The most recent VIA IRQ quirk changes have broken various VIA devices for
some users. We are not able to add these devices to the blacklist as they
are also available in PCI-card form, and running the quirk on these devices
brings us back to square one (running the VIA quirk on non-VIA boards where
the quirk is not needed).
This patch, based on suggestions from Sergey Vlasov, implements a scheme
similar to but more restrictive than the scheme we had in 2.6.16 and
earlier. It runs the quirk on all VIA hardware, but *only* if a VIA
southbridge was detected on the system.
To further reduce the amount of quirked devices, this patch includes a change
suggested by Linus at http://lkml.org/lkml/2005/9/27/113
This ensures that devices bound to non-legacy IO-APIC interrupt lines are
not quirked. We have made one change to Linus' suggestion: we do a comparison
of ">15" rather than ">=15", as 15 is still in the legacy interrupt range.
There is still a downside to this patch: if the user inserts a VIA PCI card
into a VIA-based motherboard, in some circumstances the quirk will also run on
the VIA PCI card. This corner case is hard to avoid.
Signed-off-by: Daniel Drake <[email protected]>
---
Andrew, please replace the current -mm patch with this one. The general idea
is that we *consider* applying the quirk to a lot more devices than we currently
do (more comparable to 2.6.16 and previous), but we add various bail-out
conditions to actually end up applying the quirks much less.
I am fairly confident that we'll still be quirking enough hardware to not
cause any breakage, but we can't be sure until it has seen some testing. This
is compile-tested only.
Index: linux/drivers/pci/quirks.c
===================================================================
--- linux.orig/drivers/pci/quirks.c
+++ linux/drivers/pci/quirks.c
@@ -650,11 +650,43 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_V
* Some of the on-chip devices are actually '586 devices' so they are
* listed here.
*/
+
+static int via_irq_fixup_needed = -1;
+
+/*
+ * As some VIA hardware is available in PCI-card form, we need to restrict
+ * this quirk to VIA PCI hardware built onto VIA-based motherboards only.
+ * We try to locate a VIA southbridge before deciding whether the quirk
+ * should be applied.
+ */
+static const struct pci_device_id via_irq_fixup_tbl[] = {
+ {
+ .vendor = PCI_VENDOR_ID_VIA,
+ .device = PCI_ANY_ID,
+ .subvendor = PCI_ANY_ID,
+ .subdevice = PCI_ANY_ID,
+ .class = PCI_CLASS_BRIDGE_ISA << 8,
+ .class_mask = 0xffff00,
+ },
+ { 0, },
+};
+
static void quirk_via_irq(struct pci_dev *dev)
{
u8 irq, new_irq;
- new_irq = dev->irq & 0xf;
+ if (via_irq_fixup_needed == -1)
+ via_irq_fixup_needed = pci_dev_present(via_irq_fixup_tbl);
+
+ if (!via_irq_fixup_needed)
+ return;
+
+ new_irq = dev->irq;
+
+ /* Don't quirk interrupts outside the legacy IRQ range */
+ if (!new_irq || new_irq > 15)
+ return;
+
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",
@@ -663,13 +695,7 @@ static void quirk_via_irq(struct pci_dev
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
Ar Iau, 2006-09-07 am 23:33 +0100, ysgrifennodd Daniel Drake:
> There is still a downside to this patch: if the user inserts a VIA PCI card
> into a VIA-based motherboard, in some circumstances the quirk will also run on
> the VIA PCI card. This corner case is hard to avoid.
NAK
This is not a "corner case"
Very large numbers of VIA mainboards ship with some of the VIA devices
built in and some of them on the PCI bus. In fact they generally start
shipped on the board as PCI devices and migrate over time.
You know from the northbridge which devices are internal and which are
external.
Alan
Alan Cox wrote:
> Very large numbers of VIA mainboards ship with some of the VIA devices
> built in and some of them on the PCI bus.
What's the difference between "built in" and "on the PCI bus"? Both
types are physically a part of the mainboard, and need to be quirked, right?
The corner case I was referring to is where someone plugs an *external*
VIA-based PCI card into a PCI slot on a VIA motherboard. In that case,
the PCI card gets quirked too, when it didn't need to be, and this may
or may not cause problems...
> You know from the northbridge which devices are internal and which are
> external.
I don't know much about PCI. How can I detect this?
Alternatively if you (or anyone else who knows PCI) wants to write a new
patch or modify the existing one I would have no objections. I can also
get a few people to test it.
Thanks.
Daniel
Ar Sad, 2006-09-09 am 10:44 -0400, ysgrifennodd Daniel Drake:
> Alan Cox wrote:
> > Very large numbers of VIA mainboards ship with some of the VIA devices
> > built in and some of them on the PCI bus.
>
> What's the difference between "built in" and "on the PCI bus"? Both
> types are physically a part of the mainboard, and need to be quirked, right?
No.
If they are on the V-Bus then the IRQ number controls routing if they
are on the PCI bus the IRQ line controls routing as normal.
Alan Cox wrote:
> If they are on the V-Bus then the IRQ number controls routing if they
> are on the PCI bus the IRQ line controls routing as normal.
OK, so per your last mail, most VIA devices start on the PCI bus and
then later are migrated onto the V-bus.
Devices on the PCI bus need to be quirked (in some circumstances), as
when they are on the PCI bus they use the IRQ line for routing, and the
IRQ line is what the quirk actually modifies.
V-bus devices do not need the quirk because IRQ routing there is handled
by IRQ number alone.
Is the above correct?
I did some searching and couldn't find anything out about the V-bus, I
assume that is some VIA-specific thing.
That aside, it appears we were talking about different situations in the
earlier email. We have 3 device classes:
- Internal PCI bus devices
- Internal V-bus devices
- External PCI card devices
I was talking about the corner case where we quirk an external-PCI-card
device when it is plugged into a mainboard which happens to be based on
a VIA chipset, whereas you were objecting to the fact that my patch
quirks both internal-PCI-bus and internal-V-bus devices (but only one of
those classes needs to be quirked). Is that correct?
Final question for now, are you saying that the current quirk in
mainline only quirks devices which are in the internal-PCI-bus class?
i.e. all of the following are *not* available in internal-V-bus form?
DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_0,
DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_1,
DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_2,
DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_3,
DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686,
DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_4,
DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_5,
Thanks.
Daniel
Ar Sad, 2006-09-09 am 17:34 -0400, ysgrifennodd Daniel Drake:
> Devices on the PCI bus need to be quirked (in some circumstances), as
> when they are on the PCI bus they use the IRQ line for routing, and the
> IRQ line is what the quirk actually modifies.
>
> V-bus devices do not need the quirk because IRQ routing there is handled
> by IRQ number alone.
>
> Is the above correct?
I've no idea. The data sheets imply not.
> I did some searching and couldn't find anything out about the V-bus, I
> assume that is some VIA-specific thing.
Earlier VIA chipsets use PCI to link internal devices and the bridges as
is normal for older systems. Later systems use a private internal bus
for this (as intel does with GCH), but which looks like PCI
And then you have external PCI devices on plug in cards.
All the PCI cases should be the same, IRQ routing by IRQ line/pin
A/B/C/D.
VIA have always told me that "ACPI handles this" and we don't need
quirks. Various chips have different IRQ routing logic and it's all a
bit weird if we don't use ACPI and/or BIOS routing.
Anyway its supposed to work like this if you want to try and unpick the
failing cases and work out how to fix them sanely:
MVP4 and 82C686*
IDE IRQ is 0x4A bits 3/2 (sec ide) and (1/0) (pri ide)
00 - 14 01 - 15 10 - 10 11 - 11
0x51 bits 7-4 are parport irq
0x51 bits 3-0 are floppy irq
0x52 bits 7-4 are ser2 irq
0x53 bits 3-0 are ser1 irq
0x55 bits 7-4 route PIRQA
0x56 bits 7-4 route PIRQC
0x56 bits 0-3 route PIRQB
0x57 bits 7-4 route PIRQD
0-15 = irq num but 0 = off 2, 8 and 13 are not allowed
82C686 adds
0x58 bit 0 - USB port 0 IRQ to APIC
bit 1 - USB port 1 IRQ to APIC
bit 2 - AC97 IRQ to APIC
bit 3 - MC97 IRQ to APIC (thats the modem)
bit 4 - ACPI IRQ to APIC
Each chip gets more complex so you can see why quirks and PCI IRQ
re-routing games will get quite horrible quite fast.
By the 8233 (just to cause pain btw some 8233's have a 3com built in
network...)
0x4D has become APIC control instead of 0x58 and adds
bit 6 USB port 4/5
bit 5 LAN
while 0x51-0x53 vanish but 55-57 are the same (ie it becomes a bit more
sane). Things like the USB IRQ pin are still hardwired (R/O).
The 8235 has some strange IRQ routing logic of its own. The APIC and
system now deals with 24 IRQs with an allegedly fixed routing of INTA ->
16 INTB -17 INTC -18 INTD -19 IDE -20 USB1 21, USB 2 21 or 23
[selectable], AC97/MC97 - 22
55-57 remain the same but the 0x4D register vanishes although it appears
to be a docs error and bit 7 is added for IDE. virtual PCI devices end
up at IRQ 16-23 using the low 3 bits of the IRQ line value if the line
is switched to APIC. The docs self conflict here on whether you can only
use IRQ 20 for IDE etc
One way you can often identify the onboard devices btw is that writes to
interrupt pin have no effect (ie PIN is fixed) and on older chips writes
to irq number are masked by 0x0F. Also IRQ 2 and 15 (or 0x?F if you dont
notice the masking) are not permitted generally but can be written.
On Sun, Sep 10, 2006 at 01:31:12AM +0100, Alan Cox wrote:
> VIA have always told me that "ACPI handles this" and we don't need
> quirks. Various chips have different IRQ routing logic and it's all a
> bit weird if we don't use ACPI and/or BIOS routing.
So why isn't acpi handling all of this for us? Do people not want to
use acpi for some reason?
thanks,
greg k-h
On Sat, Sep 09, 2006 at 05:21:12PM -0700, Greg KH wrote:
> So why isn't acpi handling all of this for us?
for some people it does...
> Do people not want to use acpi for some reason?
I was told that in the past VIA has buggy/broken ACPI, so we need to
figure out what ACPI workaround Windows has and implement that (or
maybe they do it in the driver(s)?)
On Sat, Sep 09, 2006 at 05:39:22PM -0700, Chris Wedgwood wrote:
> On Sat, Sep 09, 2006 at 05:21:12PM -0700, Greg KH wrote:
>
> > So why isn't acpi handling all of this for us?
>
> for some people it does...
>
> > Do people not want to use acpi for some reason?
>
> I was told that in the past VIA has buggy/broken ACPI, so we need to
> figure out what ACPI workaround Windows has and implement that (or
> maybe they do it in the driver(s)?)
Then that sounds like an ACPI issue, instead of trying to create a quirk
for the pci device itself.
Why not enable ACPI (which the manufacturer says is the way to go), and
then work from there?
thanks,
greg k-h
lør, 09,.09.2006 kl. 21.37 -0700, skrev Greg KH:
> Then that sounds like an ACPI issue, instead of trying to create a quirk
> for the pci device itself.
>
> Why not enable ACPI (which the manufacturer says is the way to go), and
> then work from there?
I've been using acpi on that motherboard since early 2.5, and it works
fine. But I still need that quirk to get it working.
The acpi guys are well aware of my problem since early 2004, but hasn't
been able to fix it yet, at least.
http://bugzilla.kernel.org/show_bug.cgi?id=2874
So if you disable the quirk for me, my computer will be without usb and
acpi...
Still, noone would be happier than me if this is solved "the right way".
Thanks.
Best regards,
Stian
Greg KH wrote:
> On Sun, Sep 10, 2006 at 01:31:12AM +0100, Alan Cox wrote:
>> VIA have always told me that "ACPI handles this" and we don't need
>> quirks. Various chips have different IRQ routing logic and it's all a
>> bit weird if we don't use ACPI and/or BIOS routing.
>
> So why isn't acpi handling all of this for us? Do people not want to
> use acpi for some reason?
It doesn't appear to be this simple in reality. Chris has reports that
indeed enabling ACPI avoids the needs for quirks, but Gentoo have
reports that quirks are *only* required in ACPI mode. Sergio is of the
opinion that quirks are not required in IO-APIC setups, but Stian has
shown that quirks are required on legacy interrupts even with a working
IO-APIC setup.
Len Brown has some notes to add:
http://lists.openwall.net/linux-kernel/2006/07/14/147
Daniel
Alan, sorry but I'm still having trouble understanding which aspect of
my patch you are objecting to. I think I probably misinterpreted one of
your earlier comments.
My patch included this comment:
> There is still a downside to this patch: if the user inserts a VIA
> PCI card into a VIA-based motherboard, in some circumstances the
> quirk will also run on
> the VIA PCI card. This corner case is hard to avoid.
To which you replied:
> NAK
>
> This is not a "corner case"
>
> Very large numbers of VIA mainboards ship with some of the VIA devices
> built in and some of them on the PCI bus. In fact they generally start
> shipped on the board as PCI devices and migrate over time.
and later followed up with:
> If they are on the V-Bus then the IRQ number controls routing if they
> are on the PCI bus the IRQ line controls routing as normal.
The scenario you are talking about there (internal devices on PCI bus vs
V-bus) is different from the one I was talking about (external VIA-based
PCI cards going into PCI slots on a VIA-based motherboard).
Regardless of that I tried to piece together what I thought you might be
trying to say, in order to understand the NAK:
> OK, so per your last mail, most VIA devices start on the PCI bus and
> then later are migrated onto the V-bus.
>
> Devices on the PCI bus need to be quirked (in some circumstances), as
> when they are on the PCI bus they use the IRQ line for routing, and
> the IRQ line is what the quirk actually modifies.
>
> V-bus devices do not need the quirk because IRQ routing there is
> handled by IRQ number alone.
>
> Is the above correct?
And then you replied:
> I've no idea.
Can you clarify?
Thanks.
Daniel
Basically we are going around in circles inventing new random
hypothetical rule sets that may or may not fix the problem. You can do
this for years, in fact we *have* been doing this for years.
The detailed stuff I posted by digging over all the docs should be
enough to figure out WTF is actually going on and fix the stuff
properly.
Alan Cox wrote:
> The detailed stuff I posted by digging over all the docs should be
> enough to figure out WTF is actually going on and fix the stuff
> properly.
FWIW, older VIA docs are also posted at
http://gkernel.sourceforge.net/specs/via/
Jeff
On Sat, 2006-09-09 at 17:21 -0700, Greg KH wrote:
> On Sun, Sep 10, 2006 at 01:31:12AM +0100, Alan Cox wrote:
> > VIA have always told me that "ACPI handles this" and we don't need
> > quirks. Various chips have different IRQ routing logic and it's all a
> > bit weird if we don't use ACPI and/or BIOS routing.
>
> So why isn't acpi handling all of this for us? Do people not want to
> use acpi for some reason?
Some applications such as realtime audio and probably gaming require
ACPI to be disabled, as it causes horrible latency problems. This
applies equally to Linux and Windows.
Lee
Alan Cox wrote:
> Basically we are going around in circles inventing new random
> hypothetical rule sets that may or may not fix the problem. You can do
> this for years, in fact we *have* been doing this for years.
>
> The detailed stuff I posted by digging over all the docs should be
> enough to figure out WTF is actually going on and fix the stuff
> properly.
OK - I'll try and figure out what is going on in Stian's case. Thanks
for the info.
Daniel
Ar Sul, 2006-09-10 am 15:06 -0400, ysgrifennodd Daniel Drake:
> Alan Cox wrote:
> > Basically we are going around in circles inventing new random
> > hypothetical rule sets that may or may not fix the problem. You can do
> > this for years, in fact we *have* been doing this for years.
> >
> > The detailed stuff I posted by digging over all the docs should be
> > enough to figure out WTF is actually going on and fix the stuff
> > properly.
>
> OK - I'll try and figure out what is going on in Stian's case. Thanks
> for the info.
Feel free to cc me the lspci data and partial diagnostics and I'll try
and help too.
On søn, 2006-09-10 at 20:41 +0100, Alan Cox wrote:
> Feel free to cc me the lspci data and partial diagnostics and I'll try
> and help too.
Attached is lspci -xxx and dmesg from 2.6.18-rc6.
http://bugzilla.kernel.org/show_bug.cgi?id=2874 has some further
information about this (stupid) motherboard. Anything else you need?
If anyone can help me with this, I'll promise to send the hero some
boxes of Norwegian beer!
On Sun, Sep 10, 2006 at 02:40:46PM -0400, Lee Revell wrote:
> Some applications such as realtime audio and probably gaming require
> ACPI to be disabled, as it causes horrible latency problems. This
> applies equally to Linux and Windows.
How, and on what hardware?
--
Matthew Garrett | [email protected]
On Sun, 2006-09-10 at 21:45 +0100, Matthew Garrett wrote:
> On Sun, Sep 10, 2006 at 02:40:46PM -0400, Lee Revell wrote:
>
> > Some applications such as realtime audio and probably gaming require
> > ACPI to be disabled, as it causes horrible latency problems. This
> > applies equally to Linux and Windows.
>
> How, and on what hardware?
Sorry, all I have is anecdotal evidence. The scope of the problem isn't
fully known. Could be related to vendors implementing ACPI using SMM.
Vendors are tight lipped about which hardware is affected because it
understandably annoys users.
It's been a FAQ in Windows pro audio forums for years; digital audio
software vendors recommend disabling ACPI (on Windows this means
reinstalling with the legacy PC HAL) as a last resort if you can't get a
low enough latency on some hardware.
Lee
On Sun, Sep 10, 2006 at 05:30:18PM -0400, Lee Revell wrote:
> Sorry, all I have is anecdotal evidence. The scope of the problem isn't
> fully known. Could be related to vendors implementing ACPI using SMM.
> Vendors are tight lipped about which hardware is affected because it
> understandably annoys users.
I don't know what you really mean by "implementing ACPI" here. Certain
queries may generate SMM traps, but I haven't seen any event driven code
paths that do[1]. If you're polling hardware you may generate some
latency, but I don't think that's any great surprise.
It would be interesting to have a test case under Linux so we could
attempt to figure out whether it's an actual problem, or just Windows
doing awkward things.
[1] outside sort of obvious stuff like ripping out a hotswap bay and
/potentially/ critical battery status to switch on a warning light, but
if you hit those situations you're probably pretty much dead anyway
--
Matthew Garrett | [email protected]
On Sun, 2006-09-10 at 21:21 +0200, Stian Jordet wrote:
> On søn, 2006-09-10 at 20:41 +0100, Alan Cox wrote:
> > Feel free to cc me the lspci data and partial diagnostics and I'll try
> > and help too.
>
> Attached is lspci -xxx and dmesg from 2.6.18-rc6.
> http://bugzilla.kernel.org/show_bug.cgi?id=2874 has some further
> information about this (stupid) motherboard. Anything else you need?
>
> If anyone can help me with this, I'll promise to send the hero some
> boxes of Norwegian beer!
>
>
Hi, this isn't the case of one USB with IO-APIC-level on legacy
interrupts ?
11: 5333 5326 IO-APIC-level uhci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3
if it is , was resolved with this [PATCH V3] VIA IRQ quirk behaviour change ?
Thanks,
--
Sérgio M. B.
On man, 2006-09-11 at 16:33 +0100, Sergio Monteiro Basto wrote:
> On Sun, 2006-09-10 at 21:21 +0200, Stian Jordet wrote:
> > On søn, 2006-09-10 at 20:41 +0100, Alan Cox wrote:
> > > Feel free to cc me the lspci data and partial diagnostics and I'll try
> > > and help too.
> >
> > Attached is lspci -xxx and dmesg from 2.6.18-rc6.
> > http://bugzilla.kernel.org/show_bug.cgi?id=2874 has some further
> > information about this (stupid) motherboard. Anything else you need?
> >
> > If anyone can help me with this, I'll promise to send the hero some
> > boxes of Norwegian beer!
> >
> >
> Hi, this isn't the case of one USB with IO-APIC-level on legacy
> interrupts ?
> 11: 5333 5326 IO-APIC-level uhci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3
>
> if it is , was resolved with this [PATCH V3] VIA IRQ quirk behaviour change ?
I have no idea what you mean here, but it's by no means fixed by that
patch, actually it just got worse (usb didn't work, but still got
interrupts from eth0 - and it still used irq 11)
Thanks.
-Stian
On Mon, 2006-09-11 at 22:16 +0200, Stian Jordet wrote:
> On man, 2006-09-11 at 16:33 +0100, Sergio Monteiro Basto wrote:
> > On Sun, 2006-09-10 at 21:21 +0200, Stian Jordet wrote:
> > > On s?n, 2006-09-10 at 20:41 +0100, Alan Cox wrote:
> > > > Feel free to cc me the lspci data and partial diagnostics and I'll try
> > > > and help too.
> > >
> > > Attached is lspci -xxx and dmesg from 2.6.18-rc6.
> > > http://bugzilla.kernel.org/show_bug.cgi?id=2874 has some further
> > > information about this (stupid) motherboard. Anything else you need?
> > >
> > > If anyone can help me with this, I'll promise to send the hero some
> > > boxes of Norwegian beer!
> > >
> > >
> > Hi, this isn't the case of one USB with IO-APIC-level on legacy
> > interrupts ?
> > 11: 5333 5326 IO-APIC-level uhci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3
> >
> > if it is , was resolved with this [PATCH V3] VIA IRQ quirk behaviour change ?
>
> I have no idea what you mean here, but it's by no means fixed by that
> patch, actually it just got worse (usb didn't work, but still got
> interrupts from eth0 - and it still used irq 11)
What ?! Aren't we talk about this computer
http://lkml.org/lkml/2006/9/6/178
and this
http://lkml.org/lkml/2006/9/7/220
if you don't get your device quirked we have add your hardware to the
list ...
Thanks,
--
S?rgio M. B.
On man, 2006-09-11 at 22:23 +0100, Sergio Monteiro Basto wrote:
> On Mon, 2006-09-11 at 22:16 +0200, Stian Jordet wrote:
> > On man, 2006-09-11 at 16:33 +0100, Sergio Monteiro Basto wrote:
> > > On Sun, 2006-09-10 at 21:21 +0200, Stian Jordet wrote:
> > > > On søn, 2006-09-10 at 20:41 +0100, Alan Cox wrote:
> > > > > Feel free to cc me the lspci data and partial diagnostics and I'll try
> > > > > and help too.
> > > >
> > > > Attached is lspci -xxx and dmesg from 2.6.18-rc6.
> > > > http://bugzilla.kernel.org/show_bug.cgi?id=2874 has some further
> > > > information about this (stupid) motherboard. Anything else you need?
> > > >
> > > > If anyone can help me with this, I'll promise to send the hero some
> > > > boxes of Norwegian beer!
> > > >
> > > >
> > > Hi, this isn't the case of one USB with IO-APIC-level on legacy
> > > interrupts ?
> > > 11: 5333 5326 IO-APIC-level uhci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3
> > >
> > > if it is , was resolved with this [PATCH V3] VIA IRQ quirk behaviour change ?
> >
> > I have no idea what you mean here, but it's by no means fixed by that
> > patch, actually it just got worse (usb didn't work, but still got
> > interrupts from eth0 - and it still used irq 11)
>
> What ?! Aren't we talk about this computer
> http://lkml.org/lkml/2006/9/6/178
> and this
> http://lkml.org/lkml/2006/9/7/220
>
> if you don't get your device quirked we have add your hardware to the
> list ...
That last patch there, made my system work (but that bugzilla bug is
still a problem). So with that last patch, my system works just as good
as it always has, if that's what you're trying to ask :)
-Stian
Sergio Monteiro Basto wrote:
> Hi, this isn't the case of one USB with IO-APIC-level on legacy
> interrupts ?
> 11: 5333 5326 IO-APIC-level uhci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3
Yes.
> if it is , was resolved with this [PATCH V3] VIA IRQ quirk behaviour change ?
Yes, but Alan Cox rejected it. We're now attempting to investigate
Stian's system to fully understand what's going on.
Daniel
Stian Jordet wrote:
>> if it is , was resolved with this [PATCH V3] VIA IRQ quirk behaviour change ?
>
> I have no idea what you mean here, but it's by no means fixed by that
> patch, actually it just got worse (usb didn't work, but still got
> interrupts from eth0 - and it still used irq 11)
Are you sure? The failure report you sent me was from V2 of the patch.
V3 should work fine, based on earlier comments and info from you.
Daniel
On man, 2006-09-11 at 17:54 -0400, Daniel Drake wrote:
> Stian Jordet wrote:
> >> if it is , was resolved with this [PATCH V3] VIA IRQ quirk behaviour change ?
> >
> > I have no idea what you mean here, but it's by no means fixed by that
> > patch, actually it just got worse (usb didn't work, but still got
> > interrupts from eth0 - and it still used irq 11)
>
> Are you sure? The failure report you sent me was from V2 of the patch.
> V3 should work fine, based on earlier comments and info from you.
Sorry, I was thinking of the wrong patch (the first one, which disabled
quirks for acpi). My wrong, sorry. With your last patch it works just
like it always has :)
Thanks!
-Stian
On Mon, 2006-09-11 at 23:38 +0200, Stian Jordet wrote:
> On man, 2006-09-11 at 22:23 +0100, Sergio Monteiro Basto wrote:
> > On Mon, 2006-09-11 at 22:16 +0200, Stian Jordet wrote:
> > > On man, 2006-09-11 at 16:33 +0100, Sergio Monteiro Basto wrote:
> > > > On Sun, 2006-09-10 at 21:21 +0200, Stian Jordet wrote:
> > > > > On søn, 2006-09-10 at 20:41 +0100, Alan Cox wrote:
> > > > > > Feel free to cc me the lspci data and partial diagnostics and I'll try
> > > > > > and help too.
> > > > >
> > > > > Attached is lspci -xxx and dmesg from 2.6.18-rc6.
> > > > > http://bugzilla.kernel.org/show_bug.cgi?id=2874 has some further
> > > > > information about this (stupid) motherboard. Anything else you need?
> > > > >
> > > > > If anyone can help me with this, I'll promise to send the hero some
> > > > > boxes of Norwegian beer!
> > > > >
> > > > >
> > > > Hi, this isn't the case of one USB with IO-APIC-level on legacy
> > > > interrupts ?
> > > > 11: 5333 5326 IO-APIC-level uhci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3
> > > >
> > > > if it is , was resolved with this [PATCH V3] VIA IRQ quirk behaviour change ?
> > >
> > > I have no idea what you mean here, but it's by no means fixed by that
> > > patch, actually it just got worse (usb didn't work, but still got
> > > interrupts from eth0 - and it still used irq 11)
> >
> > What ?! Aren't we talk about this computer
> > http://lkml.org/lkml/2006/9/6/178
> > and this
> > http://lkml.org/lkml/2006/9/7/220
> >
> > if you don't get your device quirked we have add your hardware to the
> > list ...
>
> That last patch there, made my system work (but that bugzilla bug is
> still a problem). So with that last patch, my system works just as good
> as it always has, if that's what you're trying to ask :)
Ok, as a quick answer, you have a very primitive VIA SMP board, which
make me remember my old laptop.
I maintain what a had write in previous emails about this system.
Seeing the configuration of irqs on windows, USB are in 9, so could be a
clue.
If I had your board, I'll try not quirk USB (cause quirk put USB in 11)
and make USB interrupts work as IO-APIC-edge.
9: nnnn nnnn IO-APIC-edge uhci_hcd:usb1, uhci_hcd:usb2,
uhci_hcd:usb3
--
Sérgio M. B.
On tir, 2006-09-12 at 13:37 +0100, Sergio Monteiro Basto wrote:
> Ok, as a quick answer, you have a very primitive VIA SMP board, which
> make me remember my old laptop.
> I maintain what a had write in previous emails about this system.
> Seeing the configuration of irqs on windows, USB are in 9, so could be a
> clue.
> If I had your board, I'll try not quirk USB (cause quirk put USB in 11)
> and make USB interrupts work as IO-APIC-edge.
> 9: nnnn nnnn IO-APIC-edge uhci_hcd:usb1, uhci_hcd:usb2,
> uhci_hcd:usb3
The point is, that even when I do not quirk (just insert return at the
top of the quirk-function), usb still uses irq 11 (as I wrote here:
http://lkml.org/lkml/2006/9/6/49 ), but won't work. And acpi (on
interrupt 9) gets an interrupt storm, and gets disabled.
But if I somehow got usb using irq 9, all my problems might vanish...
-Stian
On Tue, 2006-09-12 at 23:38 +0200, Stian Jordet wrote:
> On tir, 2006-09-12 at 13:37 +0100, Sergio Monteiro Basto wrote:
> > Ok, as a quick answer, you have a very primitive VIA SMP board, which
> > make me remember my old laptop.
> > I maintain what a had write in previous emails about this system.
> > Seeing the configuration of irqs on windows, USB are in 9, so could be a
> > clue.
> > If I had your board, I'll try not quirk USB (cause quirk put USB in 11)
> > and make USB interrupts work as IO-APIC-edge.
> > 9: nnnn nnnn IO-APIC-edge uhci_hcd:usb1, uhci_hcd:usb2,
> > uhci_hcd:usb3
>
> The point is, that even when I do not quirk (just insert return at the
> top of the quirk-function), usb still uses irq 11 (as I wrote here:
> http://lkml.org/lkml/2006/9/6/49 ), but won't work. And acpi (on
> interrupt 9) gets an interrupt storm, and gets disabled.
>
Good point , you got on your dmesg of kernel 2.6.18-rc6
(http://lkml.org/lkml/2006/9/10/120)
USB Universal Host Controller Interface driver v3.0
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11
ACPI: PCI Interrupt 0000:00:11.2[D] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11
PCI: VIA IRQ fixup for 0000:00:11.2, from 9 to 11
uhci_hcd 0000:00:11.2: UHCI Host Controller
uhci_hcd 0000:00:11.2: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:11.2: irq 11, io base 0x00009800
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
but before
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
LNKD was on 9, so may be the bug is on ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11
you have to investigate :)
Further more, your interrupts have 4 steps
ACPI: PCI Interrupt 0000:00:11.2[D] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11
and mine just got 3
ACPI: PCI Interrupt 0000:00:10.1[A] -> GSI 21 (level, low) -> IRQ 201
> But if I somehow got usb using irq 9, all my problems might vanish...
>
> -Stian
>
--
S?rgio M. B.
On Sun, 2006-09-10 at 21:45 +0100, Matthew Garrett wrote:
> On Sun, Sep 10, 2006 at 02:40:46PM -0400, Lee Revell wrote:
>
> > Some applications such as realtime audio and probably gaming require
> > ACPI to be disabled, as it causes horrible latency problems. This
> > applies equally to Linux and Windows.
>
> How, and on what hardware?
Here's a case where the kernel does not see a user's sound card at all
unless ACPI is disabled (second to last comment):
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2174
Lee
On Tue, Sep 19, 2006 at 04:04:27PM -0400, Lee Revell wrote:
> On Sun, 2006-09-10 at 21:45 +0100, Matthew Garrett wrote:
> > On Sun, Sep 10, 2006 at 02:40:46PM -0400, Lee Revell wrote:
> >
> > > Some applications such as realtime audio and probably gaming require
> > > ACPI to be disabled, as it causes horrible latency problems. This
> > > applies equally to Linux and Windows.
> >
> > How, and on what hardware?
>
> Here's a case where the kernel does not see a user's sound card at all
> unless ACPI is disabled (second to last comment):
That's more likely to be an interrupt routing issue than anything
intrinsically awkward with ACPI.
--
Matthew Garrett | [email protected]
On Tue, 2006-09-19 at 21:12 +0100, Matthew Garrett wrote:
> On Tue, Sep 19, 2006 at 04:04:27PM -0400, Lee Revell wrote:
> > On Sun, 2006-09-10 at 21:45 +0100, Matthew Garrett wrote:
> > > On Sun, Sep 10, 2006 at 02:40:46PM -0400, Lee Revell wrote:
> > >
> > > > Some applications such as realtime audio and probably gaming require
> > > > ACPI to be disabled, as it causes horrible latency problems. This
> > > > applies equally to Linux and Windows.
> > >
> > > How, and on what hardware?
> >
> > Here's a case where the kernel does not see a user's sound card at all
> > unless ACPI is disabled (second to last comment):
>
> That's more likely to be an interrupt routing issue than anything
> intrinsically awkward with ACPI.
>
True, but I was responding to an earlier statement along the lines of
"disabling ACPI is silly, who would do that?", and from these (and many
other) users' POV, they need to disable ACPI to have a working machine.
Lee