|
Description
André Oliva
2011-05-27 18:08:05 UTC
Looks like the radeon kernel module is not loaded before starting X. The kernel modules must be loaded before starting X. Created attachment 47257 [details] [review] Xorg.0.log This is a fresh Xorg.0.log if you want to check... In this case KMS is properly initialized. Is 3D not working? That's right, the 3D acceleration is not working in that case (glxgears results in a black window). But when it does work, the Xorg.0.log looks the same (I'm not sure if something changes). Does glxgears work if you disable vsync? vblank_mode=0 glxgears Can you also attach the output of glxinfo? I'm the person experiencing problems on Fedora 15 - I think it's related to this problem. Only if I include NoModeSet in the kernel parameters will GNOME3 start. 90% of the time only the background appears (no panel, no activities) and then it hangs. Very occassionally will Gnome4 start, but it soon hangs. KDE4 will start OK without NoModeSet, this is where the following attachments are from. Xorg.0.log-KDE4 lspci-vv.txt lsmod.txt glxgears.txt glxinfo.txt Note that under KDE4: "glxgears" just gives a black window, without any gears! "vblank_mode=0 glxgears" gives the correct output with approx 62-80fps. ============== p.s. I started to have problems with X hanging completely (in KDE4 or GNOME2) on Fedora 14. X completely locks up, The display no longer updates, but does not become corrupted, but all inputs are blocked. Only the cursor moves. The laptop fan comes on 100% and I can only do reboot via the power button to get things moving again. I am still experiencing these problems with Fedora 15 - setting NoModeSet does not stop this problem occuring. Created attachment 47355 [details]
glxgears run under KDE (NoModeSet is NOT in kernel params)
Created attachment 47356 [details]
glxinfo run under KDE (NoModeSet is NOT in kernel params)
Created attachment 47357 [details]
lspci -vv
Created attachment 47358 [details] [review] Xorg.0.log run under KDE (NoModeSet is NOT in kernel params) (In reply to comment #6) > "glxgears" just gives a black window, without any gears! > "vblank_mode=0 glxgears" gives the correct output with approx 62-80fps. It looks like interrupts aren't working on your system. If you run: cat /proc/interrupts while running X do you see the numbers increasing for the interrupt used by radeon? Running cat /proc/interrupts under X does NOT have any increasing numbers for radeon. Further info: This problem is intermittent. On my last reboot I started KDE4, and was able to run "vblank_mode=0 glxgears", "glxgears" and then boot into Gnome3 all successfully. Throughout this /proc/interrupts remained the same for the radeon line. See attached*-gnome3-hang.txt files. Created attachment 47380 [details]
/proc/interrupts when gnome3 hangs and after killing X and starting KDE4
Created attachment 47382 [details]
Xorg.0.log when gnome3 hangs (NoModeSet is NOT on kernel params)
Does booting with pci=nomsi on the kernel command line in grub help? (In reply to comment #15) > Does booting with pci=nomsi on the kernel command line in grub help? No this doesn't make any difference - I still get: 1. /proc/interrupts doesn't change for the radeon line. 2. "glxgears" gives a black window. "vblank_mode=0 glxgears" works OK. 3. GNOME3 hanging on startup. See attached Xorg.0.log-pci=nomsi.txt Created attachment 47402 [details]
Xorg.0.log with pci=nomsi no kernel params
"vblank_mode=0 glxgears" works also for me! I can use normal 3d acceleration with that method. Stellarium and Glxgears work well: fast, smooth, as expected. But "vblank_mode=0 compiz --replace" does not work (I get a blank screen with the mouse pointer). (In reply to comment #18) > "vblank_mode=0 glxgears" works also for me! I can use normal 3d acceleration > with that method. Stellarium and Glxgears work well: fast, smooth, as expected. > But "vblank_mode=0 compiz --replace" does not work (I get a blank screen with > the mouse pointer). compiz is a script, so you'll probably have to set vblank_mode as a global env var export vblank_mode=0 compiz --replace Still, it's just a workaround. For some reason, interrupts are not working on your system. Ok, with the "export", compiz also starts. I have to say that Compiz is *very* slow... Almost as software rendering. I don't know why... As a workaround, the 3d acceleration works better if the program is started from Metacity (??). (In reply to comment #20) > Ok, with the "export", compiz also starts. I have to say that Compiz is *very* > slow... Almost as software rendering. I don't know why... As a workaround, the > 3d acceleration works better if the program is started from Metacity (??). If you aren't getting interrupts, fences won't work properly, so GL will be slow as well since every fence has to time out before it's retired. (In reply to comment #21) > (In reply to comment #20) > > Ok, with the "export", compiz also starts. I have to say that Compiz is *very* > > slow... Almost as software rendering. I don't know why... As a workaround, the > > 3d acceleration works better if the program is started from Metacity (??). > > If you aren't getting interrupts, fences won't work properly, so GL will be > slow as well since every fence has to time out before it's retired. I see... Thank you for your explanation... I use also the Visual module of python (vpython.org). It's a module for making 3d simulations, and it uses 3d acceleration. I'm getting an extrange error: ATTENTION: default value of option vblank_mode overridden by environment. ATTENTION: default value of option vblank_mode overridden by environment. r300 FP: Compiler Error: Ran out of hardware temporaries Using a dummy shader instead. when I use "export vblank_mode=0; ipython" and run > from visual import * > sphere() (I'm getting a black window, where the simulation is supposed to be) Everything works well in Ubuntu 10.04. Also, I can run simulations (very slowly) with software rendering (and since the simulations are for scientific purposes, the speed of the simulation is highly important). In another computer with a newer ATI graphics card, the problem is not present. I would like to know if I get this error because of this bug or this is another issue related with vpython... (In reply to comment #23) > I use also the Visual module of python (vpython.org). It's a module for making > 3d simulations, and it uses 3d acceleration. I'm getting an extrange error: > > ATTENTION: default value of option vblank_mode overridden by environment. > ATTENTION: default value of option vblank_mode overridden by environment. > r300 FP: Compiler Error: > Ran out of hardware temporaries > Using a dummy shader instead. That is a different bug. Please file a different bug report for that. (In reply to comment #24) > (In reply to comment #23) > > I use also the Visual module of python (vpython.org). It's a module for making > > 3d simulations, and it uses 3d acceleration. I'm getting an extrange error: > > > > ATTENTION: default value of option vblank_mode overridden by environment. > > ATTENTION: default value of option vblank_mode overridden by environment. > > r300 FP: Compiler Error: > > Ran out of hardware temporaries > > Using a dummy shader instead. > > That is a different bug. Please file a different bug report for that. A bug report here or in vpython.org? (In reply to comment #25) > A bug report here or in vpython.org? Here against the r300 gallium driver. Alex, I have built the latest radeon driver from git master, and still get the problem of no interrupts in /proc/interrupts. (I do get interrupts on another PC using Radeon HD 4350, RV710.) Can you point me in the direction of where the interrupts might be turned on/off? Is it by the radeon driver, or elsewhere in the kernel? Thanks. (In reply to comment #27) > Alex, > I have built the latest radeon driver from git master, and still get the > problem of no interrupts in /proc/interrupts. (I do get interrupts on another > PC using Radeon HD 4350, RV710.) Can you point me in the direction of where the > interrupts might be turned on/off? Is it by the radeon driver, or elsewhere in > the kernel? Thanks. It could be a hardware or bios problem. The drm just registers an interrupt handler with the core interrupt code in the kernel and enables device specific interrupt sources. You don't seem to be getting any interrupts for the radeon chip so it seems like something is set wrong in the northbridge configuration which is usually handled by the bios. Does your system have a bios upgrade available? (In reply to comment #28) > .... Does your system have a bios upgrade available? I've just applied the latest BIOS for the HP Compaq 6715b laptop. I upgraded from F.07 (16/07/2007) to F.0E (25/11/2008) from here: http://h20000.www2.hp.com/bizsupport/TechSupport/SoftwareIndex.jsp?lang=en&cc=us&prodNameId=3356624&prodTypeId=321957&prodSeriesId=3368540&swLang=13&taskId=135&swEnvOID=1093 After doing this and a vanilla kernel boot (nomodeset not set), and the latest git radeon driver I get: (NOTE: this is a two core system) 0. GNOME3 hangs immediately on startup (so tried KDE4). 1. Whilst booting KDE4 can monitor /proc/interrupts in non-X console and see radeon interupts rising for both CPUs. 2. Can use X under KDE4 and notice radeon interrupts rising (when windows moved etc) 3. Then starting "glxgears" or "vblank_output=0 glxgears" under KDE4 gives a blank window and causes interrupts to no longer be registered in /proc/interrupts! At this point moving windows around becomes noticeably slower. (Sometimes this occurs without needing to run glxgears) 4. Killing X (Ctrl-Alt-Backspace) back to GDM and restarting KDE4 causes interrupts to start being counted again for radeon in /proc/interrupts. BUT interrupts only increase on CPU0. CPU1 does not increase past that counted in step 3. 5. Starting "glxgears" causes all radeon interrupts to stop being counted in /proc/interrupts. 6. Go to step 4 and repeat! I also got the following messages in syslog. Note radeon is on irq 19. Jun 4 00:33:54 f15 kernel: [ 900.986231] irq 19: nobody cared (try booting with the "irqpoll" option) Jun 4 00:33:54 f15 kernel: [ 900.986241] Pid: 3410, comm: knotify4 Not tainted 2.6.38.6-27.fc15.i686 #1 Jun 4 00:33:54 f15 kernel: [ 900.986245] Call Trace: Jun 4 00:33:54 f15 kernel: [ 900.986256] [<c07ceb2d>] ? printk+0x2d/0x2f Jun 4 00:33:54 f15 kernel: [ 900.986262] [<c07d00ff>] __report_bad_irq+0x3e/0x86 Jun 4 00:33:54 f15 kernel: [ 900.986269] [<c048820f>] note_interrupt+0xfa/0x153 Jun 4 00:33:54 f15 kernel: [ 900.986274] [<c0488b17>] handle_fasteoi_irq+0x88/0xa6 Jun 4 00:33:54 f15 kernel: [ 900.986279] [<c0488a8f>] ? handle_fasteoi_irq+0x0/0xa6 Jun 4 00:33:54 f15 kernel: [ 900.986282] <IRQ> [<c0404bbd>] ? do_IRQ+0x3c/0x92 Jun 4 00:33:54 f15 kernel: [ 900.986292] [<c0403770>] ? common_interrupt+0x30/0x38 Jun 4 00:33:54 f15 kernel: [ 900.986298] [<c04620fd>] ? arch_local_irq_restore+0x5/0xb Jun 4 00:33:54 f15 kernel: [ 900.986305] [<c07d62b3>] ? _raw_spin_unlock_irqrestore+0x13/0x15 Jun 4 00:33:54 f15 kernel: [ 900.986310] [<c0732fb2>] ? skb_dequeue+0x48/0x4f Jun 4 00:33:54 f15 kernel: [ 900.986316] [<c07aa2cf>] ? unix_stream_recvmsg+0x116/0x408 Jun 4 00:33:54 f15 kernel: [ 900.986323] [<c0592f7b>] ? selinux_socket_recvmsg+0x1f/0x22 Jun 4 00:33:54 f15 kernel: [ 900.986329] [<c072e303>] ? sock_aio_read+0xf6/0xfe Jun 4 00:33:54 f15 kernel: [ 900.986335] [<c043feb7>] ? irq_exit+0x4c/0x70 Jun 4 00:33:54 f15 kernel: [ 900.986342] [<c04e4352>] ? do_sync_read+0x96/0xcf Jun 4 00:33:54 f15 kernel: [ 900.986348] [<c04e4672>] ? rw_verify_area+0xd0/0xf3 Jun 4 00:33:54 f15 kernel: [ 900.986352] [<c042e4e2>] ? __might_sleep+0x29/0xe4 Jun 4 00:33:54 f15 kernel: [ 900.986357] [<c04e49e6>] ? vfs_read+0x94/0xd5 Jun 4 00:33:54 f15 kernel: [ 900.986362] [<c04e4a69>] ? sys_read+0x42/0x63 Jun 4 00:33:54 f15 kernel: [ 900.986367] [<c07d66b4>] ? syscall_call+0x7/0xb Jun 4 00:33:54 f15 kernel: [ 900.986370] handlers: Jun 4 00:33:54 f15 kernel: [ 900.986372] [<f7a15415>] (radeon_driver_irq_handler_kms+0x0/0x19 [radeon]) Jun 4 00:33:54 f15 kernel: [ 900.986440] Disabling IRQ #19 So I tried rebooting with "irqpoll" in the kernel options. KDE4 and GNOME3 (gnome-shell) both run. glxgears gives 50 FPS !! So, my guess is the kernel/drm/radeon is wedging on interrupt processing. (In reply to comment #29) > > So I tried rebooting with "irqpoll" in the kernel options. KDE4 and GNOME3 > (gnome-shell) both run. glxgears gives 50 FPS !! > > So, my guess is the kernel/drm/radeon is wedging on interrupt processing. Sounds like your board bios has screwed up the irq routing which is not something we can fix in the driver unfortunately. irqpoll [HW] When an interrupt is not handled search all handlers for it. Also check all handlers each timer interrupt. Intended to get systems with badly broken firmware running. Hardware 3D will work in proprietary legacy 3D driver in Debian Lenny. (In reply to comment #30) > (In reply to comment #29) > > > > So I tried rebooting with "irqpoll" in the kernel options. KDE4 and GNOME3 > > (gnome-shell) both run. glxgears gives 50 FPS !! > > > > So, my guess is the kernel/drm/radeon is wedging on interrupt processing. > > Sounds like your board bios has screwed up the irq routing which is not > something we can fix in the driver unfortunately. > > irqpoll [HW] > When an interrupt is not handled search all handlers > for it. Also check all handlers each timer > interrupt. Intended to get systems with badly broken > firmware running. But I have never made an upgrade of BIOS, and 3d acceleration worked in Ubuntu 10.04, but now it doesn't work. In fact, right now I can boot into 10.04 and 3d acceleration works. Isn't the driver responsible for that behavior? (In reply to comment #32) > > But I have never made an upgrade of BIOS, and 3d acceleration worked in Ubuntu > 10.04, but now it doesn't work. In fact, right now I can boot into 10.04 and 3d > acceleration works. Isn't the driver responsible for that behavior? Did 10.04 use KMS? The UMS code did not rely on irqs as much. (In reply to comment #30) > (In reply to comment #29) > > > So, my guess is the kernel/drm/radeon is wedging on interrupt processing. > > Sounds like your board bios has screwed up the irq routing which is not > something we can fix in the driver unfortunately. See comment #29, upon initial boot the radeon interrupts are firing when first booted, they then stop for 1 CPU when glxgears runs, and then stop totally after X is killed restarted and glxgears re-runs. What is glxgears doing that affects the routing IRQs in the BIOS??? (In reply to comment #33) > > Did 10.04 use KMS? The UMS code did not rely on irqs as much. Yes, 10.04 uses KMS by default. (In reply to comment #35) > (In reply to comment #33) > > > > Did 10.04 use KMS? The UMS code did not rely on irqs as much. > > Yes, 10.04 uses KMS by default. Bisect the kernel and see what commit broke it. Does: Option "EnablePageFlip" "False" in the device section of your xorg.conf help? (In reply to comment #37) > Does: > Option "EnablePageFlip" "False" > in the device section of your xorg.conf help? This thread seems to indicate the cause of stopping interrupts is the dodgy BIOS and ACPI stuff: http://www.gossamer-threads.com/lists/linux/kernel/981060 I'm currently investigating with Fedora 9 & Fedora 10 since *may* be where the problem was introduced. Adding "noapic" to grub (GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub in ubuntu) fix this problem for me. also it fix some skype sound problems.
cat /proc/interrupts
CPU0
0: 154291 XT-PIC-XT-PIC timer
1: 2902 XT-PIC-XT-PIC i8042
2: 0 XT-PIC-XT-PIC cascade
7: 569 XT-PIC-XT-PIC
8: 0 XT-PIC-XT-PIC rtc0
9: 2353 XT-PIC-XT-PIC acpi
10: 350 XT-PIC-XT-PIC ohci_hcd:usb2, hda_intel
11: 97805 XT-PIC-XT-PIC ehci_hcd:usb1, ohci_hcd:usb3, ohci_hcd:usb4, ohci_hcd:usb5, ohci_hcd:usb6, ahci, eth1, radeon
12: 269533 XT-PIC-XT-PIC i8042
14: 0 XT-PIC-XT-PIC pata_atiixp
15: 0 XT-PIC-XT-PIC pata_atiixp
42: 42003 PCI-MSI-edge sky2@pci:0000:02:00.0
NMI: 0 Non-maskable interrupts
LOC: 198285 Local timer interrupts
SPU: 0 Spurious interrupts
PMI: 0 Performance monitoring interrupts
IWI: 0 IRQ work interrupts
RES: 0 Rescheduling interrupts
CAL: 0 Function call interrupts
TLB: 0 TLB shootdowns
TRM: 0 Thermal event interrupts
THR: 0 Threshold APIC interrupts
MCE: 0 Machine check exceptions
MCP: 4 Machine check polls
ERR: 569
MIS: 0
sry for poor eng :)
With that line in the Grub, I'm able to start Unity, but it's terribly slow.
glxgears:
55 frames in 5.0 seconds = 10.959 FPS
vblank_mode=0 glxgears:
1302 frames in 5.0 seconds = 260.377 FPS
/proc/interrupts
CPU0 CPU1
0: 229673 42359 XT-PIC-XT-PIC timer
1: 1857 275 XT-PIC-XT-PIC i8042
2: 0 0 XT-PIC-XT-PIC cascade
3: 14 6 XT-PIC-XT-PIC firewire_ohci
5: 24087 9605 XT-PIC-XT-PIC ohci_hcd:usb3, ohci_hcd:usb5, eth0, radeon
7: 83593 365590 XT-PIC-XT-PIC ehci_hcd:usb1, mmc0, r852
8: 0 0 XT-PIC-XT-PIC rtc0
9: 2 0 XT-PIC-XT-PIC acpi, ohci_hcd:usb4, ohci_hcd:usb6
10: 18453 4682 XT-PIC-XT-PIC ahci
11: 200 76 XT-PIC-XT-PIC ohci_hcd:usb2, hda_intel
12: 88865 24737 XT-PIC-XT-PIC i8042
14: 2610 1842 XT-PIC-XT-PIC pata_atiixp
15: 0 0 XT-PIC-XT-PIC pata_atiixp
NMI: 0 0 Non-maskable interrupts
LOC: 56514 169570 Local timer interrupts
SPU: 0 0 Spurious interrupts
PMI: 0 0 Performance monitoring interrupts
IWI: 0 0 IRQ work interrupts
RES: 122753 131496 Rescheduling interrupts
CAL: 372 533 Function call interrupts
TLB: 2175 2723 TLB shootdowns
TRM: 0 0 Thermal event interrupts
THR: 0 0 Threshold APIC interrupts
MCE: 0 0 Machine check exceptions
MCP: 4 4 Machine check polls
ERR: 245628
MIS: 0
(In reply to comment #40) > With that line in the Grub, I'm able to start Unity, but it's terribly slow. > > glxgears: > 55 frames in 5.0 seconds = 10.959 FPS > > vblank_mode=0 glxgears: > 1302 frames in 5.0 seconds = 260.377 FPS Noapic is not working for me in amd64 (it switch to software rendering whith 100% CPU usage. In glxinfo it show harware rendering). It work in i386. (In reply to comment #41) > Noapic is not working for me in amd64 (it switch to software rendering whith > 100% CPU usage. In glxinfo it show harware rendering). Try running the app which ends up using software rendering with LIBGL_DEBUG=verbose to see where it's picking up the drivers from. (In reply to comment #42) > Try running the app which ends up using software rendering with > LIBGL_DEBUG=verbose to see where it's picking up the drivers from. LIBGL_DEBUG=verbose vblank_mode=0 glxgears libGL: OpenDriver: trying /usr/lib/dri/tls/r300_dri.so libGL: OpenDriver: trying /usr/lib/dri/r300_dri.so ATTENTION: default value of option vblank_mode overridden by environment. ATTENTION: default value of option vblank_mode overridden by environment. libGL: Can't open configuration file /etc/drirc: No such file or directory. libGL: Can't open configuration file /home/ubuntu/.drirc: No such file or directory. libGL: Can't open configuration file /etc/drirc: No such file or directory. libGL: Can't open configuration file /home/ubuntu/.drirc: No such file or directory. 1081 frames in 5.0 seconds = 216.093 FPS 1133 frames in 5.0 seconds = 226.586 FPS 1129 frames in 5.0 seconds = 225.717 FPS XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0" after 4127 requests (4127 known processed) with 0 events remaining. LIBGL_DEBUG=verbose glxinfo| fgrep render libGL: OpenDriver: trying /usr/lib/dri/tls/r300_dri.so libGL: OpenDriver: trying /usr/lib/dri/r300_dri.so libGL: Can't open configuration file /etc/drirc: No such file or directory. libGL: Can't open configuration file /home/ubuntu/.drirc: No such file or directory. libGL: Can't open configuration file /etc/drirc: No such file or directory. libGL: Can't open configuration file /home/ubuntu/.drirc: No such file or directory. direct rendering: Yes OpenGL renderer string: Gallium 0.4 on ATI RS690 GL_NV_blend_square, GL_NV_conditional_render, GL_NV_light_max_exponent, libGL: OpenDriver: trying /usr/lib/dri/tls/r300_dri.so libGL: OpenDriver: trying /usr/lib/dri/r300_dri.so libGL: Can't open configuration file /etc/drirc: No such file or directory. libGL: Can't open configuration file /home/ubuntu/.drirc: No such file or directory. In Ubuntu 11.04 i386:
LIBGL_DEBUG=verbose vblank_mode=0 glxgears
libGL: OpenDriver: trying /usr/lib/dri/tls/r300_dri.so
libGL: OpenDriver: trying /usr/lib/dri/r300_dri.so
ATTENTION: default value of option vblank_mode overridden by environment.
ATTENTION: default value of option vblank_mode overridden by environment.
libGL: Can't open configuration file /etc/drirc: No such file or directory.
libGL: Can't open configuration file /home/krmolot/.drirc: No such file or directory.
libGL: Can't open configuration file /etc/drirc: No such file or directory.
libGL: Can't open configuration file /home/krmolot/.drirc: No such file or directory.
3101 frames in 5.0 seconds = 620.159 FPS
3170 frames in 5.0 seconds = 633.798 FPS
3164 frames in 5.0 seconds = 632.756 FPS
XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0"
after 9864 requests (9864 known processed) with 0 events remaining.
(In reply to comment #43) > libGL: OpenDriver: trying /usr/lib/dri/r300_dri.so This isn't software rendering. The speed difference may be due to a different 3D driver (r300g vs classic) / version / build (e.g. r300g with/out LLVM support, check with 'strings /usr/lib/dri/r300_dri.so|grep LLVM_') / ... (In reply to comment #45) > > This isn't software rendering. The speed difference may be due to a different > 3D driver (r300g vs classic) / version / build (e.g. r300g with/out LLVM > support, check with 'strings /usr/lib/dri/r300_dri.so|grep LLVM_') / ... I'm using the same version of distributive: ubuntu-11.04-desktop-amd64.iso ubuntu-11.04-desktop-i386.iso "strings /usr/lib/dri/r300_dri.so|grep LLVM_" nothing is return. (In reply to comment #46) > "strings /usr/lib/dri/r300_dri.so|grep LLVM_" nothing is return. In neither case? How about ldd /usr/lib/dri/r300_dri.so|grep LLVM (In reply to comment #47) > (In reply to comment #46) > > "strings /usr/lib/dri/r300_dri.so|grep LLVM_" nothing is return. > > In neither case? Yes > How about > > ldd /usr/lib/dri/r300_dri.so|grep LLVM Nothing ldd /usr/lib/dri/r300_dri.so linux-vdso.so.1 => (0x00007fff225ff000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f06eaee1000) libdricore.so => /usr/lib/dri/libdricore.so (0x00007f06eaaac000) libglsl.so => /usr/lib/dri/libglsl.so (0x00007f06ea7a7000) libdrm.so.2 => /lib/x86_64-linux-gnu/libdrm.so.2 (0x00007f06ea59c000) libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f06ea372000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f06ea153000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f06e9f4f000) libdrm_radeon.so.1 => /lib/x86_64-linux-gnu/libdrm_radeon.so.1 (0x00007f06e9d48000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f06e9ac2000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f06e98ac000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f06e9518000) /lib64/ld-linux-x86-64.so.2 (0x00007f06eb7bc000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f06e930f000) ldd /usr/lib/dri/r300_dri.so linux-gate.so.1 => (0x00387000) libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0x00110000) libdricore.so => /usr/lib/dri/libdricore.so (0x00388000) libglsl.so => /usr/lib/dri/libglsl.so (0x001fb000) libdrm.so.2 => /lib/i386-linux-gnu/libdrm.so.2 (0x002eb000) libexpat.so.1 => /lib/i386-linux-gnu/libexpat.so.1 (0x002f5000) libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0x0076d000) libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0x0031f000) libdrm_radeon.so.1 => /lib/i386-linux-gnu/libdrm_radeon.so.1 (0x00704000) libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0x00323000) libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0x00349000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0x0097c000) /lib/ld-linux.so.2 (0x00616000) librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0x00365000) Notebook: emachines d620, video: x1250 Actually, I think the lack of LLVM support explains the difference: IIRC, without LLVM the Gallium software vertex processing code uses assembly optimizations on 32 bit but not on 64 bit. Current upstream r600g refuses to build without LLVM, so this should clear up on its own at some point. Maybe you can try current oneiric live CDs. (In reply to comment #49) > Actually, I think the lack of LLVM support explains the difference: IIRC, > without LLVM the Gallium software vertex processing code uses assembly > optimizations on 32 bit but not on 64 bit. Current upstream r600g refuses to > build without LLVM, so this should clear up on its own at some point. Maybe you > can try current oneiric live CDs. Yes, LLVM support is increased FPS in amd64 and drop it in i386. I confirm that Gnome 3 hangs in Fedora 15. I booted from a live USB. I could start Unity 3D, but someone could start Gnome 3? And how? Still occurs on Fedora 16 test day live CD ISO. https://fedoraproject.org/wiki/Test_Day:2011-09-07_Radeon http://adamwill.fedorapeople.org/graphics_test_week_20110905/graphics_test_week-20110905-i686.iso So it seems the bug got a bit sidetracked by that speed issue, but regardless of that, the underlying issue doesn't seem to have been addressed: both reporters seem to need the 'noapic' or 'irqpoll' workarounds to get things flying at all. Is anything happening to address the fundamental bug? (In reply to comment #53) > So it seems the bug got a bit sidetracked by that speed issue, but regardless > of that, the underlying issue doesn't seem to have been addressed: both > reporters seem to need the 'noapic' or 'irqpoll' workarounds to get things > flying at all. Is anything happening to address the fundamental bug? When I tried Fedora 15 from Live USB, I could *not* start Gnome 3 (--> bad 3d acceleration --> the same bug) [blank screen and the pinter]. I used uNetbootin to create the Live USB, and even if I tried to add "noapic" to the boot line, it didn't work. Also I tried killing the X server, running "export vblank_mode=0" and "export CLUTTER_VBLANK=none" and restarting X server and also didn't work. Of course, I didn't tried installing Fedora 15, and then retrying the workaround, but at least from Live USB I couldn't make it work. However, I noticed that when Gnome 3 loads and the freeze happens, and then I press ALT+F2, kill gnome-shell, and then ALT+F8, the Gnome-shell elements (top panel and dash) appear in the screen, but of course I can not use it because I killed the process. It's may be a clue. (In reply to comment #54) > However, I noticed that when Gnome 3 loads and the freeze happens, and then I > press ALT+F2, kill gnome-shell, and then ALT+F8, the Gnome-shell elements (top > panel and dash) appear in the screen, but of course I can not use it because I > killed the process. It's may be a clue. Interrupts aren't working on your system for some reason. That's the issue. The "freeze" is gnome shell waiting for an event that never comes because interrupts aren't working. (In reply to comment #55) > > Interrupts aren't working on your system for some reason. That's the issue. > The "freeze" is gnome shell waiting for an event that never comes because > interrupts aren't working. How can I help debug this issue?? I am willing to investigate into any areas that you think may be causing this - I may need some help, e.g. bisect instructions, knowing which versions to try, etc. p.s. Win7 works OK on the laptop, and does HW accelerated Aero mode. (In reply to comment #56) > > How can I help debug this issue?? I am willing to investigate into any areas > that you think may be causing this - I may need some help, e.g. bisect > instructions, knowing which versions to try, etc. > > p.s. Win7 works OK on the laptop, and does HW accelerated Aero mode. Presumably the system bios on your board is not setting up the northbridge correctly. You might see if there is a new system bios for your board. It would be interesting to find out if windows has working irqs on your board. We don't currently have a fallback path in the open source driver if irqs aren't working and for certain things it's nearly impossible without irqs. You might also try the noapic or irqpoll kernel options. Additionally, if KMS was working with an older kernel, it would be great if you could bisect. I don't think that is the Bios. I have 3 OS on 3 partitions: Windows XP, Ubuntu 10.04 LTS and Ubuntu 11.04. 3d acc works well on Windows and Ubuntu 10.04. It doesn't work in Ubuntu 11.04. El 09/09/2011 16:31, <bugzilla-daemon@freedesktop.org> escribió: https://bugs.freedesktop.org/show_bug.cgi?id=37679 --- Comment #57 from Alex Deucher <agd5f@yahoo.com> 2011-09-09 15:31:17 PDT --- (In reply to comment #56) > > How can I help debug this issue?? I am willing to investigate into any areas > that you think m... Presumably the system bios on your board is not setting up the northbridge correctly. You might see if there is a new system bios for your board. It would be interesting to find out if windows has working irqs on your board. We don't currently have a fallback path in the open source driver if irqs aren't working and for certain things it's nearly impossible without irqs. You might also try the noapic or irqpoll kernel options. Additionally, if KMS was working with an older kernel, it would be great if you could bisect. (In reply to comment #58) > I don't think that is the Bios. I have 3 OS on 3 partitions: Windows XP, > Ubuntu 10.04 LTS and Ubuntu 11.04. 3d acc works well on Windows and Ubuntu > 10.04. It doesn't work in Ubuntu 11.04. As I mentioned previously, it depends if 10.04 used KMS or UMS. UMS did not make as extensive use of interrupts as KMS does. If 10.04 used KMS, then please bisect the kernel to see what commit caused the problem. (In reply to comment #59) > (In reply to comment #58) > > I don't think that is the Bios. I have 3 OS on 3 partitions: Windows XP, > > Ubuntu 10.04 LTS and Ubuntu 11.04. 3d acc works well on Windows and Ubuntu > > 10.04. It doesn't work in Ubuntu 11.04. > > As I mentioned previously, it depends if 10.04 used KMS or UMS. UMS did not > make as extensive use of interrupts as KMS does. If 10.04 used KMS, then > please bisect the kernel to see what commit caused the problem. Based on here https://help.ubuntu.com/community/RadeonDriver and the release notes of Lucid, I guess that 10.04 used KMS, not UMS. I have 10.04 still installed in my laptop. Is there a way to check if KMS is been used? And if so, I'm completely unfamiliar with bisecting the kernel. Could you please give me more instructions about what does it mean and how to do it? Hi. I'm having this bug. I'm using Gentoo, not Ubuntu. If kms is in use, Xorg.0.log has the following line: [ 1776.086] (II) [KMS] Kernel modesetting enabled. Very good git bisect tutorial is found here: http://www.landley.net/writing/git-bisect-howto.html I may add some more comments after some investigation. With best regards. Older versions of radeon kms did not support vsynced 3D which relies on vblank interrupts in addition to sw interrupts. You can disable it by setting the env var vblank_mode=0. Hi. I noticed one peculiar thing: IRQ 19 (radeon's) is almost always frozen at 200001 times:
$ cat /proc/interrupts
CPU0
0: 409332 IO-APIC-edge timer
1: 448 IO-APIC-edge i8042
8: 0 IO-APIC-edge rtc0
9: 178 IO-APIC-fasteoi acpi
12: 73159 IO-APIC-edge i8042
16: 22757 IO-APIC-fasteoi ahci, hda_intel
17: 9173 IO-APIC-fasteoi ohci_hcd:usb3, ohci_hcd:usb4, ohci_hcd:usb5, ohci_hcd:usb6
19: 200001 IO-APIC-fasteoi radeon
23: 2 IO-APIC-fasteoi ehci_hcd:usb1, ohci_hcd:usb2
42: 30400 PCI-MSI-edge eth0
NMI: 0 Non-maskable interrupts
LOC: 173250 Local timer interrupts
SPU: 0 Spurious interrupts
PMI: 0 Performance monitoring interrupts
IWI: 0 IRQ work interrupts
ERR: 0
MIS: 0
And it seems when it reaches that number, dmesg "irq 19: nobody cared" appears, though not sure.
I've also seen the number 300001, only once during several rebooting. Except this time, all was 200001. Why step of 100000??
But Phil Cole said above that he has 2 cpus, and the threshold of the attachement[1] was 281.
[1]https://bugs.freedesktop.org/attachment.cgi?id=47380
"noapic" boot option doesn't help. I tried it only once, and it showed:
11: 200002 XT-PIC-XT-PIC ehci_hcd:usb1, ohci_hcd:usb2, radeon
(Without noapic, the ERR interrupt is always 0, but with noapic, ERR increases.)
Let me add one more issue, module vs built-in: when I compile the driver "radeon" as a module, kms starts. But if it's built into the kernel, it freezes at the boot time, showing black screen. Keyboard is ignored, and HDD access LED doesn't turn on. I've checked it's the only difference. (In menuconfig, CONFIG_DRM_RADEON being "m" or "y". In the .config file this option will automatically pull in several other flags.)
I tried boot options below, but none worked: "irqpoll", "ioapicreroute", "nohz=off processor.max_cstate=2". (In the past, the last one was necessary for my HP Compaq 6715s, but recent kernels do't require it.)
I found several other "200001" IRQ issues, completely independent of radeon: * Wireless driver, with a successful fix. (Too bad kernel.org is closed now, but if you have kernel git repo on your local HDD, the relevant commit is shown.) https://bugzilla.redhat.com/show_bug.cgi?id=537943 All others shown below don't contain fix. * nvidia http://www.linuxquestions.org/questions/slackware-14/disabling-irq-16-a-879964/ * Ata? http://www.amailbox.org/mailarchive/linux-kernel/2007/8/26/164946/thread#mid-164946 * ether card https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/126369 * ehci_usb http://answers.softpicks.net/answers/topic/USB-Serial-device-disconnect-causes-IRQ-disable-1978236-1.htm You can also find 100001 and 300001 cases. Is there any nasty kernel or acpi spec bug? Thanks in advance. (In reply to comment #64) > I found several other "200001" IRQ issues, completely independent of radeon: That's a red herring I'm afraid: If you look at the code in kernel/irq/spurious.c, this message is generated after 200000 unhandled interrupts, and then the IRQ is disabled. The 100001 and 300001 values probably have the same explanation with different kernel versions or patched kernels. Unfortunately, this doesn't say anything about what caused the interrupts not to be handled properly in each case. Hi. With kernel-3.0.4, the problem seems to be gone for me. And thank you, Michel Dänzer, for your comment. (In reply to comment #66) > Hi. With kernel-3.0.4, the problem seems to be gone for me. Any chance you could bisect and track down what commit fixed it? Sorry, I was wrong. No difference between 2.6.39.2 and 3.0.4. OTOH, I tried 2.6.32.36, and kms worked, although "EnablePageFlip" "off" was necessary; without it, the screen is black, showing nothing. vblank_mode=0 doesn't affect fps of glxgears. Below I've attached dmesg of 2.6.32.36 (good) and 3.0.4 (bad). You'll have noticed both have a line radeon 0000:01:05.0: PCI INT B -> GSI 19 (level, low) -> IRQ 19 but in the good, there's also a line radeon 0000:01:05.0: irq 26 for MSI/MSI-X and /proc/interrupts says only irq # 26 is used in the good. (In bad, it's 19.) Created attachment 52414 [details] [review] dmesg of 2.6.32.36 Created attachment 52415 [details]
dmesg of 3.0.4
Created attachment 52416 [details]
dmesg of 2.6.32.36 (radeon part only)
Created attachment 52417 [details]
dmesg of 3.0.4 (radeon part only)
Created attachment 52418 [details] [review] cat /proc/interrupts from 2.6.32 Created attachment 52419 [details]
glxinfo from 2.6.32
Does 2.6.32.36 work correctly if you boot with pci=nomsi on the kernel command line in grub? How about 3.0.4? 2.6.32 with pci=nomsi: It's "bad". irq # 19 count is frozen. glxgears draws, but the FPS is reduced 70, while without "nomsi" it was 240. Xorg log is the same. dmesg is same except "irq for nomsi". I haven't reported this before, but when it's "bad", redraw of my x terminal, urxvt, is snail-slow, and I saw it with "nomsi", too. (I don't need opengl, so this is the biggest trouble for me.) 3.0.4: no much difference with pci=nomsi, it's anyway bad. (In 2.6.39 and 3.0.4, in most cases glxgears is not drawn, showing only black box. But in 2.6.32, every time I tried gears were drawn even with nomsi, but the test is not thorough.) Most of dmesg differences are trivial, but I quote one hunk here FYI: ------------------------------------------------------------------------ --- dmesg-3.0.4 2011-10-18 17:02:54.743566206 +0900 +++ dmesg-3.0.4-nomsi 2011-10-18 16:57:38.871537255 +0900 @@ -268,9 +266,7 @@ ACPI: PCI Interrupt Routing Table [\_SB_.C08B._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.C08B.C08C._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.C08B.C0FC._PRT] - pci0000:00: Requesting ACPI _OSC control (0x1d) - pci0000:00: ACPI _OSC request failed (AE_NOT_FOUND), returned control mask: 0x1d -ACPI _OSC control for PCIe not granted, disabling ASPM + pci0000:00: Unable to request _OSC control (_OSC support mask: 0x0f) ACPI: PCI Interrupt Link [C145] (IRQs 10 11) *0, disabled. ACPI: PCI Interrupt Link [C146] (IRQs 10 11) *0, disabled. ACPI: PCI Interrupt Link [C147] (IRQs 10 11) *0, disabled. ------------------------------------------------------------------------ Created attachment 52475 [details] [review] enable msi Looks like only MSIs work on your system. Does the attached patch fix newer kernels? I patched 3.0.4. It's a must-have, but not simple. It partially fixes. "black box glxgears" nor "irq count freeze" never happen. "pageflip" on-or-off doesn't matter. Xorg.0.log isn't affected. dmesg is the same with unpatched 3.0.4, except MSI: ------------------------------------------------------------------------ @@ -8,12 +8,10 @@ radeon 0000:01:05.0: GTT: 512M 0x0000000060000000 - 0x000000007FFFFFFF [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [drm] Driver supports precise vblank timestamp query. +radeon 0000:01:05.0: irq 42 for MSI/MSI-X +radeon 0000:01:05.0: radeon: using MSI. [drm] radeon: irq initialized. [drm] Detected VRAM RAM=128M, BAR=128M [drm] RAM width 128bits DDR ------------------------------------------------------------------------ Glxgears fps is always only 60 (which is 240 with good kms), regardless of "pageflip" or "vblank_mode=0". But that's not all; The first time I booted the patched kenel, right after udev loaded the module, (I was on VT1) it seemed ok - the screen went high resolution, the previous screen contents were correctly shown, and the cursor continued blinking - but it halted there. Keypresses are echoed to the screen, but Ctrl+Alt+Del didn't work. It happened only once, and after that, all 5 boots were successful. It also seems to have a nice side effect; when kms is enabled in the bad kernel, I often experinced a problem in s2ram, but with your patch s2ram has succeeded in some 10 trials in row. So I think we're in the right direction. (The problem was that for most times suspend doesn't complete, or takes too long, after the screen turns black.) Since I don't need opengl, I'm quite satisfied with this patch. =P What are your pci device and subsystem ids? lspci -vnn Created attachment 52722 [details]
lspci -vnn of katabami's PC
In short, same as Phil Cole's:
01:05.0 VGA compatible controller [0300]: ATI Technologies Inc RS690M [Radeon X1200 Series] [1002:791f] (prog-if 00 [VGA controller])
Subsystem: Hewlett-Packard Company Device [103c:30c2]
Thank you very much for taking care.
With kind regards.
Created attachment 52758 [details] [review] fix 1/2 Patch 1/2 Created attachment 52759 [details] [review] fix 2/2 patch 2/2 Can you try these two patches? It looks like a platform/bios bug rather than a driver bug since legacy irqs should always work AFAIK, but I'm not sure where the problem lies. This patch just adds a quirk to always enable MSIs on your system. Thanks, it surely works, again for 3.0.4. I forgot to report that built-in driver (= not as modules) doesn't work with 2.6.32, nor with 3.0.4 + your patch. If someone wants to bisect: it'll take some 18-20 times of kernel compilation, I guess. I've done kernel bisect twice, but both were straightforward. As usual, you can ask helps at forums. You can also ask me by email for basic procedures. (Login here to see my email address.) (In reply to comment #83) > Thanks, it surely works, again for 3.0.4. > > I forgot to report that built-in driver (= not as modules) doesn't work with > 2.6.32, nor with 3.0.4 + your patch. Did you include the required firmware in your kernel image? Can anyone else on this report check if attachment 52475 [details] [review] helps you as well? (In reply to comment #84) Thanks again. Built-in works just like module by adding the firmware, radeon/RS690_cp.bin, for each version. # Oh my ass, I've never heard of that magic. ;) Created attachment 52873 [details]
Xorg.0.log from 2.6.32
Some notes on glxgears FPS: 2.6.32 reports more resolution modes, and fps varies among modes. In 3.0.4 + patch, fps is about 60 in all modes.
Let me attach Xorg server's logs. This file is from 2.6.32.
Created attachment 52874 [details]
Xorg.0.log from 3.0.4
Xorg.0.log from 3.0.4
Just completed a fresh install of Fedora 15 x86 and rebuilt the stock Fedora kernel (2.6.40.6) keeping the exact same configuration apart from the addition of the two patches from Comment 81 and Comment 82 and it fixes the problem as far as I can see. Boots fine without kernel param "nomodeset". glxgears gives approx 57-60fps. Gnome3 much more responsive. Thanks Alex for your persistence with this bug. Thanks katabami too. I, the original reporter of this bug, want to thank also Alex and all the people involved for all the effort and the time spent in this bug. These weeks I simply didn't have enough time to try to bisect the Kernel and to try the patches (I'm unfamiliar with that and it's something that I have to learn how to do it). Sorry for that. But really, thank you very much! 2011/10/29 <bugzilla-daemon@freedesktop.org> > https://bugs.freedesktop.org/show_bug.cgi?id=37679 > > --- Comment #89 from Phil Cole <filcole@gmail.com> 2011-10-29 12:09:28 UTC > --- > Just completed a fresh install of Fedora 15 x86 and rebuilt the stock > Fedora > kernel (2.6.40.6) keeping the exact same configuration apart from the > addition > of the two patches from Comment 81 and Comment 82 and it fixes the problem > as > far as I can see. > > Boots fine without kernel param "nomodeset". > glxgears gives approx 57-60fps. > Gnome3 much more responsive. > > Thanks Alex for your persistence with this bug. Thanks katabami too. > > -- > Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You reported the bug. > I hope it's ok for me to say, but Alex Deucher has kindly commited the patches 10 days ago, and the fix seems available in 3.0.9 and 3.1.1. Let me express my gratitude to Alex, and all involved people. If André and Phil didn't report it, I was clueless. :) With best regards. A patch referencing this bug report has been merged in Linux v3.2-rc1: commit b362105f7f5223fa4d2e03ceeea0e51da754ccc6 Author: Alex Deucher <alexander.deucher@amd.com> Date: Tue Oct 25 15:11:08 2011 -0400 drm/radeon/kms: Add MSI quirk for HP RS690 A patch referencing this bug report has been merged in Linux v3.2-rc1: commit a18cee15ed4c8b6a35f96b7b26a46bac32e04bd9 Author: Alex Deucher <alexander.deucher@amd.com> Date: Tue Nov 1 14:20:30 2011 -0400 drm/radeon/kms: add MSI module parameter I have the same problem with my DELL Inspiron 1521 laptop and the patch doesn't fix the problem cause my video card reports another subsystem_device: cat /sys/bus/pci/devices/0000:01:05.0/subsystem_device 0x01fc So I just changed subsystem_device in the patch and now it works fine. Created attachment 55596 [details] [review] Add another DELL quirk I've sent this additional patch upstream. A patch referencing this bug report has been merged in Linux v3.2-rc1: commit 01e718ec194e30b3e8eb3858c742c13649757efc Author: Alex Deucher <alexander.deucher@amd.com> Date: Tue Nov 1 14:14:18 2011 -0400 drm/radeon/kms: Add MSI quirk for Dell RS690 A patch referencing this bug report has been merged in Linux v3.3-rc2: commit 44517c44496062180a6376cc704b33129441ce60 Author: Alex Deucher <alexander.deucher@amd.com> Date: Sun Jan 15 08:51:12 2012 -0500 drm/radeon/kms: Add an MSI quirk for Dell RS690 I have this problem with my Radeon 9600XT I had this problem on an install of Ubuntu Natty and so far the only thing I can confirm with repeatability is that 3D works when the S-video output is 'detected' and doesn't work when it isn't. If I boot into Windows XP (dual boot) and enable the TV-Out on S-Video (even without a TV plugged in) and then reboot into Ubuntu Natty I get a 2nd screen on S-video showing up in the displays control panel and I get 3D acceleration to work. I installed a test copy of Ubuntu Oneiric onto a USB HDD and so far haven't had issues with 3D. HOWEVER: I recently did an upgrade to Oneiric inside the currently-installed Natty and the 3D issue is still present, so perhaps that is from something still there from the old installation? Again, enabling S-video in Windows and rebooting is the only sure way to make 3D work. Occasionally it will boot up and detect the S-video and enable 3D by itself but this is not often. (In reply to comment #98) > I have this problem with my Radeon 9600XT No, you probably don't. This problem is (was? Looks like this report can be resolved now?) specific to RS690 chipsets. Please file your own report with the usual information attached, i.e. at least Xorg.0.log and the output of dmesg and glxinfo from when the problem occurs (and maybe also from when it doesn't). Please also describe in more detail what exactly "3D acceleration doesn't work" means in your case. Hello. Plz tell me, where i can find detailed information about my Radeon x1250. Something like this: if ((rdev->pdev->device == 0x791f) && (rdev->pdev->subsystem_vendor == 0x1028) && (rdev->pdev->subsystem_device == 0x01fc)) Simple hack "return true;" work. Notebook: Emachines D620 Thanks. 00:00.0 Host bridge [0600]: Advanced Micro Devices [AMD] nee ATI RS690 Host Bridge [1002:7910] Subsystem: Gateway 2000 Device [107b:0185] Flags: bus master, 66MHz, medium devsel, latency 64 Kernel modules: ati-agp 00:01.0 PCI bridge [0604]: Advanced Micro Devices [AMD] nee ATI RS690 PCI to PCI Bridge (Internal gfx) [1002:7912] (prog-if 00 [Normal decode]) Flags: bus master, 66MHz, medium devsel, latency 64 Bus: primary=00, secondary=01, subordinate=01, sec-latency=64 I/O behind bridge: 00009000-00009fff Memory behind bridge: f0000000-f01fffff Prefetchable memory behind bridge: 00000000d0000000-00000000dfffffff Capabilities: <access denied> Kernel modules: shpchp 00:04.0 PCI bridge [0604]: Advanced Micro Devices [AMD] nee ATI Device [1002:7914] (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=02, subordinate=04, sec-latency=0 I/O behind bridge: 0000a000-0000afff Memory behind bridge: f0200000-f02fffff Capabilities: <access denied> Kernel driver in use: pcieport Kernel modules: shpchp 00:05.0 PCI bridge [0604]: Advanced Micro Devices [AMD] nee ATI RS690 PCI to PCI Bridge (PCI Express Port 1) [1002:7915] (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=05, subordinate=07, sec-latency=0 Memory behind bridge: f0300000-f03fffff Capabilities: <access denied> Kernel driver in use: pcieport Kernel modules: shpchp 00:12.0 SATA controller [0106]: Advanced Micro Devices [AMD] nee ATI SB600 Non-Raid-5 SATA [1002:4380] (prog-if 01 [AHCI 1.0]) Subsystem: Gateway 2000 Device [107b:0185] Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 22 I/O ports at 8440 [size=8] I/O ports at 8434 [size=4] I/O ports at 8438 [size=8] I/O ports at 8430 [size=4] I/O ports at 8400 [size=16] Memory at f0609000 (32-bit, non-prefetchable) [size=1K] Capabilities: <access denied> Kernel driver in use: ahci 00:13.0 USB controller [0c03]: Advanced Micro Devices [AMD] nee ATI SB600 USB (OHCI0) [1002:4387] (prog-if 10 [OHCI]) Subsystem: Gateway 2000 Device [107b:0185] Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16 Memory at f0404000 (32-bit, non-prefetchable) [size=4K] Kernel driver in use: ohci_hcd 00:13.1 USB controller [0c03]: Advanced Micro Devices [AMD] nee ATI SB600 USB (OHCI1) [1002:4388] (prog-if 10 [OHCI]) Subsystem: Gateway 2000 Device [107b:0185] Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 17 Memory at f0405000 (32-bit, non-prefetchable) [size=4K] Kernel driver in use: ohci_hcd 00:13.2 USB controller [0c03]: Advanced Micro Devices [AMD] nee ATI SB600 USB (OHCI2) [1002:4389] (prog-if 10 [OHCI]) Subsystem: Gateway 2000 Device [107b:0185] Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 18 Memory at f0406000 (32-bit, non-prefetchable) [size=4K] Kernel driver in use: ohci_hcd 00:13.3 USB controller [0c03]: Advanced Micro Devices [AMD] nee ATI SB600 USB (OHCI3) [1002:438a] (prog-if 10 [OHCI]) Subsystem: Gateway 2000 Device [107b:0185] Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 17 Memory at f0407000 (32-bit, non-prefetchable) [size=4K] Kernel driver in use: ohci_hcd 00:13.4 USB controller [0c03]: Advanced Micro Devices [AMD] nee ATI SB600 USB (OHCI4) [1002:438b] (prog-if 10 [OHCI]) Subsystem: Gateway 2000 Device [107b:0185] Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 18 Memory at f0408000 (32-bit, non-prefetchable) [size=4K] Kernel driver in use: ohci_hcd 00:13.5 USB controller [0c03]: Advanced Micro Devices [AMD] nee ATI SB600 USB Controller (EHCI) [1002:4386] (prog-if 20 [EHCI]) Subsystem: Gateway 2000 Device [107b:0185] Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 19 Memory at f0609400 (32-bit, non-prefetchable) [size=256] Capabilities: <access denied> Kernel driver in use: ehci_hcd 00:14.0 SMBus [0c05]: Advanced Micro Devices [AMD] nee ATI SBx00 SMBus Controller [1002:4385] (rev 14) Subsystem: Gateway 2000 Device [107b:0185] Flags: 66MHz, medium devsel I/O ports at 8410 [size=16] Capabilities: <access denied> Kernel driver in use: piix4_smbus Kernel modules: sp5100_tco, i2c-piix4 00:14.1 IDE interface [0101]: Advanced Micro Devices [AMD] nee ATI SB600 IDE [1002:438c] (prog-if 8a [Master SecP PriP]) Subsystem: Gateway 2000 Device [107b:0185] Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16 I/O ports at 01f0 [size=8] I/O ports at 03f4 [size=1] I/O ports at 0170 [size=8] I/O ports at 0374 [size=1] I/O ports at 8420 [size=16] Kernel driver in use: pata_atiixp Kernel modules: pata_atiixp 00:14.2 Audio device [0403]: Advanced Micro Devices [AMD] nee ATI SBx00 Azalia (Intel HDA) [1002:4383] Subsystem: Gateway 2000 Device [107b:0185] Flags: bus master, slow devsel, latency 64, IRQ 16 Memory at f0400000 (64-bit, non-prefetchable) [size=16K] Capabilities: <access denied> Kernel driver in use: snd_hda_intel Kernel modules: snd-hda-intel 00:14.3 ISA bridge [0601]: Advanced Micro Devices [AMD] nee ATI SB600 PCI to LPC Bridge [1002:438d] Subsystem: Gateway 2000 Device [107b:0185] Flags: bus master, 66MHz, medium devsel, latency 0 00:14.4 PCI bridge [0604]: Advanced Micro Devices [AMD] nee ATI SBx00 PCI to PCI Bridge [1002:4384] (prog-if 01 [Subtractive decode]) Flags: bus master, 66MHz, medium devsel, latency 64 Bus: primary=00, secondary=0b, subordinate=0d, sec-latency=64 00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration [1022:1100] Flags: fast devsel Capabilities: <access denied> 00:18.1 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map [1022:1101] Flags: fast devsel 00:18.2 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller [1022:1102] Flags: fast devsel 00:18.3 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control [1022:1103] Flags: fast devsel Capabilities: <access denied> Kernel driver in use: k8temp Kernel modules: k8temp 01:05.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI RS690M [Radeon X1200 Series] [1002:791f] (prog-if 00 [VGA controller]) Subsystem: Gateway 2000 Device [107b:0185] Flags: bus master, fast devsel, latency 64, IRQ 43 Memory at d0000000 (64-bit, prefetchable) [size=256M] Memory at f0100000 (64-bit, non-prefetchable) [size=64K] I/O ports at 9400 [size=256] Memory at f0000000 (32-bit, non-prefetchable) [size=1M] Expansion ROM at <unassigned> [disabled] Capabilities: <access denied> Kernel driver in use: radeon Kernel modules: radeon 02:00.0 Ethernet controller [0200]: Marvell Technology Group Ltd. 88E8040 PCI-E Fast Ethernet Controller [11ab:4354] (rev 13) Subsystem: Gateway 2000 Device [107b:0185] Flags: bus master, fast devsel, latency 0, IRQ 42 Memory at f0200000 (64-bit, non-prefetchable) [size=16K] I/O ports at a400 [size=256] Capabilities: <access denied> Kernel driver in use: sky2 Kernel modules: sky2 05:00.0 Network controller [0280]: Broadcom Corporation BCM4312 802.11b/g LP-PHY [14e4:4315] (rev 01) Subsystem: Foxconn International, Inc. T77H030.00 Wireless Mini PCIe Card [105b:e003] Flags: bus master, fast devsel, latency 0, IRQ 17 Memory at f0300000 (64-bit, non-prefetchable) [size=16K] Capabilities: <access denied> Kernel driver in use: wl Kernel modules: wl cat /sys/bus/pci/devices/0000:01:05.0/subsystem_device 0x0185 Created attachment 67737 [details] [review] fix for gateway laptop This patch should fix your gateway laptop. Created attachment 67738 [details] [review] force MSIs for all RS690s For anyone with an RS690, try this patch and see if it helps. On my Acer Emachine e625 laptop, enabling MSI seems to be an improvement. `vblank_mode=0 glxgears` give me 690 FPS when I had 590 without MSI. However, the desktop experience (Unity 3D) feels the same with or without it. (In reply to comment #102) > Created attachment 67737 [details] [review] [review] > fix for gateway laptop > This patch should fix your gateway laptop. Yes, it's work. Can you send this patch in upstream? :) cat /proc/interrupts ... 43: 20852 PCI-MSI-edge radeon Thanks. (In reply to comment #105) > Yes, it's work. Can you send this patch in upstream? :) Yes, it's already queued for 3.7 and stable. I forgot this about my system: cat /sys/bus/pci/devices/0000:01:05.0/subsystem_device 0x0213 Let me know if you need something else. (In reply to comment #107) > I forgot this about my system: > cat /sys/bus/pci/devices/0000:01:05.0/subsystem_device > 0x0213 The patch in attachment 67738 [details] [review] should handle your card. Yes, this patch does enable MSI and so does solve most of my problems with this laptop. Though the patch does not apply as is (at least on the Ubuntu kernel). Fixed in 3.6.2 / 3.5.7 / 3.4.14 . A patch referencing this bug report has been merged in Linux v3.7-rc1: commit 3a6d59df80897cc87812b6826d70085905bed013 Author: Alex Deucher <alexander.deucher@amd.com> Date: Wed Sep 26 12:31:45 2012 -0400 drm/radeon: Add MSI quirk for gateway RS690 A patch referencing this bug report has been merged in Linux v3.7-rc1: commit fb6ca6d154cdcd53e7f27f8dbba513830372699b Author: Alex Deucher <alexander.deucher@amd.com> Date: Wed Sep 26 12:40:45 2012 -0400 drm/radeon: force MSIs on RS690 asics |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.