Hi!
> > > With the USB subsystem I have followed the approach taken by the PM
> > > core, which is that tasks are frozen. But one can -- and Linus has on
> > > at least one occasion -- make a good case that tasks should be left
> > > running while only I/O is frozen. This would require the
On Mon, 4 Jun 2007, Pavel Machek wrote:
> > With the USB subsystem I have followed the approach taken by the PM
> > core, which is that tasks are frozen. But one can -- and Linus has on
> > at least one occasion -- make a good case that tasks should be left
> > running while only I/O is frozen.
On Mon, 4 Jun 2007, Pavel Machek wrote:
With the USB subsystem I have followed the approach taken by the PM
core, which is that tasks are frozen. But one can -- and Linus has on
at least one occasion -- make a good case that tasks should be left
running while only I/O is frozen. This
Hi!
With the USB subsystem I have followed the approach taken by the PM
core, which is that tasks are frozen. But one can -- and Linus has on
at least one occasion -- make a good case that tasks should be left
running while only I/O is frozen. This would require the subsystem to
Hi!
> > > The theoretical answer is that it behaves the way we want. The kernel
> > > thread does selective resumes in response to device requests. If such
> > > a request comes in while the system is asleep it will awaken the
> > > system; so it's only logical that a request coming in while
Hi!
The theoretical answer is that it behaves the way we want. The kernel
thread does selective resumes in response to device requests. If such
a request comes in while the system is asleep it will awaken the
system; so it's only logical that a request coming in while the system
Hi!
> > >> Userspace should handle the async request just fine when it comes
> > >> back
> > >> running, regardless of the time it was submitted.
> > >
> > > Okay, so the solution is to convert the drivers to use
> > > request_firmware_nowait() instead of request_firmware() in
> > > their
Hi!
Userspace should handle the async request just fine when it comes
back
running, regardless of the time it was submitted.
Okay, so the solution is to convert the drivers to use
request_firmware_nowait() instead of request_firmware() in
their .resume()
routines.
On Monday 28 May 2007 4:48 am, Michael-Luke Jones wrote:
> On 28 May 2007, at 08:43, Rafael J. Wysocki wrote:
>
> >> Seems, that's just the broken synchronous firmware loading interface
> >> with the useless timeout handling. The nowait version of the same
> >> loader
> >> doesn't time out, and
On Monday 28 May 2007 5:06 am, Kay Sievers wrote:
> Well, 10 seconds are just to short for userspace to react on some
> setups, from tiny boxes which are busy, to 512 CPU boxes enumerating
> thousands of devices, all had problems here. Any timeout for a
> firmware-request is just a broken concept,
On Tue, 29 May 2007, David Brownell wrote:
> On Monday 28 May 2007, Alan Stern wrote:
>
> > This is a matter of one's philosophy. In suspend-to-RAM, should tasks
> > be frozen or should I/O queues be frozen?
> >
> > With the USB subsystem I have followed the approach taken by the PM
> > core,
On Sunday 27 May 2007 4:45 pm, Michael-Luke Jones wrote:
> (Slightly OT: A particularly nasty race is when an initramfs
> userspace is present, but firmware loading cannot occur because init
> has not run, so proc hasn't been mounted, so a hotplug event handler
> cannot be registered,
On Monday 28 May 2007, Alan Stern wrote:
> This is a matter of one's philosophy. In suspend-to-RAM, should tasks
> be frozen or should I/O queues be frozen?
>
> With the USB subsystem I have followed the approach taken by the PM
> core, which is that tasks are frozen. But one can -- and Linus
On Monday 28 May 2007, Alan Stern wrote:
This is a matter of one's philosophy. In suspend-to-RAM, should tasks
be frozen or should I/O queues be frozen?
With the USB subsystem I have followed the approach taken by the PM
core, which is that tasks are frozen. But one can -- and Linus has
On Sunday 27 May 2007 4:45 pm, Michael-Luke Jones wrote:
(Slightly OT: A particularly nasty race is when an initramfs
userspace is present, but firmware loading cannot occur because init
has not run, so proc hasn't been mounted, so a hotplug event handler
cannot be registered, despite
On Tue, 29 May 2007, David Brownell wrote:
On Monday 28 May 2007, Alan Stern wrote:
This is a matter of one's philosophy. In suspend-to-RAM, should tasks
be frozen or should I/O queues be frozen?
With the USB subsystem I have followed the approach taken by the PM
core, which is
On Monday 28 May 2007 5:06 am, Kay Sievers wrote:
Well, 10 seconds are just to short for userspace to react on some
setups, from tiny boxes which are busy, to 512 CPU boxes enumerating
thousands of devices, all had problems here. Any timeout for a
firmware-request is just a broken concept, the
On Monday 28 May 2007 4:48 am, Michael-Luke Jones wrote:
On 28 May 2007, at 08:43, Rafael J. Wysocki wrote:
Seems, that's just the broken synchronous firmware loading interface
with the useless timeout handling. The nowait version of the same
loader
doesn't time out, and should not
On Mon, 28 May 2007, Pavel Machek wrote:
> > The theoretical answer is that it behaves the way we want. The kernel
> > thread does selective resumes in response to device requests. If such
> > a request comes in while the system is asleep it will awaken the
> > system; so it's only logical
Hi!
> >In fact, I'd like drivers to use notifiers to actually
> >load the firmware into
> >memory before hibernation/suspend. Namely, if there's
> >PM_PRE_FREEZE, the
> >driver calls request_firmware() from within the
> >notifier and saves the firmware
> >in memory for future use, if need be.
Hi!
> > > I can't speak for the second example, but there's a good reason the
> > > first example works this way. It's not a matter of races; the problem
> > > is that the kernel thread's job is to selectively suspend and resume
> > > devices. We don't want it doing this while a system sleep is
On 5/28/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
On Monday, 28 May 2007 17:55, Alan Stern wrote:
> You're using the PM_PRE_FREEZE and PM_POST_THAW notifiers for both this
> and the userspace helper change. Is it your intention that drivers
> should continue to request these services but
On Mon, 28 May 2007, Matthew Garrett wrote:
> On Mon, May 28, 2007 at 12:43:36PM -0400, Alan Stern wrote:
> > On Mon, 28 May 2007, Matthew Garrett wrote:
> > > On Mon, May 28, 2007 at 12:09:30PM -0400, Alan Stern wrote:
> > >
> > > > I can't speak for the second example, but there's a good
On Monday, 28 May 2007 17:55, Alan Stern wrote:
> On Sun, 27 May 2007, Rafael J. Wysocki wrote:
>
> > From: Rafael J. Wysocki <[EMAIL PROTECTED]>
> >
> > Use a hibernation and suspend notifier to disable the firmware requesting
> > mechanism before a hibernation/suspend and enable it after the
On Mon, May 28, 2007 at 12:43:36PM -0400, Alan Stern wrote:
> On Mon, 28 May 2007, Matthew Garrett wrote:
> > On Mon, May 28, 2007 at 12:09:30PM -0400, Alan Stern wrote:
> >
> > > I can't speak for the second example, but there's a good reason the
> > > first example works this way. It's not a
On Mon, 28 May 2007, Matthew Garrett wrote:
> On Mon, May 28, 2007 at 12:09:30PM -0400, Alan Stern wrote:
>
> > I can't speak for the second example, but there's a good reason the
> > first example works this way. It's not a matter of races; the problem
> > is that the kernel thread's job is to
On Mon, May 28, 2007 at 12:09:30PM -0400, Alan Stern wrote:
> I can't speak for the second example, but there's a good reason the
> first example works this way. It's not a matter of races; the problem
> is that the kernel thread's job is to selectively suspend and resume
> devices. We don't
On Sun, 27 May 2007, Matthew Garrett wrote:
> > BTW, I know of two subsystems that want their kernel threads to be frozen
> > for
> > synchronization purposes. Please see these messages:
> >
> > 1)
> > https://lists.linux-foundation.org/pipermail/linux-pm/2007-May/012592.html
> > (plus follow
On Sun, 27 May 2007, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <[EMAIL PROTECTED]>
>
> Use a hibernation and suspend notifier to disable the firmware requesting
> mechanism before a hibernation/suspend and enable it after the operation.
You're using the PM_PRE_FREEZE and PM_POST_THAW
On 28 May 2007, at 14:00, Pavel Machek wrote:
I'm too lazy to figure out how it currently works, but
I'll just state it is not my fault
Figuring out how a userspace/kernelspace interface works should not
rely on having to read kernelspace code. Unfortunately, in the case
of hotplug /
Hi!
> From: Rafael J. Wysocki <[EMAIL PROTECTED]>
>
> Use a hibernation and suspend notifier to disable the firmware requesting
> mechanism before a hibernation/suspend and enable it after the operation.
>
> Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
>
>
Hi!
> >From: Rafael J. Wysocki <[EMAIL PROTECTED]>
> >
> >Use a hibernation and suspend notifier to disable the firmware
> >requesting
> >mechanism before a hibernation/suspend and enable it after the
> >operation.
> >
> >Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
> >
> >
Hi!
> *Grumble ahead*
> Unfortunately, I don't properly understand the uevent interface, so
> some of the above may be inaccurate. This is *not* my fault as there
> is no decent documentation (and btw, telling me to write the
Translated: "I don't know what I'm talking about, but I still
On Mon, 2007-05-28 at 13:26 +0100, Michael-Luke Jones wrote:
> On 28 May 2007, at 12:51, Kay Sievers wrote:
>
> > Either the whole idea of userspace firmware-loading should be
> > considered
> > as a problem impossible to do right because of its unsolvable side
> > effects. Or at least
On 28 May 2007, at 12:51, Kay Sievers wrote:
Either the whole idea of userspace firmware-loading should be
considered
as a problem impossible to do right because of its unsolvable side
effects. Or at least releasing loaded firmware should be the exception
for drivers which can be sure, that
On 28 May 2007, at 13:01, Kay Sievers wrote:
In our development model, users of an interface are expected to
improve
it, because nobody else really knows what's needed. That unfortunately
didn't happen so far.
Thanks for responding :)
The fact that no-one is told to use the new right way
On Mon, 2007-05-28 at 11:26 +0100, Michael-Luke Jones wrote:
> On 28 May 2007, at 10:06, Kay Sievers wrote:
>
> > The underlying issue are the driver authors, that's not so easy to
> > fix. :)
>
> Sorry, I know this maybe be unintentional, but comments like this
> make me somewhat angry.
It
On Mon, 2007-05-28 at 12:38 +0100, Michael-Luke Jones wrote:
> On 28 May 2007, at 12:24, Kay Sievers wrote:
>
> > A driver for a bootup-critical device like this should just never
> > release the firmware after the first load. There is absolutely no
> > point
> > in doing that.
>
> Bogus
> This functionality should also be written into the firmware-class
> (and this fact *is* acknowledged in the sparse documentation).
Feel free to submit documentation improvements.
Pavel
--
(english)
On 28 May 2007, at 12:24, Kay Sievers wrote:
A driver for a bootup-critical device like this should just never
release the firmware after the first load. There is absolutely no
point
in doing that.
Bogus argument: is a USB-Ethernet device which needs firmware loading
boot-up critical?
On Mon 2007-05-28 13:24:53, Kay Sievers wrote:
> On Mon, 2007-05-28 at 13:15 +0200, Pavel Machek wrote:
> > Hi!
> >
> > > > > > What exactly is the problem we see here? The timeout of the
> > > > > > firmware loader?
> > > > > > What goes wrong with frozen userspace, usually there is only a
> >
On Mon, 2007-05-28 at 13:15 +0200, Pavel Machek wrote:
> Hi!
>
> > > > > What exactly is the problem we see here? The timeout of the firmware
> > > > > loader?
> > > > > What goes wrong with frozen userspace, usually there is only a netlink
> > > > > message sent from the kernel, which should be
On Monday, 28 May 2007 13:15, Pavel Machek wrote:
> Hi!
>
> > > > > What exactly is the problem we see here? The timeout of the firmware
> > > > > loader?
> > > > > What goes wrong with frozen userspace, usually there is only a netlink
> > > > > message sent from the kernel, which should be
On Monday, 28 May 2007 10:30, Nigel Cunningham wrote:
> Hi.
>
> On Sun, 2007-05-27 at 23:45 +0200, Rafael J. Wysocki wrote:
> > On Sunday, 27 May 2007 22:49, Matthew Garrett wrote:
> > > On Sun, May 27, 2007 at 10:31:53PM +0200, Rafael J. Wysocki wrote:
> > > > From: Rafael J. Wysocki <[EMAIL
Hi!
> > > > What exactly is the problem we see here? The timeout of the firmware
> > > > loader?
> > > > What goes wrong with frozen userspace, usually there is only a netlink
> > > > message sent from the kernel, which should be received and handled
> > > > just fine when userspace is running
Now a technical rather than emotional response...
On 28 May 2007, at 10:06, Kay Sievers wrote:
At device driver load, firmware loading must be asynchronous. This is
because device driver init can occur before userspace runs and
registers a hotplug/uevent event handler. If device use is
On 28 May 2007, at 10:06, Kay Sievers wrote:
The underlying issue are the driver authors, that's not so easy to
fix. :)
Sorry, I know this maybe be unintentional, but comments like this
make me somewhat angry.
If there is no decent documentation as to how to do it the right way
(tm),
On Mon, 2007-05-28 at 09:48 +0100, Michael-Luke Jones wrote:
> On 28 May 2007, at 08:43, Rafael J. Wysocki wrote:
>
> >> Seems, that's just the broken synchronous firmware loading interface
> >> with the useless timeout handling. The nowait version of the same
> >> loader
> >> doesn't time out,
On 28 May 2007, at 08:43, Rafael J. Wysocki wrote:
Seems, that's just the broken synchronous firmware loading interface
with the useless timeout handling. The nowait version of the same
loader
doesn't time out, and should not have that problem. The sync version
should be removed from the
Hi.
On Sun, 2007-05-27 at 23:45 +0200, Rafael J. Wysocki wrote:
> On Sunday, 27 May 2007 22:49, Matthew Garrett wrote:
> > On Sun, May 27, 2007 at 10:31:53PM +0200, Rafael J. Wysocki wrote:
> > > From: Rafael J. Wysocki <[EMAIL PROTECTED]>
> > >
> > > Use a hibernation and suspend notifier to
On Monday, 28 May 2007 00:16, Kay Sievers wrote:
> On Sun, 2007-05-27 at 23:04 +0100, Matthew Garrett wrote:
> > On Sun, May 27, 2007 at 11:49:30PM +0200, Kay Sievers wrote:
> >
> > > What exactly is the problem we see here? The timeout of the firmware
> > > loader?
> > > What goes wrong with
On Monday, 28 May 2007 00:01, Matthew Garrett wrote:
> On Sun, May 27, 2007 at 11:45:03PM +0200, Rafael J. Wysocki wrote:
> > On Sunday, 27 May 2007 22:49, Matthew Garrett wrote:
> > > If we remove process freezing in STR, this should just work[1] without the
> > > need to complicate things.
> >
On Monday, 28 May 2007 00:01, Matthew Garrett wrote:
On Sun, May 27, 2007 at 11:45:03PM +0200, Rafael J. Wysocki wrote:
On Sunday, 27 May 2007 22:49, Matthew Garrett wrote:
If we remove process freezing in STR, this should just work[1] without the
need to complicate things.
Under
On Monday, 28 May 2007 00:16, Kay Sievers wrote:
On Sun, 2007-05-27 at 23:04 +0100, Matthew Garrett wrote:
On Sun, May 27, 2007 at 11:49:30PM +0200, Kay Sievers wrote:
What exactly is the problem we see here? The timeout of the firmware
loader?
What goes wrong with frozen
Hi.
On Sun, 2007-05-27 at 23:45 +0200, Rafael J. Wysocki wrote:
On Sunday, 27 May 2007 22:49, Matthew Garrett wrote:
On Sun, May 27, 2007 at 10:31:53PM +0200, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki [EMAIL PROTECTED]
Use a hibernation and suspend notifier to disable the
On 28 May 2007, at 08:43, Rafael J. Wysocki wrote:
Seems, that's just the broken synchronous firmware loading interface
with the useless timeout handling. The nowait version of the same
loader
doesn't time out, and should not have that problem. The sync version
should be removed from the
On Mon, 2007-05-28 at 09:48 +0100, Michael-Luke Jones wrote:
On 28 May 2007, at 08:43, Rafael J. Wysocki wrote:
Seems, that's just the broken synchronous firmware loading interface
with the useless timeout handling. The nowait version of the same
loader
doesn't time out, and should
On 28 May 2007, at 10:06, Kay Sievers wrote:
The underlying issue are the driver authors, that's not so easy to
fix. :)
Sorry, I know this maybe be unintentional, but comments like this
make me somewhat angry.
If there is no decent documentation as to how to do it the right way
(tm),
Now a technical rather than emotional response...
On 28 May 2007, at 10:06, Kay Sievers wrote:
At device driver load, firmware loading must be asynchronous. This is
because device driver init can occur before userspace runs and
registers a hotplug/uevent event handler. If device use is
Hi!
What exactly is the problem we see here? The timeout of the firmware
loader?
What goes wrong with frozen userspace, usually there is only a netlink
message sent from the kernel, which should be received and handled
just fine when userspace is running again.
Driver
On Monday, 28 May 2007 10:30, Nigel Cunningham wrote:
Hi.
On Sun, 2007-05-27 at 23:45 +0200, Rafael J. Wysocki wrote:
On Sunday, 27 May 2007 22:49, Matthew Garrett wrote:
On Sun, May 27, 2007 at 10:31:53PM +0200, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki [EMAIL PROTECTED]
On Monday, 28 May 2007 13:15, Pavel Machek wrote:
Hi!
What exactly is the problem we see here? The timeout of the firmware
loader?
What goes wrong with frozen userspace, usually there is only a netlink
message sent from the kernel, which should be received and handled
On Mon, 2007-05-28 at 13:15 +0200, Pavel Machek wrote:
Hi!
What exactly is the problem we see here? The timeout of the firmware
loader?
What goes wrong with frozen userspace, usually there is only a netlink
message sent from the kernel, which should be received and handled
On Mon 2007-05-28 13:24:53, Kay Sievers wrote:
On Mon, 2007-05-28 at 13:15 +0200, Pavel Machek wrote:
Hi!
What exactly is the problem we see here? The timeout of the
firmware loader?
What goes wrong with frozen userspace, usually there is only a
netlink
On 28 May 2007, at 12:24, Kay Sievers wrote:
A driver for a bootup-critical device like this should just never
release the firmware after the first load. There is absolutely no
point
in doing that.
Bogus argument: is a USB-Ethernet device which needs firmware loading
boot-up critical?
This functionality should also be written into the firmware-class
(and this fact *is* acknowledged in the sparse documentation).
Feel free to submit documentation improvements.
Pavel
--
(english)
On Mon, 2007-05-28 at 12:38 +0100, Michael-Luke Jones wrote:
On 28 May 2007, at 12:24, Kay Sievers wrote:
A driver for a bootup-critical device like this should just never
release the firmware after the first load. There is absolutely no
point
in doing that.
Bogus argument: is a
On Mon, 2007-05-28 at 11:26 +0100, Michael-Luke Jones wrote:
On 28 May 2007, at 10:06, Kay Sievers wrote:
The underlying issue are the driver authors, that's not so easy to
fix. :)
Sorry, I know this maybe be unintentional, but comments like this
make me somewhat angry.
It was the
On 28 May 2007, at 13:01, Kay Sievers wrote:
In our development model, users of an interface are expected to
improve
it, because nobody else really knows what's needed. That unfortunately
didn't happen so far.
Thanks for responding :)
The fact that no-one is told to use the new right way
On 28 May 2007, at 12:51, Kay Sievers wrote:
Either the whole idea of userspace firmware-loading should be
considered
as a problem impossible to do right because of its unsolvable side
effects. Or at least releasing loaded firmware should be the exception
for drivers which can be sure, that
On Mon, 2007-05-28 at 13:26 +0100, Michael-Luke Jones wrote:
On 28 May 2007, at 12:51, Kay Sievers wrote:
Either the whole idea of userspace firmware-loading should be
considered
as a problem impossible to do right because of its unsolvable side
effects. Or at least releasing loaded
Hi!
*Grumble ahead*
Unfortunately, I don't properly understand the uevent interface, so
some of the above may be inaccurate. This is *not* my fault as there
is no decent documentation (and btw, telling me to write the
Translated: I don't know what I'm talking about, but I still like to
Hi!
From: Rafael J. Wysocki [EMAIL PROTECTED]
Use a hibernation and suspend notifier to disable the firmware
requesting
mechanism before a hibernation/suspend and enable it after the
operation.
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
drivers/base/firmware_class.c |
Hi!
From: Rafael J. Wysocki [EMAIL PROTECTED]
Use a hibernation and suspend notifier to disable the firmware requesting
mechanism before a hibernation/suspend and enable it after the operation.
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
drivers/base/firmware_class.c | 36
On 28 May 2007, at 14:00, Pavel Machek wrote:
I'm too lazy to figure out how it currently works, but
I'll just state it is not my fault
Figuring out how a userspace/kernelspace interface works should not
rely on having to read kernelspace code. Unfortunately, in the case
of hotplug /
On Sun, 27 May 2007, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki [EMAIL PROTECTED]
Use a hibernation and suspend notifier to disable the firmware requesting
mechanism before a hibernation/suspend and enable it after the operation.
You're using the PM_PRE_FREEZE and PM_POST_THAW
On Sun, 27 May 2007, Matthew Garrett wrote:
BTW, I know of two subsystems that want their kernel threads to be frozen
for
synchronization purposes. Please see these messages:
1)
https://lists.linux-foundation.org/pipermail/linux-pm/2007-May/012592.html
(plus follow up)
2)
On Mon, May 28, 2007 at 12:09:30PM -0400, Alan Stern wrote:
I can't speak for the second example, but there's a good reason the
first example works this way. It's not a matter of races; the problem
is that the kernel thread's job is to selectively suspend and resume
devices. We don't want
On Mon, May 28, 2007 at 12:43:36PM -0400, Alan Stern wrote:
On Mon, 28 May 2007, Matthew Garrett wrote:
On Mon, May 28, 2007 at 12:09:30PM -0400, Alan Stern wrote:
I can't speak for the second example, but there's a good reason the
first example works this way. It's not a matter of
On Mon, 28 May 2007, Matthew Garrett wrote:
On Mon, May 28, 2007 at 12:09:30PM -0400, Alan Stern wrote:
I can't speak for the second example, but there's a good reason the
first example works this way. It's not a matter of races; the problem
is that the kernel thread's job is to
On Monday, 28 May 2007 17:55, Alan Stern wrote:
On Sun, 27 May 2007, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki [EMAIL PROTECTED]
Use a hibernation and suspend notifier to disable the firmware requesting
mechanism before a hibernation/suspend and enable it after the operation.
On Mon, 28 May 2007, Matthew Garrett wrote:
On Mon, May 28, 2007 at 12:43:36PM -0400, Alan Stern wrote:
On Mon, 28 May 2007, Matthew Garrett wrote:
On Mon, May 28, 2007 at 12:09:30PM -0400, Alan Stern wrote:
I can't speak for the second example, but there's a good reason the
On 5/28/07, Rafael J. Wysocki [EMAIL PROTECTED] wrote:
On Monday, 28 May 2007 17:55, Alan Stern wrote:
You're using the PM_PRE_FREEZE and PM_POST_THAW notifiers for both this
and the userspace helper change. Is it your intention that drivers
should continue to request these services but
Hi!
I can't speak for the second example, but there's a good reason the
first example works this way. It's not a matter of races; the problem
is that the kernel thread's job is to selectively suspend and resume
devices. We don't want it doing this while a system sleep is in
Hi!
In fact, I'd like drivers to use notifiers to actually
load the firmware into
memory before hibernation/suspend. Namely, if there's
PM_PRE_FREEZE, the
driver calls request_firmware() from within the
notifier and saves the firmware
in memory for future use, if need be. Later, when
On Mon, 28 May 2007, Pavel Machek wrote:
The theoretical answer is that it behaves the way we want. The kernel
thread does selective resumes in response to device requests. If such
a request comes in while the system is asleep it will awaken the
system; so it's only logical that a
On Sun, 2007-05-27 at 23:04 +0100, Matthew Garrett wrote:
> On Sun, May 27, 2007 at 11:49:30PM +0200, Kay Sievers wrote:
>
> > What exactly is the problem we see here? The timeout of the firmware loader?
> > What goes wrong with frozen userspace, usually there is only a netlink
> > message sent
On Sun, May 27, 2007 at 11:49:30PM +0200, Kay Sievers wrote:
> What exactly is the problem we see here? The timeout of the firmware loader?
> What goes wrong with frozen userspace, usually there is only a netlink
> message sent from the kernel, which should be received and handled
> just fine
On Sun, May 27, 2007 at 11:45:03PM +0200, Rafael J. Wysocki wrote:
> On Sunday, 27 May 2007 22:49, Matthew Garrett wrote:
> > If we remove process freezing in STR, this should just work[1] without the
> > need to complicate things.
>
> Under the (optimistic, IMO) assumption that the relevant
On Sunday, 27 May 2007 23:49, Kay Sievers wrote:
> On 5/27/07, Matthew Garrett <[EMAIL PROTECTED]> wrote:
> > On Sun, May 27, 2007 at 10:31:53PM +0200, Rafael J. Wysocki wrote:
> > > From: Rafael J. Wysocki <[EMAIL PROTECTED]>
> > >
> > > Use a hibernation and suspend notifier to disable the
On 5/27/07, Matthew Garrett <[EMAIL PROTECTED]> wrote:
On Sun, May 27, 2007 at 10:31:53PM +0200, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <[EMAIL PROTECTED]>
>
> Use a hibernation and suspend notifier to disable the firmware requesting
> mechanism before a hibernation/suspend and
On Sunday, 27 May 2007 22:45, Michael-Luke Jones wrote:
> On 27 May 2007, at 21:31, Rafael J. Wysocki wrote:
>
> > From: Rafael J. Wysocki <[EMAIL PROTECTED]>
> >
> > Use a hibernation and suspend notifier to disable the firmware
> > requesting
> > mechanism before a hibernation/suspend and
On Sunday, 27 May 2007 22:49, Matthew Garrett wrote:
> On Sun, May 27, 2007 at 10:31:53PM +0200, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki <[EMAIL PROTECTED]>
> >
> > Use a hibernation and suspend notifier to disable the firmware requesting
> > mechanism before a hibernation/suspend
On Sun, May 27, 2007 at 10:31:53PM +0200, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <[EMAIL PROTECTED]>
>
> Use a hibernation and suspend notifier to disable the firmware requesting
> mechanism before a hibernation/suspend and enable it after the operation.
This avoids the problem of
On 27 May 2007, at 21:31, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
Use a hibernation and suspend notifier to disable the firmware
requesting
mechanism before a hibernation/suspend and enable it after the
operation.
Signed-off-by: Rafael J. Wysocki <[EMAIL
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
Use a hibernation and suspend notifier to disable the firmware requesting
mechanism before a hibernation/suspend and enable it after the operation.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
drivers/base/firmware_class.c | 36
From: Rafael J. Wysocki [EMAIL PROTECTED]
Use a hibernation and suspend notifier to disable the firmware requesting
mechanism before a hibernation/suspend and enable it after the operation.
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
drivers/base/firmware_class.c | 36
On 27 May 2007, at 21:31, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki [EMAIL PROTECTED]
Use a hibernation and suspend notifier to disable the firmware
requesting
mechanism before a hibernation/suspend and enable it after the
operation.
Signed-off-by: Rafael J. Wysocki [EMAIL
On Sun, May 27, 2007 at 10:31:53PM +0200, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki [EMAIL PROTECTED]
Use a hibernation and suspend notifier to disable the firmware requesting
mechanism before a hibernation/suspend and enable it after the operation.
This avoids the problem of .resume
On Sunday, 27 May 2007 22:49, Matthew Garrett wrote:
On Sun, May 27, 2007 at 10:31:53PM +0200, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki [EMAIL PROTECTED]
Use a hibernation and suspend notifier to disable the firmware requesting
mechanism before a hibernation/suspend and enable it
1 - 100 of 106 matches
Mail list logo
