Hi,
I'm looking at the linux uvc driver, and noticed after resuming my
notebook it deadlocks at usb_set_interface.
The linux kernel version on that notebook is 2.6.21.4, I searched
around and haven't found any such bugreports.
I wonder if anyone has ever heard about such a problem?
I'm digging closer into that issue now..
thanks,
Markus
Markus Rechberger wrote:
> Hi,
>
> I'm looking at the linux uvc driver, and noticed after resuming my
..
Pardon me.. what is the "uvc" driver? Which module/source file is that?
Thanks
> notebook it deadlocks at usb_set_interface.
> The linux kernel version on that notebook is 2.6.21.4, I searched
> around and haven't found any such bugreports.
> I wonder if anyone has ever heard about such a problem?
>
> I'm digging closer into that issue now..
>
> thanks,
> Markus
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On 11/21/07, Mark Lord <[email protected]> wrote:
> Markus Rechberger wrote:
> > Hi,
> >
> > I'm looking at the linux uvc driver, and noticed after resuming my
> ..
>
> Pardon me.. what is the "uvc" driver? Which module/source file is that?
>
http://linux-uvc.berlios.de/ it's not yet included in the kernel
sources although many distributions already ship it.
A "dry" run putting the device into sleep mode works fine (I added a
proc interface for calling those suspend/resume function).
Markus
On 11/21/07, Markus Rechberger <[email protected]> wrote:
> On 11/21/07, Mark Lord <[email protected]> wrote:
> > Markus Rechberger wrote:
> > > Hi,
> > >
> > > I'm looking at the linux uvc driver, and noticed after resuming my
> > ..
> >
> > Pardon me.. what is the "uvc" driver? Which module/source file is that?
> >
>
> http://linux-uvc.berlios.de/ it's not yet included in the kernel
> sources although many distributions already ship it.
> A "dry" run putting the device into sleep mode works fine (I added a
> proc interface for calling those suspend/resume function).
>
it's not just usb_set_interface that hangs actually.
It seems to hang at
wait_event(usb_kill_urb_queue, atomic_read(&urb->use_count) == 0);
in drivers/usb/core/urb.c after resuming. I disabled access to the usb
subsystem in the uvc driver, although connecting any other usb storage
fails too, just at the same point.
The hardware is:
00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) USB UHCI #1 (rev 04) (8086:2658)
Markus
Am Mittwoch 21 November 2007 schrieb Markus Rechberger:
> On 11/21/07, Markus Rechberger <[email protected]> wrote:
> > On 11/21/07, Mark Lord <[email protected]> wrote:
> > > Markus Rechberger wrote:
> > > > Hi,
> > > >
> > > > I'm looking at the linux uvc driver, and noticed after resuming my
> > > ..
> > >
> > > Pardon me.. what is the "uvc" driver? ?Which module/source file is that?
> > >
> >
> > http://linux-uvc.berlios.de/ it's not yet included in the kernel
> > sources although many distributions already ship it.
> > A "dry" run putting the device into sleep mode works fine (I added a
> > proc interface for calling those suspend/resume function).
> >
>
> it's not just usb_set_interface that hangs actually.
> It seems to hang at
>
> wait_event(usb_kill_urb_queue, atomic_read(&urb->use_count) == 0);
>
> in drivers/usb/core/urb.c after resuming. I disabled access to the usb
> subsystem in the uvc driver, although connecting any other usb storage
> fails too, just at the same point.
Which URB is usb_kill_urb() called for?
Regards
Oliver
On 11/21/07, Oliver Neukum <[email protected]> wrote:
> Am Mittwoch 21 November 2007 schrieb Markus Rechberger:
> > On 11/21/07, Markus Rechberger <[email protected]> wrote:
> > > On 11/21/07, Mark Lord <[email protected]> wrote:
> > > > Markus Rechberger wrote:
> > > > > Hi,
> > > > >
> > > > > I'm looking at the linux uvc driver, and noticed after resuming my
> > > > ..
> > > >
> > > > Pardon me.. what is the "uvc" driver? Which module/source file is
> that?
> > > >
> > >
> > > http://linux-uvc.berlios.de/ it's not yet included in the kernel
> > > sources although many distributions already ship it.
> > > A "dry" run putting the device into sleep mode works fine (I added a
> > > proc interface for calling those suspend/resume function).
> > >
> >
> > it's not just usb_set_interface that hangs actually.
> > It seems to hang at
> >
> > wait_event(usb_kill_urb_queue, atomic_read(&urb->use_count) == 0);
> >
> > in drivers/usb/core/urb.c after resuming. I disabled access to the usb
> > subsystem in the uvc driver, although connecting any other usb storage
> > fails too, just at the same point.
>
> Which URB is usb_kill_urb() called for?
>
it's the usb_control_message which calls usb_kill_urb if I haven't got
it wrong. (if you're looking for some other information please let me
know)
Although, I got a bit further with it. The error seems to happen
earlier already.
If I load the driver, and do not access the device after suspending
all usb_control commands fail with -71 eproto.
Reloading the driver doesn't help at tht point, only reconnecting the
device does.
The data is transfered using bulk transfer.
Markus
On 11/21/07, Markus Rechberger <[email protected]> wrote:
> On 11/21/07, Oliver Neukum <[email protected]> wrote:
> > Am Mittwoch 21 November 2007 schrieb Markus Rechberger:
> > > On 11/21/07, Markus Rechberger <[email protected]> wrote:
> > > > On 11/21/07, Mark Lord <[email protected]> wrote:
> > > > > Markus Rechberger wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I'm looking at the linux uvc driver, and noticed after resuming my
> > > > > ..
> > > > >
> > > > > Pardon me.. what is the "uvc" driver? Which module/source file is
> > that?
> > > > >
> > > >
> > > > http://linux-uvc.berlios.de/ it's not yet included in the kernel
> > > > sources although many distributions already ship it.
> > > > A "dry" run putting the device into sleep mode works fine (I added a
> > > > proc interface for calling those suspend/resume function).
> > > >
> > >
> > > it's not just usb_set_interface that hangs actually.
> > > It seems to hang at
> > >
> > > wait_event(usb_kill_urb_queue, atomic_read(&urb->use_count) == 0);
> > >
> > > in drivers/usb/core/urb.c after resuming. I disabled access to the usb
> > > subsystem in the uvc driver, although connecting any other usb storage
> > > fails too, just at the same point.
> >
> > Which URB is usb_kill_urb() called for?
> >
>
> it's the usb_control_message which calls usb_kill_urb if I haven't got
> it wrong. (if you're looking for some other information please let me
> know)
> Although, I got a bit further with it. The error seems to happen
> earlier already.
> If I load the driver, and do not access the device after suspending
> all usb_control commands fail with -71 eproto.
>
> Reloading the driver doesn't help at tht point, only reconnecting the
> device does.
>
> The data is transfered using bulk transfer.
>
Do you know any good way for performing a softreset within the driver?
The video application should get a continuous datastream after
resuming the notebook, so the driver shouldn't be unloaded.
The driver also keeps a list of previous camera settings which should
be set up again after resuming. Stopping the video application and
reattaching the device using ACPI (this board supports reconnecting
the device using ACPI) should be avoided.
Markus
Hi,
On Wed, 21 Nov 2007 15:37:20 +0100, "Markus Rechberger"
<[email protected]> wrote:
> On 11/21/07, Oliver Neukum <[email protected]> wrote:
>> Am Mittwoch 21 November 2007 schrieb Markus Rechberger:
>> > On 11/21/07, Markus Rechberger <[email protected]> wrote:
>> > > On 11/21/07, Mark Lord <[email protected]> wrote:
>> > > > Markus Rechberger wrote:
>> > > > > Hi,
>> > > > >
>> > > > > I'm looking at the linux uvc driver, and noticed after resuming
> my
>> > > > ..
>> > > >
>> > > > Pardon me.. what is the "uvc" driver? Which module/source file is
>> that?
>> > > >
>> > >
>> > > http://linux-uvc.berlios.de/ it's not yet included in the kernel
>> > > sources although many distributions already ship it.
>> > > A "dry" run putting the device into sleep mode works fine (I added a
>> > > proc interface for calling those suspend/resume function).
>> > >
>> >
>> > it's not just usb_set_interface that hangs actually.
>> > It seems to hang at
>> >
>> > wait_event(usb_kill_urb_queue, atomic_read(&urb->use_count) == 0);
>> >
>> > in drivers/usb/core/urb.c after resuming. I disabled access to the usb
>> > subsystem in the uvc driver, although connecting any other usb storage
>> > fails too, just at the same point.
>>
>> Which URB is usb_kill_urb() called for?
>>
>
> it's the usb_control_message which calls usb_kill_urb if I haven't got
> it wrong. (if you're looking for some other information please let me
> know)
> Although, I got a bit further with it. The error seems to happen
> earlier already.
> If I load the driver, and do not access the device after suspending
> all usb_control commands fail with -71 eproto.
This device shouldn't be suspended. AFAIK it should have auto_suspend
disabled
by default.
Try adding this device to drivers/usb/core/quirks.c with
USB_QUIRK_NO_AUTOSUSPEND flag set. Something like:
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index d42c561..729eb4b 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -45,6 +45,9 @@ static const struct usb_device_id usb_quirk_list[] = {
/* SKYMEDI USB_DRIVE */
{ USB_DEVICE(0x1516, 0x8628), .driver_info = USB_QUIRK_RESET_RESUME
},
+ /* Your device */
+ { USB_DEVICE(0x0000, 0x0000), .driver_info =
USB_QUIRK_NO_AUTOSUSPEND },
+
{ } /* terminating entry must be last */
};
>
> Reloading the driver doesn't help at tht point, only reconnecting the
> device does.
>
> The data is transfered using bulk transfer.
>
> Markus
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Best Regards,
Felipe Balbi
http://felipebalbi.com
[email protected]
On 11/21/07, Markus Rechberger <[email protected]> wrote:
> On 11/21/07, Markus Rechberger <[email protected]> wrote:
> > On 11/21/07, Oliver Neukum <[email protected]> wrote:
> > > Am Mittwoch 21 November 2007 schrieb Markus Rechberger:
> > > > On 11/21/07, Markus Rechberger <[email protected]> wrote:
> > > > > On 11/21/07, Mark Lord <[email protected]> wrote:
> > > > > > Markus Rechberger wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > I'm looking at the linux uvc driver, and noticed after resuming
> my
> > > > > > ..
> > > > > >
> > > > > > Pardon me.. what is the "uvc" driver? Which module/source file is
> > > that?
> > > > > >
> > > > >
> > > > > http://linux-uvc.berlios.de/ it's not yet included in the kernel
> > > > > sources although many distributions already ship it.
> > > > > A "dry" run putting the device into sleep mode works fine (I added a
> > > > > proc interface for calling those suspend/resume function).
> > > > >
> > > >
> > > > it's not just usb_set_interface that hangs actually.
> > > > It seems to hang at
> > > >
> > > > wait_event(usb_kill_urb_queue, atomic_read(&urb->use_count) == 0);
> > > >
> > > > in drivers/usb/core/urb.c after resuming. I disabled access to the usb
> > > > subsystem in the uvc driver, although connecting any other usb storage
> > > > fails too, just at the same point.
> > >
> > > Which URB is usb_kill_urb() called for?
> > >
> >
> > it's the usb_control_message which calls usb_kill_urb if I haven't got
> > it wrong. (if you're looking for some other information please let me
> > know)
> > Although, I got a bit further with it. The error seems to happen
> > earlier already.
> > If I load the driver, and do not access the device after suspending
> > all usb_control commands fail with -71 eproto.
> >
> > Reloading the driver doesn't help at tht point, only reconnecting the
> > device does.
> >
> > The data is transfered using bulk transfer.
> >
>
> Do you know any good way for performing a softreset within the driver?
> The video application should get a continuous datastream after
> resuming the notebook, so the driver shouldn't be unloaded.
> The driver also keeps a list of previous camera settings which should
> be set up again after resuming. Stopping the video application and
> reattaching the device using ACPI (this board supports reconnecting
> the device using ACPI) should be avoided.
>
ok usb_reset_device() did the job after resuming. First problem solved.
Markus
On Wed, 21 Nov 2007 15:42:43 +0100, "Markus Rechberger"
<[email protected]> wrote:
> On 11/21/07, Markus Rechberger <[email protected]> wrote:
>> On 11/21/07, Oliver Neukum <[email protected]> wrote:
>> > Am Mittwoch 21 November 2007 schrieb Markus Rechberger:
>> > > On 11/21/07, Markus Rechberger <[email protected]> wrote:
>> > > > On 11/21/07, Mark Lord <[email protected]> wrote:
>> > > > > Markus Rechberger wrote:
>> > > > > > Hi,
>> > > > > >
>> > > > > > I'm looking at the linux uvc driver, and noticed after
> resuming my
>> > > > > ..
>> > > > >
>> > > > > Pardon me.. what is the "uvc" driver? Which module/source file
> is
>> > that?
>> > > > >
>> > > >
>> > > > http://linux-uvc.berlios.de/ it's not yet included in the kernel
>> > > > sources although many distributions already ship it.
>> > > > A "dry" run putting the device into sleep mode works fine (I added
> a
>> > > > proc interface for calling those suspend/resume function).
>> > > >
>> > >
>> > > it's not just usb_set_interface that hangs actually.
>> > > It seems to hang at
>> > >
>> > > wait_event(usb_kill_urb_queue, atomic_read(&urb->use_count) == 0);
>> > >
>> > > in drivers/usb/core/urb.c after resuming. I disabled access to the
> usb
>> > > subsystem in the uvc driver, although connecting any other usb
> storage
>> > > fails too, just at the same point.
>> >
>> > Which URB is usb_kill_urb() called for?
>> >
>>
>> it's the usb_control_message which calls usb_kill_urb if I haven't got
>> it wrong. (if you're looking for some other information please let me
>> know)
>> Although, I got a bit further with it. The error seems to happen
>> earlier already.
>> If I load the driver, and do not access the device after suspending
>> all usb_control commands fail with -71 eproto.
>>
>> Reloading the driver doesn't help at tht point, only reconnecting the
>> device does.
>>
>> The data is transfered using bulk transfer.
>>
>
> Do you know any good way for performing a softreset within the driver?
> The video application should get a continuous datastream after
> resuming the notebook, so the driver shouldn't be unloaded.
> The driver also keeps a list of previous camera settings which should
> be set up again after resuming. Stopping the video application and
> reattaching the device using ACPI (this board supports reconnecting
> the device using ACPI) should be avoided.
When you suspend, you cut off vbus (afaik, correct me if I'm wrong), which
means your device will get disconnected. One way to avoid this is enabling
CONFIG_USB_PERSIST and trying with that on.
You should also disable auto_suspend for this device. It won't work ok
after
that probably.
>
> Markus
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Best Regards,
Felipe Balbi
http://felipebalbi.com
[email protected]
On Wed, 21 Nov 2007 15:52:37 +0100, "Markus Rechberger"
<[email protected]> wrote:
> On 11/21/07, Markus Rechberger <[email protected]> wrote:
>> On 11/21/07, Markus Rechberger <[email protected]> wrote:
>> > On 11/21/07, Oliver Neukum <[email protected]> wrote:
>> > > Am Mittwoch 21 November 2007 schrieb Markus Rechberger:
>> > > > On 11/21/07, Markus Rechberger <[email protected]> wrote:
>> > > > > On 11/21/07, Mark Lord <[email protected]> wrote:
>> > > > > > Markus Rechberger wrote:
>> > > > > > > Hi,
>> > > > > > >
>> > > > > > > I'm looking at the linux uvc driver, and noticed after
> resuming
>> my
>> > > > > > ..
>> > > > > >
>> > > > > > Pardon me.. what is the "uvc" driver? Which module/source
> file is
>> > > that?
>> > > > > >
>> > > > >
>> > > > > http://linux-uvc.berlios.de/ it's not yet included in the kernel
>> > > > > sources although many distributions already ship it.
>> > > > > A "dry" run putting the device into sleep mode works fine (I
> added a
>> > > > > proc interface for calling those suspend/resume function).
>> > > > >
>> > > >
>> > > > it's not just usb_set_interface that hangs actually.
>> > > > It seems to hang at
>> > > >
>> > > > wait_event(usb_kill_urb_queue, atomic_read(&urb->use_count) == 0);
>> > > >
>> > > > in drivers/usb/core/urb.c after resuming. I disabled access to the
> usb
>> > > > subsystem in the uvc driver, although connecting any other usb
> storage
>> > > > fails too, just at the same point.
>> > >
>> > > Which URB is usb_kill_urb() called for?
>> > >
>> >
>> > it's the usb_control_message which calls usb_kill_urb if I haven't got
>> > it wrong. (if you're looking for some other information please let me
>> > know)
>> > Although, I got a bit further with it. The error seems to happen
>> > earlier already.
>> > If I load the driver, and do not access the device after suspending
>> > all usb_control commands fail with -71 eproto.
>> >
>> > Reloading the driver doesn't help at tht point, only reconnecting the
>> > device does.
>> >
>> > The data is transfered using bulk transfer.
>> >
>>
>> Do you know any good way for performing a softreset within the driver?
>> The video application should get a continuous datastream after
>> resuming the notebook, so the driver shouldn't be unloaded.
>> The driver also keeps a list of previous camera settings which should
>> be set up again after resuming. Stopping the video application and
>> reattaching the device using ACPI (this board supports reconnecting
>> the device using ACPI) should be avoided.
>>
>
> ok usb_reset_device() did the job after resuming. First problem solved.
hmm... in that case try setting in quirks USB_QUIRK_RESET_RESUME
>
> Markus
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Best Regards,
Felipe Balbi
http://felipebalbi.com
[email protected]
Am Mittwoch 21 November 2007 schrieb Felipe Balbi:
> Hi,
>
> On Wed, 21 Nov 2007 15:37:20 +0100, "Markus Rechberger"
> <[email protected]> wrote:
> > it's the usb_control_message which calls usb_kill_urb if I haven't got
> > it wrong. (if you're looking for some other information please let me
> > know)
> > Although, I got a bit further with it. The error seems to happen
> > earlier already.
> > If I load the driver, and do not access the device after suspending
> > all usb_control commands fail with -71 eproto.
>
> This device shouldn't be suspended. AFAIK it should have auto_suspend
> disabled
> by default.
>
> Try adding this device to drivers/usb/core/quirks.c with
> USB_QUIRK_NO_AUTOSUSPEND flag set. Something like:
Unless the device sets a flag it won't be autosuspended. Nevertheless
it will and must be suspended as the whole system is supended.
Regards
Oliver
Am Mittwoch 21 November 2007 schrieb Felipe Balbi:
> > Do you know any good way for performing a softreset within the driver?
> > The video application should get a continuous datastream after
> > resuming the notebook, so the driver shouldn't be unloaded.
> > The driver also keeps a list of previous camera settings which should
> > be set up again after resuming. Stopping the video application and
> > reattaching the device using ACPI (this board supports reconnecting
> > the device using ACPI) should be avoided.
>
> When you suspend, you cut off vbus (afaik, correct me if I'm wrong), which
> means your device will get disconnected. One way to avoid this is enabling
> CONFIG_USB_PERSIST and trying with that on.
Suspend may or may not cut off power. If it does cut off power, resume() will
never be called, instead either disconnect() or reset_resume().
Regards
Oliver
Am Mittwoch 21 November 2007 schrieb Markus Rechberger:
> > Which URB is usb_kill_urb() called for?
> >
>
> it's the usb_control_message which calls usb_kill_urb if I haven't got
> it wrong. (if you're looking for some other information please let me
> know)
> Although, I got a bit further with it. The error seems to happen
> earlier already.
> If I load the driver, and do not access the device after suspending
> all usb_control commands fail with -71 eproto.
A timeout. You should add the RESET_RESUME quirk for your device.
usb_reset_device() from resume() is not a good idea.
Regards
Oliver
On 11/21/07, Oliver Neukum <[email protected]> wrote:
> Am Mittwoch 21 November 2007 schrieb Markus Rechberger:
> > > Which URB is usb_kill_urb() called for?
> > >
> >
> > it's the usb_control_message which calls usb_kill_urb if I haven't got
> > it wrong. (if you're looking for some other information please let me
> > know)
> > Although, I got a bit further with it. The error seems to happen
> > earlier already.
> > If I load the driver, and do not access the device after suspending
> > all usb_control commands fail with -71 eproto.
>
> A timeout. You should add the RESET_RESUME quirk for your device.
> usb_reset_device() from resume() is not a good idea.
>
ok this is good to know, although I have to stick with kernel 2.6.21.3 here.
It's Laurent's driver best would be to check for the specific
kernelversion and do whatever is appropriate.
thanks,
Markus
On Wed, 21 Nov 2007, Markus Rechberger wrote:
> > > it's not just usb_set_interface that hangs actually.
> > > It seems to hang at
> > >
> > > wait_event(usb_kill_urb_queue, atomic_read(&urb->use_count) == 0);
> > >
> > > in drivers/usb/core/urb.c after resuming. I disabled access to the usb
> > > subsystem in the uvc driver, although connecting any other usb storage
> > > fails too, just at the same point.
> >
> > Which URB is usb_kill_urb() called for?
> >
>
> it's the usb_control_message which calls usb_kill_urb if I haven't got
> it wrong. (if you're looking for some other information please let me
> know)
> Although, I got a bit further with it. The error seems to happen
> earlier already.
> If I load the driver, and do not access the device after suspending
> all usb_control commands fail with -71 eproto.
That's very strange. Getting -71 errors is understandable; it
indicates that the device can't handle being suspended. But the
wait_event() line still shouldn't hang. If it does, it indicates that
there's something wrong with the USB host controller, not just the
device.
Can you try testing this on a different sort of computer?
Alan Stern
On 11/21/07, Alan Stern <[email protected]> wrote:
> On Wed, 21 Nov 2007, Markus Rechberger wrote:
>
> > > > it's not just usb_set_interface that hangs actually.
> > > > It seems to hang at
> > > >
> > > > wait_event(usb_kill_urb_queue, atomic_read(&urb->use_count) == 0);
> > > >
> > > > in drivers/usb/core/urb.c after resuming. I disabled access to the usb
> > > > subsystem in the uvc driver, although connecting any other usb storage
> > > > fails too, just at the same point.
> > >
> > > Which URB is usb_kill_urb() called for?
> > >
> >
> > it's the usb_control_message which calls usb_kill_urb if I haven't got
> > it wrong. (if you're looking for some other information please let me
> > know)
> > Although, I got a bit further with it. The error seems to happen
> > earlier already.
> > If I load the driver, and do not access the device after suspending
> > all usb_control commands fail with -71 eproto.
>
> That's very strange. Getting -71 errors is understandable; it
> indicates that the device can't handle being suspended. But the
> wait_event() line still shouldn't hang. If it does, it indicates that
> there's something wrong with the USB host controller, not just the
> device.
>
> Can you try testing this on a different sort of computer?
>
Not really, suspending doesn't work at all on my other notebook it
just freezes..
I'm basically trying to get that driver work on my eee PC [1], it's
cheap and tiny so I don't expect anything special in there..
The system is preloaded with Xandros (it's debian etch with a few
custom applications) and linux 2.6.21.4.
The system still locks up, although only if I leave the video
application running during suspending. I don't have to reload the
driver anymore after resuming if the video node doesn't get accessed
(I'm looking for races in the uvc driver at the moment).
thanks,
Markus
[1] http://eeepc.asus.com
On Wed, 21 Nov 2007, Markus Rechberger wrote:
> Not really, suspending doesn't work at all on my other notebook it
> just freezes..
> I'm basically trying to get that driver work on my eee PC [1], it's
> cheap and tiny so I don't expect anything special in there..
> The system is preloaded with Xandros (it's debian etch with a few
> custom applications) and linux 2.6.21.4.
>
> The system still locks up, although only if I leave the video
> application running during suspending. I don't have to reload the
> driver anymore after resuming if the video node doesn't get accessed
> (I'm looking for races in the uvc driver at the moment).
The point is that the system shouldn't lock up. The application might
fail or crash, but the system should continue to run. The fact that it
doesn't means that something is wrong in the kernel.
Alan Stern
On Wednesday 21 November 2007, Markus Rechberger wrote:
> On 11/21/07, Oliver Neukum <[email protected]> wrote:
> > Am Mittwoch 21 November 2007 schrieb Markus Rechberger:
> > > > Which URB is usb_kill_urb() called for?
> > >
> > > it's the usb_control_message which calls usb_kill_urb if I haven't got
> > > it wrong. (if you're looking for some other information please let me
> > > know)
> > > Although, I got a bit further with it. The error seems to happen
> > > earlier already.
> > > If I load the driver, and do not access the device after suspending
> > > all usb_control commands fail with -71 eproto.
> >
> > A timeout. You should add the RESET_RESUME quirk for your device.
> > usb_reset_device() from resume() is not a good idea.
>
> ok this is good to know, although I have to stick with kernel 2.6.21.3
> here. It's Laurent's driver best would be to check for the specific
> kernelversion and do whatever is appropriate.
I like the RESET_RESUME quirk best. Adding a new quirk to the uvcvideo driver
doesn't really make sense when the USB subsystem is already able to handle
this situation.
Best regards,
Laurent Pinchart
On Wednesday 21 November 2007, Markus Rechberger wrote:
> On 11/21/07, Alan Stern <[email protected]> wrote:
> > On Wed, 21 Nov 2007, Markus Rechberger wrote:
> > > > > it's not just usb_set_interface that hangs actually.
> > > > > It seems to hang at
> > > > >
> > > > > wait_event(usb_kill_urb_queue, atomic_read(&urb->use_count) == 0);
> > > > >
> > > > > in drivers/usb/core/urb.c after resuming. I disabled access to the
> > > > > usb subsystem in the uvc driver, although connecting any other usb
> > > > > storage fails too, just at the same point.
> > > >
> > > > Which URB is usb_kill_urb() called for?
> > >
> > > it's the usb_control_message which calls usb_kill_urb if I haven't got
> > > it wrong. (if you're looking for some other information please let me
> > > know)
> > > Although, I got a bit further with it. The error seems to happen
> > > earlier already.
> > > If I load the driver, and do not access the device after suspending
> > > all usb_control commands fail with -71 eproto.
> >
> > That's very strange. Getting -71 errors is understandable; it
> > indicates that the device can't handle being suspended. But the
> > wait_event() line still shouldn't hang. If it does, it indicates that
> > there's something wrong with the USB host controller, not just the
> > device.
> >
> > Can you try testing this on a different sort of computer?
>
> Not really, suspending doesn't work at all on my other notebook it
> just freezes..
> I'm basically trying to get that driver work on my eee PC [1], it's
> cheap and tiny so I don't expect anything special in there..
> The system is preloaded with Xandros (it's debian etch with a few
> custom applications) and linux 2.6.21.4.
If I'm not mistaken, the EeePC ACPI bios plays tricks with the USB ports
during suspend/resume. You should really test suspend/resume with the same
camera chipset on a proper computer. If the camera still crashes, we have a
buggy chipset which needs a reset quirk. If it doesn't, the EeePC ACPI bios
is probably at fault. Adding quirks and hacks to the Linux kernel (either in
the USB stack or the uvcvideo driver) is pretty pointless if the bios tries
to make the system crash. The ACPI code should be fixed in that case.
> The system still locks up, although only if I leave the video
> application running during suspending. I don't have to reload the
> driver anymore after resuming if the video node doesn't get accessed
> (I'm looking for races in the uvc driver at the moment).
Best regards,
Laurent Pinchart
On Wednesday 21 November 2007, Oliver Neukum wrote:
> Am Mittwoch 21 November 2007 schrieb Felipe Balbi:
> > > Do you know any good way for performing a softreset within the driver?
> > > The video application should get a continuous datastream after
> > > resuming the notebook, so the driver shouldn't be unloaded.
> > > The driver also keeps a list of previous camera settings which should
> > > be set up again after resuming. Stopping the video application and
> > > reattaching the device using ACPI (this board supports reconnecting
> > > the device using ACPI) should be avoided.
> >
> > When you suspend, you cut off vbus (afaik, correct me if I'm wrong),
> > which means your device will get disconnected. One way to avoid this is
> > enabling CONFIG_USB_PERSIST and trying with that on.
>
> Suspend may or may not cut off power.
I've always been confused by this.
If I'm not mistaken, there are three kind of suspend modes: autosuspend,
suspend to RAM and suspend to disk. In the first case I expect the USB hub
(either root hub or external hub) to make the bus idle but not power it down.
In the last case I suspect the USB bus to be powered down.
What controls the USB bus power on suspended ports ? Is it handled by the
system (BIOS, ...) ? Is it allowed to power down the ports or keep them
powered as it chooses ? What are the rules set in stone ?
> If it does cut off power, resume() will never be called, instead either
> disconnect() or reset_resume().
What is reset_resume() for ? Which one will be called on resume after a bus
power down ?
Best regards,
Laurent Pinchart
On Wed, 21 Nov 2007, Laurent Pinchart wrote:
> > > When you suspend, you cut off vbus (afaik, correct me if I'm wrong),
> > > which means your device will get disconnected. One way to avoid this is
> > > enabling CONFIG_USB_PERSIST and trying with that on.
> >
> > Suspend may or may not cut off power.
>
> I've always been confused by this.
>
> If I'm not mistaken, there are three kind of suspend modes: autosuspend,
You mean runtime (AKA dynamic) suspend -- autosuspend is merely one
type of runtime suspend.
> suspend to RAM and suspend to disk.
The nomenclature du jour is just plain "suspend" for suspend-to-RAM and
"hibernation" for suspend-to-disk.
> In the first case I expect the USB hub
> (either root hub or external hub) to make the bus idle but not power it down.
Correct.
> In the last case I suspect the USB bus to be powered down.
Usually, not but always! Some Macs have been known to keep USB suspend
current available during hibernation.
> What controls the USB bus power on suspended ports ? Is it handled by the
> system (BIOS, ...) ? Is it allowed to power down the ports or keep them
> powered as it chooses ? What are the rules set in stone ?
There are no rules set in stone. :-)
Systems are _supposed_ to keep the ports powered during suspend, but
some may fail to do so. It depends on the firmware (i.e., BIOS for
PCs) and the motherboard design.
> > If it does cut off power, resume() will never be called, instead either
> > disconnect() or reset_resume().
>
> What is reset_resume() for ? Which one will be called on resume after a bus
> power down ?
This is explained in Documentation/usb/power-management.txt. If the
USB Persist facility has been enabled for a device then reset_resume
will be called, to indicate that the device had to be reset as part of
the resume procedure. If USB Persist isn't enabled then the disconnect
method will be called and the device will be re-enumerated, exactly as
though it had been unplugged and then plugged back in.
Alan Stern
On 11/21/07, Laurent Pinchart <[email protected]> wrote:
> On Wednesday 21 November 2007, Markus Rechberger wrote:
> > On 11/21/07, Alan Stern <[email protected]> wrote:
> > > On Wed, 21 Nov 2007, Markus Rechberger wrote:
> > > > > > it's not just usb_set_interface that hangs actually.
> > > > > > It seems to hang at
> > > > > >
> > > > > > wait_event(usb_kill_urb_queue, atomic_read(&urb->use_count) == 0);
> > > > > >
> > > > > > in drivers/usb/core/urb.c after resuming. I disabled access to the
> > > > > > usb subsystem in the uvc driver, although connecting any other usb
> > > > > > storage fails too, just at the same point.
> > > > >
> > > > > Which URB is usb_kill_urb() called for?
> > > >
> > > > it's the usb_control_message which calls usb_kill_urb if I haven't got
> > > > it wrong. (if you're looking for some other information please let me
> > > > know)
> > > > Although, I got a bit further with it. The error seems to happen
> > > > earlier already.
> > > > If I load the driver, and do not access the device after suspending
> > > > all usb_control commands fail with -71 eproto.
> > >
> > > That's very strange. Getting -71 errors is understandable; it
> > > indicates that the device can't handle being suspended. But the
> > > wait_event() line still shouldn't hang. If it does, it indicates that
> > > there's something wrong with the USB host controller, not just the
> > > device.
> > >
> > > Can you try testing this on a different sort of computer?
> >
> > Not really, suspending doesn't work at all on my other notebook it
> > just freezes..
> > I'm basically trying to get that driver work on my eee PC [1], it's
> > cheap and tiny so I don't expect anything special in there..
> > The system is preloaded with Xandros (it's debian etch with a few
> > custom applications) and linux 2.6.21.4.
>
> If I'm not mistaken, the EeePC ACPI bios plays tricks with the USB ports
> during suspend/resume. You should really test suspend/resume with the same
> camera chipset on a proper computer. If the camera still crashes, we have a
> buggy chipset which needs a reset quirk. If it doesn't, the EeePC ACPI bios
> is probably at fault. Adding quirks and hacks to the Linux kernel (either in
> the USB stack or the uvcvideo driver) is pretty pointless if the bios tries
> to make the system crash. The ACPI code should be fixed in that case.
>
With ACPI it seems to be possible to disconnect the uvc device.
I tested the suspend/resume functions by adding a proc interface to
it, and it worked properly.
Although the eee PC also suspends the underlying bus where the usb
controller is connected to (which is PCI or PCIe)
> > The system still locks up, although only if I leave the video
> > application running during suspending. I don't have to reload the
> > driver anymore after resuming if the video node doesn't get accessed
> > (I'm looking for races in the uvc driver at the moment).
>
The current state I revealed is that after suspend if the video node
isn't used it's not necessary to reconnect the device nor to reload
the driver again if that reset is implemented.
That eee PC comes with 2.6.21.3 which has no such reset quirk feature
in the usbcore (that's what I initially meant actually).
If a videoapplication accesses the nodes during suspend the notebook
won't come back again.
I also think it's faulty hardware in that case but I'm moreover
looking for a solution for it. My other intel notebook doesn't even
awake from suspend to ram, and for some reason suspend to disk just
didn't work as expected either (Acer Travelmate 660).
thanks for the feedback,
Markus
Am Mittwoch 21 November 2007 schrieb Laurent Pinchart:
> I like the RESET_RESUME quirk best. Adding a new quirk to the uvcvideo driver
> doesn't really make sense when the USB subsystem is already able to handle
> this situation.
Not the driver but teh system wide quirks table. We have to reset such devices
even if no driver is loaded.
Regards
Oliver