Re: 2.6.35-rc4 ppc crash when loading radeon modeset=1
On Die, 2010-07-13 at 19:05 +0200, jjDaNiMoTh wrote: > > So, I've now the acceleration. The main problem was radeon.agpmode, > setting it to -1 (and removing all files in xorg.conf.d related to > radeon) fixes all issue (also the freeze on glxgears). Now I have > ~1500 FPS, and I'm fine with it (before I got 100 FPS). > > I get the acceleration also with a non-KMS capable kernel, so I think > we got the point. I will add the option to modprobe.conf for archPPC. Note that e.g. on my PowerBook agpmode=1 works (mostly) stable, and if AGP works it performs significantly better than PCI. > I tried a program which use a lot opengl, the only thing I see is > ERROR: GL error 1282 > ERROR: Ignoring 1 openGL errors Something the app does causes Mesa to raise a GL_INVALID_OPERATION error. This may be a bug in the app or in Mesa. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 2.6.35-rc4 ppc crash when loading radeon modeset=1
2010/7/13 Michel Dänzer : [cut] > Are you looking at the right log file, not the one from the new X server > after the reboot? Yes, I looked to .old, when referring to Xorg.0.log. > Maybe you could post the full dmesg, Xorg.0.log and X server stderr > output (should be captured in the gdm/kdm log file) from trying with > modeset=1. > >> At this time, I think it isn't a kernel problem, am I right? > > With modeset=1 it most likely is a kernel (configuration) problem. So, I've now the acceleration. The main problem was radeon.agpmode, setting it to -1 (and removing all files in xorg.conf.d related to radeon) fixes all issue (also the freeze on glxgears). Now I have ~1500 FPS, and I'm fine with it (before I got 100 FPS). I get the acceleration also with a non-KMS capable kernel, so I think we got the point. I will add the option to modprobe.conf for archPPC. I tried a program which use a lot opengl, the only thing I see is ERROR: GL error 1282 ERROR: Ignoring 1 openGL errors but the topic-error is fixed. Thank you. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 2.6.35-rc4 ppc crash when loading radeon modeset=1
On Die, 2010-07-13 at 18:02 +0200, jjDaNiMoTh wrote: > 2010/7/13 Michel Dänzer : > > What does the log file contain with modeset=1? > > We have no message, after the X.org freeze. > > messages.log: > [...] > Jul 13 17:11:01 jim kernel: [drm] Num pipes: 1 > Jul 13 17:13:39 jim kernel: Using PowerMac machine description > > (we have rebooted) > > In Xorg.0.log there aren't information after the crash, only a right startup. Are you looking at the right log file, not the one from the new X server after the reboot? Maybe you could post the full dmesg, Xorg.0.log and X server stderr output (should be captured in the gdm/kdm log file) from trying with modeset=1. > At this time, I think it isn't a kernel problem, am I right? With modeset=1 it most likely is a kernel (configuration) problem. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 2.6.35-rc4 ppc crash when loading radeon modeset=1
2010/7/13 Michel Dänzer : [cut] > Could be a GPU lockup again, possibly due to still using AGP 4x with > modeset=0. [cut] > What does the log file contain with modeset=1? We have no message, after the X.org freeze. messages.log: [...] Jul 13 17:11:01 jim kernel: [drm] Num pipes: 1 Jul 13 17:13:39 jim kernel: Using PowerMac machine description (we have rebooted) In Xorg.0.log there aren't information after the crash, only a right startup. Maybe I could try to connect via ssh and see if there are some informations which aren't written to disk... At this time, I think it isn't a kernel problem, am I right? Also, we have the same problem (freeze in glxgears or other program using glx) both from normal user and from root. Thank you again ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 2.6.35-rc4 ppc crash when loading radeon modeset=1
On Die, 2010-07-13 at 16:51 +0200, jjDaNiMoTh wrote:
> 2010/7/13 Michel Dänzer :
> > Does KMS work better with radeon.agpmode=1 (or 2 or -1)?
>
> with radeon.agpmode=-1, we could start X server (no black screen),
> with both radeon.modeset={0,1}.
Note that radeon.agpmode is only effective with radeon.modeset=1,
otherwise you need to use Option "AGPMode" in xorg.conf (and vice
versa).
> In all cases, Xorg works fine, except when we try to load an OpenGL
> application (like glxgears), Xorg freeze, we could move only the
> mouse, we couldn't switch to a backup console.
Could be a GPU lockup again, possibly due to still using AGP 4x with
modeset=0.
> Same situations with glxgears in both modeset=0 and =1. In the log
> (Xorg.0.log) we have found:
>
> [.. other xorg log, no EE only WW]
> [65.238] (II) RADEON(0): Panel infos found from DDC detailed: 1280x854
> [65.238] (II) RADEON(0): EDID vendor "APP", prod id 39968
> [65.249] (II) RADEON(0): Output: DVI-0, Detected Monitor Type: 0
> [65.249] Unhandled monitor type 0
> [65.249] (II) RADEON(0): Output: S-video, Detected Monitor Type: 0
> [ 137.813] [mi] EQ overflowing. The server is probably stuck in an
> infinite loop.
> [ 137.813]
> Backtrace:
> [ 137.814] 0: /usr/bin/X (xorg_backtrace+0x58) [0x100582cc]
> [ 137.814] 1: /usr/bin/X (mieqEnqueue+0x1c8) [0x1004e5d8]
> [ 137.814] 2: /usr/bin/X (xf86PostButtonEventP+0xf4) [0x10061be8]
> [ 137.814] 3: /usr/bin/X (xf86PostButtonEvent+0xb4) [0x10061d2c]
> [ 137.814] 4: /usr/lib/xorg/modules/input/evdev_drv.so
> (0xf38+0x3d88) [0xf383d88]
> [ 137.814] 5: /usr/bin/X (0x1000+0x68784) [0x10068784]
> [ 137.814] 6: /usr/bin/X (0x1000+0x11a7e4) [0x1011a7e4]
> [ 137.814] 7: (vdso) (__kernel_sigtramp32+0x0) [0x100344]
> [ 137.814] 8: /usr/lib/xorg/modules/dri/r300_dri.so
> (0xf3f5000+0x48534) [0xf43d534]
> [ 137.814] 9: /usr/lib/libdrm.so.2 (drmIoctl+0x40) [0xf8b8f64]
> [ 137.814] 10: /usr/lib/libdrm.so.2 (drmCommandWrite+0x24) [0xf8bbe60]
> [ 137.814] 11: /usr/lib/xorg/modules/dri/r300_dri.so
> (0xf3f5000+0x46944) [0xf43b944]
> [ 137.814] 12: /usr/lib/xorg/modules/dri/r300_dri.so
> (0xf3f5000+0x64d8c) [0xf459d8c]
> [ 137.814] 13: /usr/lib/xorg/modules/extensions/libglx.so
> (0xf93+0x40f78) [0xf970f78]
> [ 137.814] 14: /usr/lib/xorg/modules/extensions/libglx.so
> (0xf93+0x44be4) [0xf974be4]
> [ 137.814] 15: /usr/bin/X (0x1000+0x34a24) [0x10034a24]
> [ 137.815] 16: /usr/bin/X (0x1000+0x18bc4) [0x10018bc4]
> [ 137.815] 17: /lib/libc.so.6 (0xfb39000+0x1f544) [0xfb58544]
> [ 137.815] 18: /lib/libc.so.6 (0xfb39000+0x1f6d0) [0xfb586d0]
What does the log file contain with modeset=1?
> Do we need to compile mesa, ati-dri, x.org and xf86-video-ati from git?
Shouldn't be necessary.
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 2.6.35-rc4 ppc crash when loading radeon modeset=1
2010/7/13 Michel Dänzer :
[cut]
> Which framebuffer device (if any) is it trying to initialize otherwise?
> OFfb? The first paragraph above implies none, but then I'm not sure why
> the video= parameters would make any difference.
We tried and with 2.6.35-rc4 we could boot without video=. First good news :)
[cut]
> Does KMS work better with radeon.agpmode=1 (or 2 or -1)?
with radeon.agpmode=-1, we could start X server (no black screen),
with both radeon.modeset={0,1}. In all cases, Xorg works fine, except
when we try to load an OpenGL application (like glxgears), Xorg
freeze, we could move only the mouse, we couldn't switch to a backup
console. Same situations with glxgears in both modeset=0 and =1. In
the log (Xorg.0.log) we have found:
[.. other xorg log, no EE only WW]
[65.238] (II) RADEON(0): Panel infos found from DDC detailed: 1280x854
[65.238] (II) RADEON(0): EDID vendor "APP", prod id 39968
[65.249] (II) RADEON(0): Output: DVI-0, Detected Monitor Type: 0
[65.249] Unhandled monitor type 0
[65.249] (II) RADEON(0): Output: S-video, Detected Monitor Type: 0
[ 137.813] [mi] EQ overflowing. The server is probably stuck in an
infinite loop.
[ 137.813]
Backtrace:
[ 137.814] 0: /usr/bin/X (xorg_backtrace+0x58) [0x100582cc]
[ 137.814] 1: /usr/bin/X (mieqEnqueue+0x1c8) [0x1004e5d8]
[ 137.814] 2: /usr/bin/X (xf86PostButtonEventP+0xf4) [0x10061be8]
[ 137.814] 3: /usr/bin/X (xf86PostButtonEvent+0xb4) [0x10061d2c]
[ 137.814] 4: /usr/lib/xorg/modules/input/evdev_drv.so
(0xf38+0x3d88) [0xf383d88]
[ 137.814] 5: /usr/bin/X (0x1000+0x68784) [0x10068784]
[ 137.814] 6: /usr/bin/X (0x1000+0x11a7e4) [0x1011a7e4]
[ 137.814] 7: (vdso) (__kernel_sigtramp32+0x0) [0x100344]
[ 137.814] 8: /usr/lib/xorg/modules/dri/r300_dri.so
(0xf3f5000+0x48534) [0xf43d534]
[ 137.814] 9: /usr/lib/libdrm.so.2 (drmIoctl+0x40) [0xf8b8f64]
[ 137.814] 10: /usr/lib/libdrm.so.2 (drmCommandWrite+0x24) [0xf8bbe60]
[ 137.814] 11: /usr/lib/xorg/modules/dri/r300_dri.so
(0xf3f5000+0x46944) [0xf43b944]
[ 137.814] 12: /usr/lib/xorg/modules/dri/r300_dri.so
(0xf3f5000+0x64d8c) [0xf459d8c]
[ 137.814] 13: /usr/lib/xorg/modules/extensions/libglx.so
(0xf93+0x40f78) [0xf970f78]
[ 137.814] 14: /usr/lib/xorg/modules/extensions/libglx.so
(0xf93+0x44be4) [0xf974be4]
[ 137.814] 15: /usr/bin/X (0x1000+0x34a24) [0x10034a24]
[ 137.815] 16: /usr/bin/X (0x1000+0x18bc4) [0x10018bc4]
[ 137.815] 17: /lib/libc.so.6 (0xfb39000+0x1f544) [0xfb58544]
[ 137.815] 18: /lib/libc.so.6 (0xfb39000+0x1f6d0) [0xfb586d0]
Do we need to compile mesa, ati-dri, x.org and xf86-video-ati from git?
Many thanks
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 2.6.35-rc4 ppc crash when loading radeon modeset=1
On Die, 2010-07-13 at 16:03 +0200, jjDaNiMoTh wrote: > > When trying new 2.6.35-rc4, our kernel team (ArchLinuxPPC) has tried > to setup KMS acceleration for radeon based machine. > We have removed radeonfb, and all others framebuffer driver, and added > fbcon and KMS enabled by default for radeon driver. > > With a clean start, the screen freeze, when the control pass from > yaboot to kernel. > > If we start with video=fbcon (or video=radeondrmfb), we could reach > the loading modules point, [...] Which framebuffer device (if any) is it trying to initialize otherwise? OFfb? The first paragraph above implies none, but then I'm not sure why the video= parameters would make any difference. > Jul 13 15:31:39 jim kernel: [drm] Initialized drm 1.1.0 20060810 > Jul 13 15:31:39 jim kernel: [drm] radeon kernel modesetting enabled. > Jul 13 15:31:39 jim kernel: [drm] initializing kernel modesetting > (RV350 0x1002:0x4E50). > Jul 13 15:31:39 jim kernel: [drm] register mmio base: 0xB000 > Jul 13 15:31:39 jim kernel: [drm] register mmio size: 65536 > Jul 13 15:31:39 jim kernel: [drm] Using generic clock info > Jul 13 15:31:39 jim kernel: agpgart-uninorth :00:0b.0: putting AGP > V2 device into 4x mode > Jul 13 15:31:39 jim kernel: radeon :00:10.0: putting AGP V2 device > into 4x mode > Jul 13 15:31:39 jim kernel: radeon :00:10.0: GTT: 256M 0x > - 0x0FFF > Jul 13 15:31:39 jim kernel: [drm] Generation 2 PCI interface, using > max accessible memory > Jul 13 15:31:39 jim kernel: radeon :00:10.0: VRAM: 64M 0xB800 > - 0xBBFF (64M used) > Jul 13 15:31:39 jim kernel: [drm] radeon: irq initialized. > Jul 13 15:31:39 jim kernel: [drm] Detected VRAM RAM=64M, BAR=128M > Jul 13 15:31:39 jim kernel: [drm] RAM width 128bits DDR > Jul 13 15:31:39 jim kernel: [TTM] Zone kernel: Available graphics > memory: 384990 kiB. > Jul 13 15:31:39 jim kernel: [TTM] Zone highmem: Available graphics > memory: 516062 kiB. > Jul 13 15:31:39 jim kernel: [TTM] Initializing pool allocator. > Jul 13 15:31:39 jim kernel: [drm] radeon: 64M of VRAM memory ready > Jul 13 15:31:39 jim kernel: [drm] radeon: 256M of GTT memory ready. > Jul 13 15:31:39 jim kernel: [drm] radeon: 1 quad pipes, 1 Z pipes initialized. > Jul 13 15:31:39 jim kernel: [drm] Loading R300 Microcode > Jul 13 15:31:39 jim kernel: [drm] radeon: ring at 0x > Jul 13 15:31:39 jim kernel: [drm] ring test succeeded in 3 usecs > Jul 13 15:31:39 jim kernel: [drm] radeon: ib pool ready. So far, so good. > Jul 13 15:31:40 jim kernel: GPU lockup (waiting for 0x0001 last > fence id 0x) The GPU locks up, and things go downhill from there... Does KMS work better with radeon.agpmode=1 (or 2 or -1)? -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
2.6.35-rc4 ppc crash when loading radeon modeset=1
Hello to all. Sorry if these aren't right place, please point me to the right direction if you can :) When trying new 2.6.35-rc4, our kernel team (ArchLinuxPPC) has tried to setup KMS acceleration for radeon based machine. We have removed radeonfb, and all others framebuffer driver, and added fbcon and KMS enabled by default for radeon driver. With a clean start, the screen freeze, when the control pass from yaboot to kernel. If we start with video=fbcon (or video=radeondrmfb), we could reach the loading modules point, but after the loading of radeon, the screen goes black, without any log information. Loading kernel with video=fbcon radeon.modeset=0 allow us to reach the end of init stage, and we could load X.org. In this case, acceleration is disabled. If we log out and do the following command: modprobe -r radeon drm modprobe drm debug=1 modprobe radeon modeset=1 The screen goes black, but at next boot we have found the logs. Any hint? System information: Xorg server: 1.8.1 xf86-video-ati 6.13.0 ati-dri 7.8.1 mesa 7.8.1 linux 2.6.35-rc4-00131-ge467e10 There are logs (most relevant part): [...] Jul 13 15:29:50 jim kernel: Caused by (from SRR1=149030): Transfer error ack signal Jul 13 15:29:50 jim kernel: Machine check in kernel mode. Jul 13 15:29:50 jim kernel: Caused by (from SRR1=149030): Transfer error ack signal Jul 13 15:29:50 jim kernel: Machine check in kernel mode. Jul 13 15:29:50 jim kernel: Caused by (from SRR1=149030): Transfer error ack signal Jul 13 15:29:50 jim kernel: Machine check in kernel mode. Jul 13 15:29:50 jim kernel: Caused by (from SRR1=149030): Transfer error ack signal [] Jul 13 15:31:28 jim kernel: [drm] Module unloaded Jul 13 15:31:39 jim kernel: [drm] Initialized drm 1.1.0 20060810 Jul 13 15:31:39 jim kernel: [drm] radeon kernel modesetting enabled. Jul 13 15:31:39 jim kernel: [drm] initializing kernel modesetting (RV350 0x1002:0x4E50). Jul 13 15:31:39 jim kernel: [drm] register mmio base: 0xB000 Jul 13 15:31:39 jim kernel: [drm] register mmio size: 65536 Jul 13 15:31:39 jim kernel: [drm] Using generic clock info Jul 13 15:31:39 jim kernel: agpgart-uninorth :00:0b.0: putting AGP V2 device into 4x mode Jul 13 15:31:39 jim kernel: radeon :00:10.0: putting AGP V2 device into 4x mode Jul 13 15:31:39 jim kernel: radeon :00:10.0: GTT: 256M 0x - 0x0FFF Jul 13 15:31:39 jim kernel: [drm] Generation 2 PCI interface, using max accessible memory Jul 13 15:31:39 jim kernel: radeon :00:10.0: VRAM: 64M 0xB800 - 0xBBFF (64M used) Jul 13 15:31:39 jim kernel: [drm] radeon: irq initialized. Jul 13 15:31:39 jim kernel: [drm] Detected VRAM RAM=64M, BAR=128M Jul 13 15:31:39 jim kernel: [drm] RAM width 128bits DDR Jul 13 15:31:39 jim kernel: [TTM] Zone kernel: Available graphics memory: 384990 kiB. Jul 13 15:31:39 jim kernel: [TTM] Zone highmem: Available graphics memory: 516062 kiB. Jul 13 15:31:39 jim kernel: [TTM] Initializing pool allocator. Jul 13 15:31:39 jim kernel: [drm] radeon: 64M of VRAM memory ready Jul 13 15:31:39 jim kernel: [drm] radeon: 256M of GTT memory ready. Jul 13 15:31:39 jim kernel: [drm] radeon: 1 quad pipes, 1 Z pipes initialized. Jul 13 15:31:39 jim kernel: [drm] Loading R300 Microcode Jul 13 15:31:39 jim kernel: [drm] radeon: ring at 0x Jul 13 15:31:39 jim kernel: [drm] ring test succeeded in 3 usecs Jul 13 15:31:39 jim kernel: [drm] radeon: ib pool ready. Jul 13 15:31:40 jim kernel: GPU lockup (waiting for 0x0001 last fence id 0x) Jul 13 15:31:40 jim kernel: NIP: f260fda4 LR: f260fda4 CTR: 0001 Jul 13 15:31:40 jim kernel: REGS: ef3a3b90 TRAP: 0700 Not tainted (2.6.35-rc4-NAT-00131-ge467e10) Jul 13 15:31:40 jim kernel: MSR: 00029032 CR: 22822484 XER: 2000 Jul 13 15:31:40 jim kernel: TASK = eedb9ac0[2066] 'modprobe' THREAD: ef3a2000 Jul 13 15:31:40 jim kernel: GPR00: f260fda4 ef3a3c40 eedb9ac0 0040 416d5d8c c04db984 416d5d09 Jul 13 15:31:40 jim kernel: GPR08: 416d5d8c 0001 000a 22822482 100238a8 Jul 13 15:31:40 jim kernel: GPR16: 007d c04a f26a1d54 0001 ef3a2000 Jul 13 15:31:40 jim kernel: GPR24: c005f328 ef3a3c54 eed386cc ef3a3c48 eed38000 ef085d40 Jul 13 15:31:40 jim kernel: NIP [f260fda4] radeon_fence_wait+0x28c/0x2f4 [radeon] Jul 13 15:31:40 jim kernel: LR [f260fda4] radeon_fence_wait+0x28c/0x2f4 [radeon] Jul 13 15:31:40 jim kernel: Call Trace: Jul 13 15:31:40 jim kernel: [ef3a3c40] [f260fda4] radeon_fence_wait+0x28c/0x2f4 [radeon] (unreliable) Jul 13 15:31:40 jim kernel: [ef3a3cb0] [f2638234] r100_ib_test+0x158/0x280 [radeon] Jul 13 15:31:40 jim kernel: [ef3a3ce0] [f26383a4] r100_ib_init+0x28/0xc8 [radeon] Jul 13 15:31:40 jim kernel: [ef3a3cf0] [f263f65c] r300_startup+0xd4/0x1e4 [radeon] Jul 13 15:31:40 jim kernel: [ef3a3d00] [f263fb3c] r300_init+0x150/0x334 [radeon] Jul 13 15:31:40 jim kernel: [ef3a3d10] [f25fc514] radeon_device_init+0x2b0/0x418 [radeon] Jul 13 15:31:40
