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@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@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@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
signature.asc
Description: OpenPGP digital signature
