2.6.17-rc6-mm2 - USB issues]

Fwd: Re: Johny Ågotnes 8 participants 25 messages Jun 18, 2006 – Jun 28, 2006

Subsystems (2)

ACPI PCI

lore

Share & tools

lore

Johny Ågotnes

author

2006-06-18 11:39 UTC #0 lore raw

didn't go through due to missing vger. ...

All,

I've now tested the following;

2.6.17-rc6-mm2 with the following patch applied;
---
git-acpi.patch from ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc6/2.6.17-rc6-mm2/broken-out/
---

With no difference to the end-result.

Next I stripped out 802.11 generic support and acx111 drivers from the kernel (including the acpi patches) to check if it clashes, but the same errors occur....

Thirdly, I booted with acpi=off on the command line with two kernels, the stock 2.6.17-rc6-mm2 (no acpi patch and including acx111) and the one including the acpi patch and no acx111, the results were;

acpi_patch;
works a treat, picks up USB devices as expected.

stock;
works a treat, picks up USB devices as expected, and my acx111 card works too :)

Now I'm looking for good suggestions again, this definitely looks like it is related to ACPI, hence the cc' to that list too, as requested by Andrew M.

I'm happy to apply patches / config changes as appropriate and for those who may ask for my .config files, please see;

http://www.agotnes.com/kernelStuff/config-2.6.17-rc6-mm2

http://www.agotnes.com/kernelStuff/config-2.6.17-rc6-mm2git-acpi_patch

Also, I left the output of lspci there for reference;

http://www.agotnes.com/kernelStuff/lspci

Cheers,

:)Johny

Quoted 76 lines · Alan Stern

[Moved to linux-usb-devel in the hope of getting additional help]
Quoted 27 lines · Johny
Alan,
See comments interspersed, thanks for your assistance :)
Quoted 22 lines · Alan Stern
Quoted 1 line · Johny
Is this best suited to this mailing list?
It's appropriate.
Quoted 2 lines
I tried the kernel list with zero responses (so far ;), let me know if there is anywhere else this should go.
...
Quoted 13 lines
Quoted 12 lines · Johny Ågotnes
All,
My USB hub isn't recognised with the latest -mm series, whereas with 2.6.16 vanilla it is picked up & used immediately.
The error I get in dmesg is;
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
usb 1-4: new high speed USB device using ehci_hcd and address 3 ehci_hcd 0000:00:10.3: Unlink after no-IRQ? Controller is probably using the wrong IRQ.
Quoted 5 lines
Quoted 4 lines
That last line is a clue. What interrupt numbers are assigned under 2.6.16? If you unplug the SonyEricsson DCU-11 Cable before booting (and leave it unplugged), what shows up in /proc/interrupts for both versions of the kernel?
See attached, both with the DCU-11 cable disconnected.
From 2.6.16:
CPU0
  0:      16101          XT-PIC  timer
  1:        148          XT-PIC  i8042
  2:          0          XT-PIC  cascade
  7:          0          XT-PIC  parport0
  9:          0          XT-PIC  acpi
 10:        151          XT-PIC  ehci_hcd:usb1, uhci_hcd:usb4
 11:          0          XT-PIC  uhci_hcd:usb2, uhci_hcd:usb3
 12:        138          XT-PIC  i8042
 14:        172          XT-PIC  ide0
 15:       2458          XT-PIC  ide1
NMI: 0 ERR: 0
From 2.6.17:
CPU0
  0:      35651    XT-PIC-level    timer
  1:        129    XT-PIC-level    i8042
  2:          0    XT-PIC-level    cascade
  6:          3    XT-PIC-level    floppy
  7:          0    XT-PIC-level    parport0
  9:          0    XT-PIC-level    acpi
 10:          0    XT-PIC-level    ehci_hcd:usb1, uhci_hcd:usb4
 11:       1940    XT-PIC-level    uhci_hcd:usb2, uhci_hcd:usb3, wlan0
 12:        162    XT-PIC-level    i8042
 14:        171    XT-PIC-level    ide0
 15:       4251    XT-PIC-level    ide1
NMI: 0 ERR: 0
There's nothing obviously wrong.
Quoted 3 lines
Quoted 2 lines
Most likely this is a problem with the ACPI subsystem, not a USB problem.
I guessed USB due to the number of USB changes in the -mm series and, obviously, my USB devices stopped registering, however, I'd not know one from the other ;)
What happens if you boot with "acpi=off" on the boot command line?
Alan Stern

Johny

2006-06-20 11:21 UTC #1 lore raw

Firstly, apologies for a) the massive x-post and b) the time taken to get back to people... Please let me know where this is most appropriately dealt with and I'll keep it off other lists, considering the latest information;

Andrew - please note - this is not a problem exclusive to the -mm series, on testing various combos I found it in the stock series too.

Stock kernels break for me starting with 2.6.17-rc4 (I tested all rcs and also .17 itself), rc3 works a treat for using USB. I suspect the following line missing in dmesg for rc4 is the reason;

-PCI: Via IRQ fixup for 0000:00:11.1, from 255 to 11

See the following dmesg files for details;

http://www.agotnes.com/kernelStuff/dmesg-2.6.17-rc3-working
http://www.agotnes.com/kernelStuff/dmesg-2.6.17-rc4-not-working

And the diff, for convenience;

http://www.agotnes.com/kernelStuff/diff-rc3_rc4

I have a Via chipset motherboard (for my sins), further details available on request, again, for convenience, the lspci;

http://www.agotnes.com/kernelStuff/lspci

A couple of possible suspect patches introduced in the changelog for rc4 were (with the first one looking particularly interesting, the others less interesting as I go down the list);

[PATCH] PCI quirk: VIA IRQ fixup should only run for VIA southbridges [PATCH] x86_64: avoid IRQ0 ioapic pin collision
[PATCH] PCI: fix via irq SATA patch
[ALSA] via82xx - Use DXS_SRC as default for VIA8235/8237/8251 chips [ALSA] via82xx: tweak VT8251 workaround
[ALSA] via82xx: add support for VIA VT8251 (AC'97)

I'm no kernel hacker, so I'm not sure how I'd isolate this one patch and reverse / modify it. Please let me know how I can progress testing this as I'm currently prevented from using USB with the latest set of kernels on my test server...

I've got all kernels in the 2.6.17-rc1 through to .17 itself there, plus a variety of mm ones too, so patches against any of those I can very easily test.

Please keep me cc'd as I'm not on all these lists, thanks :)

:)Johny

Quoted 52 lines · Johny Ågotnes

didn't go through due to missing vger. ...
------------------------------------------------------------------------
Subject:
Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues From:
Johny <[email protected]>
Date:
Sun, 18 Jun 2006 21:37:00 +1000
To:
Alan Stern <[email protected]>
To:
Alan Stern <[email protected]>
CC:
Johny <[email protected]>, USB development list <[email protected]>, kernel list <[email protected]>, [email protected], [email protected]
All,
I've now tested the following;
2.6.17-rc6-mm2 with the following patch applied;
---
git-acpi.patch from ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc6/2.6.17-rc6-mm2/broken-out/
---
With no difference to the end-result.
Next I stripped out 802.11 generic support and acx111 drivers from the kernel (including the acpi patches) to check if it clashes, but the same errors occur....
Thirdly, I booted with acpi=off on the command line with two kernels, the stock 2.6.17-rc6-mm2 (no acpi patch and including acx111) and the one including the acpi patch and no acx111, the results were;
acpi_patch;
works a treat, picks up USB devices as expected.
stock;
works a treat, picks up USB devices as expected, and my acx111 card works too :)
Now I'm looking for good suggestions again, this definitely looks like it is related to ACPI, hence the cc' to that list too, as requested by Andrew M.
I'm happy to apply patches / config changes as appropriate and for those who may ask for my .config files, please see;
http://www.agotnes.com/kernelStuff/config-2.6.17-rc6-mm2
http://www.agotnes.com/kernelStuff/config-2.6.17-rc6-mm2git-acpi_patch
Also, I left the output of lspci there for reference;

Quoted 81 lines

http://www.agotnes.com/kernelStuff/lspci
Cheers,
:)Johny
Quoted 74 lines · Alan Stern
[Moved to linux-usb-devel in the hope of getting additional help]
Quoted 27 lines · Johny
Alan,
See comments interspersed, thanks for your assistance :)
Quoted 22 lines · Alan Stern
Quoted 1 line · Johny
Is this best suited to this mailing list?
It's appropriate.
Quoted 2 lines
I tried the kernel list with zero responses (so far ;), let me know if there is anywhere else this should go.
...
Quoted 13 lines
Quoted 12 lines · Johny Ågotnes
All,
My USB hub isn't recognised with the latest -mm series, whereas with 2.6.16 vanilla it is picked up & used immediately.
The error I get in dmesg is;
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
usb 1-4: new high speed USB device using ehci_hcd and address 3 ehci_hcd 0000:00:10.3: Unlink after no-IRQ? Controller is probably using the wrong IRQ.
Quoted 5 lines
Quoted 4 lines
That last line is a clue. What interrupt numbers are assigned under 2.6.16? If you unplug the SonyEricsson DCU-11 Cable before booting (and leave it unplugged), what shows up in /proc/interrupts for both versions of the kernel?
See attached, both with the DCU-11 cable disconnected.
From 2.6.16:
CPU0 0: 16101 XT-PIC timer
  1:        148          XT-PIC  i8042
  2:          0          XT-PIC  cascade
  7:          0          XT-PIC  parport0
  9:          0          XT-PIC  acpi
 10:        151          XT-PIC  ehci_hcd:usb1, uhci_hcd:usb4
 11:          0          XT-PIC  uhci_hcd:usb2, uhci_hcd:usb3
 12:        138          XT-PIC  i8042
 14:        172          XT-PIC  ide0
 15:       2458          XT-PIC  ide1
NMI: 0 ERR: 0
From 2.6.17:
CPU0 0: 35651 XT-PIC-level timer
  1:        129    XT-PIC-level    i8042
  2:          0    XT-PIC-level    cascade
  6:          3    XT-PIC-level    floppy
  7:          0    XT-PIC-level    parport0
  9:          0    XT-PIC-level    acpi
 10:          0    XT-PIC-level    ehci_hcd:usb1, uhci_hcd:usb4
 11:       1940    XT-PIC-level    uhci_hcd:usb2, uhci_hcd:usb3, wlan0
 12:        162    XT-PIC-level    i8042
 14:        171    XT-PIC-level    ide0
 15:       4251    XT-PIC-level    ide1
NMI: 0 ERR: 0
There's nothing obviously wrong.
Quoted 3 lines
Quoted 2 lines
Most likely this is a problem with the ACPI subsystem, not a USB problem.
I guessed USB due to the number of USB changes in the -mm series and, obviously, my USB devices stopped registering, however, I'd not know one from the other ;)
What happens if you boot with "acpi=off" on the boot command line?
Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Andrew Morton

Acked-by Jeff Garzik

2006-06-20 11:40 UTC #2 lore raw

Quoted 7 lines · On Tue, 20 Jun 2006 21:21:35 +1000 Johny <[email protected]> wrote:

Firstly, apologies for a) the massive x-post and b) the time taken to get back to people... Please let me know where this is most appropriately dealt with and I'll keep it off other lists, considering the latest information;
Andrew - please note - this is not a problem exclusive to the -mm series, on testing various combos I found it in the stock series too.

Thanks for persisting with this.

Quoted 5 lines

Stock kernels break for me starting with 2.6.17-rc4 (I tested all rcs and also .17 itself), rc3 works a treat for using USB. I suspect the following line missing in dmesg for rc4 is the reason;
-PCI: Via IRQ fixup for 0000:00:11.1, from 255 to 11

yes, that looks suspicious.

Quoted 12 lines

See the following dmesg files for details;
http://www.agotnes.com/kernelStuff/dmesg-2.6.17-rc3-working
http://www.agotnes.com/kernelStuff/dmesg-2.6.17-rc4-not-working
And the diff, for convenience;
http://www.agotnes.com/kernelStuff/diff-rc3_rc4
I have a Via chipset motherboard (for my sins), further details available on request, again, for convenience, the lspci;

Quoted 7 lines

http://www.agotnes.com/kernelStuff/lspci
A couple of possible suspect patches introduced in the changelog for rc4 were (with the first one looking particularly interesting, the others less interesting as I go down the list);
[PATCH] PCI quirk: VIA IRQ fixup should only run for VIA southbridges

This one, I'd expect.

Quoted 6 lines

[PATCH] x86_64: avoid IRQ0 ioapic pin collision
[PATCH] PCI: fix via irq SATA patch
[ALSA] via82xx - Use DXS_SRC as default for VIA8235/8237/8251 chips [ALSA] via82xx: tweak VT8251 workaround
[ALSA] via82xx: add support for VIA VT8251 (AC'97)

You could try a `patch -R' of the below.

commit 75cf7456dd87335f574dcd53c4ae616a2ad71a11

Author: Chris Wedgwood <[email protected]>
Date:   Tue Apr 18 23:57:09 2006 -0700

[PATCH] PCI quirk: VIA IRQ fixup should only run for VIA southbridges

Alan Cox pointed out that the VIA 'IRQ fixup' was erroneously running on my system which has no VIA southbridge (but I do have a VIA IEEE 1394 device).

This should address that. I also changed "Via IRQ" to "VIA IRQ" (initially I read Via as a capitalized via (by way/means of).

Signed-off-by Chris Wedgwood <[email protected]>

Acked-by Jeff Garzik <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

drivers/pci/quirks.c +4 -2

index c42ae2c..19e2b17 100644
@@ -642,13 +642,15 @@ static void quirk_via_irq(struct pci_dev
 	new_irq = dev->irq & 0xf;
 	pci_read_config_byte(dev, PCI_INTERRUPT_LINE, &irq);
 	if (new_irq != irq) {
-		printk(KERN_INFO "PCI: Via IRQ fixup for %s, from %d to %d\n",
+		printk(KERN_INFO "PCI: VIA IRQ fixup for %s, from %d to %d\n",
 			pci_name(dev), irq, new_irq);
 		udelay(15);	/* unknown if delay really needed */
 		pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
 	}
 }
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686, quirk_via_irq);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_4, quirk_via_irq);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_5, quirk_via_irq);
 
 /*
  * VIA VT82C598 has its device ID settable and many BIOSes

If you have trouble getting it to apply, just manually replace all the DECLARE_PCI_FIXUP_ENABLE lines at the end of quirk_via_irq() with the single line

DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq);

Sergio Monteiro Basto

2006-06-20 13:22 UTC #3 lore raw

Hi,

In first thread of this issue in LKML, some months ago, (right now, I don't have the link).
After some discussion, someone arrive the conclusion of that:
You only need this quirks, if interrupts are in XT-PIC mode and is harmless if don't (and "should only run for VIA southbridges"). So if you are in XT-PIC mode, it is more probability that patch -R in question, have some affect.
cat /proc/interrupts
give you: IO-APIC-... or XT-PIC ?

and what PCI_IDs do you have ? (lspci -n)

Other issue, you can't revert this patch cleanly because after that we have other patch that adds some more IDs. So just delete any declare of PCI_DEVICE_ID_VIA_82C... and add one declare with PCI_ANY_ID

Thanks,
Sérgio M. B.

Quoted 5 lines · Andrew Morton

You could try a `patch -R' of the below.
commit 75cf7456dd87335f574dcd53c4ae616a2ad71a11
Author: Chris Wedgwood <[email protected]>
Date:   Tue Apr 18 23:57:09 2006 -0700 

-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Johny

2006-06-21 10:50 UTC #4 lore raw

In reply to Andrew Morton

Andrew,

Success :)

I've attached the patches used vs 2.6.17-rc4 (stock) and 2.6.17-rc6-mm2 (as the VIA include lists were different). I simply made the change manually, based on your and others' inputs (it seemed the simpler option).

Both kernels now boot, and all USB devices are recognised correctly.

Sergio, you can find attached lspci -n output as requested, and indeed, I run in XT_PIC mode for interrupts.

I did NOT run the setpci command as requested by Sergey, let me know if that helps anyone considering the fix sorted this out.

Where to from here I'll leave with you guys, an entry in the quirks.c file certainly is warranted for my motherboard...

I'm happy to test further patches if required on this, for now I'm on rc6-mm2 with my attached patch to have both ACX111 networking and USB working good :)

Cheers!

:)Johny

Quoted 84 lines · Andrew Morton

Quoted 3 lines · On Tue, 20 Jun 2006 21:21:35 +1000 Johny <[email protected]> wrote:
Firstly, apologies for a) the massive x-post and b) the time taken to get back to people... Please let me know where this is most appropriately dealt with and I'll keep it off other lists, considering the latest information;
Andrew - please note - this is not a problem exclusive to the -mm series, on testing various combos I found it in the stock series too.
Thanks for persisting with this.
Quoted 3 lines
Stock kernels break for me starting with 2.6.17-rc4 (I tested all rcs and also .17 itself), rc3 works a treat for using USB. I suspect the following line missing in dmesg for rc4 is the reason;
-PCI: Via IRQ fixup for 0000:00:11.1, from 255 to 11
yes, that looks suspicious.
Quoted 9 lines
See the following dmesg files for details;
http://www.agotnes.com/kernelStuff/dmesg-2.6.17-rc3-working
http://www.agotnes.com/kernelStuff/dmesg-2.6.17-rc4-not-working
And the diff, for convenience;
http://www.agotnes.com/kernelStuff/diff-rc3_rc4
Quoted 7 lines
I have a Via chipset motherboard (for my sins), further details available on request, again, for convenience, the lspci;
http://www.agotnes.com/kernelStuff/lspci
A couple of possible suspect patches introduced in the changelog for rc4 were (with the first one looking particularly interesting, the others less interesting as I go down the list);
[PATCH] PCI quirk: VIA IRQ fixup should only run for VIA southbridges
This one, I'd expect.
Quoted 6 lines
[PATCH] x86_64: avoid IRQ0 ioapic pin collision
[PATCH] PCI: fix via irq SATA patch
[ALSA] via82xx - Use DXS_SRC as default for VIA8235/8237/8251 chips [ALSA] via82xx: tweak VT8251 workaround
[ALSA] via82xx: add support for VIA VT8251 (AC'97)
You could try a `patch -R' of the below.
commit 75cf7456dd87335f574dcd53c4ae616a2ad71a11
Author: Chris Wedgwood <[email protected]>
Date:   Tue Apr 18 23:57:09 2006 -0700
[PATCH] PCI quirk: VIA IRQ fixup should only run for VIA southbridges
Alan Cox pointed out that the VIA 'IRQ fixup' was erroneously running on my system which has no VIA southbridge (but I do have a VIA IEEE 1394 device).
This should address that. I also changed "Via IRQ" to "VIA IRQ" (initially I read Via as a capitalized via (by way/means of).
Signed-off-by Chris Wedgwood <[email protected]>
Acked-by Jeff Garzik <[email protected]>
Signed-off-by Greg Kroah-Hartman <[email protected]>
drivers/pci/quirks.c +4 -2
index c42ae2c..19e2b17 100644
@@ -642,13 +642,15 @@ static void quirk_via_irq(struct pci_dev
 	new_irq = dev->irq & 0xf;
 	pci_read_config_byte(dev, PCI_INTERRUPT_LINE, &irq);
 	if (new_irq != irq) {
-		printk(KERN_INFO "PCI: Via IRQ fixup for %s, from %d to %d\n",
+		printk(KERN_INFO "PCI: VIA IRQ fixup for %s, from %d to %d\n",
 			pci_name(dev), irq, new_irq);
 		udelay(15);	/* unknown if delay really needed */
 		pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
 	}
 }
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686, quirk_via_irq);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_4, quirk_via_irq);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_5, quirk_via_irq);
 
 /*
  * VIA VT82C598 has its device ID settable and many BIOSes

Quoted 6 lines

If you have trouble getting it to apply, just manually replace all the DECLARE_PCI_FIXUP_ENABLE lines at the end of quirk_via_irq() with the single line
DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq);

drivers/pci/quirks.c +1 -3

@@ -648,9 +648,7 @@
 		pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
 	}
 }
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_4, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_5, quirk_via_irq);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq);
 
 /*
  * VIA VT82C598 has its device ID settable and many BIOSes

drivers/pci/quirks.c +1 -7

@@ -662,13 +662,7 @@
 		pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
 	}
 }
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_0, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_1, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_2, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_3, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_4, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_5, quirk_via_irq);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq);
 
 /*
  * VIA VT82C598 has its device ID settable and many BIOSes

00:00.0 0600: 1106:3205 00:01.0 0604: 1106:b198 00:08.0 0280: 104c:9066 00:10.0 0c03: 1106:3038 (rev 80) 00:10.1 0c03: 1106:3038 (rev 80) 00:10.2 0c03: 1106:3038 (rev 80) 00:10.3 0c03: 1106:3104 (rev 82) 00:11.0 0601: 1106:3177 00:11.1 0101: 1106:0571 (rev 06) 00:11.5 0401: 1106:3059 (rev 50) 00:12.0 0200: 1106:3065 (rev 74) 01:00.0 0300: 1106:7205 (rev 01)

Sergio Monteiro Basto

2006-06-22 00:37 UTC #5 lore raw

who I do know if a interrupt is ioapic_edge_type or ioapic_level_type? [Was Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]]

who I do know if a interrupt is ioapic_edge_type or ioapic_edge_type ?

Quoted 11 lines · Johny

Success :)
I simply made the change
manually, based on your and others' inputs (it seemed the simpler option).
Both kernels now boot, and all USB devices are recognised correctly.
I run in XT_PIC mode for interrupts.

Hi, thanks for your positive test on "my" theory.

Here it goes the link that I talked about on last email
http://lkml.org/lkml/2005/8/18/92 (you can read the previous messages on this thread)

The patch of this link doesn't compile (at least for me), but have a simple idea, which is just quirk the VIA_PCIs if they are in XT_PIC mode and I think that is the way of this quirks should go.

So someone help me out and do a patch that recognize if the interrupt is in XT-PIC mode or not ?

Thanks,

Signature · 1 line

Sérgio M. B.

Randy.Dunlap

2006-06-22 00:45 UTC #6 lore raw

Re: who I do know if a interrupt is ioapic_edge_type or ioapic_level_type? [Was Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]]

Quoted 1 line · On Thu, 22 Jun 2006 01:36:46 +0100 Sergio Monteiro Basto wrote:

who I do know if a interrupt is ioapic_edge_type or ioapic_edge_type ?

Do you mean how they are configured in a running kernel?

cat /proc/interrupts ::

CPU0 CPU1

  0:   12412944   12407808    IO-APIC-edge  timer
  1:     122673     124208    IO-APIC-edge  i8042
  7:          0          0    IO-APIC-edge  parport0
  9:          0          0   IO-APIC-level  acpi
 12:    1141950    1138138    IO-APIC-edge  i8042
 14:    1107749    1109102    IO-APIC-edge  ide0
 58:     451498          0         PCI-MSI  eth0
 66:     530689     495356         PCI-MSI  libata
 74:          0          0   IO-APIC-level  ehci_hcd:usb1, uhci_hcd:usb6
 82:         31          3   IO-APIC-level  ohci_hcd:usb2, ohci_hcd:usb3, ohci_hcd:usb4, ohci_hcd:usb5
 90:        561        492   IO-APIC-level  HDA Intel
169:          3          0   IO-APIC-level  ohci1394
177:          0          0   IO-APIC-level  uhci_hcd:usb8
185:          0          0   IO-APIC-level  uhci_hcd:usb7
193:          0          0   IO-APIC-level  uhci_hcd:usb9

or how they should be configured in case you are not sure? See a hardware spec. for that.

Quoted 19 lines · Johny

Quoted 11 lines
Success :)
I simply made the change
manually, based on your and others' inputs (it seemed the simpler option).
Both kernels now boot, and all USB devices are recognised correctly.
I run in XT_PIC mode for interrupts.
Hi, thanks for your positive test on "my" theory.
Here it goes the link that I talked about on last email
http://lkml.org/lkml/2005/8/18/92 (you can read the previous messages on this thread)

Quoted 11 lines

The patch of this link doesn't compile (at least for me), but have a simple idea, which is just quirk the VIA_PCIs if they are in XT_PIC mode and I think that is the way of this quirks should go.
So someone help me out and do a patch that recognize if the interrupt is in XT-PIC mode or not ?
Thanks,
Signature · 1 line
Sérgio M. B.

---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Sergio Monteiro Basto

2006-06-22 01:05 UTC #7 lore raw

Re: how I know if a interrupt is ioapic_edge_type or ioapic_level_type? [Was Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]]

who no, how sorry! I am a little tired

Quoted 5 lines · Randy.Dunlap

Quoted 1 line · On Thu, 22 Jun 2006 01:36:46 +0100 Sergio Monteiro Basto wrote:
who I do know if a interrupt is ioapic_edge_type or ioapic_edge_type ?
Do you mean how they are configured in a running kernel?

yes, I want to know in
linux-2.6.13/drivers/pci/quirks.c
when I am going quirk the PCI_VIA irq, if this irq is in IO-APIC-something or is in XT-PIC , to decide if I quirk the interrupt or not

Quoted 59 lines

cat /proc/interrupts ::
CPU0 CPU1
  0:   12412944   12407808    IO-APIC-edge  timer
  1:     122673     124208    IO-APIC-edge  i8042
  7:          0          0    IO-APIC-edge  parport0
  9:          0          0   IO-APIC-level  acpi
 12:    1141950    1138138    IO-APIC-edge  i8042
 14:    1107749    1109102    IO-APIC-edge  ide0
 58:     451498          0         PCI-MSI  eth0
 66:     530689     495356         PCI-MSI  libata
 74:          0          0   IO-APIC-level  ehci_hcd:usb1, uhci_hcd:usb6
 82:         31          3   IO-APIC-level  ohci_hcd:usb2, ohci_hcd:usb3, ohci_hcd:usb4, ohci_hcd:usb5
 90:        561        492   IO-APIC-level  HDA Intel
169:          3          0   IO-APIC-level  ohci1394
177:          0          0   IO-APIC-level  uhci_hcd:usb8
185:          0          0   IO-APIC-level  uhci_hcd:usb7
193:          0          0   IO-APIC-level  uhci_hcd:usb9
or how they should be configured in case you are not sure? See a hardware spec. for that.
Quoted 19 lines · Johny
Quoted 11 lines
Success :)
I simply made the change
manually, based on your and others' inputs (it seemed the simpler option).
Both kernels now boot, and all USB devices are recognised correctly.
I run in XT_PIC mode for interrupts.
Hi, thanks for your positive test on "my" theory.
Here it goes the link that I talked about on last email
http://lkml.org/lkml/2005/8/18/92 (you can read the previous messages on this thread)
Quoted 11 lines
The patch of this link doesn't compile (at least for me), but have a simple idea, which is just quirk the VIA_PCIs if they are in XT_PIC mode and I think that is the way of this quirks should go.
So someone help me out and do a patch that recognize if the interrupt is in XT-PIC mode or not ?
Thanks,
Signature · 1 line
Sérgio M. B.
---
~Randy

Randy.Dunlap

2006-06-22 04:05 UTC #8 lore raw

Re: how I know if a interrupt is ioapic_edge_type or ioapic_level_type? [Was Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]]

Quoted 8 lines · On Thu, 22 Jun 2006 02:04:48 +0100 Sergio Monteiro Basto wrote:

who no, how sorry! I am a little tired
Quoted 4 lines · Randy.Dunlap
Quoted 1 line · On Thu, 22 Jun 2006 01:36:46 +0100 Sergio Monteiro Basto wrote:
who I do know if a interrupt is ioapic_edge_type or ioapic_edge_type ?

Quoted 7 lines

Quoted 1 line
Do you mean how they are configured in a running kernel?
yes, I want to know in
linux-2.6.13/drivers/pci/quirks.c
when I am going quirk the PCI_VIA irq, if this irq is in IO-APIC-something or is in XT-PIC , to decide if I quirk the interrupt or not

You have to look all over the place. :(
And I've probably missed some of them.

But if the system if using PICs, they will be XT-PIC. Edge or level triggered is then determined by the bus type:
ISA is mostly edge-triggered (OK, I can't remember that far back) and PCI is defined as level-triggered. However, there are exceptions. IIRC, legacy IDE is edge-triggered even if it is on a PCI bus (see listing below for ide0). And some legacy devices are edge-triggered (timer, keyboard controller/8042, parallel port).

You can find info about specifics in places like Intel chipset specs (ICH5, ICH6, ICH7, etc.), the (large) ACPI spec from www.acpi.info, the Multiprocessor (MP) spec. from developer.intel.com, probably some AMD chipset specs, some PCI bus specs, and in some Linux kernel source code. Like I said, I probably missed a few places.

If you have a specific issue/problem, it would probably be better just to focus on that.

Quoted 47 lines

Quoted 47 lines
cat /proc/interrupts ::
CPU0 CPU1
  0:   12412944   12407808    IO-APIC-edge  timer
  1:     122673     124208    IO-APIC-edge  i8042
  7:          0          0    IO-APIC-edge  parport0
  9:          0          0   IO-APIC-level  acpi
 12:    1141950    1138138    IO-APIC-edge  i8042
 14:    1107749    1109102    IO-APIC-edge  ide0
 58:     451498          0         PCI-MSI  eth0
 66:     530689     495356         PCI-MSI  libata
 74:          0          0   IO-APIC-level  ehci_hcd:usb1, uhci_hcd:usb6
 82:         31          3   IO-APIC-level  ohci_hcd:usb2, ohci_hcd:usb3, ohci_hcd:usb4, ohci_hcd:usb5
 90:        561        492   IO-APIC-level  HDA Intel
169:          3          0   IO-APIC-level  ohci1394
177:          0          0   IO-APIC-level  uhci_hcd:usb8
185:          0          0   IO-APIC-level  uhci_hcd:usb7
193:          0          0   IO-APIC-level  uhci_hcd:usb9
or how they should be configured in case you are not sure? See a hardware spec. for that.
Quoted 23 lines · Johny
Quoted 11 lines
Success :)
I simply made the change
manually, based on your and others' inputs (it seemed the simpler option).
Both kernels now boot, and all USB devices are recognised correctly.
I run in XT_PIC mode for interrupts.
Hi, thanks for your positive test on "my" theory.
Here it goes the link that I talked about on last email
http://lkml.org/lkml/2005/8/18/92 (you can read the previous messages on this thread)
The patch of this link doesn't compile (at least for me), but have a simple idea, which is just quirk the VIA_PCIs if they are in XT_PIC mode and I think that is the way of this quirks should go.

Quoted 6 lines

Quoted 6 lines
Quoted 6 lines
So someone help me out and do a patch that recognize if the interrupt is in XT-PIC mode or not ?
Thanks,
Signature · 1 line
Sérgio M. B.

---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Sergio Monteiro Basto

2006-06-22 11:56 UTC #9 lore raw

Re: how I know if a interrupt is ioapic_edge_type or ioapic_level_type? [Was Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]]

Quoted 3 lines · Randy.Dunlap

If you have a specific issue/problem, it would probably be better just to focus on that.

on linux-2.6.17/drivers/pci/quirks.c

* we must mask the PCI_INTERRUPT_LINE value versus 0xf to get
* interrupts delivered properly.
*/

static void quirk_via_irq(struct pci_dev *dev)
{
u8 irq, new_irq;

I want here put something like: if ( dev->irq != XT-PIC) return and don't quirk this dev.
else

	new_irq = dev->irq & 0xf;

pci_read_config_byte(dev, PCI_INTERRUPT_LINE, &irq);

--
Sérgio M. B.

Randy.Dunlap

2006-06-22 21:26 UTC #10 lore raw

Re: how I know if a interrupt is ioapic_edge_type or ioapic_level_type? [Was Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]]

Quoted 11 lines · On Thu, 22 Jun 2006 12:56:25 +0100 Sergio Monteiro Basto wrote:

Quoted 3 lines · Randy.Dunlap
If you have a specific issue/problem, it would probably be better just to focus on that.
on linux-2.6.17/drivers/pci/quirks.c
* we must mask the PCI_INTERRUPT_LINE value versus 0xf to get
* interrupts delivered properly.
*/

Quoted 6 lines

static void quirk_via_irq(struct pci_dev *dev)
{
u8 irq, new_irq;
I want here put something like: if ( dev->irq != XT-PIC) return and don't quirk this dev.
else

I don't think the interrupt device mode is known by this code (AFAICT with a quick look). The function is only called for certain VIA chipsets.

Do you want the quirk for any particular hardware device? You might be able to look at the function's <dev> parameter to decide on using the quirk or not.

Quoted 2 lines

	new_irq = dev->irq & 0xf;
pci_read_config_byte(dev, PCI_INTERRUPT_LINE, &irq);

---
~Randy

Sergio Monteiro Basto

2006-06-22 22:53 UTC #11 lore raw

Re: how I know if a interrupt is ioapic_edge_type or ioapic_level_type? [Was Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]]

Quoted 20 lines · Randy.Dunlap

Quoted 11 lines · On Thu, 22 Jun 2006 12:56:25 +0100 Sergio Monteiro Basto wrote:
Quoted 3 lines · Randy.Dunlap
If you have a specific issue/problem, it would probably be better just to focus on that.
on linux-2.6.17/drivers/pci/quirks.c
* we must mask the PCI_INTERRUPT_LINE value versus 0xf to get
* interrupts delivered properly.
*/
Quoted 6 lines
static void quirk_via_irq(struct pci_dev *dev)
{
u8 irq, new_irq;
I want here put something like: if ( dev->irq != XT-PIC) return and don't quirk this dev.
else

Quoted 10 lines

I don't think the interrupt device mode is known by this code (AFAICT with a quick look). The function is only called for certain VIA chipsets.
Do you want the quirk for any particular hardware device? You might be able to look at the function's <dev> parameter to decide on using the quirk or not.
Quoted 2 lines
	new_irq = dev->irq & 0xf;
pci_read_config_byte(dev, PCI_INTERRUPT_LINE, &irq);

yap, in my opinion this function should back to

drivers/pci/quirks.c +1 -7

@@ -662,13 +662,7 @@
 		pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
 	}
 }
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_0, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_1, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_2, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_3, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_4, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_5, quirk_via_irq);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq);
 
 /*
  * VIA VT82C598 has its device ID settable and many BIOSes

But do you know or not ? how I know if dev->irq is XT-pic ?

Signature · 1 line

Sérgio M. B.

Randy.Dunlap

2006-06-22 23:22 UTC #12 lore raw

Re: how I know if a interrupt is ioapic_edge_type or ioapic_level_type? [Was Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]]

Quoted 29 lines · On Thu, 22 Jun 2006 23:46:38 +0100 Sergio Monteiro Basto wrote:

Quoted 28 lines · Randy.Dunlap
Quoted 11 lines · On Thu, 22 Jun 2006 12:56:25 +0100 Sergio Monteiro Basto wrote:
Quoted 3 lines · Randy.Dunlap
If you have a specific issue/problem, it would probably be better just to focus on that.
on linux-2.6.17/drivers/pci/quirks.c
* we must mask the PCI_INTERRUPT_LINE value versus 0xf to get
* interrupts delivered properly.
*/
Quoted 6 lines
static void quirk_via_irq(struct pci_dev *dev)
{
u8 irq, new_irq;
I want here put something like: if ( dev->irq != XT-PIC) return and don't quirk this dev.
else
I don't think the interrupt device mode is known by this code (AFAICT with a quick look). The function is only called for certain VIA chipsets.
Do you want the quirk for any particular hardware device? You might be able to look at the function's <dev> parameter to decide on using the quirk or not.

Quoted 4 lines

Quoted 2 lines
Quoted 2 lines
	new_irq = dev->irq & 0xf;
pci_read_config_byte(dev, PCI_INTERRUPT_LINE, &irq);
yap, in my opinion this function should back to

No idea about that.
I think that you still didn't answer my question, or maybe I didn't ask it well enough. What device are you having problems with? I don't mean what chipset, I mean what device that you touch...

Quoted 19 lines

drivers/pci/quirks.c +1 -7

@@ -662,13 +662,7 @@
 		pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
 	}
 }
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_0, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_1, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_2, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_3, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_4, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_5, quirk_via_irq);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq);
 
 /*
  * VIA VT82C598 has its device ID settable and many BIOSes

Quoted 1 line

But do you know or not ? how I know if dev->irq is XT-pic ?

I don't see a way to know that currently. It could be added somehow if it's really required. So far I haven't seen a full problem description or requirement for this.

---
~Randy

Sergio Monteiro Basto

2006-06-23 01:37 UTC #13 lore raw

Re: how I know if a interrupt is ioapic_edge_type or ioapic_level_type? [Was Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]]

Quoted 6 lines · Randy.Dunlap

No idea about that.
I think that you still didn't answer my question, or maybe I didn't ask it well enough. What device are you having problems with? I don't mean what chipset, I mean what device that you touch...

I'd like to give you one answer , but I don't have one problem with one device, I bought (accidentally) one VIA with a Pentium dual-core, which have a bunch of problems.

Quoted 30 lines

drivers/pci/quirks.c 2006-06-21
Quoted 3 lines
drivers/pci/quirks.c 2006-06-21 renamed from drivers/pci/quirks.c 2006-06-21 20:25:41.000000000 +1000 +0 -0
20:25:08.000000000 +1000
drivers/pci/quirks.c 2006-06-21 line 662
Quoted 2 lines
drivers/pci/quirks.c 2006-06-21 renamed from drivers/pci/quirks.c 2006-06-21 20:25:41.000000000 +1000 +0 -0
@@ -662,13 +662,7 @@
              pci_write_config_byte(dev, PCI_INTERRUPT_LINE,
new_irq);
drivers/pci/quirks.c 2006-06-21 line 665
Quoted 3 lines
drivers/pci/quirks.c 2006-06-21 renamed from drivers/pci/quirks.c 2006-06-21 20:25:41.000000000 +1000 +0 -1
      }
 }
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA,
PCI_DEVICE_ID_VIA_82C586_0, quirk_via_irq);
drivers/pci/quirks.c 2006-06-21 line 666
Quoted 1 line
drivers/pci/quirks.c 2006-06-21 renamed from drivers/pci/quirks.c 2006-06-21 20:25:41.000000000 +1000 +0 -1
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA,
PCI_DEVICE_ID_VIA_82C586_1, quirk_via_irq);
drivers/pci/quirks.c 2006-06-21 line 667
Quoted 1 line
drivers/pci/quirks.c 2006-06-21 renamed from drivers/pci/quirks.c 2006-06-21 20:25:41.000000000 +1000 +0 -1
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA,
PCI_DEVICE_ID_VIA_82C586_2, quirk_via_irq);
drivers/pci/quirks.c 2006-06-21 line 668
Quoted 1 line
drivers/pci/quirks.c 2006-06-21 renamed from drivers/pci/quirks.c 2006-06-21 20:25:41.000000000 +1000 +0 -1
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA,
PCI_DEVICE_ID_VIA_82C586_3, quirk_via_irq);
drivers/pci/quirks.c 2006-06-21 line 669
Quoted 1 line
drivers/pci/quirks.c 2006-06-21 renamed from drivers/pci/quirks.c 2006-06-21 20:25:41.000000000 +1000 +0 -1
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA,
PCI_DEVICE_ID_VIA_82C686, quirk_via_irq);
drivers/pci/quirks.c 2006-06-21 line 670
Quoted 1 line
drivers/pci/quirks.c 2006-06-21 renamed from drivers/pci/quirks.c 2006-06-21 20:25:41.000000000 +1000 +0 -1
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA,
PCI_DEVICE_ID_VIA_82C686_4, quirk_via_irq);
drivers/pci/quirks.c 2006-06-21 line 671
Quoted 1 line
drivers/pci/quirks.c 2006-06-21 renamed from drivers/pci/quirks.c 2006-06-21 20:25:41.000000000 +1000 +0 -1
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA,
PCI_DEVICE_ID_VIA_82C686_5, quirk_via_irq);
drivers/pci/quirks.c 2006-06-21 line 665
Quoted 1 line
drivers/pci/quirks.c 2006-06-21 renamed from drivers/pci/quirks.c 2006-06-21 20:25:41.000000000 +1000 +1 -0
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID,
quirk_via_irq);
Quoted 5 lines
drivers/pci/quirks.c 2006-06-21 renamed from drivers/pci/quirks.c 2006-06-21 20:25:41.000000000 +1000 +0 -0
 /*
  * VIA VT82C598 has its device ID settable and many BIOSes
 

Quoted 5 lines

Quoted 1 line
But do you know or not ? how I know if dev->irq is XT-pic ?
I don't see a way to know that currently. It could be added somehow if it's really required. So far I haven't seen a full problem description or requirement for this.

Well, this is based in tests along this 4 years, with my two computers. Like Bjorn said, we don't have any specification of VIA chipsets. But I like to try, use this quirks only if system don't have IO-APICs enabled. Many VIA systems work like that, for example my old laptop.

For me, I know that my old laptop needs the quirks and run with interrupts in XT-PIC, and with my new desktop, I quit sure that don't need the quirks and system runs with interrupts in IO-APIC-edge and IO-APIC-level.

Based in, what I read in this original thread
http://lkml.org/lkml/2005/8/18/92 , seems to me, that we could try this solution, if we have a easy way to know what kind of interrupts have the device.

Thanks Randy for your time,

Signature · 1 line

Sérgio M. B.

Chris Wedgwood

2006-06-22 23:41 UTC #14 lore raw

Re: how I know if a interrupt is ioapic_edge_type or ioapic_level_type? [Was Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]]

In reply to Sergio Monteiro Basto

Quoted 3 lines · Sergio Monteiro Basto

yap, in my opinion this function should back to
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq);

this is *obviousyl* wrong, it should never have been merged like that and there are reports and complaints this causes problems for some people

we should first attempt to get all the IDs (some are clearly missing still, patch coming up to address that) and where that fails perhaps have a kernel command-line parameter to be overly aggressive as a stop-gap until we van figure out the proper solution

i'd also like to figure out why the quirk is needed/fails when people are using ACPI for interrupt routing as presumbly that must work as windows relies on it

Sergio Monteiro Basto

2006-06-23 01:00 UTC #15 lore raw

Re: how I know if a interrupt is ioapic_edge_type or ioapic_level_type? [Was Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]]

Quoted 11 lines · Chris Wedgwood

Quoted 3 lines · Sergio Monteiro Basto
yap, in my opinion this function should back to
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq);
this is *obviousyl* wrong, it should never have been merged like that and there are reports and complaints this causes problems for some people

It was like that in kernel 2.6.16 and previous since, I don't know, 2.6.9 or 2.6.13 ....

Quoted 5 lines

we should first attempt to get all the IDs (some are clearly missing still, patch coming up to address that) and where that fails perhaps have a kernel command-line parameter to be overly aggressive as a stop-gap until we van figure out the proper solution

I believe this quirks is just for VIA system with interrupts in XT-PIC mode (like my old laptop).

Quoted 4 lines

i'd also like to figure out why the quirk is needed/fails when people are using ACPI for interrupt routing as presumbly that must work as windows relies on it

yes, this is other mysterious, why boot with acpi=noirq could be one workaround. But could be other problem more related with usb drives.

Randy.Dunlap

2006-06-23 01:36 UTC #16 lore raw

Re: how I know if a interrupt is ioapic_edge_type or ioapic_level_type? [Was Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]]

Quoted 17 lines · On Fri, 23 Jun 2006 02:00:44 +0100 Sergio Monteiro Basto wrote:

Quoted 11 lines · Chris Wedgwood
Quoted 3 lines · Sergio Monteiro Basto
yap, in my opinion this function should back to
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq);
this is *obviousyl* wrong, it should never have been merged like that and there are reports and complaints this causes problems for some people
It was like that in kernel 2.6.16 and previous since, I don't know, 2.6.9 or 2.6.13 ....
Quoted 1 line

Quoted 7 lines

Quoted 4 lines
we should first attempt to get all the IDs (some are clearly missing still, patch coming up to address that) and where that fails perhaps have a kernel command-line parameter to be overly aggressive as a stop-gap until we van figure out the proper solution
I believe this quirks is just for VIA system with interrupts in XT-PIC mode (like my old laptop).

This sounds like just running with CONFIG_IO_APIC=n or using "noapic" on the kernel boot command line. If that's what is needed, we can know that. I just haven't seen info to know what the real problem is.

Quoted 6 lines

Quoted 3 lines
i'd also like to figure out why the quirk is needed/fails when people are using ACPI for interrupt routing as presumbly that must work as windows relies on it
yes, this is other mysterious, why boot with acpi=noirq could be one workaround. But could be other problem more related with usb drives.

---
~Randy

Sergio Monteiro Basto

2006-06-23 01:50 UTC #17 lore raw

Re: how I know if a interrupt is ioapic_edge_type or ioapic_level_type? [Was Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]]

Quoted 4 lines · Randy.Dunlap

This sounds like just running with CONFIG_IO_APIC=n or using "noapic" on the kernel boot command line. If that's what is needed, we can know that. I just haven't seen info to know what the real problem is.

yes, could be a way, if we know if IO_APIC or LOCAL_APIC is enabled or not ?

thanks,

Signature · 1 line

Sérgio M. B.

Randy.Dunlap

2006-06-23 01:59 UTC #18 lore raw

Re: how I know if a interrupt is ioapic_edge_type or ioapic_level_type? [Was Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]]

Quoted 8 lines · On Fri, 23 Jun 2006 02:50:15 +0100 Sergio Monteiro Basto wrote:

Quoted 4 lines · Randy.Dunlap
This sounds like just running with CONFIG_IO_APIC=n or using "noapic" on the kernel boot command line. If that's what is needed, we can know that. I just haven't seen info to know what the real problem is.
yes, could be a way, if we know if IO_APIC or LOCAL_APIC is enabled or not ?

I don't know of a current flag or state that tells us that, but it could be added.

---
~Randy

Sergio Monteiro Basto

2006-06-28 01:08 UTC #19 lore raw

In reply to Sergio Monteiro Basto

Quoted 10 lines · Sergio Monteiro Basto

Quoted 1 line · Chris Wedgwood
On Thu, Jun 22, 2006 at 11:46:38PM +0100, Sergio Monteiro Basto
Quoted 4 lines · wrote:
Quoted 4 lines
yap, in my opinion this function should back to
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID,
quirk_via_irq);
Quoted 2 lines

Quoted 8 lines

Quoted 1 line
this is *obviousyl* wrong, it should never have been merged like
that
Quoted 3 lines
and there are reports and complaints this causes problems for some people
It was like that in kernel 2.6.16 and previous since, I don't know, 2.6.9 or 2.6.13 ....

Hi, Chris Wedgwood
I found the bugzilla report where the initial version of this function quirk_via_irq (drivers/pci/quirks.c) has been made:
http://bugzilla.kernel.org/show_bug.cgi?id=3319#c28
might be interesting !

Signature · 1 line

Sérgio M. B.

Johny

2006-06-23 01:40 UTC #20 lore raw

Re: how I know if a interrupt is ioapic_edge_type or ioapic_level_type? [Was Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]]

In reply to Chris Wedgwood

Chris,

If you keep me posted on the patch when released (I'm not on the kernel list, too high volume for me) I'll be happy to give your patch a whirl on my test box against whichever kernel you patch.

Your last point is real good, how DOES Windows figure it out? In saying that, without the VIA drivers I only have USB1.1 support on this motherboard... Again, happy to test some theories if you have some tests you'd like ran...

Cheers,

:)Johny

Quoted 19 lines · Chris Wedgwood

Quoted 3 lines · Sergio Monteiro Basto
yap, in my opinion this function should back to
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq);
this is *obviousyl* wrong, it should never have been merged like that and there are reports and complaints this causes problems for some people
we should first attempt to get all the IDs (some are clearly missing still, patch coming up to address that) and where that fails perhaps have a kernel command-line parameter to be overly aggressive as a stop-gap until we van figure out the proper solution
i'd also like to figure out why the quirk is needed/fails when people are using ACPI for interrupt routing as presumbly that must work as windows relies on it

David Brownell

2006-06-23 15:39 UTC #21 lore raw

Re: [linux-usb-devel] who I do know if a interrupt is ioapic_edge_type or ioapic_level_type? [Was Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]]

In reply to Sergio Monteiro Basto

This isn't quite the same as "how to handle the VIA quirks correctly", but it does seem like the IRQ API should probably have a call to get the IRQ trigger mode, just like it has ways to set it. I've seen drivers that need to try multiple trigger modes before they find one that will work on the target platform.

The actual details of _how_ that trigger mode is set -- APIC, PIC and so on for x86; or other IRQ controllers on other hardware -- should not matter to drivers, since they're platform-specific. The quirk handling code is platform-specific though, and might care.

- Dave

Sergey Vlasov

2006-06-20 12:09 UTC #22 lore raw

In reply to Johny

On Tue, Jun 20, 2006 at 09:21:35PM +1000, Johny wrote:
[...]

Quoted 5 lines

Stock kernels break for me starting with 2.6.17-rc4 (I tested all rcs and also .17 itself), rc3 works a treat for using USB. I suspect the following line missing in dmesg for rc4 is the reason;
-PCI: Via IRQ fixup for 0000:00:11.1, from 255 to 11

Well, not exactly this line (0000:00:11.1 is the IDE controller, which is in legacy mode and therefore does not use its PCI interrupt), but the next similar line is for the USB 2.0 (EHCI) controller:

-PCI: Via IRQ fixup for 0000:00:10.3, from 5 to 10

Quoted 8 lines

See the following dmesg files for details;
http://www.agotnes.com/kernelStuff/dmesg-2.6.17-rc3-working
http://www.agotnes.com/kernelStuff/dmesg-2.6.17-rc4-not-working
And the diff, for convenience;
http://www.agotnes.com/kernelStuff/diff-rc3_rc4

Try as root:

	setpci -s 00:10.3 INTERRUPT_LINE=0a

(this matches "ehci_hcd 0000:00:10.3: irq 10, ..." in dmesg).

If after doing this USB works again (you will need to replug USB devices), the missing VIA IRQ quirk is definitely the problem.

Quoted 4 lines

I have a Via chipset motherboard (for my sins), further details available on request, again, for convenience, the lspci;
http://www.agotnes.com/kernelStuff/lspci

You seem to have also the builtin audio and Ethernet on this board - these devices may have the same problem, if you tried to use them.

Quoted 174 lines

A couple of possible suspect patches introduced in the changelog for rc4 were (with the first one looking particularly interesting, the others less interesting as I go down the list);
[PATCH] PCI quirk: VIA IRQ fixup should only run for VIA southbridges [PATCH] x86_64: avoid IRQ0 ioapic pin collision
[PATCH] PCI: fix via irq SATA patch
[ALSA] via82xx - Use DXS_SRC as default for VIA8235/8237/8251 chips [ALSA] via82xx: tweak VT8251 workaround
[ALSA] via82xx: add support for VIA VT8251 (AC'97)
I'm no kernel hacker, so I'm not sure how I'd isolate this one patch and reverse / modify it. Please let me know how I can progress testing this as I'm currently prevented from using USB with the latest set of kernels on my test server...
I've got all kernels in the 2.6.17-rc1 through to .17 itself there, plus a variety of mm ones too, so patches against any of those I can very easily test.
Please keep me cc'd as I'm not on all these lists, thanks :)
:)Johny
Quoted 149 lines · Johny ?gotnes
didn't go through due to missing vger. ...
------------------------------------------------------------------------
Subject:
Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues From:
Johny <[email protected]>
Date:
Sun, 18 Jun 2006 21:37:00 +1000
To:
Alan Stern <[email protected]>
To:
Alan Stern <[email protected]>
CC:
Johny <[email protected]>, USB development list <[email protected]>, kernel list <[email protected]>, [email protected], [email protected]
All,
I've now tested the following;
2.6.17-rc6-mm2 with the following patch applied;
---
git-acpi.patch from ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc6/2.6.17-rc6-mm2/broken-out/
---
With no difference to the end-result.
Next I stripped out 802.11 generic support and acx111 drivers from the kernel (including the acpi patches) to check if it clashes, but the same errors occur....
Thirdly, I booted with acpi=off on the command line with two kernels, the stock 2.6.17-rc6-mm2 (no acpi patch and including acx111) and the one including the acpi patch and no acx111, the results were;
acpi_patch;
works a treat, picks up USB devices as expected.
stock;
works a treat, picks up USB devices as expected, and my acx111 card works too :)
Now I'm looking for good suggestions again, this definitely looks like it is related to ACPI, hence the cc' to that list too, as requested by Andrew M.
I'm happy to apply patches / config changes as appropriate and for those who may ask for my .config files, please see;
http://www.agotnes.com/kernelStuff/config-2.6.17-rc6-mm2
http://www.agotnes.com/kernelStuff/config-2.6.17-rc6-mm2git-acpi_patch
Also, I left the output of lspci there for reference;
http://www.agotnes.com/kernelStuff/lspci
Cheers,
:)Johny
Quoted 79 lines · Alan Stern
[Moved to linux-usb-devel in the hope of getting additional help]
Quoted 28 lines · Johny
Alan,
See comments interspersed, thanks for your assistance :)
Quoted 23 lines · Alan Stern
Quoted 1 line · Johny
Is this best suited to this mailing list?
It's appropriate.
Quoted 3 lines
I tried the kernel list with zero responses (so far ;), let me know if there is
anywhere else this should go.
...
Quoted 13 lines
Quoted 12 lines · Johny ?gotnes
All,
My USB hub isn't recognised with the latest -mm series, whereas with 2.6.16 vanilla it is picked up & used immediately.
The error I get in dmesg is;
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
usb 1-4: new high speed USB device using ehci_hcd and address 3 ehci_hcd 0000:00:10.3: Unlink after no-IRQ? Controller is probably using the wrong IRQ.
Quoted 7 lines
Quoted 6 lines
That last line is a clue. What interrupt numbers are assigned under 2.6.16? If you unplug the SonyEricsson DCU-11 Cable before booting (and
leave it unplugged), what shows up in /proc/interrupts for both versions
of the kernel?
See attached, both with the DCU-11 cable disconnected.
From 2.6.16:
CPU0 0: 16101 XT-PIC timer
  1:        148          XT-PIC  i8042
  2:          0          XT-PIC  cascade
  7:          0          XT-PIC  parport0
  9:          0          XT-PIC  acpi
 10:        151          XT-PIC  ehci_hcd:usb1, uhci_hcd:usb4
 11:          0          XT-PIC  uhci_hcd:usb2, uhci_hcd:usb3
 12:        138          XT-PIC  i8042
 14:        172          XT-PIC  ide0
 15:       2458          XT-PIC  ide1
NMI: 0 ERR: 0
From 2.6.17:
CPU0 0: 35651 XT-PIC-level timer
  1:        129    XT-PIC-level    i8042
  2:          0    XT-PIC-level    cascade
  6:          3    XT-PIC-level    floppy
  7:          0    XT-PIC-level    parport0
  9:          0    XT-PIC-level    acpi
 10:          0    XT-PIC-level    ehci_hcd:usb1, uhci_hcd:usb4
 11:       1940    XT-PIC-level    uhci_hcd:usb2, uhci_hcd:usb3, wlan0
 12:        162    XT-PIC-level    i8042
 14:        171    XT-PIC-level    ide0
 15:       4251    XT-PIC-level    ide1
NMI: 0 ERR: 0
There's nothing obviously wrong.
Quoted 6 lines
Quoted 3 lines
Most likely this is a problem with the ACPI subsystem, not a USB problem.
I guessed USB due to the number of USB changes in the -mm series and, obviously, my USB devices stopped registering, however, I'd not know one from the other ;)
What happens if you boot with "acpi=off" on the boot command line?
Alan Stern

Sergio Monteiro Basto

2006-06-20 13:30 UTC #23 lore raw

someone has it has a case similar and said that won't work without acpi=noirq

http://bugzilla.kernel.org/show_bug.cgi?id=6654

Quoted 32 lines · Sergey Vlasov

On Tue, Jun 20, 2006 at 09:21:35PM +1000, Johny wrote:
[...]
Quoted 5 lines
Stock kernels break for me starting with 2.6.17-rc4 (I tested all rcs and also .17 itself), rc3 works a treat for using USB. I suspect the following line missing in dmesg for rc4 is the reason;
-PCI: Via IRQ fixup for 0000:00:11.1, from 255 to 11
Well, not exactly this line (0000:00:11.1 is the IDE controller, which is in legacy mode and therefore does not use its PCI interrupt), but the next similar line is for the USB 2.0 (EHCI) controller:
-PCI: Via IRQ fixup for 0000:00:10.3, from 5 to 10
Quoted 8 lines
See the following dmesg files for details;
http://www.agotnes.com/kernelStuff/dmesg-2.6.17-rc3-working
http://www.agotnes.com/kernelStuff/dmesg-2.6.17-rc4-not-working
And the diff, for convenience;
http://www.agotnes.com/kernelStuff/diff-rc3_rc4
Try as root:
	setpci -s 00:10.3 INTERRUPT_LINE=0a
(this matches "ehci_hcd 0000:00:10.3: irq 10, ..." in dmesg).
If after doing this USB works again (you will need to replug USB devices), the missing VIA IRQ quirk is definitely the problem.

Quoted 182 lines

Quoted 4 lines
I have a Via chipset motherboard (for my sins), further details available on request, again, for convenience, the lspci;
http://www.agotnes.com/kernelStuff/lspci
You seem to have also the builtin audio and Ethernet on this board - these devices may have the same problem, if you tried to use them.
Quoted 174 lines
A couple of possible suspect patches introduced in the changelog for rc4 were (with the first one looking particularly interesting, the others less interesting as I go down the list);
[PATCH] PCI quirk: VIA IRQ fixup should only run for VIA southbridges [PATCH] x86_64: avoid IRQ0 ioapic pin collision
[PATCH] PCI: fix via irq SATA patch
[ALSA] via82xx - Use DXS_SRC as default for VIA8235/8237/8251 chips [ALSA] via82xx: tweak VT8251 workaround
[ALSA] via82xx: add support for VIA VT8251 (AC'97)
I'm no kernel hacker, so I'm not sure how I'd isolate this one patch and reverse / modify it. Please let me know how I can progress testing this as I'm currently prevented from using USB with the latest set of kernels on my test server...
I've got all kernels in the 2.6.17-rc1 through to .17 itself there, plus a variety of mm ones too, so patches against any of those I can very easily test.
Please keep me cc'd as I'm not on all these lists, thanks :)
:)Johny
Quoted 149 lines · Johny ?gotnes
didn't go through due to missing vger. ...
------------------------------------------------------------------------
Subject:
Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues From:
Johny <[email protected]>
Date:
Sun, 18 Jun 2006 21:37:00 +1000
To:
Alan Stern <[email protected]>
To:
Alan Stern <[email protected]>
CC:
Johny <[email protected]>, USB development list <[email protected]>, kernel list <[email protected]>, [email protected], [email protected]
All,
I've now tested the following;
2.6.17-rc6-mm2 with the following patch applied;
---
git-acpi.patch from ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc6/2.6.17-rc6-mm2/broken-out/
---
With no difference to the end-result.
Next I stripped out 802.11 generic support and acx111 drivers from the kernel (including the acpi patches) to check if it clashes, but the same errors occur....
Thirdly, I booted with acpi=off on the command line with two kernels, the stock 2.6.17-rc6-mm2 (no acpi patch and including acx111) and the one including the acpi patch and no acx111, the results were;
acpi_patch;
works a treat, picks up USB devices as expected.
stock;
works a treat, picks up USB devices as expected, and my acx111 card works too :)
Now I'm looking for good suggestions again, this definitely looks like it is related to ACPI, hence the cc' to that list too, as requested by Andrew M.
I'm happy to apply patches / config changes as appropriate and for those who may ask for my .config files, please see;
http://www.agotnes.com/kernelStuff/config-2.6.17-rc6-mm2
http://www.agotnes.com/kernelStuff/config-2.6.17-rc6-mm2git-acpi_patch
Also, I left the output of lspci there for reference;
http://www.agotnes.com/kernelStuff/lspci
Cheers,
:)Johny
Quoted 79 lines · Alan Stern
[Moved to linux-usb-devel in the hope of getting additional help]
Quoted 28 lines · Johny
Alan,
See comments interspersed, thanks for your assistance :)
Quoted 23 lines · Alan Stern
Quoted 1 line · Johny
Is this best suited to this mailing list?
It's appropriate.
Quoted 3 lines
I tried the kernel list with zero responses (so far ;), let me know if there is
anywhere else this should go.
...
Quoted 13 lines
Quoted 12 lines · Johny ?gotnes
All,
My USB hub isn't recognised with the latest -mm series, whereas with 2.6.16 vanilla it is picked up & used immediately.
The error I get in dmesg is;
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
usb 1-4: new high speed USB device using ehci_hcd and address 3 ehci_hcd 0000:00:10.3: Unlink after no-IRQ? Controller is probably using the wrong IRQ.
Quoted 7 lines
Quoted 6 lines
That last line is a clue. What interrupt numbers are assigned under 2.6.16? If you unplug the SonyEricsson DCU-11 Cable before booting (and
leave it unplugged), what shows up in /proc/interrupts for both versions
of the kernel?
See attached, both with the DCU-11 cable disconnected.
From 2.6.16:
CPU0 0: 16101 XT-PIC timer
  1:        148          XT-PIC  i8042
  2:          0          XT-PIC  cascade
  7:          0          XT-PIC  parport0
  9:          0          XT-PIC  acpi
 10:        151          XT-PIC  ehci_hcd:usb1, uhci_hcd:usb4
 11:          0          XT-PIC  uhci_hcd:usb2, uhci_hcd:usb3
 12:        138          XT-PIC  i8042
 14:        172          XT-PIC  ide0
 15:       2458          XT-PIC  ide1
NMI: 0 ERR: 0
From 2.6.17:
CPU0 0: 35651 XT-PIC-level timer
  1:        129    XT-PIC-level    i8042
  2:          0    XT-PIC-level    cascade
  6:          3    XT-PIC-level    floppy
  7:          0    XT-PIC-level    parport0
  9:          0    XT-PIC-level    acpi
 10:          0    XT-PIC-level    ehci_hcd:usb1, uhci_hcd:usb4
 11:       1940    XT-PIC-level    uhci_hcd:usb2, uhci_hcd:usb3, wlan0
 12:        162    XT-PIC-level    i8042
 14:        171    XT-PIC-level    ide0
 15:       4251    XT-PIC-level    ide1
NMI: 0 ERR: 0
There's nothing obviously wrong.
Quoted 6 lines
Quoted 3 lines
Most likely this is a problem with the ACPI subsystem, not a USB problem.
I guessed USB due to the number of USB changes in the -mm series and, obviously, my USB devices stopped registering, however, I'd not know one from the other ;)
What happens if you boot with "acpi=off" on the boot command line?
Alan Stern

_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Sergey Vlasov

2006-06-20 13:59 UTC #24 lore raw

Quoted 4 lines · Sergio Monteiro Basto

someone has it has a case similar and said that won't work without acpi=noirq
http://bugzilla.kernel.org/show_bug.cgi?id=6654

Yes, acpi=noirq will work around this bug in many cases, because Linux will not try to reassign IRQs set up by BIOS.

BTW, the problem may be considered as an ACPI BIOS bug, because reconfiguring a PCI Interrupt Link should set up IRQ routing, but it obviously does not. Unfortunately, this problem seems to be widespread, so a workaround in kernel is needed.

_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel