Re: Hunting the ahc boot-time panic

[Michael <macallan%netbsd.org@localhost>]

Hello,

On Tue, 18 Oct 2011 08:23:40 -0500 (CDT)
"John D. Baker" <jdbaker%mylinuxisp.com@localhost> wrote:

> 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.)

What font they default to depends on which fonts you compile into the kernel. 
Leave out Gallant, add something like VT8x8 and you should have all the screen 
real estate you need ;)

> 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".

ofb hasn't been used or tested for ages, please use genfb instead.

> [...]
> 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.

Does this particular ahc have:
- an OpenFirmware ROM? Are you trying to boot from it?
- any devices attached?

I remember some changes related to enabling IO and memory access a few months 
ago but the only ahc I have in regular use is in an SGI O2, and it's the device 
we use to boot from so the firmware set them up and wouldn't need kernel code 
to enable IO or memory access in the first place.
To see if that's what happens just add a printf() to dump the command/status 
register's content ( it's read early on in ahc_pci_attach(), according to your 
kernel output we crash a bit later, after the printf() that's already there )

have fun
Michael