Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 05 Dec 2009 19:24:57 PST
From:      Dieter <freebsd@sopwith.solgatos.com>
To:        freebsd-questions@freebsd.org
Subject:   8.0 dmesg output is mangled
Message-ID:  <200912060324.DAA25727@sopwith.solgatos.com>

Next in thread | Raw E-Mail | Index | Archive | Help
Updating an amd64 box from 7.1 to 8.0.
Console is RS-232.

Check to see if any disk names have changed:
	dmesg | grep ^ad
looks reasonable.

added
	siis_load="YES"
to loader.conf and rebooted

	dmesg | grep siis
gives output that doesn't look right at all:

siis0: <SiI3132 SATA2 controller> port 0x7c00-0x7c7f mem 0xfe6ff000-0xfe6ff07f,0
xfe6f8000-0xfe6fbfff irq 16 at device 0.0 on pci4
siis0: [ITHREAD]
siisch0: <SIIS channel> at channel 0 on siis0
siisch0: [ITHREAD]
siisch1: <SIIS channel> at channel 1 on siis0
siisch1: [ITHREAD]
ad2: 305245MB <Seagate ST3320620A 3.AAC> at ata1-master UDMA100(aprobe0:siisch0:
0:15:0): SIGNATURE: 0000
(aprobe0:siisch0:0:0:0): SIGNATURE: 0000
ad10: 1907729MB <Hitachi HDS722020ALA330 JKAOA20N> at ata5-master SATA300(aprobe
1:siisch1:0:15:0): SIGNATURE: 0000
ad14: 953869MB <SAMSUNG HD103UJ 1AA01113> at ata7-master SATA300(aprobe0:siisch1
:0:0:0): SIGNATURE: 0000
ada0 at siisch0 bus 0 target 0 lun 0
ada1 at siisch1 bus 0 target 0 lun 0

The Samsung disk is connected to a JMB363 controller, not the SiI 3132.
The SiI 3132 has a Hitachi and a Seagate.

	dmesg | grep ^ada
ada0 at siisch0 bus 0 target 0 lun 0
ada0: <Hitachi HDT721010SLA360 ST6OA31B> ATA/ATAPI-8 SATA 2.x device
ada0: 300.000MB/s transfers
ada0: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C)
ada0: Native Command Queueing enabled
ada1 at siisch1 bus 0 target 0 lun 0
ada1: <ST31500341AS CC1H> ATA/ATAPI-8 SATA 2.x device
ada1: 300.000MB/s transfers
ada1: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C)
ada1: Native Command Queueing enabled

This looks reasonable except for a 1 TB and a 1.5 TB drive having
the same number of heads, sectors/track and cylinders.  (not that
those numbers are meaningful with recent disks)

I'm thinking that perhaps the outputs from ata(4) and siis(4) are getting
jumbled together like two processes writing to the same tty?



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?200912060324.DAA25727>