LinuxQuestions.org - [SOLVED] USB keyboard and mouse not detected at boot with kernel 5.13.4, 5.12.11 is OK

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - USB keyboard and mouse not detected at boot with kernel 5.13.4, 5.12.11 is OK (https://www.linuxquestions.org/questions/slackware-14/usb-keyboard-and-mouse-not-detected-at-boot-with-kernel-5-13-4-5-12-11-is-ok-4175698287/)

Quote:

Originally Posted by marav (Post 6270021)

otherwise, just to know
why not use an LTS kernel in this case? (5.10.x for ex.)

I am just following Patrick's policy, as he knows a lot better than me:

Code:

Mon Jun  7 18:53:49 UTC 2021

Hey folks! Sorry about the delay in getting this batch out but I had other

distractions going on here last week that prevented getting this one wrapped

up. Anyway, probably the highlight of this update set is that we've decided

to abandon the 5.10 LTS kernel in favor of following the latest one. We've

never really had a policy that required LTS in a stable release although that

is how it has been done for years, but based on comments from the Slackware

community it seems like 5.10 LTS isn't getting a lot of love and lacks

hardware support that people need now. Conversely, the reports on 5.12 have

been almost entirely positive, so we're going to provide what we think is the

best available kernel. It's unlikely that we'll see another LTS prior to

release, so the plan for maintenance is to keep following the latest kernels

as needed for security purposes. If that means we have to jump to a new branch

while supporting the stable release, we'll start the kernel out in testing

first until we've had some feedback that it's safe to move it to the patches

directory. Sooner or later we will end up on an LTS kernel again, and at that

point we'll just roll with that one. Feel free to comment (or complain) about

this plan on LQ... I'll be curious to see what people think. Anyway, enjoy!

Code:

Sooner or later we will end up on an LTS kernel again

It can be earlier for you ;-)

Deleted. Sorry for the noise!

Are you custom build kernel on 14.2? I guess yes. If not build your own. Now it is mess. Try to connect to system via network. But imo this is completely unworthy any investigation. Use 5.12.x. Why does it matter for you? You are still using 14.2. We can spend month here without any result. Just things happen. Like for me today. All wifi network stack just refused to work. I rebooted and it works now. Should I spend two weeks to figure out what happened? For time being stick to 5.12.x - 5.13.x seems also be some kind flawed. Let forget about it and move on.

5.13.5 seems to have cleared up things for me. I use the Huge kernel on -current. Can confirm 3.0 and 3.1 ports had been impacted (all I have on my rear IO). This happened only after a cold boot. I likely did not notice this on earlier kernel updates as I usually "restart" after I apply an upgrade to -current. I tested a couple times using 5.13.4 and cold boot was still leaving me with a powered mouse and keyboard, but no input was recognized until I did a hard reset. After upgrading to 5.13.5 things work fine after starting cold. I had mentioned earlier that unplugging and re-plugging the mouse and keyboard seemed to fix things, but this was either incorrect or inconsistent.

[duplicate, deleted]

Quote:

Originally Posted by igadoter (Post 6270063)

I disagree. Getting stuck with an old kernel can be an option for you, just not my choice for Slint. Also solving this issue probably matters too for folks wanting to upgrade to Slackware 15 when released and eager to help making it as good as previous versions.

Quote:

Originally Posted by Franklin (Post 6270065)

Thanks, will upgrade Slackware64-current to 5.13.5 (both huge and generic) and if that confirms your findings will build a generic package to with 5.13.5 for Slint.

Quote:

Originally Posted by chris.willing (Post 6269996)

Another data point here. In a mature machine (about 6yrs old), all the USB-2 ports work fine but none of the 3x USB-3.0 ports work with kernels 5.13.3,4. On a newer machine all the USB ports are USB-3.2 Gen 2 and all seem to be working OK (as do the USB-2 ports).

The resulting conjecture would be that older USB-3.0 ports are problematic with 5.13.x kernels.

chris

Thanks for this information, Chris. Can you confirm that 5.13.5 is better on this respect?

Quote:

Originally Posted by Didier Spaier (Post 6270081)

Thanks, will upgrade Slackware64-current to 5.13.5 (both huge and generic) and if that confirms your findings will build a generic package to with 5.13.5 for Slint.

Here, having upgraded kernel-huge and kernel-generic to version 5.13.5 didn't help. Keyboard and mouse still don't work plugged in the same USB ports, but do in the other ones.

Quote:

Originally Posted by Didier Spaier (Post 6270081)

Kernel 5.12.x is by no means old kernel. Today used kernel for stable releases of many distributions are 4.19.x , 5.4.x. It is planned next Debian will be shipped with 5.10.x.

It is just Slackware -current is racing horse. There is no need to follow kernel policy as it is in Slackware -current. I would say - you should expect problems running -current. Get to used it.

Almost no one here has enough knowledge about kernel usb stack to have even glimpse what's happening. Sure we can behave like say monkeys (no abuse for monkeys) by unplugging and plugging again usb keyboard, mouse. But it does not make us an inch closer to solution of problem.

I think it is better for now to stick to "old" 5.12.x which works. I am almost sure things will improve in time.

Quote:

Originally Posted by igadoter (Post 6270105)

Kernel 5.12.x is by no means old kernel. Today used kernel for stable releases of many distributions are 4.19.x , 5.4.x. It is planned next Debian will be shipped with 5.10.x.

because these many distributions maintain their own kernel
slackware is not in this case

Quote:

Originally Posted by igadoter (Post 6270105)

I think it is better for now to stick to "old" 5.12.x which works. I am almost sure things will improve in time.

I have indicated in post #11 that the same issue occurs with 5.12.19 (mostly recent release of this branch) furthermore this branch has been declared EOL (End of Life) as you can check here.

Quote:

Originally Posted by marav (Post 6270106)

because these many distributions maintain their own <massively altered> kernel
slackware is not in this case

There! Refined that for ya. ;)

Quote:

Originally Posted by enorbet (Post 6270110)

There! Refined that for ya. ;)

you're welcome :hattip:

Quote:

Originally Posted by Didier Spaier (Post 6270101)

Here, having upgraded kernel-huge and kernel-generic to version 5.13.5 didn't help. Keyboard and mouse still don't work plugged in the same USB ports, but do in the other ones.

That's unfortunate. I went back and rested all my USB ports again using the same methods that failed for me with 5.13.4 and everything is working as expected now. These are USB 3.0 and 3.1 ports.

I have been looking at commit 34ada7b357dda19b32a1c440512da5367621be20 in ChangeLog-5.13.4 , which has also been backported into the 5.12.19 kernel. (Thanks Marav!)

I am no expert, but the way I read the code,

Code:

        if (gadget_is_otg(gadget) && !otg_desc[0]) {

                struct usb_descriptor_header *usb_desc;



                usb_desc = usb_otg_descriptor_alloc(gadget);

                if (!usb_desc) {

                        status = -ENOMEM;

                        goto put;

                }

                usb_otg_descriptor_init(gadget, usb_desc);

                otg_desc[0] = usb_desc;

                otg_desc[1] = NULL;

        }



        /* register our configuration */

        status = usb_add_config(cdev, &config_driver, do_config);

        if (status < 0)

                goto free_otg_desc;



        usb_composite_overwrite_options(cdev, &coverwrite);

        dev_info(&gadget->dev, DRIVER_DESC ", version: " DRIVER_VERSION "\n");



        return 0;



free_otg_desc:

        kfree(otg_desc[0]);

        otg_desc[0] = NULL;

put:

        list_for_each_entry(m, &hidg_func_list, node) {

                if (m == n)

                        break;

                usb_put_function_instance(m->fi);

        }

        return status;

}

if the test is passed, then it is possible to skip over the usb configuration if USB On-The-Go capability is detected.
The gadget_is_otg() is defined in /include/linux/usb/gadget.h

Code:

/**

 * gadget_is_otg - return true iff the hardware is OTG-ready

 * @g: controller that might have a Mini-AB connector

 *

 * This is a runtime test, since kernels with a USB-OTG stack sometimes

 * run on boards which only have a Mini-B (or Mini-A) connector.

 */

static inline int gadget_is_otg(struct usb_gadget *g)

{

#ifdef CONFIG_USB_OTG

        return g->is_otg;

#else

        return 0;

#endif

}

In the Slackware64 kernel 5.13.4 and 5.13.5 there is

Quote:

bash-5.1$ grep CONFIG_USB_OTG /usr/src/linux/.config
CONFIG_USB_OTG=y
# CONFIG_USB_OTG_PRODUCTLIST is not set
# CONFIG_USB_OTG_DISABLE_EXTERNAL_HUB is not set
# CONFIG_USB_OTG_FSM is not set

I do not have hardware to test this, but my suggestion is to either try reversing that commit or perhaps disabling the .config setting.