sudo lshw causes console to turn blue on dell inspiron 1011 and fujitsu livebook T4410

VT switching to vt2 and back to vt1 clears it. Guessing this is a kernel framebuffer issue.

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

I've reproduced this same issue on a fujitsu laptop, which has a different graphics chipset (gm45). If it helps I can post the info from this system.

Hi Bryce,

Please be sure to confirm this issue exists with the latest development release of Ubuntu. ISO CD images are available from http://cdimage.ubuntu.com/releases/lucid . If the issue remains, please run the following command from a Terminal (Applications->Accessories->Terminal). It will automatically gather and attach updated debug information to this report.

apport-collect -p linux 527369

Also, if you could test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Thanks in advance.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

I can confirm it on an updated Lucid. using Asus Eee PC 1005HA

Confirmed on latest Lucid. Compaq Presario C550em. Intel 945 chipset.

I am not able to reproduce this on either of my two computers... however... in my attempts I noticed that in all cases (on both systems) where the lastmountpoint attribute was displayed it seems to be corrupt.

Could this corrupt sequence of characters possibly be interpreted as control characters thereby changing the color?

Relevant output
                   configuration: created=2010-03-14 19:12:40 filesystem=ext4 lastmountpoint=/�fGM����(�*������U�E� �=�/���U��!�`V�`V������U���U�� modified=2010-03-14 19:30:57$

NOTE: I am running Lucid Alpha-3 with all updates as of 3/15/2010.

Ahha :)

https://bugs.launchpad.net/ubuntu/+source/lshw/+bug/512251

This bug seems to confirm my suspicion. It even talks about the terminal changing colors.

512251 is fixed in the upstream development release.

Can someone who can recreate the terminal color problem please download the latest lshw and see if you can recreate the problem?

If you have subversion installed you can obtain the code via this command:
svn co http://ezix.org/source/packages/lshw/development lshw

Then simply make the software like so:
cd lshw
make

To test:
sudo ./lshw

On Wed, Mar 17, 2010 at 10:14:29PM -0000, Jason Herne wrote:
> 512251 is fixed in the upstream development release.
>
> Can someone who can recreate the terminal color problem please download
> the latest lshw and see if you can recreate the problem?
>
> If you have subversion installed you can obtain the code via this command:
> svn co http://ezix.org/source/packages/lshw/development lshw
>
> Then simply make the software like so:
> cd lshw
> make
>
> To test:
> sudo ./lshw

Thanks for the cookie cutter directions. I repro'd the bug with the
stock lshw on my test hw, then downloaded the lshw using the svn string
you provided, built the code, and then ran:

 sudo ./src/lshw

Exactly the same corruption occurred on the screen.

But I can confirm that with the svn version the lastmountpoint parameter
does not show non-ascii characters, as the stock lucid version does.

Bryce

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).

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

$ gcc fb.c -o fb && sudo ./fb
open: 1 29 7425
mknod /var/run/fb-2925
open(/var/run/fb-2925, O_RDONLY)
unlink(/var/run/fb-2925)
close: 1 29 7425

This produces the screen corruption for me. vt switching clears it.

Before anyone asks, yes I updated to latest stuff today with -16 kernel and tested.

/proc/fb shows:
 0 inteldrmfb
 1 VGA16 VGA

I'm gathering that this is some sort of incompatibility when opening VGA16 while inteldrmfb is in use...

On Tue, Mar 23, 2010 at 11:15:26PM -0000, Robert Hooker wrote:
> Ok, after finding one of the dupes that was having this issue on the
> same machine I'm using where I couldn't reproduce it I looked into it a
> bit more. It looks like having vga16fb loaded (which I had blacklisted)
> is what's causing the problem and I can reproduce it on a livecd.

From IRC discussion...

vga16fb was added to the kernel in november or december for plymouth.
But it doesn't interact well with KMS, so results in errors like this.

Could make lshw ignore vga16fb when drmfb is present... or could force
vga16fb fail to load when there is a real framebuffer...

Basically, there's no good solution to this bug for Lucid. There's no reasonable way to keep vga16fb from loading when a suitable hw framebuffer is available. There's a hacked solution, but due to the lack of locking that I can find in register_framebuffer (maybe there's locking above, but I can't be sure) I'm afraid to add code that would prevent vga16fb from loading if another framebuffer already exists. Adding locking would help, but that's too large of an addition to Lucid at this point.

In M, we hope to be done with vga16fb and just use efifb, which would hand off to nouveau/intel/radeon properly (unlike vga16fb). So this is really just an issue with Lucid.

IMHO, for Lucid we should try to teach lshw to be careful with framebuffers. Why does it need to open the framebuffer at all?

After browsing the lshw source, it does a lot of detection by opening and querying the framebuffer. I don't think we can teach lshw about vga16fb easily, and it would likely be very hackish.

I've made a hackish patch for Lucid that would prevent vga16fb from registering after another framebuffer and sent it off to the kernel-team mailing list for discussion.

This bug was fixed in the package linux - 2.6.32-18.27

---------------
linux (2.6.32-18.27) lucid; urgency=low

  [ Chase Douglas ]

  * SAUCE: Don't register vga16fb framebuffer if other framebuffers are
    present
    - LP: #527369

  [ Loïc Minier ]

  * [Config] armel/versatile: Set CRAMFS=m
    - LP: #524893
  * [Config] armel: Reset default command-line
    - LP: #524893

  [ Stefan Bader ]

  * build/modules: Update d-i to reflect recent config changes
    - LP: #546929

  [ Upstream Kernel Changes ]

  * (pre-stable) drm/nouveau: report unknown connector state if lid closed
    - LP: #523072
  * (pre-stable) Staging: rt2870: Add USB ID for Buffalo Airstation
    WLI-UC-GN
    - LP: #441990
  * (pre-stable) iwlwifi: fix nfreed--
    - LP: #545585
  * (pre-stable) pata_via: Add VIA VX900 support
    - LP: #548675
 -- Stefan Bader <email address hidden> Fri, 26 Mar 2010 18:39:42 +0100