Question about Xen S3 and resume code - Linux dom0 never exits the xen_safe_halt hypercall after resume

Question about Xen S3 and resume code - Linux dom0 never exits the xen_safe_halt hypercall after resume

[Konrad Rzeszutek Wilk]

I've been eyeing the ACPI S3/S5 code to see what would be necessary to
retool, and while testing I found something strange..

I've stuck the code on

 git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git devel/acpi-s3.v1

I found out that if I don't have this patch:

commit 9f301b0a0081676dfc71b7f0898295e6bcba391a
Author: Yu Ke <ke.yu@intel.com>
Date:   Thu Jun 16 17:15:26 2011 -0400

    xen/acpi: add xen acpi processor driver

(which is in the devel/acpi-s3.v0 branch).

the hypervisor, after an S3 resume sits forever in the default_idle. The
Linux dom0 is stuck looping (I think) around SCHEDOP_block hypercall.

http://darnok.org/xen/devel.acpi-s3.v1.serial.log

If that patch above is present and I've cpufreq=xen on the Xen
hypervisor then Linux kernel gets unstuck and returns to userspace:

http://darnok.org/xen/devel.acpi-s3.v0.serial.log

(however, if I set cpuidle=0 cpufreq=none on the hypervisor line and
have the 9f301b0a0081676dfc71b7f0898295e6bcba391a patch it still
gets stuck).

I figured that the primary reason the guest is allowed to
exit is SCHEDOP_block loop is b/c the pm_idle call is set to the
acp_processor_idle which does "something" extra after the machine comes
out of a S3 suspend.

Any ideas?

RE: Question about Xen S3 and resume code - Linux dom0 never exits the xen_safe_halt hypercall after resume

[Tian, Kevin]

> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: Friday, June 17, 2011 6:58 AM
> 
> I've been eyeing the ACPI S3/S5 code to see what would be necessary to
> retool, and while testing I found something strange..
> 
> I've stuck the code on
> 
>  git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git devel/acpi-s3.v1
> 
> I found out that if I don't have this patch:
> 
> commit 9f301b0a0081676dfc71b7f0898295e6bcba391a
> Author: Yu Ke <ke.yu@intel.com>
> Date:   Thu Jun 16 17:15:26 2011 -0400
> 
>     xen/acpi: add xen acpi processor driver

ideally ACPI S3/S5 has nothing to do with ACPI processor driver which is for Cx/Px.

> 
> (which is in the devel/acpi-s3.v0 branch).
> 
> the hypervisor, after an S3 resume sits forever in the default_idle. The
> Linux dom0 is stuck looping (I think) around SCHEDOP_block hypercall.
> 
> http://darnok.org/xen/devel.acpi-s3.v1.serial.log
> 
> If that patch above is present and I've cpufreq=xen on the Xen
> hypervisor then Linux kernel gets unstuck and returns to userspace:
> 
> http://darnok.org/xen/devel.acpi-s3.v0.serial.log

Compare your logs, the major difference is:

[  168.754739] calling  i2c-8+ @ 3096
[  168.758200] call i2c-8+ returned 0 after 0 usecs
<<< 1st case stuck here
[  168.762882] calling  card0-VGA-1+ @ 3096
[  168.766867] call card0-VGA-1+ returned 0 after 0 usecs
[  168.772085] calling  ttm+ @ 3096
[  168.775360] call ttm+ returned 0 after 0 usecs
[  168.779870] PM: resume of devices complete after 13117.603 msecs
[  168.786006] PM: Finishing wakeup.
<<<2nd case forward progress

It looks that VGA card resume has some problem on resume, which then
makes dom0 stay in idle loop and thus block hypercall, and then due to
no runnable vcpu so Xen most time in idle_loop too. In earlier log there're
some stack trace in i915 driver. Perhaps you can try a different machine
or try native S3 on same box to make sure it's not mixed with native issues.

> 
> (however, if I set cpuidle=0 cpufreq=none on the hypervisor line and
> have the 9f301b0a0081676dfc71b7f0898295e6bcba391a patch it still
> gets stuck).
> 
> I figured that the primary reason the guest is allowed to
> exit is SCHEDOP_block loop is b/c the pm_idle call is set to the
> acp_processor_idle which does "something" extra after the machine comes
> out of a S3 suspend.

If that's the case I think you should disable CONFIG_ACPI_PROCESSOR in dom0
before incorporating Xen specific version (the patch you tried). We don't want
dom0 to play with Cx directly b/c it's the responsibility of Xen.

Of course we still need figure out why same issues occur with cpuidle=0/
cpufreq=none, which however can be revisited after the basic S3 works. :-)

> 
> Any ideas?

No other ideas for now. From historical view Xen S3 was supported before
Cx/Px, and so it's expected to work correctly w/o ACPI processor driver. So 
please make sure CONFIG_ACPI_PROCESSOR not enabled in your test for
basic S3.

Thanks
Kevin

Re: Question about Xen S3 and resume code - Linux dom0 never exits the xen_safe_halt hypercall after resume

[Konrad Rzeszutek Wilk]

> ideally ACPI S3/S5 has nothing to do with ACPI processor driver which is for Cx/Px.

Right..
> 
> > 
> > (which is in the devel/acpi-s3.v0 branch).
> > 
> > the hypervisor, after an S3 resume sits forever in the default_idle. The
> > Linux dom0 is stuck looping (I think) around SCHEDOP_block hypercall.
> > 
> > http://darnok.org/xen/devel.acpi-s3.v1.serial.log
> > 
> > If that patch above is present and I've cpufreq=xen on the Xen
> > hypervisor then Linux kernel gets unstuck and returns to userspace:
> > 
> > http://darnok.org/xen/devel.acpi-s3.v0.serial.log
> 
> Compare your logs, the major difference is:
> 
> [  168.754739] calling  i2c-8+ @ 3096
> [  168.758200] call i2c-8+ returned 0 after 0 usecs
> <<< 1st case stuck here
> [  168.762882] calling  card0-VGA-1+ @ 3096
> [  168.766867] call card0-VGA-1+ returned 0 after 0 usecs
> [  168.772085] calling  ttm+ @ 3096
> [  168.775360] call ttm+ returned 0 after 0 usecs
> [  168.779870] PM: resume of devices complete after 13117.603 msecs
> [  168.786006] PM: Finishing wakeup.
> <<<2nd case forward progress
> 
> It looks that VGA card resume has some problem on resume, which then

In both cases - with the patch and without..

> makes dom0 stay in idle loop and thus block hypercall, and then due to
> no runnable vcpu so Xen most time in idle_loop too. In earlier log there're
> some stack trace in i915 driver. Perhaps you can try a different machine

Or remove the i915 just to eliminate that.
> or try native S3 on same box to make sure it's not mixed with native issues.
> 
> > 
> > (however, if I set cpuidle=0 cpufreq=none on the hypervisor line and
> > have the 9f301b0a0081676dfc71b7f0898295e6bcba391a patch it still
> > gets stuck).
> > 
> > I figured that the primary reason the guest is allowed to
> > exit is SCHEDOP_block loop is b/c the pm_idle call is set to the
> > acp_processor_idle which does "something" extra after the machine comes
> > out of a S3 suspend.
> 
> If that's the case I think you should disable CONFIG_ACPI_PROCESSOR in dom0
> before incorporating Xen specific version (the patch you tried). We don't want
> dom0 to play with Cx directly b/c it's the responsibility of Xen.

Huh? You misunderstood me. The 'acpi_processor_idle' is the hypervisor's
idle loop. It can be running inside of that one, or the 'default_idle' loop. Hence
my question why would that specific hypervisor idle loop make dom0 run nicely
while the default one would not.

In dom0, irregardless of the patches, the 'default_idle' is run which makes the
xen_safe_halt paravirt call.

> 
> Of course we still need figure out why same issues occur with cpuidle=0/
> cpufreq=none, which however can be revisited after the basic S3 works. :-)

Right. The end result of those parameters is that the 'default_idle' in the
hypervisor is choosen instead of the 'acpi_processor_idle' one.
> 
> > 
> > Any ideas?
> 
> No other ideas for now. From historical view Xen S3 was supported before

Hmm, I am actually tempted to start commenting out code in the acpi_processor_idle
and seeing what will cause it to have the same failure as 'default_idle'.

RE: Question about Xen S3 and resume code - Linux dom0 never exits the xen_safe_halt hypercall after resume

[Tian, Kevin]

> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: Monday, June 20, 2011 8:36 PM
> 
> > ideally ACPI S3/S5 has nothing to do with ACPI processor driver which is for
> Cx/Px.
> 
> Right..
> >
> > >
> > > (which is in the devel/acpi-s3.v0 branch).
> > >
> > > the hypervisor, after an S3 resume sits forever in the default_idle. The
> > > Linux dom0 is stuck looping (I think) around SCHEDOP_block hypercall.
> > >
> > > http://darnok.org/xen/devel.acpi-s3.v1.serial.log
> > >
> > > If that patch above is present and I've cpufreq=xen on the Xen
> > > hypervisor then Linux kernel gets unstuck and returns to userspace:
> > >
> > > http://darnok.org/xen/devel.acpi-s3.v0.serial.log
> >
> > Compare your logs, the major difference is:
> >
> > [  168.754739] calling  i2c-8+ @ 3096
> > [  168.758200] call i2c-8+ returned 0 after 0 usecs
> > <<< 1st case stuck here
> > [  168.762882] calling  card0-VGA-1+ @ 3096
> > [  168.766867] call card0-VGA-1+ returned 0 after 0 usecs
> > [  168.772085] calling  ttm+ @ 3096
> > [  168.775360] call ttm+ returned 0 after 0 usecs
> > [  168.779870] PM: resume of devices complete after 13117.603 msecs
> > [  168.786006] PM: Finishing wakeup.
> > <<<2nd case forward progress
> >
> > It looks that VGA card resume has some problem on resume, which then
> 
> In both cases - with the patch and without..

that's expected since device suspend is always invoked in the S3 path.

> 
> > makes dom0 stay in idle loop and thus block hypercall, and then due to
> > no runnable vcpu so Xen most time in idle_loop too. In earlier log there're
> > some stack trace in i915 driver. Perhaps you can try a different machine
> 
> Or remove the i915 just to eliminate that.

So any result there? :-)

> > or try native S3 on same box to make sure it's not mixed with native issues.
> >
> > >
> > > (however, if I set cpuidle=0 cpufreq=none on the hypervisor line and
> > > have the 9f301b0a0081676dfc71b7f0898295e6bcba391a patch it still
> > > gets stuck).
> > >
> > > I figured that the primary reason the guest is allowed to
> > > exit is SCHEDOP_block loop is b/c the pm_idle call is set to the
> > > acp_processor_idle which does "something" extra after the machine comes
> > > out of a S3 suspend.
> >
> > If that's the case I think you should disable CONFIG_ACPI_PROCESSOR in
> dom0
> > before incorporating Xen specific version (the patch you tried). We don't want
> > dom0 to play with Cx directly b/c it's the responsibility of Xen.
> 
> Huh? You misunderstood me. The 'acpi_processor_idle' is the hypervisor's
> idle loop. It can be running inside of that one, or the 'default_idle' loop. Hence

running inside which one? I'd think only default_idle invokes it when current cpu
is actually idle.

> my question why would that specific hypervisor idle loop make dom0 run nicely
> while the default one would not.

this is counterintuitive to me honestly speaking. I'd more think that 
acpi_processor_idle may cause some issue than pure "sti;hlt" because acpi
version has more logic to handle. In earlier day when it's still in stabilization
phase, we did observe some non-exit case from deep Cstate but this never
happens on pure hlt.

IOW, I don't take this idle path as a necessary step to make S3 resume working,
which is simply related when the cpu has nothing to do... 

> 
> In dom0, irregardless of the patches, the 'default_idle' is run which makes the
> xen_safe_halt paravirt call.

OK, that matches my expectation then.

> 
> >
> > Of course we still need figure out why same issues occur with cpuidle=0/
> > cpufreq=none, which however can be revisited after the basic S3 works. :-)
> 
> Right. The end result of those parameters is that the 'default_idle' in the
> hypervisor is choosen instead of the 'acpi_processor_idle' one.
> >
> > >
> > > Any ideas?
> >
> > No other ideas for now. From historical view Xen S3 was supported before
> 
> Hmm, I am actually tempted to start commenting out code in the
> acpi_processor_idle
> and seeing what will cause it to have the same failure as 'default_idle'.

you can also try "max_cstates=1" to see any difference, which is expected to
has similar effect as safe_halt().

Thanks
Kevin

RE: RE: Question about Xen S3 and resume code - Linux dom0 never exits the xen_safe_halt hypercall after resume

[Tian, Kevin]

Hi, Konrad,

any update on this S3 problem you're seeing?

I just got a chance to give a try on my Dell core-i7 platform with a Ubuntu 10.10
system. 

Xen version is:
changeset:   23632:33717472f37e
tag:         tip
user:        Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
date:        Tue Jun 28 18:15:44 2011 +0100
summary:     libxc: Squash xc_e820.h (and delete) into xenctrl.h

for dom0 I use origin/master plus ACPI patches queued on your origin/devel/acpi-s3.v0:
commit 4aa69dc48e031276b4d771dcb227d553fd3def0b
Merge: df5b2b6 9f90a3b
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Tue Jun 21 09:34:31 2011 -0400

    Merge branch '3.0-rc1-rem_pg_reserve-4' of git://xenbits.xen.org/people/sstabellini/linux-pvhvm

w/ or w/o ACPI processor patches on my box ACPI S3 just works well.

Thanks
Kevin

> From: Tian, Kevin
> Sent: Tuesday, June 21, 2011 7:22 AM
> 
> > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> > Sent: Monday, June 20, 2011 8:36 PM
> >
> > > ideally ACPI S3/S5 has nothing to do with ACPI processor driver which is for
> > Cx/Px.
> >
> > Right..
> > >
> > > >
> > > > (which is in the devel/acpi-s3.v0 branch).
> > > >
> > > > the hypervisor, after an S3 resume sits forever in the default_idle. The
> > > > Linux dom0 is stuck looping (I think) around SCHEDOP_block hypercall.
> > > >
> > > > http://darnok.org/xen/devel.acpi-s3.v1.serial.log
> > > >
> > > > If that patch above is present and I've cpufreq=xen on the Xen
> > > > hypervisor then Linux kernel gets unstuck and returns to userspace:
> > > >
> > > > http://darnok.org/xen/devel.acpi-s3.v0.serial.log
> > >
> > > Compare your logs, the major difference is:
> > >
> > > [  168.754739] calling  i2c-8+ @ 3096
> > > [  168.758200] call i2c-8+ returned 0 after 0 usecs
> > > <<< 1st case stuck here
> > > [  168.762882] calling  card0-VGA-1+ @ 3096
> > > [  168.766867] call card0-VGA-1+ returned 0 after 0 usecs
> > > [  168.772085] calling  ttm+ @ 3096
> > > [  168.775360] call ttm+ returned 0 after 0 usecs
> > > [  168.779870] PM: resume of devices complete after 13117.603 msecs
> > > [  168.786006] PM: Finishing wakeup.
> > > <<<2nd case forward progress
> > >
> > > It looks that VGA card resume has some problem on resume, which then
> >
> > In both cases - with the patch and without..
> 
> that's expected since device suspend is always invoked in the S3 path.
> 
> >
> > > makes dom0 stay in idle loop and thus block hypercall, and then due to
> > > no runnable vcpu so Xen most time in idle_loop too. In earlier log there're
> > > some stack trace in i915 driver. Perhaps you can try a different machine
> >
> > Or remove the i915 just to eliminate that.
> 
> So any result there? :-)
> 
> > > or try native S3 on same box to make sure it's not mixed with native issues.
> > >
> > > >
> > > > (however, if I set cpuidle=0 cpufreq=none on the hypervisor line and
> > > > have the 9f301b0a0081676dfc71b7f0898295e6bcba391a patch it still
> > > > gets stuck).
> > > >
> > > > I figured that the primary reason the guest is allowed to
> > > > exit is SCHEDOP_block loop is b/c the pm_idle call is set to the
> > > > acp_processor_idle which does "something" extra after the machine
> comes
> > > > out of a S3 suspend.
> > >
> > > If that's the case I think you should disable CONFIG_ACPI_PROCESSOR in
> > dom0
> > > before incorporating Xen specific version (the patch you tried). We don't
> want
> > > dom0 to play with Cx directly b/c it's the responsibility of Xen.
> >
> > Huh? You misunderstood me. The 'acpi_processor_idle' is the hypervisor's
> > idle loop. It can be running inside of that one, or the 'default_idle' loop. Hence
> 
> running inside which one? I'd think only default_idle invokes it when current cpu
> is actually idle.
> 
> > my question why would that specific hypervisor idle loop make dom0 run
> nicely
> > while the default one would not.
> 
> this is counterintuitive to me honestly speaking. I'd more think that
> acpi_processor_idle may cause some issue than pure "sti;hlt" because acpi
> version has more logic to handle. In earlier day when it's still in stabilization
> phase, we did observe some non-exit case from deep Cstate but this never
> happens on pure hlt.
> 
> IOW, I don't take this idle path as a necessary step to make S3 resume working,
> which is simply related when the cpu has nothing to do...
> 
> >
> > In dom0, irregardless of the patches, the 'default_idle' is run which makes the
> > xen_safe_halt paravirt call.
> 
> OK, that matches my expectation then.
> 
> >
> > >
> > > Of course we still need figure out why same issues occur with cpuidle=0/
> > > cpufreq=none, which however can be revisited after the basic S3 works. :-)
> >
> > Right. The end result of those parameters is that the 'default_idle' in the
> > hypervisor is choosen instead of the 'acpi_processor_idle' one.
> > >
> > > >
> > > > Any ideas?
> > >
> > > No other ideas for now. From historical view Xen S3 was supported before
> >
> > Hmm, I am actually tempted to start commenting out code in the
> > acpi_processor_idle
> > and seeing what will cause it to have the same failure as 'default_idle'.
> 
> you can also try "max_cstates=1" to see any difference, which is expected to
> has similar effect as safe_halt().
> 
> Thanks
> Kevin
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: RE: Question about Xen S3 and resume code - Linux dom0 never exits the xen_safe_halt hypercall after resume

[Konrad Rzeszutek Wilk]

On Thu, Jun 30, 2011 at 01:34:27PM +0800, Tian, Kevin wrote:
> Hi, Konrad,
> 
> any update on this S3 problem you're seeing?

I removed the i915, the USB, and didn't have any WARN or such in the
bootup. But it still would not get back to the Linux dom0 after a resume.

(http://darnok.org/xen/devel-acpi-s1-no-i915-no-usb.log)

> 
> I just got a chance to give a try on my Dell core-i7 platform with a Ubuntu 10.10
> system. 
> 
> Xen version is:
> changeset:   23632:33717472f37e
> tag:         tip
> user:        Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> date:        Tue Jun 28 18:15:44 2011 +0100
> summary:     libxc: Squash xc_e820.h (and delete) into xenctrl.h
> 
> for dom0 I use origin/master plus ACPI patches queued on your origin/devel/acpi-s3.v0:

<nods> OK, so the working branch.

> commit 4aa69dc48e031276b4d771dcb227d553fd3def0b
> Merge: df5b2b6 9f90a3b
> Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date:   Tue Jun 21 09:34:31 2011 -0400
> 
>     Merge branch '3.0-rc1-rem_pg_reserve-4' of git://xenbits.xen.org/people/sstabellini/linux-pvhvm
> 
> w/ or w/o ACPI processor patches on my box ACPI S3 just works well.

And without the ACPI proccessor. What 'Dell Core i7' box is this? Let me try to get the
OptiPlex 780 I've here and see how it fares. Did you use any fancy patches for the AMT?

Re: RE: Question about Xen S3 and resume code - Linux dom0 never exits the xen_safe_halt hypercall after resume

[Konrad Rzeszutek Wilk]

> > w/ or w/o ACPI processor patches on my box ACPI S3 just works well.
> 
> And without the ACPI proccessor. What 'Dell Core i7' box is this? Let me try to get the
> OptiPlex 780 I've here and see how it fares. Did you use any fancy patches for the AMT?

Tried it on a Dell Optiplex 780 and found out that if I use Xen 4.1.1 (but not
Xen-unstable) it suspends and resumes just fine. Albeit I had trouble with the Intel AMT
but that could be related to something else.

Anyhow going to try this on the SandyBridge box I saw this issue the first time
and I will stick the Xen 4.1.1 instead of Xen unstable on it.

RE: RE: Question about Xen S3 and resume code - Linux dom0 never exits the xen_safe_halt hypercall after resume

[Tian, Kevin]

> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: Friday, July 01, 2011 6:13 AM
> 
> > > w/ or w/o ACPI processor patches on my box ACPI S3 just works well.
> >
> > And without the ACPI proccessor. What 'Dell Core i7' box is this? Let me try to
> get the
> > OptiPlex 780 I've here and see how it fares. Did you use any fancy patches for
> the AMT?
> 
> Tried it on a Dell Optiplex 780 and found out that if I use Xen 4.1.1 (but not
> Xen-unstable) it suspends and resumes just fine. Albeit I had trouble with the
> Intel AMT
> but that could be related to something else.

that's good news. at least you have a stable environment now when you work on
upstreaming it. :-)

> 
> Anyhow going to try this on the SandyBridge box I saw this issue the first time
> and I will stick the Xen 4.1.1 instead of Xen unstable on it.

that's fine. I'll see whether I can find other boxes with same issue as you observed.

Thanks
Kevin

RE: RE: Question about Xen S3 and resume code - Linux dom0 never exits the xen_safe_halt hypercall after resume

[Tian, Kevin]

> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: Friday, July 01, 2011 12:31 AM
> 
> On Thu, Jun 30, 2011 at 01:34:27PM +0800, Tian, Kevin wrote:
> > Hi, Konrad,
> >
> > any update on this S3 problem you're seeing?
> 
> I removed the i915, the USB, and didn't have any WARN or such in the
> bootup. But it still would not get back to the Linux dom0 after a resume.
> 
> (http://darnok.org/xen/devel-acpi-s1-no-i915-no-usb.log)

S3 is a very fragile feature which highly depends on the platform implementation.
I'd more think there's a driver related resume issue which is incompatible with
Xen in the resume path. I can't tell why w/ ACPI processor driver it can forward
progress... perhaps due to more timer activity e.g. from cpufreq timer which
kicks some hanging point...

> 
> >
> > I just got a chance to give a try on my Dell core-i7 platform with a Ubuntu
> 10.10
> > system.
> >
> > Xen version is:
> > changeset:   23632:33717472f37e
> > tag:         tip
> > user:        Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > date:        Tue Jun 28 18:15:44 2011 +0100
> > summary:     libxc: Squash xc_e820.h (and delete) into xenctrl.h
> >
> > for dom0 I use origin/master plus ACPI patches queued on your
> origin/devel/acpi-s3.v0:
> 
> <nods> OK, so the working branch.
> 
> > commit 4aa69dc48e031276b4d771dcb227d553fd3def0b
> > Merge: df5b2b6 9f90a3b
> > Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > Date:   Tue Jun 21 09:34:31 2011 -0400
> >
> >     Merge branch '3.0-rc1-rem_pg_reserve-4' of
> git://xenbits.xen.org/people/sstabellini/linux-pvhvm
> >
> > w/ or w/o ACPI processor patches on my box ACPI S3 just works well.
> 
> And without the ACPI proccessor. What 'Dell Core i7' box is this? Let me try to
> get the
> OptiPlex 780 I've here and see how it fares. Did you use any fancy patches for
> the AMT?

Have to say I lose the actual name for this box. It's a "studio xps" model, with
cpu as "core i7 870 (2.93G)"

there's no AMT related BIOS option on this box, and thus I don't use any other
patches aside. :-)

Thanks
Kevin