DRI problems with ati/radeon on stable/7 r203425

[Robert Noland]

On Wed, 2010-02-10 at 11:37 -0800, David Wolfskill wrote:
> On Wed, Feb 10, 2010 at 09:14:35AM -0600, Robert Noland wrote:
> > On Wed, 2010-02-10 at 07:06 -0800, David Wolfskill wrote:
> > > On Wed, Feb 10, 2010 at 08:56:45AM -0600, Robert Noland wrote:
> > > > ...
> > > > Right, it sounds like the other person is having interrupt issues.  Does
> > > > moving the mouse / touchpad have any impact?
> > > 
> > > Well, trying to doesn't appear to have any effect; it doesn't move,
> > > regardless.
> > > 
> > > > Or, possibly disabling msi? (adding hw.drm.msi=0 to loader.conf)
> > > > ....
> > > 
> > > Well, I don't know what msi is, so I hadn't tried that.  I will try it
> > > after the daily builds are finished -- probably 3 - 4 hours from now.
> > 
> > MSI is "Message Signaled Interrupt" and is enabled by default for any
> > card that reports that it is capable (except for intel 945, which is
> > borked).  When drm loads it will tell you if it is using msi or not.
> > ...
> 
> OK.  I re-enabled DRI in xorg.conf & disabled hw.drm.msi; the result
> appeared to work, though the screen didn't always clear all of images
> (e.g., the "swarm" screen saver left little white bits lying around;
> when the (2-D) juggler was tossing scarves, huge vertical swaths of
> color were left behind).
> 
> I re-enabled hw.drm.msi & rebooted; got the lockup.  Noticed that
> sending a BREAK on serial console does get me into DDB.  Rebooted; fsck;
> disabled hw.drm.msi again; rebooted (there's a lot of that...).
> 
> xdm came up OK.
> 
> I logged in via ssh, the started killing off the xdm process.  It would
> terminate, then init(8) would fire it back up again (courtesy of the
> entry in /etc/ttys), as expected.
> 
> About the 5th time around, xdm didn't come back.
> 
> Couldn't switch to a vty (via Ctl+Alt+Fx).  No "login: " prompt at
> serial console.
> 
> Sent a BREAK to the latter; backtrace shows:
> 
> agp0: Setting AGP v2 mode 4

Hrm, this is the first time I've heard of msi issues on radeons.  You
might also try different agp modes i.e. AGPMode "1".  agp can be a bit
finicky... Actually, an r200 trying to do msi?  What does pciconf -lvbc
show for the card/chip?  The test for msi should just fail and normal
interrupt should be used.  What else is sharing the interrupt with
vgapci?

robert.

> info: [drm] Setting GART location based on new memory map
> info: [drm] Loading R200 Microcode
> info: [drm] writeback test succeeded in 2 usecs
> drm0: [MPSAFE]
> drm0: [ITHREAD]
> agp0: Setting AGP v2 mode 4
> info: [drm] Setting GART location based on new memory map
> info: [drm] Loading R200 Microcode
> info: [drm] writeback test succeeded in 2 usecs
> drm0: [MPSAFE]
> drm0: [ITHREAD]
> ~KDB: enter: Line break on console
> [thread pid 13 tid 100005 ]
> Stopped at      0xc081c68a = kdb_enter_why+0x3a:        movl    $0,0xc0cd1338 = kdb_why
> db> bt
> Tracing pid 13 tid 100005 td 0xc54e36c0
> kdb_enter_why(c0b63ea1,c0b9492d,c0cd0480,b,c5c0c48c,...) at 0xc081c68a = kdb_enter_why+0x3a
> siointr1(c07f7526,c54e36c0,0,6,c3feb7f8,...) at 0xc0ad07c3 = siointr1+0x133
> siointr(c5c0c400,c54e36c0,c0ca1830,c552a700,4,...) at 0xc0ad2140 = siointr+0x70
> intr_event_handle(c552a700,c51b1c78,c58768cc,c54e36c0,4,...) at 0xc07ca25c = intr_event_handle+0x5c
> intr_execute_handlers(c0ca1830,c51b1c78,c0811a2f,c54e36c0,c58766c0,...) at 0xc0ae5e2f = intr_execute_handlers+0x4f
> atpic_handle_intr(4,c51b1c78) at 0xc0b019f7 = atpic_handle_intr+0xf7
> Xatpic_intr4() at 0xc0ae1171 = Xatpic_intr4+0x21
> --- interrupt, eip = 0xc0aeb07b, esp = 0xc51b1cb8, ebp = 0xc51b1cbc ---
> spinlock_exit(1,0,c0b9ea17,4fc,0,...) at 0xc0aeb07b = spinlock_exit+0x2b
> ithread_loop(c54db880,c51b1d38,0,0,0,...) at 0xc07caea8 = ithread_loop+0x338
> fork_exit(c07cab70,c54db880,c51b1d38) at 0xc07c7089 = fork_exit+0x99
> fork_trampoline() at 0xc0ae1080 = fork_trampoline+0x8
> --- trap 0, eip = 0, esp = 0xc51b1d70, ebp = 0 ---
> db> show lock 
> db> show sleepqueue
> db> show lockchain 
> thread 100005 (pid 13, swi4: clock sio) running on CPU 0
> db> show sleepchain
> thread 100005 (pid 13, swi4: clock sio) running on CPU 0
> 
> Please let me know if there's any other information I could provide; I'd
> like to help get this resolved.
> 
> Peace,
> david
-- 
Robert Noland <rnoland at FreeBSD.org>
FreeBSD