[4498] in linux-scsi channel archive
Re: 2.0 scsi BLIST_SINGLELUN and MBR-7 (fwd)
daemon@ATHENA.MIT.EDU (Derrick J Brashear)
Mon Aug 3 22:30:44 1998
Date: Mon, 3 Aug 1998 22:26:21 -0400 (EDT)
From: Derrick J Brashear <shadow@DEMENTIA.ORG>
To: linux-scsi@vger.rutgers.edu
No one on linux-kernel was able to shed light on this; perhaps someone
here can?
I have an (repackaged) Nakamichi MBR-7 attached to my Sparc 4 running
2.0.35. The device is correctly BLIST_SINGLELUN'd in scsi.c, but this
doesn't seem to work correctly. Sometimes, simulatenous access attempts
will hang the machine after about 40 seconds, but this is not reliably
reproducible.
However, there's also a second problem.
in one window:
cat cd6/doors/albums/doors/11.mp3 > /dev/null
in the other:
cat cd5/police/albums/every_breath_you_take_the_classics/14.mp3 > /dev/null
both lose:
cat: cd5/police/albums/every_breath_you_take_the_classics/14.mp3: I/O
error
cat: cd6/doors/albums/doors/11.mp3: I/O error
which isn't a crash, but isn't what others reported, which is the cats
taking turns.
both discs become inaccessible from then on until unmounted and remounted.
i augmented scsi.c to notify me when we get to the return NULL case in the
single_lun stanza in request_queueable; it wasn't called, presumably
because that block of code leaves SCpnt a null pointer and the return
after the block of code catches it.
i tried catting a file to /dev/null and simultaneously ls -lR'ing another
disc, and that had the behavior others observed, i.e. things taking turns.
Any hints to tracking my problem people can offer would be appreciated,
since apparently this code works at least for some people.
-D
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu