lkml.org 
[lkml]   [1999]   [Aug]   [3]   [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: 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..

I want the Linux SCSI subsystem to be more ROBUST much like that of
SunOS 4 or SunOS 5 SCSI subsytems. As far as I remeber, we replaced
maybe a dozen or so SCSI disks at the office (mostly Sun shops with
other workstations) in the last 10? years, the only times that I recall the
whole system became unusable was the following occasions.:

- once when a Sun disk with "/usr" partition suddenly became
faulty and no /usr/bin/ executables were available anymore,

- once when a Sun disk that contained the "/" partition became
unaccessible, and

- once when a Dec Ultrix workstation (based on MIPS) developed
a bad block related to a file. Whenever I tried to read the
contents of this file, the system crashed. After playing around,
I renamed the file with "mv" command to

/mnt/bad_block_file/dont_remove_this_file

so that I won't touch it by mistake.
Thereafter, the system never crashed.

All other times, when an error was encountered in accessing user data
files on SCSI disks, the system log messages showed the SCSI systems
of the respective OS/workstation recovered more or less gracefully and
we were given ample time to ponder the eventual replacement of SCSI
disk, 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.

I also enabled DEBUG_TIMEOUT of scsi_obsolete.c (and DEBUG: had to
disable certain normal condition printk() statements since it produced
too much output for me), but could not find many useful messages when
the system became unusable. [Oh well, maybe the newer kernel really
don't care much about scsi_obsolete.c use?]

Any tips in solving this welcome.

YES, I can always use fresh disk, but I REALLY want to see
LINUX SCSI subsystem more ROBUST. I can try to test any suggested
patches, etc.. I believe some of the early problems reported
regarding SCSI tape causing system hung-like symptom after
tape medium error was seen *could* be related to similar underlying
cause. But the disk and tape drives seem to be handled very
differently, so I may be wrong.

TIA

Chiaki Ishikawa


>>>>> "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.098 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site