> Just tried to boot 2.3.33. Unfortunately enough, the gdth driver does not
> work for me. I have the root fs on a scsi disk plugged into the GDT6117RP
> controller so I can't use that kernel at all.
>
> The beast did actually boot for the first time and oopsed when I did try to
> "cat /proc/scsi/gdth/0". Mea culpa, I did not copy the oops from the screen
> by hand thinking that I'd better point my syslog to another machine to get
> the oops logged. Unfortunatelly, it didn't work - kernel now oopses when
> initializing the adapter outta initrd, oops goes off screen and console is
> locked so no scrollback available... That's why I can't give an oops
> trace...
>
> Kernel is built fully modular (all scsi layer is modular, ide too) with
> gcc-2.95.2. The use of kgcc-2.7.2.3 does not cure the problem. The system is
> double Xeon/550 with 256 Mbyte RAM. Sure, kernel is built SMP. 64 Gbyte RAM
> support is turned on.
>
> I'm ready to make any test required to get the gdth driver fixed. Any ideas?
I did catch an oops. The kernel behaviour is extremely strange. I've been
working in 2.2.10-ac10, did install the fresh compiled 2.3.34 and said
"reboot". The machine did reboot and 2.3.34 did come up and all was good
until I did "cat /proc/scsi/gdth/0" when it did oops and my scsi disks died.
Then it was impossible to boot to 2.3.34 - it oopsed insmoding gdth driver
every time I did try to boot it. I did try to poweroff the machine, to boot
outta 2.2.10-ac10 to no avail... The first oops when cat'ing
/proc/scsi/gdth/0 have been accompanied with something like "Lock on CPU0"
etc.
There have been the following right before the oops itself:
kernel BUG at /tmp/build-kernel/usr/src/linux/include/asm/spinlock.h:92!
and "Segmentation fault" afterwards.
scsi_mod and sd_mod have been loaded before the gdth driver and aic7xxx was
succesfully insmoded after insmod did segfault on gdth.
This is the oops itself (looks strange with all those END_OF_CODE+ , but
there it is)...
=== Cut ===
ksymoops 0.7c on i686 2.2.10-ac10. Options used
-V (specified)
-K (specified)
-L (specified)
-o /lib/modules/kernel/2.3.34 (specified)
-m /boot/System.map-2.3.34 (specified)
No modules in ksyms, skipping objects
invalid operand: 0000
CPU: 0
EIP: 0010:[<c01c747a>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010282
eax: 00000050 ebx: c157a164 ecx: c0250a5c edx: c0250a4c
esi: 00000202 edi: 00000286 ebp: cfe81dac esp: cfe81d58
ds: 0018 es: 0018 ss: 0018
Process insmod (pid: 9, stackpage=cfe81000)
Stack: 0000005c 00000000 cfdca3c8 c0142a8d c157a164 00000810 c0255290 00000011
cfe80000 01234567 cfe80000 00000000 00000000 cfe81da4 00000000 01234567
cfe80000 cfdca3d0 cfe81da4 00000000 c157a4a0 c01445d1 cfdca380
Call Trace: [<c0142a8d>] [<c01445d1>] [<c0166245>] [<c0164e16>] [<d0817370>] [<c01651a5>] [<d0817bea>]
[<d0817863>] [<d08188a0>] [<d0803ed2>] [<d0825780>] [<d081a04d>] [<d081a048>] [<d08045e6>] [<d0825780>]
[<d081a000>] [<d082276e>] [<d0825780>] [<c0122a57>] [<d081a000>] [<d0816000>] [<d081a048>] [<c010cea0>]
[<d08258c7>] [<d081a000>]
Code: 0f 0b 83 c4 0c 90 f0 0f ba 35 c4 b4 25 c0 00 56 9d 5b 5e c3
>>EIP; c01c747a <unplug_device+a2/b8> <=====
Trace; c0142a8d <__wait_on_buffer+26d/378>
Trace; c01445d1 <bread+45/64>
Trace; c0166245 <msdos_partition+61/2fc>
Trace; c0164e16 <check_partition+e6/120>
Trace; d0817370 <END_OF_CODE+105030e4/????>
Trace; c01651a5 <resetup_one_dev+3d/78>
Trace; d0817bea <END_OF_CODE+1050395e/????>
Trace; d0817863 <END_OF_CODE+105035d7/????>
Trace; d08188a0 <END_OF_CODE+10504614/????>
Trace; d0803ed2 <END_OF_CODE+104efc46/????>
Trace; d0825780 <END_OF_CODE+105114f4/????>
Trace; d081a04d <END_OF_CODE+10505dc1/????>
Trace; d081a048 <END_OF_CODE+10505dbc/????>
Trace; d08045e6 <END_OF_CODE+104f035a/????>
Trace; d0825780 <END_OF_CODE+105114f4/????>
Trace; d081a000 <END_OF_CODE+10505d74/????>
Trace; d082276e <END_OF_CODE+1050e4e2/????>
Trace; d0825780 <END_OF_CODE+105114f4/????>
Trace; c0122a57 <sys_init_module+573/6b4>
Trace; d081a000 <END_OF_CODE+10505d74/????>
Trace; d0816000 <END_OF_CODE+10501d74/????>
Trace; d081a048 <END_OF_CODE+10505dbc/????>
Trace; c010cea0 <system_call+34/38>
Trace; d08258c7 <END_OF_CODE+1051163b/????>
Trace; d081a000 <END_OF_CODE+10505d74/????>
Code; c01c747a <unplug_device+a2/b8>
00000000 <_EIP>:
Code; c01c747a <unplug_device+a2/b8> <=====
0: 0f 0b ud2a <=====
Code; c01c747c <unplug_device+a4/b8>
2: 83 c4 0c add $0xc,%esp
Code; c01c747f <unplug_device+a7/b8>
5: 90 nop
Code; c01c7480 <unplug_device+a8/b8>
6: f0 0f ba 35 c4 b4 25 lock btrl $0x0,0xc025b4c4
Code; c01c7487 <unplug_device+af/b8>
d: c0 00
Code; c01c7489 <unplug_device+b1/b8>
f: 56 push %esi
Code; c01c748a <unplug_device+b2/b8>
10: 9d popf
Code; c01c748b <unplug_device+b3/b8>
11: 5b pop %ebx
Code; c01c748c <unplug_device+b4/b8>
12: 5e pop %esi
Code; c01c748d <unplug_device+b5/b8>
13: c3 ret
=== Cut ===
This is "cat /proc/scsi/gdth/0" output from the running 2.2.10-ac10:
=== Cut ===
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.22.09-N01D
Serial No.: 0x11C0362D Cache RAM size: 16384 KB
Physical Devices:
Chn/ID/LUN: A/00/0 Name: IBM DGHS18V 03C0
Capacity [MB]: 17501 To Log. Drive: 0
Retries: 0 Reassigns: 0
Grown Defects: 0
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: --
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:
=== Cut ===
I do hope that it does help and the gdth driver will be fixed. I can't move
to 2.3.xx until it's not :(((
I'm ready to make any necessary experiments to get it working. Please, let
me know...
===========================================================================
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/