The path needs to be triggered, it is the path to handle spoofing of the Adapter's inquiry. You need more printk instrumentation to determine *why* it is not reaching that code path. What is the result of scb->scsi_cmd. scb->bus, ips_is_passthru(scb->scsi_cmd)? The sg breakup issue may need to be looked at, but keep in mind the driver is going down a path that was not intended. Sincerely -- Mark Salyzyn > -----Original Message----- > From: Tim Pepper [mailto:lnxninja@xxxxxxxxxxxxxxxxxx] > Sent: Wednesday, February 13, 2008 7:04 PM > To: linux-scsi@xxxxxxxxxxxxxxx > Cc: FUJITA Tomonori; Salyzyn, Mark > Subject: Re: ips.c broken since 2.6.23 on x86_64? > > (replaced missing cc's including linux-scsi) > > On Wed 13 Feb at 14:39:07 -0800 Mark_Salyzyn@xxxxxxxxxxx said: > > > > - Is the command path code even reaching the controller's > processor inquiry > > spoofing section? > > > > if (scb->scsi_cmd->cmnd[0] == INQUIRY) { > > IPS_SCSI_INQ_DATA inquiry; > > > > memset(&inquiry, 0, > > sizeof (IPS_SCSI_INQ_DATA)); > > > > inquiry.DeviceType = > > IPS_SCSI_INQ_TYPE_PROCESSOR; > > I just added printk's in ips_send_cmd()'s INQUIRY case just before > the above condition test and just within the conditional block. > Neither showed on the console. > > > The target_id check may be flawed? It is not using the > > scmd/sdev accessors and could be the wrong value as a > result. Wild goose > > since arrays are working correctly (?) > > In the original case the arrays appeared to be working > correctly although > we were worried. In the repro case we don't actually have any disk > attached...Forgot to mention that in the original email. > > > - There appears to be a missing 'break' statement for the > START_STOP command > > immediately preceding the TEST_UNIT_READY/INQUIRY cases. > What are the side > > effects of that? It appears to be innocuous. > > No change noted with the missing break added. > > > - ips_scmd_buf_write is used for array capacity and other > fiddly bits and > > must be functioning correctly (?), so I can NOT harm it's > functionality > > except to question if the kmap_atomic returned a non-null > value, it's > > return value apparently is not checked. It's failure > could speak of > > problem(s) elsewhere. > > I've got a printk there and haven't seen any output from it. > Haven't seen > anything from any of the printk's I've tried actually before: > > In the run above to check if ips_send_cmd() hits the > condition you were > curious about...I did capture the following from printk's I added in > ips_allocatescbs(): > > pci_alloc_consistent returns ha->scbs @ 0x18446604437762007040 > pci_alloc_consistent returns ips_sg.list @ 0x18446604437762002944 > pci_alloc_consistent returns ha->scbs @ 0x18446604437698871296 > pci_alloc_consistent returns ips_sg.list @ 0x18446604437756837888 > > I take that as ips_init_phase2() being called and presumable returning > SUCCESS. > > -- > Tim Pepper <lnxninja@xxxxxxxxxxxxxxxxxx> > IBM Linux Technology Center > - 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
