linux-kernel mailing list

FromSubjectsort iconDate
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 ...
Sep 30, 4:49 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, 4:57 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, 4:52 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" depends on ...
Sep 30, 4:29 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 =================================================================== --- ...
Sep 30, 4: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, 4:29 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, 4:41 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, 4:59 pm 2008
Elias Oltmanns
Block: Fix blk_start_queueing() so as not to process a s ...
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.c | 6 ...
Sep 30, 4:19 pm 2008
Rusty Russell
[PATCH] x86: clean up speedctep-centrino and reduce cpum ...
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 dc205c205c8a ...
Sep 30, 4: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, 3: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, 4: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 ...
Sep 30, 3: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 ...
Sep 30, 3: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, 3:22 pm 2008
Yinghai Lu Sep 30, 4:13 pm 2008
H. Peter Anvin
Re: [PATCH] x86: mtrr_cleanup update command line and do ...
Could you split that into two patches, please? -hpa --
Sep 30, 4:11 pm 2008
Yinghai Lu
[PATCH] x86: mtrr_cleanup update command line and doc mt ...
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: ...
Sep 30, 3:06 pm 2008
H. Peter Anvin
Re: [PATCH] x86: mtrr_cleanup update command line and do ...
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, 3:03 pm 2008
Yinghai Lu
[PATCH] x86: mtrr_cleanup update command line and doc mt ...
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: ...
Sep 30, 3:01 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: ...
Sep 30, 3:23 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, 2:18 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 ...
Sep 30, 1:27 pm 2008
Krzysztof Helt
[PATCH] x86: do not allow to optimize flag_is_changeable ...
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 the ...
Sep 30, 2:17 pm 2008
Serge E. Hallyn
Re: [PATCH 02/14] LSM/SELinux: inode_{get,set,notify}sec ...
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, 1:22 pm 2008
Serge E. Hallyn Sep 30, 1: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 ...
Sep 30, 1:05 pm 2008
Serge E. Hallyn
Re: [PATCH 02/14] LSM/SELinux: inode_{get,set,notify}sec ...
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, 1: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 ...
Sep 30, 12: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 +++ ...
Sep 30, 12: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 =================================================================== --- ...
Sep 30, 12: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_t ...
Sep 30, 12: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 ...
Sep 30, 12:48 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, 12: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 ...
Sep 30, 1: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: ...
Sep 30, 2:09 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 ...
Sep 30, 12:35 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, 12:17 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, 11:51 am 2008
Andrew Lyon
Re: kernel.org missing .1 incremental patches
Sorry, I should really have figured that out! Andy --
Sep 30, 12: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: ...
Sep 30, 11:44 am 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 @@ ...
Sep 30, 11:44 am 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, 11:44 am 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 +++ ...
Sep 30, 11:44 am 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] ...
Sep 30, 11:15 am 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, 11:02 am 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, 3:49 pm 2008
Ingo Molnar
Re: [PATCH] x86, Fix broken LDT access in VMI
oops. Applied to tip/x86/urgent, thanks Zachary! Ingo --
Sep 30, 12:13 pm 2008
Sitsofe Wheeler
sleeping function called from invalid context at kernel/ ...
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 ...
Sep 30, 10:00 am 2008
Alexander van Heukelum
[PATCH 4/4] traps: x86: converge do_debug handlers
Make the x86_64-version and the i386-version of do_debug more similar. - introduce preempt_conditional_sti/cli to i386. The preempt-count is now elevated during the trap handler, like on x86_64. It does not run on a separate stack, however. - replace an open-coded "send_sigtrap" - copy some comments Signed-off-by: Alexander van Heukelum <heukelum@fastmail.fm> --- arch/x86/kernel/traps_32.c | 30 +++++++++++++++++++++--------- arch/x86/kernel/traps_64.c | 17 +++++++++-------- ...
Sep 30, 9:41 am 2008
Alexander van Heukelum
[PATCH 2/4] traps: i386: factor out lazy io-bitmap copy
x86_64 does not do the lazy io-bitmap dance. Putting it in its own function makes i386's do_general_protection look much more like x86_64's. Signed-off-by: Alexander van Heukelum <heukelum@fastmail.fm> --- arch/x86/kernel/traps_32.c | 76 +++++++++++++++++++++++++------------------- 1 files changed, 43 insertions(+), 33 deletions(-) diff --git a/arch/x86/kernel/traps_32.c b/arch/x86/kernel/traps_32.c index dd183a2..78113d3 100644 --- a/arch/x86/kernel/traps_32.c +++ ...
Sep 30, 9:41 am 2008
Yinghai Lu
Re: [PATCH] fix: x86: remove cpu_vendor_dev
On Tue, Sep 30, 2008 at 12:37 PM, Alexander van Heukelum that is merging problem, Ingo should fix that already... YH --
Sep 30, 1:37 pm 2008
Alexander van Heukelum
[PATCH 3/4] traps: x86: introduce dotraplinkage
Mark the exception handlers with "dotraplinkage" to hide the calling convention differences between i386 and x86_64. Signed-off-by: Alexander van Heukelum <heukelum@fastmail.fm> --- arch/x86/kernel/entry_64.S | 2 +- arch/x86/kernel/traps_32.c | 28 +++++++++------- arch/x86/kernel/traps_64.c | 31 +++++++++++------- include/asm-x86/traps.h | 73 +++++++++++++++++++++---------------------- 4 files changed, 72 insertions(+), 62 deletions(-) diff --git ...
Sep 30, 9:41 am 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. ...
Sep 30, 9:41 am 2008
Alexander van Heukelum
[PATCH 1/4] traps: x86_64: split out math_error and simd ...
Split out math_error from do_coprocessor_error and simd_math_error from do_simd_coprocessor_error, like on i386. While at it, add the "error_code" parameter to do_coprocessor_error, do_simd_coprocessor_error and do_spurious_interrupt_bug. This does not change the generated code, but brings the declarations in line with all the other trap handlers. Signed-off-by: Alexander van Heukelum <heukelum@fastmail.fm> --- arch/x86/kernel/traps_64.c | 36 +++++++++++++++++++++--------------- ...
Sep 30, 9:41 am 2008
Alexander van Heukelum
[PATCH] fix: x86: remove cpu_vendor_dev
x86_64-kernels after commit 10a434fcb "x86: remove cpu_vendor_dev" crashed on qemu-system-x86_64 due to a typo in vmlinux_64.lds.S. Signed-off-by: Alexander van Heukelum <heukelum@fastmail.fm> --- It took quite some time, but I found the problem... I'll leave the other one to you ;). Greetings, Alexander arch/x86/kernel/vmlinux_64.lds.S | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/x86/kernel/vmlinux_64.lds.S ...
Sep 30, 12:37 pm 2008
Krishna Kumar
Re: [REV2: PATCH 1/2]: workqueue: Implement the kernel API
Hi Oleg, As you stated in an earlier mail, the following code should handle all cases. I think delay==0 is fine now, we take the costly (but rare) path. int queue_update_delayed_work(struct workqueue_struct *wq, struct delayed_work *dwork, unsigned long delay) { int ret = 1; while (queue_delayed_work(wq, dwork, delay)) { unsigned long when = jiffies + delay; ret = 0; if (delay && ...
Sep 30, 9:25 am 2008
Takashi Iwai
[GIT PULL] ALSA fixes
Linus, please pull ALSA updates for 2.6.27-rc8 from: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git for-linus These are hopefully last fixes for 2.6.27: one is a patch I missed in the previous pull request for ASoC cs4270 codec fix, and another is a trivial fix for a Dell laptop. Thanks! Takashi == Jean Delvare (1): ALSA: ASoC: Fix cs4270 error path Takashi Iwai (1): ALSA: hda - Fix model for Dell Inspiron 1525 ...
Sep 30, 9:01 am 2008
Randy Dunlap
Re: About the maintainer of "MOUSE AND MISC DEVICES"
I'd say that the entry should just be for MISC DEVICES. MOUSE is covered/handled by INPUT DRIVERS. The L: and S: look OK to me. Please send a patch to linux-kernel@vger.kernel.org and to akpm@linux-foundation.org . Thanks, --- ~Randy --
Sep 30, 11:36 am 2008
Randy Dunlap
Re: About the maintainer of "MOUSE AND MISC DEVICES"
Ack. And there is no MISC maintainer, so Jiri's patch to remove the entire entry makes sense IMO. --- ~Randy --
Sep 30, 3:49 pm 2008
Rodolfo Giometti
About the maintainer of "MOUSE AND MISC DEVICES"
Hello, I just wrote to Alessandro in order to have some suggestions about a misc device I wish to propose to this list, but he told me that he wants leave his maintanership. So which is the person should I send my requests about misc devices? He also asked to me to propose to this list a "patch" to remove him from the MAINTANERS file... if so the new entry should be: MOUSE AND MISC DEVICES [GENERAL] L: linux-kernel@vger.kernel.org S: Maintained Is taht ...
Sep 30, 8:37 am 2008
Jiri Kosina
Re: About the maintainer of "MOUSE AND MISC DEVICES"
I in fact never understood what this maintainers entry meant ... what is the device in question here? Anyway, something for Andrew From: Jiri Kosina <jkosina@suse.cz> Subject: [PATCH] remove "Mouse and Misc devices" from MAINTAINERS remove "Mouse and Misc devices" from MAINTAINERS Alessandro himself claims that he gives up maintainership, and to be frank, I don't have a clue what this entry is about. Signed-off-by: Jiri Kosina <jkosina@suse.cz> --- MAINTAINERS | 6 ...
Sep 30, 1:55 pm 2008
Jiri Kosina
Re: About the maintainer of "MOUSE AND MISC DEVICES"
It is. Generic mice interface is maintained by Dmitry as part of linux input subsystem, and USB mice (usb hid) is maintained by me. -- Jiri Kosina SUSE Labs --
Sep 30, 2:54 pm 2008
Kristoffer Ericson
Re: About the maintainer of "MOUSE AND MISC DEVICES"
On Tue, 30 Sep 2008 22:55:40 +0200 (CEST) I thought mouse was a part of linux-input? Or am I missing something? Besides that misc thingie is really creepy, makes me feel Ive -- Kristoffer Ericson <kristoffer.ericson@gmail.com> --
Sep 30, 2:06 pm 2008
Matt Mackall
Re: [PATCH] slub: reduce total stack usage of slab_err & ...
That's fascinating. I tried a simple test case in userspace: #include <stdarg.h> #include <stdio.h> void p(char *fmt, ...) { va_list args; va_start(args, fmt); vprintf(fmt, args); va_end(args); } On 32-bit, I'm seeing 32 bytes of stack vs 216 on 64-bit. Disassembly suggests it's connected to va_list fiddling with XMM registers, which seems quite odd. -- Mathematics is the supreme nostalgia of our time. --
Sep 30, 10:37 am 2008
Matt Mackall
Re: [PATCH] slub: reduce total stack usage of slab_err & ...
Ok, on closer inspection, this is part of the x86_64 calling convention. When calling a varargs function, the caller passes the number of floating point SSE regs used in rax. The callee then has to save these away for va_list use. The GCC prologue apparently sets aside space for xmm0-xmm7 (16 bytes each) all the time (plus rdi, rsi, rdx, rcx, r8, and r9). Obviously, we're never passing floating point args in the kernel, so we're taking about a 40+ byte hit in code size and 128 byte hit in ...
Sep 30, 11:33 am 2008
Christoph Lameter
Re: [PATCH] slub: reduce total stack usage of slab_err & ...
Really 208 bytes for a va arg parameter declaration? I expected it to be simply a null terminated pointer list. --
Sep 30, 10:36 am 2008
Christoph Lameter
Re: [PATCH] slub: reduce total stack usage of slab_err & ...
You could simply get rid of the 100 byte buffer by using vprintk? Same method could be used elsewhere in the kernel and does not require additional functions. Compiles, untestted. Subject: Slub reduce slab_bug stack usage by using vprintk Signed-off-by: Christoph Lameter <cl@linux-foundation.org> Index: linux-2.6/mm/slub.c =================================================================== --- linux-2.6.orig/mm/slub.c 2008-09-30 10:34:40.000000000 -0500 +++ ...
Sep 30, 8:38 am 2008
Jörn
Re: [PATCH] slub: reduce total stack usage of slab_err & ...
Cool! I once did the same, although the code has severely bitrotted by now. Is the code available somewhere? Jörn -- "Error protection by error detection and correction." -- from a university class --
Sep 30, 12:33 pm 2008
Matt Mackall
Re: [PATCH] slub: reduce total stack usage of slab_err & ...
I'm fixing a bunch of these in the kernel right now. -- Mathematics is the supreme nostalgia of our time. --
Sep 30, 8:49 am 2008
Matt Mackall
Re: [PATCH] slub: reduce total stack usage of slab_err & ...
(Funny, I added vprintk precisely to fix the extra buffer issue in ext2/3 years ago, but never hit the rest of the kernel..) Use vprintk rather that vsnprintf where possible This does away with lots of large static and on-stack buffers as well as a few associated locks. Signed-off-by: Matt Mackall <mpm@selenic.com> diff -r 6841f3ce32be -r 9ac0727d59d8 drivers/cpufreq/cpufreq.c --- a/drivers/cpufreq/cpufreq.c Mon Sep 29 17:28:44 2008 -0500 +++ b/drivers/cpufreq/cpufreq.c Tue Sep 30 ...
Sep 30, 9:43 am 2008
Richard Kennedy
Re: [PATCH] slub: reduce total stack usage of slab_err & ...
Yes, using vprintk is better but you still have this path : ( with your patch applied) object_err -> slab_bug(208) -> printk(216) instead of object_err -> slab_bug_message(8) -> printk(216) unfortunately the overhead for having var_args is pretty big, at least on x86_64. I haven't measured it on 32 bit yet. Richard --
Sep 30, 9:20 am 2008
Matt Mackall
Re: [PATCH] slub: reduce total stack usage of slab_err & ...
I've got a better idea: use vprintk. -- Mathematics is the supreme nostalgia of our time. --
Sep 30, 8:32 am 2008
Richard Kennedy
[PATCH] slub: reduce total stack usage of slab_err & obj ...
reduce the total stack usage of slab_err & object_err. Introduce a new function to display a simple slab bug message, and call this when vprintk is not needed. before: (stack size as reported by checkstack on x86_64) slab_err/object_err -> slab_bug(328)->printk after: slab_err/object_err -> slab_bug_message(8) -> printk Signed-off-by: Richard Kennedy <richard@rsk.demon.co.uk> ---- I've been trying to build a tool to estimate the maximum stack usage in the kernel, & noticed that most ...
Sep 30, 8:15 am 2008
Adam Litke
Re: [PATCH] properly reserve in bootmem the lmb reserved ...
This seems like the right approach to me. I have pointed out a few stylistic issues below. On Tue, 2008-09-30 at 09:53 -0500, Jon Tollefson wrote: CodingStyle dictates that this should be: unsigned long end_pfn = ((physbase + size - 1) >> PAGE_SHIFT); Bad style. I think the convention would be to write it like this: struct node_active_region * Since this is using the early_node_map[], should we mark the function __mminit? -- Adam Litke - (agl at us.ibm.com) IBM Linux ...
Sep 30, 8:47 am 2008
Jon Tollefson
[PATCH] properly reserve in bootmem the lmb reserved reg ...
If there are multiple reserved memory blocks via lmb_reserve() that are contiguous addresses and on different numa nodes we are losing track of which address ranges to reserve in bootmem on which node. I discovered this when I only recently got to try 16GB huge pages on a system with more then 2 nodes. When scanning the device tree in early boot we call lmb_reserve() with the addresses of the 16G pages that we find so that the memory doesn't get used for something else. For example the ...
Sep 30, 7:53 am 2008
Benjamin Herrenschmidt
Re: [PATCH] suspend/resume for ATI Mobility Radeon RV350
Can you resend it with a proper Signed-off-by: line ? Thanks ! Cheers, --
Sep 30, 3:10 pm 2008
Wolfgang Kroener
[PATCH] suspend/resume for ATI Mobility Radeon RV350
Hi, I have a ATI Mobility Radeon RV350 and similar problems with radeonfb described in http://kernel.org/doc/Documentation/power/s2ram.txt Adding the device to radeon_workaround_list solves the Problem. Please accept the following patch: --8<-- --- drivers/video/aty/radeon_pm.c.orig 2008-09-30 15:00:40.988111330 +0200 +++ drivers/video/aty/radeon_pm.c 2008-09-30 15:14:10.941524474 +0200 @@ -89,6 +89,9 @@ BUGFIX("Acer Aspire 2010", PCI_VENDOR_ID_AI, 0x0061, radeon_pm_off, ...
Sep 30, 7:06 am 2008
Parag Warudkar
Re: [ksoftirqd/1] CPU reporting.
Forgot to include Rafael on the previous one. Parag --
Sep 30, 3:42 pm 2008
Parag Warudkar
Re: [ksoftirqd/1] CPU reporting.
Uh oh - Here we go again. Rafael - time for re-reopening of http://bugzilla.kernel.org/show_bug.cgi?id=11209 I suppose? Parag --
Sep 30, 3:39 pm 2008
Jon Smirl
[ksoftirqd/1] CPU reporting.
What's up with ksoftirqd? I'm pretty sure it hasn't used 14,676 years of CPU time. Linus current git on a Q6600 64b. jonsmirl@terra:~/fs$ ps aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.0 4016 884 ? Ss 07:27 0:01 /sbin/init root 2 0.0 0.0 0 0 ? S< 07:27 0:00 [kthreadd] root 3 0.0 0.0 0 0 ? S< 07:27 0:00 [migration/0] root 4 0.0 0.0 0 0 ? S< ...
Sep 30, 7:41 am 2008
Haavard Skinnemoen
[PATCH] dw_dmac: Fix copy/paste bug in tasklet
The tasklet checks RAW.BLOCK twice, and does not check RAW.XFER. This is obviously wrong, and could theoretically cause the driver to hang. Reported-by: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com> --- drivers/dma/dw_dmac.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c index 94df917..0778d99 100644 --- a/drivers/dma/dw_dmac.c +++ b/drivers/dma/dw_dmac.c @@ ...
Sep 30, 7:27 am 2008
Reto Glauser
PROBLEM: processes claim CPU indefinitely on Intel(R) Co ...
[1.] One line summary of the problem Processes claim CPU indefinitely on Intel(R) Core(TM)2 Quad CPU Q6600 [2.] Full description of the problem/report Processes hang indefinitely (but might recover after 10min. or so) while executing forked tasks like sed, touch, mv, uic (Qt), grep etc. The processes claim a CPU, which may be for 2min. or 30min. and continue later on. This happens very often and changing the preemption model does not make a difference (be it Preemptible Kernel or Voluntary ...
Sep 30, 7:19 am 2008
Eric Paris
Re: [PATCH] capability: WARN when invalid capability is ...
No argument from me that patching up for buggy drivers sucks. Yours would be less overhead, and it would return the cap system back to pre-2.6.25 operation (garbage in garbage out but no panic). Since we already have the branch in SELinux its no 'extra' overhead to EPERM there instead of here (garbage in EPERM out). -Eric --
Sep 30, 10:22 am 2008
Arjan van de Ven
Re: [PATCH] capability: WARN when invalid capability is ...
On Tue, 30 Sep 2008 13:22:30 -0400 to be honest, this is really a case of panic("This stuff is really borken") if it passes some random value, what other api's does it pass a random value to ? (and in addition, random values to security critical APIs deserve a process kill, because it could well be an exploit attempt at guessing something. At least by not letting it live it's harder to get such type of exploits to be able to guess things. So imo, BUG() is the right answer) -- ...
Sep 30, 10:28 am 2008
Serge E. Hallyn
Re: [PATCH] capability: WARN when invalid capability is ...
Heh I don't like either one, just thought this would reduce the overhead a bit :) --
Sep 30, 9:28 am 2008
Eric Paris
[PATCH] capability: WARN when invalid capability is requ ...
The firegl ATI/AMD closed source proprietary driver has some 2,733 panics registered on kerneloops.org and recently SELinux was blamed for BUGing because of this driver. http://www.kerneloops.org/search.php?search=firegl_ioctl&btnG=Function+Search Basically it looks like the firegl_ioctl() function is calling capable() with a huge value. cap_capable dereferences an array (64 bits long) WAY off the end. I know a specific example would be referencing the array c.cap[0x7B4BB01]. As dumb luck ...
Sep 30, 6:55 am 2008
Serge E. Hallyn
Re: [PATCH] capability: WARN when invalid capability is ...
Perhaps we should have CAP_TO_INDEX mask itself? #define CAP_TO_INDEX(x) (((x) >> 5) & _KERNEL_CAPABILITY_U32S) Though I still think it's not unreasonable to simply ask for the driver --
Sep 30, 8:38 am 2008
Eric Paris
Re: [PATCH] capability: WARN when invalid capability is ...
Well, you save a branch and won't get the pagefault so it does 'fix' the pagefault/panic from cap code. It doesn't tell us when others screw up and SELinux is still possibly going to BUG(). We are also going to actually be returning a permission decision not on what was requested but on something wholely different. I like mine better, but I'm ok with yours and can just do my changes in SELinux if this is how cap wants to handle it. I don't really like the idea of mutating the inputs and ...
Sep 30, 9:07 am 2008
James Morris
Re: [PATCH] capability: WARN when invalid capability is ...
An issue here is whether we should be adding workarounds in the mainline kernel for buggy closed drivers. Papering over problems rather than getting them fixed does not seem like a winning approach. Especially problems which are unexpectedly messing with kernel security APIs. Also, won't this encourage vendors of such drivers to continue with this behavior, while discouraging those vendors who are doing the right thing? Do we know if this even really helps the user? For all we know, ...
Sep 30, 7:23 am 2008
Eric Paris
Re: [PATCH] capability: WARN when invalid capability is ...
I don't know, looking at the feelings on "Can userspace bugs be kernel regressions" leads me to believe that when we break something that once worked we are supposed to fix it. http://lwn.net/Articles/292143/ I don't think the proprietary closed source nature of the driver makes it any less our problem to not make changes which cause the kernel to Discouraging people who open source their drivers and put them in the kernel? obviously not. encouraging crap? well, I hope we fix Well, ...
Sep 30, 7:36 am 2008
krzysztof.h1
Re: [PATCH] x86: enable CPUID on Cyrix cpus with CPUID d ...
I know that it was connected with the Geode booting, but I read the cyrix.c file and most paths are Geode specific and I won't be able to test them. I tested that reverting the commit 026e2c0 ("x86, cyrix: debug") does not break anything on 6x86MX cpu. If the tip/master is a correct tree, please revert the commit 026e2c0 in the linux-next and drop this patch. This way everything is correct. Regards, Krzysztof ---------------------------------------------------------------------- Dzwon ...
Sep 30, 6:06 am 2008
Janos Haar
Re: Whats going on? (somebody can say something?)
----- Original Message ----- From: "Ray Lee" <ray-lk@madrabbit.org> To: "Janos Haar" <djani22@netcenter.hu> Cc: <linux-kernel@vger.kernel.org> Sent: Friday, September 26, 2008 11:12 PM No. :-) Thank you. If i will have a little time, i will do that.... Thanks, Janos Haar --
Sep 30, 5:06 am 2008
Janos Haar
Re: Whats going on? (somebody can say something?)
----- Original Message ----- From: "Dave Chinner" <david@fromorbit.com> To: "Janos Haar" <djani22@netcenter.hu> Cc: <linux-kernel@vger.kernel.org>; <xfs@premium9.geo.yahoo7.akadns.net> Sent: Saturday, September 27, 2008 3:44 AM Linux version 2.6.26.2 (root@gl-albth) (gcc version 4.1.1 20061011 (Red Hat unfortunately, i can't wait for this, and don't want to step back in the versions, this is a productive box. :-( This time i forced to use another FS, but nex time i will check again with ...
Sep 30, 5:09 am 2008
Michael Fritscher
Linux 2.6.27-rc8 - e1000 problems: bug(s) report
hi, at first: no, I didn't brick my thinkpad x61 :-) But: I have severe problems since 2.6.26 (jes) kernel: textmode consoles doesn't work most(!) of the time, sometimes the notebook crashes on boot, displaying garbage. The 2.6.24/xen kernel from ubuntu doesn't work with X, too. Suspend/resume doesn't work anymore with the 2.6.26/27 kernel, too (garbage on display) Its a x3100 chipset with 4GB ram, I don't use a highmem-kernel, so I've only 3 GB. Perhaps something with mem sharing between ...
Sep 30, 5:26 am 2008
Janos Haar
How can i read really 512 byte?
Hello list, Now i am working on recover some data from one defective drive. I am using dd_rescue, and dd, but both ready only 4K, i think, because the kernel's block size is 4K. I have tried to google for the solution, but only found this trick: losetup /dev/loop0 /dev/hdc blockdev --setbsz 512 /dev/hdc and after this set, trying to read the hdc... It looks like working on the first look, but not really. :-( The 512 size bad sectors still have 4K sizes, but the reading attempt takes ...
Sep 30, 5:25 am 2008
Milton Miller
How can i read really 512 byte?
You need to add O_DIRECT to the open call in the flags parameter (the second argument). (My brother tested this a year or so ago, and it worked for him). milton --
Sep 30, 7:50 am 2008
Haavard Skinnemoen
Re: [PATCH] mtd: AT49BV6416 has swapped erase regions
That's a good question. I guess there may be others in the same family with the same bug. I don't really know. That's interesting...especially since u-boot only reads the low byte of the JEDEC ID, so adding a fixup for one particular ID may match tons of chips with 16-bit IDs. I'll have to check the latest u-boot and see if it breaks any of my boards. Haavard --
Sep 30, 5:22 am 2008
Leon Woestenberg
Re: [PATCH] mtd: AT49BV6416 has swapped erase regions
Haavard, On Tue, Sep 30, 2008 at 1:55 PM, Haavard Skinnemoen Are there other Atmel designs with this bug or only the chip with this CFI ID? I ask, because the check in u-boot is too generic; I found u-boot wrongly assumes wrong order for another Atmel part, not checking on a specific CFI ID. (Need to lookup the part numbers later at home). Regards, -- Leon --
Sep 30, 5:02 am 2008
Haavard Skinnemoen
[PATCH] mtd: AT49BV6416 has swapped erase regions
The CFI information read from AT49BV6416 lists the erase regions in the wrong order, causing problems when trying to erase or update the first or last 64K block. Work around this by inverting the "top boot" flag, which will effectively reverse the order of the erase regions. This chip is obsolete, but it's used in some existing designs. Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com> --- I'd like this fix to be applied before 2.6.27. However, it's not a big deal since the ...
Sep 30, 4:55 am 2008
Ingo Molnar
Re: [PATCH 0/2] x86: split out dumpstack code from traps_xx.c
applied to tip/x86/traps: # 9bb2b4f: x86_64: split out dumpstack code from traps_64.c # f616942: i386: split out dumpstack code from traps_32.c there were some interactions with other branches: 054efa5: Merge branch 'tracing/nmisafe' into x86/traps 9ecb7cf: Merge branch 'kmemcheck' into x86/traps 8955b63: Merge branch 'core/signal' into x86/traps ff1b7a8: Merge branch 'x86/signal' into x86/traps 76b22d8: Merge commit 'v2.6.27-rc8' into x86/traps b58c936: Merge branch ...
Sep 30, 4:44 am 2008
Alexander van Heukelum
[PATCH 1/2] i386: split out dumpstack code from traps_32.c
The dumpstack code is logically quite independent from the hardware traps. Split it out into its own file. Signed-off-by: Alexander van Heukelum <heukelum@fastmail.fm> --- arch/x86/kernel/Makefile | 2 +- arch/x86/kernel/dumpstack_32.c | 425 ++++++++++++++++++++++++++++++++++++++++ arch/x86/kernel/traps_32.c | 407 -------------------------------------- 3 files changed, 426 insertions(+), 408 deletions(-) create mode 100644 arch/x86/kernel/dumpstack_32.c diff --git ...
Sep 30, 4:12 am 2008
Alexander van Heukelum
[PATCH 0/2] x86: split out dumpstack code from traps_xx.c
Hi Ingo, I intend to keep looking for possibilities to bring traps_32.c and traps_64.c closer to each-other. One trivial way (from my point of view) is to split out code into separate files. These two patches split out a large piece of code that has nothing to do with hardware traps. Are you willing to take those two patches? Or are they to intrusive? Patches are against the current master branch of the tip tree. The defconfigs compile fine and I ran some simple configs ...
Sep 30, 4:12 am 2008
Ingo Molnar
Re: [PATCH 0/2] x86: split out dumpstack code from traps_xx.c
they are not intrusive at all! The right way to do such things is to would be nice to bring dumpstack_32.c and dumpstack_64.c together as well. While some of the details like IST stack logic (which dont exist on 32-bit) are special, most of the glue, the iterators, the boot parameters, and even the output should be unified some more. Ingo --
Sep 30, 4:27 am 2008
Alexander van Heukelum
[PATCH 2/2] x86_64: split out dumpstack code from traps_64.c
The dumpstack code is logically quite independent from the hardware traps. Split it out into its own file. Signed-off-by: Alexander van Heukelum <heukelum@fastmail.fm> --- arch/x86/kernel/Makefile | 4 +- arch/x86/kernel/dumpstack_64.c | 567 ++++++++++++++++++++++++++++++++++++++++ arch/x86/kernel/traps_64.c | 549 -------------------------------------- 3 files changed, 569 insertions(+), 551 deletions(-) create mode 100644 arch/x86/kernel/dumpstack_64.c diff --git ...
Sep 30, 4:12 am 2008
Nick Piggin
[rfc] "improve" preempt debugging
Hi, don't know if you really like this patch or not, but it helped me out with a problem I recently had.... Basically, when the kernel lock is held, then preempt_count underflow does not get detected until it is released which may be a long time (and arbitrarily, eg at different points it may be rescheduled). If the bkl is released at schedule, the resulting output is actually fairly cryptic... With any other lock that elevates preempt_count, it is illegal to schedule under it (which would ...
Sep 30, 3:50 am 2008
Ingo Molnar
Re: [rfc] "improve" preempt debugging
looks useful to me. This hardcodes a "BKL is tied to preempt-off" assumption but that should be OK - when get rid of the BKL by turning it into a plain mutex we have to remember to remove this. applied the commit below to tip/core/locking, thanks Nick! Peter, does it look good to you too? Ingo ---------------> From 7317d7b87edb41a9135e30be1ec3f7ef817c53dd Mon Sep 17 00:00:00 2001 From: Nick Piggin <nickpiggin@yahoo.com.au> Date: Tue, 30 Sep 2008 20:50:27 +1000 Subject: [PATCH] ...
Sep 30, 3:58 am 2008
Tony Vroon
Re: CD tray closes spontaneously after opening it
For the record, I had this on my Gentoo system. It turned out that HAL was responsible. (So it may not be a kernel bug at all) Do see this report: Regards, Tony V.
Sep 30, 4:18 am 2008
Frans Pop
CD tray closes spontaneously after opening it
Hi, I'm late reporting this mainly because until now I wasn't sure whether this was a kernel issue or not. Since 2.6.27 I've had several times, but not always, that after I open the CD tray by pressing the eject button it spontaneously closes after a short delay. The delay varies between ~0 and ~2 seconds. A few times this has resulted in a DVD getting stuck halfway out because I had already staring taking it out after playing it with vlc. I've now also seen this happen two times ...
Sep 30, 3:47 am 2008
Kay Sievers
Re: CD tray closes spontaneously after opening it
This rule is fine, it was only ide-cs, the old pcmcia stuff, that had these issues. You might need: http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=f755fd5657b619fd27160ad... Kay --
Sep 30, 5:35 am 2008
Frans Pop
Re: CD tray closes spontaneously after opening it
Yes, I'd seen that new rule, but: - that fix is already included in the udev version I'm using - I'm seeing the issue on /dev/hda (IDE DVD drive), not on /dev/sr* --
Sep 30, 5:47 am 2008
Frans Pop
Re: CD tray closes spontaneously after opening it
Well, in upstream udev 128 the comment for that rule has been changed to: # never access non-cdrom removable ide devices, the drivers are causing # event loops on open() So it looks like that's not it either. --
Sep 30, 5:35 am 2008
Kay Sievers
Re: CD tray closes spontaneously after opening it
Does: /sbin/udevadm monitor --env print something while you see the tray closing? Does this also happen when you set: /proc/sys/dev/cdrom/autoclose to 0? Kay --
Sep 30, 6:55 am 2008
Frans Pop
Re: CD tray closes spontaneously after opening it
I was somewhat lucky to reproduce it with that running and there was no output during the open or close. I guess that rules out udev? I still don't know how to reliably reproduce this. It seems that after it has occurred once, it will not occur again unless the system is rebooted. But I'm not 100% sure of that. Most times I've seen it was after playing a DVD when ejecting the disc to put it back in its box, but not when the DVD was inserted earlier. But I've also seen it shortly after ...
Sep 30, 12:50 pm 2008
Frans Pop
Re: CD tray closes spontaneously after opening it
Thanks for the link. It cannot be hal in my case as I've disabled polling by hal for both drives using the 'hal-disable-polling' command. The bug report also mentions udev, but I'm not sure if that's it either as the bit in the report is about sr* devices, which is SCSI/SATA and the patch linked there is in Debian's udev. The udev changelog for Debian has: udev (0.125-4) unstable; urgency=medium * 60-persistent-storage.rules: do not run vol_id on media tray open events or the kernel ...
Sep 30, 5:01 am 2008
Kay Sievers
Re: CD tray closes spontaneously after opening it
That will prevent the closing, when something tries to open the device in blocking mode. If that solves the issue, you should start looking which process tries to access your drive. Kay --
Sep 30, 1:02 pm 2008
Christer Weinigel
[patch 3/3] RFC: Low-latency SDIO, add hard interrupt handlers
Finally, the goal of all these changes, add a hard SDIO interrupt handler which will be called directly from interrupt context. Nothing really tricky here, the patch adds a new function sdio_claim_hard_irq and moves the common code from sdio_hard_irq into __sdio_claim_irq. It also adds some code that calls the hard interrupt handler directly from interrupt context. One very important thing here is that since the hard interrupt handler will return immediately, it has to call sdio_release_host ...
Sep 30, 3:23 am 2008
Christer Weinigel
[patch 2/3] RFC: Low-latency SDIO, convert sdio_irq_thre ...
Change sdio_irq_thread into a workqueue. The polling logic is moved to delayed_work which runs periodically. There are two major changes in behaviour from the thread version: First, mmc_signal_sdio_irq will use an asynchronous operation to read SDIO_CCCR_INTx, and the asynchronous callback then schedules sdio_irq_work to do the processing. Since this function can be called from interrupt context, the request function in the SDIO host driver can no longer sleep, something that it could get ...
Sep 30, 3:23 am 2008
Christer Weinigel
[patch 1/3] RFC: Low-latency SDIO, add asynchronous SDIO ...
To improve the latency of the SDIO operations, I've add asynchronous versions of sdio operations that split a blocking sdio call into a _start call which takes a callback and a _result function which gets the result from the last operation. The callback is called directly from interrupt context so this avoids the scheduling overhead from waking up the calling thread all the time. This makes a noticeable difference in latency and CPU load on slow embedded systems. To begin with the patch ...
Sep 30, 3:23 am 2008
Christer Weinigel
[patch 0/3] RFC: Low-latency SDIO
Hi Pierre and anyone else who is interested, Here is a cleaned up patch that implements the low-latency SDIO stuff I mailed about a couple of weeks ago. Basically the patches adds asynchronous SDIO operations and makes it possible to register a "hard" SDIO interrupt handler which will be called directly from interrupt context (mmc_signal_sdio_irq). So, tell me what you think. :-) /Christer -- "Just how much can I get away with and still go to heaven?" Christer Weinigel ...
Sep 30, 3:23 am 2008
Matti Linnanvuori
Re: [patch v1.2.34] WAN: merge driver retina
Actually there is one call of virt_to_phys in the patch I sent. I don't know any way to replace virt_to_phys and still use remap_pfn_range. If all architectures support virt_to_phys, I see no reason to replace it with something else. The driver is legacy. --
Sep 30, 2:51 am 2008
Artem Bityutskiy
Re: What is in ubifs-2.6.git
Actually UBIFS reads up to whole eraseblock. So if you have a file, and it is resided in consecutive NAND pages of an eraseblock, and UBIFS has decided to do read-ahead, it would read whole eraseblock. So for OneNAND, indeed UBIFS may read up to 64 NAND pages at one go. -- Best regards, Artem Bityutskiy (Битюцкий Артём) --
Sep 30, 2:02 am 2008
Amit Kumar Sharma
Re: What is in ubifs-2.6.git
Hi Artem OneNAND can support for full block read also in sync burst block read mode ,so why u want to limit bulk read only for 4 pages , with sync burst enable u can read max 64 pages. so in place of max 4 pages , u can set max to 64 it will be improve performance if sync burst mode is upported. Rgs Amit ----- Original Message ----- From: "Artem Bityutskiy" <dedekind@infradead.org> To: <linux-fsdevel@vger.kernel.org> Cc: <linux-mtd@lists.infradead.org>; "Adrian Hunter" ...
Sep 30, 1:55 am 2008
krzysztof.h1
Re: [PATCH] x86: do not allow to optimize flag_is_change ...
Why you call it undocumented. This is information you can find with "info gcc" in the Extendend Asm section: If your assembler instructions access memory in an unpredictable fashion, add `memory' to the list of clobbered registers. This will cause GCC to not keep memory values cached in registers across the assembler instruction and not optimize stores or loads to that memory. You will also want to add the `volatile' keyword if the memory affected is not listed in the inputs or outputs of the ...
Sep 30, 1:27 am 2008
Jeremy Fitzhardinge
Re: [PATCH] x86: do not allow to optimize flag_is_change ...
Yes, you're right. The pertinent part of the manual is: The `volatile' keyword indicates that the instruction has important side-effects. GCC will not delete a volatile `asm' if it is reachable. (The instruction can still be deleted if GCC can prove that control-flow will never reach the location of the instruction.) Note that even a volatile `asm' instruction can be moved relative to other code, including across jump instructions. I normally do my "asm ...
Sep 30, 8:23 am 2008
Samuel Ortiz
[GIT] MFD pull request
Hi Linus, While preparing the merge window, I found a build failure due to some changes in gpiolib. Could you please pull ? The following changes since commit 94aca1dac6f6d21f4b07e4864baf7768cabcc6e7: Linus Torvalds (1): Linux 2.6.27-rc8 are available in the git repository at: git://git.o-hand.com/linux-mfd for-linus Samuel Ortiz (2): mfd: Fix Kconfig accroding to the new gpiolib symbols mfd: Fix asic3 compilation drivers/mfd/Kconfig | 4 ++-- ...
Sep 30, 1:19 am 2008
Artem Bityutskiy
[PATCH] UBIFS: allow for sync_fs when read-only
From: Adrian Hunter <ext-adrian.hunter@nokia.com> sync_fs can be called even if the file system is mounted read-only. Ensure the commit is not run in that case. Reported-by: Zoltan Sogor <weth@inf.u-szeged.hu> Signed-off-by: Adrian Hunter <ext-adrian.hunter@nokia.com> --- fs/ubifs/super.c | 19 ++++++++++--------- 1 files changed, 10 insertions(+), 9 deletions(-) diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c index 7e1f3ef..7fd759d 100644 --- a/fs/ubifs/super.c +++ ...
Sep 30, 2:19 am 2008
Artem Bityutskiy
[PATCH] UBIFS: correct key comparison
From: Adrian Hunter <ext-adrian.hunter@nokia.com> The comparison was working, but more by accident than design. Signed-off-by: Adrian Hunter <ext-adrian.hunter@nokia.com> --- fs/ubifs/tnc_misc.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/ubifs/tnc_misc.c b/fs/ubifs/tnc_misc.c index a25c1cc..b48db99 100644 --- a/fs/ubifs/tnc_misc.c +++ b/fs/ubifs/tnc_misc.c @@ -480,8 +480,8 @@ int ubifs_tnc_read_node(struct ubifs_info *c, struct ubifs_zbranch *zbr, ...
Sep 30, 2:19 am 2008
Artem Bityutskiy
[PATCH] UBIFS: fix bulk-read handling uptodate pages
From: Adrian Hunter <ext-adrian.hunter@nokia.com> Bulk-read skips uptodate pages but this was putting its array index out and causing it to treat subsequent pages as holes. Signed-off-by: Adrian Hunter <ext-adrian.hunter@nokia.com> --- fs/ubifs/file.c | 16 +++++++++++----- 1 files changed, 11 insertions(+), 5 deletions(-) diff --git a/fs/ubifs/file.c b/fs/ubifs/file.c index 2f20a49..51cf511 100644 --- a/fs/ubifs/file.c +++ b/fs/ubifs/file.c @@ -595,7 +595,7 @@ out: static int ...
Sep 30, 2:19 am 2008
Artem Bityutskiy
[PATCH] UBIFS: check data CRC when in error state
From: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> When UBIFS switches to R/O mode because of an error, it is reasonable to enable data CRC checking. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> --- fs/ubifs/io.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/fs/ubifs/io.c b/fs/ubifs/io.c index 40e2790..0168271 100644 --- a/fs/ubifs/io.c +++ b/fs/ubifs/io.c @@ -62,6 +62,7 @@ void ubifs_ro_mode(struct ubifs_info *c, int err) { if ...
Sep 30, 2:19 am 2008
Artem Bityutskiy
[PATCH] UBIFS: use bit-fields when possible
From: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> The "bulk_read" and "no_chk_data_crc" have only 2 values - 0 and 1. We already have bit-fields in corresponding data structers, so make "bulk_read" and "no_chk_data_crc" bit-fields as well. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> --- fs/ubifs/ubifs.h | 24 +++++++++++------------- 1 files changed, 11 insertions(+), 13 deletions(-) diff --git a/fs/ubifs/ubifs.h b/fs/ubifs/ubifs.h index d6ae3f7..542cbaf 100644 --- ...
Sep 30, 2:19 am 2008
Artem Bityutskiy
[PATCH] UBIFS: fix races in bit-fields
From: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> We cannot store bit-fields together if the processes which change them may race, unless we serialize them. Thus, move the nospc and nospc_rp bit-fields eway from the mount option/constant bit-fields, to avoid races. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> --- fs/ubifs/ubifs.h | 17 +++++++++-------- 1 files changed, 9 insertions(+), 8 deletions(-) diff --git a/fs/ubifs/ubifs.h b/fs/ubifs/ubifs.h index ...
Sep 30, 2:19 am 2008
Artem Bityutskiy
[PATCH] UBIFS: correct comment for commit_on_unmount
From: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> --- fs/ubifs/super.c | 9 +++------ 1 files changed, 3 insertions(+), 6 deletions(-) diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c index cf078b5..dae1c62 100644 --- a/fs/ubifs/super.c +++ b/fs/ubifs/super.c @@ -1465,12 +1465,9 @@ out: * commit_on_unmount - commit the journal when un-mounting. * @c: UBIFS file-system description object * - * This function is ...
Sep 30, 2:19 am 2008
Artem Bityutskiy
Re: What is in ubifs-2.6.git
Actually this example is a little wrong, because UBIFS starts doing bulk-read only if few pages were read sequentially before. So, user would have to read pages 0-3 sequentially, then UBIFS would start doing bulk-read for this inode. -- Best regards, Artem Bityutskiy (Битюцкий Артём) --
Sep 30, 12:56 am 2008
Artem Bityutskiy
[PATCH] UBIFS: add more debugging messages for LPT
From: Adrian Hunter <ext-adrian.hunter@nokia.com> Also add debugging checks for LPT size and separate out c->check_lpt_free from unrelated bitfields. Signed-off-by: Adrian Hunter <ext-adrian.hunter@nokia.com> --- fs/ubifs/debug.c | 37 ++++++++++ fs/ubifs/debug.h | 6 ++ fs/ubifs/lpt.c | 3 +- fs/ubifs/lpt_commit.c | 185 ++++++++++++++++++++++++++++++++++++++++++++++--- fs/ubifs/ubifs.h | 10 ++- 5 files changed, 228 insertions(+), 13 deletions(-) diff ...
Sep 30, 2:19 am 2008
Artem Bityutskiy
[PATCH] UBIFS: correct condition to eliminate unecessary ...
From: Adrian Hunter <ext-adrian.hunter@nokia.com> Signed-off-by: Adrian Hunter <ext-adrian.hunter@nokia.com> --- fs/ubifs/tnc.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/fs/ubifs/tnc.c b/fs/ubifs/tnc.c index e0878a4..d27fd91 100644 --- a/fs/ubifs/tnc.c +++ b/fs/ubifs/tnc.c @@ -1600,7 +1600,7 @@ out: * An enormous hole could cause bulk-read to encompass too many * page cache pages, so limit the number here. */ - if (bu->blk_cnt >= ...
Sep 30, 2:19 am 2008
Artem Bityutskiy
[PATCH] UBIFS: check buffer length when scanning for LPT nodes
From: Adrian Hunter <ext-adrian.hunter@nokia.com> 'is_a_node()' function was reading from a buffer before checking the buffer length, resulting in an OOPS as follows: BUG: unable to handle kernel paging request at f8f74002 IP: [<f8f9783f>] :ubifs:ubifs_unpack_bits+0xca/0x233 *pde = 19e95067 *pte = 00000000 Oops: 0000 [#1] PREEMPT SMP Modules linked in: ubifs ubi mtdchar bio2mtd mtd brd video output [last unloaded: mtd] Pid: 6414, comm: integck Not tainted (2.6.27-rc6ubifs34 #23) EIP: ...
Sep 30, 2:19 am 2008
Artem Bityutskiy
What is in ubifs-2.6.git
Hi, here is the stuff we have scheduled for 2.6.28. The patches contains various small fixes and cleanups, but there is something interesting as well. The first interesting thing is new "bulk read" functionality. The idea is that many NAND flashes support "bulk read" in some form. For example, OneNAND has "read while load" feature, which allows reading consecutive NAND pages faster than reading them one-by-one. So we've made UBIFS benefit from this feature and introduced new "bulk_read" ...
Sep 30, 2:18 am 2008
Artem Bityutskiy
[PATCH] UBIFS: add no_chk_data_crc mount option
From: Adrian Hunter <ext-adrian.hunter@nokia.com> UBIFS read performance can be improved by skipping the CRC check when data nodes are read. This option can be used if the underlying media is considered to be highly reliable. Note that CRCs are always checked for metadata. Read speed on Arm platform with OneNAND goes from 19 MiB/s to 27 MiB/s with data CRC checking disabled. Signed-off-by: Adrian Hunter <ext-adrian.hunter@nokia.com> --- Documentation/filesystems/ubifs.txt | 6 ...
Sep 30, 2:19 am 2008
Artem Bityutskiy
[PATCH] UBIFS: add bulk-read facility
From: Adrian Hunter <ext-adrian.hunter@nokia.com> Some flash media are capable of reading sequentially at faster rates. UBIFS bulk-read facility is designed to take advantage of that, by reading in one go consecutive data nodes that are also located consecutively in the same LEB. Read speed on Arm platform with OneNAND goes from 17 MiB/s to 19 MiB/s. Signed-off-by: Adrian Hunter <ext-adrian.hunter@nokia.com> --- Documentation/filesystems/ubifs.txt | 3 + fs/ubifs/file.c ...
Sep 30, 2:19 am 2008
Artem Bityutskiy
[PATCH] UBIFS: ensure data read beyond i_size is zeroed ...
From: Adrian Hunter <ext-adrian.hunter@nokia.com> Signed-off-by: Adrian Hunter <ext-adrian.hunter@nokia.com> --- fs/ubifs/file.c | 10 ++++++++-- fs/ubifs/ubifs-media.h | 1 - 2 files changed, 8 insertions(+), 3 deletions(-) diff --git a/fs/ubifs/file.c b/fs/ubifs/file.c index cdcfe95..2f20a49 100644 --- a/fs/ubifs/file.c +++ b/fs/ubifs/file.c @@ -147,6 +147,12 @@ static int do_readpage(struct page *page) err = ret; if (err != -ENOENT) break; + } else if ...
Sep 30, 2:19 am 2008
Artem Bityutskiy
[PATCH] UBIFS: add a print, fix comments and more minor stuff
From: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> This commit adds a reserved pool size print and tweaks the prints to make them look nicer. It also fixes and cleans-up some comments. Additionally, it deletes some blank lines to make the code look a little nicer. In other words, nothing essential. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> --- fs/ubifs/budget.c | 26 ++++++++++++++------------ fs/ubifs/lprops.c | 6 +----- fs/ubifs/super.c | 16 ...
Sep 30, 2:18 am 2008
Artem Bityutskiy
[PATCH] UBIFS: improve garbage collection
From: Adrian Hunter <ext-adrian.hunter@nokia.com> Make garbage collection try to keep data nodes from the same inode together and in ascending order. This improves performance when reading those nodes especially when bulk-read is used. Signed-off-by: Adrian Hunter <ext-adrian.hunter@nokia.com> --- fs/ubifs/gc.c | 82 ++++++++++++++++++++++++++++++++++++++++++++++++++------- 1 files changed, 72 insertions(+), 10 deletions(-) diff --git a/fs/ubifs/gc.c b/fs/ubifs/gc.c index ...
Sep 30, 2:19 am 2008
Artem Bityutskiy
[PATCH] UBIFS: remove unneeded unlikely()
From: Hirofumi Nakagawa <hnakagawa@miraclelinux.com> IS_ERR() macro already has unlikely(), so do not use constructions like 'if (unlikely(IS_ERR())'. Signed-off-by: Hirofumi Nakagawa <hnakagawa@miraclelinux.com> Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> --- fs/ubifs/find.c | 4 ++-- fs/ubifs/gc.c | 8 ++++---- fs/ubifs/tnc.c | 4 ++-- fs/ubifs/xattr.c | 2 +- 4 files changed, 9 insertions(+), 9 deletions(-) diff --git a/fs/ubifs/find.c ...
Sep 30, 2:18 am 2008
Artem Bityutskiy
[PATCH] UBIFS: fix commentary
From: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Znode may refer both data nodes and indexing nodes Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> --- fs/ubifs/ubifs.h | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/ubifs/ubifs.h b/fs/ubifs/ubifs.h index c3ac5a8..49b06c9 100644 --- a/fs/ubifs/ubifs.h +++ b/fs/ubifs/ubifs.h @@ -707,8 +707,8 @@ struct ubifs_jhead { * struct ubifs_zbranch - key/coordinate/length branch stored in znodes. ...
Sep 30, 2:19 am 2008
Artem Bityutskiy
[PATCH] UBIFS: improve znode splitting rules
From: Adrian Hunter <ext-adrian.hunter@nokia.com> When inserting into a full znode it is split into two znodes. Because data node keys are usually consecutive, it is better to try to keep them together. This patch does a better job of that. Signed-off-by: Adrian Hunter <ext-adrian.hunter@nokia.com> --- fs/ubifs/tnc.c | 54 +++++++++++++++++++++++++++++++++--------------------- 1 files changed, 33 insertions(+), 21 deletions(-) diff --git a/fs/ubifs/tnc.c b/fs/ubifs/tnc.c index ...
Sep 30, 2:19 am 2008
Artem Bityutskiy
[PATCH] UBIFS: use an IS_ERR test rather than a NULL test
From: Julien Brunel <brunel@diku.dk> In case of error, the function kthread_create returns an ERR pointer, but never returns a NULL pointer. So a NULL test that comes before an IS_ERR test should be deleted. The semantic match that finds this problem is as follows: (http://www.emn.fr/x-info/coccinelle/) // <smpl> @match_bad_null_test@ expression x, E; statement S1,S2; @@ x = kthread_create(...) ... when != x = E * if (x == NULL) S1 else S2 // </smpl> Signed-off-by: Julien Brunel ...
Sep 30, 2:19 am 2008
Artem Bityutskiy
[PATCH] UBIFS: inline one-line functions
From: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> 'ubifs_get_lprops()' and 'ubifs_release_lprops()' basically wrap mutex lock and unlock. We have them because we want lprops subsystem be separate and as independent as possible. And we planned better locking rules for lprops. Anyway, because they are short, it is better to inline them. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> --- fs/ubifs/lprops.c | 28 ---------------------------- fs/ubifs/misc.h | 27 ...
Sep 30, 2:18 am 2008
Artem Bityutskiy
[PATCH] UBIFS: commit on sync_fs
From: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Commit the journal when the FS is sync'ed. This will make statfs provide better free space report. And we anyway advice our users to sync the FS if they want better statfs report. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> --- fs/ubifs/super.c | 12 ++++++++++++ 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c index dae1c62..7e1f3ef 100644 --- ...
Sep 30, 2:19 am 2008
Artem Bityutskiy
[PATCH] UBIFS: update dbg_dump_inode
From: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> 'dbg_dump_inode()' is quite outdated and does not print all the fileds. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> --- fs/ubifs/debug.c | 42 +++++++++++++++++++++++++----------------- 1 files changed, 25 insertions(+), 17 deletions(-) diff --git a/fs/ubifs/debug.c b/fs/ubifs/debug.c index d7f7645..32071ec 100644 --- a/fs/ubifs/debug.c +++ b/fs/ubifs/debug.c @@ -222,30 +222,38 @@ void dbg_dump_inode(const struct ...
Sep 30, 2:19 am 2008
Parav Pandit
Re: Calculating time in order of 0.1usec on x86 system
I am getting my desired numbers. get_cycles()/cpu_khz gives the right time interval on x86 system. Parav --
Sep 30, 2:37 am 2008
Parav Pandit
Calculating time in order of 0.1usec on x86 system
Hi, I need to calculate time spent by a function in order of less then a microsecond on x86 SMP platform. Current profiling tools and gettimeofday() are not sufficient. So I am using get_cycles() to get the CPU cycles. Now how do I convert it into the time interval? Do I have to divide it by "cpu_khz" variable? Or some other method? Is yes, what will be the unit of the result (time interval)? nsec/usec/msec? e.g. get_cycles()/cpu_khz (unit?) Or Is there more simpler method ...
Sep 30, 12:01 am 2008
Ingo Molnar
Re: [PATCH] Tracepoints fix reentrancy
applied to tip/tracing/ftrace, thanks Mathieu! Ingo --
Sep 30, 12:10 am 2008
Mathieu Desnoyers
[PATCH] Tracepoints fix reentrancy
The tracepoints had the same problem markers did have wrt reentrancy. Apply a similar fix using a rcu_barrier after each tracepoint mutex lock. Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> CC: Ingo Molnar <mingo@elte.hu> CC: "Frank Ch. Eigler" <fche@redhat.com> CC: Lai Jiangshan <laijs@cn.fujitsu.com> --- kernel/tracepoint.c | 4 ++++ 1 file changed, 4 insertions(+) Index: ...
Sep 29, 10:51 pm 2008
Mathieu Desnoyers
[PATCH] Tracepoint use rcu sched
Make tracepoints use rcu sched. (cleanup) Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> CC: Ingo Molnar <mingo@elte.hu> CC: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> --- kernel/tracepoint.c | 15 ++++++--------- 1 file changed, 6 insertions(+), 9 deletions(-) Index: linux-2.6-lttng/kernel/tracepoint.c =================================================================== --- linux-2.6-lttng.orig/kernel/tracepoint.c 2008-09-30 01:36:26.000000000 -0400 +++ ...
Sep 29, 10:49 pm 2008
Ingo Molnar
Re: [PATCH] Tracepoint use rcu sched
applied to tip/tracing/ftrace, thanks Mathieu! Ingo --
Sep 30, 12:10 am 2008
Ingo Molnar
Re: [PATCH] Markers : fix reentrancy
could you please send a delta patch against tip/master? Lai's patch is already applied and is tested. Thanks, Ingo --
Sep 30, 12:09 am 2008
Mathieu Desnoyers
[PATCH] Markers : fix reentrancy
Ah, you're right. I looked again through your patch description and I think using a : if (entry->rcu_pending) rcu_barrier_sched(); After each time the markers_mutex is taken would keep the fast batch registration/unregistration and fix the reentrancy problem. The following patch should address the problem. Thanks, Mathieu Lai Jiangshan discovered a reentrancy issue with markers. This patch implements a version of the fix which won't slow down marker ...
Sep 29, 10:41 pm 2008
Mathieu Desnoyers
Re: [PATCH] Markers : fix reentrancy
Hrm, Most of Lai "simplifications" to use synchronize_sched() instead of call_rcu_sched() will make batch registration/unregistration much slower (very noticeable on ~50 markers on a loaded machine). It also contains two different fixes in one, one of which has been nacked. The correct list of changes against tip now becomes : Revert commit d587284c1d26b796bf52a6e3d3f783db4e462119 Apply patch "Markers : marker_synchronize_unregister()" Apply patch "Markers : probe example fix ...
Sep 30, 8:52 am 2008
Madhusudhan Chikkature Sep 29, 10:20 pm 2008
George Nychis
help finding entry point of USB data in the kernel, not ...
Hi all, I am trying to find the entry point of USB data in the kernel. I have a USB device and I would like to find the latency between the time the data enters the kernel, and I read it in userspace. My first goal is to find where it actually enters the kernel. The host device driver obtains a URB and reads the data from urb->buffer. From digging around the kernel code, I had assumed the entry point for all USB data was in drivers/usb/core/devio.c::usbdev_read() ... but it seems ...
Sep 29, 10:04 pm 2008
Greg KH
Re: help finding entry point of USB data in the kernel, ...
I suggest asking this on the linux-usb mailing list instead, it would No, that entry point is for usbfs, not the individual drivers, and not Are you watching all of the different USB device endpoints? thanks, greg k-h --
Sep 29, 10:12 pm 2008
George Nychis
Re: help finding entry point of USB data in the kernel, ...
Yes, I am not filtering really. But if this code is for usbfs, then this is definitely not what I am looking for. I think what I am looking for might be in devices.c::usb_device_read() ... poking around there now. It calls usb_device_dump() which takes a user space buffer as a parameter for which it dumps data in to. Thanks for the response! - George --
Sep 29, 10:22 pm 2008
Zhang, Yanmin
[PATCH] pci-e: ignore unknown capability and continue se ...
Subject: pci-e: ignore unknown capability and continue searching From: "Zhang, Yanmin" <yanmin_zhang@linux.intel.com> Tomasz reported AER driver couldn't work on his machine. With the output of "lcpsi -vvv", I found the root port's extended capabilities are Capabilities: [100] Unknown (11) Capabilities: [150] Advanced Error Reporting Capabilities: [190] Unknown (13) Such Unknown capability is not expected. During pci-e ...
Sep 29, 9:29 pm 2008
Benjamin Herrenschmidt
Please pull 'merge' branch of "deputy" powerpc.git tree
Hi Linus ! The following changes since commit 94aca1dac6f6d21f4b07e4864baf7768cabcc6e7: Linus Torvalds (1): Linux 2.6.27-rc8 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge Those are two fixes for regressions introduced recently, the first one due to some change in the timer code becoming more sensitive to timer interrupts taken from offlined CPUs and the second is an update to a board device-tree to fix some ...
Sep 29, 8:38 pm 2008
Mathieu Desnoyers
Re: [PATCH] markers: let marker_debug as module parameter
Given it's only called at probe registration/unregistration and never put in the critical path of an executed marker, it makes sense to make this a kernel arg debug option. I like this patch :) -- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 --
Sep 29, 8:41 pm 2008
Ingo Molnar
Re: [PATCH] markers: let marker_debug as module parameter
hm, in tip/master we already have ftrace_printk(), which allows such debug output to any of the active tracers. That is a far more useful way of debugging such things. See: http://people.redhat.com/mingo/tip.git/README and: http://redhat.com/~mingo/sched-devel.git/readme-tracer.txt note how much cleaner and more usable it will also become: no silly module flags or recompilation to activate this debug output, and no debug clutter in the syslog. if you enable tracing in the ...
Sep 30, 12:15 am 2008
Lai Jiangshan
[PATCH] markers: let marker_debug as module parameter
if we want to enable marker debug output, we have to modify the code and remake/reinstall the kernel in current code. this patch enable marker_debug to be set when kernel start. Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com> --- diff --git a/kernel/marker.c b/kernel/marker.c index 9f76c4a..5d8404f 100644 --- a/kernel/marker.c +++ b/kernel/marker.c @@ -28,8 +28,9 @@ extern struct marker __start___markers[]; extern struct marker __stop___markers[]; -/* Set to 1 to enable marker ...
Sep 29, 8:28 pm 2008
Jesse Brandeburg
[RFC PATCH 08/12] e1000e: allow bad checksum
currently if the driver notices a bad checksum it will fail to load. This patch allows the driver load process to continue with an invalid mac address and could allow the user to use ethtool or another app to fix the eeprom. copied from implementation in e1000 Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> --- drivers/net/e1000e/netdev.c | 81 ++++++++++++++++++++++++++++++++++++------- 1 files changed, 67 insertions(+), 14 deletions(-) diff --git ...
Sep 29, 8:19 pm 2008
Jesse Brandeburg
[RFC PATCH 05/12] e1000e: fix lockdep issues
thanks to tglx, we're finding some interesting lockdep issues. The good news is that this patch fixes all the ones I could find, without damaging any functionality. CC: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> --- drivers/net/e1000e/ethtool.c | 6 +++++- drivers/net/e1000e/netdev.c | 13 ------------- 2 files changed, 5 insertions(+), 14 deletions(-) diff --git a/drivers/net/e1000e/ethtool.c ...
Sep 29, 8:19 pm 2008
Jesse Brandeburg
[RFC PATCH 11/12] e1000e: write protect ICHx NVM to prev ...
From: Bruce Allan <bruce.w.allan@intel.com> Set the hardware to ignore all write/erase cycles to the GbE region in the ICHx NVM. This feature can be disabled by the WriteProtectNVM module parameter (enabled by default) though that is not recommended. Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> --- drivers/net/e1000e/e1000.h | 2 ++ drivers/net/e1000e/ethtool.c | 3 +++ drivers/net/e1000e/ich8lan.c | 46 ...
Sep 29, 8:20 pm 2008
Jesse Brandeburg
[RFC PATCH 04/12] e1000e: do not ever sleep in interrupt ...
e1000e was apparently calling two functions that attempted to reserve the SWFLAG bit for exclusive (to hardware and firmware) access to the PHY and NVM (aka eeprom). These accesses could possibly call msleep to wait for the resource which is not allowed from interrupt context. Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> CC: Thomas Gleixner <tglx@linutronix.de> --- drivers/net/e1000e/e1000.h | 2 ++ drivers/net/e1000e/netdev.c | 31 ++++++++++++++++++++++++++++--- 2 ...
Sep 29, 8:19 pm 2008
Ingo Molnar
Re: [RFC PATCH 01/12] x86: export set_memory_ro and set_ ...
applied to tip/x86/exports, thanks Jesse. Ingo --
Sep 30, 12:07 am 2008
Allan, Bruce W
RE: [RFC PATCH 11/12] e1000e: write protect ICHx NVM to ...
Yeah, we can do that. I need to amend the patch a bit to prevent the protected range lock from being lifted unintentionally and will add some debug statements if/when any write/erase cycles fail. -----Original Message----- From: Jiri Kosina [mailto:jkosina@suse.cz] Sent: Tuesday, September 30, 2008 5:41 AM To: Brandeburg, Jesse Cc: linux-kernel@vger.kernel.org; linux-netdev@vger.kernel.org; kkeil@suse.de; agospoda@redhat.com; arjan@linux.intel.com; Graham, David; Allan, Bruce W; Ronciak, John; ...
Sep 30, 8:47 am 2008
Jesse Brandeburg
[RFC PATCH 01/12] x86: export set_memory_ro and set_memory_rw
From: Bruce Allan <bruce.w.allan@intel.com> Export set_memory_ro() and set_memory_rw() calls for use by drivers that need to have more debug information about who might be writing to memory space. this was initially developed for use while debugging a memory corruption problem with e1000e. patch was modified with this suggestion. Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Acked-by: Ingo Molnar <mingo@elte.hu> --- ...
Sep 29, 8:19 pm 2008
Jesse Brandeburg
[RFC PATCH 12/12] update version
--- drivers/net/e1000e/netdev.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c index 2626c42..df547b6 100644 --- a/drivers/net/e1000e/netdev.c +++ b/drivers/net/e1000e/netdev.c @@ -47,7 +47,7 @@ #include "e1000.h" -#define DRV_VERSION "0.3.3.3-k2" +#define DRV_VERSION "0.3.3.3-kt" char e1000e_driver_name[] = "e1000e"; const char e1000e_driver_version[] = DRV_VERSION; --
Sep 29, 8:20 pm 2008
Jesse Brandeburg
[RFC PATCH 02/12] On Tue, 23 Sep 2008, David Miller wrote:
Here's a patch that adds range checking to the sysfs mappings at least. This patch should catch the case where X (or some other process) tries to map beyond the specific BAR it's (supposedly) trying to access, making things safer in general. FWIW both my F9 and development versions of X start up fine with this patch applied. DaveM, will this work for you on sparc? It looked like your code was allowing bridge window mappings, but that behavior should be preserved as long as your bridge ...
Sep 29, 8:19 pm 2008
Jesse Brandeburg
[RFC PATCH 10/12] e1000e: Use set_memory_ro()/set_memory ...
From: Bruce Allan <bruce.w.allan@intel.com> A number of users have reported NVM corruption on various ICHx platform LOMs. One possible reasons for this could be unexpected and/or malicious writes to the flash memory area mapped into kernel memory. Once the interface is up, there should be very few reads/writes of the mapped flash memory. This patch makes use of the x86 set_memory_*() functions to set the mapped memory read-only and temporarily set it writable only when the driver needs to ...
Sep 29, 8:20 pm 2008
Jiri Kosina
Re: [RFC PATCH 08/12] e1000e: allow bad checksum
BTW wouldn't something like if (e1000_validate_nvm_checksum(hw) >= 0 || e1000_validate_nvm_checksum(hw) >= 0) { /* copy the MAC address out of the NVM */ if (e1000e_read_mac_addr(&adapter->hw)) e_err("NVM Read Error reading MAC address\n"); } else { e_err("The NVM Checksum Is Not Valid\n"); e1000e_dump_eeprom(adapter); /* * set MAC address to all zeroes to invalidate and * temporary disable this device for the user. This * blocks regular traffic while still ...
Sep 30, 1:38 am 2008
Jiri Kosina
Re: [RFC PATCH 11/12] e1000e: write protect ICHx NVM to ...
I guess there is no chance to have kernel somehow notified when write/erase cycle is unsuccessfully tried, is it? This way, it would also make chasing the root cause easier. Thanks, -- Jiri Kosina SUSE Labs --
Sep 30, 5:40 am 2008
Jesse Brandeburg
[RFC PATCH 06/12] e1000e: drop stats lock
the stats lock is left over from e1000, e1000e no longer has the adjust tbi stats function that required the addition of the stats lock to begin with. adding a mutex to acquire_swflag helped catch this one too. Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> CC: Thomas Gleixner <tglx@linutronix.de> --- drivers/net/e1000e/e1000.h | 1 - drivers/net/e1000e/netdev.c | 18 ------------------ 2 files changed, 0 insertions(+), 19 deletions(-) diff --git ...
Sep 29, 8:19 pm 2008
Jesse Brandeburg
[RFC PATCH 00/12] e1000e debug and protection patches
please be warned this is a test series of patches that we are currently validating, but we wanted to post them sooner than later. this series of patches implements: 1-2) base kernel code fixes that might be helpful for debugging 3-6) a series of patches to fix some (possible) buglets in eeprom access code 7) a patch that triggered the bugs that were fixed in 3-6, from Thomas 8-9) (what should be) debug helper patches for testers to log to syslog the first bytes of the eeprom, that are ...
Sep 29, 8:19 pm 2008
Jesse Brandeburg
[RFC PATCH 09/12] e1000e: dump eeprom to dmesg for ich8/9
dumping the eeprom for now seems like a bit of a verbose hack, but might be useful when we want to restore it. if syslogd (or something like) isn't running it won't be kept however. Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> --- drivers/net/e1000e/netdev.c | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c index 48b0ded..57cead3 100644 --- a/drivers/net/e1000e/netdev.c +++ ...
Sep 29, 8:20 pm 2008
Jesse Brandeburg
[RFC PATCH 07/12] e1000e: debug contention on NVM SWFLAG
From: Thomas Gleixner <tglx@linutronix.de> This patch adds a mutex to the e1000e driver that would help catch any collisions of two e1000e threads accessing hardware at the same time. description and patch updated by Jesse Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> --- drivers/net/e1000e/ich8lan.c | 17 +++++++++++++++++ 1 files changed, 17 insertions(+), 0 deletions(-) diff --git a/drivers/net/e1000e/ich8lan.c ...
Sep 29, 8:19 pm 2008
Jesse Brandeburg
[RFC PATCH 03/12] e1000e: reset swflag after resetting h ...
in the process of debugging things, noticed that the swflag is not reset by the driver after reset, and the swflag is probably not reset unless management firmware clears it after 100ms. Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> --- drivers/net/e1000e/ich8lan.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/net/e1000e/ich8lan.c b/drivers/net/e1000e/ich8lan.c index 9e38452..a076079 100644 --- a/drivers/net/e1000e/ich8lan.c +++ ...
Sep 29, 8:19 pm 2008
Steven Rostedt
[PATCH 3/6] ring_buffer: add paranoid check for buffer page
If for some strange reason the buffer_page gets bigger, or the page struct gets smaller, I want to know this ASAP. The best way is to not let the kernel compile. This patch adds code to test the size of the struct buffer_page against the page struct and will cause compile issues if the buffer_page ever gets bigger than the page struct. Signed-off-by: Steven Rostedt <srostedt@redhat.com> --- kernel/trace/ring_buffer.c | 11 +++++++++++ 1 file changed, 11 insertions(+) Index: ...
Sep 29, 8:02 pm 2008
Steven Rostedt Sep 29, 8:02 pm 2008
Steven Rostedt
Re: [PATCH 6/6] ftrace: take advantage of variable lengt ...
I believe 88 was what I came up with on x86_64. It was just a size to pick out of the blue and has no real meaning. I'm not sure anyone uses it This patch is bringing us to the stage to get rid of the CONT flag. Thanks, I'll add a patch to my coming queue to handle this. -- Steve --
Sep 30, 10:45 am 2008
Pekka Paalanen
Re: [PATCH 6/6] ftrace: take advantage of variable lengt ...
Hi Steven, This is great news. I have some questions below. On Mon, 29 Sep 2008 23:02:42 -0400 I've read this paragraph over and over, and I can't really understand "only storing the size of the ... event". Maybe you are trying to say that now we are not consuming more ring space than the actual size of the event? Oh! I misunderstood also the last sentence, it's not generating extra I'm just wondering, does this hold for both 32- and 64-bit kernels? Long type is quite common in the ...
Sep 30, 10:33 am 2008
Steven Rostedt Sep 29, 8:02 pm 2008
Steven Rostedt
Re: [PATCH 2/6] Unified trace buffer
hm, why? It is ordered locking based on the cpu value. This is exactly what ftrace did as well. The unlock even goes backwards max_cpu to 0. But version 2 of this code will drop both ring_buffer_lock and unlock, but that will come later. -- Steve --
Sep 30, 5:06 am 2008
Ingo Molnar
Re: [PATCH 2/6] Unified trace buffer
hm, that's rather unintelligent and needs to be fixed. Ingo --
Sep 30, 2:45 am 2008
Steven Rostedt
[PATCH 2/6] Unified trace buffer
This is a unified tracing buffer that implements a ring buffer that hopefully everyone will eventually be able to use. The events recorded into the buffer have the following structure: struct ring_buffer_event { u32 type:2, len:3, time_delta:27; u32 array[]; }; The minimum size of an event is 8 bytes. All events are 4 byte aligned inside the buffer. There are 4 types (all internal use for the ring buffer, only the data type is exported to the interface ...
Sep 29, 8:02 pm 2008
Ingo Molnar
Re: [PATCH 2/6] Unified trace buffer
a third type of lockdep splat surfaced in -tip testing: ============================================= [ INFO: possible recursive locking detected ] 2.6.27-rc8-tip #37560 --------------------------------------------- swapper/0 is trying to acquire lock: (&cpu_buffer->lock){.+..}, at: [<ffffffff802906ac>] ring_buffer_lock+0x46/0x5e but task is already holding lock: (&cpu_buffer->lock){.+..}, at: [<ffffffff802906ac>] ring_buffer_lock+0x46/0x5e other info that might help us debug this: 2 ...
Sep 30, 4:53 am 2008
Steven Rostedt
[PATCH 1/6] ftrace: give time for wakeup test to run
It is possible that the testing thread in the ftrace wakeup test does not run before we stop the trace. This will cause the trace to fail since nothing will be in the buffers. This patch adds a small wait in the wakeup test to allow for the woken task to run and be traced. Signed-off-by: Steven Rostedt <srostedt@redhat.com> --- kernel/trace/trace_selftest.c | 3 +++ 1 file changed, 3 insertions(+) Index: ...
Sep 29, 8:02 pm 2008
Steven Rostedt
[PATCH 0/6] ftrace: port to the new ring_buffer
These patches are against linux-tip. The first is just a fix in the wakeup selftest. The next is a port of the Unified tracer buffer to linux-tip and some updates. After that is the ftrace port to use the ring buffer, followed by some more enhancements to ftrace because of the new variable length buffer. I tried a few configurations and tried to test all the different ftrace tracers, but I'm sure there may be some bugs still to work out. I worked out all those that I found. But, with ...
Sep 29, 8:02 pm 2008
Ingo Molnar
Re: [PATCH 0/6] ftrace: port to the new ring_buffer
ok, -tip testing found a serious-looking locking bug: [ 4.044005] calling init_irqsoff_tracer+0x0/0x11 @ 1 [ 4.048005] Testing tracer irqsoff: [ 4.056202] ============================================= [ 4.060000] [ INFO: possible recursive locking detected ] [ 4.060000] 2.6.27-rc8-tip-00917-g01214de-dirty #37512 [ 4.060000] --------------------------------------------- [ 4.060000] swapper/1 is trying to acquire lock: [ 4.060000] (&cpu_buffer->lock){++..}, at: ...
Sep 30, 2:13 am 2008
Ingo Molnar
Re: [PATCH 0/6] ftrace: port to the new ring_buffer
very nice! I'd expect breakages and complications too so i restructured tip/tracing/* a bit: firstly i created a tip/tracing/core append-only merge branch which collects all the known-robust bits. Then i created a new branch for your new generic ring-buffer feature: tip/tracing/ring-buffer, and applied your patches. I've started testing it. yeah. Ideally this should just fall out of the generic framework - i.e. tracer plugins should not have to do anything extra to get per tracer ...
Sep 30, 12:45 am 2008
Ingo Molnar
Re: [PATCH 0/6] ftrace: port to the new ring_buffer
FYI, triggered on a number of 32-bit test-systems as well - see the log below. Ingo [ 0.564008] calling tracer_alloc_buffers+0x0/0x16b @ 1 [ 0.574504] ------------[ cut here ]------------ [ 0.576002] WARNING: at kernel/lockdep.c:2880 check_flags+0x5a/0x155() [ 0.576002] Modules linked in: [ 0.576002] Pid: 1, comm: swapper Not tainted 2.6.27-rc8-tip-00915-g8cb18a9-dirty #37502 [ 0.576002] [<c01536c4>] warn_on_slowpath+0x46/0x6a [ 0.576002] [<c0170b14>] ? ...
Sep 30, 1:30 am 2008
Steven Rostedt
Re: [PATCH 0/6] ftrace: port to the new ring_buffer
Again, I think this is the same issue with the raws? -- Steve --
Sep 30, 5:04 am 2008
Ingo Molnar
Re: [PATCH 0/6] ftrace: port to the new ring_buffer
-tip testing found that tip/tracing/ring-buffer causes a new lockdep splat: [ 0.000000] Linux version 2.6.27-rc8-tip-00915-g8cb18a9-dirty (mingo@dione) (gcc version 4.2.3) #37501 SMP Tue Sep 30 10:10:10 CEST 2008 [...] [ 0.268001] calling tracer_alloc_buffers+0x0/0x1e5 @ 1 [ 0.270983] ------------[ cut here ]------------ [ 0.271100] WARNING: at kernel/lockdep.c:2880 check_flags+0x63/0x179() [ 0.271219] Modules linked in: [ 0.271356] Pid: 1, comm: swapper ...
Sep 30, 1:23 am 2008
Steven Rostedt
Re: [PATCH 0/6] ftrace: port to the new ring_buffer
I don't even need to look at the configs. There's places I still used the "raw_local_irq_save" and that is what in the past has caused this issue. I'll go and remove those. -- Steve --
Sep 30, 5:04 am 2008
Steven Rostedt
[PATCH 4/6] ring_buffer: reset buffer page when freeing
Mathieu Desnoyers pointed out that the freeing of the page frame needs to be reset otherwise we might trigger BUG_ON in the page free code. Signed-off-by: Steven Rostedt <srostedt@redhat.com> --- kernel/trace/ring_buffer.c | 19 +++++++++++++++---- 1 file changed, 15 insertions(+), 4 deletions(-) Index: linux-tip.git/kernel/trace/ring_buffer.c =================================================================== --- linux-tip.git.orig/kernel/trace/ring_buffer.c 2008-09-29 19:59:24.000000000 ...
Sep 29, 8:02 pm 2008
Robert Hancock Sep 29, 7:29 pm 2008
Kenji Kaneshige
Re: [PATCH v3 02/14] PCI: prevent duplicate slot names
It seems my previous e-mail was not sent properly. So resending it. Thanks, Kenji Kaneshige --
Sep 29, 7:06 pm 2008
Yinghai Lu
Re: [PATCH 1/2] x86: mtrr_cleanup prepare to make gran_s ...
it will compare the exact mem range between the updated and original, so it should be safe to set it to default-y. YH --
Sep 30, 9:06 am 2008
Ingo Molnar
Re: [PATCH 1/2] x86: mtrr_cleanup prepare to make gran_s ...
btw., now that we've got wide enough exposure (a kernel release), could we please flip around the default of CONFIG_MTRR_SANITIZER and make it default-y? This feature should only produce a worse result if there's a bug in that code, right? Ingo --
Sep 30, 1:11 am 2008
Yinghai Lu
[PATCH 1/2] x86: mtrr_cleanup prepare to make gran_size ...
make the print out right with size < 1M Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/kernel/cpu/mtrr/main.c | 109 ++++++++++++++++++++++++++++++---------- 1 file changed, 82 insertions(+), 27 deletions(-) Index: linux-2.6/arch/x86/kernel/cpu/mtrr/main.c =================================================================== --- linux-2.6.orig/arch/x86/kernel/cpu/mtrr/main.c +++ linux-2.6/arch/x86/kernel/cpu/mtrr/main.c @@ -905,6 +905,27 @@ set_var_mtrr_all(unsigned int ...
Sep 29, 6:54 pm 2008
H. Peter Anvin
Re: [PATCH 1/2] x86: mtrr_cleanup prepare to make gran_s ...
Applied series to tip:x86/mtrr, thanks! -hpa --
Sep 29, 9:07 pm 2008
Yinghai Lu
[PATCH 2/2] x86: mtrr_cleanup try gran_size to less than 1M
one have gran < 1M reg00: base=0xd8000000 (3456MB), size= 128MB: uncachable, count=1 reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1 reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1 reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1 reg05: base=0xd7f80000 (3455MB), size= 512KB: uncachable, count=1 will get Found optimal setting for mtrr clean up gran_size: 512K ...
Sep 29, 6:54 pm 2008
Ingo Molnar
Re: [PATCH 1/2] x86: mtrr_cleanup prepare to make gran_s ...
tested them and pushed it out into tip/master. Ingo --
Sep 30, 12:45 am 2008
H. Peter Anvin
Re: [PATCH 1/2] x86: mtrr_cleanup prepare to make gran_s ...
Yes. Furthermore, right now the code has to be enabled *and* a kernel command line option has to be passed. I suspect we eventually want to runtime-enable it by default, too. -hpa --
Sep 30, 11:50 am 2008
Yinghai Lu
Re: Strange mtrrs in Aspire One
last entry is really sick... YH --
Sep 29, 6:05 pm 2008
D. Hugh Redelmeier
Re: questions about x86: mtrr cleanup for converting con ...
| From: Dylan Taft <d13f00l@gmail.com> Thanks for your reply. | To: linux-kernel@vger.kernel.org, yinghai@kernel.org, hugh@mimosa.com | Subject: Re: questions about x86: mtrr cleanup for converting continuous to | discrete layout | | I think a workaround in the kernel is absolutely necessary. A lot of | newer motherboards have this issue, I agree. | where a whole section of memory | will be marked as write-back, and write-combining can't be | embedded/nested. To be more ...
Sep 30, 1:34 am 2008
Ingo Molnar
Re: Typo bug [Re: Linux 2.6.27-rc8]
applied to tip/x86/urgent, thanks! Ingo --
Sep 30, 1:05 am 2008
Dave Airlie
Re: Linux 2.6.27-rc8
On Tue, Sep 30, 2008 at 11:56 AM, Linus Torvalds If we had the magic we'd have fixed it by now, the current working theory is its X server related. This hasn't been proven, though my ATI GPU e1000e seems fine so it may have some legs. If it is X related then its both a kernel + X server issue, the e1000e driver opens the barn door, the X server drives the horses through it. Of course until someone produces a way to fix the hw after it breaks, reproducing this isn't something for the feint ...
Sep 29, 6:59 pm 2008
H. Peter Anvin
Re: Typo bug [Re: Linux 2.6.27-rc8]
These options are also named inconsistently with all other options. The standard way to name an boolean option is "foo" versus "nofoo", in this case, "mtrrcleanup" vs "nomtrrcleanup". -hpa --
Sep 30, 11:47 am 2008
Yinghai Lu
Re: Typo bug [Re: Linux 2.6.27-rc8]
ok, we could change it... YH --
Sep 30, 12:30 pm 2008
Krzysztof Halasa
Re: Linux 2.6.27-rc8
And this e1000e must be ICH*, right? I.e. not a separate e1000e chip/card? -- Krzysztof Halasa --
Sep 30, 7:09 am 2008
Linus Torvalds
Re: Linux 2.6.27-rc8
Are you sure? There was a mandriva report abou NVM corruption on an e100 too (that one apparently just caused PXE failure, the networking worked fine). So I wonder if it's _purely_ X-server-related, adn the reason people blame 2.6.27-rc1 is just timing of some X update and then people just look at the kernel beceuse the 'network card failed' looks so kernel-related. The reason I mention that is right now it looks like the distros are just running around disabling the e1000e module, ...
Sep 29, 7:21 pm 2008
Linus Torvalds
Re: Linux 2.6.27-rc8
Btw, the _real_ bug is clearly in the hardware design that allows you to brick those things without apparently even having a lock bit. I'm hoping Intel doesn't treat this as just a software bug. Some hw designer should be thinking hard about which orifice they put their head up in. It used to be that you could fry some monitors by feeding them out-of-range signals. The _monitors_ got fixed. Linus --
Sep 29, 7:23 pm 2008
Dave Airlie
Re: Linux 2.6.27-rc8
On Tue, Sep 30, 2008 at 12:21 PM, Linus Torvalds Well from a purely empirical standpoint, I've been running new X against that laptop for a long time, and others have the same laptop, so I think its a problem with the e1000e driver putting the card into a state which allows X to do bad things. I think X maybe causing issues on other hw, like e100 and some realtek.. Also when we say X I think it looks like Intel driver interaction issues, as I said I'm running the same stuff on my ATI gpu ...
Sep 29, 7:39 pm 2008
H. Peter Anvin
Re: Typo bug [Re: Linux 2.6.27-rc8]
Dashes seem to be used more than underscores, so it probably should be "mtrr-cleanup" and "nomtrr-cleanup" if you want a separator. -hpa --
Sep 30, 2:37 pm 2008
Linus Torvalds
Re: Linux 2.6.27-rc8
What's the magic to trigger it? I've got a laptop with that e1000e chip in it, and am obviously running a recent kernel on it. Do people have a handle on it? Is it actually verified to be kernel-related, and not related to the X server etc? Linus --
Sep 29, 6:56 pm 2008
Linus Torvalds
Re: Linux 2.6.27-rc8
Mostly. I think you can still do bad things to internal LCD's on at least some laptops. Although I hope I'm wrong. Linus --
Sep 29, 7:24 pm 2008
H. Peter Anvin
Re: Typo bug [Re: Linux 2.6.27-rc8]
I would prefer "mtrr-cleanup-debug" if the main one is "mtrr-cleanup"; mixing dashes and underscores is a bit sick. Unfortunately we have had very few attempts at consistency with command line options... some in the early days were even StudlyCaps (yuck...) -hpa --
Sep 30, 3:02 pm 2008
Jiri Kosina
Re: Linux 2.6.27-rc8
So far it seems to be that you need 1) something close to xorg 7.4 and 2) 2.6.27-rcX kernel to trigger it. Not every system having e1000e is affected. Apparently it is some kind of race, as it usually takes multiple cycles to trigger (on one of our testing machines this took three attempts to trigger for the first time, and then after unbricking the machine and restarting testing, the reproduction tests have been running for several hours). It always seems to happen when X is ...
Sep 30, 12:06 am 2008
Allan, Bruce W
RE: Linux 2.6.27-rc8
Ditto here, i.e. we have no similar reports on other parts. -----Original Message----- From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Jiri Kosina Sent: Tuesday, September 30, 2008 7:11 AM To: Krzysztof Halasa Cc: Linus Torvalds; Linux Kernel Mailing List; Brandeburg, Jesse Subject: Re: Linux 2.6.27-rc8 So far all the affected systems I am aware of were ICH. -- Jiri Kosina SUSE Labs -- --
Sep 30, 8:48 am 2008
Arjan van de Ven
Re: Linux 2.6.27-rc8
On Tue, 30 Sep 2008 11:59:58 +1000 we have a patch to save/restore now, in final testing stages (obviously we want to be really careful with this) Note that so far it seems to mostly hit with "new" distros, so both new kernel and new X... ;( -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org --
Sep 29, 7:06 pm 2008
Alan Cox
Re: Linux 2.6.27-rc8
You still can in some cases. You can also erase many video card firmwares, trash disks, brick DVD drives and the like fairly easily too but you do tend to have to try to be evil in these cases, not just get an address wrong. Alan --
Sep 30, 5:06 am 2008
Brandeburg, Jesse
RE: Linux 2.6.27-rc8
my current status mail was posted earlier today to lkml from this address, since then we've had a local reproduction and are going for number two. The reproduction seems racy, i.e. it doesn't happen every time, so we put it in a loop doing detect, check eeprom, detect, etc, and we'll see if it fails. Reproduction seems to consistently be around X probing time, no firm leads yet. As for Intel we have keithp and jbarnes as well as arjan, auke, myself and a few others involved. We have some ...
Sep 29, 7:30 pm 2008
Eric Piel
Re: Linux 2.6.27-rc8
Likely not, you are mentioning a patch for e1000, while the Mandriva bug report is about e100: https://qa.mandriva.com/show_bug.cgi?id=44192 See you, Eric --
Sep 30, 12:58 am 2008
Arjan van de Ven
Re: Linux 2.6.27-rc8
On Mon, 29 Sep 2008 19:21:02 -0700 (PDT) btw, we're also working on making some parts of the kernel more robust against certain types of bugs; for example the ioremap checks and sysfs resource checks. There's a set of checks and API changes we can do to make it less likely that drivers end up doing bad stuff; but that's obviously more for 2.6.28 than for .27 -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit ...
Sep 29, 8:19 pm 2008
Brandeburg, Jesse
Re: Linux 2.6.27-rc8
The hardware has a lock bit, and we're trying to figure out why the BIOS writers guide doesn't say to set it. Probably because of the MAC address, We will post a patch to e1000e tomorrow that sets a lock bit that prevents the registers memory mapped by 0:19.0 BAR1 from causing flash write cycles. The patches I've just posted don't quite do that yet. --
Sep 29, 8:42 pm 2008
Jiri Kosina
Re: Linux 2.6.27-rc8
That is very probably completely separate issue, and shoudl have been I think that not many peeople are suspecting bug in e1000e directly. Rather a combination of X bug, kernel allowing X to do bad things (for example the missing check in drivers/pci/pci-sysfs.c:pci_mmap_resource() looks particularly suspicious) and a "bug-friendly" hardware behavior. -- Jiri Kosina SUSE Labs --
Sep 30, 12:11 am 2008
J.A.
Typo bug [Re: Linux 2.6.27-rc8]
Hi.... Dealing with my Aspire One setup, I found this (so obvious I don't send a patch:) arch/x86/kernel/cpu/mtrr/main.c: static int __init disable_mtrr_cleanup_setup(char *str) { if (enable_mtrr_cleanup != -1) enable_mtrr_cleanup = 0; return 0; } early_param("disable_mtrr_cleanup", disable_mtrr_cleanup_setup); static int __init enable_mtrr_cleanup_setup(char *str) { if (enable_mtrr_cleanup != -1) enable_mtrr_cleanup = 1; return ...
Sep 30, 12:43 am 2008
Ingo Molnar
Re: Typo bug [Re: Linux 2.6.27-rc8]
heh. Could you send a patch with a changelog please? Ingo --
Sep 30, 12:55 am 2008
J.A.
Re: Typo bug [Re: Linux 2.6.27-rc8]
Here it goes...I hope its right. ================== Correct typo for 'enable_mtrr_cleanup' early boot param name. Signed-off-by: J.A. Magallon <jamagallon@ono.com> diff -p -up linux/arch/x86/kernel/cpu/mtrr/main.c.orig linux/arch/x86/kernel/cpu/mtrr/main.c --- linux/arch/x86/kernel/cpu/mtrr/main.c.orig 2008-09-30 09:57:46.000000000 +0200 +++ linux/arch/x86/kernel/cpu/mtrr/main.c 2008-09-30 09:57:55.000000000 +0200 @@ -834,7 +834,7 @@ static int __init enable_mtrr_cleanup_se ...
Sep 30, 1:02 am 2008
Alan Cox
Re: Linux 2.6.27-rc8
I am confident they will, because right now some more malicious virus writers will be thinking 'whoopeee party time'. --
Sep 30, 5:05 am 2008
Jiri Kosina
Re: Linux 2.6.27-rc8
So far all the affected systems I am aware of were ICH. -- Jiri Kosina SUSE Labs --
Sep 30, 7:11 am 2008
Luiz Fernando N. Cap ...
Re: Linux 2.6.27-rc8
Em Tue, 30 Sep 2008 09:58:56 +0200 Eric Piel <eric.piel@tremplin-utc.net> escreveu: | Jiri Kosina schreef: | > On Mon, 29 Sep 2008, Linus Torvalds wrote: | > | >>> If it is X related then its both a kernel + X server issue, the e1000e | >>> driver opens the barn door, the X server drives the horses through it. | >> Are you sure? There was a mandriva report abou NVM corruption on an e100 | >> too (that one apparently just caused PXE failure, the networking worked | >> fine). | > | > ...
Sep 30, 9:28 am 2008
Herton Ronaldo Krzes ...
Re: Linux 2.6.27-rc8
He finished checks and discovered the e100 issue was in reality a hardware problem in the switch being used that started to have problems now, coincidently with this e1000e issue getting more attention, after swapping the switch the problem stopped, so just a false alarm. I closed https://qa.mandriva.com/show_bug.cgi?id=44192 that was the original report. -- []'s Herton --
Sep 30, 11:27 am 2008
H. Peter Anvin
Re: Typo bug [Re: Linux 2.6.27-rc8]
If we're fixing a typo anyway I'd suggest so. We know we're not breaking anyone's working setup... -hpa --
Sep 30, 12:59 pm 2008
Yinghai Lu
Re: Typo bug [Re: Linux 2.6.27-rc8]
mtrr_cleanup and no_mtrr_cleanup? YH --
Sep 30, 2:35 pm 2008
Yinghai Lu
Re: Typo bug [Re: Linux 2.6.27-rc8]
i need to document the mtrr_cleanup_debug too...change it to mtrrcleanup_debug ? just like initcall_debug? YH --
Sep 30, 2:42 pm 2008
Thomas Gleixner
RE: Linux 2.6.27-rc8
Can we get the simple debug patches including the fixes which resulted from them pushed upstream ASAP ? Thanks, tglx --
Sep 30, 3:07 pm 2008
Paul E. McKenney
Re: [GIT pull] timer fixes for .27
For "we" == Thomas, yes. ;-) --
Sep 29, 8:54 pm 2008
Linus Torvalds
Re: [GIT pull] timer fixes for .27
Did you forget to push? The tip of that branch is still commit 1eda81495a49a4ee91d8863b0a441a624375efea ("x86: prevent stale state of c1e_mask ...") which I already pulled last week. Linus --
Sep 30, 7:34 am 2008
Benjamin Herrenschmidt
Re: [GIT pull] timer fixes for .27
Ah, so we found and fixed these ? Linus, those bugs are actually a regression from when we didn't use the new timer code (which isn't that long ago). It would be nice to have the fixes in .27 (and thus in the various distros that will derive from it) but I would understand if the size of the patch made you choke that late in the -rc cycle... In which case we'll be in for more backports :-) Cheers, Ben. --
Sep 29, 8:41 pm 2008
Paul E. McKenney
Re: [GIT pull] timer fixes for .27
One other thing -- these bugs affect x86 as well as Power. Just takes more stress for x86 to see the bugs in some cases. --
Sep 29, 9:02 pm 2008
Ingo Molnar
Re: [GIT pull] timer fixes for .27
hm, i just re-ran the pushout script - see below. Ingo ---------> Linus, Please pull the latest timers-fixes-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git timers-fixes-for-linus Thanks, Ingo ------------------> Thomas Gleixner (4): hrtimer: migrate pending list on cpu offline hrtimer: fix migration of CB_IRQSAFE_NO_SOFTIRQ hrtimers hrtimer: mark migration state hrtimer: prevent migration of per ...
Sep 30, 8:16 am 2008
Ingo Molnar
Re: [patch 2/2] x86: move prefill_possible_map calling e ...
applied to tip/x86/core, thanks Chuck! Made it a single delta patch, to ease backporting. Ingo --
Sep 30, 12:53 am 2008
Ingo Molnar
Re: [patch] xen: make CONFIG_XEN_SAVE_RESTORE depend on ...
applied to tip/x86/xen, thanks! (hand-applied it as this portion already changed relative to mainline) Ingo --
Sep 30, 12:58 am 2008
Jon Smirl
Re: [RFC PATCH 0/4] Implementation of IR support using t ...
You need to write an app to use the sysfs interface for raw code. Or you could write an in-kernel encoder/decoder and use the standard interfaces. Or you could throw it away and spend $10 for a standard one. -- Jon Smirl jonsmirl@gmail.com --
Sep 29, 5:13 pm 2008
Alexey Starikovskiy
Re: BUG: Commit 1b7fc5aae8867046f8d3d45808309d5b7f2e036a ...
could you please uncomment "#define DEBUG" in the beginning of drivers/acpi/ec.c? please also open bug report in bugzilla.kernel.org against ACPI and attach dmesg from working and broken kernel with enabled DEBUG. Let me know the number of bug report. Thanks, Alex. --
Sep 29, 9:46 pm 2008
Karol Lewandowski Sep 30, 7:08 am 2008
H. Peter Anvin
Re: [PATCH] x86: mtrr_cleanup safe to get more spare regs now
Tried it out, works great. Added to x86/mtrr. Thanks! -hpa --
Sep 29, 6:34 pm 2008
Matthew Garrett
Re: Put unused PCI devices in D3
The majority (though it's not universal) of modern hardware can be put into a state where you get most of the power savings of the entire part being in D3 but with little functional regression. While I'm not averse to adding features that aid the power user who's happy to poke around with individual drivers, this shouldn't be at the expense of implementing good runtime power management for the more common case. Not that I'm suggesting you're doing that, I just want to emphasise that ...
Sep 29, 6:06 pm 2008
Jeffrey W. Baker
Re: Put unused PCI devices in D3
True. On my hardware, the smbus controller doesn't advertise power Very cool. netbsd-current apparently has this already (and a kernel-wide topological representation of PCI power management I sure would like to have it back, if only just for experimentation. Right now, I don't even know what kind of power savings could be achieved from D3, I'm just speculating. As you rightfully point out, it's possible that the driver could put the device into an ultra-low power saving state while ...
Sep 29, 5:55 pm 2008
Matthew Garrett
Re: Put unused PCI devices in D3
The fact that Linux isn't using a device doesn't inherently mean that the system isn't using it. For example, the smbus controller will Potential problems with hotplugging? But sure, this kind of thing is Nothing I'm aware of. It sounds pretty safe in that case. But that would require you to load and unload the driver - better to have the driver loaded the entire time and make sure it does as much runtime power management as possible. I don't know enough about the firewire OHCI ...
Sep 29, 5:09 pm 2008
Gary Hade
Re: [PATCH] mm: show node to memory section relationship ...
Yes, this would be nice but unfortunately the presence of the memory section directories that are referenced by the symlinks also depend on CONFIG_MEMORY_HOTPLUG_SPARSE being enabled. Removal of the memory hotplug dependency for the code in drivers/base/memory.c will require more than a simple CONFIG_MEMORY_HOTPLUG_SPARSE to CONFIG_SPARSEMEM dependency change. I am still looking at this. Thanks for the review and testing. Gary -- Gary Hade System x Enablement IBM Linux Technology ...
Sep 30, 4:29 pm 2008
Dave Hansen
Re: [PATCH] mm: show node to memory section relationship ...
Crap, I was worried about that. Gary, this means that we have a N:1 relationship between NUMA nodes and sections. This normally isn't a problem because sections don't really care about nodes and they layer underneath them. We'll probably need multiple symlinks in each section directory. -- Dave --
Sep 30, 8:50 am 2008
Yasunori Goto
Re: [PATCH] mm: show node to memory section relationship ...
: I think this patch is convenience even when memory hotplug is disabled. If the first page of the section is not valid, then this section_nr_to_nid() doesn't return correct value. I tested this patch. In my box, the start_pfn of node 1 is 1200400, but section_nr_to_pfn(mem_blk->phys_index) returns 1200000. As a result, the section is linked to node 0. Bye. -- Yasunori Goto --
Sep 30, 1:06 am 2008
Gary Hade
Re: [PATCH] mm: show node to memory section relationship ...
So, using Yasunori-san's example the memory section starting at or perhaps symlinks to the same section directory from >1 node directory. Gary -- Gary Hade System x Enablement IBM Linux Technology Center 503-578-4503 IBM T/L: 775-4503 garyhade@us.ibm.com http://www.ibm.com/linux/ltc --
Sep 30, 12:41 pm 2008
Pekka Enberg
Re: [patch 3/4] cpu alloc: The allocator
I think you're confusing it to "nr_units" or, alternatively, I need new glasses. --
Sep 30, 4:48 am 2008
Christoph Lameter
Re: [patch 3/4] cpu alloc: The allocator
You are right. units is debri from earlier revs and has no function today. Subject: cpu_alloc: Remove useless variable The "units" variable is a leftover and has no function at this point. Signed-off-by: Christoph Lameter <cl@linux-foundation.org> Index: linux-2.6/mm/cpu_alloc.c =================================================================== --- linux-2.6.orig/mm/cpu_alloc.c 2008-09-30 07:09:09.000000000 -0500 +++ linux-2.6/mm/cpu_alloc.c 2008-09-30 07:10:20.000000000 -0500 @@ ...
Sep 30, 5:12 am 2008
Christoph Lameter
Re: [patch 3/4] cpu alloc: The allocator
This is the number of units available from the cpu allocator. Its determined on bootup and the bitmap is sized correspondingly. --
Sep 30, 4:38 am 2008
Pekka Enberg
Re: [patch 3/4] cpu alloc: The allocator
What is this thing? Otherwise looks good to me. --
Sep 29, 11:35 pm 2008
Rusty Russell
Re: [patch 0/4] Cpu alloc V6: Replace percpu allocator i ...
Hi Christoph, I'm not particularly attached to the allocator in module.c, and yours is Yerch. OK, it *is* better than nothing. Thanks for digging into this again, Rusty. --
Sep 30, 3:27 pm 2008
Rusty Russell
Re: [patch 4/4] cpu alloc: Use cpu allocator instead of ...
Acked-by: Rusty Russell <rusty@rustcorp.com.au> Thanks, Rusty. --
Sep 30, 3:28 pm 2008
Ingo Molnar
Re: [PATCH] x86: IOMMU setup failures should not be KERN_ERR
applied to tip/x86/debug, thanks Adam! Ingo --
Sep 30, 1:25 am 2008
Ingo Molnar
Re: [PATCH V2 -tip 3/4] Tracing/ftrace: Adapt mmiotrace ...
thanks guys! Steve's latest trace-ringbuffer code against -tip complicates life a little bit. We dont yet know whether tip/tracing/ring-buffer is ready for wider consumption, so it's in a separate feature branch. These four patches conflict with the ring-buffer code quite widely. So ... i did an optimistic merge approach: i merged these 4 patches ontop of the new tip/tracing/ring-buffer code, and have put it into a new tip/tracing/pipe branch: # f19d495: tracing/ftrace: adapt ...
Sep 30, 1:52 am 2008
Steven Rostedt
Re: [PATCH V2 -tip 3/4] Tracing/ftrace: Adapt mmiotrace ...
Opps, I mean the find_next_entry_inc will do the lock. The ring_buffer_lock locks all CPU buffers, and the find_next_entry_inc will read from the ring buffer which will also lock the buffer. Hence a deadlock. --
Sep 30, 6:33 am 2008
Frédéric Weisbecker
Re: [PATCH V2 -tip 3/4] Tracing/ftrace: Adapt mmiotrace ...
Strange, I can't see any case where print_trace_line could call the ring_buffer_lock. Hmm, I will see in your patch. Ingo, I just saw one damage from the merging, trace_empty() returns TRACE_TYPE_HANDLED. The type is wrong, it should return 1. It's not urgent since the value is the same. Should I send a patch for such a small error? Thanks. --
Sep 30, 6:25 am 2008
Ingo Molnar
Re: [PATCH V2 -tip 3/4] Tracing/ftrace: Adapt mmiotrace ...
yes, please do. One too many patch is far better than one too few ;-) Ingo --
Sep 30, 8:39 am 2008
Frederic Weisbecker
Re: [PATCH V2 -tip 3/4] Tracing/ftrace: Adapt mmiotrace ...
Here it is! Subject: [PATCH -tip] Tracing/ftrace: correct return value of trace_empty Correct the value's type of trace_empty function Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com> --- diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index 6a1c76b..da3789d 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -1686,7 +1686,7 @@ static int trace_empty(struct trace_iterator *iter) if (!ring_buffer_iter_empty(iter->buffer_iter[cpu])) return 0; ...
Sep 30, 9:13 am 2008
Steven Rostedt
Re: [PATCH V2 -tip 3/4] Tracing/ftrace: Adapt mmiotrace ...
OK, I'll nuke the ring_buffer_lock :-/ The trace_pipe calls that and then calls print_trace_line which will eventually lock the buffer again. This is a bug on my part. I'll fix that today. Thanks, -- Steve --
Sep 30, 5:45 am 2008
Frédéric Weisbecker
Re: [PATCH V2 -tip 3/4] Tracing/ftrace: Adapt mmiotrace ...
Thanks Ingo. I'm currently testing tip/master, since tracing/pipe is merged into. It seems there are some locking issues that I hadn't when I tested the patches. Perhaps it's because of the merge with the new ring buffer. I just launched the sched_switch tracer and it worked well until 4 seconds of execution. And after that it blocked. I tested too a marker message adding and it is never displayed. Worse: I can't break the pipe with Ctrl + C after that. When I will have some time, I will ...
Sep 30, 5:39 am 2008
Frédéric Weisbecker Sep 30, 9:16 am 2008
Hiroshi Shimamoto
Re: [PATCH -tip] sched: fix using uninilialzed rq in tas ...
No I've never seen any problem yesterday. And I didn't have much time to use tip tree yesterday:) Today's looks good. thanks, Hiroshi Shimamoto --
Sep 30, 9:45 am 2008
Ingo Molnar
Re: [PATCH -tip] sched: fix using uninilialzed rq in tas ...
heh, just fixed that as well, latest tip/master should have the fix. Have you seen any weirdness due to this uninitialized variable? Ingo --
Sep 30, 1:58 am 2008
Frédéric Weisbecker
Re: A style question: repeated return value check
I think the same. The code flow seems to me more natural as is even if it looks more noisy. IMHO, when one is reading the code, such a compact path forces a break to figure out what is going on in these tests. But I agree with Pekka for the fact that it could be unified in a single call to trace_seq_printf. That will produce a small "3 format" easy to understand. Seems good. --
Sep 30, 1:48 am 2008
Frédéric Weisbecker
Re: A style question: repeated return value check
Actually it's a "5 format". Why not unify... --
Sep 30, 1:50 am 2008
Ingo Molnar
Re: A style question: repeated return value check
in this particular case it's marginally worse style i think, even considering that it makes the code more compact. The reason is that it makes the code a tiny bit less obvious: the flow looks a bit unusual and when skimming it i'd have to look once more to understand its purpose. With the returns its more verbose but also plain obvious. YMMV. Ingo --
Sep 30, 1:33 am 2008
Jeremy Fitzhardinge
Re: [PATCH] x86: do not allow to optimize flag_is_change ...
If "asm volatile" changes the code and fixes the bug, it seems like you're making use of an undocumented - or at least non-portable - behaviour. Does adding a "memory" clobber also fix the problem? That would have better defined characteristics. --
Sep 29, 11:14 pm 2008
Yinghai Lu
Re: [PATCH] x86: do not allow to optimize flag_is_change ...
how about if (!have_cpuid_p()) { identify_cpu_without_cpuid(c); /* cyrix could have cpuid enabled via c_identify()*/ if (!have_cpuid_p()) return; } YH --
Sep 29, 11:34 pm 2008
Jeremy Fitzhardinge
Re: [PATCH] x86: do not allow to optimize flag_is_change ...
That doesn't help, does it? If gcc thinks it can get away with evaluating have_cpuid_p() once, then that's the same as: if (!have_cpuid_p()) { identify_cpu_without_cpuid(c); return; } even though identify_cpu_without_cpuid() can cause the cpu to suddenly start supporting cpuid. The trouble is that flag_is_changeable_p() doesn't have any obvious global dependencies; it just takes a constant argument and returns a result. The asm() needs to be updated to have a "memory" ...
Sep 29, 11:54 pm 2008
Rusty Russell
Re: [PATCH 01/31] cpumask: Documentation
Hi Mike, I have several problems with this patch series. First, it's a flag day change, which means it isn't bisectable and can't go through linux-next. Secondly, we still can't hide the definition of the cpumask struct as long as they're passed as cpumask_t, so it's going to be hard to find assignments (illegal once we allocate nr_cpu_ids bits rather than NR_CPUS), and on-stack users. Finally, we end up with code which is slightly more opaque than the current code, with ...
Sep 30, 3:49 pm 2008
Ingo Molnar
Re: [PATCH 05/31] cpumask: Provide new cpumask API
minor namespace nit i noticed while looking at actual usage of cpus_copy(): could you please rename it cpumask_set(dst, src)? That streamlines it to have the same naming concept as atomic_set(), node_set(), zero_fd_set(), etc. the patch-set looks quite nice otherwise already, the changes are straightforward and the end result already looks a lot more maintainable and not fragile at all. In what way will Rusty's changes differ? Since you incorporate some of Rusty's changes already, ...
Sep 30, 2:11 am 2008
Mike Travis
Re: [PATCH 05/31] cpumask: Provide new cpumask API
Cpus_copy came from it's underlying function: bits_copy(). Cpumask_set would deviate from the current naming convention of cpu_XXX for single I was hoping for a stronger compiler error to indicate incorrect usage, it currently just says "may be used before it's initialized" if you mistakenly Our timezones are not very conducive to a lot of email exchanges (and he's moving.) From what I've seen I believe he's leaning towards using struct cpumask * and less trickery than I have. The other ...
Sep 30, 8:42 am 2008
Mike Travis
Re: [PATCH 05/31] cpumask: Provide new cpumask API
Oh yeah, I forgot the other major point of Rusty's approach. He wants the patchset to be completely bisectable. That's far from true in my version. Thanks, Mike --
Sep 30, 9:17 am 2008
Serge E. Hallyn Sep 30, 12:51 pm 2008
Serge E. Hallyn
Re: [PATCH 06/14] KConfig: Add KConfig entries for Labeled NFS
A little more here :) "Say Y here if you want security label attribute support for NFS version 4. Security labels allow security modules like SELinux and Smack to label files to facilitate enforcement of their policies. If you do not wish to enforce SELinux or Smack policies on NFSv4 files, say N." Or something... the idea being to make it clear to anyone configuring --
Sep 30, 1:40 pm 2008
Ingo Molnar
Re: [PATCH] x86: enable CPUID on Cyrix cpus with CPUID d ...
now that the bug is correctly understood and fixed, could you please send a patch that cleans it all up and gets rid of the setCx86_old() / setCx86() API distinction? I.e. revert commit 026e2c0 ("x86, cyrix: debug"). Against tip/master please. note that this was all done in connection to: commit c6744955d0ec0cb485c28c51eeb7185e260f6172 Author: Samuel Sieb <samuel@sieb.net> Date: Wed Aug 6 22:06:29 2008 -0700 x86: fix "kernel won't boot on a Cyrix MediaGXm ...
Sep 30, 2:43 am 2008
KAMEZAWA Hiroyuki
Re: setup_per_zone_pages_min(): zone->lock vs. zone->lru_lock
On Mon, 29 Sep 2008 23:20:05 +0200 At first look, replacing zone->lru_lock with zone->lock is enough... This function is an only one function which use zone->lru_lock in page_alloc.c And zone_watermark_ok() which access zone->pages_min/low/high is not under any locks. So, taking zone->lru_lock here doesn't seem to be necessary... Thanks, -Kame --
Sep 29, 5:40 pm 2008
Yasunori Goto
Re: setup_per_zone_pages_min(): zone->lock vs. zone->lru_lock
The zone->lru_lock() have been used before memory hotplug code was I agree. Bye. -- Yasunori Goto --
Sep 29, 6:53 pm 2008
Linus Torvalds
Re: [patch 2/2] PNP: don't check disabled PCI BARs for c ...
Hell no. We do not want any implicit parallelism in the initcalls. That way lies madness. The probe functions that explicitly know that they are slow (like USB detection and/or other individual drivers that have timeouts) should put themselves in the background. We should _not_ use the dependency chain to do so automatically, because for most cases drivers are totally independent, but we still want a _reliable_ and _repeatable_ ordering. Which means that I will not accept stuff ...
Sep 30, 12:51 pm 2008
Rene Herman
Re: [patch 2/2] PNP: don't check disabled PCI BARs for c ...
Well, if you say so... Just did the attached which might match that intention. Please do not consider this a submission as I've no idea if this is sensible nor if it actually helps Frans. Just for discussion. Anything here should arrive through Bjorn. Rene.
Sep 30, 2:19 am 2008
Linus Torvalds
Re: [patch 2/2] PNP: don't check disabled PCI BARs for c ...
I think you got the logic the wrong way around: + /* have we been registered already? */ + if (pci_res->parent) + continue; This ignores resources that are _registered_, but it should be the other way around - we should ignore resources that aren't (because they may be invalid or they may move around) + pci_start = pci_res->start; + pci_end = pci_res->end; + + ...
Sep 30, 7:48 am 2008
Linus Torvalds
Re: [patch 2/2] PNP: don't check disabled PCI BARs for c ...
Oh, ok. Looking at it, it does seem that we actually _insert_ the PCI resources too late. We do it in pcibios_allocate_resources(), and there we even take care to look at whether it was enabled or disabled (we prioritize enabled resources, so that a disabled one will never be requested before an enabled one and if they clash, it's always the disabled one that loses the resource). But pcibios_allocate_resources() is called from pcibios_resource_survey(), which is called from ...
Sep 30, 9:29 am 2008
Arjan van de Ven
Re: [patch 2/2] PNP: don't check disabled PCI BARs for c ...
On Tue, 30 Sep 2008 12:51:07 -0700 (PDT) just to avoid any confusion; the current -fastboot tree does not do this parallel stuff. At all. (so please don't judge it as doing that) -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org --
Sep 30, 12:54 pm 2008
Rene Herman
Re: [patch 2/2] PNP: don't check disabled PCI BARs for c ...
Yes, I also get that oops but other than that, both link order versions you sent out work -- ie, booting with acpi=noirq gets me to a functional system with the quirk having run for PNP0c02 (acpi=off disables all of PNP0c02) and doing its job. For some reason only some of your messages seem to be making it into my inbox (in order, at least) but either of these that is: http://lkml.org/lkml/2008/9/30/242 http://lkml.org/lkml/2008/9/30/261 With the attached on top, all's working fine ...
Sep 30, 12:29 pm 2008
Rene Herman
Re: [patch 2/2] PNP: don't check disabled PCI BARs for c ...
It doesn't. With the test negated it triggers for all PCI resources (and ofcourse my soundcard driver fails again). If the simple res->start == 0/SOME_ARCH_DEFINE definitely won't do and the issue with Bjorn's approach is the bus hammering the solution might be to set a per resource flag in pci_dev at parse time? (that's PCI though and I can't really be here at the moment so over to someone else). Rene. --
Sep 30, 8:57 am 2008
Rene Herman
Re: [patch 2/2] PNP: don't check disabled PCI BARs for c ...
I'll have to wait for the message to arrive here or in a web-archive to answer that (...) but please note that I am already fine with the original code; it is the fix for my own issue that's IN mainline (ie, not only check for MEM resource overlaps but also IO) that now made Frans Pop yell due to his machine now spitting out lots of I/O overlap warnings -- which turned out to not be real overlaps, but due to a uninialized BAR. You might want Frans to test this though ...
Sep 30, 12:51 pm 2008
Bjorn Helgaas
Re: [patch 2/2] PNP: don't check disabled PCI BARs for c ...
Right. The point of this quirk (quirk_system_pci_resources()) is to prevent the PNP system driver from claiming resources that are actually used by PCI. So I don't think there's any reason to run it before we bind the driver to the device. PNP doesn't currently have any early/ late concept for quirks, but we probably should add one. Feels like a post-2.6.27 project though. Bjorn --
Sep 30, 12:16 pm 2008
Linus Torvalds
Re: [patch 2/2] PNP: don't check disabled PCI BARs for c ...
Side note: unlike the more radical "move all arch driver initcalls earlier", this one actually works for me. But it does cause pnp_system_init() to actually run before pnpacpi_init and pnpbios_init, due to the link order within PnP. That seems ok, since the system/acpi/pnp drivers should all be just different versions of PnP drivers, but I thought I'd mention it. Maybe there is some PnP internal reason why pnp_system_init should run after the pnp_acpi/bios_init functions. (And if ...
Sep 30, 11:13 am 2008
Rolf Eike Beer
Re: [patch 2/2] PNP: don't check disabled PCI BARs for c ...
Why calculate this at boot time? Do you expect this to change between bootups? Eike
Sep 30, 1:05 pm 2008
Rene Herman
Re: [patch 2/2] PNP: don't check disabled PCI BARs for c ...
Yes. I am fine on current mainline and with this seem to still be fine, with or without the quirk changes (*) applied. (*) http://marc.info/?l=linux-kernel&m=122280330516865&w=2 Frans Pop will need something like those quirk changes on top to have his machine stop yelling at him -- assuming it actually works for him that is (which it should I guess, but it's not been tested by him yet). The pci_start == 0 version, attached for convenience and also still available from the ...
Sep 30, 1:48 pm 2008
Bjorn Helgaas
Re: [patch 2/2] PNP: don't check disabled PCI BARs for c ...
Sorry for the delay in responding -- I'm officially on vacation yesterday and today. I agree that for 2.6.27 the "res->start == 0 means disabled" check in the PNP quirk seems safest. I don't like it long-term, because (a) I'd like that knowledge to at least be in PCI, not PNP, and (b) res->start is the CPU address, not necessarily the PCI bus address, and the BAR value (== PCI bus address) is what we're trying to check. Even if we looked at the BAR value instead of res->start, I think ...
Sep 30, 12:12 pm 2008
Linus Torvalds
Re: [patch 2/2] PNP: don't check disabled PCI BARs for c ...
Btw, why is that? We very much have a separate /** * Reserve motherboard resources after PCI claim BARs, * but before PCI assign resources for uninitialized PCI devices */ fs_initcall(pnp_system_init); which is called much later. That seems to be the _right_ point for any quirks. It seems that the _real_ problem here is that the PnP device fixup is simply called from the wrong point. Ie, why do we do device discovery - and thus PnP quirks - in pnp_init (before the PCI bus ...
Sep 30, 11:01 am 2008
Rene Herman
Re: [patch 2/2] PNP: don't check disabled PCI BARs for c ...
It does, but that said... placing the attached small debug printk's on which does still feel rather clunky (especially the missing "middle" resources 7, 8 and 9 for 01.0, my AGP bridge, look a little weird). (0a.0 is ofcourse my soundcard that is the issue) The resources array for pci_dev is static -- a pci_dev bitmask of enabled resources does sound somewhat nice-ish still perhaps. Rene.
Sep 30, 12:37 pm 2008
Linus Torvalds
Re: [patch 2/2] PNP: don't check disabled PCI BARs for c ...
A clearer (and more flexible) solution might be this patch. It's more explicit about the fact that it simply makes it clear that any drivers that are added by the architecture Makefile will be _first_ in the list of drivers. I suspect we should do the same with 'libs' and 'core' too, for that matter, but we don't really use '*.a' libraries any more so link order doesn't matter apart from initcall ordering. And libraries should hopfully never have that issue. And 'core' is at least ...
Sep 30, 10:10 am 2008
Ingo Molnar
Re: [patch 2/2] PNP: don't check disabled PCI BARs for c ...
well, as i mentioned it was and is on the backburner, because we went over the same list of problems that you mentioned: harder to read and interpret and debug, harder to reproduce boot ordering, etc. but i'd still like the address the above specific point: it would be silly to propagate Kconfig dependencies into the initcall dependencies, why do you assume we'd do that? When PROCFS or PNP is turned off, then their initcall symbols should naturally alias to some NOP definition, a ...
Sep 30, 1:01 pm 2008
Linus Torvalds
Re: [patch 2/2] PNP: don't check disabled PCI BARs for c ...
Ok. But that means that the last patch I sent out - the one that _only_ changes the order for PnP itself, and moves pnpacpi_init and pnpbios_init to be fs_initcalls - should also work, and have none of he other Don't know why you can't see the messages, but in case this one comes through but not the other ones, look at the third patch in http://lkml.org/lkml/2008/9/30/283 instead. Linus --
Sep 30, 12:44 pm 2008
Linus Torvalds
Re: [patch 2/2] PNP: don't check disabled PCI BARs for c ...
It looks like both of these will fall afoul of the fact that ACPI currently seems to _expect_ to be called in the old order, ie I get some oops in acpi_irq_penalty_init() apparently because it knew that it got called later (thanks to being called from pci_acpi_init in the arch-specific directory), and knew that the other ACPI subsys setup routines had been done before. Dang. I guess we'll have to bite the bullet some day and actually create some explicit topological ordering of ...
Sep 30, 10:21 am 2008
Ingo Molnar
Re: [patch 2/2] PNP: don't check disabled PCI BARs for c ...
incidentally, i've been talking to Arjan about this recently in context of the CONFIG_FASTBOOT feature. Because, as a side-effect, in the long run, once the dependencies between initcalls fan out in a more natural way, with explicit initcall ordering we'll also be able to boot a bit faster and a bit more parallel. [ but performance is far less important than robustness, so this idea was on the backburner. ] and i think on the conceptual level initcall levels and implicit ...
Sep 30, 12:38 pm 2008
Ingo Molnar
Re: [PATCH] - New UV genapic functions for x2apic
applied to tip/x86/core, thanks Jack. small patch submission request, could you please use this format in future patches: Subject: [PATCH] x86, UV: new genapic functions for x2apic instead of: Subject: [PATCH] - New UV genapic functions for x2apic that follows the typical subject line patterns in x86 commits more closely. Fixed it up in this patch, no need to resend. Thanks, Ingo --
Sep 30, 2:49 am 2008
Stefan Bader
Re: [PATCH] x86: Reserve FIRST_DEVICE_VECTOR in used_vec ...
I can't see this as required for tip. FIRST_DEVICE_VECTOR is there defined distinct to the ISA IRQs (IRQ15_VECTOR+2) while it is defined to be equal to IRQ0_VECTOR on 2.6.27 and before (at least down to 2.6.24). Regards, Stefan -- When all other means of communication fail, try words! --
Sep 30, 5:53 am 2008
Ingo Molnar
Re: [PATCH] x86: Reserve FIRST_DEVICE_VECTOR in used_vec ...
hi, the IO-APIC code got unified in the x86 tree for v2.6.28. So could you please send the fix against tip/master: http://people.redhat.com/mingo/tip.git/README Thanks, Ingo --
Sep 30, 2:51 am 2008
Balbir Singh
Re: [PATCH 3/4] memcg: avoid account not-on-LRU pages
Coding style braces for a single-line if-else, please recheck -- Balbir --
Sep 30, 1:14 am 2008
KAMEZAWA Hiroyuki
[PATCH/stylefix 3/4] memcg: avoid account not-on-LRU pages
This is conding-style fixed version. Thank you, Nishimura-san. -Kmae == There are not-on-LRU pages which can be mapped and they are not worth to be accounted. (becasue we can't shrink them and need dirty codes to handle specical case) We'd like to make use of usual objrmap/radix-tree's protcol and don't want to account out-of-vm's control pages. When special_mapping_fault() is called, page->mapping is tend to be NULL and it's charged as Anonymous page. insert_page() also handles some special ...
Sep 29, 6:17 pm 2008
Balbir Singh
Re: [PATCH 1/4] memcg: account swap cache under lock
Looks good to me Acked-by: Balbir Singh <balbir@linux.vnet.ibm.com> -- Balbir --
Sep 30, 1:05 am 2008
Amit K. Arora
Re: [PATCH] sched: minor optimizations in wake_affine an ...
Thats a good question. Its kind of arguable and I wasn't sure if everyone will be happy if I removed more arguments from wake_affine() than what I did in my patch (because of the recalculations required). wake_affine() currently has 11 arguments and I thought it may make sense in reducing it to a sane number. For that I chose arguments which I thought can be recalculated with minimum overhead (involves single struct dereference, a simple per cpu variable and/or a simple arithmetic). And one ...
Sep 30, 12:03 am 2008
Ingo Molnar
Re: [PATCH][resubmit] sched: minor optimizations in wake ...
applied to tip/sched/devel, thanks Amit! Ingo --
Sep 30, 6:26 am 2008
Amit K. Arora
[PATCH][resubmit] sched: minor optimizations in wake_aff ...
As mentioned in http://lkml.org/lkml/2008/9/30/141 , this is the new patch. sched: Minor optimizations in wake_affine and select_task_rq_fair This patch does following: o Removes unused variable and argument "rq". o Optimizes one of the "if" conditions in wake_affine() - i.e. if "balanced" is true, we need not do rest of the calculations in the condition. o If this cpu is same as the previous cpu (on which woken up task was running when it went to sleep), no need to call ...
Sep 30, 4:45 am 2008
Ingo Molnar
Re: [PATCH] sched: minor optimizations in wake_affine an ...
it's usually not worth it, especially if it leads to duplicated calculations (and code) like: + unsigned int imbalance = 100 + (this_sd->imbalance_pct - 100) / 2; gcc will optimize it away because it's all static functions, but still. 'size kernel/sched.o' should be a good guideline: if the .o's text section gets smaller due to a patch it usually gets faster as well. Ingo --
Sep 30, 12:01 am 2008
Amit K. Arora
Re: [PATCH] sched: minor optimizations in wake_affine an ...
Ok. I will resubmit the patch with other suggested changes only. It won't try to reduce wake_affine's arguments (besides the first argument "rq" which is not being used at all). Regards, --
Sep 30, 4:40 am 2008
Paul E. McKenney
Re: [PATCH] RCU read sched
Please do! Thanx, Paul --
Sep 30, 6:10 am 2008
Ingo Molnar
Re: [PATCH] RCU read sched
Paul, does this API extension look good to you? i'll apply it to tip/core/rcu if yes. Ingo --
Sep 30, 3:08 am 2008
Jeremy Kerr
Re: [PATCH] sputrace : use marker_synchronize_unregister()
Looks good - added to spufs.git. Cheers, Jeremy --
Sep 29, 5:28 pm 2008
Ingo Molnar
Re: [PATCH] Markers use rcu_read_lock_sched()
applied this cleanup on top of the fix from Lai Jiangshan, thanks Matthieu! here are the new commits in tip/tracing/markers: 2396ac3: sputrace: use marker_synchronize_unregister() a16801c: markers: documentation fix for teardown b05d9cf: markers: probe example, fix teardown 4b0b16f: markers: fix unregister bug and reenter bug, cleanup 1638da5: markers: marker_synchronize_unregister() b211730: Merge branch 'core/rcu' into tracing/markers 1c50b72: rcu: add rcu_read_lock_sched() / ...
Sep 30, 3:13 am 2008
Ingo Molnar
Re: [PATCH] sputrace : use marker_synchronize_unregister()
that wont work very well as the patch relies on the new marker_synchronize_unregister() facility. Ingo --
Sep 30, 2:55 am 2008
Jeremy Kerr
Re: [Cbe-oss-dev] [PATCH] sputrace : use marker_synchron ...
d'oh, right you are. Should I leave this in your hands to merge? Cheers, Jeremy --
Sep 30, 4:22 am 2008
Jeremy Kerr
Re: [Cbe-oss-dev] [PATCH] sputrace : use marker_synchron ...
Sure! Acked-by: Jeremy Kerr <jk@ozlabs.org> Jeremy --
Sep 30, 4:34 am 2008
Lai Jiangshan
Re: [PATCH] Markers : marker_synchronize_unregister()
marker_synchronize_unregister must be called _also_ between unregistration and destruction the data that unregistration-ed probes need to make sure --
Sep 29, 6:47 pm 2008
Ingo Molnar
Re: [Cbe-oss-dev] [PATCH] sputrace : use marker_synchron ...
would be nice if you could give your Acked-by for the sputrace bits, then we can merge it. It's a oneliner so it shouldnt cause merging trouble in linux-next. Ingo --
Sep 30, 4:30 am 2008
Paul E. McKenney
Re: [PATCH] RCU read sched
Looks like a very good addition to me! Thanx, Paul --
Sep 30, 6:10 am 2008
Lai Jiangshan
Re: [PATCH] markers: fix unregister bug and reenter bug
1) the new API marker_synchronize_unregister() is ugly, it separate one thing into two steps. user have to remember to call marker_synchronize_unregister() and have to know what he can do and what he can't do before marker_synchronize_unregister(). 2) IMO, synchronous code is better than asynchronous in non-critical-path. we need synchronize_sched() for free(old). you fixes haven't fix the reenter bug. --
Sep 29, 6:40 pm 2008
Mathieu Desnoyers
Re: [PATCH] markers: fix unregister bug and reenter bug
Hum, yes it does separate unregistration and synchronization in two steps for a very precise purpose : I don't want unregistration of 100 free(old) is only done in call_rcu. the rcu callback is forced by a rcu_barrier() if two consecutive operations are done on the same I don't see any reentrancy bug here. Have you actually experienced such an issue ? Can you give me an example of a bogus execution trace (step-by-step operations) ? Thanks, -- Mathieu Desnoyers OpenPGP key ...
Sep 29, 8:38 pm 2008
Oleg Nesterov
Re: [REV2: PATCH 1/2]: workqueue: Implement the kernel API
Yes I see. But actually I meant "see below, I don't think we need Exactly! And in that case update_timer_expiry() will do its work. Yes, the games with __queue_delayed_work() can save a couple of clear/set bit, but this is the slow an unlikely path, that was my point. And, if we are talking about the function call overhead. Please note that __queue_delayed_work() adds the "unnecessary" call to the "normal" queue_delayed_work(), and this path is more common. Hmm. How so? cancel() ...
Sep 30, 6:15 am 2008
Krishna Kumar2
Re: [REV2: PATCH 1/2]: workqueue: Implement the kernel API
Oleg Nesterov <oleg@tv-sign.ru> wrote on 09/29/2008 07:57:34 PM: The reason I had coded this way was to avoid an unnecessary call - unnecessary since the update function should be usually called to update a work and hence the work is almost always pending. But I will make this change as it is more work. I had tried to capture this information in the comment above, maybe it needs Correct. But the behavior is the same as the existing (say driver) code which calls cancel (which ...
Sep 30, 4:08 am 2008
Tom Zanussi
Re: [RFC PATCH 7/11] relay - Remove padding-related code ...
Yeah, that's pretty much it. In the case of splicing from a relay file to an output file, the path is basically relay->pipe->outfile. To do the relay->pipe part, do_splice_to() needs a splice_read() implementation, Yes, I think a relay splice_write implementation would take the data from a pipe but would write it into a relay buffer i.e. input->pipe->relay with do_splice_from() calling relay's splice_write() implementation. Once the data is in relay, getting it from there to the disk or ...
Sep 29, 10:04 pm 2008
Jens Axboe
Re: [RFC PATCH 7/11] relay - Remove padding-related code ...
I don't understand where you are going with this... With the ->splice_read(), we can move relay data into a pipe and pass that to a user application (or send it off using sendfile() or splice to a socket). So it's a way to get the data to user space, instead of using read(). With a ->splice_write(), you could support adding data to relayfs from userspace. Why? You want the ->splice_write() on the output end, for your socket or file or wherever you want to send to relay data TO. So as long ...
Sep 30, 2:04 am 2008
Justin Mattock
Re: BUG kmalloc-16: Object already free
On Mon, Sep 29, 2008 at 10:21 PM, Justin Mattock O.k. after messing around with /etc/dbus I've applied the patch that was supplied. Looks good!! attached is a before the patch was applied and after the patch was applied. -- Justin P. Mattock
Sep 30, 11:24 am 2008
Justin Mattock
Re: BUG kmalloc-16: Object already free
This was the first time I've seen this, I can apply the patch myself, but first I need to figure why dbus can be such a bitch : ) Need to figure out how to write dbus rules(if this is the case) keep getting the permissions denied crap. -- Justin P. Mattock --
Sep 29, 10:21 pm 2008
Eric W. Biederman Sep 29, 9:06 pm 2008
jmerkey Sep 29, 9:18 pm 2008
Avi Kivity
Re: [PATCH 1/3] ioctl: generic ioctl dispatcher
If the simple calls mostly don't use the argument as a pointer, they are better off using a plain switch. For my own code, I usually leave the boilerplate within the switch and the app-specific code in a separate function anyway, so there's no big change in style. The main motivation here was the extensibility (patch 2), which becomes We need to execute code both before and after the handler, so it would look pretty ugly: long my_ioctl_handler(...) { struct ioctl_arg iarg; ...
Sep 30, 2:08 am 2008
Martin Bligh
Re: [RFC PATCH] LTTng relay buffer allocation, read, write
Ah, sorry, maybe I misread this. No data with no event ids, etc is fairly useless. 4 bytes data including space to record event ids is OK. --
Sep 30, 10:23 am 2008
Steven Rostedt
Re: [RFC PATCH] LTTng relay buffer allocation, read, write
Field goal! Yes! That is exactly what I want. If your trace has only one event, why would it want to record them? The event id belongs in the tracer layer not the ring buffer layer. I would like to make a "trace_buffer" layer that includes all of this. -- Steve --
Sep 30, 1:21 pm 2008
Mathieu Desnoyers
Re: [RFC PATCH] LTTng relay buffer allocation, read, write
In Steven's scheme, the event IDs in the 4 bytes are reserved for (useless) internal use ;) They can therefore not be used for specific tracer event IDs, which I think is a misuse of the precious bits otherwise available to store really useful event IDs. Mathieu -- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 --
Sep 30, 11:14 am 2008
Martin Bligh
Re: [RFC PATCH] LTTng relay buffer allocation, read, write
This is all over 1 bit of information, right? Since you need at least 1 for the timestamp stuff. --
Sep 30, 12:44 pm 2008
Mathieu Desnoyers
Re: [RFC PATCH] LTTng relay buffer allocation, read, write
You are actually using them to put redundant information that could be encoded differently and thus save 4 bits per event records, more or less what will be needed by most tracers (15 IDs, 1 reserved for an extended ID field). So the fact that you use them does not mean they are really required, and I don't think such duplicated information actually makes things more solid. Maybe just more obscure ? Mathieu -- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 ...
Sep 30, 11:35 am 2008
Martin Bligh
Re: [RFC PATCH] LTTng relay buffer allocation, read, write
That's true. So do we have a bunch of stuff that we really really need Sounds like a plan ;-) All this stuff is internal representations anyway. --
Sep 30, 1:49 pm 2008
Mathieu Desnoyers
Re: [RFC PATCH] LTTng relay buffer allocation, read, write
Stuff like irq_exit has 0 byte payload, is very high rate, and useful, Probably pointers on 32 bits archs. Any "int" value, on 32 or 64 bits, will need careful attention if we want only to export the 28 LSBs. It Yup. Mathieu -- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 --
Sep 30, 1:55 pm 2008
Martin Bligh
Re: [RFC PATCH] LTTng relay buffer allocation, read, write
> A 4 byte dataless payload is useless anyway. Not at all convinced that's true - we used it for lots of things. Start and end of irq event is one frequent example. Also, in a compact mode, we can record start and end of syscalls like this (without parameters). --
Sep 30, 10:22 am 2008
Frank Ch. Eigler
Re: [RFC PATCH] LTTng relay buffer allocation, read, write
Hi - That's fine for a ring buffer that only ever contains data from one event source. How do you imagine multiplexing working, where one wants to grep a single debugfs file that contains data from different event sources? Punt to another layer? - FChE --
Sep 30, 1:01 pm 2008
Steven Rostedt
Re: [RFC PATCH] LTTng relay buffer allocation, read, write
I really like the idea of keeping the tracer event ids out of the ring Well, at least for version 1 these bits stay. I already found two bugs by hitting the event padding when the size said it should not have. This redundant information makes me feel a bit more cozy when they match. -- Steve --
Sep 30, 12:43 pm 2008
Steven Rostedt
Re: [RFC PATCH] LTTng relay buffer allocation, read, write
I'm using them, so they must not be totally useless. ;-) But ftrace has its own event ids and I don't want the ring buffer to ever have to know about them. -- Steve --
Sep 30, 11:22 am 2008
Mathieu Desnoyers
Re: [RFC PATCH] LTTng relay buffer allocation, read, write
I am not saying anything about the actual number of events with 0 bytes payload I actually have in my own instrumentation, if this is what you mean. I am just saying that it leaves this room available for such events. Even if there is a 32 bits payload associated with those events, the fact that we can encode the event ID in the 32 bits header will bring 4 bits of information could be added to the 32-bits header if we allow tracers to register their first 15 event IDs in those 4 ...
Sep 30, 12:54 pm 2008
Alex Chiang
Re: [PATCH 4/6 v3] PCI: support SR-IOV capability
Same questions here that I had for the ARI stuff. Does this dev_info add value, or is it more noise, and is this message Do you want to emit a kobject_uevent here after success? Alternatively, have you investigated making these virtual functions into real struct device's? You get a lot of sysfs stuff for free if you do so, including correct place in sysfs hierarchy and uevents, etc. My major complaints from last round (more documentation, shouldn't be a PCI hotplug driver) have been ...
Sep 30, 3:38 pm 2008
Roland Dreier
Re: [PATCH 4/6 v3] PCI: support SR-IOV capability
> + ctrl = pci_ari_enabled(dev) ? PCI_IOV_CTRL_ARI : 0; > + pci_write_config_word(dev, pos + PCI_IOV_CTRL, ctrl); > + ssleep(1); You seem to sleep for 1 second wherever you write the IOV_CTRL register. Why is this? Is this specified by PCI, or is it coming from somewhere else? - R. --
Sep 30, 3:40 pm 2008
Alex Chiang
Re: [PATCH 3/6 v3] PCI: support ARI capability
This is user-visible, so my questions are: 1) Does this really add value for the user? Or is this just more noise? 2) Is this output string informative enough for the user? Thanks. /ac --
Sep 30, 3:31 pm 2008
H. Peter Anvin
Re: Use CPUID to communicate with the hypervisor.
We don't have a quorum to create a consensus, since we only have a subset of the relevant parties present. We can get away with that if we agree on a standard that includes We already have this situation in a number of places. The answer is generally that there is one form that the kernel prefer over another (in CPUID space, leaf 80000006 over leaf 2, for example) because it is The standard way to handle that in CPUID space is to leave the It gives individual sub-APIs ...
Sep 29, 5:31 pm 2008
Nakajima, Jun
RE: Use CPUID to communicate with the hypervisor.
T24gOS8yOS8yMDA4IDU6NTg6MDEgUE0sIEguIFBldGVyIEFudmluIHdyb3RlOg0KPiBOYWthamlt YSwgSnVuIHdyb3RlOg0KPiA+ID4gPg0KPiA+ID4gV2UgZG9uJ3QgaGF2ZSBhIHF1b3J1bSB0byBj cmVhdGUgYSBjb25zZW5zdXMsIHNpbmNlIHdlIG9ubHkgaGF2ZSBhDQo+ID4gPiBzdWJzZXQgb2Yg dGhlIHJlbGV2YW50IHBhcnRpZXMgcHJlc2VudC4NCj4gPg0KPiA+IFdobyBlbHNlIGRvIHdlIG5l ZWQgaGVyZT8NCj4gPg0KPg0KPiBBdCBsZWFzdCBQYXJhbGxlbHMgYW5kIFZpcnR1YWwgUEMvVmly dHVhbCBTZXJ2ZXIuDQo+DQo+ICAgICAgICAgLWhwYQ0KDQpUaGF0IHNob3VsZCBiZSBkb2FibGUu IEFsdGhvdWdoIEknbSBub3Qgc3VyZSBpZiB0aGVp ...
Sep 29, 6:14 pm 2008
H. Peter Anvin
Re: Use CPUID to communicate with the hypervisor.
At least Parallels and Virtual PC/Virtual Server. -hpa --
Sep 29, 5:58 pm 2008
Alok Kataria
Re: Use CPUID to communicate with the hypervisor.
Hi Gerd, I really fail to see your point here. Maybe you can point out what am i missing. Think about the current situation, whenever there is migration to such a tsc-is-different system , how does the guest come to know about the frequency change, either through a $event or if it reboots it runs the calibration algorithm. How does asking the hypervisor for tsc instead of calibrating it, breaks the semantics for this migration. What special things does Xen do at migration, which would be ...
Sep 29, 5:33 pm 2008
H. Peter Anvin
Re: Use CPUID to communicate with the hypervisor.
OK, if so we should write up a formal proposal. -hpa --
Sep 29, 7:21 pm 2008
H. Peter Anvin
Re: Use CPUID to communicate with the hypervisor.
No, I don't think we are. Under the circumstances I do not think anything other than positive identification is unacceptable. If someone had the power to proclaim it by fatwa we wouldn't have much to worry about. Intel might have the power, but we as a group in this thread definitely do not. However, it is clear the virtualization industry doesn't have their act together to the point where one can rely on anything but positive identification, unlike in the hardware space, where ...
Sep 29, 5:33 pm 2008
Nakajima, Jun
RE: Use CPUID to communicate with the hypervisor.
. Jun Nakajima | Intel Open Source Technology Center
Sep 29, 5:56 pm 2008
Alok Kataria
Re: Use CPUID to communicate with the hypervisor.
Sure, some leaves have been defined already, but it's not too late to try to go the generic route for the remaining leaves. The longer we wait to come to a consensus on generic leaves, the more I don't agree that this solution makes any difference OTOH, it just complicates the situation. Here is why.... 1. This solution really bloats the kernel, below are few observations i) What happens if two ABI signature blocks define a cpuid leaf which have similar semantics, how does the kernel ...
Sep 29, 5:12 pm 2008
H. Peter Anvin
Re: Use CPUID to communicate with the hypervisor.
That's part of the problem -- it's not, and it can't be. It's about the hypervisor providing a specific service to its guest, and although we can explain how Linux would use this, there is going to be an expectation -- especially for Microsoft and Apple -- that other OSes would use the same interfaces (to the extent they care, obviously.) -hpa --
Sep 29, 8:48 pm 2008
Gerd Hoffmann
Re: Use CPUID to communicate with the hypervisor.
Well, that should be clearly defined, that is my point. When asking the hypervisor for the tsc instead of running a calibration loop, then we have a small bit of paravirtualization: The guest is aware that it runs on a hypervisor and just asks it directly. So while we are at it we can also define a way to communicate tsc freq changes between host and guest, so the cost of trap'n'emulate tsc reads can be avoided. Or we define "tsc is constant" and leave it to the hypervisor to make sure ...
Sep 30, 1:11 am 2008
Avi Kivity
Re: Use CPUID to communicate with the hypervisor.
Features that the guest needs to enable very early on, before ACPI is up. I don't think there are many of those. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. --
Sep 30, 2:16 am 2008
Nakajima, Jun
RE: Use CPUID to communicate with the hypervisor.
. Jun Nakajima | Intel Open Source Technology Center
Sep 29, 8:14 pm 2008
Zachary Amsden
Re: Use CPUID to communicate with the hypervisor.
Non-constant TSCs probably won't want to use CPUID based retreival, due to the extra trap it would require to read TSC frequency, it can't be done at every TSC read (or else, virtualizing TSC frequency has the same cost and you haven't won anything by making it dynamic). It's also not clean to issue interrupts to the guest telling it TSC frequency has changed because the guest may not notice the interrupt before making computations using the old value, and multiple rapid changes would Not ...
Sep 30, 9:42 am 2008
Arjan van de Ven
Re: [PATCH] pci: introduce users of ioremap_pcibar()
On Tue, 30 Sep 2008 23:24:50 -0600 I'm fine with pci_iomap_bar()... it meets my goals Would be nice if I'd be allowed to make it only work on MEM bars not IO bars (so that drivers don't accidentally end up calling this on an IO bar and then using readl() etc) -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org --
Sep 30, 3:30 pm 2008
Peter Zijlstra
Re: [PATCH 0/4] futex: get_user_pages_fast() for shared ...
Ah, right - its a NOP, that's why it didn't show up in testing. The thing is, I changed the semantics of get_futex_key() to return a key with reference taken. And then noticed I didn't take one in the private futex path, and failed to notice the ref ops are nops for private futexes. So yeah, the below patch is basically a NOP, but we might consider --
Sep 30, 4:16 am 2008
Ingo Molnar
Re: [PATCH 0/4] futex: get_user_pages_fast() for shared ...
great - i've added your Acked-by to the patches and have activated the tip/core/futexes branch for tip/auto-core-next linux-next integration. here are the commits: 42569c3: futex: fixup get_futex_key() for private futexes c2f9f20: futex: cleanup fshared 734b05b: futex: use fast_gup() 6127070: futex: reduce mmap_sem usage 38d47c1: futex: rely on get_user_pages() for shared futexes Thanks, Ingo --
Sep 30, 3:39 am 2008
Nick Piggin
Re: [PATCH 0/4] futex: get_user_pages_fast() for shared ...
Yeah, these all look pretty good. It's nice to get rid of mmap sem here. Which reminds me, we need to put a might_lock mmap_sem into get_user_pages_fast... But these patches look good to me (last time we discussed them I thought there was a race with page truncate, but it looks like you've closed that by holding page lock over the whole operation...) Nice work, Peter. BTW. what kinds of things use inter-process futexes as of now? --
Sep 30, 12:21 am 2008
Eric Dumazet
Re: [PATCH 0/4] futex: get_user_pages_fast() for shared ...
inter-process futexes are still used for pthread creation/join (aka clear_child_tid / CLONE_CHILD_CLEARTID) kernel/fork.c, functions mm_release() & sys_set_tid_address() I am not sure how it could be converted to private futexes, since Sorry I am lost... --
Sep 30, 3:55 am 2008
Ingo Molnar
Re: [PATCH 0/4] futex: get_user_pages_fast() for shared ...
applied to tip/core/futexes, thanks Peter! Ingo --
Sep 30, 3:39 am 2008
Nick Piggin
Re: [PATCH 0/4] futex: get_user_pages_fast() for shared ...
It is enough to guarantee enough to function normally I guess. Actually futex syscalls are interesting in that they logically perform 2 totally different operations and actually want 2 keys but it manages to mash them into one (the user address). They need a futex identifier, on which to wait/wake/etc. For anonymous futexes, this is basically an arbitrary number which is taken from the user address (but note that if that address is subsequently mremap()ed for example, then the futex ...
Sep 30, 3:42 am 2008
Peter Zijlstra
Re: [PATCH 0/4] futex: get_user_pages_fast() for shared ...
Just to be sure, I only hold the page lock over the get_futex_key() op, and drop it after getting a ref on the futex key. I then drop the futex key ref after the futex op is complete. This assumes the futex key ref is suffucient to guarantee whatever is needed - which is the point I'm still not quite sure about myself. The futex key ref was used between futex ops, with I assume the intent to ensure the futex backing stays valid. However, the key ref only takes a ref on either the inode ...
Sep 30, 1:51 am 2008
Jonathan Corbet
Re: [PATCH v10 Golden] Unified trace buffer
On Tue, 30 Sep 2008 00:00:11 -0400 (EDT) Perhaps I'm speaking out of turn, but I have to wonder: am I the only one who gets uncomfortable looking at these hacks to overload struct page? It seems fragile as all hell; woe to he who tries to make a change to struct page someday and has to track all of this stuff down. Are the savings gained by using struct page this way really worth the added complexity? jon --
Sep 30, 8:20 am 2008
Steven Rostedt
Re: [PATCH v10 Golden] Unified trace buffer
Of course we would not be declaring a "struct unsigned long" ;-) -- Steve --
Sep 30, 11:02 am 2008
Peter Zijlstra
Re: [PATCH v10 Golden] Unified trace buffer
Its not that complex IMHO, the thing that is ugly are those struct page overloads, what we could do is try and sanitize the regular struct page and pull all these things in. Because the only reason people are doing these overloads is because struct page in mm_types.h is becomming an unreadable mess. Trouble is, looking at it I see no easy way out, --
Sep 30, 8:54 am 2008
Peter Zijlstra
Re: [PATCH v10 Golden] Unified trace buffer
The problem with storing the page link information inside the page is that it doesnt transfer to another address space, so if you do indeed mmap these pages, then the link information is bogus. Of course, in such a situation you could ignore these headers, but somehow that doesn't sound too apealing. --
Sep 30, 10:49 am 2008
Steven Rostedt
Re: [PATCH v10 Golden] Unified trace buffer
Actually my resize does free the buffers and I did test this. I probably never ran the trace when testing the freeing which means those pointers could have luckily not have been changed. -- Steve --
Sep 29, 5:12 pm 2008
Steven Rostedt
Re: [PATCH v10 Golden] Unified trace buffer
No that's not what I'm proposing. I'm proposing to allocate a page_header structure for every page we alloc, and make a link list of them. In other words: struct ring_buffer_per_cpu { [...] struct list_head pages; [...] }; struct buffer_page { [...]; void *page; struct list_head list; [...]; }; In ring_buffer_allocate_cpu: struct buffer_page *bpage; struct unsigned long addr; [...] for every page() { bpage = kzalloc(sizeof(*bpage), ...
Sep 30, 10:56 am 2008
Mathieu Desnoyers
Re: [PATCH v10 Golden] Unified trace buffer
I also got some corruption of the offset field in the struct page I use. I think it might be related to the fact that I don't set the PG_private bit (slob does set it when the page is in its free pages list). However, given I'd like to pass the buffer pages to disk I/O and for network socket and still keep the ability to re-use it when the I/O has been performed, I wonder where I should put my struct list_head list; /* linked list of buf pages */ ...
Sep 29, 8:46 pm 2008
Mathieu Desnoyers
Re: [PATCH v10 Golden] Unified trace buffer
My guess is that you never free your buffers in your test cases. I don't know if it was expected; probably not if your code is built into the kernel. -- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 --
Sep 29, 5:03 pm 2008
Linus Torvalds
Re: [PATCH v10 Golden] Unified trace buffer
That's not the scary part. The scary part is that somebody may well want to access the trace buffer pages in complex ways. If you mmap them, for example, you can use VM_PFNMAP to make sure that nobody should ever look at the "struct page", but if you want to do things like direct-to-disk IO on the trace pages (either with splice() or with The "unreadable mess" has exactly the same issues, though: people need to realize that when you overload fields in the page structure, you can ...
Sep 30, 9:38 am 2008
Steven Rostedt
Re: [PATCH v10 Golden] Unified trace buffer
Hi Mathieu! Thanks! I must have been lucky some how not to trigger this :-/ I'll add an update patch for this. -- Steve --
Sep 29, 5:01 pm 2008
Steven Rostedt
Re: [PATCH v10 Golden] Unified trace buffer
Regardless, there's more info we want to store for each page than the list head. Especially when we start converting this to lockless. I rather get out of the overlaying of the page frames, its nice to save the space, but really scares the hell out of me. I can just imagine this blowing up if we redo the paging, and I dislike this transparent coupling between the tracer buffer and the pages. -- Steve --
Sep 30, 10:41 am 2008
Linus Torvalds
Re: [PATCH v10 Golden] Unified trace buffer
That might be the best option. Yes, doing it in the 'struct page' itself is obviously going to save us some memory over having specially allocated page headers, but it's not like we'd expect to have _that_ many of these, and having a separate structure is actually good in that it also would make it simpler/clearer when/if you want to add larger pages (or other non-page allocations) into the mix. For example, if somebody really wants bigger areas, they can allocate them with ...
Sep 30, 10:01 am 2008
Peter Zijlstra
Re: [PATCH v10 Golden] Unified trace buffer
The list_head in the page frame should be available regardless of splice() stuffs. --
Sep 30, 10:00 am 2008
Steven Rostedt
Re: [PATCH v10 Golden] Unified trace buffer
Actually, looking at the code, there is no reason I need to keep this in the frame buffer itself. I've also encapsulated the accesses to the incrementing of the pointers so it would be trivial to try other approaches. The problem we had with the big array struct is that we can want large buffers and to do that with pointers means we would need to either come up with a large allocator or use vmap. But I just realized that I could also just make a link list of page pointers and do ...
Sep 30, 9:48 am 2008
Steven Rostedt
Re: [PATCH v10 Golden] Unified trace buffer
Ah, I believe the disk IO uses the page frame. That might be a bit more difficult to pass the data to disk and still keep information on the page frame. -- Steve --
Sep 29, 9:00 pm 2008
Casey Schaufler
Re: SMACK netfilter smacklabel socket match
If you really want to be abusive you could replace the smack_access() function in security/smack/smack_access.c (of all places) with a no-op Smack will eventually bite you if you're not careful, but users of MAC systems wouldn't be surprised by that. I don't think it's crazy, I think it's a matter of using what's available in novel ways. Don't hesitate if there's anything I can do to be helpful. --
Sep 29, 8:29 pm 2008
Gilles Carry
Re: [BUG][PPC64] BUG in 2.6.26.5-rt9 causing Hang
Hi, I have access to Power6 and x86_64 boxes and so far I could only reproduce the bug on PPC64. The bug arised from 2.6.26.3-rt6 since sched-only-push-if-pushable.patch and sched-only-push-once-per-queue.patch. Whereas sbrk_mutex definetly shows up the problem, it also can occur randomly, sometimes during the boot period. At the beginning, I had system hangs or this (very similar to Chirag's and not necessarly in sbrk_mutex): cpu 0x3: Vector: 700 (Program Check) at ...
Sep 29, 11:47 pm 2008
Chirag Jog
Re: [BUG][PPC64] BUG in 2.6.26.5-rt9 causing Hang
Hi Gregory, This particular bug is not producible on the x86 boxes, i have access to. Only on ppc64. Please send the diagnostic patches across. I'll try them out! :) -- -Thanks,Chirag --
Sep 29, 9:43 pm 2008
Hidehiro Kawai
Re: [PATCH 1/2] coredump_filter: add hugepage dumping v3
Hi Kosaki-san, This should be: write 0x21 to the process's proc file. Except for this, it seems OK. Thanks. -- Hidehiro Kawai Hitachi, Systems Development Laboratory Linux Technology Center --
Sep 30, 5:17 am 2008
David Miller
Re: [PATCH] iucv: Fix mismerge again.
From: Heiko Carstens <heiko.carstens@de.ibm.com> Applied to net-2.6, thanks. --
Sep 30, 3:06 am 2008
H. Peter Anvin
Re: [PATCH 3/3] x86/iommu: use __GFP_ZERO instead of mem ...
Boot configurations, too, can be tested in automated setups, and there is benefit to being able to do that without compilation. However, what we'd need is a machine-readable description that one can select a configuration from. -hpa --
Sep 30, 1:53 pm 2008
Ingo Molnar
Re: [PATCH 3/3] x86/iommu: use __GFP_ZERO instead of mem ...
yes - but iommu=force is not randconfig covered, hence it never gets tested by -tip testing. So my suggestion was a really simple patch: a new Kconfig entry that makes iommu=force default. CONFIG_BOOTPARAM_IOMMU_FORCE=y would be the right name for it. (disabled all i'm suggesting is to please expose existing debug capabilities in the .config space, so that it can be tested in automated setups. Ingo --
Sep 30, 4:03 am 2008
Pavel Machek
Re: Thinkpad brightness keys kill X on 2.6.26.5
Yes, I had similar problems... for me it blanked screen on closing For me CONFIG_ACPI_VIDEO never really worked... -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --
Sep 30, 4:19 pm 2008
Cyrill Gorcunov
Re: [PATCH 7/7] x86: print out irq nr for msi/ht -v2
On Mon, Sep 29, 2008 at 11:57 PM, Grant Grundler Yes, the only acceptable solution is to buy one of these books - I've found one in a local online shop. So I have no rights to ask such a question neither I should. Actually it's a good example of _bad_ behaviour absolutely non- acceptable in LKML!!! My apologizes! --
Sep 29, 9:20 pm 2008
Tejun Heo
Re: bug report
Does the problem occur w/o ath5k? I don't really see how ata_piix can trigger the WARN_ON(). Thanks. -- tejun --
Sep 30, 4:47 am 2008
Serge E. Hallyn
Re: [TOMOYO #9 (2.6.27-rc7-mm1) 1/6] LSM adapter functions.
That's not reasonable, is it. The rule thus far has been 'DAC before MAC'. Question to all: do we insist on keeping it that way? If the answer is yes, then the security_path_hooks patch is inherently wrong. If the answer is no, then Kentaro doesn't need to resort to this ugliness to try and get may_delete() called before his MAC code, only to have may_delete() called a second time from the vfs_* functions. --
Sep 30, 8:45 am 2008
Stephen Smalley
Re: [TOMOYO #9 (2.6.27-rc7-mm1) 1/6] LSM adapter functions.
It isn't a hard rule; there are already some hooks that occur before the DAC checking, e.g. setattr, because the DAC checking happens in the fs code as part of the inode op. But when possible, we prefer DAC before MAC for SELinux so that we don't get noise in the audit logs from harmless application/library probing that would be denied by DAC anyway. Same issue would seemingly apply for learning modes of TOMOYO or -- Stephen Smalley National Security Agency --
Sep 30, 9:14 am 2008
Serge E. Hallyn
Re: [TOMOYO #9 (2.6.27-rc7-mm1) 1/6] LSM adapter functions.
Since SELinux won't be using the security_path hooks, it won't be affected by this, though, right? Though if we start down the path of mixing dac+mac with _path hooks then --
Sep 30, 9:23 am 2008
Larry Finger
Re: Logs being spammed with "Unable to enumerate USB device"
I now have more information. The if statement that triggers the message is as follows: if (hub->hdev->parent || !hcd->driver->port_handed_over || !(hcd->driver->port_handed_over)(hcd, port1)) For all the messages that I have captured, the first condition (hub->hdev->parent) is always true. For the isolated message that occurs at bootup, the second condition (!hcd->driver->port_handed_over) is true and the third is false. When the message storm occurs, the second condition is ...
Sep 30, 4:38 pm 2008
Eric Anholt
Re: [patch] mm: pageable memory allocator (for DRM-GEM?)
Hiding the details of shmem and the pagecache sounds pretty good to me (since we've got it wrong at least twice so far). Hopefully the result . I think the explanation for this got covered in other parts of the Yes, we definitely considered a filesystem (it would be nice for debugging to be able to look at object contents from a debugger process \easily). However, once we realized that fds just wouldn't work (we're allocating objects in a library, so we couldn't just dup2 them up ...
Sep 29, 6:10 pm 2008
Rafael J. Wysocki
Re: Wakeup from suspend via keyboard and mouse doesn't w ...
OK, thanks for testing. I'm going to submit the sky2 patch for merging too. Thanks, Rafael --
Sep 30, 1:09 pm 2008
Tino Keitel
Re: Wakeup from suspend via keyboard and mouse doesn't w ...
With this patch only, WOL is still broken. The machine doesn't wake up and the power/wakeup entry for the sky2 device stays at "disabled" after I enable WOL. With the WOL patch, power/wakeup changed to "enabled" after "ethtool -s eth0 wol g". Regards, Tino --
Sep 30, 12:53 pm 2008
Joerg Roedel
Re: [PATCH 6/9] x86/iommu: change Calgary to use dma_ops ...
Yes. I will change it. Joerg -- | AMD Saxony Limited Liability Company & Co. KG Operating | Wilschdorfer Landstr. 101, 01109 Dresden, Germany System | Register Court Dresden: HRA 4896 Research | General Partner authorized to represent: Center | AMD Saxony LLC (Wilmington, Delaware, US) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy --
Sep 30, 4:58 am 2008
Ingo Molnar
Re: [PATCH 6/9] x86/iommu: change Calgary to use dma_ops ...
we never do that for simple stuff like this. The kernel would be twice as large if we did. An oops is easy enough to decode and an oops does not come with a line number. Ingo --
Sep 30, 8:38 am 2008
Muli Ben-Yehuda
Re: [PATCH 6/9] x86/iommu: change Calgary to use dma_ops ...
I assume you are talking about the source size, because the generated code size should be exactly the same. In any case, arguing where to place the semi-colon is a waste of time. Do as you see fit. Cheers, Muli -- The First Workshop on I/O Virtualization (WIOV '08) Dec 2008, San Diego, CA, http://www.usenix.org/wiov08/ xxx SYSTOR 2009---The Israeli Experimental Systems Conference http://www.haifa.il.ibm.com/conferences/systor2009/ --
Sep 30, 11:33 am 2008
Muli Ben-Yehuda
Re: [PATCH 6/9] x86/iommu: change Calgary to use dma_ops ...
Sure, but I prefer the explicit form since it lends itself to easier debugging (oops line numbers, adding printks, etc.). Cheers, Muli -- The First Workshop on I/O Virtualization (WIOV '08) Dec 2008, San Diego, CA, http://www.usenix.org/wiov08/ xxx SYSTOR 2009---The Israeli Experimental Systems Conference http://www.haifa.il.ibm.com/conferences/systor2009/ --
Sep 30, 6:30 am 2008
Muli Ben-Yehuda
Re: [PATCH 9/9] x86/iommu: use dma_ops_list in get_dma_ops
It might be possible to have a per-device slow or fast path, where the fast path is for devices which have no DMA limitations (high-end It should be possible to reduce the number and overhead of hypercalls to the point where their cost is immaterial. I think that's fundamentally a better approach. Cheers, Muli -- The First Workshop on I/O Virtualization (WIOV '08) Dec 2008, San Diego, CA, http://www.usenix.org/wiov08/ xxx SYSTOR 2009---The Israeli Experimental ...
Sep 30, 12:44 pm 2008
Ingo Molnar Sep 30, 4:10 am 2008
Tom Mortensen
Re: exception Emask 0x0 SAct 0x1 / SErr 0x0 action 0x2 frozen
Don't know if this is the original poster's problem, but if the drive is spun down, then enabling SMART or trying to read SMART attributes causes the drive to spin up and the command is delayed until this has occurred. The fix is to increase the timeout given to scsi_execute() in drivers/ata/libata-scsi.c. ie, current code (2.6.26.5) is: /* Good values for timeout and retries? Values below from scsi_ioctl_send_command() for default case... */ cmd_result = ...
Sep 30, 1:47 pm 2008
Justin Piszcz
Re: exception Emask 0x0 SAct 0x1 / SErr 0x0 action 0x2 frozen
Velociraptor 10k drive here (2.6.26.5): Sep 30 15:55:06 p34 kernel: [420781.333179] ata6.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen Sep 30 15:55:06 p34 kernel: [420781.333189] ata6.00: cmd b0/d8:00:00:4f:c2/00:00:00:00:00/00 tag 0 Sep 30 15:55:06 p34 kernel: [420781.333190] res 40/00:ff:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Sep 30 15:55:06 p34 kernel: [420781.333194] ata6.00: status: { DRDY } Sep 30 15:55:06 p34 kernel: [420781.333200] ata6: hard ...
Sep 30, 2:18 pm 2008
Pavel Machek
Re: [Bug #11220] Screen stays black after resume
This is actually three problems in one :-(. If you try to suspend with minimum config, will resume still take 30 seconds? Is the problem still there in 2.6.27-rc7? Is there chance to bisect it? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --
Sep 30, 3:25 pm 2008
Ingo Molnar
Re: How how latent should non-preemptive scheduling be?
that's about 60 msecs. ath5k_intr IRQ handling overhead? IRQ handlers are non-preemptible. (even under CONFIG_PREEMPT=y) Ingo --
Sep 30, 4:22 am 2008
Sitsofe Wheeler
Re: How how latent should non-preemptive scheduling be?
What about the piece leading up to that: cat-7717 [000] 1392.752092: del_timer <-schedule_timeout cat-7717 [000] 1392.772263: account_scheduler_latency <-enqueue_task_fair cat-7717 [000] 1392.773224: __tasklet_schedule <-kbd_event cat-7717 [000] 1392.773225: schedule_console_callback <-kbd_event cat-7717 [000] 1392.773225: schedule_work <-schedule_console_callback cat-7717 [000] 1392.773226: ...
Sep 30, 6:18 am 2008
Chris Friesen
Re: unpredictability in scheduler test results -- still ...
It's either an ftrace bug or a fragile load balancer bug. I wonder if it's related somehow to the stop_machine() call in ftrace_dynamic_init()? Chris --
Sep 30, 2:14 pm 2008
Ingo Molnar
Re: unpredictability in scheduler test results -- still ...
ok, that would be a clear ftrace bug i guess? Ingo --
Sep 30, 4:12 am 2008
Frans Pop
Re: [patch 2/2] x86: Handle error returns in set_memory_*
I would be interested in this as well. As I mentioned before, I only tested with the first of the two patches (as you asked me to) and that solved the artifacts for me. What's the explanation behind that? What is the relationship between the first and second patch? Cheers, FJP --
Sep 30, 1:36 am 2008
Suresh Siddha
Re: [patch 2/2] x86: Handle error returns in set_memory_*
Frans, There is no relationship between the two patches. First patch (track memtype for RAM in page struct) will fix the behavior you observed and the second patch addresses some error conditions which were noticed by Venki. Both should have been pushed independently. thanks, suresh --
Sep 30, 2:29 pm 2008
Ingo Molnar Sep 30, 4:21 am 2008
Nick Piggin
Re: [patch 1/2] x86: track memtype for RAM in page struct - v3
I'd rather we didn't add any more uses of PageReserved without a really good reason. At this point in time (or at least last time I looked, a year or two ago), it isn't a whole lot of work to remove PG_reserved completely. If the waters get muddied up again, it could require another significant rework to remove it in future... Thanks, Nick --
Sep 30, 12:28 am 2008
Suresh Siddha
Re: [patch 1/2] x86: track memtype for RAM in page struct - v3
If a driver by mistake free's a RAM page before changing its memory attribute back to WB, we want the generic -mm to catch it. Today, free_pages_check() prevents freeing the page with PageReserved set. We want to use this and make sure that either set_page_uc/wc() or the driver calling these API's set the PageReserved bit. There are already some drivers which do SetPageReserved() before changing the attribute. I don't know the history behind PageReserved. But is there a recommended way to ...
Sep 30, 2:14 pm 2008
Oleksandr Natalenko Sep 30, 9:35 am 2008
Takashi Iwai
Re: REGRESSION: Sound's decreasing when headphones are plugged
At Sun, 14 Sep 2008 01:47:44 +0300, Thanks. I put the following simple fix to the next pull request. Takashi From 24918b61b55c21e09a3e07cd82e1b3a8154782dc Mon Sep 17 00:00:00 2001 From: Takashi Iwai <tiwai@suse.de> Date: Tue, 30 Sep 2008 12:58:54 +0200 Subject: [PATCH] ALSA: hda - Fix model for Dell Inspiron 1525 Dell Inspiron 1525 seems to have a buggy BIOS setup and screws up the recent codec parser, as reported by Oleksandr Natalenko: http://lkml.org/lkml/2008/9/12/203 This ...
Sep 30, 6:52 am 2008
Frank Mayhar
Re: [PATCH 2.6.27-rc5 incremental re-resubmit] Fix itime ...
You know, I just knew I had a brain around here _somewhere_. Weirdly, this didn't fall over on any of my testing. The gods know what it was actually doing, though. I'm picking up tip/master right now and will test your fix for this shortly. -- Frank Mayhar <fmayhar@google.com> Google, Inc. --
Sep 30, 9:36 am 2008
Ingo Molnar
Re: [PATCH 2.6.27-rc5 incremental re-resubmit] Fix itime ...
hmmm ... where do we get 'rq' from? in v3 you did this: - rq = task_rq_lock(p, &flags); which removed the deadlock but left us with a random uninitialized rq variable ... the right solution for the bug would have been to unlock it. Miraculously we didnt actually crash anywhere visibly, found it by reviewing the code. I thought this code gets excercised quite frequently. The commit below fixes it. Could you please functionality-test latest tip/master: ...
Sep 29, 11:33 pm 2008
Jan Beulich
[PATCH] checkpatch: Check for %L for all integer formats ...
I understand all of this, but can't see why you would care about floating point formats in the kernel (when specifically you know that vsnprintf() & Co aren't able to handle it anyway). So I think rather than widening the set of specifiers checkpatch looks for, the check should rather be removed altogether. Jan --
Sep 30, 8:32 am 2008
Geert Uytterhoeven
[PATCH] checkpatch: Check for %L for all integer formats ...
Why did you replace `%ll' by `%L'? While `L' is used as an internal flag in Linux' vsnprintf() implementation and is still supported because of historical (pre-C99) reasons, the `L' conversion qualifier is meant for the `long double' floating point type, as per C99. The recommended conversion qualifier for the `long long' integer type is `ll'. Perhaps checkpatch should check for this? Ah, it already does for some of the integer formats. The patch below adds checks for the missing ...
Sep 30, 4:29 am 2008
Andy Whitcroft
Re: [PATCH] checkpatch: Check for %L for all integer for ...
[...] Yes that looks entirly reasonable to me. Will queue it up with my next batch for Andrew. Thanks. -apw --
Sep 30, 6:14 am 2008
KOSAKI Motohiro
Re: [PATCH 12/13] hrtimer: create a "timer_slack" field ...
Hi Arjan, Sorry for _really_ late responce. I recently found this patch in linux-next. In general, I like this patch. I wonder to why PR_SET_TIMERSLACK decreasing doesn't need root privilege. example, nice() systemcall is - nice increasing (pirority decreasing) doesn't need root privilege. - nice decreasing (priority incriasing) need root privilege. So, I think time slack setting need similar one. Otherwise, non-privilege user can increase power consumpsion easily by ...
Sep 29, 10:16 pm 2008
Arjan van de Ven
Re: [PATCH 12/13] hrtimer: create a "timer_slack" field ...
On Tue, 30 Sep 2008 14:16:09 +0900 (JST) setting timerslack to 0 has no real negative effects on the system on the one hand, on the other hand, it'll be multimedia apps and games who want to do this. Requiring this type of app to be root doesn't sound like a good idea, especially since all you get by "cheating" is ... the exact behavior you ask for anyway. "Increased power consumption" isn't a root privilege, the app can consume much more power just by a "while (1);" loop for ...
Sep 30, 1:28 am 2008
KOSAKI Motohiro
Re: [PATCH 12/13] hrtimer: create a "timer_slack" field ...
Hi Arjan, Right. But I worry about an end user can't find a application which spent large power comsumption. Many laptop users think battery life is really really important. end user can find "while(1)" app easily by top command. but they can't find timerslack==0 app easily. So, I can drop my proposal. but I hope you explain your expected end user usages. --
Sep 30, 1:54 am 2008
Tejun Heo
Re: SATA Cold Boot problems on >2.6.25 with NV
Ah.. okay, so generic is not the only one affected by the original hardreset problem. Can you please post the result of "lspci -nn"? -- tejun --
Sep 30, 7:09 am 2008
Tejun Heo
Re: SATA Cold Boot problems on >2.6.25 with NV
Please apply the attached patch and see whether the problem goes away. Also, can you test whether hotplug works with the patch applied? CK804 had problems with hotplug w/ HRST removed. I wanna make sure nf2/3 doesn't have the same problem. Thanks. -- tejun
Sep 30, 9:47 am 2008
Konstantin Kletschke
Re: SATA Cold Boot problems on >2.6.25 with NV
00:00.0 Host bridge [0600]: nVidia Corporation nForce3 250Gb Host Bridge [10de:00e1] (rev a1) 00:01.0 ISA bridge [0601]: nVidia Corporation nForce3 250Gb LPC Bridge [10de:00e0] (rev a2) 00:01.1 SMBus [0c05]: nVidia Corporation nForce 250Gb PCI System Management [10de:00e4] (rev a1) 00:02.0 USB Controller [0c03]: nVidia Corporation CK8S USB Controller [10de:00e7] (rev a1) 00:02.1 USB Controller [0c03]: nVidia Corporation CK8S USB Controller [10de:00e7] (rev a1) 00:02.2 USB Controller [0c03]: ...
Sep 30, 8:16 am 2008
Konstantin Kletschke
Re: SATA Cold Boot problems on >2.6.25 with NV
Well, this Patch simply installs the old weird behaviour with the result in sometimes no cold boot possible yielding into ataX: link too slow to response ... ataX: COMRESET failed (errno=-16) After that powercycle required. I wrote it down from memory. If there is a detailed log required I can create them tomorrow when I have my Hands back onto the machine. Kind Regards, Konsti -- GPG KeyID EF62FCEF Fingerprint: 13C9 B16B 9844 EC15 CC2E A080 1E69 3FDA EF62 FCEF --
Sep 30, 1:12 am 2008
Ingo Molnar
Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmal ...
btw., are the resulting instructions also expected to be the same? If yes then you might want to verify it all by making sure the md5's of the .o's do not change. (If that's not possible (gcc decides to compile it a bit differently) then no big deal, just wanted to mention the possibility.) Ingo --
Sep 30, 4:04 am 2008
Mike Travis
Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmal ...
Well, not exactly... ;-) It does institute the new API change that specifies only pointers to cpumask's can be passed to functions and returned from functions. I really wanted the default cpumask_t to be a constant so those instances where the passed in cpumask is used as a read/write temp variable would be caught. But it started getting messy. One pain is: typedef struct __cpumask_s *cpumask_t; const cpumask_t xxx; is not the same as: typedef const struct __cpumask_s ...
Sep 30, 9:14 am 2008
Linus Torvalds
Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmal ...
Umm. The const has different One is typedef const struct __cpumask_s *const_cpumask_t; which becomes (const struct __cpumask_s) * while the other is const cpumask_t xxx which is const (struct __cpumask_s *) and if you look a bit more closely, you'll see that they are _obviously_ not the same thing at all. Quite frankly, I personally do hate typedefs that end up being pointers, and used as pointers, without showing that in the source code. When you ...
Sep 30, 9:46 am 2008
Mike Travis
[RFC 1/1] cpumask: New cpumask API - take 2 - use unsign ...
... Here's an alternate proposal for the new cpumask API. I have not yet begun the tedious work of making it compile so there may still be some syntax errors. (Init/main.c compiles.) But I believe it more closely adheres to proper 'C' coding styles. Thanks, Mike -- Subject: cpumask: Provide new cpumask API [Copied from Documentation/cpumask.txt] Introduction Cpumask variables are used to represent (with a single bit) all the CPU's in a system. With the prolific increase in the ...
Sep 30, 3:22 pm 2008
Mike Travis
Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmal ...
Thanks, yes that explains what I should have figured out. (Nice way to I agree, and as I mentioned, Rusty was working towards an alternative method of declaring cpumask's which does not hide this. My goal was to create an (apparent) opaque handle for cpumask_t and modify Perhaps then defining the cpumask as a list of unsigned longs (remove the outer struct) would play more "naturally". Lists by definition are always referenced by pointers. I have another version of the patchset that ...
Sep 30, 11:02 am 2008
Tejun Heo
Re: Another one for fixup-storage
Hello, Ah... thanks. I Robert's case is like that too and I don't think storage-fixup is the right place to deal with that. It seems we'll need something which is somewhat intelligent and more dynamic. I'll talk with Bruce whether we can do something about it using smartd. Thanks. -- tejun --
Sep 30, 10:38 am 2008
Tejun Heo
Re: Another one for fixup-storage
Just one more question. What do you mean by non-OEM? It didn't come with the listed harddrive? -- tejun --
Sep 30, 10:10 am 2008
Robert Krawitz
Re: Another one for fixup-storage
Date: Wed, 01 Oct 2008 02:10:05 +0900 From: Tejun Heo <tj@kernel.org> Robert Krawitz wrote: > This is for a Dell Inspiron E1705/9400. I'm using a non-OEM disk (a > Hitachi 320 GB drive). Just one more question. What do you mean by non-OEM? It didn't come with the listed harddrive? Correct. I purchased and installed the hard drive after I bought the laptop. Anyway, here's my smartctl output. My laptop was mostly fairly idle during these 2 10-minute periods, ...
Sep 30, 10:34 am 2008
Robert Krawitz
Re: Another one for fixup-storage
Date: Tue, 30 Sep 2008 23:16:24 +0900 From: Tejun Heo <tj@kernel.org> MIME-Version: 1.0 CC: linux-kernel@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Robert Krawitz wrote: > Date: Mon, 29 Sep 2008 16:22:51 +0900 > From: Tejun Heo <tj@kernel.org> > > Robert Krawitz wrote: > > This is for a Dell Inspiron E1705/9400. I'm using a non-OEM disk (a > > Hitachi 320 GB drive). > > > > Note that matching on "MP061" doesn't ...
Sep 30, 7:22 am 2008
Tejun Heo
Re: Another one for fixup-storage
Can you please measure it again and post the result? Thanks. -- tejun --
Sep 30, 9:57 am 2008
Tejun Heo Sep 30, 11:45 am 2008
Tejun Heo
Re: Another one for fixup-storage
Thanks. And how much does the load cycle count increase per hour without any adustment? -- tejun --
Sep 30, 7:16 am 2008
Daniel Lezcano
Re: [PATCH 00/30] Swap over NFS -v18
Oops, no. I was busy and I forgot, sorry. Let me review the sysctl vs namespace part. Thanks -- Daniel --
Sep 30, 8:46 am 2008
Peter Zijlstra
Re: [PATCH 00/30] Swap over NFS -v18
Daniel, have you ever found time to look at my namespace issues? --
Sep 30, 5:41 am 2008
Monty Montgomery
Re: [regression] CD-DA delay needed after insertion (htt ...
Fixed in SVN; pull a copy and try again. [Mein Gott, that bug was just embarrassing] Monty --
Sep 30, 5:51 am 2008
Matthew Wilcox
Re: [regression] CD-DA delay needed after insertion (htt ...
In this case, sg means scatter/gather, and it's a purely internal interface. It does not start/stop the drive, nor the scsi interface. -- Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." --
Sep 30, 10:41 am 2008
Monty Montgomery
Re: [regression] CD-DA delay needed after insertion (htt ...
Oh, good catch. Platform/drive combination that hadn't been tripped here. Fixing in SVN now. (you're on bigendian or using an old bigendian SCSI drive?) Monty --
Sep 30, 5:48 am 2008
Monty Montgomery
Re: [regression] CD-DA delay needed after insertion (htt ...
On Tue, Sep 30, 2008 at 11:21 AM, Geert Uytterhoeven why the calls to sg_start? Monty --
Sep 30, 10:32 am 2008
Geert Uytterhoeven
Re: [regression] CD-DA delay needed after insertion (htt ...
Hi Monty, Yep. This is on PS3, which is ppc64 (albeit most userland is ppc32). With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft Centre Europe The Corporate Village
Sep 30, 6:37 am 2008
Matthew Wilcox
Re: [regression] CD-DA delay needed after insertion (htt ...
That'll teach me to comment before reading the entire thread. Please ignore this mistaken explanation; I thought you were commenting on a patch, not on the commands used at the command line. -- Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." --
Sep 30, 10:45 am 2008
Geert Uytterhoeven
Re: [regression] CD-DA delay needed after insertion (htt ...
It happens on anything after 2.6.24 (cfr. http://bugzilla.kernel.org/show_bug.cgi?id=10974). The difficult part is who's to blame: Linux commit Which hard starting/stopping do you mean? Thanks! With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft Centre Europe The Corporate Village
Sep 30, 8:21 am 2008
Monty Montgomery
Re: [regression] CD-DA delay needed after insertion (htt ...
Ah. Geert, I'm sorry this has come up and thanks for bringing it to my attention. I'm relying on 15 year old behavior. It has always been the case that the packet pass-through interfaces treat O_NONBLOCK as 'don't wait for commands' (ie, classic async communication or, in the case of SGIO, don't block on mandatory locks) not 'change how you mediate the communication'. The whole point of the passthrough interface is 'please don't fuck with the packet stream. My userspace ...
Sep 30, 11:10 am 2008
Geert Uytterhoeven
Re: [regression] CD-DA delay needed after insertion (htt ...
Hi Monty, But the patch above doesn't help. Now cdparanoia crashes with a segmentation fault: | 0x0ffd5730 in cdda_read_timed () from /usr/lib/libcdda_interface.so.0 | (gdb) bt | #0 0x0ffd5730 in cdda_read_timed () from /usr/lib/libcdda_interface.so.0 | #1 0x0ffa7624 in i_read_c_block () from /usr/lib/libcdda_paranoia.so.0 | #2 0x0ffa9114 in paranoia_read_limited () from /usr/lib/libcdda_paranoia.so.0 | #3 0x10004da0 in ?? () | #4 0x0fd46704 in ?? () from /lib/libc.so.6 | #5 ...
Sep 30, 5:33 am 2008
Monty Montgomery
Re: [regression] CD-DA delay needed after insertion (htt ...
On Wed, Sep 17, 2008 at 11:05 AM, Geert Uytterhoeven O_NONBLOCK has nothing to do with the drive being ready. It means not to wait to open a device locked or in use exclusively by another process. It does not affect command processing (at least not the way cdparanoia is doing it). If a drive isn't ready, it returns a sense key of 'not ready' and the SGIO layer doesn't filter that in any way. SGIO itself never waits or takes any special action on 'not ready', it merely passes through the ...
Sep 30, 1:17 am 2008
Geert Uytterhoeven
Re: [regression] CD-DA delay needed after insertion (htt ...
With latest cdparanoia git-^H^H^H^Hsvn, the problem still happens. After applying the patch below, there's no more crash thanks to your last commit, and It Just Works(tm): eject; sg_start -i -l /dev/scd0; cdparanoia -d /dev/scd0 -Z -q 1-1[:1] /dev/null || echo failed diff --git a/interface/scan_devices.c b/interface/scan_devices.c index bfe5403..df08906 100644 --- a/interface/scan_devices.c +++ b/interface/scan_devices.c @@ -614,7 +614,7 @@ cdrom_drive *cdda_identify_scsi(const char ...
Sep 30, 7:51 am 2008
Monty Montgomery
Re: [regression] CD-DA delay needed after insertion (htt ...
Then I will be doing some headscratching over a copy of the kernel. Oh-- what *exact* kernel are you using? non-x86 trees don't always sync often with the 'official' mainline and I want to be sure I'm reading the correct thing. I was a longtime PPC user until about two years ago, and I'm used to there being several substantially different PPC kernel trees [just making sure]. OTOH, if the kernel isn't even servicing the device as a block device until the drive returns a ready status and ...
Sep 30, 8:07 am 2008
Serge E. Hallyn
Re: unprivileged mounts git tree
Rules according to permit_mount: if CAP_SYS_ADMIN, allowed if fs type is not marked safe for user mounts (and not bind), -EPERM if target is a link, -EPERM if target is labeled with new nosubmnt flag, -EPERM if target is not a user mount owned by current->uid, -EPERM You mean if we rm something, do the same thing we do for a lazy umount? That sounds reasonble, if the implementation is doable. And should The rename issue here being what you mentioned above about losing a --
Sep 30, 12:39 pm 2008
previous daytodaynext day
September 29, 2008September 30, 2008October 1, 2008