On Fri, 25 May 2007, Pavel Machek wrote:
> My proposed solution is "fix pcmcia to load firmware before suspend
> even starts"
s/pcmcia/all drivers that load firmware/ if you are going to go that way.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the
On Fri, 25 May 2007, Pavel Machek wrote:
> >
> > Why the HELL cannot you realize that kernel threads are different?
>
> Ugh? We are talking about request_firmware() here, right? That's
> calling userland helper to load the firmware...? Looks like USER
> thread to me.
Right. And if we had had
On Thu 2007-05-24 15:23:56, Linus Torvalds wrote:
>
>
> On Thu, 24 May 2007, Linus Torvalds wrote:
> >
> > Then, what you do is:
> > - stop user space
> > - suspend
> > - resume
> > - start user space
>
> Btw, this is where things like "udevd" can be really problematic. That
> whole
Hi!
>
> On Fri, 25 May 2007, Pavel Machek wrote:
> > >
> > > Equally arguably, we should just have a "resume_late()" call that can be
> > > used to do this after everything is up and running.
> >
> > Yes, we can do that. But userland will see devices "not there" for a
> > few seconds after
On Thu, 24 May 2007, Linus Torvalds wrote:
>
> Then, what you do is:
> - stop user space
> - suspend
> - resume
> - start user space
Btw, this is where things like "udevd" can be really problematic. That
whole "uevent over netlink" stuff is really nasty for things like this.
It's quite
On Thu 2007-05-24 15:10:29, Linus Torvalds wrote:
>
>
> On Fri, 25 May 2007, Pavel Machek wrote:
> > >
> > > Equally arguably, we should just have a "resume_late()" call that can be
> > > used to do this after everything is up and running.
> >
> > Yes, we can do that. But userland will see
On Fri, 25 May 2007, Pavel Machek wrote:
> >
> > Equally arguably, we should just have a "resume_late()" call that can be
> > used to do this after everything is up and running.
>
> Yes, we can do that. But userland will see devices "not there" for a
> few seconds after boot.
No they won't.
Hi!
> > Well. we'd like to present hardware in working state as soon as we
> > resume (if eth0 was there before resume, it should be there after
> > resume. not 3 seconds after resume); so if someone needs to load the
> > firmware, they should just store it in the kernel memory, and load it
> >
On Thursday, 24 May 2007 22:27, Linus Torvalds wrote:
>
> On Thu, 24 May 2007, Pavel Machek wrote:
> >
> > If someone does request_firmware from resume function... that's
> > bad. Resume function should be fixed. Pcmcia? ti12xx driver?
>
> Probably pcmcia "ds" driver and CONFIG_PCMCIA_LOAD_CIS.
On Thu, 24 May 2007, Pavel Machek wrote:
>
> If someone does request_firmware from resume function... that's
> bad. Resume function should be fixed. Pcmcia? ti12xx driver?
Probably pcmcia "ds" driver and CONFIG_PCMCIA_LOAD_CIS.
> Well. we'd like to present hardware in working state as soon as
Hi!
> Yeah, but the interesting one is this pair:
>
> events/0 R running 0 4 1 (L-TLB)
>
> sleep.sh D 014F 0 5798 5789 (NOTLB)
> Call Trace:
>[] kobject_uevent_env+0x3a1/0x4a0
>[] wait_for_completion+0x79/0xb0
>[]
Hi!
Yeah, but the interesting one is this pair:
events/0 R running 0 4 1 (L-TLB)
sleep.sh D 014F 0 5798 5789 (NOTLB)
Call Trace:
[c01d3c01] kobject_uevent_env+0x3a1/0x4a0
[c02d8509] wait_for_completion+0x79/0xb0
[c0116640]
On Thu, 24 May 2007, Pavel Machek wrote:
If someone does request_firmware from resume function... that's
bad. Resume function should be fixed. Pcmcia? ti12xx driver?
Probably pcmcia ds driver and CONFIG_PCMCIA_LOAD_CIS.
Well. we'd like to present hardware in working state as soon as we
On Thursday, 24 May 2007 22:27, Linus Torvalds wrote:
On Thu, 24 May 2007, Pavel Machek wrote:
If someone does request_firmware from resume function... that's
bad. Resume function should be fixed. Pcmcia? ti12xx driver?
Probably pcmcia ds driver and CONFIG_PCMCIA_LOAD_CIS.
Well.
Hi!
Well. we'd like to present hardware in working state as soon as we
resume (if eth0 was there before resume, it should be there after
resume. not 3 seconds after resume); so if someone needs to load the
firmware, they should just store it in the kernel memory, and load it
during boot
On Fri, 25 May 2007, Pavel Machek wrote:
Equally arguably, we should just have a resume_late() call that can be
used to do this after everything is up and running.
Yes, we can do that. But userland will see devices not there for a
few seconds after boot.
No they won't.
Why the HELL
On Thu 2007-05-24 15:10:29, Linus Torvalds wrote:
On Fri, 25 May 2007, Pavel Machek wrote:
Equally arguably, we should just have a resume_late() call that can be
used to do this after everything is up and running.
Yes, we can do that. But userland will see devices not there
On Thu, 24 May 2007, Linus Torvalds wrote:
Then, what you do is:
- stop user space
- suspend
- resume
- start user space
Btw, this is where things like udevd can be really problematic. That
whole uevent over netlink stuff is really nasty for things like this.
It's quite possible
Hi!
On Fri, 25 May 2007, Pavel Machek wrote:
Equally arguably, we should just have a resume_late() call that can be
used to do this after everything is up and running.
Yes, we can do that. But userland will see devices not there for a
few seconds after boot.
No they won't.
On Thu 2007-05-24 15:23:56, Linus Torvalds wrote:
On Thu, 24 May 2007, Linus Torvalds wrote:
Then, what you do is:
- stop user space
- suspend
- resume
- start user space
Btw, this is where things like udevd can be really problematic. That
whole uevent over netlink stuff
On Fri, 25 May 2007, Pavel Machek wrote:
My proposed solution is fix pcmcia to load firmware before suspend
even starts
s/pcmcia/all drivers that load firmware/ if you are going to go that way.
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the
On Thu 2007-05-24 20:16:38, Henrique de Moraes Holschuh wrote:
On Fri, 25 May 2007, Pavel Machek wrote:
My proposed solution is fix pcmcia to load firmware before suspend
even starts
s/pcmcia/all drivers that load firmware/ if you are going to go that way.
I'm not going that way. It
On Fri, 25 May 2007, Pavel Machek wrote:
Why the HELL cannot you realize that kernel threads are different?
Ugh? We are talking about request_firmware() here, right? That's
calling userland helper to load the firmware...? Looks like USER
thread to me.
Right. And if we had had the nice
Hi!
Why the HELL cannot you realize that kernel threads are different?
Ugh? We are talking about request_firmware() here, right? That's
calling userland helper to load the firmware...? Looks like USER
thread to me.
Right. And if we had had the nice old /sbin/hotplug thing, it would
On Fri, 25 May 2007, Pavel Machek wrote:
2) we need to preload firmware during _suspend_. I AM TELLING THAT TO
PEOPLE FOR FIVE YEARS NOW.
And people aren't listening. Have you thought about _why_?
The thing is, it should just work. Even without pre-loading.
Imageine we killed freezer.
Hi Linus.
On Thu, 2007-05-24 at 17:37 -0700, Linus Torvalds wrote:
On Fri, 25 May 2007, Pavel Machek wrote:
2) we need to preload firmware during _suspend_. I AM TELLING THAT TO
PEOPLE FOR FIVE YEARS NOW.
And people aren't listening. Have you thought about _why_?
The thing is, it
Hi Linus.
On Thu, 2007-05-24 at 19:10 -0700, Linus Torvalds wrote:
On Fri, 25 May 2007, Nigel Cunningham wrote:
First, let me agree with you that for the atomic copy itself, the
freezer is unnecessary. Disabling irqs and so on is enough to ensure the
atomic copy is atomic. I don't
On Fri, 25 May 2007, Nigel Cunningham wrote:
First, let me agree with you that for the atomic copy itself, the
freezer is unnecessary. Disabling irqs and so on is enough to ensure the
atomic copy is atomic. I don't think any of us are arguing with you
there.
First off, realize that the
On Fri, 25 May 2007, Nigel Cunningham wrote:
To answer the question, I guess the answer is that although they're
different creatures, they have similarities. This is one of them, which
is why I could make the mistake I did. Nothing in the issue being
discussed was unique to suspend-to-ram.
Hi.
On Thu, 2007-05-24 at 19:41 -0700, Linus Torvalds wrote:
On Fri, 25 May 2007, Nigel Cunningham wrote:
To answer the question, I guess the answer is that although they're
different creatures, they have similarities. This is one of them, which
is why I could make the mistake I did.
On Fri, 25 May 2007, Nigel Cunningham wrote:
That said, I think freezing is crap even for snapshotting/suspend-to-disk,
but the point of the above rant is to show how insane it is to think that
problems and complexity in one area should translate into problems and
complexity in
On Fri, 25 May 2007, Nigel Cunningham wrote:
Does that mean you never ever power off your laptop (assuming you have
one), and the battery never runs out? Surely you must power it off
completely sometimes?
So? The bootup isn't that much worse than a disk suspend/resume, and it's
reliable.
Howdy.
On Thu, 2007-05-24 at 20:31 -0700, Linus Torvalds wrote:
On Fri, 25 May 2007, Nigel Cunningham wrote:
That said, I think freezing is crap even for
snapshotting/suspend-to-disk,
but the point of the above rant is to show how insane it is to think that
problems and
Hi.
On Thu, 2007-05-24 at 21:49 -0700, Linus Torvalds wrote:
On Fri, 25 May 2007, Nigel Cunningham wrote:
Does that mean you never ever power off your laptop (assuming you have
one), and the battery never runs out? Surely you must power it off
completely sometimes?
So? The bootup
101 - 134 of 134 matches
Mail list logo
