drive appears confused; hda lost interrupt; IRQ169: nobody cared

drive appears confused; hda lost interrupt; IRQ169: nobody cared

[Michael Schmitt]

Hi folks,

I have some major or at least annoying issues with a Asus P4P800-SE
mainboard. It has 2 pATA connectors (so 4 drives) and 2 sATA connectors.
In addition I plugged in another sATA controller too (to isolate
problems with the mainboard chipset more easily) with two sATA
connectors. All together 4 pATA drives and 4 sATA drives possible.
I changed the mainboard of this computer recently to this P4P800-SE from
a rubish oem SIS chipset board and I had the problems right away,
starting with kernel 2.6.18 but problems persist even with 2.6.23
(Debian kernels).

In the BIOS of the mainboard I can set the IDE operations to be
"native" (it says enhanced) or "not native" (it says compatible there)
which means in compatible mode I can choose between just pATA or two
pATA drives and 2 sATA drives, with enhanced I could use all.

Now the problems, I try to collect every information I am able to, but
please don't hesitate to ask if I missed something!

2.6.18; no kernel cmdline additions >
	irq 169: nobody cared (try booting with the "irqpoll" option)
Some data containing a stack trace (just made a photo) and after that
	Disabling IRQ 169
	hda: dma_timer_expiry: dma status == 0x24
	hda: DMA interrupt recovery
	hda: lost interrupt
	hda: dma_timer_expiry: dma status == 0x24
	[...]
I did hit the reset button at this stage, now booting 2.6.18 with
"irqpoll" option. The system boots up, apart from some errors in the log
(and again the hint to use irqpoll even if I did it already) I can use
the system nevertheless. See the file kern.log-2.6.18-irqpoll. hdc drive
appears confused, IRQ 169: nobody cared... but I can log in, read from
all disks / dvd drive, even burn a cd and I don't notice _any_ serious
problem during operation... just the log files make my head ache. There
is only one thing that does not work anymore, which maks be believe it
may be a hal / dbus issue. Normally I think gnome should ask me when I
insert a blank cd if I want to burn a cd. During my tests it does it not
anymore but burning itself works flawlessly. I just get every once in a
while this:
Dec 21 11:17:48 elara kernel: hdc: cdrom_pc_intr: The drive appears
confused (ireason = 0x01). Trying to recover by ending request.
Dec 21 11:23:28 elara kernel: hdc: cdrom_pc_intr: The drive appears
confused (ireason = 0x01). Trying to recover by ending request.
Dec 21 11:31:22 elara kernel: hdc: cdrom_pc_intr: The drive appears
confused (ireason = 0x01). Trying to recover by ending request.
Dec 21 11:33:26 elara kernel: hdc: cdrom_pc_intr: The drive appears
confused (ireason = 0x01). Trying to recover by ending request.
Dec 21 11:44:02 elara kernel: hdc: cdrom_pc_intr: The drive appears
confused (ireason = 0x01). Trying to recover by ending request.

On IRQ 169 seems to be the internal IDE controller but as said all
drives work, despite

mschmitt@elara:~$ dmesg |grep 169
irq 169: nobody cared (try booting with the "irqpoll" option)
Disabling IRQ #169
ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 169
uhci_hcd 0000:00:1d.2: irq 169, io base 0x0000ef20
ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 18 (level, low) -> IRQ 169
ata3: SATA max UDMA/133 cmd 0xEFA0 ctl 0xEF8E bmdma 0xEF60 irq 169
ata4: SATA max UDMA/133 cmd 0xEF80 ctl 0xEF8A bmdma 0xEF68 irq 169
mschmitt@elara:~$ 

As I watch /proc/interrupts I see that IRQ 169 does not change, as there
would be no interrupt requests and just to make it clear

169:     200116   IO-APIC-level  ide0, ide1, uhci_hcd:usb3, libata

rather busy interrupt but no real problems with ide0 (hda), ide1 (hdc)
and libata (in this case sdc, sda and sdb are on the PCI sATA controller
which is on IRQ 209). With "busy" I mean many devices on that IRQ but
the value "200116" stays forever.
With 2.6.23 it is more or less the same if you want I can provide you
with the same information for this kernel nevertheless. As a side note,
if I plug in another DVD drive (due to cableing issues hdc would become
hdd and hdc would be the new drive) I get those "drive appears confused"
messages for both optical drives but reading / burning no problem there
too, despite that the performance with slave / master sucks when both
drives are used at the same time.
So, my main concern is that there may be some sort of data corruption
even if I don't see them right now but as the messages seem to be very
serious... dunno. Any thoughts?

kind regards
Michael Schmitt

Re: drive appears confused; hda lost interrupt; IRQ169: nobody cared

[Alan Cox]

> I changed the mainboard of this computer recently to this P4P800-SE from
> a rubish oem SIS chipset board and I had the problems right away,
> starting with kernel 2.6.18 but problems persist even with 2.6.23
> (Debian kernels).

Your IRQ routing appears broken. That is usually a BIOS problem.

> So, my main concern is that there may be some sort of data corruption
> even if I don't see them right now but as the messages seem to be very
> serious... dunno. Any thoughts?

Check for BIOS uupdates also try playing with the various pci irq
routing, APIC and acpi options. 

Alan

Re: drive appears confused; hda lost interrupt; IRQ169: nobody cared

[Michael Schmitt]

Hi Alan

thanks for the input! This BIOS seems to be current, there are just two
beta BIOS available and as in the changelog there is nothing IRQ related
written (there is almost nothing in it) I don't think I want to flash
one of them, but here are the various options I tried:

noapic > the one and the same thing, but this time (as classic PIC is
used) nobody cared about IRQ 11.

acpi=noirq > the same, this time IRQ 185

pci=routeirq > the same as right above

pci=nobios > without irqpoll hda DMA expire, IRQ lost, with irqpoll IRQ
169 again

pci=noacpi > the same as two and three above

irqfixup (instead of irqpoll) > hda DMA timer expire, IRQ lost

I may have missed some options to try out, do you suggest some else?
I've read kernel-parameters.txt and tried to find reasonable options...
But what I don't get... how tragic are those "irq N nobody cared" and
"drive appears confused" messages as I don't see a negative impact? And
at the end, what do they mean? If an IRQ is disabled I thought the
device behind it would not work anymore... but...
Maybe I will give the two beta BIOS a try nevertheless.

greetings
Michael

Am Freitag, den 21.12.2007, 13:18 +0000 schrieb Alan Cox: 
> > I changed the mainboard of this computer recently to this P4P800-SE from
> > a rubish oem SIS chipset board and I had the problems right away,
> > starting with kernel 2.6.18 but problems persist even with 2.6.23
> > (Debian kernels).
> 
> Your IRQ routing appears broken. That is usually a BIOS problem.
> 
> > So, my main concern is that there may be some sort of data corruption
> > even if I don't see them right now but as the messages seem to be very
> > serious... dunno. Any thoughts?
> 
> Check for BIOS uupdates also try playing with the various pci irq
> routing, APIC and acpi options. 
> 
> Alan

Re: drive appears confused; hda lost interrupt; IRQ169: nobody cared

[Len Brown]

> thanks for the input! This BIOS seems to be current, there are just two
> beta BIOS available and as in the changelog there is nothing IRQ related
> written (there is almost nothing in it) I don't think I want to flash
> one of them, but here are the various options I tried:
> 
> noapic > the one and the same thing, but this time (as classic PIC is
> used) nobody cared about IRQ 11.
> 
> acpi=noirq > the same, this time IRQ 185
> 
> pci=routeirq > the same as right above
> 
> pci=nobios > without irqpoll hda DMA expire, IRQ lost, with irqpoll IRQ
> 169 again
> 
> pci=noacpi > the same as two and three above
> 
> irqfixup (instead of irqpoll) > hda DMA timer expire, IRQ lost
> 
> I may have missed some options to try out, do you suggest some else?
> I've read kernel-parameters.txt and tried to find reasonable options...
> But what I don't get... how tragic are those "irq N nobody cared" and
> "drive appears confused" messages as I don't see a negative impact? And
> at the end, what do they mean? If an IRQ is disabled I thought the
> device behind it would not work anymore... but...
> Maybe I will give the two beta BIOS a try nevertheless.

Start by running a recent kernel, such as 2.6.25 or 2.6.26-rc.

when we hit the "nobody cared", we basically mask that IRQ forever.
If any devices on that IRQ needs interrupts, that would starve them
to death from that moment forward (unless you boot with irqpoll)

The fact that (at least some of) the devices on the disabled IRQ
still work means that they're secretly getting
an IRQ from someplace else, and you should be able to find
that place by watching /proc/interrupts.

-Len