Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 27 Aug 2011 21:36:14 +0300
From:      Andrey Kosachenko <andrey.kosachenko@gmail.com>
To:        freebsd-x11@freebsd.org
Subject:   Re: xorg-dev + intel driver + KMS
Message-ID:  <4E59391E.10908@gmail.com>
In-Reply-To: <4E54C04D.5050000@gmail.com>
References:  <CAK8LArPHWe6-O7BR74EsDpi94Om%2B3rwfGcGAiUOMA435png-vw@mail.gmail.com> <20110823085937.GC17489@deviant.kiev.zoral.com.ua> <4E543828.2040703@gmail.com> <20110824081303.GG17489@deviant.kiev.zoral.com.ua> <4E54C04D.5050000@gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi, Konstantin,

On 24.08.2011 12:11, Andrey Kosachenko wrote:
> On 24.08.2011 11:13, Kostik Belousov wrote:
>> Again, the backtrace is not useful. To make it useful, debugging symbols
>> must be compiled into the dso loaded into the process. I highly suspect
>> that the real backtrace ends at the frame 10.
>>
>> Try to start with compiling rtld/libc/libthr with debugging symbols.
>> It is enough to do
>> cd $SRC/libexec/rtld-elf
>> make obj&& make all install DEBUG_FLAGS=-g
>> cd $SRC/lib/libc
>> make obj&& make all install DEBUG_FLAGS=-g
>> cd $SRC/lib/libthr
>> make obj&& make all install DEBUG_FLAGS=-g
>> uxa faulting might be an indicator of the bug in the KBI of the new
>> Intel driver, but may be a genuine Xorg/ddx driver bug.
>
> ok, thanks for instructions: will do and let you know as soon as I'll be
> able to reproduce it (again, with xorg-dev it happens more seldom,
> sporadically and I've no exact STR for it)

sorry for delay,
I followed your instructions and tried to rebuild DSOs with debugging 
symbols. Unfortunately trapped into very unpleasant situation. An 
attempt to recompile libc failed with error:

--
beastie# make obj
beastie# make all install DEBUG_FLAGS=-g
cat /usr/src/lib/libc/amd64/Symbol.map /usr/src/lib/libc/db/Symbol.map 
/usr/src/lib/libc/compat-43/Symbol.map 
/usr/src/lib/libc/gdtoa/Symbol.map /usr/src/lib/libc/gen/Symbol.map 
/usr/src/lib/libc/gmon/Symbol.map /usr/src/lib/libc/inet/Symbol.map 
/usr/src/lib/libc/locale/Symbol.map /usr/src/lib/libc/nameser/Symbol.map 
/usr/src/lib/libc/net/Symbol.map /usr/src/lib/libc/nls/Symbol.map 
/usr/src/lib/libc/posix1e/Symbol.map /usr/src/lib/libc/regex/Symbol.map 
/usr/src/lib/libc/resolv/Symbol.map /usr/src/lib/libc/stdio/Symbol.map 
/usr/src/lib/libc/stdlib/Symbol.map /usr/src/lib/libc/stdtime/Symbol.map 
/usr/src/lib/libc/string/Symbol.map /usr/src/lib/libc/sys/Symbol.map 
/usr/src/lib/libc/rpc/Symbol.map /usr/src/lib/libc/uuid/Symbol.map 
/usr/src/lib/libc/xdr/Symbol.map /usr/src/lib/libc/yp/Symbol.map | cpp - 
-  | awk -v vfile=/usr/src/lib/libc/Versions.def -f 
/usr/share/mk/version_gen.awk > Version.map
building shared library libc.so.7
install -C -o root -g wheel -m 444   libc.a /usr/lib
install  -o root -g wheel -m 444   -fschg -S  libc.so.7 /lib
ln -fs /lib/libc.so.7  /usr/lib/libc.so
/libexec/ld-elf.so.1: /lib/libc.so.7: Undefined symbol "_nsyyin"
*** Error code 1

Stop in /usr/src/lib/libc.
--

Furthermore it corrupted my system and none of userland binaries could 
be launched (failed with the same error as above, i.e. 
"/libexec/ld-elf.so.1: /lib/libc.so.7: Undefined symbol "_nsyyin""). So 
I did 3 things:

1) took a look into /rescue but didn't manage to find somewhat that 
would help me to recover;

2) given that it was my working machine I decided not to experiment too 
much, booted from usb stick, imported zfs pool with legacy 
system/sources, rebuilt and reinstalled world+kernel;

3) one more time answered the rhetorical  question why disclaimer 
regarding usage of -CURRENT exists.


After that I did snapshots for "/" and "/usr" tried again: nothing 
changed. Issue persisted. I'm not sure what is going on. Checked 
build(7) then lists. Though found this thread 
http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026611.html 
which looks pretty relevant, however I was able to rebuild the whole 
world w/o any issues (using the same sources).

So my plan is to csup sources and rebuild everything once again then 
wait for new cores for investigation.

--
WBR,
Andrey Kosachenko



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E59391E.10908>