Bug 1077186 - Increase the firmware loading timeout to 600s
Summary: Increase the firmware loading timeout to 600s
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: udev
Version: 6.6
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Harald Hoyer
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks: 994246
TreeView+ depends on / blocked
 
Reported: 2014-03-17 12:29 UTC by Harald Hoyer
Modified: 2019-07-11 07:53 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: For firmware loading request the global timeout is 60 seconds by default. Consequence: Some firmware loading takes longer than 60 seconds on systems with heavy I/O load and thus fails sometimes. Fix: The global timeout for firmware loading is increased to 600 seconds. Result: 600 seconds should be long enough even on systems with heavy I/O load during the boot process, to let all firmware load without a timeout.
Clone Of:
Environment:
Last Closed: 2014-10-14 07:17:55 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Proposed patch (762 bytes, patch)
2014-03-17 12:29 UTC, Harald Hoyer
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 206493 0 None None None Never
Red Hat Product Errata RHBA-2014:1524 0 normal SHIPPED_LIVE udev bug fix and enhancement update 2014-10-14 01:22:06 UTC

Description Harald Hoyer 2014-03-17 12:29:39 UTC
Created attachment 875486 [details]
Proposed patch

Increase the firmware timeout of 60s seconds to 600s by writing into /sys/class/firmware/timeout. This should be done before any module is loaded.

The timeout begins as soon as the module loaded. udev might work on the uevent any time later on, so the firmware can timeout before udev even looks at the uevent.

Because of the modprobe locking patch, things get worse, because we serialize network related modprobes. If the maximum number of childs is reached, the timespan can even get longer or even deadlock.

This patch should go along with a solution for bug 1028174

Comment 2 Harald Hoyer 2014-03-17 15:25:57 UTC
related: bug 1077186

Comment 3 Harald Hoyer 2014-06-06 14:25:54 UTC
Please test http://people.redhat.com/harald/downloads/udev/udev-147-2.53.el6/

Comment 5 Karel Volný 2014-08-14 13:37:23 UTC
ahem, which version is this fixed-in?

I went down to udev-147-2.51.el6.i686, rebooted the system, and ...

# cat /sys/class/firmware/timeout
600

so I cannot prove anything got fixed in udev-147-2.57.el6 as the value is the same

or is there any other way to test?

Comment 6 Harald Hoyer 2014-08-14 14:23:06 UTC
It's also set in the initramfs, so that might have already set it.

Comment 7 Karel Volný 2014-08-14 15:19:55 UTC
(In reply to Harald Hoyer from comment #6)
> It's also set in the initramfs, so that might have already set it.

so I've run `dracut -f` and rebooted ... and the timeout is still set to 600

Comment 8 Harald Hoyer 2014-08-15 07:51:28 UTC
(In reply to Karel Volný from comment #7)
> (In reply to Harald Hoyer from comment #6)
> > It's also set in the initramfs, so that might have already set it.
> 
> so I've run `dracut -f` and rebooted ... and the timeout is still set to 600

and you installed an old dracut and an old udev?

The udev patch is in udev-147-2.53 and the dracut patch in dracut-004-347.

Comment 9 Karel Volný 2014-09-04 15:50:25 UTC
(In reply to Harald Hoyer from comment #8)
> and you installed an old dracut and an old udev?
> 
> The udev patch is in udev-147-2.53 and the dracut patch in dracut-004-347.

old dracut? - I don't get it why, but anyways ...

with udev-147-2.51.el6.i686 and dracut-004-336.el6.noarch:

.live.[root@i386-6s-m1 ~]# cat /sys/class/firmware/timeout
60

with either of those updated:

.qa.[root@i386-6s-m1 ~]# cat /sys/class/firmware/timeout
600

Comment 10 errata-xmlrpc 2014-10-14 07:17:55 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2014-1524.html


Note You need to log in before you can comment on or make changes to this bug.