RE: [ACPI] Re: [2.5.50, ACPI] link error

RE: [ACPI] Re: [2.5.50, ACPI] link error

[Grover, Andrew]

> From: Ducrot Bruno [mailto:poup@poupinou.org] 

> > I think that s4bios is nice to have. Its similar to S3 and easier to
> > set up than swsusp... It would be nice to have it.
> 
> for me:
> pros:
> -----
> 1- it is really really more easier to implement than S4;
> 2- we can even have it with 2.4 kernels (it seems that it work without
> the need of freezing processes, but I suspect that this statement
> is 'wrong' by nature).
> 
> cons:
> -----
> 1- it is much slower (especially at save time) than your swsusp;
> 2- end users must setup their systems (need to create a 
> suspend partition,
> or to keep a vfat partition as the really first one (/dev/hda1));
> 3- we use a bios function.  Actually, everything can happen...
> 
> That why I prefer swsusp at this time, or any other 
> implementation of S4 (I
> think about an implementation of S4 via LKCD).

I concur with your pros and cons. This makes me think that if S4BIOS support
ever gets added, it should get added to 2.4 only.

Regards -- Andy

RE: [ACPI] Re: [2.5.50, ACPI] link error

[Alan Cox]

On Mon, 2002-12-09 at 19:12, Grover, Andrew wrote:
> I concur with your pros and cons. This makes me think that if S4BIOS support
> ever gets added, it should get added to 2.4 only.

That assumes no box exists where S4bios works an S4 doesnt (eg due to
bad tables or "knowing" what other-os does)

Re: [ACPI] Re: [2.5.50, ACPI] link error

[Pavel Machek]

Hi!

> > I concur with your pros and cons. This makes me think that if S4BIOS support
> > ever gets added, it should get added to 2.4 only.

And S4BIOS will never get added to 2.4 since it needs driver model
:-(.

> That assumes no box exists where S4bios works an S4 doesnt (eg due to
> bad tables or "knowing" what other-os does)

We have full control over S4 (== swsusp), so we can fix that in most
cases.

S4BIOS is still little friendlier to the user -- no need to set up
swap partition and command line parameter, can't go wrong if you boot
without resume=, etc.
								Pavel

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

Re: [ACPI] Re: [2.5.50, ACPI] link error

[Andrew McGregor]

I strongly suspect that s4bios will work on this machine, but swsusp won't. 
Why?  It's a Dell Inspiron 8000 with an NVidia Geforce2go, and until NVidia 
put pm support in their driver, it's game over for Linux.  Except that the 
BIOS knows how to suspend it, so some kernel/driver combinations work with 
APM.  I suspect any Geforce2go Dell is the same.

Andrew

--On Tuesday, December 10, 2002 21:40:31 +0100 Pavel Machek <pavel@suse.cz> 
wrote:

> Hi!
>
>> > I concur with your pros and cons. This makes me think that if S4BIOS
>> > support ever gets added, it should get added to 2.4 only.
>
> And S4BIOS will never get added to 2.4 since it needs driver model
> :-(.
>
>> That assumes no box exists where S4bios works an S4 doesnt (eg due to
>> bad tables or "knowing" what other-os does)
>
> We have full control over S4 (== swsusp), so we can fix that in most
> cases.
>
> S4BIOS is still little friendlier to the user -- no need to set up
> swap partition and command line parameter, can't go wrong if you boot
> without resume=, etc.
> 								Pavel
>
> --
> Casualities in World Trade Center: ~3k dead inside the building,
> cryptography in U.S.A. and free speech in Czech Republic.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>

Re: [ACPI] Dell i8k was: Re: [2.5.50, ACPI] link error

[Andrew McGregor]

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

Hmm, when I boot 2.5.51 w/ACPI on it with a battery installed, it panics. 
By booting without and then inserting the battery, I got the attached oops. 
See also the messages in the dmesg output.

Andrew

--On Wednesday, December 11, 2002 09:50:48 +1300 Andrew McGregor 
<andrew@indranet.co.nz> wrote:

> I strongly suspect that s4bios will work on this machine, but swsusp
> won't. Why?  It's a Dell Inspiron 8000 with an NVidia Geforce2go, and
> until NVidia put pm support in their driver, it's game over for Linux.
> Except that the BIOS knows how to suspend it, so some kernel/driver
> combinations work with APM.  I suspect any Geforce2go Dell is the same.
>
> Andrew
>
> --On Tuesday, December 10, 2002 21:40:31 +0100 Pavel Machek
> <pavel@suse.cz> wrote:
>
>> Hi!
>>
>>> > I concur with your pros and cons. This makes me think that if S4BIOS
>>> > support ever gets added, it should get added to 2.4 only.
>>
>> And S4BIOS will never get added to 2.4 since it needs driver model
>> :-(.
>>
>>> That assumes no box exists where S4bios works an S4 doesnt (eg due to
>>> bad tables or "knowing" what other-os does)
>>
>> We have full control over S4 (== swsusp), so we can fix that in most
>> cases.
>>
>> S4BIOS is still little friendlier to the user -- no need to set up
>> swap partition and command line parameter, can't go wrong if you boot
>> without resume=, etc.
>> 								Pavel
>>
>> --
>> Casualities in World Trade Center: ~3k dead inside the building,
>> cryptography in U.S.A. and free speech in Czech Republic.
>> -
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
>> in the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
>>
>>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>


[-- Attachment #2: battery-2.5.51.oops --]
[-- Type: application/octet-stream, Size: 4987 bytes --]

ksymoops 2.4.5 on i686 2.5.51.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.5.51/ (default)
     -m /boot/System.map-2.5.51 (default)

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc.  ksymoops -h explains the options.

Error (regular_file): read_ksyms stat /proc/ksyms failed
No modules in ksyms, skipping objects
No ksyms, skipping lsmod
e100: selftest OK.
e100: eth0: Intel(R) 8255x-based Ethernet Adapter
 [<c013b6cd>] __alloc_pages+0x28d/0x2a0
 [<c013b702>] __get_free_pages+0x22/0x60
 [<c0120264>] dup_task_struct+0xb4/0x100
 [<c030e150>] stall_callback+0x0/0x1a0
 [<c01209c9>] copy_process+0x69/0x8f0
 [<c030e150>] stall_callback+0x0/0x1a0
 [<c0129e42>] __run_timers+0x82/0x160
 [<c012129d>] do_fork+0x4d/0x150
 [<c010a312>] kernel_thread+0x92/0xb0
 [<e08db650>] nodemgr_host_thread+0x0/0xb0 [ieee1394]
 [<c010a268>] kernel_thread_helper+0x0/0x18
 [<e08db964>] nodemgr_add_host+0x74/0xf0 [ieee1394]
 [<e08db650>] nodemgr_host_thread+0x0/0xb0 [ieee1394]
 [<e08d8418>] highlevel_add_host+0x38/0x70 [ieee1394]
 [<e08d7e95>] hpsb_add_host+0x45/0x70 [ieee1394]
 [<c0227efd>] pci_device_probe+0x5d/0x70
 [<c0262ce3>] bus_match+0x43/0x80
 [<c0262e01>] driver_attach+0x61/0x80
 [<c026313d>] bus_add_driver+0xad/0xd0
 [<c02635e1>] driver_register+0x31/0x40
 [<c022803d>] pci_register_driver+0x4d/0x60
 [<c0133809>] sys_init_module+0x1c9/0x1f0
 [<c010c3bf>] syscall_call+0x7/0xb
e100: eth0 NIC Link is Up 100 Mbps Full duplex
cs: IO port probe 0x0c00-0x0cff: clean.
cs: IO port probe 0x0100-0x04ff: excluding 0x170-0x177 0x370-0x37f 0x3c0-0x3df 0x4d0-0x4d7
cs: IO port probe 0x0a00-0x0aff: clean.
Unable to handle kernel NULL pointer dereference at virtual address 00000010
c022bab9
*pde = 00000000
Oops: 0002
CPU:    0
EIP:    0060:[<c022bab9>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010246
eax: 00000000   ebx: 00000000   ecx: dffe8ba0   edx: dee76ac0
esi: c170ec00   edi: c15e6900   ebp: dd9e9c9c   esp: dd9e9c70
ds: 0068   es: 0068   ss: 0068
Stack: c170ec00 00000001 00000000 00000000 00000000 00000000 00000000 00000001 
       dee76ac0 dfdc1be0 c15e21b4 dd9e9cb4 c022bc1b dee76ac0 dee76ac0 00000000 
       00000000 dd9e9cdc c0237629 dfdc1be0 c15e2000 00000060 00000000 00000000 
 [<c022bc1b>] acpi_ds_get_buffer_arguments+0x3b/0x50
 [<c0237629>] acpi_ex_resolve_node_to_value+0xc9/0x110
 [<c023275a>] acpi_ex_resolve_to_value+0x4a/0x70
 [<c022d73c>] acpi_ds_resolve_operands+0x2c/0x50
 [<c022c7bb>] acpi_ds_exec_end_op+0x13b/0x2e0
 [<c023d14a>] acpi_ps_parse_loop+0x61a/0xb60
 [<c022a8a0>] acpi_os_wait_semaphore+0xf0/0x120
 [<c022a8a0>] acpi_os_wait_semaphore+0xf0/0x120
 [<c0243f45>] acpi_ut_acquire_mutex+0x75/0xa0
 [<c0242c50>] acpi_ut_release_to_cache+0x40/0xd0
 [<c0243fe4>] acpi_ut_release_mutex+0x74/0xa0
 [<c022ea4e>] acpi_ds_delete_walk_state+0x4e/0xc0
 [<c023d89b>] acpi_ps_parse_aml+0x20b/0x220
 [<c022e997>] acpi_ds_init_aml_walk+0xc7/0x130
 [<c023e355>] acpi_psx_execute+0x205/0x250
 [<c023a7a4>] acpi_ns_execute_control_method+0x54/0x80
 [<c023a737>] acpi_ns_evaluate_by_handle+0xa7/0xc0
 [<c023a59b>] acpi_ns_evaluate_relative+0xdb/0x100
 [<c02453e8>] acpi_ut_remove_reference+0x38/0x40
 [<c0239bc1>] acpi_evaluate_object+0x81/0x220
 [<c0246d02>] acpi_battery_get_info+0x72/0x150
 [<c0247070>] acpi_battery_check+0xa0/0x120
 [<c024797d>] acpi_battery_notify+0x4d/0x70
 [<c022fad4>] acpi_ev_notify_dispatch+0x64/0x90
 [<c022a5e8>] acpi_os_queue_exec+0x58/0x70
 [<c022a590>] acpi_os_queue_exec+0x0/0x70
 [<c010a26d>] kernel_thread_helper+0x5/0x18
Code: 89 50 10 89 3c 24 e8 cc 21 01 00 c7 04 24 37 00 00 00 e8 00 


>>EIP; c022bab9 <acpi_ds_execute_arguments+c9/190>   <=====

>>ecx; dffe8ba0 <END_OF_CODE+1fa943e0/????>
>>edx; dee76ac0 <END_OF_CODE+1e922300/????>
>>esi; c170ec00 <END_OF_CODE+11ba440/????>
>>edi; c15e6900 <END_OF_CODE+1092140/????>
>>ebp; dd9e9c9c <END_OF_CODE+1d4954dc/????>
>>esp; dd9e9c70 <END_OF_CODE+1d4954b0/????>

Code;  c022bab9 <acpi_ds_execute_arguments+c9/190>
00000000 <_EIP>:
Code;  c022bab9 <acpi_ds_execute_arguments+c9/190>   <=====
   0:   89 50 10                  mov    %edx,0x10(%eax)   <=====
Code;  c022babc <acpi_ds_execute_arguments+cc/190>
   3:   89 3c 24                  mov    %edi,(%esp,1)
Code;  c022babf <acpi_ds_execute_arguments+cf/190>
   6:   e8 cc 21 01 00            call   121d7 <_EIP+0x121d7>
Code;  c022bac4 <acpi_ds_execute_arguments+d4/190>
   b:   c7 04 24 37 00 00 00      movl   $0x37,(%esp,1)
Code;  c022bacb <acpi_ds_execute_arguments+db/190>
  12:   e8 00 00 00 00            call   17 <_EIP+0x17>


1 warning and 1 error issued.  Results may not be reliable.

[-- Attachment #3: dmesg-2.5.51 --]
[-- Type: application/octet-stream, Size: 13658 bytes --]

Linux version 2.5.51 (andrewm@ijir) (gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)) #2 Wed Dec 11 15:37:35 NZDT 2002
Video mode to be used for restore is ffff
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 0000000000100000 - 000000001ffea800 (usable)
 BIOS-e820: 000000001ffea800 - 0000000020000000 (reserved)
 BIOS-e820: 00000000feea0000 - 00000000fef00000 (reserved)
 BIOS-e820: 00000000ffb80000 - 0000000100000000 (reserved)
511MB LOWMEM available.
ACPI: Wakeup code way too big, will crash on attempt to suspend
ACPI: have wakeup address 0xc0001000
On node 0 totalpages: 131050
  DMA zone: 4096 pages, LIFO batch:1
  Normal zone: 126954 pages, LIFO batch:16
  HighMem zone: 0 pages, LIFO batch:1
ACPI: RSDP (v000 DELL                       ) @ 0x000fde50
ACPI: RSDT (v001 DELL    CPi R   10193.02324) @ 0x000fde64
ACPI: FADT (v001 DELL    CPi R   10193.02324) @ 0x000fde90
ACPI: DSDT (v001 INT430 SYSFexxx 00000.04097) @ 0x00000000
ACPI: BIOS passes blacklist
Building zonelist for node : 0
Kernel command line: ro root=/dev/hda3 3
Initializing CPU#0
Detected 897.916 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 1777.66 BogoMIPS
Memory: 513788k/524200k available (2802k kernel code, 9620k reserved, 1195k data, 124k 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)
-> /dev
-> /dev/console
-> /root
CPU: Before vendor init, caps: 0383f9ff 00000000 00000000, vendor = 0
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
CPU: After vendor init, caps: 0383f9ff 00000000 00000000 00000000
CPU:     After generic, caps: 0383f9ff 00000000 00000000 00000000
CPU:             Common caps: 0383f9ff 00000000 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: Intel Pentium III (Coppermine) stepping 06
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
mtrr: v2.0 (20020519)
device class 'cpu': registering
device class cpu: adding driver system:cpu
PCI: PCI BIOS revision 2.10 entry at 0xfc06e, last bus=8
PCI: Using configuration type 1
device class cpu: adding device CPU 0
interfaces: adding device CPU 0
BIO: pool of 256 setup, 14Kb (56 bytes/bio)
biovec pool[0]:   1 bvecs: 256 entries (12 bytes)
biovec pool[1]:   4 bvecs: 256 entries (48 bytes)
biovec pool[2]:  16 bvecs: 256 entries (192 bytes)
biovec pool[3]:  64 bvecs: 256 entries (768 bytes)
biovec pool[4]: 128 bvecs: 256 entries (1536 bytes)
biovec pool[5]: 256 bvecs: 256 entries (3072 bytes)
ACPI: Subsystem revision 20021205
..........................................................................................................................................................    ACPI-0263: *** Info: GPE Block0 defined as GPE0 to GPE15
    ACPI-0263: *** Info: GPE Block1 defined as GPE16 to GPE31
...................................................................................................<6>ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: (supports S0 S1 S3 S4 S5)
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
Transparent bridge - Intel Corp. 82801BAM/CAM PCI Bri
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 *5 6 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 11 12 14 15, disabled)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGP_._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCIE._PRT]
ACPI: Power Resource [PADA] (on)
Linux Plug and Play Support v0.93 (c) Adam Belay
block request queues:
 128 requests per read queue
 128 requests per write queue
 8 requests per batch
 enter congestion at 31
 exit congestion at 33
SCSI subsystem driver Revision: 1.00
device class 'scsi-host': registering
drivers/usb/core/usb.c: registered new driver usbfs
drivers/usb/core/usb.c: registered new driver hub
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 10
PCI: Using ACPI for IRQ routing
PCI: if you experience problems, try using option 'pci=noacpi' or even 'acpi=off'
Total HugeTLB memory allocated, 0
aio_setup: sizeof(struct page) = 40
[c151c040] eventpoll: successfully initialized.
Journalled Block Device driver loaded
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
udf: registering filesystem
Initializing Cryptographic API
ACPI: AC Adapter [AC] (on-line)
ACPI: Battery Slot [BAT0] (battery absent)
ACPI: Battery Slot [BAT1] (battery absent)
ACPI: Lid Switch [LID]
ACPI: Power Button (CM) [PBTN]
ACPI: Sleep Button (CM) [SBTN]
ACPI: Processor [CPU0] (supports C1 C2)
ACPI: Thermal Zone [THM] (25 C)
Serial: 8250/16550 driver $Revision: 1.90 $ IRQ sharing disabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE]
parport0: irq 7 detected
parport0: cpp_daisy: aa5500ff(38)
parport0: assign_addrs: aa5500ff(38)
parport0: cpp_daisy: aa5500ff(38)
parport0: assign_addrs: aa5500ff(38)
pty: 256 Unix98 ptys configured
Dell laptop SMM driver v1.7 21/11/2001 Massimo Dal Zotto (dz@debian.org)
lp0: using parport0 (polling).
i810_rng: RNG not detected
Linux agpgart interface v1.0 (c) Dave Jones
agpgart: agpgart: Detected an Intel i815, but could not find the secondary device. Assuming a non-integrated video card.
agpgart: Detected Intel i815 chipset
agpgart: Maximum main memory to use for agp memory: 439M
agpgart: AGP aperture is 64M @ 0xe8000000
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
Intel(R) PRO/100 Network Driver - version 2.1.24-k2
Copyright (c) 2002 Intel Corporation

e100: selftest OK.
Freeing alive device dfd5e800, eth%d
e100: eth0: Intel(R) 8255x-based Ethernet Adapter
  Mem:0xf8fff000  IRQ:11  Speed:0 Mbps  Dx:N/A
  Hardware receive checksums enabled
  cpu cycle saver enabled

Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH2M: IDE controller at PCI slot 00:1f.1
ICH2M: chipset revision 3
ICH2M: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0xbfa0-0xbfa7, BIOS settings: hda:DMA, hdb:DMA
    ide1: BM-DMA at 0xbfa8-0xbfaf, BIOS settings: hdc:pio, hdd:pio
hda: IBM-DJSA-232, ATA DISK drive
hdb: TOSHIBA DVD-ROM SD-C2502, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: host protected area => 1
hda: 62506080 sectors (32003 MB) w/1874KiB Cache, CHS=62010/16/63, UDMA(66)
 hda: hda1 hda2 hda3 hda4 < hda5 >
hdb: ATAPI 24X DVD-ROM drive, 128kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.12
scsi HBA driver <NULL> didn't set max_sectors, please fix the template<4>scsi HBA driver Qlogic ISP 1280/12160 didn't set max_sectors, please fix the template<3>request_module[scsi_hostadapter]: not ready
request_module[scsi_hostadapter]: not ready
request_module[scsi_hostadapter]: not ready
Linux Kernel Card Services 3.1.22
  options:  [pci] [cardbus] [pm]
PCI: Enabling device 02:0f.0 (0000 -> 0002)
PCI: Enabling device 02:0f.1 (0000 -> 0002)
drivers/usb/host/uhci-hcd.c: USB Universal Host Controller Interface driver v2.0
PCI: Setting latency timer of device 00:1f.2 to 64
uhci-hcd 00:1f.2: Intel Corp. 82801BA/BAM USB (Hub
uhci-hcd 00:1f.2: irq 11, io base 0000bce0
drivers/usb/core/hcd.c: new USB bus registered, assigned bus number 1
Yenta IRQ list 0098, PCI irq11
Socket status: 30000006
Yenta IRQ list 0098, PCI irq11
Socket status: 30000006
drivers/usb/core/hub.c: USB hub found at 0
drivers/usb/core/hub.c: 2 ports detected
Initializing USB Mass Storage driver...
drivers/usb/core/usb.c: registered new driver usb-storage
USB Mass Storage support registered.
drivers/usb/core/usb.c: registered new driver usbscanner
drivers/usb/image/scanner.c: 0.4.6:USB Scanner Driver
drivers/usb/core/usb.c: registered new driver serial
drivers/usb/serial/usb-serial.c: USB Serial Driver core v1.8
device class 'input': registering
register interface 'mouse' with class 'input'
mice: PS/2 mouse device common for all mice
input: PS/2 Synaptics TouchPad on isa0060/serio1
serio: i8042 AUX port at 0x60,0x64 irq 12
input: AT Set 2 keyboard on isa0060/serio0
serio: i8042 KBD port at 0x60,0x64 irq 1
Advanced Linux Sound Architecture Driver Version 0.9.0rc5 (Sun Nov 10 19:48:18 2002 UTC).
request_module[snd-card-0]: not ready
request_module[snd-card-1]: not ready
request_module[snd-card-2]: not ready
request_module[snd-card-3]: not ready
request_module[snd-card-4]: not ready
request_module[snd-card-5]: not ready
request_module[snd-card-6]: not ready
request_module[snd-card-7]: not ready
ALSA device list:
  No soundcards found.
NET4: Linux TCP/IP 1.0 for NET4.0
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.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 124k freed
drivers/usb/core/usb.c: registered new driver hiddev
drivers/usb/core/usb.c: registered new driver hid
drivers/usb/input/hid-core.c: v2.0:USB HID core driver
EXT3 FS 2.4-0.9.16, 02 Dec 2001 on ide0(3,3), internal journal
Adding 1044184k swap on /dev/hda5.  Priority:-1 extents:1
kjournald starting.  Commit interval 5 seconds
EXT3 FS 2.4-0.9.16, 02 Dec 2001 on ide0(3,2), internal journal
EXT3-fs: mounted filesystem with ordered data mode.
blk: queue c0544afc, I/O limit 4095Mb (mask 0xffffffff)
ohci1394: $Rev: 601 $ Ben Collins <bcollins@debian.org>
ohci1394_0: OHCI-1394 1.0 (PCI): IRQ=[11]  MMIO=[f6ffd800-f6ffdfff]  Max Packet=[2048]
Debug: sleeping function called from illegal context at mm/page_alloc.c:450
Call Trace:
 [<c013b6cd>] __alloc_pages+0x28d/0x2a0
 [<c013b702>] __get_free_pages+0x22/0x60
 [<c0120264>] dup_task_struct+0xb4/0x100
 [<c030e150>] stall_callback+0x0/0x1a0
 [<c01209c9>] copy_process+0x69/0x8f0
 [<c030e150>] stall_callback+0x0/0x1a0
 [<c0129e42>] __run_timers+0x82/0x160
 [<c012129d>] do_fork+0x4d/0x150
 [<c010a312>] kernel_thread+0x92/0xb0
 [<e08db650>] nodemgr_host_thread+0x0/0xb0 [ieee1394]
 [<c010a268>] kernel_thread_helper+0x0/0x18
 [<e08db964>] nodemgr_add_host+0x74/0xf0 [ieee1394]
 [<e08db650>] nodemgr_host_thread+0x0/0xb0 [ieee1394]
 [<e08d8418>] highlevel_add_host+0x38/0x70 [ieee1394]
 [<e08d7e95>] hpsb_add_host+0x45/0x70 [ieee1394]
 [<c0227efd>] pci_device_probe+0x5d/0x70
 [<c0262ce3>] bus_match+0x43/0x80
 [<c0262e01>] driver_attach+0x61/0x80
 [<c026313d>] bus_add_driver+0xad/0xd0
 [<c02635e1>] driver_register+0x31/0x40
 [<c022803d>] pci_register_driver+0x4d/0x60
 [<c0133809>] sys_init_module+0x1c9/0x1f0
 [<c010c3bf>] syscall_call+0x7/0xb

ieee1394: Host added: Node[00:1023]  GUID[4a4fc000379e0c38]  [Linux OHCI-1394]
e100: eth0 NIC Link is Up 100 Mbps Full duplex
cs: IO port probe 0x0c00-0x0cff: clean.
cs: IO port probe 0x0100-0x04ff: excluding 0x170-0x177 0x370-0x37f 0x3c0-0x3df 0x4d0-0x4d7
cs: IO port probe 0x0a00-0x0aff: clean.
    ACPI-0189: *** Warning: Buffer created with zero length in AML
Unable to handle kernel NULL pointer dereference at virtual address 00000010
 printing eip:
c022bab9
*pde = 00000000
Oops: 0002
CPU:    0
EIP:    0060:[<c022bab9>]    Not tainted
EFLAGS: 00010246
EIP is at acpi_ds_execute_arguments+0xc9/0x190
eax: 00000000   ebx: 00000000   ecx: dffe8ba0   edx: dee76ac0
esi: c170ec00   edi: c15e6900   ebp: dd9e9c9c   esp: dd9e9c70
ds: 0068   es: 0068   ss: 0068
Process kacpidpc (pid: 910, threadinfo=dd9e8000 task=c171f280)
Stack: c170ec00 00000001 00000000 00000000 00000000 00000000 00000000 00000001 
       dee76ac0 dfdc1be0 c15e21b4 dd9e9cb4 c022bc1b dee76ac0 dee76ac0 00000000 
       00000000 dd9e9cdc c0237629 dfdc1be0 c15e2000 00000060 00000000 00000000 
Call Trace:
 [<c022bc1b>] acpi_ds_get_buffer_arguments+0x3b/0x50
 [<c0237629>] acpi_ex_resolve_node_to_value+0xc9/0x110
 [<c023275a>] acpi_ex_resolve_to_value+0x4a/0x70
 [<c022d73c>] acpi_ds_resolve_operands+0x2c/0x50
 [<c022c7bb>] acpi_ds_exec_end_op+0x13b/0x2e0
 [<c023d14a>] acpi_ps_parse_loop+0x61a/0xb60
 [<c022a8a0>] acpi_os_wait_semaphore+0xf0/0x120
 [<c022a8a0>] acpi_os_wait_semaphore+0xf0/0x120
 [<c0243f45>] acpi_ut_acquire_mutex+0x75/0xa0
 [<c0242c50>] acpi_ut_release_to_cache+0x40/0xd0
 [<c0243fe4>] acpi_ut_release_mutex+0x74/0xa0
 [<c022ea4e>] acpi_ds_delete_walk_state+0x4e/0xc0
 [<c023d89b>] acpi_ps_parse_aml+0x20b/0x220
 [<c022e997>] acpi_ds_init_aml_walk+0xc7/0x130
 [<c023e355>] acpi_psx_execute+0x205/0x250
 [<c023a7a4>] acpi_ns_execute_control_method+0x54/0x80
 [<c023a737>] acpi_ns_evaluate_by_handle+0xa7/0xc0
 [<c023a59b>] acpi_ns_evaluate_relative+0xdb/0x100
 [<c02453e8>] acpi_ut_remove_reference+0x38/0x40
 [<c0239bc1>] acpi_evaluate_object+0x81/0x220
 [<c0246d02>] acpi_battery_get_info+0x72/0x150
 [<c0247070>] acpi_battery_check+0xa0/0x120
 [<c024797d>] acpi_battery_notify+0x4d/0x70
 [<c022fad4>] acpi_ev_notify_dispatch+0x64/0x90
 [<c022a5e8>] acpi_os_queue_exec+0x58/0x70
 [<c022a590>] acpi_os_queue_exec+0x0/0x70
 [<c010a26d>] kernel_thread_helper+0x5/0x18

Code: 89 50 10 89 3c 24 e8 cc 21 01 00 c7 04 24 37 00 00 00 e8 00 
 

Re: [ACPI] Re: [2.5.50, ACPI] link error

[Ducrot Bruno]

On Wed, Dec 11, 2002 at 09:50:48AM +1300, Andrew McGregor wrote:
> I strongly suspect that s4bios will work on this machine, but swsusp won't. 
> Why?  It's a Dell Inspiron 8000 with an NVidia Geforce2go, and until NVidia 
> put pm support in their driver, it's game over for Linux.  Except that the 
> BIOS knows how to suspend it, so some kernel/driver combinations work with 
> APM.  I suspect any Geforce2go Dell is the same.

No.  You are wrong.  I need to suspend allmost all the drivers, and the
video chipset is not an execption (or go to a console before suspending,
in fact).
You still need to bug NVIDIA in order to have proper pm support
in their driver.

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

Re: [ACPI] Re: [2.5.50, ACPI] link error

[Alan Cox]

On Wed, 2002-12-11 at 10:14, Ducrot Bruno wrote:
> No.  You are wrong.  I need to suspend allmost all the drivers, and the
> video chipset is not an execption (or go to a console before suspending,
> in fact).
> You still need to bug NVIDIA in order to have proper pm support
> in their driver.

To an extent. However you can also switch back to text mode on suspend
to disk, then resume back into text mode and effectively switch back
into X11

Re: [ACPI] Re: [2.5.50, ACPI] link error

[Ducrot Bruno]

On Tue, Dec 10, 2002 at 09:40:31PM +0100, Pavel Machek wrote:
> Hi!
> 
> > > I concur with your pros and cons. This makes me think that if S4BIOS support
> > > ever gets added, it should get added to 2.4 only.
> 
> And S4BIOS will never get added to 2.4 since it needs driver model
> :-(.

Well, it worked for me with 2.4 with 'basic' pm_send_xxx

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

Re: [2.5.50, ACPI] link error

[Pavel Machek]

Hi!

> >>>Yes, there are about 10 patches to fix it floating around... I just
> >>>hope linus takes one of them. (Fix is make ACPI_SLEEP depend on
> >>>swsusp).
> >>
> >>
> >>I haven't seen the patch, but does it make sense for hardware suspend to 
> >>depend on software suspend?
> >>
> >>IMO there should be a common core (CONFIG_SUSPEND?), not force ACPI to 
> >>depend on swsusp.  That way you get the _least_ common denominator, not 
> >>the union of two sets.
> >
> >
> >Feel free to fix that, but as swsusp is needed for S4, anyway, I do not
> >see big need to do that.
> 
> 
> Why should I fix your fix?
> 
> Doesn't that imply your fix is broken to begin with?

ACPI/S4 support needs swsusp. ACPI/S3 needs big part of
swsusp. Splitting CONFIG_ACPI_SLEEP to S3 and S4 part seems like
overdesign to me, OTOH if you do the work it is okay with me.

								Pavel

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

Re: [2.5.50, ACPI] link error

[Patrick Mochel]

> > Doesn't that imply your fix is broken to begin with?
> 
> ACPI/S4 support needs swsusp. ACPI/S3 needs big part of
> swsusp. Splitting CONFIG_ACPI_SLEEP to S3 and S4 part seems like
> overdesign to me, OTOH if you do the work it is okay with me.

You broke the design. S3 support was developed long before swsusp was in 
the kernel, and completely indpendent of it. It should have remained that 
way. 

S3 support is a subset of what is need for S4 support. 

swsusp is an implementation of S4 support. In theory, there could be 
multiple implementations that all use the same core (saving/restoring 
state). 

There could also be different power management schemes that use swsusp as 
an implementation for suspend-to-disk. But, that's another tangent. 

CONFIG_ACPI_SLEEP should give you S3 support, and the ACPI side of S4 
support. The comment in the config option should tell the user that they 
must choose a suspend implementation (e.g. CONFIG_SUSPEND, which should 
prolly be CONFIG_SWAP_SUSPEND) in order to get complete S4 support. (The 
ACPI side can make an empty call to swsusp if no implementation is 
selected). 


Some time ago, I made a BK repo for suspend support. I axed it, since no 
one ever used it. But, it's back again, and I'll be integrating your 
patches and try to dedicate a few extra cycles to resolving some of the 
issues. I'll send an announcement to the list once I've integrated your 
patches. 

	-pat

Re: [2.5.50, ACPI] link error

[Pavel Machek]

Hi!

> > > Doesn't that imply your fix is broken to begin with?
> > 
> > ACPI/S4 support needs swsusp. ACPI/S3 needs big part of
> > swsusp. Splitting CONFIG_ACPI_SLEEP to S3 and S4 part seems like
> > overdesign to me, OTOH if you do the work it is okay with me.
> 
> You broke the design. S3 support was developed long before swsusp was in 
> the kernel, and completely indpendent of it. It should have remained that 
> way. 
> 
> S3 support is a subset of what is need for S4 support. 

That's not true. acpi_wakeup.S is nasty piece of code, needed for S3
but not for S4. Big part of driver support is only needed for S3.

> swsusp is an implementation of S4 support. In theory, there could be 
> multiple implementations that all use the same core (saving/restoring 
> state). 

There were patches for S4bios floating around, but it never really
worked, IIRC.

> There could also be different power management schemes that use swsusp as 
> an implementation for suspend-to-disk. But, that's another tangent. 
> 
> CONFIG_ACPI_SLEEP should give you S3 support, and the ACPI side of S4 
> support. 

What's ACPI side of S4 good for when you can not do S4?

> The comment in the config option should tell the user that they 
> must choose a suspend implementation (e.g. CONFIG_SUSPEND, which should 
> prolly be CONFIG_SWAP_SUSPEND) in order to get complete S4 support. (The 
> ACPI side can make an empty call to swsusp if no implementation is 
> selected). 

S3 needs process stopper from kernel/suspend.c. I did not want to have
#ifdefs all over suspend.c...

> Some time ago, I made a BK repo for suspend support. I axed it, since no 
> one ever used it. But, it's back again, and I'll be integrating your 
> patches and try to dedicate a few extra cycles to resolving some of the 
> issues. I'll send an announcement to the list once I've integrated your 
> patches. 

I probably will not persuade you to make it CVS, right? [Sorry, I'm
not going to touch bitkeeper.]
								Pavel
-- 
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.

Re: [ACPI] Re: [2.5.50, ACPI] link error

[Ducrot Bruno]

On Fri, Dec 06, 2002 at 01:06:18AM +0100, Pavel Machek wrote:
> Hi!
> 
> > > > Doesn't that imply your fix is broken to begin with?
> > > 
> > > ACPI/S4 support needs swsusp. ACPI/S3 needs big part of
> > > swsusp. Splitting CONFIG_ACPI_SLEEP to S3 and S4 part seems like
> > > overdesign to me, OTOH if you do the work it is okay with me.
> > 
> > You broke the design. S3 support was developed long before swsusp was in 
> > the kernel, and completely indpendent of it. It should have remained that 
> > way. 
> > 
> > S3 support is a subset of what is need for S4 support. 
> 
> That's not true. acpi_wakeup.S is nasty piece of code, needed for S3
> but not for S4. Big part of driver support is only needed for S3.
> 
> > swsusp is an implementation of S4 support. In theory, there could be 
> > multiple implementations that all use the same core (saving/restoring 
> > state). 
> 
> There were patches for S4bios floating around, but it never really
> worked, IIRC.

No.  It work.  I do not resubmmited patches because I think that
swsusp is better.

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

Re: [ACPI] Re: [2.5.50, ACPI] link error

[Ducrot Bruno]

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

Hi, Pavel.

On Fri, Dec 06, 2002 at 07:57:02PM +0100, Ducrot Bruno wrote:
> On Fri, Dec 06, 2002 at 01:06:18AM +0100, Pavel Machek wrote:
> > Hi!
> > 
> > > > > Doesn't that imply your fix is broken to begin with?
> > > > 
> > > > ACPI/S4 support needs swsusp. ACPI/S3 needs big part of
> > > > swsusp. Splitting CONFIG_ACPI_SLEEP to S3 and S4 part seems like
> > > > overdesign to me, OTOH if you do the work it is okay with me.
> > > 
> > > You broke the design. S3 support was developed long before swsusp was in 
> > > the kernel, and completely indpendent of it. It should have remained that 
> > > way. 
> > > 
> > > S3 support is a subset of what is need for S4 support. 
> > 
> > That's not true. acpi_wakeup.S is nasty piece of code, needed for S3
> > but not for S4. Big part of driver support is only needed for S3.
> > 
> > > swsusp is an implementation of S4 support. In theory, there could be 
> > > multiple implementations that all use the same core (saving/restoring 
> > > state). 
> > 
> > There were patches for S4bios floating around, but it never really
> > worked, IIRC.
> 
> No.  It work.  I do not resubmmited patches because I think that
> swsusp is better.
> 

I attach also this patch, it is ughly, though, but if you are sure
that your laptop can support S4BIOS (I do not include basic checks for
that), it should survive (I need myself to reset at wakeup the keyboard controller,
though).

It is again acpi on sf.net of today, and some of your patches for S3 support.

echo 4b > /proc/acpi/sleep if you want to say goodbye to your data :)

Cheers,

-- 
Ducrot Bruno
http://www.poupinou.org        Page profaissionelle
http://toto.tu-me-saoules.com  Haume page

[-- Attachment #2: s4bios-2.5.50.diff --]
[-- Type: text/plain, Size: 5017 bytes --]

--- linux-2.5.50/arch/i386/kernel/acpi_wakeup.S	2002/12/06 21:34:17	1.1
+++ linux-2.5.50/arch/i386/kernel/acpi_wakeup.S	2002/12/06 21:48:14
@@ -336,6 +336,48 @@
 	pushl saved_context_eflags ; popfl
 	ret
 
+ENTRY(do_suspend_lowlevel_s4bios)
+	cmpl $0,4(%esp)
+	jne .L1432
+	call save_processor_state
+
+	movl %esp, saved_context_esp
+	movl %eax, saved_context_eax
+	movl %ebx, saved_context_ebx
+	movl %ecx, saved_context_ecx
+	movl %edx, saved_context_edx
+	movl %ebp, saved_context_ebp
+	movl %esi, saved_context_esi
+	movl %edi, saved_context_edi
+	pushfl ; popl saved_context_eflags
+
+	movl $.L1432,saved_eip
+	movl %esp,saved_esp
+	movl %ebp,saved_ebp
+	movl %ebx,saved_ebx
+	movl %edi,saved_edi
+	movl %esi,saved_esi
+
+	pushl $3
+	call acpi_enter_sleep_state_s4bios
+	addl $4,%esp
+	ret
+	.p2align 4,,7
+.L1433:
+	movl $__KERNEL_DS,%eax
+	movw %ax, %ds
+	movl saved_context_esp, %esp
+	movl saved_context_ebp, %ebp
+	movl saved_context_eax, %eax
+	movl saved_context_ebx, %ebx
+	movl saved_context_ecx, %ecx
+	movl saved_context_edx, %edx
+	movl saved_context_esi, %esi
+	movl saved_context_edi, %edi
+	call restore_processor_state
+	pushl saved_context_eflags ; popfl
+	ret
+
 ALIGN
 # saved registers
 saved_gdt:	.long	0,0
--- linux-2.5.50/drivers/acpi/include/acpixf.h	2002/12/06 21:56:49	1.1
+++ linux-2.5.50/drivers/acpi/include/acpixf.h	2002/12/06 22:02:42
@@ -380,6 +380,10 @@
 	u8                      sleep_state);
 
 acpi_status
+acpi_enter_sleep_state_s4bios (
+	void);
+
+acpi_status
 acpi_leave_sleep_state (
 	u8                      sleep_state);
 
--- linux-2.5.50/drivers/acpi/hardware/hwsleep.c	2002/12/06 21:39:07	1.1
+++ linux-2.5.50/drivers/acpi/hardware/hwsleep.c	2002/12/06 22:08:22
@@ -319,6 +319,51 @@
 
 /******************************************************************************
  *
+ * FUNCTION:    Acpi_enter_sleep_state_s4bios
+ *
+ * PARAMETERS:  None
+ *
+ * RETURN:      Status
+ *
+ * DESCRIPTION: Perform a s4 bios request.
+ *              THIS FUNCTION MUST BE CALLED WITH INTERRUPTS DISABLED
+ *
+ ******************************************************************************/
+
+acpi_status
+acpi_enter_sleep_state_s4bios (void)
+{
+	u32                     in_value;
+	acpi_status             status;
+
+
+	ACPI_FUNCTION_TRACE ("Acpi_enter_sleep_state_s4bios");
+
+
+	acpi_set_register (ACPI_BITREG_WAKE_STATUS, 1, ACPI_MTX_LOCK);
+	acpi_hw_clear_acpi_status();
+
+	acpi_hw_disable_non_wakeup_gpes();
+
+	ACPI_FLUSH_CPU_CACHE();
+
+	acpi_os_stall (10000);
+
+	status = acpi_os_write_port (acpi_gbl_FADT->smi_cmd, (acpi_integer) acpi_gbl_FADT->S4bios_req, 8);
+
+	do {
+		status = acpi_get_register (ACPI_BITREG_WAKE_STATUS, &in_value, ACPI_MTX_LOCK);
+		if (ACPI_FAILURE (status)) {
+			return_ACPI_STATUS (status);
+		}
+	} while (!in_value);
+
+	return_ACPI_STATUS (AE_OK);
+}
+
+
+/******************************************************************************
+ *
  * FUNCTION:    Acpi_leave_sleep_state
  *
  * PARAMETERS:  Sleep_state         - Which sleep state we just exited
--- linux-2.5.50/drivers/acpi/sleep.c	2002/12/06 21:21:25	1.1
+++ linux-2.5.50/drivers/acpi/sleep.c	2002/12/06 22:29:28
@@ -149,8 +149,10 @@
 		if (state > ACPI_STATE_S1) {
 			error = acpi_save_state_mem();
 
+#if 0
 			if (!error && (state == ACPI_STATE_S4))
 				error = acpi_save_state_disk();
+#endif
 
 			if (error) {
 				device_resume(RESUME_RESTORE_STATE);
@@ -227,6 +229,8 @@
 	case ACPI_STATE_S3:
 		do_suspend_lowlevel(0);
 #endif
+	case ACPI_STATE_S4:
+		do_suspend_lowlevel_s4bios(0);
 		break;
 	}
 	local_irq_restore(flags);
@@ -253,7 +257,7 @@
 	freeze_processes();		/* device_suspend needs processes to be stopped */
 
 	/* do we have a wakeup address for S2 and S3? */
-	if (state == ACPI_STATE_S2 || state == ACPI_STATE_S3) {
+	if (state == ACPI_STATE_S2 || state == ACPI_STATE_S3 || state == ACPI_STATE_S4) {
 		if (!acpi_wakeup_address)
 			return AE_ERROR;
 		acpi_set_firmware_waking_vector((ACPI_PHYSICAL_ADDRESS) acpi_wakeup_address);
@@ -336,12 +340,14 @@
 	if (!sleep_states[state])
 		return_VALUE(-ENODEV);
 
+	if (state == 4 && state_string[1] != 'b') {
 #ifdef CONFIG_SOFTWARE_SUSPEND
-	if (state == 4) {
+	/* if (state == 4) { */
 		software_suspend();
 		return_VALUE(count);
-	}
+	/* } */
 #endif
+	}
 	status = acpi_suspend(state);
 
 	if (ACPI_FAILURE(status))
--- linux-2.5.50/drivers/acpi/acpi_ksyms.c	2002/12/06 21:58:48	1.1
+++ linux-2.5.50/drivers/acpi/acpi_ksyms.c	2002/12/06 21:59:12
@@ -86,6 +86,7 @@
 EXPORT_SYMBOL(acpi_get_register);
 EXPORT_SYMBOL(acpi_set_register);
 EXPORT_SYMBOL(acpi_enter_sleep_state);
+EXPORT_SYMBOL(acpi_enter_sleep_state_s4bios);
 EXPORT_SYMBOL(acpi_get_system_info);
 EXPORT_SYMBOL(acpi_get_devices);
 
--- linux-2.5.50/include/linux/suspend.h	2002/12/06 21:53:17	1.1
+++ linux-2.5.50/include/linux/suspend.h	2002/12/06 21:54:27
@@ -71,6 +71,8 @@
 
 extern void do_suspend_lowlevel(int resume);
 
+extern void do_suspend_lowlevel_s4bios(int resume);
+
 #else
 static inline void software_suspend(void)
 {

Re: [ACPI] Re: [2.5.50, ACPI] link error

[Pavel Machek]

Hi!

> > > > > Doesn't that imply your fix is broken to begin with?
> > > > 
> > > > ACPI/S4 support needs swsusp. ACPI/S3 needs big part of
> > > > swsusp. Splitting CONFIG_ACPI_SLEEP to S3 and S4 part seems like
> > > > overdesign to me, OTOH if you do the work it is okay with me.
> > > 
> > > You broke the design. S3 support was developed long before swsusp was in 
> > > the kernel, and completely indpendent of it. It should have remained that 
> > > way. 
> > > 
> > > S3 support is a subset of what is need for S4 support. 
> > 
> > That's not true. acpi_wakeup.S is nasty piece of code, needed for S3
> > but not for S4. Big part of driver support is only needed for S3.
> > 
> > > swsusp is an implementation of S4 support. In theory, there could be 
> > > multiple implementations that all use the same core (saving/restoring 
> > > state). 
> > 
> > There were patches for S4bios floating around, but it never really
> > worked, IIRC.
> 
> No.  It work.  I do not resubmmited patches because I think that
> swsusp is better.

I think that s4bios is nice to have. Its similar to S3 and easier to
set up than swsusp... It would be nice to have it.
								Pavel
-- 
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.

Re: [ACPI] Re: [2.5.50, ACPI] link error

[Constantinos Antoniou]

On Sun, 2002-12-08 at 14:49, Pavel Machek wrote:
> Hi!
> 
> > > > > > Doesn't that imply your fix is broken to begin with?
> > > > > 
> > > > > ACPI/S4 support needs swsusp. ACPI/S3 needs big part of
> > > > > swsusp. Splitting CONFIG_ACPI_SLEEP to S3 and S4 part seems like
> > > > > overdesign to me, OTOH if you do the work it is okay with me.
> > > > 
> > > > You broke the design. S3 support was developed long before swsusp was in 
> > > > the kernel, and completely indpendent of it. It should have remained that 
> > > > way. 
> > > > 
> > > > S3 support is a subset of what is need for S4 support. 
> > > 
> > > That's not true. acpi_wakeup.S is nasty piece of code, needed for S3
> > > but not for S4. Big part of driver support is only needed for S3.
> > > 
> > > > swsusp is an implementation of S4 support. In theory, there could be 
> > > > multiple implementations that all use the same core (saving/restoring 
> > > > state). 
> > > 
> > > There were patches for S4bios floating around, but it never really
> > > worked, IIRC.
> > 
> > No.  It work.  I do not resubmmited patches because I think that
> > swsusp is better.
> 
> I think that s4bios is nice to have. Its similar to S3 and easier to
> set up than swsusp... It would be nice to have it.

(I do not know much, but) another reason may be that some laptops do not
support S3, while they support S4? for example, in my Compaq Presario
1700T:

$ more /proc/acpi/info
ACPI-CA Version:         20011018
Sx States Supported:     S0 S1 S4 S5

(unpatched 2.4.19, if this has anything to do)

Costas

> 								Pavel
-- 
Constantinos Antoniou
Ph.D. Candidate
Massachusetts Institute of Technology
Intelligent Transportation Systems Program
77 Massachusetts Ave., NE20-208, Cambridge, MA 02139
(T) 617-252-1113 * (F) 617-252-1130 * (email) costas@mit.edu

Re: [ACPI] Re: [2.5.50, ACPI] link error

[Ducrot Bruno]

On Sun, Dec 08, 2002 at 03:46:20PM -0500, Constantinos Antoniou wrote:
> On Sun, 2002-12-08 at 14:49, Pavel Machek wrote:
> > Hi!
> > 
> > > > > > > Doesn't that imply your fix is broken to begin with?
> > > > > > 
> > > > > > ACPI/S4 support needs swsusp. ACPI/S3 needs big part of
> > > > > > swsusp. Splitting CONFIG_ACPI_SLEEP to S3 and S4 part seems like
> > > > > > overdesign to me, OTOH if you do the work it is okay with me.
> > > > > 
> > > > > You broke the design. S3 support was developed long before swsusp was in 
> > > > > the kernel, and completely indpendent of it. It should have remained that 
> > > > > way. 
> > > > > 
> > > > > S3 support is a subset of what is need for S4 support. 
> > > > 
> > > > That's not true. acpi_wakeup.S is nasty piece of code, needed for S3
> > > > but not for S4. Big part of driver support is only needed for S3.
> > > > 
> > > > > swsusp is an implementation of S4 support. In theory, there could be 
> > > > > multiple implementations that all use the same core (saving/restoring 
> > > > > state). 
> > > > 
> > > > There were patches for S4bios floating around, but it never really
> > > > worked, IIRC.
> > > 
> > > No.  It work.  I do not resubmmited patches because I think that
> > > swsusp is better.
> > 
> > I think that s4bios is nice to have. Its similar to S3 and easier to
> > set up than swsusp... It would be nice to have it.
> 
> (I do not know much, but) another reason may be that some laptops do not
> support S3, while they support S4? for example, in my Compaq Presario
> 1700T:
> 
> $ more /proc/acpi/info
> ACPI-CA Version:         20011018
> Sx States Supported:     S0 S1 S4 S5

Some southbrigdes have well know design flaw that prevent a 'good' S3
functionality.  Those this is disabled.

-- 
Ducrot Bruno
http://www.poupinou.org        Page profaissionelle
http://toto.tu-me-saoules.com  Haume page

Re: [ACPI] Re: [2.5.50, ACPI] link error

[Ducrot Bruno]

Hi Pavel:

On Sun, Dec 08, 2002 at 08:49:45PM +0100, Pavel Machek wrote:
> Hi!
> 
> > > > > > Doesn't that imply your fix is broken to begin with?
> > > > > 
> > > > > ACPI/S4 support needs swsusp. ACPI/S3 needs big part of
> > > > > swsusp. Splitting CONFIG_ACPI_SLEEP to S3 and S4 part seems like
> > > > > overdesign to me, OTOH if you do the work it is okay with me.
> > > > 
> > > > You broke the design. S3 support was developed long before swsusp was in 
> > > > the kernel, and completely indpendent of it. It should have remained that 
> > > > way. 
> > > > 
> > > > S3 support is a subset of what is need for S4 support. 
> > > 
> > > That's not true. acpi_wakeup.S is nasty piece of code, needed for S3
> > > but not for S4. Big part of driver support is only needed for S3.
> > > 
> > > > swsusp is an implementation of S4 support. In theory, there could be 
> > > > multiple implementations that all use the same core (saving/restoring 
> > > > state). 
> > > 
> > > There were patches for S4bios floating around, but it never really
> > > worked, IIRC.
> > 
> > No.  It work.  I do not resubmmited patches because I think that
> > swsusp is better.
> 
> I think that s4bios is nice to have. Its similar to S3 and easier to
> set up than swsusp... It would be nice to have it.

for me:
pros:
-----
1- it is really really more easier to implement than S4;
2- we can even have it with 2.4 kernels (it seems that it work without
the need of freezing processes, but I suspect that this statement
is 'wrong' by nature).

cons:
-----
1- it is much slower (especially at save time) than your swsusp;
2- end users must setup their systems (need to create a suspend partition,
or to keep a vfat partition as the really first one (/dev/hda1));
3- we use a bios function.  Actually, everything can happen...

That why I prefer swsusp at this time, or any other implementation of S4 (I
think about an implementation of S4 via LKCD).

Cheers,

-- 
Ducrot Bruno
http://www.poupinou.org        Page profaissionelle
http://toto.tu-me-saoules.com  Haume page

Re: [ACPI] Re: [2.5.50, ACPI] link error

[Pavel Machek]

Hi!

> > I think that s4bios is nice to have. Its similar to S3 and easier to
> > set up than swsusp... It would be nice to have it.
> 
> for me:
> pros:
> -----
> 1- it is really really more easier to implement than S4;
> 2- we can even have it with 2.4 kernels (it seems that it work without
> the need of freezing processes, but I suspect that this statement
> is 'wrong' by nature).
> 
> cons:
> -----
> 1- it is much slower (especially at save time) than your swsusp;
> 2- end users must setup their systems (need to create a suspend partition,
> or to keep a vfat partition as the really first one (/dev/hda1));
> 3- we use a bios function.  Actually, everything can happen...
> 
> That why I prefer swsusp at this time, or any other implementation of S4 (I
> think about an implementation of S4 via LKCD).

Yes I think swsusp is better (long term), but it might be worth it to
have S4bios, too. At least it has nice graphical task bars :-). Can
you push the patch, or is it okay for me to try to get it merged?

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

Re: [ACPI] Re: [2.5.50, ACPI] link error

[Ducrot Bruno]

On Mon, Dec 09, 2002 at 12:01:11PM +0100, Pavel Machek wrote:
> Hi!
> 
> > > I think that s4bios is nice to have. Its similar to S3 and easier to
> > > set up than swsusp... It would be nice to have it.
> > 
> > for me:
> > pros:
> > -----
> > 1- it is really really more easier to implement than S4;
> > 2- we can even have it with 2.4 kernels (it seems that it work without
> > the need of freezing processes, but I suspect that this statement
> > is 'wrong' by nature).
> > 
> > cons:
> > -----
> > 1- it is much slower (especially at save time) than your swsusp;
> > 2- end users must setup their systems (need to create a suspend partition,
> > or to keep a vfat partition as the really first one (/dev/hda1));
> > 3- we use a bios function.  Actually, everything can happen...
> > 
> > That why I prefer swsusp at this time, or any other implementation of S4 (I
> > think about an implementation of S4 via LKCD).
> 
> Yes I think swsusp is better (long term), but it might be worth it to
> have S4bios, too. At least it has nice graphical task bars :-). Can
> you push the patch, or is it okay for me to try to get it merged?
> 

Ok, ok.  I will try to push the patch.

-- 
Ducrot Bruno
http://www.poupinou.org        Page profaissionelle
http://toto.tu-me-saoules.com  Haume page