PeterNSteinmetz wrote on 2009-01-28: > I understand this chip has had issues in the past under Linux kernels, and I > see in the > dmesg that a workaround is being used. The comments in the source (sdp2.c) > for this > workaround note, however, that this may have been only necessary for their > older > products, and the lookup is using a wildcard for the model_id. > > So is it possible, with the latest firmware upgrades, that this workaround > itself is > causing the timeout on login?
No, it doesn't. This particular workaround only influences behaviour of the SCSI layer which only kicks in after a successful login. > (the workaround seems to be chopping the length in the request to conform to > some > older windows bug) More precisely, it tells the Linux SCSI core how to set the ALLOCATION LENGTH parameter in the SCSI INQUIRY command. (See the SPC spec, section "Commands for all device types", "INQUIRY command", if you are interested in the details.) IIRC this was of more importance a few years ago in earlier revisions of the SCSI core. Nowadays the SCSI core sets it to 36 bytes in the first attempt of INQUIRY anyway. If the 36 byte INQUIRY is successful, the SCSI core will run a retry with a larger ALLOCATION LENGTH unless the device was blacklisted (because it returns wrong results with larger lengths or crashes or whatever). The reference to Windows in sbp2.c's comment basically means that popular Windows flavors apparently issue only 36 byte INQUIRYs, hence firmware authors don't easily notice if they made a mistake in their INQUIRY handler. So, the SBP2_WORKAROUND_INQUIRY_36 merely influences behaviour _after_ successful login and _after_ successful first INQUIRY SCSI transaction. Furthermore, an ALLOCATION LENGTH bigger than 36 bytes, if it is supported by the device, returns information that is mostly uninteresting for FireWire devices, except for marginally interesting claims of conformance to SCSI specifications in addition to the conformance claims made in the first 8 bytes of the INQUIRY response. > And if this is true, is there a way to turn off the workaround? So, you don't need to turn the hard-wired workaround off; yet you can do so easily: # echo 0x100 > /sys/module/sbp2/parameters/workarounds This, like any other echo command into sbp2's workaround parameter file, becomes effective at the next time a device is plugged in. # modinfo sbp2 has a brief overview of available workarounds flags. Note that usage of the workarounds module parameter is only meant as a measure of last resort, hence we don't provide actual documentation of it besides the sbp2.c source. > Or perhaps modify this module to identify the devices for which the > workaround is > really needed? This is impossible because we don't know which Initio firmwares are affected and whether they have any identifiers that differ from unaffected variants. -- External ieee1394 drive not recognized 2.6.27-5 https://bugs.launchpad.net/bugs/279342 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
