Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
Applied. thanks, -Len On Thu, 2005-03-24 at 13:24, Bjorn Helgaas wrote: > On Wed, 2005-03-23 at 13:40 -0500, Len Brown wrote: > > But checking skip_ioapic_setup in the non-ACPI case > > isn't quite right. This is set for "noapic". But > > it is not set in the PIC-mode case where the kernel > > supports IOAPIC but the hardware does not -- in that > > case the quirk would erroneously exit. > > Ah, right, thanks. I changed it to: > > if (nr_ioapics && !skip_ioapic_setup) > return; > > Is that better? > > > Also, the original quirk_via_irqpic() > > had a udelay(15) before the write -- I have no idea > > if that was significant or not -- maybe soembody else > > on the list does -- as none of us have VIA documentation... > > Yes, I was worried about that, too. I added it back. > > > ps. we need to fix this on 2.4 also. > > Here's yet another iteration for 2.6. If this works OK, > I can back-port it to 2.4. ... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
Applied. thanks, -Len On Thu, 2005-03-24 at 13:24, Bjorn Helgaas wrote: On Wed, 2005-03-23 at 13:40 -0500, Len Brown wrote: But checking skip_ioapic_setup in the non-ACPI case isn't quite right. This is set for noapic. But it is not set in the PIC-mode case where the kernel supports IOAPIC but the hardware does not -- in that case the quirk would erroneously exit. Ah, right, thanks. I changed it to: if (nr_ioapics !skip_ioapic_setup) return; Is that better? Also, the original quirk_via_irqpic() had a udelay(15) before the write -- I have no idea if that was significant or not -- maybe soembody else on the list does -- as none of us have VIA documentation... Yes, I was worried about that, too. I added it back. ps. we need to fix this on 2.4 also. Here's yet another iteration for 2.6. If this works OK, I can back-port it to 2.4. ... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
On Wed, 2005-03-23 at 13:40 -0500, Len Brown wrote:
> But checking skip_ioapic_setup in the non-ACPI case
> isn't quite right. This is set for "noapic". But
> it is not set in the PIC-mode case where the kernel
> supports IOAPIC but the hardware does not -- in that
> case the quirk would erroneously exit.
Ah, right, thanks. I changed it to:
if (nr_ioapics && !skip_ioapic_setup)
return;
Is that better?
> Also, the original quirk_via_irqpic()
> had a udelay(15) before the write -- I have no idea
> if that was significant or not -- maybe soembody else
> on the list does -- as none of us have VIA documentation...
Yes, I was worried about that, too. I added it back.
> ps. we need to fix this on 2.4 also.
Here's yet another iteration for 2.6. If this works OK,
I can back-port it to 2.4.
In PIC mode, some Via devices update IRQ routing when
PCI_INTERRUPT_LINE is written. So if we've updated the
device's IRQ, we also need to update PCI_INTERRUPT_LINE.
This also restores the mysterious "udelay(15)" before the
update because we don't know whether it's necessary and
haven't seen an argument for its removal.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
= arch/i386/pci/irq.c 1.55 vs edited =
--- 1.55/arch/i386/pci/irq.c2005-02-07 22:39:15 -07:00
+++ edited/arch/i386/pci/irq.c 2005-03-15 10:11:44 -07:00
@@ -1026,7 +1026,6 @@
static int pirq_enable_irq(struct pci_dev *dev)
{
u8 pin;
- extern int via_interrupt_line_quirk;
struct pci_dev *temp_dev;
pci_read_config_byte(dev, PCI_INTERRUPT_PIN, );
@@ -1081,10 +1080,6 @@
printk(KERN_WARNING "PCI: No IRQ known for interrupt pin %c of
device %s.%s\n",
'A' + pin, pci_name(dev), msg);
}
- /* VIA bridges use interrupt line for apic/pci steering across
- the V-Link */
- else if (via_interrupt_line_quirk)
- pci_write_config_byte(dev, PCI_INTERRUPT_LINE, dev->irq & 15);
return 0;
}
= drivers/acpi/pci_irq.c 1.37 vs edited =
--- 1.37/drivers/acpi/pci_irq.c 2005-03-01 09:57:29 -07:00
+++ edited/drivers/acpi/pci_irq.c 2005-03-15 10:10:57 -07:00
@@ -388,7 +388,6 @@
u8 pin = 0;
int edge_level = ACPI_LEVEL_SENSITIVE;
int active_high_low = ACPI_ACTIVE_LOW;
- extern int via_interrupt_line_quirk;
ACPI_FUNCTION_TRACE("acpi_pci_irq_enable");
@@ -437,9 +436,6 @@
return_VALUE(0);
}
}
-
- if (via_interrupt_line_quirk)
- pci_write_config_byte(dev, PCI_INTERRUPT_LINE, irq & 15);
dev->irq = acpi_register_gsi(irq, edge_level, active_high_low);
= drivers/pci/quirks.c 1.72 vs edited =
--- 1.72/drivers/pci/quirks.c 2005-03-10 01:38:25 -07:00
+++ edited/drivers/pci/quirks.c 2005-03-24 11:07:19 -07:00
@@ -683,19 +683,41 @@
}
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82454NX,
quirk_disable_pxb );
-/*
- * VIA northbridges care about PCI_INTERRUPT_LINE
- */
-int via_interrupt_line_quirk;
+#ifdef CONFIG_ACPI
+#include
+#endif
-static void __devinit quirk_via_bridge(struct pci_dev *pdev)
+static void __devinit quirk_via_irqpic(struct pci_dev *dev)
{
- if(pdev->devfn == 0) {
- printk(KERN_INFO "PCI: Via IRQ fixup\n");
- via_interrupt_line_quirk = 1;
+ u8 irq, new_irq;
+
+#ifdef CONFIG_X86_IO_APIC
+ if (nr_ioapics && !skip_ioapic_setup)
+ return;
+#endif
+#ifdef CONFIG_ACPI
+ if (acpi_irq_model != ACPI_IRQ_MODEL_PIC)
+ return;
+#endif
+ /*
+* Some Via devices make an internal connection to the PIC when the
+* PCI_INTERRUPT_LINE register is written. If we've changed the
+* device's IRQ, we need to update this routing.
+*
+* I suspect this only happens for devices on the same chip as the
+* PIC, but I don't know how to identify those without listing them
+* all individually, which is a maintenance problem.
+*/
+ new_irq = dev->irq & 0xf;
+ pci_read_config_byte(dev, PCI_INTERRUPT_LINE, );
+ if (new_irq != irq) {
+ printk(KERN_INFO "PCI: Via PIC IRQ fixup for %s, from %d to
%d\n",
+ pci_name(dev), irq, new_irq);
+ udelay(15);
+ pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
}
}
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA,PCI_ANY_ID,
quirk_via_bridge );
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irqpic);
/*
* Serverworks CSB5 IDE does not fully support native mode
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
On Wed, 2005-03-23 at 13:40 -0500, Len Brown wrote:
But checking skip_ioapic_setup in the non-ACPI case
isn't quite right. This is set for noapic. But
it is not set in the PIC-mode case where the kernel
supports IOAPIC but the hardware does not -- in that
case the quirk would erroneously exit.
Ah, right, thanks. I changed it to:
if (nr_ioapics !skip_ioapic_setup)
return;
Is that better?
Also, the original quirk_via_irqpic()
had a udelay(15) before the write -- I have no idea
if that was significant or not -- maybe soembody else
on the list does -- as none of us have VIA documentation...
Yes, I was worried about that, too. I added it back.
ps. we need to fix this on 2.4 also.
Here's yet another iteration for 2.6. If this works OK,
I can back-port it to 2.4.
In PIC mode, some Via devices update IRQ routing when
PCI_INTERRUPT_LINE is written. So if we've updated the
device's IRQ, we also need to update PCI_INTERRUPT_LINE.
This also restores the mysterious udelay(15) before the
update because we don't know whether it's necessary and
haven't seen an argument for its removal.
Signed-off-by: Bjorn Helgaas [EMAIL PROTECTED]
= arch/i386/pci/irq.c 1.55 vs edited =
--- 1.55/arch/i386/pci/irq.c2005-02-07 22:39:15 -07:00
+++ edited/arch/i386/pci/irq.c 2005-03-15 10:11:44 -07:00
@@ -1026,7 +1026,6 @@
static int pirq_enable_irq(struct pci_dev *dev)
{
u8 pin;
- extern int via_interrupt_line_quirk;
struct pci_dev *temp_dev;
pci_read_config_byte(dev, PCI_INTERRUPT_PIN, pin);
@@ -1081,10 +1080,6 @@
printk(KERN_WARNING PCI: No IRQ known for interrupt pin %c of
device %s.%s\n,
'A' + pin, pci_name(dev), msg);
}
- /* VIA bridges use interrupt line for apic/pci steering across
- the V-Link */
- else if (via_interrupt_line_quirk)
- pci_write_config_byte(dev, PCI_INTERRUPT_LINE, dev-irq 15);
return 0;
}
= drivers/acpi/pci_irq.c 1.37 vs edited =
--- 1.37/drivers/acpi/pci_irq.c 2005-03-01 09:57:29 -07:00
+++ edited/drivers/acpi/pci_irq.c 2005-03-15 10:10:57 -07:00
@@ -388,7 +388,6 @@
u8 pin = 0;
int edge_level = ACPI_LEVEL_SENSITIVE;
int active_high_low = ACPI_ACTIVE_LOW;
- extern int via_interrupt_line_quirk;
ACPI_FUNCTION_TRACE(acpi_pci_irq_enable);
@@ -437,9 +436,6 @@
return_VALUE(0);
}
}
-
- if (via_interrupt_line_quirk)
- pci_write_config_byte(dev, PCI_INTERRUPT_LINE, irq 15);
dev-irq = acpi_register_gsi(irq, edge_level, active_high_low);
= drivers/pci/quirks.c 1.72 vs edited =
--- 1.72/drivers/pci/quirks.c 2005-03-10 01:38:25 -07:00
+++ edited/drivers/pci/quirks.c 2005-03-24 11:07:19 -07:00
@@ -683,19 +683,41 @@
}
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82454NX,
quirk_disable_pxb );
-/*
- * VIA northbridges care about PCI_INTERRUPT_LINE
- */
-int via_interrupt_line_quirk;
+#ifdef CONFIG_ACPI
+#include linux/acpi.h
+#endif
-static void __devinit quirk_via_bridge(struct pci_dev *pdev)
+static void __devinit quirk_via_irqpic(struct pci_dev *dev)
{
- if(pdev-devfn == 0) {
- printk(KERN_INFO PCI: Via IRQ fixup\n);
- via_interrupt_line_quirk = 1;
+ u8 irq, new_irq;
+
+#ifdef CONFIG_X86_IO_APIC
+ if (nr_ioapics !skip_ioapic_setup)
+ return;
+#endif
+#ifdef CONFIG_ACPI
+ if (acpi_irq_model != ACPI_IRQ_MODEL_PIC)
+ return;
+#endif
+ /*
+* Some Via devices make an internal connection to the PIC when the
+* PCI_INTERRUPT_LINE register is written. If we've changed the
+* device's IRQ, we need to update this routing.
+*
+* I suspect this only happens for devices on the same chip as the
+* PIC, but I don't know how to identify those without listing them
+* all individually, which is a maintenance problem.
+*/
+ new_irq = dev-irq 0xf;
+ pci_read_config_byte(dev, PCI_INTERRUPT_LINE, irq);
+ if (new_irq != irq) {
+ printk(KERN_INFO PCI: Via PIC IRQ fixup for %s, from %d to
%d\n,
+ pci_name(dev), irq, new_irq);
+ udelay(15);
+ pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
}
}
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA,PCI_ANY_ID,
quirk_via_bridge );
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irqpic);
/*
* Serverworks CSB5 IDE does not fully support native mode
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
Bjorn, I like how pci_fixup_device() invokes the quirk when we want at pci_enable_device() time w/o cluttering the code with VIA specific hooks. I think you've also identified an improvement by checking acpi_irq_model -- as the PCI config space IRQ register is defined only in PIC-mode -- so one must assume that the quirky via HW can't depend on us writing reserved bits for IRQs > 15. But checking skip_ioapic_setup in the non-ACPI case isn't quite right. This is set for "noapic". But it is not set in the PIC-mode case where the kernel supports IOAPIC but the hardware does not -- in that case the quirk would erroneously exit. Also, the original quirk_via_irqpic() had a udelay(15) before the write -- I have no idea if that was significant or not -- maybe soembody else on the list does -- as none of us have VIA documentation... thanks, -Len ps. we need to fix this on 2.4 also. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
Bjorn, I like how pci_fixup_device() invokes the quirk when we want at pci_enable_device() time w/o cluttering the code with VIA specific hooks. I think you've also identified an improvement by checking acpi_irq_model -- as the PCI config space IRQ register is defined only in PIC-mode -- so one must assume that the quirky via HW can't depend on us writing reserved bits for IRQs 15. But checking skip_ioapic_setup in the non-ACPI case isn't quite right. This is set for noapic. But it is not set in the PIC-mode case where the kernel supports IOAPIC but the hardware does not -- in that case the quirk would erroneously exit. Also, the original quirk_via_irqpic() had a udelay(15) before the write -- I have no idea if that was significant or not -- maybe soembody else on the list does -- as none of us have VIA documentation... thanks, -Len ps. we need to fix this on 2.4 also. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
> On Wed, 2005-03-23 at 04:57, Bjorn Helgaas wrote:
>> Great. Shaohua, where should we go from here? Do you have more
>> concerns with the current patch, or should we ask Andrew to put it
>> in -mm? If you do have concerns, would you like to propose an
>> alternate patch that fixes the problem for Grzegorz?
> No, the patch is great to me.
Good. Thanks for all the help in refining this!
Andrew, can we put this in -mm?
BTW, I also have a report that this fixes a problem like
the following. I've had several similar reports that initially
seemed to be related to "pci=routeirq", so I'm optimistic that
fixing this Via problem will help several folks.
Probing IDE interface ide2...
hde: _NEC DV-5700A, ATAPI CD/DVD-ROM drive
irq 11: nobody cared!
[] __report_bad_irq+0x2a/0x90
[] handle_IRQ_event+0x39/0x70
[] note_interrupt+0xa3/0xd0
[] __do_IRQ+0x160/0x180
[] do_IRQ+0x19/0x30
[] common_interrupt+0x1a/0x20
[] __do_softirq+0x30/0x90
[] do_softirq+0x26/0x30
[] irq_exit+0x35/0x40
[] do_IRQ+0x1e/0x30
[] common_interrupt+0x1a/0x20
[] enable_irq+0x43/0x110
[] ide_config_drive_speed+0x149/0x380
[] hpt370_tune_chipset+0x158/0x160
[] hpt366_config_drive_xfer_rate+0x3c/0xa0
[] probe_hwif+0x420/0x490
[] probe_hwif_init_with_fixup+0x1b/0x70
[] ide_setup_pci_device+0x5b/0xa0
[] init_setup_hpt366+0x17e/0x1b0
[] hpt366_init_one+0x28/0x30
[] ide_scan_pcidev+0x4d/0x70
[] ide_scan_pcibus+0x28/0xc0
[] probe_for_hwifs+0x10/0x20
[] ide_init+0x5e/0x80
[] do_initcalls+0x53/0xc0
[] init+0x0/0x120
[] init+0x2f/0x120
[] kernel_thread_helper+0x0/0x10
[] kernel_thread_helper+0x5/0x10
handlers:
[] (acpi_irq+0x0/0x16)
Disabling IRQ #11
On Fri, 2005-03-18 at 11:07 -0700, Bjorn Helgaas wrote:
> OK. Try this one for size. It differs from what's currently in
> the tree in these ways:
>
> - It's a quirk, so we don't have to clutter acpi_pci_irq_enable()
> and pirq_enable_irq() with Via-specific code.
>
> - It doesn't do anything unless we're in PIC mode. The comment
> suggests this issue only affects PIC routing.
>
> - We do this for ALL Via devices. The current code in the tree
> does it for all devices in the system IF there is a Via device
> with devfn==0, which misses Grzegorz's case.
>
> Does anybody have a pointer to a spec that talks about this? It'd
> be awfully nice to have a reference.
>
> Grzegorz, can you check to make sure this still works after all the
> tweaking?
Oops, I had the sense of the skip_ioapic_setup test reversed. Corrected
patch follows.
= arch/i386/pci/irq.c 1.55 vs edited =
--- 1.55/arch/i386/pci/irq.c2005-02-07 22:39:15 -07:00
+++ edited/arch/i386/pci/irq.c 2005-03-15 10:11:44 -07:00
@@ -1026,7 +1026,6 @@
static int pirq_enable_irq(struct pci_dev *dev)
{
u8 pin;
- extern int via_interrupt_line_quirk;
struct pci_dev *temp_dev;
pci_read_config_byte(dev, PCI_INTERRUPT_PIN, );
@@ -1081,10 +1080,6 @@
printk(KERN_WARNING "PCI: No IRQ known for interrupt pin %c of
device %s.%s\n",
'A' + pin, pci_name(dev), msg);
}
- /* VIA bridges use interrupt line for apic/pci steering across
- the V-Link */
- else if (via_interrupt_line_quirk)
- pci_write_config_byte(dev, PCI_INTERRUPT_LINE, dev->irq & 15);
return 0;
}
= drivers/acpi/pci_irq.c 1.37 vs edited =
--- 1.37/drivers/acpi/pci_irq.c 2005-03-01 09:57:29 -07:00
+++ edited/drivers/acpi/pci_irq.c 2005-03-15 10:10:57 -07:00
@@ -388,7 +388,6 @@
u8 pin = 0;
int edge_level = ACPI_LEVEL_SENSITIVE;
int active_high_low = ACPI_ACTIVE_LOW;
- extern int via_interrupt_line_quirk;
ACPI_FUNCTION_TRACE("acpi_pci_irq_enable");
@@ -437,9 +436,6 @@
return_VALUE(0);
}
}
-
- if (via_interrupt_line_quirk)
- pci_write_config_byte(dev, PCI_INTERRUPT_LINE, irq & 15);
dev->irq = acpi_register_gsi(irq, edge_level, active_high_low);
= drivers/pci/quirks.c 1.72 vs edited =
--- 1.72/drivers/pci/quirks.c 2005-03-10 01:38:25 -07:00
+++ edited/drivers/pci/quirks.c 2005-03-21 09:22:23 -07:00
@@ -683,19 +683,40 @@
}
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82454NX,
quirk_disable_pxb );
-/*
- * VIA northbridges care about PCI_INTERRUPT_LINE
- */
-int via_interrupt_line_quirk;
+#ifdef CONFIG_ACPI
+#include
+#endif
-static void __devinit quirk_via_bridge(struct pci_dev *pdev)
+static void __devinit quirk_via_irqpic(struct pci_dev *dev)
{
- if(pdev->devfn == 0) {
- printk(KERN_INFO "PCI: Via IRQ fixup\n");
- via_interrupt_line_quirk = 1;
+ u8 irq, new_irq;
+
+#ifdef CONFIG_X86_IO_APIC
+ if (!skip_ioapic_setup)
+ return;
+#endif
+#ifdef CONFIG_ACPI
+ if (acpi_irq_model !=
Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
On Wed, 2005-03-23 at 04:57, Bjorn Helgaas wrote: > > Your patch applied with some problems: > > > > patching file arch/i386/pci/irq.c > > Hunk #2 succeeded at 1081 with fuzz 2 (offset 1 line). > > patching file drivers/acpi/pci_irq.c > > patching file drivers/pci/quirks.c > > Hunk #1 succeeded at 678 (offset -5 lines). > > These indicate minor differences in these files between upstream BK > (which is what my patch was against) and the kernel you're building. > You can ignore them. > > > Then I tested it and it works (at least my speedtouch still works). > > Great. Shaohua, where should we go from here? Do you have more > concerns with the current patch, or should we ask Andrew to put it > in -mm? If you do have concerns, would you like to propose an > alternate patch that fixes the problem for Grzegorz? No, the patch is great to me. Thanks, Shaohua - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
> Your patch applied with some problems: > > patching file arch/i386/pci/irq.c > Hunk #2 succeeded at 1081 with fuzz 2 (offset 1 line). > patching file drivers/acpi/pci_irq.c > patching file drivers/pci/quirks.c > Hunk #1 succeeded at 678 (offset -5 lines). These indicate minor differences in these files between upstream BK (which is what my patch was against) and the kernel you're building. You can ignore them. > Then I tested it and it works (at least my speedtouch still works). Great. Shaohua, where should we go from here? Do you have more concerns with the current patch, or should we ask Andrew to put it in -mm? If you do have concerns, would you like to propose an alternate patch that fixes the problem for Grzegorz? > Mar 22 01:32:37 kangur speedtch: Unknown symbol release_firmware > Mar 22 01:32:37 kangur usb 1-2: modprobe timed out on ep0in I don't know about the above messages, but I don't think they're related to the Via quirk we're working on at the moment. Probably some mismatch between the kernel you built and the modules. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
Your patch applied with some problems: patching file arch/i386/pci/irq.c Hunk #2 succeeded at 1081 with fuzz 2 (offset 1 line). patching file drivers/acpi/pci_irq.c patching file drivers/pci/quirks.c Hunk #1 succeeded at 678 (offset -5 lines). These indicate minor differences in these files between upstream BK (which is what my patch was against) and the kernel you're building. You can ignore them. Then I tested it and it works (at least my speedtouch still works). Great. Shaohua, where should we go from here? Do you have more concerns with the current patch, or should we ask Andrew to put it in -mm? If you do have concerns, would you like to propose an alternate patch that fixes the problem for Grzegorz? Mar 22 01:32:37 kangur speedtch: Unknown symbol release_firmware Mar 22 01:32:37 kangur usb 1-2: modprobe timed out on ep0in I don't know about the above messages, but I don't think they're related to the Via quirk we're working on at the moment. Probably some mismatch between the kernel you built and the modules. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
On Wed, 2005-03-23 at 04:57, Bjorn Helgaas wrote: Your patch applied with some problems: patching file arch/i386/pci/irq.c Hunk #2 succeeded at 1081 with fuzz 2 (offset 1 line). patching file drivers/acpi/pci_irq.c patching file drivers/pci/quirks.c Hunk #1 succeeded at 678 (offset -5 lines). These indicate minor differences in these files between upstream BK (which is what my patch was against) and the kernel you're building. You can ignore them. Then I tested it and it works (at least my speedtouch still works). Great. Shaohua, where should we go from here? Do you have more concerns with the current patch, or should we ask Andrew to put it in -mm? If you do have concerns, would you like to propose an alternate patch that fixes the problem for Grzegorz? No, the patch is great to me. Thanks, Shaohua - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
On Wed, 2005-03-23 at 04:57, Bjorn Helgaas wrote:
Great. Shaohua, where should we go from here? Do you have more
concerns with the current patch, or should we ask Andrew to put it
in -mm? If you do have concerns, would you like to propose an
alternate patch that fixes the problem for Grzegorz?
No, the patch is great to me.
Good. Thanks for all the help in refining this!
Andrew, can we put this in -mm?
BTW, I also have a report that this fixes a problem like
the following. I've had several similar reports that initially
seemed to be related to pci=routeirq, so I'm optimistic that
fixing this Via problem will help several folks.
Probing IDE interface ide2...
hde: _NEC DV-5700A, ATAPI CD/DVD-ROM drive
irq 11: nobody cared!
[c013769a] __report_bad_irq+0x2a/0x90
[c0136f99] handle_IRQ_event+0x39/0x70
[c01377c3] note_interrupt+0xa3/0xd0
[c0137130] __do_IRQ+0x160/0x180
[c0105649] do_IRQ+0x19/0x30
[c0103b4e] common_interrupt+0x1a/0x20
[c011eb00] __do_softirq+0x30/0x90
[c011eb86] do_softirq+0x26/0x30
[c0136f55] irq_exit+0x35/0x40
[c010564e] do_IRQ+0x1e/0x30
[c0103b4e] common_interrupt+0x1a/0x20
[c0137243] enable_irq+0x43/0x110
[c023adc9] ide_config_drive_speed+0x149/0x380
[c022ff38] hpt370_tune_chipset+0x158/0x160
[c02303dc] hpt366_config_drive_xfer_rate+0x3c/0xa0
[c023d310] probe_hwif+0x420/0x490
[c023d39b] probe_hwif_init_with_fixup+0x1b/0x70
[c0240a6b] ide_setup_pci_device+0x5b/0xa0
[c0231dbe] init_setup_hpt366+0x17e/0x1b0
[c0231e18] hpt366_init_one+0x28/0x30
[c039ccad] ide_scan_pcidev+0x4d/0x70
[c039ccf8] ide_scan_pcibus+0x28/0xc0
[c039cbd0] probe_for_hwifs+0x10/0x20
[c039cc3e] ide_init+0x5e/0x80
[c03808b3] do_initcalls+0x53/0xc0
[c0100410] init+0x0/0x120
[c010043f] init+0x2f/0x120
[c01012c0] kernel_thread_helper+0x0/0x10
[c01012c5] kernel_thread_helper+0x5/0x10
handlers:
[c01df538] (acpi_irq+0x0/0x16)
Disabling IRQ #11
On Fri, 2005-03-18 at 11:07 -0700, Bjorn Helgaas wrote:
OK. Try this one for size. It differs from what's currently in
the tree in these ways:
- It's a quirk, so we don't have to clutter acpi_pci_irq_enable()
and pirq_enable_irq() with Via-specific code.
- It doesn't do anything unless we're in PIC mode. The comment
suggests this issue only affects PIC routing.
- We do this for ALL Via devices. The current code in the tree
does it for all devices in the system IF there is a Via device
with devfn==0, which misses Grzegorz's case.
Does anybody have a pointer to a spec that talks about this? It'd
be awfully nice to have a reference.
Grzegorz, can you check to make sure this still works after all the
tweaking?
Oops, I had the sense of the skip_ioapic_setup test reversed. Corrected
patch follows.
= arch/i386/pci/irq.c 1.55 vs edited =
--- 1.55/arch/i386/pci/irq.c2005-02-07 22:39:15 -07:00
+++ edited/arch/i386/pci/irq.c 2005-03-15 10:11:44 -07:00
@@ -1026,7 +1026,6 @@
static int pirq_enable_irq(struct pci_dev *dev)
{
u8 pin;
- extern int via_interrupt_line_quirk;
struct pci_dev *temp_dev;
pci_read_config_byte(dev, PCI_INTERRUPT_PIN, pin);
@@ -1081,10 +1080,6 @@
printk(KERN_WARNING PCI: No IRQ known for interrupt pin %c of
device %s.%s\n,
'A' + pin, pci_name(dev), msg);
}
- /* VIA bridges use interrupt line for apic/pci steering across
- the V-Link */
- else if (via_interrupt_line_quirk)
- pci_write_config_byte(dev, PCI_INTERRUPT_LINE, dev-irq 15);
return 0;
}
= drivers/acpi/pci_irq.c 1.37 vs edited =
--- 1.37/drivers/acpi/pci_irq.c 2005-03-01 09:57:29 -07:00
+++ edited/drivers/acpi/pci_irq.c 2005-03-15 10:10:57 -07:00
@@ -388,7 +388,6 @@
u8 pin = 0;
int edge_level = ACPI_LEVEL_SENSITIVE;
int active_high_low = ACPI_ACTIVE_LOW;
- extern int via_interrupt_line_quirk;
ACPI_FUNCTION_TRACE(acpi_pci_irq_enable);
@@ -437,9 +436,6 @@
return_VALUE(0);
}
}
-
- if (via_interrupt_line_quirk)
- pci_write_config_byte(dev, PCI_INTERRUPT_LINE, irq 15);
dev-irq = acpi_register_gsi(irq, edge_level, active_high_low);
= drivers/pci/quirks.c 1.72 vs edited =
--- 1.72/drivers/pci/quirks.c 2005-03-10 01:38:25 -07:00
+++ edited/drivers/pci/quirks.c 2005-03-21 09:22:23 -07:00
@@ -683,19 +683,40 @@
}
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82454NX,
quirk_disable_pxb );
-/*
- * VIA northbridges care about PCI_INTERRUPT_LINE
- */
-int via_interrupt_line_quirk;
+#ifdef CONFIG_ACPI
+#include linux/acpi.h
+#endif
-static void __devinit quirk_via_bridge(struct pci_dev *pdev)
+static void __devinit quirk_via_irqpic(struct pci_dev *dev)
{
- if(pdev-devfn == 0) {
- printk(KERN_INFO PCI: Via IRQ fixup\n);
-
Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
On Mon, 21 Mar 2005, Bjorn Helgaas wrote: On Fri, 2005-03-18 at 11:07 -0700, Bjorn Helgaas wrote: OK. Try this one for size. It differs from what's currently in the tree in these ways: - It's a quirk, so we don't have to clutter acpi_pci_irq_enable() and pirq_enable_irq() with Via-specific code. - It doesn't do anything unless we're in PIC mode. The comment suggests this issue only affects PIC routing. - We do this for ALL Via devices. The current code in the tree does it for all devices in the system IF there is a Via device with devfn==0, which misses Grzegorz's case. Does anybody have a pointer to a spec that talks about this? It'd be awfully nice to have a reference. Grzegorz, can you check to make sure this still works after all the tweaking? Oops, I had the sense of the skip_ioapic_setup test reversed. Corrected patch follows. Hi, Your patch applied with some problems: patching file arch/i386/pci/irq.c Hunk #2 succeeded at 1081 with fuzz 2 (offset 1 line). patching file drivers/acpi/pci_irq.c patching file drivers/pci/quirks.c Hunk #1 succeeded at 678 (offset -5 lines). (I do not know why). Then I tested it and it works (at least my speedtouch still works). Here is the log: Mar 22 01:32:37 kangur Linux version 2.6.11-cko1 ([EMAIL PROTECTED]) (gcc version 3.3.3 20040412 (Gentoo Linux 3.3.3-r6, ssp-3.3.2-2, pie-8.7.6)) #4 Tue Mar 22 01:24:18 CET 2005 Mar 22 01:32:37 kangur BIOS-provided physical RAM map: Mar 22 01:32:37 kangur BIOS-e820: - 0009fc00 (usable) Mar 22 01:32:37 kangur BIOS-e820: 0009fc00 - 000a (reserved) Mar 22 01:32:37 kangur BIOS-e820: 000f - 0010 (reserved) Mar 22 01:32:37 kangur BIOS-e820: 0010 - 1fff (usable) Mar 22 01:32:37 kangur BIOS-e820: 1fff - 1fff3000 (ACPI NVS) Mar 22 01:32:37 kangur BIOS-e820: 1fff3000 - 2000 (ACPI data) Mar 22 01:32:37 kangur BIOS-e820: - 0001 (reserved) Mar 22 01:32:37 kangur 511MB LOWMEM available. Mar 22 01:32:37 kangur On node 0 totalpages: 131056 Mar 22 01:32:37 kangur DMA zone: 4096 pages, LIFO batch:1 Mar 22 01:32:37 kangur Normal zone: 126960 pages, LIFO batch:16 Mar 22 01:32:37 kangur HighMem zone: 0 pages, LIFO batch:1 Mar 22 01:32:37 kangur DMI 2.2 present. Mar 22 01:32:37 kangur ACPI: RSDP (v000 761686 ) @ 0x000f6a70 Mar 22 01:32:37 kangur ACPI: RSDT (v001 761686 AWRDACPI 0x42302e31 AWRD 0x) @ 0x1fff3000 Mar 22 01:32:37 kangur ACPI: FADT (v001 761686 AWRDACPI 0x42302e31 AWRD 0x) @ 0x1fff3040 Mar 22 01:32:37 kangur ACPI: DSDT (v001 761686 AWRDACPI 0x1000 MSFT 0x010c) @ 0x Mar 22 01:32:37 kangur ACPI: PM-Timer IO Port: 0x4008 Mar 22 01:32:37 kangur Allocating PCI resources starting at 2000 (gap: 2000:dfff) Mar 22 01:32:37 kangur Built 1 zonelists Mar 22 01:32:37 kangur Kernel command line: ro root=/dev/hdb4 Mar 22 01:32:37 kangur Local APIC disabled by BIOS -- you can enable it with "lapic" Mar 22 01:32:37 kangur mapped APIC to d000 (01402000) Mar 22 01:32:37 kangur Initializing CPU#0 Mar 22 01:32:37 kangur CPU 0 irqstacks, hard=b0477000 soft=b0476000 Mar 22 01:32:37 kangur PID hash table entries: 2048 (order: 11, 32768 bytes) Mar 22 01:32:37 kangur Detected 1203.036 MHz processor. Mar 22 01:32:37 kangur Using pmtmr for high-res timesource Mar 22 01:32:37 kangur Console: colour VGA+ 80x25 Mar 22 01:32:37 kangur Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Mar 22 01:32:37 kangur Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Mar 22 01:32:37 kangur Memory: 514940k/524224k available (2543k kernel code, 8732k reserved, 819k data, 156k init, 0k highmem) Mar 22 01:32:37 kangur Checking if this processor honours the WP bit even in supervisor mode... Ok. Mar 22 01:32:37 kangur Calibrating delay loop... 2375.68 BogoMIPS (lpj=1187840) Mar 22 01:32:37 kangur Security Framework v1.0.0 initialized Mar 22 01:32:37 kangur Capability LSM initialized Mar 22 01:32:37 kangur Mount-cache hash table entries: 512 (order: 0, 4096 bytes) Mar 22 01:32:37 kangur CPU: After generic identify, caps: 0383f9ff c1cbf9ff Mar 22 01:32:37 kangur CPU: After vendor identify, caps: 0383f9ff c1cbf9ff Mar 22 01:32:37 kangur CPU: CLK_CTL MSR was 60071263. Reprogramming to 20071263 Mar 22 01:32:37 kangur CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) Mar 22 01:32:37 kangur CPU: L2 Cache: 512K (64 bytes/line) Mar 22 01:32:37 kangur CPU: After all inits, caps: 0383f9ff c1cbf9ff 0020 Mar 22 01:32:37 kangur Intel machine check architecture supported. Mar 22 01:32:37 kangur Intel machine check reporting enabled on CPU#0. Mar 22 01:32:37 kangur CPU: AMD Unknown CPU Type stepping 00 Mar 22 01:32:37 kangur Enabling fast FPU save and
Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
On Fri, 2005-03-18 at 11:07 -0700, Bjorn Helgaas wrote:
> OK. Try this one for size. It differs from what's currently in
> the tree in these ways:
>
> - It's a quirk, so we don't have to clutter acpi_pci_irq_enable()
> and pirq_enable_irq() with Via-specific code.
>
> - It doesn't do anything unless we're in PIC mode. The comment
> suggests this issue only affects PIC routing.
>
> - We do this for ALL Via devices. The current code in the tree
> does it for all devices in the system IF there is a Via device
> with devfn==0, which misses Grzegorz's case.
>
> Does anybody have a pointer to a spec that talks about this? It'd
> be awfully nice to have a reference.
>
> Grzegorz, can you check to make sure this still works after all the
> tweaking?
Oops, I had the sense of the skip_ioapic_setup test reversed. Corrected
patch follows.
= arch/i386/pci/irq.c 1.55 vs edited =
--- 1.55/arch/i386/pci/irq.c2005-02-07 22:39:15 -07:00
+++ edited/arch/i386/pci/irq.c 2005-03-15 10:11:44 -07:00
@@ -1026,7 +1026,6 @@
static int pirq_enable_irq(struct pci_dev *dev)
{
u8 pin;
- extern int via_interrupt_line_quirk;
struct pci_dev *temp_dev;
pci_read_config_byte(dev, PCI_INTERRUPT_PIN, );
@@ -1081,10 +1080,6 @@
printk(KERN_WARNING "PCI: No IRQ known for interrupt pin %c of
device %s.%s\n",
'A' + pin, pci_name(dev), msg);
}
- /* VIA bridges use interrupt line for apic/pci steering across
- the V-Link */
- else if (via_interrupt_line_quirk)
- pci_write_config_byte(dev, PCI_INTERRUPT_LINE, dev->irq & 15);
return 0;
}
= drivers/acpi/pci_irq.c 1.37 vs edited =
--- 1.37/drivers/acpi/pci_irq.c 2005-03-01 09:57:29 -07:00
+++ edited/drivers/acpi/pci_irq.c 2005-03-15 10:10:57 -07:00
@@ -388,7 +388,6 @@
u8 pin = 0;
int edge_level = ACPI_LEVEL_SENSITIVE;
int active_high_low = ACPI_ACTIVE_LOW;
- extern int via_interrupt_line_quirk;
ACPI_FUNCTION_TRACE("acpi_pci_irq_enable");
@@ -437,9 +436,6 @@
return_VALUE(0);
}
}
-
- if (via_interrupt_line_quirk)
- pci_write_config_byte(dev, PCI_INTERRUPT_LINE, irq & 15);
dev->irq = acpi_register_gsi(irq, edge_level, active_high_low);
= drivers/pci/quirks.c 1.72 vs edited =
--- 1.72/drivers/pci/quirks.c 2005-03-10 01:38:25 -07:00
+++ edited/drivers/pci/quirks.c 2005-03-21 09:22:23 -07:00
@@ -683,19 +683,40 @@
}
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82454NX,
quirk_disable_pxb );
-/*
- * VIA northbridges care about PCI_INTERRUPT_LINE
- */
-int via_interrupt_line_quirk;
+#ifdef CONFIG_ACPI
+#include
+#endif
-static void __devinit quirk_via_bridge(struct pci_dev *pdev)
+static void __devinit quirk_via_irqpic(struct pci_dev *dev)
{
- if(pdev->devfn == 0) {
- printk(KERN_INFO "PCI: Via IRQ fixup\n");
- via_interrupt_line_quirk = 1;
+ u8 irq, new_irq;
+
+#ifdef CONFIG_X86_IO_APIC
+ if (!skip_ioapic_setup)
+ return;
+#endif
+#ifdef CONFIG_ACPI
+ if (acpi_irq_model != ACPI_IRQ_MODEL_PIC)
+ return;
+#endif
+ /*
+* Some Via devices make an internal connection to the PIC when the
+* PCI_INTERRUPT_LINE register is written. If we've changed the
+* device's IRQ, we need to update this routing.
+*
+* I suspect this only happens for devices on the same chip as the
+* PIC, but I don't know how to identify those without listing them
+* all individually, which is a maintenance problem.
+*/
+ new_irq = dev->irq & 0xf;
+ pci_read_config_byte(dev, PCI_INTERRUPT_LINE, );
+ if (new_irq != irq) {
+ printk(KERN_INFO "PCI: Via PIC IRQ fixup for %s, from %d to
%d\n",
+ pci_name(dev), irq, new_irq);
+ pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
}
}
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA,PCI_ANY_ID,
quirk_via_bridge );
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irqpic);
/*
* Serverworks CSB5 IDE does not fully support native mode
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
On Fri, 2005-03-18 at 11:07 -0700, Bjorn Helgaas wrote:
OK. Try this one for size. It differs from what's currently in
the tree in these ways:
- It's a quirk, so we don't have to clutter acpi_pci_irq_enable()
and pirq_enable_irq() with Via-specific code.
- It doesn't do anything unless we're in PIC mode. The comment
suggests this issue only affects PIC routing.
- We do this for ALL Via devices. The current code in the tree
does it for all devices in the system IF there is a Via device
with devfn==0, which misses Grzegorz's case.
Does anybody have a pointer to a spec that talks about this? It'd
be awfully nice to have a reference.
Grzegorz, can you check to make sure this still works after all the
tweaking?
Oops, I had the sense of the skip_ioapic_setup test reversed. Corrected
patch follows.
= arch/i386/pci/irq.c 1.55 vs edited =
--- 1.55/arch/i386/pci/irq.c2005-02-07 22:39:15 -07:00
+++ edited/arch/i386/pci/irq.c 2005-03-15 10:11:44 -07:00
@@ -1026,7 +1026,6 @@
static int pirq_enable_irq(struct pci_dev *dev)
{
u8 pin;
- extern int via_interrupt_line_quirk;
struct pci_dev *temp_dev;
pci_read_config_byte(dev, PCI_INTERRUPT_PIN, pin);
@@ -1081,10 +1080,6 @@
printk(KERN_WARNING PCI: No IRQ known for interrupt pin %c of
device %s.%s\n,
'A' + pin, pci_name(dev), msg);
}
- /* VIA bridges use interrupt line for apic/pci steering across
- the V-Link */
- else if (via_interrupt_line_quirk)
- pci_write_config_byte(dev, PCI_INTERRUPT_LINE, dev-irq 15);
return 0;
}
= drivers/acpi/pci_irq.c 1.37 vs edited =
--- 1.37/drivers/acpi/pci_irq.c 2005-03-01 09:57:29 -07:00
+++ edited/drivers/acpi/pci_irq.c 2005-03-15 10:10:57 -07:00
@@ -388,7 +388,6 @@
u8 pin = 0;
int edge_level = ACPI_LEVEL_SENSITIVE;
int active_high_low = ACPI_ACTIVE_LOW;
- extern int via_interrupt_line_quirk;
ACPI_FUNCTION_TRACE(acpi_pci_irq_enable);
@@ -437,9 +436,6 @@
return_VALUE(0);
}
}
-
- if (via_interrupt_line_quirk)
- pci_write_config_byte(dev, PCI_INTERRUPT_LINE, irq 15);
dev-irq = acpi_register_gsi(irq, edge_level, active_high_low);
= drivers/pci/quirks.c 1.72 vs edited =
--- 1.72/drivers/pci/quirks.c 2005-03-10 01:38:25 -07:00
+++ edited/drivers/pci/quirks.c 2005-03-21 09:22:23 -07:00
@@ -683,19 +683,40 @@
}
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82454NX,
quirk_disable_pxb );
-/*
- * VIA northbridges care about PCI_INTERRUPT_LINE
- */
-int via_interrupt_line_quirk;
+#ifdef CONFIG_ACPI
+#include linux/acpi.h
+#endif
-static void __devinit quirk_via_bridge(struct pci_dev *pdev)
+static void __devinit quirk_via_irqpic(struct pci_dev *dev)
{
- if(pdev-devfn == 0) {
- printk(KERN_INFO PCI: Via IRQ fixup\n);
- via_interrupt_line_quirk = 1;
+ u8 irq, new_irq;
+
+#ifdef CONFIG_X86_IO_APIC
+ if (!skip_ioapic_setup)
+ return;
+#endif
+#ifdef CONFIG_ACPI
+ if (acpi_irq_model != ACPI_IRQ_MODEL_PIC)
+ return;
+#endif
+ /*
+* Some Via devices make an internal connection to the PIC when the
+* PCI_INTERRUPT_LINE register is written. If we've changed the
+* device's IRQ, we need to update this routing.
+*
+* I suspect this only happens for devices on the same chip as the
+* PIC, but I don't know how to identify those without listing them
+* all individually, which is a maintenance problem.
+*/
+ new_irq = dev-irq 0xf;
+ pci_read_config_byte(dev, PCI_INTERRUPT_LINE, irq);
+ if (new_irq != irq) {
+ printk(KERN_INFO PCI: Via PIC IRQ fixup for %s, from %d to
%d\n,
+ pci_name(dev), irq, new_irq);
+ pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
}
}
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA,PCI_ANY_ID,
quirk_via_bridge );
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irqpic);
/*
* Serverworks CSB5 IDE does not fully support native mode
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
On Mon, 21 Mar 2005, Bjorn Helgaas wrote: On Fri, 2005-03-18 at 11:07 -0700, Bjorn Helgaas wrote: OK. Try this one for size. It differs from what's currently in the tree in these ways: - It's a quirk, so we don't have to clutter acpi_pci_irq_enable() and pirq_enable_irq() with Via-specific code. - It doesn't do anything unless we're in PIC mode. The comment suggests this issue only affects PIC routing. - We do this for ALL Via devices. The current code in the tree does it for all devices in the system IF there is a Via device with devfn==0, which misses Grzegorz's case. Does anybody have a pointer to a spec that talks about this? It'd be awfully nice to have a reference. Grzegorz, can you check to make sure this still works after all the tweaking? Oops, I had the sense of the skip_ioapic_setup test reversed. Corrected patch follows. Hi, Your patch applied with some problems: patching file arch/i386/pci/irq.c Hunk #2 succeeded at 1081 with fuzz 2 (offset 1 line). patching file drivers/acpi/pci_irq.c patching file drivers/pci/quirks.c Hunk #1 succeeded at 678 (offset -5 lines). (I do not know why). Then I tested it and it works (at least my speedtouch still works). Here is the log: Mar 22 01:32:37 kangur Linux version 2.6.11-cko1 ([EMAIL PROTECTED]) (gcc version 3.3.3 20040412 (Gentoo Linux 3.3.3-r6, ssp-3.3.2-2, pie-8.7.6)) #4 Tue Mar 22 01:24:18 CET 2005 Mar 22 01:32:37 kangur BIOS-provided physical RAM map: Mar 22 01:32:37 kangur BIOS-e820: - 0009fc00 (usable) Mar 22 01:32:37 kangur BIOS-e820: 0009fc00 - 000a (reserved) Mar 22 01:32:37 kangur BIOS-e820: 000f - 0010 (reserved) Mar 22 01:32:37 kangur BIOS-e820: 0010 - 1fff (usable) Mar 22 01:32:37 kangur BIOS-e820: 1fff - 1fff3000 (ACPI NVS) Mar 22 01:32:37 kangur BIOS-e820: 1fff3000 - 2000 (ACPI data) Mar 22 01:32:37 kangur BIOS-e820: - 0001 (reserved) Mar 22 01:32:37 kangur 511MB LOWMEM available. Mar 22 01:32:37 kangur On node 0 totalpages: 131056 Mar 22 01:32:37 kangur DMA zone: 4096 pages, LIFO batch:1 Mar 22 01:32:37 kangur Normal zone: 126960 pages, LIFO batch:16 Mar 22 01:32:37 kangur HighMem zone: 0 pages, LIFO batch:1 Mar 22 01:32:37 kangur DMI 2.2 present. Mar 22 01:32:37 kangur ACPI: RSDP (v000 761686 ) @ 0x000f6a70 Mar 22 01:32:37 kangur ACPI: RSDT (v001 761686 AWRDACPI 0x42302e31 AWRD 0x) @ 0x1fff3000 Mar 22 01:32:37 kangur ACPI: FADT (v001 761686 AWRDACPI 0x42302e31 AWRD 0x) @ 0x1fff3040 Mar 22 01:32:37 kangur ACPI: DSDT (v001 761686 AWRDACPI 0x1000 MSFT 0x010c) @ 0x Mar 22 01:32:37 kangur ACPI: PM-Timer IO Port: 0x4008 Mar 22 01:32:37 kangur Allocating PCI resources starting at 2000 (gap: 2000:dfff) Mar 22 01:32:37 kangur Built 1 zonelists Mar 22 01:32:37 kangur Kernel command line: ro root=/dev/hdb4 Mar 22 01:32:37 kangur Local APIC disabled by BIOS -- you can enable it with lapic Mar 22 01:32:37 kangur mapped APIC to d000 (01402000) Mar 22 01:32:37 kangur Initializing CPU#0 Mar 22 01:32:37 kangur CPU 0 irqstacks, hard=b0477000 soft=b0476000 Mar 22 01:32:37 kangur PID hash table entries: 2048 (order: 11, 32768 bytes) Mar 22 01:32:37 kangur Detected 1203.036 MHz processor. Mar 22 01:32:37 kangur Using pmtmr for high-res timesource Mar 22 01:32:37 kangur Console: colour VGA+ 80x25 Mar 22 01:32:37 kangur Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Mar 22 01:32:37 kangur Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Mar 22 01:32:37 kangur Memory: 514940k/524224k available (2543k kernel code, 8732k reserved, 819k data, 156k init, 0k highmem) Mar 22 01:32:37 kangur Checking if this processor honours the WP bit even in supervisor mode... Ok. Mar 22 01:32:37 kangur Calibrating delay loop... 2375.68 BogoMIPS (lpj=1187840) Mar 22 01:32:37 kangur Security Framework v1.0.0 initialized Mar 22 01:32:37 kangur Capability LSM initialized Mar 22 01:32:37 kangur Mount-cache hash table entries: 512 (order: 0, 4096 bytes) Mar 22 01:32:37 kangur CPU: After generic identify, caps: 0383f9ff c1cbf9ff Mar 22 01:32:37 kangur CPU: After vendor identify, caps: 0383f9ff c1cbf9ff Mar 22 01:32:37 kangur CPU: CLK_CTL MSR was 60071263. Reprogramming to 20071263 Mar 22 01:32:37 kangur CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) Mar 22 01:32:37 kangur CPU: L2 Cache: 512K (64 bytes/line) Mar 22 01:32:37 kangur CPU: After all inits, caps: 0383f9ff c1cbf9ff 0020 Mar 22 01:32:37 kangur Intel machine check architecture supported. Mar 22 01:32:37 kangur Intel machine check reporting enabled on CPU#0. Mar 22 01:32:37 kangur CPU: AMD Unknown CPU Type stepping 00 Mar 22 01:32:37 kangur Enabling fast FPU save and restore...
Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
On Fri, 2005-03-18 at 09:09 +0800, Li Shaohua wrote:
> On Fri, 2005-03-18 at 02:08, Bjorn Helgaas wrote:
> > On Thu, 2005-03-17 at 09:33 +0800, Li Shaohua wrote:
> > > The comments in previous quirk said it's required only in PIC mode.
> > ...
> > > I feel we concerned too much. Changing the interrupt line isn't harmful,
> > > right? Linux actually ignored interrupt line. Maybe just a
> > > PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq) is
> > > sufficient.
> >
> > I think it's good to limit the scope of the quirk as much as
> > possible because that makes it easier to do future restructuring,
> > such as device-specific interrupt routers.
> >
> > The comment (before quirk_via_acpi(), nowhere near quirk_via_irqpic())
> > says *on-chip devices* have this unusual behavior when the interrupt
> > line is written. That makes sense to me.
> >
> > Writing the interrupt line on random plug-in Via PCI devices does
> > not make sense to me, because for that to have any effect, an
> > upstream bridge would have to be snooping the traffic going through
> > it. That doesn't sound plausible to me.
> >
> > What about this:
> Hmm, this looks like previous solution. We removed the specific via
> quirk is because we don't know how many devices have such issue. Every
> time we encounter an IRQ issue in a VIA PCI device, we will suspect it
> requires quirk and keep try. This is a big overhead.
OK. Try this one for size. It differs from what's currently in
the tree in these ways:
- It's a quirk, so we don't have to clutter acpi_pci_irq_enable()
and pirq_enable_irq() with Via-specific code.
- It doesn't do anything unless we're in PIC mode. The comment
suggests this issue only affects PIC routing.
- We do this for ALL Via devices. The current code in the tree
does it for all devices in the system IF there is a Via device
with devfn==0, which misses Grzegorz's case.
Does anybody have a pointer to a spec that talks about this? It'd
be awfully nice to have a reference.
Grzegorz, can you check to make sure this still works after all the
tweaking?
= arch/i386/pci/irq.c 1.55 vs edited =
--- 1.55/arch/i386/pci/irq.c2005-02-07 22:39:15 -07:00
+++ edited/arch/i386/pci/irq.c 2005-03-15 10:11:44 -07:00
@@ -1026,7 +1026,6 @@
static int pirq_enable_irq(struct pci_dev *dev)
{
u8 pin;
- extern int via_interrupt_line_quirk;
struct pci_dev *temp_dev;
pci_read_config_byte(dev, PCI_INTERRUPT_PIN, );
@@ -1081,10 +1080,6 @@
printk(KERN_WARNING "PCI: No IRQ known for interrupt pin %c of
device %s.%s\n",
'A' + pin, pci_name(dev), msg);
}
- /* VIA bridges use interrupt line for apic/pci steering across
- the V-Link */
- else if (via_interrupt_line_quirk)
- pci_write_config_byte(dev, PCI_INTERRUPT_LINE, dev->irq & 15);
return 0;
}
= drivers/acpi/pci_irq.c 1.37 vs edited =
--- 1.37/drivers/acpi/pci_irq.c 2005-03-01 09:57:29 -07:00
+++ edited/drivers/acpi/pci_irq.c 2005-03-15 10:10:57 -07:00
@@ -388,7 +388,6 @@
u8 pin = 0;
int edge_level = ACPI_LEVEL_SENSITIVE;
int active_high_low = ACPI_ACTIVE_LOW;
- extern int via_interrupt_line_quirk;
ACPI_FUNCTION_TRACE("acpi_pci_irq_enable");
@@ -437,9 +436,6 @@
return_VALUE(0);
}
}
-
- if (via_interrupt_line_quirk)
- pci_write_config_byte(dev, PCI_INTERRUPT_LINE, irq & 15);
dev->irq = acpi_register_gsi(irq, edge_level, active_high_low);
= drivers/pci/quirks.c 1.72 vs edited =
--- 1.72/drivers/pci/quirks.c 2005-03-10 01:38:25 -07:00
+++ edited/drivers/pci/quirks.c 2005-03-18 10:55:01 -07:00
@@ -683,19 +683,40 @@
}
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82454NX,
quirk_disable_pxb );
-/*
- * VIA northbridges care about PCI_INTERRUPT_LINE
- */
-int via_interrupt_line_quirk;
+#ifdef CONFIG_ACPI
+#include
+#endif
-static void __devinit quirk_via_bridge(struct pci_dev *pdev)
+static void __devinit quirk_via_irqpic(struct pci_dev *dev)
{
- if(pdev->devfn == 0) {
- printk(KERN_INFO "PCI: Via IRQ fixup\n");
- via_interrupt_line_quirk = 1;
+ u8 irq, new_irq;
+
+#ifdef CONFIG_X86_IO_APIC
+ if (skip_ioapic_setup)
+ return;
+#endif
+#ifdef CONFIG_ACPI
+ if (acpi_irq_model != ACPI_IRQ_MODEL_PIC)
+ return;
+#endif
+ /*
+* Some Via devices make an internal connection to the PIC when the
+* PCI_INTERRUPT_LINE register is written. If we've changed the
+* device's IRQ, we need to update this routing.
+*
+* I suspect this only happens for devices on the same chip as the
+* PIC, but I don't know how to identify those without listing
Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
On Fri, 2005-03-18 at 09:09 +0800, Li Shaohua wrote:
On Fri, 2005-03-18 at 02:08, Bjorn Helgaas wrote:
On Thu, 2005-03-17 at 09:33 +0800, Li Shaohua wrote:
The comments in previous quirk said it's required only in PIC mode.
...
I feel we concerned too much. Changing the interrupt line isn't harmful,
right? Linux actually ignored interrupt line. Maybe just a
PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq) is
sufficient.
I think it's good to limit the scope of the quirk as much as
possible because that makes it easier to do future restructuring,
such as device-specific interrupt routers.
The comment (before quirk_via_acpi(), nowhere near quirk_via_irqpic())
says *on-chip devices* have this unusual behavior when the interrupt
line is written. That makes sense to me.
Writing the interrupt line on random plug-in Via PCI devices does
not make sense to me, because for that to have any effect, an
upstream bridge would have to be snooping the traffic going through
it. That doesn't sound plausible to me.
What about this:
Hmm, this looks like previous solution. We removed the specific via
quirk is because we don't know how many devices have such issue. Every
time we encounter an IRQ issue in a VIA PCI device, we will suspect it
requires quirk and keep try. This is a big overhead.
OK. Try this one for size. It differs from what's currently in
the tree in these ways:
- It's a quirk, so we don't have to clutter acpi_pci_irq_enable()
and pirq_enable_irq() with Via-specific code.
- It doesn't do anything unless we're in PIC mode. The comment
suggests this issue only affects PIC routing.
- We do this for ALL Via devices. The current code in the tree
does it for all devices in the system IF there is a Via device
with devfn==0, which misses Grzegorz's case.
Does anybody have a pointer to a spec that talks about this? It'd
be awfully nice to have a reference.
Grzegorz, can you check to make sure this still works after all the
tweaking?
= arch/i386/pci/irq.c 1.55 vs edited =
--- 1.55/arch/i386/pci/irq.c2005-02-07 22:39:15 -07:00
+++ edited/arch/i386/pci/irq.c 2005-03-15 10:11:44 -07:00
@@ -1026,7 +1026,6 @@
static int pirq_enable_irq(struct pci_dev *dev)
{
u8 pin;
- extern int via_interrupt_line_quirk;
struct pci_dev *temp_dev;
pci_read_config_byte(dev, PCI_INTERRUPT_PIN, pin);
@@ -1081,10 +1080,6 @@
printk(KERN_WARNING PCI: No IRQ known for interrupt pin %c of
device %s.%s\n,
'A' + pin, pci_name(dev), msg);
}
- /* VIA bridges use interrupt line for apic/pci steering across
- the V-Link */
- else if (via_interrupt_line_quirk)
- pci_write_config_byte(dev, PCI_INTERRUPT_LINE, dev-irq 15);
return 0;
}
= drivers/acpi/pci_irq.c 1.37 vs edited =
--- 1.37/drivers/acpi/pci_irq.c 2005-03-01 09:57:29 -07:00
+++ edited/drivers/acpi/pci_irq.c 2005-03-15 10:10:57 -07:00
@@ -388,7 +388,6 @@
u8 pin = 0;
int edge_level = ACPI_LEVEL_SENSITIVE;
int active_high_low = ACPI_ACTIVE_LOW;
- extern int via_interrupt_line_quirk;
ACPI_FUNCTION_TRACE(acpi_pci_irq_enable);
@@ -437,9 +436,6 @@
return_VALUE(0);
}
}
-
- if (via_interrupt_line_quirk)
- pci_write_config_byte(dev, PCI_INTERRUPT_LINE, irq 15);
dev-irq = acpi_register_gsi(irq, edge_level, active_high_low);
= drivers/pci/quirks.c 1.72 vs edited =
--- 1.72/drivers/pci/quirks.c 2005-03-10 01:38:25 -07:00
+++ edited/drivers/pci/quirks.c 2005-03-18 10:55:01 -07:00
@@ -683,19 +683,40 @@
}
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82454NX,
quirk_disable_pxb );
-/*
- * VIA northbridges care about PCI_INTERRUPT_LINE
- */
-int via_interrupt_line_quirk;
+#ifdef CONFIG_ACPI
+#include linux/acpi.h
+#endif
-static void __devinit quirk_via_bridge(struct pci_dev *pdev)
+static void __devinit quirk_via_irqpic(struct pci_dev *dev)
{
- if(pdev-devfn == 0) {
- printk(KERN_INFO PCI: Via IRQ fixup\n);
- via_interrupt_line_quirk = 1;
+ u8 irq, new_irq;
+
+#ifdef CONFIG_X86_IO_APIC
+ if (skip_ioapic_setup)
+ return;
+#endif
+#ifdef CONFIG_ACPI
+ if (acpi_irq_model != ACPI_IRQ_MODEL_PIC)
+ return;
+#endif
+ /*
+* Some Via devices make an internal connection to the PIC when the
+* PCI_INTERRUPT_LINE register is written. If we've changed the
+* device's IRQ, we need to update this routing.
+*
+* I suspect this only happens for devices on the same chip as the
+* PIC, but I don't know how to identify those without listing them
+* all individually, which is a
Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
On Fri, 2005-03-18 at 02:08, Bjorn Helgaas wrote: > On Thu, 2005-03-17 at 09:33 +0800, Li Shaohua wrote: > > The comments in previous quirk said it's required only in PIC mode. > ... > > I feel we concerned too much. Changing the interrupt line isn't harmful, > > right? Linux actually ignored interrupt line. Maybe just a > > PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq) is > > sufficient. > > I think it's good to limit the scope of the quirk as much as > possible because that makes it easier to do future restructuring, > such as device-specific interrupt routers. > > The comment (before quirk_via_acpi(), nowhere near quirk_via_irqpic()) > says *on-chip devices* have this unusual behavior when the interrupt > line is written. That makes sense to me. > > Writing the interrupt line on random plug-in Via PCI devices does > not make sense to me, because for that to have any effect, an > upstream bridge would have to be snooping the traffic going through > it. That doesn't sound plausible to me. > > What about this: Hmm, this looks like previous solution. We removed the specific via quirk is because we don't know how many devices have such issue. Every time we encounter an IRQ issue in a VIA PCI device, we will suspect it requires quirk and keep try. This is a big overhead. Thanks, Shaohua - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
On Thu, 2005-03-17 at 09:33 +0800, Li Shaohua wrote:
> The comments in previous quirk said it's required only in PIC mode.
...
> I feel we concerned too much. Changing the interrupt line isn't harmful,
> right? Linux actually ignored interrupt line. Maybe just a
> PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq) is
> sufficient.
I think it's good to limit the scope of the quirk as much as
possible because that makes it easier to do future restructuring,
such as device-specific interrupt routers.
The comment (before quirk_via_acpi(), nowhere near quirk_via_irqpic())
says *on-chip devices* have this unusual behavior when the interrupt
line is written. That makes sense to me.
Writing the interrupt line on random plug-in Via PCI devices does
not make sense to me, because for that to have any effect, an
upstream bridge would have to be snooping the traffic going through
it. That doesn't sound plausible to me.
What about this:
= arch/i386/pci/irq.c 1.55 vs edited =
--- 1.55/arch/i386/pci/irq.c2005-02-07 22:39:15 -07:00
+++ edited/arch/i386/pci/irq.c 2005-03-15 10:11:44 -07:00
@@ -1026,7 +1026,6 @@
static int pirq_enable_irq(struct pci_dev *dev)
{
u8 pin;
- extern int via_interrupt_line_quirk;
struct pci_dev *temp_dev;
pci_read_config_byte(dev, PCI_INTERRUPT_PIN, );
@@ -1081,10 +1080,6 @@
printk(KERN_WARNING "PCI: No IRQ known for interrupt pin %c of
device %s.%s\n",
'A' + pin, pci_name(dev), msg);
}
- /* VIA bridges use interrupt line for apic/pci steering across
- the V-Link */
- else if (via_interrupt_line_quirk)
- pci_write_config_byte(dev, PCI_INTERRUPT_LINE, dev->irq & 15);
return 0;
}
= drivers/acpi/pci_irq.c 1.37 vs edited =
--- 1.37/drivers/acpi/pci_irq.c 2005-03-01 09:57:29 -07:00
+++ edited/drivers/acpi/pci_irq.c 2005-03-15 10:10:57 -07:00
@@ -388,7 +388,6 @@
u8 pin = 0;
int edge_level = ACPI_LEVEL_SENSITIVE;
int active_high_low = ACPI_ACTIVE_LOW;
- extern int via_interrupt_line_quirk;
ACPI_FUNCTION_TRACE("acpi_pci_irq_enable");
@@ -437,9 +436,6 @@
return_VALUE(0);
}
}
-
- if (via_interrupt_line_quirk)
- pci_write_config_byte(dev, PCI_INTERRUPT_LINE, irq & 15);
dev->irq = acpi_register_gsi(irq, edge_level, active_high_low);
= drivers/pci/quirks.c 1.72 vs edited =
--- 1.72/drivers/pci/quirks.c 2005-03-10 01:38:25 -07:00
+++ edited/drivers/pci/quirks.c 2005-03-17 10:48:04 -07:00
@@ -683,19 +683,33 @@
}
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82454NX,
quirk_disable_pxb );
-/*
- * VIA northbridges care about PCI_INTERRUPT_LINE
- */
-int via_interrupt_line_quirk;
+#ifdef CONFIG_ACPI
+#include
+#endif
-static void __devinit quirk_via_bridge(struct pci_dev *pdev)
+static void __devinit quirk_via_irqpic(struct pci_dev *dev)
{
- if(pdev->devfn == 0) {
- printk(KERN_INFO "PCI: Via IRQ fixup\n");
- via_interrupt_line_quirk = 1;
+ u8 irq, new_irq;
+
+#ifdef CONFIG_ACPI
+ if (acpi_irq_model != ACPI_IRQ_MODEL_PIC)
+ return;
+#endif
+
+ new_irq = dev->irq & 0xf;
+ pci_read_config_byte(dev, PCI_INTERRUPT_LINE, );
+ if (new_irq != irq) {
+ printk(KERN_INFO "PCI: Via PIC IRQ fixup for %s, from %d to
%d\n",
+ pci_name(dev), irq, new_irq);
+ udelay(15);
+ pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
}
}
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA,PCI_ANY_ID,
quirk_via_bridge );
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_2,
quirk_via_irqpic);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_5,
quirk_via_irqpic);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_6,
quirk_via_irqpic);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8233_5,
quirk_via_irqpic);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8233_7,
quirk_via_irqpic);
/*
* Serverworks CSB5 IDE does not fully support native mode
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
On Thu, 2005-03-17 at 09:33 +0800, Li Shaohua wrote:
The comments in previous quirk said it's required only in PIC mode.
...
I feel we concerned too much. Changing the interrupt line isn't harmful,
right? Linux actually ignored interrupt line. Maybe just a
PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq) is
sufficient.
I think it's good to limit the scope of the quirk as much as
possible because that makes it easier to do future restructuring,
such as device-specific interrupt routers.
The comment (before quirk_via_acpi(), nowhere near quirk_via_irqpic())
says *on-chip devices* have this unusual behavior when the interrupt
line is written. That makes sense to me.
Writing the interrupt line on random plug-in Via PCI devices does
not make sense to me, because for that to have any effect, an
upstream bridge would have to be snooping the traffic going through
it. That doesn't sound plausible to me.
What about this:
= arch/i386/pci/irq.c 1.55 vs edited =
--- 1.55/arch/i386/pci/irq.c2005-02-07 22:39:15 -07:00
+++ edited/arch/i386/pci/irq.c 2005-03-15 10:11:44 -07:00
@@ -1026,7 +1026,6 @@
static int pirq_enable_irq(struct pci_dev *dev)
{
u8 pin;
- extern int via_interrupt_line_quirk;
struct pci_dev *temp_dev;
pci_read_config_byte(dev, PCI_INTERRUPT_PIN, pin);
@@ -1081,10 +1080,6 @@
printk(KERN_WARNING PCI: No IRQ known for interrupt pin %c of
device %s.%s\n,
'A' + pin, pci_name(dev), msg);
}
- /* VIA bridges use interrupt line for apic/pci steering across
- the V-Link */
- else if (via_interrupt_line_quirk)
- pci_write_config_byte(dev, PCI_INTERRUPT_LINE, dev-irq 15);
return 0;
}
= drivers/acpi/pci_irq.c 1.37 vs edited =
--- 1.37/drivers/acpi/pci_irq.c 2005-03-01 09:57:29 -07:00
+++ edited/drivers/acpi/pci_irq.c 2005-03-15 10:10:57 -07:00
@@ -388,7 +388,6 @@
u8 pin = 0;
int edge_level = ACPI_LEVEL_SENSITIVE;
int active_high_low = ACPI_ACTIVE_LOW;
- extern int via_interrupt_line_quirk;
ACPI_FUNCTION_TRACE(acpi_pci_irq_enable);
@@ -437,9 +436,6 @@
return_VALUE(0);
}
}
-
- if (via_interrupt_line_quirk)
- pci_write_config_byte(dev, PCI_INTERRUPT_LINE, irq 15);
dev-irq = acpi_register_gsi(irq, edge_level, active_high_low);
= drivers/pci/quirks.c 1.72 vs edited =
--- 1.72/drivers/pci/quirks.c 2005-03-10 01:38:25 -07:00
+++ edited/drivers/pci/quirks.c 2005-03-17 10:48:04 -07:00
@@ -683,19 +683,33 @@
}
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82454NX,
quirk_disable_pxb );
-/*
- * VIA northbridges care about PCI_INTERRUPT_LINE
- */
-int via_interrupt_line_quirk;
+#ifdef CONFIG_ACPI
+#include linux/acpi.h
+#endif
-static void __devinit quirk_via_bridge(struct pci_dev *pdev)
+static void __devinit quirk_via_irqpic(struct pci_dev *dev)
{
- if(pdev-devfn == 0) {
- printk(KERN_INFO PCI: Via IRQ fixup\n);
- via_interrupt_line_quirk = 1;
+ u8 irq, new_irq;
+
+#ifdef CONFIG_ACPI
+ if (acpi_irq_model != ACPI_IRQ_MODEL_PIC)
+ return;
+#endif
+
+ new_irq = dev-irq 0xf;
+ pci_read_config_byte(dev, PCI_INTERRUPT_LINE, irq);
+ if (new_irq != irq) {
+ printk(KERN_INFO PCI: Via PIC IRQ fixup for %s, from %d to
%d\n,
+ pci_name(dev), irq, new_irq);
+ udelay(15);
+ pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
}
}
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA,PCI_ANY_ID,
quirk_via_bridge );
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_2,
quirk_via_irqpic);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_5,
quirk_via_irqpic);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_6,
quirk_via_irqpic);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8233_5,
quirk_via_irqpic);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8233_7,
quirk_via_irqpic);
/*
* Serverworks CSB5 IDE does not fully support native mode
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
On Fri, 2005-03-18 at 02:08, Bjorn Helgaas wrote: On Thu, 2005-03-17 at 09:33 +0800, Li Shaohua wrote: The comments in previous quirk said it's required only in PIC mode. ... I feel we concerned too much. Changing the interrupt line isn't harmful, right? Linux actually ignored interrupt line. Maybe just a PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq) is sufficient. I think it's good to limit the scope of the quirk as much as possible because that makes it easier to do future restructuring, such as device-specific interrupt routers. The comment (before quirk_via_acpi(), nowhere near quirk_via_irqpic()) says *on-chip devices* have this unusual behavior when the interrupt line is written. That makes sense to me. Writing the interrupt line on random plug-in Via PCI devices does not make sense to me, because for that to have any effect, an upstream bridge would have to be snooping the traffic going through it. That doesn't sound plausible to me. What about this: Hmm, this looks like previous solution. We removed the specific via quirk is because we don't know how many devices have such issue. Every time we encounter an IRQ issue in a VIA PCI device, we will suspect it requires quirk and keep try. This is a big overhead. Thanks, Shaohua - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
Hi,
On Thu, 2005-03-17 at 00:10, Bjorn Helgaas wrote:
> On Tue, 2005-03-15 at 16:02 -0700, Zwane Mwaikambo wrote:
> > On Tue, 15 Mar 2005, Bjorn Helgaas wrote:
> > > That seems awfully suspicious to me. So the following is
> > > probably safe as far as it goes, but not sufficient for all
> > > cases.
> >
> > VIA bridges allow for IRQ routing updates by programming
> > PCI_INTERRUPT_LINE, so it is supposed to work even if we do it for
> all the
> > devices, so it appears to be a board/bios specific problem.
>
> This just feels like a sledgehammer approach, i.e., we're
> programming PCI_INTERRUPT_LINE in more cases that we actually
> need to. I especially don't like that any Via device with
> devfn==0 triggers the quirk. That doesn't seem like the
> right test if we're really looking for a Via bridge.
>
> > > -static void __devinit quirk_via_bridge(struct pci_dev *pdev)
> > > +static void __devinit quirk_via_irqpic(struct pci_dev *dev)
> > > {
> > > - if(pdev->devfn == 0) {
> > > - printk(KERN_INFO "PCI: Via IRQ fixup\n");
> > > - via_interrupt_line_quirk = 1;
> > > + u8 irq, new_irq = dev->irq & 0xf;
> > > +
> > > + pci_read_config_byte(dev, PCI_INTERRUPT_LINE, );
> > > + if (new_irq != irq) {
> > > + printk(KERN_INFO "PCI: Via IRQ fixup for %s, from %d
> to %d\n",
> > > + pci_name(dev), irq, new_irq);
> > > + udelay(15);
> > > + pci_write_config_byte(dev, PCI_INTERRUPT_LINE,
> new_irq);
> > > }
> > > }
> > > -DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA,
> PCI_ANY_ID, quirk_via_bridge );
> > > +DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA,
> PCI_DEVICE_ID_VIA_82C586_2, quirk_via_irqpic);
> > > +DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA,
> PCI_DEVICE_ID_VIA_82C686_5, quirk_via_irqpic);
> > > +DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA,
> PCI_DEVICE_ID_VIA_82C686_6, quirk_via_irqpic);
> > > +DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA,
> PCI_DEVICE_ID_VIA_8233_5, quirk_via_irqpic);
> > > +DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA,
> PCI_DEVICE_ID_VIA_8233_7, quirk_via_irqpic);
> >
> > This looks like it'll only affect the PCI device associated with the
> > listed south bridges, which might break systems which relied on the
> per
> > device setting. Your 'debug' patch actually made sense to me, that
> is,
> > moving the PCI_INTERRUPT_LINE fixup at gsi register.
>
> Yes, that's what I meant by the above probably not being sufficient.
>
> The main thing the debug patch did was to move the write to after
> the IOAPIC programming. (And I think it added back the mysterious
> udelay().) My point is that the write could just as easily be done
> in a pci_enable fixup, because that also happens after the IOAPIC
> update.
The comments in previous quirk said it's required only in PIC mode.
>
> The quirk would have to be something like this:
>
> static void __devinit quirk_via_irq(struct pci_dev *dev)
> {
> if (!via_interrupt_line_quirk)
> return;
>
> /* update PCI_INTERRUPT_LINE */
> ...
> }
> DECLARE_PCI_FIXUP_ENABLE(PCI_ANY_ID, PCI_ANY_ID,
> quirk_via_irq);
>
> with a PCI_FIXUP_HEADER quirk that sets via_interrupt_line_quirk when
> we find a Via bridge.
>
> But I'm uneasy even about this -- what if there are multiple bridges,
> with only one of them being a Via? Why would we want to apply this
> quirk to the devices under the non-Via bridges? Wouldn't it be better
> to search up the hierarchy of each device, looking for a Via bridge,
> and apply the quirk only if we find one?
I feel we concerned too much. Changing the interrupt line isn't harmful,
right? Linux actually ignored interrupt line. Maybe just a
PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq) is
sufficient.
and
quirk_via_irq(..)
{
update_interrupt_line
}
Thanks,
Shaohua
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
On Tue, 2005-03-15 at 16:02 -0700, Zwane Mwaikambo wrote:
> On Tue, 15 Mar 2005, Bjorn Helgaas wrote:
> > That seems awfully suspicious to me. So the following is
> > probably safe as far as it goes, but not sufficient for all
> > cases.
>
> VIA bridges allow for IRQ routing updates by programming
> PCI_INTERRUPT_LINE, so it is supposed to work even if we do it for all the
> devices, so it appears to be a board/bios specific problem.
This just feels like a sledgehammer approach, i.e., we're
programming PCI_INTERRUPT_LINE in more cases that we actually
need to. I especially don't like that any Via device with
devfn==0 triggers the quirk. That doesn't seem like the
right test if we're really looking for a Via bridge.
> > -static void __devinit quirk_via_bridge(struct pci_dev *pdev)
> > +static void __devinit quirk_via_irqpic(struct pci_dev *dev)
> > {
> > - if(pdev->devfn == 0) {
> > - printk(KERN_INFO "PCI: Via IRQ fixup\n");
> > - via_interrupt_line_quirk = 1;
> > + u8 irq, new_irq = dev->irq & 0xf;
> > +
> > + pci_read_config_byte(dev, PCI_INTERRUPT_LINE, );
> > + if (new_irq != irq) {
> > + printk(KERN_INFO "PCI: Via IRQ fixup for %s, from %d to %d\n",
> > + pci_name(dev), irq, new_irq);
> > + udelay(15);
> > + pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
> > }
> > }
> > -DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA,PCI_ANY_ID,
> > quirk_via_bridge );
> > +DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_2,
> > quirk_via_irqpic);
> > +DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_5,
> > quirk_via_irqpic);
> > +DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_6,
> > quirk_via_irqpic);
> > +DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8233_5,
> > quirk_via_irqpic);
> > +DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8233_7,
> > quirk_via_irqpic);
>
> This looks like it'll only affect the PCI device associated with the
> listed south bridges, which might break systems which relied on the per
> device setting. Your 'debug' patch actually made sense to me, that is,
> moving the PCI_INTERRUPT_LINE fixup at gsi register.
Yes, that's what I meant by the above probably not being sufficient.
The main thing the debug patch did was to move the write to after
the IOAPIC programming. (And I think it added back the mysterious
udelay().) My point is that the write could just as easily be done
in a pci_enable fixup, because that also happens after the IOAPIC
update.
The quirk would have to be something like this:
static void __devinit quirk_via_irq(struct pci_dev *dev)
{
if (!via_interrupt_line_quirk)
return;
/* update PCI_INTERRUPT_LINE */
...
}
DECLARE_PCI_FIXUP_ENABLE(PCI_ANY_ID, PCI_ANY_ID, quirk_via_irq);
with a PCI_FIXUP_HEADER quirk that sets via_interrupt_line_quirk when
we find a Via bridge.
But I'm uneasy even about this -- what if there are multiple bridges,
with only one of them being a Via? Why would we want to apply this
quirk to the devices under the non-Via bridges? Wouldn't it be better
to search up the hierarchy of each device, looking for a Via bridge,
and apply the quirk only if we find one?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
On Tue, 2005-03-15 at 16:02 -0700, Zwane Mwaikambo wrote:
On Tue, 15 Mar 2005, Bjorn Helgaas wrote:
That seems awfully suspicious to me. So the following is
probably safe as far as it goes, but not sufficient for all
cases.
VIA bridges allow for IRQ routing updates by programming
PCI_INTERRUPT_LINE, so it is supposed to work even if we do it for all the
devices, so it appears to be a board/bios specific problem.
This just feels like a sledgehammer approach, i.e., we're
programming PCI_INTERRUPT_LINE in more cases that we actually
need to. I especially don't like that any Via device with
devfn==0 triggers the quirk. That doesn't seem like the
right test if we're really looking for a Via bridge.
-static void __devinit quirk_via_bridge(struct pci_dev *pdev)
+static void __devinit quirk_via_irqpic(struct pci_dev *dev)
{
- if(pdev-devfn == 0) {
- printk(KERN_INFO PCI: Via IRQ fixup\n);
- via_interrupt_line_quirk = 1;
+ u8 irq, new_irq = dev-irq 0xf;
+
+ pci_read_config_byte(dev, PCI_INTERRUPT_LINE, irq);
+ if (new_irq != irq) {
+ printk(KERN_INFO PCI: Via IRQ fixup for %s, from %d to %d\n,
+ pci_name(dev), irq, new_irq);
+ udelay(15);
+ pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
}
}
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA,PCI_ANY_ID,
quirk_via_bridge );
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_2,
quirk_via_irqpic);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_5,
quirk_via_irqpic);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_6,
quirk_via_irqpic);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8233_5,
quirk_via_irqpic);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8233_7,
quirk_via_irqpic);
This looks like it'll only affect the PCI device associated with the
listed south bridges, which might break systems which relied on the per
device setting. Your 'debug' patch actually made sense to me, that is,
moving the PCI_INTERRUPT_LINE fixup at gsi register.
Yes, that's what I meant by the above probably not being sufficient.
The main thing the debug patch did was to move the write to after
the IOAPIC programming. (And I think it added back the mysterious
udelay().) My point is that the write could just as easily be done
in a pci_enable fixup, because that also happens after the IOAPIC
update.
The quirk would have to be something like this:
static void __devinit quirk_via_irq(struct pci_dev *dev)
{
if (!via_interrupt_line_quirk)
return;
/* update PCI_INTERRUPT_LINE */
...
}
DECLARE_PCI_FIXUP_ENABLE(PCI_ANY_ID, PCI_ANY_ID, quirk_via_irq);
with a PCI_FIXUP_HEADER quirk that sets via_interrupt_line_quirk when
we find a Via bridge.
But I'm uneasy even about this -- what if there are multiple bridges,
with only one of them being a Via? Why would we want to apply this
quirk to the devices under the non-Via bridges? Wouldn't it be better
to search up the hierarchy of each device, looking for a Via bridge,
and apply the quirk only if we find one?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
Hi,
On Thu, 2005-03-17 at 00:10, Bjorn Helgaas wrote:
On Tue, 2005-03-15 at 16:02 -0700, Zwane Mwaikambo wrote:
On Tue, 15 Mar 2005, Bjorn Helgaas wrote:
That seems awfully suspicious to me. So the following is
probably safe as far as it goes, but not sufficient for all
cases.
VIA bridges allow for IRQ routing updates by programming
PCI_INTERRUPT_LINE, so it is supposed to work even if we do it for
all the
devices, so it appears to be a board/bios specific problem.
This just feels like a sledgehammer approach, i.e., we're
programming PCI_INTERRUPT_LINE in more cases that we actually
need to. I especially don't like that any Via device with
devfn==0 triggers the quirk. That doesn't seem like the
right test if we're really looking for a Via bridge.
-static void __devinit quirk_via_bridge(struct pci_dev *pdev)
+static void __devinit quirk_via_irqpic(struct pci_dev *dev)
{
- if(pdev-devfn == 0) {
- printk(KERN_INFO PCI: Via IRQ fixup\n);
- via_interrupt_line_quirk = 1;
+ u8 irq, new_irq = dev-irq 0xf;
+
+ pci_read_config_byte(dev, PCI_INTERRUPT_LINE, irq);
+ if (new_irq != irq) {
+ printk(KERN_INFO PCI: Via IRQ fixup for %s, from %d
to %d\n,
+ pci_name(dev), irq, new_irq);
+ udelay(15);
+ pci_write_config_byte(dev, PCI_INTERRUPT_LINE,
new_irq);
}
}
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA,
PCI_ANY_ID, quirk_via_bridge );
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA,
PCI_DEVICE_ID_VIA_82C586_2, quirk_via_irqpic);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA,
PCI_DEVICE_ID_VIA_82C686_5, quirk_via_irqpic);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA,
PCI_DEVICE_ID_VIA_82C686_6, quirk_via_irqpic);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA,
PCI_DEVICE_ID_VIA_8233_5, quirk_via_irqpic);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA,
PCI_DEVICE_ID_VIA_8233_7, quirk_via_irqpic);
This looks like it'll only affect the PCI device associated with the
listed south bridges, which might break systems which relied on the
per
device setting. Your 'debug' patch actually made sense to me, that
is,
moving the PCI_INTERRUPT_LINE fixup at gsi register.
Yes, that's what I meant by the above probably not being sufficient.
The main thing the debug patch did was to move the write to after
the IOAPIC programming. (And I think it added back the mysterious
udelay().) My point is that the write could just as easily be done
in a pci_enable fixup, because that also happens after the IOAPIC
update.
The comments in previous quirk said it's required only in PIC mode.
The quirk would have to be something like this:
static void __devinit quirk_via_irq(struct pci_dev *dev)
{
if (!via_interrupt_line_quirk)
return;
/* update PCI_INTERRUPT_LINE */
...
}
DECLARE_PCI_FIXUP_ENABLE(PCI_ANY_ID, PCI_ANY_ID,
quirk_via_irq);
with a PCI_FIXUP_HEADER quirk that sets via_interrupt_line_quirk when
we find a Via bridge.
But I'm uneasy even about this -- what if there are multiple bridges,
with only one of them being a Via? Why would we want to apply this
quirk to the devices under the non-Via bridges? Wouldn't it be better
to search up the hierarchy of each device, looking for a Via bridge,
and apply the quirk only if we find one?
I feel we concerned too much. Changing the interrupt line isn't harmful,
right? Linux actually ignored interrupt line. Maybe just a
PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq) is
sufficient.
and
quirk_via_irq(..)
{
update_interrupt_line
}
Thanks,
Shaohua
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
Hi Bjorn,
On Tue, 15 Mar 2005, Bjorn Helgaas wrote:
> That seems awfully suspicious to me. So the following is
> probably safe as far as it goes, but not sufficient for all
> cases.
VIA bridges allow for IRQ routing updates by programming
PCI_INTERRUPT_LINE, so it is supposed to work even if we do it for all the
devices, so it appears to be a board/bios specific problem.
> Shaohua, Len, Zwane? This is related to
> http://bugzilla.kernel.org/show_bug.cgi?id=3319
>
> = arch/i386/pci/irq.c 1.55 vs edited =
> --- 1.55/arch/i386/pci/irq.c 2005-02-07 22:39:15 -07:00
> +++ edited/arch/i386/pci/irq.c2005-03-15 10:11:44 -07:00
> @@ -1026,7 +1026,6 @@
> static int pirq_enable_irq(struct pci_dev *dev)
> {
> u8 pin;
> - extern int via_interrupt_line_quirk;
> struct pci_dev *temp_dev;
>
> pci_read_config_byte(dev, PCI_INTERRUPT_PIN, );
> @@ -1081,10 +1080,6 @@
> printk(KERN_WARNING "PCI: No IRQ known for interrupt pin %c of
> device %s.%s\n",
> 'A' + pin, pci_name(dev), msg);
> }
> - /* VIA bridges use interrupt line for apic/pci steering across
> -the V-Link */
> - else if (via_interrupt_line_quirk)
> - pci_write_config_byte(dev, PCI_INTERRUPT_LINE, dev->irq & 15);
> return 0;
> }
>
> = drivers/acpi/pci_irq.c 1.37 vs edited =
> --- 1.37/drivers/acpi/pci_irq.c 2005-03-01 09:57:29 -07:00
> +++ edited/drivers/acpi/pci_irq.c 2005-03-15 10:10:57 -07:00
> @@ -388,7 +388,6 @@
> u8 pin = 0;
> int edge_level = ACPI_LEVEL_SENSITIVE;
> int active_high_low = ACPI_ACTIVE_LOW;
> - extern int via_interrupt_line_quirk;
>
> ACPI_FUNCTION_TRACE("acpi_pci_irq_enable");
>
> @@ -437,9 +436,6 @@
> return_VALUE(0);
> }
> }
> -
> - if (via_interrupt_line_quirk)
> - pci_write_config_byte(dev, PCI_INTERRUPT_LINE, irq & 15);
>
> dev->irq = acpi_register_gsi(irq, edge_level, active_high_low);
>
> = drivers/pci/quirks.c 1.72 vs edited =
> --- 1.72/drivers/pci/quirks.c 2005-03-10 01:38:25 -07:00
> +++ edited/drivers/pci/quirks.c 2005-03-15 12:15:00 -07:00
> @@ -683,19 +683,23 @@
> }
> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82454NX,
> quirk_disable_pxb );
>
> -/*
> - * VIA northbridges care about PCI_INTERRUPT_LINE
> - */
> -int via_interrupt_line_quirk;
> -
> -static void __devinit quirk_via_bridge(struct pci_dev *pdev)
> +static void __devinit quirk_via_irqpic(struct pci_dev *dev)
> {
> - if(pdev->devfn == 0) {
> - printk(KERN_INFO "PCI: Via IRQ fixup\n");
> - via_interrupt_line_quirk = 1;
> + u8 irq, new_irq = dev->irq & 0xf;
> +
> + pci_read_config_byte(dev, PCI_INTERRUPT_LINE, );
> + if (new_irq != irq) {
> + printk(KERN_INFO "PCI: Via IRQ fixup for %s, from %d to %d\n",
> + pci_name(dev), irq, new_irq);
> + udelay(15);
> + pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
> }
> }
> -DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA, PCI_ANY_ID,
> quirk_via_bridge );
> +DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_2,
> quirk_via_irqpic);
> +DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_5,
> quirk_via_irqpic);
> +DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_6,
> quirk_via_irqpic);
> +DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8233_5,
> quirk_via_irqpic);
> +DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8233_7,
> quirk_via_irqpic);
This looks like it'll only affect the PCI device associated with the
listed south bridges, which might break systems which relied on the per
device setting. Your 'debug' patch actually made sense to me, that is,
moving the PCI_INTERRUPT_LINE fixup at gsi register.
Thanks,
Zwane
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
On Sun, 2005-03-13 at 16:14 +0100, Grzegorz Kulewski wrote:
> On Fri, 11 Mar 2005, Bjorn Helgaas wrote:
> > So here's another patch to try (revert the first one, then apply this).
> >
> > = drivers/acpi/pci_irq.c 1.37 vs edited =
> > --- 1.37/drivers/acpi/pci_irq.c 2005-03-01 09:57:29 -07:00
> > +++ edited/drivers/acpi/pci_irq.c 2005-03-11 15:13:49 -07:00
> > @@ -438,10 +439,17 @@
> > }
> > }
> >
> > - if (via_interrupt_line_quirk)
> > - pci_write_config_byte(dev, PCI_INTERRUPT_LINE, irq & 15);
> > -
> > dev->irq = acpi_register_gsi(irq, edge_level, active_high_low);
> > +
> > + if (dev->vendor == PCI_VENDOR_ID_VIA) {
> > + u8 old_irq, new_irq = dev->irq & 0xf;
> > +
> > + pci_read_config_byte(dev, PCI_INTERRUPT_LINE, _irq);
> > + printk(KERN_INFO PREFIX "Via IRQ fixup for %s, from %d "
> > + "to %d\n", pci_name(dev), old_irq, new_irq);
> > + udelay(15);
> > + pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
> > + }
> >
> > printk(KERN_INFO PREFIX "PCI interrupt %s[%c] -> GSI %u "
> > "(%s, %s) -> IRQ %d\n",
> >
> Ok, this patch works. Here is the log:
> Mar 13 17:16:17 kangur USB Universal Host Controller Interface driver v2.2
> Mar 13 17:16:17 kangur ACPI: Via IRQ fixup for :00:07.2, from 9 to 10
> Mar 13 17:16:17 kangur ACPI: PCI interrupt :00:07.2[D] -> GSI 10
> (level, low) -> IRQ 10
> Mar 13 17:16:17 kangur uhci_hcd :00:07.2: UHCI Host Controller
> Mar 13 17:16:17 kangur uhci_hcd :00:07.2: irq 10, io base 0xc800
> Mar 13 17:16:17 kangur uhci_hcd :00:07.2: new USB bus registered,
> assigned bus number 1
> Mar 13 17:16:17 kangur hub 1-0:1.0: USB hub found
> Mar 13 17:16:17 kangur hub 1-0:1.0: 2 ports detected
> Mar 13 17:16:17 kangur ACPI: Via IRQ fixup for :00:07.3, from 9 to 10
> Mar 13 17:16:17 kangur ACPI: PCI interrupt :00:07.3[D] -> GSI 10
> (level, low) -> IRQ 10
> To me everything works (at least now). Can this patch be pushed into
> 2.6.12 and/or 2.6.11.4 fast?
The patch I sent you was just for debugging -- I think we can come
up with a cleaner fix.
I think the INTERRUPT_LINE write should actually happen in a
pci_enable_device() fixup. Then we could get rid of all gunk
in pirq_enable_irq() and acpi_pci_irq_enable().
Something like the following will probably work for you, Grzegorz,
but I expect that it won't be enough for somebody with a Via
northbridge.
The previous quirk_via_bridge() says "if the system contains any
Via device with devfn==0, then do the INTERRUPT_LINE fixup for
every PCI device in the system, regardless of what the Via
device is or where it is relative to the current device."
That seems awfully suspicious to me. So the following is
probably safe as far as it goes, but not sufficient for all
cases.
Shaohua, Len, Zwane? This is related to
http://bugzilla.kernel.org/show_bug.cgi?id=3319
= arch/i386/pci/irq.c 1.55 vs edited =
--- 1.55/arch/i386/pci/irq.c2005-02-07 22:39:15 -07:00
+++ edited/arch/i386/pci/irq.c 2005-03-15 10:11:44 -07:00
@@ -1026,7 +1026,6 @@
static int pirq_enable_irq(struct pci_dev *dev)
{
u8 pin;
- extern int via_interrupt_line_quirk;
struct pci_dev *temp_dev;
pci_read_config_byte(dev, PCI_INTERRUPT_PIN, );
@@ -1081,10 +1080,6 @@
printk(KERN_WARNING "PCI: No IRQ known for interrupt pin %c of
device %s.%s\n",
'A' + pin, pci_name(dev), msg);
}
- /* VIA bridges use interrupt line for apic/pci steering across
- the V-Link */
- else if (via_interrupt_line_quirk)
- pci_write_config_byte(dev, PCI_INTERRUPT_LINE, dev->irq & 15);
return 0;
}
= drivers/acpi/pci_irq.c 1.37 vs edited =
--- 1.37/drivers/acpi/pci_irq.c 2005-03-01 09:57:29 -07:00
+++ edited/drivers/acpi/pci_irq.c 2005-03-15 10:10:57 -07:00
@@ -388,7 +388,6 @@
u8 pin = 0;
int edge_level = ACPI_LEVEL_SENSITIVE;
int active_high_low = ACPI_ACTIVE_LOW;
- extern int via_interrupt_line_quirk;
ACPI_FUNCTION_TRACE("acpi_pci_irq_enable");
@@ -437,9 +436,6 @@
return_VALUE(0);
}
}
-
- if (via_interrupt_line_quirk)
- pci_write_config_byte(dev, PCI_INTERRUPT_LINE, irq & 15);
dev->irq = acpi_register_gsi(irq, edge_level, active_high_low);
= drivers/pci/quirks.c 1.72 vs edited =
--- 1.72/drivers/pci/quirks.c 2005-03-10 01:38:25 -07:00
+++ edited/drivers/pci/quirks.c 2005-03-15 12:15:00 -07:00
@@ -683,19 +683,23 @@
}
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82454NX,
quirk_disable_pxb );
-/*
- * VIA northbridges care about PCI_INTERRUPT_LINE
- */
-int via_interrupt_line_quirk;
-
-static void __devinit quirk_via_bridge(struct pci_dev *pdev)
Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
On Sun, 2005-03-13 at 16:14 +0100, Grzegorz Kulewski wrote:
On Fri, 11 Mar 2005, Bjorn Helgaas wrote:
So here's another patch to try (revert the first one, then apply this).
= drivers/acpi/pci_irq.c 1.37 vs edited =
--- 1.37/drivers/acpi/pci_irq.c 2005-03-01 09:57:29 -07:00
+++ edited/drivers/acpi/pci_irq.c 2005-03-11 15:13:49 -07:00
@@ -438,10 +439,17 @@
}
}
- if (via_interrupt_line_quirk)
- pci_write_config_byte(dev, PCI_INTERRUPT_LINE, irq 15);
-
dev-irq = acpi_register_gsi(irq, edge_level, active_high_low);
+
+ if (dev-vendor == PCI_VENDOR_ID_VIA) {
+ u8 old_irq, new_irq = dev-irq 0xf;
+
+ pci_read_config_byte(dev, PCI_INTERRUPT_LINE, old_irq);
+ printk(KERN_INFO PREFIX Via IRQ fixup for %s, from %d
+ to %d\n, pci_name(dev), old_irq, new_irq);
+ udelay(15);
+ pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
+ }
printk(KERN_INFO PREFIX PCI interrupt %s[%c] - GSI %u
(%s, %s) - IRQ %d\n,
Ok, this patch works. Here is the log:
Mar 13 17:16:17 kangur USB Universal Host Controller Interface driver v2.2
Mar 13 17:16:17 kangur ACPI: Via IRQ fixup for :00:07.2, from 9 to 10
Mar 13 17:16:17 kangur ACPI: PCI interrupt :00:07.2[D] - GSI 10
(level, low) - IRQ 10
Mar 13 17:16:17 kangur uhci_hcd :00:07.2: UHCI Host Controller
Mar 13 17:16:17 kangur uhci_hcd :00:07.2: irq 10, io base 0xc800
Mar 13 17:16:17 kangur uhci_hcd :00:07.2: new USB bus registered,
assigned bus number 1
Mar 13 17:16:17 kangur hub 1-0:1.0: USB hub found
Mar 13 17:16:17 kangur hub 1-0:1.0: 2 ports detected
Mar 13 17:16:17 kangur ACPI: Via IRQ fixup for :00:07.3, from 9 to 10
Mar 13 17:16:17 kangur ACPI: PCI interrupt :00:07.3[D] - GSI 10
(level, low) - IRQ 10
To me everything works (at least now). Can this patch be pushed into
2.6.12 and/or 2.6.11.4 fast?
The patch I sent you was just for debugging -- I think we can come
up with a cleaner fix.
I think the INTERRUPT_LINE write should actually happen in a
pci_enable_device() fixup. Then we could get rid of all gunk
in pirq_enable_irq() and acpi_pci_irq_enable().
Something like the following will probably work for you, Grzegorz,
but I expect that it won't be enough for somebody with a Via
northbridge.
The previous quirk_via_bridge() says if the system contains any
Via device with devfn==0, then do the INTERRUPT_LINE fixup for
every PCI device in the system, regardless of what the Via
device is or where it is relative to the current device.
That seems awfully suspicious to me. So the following is
probably safe as far as it goes, but not sufficient for all
cases.
Shaohua, Len, Zwane? This is related to
http://bugzilla.kernel.org/show_bug.cgi?id=3319
= arch/i386/pci/irq.c 1.55 vs edited =
--- 1.55/arch/i386/pci/irq.c2005-02-07 22:39:15 -07:00
+++ edited/arch/i386/pci/irq.c 2005-03-15 10:11:44 -07:00
@@ -1026,7 +1026,6 @@
static int pirq_enable_irq(struct pci_dev *dev)
{
u8 pin;
- extern int via_interrupt_line_quirk;
struct pci_dev *temp_dev;
pci_read_config_byte(dev, PCI_INTERRUPT_PIN, pin);
@@ -1081,10 +1080,6 @@
printk(KERN_WARNING PCI: No IRQ known for interrupt pin %c of
device %s.%s\n,
'A' + pin, pci_name(dev), msg);
}
- /* VIA bridges use interrupt line for apic/pci steering across
- the V-Link */
- else if (via_interrupt_line_quirk)
- pci_write_config_byte(dev, PCI_INTERRUPT_LINE, dev-irq 15);
return 0;
}
= drivers/acpi/pci_irq.c 1.37 vs edited =
--- 1.37/drivers/acpi/pci_irq.c 2005-03-01 09:57:29 -07:00
+++ edited/drivers/acpi/pci_irq.c 2005-03-15 10:10:57 -07:00
@@ -388,7 +388,6 @@
u8 pin = 0;
int edge_level = ACPI_LEVEL_SENSITIVE;
int active_high_low = ACPI_ACTIVE_LOW;
- extern int via_interrupt_line_quirk;
ACPI_FUNCTION_TRACE(acpi_pci_irq_enable);
@@ -437,9 +436,6 @@
return_VALUE(0);
}
}
-
- if (via_interrupt_line_quirk)
- pci_write_config_byte(dev, PCI_INTERRUPT_LINE, irq 15);
dev-irq = acpi_register_gsi(irq, edge_level, active_high_low);
= drivers/pci/quirks.c 1.72 vs edited =
--- 1.72/drivers/pci/quirks.c 2005-03-10 01:38:25 -07:00
+++ edited/drivers/pci/quirks.c 2005-03-15 12:15:00 -07:00
@@ -683,19 +683,23 @@
}
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82454NX,
quirk_disable_pxb );
-/*
- * VIA northbridges care about PCI_INTERRUPT_LINE
- */
-int via_interrupt_line_quirk;
-
-static void __devinit quirk_via_bridge(struct pci_dev *pdev)
+static void __devinit quirk_via_irqpic(struct pci_dev *dev)
{
- if(pdev-devfn == 0) {
-
Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
Hi Bjorn,
On Tue, 15 Mar 2005, Bjorn Helgaas wrote:
That seems awfully suspicious to me. So the following is
probably safe as far as it goes, but not sufficient for all
cases.
VIA bridges allow for IRQ routing updates by programming
PCI_INTERRUPT_LINE, so it is supposed to work even if we do it for all the
devices, so it appears to be a board/bios specific problem.
Shaohua, Len, Zwane? This is related to
http://bugzilla.kernel.org/show_bug.cgi?id=3319
= arch/i386/pci/irq.c 1.55 vs edited =
--- 1.55/arch/i386/pci/irq.c 2005-02-07 22:39:15 -07:00
+++ edited/arch/i386/pci/irq.c2005-03-15 10:11:44 -07:00
@@ -1026,7 +1026,6 @@
static int pirq_enable_irq(struct pci_dev *dev)
{
u8 pin;
- extern int via_interrupt_line_quirk;
struct pci_dev *temp_dev;
pci_read_config_byte(dev, PCI_INTERRUPT_PIN, pin);
@@ -1081,10 +1080,6 @@
printk(KERN_WARNING PCI: No IRQ known for interrupt pin %c of
device %s.%s\n,
'A' + pin, pci_name(dev), msg);
}
- /* VIA bridges use interrupt line for apic/pci steering across
-the V-Link */
- else if (via_interrupt_line_quirk)
- pci_write_config_byte(dev, PCI_INTERRUPT_LINE, dev-irq 15);
return 0;
}
= drivers/acpi/pci_irq.c 1.37 vs edited =
--- 1.37/drivers/acpi/pci_irq.c 2005-03-01 09:57:29 -07:00
+++ edited/drivers/acpi/pci_irq.c 2005-03-15 10:10:57 -07:00
@@ -388,7 +388,6 @@
u8 pin = 0;
int edge_level = ACPI_LEVEL_SENSITIVE;
int active_high_low = ACPI_ACTIVE_LOW;
- extern int via_interrupt_line_quirk;
ACPI_FUNCTION_TRACE(acpi_pci_irq_enable);
@@ -437,9 +436,6 @@
return_VALUE(0);
}
}
-
- if (via_interrupt_line_quirk)
- pci_write_config_byte(dev, PCI_INTERRUPT_LINE, irq 15);
dev-irq = acpi_register_gsi(irq, edge_level, active_high_low);
= drivers/pci/quirks.c 1.72 vs edited =
--- 1.72/drivers/pci/quirks.c 2005-03-10 01:38:25 -07:00
+++ edited/drivers/pci/quirks.c 2005-03-15 12:15:00 -07:00
@@ -683,19 +683,23 @@
}
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82454NX,
quirk_disable_pxb );
-/*
- * VIA northbridges care about PCI_INTERRUPT_LINE
- */
-int via_interrupt_line_quirk;
-
-static void __devinit quirk_via_bridge(struct pci_dev *pdev)
+static void __devinit quirk_via_irqpic(struct pci_dev *dev)
{
- if(pdev-devfn == 0) {
- printk(KERN_INFO PCI: Via IRQ fixup\n);
- via_interrupt_line_quirk = 1;
+ u8 irq, new_irq = dev-irq 0xf;
+
+ pci_read_config_byte(dev, PCI_INTERRUPT_LINE, irq);
+ if (new_irq != irq) {
+ printk(KERN_INFO PCI: Via IRQ fixup for %s, from %d to %d\n,
+ pci_name(dev), irq, new_irq);
+ udelay(15);
+ pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
}
}
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA, PCI_ANY_ID,
quirk_via_bridge );
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_2,
quirk_via_irqpic);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_5,
quirk_via_irqpic);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_6,
quirk_via_irqpic);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8233_5,
quirk_via_irqpic);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8233_7,
quirk_via_irqpic);
This looks like it'll only affect the PCI device associated with the
listed south bridges, which might break systems which relied on the per
device setting. Your 'debug' patch actually made sense to me, that is,
moving the PCI_INTERRUPT_LINE fixup at gsi register.
Thanks,
Zwane
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
Hi,
This issue is quite interesting. We removed all specific VIA quirk
recently and apply a generic VIA quirk. But in this case, the MCH 00:0.0
is from AMD, and the ISA bridge and built-in devices are from VIA, this
means VIA quirk is useless, since it takes action only when the MCH is
from VIA. We possibly should enable VIA quirk if a VIA ISA bridge is
found instead of a VIA MCH found, but Bjorn's method seems ok.
If you want to put the patch into kernel, please also change the '
pirq_enable_irq' case.
Thanks,
Shaohua
>-Original Message-
>From: [EMAIL PROTECTED] [mailto:acpi-devel-
>[EMAIL PROTECTED] On Behalf Of Grzegorz Kulewski
>Sent: Sunday, March 13, 2005 11:15 PM
>To: Bjorn Helgaas
>Cc: Andrew Morton; ACPI List; lkml
>Subject: Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI
breaks
>USB
>
>On Fri, 11 Mar 2005, Bjorn Helgaas wrote:
>
>> Can you do an "lspci -vvn"? I'm looking at quirk_via_irqpic() in
>> 2.6.9, which is what printed this:
>>
>>>>PCI: Via IRQ fixup for :00:07.2, from 9 to 10
>>>>PCI: Via IRQ fixup for :00:07.3, from 9 to 10
>>
>> but it looks like it should only run for PCI_DEVICE_ID_VIA_82C586_2,
>> PCI_DEVICE_ID_VIA_82C686_5, and PCI_DEVICE_ID_VIA_82C686_6.
>>
>> You have:
>>
>> :00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo
Super
>South] (rev 40)
>> :00:07.1 IDE interface: VIA Technologies, Inc.
>VT82C586A/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master IDE (rev 06)
>> :00:07.2 USB Controller: VIA Technologies, Inc. USB (rev 1a)
(prog-if
>00 [UHCI])
>> :00:07.3 USB Controller: VIA Technologies, Inc. USB (rev 1a)
(prog-if
>00 [UHCI])
>>
>> and we apparently ran the quirk for 07.2 and 07.3. I wouldn't
>> have thought those would have one of the above device IDs. The
>> "lspci -vvn" should tell us for sure.
>>
>> 2.6.11 removed that quirk and runs quirk_via_bridge() for
>> all VIA devices, but only sets via_interrupt_line_quirk if
>> (pdev->devfn == 0), which you don't have. So that's why
>> my patch didn't do anything.
>>
>>> Also two more questions:
>>>
>>> 1. What is VIA fixup? Is it some hardware bug? Or BIOS problem? Why
is
>it
>>> needed? On what hardware / software it is needed?
>>
>> I really don't know much about the VIA fixup. I just noticed
>> that we seem to be doing it slightly differently in 2.6.11 than
>> we did in 2.6.9, and thought maybe it was related to your problem.
>> Here's a changeset that has a couple pointers:
>>
>>http://linux.bkbits.net:8080/linux-
>2.5/cset%4041cb9d48DRV4TYe77gvstTawuZFYyQ
>>
>>> 2. Why this patch shrinked bzImage that much:
>>>
>>> -rw-r--r-- 1 root root 1828186 mar 11 23:33 vmlinuz-2.6.11-cko1
>>> -rw-r--r-- 1 root root 1828355 mar 2 20:48 vmlinuz-2.6.11-cko1.old
>>
>> I have no idea about this. But it's only a couple hundred bytes.
>>
>> So here's another patch to try (revert the first one, then apply
this).
>>
>> = drivers/acpi/pci_irq.c 1.37 vs edited =
>> --- 1.37/drivers/acpi/pci_irq.c 2005-03-01 09:57:29 -07:00
>> +++ edited/drivers/acpi/pci_irq.c2005-03-11 15:13:49 -07:00
>> @@ -30,6 +30,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -438,10 +439,17 @@
>> }
>> }
>>
>> -if (via_interrupt_line_quirk)
>> -pci_write_config_byte(dev, PCI_INTERRUPT_LINE, irq &
15);
>> -
>> dev->irq = acpi_register_gsi(irq, edge_level, active_high_low);
>> +
>> +if (dev->vendor == PCI_VENDOR_ID_VIA) {
>> +u8 old_irq, new_irq = dev->irq & 0xf;
>> +
>> +pci_read_config_byte(dev, PCI_INTERRUPT_LINE, _irq);
>> +printk(KERN_INFO PREFIX "Via IRQ fixup for %s, from %d "
>> +"to %d\n", pci_name(dev), old_irq, new_irq);
>> +udelay(15);
>> +pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
>> +}
>>
>> printk(KERN_INFO PREFIX "PCI interrupt %s[%c] -> GSI %u "
>> "(%s, %s) -> IRQ %d\n",
>>
>
>Ok, this patch works. Here is the log:
>
>Mar 13 17:16:17 kangur Linux version 2.6.11-cko1 ([EMAIL PROTECTED]) (gcc
>version 3.3.3 20040412 (Gentoo Linux 3.3.3-r6, ssp-3.3.2-2, pie-8.7.6))
#3
>Sun Mar 13 17:10:10 CET 2005
>Mar 13 17:16:17 kangur BIOS-provided physical RAM map:
>Mar 13 17:16:17 kangur BIOS-e820: 000
RE: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
Hi,
This issue is quite interesting. We removed all specific VIA quirk
recently and apply a generic VIA quirk. But in this case, the MCH 00:0.0
is from AMD, and the ISA bridge and built-in devices are from VIA, this
means VIA quirk is useless, since it takes action only when the MCH is
from VIA. We possibly should enable VIA quirk if a VIA ISA bridge is
found instead of a VIA MCH found, but Bjorn's method seems ok.
If you want to put the patch into kernel, please also change the '
pirq_enable_irq' case.
Thanks,
Shaohua
-Original Message-
From: [EMAIL PROTECTED] [mailto:acpi-devel-
[EMAIL PROTECTED] On Behalf Of Grzegorz Kulewski
Sent: Sunday, March 13, 2005 11:15 PM
To: Bjorn Helgaas
Cc: Andrew Morton; ACPI List; lkml
Subject: Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI
breaks
USB
On Fri, 11 Mar 2005, Bjorn Helgaas wrote:
Can you do an lspci -vvn? I'm looking at quirk_via_irqpic() in
2.6.9, which is what printed this:
PCI: Via IRQ fixup for :00:07.2, from 9 to 10
PCI: Via IRQ fixup for :00:07.3, from 9 to 10
but it looks like it should only run for PCI_DEVICE_ID_VIA_82C586_2,
PCI_DEVICE_ID_VIA_82C686_5, and PCI_DEVICE_ID_VIA_82C686_6.
You have:
:00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo
Super
South] (rev 40)
:00:07.1 IDE interface: VIA Technologies, Inc.
VT82C586A/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master IDE (rev 06)
:00:07.2 USB Controller: VIA Technologies, Inc. USB (rev 1a)
(prog-if
00 [UHCI])
:00:07.3 USB Controller: VIA Technologies, Inc. USB (rev 1a)
(prog-if
00 [UHCI])
and we apparently ran the quirk for 07.2 and 07.3. I wouldn't
have thought those would have one of the above device IDs. The
lspci -vvn should tell us for sure.
2.6.11 removed that quirk and runs quirk_via_bridge() for
all VIA devices, but only sets via_interrupt_line_quirk if
(pdev-devfn == 0), which you don't have. So that's why
my patch didn't do anything.
Also two more questions:
1. What is VIA fixup? Is it some hardware bug? Or BIOS problem? Why
is
it
needed? On what hardware / software it is needed?
I really don't know much about the VIA fixup. I just noticed
that we seem to be doing it slightly differently in 2.6.11 than
we did in 2.6.9, and thought maybe it was related to your problem.
Here's a changeset that has a couple pointers:
http://linux.bkbits.net:8080/linux-
2.5/cset%4041cb9d48DRV4TYe77gvstTawuZFYyQ
2. Why this patch shrinked bzImage that much:
-rw-r--r-- 1 root root 1828186 mar 11 23:33 vmlinuz-2.6.11-cko1
-rw-r--r-- 1 root root 1828355 mar 2 20:48 vmlinuz-2.6.11-cko1.old
I have no idea about this. But it's only a couple hundred bytes.
So here's another patch to try (revert the first one, then apply
this).
= drivers/acpi/pci_irq.c 1.37 vs edited =
--- 1.37/drivers/acpi/pci_irq.c 2005-03-01 09:57:29 -07:00
+++ edited/drivers/acpi/pci_irq.c2005-03-11 15:13:49 -07:00
@@ -30,6 +30,7 @@
#include linux/module.h
#include linux/init.h
#include linux/types.h
+#include linux/delay.h
#include linux/proc_fs.h
#include linux/spinlock.h
#include linux/pm.h
@@ -438,10 +439,17 @@
}
}
-if (via_interrupt_line_quirk)
-pci_write_config_byte(dev, PCI_INTERRUPT_LINE, irq
15);
-
dev-irq = acpi_register_gsi(irq, edge_level, active_high_low);
+
+if (dev-vendor == PCI_VENDOR_ID_VIA) {
+u8 old_irq, new_irq = dev-irq 0xf;
+
+pci_read_config_byte(dev, PCI_INTERRUPT_LINE, old_irq);
+printk(KERN_INFO PREFIX Via IRQ fixup for %s, from %d
+to %d\n, pci_name(dev), old_irq, new_irq);
+udelay(15);
+pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
+}
printk(KERN_INFO PREFIX PCI interrupt %s[%c] - GSI %u
(%s, %s) - IRQ %d\n,
Ok, this patch works. Here is the log:
Mar 13 17:16:17 kangur Linux version 2.6.11-cko1 ([EMAIL PROTECTED]) (gcc
version 3.3.3 20040412 (Gentoo Linux 3.3.3-r6, ssp-3.3.2-2, pie-8.7.6))
#3
Sun Mar 13 17:10:10 CET 2005
Mar 13 17:16:17 kangur BIOS-provided physical RAM map:
Mar 13 17:16:17 kangur BIOS-e820: - 0009fc00
(usable)
Mar 13 17:16:17 kangur BIOS-e820: 0009fc00 - 000a
(reserved)
Mar 13 17:16:17 kangur BIOS-e820: 000f - 0010
(reserved)
Mar 13 17:16:17 kangur BIOS-e820: 0010 - 1fff
(usable)
Mar 13 17:16:17 kangur BIOS-e820: 1fff - 1fff3000
(ACPI NVS)
Mar 13 17:16:17 kangur BIOS-e820: 1fff3000 - 2000
(ACPI data)
Mar 13 17:16:17 kangur BIOS-e820: - 0001
(reserved)
Mar 13 17:16:17 kangur 511MB LOWMEM available.
Mar 13 17:16:17 kangur On node 0 totalpages: 131056
Mar 13 17:16:17 kangur DMA zone: 4096 pages, LIFO batch:1
Mar 13 17:16:17 kangur Normal zone: 126960 pages, LIFO batch:16
Mar 13 17:16:17 kangur HighMem zone: 0 pages, LIFO
Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
On Fri, 11 Mar 2005, Bjorn Helgaas wrote:
Can you do an "lspci -vvn"? I'm looking at quirk_via_irqpic() in
2.6.9, which is what printed this:
PCI: Via IRQ fixup for :00:07.2, from 9 to 10
PCI: Via IRQ fixup for :00:07.3, from 9 to 10
but it looks like it should only run for PCI_DEVICE_ID_VIA_82C586_2,
PCI_DEVICE_ID_VIA_82C686_5, and PCI_DEVICE_ID_VIA_82C686_6.
You have:
:00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South]
(rev 40)
:00:07.1 IDE interface: VIA Technologies, Inc.
VT82C586A/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master IDE (rev 06)
:00:07.2 USB Controller: VIA Technologies, Inc. USB (rev 1a) (prog-if 00
[UHCI])
:00:07.3 USB Controller: VIA Technologies, Inc. USB (rev 1a) (prog-if 00
[UHCI])
and we apparently ran the quirk for 07.2 and 07.3. I wouldn't
have thought those would have one of the above device IDs. The
"lspci -vvn" should tell us for sure.
2.6.11 removed that quirk and runs quirk_via_bridge() for
all VIA devices, but only sets via_interrupt_line_quirk if
(pdev->devfn == 0), which you don't have. So that's why
my patch didn't do anything.
Also two more questions:
1. What is VIA fixup? Is it some hardware bug? Or BIOS problem? Why is it
needed? On what hardware / software it is needed?
I really don't know much about the VIA fixup. I just noticed
that we seem to be doing it slightly differently in 2.6.11 than
we did in 2.6.9, and thought maybe it was related to your problem.
Here's a changeset that has a couple pointers:
http://linux.bkbits.net:8080/linux-2.5/cset%4041cb9d48DRV4TYe77gvstTawuZFYyQ
2. Why this patch shrinked bzImage that much:
-rw-r--r-- 1 root root 1828186 mar 11 23:33 vmlinuz-2.6.11-cko1
-rw-r--r-- 1 root root 1828355 mar 2 20:48 vmlinuz-2.6.11-cko1.old
I have no idea about this. But it's only a couple hundred bytes.
So here's another patch to try (revert the first one, then apply this).
= drivers/acpi/pci_irq.c 1.37 vs edited =
--- 1.37/drivers/acpi/pci_irq.c 2005-03-01 09:57:29 -07:00
+++ edited/drivers/acpi/pci_irq.c 2005-03-11 15:13:49 -07:00
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -438,10 +439,17 @@
}
}
- if (via_interrupt_line_quirk)
- pci_write_config_byte(dev, PCI_INTERRUPT_LINE, irq & 15);
-
dev->irq = acpi_register_gsi(irq, edge_level, active_high_low);
+
+ if (dev->vendor == PCI_VENDOR_ID_VIA) {
+ u8 old_irq, new_irq = dev->irq & 0xf;
+
+ pci_read_config_byte(dev, PCI_INTERRUPT_LINE, _irq);
+ printk(KERN_INFO PREFIX "Via IRQ fixup for %s, from %d "
+ "to %d\n", pci_name(dev), old_irq, new_irq);
+ udelay(15);
+ pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
+ }
printk(KERN_INFO PREFIX "PCI interrupt %s[%c] -> GSI %u "
"(%s, %s) -> IRQ %d\n",
Ok, this patch works. Here is the log:
Mar 13 17:16:17 kangur Linux version 2.6.11-cko1 ([EMAIL PROTECTED]) (gcc
version 3.3.3 20040412 (Gentoo Linux 3.3.3-r6, ssp-3.3.2-2, pie-8.7.6)) #3
Sun Mar 13 17:10:10 CET 2005
Mar 13 17:16:17 kangur BIOS-provided physical RAM map:
Mar 13 17:16:17 kangur BIOS-e820: - 0009fc00
(usable)
Mar 13 17:16:17 kangur BIOS-e820: 0009fc00 - 000a
(reserved)
Mar 13 17:16:17 kangur BIOS-e820: 000f - 0010
(reserved)
Mar 13 17:16:17 kangur BIOS-e820: 0010 - 1fff
(usable)
Mar 13 17:16:17 kangur BIOS-e820: 1fff - 1fff3000
(ACPI NVS)
Mar 13 17:16:17 kangur BIOS-e820: 1fff3000 - 2000
(ACPI data)
Mar 13 17:16:17 kangur BIOS-e820: - 0001
(reserved)
Mar 13 17:16:17 kangur 511MB LOWMEM available.
Mar 13 17:16:17 kangur On node 0 totalpages: 131056
Mar 13 17:16:17 kangur DMA zone: 4096 pages, LIFO batch:1
Mar 13 17:16:17 kangur Normal zone: 126960 pages, LIFO batch:16
Mar 13 17:16:17 kangur HighMem zone: 0 pages, LIFO batch:1
Mar 13 17:16:17 kangur DMI 2.2 present.
Mar 13 17:16:17 kangur ACPI: RSDP (v000 761686
) @ 0x000f6a70
Mar 13 17:16:17 kangur ACPI: RSDT (v001 761686 AWRDACPI 0x42302e31 AWRD
0x) @ 0x1fff3000
Mar 13 17:16:17 kangur ACPI: FADT (v001 761686 AWRDACPI 0x42302e31 AWRD
0x) @ 0x1fff3040
Mar 13 17:16:17 kangur ACPI: DSDT (v001 761686 AWRDACPI 0x1000 MSFT
0x010c) @ 0x
Mar 13 17:16:17 kangur ACPI: PM-Timer IO Port: 0x4008
Mar 13 17:16:17 kangur Allocating PCI resources starting at 2000 (gap:
2000:dfff)
Mar 13 17:16:17 kangur Built 1 zonelists
Mar 13 17:16:17 kangur Kernel command line: ro root=/dev/hdb4
Mar 13 17:16:17 kangur Local APIC disabled by BIOS -- you can enable it
with "lapic"
Mar 13 17:16:17 kangur mapped APIC to d000 (01402000)
Mar 13 17:16:17 kangur Initializing CPU#0
Mar 13 17:16:17 kangur CPU 0 irqstacks, hard=b0477000 soft=b0476000
Mar 13
Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
On Fri, 11 Mar 2005, Bjorn Helgaas wrote:
Can you do an lspci -vvn? I'm looking at quirk_via_irqpic() in
2.6.9, which is what printed this:
PCI: Via IRQ fixup for :00:07.2, from 9 to 10
PCI: Via IRQ fixup for :00:07.3, from 9 to 10
but it looks like it should only run for PCI_DEVICE_ID_VIA_82C586_2,
PCI_DEVICE_ID_VIA_82C686_5, and PCI_DEVICE_ID_VIA_82C686_6.
You have:
:00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South]
(rev 40)
:00:07.1 IDE interface: VIA Technologies, Inc.
VT82C586A/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master IDE (rev 06)
:00:07.2 USB Controller: VIA Technologies, Inc. USB (rev 1a) (prog-if 00
[UHCI])
:00:07.3 USB Controller: VIA Technologies, Inc. USB (rev 1a) (prog-if 00
[UHCI])
and we apparently ran the quirk for 07.2 and 07.3. I wouldn't
have thought those would have one of the above device IDs. The
lspci -vvn should tell us for sure.
2.6.11 removed that quirk and runs quirk_via_bridge() for
all VIA devices, but only sets via_interrupt_line_quirk if
(pdev-devfn == 0), which you don't have. So that's why
my patch didn't do anything.
Also two more questions:
1. What is VIA fixup? Is it some hardware bug? Or BIOS problem? Why is it
needed? On what hardware / software it is needed?
I really don't know much about the VIA fixup. I just noticed
that we seem to be doing it slightly differently in 2.6.11 than
we did in 2.6.9, and thought maybe it was related to your problem.
Here's a changeset that has a couple pointers:
http://linux.bkbits.net:8080/linux-2.5/cset%4041cb9d48DRV4TYe77gvstTawuZFYyQ
2. Why this patch shrinked bzImage that much:
-rw-r--r-- 1 root root 1828186 mar 11 23:33 vmlinuz-2.6.11-cko1
-rw-r--r-- 1 root root 1828355 mar 2 20:48 vmlinuz-2.6.11-cko1.old
I have no idea about this. But it's only a couple hundred bytes.
So here's another patch to try (revert the first one, then apply this).
= drivers/acpi/pci_irq.c 1.37 vs edited =
--- 1.37/drivers/acpi/pci_irq.c 2005-03-01 09:57:29 -07:00
+++ edited/drivers/acpi/pci_irq.c 2005-03-11 15:13:49 -07:00
@@ -30,6 +30,7 @@
#include linux/module.h
#include linux/init.h
#include linux/types.h
+#include linux/delay.h
#include linux/proc_fs.h
#include linux/spinlock.h
#include linux/pm.h
@@ -438,10 +439,17 @@
}
}
- if (via_interrupt_line_quirk)
- pci_write_config_byte(dev, PCI_INTERRUPT_LINE, irq 15);
-
dev-irq = acpi_register_gsi(irq, edge_level, active_high_low);
+
+ if (dev-vendor == PCI_VENDOR_ID_VIA) {
+ u8 old_irq, new_irq = dev-irq 0xf;
+
+ pci_read_config_byte(dev, PCI_INTERRUPT_LINE, old_irq);
+ printk(KERN_INFO PREFIX Via IRQ fixup for %s, from %d
+ to %d\n, pci_name(dev), old_irq, new_irq);
+ udelay(15);
+ pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
+ }
printk(KERN_INFO PREFIX PCI interrupt %s[%c] - GSI %u
(%s, %s) - IRQ %d\n,
Ok, this patch works. Here is the log:
Mar 13 17:16:17 kangur Linux version 2.6.11-cko1 ([EMAIL PROTECTED]) (gcc
version 3.3.3 20040412 (Gentoo Linux 3.3.3-r6, ssp-3.3.2-2, pie-8.7.6)) #3
Sun Mar 13 17:10:10 CET 2005
Mar 13 17:16:17 kangur BIOS-provided physical RAM map:
Mar 13 17:16:17 kangur BIOS-e820: - 0009fc00
(usable)
Mar 13 17:16:17 kangur BIOS-e820: 0009fc00 - 000a
(reserved)
Mar 13 17:16:17 kangur BIOS-e820: 000f - 0010
(reserved)
Mar 13 17:16:17 kangur BIOS-e820: 0010 - 1fff
(usable)
Mar 13 17:16:17 kangur BIOS-e820: 1fff - 1fff3000
(ACPI NVS)
Mar 13 17:16:17 kangur BIOS-e820: 1fff3000 - 2000
(ACPI data)
Mar 13 17:16:17 kangur BIOS-e820: - 0001
(reserved)
Mar 13 17:16:17 kangur 511MB LOWMEM available.
Mar 13 17:16:17 kangur On node 0 totalpages: 131056
Mar 13 17:16:17 kangur DMA zone: 4096 pages, LIFO batch:1
Mar 13 17:16:17 kangur Normal zone: 126960 pages, LIFO batch:16
Mar 13 17:16:17 kangur HighMem zone: 0 pages, LIFO batch:1
Mar 13 17:16:17 kangur DMI 2.2 present.
Mar 13 17:16:17 kangur ACPI: RSDP (v000 761686
) @ 0x000f6a70
Mar 13 17:16:17 kangur ACPI: RSDT (v001 761686 AWRDACPI 0x42302e31 AWRD
0x) @ 0x1fff3000
Mar 13 17:16:17 kangur ACPI: FADT (v001 761686 AWRDACPI 0x42302e31 AWRD
0x) @ 0x1fff3040
Mar 13 17:16:17 kangur ACPI: DSDT (v001 761686 AWRDACPI 0x1000 MSFT
0x010c) @ 0x
Mar 13 17:16:17 kangur ACPI: PM-Timer IO Port: 0x4008
Mar 13 17:16:17 kangur Allocating PCI resources starting at 2000 (gap:
2000:dfff)
Mar 13 17:16:17 kangur Built 1 zonelists
Mar 13 17:16:17 kangur Kernel command line: ro root=/dev/hdb4
Mar 13 17:16:17 kangur Local APIC disabled by BIOS -- you can enable it
with lapic
Mar 13 17:16:17 kangur mapped APIC to d000 (01402000)
Mar 13 17:16:17 kangur Initializing CPU#0
Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
On Fri, 11 Mar 2005, Bjorn Helgaas wrote: Can you do an "lspci -vvn"? # lspci -vvn :00:00.0 Class 0600: 1022:700e (rev 13) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Latency: 32 Region 0: Memory at f000 (32-bit, prefetchable) Region 1: Memory at f7003000 (32-bit, prefetchable) [size=4K] Region 2: I/O ports at c000 [disabled] [size=4] Capabilities: [a0] AGP version 2.0 Status: RQ=16 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4 Command: RQ=1 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW+ Rate=x4 :00:01.0 Class 0604: 1022:700f Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Latency: 32 Bus: primary=00, secondary=01, subordinate=01, sec-latency=32 Memory behind bridge: f400-f5ff Prefetchable memory behind bridge: e800-efff BridgeCtl: Parity- SERR+ NoISA+ VGA+ MAbort- >Reset- FastB2B- :00:07.0 Class 0601: 1106:0686 (rev 40) Subsystem: 147b:a702 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Latency: 0 Capabilities: [c0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- :00:07.1 Class 0101: 1106:0571 (rev 06) (prog-if 8a [Master SecP PriP]) Subsystem: 1106:0571 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Latency: 32 Region 4: I/O ports at c400 [size=16] Capabilities: [c0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- :00:07.2 Class 0c03: 1106:3038 (rev 1a) Subsystem: 0925:1234 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Latency: 32, cache line size 08 Interrupt: pin D routed to IRQ 9 Region 4: I/O ports at c800 [size=32] Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- :00:07.3 Class 0c03: 1106:3038 (rev 1a) Subsystem: 0925:1234 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Latency: 32, cache line size 08 Interrupt: pin D routed to IRQ 9 Region 4: I/O ports at cc00 [size=32] Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- :00:07.4 Class 0c05: 1106:3057 (rev 40) Subsystem: 1106:3057 Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Interrupt: pin ? routed to IRQ 11 Capabilities: [68] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- :00:09.0 Class 0400: 109e:036e (rev 11) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Latency: 32 (4000ns min, 1ns max) Interrupt: pin A routed to IRQ 5 Region 0: Memory at f700 (32-bit, prefetchable) Capabilities: [44] Vital Product Data Capabilities: [4c] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- :00:09.1 Class 0480: 109e:0878 (rev 11) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Latency: 32 (1000ns min, 63750ns max) Interrupt: pin A routed to IRQ 5 Region 0: Memory at f7001000 (32-bit, prefetchable) Capabilities: [44]
Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
Can you do an "lspci -vvn"? I'm looking at quirk_via_irqpic() in
2.6.9, which is what printed this:
> >PCI: Via IRQ fixup for :00:07.2, from 9 to 10
> >PCI: Via IRQ fixup for :00:07.3, from 9 to 10
but it looks like it should only run for PCI_DEVICE_ID_VIA_82C586_2,
PCI_DEVICE_ID_VIA_82C686_5, and PCI_DEVICE_ID_VIA_82C686_6.
You have:
:00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South]
(rev 40)
:00:07.1 IDE interface: VIA Technologies, Inc.
VT82C586A/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master IDE (rev 06)
:00:07.2 USB Controller: VIA Technologies, Inc. USB (rev 1a) (prog-if 00
[UHCI])
:00:07.3 USB Controller: VIA Technologies, Inc. USB (rev 1a) (prog-if 00
[UHCI])
and we apparently ran the quirk for 07.2 and 07.3. I wouldn't
have thought those would have one of the above device IDs. The
"lspci -vvn" should tell us for sure.
2.6.11 removed that quirk and runs quirk_via_bridge() for
all VIA devices, but only sets via_interrupt_line_quirk if
(pdev->devfn == 0), which you don't have. So that's why
my patch didn't do anything.
> Also two more questions:
>
> 1. What is VIA fixup? Is it some hardware bug? Or BIOS problem? Why is it
> needed? On what hardware / software it is needed?
I really don't know much about the VIA fixup. I just noticed
that we seem to be doing it slightly differently in 2.6.11 than
we did in 2.6.9, and thought maybe it was related to your problem.
Here's a changeset that has a couple pointers:
http://linux.bkbits.net:8080/linux-2.5/cset%4041cb9d48DRV4TYe77gvstTawuZFYyQ
> 2. Why this patch shrinked bzImage that much:
>
> -rw-r--r-- 1 root root 1828186 mar 11 23:33 vmlinuz-2.6.11-cko1
> -rw-r--r-- 1 root root 1828355 mar 2 20:48 vmlinuz-2.6.11-cko1.old
I have no idea about this. But it's only a couple hundred bytes.
So here's another patch to try (revert the first one, then apply this).
= drivers/acpi/pci_irq.c 1.37 vs edited =
--- 1.37/drivers/acpi/pci_irq.c 2005-03-01 09:57:29 -07:00
+++ edited/drivers/acpi/pci_irq.c 2005-03-11 15:13:49 -07:00
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -438,10 +439,17 @@
}
}
- if (via_interrupt_line_quirk)
- pci_write_config_byte(dev, PCI_INTERRUPT_LINE, irq & 15);
-
dev->irq = acpi_register_gsi(irq, edge_level, active_high_low);
+
+ if (dev->vendor == PCI_VENDOR_ID_VIA) {
+ u8 old_irq, new_irq = dev->irq & 0xf;
+
+ pci_read_config_byte(dev, PCI_INTERRUPT_LINE, _irq);
+ printk(KERN_INFO PREFIX "Via IRQ fixup for %s, from %d "
+ "to %d\n", pci_name(dev), old_irq, new_irq);
+ udelay(15);
+ pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
+ }
printk(KERN_INFO PREFIX "PCI interrupt %s[%c] -> GSI %u "
"(%s, %s) -> IRQ %d\n",
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
On Fri, 11 Mar 2005, Bjorn Helgaas wrote:
On Fri, 2005-03-11 at 20:36 +0100, Grzegorz Kulewski wrote:
On Fri, 11 Mar 2005, Bjorn Helgaas wrote:
Can you check to see whether there are any BIOS updates available
for your box? It looks to me like your USB controllers are wired
to IRQ9, and that's how the BIOS is leaving them configured.
And if this is a BIOS issue then why it worked for 3 years with all
kernels up to at least 2.6.9
Good point.
Thanks for posting the 2.6.9 output as well. It contains this:
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 10
ACPI: PCI interrupt :00:07.2[D] -> GSI 10 (level, low) -> IRQ 10
ACPI: PCI interrupt :00:07.3[D] -> GSI 10 (level, low) -> IRQ 10
PCI: Via IRQ fixup for :00:07.2, from 9 to 10
PCI: Via IRQ fixup for :00:07.3, from 9 to 10
In 2.6.9, we did all the ACPI IRQ routing early, then did the
Via IRQ fixups. In 2.6.11, ACPI IRQ routing is done only when
a driver claims a device, and the Via IRQ fixup is done a little
differently. In fact, the Via fixup happens before we twiddle
the IOAPIC, where in 2.6.9, it happened after.
Can you try the attached patch to see whether it makes any
difference?
= drivers/acpi/pci_irq.c 1.37 vs edited =
--- 1.37/drivers/acpi/pci_irq.c 2005-03-01 09:57:29 -07:00
+++ edited/drivers/acpi/pci_irq.c 2005-03-11 13:45:56 -07:00
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -438,10 +439,19 @@
}
}
- if (via_interrupt_line_quirk)
- pci_write_config_byte(dev, PCI_INTERRUPT_LINE, irq & 15);
-
dev->irq = acpi_register_gsi(irq, edge_level, active_high_low);
+
+ if (via_interrupt_line_quirk) {
+ u8 old_irq, new_irq = dev->irq & 0xf;
+
+ pci_read_config_byte(dev, PCI_INTERRUPT_LINE, _irq);
+ if (new_irq != old_irq) {
+ printk(KERN_INFO PREFIX "Via IRQ fixup for %s, from %d "
+ "to %d\n", pci_name(dev), old_irq, new_irq);
+ udelay(15);
+ pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
+ }
+ }
printk(KERN_INFO PREFIX "PCI interrupt %s[%c] -> GSI %u "
"(%s, %s) -> IRQ %d\n",
Unfortunatelly no. Here is the log:
Mar 11 23:47:44 kangur Linux version 2.6.11-cko1 ([EMAIL PROTECTED]) (gcc
version 3.3.3 20040412 (Gentoo Linux 3.3.3-r6, ssp-3.3.2-2, pie-8.7.6)) #2
Fri Mar 11 23:32:57 CET 2005
Mar 11 23:47:44 kangur BIOS-provided physical RAM map:
Mar 11 23:47:44 kangur BIOS-e820: - 0009fc00
(usable)
Mar 11 23:47:44 kangur BIOS-e820: 0009fc00 - 000a
(reserved)
Mar 11 23:47:44 kangur BIOS-e820: 000f - 0010
(reserved)
Mar 11 23:47:44 kangur BIOS-e820: 0010 - 1fff
(usable)
Mar 11 23:47:44 kangur BIOS-e820: 1fff - 1fff3000
(ACPI NVS)
Mar 11 23:47:44 kangur BIOS-e820: 1fff3000 - 2000
(ACPI data)
Mar 11 23:47:44 kangur BIOS-e820: - 0001
(reserved)
Mar 11 23:47:44 kangur 511MB LOWMEM available.
Mar 11 23:47:44 kangur On node 0 totalpages: 131056
Mar 11 23:47:44 kangur DMA zone: 4096 pages, LIFO batch:1
Mar 11 23:47:44 kangur Normal zone: 126960 pages, LIFO batch:16
Mar 11 23:47:44 kangur HighMem zone: 0 pages, LIFO batch:1
Mar 11 23:47:44 kangur DMI 2.2 present.
Mar 11 23:47:44 kangur ACPI: RSDP (v000 761686
) @ 0x000f6a70
Mar 11 23:47:44 kangur ACPI: RSDT (v001 761686 AWRDACPI 0x42302e31 AWRD
0x) @ 0x1fff3000
Mar 11 23:47:44 kangur ACPI: FADT (v001 761686 AWRDACPI 0x42302e31 AWRD
0x) @ 0x1fff3040
Mar 11 23:47:44 kangur ACPI: DSDT (v001 761686 AWRDACPI 0x1000 MSFT
0x010c) @ 0x
Mar 11 23:47:44 kangur ACPI: PM-Timer IO Port: 0x4008
Mar 11 23:47:44 kangur Allocating PCI resources starting at 2000 (gap:
2000:dfff)
Mar 11 23:47:44 kangur Built 1 zonelists
Mar 11 23:47:44 kangur Kernel command line: ro root=/dev/hdb4
Mar 11 23:47:44 kangur Local APIC disabled by BIOS -- you can enable it
with "lapic"
Mar 11 23:47:44 kangur mapped APIC to d000 (01402000)
Mar 11 23:47:44 kangur Initializing CPU#0
Mar 11 23:47:44 kangur CPU 0 irqstacks, hard=b0477000 soft=b0476000
Mar 11 23:47:44 kangur PID hash table entries: 2048 (order: 11, 32768
bytes)
Mar 11 23:47:44 kangur Detected 1203.228 MHz processor.
Mar 11 23:47:44 kangur Using pmtmr for high-res timesource
Mar 11 23:47:44 kangur Console: colour VGA+ 80x25
Mar 11 23:47:44 kangur Dentry cache hash table entries: 131072 (order: 7,
524288 bytes)
Mar 11 23:47:44 kangur Inode-cache hash table entries: 65536 (order: 6,
262144 bytes)
Mar 11 23:47:44 kangur Memory: 514940k/524224k available (2543k kernel
code, 8732k reserved, 819k data, 156k init, 0k highmem)
Mar 11 23:47:44 kangur Checking if this processor honours the WP bit even
in supervisor mode... Ok.
Mar 11 23:47:44 kangur
Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
On Fri, 2005-03-11 at 20:36 +0100, Grzegorz Kulewski wrote:
> On Fri, 11 Mar 2005, Bjorn Helgaas wrote:
> > Can you check to see whether there are any BIOS updates available
> > for your box? It looks to me like your USB controllers are wired
> > to IRQ9, and that's how the BIOS is leaving them configured.
>
> And if this is a BIOS issue then why it worked for 3 years with all
> kernels up to at least 2.6.9
Good point.
Thanks for posting the 2.6.9 output as well. It contains this:
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 10
ACPI: PCI interrupt :00:07.2[D] -> GSI 10 (level, low) -> IRQ 10
ACPI: PCI interrupt :00:07.3[D] -> GSI 10 (level, low) -> IRQ 10
PCI: Via IRQ fixup for :00:07.2, from 9 to 10
PCI: Via IRQ fixup for :00:07.3, from 9 to 10
In 2.6.9, we did all the ACPI IRQ routing early, then did the
Via IRQ fixups. In 2.6.11, ACPI IRQ routing is done only when
a driver claims a device, and the Via IRQ fixup is done a little
differently. In fact, the Via fixup happens before we twiddle
the IOAPIC, where in 2.6.9, it happened after.
Can you try the attached patch to see whether it makes any
difference?
= drivers/acpi/pci_irq.c 1.37 vs edited =
--- 1.37/drivers/acpi/pci_irq.c 2005-03-01 09:57:29 -07:00
+++ edited/drivers/acpi/pci_irq.c 2005-03-11 13:45:56 -07:00
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -438,10 +439,19 @@
}
}
- if (via_interrupt_line_quirk)
- pci_write_config_byte(dev, PCI_INTERRUPT_LINE, irq & 15);
-
dev->irq = acpi_register_gsi(irq, edge_level, active_high_low);
+
+ if (via_interrupt_line_quirk) {
+ u8 old_irq, new_irq = dev->irq & 0xf;
+
+ pci_read_config_byte(dev, PCI_INTERRUPT_LINE, _irq);
+ if (new_irq != old_irq) {
+ printk(KERN_INFO PREFIX "Via IRQ fixup for %s, from %d "
+ "to %d\n", pci_name(dev), old_irq, new_irq);
+ udelay(15);
+ pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
+ }
+ }
printk(KERN_INFO PREFIX "PCI interrupt %s[%c] -> GSI %u "
"(%s, %s) -> IRQ %d\n",
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
Hi, Thanks for your prompt anwser. On Fri, 11 Mar 2005, Bjorn Helgaas wrote: On Fri, 2005-03-11 at 00:08 +0100, Grzegorz Kulewski wrote: Anything new about it? Can I provide more usefull info? Can you check to see whether there are any BIOS updates available for your box? It looks to me like your USB controllers are wired to IRQ9, and that's how the BIOS is leaving them configured. Unfortunatelly its 3 years ABIT KG7-Lite. I was begging ABIT for update (to fix some other problems with new CPUs) some time ago but they refused to make new BIOS for this board. And I have the newset release. And if this is a BIOS issue then why it worked for 3 years with all kernels up to at least 2.6.9 (only -mm kernels had some problems with USB and other subsystems since I think 2.6.3-mm? or something like that - I stopped using them soon after)? BTW. My mainboard manual says: "PCI-4 and USB controllers share an IRQ" (the manual is on www.abit.com.tw so you can check it). But ACPI is telling us they're on IRQ10, which seems like a BIOS bug. Maybe this is just some off-by-one in recent kernels? ;-) Can you also post the complete dmesg log without "acpi=off"? There might be an ACPI interrupt link device for the USB controller, and maybe there's something wrong there. Ok, here it goes: Mar 2 23:36:56 kangur syslog-ng[10153]: syslog-ng version 1.6.4 starting Mar 2 23:36:56 kangur syslog-ng[10153]: Changing permissions on special file /dev/tty12 Mar 2 23:36:56 kangur Linux version 2.6.11-cko1 ([EMAIL PROTECTED]) (gcc version 3.3.3 20040412 (Gentoo Linux 3.3.3-r6, ssp-3.3.2-2, pie-8.7.6)) #1 Wed Mar 2 20:48:19 CET 2005 Mar 2 23:36:56 kangur BIOS-provided physical RAM map: Mar 2 23:36:56 kangur BIOS-e820: - 0009fc00 (usable) Mar 2 23:36:56 kangur BIOS-e820: 0009fc00 - 000a (reserved) Mar 2 23:36:56 kangur BIOS-e820: 000f - 0010 (reserved) Mar 2 23:36:56 kangur BIOS-e820: 0010 - 1fff (usable) Mar 2 23:36:56 kangur BIOS-e820: 1fff - 1fff3000 (ACPI NVS) Mar 2 23:36:56 kangur BIOS-e820: 1fff3000 - 2000 (ACPI data) Mar 2 23:36:56 kangur BIOS-e820: - 0001 (reserved) Mar 2 23:36:56 kangur 511MB LOWMEM available. Mar 2 23:36:56 kangur On node 0 totalpages: 131056 Mar 2 23:36:56 kangur DMA zone: 4096 pages, LIFO batch:1 Mar 2 23:36:56 kangur Normal zone: 126960 pages, LIFO batch:16 Mar 2 23:36:56 kangur HighMem zone: 0 pages, LIFO batch:1 Mar 2 23:36:56 kangur DMI 2.2 present. Mar 2 23:36:56 kangur ACPI: RSDP (v000 761686 ) @ 0x000f6a70 Mar 2 23:36:56 kangur ACPI: RSDT (v001 761686 AWRDACPI 0x42302e31 AWRD 0x) @ 0x1fff3000 Mar 2 23:36:56 kangur ACPI: FADT (v001 761686 AWRDACPI 0x42302e31 AWRD 0x) @ 0x1fff3040 Mar 2 23:36:56 kangur ACPI: DSDT (v001 761686 AWRDACPI 0x1000 MSFT 0x010c) @ 0x Mar 2 23:36:56 kangur ACPI: PM-Timer IO Port: 0x4008 Mar 2 23:36:56 kangur Allocating PCI resources starting at 2000 (gap: 2000:dfff) Mar 2 23:36:56 kangur Built 1 zonelists Mar 2 23:36:56 kangur Kernel command line: ro root=/dev/hdb4 Mar 2 23:36:56 kangur Local APIC disabled by BIOS -- you can enable it with "lapic" Mar 2 23:36:56 kangur mapped APIC to d000 (01402000) Mar 2 23:36:56 kangur Initializing CPU#0 Mar 2 23:36:56 kangur CPU 0 irqstacks, hard=b0476000 soft=b0475000 Mar 2 23:36:56 kangur PID hash table entries: 2048 (order: 11, 32768 bytes) Mar 2 23:36:56 kangur Detected 1203.036 MHz processor. Mar 2 23:36:56 kangur Using pmtmr for high-res timesource Mar 2 23:36:56 kangur Console: colour VGA+ 80x25 Mar 2 23:36:56 kangur Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Mar 2 23:36:56 kangur Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Mar 2 23:36:56 kangur Memory: 514944k/524224k available (2543k kernel code, 8728k reserved, 815k data, 156k init, 0k highmem) Mar 2 23:36:56 kangur Checking if this processor honours the WP bit even in supervisor mode... Ok. Mar 2 23:36:56 kangur Calibrating delay loop... 2375.68 BogoMIPS (lpj=1187840) Mar 2 23:36:56 kangur Security Framework v1.0.0 initialized Mar 2 23:36:56 kangur Capability LSM initialized Mar 2 23:36:56 kangur Mount-cache hash table entries: 512 (order: 0, 4096 bytes) Mar 2 23:36:56 kangur CPU: After generic identify, caps: 0383f9ff c1cbf9ff Mar 2 23:36:56 kangur CPU: After vendor identify, caps: 0383f9ff c1cbf9ff Mar 2 23:36:56 kangur CPU: CLK_CTL MSR was 60071263. Reprogramming to 20071263 Mar 2 23:36:56 kangur CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) Mar 2 23:36:56 kangur CPU: L2 Cache: 512K (64 bytes/line) Mar 2 23:36:56 kangur CPU: After all inits, caps: 0383f9ff c1cbf9ff 0020 Mar 2 23:36:56 kangur Intel machine
Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
On Fri, 2005-03-11 at 00:08 +0100, Grzegorz Kulewski wrote: > Anything new about it? > > Can I provide more usefull info? Can you check to see whether there are any BIOS updates available for your box? It looks to me like your USB controllers are wired to IRQ9, and that's how the BIOS is leaving them configured. But ACPI is telling us they're on IRQ10, which seems like a BIOS bug. Can you also post the complete dmesg log without "acpi=off"? There might be an ACPI interrupt link device for the USB controller, and maybe there's something wrong there. > My log (2.6.11 without acpi=off): > Mar 2 23:36:56 kangur USB Universal Host Controller Interface driver v2.2 > Mar 2 23:36:56 kangur ACPI: PCI interrupt :00:07.2[D] -> GSI 10 (level, > low) -> IRQ 10 > Mar 2 23:36:56 kangur uhci_hcd :00:07.2: UHCI Host Controller > Mar 2 23:36:56 kangur uhci_hcd :00:07.2: irq 10, io base 0xc800 > Mar 2 23:36:56 kangur uhci_hcd :00:07.2: new USB bus registered, > assigned bus number 1 > Mar 2 23:36:56 kangur hub 1-0:1.0: USB hub found > Mar 2 23:36:56 kangur hub 1-0:1.0: 2 ports detected > Mar 2 23:36:56 kangur ACPI: PCI interrupt :00:07.3[D] -> GSI 10 (level, > low) -> IRQ 10 > Mar 2 23:36:56 kangur uhci_hcd :00:07.3: UHCI Host Controller > Mar 2 23:36:56 kangur uhci_hcd :00:07.3: irq 10, io base 0xcc00 > Mar 2 23:36:56 kangur uhci_hcd :00:07.3: new USB bus registered, > assigned bus number 2 > Mar 2 23:36:56 kangur hub 2-0:1.0: USB hub found > Mar 2 23:36:56 kangur hub 2-0:1.0: 2 ports detected > My log (2.6.11 with acpi=off): > Mar 3 01:45:48 kangur USB Universal Host Controller Interface driver v2.2 > Mar 3 01:45:48 kangur PCI: Found IRQ 9 for device :00:07.2 > Mar 3 01:45:48 kangur PCI: Sharing IRQ 9 with :00:07.3 > Mar 3 01:45:48 kangur PCI: Sharing IRQ 9 with :00:0b.0 > Mar 3 01:45:48 kangur uhci_hcd :00:07.2: UHCI Host Controller > Mar 3 01:45:48 kangur uhci_hcd :00:07.2: irq 9, io base 0xc800 > Mar 3 01:45:48 kangur uhci_hcd :00:07.2: new USB bus registered, > assigned bus number 1 > Mar 3 01:45:48 kangur hub 1-0:1.0: USB hub found > Mar 3 01:45:48 kangur hub 1-0:1.0: 2 ports detected > Mar 3 01:45:48 kangur PCI: Found IRQ 9 for device :00:07.3 > Mar 3 01:45:48 kangur PCI: Sharing IRQ 9 with :00:07.2 > Mar 3 01:45:48 kangur PCI: Sharing IRQ 9 with :00:0b.0 > Mar 3 01:45:48 kangur uhci_hcd :00:07.3: UHCI Host Controller > Mar 3 01:45:48 kangur uhci_hcd :00:07.3: irq 9, io base 0xcc00 > Mar 3 01:45:48 kangur uhci_hcd :00:07.3: new USB bus registered, > assigned bus number 2 > Mar 3 01:45:48 kangur hub 2-0:1.0: USB hub found > Mar 3 01:45:48 kangur hub 2-0:1.0: 2 ports detected - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
On Fri, 2005-03-11 at 00:08 +0100, Grzegorz Kulewski wrote: Anything new about it? Can I provide more usefull info? Can you check to see whether there are any BIOS updates available for your box? It looks to me like your USB controllers are wired to IRQ9, and that's how the BIOS is leaving them configured. But ACPI is telling us they're on IRQ10, which seems like a BIOS bug. Can you also post the complete dmesg log without acpi=off? There might be an ACPI interrupt link device for the USB controller, and maybe there's something wrong there. My log (2.6.11 without acpi=off): Mar 2 23:36:56 kangur USB Universal Host Controller Interface driver v2.2 Mar 2 23:36:56 kangur ACPI: PCI interrupt :00:07.2[D] - GSI 10 (level, low) - IRQ 10 Mar 2 23:36:56 kangur uhci_hcd :00:07.2: UHCI Host Controller Mar 2 23:36:56 kangur uhci_hcd :00:07.2: irq 10, io base 0xc800 Mar 2 23:36:56 kangur uhci_hcd :00:07.2: new USB bus registered, assigned bus number 1 Mar 2 23:36:56 kangur hub 1-0:1.0: USB hub found Mar 2 23:36:56 kangur hub 1-0:1.0: 2 ports detected Mar 2 23:36:56 kangur ACPI: PCI interrupt :00:07.3[D] - GSI 10 (level, low) - IRQ 10 Mar 2 23:36:56 kangur uhci_hcd :00:07.3: UHCI Host Controller Mar 2 23:36:56 kangur uhci_hcd :00:07.3: irq 10, io base 0xcc00 Mar 2 23:36:56 kangur uhci_hcd :00:07.3: new USB bus registered, assigned bus number 2 Mar 2 23:36:56 kangur hub 2-0:1.0: USB hub found Mar 2 23:36:56 kangur hub 2-0:1.0: 2 ports detected My log (2.6.11 with acpi=off): Mar 3 01:45:48 kangur USB Universal Host Controller Interface driver v2.2 Mar 3 01:45:48 kangur PCI: Found IRQ 9 for device :00:07.2 Mar 3 01:45:48 kangur PCI: Sharing IRQ 9 with :00:07.3 Mar 3 01:45:48 kangur PCI: Sharing IRQ 9 with :00:0b.0 Mar 3 01:45:48 kangur uhci_hcd :00:07.2: UHCI Host Controller Mar 3 01:45:48 kangur uhci_hcd :00:07.2: irq 9, io base 0xc800 Mar 3 01:45:48 kangur uhci_hcd :00:07.2: new USB bus registered, assigned bus number 1 Mar 3 01:45:48 kangur hub 1-0:1.0: USB hub found Mar 3 01:45:48 kangur hub 1-0:1.0: 2 ports detected Mar 3 01:45:48 kangur PCI: Found IRQ 9 for device :00:07.3 Mar 3 01:45:48 kangur PCI: Sharing IRQ 9 with :00:07.2 Mar 3 01:45:48 kangur PCI: Sharing IRQ 9 with :00:0b.0 Mar 3 01:45:48 kangur uhci_hcd :00:07.3: UHCI Host Controller Mar 3 01:45:48 kangur uhci_hcd :00:07.3: irq 9, io base 0xcc00 Mar 3 01:45:48 kangur uhci_hcd :00:07.3: new USB bus registered, assigned bus number 2 Mar 3 01:45:48 kangur hub 2-0:1.0: USB hub found Mar 3 01:45:48 kangur hub 2-0:1.0: 2 ports detected - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
Hi, Thanks for your prompt anwser. On Fri, 11 Mar 2005, Bjorn Helgaas wrote: On Fri, 2005-03-11 at 00:08 +0100, Grzegorz Kulewski wrote: Anything new about it? Can I provide more usefull info? Can you check to see whether there are any BIOS updates available for your box? It looks to me like your USB controllers are wired to IRQ9, and that's how the BIOS is leaving them configured. Unfortunatelly its 3 years ABIT KG7-Lite. I was begging ABIT for update (to fix some other problems with new CPUs) some time ago but they refused to make new BIOS for this board. And I have the newset release. And if this is a BIOS issue then why it worked for 3 years with all kernels up to at least 2.6.9 (only -mm kernels had some problems with USB and other subsystems since I think 2.6.3-mm? or something like that - I stopped using them soon after)? BTW. My mainboard manual says: PCI-4 and USB controllers share an IRQ (the manual is on www.abit.com.tw so you can check it). But ACPI is telling us they're on IRQ10, which seems like a BIOS bug. Maybe this is just some off-by-one in recent kernels? ;-) Can you also post the complete dmesg log without acpi=off? There might be an ACPI interrupt link device for the USB controller, and maybe there's something wrong there. Ok, here it goes: Mar 2 23:36:56 kangur syslog-ng[10153]: syslog-ng version 1.6.4 starting Mar 2 23:36:56 kangur syslog-ng[10153]: Changing permissions on special file /dev/tty12 Mar 2 23:36:56 kangur Linux version 2.6.11-cko1 ([EMAIL PROTECTED]) (gcc version 3.3.3 20040412 (Gentoo Linux 3.3.3-r6, ssp-3.3.2-2, pie-8.7.6)) #1 Wed Mar 2 20:48:19 CET 2005 Mar 2 23:36:56 kangur BIOS-provided physical RAM map: Mar 2 23:36:56 kangur BIOS-e820: - 0009fc00 (usable) Mar 2 23:36:56 kangur BIOS-e820: 0009fc00 - 000a (reserved) Mar 2 23:36:56 kangur BIOS-e820: 000f - 0010 (reserved) Mar 2 23:36:56 kangur BIOS-e820: 0010 - 1fff (usable) Mar 2 23:36:56 kangur BIOS-e820: 1fff - 1fff3000 (ACPI NVS) Mar 2 23:36:56 kangur BIOS-e820: 1fff3000 - 2000 (ACPI data) Mar 2 23:36:56 kangur BIOS-e820: - 0001 (reserved) Mar 2 23:36:56 kangur 511MB LOWMEM available. Mar 2 23:36:56 kangur On node 0 totalpages: 131056 Mar 2 23:36:56 kangur DMA zone: 4096 pages, LIFO batch:1 Mar 2 23:36:56 kangur Normal zone: 126960 pages, LIFO batch:16 Mar 2 23:36:56 kangur HighMem zone: 0 pages, LIFO batch:1 Mar 2 23:36:56 kangur DMI 2.2 present. Mar 2 23:36:56 kangur ACPI: RSDP (v000 761686 ) @ 0x000f6a70 Mar 2 23:36:56 kangur ACPI: RSDT (v001 761686 AWRDACPI 0x42302e31 AWRD 0x) @ 0x1fff3000 Mar 2 23:36:56 kangur ACPI: FADT (v001 761686 AWRDACPI 0x42302e31 AWRD 0x) @ 0x1fff3040 Mar 2 23:36:56 kangur ACPI: DSDT (v001 761686 AWRDACPI 0x1000 MSFT 0x010c) @ 0x Mar 2 23:36:56 kangur ACPI: PM-Timer IO Port: 0x4008 Mar 2 23:36:56 kangur Allocating PCI resources starting at 2000 (gap: 2000:dfff) Mar 2 23:36:56 kangur Built 1 zonelists Mar 2 23:36:56 kangur Kernel command line: ro root=/dev/hdb4 Mar 2 23:36:56 kangur Local APIC disabled by BIOS -- you can enable it with lapic Mar 2 23:36:56 kangur mapped APIC to d000 (01402000) Mar 2 23:36:56 kangur Initializing CPU#0 Mar 2 23:36:56 kangur CPU 0 irqstacks, hard=b0476000 soft=b0475000 Mar 2 23:36:56 kangur PID hash table entries: 2048 (order: 11, 32768 bytes) Mar 2 23:36:56 kangur Detected 1203.036 MHz processor. Mar 2 23:36:56 kangur Using pmtmr for high-res timesource Mar 2 23:36:56 kangur Console: colour VGA+ 80x25 Mar 2 23:36:56 kangur Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Mar 2 23:36:56 kangur Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Mar 2 23:36:56 kangur Memory: 514944k/524224k available (2543k kernel code, 8728k reserved, 815k data, 156k init, 0k highmem) Mar 2 23:36:56 kangur Checking if this processor honours the WP bit even in supervisor mode... Ok. Mar 2 23:36:56 kangur Calibrating delay loop... 2375.68 BogoMIPS (lpj=1187840) Mar 2 23:36:56 kangur Security Framework v1.0.0 initialized Mar 2 23:36:56 kangur Capability LSM initialized Mar 2 23:36:56 kangur Mount-cache hash table entries: 512 (order: 0, 4096 bytes) Mar 2 23:36:56 kangur CPU: After generic identify, caps: 0383f9ff c1cbf9ff Mar 2 23:36:56 kangur CPU: After vendor identify, caps: 0383f9ff c1cbf9ff Mar 2 23:36:56 kangur CPU: CLK_CTL MSR was 60071263. Reprogramming to 20071263 Mar 2 23:36:56 kangur CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) Mar 2 23:36:56 kangur CPU: L2 Cache: 512K (64 bytes/line) Mar 2 23:36:56 kangur CPU: After all inits, caps: 0383f9ff c1cbf9ff 0020 Mar 2 23:36:56 kangur Intel machine check
Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
On Fri, 2005-03-11 at 20:36 +0100, Grzegorz Kulewski wrote:
On Fri, 11 Mar 2005, Bjorn Helgaas wrote:
Can you check to see whether there are any BIOS updates available
for your box? It looks to me like your USB controllers are wired
to IRQ9, and that's how the BIOS is leaving them configured.
And if this is a BIOS issue then why it worked for 3 years with all
kernels up to at least 2.6.9
Good point.
Thanks for posting the 2.6.9 output as well. It contains this:
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 10
ACPI: PCI interrupt :00:07.2[D] - GSI 10 (level, low) - IRQ 10
ACPI: PCI interrupt :00:07.3[D] - GSI 10 (level, low) - IRQ 10
PCI: Via IRQ fixup for :00:07.2, from 9 to 10
PCI: Via IRQ fixup for :00:07.3, from 9 to 10
In 2.6.9, we did all the ACPI IRQ routing early, then did the
Via IRQ fixups. In 2.6.11, ACPI IRQ routing is done only when
a driver claims a device, and the Via IRQ fixup is done a little
differently. In fact, the Via fixup happens before we twiddle
the IOAPIC, where in 2.6.9, it happened after.
Can you try the attached patch to see whether it makes any
difference?
= drivers/acpi/pci_irq.c 1.37 vs edited =
--- 1.37/drivers/acpi/pci_irq.c 2005-03-01 09:57:29 -07:00
+++ edited/drivers/acpi/pci_irq.c 2005-03-11 13:45:56 -07:00
@@ -30,6 +30,7 @@
#include linux/module.h
#include linux/init.h
#include linux/types.h
+#include linux/delay.h
#include linux/proc_fs.h
#include linux/spinlock.h
#include linux/pm.h
@@ -438,10 +439,19 @@
}
}
- if (via_interrupt_line_quirk)
- pci_write_config_byte(dev, PCI_INTERRUPT_LINE, irq 15);
-
dev-irq = acpi_register_gsi(irq, edge_level, active_high_low);
+
+ if (via_interrupt_line_quirk) {
+ u8 old_irq, new_irq = dev-irq 0xf;
+
+ pci_read_config_byte(dev, PCI_INTERRUPT_LINE, old_irq);
+ if (new_irq != old_irq) {
+ printk(KERN_INFO PREFIX Via IRQ fixup for %s, from %d
+ to %d\n, pci_name(dev), old_irq, new_irq);
+ udelay(15);
+ pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
+ }
+ }
printk(KERN_INFO PREFIX PCI interrupt %s[%c] - GSI %u
(%s, %s) - IRQ %d\n,
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
On Fri, 11 Mar 2005, Bjorn Helgaas wrote:
On Fri, 2005-03-11 at 20:36 +0100, Grzegorz Kulewski wrote:
On Fri, 11 Mar 2005, Bjorn Helgaas wrote:
Can you check to see whether there are any BIOS updates available
for your box? It looks to me like your USB controllers are wired
to IRQ9, and that's how the BIOS is leaving them configured.
And if this is a BIOS issue then why it worked for 3 years with all
kernels up to at least 2.6.9
Good point.
Thanks for posting the 2.6.9 output as well. It contains this:
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 10
ACPI: PCI interrupt :00:07.2[D] - GSI 10 (level, low) - IRQ 10
ACPI: PCI interrupt :00:07.3[D] - GSI 10 (level, low) - IRQ 10
PCI: Via IRQ fixup for :00:07.2, from 9 to 10
PCI: Via IRQ fixup for :00:07.3, from 9 to 10
In 2.6.9, we did all the ACPI IRQ routing early, then did the
Via IRQ fixups. In 2.6.11, ACPI IRQ routing is done only when
a driver claims a device, and the Via IRQ fixup is done a little
differently. In fact, the Via fixup happens before we twiddle
the IOAPIC, where in 2.6.9, it happened after.
Can you try the attached patch to see whether it makes any
difference?
= drivers/acpi/pci_irq.c 1.37 vs edited =
--- 1.37/drivers/acpi/pci_irq.c 2005-03-01 09:57:29 -07:00
+++ edited/drivers/acpi/pci_irq.c 2005-03-11 13:45:56 -07:00
@@ -30,6 +30,7 @@
#include linux/module.h
#include linux/init.h
#include linux/types.h
+#include linux/delay.h
#include linux/proc_fs.h
#include linux/spinlock.h
#include linux/pm.h
@@ -438,10 +439,19 @@
}
}
- if (via_interrupt_line_quirk)
- pci_write_config_byte(dev, PCI_INTERRUPT_LINE, irq 15);
-
dev-irq = acpi_register_gsi(irq, edge_level, active_high_low);
+
+ if (via_interrupt_line_quirk) {
+ u8 old_irq, new_irq = dev-irq 0xf;
+
+ pci_read_config_byte(dev, PCI_INTERRUPT_LINE, old_irq);
+ if (new_irq != old_irq) {
+ printk(KERN_INFO PREFIX Via IRQ fixup for %s, from %d
+ to %d\n, pci_name(dev), old_irq, new_irq);
+ udelay(15);
+ pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
+ }
+ }
printk(KERN_INFO PREFIX PCI interrupt %s[%c] - GSI %u
(%s, %s) - IRQ %d\n,
Unfortunatelly no. Here is the log:
Mar 11 23:47:44 kangur Linux version 2.6.11-cko1 ([EMAIL PROTECTED]) (gcc
version 3.3.3 20040412 (Gentoo Linux 3.3.3-r6, ssp-3.3.2-2, pie-8.7.6)) #2
Fri Mar 11 23:32:57 CET 2005
Mar 11 23:47:44 kangur BIOS-provided physical RAM map:
Mar 11 23:47:44 kangur BIOS-e820: - 0009fc00
(usable)
Mar 11 23:47:44 kangur BIOS-e820: 0009fc00 - 000a
(reserved)
Mar 11 23:47:44 kangur BIOS-e820: 000f - 0010
(reserved)
Mar 11 23:47:44 kangur BIOS-e820: 0010 - 1fff
(usable)
Mar 11 23:47:44 kangur BIOS-e820: 1fff - 1fff3000
(ACPI NVS)
Mar 11 23:47:44 kangur BIOS-e820: 1fff3000 - 2000
(ACPI data)
Mar 11 23:47:44 kangur BIOS-e820: - 0001
(reserved)
Mar 11 23:47:44 kangur 511MB LOWMEM available.
Mar 11 23:47:44 kangur On node 0 totalpages: 131056
Mar 11 23:47:44 kangur DMA zone: 4096 pages, LIFO batch:1
Mar 11 23:47:44 kangur Normal zone: 126960 pages, LIFO batch:16
Mar 11 23:47:44 kangur HighMem zone: 0 pages, LIFO batch:1
Mar 11 23:47:44 kangur DMI 2.2 present.
Mar 11 23:47:44 kangur ACPI: RSDP (v000 761686
) @ 0x000f6a70
Mar 11 23:47:44 kangur ACPI: RSDT (v001 761686 AWRDACPI 0x42302e31 AWRD
0x) @ 0x1fff3000
Mar 11 23:47:44 kangur ACPI: FADT (v001 761686 AWRDACPI 0x42302e31 AWRD
0x) @ 0x1fff3040
Mar 11 23:47:44 kangur ACPI: DSDT (v001 761686 AWRDACPI 0x1000 MSFT
0x010c) @ 0x
Mar 11 23:47:44 kangur ACPI: PM-Timer IO Port: 0x4008
Mar 11 23:47:44 kangur Allocating PCI resources starting at 2000 (gap:
2000:dfff)
Mar 11 23:47:44 kangur Built 1 zonelists
Mar 11 23:47:44 kangur Kernel command line: ro root=/dev/hdb4
Mar 11 23:47:44 kangur Local APIC disabled by BIOS -- you can enable it
with lapic
Mar 11 23:47:44 kangur mapped APIC to d000 (01402000)
Mar 11 23:47:44 kangur Initializing CPU#0
Mar 11 23:47:44 kangur CPU 0 irqstacks, hard=b0477000 soft=b0476000
Mar 11 23:47:44 kangur PID hash table entries: 2048 (order: 11, 32768
bytes)
Mar 11 23:47:44 kangur Detected 1203.228 MHz processor.
Mar 11 23:47:44 kangur Using pmtmr for high-res timesource
Mar 11 23:47:44 kangur Console: colour VGA+ 80x25
Mar 11 23:47:44 kangur Dentry cache hash table entries: 131072 (order: 7,
524288 bytes)
Mar 11 23:47:44 kangur Inode-cache hash table entries: 65536 (order: 6,
262144 bytes)
Mar 11 23:47:44 kangur Memory: 514940k/524224k available (2543k kernel
code, 8732k reserved, 819k data, 156k init, 0k highmem)
Mar 11 23:47:44 kangur Checking if this
Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
Can you do an lspci -vvn? I'm looking at quirk_via_irqpic() in
2.6.9, which is what printed this:
PCI: Via IRQ fixup for :00:07.2, from 9 to 10
PCI: Via IRQ fixup for :00:07.3, from 9 to 10
but it looks like it should only run for PCI_DEVICE_ID_VIA_82C586_2,
PCI_DEVICE_ID_VIA_82C686_5, and PCI_DEVICE_ID_VIA_82C686_6.
You have:
:00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South]
(rev 40)
:00:07.1 IDE interface: VIA Technologies, Inc.
VT82C586A/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master IDE (rev 06)
:00:07.2 USB Controller: VIA Technologies, Inc. USB (rev 1a) (prog-if 00
[UHCI])
:00:07.3 USB Controller: VIA Technologies, Inc. USB (rev 1a) (prog-if 00
[UHCI])
and we apparently ran the quirk for 07.2 and 07.3. I wouldn't
have thought those would have one of the above device IDs. The
lspci -vvn should tell us for sure.
2.6.11 removed that quirk and runs quirk_via_bridge() for
all VIA devices, but only sets via_interrupt_line_quirk if
(pdev-devfn == 0), which you don't have. So that's why
my patch didn't do anything.
Also two more questions:
1. What is VIA fixup? Is it some hardware bug? Or BIOS problem? Why is it
needed? On what hardware / software it is needed?
I really don't know much about the VIA fixup. I just noticed
that we seem to be doing it slightly differently in 2.6.11 than
we did in 2.6.9, and thought maybe it was related to your problem.
Here's a changeset that has a couple pointers:
http://linux.bkbits.net:8080/linux-2.5/cset%4041cb9d48DRV4TYe77gvstTawuZFYyQ
2. Why this patch shrinked bzImage that much:
-rw-r--r-- 1 root root 1828186 mar 11 23:33 vmlinuz-2.6.11-cko1
-rw-r--r-- 1 root root 1828355 mar 2 20:48 vmlinuz-2.6.11-cko1.old
I have no idea about this. But it's only a couple hundred bytes.
So here's another patch to try (revert the first one, then apply this).
= drivers/acpi/pci_irq.c 1.37 vs edited =
--- 1.37/drivers/acpi/pci_irq.c 2005-03-01 09:57:29 -07:00
+++ edited/drivers/acpi/pci_irq.c 2005-03-11 15:13:49 -07:00
@@ -30,6 +30,7 @@
#include linux/module.h
#include linux/init.h
#include linux/types.h
+#include linux/delay.h
#include linux/proc_fs.h
#include linux/spinlock.h
#include linux/pm.h
@@ -438,10 +439,17 @@
}
}
- if (via_interrupt_line_quirk)
- pci_write_config_byte(dev, PCI_INTERRUPT_LINE, irq 15);
-
dev-irq = acpi_register_gsi(irq, edge_level, active_high_low);
+
+ if (dev-vendor == PCI_VENDOR_ID_VIA) {
+ u8 old_irq, new_irq = dev-irq 0xf;
+
+ pci_read_config_byte(dev, PCI_INTERRUPT_LINE, old_irq);
+ printk(KERN_INFO PREFIX Via IRQ fixup for %s, from %d
+ to %d\n, pci_name(dev), old_irq, new_irq);
+ udelay(15);
+ pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
+ }
printk(KERN_INFO PREFIX PCI interrupt %s[%c] - GSI %u
(%s, %s) - IRQ %d\n,
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
On Fri, 11 Mar 2005, Bjorn Helgaas wrote: Can you do an lspci -vvn? # lspci -vvn :00:00.0 Class 0600: 1022:700e (rev 13) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort+ SERR- PERR- Latency: 32 Region 0: Memory at f000 (32-bit, prefetchable) Region 1: Memory at f7003000 (32-bit, prefetchable) [size=4K] Region 2: I/O ports at c000 [disabled] [size=4] Capabilities: [a0] AGP version 2.0 Status: RQ=16 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4 Command: RQ=1 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW+ Rate=x4 :00:01.0 Class 0604: 1022:700f Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 32 Bus: primary=00, secondary=01, subordinate=01, sec-latency=32 Memory behind bridge: f400-f5ff Prefetchable memory behind bridge: e800-efff BridgeCtl: Parity- SERR+ NoISA+ VGA+ MAbort- Reset- FastB2B- :00:07.0 Class 0601: 1106:0686 (rev 40) Subsystem: 147b:a702 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 Capabilities: [c0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- :00:07.1 Class 0101: 1106:0571 (rev 06) (prog-if 8a [Master SecP PriP]) Subsystem: 1106:0571 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 32 Region 4: I/O ports at c400 [size=16] Capabilities: [c0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- :00:07.2 Class 0c03: 1106:3038 (rev 1a) Subsystem: 0925:1234 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 32, cache line size 08 Interrupt: pin D routed to IRQ 9 Region 4: I/O ports at c800 [size=32] Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- :00:07.3 Class 0c03: 1106:3038 (rev 1a) Subsystem: 0925:1234 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 32, cache line size 08 Interrupt: pin D routed to IRQ 9 Region 4: I/O ports at cc00 [size=32] Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- :00:07.4 Class 0c05: 1106:3057 (rev 40) Subsystem: 1106:3057 Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Interrupt: pin ? routed to IRQ 11 Capabilities: [68] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- :00:09.0 Class 0400: 109e:036e (rev 11) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR+ Latency: 32 (4000ns min, 1ns max) Interrupt: pin A routed to IRQ 5 Region 0: Memory at f700 (32-bit, prefetchable) Capabilities: [44] Vital Product Data Capabilities: [4c] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- :00:09.1 Class 0480: 109e:0878 (rev 11) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR-
