Re: ips.c broken since 2.6.23 on x86_64?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



(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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux