Created attachment 130272 [details] kernel config file used Hardware: Joule SOC: Broxton Kernel version: 4.11.rc2 Rootfs: Minimal rootfs based on busybox I tried booting 4.11.rc2 tip on Joule hardware. But my boot sequence is blocked for 60 seconds in drm HUC firmware failure. Attached is the config file and dmesg log.
Created attachment 130273 [details] dmesg log
The delay is caused by call to fw_load_from_user_helper() from inside _request_firmware(). The problem is that the drm/i915 driver is trying to load GuC/DMC/HuC firmware in early boot stage before any file system is mounted. So the request_firmware() call will fail to load the firmware and fallback to usermode helper mechanism. However, since this is happening in early boot before init program is started, it's impossible for any usermode helper to load the firmware either. Thus the fw_load_from_user_helper() would stuck there until it times out in 60 seconds. I believe this firmware loading mechanism is problematic, it should just schedule a delayed the firmware loading work to some point of time after file system is mounted.
(In reply to Fei Yang from comment #2) > I believe this firmware loading mechanism is problematic, it should just > schedule a delayed the firmware loading work to some point of time after > file system is mounted. No, if you're using an initrd, you should put all required firmware files in the initrd.
(In reply to Jani Nikula from comment #3) > (In reply to Fei Yang from comment #2) > > I believe this firmware loading mechanism is problematic, it should just > > schedule a delayed the firmware loading work to some point of time after > > file system is mounted. > > No, if you're using an initrd, you should put all required firmware files in > the initrd. Alternatively, configure i915 as a module, and load it from the real rootfs.
Hello sathya, Did instructions given by Jani on comment 3 and 4 help you to resolve the problem?
Following Jani's comment might help me successfully load the i915 driver. But if I don't want to build the i915 as module or not add the firmware files to my initrd, then it should not block my boot by 60 seconds. If it can't find the firmware , it should either fail or go into a blocking loop till my filesystems are loaded. right ?
Lyncoln says this is likely a GuC FW issue since GuC loads HuC. Assigning to John for next steps.
(In reply to dog from comment #7) > Lyncoln says this is likely a GuC FW issue since GuC loads HuC. If the scenario is i915 as built-in or as a module in initrd *and* there is no firmware blob in initrd, it's not a GuC issue. It's up to debate whether we should care about such a use case.
(In reply to Jani Nikula from comment #8) > (In reply to dog from comment #7) > > Lyncoln says this is likely a GuC FW issue since GuC loads HuC. > > If the scenario is i915 as built-in or as a module in initrd *and* there is > no firmware blob in initrd, it's not a GuC issue. It's up to debate whether > we should care about such a use case. This is the same case in Android (apologies if people was trying to omit the name); there we have to carry a must-rebase patch to delay the fw loading until first use. So I agree with Jani. It isn't something upstream should care about.
Created attachment 131058 [details] [review] late guc loading For completeness, here is the 'deferred' guc/huc fw loading patch. It applies on top of drm-tip (2017y-04m-25d-14h-42m-59s). Or just don't use guc, simples...
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.