rt2800pci: handle spurious interrupts

Ivo Van Doorn · 2011-11-16 10:14 UTC

Hi,

Quoted 23 lines · Stanislaw Gruszka

Some devices may generate spurious interrupts, we have to handle them otherwise interrupt line will be disabled with below message and driver will not work:

[ 2052.114334] irq 17: nobody cared (try booting with the "irqpoll" option)
[ 2052.114339] Pid: 0, comm: swapper Tainted: P           2.6.35.6-48.fc14.x86_64 #1
[ 2052.114341] Call Trace:
[ 2052.114342]  <IRQ>  [<ffffffff810a6e2b>] __report_bad_irq.clone.1+0x3d/0x8b
[ 2052.114349]  [<ffffffff810a6f93>] note_interrupt+0x11a/0x17f
[ 2052.114352]  [<ffffffff810a7a73>] handle_fasteoi_irq+0xa8/0xce
[ 2052.114355]  [<ffffffff8100c2ea>] handle_irq+0x88/0x90
[ 2052.114357]  [<ffffffff8146f034>] do_IRQ+0x5c/0xb4
[ 2052.114360]  [<ffffffff81469593>] ret_from_intr+0x0/0x11
[ 2052.114361]  <EOI>  [<ffffffff8102b7f9>] ? native_safe_halt+0xb/0xd
[ 2052.114366]  [<ffffffff81010f03>] ? need_resched+0x23/0x2d
[ 2052.114367]  [<ffffffff8101102a>] default_idle+0x34/0x4f
[ 2052.114370]  [<ffffffff81008325>] cpu_idle+0xaa/0xcc
[ 2052.114373]  [<ffffffff81461f2a>] start_secondary+0x24d/0x28e
[ 2052.114374] handlers:
[ 2052.114375] [<ffffffff81332944>] (usb_hcd_irq+0x0/0x7c)
[ 2052.114378] [<ffffffffa00697da>] (rt2800pci_interrupt+0x0/0x18d [rt2800pci])
[ 2052.114384] Disabling IRQ #17

Quoted 6 lines

Resolve:
https://bugzilla.redhat.com/show_bug.cgi?id=658451
Reported-and-tested-by Amir Hedayaty <[email protected]>
Cc [email protected]
Signed-off-by Stanislaw Gruszka <[email protected]>

Acked-by Ivo van Doorn <[email protected]>

Quoted 3 lines

---
I changed rt2800pci only because get bug report for that device, not sure if similar changes are not needed for other rt2x00 PCI devices.

The ticket mentiones that the end-result is a slow connection, this is also a bug in older chipsets. So could you prepare a patch for the other drivers as well?

Quoted 26 lines

drivers/net/wireless/rt2x00/rt2800pci.c | 7 ++++++-

 1 files changed, 6 insertions(+), 1 deletions(-)

drivers/net/wireless/rt2x00/rt2800pci.c +6 -2

index da48c8a..4dc2d0f 100644
@@ -880,8 +880,13 @@ static irqreturn_t rt2800pci_interrupt(int irq, void *dev_instance)
        rt2x00pci_register_read(rt2x00dev, INT_SOURCE_CSR, &reg);
        rt2x00pci_register_write(rt2x00dev, INT_SOURCE_CSR, reg);
 
+       /*
+        * Some devices can generate interrupts with empty CSR register, we
+        * "handle" such irq's to prevent interrupt controller treat them as
+        * spurious interrupts and disable irq line.
+        */
        if (!reg)
-               return IRQ_NONE;
+               return IRQ_HANDLED;
 
        if (!test_bit(DEVICE_STATE_ENABLED_RADIO, &rt2x00dev->flags))
                return IRQ_HANDLED;
--

1.7.1

Helmut Schaa · 2011-11-16 10:46 UTC

Quoted 8 lines · Stanislaw Gruszka

+ /*
+ * Some devices can generate interrupts with empty CSR register, we
+ * "handle" such irq's to prevent interrupt controller treat them as
+ * spurious interrupts and disable irq line.
+ */
if (!reg)
- return IRQ_NONE;
+ return IRQ_HANDLED;

What if this interrupt belongs to a different device on a shared interrupt line? In case reg is zero we can't be sure our device generated this interrupt, right?

Helmut

Ivo Van Doorn · 2011-11-16 10:52 UTC

Quoted 10 lines · Helmut Schaa

Quoted 8 lines · Stanislaw Gruszka
+ /*
+ * Some devices can generate interrupts with empty CSR register, we
+ * "handle" such irq's to prevent interrupt controller treat them as
+ * spurious interrupts and disable irq line.
+ */
if (!reg)
- return IRQ_NONE;
+ return IRQ_HANDLED;

Quoted 2 lines

What if this interrupt belongs to a different device on a shared interrupt line? In case reg is zero we can't be sure our device generated this interrupt, right?

In the bugzilla report Stanislaw indicated that even when rt2800pci indicates IRQ_HANDLED,
all other drivers on the same interruptline will still get the interrupt event.

Ivo

Helmut Schaa · 2011-11-16 11:01 UTC

Quoted 12 lines · Ivo Van Doorn

Quoted 10 lines · Helmut Schaa
Quoted 8 lines · Stanislaw Gruszka
+ /*
+ * Some devices can generate interrupts with empty CSR register, we
+ * "handle" such irq's to prevent interrupt controller treat them as
+ * spurious interrupts and disable irq line.
+ */
if (!reg)
- return IRQ_NONE;
+ return IRQ_HANDLED;

Quoted 6 lines

Quoted 2 lines
What if this interrupt belongs to a different device on a shared interrupt line? In case reg is zero we can't be sure our device generated this interrupt, right?
In the bugzilla report Stanislaw indicated that even when rt2800pci indicates IRQ_HANDLED,
all other drivers on the same interruptline will still get the interrupt event.

Ah, ok. Should be fine with me then ...

Thanks.

Stanislaw Gruszka · 2011-11-16 11:15 UTC

Quoted 6 lines · Ivo Van Doorn

Quoted 2 lines
I changed rt2800pci only because get bug report for that device, not sure if similar changes are not needed for other rt2x00 PCI devices.
The ticket mentiones that the end-result is a slow connection, this is also a bug in older chipsets. So could you prepare a patch for the other drivers as well?

Yes, sure. Do you have handy links to bug reports that I could reference in the changelog?

Stanislaw

Ivo Van Doorn · 2011-11-16 11:45 UTC

Quoted 9 lines · Stanislaw Gruszka

Quoted 6 lines · Ivo Van Doorn
Quoted 2 lines
I changed rt2800pci only because get bug report for that device, not sure if similar changes are not needed for other rt2x00 PCI devices.
The ticket mentiones that the end-result is a slow connection, this is also a bug in older chipsets. So could you prepare a patch for the other drivers as well?
Yes, sure. Do you have handy links to bug reports that I could reference in the changelog?

Not really, I think most complains were on the mailinglist. There are probably some bugreports, but I am not sure if that was the kernel bugzilla, or on one of the distributions bugzilla's.

Ivo

Michael Basse · 2011-11-22 20:35 UTC

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

Hi Stanislaw,
first of all thank you for your patch.

Quoted 3 lines

I changed rt2800pci only because get bug report for that device, not sure if similar changes are not needed for other rt2x00 PCI devices

Me (and many other) ubuntu-users are facing issues with different Version of Kernel 3.x. As it seems all users are using "rt2800pci" for there wifi.

Model: "RaLink RT2860"
Vendor: pci 0x1814 "RaLink"
Device: pci 0x0781 "RT2860"
SubVendor: pci 0x1814 "RaLink"
SubDevice: pci 0x2790
Driver: "rt2800pci"
Driver Modules: "rt2800pci"

See also

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/869502
http://thread.gmane.org/gmane.linux.kernel/1211290
http://rt2x00.serialmonkey.com/phpBB/viewtopic.php?f=5&t=6192

I have build the newest ubuntu-kernel with your patch

http://alpha-unix.de/~iceroot/ubuntu/

Hopefully your patch is fixing the issues we are facing. Just wanted to say thank you to your work and i will give you feedback about your patch.

Greetings from germany

Michael Basse
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOzAcdAAoJEMIajL8dFT4GAXwIAJJJoUghmTUbw/354z09CDuB eCpIaJw0is+zyp3RLssUJmmabyFtLkC0nFJ4iAGJfL/ozf7ISjtk1nLlQFbt6/iy knV1uSGv6o9UuFCzJZ7boJ9cdNq35pAVul86PFqQ+fgDQYdlqfdLyNc71JRazvIE b01jUudgjZDe09rKmrxiBvcr7FVKPhsSvrH5t6mSYpHJufDDm+TmQk+TJBT+KS8/ aDMPKXlCaAXNlXlm8tgLds8Flx5nnxGvvSXA1DDw37Z7kHOWKLOeHz8ILuctneVz e8Fp5kgl02VVUVFK/K6+M4EbF/jmTo7FIW5Nlv60H9qsfx+peTkhKqx8o48FGAQ= =D2BU
-----END PGP SIGNATURE-----

John W. Linville · 2011-11-22 22:00 UTC

Quoted 23 lines · Stanislaw Gruszka

Some devices may generate spurious interrupts, we have to handle them otherwise interrupt line will be disabled with below message and driver will not work:

[ 2052.114334] irq 17: nobody cared (try booting with the "irqpoll" option)
[ 2052.114339] Pid: 0, comm: swapper Tainted: P           2.6.35.6-48.fc14.x86_64 #1
[ 2052.114341] Call Trace:
[ 2052.114342]  <IRQ>  [<ffffffff810a6e2b>] __report_bad_irq.clone.1+0x3d/0x8b
[ 2052.114349]  [<ffffffff810a6f93>] note_interrupt+0x11a/0x17f
[ 2052.114352]  [<ffffffff810a7a73>] handle_fasteoi_irq+0xa8/0xce
[ 2052.114355]  [<ffffffff8100c2ea>] handle_irq+0x88/0x90
[ 2052.114357]  [<ffffffff8146f034>] do_IRQ+0x5c/0xb4
[ 2052.114360]  [<ffffffff81469593>] ret_from_intr+0x0/0x11
[ 2052.114361]  <EOI>  [<ffffffff8102b7f9>] ? native_safe_halt+0xb/0xd
[ 2052.114366]  [<ffffffff81010f03>] ? need_resched+0x23/0x2d
[ 2052.114367]  [<ffffffff8101102a>] default_idle+0x34/0x4f
[ 2052.114370]  [<ffffffff81008325>] cpu_idle+0xaa/0xcc
[ 2052.114373]  [<ffffffff81461f2a>] start_secondary+0x24d/0x28e
[ 2052.114374] handlers:
[ 2052.114375] [<ffffffff81332944>] (usb_hcd_irq+0x0/0x7c)
[ 2052.114378] [<ffffffffa00697da>] (rt2800pci_interrupt+0x0/0x18d [rt2800pci])
[ 2052.114384] Disabling IRQ #17

Quoted 6 lines

Resolve:
https://bugzilla.redhat.com/show_bug.cgi?id=658451
Reported-and-tested-by Amir Hedayaty <[email protected]>
Cc [email protected]
Signed-off-by Stanislaw Gruszka <[email protected]>

I trust that you saw the comments in the other thread. I have reverted this patch and the related rt2x00 one.

Perhaps there is some way to convince the hardware not to generate spurious interrupts?

John

Signature · 2 lines

John W. Linville		Someday the world will need a hero, and you
[email protected]			might be all we have.  Be ready.

Helmut Schaa · 2011-11-22 22:10 UTC

Am Dienstag, 22. November 2011, 21:33:34 schrieb Michael Basse:

Quoted 1 line

Hopefully your patch is fixing the issues we are facing.

Why do you think the panics are produced by rt2800pci? The stacktraces attached to https://bugs.launchpad.net/ubuntu/+source/linux/+bug/869502
don't show rt2x00 related functions ...

Helmut

Michael Basse · 2011-11-23 06:33 UTC

Am 22.11.2011 23:10, schrieb Helmut Schaa:

Quoted 5 lines

Why do you think the panics are produced by rt2800pci? The stacktraces attached to https://bugs.launchpad.net/ubuntu/+source/linux/+bug/869502
don't show rt2x00 related functions ...
Helmut

Hi Helmut,
i am not sure if the panics are related to rt2800pci. Because of the following facts i thought it was related to that module.

- all systems facing that kind of panics are using rt2800pci
- with the newest compat wifi-drivers that kind of panics are gone
- panics are not happening when wifi is disabled (using fn-key to disable wifi)
- i saw the patch from Stanislaw and thought it will fix the issue because its related to rt2800pci

My problem is that i dont know how to do a better debbuging for that kind of problem, so i was just trying some things around and thought the issues are coming from rt2800pci. But all i am doing at the moment is just guessing, because i am lost with that kind of problem.

Greetings

Michael

Stanislaw Gruszka · 2011-11-23 08:02 UTC

Quoted 27 lines · John W. Linville

Quoted 26 lines · Stanislaw Gruszka

Some devices may generate spurious interrupts, we have to handle them otherwise interrupt line will be disabled with below message and driver will not work:

[ 2052.114334] irq 17: nobody cared (try booting with the "irqpoll" option)
[ 2052.114339] Pid: 0, comm: swapper Tainted: P           2.6.35.6-48.fc14.x86_64 #1
[ 2052.114341] Call Trace:
[ 2052.114342]  <IRQ>  [<ffffffff810a6e2b>] __report_bad_irq.clone.1+0x3d/0x8b
[ 2052.114349]  [<ffffffff810a6f93>] note_interrupt+0x11a/0x17f
[ 2052.114352]  [<ffffffff810a7a73>] handle_fasteoi_irq+0xa8/0xce
[ 2052.114355]  [<ffffffff8100c2ea>] handle_irq+0x88/0x90
[ 2052.114357]  [<ffffffff8146f034>] do_IRQ+0x5c/0xb4
[ 2052.114360]  [<ffffffff81469593>] ret_from_intr+0x0/0x11
[ 2052.114361]  <EOI>  [<ffffffff8102b7f9>] ? native_safe_halt+0xb/0xd
[ 2052.114366]  [<ffffffff81010f03>] ? need_resched+0x23/0x2d
[ 2052.114367]  [<ffffffff8101102a>] default_idle+0x34/0x4f
[ 2052.114370]  [<ffffffff81008325>] cpu_idle+0xaa/0xcc
[ 2052.114373]  [<ffffffff81461f2a>] start_secondary+0x24d/0x28e
[ 2052.114374] handlers:
[ 2052.114375] [<ffffffff81332944>] (usb_hcd_irq+0x0/0x7c)
[ 2052.114378] [<ffffffffa00697da>] (rt2800pci_interrupt+0x0/0x18d [rt2800pci])
[ 2052.114384] Disabling IRQ #17

Resolve:
https://bugzilla.redhat.com/show_bug.cgi?id=658451

Quoted 6 lines

Quoted 3 lines
Reported-and-tested-by Amir Hedayaty <[email protected]>
Cc [email protected]
Signed-off-by Stanislaw Gruszka <[email protected]>
I trust that you saw the comments in the other thread. I have reverted this patch and the related rt2x00 one.

I responded there.

Quoted 2 lines

Perhaps there is some way to convince the hardware not to generate spurious interrupts?

Ivo, Gertjan, Helmut, is there a possibility that I can get hardware documentation or any other support from Ralink, that could help to solve this (and possible other issues)?

Stanislaw

Ivo Van Doorn · 2011-11-23 08:50 UTC

Hi,

Quoted 34 lines · Stanislaw Gruszka

Quoted 27 lines · John W. Linville
Quoted 26 lines · Stanislaw Gruszka
Some devices may generate spurious interrupts, we have to handle them otherwise interrupt line will be disabled with below message and driver will not work:
[ 2052.114334] irq 17: nobody cared (try booting with the "irqpoll" option)
[ 2052.114339] Pid: 0, comm: swapper Tainted: P           2.6.35.6-48.fc14.x86_64 #1
[ 2052.114341] Call Trace:
[ 2052.114342]  <IRQ>  [<ffffffff810a6e2b>] __report_bad_irq.clone.1+0x3d/0x8b
[ 2052.114349]  [<ffffffff810a6f93>] note_interrupt+0x11a/0x17f
[ 2052.114352]  [<ffffffff810a7a73>] handle_fasteoi_irq+0xa8/0xce
[ 2052.114355]  [<ffffffff8100c2ea>] handle_irq+0x88/0x90
[ 2052.114357]  [<ffffffff8146f034>] do_IRQ+0x5c/0xb4
[ 2052.114360]  [<ffffffff81469593>] ret_from_intr+0x0/0x11
[ 2052.114361]  <EOI>  [<ffffffff8102b7f9>] ? native_safe_halt+0xb/0xd
[ 2052.114366]  [<ffffffff81010f03>] ? need_resched+0x23/0x2d
[ 2052.114367]  [<ffffffff8101102a>] default_idle+0x34/0x4f
[ 2052.114370]  [<ffffffff81008325>] cpu_idle+0xaa/0xcc
[ 2052.114373]  [<ffffffff81461f2a>] start_secondary+0x24d/0x28e
[ 2052.114374] handlers:
[ 2052.114375] [<ffffffff81332944>] (usb_hcd_irq+0x0/0x7c)
[ 2052.114378] [<ffffffffa00697da>] (rt2800pci_interrupt+0x0/0x18d [rt2800pci])
[ 2052.114384] Disabling IRQ #17
Resolve:
https://bugzilla.redhat.com/show_bug.cgi?id=658451
Quoted 6 lines
Quoted 3 lines
Reported-and-tested-by Amir Hedayaty <[email protected]>
Cc [email protected]
Signed-off-by Stanislaw Gruszka <[email protected]>
I trust that you saw the comments in the other thread. I have reverted this patch and the related rt2x00 one.

Quoted 8 lines

I responded there.
Quoted 2 lines
Perhaps there is some way to convince the hardware not to generate spurious interrupts?
Ivo, Gertjan, Helmut, is there a possibility that I can get hardware documentation or any other support from Ralink, that could help to solve this (and possible other issues)?

In the rt2x00 project we do have the early draft of the Specsheet for the first 2800pci devices. However this falls in the category of specsheets which is not yet publically published by Ralink, and hence we can't distribute it further.

I've added Eddy Tsai to the recipientlist for this mail, he is the Ralink developer, and he might have a better idea on this issue.

Eddy, we have an issue with rt2860 devices which are generating spurious interrupts,
however how can we determine in our IRQ handler if the rt2860 generated the interrupt and not another device on the same IRQ line?
In the driver released by Ralink the CSR is checked to see if any interrupt bit is set, and if nothing is set IRQ_HANDLED is returned. However this means we can return IRQ_HANDLED when the interrupt was triggered by another device as well.
Is there a way to prevent rt2860 from firing spurious interrupts, or is there a better
way to detect if rt2860 fired the interrupt?

Thanks,

Ivo

Helmut Schaa · 2011-11-23 08:51 UTC

Quoted 8 lines · Stanislaw Gruszka

Quoted 3 lines · John W. Linville
On Wed, Nov 16, 2011 at 11:09:17AM +0100, Stanislaw Gruszka wrote:
Perhaps there is some way to convince the hardware not to generate spurious interrupts?
Ivo, Gertjan, Helmut, is there a possibility that I can get hardware documentation or any other support from Ralink, that could help to solve this (and possible other issues)?

There is sort of documentation for this hardware but not freely available :(

Are we 100% sure that the rt2800pci device is generating the interrupts?

Just a shot in the dark but instead of masking out interrupts we don't handle just enable all device interrupts. Mind to try the below patch?

Helmut

---

(quoted diff) +0 -0

b/drivers/net/wireless/rt2x00/rt2800pci.c
index 4dc2d0f..c0badec 100644

drivers/net/wireless/rt2x00/rt2800pci.c +0 -0

@@ -437,24 +437,24 @@ static void rt2800pci_toggle_irq(struct

rt2x00_dev *rt2x00dev,

spin_lock_irqsave(&rt2x00dev->irqmask_lock, flags); rt2x00pci_register_read(rt2x00dev, INT_MASK_CSR, &reg);
- rt2x00_set_field32(&reg, INT_MASK_CSR_RXDELAYINT, 0);
- rt2x00_set_field32(&reg, INT_MASK_CSR_TXDELAYINT, 0);
+ rt2x00_set_field32(&reg, INT_MASK_CSR_RXDELAYINT, mask);
+ rt2x00_set_field32(&reg, INT_MASK_CSR_TXDELAYINT, mask);
rt2x00_set_field32(&reg, INT_MASK_CSR_RX_DONE, mask);
- rt2x00_set_field32(&reg, INT_MASK_CSR_AC0_DMA_DONE, 0);
- rt2x00_set_field32(&reg, INT_MASK_CSR_AC1_DMA_DONE, 0);
- rt2x00_set_field32(&reg, INT_MASK_CSR_AC2_DMA_DONE, 0);
- rt2x00_set_field32(&reg, INT_MASK_CSR_AC3_DMA_DONE, 0);
- rt2x00_set_field32(&reg, INT_MASK_CSR_HCCA_DMA_DONE, 0);
- rt2x00_set_field32(&reg, INT_MASK_CSR_MGMT_DMA_DONE, 0);
- rt2x00_set_field32(&reg, INT_MASK_CSR_MCU_COMMAND, 0);
- rt2x00_set_field32(&reg, INT_MASK_CSR_RXTX_COHERENT, 0);
+ rt2x00_set_field32(&reg, INT_MASK_CSR_AC0_DMA_DONE, mask);
+ rt2x00_set_field32(&reg, INT_MASK_CSR_AC1_DMA_DONE, mask);
+ rt2x00_set_field32(&reg, INT_MASK_CSR_AC2_DMA_DONE, mask);
+ rt2x00_set_field32(&reg, INT_MASK_CSR_AC3_DMA_DONE, mask);
+ rt2x00_set_field32(&reg, INT_MASK_CSR_HCCA_DMA_DONE, mask);
+ rt2x00_set_field32(&reg, INT_MASK_CSR_MGMT_DMA_DONE, mask);
+ rt2x00_set_field32(&reg, INT_MASK_CSR_MCU_COMMAND, mask);
+ rt2x00_set_field32(&reg, INT_MASK_CSR_RXTX_COHERENT, mask);
rt2x00_set_field32(&reg, INT_MASK_CSR_TBTT, mask); rt2x00_set_field32(&reg, INT_MASK_CSR_PRE_TBTT, mask); rt2x00_set_field32(&reg, INT_MASK_CSR_TX_FIFO_STATUS, mask); rt2x00_set_field32(&reg, INT_MASK_CSR_AUTO_WAKEUP, mask);
- rt2x00_set_field32(&reg, INT_MASK_CSR_GPTIMER, 0);
- rt2x00_set_field32(&reg, INT_MASK_CSR_RX_COHERENT, 0);
- rt2x00_set_field32(&reg, INT_MASK_CSR_TX_COHERENT, 0);
+ rt2x00_set_field32(&reg, INT_MASK_CSR_GPTIMER, mask);
+ rt2x00_set_field32(&reg, INT_MASK_CSR_RX_COHERENT, mask);
+ rt2x00_set_field32(&reg, INT_MASK_CSR_TX_COHERENT, mask);
rt2x00pci_register_write(rt2x00dev, INT_MASK_CSR, reg); spin_unlock_irqrestore(&rt2x00dev->irqmask_lock, flags);

Stanislaw Gruszka · 2011-11-23 10:48 UTC

Quoted 1 line · Helmut Schaa

Are we 100% sure that the rt2800pci device is generating the interrupts?

No, good point. There is also usb_hcd_irq() registered on that line.

I wonder if there is method to control irq routing. I don't know about any that could allow to control assignment of individual irq's. There are nomsi, acpi=noirq and noacpi kernel parameters which influence irq routing, so perhaps with a bit of luck they could cause exclusively Ralink device will be assigned to irq line>

Amir, could you configure system to assure Ralink device have assigned exclusive (non shared) irq line. Interrupts assignment can be seen in /proc/interrupts. If above kernel parameters do not achieve that, you can try disabling USB in BIOS and (if possible) changing pci slot of Ralink device.

Quoted 2 lines

Just a shot in the dark but instead of masking out interrupts we don't handle just enable all device interrupts. Mind to try the below patch?

Amir, the best way is to test it on top of compat wireless, if you will be unable to do this, I'll prepare fedora koji build with patch.

Thanks
Stanislaw

Quoted 44 lines

---

drivers/net/wireless/rt2x00/rt2800pci.c +13 ~~-13~~

index 4dc2d0f..c0badec 100644
@@ -437,24 +437,24 @@ static void rt2800pci_toggle_irq(struct
 rt2x00_dev *rt2x00dev,
 
 	spin_lock_irqsave(&rt2x00dev->irqmask_lock, flags);
 	rt2x00pci_register_read(rt2x00dev, INT_MASK_CSR, &reg);
-	rt2x00_set_field32(&reg, INT_MASK_CSR_RXDELAYINT, 0);
-	rt2x00_set_field32(&reg, INT_MASK_CSR_TXDELAYINT, 0);
+	rt2x00_set_field32(&reg, INT_MASK_CSR_RXDELAYINT, mask);
+	rt2x00_set_field32(&reg, INT_MASK_CSR_TXDELAYINT, mask);
 	rt2x00_set_field32(&reg, INT_MASK_CSR_RX_DONE, mask);
-	rt2x00_set_field32(&reg, INT_MASK_CSR_AC0_DMA_DONE, 0);
-	rt2x00_set_field32(&reg, INT_MASK_CSR_AC1_DMA_DONE, 0);
-	rt2x00_set_field32(&reg, INT_MASK_CSR_AC2_DMA_DONE, 0);
-	rt2x00_set_field32(&reg, INT_MASK_CSR_AC3_DMA_DONE, 0);
-	rt2x00_set_field32(&reg, INT_MASK_CSR_HCCA_DMA_DONE, 0);
-	rt2x00_set_field32(&reg, INT_MASK_CSR_MGMT_DMA_DONE, 0);
-	rt2x00_set_field32(&reg, INT_MASK_CSR_MCU_COMMAND, 0);
-	rt2x00_set_field32(&reg, INT_MASK_CSR_RXTX_COHERENT, 0);
+	rt2x00_set_field32(&reg, INT_MASK_CSR_AC0_DMA_DONE, mask);
+	rt2x00_set_field32(&reg, INT_MASK_CSR_AC1_DMA_DONE, mask);
+	rt2x00_set_field32(&reg, INT_MASK_CSR_AC2_DMA_DONE, mask);
+	rt2x00_set_field32(&reg, INT_MASK_CSR_AC3_DMA_DONE, mask);
+	rt2x00_set_field32(&reg, INT_MASK_CSR_HCCA_DMA_DONE, mask);
+	rt2x00_set_field32(&reg, INT_MASK_CSR_MGMT_DMA_DONE, mask);
+	rt2x00_set_field32(&reg, INT_MASK_CSR_MCU_COMMAND, mask);
+	rt2x00_set_field32(&reg, INT_MASK_CSR_RXTX_COHERENT, mask);
 	rt2x00_set_field32(&reg, INT_MASK_CSR_TBTT, mask);
 	rt2x00_set_field32(&reg, INT_MASK_CSR_PRE_TBTT, mask);
 	rt2x00_set_field32(&reg, INT_MASK_CSR_TX_FIFO_STATUS, mask);
 	rt2x00_set_field32(&reg, INT_MASK_CSR_AUTO_WAKEUP, mask);
-	rt2x00_set_field32(&reg, INT_MASK_CSR_GPTIMER, 0);
-	rt2x00_set_field32(&reg, INT_MASK_CSR_RX_COHERENT, 0);
-	rt2x00_set_field32(&reg, INT_MASK_CSR_TX_COHERENT, 0);
+	rt2x00_set_field32(&reg, INT_MASK_CSR_GPTIMER, mask);
+	rt2x00_set_field32(&reg, INT_MASK_CSR_RX_COHERENT, mask);
+	rt2x00_set_field32(&reg, INT_MASK_CSR_TX_COHERENT, mask);
 	rt2x00pci_register_write(rt2x00dev, INT_MASK_CSR, reg);
 	spin_unlock_irqrestore(&rt2x00dev->irqmask_lock, flags);

Stanislaw Gruszka · 2011-11-23 14:38 UTC

Hi Luis,

(adding CCes again, please keep them next time :-)

Quoted 5 lines · Luis Correia

this suggestion won't really help much, but you could try also booting with the 'irqpoll' option.
This slows down a bit all interrupt processing but can help to investigate situations in where the IRQ lines are really shared.

Thanks, this is a good hint. I think irqpoll option can be used as workaround for the bug.

Stanislaw

Luis Correia · 2011-11-23 14:45 UTC

Hi Stanislaw,

Quoted 3 lines · Stanislaw Gruszka

Hi Luis,
(adding CCes again, please keep them next time :-)

Sorry about the mess, I was in a hurry to leave and really wanted to provide feedback.

Quoted 13 lines · Luis Correia

Quoted 5 lines
this suggestion won't really help much, but you could try also booting with the 'irqpoll' option.
This slows down a bit all interrupt processing but can help to investigate situations in where the IRQ lines are really shared.
Thanks, this is a good hint. I think irqpoll option can be used as workaround for the bug.
Stanislaw

The last time I used it, it really did avoid kernel panic because the two drivers that were sharing the same IRQ line were misbehaving.

Luis Correia

Stanislaw Gruszka · 2011-11-23 15:11 UTC

Amir

Quoted 20 lines · Amir Hedayaty

[amir@amir-client ~]$ cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
  0:        379          0          0         13   IO-APIC-edge      timer
  1:         12          0          0          2   IO-APIC-edge      i8042
  7:          1          0          0          0   IO-APIC-edge
  8:          0          0          0          1   IO-APIC-edge      rtc0
  9:          7          0          0          1   IO-APIC-fasteoi   acpi
 12:         18          0          0          4   IO-APIC-edge      i8042
 14:          0          0          0          0   IO-APIC-edge
pata_atiixp
15: 0 0 0 0 IO-APIC-edge
pata_atiixp
16: 632032 28450 81705 16199 IO-APIC-fasteoi
ohci_hcd:usb3, ohci_hcd:usb4, snd_hda_intel
17: 22153190 140306 13063918 91518105 IO-APIC-fasteoi
ehci_hcd:usb1, 0000:02:00.0
18: 0 0 0 3 IO-APIC-fasteoi
ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7
19: 2076 0 0 0 IO-APIC-fasteoi
ehci_hcd:usb2

Quoted 5 lines

 22:     221936     131775     149195     162901   IO-APIC-fasteoi   ahci
 43:    6097940         40        572     254483   PCI-MSI-edge      radeon
 44:          0          0          0         73   PCI-MSI-edge

snd_hda_intel
45: 0 0 0 1 PCI-MSI-edge em1

I'm seeing rt2800pci anywhere, is module loaded? Anyway, I'm asking you to try to configure your system (by disabling USB in BIOS or kernel options, etc) to force rt2800pci do not share interrupt line. Hence we could see if for spurious interrupts come from rt2800pci, or maybe from some other device, i.e. usb controller.

Quoted 1 line

I have not dealt with interrupts since MSDOS!

Well, problem you are hitting is generally a hardware issue, and we need to find out how deal with that in software. The way this is done in vendor driver (and what I did in my patch) is wrong.

Quoted 2 lines

I think the green line is for
rt2860 device, which seems unique to me.

Hmm, not sure what is green line?

Quoted 5 lines

BTW the (original) patch did not 100% solve the issue (it is a major improvement though) when the issue happens I remove
the module and insert it again and so far after this patch that has not failed.

Quoted 9 lines

About the recent patch, do you mean reverse patching the previous one and patching the new one?
Second I tried applying the patch it gets rejected, here is the situation:
I have build a kernel applying previous patch using rpmbuild sine I do not want to through the long process of building kernel, reversed the previous patch
and tried to apply the recent one. maybe it is being messed up during copy/paste can you attach
that file? The kernel I am trying the patch is 3.1.1-2.

I'll do koji kernel build with the patch, that would be easiest, I'll provide link shortly.

Stanislaw

Stanislaw Gruszka · 2011-11-23 15:42 UTC

Quoted 3 lines · Stanislaw Gruszka

Quoted 3 lines
ohci_hcd:usb3, ohci_hcd:usb4, snd_hda_intel
17: 22153190 140306 13063918 91518105 IO-APIC-fasteoi
ehci_hcd:usb1, 0000:02:00.0

[snip]

Quoted 1 line

I'm seeing rt2800pci anywhere, is module loaded?

It must be 0000:02:00.0 entry, lscpi can be used to confirm that.

Stanislaw

Michael Basse · 2011-11-23 15:51 UTC

Hi

Am 23.11.2011 08:35, schrieb Stanislaw Gruszka:

Quoted 5 lines

Hi
I do not think my patch fix this problem, but perhaps Gertjan's patch do this:

Quoted 8 lines

http://marc.info/?l=linux-wireless&m=132112188308082&w=2
Note, if you are hitting the same issue, what is fixed by this patch, it's enough to do "iwconfig wlan0 power off" to workaround the problem. So you can avoid applying the patch, and just use above command and check if issue is still reproducible.
Stanislaw

Thank you very much for that feedback. I have posted that informations on the ubuntu-bugtracker. I will do some testing with that workaround and hopefully it is fixing the issue.

Greetings

Michael

Stanislaw Gruszka · 2011-11-23 16:58 UTC

Quoted 2 lines · Stanislaw Gruszka

I'll do koji kernel build with the patch, that would be easiest, I'll provide link shortly.

Is here:
http://koji.fedoraproject.org/koji/taskinfo?taskID=3535123
it still compile, so I hope there will be no errors during compilation.

Stanislaw

David Miller · 2011-11-23 20:49 UTC

From: Stanislaw Gruszka <[email protected]>
Date: Wed, 23 Nov 2011 11:51:07 +0100

Quoted 5 lines · Helmut Schaa

Quoted 1 line
Are we 100% sure that the rt2800pci device is generating the interrupts?
No, good point. There is also usb_hcd_irq() registered on that line.
I wonder if there is method to control irq routing.

The IRQ routing is likely determined by the physical line traces on your motherboard and therefore cannot be changed.