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

Page 1 of 2

Show 50 post(s) from this thread on one page

- 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/)

Didier Spaier

07-25-2021 04:12 PM

USB keyboard and mouse not detected at boot with kernel 5.13.4, 5.12.11 is OK

System: Slint64-14.2.1 based on Slackware64-14.2
kernel generic + initrd (kernel config very close to the one used for Slackware-current)

Symptom: USB keyboard and mouse don't work after booting so no way to log in when using a 5.13.4 kernel, no issue with 5.12.11. Which is sad as 5.12 is tagged EOL upstream.

I have added a few commands at the end of /etc/rc.d/rc.M to investigate:

Code:

kerver=$(uname -r)

dmesg >/tmp/dmesg$kerver

lsmod >/tmp/lsmod$kerver

lsusb >/tmp/lsusb$kerver

modinfo usbhid >/tmp/usbhid$kerver

cat /proc/bus/input/devices >/tmp/input_devices$kerver

I have compared the output of lsmod after booting in both cases, nearly identical.

"modinfo usbhid" gives the same output with both kernels, kernel version put aside.

In dmesg5.12.11 but not in dmesg5.13.4 I find these lines:

Code:

input: Lite-On Technology Corp. USB Multimedia Keyboard as /devices/pci0000:00/0000:00:1c.5/0000:06:00.0/usb3/3-1/3-1:1.0/0003:04CA:005A.0001/input/input0

input: Lite-On Technology Corp. USB Multimedia Keyboard Consumer Control as /devices/pci0000:00/0000:00:1c.5/0000:06:00.0/usb3/3-1/3-1:1.1/0003:04CA:005A.0002/input/input1

input: Lite-On Technology Corp. USB Multimedia Keyboard System Control as /devices/pci0000:00/0000:00:1c.5/0000:06:00.0/usb3/3-1/3-1:1.1/0003:04CA:005A.0002/input/input2

input: Logitech USB Optical Mouse as /devices/pci0000:00/0000:00:1c.5/0000:06:00.0/usb3/3-2/3-2:1.0/0003:046D:C077.0003/input/input3

In lsusb5.12.11 only:

Code:

Bus 003 Device 003: ID 046d:c077 Logitech, Inc. M105 Optical Mouse

Bus 003 Device 002: ID 04ca:005a Lite-On Technology Corp. USB Multimedia Keyboard

in the output of cat /proc/bus/input/devices for 5.12.11 only:

Code:

I: Bus=0003 Vendor=04ca Product=005a Version=0111

N: Name="Lite-On Technology Corp. USB Multimedia Keyboard"

P: Phys=usb-0000:06:00.0-1/input0

S: Sysfs=/devices/pci0000:00/0000:00:1c.5/0000:06:00.0/usb3/3-1/3-1:1.0/0003:04CA:005A.0001/input/input0

U: Uniq=

H: Handlers=sysrq kbd leds event0 

B: PROP=0

B: EV=120013

B: KEY=1000000000007 ff9f207ac14057ff febeffdfffefffff fffffffffffffffe

B: MSC=10

B: LED=1f



I: Bus=0003 Vendor=04ca Product=005a Version=0111

N: Name="Lite-On Technology Corp. USB Multimedia Keyboard Consumer Control"

P: Phys=usb-0000:06:00.0-1/input1

S: Sysfs=/devices/pci0000:00/0000:00:1c.5/0000:06:00.0/usb3/3-1/3-1:1.1/0003:04CA:005A.0002/input/input1

U: Uniq=

H: Handlers=kbd event1 

B: PROP=0

B: EV=1f

B: KEY=300ff 0 0 483ffff17aff32d bfd4444600000000 1 130c730b17c000 267bfad9415fed 9e168000004400 10000002

B: REL=1040

B: ABS=100000000

B: MSC=10



I: Bus=0003 Vendor=04ca Product=005a Version=0111

N: Name="Lite-On Technology Corp. USB Multimedia Keyboard System Control"

P: Phys=usb-0000:06:00.0-1/input1

S: Sysfs=/devices/pci0000:00/0000:00:1c.5/0000:06:00.0/usb3/3-1/3-1:1.1/0003:04CA:005A.0002/input/input2

U: Uniq=

H: Handlers=kbd event2 

B: PROP=0

B: EV=13

B: KEY=c000 10000000000000 0

B: MSC=10



I: Bus=0003 Vendor=046d Product=c077 Version=0111

N: Name="Logitech USB Optical Mouse"

P: Phys=usb-0000:06:00.0-2/input0

S: Sysfs=/devices/pci0000:00/0000:00:1c.5/0000:06:00.0/usb3/3-2/3-2:1.0/0003:046D:C077.0003/input/input3

U: Uniq=

H: Handlers=mouse0 event3 

B: PROP=0

B: EV=17

B: KEY=70000 0 0 0 0

B: REL=903

B: MSC=10

I would like to know why these input devices are detected when using the kernel 5.12.11 but not 5.13.4.

Any clue appreciated.

marav

07-25-2021 06:48 PM

Bonsoir Didier

Quote:

Originally Posted by Didier Spaier (Post 6269616)

Code:

kerver=$(uname -r)

dmesg >/tmp/dmesg$kerver

lsmod >/tmp/lsmod$kerver

lsusb >/tmp/lsusb$kerver

modinfo usbhid >/tmp/usbhid$kerver

cat /proc/bus/input/devices >/tmp/input_devices$kerver

I suggest :

Code:

kerver=$(uname -r)

dmesg >/tmp/dmesg$kerver

lsmod >/tmp/lsmod$kerver

lsusb >/tmp/lsusb$kerver

modinfo usbhid >/tmp/usbhid$kerver

cat /proc/bus/input/devices >/tmp/input_devices$kerver

udevadm monitor > /tmp/udevadm$kerver

Didier Spaier

07-26-2021 06:31 AM

Merci marav, but this didn't help (console stuck after that).

I also tried to compare outputs of pstree and ps -ef, which gave no more clue.

As I have Slackware64-current installed on the same machine, I updated this system using slackpkg, which installed kernels huge and generic also at version 5.13.4, to no avail: same symptoms, so I can't log in using either the generic + initrd or the huge one.

Still puzzled.

marav

07-26-2021 06:41 AM

Quote:

Originally Posted by Didier Spaier (Post 6269736)

Merci marav, but this didn't help (console stuck after that).

right

my bad

Code:

udevadm monitor > /tmp/udevadm$kerver &

Franklin

07-26-2021 06:55 AM

Can confirm same behavior here. Unplugging and re-plugging the usb devices (keyboard & mouse) allows them to be recognized. I applied last 4 upgrades at the same time so could not place blame on any one in particular.

marav

07-26-2021 06:59 AM

Just a thought

Do you have :

Code:

Enable loadable module support / Path to modprobe binary / (/sbin/modprobe)

In your kernel menuconfig ?

Or in .config

Code:

CONFIG_MODPROBE_PATH="/sbin/modprobe"

EDIT : ignore it
http://ftp.slackware.com/pub/slackwa...ric-5.13.4.x64

Didier Spaier

07-26-2021 07:29 AM

2 Attachment(s)

Having put "udevadm monitor" in the background (which I should have done from the beginning, *my* mistake) gives interesting results (in Slint in this case), attached.

Should I understand that for some reason the kernel does not send uevents related to the mouse and keyboard so there's nothing eudev can do when using 5.13.4?

How do I confirm or infirm that? scanning /sys to check that the paths are created as they should?

Oh, and yes I have CONFIG_MODPROBE_PATH="/sbin/modprobe"

ZhaoLin1457

07-26-2021 07:33 AM

Quote:

Originally Posted by Didier Spaier (Post 6269616)

Any clue appreciated.

I use the generic kernel and the following modules loaded on initrd:

Code:

usb-storage:uas:xhci-pci:ehci-pci:ohci-pci:xhci-hcd:ehci-hcd:uhci-hcd:hid:usbhid:i2c-hid:hid_generic:hid-asus:hid-cherry:hid-logitech:hid-logitech-dj:hid-logitech-hidpp:hid-lenovo:hid-microsoft:hid_multitouch:mbcache:jbd2:ext4:f2fs:crc32_generic:vfat

With this setup, I never had problems with the USB mouses or keyboards. Even while running the latest kernel.

marav

07-26-2021 07:48 AM

The use of :

Code:

/usr/share/mkinitrd/mkinitrd_command_generator.sh -k 5.13.4

could be helpful ?

Didier Spaier

07-26-2021 11:58 AM

3 Attachment(s)

It appears that the input devices for the mouse and the keyboard are not exposed in the /sys directory in case of the kernel 5.13.4, thus the corresponding uevent files do not exist. So eudev not being informed of theses devices' existence by uevent can't create paths in /dev for them.

Find why /sys is not populated as it should when using a 5.13.4 kernel needs more investigation.

Meanwhile I will provide a kernel 5.12.19 for Slint to stay on the safe side of the world.

PS
@marav: Thanks but I ran geninitrd (with a few modifications in Slint and as is in Slackware) and anyway using the huge kernel in Slackware doesn't help
@ZhaoLin1457: thanks for the hint. Maybe either mkinitrd_command_generator.sh and/or the kernel's configuration need an adaptation (I would assume the latter at least as the huge kernel doesn't help), I don't know yet. There could be a bug in the source code of the kernel, but then someone would have found it already and filed an issue upstream, I assume.

Didier Spaier

07-26-2021 05:15 PM

Update: same symptoms with 5.12.19...

But I just realized that two USB ports out of 6 on this machine are affected. Maybe a commit applied on 5.2.x and also on 5.13.y is the cause?

Anyway I am uploading kernel packages at version 5.12.19 on the main Slint mirror. At worst users will be able to boot using the kernel in use when applying the upgrade, which will be preserved.

Still I am curious to know a fix: this is still an issue and not only an hardware one, as even with the problematic USB ports the keyboard and mouse work using the kernel 5.12.11. In the mean time I am not ready to build and try all kernels between 5.12.11 and 5.12.19, then do a git bisect to maybe find the offending commit... Any idea to find it more easily is warmly welcome.

marav

07-26-2021 05:40 PM

Our fantastic wizard has published each changelog here :

https://www.linuxquestions.org/quest...3/page244.html

suggested by someone you know well ... :-)

chris.willing

07-27-2021 01:59 AM

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

marav

07-27-2021 02:30 AM

1 Attachment(s)

In attachment, the result of :

Code:

#!/bin/bash

mkdir $HOME/change/

VER="5.12.12 5.12.13 5.12.14 5.12.15 5.12.16 5.12.17 5.12.18 5.12.19 5.13.0 5.13.1 5.13.2 5.13.3 5.13.4"

for i in $VER; do

  wget -O $HOME/change/changelog_"$i".txt https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-"$i"

done

grep usb $HOME/change/* > $HOME/change/all_usb_change.txt

And good luck with the rest
I am clearly not able to interpret the changelog of a kernel.

marav

07-27-2021 04:55 AM

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

Didier Spaier

07-27-2021 05:15 AM

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!

marav

07-27-2021 05:33 AM

Code:

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

It can be earlier for you ;-)

LuckyCyborg

07-27-2021 06:57 AM

Deleted. Sorry for the noise!

igadoter

07-27-2021 07:47 AM

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.

Franklin

07-27-2021 08:05 AM

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.

Didier Spaier

07-27-2021 08:31 AM

[duplicate, deleted]

Didier Spaier

07-27-2021 08:32 AM

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)

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

Didier Spaier

07-27-2021 09:21 AM

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.

igadoter

07-27-2021 09:28 AM

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.

marav

07-27-2021 09:32 AM

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

Didier Spaier

07-27-2021 09:37 AM

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.

enorbet

07-27-2021 09:39 AM

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. ;)

marav

07-27-2021 09:41 AM

Quote:

Originally Posted by enorbet (Post 6270110)

There! Refined that for ya. ;)

you're welcome :hattip:

Franklin

07-27-2021 09:52 AM

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.

allend

07-27-2021 10:47 AM

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.

Didier Spaier

07-27-2021 12:00 PM

Quote:

Originally Posted by allend (Post 6270127)

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

Thanks for looking at it and for the suggestion. However IIRC I have also built a 5.13.2 with the same issue.

For now I will try some relatively recent huge kernels found in http://slackware.uk/cumulative/slack...slackware64/k/ (thanks Darren for hosting them!) and check which is the last working here with all ports.

Didier Spaier

07-27-2021 02:05 PM

Quote:

Originally Posted by Didier Spaier (Post 6270155)

Thanks for looking at it and for the suggestion. However IIRC I have also built a 5.13.2 with the same issue.

For now I will try some relatively recent huge kernels found in http://slackware.uk/cumulative/slackware64-current/slackware64/a/ (thanks Darren for hosting them!) and check which is the last working here with all ports.

The answer is 5.12.16, as 5.13.2 and 5.13.3 have the same issue as 5.13.5.

Didier Spaier

07-27-2021 02:39 PM

I just posted this on the Slint mailing list.

marav

07-27-2021 02:55 PM

Didier,

Excuse me to come back to this, but
You said :

Quote:

I am just following Patrick's policy

And because of this usb issue, you can't put the stable 5.13.x
So why ship Slint with an EOL kernel instead of an LTS one?

LuckyCyborg

07-27-2021 03:09 PM

Is that Slint equivalent of slackware-current released as stable?

After all, the Slackware 15.0 may be released with the kernel 5.14.x or even 5.16.x, right?

And how reproducible is that issue?

Is affected only a particular model of laptop, or are many other hardware affected?

I ask this because I have never had (also) problems with mouses and keyboards on the last 15 years, no matter of what Linux distribution I used, and I have a garage full of trashware.

And all boxes works from this POV.

Didier Spaier

07-27-2021 03:12 PM

Quote:

Originally Posted by marav (Post 6270216)

So why ship Slint with an EOL kernel instead of an LTS one?

Temporarily, while waiting for better. I am confident that the problem will be solved in the 5.13 branch. If it is not fixed before Slackware 15 is released, I'll take care of it.

marav

07-27-2021 03:16 PM

Quote:

Originally Posted by Didier Spaier (Post 6270225)

Temporarily, while waiting for better. I am confident that the problem will be solved in the 5.13 branch. If it is not fixed before Slackware 15 is released, I'll take care of it.

that makes sense ;-)
let's hope so

Didier Spaier

07-27-2021 03:26 PM

Quote:

Originally Posted by LuckyCyborg (Post 6270222)

Is that Slint equivalent of slackware-current released as stable?

No. Let's call it a semi-rolling distribution. For instance we still ship gcc-5.5 and glibc-2.23, but already python-3.9, the most recent software in the accessibility stack and an up to date Mate desktop.

Quote:

After all, the Slackware 15.0 may be released with the kernel 5.14.x or even 5.16.x, right?

If the issue is solved in 5.14 I will ship it, no problem. Switching to a new branch is not an issue, I have done that twice already without any user complaint. I really hope this issue will be solved in a matter of days or at most weeks, not months, for the sake of Linux' reputation...

Didier Spaier

07-27-2021 03:36 PM

Quote:

Originally Posted by LuckyCyborg (Post 6270222)

And how reproducible is that issue?

Is affected only a particular model of laptop, or are many other hardware affected?

I can't answer, all I know is two other people have reported similar issues in this thread.

Quote:

I ask this because I have never had (also) problems with mouses and keyboards on the last 15 years, no matter of what Linux distribution I used, and I have a garage full of trashware.

And all boxes works from this POV.

Are you telling us that an issue of which you don't suffer personally is not worth taking care of?

LuckyCyborg

07-27-2021 03:56 PM

Quote:

Originally Posted by Didier Spaier (Post 6270234)

I can't answer, all I know is two other people have reported similar issues in this thread.

Are you telling us that an issue of which you don't suffer personally is not worth taking care of?

Absolutely NOT!

As you have seen what I did regarding those strange issues generated by that shared bind mounting of /var/run, for example.

I have just asked you regarding the (estimated) impact area, considering that I have never had such problems, even I loved to collect various (old) computers. In fact, until recently you do not specified that multiple users are affected, right?

Right now, I have 11 functional computers, and if I will insist a bit, I can bring to life another 5. Everything is trashware, thought - as I already confessed.

My flagship box has an AM3 Athlon x4 605e with TDP of 45W and (mainly) works with a built-in Radeon 4250 graphics. For various reasons, sometimes I mount on it a Radeon HD7450, or an AMD R5 240 or a NVIDIA GeForce 605.

That's the best I have. Imagine the lower ones. ;)

drumz

07-27-2021 03:59 PM

Quote:

Originally Posted by Didier Spaier (Post 6269923)

In the mean time I am not ready to build and try all kernels between 5.12.11 and 5.12.19, then do a git bisect to maybe find the offending commit... Any idea to find it more easily is warmly welcome.

No need to narrow it down to a point version before doing the git bisect. If you already know 5.12.11 is good and 5.12.19 is bad just those as your starting point for git bisect. It will actually be more efficient that way, as git bisect won't restrict itself to first testing 5.12.y tags.

If you can narrow it down to an offending commit for bonus points you can then test all (or as many as you want) of the release branches of the kernel (with and without the offending associated commit) when reporting it to the kernel developers.

Didier Spaier

07-27-2021 05:04 PM

5.12.18 is "bad". Now building 5.12.17.

PS meanwhile, listening https://www.youtube.com/watch?v=GKHL8XPeLpE

The text is misleading: Menahem Pressler is 97 years old, not 90.

chris.willing

07-27-2021 05:11 PM

Quote:

Originally Posted by Didier Spaier (Post 6270081)

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

Sorry for the delay - we've been asleep on this side of the world.

I just tried 5.13.5 on the affected machine but the problem is still there.

I'm a little perplexed as to why there are so few reports about this elsewhere - is Slackware so far ahead of other distros that not many working systems in the world have experienced the problem yet?

chris

Didier Spaier

07-27-2021 05:24 PM

Quote:

Originally Posted by chris.willing (Post 6270259)

I'm a little perplexed as to why there are so few reports about this elsewhere - is Slackware so far ahead of other distros that not many working systems in the world have experienced the problem yet?

Same question here. At least Arch is also shipping 5.13.5 currently and it is customary for Arch users to upgrade their packages as soon as possible.

marav

07-27-2021 05:24 PM

Quote:

Originally Posted by chris.willing (Post 6270259)

OpenSuse Tumbleweed (LiveCD) is ship with a 5.13.4
Maybe, you could give a try ?

Didier Spaier

07-27-2021 06:19 PM

5.12.17 is "bad". So it seems that the last "good" kernel be 5.12.16. Bed time form me now (UTC+2).

Franklin

07-27-2021 06:22 PM

OK, so this is interesting ...

I just applied the latest update to -current and the 5.13.5 kernel-huge that was working fine for me prior (after multiple tests) is now broken again - worse with respect to the mouse as the pointer no longer functions like before. No kernel updates this time and yes, I did merge my .new rc.d scripts as indicated in the 7/27 ChangeLog.

Hard reset fixes things. Cold boot now no-go as with 5.13.4 (for me).

** I should probably specify that it was the 2nd 7/27 update to -current that made 5.13.5 stop working for me. The first 7/27 update to -current that upgrade 5.13.4 to 5.13.5 actually fixed things - for 10 hours or so. ;)

Franklin

07-27-2021 07:14 PM

Just trying to share a similar experience in case it points someone to a possible cause. Does not seem to be a common experience.

Currently (no pun intended ;) ), a cold boot will cause the mouse and keyboard to not be recognized with respect to key strokes or mouse clicks. Keeping the mouse and keyboard inserted in the same USB port and pressing the reset button will allow both to be recognized and usable upon reboot. The functionality will be maintained so long as the mouse and keyboard USB ports are not changed.

Shutting down the box and changing the USB ports for both the mouse and keyboard will result in the mouse and keyboard to become unresponsive again until the reset button is pressed to reboot. The mouse and keyboard will then be functional in the new ports and remain that way so long as the USB ports are not changed again.

All this is with the 5.13.5 huge-kernel. This worked fine prior to the 2nd 7/27 -current update using the 5.13.5. Initially I saw issues only on 5.13.4 which were fixed with the 5.13.5 upgrade (1st 7/27 update to -current).

philanc

07-28-2021 01:05 AM

Quote:

Originally Posted by Didier Spaier (Post 6270258)

PS meanwhile, listening https://www.youtube.com/watch?v=GKHL8XPeLpE

The text is misleading: Menahem Pressler is 97 years old, not 90.

Thanks for the link. Great piece of music.

BTW, the text is exact. It was recorded for the 90th birthday of Menahem Pressler, in December 2013.

Didier Spaier

07-28-2021 01:48 AM

Quote:

Originally Posted by philanc (Post 6270311)

BTW, the text is exact. It was recorded for the 90th birthday of Menahem Pressler, in December 2013.

Thanks for the correction, I mistakenly took the date of upload as the date of recording.

All times are GMT -5. The time now is 03:33 AM.

Page 1 of 2

Show 50 post(s) from this thread on one page