[Bug 1933028] Re: Power supply disconnection not recognized on Dell XPS 13 9310 w/5.10 OEM kernel
This problem exists in all kernels I have tried newer than 5.7, including 5.11 HWE-Edge and several mainlines, including 5.12.x and 5.13.x (RC), as well as 5.10 OEM. There was a problem identical to this reported at upower (https://gitlab.freedesktop.org/upower/upower/-/issues/126), but it was supposedly fixed with a kernel commit (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=992a60ed0d5e312ce9a485c9e12097ac82ae4b3e). I'm still seeing the bug, however. Everything in the description in the thread of comments at upower is what I am seeing to the letter. If the laptop finishes POST and loads GRUB with the power disconnected, upower will report the power supply state as offline from there forward, though then the desktop environment responds correctly to power state changes. If it finishes POST and loads GRUB with power connected, it reports the power online from there forward, and that does prevent the desktop environment from detecting power state changes. This issue was also present in a live session of Manjaro I tried with 5.10. ** Bug watch added: gitlab.freedesktop.org/upower/upower/-/issues #126 https://gitlab.freedesktop.org/upower/upower/-/issues/126 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1933028 Title: Power supply disconnection not recognized on Dell XPS 13 9310 w/5.10 OEM kernel To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-oem-5.10/+bug/1933028/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1933028] [NEW] Power supply disconnection not recognized on Dell XPS 13 9310 w/5.10 OEM kernel
Public bug reported: I bought a Dell XPS 9310 "Developer edition" with Ubuntu 20.04 preinstalled. It came with 5.6 OEM kernel, and when I unplugged the AC power, it would properly recognize it and do the things like switch to a dimmer display (as configured) and sleep if the lid is closed (rather than just lock the session as it would do with AC power connected). Since the 5.6 kernel auto updated to 5.10, this has not worked, with exceptions (below). Unplugging the power supply generates the appropriate ACPI event as noted in acpi_listen (and TLP does properly recognize the on-battery status and apply the on-battery changes), and upower does report the power supply as being offline with 'upower --monitor-detail'. However, this portion of the details: [04:00:48.093] daemon changed: daemon-version: 0.99.11 on-battery: no lid-is-closed: no lid-is-present: yes critical-action: HybridSleep is not present when the command is executed while running 5.10 OEM. It is present when the 5.6 kernel is running. It seems to correspond 1:1 with the proper function when the power supply is removed... if the 'daemon changed section' exists, it works, otherwise not. If I am running KDE Plasma, when the issue is manifesting, the tooltip for the power management widget says "plugged in but discharging," claiming the power supply is attached but not producing enough power. It is definitely not connected, and is wholly on battery power when it says that. It's not just a KDE thing, though, as the same malfunction happens in GNOME in the bone-stock Dell install of Ubuntu 20.04 also. It just doesn't tell the bit about "plugged in but discharging," as far as I know. I am not very familiar with GNOME. Now, the exceptions. If I boot the laptop while on battery power, the connection and disconnection of the power supply will be properly recognized until the next boot. The 'daemon changed' bit from upower will be reported. If the next boot is on AC, it resumes working incorrectly, with or without a cold boot in between. I have tried various kernel parameters to get it to work, but while a couple of times I thought I finally "got it," the improvement proved ephemeral. When I added 'acpi_rev_override=1 acpi_osi=Linux' to the kernel parameters using GRUB, it would work properly for the next boot (on AC), but only for that boot. Afterward, it would malfunction like 5.10 OEM usually does when booting on AC. I had the same happen with other combinations of ACPI_* kernel parameters. None ever had its effect persist more than one boot. I tried telling it that it was Windows (which worked for one boot), or using two parameters to say it was Linux (acpi_osi and acpi_os_name), and it worked for one boot also. I don't recall it ever working without using the acpi_rev_override parameter, though I tried so many things that I may be in error about that. The same faulty behavior is noted when using the standard Ubuntu kernel 5.8 (HWE) or mainline 5.11+ kernels. I also tried Manjaro KDE from a live session (5.10 kernel), and it did the same as in Ubuntu 20.04 (since the live session had booted on AC, unplugging power did not register; it again said "plugged in but discharging" in the power widget tooltip). Whatever patch Dell must have checked in to 5.6 to make the power state changes work correctly, if there is one, apparently did not make it to 5.10, or else it is not compatible fully with 5.10. Machine specs are i5-1135G7, 16GB, Dell firmware 2.2.0 (latest, as of this writing). No touch, 1920x1200 display, NVMe SSD (1TB SK Hynix, but the same behavior is noted with the stock 256GB WD NVMe SSD). Thw power supply I am using is the factory Dell unit (USB-C connector) plugged directly into the unit with no intermediate hub. Nothing is plugged in other than the power. The faulty versions of the kernel include all of the 5.10 variants I tried, most recently 5.10.1029.30. It happens on Ubuntu 20.04 proper as well as the downstream variant, KDE Neon (20.04 base). What I expected to happen: When I boot with the AC power plugged in, then later unplug it, I expect the system to apply the settings I chose for on-battery operation: Dimmer LCD backlight, enter standby when lid is closed, and recognition of the on-battery status from the power applet in the tray. The "power unplugged" system sound is heard. What actually happens: The "on battery" settings are not applied, and the power applet reports "plugged in but discharging." No system sound is heard. ** Affects: linux-oem-5.10 (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1933028 Title: Power supply disconnection not recognized on Dell XPS 13 9310 w/5.10 OEM kernel To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-oem-5.10/+bug/1933028/+subscriptions -- ubuntu-bugs
Re: [Bug 1900149] Re: Microcode update causes hard lockups in Intel N4200 CPU/SoC
It's been two more weeks since the 0x40 microcode was installed, and the Swift has not locked up since. Looks so far like it's fixed so far, as by now I would have expected several crashes to have taken place, but I will keep watching and post back as long as the bug is still open (and certainly if the Swift locks up). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1900149 Title: Microcode update causes hard lockups in Intel N4200 CPU/SoC To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/intel-microcode/+bug/1900149/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1900149] Re: Microcode update causes hard lockups in Intel N4200 CPU/SoC
I installed it yesterday morning, and it has not locked up since then. Looks promising so far, as normally it would have locked up by now, but I'll definitely keep using it (I use the laptop daily anyway) with the new microcode and report back here. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1900149 Title: Microcode update causes hard lockups in Intel N4200 CPU/SoC To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/intel-microcode/+bug/1900149/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1895469] Re: KDE Connect constantly loses pairing, can't share/receive files
As I wrote in the parallel bug I filed in KDE's tracker (https://bugs.kde.org/show_bug.cgi?id=424606#c2), I've found what may be the root of the bug. Initially I did not report this here because (after finding that KDE Neon, which previously shared the same bug, was now working with KDE Connect) when I tried it in Kubuntu 20.04, it didn't work as it had in KDE Neon. Just now, though, I tried Kubuntu 20.04 again, and it worked as it should for the first time since the upgrade to 20.04 from 18.04. The upgrade to Plasma 5.20 on Neon a few weeks ago brought a new detail in the log that was not there previously. It mentioned an SSL issue with certificate validation with KDE Connect when I attempted a file transfer, so I did some poking around and found that the version of libssl and openssl in Ubuntu is not the one in any of the distros whose KDE Plasma works well (Fedora 32, Manjaro, OpenSUSE Tumbleweed). The one in Ubuntu was/is 1.1.1f, while the version in each of the distros above was 1.1.1g or 1.1.1h (don't really remember which, only that it was newer than Ubuntu). I did a package search and found that Debian Sid had 1.1.1h in .deb form, and I was able to install that in Kubuntu and Neon without a hitch (openssl and libssl, 1.1.1h, as well as the 32-bit version of libssl 1.1.1h). Neon began to work after that, while back then Kubuntu 20.04 changed its failure behavior a little, but still was not working. For some reason, it's working now in Kubuntu 20.04 too. ** Bug watch added: KDE Bug Tracking System #424606 https://bugs.kde.org/show_bug.cgi?id=424606 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1895469 Title: KDE Connect constantly loses pairing, can't share/receive files To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/kdeconnect/+bug/1895469/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1900149] Re: Microcode update causes hard lockups in Intel N4200 CPU/SoC
I did now, thanks for the link. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1900149 Title: Microcode update causes hard lockups in Intel N4200 CPU/SoC To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/intel-microcode/+bug/1900149/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1900149] Re: Microcode update causes hard lockups in Intel N4200 CPU/SoC
Not sure how kdeconnect got in there... that was from another big I filed, not this one. ** Package changed: kdeconnect (Ubuntu) => intel-microcode (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1900149 Title: Microcode update causes hard lockups in Intel N4200 CPU/SoC To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/intel-microcode/+bug/1900149/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1900149] [NEW] Microcode update causes hard lockups in Intel N4200 CPU/SoC
Public bug reported: Months ago, my Acer Swift SF113-31-P5CK laptop (running KDE Neon or Kubuntu) began to hard lock at seemingly random intervals, ignoring sysrq+REISUB and requiring a force-off. After some trial and error, I tried removing the pertinent microcode file (06-5c-09) from /lib/firmware/intel-ucode and updating the initramfs, and the lockup never happened again. After I discovered that, I checked, and indeed, the onset of the lockups coincided with the delivery of the latest Intel microcode by Ubuntu. I then tried inserting the second newest microcode file into /lib/firmware/intel-ucode and updated the initramfs, and again, no lockups. They previously happened anywhere from 5 minutes to a few hours into a session, and often multiple times a day. By now it has been several months since the last lockup, and I use the laptop hours each day. I could not get through a day without a lockup with the newest microcode file (0x38) in use, and often there were multiples per day. The faulty microcode for the Intel Pentium Silver N4200 SoC that my Swift uses is 0x38, which is the newest, as far as I know, so that's the one the Ubuntu update delivers. The one I am using now is 0x32, the previous one before 0x38, and it's been in use for over a thousand hours with no lockup. I saw a recent Microsoft info bulletin describing the newest Windows microcode update at the time, and I noticed that the microcode listed for my CPU in that update was 0x32. The prior Microsoft microcode update showed 0x38, and there was a footnote for the bulletin that mentioned it had been reverted (though it didn't say why). I can only conclude that I was not the only one having problems with the 0x38 release of 06-5c-09 (SHA256 9f6d3bef49d33dfc556aedb94670c6c347662d9c3cb9ececd58e23cd636512fc). Not surprisingly, I had the same experience with non-Ubuntu distros (OpenSUSE and Fedora). If 0x38 was loaded, it was going to lock up frequently. I think 0x38 was probably one of the Spectre or Meltdown ucode updates, but it's no good if the thing causes PCs to lock up in 5 minutes of use. Until/unless Intel decides to release a version that actually works as intended, I think 0x32 is the lesser of the two evils. ** Affects: kdeconnect (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1900149 Title: Microcode update causes hard lockups in Intel N4200 CPU/SoC To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/kdeconnect/+bug/1900149/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1895469] Re: KDE Connect constantly loses pairing, can't share/receive files
This bug also affects the Kubuntu Groovy Gorilla beta right now, with so I added the tag 'groovy'. The current version of Kubuntu Groovy uses KDE Connect version 20.08.1-0ubuntu1. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1895469 Title: KDE Connect constantly loses pairing, can't share/receive files To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/kdeconnect/+bug/1895469/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1895469] Re: KDE Connect constantly loses pairing, can't share/receive files
** Tags added: groovy -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1895469 Title: KDE Connect constantly loses pairing, can't share/receive files To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/kdeconnect/+bug/1895469/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1895469] [NEW] KDE Connect constantly loses pairing, can't share/receive files
Public bug reported: When I pair KDE Connect with another PC running KDE connect, the pairing works as expected, and some of the functions work. Most of them are not useful to me, connecting PC to PC rather than PC to phone, so I only really use the shared clipboard and file sharing, and ping for testing. Ping and shared clipboard work, but files cannot be sent (using "share") in either direction. The "receiving file" dialog appears on the receiving PC, but it never progresses. It does not work from the KDE Connect tray menu or from the command line either. The pairing is not persistent either. When the PCs are paired, pressing the "refresh" button in the KDE Connect dialog causes the pairing to be lost on both PCs, and so does rebooting. This happens any time at least one of the paired PCs is running Kubuntu 20.04 or another Ubuntu 20.04 derivative, like KDE Neon (20.04 rebase), or even Mint Cinnamon 20 with KDE Connect Indicator. It doesn't matter what distro is on the other end, or which of my PCs is the one running Kubuntu 20.04 (or if they both are). Fedora 32, Kubuntu 18.04, Neon (18.04 base), OpenSUSE Tumbleweed, and Manjaro all work with one another as expected in all the combinations I tried. I tried it with the PCs connected wirelessly, by ethernet, or one of each, and it was all the same. I even tried booting to a live session of Kubuntu 20.04 and pairing that with a PC running a non-Ubuntu 20.04 release, and it did the same. The issue is apparently not in any of the changes I made. I had made a bunch of modifications to my Kubuntu 20.04 installation previously, like grabbing the Qt and frameworks version from the Groovy repo, so I just today reinstalled Kubuntu to use the ubuntu-bug tool with the default packages showing. I tried the thing in the KDE Connect troubleshooting guide to open the necessary ports in UFW, and it didn't help, so I tried just removing UFW (with the Kubuntu installation I had before this fresh one) as a test, and it made no difference. Kernel versions have no effect on any of this. I've tried 5.4 to 5.8, Ubuntu and mainline, as well as those from the other distros I tried, and they made no difference. I reported this issue in KDE's bug tracker also, but it seems that the bug originates upstream from Neon, in Ubuntu. The last iteration of Neon that was based on 18.04 had all the same KDE package versions as the 20.04 version that replaced it, yet Neon (18.04)'s combination of KDE Connect 1.4.0, Qt 5.14.2, frameworks 5.72(?), etc., worked fine, while the 20.04 version of Neon worked the same as Kubuntu 20.04, which is to say, badly. The report from ubuntu-bug should be attached. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: kdeconnect 1.4-0ubuntu5 ProcVersionSignature: Ubuntu 5.4.0-47.51-generic 5.4.55 Uname: Linux 5.4.0-47-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27.8 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: KDE Date: Sun Sep 13 09:54:02 2020 InstallationDate: Installed on 2020-09-13 (0 days ago) InstallationMedia: Kubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731) SourcePackage: kdeconnect UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: kdeconnect (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug focal -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1895469 Title: KDE Connect constantly loses pairing, can't share/receive files To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/kdeconnect/+bug/1895469/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1784152] Re: i2c_hid_get_input floods system logs
Issue is fixed by kernel version 4.18.0-16 on my Elan touchpad ELAN0501 04F3:305B touchpad. Selecting 4.18.0-15 brings the issue back, so I can confirm it was in the kernel and not another update. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1784152 Title: i2c_hid_get_input floods system logs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1784152/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1784152] Re: i2c_hid_get_input floods system logs
Niel, it's still happening on my system as of now (October 10, 2018), using latest Ubuntu kernel. Did you change the touchpad to basic mode by any chance? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1784152 Title: i2c_hid_get_input floods system logs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1784152/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1784152] Re: i2c_hid_get_input floods system logs
Kai-Heng Feng, I installed the kernel as linked in post #18. It installed without a problem and booted and ran on the laptop just like the official kernels. I've confirmed it is 4.19.1 running. Unfortunately, dmesg still reports many multiples of the error in question each time I use the touchpad (about 100 instances of this error per second the whole time I am using the touchpad): i2c_hid i2c-ELAN0501:00: i2c_hid_get_input: incomplete report (64/65535) Note that the 14/65535 from the previous kernels has changed to 64/65535. I don't have any idea what the significance of that is, but it's a change. Do you need another udevadm report for this kernel too? I will be happy to provide one if it will help. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1784152 Title: i2c_hid_get_input floods system logs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1784152/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1784152] Re: i2c_hid_get_input floods system logs
Adding "udevadm info -e" results for my Swift 1. I2C is active, kernel parameter as above not set, kernel 4.15.0-35-generic ** Attachment added: "info.txt" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1784152/+attachment/5193692/+files/info.txt -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1784152 Title: i2c_hid_get_input floods system logs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1784152/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1784152] Re: i2c_hid_get_input floods system logs
Seeing it also on my Acer Swift 1 laptop with the newer Ubuntu 4.15 kernel releases (newest as of this writing is 4.15.0-35-38, and the issue is present in that build) and also with the mainline 4.18.10 release. My touchpad is also an Elantech, but is a different model from the original report. My touchpad is reported as ELAN0501 instead of ELAN1010 in the dmesg spam, but otherwise, it's exactly as reported (also reporting 14/65535). Changing the touchpad mode to basic in the UEFI does eliminate the dmesg spam, but that's because it switches it to PS/2 mouse emulation mode, no longer using the I2C bus at all. The acpi_osi= parameter disabled the touchpad when I tried it. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1784152 Title: i2c_hid_get_input floods system logs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1784152/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
