Opps...with ELDK-2.1.0 (ppc_4xx)
Eugene Surovegin
ebs at ebshome.net
Wed Apr 23 06:33:18 EST 2003
At 12:50 PM 4/22/2003, Wolfgang Denk wrote:
>It is pretty much consisten with what we're seeing here...
>
> > Trace; c000f2dc <schedule+94/57c>
> > Trace; c000f1ec <schedule_timeout+98/cc>
> > Trace; c000fcec <interruptible_sleep_on_timeout+68/ac>
> > Trace; c00dc510 <iic_wait_for_irq+88/1b0>
> > Trace; c00dc860 <iic_sendbytes+228/29c>
> > Trace; c00dcf74 <iic_xfer+1bc/1d0>
> > Trace; c00da7a0 <i2c_transfer+8c/e0>
> > Trace; c00db5cc <i2c_smbus_xfer_emulated+218/298>
> > Trace; c00db720 <i2c_smbus_xfer+d4/f0>
> > Trace; c00db110 <i2c_smbus_write_byte_data+34/44>
> > Trace; c00dd664 <rtc_write+28/58>
> > Trace; c00dd7e4 <m41t00_set_rtc_time+150/1b0>
> > Trace; c0004f04 <timer_interrupt+1c4/254>
> > Trace; c000376c <ret_from_intercept+0/8>
> > Trace; c00228c8 <check_pgt_cache+20/30>
> > Trace; c0004d04 <idled+58/70>
> > Trace; c0004d2c <cpu_idle+10/24>
> > Trace; c00011d0 <rest_init+30/40>
> > Trace; c0181598 <start_kernel+168/17c>
> > Trace; c0000224 <skpinv+1b8/1f0>
>
>This means you have a RTC on the I2C bus, right? Same here. It works
>fine on all baords except those with a I2C based RTC. Which is why we
>detected the problem so late.
It looks like a bug in m41t00_set_rtc_time.
Generic I2C layer is very high-level subsystem and can not be used from the
interrupt context.
Eugene.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
More information about the Linuxppc-embedded
mailing list