* problem with pata_hpt37x ...
@ 2007-01-02 7:01 Herbert Poetzl
2007-01-02 14:58 ` Alan
0 siblings, 1 reply; 6+ messages in thread
From: Herbert Poetzl @ 2007-01-02 7:01 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-ide, Alan Cox, Linux Kernel ML
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: problem with pata_hpt37x ...
2007-01-02 7:01 problem with pata_hpt37x Herbert Poetzl
@ 2007-01-02 14:58 ` Alan
2007-01-04 16:09 ` Brad Campbell
0 siblings, 1 reply; 6+ messages in thread
From: Alan @ 2007-01-02 14:58 UTC (permalink / raw)
To: Herbert Poetzl; +Cc: Jeff Garzik, linux-ide, Linux Kernel ML
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);
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: problem with pata_hpt37x ...
2007-01-02 14:58 ` Alan
@ 2007-01-04 16:09 ` Brad Campbell
2007-01-04 17:30 ` Herbert Poetzl
0 siblings, 1 reply; 6+ messages in thread
From: Brad Campbell @ 2007-01-04 16:09 UTC (permalink / raw)
To: Alan; +Cc: Herbert Poetzl, Jeff Garzik, linux-ide, Linux Kernel ML
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: problem with pata_hpt37x ...
2007-01-04 16:09 ` Brad Campbell
@ 2007-01-04 17:30 ` Herbert Poetzl
2007-01-04 18:08 ` Brad Campbell
0 siblings, 1 reply; 6+ messages in thread
From: Herbert Poetzl @ 2007-01-04 17:30 UTC (permalink / raw)
To: Brad Campbell; +Cc: Alan, Jeff Garzik, linux-ide, Linux Kernel ML
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: problem with pata_hpt37x ...
2007-01-04 17:30 ` Herbert Poetzl
@ 2007-01-04 18:08 ` Brad Campbell
2007-01-06 9:06 ` Brad Campbell
0 siblings, 1 reply; 6+ messages in thread
From: Brad Campbell @ 2007-01-04 18:08 UTC (permalink / raw)
To: Brad Campbell, Alan, Jeff Garzik, linux-ide, Linux Kernel ML
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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: problem with pata_hpt37x ...
2007-01-04 18:08 ` Brad Campbell
@ 2007-01-06 9:06 ` Brad Campbell
0 siblings, 0 replies; 6+ messages in thread
From: Brad Campbell @ 2007-01-06 9:06 UTC (permalink / raw)
To: Brad Campbell; +Cc: Alan, Jeff Garzik, linux-ide, Linux Kernel ML
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2007-01-06 9:06 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-01-02 7:01 problem with pata_hpt37x Herbert Poetzl
2007-01-02 14:58 ` Alan
2007-01-04 16:09 ` Brad Campbell
2007-01-04 17:30 ` Herbert Poetzl
2007-01-04 18:08 ` Brad Campbell
2007-01-06 9:06 ` Brad Campbell
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).