All of the Initio bridges are notorious for funky firmware. I will look into
what could be done.

Are you sure though that this bridge doesn't have perhaps a write protect jumper
somewhere? Some bridges used for HDD forensics do.

Also, I assume you rather meant "Most recent kernel where this bug *did* occur:
2.6.17.7" (instead of "did not occur"), right?

The information I got from Initio do not mention write-protect jumps.
The only pins available are for LED and chip GPIO, which the current
firmware is not supposed to use.
As I mentioned, the USB side works fine (which reminds me to check
the sense reported in this case), since this is integrated in the
INIC-1530, I guess a potential write-protect switch should have
worked also in the USB case.
In the meantime I got a new firmware from Initio, which, at the moment,
I cannot download (I need a windows PC), I'll let you know (but, please,
don't stop your investigation).

About the "did not occur" thing, of course I should not write bug
report in hurry in the evening...
That was an "overlook" from my side, actually, as mentioned, it seems
to me around Oct/Nov 2005 it was working properly.

It is worth trying to look for a safe and cheap workaround before you try the
firmware upgrade. I suppose the cheapest approach would be to give a
BLIST_MS_SKIP_PAGE_3F blacklist flag to scsi_mod:
# modprobe scsi_mod scsi_dev_flags=Initio:SP2014N:16384
or without distinction of vendor and model:
# modprobe scsi_mod scsi_default_dev_flags=16384

Another thing to try: How does the disk behave if you remove the line
	sdev->use_10_for_ms = 1;
from sbp2scsi_slave_configure?

BTW, the main difference to 2005 is that sd_mod now handles the RBC command set
by itself and sbp2's RBC conversions were removed. Although Initio bridges are
among the few odd SBP-2 bridges which claim to implement SBC instead of RBC for
HDDs.

I found something interesting, but let's proceed in order.

The scsi dev_flag trick did not work, write protect on was always there,
and sense result was also the same 00 13 00 af.

The sbp2.c trick, did work, write protect went off, sense was 10 00 00 00.

USB sense is 00 00 00 00, I dunno if this can help.

But the _really_ funny thing is an other.

This behaviour seems to be hard disk dependent!

The SP2014N originally attached (set as master) reports the 00 13 00 af
and write protect on, so does a WD800BB set as master or cable select.

A _very_ old FIREBALL_TM3840A report sense 00 13 00 7f and starts,
without any trick, with write protect off (set as master).
Same does a brand new ST3250620A, with sense 00 13 00 6f (also master).

This makes me think that it could be some timing problem either in the
Initio (chip and/or firmware) or in the sbp2 software.
The FIREBALL_TM3840A is pretty slow and does not support UDMA, the ST3250620A,
while brand new, might have some longer setup time (compared to the other
two not working).

I have an other couple of HD, which could be tested, in the meantime
do you have any idea or other suggestions?
Thanks.

Sorry, I got the syntax of scsi_mod's parameters wrong.
# modprobe scsi_mod dev_flags=Initio:SP2014N:16384
or
# modprobe scsi_mod default_dev_flags=16384
should result in a log message like "kernel: sda: assuming Write Enabled". Or
that's how it works for me (with different disks) under Linux 2.6.17.6. This
blacklist flag will let sd_mod skip the WP bit test entirely. The first syntax
won't work if the vendor and model strings don't match exactly. It doesn't seem
to work if the vendor and model strings contain spaces.

Anyway. If disabling of "use_10_for_ms" works, we could add this as a
blacklist-triggered workaround to sbp2. I will follow up with a patch.

The phenomenon that the bridge behaves differently depending on attached disks
may come from buffer[3] containing some data that differs from disk to disk ---
but is definitely not a MODE SENSE 10 header with WP flag as highest bit in the
fourth byte (i.e. byte 3) as expected by the SBC spec.
scsi_lib.c::scsi_mode_sense() already contains a related check for INIC 14x0 and
INIC2430:
http://me.in-berlin.de/~s5r6/linux1394/merged/available_in_2.6.17/scsi_lib-fix-recognition-of-cache-type-of-Initio-SBP2-bridges.patch
But I can't identify yet what the exact breakage of your INIC1530 is and how it
could be converted. Could you add
    printk(KERN_DEBUG "scsi_mode_sense: %02x %02x %02x %02x\n",
           buffer[0], buffer[1], buffer[2], buffer[3]);
    if (len >= 8)
        printk(KERN_DEBUG "scsi_mode_sense: %02x %02x %02x %02x\n",
               buffer[4], buffer[5], buffer[6], buffer[7]);
to scsi_mode_sense() right before the line with
"if(scsi_status_is_good(result))" and post the output?

Using:

# modprobe scsi_mod default_dev_flags=16384

works as you mentiond.
Problem was I was using the other method:

# modprobe scsi_mod dev_flags=Initio:SP2014N:16384

But with "Initio::16384" hoping it will match everything,
since the "SP2014N" in the HD model and it changes, when
changing the HD. The workaround must be model independent,
I guess.

This is the output, after the printk path in scsi_lib.c
(assuming I did not make mistakes...) using the WD800BB
HD (set as cable select):

...
SCSI subsystem initialized
ieee1394: sbp2: Driver forced to serialize I/O (serialize_io=1)
ieee1394: sbp2: Try serialize_io=0 for better performance
scsi0 : SBP-2 IEEE-1394
ieee1394: sbp2: Workarounds for node 0-00:1023: 0x2 (firmware_revision 0x000243,
vendor_id 0x001010, model_id 0x000540)
ieee1394: sbp2: Logged into SBP-2 device
ieee1394: Node 0-00:1023: Max speed [S400] - Max payload [2048]
  Vendor: Initio    Model: WD800BB-22JHC0    Rev: 2.43
  Type:   Direct-Access                      ANSI SCSI revision: 00
SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
scsi_mode_sense: 00 13 00 af
scsi_mode_sense: 00 00 00 00
sda: Write Protect is on
sda: Mode Sense: 00 13 00 af
scsi_mode_sense: 00 13 00 af
scsi_mode_sense: 00 00 00 00
scsi_mode_sense: 00 13 00 af
scsi_mode_sense: 00 00 00 00
SCSI device sda: drive cache: write back
SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
scsi_mode_sense: 00 13 00 af
scsi_mode_sense: 00 00 00 00
sda: Write Protect is on
sda: Mode Sense: 00 13 00 af
scsi_mode_sense: 00 13 00 af
scsi_mode_sense: 00 00 00 00
scsi_mode_sense: 00 13 00 af
scsi_mode_sense: 00 00 00 00
SCSI device sda: drive cache: write back
 sda: unknown partition table
sd 0:0:0:0: Attached scsi disk sda
...

I tried also to set workarounds to 0x100, so to override
the inquiry hack 36, but did not change a bit.

Hope this helps.

Hmm, alas I still don't recognize this pattern of the scsi_mode_sense buffer. I
think we should go the MODE SENSE (6) route since this yields proper data. Patch
will follow in a minute.

BTW, www.initio.com has a "data book" PDF for INIC-1530 which seems to contain
all the information required to implement a firmware uploader. (But although it
looks rather simple, I won't start such a project anytime soon.)

Proposed patch which selectively enforces MODE SENSE (6):

against 2.6.17.y
http://me.in-berlin.de/~s5r6/linux1394/pending/2.6.17.7-ieee1394-sbp2-workaround-for-write-protect-bit-of-initio-firmware.patch

against 2.6.18-rc2-mm1
http://me.in-berlin.de/~s5r6/linux1394/pending/133-ieee1394-sbp2-workaround-for-write-protect-bit-of-initio-firmware.patch

posting to linux1394-devel and linux-scsi
http://thread.gmane.org/gmane.linux.kernel.firewire.devel/7642

Just one quick question.

The MODE SENSE (6) what other consequences could have?

Is anything I should test, apart the write protect, in
order to make sure the patch does not have any side effects?
Or everything is fine like this?

Because than a question pops up in my mind: why not to use
MODE SENSE (6) always?

Anyway, if you need further testing, don't esitate do ask.

Of course, I meant "then" and not "than" in:

"Because then a question pops up in my mind: why not to use
MODE SENSE (6) always?"

About the firmware downloader, the data book mentions 1394 and
USB mode, the win utility uses only USB mode (for the 1530).

You mention it should not be difficult, but is there any
documentation/tool around on how to user the "raw" interface?

About MS(6) versus MS(10):
RBC requires devices to implement MS(6). Most SBP-2 HDDs implement RBC.
SBC says MS(6) and MS(10) were both optional. Initio nridges claim to implement
SBC if a HDD is connected.
MMC requires devices to implement MS(10). Most CD/DVD-ROMs or writers implement MMC.

Linux starts with MS(10) or MS(6) according to the use_10_for_ms bit. If a
device returns "illegal request" status, Linux flips the bit and retries.

Therefore the initial setting of use_10_for_ms does not have an effect on
properly implemented devices. Alas not all devices are properly implemented,
therefore I'd rather stick with what sbp2 has done before and seems to work with
the vast majority of devices.

The buffer "10 00 00 00" after MS(6) looks OK to me, but I'm not a SCSI expert.
As long as the write protect flag and the cache type are properly recognized (I
suppose "write back" or "write through"), MS(6) does what we want.

About the firmware downloader (or uploader):
You would need a program which, among else, has to translate each byte of the
firmware image into a quadlet to feed into the bridge. This can be done via
libraw1394 using raw1394_read() to check the device's type and model (and
perhaps read the present firmware to make a backup image) and raw1394_write() to
write the firmware. In theory it could even be done without direct interfacing
to libraw1394 but rather via the command line tool 1394commander, embedded in a
script or program.

The patch from comment #8 has been posted to lkml and was picked up for Linux
2.6.18-rc4-mm1.

If the patch is OK for you I will send it to Linus (or actually Greg KH while
Linus is away) circa at the end of next week to get it into Linux 2.6.18.

Good to read this!

I was using the sbp2 patched in these days, and I had no problems at all.
Even if I cannot say I did a deep test, but I guess I can bless it ;-)

I have some other news, anyway, which could affect the patch.

I updated today the firmware, from 2.43 to 2.64, this is the output
of the "verbose" scsi_lib, with workarounds disabled (I hope):

ieee1394: sbp2: Workarounds for node 0-02:1023: 0x100 (firmware_revision
0x000264, vendor_id 0x001010, model_id 0x000540)
ieee1394: sbp2: Logged into SBP-2 device
ieee1394: Node 0-02:1023: Max speed [S400] - Max payload [2048]
  Vendor: Initio    Model: SP2014N           Rev: 2.64
  Type:   Direct-Access                      ANSI SCSI revision: 00
SCSI device sdb: 390721968 512-byte hdwr sectors (200050 MB)
scsi_mode_sense: 00 13 00 00
scsi_mode_sense: 00 00 00 00
sdb: Write Protect is off
sdb: Mode Sense: 00 13 00 00
scsi_mode_sense: 00 13 00 00
scsi_mode_sense: 00 00 00 00
scsi_mode_sense: 00 13 00 00
scsi_mode_sense: 00 00 00 00
SCSI device sdb: drive cache: write back
SCSI device sdb: 390721968 512-byte hdwr sectors (200050 MB)
scsi_mode_sense: 00 13 00 00
scsi_mode_sense: 00 00 00 00
sdb: Write Protect is off
sdb: Mode Sense: 00 13 00 00
scsi_mode_sense: 00 13 00 00
scsi_mode_sense: 00 00 00 00
scsi_mode_sense: 00 13 00 00
scsi_mode_sense: 00 00 00 00
SCSI device sdb: drive cache: write back
 sdb: unknown partition table
sd 3:0:0:0: Attached scsi disk sdb

It seems to me, if I understand it correctly, they fixed the issue.
Maybe it would be better to have the MS(6) (and inquiry 36) workaround
available, but disabled by default.
The problem is that the "Vendor" and "Model" are fully programmable
(I discovered this by playing with the firmware tool), together with
_all_ the ID numbers, so I'm not so sure it make sense to detect the
device by these means and apply workarounds which could not be suitable
for the actual device or should be applied, but the device is not
properly detected.
Maybe could be OK to clearly and fully document the workarounds
(and the cases where they are known to be useful) to the end user,
instead of trying to apply them fully automatically, which may
not be really working.
Anyway, you know better, this was just some free thinking.

As I wrote above, it seems they fixed the "Write protect" issue,
but now something else popped up:

ieee1394: sbp2: sbp2util_node_write_no_wait failed.

ieee1394: sbp2: aborting sbp2 command
sd 3:0:0:0:
        command: cdb[0]=0x2a: 2a 00 12 02 41 20 00 00 f8 00

Maybe they improved the performaces too much too...
How is it going with your reworking? Do you need some support?

An other note, the 1530 docs mentions that SBP2, MMC-2, RBC
and ATA/ATAPI are supported, but not SBC.
Of course, MMC-2 should imply MS(10), but SBC is not mentioned,
so if the sbp2 driver uses it for the Initio, it does not seems
to be really correct.

Hope this helps.

Final note: I'm having a look on the firmware uploader/downloader,
just playing with 1394commander (and the 1530 datasheet).
Eventually, if something meaninful pops up, I'll let you know.

Thanks again.

a) The output after firmware update looks good.

b) I'd rather keep those workarounds enabled. All of sbp2's current workarounds
(except for the fix capacity bit) will not affect devices which are fully
compliant to their respective SCSI command set specification.

c) Yes, those config ROM values are not entirely trustworthy and they do not
tell if there is a buggy or fixed firmware present. However this is less of an
issue as long as (b) applies.

We cannot educate users to become SCSI command set experts. I'm not one either,
I just learn more of SCSI command sets on the go. Instead we should try to let
sbp2 interoperate automatically as far as possible. That's realistic as long as
(b) is true.

I agree to the extent that we should try harder to document sbp2 more clearly
(as well as the rest of the ieee1394 subsystem). We have www.linux1394.org but
there are difficulties to keep it up to date.

d) We will track 'sbp2util_node_write_no_wait failed' under bug 6948.

e) MMC applies if a CD or DVD-ROM or -R/W is attached. The bridge would then
show a PERIPHERAL DEVICE TYPE of 0x05 in the inqury data (printed as "CD-ROM" by
scsi_mod, also shown as numeric sysfs attribute of the SCSI device). RBC applies
 to most HDDs and similar blockwise accessed devices if attached via SBP-2. The
bridge is then expected to show device type 0x0e (printed as
"Direct-Access-RBC"). The Initio bridges claim device type 0x00 though
("Direct-Access", which is associated with SBC). I suppose they actually (tried
to) implement RBC instead of SBC though.

As mentioned, if a device supports MODE SENSE (6) but not MODE SENSE (10), it
has to return a status of "illegal request" after MODE SENSE (10). The trouble
with the old Initio firmware was that it obviously returned "good" status
instead and delivered bogus mode parameters.

What I don't fully understand is why sbp2 always enforced MODE SENSE (10) in
older versions and is now still recommending MODE SENSE (10) to the SCSI layer
--- although RBC requires only MODE SENSE (6) to be implemented. However even if
sbp2 would leave use_10_for_ms off if it detects an RBC device, it wouldn't have
helped with the Initio bridge since it poses as an SBC device, not an RBC device.

Anyway. Thanks for the good reports and all the tests so far. I will mark this
bug as closed when the use_10_for_ms patch went into mainline.

Further investigation lead to plan to drop the proposed Initio specific patch
and always prefer MODE SENSE (6) -- just like you said in comment #9.
http://lkml.org/lkml/2006/9/4/244
http://lkml.org/lkml/2006/9/7/261

fix went into Linux 2.6.18-git16