PC "freeze" sometimes when a sr0 CD-ROM is detected #171
Comments
|
Hi @Massedil
I'll try to help. This is actually not a driver issue. It is a problem with the adapter being multi-state. I have recently been looking into this issue as there seems to have been a rise in the number of cases. I am aware of a couple of workarounds. Tell me, does this adapter have bluetooth capability or is it wifi only? Side note: You won't like this but the only sure way to eliminate multi-state (storage mode) as an issue is to get an adapter that is single-state. The Main Menu for this site is as follows: https://github.com/morrownr/USB-WiFi Reading menu items 1 and 2 can help. Menu item 2 gives information and links to many adapters that are single-state. With that said, answer my question and I will try to help. |
Thank you !
It is Wi-Fi only. Id with
But can't this bug be solved in driver, kernel or somewhere else ?
Done, let me know if I can do more for help solving this ! Thanks again ! |
The bug cannot be solved in the driver as the driver has nothing to do with what causes the issue. In fact, you will see the same problem without the driver installed. Let me post a short guide that I have in the FAQ of one of the drivers here: Question: My USB WiFi adapter is showing up as a CDROM or Flash drive instead of a WiFi adapter. What is the problem? Answer: Your Realtek USB WiFi adapter showing up as a CDROM or Flash drive (often with ID 0bda:1a2b) instead of functioning as a network adapter (such as ID 35bc:0102 or similar) is likely due to a "mode-switching" issue. Some USB WiFi adapters include onboard memory that contains drivers or installation software for Windows. When plugged into a system for the first time, they initially present themselves as a virtual CD-ROM or Flash driver containing the drivers. In Linux, the usb_modeswitch utility generally handles this issue but there are situations where it does not work as expected. Your options:
https://github.com/morrownr/USB-WiFi/blob/main/home/How_to_Modeswitch.md If you have exhausted recommendations from the information in item 2, then:
How to add kernel parameters with GRUB in Ubuntu: Note: This method may vary by distro so if you are not using Ubuntu, please consult the documentation for your distro. Once your device has booted, use a text editor to open the following file: $ sudo nano /etc/default/grub Add parameters to GRUB_CMDLINE_LINUX while keeping the following in mind: Enter parameters inside the double-quotes Leave a space before each new parameter Don’t add space round = and other punctuations for each key-value Don’t add line breaks If your original line looks like: GRUB_CMDLINE_LINUX="quiet" Then your updated line should read like: GRUB_CMDLINE_LINUX="quiet usb-storage.quirks=0bda:1a2b:i" Note: If the storage VId/PID (ID) i not 0bda:1a2b, you will need to change 0bda:1a2b to the storage mode VID/PID of your adapter. Save and close the editor. Update GRUB with its new configuration: $ sudo update-grub $ sudo reboot Note: If your distro does not use grub, the RasPiOS is an example, you will need to read your distro docs to see how to do the above. Example for Raspberry Pi OS: $ sudo nano /boot/firmware/cmdline.txt add the following to the end of the console= line: usb-storage.quirks=0bda:1a2b:i Save, close the editor and reboot. |
|
Thanks ! And nothing with That is why I see So you suggest me to try : Things I don't understand :
|
|
Thanks ! And nothing with So you suggest me to try : Things I don't understand :
|
|
I've done I've also activate |
There should be nothing in that file with c811. usb_modeswitch is try to switch you out of CDROM mode so it needs the ID of the storage.
It is not unusual for this problem to be random.
That does give us a hint that something could be getting messed up during the boot process. usb_modeswitch is started by systemd.
That actually should not work as your should be using the ID for the storage mode but if it works, great. How about you use it some more and see if it was coincident.
I think the log is somewhere down in /var and you should be able to see it with |
I don't see anything in logs about "usb_modeswitch" when I boot. I think usb_modeswitch is not started at all, that is why I don't have logs. But when I plug the device after boot, tadam : Now I have a log file at
Yes, surely a coincidence. A good boot as describe in my first post. Now, I need to find why it is not started at boot... Do you have an idea ? |
I do not have a good idea. I have been digging some as I have had time over the last week but obviously I have not uncovered the problem. I'm digging for another chip, the rtl8852/32cu. I just went public with a new driver for that chip today and several users have reported usb_modeswitch problems and I am seeing it myself. Same stuff that you and others see with this chip. If you want to work together to figure out what is causing this, I'm in. One thing we need to do is document things as we go along. I end up working on other things so I need a document to refresh my mind. So what starts usb_modeswitch? systemd. So, let's look at the service file usbmodeswitch: /usr/lib/systemd/system/[email protected] Now editing the original may not be a good idea so copying this original to a place that will override the original will give us a file to edit and if we mess it up we can just copy the original over the one we are editing and start over. sudo cp /usr/lib/systemd/system/[email protected] /etc/systemd/system/[email protected] Then to edit: sudo nano /etc/systemd/system/[email protected] So, what do we edit? Beats me. We need to figure out where things are going wrong. |
|
Here is an interesting read. Not saying this is our problem but it adds to our knowledge: |
|
Another interesting read: |
|
Just to inform you that I didn't have time today (and just quickly read your messages), but I will try to understand the boot process and debug the problem. I'll let you informed of what I will find. Thanks again ! |
|
No hurry. I had a little extra time and found a few things that might add something to the search. |
|
Hello, Some news ! I better understand my cases. When I cold boot (real power off), I have the problem. The device present it self as a CD-ROM When I reboot, I don't have the problem because I imagine the usb device is not power off and retain the last usb_modswitch switch command and presents immediately itself as usb_modswitch don't execute at all in this case ! So in all cases, usb_modswitch is not executed at boot. When I have booted and plug the device (here with udev logs activated), everything works fine because udev trigger a usb_modeswitch call : |
|
Some things to understand or find where to report if it is a bug :
|
|
I found that udev is well called at boot. But it seems there is some deadlock when trying to apply actions on the CD-ROM I reboot and try to wait more to see what happens. In this boot sequence I halted the system at 22:08:02. |
Common behavior, when an old boot failed (without udev logs) : Given the long time between messages, that is why I will wait more for next fail reboot !
May be a hack we can try if we didn't find the problem. I have hope that we will have more info after next failed reboot with udev debug logs ! |
|
Waiting a long time finally permit me to log-in ! In In fact, we can see that usb_modeswitch is called : I have the log of the first call only (don't understand why not the last) : Content of So we can see that the command is not really launched compared to the log I have when the session has booted. |
|
Here is the log file. I hope it gives you ideas. |
|
Looking at the log without knowing what you were doing with the computer makes it hard to interpret but... I think it shows that there is difficulty bringing SR0 up. That is, the system is having a problem bringing what it thinks is a CDROM up. This in turn causes usb_modeswitch from being triggered and that means no mode switching is taking place. This is interesting. On 3 test systems here, the adapter I am testing works fine on a system that has a real CDROM but fails on the other two that do not. Coincidence? I don't know but can I get you to clean the udev log and only do one cold boot. Send the log from just doing that. I'll try to do the same on two systems here as able. I am having some health difficulties so I may be slow over the next two days or so.. |
Simple : in udevlog.boot.fail_wait_long.log I have done nothing ! Just booted and waited doing nothing. In this file you have a cold boot with the device plugged in.
I agree.
For me usb_modeswitch is triggered (but fail I don't know why), because we can see : Or:
I effectively don't have a real CD-ROM plugged in, but may be I can plug one if you need.
You have that in the file. Only one cold boot from déc. 18 23:21:56 to déc. 18 23:31:12. Let me know if I can help more. |
|
I am going to see about getting some help. It may take some time. We need to get to the bottom of this. |
|
I hope you had a good holiday season. I am no further along than I was we left off. I am just holding this issue until I discover more information. I think it is a problem with Linux bringing up the cd-rom. If the cd-rom is not up like it should be then usb_modeswitch can't switch it. |
Hello,
Since I installed this driver, when I boot with the USB Wi-Fi adapter connected, sometimes (once out of 2 boot ?) my computer "freeze" at the login screen. It is not really a freeze because the displayed hour is updated, but I can't use my keyboard and my mouse. If I press the power button, the computer try to stops, but hangs.
Comparing the log between a succesfull boot (I can login and use my computer) and a failed one (stuck at boot screen), I can see that the kernel dectect a
sr0CD-ROM Realtek Driver Storagewhen it fails.Here are the logs :
When I try to stop the computer, it fails to stop and I see this :
Ubuntu 24.04.1 LTS / kernel 6.8.0-50-generic / USB :
0bda:c811 Realtek Semiconductor Corp. 802.11ac NICMore logs :
boot failed :
Boot successful :
I don't know if it is related, but even when the boot is successful, I often have to disconnect and reconnect the USB device for it to connect to Wi-Fi networks.
I'm available for tests if you need !
The text was updated successfully, but these errors were encountered: