From: Justin T. Gibbs <hidden> Date: 2001-10-12 16:47:46
This card is the Adaptec PCI card that apples shipped (ships?) as part of
it Build-To-Order process. The card is identified as an Adaptec 2930CU
and it has the following numbers (taken from Open Firmware)
1686806-04
Rom # 4.0
rev. 3
We should have one somewhere around the office. I'll go look.
quoted
From the messages file, it appears that the timing out device is
simply not bothering to complete commands it has accepted. We
abort these stuck commands successfully and even try them again,
but the device won't cooperate. This appears to be your Quantum
Fireball - a drive with a very spotty history.
Never a day of trouble with it under Mac or Linux up till the point I used
the new driver. Still works fine under the old aic7xxx driver.
The old driver never issued more than 8 tags. The new driver will attempt
to dynamically determine the capabilities of the drive and can issue as
much as 253 tags. The algorithm used depends on the drive actually adhering
to the SCSI spec and might fail on a buggy drive. If you set the tag depth
to 8 you may see similar behavior to the old driver.
BTW, does the old driver acurately detect that only the external cable
is attached?
quoted
Perhaps the drive
will function correctly if tagged queing is disabled for it. You
can do this only for target 1 with the "tag_info" option. There may
also be firmware updates for this drive.
Can you be more specific about how to use the "tag_info" option. Where is
this option set (in the driver source code?) Or is it passed to the kernel
liek the aic7xxx=verbose option. If the latter, what syntax should I be
using so that I can test that option.
It is like the verbose option. A sample modules.conf line might look
like (assuming you are using a loadable module):
options aic7xxx aic7xxx='"verbose.tag_info:{{253.8.16.92.0.0.0.0}}"'
This sets the tag depth to 253, 8, 16, 92, and "don't do tags" for the
targets 0, 1, 2, 3, and all others on adapter 0, respectively. There is
a comment section in the driver (I may have only updated it in 6.2.2 or 6.2.3)
that discusses all of the driver options in detail. The latest driver
is 6.2.4.
--
Justin
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Kevin B. Hendricks <hidden> Date: 2001-10-12 18:13:58
Hi,
The old driver never issued more than 8 tags. The new driver will
attempt to dynamically determine the capabilities of the drive and can
issue as much as 253 tags. The algorithm used depends on the drive
actually adhering to the SCSI spec and might fail on a buggy drive. If
you set the tag depth to 8 you may see similar behavior to the old
driver.
quoted
quoted
Perhaps the drive
will function correctly if tagged queing is disabled for it. You
can do this only for target 1 with the "tag_info" option. There may
also be firmware updates for this drive.
Okay I used tag_info as you directed and set the Quantum Fireball drive to
use a maximum tag depth of 8 (like the old driver used) and everything
seems to work fine.
So can you point me to where in your driver code the depth of the tagged
queueing is dynamically determined? I would like to play around a bit
with the driver code to see if I can tell if the Quantum Fireball is
simply spitting back bogus info or and if so what?
Thanks,
Kevin
It is like the verbose option. A sample modules.conf line might look
like (assuming you are using a loadable module):
options aic7xxx aic7xxx='"verbose.tag_info:{{253.8.16.92.0.0.0.0}}"'
This sets the tag depth to 253, 8, 16, 92, and "don't do tags" for the
targets 0, 1, 2, 3, and all others on adapter 0, respectively. There is
a comment section in the driver (I may have only updated it in 6.2.2 or
6.2.3) that discusses all of the driver options in detail. The latest
driver is 6.2.4.
From: David A. Gatwood <hidden> Date: 2001-10-12 18:29:01
On Friday, October 12, 2001, at 11:13 AM, Kevin B. Hendricks wrote:
quoted
quoted
quoted
Perhaps the drive
will function correctly if tagged queing is disabled for it. You
can do this only for target 1 with the "tag_info" option. There may
also be firmware updates for this drive.
Okay I used tag_info as you directed and set the Quantum Fireball drive
to
use a maximum tag depth of 8 (like the old driver used) and everything
seems to work fine.
So can you point me to where in your driver code the depth of the tagged
queueing is dynamically determined? I would like to play around a bit
with the driver code to see if I can tell if the Quantum Fireball is
simply spitting back bogus info or and if so what?
IIRC, early Fireball models reported support for TCQ and didn't even
support it. This from discussions on the NetBSD forums a few years
back. I wouldn't be surprised if the drive were reporting wrong
info.... From what I gather, Quantum's high end drives were pretty
decent, but I have a stack of dead Fireballs to prove that their low end
drives weren't.... :-|
Later,
David
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel Lanners <hidden> Date: 2001-10-12 20:06:56
On 12 Oct, this message from David A. Gatwood echoed through cyberspace:
From what I gather, Quantum's high end drives were pretty
decent, but I have a stack of dead Fireballs to prove that their low end
drives weren't.... :-|
I can add one to your stack, a 1.2 Gig originally from my 7600/132. Took
the Debian install on my Performa 475 with it when half of the disk
surface went unreadable.
Michel
-------------------------------------------------------------------------
Michel Lanners | " Read Philosophy. Study Art.
23, Rue Paul Henkes | Ask Questions. Make Mistakes.
L-1710 Luxembourg |
email mlan@cpu.lu |
http://www.cpu.lu/~mlan | Learn Always. "
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: David A. Gatwood <hidden> Date: 2001-10-12 22:02:57
On Friday, October 12, 2001, at 01:06 PM, Michel Lanners wrote:
On 12 Oct, this message from David A. Gatwood echoed through
cyberspace:
quoted
From what I gather, Quantum's high end drives were pretty
decent, but I have a stack of dead Fireballs to prove that their low
end
drives weren't.... :-|
I can add one to your stack, a 1.2 Gig originally from my 7600/132. Took
the Debian install on my Performa 475 with it when half of the disk
surface went unreadable.
Same here, only a 7600/120. Thankfully, in my case, the bad blocks
first appeared in swap space, causing a kernel panic, which set off a
million red flags, so that very night, I backed everything up onto a 9
gig seagate and started using that as the main drive.
I left that Quantum drive in the machine as a backup. A month later, I
tried accessing it, and it returned "DRIVE FAIL". After a reboot a few
weeks later, the drive sounded like a chainsaw. :-)
Later,
David
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/