You are not logged in.
My problem is that my Dell Inspiron NVIDIA system is using bumblebee and bbswitch to turn off the nvidia card when it is not in use.
However, I would notice a delay of approximately 1m15sec when starting the XOrg server from my login manager *while on laptop battery*.
When it is connected to a power source, the XOrg sever starts very quickly, in a couple of seconds.
Please note that when I disabled bumblebeed.service, this delay was not encountered when booting up on battery!
After reaching the two forum topics below, I was able to determine the problem was the bbswitch and bumblebee software would turn off the nvidia card when the laptop was started on battery, and for some reason XOrg would wait for "pci 0000:01:00.0" (nvidia card) for a long long time before giving up.
https://bbs.archlinux.org/viewtopic.php?id=286976
https://bbs.archlinux.org/viewtopic.php?id=236922
jan 01 14:48:02 archhost kernel: pcieport 0000:00:1c.0: broken device, retraining non-functional downstream link at 2.5GT/s
jan 01 14:48:02 archhost kernel: psmouse serio1: Failed to deactivate mouse on isa0060/serio1: -5
jan 01 14:48:03 archhost kernel: psmouse serio1: Failed to enable mouse on isa0060/serio1
jan 01 14:48:03 archhost kernel: pcieport 0000:00:1c.0: retraining failed
jan 01 14:48:04 archhost kernel: pcieport 0000:00:1c.0: broken device, retraining non-functional downstream link at 2.5GT/s
jan 01 14:48:05 archhost kernel: pcieport 0000:00:1c.0: retraining failed
jan 01 14:48:05 archhost kernel: pci 0000:01:00.0: not ready 1023ms after resume; waiting
jan 01 14:48:06 archhost kernel: pci 0000:01:00.0: not ready 2047ms after resume; waiting
[...]
jan 01 14:48:21 archhost kernel: pci 0000:01:00.0: not ready 16383ms after resume; waiting
jan 01 14:48:38 archhost kernel: pci 0000:01:00.0: not ready 32767ms after resume; waiting
jan 01 14:49:12 archhost kernel: pci 0000:01:00.0: not ready 65535ms after resume; giving up
jan 01 14:49:12 archhost kernel: pci 0000:01:00.0: Unable to change power state from D3cold to D0, device inaccessible
jan 01 14:49:13 archhost kernel: pcieport 0000:00:1c.0: Data Link Layer Link Active not set in 1000 msec
jan 01 14:49:13 archhost kernel: pci 0000:01:00.0: Unable to change power state from D3cold to D0, device inaccessible
jan 01 14:49:14 archhost kernel: pci 0000:01:00.0: Unable to change power state from D3cold to D0, device inaccessibleFull journals of the energy cable boot and the battery boot follow below.
On energy boot journal:
https://pastebin.com/fTK6Fxvu
On battery boot journal:
https://pastebin.com/AVku9hyw
Is that some sort of a problem? Can't the Xorg wait less on the "pci 0000:01:00.0" (nvidia card) process or give up when it is not available?
Last edited by lilikoi (2024-01-03 03:39:07)
Offline
Please post your Xorg log, https://wiki.archlinux.org/title/Xorg#General
Neither journal shows the nividia device being used anywhere (the PCI device shows up, bbswitch suggests it's on, 'nvidia_uvm' is deny-listed (by kmod) and the journal on battery has
jan 01 14:48:05 archhost kernel: pci 0000:01:00.0: not ready 1023ms after resume; waiting
jan 01 14:48:06 archhost kernel: pci 0000:01:00.0: not ready 2047ms after resume; waiting
jan 01 14:48:08 archhost kernel: pci 0000:01:00.0: not ready 4095ms after resume; waiting
jan 01 14:48:13 archhost kernel: pci 0000:01:00.0: not ready 8191ms after resume; waiting
jan 01 14:48:21 archhost kernel: pci 0000:01:00.0: not ready 16383ms after resume; waiting
jan 01 14:48:38 archhost kernel: pci 0000:01:00.0: not ready 32767ms after resume; waiting
jan 01 14:49:12 archhost kernel: pci 0000:01:00.0: not ready 65535ms after resume; giving up
jan 01 14:49:12 archhost kernel: pci 0000:01:00.0: Unable to change power state from D3cold to D0, device inaccessible
jan 01 14:49:13 archhost kernel: pci 0000:01:00.0: Unable to change power state from D3cold to D0, device inaccessible
jan 01 14:49:14 archhost kernel: pci 0000:01:00.0: Unable to change power state from D3cold to D0, device inaccessible
jan 01 14:49:48 archhost kernel: pci 0000:01:00.0: Unable to change power state from D3cold to D0, device inaccessible
jan 01 14:49:48 archhost kernel: pci 0000:01:00.0: Unable to change power state from D3cold to D0, device inaccessible
jan 01 14:49:48 archhost kernel: pci 0000:01:00.0: Unable to change power state from D3cold to D0, device inaccessible
jan 01 14:49:48 archhost kernel: pci 0000:01:00.0: Unable to change power state from D3cold to D0, device inaccessible
jan 01 14:49:52 archhost kernel: pci 0000:01:00.0: Unable to change power state from D3cold to D0, device inaccessible
jan 01 14:49:52 archhost kernel: pci 0000:01:00.0: Unable to change power state from D3cold to D0, device inaccessible
jan 01 14:49:52 archhost kernel: pci 0000:01:00.0: Unable to change power state from D3cold to D0, device inaccessible
jan 01 14:49:52 archhost kernel: pci 0000:01:00.0: Unable to change power state from D3cold to D0, device inaccessiblebut battery or AC, the nvidia GPU is never in actual use.
Offline
seth,
below are the user Xorg logs. i could not find anything of much relevance in their diff.
AC Xorg:
https://pastebin.com/VqZJXUPF
Battery Xorg:
https://pastebin.com/LEDcCVv8
i dont use the nvidia card often, and i am thinking about just disabling bumblebeed for now. but it would be good to have the nvidia card set to OFF when the laptop is using battery, so that is why it would be good to have bumblebeed and bbswitch working, as per my best thinking.
Offline
There's an /etc/X11/xorg.conf but apparently it's empty?
I'd expect bumblebee to write configs for the desired setup and steer the server away from unused devices?
W/ the skylake HD 520 and bumblebee, you might (idk, you'll have to try) be better off w/ xf86-video-intel and mesa-amber.
Also add "nvidia_drm.modeset=1" to the kernel parameters to avoid the simpledrm device and get the IGP as dri/card0
Offline
I see TLP in the journal, configure
RUNTIME_PM_DISABLE="01:00.0"in your /etc/tlp.conf to leave handling of this up to bbswitch/bumblebee.
Offline
OK, I did a pre-eliminary test on the systems and gosh dont you rock so much?!
I applied for all directions, and *now the system seems* to work as expected with bumblebee enabled.
What seems to have made the bigger change was Mr. V1del suggestion to add that line to the TLP config,
as well as seth pondering on the kernel settings and the empty (commented out) file, which seems really justifiable!
i will try the driver suggestion later on at a more leisurely time, thanks ,seth!
Last edited by lilikoi (2024-01-03 03:56:12)
Offline