C1+ Freezing

[uu0113]

Hi.

I own an Odroid C1+ (rev0.4 20150930) and C2.

While the C2 is running super fine (using LibreElec) I cannot get the C1+ working stable. The issue persists since I own it (over 1 years) and no software release or update ever solved it and I tried a lot! It seems to me the C1+ has a hardware problem. That's why I bought the C2. I want to see if it's the hardware...

Issue Description

• Once I disconnect ANY keyboard and/or mouse from one of the USB ports, the C1+ immediately freezes.
• Also the C+1 freezes occasionally when I am typing anything for 30-60 seconds and move the mouse for a random time within the menu. The C1+ somtimes hangs and recoves (if I hold still) but when active (e.g. playing a movie) it freezes completely and never comes back. Power cycle the only solution here.

I am currently running "LibreELEC-Odroid_C1.arm-8.0.4a.img" onto Sandisk 8GB SD-Card. LAN and HDMI are connected. I tried different keyboards, mouses, USB hubs and power sources (MicroUSB and Power Supply) with no success.

Anyone experience the same issues? Any clues what's wrong with the board?

[mad_ady]

Try the official ubuntu image - mine is rock solid, though it's headless

[meveric]

Issue Description

• Once I disconnect ANY keyboard and/or mouse from one of the USB ports, the C1+ immediately freezes.

That's a known issue, the C1 has broken USB drivers that causes this issue (and other USB related issues)

• Also the C+1 freezes occasionally when I am typing anything for 30-60 seconds and move the mouse for a random time within the menu. The C1+ somtimes hangs and recoves (if I hold still) but when active (e.g. playing a movie) it freezes completely and never comes back. Power cycle the only solution here.

Not sure if this is also related to the USB issue, but also the C1 has very little RAM and can't handle many tasks simultaneously, that can also cause lock ups, you might want to watch memory usage, maybe over ssh to see what the system is doing around the time it's locking up.

I am currently running "LibreELEC-Odroid_C1.arm-8.0.4a.img" onto Sandisk 8GB SD-Card. LAN and HDMI are connected.

Probably also an issue, LibreELEC is multimedia oriented, doing other stuff than watching movies, may very likely cause issues, as the video layer is on top of everything else normally.
Also I'm not sure if LibreELEC uses ZRAM or any other kind of SWAP, which also means, on memory issues, you are more likely to end up in a deadly "lock".
Other OS like Ubuntu, or Debian, normally use ZRAM to reduce the memory issues of the C1.

I tried different keyboards, mouses, USB hubs and power sources (MicroUSB and Power Supply) with no success.

Since this issue is related to the USB drivers itself changing the USB hardware connected to it, has probably minimal to no effect.
I have the same issues on my ODROIDs, removing keyboard causes a freeze, and as I use a wireless keyboard, for about 3-5 ODROIDs I permanently have on for testing, I'm switching keyboard through boards quite often and the C1 is not a nice player in that kind of setup.

Anyone experience the same issues? Any clues what's wrong with the board?

See above, you're not alone.

[bobcov]

I have gotten to this forum in a round-about way due to this issue on an Android TV box running 5.11 on an Amlogic S905 processor.
I have a very similar issue and I believe it is related to CPU core management. I shut off CPU core management last night and since that time my number and frequency of freezes and my ability to create them almost at will has dropped 99 percent.
When I got this box in July 2017 I first noticed a problem while using Netflix. The box would freeze but only when I used my Logitech wireless keyboard with USB dongle to move the cursor to go forward or back in the movie. And not every time, but often enough to finally prompt me this weekend to investigate. Also, only very rarely would it crash outside of Netflix, but also only when cursor movement was involved.
To make a long investigation story shorter, it came down to theorizing that USB mouse and keyboard functions were causing some kind of interrupt problem. Loading 3rd party firmware onto the box allowed me to get a log file which showed as one of the last entries before freezing that an IRQ was losing its connection to a CPU core being shutdown while another core subsequently was being rebooted. I'm not technical enough to understand what it all meant, but I got a utility to shut down core management and leave the cores running and the problem was vastly reduced. I now am thinking the remaining shutdowns, which are very hard to make happen, may be heat-related. The cpu has a tiny little heatsink and temps were about about 74C when the last freeze happened. That might well be within spec, but I haven't checked yet. Also, I have meant to dig out the remote controller which came with the TV box. It has a small keyboard and may use a different architecture than USB and might be a trouble-free option which will not trigger freezes. So, the long and short of it is is I believe there is a problem with USB and CPU performance management but I am not versed enough technically to know if what I have observed supports my conclusions.

[biterror]

Issue Description

• Once I disconnect ANY keyboard and/or mouse from one of the USB ports, the C1+ immediately freezes.

That's a known issue, the C1 has broken USB drivers that causes this issue (and other USB related issues)

Is there any fix or workaround for the USB problems? We have hundreds of C1+'s with two or three USB devices attached and the USB devices stop working at random intervals and/or the C1+ crashes. We're running 3.10.96-151 but the latest Ubuntu 16.04 didn't seem to help (disconnect a USB device twice -> instant crash).

EDIT: I thought I'd try setting (=limiting) the USB ports to full speed, but the instructions I found do not work with C1+.

EDIT#2: We have connected one of the USB devices to the OTG port and it helps some, but it doesn't solve the problem completely.

[odroid]

Can you show us "lsusb -t" and "lsusb" outputs?

[biterror]

Here, with one device connected to OTG port:
# lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 2: Dev 6, If 0, Class=Printer, Driver=usblp, 12M
# lsusb
Bus 001 Device 006: ID 05d9:a795 Axiohm Transaction Solutions
Bus 001 Device 002: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID d6e6:0002
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

[odroid]

Connect the printer device to the OTG port and let me know the result.

[biterror]

Connect the printer device to the OTG port and let me know the result.

Umm.. what do you mean? It's mainly the HID device that (I think) is causing problems. If I disconnect and reconnect it, linux will crash. Doing the same with the printer hasn't crashed the system as far as I know. That's why we put the HID device to the OTG port, but it didn't seem to solve all the problems. This is difficult to debug because the devices are all over the country and we get no logs / can't login the systems remotely.

[odroid]

I see.

Can you check the CPU governor?
Some people reported the USB IRQ related issues could be reduced significantly with "Performance" governor.
https://wiki.odroid.com/odroid-c1/os_im ... erformance

[biterror]

It seems to be using the Performance governor already.

[odroid]

I've connected and disconnected my Logitech K400 HID USB several times, but I couldn't reproduce the freezing issue so far.

Can you tell me brand & model name of your HID device?

[biterror]

It says "TSD Touch Monitor Model ITL101". The HID is a touch panel.

[odroid]

When we tested our Vu5/Vu7/Vu8 touchscreen devices, there was no such issue.

Can you try to plug and unplug your USB mouse or keyboard several times?

[RWAP]

I seem to have come across the same issue on both an Odroid C1 and a C1+

I have written some software which captures data being sent over USB from a computer - the computer connects to the USB-OTG port and I am using the gadget printer to capture the incoming data.

This works successfully on a Banana Pi (albeit a bit slowly).

We wanted to use the better Odroid C1 / C1+, but found the same freezing issue.

If I start the device and connect via SSH, everything is working fine. However, as soon as I connect the computer to the USB-OTG port, the device is unresponsive and freezes. I cannot access it via SSH and in fact the blue heartbeat LED stops flashing after a while - only the red LED and the green network LED continue to be active (the green network LED continues to flash).

Unfortunately, I don't have any means of connecting a HDMI display to view the screen.

I am using an external 2A PSU to power the Odroid.

Any suggestions as to how to overcome this would be welcome.

[meveric]

As this is a long standing issue (for several years already) I''m afraid there is no suggestion we can give that would work.
USB is an issue on the C1 and no matter what you do it won't change.

If there's ever a different Kernel than 3.10 for the ODROID C1 there's a chance the issue is fixed, but as long as the Kernel is still 3.10 don't expect this issue to be solved.

[RWAP]

Actually I have found what was causing the freezing issue in my particular application.

I have a loop which tests for incoming data over the USB-OTG port - after a specific timeout, it opened a channel with :

Code: Select all

FPRINTER=fopen("/dev/usb/lp0","w");

It then checked for new files which could have come from various sources in a directory and if necessary output them to that channel.

It then closed that channel with:

Code: Select all

fclose(FPRINTER)
FPRINTER=NULL


Unfortunately, I cannot open that channel at the start of the program, as other processes may also need to directly access /dev/usb/lp0

I found that after several loops, the Odroid freezes, which suggests that memory or stack space is being allocated every time this channel was opened, but not released when it was closed.

I am surprised that the Banana Pi did not have the same issue.