I upgraded my Mark II with a 2nd hard drive. It works just fine at home with the AC power supply but in the car, it says "No Hard Disk Found"...

Anybody experience this?

Is the battery icon on?

...and what version are you running?

I seem to recall that another user who had this problem traced it to some kind of a wiring problem where the player wasn't getting the proper amount of power.

...which was that he had crossed the switched 12V and permanent 12V lines. The Mk2 (empeg) would run on that, the Mk2a (Riocar) was modified to prevent fuse blows and other naughties (including track burnouts) and won't.

Well remembered. I'd get a multimeter onto the power lines and work out which one is which.

So you're saying that "no hard disk found" is the 2a's way of telling you that your wires are backwards?

This is surprising. I would figure that it would either work normally (but perhaps behave oddly with respect to ignition on/off cycles), or it would fail to work altogether. Having it get enough juice to fire the display but not the disks sounds odd.

Hugo, if you're reading this, can you comment?

Well, a VFD requires relatively little current to light up; conversely, two disks would pull one huge starting current spike.

A desk based PSU bypasses the sled wiring connections directly to the regulation circuitry; in the sled, if he has the sled wiring the wrong way round, then there will be insufficient current available to spin up the disks. They won't start up, hence the kernel probe will fail and you get the "Disks not Found" message.

2.0b3

Doug,

2.0b3 is really buggy, and you should be running either 1.03 or 2.0b7. 2.0b7 has its own share of bugs, but it's not quite as bad as 2.0b3.

If you're running a Hijack kernel, make sure you have the latest one. I think he fixed a bug recently where it might say "no hard drive found" in certain situations.

He did. I got the no drives found message about 75% of the time, but only if I had HiJack installed. Seems he changed what bit did what in the flash somewhere on the way...

Here's his instructions to fix it:

Sounds like the "1/2 drives bit" is toggled in the flash memory.
Here's how to check it: install hijack (latest version), reboot.
As soon as you see the display light up, press and hold the knob to get the hijack menu, and then go check/fix the setting.

I'll add that you might want to check over all the settings in HiJack, not just 1/2 disk detection, and that I needed another reboot after fixing the settings to make it behave properly again.

/Michael

No hijack...but I found with 2.0b7 the front panel buttons would lock up all the time. I will try it again though and see if it helps.

I found with 2.0b7 the front panel buttons would lock up all the time.

Yeah, that's a known bug in 2.0b7.

In that case, how about running the known-good 1.03?

No luck with 2.0b7, 2.0b3 nor 1.03.

With 1.03, I just get the Empeg Penguin welcome screen and it sits there.

I think my power leads are connected correctly because it doesn't reboot if I turn my ignition off for only a short period of time.

I'm stumped. Call support?

Support, for an upgrade I performed myself?? I guess I'll probably just pull out the 2nd HD, hope I didn't fry something.

Support, for an upgrade I performed myself?

Yes. The worst they can do is say "no". And somehow, for someone who's been around as long as you have (for those who don't know, Doug316 sold me my first Mark1 which I still have), I would imagine they'd be happy to help you. Especially if the problem was unrelated to your drive upgrade (and I imagine it is probably unrelated to your upgrade as long as you were careful).

You're very unlikely to have fried something if one drive is working, they're on the same cable and share the same signals.

Hugo

Right--and since it works at home. Maybe I'll just pull out the 2nd drive and live with my 18GB...

Here's what I would do in your situation:

#1: Upgrade to v2.00b7 (or b3, but b7 is much better). This upgrade is needed for step #2 below.

#2: Install the Hijack kernel -- it has some useful features for debugging, as you will see.

#3: Fix your front panel buttons, by adding these lines to config.ini (not a 100% fix, but almost):

[Startup]

ReserveCache=12

#4: Now that everything is in place, plug the unit in at home, on the AC supply, and hook up the serial port to a terminal emulator so we can see what is happening.

#5: To reproduce in-car behaviour while on AC power, press and hold the KNOB (or MENU on the remote) until the Hijack menu appears. Go to the "Force AC/DC Power Mode" item, and use the knob to change the setting to "Force DC/Car", and then reboot when prompted.

If both drives work, then pull the power plug, wait a few seconds, and plug it back in again. If they still work, well that tells us it is power related. If they don't work, then.. time to look at the serial output and perhaps post it HERE for us to look at.

Cheers

Ok, I think I have discovered the problem. Hijack was helpful!

I think the Empeg is not giving enough time for the 2nd hard drive to spin-up before it checks for it. When the boot fails, I go into the hijack menu and reboot, and it seems to come up just fine. Can the delay be increased?

I think the Empeg is not giving enough time for the 2nd hard drive to spin-up before it checks for it.

Aha. Good catch!

From the Drive Upgrade Guide:

Another possible compatibility problem is if there's an extreme difference in spin-up time between the two drives, it might cause the second drive to time out if it takes too long. So you may want to consider installing your drives as a matched pair. This isn't strictly necessary, and if you're lucky, you might be able to work around these kinds of problems simply by swapping the drive order.

Yeah, you can fix that in the kernel source code, if you like.

Just edit drivers/block/ide-probe.c, and locate this line:

     } while(on_if0<2 && retries<20);

Assuming you don't have a mk1, just change the 20 to, say, 40.

-ml

Any chance of making this a configurable option??

Compiling my own kernal will not be easy for me.

you'll have to talk with rio support about that.

-ml

Actually, have you tried a Hijack kernel in this setup yet?

Hijack DOES do the detection slightly differently, and might work fine as-is. Otherwise, perhaps I'll tweak the timeout slightly for you (and everyone else will also have to suffer with it..).

-ml

(and everyone else will also have to suffer with it..

...which is OK, since single-drive users can still use Hijack's 'skip check for second drive' feature.

Yes, I have noticed it's a bit more reliable coming up with Hijack, not 100%...how hard would it be to make a "fast" and "slow" setting? Thanks for considering.

I don't really want to use up one of my few remaining flash bits for this, so instead I'll just lengthen the timeout slightly when Hijack v152 comes out (could be a while yet, I'm overhauling something..).

Cheers

How much longer will it take for the empeg to boot up then?

>how much longer will it take to boot

If you have two drives, no longer than at present.

If you have one drive, a few seconds longer, until you go into the Hijack menu and set the "Hard Disk Detection" to "One Drive only".

Cheers

How many total flash bits are there?

Calvin

The flash savearea is 128 * 8 = 1024 bits in size. Hijack "hijacks" 64 of those bits, and could be kicked out at any time if the Rio player software ever claims those bits (looking more likely by the day..).

Cheers

if the Rio player software ever claims those bits (looking more likely by the day..).

So maybe it's time to think about that "raw writes to a file on the disk while mounted read-only" strategy you have on your to-do list?

Someday soon. But that doesn't help with the data that MUST be read before the config.ini file can be read in (most of the bits)..

Cheers

Someday soon. But that doesn't help with the data that MUST be read before the config.ini file can be read in (most of the bits)..

True... That's a dilly of a pickle...

Is this working for you now with the latest Hijack kernel?

Nope, still have to manually reboot.

Okay, I'll bump up the timeout some more for v168. Once we get a timeout that works for you, it should be fine.

Still no dice...you think maybe you could build me a special image with a rediculously large delay and we can see if that solves the problem? I'm thinking maybe the delay isn't in the right place.