Hi Owain,
>
>From a look at the kernel code and a look at your X log it looks like
>this spamming is happening only while you are vt switched away from X.
>
correct.  another symptom is that xorg _does_not_ refresh the screen.
this is why I inadvertently duplicated dmesg and Xorg.0.log.

>(you use startx, right? else that shouldn't appear on the console, it's
>an X message)

correct again.
>
<snip>
>For some stupid reason the x driver is still trying to submit commands
>to the gpu while vt switched (this is verboten, and returns with EBUSY).
>What are you running in X at the time? I can't reproduce this issue to
>try and fix it.
>
I have reproduced the same error with an i386 x60s Thinkpad. I source startx,
and start firefox-10.0. the x60s was tested with the Feb. 7th snap.

<snip>
>> Here is Xorg.0.log.old:
<snip>
>> [1595812.018] (II) intel(0): Printing probed modes for output LVDS
>> [1595812.018] (II) intel(0): Modeline "1440x900"x60.0  102.00  1440 1488 
>> 1520 1836  900 903 909 926 -hsync -vsync (55.6 kHz)
>> [1595812.018] (II) intel(0): Modeline "1440x900"x50.0   85.00  1440 1488 
>> 1520 1836  900 903 909 926 -hsync -vsync (46.3 kHz)
<snip>
>> [1595812.870] (II) intel(0): Allocated new frame buffer 1472x900 stride 
>> 6144, tiled
<snip>
>> [1595822.857] (EE) intel(0): Failed to submit batch buffer, expect rendering 
>> corruption or even a frozen display: Device busy.
<snip>

Is the failure to submit the batch buffer because the frame buffer is
1472x900 when it should be 1440x900?

Thanks,
Dave.

Reply via email to