Re: Partitions not detected with firewire - 36 bytes offset - PL-3507

[Fab S. <fab...@ya...>]

Thanks for your detailed answer

Le mardi 7 juin 2016 15:15:54, vous avez écrit :
> One example would be that userland sends another INQUIRY request.  Which
> would be perfectly standards conforming but is highly dangerous for
> PL-3507.
> 
> The 36 bytes offset which you observed happens to be the same number of
> bytes as the length of a typical INQUIRY response buffer.  Coincidence?
> 
> So,
>   - the SCSI layer and block layer of the Linux kerne could issue commands
>     which the PL-3507's firmware cannot handle, but this can be influenced
>     to some degree by specifying quirk flags to SCSI core.  (I don't
>     remember right now how to do that precisely.)
>   - Or Linux userland could issue commands which crash the firmware.
> 
> To investigate the latter possibility, you could boot into a minimal
> single-user command line and try to use the disk from there.  Consult your
> distribution's documentation on how to get into single-user mode.  If that
> works, then there is some sort of device probing going on in your regular
> userland which upsets the firmware.  E.g. the mentioned double INQUIRY.

For single-user I booted on recovery-mode in debian (having the "single" option on the kernel line). The problem is the same.

However, based on you explanations I tried a few things and noticed this behaviour :

 * If I run "sg_readcap /deb/sdb" then, the offset doesn't exist anymore and when I run cfdisk /dev/sdb the partition table is correctly displayed. However, after closure of cfdisk, the offset is there again and cfdisk doesn't display the partition table anymore.
 * If I run "sg_readcap" followed by "sg_inq", sg_inq makes the offset appear again.
 * If I run "sdparm /dev/sdb", there isn't an offset anymore and cfdisk displays the partition table
 * If I run "sdparm -i /dev/sdb" the offset appears again

So it seems "cfdisk", "sg_inq" and "sdparm -i" send a command that makes the offset appear again, while "sdparm" and "sg_readcap" 'fix' the offset issue.

Output of "sdparm -i /dev/sdb"
    /dev/sdb: SAMSUNG   SP0842N                 [simplified direct access device]
malformed VPD response, VPD pages probably not supported


Output of "sdparm -a /dev/sdb" is attached (and displays also a few warings)


> > * relevant messages from dmesg
> > [66693.391283] firewire_core 0000:02:00.0: phy config: new root=ffc1,
> > gap_count=5 [66697.227221] firewire_core 0000:02:00.0: phy config: new
> > root=ffc1, gap_count=5 [66697.666381] firewire_core 0000:02:00.0: created
> > device fw1: GUID 0000190e0000026e, S400 [66697.844315] scsi host5: SBP-2
> > IEEE-1394
> > [66697.844445] firewire_sbp2 fw1.0: workarounds 0x20 (firmware_revision
> > 0x012804, model_id 0x000001) [66698.044800] firewire_sbp2 fw1.0: logged
> > in to LUN 0000 (0 retries) [66698.045542] scsi 5:0:0:0: Direct-Access-RBC
> > SAMSUNG  SP0842N               PQ: 0 ANSI: 4 [66698.045892] sd 5:0:0:0:
> > Attached scsi generic sg3 type 14
> > [66698.046476] sd 5:0:0:0: [sdc] 156301488 512-byte logical blocks: (80.0
> > GB/74.5 GiB) [66698.046591] sd 5:0:0:0: [sdc] Write Protect is off
> > [66698.046596] sd 5:0:0:0: [sdc] Mode Sense: 11 00 00 00
> > [66698.046868] sd 5:0:0:0: [sdc] Write cache: enabled, read cache:
> > enabled, doesn't support DPO or FUA [66698.055440] sd 5:0:0:0: [sdc]
> > Attached SCSI disk
> 
> Are there no further messages from the SCSI drivers or block layer drivers?

No, there are no further messages

--
Fab