Re: IRQ disabled (SATA) on NForce2 and my theory

[Bob <recbo@nishanet.com>]

sii chips have a long history of needing to
hdparm off the unmask interrupt feature.

I don't know about that chip but for
sii680 there is a special option "-p9"
for hdparm which is to say pio mode 9
is a special instruction in addition to
standard hdparm opt "-u0" turning off
irq unmask.

/sbin/hdparm -d1 -c1 -p9 -X70 -u0 -k0 -i $a

also the sii sata chips can have the kernel config
low-level scsi driver CONFIG_SCSI_SATA=y
which you should read about in this list archive.
I don't personally know about that.

-Bob

Julien Oster wrote:

>Hello!
>
>I got an ASUS A7N8X Deluxe v2.0 and APIC and I/O APIC enabled, thanks
>to athcool. (I didn't apply any patches, I just disable CPU Disconnect
>with 'athcool off' as first thing on boot).
>
>Now, however, since I am running with APIC, the following error occurs
>quite often:
>
>[...]
>Dec  8 19:16:20 frodo kernel: hde: DMA disabled
>Dec  8 19:16:20 frodo kernel: ide2: reset phy, status=0x00000113, siimage_reset
>[...]
>
>Shortly after that, the kernel would report:
>
>Dec  8 19:16:21 frodo kernel: Disabling IRQ #18
>Dec  8 19:16:22 frodo kernel: irq 18: nobody cared!
>
>This happens sometimes under very high load on my onboard SATA where
>both harddrivers (fast 10000rpm Raptors) are attached to a Linux
>Softraid RAID0. IRQ18 is attached to this.
>
>The drive/controller won't recover afterwards, only a reboot helps.
>
>Now, my theory about this: One patch to fix the NForce2 lockups was to
>insert a small delay in the acknowledgement of the timer
>interrupt. Apparently, the machine would lock up if the timer
>interrupt gets acknowledged too fast, meaning too soon.
>
>I now suspect that my IRQ18 problems are a result of exactly the same
>cause: IRQ18 getting acknowledged too soon on very high load, thus all
>further interrupts won't occur anymore and disk operations come to a
>halt.
>
>It was most noticeable for the timer interrupt, because the timer
>interrupt is basically always at "high load" and a lack of it would
>result in a hard lockup of the board. However, it now seems like the
>timer interrupt isn't the only interrupt suffering from this issue.
>
>So, I think inserting the small delay in the appropriate IRQ
>handler might fix this, too.
>
>But there's still the question, why the delay is actually needed for
>NForce2 boards. That would basically mean that you'll have to
>introduce the delay for *every* IRQ, to avoid a lockup of any device
>that will do high load at some time. I bet that, if I put my Firewire
>Card back in (or just use the onboard Firewire ports) and stream a
>video from my DV cam onto the harddisk, it would lock up as well after
>a very short time, since those who know DV also know that DV has a
>very high bandwidth, half an hour of film is like 40GB or the
>like. (However, I can't test this right now, because my DV cam is
>currently not accessible)
>
>So, we're still not "rock solid" with NForce2, I guess...
>Any idea?
>
>Regards,
>Julien
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>
>  
>