| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20090525205353.GB6856@redhat.com> Date: Mon, 25 May 2009 23:53:53 +0300 From: "Michael S. Tsirkin" <mst@...hat.com> To: Alan Stern <stern@...land.harvard.edu> Cc: Kay Sievers <kay.sievers@...y.org>, OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>, Kernel development list <linux-kernel@...r.kernel.org>, USB list <linux-usb@...r.kernel.org> Subject: Re: 2.a.30-rc7: fat filesystem misdetected as amiga On Mon, May 25, 2009 at 04:37:59PM -0400, Alan Stern wrote: > On Mon, 25 May 2009, Michael S. Tsirkin wrote: > > > On Mon, May 25, 2009 at 11:32:31AM -0400, Alan Stern wrote: > > > On Mon, 25 May 2009, OGAWA Hirofumi wrote: > > > > > > > "Michael S. Tsirkin" <mst@...hat.com> writes: > > > > > > > > > An attempt to mount it under linux 2.6.30-rc7 results in these messages: > > > > > > > > > > usb 1-3: new high speed USB device using ehci_hcd and address 7 > > > > > usb 1-3: New USB device found, idVendor=090c, idProduct=6000 > > > > > usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 > > > > > usb 1-3: Product: USB2.0 Card Reader > > > > > usb 1-3: Manufacturer: Generic , . > > > > > usb 1-3: SerialNumber: 0000001 > > > > > usb 1-3: configuration #1 chosen from 1 choice > > > > > Initializing USB Mass Storage driver... > > > > > scsi2 : SCSI emulation for USB Mass Storage devices > > > > > usbcore: registered new interface driver usb-storage > > > > > USB Mass Storage support registered. > > > > > usb-storage: device found at 7 > > > > > usb-storage: waiting for device to settle before scanning > > > > > usb-storage: device scan complete > > > > > scsi 2:0:0:0: Direct-Access Generic 6000 PQ: 0 ANSI: 0 CCS > > > > > sd 2:0:0:0: Attached scsi generic sg2 type 0 > > > > > sd 2:0:0:0: [sdb] 990976 512-byte hardware sectors: (507 MB/483 MiB) > > > > > sd 2:0:0:0: [sdb] Write Protect is off > > > > > sd 2:0:0:0: [sdb] Mode Sense: 4b 00 00 08 > > > > > sd 2:0:0:0: [sdb] Assuming drive cache: write through > > > > > sd 2:0:0:0: [sdb] Assuming drive cache: write through > > > > > sdb:<6>sd 2:0:0:0: [sdb] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE > > > > > sd 2:0:0:0: [sdb] Sense Key : Illegal Request [current] > > > > > sd 2:0:0:0: [sdb] Add. Sense: Logical block address out of range > > > > > end_request: I/O error, dev sdb, sector 0 > > > > > Buffer I/O error on device sdb, logical block 0 > > > > > Dev sdb: unable to read RDB block 0 > > > > > unable to read partition table > > > > > sd 2:0:0:0: [sdb] Attached SCSI removable disk > > > > > usb 1-3: USB disconnect, address 7 > > > > > > > > > > parted seems to display both partitions just fine, > > > > > and that other OS does not seem to have any trouble > > > > > accessing the disk. > > > > > > > > > > The message 'unable to read RDB block' seems to come from > > > > > fs/partitions/amiga.c which looks pretty weird. > > > > > > > > > > Any idea what info would be helpful in debugging this? > > > > > Just to clarify, this is not a regression - older linux versions > > > > > as far back as 2.6.24 seem to behave the same way. > > > > > > > > It seems I/O error happened while checking the partition types (sector 0). > > > > I guess usb people may have knowledge of this. CC to linux-usb. > > > > > > It's hard to imagine why a device would claim that sector 0 was out of > > > range! > > > > > > Try collecting a usbmon trace of these events (instructions in > > > Documentation/usb/usbmon.txt). > > > > > > Alan Stern > > > > Here comes: > > > > lsusb output: > > Bus 001 Device 006: ID 090c:6000 Feiya Technology Corp. > > Bus 001 Device 001: ID 1d6b:0002 > > Bus 005 Device 003: ID 10d5:55a4 Uni Class Technology Co., Ltd > > Bus 005 Device 002: ID 058f:9254 Alcor Micro Corp. Hub > > Bus 005 Device 001: ID 1d6b:0001 > > Bus 004 Device 001: ID 1d6b:0001 > > Bus 003 Device 001: ID 1d6b:0001 > > Bus 002 Device 001: ID 1d6b:0001 > > > > First device (Feiya Technology Corp) is the disk on key. > > > > Usbmon output from cat /sys/kernel/debug/usbmon/1u > > (... Uninteresting parts removed ...) > > Here is the command preceding the one that failed. It is a MODE > SENSE(6) command for 192 bytes; the device replies with 76 bytes and > then fails to set the residue appropriately -- not a good sign but > plenty of other devices have the same bug. > > > ef48ab00 3229280711 S Bo:1:006:2 -115 31 = 55534243 0c000000 c0000000 8000061a 003f00c0 00000000 00000000 000000 > > ef48ab00 3229280811 C Bo:1:006:2 0 31 > > > ef727880 3229280818 S Bi:1:006:1 -115 192 < > > ef727880 3229281185 C Bi:1:006:1 -121 76 = 4b000008 000f1f00 00000200 010a0010 00000000 03000000 051e3c00 203f0200 > > ef48ab00 3229281195 S Bi:1:006:1 -115 13 < > > ef48ab00 3229281435 C Bi:1:006:1 0 13 = 55534253 0c000000 00000000 00 > > Next comes the very first READ(10) command. It asks for 8 sectors > starting at sector 0: > > > ef48ab00 3229281483 S Bo:1:006:2 -115 31 = 55534243 0d000000 00100000 80000a28 00000000 00000008 00000000 000000 > > ef48ab00 3229281560 C Bo:1:006:2 0 31 > > > ef635d80 3229281567 S Bi:1:006:1 -115 4096 < > > ef635d80 3229410691 C Bi:1:006:1 -32 0 > > ef48ab00 3229410723 S Co:1:006:0 s 02 01 0000 0081 0000 0 > > ef48ab00 3229410815 C Co:1:006:0 0 0 > > ef48ab00 3229410822 S Bi:1:006:1 -115 13 < > > ef48ab00 3229410940 C Bi:1:006:1 0 13 = 55534253 0d000000 00100000 01 > > The command fails. The computer then sends a REQUEST SENSE command to > find out why: > > > ef48ab00 3229410948 S Bo:1:006:2 -115 31 = 55534243 0e000000 12000000 80000603 00000012 00000000 00000000 000000 > > ef48ab00 3229411065 C Bo:1:006:2 0 31 > > > ef6c7f00 3229411071 S Bi:1:006:1 -115 18 < > > ef6c7f00 3229411190 C Bi:1:006:1 0 18 = 70000500 0000000a 00000000 21000000 0000 > > ef48ab00 3229411197 S Bi:1:006:1 -115 13 < > > ef48ab00 3229411315 C Bi:1:006:1 0 13 = 55534253 0e000000 12000000 00 > > The device responds with Sense Key = 5 (Illegal Request) and ASC = > 0x21 (Logical Block Address Out of Range), as mentioned in the log. > Oddly enough, the residue value for this REQUEST SENSE result is set to > 18, so perhaps that means we shouldn't believe any of the sense data! > (More likely it means the residue values are totally bogus...) > > Regardless, this causes the read of the partition table to fail. But > the next command sent by the computer is another READ(10) for 8 sectors > starting at sector 0, and this time it works! > > > ef48ab00 3229411387 S Bo:1:006:2 -115 31 = 55534243 0f000000 00100000 80000a28 00000000 00000008 00000000 000000 > > ef48ab00 3229411439 C Bo:1:006:2 0 31 > > > ef6c7e00 3229411497 S Bi:1:006:1 -115 4096 < > > ef6c7e00 3229412314 C Bi:1:006:1 0 4096 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > > ef48ab00 3229412831 S Bi:1:006:1 -115 13 < > > ef48ab00 3229412939 C Bi:1:006:1 0 13 = 55534253 0f000000 00000000 00 > > So apparently this is a bug in the device; it doesn't respond correctly > to the first READ command. But since it does respond correctly to > later commands, everything works okay thereafter. You ought to be able > to recover from the error by running > > blockdev --rereadpt /dev/sdb > > manually. Yes, this helps. Would it make sense for kernel to retry automatically? Why doesn't it? > As far as I can tell, this has nothing to do with any user programs in > the distribution. It appears to be entirely the device's fault. > > Alan Stern BTW, any idea how come I later get errors apparently from amiga fs? -- MST -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists