login
Search
| From | Subject | Date |
|---|---|---|
| Matt Mackall | [PATCH] mm: unify shmem and tiny-shmem
(This applies on top of Nick's second tiny-shmem patch, which hasn't
made it to mainline yet(!). But as this deletes tiny-shmem.c, you can
probably ignore the rejects.)
tiny-shmem shares most of its 130 lines of code with shmem and tends
to break when particular bits of shmem get modified. Unifying saves
code and makes keeping these two in sync much easier.
before:
14367 392 24 14783 39bf mm/shmem.o
396 72 8 476 1dc mm/tiny-shmem.o
after:
14367 39...
| Sep 30, 7:49 pm 2008 |
| Yinghai Lu | [PATCH 1/3] x86: mtrr_cleanup update command line
change enable_mtrr_cleanup to mtrr-cleanup, disable_mtrr_cleanup to nomtrr-cleanup.
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
---
Documentation/kernel-parameters.txt | 4 ++--
arch/x86/Kconfig | 2 +-
arch/x86/kernel/cpu/mtrr/main.c | 4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)
Index: linux-2.6/Documentation/kernel-parameters.txt
===================================================================
--- linux-2.6.orig/Documentation/kern...
| Sep 30, 7:29 pm 2008 |
| Randy Dunlap | Re: [PATCH 1/3] x86: mtrr_cleanup update command line
Looks like Documentation/kernel-parameters.txt needs a comment that says that
entries are supposed to be listed in alphabetical order, not grouped by <subject>.
Please don't add them like this.
E.g., the "apic" entries are not grouped together and these mtrr entries should
not be grouped together unless they all begin with "mtrr", which is an option here:
they could be renamed to "mtrr-cleanup" and "mtrr-nocleanup".
---
~Randy
--
| Sep 30, 7:57 pm 2008 |
| H. Peter Anvin | Re: [PATCH 1/3] x86: mtrr_cleanup update command line
That does collide with the (not always kept) convention of prefixing
"no" to disable a boolean option, though.
-hpa
--
| Sep 30, 7:41 pm 2008 |
| Yinghai Lu | Re: [PATCH 1/3] x86: mtrr_cleanup update command line
it seems should group them and then provide one index section...
YH
--
| Sep 30, 7:52 pm 2008 |
| Yinghai Lu | Re: [PATCH 1/3] x86: mtrr_cleanup update command line
or
1. put all description in .c files
2. have one scripts to search early_param and __setup and create that
kernel_parameter...
YH
--
| Sep 30, 7:59 pm 2008 |
| Yinghai Lu | [PATCH 3/3] x86: change MTRR_SANITIZER to def_bool y
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
---
arch/x86/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6/arch/x86/Kconfig
===================================================================
--- linux-2.6.orig/arch/x86/Kconfig
+++ linux-2.6/arch/x86/Kconfig
@@ -1243,7 +1243,7 @@ config MTRR
See <file:Documentation/x86/mtrr.txt> for more information.
config MTRR_SANITIZER
- bool
+ def_bool y
prompt "MTRR cleanup support"
de...
| Sep 30, 7:29 pm 2008 |
| Yinghai Lu | [PATCH 2/3] x86: doc mtrr-cleanup-debug
doc mtrr-cleanup-debug.
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
---
Documentation/kernel-parameters.txt | 3 +++
arch/x86/kernel/cpu/mtrr/main.c | 2 +-
2 files changed, 4 insertions(+), 1 deletion(-)
Index: linux-2.6/Documentation/kernel-parameters.txt
===================================================================
--- linux-2.6.orig/Documentation/kernel-parameters.txt
+++ linux-2.6/Documentation/kernel-parameters.txt
@@ -620,6 +620,9 @@ and is between 256 and...
| Sep 30, 7:29 pm 2008 |
| Elias Oltmanns | Block: Fix blk_start_queueing() so as not to process a stopp...
Especially since blk_start_queueing() is used as the unplug_fn() callback
by the cfq scheduler, we'd better make it behave like a proper unplug
function. That is to say, return immediately if the queue is stopped.
Cc: stable <stable@kernel.org>
Signed-off-by: Elias Oltmanns <eo@nebensachen.de>
---
This is not a recent regression, so it might not be accepted as an rc
fix. However, it most definitely is a bug and should go into a stable
release. Applies to 2.6.27-rc8.
block/blk-core....
| Sep 30, 7:19 pm 2008 |
| Rusty Russell | [PATCH] x86: clean up speedctep-centrino and reduce cpumask_...
1) The #ifdef CONFIG_HOTPLUG_CPU seems unnecessary these days.
2) The loop can simply skip over offline cpus, rather than creating a tmp mask.
3) set_mask is set to either a single cpu or all online cpus in a policy.
Since it's just used for set_cpus_allowed(), any offline cpus in a policy
don't matter, so we can just use cpumask_of_cpu() or the policy->cpus.
Note: untested, since I don't have such a system.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
diff -r dc205c205c8...
| Sep 30, 7:01 pm 2008 |
| Rusty Russell | [PATCH] x86: remove noop cpus_and() with CPU_MASK_ALL.
I'm not sure what this is supposed to do.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
diff -r 52e0cb95ef98 arch/x86/kernel/io_apic_32.c
--- a/arch/x86/kernel/io_apic_32.c Sat Sep 06 15:18:06 2008 +1000
+++ b/arch/x86/kernel/io_apic_32.c Thu Sep 18 14:30:01 2008 +1000
@@ -346,9 +346,7 @@ static void set_ioapic_affinity_irq(unsi
if (cpus_empty(tmp))
tmp = TARGET_CPUS;
- cpus_and(cpumask, tmp, CPU_MASK_ALL);
-
- apicid_value = cpu_mask_to_apicid(cpumask);
+ apicid_value = ...
| Sep 30, 6:59 pm 2008 |
| Yinghai Lu | Re: [PATCH] x86: remove noop cpus_and() with CPU_MASK_ALL.
can you check tip/master?
http://people.redhat.com/mingo/tip.git/readme.txt
we merged io_apic_32.c and io_apic_64.c to io_apic.c for 2.6.28
also make 32bit to use per-cpu vector....
YH
--
| Sep 30, 7:08 pm 2008 |
| Alex Riesen | NETGEAR WG111v2 (USB RTL8187): freezes whole system when setup
I have an USB wireless card: Netgear WG111v2. It is reported in
syslog as:
usb 4-2: Product: NETGEAR WG111v2
usb 4-2: Manufacturer: NETGEAR WG111v2
usb 4-2: SerialNumber: 000FB5D51ECA
phy1: Selected rate control algorithm 'pid'
phy1: hwaddr 00:0f:b5:d5:1e:ca, RTL8187vB (default) V1 + rtl8225
usbcore: registered new interface driver rtl8187
On ifconfig up, the card always locks up two very different systems: a
relatively modern P4 desktop and P-MMX laptop with UHCI (ancie...
| Sep 30, 6:27 pm 2008 |
| Christian | Re: exception Emask 0x0 SAct 0x1 / SErr 0x0 action 0x2 frozen
I'm also experiencing the same issue..
These messages have been coming in from time to time (sometimes a couple per day). I've tried getting around with this with various kernel settings such as noapic with no luck.
The drives are running on a Supermicro 8 port SATA card (AOC-SAT2-MV8) that's plugged into a standard PCI slot (not pci-x).
01:07.0 SCSI storage controller: Marvell Technology Group Ltd. MV88SX6081 8-port SATA II PCI-X Controller (rev 09)
ata10.00: exception Emask 0x0 SAct 0x1 S...
| Sep 30, 6:04 pm 2008 |
| Sitsofe Wheeler | [PATCH] PCIE: Reduce cannot add device warnings to KERN_INFO
On my EeePC 900 when the wired and wireless ethernet are enabled and the
system is booted with pciehp.pciehp_force=1 the following when booting
with the quiet parameter:
pciehp: Device 0000:03:00.0 already exists at 3:0, cannot hot-add
pciehp: Cannot add device 0x3:0
pciehp: Device 0000:01:00.0 already exists at 1:0, cannot hot-add
pciehp: Cannot add device 0x1:0
This changed prevents the messages turning up during a quiet boot.
Signed-off-by: Sitsofe Wheeler <sitsofe@yahoo.com>
--
| Sep 30, 6:22 pm 2008 |
| Yinghai Lu | [PATCH] x86: mtrr_cleanup update command line and doc mtrr-c...
change enable_mtrr_cleanup to mtrr-cleanup, disable_mtrr_cleanup to nomtrr-cleanup.
so doc mtrr-cleanup-debug.
v2: some _ to -
and change MTRR_SANITIZER to def_bool y
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
---
Documentation/kernel-parameters.txt | 7 +++++--
arch/x86/Kconfig | 6 +++---
arch/x86/kernel/cpu/mtrr/main.c | 6 +++---
3 files changed, 11 insertions(+), 8 deletions(-)
Index: linux-2.6/Documentation/kernel-parameters.txt
======...
| Sep 30, 6:06 pm 2008 |
| H. Peter Anvin | Re: [PATCH] x86: mtrr_cleanup update command line and doc mt...
Could you split that into two patches, please?
-hpa
--
| Sep 30, 7:11 pm 2008 |
| Yinghai Lu | Re: [PATCH] x86: mtrr_cleanup update command line and doc mt...
will split into three.
YH
--
| Sep 30, 7:13 pm 2008 |
| Yinghai Lu | [PATCH] x86: mtrr_cleanup update command line and doc mtrrcl...
change enable_mtrr_cleanup to mtrrcleanup, disable_mtrr_cleanup to nomtrrcleanup.
so doc mtrrcleanup_debug.
and change MTRR_SANITIZER to def_bool y
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
---
Documentation/kernel-parameters.txt | 7 +++++--
arch/x86/Kconfig | 6 +++---
arch/x86/kernel/cpu/mtrr/main.c | 6 +++---
3 files changed, 11 insertions(+), 8 deletions(-)
Index: linux-2.6/Documentation/kernel-parameters.txt
============================...
| Sep 30, 6:01 pm 2008 |
| H. Peter Anvin | Re: [PATCH] x86: mtrr_cleanup update command line and doc mt...
Looks good to me.
Acked-by: H. Peter Anvin <hpa@zytor.com>
I'll add it to tip:x86/mtrr in a bit.
-hpa
--
| Sep 30, 6:03 pm 2008 |
| Quentin Godfroy | possible (ext4 related?) memory leak in kernel 2.6.26
Hi lists,
I'd like to report the following problem : after ~ 10 days' uptime on a
Debian 2.6.26-1-686 kernel, my system becomes extremely sluggish and
unresponsive and the OOM-killer starts targeting even innocent processes like
identd or rsync (when the swap is disabled). The machine is low on RAM (192
MB) but this has never been a problem before. As for the slowness, strace
shows that the brk() syscall takes ages to complete; the blocking processes
are in the D state (and for some reason the kern...
| Sep 30, 4:27 pm 2008 |
| Theodore Tso | Re: possible (ext4 related?) memory leak in kernel 2.6.26
[ Reply-to set to linux-ext4@vger.kernel.org ]
Can you send the output of /proc/meminfo and /proc/slabinfo?
- Ted
--
| Sep 30, 5:18 pm 2008 |
| Quentin | Re: possible (ext4 related?) memory leak in kernel 2.6.26
Of course. However since I unmounted and remounted /home the 'buffer' line
is now only 59megs, and they are still not dropped when a program tries to
malloc all the memory. I'll tell next time the problem shows up (it
can take ten days)
MemTotal: 190356 kB
MemFree: 12300 kB
Buffers: 59652 kB
Cached: 21612 kB
SwapCached: 5508 kB
Active: 84868 kB
Inactive: 78116 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 190356 k...
| Sep 30, 6:23 pm 2008 |
| Krzysztof Helt | [PATCH] x86: do not allow to optimize flag_is_changeable_p()...
From: Krzysztof Helt <krzysztof.h1@wp.pl>
The flag_is_changeable_p() is used by
has_cpuid_p() which can return different results
in the code sequence below:
if (!have_cpuid_p())
identify_cpu_without_cpuid(c);
/* cyrix could have cpuid enabled via c_identify()*/
if (!have_cpuid_p())
return;
Otherwise, the gcc 3.4.6 optimizes these two calls
into one which make the code not working correctly.
Cyrix cpus have the CPUID instruction enabled before
the second call to t...
| Sep 30, 5:17 pm 2008 |
| Serge E. Hallyn | Re: [PATCH 02/14] LSM/SELinux: inode_{get,set,notify}secctx ...
Hmm, sorry, for all of these new hooks which you introduce, you do not
define empty cap_* versions and assign them when need in
security_fixup_ops(). But you unconditionally call them if
CONFIG_SECURITY=y. So if you compile a kernel with CONFIG_SECURITY=y
--
| Sep 30, 4:22 pm 2008 |
| Serge E. Hallyn | Sep 30, 4:15 pm 2008 | |
| Elias Oltmanns | Rounding conventions for jiffies_to_msecs / msecs_to_jiffies
Hi all,
since I don't really understand the algorithm in jiffies_to_msecs() for
HZ values that are not divisors or multiples of 1000 right now, I'd like
to ask if somebody can tell me something about it. In particular, I'd
like to know what we can assume wrt rounding, i.e. always round up /
down, etc. In fact, I'm most interested in the case where the argument
of jiffies_to_msecs() is close to zero. Can I safely assume that a
non-zero argument will *always* result in a non-zero return value
whatev...
| Sep 30, 4:05 pm 2008 |
| Serge E. Hallyn | Re: [PATCH 02/14] LSM/SELinux: inode_{get,set,notify}secctx ...
sentence above is odd. How about
'called with inode->i_mutex locked' would make more sense here.
Requirements on the callers would make more sense in the comments
in include/linux/security.h, right?
No code objections, though.
--
| Sep 30, 4:01 pm 2008 |
| Howard Chu | APIC frequency too slow on HP dv5z
More often than not, on a warm boot I see something like this
msg.new:[ 1.940031] Using local APIC timer interrupts.
msg.new:[ 1.944031] APIC timer calibration result 466046
msg.new:[ 1.944031] Detected 0.466 MHz APIC timer.
msg.new:[ 1.944031] APIC frequency too slow, disabling apic timer
On cold boots it may see 12.5MHz, or may not...
[ 2.000584] Using local APIC timer interrupts.
[ 2.004067] APIC timer calibration result 12500236
[ 2.004080] Detected 12.500 MHz APIC tim...
| Sep 30, 3:55 pm 2008 |
| Thomas Gleixner | [RFC patch 3/3] x86: hookup sys_rt_tgsigqueueinfo
Make the new sys_rt_tgsigqueueinfo available for x86.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
arch/x86/kernel/syscall_table_32.S | 1 +
include/asm-x86/unistd_32.h | 1 +
include/asm-x86/unistd_64.h | 2 ++
3 files changed, 4 insertions(+)
Index: linux-2.6-tip/arch/x86/kernel/syscall_table_32.S
===================================================================
--- linux-2.6-tip.orig/arch/x86/kernel/syscall_table_32.S
+++ linux-2.6-tip/arch/x86/ker...
| Sep 30, 3:49 pm 2008 |
| Thomas Gleixner | [RFC patch 2/3] signals: implement sys_rt_tgsigqueueinfo
sys_kill has the per thread counterpart sys_tgkill. sigqueueinfo is
missing a thread directed counterpart. Such an interface is important
for migrating applications from other OSes which have the per thread
delivery implemented.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
kernel/signal.c | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
Index: linux-2.6-tip/kernel/signal.c
===================================================================
--- linux-2.6-tip.orig...
| Sep 30, 3:49 pm 2008 |
| Thomas Gleixner | [RFC patch 1/3] signals: split do_tkill
Split out the code from do_tkill to make it reusable by the follow up
patch which implements sys_rt_tgsigqueueinfo
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
kernel/signal.c | 31 ++++++++++++++++++++-----------
1 file changed, 20 insertions(+), 11 deletions(-)
Index: linux-2.6-tip/kernel/signal.c
===================================================================
--- linux-2.6-tip.orig/kernel/signal.c
+++ linux-2.6-tip/kernel/signal.c
@@ -2212,24 +2212,20 @@ sys_kill(pid...
| Sep 30, 3:48 pm 2008 |
| Thomas Gleixner | [RFC patch 0/3] signals: add rt_tgsigqueueinfo syscall
sys_kill has a counterpart sys_tgkill which allows to send signals to
a particular thread. sys_rt_sigqueueinfo is lacking such a counterpart.
Aside of the asymetry it is a show stopper for migrating applications
from other unix-alike RTOSes.
The following patch series implements rt_tgsigqueueinfo and hooks it
up for x86.
Find below the raw documentation.
Thanks,
tglx
----
NAME
rt_tgsigqueueinfo - Send signal information to a signal to a thread
SYNOPSIS
long sys_rt_t...
| Sep 30, 3:48 pm 2008 |
| Nicolas Pitre | wrong usage of MAX_DMA_ADDRESS in bootmem.h
I have implemented highmem for ARM. To catch wrong usage of __pa() and
__va() with out of range values, I added a range check when
CONFIG_DEBUG_HIGHMEM is set.
One issue is that bootmem.h uses __pa(MAX_DMA_ADDRESS). However
MAX_DMA_ADDRESS on ARM is defined as 0xffffffff because there is usually
no restriction on the maximum DMA-able address.
RMK suggested that those places should be using ISA_DMA_THRESHOLD
So what about this patch?
diff --git a/include/linux/bootmem.h b/include/linux/...
| Sep 30, 3:35 pm 2008 |
| Christoph Lameter | Re: wrong usage of MAX_DMA_ADDRESS in bootmem.h
ok so do
#define MAX_DMA_ADDRESS ISA_DMA_THRESHOLD
MAX_DMA_ADDRESS is the highest address used for ZONE_DMA / GFP_DMA
Does ISA_DMA_THRESHOLD have any meaning on ARM? If you use old ISA stuff then
you need CONFIG_ZONE_DMA and therefore also MAX_DMA_ADDRESS.
If not then there is no need to define CONFIG_ZONE_DMA and MAX_DMA_ADDRESS
looses its usual meaning.
--
| Sep 30, 3:56 pm 2008 |
| Russell King - ARM Linux | Re: wrong usage of MAX_DMA_ADDRESS in bootmem.h
Not correct. MAX_DMA_ADDRESS is a virtual address. ISA_DMA_THRESHOLD
is the last byte of _physical_ memory which ISA DMA can transfer:
include/asm-x86/scatterlist.h:#define ISA_DMA_THRESHOLD (0x00ffffff)
Incorrect. MAX_DMA_ADDRESS is the highest possible virtual DMA address:
include/asm-x86/dma.h:#define MAX_DMA_ADDRESS (PAGE_OFFSET + 0x1000000)
As we have already covered in the past, CONFIG_ZONE_DMA has to always
be enabled on ARM because ARM always puts all memory in the first ...
| Sep 30, 4:12 pm 2008 |
| Nicolas Pitre | Re: wrong usage of MAX_DMA_ADDRESS in bootmem.h
I just tried this:
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 70dba16..8f609cc 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -148,7 +148,6 @@ config ARCH_MAY_HAVE_PC_FDC
config ZONE_DMA
bool
- default y
config GENERIC_ISA_DMA
bool
with no other changes what so ever. And the resulting kernel still
works fine, with this difference:
|On node 0 totalpages: 131072
|free_area_init_node: node 0, pgdat c03c5e00, node_mem_map c03e7000
| Normal zone: 130048 ...
| Sep 30, 5:09 pm 2008 |
| Andrew Lyon | kernel.org missing .1 incremental patches
Hi,
The incremental patches at
http://www.kernel.org/pub/linux/kernel/v2.6/incr/ seem to be missing
all .1 patches, for example there are patches to take 2.6.25 from
EXTRAVERSION = .2 to .17 but no patch for .0 > .1, attempting to apply
patch-2.6.25.1-2 to 2.6.25 will fail on the Makefile as it does not
have the correct starting version.
I assume the patches are generated from a script and there is a bug,
easily worked around by downloading the full 2.6.25.1 tarball but the
full incremental ...
| Sep 30, 2:51 pm 2008 |
| Rabin Vincent | Re: kernel.org missing .1 incremental patches
There are no incremental patches for .0 -> .1 in incr because those
would be the same as the patch-2.6.xy.1.bz2 patches available at
pub/linux/kernel/v2.6/.
Rabin
--
| Sep 30, 3:17 pm 2008 |
| Andrew Lyon | Re: kernel.org missing .1 incremental patches
Sorry, I should really have figured that out!
Andy
--
| Sep 30, 3:23 pm 2008 |
| Thomas Gleixner | [patch 2/3] timer_list: print cpu number of clockevents device
The per cpu clock events device output of timer_list lacks an
association of the device to the cpu which is annoying when looking at
the output of /proc/timer_list from a 128 way system.
Add the CPU number info and mark the broadcast device in the device
list printout.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
kernel/time/timer_list.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
Index: linux-2.6-tip/kernel/time/timer_list.c
========================...
| Sep 30, 2:44 pm 2008 |
| Thomas Gleixner | [patch 3/3] timer_list: add base address to clock base
The base address of a (per cpu) clock base is a useful debug info.
Add it and bump the version number of timer_lists.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
kernel/time/timer_list.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: linux-2.6-tip/kernel/time/timer_list.c
===================================================================
--- linux-2.6-tip.orig/kernel/time/timer_list.c
+++ linux-2.6-tip/kernel/time/timer_list.c
@@ -110,6 +110,7 @@ next_one...
| Sep 30, 2:44 pm 2008 |
| Thomas Gleixner | [patch 0/3] timer_list: make debug output more useful
/proc/timer_list resp. sysrq-Q is an important debug helper to analyse
timer related problems. Make it more useful.
Thanks,
tglx
--
| Sep 30, 2:44 pm 2008 |
| Thomas Gleixner | [patch 1/3] timer_list: print real timer address
The current timer_list output prints the address of the on stack copy
of the active hrtimer instead of the hrtimer itself.
Print the address of the real timer instead.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
kernel/time/timer_list.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
Index: linux-2.6-tip/kernel/time/timer_list.c
===================================================================
--- linux-2.6-tip.orig/kernel/time/timer_list.c
+++ linux-2.6-...
| Sep 30, 2:44 pm 2008 |
| Sitsofe Wheeler | ath5k tries to free an IRQ that is already-free
In yesterday's linux-tip I was able to provoke this backtrace by
repeatedly disabling and enabling the wifi on my EeePC 900:
[ 786.455830] uvcvideo 1-8:1.0: no reset_resume for driver uvcvideo?
[ 786.455835] uvcvideo 1-8:1.1: no reset_resume for driver uvcvideo?
[ 786.458642] uvcvideo: Found UVC 1.00 device CNF7129 (04f2:b071)
[ 786.485835] Restarting tasks ... <6>pciehp: Card not present on Slot(3)
[ 787.160420] done.
[ 787.197658] Trying to free already-free IRQ 18
[ 787.197726] P...
| Sep 30, 2:15 pm 2008 |
| Zachary Amsden | [PATCH] x86, Fix broken LDT access in VMI
This one took a long time to rear up because LDT usage is not very
common, but the bug is quite serious. It got introduced along with
another bug, already fixed, by 75b8bb3e56ca09a467fbbe5229bc68627f7445be
Please apply. Fix should also be headed for stable tree and backported,
it is really sadly trivial. Glauber, Ingo, sorry for the offlist
posting, somehow the original missed LKML.
Zach
| Sep 30, 2:02 pm 2008 |
| Ingo Molnar | Re: [PATCH] x86, Fix broken LDT access in VMI
oops. Applied to tip/x86/urgent, thanks Zachary!
Ingo
--
| Sep 30, 3:13 pm 2008 |
| Parag Warudkar | Re: [PATCH] x86, Fix broken LDT access in VMI
For a few seconds I thought it was diff going mad diff'ing exactly
similar lines.
This one could actually use some capitalization to reduce the
possibility of similar problems in future - rename to write_IDT_entry
and write_LDT_entry perhaps?
Parag
--
| Sep 30, 6:49 pm 2008 |
| Sitsofe Wheeler | sleeping function called from invalid context at kernel/mute...
This turned up in a linux-tip from yesterday after resuming from a
suspend on an EeePC 900:
[ 1176.720189] ACPI: Preparing to enter system sleep state S3
[ 1176.745011] Intel machine check architecture supported.
[ 1176.745011] Intel machine check reporting enabled on CPU#0.
[ 1176.745011] Back to C!
[ 1176.745011] BUG: sleeping function called from invalid context at
kernel/mutex.c:207
[ 1176.745011] in_atomic(): 0, irqs_disabled(): 1, pid: 4513, name:
pm-suspend
[ 1176.745011] 3 locks held ...
| Sep 30, 1:00 pm 2008 |
| Alexander van Heukelum | [PATCH 0/4] traps: x86: more unification
Hi Ingo,
Here are some more unification patches for traps_xx.c. They
are against the current x86/traps branch in the tip tree and
work fine for my miniconfigs.
The branch does not at the moment compile a defconfig kernel,
due to a missing PCI_DEVICE_ID_AMD_10H_NB_MISC define, however.
Moreover, a defconfig won't run :-/ (on qemu-system-x86_64).
Bisection pointed to commit 10a434fcb "x86: remove cpu_vendor_dev".
The kernel crashes early with a general protection fault in a call
to strnlen. I h...
| Sep 30, 12:41 pm 2008 |
| previous day | today | next day |
|---|---|---|
| September 29, 2008 | September 30, 2008 | October 31, 2008 |
| Greg Kroah-Hartman | [PATCH 004/196] Chinese: add translation of SubmittingPatches |
| Jeff Garzik | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Paul E. McKenney | [PATCH RFC 3/9] RCU: Preemptible RCU |
| James Bottomley | Re: Integration of SCST in the mainstream Linux kernel |
git: | |
| Gerrit Renker | [PATCH 13/37] dccp: Deprecate Ack Ratio sysctl |
| Patrick McHardy | Re: [GIT]: Networking |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
