[991] in linux-scsi channel archive
Re: Buslogic 445S and iomega jaz drive
daemon@ATHENA.MIT.EDU (Leonard N. Zubkoff)
Fri Nov 22 02:47:00 1996
Date: Thu, 21 Nov 1996 23:44:29 -0800
From: "Leonard N. Zubkoff" <lnz@dandelion.com>
To: dodson@redwood.mza.com
CC: linux-scsi@vger.rutgers.edu
In-reply-to: <199611220640.XAA05640@redwood.mza.com> (message from Zane Dodson
on Thu, 21 Nov 1996 23:40:09 -0700 (MST))
From: Zane Dodson <dodson@redwood.mza.com>
Date: Thu, 21 Nov 1996 23:40:09 -0700 (MST)
I am wondering if anyone has had success using a Buslogic 445S
SCSI host adapter with the iomega jaz drive.
I suggest you also direct your question to BusLogic Technical Support
(techsup@buslogic.com). They may well have reports of success or failure with
this combination.
I am getting bus resets and a variety of interesting messages
when I run a find over the entire 1GB disk. I am using the Buslogic
driver by Leonard Zubkoff. Here is an excerpt from the syslog
about the host adapter.
Here is what often happens when using the jaz drive. It appears
that after Tagged Queueing is disabled, I don't have any more problems with
the drive, though this could be simply coincidental.
Sounds like the Jaz may have a buggy implementation of tagged queuing. You can
disable tagged queuing entirely by booting with the command line
"BusLogic=TQ:Disable", or just for target 4 with "BusLogic=TQ:YYYYN".
Unable to handle kernel NULL pointer dereference at virtual address c0000004
current->tss.cr3 = 00d4f000, %cr3 = 00d4f000
*pde = 00102067
*pte = 00000027
Oops: 0000
CPU: 0
EIP: 0010:[<001bbf91>]
EFLAGS: 00010246
eax: 00000000 ebx: 00093118 ecx: 00dbde6c edx: 00000000
esi: 00000806 edi: 00000046 ebp: 00000001 esp: 00dbdec8
ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018
Process syslogd (pid: 50, process nr: 11, stackpage=00dbd000)
Stack: 00000000 002128d4 00000806 00212814 00220fb4 0017ea97 00000008 000052ec
00000001 00000002 0017eeef 00220fb4 00212814 00000000 00dbdf60 00000001
00000400 00212844 00000806 0000002a 00000000 00008706 0017f039 00000008
Call Trace: [<0017ea97>] [<0017eeef>] [<0017f039>] [<001596ce>] [<00159822>] [<001599ff>] [<00124aa4>]
[<0010a5e2>]
Code: 8a 40 04 c1 e8 04 83 e0 0f 8b 15 3c e2 1f 00 8d 04 80 8b 44
The above does not look good. Can you run ksymoops over this to give us a
backtrace? It's impossible to determine from the above if the OOPS is related,
or where it occurred.
A more recent kernel would also be a good idea.
Leonard
