You are not logged in.
I installed Arch on a new ThinkPad P16 Gen 1 about 2 weeks ago. Over the last several days, while sitting idle, when I return to the machine, the capslock key is flashing and the machine is otherwise unresponsive. I did a hard shutdown, then restarted. The subequent boot always fails to proceed to sddm login, though I can get to a terminal.
Here is the full `journalctl -b` output: https://0x0.st/o9iQ.txt
Most notably:
Aug 20 11:57:16 eh-thinkpad systemd[1]: Starting Daemon for power management...
Aug 20 11:57:16 eh-thinkpad upowerd[2158]: energy_full (101.460000) is greater than energy_full_design (93.540000)
Aug 20 11:57:16 eh-thinkpad upowerd[2158]: did not recognise type Unknown, please report
Aug 20 11:57:16 eh-thinkpad kernel: BUG: kernel NULL pointer dereference, address: 0000000000000000
Aug 20 11:57:16 eh-thinkpad kernel: #PF: supervisor instruction fetch in kernel mode
Aug 20 11:57:16 eh-thinkpad kernel: #PF: error_code(0x0010) - not-present page
Aug 20 11:57:16 eh-thinkpad kernel: PGD 0 P4D 0
Aug 20 11:57:16 eh-thinkpad kernel: Oops: 0010 [#1] PREEMPT SMP NOPTI
Aug 20 11:57:16 eh-thinkpad kernel: CPU: 4 PID: 2158 Comm: upowerd Tainted: P OE 5.19.1-arch2-1 #1 e053941816231cdb69988a866d07465c3100e80c
Aug 20 11:57:16 eh-thinkpad kernel: Hardware name: LENOVO 21D6004TUS/21D6004TUS, BIOS N3FET25W (1.10 ) 07/14/2022
Aug 20 11:57:16 eh-thinkpad kernel: RIP: 0010:0x0
Aug 20 11:57:16 eh-thinkpad kernel: Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6.
Aug 20 11:57:16 eh-thinkpad kernel: RSP: 0018:ffffa533418a7d28 EFLAGS: 00010202
Aug 20 11:57:16 eh-thinkpad kernel: RAX: 0000000000000000 RBX: ffffffff8b584d08 RCX: ffffffff8b584d08
Aug 20 11:57:16 eh-thinkpad kernel: RDX: ffffa533418a7d30 RSI: 0000000000000004 RDI: ffff990a08e79800
Aug 20 11:57:16 eh-thinkpad kernel: RBP: 0000000000000004 R08: ffff990a08e79838 R09: ffff990a2b493380
Aug 20 11:57:16 eh-thinkpad kernel: R10: 0000000000000000 R11: 0000000000000001 R12: ffff990a2cebe000
Aug 20 11:57:16 eh-thinkpad kernel: R13: ffff990a08e79838 R14: ffffffff8b584d08 R15: ffff990a08e79800
Aug 20 11:57:16 eh-thinkpad kernel: FS: 00007f5863285740(0000) GS:ffff99114fb00000(0000) knlGS:0000000000000000
Aug 20 11:57:16 eh-thinkpad kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Aug 20 11:57:16 eh-thinkpad kernel: CR2: ffffffffffffffd6 CR3: 00000001315de005 CR4: 0000000000770ee0
Aug 20 11:57:16 eh-thinkpad kernel: PKRU: 55555554
Aug 20 11:57:16 eh-thinkpad kernel: Call Trace:
Aug 20 11:57:16 eh-thinkpad kernel: <TASK>
Aug 20 11:57:16 eh-thinkpad kernel: power_supply_show_property+0xbf/0x240
Aug 20 11:57:16 eh-thinkpad kernel: dev_attr_show+0x19/0x40
Aug 20 11:57:16 eh-thinkpad kernel: sysfs_kf_seq_show+0xa4/0xf0
Aug 20 11:57:16 eh-thinkpad kernel: seq_read_iter+0x123/0x450
Aug 20 11:57:16 eh-thinkpad kernel: new_sync_read+0x134/0x1c0
Aug 20 11:57:16 eh-thinkpad kernel: vfs_read+0x148/0x190
Aug 20 11:57:16 eh-thinkpad kernel: ksys_read+0x6f/0xf0
Aug 20 11:57:16 eh-thinkpad kernel: do_syscall_64+0x5c/0x90
Aug 20 11:57:16 eh-thinkpad kernel: ? exc_page_fault+0x74/0x170
Aug 20 11:57:16 eh-thinkpad kernel: entry_SYSCALL_64_after_hwframe+0x63/0xcd
Aug 20 11:57:16 eh-thinkpad kernel: RIP: 0033:0x7f58634d5e2c
Aug 20 11:57:16 eh-thinkpad kernel: Code: ec 28 48 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 d9 bd f8 ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 34 44 89 c7 48 89 44 24 08 e8 2f be f8 ff 48
Aug 20 11:57:16 eh-thinkpad kernel: RSP: 002b:00007fff50ccf140 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
Aug 20 11:57:16 eh-thinkpad kernel: RAX: ffffffffffffffda RBX: 000055998ff3c760 RCX: 00007f58634d5e2c
Aug 20 11:57:16 eh-thinkpad kernel: RDX: 0000000000001000 RSI: 000055998ff845f0 RDI: 000000000000000e
Aug 20 11:57:16 eh-thinkpad kernel: RBP: 00007fff50ccf270 R08: 0000000000000000 R09: 000055998ff3cef0
Aug 20 11:57:16 eh-thinkpad kernel: R10: 00007f58635b7b20 R11: 0000000000000246 R12: 0000000000000000
Aug 20 11:57:16 eh-thinkpad kernel: R13: 0000000000000000 R14: 0000000000000000 R15: 000000000000000e
Aug 20 11:57:16 eh-thinkpad kernel: </TASK>
Rebooting after that times out after 90s trying to shut down `upowerd`, but the following boot usually succeeds.
I have a number of hardware related errors that I've been trying to solve as well. I'm not trying to turn this into a kitchen sink post if they're unrelated to the topic (though I wouldn't turn down advice!), but in the interest of being thorough, here's what I know of them:
* I have installed all of the firmware related to "possible missing firmware" errors as recommended on the mkinicpio page of the wiki
* I tried installing `extra/sof-firmware` which installs version 2.1, but it reported errors of the ABI being newer than the kernel, so I removed it. Assuming I need to manually install a different version, but haven't figured out which to use yet
fwupd doesn't shine much light on it:
$ fwupdmgr update
Devices with no available firmware updates:
• ELAN0683:00 04F3:320B
• Integrated Camera
• System Firmware
• UEFI Device Firmware
• UEFI Device Firmware
• UEFI Device Firmware
• UEFI Device Firmware
• UEFI Device Firmware
• UEFI Device Firmware
• UEFI Device Firmware
• UEFI Device Firmware
• UEFI Device Firmware
• UEFI Device Firmware
• UEFI Device Firmware
• UEFI Device Firmware
• UEFI Device Firmware
• UEFI dbx
Devices with the latest available firmware version:
• Micron MTFDKBA1T0TFH
• Unifying Receiver
$ uname -r
5.19.1-arch2-1
Kernel params:
# Created by: archinstall
# Created on: 2022-08-10_23-37-35
title Arch Linux (linux)
linux /vmlinuz-linux
initrd /intel-ucode.img
initrd /initramfs-linux.img
options cryptdevice=PARTUUID=b62c4f7a-52b5-4581-909e-c7f8e2a7a18d:luksdev root=/dev/mapper/luksdev zswap.enabled=0 rw intel_pstate=no_hwp rootfstype=ext4 nvidia-drm.modeset=1 ibt=off pcie_aspm=off ipv6.disable_ipv6=1 lsm=landlock,lockdown,yama,integrity,apparmor,bpf
All installed packages: https://0x0.st/oLDG.txt
If there is anything else I can provide, please let me know. Any insights would be much appreciated!
Offline
The flashing caps is a positive indication there had been a kernel panic. https://wiki.archlinux.org/title/Kernel#Kernel_panics
After a panic, what we really need to see is journalctl -b -1 That will show us the journal for the *previous* boot, not the current boot
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way
Offline
Oops, I thought I included that as well. Here is an example: http://0x0.st/o9PH.txt
They never seem to end with a bang, though, just trail off like the plug was pulled. The cycle is very consistent, though, which leads me to avoid hastily blaming it on a hardware failure:
system crashes after I leave it
subsequent boot fails on upowerd daemon with logs like above
boot after that successfully goes to sddm, upowerd starts normally, and the system works fine until I leave it for a while, then rinse & repeat
Offline
Kernel trace matches https://bbs.archlinux.org/viewtopic.php?id=279005
"journalctl -b -1" will not have any indications of the kernel panic unless you can reboot w/ https://wiki.archlinux.org/title/Keyboa … el_(SysRq) (and previously sync/umount the drive) because the journal doesn't get sync'd to disk.
Online
Yeah, it wasn't responsive for sysrq.
Looking at the thread you linked, I thought I would start by getting up to date so my kernel matched the one he was patching, and it panicked in the middle of the update. I can't even chroot into it from the live media now.
The only post I found similar is: https://bbs.archlinux.org/viewtopic.php?id=243149, in which you were also a participant.
So I gave the strace a shot:
strace -f chroot /mnt /bin/bash &> /tmp/strace.log
Which ended up with: http://0x0.st/o9aL.txt
I'm kind of out of my element from there... I think the locale part might be a red herring, but I tried updating the locale in the live environment and retrying the chroot just to see if it would help. However, on my mounted filesystem, the only dir in /usr/lib/locale is C.UTF-8, but there is no /usr/share/locale/C.UTF-8, so no matter which I go with, I end up with an ENOENT in one or the other of /usr/lib or /usr/share
Afraid I'm going to have to start over on this one. I've used Arch for years on my personal desktops and have had no real issues with stability. This was my first foray into a laptop, and as a dedicated work machine, I'm definitely starting to wonder if I should have just built another desktop...
Offline
You'll have to fix teh installation offline (no chroot, but sysroot), https://wiki.archlinux.org/title/Pacman … an_upgrade
Online
So I did end up just starting over with it. It's still new, so it was simple enough. Currently, it will boot into sddm -> KDE, but it endlessly tries to start plasma-powerdevil, which then leads to a similar kernel error as above. I don't think there's anything new, but here's the log anyway: https://0x0.st/o9Qi.txt
I now have kernel:
5.19.2-arch1-2
In the other thread you linked, loqs posted the 2 patched kernels that would provide additional logging. Having never installed a kernel like this before, would I just install those like any local package? Anything else I need to do?
pacman -U linux-5.19.2.arch1-2.2-x86_64.pkg.tar.zst
pacman -U linux-headers-5.19.2.arch1-2.2-x86_64.pkg.tar.zst
Offline
In the other thread you linked, loqs posted the 2 patched kernels that would provide additional logging. Having never installed a kernel like this before, would I just install those like any local package? Anything else I need to do?
pacman -U linux-5.19.2.arch1-2.2-x86_64.pkg.tar.zst pacman -U linux-headers-5.19.2.arch1-2.2-x86_64.pkg.tar.zst
You do not need to do anything else. You can skip installing linux-headers if it is not needed on the system. It is typically used to build out of tree modules.
Offline
I installed the patched kernel. The boot froze at:
kernel: spi-nor spi0.0: unrecognized JEDEC id bytes: 3c f0 30 09 5c 00
But I could open a terminal. Since it was KDE attempting to start upowerd.service, I manually started upower.service (there is no upowerd.service unit, but that seems to be the case for all of the services that KDE starts. Not sure how that works).
Log output: https://0x0.st/o9jj.txt
dmesg output: https://0x0.st/o9je.txt
Here is a list of all installed packages: https://0x0.st/o9jM.txt
Here are my kernel parameters: https://0x0.st/o9ju.txt
Hopefully this helps. Happy to do any other debugging, but out of my element at this point, so might need a nudge in the right direction.
Sorry for my rant last night. Definitely not your problem, and I appreciate the assistance.
Offline
[ 55.022781] psp set.
[ 55.022785] BUG: kernel NULL pointer dereference, address: 0000000000000000
[ 55.022842] #PF: supervisor instruction fetch in kernel mode
[ 55.022883] #PF: error_code(0x0010) - not-present page
[ 55.022921] PGD 0 P4D 0
[ 55.022943] Oops: 0010 [#1] PREEMPT SMP NOPTI
Referencing the patch https://bbs.archlinux.org/viewtopic.php … 9#p2052909
I think the code reaches https://github.com/torvalds/linux/blob/ … sfs.c#L284 and the dereference is inside power_supply_get_property.
Edit:
Possibly psy->desc is null https://github.com/torvalds/linux/blob/ … re.c#L1055
diff --git a/drivers/power/supply/power_supply_core.c b/drivers/power/supply/power_supply_core.c
index 470253c337c7..4c8b6f52f78e 100644
--- a/drivers/power/supply/power_supply_core.c
+++ b/drivers/power/supply/power_supply_core.c
@@ -1046,6 +1046,7 @@ int power_supply_get_property(struct power_supply *psy,
enum power_supply_property psp,
union power_supply_propval *val)
{
+ pr_info("psy ptr %px, psy->desc ptr %px.\n",psy,psy->desc);
if (atomic_read(&psy->use_cnt) <= 0) {
if (!psy->initialized)
return -EAGAIN;
diff --git a/drivers/power/supply/power_supply_sysfs.c b/drivers/power/supply/power_supply_sysfs.c
index 4239591e1522..654ff26de54f 100644
--- a/drivers/power/supply/power_supply_sysfs.c
+++ b/drivers/power/supply/power_supply_sysfs.c
@@ -273,15 +273,22 @@ static ssize_t power_supply_show_property(struct device *dev,
struct device_attribute *attr,
char *buf) {
ssize_t ret;
+ pr_info("dev ptr %px, attr ptr %px.\n",dev,attr);
struct power_supply *psy = dev_get_drvdata(dev);
+ pr_info("psy ptr %px.\n",psy);
struct power_supply_attr *ps_attr = to_ps_attr(attr);
+ pr_info("ps_attr ptr %px.\n",ps_attr);
enum power_supply_property psp = dev_attr_psp(attr);
+ pr_info("psp set.\n");
union power_supply_propval value;
if (psp == POWER_SUPPLY_PROP_TYPE) {
+ pr_info("psp == POWER_SUPPLY_PROP_TYPE.\n");
value.intval = psy->desc->type;
} else {
+ pr_info("psp != POWER_SUPPLY_PROP_TYPE.\n");
ret = power_supply_get_property(psy, psp, &value);
+ pr_info("power_supply_get_property return %zx.\n",ret);
if (ret < 0) {
if (ret == -ENODATA)
@@ -302,13 +309,16 @@ static ssize_t power_supply_show_property(struct device *dev,
switch (psp) {
case POWER_SUPPLY_PROP_USB_TYPE:
+ pr_info("psp == POWER_SUPPLY_PROP_USB_TYPE.\n");
ret = power_supply_show_usb_type(dev, psy->desc,
&value, buf);
break;
case POWER_SUPPLY_PROP_MODEL_NAME ... POWER_SUPPLY_PROP_SERIAL_NUMBER:
+ pr_info("psp == POWER_SUPPLY_PROP_MODEL_NAME ... POWER_SUPPLY_PROP_SERIAL_NUMBER.\n");
ret = sprintf(buf, "%s\n", value.strval);
break;
default:
+ pr_info("psp default case.\n");
ret = sprintf(buf, "%d\n", value.intval);
}
https://drive.google.com/file/d/1UKVCeb … sp=sharing linux-5.19.2.arch1-2.5-x86_64.pkg.tar.zst
https://drive.google.com/file/d/1EvqRqa … sp=sharing linux-headers-5.19.2.arch1-2.5-x86_64.pkg.tar.zst
Last edited by loqs (2022-08-23 21:11:50)
Offline
Does that mean that the kernel code should check for the null, or that the hardware is incorrectly failing to provide the value?
Offline
Does that mean that the kernel code should check for the null, or that the hardware is incorrectly failing to provide the value?
Not familiar with the code that fills in struct power_supply *psy to say. This is assuming that is the issue, hopefully the additional diagnostics will show that.
Offline
Sorry if I've misunderstood, but just to be clear, I couldn't use the machine with the patched kernel. The boot froze at the "unrecognized JEDEC id". I could get a terminal session, but the network was dead and I couldn't launch the display manager. I manually started the service that causes the issue in the log above in the hopes that it was outputting additional useful info, but if there are additional diagnostics to perform, I don't know how to proceed.
I don't want to take up too much of your time if this seems like an issue specific to my machine... for all I know, it's a defective unit. If this is something that's affecting a wider audience (e.g. the other linked thread), I'm happy to provide any additional details I can. If not, though, I'll start the process of returning it.
Offline
The boot froze at the "unrecognized JEDEC id".
Are you booting from a flash drive? Or is a flash drive in your fstab?
You probably ended in the rescue shell.
Online
No, no usb. I just did pacman -U with the patched kernel, then rebooted. I went back and forth between it and the original one from the pacman cache to make sure I got the logs above without any extraneous junk in them, but the patched version consistently had the boot issue.
The fstab is exactly as generated by archinstall. I have an nvme drive, where I left the original EFI partition alone and made the rest of the disk a single luks encrypted '/' partition with the arch installation.
# Static information about the filesystems.
# See fstab(5) for details.
# <file system> <dir> <type> <options> <dump> <pass>
# /dev/mapper/ainstnvme0n1p2
UUID=557eee3e-b616-496f-b0ff-cf45eb18d039 / ext4 rw,relatime 0 1
# /dev/nvme0n1p1
UUID=A410-0A8F /boot vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro 0 2
Offline
It's more affiliated w/ SDCs, but probably from intel-spi and not fatal.
Do you have the actual message (in doubt link a photo) and the output of lspci (regardless from which kernel)
Do you have the quiet parameter around?
Remove that and add https://wiki.archlinux.org/title/Genera … bug_output "debug ignore_loglevel earlyprintk=vga,keep" instead for more fine-grained boot messages.
Online
I seem to have the same issue on my Thinkpad.
With the original kernel (most recent), I have lots of these Oopses, here are #1, #2, #3 and #21
https://0x0.st/o93b.txt
With a patched kernel (using your patch from above, but the most recent kernel version), I had one Oops so far:
https://0x0.st/o93c.txt
Will post once more come in.
Thanks for looking into this and please let me know if you need any additional info.
EDIT: It seems I can trigger this with:
sudo systemctl restart upower.service
This is what I get then: https://0x0.st/o93m.txt
Note that after none of these my laptop really crashed / got stuck. That did happen about once every day however, but not with the patched kernel so far.
Last edited by KloolK (2022-08-25 08:34:47)
Offline
Hello! I think this bug report may be a variation on the same kernel bug: https://bugs.archlinux.org/task/75666
Have you tried to boot the system with live media and downgrade the kernel (and any GPU driver(s) that may depend on a specific kernel version)?
"There's a special place in hell...
... reserved for child molesters and people who talk in the theater."
-- Shepherd Meriah Book, "Firefly"
Offline
If it is a kernel regression can someone affected please test the kernel from https://bbs.archlinux.org/viewtopic.php … 3#p2052293 if that has the issue then try the kernels from that thread from in order #15 #17 #19 #27 #29
Offline
Hello! I think this bug report may be a variation on the same kernel bug: https://bugs.archlinux.org/task/75666
Have you tried to boot the system with live media and downgrade the kernel (and any GPU driver(s) that may depend on a specific kernel version)?
Thanks for the link. As you can see below, the older kernel works, yes.
If it is a kernel regression can someone affected please test the kernel from https://bbs.archlinux.org/viewtopic.php … 3#p2052293 if that has the issue then try the kernels from that thread from in order #15 #17 #19 #27 #29
These are my results:
#13
linux-5.19-1-x86_64.pkg.tar -> issues
Linux arch-esr-2399 5.19.0-1 #1 SMP PREEMPT_DYNAMIC Wed, 17 Aug 2022 14:08:33 +0000 x86_64 GNU/Linux
#15
linux-5.18.r7905.gc011dd537ffe-1-x86_64.pkg.tar -> no issues
Linux arch-esr-2399 5.18.0-1-07905-gc011dd537ffe #1 SMP PREEMPT_DYNAMIC Wed, 17 Aug 2022 16:14:52 +0000 x86_64 GNU/Linux
#17
linux-5.18.r4943.g7e062cda7d90-1-x86_64.pkg.tar -> no issues
Linux arch-esr-2399 5.18.0-1-04943-g7e062cda7d90 #1 SMP PREEMPT_DYNAMIC Wed, 17 Aug 2022 18:18:30 +0000 x86_64 GNU/Linux
#19.1
linux-5.18.r2404.g3842007b1a33-1-x86_64.pkg.tar -> no issues
Linux arch-esr-2399 5.18.0-1-02404-g3842007b1a33 #1 SMP PREEMPT_DYNAMIC Wed, 17 Aug 2022 19:39:51 +0000 x86_64 GNU/Linux
#27
linux-5.18.r1199.g22922deae13f-1-x86_64.pkg.tar -> no issues
Linux arch-esr-2399 5.18.0-1-01199-g22922deae13f #1 SMP PREEMPT_DYNAMIC Sat, 20 Aug 2022 09:40:50 +0000 x86_64 GNU/Linux
#29
linux-5.18.r593.g03e1ccd45fa7-1-x86_64.pkg.tar -> no issues
Linux arch-esr-2399 5.18.0-1-00593-g03e1ccd45fa7 #1 SMP PREEMPT_DYNAMIC Sat, 20 Aug 2022 11:09:52 +0000 x86_64 GNU/Linux
I guess it's a different issue then?
I will try to find the time for a bisect today. Should I bisect between #13 (bad) and #15 (good) or any other commits?
Offline
I guess it's a different issue then?
Yes.
I will try to find the time for a bisect today. Should I bisect between #13 (bad) and #15 (good) or any other commits?
$ git bisect start
$ git bisect bad v5.19
$ git bisect good v5.18
Bisecting: 8493 revisions left to test after this (roughly 13 steps)
[c011dd537ffe47462051930413fed07dbdc80313] Merge tag 'arm-soc-5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
$ git bisect good
Bisecting: 4244 revisions left to test after this (roughly 12 steps)
[5d4af9c1f04ab0411ba5818baad9a68e87f33099] Merge branch 'mv88e6xxx-fixes-for-reading-serdes-state'
https://drive.google.com/file/d/1L8Yffw … sp=sharing linux-5.18.r12154.g5d4af9c1f04a-1-x86_64.pkg.tar.zst
https://drive.google.com/file/d/1h8A80n … sp=sharing linux-headers-5.18.r12154.g5d4af9c1f04a-1-x86_64.pkg.tar.zst
Offline
https://drive.google.com/file/d/1L8Yffw … sp=sharing linux-5.18.r12154.g5d4af9c1f04a-1-x86_64.pkg.tar.zst
https://drive.google.com/file/d/1h8A80n … sp=sharing linux-headers-5.18.r12154.g5d4af9c1f04a-1-x86_64.pkg.tar.zst
Linux arch-esr-2399 5.18.0-1-12154-g5d4af9c1f04a #1 SMP PREEMPT_DYNAMIC Fri, 26 Aug 2022 13:15:13 +0000 x86_64 GNU/Linux
good
Offline
git bisect good
Bisecting: 2122 revisions left to test after this (roughly 11 steps)
[7a68065eb9cd194cf03f135c9211eeb2d5c4c0a0] Merge tag 'gpio-fixes-for-v5.19-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux
https://drive.google.com/file/d/1-Q2dgh … sp=sharing linux-5.19rc1.r303.g7a68065eb9cd-1-x86_64.pkg.tar.zst
https://drive.google.com/file/d/1z0ez51 … sp=sharing linux-headers-5.19rc1.r303.g7a68065eb9cd-1-x86_64.pkg.tar.zst
Offline
git bisect good Bisecting: 2122 revisions left to test after this (roughly 11 steps) [7a68065eb9cd194cf03f135c9211eeb2d5c4c0a0] Merge tag 'gpio-fixes-for-v5.19-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux
https://drive.google.com/file/d/1-Q2dgh … sp=sharing linux-5.19rc1.r303.g7a68065eb9cd-1-x86_64.pkg.tar.zst
https://drive.google.com/file/d/1z0ez51 … sp=sharing linux-headers-5.19rc1.r303.g7a68065eb9cd-1-x86_64.pkg.tar.zst
Linux arch-esr-2399 5.19.0-rc1-1-00303-g7a68065eb9cd #1 SMP PREEMPT_DYNAMIC Fri, 26 Aug 2022 14:53:36 +0000 x86_64 GNU/Linux
bad
Offline
git bisect bad
Bisecting: 1091 revisions left to test after this (roughly 10 steps)
[54c2cc79194c961a213c1d375fe3aa4165664cc4] Merge tag 'usb-5.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
https://drive.google.com/file/d/1rkwIw1 … sp=sharing linux-5.18.r13138.g54c2cc79194c-1-x86_64.pkg.tar.zst
https://drive.google.com/file/d/1j47nlt … sp=sharing linux-headers-5.18.r13138.g54c2cc79194c-1-x86_64.pkg.tar.zst
Offline