Interrupt posted but not delivered

Interrupt posted but not delivered

[Michal Jaegermann]

I have troubles which look like an IRQ delivery failures on
TYAN-S2466N-4M dual processor Athlon board.

More precisely this looks as follows. There is a 3Com 3c905C Tornado
NIC built-in on the board.  It works, no problems, as long as it is
alone. But we also have to add to that DLink DFE570 with four other
ethernet ports which are using 'tulip' (or 'de4x5') driver.  This
card, and video, are stuck into a raiser card.  I understand that
this spells trouble but the whole thing have to fit into a 2U unit.

The moment these extra ports show up 3c905C stops to work.  It is
visible, and I configure it using a static IP address, but nothing
gets through it and from /proc/interrupts it looks that it is not
getting a single interrupt.  I can get tulip ports to work; at least
with some raisers, and this may require an extra voodoo, but it
is doable.  So far no luck with tornado as long as as tulips are
present.  I tried few different kernels from 2.4 series (none from
2.4.19pre yet, though) and results are invariably the same.  Options
like 'noacpi' and/or 'pci=biosirq' do not improve anything.  There
seem to be some conflict with USB which is not needed here.  Booting
with 'nousb' seems to give somewhat saner results but still no dice.

'lspci -tv' with a "good" raiser provides the following picture and
I marked assigned IRQs (no conflicts on i/o ports as far as I can see).

-[00]-+-00.0  Advanced Micro Devices [AMD]: Unknown device 700c
      +-01.0-[01]--
      +-07.0  Advanced Micro Devices [AMD]: Unknown device 7440
      +-07.1  Advanced Micro Devices [AMD]: Unknown device 7441
      +-07.3  Advanced Micro Devices [AMD]: Unknown device 7443
      +-08.0-[02]--+-04.0  Digital Equipment Corporation DECchip 21142/43
								(IRQ 10)
      |            +-05.0  Digital Equipment Corporation DECchip 21142/43
								(IRQ 11)
      |            +-06.0  Digital Equipment Corporation DECchip 21142/43
								(IRQ 5)
      |            \-07.0  Digital Equipment Corporation DECchip 21142/43
								(IRQ 9)
      +-09.0  nVidia Corporation Vanta [NV6]    (IRQ 11)
      \-10.0-[03]--+-00.0  Advanced Micro Devices [AMD]: Unknown device 7449
								(IRQ 10)
                   \-08.0  3Com Corporation 3c905C-TX [Fast Etherlink] (IRQ 11)

"Uknown devices" are:
 700c - host bridge
 7440 - ISA bridge
 7441 - IDE interface
 7443 - bridge of some kind
 7449 - USB controller

Attempts to pass, rather long, 'pirq=...' line to kernel made tulips
to behave somewhat "better" but nothing for 3com.  Maybe I have not
done that properly with with four busses this seem to be 16 numbers.
BTW, Tyan FAQ gives that (AGP slot is not used):

AGP                     IntB/IntC
PCI Bus 1 slot 1 =      IntA
PCI bus 1 slot 2 =      IntB
PCI Bus 2 slot 1 =      IntA
PCI bus 2 slot 2 =      IntB
PCI bus 2 slot 3 =      IntC
PCI bus 2 slot 4 =      IntD
3COM LAN                IntD

MP specs are v1.4 and I do not see a way to switch them to v1.1;
at least not in BIOS.  Am I looking in wrong places?

Here are what looks like relavant fragments of 'dmesg' (these are
from 2.4.18 based kernel but they really do not differ elsewhere).

127MB HIGHMEM available.
found SMP MP-table at 000f71e0
hm, page 000f7000 reserved twice.
hm, page 000f8000 reserved twice.
hm, page 0009f000 reserved twice.
hm, page 000a0000 reserved twice.
On node 0 totalpages: 262016
zone(0): 4096 pages.
zone(1): 225280 pages.
zone(2): 32640 pages.
Intel MultiProcessor Specification v1.4
    Virtual Wire compatibility mode.
OEM ID: TYAN     Product ID: PAULANER     APIC at: 0xFEE00000
Processor #1 Pentium(tm) Pro APIC version 16
Processor #0 Pentium(tm) Pro APIC version 16
I/O APIC #2 Version 17 at 0xFEC00000.
.........
Total of 2 processors activated (6121.06 BogoMIPS).
ENABLING IO-APIC IRQs
Setting 2 in the phys_id_present_map
...changing IO-APIC physical APIC ID to 2 ... ok.
init IO_APIC IRQs
 IO-APIC (apicid-pin) 2-0, 2-22, 2-23 not connected.
..TIMER: vector=0x31 pin1=2 pin2=0
number of MP IRQ sources: 22.
number of IO-APIC #2 registers: 24.
testing the IO APIC.......................

IO APIC #2......
.... register #00: 02000000
.......    : physical APIC id: 02
.... register #01: 00170011
.......     : max redirection entries: 0017
.......     : PRQ implemented: 0
.......     : IO APIC version: 0011
.... register #02: 00000000
.......     : arbitration: 00
.... IRQ redirection table:
 NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:   
 00 000 00  1    0    0   0   0    0    0    00
 01 003 03  0    0    0   0   0    1    1    39
 02 003 03  0    0    0   0   0    1    1    31
 03 003 03  0    0    0   0   0    1    1    41
 04 003 03  0    0    0   0   0    1    1    49
 05 003 03  1    1    0   1   0    1    1    51
 06 003 03  0    0    0   0   0    1    1    59
 07 003 03  0    0    0   0   0    1    1    61
 08 003 03  0    0    0   0   0    1    1    69
 09 003 03  1    1    0   1   0    1    1    71
 0a 003 03  1    1    0   1   0    1    1    79
 0b 003 03  1    1    0   1   0    1    1    81
 0c 003 03  0    0    0   0   0    1    1    89
 0d 003 03  0    0    0   0   0    1    1    91
 0e 003 03  0    0    0   0   0    1    1    99
 0f 003 03  0    0    0   0   0    1    1    A1
 10 003 03  0    0    0   0   0    1    1    A9
 11 003 03  0    0    0   0   0    1    1    B1
 12 003 03  0    0    0   0   0    1    1    B9
 13 003 03  0    0    0   0   0    1    1    C1
 14 003 03  0    0    0   0   0    1    1    C9
 15 003 03  1    1    0   1   0    1    1    D1
 16 000 00  1    0    0   0   0    0    0    00
 17 000 00  1    0    0   0   0    0    0    00
IRQ to pin mappings:
IRQ0 -> 0:2
IRQ1 -> 0:1
IRQ3 -> 0:3
IRQ4 -> 0:4
IRQ5 -> 0:5
IRQ6 -> 0:6
IRQ7 -> 0:7
IRQ8 -> 0:8
IRQ9 -> 0:9
IRQ10 -> 0:10
IRQ11 -> 0:11
IRQ12 -> 0:12
IRQ13 -> 0:13
IRQ14 -> 0:14
IRQ15 -> 0:15
IRQ16 -> 0:16
IRQ17 -> 0:17
IRQ18 -> 0:18
IRQ19 -> 0:19
IRQ20 -> 0:20
IRQ21 -> 0:21
.................................... done.
..............
PCI: Using IRQ router default [1022/7443] at 00:07.3
BIOS failed to enable PCI standards compliance, fixing this error.
..........
Linux Tulip driver version 0.9.15-pre10 (Mar 8, 2002)
tulip0:  EEPROM default media type Autosense.
tulip0:  Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block.
tulip0:  MII transceiver #1 config 1000 status 786d advertising 01e1.
eth0: Digital DS21143 Tulip rev 65 at 0xf8947000, 00:80:C8:CF:E0:DD, IRQ 10.
tulip1:  EEPROM default media type Autosense.
tulip1:  Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block.
tulip1:  MII transceiver #1 config 1000 status 7849 advertising 01e1.
eth1: Digital DS21143 Tulip rev 65 at 0xf8949400, 00:80:C8:CF:E0:DE, IRQ 11.
tulip2:  EEPROM default media type Autosense.
tulip2:  Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block.
tulip2:  MII transceiver #1 config 1000 status 7849 advertising 01e1.
eth2: Digital DS21143 Tulip rev 65 at 0xf894b800, 00:80:C8:CF:E0:DF, IRQ 5.
tulip3:  EEPROM default media type Autosense.
tulip3:  Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block.
tulip3:  MII transceiver #1 config 1000 status 7849 advertising 01e1.
eth3: Digital DS21143 Tulip rev 65 at 0xf894dc00, 00:80:C8:CF:E0:E0, IRQ 9.
3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
03:08.0: 3Com PCI 3c905C Tornado at 0x3000. Vers LK1.1.16
eth0: Setting full-duplex based on MII#1 link partner capability of 45e1.
3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
03:08.0: 3Com PCI 3c905C Tornado at 0x3000. Vers LK1.1.16

and later after attempts to sent something through Tornado:

NETDEV WATCHDOG: eth4: transmit timed out
eth4: transmit timed out, tx_status 00 status e601.
  diagnostics: net 0ccc media 8880 dma 0000003a.
eth4: Interrupt posted but not delivered -- IRQ blocked by another device?
  Flags; bus-master 1, dirty 16(0) current 16(0)
  Transmit list 00000000 vs. f610c200.
  0: @f610c200  length 8000002a status 0001002a
  1: @f610c240  length 8000002a status 0001002a
  2: @f610c280  length 8000002a status 0001002a
  3: @f610c2c0  length 8000002a status 0001002a
  4: @f610c300  length 8000002a status 0001002a
  5: @f610c340  length 8000002a status 0001002a
  6: @f610c380  length 8000002a status 0001002a
  7: @f610c3c0  length 8000002a status 0001002a
  8: @f610c400  length 8000002a status 0001002a
  9: @f610c440  length 8000002a status 0001002a
  10: @f610c480  length 8000002a status 0001002a
  11: @f610c4c0  length 8000002a status 0001002a
  12: @f610c500  length 8000002a status 0001002a
  13: @f610c540  length 8000002a status 0001002a
  14: @f610c580  length 8000002a status 8001002a
  15: @f610c5c0  length 8000002a status 8001002a
eth4: Resetting the Tx ring pointer.

Any bright ideas what could/should be done here?

  TIA,
  Michal

Interrupt posted but not delivered

[Chuck Ebbert]

I've now seen several reports of this message from the 3Com
3c59x driver.  This seems to be a very old problem that has
somehow come back starting with kernel 2.6.19 AFAICT. What
could cause this?

[PATCH] Correctly prevent IDE timer expiry function to run if request was already handled

[Suleiman Souhlal]

It is possible for the timer expiry function to run even though the
request has already been handled: ide_timer_expiry() only checks that
the handler is not NULL, but it is possible that we have handled a
request (thus clearing the handler) and then started a new request
(thus starting the timer again, and setting a handler). 

A simple way to exhibit this is to set the DMA timeout to 1 jiffy and
run dd: The kernel will panic after a few minutes because
ide_timer_expiry() tries to add a timer when it's already active.

To fix this, we simply add a request generation count that gets
incremented at every interrupt, and check in ide_timer_expiry() that
we have not already handled a new interrupt before running the expiry
function.

Signed-off-by:	Suleiman Souhlal <suleiman@google.com>

---
 drivers/ide/ide-io.c   |    6 +++++-
 drivers/ide/ide-iops.c |    2 ++
 include/linux/ide.h    |    2 ++
 3 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/drivers/ide/ide-io.c b/drivers/ide/ide-io.c
index 0e02800..8670112 100644
--- a/drivers/ide/ide-io.c
+++ b/drivers/ide/ide-io.c
@@ -1226,6 +1226,7 @@ #if 1
 #endif
 				/* so that ide_timer_expiry knows what to do */
 				hwgroup->sleeping = 1;
+				hwgroup->req_gen_timer = hwgroup->req_gen;
 				mod_timer(&hwgroup->timer, sleep);
 				/* we purposely leave hwgroup->busy==1
 				 * while sleeping */
@@ -1411,7 +1412,8 @@ void ide_timer_expiry (unsigned long dat
 
 	spin_lock_irqsave(&ide_lock, flags);
 
-	if ((handler = hwgroup->handler) == NULL) {
+	if (((handler = hwgroup->handler) == NULL) ||
+	    (hwgroup->req_gen != hwgroup->req_gen_timer)) {
 		/*
 		 * Either a marginal timeout occurred
 		 * (got the interrupt just as timer expired),
@@ -1439,6 +1441,7 @@ void ide_timer_expiry (unsigned long dat
 				if ((wait = expiry(drive)) > 0) {
 					/* reset timer */
 					hwgroup->timer.expires  = jiffies + wait;
+					hwgroup->req_gen_timer = hwgroup->req_gen;
 					add_timer(&hwgroup->timer);
 					spin_unlock_irqrestore(&ide_lock, flags);
 					return;
@@ -1653,6 +1656,7 @@ #endif /* CONFIG_BLK_DEV_IDEPCI */
 		printk(KERN_ERR "%s: ide_intr: hwgroup->busy was 0 ??\n", drive->name);
 	}
 	hwgroup->handler = NULL;
+	hwgroup->req_gen++;
 	del_timer(&hwgroup->timer);
 	spin_unlock(&ide_lock);
 
diff --git a/drivers/ide/ide-iops.c b/drivers/ide/ide-iops.c
index 1ee53a5..3caa176 100644
--- a/drivers/ide/ide-iops.c
+++ b/drivers/ide/ide-iops.c
@@ -889,6 +889,7 @@ static void __ide_set_handler (ide_drive
 	hwgroup->handler	= handler;
 	hwgroup->expiry		= expiry;
 	hwgroup->timer.expires	= jiffies + timeout;
+	hwgroup->req_gen_timer = hwgroup->req_gen;
 	add_timer(&hwgroup->timer);
 }
 
@@ -929,6 +930,7 @@ void ide_execute_command(ide_drive_t *dr
 	hwgroup->handler	= handler;
 	hwgroup->expiry		= expiry;
 	hwgroup->timer.expires	= jiffies + timeout;
+	hwgroup->req_gen_timer = hwgroup->req_gen;
 	add_timer(&hwgroup->timer);
 	hwif->OUTBSYNC(drive, cmd, IDE_COMMAND_REG);
 	/* Drive takes 400nS to respond, we must avoid the IRQ being
diff --git a/include/linux/ide.h b/include/linux/ide.h
index 58564a1..d3bbc71 100644
--- a/include/linux/ide.h
+++ b/include/linux/ide.h
@@ -861,6 +861,8 @@ typedef struct hwgroup_s {
 	int (*expiry)(ide_drive_t *);
 		/* ide_system_bus_speed */
 	int pio_clock;
+	int req_gen;
+	int req_gen_timer;
 
 	unsigned char cmd_buf[4];
 } ide_hwgroup_t;

Re: [PATCH] Correctly prevent IDE timer expiry function to run if request was already handled

[Sergei Shtylyov]

Hello.

Suleiman Souhlal wrote:

> It is possible for the timer expiry function to run even though the
> request has already been handled: ide_timer_expiry() only checks that
> the handler is not NULL, but it is possible that we have handled a
> request (thus clearing the handler) and then started a new request
> (thus starting the timer again, and setting a handler). 

> A simple way to exhibit this is to set the DMA timeout to 1 jiffy and
> run dd: The kernel will panic after a few minutes because
> ide_timer_expiry() tries to add a timer when it's already active.

> To fix this, we simply add a request generation count that gets
> incremented at every interrupt, and check in ide_timer_expiry() that
> we have not already handled a new interrupt before running the expiry
> function.

    Couldn't this be addressed by simply changing add_timer() to mod_timer()?

MBR, Sergei

Re: [PATCH] Correctly prevent IDE timer expiry function to run if request was already handled

[Suleiman Souhlal]

On Fri, April 6, 2007 12:22 pm, Sergei Shtylyov wrote:
> Hello.
>
>
> Suleiman Souhlal wrote:
>
>
>> It is possible for the timer expiry function to run even though the
>> request has already been handled: ide_timer_expiry() only checks that the
>> handler is not NULL, but it is possible that we have handled a request
>> (thus clearing the handler) and then started a new request
>> (thus starting the timer again, and setting a handler).
>>
>
>> A simple way to exhibit this is to set the DMA timeout to 1 jiffy and
>> run dd: The kernel will panic after a few minutes because
>> ide_timer_expiry() tries to add a timer when it's already active.
>
>> To fix this, we simply add a request generation count that gets
>> incremented at every interrupt, and check in ide_timer_expiry() that we
>> have not already handled a new interrupt before running the expiry
>> function.
>
> Couldn't this be addressed by simply changing add_timer() to mod_timer()?

No, we don't want to run the expiry function at all, in this case, since
the   request might have correctly been handled already by the time we
would try to run the expiry function/restart the timer.

Also, if we just change the add_timer() to mod_timer(), we will just be
hiding the problem because you might end up changing the timeout of a
timer whose purpose is different (for a new request, for example).
The timer should not be active when ide_timer_expiry() tries to restart
it, since that function is called when the timer has expired (meaning it
is not active anymore).
The reason the timer could have been active at that point, before applying
this patch, is that we try to dispatch a new request after handling one.
The new request will then have its own expiry timer, along with a handler.
Since  before this patch ide_timer_expiry() only looked at whether or not
a handler was present, it would incorrectly think the request had not been
handled already, and incorrectly tried to restart the timer.

-- Suleiman

Re: [PATCH] Correctly prevent IDE timer expiry function to run if request was already handled

[Sergei Shtylyov]

Hello.

Suleiman Souhlal wrote:

>>>It is possible for the timer expiry function to run even though the
>>>request has already been handled: ide_timer_expiry() only checks that the
>>>handler is not NULL, but it is possible that we have handled a request
>>>(thus clearing the handler) and then started a new request
>>>(thus starting the timer again, and setting a handler).

>>>A simple way to exhibit this is to set the DMA timeout to 1 jiffy and
>>>run dd: The kernel will panic after a few minutes because
>>>ide_timer_expiry() tries to add a timer when it's already active.

>>>To fix this, we simply add a request generation count that gets
>>>incremented at every interrupt, and check in ide_timer_expiry() that we
>>>have not already handled a new interrupt before running the expiry
>>>function.

>>Couldn't this be addressed by simply changing add_timer() to mod_timer()?

> No, we don't want to run the expiry function at all, in this case, since
> the   request might have correctly been handled already by the time we
> would try to run the expiry function/restart the timer.

> Also, if we just change the add_timer() to mod_timer(), we will just be
> hiding the problem because you might end up changing the timeout of a
> timer whose purpose is different (for a new request, for example).
> The timer should not be active when ide_timer_expiry() tries to restart
> it, since that function is called when the timer has expired (meaning it
> is not active anymore).

    Yeah, that was stupid idea.  Been looking at network schedulers too much 
recently. :-)

> The reason the timer could have been active at that point, before applying
> this patch, is that we try to dispatch a new request after handling one.
> The new request will then have its own expiry timer, along with a handler.
> Since  before this patch ide_timer_expiry() only looked at whether or not
> a handler was present, it would incorrectly think the request had not been
> handled already, and incorrectly tried to restart the timer.

    Hm, I'm still not sure why this happens at all, probably need to try 
reproducing it (unless you post a stack trace :-).

> -- Suleiman

MBR, Sergei

Re: Interrupt posted but not delivered

[Kirill Yushkov]

Hello, Chuck!
You wrote to LKML on 2007-03-26 0:28:05:

CE> I've now seen several reports of this message from the 3Com
CE> 3c59x driver.  This seems to be a very old problem that has
CE> somehow come back starting with kernel 2.6.19 AFAICT. What
CE> could cause this?
I too have the same problem on version 2.6.20

Apr  6 18:18:14 gw kernel: NETDEV WATCHDOG: eth0: transmit timed out
Apr  6 18:18:14 gw kernel: eth0: transmit timed out, tx_status 00 status 
e681.
Apr  6 18:18:14 gw kernel:   diagnostics: net 0cf6 media 8880 dma 0000003a 
fifo 8000
Apr  6 18:18:14 gw kernel: eth0: Interrupt posted but not delivered -- IRQ 
blocked by another device?
Apr  6 18:18:14 gw kernel:   Flags; bus-master 1, dirty 63886224(0) current 
63886224(0)
Apr  6 18:18:14 gw kernel:   Transmit list 00000000 vs. ffff8100b8967200.
Apr  6 18:18:14 gw kernel:   0: @ffff8100b8967200  length 80000032 status 
00010032
Apr  6 18:18:14 gw kernel:   1: @ffff8100b89672a0  length 80000032 status 
00010032
Apr  6 18:18:14 gw kernel:   2: @ffff8100b8967340  length 8000002e status 
0001002e
Apr  6 18:18:14 gw kernel:   3: @ffff8100b89673e0  length 80000032 status 
00010032
Apr  6 18:18:14 gw kernel:   4: @ffff8100b8967480  length 80000058 status 
00010058
Apr  6 18:18:14 gw kernel:   5: @ffff8100b8967520  length 800002bc status 
000102bc
Apr  6 18:18:14 gw kernel:   6: @ffff8100b89675c0  length 80000061 status 
00010061
Apr  6 18:18:14 gw kernel:   7: @ffff8100b8967660  length 800000b3 status 
000100b3
Apr  6 18:18:14 gw kernel:   8: @ffff8100b8967700  length 800000aa status 
000100aa
Apr  6 18:18:14 gw kernel:   9: @ffff8100b89677a0  length 8000005c status 
0001005c
Apr  6 18:18:14 gw kernel:   10: @ffff8100b8967840  length 800005ac status 
000105ac
Apr  6 18:18:14 gw kernel:   11: @ffff8100b89678e0  length 800000e8 status 
000100e8
Apr  6 18:18:14 gw kernel:   12: @ffff8100b8967980  length 800005ac status 
000105ac
Apr  6 18:18:14 gw kernel:   13: @ffff8100b8967a20  length 800005ac status 
000105ac
Apr  6 18:18:14 gw kernel:   14: @ffff8100b8967ac0  length 80000062 status 
80010062
Apr  6 18:18:14 gw kernel:   15: @ffff8100b8967b60  length 8000046a status 
8001046a
Apr  6 18:18:15 gw kernel: BUG: at include/net/dst.h:154 dst_release()
Apr  6 18:18:15 gw kernel:
Apr  6 18:18:15 gw kernel: Call Trace:
Apr  6 18:18:15 gw kernel:  <IRQ>  [<ffffffff8022285f>] 
__kfree_skb+0x3f/0x120
Apr  6 18:18:15 gw kernel:  [<ffffffff80427282>] 
__neigh_event_send+0x142/0x190
Apr  6 18:18:15 gw kernel:  [<ffffffff804471c0>] ip_finish_output+0x0/0x200
Apr  6 18:18:15 gw kernel:  [<ffffffff8024c89a>] 
neigh_resolve_output+0x7a/0x1a0
Apr  6 18:18:15 gw kernel:  [<ffffffff80229c44>] ip_output+0x244/0x280
Apr  6 18:18:15 gw kernel:  [<ffffffff881198bb>] :pptp:pptp_xmit+0x6bb/0x760
Apr  6 18:18:15 gw kernel:  [<ffffffff8810254f>] 
:ppp_generic:ppp_push+0x5f/0xe0
Apr  6 18:18:15 gw kernel:  [<ffffffff881024c4>] 
:ppp_generic:ppp_send_frame+0x4e4/0x510
Apr  6 18:18:15 gw kernel:  [<ffffffff88101f77>] 
:ppp_generic:ppp_xmit_process+0x37/0xa0
Apr  6 18:18:15 gw kernel:  [<ffffffff88101d91>] 
:ppp_generic:ppp_start_xmit+0x1e1/0x210
Apr  6 18:18:15 gw kernel:  [<ffffffff80421c4e>] 
dev_hard_start_xmit+0x8e/0x140
Apr  6 18:18:15 gw kernel:  [<ffffffff804324bf>] __qdisc_run+0xff/0x1c0
Apr  6 18:18:15 gw kernel:  [<ffffffff80227845>] dev_queue_xmit+0x145/0x280
Apr  6 18:18:15 gw kernel:  [<ffffffff80447352>] 
ip_finish_output+0x192/0x200
Apr  6 18:18:15 gw kernel:  [<ffffffff8043d810>] nf_reinject+0x190/0x1e0
Apr  6 18:18:15 gw kernel:  [<ffffffff804471c0>] ip_finish_output+0x0/0x200
Apr  6 18:18:15 gw kernel:  [<ffffffff8811009a>] :imq:imq_dev_xmit+0x4a/0x60
Apr  6 18:18:15 gw kernel:  [<ffffffff80421c4e>] 
dev_hard_start_xmit+0x8e/0x140
Apr  6 18:18:15 gw kernel:  [<ffffffff804322dc>] qdisc_restart1+0xdc/0x1c0

With best regards, Kirill Yushkov.  E-mail: mail@kirya.ru