lkml.org 
[lkml]   [2000]   [Feb]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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/

    \
     
     \ /
      Last update: 2005-03-22 13:56    [W:4.529 / U:0.096 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site