Hi, this patch (now for 2.6.18-rc5).
I found, on my new VIA with IO-APIC working well, that quirks aren't
good/needed.
After, I found this interesting email http://lkml.org/lkml/2005/8/13/30
by Karsten Wiese, after, Alan Cox writes this
http://lkml.org/lkml/2005/8/16/160 (on same thread) and Karsten Wiese
end ups with the solution on http://lkml.org/lkml/2005/8/18/92, which I
want try to implement.
I have 2 VIAs with almost same IDs (others reporters have
with exactly the same IDs) and in ones I need the quirks and in others
don't, because one don't have APIC enabled, the other have it !?!
we have other reported of the same problem
http://lkml.org/lkml/2006/7/30/59
and
http://lkml.org/lkml/2006/9/1/106
Checking my emails that I send to Len Brown on May of 2005 about this
subject. I found, what I want, is just revert one patch of Bjorn
Helgaas, between kernel 2.6.12-rc5 and 6.14.
Check this out
http://sourceforge.net/mailarchive/message.php?msg_id=11858102
To finish I want put clear, the great work of Bjorn Helgaas which have
made all of this, but at the end, I suspect with one false positive
report introduce this regression, that I hopefully found.
Thanks,
I aspect all of you, your positive vote.
--
S?rgio M. B.
Cc: [email protected]
Cc: [email protected]
Cc: Daniel Drake <[email protected]>
Cc: Alan Cox <[email protected]>
Cc: "Scott J. Harmon" <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: Chris Wedgwood <[email protected]>
Cc: Greg KH <[email protected]>
Signed-off-by: Sergio Monteiro Basto <[email protected]
diff linux-2.6.17.x86_64/drivers/pci/quirks.c.orig linux-2.6.17.x86_64/drivers/pci/quirks.c -up
--- linux-2.6.17.x86_64/drivers/pci/quirks.c.orig 2006-09-04 01:37:09.000000000 +0100
+++ linux-2.6.17.x86_64/drivers/pci/quirks.c 2006-09-04 01:40:16.000000000 +0100
@@ -654,22 +654,24 @@ static void quirk_via_irq(struct pci_dev
{
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
new_irq = dev->irq & 0xf;
pci_read_config_byte(dev, PCI_INTERRUPT_LINE, &irq);
if (new_irq != irq) {
- printk(KERN_INFO "PCI: VIA IRQ fixup for %s, from %d to %d\n",
+ printk(KERN_INFO "PCI: VIA PIC IRQ fixup for %s, from %d to %d\n",
pci_name(dev), irq, new_irq);
udelay(15); /* unknown if delay really needed */
pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
}
}
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_0, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_1, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_2, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_3, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_4, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_5, quirk_via_irq);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq);
/*
* VIA VT82C598 has its device ID settable and many BIOSes
On Mon, 04 Sep 2006 01:42:47 +0100
Sergio Monteiro Basto <[email protected]> wrote:
> Hi, this patch (now for 2.6.18-rc5).
>
>
> I found, on my new VIA with IO-APIC working well, that quirks aren't
> good/needed.
> After, I found this interesting email http://lkml.org/lkml/2005/8/13/30
> by Karsten Wiese, after, Alan Cox writes this
> http://lkml.org/lkml/2005/8/16/160 (on same thread) and Karsten Wiese
> end ups with the solution on http://lkml.org/lkml/2005/8/18/92, which I
> want try to implement.
> I have 2 VIAs with almost same IDs (others reporters have
> with exactly the same IDs) and in ones I need the quirks and in others
> don't, because one don't have APIC enabled, the other have it !?!
>
> we have other reported of the same problem
> http://lkml.org/lkml/2006/7/30/59
> and
> http://lkml.org/lkml/2006/9/1/106
>
> Checking my emails that I send to Len Brown on May of 2005 about this
> subject. I found, what I want, is just revert one patch of Bjorn
> Helgaas, between kernel 2.6.12-rc5 and 6.14.
> Check this out
> http://sourceforge.net/mailarchive/message.php?msg_id=11858102
>
> To finish I want put clear, the great work of Bjorn Helgaas which have
> made all of this, but at the end, I suspect with one false positive
> report introduce this regression, that I hopefully found.
>
This thing is getting embarrassing.
> diff linux-2.6.17.x86_64/drivers/pci/quirks.c.orig linux-2.6.17.x86_64/drivers/pci/quirks.c -up
> --- linux-2.6.17.x86_64/drivers/pci/quirks.c.orig 2006-09-04 01:37:09.000000000 +0100
> +++ linux-2.6.17.x86_64/drivers/pci/quirks.c 2006-09-04 01:40:16.000000000 +0100
> @@ -654,22 +654,24 @@ static void quirk_via_irq(struct pci_dev
> {
> 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
> new_irq = dev->irq & 0xf;
> pci_read_config_byte(dev, PCI_INTERRUPT_LINE, &irq);
> if (new_irq != irq) {
> - printk(KERN_INFO "PCI: VIA IRQ fixup for %s, from %d to %d\n",
> + printk(KERN_INFO "PCI: VIA PIC IRQ fixup for %s, from %d to %d\n",
> pci_name(dev), irq, new_irq);
> udelay(15); /* unknown if delay really needed */
> pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
> }
> }
> -DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_0, quirk_via_irq);
> -DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_1, quirk_via_irq);
> -DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_2, quirk_via_irq);
> -DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_3, quirk_via_irq);
> -DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686, quirk_via_irq);
> -DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_4, quirk_via_irq);
> -DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_5, quirk_via_irq);
> +DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq);
>
> /*
> * VIA VT82C598 has its device ID settable and many BIOSes
>
There's a similar patch in -mm: pci-quirk_via_irq-behaviour-change.patch.
Does that work for you?
--
VGER BF report: H 0
Andrew Morton wrote:
> There's a similar patch in -mm: pci-quirk_via_irq-behaviour-change.patch.
> Does that work for you?
And then, we return to:
Some installations have VIA products on a PCI card. We cannot assume
that all PCI_VENDOR_ID_VIA devices are on-board devices with the special
VIA PIC on-chip routing (the thing quirk_via_irq tweaks).
Jeff
--
VGER BF report: H 0
On Mon, Sep 04, 2006 at 01:44:08AM -0400, Jeff Garzik wrote:
> Some installations have VIA products on a PCI card. We cannot
> assume that all PCI_VENDOR_ID_VIA devices are on-board devices with
> the special VIA PIC on-chip routing (the thing quirk_via_irq
> tweaks).
I'll also point out that I was told (very indirectly, those with
definitive knowledge please speak up) that VIA claimed the recommended
way to deal with these chipset problems is to use ACPI...
However, we know in some cases ACPI doesn't work as-is under Linux,
but apparently does under Windows. In many cases though it does
appear to suffice.
When chasing down why it doesn't work on other main boards someone who
is ACPI knowledgeable claimed that in the past VIA got their ACPI
wrong, so we need to figure out what ACPI specific quirk windows is
using if we go that route.
It would be really nice if someone from VIA could come forward on this
matter.
Now, failing that, Jeff, what about if we try to use ACPI to detect if
the PCI device is on-board or a plug-in card? If we did and ignored
them would that satisfy you?
Yes, I know this is yet-another horrible heuristic and might not work
in all cases, but I think we need to aim to get the majority of
systems broken working pretty promptly. As Andrew said, this really
is quire embarrassing right now.
--
VGER BF report: H 0.3996
Chris Wedgwood wrote:
> Now, failing that, Jeff, what about if we try to use ACPI to detect if
> the PCI device is on-board or a plug-in card? If we did and ignored
> them would that satisfy you?
>
> Yes, I know this is yet-another horrible heuristic and might not work
> in all cases, but I think we need to aim to get the majority of
> systems broken working pretty promptly. As Andrew said, this really
> is quire embarrassing right now.
It's not a question of me being satisfied or embarrassed. The only
question is what works for all cases.
My guess is that we need more complex logic to detect which devices are
truly on-board.
Unfortunately for us, PCI cards with VIA SATA or VIA ethernet exist, so
we cannot continue the current scheme of device ID enumeration either.
Jeff
--
VGER BF report: H 0
On Sun, 2006-09-03 at 22:55 -0700, Chris Wedgwood wrote:
> On Mon, Sep 04, 2006 at 01:44:08AM -0400, Jeff Garzik wrote:
>
> > Some installations have VIA products on a PCI card. We cannot
> > assume that all PCI_VENDOR_ID_VIA devices are on-board devices with
> > the special VIA PIC on-chip routing (the thing quirk_via_irq
> > tweaks).
I don't know if this is a real question. Have we VIA products on PCI
card, running on not VIA chip sets ?
but in this cases, we can add other "if" to exclude this cases from
quirks. Until then I think it is urgent put this VIA PIC quirks back to
state of kernel 2.6.12, with quirking just on PIC mode .
(http://www.kernel.org/diff/diffview.cgi?file=%2Fpub%2Flinux%2Fkernel%
2Fv2.6%2Fpatch-2.6.12.bz2;z=2752)
Thanks,
--
Sérgio M. B.
--
VGER BF report: H 5.50155e-11
Sergio Monteiro Basto wrote:
> I don't know if this is a real question. Have we VIA products on PCI
> card, running on not VIA chip sets ?
A PCI card can be placed into any compatible system.
I test VIA SATA and VIA ethernet exclusively on non-VIA systems, simply
because I don't have access to a VIA-based system anymore.
Jeff
--
VGER BF report: H 0
On Sun, 2006-09-03 at 17:58 -0700, Andrew Morton wrote:
> There's a similar patch in -mm:
> pci-quirk_via_irq-behaviour-change.patch.
> Does that work for you?
For me, the problem is not if it work or not.
For the same VIA IDs, sometimes we need quirk and other times not.
Thanks,
--
Sérgio M. B.
Jeff Garzik wrote:
> Andrew Morton wrote:
>> There's a similar patch in -mm:
>> pci-quirk_via_irq-behaviour-change.patch. Does that work for you?
>
> And then, we return to:
>
> Some installations have VIA products on a PCI card. We cannot assume
> that all PCI_VENDOR_ID_VIA devices are on-board devices with the special
> VIA PIC on-chip routing (the thing quirk_via_irq tweaks).
I'm not sure whether you are commenting on my patch
(pci-quirk_via_irq-behaviour-change.patch), or Sergio's, but just to
clarify:
My patch includes a hack that detects the presence of a VIA southbridge,
and only applies quirks if a southbridge is present.
This isn't perfect, as someone could insert a VIA PCI card into a
VIA-based motherboard and the PCI card would get quirked, but it's the
most accurate solution which has been proposed so far.
If the southbridge detection hack is acceptable, there is no reason why
it could not be combined with Sergio's patch.
Daniel
On Mon, Sep 04, 2006 at 12:54:07PM +0100, Sergio Monteiro Basto wrote:
> I don't know if this is a real question. Have we VIA products on PCI
> card, running on not VIA chip sets ?
Yes. Certainly for on-board devices too.
On Mon, 2006-09-04 at 11:33 -0700, Chris Wedgwood wrote:
> On Mon, Sep 04, 2006 at 12:54:07PM +0100, Sergio Monteiro Basto wrote:
>
> > I don't know if this is a real question. Have we VIA products on PCI
> > card, running on not VIA chip sets ?
>
> Yes. Certainly for on-board devices too.
OK , other argument.
We have billions of VIA chip sets with VIA PCI on-board and
VIA PCI on others chip sets, if exists, are a very few.
So, because some exceptions, we shouldn't stop a resolution of a very
large % of the cases.
Thanks,
--
Sérgio M. B.
Sergio Monteiro Basto wrote:
> On Mon, 2006-09-04 at 11:33 -0700, Chris Wedgwood wrote:
>> On Mon, Sep 04, 2006 at 12:54:07PM +0100, Sergio Monteiro Basto wrote:
>>
>>> I don't know if this is a real question. Have we VIA products on PCI
>>> card, running on not VIA chip sets ?
>> Yes. Certainly for on-board devices too.
>
> OK , other argument.
> We have billions of VIA chip sets with VIA PCI on-board and
> VIA PCI on others chip sets, if exists, are a very few.
> So, because some exceptions, we shouldn't stop a resolution of a very
> large % of the cases.
No thanks. As VIA SATA maintainer, I like being able to use my VIA SATA
PCI card.
Jeff
Ar Maw, 2006-09-05 am 15:55 +0100, ysgrifennodd Sergio Monteiro Basto:
> We have billions of VIA chip sets with VIA PCI on-board and
> VIA PCI on others chip sets, if exists, are a very few.
> So, because some exceptions, we shouldn't stop a resolution of a very
> large % of the cases.
Not true at all. Large numbers of the VIA devices on VIA boards are not
the builtin version. Devices migrate over time from one to the other.
You can tell fron the PCI northbridge what is built in (in theory) but
we need a better way to deal with all this
On Tue, 2006-09-05 at 11:13 -0400, Jeff Garzik wrote:
> Sergio Monteiro Basto wrote:
> > On Mon, 2006-09-04 at 11:33 -0700, Chris Wedgwood wrote:
> >> On Mon, Sep 04, 2006 at 12:54:07PM +0100, Sergio Monteiro Basto wrote:
> >>
> >>> I don't know if this is a real question. Have we VIA products on PCI
> >>> card, running on not VIA chip sets ?
> >> Yes. Certainly for on-board devices too.
> >
> > OK , other argument.
> > We have billions of VIA chip sets with VIA PCI on-board and
> > VIA PCI on others chip sets, if exists, are a very few.
> > So, because some exceptions, we shouldn't stop a resolution of a very
> > large % of the cases.
>
> No thanks. As VIA SATA maintainer, I like being able to use my VIA SATA
> PCI card.
>
> Jeff
I have 2 computer with 2 different Asrock
(http://www.asrock.com/product/775Dual-880Pro.htm) boards, both have a
VIA8237 and a VIA SATA, and both are quirked wrongly, when I use kernels
2.6.17+ .
And if I haven't bought this 2 computers in a supermarket, I won't be
here discussion this subjects.
So I like to remember
http://lkml.org/lkml/2006/7/28/264
http://lkml.org/lkml/2006/9/4/111 ( that confirm a VIA SATA on XT-PIC
mode ) http://lkml.org/lkml/2006/9/1/106 )
So VIA SATA needs my patch or Daniel Drake patch to _WORK_ .
Adding my patch to Daniel Drake patch ( that is already on -mm series )
could be a reasonable solution.
Patch for 2.6.18-rc5-mm1
Cc: Daniel Drake <[email protected]>
Cc: Alan Cox <[email protected]>
Cc: "Scott J. Harmon" <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: Chris Wedgwood <[email protected]>
Cc: Greg KH <[email protected]>
Signed-off-by: Sergio Monteiro Basto <[email protected]
diff linux-2.6.17.x86_64/drivers/pci/quirks.c.orig linux-2.6.17.x86_64/drivers/pci/quirks.c -up
--- linux-2.6.17.x86_64/drivers/pci/quirks.c.orig 2006-09-06 02:03:09.000000000 +0100
+++ linux-2.6.17.x86_64/drivers/pci/quirks.c 2006-09-06 02:05:44.000000000 +0100
@@ -654,6 +654,14 @@ static void quirk_via_irq(struct pci_dev
{
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
if (via_irq_fixup_needed == -1)
via_irq_fixup_needed = pci_dev_present(via_irq_fixup_tbl);
@@ -663,7 +671,7 @@ static void quirk_via_irq(struct pci_dev
new_irq = dev->irq & 0xf;
pci_read_config_byte(dev, PCI_INTERRUPT_LINE, &irq);
if (new_irq != irq) {
- printk(KERN_INFO "PCI: VIA IRQ fixup for %s, from %d to %d\n",
+ printk(KERN_INFO "PCI: VIA PIC IRQ fixup for %s, from %d to %d\n",
pci_name(dev), irq, new_irq);
udelay(15); /* unknown if delay really needed */
pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
Thanks,
--
S?rgio M. B.
Sergio Monteiro Basto wrote:
> On Tue, 2006-09-05 at 11:13 -0400, Jeff Garzik wrote:
>> Sergio Monteiro Basto wrote:
>>> On Mon, 2006-09-04 at 11:33 -0700, Chris Wedgwood wrote:
>>>> On Mon, Sep 04, 2006 at 12:54:07PM +0100, Sergio Monteiro Basto wrote:
>>>>
>>>>> I don't know if this is a real question. Have we VIA products on PCI
>>>>> card, running on not VIA chip sets ?
>>>> Yes. Certainly for on-board devices too.
>>> OK , other argument.
>>> We have billions of VIA chip sets with VIA PCI on-board and
>>> VIA PCI on others chip sets, if exists, are a very few.
>>> So, because some exceptions, we shouldn't stop a resolution of a very
>>> large % of the cases.
>> No thanks. As VIA SATA maintainer, I like being able to use my VIA SATA
>> PCI card.
>>
>> Jeff
>
> I have 2 computer with 2 different Asrock
> (http://www.asrock.com/product/775Dual-880Pro.htm) boards, both have a
> VIA8237 and a VIA SATA, and both are quirked wrongly, when I use kernels
> 2.6.17+ .
> And if I haven't bought this 2 computers in a supermarket, I won't be
> here discussion this subjects.
>
> So I like to remember
> http://lkml.org/lkml/2006/7/28/264
> http://lkml.org/lkml/2006/9/4/111 ( that confirm a VIA SATA on XT-PIC
> mode ) http://lkml.org/lkml/2006/9/1/106 )
>
> So VIA SATA needs my patch or Daniel Drake patch to _WORK_ .
No argument.
I'm just saying that you cannot avoid the VIA-device-not-on-VIA-chipset
case. I don't care which patch is used, as long as _both_ cases work.
Jeff