Re: Partitions not detected with firewire - 36 bytes offset - PL-3507
Brought to you by:
aeb,
bencollins
From: Fab S. <fab...@gm...> - 2016-06-14 07:05:53
|
(sent again from another email because rejected from linux-scsi) 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 |