webcam problem after suspend/hibernate
Mohamed Ikbel Boulabiar
After suspend/resume, I have my webcam no more working.
The /dev/video0 file still exist, but the webcam won't be used until I do this :
rmmod � � uvcvideo
modprobe uvcvideo
(2.6.31.8-0.1)
This is may be caused by a bug somewhere.
These are more information about my hardware :
I have Microdia webcam
`lsusb`
Bus 001 Device 004: ID 0c45:62c0 Microdia Sonix USB 2.0 Camera
on openSUSE 11.2�`uname -a`
Linux linux-l365 2.6.31.8-0.1-desktop #1 SMP PREEMPT 2009-12-15
23:55:40 +0100 i686 i686 i386 GNU/Linux
`hwinfo --usb`
: USB 00.0: 0000 Unclassified device
��[Created at usb.122]
��UDI: /org/freedesktop/Hal/devices/usb_device_c45_62c0_1_3_2_1_7_if0_logicaldev_input
��Unique ID: Uc5H.F0c0EBqBP10
��Parent ID: k4bc.9T1GDCLyFd9
��SysFS ID: /devices/pci0000:00/0000:00:1d.7/usb1/1-4/1-4:1.0
��SysFS BusID: 1-4:1.0
��Hardware Class: unknown
��Model: "Microdia LG Webcam"
��Hotplug: USB
��Vendor: usb 0x0c45 "Microdia"
��Device: usb 0x62c0 "LG Webcam"
��Revision: "32.17"
��Serial ID: "1.3.2.1.7"
��Driver: "uvcvideo"
��Driver Modules: "uvcvideo"
��Device File: /dev/input/event8
��Device Files: /dev/input/event8, /dev/char/13:72,
/dev/input/by-id/usb-LG_Innotek_LG_Webcam_1.3.2.1.7-event-if00,
/dev/input/by-path/pci-0000:00:1d.7-usb-0:4:1.0-event
��Device Number: char 13:72
��Speed: 480 Mbps
��Module Alias: "usb:v0C45p62C0d3217dcEFdsc02dp01ic0Eisc01ip00"
��Driver Info #0:
�� �Driver Status: uvcvideo is active
�� �Driver Activation Cmd: "modprobe uvcvideo"
��Config Status: cfg=no, avail=yes, need=no, active=unknown
��Attached to: #4 (Hub)
If there is a scenario you propose me to do to detect from where comes
the problem, I can apply it.
Thanks,
ik.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Laurent Pinchart
On Tuesday 30 March 2010 23:55:38 Mohamed Ikbel Boulabiar wrote:
> Hi,
>
> After suspend/resume, I have my webcam no more working.
> The /dev/video0 file still exist, but the webcam won't be used until I do
> this : rmmod uvcvideo
> modprobe uvcvideo
> (2.6.31.8-0.1)
>
> This is may be caused by a bug somewhere.
> These are more information about my hardware :
>
> I have Microdia webcam
> `lsusb`
> Bus 001 Device 004: ID 0c45:62c0 Microdia Sonix USB 2.0 Camera
>
> on openSUSE 11.2 `uname -a`
> Linux linux-l365 2.6.31.8-0.1-desktop #1 SMP PREEMPT 2009-12-15
> 23:55:40 +0100 i686 i686 i386 GNU/Linux
>
> `hwinfo --usb`
>
> : USB 00.0: 0000 Unclassified device
>
> [Created at usb.122]
> UDI:
> /org/freedesktop/Hal/devices/usb_device_c45_62c0_1_3_2_1_7_if0_logicaldev_
> input Unique ID: Uc5H.F0c0EBqBP10
Could you please post the messages printed by the uvcvideo driver and USB core
to the kernel log when you suspend and resume your system ? Thanks.
--
Regards,
Laurent Pinchart
Mohamed Ikbel Boulabiar
Do you mean the dmesg output ?
A full dmesg is included in this address :
http://pastebin.com/8XU619Uk
Not in all suspend/hibernate the problem comes, only in some of them
and this included dmesg output is just after a non working case of
webcam fault.
I also have found this in `/var/log/messages | grep uvcvideo`
Mar 31 00:31:16 linux-l365 kernel: [399905.714743] usbcore:
deregistering interface driver uvcvideo
Mar 31 00:31:24 linux-l365 kernel: [399914.121386] uvcvideo: Found UVC
1.00 device LG Webcam (0c45:62c0)
Mar 31 00:31:24 linux-l365 kernel: [399914.135661] usbcore: registered
new interface driver uvcvideo
and in `cat /proc/modules | grep uvcvideo`
uvcvideo 65900 0 - Live 0xfa386000
videodev 39168 1 uvcvideo, Live 0xf8244000
v4l1_compat 16004 2 uvcvideo,videodev, Live 0xf822f000
And thanks in advance for you help.
Pavel Machek
> Do you mean the dmesg output ?
> A full dmesg is included in this address :
> http://pastebin.com/8XU619Uk
> Not in all suspend/hibernate the problem comes, only in some of them
> and this included dmesg output is just after a non working case of
> webcam fault.
>
>
> I also have found this in `/var/log/messages | grep uvcvideo`
> Mar 31 00:31:16 linux-l365 kernel: [399905.714743] usbcore:
> deregistering interface driver uvcvideo
> Mar 31 00:31:24 linux-l365 kernel: [399914.121386] uvcvideo: Found UVC
> 1.00 device LG Webcam (0c45:62c0)
> Mar 31 00:31:24 linux-l365 kernel: [399914.135661] usbcore: registered
> new interface driver uvcvideo
Also try unloading uvcvideo before suspend and reloading it after
resume...
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Philippe Troin
> > Do you mean the dmesg output ?
> > A full dmesg is included in this address :
> > http://pastebin.com/8XU619Uk
> > Not in all suspend/hibernate the problem comes, only in some of them
> > and this included dmesg output is just after a non working case of
> > webcam fault.
> >
> >
> > I also have found this in `/var/log/messages | grep uvcvideo`
> > Mar 31 00:31:16 linux-l365 kernel: [399905.714743] usbcore:
> > deregistering interface driver uvcvideo
> > Mar 31 00:31:24 linux-l365 kernel: [399914.121386] uvcvideo: Found UVC
> > 1.00 device LG Webcam (0c45:62c0)
> > Mar 31 00:31:24 linux-l365 kernel: [399914.135661] usbcore: registered
> > new interface driver uvcvideo
>
> Also try unloading uvcvideo before suspend and reloading it after
> resume...
I have a similar problem with a Creative Optia webcam.
I have found that removing the ehci_hcd module and reinserting it
fixes the problem.
If your kernel ships with ehci_hcd built-in (F11 and later), the
script included also fixes the problem (it rebind the device).
Of course, I'd love to see this issue fixed.
Phil.
Script: /etc/pm/sleep.d/50kickuvc
#!/bin/sh
case "$1" in
resume|thaw)
cd /sys/bus/usb/drivers/uvcvideo || exit 1
devices=''
for i in [0-9]*-[0-9]*:*
do
[ -L "$i" ] || break
saved_IFS="$IFS"
IFS=:
set -- $i
IFS="$saved_IFS"
found=no
for j in $devices
do
if [ "$j" = "$1" ]
then
found=yes
fi
done
if [ "$found" = no ]
then
devices="$devices $1"
fi
done
if [ "$devices" != "" ]
then
cd /sys/bus/usb/drivers/usb || exit 1
for i in $devices
do
echo $i > unbind
sleep 1
echo $i > bind
done
fi
;;
esac
Pavel Machek
> > > Do you mean the dmesg output ?
> > > A full dmesg is included in this address :
> > > http://pastebin.com/8XU619Uk
> > > Not in all suspend/hibernate the problem comes, only in some of them
> > > and this included dmesg output is just after a non working case of
> > > webcam fault.
> > >
> > >
> > > I also have found this in `/var/log/messages | grep uvcvideo`
> > > Mar 31 00:31:16 linux-l365 kernel: [399905.714743] usbcore:
> > > deregistering interface driver uvcvideo
> > > Mar 31 00:31:24 linux-l365 kernel: [399914.121386] uvcvideo: Found UVC
> > > 1.00 device LG Webcam (0c45:62c0)
> > > Mar 31 00:31:24 linux-l365 kernel: [399914.135661] usbcore: registered
> > > new interface driver uvcvideo
> >
> > Also try unloading uvcvideo before suspend and reloading it after
> > resume...
>
> I have a similar problem with a Creative Optia webcam.
>
> I have found that removing the ehci_hcd module and reinserting it
> fixes the problem.
>
> If your kernel ships with ehci_hcd built-in (F11 and later), the
> script included also fixes the problem (it rebind the device).
>
> Of course, I'd love to see this issue fixed.
If unload/reload of uvcvideo helps, it is most likely problem in that.
If unload/reload of ehci_hcd is needed, it is most likely ehci problem.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Philippe Troin
My testing shows that:
1. If I remove uvcvideo BEFORE suspend and reinsert it after resume,
it works. However, I cannot always rmmod uvcvideo before suspend
as it may be in use.
2. As a work around, removing ehci_hcd and reinserting ehci_hcd upon
resume works as well.
3. Since my distribution's kernels come with ehci_hcd built into the
kernel, and I cannot do #2 any more, I also found that unbinding
and rebinding the device (with the script I sent earlier on) works
as well.
I think uvcvideo is failing to reinitialize the camera on resume, and
forcing an uvcvideo "reset" with either of these three methods kicks
uvcvideo into working again.
Phil.
Pavel Machek
> > If unload/reload of uvcvideo helps, it is most likely problem in that.
> >
> > If unload/reload of ehci_hcd is needed, it is most likely ehci problem.
>
> My testing shows that:
>
> 1. If I remove uvcvideo BEFORE suspend and reinsert it after resume,
> it works. However, I cannot always rmmod uvcvideo before suspend
> as it may be in use.
>
> 2. As a work around, removing ehci_hcd and reinserting ehci_hcd upon
> resume works as well.
>
> 3. Since my distribution's kernels come with ehci_hcd built into the
> kernel, and I cannot do #2 any more, I also found that unbinding
> and rebinding the device (with the script I sent earlier on) works
> as well.
>
> I think uvcvideo is failing to reinitialize the camera on resume, and
> forcing an uvcvideo "reset" with either of these three methods kicks
> uvcvideo into working again.
Ok, that puts the problem firmly into uvcvideo area.
Try changing its _resume routine to whatever is done on device
unplug... it should be rather easy, and is quite close to "correct"
solution.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Mohamed Ikbel Boulabiar
> Ok, that puts the problem firmly into uvcvideo area.
>
> Try changing its _resume routine to whatever is done on device
> unplug... it should be rather easy, and is quite close to "correct"
> solution.
I am waiting to try that.
If I always need to rmmod/modprobe everytime, that is meaning that
something is kept messed somewhere in memory and should be cleaned by
restart (reinitialize ?) the device.
Mohamed-Ikbel
Pavel Machek
> Hi !
>
> > Ok, that puts the problem firmly into uvcvideo area.
> >
> > Try changing its _resume routine to whatever is done on device
> > unplug... it should be rather easy, and is quite close to "correct"
> > solution.
>
> I am waiting to try that.
>
> If I always need to rmmod/modprobe everytime, that is meaning that
> something is kept messed somewhere in memory and should be cleaned by
> restart (reinitialize ?) the device.
Yes. And it also means that problem is within the stuff being rmmoded/insmoded.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Laurent Pinchart
> Hi!
>
> > > If unload/reload of uvcvideo helps, it is most likely problem in that.
> > >
> > > If unload/reload of ehci_hcd is needed, it is most likely ehci problem.
> >
> > My testing shows that:
> > 1. If I remove uvcvideo BEFORE suspend and reinsert it after resume,
> >
> > it works. However, I cannot always rmmod uvcvideo before suspend
> > as it may be in use.
> >
> > 2. As a work around, removing ehci_hcd and reinserting ehci_hcd upon
> >
> > resume works as well.
> >
> > 3. Since my distribution's kernels come with ehci_hcd built into the
> >
> > kernel, and I cannot do #2 any more, I also found that unbinding
> > and rebinding the device (with the script I sent earlier on) works
> > as well.
> >
> > I think uvcvideo is failing to reinitialize the camera on resume, and
> > forcing an uvcvideo "reset" with either of these three methods kicks
> > uvcvideo into working again.
>
> Ok, that puts the problem firmly into uvcvideo area.
No, it doesn't.
First of all, the dmesg output available on pastebin.com is difficult to
understand. As it seems you perform several suspend/resume cycles there.
Mohamed, could you please
- clear the kernel log ('dmesg -c' as root)
- suspend and resume your system
- post the kernel log content ('dmesg')
- clear the kernel log
- try to use your webcam with whatever test software your prefer
- describe the failure (application error messages, ...)
- post the kernel log content
> Try changing its _resume routine to whatever is done on device
> unplug... it should be rather easy, and is quite close to "correct"
> solution.
That's not a solution. Devices are supposed to resume properly without being
reset. The camera might be crashing, or the USB core might be doing something
wrong, requiring some kind of reset. I'd like to diagnose the problem
correctly before trying to fix it.
--
Regards,
Laurent Pinchart
Pavel Machek
> > > My testing shows that:
> > > 1. If I remove uvcvideo BEFORE suspend and reinsert it after resume,
> > >
> > > it works. However, I cannot always rmmod uvcvideo before suspend
> > > as it may be in use.
...
> > > I think uvcvideo is failing to reinitialize the camera on resume, and
> > > forcing an uvcvideo "reset" with either of these three methods kicks
> > > uvcvideo into working again.
> >
> > Ok, that puts the problem firmly into uvcvideo area.
>
> No, it doesn't.
I believe that the fact that rmmod/insmod fixes it means that problem
is in the driver (and not in ehci or something like that).
> First of all, the dmesg output available on pastebin.com is difficult to
> understand. As it seems you perform several suspend/resume cycles there.
> Mohamed, could you please
>
> - clear the kernel log ('dmesg -c' as root)
> - suspend and resume your system
> - post the kernel log content ('dmesg')
> - clear the kernel log
> - try to use your webcam with whatever test software your prefer
> - describe the failure (application error messages, ...)
> - post the kernel log content
Good idea.
> > Try changing its _resume routine to whatever is done on device
> > unplug... it should be rather easy, and is quite close to "correct"
> > solution.
>
> That's not a solution. Devices are supposed to resume properly without being
> reset. The camera might be crashing, or the USB core might be doing something
> wrong, requiring some kind of reset. I'd like to diagnose the problem
> correctly before trying to fix it.
Ok. (You are right that simulating rmmod/insmod is not the same as
proper suspend/resume support, but I still guess it would help with
debugging.)
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html