x11 hangs unkillable on 10.0-BETA1

[Oliver Pinter]

On 10/27/13, Kevin Oberman <rkoberman at gmail.com> wrote:
> On Sun, Oct 27, 2013 at 2:06 AM, Wolfgang Zenker
> <wolfgang at lyxys.ka.sub.org>wrote:
>
>> * Kevin Oberman <rkoberman at gmail.com> [131027 06:10]:
>> > On Sat, Oct 26, 2013 at 9:31 PM, illoai at gmail.com <illoai at gmail.com>
>> wrote:
>> >> On 26 October 2013 21:18, Wolfgang Zenker <wolfgang at lyxys.ka.sub.org>
>> >> wrote:
>> >>> Testing 10.0-BETA1 on an old IBM T42p Laptop, after a while Xorg
>> >>> starts
>> >>> to use 100% CPU, stops to update the screen and does not accept any
>> >>> input anymore. I can still work from remote via ssh; top shows Xorg
>> using
>> >>> up 100% CPU most of the time. Trying to kill or even kill -9 the Xorg
>> >>> process does not result in an error message but fails to terminate
>> >>> the
>> >>> process.
>>
>> >> [..]
>> >> Summary:
>> >> Xorg on FreeBSD is a crap shoot based on your card.  IIRC a T42
>> >> is one of those terrible i915 or something video cards.  Ugh.
>>
>> This is a pre-Lenovo T42p and X identifies the graphics card as an
>> [AMD/ATI] RV350/M10 GL [Mobility FireGL T2] rev 128
>>
>> > I am surprised by this. I have a T42 with the Intel 3000 graphics card
>> and
>> > it has worked quite well for me. I use mplayer, vlc, and (primarily)
>> > xine
>> > on it.  I use the default video output device for all. I thought the
>> > default was Xv, but I could well be wrong. It's been working for me on
>> > stable for well over a year. I started using it when kib made patches
>> > available, but I have been running the committed version.
>>
>> > Just to confirm, you have WITH_NEW_XORG=YES and WITH_KMS=YES in
>> > /etc/make.conf and have built all X ports and the kernel with these
>> options.
>>
>> So far I have not tried WITH_NEW_XORG=YES, beause AFAIR that would not
>> allow me to switch back to console after starting X11.
>>
>
> No, WITH_NEW_XORG has nothing to do with this. It's KMS on Intel graphics
> that prevents getting a vty after X is started. Well. actually is is th
> display of vty that fails. You can still type commands and they are
> executed. You can, for example, restart X (startx). NEW_XORG is mostly the
> new MESA code that no linger supports older version of may cards. What
> results would be on your RV350, I can't say.  Once you go to 10, you can
> build WITH_GALIUM and, hopefully shortly after that newcons will be ready
> and the problem of returning to console mode will be over.  That said, I am
> not sure whether KMS support will make any difference on your system.
>
> I do recommend starting without an xorg.conf file. It almost always works
> at a basic level. Then, if that works, with or without WITH_NEW_XORG=YES,
> you can add "extras" like optional fonts, or additional modules. Mine is
> pretty short.
>
>
>> The last line in the Xorg.0.log of the failed session was
>> [mi] EQ overflowing. The server is probably stuck in an infinite loop.
>> so I might give WITH_NEW_XORG=YES a try.
>>
>> Wolfgang
>>
>> _______________________________________________
>> freebsd-stable at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
>>
>
>
>
> --
> R. Kevin Oberman, Network Engineer
> E-mail: rkoberman at gmail.com
> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
>

In my case, the system locked up. Possible double or triple fault. The
system must be rebooted.
I use an Intel Haswell core-i5-4670 CPU with VESA driver without DRI.

The last lines from Xorg shutdown are:

(==) VESA(0): Write-combining range (0x0, 0x1000) was already clear
(==) VESA(0): Write-combining range (0x0, 0x1000) was already clear
(==) VESA(0): Write-combinin

And at this point I loose the control over the machine. No serial port
access, no input, nothing. No panic, no DDB.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xorg-crash-201310272145
Type: application/octet-stream
Size: 30174 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20131027/708dcfd4/attachment.obj>