Rev C3 Beagleboard lockups

Recently I’ve been getting more and more random lockups. Quite often all the attached USB devices stop working. The clock continues ticking though. As well as the lockups networking stops working after a few seconds. The problems happen even booting to just the supervisor prompt but mainly as soon as the desktop appears.

I originally thought it was a problem with the hub I’m using. I swapped it for another but the same problems kept happening. Then I remembered each time I built a new rom I kept a previous build on the SD card. So with a bit of trial and error I found going back to a rom I built on 1st Feb all the problems go away. The next one I have was built on the 1st March. The lockups and network timeouts come back with any rom from this one onwards.

Hmm, would be nice if the revision viewer went back more than the 20 most recent changes :(

I think the only real thing I did during February was write the first version of the OMAPVideo driver – so there’s a chance it could be that which is causing problems. If you open HAL.OMAP3.hdr.omap3530 and change HALDoesVideo to TRUE then it will switch the OS back to using the old video driver – try that and see if it fixes it.

At the same time as checking in the new video driver I also checked in some interrupt-related fixes for Sound0HAL (aka SoundDMA) and the USB drivers, and some Kernel fixes (specifically, the abort handler for the cache/TLB maintenance ops). Are you sure that your local sources contain all those fixes? Does the ROM that ROOL uploaded a couple of days ago suffer from the same problems?

If you’re getting a complete lockup then you could try using enabling the FIQDebug code (in HAL.OMAP3.s.Boot) and seeing what address(es) it prints out over the serial port when you press the USER button (Remember to call the magic SWI to enable the code – SYS "OS_Hardware",123,,,,,,,,0,100)

If it’s something less fatal then you’ll probably have to try enabling the DebugTerminal (in Kernel.hdr.Options) and see if you can get anything useful out of the OS during/after the crash. If USB just dies without giving any error message then you may also want to try building debug versions of the USB modules (debugging the USB drivers is a whole different story, but there’s a rough guide to building and using the debug drivers here)

Good luck!

Hmm, would be nice if the revision viewer went back more than the 20 most recent changes :(

CVS exports committed logs to an external history file via cvslog2web, a Python script with a configurable limit on the number of entries it stores. I’ve increased this to 100. The Rails front-end has no internal limits or pagination, so will just display whatever is there. The way cvslog2web is written seems to not lend itself to very huge history lists as it’ll start chewing up an awful lot of RAM and CPU time both during commits and during subsequent history reads (100 may well prove too large).

New commits should hopefully now start adding to the list, without old items dropping off the end, until the new limit is reached. It isn’t possible (or at least very hard and beyond me at present) to get CVS to re-export its historical set of all logs in order to re-populate the cvslog2web data with 100 entries straight away.

https://www.riscosopen.org/tracker/repository/changesets/276

I tried the latest downloadable rom. That does the same thing.

If you open HAL.OMAP3.hdr.omap3530 and change HALDoesVideo to TRUE then it will switch the OS back to using the old video driver – try that and see if it fixes it.

It’s a lot better switching back to the old video driver. Networking still stops although I can now resurrect it without rebooting. I’ll have a go at trying your debug suggestions. Not sure how far I’ll get but worth a try.

CVS exports committed logs to an external history file via cvslog2web, a Python script with a configurable limit on the number of entries it stores. I’ve increased this to 100.

Cheers – that should be a big help when things like this crop up.

It’s a lot better switching back to the old video driver. Networking still stops although I can now resurrect it without rebooting. I’ll have a go at trying your debug suggestions. Not sure how far I’ll get but worth a try.

Interesting. I’m in the process of fixing/tweaking a few bits to try and solve the IGEP problems; with any luck they’ll help with your problems too (although AFAIK most of the problems I’m fixing were in the HAL driver too)

I’ve now got a fan blowing air from underneath the board and since doing this I’ve had no lockups or network hangs.

What temperature is your board running at? (See WPB’s CPUTmpMon referred to in the RISC OS on IGEPv2 thread )