Marc -- In re: why behavior is different at boot-up vs hotplug -- have you considered the possibility that your BIOS sends a READ_CAPACITY command to the drive during POST? If you BIOS is enabled for boot-from-USB (and most are), then it likely probes the device to compile a list of boot targets, before later trying each target in turn.
Heck, depending on how your BIOS is configured, it might access each bootable device to determine if it's a "legacy boot" or "UEFI boot" (or both!) configured device. That access, or series of accesses, might trigger some sort of "compatibility" behavior in the drive; I'm guessing a lot of BIOSes don't support 4k sectors yet, so a feature like that might actually be useful to some people. You might try to see if you can disable USB boot in your BIOS, and see if that makes any difference to the behavior of the drive at all. Matt On Mon, Mar 23, 2015 at 11:52 AM, Marc Joliet <mar...@gmx.de> wrote: > Am Mon, 23 Mar 2015 13:29:02 -0400 (EDT) > schrieb Alan Stern <st...@rowland.harvard.edu>: > >> On Mon, 23 Mar 2015, Marc Joliet wrote: >> >> > Am Mon, 23 Mar 2015 11:34:59 +0100 >> > schrieb Marc Joliet <mar...@gmx.de>: >> > >> > [...] >> > > > - Same as above, but this time I load the uas module before plugging >> > > > in the >> > > > drive (I could have used usb-storage, but didn't out of mental >> > > > habit). This >> > > > time the sector size is detected correctly. There are almost 16000 >> > > > lines of >> > > > usbmon output from this, which is... a lot to look through for stuff >> > > > to trim. >> > > > >> > > > So in summary, I'm confused. Why would the drive work correctly when >> > > > I plug it >> > > > in after the fact, but not when it is plugged in before the system >> > > > boots? >> > >> > OK, here's the first ~250 lines of usbmon output from this. The relevant >> > bits >> > from the system log from when this file was generated: >> > >> > Mär 23 00:53:28 marcec kernel: usbcore: registered new interface driver >> > usb-storage >> > Mär 23 00:53:28 marcec kernel: usbcore: registered new interface driver uas >> > Mär 23 00:53:59 marcec kernel: usb 4-2: new SuperSpeed USB device number 2 >> > using xhci_hcd >> > Mär 23 00:53:59 marcec kernel: usb-storage 4-2:1.0: USB Mass Storage >> > device detected >> > Mär 23 00:53:59 marcec kernel: scsi host8: usb-storage 4-2:1.0 >> > Mär 23 00:54:09 marcec kernel: scsi 8:0:0:0: Direct-Access Toshiba >> > External USB 3.0 0201 PQ: 0 ANSI: 6 >> > Mär 23 00:54:09 marcec kernel: sd 8:0:0:0: Attached scsi generic sg6 type 0 >> > Mär 23 00:54:09 marcec kernel: sd 8:0:0:0: [sdf] Very big device. Trying >> > to use READ CAPACITY(16). >> > Mär 23 00:54:09 marcec kernel: sd 8:0:0:0: [sdf] 732566645 4096-byte >> > logical blocks: (3.00 TB/2.72 TiB) >> > Mär 23 00:54:09 marcec kernel: sd 8:0:0:0: [sdf] Write Protect is off >> > Mär 23 00:54:09 marcec kernel: sd 8:0:0:0: [sdf] Mode Sense: 2b 00 00 00 >> > Mär 23 00:54:09 marcec kernel: sd 8:0:0:0: [sdf] Write cache: disabled, >> > read cache: enabled, doesn't support DPO or FUA >> > Mär 23 00:54:09 marcec kernel: sd 8:0:0:0: [sdf] 732566645 4096-byte >> > logical blocks: (3.00 TB/2.72 TiB) >> > Mär 23 00:54:09 marcec kernel: sdf: sdf1 sdf2 >> > Mär 23 00:54:09 marcec kernel: sd 8:0:0:0: [sdf] 732566645 4096-byte >> > logical blocks: (3.00 TB/2.72 TiB) >> > Mär 23 00:54:09 marcec kernel: sd 8:0:0:0: [sdf] Attached SCSI disk >> > Mär 23 00:54:11 marcec kernel: BTRFS: device label MARCEC_BACKUP devid 1 >> > transid 66044 /dev/sdf2 >> > Mär 23 00:54:12 marcec kernel: EXT4-fs (sdf1): mounted filesystem with >> > ordered data mode. Opts: (null) >> > Mär 23 00:54:12 marcec udisksd[752]: Mounted /dev/sdf1 (system) at >> > /media/TOSHIBA EXT on behalf of uid 1000 >> > Mär 23 00:54:12 marcec kernel: BTRFS info (device sdf2): disk space >> > caching is enabled >> > Mär 23 00:54:12 marcec kernel: BTRFS: has skinny extents >> > Mär 23 00:54:18 marcec udisksd[752]: Mounted /dev/sdf2 (system) at >> > /media/MARCEC_BACKUP on behalf of uid 1000 >> > >> > So, you know, everything behaving as expected, apparently. >> >> Yes, the usbmon trace confirms this. It's kind of odd, though. First >> the computer sends a READ CAPACITY(10), and the drive responds by >> saying that it has more than 4 billion 512-byte blocks. Then the >> computer sends READ CAPACITY(16), and the drive responds by saying that >> it has 732566645 (less than 4 billion!) 4096-byte blocks. There's no >> way to know why it changes its mind about the block size. >> >> When the computer sends another READ CAPACITY(10) command later on, the >> drive says the block size is 4096. It really does send different >> responses to the same command at different times. > > OK, so obviously the drive is doing something wrong. I'm just confused about > why one way works and not the other: > > - Boot up the computer with the drive attached: failure. > > - Boot up the computer without the drive attached, load the required kernel > modules, and plug it in: success. > > I would think that, if it's solely the drive's fault, neither case would work, > since in both cases I'm plugging the drive in for the first time and it has > not spun up yet, and in both cases the uas and usb-storage modules are loaded > beforehand (albeit with a larger delay in the second case). That is: what is > the difference from the drive's perspective? > > (Also, why does Windows, without any manually installed drivers, work, then?) > > This, and all the other situations I described where the drive worked fine > (such as turning the drive off for several hours), make me wonder whether you > or anybody else on this list know of any drives/usb adapters that behave in > strange ways when they are connected at boot up like this (for example, I read > of older drives that would initially announce themselves as CD-ROM drives). > > Of course, if the diagnosis is definitely "the drive did it", then I'm willing > to resign myself to the notion that nothing can be done about it, however > disappointing that would be. > > -- > Marc Joliet > -- > "People who think they know everything really annoy those of us who know we > don't" - Bjarne Stroustrup -- Matthew Dharm Maintainer, USB Mass Storage driver for Linux -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
