kernel-packages team mailing list archive
-
kernel-packages team
-
Mailing list archive
-
Message #30231
[Bug 1252242] Re: CONFIG_RTC_DRV_PL031=m stops the kernel from setting the system time from the RTC automatically, which userspace expects
** Description changed:
+ SRU Justification:
+
+ Impact: the Linux kernel resets the wall clock (RTC_HCTOSYS=y) using the
+ value read from a specific rtc device (RTC_HCTOSYS_DEVICE=rtc0) as a
+ late_initcall() (see drivers/rtc/hctosys.c::rtc_hctosys()). That implies
+ that the RTC_HCTOSYS_DEVICE must be available when rtc_hctosys() is
+ called, making all the rtc drivers that are built as a module unsuitanle
+ for this task.
+
+ dmesg:
+
+ ...
+ [ 5.396605] /home/ppisati/ubuntu-saucy/drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
+ # here is when rtc_hctosys() is called, tries to open rtc0 to read the time value bu # since the driver for this rtc is compiled as a module, it's unavailable at this # time, this it fails to read it and fails to set the wall clock
+ [ 10.609622] rtc-pl031 fff35000.rtc: rtc core: registered pl031 as rtc0
+ # later on the rtc driver is loaded, but it's too late
+ ...
+ ubuntu@m01:~$ date
+ Wed Dec 31 19:25:24 EST 1969
+
+
+ Fix: compile in the rtc driver that your board uses to set the wall clock (pl031 on calxeda) - see the attached patch
+
+ Test case:
+
+ dmesg:
+ ...
+ [ 5.303860] rtc-pl031 fff35000.rtc: rtc core: registered pl031 as rtc0
+ [ 5.421639] rtc-pl031 fff35000.rtc: setting system clock to 2013-11-19 16:47:18 UTC (1384879638)
+ ...
+
+ when the rtc driver is correctly build-in, you should see something like
+ this in your bootlog.
+
+ --
+
Working on MAAS, I see midway machines boot on Saucy with an incorrect
system time (close to epoch). I have tried various things, including
using MAAS to make sure that the hardware clock was set correctly before
installation. Despite this, I find that the hardware clock (as reported
by "hwclock --utc") is correct, yet the system time ("date --utc") is
close to epoch.
Affects: Saucy linux-image-3.11.0-13-generic-lpae 3.11.0-13.20, util-
linux 2.20.1-5.1ubuntu9.
Below is my current understanding of the root cause and possible
solutions. My understanding may not be accurate. Please correct any
inaccuracies. This is just my current understanding; all I know is that
it doesn't work :)
In userspace, util-linux via /etc/init/hwclock.conf is involved with the
RTC. But it doesn't use --hctosys. I can find nothing in userspace that
takes responsibility for setting up the system time from the RTC.
hwclock(8) says that --hctosys is "a good option to use in one of the
system startup scripts.", but also that --systz is "is an alternate
option to --hctosys that does not read the hardware clock, and may be
used in system startup scripts for recent 2.6 kernels where you
know the System Time contains the Hardware Clock time."
So it appears to me that it is the kernel that is supposed to make sure
the RTC is copied to the system clock on boot, or at least that this is
the assumption that userspace is making. It's my understanding that this
isn't happening because rtc_pl031 is a module.
I assume that an RTC module load doesn't reset the system time. Or
should it? It sounds like an evil side effect to me if it doesn't happen
on boot. Perhaps there should be or there is a module parameter to make
it do that, though? If so, I am unaware of it, or any userspace
implementation of using that.
I can see two broad solutions to this:
1) The kernel takes responsibility for doing this task, which AIUI we
can do with CONFIG_RTC_DRV_PL031=y. This was the case with the linux-
highbank package in Quantal, which I believe is why this appears to be a
regression from MAAS' perspective.
2) Userspace takes responsibility for running "hwclock --hctosys", which
case we need logic to figure out when this is necessary (AIUI, it isn't
necessary for Intel, as the RTC driver is compiled in?) and how to
arrange this.
Other options:
3) Some kind of definition of the semantics (perhaps there is one and
I'm missing it) and userspace asking the module to do it on module load,
or an hwclock command after module load or something. I am concerned
about coordinating the timing involved in this option, though.
4) fixrtc on the command line as a workaround for MAAS. This would need
us to amend flash-kernel. But this doesn't really fix the problem; a
--hctosys would still be needed to make the clock properly accurate.
ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: linux-image-3.11.0-13-generic-lpae 3.11.0-13.20
ProcVersionSignature: User Name 3.11.0-13.20-generic-lpae 3.11.6
Uname: Linux 3.11.0-13-generic-lpae armv7l
AlsaDevices:
total 0
crw-rw---- 1 root audio 116, 1 Dec 31 1969 seq
crw-rw---- 1 root audio 116, 33 Dec 31 1969 timer
AlsaVersion: Advanced Linux Sound Architecture Driver Version k3.11.0-13-generic-lpae.
AplayDevices: Error: [Errno 2] No such file or directory: 'aplay'
ApportVersion: 2.12.5-0ubuntu2.1
Architecture: armhf
ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord'
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1:
CRDA: Error: [Errno 2] No such file or directory: 'iw'
Date: Mon Nov 18 06:33:34 2013
HibernationDevice: RESUME=UUID=1337d4f1-3df8-4589-9008-a47a197b579f
IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig'
Lsusb: Error: command ['lsusb'] failed with exit code 1: unable to initialize libusb: -99
MarkForUpload: True
PciMultimedia:
ProcFB:
ProcKernelCmdLine: console=ttyAMA0 nosplash
ProcModules:
binfmt_misc 7197 1 - Live 0x00000000 (F)
rtc_pl031 4594 0 - Live 0x00000000 (F)
uio 8483 1 uio_pdrv_genirq, Live 0x00000000 (F)
uio_pdrv_genirq 3441 0 - Live 0x00000000 (F)
xgmac 18035 0 - Live 0x00000000 (F)
RelatedPackageVersions:
linux-restricted-modules-3.11.0-13-generic-lpae N/A
linux-backports-modules-3.11.0-13-generic-lpae N/A
linux-firmware 1.116
RfKill: Error: [Errno 2] No such file or directory: 'rfkill'
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
WifiSyslog:
Nov 18 06:26:32 m22 dhclient: DHCPREQUEST of 10.193.24.144 on eth0 to 10.193.37.1 port 67 (xid=0xb672694)
Nov 18 06:26:32 m22 dhclient: DHCPACK of 10.193.24.144 from 10.193.24.1
Nov 18 06:26:32 m22 dhclient: bound to 10.193.24.144 -- renewal in 3558 seconds.
** Description changed:
SRU Justification:
Impact: the Linux kernel resets the wall clock (RTC_HCTOSYS=y) using the
value read from a specific rtc device (RTC_HCTOSYS_DEVICE=rtc0) as a
late_initcall() (see drivers/rtc/hctosys.c::rtc_hctosys()). That implies
that the RTC_HCTOSYS_DEVICE must be available when rtc_hctosys() is
called, making all the rtc drivers that are built as a module unsuitanle
for this task.
dmesg:
...
[ 5.396605] /home/ppisati/ubuntu-saucy/drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
- # here is when rtc_hctosys() is called, tries to open rtc0 to read the time value bu # since the driver for this rtc is compiled as a module, it's unavailable at this # time, this it fails to read it and fails to set the wall clock
+ # rtc_hctosys() is called, it tries to open rtc0 but it's unavailable at this # time and so it fails to set the wall clock
[ 10.609622] rtc-pl031 fff35000.rtc: rtc core: registered pl031 as rtc0
# later on the rtc driver is loaded, but it's too late
...
ubuntu@m01:~$ date
Wed Dec 31 19:25:24 EST 1969
-
- Fix: compile in the rtc driver that your board uses to set the wall clock (pl031 on calxeda) - see the attached patch
+ Fix: compile in the rtc driver that your board uses to set the wall
+ clock (pl031 on calxeda) - see the attached patch
Test case:
dmesg:
...
[ 5.303860] rtc-pl031 fff35000.rtc: rtc core: registered pl031 as rtc0
[ 5.421639] rtc-pl031 fff35000.rtc: setting system clock to 2013-11-19 16:47:18 UTC (1384879638)
...
when the rtc driver is correctly build-in, you should see something like
this in your bootlog.
--
Working on MAAS, I see midway machines boot on Saucy with an incorrect
system time (close to epoch). I have tried various things, including
using MAAS to make sure that the hardware clock was set correctly before
installation. Despite this, I find that the hardware clock (as reported
by "hwclock --utc") is correct, yet the system time ("date --utc") is
close to epoch.
Affects: Saucy linux-image-3.11.0-13-generic-lpae 3.11.0-13.20, util-
linux 2.20.1-5.1ubuntu9.
Below is my current understanding of the root cause and possible
solutions. My understanding may not be accurate. Please correct any
inaccuracies. This is just my current understanding; all I know is that
it doesn't work :)
In userspace, util-linux via /etc/init/hwclock.conf is involved with the
RTC. But it doesn't use --hctosys. I can find nothing in userspace that
takes responsibility for setting up the system time from the RTC.
hwclock(8) says that --hctosys is "a good option to use in one of the
system startup scripts.", but also that --systz is "is an alternate
option to --hctosys that does not read the hardware clock, and may be
used in system startup scripts for recent 2.6 kernels where you
know the System Time contains the Hardware Clock time."
So it appears to me that it is the kernel that is supposed to make sure
the RTC is copied to the system clock on boot, or at least that this is
the assumption that userspace is making. It's my understanding that this
isn't happening because rtc_pl031 is a module.
I assume that an RTC module load doesn't reset the system time. Or
should it? It sounds like an evil side effect to me if it doesn't happen
on boot. Perhaps there should be or there is a module parameter to make
it do that, though? If so, I am unaware of it, or any userspace
implementation of using that.
I can see two broad solutions to this:
1) The kernel takes responsibility for doing this task, which AIUI we
can do with CONFIG_RTC_DRV_PL031=y. This was the case with the linux-
highbank package in Quantal, which I believe is why this appears to be a
regression from MAAS' perspective.
2) Userspace takes responsibility for running "hwclock --hctosys", which
case we need logic to figure out when this is necessary (AIUI, it isn't
necessary for Intel, as the RTC driver is compiled in?) and how to
arrange this.
Other options:
3) Some kind of definition of the semantics (perhaps there is one and
I'm missing it) and userspace asking the module to do it on module load,
or an hwclock command after module load or something. I am concerned
about coordinating the timing involved in this option, though.
4) fixrtc on the command line as a workaround for MAAS. This would need
us to amend flash-kernel. But this doesn't really fix the problem; a
--hctosys would still be needed to make the clock properly accurate.
ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: linux-image-3.11.0-13-generic-lpae 3.11.0-13.20
ProcVersionSignature: User Name 3.11.0-13.20-generic-lpae 3.11.6
Uname: Linux 3.11.0-13-generic-lpae armv7l
AlsaDevices:
total 0
crw-rw---- 1 root audio 116, 1 Dec 31 1969 seq
crw-rw---- 1 root audio 116, 33 Dec 31 1969 timer
AlsaVersion: Advanced Linux Sound Architecture Driver Version k3.11.0-13-generic-lpae.
AplayDevices: Error: [Errno 2] No such file or directory: 'aplay'
ApportVersion: 2.12.5-0ubuntu2.1
Architecture: armhf
ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord'
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1:
CRDA: Error: [Errno 2] No such file or directory: 'iw'
Date: Mon Nov 18 06:33:34 2013
HibernationDevice: RESUME=UUID=1337d4f1-3df8-4589-9008-a47a197b579f
IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig'
Lsusb: Error: command ['lsusb'] failed with exit code 1: unable to initialize libusb: -99
MarkForUpload: True
PciMultimedia:
ProcFB:
ProcKernelCmdLine: console=ttyAMA0 nosplash
ProcModules:
binfmt_misc 7197 1 - Live 0x00000000 (F)
rtc_pl031 4594 0 - Live 0x00000000 (F)
uio 8483 1 uio_pdrv_genirq, Live 0x00000000 (F)
uio_pdrv_genirq 3441 0 - Live 0x00000000 (F)
xgmac 18035 0 - Live 0x00000000 (F)
RelatedPackageVersions:
linux-restricted-modules-3.11.0-13-generic-lpae N/A
linux-backports-modules-3.11.0-13-generic-lpae N/A
linux-firmware 1.116
RfKill: Error: [Errno 2] No such file or directory: 'rfkill'
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
WifiSyslog:
Nov 18 06:26:32 m22 dhclient: DHCPREQUEST of 10.193.24.144 on eth0 to 10.193.37.1 port 67 (xid=0xb672694)
Nov 18 06:26:32 m22 dhclient: DHCPACK of 10.193.24.144 from 10.193.24.1
Nov 18 06:26:32 m22 dhclient: bound to 10.193.24.144 -- renewal in 3558 seconds.
** Description changed:
SRU Justification:
Impact: the Linux kernel resets the wall clock (RTC_HCTOSYS=y) using the
value read from a specific rtc device (RTC_HCTOSYS_DEVICE=rtc0) as a
late_initcall() (see drivers/rtc/hctosys.c::rtc_hctosys()). That implies
that the RTC_HCTOSYS_DEVICE must be available when rtc_hctosys() is
called, making all the rtc drivers that are built as a module unsuitanle
for this task.
dmesg:
...
[ 5.396605] /home/ppisati/ubuntu-saucy/drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
- # rtc_hctosys() is called, it tries to open rtc0 but it's unavailable at this # time and so it fails to set the wall clock
+ # rtc_hctosys() is called, it tries to open rtc0 but the driver is unavailable at # this time so it fails to set the system time
[ 10.609622] rtc-pl031 fff35000.rtc: rtc core: registered pl031 as rtc0
# later on the rtc driver is loaded, but it's too late
...
ubuntu@m01:~$ date
Wed Dec 31 19:25:24 EST 1969
Fix: compile in the rtc driver that your board uses to set the wall
clock (pl031 on calxeda) - see the attached patch
Test case:
dmesg:
...
[ 5.303860] rtc-pl031 fff35000.rtc: rtc core: registered pl031 as rtc0
[ 5.421639] rtc-pl031 fff35000.rtc: setting system clock to 2013-11-19 16:47:18 UTC (1384879638)
...
when the rtc driver is correctly build-in, you should see something like
this in your bootlog.
--
Working on MAAS, I see midway machines boot on Saucy with an incorrect
system time (close to epoch). I have tried various things, including
using MAAS to make sure that the hardware clock was set correctly before
installation. Despite this, I find that the hardware clock (as reported
by "hwclock --utc") is correct, yet the system time ("date --utc") is
close to epoch.
Affects: Saucy linux-image-3.11.0-13-generic-lpae 3.11.0-13.20, util-
linux 2.20.1-5.1ubuntu9.
Below is my current understanding of the root cause and possible
solutions. My understanding may not be accurate. Please correct any
inaccuracies. This is just my current understanding; all I know is that
it doesn't work :)
In userspace, util-linux via /etc/init/hwclock.conf is involved with the
RTC. But it doesn't use --hctosys. I can find nothing in userspace that
takes responsibility for setting up the system time from the RTC.
hwclock(8) says that --hctosys is "a good option to use in one of the
system startup scripts.", but also that --systz is "is an alternate
option to --hctosys that does not read the hardware clock, and may be
used in system startup scripts for recent 2.6 kernels where you
know the System Time contains the Hardware Clock time."
So it appears to me that it is the kernel that is supposed to make sure
the RTC is copied to the system clock on boot, or at least that this is
the assumption that userspace is making. It's my understanding that this
isn't happening because rtc_pl031 is a module.
I assume that an RTC module load doesn't reset the system time. Or
should it? It sounds like an evil side effect to me if it doesn't happen
on boot. Perhaps there should be or there is a module parameter to make
it do that, though? If so, I am unaware of it, or any userspace
implementation of using that.
I can see two broad solutions to this:
1) The kernel takes responsibility for doing this task, which AIUI we
can do with CONFIG_RTC_DRV_PL031=y. This was the case with the linux-
highbank package in Quantal, which I believe is why this appears to be a
regression from MAAS' perspective.
2) Userspace takes responsibility for running "hwclock --hctosys", which
case we need logic to figure out when this is necessary (AIUI, it isn't
necessary for Intel, as the RTC driver is compiled in?) and how to
arrange this.
Other options:
3) Some kind of definition of the semantics (perhaps there is one and
I'm missing it) and userspace asking the module to do it on module load,
or an hwclock command after module load or something. I am concerned
about coordinating the timing involved in this option, though.
4) fixrtc on the command line as a workaround for MAAS. This would need
us to amend flash-kernel. But this doesn't really fix the problem; a
--hctosys would still be needed to make the clock properly accurate.
ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: linux-image-3.11.0-13-generic-lpae 3.11.0-13.20
ProcVersionSignature: User Name 3.11.0-13.20-generic-lpae 3.11.6
Uname: Linux 3.11.0-13-generic-lpae armv7l
AlsaDevices:
total 0
crw-rw---- 1 root audio 116, 1 Dec 31 1969 seq
crw-rw---- 1 root audio 116, 33 Dec 31 1969 timer
AlsaVersion: Advanced Linux Sound Architecture Driver Version k3.11.0-13-generic-lpae.
AplayDevices: Error: [Errno 2] No such file or directory: 'aplay'
ApportVersion: 2.12.5-0ubuntu2.1
Architecture: armhf
ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord'
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1:
CRDA: Error: [Errno 2] No such file or directory: 'iw'
Date: Mon Nov 18 06:33:34 2013
HibernationDevice: RESUME=UUID=1337d4f1-3df8-4589-9008-a47a197b579f
IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig'
Lsusb: Error: command ['lsusb'] failed with exit code 1: unable to initialize libusb: -99
MarkForUpload: True
PciMultimedia:
ProcFB:
ProcKernelCmdLine: console=ttyAMA0 nosplash
ProcModules:
binfmt_misc 7197 1 - Live 0x00000000 (F)
rtc_pl031 4594 0 - Live 0x00000000 (F)
uio 8483 1 uio_pdrv_genirq, Live 0x00000000 (F)
uio_pdrv_genirq 3441 0 - Live 0x00000000 (F)
xgmac 18035 0 - Live 0x00000000 (F)
RelatedPackageVersions:
linux-restricted-modules-3.11.0-13-generic-lpae N/A
linux-backports-modules-3.11.0-13-generic-lpae N/A
linux-firmware 1.116
RfKill: Error: [Errno 2] No such file or directory: 'rfkill'
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
WifiSyslog:
Nov 18 06:26:32 m22 dhclient: DHCPREQUEST of 10.193.24.144 on eth0 to 10.193.37.1 port 67 (xid=0xb672694)
Nov 18 06:26:32 m22 dhclient: DHCPACK of 10.193.24.144 from 10.193.24.1
Nov 18 06:26:32 m22 dhclient: bound to 10.193.24.144 -- renewal in 3558 seconds.
** Description changed:
SRU Justification:
Impact: the Linux kernel resets the wall clock (RTC_HCTOSYS=y) using the
value read from a specific rtc device (RTC_HCTOSYS_DEVICE=rtc0) as a
late_initcall() (see drivers/rtc/hctosys.c::rtc_hctosys()). That implies
that the RTC_HCTOSYS_DEVICE must be available when rtc_hctosys() is
called, making all the rtc drivers that are built as a module unsuitanle
for this task.
dmesg:
...
[ 5.396605] /home/ppisati/ubuntu-saucy/drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
- # rtc_hctosys() is called, it tries to open rtc0 but the driver is unavailable at # this time so it fails to set the system time
+ # rtc_hctosys() is called, it tries to open rtc0 but the driver is unavailable at # this time so it fails to set the system time
[ 10.609622] rtc-pl031 fff35000.rtc: rtc core: registered pl031 as rtc0
# later on the rtc driver is loaded, but it's too late
...
ubuntu@m01:~$ date
Wed Dec 31 19:25:24 EST 1969
Fix: compile in the rtc driver that your board uses to set the wall
clock (pl031 on calxeda) - see the attached patch
Test case:
dmesg:
...
[ 5.303860] rtc-pl031 fff35000.rtc: rtc core: registered pl031 as rtc0
[ 5.421639] rtc-pl031 fff35000.rtc: setting system clock to 2013-11-19 16:47:18 UTC (1384879638)
...
when the rtc driver is correctly build-in, you should see something like
this in your bootlog.
--
Working on MAAS, I see midway machines boot on Saucy with an incorrect
system time (close to epoch). I have tried various things, including
using MAAS to make sure that the hardware clock was set correctly before
installation. Despite this, I find that the hardware clock (as reported
by "hwclock --utc") is correct, yet the system time ("date --utc") is
close to epoch.
Affects: Saucy linux-image-3.11.0-13-generic-lpae 3.11.0-13.20, util-
linux 2.20.1-5.1ubuntu9.
Below is my current understanding of the root cause and possible
solutions. My understanding may not be accurate. Please correct any
inaccuracies. This is just my current understanding; all I know is that
it doesn't work :)
In userspace, util-linux via /etc/init/hwclock.conf is involved with the
RTC. But it doesn't use --hctosys. I can find nothing in userspace that
takes responsibility for setting up the system time from the RTC.
hwclock(8) says that --hctosys is "a good option to use in one of the
system startup scripts.", but also that --systz is "is an alternate
option to --hctosys that does not read the hardware clock, and may be
used in system startup scripts for recent 2.6 kernels where you
know the System Time contains the Hardware Clock time."
So it appears to me that it is the kernel that is supposed to make sure
the RTC is copied to the system clock on boot, or at least that this is
the assumption that userspace is making. It's my understanding that this
isn't happening because rtc_pl031 is a module.
I assume that an RTC module load doesn't reset the system time. Or
should it? It sounds like an evil side effect to me if it doesn't happen
on boot. Perhaps there should be or there is a module parameter to make
it do that, though? If so, I am unaware of it, or any userspace
implementation of using that.
I can see two broad solutions to this:
1) The kernel takes responsibility for doing this task, which AIUI we
can do with CONFIG_RTC_DRV_PL031=y. This was the case with the linux-
highbank package in Quantal, which I believe is why this appears to be a
regression from MAAS' perspective.
2) Userspace takes responsibility for running "hwclock --hctosys", which
case we need logic to figure out when this is necessary (AIUI, it isn't
necessary for Intel, as the RTC driver is compiled in?) and how to
arrange this.
Other options:
3) Some kind of definition of the semantics (perhaps there is one and
I'm missing it) and userspace asking the module to do it on module load,
or an hwclock command after module load or something. I am concerned
about coordinating the timing involved in this option, though.
4) fixrtc on the command line as a workaround for MAAS. This would need
us to amend flash-kernel. But this doesn't really fix the problem; a
--hctosys would still be needed to make the clock properly accurate.
ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: linux-image-3.11.0-13-generic-lpae 3.11.0-13.20
ProcVersionSignature: User Name 3.11.0-13.20-generic-lpae 3.11.6
Uname: Linux 3.11.0-13-generic-lpae armv7l
AlsaDevices:
total 0
crw-rw---- 1 root audio 116, 1 Dec 31 1969 seq
crw-rw---- 1 root audio 116, 33 Dec 31 1969 timer
AlsaVersion: Advanced Linux Sound Architecture Driver Version k3.11.0-13-generic-lpae.
AplayDevices: Error: [Errno 2] No such file or directory: 'aplay'
ApportVersion: 2.12.5-0ubuntu2.1
Architecture: armhf
ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord'
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1:
CRDA: Error: [Errno 2] No such file or directory: 'iw'
Date: Mon Nov 18 06:33:34 2013
HibernationDevice: RESUME=UUID=1337d4f1-3df8-4589-9008-a47a197b579f
IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig'
Lsusb: Error: command ['lsusb'] failed with exit code 1: unable to initialize libusb: -99
MarkForUpload: True
PciMultimedia:
ProcFB:
ProcKernelCmdLine: console=ttyAMA0 nosplash
ProcModules:
binfmt_misc 7197 1 - Live 0x00000000 (F)
rtc_pl031 4594 0 - Live 0x00000000 (F)
uio 8483 1 uio_pdrv_genirq, Live 0x00000000 (F)
uio_pdrv_genirq 3441 0 - Live 0x00000000 (F)
xgmac 18035 0 - Live 0x00000000 (F)
RelatedPackageVersions:
linux-restricted-modules-3.11.0-13-generic-lpae N/A
linux-backports-modules-3.11.0-13-generic-lpae N/A
linux-firmware 1.116
RfKill: Error: [Errno 2] No such file or directory: 'rfkill'
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
WifiSyslog:
Nov 18 06:26:32 m22 dhclient: DHCPREQUEST of 10.193.24.144 on eth0 to 10.193.37.1 port 67 (xid=0xb672694)
Nov 18 06:26:32 m22 dhclient: DHCPACK of 10.193.24.144 from 10.193.24.1
Nov 18 06:26:32 m22 dhclient: bound to 10.193.24.144 -- renewal in 3558 seconds.
** Description changed:
SRU Justification:
Impact: the Linux kernel resets the wall clock (RTC_HCTOSYS=y) using the
value read from a specific rtc device (RTC_HCTOSYS_DEVICE=rtc0) as a
late_initcall() (see drivers/rtc/hctosys.c::rtc_hctosys()). That implies
that the RTC_HCTOSYS_DEVICE must be available when rtc_hctosys() is
called, making all the rtc drivers that are built as a module unsuitanle
for this task.
dmesg:
...
[ 5.396605] /home/ppisati/ubuntu-saucy/drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
- # rtc_hctosys() is called, it tries to open rtc0 but the driver is unavailable at # this time so it fails to set the system time
+ # rtc_hctosys() is called, it tries to open rtc0 but the driver is unavailable at this time so it fails to set the system time
[ 10.609622] rtc-pl031 fff35000.rtc: rtc core: registered pl031 as rtc0
# later on the rtc driver is loaded, but it's too late
...
ubuntu@m01:~$ date
Wed Dec 31 19:25:24 EST 1969
Fix: compile in the rtc driver that your board uses to set the wall
clock (pl031 on calxeda) - see the attached patch
Test case:
dmesg:
...
[ 5.303860] rtc-pl031 fff35000.rtc: rtc core: registered pl031 as rtc0
[ 5.421639] rtc-pl031 fff35000.rtc: setting system clock to 2013-11-19 16:47:18 UTC (1384879638)
...
when the rtc driver is correctly build-in, you should see something like
this in your bootlog.
--
Working on MAAS, I see midway machines boot on Saucy with an incorrect
system time (close to epoch). I have tried various things, including
using MAAS to make sure that the hardware clock was set correctly before
installation. Despite this, I find that the hardware clock (as reported
by "hwclock --utc") is correct, yet the system time ("date --utc") is
close to epoch.
Affects: Saucy linux-image-3.11.0-13-generic-lpae 3.11.0-13.20, util-
linux 2.20.1-5.1ubuntu9.
Below is my current understanding of the root cause and possible
solutions. My understanding may not be accurate. Please correct any
inaccuracies. This is just my current understanding; all I know is that
it doesn't work :)
In userspace, util-linux via /etc/init/hwclock.conf is involved with the
RTC. But it doesn't use --hctosys. I can find nothing in userspace that
takes responsibility for setting up the system time from the RTC.
hwclock(8) says that --hctosys is "a good option to use in one of the
system startup scripts.", but also that --systz is "is an alternate
option to --hctosys that does not read the hardware clock, and may be
used in system startup scripts for recent 2.6 kernels where you
know the System Time contains the Hardware Clock time."
So it appears to me that it is the kernel that is supposed to make sure
the RTC is copied to the system clock on boot, or at least that this is
the assumption that userspace is making. It's my understanding that this
isn't happening because rtc_pl031 is a module.
I assume that an RTC module load doesn't reset the system time. Or
should it? It sounds like an evil side effect to me if it doesn't happen
on boot. Perhaps there should be or there is a module parameter to make
it do that, though? If so, I am unaware of it, or any userspace
implementation of using that.
I can see two broad solutions to this:
1) The kernel takes responsibility for doing this task, which AIUI we
can do with CONFIG_RTC_DRV_PL031=y. This was the case with the linux-
highbank package in Quantal, which I believe is why this appears to be a
regression from MAAS' perspective.
2) Userspace takes responsibility for running "hwclock --hctosys", which
case we need logic to figure out when this is necessary (AIUI, it isn't
necessary for Intel, as the RTC driver is compiled in?) and how to
arrange this.
Other options:
3) Some kind of definition of the semantics (perhaps there is one and
I'm missing it) and userspace asking the module to do it on module load,
or an hwclock command after module load or something. I am concerned
about coordinating the timing involved in this option, though.
4) fixrtc on the command line as a workaround for MAAS. This would need
us to amend flash-kernel. But this doesn't really fix the problem; a
--hctosys would still be needed to make the clock properly accurate.
ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: linux-image-3.11.0-13-generic-lpae 3.11.0-13.20
ProcVersionSignature: User Name 3.11.0-13.20-generic-lpae 3.11.6
Uname: Linux 3.11.0-13-generic-lpae armv7l
AlsaDevices:
total 0
crw-rw---- 1 root audio 116, 1 Dec 31 1969 seq
crw-rw---- 1 root audio 116, 33 Dec 31 1969 timer
AlsaVersion: Advanced Linux Sound Architecture Driver Version k3.11.0-13-generic-lpae.
AplayDevices: Error: [Errno 2] No such file or directory: 'aplay'
ApportVersion: 2.12.5-0ubuntu2.1
Architecture: armhf
ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord'
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1:
CRDA: Error: [Errno 2] No such file or directory: 'iw'
Date: Mon Nov 18 06:33:34 2013
HibernationDevice: RESUME=UUID=1337d4f1-3df8-4589-9008-a47a197b579f
IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig'
Lsusb: Error: command ['lsusb'] failed with exit code 1: unable to initialize libusb: -99
MarkForUpload: True
PciMultimedia:
ProcFB:
ProcKernelCmdLine: console=ttyAMA0 nosplash
ProcModules:
binfmt_misc 7197 1 - Live 0x00000000 (F)
rtc_pl031 4594 0 - Live 0x00000000 (F)
uio 8483 1 uio_pdrv_genirq, Live 0x00000000 (F)
uio_pdrv_genirq 3441 0 - Live 0x00000000 (F)
xgmac 18035 0 - Live 0x00000000 (F)
RelatedPackageVersions:
linux-restricted-modules-3.11.0-13-generic-lpae N/A
linux-backports-modules-3.11.0-13-generic-lpae N/A
linux-firmware 1.116
RfKill: Error: [Errno 2] No such file or directory: 'rfkill'
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
WifiSyslog:
Nov 18 06:26:32 m22 dhclient: DHCPREQUEST of 10.193.24.144 on eth0 to 10.193.37.1 port 67 (xid=0xb672694)
Nov 18 06:26:32 m22 dhclient: DHCPACK of 10.193.24.144 from 10.193.24.1
Nov 18 06:26:32 m22 dhclient: bound to 10.193.24.144 -- renewal in 3558 seconds.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1252242
Title:
CONFIG_RTC_DRV_PL031=m stops the kernel from setting the system time
from the RTC automatically, which userspace expects
Status in “linux” package in Ubuntu:
Confirmed
Bug description:
SRU Justification:
Impact: the Linux kernel resets the wall clock (RTC_HCTOSYS=y) using
the value read from a specific rtc device (RTC_HCTOSYS_DEVICE=rtc0) as
a late_initcall() (see drivers/rtc/hctosys.c::rtc_hctosys()). That
implies that the RTC_HCTOSYS_DEVICE must be available when
rtc_hctosys() is called, making all the rtc drivers that are built as
a module unsuitanle for this task.
dmesg:
...
[ 5.396605] /home/ppisati/ubuntu-saucy/drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
# rtc_hctosys() is called, it tries to open rtc0 but the driver is unavailable at this time so it fails to set the system time
[ 10.609622] rtc-pl031 fff35000.rtc: rtc core: registered pl031 as rtc0
# later on the rtc driver is loaded, but it's too late
...
ubuntu@m01:~$ date
Wed Dec 31 19:25:24 EST 1969
Fix: compile in the rtc driver that your board uses to set the wall
clock (pl031 on calxeda) - see the attached patch
Test case:
dmesg:
...
[ 5.303860] rtc-pl031 fff35000.rtc: rtc core: registered pl031 as rtc0
[ 5.421639] rtc-pl031 fff35000.rtc: setting system clock to 2013-11-19 16:47:18 UTC (1384879638)
...
when the rtc driver is correctly build-in, you should see something
like this in your bootlog.
--
Working on MAAS, I see midway machines boot on Saucy with an incorrect
system time (close to epoch). I have tried various things, including
using MAAS to make sure that the hardware clock was set correctly
before installation. Despite this, I find that the hardware clock (as
reported by "hwclock --utc") is correct, yet the system time ("date
--utc") is close to epoch.
Affects: Saucy linux-image-3.11.0-13-generic-lpae 3.11.0-13.20, util-
linux 2.20.1-5.1ubuntu9.
Below is my current understanding of the root cause and possible
solutions. My understanding may not be accurate. Please correct any
inaccuracies. This is just my current understanding; all I know is
that it doesn't work :)
In userspace, util-linux via /etc/init/hwclock.conf is involved with
the RTC. But it doesn't use --hctosys. I can find nothing in userspace
that takes responsibility for setting up the system time from the RTC.
hwclock(8) says that --hctosys is "a good option to use in one of the
system startup scripts.", but also that --systz is "is an alternate
option to --hctosys that does not read the hardware clock, and may
be used in system startup scripts for recent 2.6 kernels where
you know the System Time contains the Hardware Clock time."
So it appears to me that it is the kernel that is supposed to make
sure the RTC is copied to the system clock on boot, or at least that
this is the assumption that userspace is making. It's my understanding
that this isn't happening because rtc_pl031 is a module.
I assume that an RTC module load doesn't reset the system time. Or
should it? It sounds like an evil side effect to me if it doesn't
happen on boot. Perhaps there should be or there is a module parameter
to make it do that, though? If so, I am unaware of it, or any
userspace implementation of using that.
I can see two broad solutions to this:
1) The kernel takes responsibility for doing this task, which AIUI we
can do with CONFIG_RTC_DRV_PL031=y. This was the case with the linux-
highbank package in Quantal, which I believe is why this appears to be
a regression from MAAS' perspective.
2) Userspace takes responsibility for running "hwclock --hctosys",
which case we need logic to figure out when this is necessary (AIUI,
it isn't necessary for Intel, as the RTC driver is compiled in?) and
how to arrange this.
Other options:
3) Some kind of definition of the semantics (perhaps there is one and
I'm missing it) and userspace asking the module to do it on module
load, or an hwclock command after module load or something. I am
concerned about coordinating the timing involved in this option,
though.
4) fixrtc on the command line as a workaround for MAAS. This would
need us to amend flash-kernel. But this doesn't really fix the
problem; a --hctosys would still be needed to make the clock properly
accurate.
ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: linux-image-3.11.0-13-generic-lpae 3.11.0-13.20
ProcVersionSignature: User Name 3.11.0-13.20-generic-lpae 3.11.6
Uname: Linux 3.11.0-13-generic-lpae armv7l
AlsaDevices:
total 0
crw-rw---- 1 root audio 116, 1 Dec 31 1969 seq
crw-rw---- 1 root audio 116, 33 Dec 31 1969 timer
AlsaVersion: Advanced Linux Sound Architecture Driver Version k3.11.0-13-generic-lpae.
AplayDevices: Error: [Errno 2] No such file or directory: 'aplay'
ApportVersion: 2.12.5-0ubuntu2.1
Architecture: armhf
ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord'
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1:
CRDA: Error: [Errno 2] No such file or directory: 'iw'
Date: Mon Nov 18 06:33:34 2013
HibernationDevice: RESUME=UUID=1337d4f1-3df8-4589-9008-a47a197b579f
IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig'
Lsusb: Error: command ['lsusb'] failed with exit code 1: unable to initialize libusb: -99
MarkForUpload: True
PciMultimedia:
ProcFB:
ProcKernelCmdLine: console=ttyAMA0 nosplash
ProcModules:
binfmt_misc 7197 1 - Live 0x00000000 (F)
rtc_pl031 4594 0 - Live 0x00000000 (F)
uio 8483 1 uio_pdrv_genirq, Live 0x00000000 (F)
uio_pdrv_genirq 3441 0 - Live 0x00000000 (F)
xgmac 18035 0 - Live 0x00000000 (F)
RelatedPackageVersions:
linux-restricted-modules-3.11.0-13-generic-lpae N/A
linux-backports-modules-3.11.0-13-generic-lpae N/A
linux-firmware 1.116
RfKill: Error: [Errno 2] No such file or directory: 'rfkill'
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
WifiSyslog:
Nov 18 06:26:32 m22 dhclient: DHCPREQUEST of 10.193.24.144 on eth0 to 10.193.37.1 port 67 (xid=0xb672694)
Nov 18 06:26:32 m22 dhclient: DHCPACK of 10.193.24.144 from 10.193.24.1
Nov 18 06:26:32 m22 dhclient: bound to 10.193.24.144 -- renewal in 3558 seconds.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1252242/+subscriptions
References
