Re: [Fwd: Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4]

[Ingo Molnar <mingo@elte.hu>]

* Florian Schmidt <mista.tapas@gmx.net> wrote:

> > i'm seeing some weird traces, which show rtc_wakeup doing this cycle:
> > 
> > 	[~900 usecs pass]
> > 
> > 	hardirq 8 comes in, wakes IRQ 8 thread
> > 	IRQ 8 thread wakes up rtc_wakeup
> > 
> > 	rtc_wakeup fast-thread returns from sys_read()
> > 	rtc_wakeup fast-thread enters sys_poll() and returns immediately
> > 	rtc_wakeup fast-thread enters sys_read() and blocks
> 
> weird. why could poll return immeaditly? Only when data should be
> available right? Ahh, maybe there's less data available than which is
> needed by read(). I suppose i need to check if enough data is
> available. If not, repoll(), then generate the timestamp. Then read().
> I had the impression that this small amount of data which rtc delivers
> (4 bytes i think) would not be split into smaller parts.
> 
> It never occured to me that poll() could return with incomplete rtc
> data available..

this is how it works:

static unsigned int rtc_poll(struct file *file, poll_table *wait)
{
        unsigned long l;

        if (rtc_has_irq == 0)
                return 0;

        poll_wait(file, &rtc_wait, wait);

        spin_lock_irq (&rtc_lock);
        l = rtc_irq_data;
        spin_unlock_irq (&rtc_lock);

        if (l != 0)
                return POLLIN | POLLRDNORM;
        return 0;
}

it seems that it cannot return with incomplete data. rtc_has_irq is a
boot-time-only thing - either the RTC can generate interrupts or it
cannot. rtc_irq_data is updated atomically - either it's full with 4
bytes or it's completely empty.

safest would be to call the read() with O_NONBLOCK and figure out how
often -EAGAIN happens? (O_NONBLOCK is honored by /dev/rtc.)

but i could imagine that you could get into a 'wrong phase' if for
whatever reason an RTC interrupt slips in before the poll()?

	Ingo