On Mon, Oct 12, 2015 at 02:43:25PM +0300, Peter Mamonov wrote: > On Mon, 12 Oct 2015 09:00:21 +0200 > Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> wrote: > > > On Wed, Oct 07, 2015 at 07:52:21PM +0300, Peter Mamonov wrote: > > > On Wed, 7 Oct 2015 17:40:24 +0200 > > > > > Non-interruptible delays are needed here to prevent ehci_* > > > > > functions re-entrance. The re-entrance occurs during a usb bus > > > > > scan, after detection of a usb keyboard. As soon as a USB > > > > > keyboard is detected, it's driver starts the poller, which > > > > > interferes with the process of usb bus scan. However that last > > > > > one delay may be interruptible. > > > > > > > > my problem is as soon as you start a usb control msg you block > > > > everything > > > > > > > > nothing else can run in barebox > > > > > > > > can slow down barebox boot > > > > > > > > I do think we need a real mdelay_non_interruptible feature but > > > > just forbidden to recall usb control msg. > > > > But the rest of barebox can run durring those 5ms > > > > > > Well, I think it can be done by returning -EAGAIN on re-entrance > > > detection in ehci_* functions [1], and skipping the poll in the > > > keyboard driver. > > > > Could you tell us what you have done to get re-entrance problems? I > > have just replaced the mdelay_non_interruptible with regular mdelay > > in the ehci driver and didn't notice any problems. Could you verify > > the _non_interruptible is still needed? > > If I revert the "usb: ehci-hcd: use mdelay_non_interruptible()" patch, > while leaving the "usb: ehci-hcd: detect re-entrance" applied, I get > the following messages after running the "usb" command: > > barebox:/ usb > USB: scanning bus for devices... > Bus 001 Device 001: ID 0000:0000 EHCI Host Controller > Bus 001 Device 002: ID 0424:2514 > Bus 001 Device 003: ID 413c:2112 Dell USB Wired Multimedia Keybo > usb-keyboard usb1-0-0: USB keyboard found > Bus 001 Device 004: ID 8564:1000 Mass Storage Device > Using index 0 for the new disk > usb-keyboard usb1-0-0: submit_int_msg: re-entrance 1 (usb-hub:usb1) > usb-keyboard usb1-0-0: submit_int_msg: re-entrance 1 (usb-hub:usb1) > usb-keyboard usb1-0-0: submit_int_msg: re-entrance 1 (usb-keyboard:usb1-0-0) > usb-keyboard usb1-0-0: submit_int_msg: re-entrance 1 (usb-keyboard:usb1-0-0) > usb-keyboard usb1-0-0: submit_int_msg: re-entrance 1 (usb-hub:usb1) > usb-keyboard usb1-0-0: submit_int_msg: re-entrance 1 (usb-keyboard:usb1-0-0) > usb-keyboard usb1-0-0: submit_int_msg: re-entrance 1 (usb-keyboard:usb1-0-0) > Bus 001 Device 005: ID 0424:2514 > 5 USB Device(s) found > > According to the debug messages: submit_int_msg() is called by the usb-keyboard driver (from the poller function), > while "usb-hub" driver is executing submit_control_msg() (which calls mdelay() and poller_call() subsequently). > This occurs several times, until usb bus scan is completed. > Probably the problem can be reproduced by adding more usb devices. I wonder why this does not happen here. I finally could reproduce this by adding some additional delays to the ehci driver. We should probably move the reentrance detection to the generic usb layer to usb_submit_int_msg, usb_control_msg and usb_bulk_msg. This would avoid running into the same problems in the other usb host drivers. If I understand the issue correctly we could just use regular *delay in the host drivers when we detect reentrancy correctly, right? I mean we don't have to print an error message when we detect reentrance, but instead just consider that a case that can happen. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
