linux-kernel - Re: FW: RTC, ds1307 I2C driver and NTP does not work.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Sat, 18 Nov 2006 09:48:55 -0800
From:	David Brownell <david-b@...bell.net>
To:	joakim.tjernlund@...nsmode.se
Cc:	paulus@...ba.org, linux-kernel@...r.kernel.org,
	galak@...nel.crashing.org
Subject: Re: FW: RTC, ds1307 I2C driver and NTP does not work.

> > Of course you can't do that.  You're calling rtc_set_time(), which
> > requires a task/sleeping context, from an atomic can't-sleep context
> > (timer irq handler in this case).
> > 
> > Whatever your rtc_class_hookup() is doing, it's clearly wrong.
>
> It isn't my rtc_class_hookup(), it is in arch/powerpc/kernel/time.c
> and I am only using it the only way I can:
>
>  #ifdef CONFIG_RTC_CLASS
>  late_initcall(rtc_class_hookup);
>  #endif

Yeah, and that routine is clearly a bug.  The mechanism has only been
there about six weeks; 7a69af63e788a324d162201a0b23df41bcf158dd should
be reverted ASAP, it's braindead by design:

  - the issue noted above, calling rtc_set_time() from irq context
    ... so it BUG()s with NTP clock synch

  - wrongly assumes CONFIG_RTC_CLASS implies CONFIG_RTC_HCTOSYS_DEVICE
    ... so it will cause build errors when the latter isn't present

  - makes system time be set TWICE from that RTC, given HCTOSYS_DEVICE
    ... once from the powerpc time_init(), once from rtc class setup

The second would be trivially fixed (it's just #ifdeffed wrong), but the
other points aren't.  It would however be good to see someone make sure
that the RTC class code works with NTP synch, and sort out some of those
arch specific clock setup issues.


> > You're on the right track that the RTC class code needs to hook up
> > to NTP, but you can't do it that way.
>
> Clearly, but where should it be fixed in RTC CLASS or in ds1307 driver?

Neither:  arch/powerpc/kernel/time.c should revert the patch referenced
above.  No need to ship 2.6.19 with such a regression, and 2.6.20 could
ship with working code.

- Dave


> > > BUG: scheduling while atomic: swapper/0x00010000/0
> > > Call Trace:
> > > [C0245C80] [C000860C] show_stack+0x48/0x194 (unreliable)
> > > [C0245CB0] [C01BEFF4] schedule+0x5d4/0x618
> > > [C0245CF0] [C01BF9C8] schedule_timeout+0x70/0xd0
> > > [C0245D30] [C014416C] i2c_wait+0x164/0x1d8
> > > [C0245D80] [C0144490] mpc_xfer+0x2b0/0x3a8
> > > [C0245DD0] [C01423E8] i2c_transfer+0x58/0x7c
> > > [C0245DF0] [C0141124] ds1307_set_time+0x1bc/0x234
> > > [C0245E00] [C013F82C] rtc_set_time+0xb0/0xb8^M
> > > [C0245E20] [C000BFC4] set_rtc_class_time+0x34/0x58
> > > [C0245E40] [C000C8D0] timer_interrupt+0x5a0/0x5fc
> > > [C0245EE0] [C000F7B0] ret_from_except+0x0/0x14
> > > --- Exception: 901 at cpu_idle+0xc8/0xf0
> > >     LR = cpu_idle+0xec/0xf0
> > > [C0245FC0] [C000388C] rest_init+0x28/0x38
> > > [C0245FD0] [C01F36E0] start_kernel+0x1d8/0x228
> > > [C0245FF0] [00003438] 0x3438
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/