Re: FreeBSD 8.0 Beta2 / ALC driver crashbase

On Wed, Aug 12, 2009 at 03:48:20PM +0100, Gavin Atkinson wrote:
> On Thu, 2009-08-06 at 20:05 -0400, Jim wrote:
> > I couldn't get the copy of the if_alc driver to compile in FreeBSD 7.2
> > on my new notebook, so I decided to use 8.0, and I found an issue,
> > when I boot the installer media CD (boot only or DVD1), I get the
> > following error:
> > 
> > alc0: <Atheros AR8131 PCIe Gigabit Ethernet> irq 16 at device 0.0 on pci7
> > alc0: 0x40000 bytes of rid 0x10 res 3 failed (0, 0xffffffffffffffff).
> > alc0: cannot allocate memory resources).
> > 
> > Fatal trap 12: page fault while in kernel mode
> > cpuid = 0; apic id = 00
> > fatal virtual address = 0x08
> > fault code = supervisor read data, page not present
> > instruction pointer = 0x20:0xffffffff0024c6e8
> > stack pointer = 0x20:0xffffffff813f65f0
> > frame pointer = 0x20:0xffffffff813f6600
> > code segment = base 0x0, limit 0xfffff, type 0x1b
> >  = DLP 0, pres 1, long 1, def32 0, gran 1
> > processor eflags = interrupt enabled, resume, IOPL = 0
> > correct process = 0 (swapper)
> > [thread pid 0 tid 100000 ]
> > Stopped at   alc_phy_down+0x0:  cmpq  $0,0x8(xrax)
> > db>
> > 
> > 
> > I'm not knowledgeable about this to the point where I could debug the
> > issue, is there anything I could do to provide the developers with the
> > info needed to fix the issue, or could someone tell me how to boot the
> > installer and force it to not load if_alc, and suggest give me an idea
> > of what this means, in laymans terms so I can try to diagnose it? If I
> > had to guess, I would say it's trying to access a chunk of
> > memory/address-space that hasn't been allocated or doesn't exist, but
> > I don't know if that's correct or where to go from there.
> 
> First thing to do, at the "db> " prompt, enter "bt" and show us the
> results.  What version of FreeBSD is this?  (8.0-BETA2 I'm assuming?)
> 
> There are probably at least two issues here: 1) The allocation shouldn't
> fail, but is, and 2) it shouldn't panic.  Getting a backtrace (with "bt"
> will hopefully be enough to figure out the second issue, but for the
> first one we may need a full verbose dmesg from the system.  Do you have

I guess I found a bug in failure path. Try attached one.

> a serial console hooked up to the machine with which you could obtain
> this?
> 
> Thanks,
> 
> Gavin