Am 12.06.2016 um 01:25 schrieb Oscar C
: El 2016-05-30 21:30, Alexander Graf escribió:
Hi Oscar,
On 05/30/2016 09:09 PM, Oscar C wrote: Hi,
I'm trying to boot a udoo quad board (imx6, similar to cubox-i). It boots and I can login but one of the usb ports work. Looking at the dmesg output I see that there are unknown symbol errors when the usb modules are being loaded:
[ 12.905677] libphy: fec_enet_mii_bus: probed [ 12.910917] fec 2188000.ethernet eth0: registered PHC device 0 [ 12.979507] usbcore: registered new interface driver usbfs [ 12.985146] usbcore: registered new interface driver hub [ 12.990659] usbcore: registered new device driver usb [ 13.175153] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 13.407405] usb_otg_fsm: module license 'unspecified' taints kernel.
This message means that the driver author didn't specify the license in the source file.
[ 13.413995] Disabling lock debugging due to kernel taint [ 13.420407] usb_otg_fsm: Unknown symbol usb_bus_start_enum (err 0) [ 13.426990] usb_otg_fsm: Unknown symbol usb_control_msg (err 0) [ 13.433189] usb_otg_fsm: Unknown symbol usb_hub_find_child (err 0) [ 13.463782] usb_otg_fsm: Unknown symbol usb_bus_start_enum (err 0) [ 13.471592] usb_otg_fsm: Unknown symbol usb_control_msg (err 0) [ 13.478116] usb_otg_fsm: Unknown symbol usb_hub_find_child (err 0)
and those most probably mean that the driver is trying to use functions / variables that are defined outside its own scope, but not declared with EXPORT_SYMBOL() which would be needed to have something get used by a non-GPL module. And indeed, in the source you can see
drivers/usb/core/hcd.c:EXPORT_SYMBOL_GPL(usb_bus_start_enum);
which declares one of those "missing" symbols, but only to GPL modules. The fix would be to add a
MODULE_LICENSE("GPL");
line in the usb_otg_fsm driver source file. At least if that's an accurate description and the file is indeed GPL (which I guess it is, since it's upstream). Send that patch upstream, mark it as CC stable@vger.kernel.org. It will get into our tree automatically then. If you like we can also backport it earlier if going via stable turns out too slow for you :).
Thanks Alex.
To see if I fixed it correctly, I compiled the module after the changes you suggested. Although that errors are now gone, I have another problem with the usb subsystem: even though all modules can be loaded, as soon as I try to load the module ci_hdrc_imx, the kernel hangs without any error at all.
If I boot the board blacklisting the ci_hdrc_imx module (appending modprobe.blacklist=ci_hdrc_imx as boot parm) I can boot and logon, but no usb devices are present. This is the output from hwinfo and lsusb (empty):
nohostname:~ # hwinfo --usb --usb-ctrl 03: None 00.0: 0c03 USB Controller (UHCI) [Created at pci.996] Unique ID: OUde.nXi7rxFKh4B SysFS ID: /devices/soc0/soc/2100000.aips-bus/2184200.usb SysFS BusID: 2184200.usb Hardware Class: usb controller Model: "ARM USB 0" Device: "ARM USB 0" Module Alias: "of:NusbT<NULL>Cfsl,imx6q-usbCfsl,imx27-usb" Driver Info #0: Driver Status: uhci-hcd is active Driver Activation Cmd: "modprobe uhci-hcd" Driver Info #1: Driver Status: ci_hdrc_imx is not active Driver Activation Cmd: "modprobe ci_hdrc_imx" Config Status: cfg=new, avail=yes, need=no, active=unknown
nohostname:~ # lsusb -vvvv nohostname:~ #
What can I do now?
Phew, that almost sounds like a clock problem. I think the best path forward would be to submit the patch that you wrote to the mailing list and note in the patch description that the system now crashes on module load. Make sure to CC the driver maintainer and then work with him to resolve the problem :). Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org