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. 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 > No, it's definitely "other reasons". The driver does not see a short CSW > -- it doesn't see any CSW at all. In fact, the transfer is aborted even > before the preceding write completes because the device stops responding. > And even after trying multiple resets, the device still doesn't respond. > 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? > 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. > 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? > 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? Best regards and once again thank you, -- Tomasz Motylewski BFAD GmbH & Co. KG ------------------------------------------------------- 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
