Hi!
mysqld does signal calls in pretty tight loop, and swsusp is not able
to stop processes in such case. This should fix it. Please apply,
Pavel
Index: linux/kernel/signal.c
===================================================================
--- linux.orig/kernel/signal.c 2004-10-01 12:24:26.000000000 +0200
+++ linux/kernel/signal.c 2004-10-01 01:00:26.000000000 +0200
@@ -1483,8 +1483,7 @@
unsigned long flags;
struct sighand_struct *psig;
- if (sig == -1)
- BUG();
+ BUG_ON(sig == -1);
/* do_notify_parent_cldstop should have been called instead. */
BUG_ON(tsk->state & (TASK_STOPPED|TASK_TRACED));
@@ -2260,6 +2259,8 @@
ret = -EINTR;
}
+ if (current->flags & PF_FREEZE)
+ refrigerator(1);
return ret;
}
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
On Monday 04 October 2004 14:24, Pavel Machek wrote:
> Hi!
>
> mysqld does signal calls in pretty tight loop, and swsusp is not able
> to stop processes in such case. This should fix it. Please apply,
> Pavel
Pavel,
I applied your patch to 2.6.9-rc3. Unfortunately, now the system doesn't suspend anymore, it comes back almost immediately:
Stopping tasks: ====================================================|
Freeing memory: ...................................|
radeonfb: suspending to state: 3...
agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
agpgart: Putting AGP V2 device at 0000:00:00.0 into 0x mode
agpgart: Putting AGP V2 device at 0000:01:00.0 into 0x mode
PCI: Setting latency timer of device 0000:00:1d.0 to 64
PCI: Setting latency timer of device 0000:00:1d.0 to 64
PCI: Setting latency timer of device 0000:00:1d.1 to 64
PCI: Setting latency timer of device 0000:00:1d.1 to 64
PCI: Setting latency timer of device 0000:00:1d.2 to 64
PCI: Setting latency timer of device 0000:00:1d.2 to 64
PCI: Setting latency timer of device 0000:00:1d.7 to 64
ACPI: PCI interrupt 0000:00:1f.1[A] -> GSI 10 (level, low) -> IRQ 10
ACPI: PCI interrupt 0000:00:1f.5[B] -> GSI 10 (level, low) -> IRQ 10
PCI: Setting latency timer of device 0000:00:1f.5 to 64
ACPI: PCI interrupt 0000:00:1f.6[B] -> GSI 10 (level, low) -> IRQ 10
PCI: Setting latency timer of device 0000:00:1f.6 to 64
radeonfb: resumed !
Restarting tasks... done
The system never reaches suspend.
Jan
--
BOFH excuse #323:
Your processor has processed too many instructions. Turn it off immediately, do not type any commands!!
Pavel Machek <[email protected]> wrote:
>
> mysqld does signal calls in pretty tight loop, and swsusp is not able
> to stop processes in such case. This should fix it. Please apply,
>
> ...
> @@ -2260,6 +2259,8 @@
> ret = -EINTR;
> }
>
> + if (current->flags & PF_FREEZE)
> + refrigerator(1);
> return ret;
> }
This seems hacky, and arbitrary. I mean, why add this in
sys_rt_sigtimedwait()? Because that is the syscall which mysql appears to
use? What if a different application were to be using a different syscall?
Do we add a refrigerator() call there too?
Or am I missing something?
Hi!
> > mysqld does signal calls in pretty tight loop, and swsusp is not able
> > to stop processes in such case. This should fix it. Please apply,
>
> I applied your patch to 2.6.9-rc3. Unfortunately, now the system doesn't suspend anymore, it comes back almost immediately:
>
And it did work before that patch? I fail to see how this patch could have
broken anything.
Pavel
--
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms
On Tuesday 05 October 2004 00:26, Pavel Machek wrote:
> Hi!
>
> > > mysqld does signal calls in pretty tight loop, and swsusp is not able
> > > to stop processes in such case. This should fix it. Please apply,
> >
> > I applied your patch to 2.6.9-rc3. Unfortunately, now the system doesn't
> > suspend anymore, it comes back almost immediately:
>
> And it did work before that patch? I fail to see how this patch could have
> broken anything.
Suspending worked (besides mysql, which I had to kill manually). With this
patch it doesn't.
Jan
--
BOFH excuse #418:
Sysadmins busy fighting SPAM.