Hello, I’m having an issue when generating a custom kernel. The generated kernel boots and everything works, however
if I have a USB device connected, it takes 60 seconds after boot to detect it, and then this message in bold shows up:
[ 14.399437] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes ready
[ 17.206049] random: crng init done
[ 17.211904] random: 3 urandom warning(s) missed due to ratelimiting [ 64.489011] tegra-xusb 70090000.xusb: cannot find firmware…retry after 1 second
[ 65.519995] tegra-xusb 70090000.xusb: Firmware timestamp: 2019-10-17 15:58:59 UTC, Version: 50.25 release
[ 65.532070] tegra-xusb 70090000.xusb: xHCI Host Controller
[ 65.540084] tegra-xusb 70090000.xusb: new USB bus registered, assigned bus number 1
[ 65.550984] tegra-xusb 70090000.xusb: hcc params 0x0184f525 hci version 0x100 quirks 0x00050010
[ 65.562255] tegra-xusb 70090000.xusb: irq 61, io mem 0x70090000
[ 65.570799] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
This doesn’t happen in the official Nano image, am I missing some steps when generating this custom kernel?
I just write the nano image to the SDcard, put the SDcard on the Nano, and with any USB device connected to the Nano, I connect the power cable to the Nano.
I want to know what is your step to reproduce this issue.
We need a clear step from the beginning to the end.
What did you modify in kernel?
What command do you use to build kernel?
Where do you put your new kernel?
What command do you use to flash your new driver package to the device?
Please do not just say you compiled OpenWRT using our kernel and nothing else. We really don’t know how you achieve that and couldn’t find where the problem is by just such little info.
I can’t share the code since it contains lots of modifications and my client probably wouldn’t approve it, I was hoping you could help me debug the cause of the 60 second delay when detecting the USB devices at boot. Do you know of any similar issues that you could point me to?
Also, I don’t think purely modifying the kernel would hit this problem. Based on the info you shared so far, I can only say we cannot debug this issue. No enough information.
This is rather vague, and perhaps not too useful, but if the device eventually works, then there is a possibility that it is the enumeration which is slow. However, the log shows fast enumeration. What I do see is just after USB, and might be the real delay:
[ 316.387134] EXT4-fs (mmcblk0p1): error count since last fsck: 3
[ 316.395451] EXT4-fs (mmcblk0p1): initial error at time 1619975475: ext4_journal_check_start:61
[ 316.406557] EXT4-fs (mmcblk0p1): last error at time 1619975489: ext4_remount:5226
Your filesystem seems to be unmounted uncleanly, and may take significant time to correct for filesystem errors. Is the system with OpenWRT truly being shut down cleanly?
Yes, the device works after a minute. The filesystem was dirty, but after a fsck the problem persists as you can see.
Do you know what could cause a delay in the device enumeration?
If you really cannot share the code, then just remove those codes and see if the issue is still there.
There are lots of method to approach your scenario without revealing the code. Just try to share those info as possible.
Though it still makes no sense to not reveal your modified kernel. I can understand if you don’t want to reveal your usespace side code. But it makes no sense for kernel parts.
Ok, I started with the basic nano image, then replaced the rootfs with the one generated by OpenWRT, and then copied the firmware from the original Nano image partition to /lib/firmware.
But the problem appears to be that the firmware direct load is failing for some reason, and after 60 seconds it works.
Is there anything else that I have to change in the other partitions?