From: Chiaki <ishikawa@yk.rim.or.jp>
To: Christoph Hellwig <hch@infradead.org>, Bob Doyle <doyle@primenet.com>
Cc: linux-scsi@vger.kernel.org
Subject: Re: BusLogic cleanup
Date: Thu, 08 Jan 2004 02:02:47 +0900 [thread overview]
Message-ID: <3FFC3BB7.7010308@yk.rim.or.jp> (raw)
In-Reply-To: <20040107153149.A29756@infradead.org>
>>So - now the questions...
>>
>>How do I test the eh_* handler functions? I've tried everything
>>I can think of to provoke them but haven't managed to. For now,
>>I don't know if they work or not.
>
>
> The best testcase would be a faulty disk. You could also try to get
> into EH szenarios by wrong termination / cabling - but who wants to do
> that to his system?
>
I have kept a faulty disk from a raid array of about 5 years ago
specifically for provoking SCSI driver, mid-layer errors ! :-)
AND I have buslogic PCI card, which ran fine under 2.2.xx, and 2.4.yy.
Should I take up the challenge?
The only problem is that I haven't used that faulty disk for the last two
to three years, so I am not sure if it still works.
The symptom was that it would fault after about one hour or two.
The problem looks to be a media problem and the driver firmware seems
to try hard to recover from the error by remapping, etc. and it takes
almost forever,
usually 10-20 sec. This was too lengthy for the linux scsi driver /
mid-layer
a few years ago.
If the disk is not usable by now, I have a working Nakamichi SCSI
CD changer (7 CD unit) which caused hiccups for some SCSI drivers
when I tried to access two CDs simultaneously in the changer
under linux.
Since the changer needs to shuffle the CDs to access them,
trying to access them simultaneously causes a lot of
mechanical shuffling and long deadtime in between, and again
this dead time of a few seconds (varying) was
too lengthy for linux SCSI subsystem a few years ago.
I am very curious if these are now handled adequately
by linux 2.6.0 now. (I still have a feeling that they may not.)
They were handled adequately by Solaris 7 and
Windows98SE.
Can the new buslogic driver work as module under 2.6.0?
This makes testing much easier than built-in driver.
Also, does the problem with the driver kill only the driver
and the device attached to it, or does the entire system
gets hung? Again, localizing damage is very important for
practical considerations.
--
int main(void){int j=2003;/*(c)2003 cishikawa. */
char t[] ="<CI> @abcdefghijklmnopqrstuvwxyz.,\n\"";
char *i ="g>qtCIuqivb,gCwe\np@.ietCIuqi\"tqkvv is>dnamz";
while(*i)((j+=strchr(t,*i++)-(int)t),(j%=sizeof t-1),
(putchar(t[j])));return 0;}/* under GPL */
next prev parent reply other threads:[~2004-01-07 17:03 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-02 6:47 BusLogic cleanup Bob Doyle
2004-01-07 15:31 ` Christoph Hellwig
2004-01-07 17:02 ` Chiaki [this message]
2004-01-08 5:12 ` Bob Doyle
2004-01-08 15:26 ` Maciej W. Rozycki
-- strict thread matches above, loose matches on Subject: below --
2004-01-08 14:58 Cress, Andrew R
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3FFC3BB7.7010308@yk.rim.or.jp \
--to=ishikawa@yk.rim.or.jp \
--cc=doyle@primenet.com \
--cc=hch@infradead.org \
--cc=linux-scsi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox