Not all USB devices are recognized with the latest Fedora 33 kernels on old pc

Hello everyone:
I know that here exist previous reported cases or issues related with USB problems and Fedora 33. I’ve been trying to replicate the solutions and advices provided by others in some of these similar cases.
I think that my case, involving a relatively old BIOS and boot options, is different from the other ones, and not replicable or solvable by following the instructions given to others. :pensive:
My laptop doesn’t work properly with the newest Fedora 33 kernels. I’m using the KDE Spin.
From Kernel 5.8.15 onwards I have found the same issue with all of them. And the problem is the following:

Certain USB devices, mainly those that aren’t disk drives, aren’t recognized by the system even if they are physically connected to the laptop. These devices don’t appear anywhere.

What kind of devices works normally:

  USB external storage devices
  SD Cards

What devices don’t work: (e.g.)

    Mouse connected via USB.
    Cryptographic card reader. 

My computer is an ASUS F50SL, a 2009 laptop. I have always experienced incompatibilities and problems booting the system normally, which has forced me to introduce boot options into the kernel lines. Such as

nolapic, radeon, irqpoll.
I’m not very well versed in linux issues, and surely the options I choose are counterproductive or cause other problems.

Just yesterday, I discovered that my computer BIOS has a menu, and marking the locked option in that section, the boot option “Nolapic” was no longer necessary. And I could use at last, my Dual Core laptop with both operating cores. I am happy with this.

This option is in the path:

Security> I/O Interface Security> New Interface Card I selected: Locked instead of Unlocked which is what is marked by default.

I don’t really know what this function does.

I can’t find any warnings, alarms, or signals in the information resulting from the various terminal commands I’ve tried. And I can’t identify what the problem is or how to solve it.

Here is some technical information obtained through Terminal commands.

Dmesg Results

Lsusb with: Criptographic card reader, scanner and gaming mouse coneccted, but missing :frowning:

]$ lsusb
Bus 001 Device 012: ID 058f:6366 Alcor Micro Corp. Multi Flash Reader
Bus 001 Device 003: ID 04f2:b071 Chicony Electronics Co., Ltd 2.0M UVC Webcam / CNF7129
Bus 001 Device 013: ID 058f:6387 Alcor Micro Corp. Flash Drive
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

I hope someone can help me. Thanks in advance. :kissing_smiling_eyes:

Trying to replicate problems means you are trying to make your machine repeat others problems and that is never a good idea. You are trying to introduce a problem into something that does not have that particular issue.

All those devices specifically require the appropriate drivers to function, and may require bios support as well.

The mouse seems strange since the bios and OS have supported usb mice for a lot of years. Maybe that particular mouse has dropped dead. Does a different one work?

Obviously you have been asleep as long as you have been using computers if you did not even know there was a bios and how to get access to it. Usually users are (at least somewhat) familiar with bios on their PCs and are willing to try changes there one at a time to confirm if the results help or not. If not then reset it and try something else. Older PCs/laptops may also need the bios updated to support installed or connected hardware and OSes that are newer than the machine.

The first thing I would suggest is that you plug one of the devices that do not work into the USB port then look at the tail end of dmesg output and see if it is recognized. Also look at the output of “lspci -nn” and see if the device is recognized there. Finally, attempt to install the drivers for the device and get it working.

Once one is solved then work on the next device. Categorically saying “all these don’t work” is a way of saying “I don’t want to try and locate the problem”

If you post the output of the 2 commands above with specific questions we might be of more help.

Please @computersavvy, we are not all native English speaking people here. Maybe @hesiteus means that he is trying to replicate the solutions.
However, sometimes, personally, yes :blush: I try to replicate other people’s problems in order to help them.

He, there is no need to make these statements. Maybe @hesiteus didn’t never used a BIOS (there is no need to access the BIOS daily, moreover if all is working). There is always a first time for everyone! :sweat_smile:
Or again, there is a language issue.
So please let’s try to avoid unneeded comments. In an international community like this, there is always an high possibility to misunderstand the statements (questions and answers). So take a breath and focus on helping people, trying to interpreting the statements and to be patient and kind.



I’ll take this opportunity to remind everyone to be excellent to each other. Even if not intended, please read and re-read your statements to ensure that they may not in anyway hurt/offend people (who will often be from different cultures and with different levels of technical knowledge).

The code of conduct explains this well. Everyone please re-read it :slight_smile:

Remember, we are friends, so we speak to each other as friends :slight_smile:

Ok, lets start from the beginning…

Take each non-working peripheral at a time, connect and check as root user ‘journalctl -xe’ for any errors, go to the next peripheral.
Don’t use usb hubs because sometimes they don’t give the right voltage.

If you choose previous kernel versions, does these devices work? Try to remove the extra commands you set on grub and update the initramfs with dracut.


First of all, I appreciate so much the fact that you took the time to answer me.

It’s true that when writing in a language that is not your mother tongue, you may end using constructions that lead to confusion to real native speakers, and even more so; if I mistakenly paste the text from the translator.

So, I apologize to you; in the first place, and to the whole community for using text copied by using the touchpad directly from the translator, and the obvious language issue that have resulted from this.

Responding now to your quotations:

I mistakenly omitted certain words. I have tried to replicate the solutions provided by others in cases that seemed related or similar to mine, but without equivalent result. Replicating what served others hasn’t served to me. :blush:

I’m sorry I didn’t explain myself clearly enough.

When do these devices work?

Always. Devices I mentioned in the second list work perfectly fine; and have no physical or hardware failures.

How can I affirm this?

  • I tested them under different scenarios and conditions:
  • They have been tested in other S.Os, or Live Fedora sessions.
  • All of these devices have worked fine on prior Fedora versions. :slight_smile:
  • That is, they aren’t physically defective.
  • The devices that aren’t working properly now; are exclusively those ones mentioned in my second list. Nor the mentioned in the first list.

What things have I tried to affirm this?

  • Other operating systems.
  • Connecting the devices that cause problems in other devices that have a USB connector
  • Connecting them in a Fedora “Live Session”.
  • I have used them until recently on Fedora 32 with no problems. (up to the last kernel updates) circumstance that caused me to migrate to Fedora 33.
  • I tried with other mouses and all of them seems to have the same issue in the below commented conditions.

When did they start to have problems?

  • On Fedora 32 using the latest kernels. I don’t remember which exactly one.
  • On Fedora 33, when upgrading to any kernel above 5.8.15.
    That is, any of the 5.8 and 5.9 series except the 5.8.15 one.
  • Works with Fedora 33 only when newly installed, not after the first kernel update.

All this leads me to conclude that:

Devices are physically fine.
USB connectors are physically fine, since they even allow (in Fedora 33 with modern kernels) me connecting mass storage devices, without problems or smartphones.

The issue, I guess, could be related, in any way, to the new kernels and my PC, the BIOS configurations, or “Boot options” I set. they are.—> “radeon” “irqpoll”.

The dmesg results provided in my previous post have been obtained using kernel 5.9.13. Obviously the devices do not work normally under this kernel.
I do not see any alert or warning that has allowed me to narrow down the problem in dmesg results exposed in my first post.

That’s the reason why I was commenting the changes made through boot options which I have incorporated to the kernel lines, guided by documentation, and different forum comments.
Also I was commenting the options marked in the BIOS… Merely in case it was useful for someone expert could limit the origin of the problem knowing these details.

It’s my fault I included a slightly unrelated “Dual Core-BIOS” topic

The problem with processor cores dates from 2017, and isn’t related to this problem that we are currently dealing with, which affects the specified USB devices as commented above.

By changing to “Locked” that cryptic BIOS option, I was able to avoid entering “nolapic” in the kernel lines. And that allowed my computer to start using both processor cores at the same time.

The comment was intended to express that I have recently made changes on BIOS
options. (unknown options for me)

Anyway,I don’t know if this BIOS option may affects the test results; but I can say you that the bug existed before and after needing “nolapic”.

Commented all the above, I proceed to carry out the suggested tests.


dmesg | tail
[ 407.372827] sd 4:0:0:0: Attached scsi generic sg2 type 0
[ 407.376593] sd 4:0:0:0: [sdb] Spinning up disk…
[ 408.394463] …ready
[ 409.419257] sd 4:0:0:0: [sdb] 488397168 512-byte logical blocks: (250 GB/233 GiB)
[ 409.420671] sd 4:0:0:0: [sdb] Write Protect is off
[ 409.420679] sd 4:0:0:0: [sdb] Mode Sense: 33 00 00 08
[ 409.421751] sd 4:0:0:0: [sdb] No Caching mode page found
[ 409.421758] sd 4:0:0:0: [sdb] Assuming drive cache: write through
[ 409.484027] sdb: sdb1 sdb2 sdb3
[ 409.487505] sd 4:0:0:0: [sdb] Attached SCSI disk>


~]$ lsusb
Bus 001 Device 004: ID 04f2:b071 Chicony Electronics Co., Ltd 2.0M UVC Webcam / CNF7129
Bus 001 Device 007: ID 152d:0567 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

~]$ lspci -nn
00:00.0 Host bridge [0600]: Silicon Integrated Systems [SiS] 671MX [1039:0671]
00:01.0 PCI bridge [0604]: Silicon Integrated Systems [SiS] PCI-to-PCI bridge [1039:0004]
00:02.0 ISA bridge [0601]: Silicon Integrated Systems [SiS] SiS968 [MuTIOL Media IO] [1039:0968] (rev 01)
00:02.5 IDE interface [0101]: Silicon Integrated Systems [SiS] 5513 IDE Controller [1039:5513] (rev 01)
00:03.0 USB controller [0c03]: Silicon Integrated Systems [SiS] USB 1.1 Controller [1039:7001] (rev 0f)
00:03.1 USB controller [0c03]: Silicon Integrated Systems [SiS] USB 1.1 Controller [1039:7001] (rev 0f)
00:03.3 USB controller [0c03]: Silicon Integrated Systems [SiS] USB 2.0 Controller [1039:7002]
00:04.0 Ethernet controller [0200]: Silicon Integrated Systems [SiS] 191 Gigabit Ethernet Adapter [1039:0191] (rev 02)
00:05.0 IDE interface [0101]: Silicon Integrated Systems [SiS] SATA Controller / IDE mode [1039:1183] (rev 03)
00:06.0 PCI bridge [0604]: Silicon Integrated Systems [SiS] PCI-to-PCI bridge [1039:000a]
00:0f.0 Audio device [0403]: Silicon Integrated Systems [SiS] Azalia Audio Controller [1039:7502]
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] RV710/M92 [Mobility Radeon HD 4530/4570/545v] [1002:9553]
01:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] RV710/730 HDMI Audio [Radeon HD 4000 series] [1002:aa38]
02:00.0 Network controller [0280]: Qualcomm Atheros AR928X Wireless Network Adapter (PCI-Express) [168c:002a] (rev 01)


I Edited for including the test alextheoto suggested me to do:

The only USB connector that is not a hub is the rear one. I have used that one.

:one:1st TEST with the cryptographic card reader connected.

SUSE Paste

:two:2nd TEST with the gaming mouse connected to the rear USB connector as said before:

SUSE Paste

:three:3rd Test with scanner connected:

 Yes! :)  they work perfectly fine with prior kernels to 5.8.15.  

All of these devices worked fine with generic linux drivers, even the old HP scanner (3400C) works fine with generic linux drivers although to obtain more advanced features I have installed the hplip drivers

I have only two kernels installed. (5.8.15 y 5.9.13)

When I start the system and press the “e” key to access edit kernel lines… It appears that the boot options, “radeon” and “irqpoll” appear as pre-marked only on kernel lines 5.9.13.

The old kernel, 5.8.15, does not seem to have any options set.

The file /etc/default/grub.cfg has not been edited, so I imagine that they must have been recorded somewhere.

I proceed to remove those options as you indicated using dracut. I may take some time because I have never used dracut before. Excuse me

I greatly appreciate the support of the community. Obviously, choosing to write in English instead of my mother tongue has been a drawback.

Sorry and thank you everyone for your help. :relaxed:


Please enter your BIOS and reset the settings with the motherboard’s default settings.
Give us what is written on ‘/etc/defaults/grub’ and the output of ‘dracut --list-modules’
Update the initramfs with ‘dracut --force’

From journalctl I don’t see any error. If the problem is still there:
1.From lsusb I don’t see any usb hub on your device.
2.Please test the problematic devices without usb hubs.

1 Like

Thank you for caring and trying to help me. I’m very sorry for taking so much time to respond your questions.

Tests have been performed under the following conditions:

  1. Using the 5.9.14 kernel. The 5.9.13 one has been replaced by 5.9.14 after an upgrade.

  2. Having completed the instruction to return the BIOS to its factory settings…

  3. If it is necessary to enter certain boot options on the lines of kernel 5.9.14, pressing the “e” key during system startup. Explained below :frowning:

  4. Plugging unrecognized USB devices into the rear USB connector of the computer. The remaining three connectors on the left side belong to a HUB.

Let’s go with your instructions.


Turned to manufacturer’s parameters. Without difficulties. Specific menu to do so.

Result: After having changed the BIOS settings: It is impossible to boot the system. And therefore access to Dracut to perform operation two. For this reason, I’m forced to enter some boot option in the lines of kernel 5.9.14, by pressing the “e” key during the computer boot.

Content of the folder: /etc/default/grub




dracut --list-modules output:

The command dracut --force is executed with no output

Additional testing. Unsolicited.

I have repeated the tests with journalctl -xe with the new circumstances and conditions I have mentioned.

Here are the results.

Test with the mouse connected to the rear USB.

Test with the Omnikey cryptographic card reader device.

Lsusb -t output. In cas It’s useful. I hope so.

[x@X61Ss ~]$ lsusb -t
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/4p, 12M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/4p, 12M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/8p, 480M
|__ Port 5: Dev 3, If 0, Class=Video, Driver=uvcvideo, 480M
|__ Port 5: Dev 3, If 1, Class=Video, Driver=uvcvideo, 480M
[x@X61Ss ~]$

Boot options different combinations
These tests have been performed in the same conditions described above.

booting with NO boot options

The system gets stuck after entering the password to decrypt the discs. And before reaching the login screen. Exactly Here—>

Introducing irqpoll in solitary.

The same thing… Stuck in during the boot. On this point.

Introducing nolapic in solitary

The boot is stuck after entering the decryption password, and before the login screen. In this case it is an incessant loop.

radeon seems to be dispensable in all scenarios.

Introducing nolapic and irqpoll together:

The computer starts up and the logon screen appears.

The tests performed ABOVE where made under this two boot options.

It can’t be said the computer with this two boot options works 100% normally. There are differences between one kernel and another.

Old kernel 5.8.15:

  • -USB devices work without problems.
  • -The processor works with only one kernel

Modern kernel. 5.9.14 (I have updated)

  • -Because nolapic is active, the processor works with only one core.
  • -The USB devices mentioned above do not work.

[> x@X61Ss ~]$ lscpu

Arquitectura: x86_64
modo(s) de operación de las CPUs: 32-bit, 64-bit
Orden de los bytes: Little Endian
Tamaños de las direcciones: 36 bits physical, 48 bits virtual
CPU(s): 1
Lista de la(s) CPU(s) en línea: 0
Hilo(s) de procesamiento por núcleo: 1
Núcleo(s) por «socket»: 1
«Socket(s)» 1
Modo(s) NUMA: 1
ID de fabricante: GenuineIntel
Familia de CPU: 6
Modelo: 23
Nombre del modelo: Intel(R) Core™2 Duo CPU T6400 @ 2.00GHz
Revisión: 10
CPU MHz: 1200.039
CPU MHz máx.: 2000,0000
CPU MHz mín.: 1200,0000
BogoMIPS: 4000.13
Caché L1d: 32 KiB
Caché L1i: 32 KiB
Caché L2: 2 MiB
CPU(s) del nodo NUMA 0: 0
Vulnerability Itlb multihit: KVM: Mitigation: VMX unsupported
Vulnerability L1tf: Mitigation; PTE Inversion
Vulnerability Mds: Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled
Vulnerability Meltdown: Mitigation; PTI
Vulnerability Spec store bypass: Vulnerable
Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2: Mitigation; Full generic retpoline, STIBP disabled, RSB filling
Vulnerability Srbds: Not affected
Vulnerability Tsx async abort: Not affected
Indicadores: fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall nx lm cons
tant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave
lahf_lm pti dtherm
[x@X61Ss ~]$

If I perform these tests with the modifications in the BIOS that I mentioned before, the results are different.

I’m clearly not qualified to speculate on the origin of the problem. I remember in the past seeing warnings in the dmesg output related to hotplug; and I think the problem is in the Apic management, or irq management.

It seems that the radeon boot option is totally dispensable afterall.

My problem is a real challenge, and I hope you can narrow down my problem and help me. I am very lost and my knowledge is really very limited.

Thank you in advance for your time and help.

That’s a very strange bios…
I’m sorry but I’m out of options here…

One last thing to try is:

  1. set BIOS to default
  2. run Fedora’s installation disk and enter into recovery mode.
  3. enter into hdd’s chroot and dracut your initramfs. (verify that you mounted your boot partition on /boot because you use encrypted partitions)
  4. reboot and on grub press ‘e’ and remove the words ‘rhgb quiet’ to show more boot messages to understand where the system halts.

Also, I didn’t understand if you tested your back usb with your non-working devices. If not, please do so.

If you have the time, you can do a git bisection on the kernel to find the change that caused the problem. Here is what I did about a year ago when the webcam on my laptop stopped working.

1 Like