lkml.org 
[lkml]   [1999]   [Dec]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    SubjectRe: Bug at spinlock.h line 92
    On Sat, 25 Dec 1999, Manfred wrote:

    > Sergey wrote:
    > >
    > > I'll try to redirect them to an IDE disk but I doubt it'd help - the
    > system
    > > freezes rock solid...
    > >
    > > Any ideas what can be done to help to localize a bug?
    > >
    >
    > Are you sure that your oops is caused by the spinlock-debugging code? Could

    I'm not. But the kernel does not boot with gdth and scsi as modules when
    there is no the MO diskette in a MO drive hooked to the GDT6117RP. The
    following patch DOES allow the beast to boot:

    === Cut ===
    --- 2.3/drivers/scsi/scsi_lib.c Tue Dec 21 09:35:12 1999
    +++ build-2.3/drivers/scsi/scsi_lib.c Fri Dec 24 09:50:00 1999
    @@ -821,12 +821,14 @@
    * get those allocated here.
    */
    if (!SDpnt->scsi_init_io_fn(SCpnt)) {
    + spin_lock_irq(&io_request_lock);
    continue;
    }
    /*
    * Initialize the actual SCSI command for this request.
    */
    if (!STpnt->init_command(SCpnt)) {
    + spin_lock_irq(&io_request_lock);
    continue;
    }
    }
    === Cut ===
    > you compile a UP kernel, and check if it crashes? UP kernels have a far
    > higher chance to survive an oops, and it's easier to prevent the screen
    > scrolling.

    It does not crash. The "cat /dev/scsi/gdth/0" still oopses on a first run.
    The kernel does survive the oops and I'm able to catch it. The next cat's do
    show an incomplete info (no more oopses) :

    === Cut ===
    [root@nomad SOURCES]# cat /proc/scsi/gdth/0
    Driver Parameters:
    reserve_mode: 1 reserve_list: --
    max_ids: 127 hdr_channel: 0

    Disk Array Controller Information:
    Number: 0 Name: GDT6117RP
    Driver Ver.: 1.14 Firmware Ver.: 1.25.00-R02D
    Serial No.: 0x11C0362D Cache RAM size: 16384 KB

    Physical Devices:[root@nomad SOURCES]#
    === Cut ===

    As one can see the output ends on "Physical Devices:", no even a new line
    after it.

    This is from 2.2.10-ac-10:

    === Cut ===
    [root@nomad SOURCES]# cat /proc/scsi/gdth/0
    Driver Parameters:
    reserve_mode: 1 reserve_list: --
    max_ids: 127 hdr_channel: 0

    Disk Array Controller Information:
    Number: 0 Name: GDT6117RP
    Driver Ver.: 1.14 Firmware Ver.: 1.25.00-R02D
    Serial No.: 0x11C0362D Cache RAM size: 16384 KB

    Physical Devices:
    Chn/ID/LUN: A/04/0 Name: FUJITSU M2513EL 0020
    Capacity [MB]: 0 To Log. Drive: --

    Chn/ID/LUN: A/05/0 Name: PIONEER CD-ROM DR-U16S 1.01
    Capacity [MB]: 0 To Log. Drive: --

    Chn/ID/LUN: A/00/0 Name: IBM DGHS18V 03C0
    Capacity [MB]: 17501 To Log. Drive: 0
    Retries: 0 Reassigns: 0
    Grown Defects: 0

    Logical Drives:
    Number: 0 Status: ok
    Capacity [MB]: 17501 Type: Disk
    To Array Drv.: --

    Array Drives:
    --

    Host Drives:
    Number: 0 Arr/Log. Drive: 0
    Capacity [MB]: 17500 Start Sector: 0

    Controller Events:
    [root@nomad SOURCES]#
    === Cut ===

    This is ksymoops output on the oops:

    === Cut ===
    ksymoops 0.7c on i686 2.3.35pre3. Options used
    -V (specified)
    -k ./ksyms (specified)
    -l ./modules (specified)
    -o /lib/modules/kernel/2.3.35pre3/ (default)
    -m /boot/System.map (default)

    Unable to handle kernel NULL pointer dereference at virtual address 00000000
    Oops: 0000
    CPU: 0
    *pde = 0b863001
    Oops: 0000
    CPU: 0
    EIP: 0010:[<c010c19a>]
    Using defaults from ksymoops -t elf32-i386 -a i386
    EFLAGS: 00010082
    eax: 00000000 ebx: 0000002b ecx: cd976000 edx: cb3bb99c
    esi: cb3bc000 edi: 00000000 ebp: d0800000 esp: cb3bb93c
    ds: 0018 es: 0018 ss: 0018
    Process cat (pid: 932, stackpage=cb3bb000)
    Stack: cb3bbd50 00000000 d1000000 c010c1ff cb3bb99c c01c8368 c01cc1be 00000000
    c011236e c01cc1be cb3bb99c 00000000 cb3ba000 cb3bbbc8 cb3bbd50 cb3bba6c
    cc2fb99c cc2fb9b4 cb3ba000 50081002 1ec89fe8 c010bea1 cb3bb99c 00000000
    Call Trace: [<d1000000>] [<c010c1ff>] [<c01c8368>] [<c01cc1be>] [<c011236e>] [<c01cc1be>] [<c010bea1>]
    [<d080915c>] [<d0801b04>] [<d081a114>] [<d081a158>] [<d0819131>] [<c0125c01>] [<c0125afc>] [<c012236c>]
    [<d081a158>] [<c0122345>] [<c012216c>] [<c0122345>] [<c0152cb5>] [<c0154bb5>] [<d0818108>] [<d0805490>]
    [<c01548b9>] [<c012f89a>] [<c010bd90>]
    Code: 0f b6 04 07 50 68 60 83 1c c0 e8 73 ac 00 00 83 c4 08 47 83
    >>EIP; c010c19a <show_registers+1ba/1e8> <=====
    Trace; d1000000 <END_OF_CODE+73eddc/????>
    Trace; c010c1ff <die+37/44>
    Trace; c01c8368 <stext_lock+2bf8/39cc>
    Trace; c01cc1be <IRQ0x0f_interrupt+2fde/6760>
    Trace; c011236e <do_page_fault+3c2/4c4>
    Trace; c01cc1be <IRQ0x0f_interrupt+2fde/6760>
    Trace; c010bea1 <error_code+2d/34>
    Trace; d080915c <[scsi_mod]scsi_insert_special_cmd+6c/78>
    Trace; d0801b04 <[scsi_mod]scsi_do_cmd+18c/1b4>
    Trace; d081a114 <[gdth]gdth_do_cmd+9c/e0>
    Trace; d081a158 <[gdth]gdth_scsi_done+0/58>
    Trace; d0819131 <[gdth]gdth_get_info+4fd/1444>
    Trace; c0125c01 <filemap_nopage+105/474>
    Trace; c0125afc <filemap_nopage+0/474>
    Trace; c012236c <do_no_page+5c/1b0>
    Trace; d081a158 <[gdth]gdth_scsi_done+0/58>
    Trace; c0122345 <do_no_page+35/1b0>
    Trace; c012216c <do_anonymous_page+c0/264>
    Trace; c0122345 <do_no_page+35/1b0>
    Trace; c0152cb5 <proc_get_inode+41/100>
    Trace; c0154bb5 <proc_lookup+8d/98>
    Trace; d0818108 <[gdth]gdth_proc_info+90/98>
    Trace; d0805490 <[scsi_mod]proc_scsi_read+44/60>
    Trace; c01548b9 <proc_file_read+141/214>
    Trace; c012f89a <sys_read+be/e0>
    Trace; c010bd90 <system_call+34/38>
    Code; c010c19a <show_registers+1ba/1e8>
    00000000 <_EIP>:
    Code; c010c19a <show_registers+1ba/1e8> <=====
    0: 0f b6 04 07 movzbl (%edi,%eax,1),%eax <=====
    Code; c010c19e <show_registers+1be/1e8>
    4: 50 push %eax
    Code; c010c19f <show_registers+1bf/1e8>
    5: 68 60 83 1c c0 push $0xc01c8360
    Code; c010c1a4 <show_registers+1c4/1e8>
    a: e8 73 ac 00 00 call ac82 <_EIP+0xac82> c0116e1c <printk+0/15c>
    Code; c010c1a9 <show_registers+1c9/1e8>
    f: 83 c4 08 add $0x8,%esp
    Code; c010c1ac <show_registers+1cc/1e8>
    12: 47 inc %edi
    Code; c010c1ad <show_registers+1cd/1e8>
    13: 83 00 00 addl $0x0,(%eax)

    === Cut ===

    > If the UP kernel survives "cat /proc/scsi/gdth/0", then modify
    > linux/include/linux/spinlock.h:
    > - #define DEBUG_SPINLOCKS 0
    > +#define DEBUG_SPINLOCKS 2
    >
    > recompile for UP, and retry. Now the kernel should log a few lines, please
    > post them.

    Alas... I did recompile kernel with DEBUG_SPINLOCKS but I'm unable to boot
    it - there a whole lot of unresolved symbols in scsi modules so the root fs
    can't be mounted...

    > We'll find the bug,
    > Manfred

    It'd be very good. But I don't know how to help you any further...
    Unfortunately, I don't have a line printer around to use an lp console...

    BTW, reboot does also crash the kernel so the reboot procedure doesn't
    complete (all fs'es are unmounted, all processes are killed, kernel says
    something kinda "Rebooting the system" and whoila - oops, segmentation fault
    on running reboot)...

    About the gdth driver - it seems that 2.3.35preX contains the very same
    driver that my working 2.2.10-ac10 does (1.14). I doubt that 2.2.x kernel
    modules are well suited for a 2.3.xx, that it could also be a source of the
    problem. As one can see the last revision mark and comment in the gdth
    source is:

    === Cut ===
    * Tested with Linux 1.2.13, ..., 2.2.4 *
    * *
    * $Log: gdth.c,v $
    * Revision 1.23 1999/03/26 09:12:31 achim
    === Cut ===

    Yes, the 2.2.10 and 2.3.35preX gdth sources do differ, but I suspect that
    the driver has not being modified by the ICP-Vortex itself 'coz the revision
    mark is not changed. There is no also any sign of life from achim - the
    messages seems to go into the black hole... Does it mean that ICP-Vortex did
    abandon to develop their drivers for Linux? May be all of GDTxxx owners are
    doomed and they'd better exchange these otherwise very good controllers for
    something else which IS supported? It'd be a pain in the ass to do so...

    ===========================================================================
    Sergey Kubushin aka the Tamer < > The impossible we do immediately.
    e-mail: ksi@ksi-linux.com SK320-RIPE < > Miracles require 24-hour notice.
    ===========================================================================


    -
    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:55    [W:0.035 / U:30.616 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site