aarch64: Kernel instabilities

[lategoodbye]

Wow, this is a huge setup. Would be interesting to know if a specific serial to USB driver cause this issue (CH340 or the FTDI).

So it's possible to temporary disconnect one of the serial to USB?

[df8oe]

Thanks graysky. Since I have more informations I think I will dig deeper. The issue seems to be present since years but because of it pops up only under rare conditions it was not identified yet. With some more informations and testing it could be possibly isolated and eliminated - we will see. It is not an Arch packaging issue - it is upstream.

[df8oe]

No - I cannot disconnect one of them for a long time. But I remember the issue was present if only the FTDI was connected. Most others that report same instability (google search from my post) are only using FTDI.

[lategoodbye]

The BCM283x SoC only supports 8 USB endpoints, so i suggest to remove all unrelated devices like DVB-T first.

[df8oe]

DVB-T is needed for amateur-radio purposes. It provides a net accessible SDR (software defined radio).

Using the vanilla kernel I could remove FTDI and use integrated serial port of rpi - but using rpi kernel I cannot get it work whatever I do. I have added $this->bbcode_second_pass_code('', 'enable_uart=1
dtoverlay=pi3-disable-wifi
dtoverlay=pi3-disable-bt
dtoverlay=disable-wifi
dtoverlay=disable-bt')to cmdline.txt but /dev/ttyACM0 is not connected to GPIO14/15 as it was with vanilla kernel. I gave up got it running and took a usb2serial converter. Running vanilla kernel has another issue: When I reboot (or start) rpi it hangs at mounting USB RAID devices. I have to powerdown and up the RAID controller and then the USB device was identified as an USB SATA. I was not able to reboot without direct access to the hardware.

I have added an external USB hub for connecting a keyboard, or a USB hard drive (for backup purposes) and all are working (if I connect one of them it should no longer work if BCM only supports 8 devices) but all of them are working (more or less stable with the mentioned long term instability).

[lategoodbye]

The linux-rpi Kernel uses a so called out of tree driver (dwc_otg), which is only supported by the Raspberry Pi trading.

The vanilla kernel uses the dwc2 driver which improved a lot in the last years, but doesn't have all tricks of the dwc_otg (FIQ support which is unlikely to be accepted mainline). I tried to reproduce these hanging issue with a recent mainline Linux 5.19, but i failed to reproduce it. So it seems specific to your setup.

As you tested it with the vanilla kernel, did you try to disconnect all USB devices except of the RAID?

Could you please provide at least the output of
lsusb -t

[df8oe]

Using vanilla kernel and only DVB-T stick and RAID runs rock solid. I have used this setup for years (first Raspbian, since ~ 1 year aarch64). 1.5 months ago I started a new project on my rpi: communication with my solar inverter and battery. Because there were many changes in the beginning of the project Iand there are overlapping issues I cannt remember perfectly. First I used onbiard RS232 (GPIO14/15) and I think there was no issue except the one I have to power down and up RAID if I reboot rpi. That bothers so I switched to rpi kernel. Now there was no need for powering down - RAID was recognized stable at a reboot. But RS232 vanished and I could not bring it back again. Now I added a FTDI - and then (I think) freezing started. 10 days later (sure freezing was before that) I added RS485. Since then there passed a few kernels, and as I already stated there were some which looks better than others in stability. But I have had none which was solid.$this->bbcode_second_pass_code('', 'lsusb -t
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/5p, 480M
|__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=smsc95xx, 480M
|__ Port 2: Dev 4, If 0, Class=Hub, Driver=hub/4p, 12M
|__ Port 3: Dev 6, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M
|__ Port 4: Dev 7, If 0, Class=Vendor Specific Class, Driver=ch341, 12M
|__ Port 4: Dev 5, If 0, Class=Vendor Specific Class, Driver=, 480M
|__ Port 4: Dev 5, If 1, Class=Vendor Specific Class, Driver=, 480M
|__ Port 5: Dev 8, If 0, Class=Mass Storage, Driver=usb-storage, 480M
')

[df8oe]

You pointed me to dwc2 - I have not tried it yet. I added $this->bbcode_second_pass_code('', 'dtoverlay=dwc2') to config.txt and rebootet. Everything comes up as expected. I will run dwc2 driver for the next time and look if something changes...

[df8oe]

Very interesting. Using dwc2 seems to solve the issue completely. Since I switched to dwc2 there was not one log entry regarding USB. Before there were messages every 1...2 minutes, at higher datarates to the USB RAID the spans shrink to a few seconds. Today a new 5.19 kernel was installed and rebooting was successfully. All USB devices are working perfectly and there are no log entries regarding USB issues. It is too early to give a final statement but it looks very, very good. I wonder where the issue should be reported.

[df8oe]

I can close this issue report now. The "bad boy" is dwc1-driver. Using dwc2 shows no problems anymore. Actually I am running 5.19 rpi kernel. But I am nearly sure vanilla-kernel or 5.15 kernel will show same behaviour.

Many thanks for prividing arch buildings and for every participating to my post.

Andreas, DF8OE (ham radio callsign...)