siimage slow on 2.4.21-rc6-ac2

DISCUSSION Mauk van der Laan 3 participants 10 messages Jun 3, 2003 – Jun 4, 2003

Share & tools

Mauk van der Laan

author

2003-06-03 21:56 UTC #0 lore raw

I just tested the siimage driver in 2.4.21-rc6-ac2. The errors i get in -rc6 have disappeared but the computer becomes unresponsive (20 seconds between screen switches) when I run bonnie and the disk is very slow:

I do hdparm -d1 -X66. Anything else I can try?

Mauk

Alan Cox

2003-06-03 22:07 UTC #1 lore raw

Quoted 5 lines · Mauk van der Laan

I just tested the siimage driver in 2.4.21-rc6-ac2. The errors i get in -rc6 have disappeared but
the computer becomes unresponsive (20 seconds between screen switches) when I run bonnie
and the disk is very slow:

Sounds like your system has switched back to PIO.

Mauk van der Laan

author

2003-06-03 22:21 UTC #2 lore raw

Quoted 14 lines · Alan Cox

Quoted 6 lines · Mauk van der Laan
I just tested the siimage driver in 2.4.21-rc6-ac2. The errors i get in -rc6 have disappeared but
the computer becomes unresponsive (20 seconds between screen switches) when I run bonnie and the disk is very slow:
Sounds like your system has switched back to PIO.

Yes, it did. Nothing in the log, though.

Still having problems:
hdparm -d1 -X66 /dev/hdg
mke2fs /dev/hdg1

See the empty lines and the funny r 18 line?

Jun  4 00:28:56 debby kernel: blk: queue c0407c34, I/O limit 4095Mb (mask 0xffffffff)
Jun  4 00:29:42 debby kernel: hdg: dma_timer_expiry: dma status == 0x21
Jun  4 00:29:52 debby kernel: hdg: dma timeout retry: status=0xd8 { Busy }
Jun  4 00:29:52 debby kernel:
Jun  4 00:29:52 debby kernel: hdg: DMA disabled
Jun  4 00:29:52 debby kernel: ide3: reset phy, status=0x00000113, siimage_reset
Jun  4 00:30:22 debby kernel: ide3: reset timed-out, status=0xd8
Jun  4 00:30:22 debby kernel: hdg: status timeout: status=0xd8 { Busy }
Jun  4 00:30:22 debby kernel:
Jun  4 00:30:22 debby kernel: ide3: reset phy, status=0x00000113, siimage_reset
Jun  4 00:30:52 debby kernel: r 18
Jun  4 00:30:52 debby kernel: end_request: I/O error, dev 22:01 (hdg), sector 20
Jun  4 00:30:52 debby kernel: end_request: I/O error, dev 22:01 (hdg), sector 22
Jun  4 00:30:52 debby kernel: end_request: I/O error, dev 22:01 (hdg), sector 4088
Jun  4 00:30:52 debby kernel: end_request: I/O error, dev 22:01 (hdg), sector 4090

(lots more of these)

Mauk

Mauk van der Laan

author

2003-06-03 22:35 UTC #3 lore raw

He! I just did

# hdparm -d1 -X66 /dev/hdX
# echo "max_kb_per_request:15" > /proc/.ide/hdX/settings

on BOTH sata drives and everything works fine!
Is it possible that they influence each other?

Mauk

Quoted 42 lines · Mauk van der Laan

Quoted 13 lines · Alan Cox
Quoted 4 lines · Mauk van der Laan
I just tested the siimage driver in 2.4.21-rc6-ac2. The errors i get in -rc6 have disappeared but the computer becomes unresponsive (20 seconds between screen switches) when I run bonnie and the disk is very slow:
Sounds like your system has switched back to PIO.
Yes, it did. Nothing in the log, though.
Still having problems:
hdparm -d1 -X66 /dev/hdg
mke2fs /dev/hdg1
See the empty lines and the funny r 18 line?
Jun  4 00:28:56 debby kernel: blk: queue c0407c34, I/O limit 4095Mb (mask 0xffffffff)
Jun  4 00:29:42 debby kernel: hdg: dma_timer_expiry: dma status == 0x21
Jun  4 00:29:52 debby kernel: hdg: dma timeout retry: status=0xd8 { Busy }
Jun  4 00:29:52 debby kernel:
Jun  4 00:29:52 debby kernel: hdg: DMA disabled
Jun  4 00:29:52 debby kernel: ide3: reset phy, status=0x00000113, siimage_reset
Jun  4 00:30:22 debby kernel: ide3: reset timed-out, status=0xd8
Jun  4 00:30:22 debby kernel: hdg: status timeout: status=0xd8 { Busy }
Jun  4 00:30:22 debby kernel:
Jun  4 00:30:22 debby kernel: ide3: reset phy, status=0x00000113, siimage_reset
Jun  4 00:30:52 debby kernel: r 18
Jun  4 00:30:52 debby kernel: end_request: I/O error, dev 22:01 (hdg), sector 20
Jun  4 00:30:52 debby kernel: end_request: I/O error, dev 22:01 (hdg), sector 22
Jun  4 00:30:52 debby kernel: end_request: I/O error, dev 22:01 (hdg), sector 4088
Jun  4 00:30:52 debby kernel: end_request: I/O error, dev 22:01 (hdg), sector 4090
(lots more of these)
Mauk

Alan Cox

2003-06-03 23:04 UTC #4 lore raw

Quoted 7 lines · Mauk van der Laan

He! I just did
# hdparm -d1 -X66 /dev/hdX
# echo "max_kb_per_request:15" > /proc/.ide/hdX/settings
on BOTH sata drives and everything works fine!
Is it possible that they influence each other?

Not as I understand it, but this is rather useful information. The SI does have some ties for PIO mode but not UDMA clocking. This is most interesting information.

The max_kb_per thing should be irrelevant btw.

Andre Hedrick

2003-06-04 00:51 UTC #5 lore raw

NO, it is not irrelevant.

Seagate and Silicon Image are the only two player (well intel now) who did their own PHY. They did not use the Marvel pairs.

It is a function of possible ECC on the wire and the relation to the segments in the PIO or SG operations. It is a FIFO issue based on 512byte boundaries being breached on corner cases.

The data on the wire is in 8K units.

It is a 7.5K + 0.5K corner case.

max_kb_per_request:15 == 7.5K

This prevents this corner case until I can code the proper special case SG table.

drive->id->hwconfig |= 0x6000;

Is needed to fake the driver for device side cable detect. There are several issues and I have not had time to keep up.

I have to do other business ventures because being an independent developer/contract no longer can pay the bills. More proof that free drivers and free software still has a cost to somebody.

Cheers,

Quoted 13 lines · Alan Cox

Quoted 7 lines · Mauk van der Laan
He! I just did
# hdparm -d1 -X66 /dev/hdX
# echo "max_kb_per_request:15" > /proc/.ide/hdX/settings
on BOTH sata drives and everything works fine!
Is it possible that they influence each other?
Not as I understand it, but this is rather useful information. The SI does have some ties for PIO mode but not UDMA clocking. This is most interesting information.

Quoted 8 lines

The max_kb_per thing should be irrelevant btw.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Andre Hedrick
LAD Storage Consulting Group

Mauk van der Laan

author

2003-06-04 01:10 UTC #6 lore raw

He is right. I did several tests and it is the max_kb setting that does it, not the fact that I programmed both disks. Sorry to have put you in the wrong direction.

By the way, the autodma code doesnt seem to do anything?

Mauk

Quoted 70 lines · Andre Hedrick

NO, it is not irrelevant.
Seagate and Silicon Image are the only two player (well intel now) who did their own PHY. They did not use the Marvel pairs.
It is a function of possible ECC on the wire and the relation to the segments in the PIO or SG operations. It is a FIFO issue based on 512byte boundaries being breached on corner cases.
The data on the wire is in 8K units.
It is a 7.5K + 0.5K corner case.
max_kb_per_request:15 == 7.5K
This prevents this corner case until I can code the proper special case SG table.
drive->id->hwconfig |= 0x6000;
Is needed to fake the driver for device side cable detect. There are several issues and I have not had time to keep up.
I have to do other business ventures because being an independent developer/contract no longer can pay the bills. More proof that free drivers and free software still has a cost to somebody.
Cheers,
Quoted 16 lines · Alan Cox
Quoted 9 lines · Mauk van der Laan
He! I just did
# hdparm -d1 -X66 /dev/hdX
# echo "max_kb_per_request:15" > /proc/.ide/hdX/settings
on BOTH sata drives and everything works fine!
Is it possible that they influence each other?
Not as I understand it, but this is rather useful information. The SI does have some ties for PIO mode but not UDMA clocking. This is most interesting information.
Quoted 10 lines
The max_kb_per thing should be irrelevant btw.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andre Hedrick
LAD Storage Consulting Group
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Andre Hedrick

2003-06-04 01:18 UTC #7 lore raw

static byte siimage_ratemask (ide_drive_t *drive)

or whatever the new name is:

        switch(dev->device) {
                case PCI_DEVICE_ID_CMD_3112:

+ drive->id->hwconfig |= 0x6000;

Insert in your drivers/ide/pci/siimage.c

Quoted 85 lines · Mauk van der Laan

He is right. I did several tests and it is the max_kb setting that does it, not the fact that I programmed both disks. Sorry to have put you in the wrong direction.
By the way, the autodma code doesnt seem to do anything?
Mauk
Quoted 60 lines · Andre Hedrick
NO, it is not irrelevant.
Seagate and Silicon Image are the only two player (well intel now) who did their own PHY. They did not use the Marvel pairs.
It is a function of possible ECC on the wire and the relation to the segments in the PIO or SG operations. It is a FIFO issue based on 512byte boundaries being breached on corner cases.
The data on the wire is in 8K units.
It is a 7.5K + 0.5K corner case.
max_kb_per_request:15 == 7.5K
This prevents this corner case until I can code the proper special case SG table.
drive->id->hwconfig |= 0x6000;
Is needed to fake the driver for device side cable detect. There are several issues and I have not had time to keep up.
I have to do other business ventures because being an independent developer/contract no longer can pay the bills. More proof that free drivers and free software still has a cost to somebody.
Cheers,
Quoted 16 lines · Alan Cox
Quoted 9 lines · Mauk van der Laan
He! I just did
# hdparm -d1 -X66 /dev/hdX
# echo "max_kb_per_request:15" > /proc/.ide/hdX/settings
on BOTH sata drives and everything works fine!
Is it possible that they influence each other?
Not as I understand it, but this is rather useful information. The SI does have some ties for PIO mode but not UDMA clocking. This is most interesting information.
Quoted 10 lines
The max_kb_per thing should be irrelevant btw.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Quoted 10 lines
Andre Hedrick
LAD Storage Consulting Group
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Quoted 6 lines

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Andre Hedrick
LAD Storage Consulting Group

Alan Cox

2003-06-04 11:13 UTC #8 lore raw

In reply to Andre Hedrick

Quoted 4 lines · Andre Hedrick

NO, it is not irrelevant.
Seagate and Silicon Image are the only two player (well intel now) who did their own PHY. They did not use the Marvel pairs.

Ok I know about the maxtor+marvel phy problem I didnt know about SI phy problems.

Quoted 3 lines

I have to do other business ventures because being an independent developer/contract no longer can pay the bills. More proof that free drivers and free software still has a cost to somebody.

Sure. Nobody is asking you to fix it all. I'll go bug SI as I've already got the needed hooks in the 2.4 core code (although not 2.5 since the taskfile stuff needs to get resolved first).

Alan

Alan Cox

2003-06-04 11:49 UTC #9 lore raw

In reply to Andre Hedrick

Quoted 4 lines · Andre Hedrick

drive->id->hwconfig |= 0x6000;
Is needed to fake the driver for device side cable detect. There are several issues and I have not had time to keep up.

The SI3112 ignores the word93 check.