On Mon, 31 May 2004, Tomasz Motylewski wrote: > Hello, > > I have tried to exercise the disk in a more complicated way - started to > overwrite with random data /dev/sda at the offset of more than 110 GB and at > the same time tried to create partition and ext3 filesystem on /dev/sda2 > (start to +60 GB) > > The disk has stopped in well known way after about 20 s. mke2fs reported > "Attempt to read block from filesystem resulted in short read while creating > root dir" after "Writing inode tables: done". Trying to open /dev/sda results > now in ENXIO. But the other dd is still happily writing GBs of data to /dev/sda > - this was what my critique in the previous mail was about. Before putting data > into the buffer it would be good to check whether the device exists at all.
It's the job of the block layer to propagate device errors upwards from the device driver (SCSI) level to the filesystem/user level. Try complaining to the people who maintain the block layer code. > Well, it looks that the whole story is about unspecified delay in unspecified > place. > > Unplugging/plugging USB 2 times recovers the disk, but then mke2fs alone ( > -b 1024 on 60 G partition) hangs it again. (LED stuck ON). Writing inode tables > initially stops, then after 30-60s continues OK on offline device, first error > is on read(). > > May be next weekend I will be trying adding some delays here and there. > > Best regards, > -- > Tomasz Motylewski > > Is that true even if you haven't done anything else previously, i.e., no > > bandwidth-saturating writes (or no writes at all)? If it is, post a > > usb-storage debugging log showing the time delay. > > Yes, without any data in the buffer. Will try next weekend. Is there any > proc/sys interface to enable debugging after I compile it in? Unforunately no. It's either always on or always off. Anyway, you probably wouldn't be able to turn it on at the right time -- immediately _before_ the errors start occurring. > > That may be an artifact of the way I/O is handled. Probably dd's write > > calls to the system returned success and the data was buffered, and the > > errors didn't start until the buffers were flushed to the device. But I > > don't know the details. > > Even after the buffers are flushed and rejected by SCSI layer, new write() > repports succeess. A block layer or filesystem problem. Or possibly a problem in the communication between the block layer and the SCSI layer. > > Well, that's a different story. It could be that problems with > > usb-storage have blocked the USB hub driver. If the hub driver is waiting > > for usb-storage to finish disconnecting the disk drive then it can't > > respond to additional devices being plugged in. > > How long this waiting may take? Until usb-storage can proceed. If it's blocked because it's trying to perform a USB port reset on the device that might mean indefinitely; the port reset code is still buggy. > > If you turn on USB debugging in the kernel configuration then you'll be > > able to see what happens when connecting a new device fails. > > May I beg for "debugging USB for dummies" URL? I don't have one. But turning on USB debugging is no big deal; if you do "make menuconfig" then it's under "device drivers"/"USB support", the second item on the menu. If you mean that you want to learn what the messages signify and how to interpret them... That's no job for a dummy! You have to understand a large portion of the USB Specification and a fair amount of kernel code. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
