Bug 49993 - SCSI driver aha152x 2.4 craches with PCMCIA Adaptec SlimSCSI card and Seagate ST15150N drive
SCSI driver aha152x 2.4 craches with PCMCIA Adaptec SlimSCSI card and Seagate...
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.1
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Arjan van de Ven
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-07-25 16:14 EDT by Henrik Nilsson
Modified: 2008-08-01 12:22 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-30 11:39:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Henrik Nilsson 2001-07-25 16:14:17 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.75 [en] (X11; U; Linux 2.2.16-3 i686)

Description of problem:
I'm running RedHat Linux (and Windows98, see below) on a Dell Latitude CPi
D266XT.
The SCSI driver aha152x v. 2.4 (as included with RH 7.1) fails/crashes when
trying to
talk to an externally mounted Seagate ST15150N (4.1 GByte, firmware 5216)
drive
over an Adaptec PCMCIA APA-1460 SlimSCSI adapter. (According to Windows98:
Adaptec APA-1425/50/60 PCMCIA SCSI Host Adapter.) The really weird thing is
that 
everything seems to work when I connect a 250 MByte external SCSI iomega
Zip
drive, or a Seagate ST31200N (1 GByte) external SCSI hard drive (these are
the three
external SCSI devices I have). Everything works great under RH 6.2 (with
aha152x v.
1.7) and Windows98. I've switched back and forth between the three
different operating
systems numerous times with EXACTLY the same hardware configuartion, so I'm
sure
this is not a hardware problem. Or at least not just a hardware problem.
I've also tried
with the PCMCIA-enabled floppy boot images for installation, and again
everything
works fine for RH6.2 whereas RH7.1 crashes with a stack dump when (and only
when) the ST15150N disk is connected. Also, if I access /proc/scsi after
booting
RH7.1 with the ST15150N attached, I get a segmentation fault and a stack
dump
in the log files (included below). Furthermore, shutting down the system in
this
condition typically fails (with another stack dump) sufficiently early that
the
system complains about not having been properly shut down necessitating an
fsck
when rebooted.


How reproducible:
Always

Steps to Reproduce:
1. Insert Adaptec APA-1460 SlimSCSI PCMCIA host adapter.
2 .Connect external Seagate ST15150N 4.1 GByte SCSI hard disk.
3. Boot RedHat 7.1 (or use the RH7.1 PCMCIA installation floppy image).
	

Actual Results:  Here are (what I believe are the relevant) excerpts from
/var/log/messages:

Jul 25 13:53:40 localhost pcmcia: Starting PCMCIA services:
Jul 25 13:53:42 localhost kernel: Linux PCMCIA Card Services 3.1.22
Jul 25 13:53:42 localhost kernel:   options:  [pci] [cardbus] [pm]
Jul 25 13:53:43 localhost rc: Starting pcmcia:  succeeded
Jul 25 13:53:43 localhost cardmgr[597]: starting, version is 3.1.22
Jul 25 13:53:43 localhost cardmgr[597]: watching 2 sockets
Jul 25 13:53:43 localhost kernel: cs: IO port probe 0x0c00-0x0cff: clean.
Jul 25 13:53:43 localhost kernel: cs: IO port probe 0x0100-0x04ff:
excluding 0x210-0x217 0x220-0x22f 0x280-0x287 0x378-0x37f 0x388-0x38f
0x4d0-0x4d7
Jul 25 13:53:43 localhost kernel: cs: IO port probe 0x0a00-0x0aff: clean.
Jul 25 13:53:43 localhost cardmgr[597]: initializing socket 0
Jul 25 13:53:43 localhost kernel: cs: memory probe 0xa0000000-0xa0ffffff:
clean.Jul 25 13:53:43 localhost cardmgr[597]: socket 0: Adaptec APA-1460
SlimSCSI
Jul 25 13:53:43 localhost cardmgr[597]: executing: 'modprobe aha152x_cs'
Jul 25 13:53:44 localhost kernel: SCSI subsystem driverRevision: 1.00
Jul 25 13:53:45 localhost kernel: aha152x: processing commandline: ok
Jul 25 13:53:45 localhost kernel: aha152x: BIOS test: passed, detected 1
controller(s)
Jul 25 13:53:45 localhost kernel: aha152x: resetting bus...
Jul 25 13:53:45 localhost kernel: aha152x0: vital data: rev=1, io=0x340
(0x340/0x340), irq=3, scsiid=7, reconnect=enabled, parity=enabled,
synchronous=disabled, delay=100, extended translation=disabled
Jul 25 13:53:45 localhost kernel: aha152x0: trying software interrupt, ok.
Jul 25 13:53:45 localhost kernel: scsi0 : Adaptec 152x SCSI driver;
$Revision: 2.4 $
Jul 25 13:53:51 localhost kernel: (scsi0:0:0) cannot abort running or
disconnected command
Jul 25 13:53:51 localhost kernel: (scsi0:0:0) cannot reset current device
Jul 25 13:53:51 localhost kernel: aha152x0: scsi reset in
Jul 25 13:54:06 localhost kernel: (scsi0:0:0) cannot abort running or
disconnected command
Jul 25 13:54:06 localhost kernel: scsi: device set offline - not ready or
command retry failed after bus reset: host 0 channel 0 id 0 lun 0
Jul 25 13:56:02 localhost kernel: aha152x: timer expired
Jul 25 13:56:02 localhost kernel: aha152x0: scsi reset in
Jul 25 13:56:07 localhost kernel: scsi: device set offline - not ready or
command retry failed after bus reset: host 0 channel 0 id 1 lun 0
Jul 25 13:56:09 localhost cardmgr[597]: get dev info on socket 0 failed: No
such device
Jul 25 13:56:09 localhost kernel: aha152x_cs: no SCSI devices found
Jul 25 13:56:09 localhost kernel: scsi : 0 hosts left.
Jul 25 13:56:09 localhost kernel: Trying to free nonexistent resource
<00000340-0000035f>
Jul 25 13:56:09 localhost cardmgr[597]: initializing socket 1
Jul 25 13:56:09 localhost cardmgr[597]: socket 1: 3Com 3c575-TX Fast
EtherLink XL
Jul 25 13:56:09 localhost cardmgr[597]: executing: 'modprobe cb_enabler'
Jul 25 13:56:09 localhost cardmgr[597]: executing: 'modprobe 3c59x'
Jul 25 13:56:09 localhost cardmgr[597]: executing: './network start 3c59x'
Jul 25 13:58:14 localhost modprobe: modprobe: Can't locate module
char-major-81

(I can send you the complete log if needed.)

Once booted, trying to print /proc/scsi/scsi or /proc/scsi/aha152x/0 fails
with
segmentation fault. The following entries can be found in /var/log/messages
after
this:

Trying to cat /proc/scsi/scsi:

Jul 25 14:41:21 localhost kernel:  printing eip:
Jul 25 14:41:21 localhost kernel: c01ff017
Jul 25 14:41:21 localhost kernel: pgd entry c3c6b000: 0000000000000000
Jul 25 14:41:21 localhost kernel: pmd entry c3c6b000: 0000000000000000
Jul 25 14:41:21 localhost kernel: ... pmd not present!
Jul 25 14:41:21 localhost kernel: Oops: 0000
Jul 25 14:41:21 localhost kernel: CPU:    0
Jul 25 14:41:21 localhost kernel: EIP:    0010:[vsprintf+423/896]
Jul 25 14:41:21 localhost kernel: EIP:    0010:[<c01ff017>]
Jul 25 14:41:21 localhost kernel: EFLAGS: 00010297
Jul 25 14:41:21 localhost kernel: eax: 000a0a0c   ebx: ffffffff   ecx:
000a0a0c   edx: fffffffe
Jul 2514:41:21 localhost kernel: esi: c3c5d079   edi: c3caff04   ebp:
ffffffff   esp: c3cafecc
Jul 25 14:41:21 localhost kernel: ds: 0018   es: 0018   ss: 0018
Jul 25 14:41:21 localhost kernel: Process cat (pid: 1189,
stackpage=c3caf000)
Jul 25 14:41:21 localhost kernel: Stack: 00000000 0000000a 00000013
0000005c 00000013 c3c5d013 c01ff204 c3c5d06f 
Jul 25 14:41:21 localhost kernel:        c88a416d c3caff00 c8896a9f
c3c5d06f c88a4162 000a0a0c c3c5d06e c88a414e 
Jul 25 14:41:21 localhost kernel:        c7a54400 c77c7c00 00000013
c3caff34 c88933fd c7a54400 c3c5d000 c3caff34 
Jul 25 14:41:21 localhost kernel: Call Trace: [sprintf+20/32]
[sound:__insmod_sound_S.bss_L5292+442701/116199393]
[sound:__insmod_sound_S.bss_L5292+387711/116254383]
[sound:__insmod_sound_S.bss_L5292+442690/116199404]
[sound:__insmod_sound_S.bss_L5292+442670/116199424]
[sound:__insmod_sound_S.bss_L5292+373725/116268369]
[proc_file_read+148/400] 
Jul 25 14:41:21 localhost kernel: Call Trace: [<c01ff204>] [<c88a416d>]
[<c8896a9f>] [<c88a4162>] [<c88a414e>] [<c88933fd>] [<c014fbc4>] 
Jul 25 14:41:21 localhost kernel:        [sys_read+150/208]
[system_call+51/56] Jul 25 14:41:21 localhost kernel:        [<c01339a6>]
[<c010901b>] 
Jul 25 14:41:21 localhost kernel: 
Jul 25 14:41:21 localhost kernel: Code: 80 38 00 74 07 40 4a 83 fa ff 75 f4
29 c8 f6 04 24 10 89 c3 

Trying to cat /proc/scsi/aha152x.0:

Jul 25 14:44:42 localhost kernel: Unable to handle kernel NULL pointer
dereference at virtual address 00000000
Jul 25 14:44:42 localhost kernel:  printing eip:
Jul 25 14:44:42 localhost kernel: c88b56cc
Jul 25 14:44:42 localhost kernel: pgd entry c3c12000: 0000000000000000
Jul 25 14:44:42 localhost kernel: pmd entry c3c12000: 0000000000000000
Jul 25 14:44:42 localhost kernel: ... pmd not present!
Jul 25 14:44:42 localhost kernel: Oops: 0000
Jul 25 14:44:42 localhost kernel: CPU:    0
Jul 25 14:44:42 localhost kernel: EIP:   
0010:[sound:__insmod_sound_S.bss_L5292+513708/116128386]
Jul 25 14:44:42 localhost kernel: EIP:    0010:[<c88b56cc>]
Jul 25 14:44:42 localhost kernel: EFLAGS: 00010096
Jul 25 14:44:42 localhost kernel: eax: 00000000   ebx: c2e7d1a5   ecx:
c88b8239   edx: c88b8238
Jul 25 14:44:42 localhost kernel: esi: c2e7d19d   edi: c7093d88   ebp:
c2e7d0f1   esp: c3c31ecc
Jul 25 14:44:43 localhost kernel: ds: 0018   es: 0018   ss: 0018
Jul 25 14:44:43 localhost kernel: Process cat (pid: 1224,
stackpage=c3c31000)
Jul 25 14:44:43 localhost kernel: Stack: c7093d88 c2e7d0f1 00000296
c77c7c00 c88b65c7 c2e7d0f1 c7093d88 c2ee7da0 
Jul 25 14:44:43 localhost kernel:        c3c31efc 00000000 00000c00
00000000 c3c31f68 c2e7d000 00000c00 00000000 
Jul 25 14:44:43 localhost kernel:        c3c31f68 c2e7d000 c88964af
c2e7d000 c3c31f68 00000000 00000c00 00000000 
Jul 25 14:44:43 localhost kernel: Call Trace:
[sound:__insmod_sound_S.bss_L5292+517543/116124551]
[sound:__insmod_sound_S.bss_L5292+386191/116255903]
[proc_file_read+206/400] [sys_read+150/208] [sys_brk+164/208]
[system_call+51/56] 
Jul 25 14:44:43 localhost kernel: Call Trace: [<c88b65c7>] [<c88964af>]
[<c014fbfe>] [<c01339a6>] [<c01236f4>] [<c010901b>] 
Jul 25 14:44:43 localhost kernel: 
Jul 25 14:44:43 localhost kernel: Code: 8b 08 51 68 4d 82 8b c8 53 e8 16 9b
94 f7 01 c3 29 eb 83 c4 

Also, shutting down the systemin this state typically fails, producing
another
similarly looking stack dump. Sometimes is seems as if the kernel(?)
manages
to deactivate the aha152x module after some time. Then /proc/scsi/scsi just
indicates that there are no connected devices, /proc/scsi/aha152x/0 does
not exist,
and the system shuts down fine.

As stated in the description above, everything works fine if I connect a
iomega 250Mbyte zip drive or an Seagate ST31200N drive (or both) instead of
the ST15150N.

I have also tried to boot the system with the PCMCIA enabled installation
kernel
shipped with RH7.1 (pcmcia.img and pcmciadd.img). Typically, the process
will hang twhen trying to activate the PCMCIA devices. After a while, a
stack
dump like this might be produced (hand transcribed, so may not be 100 %
accurate):

Oops: 0000
EIP: 0010: [<c8a4d9a7>]
eax: 00000000 ebx: c7bcfd9- ecx: c8a4da28 edx: 00000000
esi: 00000000 edi: c7be0478 ebp: c7be0400 esp: c7bcff3c
ds: 0018 es: 0018 ss: 0018

Process: SCSI_eh_0 (pid: 46, stack page = c7bcf000)
Stack: 00000086 00000286 c6be0400 00000000 c7cb2e00 c8a4da3b c7be0400
c7be0478
          00000286 c7cb2e00 c8a05269 c7cb2e00 00000001 00000000 c8a058eb
c7cb2e00
          c7bcffd0 c7beffd0 c7cb2a00 00000000 c7be0400 c7be0400 c7be0400
c7be0400

Call Trace: [<c8a4da3b>] [<c8a05269>] [<c8a05d86>] [<c0108f89>]
[<c01074fe>] [<c8a05ca8>]

Code: f6 80 fb 00 00 00 10 75 66 8b 0f 31 d2 eb 0c 89 f6 89 ca 8b

And as I've said, when trying booting with the RH6.2 pcmcia.img, everything
works
fine.


Expected Results:  Since the ST15150N works under RH6.2 and Windows98, I
would expect it to
work also under RH7.1.

I have swithed between RH7.1, RH6.2, and Windows98 repeatedly by switching
between an old internal IDE Hard drive containing RH6.2 and Windows98 and a
new
one containing RH7.1, keeping the rest of the hardware setup EXACTLY the
same to
make sure that it is not (just) a hardware problem with the ST15150N.


Additional info:

I've included everything I know above.
Comment 1 Bugzilla owner 2004-09-30 11:39:05 EDT
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
persists.

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/

Note You need to log in before you can comment on or make changes to this bug.