LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* [PATCH V3] VIA IRQ quirk behaviour change
@ 2006-09-07 22:33 Daniel Drake
  2006-09-09 14:20 ` Alan Cox
  0 siblings, 1 reply; 34+ messages in thread
From: Daniel Drake @ 2006-09-07 22:33 UTC (permalink / raw)
  To: akpm
  Cc: torvalds, sergio, jeff, greg, cw, bjorn.helgaas, linux-kernel,
	alan, harmon, len.brown, vsu, liste

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 <dsd@gentoo.org>
---

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3] VIA IRQ quirk behaviour change
  2006-09-07 22:33 [PATCH V3] VIA IRQ quirk behaviour change Daniel Drake
@ 2006-09-09 14:20 ` Alan Cox
  2006-09-09 14:44   ` Daniel Drake
  0 siblings, 1 reply; 34+ messages in thread
From: Alan Cox @ 2006-09-09 14:20 UTC (permalink / raw)
  To: Daniel Drake
  Cc: akpm, torvalds, sergio, jeff, greg, cw, bjorn.helgaas,
	linux-kernel, harmon, len.brown, vsu, liste

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


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3] VIA IRQ quirk behaviour change
  2006-09-09 14:20 ` Alan Cox
@ 2006-09-09 14:44   ` Daniel Drake
  2006-09-09 16:03     ` Alan Cox
  0 siblings, 1 reply; 34+ messages in thread
From: Daniel Drake @ 2006-09-09 14:44 UTC (permalink / raw)
  To: Alan Cox
  Cc: akpm, torvalds, sergio, jeff, greg, cw, bjorn.helgaas,
	linux-kernel, harmon, len.brown, vsu, liste

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3] VIA IRQ quirk behaviour change
  2006-09-09 14:44   ` Daniel Drake
@ 2006-09-09 16:03     ` Alan Cox
  2006-09-09 21:34       ` Daniel Drake
  0 siblings, 1 reply; 34+ messages in thread
From: Alan Cox @ 2006-09-09 16:03 UTC (permalink / raw)
  To: Daniel Drake
  Cc: akpm, torvalds, sergio, jeff, greg, cw, bjorn.helgaas,
	linux-kernel, harmon, len.brown, vsu, liste

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.



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3] VIA IRQ quirk behaviour change
  2006-09-09 16:03     ` Alan Cox
@ 2006-09-09 21:34       ` Daniel Drake
  2006-09-10  0:31         ` Alan Cox
  0 siblings, 1 reply; 34+ messages in thread
From: Daniel Drake @ 2006-09-09 21:34 UTC (permalink / raw)
  To: Alan Cox
  Cc: akpm, torvalds, sergio, jeff, greg, cw, bjorn.helgaas,
	linux-kernel, harmon, len.brown, vsu, liste

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3] VIA IRQ quirk behaviour change
  2006-09-10  0:31         ` Alan Cox
@ 2006-09-10  0:21           ` Greg KH
  2006-09-10  0:39             ` Chris Wedgwood
                               ` (2 more replies)
  2006-09-10 16:01           ` Daniel Drake
  1 sibling, 3 replies; 34+ messages in thread
From: Greg KH @ 2006-09-10  0:21 UTC (permalink / raw)
  To: Alan Cox
  Cc: Daniel Drake, akpm, torvalds, sergio, jeff, cw, bjorn.helgaas,
	linux-kernel, harmon, len.brown, vsu, liste

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3] VIA IRQ quirk behaviour change
  2006-09-09 21:34       ` Daniel Drake
@ 2006-09-10  0:31         ` Alan Cox
  2006-09-10  0:21           ` Greg KH
  2006-09-10 16:01           ` Daniel Drake
  0 siblings, 2 replies; 34+ messages in thread
From: Alan Cox @ 2006-09-10  0:31 UTC (permalink / raw)
  To: Daniel Drake
  Cc: akpm, torvalds, sergio, jeff, greg, cw, bjorn.helgaas,
	linux-kernel, harmon, len.brown, vsu, liste

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.





^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3] VIA IRQ quirk behaviour change
  2006-09-10  0:21           ` Greg KH
@ 2006-09-10  0:39             ` Chris Wedgwood
  2006-09-10  4:37               ` Greg KH
  2006-09-10 15:48             ` Daniel Drake
  2006-09-10 18:40             ` Lee Revell
  2 siblings, 1 reply; 34+ messages in thread
From: Chris Wedgwood @ 2006-09-10  0:39 UTC (permalink / raw)
  To: Greg KH
  Cc: Alan Cox, Daniel Drake, akpm, torvalds, sergio, jeff,
	bjorn.helgaas, linux-kernel, harmon, len.brown, vsu, liste

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)?)

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3] VIA IRQ quirk behaviour change
  2006-09-10  0:39             ` Chris Wedgwood
@ 2006-09-10  4:37               ` Greg KH
  2006-09-10  9:48                 ` Stian Jordet
  0 siblings, 1 reply; 34+ messages in thread
From: Greg KH @ 2006-09-10  4:37 UTC (permalink / raw)
  To: Chris Wedgwood
  Cc: Alan Cox, Daniel Drake, akpm, torvalds, sergio, jeff,
	bjorn.helgaas, linux-kernel, harmon, len.brown, vsu, liste

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3] VIA IRQ quirk behaviour change
  2006-09-10  4:37               ` Greg KH
@ 2006-09-10  9:48                 ` Stian Jordet
  0 siblings, 0 replies; 34+ messages in thread
From: Stian Jordet @ 2006-09-10  9:48 UTC (permalink / raw)
  To: Greg KH
  Cc: Chris Wedgwood, Alan Cox, Daniel Drake, akpm, torvalds, sergio,
	jeff, bjorn.helgaas, linux-kernel, harmon, len.brown, vsu

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


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3] VIA IRQ quirk behaviour change
  2006-09-10  0:21           ` Greg KH
  2006-09-10  0:39             ` Chris Wedgwood
@ 2006-09-10 15:48             ` Daniel Drake
  2006-09-10 18:40             ` Lee Revell
  2 siblings, 0 replies; 34+ messages in thread
From: Daniel Drake @ 2006-09-10 15:48 UTC (permalink / raw)
  To: Greg KH
  Cc: Alan Cox, akpm, torvalds, sergio, jeff, cw, bjorn.helgaas,
	linux-kernel, harmon, len.brown, vsu, liste

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3] VIA IRQ quirk behaviour change
  2006-09-10  0:31         ` Alan Cox
  2006-09-10  0:21           ` Greg KH
@ 2006-09-10 16:01           ` Daniel Drake
  2006-09-10 16:39             ` Alan Cox
  1 sibling, 1 reply; 34+ messages in thread
From: Daniel Drake @ 2006-09-10 16:01 UTC (permalink / raw)
  To: Alan Cox
  Cc: akpm, torvalds, sergio, jeff, greg, cw, bjorn.helgaas,
	linux-kernel, harmon, len.brown, vsu, liste

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3] VIA IRQ quirk behaviour change
  2006-09-10 16:01           ` Daniel Drake
@ 2006-09-10 16:39             ` Alan Cox
  2006-09-10 16:44               ` Jeff Garzik
  2006-09-10 19:06               ` Daniel Drake
  0 siblings, 2 replies; 34+ messages in thread
From: Alan Cox @ 2006-09-10 16:39 UTC (permalink / raw)
  To: Daniel Drake
  Cc: akpm, torvalds, sergio, jeff, greg, cw, bjorn.helgaas,
	linux-kernel, harmon, len.brown, vsu, liste

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. 



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3] VIA IRQ quirk behaviour change
  2006-09-10 16:39             ` Alan Cox
@ 2006-09-10 16:44               ` Jeff Garzik
  2006-09-10 19:06               ` Daniel Drake
  1 sibling, 0 replies; 34+ messages in thread
From: Jeff Garzik @ 2006-09-10 16:44 UTC (permalink / raw)
  To: Alan Cox
  Cc: Daniel Drake, akpm, torvalds, sergio, greg, cw, bjorn.helgaas,
	linux-kernel, harmon, len.brown, vsu, liste

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



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3] VIA IRQ quirk behaviour change
  2006-09-10  0:21           ` Greg KH
  2006-09-10  0:39             ` Chris Wedgwood
  2006-09-10 15:48             ` Daniel Drake
@ 2006-09-10 18:40             ` Lee Revell
  2006-09-10 20:45               ` Matthew Garrett
  2 siblings, 1 reply; 34+ messages in thread
From: Lee Revell @ 2006-09-10 18:40 UTC (permalink / raw)
  To: Greg KH
  Cc: Alan Cox, Daniel Drake, akpm, torvalds, sergio, jeff, cw,
	bjorn.helgaas, linux-kernel, harmon, len.brown, vsu, liste

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


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3] VIA IRQ quirk behaviour change
  2006-09-10 16:39             ` Alan Cox
  2006-09-10 16:44               ` Jeff Garzik
@ 2006-09-10 19:06               ` Daniel Drake
  2006-09-10 19:41                 ` Alan Cox
  1 sibling, 1 reply; 34+ messages in thread
From: Daniel Drake @ 2006-09-10 19:06 UTC (permalink / raw)
  To: Alan Cox
  Cc: akpm, torvalds, sergio, jeff, greg, cw, bjorn.helgaas,
	linux-kernel, harmon, len.brown, vsu, liste

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3] VIA IRQ quirk behaviour change
  2006-09-10 19:41                 ` Alan Cox
@ 2006-09-10 19:21                   ` Stian Jordet
  2006-09-11 15:33                     ` Sergio Monteiro Basto
  0 siblings, 1 reply; 34+ messages in thread
From: Stian Jordet @ 2006-09-10 19:21 UTC (permalink / raw)
  To: Alan Cox
  Cc: Daniel Drake, akpm, torvalds, sergio, jeff, greg, cw,
	bjorn.helgaas, linux-kernel, harmon, len.brown, vsu

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

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!



[-- Attachment #2: lspci-xxx.txt --]
[-- Type: text/plain, Size: 16426 bytes --]

00:00.0 Host bridge: VIA Technologies, Inc. VT8633 [Apollo Pro266] (rev 01)
00: 06 11 91 30 06 00 10 a2 01 00 00 06 00 00 00 00
10: 08 00 00 f8 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 64 80
30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00
40: 00 18 88 80 82 44 00 00 18 18 88 80 82 44 00 00
50: c8 5e cf 88 c0 0c 20 20 e0 00 10 20 20 20 20 20
60: 02 aa 2a a0 e6 99 40 28 56 0f 40 50 f0 dc a1 11
70: 82 c8 00 01 00 01 10 00 00 00 00 00 00 00 00 02
80: 0f 65 00 00 c0 00 00 00 03 00 ca 1f 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 02 c0 20 00 01 02 00 1f 01 03 00 00 27 12 00 00
b0: ff bd 18 00 80 00 00 00 80 00 00 00 00 00 00 8c
c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 0c 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00

00:01.0 PCI bridge: VIA Technologies, Inc. VT8633 [Apollo Pro266 AGP]
00: 06 11 91 b0 07 00 30 22 00 00 04 06 00 00 01 00
10: 00 00 00 00 00 00 00 00 00 01 01 00 d0 d0 00 00
20: 80 de d0 df 00 e0 f0 f7 00 00 00 00 00 00 00 00
30: 00 00 00 00 80 00 00 00 00 00 00 00 00 00 08 00
40: 80 45 00 44 24 72 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 01 00 02 02 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:05.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100] (rev 08)
00: 86 80 29 12 17 00 90 02 08 00 00 02 08 20 00 00
10: 00 00 00 de 01 b8 00 00 00 00 80 dd 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 5a 80
30: 00 00 00 00 dc 00 00 00 00 00 00 00 09 01 08 38
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 01 00 22 fe
e0: 00 40 00 3a 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:07.0 SCSI storage controller: Adaptec AIC-7899P U160/m (rev 01)
00: 05 90 cf 00 16 00 b0 02 01 00 00 01 08 20 80 80
10: 01 b4 00 00 04 00 00 dd 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 6b 80
30: 00 00 00 00 dc 00 00 00 00 00 00 00 0a 01 28 19
40: 02 04 00 80 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 01 00 02 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:07.1 SCSI storage controller: Adaptec AIC-7899P U160/m (rev 01)
00: 05 90 cf 00 16 00 b0 02 01 00 00 01 08 20 80 80
10: 01 b0 00 00 04 00 80 dc 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 6b 80
30: 00 00 00 00 dc 00 00 00 00 00 00 00 05 02 28 19
40: 02 04 00 80 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 01 00 02 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:0c.0 Multimedia controller: Philips Semiconductors SAA7134 Video Broadcast Decoder (rev 01)
00: 31 11 34 71 06 00 90 82 01 00 80 04 00 20 00 00
10: 00 00 00 dc 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 3b 15 43 11
30: 00 00 00 00 40 00 00 00 00 00 00 00 09 01 ff ff
40: 01 00 01 06 00 60 00 ff 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:0d.0 Multimedia video controller: Zoran Corporation ZR36120 (rev 02)
00: de 11 20 61 06 00 00 00 02 00 00 04 00 20 00 00
10: 00 00 80 db 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 0b 01 02 10
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:0e.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 07)
00: 02 11 02 00 05 00 90 02 07 00 01 04 00 20 80 00
10: 01 a8 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 02 11 61 80
30: 00 00 00 00 dc 00 00 00 00 00 00 00 0a 01 02 14
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 01 00 01 06
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:0e.1 Input device controller: Creative Labs SB Live! MIDI/Game Port (rev 07)
00: 02 11 02 70 05 00 90 02 07 00 80 09 00 20 80 00
10: 01 a4 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 02 11 20 00
30: 00 00 00 00 dc 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 01 00 01 06
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:0f.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev 80)
00: 80 11 76 04 07 00 10 02 80 00 07 06 00 a8 82 00
10: 00 00 14 38 dc 00 00 02 00 02 05 b0 00 00 00 30
20: 00 f0 ff 31 00 00 00 32 00 f0 ff 33 00 10 00 00
30: fc 10 00 00 00 14 00 00 fc 14 00 00 05 01 80 05
40: ef 14 20 02 01 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 01 00 00 00 00 03 00 00 63 04 63 04 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: ef 14 20 02 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 01 00 19 fe
e0: 00 40 c0 24 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:0f.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev 80)
00: 80 11 76 04 07 00 10 02 80 00 07 06 00 a8 82 00
10: 00 10 14 38 dc 00 00 02 00 06 09 b0 00 00 00 34
20: 00 f0 ff 35 00 00 00 36 00 f0 ff 37 00 18 00 00
30: fc 18 00 00 00 1c 00 00 fc 1c 00 00 09 02 80 05
40: ef 14 20 02 01 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 01 00 00 00 00 03 00 00 63 04 63 04 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: ef 14 20 02 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 01 00 19 fe
e0: 00 40 c0 24 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:11.0 ISA bridge: VIA Technologies, Inc. VT8233 PCI to ISA Bridge
00: 06 11 74 30 87 00 10 02 00 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 52 80
30: 00 00 00 00 c0 00 00 00 00 00 00 00 00 00 00 00
40: 44 00 f0 00 00 00 00 00 0c 20 00 00 c4 00 0a 08
50: c1 08 09 00 00 00 00 b0 43 10 00 00 04 e4 60 00
60: 00 00 00 00 01 00 00 04 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 30 00 00 00
80: 20 80 49 00 00 00 00 00 01 e4 00 00 00 10 00 00
90: 00 68 12 04 90 40 0e 00 50 b0 20 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 01 e8 01 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 02 00 00 00 00 00 00 00 00 00

00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
00: 06 11 71 05 87 00 90 02 06 8a 01 01 00 20 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 c0 00 00 00 00 00 00 00 00 00 00 00
40: 0b c2 09 3a 1c 10 c0 00 22 a8 20 20 0d 00 22 20
50: 07 07 e4 e4 04 00 00 00 a8 a8 a8 a8 00 00 00 00
60: 00 02 00 00 00 00 00 00 00 02 00 00 00 00 00 00
70: 02 01 00 00 00 00 00 00 02 01 00 00 00 00 00 00
80: 00 f0 e0 1f 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 06 00 71 05 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:11.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 18)
00: 06 11 38 30 17 00 10 02 18 00 03 0c 08 20 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 98 00 00 00 00 00 00 00 00 00 00 25 09 34 12
30: 00 00 00 00 80 00 00 00 00 00 00 00 0b 04 00 00
40: 00 00 01 00 c2 00 22 e0 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:11.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 18)
00: 06 11 38 30 17 00 10 02 18 00 03 0c 08 20 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 94 00 00 00 00 00 00 00 00 00 00 25 09 34 12
30: 00 00 00 00 80 00 00 00 00 00 00 00 0b 04 00 00
40: 00 00 01 00 c2 00 33 30 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:11.4 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 18)
00: 06 11 38 30 17 00 10 02 18 00 03 0c 08 20 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 90 00 00 00 00 00 00 00 00 00 00 25 09 34 12
30: 00 00 00 00 80 00 00 00 00 00 00 00 0b 04 00 00
40: 00 00 01 00 c6 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R300 ND [Radeon 9700 Pro]
00: 02 10 44 4e 87 00 b0 02 00 00 00 03 08 40 80 00
10: 08 00 00 f0 01 d8 00 00 00 00 00 df 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 02 10 02 00
30: 00 00 fe ef 58 00 00 00 00 00 00 00 0b 01 08 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 02 10 02 00
50: 01 00 02 06 00 00 00 00 02 50 20 00 17 02 00 4f
60: 01 03 00 1f 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

01:00.1 Display controller: ATI Technologies Inc Radeon R300 [Radeon 9700 Pro] (Secondary)
00: 02 10 64 4e 87 00 b0 02 00 00 80 03 08 40 00 00
10: 08 00 00 e0 00 00 80 de 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 02 10 03 00
30: 00 00 00 00 50 00 00 00 00 00 00 00 ff 00 08 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 01 00 02 06 00 00 00 00 02 50 20 00 17 02 00 4f
60: 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00


[-- Attachment #3: dmesg --]
[-- Type: text/plain, Size: 18880 bytes --]

Linux version 2.6.18-rc6 (root@chevrolet) (gcc version 4.1.2 20060906 (prerelease) (Ubuntu 4.1.1-13ubuntu2)) #3 SMP Thu Sep 7 20:24:47 CEST 2006
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
 BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000001fffc000 (usable)
 BIOS-e820: 000000001fffc000 - 000000001ffff000 (ACPI data)
 BIOS-e820: 000000001ffff000 - 0000000020000000 (ACPI NVS)
 BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
 BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
511MB LOWMEM available.
found SMP MP-table at 000f5500
On node 0 totalpages: 131068
  DMA zone: 4096 pages, LIFO batch:0
  Normal zone: 126972 pages, LIFO batch:31
DMI 2.3 present.
ACPI: RSDP (v000 ASUS                                  ) @ 0x000f6930
ACPI: RSDT (v001 ASUS   CV266DLS 0x30303031 MSFT 0x31313031) @ 0x1fffc000
ACPI: FADT (v001 ASUS   CV266DLS 0x30303031 MSFT 0x31313031) @ 0x1fffc100
ACPI: BOOT (v001 ASUS   CV266DLS 0x30303031 MSFT 0x31313031) @ 0x1fffc040
ACPI: MADT (v001 ASUS   CV266DLS 0x30303031 MSFT 0x31313031) @ 0x1fffc080
ACPI: DSDT (v001   ASUS CV266DLS 0x00001000 MSFT 0x0100000b) @ 0x00000000
ACPI: PM-Timer IO Port: 0xe408
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x03] enabled)
Processor #3 6:8 APIC version 17
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 6:8 APIC version 17
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 2, version 17, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl edge)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 30000000 (gap: 20000000:dec00000)
Detected 999.736 MHz processor.
Built 1 zonelists.  Total pages: 131068
Kernel command line: root=/dev/sda2 ro quiet splash
mapped APIC to ffffd000 (fee00000)
mapped IOAPIC to ffffc000 (fec00000)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
PID hash table entries: 2048 (order: 11, 8192 bytes)
Console: colour VGA+ 80x25
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 514368k/524272k available (3127k kernel code, 9368k reserved, 1180k data, 200k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 2001.78 BogoMIPS (lpj=4003571)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: 0383fbff 00000000 00000000 00000000 00000000 00000000 00000000
CPU: After vendor identify, caps: 0383fbff 00000000 00000000 00000000 00000000 00000000 00000000
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
CPU: After all inits, caps: 0383fbff 00000000 00000000 00000040 00000000 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
Checking 'hlt' instruction... OK.
Freeing SMP alternatives: 20k freed
ACPI: Core revision 20060707
CPU0: Intel Pentium III (Coppermine) stepping 0a
Booting processor 1/0 eip 2000
Initializing CPU#1
Calibrating delay using timer specific routine.. 1999.60 BogoMIPS (lpj=3999212)
CPU: After generic identify, caps: 0383fbff 00000000 00000000 00000000 00000000 00000000 00000000
CPU: After vendor identify, caps: 0383fbff 00000000 00000000 00000000 00000000 00000000 00000000
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
CPU: After all inits, caps: 0383fbff 00000000 00000000 00000040 00000000 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#1.
CPU1: Intel Pentium III (Coppermine) stepping 0a
Total of 2 processors activated (4001.39 BogoMIPS).
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
checking TSC synchronization across 2 CPUs: passed.
Brought up 2 CPUs
migration_cost=601
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xf0d40, last bus=1
PCI: Using configuration type 1
Setting up standard PCI resources
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
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)
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
ACPI: Assume root bridge [\_SB_.PCI0] bus is 0
PCI: Firmware left 0000:00:05.0 e100 interrupts enabled, disabling
Boot video device is 0000:01:00.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1._PRT]
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new driver hub
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
irda_init()
NET: Registered protocol family 23
Bluetooth: Core ver 2.10
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
PCI: Bridge: 0000:00:01.0
  IO window: d000-dfff
  MEM window: de800000-dfdfffff
  PREFETCH window: e0000000-f7ffffff
PCI: Bus 2, cardbus bridge: 0000:00:0f.0
  IO window: 00001000-000010ff
  IO window: 00001400-000014ff
  PREFETCH window: 30000000-31ffffff
  MEM window: 32000000-33ffffff
PCI: Bus 6, cardbus bridge: 0000:00:0f.1
  IO window: 00001800-000018ff
  IO window: 00001c00-00001cff
  PREFETCH window: 34000000-35ffffff
  MEM window: 36000000-37ffffff
PCI: Setting latency timer of device 0000:00:01.0 to 64
PCI: Enabling device 0000:00:0f.0 (0000 -> 0003)
ACPI: PCI Interrupt 0000:00:0f.0[A] -> GSI 18 (level, low) -> IRQ 16
PCI: Enabling device 0000:00:0f.1 (0000 -> 0003)
ACPI: PCI Interrupt 0000:00:0f.1[B] -> GSI 19 (level, low) -> IRQ 17
NET: Registered protocol family 2
IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
TCP established hash table entries: 16384 (order: 5, 131072 bytes)
TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 16384 bind 8192)
TCP reno registered
Simple Boot Flag at 0x3a set to 0x1
IA-32 Microcode Update Driver: v1.14a <tigran@veritas.com>
NTFS driver 2.1.27 [Flags: R/O].
SGI XFS with ACLs, no debug enabled
SGI XFS Quota Management subsystem
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
ACPI: Power Button (FF) [PWRF]
ACPI: Power Button (CM) [PWRB]
Real Time Clock Driver v1.12ac
Linux agpgart interface v0.101 (c) Dave Jones
agpgart: Detected VIA Pro 266 chipset
agpgart: AGP aperture is 64M @ 0xf8000000
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
loop: loaded (max 8 devices)
e100: Intel(R) PRO/100 Network Driver, 3.5.10-k2-NAPI
e100: Copyright(c) 1999-2005 Intel Corporation
ACPI: PCI Interrupt 0000:00:05.0[A] -> GSI 19 (level, low) -> IRQ 17
e100: eth0: e100_probe: addr 0xde000000, irq 17, MAC addr 00:E0:18:2E:FF:C0
PPP generic driver version 2.4.2
PPP Deflate Compression module registered
PPP BSD Compression module registered
netconsole: not configured, aborting
Linux video capture interface: v2.00
saa7130/34: v4l2 driver version 0.2.14 loaded
ACPI: PCI Interrupt 0000:00:0c.0[A] -> GSI 19 (level, low) -> IRQ 17
saa7134[0]: found at 0000:00:0c.0, rev: 1, irq: 17, latency: 32, mmio: 0xdc000000
saa7134[0]: subsystem: 153b:1143, board: Terratec Cinergy 600 TV [card=11,autodetected]
saa7134[0]: board init: gpio is 50000
input: saa7134 IR (Terratec Cinergy 60 as /class/input/input0
saa7134[0]: i2c eeprom 00: 3b 15 43 11 ff ff ff ff ff ff ff ff ff ff ff ff
saa7134[0]: i2c eeprom 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7134[0]: i2c eeprom 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7134[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7134[0]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7134[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7134[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7134[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7134[0]: registered device video0 [v4l2]
saa7134[0]: registered device vbi0
saa7134[0]: registered device radio0
tuner 0-0060: Chip ID is not zero. It is not a TEA5767
tuner 0-0060: chip found @ 0xc0 (saa7134[0])
tuner 0-0060: type set to 5 (Philips PAL_BG (FI1216 and compatibles))
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller at PCI slot 0000:00:11.1
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt8233 (rev 00) IDE UDMA100 controller on pci0000:00:11.1
    ide0: BM-DMA at 0xa000-0xa007, BIOS settings: hda:DMA, hdb:DMA
    ide1: BM-DMA at 0xa008-0xa00f, BIOS settings: hdc:pio, hdd:DMA
Probing IDE interface ide0...
hda: ST3200822A, ATA DISK drive
hdb: ST3200822A, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hdd: IOMEGA ZIP 100 ATAPI Floppy, ATAPI FLOPPY drive
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 512KiB
hda: 390721968 sectors (200049 MB) w/8192KiB Cache, CHS=24321/255/63, UDMA(33)
hda: cache flushes supported
 hda: hda1
hdb: max request size: 512KiB
hdb: 390721968 sectors (200049 MB) w/8192KiB Cache, CHS=24321/255/63, UDMA(33)
hdb: cache flushes supported
 hdb: hdb1
ide-floppy driver 0.99.newide
hdd: No disk in drive
hdd: 98304kB, 96/64/32 CHS, 4096 kBps, 512 sector size, 2941 rpm
ACPI: PCI Interrupt 0000:00:07.0[A] -> GSI 17 (level, low) -> IRQ 18
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
        <Adaptec aic7899 Ultra160 SCSI adapter>
        aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs

  Vendor: SEAGATE   Model: ST318452LW        Rev: 0004
  Type:   Direct-Access                      ANSI SCSI revision: 03
scsi0:A:0:0: Tagged Queuing enabled.  Depth 253
 target0:0:0: Beginning Domain Validation
 target0:0:0: wide asynchronous
 target0:0:0: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 63)
 target0:0:0: Ending Domain Validation
ACPI: PCI Interrupt 0000:00:07.1[B] -> GSI 18 (level, low) -> IRQ 16
scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
        <Adaptec aic7899 Ultra160 SCSI adapter>
        aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs

  Vendor: PIONEER   Model: DVD-ROM DVD-304F  Rev: 1.03
  Type:   CD-ROM                             ANSI SCSI revision: 02
 target1:0:4: Beginning Domain Validation
 target1:0:4: FAST-20 SCSI 20.0 MB/s ST (50 ns, offset 16)
 target1:0:4: Domain Validation skipping write tests
 target1:0:4: Ending Domain Validation
  Vendor: YAMAHA    Model: CRW-F1S           Rev: 1.0g
  Type:   CD-ROM                             ANSI SCSI revision: 02
 target1:0:5: Beginning Domain Validation
 target1:0:5: FAST-20 SCSI 20.0 MB/s ST (50 ns, offset 15)
 target1:0:5: Domain Validation skipping write tests
 target1:0:5: Ending Domain Validation
  Vendor: SEAGATE   Model: DAT    04687-XXX  Rev: 6610
  Type:   Sequential-Access                  ANSI SCSI revision: 02
 target1:0:6: Beginning Domain Validation
 target1:0:6: FAST-10 SCSI 7.8 MB/s ST (128 ns, offset 15)
 target1:0:6: Domain Validation skipping write tests
 target1:0:6: Ending Domain Validation
st: Version 20050830, fixed bufsize 32768, s/g segs 256
st 1:0:6:0: Attached scsi tape st0
st0: try direct i/o: yes (alignment 512 B)
SCSI device sda: 35843670 512-byte hdwr sectors (18352 MB)
sda: Write Protect is off
sda: Mode Sense: a3 00 10 08
SCSI device sda: drive cache: write back w/ FUA
SCSI device sda: 35843670 512-byte hdwr sectors (18352 MB)
sda: Write Protect is off
sda: Mode Sense: a3 00 10 08
SCSI device sda: drive cache: write back w/ FUA
 sda: sda1 sda2 sda3 sda4
sd 0:0:0:0: Attached scsi disk sda
sr0: scsi3-mmc drive: 0x/0x cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.20
sr 1:0:4:0: Attached scsi CD-ROM sr0
sr1: scsi3-mmc drive: 44x/44x writer cd/rw xa/form2 cdda tray
sr 1:0:5:0: Attached scsi CD-ROM sr1
sd 0:0:0:0: Attached scsi generic sg0 type 0
sr 1:0:4:0: Attached scsi generic sg1 type 5
sr 1:0:5:0: Attached scsi generic sg2 type 5
st 1:0:6:0: Attached scsi generic sg3 type 1
Yenta: CardBus bridge found at 0000:00:0f.0 [14ef:0220]
Yenta: ISA IRQ mask 0x0000, PCI irq 16
Socket status: 30000006
Yenta: CardBus bridge found at 0000:00:0f.1 [14ef:0220]
Yenta: ISA IRQ mask 0x0000, PCI irq 17
Socket status: 30000006
usbmon: debugfs is not available
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
ACPI: PCI Interrupt 0000:00:11.3[D] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11
PCI: VIA IRQ fixup for 0000:00:11.3, from 9 to 11
uhci_hcd 0000:00:11.3: UHCI Host Controller
uhci_hcd 0000:00:11.3: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:11.3: irq 11, io base 0x00009400
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:11.4[D] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11
PCI: VIA IRQ fixup for 0000:00:11.4, from 9 to 11
uhci_hcd 0000:00:11.4: UHCI Host Controller
uhci_hcd 0000:00:11.4: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:11.4: irq 11, io base 0x00009000
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
usb 1-1: new full speed USB device using uhci_hcd and address 2
usb 1-1: configuration #1 chosen from 1 choice
usb 2-1: new full speed USB device using uhci_hcd and address 2
usb 2-1: configuration #1 chosen from 1 choice
usb 2-2: new full speed USB device using uhci_hcd and address 3
usb 2-2: configuration #1 chosen from 1 choice
drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 3 if 0 alt 0 proto 2 vid 0x03F0 pid 0x3304
usbcore: registered new driver usblp
drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver
Initializing USB Mass Storage driver...
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
usbcore: registered new driver hiddev
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
usbcore: registered new driver usbserial
drivers/usb/serial/usb-serial.c: USB Serial Driver core
drivers/usb/serial/usb-serial.c: USB Serial support registered for FTDI USB Serial Device
usbcore: registered new driver ftdi_sio
drivers/usb/serial/ftdi_sio.c: v1.4.3:USB FTDI Serial Converters Driver
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
mice: PS/2 mouse device common for all mice
input: PC Speaker as /class/input/input1
gameport: EMU10K1 is pci0000:00:0e.1/gameport0, io 0xa400, speed 1193kHz
input: AT Translated Set 2 keyboard as /class/input/input2
logips2pp: Detected unknown logitech mouse model 57
Bluetooth: HCI USB driver ver 2.9
usbcore: registered new driver hci_usb
ISDN subsystem Rev: 1.1.2.3/1.1.2.3/1.1.2.2/1.1.2.3/none/1.1.2.2
PPP BSD Compression module registered
HiSax: Linux Driver for passive ISDN cards
HiSax: Version 3.5 (kernel)
HiSax: Layer1 Revision 2.46.2.5
HiSax: Layer2 Revision 2.30.2.4
HiSax: TeiMgr Revision 2.20.2.3
HiSax: Layer3 Revision 2.22.2.3
HiSax: LinkLayer Revision 2.59.2.4
HiSax: Total 1 card defined
HiSax: Card 1 Protocol EDSS1 Id=HiSax (0)
HiSax: Teles/PCI driver Rev. 2.23.2.3
ACPI: PCI Interrupt 0000:00:0d.0[A] -> GSI 16 (level, low) -> IRQ 19
Found: Zoran, base-address: 0xdb800000, irq: 0x13
HiSax: Teles PCI config irq:19 mem:e084e000
TelesPCI: ISAC version (0): 2086/2186 V1.1
TelesPCI: HSCX version A: V2.1  B: V2.1
Teles PCI: IRQ 19 count 0
Teles PCI: IRQ 19 count 0
Teles PCI: IRQ(19) getting no interrupts during init 1
Teles PCI: IRQ 19 count 0
Teles PCI: IRQ(19) getting no interrupts during init 2
Teles PCI: IRQ 19 count 0
Teles PCI: IRQ(19) getting no interrupts during init 3
HiSax: Card Teles PCI not installed !
Advanced Linux Sound Architecture Driver Version 1.0.12rc1 (Thu Jun 22 13:55:50 2006 UTC).
input: ImExPS/2 Logitech Explorer Mouse as /class/input/input3
specify port
snd_mpu401: probe of snd_mpu401.0 failed with error -22
ACPI: PCI Interrupt 0000:00:0e.0[A] -> GSI 17 (level, low) -> IRQ 18
ALSA device list:
  #0: SBLive 5.1 [SB0060] (rev.7, serial:0x80611102) at 0xa800, irq 18
ip_conntrack version 2.4 (4095 buckets, 32760 max) - 192 bytes per conntrack
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
IrCOMM protocol (Dag Brattli)
Bluetooth: L2CAP ver 2.8
Bluetooth: L2CAP socket layer initialized
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM TTY layer initialized
Bluetooth: RFCOMM ver 1.8
Bluetooth: BNEP (Ethernet Emulation) ver 1.2
Bluetooth: BNEP filters: protocol multicast
Using IPI Shortcut mode
saa7134 ALSA driver for DMA sound loaded
saa7134[0]/alsa: saa7134[0] at 0xdc000000 irq 17 registered as card -1
Time: tsc clocksource has been installed.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 200k freed
e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
hdd: No disk in drive
hdd: No disk in drive
Adding 1052248k swap on /dev/disk/by-uuid/ff8135cc-d5e6-40b8-b9dd-fd8ab1245cac.  Priority:-1 extents:1 across:1052248k
EXT3 (no)user_xattr options not supported
EXT3 FS on sda2, internal journal
sr0: CDROM not ready.  Make sure there is a disc in the drive.
XFS mounting filesystem sda3
Ending clean XFS mount for filesystem: sda3
XFS mounting filesystem hda1
Ending clean XFS mount for filesystem: hda1
XFS mounting filesystem hdb1
Ending clean XFS mount for filesystem: hdb1
NTFS volume version 3.1.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3] VIA IRQ quirk behaviour change
  2006-09-10 19:06               ` Daniel Drake
@ 2006-09-10 19:41                 ` Alan Cox
  2006-09-10 19:21                   ` Stian Jordet
  0 siblings, 1 reply; 34+ messages in thread
From: Alan Cox @ 2006-09-10 19:41 UTC (permalink / raw)
  To: Daniel Drake
  Cc: akpm, torvalds, sergio, jeff, greg, cw, bjorn.helgaas,
	linux-kernel, harmon, len.brown, vsu, liste

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.


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3] VIA IRQ quirk behaviour change
  2006-09-10 18:40             ` Lee Revell
@ 2006-09-10 20:45               ` Matthew Garrett
  2006-09-10 21:30                 ` Lee Revell
  2006-09-19 20:04                 ` Lee Revell
  0 siblings, 2 replies; 34+ messages in thread
From: Matthew Garrett @ 2006-09-10 20:45 UTC (permalink / raw)
  To: Lee Revell
  Cc: Greg KH, Alan Cox, Daniel Drake, akpm, torvalds, sergio, jeff,
	cw, bjorn.helgaas, linux-kernel, harmon, len.brown, vsu, liste

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 | mjg59@srcf.ucam.org

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3] VIA IRQ quirk behaviour change
  2006-09-10 20:45               ` Matthew Garrett
@ 2006-09-10 21:30                 ` Lee Revell
  2006-09-10 21:34                   ` Matthew Garrett
  2006-09-19 20:04                 ` Lee Revell
  1 sibling, 1 reply; 34+ messages in thread
From: Lee Revell @ 2006-09-10 21:30 UTC (permalink / raw)
  To: Matthew Garrett
  Cc: Greg KH, Alan Cox, Daniel Drake, akpm, torvalds, sergio, jeff,
	cw, bjorn.helgaas, linux-kernel, harmon, len.brown, vsu, liste

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



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3] VIA IRQ quirk behaviour change
  2006-09-10 21:30                 ` Lee Revell
@ 2006-09-10 21:34                   ` Matthew Garrett
  0 siblings, 0 replies; 34+ messages in thread
From: Matthew Garrett @ 2006-09-10 21:34 UTC (permalink / raw)
  To: Lee Revell
  Cc: Greg KH, Alan Cox, Daniel Drake, akpm, torvalds, sergio, jeff,
	cw, bjorn.helgaas, linux-kernel, harmon, len.brown, vsu, liste

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 | mjg59@srcf.ucam.org

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3] VIA IRQ quirk behaviour change
  2006-09-10 19:21                   ` Stian Jordet
@ 2006-09-11 15:33                     ` Sergio Monteiro Basto
  2006-09-11 20:16                       ` Stian Jordet
  2006-09-11 21:44                       ` Daniel Drake
  0 siblings, 2 replies; 34+ messages in thread
From: Sergio Monteiro Basto @ 2006-09-11 15:33 UTC (permalink / raw)
  To: Stian Jordet
  Cc: Alan Cox, Daniel Drake, akpm, torvalds, jeff, greg, cw,
	bjorn.helgaas, linux-kernel, harmon, len.brown, vsu

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. 


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3] VIA IRQ quirk behaviour change
  2006-09-11 15:33                     ` Sergio Monteiro Basto
@ 2006-09-11 20:16                       ` Stian Jordet
  2006-09-11 21:23                         ` Sergio Monteiro Basto
  2006-09-11 21:54                         ` Daniel Drake
  2006-09-11 21:44                       ` Daniel Drake
  1 sibling, 2 replies; 34+ messages in thread
From: Stian Jordet @ 2006-09-11 20:16 UTC (permalink / raw)
  To: Sergio Monteiro Basto
  Cc: Alan Cox, Daniel Drake, akpm, torvalds, jeff, greg, cw,
	bjorn.helgaas, linux-kernel, harmon, len.brown, vsu

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


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3] VIA IRQ quirk behaviour change
  2006-09-11 20:16                       ` Stian Jordet
@ 2006-09-11 21:23                         ` Sergio Monteiro Basto
  2006-09-11 21:38                           ` Stian Jordet
  2006-09-11 21:54                         ` Daniel Drake
  1 sibling, 1 reply; 34+ messages in thread
From: Sergio Monteiro Basto @ 2006-09-11 21:23 UTC (permalink / raw)
  To: Stian Jordet
  Cc: Alan Cox, Daniel Drake, akpm, torvalds, jeff, greg, cw,
	bjorn.helgaas, linux-kernel, harmon, len.brown, vsu

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

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.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2166 bytes --]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3] VIA IRQ quirk behaviour change
  2006-09-11 21:23                         ` Sergio Monteiro Basto
@ 2006-09-11 21:38                           ` Stian Jordet
  2006-09-12 12:37                             ` Sergio Monteiro Basto
  0 siblings, 1 reply; 34+ messages in thread
From: Stian Jordet @ 2006-09-11 21:38 UTC (permalink / raw)
  To: sergio
  Cc: Alan Cox, Daniel Drake, akpm, torvalds, jeff, greg, cw,
	bjorn.helgaas, linux-kernel, harmon, len.brown, vsu

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


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3] VIA IRQ quirk behaviour change
  2006-09-11 15:33                     ` Sergio Monteiro Basto
  2006-09-11 20:16                       ` Stian Jordet
@ 2006-09-11 21:44                       ` Daniel Drake
  1 sibling, 0 replies; 34+ messages in thread
From: Daniel Drake @ 2006-09-11 21:44 UTC (permalink / raw)
  To: Sergio Monteiro Basto
  Cc: Stian Jordet, Alan Cox, akpm, torvalds, jeff, greg, cw,
	bjorn.helgaas, linux-kernel, harmon, len.brown, vsu

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3] VIA IRQ quirk behaviour change
  2006-09-11 20:16                       ` Stian Jordet
  2006-09-11 21:23                         ` Sergio Monteiro Basto
@ 2006-09-11 21:54                         ` Daniel Drake
  2006-09-12  6:21                           ` Stian Jordet
  1 sibling, 1 reply; 34+ messages in thread
From: Daniel Drake @ 2006-09-11 21:54 UTC (permalink / raw)
  To: Stian Jordet
  Cc: Sergio Monteiro Basto, Alan Cox, akpm, torvalds, jeff, greg, cw,
	bjorn.helgaas, linux-kernel, harmon, len.brown, vsu

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3] VIA IRQ quirk behaviour change
  2006-09-11 21:54                         ` Daniel Drake
@ 2006-09-12  6:21                           ` Stian Jordet
  0 siblings, 0 replies; 34+ messages in thread
From: Stian Jordet @ 2006-09-12  6:21 UTC (permalink / raw)
  To: Daniel Drake
  Cc: Sergio Monteiro Basto, Alan Cox, akpm, torvalds, jeff, greg, cw,
	bjorn.helgaas, linux-kernel, harmon, len.brown, vsu

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


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3] VIA IRQ quirk behaviour change
  2006-09-11 21:38                           ` Stian Jordet
@ 2006-09-12 12:37                             ` Sergio Monteiro Basto
  2006-09-12 21:38                               ` Stian Jordet
  0 siblings, 1 reply; 34+ messages in thread
From: Sergio Monteiro Basto @ 2006-09-12 12:37 UTC (permalink / raw)
  To: Stian Jordet
  Cc: Alan Cox, Daniel Drake, akpm, torvalds, jeff, greg, cw,
	bjorn.helgaas, linux-kernel, harmon, len.brown, vsu

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. 


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3] VIA IRQ quirk behaviour change
  2006-09-12 12:37                             ` Sergio Monteiro Basto
@ 2006-09-12 21:38                               ` Stian Jordet
  2006-09-13  0:48                                 ` Sergio Monteiro Basto
  0 siblings, 1 reply; 34+ messages in thread
From: Stian Jordet @ 2006-09-12 21:38 UTC (permalink / raw)
  To: Sergio Monteiro Basto
  Cc: Alan Cox, Daniel Drake, akpm, torvalds, jeff, greg, cw,
	bjorn.helgaas, linux-kernel, harmon, len.brown, vsu

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


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3] VIA IRQ quirk behaviour change
  2006-09-12 21:38                               ` Stian Jordet
@ 2006-09-13  0:48                                 ` Sergio Monteiro Basto
  0 siblings, 0 replies; 34+ messages in thread
From: Sergio Monteiro Basto @ 2006-09-13  0:48 UTC (permalink / raw)
  To: Stian Jordet
  Cc: Alan Cox, Daniel Drake, akpm, torvalds, jeff, greg, cw,
	bjorn.helgaas, linux-kernel, harmon, len.brown, vsu

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

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.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2166 bytes --]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3] VIA IRQ quirk behaviour change
  2006-09-10 20:45               ` Matthew Garrett
  2006-09-10 21:30                 ` Lee Revell
@ 2006-09-19 20:04                 ` Lee Revell
  2006-09-19 20:12                   ` Matthew Garrett
  1 sibling, 1 reply; 34+ messages in thread
From: Lee Revell @ 2006-09-19 20:04 UTC (permalink / raw)
  To: Matthew Garrett
  Cc: Greg KH, Alan Cox, Daniel Drake, akpm, torvalds, sergio, jeff,
	cw, bjorn.helgaas, linux-kernel, harmon, len.brown, vsu, liste

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


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3] VIA IRQ quirk behaviour change
  2006-09-19 20:04                 ` Lee Revell
@ 2006-09-19 20:12                   ` Matthew Garrett
  2006-09-19 20:28                     ` Lee Revell
  0 siblings, 1 reply; 34+ messages in thread
From: Matthew Garrett @ 2006-09-19 20:12 UTC (permalink / raw)
  To: Lee Revell
  Cc: Greg KH, Alan Cox, Daniel Drake, akpm, torvalds, sergio, jeff,
	cw, bjorn.helgaas, linux-kernel, harmon, len.brown, vsu, liste

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 | mjg59@srcf.ucam.org

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3] VIA IRQ quirk behaviour change
  2006-09-19 20:12                   ` Matthew Garrett
@ 2006-09-19 20:28                     ` Lee Revell
  0 siblings, 0 replies; 34+ messages in thread
From: Lee Revell @ 2006-09-19 20:28 UTC (permalink / raw)
  To: Matthew Garrett
  Cc: Greg KH, Alan Cox, Daniel Drake, akpm, torvalds, sergio, jeff,
	cw, bjorn.helgaas, linux-kernel, harmon, len.brown, vsu, liste

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


^ permalink raw reply	[flat|nested] 34+ messages in thread

end of thread, other threads:[~2006-09-19 20:27 UTC | newest]

Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-09-07 22:33 [PATCH V3] VIA IRQ quirk behaviour change Daniel Drake
2006-09-09 14:20 ` Alan Cox
2006-09-09 14:44   ` Daniel Drake
2006-09-09 16:03     ` Alan Cox
2006-09-09 21:34       ` Daniel Drake
2006-09-10  0:31         ` Alan Cox
2006-09-10  0:21           ` Greg KH
2006-09-10  0:39             ` Chris Wedgwood
2006-09-10  4:37               ` Greg KH
2006-09-10  9:48                 ` Stian Jordet
2006-09-10 15:48             ` Daniel Drake
2006-09-10 18:40             ` Lee Revell
2006-09-10 20:45               ` Matthew Garrett
2006-09-10 21:30                 ` Lee Revell
2006-09-10 21:34                   ` Matthew Garrett
2006-09-19 20:04                 ` Lee Revell
2006-09-19 20:12                   ` Matthew Garrett
2006-09-19 20:28                     ` Lee Revell
2006-09-10 16:01           ` Daniel Drake
2006-09-10 16:39             ` Alan Cox
2006-09-10 16:44               ` Jeff Garzik
2006-09-10 19:06               ` Daniel Drake
2006-09-10 19:41                 ` Alan Cox
2006-09-10 19:21                   ` Stian Jordet
2006-09-11 15:33                     ` Sergio Monteiro Basto
2006-09-11 20:16                       ` Stian Jordet
2006-09-11 21:23                         ` Sergio Monteiro Basto
2006-09-11 21:38                           ` Stian Jordet
2006-09-12 12:37                             ` Sergio Monteiro Basto
2006-09-12 21:38                               ` Stian Jordet
2006-09-13  0:48                                 ` Sergio Monteiro Basto
2006-09-11 21:54                         ` Daniel Drake
2006-09-12  6:21                           ` Stian Jordet
2006-09-11 21:44                       ` Daniel Drake

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).