Hi Guenter, > Thanks for the confirmation. Do you see the problem only with the > ohci-sm501 driver or also with others ? All are likely affected, but it depends, because I believe the problem is that the USB subsystem runs out of memory. Please try the attached patch! The pool assumed 4096 byte page alignment for every allocation, which is excessive given that many requests are for 16 and 32 bytes. In the patch below, I have turned down the order to 5, which is good enough for the ED and TD structures of the OHCI, but not enough for the HCCA that needs 256 byte alignment. With some luck, the WARN_ON_ONCE will not trigger in your test, though. If it does, you may try to increase the order from 5 to 8. I have observed strange things happen when the USB subsystem runs out of memory. The mass storage drivers often seem to busy-wait on -ENOMEM, consuming a lot of processor resources. It would be much more efficient to sleep waiting for memory to become available. In your case I suspect that allocation failures are not correctly attributed. Certain kinds of temporary freezes may also occur, as the various devices are reset due to host memory allocation errors. Fredrik diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c --- a/drivers/usb/core/hcd.c +++ b/drivers/usb/core/hcd.c @@ -3011,7 +3011,7 @@ int usb_hcd_setup_local_mem(struct usb_hcd *hcd, phys_addr_t phys_addr, int err; void __iomem *local_mem; - hcd->localmem_pool = devm_gen_pool_create(hcd->self.sysdev, PAGE_SHIFT, + hcd->localmem_pool = devm_gen_pool_create(hcd->self.sysdev, 5, dev_to_node(hcd->self.sysdev), dev_name(hcd->self.sysdev)); if (IS_ERR(hcd->localmem_pool)) diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c --- a/drivers/usb/host/ohci-hcd.c +++ b/drivers/usb/host/ohci-hcd.c @@ -517,6 +517,7 @@ static int ohci_init (struct ohci_hcd *ohci) GFP_KERNEL); if (!ohci->hcca) return -ENOMEM; + WARN_ON_ONCE(ohci->hcca_dma & 0xff); if ((ret = ohci_mem_init (ohci)) < 0) ohci_stop (hcd);
