[we had some private conversation, that was not on the kernel list. Zlatko
requested a patch to override his BIOS settings]
> > You might give the attached patch a try, but I won't promise anything.
> > This is a completly untested quick hack. (And don't blame me for any
> > unpredictable result... ).
>
> [patch]
>
> Success at last. You made my day!
>
> After applying your patch and doing one small change in source by my
> own:
>
> --- linux/drivers/block/ide.c.orig Thu Sep 18 16:41:21 1997
> +++ linux/drivers/block/ide.c Thu Sep 18 16:41:52 1997
> @@ -2599,7 +2599,7 @@
> pcibios_read_config_word (bus, fn, PCI_COMMAND, &command);
> pcibios_read_config_byte (bus, fn, PCI_LATENCY_TIMER, &lat);
>
> - if (lat && (command & PCI_COMMAND_MASTER))
> +/* if (lat && (command & PCI_COMMAND_MASTER)) */
> ide_init_triton (bus, fn + func_adj);
> }
> #endif /* CONFIG_BLK_DEV_TRITON */
I don't think that this is necessary. This checks for burst DMA
capability and from your /proc/pci info I can see that you can leave
the "if" where it is.
>
> I eventually managed to get bloody thing working. :)
>
> Kernel log:
>
> SIS: bus-master IDE device on PCI bus 0 function 9
> SIS: bus-master DMA feature is not enabled (BIOS)
> SIS: bus-master DMA turned on (overiding BIOS)
> ide0: BM-DMA at 0xec70-0xec77
> ide1: BM-DMA at 0xec78-0xec7f
> ...
> hda: IBM-DAQA-33240, 3098MB w/96kB Cache, LBA, CHS=787/128/63, DMA
> ^^^
> And this is from /proc/pci (for others to compare):
>
> Bus 0, device 1, function 1:
> IDE interface: Silicon Integrated Systems 85C5513 (rev 8).
> Fast devsel. Master Capable. Latency=64.
> I/O at 0x0 [0x1].
> I/O at 0x0 [0x1].
> I/O at 0x0 [0x1].
> I/O at 0x0 [0x1].
> I/O at 0xec70 [0xec71].
You seem to have a very strange BIOS. (wonder why IDE works...)
It should look like this:
Bus 0, device 1, function 1:
IDE interface: Silicon Integrated Systems 85C5513 (rev 194).
Fast devsel. IRQ e. Master Capable. Latency=32.
I/O at 0x1f0 [0x1f1].
I/O at 0x3f4 [0x3f5].
I/O at 0x170 [0x171].
I/O at 0x374 [0x375].
I/O at 0x4000 [0x4001].
> After running some benchmarks I noticed that performance is slighly
> better when reading from disk, but worse when writing to disk (??).
> Benchmark results are available on request (I will make some more,
> just to be sure).
>
> I have been warned that DMA is not the magic solution (SCSI *is* :) ),
> but friend of mine has opinion that it should cut CPU usage to half!?!
>
> Excerpt from the "hdparm" utility man page:
>
> "Using DMA does not necessarily provide any improvement in throughput
> or system performance, but many folks swear by it. Your mileage may
> vary.".
>
> Comments on this subject are welcome (email ok).
It's right, that you don't get a performance increase in respects of
data transfer. Todays CPUs are fast enough to move the hole data around,
but you can't do much else while heavy disk access is in progress. With
DMA support CPU usage goes down form about 80% to 15% on my system.
> Thanks, Christian, for your time. I will run your patches for some
> time, and if I encounter any problems, you will know about them,
> too. Right now, thing seems very stable and is practicaly ready to go
> into the mainstream kernel, IMHO. I will gladly test any future patch
> you may come up with.
Yep! But it should be an lilo option to overide the BIOS settings, not the
default. Expect this in a few days...
Baba, Christian