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
On Maw, 2003-06-03 at 23:09, Mauk van der Laan wrote:
> 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.
Alan Cox wrote:
>On Maw, 2003-06-03 at 23:09, Mauk van der Laan wrote:
>
>
>>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
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
Mauk van der Laan wrote:
> Alan Cox wrote:
>
>> On Maw, 2003-06-03 at 23:09, Mauk van der Laan wrote:
>>
>>
>>> 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
>
On Maw, 2003-06-03 at 23:48, Mauk van der Laan wrote:
> 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.
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,
On 3 Jun 2003, Alan Cox wrote:
> On Maw, 2003-06-03 at 23:48, Mauk van der Laan wrote:
> > 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.
>
> -
> 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
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
Andre Hedrick wrote:
>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,
>
>On 3 Jun 2003, Alan Cox wrote:
>
>
>
>>On Maw, 2003-06-03 at 23:48, Mauk van der Laan wrote:
>>
>>
>>>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.
>>
>>-
>>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/
>
>
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
On Wed, 4 Jun 2003, Mauk van der Laan wrote:
>
> 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
>
>
> Andre Hedrick wrote:
>
> >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,
> >
> >On 3 Jun 2003, Alan Cox wrote:
> >
> >
> >
> >>On Maw, 2003-06-03 at 23:48, Mauk van der Laan wrote:
> >>
> >>
> >>>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.
> >>
> >>-
> >>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/
> >
> >
>
>
>
> -
> 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
On Mer, 2003-06-04 at 01:53, Andre Hedrick wrote:
> 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.
> 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
On Mer, 2003-06-04 at 01:53, Andre Hedrick wrote:
> 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.