That's drivers/video/fbmem.c: fb_release(), and the "Code:"
disassembly shows that it is
1b: e8 f7 c0 29 00 callq xyz
20: 48 8b 93 b8 03 00 00 mov 0x3b8(%rbx),%rdx
27:* 48 8b 42 10 mov 0x10(%rdx),%rax <-- trapping instruction
which corresponds to
mutex_lock(&info->lock);
if (info->fbops->fb_release)
info->fbops->fb_release(info,1);
so it looks like 'info->fbops' is invalid. It's in %rdx, and is
0x00d000ae00b500c2, which is definitely not a valid pointer. Looks
like some bad corruption (looks like a sequence of 16-bit numbers, but
it could be anything).
Looks like nouveafb took over from vesafb. Did you do anything special
to trigger this?
Also, you do seem to have some extra patches (yama at the least). Anything else?
Linus
That's drivers/video/fbmem.c: fb_release(), and the "Code:"
disassembly shows that it is
1b: e8 f7 c0 29 00 callq xyz
20: 48 8b 93 b8 03 00 00 mov 0x3b8(%rbx),%rdx
27:* 48 8b 42 10 mov 0x10(%rdx),%rax <-- trapping instruction
which corresponds to
mutex_lock(&info->lock);
if (info->fbops->fb_release)
info->fbops->fb_release(info,1);
so it looks like 'info->fbops' is invalid. It's in %rdx, and is
0x00d000ae00b500c2, which is definitely not a valid pointer. Looks
like some bad corruption (looks like a sequence of 16-bit numbers, but
it could be anything).
Looks like nouveafb took over from vesafb. Did you do anything special
to trigger this?
No. Just boot the system.
Also, you do seem to have some extra patches (yama at the least). Anything else?
I used git clone, nothing else.
First time 2.6.38-rc6 was working.
After an update from ubuntu I get that error at boot.
The dmesg is from Ubuntu 11.04 with their kernel and is working fine.
From: Dave Airlie <airlied@gmail.com> Date: 2011-02-24 00:43:43
On Thu, Feb 24, 2011 at 10:28 AM, Linus Torvalds
[off-list ref] wrote:
On Wed, Feb 23, 2011 at 9:16 AM, Anca Emanuel [off-list ref] wrote:
quoted
quoted
Looks like nouveafb took over from vesafb. Did you do anything special
to trigger this?
No. Just boot the system.
Every boot?
And just out of interest, what happens if you don't have the vesafb
driver at all?
I think this is a race condition somewhere with plymouth getting
access to vesafb before it gets kicked off the hw,
I'm assuming removing the vga= line from the command line will stop it,
Dave.
On Thu, Feb 24, 2011 at 5:20 AM, Anca Emanuel [off-list ref] wrote:
quoted
Every boot?
Yes.
quoted
And just out of interest, what happens if you don't have the vesafb
driver at all?
I used 'e' option from grub, removed the 'set gfxpayload = $linux_gfx_mode'
and it works.
dmesg: http://pastebin.com/JAZsk4vD
Hmm. So it definitely seems to be the hand-over.
Does this patch make any difference? When we unregister the old
framebuffer, we still leave it in the registered_fb[] array, which
looks wrong. But it would also be interesting to hear if setting
CONFIG_SLUB_DEBUG_ON or CONFIG_DEBUG_PAGEALLOC makes any difference
(they'd help detect accesses to free'd data structures).
Linus
From: Anca Emanuel <hidden> Date: 2011-02-25 00:48:11
On Thu, Feb 24, 2011 at 6:37 PM, Linus Torvalds
[off-list ref] wrote:
On Thu, Feb 24, 2011 at 5:20 AM, Anca Emanuel [off-list ref] wrote:
quoted
quoted
Every boot?
Yes.
quoted
And just out of interest, what happens if you don't have the vesafb
driver at all?
I used 'e' option from grub, removed the 'set gfxpayload = $linux_gfx_mode'
and it works.
dmesg: http://pastebin.com/JAZsk4vD
Hmm. So it definitely seems to be the hand-over.
Does this patch make any difference? When we unregister the old
framebuffer, we still leave it in the registered_fb[] array, which
looks wrong. But it would also be interesting to hear if setting
CONFIG_SLUB_DEBUG_ON or CONFIG_DEBUG_PAGEALLOC makes any difference
(they'd help detect accesses to free'd data structures).
Linus
apertures_struct *a,
"%s vs %s - removing generic driver\n",
name, registered_fb[i]->fix.id);
unregister_framebuffer(registered_fb[i]);
+ registered_fb[i] = NULL;
Tested the patch, and now I get this:
dmesg: http://pastebin.com/ieMNrA7C
[ 12.252328] BUG: unable to handle kernel NULL pointer dereference
at 00000000000003b8
[ 12.252342] IP: [<ffffffff81311178>] fb_mmap+0x58/0x1d0
Ok, goodie.
Or not so goodie, but it does make it clear that yeah, the fb code
seems to be using stale pointers from that registered_fb[] array, and
the whole unregistration process is just racing with people using it.
Herton had that much bigger patch, can you test it?
Linus
apertures_struct *a,
"%s vs %s - removing generic driver\n",
name, registered_fb[i]->fix.id);
unregister_framebuffer(registered_fb[i]);
+ registered_fb[i] = NULL;
Tested the patch, and now I get this:
dmesg: http://pastebin.com/ieMNrA7C
[ 12.252328] BUG: unable to handle kernel NULL pointer dereference
at 00000000000003b8
[ 12.252342] IP: [<ffffffff81311178>] fb_mmap+0x58/0x1d0
Ok, goodie.
Or not so goodie, but it does make it clear that yeah, the fb code
seems to be using stale pointers from that registered_fb[] array, and
the whole unregistration process is just racing with people using it.
Herton had that much bigger patch, can you test it?
I think Andy's patch worked, not sure why it fell between the cracks,
either didn't appear on lkml or in my inbox at all.
if we can get Herton to repost it properly + a tested by I'm happy for
it to go in.
Dave.
apertures_struct *a,
"%s vs %s - removing generic driver\n",
name, registered_fb[i]->fix.id);
unregister_framebuffer(registered_fb[i]);
+ registered_fb[i] = NULL;
Tested the patch, and now I get this:
dmesg: http://pastebin.com/ieMNrA7C
[ 12.252328] BUG: unable to handle kernel NULL pointer dereference
at 00000000000003b8
[ 12.252342] IP: [<ffffffff81311178>] fb_mmap+0x58/0x1d0
Ok, goodie.
Or not so goodie, but it does make it clear that yeah, the fb code
seems to be using stale pointers from that registered_fb[] array, and
the whole unregistration process is just racing with people using it.
Herton had that much bigger patch, can you test it?
I think Andy's patch worked, not sure why it fell between the cracks,
either didn't appear on lkml or in my inbox at all.
if we can get Herton to repost it properly + a tested by I'm happy for
it to go in.
Dave.
apertures_struct *a,
"%s vs %s - removing generic driver\n",
name, registered_fb[i]->fix.id);
unregister_framebuffer(registered_fb[i]);
+ registered_fb[i] = NULL;
Tested the patch, and now I get this:
dmesg: http://pastebin.com/ieMNrA7C
[ 12.252328] BUG: unable to handle kernel NULL pointer dereference
at 00000000000003b8
[ 12.252342] IP: [<ffffffff81311178>] fb_mmap+0x58/0x1d0
Ok, goodie.
Or not so goodie, but it does make it clear that yeah, the fb code
seems to be using stale pointers from that registered_fb[] array, and
the whole unregistration process is just racing with people using it.
Herton had that much bigger patch, can you test it?
I think Andy's patch worked, not sure why it fell between the cracks,
either didn't appear on lkml or in my inbox at all.
if we can get Herton to repost it properly + a tested by I'm happy for
it to go in.
Dave.
apertures_struct *a,
"%s vs %s - removing generic driver\n",
name, registered_fb[i]->fix.id);
unregister_framebuffer(registered_fb[i]);
+ registered_fb[i] = NULL;
Tested the patch, and now I get this:
dmesg: http://pastebin.com/ieMNrA7C
[ 12.252328] BUG: unable to handle kernel NULL pointer dereference
at 00000000000003b8
[ 12.252342] IP: [<ffffffff81311178>] fb_mmap+0x58/0x1d0
Ok, goodie.
Or not so goodie, but it does make it clear that yeah, the fb code
seems to be using stale pointers from that registered_fb[] array, and
the whole unregistration process is just racing with people using it.
Herton had that much bigger patch, can you test it?
I think Andy's patch worked, not sure why it fell between the cracks,
either didn't appear on lkml or in my inbox at all.
if we can get Herton to repost it properly + a tested by I'm happy for
it to go in.
Dave.
Ok, goodie.
Or not so goodie, but it does make it clear that yeah, the fb code
seems to be using stale pointers from that registered_fb[] array, and
the whole unregistration process is just racing with people using it.
Herton had that much bigger patch, can you test it?
I think Andy's patch worked, not sure why it fell between the cracks,
either didn't appear on lkml or in my inbox at all.
if we can get Herton to repost it properly + a tested by I'm happy for
it to go in.
Dave.
Adding Andy on CC (btw he is away for today, may get some time to answer).
Andy, can you repost the patch?
This is the first I've seen the patch as well, but fortunately patchwork
caught it on the Cc.
There's also an outstanding patch for fixing an AB-BA deadlock between
the fb_info lock and the console lock which this will clash with. I'm
happy to rework that patch on top of Andy's patch for Anca and/or Herton
to test, though.
I'll need to do some more testing locally as well..