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] [day] [month] [year] [list]
Date:	Tue, 21 Nov 2006 01:04:10 +0100
From:	Karsten Wiese <fzu@...gehoertderstaat.de>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: 2.6.19-rc6-rt4, changed yum repository

Am Sonntag, 19. November 2006 22:14 schrieb Ingo Molnar:
> 
> * Karsten Wiese <fzu@...gehoertderstaat.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

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ