Weird Xorg radeon mirroring with linux-next-20080515

Weird Xorg radeon mirroring with linux-next-20080515

[Sitsofe Wheeler]

Hi,

When using the radeon xorg driver with linux-next-20080515 there is a
strange mirroring/stretching effect in the bottom eighth of the screen. The
problem seems to have started sometime between linux-next-20080513 and 
linux-next-20080515.

(Do you always have to have done bisection before reporting regressions?)

-- 
Sitsofe

Re: Weird Xorg radeon mirroring with linux-next-20080515

[Chris Snook]

Sitsofe Wheeler wrote:
> Hi,
> 
> When using the radeon xorg driver with linux-next-20080515 there is a
> strange mirroring/stretching effect in the bottom eighth of the screen. The
> problem seems to have started sometime between linux-next-20080513 and 
> linux-next-20080515.
> 
> (Do you always have to have done bisection before reporting regressions?)
> 

NO!

But in this case, given that the reproducer is simple and deterministic, but 
you're not sure which subsystem is the cause, bisection is well-suited to the 
task.  You might be able to shave a few steps off by targeting dri-related 
commits, but that's just a guess.

-- Chris

Re: Weird Xorg radeon mirroring with linux-next-20080515 [paritial bisect]

[Sitsofe Wheeler]

On Thu, 15 May 2008 13:35:08 -0400, Chris Snook wrote:

> Sitsofe Wheeler wrote:
>> Hi,
>> 
>> When using the radeon xorg driver with linux-next-20080515 there is a
>> strange mirroring/stretching effect in the bottom eighth of the screen.
>> The problem seems to have started sometime between linux-next-20080513
>> and linux-next-20080515.
>> 
>> (Do you always have to have done bisection before reporting
>> regressions?)
>> 
>> 
> NO!

Ah, now you tell me : ) It sounded like bisection was what you did if you 
weren't a regular dev and you wanted your bug to get attention. I've 
spent a while trying to bisect this but didn't get all the way. My tests 
make me believe it lies somewhere between commits 
f5fbb15f66bd0a6017e4ca513217e823395502b7 and 
6a305693b777ecd710107387a9753117a54bcbf9 ...

The problem doesn't manifest directly after Xorg is started after boot - 
it seems to happen a few seconds later while services are still being 
started. Switching to a VT and back can make the problem go away.

-- 
Sitsofe | http://sucs.org/~sits/

Re: Weird Xorg radeon mirroring with linux-next-20080515 [paritial bisect]

[Dave Airlie]

>>> Hi,
>>>
>>> When using the radeon xorg driver with linux-next-20080515 there is a
>>> strange mirroring/stretching effect in the bottom eighth of the screen.
>>> The problem seems to have started sometime between linux-next-20080513
>>> and linux-next-20080515.
>>>
>>> (Do you always have to have done bisection before reporting
>>> regressions?)
>>>
>>>
>> NO!
>
> Ah, now you tell me : ) It sounded like bisection was what you did if you
> weren't a regular dev and you wanted your bug to get attention. I've
> spent a while trying to bisect this but didn't get all the way. My tests
> make me believe it lies somewhere between commits
> f5fbb15f66bd0a6017e4ca513217e823395502b7 and
> 6a305693b777ecd710107387a9753117a54bcbf9 ...
>
> The problem doesn't manifest directly after Xorg is started after boot -
> it seems to happen a few seconds later while services are still being
> started. Switching to a VT and back can make the problem go away.
>

wierd got any fglrx or anything installed on you're system.. the
radeon drm hasn't seen any changes that should affect this sorta
thing, do you run radeonfb or vesafb?

Dave.

Re: Weird Xorg radeon mirroring with linux-next-20080515 [paritial bisect]

[Sitsofe Wheeler]

On Fri, 16 May 2008 09:18:26 +1000, Dave Airlie wrote:

> wierd got any fglrx or anything installed on you're system.. the radeon
> drm hasn't seen any changes that should affect this sorta thing, do you
> run radeonfb or vesafb?

fglrx: Nope (I learned years ago that you can't post bugs here if you use 
binary drivers)
radeonfb: Nope.
vesafb: I don't think so (certainly the res looks typical). I have a 
feeling that trying to use vesafb left me with a completely blank console 
on boot.

-- 
Sitsofe | http://sucs.org/~sits/

Re: Weird Xorg stretching (setfont)

[Sitsofe Wheeler]

Dave Airlie wrote:

> wierd got any fglrx or anything installed on you're system.. the
> radeon drm hasn't seen any changes that should affect this sorta
> thing, do you run radeonfb or vesafb?

Just in case you didn't see my reply I'm not an fglrx user and I don't run
radeonfb or vesafb.

After testing far too many kernels it turns out that this is not a
conventional regression. During startup openSUSE runs the following
command:

/bin/setfont -C /dev/tty1 lat9w-16.psfu -m trivial

in /etc/init.d/kbd

Now on the openSUSE provided 2.6.22.17-0.1-default #1 SMP kernel if X has
started and your run that command (e.g.
chvt 7; sleep 5s && /bin/setfont -C /dev/tty1 lat9w-16.psfu -m trivial
) the command will fail with error output similar to the following:
setfont: putfont: 256,8x16: failed: -1
putfont: KDFONTOP: Invalid Argument

If you are using a stock kernel (e.g. 2.6.24/2.6.25 etc) the command will
not fail and will instead corrupt X causing the lower part of the screen to
be drawn using the same line (creating a stretch/mirror effect).

There seems to be a bit of mention of this over in
https://bugzilla.novell.com/show_bug.cgi?id=335267 but that talks about it
failing (which I consider to be better behaviour than corrupting X).

The whole thing is racy on boot (e.g. if setfont happens before X is shown
then there is no corruption) fooling me into thinking it was a regression.

-- 
Sitsofe

Re: Weird Xorg stretching (setfont)

[Bodo Eggert]

Sitsofe Wheeler <sitsofe@yahoo.com> wrote:
> Dave Airlie wrote:

>> wierd got any fglrx or anything installed on you're system.. the
>> radeon drm hasn't seen any changes that should affect this sorta
>> thing, do you run radeonfb or vesafb?
> 
> Just in case you didn't see my reply I'm not an fglrx user and I don't run
> radeonfb or vesafb.
> 
> After testing far too many kernels it turns out that this is not a
> conventional regression. During startup openSUSE runs the following
> command:
> 
> /bin/setfont -C /dev/tty1 lat9w-16.psfu -m trivial
> 
> in /etc/init.d/kbd
> 
> Now on the openSUSE provided 2.6.22.17-0.1-default #1 SMP kernel if X has
> started and your run that command (e.g.
> chvt 7; sleep 5s && /bin/setfont -C /dev/tty1 lat9w-16.psfu -m trivial
> ) the command will fail with error output similar to the following:
> setfont: putfont: 256,8x16: failed: -1
> putfont: KDFONTOP: Invalid Argument
> 
> If you are using a stock kernel (e.g. 2.6.24/2.6.25 etc) the command will
> not fail and will instead corrupt X causing the lower part of the screen to
> be drawn using the same line (creating a stretch/mirror effect).

I see a similar effect on my "GeForce2 MX/MX 400" using the "nv" driver.
The difference is: I see both the screen corruption and (from ssh):
be10:/etc/init.d # ./kbd start
Loading keymap qwertz/de-latin1-nodeadkeys.map.gz                    done
Keyboard: Typematic Rate set to 30.0 cps (delay = 250 ms)            done
Loading compose table latin1.add                                     done
Stop Unicode mode
kbd_mode not called for /dev/pts/1                                   done
Loading console font lat9w-16.psfu  -m trivial (K
putfont: PIO_FONT: Invalid argument                                  failed
be10:/etc/init.d #