svn commit: r212541 - in head/sys: amd64/amd64 amd64/include dev/acpica i386/i386 i386/include kern mips/include mips/mips pc98/pc98 powerpc/aim powerpc/booke powerpc/include powerpc/powerpc sparc6...

[Daan Vreeken]

Hi Alexander,

On Monday 13 September 2010 09:25:35 Alexander Motin wrote:
> Author: mav
> Date: Mon Sep 13 07:25:35 2010
> New Revision: 212541
> URL: http://svn.freebsd.org/changeset/base/212541
>
> Log:
>   Refactor timer management code with priority to one-shot operation mode.
>   The main goal of this is to generate timer interrupts only when there is
>   some work to do. When CPU is busy interrupts are generating at full rate
>   of hz + stathz to fullfill scheduler and timekeeping requirements. But
>   when CPU is idle, only minimum set of interrupts (down to 8 interrupts
> per second per CPU now), needed to handle scheduled callouts is executed.
> This allows significantly increase idle CPU sleep time, increasing effect
> of static power-saving technologies. Also it should reduce host CPU load on
> virtualized systems, when guest system is idle.
[snip]

When re-basing an ARM system running an older -current with local 
patches/additions to a more recent version of -current (around 
2010-09-16-ish) I found out that the resulting kernel stopped booting.
To factor out our local changes I've tried to boot a 'SHEEVAPLUG' kernel 
without modifications. This kernel also fails to boot. It just stops right 
after :

	...
	ehci0: <Marvell Integrated USB 2.0 controller> mem 0xf1050000-0xf1050fff
	  irq 48,19 on simplebus0
	ehci0: [FILTER]
	ehci0: [ITHREAD]
	usbus0: EHCI version 1.0
	usbus0: set host controller mode
	usbus0: <Marvell Integrated USB 2.0 controller> on ehci0
	Timecounters tick every 1.000 msec
	usbus0: 480Mbps High Speed USB v2.0

Doing a binary search I've found that a kernel built from sources directly 
before your commit boots normally, but with this commit the board hangs 
during boot.
The debugger is accessible when the system 'hangs'. 'ps' shows:

	KDB: enter: Line break on console
	[ thread pid 10 tid 100002 ]
	Stopped at      kdb_enter+0x48: ldrb    r15, [r15, r15, ror r15]!
	db> ps
	  pid  ppid  pgrp   uid   state   wmesg     wchan    cmd
	    5     0     0     0  DL      ccb_scan 0xc0bc49ec [xpt_thrd]
	   13     0     0     0  DL      (threaded)          [usb]
	100023                   D       -        0xc3500d0c [usbus0]
	100022                   D       USBWAIT  0xc0bca57c [usbus0]
	100021                   D       -        0xc3500cac [usbus0]
	100020                   D       -        0xc3500c7c [usbus0]
	   12     0     0     0  DL      -        0xc0bca57c [yarrow]
	    4     0     0     0  DL      -        0xc0bc7d38 [g_down]
	    3     0     0     0  DL      -        0xc0bc7d34 [g_up]
	    2     0     0     0  DL      -        0xc0bc7d2c [g_event]
	   11     0     0     0  WL      (threaded)          [intr]
	100019                   I                           [intr19: ehci0]
	100018                   I                           [swi0: uart uart]
	100017                   I                           [intr13: mge0]
	100016                   I                           [intr12: mge0]
	100015                   I                           [swi6: Giant taskq]
	100013                   I                           [swi5: +]
	100011                   I                           [swi2: cambio]
	100010                   I                           [swi6: task queue]
	100005                   I                           [swi3: vm]
	100004                   I                           [swi1: netisr 0]
	100003                   I                           [swi4: clock]
	   10     0     0     0  RL      CPU 0               [idle]
	    1     0     0     0  ?L                          [kernel]
	    0     0     0     0  DLs     (threaded)          [kernel]
	100014                   D       -        0xc343be80 [thread taskq]
	100012                   D       -        0xc343d080 [kqueue taskq]
	100000                   D       conifhk  0xc0bb3d5c [swapper]

After fiddling around a bit with the debugger, I found out that calling 
cpu_idleclock() followed by cpu_activeclock() manually from the debugger 
will 'un-freeze' the system and get it to continue booting.

For a full dmesg and the logs of the debugging session see :
	http://vehosting.nl/pub_diffs/dmesg-arm-2010-09-18-timer-code.txt

Can you perhaps tell me what's going wrong after this commit?
(If you need more info, I'd be happy to provide it where I can.)


Regards,
-- 
Daan Vreeken
VEHosting
http://VEHosting.nl
tel: +31-(0)40-7113050 / +31-(0)6-46210825
KvK nr: 17174380