Messages in this thread | | | Date | Mon, 1 Nov 2004 15:12:10 +0100 | From | Ingo Molnar <> | Subject | Re: [Fwd: Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4] |
| |
* 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |