Re: 2.6.19-rc6-rt4, changed yum repository

[Karsten Wiese <fzu@wemgehoertderstaat.de>]

Am Sonntag, 19. November 2006 22:14 schrieb Ingo Molnar:
> 
> * Karsten Wiese <fzu@wemgehoertderstaat.de> wrote:
> 
> >  Call Trace:
> >   [<c02d320f>] do_page_fault+0x2b9/0x552
> >   [<c0102f22>] work_resched+0x6/0x20
> 
> > The  [<c0102f22>] work_resched+0x6/0x20 corresponds to
> > 	mov    $0xfffff000,%ebp
> 
> > 0x000001c1 <work_resched+1>:    call   0x1c2 <work_resched+2>
> > 0x000001c6 <work_resched+6>:    mov    $0xfffff000,%ebp
> 
> no, it's the call's return address that is work_resched+6.
> 
> to get a more usable snapshot of what this task is doing you'd need 
> something like SysRq-P output. (that works on PREEMPT_RT only if you 
> enable /proc/sys/kernel/debug_direct_keyboard - but careful, it might 
> break if you generate too many interrupts - i usually only to do the 
> SysRq-P and hope that it doesnt break then.)

Thanks. It turned out, it was me having missed to .config enable
	"Enhanced Real Time Clock Support"
. Sorry for having bothered you about this.
hwclock then couldn't open /dev/rtc, fell back to iopl(3) hw access.
And that failed sometimes ;-)

I'd still like to know, why are there the do_page_fault() SysRq+T
traces under hwclock context, while hwclock userspace is in a loop
doing iopl(3)ed io-access? 

hwclock's loop active then is:
	for (i = 0; !cmos_clock_busy(); i++)
		if (i >= 10000000)
			return 1;
with:
	int cmos_clock_busy()
	{
		return   /* poll bit 7 (UIP) of Control Register A */
	    (hclock_read(10) & 0x80);
	}
with hand interpreted:
	unsigned long hclock_read(unsigned long reg)
	{
		unsigned long v;
		__asm__ volatile ("cli");
		outb (reg, clock_ctl_addr);
		 v = inb (clock_data_addr);
		__asm__ volatile ("sti");
		return v;
	}

I guess:
SysRq+T doesn't care about userspace eip and just displays hwclock's
last used kernel stack?

      Karsten