System hang when trying to enter sleep/standby state

System hang when trying to enter sleep/standby state

[Erik van Pienbroek]

Hello,

Since a few days I've got an new notebook, an Acer Aspire 1406LC (specs
can be found at
http://www.acer.nl/vi/page0.jsp-page78,,79,3,,,104,,,1623,,,,,,,,,,,,,,,,,10
4,3,,3,3,,,,3,,,,3,,,,3,,,,,,,,,,,3,,,0,0,3,,298126721.htm ).
Under Windows 2000 the sleep state works good (this has nothing to do with
ACPI if I'm right).
The standby state works also good.

Now I tried to use the ACPI functions under Linux.
I've installed Redhat 8.0 and compiled the latest 2.4 kernel with the latest
pre-patch (2.4.21-pre4) and the latest ACPI patch(20030125).
Because there isn't much documentation available about the acpi functions I
experimented a bit with the files in the /proc/acpi directory.

With my previous notebook I could issue the command 'apmsleep 12:00' to the
notebook which would let it suspend till 12:00.
Now with my notebook, I can't issue this command anymore (cause my new
notebook doesn't support APM, only ACPI).
Does anybody know if there is an tool/command to let the notebook suspend
till an specified time ?

I've seen there is a file named /proc/acpi/alarm there with an date+time in
it.
I tried to echo an date+time in it, but as soon as the command executed, my
notebook would hang.
Now I tried to install the 2.5.59 kernel with ACPI patch 20030125, but as
soon as the machine booted it would hang.
Now I tried the newest 2.5.59-bk2 patch and my notebook now normally boots.
The hang with the /proc/acpi/alarm is now solved, but as soon as the
date+time is set the
notebook continues to work normally and when the time is reached the
notebook would hang.
The /proc/acpi/sleep same story..if I echo '4' in it the notebook would
continue to work..if I echo '3' the
notebook would hang...with echo '5' the notebook would also hang...
Is this because the ACPI support isn't complete yet or am I doing something
wrong ?

Thanks in advance,

Erik van Pienbroek



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: System hang when trying to enter sleep/standby state

[Jean-Pierre Schwickerath]

"Erik van Pienbroek" <admin-0LxUhLuGNoZIf6P1QZMOBw@public.gmane.org> wrote:

> The /proc/acpi/sleep same story..if I echo '4' in it the notebook
> would continue to work..if I echo '3' the
> notebook would hang...with echo '5' the notebook would also hang...
> Is this because the ACPI support isn't complete yet or am I doing
> something wrong ?


With ACPI the control of Power Management is given into the hands of
the OS. It means you can suspend machines which have a BIOS that doesn't
support suspend to disk or suspend to ram as the OS emulates the
process. 
This could be the case with your notebook. 

I have a hp omnibook xe4400 and a similar behaviour. I didn't manage to
find out if my machine has the ability to suspend to disk from bios yet.

Anyway, swsusp (software suspend) works like a charm. 
Have a look at http://sourceforge.net/projects/swsusp for the kernel
patches and the scripts to suspend your notebook. 


Jean-Pierre

-- 
Powered by Linux From Scratch - http://schwicky.net/
PGP Key ID: 0xEE6F49B4 - AIM/Jabber: Schwicky - ICQ: 4690141

Nothing is impossible... Everything is relative!


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: System hang when trying to enter sleep/standby state

[Pavel Machek]

Hi!

> The /proc/acpi/sleep same story..if I echo '4' in it the notebook would
> continue to work..if I echo '3' the
> notebook would hang...with echo '5' the notebook would also hang...
> Is this because the ACPI support isn't complete yet or am I doing something
> wrong ?

At least '5' should work. Something is wrong ACPI.
								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:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: System hang when trying to enter sleep/standby state

[Erik van Pienbroek]

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

Hi,

I've experimented a little bit more with ACPI and found out the
following things :
With kernel 2.4.21-pre4 when I tried to echo "5" to /proc/acpi/sleep
the console would be killed an the following Oops appeared in the logs :

Feb 11 16:14:43 localhost kernel: Unable to handle kernel NULL pointer
dereference at virtual address 00000000
Feb 11 16:14:43 localhost kernel:  printing eip:
Feb 11 16:14:43 localhost kernel: c01137bb
Feb 11 16:14:43 localhost kernel: *pde = 00000000
Feb 11 16:14:43 localhost kernel: Oops: 0002
Feb 11 16:14:43 localhost kernel: CPU:    0
Feb 11 16:14:43 localhost kernel: EIP:    0010:[<c01137bb>]    Not
tainted
Feb 11 16:14:43 localhost kernel: EFLAGS: 00010002
Feb 11 16:14:43 localhost kernel: eax: 00000000   ebx: 00000001   ecx:
c0311648   edx: 00000000
Feb 11 16:14:43 localhost kernel: esi: 00000005   edi: 00000000   ebp:
da991f60   esp: da991f14
Feb 11 16:14:43 localhost kernel: ds: 0018   es: 0018   ss: 0018
Feb 11 16:14:43 localhost kernel: Process bash (pid: 1158,
stackpage=da991000)
Feb 11 16:14:43 localhost kernel: Stack: c01e1a97 00000003 00000000
00000001 c01e1cc4 00000005 00000002 00000002
Feb 11 16:14:43 localhost kernel:        da991f50 c158b880 c01e27db
00000005 00000000 00000000 00000068 02000000
Feb 11 16:14:43 localhost kernel:        c02de040 c02ddf25 da9a6380
00000a35 00000000 00000000 da9a6380 00000000
Feb 11 16:14:43 localhost kernel: Call Trace:    [<c01e1a97>]
[<c01e1cc4>] [<c01e27db>] [<c0162430>] [<c0141ea3>]
Feb 11 16:14:43 localhost kernel:   [<c010749f>]
Feb 11 16:14:43 localhost kernel:
Feb 11 16:14:43 localhost kernel: Code: 89 02 0f 20 d8 0f 22 d8 31 d2 a1
e4 5c 37 c0 e9 c1 82 02 00

Attached with this mail is my dmesg (taken from kernel 2.4.21-pre4).

Under kernel 2.5.59-bk2 :
First I set the /proc/acpi/debuglevel to 0xffffffff and when I tried
to echo "5" to /proc/acpi/sleep the system would hang.
The last thing that appeared in the logs is this :
Feb 11 16:07:35 localhost kernel: **** Context Switch from TID 351A to
TID 351C ****
Feb 11 16:07:35 localhost kernel:
Feb 11 16:07:35 localhost kernel:    sleep-0315 [351C] [16]
acpi_system_sleep_seq_: ----Entry

I tried getting swsusp to work (I've applied the s4bios patch).
This works under 2.4.21-pre4 (however, if I start up the X server
after resuming the keyboard and mouse fail to respond).
Under 2.5.59-bk2 I get the error that /proc/sys/kernel/swsusp could
not be found (and yes, I've enabled the software suspend option during
make xconfig).
Is this known or am I doing something wrong here ?

I'm also trying to debug the /drivers/acpi/sleep.c from the kernel
source and hoping to find out what goes wrong.
If I find out more info about this behaviour I will report it to this
list.

Greetings,

Erik van Pienbroek

Op zo 09-02-2003, om 10:47 schreef Pavel Machek:
> Hi!
> 
> > The DSDT table of my laptop can be found at www.zapped.2y.net/dsdt.dsl
> > I hope it's of use to any of you.
> 
> I'm not good at reading DSDT's.
> 
> > If you need more information about my notebook configuration, please ask.
> > Oh yeah, I performed the echo's on /proc/acpi/sleep with the 2.5.59-bk2
> > kernel.
> > And can anyone explain to me what the /proc/acpi/alarm file is meant
> > for ?
> 
> You need sleep working, then care about alarm. (It may well be
> broken...)
> 								Pavel
> -- 
> Casualities in World Trade Center: ~3k dead inside the building,
> cryptography in U.S.A. and free speech in Czech Republic.
> 


[-- Attachment #2: dmesg.txt --]
[-- Type: text/plain, Size: 8759 bytes --]

Linux version 2.4.21-pre4 (root-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org) (gcc versie 3.2 20020903 (Red Hat Linux 8.0 3.2-7)) #3 di feb 11 15:58:02 GMT+1 2003
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009f000 (usable)
 BIOS-e820: 000000000009f000 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000dc000 - 00000000000e0000 (reserved)
 BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000001fef0000 (usable)
 BIOS-e820: 000000001fef0000 - 000000001feff000 (ACPI data)
 BIOS-e820: 000000001feff000 - 000000001ff00000 (ACPI NVS)
 BIOS-e820: 000000001ff00000 - 000000001ff80000 (usable)
 BIOS-e820: 000000001ff80000 - 0000000020000000 (reserved)
 BIOS-e820: 00000000ff800000 - 00000000ffc00000 (reserved)
 BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)
511MB LOWMEM available.
ACPI: have wakeup address 0xc0001000
On node 0 totalpages: 130944
zone(0): 4096 pages.
zone(1): 126848 pages.
zone(2): 0 pages.
ACPI: RSDP (v000 TOSCPL                     ) @ 0x000f6db0
ACPI: RSDT (v001 TOSCPL   RSDT   01540.00000) @ 0x1fefacc1
ACPI: FADT (v001 TOSCPL BR20     01540.00000) @ 0x1fefef64
ACPI: BOOT (v001 TOSCPL $SBFTBL$ 01540.00000) @ 0x1fefefd8
ACPI: DSDT (v001 COMPAL BR20     01540.00000) @ 0x00000000
ACPI: BIOS passes blacklist
ACPI: MADT not present
Kernel command line: ro root=/dev/hda2 hdc=ide-scsi acpi_sleep=s3_bios
ide_setup: hdc=ide-scsi
No local APIC present or hardware disabled
Initializing CPU#0
Detected 2491.994 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 4967.62 BogoMIPS
Memory: 514928k/523776k available (1763k kernel code, 8396k reserved, 601k data, 104k init, 0k highmem)
Dentry cache hash table entries: 65536 (order: 7, 524288 bytes)
Inode cache hash table entries: 32768 (order: 6, 262144 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 32768 (order: 5, 131072 bytes)
Page-cache hash table entries: 131072 (order: 7, 524288 bytes)
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU:     After generic, caps: bfebf9ff 00000000 00000000 00000000
CPU:             Common caps: bfebf9ff 00000000 00000000 00000000
CPU: Intel(R) Pentium(R) 4 CPU 2.50GHz stepping 07
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.40 (20010327) Richard Gooch (rgooch-r1x6VkxMR+00zabcByZE4g@public.gmane.org)
mtrr: detected mtrr type: Intel
ACPI: Subsystem revision 20030122
PCI: PCI BIOS revision 2.10 entry at 0xfd9a0, last bus=2
PCI: Using configuration type 1
 tbxface-0098 [03] acpi_load_tables      : ACPI Tables successfully acquired
Parsing all Control Methods:...................................................................................................................................................
Table [DSDT] - 509 Objects with 47 Devices 147 Methods 19 Regions
ACPI Namespace successfully loaded at root c03859fc
evxfevnt-0073 [04] acpi_enable           : Transition to ACPI mode successful
   evgpe-0262: *** Info: GPE Block0 defined as GPE0 to GPE15
   evgpe-0262: *** Info: GPE Block1 defined as GPE16 to GPE31
Executing all Device _STA and_INI methods:...............................................
47 Devices found containing: 47 _STA, 2 _INI methods
Completing Region/Field/Buffer/Package initialization:..............................................................
Initialized 15/19 Regions 0/0 Fields 33/33 Buffers 14/14 Packages (509 nodes)
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: System [ACPI] (supports S0 S3 (swsusp) S4 S5)
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
Transparent bridge - Intel Corp. 82801BA/CA/DB PCI Bridge
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGP_._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.SLOT._PRT]
[ACPI Debug] Buffer: Length 06
ACPI: PCI Interrupt Link [LNKA] (IRQs *5)
ACPI: PCI Interrupt Link [LNKB] (IRQs *11)
ACPI: PCI Interrupt Link [LNKC] (IRQs 11, disabled)
ACPI: PCI Interrupt Link [LNKD] (IRQs *5)
[ACPI Debug] Buffer: Length 06
ACPI: PCI Interrupt Link [LNKE] (IRQs *11)
[ACPI Debug] Buffer: Length 06
ACPI: PCI Interrupt Link [LNKH] (IRQs 5, enabled at IRQ 11)
ACPI: Embedded Controller [EC0] (gpe 28)
PCI: Probing PCI hardware
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11
PCI: Using ACPI for IRQ routing
PCI: if you experience problems, try using option 'pci=noacpi' or even 'acpi=off'
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
Journalled Block Device driver loaded
ACPI: AC Adapter [ACAD] (on-line)
ACPI: Battery Slot [BAT1] (battery present)
ACPI: Power Button (FF) [PWRF]
ACPI: Lid Switch [LID]
ACPI: Processor [CPU0] (supports C1 C2)
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled
Real Time Clock Driver v1.10e
i810_rng: RNG not detected
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
loop: loaded (max 8 devices)
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 439M
agpgart: Detected Intel i845 chipset
agpgart: AGP aperture is 64M @ 0xec000000
[drm] Initialized tdfx 1.0.0 20010216 on minor 0
[drm] AGP 0.99 on Intel i845 @ 0xec000000 64MB
[drm] Initialized i810 1.2.0 20010920 on minor 1
Uniform Multi-Platform E-IDE driver Revision: 7.00beta-2.4
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH2: IDE controller at PCI slot 00:1f.1
ICH2: chipset revision 5
ICH2: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0x1800-0x1807, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0x1808-0x180f, BIOS settings: hdc:DMA, hdd:pio
hda: IC25N030ATCS04-0, ATA DISK drive
blk: queue c039fda0, I/O limit 4095Mb (mask 0xffffffff)
hdc: DW-224E, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: host protected area => 1
hda: 58605120 sectors (30006 MB) w/1768KiB Cache, CHS=3648/255/63, UDMA(100)
Partition check:
 hda: hda1 hda2 hda3
SCSI subsystem driver Revision: 1.00
scsi0 : SCSI host adapter emulation for IDE ATAPI devices
  Vendor: TEAC      Model: DW-224E           Rev: F.0A
  Type:   CD-ROM                             ANSI SCSI revision: 02
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
Initializing USB Mass Storage driver...
usb.c: registered new driver usb-storage
USB Mass Storage support registered.
Linux video capture interface: v1.00
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 4096 buckets, 32Kbytes
TCP: Hash tables configured (established 32768 bind 65536)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
EXT3-fs: INFO: recovery required on readonly filesystem.
EXT3-fs: write access will be enabled during recovery.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 104k freed
usb.c: registered new driver hid
hid-core.c: v1.8.1 Andreas Gal, Vojtech Pavlik <vojtech-AlSwsSmVLrQ@public.gmane.org>
hid-core.c: USB HID support drivers
mice: PS/2 mouse device common for all mice
EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,2), internal journal
Adding Swap: 522104k swap-space (priority -1)
eepro100.c:v1.09j-t 9/29/99 Donald Becker http://www.scyld.com/network/eepro100.html
eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin <saw-5bpFXmC1L3aJ4eUNlOKu3Q@public.gmane.org> and others
eth0: Intel Corp. 82801BA/BAM/CA/CAM Ethernet Controller, 00:02:3F:B3:34:D2, IRQ 11.
  Board assembly 000000-000, Physical connectors present: RJ45
  Primary interface chip i82555 PHY #1.
  General self-test: passed.
  Serial sub-system self-test: passed.
  Internal registers self-test: passed.
  ROM checksum self-test: passed (0x04f4518b).
Intel 810 + AC97 Audio, version 0.24, 16:01:59 Feb 11 2003
PCI: Setting latency timer of device 00:1f.5 to 64
i810: Intel ICH2 found at IO 0x1880 and 0x1c00, MEM 0x0000 and 0x0000, IRQ 11
i810_audio: Audio Controller supports 6 channels.
i810_audio: Defaulting to base 2 channel mode.
i810_audio: Resetting connection 0
ac97_codec: AC97 Audio codec, id: CRY52 (Cirrus Logic CS4299 rev D)
i810_audio: AC'97 codec 0 supports AMAP, total channels = 2

Re: System hang when trying to enter sleep/standby state

[Patrick Mochel]

On 11 Feb 2003, Erik van Pienbroek wrote:

> Hi,
> 
> I've experimented a little bit more with ACPI and found out the
> following things :
> With kernel 2.4.21-pre4 when I tried to echo "5" to /proc/acpi/sleep
> the console would be killed an the following Oops appeared in the logs :

I would recommend never, ever doing 'echo 5 > /proc/acpi/sleep', 
especially if you're trying to suspend the system. 

S5 (the state the system enters when you do that) is defined as 'Soft 
Off'. It is equivalent to what ACPI does when you shut down the system and 
it automatically powers it off for you. You cannot resume from it; you 
must restart the machine. 

The reason it's defined by the spec is to a) allow software to power down 
the system, and b) allow some events to trigger a power on by the firmware 
(like wake-on-lan). 

ACPI should not allow a user to write '5' to that file. It used to be that 
way, but someone clever decided that that interface should support _all_ 
sleep states. (It might have been me, in one of my finer moments). 


Andy, I recommend removing that from 2.4, and I'll send you a patch for 
2.5..

	-pat



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: System hang when trying to enter sleep/standby state

[Karol Kozimor]

Thus wrote Patrick Mochel:
> ACPI should not allow a user to write '5' to that file. It used to be that 
> way, but someone clever decided that that interface should support _all_ 
> sleep states. (It might have been me, in one of my finer moments). 

May I ask: why? Is it really dangerous to leave it like it is now? Does it
break anything? I actually used it a couple of times, not bothering to hold
my poweroff button for the time needed to poweroff the machine completely.
As for potential dangers, I see many other ways of using the /proc 
interface that can be really *much* more harmful to the system, yet they
don't cease to exist. However confusing it might be now, it is fully
functional, at least. I can't really see any reason for crippling that
functionality. Please, do leave it the way it is.

Gosh, where's my manners... I hereby say hello to everyone. Hope you don't
take the above too personal or whatever, I'm a newbie to ACPI and I might
as well miss the whole point there.
Regards,

-- 
Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org


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

Re: System hang when trying to enter sleep/standby state

[Patrick Mochel]

On Wed, 12 Feb 2003, Karol Kozimor wrote:

> Thus wrote Patrick Mochel:
> > ACPI should not allow a user to write '5' to that file. It used to be that 
> > way, but someone clever decided that that interface should support _all_ 
> > sleep states. (It might have been me, in one of my finer moments). 
> 
> May I ask: why? Is it really dangerous to leave it like it is now? Does it
> break anything? I actually used it a couple of times, not bothering to hold
> my poweroff button for the time needed to poweroff the machine completely.
> As for potential dangers, I see many other ways of using the /proc 
> interface that can be really *much* more harmful to the system, yet they
> don't cease to exist. However confusing it might be now, it is fully
> functional, at least. I can't really see any reason for crippling that
> functionality. Please, do leave it the way it is.

It's another chance to shoot yourself in the foot, and it should be 
removed. 

There is an explicit shutdown sequence that the kernel normally goes 
through. This does vitally important things like flushing disk buffers, 
etc. Circumventing this is asking for trouble, not to mention disk 
corruption. 

The fact that S5 is a sleep state is slightly confusing, but a decent 
design decision of the spec, since you can trigger a system to wake up. 
But that in no way justifies the mechanism to arbitrarily use it. 

The following patch removes support for triggering an S5 transition from 
proc/acpi/sleep. It also fixes an unchecked array reference with the value 
written to the file. 

It's for 2.5, though should be conceptually identical to anything in 2.4.  
Andy, you may apply manually, or wait a couple of days and I'll have a
bkbits.net tree you can pull from with a few other fixes in it..

	-pat

===== drivers/acpi/sleep.c 1.11 vs edited =====
--- 1.11/drivers/acpi/sleep.c	Mon Dec 30 06:29:15 2002
+++ edited/drivers/acpi/sleep.c	Wed Feb 12 14:58:09 2003
@@ -318,14 +318,14 @@
 	size_t			count,
 	loff_t			*ppos)
 {
-	acpi_status		status = AE_OK;
+	acpi_status		status = AE_ERROR;
 	char			state_string[12] = {'\0'};
 	u32			state = 0;
 
 	ACPI_FUNCTION_TRACE("acpi_system_write_sleep");
 
 	if (count > sizeof(state_string) - 1)
-		return_VALUE(-EINVAL);
+		goto Done;
 
 	if (copy_from_user(state_string, buffer, count))
 		return_VALUE(-EFAULT);
@@ -333,22 +333,25 @@
 	state_string[count] = '\0';
 	
 	state = simple_strtoul(state_string, NULL, 0);
-	
+
+	if (state < 1 || state > 4)
+		goto Done;
+
 	if (!sleep_states[state])
 		return_VALUE(-ENODEV);
 
 #ifdef CONFIG_SOFTWARE_SUSPEND
 	if (state == 4) {
 		software_suspend();
-		return_VALUE(count);
+		goto Done;
 	}
 #endif
 	status = acpi_suspend(state);
-
+ Done:
 	if (ACPI_FAILURE(status))
-		return_VALUE(-ENODEV);
-	
-	return_VALUE(count);
+		return_VALUE(-EINVAL);
+	else
+		return_VALUE(count);
 }
 
 static int acpi_system_alarm_seq_show(struct seq_file *seq, void *offset)



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

Re: System hang when trying to enter sleep/standby state

[Jens Haug]

> I would recommend never, ever doing 'echo 5 > /proc/acpi/sleep', 
> especially if you're trying to suspend the system. 

It's not worse than pushing the power button on a normal system
(or hold the power button on an ACPI system).

> ACPI should not allow a user to write '5' to that file. It used to be that 
> way, but someone clever decided that that interface should support _all_ 
> sleep states. (It might have been me, in one of my finer moments). 

The regular user can't write anything to that file - this must be
root. He's supposed to know what he's doing. If he wants to turn the
machine off without halting the system, then that's his choice. Think
of something like an embedded system to control a machine. Many 
machines have an emergency off whith a huge red button. This is the
software version of this red button. Your software can press this
if you thing that's necessary.

> Andy, I recommend removing that from 2.4, and I'll send you a patch for 
> 2.5..

I'd like to have it in. I don't know what I could ever use it for,
but I'd really prefer to have this possibility.


Jens

-- 
Jens Haug
IKFF Universität Stuttgart              Tel. 0711/685-6422
Pfaffenwaldring 9                       Fax  0711/685-6356
70550 Stuttgart	                haug-X6ztD3ggwzuBAmxm6OvjtTjhTm2NLCe8@public.gmane.org



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

Re: System hang when trying to enter sleep/standby state

[Patrick Mochel]

On Thu, 13 Feb 2003, Jens Haug wrote:

> > I would recommend never, ever doing 'echo 5 > /proc/acpi/sleep', 
> > especially if you're trying to suspend the system. 
> 
> It's not worse than pushing the power button on a normal system
> (or hold the power button on an ACPI system).

You're absolutely right. But, most people do those things deliberately, 
and know the consequences. 

Think about how this thread started: $Random User sees his system doesn't
suspend when writing '4' to that file, so he tries every other value.
That's a perfectly valid thing to do, and the kernel has no right to crash
when he does something like that. In order not to crash, and to guarantee
that data does not get corrupted, we should execute sys_reboot() from
inside the kernel. 

Which is possible, but ludicrous. If you want to halt your system, use
halt(1). We do not need to invent new ways to do old things, especially 
when they are dangerous. 

> > ACPI should not allow a user to write '5' to that file. It used to be that 
> > way, but someone clever decided that that interface should support _all_ 
> > sleep states. (It might have been me, in one of my finer moments). 
> 
> The regular user can't write anything to that file - this must be
> root. He's supposed to know what he's doing. If he wants to turn the
> machine off without halting the system, then that's his choice. Think
> of something like an embedded system to control a machine. Many 
> machines have an emergency off whith a huge red button. This is the
> software version of this red button. Your software can press this
> if you thing that's necessary.

That's crap. For one, most systems are single-user systems. That was 
certainly the case for the guy that crashed his system by writing to that 
file. So, by definition, root knows only as much as the most knowledgable 
user. 

For another, as mentioned before, we have safe mechanisms for halting a 
system. See 'man 1 halt'. 

> > Andy, I recommend removing that from 2.4, and I'll send you a patch for 
> > 2.5..
> 
> I'd like to have it in. I don't know what I could ever use it for,
> but I'd really prefer to have this possibility.

Listen to yourself. Also, take into account your design philosophies 
concerning Linux and other operating systems. This comment is poorly 
thought out and completely invalid.

We don't keep features around because they might be useful to someone at 
some point in the future. We do what is necessary and nothing more. 

We also don't leave gaping holes for users to accidentally screw 
themselves. Deliberately, sure. But, not on accident, that's just rude. 

There is no freedom in anarchy. Just because you can have something 
doesn't mean that you should. This is not about enforcing policy or 
behavior, or knowing 'what is best' for a user. This is about saving users 
heartache and valuable data, and developers from saying 'don't do that' a 
thousand times. 

End of story. 

	-pat



-------------------------------------------------------
This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your  SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en

Re: System hang when trying to enter sleep/standby state

[Jens Haug]

> > > I would recommend never, ever doing 'echo 5 > /proc/acpi/sleep', 
> > > especially if you're trying to suspend the system. 
> > 
> > It's not worse than pushing the power button on a normal system
> > (or hold the power button on an ACPI system).
> 
> You're absolutely right. But, most people do those things deliberately, 
> and know the consequences. 

Do you think someone becomes root and does an "echo 5 > /proc/acpi/sleep"
by accident? ;-)

> Think about how this thread started: $Random User sees his system doesn't
> suspend when writing '4' to that file, so he tries every other value.

This is not a random user. This is someone who plays around with his
system while testing beta kernel drivers. 
The random user at this stage doesn't know about acpi at all. The
random user in the future (when acpi comes with Suse or RedHat Linux 
out of the box) will only use the GUIs to suspend and such. So there's
no problem at all, I think.

> That's a perfectly valid thing to do, and the kernel has no right to crash
> when he does something like that. 

The kernel has the right to do what the specs say. There might be 
systems where this is wanted (which boot from read only medium and
need a really fast poweroff).

> Which is possible, but ludicrous. If you want to halt your system, use
> halt(1). We do not need to invent new ways to do old things, especially 
> when they are dangerous. 

This is a new thing: You can power off in less than a second.

> > The regular user can't write anything to that file - this must be
> > root. He's supposed to know what he's doing. If he wants to turn the
> > machine off without halting the system, then that's his choice. Think
> > of something like an embedded system to control a machine. Many 
> > machines have an emergency off whith a huge red button. This is the
> > software version of this red button. Your software can press this
> > if you thing that's necessary.
> 
> That's crap. 

You're too kind.

> For one, most systems are single-user systems. 

Do you want a kernel for most systems or a general purpose, scalable
OS? You're thinking the windows way. I'm glad that Linux is better.

> That was 
> certainly the case for the guy that crashed his system by writing to that 
> file. So, by definition, root knows only as much as the most knowledgable 
> user. 

No, by definition root is the administrator and knows what he's doing.
It might be true that there are many people out there who do not know
what they are doing - but they hardly ever become root in the console
and echo numbers anywhere in /proc. And if they do so - well, that's
their fault. 

> For another, as mentioned before, we have safe mechanisms for halting a 
> system. See 'man 1 halt'. 

You have *no* other mechanism to turn your box off in less than one
second.

> > I'd like to have it in. I don't know what I could ever use it for,
> > but I'd really prefer to have this possibility.
> 
> Listen to yourself. Also, take into account your design philosophies 
> concerning Linux and other operating systems. This comment is poorly 
> thought out and completely invalid.

Will you just keep on saying my comment was no good or could you
maybe tell me what exactly is wrong with it?

> We don't keep features around because they might be useful to someone at 
> some point in the future. We do what is necessary and nothing more. 

Oh, do we? We don't even know what people are doing. This is not a
set top box. This is an operating system. People build all kinds of
stuff from this. Do you think you know what is necessary for *all*
the things that can be done with Linux?

> We also don't leave gaping holes for users to accidentally screw 
> themselves. Deliberately, sure. But, not on accident, that's just rude. 

Oops, I typed "sudo echo 5 > /proc/acpi/sleep" by accident again.
Sometimes it just happens. ;-)


Jens

-- 
Jens Haug
IKFF Universität Stuttgart              Tel. 0711/685-6422
Pfaffenwaldring 9                       Fax  0711/685-6356
70550 Stuttgart	                haug-X6ztD3ggwzuBAmxm6OvjtTjhTm2NLCe8@public.gmane.org



-------------------------------------------------------
This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your  SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en

Re: System hang when trying to enter sleep/standby state

[Patrick Mochel]

> > You're absolutely right. But, most people do those things deliberately, 
> > and know the consequences. 
> 
> Do you think someone becomes root and does an "echo 5 > /proc/acpi/sleep"
> by accident? ;-)

Definitely. By, trying a range of values, they stumble on one that crashes 
their system. 

> > Think about how this thread started: $Random User sees his system doesn't
> > suspend when writing '4' to that file, so he tries every other value.
> 
> This is not a random user. This is someone who plays around with his
> system while testing beta kernel drivers. 
> The random user at this stage doesn't know about acpi at all. The
> random user in the future (when acpi comes with Suse or RedHat Linux 
> out of the box) will only use the GUIs to suspend and such. So there's
> no problem at all, I think.

The GUIs should not, and will not, support writing directly to that file. 
In the perfect, abstract future, we will not even have /proc/acpi/sleep, 
we will have an abstracted for entering sleep states. 

Note that GUIs already support shutting down safely. 

> > That's a perfectly valid thing to do, and the kernel has no right to crash
> > when he does something like that. 
> 
> The kernel has the right to do what the specs say. There might be 
> systems where this is wanted (which boot from read only medium and
> need a really fast poweroff).

The kernel does what the specs say. Read the code. The system is placed 
into S5 when doing off from a shutdown sequence, exactly what the spec 
intended to be done. 

As a whole, we do enforce a minimum amount of policy we do not want to 
lose users data. And that will happen. 

Let me repeat, and try and get you to listen: 

You *will* corrupt your data if you do not flush the disk buffers. 
You *will* corrupt your data if you do not flush the disk buffers. 
You *will* corrupt your data if you do not flush the disk buffers. 

That's why it's so slow when you do a normal shutdown. That's why 
immediately putting the system into S5 is so fast - we don't flush the 
buffers. 

If you boot from a read-only medium and you want a fast poweroff, guess 
what you use? halt(1). The same mechanism works, and it's faster because 
there are no buffers to flush. 

> > For one, most systems are single-user systems. 
> 
> Do you want a kernel for most systems or a general purpose, scalable
> OS? You're thinking the windows way. I'm glad that Linux is better.

This is not a philosophical issue. It's fact. The disabling of this 
'feature' is good for single-user systems. It's better for multi-user 
systems. It prevents a user from not only screwing themselves, but 
screwing every other user.

> > That was 
> > certainly the case for the guy that crashed his system by writing to that 
> > file. So, by definition, root knows only as much as the most knowledgable 
> > user. 
> 
> No, by definition root is the administrator and knows what he's doing.
> It might be true that there are many people out there who do not know
> what they are doing - but they hardly ever become root in the console
> and echo numbers anywhere in /proc. And if they do so - well, that's
> their fault. 

Wrong. More and more systems are desktop systems, with one user attached 
to them. That is a fact. That's the space that ACPI power management is 
most important, and the area that we're most concerned with ATM. 

You are right, though, if they start writing random values into /proc, it 
is their fault. But, the random range of numbers to be written to  
/proc/acpi/sleep is small, and not that random. The documentation suggests 
that some values work and others don't. It's human nature to exercise 
curiosity and experiment with other close values. If they do, which they 
are so likely to, I do not want to see them cause any harm to themselves. 

> > For another, as mentioned before, we have safe mechanisms for halting a 
> > system. See 'man 1 halt'. 
> 
> You have *no* other mechanism to turn your box off in less than one
> second.

Then concentrate on that, and don't encourage dangerous features in the 
kernel. 

> > We don't keep features around because they might be useful to someone at 
> > some point in the future. We do what is necessary and nothing more. 
> 
> Oh, do we? We don't even know what people are doing. This is not a
> set top box. This is an operating system. People build all kinds of
> stuff from this. Do you think you know what is necessary for *all*
> the things that can be done with Linux?

That is not the Linux design philosophy. You are welcome to implement a 
patchset incorporates every feature known to man. There is at least one 
project that does that. But, the mainstream kernel is not a trawling barge 
for random features, useful or not. This particular item is dangerous and 
will be removed from the kernel. 


	-pat



-------------------------------------------------------
This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your  SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en

Re: System hang when trying to enter sleep/standby state

[Darren Benham]

Oh come on, this is Linux not preschool.

How about making it a .config option, default to "unset" and with a big
warning in the help?
Jens Haug said:
>> > > I would recommend never, ever doing 'echo 5 > /proc/acpi/sleep',
>> > > especially if you're trying to suspend the system.
>> >
>> > It's not worse than pushing the power button on a normal system (or
>> > hold the power button on an ACPI system).
>>
>> You're absolutely right. But, most people do those things
>> deliberately,  and know the consequences.
>
> Do you think someone becomes root and does an "echo 5 >
> /proc/acpi/sleep" by accident? ;-)
>
>> Think about how this thread started: $Random User sees his system
>> doesn't suspend when writing '4' to that file, so he tries every other
>> value.
>
> This is not a random user. This is someone who plays around with his
> system while testing beta kernel drivers.
> The random user at this stage doesn't know about acpi at all. The
> random user in the future (when acpi comes with Suse or RedHat Linux
> out of the box) will only use the GUIs to suspend and such. So there's
> no problem at all, I think.
>
>> That's a perfectly valid thing to do, and the kernel has no right to
>> crash when he does something like that.
>
> The kernel has the right to do what the specs say. There might be
> systems where this is wanted (which boot from read only medium and need
> a really fast poweroff).
>
>> Which is possible, but ludicrous. If you want to halt your system, use
>> halt(1). We do not need to invent new ways to do old things,
>> especially  when they are dangerous.
>
> This is a new thing: You can power off in less than a second.
>
>> > The regular user can't write anything to that file - this must be
>> > root. He's supposed to know what he's doing. If he wants to turn the
>> > machine off without halting the system, then that's his choice.
>> > Think of something like an embedded system to control a machine.
>> > Many  machines have an emergency off whith a huge red button. This
>> > is the software version of this red button. Your software can press
>> > this if you thing that's necessary.
>>
>> That's crap.
>
> You're too kind.
>
>> For one, most systems are single-user systems.
>
> Do you want a kernel for most systems or a general purpose, scalable
> OS? You're thinking the windows way. I'm glad that Linux is better.
>
>> That was
>> certainly the case for the guy that crashed his system by writing to
>> that  file. So, by definition, root knows only as much as the most
>> knowledgable  user.
>
> No, by definition root is the administrator and knows what he's doing.
> It might be true that there are many people out there who do not know
> what they are doing - but they hardly ever become root in the console
> and echo numbers anywhere in /proc. And if they do so - well, that's
> their fault.
>
>> For another, as mentioned before, we have safe mechanisms for halting
>> a  system. See 'man 1 halt'.
>
> You have *no* other mechanism to turn your box off in less than one
> second.
>
>> > I'd like to have it in. I don't know what I could ever use it for,
>> > but I'd really prefer to have this possibility.
>>
>> Listen to yourself. Also, take into account your design philosophies
>> concerning Linux and other operating systems. This comment is poorly
>> thought out and completely invalid.
>
> Will you just keep on saying my comment was no good or could you
> maybe tell me what exactly is wrong with it?
>
>> We don't keep features around because they might be useful to someone
>> at  some point in the future. We do what is necessary and nothing
>> more.
>
> Oh, do we? We don't even know what people are doing. This is not a set
> top box. This is an operating system. People build all kinds of stuff
> from this. Do you think you know what is necessary for *all* the things
> that can be done with Linux?
>
>> We also don't leave gaping holes for users to accidentally screw
>> themselves. Deliberately, sure. But, not on accident, that's just
>> rude.
>
> Oops, I typed "sudo echo 5 > /proc/acpi/sleep" by accident again.
> Sometimes it just happens. ;-)
>
>
> Jens
>
> --
> Jens Haug
> IKFF Universität Stuttgart              Tel. 0711/685-6422
> Pfaffenwaldring 9                       Fax  0711/685-6356
> 70550 Stuttgart	                haug-X6ztD3ggwzuBAmxm6OvjtTjhTm2NLCe8@public.gmane.org
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
> are you planning your Web Server Security? Click here to get a FREE
> Thawte SSL guide and find the answers to all your  SSL security issues.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/acpi-devel


-- 
Darren




-------------------------------------------------------
This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your  SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en

Re: System hang when trying to enter sleep/standby state

[Matthew Wilcox]

On Thu, Feb 13, 2003 at 11:00:52AM -0800, Darren Benham wrote:
> Oh come on, this is Linux not preschool.
> 
> How about making it a .config option, default to "unset" and with a big
> warning in the help?

more config options are a bad thing, mmkay?
Pat's right, this is an unnecessarily stupid way of letting people
shoot themself in the foot.

-- 
"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 is sponsored by: FREE  SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your  SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en

Re: System hang when trying to enter sleep/standby state

[Karol Kozimor]

Thus wrote Patrick Mochel:
> > > You're absolutely right. But, most people do those things deliberately, 
> > > and know the consequences. 
> > Do you think someone becomes root and does an "echo 5 > /proc/acpi/sleep"
> > by accident? ;-)
> Definitely. By, trying a range of values, they stumble on one that crashes 
> their system. 

Yeah, as if all the values worked smoothly on all systems. Echoing '1' or
'3' hangs my system in most (S1) or all cases (S3). Should they be
excluded also, or left as a config option? Enabled when they finally work
and are tested on all possible systems?

> > > Think about how this thread started: $Random User sees his system doesn't
> > > suspend when writing '4' to that file, so he tries every other value.
> > This is not a random user. This is someone who plays around with his
> > system while testing beta kernel drivers. 
> > The random user at this stage doesn't know about acpi at all. The
> > random user in the future (when acpi comes with Suse or RedHat Linux 
> > out of the box) will only use the GUIs to suspend and such. So there's
> > no problem at all, I think.
> The GUIs should not, and will not, support writing directly to that file. 
> In the perfect, abstract future, we will not even have /proc/acpi/sleep, 
> we will have an abstracted for entering sleep states. 

So, if you plan to change this anyway in the future (of ACPI becoming
mainstream, or being included in distros), what is really the reason of
changing it now, during the development steage?

Again, should I pull the reset button off my chassis just because I can
accidentally push it, have my machine rebooted, and oh my oh my, loose my
data? Is there really anybody who experiments with the sleep states not
having synced, or otherwise "secured" his data or filesystems?

[...]
> As a whole, we do enforce a minimum amount of policy we do not want to 
> lose users data. And that will happen. 
> 
> Let me repeat, and try and get you to listen: 
> 
> You *will* corrupt your data if you do not flush the disk buffers. 
> You *will* corrupt your data if you do not flush the disk buffers. 
> You *will* corrupt your data if you do not flush the disk buffers. 
> 
> That's why it's so slow when you do a normal shutdown. That's why 
> immediately putting the system into S5 is so fast - we don't flush the 
> buffers. 

This is obvious. At least for halfway intelligent users, who know what they
are doing. As Jens said, no random user will ever tamper with /proc, and if
he does, well, it's all his fault anyway.

[...]
> You are right, though, if they start writing random values into /proc, it 
> is their fault. But, the random range of numbers to be written to  
> /proc/acpi/sleep is small, and not that random. The documentation suggests 
> that some values work and others don't. It's human nature to exercise 
> curiosity and experiment with other close values. If they do, which they 
> are so likely to, I do not want to see them cause any harm to themselves. 

So let the documentation suggest explicitly, what exactly echoing 5 to that
file does? Anyway, as I said earlier, chances are that other values
will cause them equal harm. So what? Is that really the single way to harm
the machine, or cause filesystem corruption? I knew a user, who, when told
to copy a file on /dev/hda1, did exactly what he was said, i.e. "cp
filename /dev/hda1"... does this show that copying over a block device
should be disabled? That something is *generally* a bad idea doesn't mean,
it has no use whatsoever. 

Really, on modern desktops possibly data-corrupting reboots (due to a 
faulty X / DRI / whatever driver) are much more frequent to really care for
a poor user that experiments with ACPI not knowing much about it.

> > > For another, as mentioned before, we have safe mechanisms for halting a 
> > > system. See 'man 1 halt'. 
> > You have *no* other mechanism to turn your box off in less than one
> > second.
> Then concentrate on that, and don't encourage dangerous features in the 
> kernel. 

To be frank, there are some features in the kernel, that during the
configuration stage are labeled as ,,DANGEROUS''. For what reasons, do you
think, they still exist?

Regards,

-- 
Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org


-------------------------------------------------------
This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your  SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en

Re: System hang when trying to enter sleep/standby state

[Pavel Machek]

Hi!

> > > You're absolutely right. But, most people do those things deliberately, 
> > > and know the consequences. 
> > 
> > Do you think someone becomes root and does an "echo 5 > /proc/acpi/sleep"
> > by accident? ;-)
> 
> Definitely. By, trying a range of values, they stumble on one that crashes 
> their system. 

And what? Try echo 5 > /proc/kmem and see what you get *then*.

> > > That's a perfectly valid thing to do, and the kernel has no right to crash
> > > when he does something like that. 
> > 
> > The kernel has the right to do what the specs say. There might be 
> > systems where this is wanted (which boot from read only medium and
> > need a really fast poweroff).
> 
> The kernel does what the specs say. Read the code. The system is placed 
> into S5 when doing off from a shutdown sequence, exactly what the spec 
> intended to be done. 
> 
> As a whole, we do enforce a minimum amount of policy we do not want to 
> lose users data. And that will happen. 
> 
> Let me repeat, and try and get you to listen: 
> 
> You *will* corrupt your data if you do not flush the disk buffers. 

Not true... With ext3 or reiser it is okay to power down system like
that.

> That's why it's so slow when you do a normal shutdown. That's why 
> immediately putting the system into S5 is so fast - we don't flush the 
> buffers. 

Normal shutdown takes services down in reverse older they start.

If you reboot by SAK-S,U,B, you can do it under a second on almost any
system. If you powerdown by 
kill -15 -1; sleep 1; kill -9 -1; umount /; echo 5 > /proc/acpi/sleep

you have clean & very fast way to do it.

And btw if someone does echo 4 > /proc/acpi/sleep and then fails to
pass resume=/dev/hdaX he's in pretty much same situation as when he
does echo 5 > sleep... And *way* worse if he manages to pass resume=
after he does fsck (silent corruption vs. fsck being run).

Better don't mess with sleep if you don't know what you know what you
are doing.

								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]


-------------------------------------------------------
This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your  SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en

Re: System hang when trying to enter sleep/standby state

[Jens Haug]

> How about making it a .config option, default to "unset" and with a big
> warning in the help?

Best solution IMHO.



Jens

-- 
Jens Haug
IKFF Universität Stuttgart              Tel. 0711/685-6422
Pfaffenwaldring 9                       Fax  0711/685-6356
70550 Stuttgart	                haug-X6ztD3ggwzuBAmxm6OvjtTjhTm2NLCe8@public.gmane.org



-------------------------------------------------------
This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your  SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en

Re: System hang when trying to enter sleep/standby state

[Jens Haug]

> > > Think about how this thread started: $Random User sees his system doesn't
> > > suspend when writing '4' to that file, so he tries every other value.
> > 
> > This is not a random user. This is someone who plays around with his
> > system while testing beta kernel drivers. 
> > The random user at this stage doesn't know about acpi at all. The
> > random user in the future (when acpi comes with Suse or RedHat Linux 
> > out of the box) will only use the GUIs to suspend and such. So there's
> > no problem at all, I think.
> 
> The GUIs should not, and will not, support writing directly to that file. 
> In the perfect, abstract future, we will not even have /proc/acpi/sleep, 
> we will have an abstracted for entering sleep states. 
> 
> Note that GUIs already support shutting down safely. 

Then what's your problem? The random user will use these GUIs and 
will not crash his system this way.

> As a whole, we do enforce a minimum amount of policy we do not want to 
> lose users data. And that will happen. 

This happens every day. People use "rm -r" in the wrong directory,
people accidentally pull the plug, people mess around with hdparm...
There are thousands of ways to lose data. You can't change that.
Echoing 5 into /proc/acpi/sleep is one of the *least* likely things.
We're discussing a problem that doesn't really exist.

> Let me repeat, and try and get you to listen: 
> 
> You *will* corrupt your data if you do not flush the disk buffers. 
> You *will* corrupt your data if you do not flush the disk buffers. 
> You *will* corrupt your data if you do not flush the disk buffers. 

So? I think I turned my box off a hundred times without flushing
the disk buffers while testing acpi, swsusp and cpufreq. These
things do happen when you mess around with beta kernel drivers.
One really annoying thing is that my box freezes when I push Fn+F8.
And this really happens by accident, because Fn+F7 turns the LCD
backlight off. 

> You are right, though, if they start writing random values into /proc, it 
> is their fault. But, the random range of numbers to be written to  
> /proc/acpi/sleep is small, and not that random. The documentation suggests 
> that some values work and others don't. It's human nature to exercise 
> curiosity and experiment with other close values. If they do, which they 
> are so likely to, I do not want to see them cause any harm to themselves. 

I do. Because, as you said, the doku suggest that *some don't work*.
So if they experiment out of curiosity, well then it's all their 
fault. Maybe the doku could be more explicit on this (and say that
S5 *does* work, but should normally not be used).

> This particular item is dangerous and will be removed from the kernel.

Is it up to you to decide that? ;-)


Jens

-- 
Jens Haug
IKFF Universität Stuttgart              Tel. 0711/685-6422
Pfaffenwaldring 9                       Fax  0711/685-6356
70550 Stuttgart	                haug-X6ztD3ggwzuBAmxm6OvjtTjhTm2NLCe8@public.gmane.org



-------------------------------------------------------
This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your  SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en

Re: System hang when trying to enter sleep/standby state

[Patrick Mochel]

> > This particular item is dangerous and will be removed from the kernel.
> 
> Is it up to you to decide that? ;-)

As a matter of fact, yes it is. And it has been removed from Linus's 2.5 
tree as of last night. 

Note that the argument is moot anwyay - there exists a sysrq key 
combination that calls pm_power_off() (which points to acpi_power_off()). 
This gives users the ability to turn their system off immediately, though 
removes it from procfs. 

	-pat



-------------------------------------------------------
This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your  SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en

Re: Sneaking patches in (was Re: System hang when trying to enter sleep/standby state)

[Patrick Mochel]

> Are we playing patch wars or what?

Not at all. The changes were discussed and sent to Andy, who had me 
forward them to Linus. The issue in question - disallowing the user from 
entering S5 directly from /proc/acpi/sleep was discussed on the list, and 
Andy agreed that it should be removed. 

> I have not seen any patch on the lists, *and*
> you also moved big blocks of code to hide your
> changes. That's pretty nasty behaviour.

That's not true. The patch to make that change is here: 

http://marc.theaimsgroup.com/?l=acpi4linux&m=104508487609853&w=2

And the accusation about moving large blocks of code to cover it up is 
completely unfair. It's not a conspiracy. 

It was also explained, along with every other change in the changelog
entries. I know that you are opposed to using BitKeeper, so I recommend 
that you subscribe to, or read, the bk-commits-head list, which has every 
patch Linus commits, with diffstat output and full changelogs for each. 

You can find info here: 

http://vger.kernel.org/vger-lists.html

and an archive here:

http://marc.theaimsgroup.com/?l=bk-commits-head&r=1&w=2

FYI, there is also a bk-commits-24 for 2.4 commits by Marcelo.

	-pat






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

Re: System hang when trying to enter sleep/standby state

[Christian Zoz]

On Fri, Feb 14, Patrick Mochel wrote:
> 
> > > This particular item is dangerous and will be removed from the kernel.
> > 
> > Is it up to you to decide that? ;-)
> 
> As a matter of fact, yes it is. And it has been removed from Linus's 2.5 
> tree as of last night. 

This is very very poor.

> Note that the argument is moot anwyay - there exists a sysrq key 
> combination that calls pm_power_off() (which points to acpi_power_off()). 
> This gives users the ability to turn their system off immediately, though 
> removes it from procfs. 

Switch it off!!! It's dangerous!

:(

-- 

ciao, christian

  --------------------------------------------------------------------
    Verglichen mit jedem x-beliebigen Redmonder Betriebssystem-Clone
    ist Linux geradezu eine leuchtende Perle der Datensicherheit.
  ------ Frank Rennemann (http://www.linux-knowledge-portal.org) -----


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

Re: Sneaking patches in (was Re: System hang when trying to enter sleep/standby state)

[Pavel Machek]

Hi!

> > I have not seen any patch on the lists, *and*
> > you also moved big blocks of code to hide your
> > changes. That's pretty nasty behaviour.
> 
> That's not true. The patch to make that change is here: 
> 
> http://marc.theaimsgroup.com/?l=acpi4linux&m=104508487609853&w=2
> 
> And the accusation about moving large blocks of code to cover it up is 
> completely unfair. It's not a conspiracy. 

While I agree it is not a conspiracy, the change is still well
hidden. Relevant changesets are:

ChangeSet 1.1003.12.2, 2003/02/13 11:51:15-06:00, mochel-3NddpPZAyC0@public.gmane.org

	acpi: Split i386 support up. 
	
	- Created arch/i386/kernel/acpi/
	- Split file into boot.c and sleep.c.
	- Moved acpi_wakeup.S into there.


ChangeSet 1.1003.2.19, 2003/02/12 19:35:58-06:00, mochel-3NddpPZAyC0@public.gmane.org

	acpi sleep: divorce sleep functionality from power off
functionality.
	
	When ACPI turns the system off on shutdown, it actually enters
S5, a sleep
	state. This functionality is dependent on CONFIG_ACPI_SLEEP,
which is 
	dependent on CONFIG_SOFTWARE_SUSPEND.
	
	This patch breaks the power off functionality into a separate
file, and 
	removes the dependency on the above-mentioned crap. Finally,
power off works
	for me again. 
	
	Thanks to Tobias Ringstrom for the original patch.


ChangeSet 1.1003.2.2, 2003/02/12 15:26:39-06:00, mochel-3NddpPZAyC0@public.gmane.org

	acpi sleep: move sleep support into own subdirectory. 

Even with the changelogs, I can't decide which one of these it
is. Probably 2.19, but as it also moves files, commit list is useless
because it represent moves as delete all lines, add all lines, and any
change is hidden.

@@ -285,16 +271,6 @@
 	printk(")\n");
 
 	acpi_sleep_proc_init();
-
-	/* Install the soft-off (S5) handler. */
-	if (sleep_states[ACPI_STATE_S5]) {
-		pm_power_off = acpi_power_off;
-
-		/* workaround: some systems don't claim S4 support,
but they
-                   do support S5 (power-down). That is all we need,
so
-		   indicate support. */
-		sleep_states[ACPI_STATE_S4] = 1;
-	}
 
 	return_VALUE(0);

Are you sure about this one?

> It was also explained, along with every other change in the changelog
> entries. I know that you are opposed to using BitKeeper, so I recommend 
> that you subscribe to, or read, the bk-commits-head list, which has every 
> patch Linus commits, with diffstat output and full changelogs for
> each. 

Well, in the past we tried to catch bugs *before* they got to the
tree.

								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

Sneaking patches in (was Re: System hang when trying to enter sleep/standby state)

[Pavel Machek]

Hi!

> > > This particular item is dangerous and will be removed from the kernel.
> > 
> > Is it up to you to decide that? ;-)
> 
> As a matter of fact, yes it is. And it has been removed from Linus's 2.5 
> tree as of last night. 

Are we playing patch wars or what?

I have not seen any patch on the lists, *and*
you also moved big blocks of code to hide your
changes. That's pretty nasty behaviour.

				Pavel



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

Re: Sneaking patches in (was Re: System hang when trying to enter sleep/standby state)

[Patrick Mochel]

On Mon, 17 Feb 2003, Pavel Machek wrote:

> Hi!
> 
> > > I have not seen any patch on the lists, *and*
> > > you also moved big blocks of code to hide your
> > > changes. That's pretty nasty behaviour.
> > 
> > That's not true. The patch to make that change is here: 
> > 
> > http://marc.theaimsgroup.com/?l=acpi4linux&m=104508487609853&w=2
> > 
> > And the accusation about moving large blocks of code to cover it up is 
> > completely unfair. It's not a conspiracy. 
> 
> While I agree it is not a conspiracy, the change is still well
> hidden. Relevant changesets are:

Actually, the relevant changeset is 

ChangeSet-6YnWl+pQIM5bgfau97FWYA@public.gmane.org, 2003-02-12 15:12:58-06:00, mochel@osdl.org
  sleep: fix /proc/acpi/sleep write handling.
  
  - Prevent users from screwing themselves by removing support for entering
    S5 from the proc file. S5 is 'soft-off' and the state the system enters
    when powering down. It needs to be preceded by a proper shutdown sequence
    and should not be triggered manually. 
  - Fix a potential unchecked array reference using the written value as the
    index.

The patch is 


diff -Nru a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
--- a/drivers/acpi/sleep.c      Mon Feb 17 10:18:20 2003
+++ b/drivers/acpi/sleep.c      Mon Feb 17 10:18:20 2003
@@ -318,14 +318,14 @@
        size_t                  count,
        loff_t                  *ppos)
 {
-       acpi_status             status = AE_OK;
+       acpi_status             status = AE_ERROR;
        char                    state_string[12] = {'\0'};
        u32                     state = 0;
 
        ACPI_FUNCTION_TRACE("acpi_system_write_sleep");
 
        if (count > sizeof(state_string) - 1)
-               return_VALUE(-EINVAL);
+               goto Done;
 
        if (copy_from_user(state_string, buffer, count))
                return_VALUE(-EFAULT);
@@ -333,22 +333,25 @@
        state_string[count] = '\0';
                                
        state = simple_strtoul(state_string, NULL, 0);
-                               
+                               
+       if (state < 1 || state > 4)
+               goto Done;
+
        if (!sleep_states[state])
                return_VALUE(-ENODEV);                                          
 
 #ifdef CONFIG_SOFTWARE_SUSPEND                                                 
        if (state == 4) {
                software_suspend();
-               return_VALUE(count);
+               goto Done;      
        }                       
 #endif                         
        status = acpi_suspend(state);
-                               
+ Done:                         
        if (ACPI_FAILURE(status))
-               return_VALUE(-ENODEV);
-       
-       return_VALUE(count);
+               return_VALUE(-EINVAL);
+       else
+               return_VALUE(count);
 }
 
 static int acpi_system_alarm_seq_show(struct seq_file *seq, void *offset)

(Careful, cut-n-pasted from an xterm)


> Even with the changelogs, I can't decide which one of these it
> is. Probably 2.19, but as it also moves files, commit list is useless
> because it represent moves as delete all lines, add all lines, and any
> change is hidden.

As a personal choice, I _never_ make changes when I move files. I've been 
so pissed at Andy for unintentionally obscuring changes this way that I 
swore I would never do it myself. :)

> -
> -	/* Install the soft-off (S5) handler. */
> -	if (sleep_states[ACPI_STATE_S5]) {
> -		pm_power_off = acpi_power_off;
> -
> -		/* workaround: some systems don't claim S4 support,
> but they
> -                   do support S5 (power-down). That is all we need,
> so
> -		   indicate support. */
> -		sleep_states[ACPI_STATE_S4] = 1;
> -	}
>  
>  	return_VALUE(0);
> 
> Are you sure about this one?

Definitely. The setting of pm_power_off was moved to poweroff.c. 

The other part is bogus. S5 is not a sleep state, and shouldn't be treated 
as such. You can still do a swsusp-style suspend and enter S5, in which 
case I wouldn't recommend going through ACPI at all. You simply don't need 
it. You need to save state, etc, then just call pm_power_off(). 

The only thing you lack is a way to trigger swsusp w/o ACPI, right? 


	-pat



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

Re: Sneaking patches in (was Re: System hang when trying to enter sleep/standby state)

[Pavel Machek]

Hi!

> > Even with the changelogs, I can't decide which one of these it
> > is. Probably 2.19, but as it also moves files, commit list is useless
> > because it represent moves as delete all lines, add all lines, and any
> > change is hidden.
> 
> As a personal choice, I _never_ make changes when I move files. I've been 
> so pissed at Andy for unintentionally obscuring changes this way that I 
> swore I would never do it myself. :)

Okay...

> > -
> > -	/* Install the soft-off (S5) handler. */
> > -	if (sleep_states[ACPI_STATE_S5]) {
> > -		pm_power_off = acpi_power_off;
> > -
> > -		/* workaround: some systems don't claim S4 support,
> > but they
> > -                   do support S5 (power-down). That is all we need,
> > so
> > -		   indicate support. */
> > -		sleep_states[ACPI_STATE_S4] = 1;
> > -	}
> >  
> >  	return_VALUE(0);
> > 
> > Are you sure about this one?
> 
> Definitely. The setting of pm_power_off was moved to poweroff.c. 
> 
> The other part is bogus. S5 is not a sleep state, and shouldn't be treated 
> as such. You can still do a swsusp-style suspend and enter S5, in which 
> case I wouldn't recommend going through ACPI at all. You simply don't need 
> it. You need to save state, etc, then just call pm_power_off(). 

Yes but I need S4 to be enabled, i.e. sleep_states[ACPI_STATE_S4] =
1;. OTOH it might be usefull to enable S4 even if S5 is not there, it
is usefull for old machines, too, user just has to turn it off
manually.

> The only thing you lack is a way to trigger swsusp w/o ACPI, right? 

Actually you can trigger swsusp using syscall, but few people do that.

								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]


-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge