Re: [linux-usb-devel] USB deadlock after resume
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 - 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/
Re: [linux-usb-devel] USB deadlock after resume
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 - 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/
Re: [linux-usb-devel] USB deadlock after resume
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(>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 - 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/
Re: [linux-usb-devel] USB deadlock after resume
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 - 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/
Re: [linux-usb-devel] USB deadlock after resume
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 - 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/
Re: [linux-usb-devel] USB deadlock after resume
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(>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 - 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/
Re: [linux-usb-devel] USB deadlock after resume
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 - 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/
Re: [linux-usb-devel] USB deadlock after resume
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 - 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/
Re: [linux-usb-devel] USB deadlock after resume
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(>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 - 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/
Re: [linux-usb-devel] USB deadlock after resume
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(>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 - 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/
Re: [linux-usb-devel] USB deadlock after resume
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 - 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/
Re: [linux-usb-devel] USB deadlock after resume
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 - 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/
Re: [linux-usb-devel] USB deadlock after resume
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 - 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/
Re: [linux-usb-devel] USB deadlock after resume
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 - 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/
Re: [linux-usb-devel] USB deadlock after resume
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 - 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/
Re: [linux-usb-devel] USB deadlock after resume
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 - 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/
Re: [linux-usb-devel] USB deadlock after resume
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 - 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/
Re: [linux-usb-devel] USB deadlock after resume
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 - 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/
