| Message ID | 1412339576-17972-1-git-send-email-matt@console-pimps.org |
|---|---|
| State | Accepted |
| Headers | show |
On Fri, 2014-10-03 at 13:32 +0100, Matt Fleming wrote: > From: Matt Fleming <matt.fleming@intel.com> > > 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 <msalter@redhat.com> > Cc: Dave Young <dyoung@redhat.com> > Cc: Alessandro Zummo <a.zummo@towertech.it> > Signed-off-by: Matt Fleming <matt.fleming@intel.com> > --- Acked-by: Mark Salter <msalter@redhat.com> > > 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 <matt.fleming@intel.com> > > > > 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 <msalter@redhat.com> > > Cc: Dave Young <dyoung@redhat.com> > > Cc: Alessandro Zummo <a.zummo@towertech.it> > > Signed-off-by: Matt Fleming <matt.fleming@intel.com> > > --- > > Acked-by: Mark Salter <msalter@redhat.com> > > > 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 > majordomo@vger.kernel.org > 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?
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...).
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 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
> > 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 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...
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...
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.