On Mon, 24 Jan 2000, Jens Axboe wrote: > On Mon, Jan 24 2000, Alan Cox wrote: > > > Jan 24 14:13:08 zeus kernel: Wrong buffer length supplied for request sense (256) > > > > These are a bad sign though - something is going astray > > Not necessarily. The 2.3 version has this #if 0 out for good > reason, since there should be no reason to expect the sense_buffer > to have the exact size. It looks like old debugging code. Anyway, I had a similar problem once with a Fujitsu MOD drive. Regardless if linux detects the device as removeable or not, SCSI specifies a mechanism of going into a Unit Attention state resp. the device needs to return a Check Condition Error after the media was changed. Linux relies on this to detect the media change. If it can, it will also lock the drive door to prevent media change of mounted devices. What you describe looks exactly as if the kernel does not notice media changes. (Normally any detected media change is also logged (if your logging level is high enough)). If it doesn't, the device sector buffers are not flushed (even if you unmount/mount it). There is an ioctl (more intended to reread a partition table) which you can use to flush the buffers with a tiny selfwritten tool (I forgot the name of the ioctl). But you must never forgot to use it before removing an unmounted fs. This is very risky as linux will happily partially dirty the still in memory buffers of the old disk and write them to the new one, thus corrupting new disks. I tried it for a short period and crashed almost all of my MO disks with it. Other OS's don't buffer removable devices and just check some serial-# in the boot sect to detect disk changes. Linux relies on the SCSI standard mechanism. For me, it turned out the MOD-device was jumpered 'Mac'-compatible which meant (among other violations of the SCSI-specs) it did not return the media change condition. Maybe, there is a similar jumper set on your device. If not, that is, if your device simply does not comply to the SCSI standard with regards to media change detection, you are doomed to use the buffer clean tool. Theoretically, it might well be possible that the 154x driver filters some of the error codes and is the real culprit. But afaik it is one of the oldest, well-test and kind of 'example driver' for the scsi system, so I doubt the reason is in there. Michael. -- Michael Weller: [EMAIL PROTECTED], [EMAIL PROTECTED], or even [EMAIL PROTECTED] If you encounter an eowmob account on any machine in the net, it's very likely it's me. - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED]
