Subject: port-alpha/25830: AlphaServer 4x00 PCI bus numbering doesn't agree with SRM
To: None <gnats-bugs@gnats.netbsd.org>
From: None <mhitch@NetBSD.org>
List: netbsd-bugs
Date: 06/05/2004 12:35:55
>Number:         25830
>Category:       port-alpha
>Synopsis:       AlphaServer 4x00 PCI bus numbering doesn't agree with SRM
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    port-alpha-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Jun 05 18:36:00 UTC 2004
>Closed-Date:
>Last-Modified:
>Originator:     Michael L. Hitch
>Release:        NetBSD 2.0E and earlier
>Organization:
	
>Environment:
	
	
System: 
Architecture: alpha
Machine: alpha
>Description:
	The PCI bus numbering on AlphaServer 4x00 machines does not match
	the numbering used by SRM.  This will cause the boot device detection
	to fail or get the wrong device.


>How-To-Repeat:
	Boot NetBSD on an AS 4x00 and note that the PCI bus number in the
	SRM boot information doesn't match the PCI bus number as probed
	by NetBSD.

	This is due to the decision to probe mid 5 of the mcbus before mid 4,
	supposedly to match what Tru64 does:

	/*
	 * Tru64 UNIX (formerly Digital UNIX (formerly DEC OSF/1)) probes for MCPCIAs
	 * in the following order:
	 *
	 *      5, 4, 7, 6
	 *
	 * This is so that the built-in CD-ROM on the internal 53c810 is always
	 * dka500.  We probe them in the same order, for consistency.
	*/

	The problem with this is that SRM (and Tru64) may probe mid 5 first,
	but it still identifies it as PCI bus 1, and PCI bus 0 on mid 4.
	NetBSD assigns the PCI bus number sequentially as it finds them,
	so the pci bus on mid5 gets 0, and the pci bus on mid4 gets 1, which
	then fails to match the SRM boot information.
		

consinit: not using prom console
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004
    The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
    The Regents of the University of California.  All rights reserved.

NetBSD 2.0_BETA (GENERIC.MP) #3: Fri Jun  4 11:07:29 MDT 2004
	mhitch@neverland.msu.montana.edu:/usr/home/mhitch/NetBSD-2-0/OBJ/alpha/sys/arch/alpha/compile.alpha/GENERIC.MP
AlphaServer 4X00 5/466 4MB, 467MHz, s/n GA12000000
8192 byte page size, 2 processors.
total memory = 512 MB
(2064 KB reserved for PROM, 509 MB used by NetBSD)
avail memory = 493 MB
mainbus0 (root)
cpu0 at mainbus0: ID 0 (primary), 21164A-2
cpu0: Architecture extensions: 1<BWX>
cpu1 at mainbus0: ID 1, 21164A-2
cpu1: Architecture extensions: 1<BWX>
mcbus0 at mainbus0: 4MB BCache
mcmem0 at mcbus0 mid 1: Memory
mcpcia0 at mcbus0 mid 5: PCI Bridge
mcpcia0: Horse Revision 3, Left Handed Saddle Revision 3, CAP Revision 2
pci0 at mcpcia0 bus 0
pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok
siop0 at pci0 dev 1 function 0: Symbios Logic 53c810 (fast scsi)
siop0: interrupting at kn300 irq 36
scsibus0 at siop0: 8 targets, 8 luns per target
mcpcia1 at mcbus0 mid 4: PCI Bridge
mcpcia1: Horse Revision 3, Left Handed Saddle Revision 3, CAP Revision 2
pci1 at mcpcia1 bus 0
pci1: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok
pceb0 at pci1 dev 1 function 0: Intel 82375EB/SB PCI-EISA Bridge (PCEB) (rev. 0x05)
vga0 at pci1 dev 2 function 0: S3 Trio32/64 (rev. 0x00)
wsdisplay0 at vga0 (kbdmux ignored): console (80x25, vt100 emulation)
mlx0 at pci1 dev 3 function 0: Mylex RAID (v2 interface)
mlx0: interrupting at kn300 irq 12
mlx0: DAC960P/PD, 1 channel, firmware 2.42-0-00, 4MB RAM
ld0 at mlx0 unit 0: JBOD, online
ld0: 8678 MB, 4407 cyl, 64 head, 63 sec, 512 bytes/sect x 17772544 sectors
mlx1 at pci1 dev 4 function 0: Mylex RAID (v2 interface)
mlx1: interrupting at kn300 irq 16
mlx1: DAC960P/PD, 1 channel, firmware 2.42-0-00, 4MB RAM
ld1 at mlx1 unit 0: RAID0, online
ld1: 31997 MB, 8126 cyl, 128 head, 63 sec, 512 bytes/sect x 65529856 sectors
ld2 at mlx1 unit 1: RAID0, online
ld2: 28749 MB, 7301 cyl, 128 head, 63 sec, 512 bytes/sect x 58877952 sectors
tlp0 at pci1 dev 5 function 0: DECchip 21140 Ethernet, pass 1.2
tlp0: broken MicroWire interface detected; setting SROM size to 1Kb
tlp0: interrupting at kn300 irq 20
tlp0: DEC DE500-XA, Ethernet address 00:00:f8:03:ca:2e
tlp0: 10baseT, 100baseTX, 100baseTX-FDX, 10baseT-FDX
eisa0 at pceb0
isa0 at pceb0
lpt0 at isa0 port 0x3bc-0x3bf irq 7
com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo
com1 at isa0 port 0x2f8-0x2ff irq 3: ns16550a, working fifo
pckbc0 at isa0 port 0x60-0x64
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0 (mux ignored): console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
midi0 at pcppi0: PC speaker
spkr0 at pcppi0
isabeep0 at pcppi0
fdc0 at isa0 port 0x3f0-0x3f7 irq 6 drq 2
mcclock0 at isa0 port 0x70-0x71: mc146818 or compatible
fd0 at fdc0 drive 0: 1.44MB, 80 cyl, 2 head, 18 sec
Kernelized RAIDframe activated
scsibus0: waiting 2 seconds for devices to settle...
cd0 at scsibus0 target 5 lun 0: <DEC, RRD45   (C) DEC, 0436> cdrom removable
cd0: async, 8-bit transfers
WARNING: can't figure what device matches "RAID 0 3 0 0 0 6000 11069"
root device: ld0a
dump device (default ld0b): 
file system (default generic): ffs
root on ld0a dumps on ld0b
init path (default /sbin/init): 
init: trying /sbin/init
stray isa irq 1
syncing disks... done
WARNING: Unable to halt secondary CPUs (0x3)

>Fix:
	The simplest way would be to probe the mcbus in order, which would
	place PCI bus 0 on mid4 and PCI bus 1 on mid5.  I don't know of
	anything on NetBSD that requires the CD to be dka500.  NetBSD doesn't
	follow the convention of hard-wiring the devices based on the device
	ID, controller number, or bus number.

	If it's really desired that the buses be probed in the same order as
	SRM/Tru64, then I can think of a couple ways to do this.

	One would be to hard-wire pcibus0 and pcibus1 to their respective
	mid slots on the mcbus.  This may very well cause problems with
	the PCI bus numbering on other alpha models.  The other models
	could also have hard-wired pcibus numbers, but since some systems
	only have one PCI bus, and others have two or more, this probably
	would not be feasible.

	Another way would be to "swizzle" pcibus0 and pcibus1 in the boot
	device detection code in dec_kn300.c.  As far as I know, that's
	the only place where NetBSD requires the SRM bus numbering to match
	the NetBSD bus numbering.
>Release-Note:
>Audit-Trail:
>Unformatted: