[4.17-rc4+ regression] X server does not start anymore with segmentation fault in `r600_dri.so`

[Paul Menzel]

Dear Michel,


Am 15.05.2018 um 10:41 schrieb Michel Dänzer:
> On 2018-05-15 08:38 AM, Paul Menzel wrote:
>> On 2018-05-14 10:44, Michel Dänzer wrote:
>>> On 2018-05-13 11:01 AM, Paul Menzel wrote:

>>>> There is a regression introduced by a commit after Linux 4.17-rc4
>>>> causing the X.Org X server start to fail with the Radeon module loaded
>>>> on Debian Sid/unstable. The same Linux kernel build works with the
>>>> modesetting driver on the same system (no module *radeon* loaded) and
>>>> with i915 and the modesetting driver on a different system with Debian
>>>> 9.4 (Stretch/stable).
>>>>
>>>>> [    16.263] xf86EnableIOPorts: failed to set IOPL for I/O (Operation
>>>>> not permitted)
>>>>> […]
>>>>> [    16.765] (EE) 0: /usr/lib/xorg/Xorg (xorg_backtrace+0x50)
>>>>> [0x5b4e60]
>>>>> [    16.766] (EE) 1: /usr/lib/xorg/Xorg (0x40d000+0x1abd92) [0x5b8d92]
>>>>> [    16.766] (EE) 2: linux-gate.so.1 (__kernel_rt_sigreturn+0x0)
>>>>> [0xb7f2ad5c]
>>>>> [    16.766] (EE) 3: /lib/i386-linux-gnu/libc.so.6
>>>>> (0xb78a0000+0x140099) [0xb79e0099]
>>>>> [    16.766] (EE) 4: /usr/lib/i386-linux-gnu/dri/r600_dri.so
>>>>> (0xb62f9000+0x6698fd) [0xb69628fd]
>>>
>>> Crashes in r600_dri.so => most likely a Mesa bug. Can you get a gdb
>>> backtrace of the crash?
>>
>> ```
>> #0  0xb7f1bd45 in __kernel_vsyscall ()
>> #1  0xb78bd5b2 in __libc_signal_restore_set (set=0xbf93883c) at
>> ../sysdeps/unix/sysv/linux/nptl-signals.h:80
>> #2  __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:48
>> #3  0xb78be9d1 in __GI_abort () at abort.c:79
>> #4  0x0061bf45 in OsAbort () at ../../../../os/utils.c:1361
>> #5  0x004ec96c in ddxGiveUp (error=EXIT_ERR_ABORT) at
>> ../../../../../../hw/xfree86/common/xf86Init.c:1011
>> #6  0x004eca05 in AbortDDX (error=EXIT_ERR_ABORT) at
>> ../../../../../../hw/xfree86/common/xf86Init.c:1055
>> #7  0x00621c6f in AbortServer () at ../../../../os/log.c:874
>> #8  0x00622654 in FatalError (f=0x650110 "Caught signal %d (%s). Server
>> aborting\n") at ../../../../os/log.c:1015
>> #9  0x00618def in OsSigHandler (signo=11, sip=0xbf938b4c,
>> unused=0xbf938bcc) at ../../../../os/osinit.c:154
>> #10 <signal handler called>
>> #11 __memcpy_ssse3 () at ../sysdeps/i386/i686/multiarch/memcpy-ssse3.S:144
>> #12 0xb69518fd in memcpy (__len=48, __src=<optimized out>,
>> __dest=<optimized out>) at
>> /usr/include/i386-linux-gnu/bits/string_fortified.h:34
>> #13 r600_create_vertex_fetch_shader (ctx=0xf08e40, count=2,
>> elements=0xbf93933c) at
>> ../../../../../src/gallium/drivers/r600/r600_asm.c:2701
> 
> Does
> https://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=76ef6b28ea4f81c3d511866a9b31392caa833126
> help?

Yes, it does help. The problem is unreproducible with 
v4.17-rc5-20-g21b9f1c7e319.

> BTW, if the CPU in this system is 64-bit capable, I'd recommend running
> a 64-bit X server.
I still have a Lenovo X60 which is 32-bit. As the SSD drive is easily 
portable, I ues the system installation for the Lenovo X60 and the 
ASRock E350M1.


Kind regards,

Paul