[parisc-linux] C3000 and Promise Ultra100 TX2 PCI Controller

[parisc-linux] C3000 and Promise Ultra100 TX2 PCI Controller

[M. Grabert]

Hi,

It's me again ;)
As so often, I try to get a IDE hard disk working on Linux/PA-RISC.

My last attempts failed (using a no-name IDE controller based on the
Silicon Image Si-680 chipset).

It occurs to me that the driver has some big endian issues (and probably
some other issues aswell). I've given up hope to get it working after
I didn't receive any replies from the maintainer, linux-ide or even lkml.


Now I stumbled across several messages (on the parisc-linux mailing list)
of users who want to get Promise IDE controllers working in Linux/PA-RISC.
Since this type of IDE controller is obviously much more popular, and
since it appears to work on PPC, I thought it is "promising" to try it ;)

NB.:
I'm still using the same Seagate ST312022A hard disk (20GB IDE Ultra100)
It works fine under 2.4 and the onboard IDE of the C3k, but only at
about 3MB/s, since DMA is not working.
I still haven't gotten any success with the 2.6 kernel to work with the
onboard IDE controller (tried with and without DMA support).


First of all, I have the same symptoms on both 2.4.25-pa0 and 2.6.3-pa2:

- I get LOTS of "hda: lost interrupt messages"

- trying to access the hda is slow or hangs the process trying to access
  the IDE hard disk (and results in issuing the above mentioned messages)

- the hard disk is eventually detected correctly on boot up
  (but it takes long time - minutes - and many "hda: lost interrupt" messages)

- fdisk shows the correct information about the partitions

- using "ide=nodma", "hda=nodma" and "nodma" as kernel options doesn't
  make any difference.


So far it seems that the driver is 'somewhat' working, but it has
some kind of 'interrupt conflict', ie. it has the typical symptoms of it
(and of course the warning messages indicate that aswell).

Looking at the lkml and googling around suggested it might be related with
DMA not working, therefore I tried to disable it; no difference.
Other than that I didn't find any other clues.



BTW, linux-2.6.3-pa2 tells

---
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PDC20268: IDE controller at PCI slot 0000:03:02.0
PDC20268: chipset revision 2
PDC20268: ROM enabled at 0xf7004000
PDC20268: 100% native mode on irq 192
    ide0: BM-DMA at 0x3c000-0x3c007, BIOS settings: hda:pio, hdb:pio
    ide1: BM-DMA at 0x3c008-0x3c00f, BIOS settings: hdc:pio, hdd:pio
hda: ST3120022A, ATA DISK drive
---

whereas linux-2.4.25-pa0 said instead

"PDC20268: not 100% native mode: will probe irqs later"

(but the rest is basically the same)


One very interesting thing is that the "hda: lost interrupt" messages
also appeared when I tried the siimage IDE controller on 2.4 kernels!
(see http://www.cs.ucc.ie/~xam/siimage/bootlog-2.4.23-pa3.txt)
Perhaps the siimage problem might be related to this problem?

Any suggestions what could be the problem or how to debug it any further?


Thanks,
  Max


PS: 2.6.3-pa2 boot log can be found here:
http://www.cs.ucc.ie/~xam/promise/bootlog-2.6.3-pa2

Re: [parisc-linux] C3000 and Promise Ultra100 TX2 PCI Controller

[Alan Cox]

On Iau, 2004-02-26 at 00:52, M. Grabert wrote:
> It occurs to me that the driver has some big endian issues (and probably
> some other issues aswell). I've given up hope to get it working after
> I didn't receive any replies from the maintainer, linux-ide or even lkml.

Well as the older maintainer I certainly didnt get anything. The core 
code is known to be good for 64bit and also big endian, the mmio IDE
code is a little less tested so you could try running the 680 in I/O
mapped mode as a first guess. Otherwise it should be clean.

> - I get LOTS of "hda: lost interrupt messages"
> 
> - trying to access the hda is slow or hangs the process trying to access
>   the IDE hard disk (and results in issuing the above mentioned messages)
> 
> - the hard disk is eventually detected correctly on boot up
>   (but it takes long time - minutes - and many "hda: lost interrupt" messages)
> 
> - fdisk shows the correct information about the partitions
> 
> - using "ide=nodma", "hda=nodma" and "nodma" as kernel options doesn't
>   make any difference.

Your IRQ routing is probably wrong. However this is a gotcha with
promise controllers. Some of them require the x86 boot firmware is run
before they operate.

> One very interesting thing is that the "hda: lost interrupt" messages
> also appeared when I tried the siimage IDE controller on 2.4 kernels!
> (see http://www.cs.ucc.ie/~xam/siimage/bootlog-2.4.23-pa3.txt)
> Perhaps the siimage problem might be related to this problem?
> 
> Any suggestions what could be the problem or how to debug it any further?

First stop sounds like figuring out what IRQ routing is being used. In
particular you need to know how legacy mode interrupt mapping is done on
your system and whether it is even wired that way. If its using native
mode you then need to work out why your IRQ is not appearing (or which
IRQ is actually correct).

(IDE chips have two modes - some more but the basic ones are

legacy mode: decodes the traditional PC IDE I/O ports, uses ISA IRQs
which can be fun since motherboard IDE may point them anywhere or not
wire them.

native mode: Uses PCI irq signalling and addressing. Used for plug in
cards but doesn't always work on motherboard devices.
)

Re: [parisc-linux] C3000 and Promise Ultra100 TX2 PCI Controller

[M. Grabert]

On Thu, 26 Feb 2004, Alan Cox wrote:

> On Iau, 2004-02-26 at 00:52, M. Grabert wrote:
> > It occurs to me that the driver has some big endian issues (and probably
> > some other issues aswell). I've given up hope to get it working after
> > I didn't receive any replies from the maintainer, linux-ide or even lkml.
>
> Well as the older maintainer I certainly didnt get anything.

<nickpick>
Well, actually you did ...

http://lists.parisc-linux.org/pipermail/parisc-linux/2003-December/021842.html

... and you were very helpful.

But you were not the maintainer I was refering to. I meant the one
you suggested in the mail mentioned above:

---
Date: Mon, 8 Dec 2003 23:47:13 +0000 (GMT)
From: M. Grabert <xam@cs.ucc.ie>
To: B.Zolnierkiewicz@elka.pw.edu.pl
Cc: linux-ide@vger.kernel.org
Subject: siimage problems on Linux/PA-RISC
---

As I said, I also sent a mail to linux kernel mailing list:
http://www.ussg.iu.edu/hypermail/linux/kernel/0402.2/0011.html

</nickpick>


> The core
> code is known to be good for 64bit and also big endian, the mmio IDE
> code is a little less tested so you could try running the 680 in I/O
> mapped mode as a first guess. Otherwise it should be clean.

I last time I tried was with the 2.4.24-pa0 kernel and with 2.6.3-rc2.

Both show the output
   hda: TS130220A2, ATA DISK drive
instead of
   hda: ST3120022A, ATA DISK drive

That's why I thought it would be related to a big-endian problem.


> Your IRQ routing is probably wrong. However this is a gotcha with
> promise controllers. Some of them require the x86 boot firmware is run
> before they operate.

Yes, that's the case for the FastTrak RAID controllers (and some others).
I found the
  "Special FastTrak feature" option that allows you to detect
the hard drives without the help from the BIOS (AFAIK).

I digged around in the 2.4.25-pa0 kernel sources obviously the option
doesn't apply to the Promise Ultra100 TX2 controllers (no #ifdefs).

And since I've seens reports that some got it working on Linux/PPC
without patching, I think you don't need the ix86 firmware to operate
this particular controller.


> > One very interesting thing is that the "hda: lost interrupt" messages
> > also appeared when I tried the siimage IDE controller on 2.4 kernels!
> > (see http://www.cs.ucc.ie/~xam/siimage/bootlog-2.4.23-pa3.txt)
> > Perhaps the siimage problem might be related to this problem?
> >
> > Any suggestions what could be the problem or how to debug it any further?
>
> First stop sounds like figuring out what IRQ routing is being used. In
> particular you need to know how legacy mode interrupt mapping is done on
> your system and whether it is even wired that way. If its using native
> mode you then need to work out why your IRQ is not appearing (or which
> IRQ is actually correct).

I've put the output of "lspci -vvv", /proc/interrupts and /proc/ioports
here: http://www.cs.ucc.ie/~xam/promise/


> (IDE chips have two modes - some more but the basic ones are
>
> legacy mode: decodes the traditional PC IDE I/O ports, uses ISA IRQs
> which can be fun since motherboard IDE may point them anywhere or not
> wire them.
>
> native mode: Uses PCI irq signalling and addressing. Used for plug in
> cards but doesn't always work on motherboard devices.
> )

I suppose the output I see with 2.6.3-pa2

"PDC20268: ROM enabled at 0xf7004000"
"PDC20268: 100% native mode on irq 192"
"ide0 at 0x3c400-0x3c407,0x3c302 on irq 192"

and the fact, that I can see the partition correctly with fdisk
(albeit very slow) seem to indicate that it is in native mode
rather than legacy mode?

BTW, the controller supports PCI33 and PCI66. I've tried both
(always the same problems), and currently it is in the PCI66 slot.


Thanks alot for the fast reply,
 greetings from Ireland,
   Max

PS: still awake at this time?

Re: [parisc-linux] C3000 and Promise Ultra100 TX2 PCI Controller

[Grant Grundler]

On Thu, Feb 26, 2004 at 05:24:45AM +0000, M. Grabert wrote:
> Maybe I took out too many lines when I responded to my Alan's reply;
> The first part of the mail describes a problem with the siimage driver
> (big-endian problem), the rest of the mail is also about the Promise IDE
> controller I'm currently trying to get working.

ah ok. that makes sense. I probably just read your mail too fast.

> Both the Silicon Image and the Promise IDE controller show the
> "hda: lost interrupt" symptom. However the Promise driver seems to
> me more 'usable' or easily fixable than the siimage driver, since
> it detects the controller and hard disk correctly!

yes - the endian issue is probably harder to fix.

If the Promise interrupt is being delivered on a different interrupt line
than the one advertised (INTERRUPT_PIN), then dumping the state
of the IOSAPIC should show which IRQ input is "high" and we can
figure out where the disconnect is.

But I'm skeptical that's really the issue. I suspect more the IDE command
isn't being programmed properly into the Promise controller and thus it
doesn't DMA correctly or for some other reason complete the command.
ie it has no reason to interrupt.

> The Promise Ultra100 TX2 controller is reported to work on PPC - not the
> siimage one - so there is probably no difference between the PARISC and
> PPC ports in this respect.

ok

grant

> 
> Greetings,
>   Max

Re: [parisc-linux] C3000 and Promise Ultra100 TX2 PCI Controller

[Alan Cox]

On Iau, 2004-02-26 at 15:56, Grant Grundler wrote:
> yes - the endian issue is probably harder to fix.

All mmio and pio goes through helper functions, so it suggests the
helper ifdefs are simply wrong in ide-iops.c - which should make fixing
stuff easier - probably the insw() op is the problem.

> But I'm skeptical that's really the issue. I suspect more the IDE command
> isn't being programmed properly into the Promise controller and thus it
> doesn't DMA correctly or for some other reason complete the command.
> ie it has no reason to interrupt.

Well if the endian stuff is broken then anything could happen

> > The Promise Ultra100 TX2 controller is reported to work on PPC - not the
> > siimage one - so there is probably no difference between the PARISC and
> > PPC ports in this respect.
> 
> ok

siimage should, at least from data sheet review 

Re: [parisc-linux] C3000 and Promise Ultra100 TX2 PCI Controller

[Grant Grundler]

On Fri, Feb 27, 2004 at 06:44:20PM +0000, Alan Cox wrote:
> On Iau, 2004-02-26 at 15:56, Grant Grundler wrote:
> > yes - the endian issue is probably harder to fix.
> 
> All mmio and pio goes through helper functions, so it suggests the
> helper ifdefs are simply wrong in ide-iops.c - which should make fixing
> stuff easier - probably the insw() op is the problem.

Correct. parisc insw/insl/outsw/outsl are all broken.
They all have cpu_to_leXX (or leXX_to_cpu()) calls and the
basic inw/outw are already taking care of the byte swap.
This has been mostly my fault since I originally didn't
know how the byte swapping was supposed to be
handled for a big endian arch.

Anyone interested in deleted all use of the cpu_to_leXX
and leXX_to_cpu in linux-2.6/arch/parisc/lib/io.c?

please post the tested patch here. I'll review and assign
bla^H^H^Hglory to the submitter when I commit it.

BTW, linux-2.4 has the same issue.
I expect the same patch will apply to both if it's
easier to test with linux-2.4.

thanks,
grant

Re: [parisc-linux] C3000 and Promise Ultra100 TX2 PCI Controller

[M. Grabert]

On Fri, 27 Feb 2004, Grant Grundler wrote:

> Anyone interested in deleted all use of the cpu_to_leXX
> and leXX_to_cpu in linux-2.6/arch/parisc/lib/io.c?

What do I have to do?

I assumed that I just have to remove the use of the functions, nothing else.
I've created a modified io.c for 2.4 and for 2.6 (can be found here:
http://www.cs.ucc.ie/~xam/io/ ). I used a CVS version updated a couple
of minutes ago, just after the merge with 2.6.4-rc1.

Was easy to do ... but I haven't tried to compile or run a kernel with the
modifications.

I'll test the the modifications tomorrow morning (in about 10 hours that is),
and will post the results. If successful, I'll also create the neccessary patches.
(btw, is there a special way how I should make the patches?)

> please post the tested patch here. I'll review and assign
> bla^H^H^Hglory to the submitter when I commit it.

;)

> BTW, linux-2.4 has the same issue.
> I expect the same patch will apply to both if it's
> easier to test with linux-2.4.

I'll try with both 2.4.25-pa0 and 2.6.4-rc1-paX and the Promise IDE
controller. Maybe these changes make also DMA work for the internal IDE
of the C3000.

 Max

Re: [parisc-linux] C3000 and Promise Ultra100 TX2 PCI Controller

[M. Grabert]

On Fri, 27 Feb 2004, M. Grabert wrote:

> On Fri, 27 Feb 2004, Grant Grundler wrote:
>
> > Anyone interested in deleted all use of the cpu_to_leXX
> > and leXX_to_cpu in linux-2.6/arch/parisc/lib/io.c?
>
> What do I have to do?
>
> I assumed that I just have to remove the use of the functions, nothing else.
> I've created a modified io.c for 2.4 and for 2.6 (can be found here:
> http://www.cs.ucc.ie/~xam/io/ ). I used a CVS version updated a couple
> of minutes ago, just after the merge with 2.6.4-rc1.

[...]

> I'll test the the modifications tomorrow morning (in about 10 hours that is),

Well, I actually couldn't resist and tried the modifications on a
linux-2.4.25-pa0 kernel (with a hard drive attached to onboard IDE
controller of the C3000).

The 'vanilla' linux-2.4.25-pa0 works, but without DMA.
With the modifications I made, the onboard IDE shows similar big-endian
problems as when using the siimage driver with a unpatched kernel (actually what I
somehow expected).

It really looks as either the Promise and the onboard-IDE have big-endian
issues (which were revealed by these modifications), or the siimage driver
has a big-endian problem.

I will test the Promise card (perhaps even the Silicon Image card), and
the 2.6-kernel tomorrow.

BTW, all my other additional hardware seem to work correctly (second
ethernet network card, a wireless network card, 5-port USB2.0 card).


Thanks,
Greetings from Ireland,
   Max

Re: [parisc-linux] C3000 and Promise Ultra100 TX2 PCI Controller

[Matthew Wilcox]

On Fri, Feb 27, 2004 at 11:50:20PM +0000, M. Grabert wrote:
> I've created a modified io.c for 2.4 and for 2.6 (can be found here:
> http://www.cs.ucc.ie/~xam/io/ ). I used a CVS version updated a couple
> of minutes ago, just after the merge with 2.6.4-rc1.

Erm, sorry, I misled you.  I started the merge, went out for dinner,
came back and finished it off.  Should be good now.

There's typically two messages to the -cvs list (plus all the directory
add mails ...), the first is adding Linus' new tree on a branch, then
the second (which should be in your mailbox by now) is the merge back
to mainline.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

Re: [parisc-linux] C3000 and Promise Ultra100 TX2 PCI Controller

[Alan Cox]

On Sad, 2004-02-28 at 01:05, M. Grabert wrote:
> It really looks as either the Promise and the onboard-IDE have big-endian
> issues (which were revealed by these modifications), or the siimage driver
> has a big-endian problem.

None of the drivers have big endian problems (tested on other archs)

> I will test the Promise card (perhaps even the Silicon Image card), and
> the 2.6-kernel tomorrow.

The SI goes via mmio promise via PIO, so it may be you unfixed the one
that was right ?

Re: [parisc-linux] C3000 and Promise Ultra100 TX2 PCI Controller

[Grant Grundler]

On Sat, Feb 28, 2004 at 04:07:13PM +0000, Alan Cox wrote:
> The SI goes via mmio promise via PIO, so it may be you unfixed the one
> that was right ?

oic.  siimage.c doesn't use the same code path.
I'll guess promise needs the arch/parisc/lib/io.c patch anyway
and something else is wrong with siimage. I'll track that
down later - could be something similar...

drivers/ide/pci/siimage.c:  default_hwif_mmiops(hwif);

ide-iops.c:void default_hwif_mmiops (ide_hwif_t *hwif)
...
        hwif->INSW      = ide_mm_insw;

include/asm-parisc/ide.h:
static __inline__ void __ide_mm_insw(unsigned long port, void *addr, u32 count)
{
        while (count--) {
                *(u16 *)addr = readw(port);
                addr += 2;
        }
}

include/asm/io.h:#define readw(addr) (*(volatile unsigned short *) __io_virt(addr))


Uhoh..no swapping at all in this case.
I was expecting readw to swap bytes.
Am I just confused again about how a BE is supposed to behave?
*sigh*

grant

Re: [parisc-linux] C3000 and Promise Ultra100 TX2 PCI Controller

[James Bottomley]

On Sat, 2004-02-28 at 10:45, Grant Grundler wrote:
> include/asm/io.h:#define readw(addr) (*(volatile unsigned short *) __io_virt(addr))
> 
> 
> Uhoh..no swapping at all in this case.
> I was expecting readw to swap bytes.
> Am I just confused again about how a BE is supposed to behave?
> *sigh*

The rule is supposed to be that inX/outX/readX/writeX be free of
endianness issues on the bus.  i.e. doing a readw() on a memory mapped
PCI config space on parisc should have a le16_to_cpu implied in the
readw().

Obviously, accesses which go straight to memory (i.e. not via accessor
macros) are the responsibility of the driver for sorting out the
endianness.

James

Re: [parisc-linux] C3000 and Promise Ultra100 TX2 PCI Controller

[Matthew Wilcox]

On Sat, Feb 28, 2004 at 09:45:06AM -0700, Grant Grundler wrote:
> include/asm/io.h:#define readw(addr) (*(volatile unsigned short *) __io_virt(addr))
> 
> 
> Uhoh..no swapping at all in this case.
> I was expecting readw to swap bytes.
> Am I just confused again about how a BE is supposed to behave?
> *sigh*

You're confused by looking at the unused definition ;-)

#define readw(addr) le16_to_cpu(__raw_readw(addr))

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

Re: [parisc-linux] C3000 and Promise Ultra100 TX2 PCI Controller

[Grant Grundler]

On Sat, Feb 28, 2004 at 05:41:49PM +0000, Matthew Wilcox wrote:
> > Uhoh..no swapping at all in this case.
> > I was expecting readw to swap bytes.
> > Am I just confused again about how a BE is supposed to behave?
> > *sigh*
> 
> You're confused by looking at the unused definition ;-)

Worse - I was confused by looking at linux-2.6/asm/io.h my laptop. :^(
/me hides

> #define readw(addr) le16_to_cpu(__raw_readw(addr))

yes - so I went on a very short goose chase.
ide_insw_mm stuff should be fine too.

thanks,
grant