login
Search
| From | Subject | Date |
|---|---|---|
| Sergei Trofimovich | uml: sparse inlines gcc-4.{2,3} compilation hack
Hi!
Small ARCH=um SUBARCH=i386 .config is in attach.
How to fix properly such kind of miscompilation? (gcc-4.3.1)
Now I have to use hacks like this:
uml: sparse inlines gcc-4.{2,3} compilation fix.
Patch fixes stuff like this:
CC mm/filemap.o
/mnt/ext/backup3/dev/git/linux-2.6/mm/filemap.c: In function '__generic_file_aio_write_nolock':
/mnt/ext/backup3/dev/git/linux-2.6/mm/filemap.c:1838: sorry, unimplemented: inlining failed in call to 'generic_write_checks': fun...
| Jul 10, 8:43 am 2008 |
| Robert Hancock | Re: Providing access to kernel memory from PCI bus
You should likely allocate the memory that you are making available to
the device using dma_alloc_coherent. That will give you a bus address
that points to the memory that you can give to your device.
--
| Jul 10, 7:44 pm 2008 |
| Jeremy Fitzhardinge | [PATCH 2/2] xen64: disable 32-bit syscall/sysenter if not su...
Old versions of Xen (3.1 and before) don't support sysenter or syscall
from 32-bit compat userspaces. If we can't set the appropriate
syscall callback, then disable the corresponding feature bit, which
will cause the vdso32 setup to fall back appropriately.
Linux assumes that syscall is always available to 32-bit userspace,
and installs it by default if sysenter isn't available. In that case,
we just disable vdso altogether, forcing userspace libc to fall back
to int $0x80.
Signed-off-by: Jere...
| Jul 10, 7:24 pm 2008 |
| Jeremy Fitzhardinge | [PATCH 1/2] x86_64: add pseudo-features for 32-bit compat sy...
Add pseudo-feature bits to describe whether the CPU supports sysenter
and/or syscall from ia32-compat userspace. This removes a hardcoded
test in vdso32-setup.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
arch/x86/kernel/cpu/centaur_64.c | 2 ++
arch/x86/kernel/cpu/common_64.c | 3 +++
arch/x86/kernel/cpu/intel_64.c | 2 ++
include/asm-x86/cpufeature.h | 4 ++--
4 files changed, 9 insertions(+), 2 deletions(-)
==============================...
| Jul 10, 7:22 pm 2008 |
| Mikulas Patocka | [SUGGESTION]: drop virtual merge accounting in I/O requests
Hi
I'm getting crashes with InitIO A100u2w controller on Sparc64 (I had to
fix the endianity issues in the driver, but that's unrelated).
When I examined the crashes, it turned out that SCSI layer passed requests
with too many segments. The controller has at most 32 SG entries per
request. It sets shost->sg_tablesize to 32, but despite this, larger
requests were submitted to it --- this resulted in overwriting random
memory and crashes.
A typical scenario, in the beginning of inia100_q...
| Jul 10, 5:56 pm 2008 |
| Julian Calaby | Re: [SUGGESTION]: drop virtual merge accounting in I/O reque...
[snip]
Should this have been CC'd to linux-scsi too? This sounds like it
could be a bug at their end.
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
--
| Jul 10, 6:59 pm 2008 |
| Mikulas Patocka | Re: [SUGGESTION]: drop virtual merge accounting in I/O reque...
This is not a bug in scsi layer, those "nr_hw_segments" miscalculations
are hapenning in block/blk-merge.c and they can show up with any block
device driver that has small number of SG entries.
But I can CC it there, just for their information.
Mikulas
--
| Jul 10, 7:57 pm 2008 |
| Eric W. Biederman | [PATCH] Enable polling for disabled screaming irqs
When we disable a screaming irq we never see it again. If the irq
line is shared or if the driver half works this is a real pain. So
periodically poll the handlers for screaming interrupts.
I use a timer instead of the classic irq poll technique of working off
the timer interrupt because when we use the local apic timers
note_interrupt is never called (bug?). Further on a system with
dynamic ticks the timer interrupt might not even fire unless there is
a timer telling it it needs to.
I forc...
| Jul 10, 5:48 pm 2008 |
| Roland McGrath | [PATCH] x86_64: fix delayed signals
On three of the several paths in entry_64.S that call
do_notify_resume() on the way back to user mode, we fail to properly
check again for newly-arrived work that requires another call to
do_notify_resume() before going to user mode. These paths set the
mask to check only _TIF_NEED_RESCHED, but this is wrong. The other
paths that lead to do_notify_resume() do this correctly already, and
entry_32.S does it correctly in all cases.
All paths back to user mode have to check all the _TIF_WORK_MASK
fl...
| Jul 10, 5:50 pm 2008 |
| Linus Torvalds | Re: [PATCH] x86_64: fix delayed signals
I have this dim memory of at least _some_ of this being on purpose.
If you look at old kernels (_really_ old ones - I think it's way before
even the historical git archive, but I didn't take a look), we used to set
up several stack frames at once, so that we'd nest the stack frames
completely.
In other words, the code in do_signal() used to literally be a loop,
something like
while ((signr = get_signal_to_deliver(&info, &ka, regs, NULL)) > 0) {
.. setup signal frame ..
...
| Jul 10, 6:06 pm 2008 |
| Roland McGrath | Re: [PATCH] x86_64: fix delayed signals
I don't think so. Firstly, TIF_SIGPENDING is not the only flag in
question. There are other reasons to re-enter do_notify_resume().
If those are set during signal processing et al, they should take
effect before going back to user mode.
Second, there is always a race. Anywhere after the last time the
siglock was held inside do_signal(), there can be an interrupt that
sets TIF_SIGPENDING (or other _TIF_DO_NOTIFY_MASK flags). If you go
on to return to user mode, then it can be a long time befor...
| Jul 10, 6:42 pm 2008 |
| Linus Torvalds | Re: [PATCH] x86_64: fix delayed signals
You're ignoring the background question - we expressly _stopped_ doing
this long ago. So the real issue was the ".. if you really .." part.
Do we really? What's the actual downside here?
Linus
--
| Jul 10, 6:51 pm 2008 |
| Linus Torvalds | Re: [PATCH] x86_64: fix delayed signals
Side note: the fact that 32-bit does it seems to imply it's ok, but it
bothers me that I know we changed the signal code at some point. Is the
64-bit code doing the exact _same_ things as 32-bit now?
Linus
--
| Jul 10, 7:02 pm 2008 |
| Milton Miller | [RFC] (almost) booting allyesconfig -- please don't poke sup...
After the following patch to mark the isa region busy and applying a few
patches[1], I was able to kexec boot into an all-yes-config kernel from
linux-next, with the following KCONFIG_ALLCONFIG file:
# CONFIG_KALLSYMS_EXTRA_PASS is not set
# CONFIG_CRASH_DUMP is not set
CONFIG_PPC_EARLY_DEBUG_RTAS_CONSOLE=y
# CONFIG_NSC_FIR is not set
# CONFIG_SMC_IRCC_FIR is not set
# CONFIG_ALI_FIR is not set
# CONFIG_TCG_NSC is not set
# CONFIG_TCG_ATMEL is not set
# CONFIG_SENSORS_F71805F is not set
# CON...
| Jul 10, 5:12 pm 2008 |
| Hans de Goede | Re: [lm-sensors] [RFC] (almost) booting allyesconfig -- plea...
Erm,
The superio sensor drivers only poke the superio chip registers without request
region during the probe phase, iow they try to detect the chip, using a widely
document and standardized (part of isa pnp AFAIK) procedure on standardized ports.
Let me try to explain a bit about superio chips, they have 2 superio control
registers (an index and data register) with which things like a manufacturer
and device id can be read, besides these id registers they also have a set of
registers with ...
| Jul 10, 5:33 pm 2008 |
| Milton Miller | Re: [lm-sensors] [RFC] (almost) booting allyesconfig -- plea...
My point is that they are probing without even knowing that a such a IO
range exists.
These are the only drivers left in the tree that still do this. (At
least that are not
blocked on a powerpc allyesconfig for 64-bit, !CONFIG_VIRT_TO_BUS).
One could make a superio driver, and create sub-devices for the IR,
I2C, floppy, parallel, etc
nodes.
I would even accept a check_region (horrors!), it would impove the
situation.
But most other drivers do this by request_region, probe, then re...
| Jul 10, 5:51 pm 2008 |
| Milton Miller | mtd: remove __PPC__ hardcoded address from nand/diskonchip a...
Such a hardcoded address can cause a checkstop or machine check if
the driver is in the kernel but the address is not acknowledged.
Both drivers allow an address to be specified as either a module
parameter or config option. Any future powerpc board should either
use one of these methods or find the address in the device tree.
Signed-off-by: Milton Miller <miltonm@bga.com>
---
There is no powerpc defconfig that sets either CONFIG_DOC200{0,1*} nor
CONFIG_MTD_NAND_DISKONCHIP in next-200807...
| Jul 10, 5:14 pm 2008 |
| Rafael J. Wysocki | Re: ACPI Error under 2.6.26-rc*
[Adding CCs.]
> [ 23.207961] PM: Adding info for No Bus:vcsa7
| Jul 10, 4:55 pm 2008 |
| Luck, Tony | [PATCH] Fix ia64 simserial.c for Ldisc revamp
This driver is "hidden" in arch/ia64 ... so it didn't get updated
by the Ldisc revamp.
Signed-off-by: Tony Luck <tony.luck@intel.com>
diff --git a/arch/ia64/hp/sim/simserial.c b/arch/ia64/hp/sim/simserial.c
index 23cafc8..f870bbf 100644
--- a/arch/ia64/hp/sim/simserial.c
+++ b/arch/ia64/hp/sim/simserial.c
@@ -354,8 +354,8 @@ static void rs_flush_buffer(struct tty_struct *tty)
wake_up_interruptible(&tty->write_wait);
if ((tty->flags & (1 << TTY_DO_WR...
| Jul 10, 4:46 pm 2008 |
| Hugh Dickins | [Bug 11063][PATCH] exec: fix stack excutability without PT_G...
Kernel Bugzilla #11063 points out that on some architectures (e.g. x86_32)
exec'ing an ELF without a PT_GNU_STACK program header should default to an
executable stack; but this got broken by the unlimited argv feature because
stack vma is now created before the right personality has been established:
so breaking old binaries using nested function trampolines.
Therefore re-evaluate VM_STACK_FLAGS in setup_arg_pages, where stack
vm_flags used to be set, before the mprotect_fixup. Checking through
ou...
| Jul 10, 4:19 pm 2008 |
| pageexec | Re: [Bug 11063][PATCH] exec: fix stack excutability without ...
alternatively, if there's a concern of stack_vma->vm_flags manipulation
during execve (maybe not now, but in the future or in non-ELF formats
that also want to rely on personality bits), you could opt for a safer
vm_flags = vma->vm_flags | (VM_STACK_FLAGS & (VM_EXEC | VM_MAYEXEC));
--
| Jul 10, 5:21 pm 2008 |
| Mark Fasheh | [git patch] one more ocfs2 regression fix
Thanks to Geoffrey Pan for reporting this and testing the fix so quickly. I
also verified this fix on my test cluster today, since things are getting
down to the wire. It's definitely 2.6.26 material.
--Mark
Please pull from 'upstream-linus' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/mfasheh/ocfs2.git upstream-linus
to receive the following updates:
fs/ocfs2/dlmglue.c | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
From: Mark Fasheh <mfasheh@suse.co...
| Jul 10, 4:01 pm 2008 |
| Sergei Trofimovich | uml: sparse inlines gcc-4.{2,3} compilation hack
Hi!
Small ARCH=um SUBARCH=i386 .config is in attach.
How to fix properly such kind of miscompilation? (gcc-4.3.1)
Now I have to use hacks like this:
uml: sparse inlines gcc-4.{2,3} compilation fix.
Patch fixes stuff like this:
CC mm/filemap.o
/mnt/ext/backup3/dev/git/linux-2.6/mm/filemap.c: In function '__generic_file_aio_write_nolock':
/mnt/ext/backup3/dev/git/linux-2.6/mm/filemap.c:1838: sorry, unimplemented: inlining failed in call to 'generic_write_checks': fun...
| Jul 10, 8:50 am 2008 |
| Jeff Dike | Re: uml: sparse inlines gcc-4.{2,3} compilation hack
Use the patch below instead.
Jeff
--
Work email - jdike at linux dot intel dot com
commit 4f81c5350b44bcc501ab6f8a089b16d064b4d2f6
Author: Jeff Dike <jdike@addtoit.com>
Date: Mon Jul 7 13:36:56 2008 -0400
[UML] fix gcc ICEs and unresolved externs
There are various constraints on the use of unit-at-a-time:
- i386 uses no-unit-at-a-time for pre-4.0 (not 4.3)
- x86_64 uses unit-at-a-time always
Uli reported a crash on x86_64 with...
| Jul 10, 4:42 pm 2008 |
| Jeff Dike | Re: UML kernel failed to start betvee 2.6.8-rc8 and current ...
OK, I believe you're seeing the same bug as Uli saw here:
http://marc.info/?l=linux-kernel&m=121011518003727&w=2
More precise symptoms are here:
http://marc.info/?l=linux-kernel&m=121011722806093&w=2
I never did figure that one out. I had the same kernel version, same
toolchain, same everything as far as I could see, and I couldn't
reproduce it, except with a binary that he gave me.
You're seeing it on i386, whereas he saw it on x86_64.
The underlying problem ...
| Jul 10, 3:30 pm 2008 |
| Mark Rustad | [PATCH] IPMI: return correct value from ipmi_write
From: Mark Rustad <MRustad@gmail.com>
This patch corrects the handling of write operations to the IPMI watchdog
to work as intended by returning the number of characters actually
processed. Without this patch, an "echo V >/dev/watchdog" enables the
watchdog if IPMI is providing the watchdog function.
Signed-off-by: Mark Rustad <MRustad@gmail.com>
---
I have not checked all of the watchdogs to see if there are others that have
this problem, but the one I was using before using the ...
| Jul 10, 3:27 pm 2008 |
| Corey Minyard | Re: [Openipmi-developer] [PATCH] IPMI: return correct value ...
This patch is correct.
Signed-off-by: Corey Minyard <cminyard@mvista.com>
--
| Jul 10, 4:16 pm 2008 |
| Alexander van Heukelum | [PATCH 1/2] x86: traps_xx: refactor die() like in x86_64
Make the diff between the traps_32.c and traps_64.c a bit smaller.
Change traps_32.c to look more like traps_64.c:
- move lock information to file scope
- split out oops_begin() and oops_end() from die()
- increment nest counter in oops_begin
Only whitespace change in traps_64.c
Signed-off-by: Alexander van Heukelum <heukelum@fastmail.fm>
---
arch/x86/kernel/traps_32.c | 95 +++++++++++++++++++++++--------------------
arch/x86/kernel/traps_64.c | 2 +-
2 files changed, 52 inse...
| Jul 10, 3:14 pm 2008 |
| Alexander van Heukelum | [PATCH 2/2] x86: traps_xx: modify x86_64 to use _log_lvl var...
i386 has show_trace_log_lvl and show_stack_log_lvl, allowing
traces to be emitted with log-level annotations. This patch
introduces them to x86_64, but log_lvl is only ever set to
an empty string. Output of traces is unchanged.
i386-chunk is whitespace-only.
Signed-off-by: Alexander van Heukelum <heukelum@fastmail.fm>
---
arch/x86/kernel/traps_32.c | 2 +-
arch/x86/kernel/traps_64.c | 24 ++++++++++++++++--------
2 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/arch...
| Jul 10, 3:16 pm 2008 |
| Philipp Zabel | [PATCH 2/2] regulator: virtual consumer current limit support
This expands the virtual consumer driver to handle current limit control
via the min_microamps and max_microamps sysfs files.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
---
drivers/regulator/virtual.c | 99 +++++++++++++++++++++++++++++++++++++++++-
1 files changed, 96 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/virtual.c b/drivers/regulator/virtual.c
index 7018f1c..5ddb464 100644
--- a/drivers/regulator/virtual.c
+++ b/drivers/regulator/virtual.c
@@ -22,1...
| Jul 10, 3:04 pm 2008 |
| Philipp Zabel | [PATCH 1/2] regulator: TI bq24022 Li-Ion Charger driver
This adds a regulator driver for the TI bq24022 Single-Chip
Li-Ion Charger with its nCE and ISET2 pins connected to GPIOs.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
---
drivers/regulator/Kconfig | 10 ++
drivers/regulator/Makefile | 2 +
drivers/regulator/bq24022.c | 167 +++++++++++++++++++++++++++++++++++++
include/linux/regulator/bq24022.h | 23 +++++
4 files changed, 202 insertions(+), 0 deletions(-)
create mode 100644 drivers/regulator/bq2402...
| Jul 10, 3:04 pm 2008 |
| Philipp Zabel | [PATCH 0/2] TI bq24022 regulator and virtual consumer curren...
Hi,
I'd be happy if the following two patches could be reviewed and
considered for inclusion into the voltage regulator framework git tree.
[PATCH 1/2] regulator: TI bq24022 Li-Ion Charger driver
[PATCH 2/2] regulator: virtual consumer current limit support
The bq24022 regulator is found on magician and blueangel among others
and can be used to control VBUS current draw from the gpio_vbus
(controlled by USB gadget) or pda_power (when connected to the wall
charger) drivers.
regards
Philipp
...
| Jul 10, 3:04 pm 2008 |
| Suresh Siddha | [patch 04/26] x64, x2apic/intr-remap: use CONFIG_DMAR for DM...
DMA remapping specific code covered with CONFIG_DMAR in
the generic code which will also be used later for enabling Interrupt-remapping.
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
---
Index: tree-x86/drivers/pci/dmar.c
===================================================================
--- tree-x86.orig/drivers/pci/dmar.c 2008-07-10 09:51:51.000000000 -0700
+++ tree-x86/drivers/pci/dmar.c 2008-07-10 09:51:53.000000000 -0700
@@ -39,7 +39,6 @@
* these units are not supported...
| Jul 10, 2:16 pm 2008 |
| Suresh Siddha | [patch 03/26] x64, x2apic/intr-remap: code re-structuring, t...
Allocate the iommu during the parse of DMA remapping hardware
definition structures. And also, introduce routines for device
scope initialization which will be explicitly called during
dma-remapping initialization.
These will be used for enabling interrupt remapping separately from the
existing DMA-remapping enabling sequence.
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
---
Index: tree-x86/drivers/pci/dmar.c
==================================================================...
| Jul 10, 2:16 pm 2008 |
| Suresh Siddha | [patch 08/26] x64, x2apic/intr-remap: Queued invalidation in...
Queued invalidation (part of Intel Virtualization Technology for
Directed I/O architecture) infrastructure.
This will be used for invalidating the interrupt entry cache in the
case of Interrupt-remapping and IOTLB invalidation in the case
of DMA-remapping.
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
---
Index: tree-x86/drivers/pci/dmar.c
===================================================================
--- tree-x86.orig/drivers/pci/dmar.c 2008-07-10 09:51:57.000000000 -07...
| Jul 10, 2:16 pm 2008 |
| Suresh Siddha | [patch 11/26] x64, x2apic/intr-remap: generic irq migration ...
Generic infrastructure for migrating the irq from the process context in the
presence of CONFIG_GENERIC_PENDING_IRQ.
This will be used later for migrating irq in the presence of
interrupt-remapping.
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
---
Index: tree-x86/include/linux/irq.h
===================================================================
--- tree-x86.orig/include/linux/irq.h 2008-07-10 09:51:45.000000000 -0700
+++ tree-x86/include/linux/irq.h 2008-07-10 09:52:07....
| Jul 10, 2:16 pm 2008 |
| Eric W. Biederman | Re: [patch 11/26] x64, x2apic/intr-remap: generic irq migrat...
Why the API difference between IRQ_MOVE_PCNTXT set affinity handlers and
--
| Jul 10, 7:08 pm 2008 |
| Suresh Siddha | [patch 02/26] x64, x2apic/intr-remap: fix the need for seque...
Clean up the intel-iommu code related to deferred iommu flush logic. There is
no need to allocate all the iommu's as a sequential array.
This will be used later in the interrupt-remapping patch series to
allocate iommu much early and individually for each device remapping
hardware unit.
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
---
Index: tree-x86/drivers/pci/dmar.c
===================================================================
--- tree-x86.orig/drivers/pci/dmar.c 20...
| Jul 10, 2:16 pm 2008 |
| Suresh Siddha | [patch 07/26] x64, x2apic/intr-remap: move IOMMU_WAIT_OP() m...
move IOMMU_WAIT_OP() macro to header file.
This will be used by both DMA-remapping and Intr-remapping.
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
---
Index: tree-x86/drivers/pci/intel-iommu.c
===================================================================
--- tree-x86.orig/drivers/pci/intel-iommu.c 2008-07-10 09:51:51.000000000 -0700
+++ tree-x86/drivers/pci/intel-iommu.c 2008-07-10 09:51:59.000000000 -0700
@@ -49,8 +49,6 @@
#define DEFAULT_DOMAIN_ADDRESS_WIDTH 48
...
| Jul 10, 2:16 pm 2008 |
| Suresh Siddha | [patch 05/26] x64, x2apic/intr-remap: Fix the need for RMRR ...
Presence of RMRR structures is not compulsory for enabling DMA-remapping.
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Yong Y Wang <yong.y.wang@intel.com>
---
Index: tree-x86/drivers/pci/dmar.c
===================================================================
--- tree-x86.orig/drivers/pci/dmar.c 2008-07-10 09:51:53.000000000 -0700
+++ tree-x86/drivers/pci/dmar.c 2008-07-10 09:51:55.000000000 -0700
@@ -419,10 +419,8 @@
}
#ifdef CONFIG_DMAR
- if (l...
| Jul 10, 2:16 pm 2008 |
| Suresh Siddha | [patch 18/26] x64, x2apic/intr-remap: x2apic ops for x2apic ...
x2apic ops for x2apic mode support. This uses MSR interface and differs
slightly from the xapic register layout.
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
---
Index: tree-x86/arch/x86/kernel/apic_64.c
===================================================================
--- tree-x86.orig/arch/x86/kernel/apic_64.c 2008-07-10 09:52:14.000000000 -0700
+++ tree-x86/arch/x86/kernel/apic_64.c 2008-07-10 09:52:22.000000000 -0700
@@ -171,6 +171,41 @@
EXPORT_SYMBOL_GPL(apic_ops);
...
| Jul 10, 2:16 pm 2008 |
| Suresh Siddha | [patch 06/26] x64, x2apic/intr-remap: parse ioapic scope und...
Parse the vt-d device scope structures to find the mapping between IO-APICs
and the interrupt remapping hardware units.
This will be used later for enabling Interrupt-remapping for IOAPIC devices.
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
---
Index: tree-x86/drivers/pci/Makefile
===================================================================
--- tree-x86.orig/drivers/pci/Makefile 2008-07-10 09:51:45.000000000 -0700
+++ tree-x86/drivers/pci/Makefile 2008-07-10 09:51:57....
| Jul 10, 2:16 pm 2008 |
| Suresh Siddha | [patch 26/26] x64, x2apic/intr-remap: introduce CONFIG_INTR_...
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
---
Index: tree-x86/arch/x86/Kconfig
===================================================================
--- tree-x86.orig/arch/x86/Kconfig 2008-07-10 09:51:44.000000000 -0700
+++ tree-x86/arch/x86/Kconfig 2008-07-10 09:52:43.000000000 -0700
@@ -1657,6 +1657,14 @@
workaround will setup a 1:1 mapping for the first
16M to make floppy (an ISA device) work.
+config INTR_REMAP
+ bool "Support for Interrupt Remapping (EXPERIMENTAL...
| Jul 10, 2:17 pm 2008 |
| Eric W. Biederman | Re: [patch 26/26] x64, x2apic/intr-remap: introduce CONFIG_I...
This has got to be the strangest config option.
X86_IO_APIC makes sense. Fundamentally it is the wrong config option but that
isn't the fault of your code.
PCI_MSI should not matter.
Is it possible to run in x2apic mode without running in interrupt remapping mode?
Just send the irqs directly to the cpu? It feels like it should be if an iommu
doesn't get in the way.
Eric
--
| Jul 10, 7:29 pm 2008 |
| Yong Wang | Re: [patch 26/26] x64, x2apic/intr-remap: introduce CONFIG_I...
Yes, it is possible to run in x2apic mode without intr-remap. However, the extended
cpu addressability will not be fully utilized that way.
--
| Jul 10, 7:37 pm 2008 |
| Suresh Siddha | [patch 25/26] x64, x2apic/intr-remap: support for x2apic phy...
x2apic Physical mode support. By default we will use x2apic cluster mode.
x2apic physical mode can be selected using "x2apic_phys" boot parameter.
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
---
Index: tree-x86/arch/x86/kernel/Makefile
===================================================================
--- tree-x86.orig/arch/x86/kernel/Makefile 2008-07-10 09:52:27.000000000 -0700
+++ tree-x86/arch/x86/kernel/Makefile 2008-07-10 09:52:40.000000000 -0700
@@ -105,6 +105,7 @@
i...
| Jul 10, 2:16 pm 2008 |
| Suresh Siddha | [patch 24/26] x64, x2apic/intr-remap: add x2apic support, in...
x2apic support. Interrupt-remapping must be enabled before enabling x2apic,
this is needed to ensure that IO interrupts continue to work properly after the
cpu mode is changed to x2apic(which uses 32bit extended physical/cluster
apic id).
On systems where apicid's are > 255, BIOS can handover the control to OS in
x2apic mode. Or if the OS handover was in legacy xapic mode, check
if it is capable of x2apic mode. And if we succeed in enabling
Interrupt-remapping, then we can enable x2apic mode in...
| Jul 10, 2:16 pm 2008 |
| Suresh Siddha | [patch 23/26] x64, x2apic/intr-remap: MSI and MSI-X support ...
MSI and MSI-X support for interrupt remapping infrastructure.
MSI address register will be programmed with interrupt-remapping table
entry(IRTE) index and the IRTE will contain information about the vector,
cpu destination, etc.
For MSI-X, all the IRTE's will be consecutively allocated in the table,
and the address registers will contain the starting index to the block
and the data register will contain the subindex with in that block.
This also introduces a new irq_chip for cleaner irq migrati...
| Jul 10, 2:16 pm 2008 |
| Suresh Siddha | [patch 16/26] x64, x2apic/intr-remap: cpuid bits for x2apic ...
cpuid feature for x2apic.
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
---
Index: tree-x86/include/asm-x86/cpufeature.h
===================================================================
--- tree-x86.orig/include/asm-x86/cpufeature.h 2008-07-10 09:51:45.000000000 -0700
+++ tree-x86/include/asm-x86/cpufeature.h 2008-07-10 09:52:16.000000000 -0700
@@ -90,6 +90,7 @@
#define X86_FEATURE_CX16 (4*32+13) /* CMPXCHG16B */
#define X86_FEATURE_XTPR (4*32+14) /* Send Task Priority Mes...
| Jul 10, 2:16 pm 2008 |
| Suresh Siddha | [patch 01/26] x64, x2apic/intr-remap: Intel vt-d, IOMMU code...
code reorganization of the generic Intel vt-d parsing related routines and linux
iommu routines specific to Intel vt-d.
drivers/pci/dmar.c now contains the generic vt-d parsing related routines
drivers/pci/intel_iommu.c contains the iommu routines specific to vt-d
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
---
Index: tree-x86/drivers/pci/dmar.c
===================================================================
--- tree-x86.orig/drivers/pci/dmar.c 2008-07-10 09:51:45.000000...
| Jul 10, 2:16 pm 2008 |
| previous day | today | next day |
|---|---|---|
| July 9, 2008 | July 10, 2008 | July 11, 2008 |
| Jon Smirl | 463 kernel developers missing! |
| Nigel Cunningham | Re: [PATCH] Remove process freezer from suspend to RAM pathway |
| Greg KH | Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linux interface for on access scan... |
| Jeff Garzik | Re: Linux 2.6.23-rc9 and a heads-up for the 2.6.24 series.. |
git: | |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Linus Torvalds | Re: [GIT]: Networking |
| Evgeniy Polyakov | Re: [BUG] New Kernel Bugs |
