Formatting External USB Drives
in [General Linux]
|
Prev: NYC LOCAL: Wednesday 7 April 2010 NYCBUG: Marco Figueroa on Nepenthes Against Script Kiddies
Next: How deep an I buried?
From: David W. Hodgins on 9 Apr 2010 13:41 On Fri, 09 Apr 2010 12:28:57 -0400, Kevin the Drummer <nobody(a)cosgroves.us> wrote: > Apr 8 23:21:22 : sd 9:0:0:0: SCSI error: return code = 0x8000002 > Apr 8 23:21:22 : sdf: Current: sense key: Aborted Command > Apr 8 23:21:22 : Additional sense: > Apr 8 23:21:22 : Logical unit communication CRC error (Ultra-DMA/32) > Apr 8 23:21:22 : end_request: I/O error, dev sdf, sector 96238085 > Apr 8 23:21:22 : Buffer I/O error on device sdf8, logical block 2168 Try booting with the kernel option "all_generic_ide=1", then running the mkfs commands again. Regards, Dave Hodgins -- Change nomail.afraid.org to ody.ca to reply by email. (nomail.afraid.org has been set up specifically for use in usenet. Feel free to use it yourself.)
From: David W. Hodgins on 9 Apr 2010 22:31 On Fri, 09 Apr 2010 13:41:45 -0400, David W. Hodgins <dwhodgins(a)nomail.afraid.org> wrote: > On Fri, 09 Apr 2010 12:28:57 -0400, Kevin the Drummer <nobody(a)cosgroves.us> wrote: > >> Apr 8 23:21:22 : sd 9:0:0:0: SCSI error: return code = 0x8000002 >> Apr 8 23:21:22 : sdf: Current: sense key: Aborted Command >> Apr 8 23:21:22 : Additional sense: >> Apr 8 23:21:22 : Logical unit communication CRC error (Ultra-DMA/32) >> Apr 8 23:21:22 : end_request: I/O error, dev sdf, sector 96238085 >> Apr 8 23:21:22 : Buffer I/O error on device sdf8, logical block 2168 > > Try booting with the kernel option "all_generic_ide=1", then running > the mkfs commands again. Another option to try, is addin a line to /etc/modprobe.conf with options libata force=2:udma33 and then rebooting. Both of these are attempts to try to get the kernel to use a slower dma mode. Either way, a bug report should probably be raised at https://qa.mandriva.com/index.cgi Regards, Dave Hodgins -- Change nomail.afraid.org to ody.ca to reply by email. (nomail.afraid.org has been set up specifically for use in usenet. Feel free to use it yourself.)
From: Grant Edwards on 9 Apr 2010 22:50 On 2010-04-10, David W. Hodgins <dwhodgins(a)nomail.afraid.org> wrote: > On Fri, 09 Apr 2010 13:41:45 -0400, David W. Hodgins <dwhodgins(a)nomail.afraid.org> wrote: > >> On Fri, 09 Apr 2010 12:28:57 -0400, Kevin the Drummer <nobody(a)cosgroves.us> wrote: >> >>> Apr 8 23:21:22 : sd 9:0:0:0: SCSI error: return code = 0x8000002 >>> Apr 8 23:21:22 : sdf: Current: sense key: Aborted Command >>> Apr 8 23:21:22 : Additional sense: >>> Apr 8 23:21:22 : Logical unit communication CRC error (Ultra-DMA/32) >>> Apr 8 23:21:22 : end_request: I/O error, dev sdf, sector 96238085 >>> Apr 8 23:21:22 : Buffer I/O error on device sdf8, logical block 2168 >> >> Try booting with the kernel option "all_generic_ide=1", then running >> the mkfs commands again. > > Another option to try, is addin a line to /etc/modprobe.conf with > options libata force=2:udma33 and then rebooting. > > Both of these are attempts to try to get the kernel to use a slower > dma mode. Can somebody explain why IDE DMA timing would affect a USB attached drive? -- Grant
From: David W. Hodgins on 10 Apr 2010 01:38 On Fri, 09 Apr 2010 22:50:04 -0400, Grant Edwards <invalid(a)invalid.invalid> wrote: > Can somebody explain why IDE DMA timing would affect a USB attached > drive? As I understand it, even though the usb-storage module is being used to provide the raw access, the ide modules are used to actually do the data transfer. I may be wrong in this, which is why I'd like to know if either of the workarounds I suggested actually work. Both of those workarounds were from when the ata module(s) were detecting 80 wire ide cables when 40 wire ide cables were actually installed. In that case, the kernel module selected udma transfer rates, that the cables could not handle. This may have no impact in this case, but I can't think of any other reason why the use of usb to access the drive would fail, while the same drive works fine when internally connected, other then a problem with the enclosure. Note that usb uses dma access too. Regards, Dave Hodgins -- Change nomail.afraid.org to ody.ca to reply by email. (nomail.afraid.org has been set up specifically for use in usenet. Feel free to use it yourself.)
From: Robert Heller on 10 Apr 2010 07:01
At Sat, 10 Apr 2010 01:38:17 -0400 "David W. Hodgins" <dwhodgins(a)nomail.afraid.org> wrote: > > On Fri, 09 Apr 2010 22:50:04 -0400, Grant Edwards <invalid(a)invalid.invalid> wrote: > > > Can somebody explain why IDE DMA timing would affect a USB attached > > drive? > > As I understand it, even though the usb-storage module is being used > to provide the raw access, the ide modules are used to actually do > the data transfer. I may be wrong in this, which is why I'd like > to know if either of the workarounds I suggested actually work. > > Both of those workarounds were from when the ata module(s) were > detecting 80 wire ide cables when 40 wire ide cables were actually > installed. In that case, the kernel module selected udma transfer > rates, that the cables could not handle. > > This may have no impact in this case, but I can't think of any other > reason why the use of usb to access the drive would fail, while the > same drive works fine when internally connected, other then a problem > with the enclosure. Random thought: could it be that although the enclosure *claims* to be USB 2.0, it is really USB 1.0? Or some such nonsense. If it really is a timing / throughput issue, this might make sense. > > Note that usb uses dma access too. > > Regards, Dave Hodgins > -- Robert Heller -- Get the Deepwoods Software FireFox Toolbar! Deepwoods Software -- Linux Installation and Administration http://www.deepsoft.com/ -- Web Hosting, with CGI and Database heller(a)deepsoft.com -- Contract Programming: C/C++, Tcl/Tk |