Bug 1665766

Hi,

Thank you for your bug report, linux/drivers/gpu/drm/gma500/psb_intel_lvds.c has this comment:

        /*
         * Blacklist machines with BIOSes that list an LVDS panel without
         * actually having one.
         */

Which currently is a place-holder for actually blacklisting.

Can you run (as a regular user!) :

grep -r . /sys/class/dmi/id 2> /dev/null

And then copy and paste the output here? Then I will write a patch and provide a kernel to test (when I can find some time for this).

Regards,

Hans

Hi, Hans.
Thanks for the quick reply. Here's the requested output:

/sys/class/dmi/id/bios_date:09/17/2012
/sys/class/dmi/id/uevent:MODALIAS=dmi:bvnPhoenixTechnologiesLtd.:bvrCDV_T30X64:bd09/17/2012:svnIntelCorporation:pnMilsteadPlatform:pvr2.2:rvnIntelCorporation:rnGraniteWell:rvrFABA:cvnIntelCorporation:ct9:cvr1.0:
/sys/class/dmi/id/product_name:Milstead Platform
/sys/class/dmi/id/chassis_vendor:Intel Corporation
/sys/class/dmi/id/chassis_asset_tag:Asset Tag
/sys/class/dmi/id/sys_vendor:Intel Corporation
/sys/class/dmi/id/power/runtime_active_time:0
/sys/class/dmi/id/power/runtime_status:unsupported
/sys/class/dmi/id/power/runtime_suspended_time:0
/sys/class/dmi/id/power/control:auto
/sys/class/dmi/id/bios_version:CDV_T30 X64
/sys/class/dmi/id/product_version:2.2
/sys/class/dmi/id/board_vendor:Intel Corporation
/sys/class/dmi/id/chassis_version:1.0
/sys/class/dmi/id/product_sku:System SKUNumber
/sys/class/dmi/id/chassis_type:9
/sys/class/dmi/id/product_family:Milstead System
/sys/class/dmi/id/bios_vendor:Phoenix Technologies Ltd.
/sys/class/dmi/id/board_asset_tag:Base Board Asset Tag
/sys/class/dmi/id/board_version:FABA
/sys/class/dmi/id/modalias:dmi:bvnPhoenixTechnologiesLtd.:bvrCDV_T30X64:bd09/17/2012:svnIntelCorporation:pnMilsteadPlatform:pvr2.2:rvnIntelCorporation:rnGraniteWell:rvrFABA:cvnIntelCorporation:ct9:cvr1.0:
/sys/class/dmi/id/board_name:Granite Well

Despite chassis type being declared as "9" (Laptop), it's a small NAS box: http://www.thecus.com/product.php?PROD_ID=76 .

I've written a patch adding a lvds-blacklist and an entry for your Thecus N2800 NAS. I've done a kernel scratch-build with the patch added, you can find this scratch-build here:

https://koji.fedoraproject.org/koji/taskinfo?taskID=32193596

Here are some generic instructions for installing and testing kernels directly from koji:
https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt

Please give this kernel a test run, without the 'video=LVDS-1:d' on the kernel command line and let me know if it fixes things.

If you can confirm the patch fixes this, then I will submit the patch upstream.

(In reply to Hans de Goede from comment #3)
> I've written a patch adding a lvds-blacklist and an entry for your Thecus
> N2800 NAS.

Thanks, but it's actually a N5550, not N2800. I'm not sure why you got
the model number.

> I've done a kernel scratch-build with the patch added, you can
> find this scratch-build here:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=32193596
> 
> Here are some generic instructions for installing and testing kernels
> directly from koji:
> https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt
> 
> Please give this kernel a test run, without the 'video=LVDS-1:d' on the
> kernel command line and let me know if it fixes things.

I'll try to find some time to do it tonight, but most likely I'll only
be able to do it next week, after I'm back from DevConf.

> If you can confirm the patch fixes this, then I will submit the patch
> upstream.

Great, thanks!

(In reply to Dominik 'Rathann' Mierzejewski from comment #4)
> (In reply to Hans de Goede from comment #3)
> > I've written a patch adding a lvds-blacklist and an entry for your Thecus
> > N2800 NAS.
> 
> Thanks, but it's actually a N5550, not N2800. I'm not sure why you got
> the model number.

Ah, I found it by looking for the CDV_T30 X64 BIOS version, so it seems
that Thecus has both an N2800 and a N5550, and both seem to be based
on more or less the same motherboard, according to:

https://wiki.debian.org/InstallingDebianOn/Thecus/N2800

The N2800 had a BIOS version of "CDV_T22 X64" followed by "CDV_T24 X64"
at point in time, so doing the DMI match on "CDV_T30 X64" is no good
since then I will only catch systems with a single BIOS version.

So instead I will do a partial match for "CDV_T"

I will prepare a new scratch-build with the updated patch.

> I'll try to find some time to do it tonight, but most likely I'll only
> be able to do it next week, after I'm back from DevConf.

Ok, enjoy DevConf, if you don't get around to it (or the new scratch build
is not ready yet) can you please download and save the rpms from the new
scratch-build before they get cleaned up by koji?

Ok the new scratch build with updated patch is building here now:
https://koji.fedoraproject.org/koji/taskinfo?taskID=32217289

Note this takes a few hours to finish.

Hi,

Any chance you can make some time to test this? I would like to submit the patch for this upstream.

Regards,

Hans

Thanks for the reminder, Hans. I'm sorry about the delay, a lot happened in the meantime and I didn't have time. Could you do a new scratch build? I'll grab it and test by the end of this week.

A new scratch build is now building here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=32962084

(In reply to Hans de Goede from comment #9)
> A new scratch build is now building here:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=32962084

It looks like it's stuck... Could you attach your patch(es) so that I can run a local mock build? Or at least resubmit your scratch build.
Thanks in advance.

It was not stuck, kernel builds just take quite a while and are not very verbose during some phases. The build is done now.

Indeed. I'm fetching it now and will test over the weekend. Thanks!

Created attachment 1542768 [details]
dmesg from patched kernel

Sorry for the delay. I was able to test your patched kernel today and it's not working:

$ for d in /sys/class/drm/card0-*-1 ; do echo -n "$(basename $d):" ; cat $d/status ; done
card0-DP-1:disconnected
card0-DVI-D-1:disconnected
card0-LVDS-1:connected
card0-VGA-1:connected

As you can see, LVDS-1 is detected as connected.

New dmesg attached.

Hmm, it looks like I accidentally build the kernel from a clean src.rpm instead of a patched one.

I've started a new scratch-build which should actually include the patch, sorry:

https://koji.fedoraproject.org/koji/taskinfo?taskID=33402447

I'm not 100% sure the is patch missing in the old build. If this build still does not work, can you please do:

sudo dmidecode &> dmidecode.log

And then attach the generated dmidecode.log here?

Created attachment 1549450 [details]
Thecus N5550 dmidecode log

The second patched kernel is not working either:

# uname -r
4.20.14-200.rhbz1665766.fc29.x86_64
# for d in /sys/class/drm/card0-*-1 ; do echo -n "$(basename $d):" ; cat $d/status ; done
card0-DP-1:disconnected
card0-DVI-D-1:disconnected
card0-LVDS-1:connected
card0-VGA-1:connected

dmidecode.log attached

Ok, so this is my bad, the gma500 driver contains 2 lvds drivers, one for the original poulsbo stuff and one for Ceder Trail hardware, I was patching the wrong one :|

Here is a new scratch-build with a fixed patch:
https://koji.fedoraproject.org/koji/taskinfo?taskID=33912533

If you do not have time to test right away, please at least download the rpms before koji garbage collects them.

Success:

# dmesg|grep gma500
[   17.692983] gma500 0000:00:02.0: System is on LVDS blacklist, skipping LVDS panel detection
[   18.341618] gma500 0000:00:02.0: fb0: psbdrmfb frame buffer device
[   18.351799] [drm] Initialized gma500 1.0.0 20140314 for 0000:00:02.0 on minor 0
# uname -r
5.0.5-200.rhbz1665766.fc29.x86_64
# for d in /sys/class/drm/card0-*-1 ; do echo -n "$(basename $d):" ; cat $d/status ; done
card0-DP-1:disconnected
card0-DVI-D-1:disconnected
card0-VGA-1:connected

Thanks!

Thank you for testing the patch.

I've submitted the patch upstream now. Given that you have a workaround and that this IMHO is a bit of a niche application, I do not think it is worth the effort to add the patch as downstream patch to the Fedora kernels. So I'm going to close this bug with a resolution of upstream now.

The patch should find its way into Fedora through the normal syncing of the Fedora kernel to the upstream kernel.

Regards,

Hans

Thanks a lot. I'd appreciate it if you could drop a note about which upstream kernel release this will go into when it gets accepted, so that I know when I can drop the workaround.

So I just got the following reply from upstream:

"Sometimes LVDS can be configured in the BIOS on CDV devices. Can you
check that it's not just a bad BIOS configuration first?"

If you have some time to check, then that would be great. If you check please also try "load BIOS defaults" or some such, because if those are wrong then IMHO we should still have the quirk.

Can you provide the correct upstream bug number? https://bugzilla.kernel.org/show_bug.cgi?id=109336 says the bug number is invalid.

I'm not sure why upstream insists there's an LVDS on my machine. There physically isn't one, it only has one HDMI and one VGA output connector, see http://www.thecus.com/upload_new/N5550_ANGLE_LARGE5.png . Or are they saying loading BIOS defaults would make it disappear from the detected outputs list?

(In reply to Hans de Goede from comment #20)
> So I just got the following reply from upstream:
> 
> "Sometimes LVDS can be configured in the BIOS on CDV devices. Can you
> check that it's not just a bad BIOS configuration first?"
> 
> If you have some time to check, then that would be great. If you check
> please also try "load BIOS defaults" or some such, because if those are
> wrong then IMHO we should still have the quirk.

So yes, I tried "load BIOS defaults". No change.

As discussed on the list, upstream has come up with another fix, here is a scratch kernel-build with upstream's fix added, please test:

https://koji.fedoraproject.org/koji/taskinfo?taskID=34215831

Note this is still building atm, testing instructions are as usual.

Hi, Hans. This latest patch seems to work fine and LVDS-1 is not present this time, either:

$ cat /proc/cmdline 
BOOT_IMAGE=/vmlinuz-5.0.7-300.hdg20190416.fc30.x86_64 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap LANG=en_US.UTF-8
$ for d in /sys/class/drm/card0-*-1 ; do echo -n "$(basename $d):" ; cat $d/status ; done
card0-DP-1:disconnected
card0-DVI-D-1:disconnected
card0-VGA-1:connected
$ dmesg|egrep -i 'drm|gma'
[   18.039379] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[   18.039385] [drm] No driver support for vblank timestamp query.
[   18.306195] fb0: switching to psbdrmfb from EFI VGA
[   18.312611] fbcon: psbdrmfb (fb0) is primary device
[   18.644866] gma500 0000:00:02.0: fb0: psbdrmfb frame buffer device
[   18.651881] [drm] Initialized gma500 1.0.0 20140314 for 0000:00:02.0 on minor 0

(In reply to Dominik 'Rathann' Mierzejewski from comment #24)
> Hi, Hans. This latest patch seems to work fine and LVDS-1 is not present
> this time, either:

Thank you for testing this. I've reported your results upstream.