davidmam
Posts: 101
Joined: Tue Dec 06, 2011 4:13 pm

Re: USB - the Elephant in our Room

Wed Nov 07, 2012 8:17 pm

I tried the fix at github (issue 151) where you put 0x31 into the register when it says 0x30

This didn't stop things dying after about 18 hours. Syslog reads:

Code: Select all

Nov  7 16:13:38 raspberrypi kernel: [73638.092377] ieee80211 phy0: wlan0: No probe r sponse from AP 74:44:01:69:6c:05 after 500ms, disconnecting.
Nov  7 16:13:38 raspberrypi wpa_supplicant[1486]: wlan0: CTRL-EVENT-DISCONNECTED bss d=74:44:01:69:6c:05 reason=4
Nov  7 16:13:38 raspberrypi kernel: [73638.116398] cfg80211: Calling CRDA to update  orld regulatory domain
Nov  7 16:13:38 raspberrypi ifplugd(wlan0)[1498]: Link beat lost.
Nov  7 16:13:49 raspberrypi ifplugd(wlan0)[1498]: Executing '/etc/ifplugd/ifplugd.ac ion wlan0 down'.
Nov  7 16:13:49 raspberrypi dhclient: Internet Systems Consortium DHCP Client 4.2.2
Nov  7 16:13:49 raspberrypi ifplugd(wlan0)[1498]: client: Internet Systems Consortiu  DHCP Client 4.2.2
Nov  7 16:13:49 raspberrypi dhclient: Copyright 2004-2011 Internet Systems Consortiu .
Nov  7 16:13:49 raspberrypi ifplugd(wlan0)[1498]: client: Copyright 2004-2011 Intern t Systems Consortium.
Nov  7 16:13:49 raspberrypi dhclient: All rights reserved.
Nov  7 16:13:49 raspberrypi ifplugd(wlan0)[1498]: client: All rights reserved.
Nov  7 16:13:49 raspberrypi dhclient: For info, please visit https://www.isc.org/sof ware/dhcp/
Nov  7 16:13:49 raspberrypi ifplugd(wlan0)[1498]: client: For info, please visit htt s://www.isc.org/software/dhcp/
Nov  7 16:13:49 raspberrypi dhclient: 
Nov  7 16:13:49 raspberrypi dhclient: Listening on LPF/wlan0/7c:dd:90:0f:30:f0
Nov  7 16:13:49 raspberrypi ifplugd(wlan0)[1498]: client: Listening on LPF/wlan0/7c: d:90:0f:30:f0
Nov  7 16:13:49 raspberrypi dhclient: Sending on   LPF/wlan0/7c:dd:90:0f:30:f0
Nov  7 16:13:49 raspberrypi ifplugd(wlan0)[1498]: client: Sending on   LPF/wlan0/7c: d:90:0f:30:f0
Nov  7 16:13:49 raspberrypi dhclient: Sending on   Socket/fallback
Nov  7 16:13:49 raspberrypi ifplugd(wlan0)[1498]: client: Sending on   Socket/fallba k
Nov  7 16:13:49 raspberrypi dhclient: DHCPRELEASE on wlan0 to 192.168.0.1 port 67
Nov  7 16:13:49 raspberrypi ifplugd(wlan0)[1498]: client: DHCPRELEASE on wlan0 to 19 .168.0.1 port 67
Nov  7 16:13:49 raspberrypi wpa_supplicant[1486]: wlan0: CTRL-EVENT-TERMINATING - si nal 15 received
Nov  7 16:13:49 raspberrypi ifplugd(wlan0)[1498]: Program executed successfully.
Nov  7 16:13:51 raspberrypi ntpd[2052]: Deleting interface #2 wlan0, 192.168.0.10#12 , interface stats: received=526, sent=529, dropped=0, active_time=73614 secs
Nov  7 16:13:51 raspberrypi ntpd[2052]: 193.140.100.40 interface 192.168.0.10 -> (no e)
Nov  7 16:13:51 raspberrypi ntpd[2052]: 193.225.118.163 interface 192.168.0.10 -> (n ne)
Nov  7 16:13:51 raspberrypi ntpd[2052]: 217.144.143.83 interface 192.168.0.10 -> (no e)
Nov  7 16:13:51 raspberrypi ntpd[2052]: 85.10.240.253 interface 192.168.0.10 -> (non )
Nov  7 16:13:51 raspberrypi ntpd[2052]: peers refreshed
Nov  7 16:15:01 raspberrypi /USR/SBIN/CRON[5544]: (root) CMD (/home/pi/crontest.sh)
Nov  7 16:15:01 raspberrypi logger: check_lan: wlan0 is down
Nov  7 16:15:01 raspberrypi /USR/SBIN/CRON[5543]: (CRON) info (No MTA installed, dis arding output)
Nov  7 16:17:01 raspberrypi /USR/SBIN/CRON[5554]: (root) CMD (   cd / && run-parts - report /etc/cron.hourly)
The register alluded to in the github note at https://github.com/raspberrypi/linux/issues/151 doesn't appear to be the issue:


Wed Nov 7 16:15:01 UTC 2012
Re[email protected] = 0x00000031
[email protected] = 0x00000031
Wed Nov 7 16:30:02 UTC 2012
[email protected] = 0x00000031
[email protected] = 0x00000031
Wed Nov 7 16:45:01 UTC 2012
[email protected] = 0x00000031
[email protected] = 0x00000031


Any ideas on how I can track and log what is going on with this so I can provide more useful info to those who may be able to fix it. The USB socket does seem to get rather hot so it might be a thermal issue.

MorePiPlease
Posts: 21
Joined: Mon Nov 05, 2012 1:59 pm

Re: USB - the Elephant in our Room

Thu Nov 08, 2012 12:36 am

Well I have the web streaming running with the defualt 352x288 resolution seems very stable...I'll tweak it and see what happens.

rspitz
Posts: 58
Joined: Tue Jul 31, 2012 7:25 pm

Re: USB - the Elephant in our Room

Sun Nov 11, 2012 10:16 pm

Since upgrading the kernel to 3.2.27+ #260 PREEMPT, I'm getting new error messages in dmesg. Before, I only got the "Failed to read register index 0x00000114", but now it says:

Code: Select all

[15559.850748] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114
[15559.850779] smsc95xx 1-1.1:1.0: eth0: Error reading MII_ACCESS
[15559.850796] smsc95xx 1-1.1:1.0: eth0: Timed out reading MII reg 01
[19663.408957] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114
[19663.408987] smsc95xx 1-1.1:1.0: eth0: Error reading MII_ACCESS
[19663.409002] smsc95xx 1-1.1:1.0: eth0: MII is busy in smsc95xx_mdio_read
No lockups yet (has been up for about 6 hours), but I'm a bit worried.

davidmam
Posts: 101
Joined: Tue Dec 06, 2011 4:13 pm

Re: USB - the Elephant in our Room

Sun Nov 11, 2012 11:21 pm

I still seem to be able to hang the Pi at will just by reading/writing to USB. See the 'capturing useful info thread'

ski522
Posts: 394
Joined: Sun Sep 30, 2012 2:22 pm

Re: USB - the Elephant in our Room

Sun Nov 11, 2012 11:52 pm

Jeez, I just run apt-get upgrade and my PI hangs up now. I have to unplug everything from the USB ports just to do upgrades.

gsh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1466
Joined: Sat Sep 10, 2011 11:43 am

Re: USB - the Elephant in our Room

Mon Nov 12, 2012 12:28 pm

What do you have plugged into the device? Which version did you upgrade from / to? Was it just the most recent fix to the fiq_fix_enable?

Try with fiq_fix_enable=0 to see if that is causing you problems...

Gordon
--
Gordon Hollingworth PhD
Raspberry Pi - Director of Software Engineering

ski522
Posts: 394
Joined: Sun Sep 30, 2012 2:22 pm

Re: USB - the Elephant in our Room

Mon Nov 12, 2012 12:47 pm

gsh wrote:What do you have plugged into the device? Which version did you upgrade from / to? Was it just the most recent fix to the fiq_fix_enable?

Try with fiq_fix_enable=0 to see if that is causing you problems...

Gordon
Running the latest. I have a logitech wireless keyboard dongle and a usb sound card plugged in. I will try the fiq_fix_enable to see if that helps.

rspitz
Posts: 58
Joined: Tue Jul 31, 2012 7:25 pm

Re: USB - the Elephant in our Room

Mon Nov 12, 2012 1:02 pm

Hi Gordon,

I have a PL2303 serial-to-USB adapter in one onboard USB and a 7-port active USB hub (Manhattan) in the other. The hub has a Sundtek DBV-C stick (not used at the moment) and a flash drive attached and is also powering the Pi, which works very well.

The change that introduced the MII messages was from 3.2.27+ #257 to 3.2.27+ #260. Apart from these messages, the Pi is running as before, no lockup yet after over 20 hours uptime.

I don't know what the MII messages mean, as long as they are only cosmetic I will happily ignore them.

Regards, Richard

ski522
Posts: 394
Joined: Sun Sep 30, 2012 2:22 pm

Re: USB - the Elephant in our Room

Tue Nov 13, 2012 10:23 am

gsh wrote:Try with fiq_fix_enable=0 to see if that is causing you problems...

Gordon
Only helped a bit...still lose ethernet connectivity when trying to run any CPU intensive apps like XBMC. Even unplugged my wireless keyboard dongle, but the problem continues. Runs fine if I have nothing in the USB port, but the PI is not useful to me at that point.

davidmam
Posts: 101
Joined: Tue Dec 06, 2011 4:13 pm

Re: USB - the Elephant in our Room

Tue Nov 13, 2012 4:08 pm

I tried removing the powered hub and plugging the TL-500 in directly. Locked up in about 2 hours.
So today I just left it doing nothing, just booted up and on the network on wireless with nothing else plugged in. Not much use like that but see whether it falls over. If it does I'll try a different USB dongle for wireless.

james968
Posts: 29
Joined: Tue Jul 17, 2012 8:52 am

Re: USB - the Elephant in our Room

Wed Nov 14, 2012 10:55 am

I've added a cronjob which restarts networking once an hour, this seem to have helped with the Pi's stability. (He's been up for 17 days straight now).

Run the command 'sudo crontab -e' and add the following line:

37 * * * * ifdown eth0 ; ifup eth0
#37 is the number of minutes past the hour, I just picked that number out of the air

I'm not sure how noticeable an effect it would have on something like streaming video, but for my purposes (sabnzb, and SickBeard), it seems to work. (I've also updated the firmware and the kernel as updates come out, so that could also be helping).

(My second Pi is in the mail and on that one I'll use it for XBMC, so I expect the "Observed" network traffic will be heavier, so I can see how much that command interferes with actual viewing).

EDIT: You can also add options so that it can do the reset less frequently.

User avatar
Mortimer
Posts: 924
Joined: Sun Jun 10, 2012 3:57 pm

Re: USB - the Elephant in our Room

Wed Nov 14, 2012 11:28 am

Would it be better idea to have a cronjob that pings your router, and if it doesn't get a response it then brings the interface down and then up again. That way, if you are streaming something through the interface, and it happens to be up and working at the time, then it leaves it alone.
--------------
The purpose of a little toe is to ensure you keep your furniture in the right place.

p4trykx
Posts: 127
Joined: Wed Jan 11, 2012 2:55 pm

Re: USB - the Elephant in our Room

Wed Nov 14, 2012 11:53 am

I use XBMC (xbian) but without any usb devices and I didn't experience any network problems. Just some occasional hangs. For input I use only my TV's remote through HDMI-CEC

james968
Posts: 29
Joined: Tue Jul 17, 2012 8:52 am

Re: USB - the Elephant in our Room

Wed Nov 14, 2012 2:39 pm

Mortimer wrote:Would it be better idea to have a cronjob that pings your router, and if it doesn't get a response it then brings the interface down and then up again. That way, if you are streaming something through the interface, and it happens to be up and working at the time, then it leaves it alone.
The problem I was seeing was a Kernel panic, with (what appeared to be*) a hard freeze. (With heavy network load)

*I had just plugged the monitor back in and saw the kernel panic message, didn't bother plugging in the keyboard.

davidmam
Posts: 101
Joined: Tue Dec 06, 2011 4:13 pm

Re: USB - the Elephant in our Room

Wed Nov 14, 2012 9:25 pm

I noticed that the timeout on my python USB code was set to 1000ms which seems rather long. I've tried reducing that to 100ms and will see if that improves stability.

..d

thradtke
Posts: 492
Joined: Wed May 16, 2012 5:16 am
Location: Germany / EL

Re: USB - the Elephant in our Room

Thu Nov 15, 2012 6:51 am

blavery wrote:The elephant is still in the room.
Not really, else Gordon wouldn't still work at it ;-).

It is, however, a bit strange to more than once read the USB problems just bother _some_ users. That goes without saying as there as obviously working setups, but at the same time this doesn't mean much. Plug in the wrong USB device (in my case a Behringer device that is perfectly supported under Debian) and things start going wrong. This can happen to everyone, and if someone isn't following this forum, he'll have a hard time debugging the system.
Rocket Scientist.

davidmam
Posts: 101
Joined: Tue Dec 06, 2011 4:13 pm

Re: USB - the Elephant in our Room

Thu Nov 15, 2012 10:00 am

There is definitely an issue somewhere between libusb and the device. This is readily expemlified by gphoto2 where repeated calls to the device without resetting USB fail and hang the USB stack. I also experience this with libusb (via pyusb) talking to a device - first acquisition of the device is fine, the second causes the USB stack to fall over. So I presume it is somewhere in the way that libusb and the kernel module (dwc_otg?) interact.

Trying to find out what is wrong is beyond my capabilities but I am more than happy to follow suggestions for gathering debugging info that could help those who can work on the problem.

..d

ski522
Posts: 394
Joined: Sun Sep 30, 2012 2:22 pm

Re: USB - the Elephant in our Room

Thu Nov 15, 2012 10:04 am

davidmam wrote:There is definitely an issue somewhere between libusb and the device. This is readily expemlified by gphoto2 where repeated calls to the device without resetting USB fail and hang the USB stack. I also experience this with libusb (via pyusb) talking to a device - first acquisition of the device is fine, the second causes the USB stack to fall over. So I presume it is somewhere in the way that libusb and the kernel module (dwc_otg?) interact.

Trying to find out what is wrong is beyond my capabilities but I am more than happy to follow suggestions for gathering debugging info that could help those who can work on the problem.

..d
Second that!

davidmam
Posts: 101
Joined: Tue Dec 06, 2011 4:13 pm

Re: USB - the Elephant in our Room

Fri Nov 16, 2012 3:46 pm

OK, I reduced the timeout for the pyUSB calls from 1000 to 100ms and so far the Pi has stayed up for about 40 hours and is still going strong.

My suspicions are that there is an issue in how libusb acquires devices with the dwc_otg module. I'll see if I can narrow this down with a minimal test script but don't hold your breath as my C coding is rusty and my knowledge of Linux kernel modules almost non-existent.

nothingtoseehere
Posts: 4
Joined: Sun Oct 28, 2012 7:01 am

Re: USB - the Elephant in our Room

Fri Nov 16, 2012 9:08 pm

piglet wrote:
nothingtoseehere wrote:... the fundamental problem is with the hardware design not with the software....
It sounds like you've some experience with the different hardware and the issues seen here. Are you able to opine about the scale of the changes needed to change the pi design from using the current hardware to the hardware you've used that "works"?

The question I'm really asking is whether with the knowledge you have you think it would be best (however you define "best") to expend the effort in changing the hardware & pi design at this point, or to try to work around the limitations of the current hardware in the software.

My reading between the lines was that you were indicating that the hardware route might be best.
"Best" is very relative. Yes, ideally getting better hardware would be the "best" solution. But in reality you have to consider the costs of each approach before saying what is "best". And I have no way of knowing the costs of replacing the SoC in this particular situation.

In our case replacing the hardware was the best option because we caught it early on and also because all of the extensive work on compensating for the hardware problems in software would cost us way more than replacing the SoC and making the necessary board changes.

However, our business model is very different than that of the raspberry pi. In the case of the raspberry pi there are qualified people volunteering their time to come up with a software compensation for the hardware deficiencies. Another difference is that here the profit margin is very small, which places even more restrictions on what you can do when there is such a problem. And yet another problem is that apparently this was not caught in the beta testing, when it may have been more plausible to change the SoC.

In other words, I'm not saying that a software solution cannot or should not be implemented. What I am saying is that the hardware design is faulty (I mean faulty for a host controller; the device parts may be fine) and this is why such extensive software workarounds are needed if you want to stick with that hardware.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 24930
Joined: Sat Jul 30, 2011 7:41 pm

Re: USB - the Elephant in our Room

Sat Nov 17, 2012 1:47 pm

I'd add that most chip hardware designs are faulty in some way, and software workarounds are required to fix them! So this is not a isolated occurrence, it's just that people never ever see the software workarounds as they always see a final product.

It's unlikely that the Rapsi would exist (yet) if we hadn't used the 2835. I suppose the Allwinner stuff would be possible but the tech support there is on the low side of naff all. There simply are not any decent SoC's of similar price/performance/support.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I own the world’s worst thesaurus. Not only is it awful, it’s awful."

nothingtoseehere
Posts: 4
Joined: Sun Oct 28, 2012 7:01 am

Re: USB - the Elephant in our Room

Sun Nov 18, 2012 11:01 pm

jamesh wrote:I'd add that most chip hardware designs are faulty in some way, and software workarounds are required to fix them! So this is not a isolated occurrence, it's just that people never ever see the software workarounds as they always see a final product.
Yes, but "in some way" is the key part here. It's true that there are often hardware bugs and sometimes reasonable shortcuts are being taken in the hardware design and as an embedded software developer I know the "we'll fix it in software" situation all too well. However, you do have to draw the line somewhere. Normally software development costs money because you have to pay the developers and if the hardware is so broken that it would take more money to "fix it in software" than to get a better hardware, then I think you're at the point where the fault is no longer acceptable.

And again, I do understand that the raspberry pi situation may be different due to the nature of the product and the fact that there are people who are willing and able to work on the problem for free. Although, I do wonder how much money was really saved by using such a poor USB host controller. From my recollection, in our case the difference in price between two, otherwise very similar SoCs but one with the dwc_otg and another with a proper EHCI controller was not that much.

And, from a more technical standpoint I don't see how this kind of design can be justified at all. USB host controllers are nothing new, and USB being the most popular communication interface, it should be quite well known what works well and what doesn't. I can't imagine how the designers could have thought that it is a good idea to do it that way.
It's unlikely that the Rapsi would exist (yet) if we hadn't used the 2835. I suppose the Allwinner stuff would be possible but the tech support there is on the low side of naff all. There simply are not any decent SoC's of similar price/performance/support.
I'm guessing you were limiting your choices within SoC's with high-performance GPUs, is that correct? If so, then I can't really say much about that because my experience has only been with SoC's that either have very minimal 2D GPU or no built-in GPU at all. I personally would have liked the raspberry pi just as much without the fancy GPU (and even more if that meant it would have had a more decent USB system) but then again I'm not the target audience.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 24930
Joined: Sat Jul 30, 2011 7:41 pm

Re: USB - the Elephant in our Room

Mon Nov 19, 2012 9:17 am

nothingtoseehere wrote:
jamesh wrote:I'd add that most chip hardware designs are faulty in some way, and software workarounds are required to fix them! So this is not a isolated occurrence, it's just that people never ever see the software workarounds as they always see a final product.
Yes, but "in some way" is the key part here. It's true that there are often hardware bugs and sometimes reasonable shortcuts are being taken in the hardware design and as an embedded software developer I know the "we'll fix it in software" situation all too well. However, you do have to draw the line somewhere. Normally software development costs money because you have to pay the developers and if the hardware is so broken that it would take more money to "fix it in software" than to get a better hardware, then I think you're at the point where the fault is no longer acceptable.

And again, I do understand that the raspberry pi situation may be different due to the nature of the product and the fact that there are people who are willing and able to work on the problem for free. Although, I do wonder how much money was really saved by using such a poor USB host controller. From my recollection, in our case the difference in price between two, otherwise very similar SoCs but one with the dwc_otg and another with a proper EHCI controller was not that much.

And, from a more technical standpoint I don't see how this kind of design can be justified at all. USB host controllers are nothing new, and USB being the most popular communication interface, it should be quite well known what works well and what doesn't. I can't imagine how the designers could have thought that it is a good idea to do it that way.
I'm not familiar with the specific issue in the USB controller, but note that the controller is built in to the SoC silicon - and chosen by Broadcom years ago. And yet the issue has only just arisen, so the knowledge that this is a poor design is relatively recent (your company knew I presume?) . Cost to fix the silicon? Multi millions of dollars. Cost to fix in software? Less than that, even if the Foundation has to pay for it. I have no idea whether Synopsys (the suppliers of the design) are fixing it - one would hope so, but I'm not holding my breath, and even a fixed design would not be pushed in to the 2835 - much too expensive to do a new mask, plus all the required testing.
nothingtoseehere wrote:
It's unlikely that the Rapsi would exist (yet) if we hadn't used the 2835. I suppose the Allwinner stuff would be possible but the tech support there is on the low side of naff all. There simply are not any decent SoC's of similar price/performance/support.
I'm guessing you were limiting your choices within SoC's with high-performance GPUs, is that correct? If so, then I can't really say much about that because my experience has only been with SoC's that either have very minimal 2D GPU or no built-in GPU at all. I personally would have liked the raspberry pi just as much without the fancy GPU (and even more if that meant it would have had a more decent USB system) but then again I'm not the target audience.
The GPU on the chip makes for a much better experience in a lot of areas than just having, for example, video out on an Arm Cortex.. You get HDMI, camera, LCD, accelerated 3D, 2D, encode/decode of HD video for example. All this that will ensure that the Raspi stays interesting well past the point of exhausting the possibilities of the core CPU. And for not much more than the price of a either much simpler chip, or one with naff all support.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I own the world’s worst thesaurus. Not only is it awful, it’s awful."

Max

Re: USB - the Elephant in our Room

Mon Nov 19, 2012 10:53 am

jasmesh wrote: but note that the controller is built in to the SoC silicon - and chosen by Broadcom years ago. And yet the issue has only just arisen
But was the SoC designed with the ability to attach a normal USB keyboard as a requirement?
Could be that the limitations of the USB controller did were known, but that it was considered acceptable for its purposes.
When using USB for network or storage, missed packets are not fatal, and can simply be transmitted again.
However a keyboard will not re-transmit lost key presses and releases.
jamesh wrote: Cost to fix the silicon? Multi millions of dollars. Cost to fix in software? Less than that, even if the Foundation has to pay for it.
That is making the assumption that it is fixable in software. As pointed out by others, Linux is not a real-time operating systems, and by its nature will never guarantee that any task can be completed in a fixed time frame.
Have the impression that the solutions so far are more aimed at mitigating how often the problem occurs, rather then a full fix.

(But might be wrong, as I do not know what might or might not be possible by running code on the GPU, instead of under Linux/ARM. Given there is no public information on that.)

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 24930
Joined: Sat Jul 30, 2011 7:41 pm

Re: USB - the Elephant in our Room

Mon Nov 19, 2012 11:16 am

Max wrote:
jasmesh wrote: but note that the controller is built in to the SoC silicon - and chosen by Broadcom years ago. And yet the issue has only just arisen
But was the SoC designed with the ability to attach a normal USB keyboard as a requirement?
Could be that the limitations of the USB controller did were known, but that it was considered acceptable for its purposes.
When using USB for network or storage, missed packets are not fatal, and can simply be transmitted again.
However a keyboard will not re-transmit lost key presses and releases.
SoC was designed over three years ago, when connecting a keyboard to a mobile SoC was not a common use case, so I'm guessing either wan't considered, or that was before the limitations of the design were known. But I don't know for sure.
Max wrote:
jamesh wrote: Cost to fix the silicon? Multi millions of dollars. Cost to fix in software? Less than that, even if the Foundation has to pay for it.
That is making the assumption that it is fixable in software. As pointed out by others, Linux is not a real-time operating systems, and by its nature will never guarantee that any task can be completed in a fixed time frame.
Have the impression that the solutions so far are more aimed at mitigating how often the problem occurs, rather then a full fix.

(But might be wrong, as I do not know what might or might not be possible by running code on the GPU, instead of under Linux/ARM. Given there is no public information on that.)
Corollary of that - don't assume that it CANNOT be fixed in software, which is what people commenting seem to be saying.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I own the world’s worst thesaurus. Not only is it awful, it’s awful."

Return to “Troubleshooting”