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 the >>>> start of xdm display manager. xdm is started from /etc/ttys on ttyv7. >>>> 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 many >>>> ports via "portmaster -f xorg xdm", hoping the new kernel/world could >>>> 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 behaviour >> in a reproducible manner I susepct a bug. >> >>> >>> * I don't know that this is different, but it may well be: my xorg.conf >>> 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 X11 >> 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 >> > > I see the same (or similar) behavior on r231158M amd64 > Compaq 6715s laptop. > > I've: > > BUZI> pkg info xdm > xdm-1.1.11: X.Org X display manager > BUZI> pkohartmann_at_thor: [~] g_info |grep xdm xdm-1.1.11 X.Org X display manager > > Starting xdm from /etc/ttys: > > BUZI> grep bin/xdm /etc/ttys > ttyv8 "/usr/local/bin/xdm -nodaemon" xterm on secure > BUZI> ohartmann_at_thor: [~] grep bin/xdm /etc/ttys ttyv7 "/usr/local/bin/xdm -nodaemon" xterm on insecure > > 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. > > 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, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Sat Apr 7 18:38:24 2012 (==) 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 > > The log file is no help: > > BUZI> cat /var/log/xdm.log > xdm error (pid 1464): Can't lock pid file /var/run/xdm.pid, another xdm is running (pid 939) > BUZI> > > 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_at_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
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:25 UTC