From owner-freebsd-current@FreeBSD.ORG Mon Apr 9 09:59:57 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5BB4E106564A; Mon, 9 Apr 2012 09:59:57 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id F191A8FC08; Mon, 9 Apr 2012 09:59:56 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1SHBO8-0005z3-1i>; Mon, 09 Apr 2012 11:59:56 +0200 Received: from e178034252.adsl.alicedsl.de ([85.178.34.252] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1SHBO7-0005l4-R8>; Mon, 09 Apr 2012 11:59:56 +0200 Message-ID: <4F82B315.3010408@zedat.fu-berlin.de> Date: Mon, 09 Apr 2012 11:59:49 +0200 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120314 Thunderbird/10.0.3 MIME-Version: 1.0 To: David Wolfskill , Current FreeBSD , mexas@bristol.ac.uk, freebsd-x11@freebsd.org References: <4F8176A0.807@zedat.fu-berlin.de> <20120408152915.GU1420@albert.catwhisker.org> <4F82A3AF.3050207@zedat.fu-berlin.de> <20120409091507.GA55822@mech-cluster241.men.bris.ac.uk> In-Reply-To: <20120409091507.GA55822@mech-cluster241.men.bris.ac.uk> X-Enigmail-Version: 1.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8A4D187F5A5A320FB21A0A80" X-Originating-IP: 85.178.34.252 Cc: Subject: Re: xdm failing to start on FBSD 10.0 r2340030 erratically X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 09:59:57 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8A4D187F5A5A320FB21A0A80 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 04/09/12 11:15, schrieb Anton Shterenlikht: > On Mon, Apr 09, 2012 at 10:54:07AM +0200, O. Hartmann wrote: >> Am 04/08/12 17:29, schrieb David Wolfskill: >>> On Sun, Apr 08, 2012 at 01:29:36PM +0200, O. Hartmann wrote: >>>> I loose hair ... >>>> Since yesterady's "make world" (last make world: the day before >>>> yesterday), getting FreeBSD 10.0-CURRENT/amd64 to r234000 or so, the= X11 >>>> system on all of our FreeBSD 10.0-CUR/amd64 boxes start rejecting th= e >>>> start of xdm display manager. xdm is started from /etc/ttys on ttyv7= =2E >>>> This worked before flawless. >>>> >>>> At this very moment, I do have X11 started via xdm - but this is a >>>> erratic and non-reproduceable process! >>>> >>>> This morning, I update world and kernel to r234030. I recompiled man= y >>>> ports via "portmaster -f xorg xdm", hoping the new kernel/world coul= d >>>> affect the ports, but this isn't. >>>> >>>> Starting Xorg X11 server works fine. xdm fails. The log in >>>> /var/log/xdm.log looks like: >>>> >>>> Build Date: 07 April 2012 04:51:08PM >>>> ... >>>> >>>> >>>> I feel a bit helpless around here since I can not get close to what = is >>>> happening. The erratic behaviour of starting xdm is frightening. >>>> Starting xdm via /etc/ttys doesn't work at all, but sometimes, with = a >>>> bit luck, xdm starts when started from the console. >>>> .... >>> >>> I am not having trouble starting xdm via /etc/ttys; my environment is= >>> known to differ from yours in the following ways: >>> >>> * My ports (save for x11/nvidia-driver and misc/compat8x) are built >>> under stable/8. (I track stable/8, stable/9, and head on a daily >>> basis, and have a common /usr/local among them. I also update >>> any installed ports that have updates available daily.) >>> >>> * I am running FreeBSD/i386, vs. FreeBSD/amd64. >>> >>> * My last 2 updates were r233994 (yesterday) and r234031 (today). >>> >>> * I have a mildly hacked-up startup script for xdm. I doubt this is = an >>> issue -- I've been doing this since 2006/03/05 19:04:03 (according = to >>> the RCS log), though I have modified the script a few times >>> since its inception. But the point here is that I'm not directly >>> invoking the xdm executable from /etc/ttys. >> >> When I start xdm via console, it starts up, but only with a "Xservers"= >> file that contains nothing but comments. If there are the lines >> >> localhost >> 127.0.0.1 >> 192.168.0.128 >> !* >> >> it will will probably start not. Since xdm does not show this behaviou= r >> in a reproducible manner I susepct a bug. >> >>> >>> * I don't know that this is different, but it may well be: my xorg.c= onf >>> includes a stanza: >>> >>> Section "ServerFlags" >>> Option "AutoAddDevices" "False" >>> EndSection >> >> I should go with this and try. But as far as I know, since I have USB >> devices (mouse, keyboard), unpluggin and pluggin them is then, without= >> hal and dbus, not recognized anymore, isn't it? >> >> There was a discussion once going one for this subject. >> >> >> Either way, at this very moment I do not know whether the OS or the X1= 1 >> is faulty and I'd like to report this as a bug. >> >>> >>> because my experiences with hald & dbus were so unpleasant. I don'= t >>> use them; I don't even try to start them. >>> >>> Peace, >>> david >> >> Regards, >> Oliver >> >=20 > I see the same (or similar) behavior on r231158M amd64 > Compaq 6715s laptop. >=20 > I've: >=20 > BUZI> pkg info xdm > xdm-1.1.11: X.Org X display manager > BUZI>=20 pkohartmann@thor: [~] g_info |grep xdm xdm-1.1.11 X.Org X display manager >=20 > Starting xdm from /etc/ttys: >=20 > BUZI> grep bin/xdm /etc/ttys > ttyv8 "/usr/local/bin/xdm -nodaemon" xterm on secure > BUZI> ohartmann@thor: [~] grep bin/xdm /etc/ttys ttyv7 "/usr/local/bin/xdm -nodaemon" xterm on insecure >=20 > causes the screen to flicker a few, maybe 3-5 times, > between the graphical and the text console, and then > I'm back to the text console. Sometimes I also recognize a "flicker" and I see the xdm login requester popping up, but only for a fraction of a second - and then vanishing. >=20 > However, starting xdm manually seems to work fine > every time. Not every time for me. Manipulating Xservers or Xaccess, even opening, changing a char in the commented out portions and saving them, can change the luck of starting or not - as I said, I can not reproduce this behaviour in a predicted manner. Starting xdm manually via console also does not work any time. If you would kill xdm, removing the /var/run/xdm.pid file and try again - I my case, this ending up in the error reported by xdm's /var/log/xdm.log: Build Date: 07 April 2012 04:51:08PM Current version of pixman: 0.24.2 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (=3D=3D) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (=3D=3D) Log file: "/var/log/Xorg.0.log", Time: Sat Apr 7 18:38:24 2012 (=3D=3D) Using config file: "/etc/X11/xorg.conf" xdm info (pid 2055): sourcing /usr/local/share/X11/xdm/Xsetup_0 xdm error (pid 2050): Unknown session exit code 2560 from process 2055 xdm info (pid 2050): Exiting >=20 > The log file is no help: >=20 > BUZI> cat /var/log/xdm.log=20 > xdm error (pid 1464): Can't lock pid file /var/run/xdm.pid, another xdm= is running (pid 939) > BUZI>=20 >=20 >=20 Try to restart xdm via /etc/ttys and then watch the content of your /var/log/xdm.log. By the way: My graphics card is a nVidia GPU GTX560Ti, running with the lates nvidia-driver: ohartmann@thor: [~] pkg_info | grep nvidia nvidia-driver-295.33 NVidia graphics card binary drivers for hardware OpenGL rendering My world and kernel are at: FreeBSD 10.0-CURRENT #5 r234046: Mon Apr 9 01:22:35 CEST 2012 As I reported before, this behaviour was introduced around r234000 and came out of the blue, since I didn't change anything of the configuration nor did I recompile anything else but the OS and kernel that day. A reboot left me floating as described. The only change I saw that day in the source updates was something with init.c. This could be a hint, but I'm a noob in terms of OS techniques, so this is only an observation, not a conclusion. Regards, Oliver --------------enig8A4D187F5A5A320FB21A0A80 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJPgrMbAAoJEOgBcD7A/5N87K0H/25o33cONdMjtlTc+UKwpHd2 QVJVIPcLjKipMsoMIl4XEMKsB2pcjiSJ+AkzvHbzqwyAN9JPs30ZTmbI3cYQPH67 4A9LBCCvzPudMidrIH3ue9kKn97ASU2bGB8encjjM0FHDyqObIWebphW//W85hEJ 5aWU+8XzS+LmpiRP6wy3AnXhPQvGzVCA2DG/un6o3G4L5FnJdtaJoehWfB5+f7Xc TbaSJtAHLwByCZjEi56c+/a2D8DXmRw3FAmGSEIQckPOq4NOezVUg+er1H1uLKlu NuHKNBPDhqXnaVOWMVcMDwiO5itjoe06A67fqF5FwcvbDbNk8N++dMmJSVXQUOo= =X5ab -----END PGP SIGNATURE----- --------------enig8A4D187F5A5A320FB21A0A80--