2003-07-18 22:27:05

by Kresimir Kukulj

[permalink] [raw]
Subject: [PATCH] siimage.c - turning DMA on because of 'md' kernel thread.

Hi

I'm trying to use Sil3112a controller with two Seagate 120Gb SATA
disks for RAID-1 (mirror) with 'md - multiple devices' driver. I am aware
that I need to use some tricks to get it working, like this:

# hdparm -d1 -X69 /dev/xxx
# echo "max_kb_per_request:15" > /proc/ide/hd?/settings

First one prevents freezing the system when enabling DMA.
Second one stops IO errors.

As far as I can tell, it works ok, but with reduced bandwidth (because of
max_kb_per_request). When using 'md' driver for RAID-1 mirror (rootfs, swap)
with persistent superblocks I have problems. If server crashes (for some
reason), 'md' tries to resync mirrors automatically. That is done by a kernel
thread that is activated before init(8) is started. I have put 'hdparm' cludge
very early in the boot process, but that happens _after_ 'md' thread starts to
resync. That means that disks are busy (in PIO mode), and when hdparm -d1 -X69
executes, system freezes [if there is no disk/little activity hdparm cludge
passes ok - for example, if RAID-1 is clean so there is no resync].

For past two days I tried to find a way to force ide driver to initialize disk
in dma mode automatically by the kernel itself although disks are set to PIO by
the bios for some reason. I devised a patch that does hdparm + echo cludge. I
have never seen linux kernel, so I am unsure if I did it correctly. Patch is
attached. Please, if anyone uses it, test it to see if it works ok for you! I
am not familiar with linux ide driver so I did this with a lot of printk's and
trial & error.

With this patch, disks are initialized by kernel to UDMA100, with
max_kb_per_request:15. Now, RAID-1 is resynced at boot with DMA already
activated (so there is no need for hdparm) and it completed successfully.
At least it works for me. I need to do more disk stress tests to be sure it is
stable.

This is all done with vanilla 2.4.21.
2.4.22-pre4 didn't work at all. Copying a few MB of data freezes the kernel.

My motherboard is Asus P4G8X deluxe.
http://www.asus.com/products/mb/socket478/p4g8x-d/overview.htm

--- siimage.c.orig Fri Jul 18 23:36:58 2003
+++ siimage.c Fri Jul 18 23:36:59 2003
@@ -97,7 +97,7 @@

switch(hwif->pci_dev->device) {
case PCI_DEVICE_ID_SII_3112:
- return 4;
+ return 3;
case PCI_DEVICE_ID_SII_680:
if ((scsc & 0x30) == 0x10) /* 133 */
mode = 4;
@@ -297,7 +297,7 @@
struct hd_driveid *id = drive->id;

if ((id->capability & 1) != 0 && drive->autodma) {
- if (!(hwif->atapi_dma))
+ if ((hwif->atapi_dma))
goto fast_ata_pio;
/* Consult the list of known "bad" drives */
if (hwif->ide_dma_bad_drive(drive))
@@ -803,7 +803,7 @@
pci_read_config_dword(dev, PCI_CLASS_REVISION, &class_rev);
class_rev &= 0xff;

- hwif->rqsize = 128;
+ hwif->rqsize = 15;
if ((dev->device == PCI_DEVICE_ID_SII_3112) && (!(class_rev)))
hwif->rqsize = 16;

-----------------------

I'm confused why is this check there:
if ((id->capability & 1) != 0 && drive->autodma) {
if (!(hwif->atapi_dma))
goto fast_ata_pio;

Is it intentional ?

--
Kresimir Kukulj [email protected]
+--------------------------------------------------+
Old PC's never die. They just become Unix terminals.


2003-07-18 22:36:39

by Alan

[permalink] [raw]
Subject: Re: [PATCH] siimage.c - turning DMA on because of 'md' kernel thread.

On Gwe, 2003-07-18 at 23:34, Kresimir Kukulj wrote:
> resync. That means that disks are busy (in PIO mode), and when hdparm -d1 -X69
> executes, system freezes [if there is no disk/little activity hdparm cludge
> passes ok - for example, if RAID-1 is clean so there is no resync].

The newest driver should put them into DMA automatically and set the
limit. The other changes I'll check over but certainly look like they
may be needed.

2003-07-21 15:19:15

by Kresimir Kukulj

[permalink] [raw]
Subject: Re: [PATCH] siimage.c - turning DMA on because of 'md' kernel thread.

Quoting Alan Cox ([email protected]):
> On Gwe, 2003-07-18 at 23:34, Kresimir Kukulj wrote:
> > resync. That means that disks are busy (in PIO mode), and when hdparm -d1 -X69
> > executes, system freezes [if there is no disk/little activity hdparm cludge
> > passes ok - for example, if RAID-1 is clean so there is no resync].
>
> The newest driver should put them into DMA automatically and set the
> limit. The other changes I'll check over but certainly look like they
> may be needed.

Hm, I tried 2.4.22-pre7 and it did not set disks to DMA mode, but it did set
the limit (max_kb_per_request). With the following modification, kernel
(2.4.22-pre7) initializes both disk to UDMA133, and as far as I can see, it
works ok.

In siimage.c there is a check for Maxtor disks - they are/should be set to
UDMA100. Is this also necessary for Seagate SATA disks ?

--------------
--- siimage.c.orig Mon Jul 21 15:13:16 2003
+++ siimage.c Mon Jul 21 16:56:28 2003
@@ -488,7 +488,7 @@
struct hd_driveid *id = drive->id;

if ((id->capability & 1) != 0 && drive->autodma) {
- if (!(hwif->atapi_dma))
+ if ((hwif->atapi_dma))
goto fast_ata_pio;
/* Consult the list of known "bad" drives */
if (hwif->ide_dma_bad_drive(drive))
---------------


And it looks like:

SiI3112 Serial ATA: IDE controller at PCI slot 02:04.0
PCI: Found IRQ 5 for device 02:04.0
PCI: Sharing IRQ 5 with 02:00.0
SiI3112 Serial ATA: chipset revision 2
SiI3112 Serial ATA: not 100% native mode: will probe irqs later
ide2: MMIO-DMA , BIOS settings: hde:pio, hdf:pio
ide3: MMIO-DMA , BIOS settings: hdg:pio, hdh:pio
hda: SAMSUNG CD-ROM SC-152A, ATAPI CD/DVD-ROM drive
hde: ST3120023AS, ATA DISK drive
blk: queue c0326ef8, I/O limit 4095Mb (mask 0xffffffff)
hdg: ST3120023AS, ATA DISK drive
blk: queue c0327364, I/O limit 4095Mb (mask 0xffffffff)
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide2 at 0xf8800080-0xf8800087,0xf880008a on irq 5
ide3 at 0xf88000c0-0xf88000c7,0xf88000ca on irq 5
hde: attached ide-disk driver.
hde: host protected area => 1
hde: 234441648 sectors (120034 MB) w/8192KiB Cache, CHS=232581/16/63, UDMA(133)
hdg: attached ide-disk driver.
hdg: host protected area => 1
hdg: 234441648 sectors (120034 MB) w/8192KiB Cache, CHS=232581/16/63, UDMA(133)


/dev/hdg:
multcount = 16 (on)
I/O support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 1 (on)
keepsettings = 0 (off)
nowerr = 0 (off)
readonly = 0 (off)
readahead = 8 (on)
geometry = 14593/255/63, sectors = 234441648, start = 0
busstate = 1 (on)


Capabilities:
LBA, IORDY(can be disabled)
Buffer size: 8192.0kB ECC bytes: 4 Queue depth: 1
Standby timer values: spec'd by standard
r/w multiple sector transfer: Max = 16 Current = 16
Advanced power management level: 65278
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=240ns IORDY flow control=120ns


[Mirror]
# hdparm -tT /dev/md3

/dev/md3:
Timing buffer-cache reads: 128 MB in 0.24 seconds =533.33 MB/sec
Timing buffered disk reads: 64 MB in 2.42 seconds = 26.45 MB/sec

[One plex]
# hdparm -tT /dev/hde3

/dev/hde3:
Timing buffer-cache reads: 128 MB in 0.24 seconds =533.33 MB/sec
Timing buffered disk reads: 64 MB in 1.82 seconds = 35.16 MB/sec

Poor results, but at least it works.

--
Kresimir Kukulj [email protected]
+--------------------------------------------------+
Old PC's never die. They just become Unix terminals.