[parisc-linux] Results of (IDE) kernel tests with modified io.c

[parisc-linux] Results of (IDE) kernel tests with modified io.c

[M. Grabert]

Hi,

I finally made the kernels tests I promised.
Sorry it took so long, but my serial null-modem cable was broken and I
had to get a new one ...


About the test:
---------------
It seems that currently Linux/PA-RISC doesn't support IDE-hard disks
with anything other than the onboard NS87415 chip of the B/Cxxx0.
Furthermore it seems that the onbard chip also doesn't use DMA
transfers and works for me only with 2.4 kernels.

Therefore I tried a Silicon Image Si680 PCI IDE controller, and a
Promise Ultra100 TX2 PCI IDE controller with both 2.4 and 2.6 kernels and
they didn't work either.


Recent discussions on p-l led to the assumption that io.c may be
broken and tests with a modified arch/parisc/io.c would be helpful.
Therefore I took out all references to leXX_to_cpu and cpu_to_leXX in io.c
and built various kernels and ran them.

I created four 2.4.25-pa0 kernel with the following configs:

- one with support for onboard NS87415 of my C3000
- one using the (new) Promise PDC202{68|69|70|71|75|76|77} driver
- one using the (old) Promise PDC202{46|62|65|67} driver
- one using the siimage driver

And then I did the same for the 2.6.4-rc1-pa1 kernel (also four configs).

N.B.
- I enabled "Use PCI DMA by default when available" for all kernels.
- I did a CVS update at March 03 22:00 GMT (for both 2.4 and 2.6 kernel
  sources) before built the kernels.
- The Silicon Image PCI card and the Promise PCI card where put in
  a PCI 33MHz slot (only one card at a time)
- I'm using a Seagate ST311022A 120GB IDE hard drive to test
  the IDE controllers.


Test results:
-------------

linux-2.4.25-pa0-io:
   - detects IDE controller: "NS87415: 100% native mode on irq 103"
   - detects hard disk wrongly as "TS130220A2", no access possible
   - NO "hda: lost interrupt" messages on boot up
   - NOTE: the unpatched vanilla kernel was correctly identifying hard
     disk as "ST3120022A" and also detects partitions correcty.
     works fine, but with merely 3.3 MB/s (obviously no DMA transfer used)

linux-2.4.25-pa0-io-promise:
   - detects IDE controller:
        "PDC20268: not 100% native mode: will probe irqs later"
   - detects hard disk wrongly as "TS130220A2", no access possible
   - "hda: lost interrupt" messages
   - NOTE: the unpatched vanilla kernel was correctly identifying hard
     disk as "ST3120022A" and also detects partitions correcty.
     However access is very slow (e.g. fdisk takes minutes), seems like
     problems with interrupts

linux-2.4.25-pa0-io-promiseold:
   - Stack dump while trying to detect IDE controller

linux-2.4.25-pa0-io-siimage:
   - detects IDE controller:
       "SiI680: not 100% native mode: will probe irqs later"
   - detects hard disk wrongly as "TS130220A2", no access possible
   - "hda: lost interrupt" messages
   - NOTE: the unpatched vanilla kernel was also identifying the hard disk
     wrongly as "TS130220A2"!

linux-2.6.4-rc1-pa1-io:
   - detects IDE controller: "NS87415: 100% native mode on irq 103"
   - detects hard disk wrongly as "TS130220A2", no access possible
   - stops booting with "Kernel panic: ide: default attach failed"
   - NOTE: an slightly older (unpatched) vanilla kernel was correctly
     identifying  hard disk as "ST3120022A" and also detects partitions
     correcty, but I wasn't able to use the hard disk
     (IIRC "lots interrupt" messages; sorry I didn't find a boot log)

linux-2.6.4-rc1-pa1-io-promise:
   - detects IDE controller: "PDC20268: 100% native mode on irq 128"
   - detects hard disk wrongly as "TS130220A2", no access possible
   - stops booting with "Kernel panic: ide: default attach failed"
   - NOTE: an unpatched, vanilla 2.6.3-pa2 kernel was correctly
     identifying hard disk as "ST3120022A" and also detects partitions correcty,
     but with lots of "lots interrupt messages"

linux-2.6.4-rc1-pa1-io-promiseold:
   - Stack dump while trying to detect IDE controller

linux-2.6.4-rc1-pa1-io-siimage:
   - detects IDE controller: "SiI680: 100% native mode on irq 128"
   - detects hard disk wrongly as "TS130220A2", no access possible
   - stops booting with "Kernel panic: ide: default attach failed"
   - NOTE: an unpatched, vanilla 2.6.0-test11-pa2 kernel was also
     identifying the hard disk wrongly as "TS130220A2", but stopped with
     "Your System ate a SPARC!"


The configs, boot logs and System.maps and the modified io.c can be found
here: http://www.cs.ucc.ie/~xam/io/

Some reports of old tests with unpatched kernels can be found in my
previous mails (search the p-l archive), and some info is also here:
http://www.cs.ucc.ie/~xam/siimage/
http://www.cs.ucc.ie/~xam/promise/


Hope that helps,
  Max

Re: [parisc-linux] Results of (IDE) kernel tests with modified io.c

[Randolph Chung]

> Recent discussions on p-l led to the assumption that io.c may be
> broken and tests with a modified arch/parisc/io.c would be helpful.
> Therefore I took out all references to leXX_to_cpu and cpu_to_leXX in io.c
> and built various kernels and ran them.

as you found out in your tests, io.c is correct as it was before.... I
think Grant got confused with our original pci mmio macros which had
wrong endian.... but that was a very long time ago :)

I am trying to bring up the ns87415 ide controller on my c3750.. not
much luck yet :-(

for the other controllers, you might need a pci fixup to bring the 
devices into native mode (as Alan mentioned in his email). i wonder if
it's safe to automatically set all IDE devices to native mode?

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] Results of (IDE) kernel tests with modified io.c

[M. Grabert]

On Mon, 8 Mar 2004, Randolph Chung wrote:

> > Recent discussions on p-l led to the assumption that io.c may be
> > broken and tests with a modified arch/parisc/io.c would be helpful.
> > Therefore I took out all references to leXX_to_cpu and cpu_to_leXX in io.c
> > and built various kernels and ran them.
>
> as you found out in your tests, io.c is correct as it was before.... I
> think Grant got confused with our original pci mmio macros which had
> wrong endian.... but that was a very long time ago :)

Guessing from his last messages about this topic it seems so ;-P

> I am trying to bring up the ns87415 ide controller on my c3750.. not
> much luck yet :-(

I don't have any troubles with it since 2.4.21 on my C3000, just DMA is
not working. However I can't get it working on 2.6 either.

> for the other controllers, you might need a pci fixup to bring the
> devices into native mode (as Alan mentioned in his email). i wonder if
> it's safe to automatically set all IDE devices to native mode?

I don't have much knowledge about IDE and especially no knowledge how
different linux architectures are dealing with it.
But since some of the cards work on other linux architectures
(e.g. the Promise card is reproted to run on Linux/PPC), it is definitely
possible.

But what I'm wondering about is why the Silicon Image driver
(always) detects the Seagate ST311022A hard drive as "TS130220A2".
Since it uses mmio instead of PIO as the other drivers, maybe there is
some big-endian problem in the Linux/PA-RISC mmio code? But then this
problem must be somewhere in the IDE code, since all mmio in general
seems to be working fine!

Slightly confused,
  Max

Re: [parisc-linux] Results of (IDE) kernel tests with modified io.c

[Randolph Chung]

> But what I'm wondering about is why the Silicon Image driver
> (always) detects the Seagate ST311022A hard drive as "TS130220A2".
> Since it uses mmio instead of PIO as the other drivers, maybe there is
> some big-endian problem in the Linux/PA-RISC mmio code? But then this
> problem must be somewhere in the IDE code, since all mmio in general
> seems to be working fine!

oh, for mmio you need to fix the macros in include/asm-parisc/ide.h. the
ones in io.c are for pio access. the mmio ones are new, i think, and 
haven't been fixed properly (__ide_mm_insw, etc) -- you can try 
replacing readw with __raw_readw, etc.

can you also try the native-mode fixup? something like this (sorry 
it's not in patch format, my tree is a bit of a mess right now and it's
late....)

in arch/parisc/kernel/pci.c, change:

struct pci_fixup pcibios_fixups[] = {
        { PCI_FIXUP_HEADER, PCI_ANY_ID, PCI_ANY_ID, parisc_fixup_ide },
        { 0 }
};

parisc_fixup_ide is something like this:

static void __devinit parisc_fixup_ide(struct pci_dev *dev)
{
    u8 prog;

    if ((dev->class >> 8) != PCI_CLASS_STORAGE_IDE)
        return;

    pci_read_config_byte(dev, 8, &prog);
    pci_write_config_byte(dev, 8, prog | 0x5);
    dev->class |= 0x5;
}

not tested, YMMV :)

Grant tells me that he suspects there's a bug somewhere in the pci
config accessor functions tho... on my box i saw that, using something
similar to the above sequence, i read 0x8a into prog (this is the 
default), but after the write if i read it again the value is still 
0x8a :(

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

[parisc-linux] 2.6.4-rc1-pa3 siimage/NS87415 IDE progess (and another mystery)!

[M. Grabert]

On Mon, 8 Mar 2004, Randolph Chung wrote:

> > But what I'm wondering about is why the Silicon Image driver
> > (always) detects the Seagate ST311022A hard drive as "TS130220A2".
> > Since it uses mmio instead of PIO as the other drivers, maybe there is
> > some big-endian problem in the Linux/PA-RISC mmio code? But then this
> > problem must be somewhere in the IDE code, since all mmio in general
> > seems to be working fine!
>
> oh, for mmio you need to fix the macros in include/asm-parisc/ide.h. the
> ones in io.c are for pio access. the mmio ones are new, i think, and
> haven't been fixed properly (__ide_mm_insw, etc) -- you can try
> replacing readw with __raw_readw, etc.

I also changed readl, writew and writel accordingly (for 2.6.4-rc1-pa3)

> can you also try the native-mode fixup? something like this (sorry
> it's not in patch format, my tree is a bit of a mess right now and it's
> late....)

Did that too, and had some success!

Now the siimage driver detects the hard drive correctly as "ST311022A" and
also sees the partition. Even mounting works, but I see lots of
"hda: lost interrupt" messages and it takes forever (several minutes) to
mount.

So I now got as far with the siimage driver as with the promise driver.
Both somewhat work, but there is a interrupt delivery problem.


===========

But NOW I have some very weird problem for you!

I also compiled a kernel with the same changes to ide.h and pci.c,
but this time using the NS87415 driver (onboard IDE of the C3000).

I doubt that the pci.c and ide.h changes contribute to the mystery, but I
could not verify  it yet by compiling a unpatched, vanilla linux-2.6.4-rc1-pa3
kernel.

Anyway, the IDE hard drive works with the onboard IDE controller of the C3000!


... Well, not 100%. Let me explain. The mystery is:

IDE works fine (without DMA support, like in the 2.4 kernels), as long as
I interrupt the automatic boot up and to a "sea" followed by a "bo pri".

If I just start the machine and don't interrupt the automatic boot up,
it will cause a HPMC. Also if I do interrupt the automatic boot up,
and just do a "bo pri" WITHOUT a "sea" first, it will also cause a HPMC.

This is 100% reproduceable. I rebooted the machine 6 times without
interruption of the boot up sequence, and 7 times I interrupted and
did a "sea" inbetween, and every time the same result.

Just to be sure I also did the following:

- Sometimes I rebooted several times after each other without interrupting
  the boot sequence, and I every time got a HPMC.
- Sometimes I interrupted twice in a row and did a "sea" and IDE worked
  every time.
- Sometimes I soft rebooted instead of hitting the power button (power cycle),
  and every time it was the same result: it only works when I do "sea"
  at the PDC.

BTW, I have "AutoSearch ON".

So it seems "sea" is initializing the IDE card or some PCI registers,
and IDE works. Without it it causes a HPMC.

Perhaps this is related with the (possible) problem in the PCI config
accessor functions (as Grant suspects).


Randolph, it might be even the case that IDE is also working for you
and your 2.6 kernel you are experimenting with, if you just do a "sea"
before booting palo/linux.
Maybe the onboard IDE controller was working all time with previous 2.6
kernels, but I didn't notice it since I didn't do a "sea" back then ...



Further info (boot logs etc.) can be found here:
http://www.cs.ucc.ie/~xam/ide/


Thanks for your attention,
  Max

[parisc-linux] Re: 2.6.4-rc1-pa3 siimage/NS87415 IDE progess (and another mystery)!

[Grant Grundler]

[ Note the date! sorry...finally got around to this...]

On Tue, Mar 09, 2004 at 03:26:00PM +0000, M. Grabert wrote:
...
> But NOW I have some very weird problem for you!
...
> Anyway, the IDE hard drive works with the onboard IDE controller of the C3000!
> ... Well, not 100%. Let me explain. The mystery is:
> 
> IDE works fine (without DMA support, like in the 2.4 kernels), as long as
> I interrupt the automatic boot up and to a "sea" followed by a "bo pri".

I looked at what the firmware is doing "out of the ordinary"
and it's only writing three config space registers at 0x40-0x42 offset
of the suckyio IDE. I appended a patch that does the same thing.
Well, almost. We don't want to mask interrupts in CTRL2.

And it seems to work. At least with the CD-532E-B 32X ATAPI CD-ROM drive.
I only tried  to "dd" from a data CD with and without DMA enabled.
w/o DMA I get ~900KB/s and with DMA I get ~2.4MB/s (8K blocks).

Now if someone could explain WTH the following bits in suckyIO
mean, it would likely explain why the DMA didn't work before.
See the 87560.pdf (page 247) available from parisc-linux docs:
	
| 20.4.17 Control Register 1
...
| bit  Description
|  4   Channel 1 Drive 1 IDE/ATAPI Buffer Mode
|      0: Normal IDE prefetch buffer mode (default)
|      1: ATAPI buffer mode (no prefetching)

which I think is related to CTRL3 (0x42):
| 20.4.19 Control Register 3
...
| Bit Description
|  0  Channel 1 Pre-fetch Buffer.
|     0: Disabled
|     1: Enabled
|  1  Channel 2 Pre-fetch Buffer.
|     0: Disabled
|     1: Enabled

(NS87415 data sheet says essentially the identical thing)


Can you (or anyone else) test this patch with IDE disk drive on C3000?
If this works, I can get rid of the magic numbers (define constants)
and commit the code.

grant

Index: drivers/ide/pci/ns87415.c
===================================================================
RCS file: /var/cvs/linux-2.6/drivers/ide/pci/ns87415.c,v
retrieving revision 1.16
diff -u -p -r1.16 ns87415.c
--- drivers/ide/pci/ns87415.c	16 Jun 2004 18:47:42 -0000	1.16
+++ drivers/ide/pci/ns87415.c	11 Jul 2004 21:54:17 -0000
@@ -235,6 +235,25 @@ static ide_pci_device_t ns87415_chipset 
 
 static int __devinit ns87415_init_one(struct pci_dev *dev, const struct pci_device_id *id)
 {
+#ifdef CONFIG_PARISC
+	u8 progif = 0;
+
+	/* Firmware (IODC) doesn't init this unless we interrupt
+	 * the auto-boot and "search".
+	 */
+	pci_read_config_byte(dev, PCI_CLASS_PROG, &progif);
+	pci_write_config_byte(dev, PCI_CLASS_PROG, progif | 0x8f);
+
+	/* IODC clobbers the CTRL registers with:
+	 * CTRL1 = 0xf0 = "ATAPI buffer mode (no prefetching)" for everyone
+	 * CTRL2 = 0x03 = mask chan1/2 interrupts
+	 * CTRL3 = 0x00 = "disable prefetch buffer"/"Master Wait States"
+	 */
+	pci_write_config_byte(dev, 0x40, 0xf0); /* IDE_CTRL1 */
+	pci_write_config_byte(dev, 0x41, 0x00); /* IDE_CTRL2 */
+	pci_write_config_byte(dev, 0x42, 0x00); /* IDE_CTRL3 */
+#endif
+
 	ide_setup_pci_device(dev, &ns87415_chipset);
 	return 0;
 }
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

[parisc-linux] Re: 2.6.4-rc1-pa3 siimage/NS87415 IDE progess (and another mystery)!

[M. Grabert]

On Sun, Jul 11, 2004 at 04:18:29PM -0600, Grant Grundler wrote:

> [ Note the date! sorry...finally got around to this...]
>
> On Tue, Mar 09, 2004 at 03:26:00PM +0000, M. Grabert wrote:
> ...

No problem, as long as it's not forgotten ;)

> > But NOW I have some very weird problem for you!
> ...
> > Anyway, the IDE hard drive works with the onboard IDE controller of the C3000!
> > ... Well, not 100%. Let me explain. The mystery is:
> > 
> > IDE works fine (without DMA support, like in the 2.4 kernels), as long as
> > I interrupt the automatic boot up and to a "sea" followed by a "bo pri".
> 
> I looked at what the firmware is doing "out of the ordinary"
> and it's only writing three config space registers at 0x40-0x42 offset
> of the suckyio IDE. I appended a patch that does the same thing.
> Well, almost. We don't want to mask interrupts in CTRL2.

Great (investigative) work!

[...]

> Can you (or anyone else) test this patch with IDE disk drive on C3000?
> If this works, I can get rid of the magic numbers (define constants)
> and commit the code.

Will try it asap and post the result on the list.

Thanks alot,
   Max
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

[parisc-linux] Re: 2.6.4-rc1-pa3 siimage/NS87415 IDE progess (and another mystery)!

[Randolph Chung]

> Can you (or anyone else) test this patch with IDE disk drive on C3000?
> If this works, I can get rid of the magic numbers (define constants)
> and commit the code.

don't have an IDE drive to try it with, but if it works, shouldn't it be
done as a pcibios fixup instead? We already have a fixup routine in
drivers/parisc/superio.c:superio_fixup_pci(), so you can probably just
add it there.

thanks
randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: 2.6.4-rc1-pa3 siimage/NS87415 IDE progess (and another mystery)!

[Randolph Chung]

> don't have an IDE drive to try it with, but if it works, shouldn't it be
> done as a pcibios fixup instead? We already have a fixup routine in
> drivers/parisc/superio.c:superio_fixup_pci(), so you can probably just
> add it there.

i.e. (the progif write was removed since it's redundant):

Index: drivers/parisc/superio.c
===================================================================
RCS file: /var/cvs/linux-2.6/drivers/parisc/superio.c,v
retrieving revision 1.9
diff -u -p -r1.9 superio.c
--- drivers/parisc/superio.c	18 May 2004 13:08:56 -0000	1.9
+++ drivers/parisc/superio.c	11 Jul 2004 23:33:06 -0000
@@ -482,6 +482,16 @@ void superio_fixup_pci(struct pci_dev *p
 	pci_write_config_byte(pdev, PCI_CLASS_PROG, pdev->class);
 
 	pci_read_config_byte(pdev, PCI_CLASS_PROG, &prog);
+
+	/* IODC clobbers the CTRL registers with:
+	 * CTRL1 = 0xf0 = "ATAPI buffer mode (no prefetching)" for everyone
+	 * CTRL2 = 0x03 = mask chan1/2 interrupts
+	 * CTRL3 = 0x00 = "disable prefetch buffer"/"Master Wait States"
+	 */
+	pci_write_config_byte(pdev, 0x40, 0xf0); /* IDE_CTRL1 */
+	pci_write_config_byte(pdev, 0x41, 0x00); /* IDE_CTRL2 */
+	pci_write_config_byte(pdev, 0x42, 0x00); /* IDE_CTRL3 */
+
 	printk("PCI: Enabled native mode for NS87415 (pif=0x%x)\n", prog);
 }
 

works fine on my c3750 with a cdrom drive too! Great job Grant :)

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: 2.6.4-rc1-pa3 siimage/NS87415 IDE progess (and another mystery)!

[Grant Grundler]

On Sun, Jul 11, 2004 at 04:34:39PM -0700, Randolph Chung wrote:
> i.e. (the progif write was removed since it's redundant):

Much nicer. Here's the cleaned up patch based on your code 
that I'd like to commit.

grant


Index: Makefile
===================================================================
RCS file: /var/cvs/linux-2.6/Makefile,v
retrieving revision 1.220
diff -u -p -r1.220 Makefile
--- Makefile	11 Jul 2004 17:31:32 -0000	1.220
+++ Makefile	12 Jul 2004 00:07:49 -0000
@@ -1,7 +1,7 @@
 VERSION = 2
 PATCHLEVEL = 6
 SUBLEVEL = 7
-EXTRAVERSION = -pa13
+EXTRAVERSION = -pa14
 NAME=Zonked Quokka
 
 # *DOCUMENTATION*
Index: drivers/parisc/superio.c
===================================================================
RCS file: /var/cvs/linux-2.6/drivers/parisc/superio.c,v
retrieving revision 1.9
diff -u -p -r1.9 superio.c
--- drivers/parisc/superio.c	18 May 2004 13:08:56 -0000	1.9
+++ drivers/parisc/superio.c	12 Jul 2004 00:07:49 -0000
@@ -483,6 +483,13 @@ void superio_fixup_pci(struct pci_dev *p
 
 	pci_read_config_byte(pdev, PCI_CLASS_PROG, &prog);
 	printk("PCI: Enabled native mode for NS87415 (pif=0x%x)\n", prog);
+
+	/* IODC clobbers the SuckyIO CTRL registers when we "search"
+	 * from BCH command line. Code below does the same.
+	 */
+	pci_write_config_byte(pdev, SIO_IDE_CTRL1, SIO_IDE_ATAPI_BUF);
+	pci_write_config_byte(pdev, SIO_IDE_CTRL2, 0x00);
+	pci_write_config_byte(pdev, SIO_IDE_CTRL3, 0x00);
 }
 
 /* Because of a defect in Super I/O, all reads of the PCI DMA status 
Index: include/asm-parisc/superio.h
===================================================================
RCS file: /var/cvs/linux-2.6/include/asm-parisc/superio.h,v
retrieving revision 1.4
diff -u -p -r1.4 superio.h
--- include/asm-parisc/superio.h	11 Mar 2004 05:41:54 -0000	1.4
+++ include/asm-parisc/superio.h	12 Jul 2004 00:07:49 -0000
@@ -12,6 +12,16 @@
 #define SIO_SP2BAR 0x98		/* Serial 2 BAR */
 #define SIO_PPBAR  0x9C		/* Parallel BAR */
 
+/* IDE (NS87415) CTRL registers */
+#define SIO_IDE_CTRL1  0x40	/* IDE Control Register 1 */
+#define   SIO_IDE_ATAPI_BUF 0xf0   /* "ATAPI buffer mode (no prefetching)" */
+#define SIO_IDE_CTRL2  0x41	/* IDE Control Register 2 */
+#define   SIO_IDE_CHAN1_IRQ 0x01   /* mask Channel 1 IRQ */
+#define   SIO_IDE_CHAN2_IRQ 0x02   /* mask Channel 2 IRQ */
+#define SIO_IDE_CTRL3  0x42	/* IDE Control Register 3 */
+#define   SIO_IDE_CHAN1_PREFETCH_ENB 0x01 /* Enable "Chan 1 Pre-fetch Buffer" */
+#define   SIO_IDE_CHAN2_PREFETCH_ENB 0x02
+
 #define TRIGGER_1  0x67		/* Edge/level trigger register 1 */
 #define TRIGGER_2  0x68		/* Edge/level trigger register 2 */
 
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: 2.6.4-rc1-pa3 siimage/NS87415 IDE progess (and another mystery)!

[M. Grabert]

On Sun, Jul 11, 2004 at 04:34:39PM -0700, Randolph Chung wrote:

> > don't have an IDE drive to try it with, but if it works, shouldn't it be
> > done as a pcibios fixup instead? We already have a fixup routine in
> > drivers/parisc/superio.c:superio_fixup_pci(), so you can probably just
> > add it there.
> 
> i.e. (the progif write was removed since it's redundant):
> 
> Index: drivers/parisc/superio.c
> ===================================================================
> RCS file: /var/cvs/linux-2.6/drivers/parisc/superio.c,v
> retrieving revision 1.9
> diff -u -p -r1.9 superio.c
> --- drivers/parisc/superio.c	18 May 2004 13:08:56 -0000	1.9
> +++ drivers/parisc/superio.c	11 Jul 2004 23:33:06 -0000
> @@ -482,6 +482,16 @@ void superio_fixup_pci(struct pci_dev *p
>  	pci_write_config_byte(pdev, PCI_CLASS_PROG, pdev->class);
>  
>  	pci_read_config_byte(pdev, PCI_CLASS_PROG, &prog);
> +
> +	/* IODC clobbers the CTRL registers with:
> +	 * CTRL1 = 0xf0 = "ATAPI buffer mode (no prefetching)" for everyone
> +	 * CTRL2 = 0x03 = mask chan1/2 interrupts
> +	 * CTRL3 = 0x00 = "disable prefetch buffer"/"Master Wait States"
> +	 */
> +	pci_write_config_byte(pdev, 0x40, 0xf0); /* IDE_CTRL1 */
> +	pci_write_config_byte(pdev, 0x41, 0x00); /* IDE_CTRL2 */
> +	pci_write_config_byte(pdev, 0x42, 0x00); /* IDE_CTRL3 */
> +
>  	printk("PCI: Enabled native mode for NS87415 (pif=0x%x)\n", prog);
>  }
>  
> 
> works fine on my c3750 with a cdrom drive too! Great job Grant :)

Tested above patch, but unfortunately it didn't work for me,
the NS87415 still doesn't use DMA (or so it seems, at least it's
still the 3MB/s instead of the expected 30-40MB/s).

hdparm -c /dev/hda showed DMA was turned on, and I even set it on
again (hdparm -c 1), just to be sure, but it didn't make any
difference in performance :(

Thanks,
   Max


PS: shall I try Grant's patch aswell?
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: 2.6.4-rc1-pa3 siimage/NS87415 IDE progess (and another mystery)!

[M. Grabert]

Sorry, there was a typo:

On Mon, Jul 12, 2004 at 04:37:52AM +0100, xam wrote:
>
> hdparm -c /dev/hda showed DMA was turned on, and I even set it on
> again (hdparm -c 1), just to be sure, but it didn't make any
> difference in performance :(

I meant 'hdparm -d' of course ...

BTW, what are the supported DMA modes of the NS87415?
The kernel just reports this:

  DMA zone: 262144 pages, LIFO batch:16
    ide0: BM-DMA at 0x0a00-0x0a07, BIOS settings: hda:pio, hdb:pio
    ide1: BM-DMA at 0x0a08-0x0a0f, BIOS settings: hdc:pio, hdd:pio
  hda: 234441648 sectors (120034 MB) w/2048KiB Cache, CHS=16383/255/63, (U)DMA
          
I suppose BM-DMA means BusMaster-DMA, but does the NS87415 support any
Ultra-DMA modes, or only Multi-Word DMA?
A 'hdparm -i /dev/hda' says this about the hdd settings/capabilities:

  PIO modes:  pio0 pio1 pio2 pio3 pio4
  DMA modes:  mdma0 mdma1 *mdma2
  UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5

Here's the performance table for pio/mdma/udma:

   pio0    3.33 MB/s
   pio1    5.22 MB/s
   pio2    8.33 MB/s
   pio3   11.11 MB/s
   pio4   16.67 MB/s
  mdma0    4.16 MB/s
  mdma1   13.33 MB/s
  mdma2   16.67 MB/s
  mdma3   33.33 MB/s
  udma0   16.67 MB/s
  udma1   25.00 MB/s
  udma2   33.33 MB/s
  udma3   44.44 MB/s
  udma4   66.67 MB/s
  udma5  100.00 MB/s
  udma6  133.33 MB/s

According to the current setting (mdma2), I should get about 16 MB/s
(the hard disk specified 'sustained data transfer rate' is >40 MB/s).
However with a 2.4 kernel I only get 3.3 MB/s and with a 2.6 kernel
I get just about 3.0 MB/s, which suggests it's running in 'pio0' mode.

Also there is a significant CPU load whenever I do a read/write access to
the IDE hard disk (compared to the CPU load when I access the SCSI disks),
which might be another indication that it's still using PIO and not DMA.


Final question:

Is 
  'hdparm -c 1' (enable 32bit I/O)
and
  'hdparm -u 1' (unmasq_irq)
useful/implemented on PA-RISC?


Greetings,
   Max
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: 2.6.4-rc1-pa3 siimage/NS87415 IDE progess (and another mystery)!

[Grant Grundler]

On Mon, Jul 12, 2004 at 05:19:35AM +0100, M. Grabert wrote:
> BTW, what are the supported DMA modes of the NS87415?

Hopefully the ns87415 data sheet will specify that.

> I suppose BM-DMA means BusMaster-DMA, but does the NS87415 support any
> Ultra-DMA modes, or only Multi-Word DMA?

DMA from the IDE controller are just regular PCI transactions.
There is no such thing as Ultra-DMA for PCI.
There is a Multi-Word DMA but I'm skeptical it's the same thing
exactly than what IDE spec means.

....
> According to the current setting (mdma2), I should get about 16 MB/s
> (the hard disk specified 'sustained data transfer rate' is >40 MB/s).
> However with a 2.4 kernel I only get 3.3 MB/s and with a 2.6 kernel
> I get just about 3.0 MB/s, which suggests it's running in 'pio0' mode.

If the IDE controller is NOT prefetching data into a local buffer,
I don't think it will be able to efficiently burst data across
the PCI bus.

> Also there is a significant CPU load whenever I do a read/write access to
> the IDE hard disk (compared to the CPU load when I access the SCSI disks),
> which might be another indication that it's still using PIO and not DMA.

Yes, that's probably a better indicator.

> Is 
>   'hdparm -c 1' (enable 32bit I/O)
> and
>   'hdparm -u 1' (unmasq_irq)
> useful/implemented on PA-RISC?

I don't think this is platform specific.
I expect both of those to be card/driver specific.

grant
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: 2.6.4-rc1-pa3 siimage/NS87415 IDE progess (and another mystery)!

[M. Grabert]

On Mon, Jul 12, 2004 at 10:14:44AM -0600, Grant Grundler wrote:

> On Mon, Jul 12, 2004 at 05:19:35AM +0100, M. Grabert wrote:
> > BTW, what are the supported DMA modes of the NS87415?
> 
> Hopefully the ns87415 data sheet will specify that.
> 
> > I suppose BM-DMA means BusMaster-DMA, but does the NS87415 support any
> > Ultra-DMA modes, or only Multi-Word DMA?
> 
> DMA from the IDE controller are just regular PCI transactions.
> There is no such thing as Ultra-DMA for PCI.

I see what you mean. Yes, sorry for mixing up these terms in
the same sentence. But it seems you understood what I wanted to say ;)

[...]

> If the IDE controller is NOT prefetching data into a local buffer,
> I don't think it will be able to efficiently burst data across
> the PCI bus.

Ah, and you fixed prefetching with the latest patch? Now I understand
the issue ...

> > Also there is a significant CPU load whenever I do a read/write access to
> > the IDE hard disk (compared to the CPU load when I access the SCSI disks),
> > which might be another indication that it's still using PIO and not DMA.
> 
> Yes, that's probably a better indicator.
>
> > Is 
> >   'hdparm -c 1' (enable 32bit I/O)
> > and
> >   'hdparm -u 1' (unmasq_irq)
> > useful/implemented on PA-RISC?

Well, it doesn't change the performance in any way.

> I don't think this is platform specific.
> I expect both of those to be card/driver specific.

The first, yes. But I'm not sure about the second (unmask_irq).


Thanks,
   Max
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: 2.6.4-rc1-pa3 siimage/NS87415 IDE progess (and another mystery)!

[Grant Grundler]

On Mon, Jul 12, 2004 at 07:51:32PM +0100, M. Grabert wrote:
> > If the IDE controller is NOT prefetching data into a local buffer,
> > I don't think it will be able to efficiently burst data across
> > the PCI bus.
> 
> Ah, and you fixed prefetching with the latest patch? Now I understand
> the issue ...

I don't think so. I think I've got the various parts of the IDE
controller to NOT prefetch. You need to read the 87560.pdf file
that is available from the parisc-linux.org Tech Docs page.
Then you'll know as much as I do about this IDE controller.
I'm really clueless about how IDE works internally.

grant
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: 2.6.4-rc1-pa3 siimage/NS87415 IDE progess (and another mystery)!

[Grant Grundler]

On Mon, Jul 12, 2004 at 09:56:32PM -0600, Grant Grundler wrote:
> You need to read the 87560.pdf file that is available from
> the parisc-linux.org Tech Docs page.

Sorry - double brainfart.
I meant PC87415.pdf file and I just added it.

grant
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: 2.6.4-rc1-pa3 siimage/NS87415 IDE progess (and another mystery)!

[Alan Cox]

On Llu, 2004-07-12 at 17:14, Grant Grundler wrote:
> > Is 
> >   'hdparm -c 1' (enable 32bit I/O)
> > and
> >   'hdparm -u 1' (unmasq_irq)
> > useful/implemented on PA-RISC?
> 
> I don't think this is platform specific.
> I expect both of those to be card/driver specific.

Both are implemented in the core code. In the case of -c 1 it isnt going
to do anything relevant. -u 1 ought to have little effect in DMA modes

_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: 2.6.4-rc1-pa3 siimage/NS87415 IDE progess (and another mystery)!

[Grant Grundler]

On Mon, Jul 12, 2004 at 04:37:52AM +0100, M. Grabert wrote:
> Tested above patch, but unfortunately it didn't work for me,

The rest of your post in fact suggests it did.
Ie you should no longer need to "sea" at the boot prompt.

> the NS87415 still doesn't use DMA (or so it seems, at least it's
> still the 3MB/s instead of the expected 30-40MB/s).
> 
> hdparm -c /dev/hda showed DMA was turned on, and I even set it on
> again (hdparm -c 1), just to be sure, but it didn't make any
> difference in performance :(

This patch makes no attempt at changing existing DMA behaviors.
It's likely the NS87415 code needs to twiddle the "Prefetch Mode"
bits for something other than ATAPI (no prefetch) to get
better performance.

grant
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: 2.6.4-rc1-pa3 siimage/NS87415 IDE progess (and another mystery)!

[M. Grabert]

On Mon, Jul 12, 2004 at 10:05:34AM -0600, Grant Grundler wrote:

> On Mon, Jul 12, 2004 at 04:37:52AM +0100, M. Grabert wrote:
> > Tested above patch, but unfortunately it didn't work for me,
> 
> The rest of your post in fact suggests it did.
> Ie you should no longer need to "sea" at the boot prompt.

OOOooOOoooopps!
This isse was resolved by Randolph, back in March, 9th:

|>  ...just add in this bit in the fixup routine:"
|>  
|>   +  pci_read_config_byte(pdev, PCI_CLASS_PROG, &prog);                                                                               
|>   +  printk("PCI: Enabled native mode for NS87415 (pif=0x%x)\n", prog); 

The next day (March, 10th) I sent you and Randolph a success report
after you both sent me patches:

|>  So far the only bugs remaining are the "lost interrupt" problems                
|>  for the promise/siimage drivers and getting DMA really working                  
|>  for the NS87415.

Those patches obviously made it into the CVS a couple the same day:
http://lists.parisc-linux.org/pipermail/parisc-linux-cvs/2004-March/033894.html
NS87415 onboard IDE + hard drivers worked since then, starting with the
(stock) 2.6.4-rc3-pa6 kernel.

Since everybody (Randolph, you, me) always replied privately in this
thread and we all didn't CC: the p-l, there was no record that
the 'mystery bug' had been fixed already.

> > the NS87415 still doesn't use DMA (or so it seems, at least it's
> > still the 3MB/s instead of the expected 30-40MB/s).
> > 
> > hdparm -c /dev/hda showed DMA was turned on, and I even set it on
> > again (hdparm -c 1), just to be sure, but it didn't make any
> > difference in performance :(
> 
> This patch makes no attempt at changing existing DMA behaviors.
> It's likely the NS87415 code needs to twiddle the "Prefetch Mode"
> bits for something other than ATAPI (no prefetch) to get
> better performance.

That's where I misunderstood you: I thought you patch was trying
to fix DMA.

BTW, I should have CC'ed my success report to p-l (back in March), maybe
this way you would have noticed/discovered more easily that this
particular bug has been fixed.

I hope my bug report was not the only reason what inspired you
to make this patch, otherwise it would have been an awful waste of
time :-/


Greetings,
   Max
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: 2.6.4-rc1-pa3 siimage/NS87415 IDE progess (and another mystery)!

[Randolph Chung]

> That's where I misunderstood you: I thought you patch was trying
> to fix DMA.

well, it does make a siginificant difference on my machine with a CD-ROM

If I do:
hdparm -d 1 /dev/cdrom
hdparm -t /dev/cdrom
I get about 2.4MB/sec

whereas before i used to only get ~1MB/s

which is not to say it's very fast or near what it probably should be
able to do, but it's definitely faster :)

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: 2.6.4-rc1-pa3 siimage/NS87415 IDE progess (and another mystery)!

[Grant Grundler]

On Mon, Jul 12, 2004 at 07:39:44PM +0100, M. Grabert wrote:
> OOOooOOoooopps!
> This isse was resolved by Randolph, back in March, 9th:
...
> Those patches obviously made it into the CVS a couple the same day:
> http://lists.parisc-linux.org/pipermail/parisc-linux-cvs/2004-March/033894.html
> NS87415 onboard IDE + hard drivers worked since then, starting with the
> (stock) 2.6.4-rc3-pa6 kernel.

yes - I remember those. But I thought that was just to get the
 controller working without DMA.

> That's where I misunderstood you: I thought you patch was trying
> to fix DMA.

Well, it clearly using DMA on the C3600 I was testing.
Using PIO modes I only got 1MB/s. With DMA I was getting ~2.4MB/s.
(using a 32X CD-ROM reading a Debian hppa-linux install CD).

> I hope my bug report was not the only reason what inspired you
> to make this patch, otherwise it would have been an awful waste of
> time :-/

No - I don't think it was. My hack suggests the ns87415 driver
is incomplete in it's support for ATAPI vs other IDE devices.

grant
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

[parisc-linux] Re: 2.6.4-rc1-pa3 siimage/NS87415 IDE progess (and another mystery)!

[Grant Grundler]

On Sun, Jul 11, 2004 at 04:14:01PM -0700, Randolph Chung wrote:
> > Can you (or anyone else) test this patch with IDE disk drive on C3000?
> > If this works, I can get rid of the magic numbers (define constants)
> > and commit the code.
> 
> don't have an IDE drive to try it with, but if it works, shouldn't it be
> done as a pcibios fixup instead? We already have a fixup routine in
> drivers/parisc/superio.c:superio_fixup_pci(), so you can probably just
> add it there.

Yes - you are right. I didn't even think of that.

grant
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Results of (IDE) kernel tests with modified io.c

[Grant Grundler]

On Mon, Mar 08, 2004 at 11:29:17PM -0800, Randolph Chung wrote:
...
> Grant tells me that he suspects there's a bug somewhere in the pci
> config accessor functions tho...

After getting some sleep, I'm convinced the lba_pci.c cfg accessors
are wrong. The following patch should fix the write path and IIRC,
Randolph already tried this out.

Two remaining issues:
1) I still need to figure out why the "TR4PLUS" code path doesn't work
   for config space read function. It still crashes with changes
   similar to the write path.

2) Both "astro" based workstations and servers provide PCI config
   accessors via PDC. A patch to support those was submitted a month
   or so ago but I haven't heard back if the submitter could/would
   apply the requested changes.

thanks,
grant

Index: drivers/parisc/lba_pci.c
===================================================================
RCS file: /var/cvs/linux-2.6/drivers/parisc/lba_pci.c,v
retrieving revision 1.9
diff -u -p -r1.9 lba_pci.c
--- a/drivers/parisc/lba_pci.c	4 Feb 2004 16:31:16 -0000	1.9
+++ b/drivers/parisc/lba_pci.c	9 Mar 2004 06:57:06 -0000
@@ -613,13 +612,14 @@ static int lba_cfg_write(struct pci_bus 
 	/* Basic Algorithm */
 	LBA_CFG_TR4_ADDR_SETUP(d, tok | pos);
 	switch(size) {
-	case 1: WRITE_REG8 (data, d->hba.base_addr + LBA_PCI_CFG_DATA);
+	case 1: WRITE_REG8 (data, d->hba.base_addr + LBA_PCI_CFG_DATA + (pos & 3));
 		   break;
-	case 2: WRITE_REG16(data, d->hba.base_addr + LBA_PCI_CFG_DATA);
+	case 2: WRITE_REG16(data, d->hba.base_addr + LBA_PCI_CFG_DATA + (pos & 2));
 		   break;
 	case 4: WRITE_REG32(data, d->hba.base_addr + LBA_PCI_CFG_DATA);
 		   break;
 	}
+	/* flush posted write */
 	lba_t32 = READ_REG32(d->hba.base_addr + LBA_PCI_CFG_ADDR);
 	return 0;
 }

Re: [parisc-linux] Results of (IDE) kernel tests with modified io.c

[John David Anglin]

> But what I'm wondering about is why the Silicon Image driver
> (always) detects the Seagate ST311022A hard drive as "TS130220A2".

Bytes are swapped.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)