於 四，2014-03-13 於 09:12 +0100，Thomas Gleixner 提到：
> On Thu, 13 Mar 2014, joeyli wrote:
> > 於 三，2014-03-12 於 20:59 -0700，H. Peter Anvin 提到：
> > > On 03/12/2014 08:55 PM, joeyli wrote:
> > > >
> > > > So do not care "CMOS RTC Not Present", if TAD is present then we use it
> > > > instead of CMOS RTC
On Thu, 13 Mar 2014, joeyli wrote:
> 於 三，2014-03-12 於 20:59 -0700，H. Peter Anvin 提到：
> > On 03/12/2014 08:55 PM, joeyli wrote:
> > >
> > > So do not care "CMOS RTC Not Present", if TAD is present then we use it
> > > instead of CMOS RTC in all kernel code? or we still can use CMOS RTC?
> > >
> >
於 三，2014-03-12 於 20:59 -0700，H. Peter Anvin 提到：
> On 03/12/2014 08:55 PM, joeyli wrote:
> >
> > So do not care "CMOS RTC Not Present", if TAD is present then we use it
> > instead of CMOS RTC in all kernel code? or we still can use CMOS RTC?
> >
>
> Why would we use *both*!? How would that poss
On 03/12/2014 08:55 PM, joeyli wrote:
>
> So do not care "CMOS RTC Not Present", if TAD is present then we use it
> instead of CMOS RTC in all kernel code? or we still can use CMOS RTC?
>
Why would we use *both*!? How would that possibly make sense?
-hpa
--
To unsubscribe from this l
於 三，2014-03-12 於 20:11 -0700，H. Peter Anvin 提到：
> On 03/12/2014 07:38 PM, joeyli wrote:
> >
> > I sent rtc-acpitad driver for RTC subsystem on last month, I will send
> > second version.
> >
> > For using TAD to set wall clock is because in ACPI 5.0 spec, there have
> > a "CMOS RTC Not Present" f
On 03/12/2014 05:54 PM, Thomas Gleixner wrote:
>
> From the timekeeping POV there is absolutely no need to set the wall
> clock time early. The kernel boot phase does not care about wall time
> at all. We should have it done before we hit userspace, but not even
> that is a hard requirement.
>
T
On 03/12/2014 07:38 PM, joeyli wrote:
>
> I sent rtc-acpitad driver for RTC subsystem on last month, I will send
> second version.
>
> For using TAD to set wall clock is because in ACPI 5.0 spec, there have
> a "CMOS RTC Not Present" flag in FADT to indicate OSPM should use TAD
> when this flag s
於 四，2014-03-13 於 00:49 +0100，Thomas Gleixner 提到：
> On Thu, 13 Mar 2014, Rafael J. Wysocki wrote:
> > I agree, and we need to fix that for 3.14. Patch is appended.
>
> You beat me by a few minutes. Was about to send out the same, just
> with a more spicy changelog :)
>
> > ---
> > From: Rafael J.
於 四，2014-03-13 於 01:54 +0100，Thomas Gleixner 提到：
> On Thu, 13 Mar 2014, Rafael J. Wysocki wrote:
> > Thus follow the original idea to execute acpi_early_init() before
> > efi_enter_virtual_mode() to help the EFI people for now and we can
> > revisit the other problem that commit 73f7d1ca3263 attemp
On Thu, 13 Mar 2014, Thomas Gleixner wrote:
> On Thu, 13 Mar 2014, Rafael J. Wysocki wrote:
> > Thus follow the original idea to execute acpi_early_init() before
> > efi_enter_virtual_mode() to help the EFI people for now and we can
> > revisit the other problem that commit 73f7d1ca3263 attempted
On Thu, 13 Mar 2014, Rafael J. Wysocki wrote:
> Thus follow the original idea to execute acpi_early_init() before
> efi_enter_virtual_mode() to help the EFI people for now and we can
> revisit the other problem that commit 73f7d1ca3263 attempted to
> address in the future (if really necessary).
It
On Thursday, March 13, 2014 12:49:07 AM Thomas Gleixner wrote:
> On Thu, 13 Mar 2014, Rafael J. Wysocki wrote:
> > I agree, and we need to fix that for 3.14. Patch is appended.
>
> You beat me by a few minutes. Was about to send out the same, just
> with a more spicy changelog :)
>
> > ---
> > F
On Thu, 13 Mar 2014, Rafael J. Wysocki wrote:
> I agree, and we need to fix that for 3.14. Patch is appended.
You beat me by a few minutes. Was about to send out the same, just
with a more spicy changelog :)
> ---
> From: Rafael J. Wysocki
> Subject: ACPI / init: Invoke early ACPI initializatio
On Wednesday, March 12, 2014 05:39:15 PM Thomas Gleixner wrote:
> On Wed, 12 Mar 2014, Thomas Gleixner wrote:
> > On Wed, 12 Mar 2014, Thomas Gleixner wrote:
> >
> > > On Wed, 12 Mar 2014, joeyli wrote:
> > > > I think maybe still using ACPI_FADT_NO_CMOS_RTC to check does
> > > > acpi_early_init()
On Wed, 12 Mar 2014, Thomas Gleixner wrote:
> On Wed, 12 Mar 2014, Thomas Gleixner wrote:
>
> > On Wed, 12 Mar 2014, joeyli wrote:
> > > I think maybe still using ACPI_FADT_NO_CMOS_RTC to check does
> > > acpi_early_init() need run before timekeeping_init().
> > > If there have any future machine
On Wed, 12 Mar 2014, Thomas Gleixner wrote:
> On Wed, 12 Mar 2014, joeyli wrote:
> > I think maybe still using ACPI_FADT_NO_CMOS_RTC to check does
> > acpi_early_init() need run before timekeeping_init().
> > If there have any future machine that applied ACPI TAD but "Fast TSC
> > calibration" f
On Wed, 12 Mar 2014, joeyli wrote:
> I think maybe still using ACPI_FADT_NO_CMOS_RTC to check does
> acpi_early_init() need run before timekeeping_init().
> If there have any future machine that applied ACPI TAD but "Fast TSC
> calibration" fail, at least the alternate TSC calibration can work
> ar
Hi Rafael,
於 三，2014-03-12 於 14:30 +0100，Rafael J. Wysocki 提到：
> > But I wonder: Can we simply enable SCI later? In other words, can
> we
> > split acpi_early_init() so that the part before
> acpi_enable_subsystem()
> > is done before timekeeping_init() and the part including and after
> > is don
於 三，2014-03-12 於 12:20 +0100，Rafael J. Wysocki 提到：
> On Wednesday, March 12, 2014 12:00:07 PM joeyli wrote:
> > Hi Julian,
[...]
> >
> >
> > >From 8ef4fff76dd2f50bef1e8eb9c96f3b0228a38401 Mon Sep 17 00:00:00 2001
> > From: Lee, Chun-Yi
> > Date: Wed, 12 Mar 2014 11:36:32 +0800
> > Subject: [PAT
> > But I wonder: Can we simply enable SCI later? In other words, can
> > we split acpi_early_init() so that the part before
> > acpi_enable_subsystem() is done before timekeeping_init() and the
> > part including and after is done right after anon_vma_init()?
> > Would the TAD initialization work
於 三，2014-03-12 於 11:20 +0100，Julian Wollrath 提到：
> > This patch restricts the position to run acpi_early_init() before
> > timekeeping_init() when only "CMOS RTC Not Present" bit set in FADT.
> >
> > Could you please help to test it on your machine?
> That patch fixes the problem, thank you.
>
>
On Wednesday, March 12, 2014 12:20:02 PM Rafael J. Wysocki wrote:
> On Wednesday, March 12, 2014 12:00:07 PM joeyli wrote:
> > Hi Julian,
> >
> > 於 二，2014-03-11 於 18:15 +0100，Julian Wollrath 提到：
> > > Am Tue, 11 Mar 2014 14:56:41 +0100 (CET)
> > > schrieb Thomas Gleixner :
> > > > > Ok, via bisec
On Wednesday, March 12, 2014 12:00:07 PM joeyli wrote:
> Hi Julian,
>
> 於 二，2014-03-11 於 18:15 +0100，Julian Wollrath 提到：
> > Am Tue, 11 Mar 2014 14:56:41 +0100 (CET)
> > schrieb Thomas Gleixner :
> > > > Ok, via bisecting I found commit
> > > > 73f7d1ca32638028e3271f54616773727e2f9f26 (see below)
> This patch restricts the position to run acpi_early_init() before
> timekeeping_init() when only "CMOS RTC Not Present" bit set in FADT.
>
> Could you please help to test it on your machine?
That patch fixes the problem, thank you.
Cheers,
Julian Wollrath
>
>
> Thanks a lot!
> Joey Lee
>
>
Hi Julian,
於 二，2014-03-11 於 18:15 +0100，Julian Wollrath 提到：
> Am Tue, 11 Mar 2014 14:56:41 +0100 (CET)
> schrieb Thomas Gleixner :
> > > Ok, via bisecting I found commit
> > > 73f7d1ca32638028e3271f54616773727e2f9f26 (see below) to be the one
> > > that introduced this regression.
> >
> > Intere
Am Tue, 11 Mar 2014 14:56:41 +0100 (CET)
schrieb Thomas Gleixner :
> > Ok, via bisecting I found commit
> > 73f7d1ca32638028e3271f54616773727e2f9f26 (see below) to be the one
> > that introduced this regression.
>
> Interesting. I have no idea what's going on. But maybe can the ACPI
> folks shed s
On Tue, 11 Mar 2014, Paul Bolle wrote:
> On Mon, 2014-03-10 at 21:50 +0100, Thomas Gleixner wrote:
> > Dammit no. We want to know WHY!
>
> Here I am one and half year after reporting seeing this error. I'm not
> aware of anyone reporting it before me. Anyhow, I don't think things
> were working fi
On Tue, 11 Mar 2014, Julian Wollrath wrote:
> Am Mon, 10 Mar 2014 11:39:44 +0100 (CET)
> schrieb Thomas Gleixner :
> > And that definitely does not affect the quick calibration. No idea,
> > except bisecting.
> Ok, via bisecting I found commit
> 73f7d1ca32638028e3271f54616773727e2f9f26 (see below)
Am Mon, 10 Mar 2014 11:39:44 +0100 (CET)
schrieb Thomas Gleixner :
> And that definitely does not affect the quick calibration. No idea,
> except bisecting.
Ok, via bisecting I found commit
73f7d1ca32638028e3271f54616773727e2f9f26 (see below) to be the one that
introduced this regression.
Cheers,
Am Mon, 10 Mar 2014 16:28:34 +0100
schrieb Paul Bolle :
> So I'm basically advising Julian to
> double check whether this is really a change in behavior between
> v3.13 and v3.14-rc1. But perhaps Julian already did.
Yes, I did and it happens reliably on every boot with v3.14-rc1.
Cheers,
Julian W
On Mon, 2014-03-10 at 21:50 +0100, Thomas Gleixner wrote:
> On Mon, 10 Mar 2014, Paul Bolle wrote:
> > So could you please consider downgrading this message?
> >
> > Yes, this will make regressions less visible, although I'm unsure we're
> > actually seeing a regression here. But I think that this
On Mon, 10 Mar 2014, Paul Bolle wrote:
> Thomas Gleixner schreef op ma 10-03-2014 om 19:57 [+0100]:
> > On Mon, 10 Mar 2014, Paul Bolle wrote:
> > >
> > > Or is there a way to handle the "SMI nonsense" (whatever that may be)?
> >
> > No, there is none. That's "value add" from the BIOS/board manuf
Thomas Gleixner schreef op ma 10-03-2014 om 19:57 [+0100]:
> On Mon, 10 Mar 2014, Paul Bolle wrote:
> >
> > Or is there a way to handle the "SMI nonsense" (whatever that may be)?
>
> No, there is none. That's "value add" from the BIOS/board manufacturer
> which utilizes the System Management Inte
On Mon, 10 Mar 2014, Paul Bolle wrote:
>
> Or is there a way to handle the "SMI nonsense" (whatever that may be)?
No, there is none. That's "value add" from the BIOS/board manufacturer
which utilizes the System Management Interrupt and steals CPU time
from the OS.
Thanks,
tglx
--
To uns
[Added Jerome, who submitted a patch similar to mine.]
On Mon, 2014-03-10 at 18:04 +0100, Thomas Gleixner wrote:
> On Mon, 10 Mar 2014, Paul Bolle wrote:
> > https://lkml.org/lkml/2012/9/24/221 . Is that analysis incorrect?
>
> Kinda. But there is no reason for the fast calibration to fail except
On Mon, 10 Mar 2014, Paul Bolle wrote:
> On Mon, 2014-03-10 at 15:06 +0100, Thomas Gleixner wrote:
> > And how is this related to Julians observation, that fast calibration
> > works in 3.13, but stopped to work in 3.14-rc ?
>
> In the rest of my message - which you didn't quote - I stated that "
On Mon, 2014-03-10 at 15:06 +0100, Thomas Gleixner wrote:
> And how is this related to Julians observation, that fast calibration
> works in 3.13, but stopped to work in 3.14-rc ?
In the rest of my message - which you didn't quote - I stated that "the
error need not be v3.14-rc1 specific. But perh
On Mon, 10 Mar 2014, Paul Bolle wrote:
> On Mon, 2014-03-10 at 11:04 +0100, Julian Wollrath wrote:
> > on a Thinkpad x121e (AMD E-450 APU) with version 3.13.5 and earlier of
> > the kernel I get:
> > [...]
> > [0.00] tsc: Fast TSC calibration using PIT
> > [0.001000] tsc: Detected 1646
On Mon, 10 Mar 2014, Julian Wollrath wrote:
> on a Thinkpad x121e (AMD E-450 APU) with version 3.13.5 and earlier of
> the kernel I get:
> [...]
> [0.00] tsc: Fast TSC calibration using PIT
> [0.001000] tsc: Detected 1646.619 MHz processor
> [0.04] Calibrating delay loop (skippe
On Mon, 2014-03-10 at 11:04 +0100, Julian Wollrath wrote:
> on a Thinkpad x121e (AMD E-450 APU) with version 3.13.5 and earlier of
> the kernel I get:
> [...]
> [0.00] tsc: Fast TSC calibration using PIT
> [0.001000] tsc: Detected 1646.619 MHz processor
> [0.04] Calibrating dela
Hi,
on a Thinkpad x121e (AMD E-450 APU) with version 3.13.5 and earlier of
the kernel I get:
[...]
[0.00] tsc: Fast TSC calibration using PIT
[0.001000] tsc: Detected 1646.619 MHz processor
[0.04] Calibrating delay loop (skipped), value calculated using
timer frequency.. 3293.2
41 matches
Mail list logo
