set CONFIG_SCSI_MULTI_LUN by default and update help
PATCH 1/1 set CONFIG_SCSI_MULTI_LUN by default and update help
Hello,
Here is a patch against 2.6.30-rc4, but probably material for 2.6.31, which should avoid a couple of people to have the same problem as me.
Eric
==
I had to set CONFIG_SCSI_MULTI_LUN to y in order to get my SE W595 working when plugging it as a mass storage. Looking at SCSI option to get a phone behaving correctly was convoluted to say the least. There are quite a few other reports about USB card readers needing this option as well.
This patch improves the help text to make the use of the option more obvious and also defaults it to Y. I couldn't find any explicit reports of devices not working because of multiple LUNs probing, but only reports of people would had heard of such reports. In addition, every mainstream distro have this option activated, so it should definitely not be too dangerous.
--- drivers/scsi/Kconfig | 18 ++++++++---------- 1 files changed, 8 insertions(+), 10 deletions(-)
drivers/scsi/Kconfig +8 -10
@@ -191,20 +191,18 @@ config SCSI_ENCLOSURE it has an enclosure device. Selecting this option will just allow certain enclosure conditions to be reported and is not required. -comment "Some SCSI devices (e.g. CD jukebox) support multiple LUNs" - depends on SCSI - config SCSI_MULTI_LUN bool "Probe all LUNs on each SCSI device" depends on SCSI + default y help - If you have a SCSI device that supports more than one LUN (Logical - Unit Number), e.g. a CD jukebox, and only one LUN is detected, you - can say Y here to force the SCSI driver to probe for multiple LUNs. - A SCSI device with multiple LUNs acts logically like multiple SCSI - devices. The vast majority of SCSI devices have only one LUN, and - so most people can say N here. The max_luns boot/module parameter - allows to override this setting. + Some devices support more than one LUN (Logical Unit Number) in order + to allow access to several media, e.g. CD jukebox, USB card reader, + mobile phone in mass storage mode. This option forces the kernel to + probe for all LUNs by default. This setting can be overriden by + max_luns boot/module parameter. You want to say Y here unless you + have one of those rare devices which reacts in an unexpected way when + probed for multiple LUNs. config SCSI_CONSTANTS bool "Verbose SCSI error reporting (kernel size +=12K)"
Signature · 1 line
1.6.2.4
James Bottomley
maintainerQuoted 14 lines · Éric Piel
Hello,
Here is a patch against 2.6.30-rc4, but probably material for 2.6.31, which should avoid a couple of people to have the same problem as me.
Eric
==I had to set
CONFIG_SCSI_MULTI_LUNto y in order to get my SE W595 working when plugging it as a mass storage. Looking at SCSI option to get a phone behaving correctly was convoluted to say the least. There are quite a few other reports about USB card readers needing this option as well.
Quoted 8 lines
This patch improves the help text to make the use of the option more obvious and also defaults it to Y. I couldn't find any explicit reports of devices not working because of multiple LUNs probing, but only reports of people would had heard of such reports. In addition, every mainstream distro have this option activated, so it should definitely not be too dangerous.
Signed-off-by Eric Piel <[email protected]>
Actually, I'd really rather not alter the default value of this setting. Multi-lun is rapidly becoming obsolete: any modern devices conforming to SCSI-3 use REPORT LUNS instead of doing LUN scanning, which gets us out of the issue. Conversely, the ancient devices which rely on correctly setting this are more likely to get upset about any change in the balance.
In your case, just add the changer's inquiry strings with a BLIST_FORCELUN.
James
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
James Bottomley schreef:
Quoted 1 line · Éric Piel
:
Quoted 7 lines
Actually, I'd really rather not alter the default value of this setting. Multi-lun is rapidly becoming obsolete: any modern devices conforming to SCSI-3 use REPORT LUNS instead of doing LUN scanning, which gets us out of the issue. Conversely, the ancient devices which rely on correctly setting this are more likely to get upset about any change in the balance.
Yes, I understand. Would like me to resend the patch without the change on the default value. IMHO, it provides a better wording.
Quoted 3 lines
In your case, just add the changer's inquiry strings with a
BLIST_FORCELUN.
Where, into the usb-storage driver? I guess there is no usb device which can get confused by this, so it should work fine as well :-)
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
James Bottomley
maintainerQuoted 4 lines · Éric Piel
James Bottomley schreef:
Quoted 1 line · Éric Piel
:
Quoted 1 line
Quoted 8 lines
Quoted 6 lines
Actually, I'd really rather not alter the default value of this setting. Multi-lun is rapidly becoming obsolete: any modern devices conforming to SCSI-3 use REPORT LUNS instead of doing LUN scanning, which gets us out of the issue. Conversely, the ancient devices which rely on correctly setting this are more likely to get upset about any change in the balance.
Yes, I understand. Would like me to resend the patch without the change on the default value. IMHO, it provides a better wording.
I'm not opposed in principle to the update ... however it might perhaps need to point out that modern devices (conforming to SCSI-3 and up) will ignore this setting.
This also brings up (again) the problem of USB lying about the SCSI conformance level. Your changer could well have reported SCSI-3 or higher and be quite capable of doing a report lun scan, but the scsiglue.c:216 fix to the scsi compliance level pushed it back down to scsi-2 again.
Quoted 4 lines
Quoted 2 lines
In your case, just add the changer's inquiry strings with a
BLIST_FORCELUN.Where, into the usb-storage driver? I guess there is no usb device which can get confused by this, so it should work fine as well :-)
It's not in the usb driver, it's in the inquiry string blacklist table in scsi_devinfo.c
James
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 6 lines · James Bottomley
Actually, I'd really rather not alter the default value of this setting. Multi-lun is rapidly becoming obsolete: any modern devices conforming to SCSI-3 use REPORT LUNS instead of doing LUN scanning, which gets us out of the issue. Conversely, the ancient devices which rely on correctly setting this are more likely to get upset about any change in the balance.
Yes, but USB devices are prohibited from being SCSI-3 devices, so it's not becoming obsolete.
Quoted 2 lines
In your case, just add the changer's inquiry strings with a
BLIST_FORCELUN.
I wonder if we should make USB devices set that by default? What does Windows do here?
Signature · 4 lines
Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step."
James Bottomley
maintainerQuoted 10 lines · Matthew Wilcox
Quoted 6 lines · James Bottomley
Actually, I'd really rather not alter the default value of this setting. Multi-lun is rapidly becoming obsolete: any modern devices conforming to SCSI-3 use REPORT LUNS instead of doing LUN scanning, which gets us out of the issue. Conversely, the ancient devices which rely on correctly setting this are more likely to get upset about any change in the balance.
Yes, but USB devices are prohibited from being SCSI-3 devices, so it's not becoming obsolete.
No they're not, there's nothing in the USB specs that say this. UAS will specifically require it.
The problem is we don't trust USB manufacturers with standards compliance any further than they could spit a rat, so we assume when they say they conform to SCSI-3 or above that they must have got it wrong and push it back down to SCSI-2.
Because of this, no-one actually knows how many working SCSI-3 USB devices we might have supported.
James
Quoted 9 lines · James Bottomley
Quoted 8 lines · Matthew Wilcox
Quoted 6 lines · James Bottomley
Actually, I'd really rather not alter the default value of this setting. Multi-lun is rapidly becoming obsolete: any modern devices conforming to SCSI-3 use REPORT LUNS instead of doing LUN scanning, which gets us out of the issue. Conversely, the ancient devices which rely on correctly setting this are more likely to get upset about any change in the balance.
Quoted 5 lines
Quoted 2 lines
Yes, but USB devices are prohibited from being SCSI-3 devices, so it's not becoming obsolete.
No they're not, there's nothing in the USB specs that say this. UAS will specifically require it.
I didn't mean "prohibited by the USB spec", I meant "prohibited by Linux", for the exact reason you say below.
Quoted 7 lines
The problem is we don't trust USB manufacturers with standards compliance any further than they could spit a rat, so we assume when they say they conform to SCSI-3 or above that they must have got it wrong and push it back down to SCSI-2.
Because of this, no-one actually knows how many working SCSI-3 USB devices we might have supported.
This is true. Suggestions for a better way to handle USB devices ... ?
Signature · 4 lines
Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step."
Quoted 4 lines · Matthew Wilcox
Quoted 4 lines
The problem is we don't trust USB manufacturers with standards compliance any further than they could spit a rat, so we assume when they say they conform to SCSI-3 or above that they must have got it wrong and push it back down to SCSI-2.
Indeed, we have run across a number of USB devices which claim to be SCSI-3 compliant and then crash when they receive a REPORT LUNS command.
Quoted 4 lines
Quoted 2 lines
Because of this, no-one actually knows how many working SCSI-3 USB devices we might have supported.
This is true. Suggestions for a better way to handle USB devices ... ?
Is there any reason usb-storage shouldn't set the FORCELUNS flag for all devices not known to have only one LUN?
Eric is trying to address two separate issues. One is bad or outdated wording of the Kconfig help text for SCSI_MULTI_LUN. The other is the fact that some USB devices can't be used to their full extent when the option isn't set, and people rolling their own configs (as opposed to using a distro kernel) tend not to enable it. Maybe changing the help text will be enough for both problems.
As for future treatment of USB devices claiming SCSI-3 compliance (or above), I don't know. Keep the field unchanged but set a flag to rule out the use of REPORT LUNS?
Alan Stern
PATCH 1/1 Update wording of CONFIG_SCSI_MULTI_LUN help
In reply to James BottomleyHello,
This is an updated version of the previous patch. It now leaves the default option value to N, and a note explaining that SCSI-3+ devices are not affected was added.
As it only makes the options more understandable without changing the behaviour, it could be considered for 2.6.30, but I let you decide :-)
Eric
==
I had to set CONFIG_SCSI_MULTI_LUN to y in order to get my SE W595 working when plugging it as a mass storage. Looking at SCSI option to get a phone behaving correctly was convoluted to say the least. There are quite a few other reports about USB card readers needing this option as well. This patch improves the help text to make the use of the option more obvious.
--- drivers/scsi/Kconfig | 19 +++++++++---------- 1 files changed, 9 insertions(+), 10 deletions(-)
drivers/scsi/Kconfig +9 -10
@@ -191,20 +191,19 @@ config SCSI_ENCLOSURE it has an enclosure device. Selecting this option will just allow certain enclosure conditions to be reported and is not required. -comment "Some SCSI devices (e.g. CD jukebox) support multiple LUNs" - depends on SCSI - config SCSI_MULTI_LUN bool "Probe all LUNs on each SCSI device" depends on SCSI help - If you have a SCSI device that supports more than one LUN (Logical - Unit Number), e.g. a CD jukebox, and only one LUN is detected, you - can say Y here to force the SCSI driver to probe for multiple LUNs. - A SCSI device with multiple LUNs acts logically like multiple SCSI - devices. The vast majority of SCSI devices have only one LUN, and - so most people can say N here. The max_luns boot/module parameter - allows to override this setting. + Some devices support more than one LUN (Logical Unit Number) in order + to allow access to several media, e.g. CD jukebox, USB card reader, + mobile phone in mass storage mode. This option forces the kernel to + probe for all LUNs by default. This setting can be overriden by + max_luns boot/module parameter. Note that this option does not affect + devices conforming to SCSI-3 or higher as they can explicitely report + their number of LUNs. It is safe to say Y here unless you have one of + those rare devices which reacts in an unexpected way when probed for + multiple LUNs. config SCSI_CONSTANTS bool "Verbose SCSI error reporting (kernel size +=12K)"
Signature · 1 line
1.6.2.4