From: Fab Stz <fabstmail@gmail.com>
To: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: linux1394-user@lists.sourceforge.net, linux-scsi@vger.kernel.org
Subject: Re: Partitions not detected with firewire - 36 bytes offset - PL-3507
Date: Tue, 14 Jun 2016 09:05:35 +0200 [thread overview]
Message-ID: <1777209.O0WHVKuHCq@debian> (raw)
In-Reply-To: <20160607151554.5b33bc0c@kant>
[-- Attachment #1: Type: text/plain, Size: 3601 bytes --]
(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
[-- Attachment #2: sdparm-a.out --]
[-- Type: text/plain, Size: 5779 bytes --]
/dev/sdb: SAMSUNG SP0842N [simplified direct access device]
Read write error recovery mode page:
>>> warning: mode page seems malformed
The page number field should be 0x01, but is 0x06; try '--flexible'
AWRE 0 [cha: n, def: 0, sav: 0]
ARRE 0 [cha: n, def: 0, sav: 0]
TB 0 [cha: n, def: 0, sav: 0]
RC 0 [cha: n, def: 0, sav: 0]
EER 0 [cha: n, def: 0, sav: 0]
PER 0 [cha: n, def: 0, sav: 0]
DTE 0 [cha: n, def: 0, sav: 0]
DCR 0 [cha: n, def: 0, sav: 0]
RRC 2 [cha: y, def: 2, sav: 2]
COR_S 0 [cha: n, def: 0, sav: 0]
HOC 0 [cha: n, def: 0, sav: 0]
DSOC 4 [cha: y, def: 4, sav: 4]
WRC 21 [cha: y, def: 21, sav: 21]
Disconnect-reconnect (SPC + transports) mode page:
>>> warning: mode page seems malformed
The page number field should be 0x02, but is 0x06; try '--flexible'
BFR 0 [cha: n, def: 0, sav: 0]
BER 2 [cha: y, def: 2, sav: 2]
BIL 0 [cha: n, def: 0, sav: 0]
DTL 1227 [cha: y, def:1227, sav:1227]
CTL 5568 [cha: y, def:5568, sav:5568]
MBS 1 [cha: y, def: 1, sav: 1]
EMDP 0 [cha: n, def: 0, sav: 0]
FA 0 [cha: n, def: 0, sav: 0]
DIMM 0 [cha: n, def: 0, sav: 0]
DTDC 0 [cha: n, def: 0, sav: 0]
RBC device parameters (RBC) mode page:
WCD 0 [cha: n, def: 0, sav: 0]
LBS 512 [cha: y, def:512, sav:512]
NLBS 0x4cb15c0 [cha: y, def:0x4cb15c0, sav:0x4cb15c0]
P_P 0 [cha: n, def: 0, sav: 0]
READD 0 [cha: n, def: 0, sav: 0]
WRITED 0 [cha: n, def: 0, sav: 0]
FORMATD 0 [cha: n, def: 0, sav: 0]
LOCKD 1 [cha: y, def: 1, sav: 1]
Control mode page:
>>> warning: mode page seems malformed
The page number field should be 0x0a, but is 0x06; try '--flexible'
TST 0 [cha: n, def: 0, sav: 0]
TMF_ONLY 0 [cha: n, def: 0, sav: 0]
DPICZ 0 [cha: n, def: 0, sav: 0]
D_SENSE 0 [cha: n, def: 0, sav: 0]
GLTSD 0 [cha: n, def: 0, sav: 0]
RLEC 0 [cha: n, def: 0, sav: 0]
QAM 0 [cha: n, def: 0, sav: 0]
NUAR 0 [cha: n, def: 0, sav: 0]
QERR 1 [cha: y, def: 1, sav: 1]
RAC 0 [cha: n, def: 0, sav: 0]
UA_INTLCK 0 [cha: n, def: 0, sav: 0]
SWP 0 [cha: n, def: 0, sav: 0]
ATO 0 [cha: n, def: 0, sav: 0]
TAS 0 [cha: n, def: 0, sav: 0]
ATMPE 0 [cha: n, def: 0, sav: 0]
RWWP 0 [cha: n, def: 0, sav: 0]
AUTOLOAD 0 [cha: n, def: 0, sav: 0]
BTP 5568 [cha: y, def:5568, sav:5568]
ESTCT 1 [cha: y, def: 1, sav: 1]
Control extension mode page:
>>> warning: mode page seems malformed
The page number field should be 0x0a, but is 0x06; try '--flexible'
TCMOS 0 [cha: n, def: 0, sav: 0]
SCSIP 0 [cha: n, def: 0, sav: 0]
IALUAE 0 [cha: n, def: 0, sav: 0]
INIT_PR 0 [cha: n, def: 0, sav: 0]
MSDL 4 [cha: y, def: 4, sav: 4]
SAT pATA control mode page:
>>> warning: mode page seems malformed
The page number field should be 0x0a, but is 0x06; try '--flexible'
MWD2 0 [cha: n, def: 0, sav: 0]
MWD1 0 [cha: n, def: 0, sav: 0]
MWD0 0 [cha: n, def: 0, sav: 0]
PIO4 0 [cha: n, def: 0, sav: 0]
PIO3 0 [cha: n, def: 0, sav: 0]
UDMA6 0 [cha: n, def: 0, sav: 0]
UDMA5 0 [cha: n, def: 0, sav: 0]
UDMA4 0 [cha: n, def: 0, sav: 0]
UDMA3 0 [cha: n, def: 0, sav: 0]
UDMA2 0 [cha: n, def: 0, sav: 0]
UDMA1 0 [cha: n, def: 0, sav: 0]
UDMA0 0 [cha: n, def: 0, sav: 0]
Protocol specific logical unit mode page:
>>> warning: mode page seems malformed
The page number field should be 0x18, but is 0x06; try '--flexible'
LUPID 0 [cha: n, def: 0, sav: 0]
Protocol specific port mode page:
>>> warning: mode page seems malformed
The page number field should be 0x19, but is 0x06; try '--flexible'
PPID 0 [cha: n, def: 0, sav: 0]
Power condition mode page:
>>> warning: mode page seems malformed
The page number field should be 0x1a, but is 0x06; try '--flexible'
PM_BG 0 [cha: n, def: 0, sav: 0]
STANDBY_Y 0 [cha: n, def: 0, sav: 0]
IDLE_C 0 [cha: n, def: 0, sav: 0]
IDLE_B 0 [cha: n, def: 0, sav: 0]
IDLE 1 [cha: y, def: 1, sav: 1]
STANDBY 0 [cha: n, def: 0, sav: 0]
ICT 1227 [cha: y, def:1227, sav:1227]
SCT 364904449 [cha: y, def:364904449, sav:364904449]
IBCT 0 [cha: n, def: 0, sav: 0]
Power consumption mode page:
>>> warning: mode page seems malformed
The page number field should be 0x1a, but is 0x06; try '--flexible'
ps_id 203 [cha: y, def:203, sav:203]
SAT ATA Power condition mode page:
>>> warning: mode page seems malformed
The page number field should be 0x1a, but is 0x06; try '--flexible'
APMP 0 [cha: n, def: 0, sav: 0]
APM 4 [cha: y, def: 4, sav: 4]
Informational exceptions control mode page:
>>> warning: mode page seems malformed
The page number field should be 0x1c, but is 0x06; try '--flexible'
PERF 0 [cha: n, def: 0, sav: 0]
EBF 0 [cha: n, def: 0, sav: 0]
EWASC 0 [cha: n, def: 0, sav: 0]
DEXCPT 0 [cha: n, def: 0, sav: 0]
TEST 0 [cha: n, def: 0, sav: 0]
EBACKERR 0 [cha: n, def: 0, sav: 0]
LOGERR 0 [cha: n, def: 0, sav: 0]
MRIE 2 [cha: y, def: 2, sav: 2]
INTT 1227 [cha: y, def:1227, sav:1227]
REPC 364904449 [cha: y, def:364904449, sav:364904449]
prev parent reply other threads:[~2016-06-14 7:05 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4379835.Lnu4rjdqZg@debian>
2016-06-07 13:15 ` Partitions not detected with firewire - 36 bytes offset - PL-3507 Stefan Richter
2016-06-14 6:55 ` Fab Stz
2016-06-14 7:05 ` Fab Stz [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1777209.O0WHVKuHCq@debian \
--to=fabstmail@gmail.com \
--cc=linux-scsi@vger.kernel.org \
--cc=linux1394-user@lists.sourceforge.net \
--cc=stefanr@s5r6.in-berlin.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).