From: Hans de Goede <hdegoede@redhat.com>
To: Jiri Kosina <jikos@kernel.org>, Dave Hansen <dave.hansen@intel.com>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>,
"open list:HID CORE LAYER" <linux-input@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: hid-related 5.2-rc1 boot hang
Date: Mon, 3 Jun 2019 11:32:11 +0200 [thread overview]
Message-ID: <e602db44-c792-1abe-e389-a71fca6d2ddd@redhat.com> (raw)
In-Reply-To: <e158d983-1e7e-4c49-aaab-ff2092d36438@redhat.com>
Hi,
On 03-06-19 11:11, Hans de Goede wrote:
> Hi,
>
> On 01-06-19 00:15, Jiri Kosina wrote:
>> On Thu, 30 May 2019, Dave Hansen wrote:
>>
>>> On 5/29/19 2:17 AM, Hans de Goede wrote:
>>> ...
>>>> Dave, can you try building your initrd without the hid-logitech-dj module
>>>> included in the initrd?
>>>
>>> I did this on a vanilla 5.2-rc2 kernel (without the reverts) and still
>>> experienced the boot hang while the device was inserted.
>>>
>>>> Also can you check if your modprobe is provided by module-init-tools
>>>> or by kmod ?
>>>
>>> $ dpkg -S `which modprobe`
>>> kmod: /sbin/modprobe
>>
>> Benjamin, Hans, are you looking into this?
>
> Not really, I cannot reproduce the request_module problem. I was hoping some
> of the info from Dave would help to pinpoint it, but it does not :|
>
>> If not, I think we should start reverting (at least the request_module()
>> changes
>
> I agree we need to do something about the request_module changes.
>
> I myself was thinking about somehow making them conditional, e.g. we
> could add a (temporary) module option defaulting to false for this
> while we investigate further.
>
> I'm afraid that if we just revert we will never find the root cause and then
> we will be stuck with the suboptimal behavior of first the generic hid driver
> binding followed by a unbind + bind of the new driver shortly afterwards,
> which also leads to a ton of udev events being fired to userspace (well I
> guess this does make for a good stress test of the userspace hotplug code).
Quick update, we have another report of module-loading related problems
which are likely related:
https://bugzilla.kernel.org/show_bug.cgi?id=203741
In this case there is no hang, instead there is a 1 to 3 minute delay.
Regards,
Hans
next prev parent reply other threads:[~2019-06-03 9:32 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-28 16:43 hid-related 5.2-rc1 boot hang Dave Hansen
2019-05-28 17:14 ` Jiri Kosina
2019-05-28 17:45 ` Benjamin Tissoires
2019-05-28 18:11 ` Dave Hansen
2019-05-29 9:17 ` Hans de Goede
2019-05-30 16:56 ` Dave Hansen
2019-05-31 22:15 ` Jiri Kosina
2019-06-03 9:11 ` Hans de Goede
2019-06-03 9:32 ` Hans de Goede [this message]
2019-06-03 9:51 ` Hans de Goede
2019-06-03 13:55 ` Benjamin Tissoires
2019-06-03 14:17 ` Hans de Goede
2019-06-04 7:51 ` Benjamin Tissoires
2019-06-04 8:05 ` Hans de Goede
2019-06-04 8:36 ` Hans de Goede
2019-06-04 8:53 ` Benjamin Tissoires
2019-06-04 21:08 ` Jiri Kosina
2019-06-05 12:29 ` Benjamin Tissoires
2019-06-04 10:08 ` Benjamin Tissoires
2019-06-04 10:50 ` Hans de Goede
2019-06-04 12:25 ` Benjamin Tissoires
2019-06-04 13:12 ` Hans de Goede
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e602db44-c792-1abe-e389-a71fca6d2ddd@redhat.com \
--to=hdegoede@redhat.com \
--cc=benjamin.tissoires@redhat.com \
--cc=dave.hansen@intel.com \
--cc=jikos@kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.