Lost Interrupt

Lost Interrupt

[SoloCDM]

The present system has operated without any changes to the hardware
with Win9.x, RH5.2, and LM7.0.  This problem only started when I
upgraded to LM8.0 and still no hardware changes have been made.

I use the 420Mb drive as a swap disk, connected along with the
CD-ROM to the secondary port.  I can't bring myself to throw the
420Mb drive out.

The following errors occur during boot-up:

Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
VP_IDE: VIA vt82c586a (rev 27) IDE UDMA33 controller on pci00:07.1
    ide0: BM-DMA at 0x6000-0x6007, BIOS settings: hda:pio, hdb:pio
    ide1: BM-DMA at 0x6008-0x600f, BIOS settings: hdc:pio, hdd:pio
ide6: Creative SB32 PnP IDE interface
hdb: WDC AC33100H, ATA DISK drive
hdc: Conner Peripherals 420MB - CFS420A, ATA DISK drive
hdc: IRQ probe failed (0xfffffff8)
hdd: CD-ROM 32X/AKU, ATAPI CD/DVD-ROM drive
hdd: IRQ probe failed (0xfffffff8)
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
ide1 at 0x170-0x177,0x376 on irq 15
hda: 16408224 sectors (8401 MB) w/256KiB Cache, CHS=1021/255/63,
UDMA(33)
hdb: 6185088 sectors (3167 MB) w/128KiB Cache, CHS=767/128/63, DMA
hdc: 832608 sectors (426 MB) w/64KiB Cache, CHS=826/16/63, DMA
hdd: lost interrupt
hdd: lost interrupt
hdd: lost interrupt
hdd: lost interrupt
hdd: lost interrupt
hdd: ATAPI 32X CD-ROM drive, 128kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.12
Partition check:
hda: hda1 hda2 < hda5 hda6 hda7 >
hdb: hdb1 hdb2
hdc:hdc: lost interrupt
hdc: lost interrupt
hdc: lost interrupt
hdc: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hdc: irq timeout: status=0x50 { DriveReady SeekComplete }
hdc: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hdc: irq timeout: status=0x50 { DriveReady SeekComplete }
hdc: lost interrupt
hdc: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hdc: irq timeout: status=0x50 { DriveReady SeekComplete }
hdc: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hdc: irq timeout: status=0x50 { DriveReady SeekComplete }
hdc: DMA disabled
hdd: DMA disabled
ide1: reset: success
hdc: lost interrupt
hdc: lost interrupt
hdc: lost interrupt
hdc: lost interrupt
hdc1 hdc2 <hdc: lost interrupt
hdc: lost interrupt
hdc5 >
hdc: lost interrupt
hdc: lost interrupt

Why does this happen and how can it be resolved?

Note: When you reply to this message, please include the mailing
      list/newsgroup address and my email address in To:.

*********************************************************************
Signed,
SoloCDM

lost interrupt

[mikeH]

Sorry if this is a repeat, I didn't see my last post come through...

I'm being plauged with "hdX: lost interrupt" messages and resultant 
system hangs in kernel 2.4.18 on a via 82XXXX chipset.

Who should I direct my questions to?

Thanks in advance,

MikeH

Re: lost interrupt

[Tomasz Rola]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 7 May 2002, mikeH wrote:

> Sorry if this is a repeat, I didn't see my last post come through...
> 
> I'm being plauged with "hdX: lost interrupt" messages and resultant 
> system hangs in kernel 2.4.18 on a via 82XXXX chipset.

I may not be the right person to answer but I had same problem (same via,
same kernel, same interrupt). It helped when I turned unmasking off, i.e.
try:

hdparm -u0 /dev/hdX  for every X in existing disks you have problems with.

Actually I did some dirty trick too, cause I have UDMA enabled by default
and compiled in via specific settings in kernel config, while at the same
time I set dma off during init, so I do:

hdparm -d0a0u0 /dev/ide/host0/bus0/target0/lun0/disc (or /dev/hda).

I think -u0 is sufficient but you may try the other command too. My
current dirty tricks are overreaction to problems with UDMA few kernels
(and years) ago so the second command is for paranoids.

bye
T.

- --
** A C programmer asked whether computer had Buddha's nature.      **
** As the answer, master did "rm -rif" on the programmer's home    **
** directory. And then the C programmer became enlightened...      **
**                                                                 **
** Tomasz Rola          mailto:tomasz_rola@bigfoot.com             **

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv

iQA/AwUBPNiPKBETUsyL9vbiEQJ/uACgxwcY2jRlPKt2aBaTd4BzwAIAPoAAoK7g
wYcFIwJZX+cfwmFopa5JHKA5
=hyqY
-----END PGP SIGNATURE-----

Re: lost interrupt

[mikeH]

Tomasz Rola wrote:

>hdparm -u0 /dev/hdX  for every X in existing disks you have problems with.
>  
>
>
>hdparm -d0a0u0 /dev/ide/host0/bus0/target0/lun0/disc (or /dev/hda).
>
>bye
>T.
>
>  
>
Thanks, I tried that but to no avail :(

To expand on the problem :

I have a creative DVD 5x drive and some unbranded CD-RW drive. The 
problem occurs on both when I try to rip audio.

I know for a fact they both have the capability to rip audio nicely, I 
have seen them do it under a 2.2.X kernel, but now I'm running 2.4.18 (I 
need 2.4 for my nvidia card)

However, hdparm returns this (on both drives, no matter what 
slave/master dma/irq combo I use)...

 HDIO_GET_MULTCOUNT failed: Invalid argument
 I/O support  =  0 (default 16-bit)
 unmaskirq    =  0 (off)
 using_dma    =  0 (off)
 keepsettings =  0 (off)
 HDIO_GET_NOWERR failed: Invalid argument
 readonly     =  1 (on)
 readahead    =  0 (off)
 HDIO_GETGEO failed: Invalid argument
 busstate     =  1 (on)
 HDIO_GET_ACOUSTIC failed: Invalid argument

See the worrying "HDIO_GET_ACOUSTIC failed: Invalid argument" ?

I'm not sure who is maintaining that part of the kernel though.

Thanks for any help,

mikeH

Re: lost interrupt

[Padraig Brady]

mikeH wrote:
> Sorry if this is a repeat, I didn't see my last post come through...
> 
> I'm being plauged with "hdX: lost interrupt" messages and resultant 
> system hangs in kernel 2.4.18 on a via 82XXXX chipset.

I'm getting the same thing (very rarely) with a BX chipset
and 2.4.16. What CPU are you using? What type of disk is the hdX?

Padraig.

Re: lost interrupt

[Mike]

Its an AMD Duron 1.2ghz, the hdX is either my creative DVD 5x or my cd-rw 
(unbranded)

mike

On Wednesday 08 May 2002 12:45 pm, Padraig Brady wrote:
> mikeH wrote:
> > Sorry if this is a repeat, I didn't see my last post come through...
> >
> > I'm being plauged with "hdX: lost interrupt" messages and resultant
> > system hangs in kernel 2.4.18 on a via 82XXXX chipset.
>
> I'm getting the same thing (very rarely) with a BX chipset
> and 2.4.16. What CPU are you using? What type of disk is the hdX?
>
> Padraig.
>
> -
> 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/

Re: lost interrupt

[Padraig Brady]

Tomasz Rola wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Tue, 7 May 2002, mikeH wrote:
> 
> 
>>Sorry if this is a repeat, I didn't see my last post come through...
>>
>>I'm being plauged with "hdX: lost interrupt" messages and resultant 
>>system hangs in kernel 2.4.18 on a via 82XXXX chipset.
> 
> 
> I may not be the right person to answer but I had same problem (same via,
> same kernel, same interrupt). It helped when I turned unmasking off, i.e.
> try:
> 
> hdparm -u0 /dev/hdX  for every X in existing disks you have problems with.
> 

unmasking is already off on my drive

Padraig.

Re: lost interrupt

[Tomasz Rola]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 8 May 2002, Padraig Brady wrote:

> Tomasz Rola wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > On Tue, 7 May 2002, mikeH wrote:
> > 
> > 
> >>Sorry if this is a repeat, I didn't see my last post come through...
> >>
> >>I'm being plauged with "hdX: lost interrupt" messages and resultant 
> >>system hangs in kernel 2.4.18 on a via 82XXXX chipset.
> > 
> > 
> > I may not be the right person to answer but I had same problem (same via,
> > same kernel, same interrupt). It helped when I turned unmasking off, i.e.
> > try:
> > 
> > hdparm -u0 /dev/hdX  for every X in existing disks you have problems with.
> > 
> 
> unmasking is already off on my drive

My so called competence ends here...

bye
T.

- --
** A C programmer asked whether computer had Buddha's nature.      **
** As the answer, master did "rm -rif" on the programmer's home    **
** directory. And then the C programmer became enlightened...      **
**                                                                 **
** Tomasz Rola          mailto:tomasz_rola@bigfoot.com             **


-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv

iQA/AwUBPNlufBETUsyL9vbiEQJeSQCeJSy+osD5VoiC7ykENLB1vfxfFmAAnicQ
Ztwl52/RkGXuXej5rCvrNlEV
=cfx4
-----END PGP SIGNATURE-----

Lost Interrupt

[David Gironella Casademont]

I compile 2.4.18 kernel with promise raid support, and when kernel is
checking my partitions say: Lost interrupt

any idea.

thk
Giro

Re: Lost Interrupt

[Samuel Flory]

  Try Alan's ac kernel for the promise controllers.  It seems to work
for most people.
ftp://ftp.us.kernel.org/pub/kernel/linux/kernel/people/alan/linux-2.4/2.4.19/


PS- You will need to patch 2.4.19-rc1 1st.
ftp://ftp.us.kernel.org/pub/kernel/linux/kernel/v2.4/testing/

cd (kernel source for 2.4.18)
bzcat |patch-2.4.19-rc1.bz2 |patch -p 1
bzcat |patch-2.4.19-rc1-ac4.bz2 |patch -p 1

On Tue, 2002-07-16 at 07:58, David Gironella Casademont wrote:
> 
> I compile 2.4.18 kernel with promise raid support, and when kernel is
> checking my partitions say: Lost interrupt
> 
> any idea.
> 
> thk
> Giro
> 
> -
> 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/
> 

lost interrupt

[Trevor Woerner]

I'm getting the dreaded "lost interrupt" whenever the kernel tries to
access my onboard CF card. I put an 'IDE_DEBUG' at the start of
'ide_intr()' so I could watch to see if/how many times my interrupt
occurs or gets called. As an example, after I run 'cardmgr' I'll get
7 'lost interrupt' messages. After the last one, I'll get 7
'IDE_DEBUG' messages indicating that there were 7 interrupts queued
and waiting on the correct interrupt line.

So if 7 interrupts are sitting there waiting on the correct line, why
can't they get into the kernel so it can know the CF card is ready,
instead of having to wait for each IDE operation to timeout? From
googling around the usual cause of 'lost interrupt' is setting the irq
incorrectly, but the fact that all 7 get delivered (eventually) to the
ide's 'ide_intr()' would seem to indicate that at least that part is
configured correctly, no?

[relevant info]
kernel: 2.4.20-rc1
interrupt: external #6 (known as 31 internally), shared
cpu: PPC405gp

in 'ide-cs.c' i call 'ide_setup_ports()' to configure the device and I
define an 'ack_intr()' in order to acknowledge and turn off the
shared interrupt. The interrupt is shared, but not with other IDE
hwif's. I'm not using DMA, chipset is 'ide_generic'. This is not a
PCI device.

How do 'ide_ack_intr()' and 'hwif->intrproc()' differ? I've only setup
'ide_ack_intr()', it appears to return a 1 if it determines the
shared interrupt source was the IDE, or 0 if it wasn't. I also use
this place to put the code to reset (or turn off) the interrupt. What
would 'intrproc()' do?

	Trevor

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: lost interrupt

[Trevor Woerner]

On May 26, 2003 11:41 pm, Trevor Woerner wrote:
> I'm getting the dreaded "lost interrupt" whenever the kernel tries to
> access my onboard CF card.

It gets a bit stranger, but I think I'm onto something. I'll try to
confirm this in the next day or so, but it appears on the surface that
my device doesn't give an interrupt between the transfer of each
segment in a multi-segment transaction.

I enabled the debug statements in 'ide-disk.c' and what I found is that
sometimes I receive interrupts and Linux is happy, and other times I
don't. After thinking about it a little bit I believe the times I got
interrupts were when single segments at a time were being read (ATA
command 0x20) and when I didn't get interrupts were when multi-segment
reads (still command 0x20 but with number of sectors > 1) were
performed.

	Trevor

kernel: 2.4.20-rc1
cpu: PPC405gp
device: SanDisk 16MB CF

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/