<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/arch/x86/kernel/mpparse.c, branch linux-2.6.37.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-2.6.37.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-2.6.37.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2010-08-31T07:45:46Z</updated>
<entry>
<title>Merge commit 'v2.6.36-rc3' into x86/memblock</title>
<updated>2010-08-31T07:45:46Z</updated>
<author>
<name>Ingo Molnar</name>
</author>
<published>2010-08-31T07:45:21Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=daab7fc734a53fdeaf844b7c03053118ad1769da'/>
<id>urn:sha1:daab7fc734a53fdeaf844b7c03053118ad1769da</id>
<content type='text'>
Conflicts:
	arch/x86/kernel/trampoline.c
	mm/memblock.c

Merge reason: Resolve the conflicts, update to latest upstream.

Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</content>
</entry>
<entry>
<title>x86: Use memblock to replace early_res</title>
<updated>2010-08-27T18:12:29Z</updated>
<author>
<name>Yinghai Lu</name>
</author>
<published>2010-08-25T20:39:17Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=72d7c3b33c980843e756681fb4867dc1efd62a76'/>
<id>urn:sha1:72d7c3b33c980843e756681fb4867dc1efd62a76</id>
<content type='text'>
1. replace find_e820_area with memblock_find_in_range
2. replace reserve_early with memblock_x86_reserve_range
3. replace free_early with memblock_x86_free_range.
4. NO_BOOTMEM will switch to use memblock too.
5. use _e820, _early wrap in the patch, in following patch, will
   replace them all
6. because memblock_x86_free_range support partial free, we can remove some special care
7. Need to make sure that memblock_find_in_range() is called after memblock_x86_fill()
   so adjust some calling later in setup.c::setup_arch()
   -- corruption_check and mptable_update

-v2: Move reserve_brk() early
    Before fill_memblock_area, to avoid overlap between brk and memblock_find_in_range()
    that could happen We have more then 128 RAM entry in E820 tables, and
    memblock_x86_fill() could use memblock_find_in_range() to find a new place for
    memblock.memory.region array.
    and We don't need to use extend_brk() after fill_memblock_area()
    So move reserve_brk() early before fill_memblock_area().
-v3: Move find_smp_config early
    To make sure memblock_find_in_range not find wrong place, if BIOS doesn't put mptable
    in right place.
-v4: Treat RESERVED_KERN as RAM in memblock.memory. and they are already in
    memblock.reserved already..
    use __NOT_KEEP_MEMBLOCK to make sure memblock related code could be freed later.
-v5: Generic version __memblock_find_in_range() is going from high to low, and for 32bit
    active_region for 32bit does include high pages
    need to replace the limit with memblock.default_alloc_limit, aka get_max_mapped()
-v6: Use current_limit instead
-v7: check with MEMBLOCK_ERROR instead of -1ULL or -1L
-v8: Set memblock_can_resize early to handle EFI with more RAM entries
-v9: update after kmemleak changes in mainline

Suggested-by: David S. Miller &lt;davem@davemloft.net&gt;
Suggested-by: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
Suggested-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Signed-off-by: Yinghai Lu &lt;yinghai@kernel.org&gt;
Signed-off-by: H. Peter Anvin &lt;hpa@zytor.com&gt;
</content>
</entry>
<entry>
<title>x86, apic: Map the local apic when parsing the MP table.</title>
<updated>2010-08-05T23:26:42Z</updated>
<author>
<name>Eric W. Biederman</name>
</author>
<published>2010-08-04T20:30:27Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5989cd6a1cbf86587edcc856791f960978087311'/>
<id>urn:sha1:5989cd6a1cbf86587edcc856791f960978087311</id>
<content type='text'>
This fixes a regression in 2.6.35 from 2.6.34, that is
present for select models of Intel cpus when people are
using an MP table.

The commit cf7500c0ea133d66f8449d86392d83f840102632
"x86, ioapic: In mpparse use mp_register_ioapic" started
calling mp_register_ioapic from MP_ioapic_info.  An extremely
simple change that was obviously correct.  Unfortunately
mp_register_ioapic did just a little more than the previous
hand crafted code and so we gained this call path.

The problem call path is:
MP_ioapic_info()
  mp_register_ioapic()
   io_apic_unique_id()
     io_apic_get_unique_id()
       get_physical_broadcast()
         modern_apic()
           lapic_get_version()
             apic_read(APIC_LVR)

Which turned out to be a problem because the local apic
was not mapped, at that point, unlike the similar point
in the ACPI parsing code.

This problem is fixed by mapping the local apic when
parsing the mptable as soon as we reasonably can.

Looking at the number of places we setup the fixmap for
the local apic, I see some serious simplification opportunities.
For the moment except for not duplicating the setting up of the
fixmap in init_apic_mappings, I have not acted on them.

The regression from 2.6.34 is tracked in bug
https://bugzilla.kernel.org/show_bug.cgi?id=16173

Cc: &lt;stable@kernel.org&gt; 2.6.35
Reported-by: David Hill &lt;hilld@binarystorm.net&gt;
Reported-by: Tvrtko Ursulin &lt;tvrtko.ursulin@sophos.com&gt;
Tested-by: Tvrtko Ursulin &lt;tvrtko.ursulin@sophos.com&gt;
Signed-off-by: Eric W. Biederman &lt;ebiederm@xmission.com&gt;
LKML-Reference: &lt;m1eiee86jg.fsf_-_@fess.ebiederm.org&gt;
Signed-off-by: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
</content>
</entry>
<entry>
<title>x86, irq: Rename gsi_end gsi_top, and fix off by one errors</title>
<updated>2010-06-09T20:34:06Z</updated>
<author>
<name>Eric W. Biederman</name>
</author>
<published>2010-06-08T18:44:32Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=a4384df3e24579d6292a1b3b41d500349948f30b'/>
<id>urn:sha1:a4384df3e24579d6292a1b3b41d500349948f30b</id>
<content type='text'>
When I introduced the global variable gsi_end I thought gsi_end on
io_apics was one past the end of the gsi range for the io_apic.  After
it was pointed out the the range on io_apics was inclusive I changed
my global variable to match.  That was a big mistake.  Inclusive
semantics without a range start cannot describe the case when no gsi's
are allocated.  Describing the case where no gsi's are allocated is
important in sfi.c and mpparse.c so that we can assign gsi numbers
instead of blindly copying the gsi assignments the BIOS has done as we
do in the acpi case.

To keep from getting the global variable confused with the gsi range
end rename it gsi_top.

To allow describing the case where no gsi's are allocated have gsi_top
be one place the highest gsi number seen in the system.

This fixes an off by one bug in sfi.c:
Reported-by: jacob pan &lt;jacob.jun.pan@linux.intel.com&gt;

This fixes the same off by one bug in mpparse.c:

This fixes an off unreachable by one bug in acpi/boot.c:irq_to_gsi
Reported-by: Yinghai &lt;yinghai.lu@oracle.com&gt;

Signed-off-by: Eric W. Biederman &lt;ebiederm@xmission.com&gt;
LKML-Reference: &lt;m17hm9jre7.fsf_-_@fess.ebiederm.org&gt;
Signed-off-by: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
</content>
</entry>
<entry>
<title>x86, ioapic: In mpparse use mp_register_ioapic</title>
<updated>2010-05-04T20:34:59Z</updated>
<author>
<name>Eric W. Biederman</name>
</author>
<published>2010-03-30T08:07:11Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=cf7500c0ea133d66f8449d86392d83f840102632'/>
<id>urn:sha1:cf7500c0ea133d66f8449d86392d83f840102632</id>
<content type='text'>
Long ago MP_ioapic_info was the primary way of setting up our
ioapic data structures and mp_register_ioapic was a compatibility
shim for acpi code.  Now the situation is reversed and
and mp_register_ioapic is the primary way of setting up our
ioapic data structures.

Keep the setting up of ioapic data structures uniform by
having mp_register_ioapic call mp_register_ioapic.

This changes a few fields:

- type: is now hardset to MP_IOAPIC but type had to
  bey MP_IOAPIC or MP_ioapic_info would not have been called.

- flags: is now hard coded to MPC_APIC_USABLE.
  We require flags to contain at least MPC_APIC_USEBLE in
  MP_ioapic_info and we don't ever examine flags so dropping
  a few flags that might possibly exist that we have never
  used is harmless.

- apicaddr: Unchanged

- apicver: Read from the ioapic instead of using the cached
  hardware value in the MP table.  The real hardware value
  will be more accurate.

- apicid: Now verified to be unique and changed if it is not.
  If the BIOS got this right this is a noop.  If the BIOS did
  not fixing things appears to be the better solution.

This adds gsi_base and gsi_end values to our ioapics defined with
the mpatable, which will make our lives simpler later since
we can always assume gsi_base and gsi_end are valid.

Signed-off-by: Eric W. Biederman &lt;ebiederm@xmission.com&gt;
LKML-Reference: &lt;1269936436-7039-10-git-send-email-ebiederm@xmission.com&gt;
Signed-off-by: H. Peter Anvin &lt;hpa@zytor.com&gt;
</content>
</entry>
<entry>
<title>x86: Handle overlapping mptables</title>
<updated>2010-04-01T20:31:07Z</updated>
<author>
<name>Andi Kleen</name>
</author>
<published>2010-03-29T07:41:11Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=909fc87b32b3b9e3f0b87dcc5d98319c41900c58'/>
<id>urn:sha1:909fc87b32b3b9e3f0b87dcc5d98319c41900c58</id>
<content type='text'>
We found a system where the MP table MPC and MPF structures overlap.

That doesn't really matter because the mptable is not used anyways with ACPI,
but it leads to a panic in the early allocator due to the overlapping
reservations in 2.6.33.

Earlier kernels handled this without problems.

Simply change these reservations to reserve_early_overlap_ok to avoid
the panic.

Reported-by: Thomas Renninger &lt;trenn@suse.de&gt;
Tested-by: Thomas Renninger &lt;trenn@suse.de&gt;
Signed-off-by: Andi Kleen &lt;ak@linux.intel.com&gt;
LKML-Reference: &lt;20100329074111.GA22821@basil.fritz.box&gt;
Signed-off-by: H. Peter Anvin &lt;hpa@zytor.com&gt;
Cc: &lt;stable@kernel.org&gt;
</content>
</entry>
<entry>
<title>x86, apic: Don't use logical-flat mode when CPU hotplug may exceed 8 CPUs</title>
<updated>2010-02-10T04:51:11Z</updated>
<author>
<name>Suresh Siddha</name>
</author>
<published>2010-02-10T02:01:44Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=681ee44d40d7c93b42118320e4620d07d8704fd6'/>
<id>urn:sha1:681ee44d40d7c93b42118320e4620d07d8704fd6</id>
<content type='text'>
We need to fall back from logical-flat APIC mode to physical-flat mode
when we have more than 8 CPUs.  However, in the presence of CPU
hotplug(with bios listing not enabled but possible cpus as disabled cpus in
MADT), we have to consider the number of possible CPUs rather than
the number of current CPUs; otherwise we may cross the 8-CPU boundary
when CPUs are added later.

32bit apic code can use more cleanups (like the removal of vendor checks in
32bit default_setup_apic_routing()) and more unifications with 64bit code.
Yinghai has some patches in works already. This patch addresses the boot issue
that is reported in the virtualization guest context.

[ hpa: incorporated function annotation feedback from Yinghai Lu ]

Signed-off-by: Suresh Siddha &lt;suresh.b.siddha@intel.com&gt;
LKML-Reference: &lt;1265767304.2833.19.camel@sbs-t61.sc.intel.com&gt;
Acked-by: Shaohui Zheng &lt;shaohui.zheng@intel.com&gt;
Reviewed-by: Yinghai Lu &lt;yinghai@kernel.org&gt;
Cc: &lt;stable@kernel.org&gt;
Signed-off-by: H. Peter Anvin &lt;hpa@zytor.com&gt;
</content>
</entry>
<entry>
<title>x86: Use find_e820() instead of hard coded trampoline address</title>
<updated>2009-12-11T08:28:22Z</updated>
<author>
<name>Yinghai Lu</name>
</author>
<published>2009-12-10T21:07:22Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=893f38d144a4d96d2483cd7c3801d26e1b2c23e9'/>
<id>urn:sha1:893f38d144a4d96d2483cd7c3801d26e1b2c23e9</id>
<content type='text'>
Jens found the following crash/regression:

[    0.000000] found SMP MP-table at [ffff8800000fdd80] fdd80
[    0.000000] Kernel panic - not syncing: Overlapping early reservations 12-f011 MP-table mpc to 0-fff BIOS data page

and

[    0.000000] Kernel panic - not syncing: Overlapping early reservations 12-f011 MP-table mpc to 6000-7fff TRAMPOLINE

and bisected it to b24c2a9 ("x86: Move find_smp_config()
earlier and avoid bootmem usage").

It turns out the BIOS is using the first 64k for mptable,
without reserving it.

So try to find good range for the real-mode trampoline instead of
hard coding it, in case some bios tries to use that range for sth.

Reported-by: Jens Axboe &lt;jens.axboe@oracle.com&gt;
Signed-off-by: Yinghai Lu &lt;yinghai@kernel.org&gt;
Tested-by: Jens Axboe &lt;jens.axboe@oracle.com&gt;
Cc: Randy Dunlap &lt;randy.dunlap@oracle.com&gt;
LKML-Reference: &lt;4B21630A.6000308@kernel.org&gt;
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</content>
</entry>
<entry>
<title>x86: Move find_smp_config() earlier and avoid bootmem usage</title>
<updated>2009-11-24T11:10:51Z</updated>
<author>
<name>Yinghai Lu</name>
</author>
<published>2009-11-24T10:48:18Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b24c2a925a9837cccf54d50aeac22ba0cbc15455'/>
<id>urn:sha1:b24c2a925a9837cccf54d50aeac22ba0cbc15455</id>
<content type='text'>
Move the find_smp_config() call to before bootmem is initialized.
Use reserve_early() instead of reserve_bootmem() in it.

This simplifies the code, we only need to call find_smp_config()
once and can remove the now unneeded reserve parameter from
x86_init_mpparse::find_smp_config.

We thus also reduce x86's dependency on bootmem allocations.

Signed-off-by: Yinghai Lu &lt;yinghai@kernel.org&gt;
LKML-Reference: &lt;4B0BB9F2.70907@kernel.org&gt;
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</content>
</entry>
<entry>
<title>Merge branch 'x86-platform-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip</title>
<updated>2009-09-18T21:05:47Z</updated>
<author>
<name>Linus Torvalds</name>
</author>
<published>2009-09-18T21:05:47Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=78f28b7c555359c67c2a0d23f7436e915329421e'/>
<id>urn:sha1:78f28b7c555359c67c2a0d23f7436e915329421e</id>
<content type='text'>
* 'x86-platform-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: (38 commits)
  x86: Move get/set_wallclock to x86_platform_ops
  x86: platform: Fix section annotations
  x86: apic namespace cleanup
  x86: Distangle ioapic and i8259
  x86: Add Moorestown early detection
  x86: Add hardware_subarch ID for Moorestown
  x86: Add early platform detection
  x86: Move tsc_init to late_time_init
  x86: Move tsc_calibration to x86_init_ops
  x86: Replace the now identical time_32/64.c by time.c
  x86: time_32/64.c unify profile_pc
  x86: Move calibrate_cpu to tsc.c
  x86: Make timer setup and global variables the same in time_32/64.c
  x86: Remove mca bus ifdef from timer interrupt
  x86: Simplify timer_ack magic in time_32.c
  x86: Prepare unification of time_32/64.c
  x86: Remove do_timer hook
  x86: Add timer_init to x86_init_ops
  x86: Move percpu clockevents setup to x86_init_ops
  x86: Move xen_post_allocator_init into xen_pagetable_setup_done
  ...

Fix up conflicts in arch/x86/include/asm/io_apic.h
</content>
</entry>
</feed>
