Testing USB4 and Mainline kernel
I am creating this help thread so @antheas can help me step through setting up EndavourOS w/ the mainline kernel. This is to test my USB4 Egpu and LeGo's sleep/wake failures.
104 Replies
you have endeavor os?
how many logical cores do you have?
I just got it installed nad booting into
I got the Z1E should be 8 Cores/16 Threads
wget https://git.kernel.org/torvalds/t/linux-6.12-rc4.tar.gz
and extract it somewhereI got the archvie downloaded and extracted
Want me to run a
make -j 8
?no
first, plug in everything you will want to use
second
make localmodconfig
then make random choices
make pacman-pkg -j 16
then finally this which will spit the kernel
sudo pacman -U
linux-upstream and if you have dkms linux-headers-upstream
thats it
should take around 5-10mingot it
also reconfigure grub to see linux-upstream so you can boot it
(i dont have the command with me for that)
I'll figure out the arch bits
I have to step out for a bit, let me get back to you in a couple of hours π
i will be asleep in 4 hours
Got it, let me get the build going
BTW my USB4 enclosure should be connected, right?
before running localmodconfig
after that it doesnt matter
otherwise anything needed to run it wont be built
It looks like the thunderbolt/usb authorization is not popping up π¦
you might need to install a package
connect it first,
make it crash
then, connect it again and reboot
run localmodconfig and compile the kernel
got it
I just needed the plasma-thunderbolt aur package, let me get the build going now
I don't the upstream package exists for the 6.12 rc4 kernel
the way i told you is faster
there is no prebuilt 6.12 rc4
building the full arch config take 45min
I mean this is what I am getting when I run
make pacman-pkg -j 16
:
I am an idiot, let me look at the missing depednency π
yeah depenencies is the one thing i cant help with
did it once and was over with
All good, it's going after a installing
bc
This is going to take a while so see you in an hour or so loli told you it takes 5-10 min if you do localmodconfig
(I have to head back to work π¦ )
in my OXP X1 making a config for the Ally X it takes 2-4min
after doing a build or something i think
Gotcha, I'll wait for the build to finish
BTW the localmodconfig took < 1 min on my device
that just makes a config
So
sudo pacman -U linux-upstream
will install the built packageyea
uname -r to check after you reboot
well you need the filename
full filename for it
just press tab
π
I'll be back in an hour or so, need to head back to work π
@antheas It got built lol
Do you know doing
sudo pacman -U linux-upstream
says that the package is not foundi told you full file name
it has a bunch of stuff after upstream
hit tab
Gotcha, sorry I am bouncing three computers
I got the 6.12 kernel booted but it's stuck at looking for non-existent drivers π¦
something something localmodconfig will only capture what was in your system
if you want to wait an hour for the full kernel
Got it, it's probably my thunderbolt encolsure's external SSD
rm .config
I'll re-configure and build again without the SSD installed
zcat /proc/config.gz > .config
or yea do that
unplug the ssd
seems like its fstab
the build will take 45m if you run the commands i sentUgh got it, I'll run the longer build, hold on
I got the big kernel built
@antheas The sleep/wake works just fine on the latest 6.12 rc4 kernel
Multiple times in a row
ok jump on bazzite unstable then, with a fresh kernel that fixes my issue
and check out if it sleeps there too
will do, I need another few mins to switch over to there
I will
I'll continue to play around with the 6.12 kernel few more times
Ny sample size of 4-5 sleep/wake cycles is a bit small π
I also have no luck with Bazzite unstable π¦
It seems to not wake successfully
Did you try endeavor os stock kernel?
And uname -r it?
It was running 6.12 rc4 when on Endeavour when it was working
Do you want me to run the stock 6.11 kernel?
Use the Linux package
Uname -r should say 6.11.4
Will do, let me get a Google Sheet doc going to write out the test cases here
If it doesn't work we're cookrd
π
@antheas The package should be
linux-mainline
?Just Linux
If it does work we're cooked I mean
If it doesn't it's Mario's problem
Got it
My egpu and sleep/wake works on the default 6.11.4-arch2-1 kernel π
Rip
Was it ever broken?
In endeavor
I think I never tested the 6.11 kernel on Endeavour
What's the stock one
Stock would be the 6.11 kernel no?
You never tested the built in kernel?
*The built-in kernel is
6.11.4-arch2-1
, this worksSo everything works in endeavoros?
Did you find a broken kernel there?
No, not thus far, everything works
it looks like Bazzite has a breaking change π¦
Did you sleep bazzite in kde or gamemode?
It's flaky in gamemode/gamescope, let me re-test on KDE
I thought you did kde
I am unsure now, let me re-test this a few more times
Does bazzite work rn?
In kde
I am hopping b/w work and Discord, let me follow up in 5 mins
It works on stable, but it freezes after a few times
Few times being, where I repeatedly and consecutively sleep/wake the device. It failed on the 3rd try
Try unstable also
That's kind of expected if you don't wait at least 10 seconds
You will probably find endeavoros is the same
Yep, I noticed that too
So we're back at the question of whether it ever worked
At least we figured out the test cases, let me go through it out all, this will take a bit
You can't run gamescope in endeavoros and even if you can you're probably cooked
Because it won't work
Unless you wanna play with cachyos too
Although there everything is lto fancy compiled
And everything is broken
It's probably gamescope tbh
I don't want to spend more time going down the rabbit hole π
It looks like so
Tell Mario KDE works in bazzite too and to tell you how to get a log
And get one from unstable
I'll try to make some vanilla kernels
I am noticing the freezes on Bazzite stable build π¦
Well stable is an ancient kernel
Go to unstable it's better for now, other than the selinux issues
Classic fedora transition
Will do
I am able to reproduce the hard lock on unstable with the 6.11 kernel π¦
On kde
Yeah, I also waited 10s and repeated and reproduced across two boots
And on endeavor it's rock solid?
Let me re-test on Endeavour to be more certain
I am able to reproduce the hard lock on Endeavour w/ 6.11
I am also able to reproduce this on 6.12 rc4 too
What changed was I disabled the screen lock on sleep/wake π
I don't understand why that helped
Me neither π
I'll boot into Endeavour and attempt another round of testing
errr it's consisntently working now, I am going to say user error
It's hard to pin this down without logs
@antheas any chance I can just buy and donate to you a thunderbolt gpu enclosure?
with what gpu lmao i dont have space for it
its not user error
its inconsistent
you need logs to debug it
I'll reach out to Mario then
tell him gamescope is completely busted
and 6.11, 6.12, and bazzite 6.11 are equally semi-busted
anything particular than busted?
Honestly, I was hoping if you could supply your own GPU π
pray oxp gets interested and sends something
but for now lets fix these handhelds
I left a comment here, https://gitlab.freedesktop.org/drm/amd/-/issues/3706#note_2624298
GitLab
Hard lock with External GPU on sleep/wake cycle (#3706) Β· Issues Β· ...
Brief summary of the problem: My current device is a Lenovo Legion Go with an external GPU (egpu) connected over USB...
I got some logs π₯
nice
It looks like the device is inaccessible
The GPU is probably disconnected while the driver is being unloaded. Itβs probably a race condition?
seems like a series of errors i know nothing about
Iβll ask Mario upstream, thanks for the troubleshooting help
well since you tagged me im part of that conversation anyway
oh you have the fancy oxp gpu thats nice
Yeah, I just got it a few weeks back
oxp makes nice devices
x1 is better than the legion go, except its controllers
its controllers are kinda sad
I really wanted the X1 mini but it's like $1500-1800 CAD π
x1 mini i think has the screen of the legion go
or very similar
the big screen is the nice one
yeah and it has connector for a proper detachable keyboard
I am waiting for the new Strix point APUs
It looks like I found an upstream kernel bug
@antheas Is there an way for an end user like me to raise awareness on the Linux kernel bugzilla?
Do you know a kernel version where it works?
None as far as I can tell, I can roll some older kernels to troubleshoot (e.g. 6.5 to 6.8)
I also tried the eGPU on another device and I ran into the same error π¦
BTW it's an issue with the USB/TB kernel modules
@antheas I figured out a workaround for the crashes
I have to disable power management on the TB/USB4 ports
A quick systemd unit file:
Disconnecting the cable does cause the system to crash as before but itβs much more stable
@antheas I had to just unbind all my devices before suspend and it works really well
It's set up for my specific laptop and device
I'll try writing a script to unload all devices on the TB pcie tunnel
What do you meAn by really well
It works 100% of the time, I booted up my spare laptop with a Intel TB4 port
What the above unit file does is forces the driver to unbind from all the devices on the TB tree
In my case, I ran
lspci -tv
to get the tree view and unbinded the loaded modules from lspci -vv
Test scenario: I am running Arch 6.12 and 6.13 rc3 and it doesn't crash anymore
Devices are re-enumerated upon sleep too
So the eGPU comes back from wake/resume
Running lspci -tv
:
Running
lspci -vv
So what I did was unbind the child nodes from the tree view and unbounded the nodes from there
Basically, the respective driver's can't crash if they are not binded
What do you think?
I can write a quick Python script to generalize this π
Do they load correctly after is the question
And also if you unbjnd you lose the game
Do they load correctly after is the questionThey do
And also if you unbjnd you lose the gameYeah π¦ I say this is a lot better than a hard lock. I would much rather save and exit my game before suspend than it hard lock I honestly cannot think of any better way and my use case is connected to egpu, play for a bit, then stop I'll give it ago with my new Onexfly later It's working well on the Onexfly too @antheas
good to hear
also good news for you, oxp wants to look into eGPU
but first, holidays