Spurious interrupts when SCI shared with e100

Spurious interrupts when SCI shared with e100

[Udo A. Steinberg]

My laptop has IRQ9 configured as ACPI SCI. When IRQ9 is shared between ACPI
and e100 an IRQ9 storm occurs when e100 is enabled, as can be seen in the
dmesg output below. The kernel then disables IRQ9, thus preventing e100 from
working properly. The problem does not occur, if I override the default PCI
steering in the BIOS, e.g. by routing LNKA to IRQ11.

Nonetheless it would be good if someone could figure out why sharing IRQ9 
is problematic.

Thanks,
-Udo.

Linux version 2.6.10-rc1 (root@laptop.delusion.de) (gcc version 3.4.2) #2 Sun Nov 7 12:17:47 PST 2004
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
 BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000000fff0000 (usable)
 BIOS-e820: 000000000fff0000 - 000000000fffec00 (ACPI data)
 BIOS-e820: 000000000fffec00 - 0000000010000000 (ACPI NVS)
 BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved)
255MB LOWMEM available.
On node 0 totalpages: 65520
  DMA zone: 4096 pages, LIFO batch:1
  Normal zone: 61424 pages, LIFO batch:14
  HighMem zone: 0 pages, LIFO batch:1
DMI 2.3 present.
ACPI: RSDP (v000 PTLTD                                 ) @ 0x000f71a0
ACPI: RSDT (v001 PTLTD    RSDT   0x06041160  LTP 0x00000000) @ 0x0fff4e5e
ACPI: FADT (v001 IBM    TP-T20   0x06041160  0x00000000) @ 0x0fffeb65
ACPI: BOOT (v001 PTLTD  $SBFTBL$ 0x06041160  LTP 0x00000001) @ 0x0fffebd9
ACPI: DSDT (v001 IBM    TP-T20   0x06041160 MSFT 0x0100000c) @ 0x00000000
ACPI: PM-Timer IO Port: 0x1008
Built 1 zonelists
Kernel command line: parport=auto resume=/dev/hda2 video=vesa:mtrr vga=0x317
Initializing CPU#0
PID hash table entries: 1024 (order: 10, 16384 bytes)
Detected 746.857 MHz processor.
Using pmtmr for high-res timesource
Console: colour dummy device 80x25
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 254700k/262080k available (2909k kernel code, 6812k reserved, 949k data, 156k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay loop... 1478.65 BogoMIPS (lpj=739328)
Security Framework v1.0.0 initialized
Capability LSM initialized
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: After generic identify, caps: 0383f9ff 00000000 00000000 00000000
CPU: After vendor identify, caps:  0383f9ff 00000000 00000000 00000000
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
CPU: After all inits, caps:        0383f9ff 00000000 00000000 00000040
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: Intel Pentium III (Coppermine) stepping 03
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
ACPI: IRQ9 SCI: Level Trigger.
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xfd94f, last bus=7
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20040816
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 *5 6 7 9 10 11)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *9 10 11)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 *10 11)
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGP_._PRT]
ACPI: Power Resource [PSER] (on)
ACPI: Power Resource [PSIO] (on)
ACPI: Embedded Controller [EC] (gpe 9)
Linux Kernel Card Services
  options:  [pci] [cardbus] [pm]
usbcore: registered new driver usbfs
usbcore: registered new driver hub
PCI: Using ACPI for IRQ routing
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
ACPI: PCI interrupt 0000:00:02.0[A] -> GSI 11 (level, low) -> IRQ 11
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 5
ACPI: PCI interrupt 0000:00:02.1[B] -> GSI 5 (level, low) -> IRQ 5
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 9
ACPI: PCI interrupt 0000:00:03.0[A] -> GSI 9 (level, low) -> IRQ 9
ACPI: PCI interrupt 0000:00:03.1[A] -> GSI 9 (level, low) -> IRQ 9
ACPI: PCI interrupt 0000:00:05.0[A] -> GSI 11 (level, low) -> IRQ 11
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 10
ACPI: PCI interrupt 0000:00:07.2[D] -> GSI 10 (level, low) -> IRQ 10
ACPI: PCI interrupt 0000:01:00.0[A] -> GSI 11 (level, low) -> IRQ 11
Simple Boot Flag at 0x35 set to 0x1
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
NTFS driver 2.1.21 [Flags: R/O].
Initializing Cryptographic API
Limiting direct PCI/PCI transfers.
vesafb: framebuffer at 0xf0000000, mapped to 0xd0880000, using 3072k, total 8192k
vesafb: mode is 1024x768x16, linelength=2048, pages=4
vesafb: protected mode interface info at c000:87f7
vesafb: scrolling: redraw
vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
Console: switching to colour frame buffer device 128x48
fb0: VESA VGA frame buffer device
ACPI: AC Adapter [AC] (on-line)
ACPI: Battery Slot [BAT0] (battery present)
ACPI: Battery Slot [BAT1] (battery present)
ACPI: Power Button (FF) [PWRF]
ACPI: Lid Switch [LID]
ACPI: Sleep Button (CM) [SLPB]
ACPI: Processor [CPU] (supports C1 C2 C3, 8 throttling states)
ACPI: Thermal Zone [THM0] (59 C)
Real Time Clock Driver v1.12
Non-volatile memory driver v1.2
Linux agpgart interface v0.100 (c) Dave Jones
agpgart: Detected an Intel 440BX Chipset.
agpgart: Maximum main memory to use for agp memory: 203M
agpgart: AGP aperture is 64M @ 0xf8000000
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing enabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a NS16550A
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ACPI: PCI interrupt 0000:00:03.1[A] -> GSI 9 (level, low) -> IRQ 9
parport0: PC-style at 0x3bc (0x7bc), irq 7, using FIFO [PCSPP,TRISTATE,COMPAT,ECP]
io scheduler noop registered
io scheduler deadline registered
elevator: using deadline as default io scheduler
Floppy drive(s): fd0 is 1.44M
FDC 0 is a National Semiconductor PC87306
loop: loaded (max 8 devices)
e100: Intel(R) PRO/100 Network Driver, 3.0.27-k2-NAPI
e100: Copyright(c) 1999-2004 Intel Corporation
ACPI: PCI interrupt 0000:00:03.0[A] -> GSI 9 (level, low) -> IRQ 9
irq 9: nobody cared!
 [<c0132544>] __report_bad_irq+0x24/0x80
 [<c013265e>] note_interrupt+0x8e/0xb0
 [<c0131ec4>] handle_IRQ_event+0x34/0x70
 [<c013205b>] __do_IRQ+0x15b/0x180
 [<c0105c06>] do_IRQ+0x26/0x40
 [<c0104228>] common_interrupt+0x18/0x20
 [<c011f30d>] __do_softirq+0x2d/0x90
 [<c011f397>] do_softirq+0x27/0x30
 [<c0131e85>] irq_exit+0x35/0x40
 [<c0105c0b>] do_IRQ+0x2b/0x40
 [<c0104228>] common_interrupt+0x18/0x20
 [<c01480f6>] __get_vm_area+0x146/0x220
 [<c0216ccd>] pci_bus_read_config_byte+0x6d/0x70
 [<c01481f7>] get_vm_area+0x27/0x30
 [<c0113a86>] __ioremap+0xc6/0x120
 [<c028f6a1>] e100_probe+0x241/0x530
 [<c0168814>] d_alloc+0x154/0x180
 [<c0168f76>] d_rehash+0x66/0x70
 [<c0169986>] alloc_inode+0xd6/0x180
 [<c016889f>] d_instantiate+0x5f/0x80
 [<c0183c3b>] sysfs_create+0x7b/0xe0
 [<c021a5c6>] pci_device_probe_static+0x46/0x70
 [<c021a629>] __pci_device_probe+0x39/0x50
 [<c021a663>] pci_device_probe+0x23/0x50
 [<c0277132>] bus_match+0x32/0x70
 [<c027726d>] driver_attach+0x4d/0x90
 [<c020c052>] kobject_register+0x22/0x60
 [<c027775f>] bus_add_driver+0x8f/0xc0
 [<c0277cc8>] driver_register+0x28/0x30
 [<c011b087>] printk+0x17/0x20
 [<c021a909>] pci_register_driver+0x59/0x80
 [<c04c87b4>] do_initcalls+0x54/0xc0
 [<c0100440>] init+0x0/0x140
 [<c0100440>] init+0x0/0x140
 [<c0100475>] init+0x35/0x140
 [<c01022a8>] kernel_thread_helper+0x0/0x18
 [<c01022ad>] kernel_thread_helper+0x5/0x18
handlers:
[<c022a06f>] (acpi_irq+0x0/0x14)
Disabling IRQ #9
e100: eth0: e100_probe: addr 0xe8120000, irq 9, MAC addr 00:02:B3:06:0A:A8

[patch] e100 and shared interrupts [was: Spurious interrupts when SCI shared with e100]

[peter swain]

[-- Attachment #1: Type: text/plain, Size: 3463 bytes --]

Udo A. Steinberg wrote:

>My laptop has IRQ9 configured as ACPI SCI. When IRQ9 is shared between ACPI
>and e100 an IRQ9 storm occurs when e100 is enabled, as can be seen in the
>dmesg output below. The kernel then disables IRQ9, thus preventing e100 from
>working properly. The problem does not occur, if I override the default PCI
>steering in the BIOS, e.g. by routing LNKA to IRQ11.
>
>Nonetheless it would be good if someone could figure out why sharing IRQ9 
>is problematic.
>  
>
Udo, please try the attached 2.6.9 patch.

I suspect intel e100 driver always had problems with shared interrupts, 
due to a classic case of
"executable comment syndrome" in the original intel driver.
I noticed races on some of our ancient boxes with e100s, sharing 
interrupts with other e100s, or other cards.

The intel e100 v2.0.40 e100intr() code says.....
        intr_status = readw(&bdp->scb->scb_status);
        /* If not my interrupt, just return */
        if (!(intr_status & SCB_STATUS_ACK_MASK) || (intr_status == 
0xffff)) {
                return IRQ_NONE;
        }

But the test above is *not* "not my interrupt" but "no interesting 
conditions".
Both tests are needed for reliable operation in a shared-irq scenario.

When the driver is meddling with e100 setup, causing intr_status bits to 
pop up, but has not yet enabled
e100 interrupts, a "stray" interrupt from a device sharing the IRQ will 
cause e100intr() to walk all over the
device even if the driver is in a critical section.  Chaos ensues -- in 
my case duplicate skb_free calls when
a parasitic interrupt "completed" processing of tx ring skbs which napi 
bh was still setting up.

Compare with becker's eepro100, where there are (IIRC) 3 locks -- a lock 
on tx resources, a lock on rx resources, and an implicit lock by way of 
the card's interrupt-enable bit.  If you enable interrupts, you're
allowing the irq-handler to play with tx,rx resources without any other 
locks.  So a courteous irq-handler will
check to see if it has been granted the privilege, by inspecting the 
interrupt-enable bit.
Other drivers follow this model, but e100 driver merely has a misleading 
comment instead of the check.

I'd guess that Udo's problem appears when...
- e100 driver is meddling with card, with e100 interrupt enable *off*
- ACPI interrupt causes e100intr to be invoked parasitcally, cleaning up 
(or breaking) some half-finished
   work intended to be guarded by interrupt-enable bit
- driver enables e100 interrupt
- e100-driven IRQ calls e100intr(), finds no work to do
- (conjecture) 2.6.10-rc1 actually checks the IRQ_NONE return, notes 
spurious interrupt & disables IRQ

Our e100 problems went away on hundreds of old linux-2.4 dual-e100 boxes 
when the attached e100-v2-irq-share.patch was applied. It applies 
cleanly to linux-2.4.27, but is untested there.
I'd seen no lkml mention of shared-irq e100 problems, so was letting it 
bake for a couple of weeks before
declaring success, porting it to recent 2.6 and publishing.

But Udo has a problem, so let's see if this fixes it...
My linux-2.6.9 patch is an untested transliteration to intel's e100-v3 
driver structure.
(v3 driver has one e100.c, v2 has e100/*.c tree, cutover was about 
2.6.4? 5?)

I'm not sure if this is implicated in the widespread mistrust of e100 
multiport cards under linux, the e100-eepro100 wars, or the recent 
e100-suspend problems. Could be the missing piece in all.


^..^ feedback very welcome
(oo)




[-- Attachment #2: e100-v2-irq-share.patch --]
[-- Type: text/plain, Size: 1709 bytes --]

## add a module param own_irq=1 to forbid interrupt sharing
## add a check in e100intr for device interrupt masking -- if the driver has masked irqs off,
##  don't execute the usual irq service, but simply report the clash

--- Linux/drivers/net/e100/e100_main.c	Thu Oct 21 17:25:24 2004
+++ linux/drivers/net/e100/e100_main.c	Fri Oct 22 11:45:27 2004
@@ -424,6 +424,9 @@ E100_PARAM(BundleMax, "Maximum number fo
 E100_PARAM(IFS, "Disable or enable the adaptive IFS algorithm");
 E100_PARAM(weight, "rx packets processed per poll");
 
+int own_irq = 0; /* every card gets *own* IRQ? */
+MODULE_PARM(own_irq, "i");
+
 /**
  * e100_exec_cmd - issue a comand
  * @bdp: atapter's private data struct
@@ -1153,7 +1156,7 @@ e100_open(struct net_device *dev)
 		netif_start_queue(dev);
 
 	e100_start_ru(bdp);
-	if ((rc = request_irq(dev->irq, &e100intr, SA_SHIRQ,
+	if ((rc = request_irq(dev->irq, &e100intr, own_irq ? 0 : SA_SHIRQ,
 			      dev->name, dev)) != 0) {
 		del_timer_sync(&bdp->watchdog_timer);
 		goto err_exit;
@@ -2062,11 +2065,20 @@ e100intr(int irq, void *dev_inst, struct
 	dev = dev_inst;
 	bdp = dev->priv;
 
-	intr_status = readw(&bdp->scb->scb_status);
 	/* If not my interrupt, just return */
-	if (!(intr_status & SCB_STATUS_ACK_MASK) || (intr_status == 0xffff)) {
+	if (readb(&bdp->scb->scb_cmd_hi) & SCB_INT_MASK) {
+		static int once = 0;
+
+		if (!once)
+			printk(KERN_ERR "e100intr ignoring disabled interrupt, suspect irq-sharing\n");
+		once = 1;
 		return IRQ_NONE;
 	}
+
+	/* If no pending action, just return */
+	intr_status = readw(&bdp->scb->scb_status);
+	if (!(intr_status & SCB_STATUS_ACK_MASK) || (intr_status == 0xffff))
+		return IRQ_NONE;
 
 
 #ifdef CONFIG_E100_NAPI

[-- Attachment #3: e100-linux-2.6.9-irq-sharing.patch --]
[-- Type: text/plain, Size: 807 bytes --]

--- drivers/net/e100.c-pre-swine	Mon Nov  8 12:19:08 2004
+++ drivers/net/e100.c	Mon Nov  8 12:25:36 2004
@@ -1580,11 +1580,18 @@ static irqreturn_t e100_intr(int irq, vo
 {
 	struct net_device *netdev = dev_id;
 	struct nic *nic = netdev_priv(netdev);
-	u8 stat_ack = readb(&nic->csr->scb.stat_ack);
+	u8 stat_ack, cmd_hi;
 
+	cmd_hi = readb(&nic->csr->scb.cmd_hi);
+	DPRINTK(INTR, DEBUG, "cmd_hi = 0x%02X\n", cmd_hi);
+
+	if(cmd_hi & irq_mask_all)	/* Not our interrupt */
+		return IRQ_NONE;
+
+	stat_ack = readb(&nic->csr->scb.stat_ack);
 	DPRINTK(INTR, DEBUG, "stat_ack = 0x%02X\n", stat_ack);
 
-	if(stat_ack == stat_ack_not_ours ||	/* Not our interrupt */
+	if(stat_ack == stat_ack_not_ours ||	/* nothing to do */
 	   stat_ack == stat_ack_not_present)	/* Hardware is ejected */
 		return IRQ_NONE;
 

Re: Spurious interrupts when SCI shared with e100

[Len Brown]

On Mon, 2004-11-08 at 05:59, Udo A. Steinberg wrote:
> My laptop has IRQ9 configured as ACPI SCI. When IRQ9 is shared between
> ACPI and e100 an IRQ9 storm occurs when e100 is enabled, as can be
> seen in the dmesg output below.

Is this new with 2.6.10-rc1, or has it always been broken in an
ACPI-enabled kernel with acpi sharing an irq with e100?

I suspect this may be a bug in the e100 -- it may have enabled
interrupts before it has registered a handler.

Assuming it is a receive interrupt, you may be able to verify this by
plugging in the network cable after the system has probed e100 and see
if it works normally after that.

Also, you might try out the eepro100 driver to see if it behaves any
differently.

thanks,
-Len

Re: Spurious interrupts when SCI shared with e100

[Phil Oester]

On Tue, Nov 09, 2004 at 12:42:46AM -0500, Len Brown wrote:
> On Mon, 2004-11-08 at 05:59, Udo A. Steinberg wrote:
> > My laptop has IRQ9 configured as ACPI SCI. When IRQ9 is shared between
> > ACPI and e100 an IRQ9 storm occurs when e100 is enabled, as can be
> > seen in the dmesg output below.
> 
> Is this new with 2.6.10-rc1, or has it always been broken in an
> ACPI-enabled kernel with acpi sharing an irq with e100?
> 
> I suspect this may be a bug in the e100 -- it may have enabled
> interrupts before it has registered a handler.

I saw similar behaviour in 2.6.8.1 on a non-ACPI enabled kernel with
a dual-port e100.  The nic simply would not work, spewing this error in
syslog:

NETDEV WATCHDOG: eth1: transmit timed out

If I booted with an ACPI enabled kernel, the box worked again.  IRQ
sharing was involved, though can't recall which IRQ eth1 tried to use.
This was on a brand new Dell Optiplex.

Phil

Re: [patch] e100 and shared interrupts [was: Spurious interrupts when SCI shared with e100]

[J.A. Magallon]

On 2004.11.08, peter swain wrote:
> Udo A. Steinberg wrote:
> 
> >My laptop has IRQ9 configured as ACPI SCI. When IRQ9 is shared between ACPI
> >and e100 an IRQ9 storm occurs when e100 is enabled, as can be seen in the
> >dmesg output below. The kernel then disables IRQ9, thus preventing e100 from
> >working properly. The problem does not occur, if I override the default PCI
> >steering in the BIOS, e.g. by routing LNKA to IRQ11.
> >
> >Nonetheless it would be good if someone could figure out why sharing IRQ9 
> >is problematic.
> >  
> >
> Udo, please try the attached 2.6.9 patch.
> 

With this patch, I still get things like this:

Nov  9 22:24:14 nada kernel: e100: Intel(R) PRO/100 Network Driver, 3.2.3-k2-NAPI
Nov  9 22:24:14 nada kernel: e100: Copyright(c) 1999-2004 Intel Corporation
Nov  9 22:24:14 nada kernel: ACPI: PCI interrupt 0000:00:0d.0[A] -> GSI 19 (level, low) -> IRQ 185
Nov  9 22:24:14 nada kernel: e100: eth0: e100_probe: addr 0xf7161000, irq 185, MAC addr 00:30:48:41:22:9F
Nov  9 22:24:14 nada kernel: Badness in enable_irq at kernel/irq/manage.c:106
Nov  9 22:24:14 nada kernel:  [enable_irq+178/256] enable_irq+0xb2/0x100
Nov  9 22:24:14 nada kernel:  [<b0136aa2>] enable_irq+0xb2/0x100
Nov  9 22:24:14 nada kernel:  [pg0+1078951656/1337152512] e100_up+0xe8/0x1f0 [e100]
Nov  9 22:24:14 nada kernel:  [<f09c0ee8>] e100_up+0xe8/0x1f0 [e100]
Nov  9 22:24:14 nada kernel:  [pg0+1078955962/1337152512] e100_open+0x2a/0x90 [e100]
Nov  9 22:24:14 nada kernel:  [<f09c1fba>] e100_open+0x2a/0x90 [e100]
Nov  9 22:24:14 nada kernel:  [dev_open+116/144] dev_open+0x74/0x90
Nov  9 22:24:14 nada kernel:  [<b02f1b74>] dev_open+0x74/0x90
Nov  9 22:24:14 nada kernel:  [dev_change_flags+86/304] dev_change_flags+0x56/0x130
Nov  9 22:24:14 nada kernel:  [<b02f3056>] dev_change_flags+0x56/0x130
Nov  9 22:24:14 nada kernel:  [devinet_ioctl+1522/1696] devinet_ioctl+0x5f2/0x6a0
Nov  9 22:24:14 nada kernel:  [<b032cd72>] devinet_ioctl+0x5f2/0x6a0
Nov  9 22:24:14 nada kernel:  [inet_ioctl+223/256] inet_ioctl+0xdf/0x100
Nov  9 22:24:14 nada kernel:  [<b032ec7f>] inet_ioctl+0xdf/0x100
Nov  9 22:24:14 nada kernel:  [sock_ioctl+435/624] sock_ioctl+0x1b3/0x270
Nov  9 22:24:14 nada kernel:  [<b02e9163>] sock_ioctl+0x1b3/0x270
Nov  9 22:24:14 nada kernel:  [fget+73/96] fget+0x49/0x60
Nov  9 22:24:14 nada kernel:  [<b0156f59>] fget+0x49/0x60
Nov  9 22:24:14 nada kernel:  [sys_ioctl+517/624] sys_ioctl+0x205/0x270
Nov  9 22:24:14 nada kernel:  [<b0168185>] sys_ioctl+0x205/0x270
Nov  9 22:24:14 nada kernel:  [sysenter_past_esp+82/113] sysenter_past_esp+0x52/0x71
Nov  9 22:24:14 nada kernel:  [<b0105add>] sysenter_past_esp+0x52/0x71
Nov  9 22:24:14 nada kernel: e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex


--
J.A. Magallon <jamagallon()able!es>     \               Software is like sex:
werewolf!able!es                         \         It's better when it's free
Mandrakelinux release 10.2 (Cooker) for i586
Linux 2.6.9-jam1 (gcc 3.4.1 (Mandrakelinux 10.1 3.4.1-4mdk)) #10