RE: Runlevel for Sleep?

RE: Runlevel for Sleep?

[Grover, Andrew]

> From: P. Christeas [mailto:p_christ-U04EIuiosng@public.gmane.org] 
> It has just come up to me, should we use a runlevel for sleep?

Right now I am leaning towards no. We don't have a runlevel for APM's
suspend, why would we for ACPI sleep?

Sleep should be very quick to enter and exit. We shouldn't have to shut down
any services. If the drivers properly save and restore context, things on
resume should just pick up where they left off.

I think we'll know better once we have working device power management if a
new runlevel is needed or not.

Regards -- Andy


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: Runlevel for Sleep?

[Lyle Seaman]

> I think we'll know better once we have working device power management if a
> new runlevel is needed or not.

I'll second this.  It seems that everybody is spending time fiddling with 
workarounds instead of fixing the drivers.

Personally, I'm trying to get the e1000 driver to resume correctly. 
After resume, an ifconfig down, ifconfig up cycle works fine, so it can't be 
*that* hard.  But my naive approach (run the down and up methods) doesn't do 
the trick, nor does merely running the close and open methods.

The analysis is complicated by the fact that the e1000 driver must be compiled 
as a module, and debugging modules with kgdb is a bit sketchy, and setting a 
breakpoint within the resume function always makes it segfault ... :(





-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Runlevel for Sleep?

[P. Christeas]

Grover, Andrew wrote:
> > From: P. Christeas [mailto:p_christ-U04EIuiosng@public.gmane.org]
> > It has just come up to me, should we use a runlevel for sleep?
>
> Right now I am leaning towards no. We don't have a runlevel for APM's
> suspend, why would we for ACPI sleep?
>
> Sleep should be very quick to enter and exit. We shouldn't have to shut
> down any services. If the drivers properly save and restore context, things
> on resume should just pick up where they left off.
>
> I think we'll know better once we have working device power management if a
> new runlevel is needed or not.
>
> Regards -- Andy

I think we already have a working power device management, thanks for that!
The mail I sent only reflects my humble opinion, I just ask if it's time we 
thought of such a change.

APM suspend never worked for me and I guess that anybody that managed to use 
it has used workarounds. ACPI already is much better than that.

We may never have 100% bug-free drivers, some of them will always need 
workarounds.
In the other hand, hardware is not the only matter. The ethernet card may not 
have any trouble at all sleeping. The net behind it, however, may change much 
while our box is sleeping. What if we have clients connected and shouldn't 
sleep after all? Now, it's up to the person pressing the 'sleep' button to 
take care of such issues. I prefer everything to be automated.

IMHO it shouldn't matter how long sleep needs to enter or exit. After all, 
initscripts won't necessarily mean that the system will be loaded 
significantly. I like binaries to keep small, as we have them loaded all the 
time. So, why have all the resume code inside the kernel, while we can only 
call a few binaries to resume?

Here is what I suggest [flame bait] :

sleep button/command
||
V
'init 7' event
||
V
initscripts like 'netfs suspend' etc. The initscrips are allowed to fail 
(say, a client on httpd) => return to previous runlevel
|
v
on sucess => 'echo 1/3/4 > /proc/acpi/sleep' by the inittab

sleeping... wake event => we're leaving runlevel 7 => restore suspended 
services with 'netfs resume' and use workarounds for buggy drivers like 
'bugcard restore' etc.
||
V
our system is ready.





-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: Runlevel for Sleep?

[Charl P. Botha]

On Wed, Sep 04, 2002 at 01:50:57PM +0300, P. Christeas wrote:
> Here is what I suggest [flame bait] :
> 
> sleep button/command
> ||
> V
> 'init 7' event
> ||
> V
> initscripts like 'netfs suspend' etc. The initscrips are allowed to fail 
> (say, a client on httpd) => return to previous runlevel
> |
> v
> on sucess => 'echo 1/3/4 > /proc/acpi/sleep' by the inittab
> 
> sleeping... wake event => we're leaving runlevel 7 => restore suspended 
> services with 'netfs resume' and use workarounds for buggy drivers like 
> 'bugcard restore' etc.
> ||
> V
> our system is ready.

What's wrong with using user-defined acpid hooks for ACPI events?  This
works now... there's nothing stopping you from making your own runlevels and
invoking them from the acpid hooks yourself.

My 2c,
Charl

-- 
charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: Runlevel for Sleep?

[Robert Wo"rle]

P. Christeas schrieb:

>Grover, Andrew wrote:
>  
>
>>>From: P. Christeas [mailto:p_christ-U04EIuiosng@public.gmane.org]
>>>It has just come up to me, should we use a runlevel for sleep?
>>>      
>>>
>>Right now I am leaning towards no. We don't have a runlevel for APM's
>>suspend, why would we for ACPI sleep?
>>
>>Sleep should be very quick to enter and exit. We shouldn't have to shut
>>down any services. If the drivers properly save and restore context, things
>>on resume should just pick up where they left off.
>>
>>I think we'll know better once we have working device power management if a
>>new runlevel is needed or not.
>>
>>Regards -- Andy
>>    
>>
>
>I think we already have a working power device management, thanks for that!
>The mail I sent only reflects my humble opinion, I just ask if it's time we 
>thought of such a change.
>
>APM suspend never worked for me and I guess that anybody that managed to use 
>it has used workarounds. ACPI already is much better than that.
>  
>
Well i had a working APM , but i also had to use the magic apmd_proxy 
script where i placed the scripts to start and stop the critical things 
( for me it was _USB and pcmcia )
So why dont we think about something similar so a script where ACPI 
looks for at States and do the things which supposed to be done ...

>We may never have 100% bug-free drivers, some of them will always need 
>workarounds.
>In the other hand, hardware is not the only matter. The ethernet card may not 
>have any trouble at all sleeping. The net behind it, however, may change much 
>while our box is sleeping. What if we have clients connected and shouldn't 
>sleep after all? Now, it's up to the person pressing the 'sleep' button to 
>take care of such issues. I prefer everything to be automated.
>
>IMHO it shouldn't matter how long sleep needs to enter or exit. After all, 
>initscripts won't necessarily mean that the system will be loaded 
>significantly. I like binaries to keep small, as we have them loaded all the 
>time. So, why have all the resume code inside the kernel, while we can only 
>call a few binaries to resume?
>
>Here is what I suggest [flame bait] :
>
>sleep button/command
>||
>V
>'init 7' event
>||
>V
>initscripts like 'netfs suspend' etc. The initscrips are allowed to fail 
>(say, a client on httpd) => return to previous runlevel
>|
>v
>on sucess => 'echo 1/3/4 > /proc/acpi/sleep' by the inittab
>
>sleeping... wake event => we're leaving runlevel 7 => restore suspended 
>services with 'netfs resume' and use workarounds for buggy drivers like 
>'bugcard restore' etc.
>||
>V
>our system is ready.
>
>
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by: OSDN - Tired of that same old
>cell phone?  Get a new here for FREE!
>https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
>_______________________________________________
>Acpi-devel mailing list
>Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>https://lists.sourceforge.net/lists/listinfo/acpi-devel
>
>
>  
>

-- 
_____________________________________
*Robert Wo"rle
Linux | Embedded Device*
*
Symplon AG*

*...touch the internet*

phone: +49 89 552 999 35
fax: +49 89 552 999 10
email: robert.woerle-y2s3ugBAdl9BDgjK7y7TUQ@public.gmane.org <mailto:robert.woerle@symplon.com>
web: www.symplon.com <http://www.symplon.com/>

_____________________________________




-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: Runlevel for Sleep?

[Pavel Machek]

Hi!

> Right now I am leaning towards no. We don't have a runlevel for APM's
> suspend, why would we for ACPI sleep?

I believe we should have it for APM, too.

umounting nfs seems like good idea, and no ammount of drivers will fix that.

> I think we'll know better once we have working device power management if a
> new runlevel is needed or not.

I believe 3 of them are needed - S1, S3 and S4. 
								Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.



-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: Runlevel for Sleep?

[Patrick Mochel]

On Fri, 6 Sep 2002, Pavel Machek wrote:

> Hi!
> 
> > Right now I am leaning towards no. We don't have a runlevel for APM's
> > suspend, why would we for ACPI sleep?
> 
> I believe we should have it for APM, too.
> 
> umounting nfs seems like good idea, and no ammount of drivers will fix that.
>
> > I think we'll know better once we have working device power management if a
> > new runlevel is needed or not.
> 
> I believe 3 of them are needed - S1, S3 and S4. 

I agree that we need to do some amount of user-level work before we go to 
sleep, but I'm not sure that a runlevel is the proper way to implement it. 

Unless you implemented a new runlevel for every possible sleep state for 
every possible platform suspend mechanism, how would pass what suspend 
state you wanted to enter? 

You don't really want to have a different one for S1, S3, and S4 because 
they are ACPI specific, both in terms of their names and what they mean. 
I don't think you could create a clean, sensible solution like that, that 
worked for all platforms...

You could have one runlevel, and pass the state we're entering somehow. 
But, we would need to get that from init(8) to reboot(2) [1]. That way we 
could use standard rc scripts for doing all the dirty little things we 
need to before we sleep. 

	-pat

[1] Once upon a time (last May), I implemented a patch that overloaded the
reboot(2) system call to initiate suspend transitions in a
platform-specific manner (as per Linus's suggestion). This is in the
resurrection queue and will probably resurface soon. 

This allows every platform to use the same mechanism for suspending. Of 
course some suspend states are platform-specific, but a few are generic 
(suspend to ram, suspend to disk). The userspace caller would pass the 
platform-specific state. sys_reboot() simply passes that on to the 
platform-supplied callback..





-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: Runlevel for Sleep?

[Pavel Machek]

Hi!

> > I believe 3 of them are needed - S1, S3 and S4. 
> 
> I agree that we need to do some amount of user-level work before we go to 
> sleep, but I'm not sure that a runlevel is the proper way to implement it. 
> 
> Unless you implemented a new runlevel for every possible sleep state for 
> every possible platform suspend mechanism, how would pass what suspend 
> state you wanted to enter? 
> 
> You don't really want to have a different one for S1, S3, and S4 because 
> they are ACPI specific, both in terms of their names and what they mean. 
> I don't think you could create a clean, sensible solution like that, that 
> worked for all platforms...

Okay, we can probably forget S1 and create arch-neutral
"suspend-to-disk" and "suspend-to-ram".

I'm not 100% sure runlevels are the right way, but they certainly look
better than special-purpose script.

...and we already have one for halt, which is just S5....

> You could have one runlevel, and pass the state we're entering somehow. 
> But, we would need to get that from init(8) to reboot(2) [1]. That way we 
> could use standard rc scripts for doing all the dirty little things we 
> need to before we sleep. 
								Pavel
-- 
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: Runlevel for Sleep?

[P. Christeas]

> Hi!
>
> > > I believe 3 of them are needed - S1, S3 and S4.
> >
It might be, but that way we are reserving all unimplemented runlevels, which 
looks really bad. I wish we could safely (for all systems) pass sth like an 
argument to the runlevel, indicating which sleep state we 're getting into.

> > I agree that we need to do some amount of user-level work before we go to
> > sleep, but I'm not sure that a runlevel is the proper way to implement
> > it.
My "original" idea is to use the init mechanism instead of any custom scripts 
and code, mainly just to avoid having extra binaries in our kernel.

> >
> > Unless you implemented a new runlevel for every possible sleep state for
> > every possible platform suspend mechanism, how would pass what suspend
> > state you wanted to enter?

If you do that, you're certainly ACPI-specific.

> >
> > You don't really want to have a different one for S1, S3, and S4 because
> > they are ACPI specific, both in terms of their names and what they mean.
> > I don't think you could create a clean, sensible solution like that, that
> > worked for all platforms...
>
> Okay, we can probably forget S1 and create arch-neutral
> "suspend-to-disk" and "suspend-to-ram".
>

IMHO you couldn't skip S1. I'm using that (in fact S3 works for me much 
worse) and I surely have to run some scripts before entering that.

We could easily agree with APM developers to have a common implementation, 
which gives the runlevel implementation an advantage. The runlevel business 
should not be ACPI specific for sure.

P. Christeas


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: Runlevel for Sleep?

[Stephen L Johnson]

On Fri, 2002-09-06 at 16:40, Patrick Mochel wrote:
> 
> On Fri, 6 Sep 2002, Pavel Machek wrote:
> 
> > Hi!
> > 
> > > Right now I am leaning towards no. We don't have a runlevel for APM's
> > > suspend, why would we for ACPI sleep?
> > 
> > I believe we should have it for APM, too.
> > 
> > umounting nfs seems like good idea, and no ammount of drivers will fix that.
> >
> > > I think we'll know better once we have working device power management if a
> > > new runlevel is needed or not.
> > 
> > I believe 3 of them are needed - S1, S3 and S4. 
> 
> I agree that we need to do some amount of user-level work before we go to 
> sleep, but I'm not sure that a runlevel is the proper way to implement it. 
> 
> Unless you implemented a new runlevel for every possible sleep state for 
> every possible platform suspend mechanism, how would pass what suspend 
> state you wanted to enter? 
> 
> You don't really want to have a different one for S1, S3, and S4 because 
> they are ACPI specific, both in terms of their names and what they mean. 
> I don't think you could create a clean, sensible solution like that, that 
> worked for all platforms...
> 
> You could have one runlevel, and pass the state we're entering somehow. 
> But, we would need to get that from init(8) to reboot(2) [1]. That way we 
> could use standard rc scripts for doing all the dirty little things we 
> need to before we sleep. 
> 

Hi all. I'm new to the list.

I've been involved with the Linux on PDAs/handheld computers over at
http://www.handhelds.org/. They have to deal with the exact same issues
suspend/resumes issues with drivers and user-space issues. Although they
major concern is just with suspending in memory.

Over the past several versions of Familiar (a linux distrubution for
handhelds) a method for dealing with user space suspend and resume
issues have been developer. It is working quite well. 

The kernel calls a user space program called pmhelper with a "suspend"
or "resume" parameter. On a suspend, pmhelper is called before the
kernel  suspends the drivers. And on a resume it's called after the
kernel resumes the drivers. 

The pmhelper program on familiar calls a series of scripts in
/etc/suspend-scripts/ or /etc/resume-scripts/ (depending on the pending
state). The scripts are run in a SysV boot-script way. The scripts are
named nnScriptName where nn are numbers. 

I'm sure that this pmhelper/scripts method could easily be adapted for
ACPI/APM usage. Just my .02 cent.

--
Stephe L Johnson <sjohnson-WpdXj7kV/NVg9hUCZPvPmw@public.gmane.org>




-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: Runlevel for Sleep?

[Lyle Seaman]

> umounting nfs seems like good idea, and no ammount of drivers will fix that.

Can't unmount it if there are open files.  I don't agree that unmounting NFS is necessarily a good idea -- I want everything to resume exactly the way it was suspended to the greatest extent possible.  If the server has gone away and returned, well, that can't be helped. But otherwise, I would expect all my network resources to be in the same state as I left them, just as with my local resources.





-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: Runlevel for Sleep?

[Patrick Mochel]

On 7 Sep 2002, Stephen L Johnson wrote:

> I've been involved with the Linux on PDAs/handheld computers over at
> http://www.handhelds.org/. They have to deal with the exact same issues
> suspend/resumes issues with drivers and user-space issues. Although they
> major concern is just with suspending in memory.
> 
> Over the past several versions of Familiar (a linux distrubution for
> handhelds) a method for dealing with user space suspend and resume
> issues have been developer. It is working quite well. 
> 
> The kernel calls a user space program called pmhelper with a "suspend"
> or "resume" parameter. On a suspend, pmhelper is called before the
> kernel  suspends the drivers. And on a resume it's called after the
> kernel resumes the drivers. 

That's not bad, but I see two problems:

- The suspend transition is usually initiated from user input, i.e. 
userspace. So, userspace would be calling into the kernel, which would be 
calling back to userspace, and returning back to the kernel to finish it 
up. 

It seems much easier to do the work you need in userspace, then transfer 
control over to the kernel once and for all.

- The standard mechanism for calling into userspace is /sbin/hotplug. 
There is NWIH you'll be able to sneak another mechanism into the kernel. 
So, being stuck with /sbin/hotplug, you run into the problem that it 
executes asynchronously. You want to wait for the userspace stuff to 
finish before you continue suspending, so you'd have to add yet more code 
to wait for notification from userspace...

> The pmhelper program on familiar calls a series of scripts in
> /etc/suspend-scripts/ or /etc/resume-scripts/ (depending on the pending
> state). The scripts are run in a SysV boot-script way. The scripts are
> named nnScriptName where nn are numbers. 

For Midori Linux (a distro for the all-but-dead x86 internet appliance
market), we rewrote the init script hoo-haw to be similar to this thing
called simpleinit. (A dependency graph was constructed so we could execute
the init scripts in parallel). Suspend was initiated via a GUI or script, 
which triggered init to run, passing 'suspend' to all the init scripts 
(and 'resume' on Resume).

In essence, we're going to be doing something similar. It's just a matter 
of how we articulate it. Also, remember that we must do the converse 
action on resume (call all the init scripts again). But, is that really a 
runlevel transition? We'd be transferring back from 7 (or whatever) to 3 
or 5. But, we don't want to restart everything; only the stuff that we 
suspended.

Are there any ideas from some of the older-school people? How exactly does 
APM do it? 


	-pat



-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: Runlevel for Sleep?

[P. Christeas]

Patrick Mochel wrote:
> In essence, we're going to be doing something similar. It's just a matter
> of how we articulate it. Also, remember that we must do the converse
> action on resume (call all the init scripts again). But, is that really a
> runlevel transition? We'd be transferring back from 7 (or whatever) to 3
> or 5. But, we don't want to restart everything; only the stuff that we
> suspended.

Right, on resume we sould only call the scripts that "leave rl. 7", not the 
ones that enter 3 or 5. This is tricky (in concept). Moreover, I had 
recommended that the initscripts introduce the words "suspend" and "resume" 
instead of "stop" and "start". This way, we could partially suspend a service.
For example, a network daemon should drop all active connections when 
suspended, but not die itself (as in 'stop'). It could keep listening to a 
port.
One more thing  (as Lyle Seaman has pointed out) is that sometimes we don't 
want to suspend, even though the user has pressed the 'suspend button'. This 
means that the initscripts should be allowed to fail, in a manner such that 
the sleep state will not be eventually entered.


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: Runlevel for Sleep?

[Diego Zuccato]

"P. Christeas" wrote:
> Right, on resume we sould only call the scripts that "leave rl. 7", not the
> ones that enter 3 or 5. This is tricky (in concept). Moreover, I had
> recommended that the initscripts introduce the words "suspend" and "resume"
> instead of "stop" and "start". This way, we could partially suspend a service.
> For example, a network daemon should drop all active connections when
> suspended, but not die itself (as in 'stop'). It could keep listening to a
> port.
Why ???
If you need that daemon to terminate answering pending connections, then
use stop. If you don't (e.g. there is no timeout on the other side),
then simply leave it alone. Really, you don't want it to accept more
connections. What happens if you are suspending a db server (well,
suspending a server is IMHO a really stupid thing, but...) and after
giving it "suspend" a new connection request arrives ? It can only be
discarded (then stop the service...) or accepted (so why in the hell is
"suspend" needed???).

Just my .02 ...

BYtE,
 Diego.


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: Runlevel for Sleep?

[P. Christeas]

Diego Zuccato wrote:
> "P. Christeas" wrote:
> > Right, on resume we sould only call the scripts that "leave rl. 7", not
> > the ones that enter 3 or 5. This is tricky (in concept). Moreover, I had
> > recommended that the initscripts introduce the words "suspend" and
> > "resume" instead of "stop" and "start". This way, we could partially
> > suspend a service. For example, a network daemon should drop all active
> > connections when suspended, but not die itself (as in 'stop'). It could
> > keep listening to a port.
>
> Why ???
> If you need that daemon to terminate answering pending connections, then
> use stop. If you don't (e.g. there is no timeout on the other side),
> then simply leave it alone. Really, you don't want it to accept more
> connections. What happens if you are suspending a db server (well,
> suspending a server is IMHO a really stupid thing, but...) and after
> giving it "suspend" a new connection request arrives ? It can only be
> discarded (then stop the service...) or accepted (so why in the hell is
> "suspend" needed???).
>
> Just my .02 ...
>
> BYtE,
>  Diego.

The whole point of the initscripts is that this is your call. The kernel 
provides the functionality and you (as the root of the system) are free to 
write any script you feel like doing.
I have suggested the 'suspend/resume' extensions because they might solve a 
few problems for *some* services. For example, you may want to stop serving 
connections, but restarting the service (the old way) may require such time, 
that the sleep/wake operation would take long (and you may not want that).
One more point is that some services may want to be notified that the system 
is going to sleep, even if they do practically nothing about it.
We are not going to handle all cases at the first day of this implementation. 
I just try to imagine situations thay may need design consideration.

P.Christeas 


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: Runlevel for Sleep?

[Diego Zuccato]

"P. Christeas" wrote:

> The whole point of the initscripts is that this is your call. The kernel
[...]
> I just try to imagine situations thay may need design consideration.
Uhm... Then just call your scripts from acpid. Or manage yourself ACPI
events. It's all in userspace. If a service needs special handling,
simply do it before (suspend) or after (resume) echoing to
/proc/acpi/sleep. IMO there's no need to provide extra hooks.
The timer setting, IIRC, is one of the "services" that need that kind of
special handlin (at resume, you have to set current time from hw clock).
Think echoing to /proc/scpi/sleep as a REALLY slow ATOMIC operation :-)

BYtE,
 Diego.


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: Runlevel for Sleep?

[Pavel Machek]

Hi!

> One more thing  (as Lyle Seaman has pointed out) is that sometimes we don't 
> want to suspend, even though the user has pressed the 'suspend
> button'. This 

Imagine notebook running out of batteries. You don't want to
completely drain batteries then crash because userspace is 100MB in
swap and can not react in time.
								Pavel 
-- 
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Runlevel for Sleep?

[Pavel Machek]

Hi!

> connections. What happens if you are suspending a db server (well,
> suspending a server is IMHO a really stupid thing, but...) and after

Why?

You bought new UPS for your server. How do you install it without
bringing machine down? Suspend to disk, rearrange power cables,
resume.

You have your server on UPS. Power died, and UPS is indicating 30
seconds to failure. What do you do? Suspend to disk.

Ethernet card in your server died. You want to replace it. Your
server is not hotplug capable. What do you do? Suspend to disk,
replace ethernet card, resume. If you are fast your users will not
even see broken connections.

[I've created FAQ section in Documentation/swsusp.txt; I'll put this
question/answer in there in next merge.]
								Pavel

-- 
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Runlevel for Sleep?

[Andreas Lohrum]

Pavel Machek <pavel=AlSwsSmVLrQ@public.gmane.org> writes:

> Hi!
> 
> > connections. What happens if you are suspending a db server (well,
> > suspending a server is IMHO a really stupid thing, but...) and after
> 
> Why?
> 
> You bought new UPS for your server. How do you install it without
> bringing machine down? Suspend to disk, rearrange power cables,
> resume.

Why taking the maschine offline at all?
If you can read german, have a look to 

  http://www.feyrer.de/Texts/Troja/usv.html

-- 
TNG Technology Consulting GmbH   Andreas Lohrum, Partner
Mobil:   +49 179 537 2076        Andreas.Lohrum-r9+Sx7D/HENBDgjK7y7TUQ@public.gmane.org
Telefon: +49 89 2158 9960        http://www.tngtech.com
Fax:     +49 89 2158 9969           




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Runlevel for Sleep?

[P. Christeas]

Pavel Machek wrote:
> Hi!
>
> > connections. What happens if you are suspending a db server (well,
> > suspending a server is IMHO a really stupid thing, but...) and after
>
> Why?
>
Those are useful questions to ask. Scripts are flexible enough to handle 
special cases, we however have to ensure there are no stiff restrictions to 
those.

> You bought new UPS for your server. How do you install it without
> bringing machine down? Suspend to disk, rearrange power cables,
> resume.
>
> You have your server on UPS. Power died, and UPS is indicating 30
> seconds to failure. What do you do? Suspend to disk.
>
AFAIK there is already a 'low battery' line in 'inittab'. Following from that 
point, we should use that line (for ACPI) instead of directly (from a binary) 
trying to enter S4 or whatever. This way the root will chose how to handle 
such a situation. In some machines S4 may be broken (not ACPI's fault always, 
consider a mis-configured partition), there 'init 0' is the only safe way to 
go down (see S5). Only the root of the machine may know that.
This will certainly be a consideration point if we decide to implement (as a 
de-facto standard) the runlevel.

> Ethernet card in your server died. You want to replace it. Your
> server is not hotplug capable. What do you do? Suspend to disk,
> replace ethernet card, resume. If you are fast your users will not
> even see broken connections.
>
Q. Will that really work?  Won't the change of Ethernet MAC ruin that?
Anyway, everybody should be free to try that.

> [I've created FAQ section in Documentation/swsusp.txt; I'll put this
> question/answer in there in next merge.]
> 								Pavel



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Runlevel for Sleep?

[Pavel Machek]

Hi!

> > You bought new UPS for your server. How do you install it without
> > bringing machine down? Suspend to disk, rearrange power cables,
> > resume.
> >
> > You have your server on UPS. Power died, and UPS is indicating 30
> > seconds to failure. What do you do? Suspend to disk.
> >
> AFAIK there is already a 'low battery' line in 'inittab'. Following from that 
> point, we should use that line (for ACPI) instead of directly (from a binary) 
> trying to enter S4 or whatever. This way the root will chose how to handle 
> such a situation. In some machines S4 may be broken (not ACPI's fault always, 
> consider a mis-configured partition), there 'init 0' is the only safe way to 
> go down (see S5). Only the root of the machine may know that.
> This will certainly be a consideration point if we decide to implement (as a 
> de-facto standard) the runlevel.

Agreed, having it de-facto standard is very important. And inittab
looks like best solution.

> > Ethernet card in your server died. You want to replace it. Your
> > server is not hotplug capable. What do you do? Suspend to disk,
> > replace ethernet card, resume. If you are fast your users will not
> > even see broken connections.
> >
> Q. Will that really work?  Won't the change of Ethernet MAC ruin that?
> Anyway, everybody should be free to try that.

I was thinking ethernet card of some rarely used interface. Anyway MAC
is settable by software and even if you forget that ARPs should save
you.
								Pavel
-- 
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

2.5.34?

[Gustavo Sverzut Barbieri]

Hello,

Is 2.5.34 patch comming out soon?


Gustavo

_______________________________________________________________________
Yahoo! PageBuilder
O super editor para criação de sites: é grátis, fácil e rápido.
http://br.geocities.yahoo.com/v/pb.html


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: 2.5.34?

[Matthew Wilcox]

On Sun, Sep 15, 2002 at 09:14:25PM -0300, Gustavo Sverzut Barbieri wrote:
> Hello,
> 
> Is 2.5.34 patch comming out soon?

i don't particularly see the point in releasing one since all ACPI patches
for 2.5 that i'm aware of are integrated into the current bitkeeper tree.
you could grab a nightly snapshot if you can't wait for 2.5.35:
http://www.kernel.org/pub/linux/kernel/people/jgarzik/snap/2.5/patch-2.5.34-bk6.bz2

-- 
Revolutions do not require corporate support.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: 2.5.34?

[Toon van der Pas]

On Mon, Sep 16, 2002 at 01:25:06AM +0100, Matthew Wilcox wrote:
> On Sun, Sep 15, 2002 at 09:14:25PM -0300, Gustavo Sverzut Barbieri wrote:
> > Hello,
> > 
> > Is 2.5.34 patch comming out soon?
> 
> i don't particularly see the point in releasing one since all ACPI patches
> for 2.5 that i'm aware of are integrated into the current bitkeeper tree.
> you could grab a nightly snapshot if you can't wait for 2.5.35:
> http://www.kernel.org/pub/linux/kernel/people/jgarzik/snap/2.5/patch-2.5.34-bk6.bz2

But be aware that the swsusp patch in the IDE driver in de 2.5 kernel
was lost when Martin Dalecki's IDE project was removed!
I would wait for it to return in some form or another, if I where you.

Regards,
Toon.
-- 
 /"\                             |
 \ /     ASCII RIBBON CAMPAIGN   |  "Who is this General Failure, and
  X        AGAINST HTML MAIL     |   what is he doing on my harddisk?"
 / \


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: 2.5.34?

[Brad Parker]

Matthew Wilcox wrote:
...
>you could grab a nightly snapshot if you can't wait for 2.5.35:
>http://www.kernel.org/pub/linux/kernel/people/jgarzik/snap/2.5/patch-2.5.34-bk
>6.bz2

Hi,

This link doesn't work; there's no .../jgarzik/snap directory.

Can anyone provide a coherent description of the S3 support in 2.5.34?
Is it close?  does it need patches (like the one above?)

I'm willing to put some work into it but I'd benefit from whom ever is
closest to it giving a quick status.

It seems like if S4 can be made to work, S3 should be straightforward
(heh).  If tried it in a stock 2.5.34 and found no difference from the
2.2.x acpi patched kernels I use...

-brad





-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: 2.5.34?

[Matthew Wilcox]

On Mon, Sep 16, 2002 at 07:30:50AM -0400, Brad Parker wrote:
> 
> Matthew Wilcox wrote:
> ...
> >you could grab a nightly snapshot if you can't wait for 2.5.35:
> >http://www.kernel.org/pub/linux/kernel/people/jgarzik/snap/2.5/patch-2.5.34-bk
> >6.bz2
> 
> Hi,
> 
> This link doesn't work; there's no .../jgarzik/snap directory.

looks like jeff moved it:
http://www.kernel.org/pub/linux/kernel/v2.5/snapshots/

but 2.5.35 is out, so there's no need any more ;-)

-- 
Revolutions do not require corporate support.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: 2.5.34?

[Brad Parker]

Matthew Wilcox wrote:
>
>but 2.5.35 is out, so there's no need any more ;-)

ok, I'll try 2.5.35;  Is there a changelog for acpi? (other than the
kernel changelog)

S1 is working for me with 2.4.19, but even if I throttle back the cpu it
eats a lot of power (and generates a lot of heat!)

I've been fooling around with S3.  It looks like the big recent
additions (in 2.5) are to try and set the video mode in the wakeup
callback.  I keep sending email to the list but I have not heard from
anyone talk about the status of this code.

I want to ask "does the s3 wakeup code work for anyone?"; I suspect it
does since I've read reports that S4 is working for some and it uses
the same code path (for wakeup anyway).

Any suggestions how to debug this?  I would hack in some code to spit
messages out the uart but my hp laptop doesn't have one :-) I may try
a pcmcia 16550 card and a kgdb hack...

S3 puts it to sleep fine but when I wake up it seem to be hung - no lcd,
no keyboard...  It's pretty hard to say how far it gets.

-brad


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: 2.5.34?

[Pavel Machek]

Hi

> > > Is 2.5.34 patch comming out soon?
> > 
> > i don't particularly see the point in releasing one since all ACPI patches
> > for 2.5 that i'm aware of are integrated into the current bitkeeper tree.
> > you could grab a nightly snapshot if you can't wait for 2.5.35:
> > http://www.kernel.org/pub/linux/kernel/people/jgarzik/snap/2.5/patch-2.5.34-bk6.bz2
> 
> But be aware that the swsusp patch in the IDE driver in de 2.5 kernel
> was lost when Martin Dalecki's IDE project was removed!
> I would wait for it to return in some form or another, if I where you.

Look at l-k, I already submitted IDE swsusp support to Andre.

-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.



-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab

Re: 2.5.34?

[Pavel Machek]

Hi!

> Can anyone provide a coherent description of the S3 support in 2.5.34?
> Is it close?  does it need patches (like the one above?)

It worked before. IDE support is recommended, through.

> I'm willing to put some work into it but I'd benefit from whom ever is
> closest to it giving a quick status.
> 
> It seems like if S4 can be made to work, S3 should be straightforward
> (heh).  If tried it in a stock 2.5.34 and found no difference from the
> 2.2.x acpi patched kernels I use...

S3 is not as simple as you think, but as it worked before... It should
be easy.
								Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.



-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab

Re: 2.5.34?

[Pavel Machek]

Hi!

> >but 2.5.35 is out, so there's no need any more ;-)
> 
> ok, I'll try 2.5.35;  Is there a changelog for acpi? (other than the
> kernel changelog)
> 
> S1 is working for me with 2.4.19, but even if I throttle back the cpu it
> eats a lot of power (and generates a lot of heat!)
> 
> I've been fooling around with S3.  It looks like the big recent
> additions (in 2.5) are to try and set the video mode in the wakeup
> callback.  I keep sending email to the list but I have not heard from
> anyone talk about the status of this code.

In such case... you are not listening.

> I want to ask "does the s3 wakeup code work for anyone?"; I suspect it
> does since I've read reports that S4 is working for some and it uses
> the same code path (for wakeup anyway).

No. S3 wakeup is completely different from S4 wakeup.

And bothworked for me in 2.5.32 IIRC.

> Any suggestions how to debug this?  I would hack in some code to spit
> messages out the uart but my hp laptop doesn't have one :-) I may try
> a pcmcia 16550 card and a kgdb hack...
> 
> S3 puts it to sleep fine but when I wake up it seem to be hung - no lcd,
> no keyboard...  It's pretty hard to say how far it gets.

Look at acpi_wakeup.S. If your mode is in  text VGA you can just write
to videoram. Maybe code to do that is still there?
								Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.



-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab

Re: 2.5.34?

[Pavel Machek]

Hi!

> > Look at l-k, I already submitted IDE swsusp support to Andre.
> 
> I know.
> I got my information from your postings on the linux-kernel mailing list. 
> My only intention was to warn people that their data is NOT safe when
> using swsusp with recent 2.5 kernels.
> 
> I should have added that you already submitted a patch on the
> linux-kernel mailing list. Sorry about that.
> 
> BTW: From your discussion with André Hedrick I understood that there
> still is some disagreement about the layer where the I/O to the IDE
> block devices should be blocked by swsusp. Is this resolved now?

No but we are working on it.
								Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: 2.5.34?

[Brad Parker]

Pavel Machek wrote:
>
>No. S3 wakeup is completely different from S4 wakeup.

Really?  I thought they both used the same "wakeup vector" and hence
used the pre-_WAK code path.  Perhaps I am mistaken.

>And bothworked for me in 2.5.32 IIRC.

ok, thanks.  That's actually the first time anyone has said that clearly.

(your previous email was somewhat vague about S3 working - it didn't
actually state that it was working and when)

>Look at acpi_wakeup.S. If your mode is in  text VGA you can just write
>to videoram. Maybe code to do that is still there?

The problem is that the backlight is not on, and it's not clear the
vga controller is turned on.  This code runs before _WAK (which I think
is what turns on the backlight)

I'll try it, however, as it's a reasonable suggestion.  thanks!

-brad


-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab

Re: 2.5.34?

[Pavel Machek]

Hi!

> >No. S3 wakeup is completely different from S4 wakeup.
> 
> Really?  I thought they both used the same "wakeup vector" and hence
> used the pre-_WAK code path.  Perhaps I am mistaken.

Well, we do S3 using ACPI but do S4 "by hand", so wakeup vector is not
even used in S4 (==swsusp) case.

S3 is similar to S4bios; there are patches for S4bios floating around,
but its not in mainline.

> >And bothworked for me in 2.5.32 IIRC.
> 
> ok, thanks.  That's actually the first time anyone has said that clearly.
> 
> (your previous email was somewhat vague about S3 working - it didn't
> actually state that it was working and when)

[I'm not 100% sure about it was 2.5.32. I think it was.]

> >Look at acpi_wakeup.S. If your mode is in  text VGA you can just write
> >to videoram. Maybe code to do that is still there?
> 
> The problem is that the backlight is not on, and it's not clear the
> vga controller is turned on.  This code runs before _WAK (which I think
> is what turns on the backlight)
> 
> I'll try it, however, as it's a reasonable suggestion.  thanks!

On my machines I'm lucky enough to have video either in VGA text or in
original mode. In VGA text it is rather easy to show some debugging.

								Pavel
-- 
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.


-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab

Re: 2.5.34?

[Toon van der Pas]

On Tue, Sep 17, 2002 at 03:46:53PM +0000, Pavel Machek wrote:
> 
> > > > Is 2.5.34 patch comming out soon?
> > > 
> > > i don't particularly see the point in releasing one since all ACPI patches
> > > for 2.5 that i'm aware of are integrated into the current bitkeeper tree.
> > > you could grab a nightly snapshot if you can't wait for 2.5.35:
> > > http://www.kernel.org/pub/linux/kernel/people/jgarzik/snap/2.5/patch-2.5.34-bk6.bz2
> > 
> > But be aware that the swsusp patch in the IDE driver in de 2.5 kernel
> > was lost when Martin Dalecki's IDE project was removed!
> > I would wait for it to return in some form or another, if I where you.
> 
> Look at l-k, I already submitted IDE swsusp support to Andre.

I know.
I got my information from your postings on the linux-kernel mailing list. 
My only intention was to warn people that their data is NOT safe when
using swsusp with recent 2.5 kernels.

I should have added that you already submitted a patch on the
linux-kernel mailing list. Sorry about that.

BTW: From your discussion with André Hedrick I understood that there
still is some disagreement about the layer where the I/O to the IDE
block devices should be blocked by swsusp. Is this resolved now?

Regards,
Toon.
-- 
 /"\                             |
 \ /     ASCII RIBBON CAMPAIGN   |  "Who is this General Failure, and
  X        AGAINST HTML MAIL     |   what is he doing on my harddisk?"
 / \


-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab

[PATCH] Toshiba ACPI Extras 0.16

[John Belmonte]

[-- Attachment #1: Type: text/plain, Size: 1093 bytes --]

Hello Andy,

Recently there was a mass patch to the 2.5 kernel that tried to replace 
instances of strncpy with strlcpy.  In the case of my driver the 
substitution was not appropriate and causes end-user problems due to the 
resulting undefined memory access.  This change was made about 6 weeks 
ago without my knowledge, the result being that there are tainted copies 
of version 0.15 of the driver out there.

What I'd like to do is forget version 0.15 ever existed, so this patch 
reverts the change and increments the version.  I'd also like to 
increment the version in the 2.4 tree to keep things in sync, so I've 
got a patch ready for each tree.

Unfortunately I've complicated matters by already trying to submit a 
patch to Linus that reverts the change but doesn't increment the 
version.  I doubt he'll apply it, but if he does before you get to it 
then apply the 2.4 patch to the 2.5 tree to increment the version only.

Sorry for the trouble.

Regards,
-John


Changes:

     * Increment version because release 0.15 was tainted by a bad
       "strlcpy conversion" patch.




[-- Attachment #2: toshiba_acpi_0.16-linux_2.6.0-test1.patch --]
[-- Type: text/plain, Size: 598 bytes --]

--- toshiba_acpi.c.old	2003-07-25 18:40:52.000000000 -0400
+++ toshiba_acpi.c	2003-07-25 18:24:48.000000000 -0400
@@ -33,7 +33,7 @@
  *
  */
 
-#define TOSHIBA_ACPI_VERSION	"0.15"
+#define TOSHIBA_ACPI_VERSION	"0.16"
 #define PROC_INTERFACE_VERSION	1
 
 #include <linux/kernel.h>
@@ -108,7 +108,9 @@
 	int result;
 	char* str2 = kmalloc(n + 1, GFP_KERNEL);
 	if (str2 == 0) return 0;
-	strlcpy(str2, str, n);
+	/* NOTE: don't even _think_ about replacing this with strlcpy */
+	strncpy(str2, str, n);
+	str2[n] = 0;
 	va_start(args, format);
 	result = vsscanf(str2, format, args);
 	va_end(args);

[-- Attachment #3: toshiba_acpi_0.16-linux_2.4.22-pre8.patch --]
[-- Type: text/plain, Size: 517 bytes --]

--- toshiba_acpi.c.old	2003-07-25 19:03:10.000000000 -0400
+++ toshiba_acpi.c	2003-07-25 18:24:48.000000000 -0400
@@ -33,7 +33,7 @@
  *
  */
 
-#define TOSHIBA_ACPI_VERSION	"0.15"
+#define TOSHIBA_ACPI_VERSION	"0.16"
 #define PROC_INTERFACE_VERSION	1
 
 #include <linux/kernel.h>
@@ -108,6 +108,7 @@
 	int result;
 	char* str2 = kmalloc(n + 1, GFP_KERNEL);
 	if (str2 == 0) return 0;
+	/* NOTE: don't even _think_ about replacing this with strlcpy */
 	strncpy(str2, str, n);
 	str2[n] = 0;
 	va_start(args, format);

Re: [PATCH] Toshiba ACPI Extras 0.16

[Matthew Wilcox]

On Fri, Jul 25, 2003 at 07:28:17PM -0400, John Belmonte wrote:
> @@ -108,7 +108,9 @@
>  	int result;
>  	char* str2 = kmalloc(n + 1, GFP_KERNEL);
>  	if (str2 == 0) return 0;
> -	strlcpy(str2, str, n);
> +	/* NOTE: don't even _think_ about replacing this with strlcpy */
> +	strncpy(str2, str, n);
> +	str2[n] = 0;
>  	va_start(args, format);
>  	result = vsscanf(str2, format, args);
>  	va_end(args);

seems to me you'd be better off doing ...

	len = strlen(str);
	if (len > n)
		len = n;
	memcpy(str2, str, n);
	str2[n] = '\0';

i wrote a short note entitled "strncpy Considered Harmful" a few years ago.
unfortunately, it seems lost in time.

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk


-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01

Re: [PATCH] Toshiba ACPI Extras 0.16

[Lyle Seaman]

> seems to me you'd be better off doing ...
> 
> 	len = strlen(str);
> 	if (len > n)
> 		len = n;
> 	memcpy(str2, str, n);
> 	str2[n] = '\0';
> 
> i wrote a short note entitled "strncpy Considered Harmful" a few years ago.
> unfortunately, it seems lost in time.

Obviously, you meant: 	memcpy(str2, str, len);

But strlen() is dangerous when you point it at something that you can't swear is null-terminated.  It almost always works because, somewhere along the line, there's a null byte.  BUT, it *is* walking off the end of your string and poking about in memory, and you never know what that might do.

You could just do this:
	memcpy(str2, str, n); 	str2[n] = '\0';

But, enlighten me.  What's wrong with strncpy, that is solved by doing the above?




-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01

Re: [PATCH] Toshiba ACPI Extras 0.16

[M. Warner Losh]

So what was wrong with strlcpy?  Was strncpy used because trailing
NULs for the length of the field was required?  That, and the point
below, are the only differences between two versions of the code
posted.

Also:
	strncyp(str2, str, n); str2[n] = '\0';
means that you copy n + 1 bytes into str2, which is typically a bug,
so a comment explaining why it isn't would be in order.

As it is the comment of 'don't even consider using strlcpy' is about
useless because it tells what, but not why.  And there's a long
history of people in the Linux world ignoring dictates when the
reasons get lost in the mists of time.

Warner


-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01

Re: [PATCH] Toshiba ACPI Extras 0.16

[John Belmonte]

Matthew Wilcox wrote:
> seems to me you'd be better off doing ...
> 
> 	len = strlen(str);
> 	if (len > n)
> 		len = n;
> 	memcpy(str2, str, n);
> 	str2[n] = '\0';
> 
> i wrote a short note entitled "strncpy Considered Harmful" a few years ago.
> unfortunately, it seems lost in time.

Since you have that experience then I would expect you to consider 
whether str is zero-terminated before suggesting that I change my code.



-- 
http:// if   l .o  /



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01

Re: [PATCH] Toshiba ACPI Extras 0.16

[John Belmonte]

Lyle Seaman wrote:
> But strlen() is dangerous when you point it at something that you
> can't swear is null-terminated.  It almost always works because,
> somewhere along the line, there's a null byte.  BUT, it *is* walking
> off the end of your string and poking about in memory, and you never
> know what that might do.

It's never acceptable to read undefined memory, and in this case it 
triggers real symptoms such as causing the driver or unrelated drivers 
to fail.



-- 
http:// if   l .o  /



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01

Re: [PATCH] Toshiba ACPI Extras 0.16

[John Belmonte]

M. Warner Losh wrote:
> So what was wrong with strlcpy?  Was strncpy used because trailing
> NULs for the length of the field was required?  That, and the point
> below, are the only differences between two versions of the code
> posted.

The strlcpy function expects the input string to be zero-terminated, 
which is not the case here.

> Also:
> 	strncyp(str2, str, n); str2[n] = '\0';
> means that you copy n + 1 bytes into str2, which is typically a bug,
> so a comment explaining why it isn't would be in order.

It isn't a bug because

     char* str2 = kmalloc(n + 1, GFP_KERNEL)

> As it is the comment of 'don't even consider using strlcpy' is about
> useless because it tells what, but not why.  And there's a long
> history of people in the Linux world ignoring dictates when the
> reasons get lost in the mists of time.

What's going on is that someone made a conversion to my driver which was 
not functionally equivalent and caused a serious bug, and did not notify 
me of the change.  It's my name in the maintainer field and I have to 
deal with resulting bug reports.  I wasted an entire day tracking down 
exactly what happened, discussing it with the people involved and even 
more with those not involved, and preparing a correction.

This should have never happened, and the comment I added is only a 
reaction to this.  To me it states the obvious, "don't break my code", 
and indeed left to my own devices it wouldn't be there.


-- 
http:// if   l .o  /



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01

Re: [PATCH] Toshiba ACPI Extras 0.16

[Matthew Wilcox]

On Sat, Jul 26, 2003 at 05:25:04PM -0400, John Belmonte wrote:
> Matthew Wilcox wrote:
> >seems to me you'd be better off doing ...
> >
> >	len = strlen(str);
> >	if (len > n)
> >		len = n;
> >	memcpy(str2, str, n);
> >	str2[n] = '\0';
> >
> >i wrote a short note entitled "strncpy Considered Harmful" a few years ago.
> >unfortunately, it seems lost in time.
> 
> Since you have that experience then I would expect you to consider 
> whether str is zero-terminated before suggesting that I change my code.

ok, you want strnlen there then.  my original note was in the context of
how completely useless strncpy was for C strings.

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk


-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01

swsusp and ac status

[Daniele Boffi]

Hi,
I noticed that a change in the ac status is not detected after a swsusp. I
think this should be a known issue; is there any workaround available?

How to reproduce the bad behavior:

- swsuspend when on ac (resp. battery) power
- unplug (resp. plug) the ac adapter when the laptop is off
- resume when on battery (resp. ac) power

Then /proc/acpi/ac_adapter/*/state says "on-line" (resp. "off-line").
A new change in the status is then correctly detected.

I tried different acpi configurations (ac in the kernel or as a module, unload
the ac module before suspending and reload it after resuming...) with no
success.

actual kernel 2.6.7 (same behavior with previous ones), no acpi patch, swsusp2
patch

Same behavior with pm-suspend, swsusp and swsusp2.

Daniele


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: swsusp and ac status

[Stefan Seyfried]

On Wed, Jun 23, 2004 at 08:26:53AM +0200, Daniele Boffi wrote:
> Hi,
> I noticed that a change in the ac status is not detected after a swsusp. I
> think this should be a known issue; is there any workaround available?

What machine? hp compaq nx5000?
-- 
Stefan Seyfried



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: swsusp and ac status

[Pavel Machek]

Hi!

> I noticed that a change in the ac status is not detected after a swsusp. I
> think this should be a known issue; is there any workaround available?

Its known, and yes I have ugly workaround.

> Same behavior with pm-suspend, swsusp and swsusp2.

Can you try pm-suspend with powerdown mode set to "platform"?
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: swsusp and ac status

[Daniele Boffi]

> > I noticed that a change in the ac status is not detected after a swsusp. I
> > think this should be a known issue; is there any workaround available?
> 
> Its known, and yes I have ugly workaround.
> 
> > Same behavior with pm-suspend, swsusp and swsusp2.
> 
> Can you try pm-suspend with powerdown mode set to "platform"?

I did and it WORKS!
In my kernel configuration I have all acpi compiled in the kernel (no 
modules).
This probably means there is something wrong with how swsusp2 handles
acpi.

Daniele




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: swsusp and ac status

[Pavel Machek]

Hi!

> > > I noticed that a change in the ac status is not detected after a swsusp. I
> > > think this should be a known issue; is there any workaround available?
> > 
> > Its known, and yes I have ugly workaround.
> > 
> > > Same behavior with pm-suspend, swsusp and swsusp2.
> > 
> > Can you try pm-suspend with powerdown mode set to "platform"?
> 
> I did and it WORKS!
> In my kernel configuration I have all acpi compiled in the kernel (no 
> modules).
> This probably means there is something wrong with how swsusp2 handles
> acpi.

There's nothing wrong, just missing code to do S4 properly. pm-disk is
only one that can do it right at this point.
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com