Bug 9458

Reply-To: akpm@linux-foundation.org

On Sun, 25 Nov 2007 16:38:49 -0800 (PST) bugme-daemon@bugzilla.kernel.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=9458
> 
>            Summary: digital camera not recognised properly by the kernel
>                     when KDE is running
>            Product: Drivers
>            Version: 2.5
>      KernelVersion: 2.6.23
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: USB
>         AssignedTo: greg@kroah.com
>         ReportedBy: v.vasaitis@sms.ed.ac.uk
> 
> 
> Most recent kernel where this bug did not occur:
> Distribution: Debian unstable
> Hardware Environment: nVidia nForce 570 Ultra OHCI/EHCI
> Software Environment: KDE 3.5.8
> Problem Description:
> 
>   On my system, for some reason KDE 3.5.8 prevents the kernel from
>   recognising
> properly my digital camera. If I'm not running KDE (I can be running X with
> some other environment, it doesn't matter) the camera is recognised fine,
> with
> messages like:
> 
> usb 2-6: new full speed USB device using ohci_hcd and address 10
> usb 2-6: configuration #1 chosen from 1 choice
> scsi14 : SCSI emulation for USB Mass Storage devices
> usb-storage: device found at 10
> usb-storage: waiting for device to settle before scanning
> scsi 14:0:0:0: Direct-Access     MATSHITA DMC-FZ7          0100 PQ: 0 ANSI: 2
> sd 14:0:0:0: [sdc] 1999872 512-byte hardware sectors (1024 MB)
> sd 14:0:0:0: [sdc] Write Protect is off
> sd 14:0:0:0: [sdc] Mode Sense: 04 00 00 00
> sd 14:0:0:0: [sdc] Assuming drive cache: write through
> sd 14:0:0:0: [sdc] 1999872 512-byte hardware sectors (1024 MB)
> sd 14:0:0:0: [sdc] Write Protect is off
> sd 14:0:0:0: [sdc] Mode Sense: 04 00 00 00
> sd 14:0:0:0: [sdc] Assuming drive cache: write through
>  sdc: sdc1
> sd 14:0:0:0: [sdc] Attached SCSI removable disk
> sd 14:0:0:0: Attached scsi generic sg3 type 0
> usb-storage: device scan complete
> 
> However, when KDE is running I get this instead:
> 
> usb 2-6: new full speed USB device using ohci_hcd and address 11
> usb 2-6: configuration #1 chosen from 1 choice
> scsi15 : SCSI emulation for USB Mass Storage devices
> usb-storage: device found at 11
> usb-storage: waiting for device to settle before scanning
> ttyS1: LSR safety check engaged!
> ttyS1: LSR safety check engaged!
> 
> This happens both for UMS mode (shown above) as well as for PTP mode -- my
> camera supports both.
> 
> Steps to reproduce:
> 

On Sun, 25 Nov 2007, Andrew Morton wrote:

> On Sun, 25 Nov 2007 16:38:49 -0800 (PST) bugme-daemon@bugzilla.kernel.org
> wrote:
> 
> > http://bugzilla.kernel.org/show_bug.cgi?id=9458
> > 
> >            Summary: digital camera not recognised properly by the kernel
> >                     when KDE is running

> > However, when KDE is running I get this instead:
> > 
> > usb 2-6: new full speed USB device using ohci_hcd and address 11
> > usb 2-6: configuration #1 chosen from 1 choice
> > scsi15 : SCSI emulation for USB Mass Storage devices
> > usb-storage: device found at 11
> > usb-storage: waiting for device to settle before scanning
> > ttyS1: LSR safety check engaged!
> > ttyS1: LSR safety check engaged!

Why assign this to the USB developers?  The bug doesn't have anything
to do with USB -- and what is that ttyS1 message doing there?  Is this
some sort of security framework violation?

Alan Stern

Reply-To: oliver@neukum.org

Am Montag 26 November 2007 schrieb Andrew Morton:
> > However, when KDE is running I get this instead:
> > 
> > usb 2-6: new full speed USB device using ohci_hcd and address 11
> > usb 2-6: configuration #1 chosen from 1 choice
> > scsi15 : SCSI emulation for USB Mass Storage devices
> > usb-storage: device found at 11
> > usb-storage: waiting for device to settle before scanning

What does "cat /sys/module/usb_storage/parameters/delay_use" say?

	Regards
		Oliver

On Sun, Nov 25, 2007 at 10:17:11PM -0500, Alan Stern wrote:
> On Sun, 25 Nov 2007, Andrew Morton wrote:
> 
> > On Sun, 25 Nov 2007 16:38:49 -0800 (PST) bugme-daemon@bugzilla.kernel.org
> wrote:
> > 
> > > http://bugzilla.kernel.org/show_bug.cgi?id=9458
> > > 
> > >            Summary: digital camera not recognised properly by the kernel
> > >                     when KDE is running
> 
> > > However, when KDE is running I get this instead:
> > > 
> > > usb 2-6: new full speed USB device using ohci_hcd and address 11
> > > usb 2-6: configuration #1 chosen from 1 choice
> > > scsi15 : SCSI emulation for USB Mass Storage devices
> > > usb-storage: device found at 11
> > > usb-storage: waiting for device to settle before scanning
> > > ttyS1: LSR safety check engaged!
> > > ttyS1: LSR safety check engaged!
> 
> Why assign this to the USB developers?  The bug doesn't have anything
> to do with USB -- and what is that ttyS1 message doing there?  Is this
> some sort of security framework violation?
> 
> Alan Stern

  It seemed like the most appropriate place to assign the bug to; feel
free to reassign. As for the ttyS1 message, indeed that's the most
puzzling bit, especially considering that my system doesn't even have
a ttyS1 (it's only got one serial port, ttyS0).

Oliver Neukum wrote:
> What does "cat /sys/module/usb_storage/parameters/delay_use" say?
> 
>         Regards
>                 Oliver
> 

  It's 5. But I'll stress again that this happens when the camera is
connected in PTP mode too, i.e. it doesn't seem to be UMS-specific.

Thanks,
Vasilis

Reply-To: oliver@neukum.org

Am Montag 26 November 2007 schrieb Vasilis Vasaitis:
> 

On Mon, 26 Nov 2007, Vasilis Vasaitis wrote:

>   It seemed like the most appropriate place to assign the bug to; feel
> free to reassign. As for the ttyS1 message, indeed that's the most
> puzzling bit, especially considering that my system doesn't even have
> a ttyS1 (it's only got one serial port, ttyS0).

All right.  What shows up in /proc/bus/usb/devices after you plug in 
the camera under KDE?  Note: not all distributions mount the filesystem 
containing that file; you may need to do it by hand:

	mount -t usbfs none /proc/bus/usb

Also, what shows up in the output from "ps -Awf"?

> > > ttyS1: LSR safety check engaged!
> > > ttyS1: LSR safety check engaged!
> 
> Why assign this to the USB developers?  The bug doesn't have anything
> to do with USB -- and what is that ttyS1 message doing there?  Is this
> some sort of security framework violation?

Its just serial debug info. Presumably ttyS1 got detected at this point
in time

On Mon, Nov 26, 2007 at 03:03:19PM +0000, Alan Cox wrote:
> > > > ttyS1: LSR safety check engaged!
> > > > ttyS1: LSR safety check engaged!
> > 
> > Why assign this to the USB developers?  The bug doesn't have anything
> > to do with USB -- and what is that ttyS1 message doing there?  Is this
> > some sort of security framework violation?
> 
> Its just serial debug info. Presumably ttyS1 got detected at this point
> in time

  Negative. These messages appear every time this happens, i.e.
everytime I plug in the camera while KDE is running. Generally two or
three of them.

On Mon, 26 Nov 2007, Vasilis Vasaitis wrote:

> On Mon, Nov 26, 2007 at 03:03:19PM +0000, Alan Cox wrote:
> > > > > ttyS1: LSR safety check engaged!
> > > > > ttyS1: LSR safety check engaged!
> > > 
> > > Why assign this to the USB developers?  The bug doesn't have anything
> > > to do with USB -- and what is that ttyS1 message doing there?  Is this
> > > some sort of security framework violation?
> > 
> > Its just serial debug info. Presumably ttyS1 got detected at this point
> > in time
> 
>   Negative. These messages appear every time this happens, i.e.
> everytime I plug in the camera while KDE is running. Generally two or
> three of them.

It certainly sounds like one of the programs in KDE is doing something 
to try and access ttyS1, while at the same time preventing usb-storage 
from working correctly.

You could try enabling the usbfs_snoop=y module parameter for usbcore.  
Maybe the dmesg log will show which program is messing things up.

Alan Stern

Created attachment 13766 [details]
dmesg output (well, kernel log file actually) with usbcore.usbfs_snoop=y

On Mon, Nov 26, 2007 at 09:57:30AM -0500, Alan Stern wrote:
> 
> All right.  What shows up in /proc/bus/usb/devices after you plug in 
> the camera under KDE?  Note: not all distributions mount the filesystem 
> containing that file; you may need to do it by hand:
> 
>       mount -t usbfs none /proc/bus/usb

  I get this entry:

T:  Bus=02 Lev=01 Prnt=01 Port=05 Cnt=02 Dev#= 16 Spd=12  MxCh= 0
D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=04da ProdID=2372 Rev= 0.10
S:  Manufacturer=Panasonic
S:  Product=DMC-FZ7
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=  2mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=(none)
E:  Ad=01(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms

> Also, what shows up in the output from "ps -Awf"?

  A set of kioslaves, here's one capture (not very helpful I know):

mod      14936 18636  0 01:45 ?        00:00:00 kio_system [kdeinit] system /tmp/ksocket-mod/klauncherXZ7X  
mod      14937 18636  0 01:45 ?        00:00:00 kio_media [kdeinit] media /tmp/ksocket-mod/klauncherXZ7Xhb  
mod      14938 18636  0 01:45 ?        00:00:00 kio_file [kdeinit] file /tmp/ksocket-mod/klauncherXZ7Xhb.s  
mod      14939 18636  2 01:45 ?        00:00:00 kio_kamera [kdeinit] camera /tmp/ksocket-mod/klauncherXZ7X  
mod      14940 18636  2 01:45 ?        00:00:00 kio_kamera [kdeinit] camera /tmp/ksocket-mod/klauncherXZ7X  
mod      14946 18636  0 01:45 ?        00:00:00 kio_media [kdeinit] media /tmp/ksocket-mod/klauncherXZ7Xhb  
mod      14947 18636  0 01:45 ?        00:00:00 kio_file [kdeinit] file /tmp/ksocket-mod/klauncherXZ7Xhb.s  
mod      14948 18636  1 01:45 ?        00:00:00 kio_kamera [kdeinit] camera /tmp/ksocket-mod/klauncherXZ7X  

  I've also tried your usbcore.usbfs_snoop=y suggestion, and I've
attached the kernel output when it's turned on to the bug page. Not
sure if it's illuminating in any way. I'll also try Oliver's
CONFIG_USB_DEBUG suggestion as soon as I find some time.

Thanks,
Vasilis

On Tue, 27 Nov 2007, Vasilis Vasaitis wrote:

> On Mon, Nov 26, 2007 at 09:57:30AM -0500, Alan Stern wrote:
> > 
> > All right.  What shows up in /proc/bus/usb/devices after you plug in 
> > the camera under KDE?  Note: not all distributions mount the filesystem 
> > containing that file; you may need to do it by hand:
> > 
> >     mount -t usbfs none /proc/bus/usb
> 
>   I get this entry:
> 
> T:  Bus=02 Lev=01 Prnt=01 Port=05 Cnt=02 Dev#= 16 Spd=12  MxCh= 0
> D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
> P:  Vendor=04da ProdID=2372 Rev= 0.10
> S:  Manufacturer=Panasonic
> S:  Product=DMC-FZ7
> C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=  2mA
> I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=(none)
> E:  Ad=01(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
> E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms

The key item here is the "Driver=(none)" field.  Something has unbound 
usb-storage from the device, probably via usbfs.

> > Also, what shows up in the output from "ps -Awf"?
> 
>   A set of kioslaves, here's one capture (not very helpful I know):
> 
> mod      14936 18636  0 01:45 ?        00:00:00 kio_system [kdeinit] system
> /tmp/ksocket-mod/klauncherXZ7X  
> mod      14937 18636  0 01:45 ?        00:00:00 kio_media [kdeinit] media
> /tmp/ksocket-mod/klauncherXZ7Xhb  
> mod      14938 18636  0 01:45 ?        00:00:00 kio_file [kdeinit] file
> /tmp/ksocket-mod/klauncherXZ7Xhb.s  
> mod      14939 18636  2 01:45 ?        00:00:00 kio_kamera [kdeinit] camera
> /tmp/ksocket-mod/klauncherXZ7X  
> mod      14940 18636  2 01:45 ?        00:00:00 kio_kamera [kdeinit] camera
> /tmp/ksocket-mod/klauncherXZ7X  
> mod      14946 18636  0 01:45 ?        00:00:00 kio_media [kdeinit] media
> /tmp/ksocket-mod/klauncherXZ7Xhb  
> mod      14947 18636  0 01:45 ?        00:00:00 kio_file [kdeinit] file
> /tmp/ksocket-mod/klauncherXZ7Xhb.s  
> mod      14948 18636  1 01:45 ?        00:00:00 kio_kamera [kdeinit] camera
> /tmp/ksocket-mod/klauncherXZ7X  

I was looking for a usb-storage process, but it's evident that we won't 
see one.

>   I've also tried your usbcore.usbfs_snoop=y suggestion, and I've
> attached the kernel output when it's turned on to the bug page. Not
> sure if it's illuminating in any way. I'll also try Oliver's
> CONFIG_USB_DEBUG suggestion as soon as I find some time.

Boy, that output is hard to interpret.  It leads me to wonder if the 
dump is being done correctly...  And unfortunately it doesn't include 
the name of the current process.  Well, we can fix that.

If you edit the kernel source file drivers/usb/core/devio.c, near the
start you'll see a definition of the snoop macro.  Change it as
follows:

 #define snoop(dev, format, arg...)                              \
         do {                                                    \
                 if (usbfs_snoop)                                \
                         dev_info( dev , "%s: " format ,         \
				current->comm , ## arg);         \
         } while (0)

That will include the process name in the log entries.

It wouldn't be surprising to find that the offending process is one of
those listed above, like kio_camera.  It may think your camera is in
PTP mode even when that's not the case.

Alan Stern

Created attachment 13771 [details]
dmesg output for UMS with usbcore.usbfs_snoop=y (patched) and CONFIG_USB_DEBUG=y

Created attachment 13772 [details]
dmesg output for PTP with usbcore.usbfs_snoop=y (patched) and CONFIG_USB_DEBUG=y

On Mon, Nov 26, 2007 at 09:46:23PM -0500, Alan Stern wrote:

..[edited]..

> The key item here is the "Driver=(none)" field.  Something has unbound 
> usb-storage from the device, probably via usbfs.

> I was looking for a usb-storage process, but it's evident that we won't 
> see one.

> >   I've also tried your usbcore.usbfs_snoop=y suggestion, and I've
> > attached the kernel output when it's turned on to the bug page. Not
> > sure if it's illuminating in any way. I'll also try Oliver's
> > CONFIG_USB_DEBUG suggestion as soon as I find some time.
> 
> Boy, that output is hard to interpret.  It leads me to wonder if the 
> dump is being done correctly...  And unfortunately it doesn't include 
> the name of the current process.  Well, we can fix that.

> It wouldn't be surprising to find that the offending process is one of
> those listed above, like kio_camera.  It may think your camera is in
> PTP mode even when that's not the case.

  OK, I've patched the kernel as you suggested and also enabled
CONFIG_USB_DEBUG. I've attached logs on the bug page both for the UMS
and the PTP case. Well, from the UMS case, I guess you won't be
surprised to see these in the output:

Nov 28 01:18:28 arakis kernel: usb 2-6: kio_kamera: usbdev_ioctl: GETDRIVER
Nov 28 01:18:28 arakis kernel: usb 2-6: kio_kamera: usbdev_ioctl: IOCTL
Nov 28 01:18:28 arakis kernel: usb-storage 2-6:1.0: disconnect by usbfs

  Actually this time I did manage to get it to work in the PTP case
(embarrassing), with programs like gphoto2 or KDE's own digikam. So I
guess it's mostly the UMS case that KDE is screwing up (though it
doesn't pop up the usual "device connected" dialog in either case).

  So I guess it's not really a kernel bug eh? Thanks for the debugging
help though.

Cheers,
Vasilis

On Wed, 28 Nov 2007, Vasilis Vasaitis wrote:

>   So I guess it's not really a kernel bug eh? Thanks for the debugging
> help though.

You're welcome.  You can mark this bug report REJECTED and start 
complaining to the KDE developers.  It looks like kio_kamera assumes 
the camera is always in PTP mode, even when it is really in 
mass-storage mode.

Alan Stern