From: Ingo Molnar <mingo@elte.hu>
To: David Witbrodt <dawitbro@sbcglobal.net>
Cc: Yinghai Lu <yhlu.kernel@gmail.com>,
linux-kernel@vger.kernel.org,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>, netdev <netdev@vger.kernel.org>
Subject: Re: HPET regression in 2.6.26 versus 2.6.25 -- connection between HPET and lockups found
Date: Tue, 19 Aug 2008 15:08:07 +0200 [thread overview]
Message-ID: <20080819130807.GB20210@elte.hu> (raw)
In-Reply-To: <452065.84245.qm@web82105.mail.mud.yahoo.com>
* David Witbrodt <dawitbro@sbcglobal.net> wrote:
> > Just to make sure: on a working kernel, do you get the HPET
> > messages? I.e. does the hpet truly work in that case?
>
> On the "fileserver", where 2.6.25 works but 2.6.26 locks up, the HPET
> _does_ work on a working kernel:
>
> $ uname -r
> 2.6.26.revert1
>
> $ dmesg | grep -i hpet
> ACPI: HPET 77FE80C0, 0038 (r1 RS690 AWRDACPI 42302E31 AWRD 98)
> ACPI: HPET id: 0x10b9a201 base: 0xfed00000
> hpet clockevent registered
> hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0
> hpet0: 4 32-bit timers, 14318180 Hz
> hpet_resources: 0xfed00000 is busy
btw., you might also want to look into drivers/char/hpet.c and
instrument that a bit. In particular the ioremap()s done there will show
exactly how the hpet is mapped.
In particular this bit:
if (hpet_is_known(hdp)) {
printk(KERN_DEBUG "%s: 0x%lx is busy\n",
__func__, hdp->hd_phys_address);
iounmap(hdp->hd_address);
return AE_ALREADY_EXISTS;
}
suggests that you've got multiple hpets listed by the BIOS?
> What I didn't realize is that the "desktop" machine, where 2.6.26 has
> always "worked", does NOT have a working HPET after all, even though I
> have enabled all HPET options in .config:
that's OK - you've still got a regression.
> (I don't know what is going on with "desktop": does the motherboard
> lack HPET, or does the Linux kernel not support the HPET hardware on
> the motherboard?)
Whether the system has a hpet listed in the BIOS data structures can be
seen in acpidump [in the pmtools package]
Even if the BIOS does not list it, the system might have hpet in the
chipset - hpet=force can be tried to force-enable it.
Ingo
next prev parent reply other threads:[~2008-08-19 13:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-19 12:49 HPET regression in 2.6.26 versus 2.6.25 -- connection between HPET and lockups found David Witbrodt
2008-08-19 13:08 ` Ingo Molnar [this message]
-- strict thread matches above, loose matches on Subject: below --
2008-08-19 3:51 David Witbrodt
2008-08-19 9:23 ` Ingo Molnar
2008-08-19 0:34 David Witbrodt
2008-08-19 1:14 ` Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080819130807.GB20210@elte.hu \
--to=mingo@elte.hu \
--cc=dawitbro@sbcglobal.net \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=yhlu.kernel@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox