I have been doing some development recently and thus need my Empeg to be at the shell prompt for long periods. During this time, the drives do not spin down as they do when the player is running. Is there any way to manually spin down the drives? I don't want them to just be spinning for no reason if I'm going to be on my other Linux box hacking and cross-compiling for 20 minutes before I FTP my programs over to test them. The obvious solution is to exit to the player each time but that's a pain.

Computers without power-management operating systems normally keep their drives spinning all the time. I don't see a big problem if you're running power from AC. It's not like you're using a laptop whose battery is about to die. :)

Bruno

Umm I'm not concerned with power, I'm concerned with the drives lifespan being shortened by spinning for no good reason. I should have been clearer in my post.

You were clear. The MTBF on those drives is pretty high. I doubt there's a problem. But I'm also sure there's probably a solution, even if using some other program to spin them down.

Yah MTBF is high but any amount I can help save my drives is good for me. I wouldn't mind running a program to do it. Or maybe I could even write a little daemon to do it if I knew the right ioctl's to call.

Yah MTBF is high but any amount I can help save my drives is good for me.

If I remember right, it's more stressful on a drive to spin up and down then it is to stay spinning for a long period of time. Most of the Y2K "problems" were caused by companies shutting down ancient hard drives (the tower sized ones that probably stored a few hundred megs at best) then trying to get them to spin back up. MTBFs are so high anymore that either is not really a concern. But again, spinning them down and up will probably shorten that time.

What he's saying is that he wants to be able to send the command to spin down the drives in the same way that the player app currently does the same thing. I think it's a valid question, and the answer (if anyone is able to give it) should be put up at the Riocar developer section.

In nore ``normal'' Linux distributions, the command to spin down a drive is ``hdparm -y device''. I don't know if this is on the empeg, but you should be able to recompile it or just rip the appropriate code out of hdparm's source.

Thanks for the tip. I did a freshmeat search for hdparm since it wasn't included with the standard ARM debian distro... And lo and behold look who the author of hdparm is. Should have known!

It works as advertised. hdparm -y does indeed spin down the drive. There are some other tuning parameters but until I know what they do I'll stick to that one.

Anyway I built hdparm 4.4 and I'll attach it here for anyone who needs it.

look who the author of hdparm is

That's funny. I was going to find it for you, but then I said, ``Nah. He can find it for himself.'' Good thing he's gone. Otherwise, I'd never get to answer a question and just end up being a smart ass all the time.

and just end up being a smart ass all the time

"Not that there's anything wrong with that." Every forum needs a few smartasses to balance things out.

As to the fact that IE decided it was a text file and the vagaries of line end translations, could you provide the md5sum of the file? Or repost it in a zip file, which does seem to work across platforms...
md5sum for windows is available here (*nix users most probably already have it on their system)

a050cd24acd58859f414cb0a7354d937 is the md5sum I get here

/Michael

a050cd24acd58859f414cb0a7354d937 is correct.

Thank you!

/Michael

Well, Mark did say he was the Linux IDE guy. Or maybe that info's only on his web page and I'm the only one that's read it.. :)

Bruno

No, he said so on this BBS.

We do a WIN_STANDBYNOW1 to spin a drive down, and a WIN_IDLENOW1 to spin it back up. We do this so that we have complete control over the disks; if we leave it to the drive then the app blocks during spinup if it needs something desparately from disk to continue.

eg:
const unsigned char spindown[4]={ WIN_STANDBYNOW1, 0, 0, 0 };
ioctl(harddisk_fd,HDIO_DRIVE_CMD,spindown);

IDLENOW1 is 0xE1 if you can't find it in the header files.

Hugo

Excellent. This is probably what Mlord's hdparm is doing under the covers. I hadn't had a chance to delve through the source yet. This will help me out a lot (and save my precious hard drive life.)

Note to all (including the Empeg folks):

Rather than explicitly using "hdparm" (or the IDE ioctl() interface) to spin drives up/down as needed by each induhvidual usermode application (which WILL lead to conflicts..), why not just let the drive do it all for you??

hdparm -S1 /dev/hda

After issuing the above command (once per reboot), the drive will spin up as needed, and spin down again only after 5 seconds of inactivity..

In the case of the player app, it could still issue the IDLENOW1 command to spin up prior to demand, but just let the drive do the spin down again on its own.

Cheers

The player app controls spin up/down with more intelligence, though - the timeout for spindown gets backed off depending on what you're doing (eg, if you've been skipping songs a lot recently). Yes, we could keep adjusting the spindown timeout, but it seems far better to do it ourselves; also, this allows us to do things like flushing dirty entries to the dynamic data partition when a spindown is about to happen so that it is as up-to-date as possible.

It also staggers spinup on 2 drive systems, as mk1's on the home ac adaptor were marginal for current draw with 2 drives starting at the same time with the display on.

Hugo

Yeah, the player seems pretty good about controlling the drives. It's more the other userland apps that are starting to appear that could produce conflicts, leave the drive spinning, etc..

Cheers

I've put a task in to add a config.ini option which will stop the standby commands getting sent to the drive. This should allow normal timeouts to be used if required.

If you want a patch before then, you could trap the standby command at ioctl level and discard it :)

Hugo

I'm not sure that this is necessary, Hugo. So long as the "hdparm -S1" (or equivalent) gets done at startup, the player can start/stop the drive at will, and user apps will still be happy (and the drive will spin down 5 seconds after any such apps complete disk access).

For that matter, if it's preferred, I could even do both things in hijack.. discard spin up/down attempts, and do "hdparm -S1" on startup (all configurable in config.ini).

Cheers

I smell a Hijack v77 feature...

Or maybe even "hdparm -S2" (longer timeout), to ensure no conflict with the player's needs.