Re: Hunting the ahc boot-time panic

["John D. Baker" <jdbaker%mylinuxisp.com@localhost>]

I built a kernel with options DEBUG and symbols--and with "ofb" and
without any other framebuffer drivers so I could get more on-screen
context.  (The screen size is only 640x480, so the default font used
by the other framebuffers is so huge, relevant messages scroll of
the screen.)

I was able to recover part of the dmesg from a failed boot, but now
have more context about the nature of the panic due to using "ofb".

[...]
uni_n0 at mainbus0 address 0xf8000000
ki2c0 at uni_n0 address 0xf8001000
iic1 at ki2c0: I2C bus
uninorth0 at mainbus0
pci0 at uninorth0 bus 0
pci0: i/o space, memory space enabled
pchb0 at pci0 dev 11 function 0
pchb0: Apple Computer UniNorth AGP Interface (rev. 0x00)
ofb0 at pci0 dev 16 function 0: ATI Technologies Rage Fury MAXX AGP 4x (TMDS)
ofb0: 640 x 480, 8bpp
wsdisplay0 at ofb0 kbdmux 1: console (std, vt100 emulation)
wsmux1: connecting to wsdisplay0
direct rendering for ofb0 unsupported
uninorth1 at mainbus0
pci1 at uninorth1 bus 0
pchb1 at pci1 dev 11 function 0
pchb1: Apple Computer UniNorth Host-PCI Bridge (rev. 0x00)
ppb0 at pci1 dev 13 function 0: Digital Equipment DC21154 PCI-PCI Bridge (rev. 
0x05)
pci2 at ppb0 bus 1
ahc0 at pci2 dev 2 function 0: Adaptec 2902/04/10/15/20/30C SCSI adapter
trap type 800 at 200
panic: trap
Stopped in pid 0.1 (system) at  netbsd:cpu_Debugger+0x10:       lwz     r0, 
0x14(r1)
0x009573e0: at panic+0x25c
0x00957430: at trap+0x100
0x009574c0: kernel FPU trap by 0x200: srr1=0
            r1-0x957580 cr=0x44022042 xer=0 ctr=0x10198c
0x00957580: at 0x95763c
0x009575a0: at ahc_pci_attach+0x208
0x009575f0: at config_attach_loc+0x1b0
[...]


The debugger shows the following:

(gdb) list *(ahc_pci_attach+0x208)
0x11e458 is in ahc_pci_attach (/d0/nbsd/current/src/sys/dev/pci/ahc_pci.c:864).
859              * Before we continue probing the card, ensure that
860              * its interrupts are *disabled*.  We don't want
861              * a misstep to hang the machine in an interrupt
862              * storm.
863              */
864             ahc_intr_enable(ahc, FALSE);
865 
866             /*
867              * XXX somehow reading this once fails on some sparc64 systems.
868              *     This may be a problem in the sparc64 PCI code. Doing it


My guess is that something's not enabling IO/MEM accesses, but my
stabs at ahc_pci.c didn't change anything.

Maybe this additional context will help find the problem.

--
|/"\ John D. Baker, KN5UKS               NetBSD     Darwin/MacOS X
|\ / jdbaker[snail]mylinuxisp[flyspeck]com    OpenBSD            FreeBSD
| X  No HTML/proprietary data in email.   BSD just sits there and works!
|/ \ GPGkeyID:  D703 4A7E 479F 63F8 D3F4  BD99 9572 8F23 E4AD 1645