On Sun, 2006-02-19 at 08:30 -0600, James Bottomley wrote:
> Yes, thanks ... although I think there's still value to wrappering
> work_struct (a bit like kref wrappers atomic_t).
OK, so how about this?
James
[PATCH] add execute_in_process_context() API
We have several points in the SCSI stack (p
I don't think anybody claimed this isn't a regression for the 600X.
>
>>> I narrowed it further. The short story is that this commit (diff
>>> below sig) makes the second S3 sleep go into the endless loop, if
>>> the loaded modules are exactly thermal, processor, intel_agp, and
>>> agpgart:
>
On Sat, 2006-02-18 at 15:16 -0500, Alan Stern wrote:
> The test should be in_atomic(), not in_interrupt().
There's a long prior discussion of why it has to be in_interrupt()
James
---
This SF.net email is sponsored by: Splunk Inc. Do you gre
On Sat, 2006-02-18 at 13:03 +0300, Sergey Vlasov wrote:
> After removing kfree(), which was here in the initial implementation,
> this function became a thunk which does nothing useful - we can just
> stick fn and data directly into work_struct.
Yes, thanks ... although I think there's still value
>>> I don't think anybody claimed this isn't a regression for the 600X.
>> I narrowed it further. The short story is that this commit (diff
>> below sig) makes the second S3 sleep go into the endless loop, if
>> the loaded modules are exactly thermal, processor, intel_agp, and
>> agpgart:
> If y
On Fri, Feb 17, 2006 at 04:42:43PM -0800, James Bottomley wrote:
> +static void execute_in_process_context_work(void *data)
> +{
> + void (*fn)(void *data);
> + struct execute_work *ew = data;
> +
> + fn = ew->fn;
> + data = ew->data;
> +
> + fn(data);
> +}
After removing kfree
On Fri, 17 Feb 2006, James Bottomley wrote:
> +/**
> + * execute_in_process_context - reliably execute the routine with user
> context
> + * @fn: the function to execute
> + * @data:data to pass to the function
> + *
> + * Executes the function immediately if process context is a
>> I don't think anybody claimed this isn't a regression for the 600X.
>
>I narrowed it further. The short story is that this commit (diff below
>sig) makes the second S3 sleep go into the endless loop, if the loaded
>modules are exactly thermal, processor, intel_agp, and agpgart:
If you believe
