linux-kernel - RE: 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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 18 Nov 2006 15:51:09 +0100
From:	"Joakim Tjernlund" <joakim.tjernlund@...nsmode.se>
To:	"'Jean Delvare'" <khali@...ux-fr.org>,
	"'Kumar Gala'" <galak@...nel.crashing.org>
Cc:	"'LKML'" <linux-kernel@...r.kernel.org>, <i2c@...sensors.org>
Subject: RE: RTC , ds1307 I2C driver and NTP does not work.

> 
> On Fri, 17 Nov 2006 18:38:10 +0100, Joakim Tjernlund wrote:
> > On Nov 17, 2006, at 10:38 AM, Joakim Tjernlund wrote:
> > 
> > > I get this when I activathte NTP and ntp "sync" the time 
> the I2C HW  
> > > clock.
> > 
> > You may be better off posting this to lkml and copy the i2c 
> list (and  
> > rtc if one exists).  Since its more a driver issue than anything  
> > really ppc specific.  Clearly we are doing schedules() in 
> mpc_xfer()  
> > and maybe we shouldn't be.
> 
> It's OK to schedule or sleep in mpc_xfer. It's not OK to call mpc_xfer
> from an interrupt context, which is what appears to be happening here.
> So the ds1307 driver would need to be changed not to directly call
> i2c_transfer from the interrupt. Using a workqueue should work.
> 
> That being said, I wonder why one would want to set the time from an
> interrupt context in the first place. Maybe that's what needs fixing.

That's the way kernel NTP code always has done it. Probably to minimize latency, ideally
you want to set the time when a new second occur since that's what most RTC HW expects.

Will a workqueue run directly after the one return from IRQ context?

> 
> > > BUG: scheduling while atomic: swapper/0x00010000/0
> > > Call Trace:^M
> > > [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
> > >
> > > I have activated RTC CLASS and have this in my board file:
> > > #ifdef CONFIG_RTC_CLASS
> > > late_initcall(rtc_class_hookup);
> > > #endif
> > >
> > > kernel 2.6.19-rc5
> > >
> > >  Jocke
> 
> -- 
> Jean Delvare
> 
> 

-
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/