kernel-packages team mailing list archive

[Brad Figg <brad.figg@xxxxxxxxxxxxx>]

This bug is missing log files that will aid in diagnosing the problem.
>From a terminal window please run:

apport-collect 1252242

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable
to run this command, please add a comment stating that fact and change
the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the
Ubuntu Kernel Team.

** Changed in: linux (Ubuntu)
       Status: New => Incomplete

-- 
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:
  Incomplete

Bug description:
  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