Hi!
This is S4bios support for 2.5.63. I'd like to see it in since it is
easier to understand and more foolproof. Please apply,
Pavel
--- clean/arch/i386/kernel/acpi/wakeup.S 2003-02-25 21:13:49.000000000 +0100
+++ linux/arch/i386/kernel/acpi/wakeup.S 2003-02-18 00:58:24.000000000 +0100
@@ -319,6 +319,31 @@
pushl saved_context_eflags ; popfl
ret
+ENTRY(do_suspend_lowlevel_s4bios)
+ cmpl $0,4(%esp)
+ jne ret_point
+ 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 $ret_point,saved_eip
+ movl %esp,saved_esp
+ movl %ebp,saved_ebp
+ movl %ebx,saved_ebx
+ movl %edi,saved_edi
+ movl %esi,saved_esi
+
+ call acpi_enter_sleep_state_s4bios
+ ret
+
ALIGN
# saved registers
saved_gdt: .long 0,0
--- clean/drivers/acpi/acpi_ksyms.c 2003-02-25 21:17:31.000000000 +0100
+++ linux/drivers/acpi/acpi_ksyms.c 2003-02-15 18:52:15.000000000 +0100
@@ -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);
--- clean/drivers/acpi/hardware/hwsleep.c 2003-02-25 21:17:34.000000000 +0100
+++ linux/drivers/acpi/hardware/hwsleep.c 2003-02-24 22:36:23.000000000 +0100
@@ -335,6 +335,51 @@
return_ACPI_STATUS (AE_OK);
}
+
+/******************************************************************************
+ *
+ * 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();
+
+ status = acpi_os_write_port (acpi_gbl_FADT->smi_cmd, (acpi_integer) acpi_gbl_FADT->S4bios_req, 8);
+
+ do {
+ acpi_os_stall(1000);
+ 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
--- clean/drivers/acpi/sleep/main.c 2003-02-25 21:17:36.000000000 +0100
+++ linux/drivers/acpi/sleep/main.c 2003-02-18 22:36:39.000000000 +0100
@@ -183,14 +180,21 @@
status = acpi_enter_sleep_state(state);
break;
- case ACPI_STATE_S2:
#ifdef CONFIG_SOFTWARE_SUSPEND
+ case ACPI_STATE_S2:
case ACPI_STATE_S3:
do_suspend_lowlevel(0);
+ break;
#endif
+ case ACPI_STATE_S4:
+ do_suspend_lowlevel_s4bios(0);
+ break;
+ default:
+ printk(KERN_WARNING PREFIX "don't know how to handle %d state.\n", state);
break;
}
local_irq_restore(flags);
+ printk(KERN_CRIT "Back to C!\n");
return status;
}
@@ -211,10 +215,20 @@
if (state < ACPI_STATE_S1 || state > ACPI_STATE_S5)
return AE_ERROR;
+ /* Since we handle S4OS via a different path (swsusp), give up if no s4bios. */
+ if (state == ACPI_STATE_S4 && !acpi_gbl_FACS->S4bios_f)
+ return AE_ERROR;
+
+ /*
+ * TBD: S1 can be done without device_suspend. Make a CONFIG_XX
+ * to handle however when S1 failed without device_suspend.
+ */
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) {
+ /* Here, we support only S4BIOS, those we set the wakeup address */
+ /* S4OS is only supported for now via swsusp.. */
+ if (state == ACPI_STATE_S2 || state == ACPI_STATE_S3 || ACPI_STATE_S4) {
if (!acpi_wakeup_address)
return AE_ERROR;
acpi_set_firmware_waking_vector((acpi_physical_address) acpi_wakeup_address);
@@ -268,6 +282,10 @@
sleep_states[i] = 1;
printk(" S%d", i);
}
+ if (i == ACPI_STATE_S4 && acpi_gbl_FACS->S4bios_f) {
+ sleep_states[i] = 1;
+ printk(" S4bios");
+ }
}
printk(")\n");
--- clean/drivers/acpi/sleep/proc.c 2003-02-25 21:17:37.000000000 +0100
+++ linux/drivers/acpi/sleep/proc.c 2003-02-15 18:57:55.000000000 +0100
@@ -27,8 +27,11 @@
ACPI_FUNCTION_TRACE("acpi_system_sleep_seq_show");
for (i = 0; i <= ACPI_STATE_S5; i++) {
- if (sleep_states[i])
+ if (sleep_states[i]) {
seq_printf(seq,"S%d ", i);
+ if (i == ACPI_STATE_S4 && acpi_gbl_FACS->S4bios_f)
+ seq_printf(seq, "S4bios ");
+ }
}
seq_puts(seq, "\n");
--- clean/include/acpi/acpixf.h 2003-02-25 21:20:49.000000000 +0100
+++ linux/include/acpi/acpixf.h 2003-02-24 22:36:42.000000000 +0100
@@ -399,6 +399,10 @@
u8 sleep_state);
acpi_status
+acpi_enter_sleep_state_s4bios (
+ void);
+
+acpi_status
acpi_leave_sleep_state (
u8 sleep_state);
--- clean/include/linux/suspend.h 2003-02-25 21:22:36.000000000 +0100
+++ linux/include/linux/suspend.h 2003-02-10 18:17:01.000000000 +0100
@@ -73,6 +73,7 @@
/* Communication between acpi and arch/i386/suspend.c */
extern void do_suspend_lowlevel(int resume);
+extern void do_suspend_lowlevel_s4bios(int resume);
#else
static inline void software_suspend(void)
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
On Wed, Feb 26, 2003 at 10:13:47PM +0100, Pavel Machek wrote:
> Hi!
>
> This is S4bios support for 2.5.63. I'd like to see it in since it is
> easier to understand and more foolproof. Please apply,
>
> Pavel
> +/******************************************************************************
> + *
> + * 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();
> +
> + status = acpi_os_write_port (acpi_gbl_FADT->smi_cmd, (acpi_integer) acpi_gbl_FADT->S4bios_req, 8);
> +
> + do {
> + acpi_os_stall(1000);
> + status = acpi_get_register (ACPI_BITREG_WAKE_STATUS, &in_value, ACPI_MTX_LOCK);
Please use ACPI_MTX_DO_NOT_LOCK flags.
1- all others user land are no more scheduled, and irqs are disabled.
2- the saved memory image is the one that appar 'randomly' when the suspension
happen, it is then possible that that we enter acpi_get_register()
3- acpi_get_register() touch one semaphore (a mutex) if you pass ACPI_MTX_LOCK,
then it is possible that this mutex is not released:
we are supposed to go to 'ret_point' in arch/i386/kernel/acpi/wakeup.S
4- after resuming, any try to acquire this mutex will deadlock (this will happen early
in acpi_leave_sleep_state()).
Cheers,
--
Ducrot Bruno
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
On Wed, Feb 26, 2003 at 10:13:47PM +0100, Pavel Machek wrote:
> This is S4bios support for 2.5.63. I'd like to see it in since it is
> easier to understand and more foolproof. Please apply,
Pavel,
Since 2.5.61 at least swsusp doesn't work here, with or without S4bios. It
lists a heap of processes entering the refrigerator, then prints '=|' and
moves one line downwards, cursor blinking on an empty line.
Nothing appears to happen then, except that if I press alt-f7, my screen
blanks as if X is still partly alive. Alt-SysRQ also works and shows heaps
of processes, most of them with 'refrigerator' somewhere in their traceback.
Nothing is written to disk however.
I try to suspend with "echo 4 > /proc/acpi/sleep".
>From dmesg on bootup:
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e8000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000000bff0000 (usable)
BIOS-e820: 000000000bff0000 - 000000000bff8000 (ACPI data)
BIOS-e820: 000000000bff8000 - 000000000c000000 (ACPI NVS)
BIOS-e820: 00000000ffef0000 - 00000000fff00000 (reserved)
BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
191MB LOWMEM available.
ACPI: have wakeup address 0xc0001000
On node 0 totalpages: 49136
DMA zone: 4096 pages, LIFO batch:1
Normal zone: 45040 pages, LIFO batch:10
HighMem zone: 0 pages, LIFO batch:1
ACPI: RSDP (v000 AMI ) @ 0x000fc740
ACPI: RSDT (v001 AMIINT AMIINT09 00000.04096) @ 0x0bff0000
ACPI: FADT (v001 AMIINT AMIINT09 00000.04096) @ 0x0bff0030
ACPI: DSDT (v001 SiS 630 00000.04096) @ 0x00000000
ACPI: BIOS passes blacklist
Building zonelist for node : 0
Kernel command line: root=/dev/hda1 resume=/dev/hda2
Initializing CPU#0
PID hash table entries: 1024 (order 10: 8192 bytes)
Detected 1096.985 MHz processor.
--
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 20030122
tbxface-0117 [03] acpi_load_tables : ACPI Tables successfully acquired
Parsing all Control Methods:...............................................................................................................................
Table [DSDT] - 419 Objects with 37 Devices 127 Methods 20 Regions
ACPI Namespace successfully loaded at root c040eb9c
evxfevnt-0092 [04] acpi_enable : Transition to ACPI mode successful
Executing all Device _STA and_INI methods:.....................................
37 Devices found containing: 37 _STA, 1 _INI methods
Completing Region/Field/Buffer/Package initialization:................................................................
Initialized 16/20 Regions 0/0 Fields 29/29 Buffers 19/19 Packages (419 nodes)
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: Embedded Controller [EC0] (gpe 11)
ACPI: Power Resource [FDDP] (off)
ACPI: Power Resource [LPTP] (off)
ACPI: Power Resource [URP2] (off)
ACPI: Power Resource [URP1] (off)
pci_link-0249 [07] acpi_pci_link_get_curr: Invalid use of IRQ 0
ACPI: PCI Interrupt Link [LNKB] (IRQs 4 6 7 11 12 14 15, disabled)
pci_link-0249 [07] acpi_pci_link_get_curr: Invalid use of IRQ 0
ACPI: PCI Interrupt Link [LNKC] (IRQs 6 7 10 12 14 15, disabled)
pci_link-0249 [07] acpi_pci_link_get_curr: Invalid use of IRQ 0
ACPI: PCI Interrupt Link [LNKD] (IRQs 11, disabled)
ACPI: Power Resource [FN10] (on)
block request queues:
128 requests per read queue
128 requests per write queue
8 requests per batch
enter congestion at 15
exit congestion at 17
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 11
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 10
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11
PCI: Using ACPI for IRQ routing
PCI: if you experience problems, try using option 'pci=noacpi' or even 'acpi=off'
NET4: Frame Diverter 0.46
Enabling SEP on CPU 0
aio_setup: sizeof(struct page) = 40
Journalled Block Device driver loaded
devfs: v1.22 (20021013) Richard Gooch ([email protected])
devfs: boot_options: 0x0
Initializing Cryptographic API
ACPI: AC Adapter [AC0] (on-line)
ACPI: Battery Slot [BAT0] (battery present)
ACPI: Lid Switch [LIDD]
ACPI: Sleep Button (CM) [SLPB]
ACPI: Power Button (CM) [PWRB]
ACPI: Fan [FAN1] (off)
ACPI: Processor [CPU1] (supports C1 C2, 8 throttling states)
exfldio-0140 [25] ex_setup_region : Field [TMPS] Base+Offset+Width 4+0+4 is beyond end of region [M4D0] (length 6)
psparse-1121: *** Error: Method execution failed [\_TZ_.THRM._TMP] (Node cbf11148), AE_AML_REGION_LIMIT
Serial: 8250/16550 driver $Revision: 1.90 $ IRQ sharing disabled
tts/0 at I/O 0x3f8 (irq = 4) is a 16550A
tts/1 at I/O 0x2f8 (irq = 3) is a 16550A
--
Initializing IPsec netlink socket
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
IPv6 v0.8 for NET4.0
IPv6 over IPv4 tunneling driver
divert: not allocating divert_blk for non-ethernet device sit0
ACPI: (supports S0 S1 S4 S5)
.config:
# egrep -i 'acpi|susp' /mnt/linux-2.5.63/.config
# Power management options (ACPI, APM)
CONFIG_SOFTWARE_SUSPEND=y
# ACPI Support
CONFIG_ACPI=y
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_SLEEP_PROC_FS=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_FAN=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
CONFIG_ACPI_TOSHIBA=y
CONFIG_ACPI_DEBUG=y
CONFIG_ACPI_BUS=y
CONFIG_ACPI_INTERPRETER=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SYSTEM=y
If you have further questions about my configuration, just let me know.
Regards,
bert
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://lartc.org Linux Advanced Routing & Traffic Control HOWTO
http://netherlabs.nl Consulting
Hi.
This bug is fixed in Linus tree. If you want swsusp to work in the mean
time, look for a couple of patches Pavel sent recently.
Regards,
Nigel
On Mon, Mar 03, 2003 at 07:44:03AM +1300, Nigel Cunningham wrote:
> Hi.
>
> This bug is fixed in Linus tree. If you want swsusp to work in the mean
> time, look for a couple of patches Pavel sent recently.
Ok,
In 2.5.63bk5 I get a BUG on drivers/ide/ide-disk.c:1557:
BUG_ON (HWGROUP(drive)->handler);
It now says (copied by hand):
freeing memory: .....................|
(this 'freeing' takes ages, around 30 seconds, while in progress, the disk
light blinks every once in a while, perhaps each time while a dot is being
printed)
syncing disks
suspending devices
suspending c0418bcc
suspending devices
suspending c0418bcc
suspending: hda ------------------[ cut here
trace back:
device_susp()
drivers_susp()
do_sofware_susp()
Regards,
bert
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://lartc.org Linux Advanced Routing & Traffic Control HOWTO
http://netherlabs.nl Consulting
On Sun, 2003-03-02 at 20:21, bert hubert wrote:
> On Mon, Mar 03, 2003 at 07:44:03AM +1300, Nigel Cunningham wrote:
> > Hi.
> >
> > This bug is fixed in Linus tree. If you want swsusp to work in the mean
> > time, look for a couple of patches Pavel sent recently.
>
> Ok,
>
> In 2.5.63bk5 I get a BUG on drivers/ide/ide-disk.c:1557:
>
>
> BUG_ON (HWGROUP(drive)->handler);
Looks like swsuspend attempted to run an operation while one was in
progress. IDE tries to catch that because the result of missing it isnt
very pretty at fsck time.
On Sun, 02 Mar 2003 21:21:18 +0100, bert hubert wrote:
> In 2.5.63bk5 I get a BUG on drivers/ide/ide-disk.c:1557:
>
>
> BUG_ON (HWGROUP(drive)->handler);
>
That problem has been around for a while. I reported it for 2.5.59 which
just happened to be the first 2.5 kernel I tested with swsuspend.
I'm seeing the bug every time I try swsuspend on 2.5. The same Vanilla
kernels seem to work for other people, though.
The only thing that came up at the time was a suggestion to replace BUG_ON
with while (which I didn't try because I'd like to keep my data).
Roger
On Mon, 2003-03-03 at 13:39, Roger Luethi wrote:
> I'm seeing the bug every time I try swsuspend on 2.5. The same Vanilla
> kernels seem to work for other people, though.
Yes - I have no problems in this area.
> The only thing that came up at the time was a suggestion to replace BUG_ON
> with while (which I didn't try because I'd like to keep my data).
I'll see if I can find a solution.
Regards,
Nigel
On Mon, Mar 03, 2003 at 03:08:11PM +1300, Nigel Cunningham wrote:
> > The only thing that came up at the time was a suggestion to replace BUG_ON
> > with while (which I didn't try because I'd like to keep my data).
>
> I'll see if I can find a solution.
A data point may be that at one point, swsusp did work just fine for me.
This was around 2.5.53, 2.5.54:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=20021227142032.GA6945%40outpost.ds9a.nl&rnum=1&prev=/groups%3Fq%3Dswsusp%2Bbert%2Bhubert%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3D20021227142032.GA6945%2540outpost.ds9a.nl%26rnum%3D1
I now use gcc 3.2.2 for compiling though. I've tried suspending a few times
with 2.5.63bk5 and I get the BUG every time, so it appears to be
deterministic and not racey.
Regards,
bert
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://lartc.org Linux Advanced Routing & Traffic Control HOWTO
http://netherlabs.nl Consulting
On Mon, 03 Mar 2003 12:31:53 +0100, bert hubert wrote:
> I now use gcc 3.2.2 for compiling though. I've tried suspending a few times
> with 2.5.63bk5 and I get the BUG every time, so it appears to be
> deterministic and not racey.
Yep. It's not the compiler, though. I'm using 2.95.3.
Roger
Hi!
> > > The only thing that came up at the time was a suggestion to replace BUG_ON
> > > with while (which I didn't try because I'd like to keep my data).
> >
> > I'll see if I can find a solution.
>
> A data point may be that at one point, swsusp did work just fine for me.
> This was around 2.5.53, 2.5.54:
>
> http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=20021227142032.GA6945%40outpost.ds9a.nl&rnum=1&prev=/groups%3Fq%3Dswsusp%2Bbert%2Bhubert%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3D20021227142032.GA6945%2540outpost.ds9a.nl%26rnum%3D1
>
> I now use gcc 3.2.2 for compiling though. I've tried suspending a few times
> with 2.5.63bk5 and I get the BUG every time, so it appears to be
> deterministic and not racey.
Well, it does not happen on my machines, but I've already seen it
happen on computer with two harddrives.
Pavel
--
Horseback riding is like software...
...vgf orggre jura vgf serr.
[ pruned mr Grover from the CC list ]
On Mon, Mar 03, 2003 at 01:23:25PM +0100, Pavel Machek wrote:
> Well, it does not happen on my machines, but I've already seen it
> happen on computer with two harddrives.
This is a laptop with only one. Anything I can do to help, let me know. Alan
has suggested that an IDE transaction was still in progress, perhaps a small
wait could prove/disprove this assumption?
Regards,
bert
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://lartc.org Linux Advanced Routing & Traffic Control HOWTO
http://netherlabs.nl Consulting
On Mon, 03 Mar 2003 13:23:25 +0100, Pavel Machek wrote:
> Well, it does not happen on my machines, but I've already seen it
> happen on computer with two harddrives.
That was my initial suspicion, since I have two of them and typical swsusp
(Laptop) users tend not to have more than one. But I gave up on that theory
when Bert's log showed only one disk:
# syncing disks
# suspending devices
# suspending c0418bcc
# suspending devices
# suspending c0418bcc
# suspending: hda ------------------[ cut here
If he had two disks, his trace should look more like mine:
# Syncing disks before copy
# Suspending devices
# Suspending device c0390e4c
# Suspending device c03911a4
# Suspending devices
# Suspending device c0390e4c
# suspending: had ------------[ cut here ]------------
# kernel BUG at drivers/ide/ide-disk.c:1557!
Roger
Hi!
> [ pruned mr Grover from the CC list ]
>
> On Mon, Mar 03, 2003 at 01:23:25PM +0100, Pavel Machek wrote:
> > Well, it does not happen on my machines, but I've already seen it
> > happen on computer with two harddrives.
>
> This is a laptop with only one. Anything I can do to help, let me know. Alan
> has suggested that an IDE transaction was still in progress, perhaps a small
> wait could prove/disprove this assumption?
Start adding printks to see whats going on. Try going ext2. Try
killing sys_sync() from kernel/suspend.c.
Pavel
--
Horseback riding is like software...
...vgf orggre jura vgf serr.
On Mon, 2003-03-03 at 00:39, Roger Luethi wrote:
> The only thing that came up at the time was a suggestion to replace BUG_ON
> with while (which I didn't try because I'd like to keep my data).
That isnt far off what you want. IDE has proper command queuing functionality and
providing you are suspending in a sleeping context you can do what you are trying
to do through the IDE layer politely. Take a look at how the various ide taskfile
ioctls issue commands.
On Mon, 2003-03-03 at 12:35, bert hubert wrote:
> This is a laptop with only one. Anything I can do to help, let me know. Alan
> has suggested that an IDE transaction was still in progress, perhaps a small
> wait could prove/disprove this assumption?
Two drives would make some sense as an easier trigger. An IDE command can only be
outstanding per interface not per device.
On Mon, Mar 03, 2003 at 02:09:07PM +0000, Alan Cox wrote:
> On Mon, 2003-03-03 at 00:39, Roger Luethi wrote:
> > The only thing that came up at the time was a suggestion to replace BUG_ON
> > with while (which I didn't try because I'd like to keep my data).
>
> That isnt far off what you want. IDE has proper command queuing functionality and
> providing you are suspending in a sleeping context you can do what you are trying
> to do through the IDE layer politely. Take a look at how the various ide taskfile
> ioctls issue commands.
>
the problem is that the suspend/resume code bypass the this kind of
stuff imho.
--
Ducrot Bruno
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
On Mon, Mar 03, 2003 at 01:41:33PM +0100, Pavel Machek wrote:
> Start adding printks to see whats going on. Try going ext2. Try
> killing sys_sync() from kernel/suspend.c.
I've tried:
hdparm -u1 /dev/hda
killing sys_sync()
doing both
To no avail. I'm investigating how I can go ext2 on this machine as I read
elsewhere that the kernel will silently mount an ext3 partition with a
journal as ext3 even when asked to mount as ext2.
Regards,
bert
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://lartc.org Linux Advanced Routing & Traffic Control HOWTO
http://netherlabs.nl Consulting
On Mon, 2003-03-03 at 15:11, bert hubert wrote:
> To no avail. I'm investigating how I can go ext2 on this machine as I read
> elsewhere that the kernel will silently mount an ext3 partition with a
> journal as ext3 even when asked to mount as ext2.
hdparm -u1 is just changing the timing its not actually touching the bug in
the suspend code.
> > [ pruned mr Grover from the CC list ]
> >
> > On Mon, Mar 03, 2003 at 01:23:25PM +0100, Pavel Machek wrote:
> > > Well, it does not happen on my machines, but I've already seen it
> > > happen on computer with two harddrives.
> >
> > This is a laptop with only one. Anything I can do to help, let me know.
> > Alan has suggested that an IDE transaction was still in progress, perhaps
> > a small wait could prove/disprove this assumption?
>
> Start adding printks to see whats going on. Try going ext2. Try
> killing sys_sync() from kernel/suspend.c.
>
> Pavel
This looks like the problem I've been reporting since 2.5.5x . On my machine
(HP XE3GC) I get a rare chance that this happens.
One raw hack I have been using to get around that, is my 'sleep' script (for
S1):
/etc/init.d/ypbind stop #i.e. prepare the system
sleep 9 #allow me to lock the screen etc.
sync #This is where I reduce the chance I have dirty buffers
sleep 1 # calm down
echo 1 >/proc/acpi/sleep #sleep now
That won't fix the bug, of course, but shows what may go wrong..
On Mon, Mar 03, 2003 at 01:41:33PM +0100, Pavel Machek wrote:
> Start adding printks to see whats going on. Try going ext2. Try
> killing sys_sync() from kernel/suspend.c.
Problem remains with ext2 and with all fs 'emergency mounted r/o' with
alt-sysrq beforehand.
This mostly ends my ability to debug this problem further as I lack the
knowledge to figure out what is going on within the IDE code.
Regards,
bert
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://lartc.org Linux Advanced Routing & Traffic Control HOWTO
http://netherlabs.nl Consulting
Hi!
> > +
> > + do {
> > + acpi_os_stall(1000);
> > + status = acpi_get_register (ACPI_BITREG_WAKE_STATUS, &in_value, ACPI_MTX_LOCK);
>
> Please use ACPI_MTX_DO_NOT_LOCK flags.
Is s/MTX_LOCK/MTX_DO_NOT_LOCK/
enough?
Pavel
--
Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...
On Tue, Mar 04, 2003 at 02:23:29PM +0100, Pavel Machek wrote:
> Hi!
>
>
> > > +
> > > + do {
> > > + acpi_os_stall(1000);
> > > + status = acpi_get_register (ACPI_BITREG_WAKE_STATUS, &in_value, ACPI_MTX_LOCK);
> >
> > Please use ACPI_MTX_DO_NOT_LOCK flags.
>
> Is s/MTX_LOCK/MTX_DO_NOT_LOCK/
> enough?
>
Never mind. Someone has already made the modif.
--
Ducrot Bruno
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.