Bug 1665766 - gma500_gfx misdetects LVDS-1 as connected causing black screen
Summary: gma500_gfx misdetects LVDS-1 as connected causing black screen
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 29
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-01-13 21:51 UTC by Dominik 'Rathann' Mierzejewski
Modified: 2019-04-21 18:47 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-04-09 07:07:33 UTC


Attachments (Terms of Use)
dmesg after modprobe'ing gma500_gfx module (8.11 KB, text/plain)
2019-01-13 21:51 UTC, Dominik 'Rathann' Mierzejewski
no flags Details
dmesg from patched kernel (60.32 KB, text/plain)
2019-03-11 07:33 UTC, Dominik 'Rathann' Mierzejewski
no flags Details
Thecus N5550 dmidecode log (15.31 KB, text/plain)
2019-03-29 12:36 UTC, Dominik 'Rathann' Mierzejewski
no flags Details


Links
System ID Priority Status Summary Last Updated
FreeDesktop.org 109336 None None None 2019-04-09 19:54:22 UTC

Description Dominik 'Rathann' Mierzejewski 2019-01-13 21:51:26 UTC
Created attachment 1520394 [details]
dmesg after modprobe'ing gma500_gfx module

1. Please describe the problem:
On a Thecus N5550 NAS box (Intel Atom D2550/Cedarview platform), the gma500_gfx driver detects LVDS-1 output as connected (it's not):

Jan 13 13:15:09 kernel: [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:36:LVDS-1] status updated from unknown to connected

Only VGA-1 is connected, but that's detected correctly. This causes black screen after kernel loads the driver. Adding video=LVDS-1:d to the kernel command line works around the issue.

2. What is the Version-Release number of the kernel:
4.19.13-300.fc29.x86_64

3. Did it work previously in Fedora? If so, what kernel version did the issue
   *first* appear?  Old kernels are available for download at
   https://koji.fedoraproject.org/koji/packageinfo?packageID=8 :
Unknown. The first Fedora version I installed on this machine was Fedora 28 and the issue is there.

4. Can you reproduce this issue? If so, please provide the steps to reproduce
   the issue below:
Yes, on every boot without 'video=LVDS-1:d' in the kernel command line.

5. Does this problem occur with the latest Rawhide kernel? To install the
   Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by
   ``sudo dnf update --enablerepo=rawhide kernel``:
I haven't tried.

6. Are you running any modules that not shipped with directly Fedora's kernel?:
No.

7. Please attach the kernel logs. You can get the complete kernel log
   for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the
   issue occurred on a previous boot, use the journalctl ``-b`` flag.

Comment 1 Hans de Goede 2019-01-14 10:30:37 UTC
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

Comment 2 Dominik 'Rathann' Mierzejewski 2019-01-14 10:46:03 UTC
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 .

Comment 3 Hans de Goede 2019-01-22 18:59:26 UTC
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.

Comment 4 Dominik 'Rathann' Mierzejewski 2019-01-23 08:38:50 UTC
(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!

Comment 5 Hans de Goede 2019-01-23 17:58:42 UTC
(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?

Comment 6 Hans de Goede 2019-01-23 22:17:47 UTC
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.

Comment 7 Hans de Goede 2019-02-20 17:01:56 UTC
Hi,

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

Regards,

Hans

Comment 8 Dominik 'Rathann' Mierzejewski 2019-02-21 11:55:09 UTC
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.

Comment 9 Hans de Goede 2019-02-22 09:28:09 UTC
A new scratch build is now building here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=32962084

Comment 10 Dominik 'Rathann' Mierzejewski 2019-02-22 10:54:20 UTC
(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.

Comment 11 Hans de Goede 2019-02-22 12:34:06 UTC
It was not stuck, kernel builds just take quite a while and are not very verbose during some phases. The build is done now.

Comment 12 Dominik 'Rathann' Mierzejewski 2019-02-22 12:39:26 UTC
Indeed. I'm fetching it now and will test over the weekend. Thanks!

Comment 13 Dominik 'Rathann' Mierzejewski 2019-03-11 07:33:12 UTC
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.

Comment 14 Hans de Goede 2019-03-11 15:40:38 UTC
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?

Comment 15 Dominik 'Rathann' Mierzejewski 2019-03-29 12:36:30 UTC
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

Comment 16 Hans de Goede 2019-04-03 11:20:15 UTC
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.

Comment 17 Dominik 'Rathann' Mierzejewski 2019-04-08 11:00:13 UTC
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!

Comment 18 Hans de Goede 2019-04-09 07:07:33 UTC
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

Comment 19 Dominik 'Rathann' Mierzejewski 2019-04-09 09:38:44 UTC
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.

Comment 20 Hans de Goede 2019-04-09 09:55:09 UTC
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.

Comment 21 Dominik 'Rathann' Mierzejewski 2019-04-09 11:19:04 UTC
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?

Comment 22 Dominik 'Rathann' Mierzejewski 2019-04-09 19:55:14 UTC
(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.

Comment 23 Hans de Goede 2019-04-16 15:34:50 UTC
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.

Comment 24 Dominik 'Rathann' Mierzejewski 2019-04-21 16:39:49 UTC
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

Comment 25 Hans de Goede 2019-04-21 18:47:47 UTC
(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.


Note You need to log in before you can comment on or make changes to this bug.