The Linux Kernel Mailing List
 help / color / mirror / Atom feed
* [BUG] VIA quirk fixup failure after 2.6.17-rc3
@ 2006-04-30 16:28 masouds
  2006-05-01  0:01 ` Chris Wedgwood
  2006-05-09 19:14 ` [PATCH] VIA quirk fixup, additional PCI IDs Chris Wedgwood
  0 siblings, 2 replies; 8+ messages in thread
From: masouds @ 2006-04-30 16:28 UTC (permalink / raw)
  To: cw; +Cc: jeff, gregkh, linux-kernel

Hello Chris, 
My machine's tulip card stopped working after I updated to 2.6.17-rc3.git3 which included 75cf7456dd87335f574dcd53c4ae616a2ad71a11 patch of yours. Revesing it made the problem go away; Is there a chance that a VIA pci_id was missed from the list of quirks in your patch? 
The problem was that bringing up this interface always failed with 'IRQ #177: nobody cared!':
---
Apr 30 08:44:54 localhost kernel: irq 177: nobody cared (try booting with the "irqpoll" option)
Apr 30 08:44:54 localhost kernel:  <c10500f4> __report_bad_irq+0x24/0x90   <c10501df> note_interrupt+0x7f/0x240
Apr 30 08:44:54 localhost kernel:  <c1022add> rebalance_tick+0x10d/0x2d0   <c104f9f3> handle_IRQ_event+0x33/0x70
Apr 30 08:44:54 localhost kernel:  <c104fb22> __do_IRQ+0xf2/0x100   <c1007553> do_IRQ+0x23/0x40
Apr 30 08:44:54 localhost kernel:  <c1003d10> default_idle+0x0/0x60   <c1005bf6> common_interrupt+0x1a/0x20
Apr 30 08:44:54 localhost kernel:  <c1003d10> default_idle+0x0/0x60   <c1003d3c> default_idle+0x2c/0x60
Apr 30 08:44:54 localhost kernel:  <c1003dcf> cpu_idle+0x5f/0xf0
Apr 30 08:44:54 localhost kernel: handlers:
Apr 30 08:44:54 localhost kernel: [pg0+392112128/1051796480] (tulip_interrupt+0x0/0xee0 [tulip])
Apr 30 08:44:54 localhost kernel: Disabling IRQ #177
Apr 30 08:45:04 localhost kernel: eth0: no IPv6 routers present
Apr 30 08:48:21 localhost kernel: NETDEV WATCHDOG: eth0: transmit timed out
Apr 30 08:48:21 localhost kernel: eth0: Transmit timed out, status e4670045, CSR12 45e1d0cc, resetting...
----

Manually removing that patch made things work again.
The machine is a MSI-694D2-Pro2 dual CPU P3/866Mhz machine with 384 megs of ram.
For more info, here is my 'lspci -vv' output:

0000:00:00.0 Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x] (rev c4)
	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
	Region 0: Memory at c0000000 (32-bit, prefetchable) [size=256M]
	Capabilities: [a0] AGP version 2.0
		Status: RQ=32 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=<none>
	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-

0000:00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x AGP] (prog-if 00 [Normal decode])
	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
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
	Memory behind bridge: d0000000-d1ffffff
	Prefetchable memory behind bridge: d2000000-d2ffffff
	BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B-
	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-

0000:00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40)
	Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge
	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-

0000:00:07.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP])
	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 9000 [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-

0000:00:07.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 16) (prog-if 00 [UHCI])
	Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller
	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: 0x08 (32 bytes)
	Interrupt: pin D routed to IRQ 10
	Region 4: I/O ports at 9400 [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-

0000:00:07.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 16) (prog-if 00 [UHCI])
	Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller
	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: 0x08 (32 bytes)
	Interrupt: pin D routed to IRQ 10
	Region 4: I/O ports at 9800 [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-

0000:00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40)
	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-

0000:00:0c.0 RAID bus controller: Promise Technology, Inc. PDC20265 (FastTrak100 Lite/Ultra100) (rev 02)
	Subsystem: Promise Technology, Inc. Ultra100
	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
	Interrupt: pin A routed to IRQ 169
	Region 0: I/O ports at ac00 [size=8]
	Region 1: I/O ports at b000 [size=4]
	Region 2: I/O ports at b400 [size=8]
	Region 3: I/O ports at b800 [size=4]
	Region 4: I/O ports at bc00 [size=64]
	Region 5: Memory at d4000000 (32-bit, non-prefetchable) [size=128K]
	Expansion ROM at 20040000 [disabled] [size=64K]
	Capabilities: [58] Power Management version 1
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:00:0f.0 Ethernet controller: Macronix, Inc. [MXIC] MX987x5 (rev 25)
	Subsystem: National Datacomm Corp: Unknown device 8110
	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 (2000ns min, 14000ns max), Cache Line Size: 0x08 (32 bytes)
	Interrupt: pin A routed to IRQ 177
	Region 0: I/O ports at c000 [size=256]
	Region 1: Memory at d4020000 (32-bit, non-prefetchable) [size=256]
	Expansion ROM at 20000000 [disabled] [size=256K]
	Capabilities: [44] 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-

0000:00:10.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 43)
	Subsystem: D-Link System Inc DFE-530TX rev A
	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 (750ns min, 2000ns max), Cache Line Size: 0x08 (32 bytes)
	Interrupt: pin A routed to IRQ 169
	Region 0: I/O ports at c400 [size=256]
	Region 1: Memory at d4021000 (32-bit, non-prefetchable) [size=256]
	Expansion ROM at 20050000 [disabled] [size=64K]
	Capabilities: [40] 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-

0000:01:00.0 VGA compatible controller: Intel Corp. 82740 (i740) AGP Graphics Accelerator (rev 21) (prog-if 00 [VGA])
	Subsystem: Diamond Multimedia Systems Stealth II G460
	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
	Interrupt: pin A routed to IRQ 5
	Region 0: Memory at d2000000 (32-bit, prefetchable) [size=16M]
	Region 1: Memory at d1000000 (32-bit, non-prefetchable) [size=512K]
	Expansion ROM at d0000000 [disabled] [size=256K]
	Capabilities: [d0] AGP version 1.0
		Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW- AGP3- Rate=x1,x2
		Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=<none>
	Capabilities: [dc] Power Management version 1
		Flags: PMEClk- DSI+ D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

-------------
cheers, 
Masoud Sharbiani

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

* Re: [BUG] VIA quirk fixup failure after 2.6.17-rc3
  2006-04-30 16:28 [BUG] VIA quirk fixup failure after 2.6.17-rc3 masouds
@ 2006-05-01  0:01 ` Chris Wedgwood
  2006-05-09 19:14 ` [PATCH] VIA quirk fixup, additional PCI IDs Chris Wedgwood
  1 sibling, 0 replies; 8+ messages in thread
From: Chris Wedgwood @ 2006-05-01  0:01 UTC (permalink / raw)
  To: masouds; +Cc: jeff, gregkh, linux-kernel

On Sun, Apr 30, 2006 at 09:28:20AM -0700, masouds@masoud.ir wrote:

> My machine's tulip card stopped working after I updated to 2.6.17-rc3.git3
> which included 75cf7456dd87335f574dcd53c4ae616a2ad71a11 patch of
> yours. Revesing it made the problem go away; Is there a chance that a VIA
> pci_id was missed from the list of quirks in your patch?

it sounds like it

i just grepped the pci_ids.h again and didn't see one missing, could you
also send me the output of "lspci -n" please?

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

* [PATCH] VIA quirk fixup, additional PCI IDs
  2006-04-30 16:28 [BUG] VIA quirk fixup failure after 2.6.17-rc3 masouds
  2006-05-01  0:01 ` Chris Wedgwood
@ 2006-05-09 19:14 ` Chris Wedgwood
  2006-05-09 19:59   ` Andrew Morton
  1 sibling, 1 reply; 8+ messages in thread
From: Chris Wedgwood @ 2006-05-09 19:14 UTC (permalink / raw)
  To: LKML, Andrew Morton; +Cc: masouds, jeff, gregkh

An earlier commit (75cf7456dd87335f574dcd53c4ae616a2ad71a11) changed
an overly-zealous PCI quirk to only poke those VIA devices that need
it.  However, some PCI devices were not included in what I hope is now
the full list.

This should I hope correct this.

Thanks to Masoud Sharbiani <masouds@masoud.ir> for pointing this out
and testing the fix.


Signed-of-By: Chris Wedgwood <cw@f00f.org>

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 19e2b17..0d36d50 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -634,6 +634,9 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_V
  * non-x86 architectures (yes Via exists on PPC among other places),
  * we must mask the PCI_INTERRUPT_LINE value versus 0xf to get
  * interrupts delivered properly.
+ *
+ * Some of the on-chip devices are actually '586 devices' so they are
+ * listed here.
  */
 static void quirk_via_irq(struct pci_dev *dev)
 {
@@ -648,6 +651,10 @@ static void quirk_via_irq(struct pci_dev
 		pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
 	}
 }
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_0, quirk_via_irq);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_1, quirk_via_irq);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_2, quirk_via_irq);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_3, quirk_via_irq);
 DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686, quirk_via_irq);
 DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_4, quirk_via_irq);
 DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_5, quirk_via_irq);

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

* Re: [PATCH] VIA quirk fixup, additional PCI IDs
  2006-05-09 19:14 ` [PATCH] VIA quirk fixup, additional PCI IDs Chris Wedgwood
@ 2006-05-09 19:59   ` Andrew Morton
  2006-05-09 20:14     ` Dave Jones
  2006-05-09 20:24     ` Chris Wedgwood
  0 siblings, 2 replies; 8+ messages in thread
From: Andrew Morton @ 2006-05-09 19:59 UTC (permalink / raw)
  To: Chris Wedgwood; +Cc: linux-kernel, masouds, jeff, gregkh

Chris Wedgwood <cw@f00f.org> wrote:
>
> An earlier commit (75cf7456dd87335f574dcd53c4ae616a2ad71a11) changed
> an overly-zealous PCI quirk to only poke those VIA devices that need
> it.  However, some PCI devices were not included in what I hope is now
> the full list.
> 
> This should I hope correct this.
> 
> Thanks to Masoud Sharbiani <masouds@masoud.ir> for pointing this out
> and testing the fix.

This looks like a 2.6.17-worthy fix, but it's not clear.  Help.  What
happens if 2.6.17 doesn't have this??

> 
> Signed-of-By: Chris Wedgwood <cw@f00f.org>

Wanna buy an "f"?

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

* Re: [PATCH] VIA quirk fixup, additional PCI IDs
  2006-05-09 19:59   ` Andrew Morton
@ 2006-05-09 20:14     ` Dave Jones
  2006-05-09 20:41       ` Andrew Morton
  2006-05-09 20:24     ` Chris Wedgwood
  1 sibling, 1 reply; 8+ messages in thread
From: Dave Jones @ 2006-05-09 20:14 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Chris Wedgwood, linux-kernel, masouds, jeff, gregkh

On Tue, May 09, 2006 at 12:59:16PM -0700, Andrew Morton wrote:
 > Chris Wedgwood <cw@f00f.org> wrote:
 > >
 > > An earlier commit (75cf7456dd87335f574dcd53c4ae616a2ad71a11) changed
 > > an overly-zealous PCI quirk to only poke those VIA devices that need
 > > it.  However, some PCI devices were not included in what I hope is now
 > > the full list.
 > > 
 > > This should I hope correct this.
 > > 
 > > Thanks to Masoud Sharbiani <masouds@masoud.ir> for pointing this out
 > > and testing the fix.
 > 
 > This looks like a 2.6.17-worthy fix, but it's not clear.  Help.  What
 > happens if 2.6.17 doesn't have this??

We won't run the quirk on machines that used to have it run,
so we get buggered up irq routing.

		Dave

-- 
http://www.codemonkey.org.uk

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

* Re: [PATCH] VIA quirk fixup, additional PCI IDs
  2006-05-09 19:59   ` Andrew Morton
  2006-05-09 20:14     ` Dave Jones
@ 2006-05-09 20:24     ` Chris Wedgwood
  1 sibling, 0 replies; 8+ messages in thread
From: Chris Wedgwood @ 2006-05-09 20:24 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel, masouds, jeff, gregkh

On Tue, May 09, 2006 at 12:59:16PM -0700, Andrew Morton wrote:

> This looks like a 2.6.17-worthy fix, but it's not clear.  Help.
> What happens if 2.6.17 doesn't have this??

Some machines with this hardware stop working.

> Wanna buy an "f"?

Sure.  How much?

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

* Re: [PATCH] VIA quirk fixup, additional PCI IDs
  2006-05-09 20:14     ` Dave Jones
@ 2006-05-09 20:41       ` Andrew Morton
  2006-05-09 20:46         ` Chris Wedgwood
  0 siblings, 1 reply; 8+ messages in thread
From: Andrew Morton @ 2006-05-09 20:41 UTC (permalink / raw)
  To: Dave Jones; +Cc: cw, linux-kernel, masouds, jeff, gregkh

Dave Jones <davej@redhat.com> wrote:
>
> On Tue, May 09, 2006 at 12:59:16PM -0700, Andrew Morton wrote:
>  > Chris Wedgwood <cw@f00f.org> wrote:
>  > >
>  > > An earlier commit (75cf7456dd87335f574dcd53c4ae616a2ad71a11) changed
>  > > an overly-zealous PCI quirk to only poke those VIA devices that need
>  > > it.  However, some PCI devices were not included in what I hope is now
>  > > the full list.
>  > > 
>  > > This should I hope correct this.
>  > > 
>  > > Thanks to Masoud Sharbiani <masouds@masoud.ir> for pointing this out
>  > > and testing the fix.
>  > 
>  > This looks like a 2.6.17-worthy fix, but it's not clear.  Help.  What
>  > happens if 2.6.17 doesn't have this??
> 
> We won't run the quirk on machines that used to have it run,
> so we get buggered up irq routing.
> 

OK..

We used to have

DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq);

and we now have

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

which is rather a step backwards, because we need to keep that list updated
now, and we'll fail to catch new devices.

What happens if we just revert 75cf7456dd87335f574dcd53c4ae616a2ad71a11?

It says

    Alan Cox pointed out that the VIA 'IRQ fixup' was erroneously running
    on my system which has no VIA southbridge (but I do have a VIA IEEE
    1394 device).

but so what?  Did anything actually go wrong?  Is it likely to go wrong in
the future?

Is there was a problem, is there something we can do at runtime in
quirk_via_irq() to avoid the problem, rather than expanding out the fixup
list in this manner?

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

* Re: [PATCH] VIA quirk fixup, additional PCI IDs
  2006-05-09 20:41       ` Andrew Morton
@ 2006-05-09 20:46         ` Chris Wedgwood
  0 siblings, 0 replies; 8+ messages in thread
From: Chris Wedgwood @ 2006-05-09 20:46 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Dave Jones, linux-kernel, masouds, jeff, gregkh

On Tue, May 09, 2006 at 01:41:01PM -0700, Andrew Morton wrote:

> DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID,
> quirk_via_irq);

which is wrong, we don't want to apply the qurik for *ALL* via devices

the comment says we want it only for on-ship devices

> 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);
>
> which is rather a step backwards, because we need to keep that list
> updated now, and we'll fail to catch new devices.

as best as i can tell this is a complete list

i tried to get details of people with hardware and was told to check
in a museum :-)

also, what *new* devices? this hardware is pretty ancient what we have
listed now should be close to everything

> What happens if we just revert
> 75cf7456dd87335f574dcd53c4ae616a2ad71a11?

the quirk gets run for VIA chips on chipsets that don't need it, so
the interrupt line is masked down when it sometimes shouldn't be (does
it mean they will always be IO-APIC-edge / PIC in that case?)

> Is there was a problem, is there something we can do at runtime in
> quirk_via_irq() to avoid the problem, rather than expanding out the
> fixup list in this manner?

from reading the comment and chedcking over pci_ids.h i think the list
is complete

in fact, i'm not sure that PCI_DEVICE_ID_VIA_82C586_0 and
PCI_DEVICE_ID_VIA_82C686 are strictly speaking supposed to be in the
list, it's unclear there and seems harmless enough

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

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

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-04-30 16:28 [BUG] VIA quirk fixup failure after 2.6.17-rc3 masouds
2006-05-01  0:01 ` Chris Wedgwood
2006-05-09 19:14 ` [PATCH] VIA quirk fixup, additional PCI IDs Chris Wedgwood
2006-05-09 19:59   ` Andrew Morton
2006-05-09 20:14     ` Dave Jones
2006-05-09 20:41       ` Andrew Morton
2006-05-09 20:46         ` Chris Wedgwood
2006-05-09 20:24     ` Chris Wedgwood

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox