On 15/02/19(Fri) 01:47, James Hastings wrote: > On 11/02/19(Mon) 18:58, Artturi Alm wrote: > > On Mon, Feb 11, 2019 at 02:15:43PM -0200, Martin Pieuchot wrote: > > > On 10/02/19(Sun) 20:46, Artturi Alm wrote: > > > > Hi, > > > > > > > > rather than patching uhub(4), i figured this would be less not-ok, > > > > if not ok as-is, given its way more limited scope. > > > > > > Why shouldn't we patch uhub(4)? > > > > > > > There's no MD code in uhub(4), and i don't know what to fix there yet, > > but the workaround i was referring to w/"patching" has MI side-effects. > > I settled on a patch providing an additional 250ms powerdelay in uhub(4). > mue(4) reliably attaches now, but hotplugging devices in the left two > ports is still an issue.
Interesting. Could you build a kernel with UHUB_DEBUG enable and compare the status of the ports? I'm wondering if your increased delay will change the value returned by usbd_get_port_status() line 376. Why did you decide to increase the delay? Did you find some doc or code saying this is necessary? > Index: dev/usb/uhub.c > =================================================================== > RCS file: /cvs/src/sys/dev/usb/uhub.c,v > retrieving revision 1.92 > diff -u -p -r1.92 uhub.c > --- dev/usb/uhub.c 7 Jan 2019 14:24:22 -0000 1.92 > +++ dev/usb/uhub.c 15 Feb 2019 05:24:54 -0000 > @@ -324,6 +324,7 @@ uhub_attach(struct device *parent, struc > } > > /* Wait for stable power. */ > + powerdelay += 250; > if (dev->powersrc->parent != NULL) > usbd_delay_ms(dev, powerdelay + USB_EXTRA_POWER_UP_TIME); >
