2003-01-09 18:27:41

by Murray J. Root

[permalink] [raw]
Subject: USB-storage/SCSI panic/error writing CF card

kernel 2.5.55
USB support & OHCI-HCD compiled in
scsi support compiled in
scsi disk support as a module
usb-storage as a module
no devfs

ASUS P4S533 (SiS645DX chipset)
P4 2GHz
1G PC2700 RAM
SanDisk SDDR-77 ImageMate Dual Card Reader (using only CF)

Writing to the card sometimes hangs the process when unmounting

Sometimes the data IS written to the card first, then it hangs the process.

Sometimes the card is corrupt (cannot cd to the mountpoint -I/O error)
/var/log/messages has several lines like:
Jan 9 13:08:51 Master kernel: FAT: Filesystem panic (dev sd(8,1))
Jan 9 13:08:51 Master kernel: Directory 4: invalid cluster chain

Sometimes get kernel panic with ONLY these 2 lines:
"Error handler thread not present at f7a57000 f7bf0d80 drivers/scsi/scsi-error.c 154"
"In interrupt handler - not syncing"
No messages in logs

--
Murray J. Root
------------------------------------------------
DISCLAIMER: http://www.goldmark.org/jeff/stupid-disclaimers/
------------------------------------------------
Mandrake on irc.freenode.net:
#mandrake & #mandrake-linux = help for newbies
#mdk-cooker = Mandrake Cooker
#cooker = moderated Mandrake Cooker


2003-01-09 18:46:50

by Patrick Mansfield

[permalink] [raw]
Subject: Re: USB-storage/SCSI panic/error writing CF card

On Thu, Jan 09, 2003 at 01:36:14PM -0500, Murray J. Root wrote:

> Writing to the card sometimes hangs the process when unmounting
>
> Sometimes the data IS written to the card first, then it hangs the process.
>
> Sometimes the card is corrupt (cannot cd to the mountpoint -I/O error)
> /var/log/messages has several lines like:
> Jan 9 13:08:51 Master kernel: FAT: Filesystem panic (dev sd(8,1))
> Jan 9 13:08:51 Master kernel: Directory 4: invalid cluster chain
>
> Sometimes get kernel panic with ONLY these 2 lines:
> "Error handler thread not present at f7a57000 f7bf0d80 drivers/scsi/scsi-error.c 154"
> "In interrupt handler - not syncing"
> No messages in logs

The panic is caused by timeout on a scsi command when the error handler
has unexpectedly gone away, possibly because of this bug, where the erorr
handler exits early because of a SIGHUP:

http://marc.theaimsgroup.com/?l=linux-scsi&m=104145526331820&w=2

Fixing the panic won't fix the corruption. scsi should really offline the
adapter and scsi devices on the adapter rather than panic.

-- Patrick Mansfield