Re: USB gadgets with configfs hang reboot

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux