Re: FreeBSD 8.0 Beta2 / ALC driver crashbase

On Wed, Aug 12, 2009 at 01:21:00PM -0700, Pyun YongHyeon wrote:
> 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.
> 

FYI: Patch committed to HEAD(r196517).

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