Could you write into support and provide us a minidump?
We would like to try and gather more data about this issue.
1 Like
For those affected by the wakes from suspend when attached to power, we still have this in the Fedora docs.
sudo sh -c '[ ! -f /etc/udev/rules.d/20-suspend-fixes.rules ] && echo "ACTION==\"add\", SUBSYSTEM==\"serio\", DRIVERS==\"atkbd\", ATTR{power/wakeup}=\"disabled\"" > /etc/udev/rules.d/20-suspend-fixes.rules'
This checks for an existing /etc/udev/rules.d/20-suspend-fixes.rules file, if none is found, creates it and appends ACTION==“add”, SUBSYSTEM==“serio”, DRIVERS==“atkbd”, ATTR{power/wakeup}=“disabled” to the file.
2 Likes
This hasn’t happened since that time, and I unfortunately had memory dumps disabled at the time. I since have turned them back on in Windows and will definitely submit a support ticket if I see it again.
I don’t know where to ask or whether I should contact support. I recently discovered some minor problem with the PD charging. This problem appears to persist before and after the BIOS/embedded controller update.
- When booting up(not restart), the PD charging input will momentarily off right upon pressing the power button before resuming to 20V(or whatever your power brick is doing). Only the FW13 AMD has this problem (IDK whether Intel versions have it too as I don’t have one).
- If the computer is switched off(not suspended) for half a day or longer, it won’t charge immediately when plugged in USBC PD, the LED is white and the current flow is 0A. You’ll have to wait for several minute before the current goes to positive and LED turns red.
Other users also discovered the problem, as shown here
1 Like
Mine does that too, but a lot of laptops renegotiate PD when powering up so it’s not that weird.
Yeah I have the same issue, it repeats that message every 2 seconds. Removing & reinserting the front right expansion card stops it until the next reboot. Setting ‘echo "on" > /sys/bus/pci/devices/0000\:c1\:00.3/power/control’ also works.
I’m running BIOS 3.05, kernel 6.8.5, with a USB A expansion card in the front right slot.
1 Like
Reporting from Kubuntu 24.04 (6.8.0-22-generic). I had these issues still with kernel 6.8 before the update (different from @Michael_Marley - not sure why, but I’m using KDE Plasma + Wayland + two external 4k displays).
So far everything looks good with sg_display=0 removed here too. I’ve done all the usual things that would trigger it and haven’t been able to replicate except for having it up and running for several days and adding/removing the monitors multiple times during that. (But I have added/removed monitors, slept/woken in different monitor states, etc.) I’ll report back if that changes, but we seem to be having joy here. 
FOLLOW-UP
After a weekend of running around with my laptop, all still seems to be good here, so this update may well have solved the sg_display issue!
I also have a the following configuration.
c || c <- charged from here for bios update
c || a
I’ve noticed today that the back right c port does not charge randomly after resuming from suspend.
The value at that location is currently auto. Curious, could you recommend an easy way to tell which port on the computer correlates to each pci address?
I’ve got:
C || C
A || A
I can’t reproduce this, but the back right is the port I usually use to charge, so I’m sure I’ll see it eventually.
auto just means that power management is handled by the kernel (the default), on means auto power management is disabled (forced on).
I originally used trial and error, e.g removed everything until the errors stopped. But lsusb -v does report the PCI address via the iSerial descriptor, so I mapped them out:
c3:00.4 || c3:00.3
c1:00.3 || c1:00.3
Which is interesting considering the front left and right are on the same bus, but only the right side will produce the error.
1 Like
I went from 3.03b to 3.05 and I thought that I’m having the same issue, but worse, since I’m using the power-on password. However I managed to figure out that it was one of the two or three passwords that I ended up rotating between (when the password expired), so I ultimately was able to continue booting.
The BIOS reset with the switch did not reset the BIOS for me - or the password. I have now tried it three times. Is this the switch?
No, that’s the “case open” (intrusion detection) switch. You’ll have to disconnect the power and battery for 30s or so.
What does Z-state mean (specifically for Windows 11)?
I tested with the notebook off and with the expansion card removed, I still am unable to charge from the back right port (#3 from the guide).
Starting to wonder if it’s an issue with either the bios, or maybe the firmware for that controller wasn’t updated in lock step with the bios firmware?
Does anyone have any advice on the matter?
Huh? are they really both on the same port ???
‘Port’ is a little ambiguous here, they’re both on the same USB controller, which is totally normal and isn’t something to be concerned about.
But shouldn’t the last digit be different like the line above it?
Nah, because it’s the PCI address, not a USB address, and the same USB controller provides both ports (and also the fingerprint reader and bluetooth). AFAIK it’s actually fairly uncommon to have a whole controller dedicated to each port like the ones above, although USB4 is probably the reason why the back 2 ports each have their own controller.
Fedora has started offering me what appears to be this update and a fingerprint reader firmware update unprompted. Is there any particular reason at this date not to just go ahead and let it install them, or is the process still buggy?
Still having issues charging via my usb port on this firmware.
I did find two dmesg errors that may be related:
[ 0.686734] usb usb5: SerialNumber: 0000:c3:00.3
[ 0.686853] hub 5-0:1.0: USB hub found
[ 0.686862] hub 5-0:1.0: 1 port detected
[ 0.687374] usb usb6: We don't know the algorithms for LPM for this host, disabling LPM.
[ 0.687391] usb usb6: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 6.08
[ 0.687393] usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.687394] usb usb6: Product: xHCI Host Controller
[ 0.687395] usb usb6: Manufacturer: Linux 6.8.4-300.fc40.x86_64 xhci-hcd
[ 0.687396] usb usb6: SerialNumber: 0000:c3:00.3
This does match up with the hardware address mentioned in Steve Tech’s post above
Some other potential related errors:
cros_ec_lpcs cros_ec_lpcs.0: EC ID not detected
ucsi_acpi USBC000:00: ucsi_handle_connector_change: ACK failed (-110)
1 Like
For anyone running F40 nighties/beta - the bug is still present also as libxmlb which needs to be 0.3.18 isn’t pushed to testing (0.3.17) and the 0.3.15 available is also bugged