James Bottomley wrote: > Firewire list cc'd It's indeed a problem in the firewire stack. ... >> now we attach another sata disk to the second port of the pci firewire B >> controller: >> >> Jan 12 16:50:49 x3400 kernel: firewire_sbp2: orb reply timed out, rcode=0x11 >> Jan 12 16:50:49 x3400 kernel: sd 11:0:0:0: [sdc] Result: hostbyte=DID_BUS_BUSY >> driverbyte=DRIVER_OK,SUGGEST_OK > > Best I can tell, this is the source of the problem. The sbp2 driver is > replying DID_BUS_BUSY until that gets sorted out, which seems to be > never. When something was plugged in or out at the same bus, fw-sbp2 has to reconnect == renew the login to each logical unit. The syslog in the report is inconclusive whether that happened or failed. There should be one of "reconnected to ... LUN ... (... retries)" or "failed to reconnect to ..." logged eventually. As long as the reconnect didn't succeed, fw-sbp2 quits newly enqueued commands with DID_BUS_BUSY. I need a bit spare time and a way to reproduce this or similar things to get to the cause of this. (I had random reconnect problems with fw-sbp2 now and then, but not yet 100% reproducible ones like the reporter has.) The last tested kernel in the report, 2.6.24-rc7, already contains the latest and greatest firewire code as far as problem at hand is concerned. > So, first pass analysis indicates the error to be in the firewire > subsystem. I'm guessing from the message that it's actually > drivers/firewire, not drivers iee1934? Yes. As a side note, the old sbp2 driver does not quit commands with DID_BUS_BUSY between bus reset and reconnect. Instead it blocks the Scsi_Host in order to not receive commands during that time at all. The time from bus reset to successful reconnect is typically circa a second, on bigger buses with lots of protocol activity after bus reset perhaps a few seconds. (Could IMO still be optimized, in both of the drivers/ieee1394 and drivers/firewire implementations.) -- Stefan Richter -=====-==--- ---= -==-= http://arcgraph.de/sr/ - To unsubscribe from this list: 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
