Re: BUG in vb_alloc() (was: [Bug 31572] New: firewire crash at boot)

[Clemens Ladisch <clemens@ladisch.de>]

(now with Nick's correct address)

Stefan Richter wrote:
> > > https://bugzilla.kernel.org/show_bug.cgi?id=31572
> > > Created an attachment (id=51502)
> > >  --> (https://bugzilla.kernel.org/attachment.cgi?id=51502)
> > > photo of oops
> 
> EIP is at vm_map_ram+0xff/0x363.

This is in some inlined part of vb_alloc (which means that the FireWire
code is not directly at fault, it's just the first one that happens to
use this code).

> Clemens, does the hex dump tell you anything?

Half of it is missing.  (What's going on with that video output?
This GPU works fine in my machine, with a 64-bit kernel.  (And why
is an 8 GB machine using a 32-bit kernel?))

Anyway, the part immediately before the crashing instruction is:
c109c993:   31 d2                   xor    %edx,%edx
c109c995:   f7 f1                   div    %ecx
c109c997:   31 d2                   xor    %edx,%edx
c109c999:   89 c7                   mov    %eax,%edi
c109c99b:   8b 45 cc                mov    -0x34(%ebp),%eax
c109c99e:   f7 f1                   div    %ecx
c109c9a0:   39 c7                   cmp    %eax,%edi
c109c9a2:   74 04                   je     0xc109c9a8
c109c9a4:   ??...                   ???                   <-- crash here

This looks as if this check in vb_alloc triggered:

                BUG_ON(addr_to_vb_idx(addr) !=
                                addr_to_vb_idx(vb->va->va_start));

On x86, we call vm_map_ram() with 8+2 pages, so the parameters here
are vb_alloc(40960, GFP_KERNEL).

I've never tested this code during bootup; I always loaded firewire-ohci
later.


Regards,
Clemens

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>