lkml.org 
[lkml]   [1999]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: SCSI Timeout, but no bus reset
X-PMC-CI-e-mail-id: 11114 

Hi,

I would like to report that the problems noted by
myself are solved by the installation of
the latest 2.2.11 kernel.
(A couple of similar, but not exact problems
had been reported earlier.)

It seems that the fixes 2.2.11 of the fs/ext2 code for tigher checking
of bogus inode values, and other corrections in various
parts of the kernel solved the problem of
handling of faulty hard disk (MEDIUM ERROR, etc.)
in SCSI higher level code.

Obviously the change of timeout from 15sec to 30sec (which
is in the kernel change for 2.2.11) was the major stabilization factor.

Thank you for the kernel hackers for these corrections.

(I don't know if the SCSI tape errors are handled
well or not by the latest kernel. Those who have experienced the
tape medium errors or rather the problems of recovering
from such errors with SCSI tape drives might want to check
the latest kernel and report their experience.)

TIA.

Happy Hacking


Chiaki Ishikawa wrote:


> X-PMC-CI-e-mail-id: 11009
>
> Hi,
>
> I have been trying to debug a similar bus reset problem
> when a disk becomes faulty : I am using 2.2.10-ac1x patch and
> AMD SCSI chip host adaptor with TMSCSIM driver (thanks to Kurt
> Garloff).
>
> [ Background: "When a disk becomes faulty" means when the system
> encouters a medium error, etc..
>

...

>
> Now, after seeing the two reports, I would like to report
> that I see similar symptoms on my home PC linux system.
>
> When a faulty medium error is encountered at a certain timing on my
> LINUX PC, the reported "reset forever" state is entered and the system
> becomes unusable. The log line is essentially the same.
>
> Given the varied hardware used by people reporting problems,
> I suspect a not so robust handling of errors in higher level SCSI
> subsystem code.
>
> Some comparisons: In my case, I use an old (5 year old) Seagate disk
> for investigating this problem.
>
> Maybe a worthwhile note:
> After seeing the mention of a large RAID array system's reset problem
> about a couple of weeks ago and the suggested fix for increasing the
> timeout value from 15*HZ to 30*HZ in sd.c suggested by the
> raid software developers posted afterward, I followed suit.
>
> Before this change, I used to see the "RESET forerver" state most of
> the time when the system became unusable.
>
> But after the change, I see the exactly the same sympom of Tim's:
> "Tim> but I can't rmmod the
> Tim> module and any processes that try using it go into
> Tim> uninterruptable sleep."
>
> In my case, I am running Bonnie (disk performance benchmark program)
> against the disk until the Medium error(s) appear.
>
> After the "15*HZ->30*HZ" change, Bonnie died without much useful
> message, and disapper from "top" output. But it is shown in the "ps"
> output as "D" (dead?). I can't kill it using kill (actually kill will
> hung). I can't unmount the disk: umount will get hung. Anything that
> will touch the disk will get hung. I tried "RESET" special command
> available with TMSCSIM driver (echo "RESET" > /proc/scsi/tmscsim/?")
> then the system locked solid.
>
> Before this change of "15*HZ->30*HZ", the sytem randomly locked
> sometimes, but most likely to enter the "RESET forrever" state.
> So this was where I tried to investigate without much luck so far.
>
> In any case, the symptoms are so similar, I think there is a common
> cause of the problems we see here. And naturally, I suspect the
> higher level SCSI code.
>
>

...

>
> >>>>> "Tim" == Tim Ricketts <tr@oxlug.org> writes:
>
> Tim> On Tue, 22 Jun 1999, David B. Rees wrote:
>
> >> Under heavy SCSI disk load, my 2.2.10 SMB (dual P133) box is showing this
> >> error, but it never recovers. I haven't tried other kernels. I am using the
> >> standard NCR53C8XX driver, not the SYM53C8XX driver, with the default settings.
>
> Tim> Mine's with 2.2.{9,10} and proposed-2.2.11pre[234] with aic7xxx (it's
> Tim> happened 8 times now).
>
> >> scsi : aborting command due to timeout : pid 269291, scsi0, channel 0, id 0,
> >> lun 0 Read (10) 00 00 2d f9 08 00 00 02 00
>
> Tim> Much the same as mine, but the command isn't always the same. More
> Tim> details including 130k of logs available.
>
> >> I would expect the driver to reset the SCSI card and recover, but it never
>
> Tim> Me too.
>
> >> does, and the only thing left to do is to SysRq Boot.
>
> Tim> As mine's only a CD writer I can reboot cleanly, but I can't rmmod the
> Tim> module and any processes that try using it go into uninterruptable sleep.
>
> >> Here is the relevant section of dmesg, let me know if you need more
> >> information. I can get this to happen by simply doing a large copy (couple
> >> hundred megabytes) between the two disks.
>
> Tim> I can't get mine to happen, it just does occasionally. I'm running a
> Tim> kernel with DEBUG_TIMEOUT defined in scsi_obsolete.c at the moment, but
> Tim> nothing's gone wrong yet.



--
Ishikawa, Chiaki ishikawa@personal-media.co.jp.NoSpam or
(family name, given name) Chiaki.Ishikawa@personal-media.co.jp.NoSpam
Personal Media Corp. ** Remove .NoSpam at the end before use **
Shinagawa, Tokyo, Japan 142-0051



-
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/

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.175 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site