Messages in this thread | | | Date | Thu, 10 Feb 2000 22:19:03 +1100 | From | Richard Gooch <> | Subject | Re: 2.3.42 crashes on boot (Was: [PATCH] devfs v99.11 available) |
| |
Sergey Kubushin writes: > On Wed, 9 Feb 2000, Richard Gooch wrote: > > > NOTE: the devfs-patch-v99.x patches are maintenance patches for the > > 2.2.x production kernels. Devfs development is done against recent > > development kernels. Occasionally, the latest devfs patch for the > > development kernels may be backported to 2.2.x series, but this > > happens rarely. > > > > This is against 2.2.14. Highlights of this release: > > > > - Ported devfs-patch-v99.10 to kernel 2.2.14 > > > > - Moved /dev/tty0 to /dev/vc/0 > > It's very nice, but can somebody explain why 2.3.42 with devfs v.154 > crashes on boot ? Initrd strikes back ?
Odd. Please send me (off-list) your /etc/lilo.conf so I can see exactly what is being passed to the kernel.
> Here is the oops: > > === Cut === > ksymoops 0.7c on i686 2.3.36. Options used > -V (specified) > -K (specified) > -L (specified) > -o /lib/modules/kernel/2.3.42/ (specified) > -m /boot/System.map-2.3.42 (specified) > > No modules in ksyms, skipping objects > Unable to handle kernel NULL pointer dereference at virtual address 00000038 > c0149ba1 > *pde = 00104001 > Oops: 0000 > CPU: 0 > EIP: 0010:[<c0149ba1>] > Using defaults from ksymoops -t elf32-i386 -a i386 > EFLAGS: 00010246 > eax: 00000038 ebx: 00000000 ecx: c02839f2 edx: c14fbe54 > esi: 00000018 edi: c14fbe54 ebp: ffffffed esp: c14fbb00 > ds: 0018 es: 0018 ss: 0018 > Process swapper (pid: 1, stackpage=c14fb000) > Stack: 00000100 00000000 c14fbb6c c14fbd04 c0283acd c14fbe54 c14fbca8 c02a00e0 > c0277fc8 00000000 00001000 c02839f2 00000000 c14fbb6c 00000000 00000000 > 00000000 00000000 c14fbc4c c14fbe54 c14fbca8 00000000 00000000 00000000 > Call Trace: [<c0110018>] [<c01081cb>] [<c010a010>] > Code: 39 46 20 74 2a 50 8b 46 20 50 68 c0 9e 21 c0 e8 53 52 fd ff > > >>EIP; c0149ba1 <blkdev_open+19/dc> <===== > Trace; c0110018 <do_int+a8/1b4> > Trace; c01081cb <init+5f/1e4> > Trace; c010a010 <kernel_thread+28/38> > Code; c0149ba1 <blkdev_open+19/dc> > 00000000 <_EIP>: > Code; c0149ba1 <blkdev_open+19/dc> <===== > 0: 39 46 20 cmp %eax,0x20(%esi) <===== > Code; c0149ba4 <blkdev_open+1c/dc> > 3: 74 2a je 2f <_EIP+0x2f> c0149bd0 <blkdev_open+48/dc> > Code; c0149ba6 <blkdev_open+1e/dc> > 5: 50 push %eax > Code; c0149ba7 <blkdev_open+1f/dc> > 6: 8b 46 20 mov 0x20(%esi),%eax > Code; c0149baa <blkdev_open+22/dc> > 9: 50 push %eax > Code; c0149bab <blkdev_open+23/dc> > a: 68 c0 9e 21 c0 push $0xc0219ec0 > Code; c0149bb0 <blkdev_open+28/dc> > f: e8 53 52 fd ff call fffd5267 <_EIP+0xfffd5267> c011ee08 <printk+0/1f4> > === Cut ===
If it crashes during boot (say mounting root), I would have expected mount_root() to appear in this traceback. Odd that it's not. Can you start sprinkling printk()'s around to figure out where blkdev_open() is being called from when this happens?
Also, I'll need details of how you're using initrd (whether you leave it mounted after switching root and so on).
Regards,
Richard.... Old: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |