Skip to contentSkip to conversation

USB-storage/SCSI panic/error writing CF card

DISCUSSION Murray J. Root 2 participants 2 messages Jan 9, 2003 SCSI

lore
Share & tools
lore

Murray J. Root

author
#0 lore raw

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

Signature · 8 lines
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
#1 lore raw
Quoted 6 lines · Murray J. Root

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:

Quoted 7 lines
  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