Hi.

I've just released Hijack v263:

-- some changes/fixes to the button illumination code from genixia
-- kernel compiled WITH frame pointers (larger kernel)

Those of you with MASSIVE music databases that have been experiencing kernel "oops" with Hijack installed please give this one a try and report back.

If you see an oops, please post the complete oops here, along with the exact Hijack version and model (mk1/mk2). Totally useless otherwise.

If behaviour is no better, I'll switch off the frame pointers again to save memory.

Cheers

Greetings!

Always happy to help. I am now loading Hijack 263 on my Mark2a with a huge database (emplode shows 111GB capacity, 18.9GB free, 15,133 tracks). I will let you know in a few minutes. I had been consistantly having trouble (I posted some detailed dumps and versions previously, using up to 253 most recently), and I will let you know in a few minutes. Since I am able to reproduce the error every time, I will know soon...

Note: my drives were booted cleanly, so there was no disk trouble before this test...

Testing... Loading 263... emplode... Changing IP address to force a full sync... Syncing...

Hm!!! Looks GOOD! This would not have worked for me before!

Testing... emplode... more radical changes... syncing... rebuilding database (for me, a long task)...

Hm!!! Still looks GOOD! This would not have worked for me before!

Okay. Now for the harshest test. Previously, I could not even upload a file via FTP or serial without the kernal bailing on me. Now... drop to shell... rw... rwm... cd /drive0/mirror (where I keep my mirrordb symlinks for http amusements)... rm -rf empeg-car... running... GOOD! swapon /swapfile... mirrordb... WOW!!! rom... ro... reboot!!!

IT WORKS!!! THANKYOUTHANKYOUTHANKYOUTHANKYOU!!! Grovel, grovel, cringe, bow, stoop, fall, worship, worship, beg, kneel, sponge, crawl...

Tomorrow, I will test this out on my other unit, and validate it with FTP and the network...

Good that it works but it's typical now that Mark can debug it more easily, that you don't have the problem

- Trevor

It's working fine for me too

Impressive, Mark!

Questions:

- The "massive music databases" problem... Is that a hijack-only thing, or is that bugfix something the default software could also take advantage of?

- What changes were made to the illumination code? Can you provide more details?

What changes were made to the illumination code? Can you provide more details?

2 changes.

Firstly the dimmer detection has been reworked so that it works in my car. Hopefully it still works in yours! Seriously though, the previous code didn't deal well with PWM dimmer lines leading to psychadelic displays when my headlights were on. Cool, but annoying as hell after a couple of minutes. This shouldn't break anything for anybody, and as I was the only one so far (AFAIK) to see this issue, it wont fix anything for any other current users either. Although anybody else with a late model VW considering the hack would have hit it, and that probably applies to Audi and possibly BMW owners too.

The other change is a fix to the timing of the command. The command byte is supposed to be delayed 0.1s after the PIC has been woken and told to expect it. Due to a bug, it was only being sent if it was within 0.1s, and discarded otherwise. This was leading to commands sometimes getting lost, and I also saw the 'dimming capacitor' problem as well which now seems to have gone. (Possibly caused by an 'impatient' command being misinterpreted as a display command byte?)

The down side is that now, everytime the button level is adjusted in the menu there is a lag - especially when reducing the level as the LED is first turned off, and then brightened in multiple 5% increments, each taking about 0.125seconds. I'm not happy about this lag and I'm still looking at this, but I think that having robust illumination that reacts predictably to the dimmer line is the end goal - the menu is just a means to an end.

Let me know if you see any other issues arising from these changes..

Thanks, I'll report if I notice any problems in the car tomorrow.

YEah, but I actually kinda expected that.

Wayyy back I turned OFF the frame pointers for Hijack kernels (they're ON by default in the "stock" Empeg kernels) to save some RAM and speed things up a fair bit. But it was always somewhat "iffy", since there may be compiler/kernel bugs (long since fixed) that rely on the existance of frame pointers.

So, now that we've shown they're needed, I'll leave them "ON".

Cheers

>The "massive music databases" problem...
>Is that a hijack-only thing, or is that bugfix something
>the default software could also take advantage of?

I didn't actually fix anything.. just told the compiler to generate "frame pointers" in the executable code again -- standard Empeg kernels normally have this enabled. Very early on in Hijack I disabled the frame pointer code, since it is not normally needed for anything, and just takes up space and costs 5% of CPU usage or so.

But there could be an ancient 2.2.xx bug (kernel or compiler) that surfaces when frame pointers are not present, so I've turned them back on again for now. Seems to be behaving better for folks.

My other StrongArm-based box (a Netwinder) works happily with a 2.2.xx kernel and NO frame pointers.. go figure.

Cheers

Hmm I'd love to hear ( Hugo || Mike || Peter )'s comments on something like this, as I'm sure we'd all love that memory and 5% CPU utilization back... Maybe if we all upgraded our toolchains we could get past whatever code needs frame pointers?

If it's in the kernel, is there some call we can look for to find it?

nnnnnn no.. not 5% overall, just maybe 5% or so within the kernel, which might work out to .001% (or less) overall.

Cheers

I think I recall it was dying in ext2_new_block().

-ml

Ahhh... I can live with that. The memory savings would be nice, of course, but I'll take sync stability over a few kb of memory.