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.096 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site