On Iau, 2005-08-18 at 14:36 +0200, Karsten Wiese wrote:
> Solutions: either calculate correct new_irq (= PIN-Number & 0x0F)
> or don't apply likely wrong value.
>
> Following diff takes the 2nd way.
>
> Well, VT8237 ignores the wrong new_irq in IOAPIC-Mode,
> but its irritating to see dmesg
Am Dienstag, 16. August 2005 19:20 schrieb Alan Cox:
>
> PCI interrupt line routing is used for all V-Bus devices. Thats all
> devices in any way on an internal bus of the north or south bridge. The
> quirk is harmless when applied to other devices.
>
> Note the description of the quirk is still
Am Dienstag, 16. August 2005 19:20 schrieb Alan Cox:
PCI interrupt line routing is used for all V-Bus devices. Thats all
devices in any way on an internal bus of the north or south bridge. The
quirk is harmless when applied to other devices.
Note the description of the quirk is still wrong
On Iau, 2005-08-18 at 14:36 +0200, Karsten Wiese wrote:
Solutions: either calculate correct new_irq (= PIN-Number 0x0F)
or don't apply likely wrong value.
Following diff takes the 2nd way.
Well, VT8237 ignores the wrong new_irq in IOAPIC-Mode,
but its irritating to see dmesg print out
On Maw, 2005-08-16 at 09:49 -0600, Bjorn Helgaas wrote:
> On Tuesday 16 August 2005 9:26 am, Karsten Wiese wrote:
> > What about the following version?
> > quirk_via_686irq() only works on pci_devs that are part of the 686.
> > Sooner or later there'll be more VIA southbridge types, which will
> >
On Tuesday 16 August 2005 9:26 am, Karsten Wiese wrote:
> What about the following version?
> quirk_via_686irq() only works on pci_devs that are part of the 686.
> Sooner or later there'll be more VIA southbridge types, which will
> not need quirk_via_irq() like the 8237.
Do you have VIA spec
Am Dienstag, 16. August 2005 00:31 schrieb Bjorn Helgaas:
> These patches seem unrelated except that they both contain the
> text "via", so I think you should at least split them.
Will do.
> This quirk_via_irq() change seems like an awful lot of work to
> get rid of a few log messages. In my
Am Dienstag, 16. August 2005 00:31 schrieb Bjorn Helgaas:
These patches seem unrelated except that they both contain the
text via, so I think you should at least split them.
Will do.
This quirk_via_irq() change seems like an awful lot of work to
get rid of a few log messages. In my opinion,
On Tuesday 16 August 2005 9:26 am, Karsten Wiese wrote:
What about the following version?
quirk_via_686irq() only works on pci_devs that are part of the 686.
Sooner or later there'll be more VIA southbridge types, which will
not need quirk_via_irq() like the 8237.
Do you have VIA spec
On Maw, 2005-08-16 at 09:49 -0600, Bjorn Helgaas wrote:
On Tuesday 16 August 2005 9:26 am, Karsten Wiese wrote:
What about the following version?
quirk_via_686irq() only works on pci_devs that are part of the 686.
Sooner or later there'll be more VIA southbridge types, which will
not need
On Saturday 13 August 2005 9:10 am, Karsten Wiese wrote:
> this fixes the 'doubled ioapic level interrupt rate' issue I've been
> seeing on a K8T800/AMD64 mainboard.
> It also switches off quirk_via_irq() for the VT8237 southbridge.
These patches seem unrelated except that they both contain the
On Saturday 13 August 2005 9:10 am, Karsten Wiese wrote:
this fixes the 'doubled ioapic level interrupt rate' issue I've been
seeing on a K8T800/AMD64 mainboard.
It also switches off quirk_via_irq() for the VT8237 southbridge.
These patches seem unrelated except that they both contain the
text
On Sat, 13 Aug 2005 12:41:33 -0400, Jeff Garzik <[EMAIL PROTECTED]> wrote:
>Grant Coady wrote:
>> I'm tracking a dataloss on box with this chip, finding it difficult
>> to nail a configuration that reliably produces dataloss, sometimes
>> only one bit (e.g. 'c' --> 'C') of unpacking kernel
Grant Coady wrote:
I'm tracking a dataloss on box with this chip, finding it difficult
to nail a configuration that reliably produces dataloss, sometimes
only one bit (e.g. 'c' --> 'C') of unpacking kernel source tree gets
changed.
I've been watching this thread in the background.
Just to
Am Samstag, 13. August 2005 18:04 schrieb Grant Coady:
>
> I'm tracking a dataloss on box with this chip, finding it difficult
> to nail a configuration that reliably produces dataloss, sometimes
> only one bit (e.g. 'c' --> 'C') of unpacking kernel source tree gets
> changed.
>
> Relevant?
On Sat, 13 Aug 2005 17:10:38 +0200, Karsten Wiese <[EMAIL PROTECTED]> wrote:
>Hi,
>
>this fixes the 'doubled ioapic level interrupt rate' issue I've been
>seeing on a K8T800/AMD64 mainboard.
>It also switches off quirk_via_irq() for the VT8237 southbridge.
I'm tracking a dataloss on box with
Hi,
this fixes the 'doubled ioapic level interrupt rate' issue I've been
seeing on a K8T800/AMD64 mainboard.
It also switches off quirk_via_irq() for the VT8237 southbridge.
As both changes are uncritical fixes, I'll post a real patch to -mm
in a week or so.
Karsten
---
Hi,
this fixes the 'doubled ioapic level interrupt rate' issue I've been
seeing on a K8T800/AMD64 mainboard.
It also switches off quirk_via_irq() for the VT8237 southbridge.
As both changes are uncritical fixes, I'll post a real patch to -mm
in a week or so.
Karsten
---
On Sat, 13 Aug 2005 17:10:38 +0200, Karsten Wiese [EMAIL PROTECTED] wrote:
Hi,
this fixes the 'doubled ioapic level interrupt rate' issue I've been
seeing on a K8T800/AMD64 mainboard.
It also switches off quirk_via_irq() for the VT8237 southbridge.
I'm tracking a dataloss on box with this chip,
Am Samstag, 13. August 2005 18:04 schrieb Grant Coady:
I'm tracking a dataloss on box with this chip, finding it difficult
to nail a configuration that reliably produces dataloss, sometimes
only one bit (e.g. 'c' -- 'C') of unpacking kernel source tree gets
changed.
Relevant? This is
Grant Coady wrote:
I'm tracking a dataloss on box with this chip, finding it difficult
to nail a configuration that reliably produces dataloss, sometimes
only one bit (e.g. 'c' -- 'C') of unpacking kernel source tree gets
changed.
I've been watching this thread in the background.
Just to
On Sat, 13 Aug 2005 12:41:33 -0400, Jeff Garzik [EMAIL PROTECTED] wrote:
Grant Coady wrote:
I'm tracking a dataloss on box with this chip, finding it difficult
to nail a configuration that reliably produces dataloss, sometimes
only one bit (e.g. 'c' -- 'C') of unpacking kernel source tree
22 matches
Mail list logo
