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
Andrew Morton wrote:
We still have some serious bugs, several of which are in 2.6.15 as well:
[...]
- Helge Hafting reports a usb printer regression - I don't know if that's
still live?
I tried printing four pages of graphichs with 2.6.16-rc3-mm1
and it worked fine. When I had the prob
>>> 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 06:12:04PM -0800, Roland Dreier wrote:
> > +int execute_in_process_context(void (*fn)(void *data), void *data,
> > + struct execute_work *ew)
> > +{
> > + if (!in_interrupt()) {
> > + fn(data);
> > + return 0;
> > + }
>
> I
> +/**
> + * 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 available,
> + * otherwise schedules the
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
Hi!
> That's suspend-to-disk, yes?
>
> Dave, would you have the 2.6.15-1.1830_FC4 -> 2.6.15-1.1831_FC4 details
> handy? There surely can't be much difference?
>
> There seem to be several ACPI problems there. Do we have a reliable means
> of feeding such reports up into the (for example) acpi
On Thu, 2006-02-16 at 21:01 +0100, Jens Axboe wrote:
> That's what I suggested in the first place as well. I still think it's a
> good idea, fwiw :)
OK smarty pants ... some of us are a bit slower on the uptake. How
about this then. It won't solve the target problem, but it will solve
the device
On Fri, Feb 17, 2006 at 04:42:43PM -0800, James Bottomley wrote:
> On Thu, 2006-02-16 at 21:01 +0100, Jens Axboe wrote:
> > That's what I suggested in the first place as well. I still think it's a
> > good idea, fwiw :)
>
> OK smarty pants ... some of us are a bit slower on the uptake. How
> abou
On Thu, 2006-02-16 at 17:12 +, Russell King wrote:
> This is probably an idiotic question, but if there's something in the
> scsi release handler can't be called in non-process context, why can't
> scsi queue up the release processing via the work API itself, rather
> than having to have this a
On Thu, Feb 16 2006, James Bottomley wrote:
> On Thu, 2006-02-16 at 18:18 +, Russell King wrote:
> > Maybe implementing it as a helper function would be the best and
> > simplest solution?
> >
> > static void scsi_release(struct device *dev)
> > {
> > schedule_release_process(dev, scsi_rel
On Thu, 2006-02-16 at 18:09 +, Russell King wrote:
> where scsi_release() is the function called by the device model on the
> last put of a scsi device.
>
> I guess is more or less what you're trying to do invasively via the
> driver model.
Yes ... except I think more than just SCSI has the p
Russell King wrote:
On Wed, Feb 15, 2006 at 08:56:00PM -0500, James Bottomley wrote:
[...]
OK, this is what I'm proposing as the device model fix. What it does is
thread context checking APIs throughout the device subsystem. SCSI can
then use it simply via device_put_process_context().
[...]
On Wed, Feb 15, 2006 at 08:56:00PM -0500, James Bottomley wrote:
> On Tue, 2006-02-14 at 10:34 -0600, James Bottomley wrote:
> > Well, I can't solve the problem that it requires memory allocation from
> > IRQ context to operate. Based on that, it's an unsafe interface. I'm
> > going to put it ins
On Thu, Feb 16, 2006 at 10:14:31AM -0800, James Bottomley wrote:
> On Thu, 2006-02-16 at 18:09 +, Russell King wrote:
> > where scsi_release() is the function called by the device model on the
> > last put of a scsi device.
> >
> > I guess is more or less what you're trying to do invasively vi
On Thu, Feb 16, 2006 at 09:57:32AM -0800, James Bottomley wrote:
> On Thu, 2006-02-16 at 17:12 +, Russell King wrote:
> > This is probably an idiotic question, but if there's something in the
> > scsi release handler can't be called in non-process context, why can't
> > scsi queue up the releas
On Thu, 2006-02-16 at 18:18 +, Russell King wrote:
> Maybe implementing it as a helper function would be the best and
> simplest solution?
>
> static void scsi_release(struct device *dev)
> {
> schedule_release_process(dev, scsi_release_process);
> }
>
> where schedule_release_process()
On Tue, 2006-02-14 at 10:34 -0600, James Bottomley wrote:
> Well, I can't solve the problem that it requires memory allocation from
> IRQ context to operate. Based on that, it's an unsafe interface. I'm
> going to put it inside SCSI for 2.6.16, since it's better than what we
> have now, but I don
>> 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
On Mon, 2006-02-13 at 20:08 -0700, Michal Jaegermann wrote:
> On Mon, Feb 13, 2006 at 09:57:48AM +0100, Arjan van de Ven wrote:
> > On Mon, 2006-02-13 at 00:12 -0800, Andrew Morton wrote:
> > >
> > > I think we can assume that it will be seen there. 2.6.16 is going into
> > > distros and will hav
On Mon, 2006-02-13 at 12:38 -0800, Greg KH wrote:
> > - Nasty warnings from scsi about kobject-layer things being called
> from
> > irq context. James has a push-it-to-process-context patch which
> sadly
> > assumes kmalloc() is immortal, but no other fix seems to have
> offered
> > itself.
Michal Jaegermann <[EMAIL PROTECTED]> wrote:
>
> On Mon, Feb 13, 2006 at 09:57:48AM +0100, Arjan van de Ven wrote:
> > On Mon, 2006-02-13 at 00:12 -0800, Andrew Morton wrote:
> > >
> > > I think we can assume that it will be seen there. 2.6.16 is going into
> > > distros and will have more exposu
On Mon, Feb 13, 2006 at 09:57:48AM +0100, Arjan van de Ven wrote:
> On Mon, 2006-02-13 at 00:12 -0800, Andrew Morton wrote:
> >
> > I think we can assume that it will be seen there. 2.6.16 is going into
> > distros and will have more exposure than 2.6.15,
>
> 2.6.15 went into distros as well, s
> 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:
53f11d4ff8797bcceaf0
> reports than the usptream developers, yet we hear so little about it>
the number of quality reports (eg enough information to do anything)
isn't that high; Dave is pretty good in sending the good ones on, it
often takes time though to get all the basic info..
--
On Mon, Feb 13, 2006 at 07:28:38PM -0800, Andrew Morton wrote:
> Michal Jaegermann <[EMAIL PROTECTED]> wrote:
> >
> > On Mon, Feb 13, 2006 at 09:57:48AM +0100, Arjan van de Ven wrote:
> > > On Mon, 2006-02-13 at 00:12 -0800, Andrew Morton wrote:
> > > >
> > > > I think we can assume that it will b
On Mon, Feb 13, 2006 at 07:28:38PM -0800, Andrew Morton wrote:
> Michal Jaegermann <[EMAIL PROTECTED]> wrote:
> >
> > On Mon, Feb 13, 2006 at 09:57:48AM +0100, Arjan van de Ven wrote:
> > > On Mon, 2006-02-13 at 00:12 -0800, Andrew Morton wrote:
> > > >
> > > > I think we can assume that it
>i have a bug similar to:
>http://bugzilla.kernel.org/show_bug.cgi?id=6038 (marked as blocking by
>Andrew) on my laptop.
6038 is in NEEDINFO.
If no submitter participates, it may never get fixed.
-Len
---
This SF.net email is sponsored by: Spl
On Mon, Feb 13, 2006 at 10:30:56PM -0500, Lee Revell wrote:
> On Mon, 2006-02-13 at 20:08 -0700, Michal Jaegermann wrote:
> > On Mon, Feb 13, 2006 at 09:57:48AM +0100, Arjan van de Ven wrote:
> > >
> > > 2.6.15 went into distros as well, such as Fedora Core 4 ;)
> >
> > And promptly broke laptop
On Mon, 2006-02-13 at 20:08 -0700, Michal Jaegermann wrote:
> On Mon, Feb 13, 2006 at 09:57:48AM +0100, Arjan van de Ven wrote:
> > On Mon, 2006-02-13 at 00:12 -0800, Andrew Morton wrote:
> > >
> > > I think we can assume that it will be seen there. 2.6.16 is going into
> > > distros and will hav
>> >- In http://bugzilla.kernel.org/show_bug.cgi?id=5989, Sanjoy
>> >Mahajan has another regression, but he's off collecting more info.
>>
>> We're talking here about a system from 1999 where Windows 98
>> refuses to run in ACPI mode and instead runs in APM mode.
>
>If it worked before a change
On Sun, 2006-02-12 at 19:05 -0800, Andrew Morton wrote:
> We still have some serious bugs, several of which are in 2.6.15 as well:
> - Benjamin LaHaise <[EMAIL PROTECTED]> had an NFS problem ("NFS processes
> gettting stuck in D with currrent git").
...but which was apparently not repeatable:
At Mon, 13 Feb 2006 15:34:28 +0100,
Patrizio Bassi wrote:
>
> Takashi Iwai ha scritto:
> > At Mon, 13 Feb 2006 14:31:23 +0100,
> > Patrizio Bassi wrote:
> >
> >> Takashi Iwai ha scritto:
> >>
> >>> At Mon, 13 Feb 2006 13:37:55 +0100,
> >>> Patrizio Bassi wrote:
> >>>
> >>>
>
>- http://bugzilla.kernel.org/show_bug.cgi?id=6049 - another acpi
> regression. We have the actual offending commit here.
per my note in the bug report, I believe that this failure
is not related to the "offending commit", and thus that commit
should not be reverted. I believe that this failu
At Sun, 12 Feb 2006 19:05:20 -0800,
Andrew Morton wrote:
>
> - Patrizio Bassi <[EMAIL PROTECTED]> has an alsa suspend
> regression ("alsa suspend/resume continues to fail for ens1370")
It's not a "regression". PM didn't work with ens1370 at all in the
eralier version.
About the problem there,
On Sun, Feb 12 2006, Andrew Morton wrote:
>
> We still have some serious bugs, several of which are in 2.6.15 as well:
>
> - The scsi_cmd leak, which I don't think is fixed.
It is fixed in 2.6.16-rcX.
> - The some-x86_64-boxes-use-GFP_DMA-from-bio-layer bug, which causes
> oom-killings.
Stil
At Mon, 13 Feb 2006 13:37:55 +0100,
Patrizio Bassi wrote:
>
> Takashi Iwai ha scritto:
> > At Sun, 12 Feb 2006 19:05:20 -0800,
> > Andrew Morton wrote:
> >
> >> - Patrizio Bassi <[EMAIL PROTECTED]> has an alsa suspend
> >> regression ("alsa suspend/resume continues to fail for ens1370")
> >>
At Mon, 13 Feb 2006 14:31:23 +0100,
Patrizio Bassi wrote:
>
> Takashi Iwai ha scritto:
> > At Mon, 13 Feb 2006 13:37:55 +0100,
> > Patrizio Bassi wrote:
> >
> >> Takashi Iwai ha scritto:
> >>
> >>> At Sun, 12 Feb 2006 19:05:20 -0800,
> >>> Andrew Morton wrote:
> >>>
> >>>
>
> I think we can assume that it will be seen there. 2.6.16 is going into
> distros and will have more exposure than 2.6.15, let alone
> 2.6.16-rcX.
A related point is that S3 sleep/wake problems are very difficult to
debug. The bug is often not reproducible (I've had a few of those).
Or it happe
Takashi Iwai ha scritto:
> At Mon, 13 Feb 2006 14:31:23 +0100,
> Patrizio Bassi wrote:
>
>> Takashi Iwai ha scritto:
>>
>>> At Mon, 13 Feb 2006 13:37:55 +0100,
>>> Patrizio Bassi wrote:
>>>
>>>
Takashi Iwai ha scritto:
> At Sun, 12 Feb 2006 19:05:2
"Brown, Len" <[EMAIL PROTECTED]> wrote:
>
> My point is that it that on the grand scale of bugs serious enough
> to have an effect on the course of 2.6.16, this one doesn't qualify
> unless the same issue is seen on other systems.
I think we can assume that it will be seen there. 2.6.16 is goin
On Sun, 2006-02-12 at 19:05 -0800, Andrew Morton wrote:
> - The scsi_cmd leak, which I don't think is fixed.
Erm, you mean the leak caused by flush barriers? That was verified as
fixed (albeit accidentally) in 2.6.16-rc1.
James
---
This SF.
On Mon, 2006-02-13 at 00:12 -0800, Andrew Morton wrote:
> "Brown, Len" <[EMAIL PROTECTED]> wrote:
> >
> > My point is that it that on the grand scale of bugs serious enough
> > to have an effect on the course of 2.6.16, this one doesn't qualify
> > unless the same issue is seen on other systems.
Andrew Morton ha scritto:
> We still have some serious bugs, several of which are in 2.6.15 as well:
>
> - The scsi_cmd leak, which I don't think is fixed.
>
> - The some-x86_64-boxes-use-GFP_DMA-from-bio-layer bug, which causes
> oom-killings.
>
> - The skbuff_head_cache leak, which has been aro
On Monday 13 February 2006 14:51, Takashi Iwai wrote:
> At Mon, 13 Feb 2006 14:09:51 +0100,
> Rafael J. Wysocki wrote:
> >
> > On Monday 13 February 2006 13:02, Takashi Iwai wrote:
> > > At Sun, 12 Feb 2006 19:05:20 -0800,
> > > Andrew Morton wrote:
> > > >
> > > > - Patrizio Bassi <[EMAIL PROTEC
At Mon, 13 Feb 2006 14:09:51 +0100,
Rafael J. Wysocki wrote:
>
> On Monday 13 February 2006 13:02, Takashi Iwai wrote:
> > At Sun, 12 Feb 2006 19:05:20 -0800,
> > Andrew Morton wrote:
> > >
> > > - Patrizio Bassi <[EMAIL PROTECTED]> has an alsa suspend
> > > regression ("alsa suspend/resume con
> systems newer than 6 years old.
According to the sticker on the bottom, this model was made in
04/2000, so the 6 years is right.
> We're talking here about a system from 1999 where Windows 98 refuses
> to run in ACPI mode and instead runs in APM mode.
I haven't tried Windows 98 on this machine
On Sun, Feb 12, 2006 at 07:05:20PM -0800, Andrew Morton wrote:
>
> We still have some serious bugs, several of which are in 2.6.15 as well:
>
> - Nathan's "sysfs-related oops during module unload", which Greg seems to
> have under control.
Yes, this isn't a "regression" but has been there for
On Sun, 2006-02-12 at 19:05 -0800, Andrew Morton wrote:
> We still have some serious bugs, several of which are in 2.6.15 as well:
>
> - The scsi_cmd leak, which I don't think is fixed.
didn't this got nailed down to a 2.6.15 specific queueing bug, fixed in
2.6.16-rc ?
--
We still have some serious bugs, several of which are in 2.6.15 as well:
- The scsi_cmd leak, which I don't think is fixed.
- The some-x86_64-boxes-use-GFP_DMA-from-bio-layer bug, which causes
oom-killings.
- The skbuff_head_cache leak, which has been around since at least
2.6.11. Another
Takashi Iwai ha scritto:
> At Sun, 12 Feb 2006 19:05:20 -0800,
> Andrew Morton wrote:
>
>> - Patrizio Bassi <[EMAIL PROTECTED]> has an alsa suspend
>> regression ("alsa suspend/resume continues to fail for ens1370")
>>
>
> It's not a "regression". PM didn't work with ens1370 at all in th
> In http://bugzilla.kernel.org/show_bug.cgi?id=5989, Sanjoy Mahajan has
> another regression, but he's off collecting more info.
I'm nearly done with bisecting (spent a day on a wild bisect goose
chase due to being careless) and I'm 95% sure the problem is
introduced by:
commit b8e4d89357fc43461
From: "Brown, Len" <[EMAIL PROTECTED]>
Date: Mon, 13 Feb 2006 02:07:50 -0500
> >- In http://bugzilla.kernel.org/show_bug.cgi?id=5989, Sanjoy
> >Mahajan has another regression, but he's off collecting more info.
>
> We're talking here about a system from 1999 where Windows 98
> refuses to run in
On Monday 13 February 2006 13:02, Takashi Iwai wrote:
> At Sun, 12 Feb 2006 19:05:20 -0800,
> Andrew Morton wrote:
> >
> > - Patrizio Bassi <[EMAIL PROTECTED]> has an alsa suspend
> > regression ("alsa suspend/resume continues to fail for ens1370")
>
> It's not a "regression". PM didn't work w
Andrew Morton wrote:
- http://bugzilla.kernel.org/show_bug.cgi?id=5914 - a sata bug (which is
quite unremarkable :(), but this one is reported to eat filesystems.
Issue closed, as the bug notes...
Jeff
---
This SF.net email is
Takashi Iwai ha scritto:
> At Mon, 13 Feb 2006 13:37:55 +0100,
> Patrizio Bassi wrote:
>
>> Takashi Iwai ha scritto:
>>
>>> At Sun, 12 Feb 2006 19:05:20 -0800,
>>> Andrew Morton wrote:
>>>
>>>
- Patrizio Bassi <[EMAIL PROTECTED]> has an alsa suspend
regression ("alsa s
>- In http://bugzilla.kernel.org/show_bug.cgi?id=5989, Sanjoy
>Mahajan has another regression, but he's off collecting more info.
We're talking here about a system from 1999 where Windows 98
refuses to run in ACPI mode and instead runs in APM mode.
So I don't consider a regression on this box
Adrian Bunk wrote:
On Sun, Feb 12, 2006 at 07:05:20PM -0800, Andrew Morton wrote:
...
- Various reports similar to
http://bugzilla.kernel.org/show_bug.cgi?id=6011, seemingly related to USB
PCI quirk handling.
...
This bug contains a patch.
What is the status of this patch?
The patch is
On Sun, Feb 12, 2006 at 07:05:20PM -0800, Andrew Morton wrote:
>...
> - Various reports similar to
> http://bugzilla.kernel.org/show_bug.cgi?id=6011, seemingly related to USB
> PCI quirk handling.
>...
This bug contains a patch.
What is the status of this patch?
cu
Adrian
--
"Is th
63 matches
Mail list logo
