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
Daan at vehosting.nl
Sat Sep 18 11:01:17 UTC 2010
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
More information about the svn-src-head
mailing list