On Wed, Mar 17, 2010 at 10:49:37PM -0000, Jason Herne wrote:
> Bryce, thanks for testing this :)
> So I guess it is official. This bug (messed up terminal colors with lshw) is separate from 512251 (lshw lastmountpoint data corrupt).
I did a bit more poking at it. It seems the issue is in the fb module.
If I run:
lshw -disable fb
This makes the issue not reproduce.
Narrowing it down further, it seems there's 3 fb's being opened, and the
corruption appears when fb[1] is opened, not fb[0] nor fb[2].
The attached simplified test case also reproduces the problem for me
when I run it as root. If I run it as non-root, it produces the same
stdout but does not trigger the corruption. Because of the test case I
think this demonstrates it's not a bug in lshw but perhaps something
deeper down, maybe in the kernel drm code.
On Wed, Mar 17, 2010 at 10:49:37PM -0000, Jason Herne wrote:
> Bryce, thanks for testing this :)
> So I guess it is official. This bug (messed up terminal colors with lshw) is separate from 512251 (lshw lastmountpoint data corrupt).
I did a bit more poking at it. It seems the issue is in the fb module.
If I run:
lshw -disable fb
This makes the issue not reproduce.
Narrowing it down further, it seems there's 3 fb's being opened, and the
corruption appears when fb[1] is opened, not fb[0] nor fb[2].
The attached simplified test case also reproduces the problem for me
when I run it as root. If I run it as non-root, it produces the same
stdout but does not trigger the corruption. Because of the test case I
think this demonstrates it's not a bug in lshw but perhaps something
deeper down, maybe in the kernel drm code.
Bryce