problem with pata_hpt37x ...

problem with pata_hpt37x ...

[Herbert Poetzl]

Hi Jeff! Alan!

today I decided to put a (granted somewhat older)
RocketRAID 454 card (hpt374 as it seems) into an
Asus P5B (which already has some controllers using
libata quite happily), and it seems that the driver
support is not perfect yet :)

note: the older hpt366 (ide) driver works quite
fine with the hpt374 controller, even under heavy
load (as I figured an hour ago) and I remembered
that there was some efford to get away from the
'old' ide drivers ...

here are the details:

[    0.000000] Linux version 2.6.19.1 (gcc version 4.1.1 20060724 (prerelease) (4.1.1-3mdk)) #10 SMP Tue Jan 2 15:13:40 CET 2007
[    0.000000] Command line: root=/dev/sda1 panic=20 console=ttyS0,115200n8

[  552.115825] irq 23: nobody cared (try booting with the "irqpoll" option)
[  552.122730] 
[  552.122731] Call Trace:
[  552.126795]  [<ffffffff8026403e>] dump_trace+0xaa/0x403
[  552.132169]  [<ffffffff802643d3>] show_trace+0x3c/0x52
[  552.137488]  [<ffffffff802643fe>] dump_stack+0x15/0x17
[  552.142748]  [<ffffffff802a4ddb>] __report_bad_irq+0x38/0x87
[  552.148589]  [<ffffffff802a4ff3>] note_interrupt+0x1c9/0x20f
[  552.154383]  [<ffffffff802a5868>] handle_fasteoi_irq+0xa7/0xd0
[  552.160321]  [<ffffffff80265cc3>] do_IRQ+0x105/0x158
[  552.165416]  [<ffffffff80258641>] ret_from_intr+0x0/0xa
[  552.170771]  [<ffffffff80263840>] mwait_idle_with_hints+0x48/0x4a
[  552.177035]  [<ffffffff80251ce1>] mwait_idle+0x10/0x25
[  552.182303]  [<ffffffff80244586>] cpu_idle+0x58/0x77
[  552.187433]  [<ffffffff80263079>] rest_init+0x26/0x28
[  552.192640]  [<ffffffff80620725>] start_kernel+0x213/0x215
[  552.198256]  [<ffffffff80620156>] _sinittext+0x156/0x15d
[  552.203730] 
[  552.205263] handlers:
[  552.207611] [<ffffffff803e5469>] (usb_hcd_irq+0x0/0x58)
[  552.213027] [<ffffffff803e5469>] (usb_hcd_irq+0x0/0x58)
[  552.218451] [<ffffffff8803ba13>] (ata_interrupt+0x0/0x1a0 [libata])
[  552.224915] [<ffffffff8803ba13>] (ata_interrupt+0x0/0x1a0 [libata])
[  552.231387] Disabling IRQ #23

after that, the system is basically dead, as the
irq is shared with the USB controller, where it
booted from ...

shufflings cards around (i.e. giving the hpt374 a
separate, non shared IRQ line) doesn't help there,
the result is the same once the devices are accessed
(only IRQ changes from #23 to #21)

if you are interested in investigating this, please
let me know what kind of data you would like to see
and/or what kind of tests would be appreciated.

TIA,
Herbert

Re: problem with pata_hpt37x ...

[Alan]

On Tue, 2 Jan 2007 08:01:45 +0100
Herbert Poetzl <herbert@13thfloor.at> wrote:

> if you are interested in investigating this, please
> let me know what kind of data you would like to see
> and/or what kind of tests would be appreciated.

I reviewed the 374 code a bit further to see what might be causing this
and found the slave channel end of DMA handling was using the wrong port
I think.

Signed-off-by: Alan Cox <alan@redhat.com>

--- linux.vanilla-2.6.20-rc3/drivers/ata/pata_hpt37x.c	2007-01-01 21:43:27.000000000 +0000
+++ linux-2.6.20-rc3/drivers/ata/pata_hpt37x.c	2007-01-02 14:30:18.122801920 +0000
@@ -25,7 +25,7 @@
 #include <linux/libata.h>
 
 #define DRV_NAME	"pata_hpt37x"
-#define DRV_VERSION	"0.5.1"
+#define DRV_VERSION	"0.5.2"
 
 struct hpt_clock {
 	u8	xfer_speed;
@@ -749,7 +749,7 @@
 {
 	struct ata_port *ap = qc->ap;
 	struct pci_dev *pdev = to_pci_dev(ap->host->dev);
-	int mscreg = 0x50 + 2 * ap->port_no;
+	int mscreg = 0x50 + 4 * ap->port_no;
 	u8 bwsr_stat, msc_stat;
 
 	pci_read_config_byte(pdev, 0x6A, &bwsr_stat);

Re: problem with pata_hpt37x ...

[Brad Campbell]

Alan wrote:
> On Tue, 2 Jan 2007 08:01:45 +0100
> Herbert Poetzl <herbert@13thfloor.at> wrote:
> 
>> if you are interested in investigating this, please
>> let me know what kind of data you would like to see
>> and/or what kind of tests would be appreciated.
> 
> I reviewed the 374 code a bit further to see what might be causing this
> and found the slave channel end of DMA handling was using the wrong port
> I think.

This now passes all my stress tests Alan. No more "Interrupt disabled" or dmesg storms.
I put the HPT Rocketraid 1540 (HPT374) back in a box and connected 4 200GB ata drives to it using 
SATA-PATA bridgeboards as before. It looks to be rock solid now.

Brad
-- 
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams

Re: problem with pata_hpt37x ...

[Herbert Poetzl]

On Thu, Jan 04, 2007 at 08:09:56PM +0400, Brad Campbell wrote:
> Alan wrote:
> >On Tue, 2 Jan 2007 08:01:45 +0100
> >Herbert Poetzl <herbert@13thfloor.at> wrote:
> >
> >>if you are interested in investigating this, please
> >>let me know what kind of data you would like to see
> >>and/or what kind of tests would be appreciated.
> >
> >I reviewed the 374 code a bit further to see what might be causing this
> >and found the slave channel end of DMA handling was using the wrong port
> >I think.
> 
> This now passes all my stress tests Alan. No more "Interrupt disabled"
> or dmesg storms. I put the HPT Rocketraid 1540 (HPT374) back in a box
> and connected 4 200GB ata drives to it using SATA-PATA bridgeboards as
> before. It looks to be rock solid now.

sounds great! where can I get that version?
should it be in 2.6.20-rc* or is there a separate
patch available somewhere?

TIA,
Herbert

> Brad
> -- 
> "Human beings, who are almost unique in having the ability
> to learn from the experience of others, are also remarkable
> for their apparent disinclination to do so." -- Douglas Adams

Re: problem with pata_hpt37x ...

[Brad Campbell]

Herbert Poetzl wrote:

> sounds great! where can I get that version?
> should it be in 2.6.20-rc* or is there a separate
> patch available somewhere?

The patch was contained in the message from Alan to you that I replied to. I just applied it to a 
vanilla 2.6.20-rc3 tree and fired it up.

(I've pasted it inline here for you but I'm using thunderbird and it's likely the resulting mess may 
not apply - not hard to manually change the required lines however)

--- linux.vanilla-2.6.20-rc3/drivers/ata/pata_hpt37x.c	2007-01-01 21:43:27.000000000 +0000
+++ linux-2.6.20-rc3/drivers/ata/pata_hpt37x.c	2007-01-02 14:30:18.122801920 +0000
@@ -25,7 +25,7 @@
  #include <linux/libata.h>

  #define DRV_NAME	"pata_hpt37x"
-#define DRV_VERSION	"0.5.1"
+#define DRV_VERSION	"0.5.2"

  struct hpt_clock {
  	u8	xfer_speed;
@@ -749,7 +749,7 @@
  {
  	struct ata_port *ap = qc->ap;
  	struct pci_dev *pdev = to_pci_dev(ap->host->dev);
-	int mscreg = 0x50 + 2 * ap->port_no;
+	int mscreg = 0x50 + 4 * ap->port_no;
  	u8 bwsr_stat, msc_stat;

  	pci_read_config_byte(pdev, 0x6A, &bwsr_stat);




Brad
-- 
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams

Re: problem with pata_hpt37x ...

[Brad Campbell]

Brad Campbell wrote:
> Herbert Poetzl wrote:
> 
>> sounds great! where can I get that version?
>> should it be in 2.6.20-rc* or is there a separate
>> patch available somewhere?
> 
> The patch was contained in the message from Alan to you that I replied 
> to. I just applied it to a vanilla 2.6.20-rc3 tree and fired it up.
> 

Just a warning. I'm seeing data corruption on this system. I need to try and narrow it down, but on 
transferring 100 files totalling about 80GB from a USB drive to the drives on this controller I'm 
seeing repeatable and apparently random corruption on the data reaching the disks. I don't recall 
seeing this when I used SIL controllers in place of the HPT but I now have an easily repeatable test 
case so I'll keep testing until I peg it.


Brad
-- 
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams