Messages in this thread Patch in this message | | | Date | Sun, 26 Dec 1999 17:02:58 +0200 (EET) | From | Sergey Kubushin <> | Subject | Re: 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/
| |