EtherUSB 0.13 works, EtherUSB 0.24 doesn't

I recently upgraded my BB-xM to RISC OS 5.20, and the network connection – which had operated quite happily up to that point – threw a hissy fit. Some frantic Googling later, and I managed to fix (by which I mean bodge) the problem.

If the computer is booted with EtherUSB 0.24 in ROM, then it completely fails to detect the existence of an Ethernet port. EJInfo lists the supported interfaces but goes no further.

If EtherUSB is unplugged, forcing 0.13 to be softloaded from System, then it works.

If EtherUSB 0.24 is RMReinited, a further call of EJInfo shows the correct information.

If EtherUSB 0.24, having been loaded from ROM, is then manually RMReinited immediately before DHCP resolution starts, it works. (This was the solution I eventually went with.)

And if some previous version (whatever was current in May 2012) is loaded from ROM, it works. (I say this because it was working before.)

It seems I’m not the first person to have problems with later versions of this module. The RMReinit EtherUSB bodge is quite widely mentioned – this was how I discovered the cure.

What is the cause of this problem? Has it been fixed in the development versions? If not, could it be?

EDIT: Bleh, it’s late. Could this be something to do with the changes to USB device initialisation? If so, is there a fix for that?

Does changing which USB devices you have connected, or changing which ports they’re plugged into make the problem go away? I’m tempted to say that the problem could be down to the RMA becoming full and OS_ChangeDynamicArea temporarily being unable to grow it, causing EtherUSB or the USB device enumeration to fail (e.g. similar to this problem)

At one point I did create a modified kernel which would log all SWI errors to a block of memory to help try and diagnose these kinds of problem – when I get a chance I’ll try resurrecting the code and uploading a ROM for you to test with.

I have the same problem since last week with my xM and 5.20. I never change the Hardware in last two years. I was afraid my board died because RISC OS acted like my BB C4 without LAN. Sometimes the connection comes back, if I wait long enough during boot up (10minutes, 30minutes …). Later I will try Martins way.

I’m running 0.24 on both my BBxM (RO 5.20) and RPi (RO 5.21 (08-Jul-13)) and haven’t seen any problem on either machine.

Both machines have quite generous power supplies (2.5A).

Over here is an OMAP3 ROM with my SWI error logging code enabled. If you can try running it, use *dadprint to dump out the log once you reach the desktop, and then send me the log then I’ll have a look through it to see if I can spot anything obvious that’s going wrong.

FYI the log is in the following format:

(SWI number) (SWI return address) (error number) (error message)

It’s also normal for there to be quite a lot of “memory cannot be moved” errors – those are from where RTSupport is trying to map memory into/out of its dynamic area from within interrupt code. Luckily RTSupport is using a sparse dynamic area, so the error comes from a slightly different place to if it was (e.g.) the RMA running out of room – so it’s easy for me to filter them out when looking at the log (the errors from RTSupport should be mostly harmless, as it tries to keep a safety buffer of free memory that it can use from interrupt code).

“… and then send me …”

I have do so.
It looks like the problem is only with my xM Rev.C not with Rev.B.

Thanks

I’ve had a look at the log Raik sent me and it looks like the problem is being caused by OS_ChangeDynamicArea failing due to application space being in use (PCI_RAMAlloc is failing when the USB drivers try to allocate the DeviceFS buffers for EtherUSB to use). So it looks like this is a fairly common (and annoying!) problem.

I’ll spend some time looking at both the ROM initialisation and the boot sequence and see if I can track down the bits which are stopping application space from being moved. It’s pretty ridiculous that the OS tries to put all available memory into application space on startup – this may have made sense when we only had 1MB of RAM, but with modern machines having gigabytes of the stuff I think it would make much more sense if we limit it to something more sensible like 4MB, and keep the rest in the free pool so that dynamic areas won’t have trouble resizing themselves.

I’ve uploaded a new ROM image which I’m hoping will fix the issue. It looks like there was only one place in the kernel which needed changing to stop the OS from moving all the memory into application space on startup (the boot sequence looks like it should be fine).

This new ROM still has the debug code enabled, so if it doesn’t solve the issue then a new log file would be appreciated!

I try any things this morning. It woks stable and better than the last ROMs I try, also 5.20.
Network is working without problems, my HD is detected fast (since long time ago there was a delay from 5-10s, with the latest ROMs (…-1.May) the HD was not detected and not working).
But *dadprint gives many missings, overflows… I will send.

Many thanks.

I wonder if the problems I sometimes see with my BBxM are related.

Occasionally at boot it just sits there waiting for the HDD to be ready. The HDD, meanwhile, has faded its light off, presumably having waited long enough and lost interest.

Also I’ve noticed on a few occasions recently that the mouse will randomly stop moving for a period of up to a few seconds. Last night the keyboard even stopped responding until it was re-plugged.

I’ve submitted my changes to CVS, so they should show up in tomorrow’s ROMs.

But *dadprint gives many missings, overflows… I will send.

I think those errors are normal. They’ll usually be generated by code trying to check if a system variable exists, or by code which reads the length of the variable before reading the value (reading the length usually involves providing a zero-length buffer, so the SWI returns both the length of the variable and a buffer overflow error).

I have try your “Debug-ROM” yesterday with all my “problem-child”. Nothing to complain about.
I hope with the tomorrow’s ROM it is the same.
Many thanks.

Todays ROM is not working at the same way like the second “Debug-ROM”.
EtherUSB is working but my HardDisc is not detected and a Pendrive is also not working. Back to the “Debug-ROM” all things fine on my xM.

my HardDisc is not detected

I upgraded my BB to todays ROM and after rebooting, it did not detect my SSD main drive (Fat32 formatted). It wasn’t even seen if it was unplugged and replugged. Going back to the 21 Apr ROM and everything is fine.

And if you try this ROM from this post ?

Thought I’d give it a try. I normally run from the uSD card on my BB -xM using a SystemDisc partition. That works fine with today’s ROM – can’t make it go wrong.

Tried plugging in a spinning HD but still using the uSD as the boot drive. Restart got as far as lighting the keyboard lamps then froze before getting to initialising the ROM modules. All BB -xM LEDs stayed lit too. Pressed the reset button (see, it does have a use) and the BB -xM started normally to the desktop.

Tried using the HDD (filecore) as my boot disc and it froze as before but again only once. A second restart was OK.

Related?

And if you try this ROM

Just tried it now and it boots up fine. The Fat32 SSD is found. The DHCP also seemed a bit quicker.

Can people try this ROM and let me know if it’s any better? It’s built from the latest code, except I’ve gone back to a slightly older version of USBDriver (the one before this change). The debug ROMs I was posting to this thread didn’t have that change either, so I’m thinking it’s that change which is causing some of the issues.

Just tried it, Jeffrey, and it boots to the desktop fine, the Fat32 SSD is found, and all my core apps run from the SSD.

Can people try this ROM

Tried the same tests as before. Can’t reproduce the hangs. Not definitive given the previous 1st boot only result but seems good.

I have also tried it. Works fine with Net and HD (and Pendrive).

Can people try this ROM and let me know if it’s any better?

I’ve been running it since shortly after you posted. It looks OK. I haven’t seen the mouse pointer pause. It will be a month before I know whether the “Waiting for HDD to become ready” has gone away, because it only happens on a small minority of start-ups.

But I was running the 5.20 ROM before.

OK, so it looks like it’s the change to the device initialisation which broke everything. Now I just need to work out how to fix it ;-)

You might like to see if this has anything to do with the troubles experienced by users of the Focusrite Scarlett 2i2 USB audio interface.

I have often wondered if there are USB devices out there that do not initialise as fast as the USB specifications require, and whether we would see less problems from users if we allowed a bit longer. But I say that from an entirely naive POV. All my USB experience has been as a user of the stack.

The USB drivers are already pretty generous with the delays they give devices upon initialisation – see the delay values listed here. Although in some cases it looks like making the delays too long can cause problems rather than solve them.

It’s also possible to tweak some of the delays using system variables, although I’m not sure off the top of my head which ones this applies to.