On Wed, Jun 25, 2014 at 2:51 PM, Luis R. Rodriguez wrote:
> I'll go ahead and test this on the other
> distribution you mentioned you had issues, curious what could trigger a
> timeout
> failure there that would be distribution specific.
I've tested this on SLE12 and see no issues as well.
On Wed, Jun 25, 2014 at 04:00:19AM +0200, Luis R. Rodriguez wrote:
> On Wed, Jun 25, 2014 at 01:39:51AM +0200, Luis R. Rodriguez wrote:
> > On Tue, Jun 24, 2014 at 09:34:19AM -0700, Casey Leedom wrote:
> > > On 06/24/14 08:55, Casey Leedom wrote:
> > >> On 06/23/14 17:29, Luis R. Rodriguez wrote:
On Wed, Jun 25, 2014 at 04:00:19AM +0200, Luis R. Rodriguez wrote:
On Wed, Jun 25, 2014 at 01:39:51AM +0200, Luis R. Rodriguez wrote:
On Tue, Jun 24, 2014 at 09:34:19AM -0700, Casey Leedom wrote:
On 06/24/14 08:55, Casey Leedom wrote:
On 06/23/14 17:29, Luis R. Rodriguez wrote:
So I
On Wed, Jun 25, 2014 at 2:51 PM, Luis R. Rodriguez mcg...@suse.com wrote:
I'll go ahead and test this on the other
distribution you mentioned you had issues, curious what could trigger a
timeout
failure there that would be distribution specific.
I've tested this on SLE12 and see no issues as
On Wed, Jun 25, 2014 at 01:39:51AM +0200, Luis R. Rodriguez wrote:
> On Tue, Jun 24, 2014 at 09:34:19AM -0700, Casey Leedom wrote:
> > On 06/24/14 08:55, Casey Leedom wrote:
> >> On 06/23/14 17:29, Luis R. Rodriguez wrote:
> > So I just did this for a normal modprobe (after the system is up):
>
On Tue, Jun 24, 2014 at 09:34:19AM -0700, Casey Leedom wrote:
> On 06/24/14 08:55, Casey Leedom wrote:
>> On 06/23/14 17:29, Luis R. Rodriguez wrote:
> So I just did this for a normal modprobe (after the system is up):
>
> JiffiesProcess
>
On 06/24/14 08:55, Casey Leedom wrote:
On 06/23/14 17:29, Luis R. Rodriguez wrote:
On Mon, Jun 23, 2014 at 12:06:48PM -0700, Casey Leedom wrote:
Also, it might be useful if there was a way for the driver
module to "tell" the timeout mechanism that forward progress _is_ being
made so it
On 06/23/14 17:29, Luis R. Rodriguez wrote:
On Mon, Jun 23, 2014 at 12:06:48PM -0700, Casey Leedom wrote:
I've looked through the patch and I might be wrong, but it appears that
all the uses of the asynchronous request_firmware_nowait() are followed
immediately by wait_for_completion()
On 06/23/14 17:29, Luis R. Rodriguez wrote:
On Mon, Jun 23, 2014 at 12:06:48PM -0700, Casey Leedom wrote:
I've looked through the patch and I might be wrong, but it appears that
all the uses of the asynchronous request_firmware_nowait() are followed
immediately by wait_for_completion()
On 06/24/14 08:55, Casey Leedom wrote:
On 06/23/14 17:29, Luis R. Rodriguez wrote:
On Mon, Jun 23, 2014 at 12:06:48PM -0700, Casey Leedom wrote:
Also, it might be useful if there was a way for the driver
module to tell the timeout mechanism that forward progress _is_ being
made so it
On Tue, Jun 24, 2014 at 09:34:19AM -0700, Casey Leedom wrote:
On 06/24/14 08:55, Casey Leedom wrote:
On 06/23/14 17:29, Luis R. Rodriguez wrote:
So I just did this for a normal modprobe (after the system is up):
JiffiesProcess
On Wed, Jun 25, 2014 at 01:39:51AM +0200, Luis R. Rodriguez wrote:
On Tue, Jun 24, 2014 at 09:34:19AM -0700, Casey Leedom wrote:
On 06/24/14 08:55, Casey Leedom wrote:
On 06/23/14 17:29, Luis R. Rodriguez wrote:
So I just did this for a normal modprobe (after the system is up):
On Mon, Jun 23, 2014 at 12:06:48PM -0700, Casey Leedom wrote:
> I've looked through the patch and I might be wrong, but it appears that
> all the uses of the asynchronous request_firmware_nowait() are followed
> immediately by wait_for_completion() calls which essentially would be the
> same
I've looked through the patch and I might be wrong, but it appears
that all the uses of the asynchronous request_firmware_nowait() are
followed immediately by wait_for_completion() calls which essentially
would be the same as the previous code with an added layer of
mechanism. Am I missing
I've looked through the patch and I might be wrong, but it appears
that all the uses of the asynchronous request_firmware_nowait() are
followed immediately by wait_for_completion() calls which essentially
would be the same as the previous code with an added layer of
mechanism. Am I missing
On Mon, Jun 23, 2014 at 12:06:48PM -0700, Casey Leedom wrote:
I've looked through the patch and I might be wrong, but it appears that
all the uses of the asynchronous request_firmware_nowait() are followed
immediately by wait_for_completion() calls which essentially would be the
same as
From: "Luis R. Rodriguez"
Its reported that loading the cxgb4 can take over 1 minute,
use the more sane request_firmware_nowait() API call just
in case this amount of time is causing issues. The driver
uses the firmware API 3 times, one for the firmware, one
for configuration and another one for
From: Luis R. Rodriguez mcg...@suse.com
Its reported that loading the cxgb4 can take over 1 minute,
use the more sane request_firmware_nowait() API call just
in case this amount of time is causing issues. The driver
uses the firmware API 3 times, one for the firmware, one
for configuration and
18 matches
Mail list logo
