Dropped IRQ disables Radeon 3D

Dropped IRQ disables Radeon 3D

[Michael Witten]

I've been randomly getting the following backtrace in dmesg for a
while now (I thought I built my kernel with debugging support and
symbols, but I guess not, so sorry if it's not that helpful); at
the time, I was running:

  v2.6.39-rc4-183-g0f1d9f7 (0f1d9f78ce41a8874d30271ef8480e6f8f7f1fce)

It only seems like my 3D acceleration is disabled as a result
of disabling the IRQ (and the IRQ number is not always the
same).

I can fix my 3D acceleration by suspending to ram and then
waking my system up again.

  [357580.931252] irq 11: nobody cared (try booting with the "irqpoll" option)
  [357580.931260] Pid: 0, comm: swapper Not tainted 2.6.39-rc4-0f1d9f78ce41a8874d30271ef8480e6f8f7f1fce-THOR-205+ #4
  [357580.931264] Call Trace:
  [357580.931276]  [<c1329df1>] ? __report_bad_irq.isra.6+0x37/0x83
  [357580.931283]  [<c12900cb>] ? snd_intel8x0_interrupt+0x4e/0x1c0
  [357580.931289]  [<c104d6a3>] ? note_interrupt+0x110/0x175
  [357580.931296]  [<c121be98>] ? tg3_interrupt_tagged+0x29/0x70
  [357580.931301]  [<c104c832>] ? handle_irq_event_percpu+0x105/0x117
  [357580.931306]  [<c104da68>] ? unmask_irq+0x1a/0x1a
  [357580.931310]  [<c104c85d>] ? handle_irq_event+0x19/0x24
  [357580.931314]  [<c104daa8>] ? handle_level_irq+0x40/0x56
  [357580.931318]  <IRQ>  [<c100358a>] ? do_IRQ+0x2e/0x81
  [357580.931327]  [<c1024510>] ? irq_exit+0x44/0x67
  [357580.931334]  [<c132e2a9>] ? common_interrupt+0x29/0x30
  [357580.931339]  [<c1024345>] ? __do_softirq+0x30/0xe5
  [357580.931343]  [<c1024315>] ? local_bh_enable+0x2/0x2
  [357580.931346]  <IRQ>  [<c10244fd>] ? irq_exit+0x31/0x67
  [357580.931353]  [<c10035ca>] ? do_IRQ+0x6e/0x81
  [357580.931360]  [<c1147dd7>] ? acpi_hw_write_port+0x22/0x83
  [357580.931365]  [<c132e2a9>] ? common_interrupt+0x29/0x30
  [357580.931371]  [<c1154f11>] ? acpi_idle_enter_bm+0x1d5/0x20a
  [357580.931378]  [<c1261150>] ? cpuidle_idle_call+0x65/0x95
  [357580.931382]  [<c1001577>] ? cpu_idle+0x23/0x3d
  [357580.931387]  [<c14dd60b>] ? start_kernel+0x263/0x268
  [357580.931392]  [<c14dd151>] ? loglevel+0x14/0x14
  [357580.931395] handlers:
  [357580.931397] [<c11bdcb4>] (radeon_driver_irq_handler_kms+0x0/0x10)
  [357580.931405] [<c122cca3>] (usb_hcd_irq+0x0/0x5e)
  [357580.931411] [<c122cca3>] (usb_hcd_irq+0x0/0x5e)
  [357580.931415] [<c121be6f>] (tg3_interrupt_tagged+0x0/0x70)
  [357580.931420] [<c129007d>] (snd_intel8x0_interrupt+0x0/0x1c0)
  [357580.931426] Disabling IRQ #11

Sincerely,
Michael Witten

Dropped IRQ disables Radeon 3D

[Michael Witten]

This is kind of a status update.

On Mon, 02 May 2011 20:19:35 +0000, Michael Witten wrote:

> I've been randomly getting the following backtrace in dmesg for a
> while now (I thought I built my kernel with debugging support and
> symbols, but I guess not, so sorry if it's not that helpful); at
> the time, I was running:
>
>   v2.6.39-rc4-183-g0f1d9f7 (0f1d9f78ce41a8874d30271ef8480e6f8f7f1fce)
>
> It only seems like my 3D acceleration is disabled as a result
> of disabling the IRQ (and the IRQ number is not always the
> same).
>
> I can fix my 3D acceleration by suspending to ram and then
> waking my system up again.
>
>   [357580.931252] irq 11: nobody cared (try booting with the "irqpoll" option)
>   [357580.931260] Pid: 0, comm: swapper Not tainted 2.6.39-rc4-0f1d9f78ce41a8874d30271ef8480e6f8f7f1fce-THOR-205+ #4
>   [357580.931264] Call Trace:
>   [357580.931276]  [<c1329df1>] ? __report_bad_irq.isra.6+0x37/0x83
>   [357580.931283]  [<c12900cb>] ? snd_intel8x0_interrupt+0x4e/0x1c0
>   [357580.931289]  [<c104d6a3>] ? note_interrupt+0x110/0x175
>   [357580.931296]  [<c121be98>] ? tg3_interrupt_tagged+0x29/0x70
>   [357580.931301]  [<c104c832>] ? handle_irq_event_percpu+0x105/0x117
>   [357580.931306]  [<c104da68>] ? unmask_irq+0x1a/0x1a
>   [357580.931310]  [<c104c85d>] ? handle_irq_event+0x19/0x24
>   [357580.931314]  [<c104daa8>] ? handle_level_irq+0x40/0x56
>   [357580.931318]  <IRQ>  [<c100358a>] ? do_IRQ+0x2e/0x81
>   [357580.931327]  [<c1024510>] ? irq_exit+0x44/0x67
>   [357580.931334]  [<c132e2a9>] ? common_interrupt+0x29/0x30
>   [357580.931339]  [<c1024345>] ? __do_softirq+0x30/0xe5
>   [357580.931343]  [<c1024315>] ? local_bh_enable+0x2/0x2
>   [357580.931346]  <IRQ>  [<c10244fd>] ? irq_exit+0x31/0x67
>   [357580.931353]  [<c10035ca>] ? do_IRQ+0x6e/0x81
>   [357580.931360]  [<c1147dd7>] ? acpi_hw_write_port+0x22/0x83
>   [357580.931365]  [<c132e2a9>] ? common_interrupt+0x29/0x30
>   [357580.931371]  [<c1154f11>] ? acpi_idle_enter_bm+0x1d5/0x20a
>   [357580.931378]  [<c1261150>] ? cpuidle_idle_call+0x65/0x95
>   [357580.931382]  [<c1001577>] ? cpu_idle+0x23/0x3d
>   [357580.931387]  [<c14dd60b>] ? start_kernel+0x263/0x268
>   [357580.931392]  [<c14dd151>] ? loglevel+0x14/0x14
>   [357580.931395] handlers:
>   [357580.931397] [<c11bdcb4>] (radeon_driver_irq_handler_kms+0x0/0x10)
>   [357580.931405] [<c122cca3>] (usb_hcd_irq+0x0/0x5e)
>   [357580.931411] [<c122cca3>] (usb_hcd_irq+0x0/0x5e)
>   [357580.931415] [<c121be6f>] (tg3_interrupt_tagged+0x0/0x70)
>   [357580.931420] [<c129007d>] (snd_intel8x0_interrupt+0x0/0x1c0)
>   [357580.931426] Disabling IRQ #11

Arnuschky wrote to me about this related Debian bug report:

  Fri, 2010-06-18 10:21:05 +0000
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586312

I popped over to #radeon on freenode where user agd5f told me to
try the following on the kernel command line:

  pci=nomsi

After reading about MSIs and the requisite CONFIG_* settings, I
realized that I didn't even have MSI support in the kernel anyway.
Then agd5f suggested the following patches by Benjamin Herrenschmidt
might be of help:

  http://lists.freedesktop.org/archives/dri-devel/2011-July/012980.html
  http://lists.freedesktop.org/archives/dri-devel/2011-July/012981.html

the latter of which fixes a syncronization bug on systems that use
non-MSI IRQs (presumably pin-based IRQs) for the radeon device/driver.

For my system, I decided to enable MSI/MSI-X support by building
Linux with the following configuration variables set:

  CONFIG_PCI=y
  CONFIG_X86_LOCAL_APIC=y
  CONFIG_X86_IO_APIC=y
  CONFIG_PCI_MSI=y

and making sure I get the following:

  $ dmesg | grep MSI | grep radeon 
  radeon 0000:01:00.0: irq 42 for MSI/MSI-X
  radeon 0000:01:00.0: radeon: using MSI.

I'm not sure if this will avoid the problem, but it sure seems like
a good bet.

Sincerely,
Michael Witten

Re: Dropped IRQ disables Radeon 3D

[Benjamin Herrenschmidt]

On Fri, 2011-07-15 at 08:20 +0000, Michael Witten wrote:
> 
> Arnuschky wrote to me about this related Debian bug report:
> 
>   Fri, 2010-06-18 10:21:05 +0000
>   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586312
> 
> I popped over to #radeon on freenode where user agd5f told me to
> try the following on the kernel command line:
> 
>   pci=nomsi
> 
> After reading about MSIs and the requisite CONFIG_* settings, I
> realized that I didn't even have MSI support in the kernel anyway.
> Then agd5f suggested the following patches by Benjamin Herrenschmidt
> might be of help:

Another problem I noticed is some cards, when not using MSIs, still seem
to shoot an MSI with whatever value was last programmed into the MSI
configuration space. Can you check with lspci -vv if there's a non-0
value in there ? It -could- be that your get bogus MSIs.

Cheers,
Ben.

> 
> http://lists.freedesktop.org/archives/dri-devel/2011-July/012980.html
> 
> http://lists.freedesktop.org/archives/dri-devel/2011-July/012981.html
> 
> the latter of which fixes a syncronization bug on systems that use
> non-MSI IRQs (presumably pin-based IRQs) for the radeon device/driver.
> 
> For my system, I decided to enable MSI/MSI-X support by building
> Linux with the following configuration variables set:
> 
>   CONFIG_PCI=y
>   CONFIG_X86_LOCAL_APIC=y
>   CONFIG_X86_IO_APIC=y
>   CONFIG_PCI_MSI=y
> 
> and making sure I get the following:
> 
>   $ dmesg | grep MSI | grep radeon 
>   radeon 0000:01:00.0: irq 42 for MSI/MSI-X
>   radeon 0000:01:00.0: radeon: using MSI.
> 
> I'm not sure if this will avoid the problem, but it sure seems like
> a good bet.
> 
> 

Re: Dropped IRQ disables Radeon 3D

[Michael Witten]

On Fri, 15 Jul 2011 19:09:44 +1000, Benjamin Herrenschmidt wrote:

> On Fri, 2011-07-15 at 08:20 +0000, Michael Witten wrote:
>> 
>> Arnuschky wrote to me about this related Debian bug report:
>> 
>>   Fri, 2010-06-18 10:21:05 +0000
>>   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586312
>> 
>> I popped over to #radeon on freenode where user agd5f told me to
>> try the following on the kernel command line:
>> 
>>   pci=nomsi
>> 
>> After reading about MSIs and the requisite CONFIG_* settings, I
>> realized that I didn't even have MSI support in the kernel anyway.
>> Then agd5f suggested the following patches by Benjamin Herrenschmidt
>> might be of help:
>
> Another problem I noticed is some cards, when not using MSIs, still seem
> to shoot an MSI with whatever value was last programmed into the MSI
> configuration space. Can you check with lspci -vv if there's a non-0
> value in there ? It -could- be that your get bogus MSIs.

So, you want me to boot my Linux version that doesn't have MSI support
and check whether `sudo lspci -vv' says that it is using MSIs?

Re: Dropped IRQ disables Radeon 3D

[Arnuschky]

On Fri, 15 Jul 2011 10:53:41 -0000 Michael Witten <mfwitten@gmail.com>
wrote:
> On Fri, 15 Jul 2011 19:09:44 +1000, Benjamin Herrenschmidt wrote:
> >
> > Another problem I noticed is some cards, when not using MSIs, still
> > seem to shoot an MSI with whatever value was last programmed into
> > the MSI configuration space. Can you check with lspci -vv if
> > there's a non-0 value in there ? It -could- be that your get bogus
> > MSIs.
> 
> So, you want me to boot my Linux version that doesn't have MSI support
> and check whether `sudo lspci -vv' says that it is using MSIs?

I thought that you've enabled it now? Anyways, I do have an enabled MSI
kernel (2.6.38 ubuntu 64bit stock):

  # grep MSI /boot/config-2.6.38-8-server 
  CONFIG_ARCH_SUPPORTS_MSI=y
  CONFIG_PCI_MSI=y
  CONFIG_MSI_LAPTOP=m
  CONFIG_MSI_WMI=m

But it does not seem to be enabled/working on my system:

  # dmesg | grep -i msi
  [    0.372534] pci 0000:04:00.0: PXH quirk detected; SHPC device MSI disabled
  [    0.372668] pci 0000:04:00.2: PXH quirk detected; SHPC device MSI disabled
  [    0.373371] pci 0000:0a:00.0: PXH quirk detected; SHPC device MSI disabled
  [    0.373498] pci 0000:0a:00.2: PXH quirk detected; SHPC device MSI disabled
  
although pci -vv does list it for my PCIe bridges (see below). I will
try to run with nomsi as soon as I can reboot the machine...

Cheers,
Arnuschky

  0a:00.2 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI Bridge B (rev 09) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Bus: primary=0a, secondary=0c, subordinate=0c, sec-latency=32
	I/O behind bridge: 0000a000-0000afff
	Memory behind bridge: df500000-df6fffff
	Secondary status: 66MHz+ FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [44] Express (v1) PCI/PCI-X Bridge, MSI 00
		DevCap:	MaxPayload 256 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
			ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
		DevCtl:	Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- BrConfRtry-
			MaxPayload 256 bytes, MaxReadReq 512 bytes
		DevSta:	CorrErr- UncorrErr+ FatalErr- UnsuppReq+ AuxPwr- TransPend-
		LnkCap:	Port #0, Speed 2.5GT/s, Width x8, ASPM L0s, Latency L0 unlimited, L1 unlimited
			ClockPM- Surprise- LLActRep- BwNot-
		LnkCtl:	ASPM Disabled; Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x4, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-
	Capabilities: [5c] MSI: Enable- Count=1/1 Maskable- 64bit+
		Address: 0000000000000000  Data: 0000
	Capabilities: [6c] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [d8] PCI-X bridge device
		Secondary Status: 64bit+ 133MHz+ SCD- USC- SCO- SRD- Freq=conv
		Status: Dev=0a:00.2 64bit- 133MHz- SCD- USC- SCO- SRD-
		Upstream: Capacity=65535 CommitmentLimit=65535
		Downstream: Capacity=65535 CommitmentLimit=65535
	Capabilities: [100 v1] Advanced Error Reporting
		UESta:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol-
		UEMsk:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
		UESvrt:	DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
		CESta:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
		CEMsk:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
		AERCap:	First Error Pointer: 14, GenCap- CGenEn- ChkCap- ChkEn-
	Capabilities: [300 v1] Power Budgeting <?>
	Kernel modules: shpchp