From walter.pelissero@iesy.net  Thu Jun  9 12:29:51 2005
Return-Path: <walter.pelissero@iesy.net>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 5E9CC16A41C
	for <FreeBSD-gnats-submit@freebsd.org>; Thu,  9 Jun 2005 12:29:51 +0000 (GMT)
	(envelope-from walter.pelissero@iesy.net)
Received: from smtp.iesy.net (mta002.iesy.net [81.210.131.41])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 084D843D4C
	for <FreeBSD-gnats-submit@freebsd.org>; Thu,  9 Jun 2005 12:29:48 +0000 (GMT)
	(envelope-from walter.pelissero@iesy.net)
Received: from zaphod.home.loc (unknown [81.210.131.48])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by smtp.iesy.net (Postfix) with ESMTP id 1CEB5B532
	for <FreeBSD-gnats-submit@freebsd.org>; Thu,  9 Jun 2005 14:29:45 +0200 (CEST)
Received: from zaphod.home.loc (localhost [127.0.0.1])
	by zaphod.home.loc (8.13.3/8.13.3) with ESMTP id j59CThRW003735
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 9 Jun 2005 14:29:43 +0200 (CEST)
	(envelope-from wcp@zaphod.home.loc)
Received: (from wcp@localhost)
	by zaphod.home.loc (8.13.3/8.13.1/Submit) id j59CThnn003734;
	Thu, 9 Jun 2005 14:29:43 +0200 (CEST)
	(envelope-from wcp)
Message-Id: <200506091229.j59CThnn003734@zaphod.home.loc>
Date: Thu, 9 Jun 2005 14:29:43 +0200 (CEST)
From: "Walter C. Pelissero" <walter@pelissero.de>
Reply-To: walter@pelissero.de
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: DRM not working with SMP
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         82064
>Category:       kern
>Synopsis:       [drm] DRM not working with SMP
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Jun 09 12:30:21 GMT 2005
>Closed-Date:    Sat Aug 21 20:34:04 UTC 2010
>Last-Modified:  Sat Aug 21 20:34:04 UTC 2010
>Originator:     Walter C. Pelissero
>Release:        FreeBSD 5.4-STABLE i386
>Organization:
>Environment:
System: FreeBSD zaphod.home.loc 5.4-STABLE FreeBSD 5.4-STABLE #0: Tue Jun 7 00:19:00 CEST 2005 root@zaphod.home.loc:/usr/src/sys/i386/compile/TYAN-TIGER-MP i386


	Dual Athlon MP and a Ati Radeon 7000-VE AGP.
>Description:
	The DRM driver (at least the Radeon) doesn't seem to work with
	SMP.  If X makes use of DRI the whole system freezes.
>How-To-Repeat:
	On a multiprocessor system configure a 5.4-STABLE for SMP,
	then add the line Load "dri" in xorg.conf and run X.  After a
	few moments of use the system freezes.  The exact activity
	that triggers the bug is not known but a few open windows are
	usually enough.

	If the same system is booted with kern.smp.disabled="1" in
	device.hints the system, including DRI/DRM, works just fine.
>Fix:

	None known.


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->anholt 
Responsible-Changed-By: anholt 
Responsible-Changed-When: Sun Jun 26 21:12:21 GMT 2005 
Responsible-Changed-Why:  
Grab this as DRM maintainer. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=82064 

From: Eric Anholt <eta@lclark.edu>
To: gnats <freebsd-gnats-submit@FreeBSD.ORG>
Cc:  
Subject: Re: kern/82064
Date: Sun, 26 Jun 2005 14:15:47 -0700

 When the system is hung, can you ssh into it?  If not, could you either
 1) Attach a serial console to see if it is a panic, and if so, get a
 backtrace.  Otherwise, while it's hung, try to break and get a backtrace
 then.
 2) enable dumps and hope that if it's a panic you dump successfully,
 then use kgdb to get a backtrace.
 
 See the handbook for information on kernel debugging.
 
 -- 
 Eric Anholt                                     eta@lclark.edu
 http://people.freebsd.org/~anholt/              anholt@FreeBSD.org
State-Changed-From-To: open->feedback 
State-Changed-By: linimon 
State-Changed-When: Wed Nov 23 05:01:36 GMT 2005 
State-Changed-Why:  
Feedback was requested. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=82064 

From: "Walter C. Pelissero" <walter@pelissero.de>
To: Mark Linimon <linimon@FreeBSD.org>
Cc: bug-followup@FreeBSD.org, anholt@FreeBSD.org
Subject: Re: kern/82064: [drm] DRM not working with SMP
Date: Wed, 23 Nov 2005 23:12:28 +0100

 No dump is produced, although the dump device has been configured.
 When the system hangs it doesn't even reply to pings; the keyboard
 LEDs are not affected by its keys, so I'd say the systems is
 completely irresponsive.
 
 I'm currently unable to check whether through a serial console things
 are any different.
 
 Today with 6.0-STABLE I've been able to run "xlock -mode gears" for
 some minutes.  The output was wrong as the gears were visible only in
 the first vertical slice (about a third) on the left of the first
 screen (it's a dual head), but this may be due to a bug in that
 particular screen saver.  Later "xlock -mode atunnels" has frozen the
 system in the usual way.  On reboot the system has frozen once again
 upon xdm startup, which is surprisingly early.
 
 -- 
 walter pelissero
 http://www.pelissero.de
State-Changed-From-To: feedback->open 
State-Changed-By: linimon 
State-Changed-When: Wed Nov 23 22:28:08 GMT 2005 
State-Changed-Why:  
Feedback received. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=82064 

From: Eric Anholt <eta@lclark.edu>
To: bug-followup@FreeBSD.org, walter@pelissero.de
Cc:  
Subject: Re: kern/82064: [drm] DRM not working with SMP
Date: Wed, 23 Nov 2005 14:54:04 -0800

 --=-E+Wl/JkahE0DQqE6oSEG
 Content-Type: text/plain
 Content-Transfer-Encoding: quoted-printable
 
 If you're hanging while running a specific application, it's probably
 not a kernel issue.  Please try updating to xorg-server-snap and
 dri-devel from ports, which may fix it.
 
 As far as only rendering to the left 1/3 or so of your first screen,
 what's the total width of your display?
 
 --=20
 Eric Anholt                                     eta@lclark.edu
 http://people.freebsd.org/~anholt/              anholt@FreeBSD.org
 
 --=-E+Wl/JkahE0DQqE6oSEG
 Content-Type: application/pgp-signature; name=signature.asc
 Content-Description: This is a digitally signed message part
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.2 (FreeBSD)
 
 iD8DBQBDhPMMHUdvYGzw6vcRAkCrAJ0SI/tUK16nnXTBWS0TtRxAHIyXIACggU4C
 +pEjFzS0vorWPuH0pf32Y/Q=
 =kD0p
 -----END PGP SIGNATURE-----
 
 --=-E+Wl/JkahE0DQqE6oSEG--

From: Eric Anholt <eta@lclark.edu>
To: bug-followup@FreeBSD.org, walter@pelissero.de
Cc:  
Subject: Re: kern/82064: [drm] DRM not working with SMP
Date: Wed, 23 Nov 2005 17:43:54 -0800

 --=-hnRBJFz6Drd4gg1+Prs3
 Content-Type: text/plain
 Content-Transfer-Encoding: quoted-printable
 
 I've just tried xlock -mode atunnels on a UP x86 with Radeon 7000 for a
 few minutes.  It's running fine so far, but then I'm using CVS drivers.
 (I'm rather dubious of SMP actually being the issue, which is why I've
 been ignoring it).  If the previous suggestion doesn't work, please
 supply links to your xorg.conf and Xorg.0.log files (or just attach
 them, though I feel the bug reports become less usable that way).
 
 --=20
 Eric Anholt                                     eta@lclark.edu
 http://people.freebsd.org/~anholt/              anholt@FreeBSD.org
 
 --=-hnRBJFz6Drd4gg1+Prs3
 Content-Type: application/pgp-signature; name=signature.asc
 Content-Description: This is a digitally signed message part
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.2 (FreeBSD)
 
 iD8DBQBDhRraHUdvYGzw6vcRAk2+AJ0avAnPkk91oXimboi4Ytcz3TsZEQCdGJb5
 TAF560P00fREPNgYEb64faA=
 =AlTB
 -----END PGP SIGNATURE-----
 
 --=-hnRBJFz6Drd4gg1+Prs3--

From: "Walter C. Pelissero" <walter@pelissero.de>
To: Eric Anholt <eta@lclark.edu>
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/82064: [drm] DRM not working with SMP
Date: Thu, 24 Nov 2005 14:16:41 +0100

 Eric Anholt writes:
  > I've just tried xlock -mode atunnels on a UP x86 with Radeon 7000 for a
  > few minutes.
 
 You will excuse me but I don't see the relevance of such a test.  As
 already explained in the PR, setting kern.smp.disabled=1 even my
 system runs flawlessly.
 
  > If you're hanging while running a specific application, it's probably
  > not a kernel issue.
 
 No, it doesn't hang on a specific application.  I thought I made that
 clear, but in SMP mode and the DRI drivers loaded, sometimes even xdm
 is enough to freeze the system.  The exact type of activity that
 triggers the bug is unknown to me, though.
 
 I just try to trigger the bug with a GL program as that is the more
 likely client of the DRI driver, which is apparently the culprit
 together with SMP.  Just my uneducated guess due to the fact that:
 
   - SMP without DRI	works
   - no SMP without DRI	works
   - no SMP with DRI	works
   - SMP with DRI	freezes
 
  > Please try updating to xorg-server-snap and dri-devel from ports,
  > which may fix it.
 
 As not to leave any stone untorned, I upgraded the X server to
 xorg-server-snap and the DRIs to dri-devel.  I don't see any
 noticeable difference; the system still freezes after a while
 regardless whether I run a GL test or not.
 
  > As far as only rendering to the left 1/3 or so of your first screen,
  > what's the total width of your display?
 
 The problem of xlock showing the GL animations only in the first third
 of the first screen could be just something wrong with xlock itself, as
 running the tests with the -inwindow option, the animation works as
 expected without any clipping no matter where i place the window.
 
 BTW, the combined geometry of the two screens is 2560x1024 pixels.
 
  > (I'm rather dubious of SMP actually being the issue, which is why I've
  > been ignoring it).
 
 kern.smp.disabled does change things, though.
 
  > If the previous suggestion doesn't work, please supply links to
  > your xorg.conf and Xorg.0.log files (or just attach them, though I
  > feel the bug reports become less usable that way).
 
 They are here:
 
 http://www.pelissero.de/kern-82064/xorg.conf
 http://www.pelissero.de/kern-82064/Xorg.0.log
 
 A last consideration which, as far as I can tell, could be just
 rubbish.  I've noticed that if I boot in SMP mode and DRI enabled I
 almost certainly get a frozen system by the time xdm fires.  If, on
 the other hand, I boot the system in SMP but with DRI disabled, and
 then I enable DRI and restart X/xdm I can get as far as testing some X
 applications before the lock up.  The only difference that comes to
 mind is that at bootstrap the system load is by far much higher.
 
 -- 
 walter pelissero
 http://www.pelissero.de

From: Eric Anholt <eta@lclark.edu>
To: walter@pelissero.de
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/82064: [drm] DRM not working with SMP
Date: Thu, 24 Nov 2005 23:45:44 -0800

 --=-TjEKac1hDVgmiXuks5qw
 Content-Type: text/plain
 Content-Transfer-Encoding: quoted-printable
 
 On Thu, 2005-11-24 at 14:16 +0100, Walter C. Pelissero wrote:
 > Eric Anholt writes:
 >  > I've just tried xlock -mode atunnels on a UP x86 with Radeon 7000 for =
 a
 >  > few minutes.
 >=20
 > You will excuse me but I don't see the relevance of such a test.  As
 > already explained in the PR, setting kern.smp.disabled=3D1 even my
 > system runs flawlessly.
 
 Well, I was assuming that 1) this is a DRI/DRM issue (not a general SMP
 issue with your system) and 2) This is not an issue with the DRI and SMP
 specifically.  2) is because my primary DRI testbox for the past 3 years
 or so was SMP, and it was my DRI-using desktop before then.  1) I can't
 guarantee.
 
 >  > If you're hanging while running a specific application, it's probably
 >  > not a kernel issue.
 >=20
 > No, it doesn't hang on a specific application.  I thought I made that
 > clear, but in SMP mode and the DRI drivers loaded, sometimes even xdm
 > is enough to freeze the system.  The exact type of activity that
 > triggers the bug is unknown to me, though.
 >=20
 > I just try to trigger the bug with a GL program as that is the more
 > likely client of the DRI driver, which is apparently the culprit
 > together with SMP.  Just my uneducated guess due to the fact that:
 >=20
 >   - SMP without DRI	works
 >   - no SMP without DRI	works
 >   - no SMP with DRI	works
 >   - SMP with DRI	freezes
 >=20
 >  > Please try updating to xorg-server-snap and dri-devel from ports,
 >  > which may fix it.
 >=20
 > As not to leave any stone untorned, I upgraded the X server to
 > xorg-server-snap and the DRIs to dri-devel.  I don't see any
 > noticeable difference; the system still freezes after a while
 > regardless whether I run a GL test or not.
 >=20
 >  > As far as only rendering to the left 1/3 or so of your first screen,
 >  > what's the total width of your display?
 >=20
 > The problem of xlock showing the GL animations only in the first third
 > of the first screen could be just something wrong with xlock itself, as
 > running the tests with the -inwindow option, the animation works as
 > expected without any clipping no matter where i place the window.
 >=20
 > BTW, the combined geometry of the two screens is 2560x1024 pixels.
 
 The Radeon can only natively draw up to 2048x2048 at a time.  So, it's
 modulating and only drawing 2560 - 2048 =3D 512 pixels.  It's something we
 should fix by drawing in multiple passes, but nobody's done it yet.
 
 > A last consideration which, as far as I can tell, could be just
 > rubbish.  I've noticed that if I boot in SMP mode and DRI enabled I
 > almost certainly get a frozen system by the time xdm fires.  If, on
 > the other hand, I boot the system in SMP but with DRI disabled, and
 > then I enable DRI and restart X/xdm I can get as far as testing some X
 > applications before the lock up.  The only difference that comes to
 > mind is that at bootstrap the system load is by far much higher.
 
 OK, you don't have any AGP options enabled, which is good.  Does it
 happen without using multiple screens?  I assume it happened with 6.8.2
 as well?  Ooh, most importantly, does the patch in i386/59854 help?  If
 not, does Option "BusType" "PCI" fix it? (boy, I hope that pci-mode
 breaking patch hadn't made it into 6.8.99.16)
 
 --=20
 Eric Anholt                                     eta@lclark.edu
 http://people.freebsd.org/~anholt/              anholt@FreeBSD.org
 
 --=-TjEKac1hDVgmiXuks5qw
 Content-Type: application/pgp-signature; name=signature.asc
 Content-Description: This is a digitally signed message part
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.2 (FreeBSD)
 
 iD8DBQBDhsEoHUdvYGzw6vcRAh2QAKCIXd2AuE5vYJgd9kki1SGFyZCY9wCghFeB
 MzoKhOTufZSpMOHEupywkcQ=
 =rmY6
 -----END PGP SIGNATURE-----
 
 --=-TjEKac1hDVgmiXuks5qw--

From: "Walter C. Pelissero" <walter@pelissero.de>
To: Eric Anholt <eta@lclark.edu>
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/82064: [drm] DRM not working with SMP
Date: Fri, 25 Nov 2005 13:49:25 +0100

 Eric Anholt writes:
  > The Radeon can only natively draw up to 2048x2048 at a time.  So, it's
  > modulating and only drawing 2560 - 2048 = 512 pixels.  It's something we
  > should fix by drawing in multiple passes, but nobody's done it yet.
 
 Right, thanks for the explanation.
 
  > Does it happen without using multiple screens?
 
 Yes, it does.
 
  > I assume it happened with 6.8.2 as well?
 
 Yes.  Just downgraded back to it and tried.
 
  > Ooh, most importantly, does the patch in i386/59854 help?
  
 No, it doesn't.  But if it may be a BIOS configuration issue I could
 provide it to you.
 
  > If not, does Option "BusType" "PCI" fix it?
 
 That messes up things badly.  That option in 6.8.99 gives a nice black
 screen and a system load > 4 (doing God knows what); no chance to get
 the attention of the system but through ssh.  On 6.8.2 it gives a
 badly corrupted screen a jerky mouse pointer and for the rest almost
 the same as with 6.8.99.
 
 -- 
 walter pelissero
 http://www.pelissero.de
Responsible-Changed-From-To: anholt->freebsd-bugs 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Fri Aug 8 00:24:56 UTC 2008 
Responsible-Changed-Why:  
Assignee has asked to resign his commit bit, so return this one to pool. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=82064 
State-Changed-From-To: open->closed 
State-Changed-By: vwe 
State-Changed-When: Sat Aug 21 20:32:49 UTC 2010 
State-Changed-Why:  
5.4 is out of support now for a long time. 

Dear Walter, if you still see this bug with a recent release, please drop us 
a note and we'll open this report again. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=82064 
>Unformatted:
