Hi, Ivaylo Dimitrov <ivo.g.dimitrov.75@xxxxxxxxx> writes: >>>>> Looks like there's some issue with the USB gadgets and configfs. >>>>> >>>>> I'm seeing rmmod of the UDC driver cause a warning and then reboot >>>>> hangs the system. This happens at least with v4.4, and I've reproduced >>>>> it with dwc3 and musb so it seems to be generic. >>>>> >>>> >>>> Having configfs is not needed, disabling usb gadgets (# >>>> CONFIG_USB_MUSB_GADGET is not set) seems to solved at least poweroff >>>> hang issue on N900. Also, g_nokia is not a module in the config I use, >>>> so I guess the problem is not related whether gadgets are modular or >>>> not. Unfortunately I was not able to test reboot, as rootfs became >>>> corrupted after the first poweroff :( . So it looks like my theory that >>>> onenand corruption on N900 is because poweroff/reboot hangs is wrong. >>> >>> (copied from "Re: [PATCH] usb: f_mass_storage: test whether thread is >>> running before starting another" thread) >>> >>> Yet another problem with USB gadget, this time with f_acm - if there is >>> an open /dev/ttyGSn device, it is impossible to reboot/power down the >>> device. >>> >>> My investigation shown that there is a process(pnatd) that opens >>> /dev/ttyGSn devices, so gserial_free_port() hangs on >>> wait_event(port->close_wait, gs_closed(port)); if I do "cd >>> /sys/bus/platform/drivers/musb-hdrc && echo musb-hdrc.0.auto > unbind". >>> >>> Unfortunately I don't have serial debug port connector on my N900, so I >>> can't capture logs after the reboot command, however, I suspect it hangs >>> on the same place as with unbind. >>> >>> That looks weird, as one would expect that close() is called when the >>> kernel kills user processes on reboot/powerdown. >> >> right, care to enable lockup detection and see if you can get more info >> out of it ? >> > > Nothing interesting, besides that screen does not work :(. However, the > device boots, I can connect through wifi and reboot still hangs. Also, I > don't see that port->close_wait in /proc/lockdep. Is that expected? no idea what /proc/lockdep is supposed to show > Is there a reason why a process (pnatd in this particular case) doesn't > get killed on reboot? there might be, and that's probably the bug we're trying to figure out. But so far, no idea. -- balbi
Attachment:
signature.asc
Description: PGP signature
