[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080127124120.GA23377@elte.hu>
Date: Sun, 27 Jan 2008 13:41:20 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Kevin Winchester <kjwinchester@...il.com>
Cc: Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
John Stultz <johnstul@...ibm.com>
Subject: Re: X fails to start with latest Linus git
* Ingo Molnar <mingo@...e.hu> wrote:
> it seems you've got hpet active by default:
>
> /sys/devices/system/clocksource/clocksource0/current_clocksource:
> hpet
> /sys/devices/system/clocksource/clocksource0/available_clocksource:
> hpet acpi_pm pit jiffies tsc
btw., it's quite mysterious how this can lock up. ktime_get() on a hpet
clocksource does a very straightforward:
static cycle_t read_hpet(void)
{
return (cycle_t)hpet_readl(HPET_COUNTER);
}
which is a very simple thing:
c0119470 <hpet_readl>:
c0119470: 8b 15 b8 b4 ae c0 mov 0xc0aeb4b8,%edx
c0119476: 55 push %ebp
c0119477: 89 e5 mov %esp,%ebp
c0119479: 5d pop %ebp
c011947a: 01 d0 add %edx,%eax
c011947c: 8b 00 mov (%eax),%eax
c011947e: c3 ret
basically just a memory access to an ioremap()-ed area.
hm, perhaps it's due to the xtime lock dependency:
do {
seq = read_seqbegin(&xtime_lock);
getnstimeofday(ts);
tomono = wall_to_monotonic;
} while (read_seqretry(&xtime_lock, seq));
perhaps your system somehow generates a printk from within an xtime_lock
locked section?
Ingo
--
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