From: Matt Fleming <[email protected]>
commit da167ad7638759 ("rtc: ia64: allow other architectures to use EFI
RTC") inadvertently introduced a regression for x86. We've been careful
not to enable the EFI rtc driver for x86 due to the generally buggy
implementations of the time-related EFI runtime services.
Previous attempts have been made to us the time EFI services, but all
have eventually been reverted due to crashes inside the firmware code.
In fact, since the above commit was merged we've seen reports of crashes
on 32-bit tablets,
https://bugzilla.kernel.org/show_bug.cgi?id=84241#c21
Disable it explicitly for x86 so that we don't give users false hope
that this driver will work - it won't, and your machine is likely to
crash.
Cc: Mark Salter <[email protected]>
Cc: Dave Young <[email protected]>
Cc: Alessandro Zummo <[email protected]>
Signed-off-by: Matt Fleming <[email protected]>
---
Unless anyone objects, I'm happy to take this through the EFI tree.
drivers/rtc/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index a168e96142b9..54ef393b0def 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -806,7 +806,7 @@ config RTC_DRV_DA9063
config RTC_DRV_EFI
tristate "EFI RTC"
- depends on EFI
+ depends on EFI && !X86
help
If you say yes here you will get support for the EFI
Real Time Clock.
--
1.9.3
On Fri, 2014-10-03 at 13:32 +0100, Matt Fleming wrote:
> From: Matt Fleming <[email protected]>
>
> commit da167ad7638759 ("rtc: ia64: allow other architectures to use EFI
> RTC") inadvertently introduced a regression for x86. We've been careful
> not to enable the EFI rtc driver for x86 due to the generally buggy
> implementations of the time-related EFI runtime services.
>
> Previous attempts have been made to us the time EFI services, but all
> have eventually been reverted due to crashes inside the firmware code.
>
> In fact, since the above commit was merged we've seen reports of crashes
> on 32-bit tablets,
>
> https://bugzilla.kernel.org/show_bug.cgi?id=84241#c21
>
> Disable it explicitly for x86 so that we don't give users false hope
> that this driver will work - it won't, and your machine is likely to
> crash.
>
> Cc: Mark Salter <[email protected]>
> Cc: Dave Young <[email protected]>
> Cc: Alessandro Zummo <[email protected]>
> Signed-off-by: Matt Fleming <[email protected]>
> ---
Acked-by: Mark Salter <[email protected]>
>
> Unless anyone objects, I'm happy to take this through the EFI tree.
>
> drivers/rtc/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> index a168e96142b9..54ef393b0def 100644
> --- a/drivers/rtc/Kconfig
> +++ b/drivers/rtc/Kconfig
> @@ -806,7 +806,7 @@ config RTC_DRV_DA9063
>
> config RTC_DRV_EFI
> tristate "EFI RTC"
> - depends on EFI
> + depends on EFI && !X86
> help
> If you say yes here you will get support for the EFI
> Real Time Clock.
On Friday 03 October 2014 17:01:57 Mark Salter wrote:
> On Fri, 2014-10-03 at 13:32 +0100, Matt Fleming wrote:
> > From: Matt Fleming <[email protected]>
> >
> > commit da167ad7638759 ("rtc: ia64: allow other architectures
> > to use EFI RTC") inadvertently introduced a regression for
> > x86. We've been careful not to enable the EFI rtc driver
> > for x86 due to the generally buggy implementations of the
> > time-related EFI runtime services.
> >
> > Previous attempts have been made to us the time EFI
> > services, but all have eventually been reverted due to
> > crashes inside the firmware code.
> >
> > In fact, since the above commit was merged we've seen
> > reports of crashes on 32-bit tablets,
> >
> > https://bugzilla.kernel.org/show_bug.cgi?id=84241#c21
> >
> > Disable it explicitly for x86 so that we don't give users
> > false hope that this driver will work - it won't, and your
> > machine is likely to crash.
> >
> > Cc: Mark Salter <[email protected]>
> > Cc: Dave Young <[email protected]>
> > Cc: Alessandro Zummo <[email protected]>
> > Signed-off-by: Matt Fleming <[email protected]>
> > ---
>
> Acked-by: Mark Salter <[email protected]>
>
> > Unless anyone objects, I'm happy to take this through the
> > EFI tree.
> >
> > drivers/rtc/Kconfig | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> > index a168e96142b9..54ef393b0def 100644
> > --- a/drivers/rtc/Kconfig
> > +++ b/drivers/rtc/Kconfig
> > @@ -806,7 +806,7 @@ config RTC_DRV_DA9063
> >
> > config RTC_DRV_EFI
> >
> > tristate "EFI RTC"
> >
> > - depends on EFI
> > + depends on EFI && !X86
> >
> > help
> >
> > If you say yes here you will get support for the EFI
> > Real Time Clock.
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in the body of a message to
> [email protected]
> More majordomo info at
> http://vger.kernel.org/majordomo-info.html Please read the
> FAQ at http://www.tux.org/lkml/
Hello,
this patch totally disabled efi rfc driver on x86 machines at
compile time. But on some x86 machines it working without crash
and reading from file /sys/class/rtc/rtc*/since_epoch returns
correct information. So why to disable compiling driver on
machines where driver working?
--
Pali Rohár
[email protected]
On Sun, Nov 09, 2014 at 06:37:46PM +0100, Pali Rohár wrote:
> this patch totally disabled efi rfc driver on x86 machines at
> compile time. But on some x86 machines it working without crash
> and reading from file /sys/class/rtc/rtc*/since_epoch returns
> correct information. So why to disable compiling driver on
> machines where driver working?
Sounds like we need an efi=rtc_enable knob for people who what to use
it...
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
On Sun, 2014-11-09 at 19:22 +0100, Borislav Petkov wrote:
> On Sun, Nov 09, 2014 at 06:37:46PM +0100, Pali Rohár wrote:
> > this patch totally disabled efi rfc driver on x86 machines at
> > compile time. But on some x86 machines it working without crash
> > and reading from file /sys/class/rtc/rtc*/since_epoch returns
> > correct information. So why to disable compiling driver on
> > machines where driver working?
>
> Sounds like we need an efi=rtc_enable knob for people who what to use
> it...
I'm not so sure. By and large, the EFI runtime Time services just don't
work very well on x86. Just because they work sometimes, doesn't
actually mean it's a good idea to use them.
The one scenario where the time services are useful is early on during
boot when we want to get the timezone information. I have vague
recollections of someone working on that.
On Monday 10 November 2014 12:22:13 Matt Fleming wrote:
> On Sun, 2014-11-09 at 19:22 +0100, Borislav Petkov wrote:
> > On Sun, Nov 09, 2014 at 06:37:46PM +0100, Pali Rohár wrote:
> > > this patch totally disabled efi rfc driver on x86 machines
> > > at compile time. But on some x86 machines it working
> > > without crash and reading from file
> > > /sys/class/rtc/rtc*/since_epoch returns correct
> > > information. So why to disable compiling driver on
> > > machines where driver working?
> >
> > Sounds like we need an efi=rtc_enable knob for people who
> > what to use it...
>
> I'm not so sure. By and large, the EFI runtime Time services
> just don't work very well on x86. Just because they work
> sometimes, doesn't actually mean it's a good idea to use
> them.
>
> The one scenario where the time services are useful is early
> on during boot when we want to get the timezone information.
> I have vague recollections of someone working on that.
On laptop Dell Latitude E6440 with 64bit kernel 3.17-rc6 (where
was rtc-efi.ko enabled at compile time for x86) it working fine
without crash. So I think that other Dell machines could work
too.
Maybe problems which were reported are only specific for 32bit
UEFI? Or 32bit kernels?
And I think that if I know that efi time service working on
machine, I should be able to use it with mainline kernel (without
hacking Kconfig to enable it and so...).
--
Pali Rohár
[email protected]
On 2014-11-10 11:23, Pali Rohár wrote:
> On Monday 10 November 2014 12:22:13 Matt Fleming wrote:
>> On Sun, 2014-11-09 at 19:22 +0100, Borislav Petkov wrote:
>>> On Sun, Nov 09, 2014 at 06:37:46PM +0100, Pali Rohár wrote:
>>>> this patch totally disabled efi rfc driver on x86 machines
>>>> at compile time. But on some x86 machines it working
>>>> without crash and reading from file
>>>> /sys/class/rtc/rtc*/since_epoch returns correct
>>>> information. So why to disable compiling driver on
>>>> machines where driver working?
>>>
>>> Sounds like we need an efi=rtc_enable knob for people who
>>> what to use it...
>>
>> I'm not so sure. By and large, the EFI runtime Time services
>> just don't work very well on x86. Just because they work
>> sometimes, doesn't actually mean it's a good idea to use
>> them.
>>
>> The one scenario where the time services are useful is early
>> on during boot when we want to get the timezone information.
>> I have vague recollections of someone working on that.
>
> On laptop Dell Latitude E6440 with 64bit kernel 3.17-rc6 (where
> was rtc-efi.ko enabled at compile time for x86) it working fine
> without crash. So I think that other Dell machines could work
> too.
>
I can also confirm that it works correctly on a number of ASUS and
ASrock desktop motherboards with the most recent BIOS updates, and on a
Lenovo Thinkpad L540. I can however confirm that it DOES NOT work
however on an Acer Aspire V5-131 system, though I had never updated the
BIOS on that one, so it may work correctly with a newer BIOS version.
> Maybe problems which were reported are only specific for 32bit
> UEFI? Or 32bit kernels?
>
> And I think that if I know that efi time service working on
> machine, I should be able to use it with mainline kernel (without
> hacking Kconfig to enable it and so...).
>
I agree, without it you need PC CMOS RTC support to access the RTC on
most systems, which in turn means that you have to enable the CSM in the
EFI firmware, which is annoying cause you can't easily dual boot windows
with secure boot when the CSM is enabled.
On Mon, Nov 10, 2014 at 11:45:06AM -0500, Austin S Hemmelgarn wrote:
> I agree, without it you need PC CMOS RTC support to access the RTC
> on most systems, which in turn means that you have to enable the CSM
> in the EFI firmware, which is annoying cause you can't easily dual
> boot windows with secure boot when the CSM is enabled.
CMOS RTC support doesn't depend on the CSM.
--
Matthew Garrett | [email protected]
On 2014-11-10 12:04, Matthew Garrett wrote:
> On Mon, Nov 10, 2014 at 11:45:06AM -0500, Austin S Hemmelgarn wrote:
>
>> I agree, without it you need PC CMOS RTC support to access the RTC
>> on most systems, which in turn means that you have to enable the CSM
>> in the EFI firmware, which is annoying cause you can't easily dual
>> boot windows with secure boot when the CSM is enabled.
>
> CMOS RTC support doesn't depend on the CSM.
>
That's really interesting, because with it compiled in, I can't boot on
my EFI based thinkpad laptop without telling EFI to launch the CSM, and
with it compiled out, I can boot fine without the CSM. I'll have to
look further into the options I have set in my kernel build, I may have
changed something else without remembering between booting with and
without the CSM enabled.
On 11/10/2014 12:37 PM, Austin S Hemmelgarn wrote:
> On 2014-11-10 12:04, Matthew Garrett wrote:
>> On Mon, Nov 10, 2014 at 11:45:06AM -0500, Austin S Hemmelgarn wrote:
>>
>>> I agree, without it you need PC CMOS RTC support to access the RTC
>>> on most systems, which in turn means that you have to enable the CSM
>>> in the EFI firmware, which is annoying cause you can't easily dual
>>> boot windows with secure boot when the CSM is enabled.
>>
>> CMOS RTC support doesn't depend on the CSM.
>>
> That's really interesting, because with it compiled in, I can't boot on
> my EFI based thinkpad laptop without telling EFI to launch the CSM, and
> with it compiled out, I can boot fine without the CSM. I'll have to
> look further into the options I have set in my kernel build, I may have
> changed something else without remembering between booting with and
> without the CSM enabled.
>
It could also be that the non-CSM BIOS somehow remaps the CMOS registers.
-hpa
On Mon, Nov 10, 2014 at 12:58:39PM -0800, H. Peter Anvin wrote:
> It could also be that the non-CSM BIOS somehow remaps the CMOS registers.
We should be getting that information from ACPI - cmos_pnp_probe()
doesn't have hardcoded assumptions about registers.
--
Matthew Garrett | [email protected]
> > look further into the options I have set in my kernel build, I may have
> > changed something else without remembering between booting with and
> > without the CSM enabled.
> >
>
> It could also be that the non-CSM BIOS somehow remaps the CMOS registers.
I don't believe there is anything which prevents the CSM from faking a
CMOS clock using SMM from whatever is actually in the hardware.
Alan
On Tue, Nov 11, 2014 at 11:38:31AM +0000, One Thousand Gnomes wrote:
> I don't believe there is anything which prevents the CSM from faking a
> CMOS clock using SMM from whatever is actually in the hardware.
HPET in SMM? Oh, sure, definitely.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
On Tuesday 11 November 2014 12:38:31 One Thousand Gnomes wrote:
> > > look further into the options I have set in my kernel
> > > build, I may have changed something else without
> > > remembering between booting with and without the CSM
> > > enabled.
> >
> > It could also be that the non-CSM BIOS somehow remaps the
> > CMOS registers.
>
> I don't believe there is anything which prevents the CSM from
> faking a CMOS clock using SMM from whatever is actually in
> the hardware.
>
> Alan
Also in case when we do not know what SMM code is doing...
--
Pali Rohár
[email protected]
On 2014-11-11 06:38, One Thousand Gnomes wrote:
>>> look further into the options I have set in my kernel build, I may have
>>> changed something else without remembering between booting with and
>>> without the CSM enabled.
>>>
>>
>> It could also be that the non-CSM BIOS somehow remaps the CMOS registers.
>
> I don't believe there is anything which prevents the CSM from faking a
> CMOS clock using SMM from whatever is actually in the hardware.
>
> Alan
>
It wouldn't surprise me if that were the case. I've had some pretty
weird firmware related issues with other Lenovo systems before (like the
brightness hot-keys causing the reported trip points for ACPI thermal
zones to temporarily change).
I've rebuilt the kernel I'm using with everything I can think of
possibly depending on the CSM compiled out or as modules, so I'll
hopefully have some more info soon.
On Monday 10 November 2014 17:45:06 Austin S Hemmelgarn wrote:
> On 2014-11-10 11:23, Pali Rohár wrote:
> > On Monday 10 November 2014 12:22:13 Matt Fleming wrote:
> >> On Sun, 2014-11-09 at 19:22 +0100, Borislav Petkov wrote:
> >>> On Sun, Nov 09, 2014 at 06:37:46PM +0100, Pali Rohár wrote:
> >>>> this patch totally disabled efi rfc driver on x86
> >>>> machines at compile time. But on some x86 machines it
> >>>> working without crash and reading from file
> >>>> /sys/class/rtc/rtc*/since_epoch returns correct
> >>>> information. So why to disable compiling driver on
> >>>> machines where driver working?
> >>>
> >>> Sounds like we need an efi=rtc_enable knob for people who
> >>> what to use it...
> >>
> >> I'm not so sure. By and large, the EFI runtime Time
> >> services just don't work very well on x86. Just because
> >> they work sometimes, doesn't actually mean it's a good
> >> idea to use them.
> >>
> >> The one scenario where the time services are useful is
> >> early on during boot when we want to get the timezone
> >> information. I have vague recollections of someone working
> >> on that.
> >
> > On laptop Dell Latitude E6440 with 64bit kernel 3.17-rc6
> > (where was rtc-efi.ko enabled at compile time for x86) it
> > working fine without crash. So I think that other Dell
> > machines could work too.
>
> I can also confirm that it works correctly on a number of ASUS
> and ASrock desktop motherboards with the most recent BIOS
> updates, and on a Lenovo Thinkpad L540. I can however
> confirm that it DOES NOT work however on an Acer Aspire
> V5-131 system, though I had never updated the BIOS on that
> one, so it may work correctly with a newer BIOS version.
>
So how to solve it? I think that something like efi=rtc_enable
param is better then disabling it for x86 at compile time.
Once we figure out which machines are affected or if in future
vendors fix their firmwares it can be enabled for new machines...
--
Pali Rohár
[email protected]