That’s the normal behavior because zypper/rpm has not inserted a key of Malcolms Repo in the database.
That’s the behavior for all downloaded packages without having added the key to zypper/rpm.
So ignore it.
@Cyclonick what @Sauerland said, so in your project add Tumbleweed at the top level, build the package and publish and add your own repo 
@Sauerland should have some extra tips to clean it up as he creates kmp’s, mine is just a quick fix…
I don’t understand a word of this or how to build a package…
I don’t want to publish anything or have it findable (unless it’s strictly necessary to get the bloody thing working)
Add the Repo:
zypper ar -f https://download.opensuse.org/repositories/home:/Cyclonick/openSUSE_Tumbleweed/ cyclonick
Install the package:
zypper in xhci-pci-kmp-default
Ok, I think I’m beginning to understand - I’ll try tomorrow - there’s something of a ritual getting the new one working.
@Sauerland 's instructions worked - for which many thanks
I no longer get the original message but boot still hangs and I get the command line - in 3mm sized text (high dpi - why am I not surprised?)
Using recovery mode I find it is still hanging at the loading of amdgpu (which it is where it stopped before) too small to read any more.
I’m going to try and record journalctl to a stick using the script command.
a) try video=1024x768 kernel parameter (use whatever resolution you prefer)
b) try setting larger font with vconsole.font kernel parameter. E.g. I use LatGrkCyr-12x22. Available fonts are in /usr/share/kbd/consolefonts/. The largest seems to be latarcyrheb-sun32.psfu.gz.
I did three runs of journalctl I’ve broken the script into 3 files, one for each run…
but I can’t upload them.
What types of files can you upload here ?
I think the kernel problem has been resolved - but there seems to be a problem with amdgpu. Someone with more knowledge than me (doesn’t take much) needs to look.
I wonder if there isn’t a problem of the kernel handing the gpu to systemd (if that isn’t stupid)
OK, I’ve found out what to do now
File 1 is at https://paste.opensuse.org/pastes/1b6fbc335f6d - the command was journalctl -p 0…6 -x -b
File 2 is at https://paste.opensuse.org/pastes/803bd886f9b2 - the command passed was journalctl -k -b
File 3 is at https://paste.opensuse.org/pastes/81d243f37404 - the cammand was journalctl -r -b… so it’s backwards
I didn’t know what would be useful so I used a how to page…
Looking at file 3 - the backwards one - just before it says it has lost control of “IRQ balance” whatever that means. I don’t think it is amdgpu after all.
As far as I can ascertain the patch and @malcolmlewis 's kmp have worked - all the usbs seem to be enumerated and configured as usb3 or usb2 (no mention of usb3 was one of the things remarked on in the kernel bug site)
I realise unfiltered results from journalctl are completely indigestible so would be happy to follow instructions for better results.
Can you try to boot with “nomodeset” without quotes at grub?
I can try ! I think I know what to do.
Once in, what am I looking for, what commands should I run - using the “script” command on a stick is effective way of recording any info (better than me trying to interpret or take a photo anyway !
I don"t know if this is pertinent but this happens with 10 IRQ’s and then the system seems to clean up and stop, leaving a command line prompt
Jul 06 18:29:16 localhost.localdomain irqbalance[932]: e[0;1;38:5:185me[0;1;39me[0;1;38:5:185mIRQ 47 affinity is now unmanagede[0m
Jul 06 18:29:16 localhost.localdomain irqbalance[932]: e[0;1;38:5:185me[0;1;39me[0;1;38:5:185mCannot change IRQ 47 affinity: Permission deniede[0m
I think the video is configured and ready to go, then this upsets things
The title says “blocks booting”. If your system reaches command line prompt, booting is most certainly not blocked.
Anyway, your original question (how to build driver with the patch) was answered. You apparently have now different problem and you better start new topic with clear title and problem description.
1 Like
I will do - if I can get an idea what the problem is.
If I’d known this was a new chipset, I wouldn’t have bought the bloody thing.
I would like confirmation from more knowledgeable people than I that the patch has worked so I can report, with confidence, to the kernel devs that it is a working solution
(and for someone with my skillset - = 0 - to wind up with a command line prompt is to be blocked !)
@Sauerland
Managed to boot with nomodeset
boot crashed with
localhost kernel: e[0;1;31me[0;1;39me[0;1;31mamdgpu 0000:0c:00.0: probe with driver amd
gpu failed with error -22e[0m
I think I managed to damage the stick with my amateur manipulations… characters aren’t showing properly.
I did “journalctl -p 2…4 -xb” and the result is here https://paste.opensuse.org/pastes/f3c968016d69
I’ve just had a thought about those IRQ’s that systemd cannot access and therefore not control…
What if
they correspond to the USBs that are linked to the virtual hub… the patch has exposed the USB’s to the system but not given access…
A : Is this possible?
B : How do I test ?
@Cyclonick It’s shouldn’t, udev should just enumerated the devices found. As indicated, this is a different issue now and best start a new thread.
Off to start a new thread.
Many thanks to @malcolmlewis and @Sauerland for their help (it may well be needed again !)