From xi at borderworlds.dk Fri Aug 1 14:48:24 2008 From: xi at borderworlds.dk (Christian Laursen) Date: Fri Aug 1 14:48:42 2008 Subject: FreeBSD Port: x11-drivers/xf86-video-intel In-Reply-To: <48931F92.7090909@gmail.com> (Jimmie James's message of "Fri\, 01 Aug 2008 10\:37\:06 -0400") References: <48931F92.7090909@gmail.com> Message-ID: Jimmie James writes: >> >> Any chance of seeing the latest Intel 2.4.0 drivers ported across >> to > FreeBSD >>>> -it finally supports the G35 chipset that my motherboard uses.Yes I know >>>> they have only been released last Wednesday ;-) but I am prepared to >>>> wait so I can finally get my motherboard working (only VESA at present). > >>> I'll happily commit it if you can test it. >>> >>> Just bump PORTVERSION to 2.4.0, run `make makesum` and `make all install clean`. > >>I just tested it on two laptops here and it works fine on both of them. > >>One of them has a 915GM chipset and the other one has a 965GM. > >>I have had to run with the NoAccel option turned on for a while but >>that is now no longer neccesary. Very nice. > > Quick question for you Christian, you were running with NoAccel, were > you getting this error with it? > > Error in I830WaitLpRing(), timeout for 2 seconds > (WW) intel(0): PRB0_CTL (0x0001f001) indicates ring buffer enabled > (WW) intel(0): PRB0_HEAD (0x13e1ad64) and PRB0_TAIL (0x0001afa8) > indicate ring buffer not flushed > (WW) intel(0): Existing errors found in hardware state. I don't remember getting it. I have only saved one Xorg log file from the old driver and that error is not in there. It might have been there on the other laptop though... -- Christian Laursen From jimmiejaz at gmail.com Fri Aug 1 15:05:21 2008 From: jimmiejaz at gmail.com (Jimmie James) Date: Fri Aug 1 15:05:28 2008 Subject: FreeBSD Port: x11-drivers/xf86-video-intel Message-ID: <48931F92.7090909@gmail.com> > >> Any chance of seeing the latest Intel 2.4.0 drivers ported across to FreeBSD >>> -it finally supports the G35 chipset that my motherboard uses.Yes I know >>> they have only been released last Wednesday ;-) but I am prepared to >>> wait so I can finally get my motherboard working (only VESA at present). >> I'll happily commit it if you can test it. >> >> Just bump PORTVERSION to 2.4.0, run `make makesum` and `make all install clean`. >I just tested it on two laptops here and it works fine on both of them. >One of them has a 915GM chipset and the other one has a 965GM. >I have had to run with the NoAccel option turned on for a while but >that is now no longer neccesary. Very nice. Quick question for you Christian, you were running with NoAccel, were you getting this error with it? Error in I830WaitLpRing(), timeout for 2 seconds (WW) intel(0): PRB0_CTL (0x0001f001) indicates ring buffer enabled (WW) intel(0): PRB0_HEAD (0x13e1ad64) and PRB0_TAIL (0x0001afa8) indicate ring buffer not flushed (WW) intel(0): Existing errors found in hardware state. I'd love if this new version has fixed this problem. -- Over the years I've come to regard you as people I've met. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From bugmaster at FreeBSD.org Mon Aug 4 11:07:05 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 4 11:09:19 2008 Subject: Current problem reports assigned to freebsd-x11@FreeBSD.org Message-ID: <200808041107.m74B74X1082260@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- f ports/106370 x11 Screen corruption when using Direct Rendering on a PCI o ports/116359 x11 x11/xorg - screen blinks with PCI-E nvidia card and ve o ports/117195 x11 ix11/Xorg 7.3 dumps core at exit (sig 11) f ports/117508 x11 x11/xorg 7.2,7.3 i8i0 and intel crash system using Ble o ports/117766 x11 x11-servers/xorg-server (7.3) crashes under heavy load o ports/118950 x11 x11-drivers/xf86-video-nv - xorg xf86 nv (nvidia) driv o ports/119037 x11 x11: Can't type _ (Underscore) under X (gnome) f ports/119091 x11 x11-drivers/xf86-video-intel 2.1.1 panics system o ports/121360 x11 x11/xorg - Change default of ~/.xsession-errors to off o ports/122830 x11 x11/xorg: Error in I830WaitLpRing() o ports/122924 x11 XCreateImage fails in most recent x11/XOrg o ports/124220 x11 [amd64] x11-servers/xorg-server - X.org server runs in o ports/124861 x11 Keyboard problems with xorg o ports/125661 x11 x11/xorg: startx fails after a couple of attempts 14 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s ports/73743 x11 XOrg/XFree xauth add/startx problem o ports/93667 x11 x11/xorg-libraries: undefined symbol in libOSMesa.* is o ports/113106 x11 x11/xorg - Xorg 7.2 + Mach64 + dri produces error mess f ports/114827 x11 Xorg server crashes when starting astro/google-earth o ports/115020 x11 New port: graphics/osmesa - Mesa's off-screen renderin s ports/115536 x11 [new port] x11/xorg-base port for a minimal X.Org inst o ports/116443 x11 x11-drivers/xf86-input-keyboard patch for USB jp106 ke f ports/116603 x11 x11/xorg server 7.3 hangs up f ports/117907 x11 x11-servers/mga_hal broken on 7.0-BETA (GLIBC error) f ports/118217 x11 xorg doesnt find usb mouse when initiated with devd, w o ports/118547 x11 [patch] x11/xdm fails with pam_krb5 o ports/118645 x11 Xorg need realtime priority for mouse work nice o ports/121230 x11 [patch] ports/x11/xkeyboard-config WITHOUT_NLS support o ports/123137 x11 x11/libX11: missing ru_RU.UTF-8 locale o ports/125883 x11 x11-fonts/xorg-fonts-cyrillic is installed, but fonts o ports/125992 x11 devel/imake: remove conflict with unexisting package 16 problems total. From avg at icyb.net.ua Mon Aug 4 13:11:55 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Mon Aug 4 13:12:02 2008 Subject: Mapping Control-Delete to BackSpace In-Reply-To: <20080719224711.GM39074@obiwan.tataz.chchile.org> References: <20080719224711.GM39074@obiwan.tataz.chchile.org> Message-ID: <4896F8AE.6020302@icyb.net.ua> on 20/07/2008 01:47 Jeremie Le Hen said the following: > Hi there! > > Please Cc: me when replying. > > The backspace key on my laptop is dead. I'd like to map Control-Delete > to BackSpace using xmodmap(1). It's straightforward to do for > Shift-Delete, but I can't figure out how to do so for Control-Delete. > > Any help would be welcome. Not sure about xmodmap but you can modify your /usr/local/share/X11/xkb/symbols/pc to have the following definition for Delete key: key { type="PC_CONTROL_LEVEL2", [ Delete, BackSpace ] }; You can do more research on XKB configuration and how to do the above in non-intrusive way. The key thing here is you need to change type of Delete key to control-modifiable. -- Andriy Gapon From donotreply at tringme.com Mon Aug 4 16:20:29 2008 From: donotreply at tringme.com (TringMe) Date: Mon Aug 4 16:20:35 2008 Subject: Make Free Calls Worldwide - Invitation From Mohd. Aijaz Message-ID: <20080804155611.DCE39B6899E@tringme.com> Dear TringMe User, Mohd. Aijaz has invited you to join TringMe and make worldwide calls FREE from your mobile and web. TringMe is the simplest way make and receive worldwide calls from the web for FREE* … just click & call !! No software to download, No software to install. Break free from the traditional telephony paradigm and embrace the next generation telephony: - Make and receive calls between Web, Instant Messengers, Phones, SIP URIs etc !! - Retrieve voicemails from any device or directly from the web. Have it mailed to you as text !! Reduce your dependency on the expensive cellular minutes - Access the same set services from TringMe's powerful MobileVoIP client - Use WiFi, 2.5G/3G data networks to make and receive cheap calls, retrieve voicemails and much more !! Join TringMe by clicking on the following link (or copy/paste in your browser) http://tringme.com/myinvite.php?e=freebsd-x11%40freebsd.org&f=13847-2483659572&ic=797a6babba5d0963 Feel free to write to us at support@tringme.com if you need any assistance. Regards, TringMe Support http://tringme.com/ From vs at FreeBSD.org Tue Aug 5 07:47:04 2008 From: vs at FreeBSD.org (vs@FreeBSD.org) Date: Tue Aug 5 07:47:11 2008 Subject: ports/93667: x11/xorg-libraries: undefined symbol in libOSMesa.* is causing problems Message-ID: <200808050747.m757l4oX032680@freefall.freebsd.org> Synopsis: x11/xorg-libraries: undefined symbol in libOSMesa.* is causing problems State-Changed-From-To: open->closed State-Changed-By: vs State-Changed-When: Tue Aug 5 07:44:06 UTC 2008 State-Changed-Why: Unable to reproduce/no longer pertinent: libOSMesa no longer exists, package graphics/tulip builds fine. Please tell us if this is still an issue. http://www.freebsd.org/cgi/query-pr.cgi?pr=93667 From bitsnstuff101 at tiscali.co.uk Tue Aug 5 17:26:02 2008 From: bitsnstuff101 at tiscali.co.uk (vangogh) Date: Tue Aug 5 17:26:08 2008 Subject: Complete System Freeze when log out of X session Message-ID: <48988A69.1000404@tiscali.co.uk> My laptop has xorg 7.3 on Freebsd 7. My xorg.conf file has: Section "Device" Identifier "card0" Driver "vesa" VendorName "S3 Inc" BoardName "VT8375 [ProSavage8 KM266/KL266]" BusID "PCI:1:0:0" EndSection Problem is when I log out of gnome my system freezes completely and control+alt+backspace does not work. The keyboard becomes totally unresponsive and i must unplug the system to turn it off. I have searched this problem and seen that posts appear in the archives back in 2006 about this issue. However, I cannot find any solution. Can someone please point me in the right direction for a solution to this please? From r.c.ladan at gmail.com Tue Aug 5 18:41:22 2008 From: r.c.ladan at gmail.com (Rene Ladan) Date: Tue Aug 5 18:41:28 2008 Subject: Complete System Freeze when log out of X session In-Reply-To: <48988A69.1000404@tiscali.co.uk> References: <48988A69.1000404@tiscali.co.uk> Message-ID: <48989825.3060307@gmail.com> vangogh schreef: > My laptop has xorg 7.3 on Freebsd 7. > My xorg.conf file has: > Section "Device" > Identifier "card0" > Driver "vesa" > VendorName "S3 Inc" > BoardName "VT8375 [ProSavage8 KM266/KL266]" > BusID "PCI:1:0:0" > EndSection > > Problem is when I log out of gnome my system freezes completely and > control+alt+backspace does not work. The keyboard becomes totally > unresponsive and i must unplug the system to turn it off. I have > searched this problem and seen that posts appear in the archives back in > 2006 about this issue. However, I cannot find any solution. Can someone > please point me in the right direction for a solution to this please? > This sounds slightly familiar. I sometimes have these freezes too, but when I'm still in xfce4. Pressing the power knob still works for me, as well as logging in remotely via ssh. This means that only the screen (which turns black, no backlight on) and keyboard/mouse are frozen. This is with an Asus A6JE, Ati Radeon X1450 running xorg 7.3 with xf86-video-radeonhd 1.2.1. HTH, Rene -- http://www.rene-ladan.nl/ GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) From wblock at wonkity.com Tue Aug 5 23:20:05 2008 From: wblock at wonkity.com (Warren Block) Date: Tue Aug 5 23:20:12 2008 Subject: Complete System Freeze when log out of X session In-Reply-To: <48988A69.1000404@tiscali.co.uk> References: <48988A69.1000404@tiscali.co.uk> Message-ID: On Tue, 5 Aug 2008, vangogh wrote: > My laptop has xorg 7.3 on Freebsd 7. > My xorg.conf file has: > Section "Device" > Identifier "card0" > Driver "vesa" > VendorName "S3 Inc" > BoardName "VT8375 [ProSavage8 KM266/KL266]" > BusID "PCI:1:0:0" > EndSection > > Problem is when I log out of gnome my system freezes completely and > control+alt+backspace does not work. The keyboard becomes totally > unresponsive and i must unplug the system to turn it off. I have searched > this problem and seen that posts appear in the archives back in 2006 about > this issue. However, I cannot find any solution. Can someone please point me > in the right direction for a solution to this please? As I've posted twice in comp.unix.bsd.freebsd.misc: Try using the xf86-video-savage driver instead of vesa, and disable DRI in xorg.conf. -Warren Block * Rapid City, South Dakota USA From drake3 at pmeredith.com Thu Aug 7 15:08:03 2008 From: drake3 at pmeredith.com (drake3 meredith) Date: Thu Aug 7 15:08:10 2008 Subject: help with headless Sparc box - cannot get X and vnc running... Message-ID: <581dbfed0808070739p7ff40f5w63abe8f7f0897a1e@mail.gmail.com> Hello, I am new to FreeBSD and could use some help. I installed 7.0 on a Sun Netra T1 AC200 headless server. Installed through serial terminal and got networking up. Installed X.org distribution and realvnc package. When I run vncserver I get some errors in the vnc log file and see nothing but a black screen when I connect to the session on the sparc. Contents of the log file: Xvnc Free Edition 4.1.2 - built Aug 6 2008 06:38:59 Copyright (C) 2002-2005 RealVNC Ltd. See http://www.realvnc.com for information on VNC. Underlying X server release 40300000, The XFree86 Project, Inc Thu Aug 7 14:01:46 2008 vncext: VNC extension running! vncext: Listening for VNC connections on port 5901 vncext: Listening for HTTP connections on port 5801 vncext: created VNC server for screen 0 Could not init font path element /usr/local/lib/X11/fonts/Speedo/, removing from list! Could not init font path element /usr/local/lib/X11/fonts/CID/, removing from list! Xlib: connection to ":1.0" invalid setup xsetroot: unable to open display ':1' Xlib: connection to ":1.0" invalid setup twm: unable to open display ":1" Xlib: connection to ":1.0" invalid setup vncconfig: unable to open display ":1" Xlib: connection to ":1.0" invalid setup xterm Xt error: Can't open display: :1 [end file] I have deinstalled the xorg-server package and reinstalled, but same result. I had to configure the xorg.conf file using "xorgconfig" because the other method did not work since it is a headless unit - no display found - could not use the console driver. I have searched X.org and mailing list archives for "invalid setup" message, but cannot find anything. Thanks for any help - Paul. From gary.jennejohn at freenet.de Thu Aug 7 17:35:46 2008 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Thu Aug 7 17:35:53 2008 Subject: help with headless Sparc box - cannot get X and vnc running... In-Reply-To: <581dbfed0808070739p7ff40f5w63abe8f7f0897a1e@mail.gmail.com> References: <581dbfed0808070739p7ff40f5w63abe8f7f0897a1e@mail.gmail.com> Message-ID: <20080807193539.426c9fa4@peedub.jennejohn.org> On Thu, 7 Aug 2008 10:39:47 -0400 "drake3 meredith" wrote: > Hello, > > I am new to FreeBSD and could use some help. > I installed 7.0 on a Sun Netra T1 AC200 headless server. Installed through > serial terminal and got networking up. Installed X.org distribution and > realvnc package. When I run vncserver I get some errors in the vnc log file > and see nothing but a black screen when I connect to the session on the > sparc. > > Contents of the log file: > > Xvnc Free Edition 4.1.2 - built Aug 6 2008 06:38:59 > Copyright (C) 2002-2005 RealVNC Ltd. > See http://www.realvnc.com for information on VNC. > Underlying X server release 40300000, The XFree86 Project, Inc > > > Thu Aug 7 14:01:46 2008 > vncext: VNC extension running! > vncext: Listening for VNC connections on port 5901 > vncext: Listening for HTTP connections on port 5801 > vncext: created VNC server for screen 0 > Could not init font path element /usr/local/lib/X11/fonts/Speedo/, removing > from list! > Could not init font path element /usr/local/lib/X11/fonts/CID/, removing > from list! > Xlib: connection to ":1.0" invalid setup > xsetroot: unable to open display ':1' > Xlib: connection to ":1.0" invalid setup > twm: unable to open display ":1" > Xlib: connection to ":1.0" invalid setup > vncconfig: unable to open display ":1" > Xlib: connection to ":1.0" invalid setup > xterm Xt error: Can't open display: :1 > > [end file] > > I have deinstalled the xorg-server package and reinstalled, but same > result. I had to configure the xorg.conf file using "xorgconfig" because > the other method did not work since it is a headless unit - no display found > - could not use the console driver. > > I have searched X.org and mailing list archives for "invalid setup" message, > but cannot find anything. > What's in your /var/log/Xorg.0.log? Is there even a graphics card in this thing? Seems like vnc needs an X-capable box for it to work, since it appears to run like Xnest does as a client of the real X server. This comment is based on a cursory review of the documentation on the web site, which isn't exactly overwhelmingly detailed. --- Gary Jennejohn From drake3 at pmeredith.com Thu Aug 7 17:58:57 2008 From: drake3 at pmeredith.com (drake3 meredith) Date: Thu Aug 7 17:59:05 2008 Subject: help with headless Sparc box - cannot get X and vnc running... In-Reply-To: <20080807193539.426c9fa4@peedub.jennejohn.org> References: <581dbfed0808070739p7ff40f5w63abe8f7f0897a1e@mail.gmail.com> <20080807193539.426c9fa4@peedub.jennejohn.org> Message-ID: <581dbfed0808071058j2e5a5badnb10d7e71d77ebb31@mail.gmail.com> > > > > What's in your /var/log/Xorg.0.log? Is there even a graphics card in > this thing? > > Seems like vnc needs an X-capable box for it to work, since it appears > to run like Xnest does as a client of the real X server. This comment > is based on a cursory review of the documentation on the web site, > which isn't exactly overwhelmingly detailed. > > --- > Gary Jennejohn > Hi Gary, There is no graphics card in the box. Completely headless machine, only direct IO to the hardware is the LOM/console port. Right before I installed FreeBSD I did install a sparc 64 port of Debian on it. X ran through vnc, but had a minor issue where some of the menus and title bars of windows under gnome were black. I did not choose to troubleshoot that install since other system processes were crashing and it was not stable. FreeBSD seems very solid running on Sparc hardware so far. Here is a copy of my Xorg.0.log file: X.Org X Server 1.4.0 Release Date: 5 September 2007 X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 7.0-RELEASE sparc64 Current Operating System: FreeBSD sparc1 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Mon Feb 25 09:35:41 UTC 2008 root@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC sparc64 Build Date: 03 February 2008 01:51:11AM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Thu Aug 7 04:15:59 2008 (==) Using config file: "/etc/X11/xorg.conf" (==) ServerLayout "Simple Layout" (**) |-->Screen "Screen 1" (0) (**) | |-->Monitor "My Monitor" (**) | |-->Device "My Video Card" (**) |-->Input Device "Mouse1" (**) |-->Input Device "Keyboard1" (==) Automatically adding devices (==) Automatically enabling devices (WW) `fonts.dir' not found (or not valid) in "/usr/local/lib/X11/fonts/local/". Entry deleted from font path. (Run 'mkfontdir' on "/usr/local/lib/X11/fonts/local/"). (==) Including the default font path /usr/local/lib/X11/fonts/misc/,/usr/local/lib/X11/fonts/TTF/,/usr/local/lib/X11/fonts/OTF,/usr/local/lib/X11/fonts/Type1/,/usr/local/lib/X11/fonts/100dpi/,/usr/local/lib/X11/fonts/75dpi/. (**) FontPath set to: /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF, /usr/local/lib/X11/fonts/Type1/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/, /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF, /usr/local/lib/X11/fonts/Type1/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/ (==) RgbPath set to "/usr/local/share/X11/rgb" (==) ModulePath set to "/usr/local/lib/xorg/modules" (II) Loader magic: 0x3a7840 (II) Module ABI versions: X.Org ANSI C Emulation: 0.3 X.Org Video Driver: 2.0 X.Org XInput driver : 2.0 X.Org Server Extension : 0.3 X.Org Font Renderer : 0.5 (II) Loader running on freebsd (II) LoadModule: "pcidata" (II) Loading /usr/local/lib/xorg/modules//libpcidata.so (II) Module pcidata: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.0.0 ABI class: X.Org Video Driver, version 2.0 Fatal server error: xf86OpenConsole: No console driver found Supported drivers: pccons (with X support), syscons, pcvt Check your kernel's console driver configuration and /dev entries [end] I guess the console issue is the problem, but figured if Debian can run X headless Freebsd could too. This Netra unit was our firewall running Solaris and Gauntlet for a long time. I am just trying to keep a good RISC system out of the dumpster by giving it a nice home and OS to run. Thanks Paul Meredith. From jeremie at le-hen.org Fri Aug 8 22:09:00 2008 From: jeremie at le-hen.org (Jeremie Le Hen) Date: Fri Aug 8 22:09:06 2008 Subject: Mapping Control-Delete to BackSpace In-Reply-To: <4896F8AE.6020302@icyb.net.ua> References: <20080719224711.GM39074@obiwan.tataz.chchile.org> <4896F8AE.6020302@icyb.net.ua> Message-ID: <20080808220240.GK27033@obiwan.tataz.chchile.org> Hi Andriy, On Mon, Aug 04, 2008 at 03:40:14PM +0300, Andriy Gapon wrote: > on 20/07/2008 01:47 Jeremie Le Hen said the following: > > Hi there! > > > > Please Cc: me when replying. > > > > The backspace key on my laptop is dead. I'd like to map Control-Delete > > to BackSpace using xmodmap(1). It's straightforward to do for > > Shift-Delete, but I can't figure out how to do so for Control-Delete. > > > > Any help would be welcome. > > Not sure about xmodmap but you can modify your > /usr/local/share/X11/xkb/symbols/pc to have the following definition for > Delete key: > > key { type="PC_CONTROL_LEVEL2", [ Delete, BackSpace ] }; > > You can do more research on XKB configuration and how to do the above in > non-intrusive way. > The key thing here is you need to change type of Delete key to > control-modifiable. Thank you very much! I didn't know that xkb was that mighty! :) For the records, I've create a new keyboard layout like this: % jarjarbinks:~:143# cat /usr/local/share/X11/xkb/symbols/jarjarbinks % partial default alphanumeric_keys % xkb_symbols "basic" { % include "fr" % key { % type= "PC_CONTROL_LEVEL2", % symbols[Group1]= [ Delete, BackSpace ] % }; % }; % Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From rnoland at FreeBSD.org Sat Aug 9 20:43:52 2008 From: rnoland at FreeBSD.org (Robert Noland) Date: Sat Aug 9 20:43:58 2008 Subject: Complete System Freeze when log out of X session In-Reply-To: <48988A69.1000404@tiscali.co.uk> References: <48988A69.1000404@tiscali.co.uk> Message-ID: <1218314623.1914.4.camel@wombat.2hip.net> On Tue, 2008-08-05 at 18:14 +0100, vangogh wrote: > My laptop has xorg 7.3 on Freebsd 7. > My xorg.conf file has: > Section "Device" > Identifier "card0" > Driver "vesa" > VendorName "S3 Inc" > BoardName "VT8375 [ProSavage8 KM266/KL266]" > BusID "PCI:1:0:0" > EndSection > > Problem is when I log out of gnome my system freezes completely and > control+alt+backspace does not work. The keyboard becomes totally > unresponsive and i must unplug the system to turn it off. I have > searched this problem and seen that posts appear in the archives back in > 2006 about this issue. However, I cannot find any solution. Can someone > please point me in the right direction for a solution to this please? This is probably a panic during lastclose(). Is drm loaded? robert. > _______________________________________________ > freebsd-x11@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-x11 > To unsubscribe, send any mail to "freebsd-x11-unsubscribe@freebsd.org" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20080809/f7b07bf7/attachment.pgp From rnoland at FreeBSD.org Sat Aug 9 21:00:46 2008 From: rnoland at FreeBSD.org (Robert Noland) Date: Sat Aug 9 21:00:52 2008 Subject: Complete System Freeze when log out of X session In-Reply-To: References: <48988A69.1000404@tiscali.co.uk> Message-ID: <1218315637.1914.14.camel@wombat.2hip.net> On Tue, 2008-08-05 at 17:20 -0600, Warren Block wrote: > On Tue, 5 Aug 2008, vangogh wrote: > > > My laptop has xorg 7.3 on Freebsd 7. > > My xorg.conf file has: > > Section "Device" > > Identifier "card0" > > Driver "vesa" > > VendorName "S3 Inc" > > BoardName "VT8375 [ProSavage8 KM266/KL266]" > > BusID "PCI:1:0:0" > > EndSection > > > > Problem is when I log out of gnome my system freezes completely and > > control+alt+backspace does not work. The keyboard becomes totally > > unresponsive and i must unplug the system to turn it off. I have searched > > this problem and seen that posts appear in the archives back in 2006 about > > this issue. However, I cannot find any solution. Can someone please point me > > in the right direction for a solution to this please? > > As I've posted twice in comp.unix.bsd.freebsd.misc: > > Try using the xf86-video-savage driver instead of vesa, and disable DRI > in xorg.conf. I don't have any of this hardware, but if someone can get me a trace of the panic, preferably with git drm modules, I can take a look... robert. > > -Warren Block * Rapid City, South Dakota USA > _______________________________________________ > freebsd-x11@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-x11 > To unsubscribe, send any mail to "freebsd-x11-unsubscribe@freebsd.org" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20080809/1d0e397a/attachment.pgp From rnoland at FreeBSD.org Sat Aug 9 21:07:47 2008 From: rnoland at FreeBSD.org (Robert Noland) Date: Sat Aug 9 21:08:00 2008 Subject: help with headless Sparc box - cannot get X and vnc running... In-Reply-To: <581dbfed0808070739p7ff40f5w63abe8f7f0897a1e@mail.gmail.com> References: <581dbfed0808070739p7ff40f5w63abe8f7f0897a1e@mail.gmail.com> Message-ID: <1218316057.1914.16.camel@wombat.2hip.net> On Thu, 2008-08-07 at 10:39 -0400, drake3 meredith wrote: > Hello, > > I am new to FreeBSD and could use some help. > I installed 7.0 on a Sun Netra T1 AC200 headless server. Installed through > serial terminal and got networking up. Installed X.org distribution and > realvnc package. When I run vncserver I get some errors in the vnc log file > and see nothing but a black screen when I connect to the session on the > sparc. > > Contents of the log file: > > Xvnc Free Edition 4.1.2 - built Aug 6 2008 06:38:59 > Copyright (C) 2002-2005 RealVNC Ltd. > See http://www.realvnc.com for information on VNC. > Underlying X server release 40300000, The XFree86 Project, Inc > > > Thu Aug 7 14:01:46 2008 > vncext: VNC extension running! > vncext: Listening for VNC connections on port 5901 > vncext: Listening for HTTP connections on port 5801 > vncext: created VNC server for screen 0 > Could not init font path element /usr/local/lib/X11/fonts/Speedo/, removing > from list! > Could not init font path element /usr/local/lib/X11/fonts/CID/, removing > from list! > Xlib: connection to ":1.0" invalid setup > xsetroot: unable to open display ':1' > Xlib: connection to ":1.0" invalid setup > twm: unable to open display ":1" > Xlib: connection to ":1.0" invalid setup > vncconfig: unable to open display ":1" > Xlib: connection to ":1.0" invalid setup > xterm Xt error: Can't open display: :1 > > [end file] > > I have deinstalled the xorg-server package and reinstalled, but same > result. I had to configure the xorg.conf file using "xorgconfig" because > the other method did not work since it is a headless unit - no display found > - could not use the console driver. > > I have searched X.org and mailing list archives for "invalid setup" message, > but cannot find anything. > > Thanks for any help - Paul. see x11-servers/xorg-vfbserver robert. _______________________________________________ > freebsd-x11@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-x11 > To unsubscribe, send any mail to "freebsd-x11-unsubscribe@freebsd.org" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20080809/c8e5d470/attachment.pgp From rnoland at 2hip.net Sat Aug 9 21:29:35 2008 From: rnoland at 2hip.net (Robert Noland) Date: Sat Aug 9 21:29:42 2008 Subject: Complete System Freeze when log out of X session In-Reply-To: <48989825.3060307@gmail.com> References: <48988A69.1000404@tiscali.co.uk> <48989825.3060307@gmail.com> Message-ID: <1218315310.1914.11.camel@wombat.2hip.net> On Tue, 2008-08-05 at 20:12 +0200, Rene Ladan wrote: > vangogh schreef: > > My laptop has xorg 7.3 on Freebsd 7. > > My xorg.conf file has: > > Section "Device" > > Identifier "card0" > > Driver "vesa" > > VendorName "S3 Inc" > > BoardName "VT8375 [ProSavage8 KM266/KL266]" > > BusID "PCI:1:0:0" > > EndSection > > > > Problem is when I log out of gnome my system freezes completely and > > control+alt+backspace does not work. The keyboard becomes totally > > unresponsive and i must unplug the system to turn it off. I have > > searched this problem and seen that posts appear in the archives back in > > 2006 about this issue. However, I cannot find any solution. Can someone > > please point me in the right direction for a solution to this please? > > > This sounds slightly familiar. I sometimes have these freezes too, > but when I'm still in xfce4. Pressing the power knob still works for me, > as well as logging in remotely via ssh. This means that only the screen > (which turns black, no backlight on) and keyboard/mouse are frozen. > > This is with an Asus A6JE, Ati Radeon X1450 running xorg 7.3 with > xf86-video-radeonhd 1.2.1. This sounds more like a gpu crash, or a deadlock in the xserver. So, I don't think that these two cases are the same. Since you can ssh in, have a look at top while it's hung and see what state the xorg process is in. If it is in drmlk2, it's locked. If that looks ok, then it's probably a gpu crash, if you set sysctl hw.dri.0.debug=1 you will probably see a lot of radeon_cp_idle and timeout calls. robert. > HTH, > Rene -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20080809/b385a394/attachment.pgp From vehemens at verizon.net Sun Aug 10 10:25:54 2008 From: vehemens at verizon.net (vehemens) Date: Sun Aug 10 10:26:01 2008 Subject: LogiTech MX Revolution Middle Button Message-ID: <200808100231.35147.vehemens@verizon.net> I have a LogiTech MX Revolution mouse and been unable to get the middle button (just behind the wheel) to work. Not sure if I'm just missing something, or that the button has simply been broken from day 1. So has anybody gotten the middle button to work? From sfourman at gmail.com Sun Aug 10 16:37:06 2008 From: sfourman at gmail.com (Sam Fourman Jr.) Date: Sun Aug 10 16:37:13 2008 Subject: LogiTech MX Revolution Middle Button In-Reply-To: <200808100231.35147.vehemens@verizon.net> References: <200808100231.35147.vehemens@verizon.net> Message-ID: <11167f520808100937g26f69678q7f8802b7ecf4fa8c@mail.gmail.com> > So has anybody gotten the middle button to work? I tried about 8 months ago to get it to work, I never could figure it out. What I can say is that in Frdora Linux 9 ther eis a option in the xorg.conf file something to the effect of evdev, I am not sure Sam Fourman Jr. From bugmaster at FreeBSD.org Mon Aug 11 11:07:12 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 11 11:09:18 2008 Subject: Current problem reports assigned to freebsd-x11@FreeBSD.org Message-ID: <200808111107.m7BB7B62047385@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- f ports/106370 x11 Screen corruption when using Direct Rendering on a PCI o ports/116359 x11 x11/xorg - screen blinks with PCI-E nvidia card and ve o ports/117195 x11 ix11/Xorg 7.3 dumps core at exit (sig 11) f ports/117508 x11 x11/xorg 7.2,7.3 i8i0 and intel crash system using Ble o ports/117766 x11 x11-servers/xorg-server (7.3) crashes under heavy load o ports/118950 x11 x11-drivers/xf86-video-nv - xorg xf86 nv (nvidia) driv o ports/119037 x11 x11: Can't type _ (Underscore) under X (gnome) f ports/119091 x11 x11-drivers/xf86-video-intel 2.1.1 panics system o ports/121360 x11 x11/xorg - Change default of ~/.xsession-errors to off o ports/122830 x11 x11/xorg: Error in I830WaitLpRing() o ports/122924 x11 XCreateImage fails in most recent x11/XOrg o ports/124220 x11 [amd64] x11-servers/xorg-server - X.org server runs in o ports/124861 x11 Keyboard problems with xorg o ports/125661 x11 x11/xorg: startx fails after a couple of attempts 14 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s ports/73743 x11 XOrg/XFree xauth add/startx problem o ports/113106 x11 x11/xorg - Xorg 7.2 + Mach64 + dri produces error mess f ports/114827 x11 Xorg server crashes when starting astro/google-earth o ports/115020 x11 New port: graphics/osmesa - Mesa's off-screen renderin s ports/115536 x11 [new port] x11/xorg-base port for a minimal X.Org inst o ports/116443 x11 x11-drivers/xf86-input-keyboard patch for USB jp106 ke f ports/116603 x11 x11/xorg server 7.3 hangs up f ports/117907 x11 x11-servers/mga_hal broken on 7.0-BETA (GLIBC error) f ports/118217 x11 xorg doesnt find usb mouse when initiated with devd, w o ports/118547 x11 [patch] x11/xdm fails with pam_krb5 o ports/118645 x11 Xorg need realtime priority for mouse work nice o ports/121230 x11 [patch] ports/x11/xkeyboard-config WITHOUT_NLS support o ports/123137 x11 x11/libX11: missing ru_RU.UTF-8 locale o ports/125883 x11 x11-fonts/xorg-fonts-cyrillic is installed, but fonts o ports/125992 x11 devel/imake: remove conflict with unexisting package 15 problems total. From StevenFriedrich at InsightBB.com Wed Aug 13 23:27:05 2008 From: StevenFriedrich at InsightBB.com (Steven Friedrich) Date: Wed Aug 13 23:27:11 2008 Subject: Matrox G550 fails to find second head, but it displays same desktop as 1st head Message-ID: <48A366FA.9000504@InsightBB.com> My dual-head used to work, but some months ago it stopped after a port update. xrandr -q only shows a default display, doesn't show multiple outputs. Possibly related to errors in Xorg.log -- Steven Friedrich Lexington, KY 40509 -------------- next part -------------- X.Org X Server 1.4.2 Release Date: 11 June 2008 X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 7.0-RELEASE-p3 i386 Current Operating System: FreeBSD freakinBSD.StevenFriedrich.org 7.0-RELEASE-p3 FreeBSD 7.0-RELEASE-p3 #78: Sat Jul 26 23:03:44 EDT 2008 root@freakinBSD.StevenFriedrich.org:/usr/obj/usr/src/sys/FREAKINBSD i386 Build Date: 02 August 2008 01:05:33PM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Wed Aug 13 18:28:58 2008 (==) Using config file: "/etc/X11/xorg.conf" (==) ServerLayout "X.org Configured" (**) |-->Screen "Screen0" (0) (**) | |-->Monitor "Monitor0" (**) | |-->Device "Card0" (**) |-->Input Device "Mouse0" (**) |-->Input Device "Keyboard0" (==) Automatically adding devices (==) Automatically enabling devices (==) Including the default font path /usr/local/lib/X11/fonts/misc/,/usr/local/lib/X11/fonts/TTF/,/usr/local/lib/X11/fonts/OTF,/usr/local/lib/X11/fonts/Type1/,/usr/local/lib/X11/fonts/100dpi/,/usr/local/lib/X11/fonts/75dpi/. (**) FontPath set to: /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF, /usr/local/lib/X11/fonts/Type1/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/, /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF, /usr/local/lib/X11/fonts/Type1/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/ (**) RgbPath set to "/usr/local/share/X11/rgb" (**) ModulePath set to "/usr/local/lib/xorg/modules" (II) Loader magic: 0x81bcd80 (II) Module ABI versions: X.Org ANSI C Emulation: 0.3 X.Org Video Driver: 2.0 X.Org XInput driver : 2.0 X.Org Server Extension : 0.3 X.Org Font Renderer : 0.5 (II) Loader running on freebsd (II) LoadModule: "pcidata" (II) Loading /usr/local/lib/xorg/modules//libpcidata.so (II) Module pcidata: vendor="X.Org Foundation" compiled for 1.4.2, module version = 1.0.0 ABI class: X.Org Video Driver, version 2.0 (--) Using syscons driver with X support (version 2.0) (--) using VT number 9 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x8000f908, mode1Res1 = 0x80000000 (WW) OS did not count PCI devices, guessing wildly From freakinBSD at insightbb.com Wed Aug 13 23:49:17 2008 From: freakinBSD at insightbb.com (Steven Friedrich) Date: Wed Aug 13 23:49:24 2008 Subject: Matrox G550 fails dual-head, used to work Message-ID: <200808131916.51687.freakinBSD@insightbb.com> Some time ago, xorg changed something and my dual-head stopped working on all my machines. I think the mga driver or xserver is having trouble detecting the second head, though it does display the same desktop as the first head. Xinerama doesn't appear to work. I built a new xorg.conf, but xrandr only says there's a default output, not two. Here's the Xorg.log (relevant part) see the last few lines... X.Org X Server 1.4.2 Release Date: 11 June 2008 X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 7.0-RELEASE-p3 i386 Current Operating System: FreeBSD freakinBSD.StevenFriedrich.org 7.0-RELEASE-p3 FreeBSD 7.0-RELEASE-p3 #78: Sat Jul 26 23:03:44 EDT 2008 root@freakinBSD.StevenFriedrich.org:/usr/obj/usr/src/sys/FREAKINBSD i386 Build Date: 02 August 2008 01:05:33PM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Wed Aug 13 18:58:53 2008 (==) Using config file: "/etc/X11/xorg.conf" (==) ServerLayout "X.org Configured" (**) |-->Screen "Screen0" (0) (**) | |-->Monitor "Monitor0" (**) | |-->Device "Card0" (**) |-->Input Device "Mouse0" (**) |-->Input Device "Keyboard0" (==) Automatically adding devices (==) Automatically enabling devices (==) Including the default font path /usr/local/lib/X11/fonts/misc/,/usr/local/lib/X11/fonts/TTF/,/usr/local/lib/X11/fonts/OTF,/usr/local/lib/X11/fonts/Type1/,/usr/local/lib/X11/fonts/100dpi/,/usr/local/lib/X11/fonts/75dpi/. (**) FontPath set to: /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF, /usr/local/lib/X11/fonts/Type1/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/, /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF, /usr/local/lib/X11/fonts/Type1/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/ (**) RgbPath set to "/usr/local/share/X11/rgb" (**) ModulePath set to "/usr/local/lib/xorg/modules" (II) Loader magic: 0x81bcd80 (II) Module ABI versions: X.Org ANSI C Emulation: 0.3 X.Org Video Driver: 2.0 X.Org XInput driver : 2.0 X.Org Server Extension : 0.3 X.Org Font Renderer : 0.5 (II) Loader running on freebsd (II) LoadModule: "pcidata" (II) Loading /usr/local/lib/xorg/modules//libpcidata.so (II) Module pcidata: vendor="X.Org Foundation" compiled for 1.4.2, module version = 1.0.0 ABI class: X.Org Video Driver, version 2.0 (--) Using syscons driver with X support (version 2.0) (--) using VT number 9 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x80021010, mode1Res1 = 0x80000000 (WW) OS did not count PCI devices, guessing wildly (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 8086,2530 card 1043,8030 rev 04 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 8086,2532 card 0000,0000 rev 04 class 06,04,00 hdr 01 (II) PCI: 00:1e:0: chip 8086,244e card 0000,0000 rev 04 class 06,04,00 hdr 01 (II) PCI: 00:1f:0: chip 8086,2440 card 0000,0000 rev 04 class 06,01,00 hdr 80 (II) PCI: 00:1f:1: chip 8086,244b card 1043,8028 rev 04 class 01,01,80 hdr 00 (II) PCI: 00:1f:2: chip 8086,2442 card 1043,8028 rev 04 class 0c,03,00 hdr 00 (II) PCI: 00:1f:4: chip 8086,2444 card 1043,8028 rev 04 class 0c,03,00 hdr 00 (II) PCI: 01:00:0: chip 102b,2527 card 102b,0f84 rev 01 class 03,00,00 hdr 00 (II) PCI: 02:02:0: chip 105a,5275 card 1043,807e rev 01 class 01,04,85 hdr 00 (II) PCI: 02:03:0: chip 13f6,0111 card 1043,80e2 rev 10 class 04,01,00 hdr 00 (II) PCI: 02:04:0: chip 1033,0035 card 807d,0035 rev 41 class 0c,03,10 hdr 80 (II) PCI: 02:04:1: chip 1033,0035 card 807d,0035 rev 41 class 0c,03,10 hdr 00 (II) PCI: 02:04:2: chip 1033,00e0 card 807d,1043 rev 02 class 0c,03,20 hdr 00 (II) PCI: 02:0d:0: chip 1317,0985 card 1317,0574 rev 11 class 02,00,00 hdr 00 (II) PCI: End of PCI scan (II) Intel Bridge workaround enabled (II) Host-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (0,0,2), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B] (II) Bus 0 prefetchable memory range: [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B] (II) PCI-to-PCI bridge: (II) Bus 1: bridge is at (0:1:0), (0,1,1), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 1 non-prefetchable memory range: [0] -1 0 0xf4800000 - 0xf5dfffff (0x1600000) MX[B] (II) Bus 1 prefetchable memory range: [0] -1 0 0xf5f00000 - 0xf7ffffff (0x2100000) MX[B] (II) Subtractive PCI-to-PCI bridge: (II) Bus 2: bridge is at (0:30:0), (0,2,2), BCTRL: 0x0006 (VGA_EN is cleared) (II) Bus 2 I/O range: [0] -1 0 0x0000a000 - 0x0000a0ff (0x100) IX[B] [1] -1 0 0x0000a400 - 0x0000a4ff (0x100) IX[B] [2] -1 0 0x0000a800 - 0x0000a8ff (0x100) IX[B] [3] -1 0 0x0000ac00 - 0x0000acff (0x100) IX[B] [4] -1 0 0x0000b000 - 0x0000b0ff (0x100) IX[B] [5] -1 0 0x0000b400 - 0x0000b4ff (0x100) IX[B] [6] -1 0 0x0000b800 - 0x0000b8ff (0x100) IX[B] [7] -1 0 0x0000bc00 - 0x0000bcff (0x100) IX[B] [8] -1 0 0x0000c000 - 0x0000c0ff (0x100) IX[B] [9] -1 0 0x0000c400 - 0x0000c4ff (0x100) IX[B] [10] -1 0 0x0000c800 - 0x0000c8ff (0x100) IX[B] [11] -1 0 0x0000cc00 - 0x0000ccff (0x100) IX[B] [12] -1 0 0x0000d000 - 0x0000d0ff (0x100) IX[B] [13] -1 0 0x0000d400 - 0x0000d4ff (0x100) IX[B] [14] -1 0 0x0000d800 - 0x0000d8ff (0x100) IX[B] [15] -1 0 0x0000dc00 - 0x0000dcff (0x100) IX[B] (II) Bus 2 non-prefetchable memory range: [0] -1 0 0xf2000000 - 0xf47fffff (0x2800000) MX[B] (II) Bus 2 prefetchable memory range: [0] -1 0 0xf5e00000 - 0xf5efffff (0x100000) MX[B] (II) PCI-to-ISA bridge: (II) Bus -1: bridge is at (0:31:0), (0,-1,-1), BCTRL: 0x0008 (VGA_EN is set) (--) PCI:*(1:0:0) Matrox Graphics, Inc. MGA G550 AGP rev 1, Mem @ 0xf6000000/25, 0xf5000000/14, 0xf4800000/23, BIOS @ 0xf5fe0000/17 (II) Addressable bus resource ranges are [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B] [1] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B] (II) OS-reported resource ranges: [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [5] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (II) PCI Memory resource overlap reduced 0xf8000000 from 0xffffffff to 0xf7ffffff (II) Active PCI resource ranges: [0] -1 0 0xf2000000 - 0xf3ffffff (0x2000000) MX[B]E [1] -1 0 0xf2800000 - 0xf2ffffff (0x800000) MX[B]E [2] -1 0 0xf3000000 - 0xf3ffffff (0x1000000) MX[B]E [3] -1 0 0xf3800000 - 0xf3ffffff (0x800000) MX[B]E [4] -1 0 0xf4000000 - 0xf7ffffff (0x4000000) MX[B]E [5] -1 0 0xf8000000 - 0xf7ffffff (0x0) MX[B]EO [6] -1 0 0xf5fe0000 - 0xf5ffffff (0x20000) MX[B](B) [7] -1 0 0xf4800000 - 0xf4ffffff (0x800000) MX[B](B) [8] -1 0 0xf5000000 - 0xf5003fff (0x4000) MX[B](B) [9] -1 0 0xf6000000 - 0xf7ffffff (0x2000000) MX[B](B) [10] -1 0 0x0000a800 - 0x0000a8ff (0x100) IX[B]E [11] -1 0 0x0000b000 - 0x0000b0ff (0x100) IX[B]E [12] -1 0 0x0000b400 - 0x0000b4ff (0x100) IX[B]E [13] -1 0 0x0000b800 - 0x0000b8ff (0x100) IX[B]E [14] -1 0 0x0000d000 - 0x0000d0ff (0x100) IX[B]E [15] -1 0 0x0000d400 - 0x0000d4ff (0x100) IX[B]E [16] -1 0 0x0000d800 - 0x0000d8ff (0x100) IX[B]E [17] -1 0 0x00009000 - 0x000090ff (0x100) IX[B]E [18] -1 0 0x00009400 - 0x000094ff (0x100) IX[B]E [19] -1 0 0x00009800 - 0x000098ff (0x100) IX[B]E (II) PCI Memory resource overlap reduced 0xf2000000 from 0xf3ffffff to 0xf27fffff (II) PCI Memory resource overlap reduced 0xf3000000 from 0xf3ffffff to 0xf37fffff (II) PCI Memory resource overlap reduced 0xf4000000 from 0xf7ffffff to 0xf47fffff (II) Active PCI resource ranges after removing overlaps: [0] -1 0 0xf2000000 - 0xf27fffff (0x800000) MX[B]E [1] -1 0 0xf2800000 - 0xf2ffffff (0x800000) MX[B]E [2] -1 0 0xf3000000 - 0xf37fffff (0x800000) MX[B]E [3] -1 0 0xf3800000 - 0xf3ffffff (0x800000) MX[B]E [4] -1 0 0xf4000000 - 0xf47fffff (0x800000) MX[B]E [5] -1 0 0xf8000000 - 0xf7ffffff (0x0) MX[B]EO [6] -1 0 0xf5fe0000 - 0xf5ffffff (0x20000) MX[B](B) [7] -1 0 0xf4800000 - 0xf4ffffff (0x800000) MX[B](B) [8] -1 0 0xf5000000 - 0xf5003fff (0x4000) MX[B](B) [9] -1 0 0xf6000000 - 0xf7ffffff (0x2000000) MX[B](B) [10] -1 0 0x0000a800 - 0x0000a8ff (0x100) IX[B]E [11] -1 0 0x0000b000 - 0x0000b0ff (0x100) IX[B]E [12] -1 0 0x0000b400 - 0x0000b4ff (0x100) IX[B]E [13] -1 0 0x0000b800 - 0x0000b8ff (0x100) IX[B]E [14] -1 0 0x0000d000 - 0x0000d0ff (0x100) IX[B]E [15] -1 0 0x0000d400 - 0x0000d4ff (0x100) IX[B]E [16] -1 0 0x0000d800 - 0x0000d8ff (0x100) IX[B]E [17] -1 0 0x00009000 - 0x000090ff (0x100) IX[B]E [18] -1 0 0x00009400 - 0x000094ff (0x100) IX[B]E [19] -1 0 0x00009800 - 0x000098ff (0x100) IX[B]E (II) OS-reported resource ranges after removing overlaps with PCI: [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [5] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (II) All system resource ranges: [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0xf2000000 - 0xf27fffff (0x800000) MX[B]E [5] -1 0 0xf2800000 - 0xf2ffffff (0x800000) MX[B]E [6] -1 0 0xf3000000 - 0xf37fffff (0x800000) MX[B]E [7] -1 0 0xf3800000 - 0xf3ffffff (0x800000) MX[B]E [8] -1 0 0xf4000000 - 0xf47fffff (0x800000) MX[B]E [9] -1 0 0xf8000000 - 0xf7ffffff (0x0) MX[B]EO [10] -1 0 0xf5fe0000 - 0xf5ffffff (0x20000) MX[B](B) [11] -1 0 0xf4800000 - 0xf4ffffff (0x800000) MX[B](B) [12] -1 0 0xf5000000 - 0xf5003fff (0x4000) MX[B](B) [13] -1 0 0xf6000000 - 0xf7ffffff (0x2000000) MX[B](B) [14] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [15] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [16] -1 0 0x0000a800 - 0x0000a8ff (0x100) IX[B]E [17] -1 0 0x0000b000 - 0x0000b0ff (0x100) IX[B]E [18] -1 0 0x0000b400 - 0x0000b4ff (0x100) IX[B]E [19] -1 0 0x0000b800 - 0x0000b8ff (0x100) IX[B]E [20] -1 0 0x0000d000 - 0x0000d0ff (0x100) IX[B]E [21] -1 0 0x0000d400 - 0x0000d4ff (0x100) IX[B]E [22] -1 0 0x0000d800 - 0x0000d8ff (0x100) IX[B]E [23] -1 0 0x00009000 - 0x000090ff (0x100) IX[B]E [24] -1 0 0x00009400 - 0x000094ff (0x100) IX[B]E [25] -1 0 0x00009800 - 0x000098ff (0x100) IX[B]E (II) "extmod" will be loaded. This was enabled by default and also specified in the config file. (II) "dbe" will be loaded. This was enabled by default and also specified in the config file. (II) "glx" will be loaded. This was enabled by default and also specified in the config file. (II) "freetype" will be loaded. This was enabled by default and also specified in the config file. (II) "type1" will be loaded. This was enabled by default and also specified in the config file. (II) "record" will be loaded. This was enabled by default and also specified in the config file. (II) "dri" will be loaded. This was enabled by default and also specified in the config file. (II) LoadModule: "extmod" (II) Loading /usr/local/lib/xorg/modules/extensions//libextmod.so (II) Module extmod: vendor="X.Org Foundation" compiled for 1.4.2, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 0.3 (II) Loading extension SHAPE (II) Loading extension MIT-SUNDRY-NONSTANDARD (II) Loading extension BIG-REQUESTS (II) Loading extension SYNC (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XC-MISC (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-Misc (II) Loading extension XFree86-DGA (II) Loading extension DPMS (II) Loading extension TOG-CUP (II) Loading extension Extended-Visual-Information (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: "record" (II) Loading /usr/local/lib/xorg/modules/extensions//librecord.so (II) Module record: vendor="X.Org Foundation" compiled for 1.4.2, module version = 1.13.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 0.3 (II) Loading extension RECORD (II) LoadModule: "dbe" (II) Loading /usr/local/lib/xorg/modules/extensions//libdbe.so (II) Module dbe: vendor="X.Org Foundation" compiled for 1.4.2, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 0.3 (II) Loading extension DOUBLE-BUFFER (II) LoadModule: "glx" (II) Loading /usr/local/lib/xorg/modules/extensions//libglx.so (II) Module glx: vendor="X.Org Foundation" compiled for 1.4.2, module version = 1.0.0 ABI class: X.Org Server Extension, version 0.3 (==) AIGLX disabled (II) Loading extension GLX (II) LoadModule: "xtrap" (II) Loading /usr/local/lib/xorg/modules/extensions//libxtrap.so (II) Module xtrap: vendor="X.Org Foundation" compiled for 1.4.2, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 0.3 (II) Loading extension DEC-XTRAP (II) LoadModule: "dri" (II) Loading /usr/local/lib/xorg/modules/extensions//libdri.so (II) Module dri: vendor="X.Org Foundation" compiled for 1.4.2, module version = 1.0.0 ABI class: X.Org Server Extension, version 0.3 (II) Loading extension XFree86-DRI (II) LoadModule: "freetype" (II) Loading /usr/local/lib/xorg/modules/fonts//libfreetype.so (II) Module freetype: vendor="X.Org Foundation & the After X-TT Project" compiled for 1.4.2, module version = 2.1.0 Module class: X.Org Font Renderer ABI class: X.Org Font Renderer, version 0.5 (II) Loading font FreeType (II) LoadModule: "type1" (II) Loading /usr/local/lib/xorg/modules/fonts//libtype1.so (II) Module type1: vendor="X.Org Foundation" compiled for 1.4.2, module version = 1.0.2 Module class: X.Org Font Renderer ABI class: X.Org Font Renderer, version 0.5 (II) Loading font Type1 (II) LoadModule: "mga" (II) Loading /usr/local/lib/xorg/modules/drivers//mga_drv.so (II) Module mga: vendor="X.Org Foundation" compiled for 1.4.2, module version = 1.4.7 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 2.0 (II) LoadModule: "mouse" (II) Loading /usr/local/lib/xorg/modules/input//mouse_drv.so (II) Module mouse: vendor="X.Org Foundation" compiled for 1.4.2, module version = 1.2.3 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 2.0 (II) LoadModule: "kbd" (II) Loading /usr/local/lib/xorg/modules/input//kbd_drv.so (II) Module kbd: vendor="X.Org Foundation" compiled for 1.4.2, module version = 1.2.2 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 2.0 (II) MGA: driver for Matrox chipsets: mga2064w, mga1064sg, mga2164w, mga2164w AGP, mgag100, mgag100 PCI, mgag200, mgag200 PCI, mgag200 SE A PCI, mgag200 SE B PCI, mgag400, mgag550 (II) Primary Device is: PCI 01:00:0 (--) Chipset mgag550 found (II) resource ranges after xf86ClaimFixedResources() call: [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0xf2000000 - 0xf27fffff (0x800000) MX[B]E [5] -1 0 0xf2800000 - 0xf2ffffff (0x800000) MX[B]E [6] -1 0 0xf3000000 - 0xf37fffff (0x800000) MX[B]E [7] -1 0 0xf3800000 - 0xf3ffffff (0x800000) MX[B]E [8] -1 0 0xf4000000 - 0xf47fffff (0x800000) MX[B]E [9] -1 0 0xf8000000 - 0xf7ffffff (0x0) MX[B]EO [10] -1 0 0xf5fe0000 - 0xf5ffffff (0x20000) MX[B](B) [11] -1 0 0xf4800000 - 0xf4ffffff (0x800000) MX[B](B) [12] -1 0 0xf5000000 - 0xf5003fff (0x4000) MX[B](B) [13] -1 0 0xf6000000 - 0xf7ffffff (0x2000000) MX[B](B) [14] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [15] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [16] -1 0 0x0000a800 - 0x0000a8ff (0x100) IX[B]E [17] -1 0 0x0000b000 - 0x0000b0ff (0x100) IX[B]E [18] -1 0 0x0000b400 - 0x0000b4ff (0x100) IX[B]E [19] -1 0 0x0000b800 - 0x0000b8ff (0x100) IX[B]E [20] -1 0 0x0000d000 - 0x0000d0ff (0x100) IX[B]E [21] -1 0 0x0000d400 - 0x0000d4ff (0x100) IX[B]E [22] -1 0 0x0000d800 - 0x0000d8ff (0x100) IX[B]E [23] -1 0 0x00009000 - 0x000090ff (0x100) IX[B]E [24] -1 0 0x00009400 - 0x000094ff (0x100) IX[B]E [25] -1 0 0x00009800 - 0x000098ff (0x100) IX[B]E (II) resource ranges after probing: [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0xf2000000 - 0xf27fffff (0x800000) MX[B]E [5] -1 0 0xf2800000 - 0xf2ffffff (0x800000) MX[B]E [6] -1 0 0xf3000000 - 0xf37fffff (0x800000) MX[B]E [7] -1 0 0xf3800000 - 0xf3ffffff (0x800000) MX[B]E [8] -1 0 0xf4000000 - 0xf47fffff (0x800000) MX[B]E [9] -1 0 0xf8000000 - 0xf7ffffff (0x0) MX[B]EO [10] -1 0 0xf5fe0000 - 0xf5ffffff (0x20000) MX[B](B) [11] -1 0 0xf4800000 - 0xf4ffffff (0x800000) MX[B](B) [12] -1 0 0xf5000000 - 0xf5003fff (0x4000) MX[B](B) [13] -1 0 0xf6000000 - 0xf7ffffff (0x2000000) MX[B](B) [14] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B] [15] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B] [16] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B] [17] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [18] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [19] -1 0 0x0000a800 - 0x0000a8ff (0x100) IX[B]E [20] -1 0 0x0000b000 - 0x0000b0ff (0x100) IX[B]E [21] -1 0 0x0000b400 - 0x0000b4ff (0x100) IX[B]E [22] -1 0 0x0000b800 - 0x0000b8ff (0x100) IX[B]E [23] -1 0 0x0000d000 - 0x0000d0ff (0x100) IX[B]E [24] -1 0 0x0000d400 - 0x0000d4ff (0x100) IX[B]E [25] -1 0 0x0000d800 - 0x0000d8ff (0x100) IX[B]E [26] -1 0 0x00009000 - 0x000090ff (0x100) IX[B]E [27] -1 0 0x00009400 - 0x000094ff (0x100) IX[B]E [28] -1 0 0x00009800 - 0x000098ff (0x100) IX[B]E [29] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B] [30] 0 0 0x000003c0 - 0x000003df (0x20) IS[B] (II) Setting vga for screen 0. (II) Loading sub module "vgahw" (II) LoadModule: "vgahw" (II) Loading /usr/local/lib/xorg/modules//libvgahw.so (II) Module vgahw: vendor="X.Org Foundation" compiled for 1.4.2, module version = 0.1.0 ABI class: X.Org Video Driver, version 2.0 (--) MGA(0): Chipset: "mgag550" (==) MGA(0): Depth 24, (==) framebuffer bpp 32 (==) MGA(0): RGB weight 888 (==) MGA(0): Using AGP 1x mode (==) MGA(0): Using XAA acceleration (--) MGA(0): Linear framebuffer at 0xF6000000 (==) MGA(0): MMIO registers at 0xF5000000 (--) MGA(0): Pseudo-DMA transfer window at 0xF4800000 (--) MGA(0): BIOS at 0xF5FE0000 Requesting insufficient memory window!: start: 0xf4800000 end: 0xf5dfffff size 0x2000000 (EE) Cannot find empty range to map base to (WW) MGA(0): Video BIOS info block not detected! From rnoland at FreeBSD.org Thu Aug 14 01:04:13 2008 From: rnoland at FreeBSD.org (Robert Noland) Date: Thu Aug 14 01:04:19 2008 Subject: [CFT] drm updates Message-ID: <1218675844.1899.18.camel@wombat.2hip.net> I have prepared a set of patches for drm kernel modules against -CURRENT and -STABLE. I would like to get this into HEAD fairly soon. This update has the latest vblank rework bits in it, so if you have hardware that can disable vblank irq's (radeon, intel) you should see the irq counts drop if there are no vblank consumers running. i915 suspend/resume support is included. For Intel, this should pick up support for the g33 chipsets as well. Lots of other fixes here and there... The patches are located at http://people.freebsd.org/~rnoland robert. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20080814/f8e0cd9b/attachment.pgp From alex.wilkinson at dsto.defence.gov.au Thu Aug 14 01:27:02 2008 From: alex.wilkinson at dsto.defence.gov.au (Wilkinson, Alex) Date: Thu Aug 14 01:27:09 2008 Subject: [CFT] drm updates In-Reply-To: <1218675844.1899.18.camel@wombat.2hip.net> References: <1218675844.1899.18.camel@wombat.2hip.net> Message-ID: <20080814010535.GN98754@stlux503.dsto.defence.gov.au> 0n Wed, Aug 13, 2008 at 09:04:04PM -0400, Robert Noland wrote: >This update has the latest vblank rework bits in it, so if you have >hardware that can disable vblank irq's (radeon, intel) you should see >the irq counts drop if there are no vblank consumers running. what is meant by "vblank" ? -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From rnoland at 2hip.net Thu Aug 14 01:29:02 2008 From: rnoland at 2hip.net (Robert Noland) Date: Thu Aug 14 01:29:09 2008 Subject: [CFT] drm updates In-Reply-To: <20080814010535.GN98754@stlux503.dsto.defence.gov.au> References: <1218675844.1899.18.camel@wombat.2hip.net> <20080814010535.GN98754@stlux503.dsto.defence.gov.au> Message-ID: <1218677322.1899.20.camel@wombat.2hip.net> On Thu, 2008-08-14 at 09:05 +0800, Wilkinson, Alex wrote: > 0n Wed, Aug 13, 2008 at 09:04:04PM -0400, Robert Noland wrote: > > >This update has the latest vblank rework bits in it, so if you have > >hardware that can disable vblank irq's (radeon, intel) you should see > >the irq counts drop if there are no vblank consumers running. > > what is meant by "vblank" ? vertical blank. robert. > -aW > > IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. > > > _______________________________________________ > freebsd-x11@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-x11 > To unsubscribe, send any mail to "freebsd-x11-unsubscribe@freebsd.org" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20080814/b889f2de/attachment.pgp From edwin at FreeBSD.org Thu Aug 14 03:10:15 2008 From: edwin at FreeBSD.org (edwin@FreeBSD.org) Date: Thu Aug 14 03:10:21 2008 Subject: ports/126521: [PATCH] graphics/libdrm: update to 2.3.1 Message-ID: <200808140310.m7E3AFr8075357@freefall.freebsd.org> Synopsis: [PATCH] graphics/libdrm: update to 2.3.1 Responsible-Changed-From-To: freebsd-ports-bugs->freebsd-x11 Responsible-Changed-By: edwin Responsible-Changed-When: Thu Aug 14 03:10:15 UTC 2008 Responsible-Changed-Why: Over to maintainer (via the GNATS Auto Assign Tool) http://www.freebsd.org/cgi/query-pr.cgi?pr=126521 From wblock at wonkity.com Thu Aug 14 03:21:33 2008 From: wblock at wonkity.com (Warren Block) Date: Thu Aug 14 03:21:39 2008 Subject: Matrox G550 fails dual-head, used to work In-Reply-To: <200808131916.51687.freakinBSD@insightbb.com> References: <200808131916.51687.freakinBSD@insightbb.com> Message-ID: On Wed, 13 Aug 2008, Steven Friedrich wrote: > Some time ago, xorg changed something and my dual-head stopped working on all > my machines. > > I think the mga driver or xserver is having trouble detecting the second head, > though it does display the same desktop as the first head. Xinerama doesn't > appear to work. I built a new xorg.conf, but xrandr only says there's a > default output, not two. If you want dual head on a Matrox card with the latest ported xorg-server, you need xf86-video-mga-1.9.100. That version of the driver was in ports for a while, but people using modelines had trouble and it was backed out. You can use portdowngrade to get 1.9.100. Additionally, you need to patch xorg-server so it can read the Matrox video BIOS. G550 with two VGA ports should work, I think. G550 with DVI, maybe not. Documentation here: http://wonkity.com/~wblock/mgapatch/ -Warren Block * Rapid City, South Dakota USA From rnoland at freebsd.org Thu Aug 14 03:30:40 2008 From: rnoland at freebsd.org (Robert Noland) Date: Thu Aug 14 03:30:47 2008 Subject: [PATCH] graphics/libdrm: update to 2.3.1 Message-ID: <200808140300.m7E30P5G017388@wombat.2hip.net> >Submitter-Id: current-users >Originator: Robert Noland >Organization: >Confidential: no >Synopsis: [PATCH] graphics/libdrm: update to 2.3.1 >Severity: non-critical >Priority: low >Category: ports >Class: update >Release: FreeBSD 8.0-CURRENT i386 >Environment: System: FreeBSD wombat.2hip.net 8.0-CURRENT FreeBSD 8.0-CURRENT #20: Wed Aug 13 17:25:35 EDT 2008 >Description: - Update to 2.3.1 Port maintainer (x11@FreeBSD.org) is cc'd. Generated with FreeBSD Port Tools 0.77 >How-To-Repeat: >Fix: --- libdrm-2.3.1.patch begins here --- Index: Makefile =================================================================== RCS file: /home/ncvs/ports/graphics/libdrm/Makefile,v retrieving revision 1.9 diff -u -r1.9 Makefile --- Makefile 29 May 2008 14:17:03 -0000 1.9 +++ Makefile 14 Aug 2008 02:53:52 -0000 @@ -6,7 +6,7 @@ # PORTNAME= libdrm -PORTVERSION= 2.3.0 +PORTVERSION= 2.3.1 CATEGORIES= graphics x11 MASTER_SITES= http://dri.freedesktop.org/libdrm/ Index: distinfo =================================================================== RCS file: /home/ncvs/ports/graphics/libdrm/distinfo,v retrieving revision 1.5 diff -u -r1.5 distinfo --- distinfo 29 May 2008 14:17:03 -0000 1.5 +++ distinfo 14 Aug 2008 02:53:52 -0000 @@ -1,3 +1,3 @@ -MD5 (libdrm-2.3.0.tar.bz2) = 01a1e1ee0268a2403db42fa630036ab2 -SHA256 (libdrm-2.3.0.tar.bz2) = f8c711427fea50845811360c92f6350ff3dacb9533741470d54ae5d0a2f6848e -SIZE (libdrm-2.3.0.tar.bz2) = 267949 +MD5 (libdrm-2.3.1.tar.bz2) = 620fe7dd02c3236c3e9881a3a238173d +SHA256 (libdrm-2.3.1.tar.bz2) = ddfd398383729707846e1f1689e9acb3bc672e4f255a632c8f0d0c55ddf8718c +SIZE (libdrm-2.3.1.tar.bz2) = 306013 Index: pkg-plist =================================================================== RCS file: /home/ncvs/ports/graphics/libdrm/pkg-plist,v retrieving revision 1.4 diff -u -r1.4 pkg-plist --- pkg-plist 19 May 2007 20:09:46 -0000 1.4 +++ pkg-plist 14 Aug 2008 02:53:52 -0000 @@ -11,7 +11,6 @@ include/drm/via_3d_reg.h include/drm/via_drm.h include/xf86drm.h -include/xf86mm.h lib/libdrm.la lib/libdrm.so lib/libdrm.so.2 --- libdrm-2.3.1.patch ends here --- From pfgshield-freebsd at yahoo.com Thu Aug 14 04:10:04 2008 From: pfgshield-freebsd at yahoo.com (Pedro Giffuni) Date: Thu Aug 14 04:10:18 2008 Subject: ports/115020: New port: graphics/osmesa - Mesa's off-screen rendering interface Message-ID: <200808140410.m7E4A3co081929@freefall.freebsd.org> The following reply was made to PR ports/115020; it has been noted by GNATS. From: Pedro Giffuni To: bug-followup@FreeBSD.org Cc: flz@FreeBSD.org Subject: Re: ports/115020: New port: graphics/osmesa - Mesa's off-screen rendering interface Date: Wed, 13 Aug 2008 21:03:01 -0700 (PDT) Hello; Some more feedback ... I was indeed wondering about an OSMesa port since I need it for VTK5 as the= default instead of using Mangled Mesa. It is useful for Paraview : http://www.vtk.org/Wiki/Setting_up_a_ParaView_Server#OSMesa_support Pedro. =0A=0A=0A Posta, news, sport, oroscopo: tutto in una sola pagina. =0AC= rea l'home page che piace a te!=0Awww.yahoo.it/latuapagina From r.c.ladan at gmail.com Thu Aug 14 06:29:51 2008 From: r.c.ladan at gmail.com (Rene Ladan) Date: Thu Aug 14 06:29:57 2008 Subject: [CFT] drm updates In-Reply-To: <1218675844.1899.18.camel@wombat.2hip.net> References: <1218675844.1899.18.camel@wombat.2hip.net> Message-ID: <48A3D0DA.9090106@gmail.com> Robert Noland schreef: > I have prepared a set of patches for drm kernel modules against -CURRENT > and -STABLE. I would like to get this into HEAD fairly soon. > > This update has the latest vblank rework bits in it, so if you have > hardware that can disable vblank irq's (radeon, intel) you should see > the irq counts drop if there are no vblank consumers running. > drm-fix-master.patch isn't yet pushed into libdrm, right? Your latest commit was 7a3d6624c47d87bdd46f5394b8cc5130c7a4ed0d on 2008-07-25 [...] > The patches are located at http://people.freebsd.org/~rnoland > Is this different than the latest code in libdrm/bsd-core? Regards, Rene -- http://www.rene-ladan.nl/ GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) From r.c.ladan at gmail.com Thu Aug 14 07:49:17 2008 From: r.c.ladan at gmail.com (Rene Ladan) Date: Thu Aug 14 07:49:24 2008 Subject: [PATCH] graphics/libdrm: update to 2.3.1 In-Reply-To: <200808140300.m7E30P5G017388@wombat.2hip.net> References: <200808140300.m7E30P5G017388@wombat.2hip.net> Message-ID: [leaving out freebsd-gnats-submit] 2008/8/14 Robert Noland : > >>Submitter-Id: current-users >>Originator: Robert Noland >>Organization: >>Confidential: no >>Synopsis: [PATCH] graphics/libdrm: update to 2.3.1 >>Severity: non-critical >>Priority: low >>Category: ports >>Class: update >>Release: FreeBSD 8.0-CURRENT i386 >>Environment: > System: FreeBSD wombat.2hip.net 8.0-CURRENT FreeBSD 8.0-CURRENT #20: Wed Aug 13 17:25:35 EDT 2008 >>Description: > - Update to 2.3.1 > [snip patch] I'm running libdrm from git on my box (7.0R amd64) with xorg from ports and xf86-video-radeonhd from git (ATI M64). Last time I tested astro/stellarium, the colors were wrong, but back in May/June they were correct. This might also be an issue with radeonhd or dri. No update to libdrm 2.4.0 yet? Regards, Rene -- http://www.rene-ladan.nl/ GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) From kostikbel at gmail.com Thu Aug 14 13:20:57 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Thu Aug 14 13:21:04 2008 Subject: [CFT] drm updates In-Reply-To: <1218675844.1899.18.camel@wombat.2hip.net> References: <1218675844.1899.18.camel@wombat.2hip.net> Message-ID: <20080814125226.GO1803@deviant.kiev.zoral.com.ua> On Wed, Aug 13, 2008 at 09:04:04PM -0400, Robert Noland wrote: > I have prepared a set of patches for drm kernel modules against -CURRENT > and -STABLE. I would like to get this into HEAD fairly soon. > > This update has the latest vblank rework bits in it, so if you have > hardware that can disable vblank irq's (radeon, intel) you should see > the irq counts drop if there are no vblank consumers running. > > i915 suspend/resume support is included. > > For Intel, this should pick up support for the g33 chipsets as well. > > Lots of other fixes here and there... > > The patches are located at http://people.freebsd.org/~rnoland > > robert. > I quickly looked over i915 drm. Cosmetic thing is that i915_initialize() defines variable ret inside code block. On the not-so cosmetic side, it seems that i915 driver still accesses user memory while holding mutex. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20080814/787ac5b8/attachment.pgp From rnoland at FreeBSD.org Thu Aug 14 15:52:05 2008 From: rnoland at FreeBSD.org (Robert Noland) Date: Thu Aug 14 15:52:17 2008 Subject: [CFT] drm updates In-Reply-To: <48A3D0DA.9090106@gmail.com> References: <1218675844.1899.18.camel@wombat.2hip.net> <48A3D0DA.9090106@gmail.com> Message-ID: <1218729113.6077.12.camel@squirrel.corp.cox.com> On Thu, 2008-08-14 at 08:29 +0200, Rene Ladan wrote: > Robert Noland schreef: > > I have prepared a set of patches for drm kernel modules against -CURRENT > > and -STABLE. I would like to get this into HEAD fairly soon. > > > > This update has the latest vblank rework bits in it, so if you have > > hardware that can disable vblank irq's (radeon, intel) you should see > > the irq counts drop if there are no vblank consumers running. > > > drm-fix-master.patch isn't yet pushed into libdrm, right? Your latest > commit was 7a3d6624c47d87bdd46f5394b8cc5130c7a4ed0d on 2008-07-25 While that patch was fine on bsd... I was getting a bit of push-back as it required minor changes on the linux side. The gem code was pushed into git master last weekend, which totally broke the build of at least the intel driver. For this, I've drawn a line in the sand to try and get an update in at least -CURRENT. The changes that were required to prevent the vt switch panic are rolled up in this changeset. Finally, there is a push to move drm development into a linux kernel tree and I'm not sure how I am going to try and deal with that if it officially happens. For now, at least gem is being developed outside of drm.git and then merged. If the change takes place, I may end up moving development to a private repo, or just working in our src tree. That makes some things easier, while other things (merging and tracking changes) will become more difficult. We will just have to see how it plays out. Anyway, this changeset is split from drm.git just prior to the gem merge, with a few additional patches added. robert. > [...] > > The patches are located at http://people.freebsd.org/~rnoland > > > Is this different than the latest code in libdrm/bsd-core? > > Regards, > Rene -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20080814/b3efaac7/attachment.pgp From cokane at FreeBSD.org Thu Aug 14 16:16:40 2008 From: cokane at FreeBSD.org (Coleman Kane) Date: Thu Aug 14 16:17:09 2008 Subject: [CFT] drm updates In-Reply-To: <1218675844.1899.18.camel@wombat.2hip.net> References: <1218675844.1899.18.camel@wombat.2hip.net> Message-ID: <1218729645.11432.0.camel@localhost> On Wed, 2008-08-13 at 21:04 -0400, Robert Noland wrote: > I have prepared a set of patches for drm kernel modules against -CURRENT > and -STABLE. I would like to get this into HEAD fairly soon. > > This update has the latest vblank rework bits in it, so if you have > hardware that can disable vblank irq's (radeon, intel) you should see > the irq counts drop if there are no vblank consumers running. > > i915 suspend/resume support is included. > > For Intel, this should pick up support for the g33 chipsets as well. > > Lots of other fixes here and there... > > The patches are located at http://people.freebsd.org/~rnoland > > robert. > Robert, Are these patches just snapshots of code currently in git master, or do they also include fixes pending commit to git master as well? -- Coleman Kane -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20080814/1eb48e18/attachment.pgp From rnoland at FreeBSD.org Thu Aug 14 16:30:49 2008 From: rnoland at FreeBSD.org (Robert Noland) Date: Thu Aug 14 16:31:01 2008 Subject: [PATCH] graphics/libdrm: update to 2.3.1 In-Reply-To: References: <200808140300.m7E30P5G017388@wombat.2hip.net> Message-ID: <1218729457.6077.18.camel@squirrel.corp.cox.com> On Thu, 2008-08-14 at 09:20 +0200, Rene Ladan wrote: > [leaving out freebsd-gnats-submit] > > 2008/8/14 Robert Noland : > > > >>Submitter-Id: current-users > >>Originator: Robert Noland > >>Organization: > >>Confidential: no > >>Synopsis: [PATCH] graphics/libdrm: update to 2.3.1 > >>Severity: non-critical > >>Priority: low > >>Category: ports > >>Class: update > >>Release: FreeBSD 8.0-CURRENT i386 > >>Environment: > > System: FreeBSD wombat.2hip.net 8.0-CURRENT FreeBSD 8.0-CURRENT #20: Wed Aug 13 17:25:35 EDT 2008 > >>Description: > > - Update to 2.3.1 > > > [snip patch] > > I'm running libdrm from git on my box (7.0R amd64) with xorg from > ports and xf86-video-radeonhd from git (ATI M64). > Last time I tested astro/stellarium, the colors were wrong, but back > in May/June they were correct. This might also > be an issue with radeonhd or dri. > > No update to libdrm 2.4.0 yet? libdrm 2.3.1 gets us the modesetting ioctl's that we need to allow vblank irqs to be disabled. With 2.3.0, the irqs will always remain active as they used to. I'm not sure if it is going to be 2.3.2 or 2.4.0, but the next cut has the gem changes in it... I don't think that those changes break libdrm for us, but they don't help us at all either. robert. > Regards, > Rene -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20080814/4e5fba95/attachment.pgp From rnoland at FreeBSD.org Thu Aug 14 16:35:26 2008 From: rnoland at FreeBSD.org (Robert Noland) Date: Thu Aug 14 16:35:32 2008 Subject: [CFT] drm updates In-Reply-To: <1218729645.11432.0.camel@localhost> References: <1218675844.1899.18.camel@wombat.2hip.net> <1218729645.11432.0.camel@localhost> Message-ID: <1218731717.6077.27.camel@squirrel.corp.cox.com> On Thu, 2008-08-14 at 12:00 -0400, Coleman Kane wrote: > On Wed, 2008-08-13 at 21:04 -0400, Robert Noland wrote: > > I have prepared a set of patches for drm kernel modules against -CURRENT > > and -STABLE. I would like to get this into HEAD fairly soon. > > > > This update has the latest vblank rework bits in it, so if you have > > hardware that can disable vblank irq's (radeon, intel) you should see > > the irq counts drop if there are no vblank consumers running. > > > > i915 suspend/resume support is included. > > > > For Intel, this should pick up support for the g33 chipsets as well. > > > > Lots of other fixes here and there... > > > > The patches are located at http://people.freebsd.org/~rnoland > > > > robert. > > > > Robert, > > Are these patches just snapshots of code currently in git master, or do > they also include fixes pending commit to git master as well? This is a snapshot of git master as of a few days ago... git master is no longer useable after this point, at least not for intel. I hope to eventually get gem working, (shameless plea for help) but it may take some time. Given that we haven't had a real update to drm in a couple of years, I wanted to get this in the tree. There are a few patches present in this changeset beyond what was in git master. As I stated earlier, the future of drm.git is in question right now, so I'm not sure what the best way to move forward is yet. I would like to go ahead and get in the features and fixes that we have now, rather than stall out and wait until we have the next feature... We will wait forever on some feature or the other. What I'm aiming to do with this changeset, is identify any outstanding bugs/regressions and get us a little more current than we are today. I have a lot of work that I would like to do outside of trying to keep up with the new features coming out, but time is limited... robert. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20080814/eeab85aa/attachment.pgp From cokane at FreeBSD.org Thu Aug 14 16:46:48 2008 From: cokane at FreeBSD.org (Coleman Kane) Date: Thu Aug 14 16:46:54 2008 Subject: [CFT] drm updates In-Reply-To: <1218731717.6077.27.camel@squirrel.corp.cox.com> References: <1218675844.1899.18.camel@wombat.2hip.net> <1218729645.11432.0.camel@localhost> <1218731717.6077.27.camel@squirrel.corp.cox.com> Message-ID: <1218732365.11432.6.camel@localhost> On Thu, 2008-08-14 at 12:35 -0400, Robert Noland wrote: > On Thu, 2008-08-14 at 12:00 -0400, Coleman Kane wrote: > > On Wed, 2008-08-13 at 21:04 -0400, Robert Noland wrote: > > > I have prepared a set of patches for drm kernel modules against -CURRENT > > > and -STABLE. I would like to get this into HEAD fairly soon. > > > > > > This update has the latest vblank rework bits in it, so if you have > > > hardware that can disable vblank irq's (radeon, intel) you should see > > > the irq counts drop if there are no vblank consumers running. > > > > > > i915 suspend/resume support is included. > > > > > > For Intel, this should pick up support for the g33 chipsets as well. > > > > > > Lots of other fixes here and there... > > > > > > The patches are located at http://people.freebsd.org/~rnoland > > > > > > robert. > > > > > > > Robert, > > > > Are these patches just snapshots of code currently in git master, or do > > they also include fixes pending commit to git master as well? > > This is a snapshot of git master as of a few days ago... git master is > no longer useable after this point, at least not for intel. I hope to > eventually get gem working, (shameless plea for help) but it may take > some time. Given that we haven't had a real update to drm in a couple > of years, I wanted to get this in the tree. There are a few patches > present in this changeset beyond what was in git master. I've been tracking master, rather than using the drm stuff in sys/ lately. Since I've got an AMD RS690, I just disabled the Intel driver after the gem breakage. I should probably try your patches out instead of the git tree for a bit just to make sure that they don't break anything new. I'm still running into some GPU crashes in the current state of the drm git tree / DRI drivers from git. > > As I stated earlier, the future of drm.git is in question right now, so > I'm not sure what the best way to move forward is yet. I would like to > go ahead and get in the features and fixes that we have now, rather than > stall out and wait until we have the next feature... We will wait > forever on some feature or the other. Argh for the Linuxization of the DRM code. > > What I'm aiming to do with this changeset, is identify any outstanding > bugs/regressions and get us a little more current than we are today. I > have a lot of work that I would like to do outside of trying to keep up > with the new features coming out, but time is limited... > > robert. > -- Coleman Kane -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20080814/6c6776d3/attachment.pgp From artem_kim at inbox.ru Thu Aug 14 22:24:00 2008 From: artem_kim at inbox.ru (Artem Kim) Date: Thu Aug 14 22:24:07 2008 Subject: [CFT] drm updates In-Reply-To: <1218675844.1899.18.camel@wombat.2hip.net> References: <1218675844.1899.18.camel@wombat.2hip.net> Message-ID: <200808150145.49675.artem_kim@inbox.ru> On Thursday 14 August 2008 05:04:04 Robert Noland wrote: > I have prepared a set of patches for drm kernel modules against -CURRENT > and -STABLE. I would like to get this into HEAD fairly soon. > This patch works for me without serious problems . My box: CPU: AMD Athlon(tm) 64 Processor 3200+ (UP) Radeon 9800 XT (R350), xf86-video-ati-6.9.0 FreeBSD 7.0-STABLE amd64 When using composite extensions (KDE4), I see some distortions that look like vertical lines. Sometimes I see: arti% glxgears ********************************* WARN_ONCE **************** ***************** File r300_mem.c function r300_mem_alloc line 225 Ran out of GART memory (for 1048576)! Please consider adjusting GARTSize option. From miwi at FreeBSD.org Thu Aug 14 23:34:01 2008 From: miwi at FreeBSD.org (miwi@FreeBSD.org) Date: Thu Aug 14 23:34:08 2008 Subject: ports/117508: x11/xorg 7.2, 7.3 i8i0 and intel crash system using Blender (OpenGL) Message-ID: <200808142334.m7ENY1it027047@freefall.freebsd.org> Synopsis: x11/xorg 7.2,7.3 i8i0 and intel crash system using Blender (OpenGL) State-Changed-From-To: feedback->closed State-Changed-By: miwi State-Changed-When: Thu Aug 14 23:33:52 UTC 2008 State-Changed-Why: Feedback timeout. If you want to update this port, please feel free to follow-up this PR so that we can re-open it and find a solution for the problem. Thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=117508 From vehemens at verizon.net Fri Aug 15 06:02:01 2008 From: vehemens at verizon.net (vehemens) Date: Fri Aug 15 06:02:08 2008 Subject: [CFT] drm updates Message-ID: <200808142307.32015.vehemens@verizon.net> On Thu, 2008-08-14 at 16:48 -0400, Coleman Kane wrote: >Argh for the Linuxization of the DRM code. Well to be fair, the BSD's haven't been doing their share for a while. All this net/open work in "my own repro" hasn't helped either. The inclusion of the intel gem code was actually a good thing as the multiple branch linux work was a disorganized mess at best. It also seems to of generated more traffic on this list then I have seen in a long time (wake-up call?). On a side note, intel just eliminated any reason for a BSD user to buy any of their new hardware. yea?? Personally I really haven't cared to much about git master usability as I'm waiting for radeon dri2 and r600 support. Having said all of that, I'll add that I'm hoping to get a commit bit soon given that I have a number of local patches that reduces the unnecessary differences (that's the plan anyway). From cokane at FreeBSD.org Fri Aug 15 14:42:16 2008 From: cokane at FreeBSD.org (Coleman Kane) Date: Fri Aug 15 14:42:22 2008 Subject: [CFT] drm updates In-Reply-To: <200808142307.32015.vehemens@verizon.net> References: <200808142307.32015.vehemens@verizon.net> Message-ID: <1218811287.1928.4.camel@localhost> On Thu, 2008-08-14 at 23:07 -0700, vehemens wrote: > On Thu, 2008-08-14 at 16:48 -0400, Coleman Kane wrote: > > >Argh for the Linuxization of the DRM code. > > Well to be fair, the BSD's haven't been doing their share for a while. All > this net/open work in "my own repro" hasn't helped either. Yeah I agree... BSD DRM has suffered from a severe lack of attention until recently. My upgrade to a RadeonHD notebook was my first introduction to this. > > The inclusion of the intel gem code was actually a good thing as the multiple > branch linux work was a disorganized mess at best. > > It also seems to of generated more traffic on this list then I have seen in a > long time (wake-up call?). > > On a side note, intel just eliminated any reason for a BSD user to buy any of > their new hardware. yea?? > > Personally I really haven't cared to much about git master usability as I'm > waiting for radeon dri2 and r600 support. > > Having said all of that, I'll add that I'm hoping to get a commit bit soon > given that I have a number of local patches that reduces the unnecessary > differences (that's the plan anyway). Do you host any of the patches publicly right now? I'd be more than happy to test them out and see how well they work with my RS690. Right now my GPU is unusable for EXA or DRI using xf86-video-ati (intermittently works) or xf86-video-radeonhd (never works, displays artifacts, then screeches to a halt). I was more active in getting things tested for the radeonhd, ati, and rnoland's patches until about halfway through June. Since then, the Day Job and a move back to Cincinnati have both occupied my ever decreasing amount of spare time. -- Coleman Kane -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20080815/f748c2c3/attachment.pgp From rnoland at 2hip.net Fri Aug 15 15:02:04 2008 From: rnoland at 2hip.net (Robert Noland) Date: Fri Aug 15 15:02:10 2008 Subject: [CFT] drm updates In-Reply-To: <200808142307.32015.vehemens@verizon.net> References: <200808142307.32015.vehemens@verizon.net> Message-ID: <1218812516.9345.22.camel@squirrel.corp.cox.com> On Thu, 2008-08-14 at 23:07 -0700, vehemens wrote: > On Thu, 2008-08-14 at 16:48 -0400, Coleman Kane wrote: > > >Argh for the Linuxization of the DRM code. > > Well to be fair, the BSD's haven't been doing their share for a while. All > this net/open work in "my own repro" hasn't helped either. > > The inclusion of the intel gem code was actually a good thing as the multiple > branch linux work was a disorganized mess at best. > > It also seems to of generated more traffic on this list then I have seen in a > long time (wake-up call?). Yes, there is more work to do than I can do alone... Any help is greatly appreciated. > On a side note, intel just eliminated any reason for a BSD user to buy any of > their new hardware. yea?? I'm frustrated, but intel has been fairly good about giving up docs and licensing of code that they write. I don't think that they are actively trying to alienate us, they are just trying to take advantage of the latest linux kernel bits and make it easier for them to merge into linux. I'm not sure that it is going to work out all that well for them (the linux folks) either though. For now, it's all still up in the air, so I don't know what will happen with the repo's. As far as gem and mode-setting go, intel has been working hard to get those features done for linux, and while I don't forsee them helping us with our code, they aren't actively working against us either... robert. > Personally I really haven't cared to much about git master usability as I'm > waiting for radeon dri2 and r600 support. > > Having said all of that, I'll add that I'm hoping to get a commit bit soon > given that I have a number of local patches that reduces the unnecessary > differences (that's the plan anyway). > _______________________________________________ > freebsd-x11@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-x11 > To unsubscribe, send any mail to "freebsd-x11-unsubscribe@freebsd.org" -- Robert Noland 2Hip Networks -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20080815/b83c3bca/attachment.pgp From vehemens at verizon.net Fri Aug 15 18:56:53 2008 From: vehemens at verizon.net (vehemens) Date: Fri Aug 15 18:56:59 2008 Subject: [CFT] drm updates In-Reply-To: <1218812516.9345.22.camel@squirrel.corp.cox.com> References: <200808142307.32015.vehemens@verizon.net> <1218812516.9345.22.camel@squirrel.corp.cox.com> Message-ID: <200808151202.11520.vehemens@verizon.net> On Friday 15 August 2008 08:01:56 am Robert Noland wrote: > On Thu, 2008-08-14 at 23:07 -0700, vehemens wrote: > ... > > On a side note, intel just eliminated any reason for a BSD user to buy > > any of their new hardware. yea?? > > I'm frustrated, but intel has been fairly good about giving up docs and > licensing of code that they write. I don't think that they are actively > trying to alienate us, they are just trying to take advantage of the > latest linux kernel bits and make it easier for them to merge into > linux. I'm not sure that it is going to work out all that well for them > (the linux folks) either though. For now, it's all still up in the air, > so I don't know what will happen with the repo's. As far as gem and > mode-setting go, intel has been working hard to get those features done > for linux, and while I don't forsee them helping us with our code, they > aren't actively working against us either... That was a bit of a dig at intel by me. They have done a log of good work recently. A lot of the GEM code appears to be usable on BSD once you get past the linux parts. Ditto for mode-setting. From vehemens at verizon.net Fri Aug 15 20:03:15 2008 From: vehemens at verizon.net (vehemens) Date: Fri Aug 15 20:03:28 2008 Subject: [CFT] drm updates In-Reply-To: <1218811287.1928.4.camel@localhost> References: <200808142307.32015.vehemens@verizon.net> <1218811287.1928.4.camel@localhost> Message-ID: <200808151308.31663.vehemens@verizon.net> On Friday 15 August 2008 07:41:27 am Coleman Kane wrote: > On Thu, 2008-08-14 at 23:07 -0700, vehemens wrote: > ... > > Having said all of that, I'll add that I'm hoping to get a commit bit > > soon given that I have a number of local patches that reduces the > > unnecessary differences (that's the plan anyway). > > Do you host any of the patches publicly right now? I'd be more than > happy to test them out and see how well they work with my RS690. Right > now my GPU is unusable for EXA or DRI using xf86-video-ati > (intermittently works) or xf86-video-radeonhd (never works, displays > artifacts, then screeches to a halt). > > I was more active in getting things tested for the radeonhd, ati, and > rnoland's patches until about halfway through June. Since then, the Day > Job and a move back to Cincinnati have both occupied my ever decreasing > amount of spare time. The kernel driver is only part of what needs to be updated. One of my systems uses a RV370 which along with most of xorg master is pretty stable. Recent input changes seems to broken the xserver mouse driver interface however. I haven't made the DRM patches available, but that's what the commit bit should do. Not sure how to handle the port tree patches and tar-balls from git master. Most of my DRM patches reduce the differences between BSD & linux which I consider a stepping stone to DRI2 and other features. I was hoping that stability would be a fall-out from this work. Haven't tried xf86-video-radeonhd with a RS690 recently, but it's PLL problems several months ago was the reason I bought a HD 2600 PRO (also for it's two DVI ports). Using git master xf86-video-radeonhd with the 2600 seems to be pretty stable. From vehemens at verizon.net Fri Aug 15 23:06:47 2008 From: vehemens at verizon.net (vehemens) Date: Fri Aug 15 23:06:53 2008 Subject: [CFT] drm updates In-Reply-To: <1218811287.1928.4.camel@localhost> References: <200808142307.32015.vehemens@verizon.net> <1218811287.1928.4.camel@localhost> Message-ID: <200808151612.11847.vehemens@verizon.net> On Friday 15 August 2008 07:41:27 am Coleman Kane wrote: > ... > Do you host any of the patches publicly right now? I'd be more than > happy to test them out and see how well they work with my RS690. Right > now my GPU is unusable for EXA or DRI using xf86-video-ati > (intermittently works) or xf86-video-radeonhd (never works, displays > artifacts, then screeches to a halt). > ... After thinking about your stability problems a bit more, xserver has recently received a number of EXA improvements, R500 MESA/DRM support is fairly recent, and the drivers are a moving target a well. Few (none?) of these improvements are in the official FreeBSD src/ports trees. I'll send you a xf86-video-radeonhd tarball that I just created and tested with my HD 2660 PRO. It may help, but I suspect that other parts of the X tree will need to be updated as well. From cokane at FreeBSD.org Fri Aug 15 23:38:21 2008 From: cokane at FreeBSD.org (Coleman Kane) Date: Fri Aug 15 23:38:28 2008 Subject: [CFT] drm updates In-Reply-To: <200808151612.11847.vehemens@verizon.net> References: <200808142307.32015.vehemens@verizon.net> <1218811287.1928.4.camel@localhost> <200808151612.11847.vehemens@verizon.net> Message-ID: <1218842011.2040.3.camel@localhost> On Fri, 2008-08-15 at 16:12 -0700, vehemens wrote: > On Friday 15 August 2008 07:41:27 am Coleman Kane wrote: > > ... > > Do you host any of the patches publicly right now? I'd be more than > > happy to test them out and see how well they work with my RS690. Right > > now my GPU is unusable for EXA or DRI using xf86-video-ati > > (intermittently works) or xf86-video-radeonhd (never works, displays > > artifacts, then screeches to a halt). > > ... > > After thinking about your stability problems a bit more, xserver has recently > received a number of EXA improvements, R500 MESA/DRM support is fairly > recent, and the drivers are a moving target a well. Few (none?) of these > improvements are in the official FreeBSD src/ports trees. > > I'll send you a xf86-video-radeonhd tarball that I just created and tested > with my HD 2660 PRO. It may help, but I suspect that other parts of the X > tree will need to be updated as well. > I've been tracking the following masters from fd.o git: mesa/drm dri2proto fontsproto glproto inputproto kbproto libX11 libXdamage libXfont libXtst libxcb libxtrans mesa/mesa xorg-server x11proto randrproto xcb-proto xextproto xf86driproto xproto libXext libXi libXrandr libpciaccess libxkbfile libxkbui xf86-video-ati xf86-video-radeonhd xf86-input-keyboard xf86-input-mouse -- Coleman Kane -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20080815/59c6d7a1/attachment.pgp From vehemens at verizon.net Fri Aug 15 23:59:34 2008 From: vehemens at verizon.net (vehemens) Date: Fri Aug 15 23:59:40 2008 Subject: [CFT] drm updates In-Reply-To: <1218842011.2040.3.camel@localhost> References: <200808142307.32015.vehemens@verizon.net> <200808151612.11847.vehemens@verizon.net> <1218842011.2040.3.camel@localhost> Message-ID: <200808151705.12296.vehemens@verizon.net> On Friday 15 August 2008 04:13:31 pm Coleman Kane wrote: > On Fri, 2008-08-15 at 16:12 -0700, vehemens wrote: > > On Friday 15 August 2008 07:41:27 am Coleman Kane wrote: > > > ... > > > Do you host any of the patches publicly right now? I'd be more than > > > happy to test them out and see how well they work with my RS690. Right > > > now my GPU is unusable for EXA or DRI using xf86-video-ati > > > (intermittently works) or xf86-video-radeonhd (never works, displays > > > artifacts, then screeches to a halt). > > > ... > > > > After thinking about your stability problems a bit more, xserver has > > recently received a number of EXA improvements, R500 MESA/DRM support is > > fairly recent, and the drivers are a moving target a well. Few (none?) > > of these improvements are in the official FreeBSD src/ports trees. > > > > I'll send you a xf86-video-radeonhd tarball that I just created and > > tested with my HD 2660 PRO. It may help, but I suspect that other parts > > of the X tree will need to be updated as well. > > I've been tracking the following masters from fd.o git: > > mesa/drm dri2proto fontsproto glproto inputproto kbproto libX11 > libXdamage libXfont libXtst libxcb libxtrans mesa/mesa xorg-server > x11proto randrproto xcb-proto xextproto xf86driproto xproto libXext > libXi libXrandr libpciaccess libxkbfile libxkbui xf86-video-ati > xf86-video-radeonhd xf86-input-keyboard xf86-input-mouse Interesting. The list is a bit shorter then mine. I don't see pixman as well as a few others. Not sure if it matters all that much. When you update mesa, do you update both the dri and libGL ports? Ditto for libdrm and kernel drm? Guess I'll checkout my builds on a RS690 and see what happens. From cokane at FreeBSD.org Sat Aug 16 01:06:01 2008 From: cokane at FreeBSD.org (Coleman Kane) Date: Sat Aug 16 01:06:07 2008 Subject: [CFT] drm updates In-Reply-To: <200808151705.12296.vehemens@verizon.net> References: <200808142307.32015.vehemens@verizon.net> <200808151612.11847.vehemens@verizon.net> <1218842011.2040.3.camel@localhost> <200808151705.12296.vehemens@verizon.net> Message-ID: <1218848713.2308.0.camel@localhost> On Fri, 2008-08-15 at 17:05 -0700, vehemens wrote: > On Friday 15 August 2008 04:13:31 pm Coleman Kane wrote: > > On Fri, 2008-08-15 at 16:12 -0700, vehemens wrote: > > > On Friday 15 August 2008 07:41:27 am Coleman Kane wrote: > > > > ... > > > > Do you host any of the patches publicly right now? I'd be more than > > > > happy to test them out and see how well they work with my RS690. Right > > > > now my GPU is unusable for EXA or DRI using xf86-video-ati > > > > (intermittently works) or xf86-video-radeonhd (never works, displays > > > > artifacts, then screeches to a halt). > > > > ... > > > > > > After thinking about your stability problems a bit more, xserver has > > > recently received a number of EXA improvements, R500 MESA/DRM support is > > > fairly recent, and the drivers are a moving target a well. Few (none?) > > > of these improvements are in the official FreeBSD src/ports trees. > > > > > > I'll send you a xf86-video-radeonhd tarball that I just created and > > > tested with my HD 2660 PRO. It may help, but I suspect that other parts > > > of the X tree will need to be updated as well. > > > > I've been tracking the following masters from fd.o git: > > > > mesa/drm dri2proto fontsproto glproto inputproto kbproto libX11 > > libXdamage libXfont libXtst libxcb libxtrans mesa/mesa xorg-server > > x11proto randrproto xcb-proto xextproto xf86driproto xproto libXext > > libXi libXrandr libpciaccess libxkbfile libxkbui xf86-video-ati > > xf86-video-radeonhd xf86-input-keyboard xf86-input-mouse > > Interesting. The list is a bit shorter then mine. I don't see pixman as well > as a few others. Not sure if it matters all that much. > > When you update mesa, do you update both the dri and libGL ports? Ditto for > libdrm and kernel drm? > > Guess I'll checkout my builds on a RS690 and see what happens. D'oh! Yeah, pixman should be included in that list too. I am tracking it as well. I can't get very far on the latest X.org without it! -- Coleman Kane -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20080816/9ed6e18e/attachment.pgp From vehemens at verizon.net Sat Aug 16 23:30:03 2008 From: vehemens at verizon.net (vehemens) Date: Sat Aug 16 23:30:10 2008 Subject: [CFT] drm updates In-Reply-To: <1218848713.2308.0.camel@localhost> References: <200808142307.32015.vehemens@verizon.net> <200808151705.12296.vehemens@verizon.net> <1218848713.2308.0.camel@localhost> Message-ID: <200808161635.32540.vehemens@verizon.net> On Friday 15 August 2008 06:05:13 pm Coleman Kane wrote: > On Fri, 2008-08-15 at 17:05 -0700, vehemens wrote: > > On Friday 15 August 2008 04:13:31 pm Coleman Kane wrote: > > > On Fri, 2008-08-15 at 16:12 -0700, vehemens wrote: > > > > On Friday 15 August 2008 07:41:27 am Coleman Kane wrote: > > > > > ... > > > > > Do you host any of the patches publicly right now? I'd be more than > > > > > happy to test them out and see how well they work with my RS690. > > > > > Right now my GPU is unusable for EXA or DRI using xf86-video-ati > > > > > (intermittently works) or xf86-video-radeonhd (never works, > > > > > displays artifacts, then screeches to a halt). > > > > > ... > > > > > > > > After thinking about your stability problems a bit more, xserver has > > > > recently received a number of EXA improvements, R500 MESA/DRM support > > > > is fairly recent, and the drivers are a moving target a well. Few > > > > (none?) of these improvements are in the official FreeBSD src/ports > > > > trees. > > > > > > > > I'll send you a xf86-video-radeonhd tarball that I just created and > > > > tested with my HD 2660 PRO. It may help, but I suspect that other > > > > parts of the X tree will need to be updated as well. > > > > > > I've been tracking the following masters from fd.o git: > > > > > > mesa/drm dri2proto fontsproto glproto inputproto kbproto libX11 > > > libXdamage libXfont libXtst libxcb libxtrans mesa/mesa xorg-server > > > x11proto randrproto xcb-proto xextproto xf86driproto xproto libXext > > > libXi libXrandr libpciaccess libxkbfile libxkbui xf86-video-ati > > > xf86-video-radeonhd xf86-input-keyboard xf86-input-mouse > > > > Interesting. The list is a bit shorter then mine. I don't see pixman as > > well as a few others. Not sure if it matters all that much. > > > > When you update mesa, do you update both the dri and libGL ports? Ditto > > for libdrm and kernel drm? > > > > Guess I'll checkout my builds on a RS690 and see what happens. > > D'oh! Yeah, pixman should be included in that list too. I am tracking it > as well. I can't get very far on the latest X.org without it! Almost all combinations of ddx/dri/drm drivers hangs my am64 box. Did get X running by using the radeonhd and dri swrast drivers, as well as removing the other drivers. System reports it has dri, but compiz or glgears doesn't run. What combinations worked for you? From cokane at FreeBSD.org Sun Aug 17 20:54:50 2008 From: cokane at FreeBSD.org (Coleman Kane) Date: Sun Aug 17 20:54:57 2008 Subject: [CFT] drm updates In-Reply-To: <200808161635.32540.vehemens@verizon.net> References: <200808142307.32015.vehemens@verizon.net> <200808151705.12296.vehemens@verizon.net> <1218848713.2308.0.camel@localhost> <200808161635.32540.vehemens@verizon.net> Message-ID: <1219006437.21310.12.camel@localhost> On Sat, 2008-08-16 at 16:35 -0700, vehemens wrote: > On Friday 15 August 2008 06:05:13 pm Coleman Kane wrote: > > On Fri, 2008-08-15 at 17:05 -0700, vehemens wrote: > > > On Friday 15 August 2008 04:13:31 pm Coleman Kane wrote: > > > > On Fri, 2008-08-15 at 16:12 -0700, vehemens wrote: > > > > > On Friday 15 August 2008 07:41:27 am Coleman Kane wrote: > > > > > > ... > > > > > > Do you host any of the patches publicly right now? I'd be more than > > > > > > happy to test them out and see how well they work with my RS690. > > > > > > Right now my GPU is unusable for EXA or DRI using xf86-video-ati > > > > > > (intermittently works) or xf86-video-radeonhd (never works, > > > > > > displays artifacts, then screeches to a halt). > > > > > > ... > > > > > > > > > > After thinking about your stability problems a bit more, xserver has > > > > > recently received a number of EXA improvements, R500 MESA/DRM support > > > > > is fairly recent, and the drivers are a moving target a well. Few > > > > > (none?) of these improvements are in the official FreeBSD src/ports > > > > > trees. > > > > > > > > > > I'll send you a xf86-video-radeonhd tarball that I just created and > > > > > tested with my HD 2660 PRO. It may help, but I suspect that other > > > > > parts of the X tree will need to be updated as well. > > > > > > > > I've been tracking the following masters from fd.o git: > > > > > > > > mesa/drm dri2proto fontsproto glproto inputproto kbproto libX11 > > > > libXdamage libXfont libXtst libxcb libxtrans mesa/mesa xorg-server > > > > x11proto randrproto xcb-proto xextproto xf86driproto xproto libXext > > > > libXi libXrandr libpciaccess libxkbfile libxkbui xf86-video-ati > > > > xf86-video-radeonhd xf86-input-keyboard xf86-input-mouse > > > > > > Interesting. The list is a bit shorter then mine. I don't see pixman as > > > well as a few others. Not sure if it matters all that much. > > > > > > When you update mesa, do you update both the dri and libGL ports? Ditto > > > for libdrm and kernel drm? > > > > > > Guess I'll checkout my builds on a RS690 and see what happens. > > > > D'oh! Yeah, pixman should be included in that list too. I am tracking it > > as well. I can't get very far on the latest X.org without it! > > Almost all combinations of ddx/dri/drm drivers hangs my am64 box. > > Did get X running by using the radeonhd and dri swrast drivers, as well as > removing the other drivers. > > System reports it has dri, but compiz or glgears doesn't run. > > What combinations worked for you? Basically, I can use radeonhd or ati from git master without trouble as long as I am not using DRI. The radeonhd driver also freezes my system when I try to use EXA. When I use EXA+DRI in the radeonhd driver, I get an X root window that has a bunch of artifacts displayed on it. Interestingly enough, it seems like it dumps a bitmap of the last image of the text console to the root window, the one I would see before the video mode switched after running startx. The mouse cursor works for a little while, as it seems compiz is beginning to load from the gnome-session manager. I never actually see any screen updates occur while it is starting up. Then, at some point the system just freezes and I need to hard-power-off the laptop, by holding down the power button until it is forced off. With the ati driver and DRI+EXA, running startx causes the X server to begin to load, then changes the video mode and blanks the screen. Once the screen has been cleared, the server freezes and no loading proceeds. I can reset the system by doing an ALT-CTRL-DELETE or by doing soft-power-off by pressing, then releasing the power button (which FreeBSD-ACPI catches and gracefully shuts the machine down). The shutdown process must be held up by something in bufdaemon or other kernel service that typically counts down the "remaining" during a normal shutdown, of course I can't see which with the X server owning the display. Eventually the system is shutdown or restarted. At some point back in early June, it all started to work for me sometimes. Robert Noland threw a bunch of patches my way that fixed numerous locking issues in the kernel, which gradually made things more reliable for me. At some point in July, some commits to the sources resulted in intermittent crashing in the EXA code, which I was able to reproduce with/without DRI enabled (always with EXA), when browsing various websites with firefox. Eventually, later on in July, I began to get the results that I currently get with DRI enabled. That is to say, it no longer ever works for me under the ati driver (freezes X server at startup). I've never been able to get radeonhd to give me operational DRI support. If I am not using EXA, but have DRI enabled, radeonhd will start up properly, but will not display any DRI output (instead just displaying black where the DRI stuff should be rendered). -- Coleman Kane -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20080817/9b103797/attachment.pgp From cokane at FreeBSD.org Sun Aug 17 22:17:11 2008 From: cokane at FreeBSD.org (Coleman Kane) Date: Sun Aug 17 22:17:18 2008 Subject: [CFT] drm updates In-Reply-To: <1219006437.21310.12.camel@localhost> References: <200808142307.32015.vehemens@verizon.net> <200808151705.12296.vehemens@verizon.net> <1218848713.2308.0.camel@localhost> <200808161635.32540.vehemens@verizon.net> <1219006437.21310.12.camel@localhost> Message-ID: <1219011377.1960.4.camel@localhost> On Sun, 2008-08-17 at 16:53 -0400, Coleman Kane wrote: > On Sat, 2008-08-16 at 16:35 -0700, vehemens wrote: > > On Friday 15 August 2008 06:05:13 pm Coleman Kane wrote: > > > On Fri, 2008-08-15 at 17:05 -0700, vehemens wrote: > > > > On Friday 15 August 2008 04:13:31 pm Coleman Kane wrote: > > > > > On Fri, 2008-08-15 at 16:12 -0700, vehemens wrote: > > > > > > On Friday 15 August 2008 07:41:27 am Coleman Kane wrote: > > > > > > > ... > > > > > > > Do you host any of the patches publicly right now? I'd be more than > > > > > > > happy to test them out and see how well they work with my RS690. > > > > > > > Right now my GPU is unusable for EXA or DRI using xf86-video-ati > > > > > > > (intermittently works) or xf86-video-radeonhd (never works, > > > > > > > displays artifacts, then screeches to a halt). > > > > > > > ... > > > > > > > > > > > > After thinking about your stability problems a bit more, xserver has > > > > > > recently received a number of EXA improvements, R500 MESA/DRM support > > > > > > is fairly recent, and the drivers are a moving target a well. Few > > > > > > (none?) of these improvements are in the official FreeBSD src/ports > > > > > > trees. > > > > > > > > > > > > I'll send you a xf86-video-radeonhd tarball that I just created and > > > > > > tested with my HD 2660 PRO. It may help, but I suspect that other > > > > > > parts of the X tree will need to be updated as well. > > > > > > > > > > I've been tracking the following masters from fd.o git: > > > > > > > > > > mesa/drm dri2proto fontsproto glproto inputproto kbproto libX11 > > > > > libXdamage libXfont libXtst libxcb libxtrans mesa/mesa xorg-server > > > > > x11proto randrproto xcb-proto xextproto xf86driproto xproto libXext > > > > > libXi libXrandr libpciaccess libxkbfile libxkbui xf86-video-ati > > > > > xf86-video-radeonhd xf86-input-keyboard xf86-input-mouse > > > > > > > > Interesting. The list is a bit shorter then mine. I don't see pixman as > > > > well as a few others. Not sure if it matters all that much. > > > > > > > > When you update mesa, do you update both the dri and libGL ports? Ditto > > > > for libdrm and kernel drm? > > > > > > > > Guess I'll checkout my builds on a RS690 and see what happens. > > > > > > D'oh! Yeah, pixman should be included in that list too. I am tracking it > > > as well. I can't get very far on the latest X.org without it! > > > > Almost all combinations of ddx/dri/drm drivers hangs my am64 box. > > > > Did get X running by using the radeonhd and dri swrast drivers, as well as > > removing the other drivers. > > > > System reports it has dri, but compiz or glgears doesn't run. > > > > What combinations worked for you? > > Basically, I can use radeonhd or ati from git master without trouble as > long as I am not using DRI. The radeonhd driver also freezes my system > when I try to use EXA. When I use EXA+DRI in the radeonhd driver, I get > an X root window that has a bunch of artifacts displayed on it. > Interestingly enough, it seems like it dumps a bitmap of the last image > of the text console to the root window, the one I would see before the > video mode switched after running startx. The mouse cursor works for a > little while, as it seems compiz is beginning to load from the > gnome-session manager. I never actually see any screen updates occur > while it is starting up. Then, at some point the system just freezes and > I need to hard-power-off the laptop, by holding down the power button > until it is forced off. > > With the ati driver and DRI+EXA, running startx causes the X server to > begin to load, then changes the video mode and blanks the screen. Once > the screen has been cleared, the server freezes and no loading proceeds. > I can reset the system by doing an ALT-CTRL-DELETE or by doing > soft-power-off by pressing, then releasing the power button (which > FreeBSD-ACPI catches and gracefully shuts the machine down). The > shutdown process must be held up by something in bufdaemon or other > kernel service that typically counts down the "remaining" during a > normal shutdown, of course I can't see which with the X server owning > the display. Eventually the system is shutdown or restarted. > > At some point back in early June, it all started to work for me > sometimes. Robert Noland threw a bunch of patches my way that fixed > numerous locking issues in the kernel, which gradually made things more > reliable for me. At some point in July, some commits to the sources > resulted in intermittent crashing in the EXA code, which I was able to > reproduce with/without DRI enabled (always with EXA), when browsing > various websites with firefox. > > Eventually, later on in July, I began to get the results that I > currently get with DRI enabled. That is to say, it no longer ever works > for me under the ati driver (freezes X server at startup). I've never > been able to get radeonhd to give me operational DRI support. If I am > not using EXA, but have DRI enabled, radeonhd will start up properly, > but will not display any DRI output (instead just displaying black where > the DRI stuff should be rendered). > When I am using the xf86-video-ati driver, and I enable DRI, the server never finishes starting (video made changes, but the root window and the cursor is never displayed). The following message is spammed from the kernel (and ends up in /var/log/messages): info: [drm] wait for fifo failed status : 0x9001C100 0x00080000 For some reason, through a number of the failures I am now seeing the following spammed to messages as well, when the server fails: Aug 17 17:51:03 erwin kernel: WARNING pid 1414 (initial thread): ioctl sign-extension ioctl ffffffffc0106407 Aug 17 17:51:03 erwin kernel: WARNING pid 1414 (initial thread): ioctl sign-extension ioctl ffffffffc0106401 Aug 17 17:51:03 erwin kernel: WARNING pid 1414 (initial thread): ioctl sign-extension ioctl ffffffffc0106401 Aug 17 17:51:03 erwin kernel: WARNING pid 1414 (initial thread): ioctl sign-extension ioctl ffffffffc0106407 Aug 17 17:51:03 erwin kernel: WARNING pid 1414 (initial thread): ioctl sign-extension ioctl ffffffffc0286415 Aug 17 17:51:03 erwin kernel: WARNING pid 1414 (initial thread): ioctl sign-extension ioctl ffffffffc0286415 Aug 17 17:51:03 erwin kernel: WARNING pid 1414 (initial thread): ioctl sign-extension ioctl ffffffffc0106426 Aug 17 17:51:03 erwin kernel: WARNING pid 1414 (initial thread): ioctl sign-extension ioctl ffffffffc0106426 Aug 17 17:51:03 erwin kernel: WARNING pid 1414 (initial thread): ioctl sign-extension ioctl ffffffffc0086420 Aug 17 17:51:03 erwin kernel: WARNING pid 1414 (initial thread): ioctl sign-extension ioctl ffffffff80086422 Aug 17 17:51:03 erwin kernel: WARNING pid 1414 (initial thread): ioctl sign-extension ioctl ffffffff8008642a Aug 17 17:51:03 erwin kernel: WARNING pid 1414 (initial thread): ioctl sign-extension ioctl ffffffffc0106438 Aug 17 17:51:03 erwin kernel: WARNING pid 1414 (initial thread): ioctl sign-extension ioctl ffffffffc0286415 I took a glance, and the "cmd" field in drm_ioctl_desc is an "unsigned long", so I am now curious if perhaps this sign extension is resulting in the wrong "cmd" value being passed to the drm ioctl handler, in my amd64 case... -- Coleman Kane -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20080817/790f267f/attachment.pgp From donotreply at tringme.com Mon Aug 18 05:57:45 2008 From: donotreply at tringme.com (TringMe) Date: Mon Aug 18 05:57:51 2008 Subject: Make Free Calls Worldwide - Invitation From Mohd. Aijaz Message-ID: <20080818055745.47190B6865A@tringme.com> Dear TringMe User, Mohd. Aijaz has invited you to join TringMe and make worldwide calls FREE from your mobile and web. TringMe is the simplest way make and receive worldwide calls from the web for FREE* … just click & call !! No software to download, No software to install. Break free from the traditional telephony paradigm and embrace the next generation telephony: - Make and receive calls between Web, Instant Messengers, Phones, SIP URIs etc !! - Retrieve voicemails from any device or directly from the web. Have it mailed to you as text !! Reduce your dependency on the expensive cellular minutes - Access the same set services from TringMe's powerful MobileVoIP client - Use WiFi, 2.5G/3G data networks to make and receive cheap calls, retrieve voicemails and much more !! Join TringMe by clicking on the following link (or copy/paste in your browser) http://tringme.com/myinvite.php?e=freebsd-x11%40freebsd.org&f=13847-2483659572&ic=797a6babba5d0963 Feel free to write to us at support@tringme.com if you need any assistance. Regards, TringMe Support http://www.tringme.com/ From bugmaster at FreeBSD.org Mon Aug 18 11:07:00 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 18 11:09:17 2008 Subject: Current problem reports assigned to freebsd-x11@FreeBSD.org Message-ID: <200808181106.m7IB6xFs080002@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- f ports/106370 x11 Screen corruption when using Direct Rendering on a PCI o ports/116359 x11 x11/xorg - screen blinks with PCI-E nvidia card and ve o ports/117195 x11 ix11/Xorg 7.3 dumps core at exit (sig 11) o ports/117766 x11 x11-servers/xorg-server (7.3) crashes under heavy load o ports/118950 x11 x11-drivers/xf86-video-nv - xorg xf86 nv (nvidia) driv o ports/119037 x11 x11: Can't type _ (Underscore) under X (gnome) f ports/119091 x11 x11-drivers/xf86-video-intel 2.1.1 panics system o ports/121360 x11 x11/xorg - Change default of ~/.xsession-errors to off o ports/122830 x11 x11/xorg: Error in I830WaitLpRing() o ports/122924 x11 XCreateImage fails in most recent x11/XOrg o ports/124220 x11 [amd64] x11-servers/xorg-server - X.org server runs in o ports/124861 x11 Keyboard problems with xorg o ports/125661 x11 x11/xorg: startx fails after a couple of attempts 13 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s ports/73743 x11 XOrg/XFree xauth add/startx problem o ports/113106 x11 x11/xorg - Xorg 7.2 + Mach64 + dri produces error mess f ports/114827 x11 Xorg server crashes when starting astro/google-earth o ports/115020 x11 New port: graphics/osmesa - Mesa's off-screen renderin s ports/115536 x11 [new port] x11/xorg-base port for a minimal X.Org inst o ports/116443 x11 x11-drivers/xf86-input-keyboard patch for USB jp106 ke f ports/116603 x11 x11/xorg server 7.3 hangs up f ports/117907 x11 x11-servers/mga_hal broken on 7.0-BETA (GLIBC error) f ports/118217 x11 xorg doesnt find usb mouse when initiated with devd, w o ports/118547 x11 [patch] x11/xdm fails with pam_krb5 o ports/118645 x11 Xorg need realtime priority for mouse work nice o ports/121230 x11 [patch] ports/x11/xkeyboard-config WITHOUT_NLS support o ports/123137 x11 x11/libX11: missing ru_RU.UTF-8 locale o ports/125883 x11 x11-fonts/xorg-fonts-cyrillic is installed, but fonts o ports/125992 x11 devel/imake: remove conflict with unexisting package o ports/126521 x11 [PATCH] graphics/libdrm: update to 2.3.1 16 problems total. From edwin at FreeBSD.org Mon Aug 18 13:21:19 2008 From: edwin at FreeBSD.org (edwin@FreeBSD.org) Date: Mon Aug 18 13:21:39 2008 Subject: ports/126625: [Patch] x11-drivers/xf86-video-openchrome - Update openChrome display driver to 0.2.902 Message-ID: <200808181321.m7IDLIpa096060@freefall.freebsd.org> Synopsis: [Patch] x11-drivers/xf86-video-openchrome - Update openChrome display driver to 0.2.902 Responsible-Changed-From-To: freebsd-ports-bugs->freebsd-x11 Responsible-Changed-By: edwin Responsible-Changed-When: Mon Aug 18 13:21:18 UTC 2008 Responsible-Changed-Why: Over to maintainer (via the GNATS Auto Assign Tool) http://www.freebsd.org/cgi/query-pr.cgi?pr=126625 From lists at jnielsen.net Mon Aug 18 18:58:36 2008 From: lists at jnielsen.net (John Nielsen) Date: Mon Aug 18 18:59:03 2008 Subject: Don't want dualhead but dual graphics cards In-Reply-To: <48A932F2.7040901@bah.homeip.net> References: <48A932F2.7040901@bah.homeip.net> Message-ID: <200808181439.10433.lists@jnielsen.net> On Monday 18 August 2008 04:29:38 am Bernt Hansson wrote: > Hello list > > I've managed to get my 2 Radeon 3870 to work with freebsd 7.0 amd64 > in dual head config wich is an improvement. Before I had to pull out > one of the cards after a reboot now I only need to switch the connector > on the back of the box. > > My question is: how do I get 2 cards to work with the primary screen? Assuming you have both adapters working but coming up as separate displays, you may just need to enable Xinerama to combine them: Section "ServerFlags" Option "Xinerama" "1" EndSection If that's not what you're after then you may need to specify more details. Also consider posting to -questions rather than -x11 as the former has a wider readership and is probably more appropriate for general howto questions. JN > uname -v > FreeBSD 7.0-RELEASE #0: Sun Feb 24 10:35:36 UTC 2008 > root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC > > xorg.conf > > Section "Monitor" > > Identifier "hitachi cm752et" > HorizSync 31-101 > VertRefresh 50-160 > > EndSection > > # Device configured by me: > > Section "Device" > Identifier "his radeon 3870" > Driver "radeon" > BusID "PCI:1:0:0" > #VideoRam 512000 > # Insert Clocks lines here if appropriate > EndSection > > Section "Device" > Identifier "his radeon 3870-2" > Driver "radeon" > BusID "PCI:4:0:0" > #VideoRam 512000 > # Insert Clocks lines here if appropriate > EndSection > Section "Screen" > Identifier "Screen 1" > Device "his radeon 3870" > Monitor "hitachi cm752et" > DefaultDepth 24 > > Subsection "Display" > Depth 8 > Modes "640x480" "800x600" "1024x768" "1280x1024" > "1600x1200" ViewPort 0 0 > EndSubsection > Subsection "Display" > Depth 16 > Modes "640x480" "800x600" "1024x768" "1280x1024" > "1600x1200" ViewPort 0 0 > EndSubsection > Subsection "Display" > Depth 24 > Modes "640x480" "800x600" "1024x768" "1280x1024" > "1600x1200" ViewPort 0 0 > EndSubsection > EndSection > > Section "Screen" > Identifier "Screen 2" > Device "his radeon 3870-2" > Monitor "hitachi cm752et" > DefaultDepth 24 > > Subsection "Display" > Depth 8 > Modes "640x480" "800x600" "1024x768" "1280x1024" > "1600x1200" ViewPort 0 0 > EndSubsection > Subsection "Display" > Depth 16 > Modes "640x480" "800x600" "1024x768" "1280x1024" > "1600x1200" ViewPort 0 0 > EndSubsection > Subsection "Display" > Depth 24 > Modes "640x480" "800x600" "1024x768" "1280x1024" > "1600x1200" ViewPort 0 0 > EndSubsection > EndSection > > Section "ServerLayout" > Identifier "Simple Layout" > > Screen "Screen 1" > Screen "Screen 2" > > InputDevice "Mouse1" "CorePointer" > InputDevice "Keyboard1" "CoreKeyboard" > > EndSection > > _______________________________________________ > freebsd-x11@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-x11 > To unsubscribe, send any mail to "freebsd-x11-unsubscribe@freebsd.org" From vehemens at verizon.net Tue Aug 19 05:34:58 2008 From: vehemens at verizon.net (vehemens) Date: Tue Aug 19 05:35:05 2008 Subject: [CFT] drm updates In-Reply-To: <1219011377.1960.4.camel@localhost> References: <200808142307.32015.vehemens@verizon.net> <1219006437.21310.12.camel@localhost> <1219011377.1960.4.camel@localhost> Message-ID: <200808182240.08874.vehemens@verizon.net> On Sunday 17 August 2008 03:16:17 pm Coleman Kane wrote: > On Sun, 2008-08-17 at 16:53 -0400, Coleman Kane wrote: > > On Sat, 2008-08-16 at 16:35 -0700, vehemens wrote: > > > On Friday 15 August 2008 06:05:13 pm Coleman Kane wrote: > > > > On Fri, 2008-08-15 at 17:05 -0700, vehemens wrote: > > > > > On Friday 15 August 2008 04:13:31 pm Coleman Kane wrote: > > > > > > On Fri, 2008-08-15 at 16:12 -0700, vehemens wrote: > > > > > > > On Friday 15 August 2008 07:41:27 am Coleman Kane wrote: > > > > > > > > ... > > > > > > > > Do you host any of the patches publicly right now? I'd be > > > > > > > > more than happy to test them out and see how well they work > > > > > > > > with my RS690. Right now my GPU is unusable for EXA or DRI > > > > > > > > using xf86-video-ati (intermittently works) or > > > > > > > > xf86-video-radeonhd (never works, displays artifacts, then > > > > > > > > screeches to a halt). > > > > > > > > ... > > > > > > > > > > > > > > After thinking about your stability problems a bit more, > > > > > > > xserver has recently received a number of EXA improvements, > > > > > > > R500 MESA/DRM support is fairly recent, and the drivers are a > > > > > > > moving target a well. Few (none?) of these improvements are in > > > > > > > the official FreeBSD src/ports trees. > > > > > > > > > > > > > > I'll send you a xf86-video-radeonhd tarball that I just created > > > > > > > and tested with my HD 2660 PRO. It may help, but I suspect > > > > > > > that other parts of the X tree will need to be updated as well. > > > > > > > > > > > > I've been tracking the following masters from fd.o git: > > > > > > > > > > > > mesa/drm dri2proto fontsproto glproto inputproto kbproto libX11 > > > > > > libXdamage libXfont libXtst libxcb libxtrans mesa/mesa > > > > > > xorg-server x11proto randrproto xcb-proto xextproto xf86driproto > > > > > > xproto libXext libXi libXrandr libpciaccess libxkbfile libxkbui > > > > > > xf86-video-ati xf86-video-radeonhd xf86-input-keyboard > > > > > > xf86-input-mouse > > > > > > > > > > Interesting. The list is a bit shorter then mine. I don't see > > > > > pixman as well as a few others. Not sure if it matters all that > > > > > much. > > > > > > > > > > When you update mesa, do you update both the dri and libGL ports? > > > > > Ditto for libdrm and kernel drm? > > > > > > > > > > Guess I'll checkout my builds on a RS690 and see what happens. > > > > > > > > D'oh! Yeah, pixman should be included in that list too. I am tracking > > > > it as well. I can't get very far on the latest X.org without it! > > > > > > Almost all combinations of ddx/dri/drm drivers hangs my am64 box. > > > > > > Did get X running by using the radeonhd and dri swrast drivers, as well > > > as removing the other drivers. > > > > > > System reports it has dri, but compiz or glgears doesn't run. > > > > > > What combinations worked for you? > > > > Basically, I can use radeonhd or ati from git master without trouble as > > long as I am not using DRI. The radeonhd driver also freezes my system > > when I try to use EXA. When I use EXA+DRI in the radeonhd driver, I get > > an X root window that has a bunch of artifacts displayed on it. > > Interestingly enough, it seems like it dumps a bitmap of the last image > > of the text console to the root window, the one I would see before the > > video mode switched after running startx. The mouse cursor works for a > > little while, as it seems compiz is beginning to load from the > > gnome-session manager. I never actually see any screen updates occur > > while it is starting up. Then, at some point the system just freezes and > > I need to hard-power-off the laptop, by holding down the power button > > until it is forced off. > > > > With the ati driver and DRI+EXA, running startx causes the X server to > > begin to load, then changes the video mode and blanks the screen. Once > > the screen has been cleared, the server freezes and no loading proceeds. > > I can reset the system by doing an ALT-CTRL-DELETE or by doing > > soft-power-off by pressing, then releasing the power button (which > > FreeBSD-ACPI catches and gracefully shuts the machine down). The > > shutdown process must be held up by something in bufdaemon or other > > kernel service that typically counts down the "remaining" during a > > normal shutdown, of course I can't see which with the X server owning > > the display. Eventually the system is shutdown or restarted. > > > > At some point back in early June, it all started to work for me > > sometimes. Robert Noland threw a bunch of patches my way that fixed > > numerous locking issues in the kernel, which gradually made things more > > reliable for me. At some point in July, some commits to the sources > > resulted in intermittent crashing in the EXA code, which I was able to > > reproduce with/without DRI enabled (always with EXA), when browsing > > various websites with firefox. > > > > Eventually, later on in July, I began to get the results that I > > currently get with DRI enabled. That is to say, it no longer ever works > > for me under the ati driver (freezes X server at startup). I've never > > been able to get radeonhd to give me operational DRI support. If I am > > not using EXA, but have DRI enabled, radeonhd will start up properly, > > but will not display any DRI output (instead just displaying black where > > the DRI stuff should be rendered). > > When I am using the xf86-video-ati driver, and I enable DRI, the server > never finishes starting (video made changes, but the root window and the > cursor is never displayed). The following message is spammed from the > kernel (and ends up in /var/log/messages): > > info: [drm] wait for fifo failed status : 0x9001C100 0x00080000 > > For some reason, through a number of the failures I am now seeing the > following spammed to messages as well, when the server fails: > > Aug 17 17:51:03 erwin kernel: WARNING pid 1414 (initial thread): ioctl > sign-extension ioctl ffffffffc0106407 Aug 17 17:51:03 erwin kernel: WARNING > pid 1414 (initial thread): ioctl sign-extension ioctl ffffffffc0106401 Aug > 17 17:51:03 erwin kernel: WARNING pid 1414 (initial thread): ioctl > sign-extension ioctl ffffffffc0106401 Aug 17 17:51:03 erwin kernel: WARNING > pid 1414 (initial thread): ioctl sign-extension ioctl ffffffffc0106407 Aug > 17 17:51:03 erwin kernel: WARNING pid 1414 (initial thread): ioctl > sign-extension ioctl ffffffffc0286415 Aug 17 17:51:03 erwin kernel: WARNING > pid 1414 (initial thread): ioctl sign-extension ioctl ffffffffc0286415 Aug > 17 17:51:03 erwin kernel: WARNING pid 1414 (initial thread): ioctl > sign-extension ioctl ffffffffc0106426 Aug 17 17:51:03 erwin kernel: WARNING > pid 1414 (initial thread): ioctl sign-extension ioctl ffffffffc0106426 Aug > 17 17:51:03 erwin kernel: WARNING pid 1414 (initial thread): ioctl > sign-extension ioctl ffffffffc0086420 Aug 17 17:51:03 erwin kernel: WARNING > pid 1414 (initial thread): ioctl sign-extension ioctl ffffffff80086422 Aug > 17 17:51:03 erwin kernel: WARNING pid 1414 (initial thread): ioctl > sign-extension ioctl ffffffff8008642a Aug 17 17:51:03 erwin kernel: WARNING > pid 1414 (initial thread): ioctl sign-extension ioctl ffffffffc0106438 Aug > 17 17:51:03 erwin kernel: WARNING pid 1414 (initial thread): ioctl > sign-extension ioctl ffffffffc0286415 > > I took a glance, and the "cmd" field in drm_ioctl_desc is an "unsigned > long", so I am now curious if perhaps this sign extension is resulting > in the wrong "cmd" value being passed to the drm ioctl handler, in my > amd64 case... Upgrading my M2A-VM bios to version 1603 was the trick to getting rid of a nasty flicker problem. Now to repeat the various driver combinations again to see what other effects the update had. On a side note, I haven't been able to run any of the recent xservers without getting a segmentation violation in the mouse driver at startup. Are you seeing this problem as well? works: 2008-07-04 00:04:19 d78bebb20a00e8519788c75c90b467a5750c78be broken: 2008-07-08 02:39:00 66fb253082ea42179180303393e48846208987fa From cokane at FreeBSD.org Tue Aug 19 14:14:33 2008 From: cokane at FreeBSD.org (Coleman Kane) Date: Tue Aug 19 14:14:40 2008 Subject: [CFT] drm updates In-Reply-To: <200808182240.08874.vehemens@verizon.net> References: <200808142307.32015.vehemens@verizon.net> <1219006437.21310.12.camel@localhost> <1219011377.1960.4.camel@localhost> <200808182240.08874.vehemens@verizon.net> Message-ID: <1219155221.1801.3.camel@localhost> On Mon, 2008-08-18 at 22:40 -0700, vehemens wrote: > On Sunday 17 August 2008 03:16:17 pm Coleman Kane wrote: > > On Sun, 2008-08-17 at 16:53 -0400, Coleman Kane wrote: > > > On Sat, 2008-08-16 at 16:35 -0700, vehemens wrote: > > > > On Friday 15 August 2008 06:05:13 pm Coleman Kane wrote: > > > > > On Fri, 2008-08-15 at 17:05 -0700, vehemens wrote: > > > > > > On Friday 15 August 2008 04:13:31 pm Coleman Kane wrote: > > > > > > > On Fri, 2008-08-15 at 16:12 -0700, vehemens wrote: > > > > > > > > On Friday 15 August 2008 07:41:27 am Coleman Kane wrote: > > > > > > > > > ... > > > > > > > > > Do you host any of the patches publicly right now? I'd be > > > > > > > > > more than happy to test them out and see how well they work > > > > > > > > > with my RS690. Right now my GPU is unusable for EXA or DRI > > > > > > > > > using xf86-video-ati (intermittently works) or > > > > > > > > > xf86-video-radeonhd (never works, displays artifacts, then > > > > > > > > > screeches to a halt). > > > > > > > > > ... > > > > > > > > > > > > > > > > After thinking about your stability problems a bit more, > > > > > > > > xserver has recently received a number of EXA improvements, > > > > > > > > R500 MESA/DRM support is fairly recent, and the drivers are a > > > > > > > > moving target a well. Few (none?) of these improvements are in > > > > > > > > the official FreeBSD src/ports trees. > > > > > > > > > > > > > > > > I'll send you a xf86-video-radeonhd tarball that I just created > > > > > > > > and tested with my HD 2660 PRO. It may help, but I suspect > > > > > > > > that other parts of the X tree will need to be updated as well. > > > > > > > > > > > > > > I've been tracking the following masters from fd.o git: > > > > > > > > > > > > > > mesa/drm dri2proto fontsproto glproto inputproto kbproto libX11 > > > > > > > libXdamage libXfont libXtst libxcb libxtrans mesa/mesa > > > > > > > xorg-server x11proto randrproto xcb-proto xextproto xf86driproto > > > > > > > xproto libXext libXi libXrandr libpciaccess libxkbfile libxkbui > > > > > > > xf86-video-ati xf86-video-radeonhd xf86-input-keyboard > > > > > > > xf86-input-mouse > > > > > > > > > > > > Interesting. The list is a bit shorter then mine. I don't see > > > > > > pixman as well as a few others. Not sure if it matters all that > > > > > > much. > > > > > > > > > > > > When you update mesa, do you update both the dri and libGL ports? > > > > > > Ditto for libdrm and kernel drm? > > > > > > > > > > > > Guess I'll checkout my builds on a RS690 and see what happens. > > > > > > > > > > D'oh! Yeah, pixman should be included in that list too. I am tracking > > > > > it as well. I can't get very far on the latest X.org without it! > > > > > > > > Almost all combinations of ddx/dri/drm drivers hangs my am64 box. > > > > > > > > Did get X running by using the radeonhd and dri swrast drivers, as well > > > > as removing the other drivers. > > > > > > > > System reports it has dri, but compiz or glgears doesn't run. > > > > > > > > What combinations worked for you? > > > > > > Basically, I can use radeonhd or ati from git master without trouble as > > > long as I am not using DRI. The radeonhd driver also freezes my system > > > when I try to use EXA. When I use EXA+DRI in the radeonhd driver, I get > > > an X root window that has a bunch of artifacts displayed on it. > > > Interestingly enough, it seems like it dumps a bitmap of the last image > > > of the text console to the root window, the one I would see before the > > > video mode switched after running startx. The mouse cursor works for a > > > little while, as it seems compiz is beginning to load from the > > > gnome-session manager. I never actually see any screen updates occur > > > while it is starting up. Then, at some point the system just freezes and > > > I need to hard-power-off the laptop, by holding down the power button > > > until it is forced off. > > > > > > With the ati driver and DRI+EXA, running startx causes the X server to > > > begin to load, then changes the video mode and blanks the screen. Once > > > the screen has been cleared, the server freezes and no loading proceeds. > > > I can reset the system by doing an ALT-CTRL-DELETE or by doing > > > soft-power-off by pressing, then releasing the power button (which > > > FreeBSD-ACPI catches and gracefully shuts the machine down). The > > > shutdown process must be held up by something in bufdaemon or other > > > kernel service that typically counts down the "remaining" during a > > > normal shutdown, of course I can't see which with the X server owning > > > the display. Eventually the system is shutdown or restarted. > > > > > > At some point back in early June, it all started to work for me > > > sometimes. Robert Noland threw a bunch of patches my way that fixed > > > numerous locking issues in the kernel, which gradually made things more > > > reliable for me. At some point in July, some commits to the sources > > > resulted in intermittent crashing in the EXA code, which I was able to > > > reproduce with/without DRI enabled (always with EXA), when browsing > > > various websites with firefox. > > > > > > Eventually, later on in July, I began to get the results that I > > > currently get with DRI enabled. That is to say, it no longer ever works > > > for me under the ati driver (freezes X server at startup). I've never > > > been able to get radeonhd to give me operational DRI support. If I am > > > not using EXA, but have DRI enabled, radeonhd will start up properly, > > > but will not display any DRI output (instead just displaying black where > > > the DRI stuff should be rendered). > > > > When I am using the xf86-video-ati driver, and I enable DRI, the server > > never finishes starting (video made changes, but the root window and the > > cursor is never displayed). The following message is spammed from the > > kernel (and ends up in /var/log/messages): > > > > info: [drm] wait for fifo failed status : 0x9001C100 0x00080000 > > > > For some reason, through a number of the failures I am now seeing the > > following spammed to messages as well, when the server fails: > > > > Aug 17 17:51:03 erwin kernel: WARNING pid 1414 (initial thread): ioctl > > sign-extension ioctl ffffffffc0106407 Aug 17 17:51:03 erwin kernel: WARNING > > pid 1414 (initial thread): ioctl sign-extension ioctl ffffffffc0106401 Aug > > 17 17:51:03 erwin kernel: WARNING pid 1414 (initial thread): ioctl > > sign-extension ioctl ffffffffc0106401 Aug 17 17:51:03 erwin kernel: WARNING > > pid 1414 (initial thread): ioctl sign-extension ioctl ffffffffc0106407 Aug > > 17 17:51:03 erwin kernel: WARNING pid 1414 (initial thread): ioctl > > sign-extension ioctl ffffffffc0286415 Aug 17 17:51:03 erwin kernel: WARNING > > pid 1414 (initial thread): ioctl sign-extension ioctl ffffffffc0286415 Aug > > 17 17:51:03 erwin kernel: WARNING pid 1414 (initial thread): ioctl > > sign-extension ioctl ffffffffc0106426 Aug 17 17:51:03 erwin kernel: WARNING > > pid 1414 (initial thread): ioctl sign-extension ioctl ffffffffc0106426 Aug > > 17 17:51:03 erwin kernel: WARNING pid 1414 (initial thread): ioctl > > sign-extension ioctl ffffffffc0086420 Aug 17 17:51:03 erwin kernel: WARNING > > pid 1414 (initial thread): ioctl sign-extension ioctl ffffffff80086422 Aug > > 17 17:51:03 erwin kernel: WARNING pid 1414 (initial thread): ioctl > > sign-extension ioctl ffffffff8008642a Aug 17 17:51:03 erwin kernel: WARNING > > pid 1414 (initial thread): ioctl sign-extension ioctl ffffffffc0106438 Aug > > 17 17:51:03 erwin kernel: WARNING pid 1414 (initial thread): ioctl > > sign-extension ioctl ffffffffc0286415 > > > > I took a glance, and the "cmd" field in drm_ioctl_desc is an "unsigned > > long", so I am now curious if perhaps this sign extension is resulting > > in the wrong "cmd" value being passed to the drm ioctl handler, in my > > amd64 case... > > Upgrading my M2A-VM bios to version 1603 was the trick to getting rid of a > nasty flicker problem. Now to repeat the various driver combinations again > to see what other effects the update had. > > On a side note, I haven't been able to run any of the recent xservers without > getting a segmentation violation in the mouse driver at startup. Are you > seeing this problem as well? > works: > 2008-07-04 00:04:19 > d78bebb20a00e8519788c75c90b467a5750c78be > broken: > 2008-07-08 02:39:00 > 66fb253082ea42179180303393e48846208987fa Yeah, you'll need to update to the latest inputproto, libXi, and the xf86-input-mouse driver. The bsd-specific mouse bits gots moved around and ar no longer in the xserver. They are now part of the mouse driver code, iirc. I needed commit f3f0a5520ed7edac3867a97f5a001b91c870563e to xf86-input-mouse. The message that the server throws is highly unhelpful in this situation. -- Coleman Kane -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20080819/f4454abd/attachment.pgp From vova at fbsd.ru Wed Aug 20 07:14:14 2008 From: vova at fbsd.ru (Vladimir Grebenschikov) Date: Wed Aug 20 07:14:20 2008 Subject: [CFT] drm updates In-Reply-To: <1218675844.1899.18.camel@wombat.2hip.net> References: <1218675844.1899.18.camel@wombat.2hip.net> Message-ID: <1219215167.1753.9.camel@localhost> On Wed, 2008-08-13 at 21:04 -0400, Robert Noland wrote: I can also confirm that git radeonhd driver works with these patches with 3D and 3D acceleration (mesa from git still required). Will be happy to see these patches in tree. > I have prepared a set of patches for drm kernel modules against -CURRENT > and -STABLE. I would like to get this into HEAD fairly soon. > > This update has the latest vblank rework bits in it, so if you have > hardware that can disable vblank irq's (radeon, intel) you should see > the irq counts drop if there are no vblank consumers running. > > i915 suspend/resume support is included. > > For Intel, this should pick up support for the g33 chipsets as well. > > Lots of other fixes here and there... > > The patches are located at http://people.freebsd.org/~rnoland > > robert. > -- Vladimir B. Grebenschikov vova@fbsd.ru From vehemens at verizon.net Wed Aug 20 08:43:03 2008 From: vehemens at verizon.net (vehemens) Date: Wed Aug 20 08:43:09 2008 Subject: [CFT] drm updates In-Reply-To: <1219155221.1801.3.camel@localhost> References: <200808142307.32015.vehemens@verizon.net> <200808182240.08874.vehemens@verizon.net> <1219155221.1801.3.camel@localhost> Message-ID: <200808200148.23286.vehemens@verizon.net> On Tuesday 19 August 2008 07:13:41 am Coleman Kane wrote: > On Mon, 2008-08-18 at 22:40 -0700, vehemens wrote: > ... > > > > On a side note, I haven't been able to run any of the recent xservers > > without getting a segmentation violation in the mouse driver at startup. > > Are you seeing this problem as well? > > works: > > 2008-07-04 00:04:19 > > d78bebb20a00e8519788c75c90b467a5750c78be > > broken: > > 2008-07-08 02:39:00 > > 66fb253082ea42179180303393e48846208987fa > > Yeah, you'll need to update to the latest inputproto, libXi, and the > xf86-input-mouse driver. The bsd-specific mouse bits gots moved around > and ar no longer in the xserver. They are now part of the mouse driver > code, iirc. > > I needed commit f3f0a5520ed7edac3867a97f5a001b91c870563e to > xf86-input-mouse. The message that the server throws is highly unhelpful > in this situation. I was running the latest version of inputproto, libXi, and xf86-input-mouse at the time. I have just updated inputproto, libXi and the radeonhd with the latest round of changes. I already had the xf86-input-mouse changes. I'm still seeing problems. What's the commit number and date of the xserver your running? From cokane at FreeBSD.org Wed Aug 20 15:11:23 2008 From: cokane at FreeBSD.org (Coleman Kane) Date: Wed Aug 20 15:11:30 2008 Subject: [CFT] drm updates In-Reply-To: <200808200148.23286.vehemens@verizon.net> References: <200808142307.32015.vehemens@verizon.net> <200808182240.08874.vehemens@verizon.net> <1219155221.1801.3.camel@localhost> <200808200148.23286.vehemens@verizon.net> Message-ID: <1219245029.1686.2.camel@localhost> On Wed, 2008-08-20 at 01:48 -0700, vehemens wrote: > On Tuesday 19 August 2008 07:13:41 am Coleman Kane wrote: > > On Mon, 2008-08-18 at 22:40 -0700, vehemens wrote: > > ... > > > > > > On a side note, I haven't been able to run any of the recent xservers > > > without getting a segmentation violation in the mouse driver at startup. > > > Are you seeing this problem as well? > > > works: > > > 2008-07-04 00:04:19 > > > d78bebb20a00e8519788c75c90b467a5750c78be > > > broken: > > > 2008-07-08 02:39:00 > > > 66fb253082ea42179180303393e48846208987fa > > > > Yeah, you'll need to update to the latest inputproto, libXi, and the > > xf86-input-mouse driver. The bsd-specific mouse bits gots moved around > > and ar no longer in the xserver. They are now part of the mouse driver > > code, iirc. > > > > I needed commit f3f0a5520ed7edac3867a97f5a001b91c870563e to > > xf86-input-mouse. The message that the server throws is highly unhelpful > > in this situation. > > I was running the latest version of inputproto, libXi, and xf86-input-mouse at > the time. I have just updated inputproto, libXi and the radeonhd with the > latest round of changes. I already had the xf86-input-mouse changes. > > I'm still seeing problems. > > What's the commit number and date of the xserver your running? > Try turning up the verbosity on your X-server. I am actually using the synaptics driver for my touchpad, and not the standard moused driver as I just remembered. I think I do get the crash after all if I plug in my USB mice... I wrestled with the problem almost a month ago so it is kind of foggy for me now. I think, though, that the standard mouse driver was crashing in the X server, according to GDB. -- Coleman Kane -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20080820/6dd22ac3/attachment.pgp From garga at FreeBSD.org Wed Aug 20 18:05:24 2008 From: garga at FreeBSD.org (Renato Botelho) Date: Wed Aug 20 18:05:54 2008 Subject: xkeyboard-config update to 1.3 Message-ID: <20080820174001.GA3125@bluepex.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I've made a patch to update xkeyboard-config from 1.2 -> 1.3. I'm using it on my desktop (i386 8.0-CURRENT) since yesterday without problems. Here is the patch: http://pastebin.com/f62e294b Could you please review? If it's OK just let me know if you people will commit or if I have approval to do it. Thanks - -- Renato Botelho GnuPG Key: http://www.FreeBSD.org/~garga/pubkey.asc To generalize is to be an idiot. -- William Blake -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkisVvEACgkQ6CRbiSJE7anqdQCgnbvpexnGmsak1M5WQtiU5lfl e8oAnA00gROxH4gcFkZp+EutTT6lYXxR =8Oly -----END PGP SIGNATURE----- From rnoland at FreeBSD.org Thu Aug 21 03:01:07 2008 From: rnoland at FreeBSD.org (Robert Noland) Date: Thu Aug 21 03:01:13 2008 Subject: [CFT] drm updates In-Reply-To: <20080820155921.GB76646@megatron.madpilot.net> References: <1218675844.1899.18.camel@wombat.2hip.net> <20080820155921.GB76646@megatron.madpilot.net> Message-ID: <1219287657.2041.1.camel@wombat.2hip.net> On Wed, 2008-08-20 at 17:59 +0200, Guido Falsi wrote: > On Wed, Aug 13, 2008 at 09:04:04PM -0400, Robert Noland wrote: > > I have prepared a set of patches for drm kernel modules against -CURRENT > > and -STABLE. I would like to get this into HEAD fairly soon. > > > > This update has the latest vblank rework bits in it, so if you have > > hardware that can disable vblank irq's (radeon, intel) you should see > > the irq counts drop if there are no vblank consumers running. > > > > i915 suspend/resume support is included. > > > > For Intel, this should pick up support for the g33 chipsets as well. > > > > Lots of other fixes here and there... > > > > The patches are located at http://people.freebsd.org/~rnoland > > > > robert. > > Hello! > > Having an HP DC7800 here at work (which has an intel Q35 on board) I > grabbed your patches and gave them a shot. > > after compiling the kernel (had to add dev/drm/i915_suspend.c to > conf/files, the patch did not do this) I rebooted and it now looks all > is going like a charm. Ok, I've uploaded a new set of patches. These fix all of the potentially blocking issues that I am aware of. Those were: The locking issue that Kostik pointed out. I didn't fix the cosmetic one, none of that code is used. There was a panic on intel hardware when restarting X. conf/files update is now included. I did commit a fix to libdrm (note that isn't drm modules) in git which addressed an issue with ioctl's on amd64. We will need to track that patch locally for the time being. I have not heard of any other regressions or critical issues, so I'll let this round of patches bake for a few days and probably try and push it into HEAD sometime next week. robert. > 2d and 3d acceleration works, and is much better than before. xorg > reports using drm features and in a day I have had no troubles. > I use this machine as a workstation, I have not stressed it much though. > > I have experimented with xscreensaver haks mainly. I will try the > composite extension as soon as I have time. > > If you're interested in any further information or have some tests which > you would like performed, please ask me. > > Thank you a lot for your work on FreeBSD! > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20080821/3e0a2e40/attachment.pgp From flz at xbsd.org Thu Aug 21 08:04:27 2008 From: flz at xbsd.org (Florent Thoumie) Date: Thu Aug 21 08:04:34 2008 Subject: xkeyboard-config update to 1.3 In-Reply-To: <20080820174001.GA3125@bluepex.com> References: <20080820174001.GA3125@bluepex.com> Message-ID: On Wed, Aug 20, 2008 at 6:40 PM, Renato Botelho wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > > I've made a patch to update xkeyboard-config from 1.2 -> 1.3. I'm using it > on my desktop (i386 8.0-CURRENT) since yesterday without problems. > > Here is the patch: http://pastebin.com/f62e294b > > Could you please review? If it's OK just let me know if you people will > commit or if I have approval to do it. Go ahead. -- Florent Thoumie flz@FreeBSD.org FreeBSD Committer From matt at chronos.org.uk Thu Aug 21 13:56:13 2008 From: matt at chronos.org.uk (Matt Dawson) Date: Thu Aug 21 13:56:20 2008 Subject: [CFT] drm updates In-Reply-To: <20080821120021.90B5610656E5@hub.freebsd.org> References: <20080821120021.90B5610656E5@hub.freebsd.org> Message-ID: <200808211456.01947.matt@chronos.org.uk> On Thursday 21 August 2008 13:00:21 rnoland@freebsd.org wrote: > Ok, I've uploaded a new set of patches. ?These fix all of the > potentially blocking issues that I am aware of. No regressions on my Radeons with this patchset at all. Everything is still working fine. -- Matt Dawson matt@chronos.org.uk MTD15-RIPE From rnoland at FreeBSD.org Sun Aug 24 02:17:10 2008 From: rnoland at FreeBSD.org (Robert Noland) Date: Sun Aug 24 02:17:20 2008 Subject: [CFT] drm updates In-Reply-To: <200808211456.01947.matt@chronos.org.uk> References: <20080821120021.90B5610656E5@hub.freebsd.org> <200808211456.01947.matt@chronos.org.uk> Message-ID: <1219544221.3430.37.camel@wombat.2hip.net> I've uploaded a final patch set to: http://people.freebsd.org/~rnoland I have committed this version to -CURRENT, but patches are available for RELENG_7 as well. This version mostly just fixes a long standing memory leak. All of the reports for radeon have been good. I'm still seeing a few odd things with Intel though. The most severe issue is on my 965gm. After restarting X, it will hang in a way that I have never seen before... The small amount of evidence that I have been able to collect suggests that this may be due to mesa trashing the hardware. I've spent a couple of days trying to figure out exactly what could be wrong. This morning I rebuilt my kernel with a stock drm from src and I got exactly the same hang. Since this update does help lots of people and doesn't seem to make things worse than they were to begin with, I went ahead and committed it. I was incorrect about the patch to libdrm... It isn't needed in 2.3.1 and it is already committed upstream. I'll commit that update to ports soon also. It, along with a recent xf86-video-* are needed to enable the new vblank behavior, which will disable vblank interrupts if there are no active consumers. robert. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20080824/81ca282c/attachment.pgp From onemda at gmail.com Sun Aug 24 10:54:24 2008 From: onemda at gmail.com (Paul B. Mahol) Date: Sun Aug 24 10:54:31 2008 Subject: [CFT] drm updates In-Reply-To: <1219544221.3430.37.camel@wombat.2hip.net> References: <20080821120021.90B5610656E5@hub.freebsd.org> <200808211456.01947.matt@chronos.org.uk> <1219544221.3430.37.camel@wombat.2hip.net> Message-ID: <3a142e750808240329n55d1b95bnd701dde4892c6c14@mail.gmail.com> On 8/24/08, Robert Noland wrote: > I've uploaded a final patch set to: > > http://people.freebsd.org/~rnoland > > I have committed this version to -CURRENT, but patches are available for > RELENG_7 as well. > > This version mostly just fixes a long standing memory leak. > > All of the reports for radeon have been good. I'm still seeing a few > odd things with Intel though. The most severe issue is on my 965gm. > After restarting X, it will hang in a way that I have never seen > before... The small amount of evidence that I have been able to collect > suggests that this may be due to mesa trashing the hardware. I've spent > a couple of days trying to figure out exactly what could be wrong. This > morning I rebuilt my kernel with a stock drm from src and I got exactly > the same hang. Since this update does help lots of people and doesn't > seem to make things worse than they were to begin with, I went ahead and > committed it. > > I was incorrect about the patch to libdrm... It isn't needed in 2.3.1 > and it is already committed upstream. I'll commit that update to ports > soon also. It, along with a recent xf86-video-* are needed to enable > the new vblank behavior, which will disable vblank interrupts if there > are no active consumers. > > robert. > Do I need to update some ports? because with kernel from HEAD I have encountered problems when drm is loaded (agp + drm + i915) astro/stellarium caused deadlock, only mouse pointer could move, if I did not started it, system will panic anyway after some time. I did not yet tested vty switching,.... related hardware: hostb0@pci0:0:0:0: class=0x060000 card=0x30a2103c chip=0x27a08086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '955XM/945GM/PM/GMS/940GML Express Processor to DRAM Controller' class = bridge subclass = HOST-PCI vgapci0@pci0:0:2:0: class=0x030000 card=0x30a2103c chip=0x27a28086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile 945GM/GU Express Integrated Graphics Controller' class = display subclass = VGA vgapci1@pci0:0:2:1: class=0x038000 card=0x30a2103c chip=0x27a68086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile 945GM/GU Express Integrated Graphics Controller' class = display also if Xorg is never started, trying to unload agp.ko (after unloading i915.ko and drm.ko) module will cause panic. From onemda at gmail.com Sun Aug 24 15:12:41 2008 From: onemda at gmail.com (Paul B. Mahol) Date: Sun Aug 24 15:12:48 2008 Subject: [CFT] drm updates In-Reply-To: <3a142e750808240329n55d1b95bnd701dde4892c6c14@mail.gmail.com> References: <20080821120021.90B5610656E5@hub.freebsd.org> <200808211456.01947.matt@chronos.org.uk> <1219544221.3430.37.camel@wombat.2hip.net> <3a142e750808240329n55d1b95bnd701dde4892c6c14@mail.gmail.com> Message-ID: <3a142e750808240812q50c1237as8c391dc35fc98ac0@mail.gmail.com> On 8/24/08, Paul B. Mahol wrote: > On 8/24/08, Robert Noland wrote: >> I've uploaded a final patch set to: >> >> http://people.freebsd.org/~rnoland >> >> I have committed this version to -CURRENT, but patches are available for >> RELENG_7 as well. >> >> This version mostly just fixes a long standing memory leak. >> >> All of the reports for radeon have been good. I'm still seeing a few >> odd things with Intel though. The most severe issue is on my 965gm. >> After restarting X, it will hang in a way that I have never seen >> before... The small amount of evidence that I have been able to collect >> suggests that this may be due to mesa trashing the hardware. I've spent >> a couple of days trying to figure out exactly what could be wrong. This >> morning I rebuilt my kernel with a stock drm from src and I got exactly >> the same hang. Since this update does help lots of people and doesn't >> seem to make things worse than they were to begin with, I went ahead and >> committed it. >> >> I was incorrect about the patch to libdrm... It isn't needed in 2.3.1 >> and it is already committed upstream. I'll commit that update to ports >> soon also. It, along with a recent xf86-video-* are needed to enable >> the new vblank behavior, which will disable vblank interrupts if there >> are no active consumers. >> >> robert. >> > > Do I need to update some ports? because with kernel from HEAD I have > encountered problems when drm is loaded (agp + drm + i915) > astro/stellarium caused deadlock, only mouse pointer could move, if I did > not > started it, system will panic anyway after some time. I did not yet tested > vty switching,.... > > related hardware: > > hostb0@pci0:0:0:0: class=0x060000 card=0x30a2103c chip=0x27a08086 > rev=0x03 > hdr=0x00 > vendor = 'Intel Corporation' > device = '955XM/945GM/PM/GMS/940GML Express Processor to DRAM > Controller' > class = bridge > subclass = HOST-PCI > vgapci0@pci0:0:2:0: class=0x030000 card=0x30a2103c chip=0x27a28086 > rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Mobile 945GM/GU Express Integrated Graphics Controller' > class = display > subclass = VGA > vgapci1@pci0:0:2:1: class=0x038000 card=0x30a2103c chip=0x27a68086 > rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Mobile 945GM/GU Express Integrated Graphics Controller' > class = display > > also if Xorg is never started, trying to unload agp.ko > (after unloading i915.ko and drm.ko) module will cause panic. > Comparing to xf86-video-i815, xf86-video-intel is more stable (it doesnt panic, crash, hardlocks, ...), but still locks display when starting astro/stellarium. From rnoland at FreeBSD.org Sun Aug 24 15:46:11 2008 From: rnoland at FreeBSD.org (Robert Noland) Date: Sun Aug 24 15:46:17 2008 Subject: [CFT] drm updates In-Reply-To: <3a142e750808240329n55d1b95bnd701dde4892c6c14@mail.gmail.com> References: <20080821120021.90B5610656E5@hub.freebsd.org> <200808211456.01947.matt@chronos.org.uk> <1219544221.3430.37.camel@wombat.2hip.net> <3a142e750808240329n55d1b95bnd701dde4892c6c14@mail.gmail.com> Message-ID: <1219592761.3430.53.camel@wombat.2hip.net> On Sun, 2008-08-24 at 12:29 +0200, Paul B. Mahol wrote: > On 8/24/08, Robert Noland wrote: > > I've uploaded a final patch set to: > > > > http://people.freebsd.org/~rnoland > > > > I have committed this version to -CURRENT, but patches are available for > > RELENG_7 as well. > > > > This version mostly just fixes a long standing memory leak. > > > > All of the reports for radeon have been good. I'm still seeing a few > > odd things with Intel though. The most severe issue is on my 965gm. > > After restarting X, it will hang in a way that I have never seen > > before... The small amount of evidence that I have been able to collect > > suggests that this may be due to mesa trashing the hardware. I've spent > > a couple of days trying to figure out exactly what could be wrong. This > > morning I rebuilt my kernel with a stock drm from src and I got exactly > > the same hang. Since this update does help lots of people and doesn't > > seem to make things worse than they were to begin with, I went ahead and > > committed it. > > > > I was incorrect about the patch to libdrm... It isn't needed in 2.3.1 > > and it is already committed upstream. I'll commit that update to ports > > soon also. It, along with a recent xf86-video-* are needed to enable > > the new vblank behavior, which will disable vblank interrupts if there > > are no active consumers. > > > > robert. > > > > Do I need to update some ports? because with kernel from HEAD I have > encountered problems when drm is loaded (agp + drm + i915) > astro/stellarium caused deadlock, only mouse pointer could move, if I did not > started it, system will panic anyway after some time. I did not yet tested > vty switching,.... As I stated, intel is still a little quirky... I'll try and look into the interaction with agp. The lockup you describe is the same as I am seeing on my 965, but I only get it after a restart. Does your xorg.log indicate that pre-existing errors in hardware state are present? specifically ESR being set? If I'm reading the docs correctly, if ESR = 0x01 it is a parse error, which suggests that mesa may bee trashing the hardware. I did find a patch from one of the intel guys in the maze of branches that might impact this, which I'm going to test out today. I use gdm to start everything up and as long as I don't log out or restart X everything works fine. That doesn't really make sense to me, but I'm still digging for a solution. From the reports I've gotten, radeon does not suffer this same issue. robert. > related hardware: > > hostb0@pci0:0:0:0: class=0x060000 card=0x30a2103c chip=0x27a08086 rev=0x03 > hdr=0x00 > vendor = 'Intel Corporation' > device = '955XM/945GM/PM/GMS/940GML Express Processor to DRAM > Controller' > class = bridge > subclass = HOST-PCI > vgapci0@pci0:0:2:0: class=0x030000 card=0x30a2103c chip=0x27a28086 > rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Mobile 945GM/GU Express Integrated Graphics Controller' > class = display > subclass = VGA > vgapci1@pci0:0:2:1: class=0x038000 card=0x30a2103c chip=0x27a68086 > rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Mobile 945GM/GU Express Integrated Graphics Controller' > class = display > > also if Xorg is never started, trying to unload agp.ko > (after unloading i915.ko and drm.ko) module will cause panic. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20080824/9cc4b3a6/attachment.pgp From rnoland at FreeBSD.org Sun Aug 24 15:55:57 2008 From: rnoland at FreeBSD.org (Robert Noland) Date: Sun Aug 24 15:56:03 2008 Subject: [CFT] drm updates In-Reply-To: <3a142e750808240812q50c1237as8c391dc35fc98ac0@mail.gmail.com> References: <20080821120021.90B5610656E5@hub.freebsd.org> <200808211456.01947.matt@chronos.org.uk> <1219544221.3430.37.camel@wombat.2hip.net> <3a142e750808240329n55d1b95bnd701dde4892c6c14@mail.gmail.com> <3a142e750808240812q50c1237as8c391dc35fc98ac0@mail.gmail.com> Message-ID: <1219593348.3430.64.camel@wombat.2hip.net> On Sun, 2008-08-24 at 17:12 +0200, Paul B. Mahol wrote: > On 8/24/08, Paul B. Mahol wrote: > > On 8/24/08, Robert Noland wrote: > >> I've uploaded a final patch set to: > >> > >> http://people.freebsd.org/~rnoland > >> > >> I have committed this version to -CURRENT, but patches are available for > >> RELENG_7 as well. > >> > >> This version mostly just fixes a long standing memory leak. > >> > >> All of the reports for radeon have been good. I'm still seeing a few > >> odd things with Intel though. The most severe issue is on my 965gm. > >> After restarting X, it will hang in a way that I have never seen > >> before... The small amount of evidence that I have been able to collect > >> suggests that this may be due to mesa trashing the hardware. I've spent > >> a couple of days trying to figure out exactly what could be wrong. This > >> morning I rebuilt my kernel with a stock drm from src and I got exactly > >> the same hang. Since this update does help lots of people and doesn't > >> seem to make things worse than they were to begin with, I went ahead and > >> committed it. > >> > >> I was incorrect about the patch to libdrm... It isn't needed in 2.3.1 > >> and it is already committed upstream. I'll commit that update to ports > >> soon also. It, along with a recent xf86-video-* are needed to enable > >> the new vblank behavior, which will disable vblank interrupts if there > >> are no active consumers. > >> > >> robert. > >> > > > > Do I need to update some ports? because with kernel from HEAD I have > > encountered problems when drm is loaded (agp + drm + i915) > > astro/stellarium caused deadlock, only mouse pointer could move, if I did > > not > > started it, system will panic anyway after some time. I did not yet tested > > vty switching,.... > > > > related hardware: > > > > hostb0@pci0:0:0:0: class=0x060000 card=0x30a2103c chip=0x27a08086 > > rev=0x03 > > hdr=0x00 > > vendor = 'Intel Corporation' > > device = '955XM/945GM/PM/GMS/940GML Express Processor to DRAM > > Controller' > > class = bridge > > subclass = HOST-PCI > > vgapci0@pci0:0:2:0: class=0x030000 card=0x30a2103c chip=0x27a28086 > > rev=0x03 hdr=0x00 > > vendor = 'Intel Corporation' > > device = 'Mobile 945GM/GU Express Integrated Graphics Controller' > > class = display > > subclass = VGA > > vgapci1@pci0:0:2:1: class=0x038000 card=0x30a2103c chip=0x27a68086 > > rev=0x03 hdr=0x00 > > vendor = 'Intel Corporation' > > device = 'Mobile 945GM/GU Express Integrated Graphics Controller' > > class = display > > > > also if Xorg is never started, trying to unload agp.ko > > (after unloading i915.ko and drm.ko) module will cause panic. > > > > Comparing to xf86-video-i815, xf86-video-intel is more stable (it doesnt panic, crash, hardlocks, ...), but still locks display when starting astro/stellarium. Oh, yes you should be using xf86-video-intel. robert. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20080824/b303954d/attachment.pgp From onemda at gmail.com Sun Aug 24 17:06:17 2008 From: onemda at gmail.com (Paul B. Mahol) Date: Sun Aug 24 17:06:23 2008 Subject: [CFT] drm updates In-Reply-To: <1219592761.3430.53.camel@wombat.2hip.net> References: <20080821120021.90B5610656E5@hub.freebsd.org> <200808211456.01947.matt@chronos.org.uk> <1219544221.3430.37.camel@wombat.2hip.net> <3a142e750808240329n55d1b95bnd701dde4892c6c14@mail.gmail.com> <1219592761.3430.53.camel@wombat.2hip.net> Message-ID: <3a142e750808241006i745bc2bcn57511695cf2ce5d0@mail.gmail.com> On 8/24/08, Robert Noland wrote: > On Sun, 2008-08-24 at 12:29 +0200, Paul B. Mahol wrote: >> On 8/24/08, Robert Noland wrote: >> > I've uploaded a final patch set to: >> > >> > http://people.freebsd.org/~rnoland >> > >> > I have committed this version to -CURRENT, but patches are available for >> > RELENG_7 as well. >> > >> > This version mostly just fixes a long standing memory leak. >> > >> > All of the reports for radeon have been good. I'm still seeing a few >> > odd things with Intel though. The most severe issue is on my 965gm. >> > After restarting X, it will hang in a way that I have never seen >> > before... The small amount of evidence that I have been able to collect >> > suggests that this may be due to mesa trashing the hardware. I've spent >> > a couple of days trying to figure out exactly what could be wrong. This >> > morning I rebuilt my kernel with a stock drm from src and I got exactly >> > the same hang. Since this update does help lots of people and doesn't >> > seem to make things worse than they were to begin with, I went ahead and >> > committed it. >> > >> > I was incorrect about the patch to libdrm... It isn't needed in 2.3.1 >> > and it is already committed upstream. I'll commit that update to ports >> > soon also. It, along with a recent xf86-video-* are needed to enable >> > the new vblank behavior, which will disable vblank interrupts if there >> > are no active consumers. >> > >> > robert. >> > >> >> Do I need to update some ports? because with kernel from HEAD I have >> encountered problems when drm is loaded (agp + drm + i915) >> astro/stellarium caused deadlock, only mouse pointer could move, if I did >> not >> started it, system will panic anyway after some time. I did not yet tested >> vty switching,.... > > As I stated, intel is still a little quirky... I'll try and look into > the interaction with agp. The lockup you describe is the same as I am > seeing on my 965, but I only get it after a restart. Does your xorg.log > indicate that pre-existing errors in hardware state are present? > specifically ESR being set? If I'm reading the docs correctly, if ESR = > 0x01 it is a parse error, which suggests that mesa may bee trashing the > hardware. I did find a patch from one of the intel guys in the maze of > branches that might impact this, which I'm going to test out today. > Restarting and vty switching works fine. Only when really using drm lock happens. Xorg.0.log attached. esr is 0x0000 xf86-video-intel have bug with xset: "xset dpms force off" will keep screen blank/off until I switch to console (no blank/off any more in console) and than switch back to Xorg. > I use gdm to start everything up and as long as I don't log out or > restart X everything works fine. That doesn't really make sense to me, > but I'm still digging for a solution. From the reports I've gotten, > radeon does not suffer this same issue. > > robert. > >> related hardware: >> >> hostb0@pci0:0:0:0: class=0x060000 card=0x30a2103c chip=0x27a08086 >> rev=0x03 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = '955XM/945GM/PM/GMS/940GML Express Processor to DRAM >> Controller' >> class = bridge >> subclass = HOST-PCI >> vgapci0@pci0:0:2:0: class=0x030000 card=0x30a2103c chip=0x27a28086 >> rev=0x03 hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'Mobile 945GM/GU Express Integrated Graphics Controller' >> class = display >> subclass = VGA >> vgapci1@pci0:0:2:1: class=0x038000 card=0x30a2103c chip=0x27a68086 >> rev=0x03 hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'Mobile 945GM/GU Express Integrated Graphics Controller' >> class = display >> >> also if Xorg is never started, trying to unload agp.ko >> (after unloading i915.ko and drm.ko) module will cause panic. > -------------- next part -------------- A non-text attachment was scrubbed... Name: Xorg.0.log Type: application/octet-stream Size: 48069 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20080824/48c972af/Xorg.0.obj From jimmiejaz at gmail.com Sun Aug 24 18:48:13 2008 From: jimmiejaz at gmail.com (Jimmie James) Date: Sun Aug 24 18:48:43 2008 Subject: [CFT] drm updates Message-ID: <48B1A590.2040701@gmail.com> Is this the type of lockup you're seeing? Error in I830WaitLpRing(), timeout for 2 seconds pgetbl_ctl: 0x3ffc0001getbl_err: 0x0 ipeir: 0 iphdr: 7d000006 LP ring tail: 1afa0 head: 1ad64 len: 1f001 start 0 eir: 0 esr: 0 emr: ffff instdone: fa41 instpm: 0 memmode: 108 instps: 800f00c4 hwstam: fffe ier: 2 imr: 8 iir: 80 Ring at virtual 0x2884d000 head 0x1ad64 tail 0x1afa0 count 143 (WW) intel(0): PRB0_CTL (0x0001f001) indicates ring buffer enabled (WW) intel(0): PRB0_HEAD (0x13e1ad64) and PRB0_TAIL (0x0001afa8) indicate ring buffer not flushed (WW) intel(0): Existing errors found in hardware state. vgapci0@pci0:0:2:0: class=0x030000 card=0x25821043 chip=0x25828086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '82915G/GV/GL, 82910GL Integrated Graphics Device' class = display subclass = VGA vgapci1@pci0:0:2:1: class=0x038000 card=0x25821043 chip=0x27828086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '82915G Graphics device: 82915G/GV/910GL Express Chipset Family' class = display >On Sun, 2008-08-24 at 12:29 +0200, Paul B. Mahol wrote: > On 8/24/08, Robert Noland wrote: > > I've uploaded a final patch set to: > > > > http://people.freebsd.org/~rnoland > > > > I have committed this version to -CURRENT, but patches are available fo= r > > RELENG_7 as well. > > > > This version mostly just fixes a long standing memory leak. > > > > All of the reports for radeon have been good. I'm still seeing a few > > odd things with Intel though. The most severe issue is on my 965gm. > > After restarting X, it will hang in a way that I have never seen > > before... The small amount of evidence that I have been able to collec= t > > suggests that this may be due to mesa trashing the hardware. I've spen= t > > a couple of days trying to figure out exactly what could be wrong. Thi= s > > morning I rebuilt my kernel with a stock drm from src and I got exactly > > the same hang. Since this update does help lots of people and doesn't > > seem to make things worse than they were to begin with, I went ahead an= d > > committed it. > > > > I was incorrect about the patch to libdrm... It isn't needed in 2.3.1 > > and it is already committed upstream. I'll commit that update to ports > > soon also. It, along with a recent xf86-video-* are needed to enable > > the new vblank behavior, which will disable vblank interrupts if there > > are no active consumers. > > > > robert. > > >=20 > Do I need to update some ports? because with kernel from HEAD I have > encountered problems when drm is loaded (agp + drm + i915) > astro/stellarium caused deadlock, only mouse pointer could move, if I did= not > started it, system will panic anyway after some time. I did not yet teste= d > vty switching,.... -- Over the years I've come to regard you as people I've met. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From edwin at FreeBSD.org Mon Aug 25 01:26:23 2008 From: edwin at FreeBSD.org (edwin@FreeBSD.org) Date: Mon Aug 25 01:26:35 2008 Subject: ports/126812: x11-drivers/xf86-video-ati - System freeze when exiting X server when using ati or radeon drivers on AMD 780G Message-ID: <200808250126.m7P1QNH3040056@freefall.freebsd.org> Synopsis: x11-drivers/xf86-video-ati - System freeze when exiting X server when using ati or radeon drivers on AMD 780G Responsible-Changed-From-To: freebsd-ports-bugs->freebsd-x11 Responsible-Changed-By: edwin Responsible-Changed-When: Mon Aug 25 01:26:22 UTC 2008 Responsible-Changed-Why: Over to maintainer (via the GNATS Auto Assign Tool) http://www.freebsd.org/cgi/query-pr.cgi?pr=126812 From cadfred at electronicbox.net Mon Aug 25 01:31:09 2008 From: cadfred at electronicbox.net (Fred) Date: Mon Aug 25 01:31:15 2008 Subject: Government funds available Message-ID: <20080825011039.42D363D811A@smtp2.electronicbox.net> Press Release 5:46:05 PM The American Grants and Loans Book is now available. This publication contains valuable information with more than 1800 financial programs, subsidies, scholarships, grants and loans offered by the United States federal government. It also includes over 700 financing programs put forth by various Foundations and Associations across the United States. Businesses, students, individuals, municipalities, government departments, institutions, foundations and associations will find a wealth of information that will help them with their new ventures or existing projects. What you get: -Description of Grant available -Url to government website -Full mailing address -Phone and fax number The Canadian Subsidy Directory is also available for Canada. CD version: $69.95 Printed version: $149.95 To order please call: 819-322-7533 If you do not wish to receive communication from us in the future please write "agl" in the subject line to: unsub2@hotpop.com Canada Books 833 Boise de la Riviere Prevost, Qc Canada J0R 1T0 From ganbold at micom.mng.net Mon Aug 25 04:53:18 2008 From: ganbold at micom.mng.net (Ganbold) Date: Mon Aug 25 04:53:26 2008 Subject: [CFT] drm updates In-Reply-To: <3a142e750808240812q50c1237as8c391dc35fc98ac0@mail.gmail.com> References: <20080821120021.90B5610656E5@hub.freebsd.org> <200808211456.01947.matt@chronos.org.uk> <1219544221.3430.37.camel@wombat.2hip.net> <3a142e750808240329n55d1b95bnd701dde4892c6c14@mail.gmail.com> <3a142e750808240812q50c1237as8c391dc35fc98ac0@mail.gmail.com> Message-ID: <48B22849.5060705@micom.mng.net> Paul B. Mahol wrote: > On 8/24/08, Paul B. Mahol wrote: > >> On 8/24/08, Robert Noland wrote: >> >>> I've uploaded a final patch set to: >>> >>> http://people.freebsd.org/~rnoland >>> >>> I have committed this version to -CURRENT, but patches are available for >>> RELENG_7 as well. >>> >>> This version mostly just fixes a long standing memory leak. >>> >>> All of the reports for radeon have been good. I'm still seeing a few >>> odd things with Intel though. The most severe issue is on my 965gm. >>> After restarting X, it will hang in a way that I have never seen >>> before... The small amount of evidence that I have been able to collect >>> suggests that this may be due to mesa trashing the hardware. I've spent >>> a couple of days trying to figure out exactly what could be wrong. This >>> morning I rebuilt my kernel with a stock drm from src and I got exactly >>> the same hang. Since this update does help lots of people and doesn't >>> seem to make things worse than they were to begin with, I went ahead and >>> committed it. >>> >>> I was incorrect about the patch to libdrm... It isn't needed in 2.3.1 >>> and it is already committed upstream. I'll commit that update to ports >>> soon also. It, along with a recent xf86-video-* are needed to enable >>> the new vblank behavior, which will disable vblank interrupts if there >>> are no active consumers. >>> >>> robert. >>> >>> >> Do I need to update some ports? because with kernel from HEAD I have >> encountered problems when drm is loaded (agp + drm + i915) >> astro/stellarium caused deadlock, only mouse pointer could move, if I did >> not >> started it, system will panic anyway after some time. I did not yet tested >> vty switching,.... >> >> related hardware: >> >> hostb0@pci0:0:0:0: class=0x060000 card=0x30a2103c chip=0x27a08086 >> rev=0x03 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = '955XM/945GM/PM/GMS/940GML Express Processor to DRAM >> Controller' >> class = bridge >> subclass = HOST-PCI >> vgapci0@pci0:0:2:0: class=0x030000 card=0x30a2103c chip=0x27a28086 >> rev=0x03 hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'Mobile 945GM/GU Express Integrated Graphics Controller' >> class = display >> subclass = VGA >> vgapci1@pci0:0:2:1: class=0x038000 card=0x30a2103c chip=0x27a68086 >> rev=0x03 hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'Mobile 945GM/GU Express Integrated Graphics Controller' >> class = display >> >> also if Xorg is never started, trying to unload agp.ko >> (after unloading i915.ko and drm.ko) module will cause panic. >> >> > > Comparing to xf86-video-i815, xf86-video-intel is more stable (it doesnt panic, crash, hardlocks, ...), but still locks display when starting astro/stellarium. > Yes, it locks the display. Did you try ctrl+atl+F1 and then hit 'C' key? As I remember that way it continued to work. Never tried to see what showed on ddb. Ganbold > _______________________________________________ > freebsd-x11@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-x11 > To unsubscribe, send any mail to "freebsd-x11-unsubscribe@freebsd.org" > > > > -- Nobody ever died from oven crude poisoning. From bugmaster at FreeBSD.org Mon Aug 25 11:07:02 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 25 11:09:24 2008 Subject: Current problem reports assigned to freebsd-x11@FreeBSD.org Message-ID: <200808251107.m7PB70hr027950@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- f ports/106370 x11 Screen corruption when using Direct Rendering on a PCI o ports/116359 x11 x11/xorg - screen blinks with PCI-E nvidia card and ve o ports/117195 x11 ix11/Xorg 7.3 dumps core at exit (sig 11) o ports/117766 x11 x11-servers/xorg-server (7.3) crashes under heavy load o ports/118950 x11 x11-drivers/xf86-video-nv - xorg xf86 nv (nvidia) driv o ports/119037 x11 x11: Can't type _ (Underscore) under X (gnome) f ports/119091 x11 x11-drivers/xf86-video-intel 2.1.1 panics system o ports/121360 x11 x11/xorg - Change default of ~/.xsession-errors to off o ports/122830 x11 x11/xorg: Error in I830WaitLpRing() o ports/122924 x11 XCreateImage fails in most recent x11/XOrg o ports/124220 x11 [amd64] x11-servers/xorg-server - X.org server runs in o ports/124861 x11 Keyboard problems with xorg o ports/125661 x11 x11/xorg: startx fails after a couple of attempts o ports/126812 x11 x11-drivers/xf86-video-ati - System freeze when exitin 14 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s ports/73743 x11 XOrg/XFree xauth add/startx problem o ports/113106 x11 x11/xorg - Xorg 7.2 + Mach64 + dri produces error mess f ports/114827 x11 Xorg server crashes when starting astro/google-earth o ports/115020 x11 New port: graphics/osmesa - Mesa's off-screen renderin s ports/115536 x11 [new port] x11/xorg-base port for a minimal X.Org inst o ports/116443 x11 x11-drivers/xf86-input-keyboard patch for USB jp106 ke f ports/116603 x11 x11/xorg server 7.3 hangs up f ports/117907 x11 x11-servers/mga_hal broken on 7.0-BETA (GLIBC error) f ports/118217 x11 xorg doesnt find usb mouse when initiated with devd, w o ports/118547 x11 [patch] x11/xdm fails with pam_krb5 o ports/118645 x11 Xorg need realtime priority for mouse work nice o ports/121230 x11 [patch] ports/x11/xkeyboard-config WITHOUT_NLS support o ports/123137 x11 x11/libX11: missing ru_RU.UTF-8 locale o ports/125883 x11 x11-fonts/xorg-fonts-cyrillic is installed, but fonts o ports/125992 x11 devel/imake: remove conflict with unexisting package o ports/126521 x11 [PATCH] graphics/libdrm: update to 2.3.1 o ports/126625 x11 [Patch] x11-drivers/xf86-video-openchrome - Update ope 17 problems total. From rnoland at FreeBSD.org Mon Aug 25 14:26:01 2008 From: rnoland at FreeBSD.org (Robert Noland) Date: Mon Aug 25 14:26:07 2008 Subject: [CFT] drm updates In-Reply-To: <48B1A590.2040701@gmail.com> References: <48B1A590.2040701@gmail.com> Message-ID: <1219674352.53929.2.camel@squirrel.corp.cox.com> On Sun, 2008-08-24 at 14:16 -0400, Jimmie James wrote: > Is this the type of lockup you're seeing? > > > Error in I830WaitLpRing(), timeout for 2 seconds > pgetbl_ctl: 0x3ffc0001getbl_err: 0x0 > ipeir: 0 iphdr: 7d000006 > LP ring tail: 1afa0 head: 1ad64 len: 1f001 start 0 > eir: 0 esr: 0 emr: ffff > instdone: fa41 instpm: 0 > memmode: 108 instps: 800f00c4 > hwstam: fffe ier: 2 imr: 8 iir: 80 > Ring at virtual 0x2884d000 head 0x1ad64 tail 0x1afa0 count 143 > > > > (WW) intel(0): PRB0_CTL (0x0001f001) indicates ring buffer enabled > (WW) intel(0): PRB0_HEAD (0x13e1ad64) and PRB0_TAIL (0x0001afa8) > indicate ring buffer not flushed > (WW) intel(0): Existing errors found in hardware state. Possibly, I haven't gotten this output though. Can you describe how you reached this state? robert. > > vgapci0@pci0:0:2:0: class=0x030000 card=0x25821043 chip=0x25828086 > rev=0x04 hdr=0x00 > vendor = 'Intel Corporation' > device = '82915G/GV/GL, 82910GL Integrated Graphics Device' > class = display > subclass = VGA > vgapci1@pci0:0:2:1: class=0x038000 card=0x25821043 chip=0x27828086 > rev=0x04 hdr=0x00 > vendor = 'Intel Corporation' > device = '82915G Graphics device: 82915G/GV/910GL Express > Chipset Family' > class = display > > >On Sun, 2008-08-24 at 12:29 +0200, Paul B. Mahol wrote: > > On 8/24/08, Robert Noland wrote: > > > I've uploaded a final patch set to: > > > > > > http://people.freebsd.org/~rnoland > > > > > > I have committed this version to -CURRENT, but patches are available fo= > r > > > RELENG_7 as well. > > > > > > This version mostly just fixes a long standing memory leak. > > > > > > All of the reports for radeon have been good. I'm still seeing a few > > > odd things with Intel though. The most severe issue is on my 965gm. > > > After restarting X, it will hang in a way that I have never seen > > > before... The small amount of evidence that I have been able to collec= > t > > > suggests that this may be due to mesa trashing the hardware. I've spen= > t > > > a couple of days trying to figure out exactly what could be wrong. Thi= > s > > > morning I rebuilt my kernel with a stock drm from src and I got exactly > > > the same hang. Since this update does help lots of people and doesn't > > > seem to make things worse than they were to begin with, I went ahead an= > d > > > committed it. > > > > > > I was incorrect about the patch to libdrm... It isn't needed in 2.3.1 > > > and it is already committed upstream. I'll commit that update to ports > > > soon also. It, along with a recent xf86-video-* are needed to enable > > > the new vblank behavior, which will disable vblank interrupts if there > > > are no active consumers. > > > > > > robert. > > > > >=20 > > Do I need to update some ports? because with kernel from HEAD I have > > encountered problems when drm is loaded (agp + drm + i915) > > astro/stellarium caused deadlock, only mouse pointer could move, if I did= > not > > started it, system will panic anyway after some time. I did not yet teste= > d > > vty switching,.... > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20080825/3d8cf45b/attachment.pgp From onemda at gmail.com Mon Aug 25 16:28:10 2008 From: onemda at gmail.com (Paul B. Mahol) Date: Mon Aug 25 16:28:16 2008 Subject: [CFT] drm updates In-Reply-To: <1219674352.53929.2.camel@squirrel.corp.cox.com> References: <48B1A590.2040701@gmail.com> <1219674352.53929.2.camel@squirrel.corp.cox.com> Message-ID: <3a142e750808250928n612761cch69a3bd2ebf374f92@mail.gmail.com> On 8/25/08, Robert Noland wrote: > On Sun, 2008-08-24 at 14:16 -0400, Jimmie James wrote: >> Is this the type of lockup you're seeing? >> >> >> Error in I830WaitLpRing(), timeout for 2 seconds >> pgetbl_ctl: 0x3ffc0001getbl_err: 0x0 >> ipeir: 0 iphdr: 7d000006 >> LP ring tail: 1afa0 head: 1ad64 len: 1f001 start 0 >> eir: 0 esr: 0 emr: ffff >> instdone: fa41 instpm: 0 >> memmode: 108 instps: 800f00c4 >> hwstam: fffe ier: 2 imr: 8 iir: 80 >> Ring at virtual 0x2884d000 head 0x1ad64 tail 0x1afa0 count 143 >> >> >> >> (WW) intel(0): PRB0_CTL (0x0001f001) indicates ring buffer enabled >> (WW) intel(0): PRB0_HEAD (0x13e1ad64) and PRB0_TAIL (0x0001afa8) >> indicate ring buffer not flushed >> (WW) intel(0): Existing errors found in hardware state. > > Possibly, I haven't gotten this output though. Can you describe how you > reached this state? > > robert. I dont have last 3 "(WW)" lines. It can be caused by any application that use direct rendering: 3D games(OpenGL): examples are zsnes, celestia, stellarium, etc. I'm using SMP kernel. Last fatal server error from recent Xorg.0.log.old had following last lines: (**) intel(0): Framebuffer compression enabled (**) intel(0): Tiling enabled (==) intel(0): Write-combining range (0xf4400000,0x80000) was already clear (==) intel(0): Write-combining range (0xf4480000,0x40000) was already clear (==) intel(0): VideoRam: 7932 KB (II) intel(0): Attempting memory allocation with tiled buffers. (EE) intel(0): Failed to allocate framebuffer. Is your VideoRAM set too low? (II) intel(0): Tiled allocation failed. (WW) intel(0): Couldn't allocate tiled memory, fb compression disabled (II) intel(0): Attempting memory allocation with untiled buffers. (WW) intel(0): Failed to allocate EXA offscreen memory. (II) intel(0): Untiled allocation failed. (II) intel(0): Couldn't allocate 3D memory, disabling DRI. ^^^^^^^^^^^^^^^^^^^^^^^^ (II) intel(0): Attempting memory allocation with untiled buffers. (WW) intel(0): Failed to allocate EXA offscreen memory. (II) intel(0): Untiled allocation failed. (EE) intel(0): Couldn't allocate video memory Fatal server error: AddScreen/ScreenInit failed for driver 0 Note that I'm unable to switch vty to console (atkbd0), but killing Xorg from network is possible. Note that panic/hardlock with unloading loaded modules from kernel (with/out Xorg session) is regression from previous drm state in CURRENT. Could backtrace somehow help? > >> >> vgapci0@pci0:0:2:0: class=0x030000 card=0x25821043 chip=0x25828086 >> rev=0x04 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82915G/GV/GL, 82910GL Integrated Graphics Device' >> class = display >> subclass = VGA >> vgapci1@pci0:0:2:1: class=0x038000 card=0x25821043 chip=0x27828086 >> rev=0x04 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82915G Graphics device: 82915G/GV/910GL Express >> Chipset Family' >> class = display >> >> >On Sun, 2008-08-24 at 12:29 +0200, Paul B. Mahol wrote: >> > On 8/24/08, Robert Noland wrote: >> > > I've uploaded a final patch set to: >> > > >> > > http://people.freebsd.org/~rnoland >> > > >> > > I have committed this version to -CURRENT, but patches are available >> > > fo= >> r >> > > RELENG_7 as well. >> > > >> > > This version mostly just fixes a long standing memory leak. >> > > >> > > All of the reports for radeon have been good. I'm still seeing a few >> > > odd things with Intel though. The most severe issue is on my 965gm. >> > > After restarting X, it will hang in a way that I have never seen >> > > before... The small amount of evidence that I have been able to >> > > collec= >> t >> > > suggests that this may be due to mesa trashing the hardware. I've >> > > spen= >> t >> > > a couple of days trying to figure out exactly what could be wrong. >> > > Thi= >> s >> > > morning I rebuilt my kernel with a stock drm from src and I got >> > > exactly >> > > the same hang. Since this update does help lots of people and doesn't >> > > seem to make things worse than they were to begin with, I went ahead >> > > an= >> d >> > > committed it. >> > > >> > > I was incorrect about the patch to libdrm... It isn't needed in 2.3.1 >> > > and it is already committed upstream. I'll commit that update to >> > > ports >> > > soon also. It, along with a recent xf86-video-* are needed to enable >> > > the new vblank behavior, which will disable vblank interrupts if there >> > > are no active consumers. >> > > >> > > robert. >> > > >> >=20 >> > Do I need to update some ports? because with kernel from HEAD I have >> > encountered problems when drm is loaded (agp + drm + i915) >> > astro/stellarium caused deadlock, only mouse pointer could move, if I >> > did= >> not >> > started it, system will panic anyway after some time. I did not yet >> > teste= >> d >> > vty switching,.... >> > From donotreply at tringme.com Tue Aug 26 06:38:55 2008 From: donotreply at tringme.com (TringMe) Date: Tue Aug 26 06:39:02 2008 Subject: Welcome To TringMe Message-ID: <20080826063854.C1850B6836E@tringme.com> Dear TringMe User, Your TringMe account is created. You can login and start using TringMe right away by clicking on the following link (or copy/paste in your browser) : http://tringme.com/login.php To login to your TringMe, you have to use the following account details : Email: freebsd-x11@freebsd.org Password: bbe920eb You are now ready to use TringMe! Visit http://tringme.com/learnmore.php to learn more about how to use various features of TringMe including TringPhone. To call worldwide, you just need to login, launch TringPhone and dial the number. No software to download, nothing to configure. You can receive your calls & voicemails on Phone, Mobile, Gtalk, SIP, and Mobile VoIP. Most of our services are FREE. You can also call worldwide at low rate using our new service TringPhone. If you haven't visit this link to find how you save over 50% using TringPhone - http://blog.tringme.com/are-you-paying-double-for-your-phone-calls/ Important: You can earn credits for every invite you send to your friends and family from your TringMe account. You can also link TringMe from your website using referral link in your profile page. When a user clicks on one of your links to TringMe, their activity will be tracked by our software. You will earn lifelong commission for sales made to the users who joined using your invite or visited using your referral links. There is no limit to how much you can earn. We'd love to get your feedback and learn about your experiences. If you have blogged about us, or posted an article or a review somewhere, just drop us a line and we will add your link to our press page. We will certainly add some phone credits for your constructive feedback and experience, whether in your blog or direct email to us, just to acknowledge and thank you for your effort. Visit our blog http://blog.tringme.com for news, updates and technical stuffs about TringMe. Feel free to write to us at support@tringme.com if you need any assistance. Regards, TringMe Support http://tringme.com/ (Mail was initiated by some user at IP address: 203.124.42.3) From dfilter at FreeBSD.ORG Tue Aug 26 12:30:07 2008 From: dfilter at FreeBSD.ORG (dfilter service) Date: Tue Aug 26 12:30:13 2008 Subject: ports/126521: commit references a PR Message-ID: <200808261230.m7QCU6OQ005139@freefall.freebsd.org> The following reply was made to PR ports/126521; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: ports/126521: commit references a PR Date: Tue, 26 Aug 2008 12:20:09 +0000 (UTC) rnoland 2008-08-26 12:19:50 UTC FreeBSD ports repository Modified files: graphics/libdrm Makefile distinfo pkg-plist Log: update to 2.3.1 PR: 126521 Approved by: flz, garga (mentor) Revision Changes Path 1.10 +1 -1 ports/graphics/libdrm/Makefile 1.6 +3 -3 ports/graphics/libdrm/distinfo 1.5 +0 -1 ports/graphics/libdrm/pkg-plist _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org" From miwi at FreeBSD.org Tue Aug 26 14:09:29 2008 From: miwi at FreeBSD.org (miwi@FreeBSD.org) Date: Tue Aug 26 14:09:38 2008 Subject: ports/126625: [Patch] x11-drivers/xf86-video-openchrome - Update openChrome display driver to 0.2.902 Message-ID: <200808261409.m7QE9T6l059728@freefall.freebsd.org> Synopsis: [Patch] x11-drivers/xf86-video-openchrome - Update openChrome display driver to 0.2.902 State-Changed-From-To: open->closed State-Changed-By: miwi State-Changed-When: Tue Aug 26 14:09:28 UTC 2008 State-Changed-Why: Committed. Thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=126625 From dfilter at FreeBSD.ORG Tue Aug 26 14:10:03 2008 From: dfilter at FreeBSD.ORG (dfilter service) Date: Tue Aug 26 14:10:09 2008 Subject: ports/126625: commit references a PR Message-ID: <200808261410.m7QEA3QH059755@freefall.freebsd.org> The following reply was made to PR ports/126625; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: ports/126625: commit references a PR Date: Tue, 26 Aug 2008 14:09:22 +0000 (UTC) miwi 2008-08-26 14:09:11 UTC FreeBSD ports repository Modified files: x11-drivers/xf86-video-openchrome Makefile distinfo Log: - Update to 0.2.902 PR: 126625 Submitted by: Mars G Miro Approved by: x11 (flz) Revision Changes Path 1.9 +1 -2 ports/x11-drivers/xf86-video-openchrome/Makefile 1.3 +3 -3 ports/x11-drivers/xf86-video-openchrome/distinfo _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org" From miwi at FreeBSD.org Tue Aug 26 14:14:47 2008 From: miwi at FreeBSD.org (miwi@FreeBSD.org) Date: Tue Aug 26 14:14:53 2008 Subject: ports/125992: devel/imake: remove conflict with unexisting package Message-ID: <200808261414.m7QEEkkv003038@freefall.freebsd.org> Synopsis: devel/imake: remove conflict with unexisting package State-Changed-From-To: open->closed State-Changed-By: miwi State-Changed-When: Tue Aug 26 14:14:46 UTC 2008 State-Changed-Why: Committed. Thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=125992 From miwi at FreeBSD.org Tue Aug 26 14:16:20 2008 From: miwi at FreeBSD.org (miwi@FreeBSD.org) Date: Tue Aug 26 14:16:27 2008 Subject: ports/126521: [PATCH] graphics/libdrm: update to 2.3.1 Message-ID: <200808261416.m7QEGJcA016529@freefall.freebsd.org> Synopsis: [PATCH] graphics/libdrm: update to 2.3.1 State-Changed-From-To: open->closed State-Changed-By: miwi State-Changed-When: Tue Aug 26 14:16:19 UTC 2008 State-Changed-Why: was committed by rnoland. http://www.freebsd.org/cgi/query-pr.cgi?pr=126521 From dfilter at FreeBSD.ORG Tue Aug 26 14:20:04 2008 From: dfilter at FreeBSD.ORG (dfilter service) Date: Tue Aug 26 14:20:10 2008 Subject: ports/125992: commit references a PR Message-ID: <200808261420.m7QEK4lU050755@freefall.freebsd.org> The following reply was made to PR ports/125992; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: ports/125992: commit references a PR Date: Tue, 26 Aug 2008 14:14:41 +0000 (UTC) miwi 2008-08-26 14:14:27 UTC FreeBSD ports repository Modified files: devel/imake Makefile Log: - Remove CONFLICT with XFree86-4 PR: 125992 Submitted by: Carlos Santos Approved by: x11 (flz) Revision Changes Path 1.19 +1 -3 ports/devel/imake/Makefile _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org" From onemda at gmail.com Tue Aug 26 14:41:23 2008 From: onemda at gmail.com (Paul B. Mahol) Date: Tue Aug 26 14:41:30 2008 Subject: [CFT] drm updates In-Reply-To: <3a142e750808250928n612761cch69a3bd2ebf374f92@mail.gmail.com> References: <48B1A590.2040701@gmail.com> <1219674352.53929.2.camel@squirrel.corp.cox.com> <3a142e750808250928n612761cch69a3bd2ebf374f92@mail.gmail.com> Message-ID: <3a142e750808260741p224bd68aw52711eab7e76aa59@mail.gmail.com> On 8/25/08, Paul B. Mahol wrote: > On 8/25/08, Robert Noland wrote: >> On Sun, 2008-08-24 at 14:16 -0400, Jimmie James wrote: >>> Is this the type of lockup you're seeing? >>> >>> >>> Error in I830WaitLpRing(), timeout for 2 seconds >>> pgetbl_ctl: 0x3ffc0001getbl_err: 0x0 >>> ipeir: 0 iphdr: 7d000006 >>> LP ring tail: 1afa0 head: 1ad64 len: 1f001 start 0 >>> eir: 0 esr: 0 emr: ffff >>> instdone: fa41 instpm: 0 >>> memmode: 108 instps: 800f00c4 >>> hwstam: fffe ier: 2 imr: 8 iir: 80 >>> Ring at virtual 0x2884d000 head 0x1ad64 tail 0x1afa0 count 143 >>> >>> >>> >>> (WW) intel(0): PRB0_CTL (0x0001f001) indicates ring buffer enabled >>> (WW) intel(0): PRB0_HEAD (0x13e1ad64) and PRB0_TAIL (0x0001afa8) >>> indicate ring buffer not flushed >>> (WW) intel(0): Existing errors found in hardware state. >> >> Possibly, I haven't gotten this output though. Can you describe how you >> reached this state? >> >> robert. > > I dont have last 3 "(WW)" lines. > Actually I have, but with UP kernel: (WW) intel(0): PRB0_CTL (0x0001f001) indicates ring buffer enabled (WW) intel(0): PRB0_HEAD (0x0000afdc) and PRB0_TAIL (0x0000dd98) indicate ring buffer not flushed (WW) intel(0): Existing errors found in hardware state. And on UP kernel it is posible to kill Xorg via keyboard (ctrl+alt+backspace) but it fails to start again. Error in I830WaitLpRing(), timeout for 2 seconds pgetbl_ctl: 0x3ffc0001 getbl_err: 0x00000000 ipeir: 0x00000000 iphdr: 0x6db3ffff LP ring tail: 0x00001ee0 head: 0x0000afdc len: 0x0001f001 start 0x00000000 eir: 0x0000 esr: 0x0000 emr: 0xffff instdone: 0xffc1 instpm: 0x0000 memmode: 0x00000306 instps: 0x800f04d0 hwstam: 0xeffe ier: 0x0002 imr: 0x0000 iir: 0x1070 > It can be caused by any application that use direct rendering: 3D > games(OpenGL): > examples are zsnes, celestia, stellarium, etc. On UP kernel I tested blender. > I'm using SMP kernel. > > > Last fatal server error from recent Xorg.0.log.old had following last lines: > > (**) intel(0): Framebuffer compression enabled > (**) intel(0): Tiling enabled > (==) intel(0): Write-combining range (0xf4400000,0x80000) was already clear > (==) intel(0): Write-combining range (0xf4480000,0x40000) was already clear > (==) intel(0): VideoRam: 7932 KB > (II) intel(0): Attempting memory allocation with tiled buffers. > (EE) intel(0): Failed to allocate framebuffer. Is your VideoRAM set too low? > (II) intel(0): Tiled allocation failed. > (WW) intel(0): Couldn't allocate tiled memory, fb compression disabled > (II) intel(0): Attempting memory allocation with untiled buffers. > (WW) intel(0): Failed to allocate EXA offscreen memory. > (II) intel(0): Untiled allocation failed. > (II) intel(0): Couldn't allocate 3D memory, disabling DRI. > ^^^^^^^^^^^^^^^^^^^^^^^^ > (II) intel(0): Attempting memory allocation with untiled buffers. > (WW) intel(0): Failed to allocate EXA offscreen memory. > (II) intel(0): Untiled allocation failed. > (EE) intel(0): Couldn't allocate video memory > > Fatal server error: > AddScreen/ScreenInit failed for driver 0 > > > Note that I'm unable to switch vty to console (atkbd0), but killing > Xorg from network > is possible. > > Note that panic/hardlock with unloading loaded modules from kernel > (with/out Xorg session) > is regression from previous drm state in CURRENT. Could backtrace somehow > help? > >> >>> >>> vgapci0@pci0:0:2:0: class=0x030000 card=0x25821043 chip=0x25828086 >>> rev=0x04 hdr=0x00 >>> vendor = 'Intel Corporation' >>> device = '82915G/GV/GL, 82910GL Integrated Graphics Device' >>> class = display >>> subclass = VGA >>> vgapci1@pci0:0:2:1: class=0x038000 card=0x25821043 chip=0x27828086 >>> rev=0x04 hdr=0x00 >>> vendor = 'Intel Corporation' >>> device = '82915G Graphics device: 82915G/GV/910GL Express >>> Chipset Family' >>> class = display >>> >>> >On Sun, 2008-08-24 at 12:29 +0200, Paul B. Mahol wrote: >>> > On 8/24/08, Robert Noland wrote: >>> > > I've uploaded a final patch set to: >>> > > >>> > > http://people.freebsd.org/~rnoland >>> > > >>> > > I have committed this version to -CURRENT, but patches are available >>> > > fo= >>> r >>> > > RELENG_7 as well. >>> > > >>> > > This version mostly just fixes a long standing memory leak. >>> > > >>> > > All of the reports for radeon have been good. I'm still seeing a few >>> > > odd things with Intel though. The most severe issue is on my 965gm. >>> > > After restarting X, it will hang in a way that I have never seen >>> > > before... The small amount of evidence that I have been able to >>> > > collec= >>> t >>> > > suggests that this may be due to mesa trashing the hardware. I've >>> > > spen= >>> t >>> > > a couple of days trying to figure out exactly what could be wrong. >>> > > Thi= >>> s >>> > > morning I rebuilt my kernel with a stock drm from src and I got >>> > > exactly >>> > > the same hang. Since this update does help lots of people and >>> > > doesn't >>> > > seem to make things worse than they were to begin with, I went ahead >>> > > an= >>> d >>> > > committed it. >>> > > >>> > > I was incorrect about the patch to libdrm... It isn't needed in 2.3.1 >>> > > and it is already committed upstream. I'll commit that update to >>> > > ports >>> > > soon also. It, along with a recent xf86-video-* are needed to enable >>> > > the new vblank behavior, which will disable vblank interrupts if >>> > > there >>> > > are no active consumers. >>> > > >>> > > robert. >>> > > >>> >=20 >>> > Do I need to update some ports? because with kernel from HEAD I have >>> > encountered problems when drm is loaded (agp + drm + i915) >>> > astro/stellarium caused deadlock, only mouse pointer could move, if I >>> > did= >>> not >>> > started it, system will panic anyway after some time. I did not yet >>> > teste= >>> d >>> > vty switching,.... >>> >> > From onemda at gmail.com Tue Aug 26 15:51:31 2008 From: onemda at gmail.com (Paul B. Mahol) Date: Tue Aug 26 15:51:38 2008 Subject: [CFT] drm updates In-Reply-To: <3a142e750808260741p224bd68aw52711eab7e76aa59@mail.gmail.com> References: <48B1A590.2040701@gmail.com> <1219674352.53929.2.camel@squirrel.corp.cox.com> <3a142e750808250928n612761cch69a3bd2ebf374f92@mail.gmail.com> <3a142e750808260741p224bd68aw52711eab7e76aa59@mail.gmail.com> Message-ID: <3a142e750808260851u13de6cf9jf2640c195f9be81e@mail.gmail.com> On 8/26/08, Paul B. Mahol wrote: > On 8/25/08, Paul B. Mahol wrote: >> On 8/25/08, Robert Noland wrote: >>> On Sun, 2008-08-24 at 14:16 -0400, Jimmie James wrote: >>>> Is this the type of lockup you're seeing? >>>> >>>> >>>> Error in I830WaitLpRing(), timeout for 2 seconds >>>> pgetbl_ctl: 0x3ffc0001getbl_err: 0x0 >>>> ipeir: 0 iphdr: 7d000006 >>>> LP ring tail: 1afa0 head: 1ad64 len: 1f001 start 0 >>>> eir: 0 esr: 0 emr: ffff >>>> instdone: fa41 instpm: 0 >>>> memmode: 108 instps: 800f00c4 >>>> hwstam: fffe ier: 2 imr: 8 iir: 80 >>>> Ring at virtual 0x2884d000 head 0x1ad64 tail 0x1afa0 count 143 >>>> >>>> >>>> >>>> (WW) intel(0): PRB0_CTL (0x0001f001) indicates ring buffer enabled >>>> (WW) intel(0): PRB0_HEAD (0x13e1ad64) and PRB0_TAIL (0x0001afa8) >>>> indicate ring buffer not flushed >>>> (WW) intel(0): Existing errors found in hardware state. >>> >>> Possibly, I haven't gotten this output though. Can you describe how you >>> reached this state? >>> >>> robert. >> >> I dont have last 3 "(WW)" lines. >> > > Actually I have, but with UP kernel: > > (WW) intel(0): PRB0_CTL (0x0001f001) indicates ring buffer enabled > (WW) intel(0): PRB0_HEAD (0x0000afdc) and PRB0_TAIL (0x0000dd98) > indicate ring buffer not flushed > (WW) intel(0): Existing errors found in hardware state. > > And on UP kernel it is posible to kill Xorg via keyboard > (ctrl+alt+backspace) > but it fails to start again. > > Error in I830WaitLpRing(), timeout for 2 seconds > pgetbl_ctl: 0x3ffc0001 getbl_err: 0x00000000 > ipeir: 0x00000000 iphdr: 0x6db3ffff > LP ring tail: 0x00001ee0 head: 0x0000afdc len: 0x0001f001 start 0x00000000 > eir: 0x0000 esr: 0x0000 emr: 0xffff > instdone: 0xffc1 instpm: 0x0000 > memmode: 0x00000306 instps: 0x800f04d0 > hwstam: 0xeffe ier: 0x0002 imr: 0x0000 iir: 0x1070 > >> It can be caused by any application that use direct rendering: 3D >> games(OpenGL): >> examples are zsnes, celestia, stellarium, etc. > > On UP kernel I tested blender. > >> I'm using SMP kernel. >> >> >> Last fatal server error from recent Xorg.0.log.old had following last >> lines: >> >> (**) intel(0): Framebuffer compression enabled >> (**) intel(0): Tiling enabled >> (==) intel(0): Write-combining range (0xf4400000,0x80000) was already >> clear >> (==) intel(0): Write-combining range (0xf4480000,0x40000) was already >> clear >> (==) intel(0): VideoRam: 7932 KB >> (II) intel(0): Attempting memory allocation with tiled buffers. >> (EE) intel(0): Failed to allocate framebuffer. Is your VideoRAM set too >> low? >> (II) intel(0): Tiled allocation failed. >> (WW) intel(0): Couldn't allocate tiled memory, fb compression disabled >> (II) intel(0): Attempting memory allocation with untiled buffers. >> (WW) intel(0): Failed to allocate EXA offscreen memory. >> (II) intel(0): Untiled allocation failed. >> (II) intel(0): Couldn't allocate 3D memory, disabling DRI. >> ^^^^^^^^^^^^^^^^^^^^^^^^ >> (II) intel(0): Attempting memory allocation with untiled buffers. >> (WW) intel(0): Failed to allocate EXA offscreen memory. >> (II) intel(0): Untiled allocation failed. >> (EE) intel(0): Couldn't allocate video memory >> >> Fatal server error: >> AddScreen/ScreenInit failed for driver 0 >> >> >> Note that I'm unable to switch vty to console (atkbd0), but killing >> Xorg from network >> is possible. >> >> Note that panic/hardlock with unloading loaded modules from kernel >> (with/out Xorg session) >> is regression from previous drm state in CURRENT. Could backtrace somehow >> help? >> >>> >>>> >>>> vgapci0@pci0:0:2:0: class=0x030000 card=0x25821043 chip=0x25828086 >>>> rev=0x04 hdr=0x00 >>>> vendor = 'Intel Corporation' >>>> device = '82915G/GV/GL, 82910GL Integrated Graphics Device' >>>> class = display >>>> subclass = VGA >>>> vgapci1@pci0:0:2:1: class=0x038000 card=0x25821043 chip=0x27828086 >>>> rev=0x04 hdr=0x00 >>>> vendor = 'Intel Corporation' >>>> device = '82915G Graphics device: 82915G/GV/910GL Express >>>> Chipset Family' >>>> class = display >>>> >>>> >On Sun, 2008-08-24 at 12:29 +0200, Paul B. Mahol wrote: >>>> > On 8/24/08, Robert Noland wrote: >>>> > > I've uploaded a final patch set to: >>>> > > >>>> > > http://people.freebsd.org/~rnoland >>>> > > >>>> > > I have committed this version to -CURRENT, but patches are available >>>> > > fo= >>>> r >>>> > > RELENG_7 as well. >>>> > > >>>> > > This version mostly just fixes a long standing memory leak. >>>> > > >>>> > > All of the reports for radeon have been good. I'm still seeing a >>>> > > few >>>> > > odd things with Intel though. The most severe issue is on my 965gm. >>>> > > After restarting X, it will hang in a way that I have never seen >>>> > > before... The small amount of evidence that I have been able to >>>> > > collec= >>>> t >>>> > > suggests that this may be due to mesa trashing the hardware. I've >>>> > > spen= >>>> t >>>> > > a couple of days trying to figure out exactly what could be wrong. >>>> > > Thi= >>>> s >>>> > > morning I rebuilt my kernel with a stock drm from src and I got >>>> > > exactly >>>> > > the same hang. Since this update does help lots of people and >>>> > > doesn't >>>> > > seem to make things worse than they were to begin with, I went ahead >>>> > > an= >>>> d >>>> > > committed it. >>>> > > >>>> > > I was incorrect about the patch to libdrm... It isn't needed in >>>> > > 2.3.1 >>>> > > and it is already committed upstream. I'll commit that update to >>>> > > ports >>>> > > soon also. It, along with a recent xf86-video-* are needed to >>>> > > enable >>>> > > the new vblank behavior, which will disable vblank interrupts if >>>> > > there >>>> > > are no active consumers. >>>> > > >>>> > > robert. >>>> > > >>>> >=20 >>>> > Do I need to update some ports? because with kernel from HEAD I have >>>> > encountered problems when drm is loaded (agp + drm + i915) >>>> > astro/stellarium caused deadlock, only mouse pointer could move, if I >>>> > did= >>>> not >>>> > started it, system will panic anyway after some time. I did not yet >>>> > teste= >>>> d >>>> > vty switching,.... Here is more kernel debug info (after updating libdrm and testing with glxgears) pid 7176 (Xorg), uid 0: exited on signal 6 free_unr with the following non-sleepable locks held: exclusive sleep mutex drmdev (drmdev) r = 0 (0xc4783cec) locked @ /usr/local/src/sys/modules/drm/drm/../../../dev/drm/drm_irq.c:256 KDB: stack backtrace: db_trace_self_wrapper(c0b570bb,c43887cc,c07f0dd5,c4d79b8f,100,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c4d79b8f,100,ffffffff,c0dcf79c,c4388800,...) at kdb_backtrace+0x29 _witness_debugger(c0b5930a,c4388814,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0b58e81,c4388838,c07a528c,...) at witness_warn+0x1c1 free_unr(c49776c0,1,c4d79696,a8,c4783ef4,...) at free_unr+0x2b drm_drawable_free_all(c4783c00,c4d7bce0,c4d796d9,1ba,0,...) at drm_drawable_free_all+0x174 drm_lastclose(c4646c80,1,c4d796d9,2e3,8,...) at drm_lastclose+0xdf drm_close(c4b37000,3,2000,c4971230,c4388900,...) at drm_close+0x2ca giant_close(c4b37000,3,2000,c4971230,c4971230,...) at giant_close+0x67 devfs_close(c4388948,3,c4d4d430,3,c4388968,...) at devfs_close+0x29a VOP_CLOSE_APV(c0c26380,c4388948,c0b61a19,124,c0c63f80,...) at VOP_CLOSE_APV+0xa5 vn_close(c4d4d430,3,c4ad9700,c4971230,0,...) at vn_close+0xe4 vn_closefile(c49df1c0,c4971230,c43889ec,c0784853,c49df1c0,...) at vn_closefile+0xe9 devfs_close_f(c49df1c0,c4971230,0,0,c49df1c0,...) at devfs_close_f+0x25 _fdrop(c49df1c0,c4971230,c4388a20,c07f0c1c,0,c49712d4,c0dcf798,c0c317b0,c0b4f841,c51c452c,6a7,c0b4f841,c4388a48,c07b9fe0,c51c452c,8,c0b4f841,6a7) at _fdrop+0x43 closef(c49df1c0,c4971230,6a7,6a5,c4470340,...) at closef+0x290 fdfree(c4971230,0,c0b5014d,102,c49712d4,...) at fdfree+0x387 exit1(c4971230,1,c0b53f0a,aad,c0b4ed7f,...) at exit1+0x543 sigexit(c4971230,1,c0b53f0a,a3d,c556baa8,...) at sigexit+0xaaf postsig(1,0,c0b587c6,df,c496d7d4,...) at postsig+0x1dd ast(c4388d38) at ast+0x37f doreti_ast() at doreti_ast+0x17 uma_zalloc_arg: zone "16" with the following non-sleepable locks held: exclusive sleep mutex drmdev (drmdev) r = 0 (0xc4783cec) locked @ /usr/local/src/sys/modules/drm/drm/../../../dev/drm/drm_irq.c:256 KDB: stack backtrace: db_trace_self_wrapper(c0b570bb,c438874c,c07f0dd5,c4d79b8f,100,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c4d79b8f,100,ffffffff,c0dcf79c,c4388780,...) at kdb_backtrace+0x29 _witness_debugger(c0b5930a,c4388794,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0b78fa6,c0b2b3ab,c0b5930a,...) at witness_warn+0x1c1 uma_zalloc_arg(c1872960,0,102,2,1,...) at uma_zalloc_arg+0x34 malloc(10,c0c34a40,102,c4388838,c07a528c,...) at malloc+0xd2 free_unr(c49776c0,1,c4d79696,a8,c4783ef4,...) at free_unr+0x47 drm_drawable_free_all(c4783c00,c4d7bce0,c4d796d9,1ba,0,...) at drm_drawable_free_all+0x174 drm_lastclose(c4646c80,1,c4d796d9,2e3,8,...) at drm_lastclose+0xdf drm_close(c4b37000,3,2000,c4971230,c4388900,...) at drm_close+0x2ca giant_close(c4b37000,3,2000,c4971230,c4971230,...) at giant_close+0x67 devfs_close(c4388948,3,c4d4d430,3,c4388968,...) at devfs_close+0x29a VOP_CLOSE_APV(c0c26380,c4388948,c0b61a19,124,c0c63f80,...) at VOP_CLOSE_APV+0xa5 vn_close(c4d4d430,3,c4ad9700,c4971230,0,...) at vn_close+0xe4 vn_closefile(c49df1c0,c4971230,c43889ec,c0784853,c49df1c0,...) at vn_closefile+0xe9 devfs_close_f(c49df1c0,c4971230,0,0,c49df1c0,...) at devfs_close_f+0x25 _fdrop(c49df1c0,c4971230,c4388a20,c07f0c1c,0,c49712d4,c0dcf798,c0c317b0,c0b4f841,c51c452c,6a7,c0b4f841,c4388a48,c07b9fe0,c51c452c,8,c0b4f841,6a7) at _fdrop+0x43 closef(c49df1c0,c4971230,6a7,6a5,c4470340,...) at closef+0x290 fdfree(c4971230,0,c0b5014d,102,c49712d4,...) at fdfree+0x387 exit1(c4971230,1,c0b53f0a,aad,c0b4ed7f,...) at exit1+0x543 sigexit(c4971230,1,c0b53f0a,a3d,c556baa8,...) at sigexit+0xaaf postsig(1,0,c0b587c6,df,c496d7d4,...) at postsig+0x1dd ast(c4388d38) at ast+0x37f doreti_ast() at doreti_ast+0x17 uma_zalloc_arg: zone "16" with the following non-sleepable locks held: exclusive sleep mutex drmdev (drmdev) r = 0 (0xc4783cec) locked @ /usr/local/src/sys/modules/drm/drm/../../../dev/drm/drm_irq.c:256 KDB: stack backtrace: db_trace_self_wrapper(c0b570bb,c438874c,c07f0dd5,c4d79b8f,100,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c4d79b8f,100,ffffffff,c0dcf79c,c4388780,...) at kdb_backtrace+0x29 _witness_debugger(c0b5930a,c4388794,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0b78fa6,c0b2b3ab,c0b5930a,...) at witness_warn+0x1c1 uma_zalloc_arg(c1872960,0,102,2,1,...) at uma_zalloc_arg+0x34 malloc(10,c0c34a40,102,c4388838,c07a528c,...) at malloc+0xd2 free_unr(c49776c0,1,c4d79696,a8,c4783ef4,...) at free_unr+0x66 drm_drawable_free_all(c4783c00,c4d7bce0,c4d796d9,1ba,0,...) at drm_drawable_free_all+0x174 drm_lastclose(c4646c80,1,c4d796d9,2e3,8,...) at drm_lastclose+0xdf drm_close(c4b37000,3,2000,c4971230,c4388900,...) at drm_close+0x2ca giant_close(c4b37000,3,2000,c4971230,c4971230,...) at giant_close+0x67 devfs_close(c4388948,3,c4d4d430,3,c4388968,...) at devfs_close+0x29a VOP_CLOSE_APV(c0c26380,c4388948,c0b61a19,124,c0c63f80,...) at VOP_CLOSE_APV+0xa5 vn_close(c4d4d430,3,c4ad9700,c4971230,0,...) at vn_close+0xe4 vn_closefile(c49df1c0,c4971230,c43889ec,c0784853,c49df1c0,...) at vn_closefile+0xe9 devfs_close_f(c49df1c0,c4971230,0,0,c49df1c0,...) at devfs_close_f+0x25 _fdrop(c49df1c0,c4971230,c4388a20,c07f0c1c,0,c49712d4,c0dcf798,c0c317b0,c0b4f841,c51c452c,6a7,c0b4f841,c4388a48,c07b9fe0,c51c452c,8,c0b4f841,6a7) at _fdrop+0x43 closef(c49df1c0,c4971230,6a7,6a5,c4470340,...) at closef+0x290 fdfree(c4971230,0,c0b5014d,102,c49712d4,...) at fdfree+0x387 exit1(c4971230,1,c0b53f0a,aad,c0b4ed7f,...) at exit1+0x543 sigexit(c4971230,1,c0b53f0a,a3d,c556baa8,...) at sigexit+0xaaf postsig(1,0,c0b587c6,df,c496d7d4,...) at postsig+0x1dd ast(c4388d38) at ast+0x37f doreti_ast() at doreti_ast+0x17 drm0: [ITHREAD] pid 9156 (Xorg), uid 0: exited on signal 6 From rnoland at FreeBSD.org Tue Aug 26 16:21:00 2008 From: rnoland at FreeBSD.org (Robert Noland) Date: Tue Aug 26 16:21:11 2008 Subject: [CFT] drm updates In-Reply-To: <3a142e750808260851u13de6cf9jf2640c195f9be81e@mail.gmail.com> References: <48B1A590.2040701@gmail.com> <1219674352.53929.2.camel@squirrel.corp.cox.com> <3a142e750808250928n612761cch69a3bd2ebf374f92@mail.gmail.com> <3a142e750808260741p224bd68aw52711eab7e76aa59@mail.gmail.com> <3a142e750808260851u13de6cf9jf2640c195f9be81e@mail.gmail.com> Message-ID: <1219767649.58043.9.camel@squirrel.corp.cox.com> On Tue, 2008-08-26 at 17:51 +0200, Paul B. Mahol wrote: > Here is more kernel debug info (after updating libdrm and testing with > glxgears) > > pid 7176 (Xorg), uid 0: exited on signal 6 > free_unr with the following non-sleepable locks held: > exclusive sleep mutex drmdev (drmdev) r = 0 (0xc4783cec) locked @ > /usr/local/src/sys/modules/drm/drm/../../../dev/drm/drm_irq.c:256 Ok, I can fix that... Thanks for finding it. robert. > KDB: stack backtrace: > db_trace_self_wrapper(c0b570bb,c43887cc,c07f0dd5,c4d79b8f,100,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(c4d79b8f,100,ffffffff,c0dcf79c,c4388800,...) at > kdb_backtrace+0x29 > _witness_debugger(c0b5930a,c4388814,4,1,0,...) at _witness_debugger > +0x25 > witness_warn(5,0,c0b58e81,c4388838,c07a528c,...) at witness_warn+0x1c1 > free_unr(c49776c0,1,c4d79696,a8,c4783ef4,...) at free_unr+0x2b > drm_drawable_free_all(c4783c00,c4d7bce0,c4d796d9,1ba,0,...) at > drm_drawable_free_all+0x174 > drm_lastclose(c4646c80,1,c4d796d9,2e3,8,...) at drm_lastclose+0xdf > drm_close(c4b37000,3,2000,c4971230,c4388900,...) at drm_close+0x2ca > giant_close(c4b37000,3,2000,c4971230,c4971230,...) at giant_close+0x67 > devfs_close(c4388948,3,c4d4d430,3,c4388968,...) at devfs_close+0x29a > VOP_CLOSE_APV(c0c26380,c4388948,c0b61a19,124,c0c63f80,...) at > VOP_CLOSE_APV+0xa5 > vn_close(c4d4d430,3,c4ad9700,c4971230,0,...) at vn_close+0xe4 > vn_closefile(c49df1c0,c4971230,c43889ec,c0784853,c49df1c0,...) at > vn_closefile+0xe9 > devfs_close_f(c49df1c0,c4971230,0,0,c49df1c0,...) at devfs_close_f > +0x25 > _fdrop(c49df1c0,c4971230,c4388a20,c07f0c1c,0,c49712d4,c0dcf798,c0c317b0,c0b4f841,c51c452c,6a7,c0b4f841,c4388a48,c07b9fe0,c51c452c,8,c0b4f841,6a7) > at _fdrop+0x43 > closef(c49df1c0,c4971230,6a7,6a5,c4470340,...) at closef+0x290 > fdfree(c4971230,0,c0b5014d,102,c49712d4,...) at fdfree+0x387 > exit1(c4971230,1,c0b53f0a,aad,c0b4ed7f,...) at exit1+0x543 > sigexit(c4971230,1,c0b53f0a,a3d,c556baa8,...) at sigexit+0xaaf > postsig(1,0,c0b587c6,df,c496d7d4,...) at postsig+0x1dd > ast(c4388d38) at ast+0x37f > doreti_ast() at doreti_ast+0x17 > uma_zalloc_arg: zone "16" with the following non-sleepable locks held: > exclusive sleep mutex drmdev (drmdev) r = 0 (0xc4783cec) locked @ > /usr/local/src/sys/modules/drm/drm/../../../dev/drm/drm_irq.c:256 > KDB: stack backtrace: > db_trace_self_wrapper(c0b570bb,c438874c,c07f0dd5,c4d79b8f,100,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(c4d79b8f,100,ffffffff,c0dcf79c,c4388780,...) at > kdb_backtrace+0x29 > _witness_debugger(c0b5930a,c4388794,4,1,0,...) at _witness_debugger > +0x25 > witness_warn(5,0,c0b78fa6,c0b2b3ab,c0b5930a,...) at witness_warn+0x1c1 > uma_zalloc_arg(c1872960,0,102,2,1,...) at uma_zalloc_arg+0x34 > malloc(10,c0c34a40,102,c4388838,c07a528c,...) at malloc+0xd2 > free_unr(c49776c0,1,c4d79696,a8,c4783ef4,...) at free_unr+0x47 > drm_drawable_free_all(c4783c00,c4d7bce0,c4d796d9,1ba,0,...) at > drm_drawable_free_all+0x174 > drm_lastclose(c4646c80,1,c4d796d9,2e3,8,...) at drm_lastclose+0xdf > drm_close(c4b37000,3,2000,c4971230,c4388900,...) at drm_close+0x2ca > giant_close(c4b37000,3,2000,c4971230,c4971230,...) at giant_close+0x67 > devfs_close(c4388948,3,c4d4d430,3,c4388968,...) at devfs_close+0x29a > VOP_CLOSE_APV(c0c26380,c4388948,c0b61a19,124,c0c63f80,...) at > VOP_CLOSE_APV+0xa5 > vn_close(c4d4d430,3,c4ad9700,c4971230,0,...) at vn_close+0xe4 > vn_closefile(c49df1c0,c4971230,c43889ec,c0784853,c49df1c0,...) at > vn_closefile+0xe9 > devfs_close_f(c49df1c0,c4971230,0,0,c49df1c0,...) at devfs_close_f > +0x25 > _fdrop(c49df1c0,c4971230,c4388a20,c07f0c1c,0,c49712d4,c0dcf798,c0c317b0,c0b4f841,c51c452c,6a7,c0b4f841,c4388a48,c07b9fe0,c51c452c,8,c0b4f841,6a7) > at _fdrop+0x43 > closef(c49df1c0,c4971230,6a7,6a5,c4470340,...) at closef+0x290 > fdfree(c4971230,0,c0b5014d,102,c49712d4,...) at fdfree+0x387 > exit1(c4971230,1,c0b53f0a,aad,c0b4ed7f,...) at exit1+0x543 > sigexit(c4971230,1,c0b53f0a,a3d,c556baa8,...) at sigexit+0xaaf > postsig(1,0,c0b587c6,df,c496d7d4,...) at postsig+0x1dd > ast(c4388d38) at ast+0x37f > doreti_ast() at doreti_ast+0x17 > uma_zalloc_arg: zone "16" with the following non-sleepable locks held: > exclusive sleep mutex drmdev (drmdev) r = 0 (0xc4783cec) locked @ > /usr/local/src/sys/modules/drm/drm/../../../dev/drm/drm_irq.c:256 > KDB: stack backtrace: > db_trace_self_wrapper(c0b570bb,c438874c,c07f0dd5,c4d79b8f,100,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(c4d79b8f,100,ffffffff,c0dcf79c,c4388780,...) at > kdb_backtrace+0x29 > _witness_debugger(c0b5930a,c4388794,4,1,0,...) at _witness_debugger > +0x25 > witness_warn(5,0,c0b78fa6,c0b2b3ab,c0b5930a,...) at witness_warn+0x1c1 > uma_zalloc_arg(c1872960,0,102,2,1,...) at uma_zalloc_arg+0x34 > malloc(10,c0c34a40,102,c4388838,c07a528c,...) at malloc+0xd2 > free_unr(c49776c0,1,c4d79696,a8,c4783ef4,...) at free_unr+0x66 > drm_drawable_free_all(c4783c00,c4d7bce0,c4d796d9,1ba,0,...) at > drm_drawable_free_all+0x174 > drm_lastclose(c4646c80,1,c4d796d9,2e3,8,...) at drm_lastclose+0xdf > drm_close(c4b37000,3,2000,c4971230,c4388900,...) at drm_close+0x2ca > giant_close(c4b37000,3,2000,c4971230,c4971230,...) at giant_close+0x67 > devfs_close(c4388948,3,c4d4d430,3,c4388968,...) at devfs_close+0x29a > VOP_CLOSE_APV(c0c26380,c4388948,c0b61a19,124,c0c63f80,...) at > VOP_CLOSE_APV+0xa5 > vn_close(c4d4d430,3,c4ad9700,c4971230,0,...) at vn_close+0xe4 > vn_closefile(c49df1c0,c4971230,c43889ec,c0784853,c49df1c0,...) at > vn_closefile+0xe9 > devfs_close_f(c49df1c0,c4971230,0,0,c49df1c0,...) at devfs_close_f > +0x25 > _fdrop(c49df1c0,c4971230,c4388a20,c07f0c1c,0,c49712d4,c0dcf798,c0c317b0,c0b4f841,c51c452c,6a7,c0b4f841,c4388a48,c07b9fe0,c51c452c,8,c0b4f841,6a7) > at _fdrop+0x43 > closef(c49df1c0,c4971230,6a7,6a5,c4470340,...) at closef+0x290 > fdfree(c4971230,0,c0b5014d,102,c49712d4,...) at fdfree+0x387 > exit1(c4971230,1,c0b53f0a,aad,c0b4ed7f,...) at exit1+0x543 > sigexit(c4971230,1,c0b53f0a,a3d,c556baa8,...) at sigexit+0xaaf > postsig(1,0,c0b587c6,df,c496d7d4,...) at postsig+0x1dd > ast(c4388d38) at ast+0x37f > doreti_ast() at doreti_ast+0x17 > drm0: [ITHREAD] > pid 9156 (Xorg), uid 0: exited on signal 6 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20080826/372eabe5/attachment.pgp From rnoland at FreeBSD.org Tue Aug 26 16:58:43 2008 From: rnoland at FreeBSD.org (Robert Noland) Date: Tue Aug 26 16:58:50 2008 Subject: [CFT] drm updates In-Reply-To: <3a142e750808260851u13de6cf9jf2640c195f9be81e@mail.gmail.com> References: <48B1A590.2040701@gmail.com> <1219674352.53929.2.camel@squirrel.corp.cox.com> <3a142e750808250928n612761cch69a3bd2ebf374f92@mail.gmail.com> <3a142e750808260741p224bd68aw52711eab7e76aa59@mail.gmail.com> <3a142e750808260851u13de6cf9jf2640c195f9be81e@mail.gmail.com> Message-ID: <1219769914.58043.11.camel@squirrel.corp.cox.com> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20080826/f663b8d1/attachment.pgp From onemda at gmail.com Wed Aug 27 10:07:36 2008 From: onemda at gmail.com (Paul B. Mahol) Date: Wed Aug 27 10:07:43 2008 Subject: [CFT] drm updates In-Reply-To: <1219769914.58043.11.camel@squirrel.corp.cox.com> References: <48B1A590.2040701@gmail.com> <1219674352.53929.2.camel@squirrel.corp.cox.com> <3a142e750808250928n612761cch69a3bd2ebf374f92@mail.gmail.com> <3a142e750808260741p224bd68aw52711eab7e76aa59@mail.gmail.com> <3a142e750808260851u13de6cf9jf2640c195f9be81e@mail.gmail.com> <1219769914.58043.11.camel@squirrel.corp.cox.com> Message-ID: <3a142e750808270307k237c5660ha98e8bcdfbddc4dc@mail.gmail.com> On 8/26/08, Robert Noland wrote: > On Tue, 2008-08-26 at 17:51 +0200, Paul B. Mahol wrote: >> Here is more kernel debug info (after updating libdrm and testing with >> glxgears) > > I don't think that the two issues are related, but try this patch... It > should at least, resolve the issue below. > > robert. Issue bellow is fixed, previous problem still exist. textdump of panic when unloading drm attached. >> pid 7176 (Xorg), uid 0: exited on signal 6 >> free_unr with the following non-sleepable locks held: >> exclusive sleep mutex drmdev (drmdev) r = 0 (0xc4783cec) locked @ >> /usr/local/src/sys/modules/drm/drm/../../../dev/drm/drm_irq.c:256 >> KDB: stack backtrace: >> db_trace_self_wrapper(c0b570bb,c43887cc,c07f0dd5,c4d79b8f,100,...) at >> db_trace_self_wrapper+0x26 >> kdb_backtrace(c4d79b8f,100,ffffffff,c0dcf79c,c4388800,...) at >> kdb_backtrace+0x29 >> _witness_debugger(c0b5930a,c4388814,4,1,0,...) at _witness_debugger >> +0x25 >> witness_warn(5,0,c0b58e81,c4388838,c07a528c,...) at witness_warn+0x1c1 >> free_unr(c49776c0,1,c4d79696,a8,c4783ef4,...) at free_unr+0x2b >> drm_drawable_free_all(c4783c00,c4d7bce0,c4d796d9,1ba,0,...) at >> drm_drawable_free_all+0x174 >> drm_lastclose(c4646c80,1,c4d796d9,2e3,8,...) at drm_lastclose+0xdf >> drm_close(c4b37000,3,2000,c4971230,c4388900,...) at drm_close+0x2ca >> giant_close(c4b37000,3,2000,c4971230,c4971230,...) at giant_close+0x67 >> devfs_close(c4388948,3,c4d4d430,3,c4388968,...) at devfs_close+0x29a >> VOP_CLOSE_APV(c0c26380,c4388948,c0b61a19,124,c0c63f80,...) at >> VOP_CLOSE_APV+0xa5 >> vn_close(c4d4d430,3,c4ad9700,c4971230,0,...) at vn_close+0xe4 >> vn_closefile(c49df1c0,c4971230,c43889ec,c0784853,c49df1c0,...) at >> vn_closefile+0xe9 >> devfs_close_f(c49df1c0,c4971230,0,0,c49df1c0,...) at devfs_close_f >> +0x25 >> _fdrop(c49df1c0,c4971230,c4388a20,c07f0c1c,0,c49712d4,c0dcf798,c0c317b0,c0b4f841,c51c452c,6a7,c0b4f841,c4388a48,c07b9fe0,c51c452c,8,c0b4f841,6a7) >> at _fdrop+0x43 >> closef(c49df1c0,c4971230,6a7,6a5,c4470340,...) at closef+0x290 >> fdfree(c4971230,0,c0b5014d,102,c49712d4,...) at fdfree+0x387 >> exit1(c4971230,1,c0b53f0a,aad,c0b4ed7f,...) at exit1+0x543 >> sigexit(c4971230,1,c0b53f0a,a3d,c556baa8,...) at sigexit+0xaaf >> postsig(1,0,c0b587c6,df,c496d7d4,...) at postsig+0x1dd >> ast(c4388d38) at ast+0x37f >> doreti_ast() at doreti_ast+0x17 >> uma_zalloc_arg: zone "16" with the following non-sleepable locks held: >> exclusive sleep mutex drmdev (drmdev) r = 0 (0xc4783cec) locked @ >> /usr/local/src/sys/modules/drm/drm/../../../dev/drm/drm_irq.c:256 >> KDB: stack backtrace: >> db_trace_self_wrapper(c0b570bb,c438874c,c07f0dd5,c4d79b8f,100,...) at >> db_trace_self_wrapper+0x26 >> kdb_backtrace(c4d79b8f,100,ffffffff,c0dcf79c,c4388780,...) at >> kdb_backtrace+0x29 >> _witness_debugger(c0b5930a,c4388794,4,1,0,...) at _witness_debugger >> +0x25 >> witness_warn(5,0,c0b78fa6,c0b2b3ab,c0b5930a,...) at witness_warn+0x1c1 >> uma_zalloc_arg(c1872960,0,102,2,1,...) at uma_zalloc_arg+0x34 >> malloc(10,c0c34a40,102,c4388838,c07a528c,...) at malloc+0xd2 >> free_unr(c49776c0,1,c4d79696,a8,c4783ef4,...) at free_unr+0x47 >> drm_drawable_free_all(c4783c00,c4d7bce0,c4d796d9,1ba,0,...) at >> drm_drawable_free_all+0x174 >> drm_lastclose(c4646c80,1,c4d796d9,2e3,8,...) at drm_lastclose+0xdf >> drm_close(c4b37000,3,2000,c4971230,c4388900,...) at drm_close+0x2ca >> giant_close(c4b37000,3,2000,c4971230,c4971230,...) at giant_close+0x67 >> devfs_close(c4388948,3,c4d4d430,3,c4388968,...) at devfs_close+0x29a >> VOP_CLOSE_APV(c0c26380,c4388948,c0b61a19,124,c0c63f80,...) at >> VOP_CLOSE_APV+0xa5 >> vn_close(c4d4d430,3,c4ad9700,c4971230,0,...) at vn_close+0xe4 >> vn_closefile(c49df1c0,c4971230,c43889ec,c0784853,c49df1c0,...) at >> vn_closefile+0xe9 >> devfs_close_f(c49df1c0,c4971230,0,0,c49df1c0,...) at devfs_close_f >> +0x25 >> _fdrop(c49df1c0,c4971230,c4388a20,c07f0c1c,0,c49712d4,c0dcf798,c0c317b0,c0b4f841,c51c452c,6a7,c0b4f841,c4388a48,c07b9fe0,c51c452c,8,c0b4f841,6a7) >> at _fdrop+0x43 >> closef(c49df1c0,c4971230,6a7,6a5,c4470340,...) at closef+0x290 >> fdfree(c4971230,0,c0b5014d,102,c49712d4,...) at fdfree+0x387 >> exit1(c4971230,1,c0b53f0a,aad,c0b4ed7f,...) at exit1+0x543 >> sigexit(c4971230,1,c0b53f0a,a3d,c556baa8,...) at sigexit+0xaaf >> postsig(1,0,c0b587c6,df,c496d7d4,...) at postsig+0x1dd >> ast(c4388d38) at ast+0x37f >> doreti_ast() at doreti_ast+0x17 >> uma_zalloc_arg: zone "16" with the following non-sleepable locks held: >> exclusive sleep mutex drmdev (drmdev) r = 0 (0xc4783cec) locked @ >> /usr/local/src/sys/modules/drm/drm/../../../dev/drm/drm_irq.c:256 >> KDB: stack backtrace: >> db_trace_self_wrapper(c0b570bb,c438874c,c07f0dd5,c4d79b8f,100,...) at >> db_trace_self_wrapper+0x26 >> kdb_backtrace(c4d79b8f,100,ffffffff,c0dcf79c,c4388780,...) at >> kdb_backtrace+0x29 >> _witness_debugger(c0b5930a,c4388794,4,1,0,...) at _witness_debugger >> +0x25 >> witness_warn(5,0,c0b78fa6,c0b2b3ab,c0b5930a,...) at witness_warn+0x1c1 >> uma_zalloc_arg(c1872960,0,102,2,1,...) at uma_zalloc_arg+0x34 >> malloc(10,c0c34a40,102,c4388838,c07a528c,...) at malloc+0xd2 >> free_unr(c49776c0,1,c4d79696,a8,c4783ef4,...) at free_unr+0x66 >> drm_drawable_free_all(c4783c00,c4d7bce0,c4d796d9,1ba,0,...) at >> drm_drawable_free_all+0x174 >> drm_lastclose(c4646c80,1,c4d796d9,2e3,8,...) at drm_lastclose+0xdf >> drm_close(c4b37000,3,2000,c4971230,c4388900,...) at drm_close+0x2ca >> giant_close(c4b37000,3,2000,c4971230,c4971230,...) at giant_close+0x67 >> devfs_close(c4388948,3,c4d4d430,3,c4388968,...) at devfs_close+0x29a >> VOP_CLOSE_APV(c0c26380,c4388948,c0b61a19,124,c0c63f80,...) at >> VOP_CLOSE_APV+0xa5 >> vn_close(c4d4d430,3,c4ad9700,c4971230,0,...) at vn_close+0xe4 >> vn_closefile(c49df1c0,c4971230,c43889ec,c0784853,c49df1c0,...) at >> vn_closefile+0xe9 >> devfs_close_f(c49df1c0,c4971230,0,0,c49df1c0,...) at devfs_close_f >> +0x25 >> _fdrop(c49df1c0,c4971230,c4388a20,c07f0c1c,0,c49712d4,c0dcf798,c0c317b0,c0b4f841,c51c452c,6a7,c0b4f841,c4388a48,c07b9fe0,c51c452c,8,c0b4f841,6a7) >> at _fdrop+0x43 >> closef(c49df1c0,c4971230,6a7,6a5,c4470340,...) at closef+0x290 >> fdfree(c4971230,0,c0b5014d,102,c49712d4,...) at fdfree+0x387 >> exit1(c4971230,1,c0b53f0a,aad,c0b4ed7f,...) at exit1+0x543 >> sigexit(c4971230,1,c0b53f0a,a3d,c556baa8,...) at sigexit+0xaaf >> postsig(1,0,c0b587c6,df,c496d7d4,...) at postsig+0x1dd >> ast(c4388d38) at ast+0x37f >> doreti_ast() at doreti_ast+0x17 >> drm0: [ITHREAD] >> pid 9156 (Xorg), uid 0: exited on signal 6 >> > From rnoland at FreeBSD.org Wed Aug 27 15:19:46 2008 From: rnoland at FreeBSD.org (Robert Noland) Date: Wed Aug 27 15:19:53 2008 Subject: [CFT] drm updates In-Reply-To: <3a142e750808270307k237c5660ha98e8bcdfbddc4dc@mail.gmail.com> References: <48B1A590.2040701@gmail.com> <1219674352.53929.2.camel@squirrel.corp.cox.com> <3a142e750808250928n612761cch69a3bd2ebf374f92@mail.gmail.com> <3a142e750808260741p224bd68aw52711eab7e76aa59@mail.gmail.com> <3a142e750808260851u13de6cf9jf2640c195f9be81e@mail.gmail.com> <1219769914.58043.11.camel@squirrel.corp.cox.com> <3a142e750808270307k237c5660ha98e8bcdfbddc4dc@mail.gmail.com> Message-ID: <1219850374.61484.7.camel@squirrel.corp.cox.com> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20080827/c279663d/attachment.pgp From r.c.ladan at gmail.com Wed Aug 27 16:39:17 2008 From: r.c.ladan at gmail.com (Rene Ladan) Date: Wed Aug 27 16:39:27 2008 Subject: Fwd: Complete System Freeze when log out of X session In-Reply-To: References: <48988A69.1000404@tiscali.co.uk> <48989825.3060307@gmail.com> <1218315310.1914.11.camel@wombat.2hip.net> Message-ID: Better sent it to the list too. Rene ---------- Forwarded message ---------- From: Rene Ladan Date: 2008/8/27 Subject: Re: Complete System Freeze when log out of X session To: Robert Noland 2008/8/9 Robert Noland : > On Tue, 2008-08-05 at 20:12 +0200, Rene Ladan wrote: >> vangogh schreef: >> > My laptop has xorg 7.3 on Freebsd 7. >> > My xorg.conf file has: >> > Section "Device" >> > Identifier "card0" >> > Driver "vesa" >> > VendorName "S3 Inc" >> > BoardName "VT8375 [ProSavage8 KM266/KL266]" >> > BusID "PCI:1:0:0" >> > EndSection >> > >> > Problem is when I log out of gnome my system freezes completely and >> > control+alt+backspace does not work. The keyboard becomes totally >> > unresponsive and i must unplug the system to turn it off. I have >> > searched this problem and seen that posts appear in the archives back in >> > 2006 about this issue. However, I cannot find any solution. Can someone >> > please point me in the right direction for a solution to this please? >> > >> This sounds slightly familiar. I sometimes have these freezes too, >> but when I'm still in xfce4. Pressing the power knob still works for me, >> as well as logging in remotely via ssh. This means that only the screen >> (which turns black, no backlight on) and keyboard/mouse are frozen. >> >> This is with an Asus A6JE, Ati Radeon X1450 running xorg 7.3 with >> xf86-video-radeonhd 1.2.1. > > This sounds more like a gpu crash, or a deadlock in the xserver. So, I > don't think that these two cases are the same. Since you can ssh in, > have a look at top while it's hung and see what state the xorg process > is in. If it is in drmlk2, it's locked. If that looks ok, then it's > probably a gpu crash, if you set sysctl hw.dri.0.debug=1 you will > probably see a lot of radeon_cp_idle and timeout calls. > My laptop (panel/keyboard) froze again last night when I was quitting xfce4. I'm currently logged in over ssh. top/ps show no X processes except for two instances of mplayer (as plugin) in S (sleep < 20s) state. The dmesg buffer filtered through uniq: WARNING pid 1153 (Xorg): ioctl sign-extension ioctl ffffffffc010644d WARNING pid 1153 (Xorg): ioctl sign-extension ioctl ffffffff80086442 info: [drm] Num pipes: 1 WARNING pid 1153 (Xorg): ioctl sign-extension ioctl ffffffff80106459 WARNING pid 1153 (Xorg): ioctl sign-extension ioctl ffffffff80086414 WARNING pid 1153 (Xorg): ioctl sign-extension ioctl ffffffff80786440 WARNING pid 1153 (Xorg): ioctl sign-extension ioctl ffffffff80106439 WARNING pid 1153 (Xorg): ioctl sign-extension ioctl ffffffffc0086421 WARNING pid 1153 (Xorg): ioctl sign-extension ioctl ffffffffc0106426 WARNING pid 1153 (Xorg): ioctl sign-extension ioctl ffffffff8008642b /var/log/messages also shows > kernel: linux_sys_futex: unknown op 129 after the freeze. Xorg still ran about 30 minutes after the freeze, I think I closed the lid at that time (which normally means that the backlight goes off). Setting hw.dri.0.debug to 1 right now doesn't show anything. -- http://www.rene-ladan.nl/ GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) From rnoland at 2hip.net Wed Aug 27 17:04:25 2008 From: rnoland at 2hip.net (Robert Noland) Date: Wed Aug 27 17:04:33 2008 Subject: Fwd: Complete System Freeze when log out of X session In-Reply-To: References: <48988A69.1000404@tiscali.co.uk> <48989825.3060307@gmail.com> <1218315310.1914.11.camel@wombat.2hip.net> Message-ID: <1219855730.77696.5.camel@squirrel.corp.cox.com> On Wed, 2008-08-27 at 18:39 +0200, Rene Ladan wrote: > Better sent it to the list too. > > Rene > > ---------- Forwarded message ---------- > From: Rene Ladan > Date: 2008/8/27 > Subject: Re: Complete System Freeze when log out of X session > To: Robert Noland > > > 2008/8/9 Robert Noland : > > On Tue, 2008-08-05 at 20:12 +0200, Rene Ladan wrote: > >> vangogh schreef: > >> > My laptop has xorg 7.3 on Freebsd 7. > >> > My xorg.conf file has: > >> > Section "Device" > >> > Identifier "card0" > >> > Driver "vesa" > >> > VendorName "S3 Inc" > >> > BoardName "VT8375 [ProSavage8 KM266/KL266]" > >> > BusID "PCI:1:0:0" > >> > EndSection > >> > > >> > Problem is when I log out of gnome my system freezes completely and > >> > control+alt+backspace does not work. The keyboard becomes totally > >> > unresponsive and i must unplug the system to turn it off. I have > >> > searched this problem and seen that posts appear in the archives back in > >> > 2006 about this issue. However, I cannot find any solution. Can someone > >> > please point me in the right direction for a solution to this please? > >> > > >> This sounds slightly familiar. I sometimes have these freezes too, > >> but when I'm still in xfce4. Pressing the power knob still works for me, > >> as well as logging in remotely via ssh. This means that only the screen > >> (which turns black, no backlight on) and keyboard/mouse are frozen. > >> > >> This is with an Asus A6JE, Ati Radeon X1450 running xorg 7.3 with > >> xf86-video-radeonhd 1.2.1. > > > > This sounds more like a gpu crash, or a deadlock in the xserver. So, I > > don't think that these two cases are the same. Since you can ssh in, > > have a look at top while it's hung and see what state the xorg process > > is in. If it is in drmlk2, it's locked. If that looks ok, then it's > > probably a gpu crash, if you set sysctl hw.dri.0.debug=1 you will > > probably see a lot of radeon_cp_idle and timeout calls. > > > My laptop (panel/keyboard) froze again last night when I was quitting xfce4. > I'm currently logged in over ssh. top/ps show no X processes except for two > instances of mplayer (as plugin) in S (sleep < 20s) state. > > The dmesg buffer filtered through uniq: > WARNING pid 1153 (Xorg): ioctl sign-extension ioctl ffffffffc010644d > WARNING pid 1153 (Xorg): ioctl sign-extension ioctl ffffffff80086442 > info: [drm] Num pipes: 1 > WARNING pid 1153 (Xorg): ioctl sign-extension ioctl ffffffff80106459 > WARNING pid 1153 (Xorg): ioctl sign-extension ioctl ffffffff80086414 > WARNING pid 1153 (Xorg): ioctl sign-extension ioctl ffffffff80786440 > WARNING pid 1153 (Xorg): ioctl sign-extension ioctl ffffffff80106439 > WARNING pid 1153 (Xorg): ioctl sign-extension ioctl ffffffffc0086421 > WARNING pid 1153 (Xorg): ioctl sign-extension ioctl ffffffffc0106426 > WARNING pid 1153 (Xorg): ioctl sign-extension ioctl ffffffff8008642b Are you running a not entirely recent libdrm from git? robert. > /var/log/messages also shows > > kernel: linux_sys_futex: unknown op 129 > after the freeze. Xorg still ran about 30 minutes after the freeze, I > think I closed the lid at that time (which normally means that the > backlight goes off). > > Setting hw.dri.0.debug to 1 right now doesn't show anything. > -- > http://www.rene-ladan.nl/ > > GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 > (subkeys.pgp.net) > _______________________________________________ > freebsd-x11@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-x11 > To unsubscribe, send any mail to "freebsd-x11-unsubscribe@freebsd.org" -- Robert Noland 2Hip Networks -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20080827/880fbf41/attachment.pgp From r.c.ladan at gmail.com Wed Aug 27 17:47:25 2008 From: r.c.ladan at gmail.com (Rene Ladan) Date: Wed Aug 27 17:47:34 2008 Subject: Fwd: Complete System Freeze when log out of X session In-Reply-To: <1219855730.77696.5.camel@squirrel.corp.cox.com> References: <48988A69.1000404@tiscali.co.uk> <48989825.3060307@gmail.com> <1218315310.1914.11.camel@wombat.2hip.net> <1219855730.77696.5.camel@squirrel.corp.cox.com> Message-ID: 2008/8/27 Robert Noland : > On Wed, 2008-08-27 at 18:39 +0200, Rene Ladan wrote: >> Better sent it to the list too. >> >> Rene >> >> ---------- Forwarded message ---------- >> From: Rene Ladan >> Date: 2008/8/27 >> Subject: Re: Complete System Freeze when log out of X session >> To: Robert Noland >> >> >> 2008/8/9 Robert Noland : >> > On Tue, 2008-08-05 at 20:12 +0200, Rene Ladan wrote: >> >> vangogh schreef: >> >> > My laptop has xorg 7.3 on Freebsd 7. >> >> > My xorg.conf file has: >> >> > Section "Device" >> >> > Identifier "card0" >> >> > Driver "vesa" >> >> > VendorName "S3 Inc" >> >> > BoardName "VT8375 [ProSavage8 KM266/KL266]" >> >> > BusID "PCI:1:0:0" >> >> > EndSection >> >> > >> >> > Problem is when I log out of gnome my system freezes completely and >> >> > control+alt+backspace does not work. The keyboard becomes totally >> >> > unresponsive and i must unplug the system to turn it off. I have >> >> > searched this problem and seen that posts appear in the archives back in >> >> > 2006 about this issue. However, I cannot find any solution. Can someone >> >> > please point me in the right direction for a solution to this please? >> >> > >> >> This sounds slightly familiar. I sometimes have these freezes too, >> >> but when I'm still in xfce4. Pressing the power knob still works for me, >> >> as well as logging in remotely via ssh. This means that only the screen >> >> (which turns black, no backlight on) and keyboard/mouse are frozen. >> >> >> >> This is with an Asus A6JE, Ati Radeon X1450 running xorg 7.3 with >> >> xf86-video-radeonhd 1.2.1. >> > >> > This sounds more like a gpu crash, or a deadlock in the xserver. So, I >> > don't think that these two cases are the same. Since you can ssh in, >> > have a look at top while it's hung and see what state the xorg process >> > is in. If it is in drmlk2, it's locked. If that looks ok, then it's >> > probably a gpu crash, if you set sysctl hw.dri.0.debug=1 you will >> > probably see a lot of radeon_cp_idle and timeout calls. >> > >> My laptop (panel/keyboard) froze again last night when I was quitting xfce4. >> I'm currently logged in over ssh. top/ps show no X processes except for two >> instances of mplayer (as plugin) in S (sleep < 20s) state. >> >> The dmesg buffer filtered through uniq: >> WARNING pid 1153 (Xorg): ioctl sign-extension ioctl ffffffffc010644d >> WARNING pid 1153 (Xorg): ioctl sign-extension ioctl ffffffff80086442 >> info: [drm] Num pipes: 1 >> WARNING pid 1153 (Xorg): ioctl sign-extension ioctl ffffffff80106459 >> WARNING pid 1153 (Xorg): ioctl sign-extension ioctl ffffffff80086414 >> WARNING pid 1153 (Xorg): ioctl sign-extension ioctl ffffffff80786440 >> WARNING pid 1153 (Xorg): ioctl sign-extension ioctl ffffffff80106439 >> WARNING pid 1153 (Xorg): ioctl sign-extension ioctl ffffffffc0086421 >> WARNING pid 1153 (Xorg): ioctl sign-extension ioctl ffffffffc0106426 >> WARNING pid 1153 (Xorg): ioctl sign-extension ioctl ffffffff8008642b > > Are you running a not entirely recent libdrm from git? > I'm running libdrm from Aug 24, commit c8fd8d3a0d37dc09165ac77c7d38938ef9942011 (overwriting the kernel modules and libdrm from ports) and mesa from Aug 25, commit 80af50b35b5a4e8890e15b28940576f8a1ac1476 (overwriting glu/glut/dri/mesa from ports) [...] -- http://www.rene-ladan.nl/ GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) From edwin at FreeBSD.org Thu Aug 28 04:30:16 2008 From: edwin at FreeBSD.org (edwin@FreeBSD.org) Date: Thu Aug 28 04:30:26 2008 Subject: ports/126904: x11/xorg startx fails on driver loading for nVidia GeForce 7300 GS card Message-ID: <200808280430.m7S4UFxu012408@freefall.freebsd.org> Synopsis: x11/xorg startx fails on driver loading for nVidia GeForce 7300 GS card Responsible-Changed-From-To: freebsd-ports-bugs->freebsd-x11 Responsible-Changed-By: edwin Responsible-Changed-When: Thu Aug 28 04:30:15 UTC 2008 Responsible-Changed-Why: Over to maintainer (via the GNATS Auto Assign Tool) http://www.freebsd.org/cgi/query-pr.cgi?pr=126904 From onemda at gmail.com Thu Aug 28 17:07:16 2008 From: onemda at gmail.com (Paul B. Mahol) Date: Thu Aug 28 17:07:23 2008 Subject: [CFT] drm updates In-Reply-To: <1219850374.61484.7.camel@squirrel.corp.cox.com> References: <48B1A590.2040701@gmail.com> <1219674352.53929.2.camel@squirrel.corp.cox.com> <3a142e750808250928n612761cch69a3bd2ebf374f92@mail.gmail.com> <3a142e750808260741p224bd68aw52711eab7e76aa59@mail.gmail.com> <3a142e750808260851u13de6cf9jf2640c195f9be81e@mail.gmail.com> <1219769914.58043.11.camel@squirrel.corp.cox.com> <3a142e750808270307k237c5660ha98e8bcdfbddc4dc@mail.gmail.com> <1219850374.61484.7.camel@squirrel.corp.cox.com> Message-ID: <3a142e750808281007r42bbe4d0u53be9c0074386c10@mail.gmail.com> On 8/27/08, Robert Noland wrote: > On Wed, 2008-08-27 at 12:07 +0200, Paul B. Mahol wrote: >> On 8/26/08, Robert Noland wrote: >> > On Tue, 2008-08-26 at 17:51 +0200, Paul B. Mahol wrote: >> >> Here is more kernel debug info (after updating libdrm and testing with >> >> glxgears) >> > >> > I don't think that the two issues are related, but try this patch... It >> > should at least, resolve the issue below. >> > >> > robert. >> >> Issue bellow is fixed, previous problem still exist. >> >> textdump of panic when unloading drm attached. > > Ok, The locking semantics are a nightmare... Give this a try, it should > correct both the previous issue as well as this one. > > robert. > Panic fixed, now only Xorg crashing when using glxgears (,...) remains ;) >> >> >> pid 7176 (Xorg), uid 0: exited on signal 6 >> >> free_unr with the following non-sleepable locks held: >> >> exclusive sleep mutex drmdev (drmdev) r = 0 (0xc4783cec) locked @ >> >> /usr/local/src/sys/modules/drm/drm/../../../dev/drm/drm_irq.c:256 >> >> KDB: stack backtrace: >> >> db_trace_self_wrapper(c0b570bb,c43887cc,c07f0dd5,c4d79b8f,100,...) at >> >> db_trace_self_wrapper+0x26 >> >> kdb_backtrace(c4d79b8f,100,ffffffff,c0dcf79c,c4388800,...) at >> >> kdb_backtrace+0x29 >> >> _witness_debugger(c0b5930a,c4388814,4,1,0,...) at _witness_debugger >> >> +0x25 >> >> witness_warn(5,0,c0b58e81,c4388838,c07a528c,...) at witness_warn+0x1c1 >> >> free_unr(c49776c0,1,c4d79696,a8,c4783ef4,...) at free_unr+0x2b >> >> drm_drawable_free_all(c4783c00,c4d7bce0,c4d796d9,1ba,0,...) at >> >> drm_drawable_free_all+0x174 >> >> drm_lastclose(c4646c80,1,c4d796d9,2e3,8,...) at drm_lastclose+0xdf >> >> drm_close(c4b37000,3,2000,c4971230,c4388900,...) at drm_close+0x2ca >> >> giant_close(c4b37000,3,2000,c4971230,c4971230,...) at giant_close+0x67 >> >> devfs_close(c4388948,3,c4d4d430,3,c4388968,...) at devfs_close+0x29a >> >> VOP_CLOSE_APV(c0c26380,c4388948,c0b61a19,124,c0c63f80,...) at >> >> VOP_CLOSE_APV+0xa5 >> >> vn_close(c4d4d430,3,c4ad9700,c4971230,0,...) at vn_close+0xe4 >> >> vn_closefile(c49df1c0,c4971230,c43889ec,c0784853,c49df1c0,...) at >> >> vn_closefile+0xe9 >> >> devfs_close_f(c49df1c0,c4971230,0,0,c49df1c0,...) at devfs_close_f >> >> +0x25 >> >> _fdrop(c49df1c0,c4971230,c4388a20,c07f0c1c,0,c49712d4,c0dcf798,c0c317b0,c0b4f841,c51c452c,6a7,c0b4f841,c4388a48,c07b9fe0,c51c452c,8,c0b4f841,6a7) >> >> at _fdrop+0x43 >> >> closef(c49df1c0,c4971230,6a7,6a5,c4470340,...) at closef+0x290 >> >> fdfree(c4971230,0,c0b5014d,102,c49712d4,...) at fdfree+0x387 >> >> exit1(c4971230,1,c0b53f0a,aad,c0b4ed7f,...) at exit1+0x543 >> >> sigexit(c4971230,1,c0b53f0a,a3d,c556baa8,...) at sigexit+0xaaf >> >> postsig(1,0,c0b587c6,df,c496d7d4,...) at postsig+0x1dd >> >> ast(c4388d38) at ast+0x37f >> >> doreti_ast() at doreti_ast+0x17 >> >> uma_zalloc_arg: zone "16" with the following non-sleepable locks held: >> >> exclusive sleep mutex drmdev (drmdev) r = 0 (0xc4783cec) locked @ >> >> /usr/local/src/sys/modules/drm/drm/../../../dev/drm/drm_irq.c:256 >> >> KDB: stack backtrace: >> >> db_trace_self_wrapper(c0b570bb,c438874c,c07f0dd5,c4d79b8f,100,...) at >> >> db_trace_self_wrapper+0x26 >> >> kdb_backtrace(c4d79b8f,100,ffffffff,c0dcf79c,c4388780,...) at >> >> kdb_backtrace+0x29 >> >> _witness_debugger(c0b5930a,c4388794,4,1,0,...) at _witness_debugger >> >> +0x25 >> >> witness_warn(5,0,c0b78fa6,c0b2b3ab,c0b5930a,...) at witness_warn+0x1c1 >> >> uma_zalloc_arg(c1872960,0,102,2,1,...) at uma_zalloc_arg+0x34 >> >> malloc(10,c0c34a40,102,c4388838,c07a528c,...) at malloc+0xd2 >> >> free_unr(c49776c0,1,c4d79696,a8,c4783ef4,...) at free_unr+0x47 >> >> drm_drawable_free_all(c4783c00,c4d7bce0,c4d796d9,1ba,0,...) at >> >> drm_drawable_free_all+0x174 >> >> drm_lastclose(c4646c80,1,c4d796d9,2e3,8,...) at drm_lastclose+0xdf >> >> drm_close(c4b37000,3,2000,c4971230,c4388900,...) at drm_close+0x2ca >> >> giant_close(c4b37000,3,2000,c4971230,c4971230,...) at giant_close+0x67 >> >> devfs_close(c4388948,3,c4d4d430,3,c4388968,...) at devfs_close+0x29a >> >> VOP_CLOSE_APV(c0c26380,c4388948,c0b61a19,124,c0c63f80,...) at >> >> VOP_CLOSE_APV+0xa5 >> >> vn_close(c4d4d430,3,c4ad9700,c4971230,0,...) at vn_close+0xe4 >> >> vn_closefile(c49df1c0,c4971230,c43889ec,c0784853,c49df1c0,...) at >> >> vn_closefile+0xe9 >> >> devfs_close_f(c49df1c0,c4971230,0,0,c49df1c0,...) at devfs_close_f >> >> +0x25 >> >> _fdrop(c49df1c0,c4971230,c4388a20,c07f0c1c,0,c49712d4,c0dcf798,c0c317b0,c0b4f841,c51c452c,6a7,c0b4f841,c4388a48,c07b9fe0,c51c452c,8,c0b4f841,6a7) >> >> at _fdrop+0x43 >> >> closef(c49df1c0,c4971230,6a7,6a5,c4470340,...) at closef+0x290 >> >> fdfree(c4971230,0,c0b5014d,102,c49712d4,...) at fdfree+0x387 >> >> exit1(c4971230,1,c0b53f0a,aad,c0b4ed7f,...) at exit1+0x543 >> >> sigexit(c4971230,1,c0b53f0a,a3d,c556baa8,...) at sigexit+0xaaf >> >> postsig(1,0,c0b587c6,df,c496d7d4,...) at postsig+0x1dd >> >> ast(c4388d38) at ast+0x37f >> >> doreti_ast() at doreti_ast+0x17 >> >> uma_zalloc_arg: zone "16" with the following non-sleepable locks held: >> >> exclusive sleep mutex drmdev (drmdev) r = 0 (0xc4783cec) locked @ >> >> /usr/local/src/sys/modules/drm/drm/../../../dev/drm/drm_irq.c:256 >> >> KDB: stack backtrace: >> >> db_trace_self_wrapper(c0b570bb,c438874c,c07f0dd5,c4d79b8f,100,...) at >> >> db_trace_self_wrapper+0x26 >> >> kdb_backtrace(c4d79b8f,100,ffffffff,c0dcf79c,c4388780,...) at >> >> kdb_backtrace+0x29 >> >> _witness_debugger(c0b5930a,c4388794,4,1,0,...) at _witness_debugger >> >> +0x25 >> >> witness_warn(5,0,c0b78fa6,c0b2b3ab,c0b5930a,...) at witness_warn+0x1c1 >> >> uma_zalloc_arg(c1872960,0,102,2,1,...) at uma_zalloc_arg+0x34 >> >> malloc(10,c0c34a40,102,c4388838,c07a528c,...) at malloc+0xd2 >> >> free_unr(c49776c0,1,c4d79696,a8,c4783ef4,...) at free_unr+0x66 >> >> drm_drawable_free_all(c4783c00,c4d7bce0,c4d796d9,1ba,0,...) at >> >> drm_drawable_free_all+0x174 >> >> drm_lastclose(c4646c80,1,c4d796d9,2e3,8,...) at drm_lastclose+0xdf >> >> drm_close(c4b37000,3,2000,c4971230,c4388900,...) at drm_close+0x2ca >> >> giant_close(c4b37000,3,2000,c4971230,c4971230,...) at giant_close+0x67 >> >> devfs_close(c4388948,3,c4d4d430,3,c4388968,...) at devfs_close+0x29a >> >> VOP_CLOSE_APV(c0c26380,c4388948,c0b61a19,124,c0c63f80,...) at >> >> VOP_CLOSE_APV+0xa5 >> >> vn_close(c4d4d430,3,c4ad9700,c4971230,0,...) at vn_close+0xe4 >> >> vn_closefile(c49df1c0,c4971230,c43889ec,c0784853,c49df1c0,...) at >> >> vn_closefile+0xe9 >> >> devfs_close_f(c49df1c0,c4971230,0,0,c49df1c0,...) at devfs_close_f >> >> +0x25 >> >> _fdrop(c49df1c0,c4971230,c4388a20,c07f0c1c,0,c49712d4,c0dcf798,c0c317b0,c0b4f841,c51c452c,6a7,c0b4f841,c4388a48,c07b9fe0,c51c452c,8,c0b4f841,6a7) >> >> at _fdrop+0x43 >> >> closef(c49df1c0,c4971230,6a7,6a5,c4470340,...) at closef+0x290 >> >> fdfree(c4971230,0,c0b5014d,102,c49712d4,...) at fdfree+0x387 >> >> exit1(c4971230,1,c0b53f0a,aad,c0b4ed7f,...) at exit1+0x543 >> >> sigexit(c4971230,1,c0b53f0a,a3d,c556baa8,...) at sigexit+0xaaf >> >> postsig(1,0,c0b587c6,df,c496d7d4,...) at postsig+0x1dd >> >> ast(c4388d38) at ast+0x37f >> >> doreti_ast() at doreti_ast+0x17 >> >> drm0: [ITHREAD] >> >> pid 9156 (Xorg), uid 0: exited on signal 6 >> >> >> > > From rnoland at FreeBSD.org Thu Aug 28 17:27:00 2008 From: rnoland at FreeBSD.org (Robert Noland) Date: Thu Aug 28 17:27:16 2008 Subject: [CFT] drm updates In-Reply-To: <3a142e750808281007r42bbe4d0u53be9c0074386c10@mail.gmail.com> References: <48B1A590.2040701@gmail.com> <1219674352.53929.2.camel@squirrel.corp.cox.com> <3a142e750808250928n612761cch69a3bd2ebf374f92@mail.gmail.com> <3a142e750808260741p224bd68aw52711eab7e76aa59@mail.gmail.com> <3a142e750808260851u13de6cf9jf2640c195f9be81e@mail.gmail.com> <1219769914.58043.11.camel@squirrel.corp.cox.com> <3a142e750808270307k237c5660ha98e8bcdfbddc4dc@mail.gmail.com> <1219850374.61484.7.camel@squirrel.corp.cox.com> <3a142e750808281007r42bbe4d0u53be9c0074386c10@mail.gmail.com> Message-ID: <1219944411.61066.5.camel@squirrel.corp.cox.com> On Thu, 2008-08-28 at 19:07 +0200, Paul B. Mahol wrote: > On 8/27/08, Robert Noland wrote: > > On Wed, 2008-08-27 at 12:07 +0200, Paul B. Mahol wrote: > >> On 8/26/08, Robert Noland wrote: > >> > On Tue, 2008-08-26 at 17:51 +0200, Paul B. Mahol wrote: > >> >> Here is more kernel debug info (after updating libdrm and testing with > >> >> glxgears) > >> > > >> > I don't think that the two issues are related, but try this patch... It > >> > should at least, resolve the issue below. > >> > > >> > robert. > >> > >> Issue bellow is fixed, previous problem still exist. > >> > >> textdump of panic when unloading drm attached. > > > > Ok, The locking semantics are a nightmare... Give this a try, it should > > correct both the previous issue as well as this one. > > > > robert. > > > > Panic fixed, now only Xorg crashing when using glxgears (,...) remains ;) Ok, what hardware are you using again? Can you manually load drm modules and set hw.dri.0.debug=1 and send me the debug output? robert. > >> > >> >> pid 7176 (Xorg), uid 0: exited on signal 6 > >> >> free_unr with the following non-sleepable locks held: > >> >> exclusive sleep mutex drmdev (drmdev) r = 0 (0xc4783cec) locked @ > >> >> /usr/local/src/sys/modules/drm/drm/../../../dev/drm/drm_irq.c:256 > >> >> KDB: stack backtrace: > >> >> db_trace_self_wrapper(c0b570bb,c43887cc,c07f0dd5,c4d79b8f,100,...) at > >> >> db_trace_self_wrapper+0x26 > >> >> kdb_backtrace(c4d79b8f,100,ffffffff,c0dcf79c,c4388800,...) at > >> >> kdb_backtrace+0x29 > >> >> _witness_debugger(c0b5930a,c4388814,4,1,0,...) at _witness_debugger > >> >> +0x25 > >> >> witness_warn(5,0,c0b58e81,c4388838,c07a528c,...) at witness_warn+0x1c1 > >> >> free_unr(c49776c0,1,c4d79696,a8,c4783ef4,...) at free_unr+0x2b > >> >> drm_drawable_free_all(c4783c00,c4d7bce0,c4d796d9,1ba,0,...) at > >> >> drm_drawable_free_all+0x174 > >> >> drm_lastclose(c4646c80,1,c4d796d9,2e3,8,...) at drm_lastclose+0xdf > >> >> drm_close(c4b37000,3,2000,c4971230,c4388900,...) at drm_close+0x2ca > >> >> giant_close(c4b37000,3,2000,c4971230,c4971230,...) at giant_close+0x67 > >> >> devfs_close(c4388948,3,c4d4d430,3,c4388968,...) at devfs_close+0x29a > >> >> VOP_CLOSE_APV(c0c26380,c4388948,c0b61a19,124,c0c63f80,...) at > >> >> VOP_CLOSE_APV+0xa5 > >> >> vn_close(c4d4d430,3,c4ad9700,c4971230,0,...) at vn_close+0xe4 > >> >> vn_closefile(c49df1c0,c4971230,c43889ec,c0784853,c49df1c0,...) at > >> >> vn_closefile+0xe9 > >> >> devfs_close_f(c49df1c0,c4971230,0,0,c49df1c0,...) at devfs_close_f > >> >> +0x25 > >> >> _fdrop(c49df1c0,c4971230,c4388a20,c07f0c1c,0,c49712d4,c0dcf798,c0c317b0,c0b4f841,c51c452c,6a7,c0b4f841,c4388a48,c07b9fe0,c51c452c,8,c0b4f841,6a7) > >> >> at _fdrop+0x43 > >> >> closef(c49df1c0,c4971230,6a7,6a5,c4470340,...) at closef+0x290 > >> >> fdfree(c4971230,0,c0b5014d,102,c49712d4,...) at fdfree+0x387 > >> >> exit1(c4971230,1,c0b53f0a,aad,c0b4ed7f,...) at exit1+0x543 > >> >> sigexit(c4971230,1,c0b53f0a,a3d,c556baa8,...) at sigexit+0xaaf > >> >> postsig(1,0,c0b587c6,df,c496d7d4,...) at postsig+0x1dd > >> >> ast(c4388d38) at ast+0x37f > >> >> doreti_ast() at doreti_ast+0x17 > >> >> uma_zalloc_arg: zone "16" with the following non-sleepable locks held: > >> >> exclusive sleep mutex drmdev (drmdev) r = 0 (0xc4783cec) locked @ > >> >> /usr/local/src/sys/modules/drm/drm/../../../dev/drm/drm_irq.c:256 > >> >> KDB: stack backtrace: > >> >> db_trace_self_wrapper(c0b570bb,c438874c,c07f0dd5,c4d79b8f,100,...) at > >> >> db_trace_self_wrapper+0x26 > >> >> kdb_backtrace(c4d79b8f,100,ffffffff,c0dcf79c,c4388780,...) at > >> >> kdb_backtrace+0x29 > >> >> _witness_debugger(c0b5930a,c4388794,4,1,0,...) at _witness_debugger > >> >> +0x25 > >> >> witness_warn(5,0,c0b78fa6,c0b2b3ab,c0b5930a,...) at witness_warn+0x1c1 > >> >> uma_zalloc_arg(c1872960,0,102,2,1,...) at uma_zalloc_arg+0x34 > >> >> malloc(10,c0c34a40,102,c4388838,c07a528c,...) at malloc+0xd2 > >> >> free_unr(c49776c0,1,c4d79696,a8,c4783ef4,...) at free_unr+0x47 > >> >> drm_drawable_free_all(c4783c00,c4d7bce0,c4d796d9,1ba,0,...) at > >> >> drm_drawable_free_all+0x174 > >> >> drm_lastclose(c4646c80,1,c4d796d9,2e3,8,...) at drm_lastclose+0xdf > >> >> drm_close(c4b37000,3,2000,c4971230,c4388900,...) at drm_close+0x2ca > >> >> giant_close(c4b37000,3,2000,c4971230,c4971230,...) at giant_close+0x67 > >> >> devfs_close(c4388948,3,c4d4d430,3,c4388968,...) at devfs_close+0x29a > >> >> VOP_CLOSE_APV(c0c26380,c4388948,c0b61a19,124,c0c63f80,...) at > >> >> VOP_CLOSE_APV+0xa5 > >> >> vn_close(c4d4d430,3,c4ad9700,c4971230,0,...) at vn_close+0xe4 > >> >> vn_closefile(c49df1c0,c4971230,c43889ec,c0784853,c49df1c0,...) at > >> >> vn_closefile+0xe9 > >> >> devfs_close_f(c49df1c0,c4971230,0,0,c49df1c0,...) at devfs_close_f > >> >> +0x25 > >> >> _fdrop(c49df1c0,c4971230,c4388a20,c07f0c1c,0,c49712d4,c0dcf798,c0c317b0,c0b4f841,c51c452c,6a7,c0b4f841,c4388a48,c07b9fe0,c51c452c,8,c0b4f841,6a7) > >> >> at _fdrop+0x43 > >> >> closef(c49df1c0,c4971230,6a7,6a5,c4470340,...) at closef+0x290 > >> >> fdfree(c4971230,0,c0b5014d,102,c49712d4,...) at fdfree+0x387 > >> >> exit1(c4971230,1,c0b53f0a,aad,c0b4ed7f,...) at exit1+0x543 > >> >> sigexit(c4971230,1,c0b53f0a,a3d,c556baa8,...) at sigexit+0xaaf > >> >> postsig(1,0,c0b587c6,df,c496d7d4,...) at postsig+0x1dd > >> >> ast(c4388d38) at ast+0x37f > >> >> doreti_ast() at doreti_ast+0x17 > >> >> uma_zalloc_arg: zone "16" with the following non-sleepable locks held: > >> >> exclusive sleep mutex drmdev (drmdev) r = 0 (0xc4783cec) locked @ > >> >> /usr/local/src/sys/modules/drm/drm/../../../dev/drm/drm_irq.c:256 > >> >> KDB: stack backtrace: > >> >> db_trace_self_wrapper(c0b570bb,c438874c,c07f0dd5,c4d79b8f,100,...) at > >> >> db_trace_self_wrapper+0x26 > >> >> kdb_backtrace(c4d79b8f,100,ffffffff,c0dcf79c,c4388780,...) at > >> >> kdb_backtrace+0x29 > >> >> _witness_debugger(c0b5930a,c4388794,4,1,0,...) at _witness_debugger > >> >> +0x25 > >> >> witness_warn(5,0,c0b78fa6,c0b2b3ab,c0b5930a,...) at witness_warn+0x1c1 > >> >> uma_zalloc_arg(c1872960,0,102,2,1,...) at uma_zalloc_arg+0x34 > >> >> malloc(10,c0c34a40,102,c4388838,c07a528c,...) at malloc+0xd2 > >> >> free_unr(c49776c0,1,c4d79696,a8,c4783ef4,...) at free_unr+0x66 > >> >> drm_drawable_free_all(c4783c00,c4d7bce0,c4d796d9,1ba,0,...) at > >> >> drm_drawable_free_all+0x174 > >> >> drm_lastclose(c4646c80,1,c4d796d9,2e3,8,...) at drm_lastclose+0xdf > >> >> drm_close(c4b37000,3,2000,c4971230,c4388900,...) at drm_close+0x2ca > >> >> giant_close(c4b37000,3,2000,c4971230,c4971230,...) at giant_close+0x67 > >> >> devfs_close(c4388948,3,c4d4d430,3,c4388968,...) at devfs_close+0x29a > >> >> VOP_CLOSE_APV(c0c26380,c4388948,c0b61a19,124,c0c63f80,...) at > >> >> VOP_CLOSE_APV+0xa5 > >> >> vn_close(c4d4d430,3,c4ad9700,c4971230,0,...) at vn_close+0xe4 > >> >> vn_closefile(c49df1c0,c4971230,c43889ec,c0784853,c49df1c0,...) at > >> >> vn_closefile+0xe9 > >> >> devfs_close_f(c49df1c0,c4971230,0,0,c49df1c0,...) at devfs_close_f > >> >> +0x25 > >> >> _fdrop(c49df1c0,c4971230,c4388a20,c07f0c1c,0,c49712d4,c0dcf798,c0c317b0,c0b4f841,c51c452c,6a7,c0b4f841,c4388a48,c07b9fe0,c51c452c,8,c0b4f841,6a7) > >> >> at _fdrop+0x43 > >> >> closef(c49df1c0,c4971230,6a7,6a5,c4470340,...) at closef+0x290 > >> >> fdfree(c4971230,0,c0b5014d,102,c49712d4,...) at fdfree+0x387 > >> >> exit1(c4971230,1,c0b53f0a,aad,c0b4ed7f,...) at exit1+0x543 > >> >> sigexit(c4971230,1,c0b53f0a,a3d,c556baa8,...) at sigexit+0xaaf > >> >> postsig(1,0,c0b587c6,df,c496d7d4,...) at postsig+0x1dd > >> >> ast(c4388d38) at ast+0x37f > >> >> doreti_ast() at doreti_ast+0x17 > >> >> drm0: [ITHREAD] > >> >> pid 9156 (Xorg), uid 0: exited on signal 6 > >> >> > >> > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20080828/0085bda5/attachment.pgp From onemda at gmail.com Thu Aug 28 18:45:09 2008 From: onemda at gmail.com (Paul B. Mahol) Date: Thu Aug 28 18:45:16 2008 Subject: [CFT] drm updates In-Reply-To: <1219944411.61066.5.camel@squirrel.corp.cox.com> References: <48B1A590.2040701@gmail.com> <1219674352.53929.2.camel@squirrel.corp.cox.com> <3a142e750808250928n612761cch69a3bd2ebf374f92@mail.gmail.com> <3a142e750808260741p224bd68aw52711eab7e76aa59@mail.gmail.com> <3a142e750808260851u13de6cf9jf2640c195f9be81e@mail.gmail.com> <1219769914.58043.11.camel@squirrel.corp.cox.com> <3a142e750808270307k237c5660ha98e8bcdfbddc4dc@mail.gmail.com> <1219850374.61484.7.camel@squirrel.corp.cox.com> <3a142e750808281007r42bbe4d0u53be9c0074386c10@mail.gmail.com> <1219944411.61066.5.camel@squirrel.corp.cox.com> Message-ID: <3a142e750808281145m3d49839fv4665066d1791e4e6@mail.gmail.com> On 8/28/08, Robert Noland wrote: > On Thu, 2008-08-28 at 19:07 +0200, Paul B. Mahol wrote: >> On 8/27/08, Robert Noland wrote: >> > On Wed, 2008-08-27 at 12:07 +0200, Paul B. Mahol wrote: >> >> On 8/26/08, Robert Noland wrote: >> >> > On Tue, 2008-08-26 at 17:51 +0200, Paul B. Mahol wrote: >> >> >> Here is more kernel debug info (after updating libdrm and testing >> >> >> with >> >> >> glxgears) >> >> > >> >> > I don't think that the two issues are related, but try this patch... >> >> > It >> >> > should at least, resolve the issue below. >> >> > >> >> > robert. >> >> >> >> Issue bellow is fixed, previous problem still exist. >> >> >> >> textdump of panic when unloading drm attached. >> > >> > Ok, The locking semantics are a nightmare... Give this a try, it should >> > correct both the previous issue as well as this one. >> > >> > robert. >> > >> >> Panic fixed, now only Xorg crashing when using glxgears (,...) remains ;) > > Ok, what hardware are you using again? Can you manually load drm > modules and set hw.dri.0.debug=1 and send me the debug output? > > robert. Hardware: "Mobile 945GM/GU Express Integrated Graphics Controller" Debug ouptut attached. I have two ktrace.out of Xorg and glxgears but I dont see point sending it. > >> >> >> >> >> pid 7176 (Xorg), uid 0: exited on signal 6 >> >> >> free_unr with the following non-sleepable locks held: >> >> >> exclusive sleep mutex drmdev (drmdev) r = 0 (0xc4783cec) locked @ >> >> >> /usr/local/src/sys/modules/drm/drm/../../../dev/drm/drm_irq.c:256 >> >> >> KDB: stack backtrace: >> >> >> db_trace_self_wrapper(c0b570bb,c43887cc,c07f0dd5,c4d79b8f,100,...) >> >> >> at >> >> >> db_trace_self_wrapper+0x26 >> >> >> kdb_backtrace(c4d79b8f,100,ffffffff,c0dcf79c,c4388800,...) at >> >> >> kdb_backtrace+0x29 >> >> >> _witness_debugger(c0b5930a,c4388814,4,1,0,...) at _witness_debugger >> >> >> +0x25 >> >> >> witness_warn(5,0,c0b58e81,c4388838,c07a528c,...) at >> >> >> witness_warn+0x1c1 >> >> >> free_unr(c49776c0,1,c4d79696,a8,c4783ef4,...) at free_unr+0x2b >> >> >> drm_drawable_free_all(c4783c00,c4d7bce0,c4d796d9,1ba,0,...) at >> >> >> drm_drawable_free_all+0x174 >> >> >> drm_lastclose(c4646c80,1,c4d796d9,2e3,8,...) at drm_lastclose+0xdf >> >> >> drm_close(c4b37000,3,2000,c4971230,c4388900,...) at drm_close+0x2ca >> >> >> giant_close(c4b37000,3,2000,c4971230,c4971230,...) at >> >> >> giant_close+0x67 >> >> >> devfs_close(c4388948,3,c4d4d430,3,c4388968,...) at devfs_close+0x29a >> >> >> VOP_CLOSE_APV(c0c26380,c4388948,c0b61a19,124,c0c63f80,...) at >> >> >> VOP_CLOSE_APV+0xa5 >> >> >> vn_close(c4d4d430,3,c4ad9700,c4971230,0,...) at vn_close+0xe4 >> >> >> vn_closefile(c49df1c0,c4971230,c43889ec,c0784853,c49df1c0,...) at >> >> >> vn_closefile+0xe9 >> >> >> devfs_close_f(c49df1c0,c4971230,0,0,c49df1c0,...) at devfs_close_f >> >> >> +0x25 >> >> >> _fdrop(c49df1c0,c4971230,c4388a20,c07f0c1c,0,c49712d4,c0dcf798,c0c317b0,c0b4f841,c51c452c,6a7,c0b4f841,c4388a48,c07b9fe0,c51c452c,8,c0b4f841,6a7) >> >> >> at _fdrop+0x43 >> >> >> closef(c49df1c0,c4971230,6a7,6a5,c4470340,...) at closef+0x290 >> >> >> fdfree(c4971230,0,c0b5014d,102,c49712d4,...) at fdfree+0x387 >> >> >> exit1(c4971230,1,c0b53f0a,aad,c0b4ed7f,...) at exit1+0x543 >> >> >> sigexit(c4971230,1,c0b53f0a,a3d,c556baa8,...) at sigexit+0xaaf >> >> >> postsig(1,0,c0b587c6,df,c496d7d4,...) at postsig+0x1dd >> >> >> ast(c4388d38) at ast+0x37f >> >> >> doreti_ast() at doreti_ast+0x17 >> >> >> uma_zalloc_arg: zone "16" with the following non-sleepable locks >> >> >> held: >> >> >> exclusive sleep mutex drmdev (drmdev) r = 0 (0xc4783cec) locked @ >> >> >> /usr/local/src/sys/modules/drm/drm/../../../dev/drm/drm_irq.c:256 >> >> >> KDB: stack backtrace: >> >> >> db_trace_self_wrapper(c0b570bb,c438874c,c07f0dd5,c4d79b8f,100,...) >> >> >> at >> >> >> db_trace_self_wrapper+0x26 >> >> >> kdb_backtrace(c4d79b8f,100,ffffffff,c0dcf79c,c4388780,...) at >> >> >> kdb_backtrace+0x29 >> >> >> _witness_debugger(c0b5930a,c4388794,4,1,0,...) at _witness_debugger >> >> >> +0x25 >> >> >> witness_warn(5,0,c0b78fa6,c0b2b3ab,c0b5930a,...) at >> >> >> witness_warn+0x1c1 >> >> >> uma_zalloc_arg(c1872960,0,102,2,1,...) at uma_zalloc_arg+0x34 >> >> >> malloc(10,c0c34a40,102,c4388838,c07a528c,...) at malloc+0xd2 >> >> >> free_unr(c49776c0,1,c4d79696,a8,c4783ef4,...) at free_unr+0x47 >> >> >> drm_drawable_free_all(c4783c00,c4d7bce0,c4d796d9,1ba,0,...) at >> >> >> drm_drawable_free_all+0x174 >> >> >> drm_lastclose(c4646c80,1,c4d796d9,2e3,8,...) at drm_lastclose+0xdf >> >> >> drm_close(c4b37000,3,2000,c4971230,c4388900,...) at drm_close+0x2ca >> >> >> giant_close(c4b37000,3,2000,c4971230,c4971230,...) at >> >> >> giant_close+0x67 >> >> >> devfs_close(c4388948,3,c4d4d430,3,c4388968,...) at devfs_close+0x29a >> >> >> VOP_CLOSE_APV(c0c26380,c4388948,c0b61a19,124,c0c63f80,...) at >> >> >> VOP_CLOSE_APV+0xa5 >> >> >> vn_close(c4d4d430,3,c4ad9700,c4971230,0,...) at vn_close+0xe4 >> >> >> vn_closefile(c49df1c0,c4971230,c43889ec,c0784853,c49df1c0,...) at >> >> >> vn_closefile+0xe9 >> >> >> devfs_close_f(c49df1c0,c4971230,0,0,c49df1c0,...) at devfs_close_f >> >> >> +0x25 >> >> >> _fdrop(c49df1c0,c4971230,c4388a20,c07f0c1c,0,c49712d4,c0dcf798,c0c317b0,c0b4f841,c51c452c,6a7,c0b4f841,c4388a48,c07b9fe0,c51c452c,8,c0b4f841,6a7) >> >> >> at _fdrop+0x43 >> >> >> closef(c49df1c0,c4971230,6a7,6a5,c4470340,...) at closef+0x290 >> >> >> fdfree(c4971230,0,c0b5014d,102,c49712d4,...) at fdfree+0x387 >> >> >> exit1(c4971230,1,c0b53f0a,aad,c0b4ed7f,...) at exit1+0x543 >> >> >> sigexit(c4971230,1,c0b53f0a,a3d,c556baa8,...) at sigexit+0xaaf >> >> >> postsig(1,0,c0b587c6,df,c496d7d4,...) at postsig+0x1dd >> >> >> ast(c4388d38) at ast+0x37f >> >> >> doreti_ast() at doreti_ast+0x17 >> >> >> uma_zalloc_arg: zone "16" with the following non-sleepable locks >> >> >> held: >> >> >> exclusive sleep mutex drmdev (drmdev) r = 0 (0xc4783cec) locked @ >> >> >> /usr/local/src/sys/modules/drm/drm/../../../dev/drm/drm_irq.c:256 >> >> >> KDB: stack backtrace: >> >> >> db_trace_self_wrapper(c0b570bb,c438874c,c07f0dd5,c4d79b8f,100,...) >> >> >> at >> >> >> db_trace_self_wrapper+0x26 >> >> >> kdb_backtrace(c4d79b8f,100,ffffffff,c0dcf79c,c4388780,...) at >> >> >> kdb_backtrace+0x29 >> >> >> _witness_debugger(c0b5930a,c4388794,4,1,0,...) at _witness_debugger >> >> >> +0x25 >> >> >> witness_warn(5,0,c0b78fa6,c0b2b3ab,c0b5930a,...) at >> >> >> witness_warn+0x1c1 >> >> >> uma_zalloc_arg(c1872960,0,102,2,1,...) at uma_zalloc_arg+0x34 >> >> >> malloc(10,c0c34a40,102,c4388838,c07a528c,...) at malloc+0xd2 >> >> >> free_unr(c49776c0,1,c4d79696,a8,c4783ef4,...) at free_unr+0x66 >> >> >> drm_drawable_free_all(c4783c00,c4d7bce0,c4d796d9,1ba,0,...) at >> >> >> drm_drawable_free_all+0x174 >> >> >> drm_lastclose(c4646c80,1,c4d796d9,2e3,8,...) at drm_lastclose+0xdf >> >> >> drm_close(c4b37000,3,2000,c4971230,c4388900,...) at drm_close+0x2ca >> >> >> giant_close(c4b37000,3,2000,c4971230,c4971230,...) at >> >> >> giant_close+0x67 >> >> >> devfs_close(c4388948,3,c4d4d430,3,c4388968,...) at devfs_close+0x29a >> >> >> VOP_CLOSE_APV(c0c26380,c4388948,c0b61a19,124,c0c63f80,...) at >> >> >> VOP_CLOSE_APV+0xa5 >> >> >> vn_close(c4d4d430,3,c4ad9700,c4971230,0,...) at vn_close+0xe4 >> >> >> vn_closefile(c49df1c0,c4971230,c43889ec,c0784853,c49df1c0,...) at >> >> >> vn_closefile+0xe9 >> >> >> devfs_close_f(c49df1c0,c4971230,0,0,c49df1c0,...) at devfs_close_f >> >> >> +0x25 >> >> >> _fdrop(c49df1c0,c4971230,c4388a20,c07f0c1c,0,c49712d4,c0dcf798,c0c317b0,c0b4f841,c51c452c,6a7,c0b4f841,c4388a48,c07b9fe0,c51c452c,8,c0b4f841,6a7) >> >> >> at _fdrop+0x43 >> >> >> closef(c49df1c0,c4971230,6a7,6a5,c4470340,...) at closef+0x290 >> >> >> fdfree(c4971230,0,c0b5014d,102,c49712d4,...) at fdfree+0x387 >> >> >> exit1(c4971230,1,c0b53f0a,aad,c0b4ed7f,...) at exit1+0x543 >> >> >> sigexit(c4971230,1,c0b53f0a,a3d,c556baa8,...) at sigexit+0xaaf >> >> >> postsig(1,0,c0b587c6,df,c496d7d4,...) at postsig+0x1dd >> >> >> ast(c4388d38) at ast+0x37f >> >> >> doreti_ast() at doreti_ast+0x17 >> >> >> drm0: [ITHREAD] >> >> >> pid 9156 (Xorg), uid 0: exited on signal 6 >> >> >> >> >> > >> > > -------------- next part -------------- A non-text attachment was scrubbed... Name: drm.debug Type: application/octet-stream Size: 23222 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20080828/897f34b7/drm.obj From rnoland at FreeBSD.org Thu Aug 28 19:55:41 2008 From: rnoland at FreeBSD.org (Robert Noland) Date: Thu Aug 28 19:55:48 2008 Subject: [CFT] drm updates In-Reply-To: <3a142e750808281145m3d49839fv4665066d1791e4e6@mail.gmail.com> References: <48B1A590.2040701@gmail.com> <1219674352.53929.2.camel@squirrel.corp.cox.com> <3a142e750808250928n612761cch69a3bd2ebf374f92@mail.gmail.com> <3a142e750808260741p224bd68aw52711eab7e76aa59@mail.gmail.com> <3a142e750808260851u13de6cf9jf2640c195f9be81e@mail.gmail.com> <1219769914.58043.11.camel@squirrel.corp.cox.com> <3a142e750808270307k237c5660ha98e8bcdfbddc4dc@mail.gmail.com> <1219850374.61484.7.camel@squirrel.corp.cox.com> <3a142e750808281007r42bbe4d0u53be9c0074386c10@mail.gmail.com> <1219944411.61066.5.camel@squirrel.corp.cox.com> <3a142e750808281145m3d49839fv4665066d1791e4e6@mail.gmail.com> Message-ID: <1219953332.2212.4.camel@squirrel.corp.cox.com> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20080828/a192eadd/attachment.pgp From admin at lissyara.su Fri Aug 29 08:10:03 2008 From: admin at lissyara.su (Alex Keda) Date: Fri Aug 29 08:10:10 2008 Subject: ports/126812: x11-drivers/xf86-video-ati - System freeze when exiting X server when using ati or radeon drivers on AMD 780G Message-ID: <200808290810.m7T8A3et022286@freefall.freebsd.org> The following reply was made to PR ports/126812; it has been noted by GNATS. From: Alex Keda To: bug-followup@FreeBSD.org, dinjiin@yahoo.com Cc: Subject: Re: ports/126812: x11-drivers/xf86-video-ati - System freeze when exiting X server when using ati or radeon drivers on AMD 780G Date: Fri, 29 Aug 2008 12:00:57 +0400 acer# uname -a FreeBSD acer.lissyara.int.otradno.ru 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Fri Aug 29 04:16:32 MSD 2008 root@acer.lissyara.int.otradno.ru:/var/tmp/obj/usr/src/sys/main-color-console amd64 some behavior - system hang when X start, with vgapci0@pci0:1:5:0: class=0x030000 card=0x009f1025 chip=0x59751002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'Radeon XPRESS 200M SERIES' class = display subclass = VGA but, with dri enabled. System work, but X server get all resourse, and system very slow response - shutdown system by short press power button - 10-15 minutes... Without hardware acceleration - all OK From onemda at gmail.com Fri Aug 29 10:54:54 2008 From: onemda at gmail.com (Paul B. Mahol) Date: Fri Aug 29 10:55:01 2008 Subject: [CFT] drm updates In-Reply-To: <1219953332.2212.4.camel@squirrel.corp.cox.com> References: <48B1A590.2040701@gmail.com> <3a142e750808260741p224bd68aw52711eab7e76aa59@mail.gmail.com> <3a142e750808260851u13de6cf9jf2640c195f9be81e@mail.gmail.com> <1219769914.58043.11.camel@squirrel.corp.cox.com> <3a142e750808270307k237c5660ha98e8bcdfbddc4dc@mail.gmail.com> <1219850374.61484.7.camel@squirrel.corp.cox.com> <3a142e750808281007r42bbe4d0u53be9c0074386c10@mail.gmail.com> <1219944411.61066.5.camel@squirrel.corp.cox.com> <3a142e750808281145m3d49839fv4665066d1791e4e6@mail.gmail.com> <1219953332.2212.4.camel@squirrel.corp.cox.com> Message-ID: <3a142e750808290354x2578a075r50ab0cd6edc21ed5@mail.gmail.com> On 8/28/08, Robert Noland wrote: > On Thu, 2008-08-28 at 20:45 +0200, Paul B. Mahol wrote: >> On 8/28/08, Robert Noland wrote: >> > On Thu, 2008-08-28 at 19:07 +0200, Paul B. Mahol wrote: >> >> On 8/27/08, Robert Noland wrote: >> >> > On Wed, 2008-08-27 at 12:07 +0200, Paul B. Mahol wrote: >> >> >> On 8/26/08, Robert Noland wrote: >> >> >> > On Tue, 2008-08-26 at 17:51 +0200, Paul B. Mahol wrote: >> >> >> >> Here is more kernel debug info (after updating libdrm and testing >> >> >> >> with >> >> >> >> glxgears) >> >> >> > >> >> >> > I don't think that the two issues are related, but try this >> >> >> > patch... >> >> >> > It >> >> >> > should at least, resolve the issue below. >> >> >> > >> >> >> > robert. >> >> >> >> >> >> Issue bellow is fixed, previous problem still exist. >> >> >> >> >> >> textdump of panic when unloading drm attached. >> >> > >> >> > Ok, The locking semantics are a nightmare... Give this a try, it >> >> > should >> >> > correct both the previous issue as well as this one. >> >> > >> >> > robert. >> >> > >> >> >> >> Panic fixed, now only Xorg crashing when using glxgears (,...) remains >> >> ;) >> > >> > Ok, what hardware are you using again? Can you manually load drm >> > modules and set hw.dri.0.debug=1 and send me the debug output? >> > >> > robert. >> >> Hardware: "Mobile 945GM/GU Express Integrated Graphics Controller" >> Debug ouptut attached. > > Alright, try this... I was pointed at this from another thread, but > your trace confirms why it doesn't work, at least with your driver. > > robert. > Nothing improved with that patch, still crash with glxgears, and lock with stellarium. How to make sure that this is really drm problem and not i915, Xorg, mesa-ports that need recompiling? From ray at one.com.au Fri Aug 29 08:21:36 2008 From: ray at one.com.au (Ray Newman) Date: Fri Aug 29 11:28:03 2008 Subject: Dual (zaphod) head on Intel i810 does not work for FreeBSD V7.0 Release Message-ID: <7FD401C4-3F70-4B91-9235-0EEA290C3967@one.com.au> Hi, Under FreeBSD V6.2 Release (X 6.9.0 and i810 1.4.1) with this xorg.conf, this log file is produced and the dual screen config works. -------------- next part -------------- A non-text attachment was scrubbed... Name: xorg.conf_V62 Type: application/octet-stream Size: 3756 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20080829/e47d7e17/xorg-0002.obj -------------- next part -------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: Xorg.0.log_V62 Type: application/octet-stream Size: 105508 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20080829/e47d7e17/Xorg.0-0002.obj -------------- next part -------------- Under FreeBSD V7.0 Release (X 1.4.0 and i810 1.6.5) with this xorg.conf which is nearly identical with the previous one, this log file is produced and the dual screen doesn't work. It seems to get the primary and secondary screens totally confused. -------------- next part -------------- A non-text attachment was scrubbed... Name: xorg.conf_DUAL Type: application/octet-stream Size: 3064 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20080829/e47d7e17/xorg-0003.obj -------------- next part -------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: Xorg.0.log Type: application/octet-stream Size: 104481 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20080829/e47d7e17/Xorg.0-0003.obj -------------- next part -------------- Ray Newman 29 Aug 2008 From jhein at timing.com Fri Aug 29 13:44:30 2008 From: jhein at timing.com (John Hein) Date: Fri Aug 29 13:44:36 2008 Subject: Dual (zaphod) head on Intel i810 does not work for FreeBSD V7.0 Release In-Reply-To: <7FD401C4-3F70-4B91-9235-0EEA290C3967@one.com.au> References: <7FD401C4-3F70-4B91-9235-0EEA290C3967@one.com.au> Message-ID: <18615.61491.957269.935152@gromit.timing.com> Ray Newman wrote at 17:56 +1000 on Aug 29, 2008: > Under FreeBSD V6.2 Release (X 6.9.0 and i810 1.4.1) with this > xorg.conf, this log file > is produced and the dual screen config works. . . > Under FreeBSD V7.0 Release (X 1.4.0 and i810 1.6.5) with this > xorg.conf which is nearly > identical with the previous one, this log file is produced and the > dual screen doesn't work. > It seems to get the primary and secondary screens totally confused. What if you try x11-drivers/xf86-video-intel instead of x11-drivers/xf86-video-i810? From tevans.uk at googlemail.com Fri Aug 29 14:13:27 2008 From: tevans.uk at googlemail.com (Tom Evans) Date: Fri Aug 29 14:13:34 2008 Subject: Dual (zaphod) head on Intel i810 does not work for FreeBSD V7.0 Release In-Reply-To: <7FD401C4-3F70-4B91-9235-0EEA290C3967@one.com.au> References: <7FD401C4-3F70-4B91-9235-0EEA290C3967@one.com.au> Message-ID: <1220017458.70002.114.camel@localhost> On Fri, 2008-08-29 at 17:56 +1000, Ray Newman wrote: > Hi, > > Under FreeBSD V6.2 Release (X 6.9.0 and i810 1.4.1) with this > xorg.conf, this log file > is produced and the dual screen config works. > > > Under FreeBSD V7.0 Release (X 1.4.0 and i810 1.6.5) with this xorg.conf which is nearly > identical with the previous one, this log file is produced and the dual screen doesn't work. > It seems to get the primary and secondary screens totally confused. > > Ray Newman > 29 Aug 2008 With X 1.4, use driver intel ( x11-drivers/xf86-video-intel ) and xrandr to achieve the same effect. This has the benefit of dynamically enabling or disabling additional heads. The configuration is slightly different, here is a pertinent snippet from mine for comparison. There is only one device, screen and monitor specified in the conf. Section "Device" Identifier "Card0" Driver "intel" VendorName "Intel Corporation" Option "DRI" "true" BoardName "Mobile Integrated Graphics Controller" BusID "PCI:0:2:0" Screen 0 EndSection Section "Screen" Identifier "Screen0" Device "Card0" Monitor "Monitor0" SubSection "Display" Viewport 0 0 Depth 32 Modes "1400x1050" Virtual 2680 1050 EndSubSection EndSection My laptop has an internal 1400x1050 screen, and also a 1280x1024 external screen to its left. It's enabled from my .xinitrc with a command like 'xrandr --output VGA --mode 1280x1024 --left-of LVDS'. Apparently due to hardware limitations, if your 'Virtual' is more than 2048x2048 in any dimension, then DRI won't work. Cheers Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20080829/e84023e3/attachment.pgp From rnoland at FreeBSD.org Fri Aug 29 15:55:18 2008 From: rnoland at FreeBSD.org (Robert Noland) Date: Fri Aug 29 15:55:24 2008 Subject: [CFT] drm updates In-Reply-To: <3a142e750808290354x2578a075r50ab0cd6edc21ed5@mail.gmail.com> References: <48B1A590.2040701@gmail.com> <3a142e750808260741p224bd68aw52711eab7e76aa59@mail.gmail.com> <3a142e750808260851u13de6cf9jf2640c195f9be81e@mail.gmail.com> <1219769914.58043.11.camel@squirrel.corp.cox.com> <3a142e750808270307k237c5660ha98e8bcdfbddc4dc@mail.gmail.com> <1219850374.61484.7.camel@squirrel.corp.cox.com> <3a142e750808281007r42bbe4d0u53be9c0074386c10@mail.gmail.com> <1219944411.61066.5.camel@squirrel.corp.cox.com> <3a142e750808281145m3d49839fv4665066d1791e4e6@mail.gmail.com> <1219953332.2212.4.camel@squirrel.corp.cox.com> <3a142e750808290354x2578a075r50ab0cd6edc21ed5@mail.gmail.com> Message-ID: <1220025309.37942.35.camel@squirrel.corp.cox.com> On Fri, 2008-08-29 at 12:54 +0200, Paul B. Mahol wrote: > On 8/28/08, Robert Noland wrote: > > On Thu, 2008-08-28 at 20:45 +0200, Paul B. Mahol wrote: > >> On 8/28/08, Robert Noland wrote: > >> > On Thu, 2008-08-28 at 19:07 +0200, Paul B. Mahol wrote: > >> >> On 8/27/08, Robert Noland wrote: > >> >> > On Wed, 2008-08-27 at 12:07 +0200, Paul B. Mahol wrote: > >> >> >> On 8/26/08, Robert Noland wrote: > >> >> >> > On Tue, 2008-08-26 at 17:51 +0200, Paul B. Mahol wrote: > >> >> >> >> Here is more kernel debug info (after updating libdrm and testing > >> >> >> >> with > >> >> >> >> glxgears) > >> >> >> > > >> >> >> > I don't think that the two issues are related, but try this > >> >> >> > patch... > >> >> >> > It > >> >> >> > should at least, resolve the issue below. > >> >> >> > > >> >> >> > robert. > >> >> >> > >> >> >> Issue bellow is fixed, previous problem still exist. > >> >> >> > >> >> >> textdump of panic when unloading drm attached. > >> >> > > >> >> > Ok, The locking semantics are a nightmare... Give this a try, it > >> >> > should > >> >> > correct both the previous issue as well as this one. > >> >> > > >> >> > robert. > >> >> > > >> >> > >> >> Panic fixed, now only Xorg crashing when using glxgears (,...) remains > >> >> ;) > >> > > >> > Ok, what hardware are you using again? Can you manually load drm > >> > modules and set hw.dri.0.debug=1 and send me the debug output? > >> > > >> > robert. > >> > >> Hardware: "Mobile 945GM/GU Express Integrated Graphics Controller" > >> Debug ouptut attached. > > > > Alright, try this... I was pointed at this from another thread, but > > your trace confirms why it doesn't work, at least with your driver. > > > > robert. > > > > Nothing improved with that patch, still crash with glxgears, and lock > with stellarium. ok, I don't understand why I'm not seeing any of this on my 965gm... If you want to send me another debug trace, I'll see if I can tell what is going on now... Also, please send me a copy of your xorg.conf. > How to make sure that this is really drm problem and not i915, Xorg, > mesa-ports that need recompiling? If you are using current ports tree, then nothing should need rebuilding that I can think of. I have been using git libdrm and xf86-video-intel driver, but what is in ports now should be fine I think. The updated libdrm should only be required to get the new vblank code to allow it to disable vblank interrupts. There is a bug which prevents vblanks irqs from being disabled after a vt switch, but it shouldn't have a real impact on functionality. robert. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20080829/1370b697/attachment.pgp From onemda at gmail.com Fri Aug 29 20:29:58 2008 From: onemda at gmail.com (Paul B. Mahol) Date: Fri Aug 29 20:30:05 2008 Subject: [CFT] drm updates In-Reply-To: <1220025309.37942.35.camel@squirrel.corp.cox.com> References: <48B1A590.2040701@gmail.com> <1219769914.58043.11.camel@squirrel.corp.cox.com> <3a142e750808270307k237c5660ha98e8bcdfbddc4dc@mail.gmail.com> <1219850374.61484.7.camel@squirrel.corp.cox.com> <3a142e750808281007r42bbe4d0u53be9c0074386c10@mail.gmail.com> <1219944411.61066.5.camel@squirrel.corp.cox.com> <3a142e750808281145m3d49839fv4665066d1791e4e6@mail.gmail.com> <1219953332.2212.4.camel@squirrel.corp.cox.com> <3a142e750808290354x2578a075r50ab0cd6edc21ed5@mail.gmail.com> <1220025309.37942.35.camel@squirrel.corp.cox.com> Message-ID: <3a142e750808291329l1836bc9bv8e94bdd96bd343aa@mail.gmail.com> On 8/29/08, Robert Noland wrote: > On Fri, 2008-08-29 at 12:54 +0200, Paul B. Mahol wrote: >> On 8/28/08, Robert Noland wrote: >> > On Thu, 2008-08-28 at 20:45 +0200, Paul B. Mahol wrote: >> >> On 8/28/08, Robert Noland wrote: >> >> > On Thu, 2008-08-28 at 19:07 +0200, Paul B. Mahol wrote: >> >> >> On 8/27/08, Robert Noland wrote: >> >> >> > On Wed, 2008-08-27 at 12:07 +0200, Paul B. Mahol wrote: >> >> >> >> On 8/26/08, Robert Noland wrote: >> >> >> >> > On Tue, 2008-08-26 at 17:51 +0200, Paul B. Mahol wrote: >> >> >> >> >> Here is more kernel debug info (after updating libdrm and >> >> >> >> >> testing >> >> >> >> >> with >> >> >> >> >> glxgears) >> >> >> >> > >> >> >> >> > I don't think that the two issues are related, but try this >> >> >> >> > patch... >> >> >> >> > It >> >> >> >> > should at least, resolve the issue below. >> >> >> >> > >> >> >> >> > robert. >> >> >> >> >> >> >> >> Issue bellow is fixed, previous problem still exist. >> >> >> >> >> >> >> >> textdump of panic when unloading drm attached. >> >> >> > >> >> >> > Ok, The locking semantics are a nightmare... Give this a try, it >> >> >> > should >> >> >> > correct both the previous issue as well as this one. >> >> >> > >> >> >> > robert. >> >> >> > >> >> >> >> >> >> Panic fixed, now only Xorg crashing when using glxgears (,...) >> >> >> remains >> >> >> ;) >> >> > >> >> > Ok, what hardware are you using again? Can you manually load drm >> >> > modules and set hw.dri.0.debug=1 and send me the debug output? >> >> > >> >> > robert. >> >> >> >> Hardware: "Mobile 945GM/GU Express Integrated Graphics Controller" >> >> Debug ouptut attached. >> > >> > Alright, try this... I was pointed at this from another thread, but >> > your trace confirms why it doesn't work, at least with your driver. >> > >> > robert. >> > >> >> Nothing improved with that patch, still crash with glxgears, and lock >> with stellarium. > > ok, I don't understand why I'm not seeing any of this on my 965gm... If > you want to send me another debug trace, I'll see if I can tell what is > going on now... Also, please send me a copy of your xorg.conf. Well, actually it is: agp0: on vgapci0 agp0: detected 7932k stolen memory agp0: aperture size is 256M drm0: on vgapci0 > >> How to make sure that this is really drm problem and not i915, Xorg, >> mesa-ports that need recompiling? > > If you are using current ports tree, then nothing should need rebuilding > that I can think of. I have been using git libdrm and xf86-video-intel > driver, but what is in ports now should be fine I think. The updated > libdrm should only be required to get the new vblank code to allow it to > disable vblank interrupts. > > There is a bug which prevents vblanks irqs from being disabled after a > vt switch, but it shouldn't have a real impact on functionality. > > robert. > > From linimon at FreeBSD.org Fri Aug 29 22:09:25 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Fri Aug 29 22:09:37 2008 Subject: ports/126937: x11/xorg: System hang when start X Message-ID: <200808292209.m7TM9PTa019608@freefall.freebsd.org> Old Synopsis: System hang when start X New Synopsis: x11/xorg: System hang when start X Responsible-Changed-From-To: freebsd-bugs->freebsd-x11 Responsible-Changed-By: linimon Responsible-Changed-When: Fri Aug 29 22:08:46 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=126937 From rnoland at FreeBSD.org Fri Aug 29 23:00:13 2008 From: rnoland at FreeBSD.org (Robert Noland) Date: Fri Aug 29 23:00:24 2008 Subject: ports/126937: x11/xorg: System hang when start X Message-ID: <200808292300.m7TN08Vn024778@freefall.freebsd.org> The following reply was made to PR ports/126937; it has been noted by GNATS. From: Robert Noland To: bug-followup@FreeBSD.org, admin@lissyara.su Cc: Subject: Re: ports/126937: x11/xorg: System hang when start X Date: Fri, 29 Aug 2008 18:55:38 -0400 --=-DH+RrNeqQ0obTMOkvqOT Content-Type: text/plain Content-Transfer-Encoding: quoted-printable This should probably be a kern pr, assigned to me. If I can have kern pr's assigned that is. This is almost certainly a drm problem. I have a few commits that I will make tonight that address some issues, however there are know issues with the Radeon 200Ms. robert. --=-DH+RrNeqQ0obTMOkvqOT Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEABECAAYFAki4fmoACgkQM4TrQ4qfROMWGgCffL87Dj5pcVBrTHyqsBVj9BUS LdcAnikIjVQ0QSHVhTM5+n2GzuwicJsn =PQKB -----END PGP SIGNATURE----- --=-DH+RrNeqQ0obTMOkvqOT-- From linimon at FreeBSD.org Sat Aug 30 00:06:41 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sat Aug 30 00:06:47 2008 Subject: kern/126937: [drm] System hang when start X Message-ID: <200808300006.m7U06epB030424@freefall.freebsd.org> Old Synopsis: x11/xorg: System hang when start X New Synopsis: [drm] System hang when start X Responsible-Changed-From-To: freebsd-x11->rnoland Responsible-Changed-By: linimon Responsible-Changed-When: Sat Aug 30 00:05:56 UTC 2008 Responsible-Changed-Why: Over to volunteer. http://www.freebsd.org/cgi/query-pr.cgi?pr=126937 From rnoland at FreeBSD.org Sat Aug 30 01:19:13 2008 From: rnoland at FreeBSD.org (Robert Noland) Date: Sat Aug 30 01:19:20 2008 Subject: drm patches in -CURRENT Message-ID: <1220059142.1883.8.camel@wombat.2hip.net> I just committed a series of patches to -CURRENT that address the locking issues that some of you were seeing. If you were using any of my patches, they are not needed now. If you are still having issues, feel free to let me know. It may also be good to file a kern pr, so that I can keep track of the issues. robert. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20080830/4ad30eb0/attachment.pgp From bitsnstuff101 at tiscali.co.uk Sat Aug 30 01:32:15 2008 From: bitsnstuff101 at tiscali.co.uk (NVangogh) Date: Sat Aug 30 01:32:22 2008 Subject: startx will start X with fvwm but not gnome help Message-ID: <48B8A316.2070200@tiscali.co.uk> I have searched the net but cannot find an answer for this. I have the latest xorg server pkg installed and configured x11. I have the correct driver installed for my system chipset.: xf86-video-intel. I am guessing the problem is not with my xorg.conf [cause fvwm works & the problem is also repeated on another pc of mine] The problem is that I cannot seem to startx with any wm other than fvwm (this is fine, but i prefer gnome). this is what i have tried 1. I have followed the standard procedure: echo "/usr/local/bin/gnome- session" > /home/mydir/.xinitrc. On re-booting i try startx and get the error i830 Vblank pipe setup failed 0. - x will not start at all. 2. alternatively - in /etc/rc.conf gnome_enable="YES". The very first time i booted with this, it worked. The next day (today) I tried to boot and got the gdm login screen. After entering my details, the gnome splash screen appears..but it seems to hang. I left it and it was like this for nearly 15 minutes. Eventually my desktop appeared - but everything was sluggish & some progs would not start eg i could not even open a terminal. After a while the session just terminates and causes a re-boot. I have tried this twice and the same thing happens. 3. Instead of gdm, i have also used the kdm and got the same problem. Anyone please assist with this problem? (To run gnome, i have to startx -which starts with with fvwm -then run a gnome-session from a aterm console. this is burning up my limited resources and of course all windows open in the fvwm style which is not ideal. From rnoland at FreeBSD.org Sat Aug 30 01:44:12 2008 From: rnoland at FreeBSD.org (Robert Noland) Date: Sat Aug 30 01:44:19 2008 Subject: startx will start X with fvwm but not gnome help In-Reply-To: <48B8A316.2070200@tiscali.co.uk> References: <48B8A316.2070200@tiscali.co.uk> Message-ID: <1220060640.1883.17.camel@wombat.2hip.net> On Sat, 2008-08-30 at 02:32 +0100, NVangogh wrote: > I have searched the net but cannot find an answer for this. > I have the latest xorg server pkg installed and configured x11. I have > the correct driver installed for my system chipset.: xf86-video-intel. I > am guessing the problem is not with my xorg.conf [cause fvwm works & the > problem is also repeated on another pc of mine] > > The problem is that I cannot seem to startx with any wm other than fvwm > (this is fine, but i prefer gnome). > > this is what i have tried > > 1. I have followed the standard procedure: echo "/usr/local/bin/gnome- > session" > /home/mydir/.xinitrc. On re-booting i try startx and get the > error i830 Vblank pipe setup failed 0. - x will not start at all. > > 2. alternatively - in /etc/rc.conf gnome_enable="YES". > The very first time i booted with this, it worked. The next day (today) I > tried to boot and got the gdm login screen. After entering my details, > the gnome splash screen appears..but it seems to hang. I left it and it > was like this for nearly 15 minutes. Eventually my desktop appeared - but > everything was sluggish & some progs would not start eg i could not even > open a terminal. After a while the session just terminates and causes a > re-boot. I have tried this twice and the same thing happens. > > 3. Instead of gdm, i have also used the kdm and got the same problem. Are you running current? or using my drm update patch? If the answer is yes, this sounds like the hang that I am getting on my 965gm. For me, it only happens if I restart X. I'm still looking for the root cause, but my latest theory is that it is related to the vblank-rework. I know that their is a problem with during/after vt switch, which is either a bug in the intel driver or drm. I'm working with the intel developers to figure out where is the best place to fix it. If you are using the latest drm, I'll need some more details to be sure that the issue you are seeing is the same. If you are not, then it is something else... robert. > > Anyone please assist with this problem? > (To run gnome, i have to startx -which starts with with fvwm -then run a > gnome-session from a aterm console. this is burning up my limited > resources and of course all windows open in the fvwm style which is not > ideal. > _______________________________________________ > freebsd-x11@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-x11 > To unsubscribe, send any mail to "freebsd-x11-unsubscribe@freebsd.org" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20080830/5999a985/attachment.pgp From ray at one.com.au Sat Aug 30 05:13:21 2008 From: ray at one.com.au (Ray Newman) Date: Sat Aug 30 05:13:27 2008 Subject: Dual (zaphod) head on Intel i810 does not work for FreeBSD V7.0 Release In-Reply-To: <1220017458.70002.114.camel@localhost> References: <7FD401C4-3F70-4B91-9235-0EEA290C3967@one.com.au> <1220017458.70002.114.camel@localhost> Message-ID: <1366D73B-2645-4FFF-845E-EEDF2E8310FF@one.com.au> Hi, Using the intel driver, I can *ALMOST* get there. What I want to do is run KDE and general apps on the first screen - LVDS ( :0.0 ) and run one single X app on the second screen - CRT ( :0.1 ). Using the intel drivers, I can't get KDE to leave the second screen alone. In fact, it keeps moving the panel to it. The docs with the intel driver say it just doesn't support dual (zaphod) head mode. Are the i810 drivers still in use? They also *ALMOST* get there in zaphod mode - they just stuff the screen modes at the last moment. Ray Newman On 29/08/2008, at 11:44 PM, Tom Evans wrote: > On Fri, 2008-08-29 at 17:56 +1000, Ray Newman wrote: >> Hi, >> >> Under FreeBSD V6.2 Release (X 6.9.0 and i810 1.4.1) with this >> xorg.conf, this log file >> is produced and the dual screen config works. >> >> >> Under FreeBSD V7.0 Release (X 1.4.0 and i810 1.6.5) with this >> xorg.conf which is nearly >> identical with the previous one, this log file is produced and the >> dual screen doesn't work. >> It seems to get the primary and secondary screens totally confused. >> >> Ray Newman >> 29 Aug 2008 > > > With X 1.4, use driver intel ( x11-drivers/xf86-video-intel ) and > xrandr > to achieve the same effect. This has the benefit of dynamically > enabling > or disabling additional heads. The configuration is slightly > different, > here is a pertinent snippet from mine for comparison. There is only > one > device, screen and monitor specified in the conf. > > Section "Device" > Identifier "Card0" > Driver "intel" > VendorName "Intel Corporation" > Option "DRI" "true" > BoardName "Mobile Integrated Graphics Controller" > BusID "PCI:0:2:0" > Screen 0 > EndSection > > Section "Screen" > Identifier "Screen0" > Device "Card0" > Monitor "Monitor0" > SubSection "Display" > Viewport 0 0 > Depth 32 > Modes "1400x1050" > Virtual 2680 1050 > EndSubSection > EndSection > > My laptop has an internal 1400x1050 screen, and also a 1280x1024 > external screen to its left. It's enabled from my .xinitrc with a > command like 'xrandr --output VGA --mode 1280x1024 --left-of LVDS'. > Apparently due to hardware limitations, if your 'Virtual' is more than > 2048x2048 in any dimension, then DRI won't work. > > Cheers > > Tom From onemda at gmail.com Sat Aug 30 10:57:50 2008 From: onemda at gmail.com (Paul B. Mahol) Date: Sat Aug 30 10:57:57 2008 Subject: [CFT] drm updates In-Reply-To: <3a142e750808291329l1836bc9bv8e94bdd96bd343aa@mail.gmail.com> References: <48B1A590.2040701@gmail.com> <3a142e750808270307k237c5660ha98e8bcdfbddc4dc@mail.gmail.com> <1219850374.61484.7.camel@squirrel.corp.cox.com> <3a142e750808281007r42bbe4d0u53be9c0074386c10@mail.gmail.com> <1219944411.61066.5.camel@squirrel.corp.cox.com> <3a142e750808281145m3d49839fv4665066d1791e4e6@mail.gmail.com> <1219953332.2212.4.camel@squirrel.corp.cox.com> <3a142e750808290354x2578a075r50ab0cd6edc21ed5@mail.gmail.com> <1220025309.37942.35.camel@squirrel.corp.cox.com> <3a142e750808291329l1836bc9bv8e94bdd96bd343aa@mail.gmail.com> Message-ID: <3a142e750808300357s49ebb105k589c749526fbd79c@mail.gmail.com> On 8/29/08, Paul B. Mahol wrote: > On 8/29/08, Robert Noland wrote: >> On Fri, 2008-08-29 at 12:54 +0200, Paul B. Mahol wrote: >>> On 8/28/08, Robert Noland wrote: >>> > On Thu, 2008-08-28 at 20:45 +0200, Paul B. Mahol wrote: >>> >> On 8/28/08, Robert Noland wrote: >>> >> > On Thu, 2008-08-28 at 19:07 +0200, Paul B. Mahol wrote: >>> >> >> On 8/27/08, Robert Noland wrote: >>> >> >> > On Wed, 2008-08-27 at 12:07 +0200, Paul B. Mahol wrote: >>> >> >> >> On 8/26/08, Robert Noland wrote: >>> >> >> >> > On Tue, 2008-08-26 at 17:51 +0200, Paul B. Mahol wrote: >>> >> >> >> >> Here is more kernel debug info (after updating libdrm and >>> >> >> >> >> testing >>> >> >> >> >> with >>> >> >> >> >> glxgears) >>> >> >> >> > >>> >> >> >> > I don't think that the two issues are related, but try this >>> >> >> >> > patch... >>> >> >> >> > It >>> >> >> >> > should at least, resolve the issue below. >>> >> >> >> > >>> >> >> >> > robert. >>> >> >> >> >>> >> >> >> Issue bellow is fixed, previous problem still exist. >>> >> >> >> >>> >> >> >> textdump of panic when unloading drm attached. >>> >> >> > >>> >> >> > Ok, The locking semantics are a nightmare... Give this a try, it >>> >> >> > should >>> >> >> > correct both the previous issue as well as this one. >>> >> >> > >>> >> >> > robert. >>> >> >> > >>> >> >> >>> >> >> Panic fixed, now only Xorg crashing when using glxgears (,...) >>> >> >> remains >>> >> >> ;) >>> >> > >>> >> > Ok, what hardware are you using again? Can you manually load drm >>> >> > modules and set hw.dri.0.debug=1 and send me the debug output? >>> >> > >>> >> > robert. >>> >> >>> >> Hardware: "Mobile 945GM/GU Express Integrated Graphics Controller" >>> >> Debug ouptut attached. >>> > >>> > Alright, try this... I was pointed at this from another thread, but >>> > your trace confirms why it doesn't work, at least with your driver. >>> > >>> > robert. >>> > >>> >>> Nothing improved with that patch, still crash with glxgears, and lock >>> with stellarium. >> >> ok, I don't understand why I'm not seeing any of this on my 965gm... If >> you want to send me another debug trace, I'll see if I can tell what is >> going on now... Also, please send me a copy of your xorg.conf. > > Well, actually it is: > > agp0: on vgapci0 > agp0: detected 7932k stolen memory > agp0: aperture size is 256M > drm0: on vgapci0 > >> >>> How to make sure that this is really drm problem and not i915, Xorg, >>> mesa-ports that need recompiling? >> >> If you are using current ports tree, then nothing should need rebuilding >> that I can think of. I have been using git libdrm and xf86-video-intel >> driver, but what is in ports now should be fine I think. The updated >> libdrm should only be required to get the new vblank code to allow it to >> disable vblank interrupts. >> >> There is a bug which prevents vblanks irqs from being disabled after a >> vt switch, but it shouldn't have a real impact on functionality. >> >> robert. >> >> > Ooops, there is still (with newest HEAD) panic when unloading agp module, textdump with backtrack and alltrace attached. From rnoland at FreeBSD.org Sat Aug 30 14:17:08 2008 From: rnoland at FreeBSD.org (Robert Noland) Date: Sat Aug 30 14:17:14 2008 Subject: [CFT] drm updates In-Reply-To: <3a142e750808300357s49ebb105k589c749526fbd79c@mail.gmail.com> References: <48B1A590.2040701@gmail.com> <3a142e750808270307k237c5660ha98e8bcdfbddc4dc@mail.gmail.com> <1219850374.61484.7.camel@squirrel.corp.cox.com> <3a142e750808281007r42bbe4d0u53be9c0074386c10@mail.gmail.com> <1219944411.61066.5.camel@squirrel.corp.cox.com> <3a142e750808281145m3d49839fv4665066d1791e4e6@mail.gmail.com> <1219953332.2212.4.camel@squirrel.corp.cox.com> <3a142e750808290354x2578a075r50ab0cd6edc21ed5@mail.gmail.com> <1220025309.37942.35.camel@squirrel.corp.cox.com> <3a142e750808291329l1836bc9bv8e94bdd96bd343aa@mail.gmail.com> <3a142e750808300357s49ebb105k589c749526fbd79c@mail.gmail.com> Message-ID: <1220105815.1832.2.camel@wombat.2hip.net> On Sat, 2008-08-30 at 12:57 +0200, Paul B. Mahol wrote: > Ooops, there is still (with newest HEAD) panic when unloading agp > module, > textdump with backtrack and alltrace attached. I haven't messed with the agp module. What was the panic message? I don't see it in the dump. robert. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20080830/e044c939/attachment.pgp From onemda at gmail.com Sat Aug 30 14:51:57 2008 From: onemda at gmail.com (Paul B. Mahol) Date: Sat Aug 30 14:55:22 2008 Subject: [CFT] drm updates In-Reply-To: <1220105815.1832.2.camel@wombat.2hip.net> References: <48B1A590.2040701@gmail.com> <3a142e750808281007r42bbe4d0u53be9c0074386c10@mail.gmail.com> <1219944411.61066.5.camel@squirrel.corp.cox.com> <3a142e750808281145m3d49839fv4665066d1791e4e6@mail.gmail.com> <1219953332.2212.4.camel@squirrel.corp.cox.com> <3a142e750808290354x2578a075r50ab0cd6edc21ed5@mail.gmail.com> <1220025309.37942.35.camel@squirrel.corp.cox.com> <3a142e750808291329l1836bc9bv8e94bdd96bd343aa@mail.gmail.com> <3a142e750808300357s49ebb105k589c749526fbd79c@mail.gmail.com> <1220105815.1832.2.camel@wombat.2hip.net> Message-ID: <3a142e750808300751h56718e17kdff447d7931dcb6b@mail.gmail.com> On 8/30/08, Robert Noland wrote: > On Sat, 2008-08-30 at 12:57 +0200, Paul B. Mahol wrote: >> Ooops, there is still (with newest HEAD) panic when unloading agp >> module, >> textdump with backtrack and alltrace attached. > > I haven't messed with the agp module. What was the panic message? I > don't see it in the dump. > > robert. > > Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xdeade0fe fault code = supervisor read, page not present instruction pointer = 0x20:0xc4810152 stack pointer = 0x28:0xc3b26b60 frame pointer = 0x28:0xc3b26b78 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 843 (kldunload) bt: Tracing pid 843 tid 100080 td 0xc458f230 agp_i810_detach(c3f98080,c41b1858,c06ff494,9a2,1,...) at agp_i810_detach+0x52 device_detach(c3f98080,c04f1c79,c403d980,1,c481b27c,...) at device_detach+0x8c devclass_delete_driver(c3e0cb80,c481b290,c06c981d,2d,c073fcac,...) at devclass_delete_driver+0x91 driver_module_handler(c400de80,1,c481b27c,ef,c400de80,...) at driver_module_handler+0xd5 module_unload(c400de80,0,253,250,c3b26c40,...) at module_unload+0x75 linker_file_unload(c4684500,0,c06c7d4c,400,c4808000,...) at linker_file_unload+0xc9 kern_kldunload(c458f230,d,0,c3b26d2c,c06a3a33,...) at kern_kldunload+0xd5 kldunloadf(c458f230,c3b26cf8,8,c06d1d21,c07027a0,...) at kldunloadf+0x2b syscall(c3b26d38) at syscall+0x283 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (444, FreeBSD ELF32, kldunloadf), eip = 0x280cde4b, esp = 0xbfbfe4fc, ebp = 0xbfbfed48 --- It is strange that panic happen only and only if i915 was loaded. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Un/loading drm with agp several times doesnt produce panic. From pav at FreeBSD.org Sat Aug 30 22:01:20 2008 From: pav at FreeBSD.org (Pav Lucistnik) Date: Sat Aug 30 22:01:28 2008 Subject: [Fwd: xf86-video-i810-1.7.4_1 failed on amd64 6] Message-ID: <1220132049.45895.41.camel@ikaros.oook.cz> -------- P?eposlan? zpr?va -------- > Od: User Ports-amd64 > Komu: cvs@oook.cz > P?edm?t: xf86-video-i810-1.7.4_1 failed on amd64 6 > Datum: Sat, 30 Aug 2008 18:19:49 GMT > > You can also find this build log at > > http://pointyhat.FreeBSD.org/errorlogs/amd64-errorlogs/a.6.20080829144210/xf86-video-i810-1.7.4_1.log > > building xf86-video-i810-1.7.4_1 on hammer2.isc.gumbysoft.com > in directory /usr2/pkgbuild/6/20080829144210/chroot/1185 > building for: 6.3-STABLE amd64 > maintained by: x11@FreeBSD.org > port directory: /usr/ports/x11-drivers/xf86-video-i810 > Makefile ident: $FreeBSD: ports/x11-drivers/xf86-video-i810/Makefile,v 1.6 2008/06/06 14:10:25 edwin Exp $ > build started at Sat Aug 30 18:18:38 UTC 2008 > FETCH_DEPENDS= > PATCH_DEPENDS= > EXTRACT_DEPENDS= > BUILD_DEPENDS=consolekit-0.2.10_2.tbz damageproto-1.1.0_2.tbz dbus-1.2.1.tbz dbus-glib-0.76.tbz dmidecode-2.9.tbz expat-2.0.1.tbz fixesproto-4.0.tbz fontsproto-2.0.2.tbz freetype2-2.3.7.tbz gamin-0.1.9_2.tbz gettext-0.17_1.tbz gio-fam-backend-2.16.5.tbz glib-2.16.5.tbz glproto-1.4.8.tbz gnome_subr-1.0.tbz hal-0.5.11_1.tbz kbproto-1.0.3.tbz libGL-7.0.3.tbz libICE-1.0.4_1,1.tbz libSM-1.0.3_1,1.tbz libX11-1.1.3_1,1.tbz libXau-1.0.3_2.tbz libXaw-1.0.4_1,1.tbz libXdamage-1.1.1.tbz libXdmcp-1.0.2_1.tbz libXext-1.0.3,1.tbz libXfixes-4.0.3_1.tbz libXfont-1.3.1_3,1.tbz libXmu-1.0.3,1.tbz libXp-1.0.0,1.tbz libXpm-3.5.7.tbz libXt-1.0.5_1.tbz libXv-1.0.3_1,1.tbz libXvMC-1.0.4_1.tbz libXxf86misc-1.0.1.tbz libXxf86vm-1.0.1.tbz libdrm-2.3.1.tbz libfontenc-1.0.4.tbz libiconv-1.11_1.tbz libvolume_id-0.81.0.tbz libxkbfile-1.0.4.tbz libxkbui-1.0.2_1.tbz libxml2-2.6.32.tbz pciids-20080726.tbz pcre-7.7_1.tbz perl-5.8.8_1.tbz pixman-0.10.0_2.tbz pkg-config-0.23_1.tbz policykit-0.9_1.tbz printproto > -1.0.3.tbz python25-2.5.2_2.tbz randrproto-1.2.1.tbz renderproto-0.9.3.tbz videoproto-2.2.2.tbz xextproto-7.0.2.tbz xf86driproto-2.0.3.tbz xf86miscproto-0.9.2.tbz xf86vidmodeproto-2.2.2.tbz xineramaproto-1.1.2.tbz xkeyboard-config-1.3.tbz xorg-server-1.4.2,1.tbz xproto-7.0.10_1.tbz > RUN_DEPENDS=consolekit-0.2.10_2.tbz damageproto-1.1.0_2.tbz dbus-1.2.1.tbz dbus-glib-0.76.tbz dmidecode-2.9.tbz expat-2.0.1.tbz fixesproto-4.0.tbz fontsproto-2.0.2.tbz freetype2-2.3.7.tbz gamin-0.1.9_2.tbz gettext-0.17_1.tbz gio-fam-backend-2.16.5.tbz glib-2.16.5.tbz gnome_subr-1.0.tbz hal-0.5.11_1.tbz kbproto-1.0.3.tbz libGL-7.0.3.tbz libICE-1.0.4_1,1.tbz libSM-1.0.3_1,1.tbz libX11-1.1.3_1,1.tbz libXau-1.0.3_2.tbz libXaw-1.0.4_1,1.tbz libXdamage-1.1.1.tbz libXdmcp-1.0.2_1.tbz libXext-1.0.3,1.tbz libXfixes-4.0.3_1.tbz libXfont-1.3.1_3,1.tbz libXmu-1.0.3,1.tbz libXp-1.0.0,1.tbz libXpm-3.5.7.tbz libXt-1.0.5_1.tbz libXv-1.0.3_1,1.tbz libXvMC-1.0.4_1.tbz libXxf86misc-1.0.1.tbz libXxf86vm-1.0.1.tbz libdrm-2.3.1.tbz libfontenc-1.0.4.tbz libiconv-1.11_1.tbz libvolume_id-0.81.0.tbz libxkbfile-1.0.4.tbz libxkbui-1.0.2_1.tbz libxml2-2.6.32.tbz pciids-20080726.tbz pcre-7.7_1.tbz perl-5.8.8_1.tbz pixman-0.10.0_2.tbz pkg-config-0.23_1.tbz policykit-0.9_1.tbz printproto-1.0.3.tbz python25- > 2.5.2_2.tbz videoproto-2.2.2.tbz xextproto-7.0.2.tbz xf86miscproto-0.9.2.tbz xf86vidmodeproto-2.2.2.tbz xkeyboard-config-1.3.tbz xorg-server-1.4.2,1.tbz xproto-7.0.10_1.tbz > prefixes: LOCALBASE=usr/local X11BASE=usr/local > add_pkg > ================================================================ > ======================================== > => xf86-video-i810-1.7.4.tar.bz2 doesn't seem to exist in /tmp/distfiles/xorg/driver. > => Attempting to fetch from ftp://freebsd.isc.org/pub/FreeBSD/ports/distfiles/xorg/driver/. > xf86-video-i810-1.7.4.tar.bz2 450 kB 2418 kBps > => MD5 Checksum OK for xorg/driver/xf86-video-i810-1.7.4.tar.bz2. > => SHA256 Checksum OK for xorg/driver/xf86-video-i810-1.7.4.tar.bz2. > ================================================================ > ======================================== > add_pkg > ===> Extracting for xf86-video-i810-1.7.4_1 > => MD5 Checksum OK for xorg/driver/xf86-video-i810-1.7.4.tar.bz2. > => SHA256 Checksum OK for xorg/driver/xf86-video-i810-1.7.4.tar.bz2. > ================================================================ > ======================================== > add_pkg > ===> Patching for xf86-video-i810-1.7.4_1 > ================================================================ > ======================================== > add_pkg consolekit-0.2.10_2.tbz damageproto-1.1.0_2.tbz dbus-1.2.1.tbz dbus-glib-0.76.tbz dmidecode-2.9.tbz expat-2.0.1.tbz fixesproto-4.0.tbz fontsproto-2.0.2.tbz freetype2-2.3.7.tbz gamin-0.1.9_2.tbz gettext-0.17_1.tbz gio-fam-backend-2.16.5.tbz glib-2.16.5.tbz glproto-1.4.8.tbz gnome_subr-1.0.tbz hal-0.5.11_1.tbz kbproto-1.0.3.tbz libGL-7.0.3.tbz libICE-1.0.4_1,1.tbz libSM-1.0.3_1,1.tbz libX11-1.1.3_1,1.tbz libXau-1.0.3_2.tbz libXaw-1.0.4_1,1.tbz libXdamage-1.1.1.tbz libXdmcp-1.0.2_1.tbz libXext-1.0.3,1.tbz libXfixes-4.0.3_1.tbz libXfont-1.3.1_3,1.tbz libXmu-1.0.3,1.tbz libXp-1.0.0,1.tbz libXpm-3.5.7.tbz libXt-1.0.5_1.tbz libXv-1.0.3_1,1.tbz libXvMC-1.0.4_1.tbz libXxf86misc-1.0.1.tbz libXxf86vm-1.0.1.tbz libdrm-2.3.1.tbz libfontenc-1.0.4.tbz libiconv-1.11_1.tbz libvolume_id-0.81.0.tbz libxkbfile-1.0.4.tbz libxkbui-1.0.2_1.tbz libxml2-2.6.32.tbz pciids-20080726.tbz pcre-7.7_1.tbz perl-5.8.8_1.tbz pixman-0.10.0_2.tbz pkg-config-0.23_1.tbz policykit-0.9_1.tbz printproto-1.0.3 > .tbz python25-2.5.2_2.tbz randrproto-1.2.1.tbz renderproto-0.9.3.tbz videoproto-2.2.2.tbz xextproto-7.0.2.tbz xf86driproto-2.0.3.tbz xf86miscproto-0.9.2.tbz xf86vidmodeproto-2.2.2.tbz xineramaproto-1.1.2.tbz xkeyboard-config-1.3.tbz xorg-server-1.4.2,1.tbz xproto-7.0.10_1.tbz > adding dependencies > pkg_add consolekit-0.2.10_2.tbz > > ==== > Note that some of the standard modules are provided as separate > ports since they require extra dependencies: > > bsddb databases/py-bsddb > gdbm databases/py-gdbm > sqlite3 databases/py-sqlite3 > tkinter x11-toolkits/py-tkinter > > Install them as needed. > ==== > > Removing stale symlinks from /usr/bin... > Skipping /usr/bin/perl > Skipping /usr/bin/perl5 > Done. > Creating various symlinks in /usr/bin... > Symlinking /usr/local/bin/perl5.8.8 to /usr/bin/perl > Symlinking /usr/local/bin/perl5.8.8 to /usr/bin/perl5 > Done. > Cleaning up /etc/make.conf... Done. > Spamming /etc/make.conf... Done. > Cleaning up /etc/manpath.config... Done. > Spamming /etc/manpath.config... Done. > > =============================================================================== > > Gamin will only provide realtime notification of changes for at most n files, > where n is the minimum value between (kern.maxfiles * 0.7) and > (kern.maxfilesperproc - 200). Beyond that limit, files will be polled. > > If you often open several large folders with Nautilus, you might want to > increase the kern.maxfiles tunable (you do not need to set > kern.maxfilesperproc, since it is computed at boot time from kern.maxfiles). > > For a typical desktop, add the following line to /boot/loader.conf, then > reboot the system: > > kern.maxfiles="25000" > > =============================================================================== > > Added group "messagebus". > Added user "messagebus". > Added group "polkit". > Added user "polkit". > pkg_add damageproto-1.1.0_2.tbz > pkg_add dbus-1.2.1.tbz > skipping dbus-1.2.1, already added > pkg_add dbus-glib-0.76.tbz > skipping dbus-glib-0.76, already added > pkg_add dmidecode-2.9.tbz > pkg_add expat-2.0.1.tbz > skipping expat-2.0.1, already added > pkg_add fixesproto-4.0.tbz > pkg_add fontsproto-2.0.2.tbz > pkg_add freetype2-2.3.7.tbz > pkg_add gamin-0.1.9_2.tbz > skipping gamin-0.1.9_2, already added > pkg_add gettext-0.17_1.tbz > skipping gettext-0.17_1, already added > pkg_add gio-fam-backend-2.16.5.tbz > skipping gio-fam-backend-2.16.5, already added > pkg_add glib-2.16.5.tbz > skipping glib-2.16.5, already added > pkg_add glproto-1.4.8.tbz > pkg_add gnome_subr-1.0.tbz > skipping gnome_subr-1.0, already added > pkg_add hal-0.5.11_1.tbz > Added group "haldaemon". > Added user "haldaemon". > pkg_add kbproto-1.0.3.tbz > skipping kbproto-1.0.3, already added > pkg_add libGL-7.0.3.tbz > pkg_add libICE-1.0.4_1,1.tbz > pkg_add libSM-1.0.3_1,1.tbz > pkg_add libX11-1.1.3_1,1.tbz > skipping libX11-1.1.3_1,1, already added > pkg_add libXau-1.0.3_2.tbz > skipping libXau-1.0.3_2, already added > pkg_add libXaw-1.0.4_1,1.tbz > pkg_add libXdamage-1.1.1.tbz > skipping libXdamage-1.1.1, already added > pkg_add libXdmcp-1.0.2_1.tbz > skipping libXdmcp-1.0.2_1, already added > pkg_add libXext-1.0.3,1.tbz > skipping libXext-1.0.3,1, already added > pkg_add libXfixes-4.0.3_1.tbz > skipping libXfixes-4.0.3_1, already added > pkg_add libXfont-1.3.1_3,1.tbz > pkg_add libXmu-1.0.3,1.tbz > skipping libXmu-1.0.3,1, already added > pkg_add libXp-1.0.0,1.tbz > skipping libXp-1.0.0,1, already added > pkg_add libXpm-3.5.7.tbz > skipping libXpm-3.5.7, already added > pkg_add libXt-1.0.5_1.tbz > skipping libXt-1.0.5_1, already added > pkg_add libXv-1.0.3_1,1.tbz > pkg_add libXvMC-1.0.4_1.tbz > pkg_add libXxf86misc-1.0.1.tbz > pkg_add libXxf86vm-1.0.1.tbz > skipping libXxf86vm-1.0.1, already added > pkg_add libdrm-2.3.1.tbz > skipping libdrm-2.3.1, already added > pkg_add libfontenc-1.0.4.tbz > skipping libfontenc-1.0.4, already added > pkg_add libiconv-1.11_1.tbz > skipping libiconv-1.11_1, already added > pkg_add libvolume_id-0.81.0.tbz > skipping libvolume_id-0.81.0, already added > pkg_add libxkbfile-1.0.4.tbz > pkg_add libxkbui-1.0.2_1.tbz > pkg_add libxml2-2.6.32.tbz > skipping libxml2-2.6.32, already added > pkg_add pciids-20080726.tbz > skipping pciids-20080726, already added > pkg_add pcre-7.7_1.tbz > skipping pcre-7.7_1, already added > pkg_add perl-5.8.8_1.tbz > skipping perl-5.8.8_1, already added > pkg_add pixman-0.10.0_2.tbz > pkg_add pkg-config-0.23_1.tbz > skipping pkg-config-0.23_1, already added > pkg_add policykit-0.9_1.tbz > skipping policykit-0.9_1, already added > pkg_add printproto-1.0.3.tbz > skipping printproto-1.0.3, already added > pkg_add python25-2.5.2_2.tbz > skipping python25-2.5.2_2, already added > pkg_add randrproto-1.2.1.tbz > pkg_add renderproto-0.9.3.tbz > pkg_add videoproto-2.2.2.tbz > skipping videoproto-2.2.2, already added > pkg_add xextproto-7.0.2.tbz > skipping xextproto-7.0.2, already added > pkg_add xf86driproto-2.0.3.tbz > pkg_add xf86miscproto-0.9.2.tbz > skipping xf86miscproto-0.9.2, already added > pkg_add xf86vidmodeproto-2.2.2.tbz > skipping xf86vidmodeproto-2.2.2, already added > pkg_add xineramaproto-1.1.2.tbz > pkg_add xkeyboard-config-1.3.tbz > pkg_add xorg-server-1.4.2,1.tbz > pkg_add xproto-7.0.10_1.tbz > skipping xproto-7.0.10_1, already added > ===> xf86-video-i810-1.7.4_1 depends on file: /usr/local/libdata/pkgconfig/xf86driproto.pc - found > ===> xf86-video-i810-1.7.4_1 depends on file: /usr/local/libdata/pkgconfig/xextproto.pc - found > ===> xf86-video-i810-1.7.4_1 depends on file: /usr/local/libdata/pkgconfig/glproto.pc - found > ===> xf86-video-i810-1.7.4_1 depends on file: /usr/local/libdata/pkgconfig/xineramaproto.pc - found > ===> xf86-video-i810-1.7.4_1 depends on file: /usr/local/libdata/pkgconfig/randrproto.pc - found > ===> xf86-video-i810-1.7.4_1 depends on file: /usr/local/libdata/pkgconfig/fontsproto.pc - found > ===> xf86-video-i810-1.7.4_1 depends on file: /usr/local/libdata/pkgconfig/renderproto.pc - found > ===> xf86-video-i810-1.7.4_1 depends on file: /usr/local/libdata/pkgconfig/xvmc.pc - found > ===> xf86-video-i810-1.7.4_1 depends on file: /usr/local/libdata/pkgconfig/x11.pc - found > ===> xf86-video-i810-1.7.4_1 depends on file: /usr/local/libdata/pkgconfig/xorg-server.pc - found > ===> xf86-video-i810-1.7.4_1 depends on file: /usr/local/libdata/pkgconfig/xproto.pc - found > ===> xf86-video-i810-1.7.4_1 depends on executable: pkg-config - found > ===> xf86-video-i810-1.7.4_1 depends on shared library: GL.1 - found > ===> Configuring for xf86-video-i810-1.7.4_1 > checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel > checking whether build environment is sane... yes > checking for gawk... no > checking for mawk... no > checking for nawk... nawk > checking whether make sets $(MAKE)... yes > checking whether to enable maintainer-specific portions of Makefiles... no > checking build system type... amd64-portbld-freebsd6.3 > checking host system type... amd64-portbld-freebsd6.3 > checking for style of include used by make... GNU > checking for gcc... cc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether cc accepts -g... yes > checking for cc option to accept ISO C89... none needed > checking dependency style of cc... gcc3 > checking for a sed that does not truncate output... /usr/bin/sed > checking for grep that handles long lines and -e... /usr/bin/grep > checking for egrep... /usr/bin/grep -E > checking for ld used by cc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... cc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking whether we are using the GNU C++ compiler... yes > checking whether c++ accepts -g... yes > checking dependency style of c++... gcc3 > checking how to run the C++ preprocessor... c++ -E > checking for g77... no > checking for xlf... no > checking for f77... f77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether f77 accepts -g... yes > checking the maximum length of command line arguments... (cached) 262144 > checking command to parse /usr/bin/nm -B output from cc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking for correct ltmain.sh version... yes > checking if cc supports -fno-rtti -fno-exceptions... no > checking for cc option to produce PIC... -fPIC > checking if cc PIC flag -fPIC works... yes > checking if cc static flag -static works... yes > checking if cc supports -c -o file.o... yes > checking whether the cc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... yes > checking dynamic linker characteristics... freebsd6.3 ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by c++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the c++ linker (/usr/bin/ld) supports shared libraries... yes > checking for c++ option to produce PIC... -fPIC > checking if c++ PIC flag -fPIC works... yes > checking if c++ static flag -static works... yes > checking if c++ supports -c -o file.o... yes > checking whether the c++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... freebsd6.3 ld.so > checking how to hardcode library paths into programs... immediate > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for f77 option to produce PIC... -fPIC > checking if f77 PIC flag -fPIC works... yes > checking if f77 static flag -static works... yes > checking if f77 supports -c -o file.o... yes > checking whether the f77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... freebsd6.3 ld.so > checking how to hardcode library paths into programs... immediate > checking for gcc... (cached) cc > checking whether we are using the GNU C compiler... (cached) yes > checking whether cc accepts -g... (cached) yes > checking for cc option to accept ISO C89... (cached) none needed > checking dependency style of cc... (cached) gcc3 > checking for intel-gen4asm... no > checking if XINERAMA is defined... yes > checking if RANDR is defined... yes > checking if RENDER is defined... yes > checking if XF86DRI is defined... yes > checking if DPMSExtension is defined... yes > checking for pkg-config... /usr/local/bin/pkg-config > checking pkg-config is at least version 0.9.0... yes > checking for XORG... yes > checking for ANSI C header files... (cached) yes > checking for /usr/local/include/xorg/dri.h... yes > checking for /usr/local/include/xorg/sarea.h... yes > checking for /usr/local/include/xorg/dristruct.h... yes > checking whether to include DRI support... yes > checking for DRI... yes > checking for /usr/local/share/X11/sgml/defs.ent... no > checking for linuxdoc... no > checking for ps2pdf... no > checking Whether to build documentation... no > checking Whether to build pdf documentation... no > configure: creating ./config.status > config.status: creating Makefile > config.status: creating src/Makefile > config.status: creating src/xvmc/Makefile > config.status: creating man/Makefile > config.status: creating config.h > config.status: executing depfiles commands > ===> Building for xf86-video-i810-1.7.4_1 > make all-recursive > Making all in src > Making all in xvmc > if /bin/sh ../../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I../.. -D_THREAD_SAFE -I/usr/local/include/xorg -I/usr/local/include/pixman-1 -I/usr/local/include -I/usr/local/include -I/usr/local/include/drm -I/usr/local/include/X11/dri -I../../src -DTRUE=1 -DFALSE=0 -O2 -fno-strict-aliasing -pipe -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -MT libI810XvMC_la-I810XvMC.lo -MD -MP -MF ".deps/libI810XvMC_la-I810XvMC.Tpo" -c -o libI810XvMC_la-I810XvMC.lo `test -f 'I810XvMC.c' || echo './'`I810XvMC.c; then mv -f ".deps/libI810XvMC_la-I810XvMC.Tpo" ".deps/libI810XvMC_la-I810XvMC.Plo"; else rm -f ".deps/libI810XvMC_la-I810XvMC.Tpo"; exit 1; fi > mkdir .libs > cc -DHAVE_CONFIG_H -I. -I. -I../.. -D_THREAD_SAFE -I/usr/local/include/xorg -I/usr/local/include/pixman-1 -I/usr/local/include -I/usr/local/include -I/usr/local/include/drm -I/usr/local/include/X11/dri -I../../src -DTRUE=1 -DFALSE=0 -O2 -fno-strict-aliasing -pipe -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -MT libI810XvMC_la-I810XvMC.lo -MD -MP -MF .deps/libI810XvMC_la-I810XvMC.Tpo -c I810XvMC.c -fPIC -DPIC -o .libs/libI810XvMC_la-I810XvMC.o > /bin/sh ../../libtool --tag=CC --mode=link cc -O2 -fno-strict-aliasing -pipe -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -o libI810XvMC.la -rpath /usr/local/lib -version-number 1:0:0 libI810XvMC_la-I810XvMC.lo > cc -shared .libs/libI810XvMC_la-I810XvMC.o -Wl,-soname -Wl,libI810XvMC.so.1 -o .libs/libI810XvMC.so.1 > (cd .libs && rm -f libI810XvMC.so && ln -s libI810XvMC.so.1 libI810XvMC.so) > (cd .libs && rm -f libI810XvMC.so && ln -s libI810XvMC.so.1 libI810XvMC.so) > creating libI810XvMC.la > (cd .libs && rm -f libI810XvMC.la && ln -s ../libI810XvMC.la libI810XvMC.la) > if /bin/sh ../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I.. -D_THREAD_SAFE -I/usr/local/include/xorg -I/usr/local/include/pixman-1 -I/usr/local/include -I/usr/local/include -I/usr/local/include/drm -I/usr/local/include/X11/dri -DI830_XV -O2 -fno-strict-aliasing -pipe -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -MT i810_accel.lo -MD -MP -MF ".deps/i810_accel.Tpo" -c -o i810_accel.lo i810_accel.c; then mv -f ".deps/i810_accel.Tpo" ".deps/i810_accel.Plo"; else rm -f ".deps/i810_accel.Tpo"; exit 1; fi > mkdir .libs > cc -DHAVE_CONFIG_H -I. -I. -I.. -D_THREAD_SAFE -I/usr/local/include/xorg -I/usr/local/include/pixman-1 -I/usr/local/include -I/usr/local/include -I/usr/local/include/drm -I/usr/local/include/X11/dri -DI830_XV -O2 -fno-strict-aliasing -pipe -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -MT i810_accel.lo -MD -MP -MF .deps/i810_accel.Tpo -c i810_accel.c -fPIC -DPIC -o .libs/i810_accel.o > if /bin/sh ../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I.. -D_THREAD_SAFE -I/usr/local/include/xorg -I/usr/local/include/pixman-1 -I/usr/local/include -I/usr/local/include -I/usr/local/include/drm -I/usr/local/include/X11/dri -DI830_XV -O2 -fno-strict-aliasing -pipe -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -MT i810_cursor.lo -MD -MP -MF ".deps/i810_cursor.Tpo" -c -o i810_cursor.lo i810_cursor.c; then mv -f ".deps/i810_cursor.Tpo" ".deps/i810_cursor.Plo"; else rm -f ".deps/i810_cursor.Tpo"; exit 1; fi > cc -DHAVE_CONFIG_H -I. -I. -I.. -D_THREAD_SAFE -I/usr/local/include/xorg -I/usr/local/include/pixman-1 -I/usr/local/include -I/usr/local/include -I/usr/local/include/drm -I/usr/local/include/X11/dri -DI830_XV -O2 -fno-strict-aliasing -pipe -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -MT i810_cursor.lo -MD -MP -MF .deps/i810_cursor.Tpo -c i810_cursor.c -fPIC -DPIC -o .libs/i810_cursor.o > if /bin/sh ../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I.. -D_THREAD_SAFE -I/usr/local/include/xorg -I/usr/local/include/pixman-1 -I/usr/local/include -I/usr/local/include -I/usr/local/include/drm -I/usr/local/include/X11/dri -DI830_XV -O2 -fno-strict-aliasing -pipe -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -MT i810_dga.lo -MD -MP -MF ".deps/i810_dga.Tpo" -c -o i810_dga.lo i810_dga.c; then mv -f ".deps/i810_dga.Tpo" ".deps/i810_dga.Plo"; else rm -f ".deps/i810_dga.Tpo"; exit 1; fi > cc -DHAVE_CONFIG_H -I. -I. -I.. -D_THREAD_SAFE -I/usr/local/include/xorg -I/usr/local/include/pixman-1 -I/usr/local/include -I/usr/local/include -I/usr/local/include/drm -I/usr/local/include/X11/dri -DI830_XV -O2 -fno-strict-aliasing -pipe -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -MT i810_dga.lo -MD -MP -MF .deps/i810_dga.Tpo -c i810_dga.c -fPIC -DPIC -o .libs/i810_dga.o > if /bin/sh ../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I.. -D_THREAD_SAFE -I/usr/local/include/xorg -I/usr/local/include/pixman-1 -I/usr/local/include -I/usr/local/include -I/usr/local/include/drm -I/usr/local/include/X11/dri -DI830_XV -O2 -fno-strict-aliasing -pipe -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -MT i810_driver.lo -MD -MP -MF ".deps/i810_driver.Tpo" -c -o i810_driver.lo i810_driver.c; then mv -f ".deps/i810_driver.Tpo" ".deps/i810_driver.Plo"; else rm -f ".deps/i810_driver.Tpo"; exit 1; fi > cc -DHAVE_CONFIG_H -I. -I. -I.. -D_THREAD_SAFE -I/usr/local/include/xorg -I/usr/local/include/pixman-1 -I/usr/local/include -I/usr/local/include -I/usr/local/include/drm -I/usr/local/include/X11/dri -DI830_XV -O2 -fno-strict-aliasing -pipe -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -MT i810_driver.lo -MD -MP -MF .deps/i810_driver.Tpo -c i810_driver.c -fPIC -DPIC -o .libs/i810_driver.o > if /bin/sh ../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I.. -D_THREAD_SAFE -I/usr/local/include/xorg -I/usr/local/include/pixman-1 -I/usr/local/include -I/usr/local/include -I/usr/local/include/drm -I/usr/local/include/X11/dri -DI830_XV -O2 -fno-strict-aliasing -pipe -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -MT i810_io.lo -MD -MP -MF ".deps/i810_io.Tpo" -c -o i810_io.lo i810_io.c; then mv -f ".deps/i810_io.Tpo" ".deps/i810_io.Plo"; else rm -f ".deps/i810_io.Tpo"; exit 1; fi > cc -DHAVE_CONFIG_H -I. -I. -I.. -D_THREAD_SAFE -I/usr/local/include/xorg -I/usr/local/include/pixman-1 -I/usr/local/include -I/usr/local/include -I/usr/local/include/drm -I/usr/local/include/X11/dri -DI830_XV -O2 -fno-strict-aliasing -pipe -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -MT i810_io.lo -MD -MP -MF .deps/i810_io.Tpo -c i810_io.c -fPIC -DPIC -o .libs/i810_io.o > if /bin/sh ../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I.. -D_THREAD_SAFE -I/usr/local/include/xorg -I/usr/local/include/pixman-1 -I/usr/local/include -I/usr/local/include -I/usr/local/include/drm -I/usr/local/include/X11/dri -DI830_XV -O2 -fno-strict-aliasing -pipe -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -MT i810_memory.lo -MD -MP -MF ".deps/i810_memory.Tpo" -c -o i810_memory.lo i810_memory.c; then mv -f ".deps/i810_memory.Tpo" ".deps/i810_memory.Plo"; else rm -f ".deps/i810_memory.Tpo"; exit 1; fi > cc -DHAVE_CONFIG_H -I. -I. -I.. -D_THREAD_SAFE -I/usr/local/include/xorg -I/usr/local/include/pixman-1 -I/usr/local/include -I/usr/local/include -I/usr/local/include/drm -I/usr/local/include/X11/dri -DI830_XV -O2 -fno-strict-aliasing -pipe -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -MT i810_memory.lo -MD -MP -MF .deps/i810_memory.Tpo -c i810_memory.c -fPIC -DPIC -o .libs/i810_memory.o > if /bin/sh ../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I.. -D_THREAD_SAFE -I/usr/local/include/xorg -I/usr/local/include/pixman-1 -I/usr/local/include -I/usr/local/include -I/usr/local/include/drm -I/usr/local/include/X11/dri -DI830_XV -O2 -fno-strict-aliasing -pipe -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -MT i810_video.lo -MD -MP -MF ".deps/i810_video.Tpo" -c -o i810_video.lo i810_video.c; then mv -f ".deps/i810_video.Tpo" ".deps/i810_video.Plo"; else rm -f ".deps/i810_video.Tpo"; exit 1; fi > cc -DHAVE_CONFIG_H -I. -I. -I.. -D_THREAD_SAFE -I/usr/local/include/xorg -I/usr/local/include/pixman-1 -I/usr/local/include -I/usr/local/include -I/usr/local/include/drm -I/usr/local/include/X11/dri -DI830_XV -O2 -fno-strict-aliasing -pipe -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -MT i810_video.lo -MD -MP -MF .deps/i810_video.Tpo -c i810_video.c -fPIC -DPIC -o .libs/i810_video.o > if /bin/sh ../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I.. -D_THREAD_SAFE -I/usr/local/include/xorg -I/usr/local/include/pixman-1 -I/usr/local/include -I/usr/local/include -I/usr/local/include/drm -I/usr/local/include/X11/dri -DI830_XV -O2 -fno-strict-aliasing -pipe -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -MT i810_wmark.lo -MD -MP -MF ".deps/i810_wmark.Tpo" -c -o i810_wmark.lo i810_wmark.c; then mv -f ".deps/i810_wmark.Tpo" ".deps/i810_wmark.Plo"; else rm -f ".deps/i810_wmark.Tpo"; exit 1; fi > cc -DHAVE_CONFIG_H -I. -I. -I.. -D_THREAD_SAFE -I/usr/local/include/xorg -I/usr/local/include/pixman-1 -I/usr/local/include -I/usr/local/include -I/usr/local/include/drm -I/usr/local/include/X11/dri -DI830_XV -O2 -fno-strict-aliasing -pipe -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -MT i810_wmark.lo -MD -MP -MF .deps/i810_wmark.Tpo -c i810_wmark.c -fPIC -DPIC -o .libs/i810_wmark.o > if /bin/sh ../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I.. -D_THREAD_SAFE -I/usr/local/include/xorg -I/usr/local/include/pixman-1 -I/usr/local/include -I/usr/local/include -I/usr/local/include/drm -I/usr/local/include/X11/dri -DI830_XV -O2 -fno-strict-aliasing -pipe -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -MT i830_accel.lo -MD -MP -MF ".deps/i830_accel.Tpo" -c -o i830_accel.lo i830_accel.c; then mv -f ".deps/i830_accel.Tpo" ".deps/i830_accel.Plo"; else rm -f ".deps/i830_accel.Tpo"; exit 1; fi > cc -DHAVE_CONFIG_H -I. -I. -I.. -D_THREAD_SAFE -I/usr/local/include/xorg -I/usr/local/include/pixman-1 -I/usr/local/include -I/usr/local/include -I/usr/local/include/drm -I/usr/local/include/X11/dri -DI830_XV -O2 -fno-strict-aliasing -pipe -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -MT i830_accel.lo -MD -MP -MF .deps/i830_accel.Tpo -c i830_accel.c -fPIC -DPIC -o .libs/i830_accel.o > if /bin/sh ../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I.. -D_THREAD_SAFE -I/usr/local/include/xorg -I/usr/local/include/pixman-1 -I/usr/local/include -I/usr/local/include -I/usr/local/include/drm -I/usr/local/include/X11/dri -DI830_XV -O2 -fno-strict-aliasing -pipe -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -MT i830_cursor.lo -MD -MP -MF ".deps/i830_cursor.Tpo" -c -o i830_cursor.lo i830_cursor.c; then mv -f ".deps/i830_cursor.Tpo" ".deps/i830_cursor.Plo"; else rm -f ".deps/i830_cursor.Tpo"; exit 1; fi > cc -DHAVE_CONFIG_H -I. -I. -I.. -D_THREAD_SAFE -I/usr/local/include/xorg -I/usr/local/include/pixman-1 -I/usr/local/include -I/usr/local/include -I/usr/local/include/drm -I/usr/local/include/X11/dri -DI830_XV -O2 -fno-strict-aliasing -pipe -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -MT i830_cursor.lo -MD -MP -MF .deps/i830_cursor.Tpo -c i830_cursor.c -fPIC -DPIC -o .libs/i830_cursor.o > if /bin/sh ../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I.. -D_THREAD_SAFE -I/usr/local/include/xorg -I/usr/local/include/pixman-1 -I/usr/local/include -I/usr/local/include -I/usr/local/include/drm -I/usr/local/include/X11/dri -DI830_XV -O2 -fno-strict-aliasing -pipe -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -MT i830_dga.lo -MD -MP -MF ".deps/i830_dga.Tpo" -c -o i830_dga.lo i830_dga.c; then mv -f ".deps/i830_dga.Tpo" ".deps/i830_dga.Plo"; else rm -f ".deps/i830_dga.Tpo"; exit 1; fi > cc -DHAVE_CONFIG_H -I. -I. -I.. -D_THREAD_SAFE -I/usr/local/include/xorg -I/usr/local/include/pixman-1 -I/usr/local/include -I/usr/local/include -I/usr/local/include/drm -I/usr/local/include/X11/dri -DI830_XV -O2 -fno-strict-aliasing -pipe -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -MT i830_dga.lo -MD -MP -MF .deps/i830_dga.Tpo -c i830_dga.c -fPIC -DPIC -o .libs/i830_dga.o > if /bin/sh ../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I.. -D_THREAD_SAFE -I/usr/local/include/xorg -I/usr/local/include/pixman-1 -I/usr/local/include -I/usr/local/include -I/usr/local/include/drm -I/usr/local/include/X11/dri -DI830_XV -O2 -fno-strict-aliasing -pipe -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -MT i830_driver.lo -MD -MP -MF ".deps/i830_driver.Tpo" -c -o i830_driver.lo i830_driver.c; then mv -f ".deps/i830_driver.Tpo" ".deps/i830_driver.Plo"; else rm -f ".deps/i830_driver.Tpo"; exit 1; fi > cc -DHAVE_CONFIG_H -I. -I. -I.. -D_THREAD_SAFE -I/usr/local/include/xorg -I/usr/local/include/pixman-1 -I/usr/local/include -I/usr/local/include -I/usr/local/include/drm -I/usr/local/include/X11/dri -DI830_XV -O2 -fno-strict-aliasing -pipe -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -MT i830_driver.lo -MD -MP -MF .deps/i830_driver.Tpo -c i830_driver.c -fPIC -DPIC -o .libs/i830_driver.o > i830_driver.c: In function `I830MergedPointerMoved': > i830_driver.c:1069: warning: `miPointerAbsoluteCursor' is deprecated (declared at /usr/local/include/xorg/mipointer.h:124) > i830_driver.c: In function `GetNextDisplayDeviceList': > i830_driver.c:2163: warning: long unsigned int format, different type arg (arg 5) > i830_driver.c: In function `GetAttachableDisplayDeviceList': > i830_driver.c:2220: warning: long unsigned int format, different type arg (arg 4) > i830_driver.c: In function `I965PrintErrorState': > i830_driver.c:6732: warning: long unsigned int format, different type arg (arg 2) > i830_driver.c:6732: warning: long unsigned int format, different type arg (arg 3) > i830_driver.c:6734: warning: long unsigned int format, different type arg (arg 2) > i830_driver.c:6734: warning: long unsigned int format, different type arg (arg 3) > i830_driver.c:6739: warning: long unsigned int format, different type arg (arg 2) > i830_driver.c:6739: warning: long unsigned int format, different type arg (arg 3) > i830_driver.c:6739: warning: long unsigned int format, different type arg (arg 4) > i830_driver.c:6739: warning: long unsigned int format, different type arg (arg 5) > i830_driver.c:6748: warning: long unsigned int format, different type arg (arg 2) > i830_driver.c:6748: warning: long unsigned int format, different type arg (arg 3) > i830_driver.c:6754: warning: long unsigned int format, different type arg (arg 2) > i830_driver.c:6754: warning: long unsigned int format, different type arg (arg 3) > i830_driver.c:6755: warning: long unsigned int format, different type arg (arg 2) > i830_driver.c:6755: warning: long unsigned int format, different type arg (arg 3) > i830_driver.c:7117:2: #error "Wrong drm.h file included. You need to compile and install a recent libdrm." > i830_driver.c: In function `I830DrmMMInit': > i830_driver.c:7127: error: syntax error before "arg" > i830_driver.c:7130: error: `arg' undeclared (first use in this function) > i830_driver.c:7130: error: (Each undeclared identifier is reported only once > i830_driver.c:7130: error: for each function it appears in.) > i830_driver.c:7131: error: `mm_init' undeclared (first use in this function) > i830_driver.c:7136: error: `DRM_IOCTL_MM_INIT' undeclared (first use in this function) > i830_driver.c: In function `I830DrmMMTakedown': > i830_driver.c:7148: error: syntax error before "arg" > i830_driver.c:7151: error: `arg' undeclared (first use in this function) > i830_driver.c:7152: error: `mm_takedown' undeclared (first use in this function) > i830_driver.c:7154: error: `DRM_IOCTL_MM_INIT' undeclared (first use in this function) > i830_driver.c: In function `I830DrmMMLock': > i830_driver.c:7163: error: syntax error before "arg" > i830_driver.c:7166: error: `arg' undeclared (first use in this function) > i830_driver.c:7167: error: `mm_lock' undeclared (first use in this function) > i830_driver.c:7171: error: `DRM_IOCTL_MM_INIT' undeclared (first use in this function) > i830_driver.c: In function `I830DrmMMUnlock': > i830_driver.c:7179: error: syntax error before "arg" > i830_driver.c:7182: error: `arg' undeclared (first use in this function) > i830_driver.c:7183: error: `mm_unlock' undeclared (first use in this function) > i830_driver.c:7187: error: `DRM_IOCTL_MM_INIT' undeclared (first use in this function) > i830_driver.c: In function `I830BIOSScreenInit': > i830_driver.c:7723: error: `DRM_BO_MEM_TT' undeclared (first use in this function) > i830_driver.c: In function `I830BIOSLeaveVT': > i830_driver.c:7904: error: `DRM_BO_MEM_TT' undeclared (first use in this function) > i830_driver.c: In function `I830BIOSEnterVT': > i830_driver.c:8365: error: `DRM_BO_MEM_TT' undeclared (first use in this function) > i830_driver.c: In function `I830BIOSCloseScreen': > i830_driver.c:8586: error: `DRM_BO_MEM_TT' undeclared (first use in this function) > i830_driver.c: In function `I830CheckDevicesTimer': > i830_driver.c:8994: warning: `miPointerCurrentScreen' is deprecated (declared at /usr/local/include/xorg/mipointer.h:142) > i830_driver.c:8996: warning: `miPointerPosition' is deprecated (declared at /usr/local/include/xorg/mipointer.h:130) > i830_driver.c:9025: warning: `miPointerPosition' is deprecated (declared at /usr/local/include/xorg/mipointer.h:130) > i830_driver.c:9036: warning: `miPointerWarpCursor' is deprecated (declared at /usr/local/include/xorg/mipointer.h:95) > i830_driver.c:9054: warning: `miPointerWarpCursor' is deprecated (declared at /usr/local/include/xorg/mipointer.h:95) > *** Error code 1 > > Stop in /work/a/ports/x11-drivers/xf86-video-i810/work/xf86-video-i810-1.7.4/src. > *** Error code 1 > > Stop in /work/a/ports/x11-drivers/xf86-video-i810/work/xf86-video-i810-1.7.4/src. > *** Error code 1 > > Stop in /work/a/ports/x11-drivers/xf86-video-i810/work/xf86-video-i810-1.7.4. > *** Error code 1 > > Stop in /work/a/ports/x11-drivers/xf86-video-i810/work/xf86-video-i810-1.7.4. > *** Error code 1 > > Stop in /a/ports/x11-drivers/xf86-video-i810. > ================================================================ > build of /usr/ports/x11-drivers/xf86-video-i810 ended at Sat Aug 30 18:19:35 UTC 2008 -- Pav Lucistnik Go back to bed America, your government is in control again. Here's American Gladiators. Watch this, shut up. Here's 56 channels of it. Watch these pituitary retards bang their fuckin skulls together and congratulate you on living in the land of freedom. -- Bill Hicks -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: Toto je =?UTF-8?Q?digit=C3=A1ln=C4=9B?= =?ISO-8859-1?Q?_podepsan=E1?= =?UTF-8?Q?_=C4=8D=C3=A1st?= =?ISO-8859-1?Q?_zpr=E1vy?= Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20080830/383cf4f9/attachment.pgp