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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.