On Mon, Sep 11, 2006 at 08:21:35AM -0400, James Smart wrote: > What this tells me is that the reporting as a scsi-4 device is > telling the midlayer to use Report Luns, and that Report Luns is likely > failing on this target. If the manual scans succeed, it says the > luns are there, but were not reported in Report Luns. What you are > encountering is an interaction between the target device and the midlayer > scan behaviors. You should have like behavior on other adapters. > Sounds like this device could use a device list entry. I can post some other log if someone finds it useful, anyway other adapters (serveraid, adaptech, iscsi) on the same system fill also their /proc stuff, this is the reason why I never noticed my scsi userspace tools were obsolete. Debian Sarge being supposedly _stable_, it was a bit a surprise for me... It is likely that this kind of problem will show up frequently while old userpace tools are not fully updated and transition to sys completed. > Please note: it is general practice that /proc stuff for adapters is > being deprecated in lieu of using the /sys/class/scsi_host/host<#> > attributes. This has been true for the lpfc driver as it was a > requirement when we first integrated into kernel.org around 2.6.10. > Expect other adapters to behave the same as lpfc. OK, Thank you. Alberto - 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
