Okay, a number of people, including His Esteemed Faqness, have reported temporary IR lockups (lasting 10-20 minutes) on their players in recent betas.

Unfortunately, it never seems to happen for me, and I'm one of the few around here who could diagnose one if it did happen. Darn.

But.. based on Tony's lucky coicidence of having such a lockup with a Hijack PopUp message at the same time, I can only conclude that the cause, as highly improbable as it seems (totally friggin impossible), is that the O/S "jiffies" counter must be stopping for whatever reason.

So.. As of Hijack v221 (now available), there is code within Hijack to detect such an occurance, and to display a pair of suitable messages on the screen.

Please, everyone, install this update, and report to me (both on the BBS and directly if you ever see one/both of these messages on the display of your RioCar/Empeg:

    ERROR: stuck jiffies

or

    unstuck at 500.34 secs   (any numeric value is fine)

Also don't forget to say which version of player software was installed, eg. v2.00-beta11.

Thanks

thank you mark.. your a pal.. i just wanna note... that it only seems to happen when its in "ac/home mode" never when its in car.. if that helps your any or confuses you more.

not true. Locks up in the car all the time for me and others. =]

Mark, i upgraded the kernel and i've got it playing and will all day until it locks up. Hasn't happened yet though.

I have seen it happen in both home and car modes, so that's not a data point.

And Mark, there's no need to refer to me in such a formal tone. "Sir FAQ Master" is plenty.

lol.. well i guess thats just my situation.. i always foced dc mode to have it not lock up on me.. and the good news is ive had the player running for the past 30min and no lock up... yippie.. so ill see how it goes

Sir FAQ Master, and other esteemed viewers, I may have found a cause of the lockups. I was tracking down the "jiffies" issue, and noticed a Hugo-ism in the kernel timer code, where he has some code which he says must run uninterruptable to reset the jiffie timer.. but the code fails to mask FIRQ's.

It's a single-character fix, and I'll put it out in v222 later today.

Of course, this is all just theory, so.. from v222 onwards, if you ever experience a lockup with Hijack, let me know.

In the meanwhile, does anyone recall exactly what FIRQs are used for on the RioCar (Mk2a)?

-ml

*crosses fingers*

ok mark player locked up.. and no message or hijack saving.. anything you want me to do or information to gain while its in this locked state.. as i said before i can still access the hijack menu.. but the player itself it locked up

Mmm.. that's different from Faq Master's lockup -- your jiffies are still working.

Point your browser at http://your.empeg/proc/interrupts
and refresh a few times: see if you can identify whether
or not "timer" is incrementing (yes), and SMC9194, and rdsirq
and any others. List them for me (or just save two successive
snapshots of the page).

Also look at empeg_ir and verify that it updates when you press on the remote.

-ml

Also, a few successive samples from /proc/stat might be useful.

-ml

ir codes work.. but the ftp/http dose not

ok heres what i got i kept hitting refresh till it froze again..

If your IR codes are working, then that's different lockup that the one we're looking for i believe.

Two of those displays, one right after the other, would be useful.

One by itself is not really.

Cheers

alrighty.. ill try and repeat it again

one erroe i notice when booting the player is this

Tried to mount /dev/hda4 as reiserfs but got error 19 coudl that have anything to do with it?

No, that message is just "normal drivel".

I assume the bug y'all are talking about is where all input is locked up? Lately I've been having this problem: When I hold a button on the remote -such as search, volume, equalizer, info, etc.- the player does nothing. But when I let go of the button it acts if I had just pressed it once instead of holding it down. It doesn't do it everytime. Perhaps my remote battery is dying? I hope it's not something wrong with the player.

ok mark i have a series of 4 messages.. in order
------Part1------
0: 0 empeg_state
1: 0 empeg_usbirq
2: 0 empeg_cs4231
3: 34020 empeg_rdsirq
4: 199 empeg_input
6: 5499 ide0
7: 97 SMC9194
17: 147 serial
20: 1102 audio-empeg
26: 2923 timer
FIQ: cs4231dma

------Part2------
0: 0 empeg_state
1: 0 empeg_usbirq
2: 0 empeg_cs4231
3: 49230 empeg_rdsirq
4: 199 empeg_input
6: 5499 ide0
7: 142 SMC9194
17: 147 serial
20: 1592 audio-empeg
26: 4202 timer
FIQ: cs4231dma

------Part3------
0: 0 empeg_state
1: 0 empeg_usbirq
2: 0 empeg_cs4231
3: 67029 empeg_rdsirq
4: 199 empeg_input
6: 5499 ide0
7: 301 SMC9194
17: 147 serial
20: 2165 audio-empeg
26: 5699 timer
FIQ: cs4231dma

------Part4------
0: 0 empeg_state
1: 0 empeg_usbirq
2: 0 empeg_cs4231
3: 94465 empeg_rdsirq
4: 253 empeg_input
6: 5500 ide0
7: 504 SMC9194
17: 147 serial
20: 3048 audio-empeg
26: 8006 timer
FIQ: cs4231dma

and the player crashed in the matter of seconds after the last one.

Nothing I can do for that one. Different issue from the "button lockup issue".

But if I worked at SonicBlue, and could reproduce the problem, I'd use Hijack khttpd to surf to /proc/nnn/ and examine what each of the player threads was doing, to see which one was stuck in a loop.

But that would require player source & map files.

Cheers

so tis kidna hopeless.. its pretty hard to reproduce the problem.. it jsut kinda dose it from tiem to time.. but like i said its only done it in "home/ac power" so my solutions is jsut to run it in car mode.. and everything is fine.. the car is the mode im more concerned about anyways.. i only bring it home for hacking and laoding music.. not for really using it as an alternative player..

Ok, my player has a unstuck at 0.0 Secs displayed on it. Im running 2.0 beta 11.

The clock and counters appear to be incrementing ok right now. Also, I noticed my clock has fallen 18 minutes behind since i set it 2 or 3 days ago.

Sean

http://empeg/proc/interrupts

0: 0 empeg_state
1: 0 empeg_usbirq
2: 0 empeg_cs4231
3: 16809834 empeg_rdsirq
4: 3244 empeg_input
6: 42016 ide0
7: 1773 SMC9194
17: 146 serial
20: 540707 audio-empeg
26: 1296006 timer
FIQ: cs4231dma

0: 0 empeg_state
1: 0 empeg_usbirq
2: 0 empeg_cs4231
3: 16828466 empeg_rdsirq
4: 3244 empeg_input
6: 42016 ide0
7: 1794 SMC9194
17: 146 serial
20: 541307 audio-empeg
26: 1297572 timer
FIQ: cs4231dma






http://empeg/proc/stat

cpu 381874 0 39154 879257
disk 2112 1456 0 0
disk_rio 2089 1456 0 0
disk_wio 23 0 0 0
disk_rblk 4178 2912 0 0
disk_wblk 46 0 0 0
page 131097 384
swap 0 0
intr 18750577 0 0 0 16860729 3244 0 42016 1804 0 0 0 0 0 0 0 8 0 146 0 0 542345 0 0 0 0 0 1300285 0 0 0 0 0
ctxt 1508455
btime 1014914061
processes 159


cpu 382700 0 39265 879983
disk 2112 1456 0 0
disk_rio 2089 1456 0 0
disk_wio 23 0 0 0
disk_rblk 4178 2912 0 0
disk_wblk 46 0 0 0
page 131097 384
swap 0 0
intr 18772672 0 0 0 16880513 3244 0 42017 1814 0 0 0 0 0 0 0 8 0 146 0 0 542982 0 0 0 0 0 1301948 0 0 0 0 0
ctxt 1510454
btime 1014914061
processes 160

Okay, that's cool. Once the "unstuck" message appears, the problem has already gone away again.

And I guess it will always say "0.0 secs", so I'll change that message next time to show something more useful.

But the fact that you even saw it, indicates that jiffies took a pause somewhere -- kernel still running, but clock interrupts (for scheduler) not working, briefly.

That's the bug that might go away when I release my fix for Hugo's timer interrupt routine.

Cheers

Speaking of which, does the clock get corrected on reboot?

(while running, the Hijack clock display is from the kernel, not the clock hardware.. if the jiffies bug occurs, the kernel clock value will lag, but the clock hardware will continue to maintain reasonably accurate time..)

Very interesting! Yes it did correct the clock on reboot.

Mark, may I suggest you NOT fix Hugo's bug until you know for sure it's the cause of the problem? This problem seems to be intermittent, so it's a good idea to give people a chance to duplicate it. It will happen on my player at least once every two days, so I'll install a new Hijack tonight. Unfortunately it tens to happen when I'm in the car (I don't play tunes much at night unless I'm working on something player-related).

I'm sure you'll have a lot of feedback in this thread by tomorrow night.

Bruno

In reply to:

---

When I hold a button on the remote -such as search, volume, equalizer, info, etc.- the player does nothing. But when I let go of the button it acts if I had just pressed it once instead of holding it down. It doesn't do it everytime. Perhaps my remote battery is dying?

---

I sometimes get this on the front panel, normally only when the disk-access icon is up. Don't know if it's related, but it's an extra datum.

It's a single-character fix, and I'll put it out in v222 later today.

Got a diff for just this fix?

In the meanwhile, does anyone recall exactly what FIRQs are used for on the RioCar (Mk2a)?

Um, I thought ARMs have IRQs and FIQs, which makes it hard to know what the FIRQ you're talking about ...

Peter

Duh.. stuck midway between x86 and ARM these days.. Yeah, I meant FIQ. The fix is to just change the save_flags_cli() call into a save_flags_clif() call in the reset_timer() routine in the kernel. Hugo already knows about, too.

Cheers

>may I suggest you NOT fix Hugo's bug until you know for sure
>it's the cause of the problem?

Yeah, I'm thinking that too.

But there is no question that it's a real bug, and also that it causes at least some of the lockups. The buggy code executes 100 times/second, and only needs to be hit once with a simultaneous FIQ to be triggered.

Remember the lockups we had when I first added the temperature-reading code into Hijack? Those happened reasonably often, and were due to exactly the same coding problem. Except this new bug has a about 200 times the probability of occuring.

Most of the time, it will be barely noticeable, but some of the time it could lock up the player for as long as 19 minutes or so (32-bit timer at 3.6864mhz) -- which is pretty much what people are reporting here.

But a little more data would be nice to confirm all of this. So, I'll put out v222 this morning, WITHOUT the fix, but with more data collection for when it happens.

Cheers