Strange PMAC IDE performance problem

Strange PMAC IDE performance problem

[Timothy A. Seufert]

I discovered hdparm today, and ran its -Tt test to show sustained DTR from
the drive on several configurations:

1) PowerMac G3,    2.1.130,    BootX, IBM DGHS-09U on Adaptec 2940UW
   buffered disk reads 14.55 MB/s

2) PowerMac G3,    2.1.130,    BootX, IBM DHEA-38451 IDE
   buffered disk reads 1.89 MB/s

3) PowerBook 2400, 2.1.115,    OF,    IBM DTCA-24090 IDE 2.5"
   buffered disk reads 1.90 MB/s

4) PowerBook 2400, 2.2.0-pre4, BootX, IBM DTCA-24090 IDE 2.5"
   buffered disk reads 1.74 MB/s

5) PowerBook 2400, 2.2.0-pre4, OF,    IBM DTCA-24090 IDE 2.5"
   buffered disk reads 0.93 MB/s


I provided the Ultra SCSI case for comparison's sake, to show that hdparm
hasn't totally lost its mind.  14.55 MB/s is pretty much what IBM claims
for the DGHS-09U (UltraStar 9LP).

Needless to say, the IDE performance figures are far less than those drives
are capable of!  Under MacOS they benchmark much higher (for example, the
38451 scores 7780 to 9472 KB/s (8819 avg) sustained read on the FWB
BenchTest).  I think it's particularly interesting that the 2400 did better
when booted from BootX than Open Firmware.  It would also appear from (3)
that things have gotten worse over time, not better.

All the IDE figures above are with DMA on (except 2.1.115, which doesn't
support IDE DMA on the PowerMac unless I am mistaken).  I tried turning IDE
DMA off on 2.2.0-pre4 (hdparm -d0 /dev/hda).  Doing so increased the
throughput by .02 MB/s (BootX, didn't try OF case).

  Tim Seufert

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Strange PMAC IDE performance problem

[Albrecht Dreß]

Timothy A. Seufert wrote:
[snip]
> Needless to say, the IDE performance figures are far less than those drives
> are capable of!  Under MacOS they benchmark much higher (for example, the
[snip]

I can confirm this behaviour on my PowerBook G3/300 with almost the same rate
under 2.1.130 (the disk is an IBM DYLA 28100). Furthermore, the whole system
nearly freezes under heavy io load (I simply used a program which writes and
reads blocks of data to/from the disk using read and write calls in a loop;
during the run the reaction to console input or a "cat" needs several seconds,
etc.). I posted this problem several times, but got no reaction, so I am glad
that I am not alone ... :-(

The problem might be connected to LOADS of "Bogus interrupts" from do_IRQ in
arch/ppc/kernel/irq.c (try "dmesg" and do a "cat /proc/interrupts" before and
after your test; you will see the increase in the "BAD" line).

I think that this is a serious problem, as it makes the machine nearly unusable
fore some applications. Hope it will get fixed ;-)

Yours, Albrecht.

-- 
+-----------------------------------------------------------------------------+
| Dr.-Ing. Albrecht Dre\3                                      ----           |
| Max-Planck-Institut f"ur Radioastronomie    |\       /      /o  o\          |
| Technische Abt. Optische Interferometrie    |  \    /      |  /   |         |
| Auf dem H"ugel 69                           |    \ |        \ ---/          |
| D-53121 Bonn (Germany)          ------------+------+-------------------     |
|                                             |    / |                        |
| Phone (+49) 228 525 319                     |  /  /                         |
| Fax   (+49) 228 525 411                     |/   /                          |
| Mail  ad@mpifr-bonn.mpg.de                                                  |
+-------------- electrical engineers do it with less resistance --------------+

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Strange PMAC IDE performance problem

[Marcus H. Mendenhall]

>Timothy A. Seufert wrote:
>[snip]
>> Needless to say, the IDE performance figures are far less than those drives
>> are capable of!  Under MacOS they benchmark much higher (for example, the
>[snip]
>
>I can confirm this behaviour on my PowerBook G3/300 with almost the same rate
>under 2.1.130 (the disk is an IBM DYLA 28100). Furthermore, the whole system
>nearly freezes under heavy io load (I simply used a program which writes and
>reads blocks of data to/from the disk using read and write calls in a loop;
>during the run the reaction to console input or a "cat" needs several seconds,
>etc.). I posted this problem several times, but got no reaction, so I am glad
>that I am not alone ... :-(
>
>The problem might be connected to LOADS of "Bogus interrupts" from do_IRQ in
>arch/ppc/kernel/irq.c (try "dmesg" and do a "cat /proc/interrupts" before and
>after your test; you will see the increase in the "BAD" line).

It goes beyond just temporary freezes/slowdowns.  After heavy i/o activity
on my G3 (rev2)/300 desktop machine, I get total freezes.  If I am out of X
(very rare...) I get a kernel stack overflow panic and a backtrace.  In X,
I get no chance to see the message.  I have not yet succeeded in copying
down enough of the message before the kernel autoreboots to be useful
(since it has only happened about twice when I was not in X).  If I
recompile a large package (ROOT, for example (a great scientific package
from root.cern.ch, incidentally)) I have nearly a 100% chance of at least
one such lockup during the operation.

I have never had enough time between the time the machine starts to slow
down and when it panics to look at dmesg and see the errors there.

This is the only serious problem I know of in kernels of the 2.1.130
vintage.  My machine at home (a 7300/180) has been running with absolutely
no problems of any type on the recent kernels.  If anyone who is following
this problem needs more info (for example the detailed backtrace) to help
debug, I will try to provoke it when not in X and hand-copy the info.  If
enough of that information has already been collected, I don't want to
spend a lot of time going through the exercise.

Looking forward to a solution... (and don't have time myself at present to
put out this particular fire)

Thanks in advance

Marcus Mendenhall



[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Strange PMAC IDE performance problem

[Timothy A. Seufert]

At 12:33 PM +0100 1/5/99, Albrecht Dreß wrote:

>I can confirm this behaviour on my PowerBook G3/300 with almost the same rate
>under 2.1.130 (the disk is an IBM DYLA 28100). Furthermore, the whole system
>nearly freezes under heavy io load (I simply used a program which writes and
>reads blocks of data to/from the disk using read and write calls in a loop;
>during the run the reaction to console input or a "cat" needs several seconds,
>etc.). I posted this problem several times, but got no reaction, so I am glad
>that I am not alone ... :-(
>
>The problem might be connected to LOADS of "Bogus interrupts" from do_IRQ in
>arch/ppc/kernel/irq.c (try "dmesg" and do a "cat /proc/interrupts" before and
>after your test; you will see the increase in the "BAD" line).

Interesting -- I don't get any bogus interrupts on either of my machines.
I also don't experience such harsh penalties to system responsiveness if
there's a lot of I/O going on -- I often use grep with find supplying the
filenames to recursively search the kernel source tree, which cranks the
disk quite a bit, and have no problems using other programs while it's
churning away.

I would guess that you have the same performance problem along with some
serious bug that for some reason is only showing up on your machine (as I
believe there are many other people using PowerBook G3 Series machines
without such problems).

  Tim Seufert

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Strange PMAC IDE performance problem

[Benjamin Herrenschmidt]

On Tue, Jan 5, 1999, Timothy A. Seufert <tas@mindspring.com> wrote:

>Interesting -- I don't get any bogus interrupts on either of my machines.
>I also don't experience such harsh penalties to system responsiveness if
>there's a lot of I/O going on -- I often use grep with find supplying the
>filenames to recursively search the kernel source tree, which cranks the
>disk quite a bit, and have no problems using other programs while it's
>churning away.
>
>I would guess that you have the same performance problem along with some
>serious bug that for some reason is only showing up on your machine (as I
>believe there are many other people using PowerBook G3 Series machines
>without such problems).

I remember Cort having tons of them initially with his PowerBook and they
disappeared, I don't know if it was after a kernel change however.

On my PowerBook G3 Series (250MHz first gen.), I have occasionally a
couple of bogus interrupts during boot and ADB probing (seems to be
related to high PMU acitivity but I have not really tracked them) and
some date reading problems (the problem appeared twice in several month,
usually persistent accross reboots, and after 1 or 2 days, it disappears
again). Those are the only apparently random problems I'm having. Also,
the IDE is not very fast (looks slower than MacOS) but this may be due to
Linux not using full features of the controller in G3 Series (according
to a very vague statement of Apple, it should be improved but nothing
precise enough however).

I never experienced the slowdown+crash on heavy i/os, even when copying
full kernel trees locally, over NFS and both at the same time.

Is there some common denominator with all those problems ? For example, I
never connect anything to my PowerBook's MESH. Did the people with the
problem have something connected to it ? never ? always ? both ? Maybe we
could collect the disk models to see if the seem to be related. Also, are
the problem similar when booting with OF and BootX or are there any
differences ?

-- 
           E-Mail: <mailto:bh40@calva.net>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>




[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Strange PMAC IDE performance problem

[Dan Malek]

Benjamin Herrenschmidt wrote:

> I remember Cort having tons of them initially with his PowerBook and they
> disappeared, I don't know if it was after a kernel change however.

I am still running 2.1.125 on my PowerBook G3, and get tons
of bogus interrupts.  I am trying to upgrade to 2.1.130 (or the
latest vger tree).  When I run 2.1.130, I don't see the problems.
The major difference is I run the IDE DMA on 2.1.130 and not
on other kernels..........I can't point to anything else.  My other
thought was something wrong with power management.


> I never experienced the slowdown+crash on heavy i/os, even when copying
> full kernel trees locally, over NFS and both at the same time.

Mine will when running 2.1.125.....not with 2.1.130.


> ........ Also, are
> the problem similar when booting with OF and BootX or are there any
> differences ?

I boot with OF (either floppy or enet) because I don't have an
easy way to get the kernel into the MacOS system folder.  I have
hacked the atyfb to force G3 resolution and depth regardless of what
it finds automatically.


    -- Dan



[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Strange PMAC IDE performance problem

[Benjamin Herrenschmidt]

On Wed, Jan 6, 1999, Dan Malek <dmalek@jlc.net> wrote:

>I boot with OF (either floppy or enet) because I don't have an
>easy way to get the kernel into the MacOS system folder.  I have
>hacked the atyfb to force G3 resolution and depth regardless of what
>it finds automatically.

You can either make a little transfer HFS partition that you mount
read/write or use MountX (get the latest version). I will probably write
a linuxdisks-like GPL'ed app too once of those days (less complex than
MountX, it will be easier to get it fully functional with read and write
working).

Another way I use for transfering kernels: netatalk. works great here,
almost nothing to configure.

-- 
           E-Mail: <mailto:bh40@calva.net>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>





[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Strange PMAC IDE performance problem

[Albrecht Dreß]

Benjamin Herrenschmidt wrote:
[snip]
> Is there some common denominator with all those problems ? For example, I
> never connect anything to my PowerBook's MESH. Did the people with the
> problem have something connected to it ? never ? always ? both ? Maybe we
> could collect the disk models to see if the seem to be related. Also, are
> the problem similar when booting with OF and BootX or are there any
> differences ?

I use the latest test kernel form your web page (2.1.130 with patches; btw. the
trackpad patch is REALLY great!!) and boot with BootX 1.0.1. Bogus interrupts
appear both with nothing attached to external SCSI and with a tape drive. I get
very few bogus irq's from via_pmu_interrupt (c01d43fc, c01d4410) and LOTS from
do_IRQ (c0005518) in both cases. According to /proc/interrupts, doing a dd of
200 MBytes form /dev/zero to the internal hd resulted in 31 bad irq's from
do_IRQ (and a transfer rate of 1.71 MB/s).

Some time ago I compiled a 2.1.130 kernel WITHOUT SCSI/MESH SUPPORT (also booted
via BootX), but got exactly the same results as with the "normal" kernels.

Yours, Albrecht.

-- 
+-----------------------------------------------------------------------------+
| Dr.-Ing. Albrecht Dre\3                                      ----           |
| Max-Planck-Institut f"ur Radioastronomie    |\       /      /o  o\          |
| Technische Abt. Optische Interferometrie    |  \    /      |  /   |         |
| Auf dem H"ugel 69                           |    \ |        \ ---/          |
| D-53121 Bonn (Germany)          ------------+------+-------------------     |
|                                             |    / |                        |
| Phone (+49) 228 525 319                     |  /  /                         |
| Fax   (+49) 228 525 411                     |/   /                          |
| Mail  ad@mpifr-bonn.mpg.de                                                  |
+-------------- electrical engineers do it with less resistance --------------+

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Strange PMAC IDE performance problem

[Benjamin Herrenschmidt]

On Wed, Jan 6, 1999, Albrecht Dreß <ad@mpifr-bonn.mpg.de> wrote:

>I use the latest test kernel form your web page (2.1.130 with patches; btw.
>the
>trackpad patch is REALLY great!!) and boot with BootX 1.0.1. Bogus interrupts
>appear both with nothing attached to external SCSI and with a tape drive. I
>get
>very few bogus irq's from via_pmu_interrupt (c01d43fc, c01d4410) and
LOTS from
>do_IRQ (c0005518) in both cases. According to /proc/interrupts, doing a dd of
>200 MBytes form /dev/zero to the internal hd resulted in 31 bad irq's from
>do_IRQ (and a transfer rate of 1.71 MB/s).

By curiousity, did someone tried to locate the exact instruction in
do_IRQ when those bogus interrupt happens ? Looks it's always the same...
On MacOS, CodeWarrior has a useful disassembly tool that mixes C and asm
output for that, but I guess there is probably something 1000 times
better on Linux, I just need to know the command line ;-)


-- 
           E-Mail: <mailto:bh40@calva.net>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>





[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Strange PMAC IDE performance problem

[Paul Mackerras]

Benjamin Herrenschmidt <bh40@calva.net> wrote:

> By curiousity, did someone tried to locate the exact instruction in
> do_IRQ when those bogus interrupt happens ? Looks it's always the same...

It's usually the instruction that reenables interrupts globally, after
we have disabled the particular interrupt we are servicing.  I think
what happens is this: we write to the interrupt controller enable
register to disable the interrupt.  This write percolates through the
PCI bridge down into the gc/ohare/heathrow/whatever chip, and some
time later that chip will negate the interrupt request signal
(assuming there are no other enabled interrupts).  In the meantime the
CPU has been proceeding from the write to the instruction where it
reenables interrupts (by putting a new value in the MSR).  If the CPU
gets there first, you can get a bogus interrupt.

I put in a sync instruction after the write to make the cpu wait at
least until the pci bridge has acknowledged the write.  That helps on
many machines but isn't sufficient on some.  Reading a register in the
interrupt controller should help, especially if there was an eieio
between the read and the write.  (The eieio goes out onto the system
bus and should therefore be seen by the PCI host bridge.  Whether the
bridge honors it by not allowing subsequent reads to bypass previous
writes is another question. :-)

Paul.

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Strange PMAC IDE performance problem

[Benjamin Herrenschmidt]

On Thu, Jan 7, 1999, Paul Mackerras <paulus@cs.anu.edu.au> wrote:

>It's usually the instruction that reenables interrupts globally, after
>we have disabled the particular interrupt we are servicing.  I think
>what happens is this: we write to the interrupt controller enable
>register to disable the interrupt.  This write percolates through the
>PCI bridge down into the gc/ohare/heathrow/whatever chip, and some
>time later that chip will negate the interrupt request signal
>(assuming there are no other enabled interrupts).  In the meantime the
>CPU has been proceeding from the write to the instruction where it
>reenables interrupts (by putting a new value in the MSR).  If the CPU
>gets there first, you can get a bogus interrupt.
>
>I put in a sync instruction after the write to make the cpu wait at
>least until the pci bridge has acknowledged the write.  That helps on
>many machines but isn't sufficient on some.  Reading a register in the
>interrupt controller should help, especially if there was an eieio
>between the read and the write.  (The eieio goes out onto the system
>bus and should therefore be seen by the PCI host bridge.  Whether the
>bridge honors it by not allowing subsequent reads to bypass previous
>writes is another question. :-)

I discussed this with Cort not so long ago, since in theory, the write to
the ack register could still be in the bridge when you re-enable EE,
regardless of the sync (posted writes are always handled async by the
bridge, and I don't see why sync would sync anything with the PCI bridge,
at least not with an ordinary bridge but maybe Grackle has some
PPC-specific features here). I suggest adding a read from the controller
(with it's eieio) anyway. This will ensure that all bridges on the path
to the interrupt controller have been flushed (at least according to PCI
standard). A bridge that allow a read to bypass a previous write is
definitely a broken bridge (do you know one ?)

-- 
           E-Mail: <mailto:bh40@calva.net>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>




[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Strange PMAC IDE performance problem

[Paul Mackerras]

Timothy A. Seufert <tas@mindspring.com> wrote:

> Needless to say, the IDE performance figures are far less than those drives
> are capable of!  Under MacOS they benchmark much higher (for example, the
> 38451 scores 7780 to 9472 KB/s (8819 avg) sustained read on the FWB

I have noticed this poor performance myself but it's hard to say what
might be the cause - whether it's some bit that needs to be set
somewhere in a hardware register, or something about the IDE driver
that is causing it to waste time somewhere.  One way to start getting
some information would be to add some statements to the IDE driver to
read the timebase register to get some timing information about how
long different parts of the process take.  If it is that the hardware
is not transferring the bytes very fast, then we need to look for a
value in a hardware register which is different between macos and
linux.  I don't think I will be able to get on to it soon but if
someone else wants to have a go that would be great.

Paul.

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Strange PMAC IDE performance problem

[Paul Mackerras]

I found a register at 0xf3020200 on my powermac G3 which affects the
speed of disk transfers.  This is at offset 0x200 from the base
address of the IDE interface and it is a 32-bit little-endian
register.  After booting Linux, it has 0x2f8526 in it, but under MacOS
it has 0x211025.  Putting 0x211025 in (with xmon) increased the speed
reported by hdparm -tT /dev/hda from 1.89MB/s to 9.7MB/s !  The disk
is a WDC 24300ACL (as reported by hdparm -i /dev/hda).  The other
hdparm settings were -d1 -u1 -m16.

Paul.

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Strange PMAC IDE performance problem

[Benjamin Herrenschmidt]

On Wed, Jan 6, 1999, Paul Mackerras <paulus@cs.anu.edu.au> wrote:

>I found a register at 0xf3020200 on my powermac G3 which affects the
>speed of disk transfers.  This is at offset 0x200 from the base
>address of the IDE interface and it is a 32-bit little-endian
>register.  After booting Linux, it has 0x2f8526 in it, but under MacOS
>it has 0x211025.  Putting 0x211025 in (with xmon) increased the speed
>reported by hdparm -tT /dev/hda from 1.89MB/s to 9.7MB/s !  The disk
>is a WDC 24300ACL (as reported by hdparm -i /dev/hda).  The other
>hdparm settings were -d1 -u1 -m16.

I confirm, I have the same values in this register here on PowerMac
G3/300 desktop (without any IDE device plugged in) and in PowerBook G3
Series. I didn't check the iMac yet but it looks like an heathrow thing. 

if you don't find a similar thing on O'Hare, I suggest checking the
"compatible" property of mac-io against heathrow before putting anything here.

-- 
           E-Mail: <mailto:bh40@calva.net>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>





[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Great IDE perf (WAS: Strange PMAC IDE performance)

[Benjamin Herrenschmidt]

On Wed, Jan 6, 1999, Paul Mackerras <paulus@cs.anu.edu.au> wrote:

>I found a register at 0xf3020200 on my powermac G3 which affects the
>speed of disk transfers.  This is at offset 0x200 from the base
>address of the IDE interface and it is a 32-bit little-endian
>register.  After booting Linux, it has 0x2f8526 in it, but under MacOS
>it has 0x211025.  Putting 0x211025 in (with xmon) increased the speed
>reported by hdparm -tT /dev/hda from 1.89MB/s to 9.7MB/s !  The disk
>is a WDC 24300ACL (as reported by hdparm -i /dev/hda).  The other
>hdparm settings were -d1 -u1 -m16.

I tried the manipulation with xmon on my wallstreet PowerBook, using
today's vger 2.2-pre4 and hdparam test jumped from 1.88Mb/s to 6.3MB/s
!!! (At first, I forgot to flush the caches, so I got 50Mb/s ;-)

Also, the register is replicated all the way from +0x200 to +0x3FF so it
looks like it's really a single register sitting there.

That's great !


-- 
           E-Mail: <mailto:bh40@calva.net>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>





[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Great IDE perf (WAS: Strange PMAC IDE performance)

[Timothy A. Seufert]

At 5:02 PM +0100 1/6/99, Benjamin Herrenschmidt wrote:
>On Wed, Jan 6, 1999, Paul Mackerras <paulus@cs.anu.edu.au> wrote:
>
>>I found a register at 0xf3020200 on my powermac G3 which affects the
>>speed of disk transfers.  This is at offset 0x200 from the base
>>address of the IDE interface and it is a 32-bit little-endian
>>register.  After booting Linux, it has 0x2f8526 in it, but under MacOS
>>it has 0x211025.  Putting 0x211025 in (with xmon) increased the speed
>>reported by hdparm -tT /dev/hda from 1.89MB/s to 9.7MB/s !  The disk
>>is a WDC 24300ACL (as reported by hdparm -i /dev/hda).  The other
>>hdparm settings were -d1 -u1 -m16.
>
>I tried the manipulation with xmon on my wallstreet PowerBook, using
>today's vger 2.2-pre4 and hdparam test jumped from 1.88Mb/s to 6.3MB/s
>!!! (At first, I forgot to flush the caches, so I got 50Mb/s ;-)

Good one, Paul!

This works on the PowerBook 2400 as well.  It so happens that the IDE
controllers also sit at 0xf3020000 and 0xf3021000 on the O'Hare.  The value
of the register at offset 0x200 is slightly different under MacOS:
0x221025.  I tried both values, it didn't seem to make a difference.  I did
a quick hack to ide-pmac.c (it just stuffs the value in, no questions
asked, though it does actually use the correct base address instead of hard
coding 0xf3020000) and that worked.  Performance is up to 5.6 MB/s (was in
the region of 1.6 before).

Right now my cheap hack is using 0x221025, but if somebody wants I will do
0x211025 instead for an extended period to see if there are any problems.

Any guesses about the meaning of this register?  It feels wrong somehow to
just ape MacOS without knowing what's really going on.  :)

  Tim Seufert

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Great IDE perf (WAS: Strange PMAC IDE performance)

[Paul Mackerras]

Tim Seufert <tas@mindspring.com> wrote:

> This works on the PowerBook 2400 as well.  It so happens that the IDE
> controllers also sit at 0xf3020000 and 0xf3021000 on the O'Hare.  The value
> of the register at offset 0x200 is slightly different under MacOS:
> 0x221025.  I tried both values, it didn't seem to make a difference.  I did
> a quick hack to ide-pmac.c (it just stuffs the value in, no questions
> asked, though it does actually use the correct base address instead of hard
> coding 0xf3020000) and that worked.  Performance is up to 5.6 MB/s (was in
> the region of 1.6 before).
> 
> Right now my cheap hack is using 0x221025, but if somebody wants I will do
> 0x211025 instead for an extended period to see if there are any problems.

The hack also works on my powerbook 3400, but I only get 4.3MB/s.  On
the iMac I get 10.53MB/s with 211025, but only 8.47MB/s with 221025.

I did some fiddling around, testing the speed with different values in
the register, and I think it is something like this:

- the 3ff000 bits control the speed of dma accesses, the 000fff bits
  control the speed of PIO accesses
- I think the 3f0000 and 00f000 bits control different aspects of dma
  access speed
- the c00, 300 and ff bitfields seem to control different aspects of
  PIO timing.  I think there are bitfields inside of the ff bitfield,
  but I haven't worked out exactly what's going on.  Time for a CRO
  maybe :-)

I think probably any modern drive would be OK with 211025.  Ideally we
would work out exactly how the values relate to the PIO and DMA modes
defined in the ATA-2 spec, then implement the code for selecting
PIO/DMA modes in the ide-pmac driver as requested by the higher level
IDE driver (based on the capabilities reported by the disk).

> Any guesses about the meaning of this register?  It feels wrong somehow to
> just ape MacOS without knowing what's really going on.  :)

It's nice to know what's really going on, but we have managed without
it more-or-less in several other places (e.g. the swim3 floppy
driver).

Paul.

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Great IDE perf (WAS: Strange PMAC IDE performance)

[Timothy A. Seufert]

At 10:32 PM +1100 1/7/99, Paul Mackerras wrote:
>Tim Seufert <tas@mindspring.com> wrote:

>> Performance is up to 5.6 MB/s (was in
>> the region of 1.6 before).

>The hack also works on my powerbook 3400, but I only get 4.3MB/s.  On
>the iMac I get 10.53MB/s with 211025, but only 8.47MB/s with 221025.

If you have the std. factory drive in the 3400, that might explain it.  I
replaced the original 1.3 GB drive in my 2400 with a much newer IBM 4.0 GB
model.

Sometimes, I get 6.3 MB/s instead of 5.6.  Kind of weird.

  Tim Seufert

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Great IDE perf (WAS: Strange PMAC IDE performance)

[Benjamin Herrenschmidt]

On Thu, Jan 7, 1999, Timothy A. Seufert <tas@mindspring.com> wrote:

>This works on the PowerBook 2400 as well.  It so happens that the IDE
>controllers also sit at 0xf3020000 and 0xf3021000 on the O'Hare.  The value
>of the register at offset 0x200 is slightly different under MacOS:
>0x221025.  I tried both values, it didn't seem to make a difference.  I did
>a quick hack to ide-pmac.c (it just stuffs the value in, no questions
>asked, though it does actually use the correct base address instead of hard
>coding 0xf3020000) and that worked.  Performance is up to 5.6 MB/s (was in
>the region of 1.6 before).

Great ! I also included this initialisation in my latest set of patch and
test kernel but currently, I test against "heathrow-ata" in the
compatible property, so it won't do it on your machine. Could you tell me
the value of the compatible property of the ATA on the 2400 ? I'll add
similar code with 0x221025 for OHare and 0x211025 for heathrow, just to
be safe.

>Any guesses about the meaning of this register?  It feels wrong somehow to
>just ape MacOS without knowing what's really going on.  :)

Good question ;-) I'm wondering if this could configure the timing of the
DMA engine on the data port. I tried with my CD-ROM and it works too (I
didn't hdparm it but at least, the CD mounts weel and I didn't see any
problem). It would be great to test with really slow devices however (my
CD is a very fast one).

Another question about IDE: Does someone have any info about IDE ZIP
drives ? I received a mail from someone which is having all sorts of
trouble with a ZIP in the expansion bay. Looks like the beast is not
correctly answering ATAPI commands sent by the driver (yeah, ATAPI, I
thought a ZIP would be plain IDE or floppy-IDE but apparently, his drive
is recognized as an ATAPI one).

-- 
           E-Mail: <mailto:bh40@calva.net>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>





[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Great IDE perf (WAS: Strange PMAC IDE performance)

[Timothy A. Seufert]

At 12:59 PM +0100 1/7/99, Benjamin Herrenschmidt wrote:

>Great ! I also included this initialisation in my latest set of patch and
>test kernel but currently, I test against "heathrow-ata" in the
>compatible property, so it won't do it on your machine. Could you tell me
>the value of the compatible property of the ATA on the 2400 ? I'll add
>similar code with 0x221025 for OHare and 0x211025 for heathrow, just to
>be safe.

It's "ohare-ata".  Should apply to any machine with the O'Hare I/O ASIC
(which includes many (all?) of the desktop 603e PCI machines, not just the
older PCI PowerBooks).

  Tim Seufert

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Great IDE perf (WAS: Strange PMAC IDE performance)

[Benjamin Herrenschmidt]

On Thu, Jan 7, 1999, Timothy A. Seufert <tas@mindspring.com> wrote:

>It's "ohare-ata".  Should apply to any machine with the O'Hare I/O ASIC
>(which includes many (all?) of the desktop 603e PCI machines, not just the
>older PCI PowerBooks).

I'm a little bit afraid of enabling this for older machines blindly. I
think I'll do a patch that looks for a specific config option on the
command line until enough people have tested it. After all, this may put
user's datas at risk.

Until Paul finds a more clear meaning of all this, this option should
allow to test if the values we found in MacOS are fine for all machines.
I could add code to BootX that sends the current MacOS values to linux
but this would really be too hackish, I think.

I'll update my test kernel and patch set later tonight or tomorrow.

-- 
           E-Mail: <mailto:bh40@calva.net>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>





[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Great IDE perf (WAS: Strange PMAC IDE performance)

[Paul Mackerras]

Benjamin Herrenschmidt <bh40@calva.net> wrote:

> Another question about IDE: Does someone have any info about IDE ZIP
> drives ? I received a mail from someone which is having all sorts of
> trouble with a ZIP in the expansion bay. Looks like the beast is not
> correctly answering ATAPI commands sent by the driver (yeah, ATAPI, I
> thought a ZIP would be plain IDE or floppy-IDE but apparently, his drive
> is recognized as an ATAPI one).

I have an ide zip drive on my desktop G3, which appears as an ATAPI
floppy drive.  It works fine.  So it's going to take some digging to
find out why the expansion bay ZIP doesn't work. :-(

Paul.

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Great IDE perf (WAS: Strange PMAC IDE performance)

[Benjamin Herrenschmidt]

On Fri, Jan 8, 1999, Paul Mackerras <paulus@cs.anu.edu.au> wrote:

>I have an ide zip drive on my desktop G3, which appears as an ATAPI
>floppy drive.  It works fine.  So it's going to take some digging to
>find out why the expansion bay ZIP doesn't work. :-(

Apparenlty, his ZIP is beeing recognized as a CDROM device, which is
obviously wrong. I'll dig around in the code and looks if I see something
obvious.


-- 
           E-Mail: <mailto:bh40@calva.net>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>





[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Great IDE perf (WAS: Strange PMAC IDE performance)

[Benjamin Herrenschmidt]

I tested on the iMac, and we have also the same register with the same
value. All three machines have the compatible property of the ide in the
device tree set to "heathrow-ata". I'm building a test kernel along with
other patches I made with a quick hack for this, I'll post it soon with
diffs so people can play with it and do real testings.


-- 
           E-Mail: <mailto:bh40@calva.net>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>





[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]