Subject: kern/23761: dmesg output and kernel disagree on wd numbering
To: None <gnats-bugs@gnats.netbsd.org>
From: Brett Lymn (Master of the Siren) <blymn@baesystems.com.au>
List: netbsd-bugs
Date: 12/16/2003 00:07:42
>Number:         23761
>Category:       kern
>Synopsis:       dmesg output and kernel disagree on wd numbering
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Dec 15 13:38:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     Brett Lymn (Master of the Siren)
>Release:        NetBSD 1.6ZF (November 23 2003)
>Organization:
Brett Lymn
>Environment:
System: NetBSD siren 1.6ZF NetBSD 1.6ZF (SIREN.MP) #3: Sat Dec 13 17:21:14 CST 2003 root@:/usr/src/sys/arch/amd64/compile/SIREN.MP amd64
Architecture: x86_64
Machine: amd64
>Description:
	I have multiple ata controllers in my machine (both a pata and 
a sata controller) and I have noticed that when the drives are being
probed the drive numbers printed do not match the number the drive is 
available on when the machine is booted.  Here are the relevant portions of
my dmesg.boot:

cmdide0 at pci1 dev 11 function 0
cmdide0: Silicon Image SATALink 3114 (rev. 0x02)
cmdide0: bus-master DMA support present
cmdide0: primary channel wired to native-PCI mode
cmdide0: using ioapic0 pin 17 (irq 10) for native-PCI interrupt
atabus0 at cmdide0 channel 0
cmdide0: secondary channel wired to native-PCI mode
atabus1 at cmdide0 channel 1
viaide0 at pci0 dev 7 function 1
viaide0: Advanced Micro Devices AMD8111 IDE Controller (rev. 0x03)
viaide0: bus-master DMA support present
viaide0: primary channel configured to compatibility mode
viaide0: primary channel interrupting at ioapic0 pin 14 (irq 14)
atabus2 at viaide0 channel 0
viaide0: secondary channel configured to compatibility mode
viaide0: secondary channel interrupting at ioapic0 pin 15 (irq 15)
atabus3 at viaide0 channel 1
wd0 at atabus0 drive 0: <ST3120026AS>
wd0: drive supports 16-sector PIO transfers, LBA48 addressing
wd0: 111 GB, 232581 cyl, 16 head, 63 sec, 512 bytes/sect x 234441648 sectors
wd0: 32-bit data port
wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133)
wd0(cmdide0:0:0): using PIO mode 4, Ultra-DMA mode 6 (Ultra/133) (using DMA data
 transfers)
wd1 at atabus2 drive 0: <IBM-DTLA-307045>
wd1: drive supports 16-sector PIO transfers, LBA addressing
wd1: 43979 MB, 89355 cyl, 16 head, 63 sec, 512 bytes/sect x 90069840 sectors
wd1: 32-bit data port
wd1: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100)
wd1(viaide0:0:0): using PIO mode 4, Ultra-DMA mode 5 (Ultra/100) (using DMA data
 transfers)

Note here the IBM drive appears to be on wd1, but attempting to access wd1
results in an error, viz:

[root@siren] disklabel wd1
disklabel: /dev/rwd1d: Device not configured

but if I try wd2:

[root@siren] disklabel wd2
# /dev/rwd2d:
type: unknown
disk: siren
.....

the drive on wd2 is the IBM drive that dmesg tells me is on wd1.

I have checked my /dev entries and they appear consistent, viz:

[root@siren] ls -las /dev/wd?d
0 brw-r-----  1 root  operator  0,  3 Jun  1  2003 /dev/wd0d
0 brw-r-----  1 root  operator  0, 11 Jun  1  2003 /dev/wd1d
0 brw-r-----  1 root  operator  0, 19 Jun  1  2003 /dev/wd2d
0 brw-r-----  1 root  operator  0, 27 Jun  1  2003 /dev/wd3d

Just for completeness, wd0 actually appears at wd0 and seems to work
fine.

>How-To-Repeat:
	At a guess, I would say any machine with multiple ata busses would
have this problem but it is hard for me to prove this.
>Fix:
	Unknown.

>Release-Note:
>Audit-Trail:
>Unformatted: