On Sun, 2005-10-23 at 02:33 +0200, Stefan Richter wrote: > I just noticed that devices which require sbp2's inquiry hack are not > usable anymore. I don't know when the regression crept in since I don't > remember when I used the affected device successfully the last time. One > thing is for sure: The code change which triggered the regression took > not place in sbp2 itself. > > The device in question is an older 2.5" FireWire disk, DViCO Momobay > CX-1. What happens under Linux 2.6.14-rc5 is this: Without debug logging > turned on, it seems as if the process which started the sbp2 probe > (knodemgrd or modprobe) is hanging in D state. But debug logging enabled > in sbp2 reveals that it isn't locked up but rather caught in a loop, > sending inquiry commands: > > > Oct 23 01:26:59 shuttle kernel: ieee1394: sbp2: sbp2_module_init > > Oct 23 01:26:59 shuttle kernel: sbp2: $Rev: 1306 $ Ben Collins <bcollins@xxxxxxxxxx> > > Oct 23 01:26:59 shuttle kernel: ieee1394: sbp2: sbp2_probe > > Oct 23 01:26:59 shuttle kernel: ieee1394: sbp2: sbp2_alloc_device > > Oct 23 01:26:59 shuttle kernel: ieee1394: sbp2: sbp2_alloc_device: allocated hostinfo > > Oct 23 01:26:59 shuttle kernel: scsi0 : SCSI emulation for IEEE-1394 SBP-2 Devices > > Oct 23 01:26:59 shuttle kernel: ieee1394: sbp2: sbp2_parse_unit_directory > > Oct 23 01:26:59 shuttle kernel: ieee1394: sbp2: sbp2_management_agent_addr = f0010000 > > Oct 23 01:26:59 shuttle kernel: ieee1394: sbp2: sbp2_unit_characteristics = a08 > > Oct 23 01:26:59 shuttle kernel: ieee1394: sbp2: sbp2_command_set_spec_id = 609e > > Oct 23 01:26:59 shuttle kernel: ieee1394: sbp2: sbp2_command_set = 104d8 > > Oct 23 01:26:59 shuttle kernel: ieee1394: sbp2: sbp2_firmware_revision = 2800 > > Oct 23 01:26:59 shuttle kernel: ieee1394: sbp2: Node 1-01:1023: Using 36byte inquiry workaround I don't see any looping in the traces, could you characterise what's going on for those of us who haven't fully explored the sbp2 driver? However, at a brief examination it looks like you do quite a lot of response snooping. This always was broken for commands from userspace, but it's completely broken now we only use scatter/gather commands from block. Secondly, I don't think your inquiry hack is effective any more, because you try to alter request_bufflen, which doesn't carry the length of a s/g command. We have a device flag: BLIST_INQUIRY_36 which restricts the named devices only to having 36 byte inquiries sent. Could your internal table be migrated up to the mid-layer list to avoid the issue altogether? James James - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
