On Friday 22 February 2008 12:28:26 am Shaohua Li wrote:
> My tiger machine hangs since 2.6.23 with commit above. I always saw oops
> in ia64_sal_physical_id_info(). In 2.6.22, if ia64_pal_logical_to_phys
> returns UNIMPLENTED, ia64_sal_physical_id_info() isn't called. Below
> patch fixes the issue
On Thursday 21 February 2008 10:10:19 pm Isaku Yamahata wrote:
> Xenlinux/ia64 needs to reserve one more region passed from xen hypervisor
> as start info.
I don't think it's really worth adding an ifdef here to save
one struct rsvd_region (two longs). Why not just increase
IA64_MAX_RSVD_REGIONS
On Tuesday 05 February 2008 07:03:23 pm Carlos Corbacho wrote:
> On Wednesday 06 February 2008 00:35:54 Bjorn Helgaas wrote:
> > > Ok. The only other vendors I really have in mind are HP and Fujitsu,
> > > since both those vendors use WMI on their laptops, so they would be
On Tuesday 05 February 2008 02:18:01 pm Carlos Corbacho wrote:
> On Tuesday 05 February 2008 21:03:30 Len Brown wrote:
> > On Monday 04 February 2008 21:16, Carlos Corbacho wrote:
> > > 2) Do you know of any IA64 systems using ACPI-WMI? At the moment, WMI
> > > will work on x86 and hopefully IA64,
On Tuesday 05 February 2008 04:12:32 pm Russ Anderson wrote:
> On Tue, Feb 05, 2008 at 01:21:00PM -0700, Bjorn Helgaas wrote:
> > On Tuesday 05 February 2008 12:32:33 pm Russ Anderson wrote:
> > > + if (first_time) {
> > > +
On Tuesday 05 February 2008 12:32:33 pm Russ Anderson wrote:
> + if (first_time) {
> + data = mca_bootmem();
> + first_time = 0;
> + } else
> + data = page_address(alloc_pages_node(numa_node_id(),
> +
On Monday 14 January 2008 10:59:24 am Luck, Tony wrote:
> The compiler team did the hard work for this distilling a problem in
> large fortran application which showed up when applied to a 290MB input
> data set down to this instruction:
>
> ldfd f34=[r17],-8
>
> Which they noticed incremen
On Thursday 03 January 2008 02:48:42 pm Luck, Tony wrote:
> This looks like a nice cleanup in general (though I'm not really sure
> how much we benefit by having e-mail addresses inside <...> style
> brackets rather than parentheses :-).
I actually like that change, because then I can easily copy
On Monday 10 December 2007 03:03:42 pm Alexei Gerasimov wrote:
> Bjorn Helgaas wrote:
> > I've only used the HP i2000 version, and even that's been a long time,
> > but my guess is that the firmware upgrade would be safe, and that the
> > appropriate HP-UX v
On Sunday 09 December 2007 10:59:15 am Alexei Gerasimov wrote:
> I happen to posses an old "Big Sur" machine manufactured by Intel, based
> around two Itanium (Merced) CPU's and a 460GX chipset. The machine is
> labeled as an "enginnering sample" (label:
> http://ishells.net/spy/itanium/DSC00873.jp
On Friday 05 October 2007 02:19:17 pm Luck, Tony wrote:
> > Ping! Tony, can you let me know your plans for this patch? I'd
> > like to get it into a distro release, and of course, it's best if
> > you accept it first.
>
> I'll put it in soon. My only vague concern is whether it should be more
>
On Thursday 20 September 2007 02:20:23 pm Bjorn Helgaas wrote:
> Here's the driver with no exported symbols.
Ping! Tony, can you let me know your plans for this patch? I'd
like to get it into a distro release, and of course, it's best if
you accept it first.
Thanks,
Bjor
eturns the
result.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: work2/arch/ia64/Kconfig
===
--- work2.orig/arch/ia64/Kconfig2007-09-19 10:09:43.0 -0600
+++ work2/arch/ia64/Kconfig 2007-09-19 10:51:15
a new "IA64_FW_CALL" that
takes care of these calling conventions, but allows the caller to specify
either ia64_sal or some other firmware entry point.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: work2/i
Here's the driver with no exported symbols.
-
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 Tuesday 18 September 2007 05:53:28 pm Luck, Tony wrote:
> > If you don't object to the two patches, can you incorporate them
> > as originally posted? If you'd prefer a different approach, I'd
> > be happy to rework them, of course.
>
> I think that adding 4K to the kernel (about 0.04% increas
On Tuesday 11 September 2007 05:14:56 pm Bjorn Helgaas wrote:
> ...
> So I'm interested in feedback on the following patches, which do not
> export sal_lock, but rather export functions that can be used to call
> SAL or other native firmware interfaces.
Hi Tony,
I haven'
On Wednesday 12 September 2007 02:56:51 am Matthew Garrett wrote:
> On Tue, Sep 11, 2007 at 05:16:46PM -0600, Bjorn Helgaas wrote:
> > +config IA64_HP_AML_NFW
> > + tristate "Support ACPI AML calls to native firmware"
>
> The description seems a bit generic f
This driver for HPQ5001 devices installs a global ACPI OpRegion handler.
AML methods can use this OpRegion to call native firmware entry points.
This is required to support some hotplug functionality on HP Integrity
systems.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: w/arc
functionality that needs the same conventions
as SAL_CALL (FP regs saved/restored, sal_lock acquired, etc), but
doesn't use the ia64_sal function pointer, and
- I'd like to make this new functionality a module, and I'd rather export
fw_call_lock() than sal_lock.
Signe
Here are a couple patches on which I'd like some feedback.
The basic idea is that ACPI AML methods sometimes need to do something
that is already implemented as a SAL interface. ACPI doesn't provide a
way for an AML method to directly call the SAL interface. That means
firmware writers sometimes
On Friday 07 September 2007 02:38:07 am Jes Sorensen wrote:
> The reason why I suggested a machvec is to avoid cluttering up the
> generic function with something like this. In addition I only see two
> machvec's that may potentially get copied, the dig one and the hpzx1
> one.
>
> If we start add
On Monday 03 September 2007 02:06:20 am Natalie Protasevich wrote:
> This patch allows to disable ptc.g. The code used to be in the kernel, then
> was removed
> in 2.4 since the bug that it was fixing has gone away. However, some large
> system vendors
> now want this capability available throu
On Friday 17 August 2007 11:21:14 am Luck, Tony wrote:
> > IA64_PSR_RI is in IPSR_MASK, apparently by intent.
> > If you want to change the behavior, you should simply change that mask.
>
> psr.ri is more complex because it is two bits where not all of the
> possible bit settings are defined. We
On Friday 17 August 2007 12:44:58 pm Luck, Tony wrote:
> > This confused me, too, because the changelog and comments say
> > "PSR.ri bits 3 are reserved" and "psr.ri bits 11 are reserved".
> >
> > Something like "PSR.ri value 3 is reserved" would have made
> > the intent more clear.
>
> Is this be
On Friday 13 July 2007 05:54:02 pm Kallol Biswas wrote:
> I have been trying to install debian 40r0 on hp longs
> peak itanium server. The installation hangs trying to
> configure net
I copied the debian-ia64 list, which is probably a better place to
start.
The HP management processor contain
On Friday 25 May 2007 02:29:17 am Horms wrote:
> On Fri, May 25, 2007 at 02:46:37PM +0900, Satoru Takeuchi wrote:
> > Conform ia64 signal code to the 80-characters-per-line rule.
> > It has no functional change.
>
> I have a bunch of simmilar changes for other files.
> Tony, are you interested in
On Sunday 27 May 2007 08:55:45 pm Peter Chubb wrote:
> >>>>> "Peter" == Peter Chubb <[EMAIL PROTECTED]> writes:
>
> >>>>> "Bjorn" == Bjorn Helgaas <[EMAIL PROTECTED]> writes:
>
> Bjorn> Example memory map (from HP
We used to warn unless the EFI system table major revision was exactly 1.
But EFI 2.00 firmware is starting to appear, and the 2.00 changes don't
affect anything in Linux.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: w/include/
Updates documentation and adds some test cases.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: work-mm10/Documentation/ia64/aliasing.txt
===
--- work-mm10.orig/Documentation/ia64/aliasing.txt 2007-03-21
r /dev/mem or a /sys/.../legacy_mem file.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: work-mm10/arch/ia64/kernel/efi.c
===
--- work-mm10.orig/arch/ia64/kernel/efi.c 2007-03-20 21:07:28.0
-0700
+++ wor
Allow cacheable mmaps of legacy_mem if WB access is supported for the region.
The "legacy_mem" file often contains a shadow option ROM, and some versions of
X depend on this.
Tim Yamin <[EMAIL PROTECTED]> reported that this change fixes X on a Dell
PowerEdge 3250.
Signed-off-b
4KB mappings instead of 16MB or 64MB mappings. The smaller
mappings give more flexibility to use the correct attributes.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: work-mm10/arch/ia64/mm/ioremap.c
===
--- work-mm10.orig/
No functional change, just use the same names as i386.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: work-mm10/arch/ia64/mm/ioremap.c
===
--- work-mm10.orig/arch/ia64/mm/ioremap.c 2007-03-16 14:03:11.0
This series fixes a few memory mapping issues on ia64.
Changes from the first posting:
- page-align address for vunmap in patch 2
- cc: akpm
Outline:
1 rename ioremap variables to match i386 (no functional change)
2 use page table mappings in ioremap to avoid unsupported attributes
3
On Thursday 29 March 2007 17:54, Luck, Tony wrote:
> Found a small problem. With this patch in place I get
> a complaint while booting on an Intel tiger:
>
> Trying to vfree() bad address (a0020001b000)
> BUG: at vm/vmalloc.c:323 __vunmap()
Oops, I forgot to page-align the address before pas
On Wednesday 21 March 2007 16:16, Bjorn Helgaas wrote:
> This series fixes a few memory mapping issues on ia64. Outline:
>
> 1 rename ioremap variables to match i386 (no functional change)
> 2 use page table mappings in ioremap to avoid unsupported attributes
> 3 allow
> > + Failing all of the above, we have to all back to a UC mapping.
>
> s/all back/fall back/
Thanks, corrected version below.
ia64: update memory attribute aliasing documentation & test cases
Updates documentation and adds some test cases.
Signed-off-by: Bjorn Helgaas &
Updates documentation and adds some test cases.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: work-mm10/Documentation/ia64/aliasing.txt
===
--- work-mm10.orig/Documentation/ia64/aliasing.txt 2007-03-21
Allow cacheable mmaps of legacy_mem if WB access is supported for the region.
The "legacy_mem" file often contains a shadow option ROM, and some versions of
X depend on this.
Tim Yamin <[EMAIL PROTECTED]> reported that this change fixes X on a Dell
PowerEdge 3250.
Signed-off-b
r /dev/mem or a /sys/.../legacy_mem file.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: work-mm10/arch/ia64/kernel/efi.c
===
--- work-mm10.orig/arch/ia64/kernel/efi.c 2007-03-20 21:07:28.0
-0700
+++ wor
No functional change, just use the same names as i386.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: work-mm10/arch/ia64/mm/ioremap.c
===
--- work-mm10.orig/arch/ia64/mm/ioremap.c 2007-03-16 14:03:11.0
4KB mappings instead of 16MB or 64MB mappings. The smaller
mappings give more flexibility to use the correct attributes.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: work-mm10/arch/ia64/mm/ioremap.c
===
--- work-mm10.orig/
This series fixes a few memory mapping issues on ia64. Outline:
1 rename ioremap variables to match i386 (no functional change)
2 use page table mappings in ioremap to avoid unsupported attributes
3 allow WB mmap of /sys/.../legacy_mem
4 fail mmaps that span areas with incompatible at
On Thursday 28 September 2006 10:36, Jesse Barnes wrote:
> On Wednesday, September 27, 2006 9:55 pm, [EMAIL PROTECTED]
> wrote:
> > pci_fixup_video turns into generic code because there are many platforms
> > need this fixup for embedded VGA as well as x86. The Video BIOS
> > integrates into Syste
On Monday 12 February 2007 12:34, Karthik Gopalakrishnan wrote:
> When I booted 2.6.19 on an IA Superdome (Orca), the kernel caused an
> MCA around the "dmi_scan" function. When I set "CONFIG_DMI = n", it
> was automatically set back to "y" during the build. I had to
> workaround the problem by com
On Tuesday 30 January 2007 13:16, Matt Domsch wrote:
> FYI, this was sent to lkml. I haven't reviewed yet.
I objected to the original LKML patch. Frederic then posted
a different one that adds x86 wrappers, similar to what ia64
already has. That one affects only x86, and seems fine to me.
Bjor
On Friday 08 December 2006 13:30, Karthik Gopalakrishnan wrote:
> I am trying to debug an MCA that I hit during kernel bootup. I
> have isolated the problem to the while loop in the console_init()
> routine called as part of start_kernel(). The IIP obtained from the
> MCA Logs point to vgacon_s
On Wednesday 15 November 2006 21:02, Keith Owens wrote:
> I implemented this in my kdb tree, but it has a very nasty side effect,
> it stops you from debugging that part of the boot process between kdb
> startup and when the i8042 is probed. KDB starts up very early so we
> can debug the boot proc
On Wednesday 31 August 2005 10:18 am, Andreas Schwab wrote:
> Bjorn Helgaas <[EMAIL PROTECTED]> writes:
>
> > Does the MCA log say anything useful?
>
> How can I find out?
On HP boxes, you can do "errdump mca" (for zx1 boxes) or
"errdump all mca" (fo
On Wednesday 31 August 2005 10:03 am, Bjorn Helgaas wrote:
> I used your .config and saw an MCA in i8042_flush() (IIP in
> __ia64_inb, BR0 in i8042_flush). Can you try turning off
> CONFIG_SERIO_I8042? This was fixed a while back, but maybe
> it got broken again.
Oh, I remember now.
On Tuesday 30 August 2005 5:04 pm, Andreas Schwab wrote:
> I'm getting an MCA during early setup on Eiger, these are the last (and
> only) messages:
>
> EFI v1.10 by HP: SALsystab=0x723feee9710 ACPI 2.0=0x723fe04
> HCDP=0x723fe0720d0 SMBIOS=0x7fffe000
> booting generic kernel on platform hpzx1
On Wednesday 24 August 2005 10:53 am, Kumar Gala wrote:
> Removed IA64 architecture specific users of asm/segment.h and
> asm-ia64/segment.h itself
I posted a similar patch a month ago, but I only removed the
arch/ia64 includes of asm/segment.h.
There are still a few drivers that include asm/segm
Parenthesize "p" to avoid ambiguity. No callers have a problem today;
this is just to clean up the bad form.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: work-vga/include/asm-ia64/io.h
===
--- work-vga.
On Tuesday 16 August 2005 3:38 am, Bartlomiej Zolnierkiewicz wrote:
> On 8/15/05, Bjorn Helgaas <[EMAIL PROTECTED]> wrote:
> > On Friday 12 August 2005 2:40 am, Alan Cox wrote:
> Agreed but I have few comments:
> * is this change OK w.r.t. IA64_HP_SIM?
Kernels for the HP
On Friday 12 August 2005 2:40 am, Alan Cox wrote:
> Assuming all IA-64 boxes are PCI or better then you actually want to
> edit include/asm-ia64/ide.h and edit ide_default_io_base where someone
> years ago cut and pasted x86-32 values so that case 2-5 are removed.
> Then you will just probe the com
On Thursday 11 August 2005 3:56 pm, Jeff Garzik wrote:
> Jeff Garzik wrote:
> > 00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE
> > Controller
> > (rev 02) (prog-if 8a [Master SecP PriP])
> > Subsystem: Hewlett-Packard Company d530 CMT (DG746A)
> > Control: I/
On Thursday 11 August 2005 2:56 pm, Jeff Garzik wrote:
> Bjorn Helgaas wrote:
> > On Thursday 11 August 2005 2:36 pm, Jeff Garzik wrote:
> >>Bjorn Helgaas wrote:
> >>> config IDE_GENERIC
> >>> tristate "generic/default IDE chipset support"
&g
On Thursday 11 August 2005 2:36 pm, Jeff Garzik wrote:
> Bjorn Helgaas wrote:
> > IA64 boxes only have PCI IDE devices, so there's no need to blindly poke
> > around in I/O port space. Poking at things that don't exist causes MCAs
> > on HP ia64 systems.
> &
On Thursday 11 August 2005 2:34 pm, Christoph Hellwig wrote:
> On Thu, Aug 11, 2005 at 02:24:43PM -0600, Bjorn Helgaas wrote:
> > IA64 boxes only have PCI IDE devices, so there's no need to blindly poke
> > around in I/O port space. Poking at things that don't exist c
IA64 boxes only have PCI IDE devices, so there's no need to blindly poke
around in I/O port space. Poking at things that don't exist causes MCAs
on HP ia64 systems.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: work-vga/dri
On Thursday 04 August 2005 5:26 pm, Bjorn Helgaas wrote:
> Maybe the third time's the charm :-) Added a bugfix
> (pcibios_penalize_isa_irq()) and a workaround for HP
> HPET firmware description since last time. The workaround
> accepts stuff that is illegal according to the sp
On Wednesday 13 July 2005 7:09 pm, Matt Tolentino wrote:
> This patch addresses a problem on x86 EFI systems with larger memory
> configurations. Up until now, we've relied on the fact that the
> ACPI RSDT would reside somewhere in low memory that could be permanently
> mapped in kernel address
On Wednesday 03 August 2005 10:24 pm, Alex Williamson wrote:
> On Thu, 2005-08-04 at 14:08 +1000, Peter Chubb wrote:
> > After I sorted out the console problem, it turns out that the MPT
> > fusion driver is no longer enabled in the ZX1_defconfig.
> >
> > Should it be? What machines is configs/zx
On Friday 29 July 2005 5:17 pm, Andrew Morton wrote:
> Khalid Aziz <[EMAIL PROTECTED]> wrote:
> >
> > Serial console is broken on ia64 on an HP rx2600 machine on
> > 2.6.13-rc3-mm3. When kernel is booted up with "console=ttyS,...", no
> > output ever appears on the console and system is hung. So I
Remove references to asm-ia64/segment.h, which is empty.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: work/arch/ia64/pci/pci.c
===
--- work.orig/arch/ia64/pci/pci.c 2005-07-25 15:04:19.0 -0600
+++ wor
Move acpi_map_iosapics() from pci.c to acpi.c, since it doesn't
have anything to do with PCI.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: work/arch/ia64/kernel/acpi.c
===
--- work.orig/arch/ia64/kernel/acpi.
On Fri, 2005-04-22 at 09:53 +0200, Rolf Eike Beer wrote:
> Am Freitag, 22. April 2005 08:38 schrieb Kenji Kaneshige:
> > Hi Bjorn,
>
> > > Nitpick: these declarations should follow the style of the rest
> > > of the file, i.e., add a space between the function name and the
> > > opening parenthesi
On Fri, 2005-04-22 at 15:38 +0900, Kenji Kaneshige wrote:
> Bjorn Helgaas wrote:
> >
> >>+ if ((dev->class >> 8) != PCI_CLASS_SYSTEM_PIC)
> >>+ continue;
> >>+ if ((dev->class & 0xff) == 0x10 || (dev->
On Thu, 2005-04-21 at 15:26 -0500, Mark Maule wrote:
> #ifdef CONFIG_SERIAL_SGI_L1_CONSOLE
> {
> extern int sn_serial_console_early_setup(void);
> if (!sn_serial_console_early_setup())
> - return 0;
> + earlycons++;
>
> +static struct pci_dev *get_apic_pci_info(acpi_handle handle)
Nitpick: follow function declaration style of file.
> + struct acpi_pci_id id;
> + struct pci_bus *bus;
> + struct pci_dev *dev;
> +
> + if (ACPI_FAILURE(acpi_get_pci_id(handle, &id)))
> + return NULL;
> +
> +acpi_status __devinit
> acpi_map_iosapic (acpi_handle handle, u32 depth, void *context, void **ret)
I think "acpi_map_iosapic" is poorly named. It's really associating
an iosapic with a locality domain.
And there's nothing ia64-specific in acpi_map_iosapic(). It'd be
nice to figure out a wa
> +++ linux-2.6.12-rc2-mm3-kanesige/arch/ia64/kernel/acpi.c 2005-04-20
> 10:51:30.136299152 +0900
> @@ -892,4 +892,21 @@ acpi_map_iosapic (acpi_handle handle, u3
> return AE_OK;
> }
> #endif /* CONFIG_NUMA */
> +
> +int
> +acpi_register_ioapic(acpi_handle handle, u64 phys_addr, u32 gsi
corner cases
Patch from [EMAIL PROTECTED] to fix up some corner cases
in ptrace. Many thanks to davidm for reviewing and improving.
Backported to 2.4 by Bjorn Helgaas ([EMAIL PROTECTED]).
<[EMAIL PROTECTED]> (05/03/12 1.1462)
[IA64] Sanity check unw_unwind_to_user
, this touches both acpi and ia64. Let me know if this is
a problem.
This patch may be used under either the GPL or the BSD license.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
= arch/ia64/kernel/acpi-ext.c 1.5 vs edited =
--- 1.5/arch/ia64/kernel/acpi-ext.c 2004-10-05 12
out EFI RT attribute (Bjorn Helgaas).
- fix FPH state check to keep task from seeing another task's regs (Arun
Sharma).
- fix pte_modify bug that allowed mprotect() to change too many bits (David
Mosberger).
- add unw_unwind_to_user() sanity check (Keith Owens).
- add missi
On Sun, 2005-02-20 at 11:38 +0100, Alexander Nyberg wrote:
> = arch/ia64/ia32/ia32_signal.c 1.35 vs edited =
> --- 1.35/arch/ia64/ia32/ia32_signal.c 2005-01-25 21:23:45 +01:00
> +++ edited/arch/ia64/ia32/ia32_signal.c 2005-02-20 11:32:55 +01:00
> @@ -460,9 +460,9 @@ __ia32_rt_sigsuspe
Rewrap a few long lines, add KERN_* and "PCI: " prefixes, etc.
No functional changes.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
= arch/ia64/pci/pci.c 1.65 vs edited =
--- 1.65/arch/ia64/pci/pci.c2005-01-12 11:08:48 -07:00
+++ edited/arch/ia64/pci/pci.c 200
On Thu, 2005-02-03 at 12:18 -0800, H. J. Lu wrote:
> I am testing the ia64 assembler changes on 2.4 and 2.6 kernel. Which
> 2.4 kernel tree should I use?
The most recent 2.4 patch for ia64 is here:
ftp://ftp.kernel.org/pub/linux/kernel/ports/ia64/v2.4/linux-2.4.26-ia64-040510.diff.bz2
I hav
-
arch/x86_64/pci/mmconfig.c |8 --
include/linux/pci.h|6 +++--
7 files changed, 51 insertions(+), 46 deletions(-)
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
= arch/i386/pci/direct.c 1.19 vs edited =
--- 1.19/arch/i386/pci/direct.c 2004-0
Always use cpu_physical_id() (which is really the ID/EID of
a processor's Local SAPIC) when programming IOSAPIC entries.
Previously we sometimes used hard_smp_processor_id(), which
is correct when CONFIG_SMP=y but wrong otherwise.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
On Tue, 2005-01-25 at 12:47 -0800, Luck, Tony wrote:
> >Ah, yes, that looks wrong. Looks like the check for (seg > 255) came
> >from the original pci_sal_read(). The original pci_sal_ext_read() did
> >check for (seg > 65535). My bad.
> >
> >Thanks for catching this.
>
>
> So you (and Matthew W
On Wed, 2005-01-19 at 10:38 -0800, Luck, Tony wrote:
> >> Does the EFI memory map help here? Is I/O memory included
> >> in the efi memory map? What about the hot-plug case ... the
> >> EFI memory map isn't updated for new i/o memory that appears
> >> when you plug in a new card?
> >
> >I think i
83 matches
Mail list logo
