Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758968Ab2HWPbd (ORCPT ); Thu, 23 Aug 2012 11:31:33 -0400 Received: from mail-ob0-f174.google.com ([209.85.214.174]:39105 "EHLO mail-ob0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752364Ab2HWPb3 (ORCPT ); Thu, 23 Aug 2012 11:31:29 -0400 MIME-Version: 1.0 In-Reply-To: References: From: Kay Sievers Date: Thu, 23 Aug 2012 17:31:08 +0200 Message-ID: Subject: Re: udev 182: response timeout for request_firmware in module_probe path To: Ming Lei Cc: Linux Kernel Mailing List , Greg Kroah-Hartman , Johannes Berg , Larry Finger , Linus Torvalds , systemd-devel@lists.freedesktop.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1244 Lines: 29 On Thu, Aug 23, 2012 at 5:16 PM, Ming Lei wrote: > On Tue, Aug 21, 2012 at 1:34 PM, Ming Lei wrote: >> I found that udev 182 doesn't response for the request_firmware in >> module_probe path until 30sec later after the 'ADD' event of firmware >> device, but no such problem in udev175, sounds like a regression of udev? > > Looks udevd is capable of handling the firmware ADD event even though > the device ADD event is being processed( modprobe is triggered by device > ADD event). Calling out from inside the kernel and blocking in a firmware loading userspace transaction during module_init() is kind of weird. The firmware loading call should not rely on a fully functional userspace, and modprobe should not hang and block until the firmware request is handled. The firmware should be requested asynchronously or from a different context as module_init(). It depends on the type of driver/hardware what's the best approach here. Thanks, Kay -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/