lkml.org 
[lkml]   [2009]   [May]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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@redhat.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


\
 
 \ /
  Last update: 2009-05-25 22:57    [W:0.257 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site