TR Forums

Well, after three days struggle, I am finally able to boot off of my UDMA 66 Quantum FireBallp ka9.1. Three LONG days.

Basically, Quatum drives and Promise cards suck, stay away from them, I finally found out I had to enter the quantum drive into the 'quirk list' on my /usr/src/linux/drivers/ide/pc2002*.c to allow the system to boot up w/out locking the kernel.

So, to make a long story short, I got a crap install on it, recompiled the kernel hooked up the quantum, booted, installed new system ( on a system w/ no CDrom or Floppy, had to pull the cdrom out of my main box ).

Now, after getting that up and running, I have a samba fileserver, using hashed passwords serving the house as a mp3 server.

Now, another question, is USB printing worth the hassle I can sense it will be? Anyone have any experience in USB printer drivers in *nix?

Question 2: hdparm, how do I determine what UDMA mode the drive is using w/ hdparm? I know it gives me info on bootup.
The promise card itself shows UDMA66 on boot.
The kernel says UDMA33 on dmesg, but hdparm and Bonnie show UDMA66 style performance when benchmarking the drive.

Question 3: Anyway to increase performance in Samba? It's approximately half of my ftp speeds, or is just the nature of the smb style protocol?

Question 4: Anyone tired of my questions yet?

Answer 2: "man hdparm" ??

Bruce: Maybe I'm 'tarded, but I can't see a way for it to tell me the UDMA mode, I see how to SET the UDMA mode, but no way to tell which one it currently is in.

I'll let you off

If you do 'hdparm /dev/hda' you get the stats on that drive. If you then do 'hdparm -d /dev/hda' it should tell you what the setting is for DMA.

Try running 'hdparm' with no parameters - it gives a full list of options.

Of course /dev/hda may not be your drive - substitute as appropriate.

Hope this helps,
Bruce

<font size=-1>[ This Message was edited by: Bruce on 2002-02-15 07:15 ]</font>

I think what he's asking is which DMA mode the drive is in, not if it's in DMA mode. I don't think there's a setting in hdparm to force a specific DMA mode.

Thanks Steel, that's exactly what I was asking.

Doh, my blue, I mis-read that

hdparm -i /dev/hda will query the controller.
hdparm -I /dev/hda will query the drive.

Both tell you the exact mode the drive is in, its capabilities, etc.

hdparm -d1 /dev/hda will turn on DMA (whatever the default is for your combination of drive and controller).
hdparm -d1 -X34 /dev/hda will force multiword DMA mode 2, at 16.7 MB/s.
hdparm -d1 -X66 /dev/hda will force Ultra DMA mode 2, at 33.3 MB/s.
hdparm -d1 -X68 /dev/hda will force Ultra DMA mode 4, at 66.7 MB/s.
hdparm -d1 -X69 /dev/hda will force Ultra DMA mode 5, at 100.0 MB/s.


<font size=-1>[ This Message was edited by: Prototyped on 2002-03-08 17:06 ]</font>

Thanks prototyped, just did some testing and I think what's happening is when a drive is set into the quirk list it forces the drive into udma33 regardless of which setting.

My earlier tests where incorrect when I thought it was getting UDMA66 rates. So, I'm pretty sure this drive is just using UMDA33 no matter what switch I give it.

Oh well, not that running in UDMA66 is gonna help this cele box anyhoo.

Actually, Linux is bad at detecting 80-conductor cables for some IDE chipsets, e.g. my '686B. You can force-enable UDMA modes 3/4/5 by passing ide2=ata66 ide3=ata66 as kernel options (assuming we're talking about an off-board controller that provides tertiary and quaternary IDE channels).

So, you edit /etc/lilo.conf (assuming you're using LILO), go to the image= line for the appropriate kernel, and add under it:

append="ide2=ata66 ide3=ata66"

Save lilo.conf and exit your editor. Then run:

lilo -v

to make the changes effective. (If you're using NTLDR to chainload LILO, you'll need to copy over the bootsector, as you probably did earlier, in this case.)

Then reboot. In this manner, you'll effectively have overridden the cable type detection scheme.

Naw, the bios of the card detects it as UDMA66, and it attempted to run UDMA66 but, in order to avoid lockups, I had to put that drive into the HD controllers 'quirk' list. Apparently this FireballLP isn't 100% compatible with the promise (ack) in UDMA66.