Created attachment 5390 [details]
My xorg.conf

Created attachment 5391 [details]
My kernel .config

Created attachment 5392 [details]
dmesg output

Created attachment 5393 [details]
Output of lspci -vvv

Created attachment 5394 [details]
Xorg.0.log

I should add that I'm comfortable with doing CVS checkouts and trying a newer 
X.org or radeon driver that way, and I'm also happy to try kernel patches 
(although I've never used git, so I'd prefer plain patches).

could you try it with 2.6.17-rc2 please and tell me if it still happens? we
don't support -mm kernels usually too much churn to follow

Created attachment 5397 [details]
2.6.17-rc2 dmesg

I'm no longer getting interrupts at all with 2.6.17-rc2; the only difference
with the previous setup is that I've done a VT switch between starting X, and
attempting to use OpenGL.

$ cat /proc/interrupts
	   CPU0
  0:	 170736    IO-APIC-edge  timer
  1:	    272    IO-APIC-edge  i8042
  7:	      0    IO-APIC-edge  parport0
  8:	      2    IO-APIC-edge  rtc
  9:	      0   IO-APIC-level  acpi
 10:	      0    IO-APIC-edge  i2c-pca-isa
 14:	    904    IO-APIC-edge  ide0
 15:	    881    IO-APIC-edge  ide1
 16:	    737   IO-APIC-level  ohci_hcd:usb4, radeon@pci:0000:01:00.0
 17:	    481   IO-APIC-level  eth0
 18:	  13304   IO-APIC-level  ide2, ide3, ohci_hcd:usb5, EMU10K1
 20:	      7   IO-APIC-level  aic7xxx, ohci_hcd:usb3
 21:	     12   IO-APIC-level  ohci1394, ehci_hcd:usb1, bttv0
 22:	     99   IO-APIC-level  ehci_hcd:usb2, uhci_hcd:usb6, uhci_hcd:usb7,
uhci_hcd:usb8
 23:	      0   IO-APIC-level  VIA8233
NMI:	      0
LOC:	 170591
ERR:	      0
MIS:	      0
$ cat /proc/interrupts
	   CPU0
  0:	 172389    IO-APIC-edge  timer
  1:	    282    IO-APIC-edge  i8042
  7:	      0    IO-APIC-edge  parport0
  8:	      2    IO-APIC-edge  rtc
  9:	      0   IO-APIC-level  acpi
 10:	      0    IO-APIC-edge  i2c-pca-isa
 14:	    922    IO-APIC-edge  ide0
 15:	    881    IO-APIC-edge  ide1
 16:	    737   IO-APIC-level  ohci_hcd:usb4, radeon@pci:0000:01:00.0
 17:	    481   IO-APIC-level  eth0
 18:	  13352   IO-APIC-level  ide2, ide3, ohci_hcd:usb5, EMU10K1
 20:	      7   IO-APIC-level  aic7xxx, ohci_hcd:usb3
 21:	     12   IO-APIC-level  ohci1394, ehci_hcd:usb1, bttv0
 22:	     99   IO-APIC-level  ehci_hcd:usb2, uhci_hcd:usb6, uhci_hcd:usb7,
uhci_hcd:usb8
 23:	      0   IO-APIC-level  VIA8233
NMI:	      0
LOC:	 172244
ERR:	      0
MIS:	      0
$ glob2
libGL warning: 3D driver claims to not support visual 0x4b
do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly.
Try running with LIBGL_THROTTLE_REFRESH and LIBL_SYNC_REFRESH unset.
$ cat /proc/interrupts
	   CPU0
  0:	 221169    IO-APIC-edge  timer
  1:	    318    IO-APIC-edge  i8042
  7:	      0    IO-APIC-edge  parport0
  8:	      2    IO-APIC-edge  rtc
  9:	      0   IO-APIC-level  acpi
 10:	      0    IO-APIC-edge  i2c-pca-isa
 14:	   1354    IO-APIC-edge  ide0
 15:	   1313    IO-APIC-edge  ide1
 16:	    737   IO-APIC-level  ohci_hcd:usb4, radeon@pci:0000:01:00.0
 17:	    722   IO-APIC-level  eth0
 18:	  16845   IO-APIC-level  ide2, ide3, ohci_hcd:usb5, EMU10K1
 20:	      7   IO-APIC-level  aic7xxx, ohci_hcd:usb3
 21:	     12   IO-APIC-level  ohci1394, ehci_hcd:usb1, bttv0
 22:	    162   IO-APIC-level  ehci_hcd:usb2, uhci_hcd:usb6, uhci_hcd:usb7,
uhci_hcd:usb8
 23:	      0   IO-APIC-level  VIA8233
NMI:	      0
LOC:	 220962
ERR:	      0
MIS:	      0
$ cat /proc/interrupts
	   CPU0
  0:	 223585    IO-APIC-edge  timer
  1:	    326    IO-APIC-edge  i8042
  7:	      0    IO-APIC-edge  parport0
  8:	      2    IO-APIC-edge  rtc
  9:	      0   IO-APIC-level  acpi
 10:	      0    IO-APIC-edge  i2c-pca-isa
 14:	   1372    IO-APIC-edge  ide0
 15:	   1331    IO-APIC-edge  ide1
 16:	    737   IO-APIC-level  ohci_hcd:usb4, radeon@pci:0000:01:00.0
 17:	    724   IO-APIC-level  eth0
 18:	  17127   IO-APIC-level  ide2, ide3, ohci_hcd:usb5, EMU10K1
 20:	      7   IO-APIC-level  aic7xxx, ohci_hcd:usb3
 21:	     12   IO-APIC-level  ohci1394, ehci_hcd:usb1, bttv0
 22:	    162   IO-APIC-level  ehci_hcd:usb2, uhci_hcd:usb6, uhci_hcd:usb7,
uhci_hcd:usb8
 23:	      0   IO-APIC-level  VIA8233
NMI:	      0
LOC:	 223376
ERR:	      0
MIS:	      0

(In reply to comment #8)
> 
> I'm no longer getting interrupts at all with 2.6.17-rc2; the only difference
> with the previous setup is that I've done a VT switch between starting X, and
> attempting to use OpenGL.

Do the interrupts stop when you switch VTs?

Please use grep radeon /proc/interrupts to avoid cluttering the comments.

(In reply to comment #8)
> Created an attachment (id=5397) [edit]
> 2.6.17-rc2 dmesg
> 
> I'm no longer getting interrupts at all with 2.6.17-rc2; the only difference
> with the previous setup is that I've done a VT switch between starting X, and
> attempting to use OpenGL.
>

can you try not switching VT???

Dave.

I think it was Ben's memmap changes...cc'ing him.

commentening out the OUTREG of GEN_INT_CNTL in the restore common registers
seems to fix the problem for me ... 

Simon can you test the same thing? around line 6346 or so..

(In reply to comment #12)

What if you add

    save->gen_int_cntl       = INREG(RADEON_GEN_INT_CNTL);

to RADEONInitCommonRegisters() instead?

(In reply to comment #13)

As discussed on IRC, that may help for the initial problem, but not for the VT
switching.

The question is why the code in RADEONDRIIrqInit() that initializes
info->ModeReg.gen_int_cntl no longer works; looking at RADEONRestoreMode(), it
always calls RADEONRestoreCommonRegisters() with &restore0 instead of restore,
is that intended?

No, I think it's a bug, should be restore in both cases

Created attachment 5400 [details] [review]
Patch based on Ben's comment #15 that fixes things for me

Sorry for the excess verbosity; I have a mortal terror of missing out something
important to you. Switching VTs was indeed what stopped the interrupts (not the
change of kernel).

Based on comment #14 and comment #15, I made the change in the attached patch.
This has fixed things for me.

Thank you all for your help so far (and the hard work you've done in the past
to make X.org and XFree86 as good as they are today); if my patch is incorrect,
please let me know, as I'm happy to try further changes.

I've applied this patch to HEAD, I'll apply to the stable ATI driver along with
another fix I have for PCIE suspend.

I think the first occurence shouldn't have been changed, as CommonRegisters
should always operate on the primary screen's data, shouldn't it? Changing all
the code involved in this issue to use pRADEONEnt->pPrimaryScrn might help make
things a little less hairy...

InitCommonRegisters() is called for both in RADEONInit and should set the same
values in both, thus I don't see a problem there. Or did I miss something ?
The only value with a meaning in there is BUS_CNTL wich is copied from
info->BusCntl and that is set for both heads.

(In reply to comment #19)
> The only value with a meaning in there is BUS_CNTL [...]

If that was true, this bug wouldn't have occurred... info->ModeReg.gen_int_cntl
can only get initialized on the primary screen, because the DRI can only be
enabled there currently.

Not sure what you mean here ... DRI isn't involved in dual entity setup... with
that fix, things appear to work fine. Do you see any reason what we do now is
wrong ? In the long run, if we ever have DRI enabled for dual entity, we'll have
to change things but I hope we'll get rid of the 2 register images things way
before that anyway.