From owner-freebsd-x11@FreeBSD.ORG Wed Feb 10 19:57:36 2010 Return-Path: Delivered-To: x11@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED41F106566C for ; Wed, 10 Feb 2010 19:57:34 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id BD6C88FC13 for ; Wed, 10 Feb 2010 19:57:34 +0000 (UTC) Received: from [192.168.1.4] (adsl-19-244-133.bna.bellsouth.net [68.19.244.133]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id o1AJtmb6006382 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 10 Feb 2010 14:55:51 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: David Wolfskill , x11@FreeBSD.org In-Reply-To: <20100210193752.GE391@bunrab.catwhisker.org> References: <20100208172654.GA391@bunrab.catwhisker.org> <1265764746.8609.18.camel@balrog.2hip.net> <20100210023558.GV391@bunrab.catwhisker.org> <1265802517.8609.25.camel@balrog.2hip.net> <20100210130642.GA391@bunrab.catwhisker.org> <1265813805.8609.52.camel@balrog.2hip.net> <20100210150604.GC391@bunrab.catwhisker.org> <1265814875.8609.61.camel@balrog.2hip.net> <20100210193752.GE391@bunrab.catwhisker.org> Content-Type: text/plain Organization: FreeBSD Date: Wed, 10 Feb 2010 13:55:41 -0600 Message-Id: <1265831741.8609.98.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00, FH_DATE_PAST_20XX, RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: Subject: Re: DRI problems with ati/radeon on stable/7 r203425 X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 19:57:36 -0000 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 FreeBSD