[lkml]   [2008]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: HPET regression in 2.6.26 versus 2.6.25 -- connection between HPET and lockups found

* David Witbrodt <> wrote:

> > the address you printed out (0xffff88000100f000), does look
> > _somewhat_ suspicious. It corresponds to the physical address of
> > 0x100f000. That is _just_ above the 16MB boundary. It should not be
> > relevant normally - but it's still somewhat suspicious.
> I guess I was hitting around about the upper 32 bits -- I take it that
> these pointers are virtualized, and the upper half is some sort of
> descriptor? In that pointer was in a flat memory model, then it would
> be pointing _way_ past the end of my 2 GB of RAM, which would end
> around 0x0000000080000000.

correct, the 64-bit "flat" physical addresses are mapped with a shift:
they are shifted down into negative addresses, starting at:

earth4:~/tip> grep PAGE_OFFSET include/asm-x86/page_64.h
#define __PAGE_OFFSET _AC(0xffff880000000000, UL)

i.e. physical address zero is mapped to "minus 120 terabytes". [we do
this on the 64-bit kernel to get out of the way of the application
address space, which goes from the usual zero.]

All in one, 0xffff88000100f000 is a regular kernel address that
corresponds to the physical address of 0x100f000 - i.e. 16 MB plus

> I am not used to looking at raw pointer addresses, just pointer variable
> names. I think I was recalling the /proc/iomem data that Yinghai asked
> for, but this stuff is just offsets stripped of descriptors, huh?:
> $ cat /proc/iomem
> fed00000-fed003ff : HPET 0
> fed00000-fed003ff : 0000:00:14.0

correct - these resource descriptors are in the "physical address" space
(system RAM, chipset decoded addresses, device decoded addresses, etc.).

fed00000-fed003ff means that your HPET hardware sits at physical address
4275044352, or just below 4GB. That is the usual place for such non-RAM
device memory - it does not get in the way of normal RAM.

> It's like the change to alloc_bootmem_low made no difference at all!
> The Aug. 12 messages I saw about alloc_bootmem() had to do with
> alignment issues on 1 GB boundaries on x86_64 NUMA machines. I
> certainly do have x86_64 NUMA machines, but the behavior above seems
> to have nothing to do with alignment issues.

the resource descriptor is really a kernel internal abstraction - it's
just a memory buffer we put the hpet address into. It's in essence used
for /proc/iomem output, not much else. So it _should_ not have any

the real difference is likely that the hpet hardware is activated on
your box - and apparently is causing problems.

> Results: locked up


Just to make sure: on a working kernel, do you get the HPET messages?
I.e. does the hpet truly work in that case?


 \ /
  Last update: 2008-08-19 11:27    [W:0.037 / U:1.124 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site