Hide Forgot
checking if image is initramfs... it is Freeing initrd memory: 5693k freed Unable to handle kernel NULL pointer dereference at 0000000000000000 RIP: [<ffffffff810838e9>] special_mapping_nopage+0x3c/0x63 PGD 7f568067 PUD 7f571067 PMD 0 Oops: 0000 [1] SMP CPU 1 Modules linked in: Pid: 219, comm: hotplug Not tainted 2.6.23.9-77.fc8 #1 RIP: 0010:[<ffffffff810838e9>] [<ffffffff810838e9>] special_mapping_nopage+0x3c/0x63 RSP: 0000:ffff810037f41d50 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff81007f4faff8 RCX: ffffffff8137e240 RDX: 0000000000000000 RSI: 00007fffeebfe000 RDI: ffff81007f4d8420 RBP: ffff81007f4d8420 R08: 00000007fffeebfe R09: 0000000000000000 R10: 000000006ffffdff R11: 000000006ffffe34 R12: 0000000000000000 R13: ffff81007f4da000 R14: 00007fffeebfe020 R15: ffff81007f4d8420 FS: 0000000000000000(0000) GS:ffff810002c3f300(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000000 CR3: 000000007f4ae000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process hotplug (pid: 219, threadinfo ffff810037f40000, task ffff81007f4bc820) Stack: ffffffff8107e42c 00000010000284d0 ffff81007f569ba8 00ff81000000f2a8 0000000000000000 ffff810000000000 00000007fffeebfe 00007fffeebfe000 0000000000000000 0000000000000004 0000000000400040 ffff81007f4d80b0 Call Trace: [<ffffffff8107e42c>] __do_fault+0x89/0x489 [<ffffffff81081bd7>] handle_mm_fault+0x4ed/0x976 [<ffffffff81084a46>] vma_link+0x70/0xfd [<ffffffff8125f037>] do_page_fault+0x45b/0x7e4 [<ffffffff810115ef>] arch_get_unmapped_area+0x184/0x1f9 [<ffffffff8108598c>] do_mmap_pgoff+0x2eb/0x350 [<ffffffff81120cec>] __up_write+0x27/0xf3 [<ffffffff8125d51d>] error_exit+0x0/0x84 Code: 48 8b 08 48 85 c9 74 1b 48 8b 01 48 89 ca 25 00 40 02 00 48 RIP [<ffffffff810838e9>] special_mapping_nopage+0x3c/0x63 RSP <ffff810037f41d50> CR2: 0000000000000000 I see many of these oops errors during bootup with my experimental mkinitrd. I probably introduced a bug in nash that is triggering this, but according to hpa I am likely hitting an actual kernel bug. The system *does* successfully boot after many of these oopses. What I don't understand is how it happens only after "Freeing initrd memory"? kernel-2.6.23.9-77.fc8.x86_64
http://fedorapeople.org/~wtogami/temp/mkinitrd-kernel-oops/ SRPM and x86_64 build of mkinitrd that exposes this kernel bug. If you are running a different arch, simply rebuild the SRPM. So far I only know it happens on my x86_64 laptop, I haven't tested it on i386 yet. http://wtogami.livejournal.com/21452.html You can follow instructions from here in order to safely use the above experimental mkinitrd to expose this bug. Note that the system DOES boot even with the kernel oopses. It *is* a bug in this experimental mkinitrd, but according to hpa and riel this is a genuine kernel bug. Here are more debug tips: 1) yum install busybox Then mkinitrd will pull in busybox into the initrd so you have more utilities to use while debugging from the initrd shell. 2) Remove "quiet" and add "verbose shell" to your kernel args. This will display everything that is run as it happens, and drop to a shell before it boots the system. "busybox dmesg"
Another thing... It isn't clear exactly where the kernel oops occurs or what initrd or nash is doing at the time of the oops. Because if you let it boot into the OS, then subsequently use dmesg, then you see the oopses after "Freeing initrd memory". But if you use "shell" arg and drop into the shell before it boots your system, you see the kernel oopses earlier during the initrd. I am a bit confused by this.
pages is NULL here, implying vma->vm_private_data was NULL: static struct page *special_mapping_nopage(struct vm_area_struct *vma, unsigned long address, int *type) { struct page **pages; BUG_ON(address < vma->vm_start || address >= vma->vm_end); address -= vma->vm_start; for (pages = vma->vm_private_data; address > 0 && *pages; ++pages) address -= PAGE_SIZE; ===> if (*pages) { struct page *page = *pages; get_page(page); return page; } return NOPAGE_SIGBUS; }
Does booting with kernel option 'vdso=0' make any difference?
vdso=0 avoids this kernel oops!
hotplug is apparently being run before the vdso is initialized.
Workaround: don't put an executable called /sbin/hotplug in the initrd.
This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '8'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 8's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 8 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.