Created attachment 133649 [details] System log (includes kernel log) On Asus T102HA the display works at first, when I close the lid it turns off but never turns back on when I open the lid. There is no backlight and I also do not see anything displayed when looking at the screen under external illumunation. This happens every time, with and without X running. Backlight control (/sys/class/backlight/intel_backlight/brightness) otherwise works before this issue occurs, after this changing the brightness has no visible effect. This happens regardless of whether the keyboard is electrically attached via its USB connection. It is possible to "close" the lid (keyboard) without attaching it as the open/closed detection uses a different mechanism. The logs attached are with the keyboard not attached as that avoids some USB related spam. Attached are: - The system log, produced using drm.debug=0x1e . It includes kernel and Xorg logs, and "Lid closed" and "Lid opened" from logind can also be seen. - intel_reg dump --all I could not dump VBIOS, I get Input/Output error when trying to "cat" the rom and an error in dmesg (i915 0000:00:02.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0xa243). Kernel version: 4.13.0-rc4 Distribution: NixOS (unstable)
Created attachment 133650 [details] intel reg dump
Created attachment 133651 [details] kernel config
Adding tag into "Whiteboard" field - ReadyForDev *Status is correct *Platform is included *Feature is included *Priority and Severity correctly set *Logs included
Hello Ambroz, could you confirm if it's still present on latest tip? Thank you. https://cgit.freedesktop.org/drm-tip
The problem is still present with revision be67da218126edb88de92c391a48964c89219c11.
Possible dupe of bug 96571, please check the kernel config options there.
I think it is not a duplicate of bug 96571. Backlight control works for me, and there is no "Failed to own the PWM chip" error. Note, to get backlight control and battery monitor to work I made these kernel config changes (to default NixOS kernel): I2C y ACPI_I2C_OPREGION y PWM y PWM_CRC y PWM_SYSFS y PWM_LPSS y PWM_LPSS_PCI y PWM_LPSS_PLATFORM y PWM_PCA9685 y I2C_DESIGNWARE_PLATFORM y I2C_DESIGNWARE_PCI y INTEL_SOC_PMIC y I used to get the "failed to own the PWM chip" error but not after these config changes. Actually, if I do not do these changes then in addition to backlight and battery control not working, the screen also does not turn off when the lid is closed and remains on when it is reopened. I do however see these errors in the kernel log (with the modified kernel config): ACPI Exception: Could not find/resolve named package element: \_SB_.PCI0.I2C7.BATC (20170728/dspkginit-381) ACPI Exception: Could not find/resolve named package element: \_SB_.PCI0.I2C7.BATC (20170728/dspkginit-381) ACPI Exception: Could not find/resolve named package element: \_SB_.PCI0.I2C3.TIDR (20170728/dspkginit-381)
Created attachment 135075 [details] System log (includes kernel log), with drm-tip System log with ACPI Exception, these are not present in my previous log with older kernel.
I confirm bug is present on 4.15.4 kernel (running Arch Linux, but kernel is custom-compiled). I'm pretty sure it's related to BIOS version 303. Few months ago I was running BIOS version 300 and screen wakeup was happening on lid open. After upgrade to BIOS 303 bug appeared. Unfortunately I am unable to downgrade BIOS. BIOS changes are possible only through BIOS builtin upgrade feature which disallows downgrades and (afaik) checks signatures. Both BIOS upgrade files are available at https://www.asus.com/us/2-in-1-PCs/ASUS-Transformer-Mini-T102HA/HelpDesk_BIOS/ Direct link to 300 version: http://dlcdnet.asus.com/pub/ASUS/nb/T102HA/T102HAAS300.zip Direct link to 303 version: http://dlcdnet.asus.com/pub/ASUS/nb/T102HA/T102HAAS303.zip I tried avoid this bug by disabling screen blanking in userland settings. I have set "When laptop lid is closed: Do nothing" instead of "Blank screen" in system settings (mate-power-preferences), but that didn't help. I'm happy to include more info - just please tell me what is needed, because I'm new here. Thanks.
First of all. Sorry about spam. This is mass update for our bugs. Sorry if you feel this annoying but with this trying to understand if bug still valid or not. If bug investigation still in progress, please ignore this and I apologize! If you think this is not anymore valid, please comment to the bug that can be closed. If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.
The bug is still present on drm-tip, revision c46052cde6a50c5459e00791ffc4d5aa1ec58a9e.
Created attachment 138555 [details] c46052c kernel log with drm.debug=0x1e just before [ 84.741306] I detached keyborad/lid (to isolate USB-related messages) then, with detached: just before [ 168.869355] I closed the lid just before [ 203.130409] I opened the lid
OK, thanks. Jani any help from you?
Does modeset work in general? Does the machine suspend on lid close? If yes, does it resume otherwise? The dmesg is a bit thin on details. Does the userspace get some lid event?
Reporter, can you reply to Jani's questions?
> Does modeset work in general? Yes I'm 100% sure it does, it is clear from the kernel log and the fact the console looks nice and switching between console and Xorg is fast. > Does the machine suspend on lid close? If yes, does it resume otherwise? The dmesg is a bit thin on details. The machine was configured not to suspend on lid close, it remains on. > Does the userspace get some lid event? Yes this is clear from the first system log I attached, see the "Lid closed" and "Lid opened" messages from systemd-logind. Aug 21 19:22:54 tablet systemd-logind[753]: Lid closed. Aug 21 19:22:54 tablet kernel: pci_bus 0000:01: Allocating resources Aug 21 19:22:54 tablet kernel: pcieport 0000:00:1c.0: bridge window [io 0x1000-0x0fff] to [bus 01] add_size 1000 Aug 21 19:22:54 tablet kernel: pcieport 0000:00:1c.0: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 01] add_size 200000 add_align 100000 Aug 21 19:22:54 tablet kernel: pcieport 0000:00:1c.0: BAR 15: assigned [mem 0x91b00000-0x91cfffff 64bit pref] Aug 21 19:22:54 tablet kernel: pcieport 0000:00:1c.0: BAR 13: assigned [io 0x1000-0x1fff] Aug 21 19:23:11 tablet systemd-logind[753]: Lid opened. Aug 21 19:23:11 tablet kernel: pci_bus 0000:01: Allocating resources Tomorrow I will try again with newer software as is available to me.
Ambroz, any updates here?
I have just tested this again with kernel 4.18.9. The same thing happens, when the lid is closed the screen turns off and when it is opened again it remain off. The system was configured to not suspend, I had a ssh session open throughout the test, the system does not crash at any point. Log from journalctl is attached (includes kernel, Xorg, systemd messages). First log entry when the lid is closed: Sep 23 09:38:01 tablet kernel: usb 1-2: USB disconnect, device number 2 First log entry when the lid is reopened: Sep 23 09:39:02 tablet systemd-logind[778]: Lid opened. Kernel configuration is attached. It is not an issue with the PWM chip error, there is no such error because I enabled relevant kernel config options. I have tested this three times now and provided all requested info, and I'm not sure if I'll be able to do this again especially if no progress is being made.
Created attachment 141693 [details] kernel config with kernel 4.18.9
Created attachment 141694 [details] system log with kernel 4.18.9
Please double check that you can do something this and it works: # xrandr --output DSI-1 --off # sleep 5 # xrandr --output DSI-1 --auto So is it really only the lid close/reopen that fails? Please attach full dmesg with drm.debug=14 running a recent kernel version, reproducing the problem.
No feedback from more than two months.Priority of this bug is changed to Medium. Ambroz, your feedback is required in order to proceed wit this issue. Do you still have the issue with latest drmtip?
Sorry for the delay. > Please double check that you can do something this and it works: > # xrandr --output DSI-1 --off > # sleep 5 > # xrandr --output DSI-1 --auto > So is it really only the lid close/reopen that fails? This results in the screen turning off and then turning back on 5 seconds later (the correct output name is DSI1). The problem is only with closing and reopening the lid. > Please attach full dmesg with drm.debug=14 running a recent kernel version, > reproducing the problem. Kernel log is attached. 10:35:52 - ran xrandr commands (screen turned off and then back on) 10:36:12 - closed lid (screen turned off) 10:36:25 - opened lid (screen remains off)
Created attachment 144125 [details] Kernel log with kernel 5.0.10 and drm.debug=14
(In reply to Ambroz Bizjak from comment #25) > Created attachment 144125 [details] > Kernel log with kernel 5.0.10 and drm.debug=14 I see some: May 02 10:35:21 tablet kernel: [drm:mipi_exec_pmic [i915]] Skipping PMIC element execution Please re-test with 5.1 or drm-tip, and make sure you have the following enabled in your kernel config: CONFIG_PMIC_OPREGION=y CONFIG_CRC_PMIC_OPREGION=y CONFIG_BXT_WC_PMIC_OPREGION=y CONFIG_CHT_WC_PMIC_OPREGION=y CONFIG_CHT_DC_TI_PMIC_OPREGION=y CONFIG_INTEL_SOC_PMIC=y CONFIG_INTEL_SOC_PMIC_BXTWC=y CONFIG_INTEL_SOC_PMIC_CHTWC=y CONFIG_INTEL_SOC_PMIC_CHTDC_TI=y
Hi, I have the same problem and shall post more info soon. Meanwhile here is my hardware and system report direct link https://linux-hardware.org/?probe=bf45e06087 I am not a programmer but just a user with a bit of linux knowledge, if I can I will help.
I have got news : I downgraded my BIOS from 303 to 300 by following a hint that adviced to type 'risky' on the window that ttells you the bios file is 'too old'. It reflashes the BIOS file 300. And wonderful, the lid close ,sleep and wake work really well. The two BIOS files are downloadable on the ASUS website as per this link: https://dlcdnets.asus.com/pub/ASUS/nb/T102HA/T102HAAS303.zip https://dlcdnets.asus.com/pub/ASUS/nb/T102HA/T102HAAS300.zip I do not know how to compare the two files, so that I cannot say what has changed. I have not used the 300 BIOS long enough to say if there is any performance loss.
I have tried with the suggested kernel config changes. First I see some errors in dmesg during boot: Jun 29 13:59:16 tablet kernel: gpio gpiochip2: (INT33FF:01): detected irqchip that is shared with multiple gpiochips: please fix the driver. Jun 29 13:59:16 tablet kernel: cherryview-pinctrl INT33FF:01: Failed to translate GPIO to IRQ Jun 29 13:59:16 tablet kernel: genirq: Flags mismatch irq 0. 00002000 (intel_soc_pmic_chtdc_ti) vs. 00015a00 (timer) Jun 29 13:59:16 tablet kernel: intel_soc_pmic_chtdc_ti i2c-INT33F5:00: Failed to request IRQ 0 for intel_soc_pmic_chtdc_ti: -16 Jun 29 13:59:16 tablet kernel: intel_soc_pmic_chtdc_ti: probe of i2c-INT33F5:00 failed with error -16 Jun 29 13:59:16 tablet kernel: gpio gpiochip3: (INT33FF:02): detected irqchip that is shared with multiple gpiochips: please fix the driver. Jun 29 13:59:16 tablet kernel: gpio gpiochip4: (INT33FF:03): detected irqchip that is shared with multiple gpiochips: please fix the driver. When I close the lid the screen goes black and the entire system hangs including network connection. This hang started happening only with these config changes. So I cannot provide logs when the lid is closed.
Created attachment 144682 [details] System log with kernel 5.1 and suggested kernel config.
Created attachment 144683 [details] System log with kernel 5.1 and suggested kernel config. Attached wrong file, sending the right one.
(In reply to Ville Syrjala from comment #26) > (In reply to Ambroz Bizjak from comment #25) > > Created attachment 144125 [details] > > Kernel log with kernel 5.0.10 and drm.debug=14 > > I see some: > May 02 10:35:21 tablet kernel: [drm:mipi_exec_pmic [i915]] Skipping PMIC > element execution > > Please re-test with 5.1 or drm-tip, and make sure you have the following > enabled in your kernel config: > CONFIG_PMIC_OPREGION=y > CONFIG_CRC_PMIC_OPREGION=y > CONFIG_BXT_WC_PMIC_OPREGION=y > CONFIG_CHT_WC_PMIC_OPREGION=y > CONFIG_CHT_DC_TI_PMIC_OPREGION=y > CONFIG_INTEL_SOC_PMIC=y > CONFIG_INTEL_SOC_PMIC_BXTWC=y > CONFIG_INTEL_SOC_PMIC_CHTWC=y > CONFIG_INTEL_SOC_PMIC_CHTDC_TI=y Results from these kernel config changes are attached.
@Ambroz, Have you tried to verify the issue with BIOS 300 as other user alfredovogel? This is to confirm if the issue is related to BIOS.
(In reply to Ambroz Bizjak from comment #29) > I have tried with the suggested kernel config changes. First I see some > errors in dmesg during boot: > > Jun 29 13:59:16 tablet kernel: gpio gpiochip2: (INT33FF:01): detected > irqchip that is shared with multiple gpiochips: please fix the driver. I was told these should be harmless, and a fix is available here: https://bugzilla.kernel.org/show_bug.cgi?id=202543 Would be cool if you can test that and give it a Tested-by tag if it works. So unfortunately those warnings don't seem to explain why the machine now dies when you close the lid :(
(In reply to alfredovogel from comment #28) > I have got news : > I downgraded my BIOS from 303 to 300 by following a hint that adviced to > type 'risky' on the window that ttells you the bios file is 'too old'. > It reflashes the BIOS file 300. > And wonderful, the lid close ,sleep and wake work really well. > The two BIOS files are downloadable on the ASUS website as per this link: > https://dlcdnets.asus.com/pub/ASUS/nb/T102HA/T102HAAS303.zip > https://dlcdnets.asus.com/pub/ASUS/nb/T102HA/T102HAAS300.zip > > I do not know how to compare the two files, so that I cannot say what has > changed. > There are three VBTs in each file, first two seem identical but the third has significant changes in the MIPI sequence block (and a small tweak to the panel timings). But I can't say which of the three is actually used. You'd need to boot with each and take a dump of /sys/kernel/debug/dri/0/i915_vbt
(In reply to Ambroz Bizjak from comment #29) > Jun 29 13:59:16 tablet kernel: cherryview-pinctrl INT33FF:01: Failed to > translate GPIO to IRQ > Jun 29 13:59:16 tablet kernel: genirq: Flags mismatch irq 0. 00002000 > (intel_soc_pmic_chtdc_ti) vs. 00015a00 (timer) > Jun 29 13:59:16 tablet kernel: intel_soc_pmic_chtdc_ti i2c-INT33F5:00: > Failed to request IRQ 0 for intel_soc_pmic_chtdc_ti: -16 > Jun 29 13:59:16 tablet kernel: intel_soc_pmic_chtdc_ti: probe of > i2c-INT33F5:00 failed with error -16 These are apparently something more serious. If you can run acpidump on the machine an attach the results here we may be able to investigate further.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/intel/issues/41.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.