Re: xdm failing to start on FBSD 10.0 r2340030 erratically
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--
討論串 (同標題文章)
完整討論串 (本文為第 5 之 7 篇)：