In 2.6.11, cpu_to_node_map has moved from numa.c to smpboot.c. Since
smpboot.c isn't built on non-SMP systems, this causes non-smp builds to
fail to link in various places.
I don't know what the right answer is here - resurrect numa.c maybe?
--
dann frazier <[EMAIL PROTECTED]>
-
To unsubscribe
A generic 2.6.11 w/ CONFIG_SMP=n:
arch/ia64/mm/discontig.c: In function `find_pernode_space':
arch/ia64/mm/discontig.c:370: error: `__per_cpu_offset' undeclared
(first use in this function)
arch/ia64/mm/discontig.c:370: error: (Each undeclared identifier is
reported only once
arch/ia64/mm/disconti
In 2.6.11 arch/ia64/mm/discontig.c defines a per_cpu_init() function;
however, non-SMP systems have a per_cpu_init macro defined in
include/asm-ia64/percpu.h.
#define per_cpu_init() (__phys_per_cpu_start)
Is this the right way to approach a patch to fix this?
diff -urN l
On Tue, Mar 08, 2005 at 05:29:13PM -0800, Jesse Barnes wrote:
...
> An MSI should behave like a processor sending an IPI to itself since its
> address can be targeted at the processor's interrupt block and set to
> generate a local interrupt. Is that right, Tom & Grant?
Yes - that's how I under
Jesse Barnes wrote:
> On Tuesday, March 08, 2005 4:13 pm, Colin Ngam wrote:
> > That's what I will find out before deciding to use it. It is not used for
> > IPIs on our platform, probably for very good reasons.
>
> Yep, because IPIs generated from the local block to a distant processor won't
> w
On Tuesday, March 08, 2005 4:13 pm, Colin Ngam wrote:
> That's what I will find out before deciding to use it. It is not used for
> IPIs on our platform, probably for very good reasons.
Yep, because IPIs generated from the local block to a distant processor won't
work otherwise (afaik).
> If we
Colin Ngam wrote:
> Jesse Barnes wrote:
>
> > On Tuesday, March 8, 2005 3:48 pm, Colin Ngam wrote:
> > > Well, unfortunately, we do not send IPI by using the Processor Interrupt
> > > Block. We actually
> > > target a Special Altix Chipset "IPI Interrupt" register that ends up
> > > generating an
Fix infinite loop if sn_hwperf_location_to_bpos() fails.
Signed-off-by: Mark Goodwin <[EMAIL PROTECTED]>
diff -auNr linux.orig/arch/ia64/sn/kernel/sn2/sn_hwperf.c
linux/arch/ia64/sn/kernel/sn2/sn_hwperf.c
--- linux.orig/arch/ia64/sn/kernel/sn2/sn_hwperf.c 2005-03-08
17:50:50.0 +11
This is an updated MC/MT identification patch based on the previous
discussions on list.
Add the Multi-core and Multi-threading detection for IPF.
- Add new core and threading related fields in /proc/cpuinfo.
Physical id
Core id
Thread id
On Tue, Mar 08, 2005 at 05:14:33PM -0600, Matt Domsch wrote:
> Thanks Alex. I applied your patch, with a couple minor changes (more
> verbose warning messages and how to eliminate them).
>
> I've released efibootmgr 0.5.1 with these changes.
> http://linux.dell.com/files/efibootmgr/efibootmgr-0.5
On Tuesday, March 8, 2005 3:48 pm, Colin Ngam wrote:
> Well, unfortunately, we do not send IPI by using the Processor Interrupt
> Block. We actually
> target a Special Altix Chipset "IPI Interrupt" register that ends up
> generating an IPI. That is why, we
> have Platform Specific "send ipi" calls
"Nguyen, Tom L" wrote:
> On Monday, March 07, 2005 8:41 PM Colin wrote:
> > On Altix systems, we have a set of "Interrupt Registers" in Memory
> Address
> > Space that is initialized to target specific CPUs. The way we
> > initialize a card's MSI is:
> >
> > 1. The Target Address is One of these
Jesse Barnes wrote:
> On Tuesday, March 8, 2005 3:48 pm, Colin Ngam wrote:
> > Well, unfortunately, we do not send IPI by using the Processor Interrupt
> > Block. We actually
> > target a Special Altix Chipset "IPI Interrupt" register that ends up
> > generating an IPI. That is why, we
> > have P
>Tony, is this going to be acceptable? Should it be the work queue or
>timer based?
The only downsides I see to Ken's suggestion are:
1) Will need extra hooks for hot plug cpu to start/stop new timer
when cpus are added/removed. Some work is presumably needed here
anyway ... when a cpu is remov
Thanks Alex. I applied your patch, with a couple minor changes (more
verbose warning messages and how to eliminate them).
I've released efibootmgr 0.5.1 with these changes.
http://linux.dell.com/files/efibootmgr/efibootmgr-0.5.1.tar.gz
http://linux.dell.com/files/efibootmgr/efibootmgr-0.5.1.tar.g
This fixes a couple of bugs in the zx1/sx1000 sba_iommu. These are
all pretty low likelihood of hitting. The first problem is a simple off
by one, deep in the sba_alloc_range() error path. Surrounding that was
a lock ordering problem that could have potentially deadlocked with the
order the
For those of you who are interested, please sign up here
https://www.redhat.com/mailman/listinfo/fedora-ia64-list
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Monday, March 07, 2005 8:41 PM Colin wrote:
> On Altix systems, we have a set of "Interrupt Registers" in Memory
Address
> Space that is initialized to target specific CPUs. The way we
> initialize a card's MSI is:
>
> 1. The Target Address is One of these "Interrupt Registers"
> 2. The Data
On Monday, March 7, 2005 8:40 pm, Colin Ngam wrote:
> It's been a long time since we tested MSI/MSIX on our Altix boxes. It has
> been longer since I looked at the code. It works and we are looking
> forward to hooking them up with the current Infrastructure available on
> ia64 - pci_enable|disab
19 matches
Mail list logo
