Subject: IRQ problem on cobalt / 2.6.6

From: [email-masked] (Kieran Fulke)
Date: Thu, 13 May 2004 19:30:59 +0100

hi folks, 

getting the below when loading the dvb budget_ci module. it disables IRQ 
#23 which is attached to the card, rendering it useless. i asked the 
same question over there and none of them suspect it to be a DVB 
problem. some esoteric pci bug perhaps?

lspci -vv
0000:00:0a.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 
01)
        Subsystem: Technotrend Systemtechnik GmbH: Unknown device 1011
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 64 (3750ns min, 9500ns max)
        Interrupt: pin A routed to IRQ 23
        Region 0: Memory at 12080800 (32-bit, non-prefetchable)

cat /proc/interrupts
           CPU0
  2:          0          XT-PIC  cascade
 14:     321895          XT-PIC  ide0
 18:   82942617            MIPS  timer
 19:     131702            MIPS  eth0
 21:        345            MIPS  serial
 22:          0            MIPS  cascade
 23:     100002            MIPS  saa7146 (0)

ERR:          0

 dmesg | ksymoops
ksymoops 2.4.9 on mips 2.6.6-mipscvs-20040510.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.6.6-mipscvs-20040510/ (default)
     -m /usr/src/linux/System.map (default)

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc.  ksymoops -h explains the options.

Error (regular_file): read_ksyms stat /proc/ksyms failed
ksymoops: No such file or directory
No modules in ksyms, skipping objects
No ksyms, skipping lsmod
Call Trace: [<80084624>]  [<8008461c>]  [<80084720>]  [<800b179c>]  
[<800b1788>]  [<80084a78>]  [<800b1af8>]  [<800826d0>]  [<800ac718>]  
[<80082ec0>]  [<801593c0>]  [<800ac7f4>]  [<80084b18>]  [<800ac6f8>]  
[<80084578>]  [<80084578>]  [<800ac7f4>]  [<80084b18>]  [<80082ec0>]  
[<800826d0>]  [<80082ec0>]  [<801594a4>]  [<801593c0>]  [<80085468>]  
[<80085480>]  [<8019c624>]  [<8019c610>]  [<c001b570>]  [<80084bec>]  
[<8015bff8>]  [<800ce3ec>]  [<800ce3ec>]  [<c001bc24>]  [<80126eb8>]  
[<8015d338>]  [<c001b544>]  [<801780e0>]  [<8015d3a0>]  [<8015d7b4>]  
[<8015d408>]  [<80153bf4>]  [<80178eb0>]  [<80154140>]  [<80154018>]  
[<80154258>]  [<80178fec>]  [<80179284>]  [<80179608>]  [<800a83e4>]  
[<800a8264>]  [<8015d684>]  [<800a81d4>]  [<c001c298>]  [<c001c288>]  
[<c002a020>]  [<800c2b98>]  [<800c2b40>]  [<800e7ef0>]  [<8008be88>]
[<c001b570>]
Warning (Oops_read): Code line not seen, dumping what data is available

Trace; 80084624 <__report_bad_irq+48/8c>
Trace; 8008461c <__report_bad_irq+40/8c>
Trace; 80084720 <note_interrupt+88/d0>
Trace; 800b179c <update_process_times+40/54>
Trace; 800b1788 <update_process_times+2c/54>
Trace; 80084a78 <do_IRQ+110/1dc>
Trace; 800b1af8 <do_timer+78/144>
Trace; 800826d0 <cobalt_irq+150/180>
Trace; 800ac718 <__do_softirq+68/ec>
Trace; 80082ec0 <ret_from_exception+0/0>
Trace; 801593c0 <memset+0/1c>
Trace; 800ac7f4 <do_softirq+58/8c>
Trace; 80084b18 <do_IRQ+1b0/1dc>
Trace; 800ac6f8 <__do_softirq+48/ec>
Trace; 80084578 <handle_IRQ_event+6c/d0>
Trace; 80084578 <handle_IRQ_event+6c/d0>
Trace; 800ac7f4 <do_softirq+58/8c>
Trace; 80084b18 <do_IRQ+1b0/1dc>
Trace; 80082ec0 <ret_from_exception+0/0>
Trace; 800826d0 <cobalt_irq+150/180>
Trace; 80082ec0 <ret_from_exception+0/0>
Trace; 801594a4 <memset_partial+48/6c>
Trace; 801593c0 <memset+0/1c>
Trace; 80085468 <setup_irq+134/1b0>
Trace; 80085480 <setup_irq+14c/1b0>
Trace; 8019c624 <pcibios_set_master+8c/9c>
Trace; 8019c610 <pcibios_set_master+78/9c>
Trace; c001b570 <__crc_bio_map_user+64b64/130ac7>
Trace; 80084bec <request_irq+a8/e4>
Trace; 8015bff8 <pci_set_master+54/64>
Trace; 800ce3ec <kmem_cache_alloc+0/98>
Trace; 800ce3ec <kmem_cache_alloc+0/98>
Trace; c001bc24 <__crc_bio_map_user+65218/130ac7>
Trace; 80126eb8 <sysfs_create+7c/d0>
Trace; 8015d338 <pci_device_probe_static+50/80>
Trace; c001b544 <__crc_bio_map_user+64b38/130ac7>
Trace; 801780e0 <get_device+20/34>
Trace; 8015d3a0 <__pci_device_probe+38/70>
Trace; 8015d7b4 <pci_dev_get+20/38>
Trace; 8015d408 <pci_device_probe+30/5c>
Trace; 80153bf4 <create_dir+3c/68>
Trace; 80178eb0 <bus_match+4c/84>
Trace; 80154140 <kobject_add+9c/fc>
Trace; 80154018 <kobject_init+3c/5c>
Trace; 80154258 <kobject_set_name+50/104>
Trace; 80178fec <driver_attach+50/9c>
Trace; 80179284 <bus_add_driver+84/b0>
Trace; 80179608 <driver_register+34/40>
Trace; 800a83e4 <printk+210/280>
Trace; 800a8264 <printk+90/280>
Trace; 8015d684 <pci_register_driver+70/a0>
Trace; 800a81d4 <printk+0/280>
Trace; c001c298 <__crc_bio_map_user+6588c/130ac7>
Trace; c001c288 <__crc_bio_map_user+6587c/130ac7>
Trace; c002a020 <__crc_bio_map_user+73614/130ac7>
Trace; 800c2b98 <sys_init_module+2bc/4f0>
Trace; 800c2b40 <sys_init_module+264/4f0>
Trace; 800e7ef0 <sys_close+d4/120>
Trace; 8008be88 <stack_done+24/40>
Trace; c001b570 <__crc_bio_map_user+64b64/130ac7>

2 warnings and 1 error issued.  Results may not be reliable.

cheers,
Kieran.

---

From: Peter Horton <[email-masked]>
Date: Fri, 14 May 2004 08:43:44 +0100

>problem. some esoteric pci bug perhaps?
Have you tried any other hardware in the slot, PCI network card perhaps ?

P.

---

From: [email-masked] (Kieran Fulke)
Date: Sun, 16 May 2004 12:36:22 +0100

> Have you tried any other hardware in the slot, PCI network card perhaps ?

yeah. adding cards like a tulip network card, linksys wmp11 wireless card. even a 
wintv pci (analogue) card all work ;

0000:00:0a.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 
(rev 41)
        Subsystem: Kingston Technologies: Unknown device 0001
        Flags: bus master, medium devsel, latency 64, IRQ 23
        I/O ports at 1080 [size=288M]
        Memory at 120c0400 (32-bit, non-prefetchable) [size=1K]
        Expansion ROM at 00040000 [disabled]

cat /proc/interrupts
           CPU0
  2:          0          XT-PIC  cascade
 14:      27636          XT-PIC  ide0
 18:     435142            MIPS  timer
 19:        696            MIPS  eth0
 20:          7            MIPS  eth2
 21:        302            MIPS  serial
 22:          0            MIPS  cascade
 23:     100002            MIPS  eth1

it just seems to be the DVB card that the pci code doesnt like, for some reason ..

all ideas warmly received ;)

Kieran.

---

From: Johannes Stezenbach <[email-masked]>
Date: Sun, 16 May 2004 17:21:13 +0200

> wintv pci (analogue) card all work ;
...
> all ideas warmly received ;)

Let me add some information from your posts to linux-dvb and from
the driver source.

I would appreciate it if someone could look it over (full source
is in linux/drivers/media/common/saa7146_core.c). The driver is
known to work on a variety of platforms, including one TX49 based
development system (last tested a few months back, though).

From your first posting:

   PCI: Setting latency timer of device 0000:00:0a.0 to 64
   irq 23: nobody cared!
   Call Trace: [snipped]
   handlers:
   [<c004b570>]
   Disabling IRQ #23
   saa7146: found saa7146 @ mem b2080800 (revision 1, irq 23) (0x13c2,0x1011).

Second try with debug enabled:

   saa7146: saa7146_register_extension(): ext:c001efb0
   saa7146: register extension 'budget_ci dvb'.
   saa7146: saa7146_init_one(): pci:83fdac00
   irq 23: nobody cared!

saa7146_init_one() does the following:
        /* disable all irqs */
	saa7146_write(dev, IER, 0);
	...
        if (request_irq(dev->pci->irq, interrupt_hw, SA_SHIRQ | SA_INTERRUPT,
                        dev->name, dev))
        {error...}
        ...
        INFO(("found saa7146 @ mem %p (revision %d, irq %d) (0x%04x,0x%04x).\n", ...));

interrupt_hw() does:
        /* read out the interrupt status register */
        isr = saa7146_read(dev, ISR);

        /* is this our interrupt? */
        if ( 0 == isr ) {
                /* nope, some other device */
                return IRQ_NONE;
        }
        ...
        return IRQ_HANDLED;

In essence, I believe something other than the saa7146 must be asserting irq 23.
Or is it possible that a bug in the PCI init stuff in saa7146_core.c can
cause this? Any hints how we could debug this would be welcome.

Johannes

---

From: Ralf Baechle <[email-masked]>
Date: Sun, 16 May 2004 19:04:45 +0200

On Sun, May 16, 2004 at 05:21:13PM +0200, Johannes Stezenbach wrote:

> In essence, I believe something other than the saa7146 must be asserting
> irq 23.  Or is it possible that a bug in the PCI init stuff in
> saa7146_core.c can

arch/mips/cobalt/irq.c:cobalt_irq() looks pretty suspect.  It connects
CAUSEF_IP7 and interrupt 23 - but the CPU's builtin count / compare
interrupt already uses this bit.

Sharing the timer interrupt with something else isn't impossible but seems
a less than bright thing to do.  Somebody with production hw to test
should compare this interrupt dispatch function with old working code
from 2.2 or 2.4 ...

  Ralf

---

From: [email-masked] (Kieran Fulke)
Date: Sun, 16 May 2004 18:11:30 +0100

> should compare this interrupt dispatch function with old working code

what exactly do you mean by test? as far as the dvb drivers go, they 
work without any problem (with in the same box / hardware) under 2.4. if 
you can suggest some test cases / methods, i'll happily run them ...

regards,
Kieran.

---

From: Johannes Stezenbach <[email-masked]>
Date: Sun, 16 May 2004 19:21:43 +0200

> should compare this interrupt dispatch function with old working code

Sorry if I snipped too much from Kieran's mail. He reported
a tulip network card works in the same PCI slot, and it uses
irq 23, too.

> >  23:     100002            MIPS  eth1

100002 is just where note_interrupt() disables an unhandled irq, so
maybe Kieran's report that the tulip card works was wrong?

Johannes

---

From: [email-masked] (Kieran Fulke)
Date: Sun, 16 May 2004 19:04:14 +0100

> maybe Kieran's report that the tulip card works was wrong?

yup. please excuse me, i was obviously typing out of my arse (or not 
testing 'thoroughly' enough ...). anyway, the following turns up on 
running 'dhcpcd eth1' (tulip card in pci slot);

Error (regular_file): read_ksyms stat /proc/ksyms failed
ksymoops: No such file or directory
No modules in ksyms, skipping objects
No ksyms, skipping lsmod
Call Trace: [<80084624>]  [<8008461c>]  [<80084720>]  [<800826d0>]  
[<80084a78>]  [<80082ec0>]  [<800826d0>]  [<80082ec0>]  [<800ec230>]  
[<800ac7f4>]  [<800ac6f8>]  [<80084578>]  [<800ac7f4>]  [<80084b18>]  
[<800826d0>]  [<8012ea48>]  [<80082ec0>]  [<800b179c>]  [<800b1788>]  
[<800ac7f4>]  [<80085468>]  [<80085480>]  [<c0051270>]  [<80084bec>]  
[<80082ec0>]  [<c0053db8>]  [<800dcf4c>]  [<801a684c>]  [<801ac4e4>]  
[<800d7924>]  [<801a85fc>]  [<801a66c0>]  [<801e9ae0>]  [<801e9958>]  
[<800d7c44>]  [<80091b50>]  [<801ec8c4>]  [<801fd878>]  [<801fd888>]  
[<8019e27c>]  [<8019e1c4>]  [<8019dc9c>]  [<800ff3bc>]  [<800ff194>]  
[<8019e4bc>]  [<8008be88>]
[<c0051270>]
Warning (Oops_read): Code line not seen, dumping what data is available

Trace; 80084624 <__report_bad_irq+48/8c>
Trace; 8008461c <__report_bad_irq+40/8c>
Trace; 80084720 <note_interrupt+88/d0>
Trace; 800826d0 <cobalt_irq+150/180>
Trace; 80084a78 <do_IRQ+110/1dc>
Trace; 80082ec0 <ret_from_exception+0/0>
Trace; 800826d0 <cobalt_irq+150/180>
Trace; 80082ec0 <ret_from_exception+0/0>
Trace; 800ec230 <bh_lru_install+180/1a4>
Trace; 800ac7f4 <do_softirq+58/8c>
Trace; 800ac6f8 <__do_softirq+48/ec>
Trace; 80084578 <handle_IRQ_event+6c/d0>
Trace; 800ac7f4 <do_softirq+58/8c>
Trace; 80084b18 <do_IRQ+1b0/1dc>
Trace; 800826d0 <cobalt_irq+150/180>
Trace; 8012ea48 <ext3_getblk+d0/298>
Trace; 80082ec0 <ret_from_exception+0/0>
Trace; 800b179c <update_process_times+40/54>
Trace; 800b1788 <update_process_times+2c/54>
Trace; 800ac7f4 <do_softirq+58/8c>
Trace; 80085468 <setup_irq+134/1b0>
Trace; 80085480 <setup_irq+14c/1b0>
Trace; c0051270 <__crc_bio_map_user+9a864/130ac7>
Trace; 80084bec <request_irq+a8/e4>
Trace; 80082ec0 <ret_from_exception+0/0>
Trace; c0053db8 <__crc_bio_map_user+9d3ac/130ac7>
Trace; 800dcf4c <pte_chain_alloc+a4/c8>
Trace; 801a684c <dev_open+94/138>
Trace; 801ac4e4 <dev_mc_upload+58/64>
Trace; 800d7924 <do_no_page+43c/510>
Trace; 801a85fc <dev_change_flags+70/154>
Trace; 801a66c0 <dev_load+24/a0>
Trace; 801e9ae0 <devinet_ioctl+30c/7cc>
Trace; 801e9958 <devinet_ioctl+184/7cc>
Trace; 800d7c44 <handle_mm_fault+f0/278>
Trace; 80091b50 <do_page_fault+170/370>
Trace; 801ec8c4 <inet_ioctl+8c/e8>
Trace; 801fd878 <packet_ioctl+18c/1b0>
Trace; 801fd888 <packet_ioctl+19c/1b0>
Trace; 8019e27c <__sock_create+1a4/384>
Trace; 8019e1c4 <__sock_create+ec/384>
Trace; 8019dc9c <sock_ioctl+418/464>
Trace; 800ff3bc <sys_ioctl+254/2d8>
Trace; 800ff194 <sys_ioctl+2c/2d8>
Trace; 8019e4bc <sys_socket+24/48>
Trace; 8008be88 <stack_done+24/40>
Trace; c0051270 <__crc_bio_map_user+9a864/130ac7>

regards,
kieran.

---

From: Peter Horton <[email-masked]>
Date: Mon, 17 May 2004 09:40:33 +0100

>should compare this interrupt dispatch function with old working code

I've got no hardware here but the code looks roughly similiar

As the Cobalt's use Galileo timer 0 for clock interrupts we could use 
Galileo rather than count/compare for the HPT.

Precision would be 50MHz rather than 125MHz but that shouldn't be a 
problem :-)

P.

---

From: [email-masked] (Kieran Fulke)
Date: Mon, 17 May 2004 12:46:58 +0100

> Precision would be 50MHz rather than 125MHz but that shouldn't be a 

is there any (uncomplicated) way of forcing the machine to assign a 
different IRQ to its single pci slot?

Kieran.

---

From: Peter Horton <[email-masked]>
Date: Mon, 17 May 2004 12:57:57 +0100

>different IRQ to its single pci slot?
It's hard wired.

P.

---

From: [email-masked] (Kieran Fulke)
Date: Mon, 17 May 2004 13:04:05 +0100

> It's hard wired.

that is quite inconvenient. 
so has that timer code changed a lot from 2.4 -> 2.6 ? i've gone back to 
2.4 in the meantime, which has its own issues but works for me .....

Kieran.

---

From: Peter Horton <[email-masked]>
Date: Mon, 17 May 2004 13:20:33 +0100

>2.4 in the meantime, which has its own issues but works for me .....
I'll have a look when I get home.

P.

---

From: Stuart Longland <[email-masked]>
Date: Tue, 18 May 2004 01:07:32 +1000

> problem. some esoteric pci bug perhaps?

If it's any help... I've had similar issues trying to use an Adaptec 
AHA-2940AU PCI SCSI card in a Gateway Microserver running Linux 2.6.[56] 
(not sure which one exactly...).  I'm now running Linux 2.4.26 quite 
happily (the box is being used as a fileserver for LANs), but I can put 
2.6.6 back on if the debugging info would be of any use.

-- 
+-------------------------------------------------------------+
| Stuart Longland           stuartl at longlandclan.hopto.org |
| Brisbane Mesh Node: 719             http://stuartl.cjb.net/ |
| I haven't lost my mind - it's backed up on a tape somewhere |
| Atomic Linux Project    <--->    http://atomicl.berlios.de/ |
+-------------------------------------------------------------+

---

From: Peter Horton <[email-masked]>
Date: Tue, 18 May 2004 08:34:39 +0100

> problem. some esoteric pci bug perhaps?

Not quite so esoteric :-)

Try changing COBALT_QUBE_SLOT_IRQ from 23 to 9 in
include/asm/cobalt/cobalt.h.

P.

---

From: [email-masked] (Kieran Fulke)
Date: Tue, 18 May 2004 18:39:16 +0100

> include/asm/cobalt/cobalt.h.

that looks embarrassingly simple. building a new kernel now. if only 
these things were a bit zippier ...

Kieran.

---

From: [email-masked] (Kieran Fulke)
Date: Tue, 18 May 2004 21:59:14 +0100

> include/asm/cobalt/cobalt.h.

alas, no joy.

<snip-snip>

Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with 
idebus=xx
VP_IDE: IDE controller at PCI slot 0000:00:09.1
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt82c586a (rev 27) IDE UDMA33 controller on pci0000:00:09.1
    ide0: BM-DMA at 0x1420-0x1427, BIOS settings: hda:pio, hdb:pio
    ide1: BM-DMA at 0x1428-0x142f, BIOS settings: hdc:pio, hdd:pio
spurious 8259A interrupt: IRQ9.

cheers,
Kieran.

---

From: [email-masked] (Kieran Fulke)
Date: Tue, 18 May 2004 22:09:52 +0100

> spurious 8259A interrupt: IRQ9.

i should also mention that the boot process stops at this point.

---

From: Peter Horton <[email-masked]>
Date: Tue, 18 May 2004 22:12:46 +0100

> spurious 8259A interrupt: IRQ9.

That's strange, it worked here.

Did you a clean build ?

P.

---

From: [email-masked] (Kieran Fulke)
Date: Tue, 18 May 2004 22:19:32 +0100

> That's strange, it worked here.

yeah. cleared out /usr/src and re-emerged mips-sources-2.6.6, then made 
the change to include/asm/cobalt/cobalt.h you suggested. kernel 
.config attached ..

Kieran.

---

From: Peter Horton <[email-masked]>
Date: Tue, 18 May 2004 22:38:10 +0100

> the change to include/asm/cobalt/cobalt.h you suggested. kernel 

Does this patch fix it ?

P.

--- linux.cvs/arch/mips/cobalt/irq.c	2003-11-13 14:30:45.000000000 +0000
+++ linux.pdh/arch/mips/cobalt/irq.c	2004-05-18 22:35:32.000000000 +0100
@@ -82,11 +83,15 @@
 	}
 
 	if (pending & CAUSEF_IP7) {			/* int 23 */
-		do_IRQ(COBALT_QUBE_SLOT_IRQ, regs);
+		do_IRQ(23, regs);
 		return;
 	}
 }

---

From: Kumba <[email-masked]>
Date: Tue, 18 May 2004 17:46:21 -0400

> the change to include/asm/cobalt/cobalt.h you suggested. kernel 

Just to rule out a few things, try disabling the following options in 
your .config:

CONFIG_IDE_TASK_IOCTL (IDE Taskfile Access)
CONFIG_IDE_TASKFILE_IO (IDE Taskfile IO)

CONFIG_TULIP_MWI (New bus configuration)
CONFIG_TULIP_MMIO (Use PCI shared mem for NIC registers)
CONFIG_TULIP_NAPI (Use NAPI RX polling)
CONFIG_TULIP_NAPI_HW_MITIGATION (Use Interrupt Mitigation)

Taskfile access is, afaict, needed only if you're doing disk forensics 
or such.  The new taskfile IO code hung up on me a few times on Cobalt 
when I was initially testing some of Peter's 2.6.x patches, and as such, 
I haven't cut it on since then.

Tulip, I don't recall which, but I *think* one of them also caused me 
some kind of an issue, I'm unsure if it was a hang or something else. In 
either case, I left them as is.

See if turning those off does anything different.

--Kumba

-- 
"Such is oft the course of deeds that move the wheels of the world: 
small hands do them because they must, while the eyes of the great are 
elsewhere."  --Elrond

---

From: [email-masked] (Kieran Fulke)
Date: Tue, 18 May 2004 23:02:14 +0100

> +++ linux.pdh/arch/mips/cobalt/irq.c	2004-05-18 22:35:32.000000000 +0100

Aha. that seems to work now. i can certainly now tune the card in and do 
stuff [tm] with it. thanks for the help.

 cat /proc/interrupts
           CPU0
  2:          0          XT-PIC  cascade
  9:       4134          XT-PIC  saa7146 (0)
 14:      27964          XT-PIC  ide0
 18:     711618            MIPS  timer
 19:      11311            MIPS  eth0
 21:        288            MIPS  serial
 22:          0            MIPS  cascade

0000:00:0a.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 
01)
        Subsystem: Technotrend Systemtechnik GmbH: Unknown device 1011
        Flags: bus master, medium devsel, latency 64, IRQ 9
        Memory at 12080800 (32-bit, non-prefetchable)

cheers,
Kieran.

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Wed, 19 May 2004 13:23:28 +0200 (CEST)

> alas, no joy.
[...]
> spurious 8259A interrupt: IRQ9.

 Hmm, interesting.  As the 8259A can only signal IRQ7 and possibly IRQ15
as spurious interrupts, this smells like a bug in 8259A handlers,
regardless of system-specific problems you have.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: [email-masked], PGP key available        +

---

From: Peter Horton <[email-masked]>
Date: Wed, 19 May 2004 13:57:22 +0100

>regardless of system-specific problems you have.
We were getting interrupt 23 and calling do_IRQ() with a value of 9 (a 
bug, obviously). Interrupt 9 is masked so we get a "spurious 8259A 
interrupt" message.

P.