linux-kernel mailing list

FromSubjectsort iconDate
Ingo Molnar
Re: Patch [1/1] minor bugfix in 2.6.26/arch/x86/mm/pat.c ...
(hm, i dont find the original thread anywhere.) ... would add a crasher cache aliasing bug in case of CONFIG_NONPROMISC_DEVMEM=n (or CONFIG_PROMISC_DEVMEM). The idea behind this check is to add a second layer of checks to mmap()s - which is absolutely necessary in the case of PAT and not optional. If non-promisc /dev/mem is used then this check is not needed. (because the higher level API already restricts us) But this duplication is ugly and confusing - we should have just a ...
Jul 17, 3:39 pm 2008
Linus Torvalds
Re: Patch [1/1] minor bugfix in 2.6.26/arch/x86/mm/pat.c ...
The real bug is that we shouldn't have "double negatives", and certainly not negative config options. Making that "promiscuous /dev/mem" option a negated thing as a config option was bad. Ingo, over to you.. --
Jul 17, 10:27 am 2008
V.Radhakrishnan
Patch [1/1] minor bugfix in 2.6.26/arch/x86/mm/pat.c - c ...
FROM: V.Radhakrishnan <rk@atr-labs.com> Description: This is a 1-line bugfix ! The program linux-2.6.26/arch/x86/mm/pat.c has the following code #ifdef CONFIG_NONPROMISC_DEVMEM /* This check is done in drivers/char/mem.c in case of NONPROMISC_DEVMEM*/ static inline int range_is_allowed(unsigned long pfn, unsigned long size) { return 1; } #else { ... } The above #ifdef must be actually #ifndef and not #ifdef The bug does not allow a valid user (root) from accessing /dev/mem ...
Jul 17, 10:25 am 2008
Ben Dooks
GPIO: Add generic gpio_to_irq call.
Add gpio_to_irq() implementation allowing the gpio_chip registration to also specify an function to map GPIO offsets into IRQs. Signed-off-by: Ben Dooks <ben-linux@fluff.org> Index: linux-2.6.26-quilt3/drivers/gpio/gpiolib.c =================================================================== --- linux-2.6.26-quilt3.orig/drivers/gpio/gpiolib.c 2008-07-18 00:40:52.000000000 +0100 +++ linux-2.6.26-quilt3/drivers/gpio/gpiolib.c 2008-07-18 00:47:03.000000000 +0100 @@ -339,6 +339,36 @@ const char ...
Jul 17, 4:52 pm 2008
Ben Dooks
GPIO: Add generic gpio_to_irq call.
Add gpio_to_irq() implementation allowing the gpio_chip registration to also specify an function to map GPIO offsets into IRQs. Signed-off-by: Ben Dooks <ben-linux@fluff.org> Index: linux-2.6.26-quilt3/drivers/gpio/gpiolib.c =================================================================== --- linux-2.6.26-quilt3.orig/drivers/gpio/gpiolib.c 2008-07-18 00:40:52.000000000 +0100 +++ linux-2.6.26-quilt3/drivers/gpio/gpiolib.c 2008-07-18 00:47:03.000000000 +0100 @@ -339,6 +339,36 @@ const char ...
Jul 17, 4:50 pm 2008
Arjan van de Ven
[PATCH] modules: extend initcall_debug functionality to ...
From: Arjan van de Ven <arjan@linux.intel.com> Subject: [PATCH] modules: extend initcall_debug functionality to the module loader The kernel has this really nice facility where if you put "initcall_debug" on the kernel commandline, it'll print which function it's going to execute just before calling an initcall, and then after the call completes it will 1) print if it had an error code 2) checks for a few simple bugs (like leaving irqs off) and 3) print how long the init call took in ...
Jul 17, 4:21 pm 2008
Dan Williams
[git pull] async-tx/dmaengine update for 2.6.27
Linus, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/djbw/async_tx.git next to receive: Dan Williams (4): async_tx: fix async_memset compile error dmaengine: remove arch dependency from DMADEVICES dmaengine: track the number of clients using a channel dmaengine: add DMA_COMPL_SKIP_{SRC,DEST}_UNMAP flags to control dma unmap Haavard Skinnemoen (5): dmaengine: Couple DMA channels to their physical DMA device dmatest: Simple DMA ...
Jul 17, 4:21 pm 2008
Ingo Molnar
Re: empty smpcommon_32.c
thanks, zapped it. Ingo --
Jul 17, 4:23 pm 2008
Yinghai Lu
empty smpcommon_32.c
it is renamed to smpcommon.c but old one with one blank line still sit the tree. YH --
Jul 17, 4:18 pm 2008
Harvey Harrison
[PATCH] pci: proc.c sparse endian annotations
drivers/pci/proc.c:91:3: warning: cast from restricted __le16 drivers/pci/proc.c:100:3: warning: cast from restricted __le32 drivers/pci/proc.c:109:3: warning: cast from restricted __le16 drivers/pci/proc.c:161:40: warning: cast to restricted __le16 drivers/pci/proc.c:170:41: warning: cast to restricted __le32 drivers/pci/proc.c:179:40: warning: cast to restricted __le16 Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> --- Patch against next-20080717 drivers/pci/proc.c | 18 ...
Jul 17, 3:57 pm 2008
Jan Engelhardt
Re: ide-cd or ide-scsi dmesg contradiction
Right, neither. cdrecord dev=/dev/sr0 (or dev=/dev/hdc) whichever is appropriate is all one needs. I guess you can even use /dev/sg0. Care to send a patch? --
Jul 17, 4:23 pm 2008
Thomas Lucaw
ide-cd or ide-scsi dmesg contradiction
Hi, for some time I've noticed giving the cmdline (to kernel at boot) "hdd=ide-scsi ..." I get ide-scsi is deprecated for cd burning! Use ide-cd and give dev=/dev/hdX as device then changing to the suggested "hdd=ide-cd ..." I get ide_setup: hdc=ide-cd -- OBSOLETE OPTION, WILL BE REMOVED SOON! Rather illogical to me :-) I guess neither should be used, I can make my cdrom and dvd devices work without ok. kernel 2.6.26 Tom --
Jul 17, 3:11 pm 2008
Bernhard Walle
[PATCH] x86: Move crashkernel reservation before dma32_r ...
On a x86-64 machine (nothing special I could encounter) I had the problem that crashkernel reservation with the usual "64M@16M" failed. While debugging that, I encountered that dma32_reserve_bootmem() reserves a memory region which is in that area. Because dma32_reserve_bootmem() does not rely on a specific offset but crashkernel does, it makes sense to move the crashkernel reservation up a bit. I tested that patch and it works without problems. I don't see any negative effects of that move, ...
Jul 17, 3:15 pm 2008
Yinghai Lu
Re: [PATCH] x86: Move crashkernel reservation before dma ...
Joe Jin already had another one to move dma32_reserve_bootmem later YH --
Jul 17, 3:50 pm 2008
Justin Mattock
Re: 2.6.26-rc9-git9 doesn't boot on Macintel
when sending the post make sure you select reply toall this way all of the cc's are there.(just in case you didn't know) you're going to have to give me that address again, deleted all of my messages this morning without thinking about it. -- Justin P. Mattock --
Jul 17, 3:09 pm 2008
Bernhard Walle
kdump: Report actual value of VMCOREINFO_OSRELEASE in VM ...
The current implementation reports the structure name as VMCOREINFO_OSRELEASE in VMCOREINFO, e.g. VMCOREINFO_OSRELEASE=init_uts_ns.name.release That doesn't make sense because it's always the same. Instead, use the value, e.g. VMCOREINFO_OSRELEASE=2.6.26-rc3 That's also what the 'makedumpfile -g' does. Signed-off-by: Bernhard Walle <bwalle@suse.de> diff --git a/include/linux/kexec.h b/include/linux/kexec.h index 3265968..3c7784d 100644 --- ...
Jul 17, 3:07 pm 2008
Alastair Stevens
Re: From 2.4 to 2.6 to 2.7?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Forgive me if I missed it, but I've not seen any suggestions along the lines of this: how about just dropping the now-meaningless '.6' from the version string and retaining the rest. In other words: 2.27 2.27.1 ... 2.28 2.28.1 2.28.2 That way you continue the series in a meaningful way, whilst reverting to a neater 3-level numbering scheme again. Perhaps you could make 2.[6.]30 the switchover point.... Cheers AL - ...
Jul 17, 3:05 pm 2008
Lennart Sorensen
Re: From 2.4 to 2.6 to 2.7?
So what makes the 6 meaningless and the 2 meaningful and worth keeping? It does nothing for Linus's dislike of large numbers either. -- Len Sorensen --
Jul 17, 3:40 pm 2008
Harvey Harrison
[PATCH] mtd: diskonchip.c fix sparse endian warnings
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> --- Al, I know you won't like this for the same reasons as the dlm patch, but I had it already done. drivers/mtd/nand/diskonchip.c | 30 +++++++++++++++--------------- 1 files changed, 15 insertions(+), 15 deletions(-) diff --git a/drivers/mtd/nand/diskonchip.c b/drivers/mtd/nand/diskonchip.c index 765d4f0..e4226e0 100644 --- a/drivers/mtd/nand/diskonchip.c +++ b/drivers/mtd/nand/diskonchip.c @@ -1125,9 +1125,9 @@ static inline ...
Jul 17, 2:57 pm 2008
Ingo Molnar
Re: [bug, netconsole, SLUB] BUG skbuff_head_cache: Poiso ...
hm, but it was not reproducible on the third and fourth attempt :-( I tried hard to provoke it by generating artificial parallel network and netconsole output - but it didnt want to trigger. Heisenbug ... Maybe the debug output gives someone an idea about the nature of the bug? Ingo --
Jul 17, 3:43 pm 2008
Ingo Molnar
Re: [bug, netconsole, SLUB] BUG skbuff_head_cache: Poiso ...
that's ok - i've got some local qa helpers that have config options. Things like making SMP bootups more likely in randconfig, adding various boot parameters to the bootup via .config methods (so that boot parameters can be randomized via make randconfig), etc. these: CONFIG_BOOTPARAM_SUPPORT=y CONFIG_BOOTPARAM_NO_HZ_OFF=y CONFIG_BOOTPARAM_NMI_WATCHDOG_BIT_0=y CONFIG_BOOTPARAM_LAPIC=y CONFIG_BOOTPARAM_IDLE_MWAIT=y CONFIG_BOOTPARAM_NOPAT=y ...
Jul 17, 4:56 pm 2008
David Miller
Re: [bug, netconsole, SLUB] BUG skbuff_head_cache: Poiso ...
From: Ingo Molnar <mingo@elte.hu> This is very unlikely to be added by us networking folks, no networking merges have happened for the 2.6.27 merge window yet :-) --
Jul 17, 2:45 pm 2008
Vegard Nossum
Re: [bug, netconsole, SLUB] BUG skbuff_head_cache: Poiso ...
1. Notice the range. It's just a single byte. 2. Notice the value. It's just a ++. Probably a stray increment of a uint8_t somewhere on a freed object? The offset from the beginning of the object is 0xf658ae9c - 0xf658ae00 = 0x9c. How big is a struct sk_buff? Hm.. it is in fact quite big. Now what member has offset 0x9c? Seems to depend on your config. Is there any way you can figure it out, Ingo? I'll try it with your config too. Vegard -- "The animistic metaphor of the bug that ...
Jul 17, 4:15 pm 2008
Ingo Molnar
Re: [bug, netconsole, SLUB] BUG skbuff_head_cache: Poiso ...
and Cc:-ed SLUB folks. Could be a sleeper cell of bugs gone active ;-) Or could be SLUB (-debugging) breakage. Netconsole is pretty reliable on this box. (and the bootup continued just fine after this report) Just re-tried it, the bug is reliably repeatable. Will try a bisection run. Ingo --
Jul 17, 3:06 pm 2008
Ingo Molnar
Re: [bug, netconsole, SLUB] BUG skbuff_head_cache: Poiso ...
hmm ... your analysis gave me a wonderful albeit admittedly remote idea: If only we had some kernel technology that could track and validate memory accesses, and point out the cases where we access uninitialized memory, just like Valgrind? ... something like kmemcheck? ;-) So i booted that box with tip/master and kmemcheck enabled. (plus a few fixlets to make networking allocations be properly tracked by kmemcheck.) It was a slow bootup and long wait, but it gave a few hits ...
Jul 17, 4:52 pm 2008
Vegard Nossum
Re: [bug, netconsole, SLUB] BUG skbuff_head_cache: Poiso ...
It doesn't actually work. The config says # head: 088fcf34 and I checked out this from the tip tree. But kernel-config still complains about unknown config options... What went wrong? Vegard -- "The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's own creation." -- E. W. Dijkstra, EWD1036 --
Jul 17, 4:27 pm 2008
Vegard Nossum
Re: [bug, netconsole, SLUB] BUG skbuff_head_cache: Poiso ...
With your config: (gdb) p ((struct sk_buff *) 0)->truesize Cannot access memory at address 0x9c Now just audit users of ->truesize... There are quite a few. Which one would only += 1? Vegard PS: I might be on the completely wrong track. So far I only have bad experiences with this sk_buff... -- "The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's own ...
Jul 17, 4:35 pm 2008
David Miller
Re: [bug, netconsole, SLUB] BUG skbuff_head_cache: Poiso ...
From: Ingo Molnar <mingo@elte.hu> This bug would be a quite positive result then :) --
Jul 17, 3:09 pm 2008
Ingo Molnar
[bug, netconsole, SLUB] BUG skbuff_head_cache: Poison ov ...
A regression to v2.6.26: I started getting this skb-head corruption message today, on a T60 laptop with e1000: PM: Removing info for No Bus:vcs11 device: 'vcs11': device_create_release ============================================================================= BUG skbuff_head_cache: Poison overwritten ----------------------------------------------------------------------------- INFO: 0xf658ae9c-0xf658ae9c. First byte 0x6a instead of 0x6b INFO: Allocated in __alloc_skb+0x2c/0x110 ...
Jul 17, 2:42 pm 2008
Len Brown
Linux Power Management Mini-Summit -- Ottawa -- July 22, 2008
We'll be in The Rideau Suite in Les-Suites Tuesday July 22nd 8:30-18:30. Thanks to HP for sponsoring lunch at 12:30 as well as snacks at 10:00 and 15:30. We'll wing it for dinner. On linux-pm (sorry, on sabbatical I've been bad about keeping up on email) I've seen intent to attend from: Len Brown <len.brown@intel.com> Alan Stern <stern@rowland.harvard.edu> Dipankar Sarma <dipankar@in.ibm.com> Rafael J. Wysocki <rjw@sisk.pl> "Woodruff, Richard" <r-woodruff2@ti.com> Vaidyanathan ...
Jul 17, 2:27 pm 2008
Timur Tabi
[PATCH v2] fsl-diu-fb: Update Freescale DIU driver to us ...
Update the Freescale DIU driver to use page_alloc_exact() to allocate a DMA buffer. This also eliminates the rheap-based memory allocator. We can do this now because commit 6ccf61f9 allows us to allocate 8MB physically- contiguous memory blocks. Signed-off-by: Timur Tabi <timur@freescale.com> --- Fix printk format specifiers, per Andrew Morton. My other patch, "Add alloc_pages_exact() and free_pages_exact()", must be applied first, otherwise drivers/video/fsl-diu-fb.c will not ...
Jul 17, 2:25 pm 2008
Daniel Walker
[PATCH] sched: sched_rt.c unused struct rq warning fix
following warning, In file included from /localuser/dwalker/linus/kernel/sched.c:1675: /localuser/dwalker/linus/kernel/sched_rt.c: In function ‘inc_rt_tasks’: /localuser/dwalker/linus/kernel/sched_rt.c:508: warning: unused variable ‘rq’ looks to be caused by, commit 1100ac91b6af02d8639d518fad5b434b1bf44ed6 Author: Ingo Molnar <mingo@elte.hu> Date: Thu Jun 5 12:25:37 2008 +0200 sched: fix cpuprio build bug this patch was not built on !SMP: kernel/sched_rt.c: In ...
Jul 17, 1:37 pm 2008
Alexey Dobriyan
Re: *sigh* /proc/*/pagemap
Now that I unsuccessfully tried to reproduce multiplication wraparound (on 32-bit), integer wraparound in kmalloc() simply can't happen here. Relevant code from pagemap_read(): uaddr = (unsigned long)buf & PAGE_MASK; uend = (unsigned long)(buf + count); pagecount = (PAGE_ALIGN(uend) - uaddr) / PAGE_SIZE; pages = kmalloc(pagecount * sizeof(struct page *), GFP_KERNEL); pagecount is effectively "count / PAGE_SIZE", where "count" is size_t. kmalloc() takes size_t as first argument, so ...
Jul 17, 1:17 pm 2008
Harvey Harrison
[RESEND-PATCH] olpc: olpc_battery.c sparse endian annotations
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> --- David, akpm? drivers/power/olpc_battery.c | 20 ++++++++------------ 1 files changed, 8 insertions(+), 12 deletions(-) diff --git a/drivers/power/olpc_battery.c b/drivers/power/olpc_battery.c index 32570af..5fbca26 100644 --- a/drivers/power/olpc_battery.c +++ b/drivers/power/olpc_battery.c @@ -205,9 +205,9 @@ static int olpc_bat_get_property(struct power_supply *psy, union power_supply_propval *val) { int ret = ...
Jul 17, 1:19 pm 2008
Denys Vlasenko
[PATCH] (updated, rolled up) make section names compatib ...
Hi Andrew, Here is the update against current Linus tree, rolled up into one patch. James Bottomley suggested a different naming scheme: instead of swapping parts (.text.head -> .head.text), prepend .kernel to our special section names. This patch implements his idea. ppc and v850 are dropped per comments from arch people. parisc and x86 had minor fixes. x86 fix added proper executable bits to a section: -.section ".text.head" +.section ".kernel.text.head","ax",@progbits Does ...
Jul 17, 1:13 pm 2008
Matthew Wilcox
Re: PCI: MSI interrupts masked using prohibited method
Quite right. Somehow I managed to test and then send out an earlier version of this patch. Unfortunately, testing the right patch results in my machine locking up. The Intel System Programming Guide, volume 3A points out that x86 interrupts really do have priorities associated with them. And since EOI simply clears the highest priority bit, delaying calling ->ack() just isn't possible. I've also found some other distressing facts about LAPICs in the guide: If more than one ...
Jul 17, 12:48 pm 2008
Alan Cox
Re: Add UDF 2.60 support
On Thu, 17 Jul 2008 21:46:20 +0200 Send patches --
Jul 17, 12:19 pm 2008
Fred .
Add UDF 2.60 support
Recently released kernel 2.6.26 came with UDF 2.50 support. * http://en.wikipedia.org/wiki/Universal_Disk_Format We should get support for UDF 2.60. Please, add support for it! The Universal Disk Format (UDF) is a format specification of a file system for storing files on optical media. It is an implementation of the ISO/IEC 13346 standard. Revision 2.60 (March 1, 2005). Considering that 2.60 been out since 3 years ago, it is rather bad that we still don't support it. Also the 2.50 ...
Jul 17, 12:46 pm 2008
Andrew Morton
Re: [PATCH 1/1] signal: Introduce kill_pid_ns_info
On Thu, 17 Jul 2008 21:37:36 +0200 (CEST) but at least the tabs weren't replaced with spaces! Fix and resend, please. --
Jul 17, 2:10 pm 2008
Daniel Hokka Zakrisson
[PATCH 1/1] signal: Introduce kill_pid_ns_info
Author: Eric W. Biederman <ebiederm@xmission.com> Implement the basic helper function that walks all of the processes in a pid namespace and sends them all a signal. Both locations that could use this functions are also updated to use this function. I use find_ge_pid instead of for_each_process because it has a chance of not touching every process in the system. [daniel@hozac.com: Optimize away nr <= 1 check, against latest Linus tree] Signed-off-by: Eric W. Biederman ...
Jul 17, 12:37 pm 2008
Daniel Hokka Zakrisson
[PATCH] signal: Introduce kill_pid_ns_info
I'm sorry Andrew, this should look better. Author: Eric W. Biederman <ebiederm@xmission.com> Implement the basic helper function that walks all of the processes in a pid namespace and sends them all a signal. Both locations that could use this functions are also updated to use this function. I use find_ge_pid instead of for_each_process because it has a chance of not touching every process in the system. [daniel@hozac.com: Optimize away nr <= 1 check, against latest Linus ...
Jul 17, 2:54 pm 2008
David Newall
Crash: 2.6.25.10: writing to USB flash drive
Was copying files to a vfat filesystem on a usb flash drive from two shells (following http://www.pendrivelinux.com/2008/05/21/usb-xubuntu-804-persistent-install-from-linux/, but doing steps 16 & 18 concurrently) and got a kernel crash; alpha lock and scroll lock (?) flashing. Predictably, nothing in syslogs. Had a USB-attached hard drive plugged in as well as the flash drive, and after reboot they enumerate in opposite order (/dev/sdb <-> /dev/sdc), if that matters, which I expect it doesn't. ...
Jul 17, 12:26 pm 2008
Geert Uytterhoeven
[patch 10/29] zorro: use memory_read_from_buffer
From: akinobu.mita@gmail.com zorro: use memory_read_from_buffer Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> --- drivers/zorro/zorro-sysfs.c | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-) --- a/drivers/zorro/zorro-sysfs.c +++ b/drivers/zorro/zorro-sysfs.c @@ -15,6 +15,7 @@ #include <linux/zorro.h> #include <linux/stat.h> #include <linux/string.h> +#include <linux/fs.h> #include "zorro.h" ...
Jul 17, 12:16 pm 2008
Geert Uytterhoeven
[patch 11/29] amifb: Register Amiga-specific video modes ...
Register the Amiga-specific video modes with sysfs, so you can see them in /sys/class/graphics/fb0/modes and change the video mode by writing to /sys/class/graphics/fb0/mode. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> --- drivers/video/amifb.c | 3 +++ 1 file changed, 3 insertions(+) --- a/drivers/video/amifb.c +++ b/drivers/video/amifb.c @@ -2383,6 +2383,9 @@ default_chipset: goto amifb_error; } + fb_videomode_to_modelist(ami_modedb, NUM_TOTAL_MODES, + ...
Jul 17, 12:16 pm 2008
Geert Uytterhoeven
[patch 12/29] atafb: Register Atari-specific video modes ...
Register the Atari-specific video modes with sysfs, so you can see them in /sys/class/graphics/fb0/modes and change the video mode by writing to /sys/class/graphics/fb0/mode. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> --- drivers/video/atafb.c | 3 +++ 1 file changed, 3 insertions(+) --- a/drivers/video/atafb.c +++ b/drivers/video/atafb.c @@ -3230,6 +3230,9 @@ int __init atafb_init(void) return -EINVAL; } + fb_videomode_to_modelist(atafb_modedb, ...
Jul 17, 12:16 pm 2008
Geert Uytterhoeven
[patch 13/29] drivers/video/c2p.c: add MODULE_LICENSE
From: Adrian Bunk <bunk@kernel.org> This patch adds the missing MODULE_LICENSE("GPL"). Reported-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> --- drivers/video/c2p.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/video/c2p.c +++ b/drivers/video/c2p.c @@ -12,6 +12,7 @@ * for more details. */ +#include <linux/module.h> #include <linux/string.h> #include "c2p.h" @@ -227,3 ...
Jul 17, 12:16 pm 2008
Geert Uytterhoeven
[patch 03/29] m68k: Return -ENODEV if no device is found
From: Geert Uytterhoeven <geert@linux-m68k.org> According to the tests in do_initcalls(), the proper error code in case no device is found is -ENODEV, not -ENXIO or -EIO. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> --- drivers/block/ataflop.c | 4 ++-- drivers/char/nvram.c | 2 +- drivers/input/keyboard/atakbd.c | 2 +- drivers/video/atafb.c | 2 +- 4 files changed, 5 insertions(+), 5 deletions(-) --- a/drivers/block/ataflop.c +++ ...
Jul 17, 12:16 pm 2008
Geert Uytterhoeven
[patch 09/29] ZORRO: Replace deprecated __initcall with ...
From: Robert P. J. Day <rpjday@crashcourse.ca> ZORRO: Replace deprecated __initcall with equivalent device_initcall. Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> --- drivers/zorro/proc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/zorro/proc.c +++ b/drivers/zorro/proc.c @@ -158,4 +158,4 @@ static int __init zorro_proc_init(void) return 0; } ...
Jul 17, 12:16 pm 2008
Geert Uytterhoeven
[patch 14/29] export amiga_vblank
From: Adrian Bunk <bunk@kernel.org> This patch fixes the following build error: <-- snip --> .. Building modules, stage 2. MODPOST 1203 modules ERROR: "amiga_vblank" [drivers/video/amifb.ko] undefined! .. make[2]: *** [__modpost] Error 1 <-- snip --> Reported-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> --- arch/m68k/amiga/config.c | 2 ++ 1 file changed, 2 insertions(+) --- ...
Jul 17, 12:16 pm 2008
Geert Uytterhoeven
[patch 15/29] export c2p
From: Adrian Bunk <bunk@kernel.org> This patch fixes the following build error: <-- snip --> .. Building modules, stage 2. MODPOST 1203 modules ERROR: "c2p" [drivers/video/amifb.ko] undefined! .. make[2]: *** [__modpost] Error 1 <-- snip --> Reported-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> --- drivers/video/c2p.c | 1 + 1 file changed, 1 insertion(+) --- ...
Jul 17, 12:16 pm 2008
Geert Uytterhoeven
[patch 16/29] m68k/amiga/: possible cleanups
From: Adrian Bunk <bunk@kernel.org> This patch contains the following possible cleanups: - amiints.c: add a proper prototype for amiga_init_IRQ() in include/asm-m68k/amigaints.h - make the following needlessly global code static: - config.c: amiga_model - config.c: amiga_psfreq - config.c: amiga_serial_console_write() - #if 0 the following unused functions: - config.c: amiga_serial_puts() - config.c: amiga_serial_console_wait_key() - config.c: ...
Jul 17, 12:16 pm 2008
Geert Uytterhoeven
[patch 17/29] m68k/atari/debug.c: possible cleanups
From: Adrian Bunk <bunk@kernel.org> This patch contains the following possible cleanups: - make the following needlessly global functions (always) static: - atari_mfp_console_write() - atari_scc_console_write() - atari_midi_console_write() - atari_init_mfp_port() - atari_init_scc_port() - atari_init_midi_port() - #if 0 the following unused functions: - atari_mfp_console_wait_key() - atari_scc_console_wait_key() - atari_midi_console_wait_key() - remove the following ...
Jul 17, 12:16 pm 2008
Geert Uytterhoeven
[patch 25/29] m68k/Apollo: remove the unused APOLLO_ELPL ...
Looking at older kernel sources the APOLLO_ELPLUS option was added somewhere during kernel 2.1, but even kernel 2.2.0 does not contain any driver that would be enabled through it... Reported-by: Robert P. J. Day <rpjday@crashcourse.ca> Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> --- drivers/net/Kconfig | 9 --------- 1 file changed, 9 deletions(-) --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -333,15 +333,6 @@ config ...
Jul 17, 12:16 pm 2008
Geert Uytterhoeven
[patch 19/29] m68k/q40/config.c: make functions static
From: Adrian Bunk <bunk@kernel.org> This patch makes the following needlessly global functions static: - q40_reset() - q40_halt() - q40_disable_irqs() - q40_gettimeoffset() - q40_hwclk() - q40_get_ss() - q40_set_clock_mmss() Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> --- arch/m68k/q40/config.c | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) --- a/arch/m68k/q40/config.c +++ ...
Jul 17, 12:16 pm 2008
Geert Uytterhoeven
[patch 20/29] m68k/sun3/: possible cleanups
From: Adrian Bunk <bunk@kernel.org> This patch contains the following possible cleanups: - make the following needlessly global code static: - config.c: sun3_bootmem_alloc() - config.c: sun3_sched_init() - dvma.c: dvma_page() - idprom.c: struct Sun_Machines[] - mmu_emu.c: struct ctx_alloc[] - sun3dvma.c: iommu_use[] - sun3ints.c: led_pattern[] - remove the unused sbus.c Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Geert Uytterhoeven ...
Jul 17, 12:16 pm 2008
Geert Uytterhoeven
[patch 21/29] m68k: remove stale ARCH_SUN4 #define
From: Adrian Bunk <bunk@stusta.de> m68k: remove stale ARCH_SUN4 #define Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> --- include/asm-m68k/sbus.h | 2 -- 1 file changed, 2 deletions(-) --- a/include/asm-m68k/sbus.h +++ b/include/asm-m68k/sbus.h @@ -12,8 +12,6 @@ struct sbus_dev { } reg_addrs[1]; }; -#define ARCH_SUN4 0 - /* sbus IO functions stolen from include/asm-sparc/io.h for the serial driver */ /* No SBUS on ...
Jul 17, 12:16 pm 2008
Geert Uytterhoeven
[patch 22/29] m68k/apollo: Add missing call to apollo_pa ...
Add the missing call to apollo_parse_bootinfo(), which had been lost from a big Apollo support patch by Peter De Schrijver in 1999. Thanks to Adrian Bunk for noticing! Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> --- arch/m68k/kernel/setup.c | 3 +++ 1 file changed, 3 insertions(+) --- a/arch/m68k/kernel/setup.c +++ b/arch/m68k/kernel/setup.c @@ -122,6 +122,7 @@ extern int bvme6000_parse_bootinfo(const extern int mvme16x_parse_bootinfo(const struct bi_record *); extern ...
Jul 17, 12:16 pm 2008
Geert Uytterhoeven
[patch 24/29] m68k/Atari: remove the dead ATARI_SCC{,_DM ...
From: Adrian Bunk <bunk@kernel.org> It seems the driver was removed back in kernel 2.3 but the options were forgotten. Reported-by: Robert P. J. Day <rpjday@crashcourse.ca> Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> --- arch/m68k/Kconfig | 24 +----------------------- 1 file changed, 1 insertion(+), 23 deletions(-) --- a/arch/m68k/Kconfig +++ b/arch/m68k/Kconfig @@ -490,28 +490,6 @@ config ATARI_MFPSER Note for Falcon ...
Jul 17, 12:16 pm 2008
Geert Uytterhoeven
[patch 26/29] arch/m68k/mm/motorola.c: Eliminate NULL te ...
From: Julia Lawall <julia@diku.dk> As noted by Akinobu Mita in patch b1fceac2b9e04d278316b2faddf276015fc06e3b, alloc_bootmem and related functions never return NULL and always return a zeroed region of memory. Thus a NULL test or memset after calls to these functions is unnecessary. This was fixed using the following semantic patch. (http://www.emn.fr/x-info/coccinelle/) // <smpl> @@ expression E; statement S; @@ E = ...
Jul 17, 12:16 pm 2008
Geert Uytterhoeven
[patch 27/29] arch/m68k/mm/sun3mmu.c: Eliminate NULL tes ...
From: Julia Lawall <julia@diku.dk> As noted by Akinobu Mita in patch b1fceac2b9e04d278316b2faddf276015fc06e3b, alloc_bootmem and related functions never return NULL and always return a zeroed region of memory. Thus a NULL test or memset after calls to these functions is unnecessary. This was fixed using the following semantic patch. (http://www.emn.fr/x-info/coccinelle/) // <smpl> @@ expression E; statement S; @@ E = ...
Jul 17, 12:16 pm 2008
Geert Uytterhoeven
[patch 28/29] dio: use dio_match_device() in dio_bus_match()
From: Akinobu Mita <akinobu.mita@gmail.com> dio_bus_match() can use dio_match_device(). Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> --- drivers/dio/dio-driver.c | 14 +------------- 1 file changed, 1 insertion(+), 13 deletions(-) --- a/drivers/dio/dio-driver.c +++ b/drivers/dio/dio-driver.c @@ -119,19 +119,7 @@ static int dio_bus_match(struct device * if (!ids) return 0; - while (ids->id) { - if (ids->id == ...
Jul 17, 12:16 pm 2008
Geert Uytterhoeven
[patch 29/29] initrd: Fix virtual/physical mix-up in ove ...
From: Geert Uytterhoeven <geert@linux-m68k.org> On recent kernels, I get the following error when using an initrd: | initrd overwritten (0x00b78000 < 0x07668000) - disabling it. My Amiga 4000 has 12 MiB of RAM at physical address 0x07400000 (virtual 0x00000000). The initrd is located at the end of RAM: 0x00b78000 - 0x00c00000 (virtual). The overwrite test compares the (virtual) initrd location to the (physical) first available memory location, which fails. This patch converts ...
Jul 17, 12:16 pm 2008
Geert Uytterhoeven
[patch 23/29] m68k/Mac: remove the unused ADB_KEYBOARD option
From: Adrian Bunk <bunk@kernel.org> When the driver was removed back in 2002 the option was forgotten. Reported-by: Robert P. J. Day <rpjday@crashcourse.ca> Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> --- arch/m68k/Kconfig | 12 ------------ 1 file changed, 12 deletions(-) --- a/arch/m68k/Kconfig +++ b/arch/m68k/Kconfig @@ -578,18 +578,6 @@ config MAC_HID depends on INPUT_ADBHID default y -config ADB_KEYBOARD - bool ...
Jul 17, 12:16 pm 2008
Geert Uytterhoeven
[patch 18/29] m68k/mac/: possible cleanups
From: Adrian Bunk <bunk@kernel.org> This patch contains the following possible cleanups: - make the following needlessly global code (always) static: - baboon.c: struct baboon - baboon.c: baboon_irq() - config.c: mac_orig_videoaddr - config.c: mac_identify() - config.c: mac_report_hardware() - config.c: mac_debug_console_write() - config.c: mac_sccb_console_write() - config.c: mac_scca_console_write() - config.c: mac_init_scc_port() - oss.c: oss_irq() - oss.c: ...
Jul 17, 12:16 pm 2008
Geert Uytterhoeven
[patch 06/29] m68k: remove -traditional
From: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Subject: [patch 06/29] [RFC patch 4/9] Re: [PATCH] Stringify support commas > This is a no-no for those archs that still use -traditional. > > I dunno if this is a problem for you at the moment and the > > right fix is anyway to nuke -traditional. > > > > Sam Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> --- arch/m68k/fpsp040/Makefile | 1 - ...
Jul 17, 12:16 pm 2008
Geert Uytterhoeven
[patch 08/29] m68k: remove AP1000 code
From: Adrian Bunk <bunk@kernel.org> Unless I miss something that's code for a sparc machine even the sparc code no longer supports that got copied to m68k when these files were copied. Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> --- arch/m68k/sun3/prom/console.c | 4 ---- arch/m68k/sun3/prom/init.c | 9 --------- arch/m68k/sun3/prom/printf.c | 5 ----- include/asm-m68k/oplib.h | 1 - 4 files changed, 19 ...
Jul 17, 12:16 pm 2008
Geert Uytterhoeven
[patch 07/29] m68k: make multi_defconfig the default defconfig
From: Adrian Bunk <bunk@kernel.org> It seems to match the intention behind multi_defconfig to make it the default defconfig. Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> --- arch/m68k/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/m68k/Makefile +++ b/arch/m68k/Makefile @@ -13,7 +13,7 @@ # Copyright (C) 1994 by Hamish Macdonald # -KBUILD_DEFCONFIG := amiga_defconfig +KBUILD_DEFCONFIG := ...
Jul 17, 12:16 pm 2008
Geert Uytterhoeven
[patch 05/29] m68k: Allow no CPU/platform type for allnoconfig
From: Geert Uytterhoeven <geert@linux-m68k.org> Allow no CPU/platform type for allnoconfig - Provide a dummy value for FPSTATESIZE if no CPU type was selected - Provide a dummy value for NR_IRQS if no platform type was selected - Warn the user if no CPU or platform type was selected Note: you still cannot build an allnoconfig kernel, as CONFIG_SWAP=n doesn't build and we cannot easily fix ...
Jul 17, 12:16 pm 2008
Geert Uytterhoeven
[patch 04/29] m68k: vmlinux-std/sun3.lds.S cleanup - use ...
From: Cyrill Gorcunov <gorcunov@gmail.com> This patch includes page.h header into linker script that allow us to use PAGE_SIZE macro instead of numeric constant Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> --- arch/m68k/kernel/vmlinux-std.lds | 3 ++- arch/m68k/kernel/vmlinux-sun3.lds | 7 ++++--- 2 files changed, 6 insertions(+), 4 deletions(-) --- a/arch/m68k/kernel/vmlinux-std.lds +++ ...
Jul 17, 12:16 pm 2008
Jeff Garzik
Re: [patch 02/29] ariadne: use netstats in net_device st ...
Acked-by: Jeff Garzik <jgarzik@redhat.com> --
Jul 17, 12:45 pm 2008
Geert Uytterhoeven
[patch 02/29] ariadne: use netstats in net_device structure
From: Paulius Zaleckas <paulius.zaleckas@teltonika.lt> Use net_device_stats from net_device structure instead of local. Signed-off-by: Paulius Zaleckas <paulius.zaleckas@teltonika.lt> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> --- drivers/net/ariadne.c | 47 ++++++++++++++++++++++------------------------- 1 file changed, 22 insertions(+), 25 deletions(-) --- a/drivers/net/ariadne.c +++ b/drivers/net/ariadne.c @@ -98,7 +98,6 @@ struct ariadne_private { volatile ...
Jul 17, 12:16 pm 2008
Geert Uytterhoeven
[patch 01/29] m68k: remove CVS keywords
From: Adrian Bunk <bunk@kernel.org> This patch removes CVS keywords that weren't updated for a long time from comments. Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> --- arch/m68k/sun3/idprom.c | 2 +- arch/m68k/sun3/prom/Makefile | 1 - arch/m68k/sun3/prom/console.c | 2 +- arch/m68k/sun3/prom/init.c | 2 +- arch/m68k/sun3/prom/misc.c | 2 +- arch/m68k/sun3/prom/printf.c | 2 +- ...
Jul 17, 12:16 pm 2008
Geert Uytterhoeven
[patch 00/29] m68k patches for 2.6.27
Hi Linus, Andrew, Here are the m68k patches for 2.6.27: [01] m68k: remove CVS keywords [02] ariadne: use netstats in net_device structure [03] m68k: Return -ENODEV if no device is found [04] m68k: vmlinux-std/sun3.lds.S cleanup - use PAGE_SIZE macro [05] m68k: Allow no CPU/platform type for allnoconfig [06] m68k: remove -traditional [RFC patch 4/9] Re: [PATCH] Stringify support commas [07] m68k: make multi_defconfig the default defconfig [08] m68k: remove AP1000 code [09] ...
Jul 17, 12:16 pm 2008
Jeff Garzik
Re: Please add ZFS support (from GPL sources)
Linux needs btrfs upstream more than it needs ZFS... Jeff --
Jul 17, 12:45 pm 2008
Alan Cox
Re: Please add ZFS support (from GPL sources)
On Thu, 17 Jul 2008 21:13:55 +0200 No we can't. The GPL ZFS bits don't include the various methods that would violate the patent so there is no grant. I've several times asked Sun to simply give permission and they don't even answer. I can only read the Sun motiviation one way - they want to look open but know that ZFS is about the only thing that might save Solaris as a product in the data centre so are not truely prepared to let Linus use it. This is now further complicated by the fact Sun ...
Jul 17, 11:55 am 2008
H. Peter Anvin
Re: Please add ZFS support (from GPL sources)
From what I can see, it is an absolutely-minimal readonly implementation. -hpa --
Jul 17, 12:28 pm 2008
Alexey Dobriyan
Re: Please add ZFS support (from GPL sources)
And I have some sketches. Not yet ready to send anywhere. --
Jul 17, 12:30 pm 2008
Evgeniy Polyakov Jul 17, 1:18 pm 2008
Fred .
Please add ZFS support (from GPL sources)
Previously we have not been able to have ZFS support due to it being licensed under the CDDL and the kernel under the GPL. Sun have contributed ZFS support to GRUB under the GPL license. We could now use that code to implement support for ZFS in the Linux kernel. http://blogs.sun.com/darren/entry/zfs_under_gplv2_already_exists --
Jul 17, 12:13 pm 2008
Mihai
Re: Please add ZFS support (from GPL sources)
There are a number of fs drivers in the kernel which provide read-only support. The GPL-ed code might not be much (I haven't looked at it), but if someone would spend some time to write a nice, clean patch which can be easily improved, I think there would be at least one user out there who would find it useful. Of course, this could open a door for all kinds of incomplete drivers, but these days people seem nuts about ZFS. In second thoughts, maybe a fuse based driver would be better. ...
Jul 17, 3:33 pm 2008
Paul Fulghum
[PATCH] synclink_gt improve and simplify write method
Improve write method by allowing multiple HDLC frames to be loaded into tx DMA buffer ring for continuous frame transmission. This simplifies the transmit code by using the common procedures for all serial protocols. Signed-off-by: Paul Fulghum <paulkf@microgate.com> --- a/drivers/char/synclink_gt.c 2008-07-17 08:39:06.000000000 -0500 +++ b/drivers/char/synclink_gt.c 2008-07-17 12:44:09.000000000 -0500 @@ -857,6 +857,7 @@ static int write(struct tty_struct *tty, int ret = 0; struct ...
Jul 17, 10:58 am 2008
Vegard Nossum
latest -git: BUG at fs/jfs/namei.c:512 assert(ip->i_nlink)
Hi, I got this on latest -git with an intentionally corrupted filesystem image: BUG at fs/jfs/namei.c:512 assert(ip->i_nlink) ------------[ cut here ]------------ kernel BUG at fs/jfs/namei.c:512! invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC Pid: 4408, comm: rm Not tainted (2.6.26-03414-g33af79d #43) EIP: 0060:[<c02df988>] EFLAGS: 00210286 CPU: 1 EIP is at jfs_unlink+0x418/0x430 EAX: 00000031 EBX: 00000000 ECX: f2d16000 EDX: 00000000 ESI: 0000004c EDI: f43b12dc EBP: f2d17f20 ESP: ...
Jul 17, 11:35 am 2008
Dave Kleikamp
Re: latest -git: BUG at fs/jfs/namei.c:512 assert(ip->i_nlink)
This assert shouldn't be here. It would be better to handle this with jfs_error(), which will mark the superblock dirty, and take appropriate How about this one? So far, compile tested only. JFS: The kernel shouldn't trap when deleting a file with nlink == 0. Signed-off-by: Dave Kleikamp <shaggy@linux.vnet.ibm.com> diff --git a/fs/jfs/namei.c b/fs/jfs/namei.c index 2aba823..10340be 100644 --- a/fs/jfs/namei.c +++ b/fs/jfs/namei.c @@ -508,33 +508,35 @@ static int jfs_unlink(struct ...
Jul 17, 4:09 pm 2008
James Bottomley
Re: [RFC] systemtap: begin the process of using proper k ...
Basically because _stext is an incredibly dangerous symbol; being linker generated it doesn't actually get put in the right place if you look: jejb@sparkweed> nm vmlinux |egrep -w '_stext|_text' ffffffff80209000 T _stext ffffffff80200000 A _text Since we can't do negative offsets, you've lost access to the symbols in the sections that start before _stext. Assuming you meant _text (which is dangerous because it's a define in the kernel linker script and could change). Then you can't ...
Jul 17, 1:12 pm 2008
James Bottomley
Re: [RFC] systemtap: begin the process of using proper k ...
It's not exactly wasted ... the calculations have to be done anyway for Well, no, they're the head code. It's actually used in CPU boot and Dangerous as in it's not necessarily part of the kernel linker scripts. Some arches have it defined as a symbol, some have it as a linker script definition ... that's why it's location is strange. The point, really, is to remove some of the fragile dependencies between Then the definition needs altering. I can see that the industrial customers ...
Jul 17, 2:06 pm 2008
Masami Hiramatsu
Re: [RFC] systemtap: begin the process of using proper k ...
Hi Frank, I know we'd better archive that requirement. However, if we lose support from developers because we are too much focusing on that, we'll also lose the future of systemtap itself. We have to see the cost/benefit from the long-term of view. Could we separate systemtap parser/elaborator and code generator to support both of old and new kernels? Thank you, -- Masami Hiramatsu Software Engineer Hitachi Computer Products (America) Inc. Software Solutions Division e-mail: ...
Jul 17, 3:03 pm 2008
Frank Ch. Eigler
Re: [RFC] systemtap: begin the process of using proper k ...
Hi - Not really - we just anchor off a different (per-module) reference Fair enough - conceivably probing that stuff is useful, as is module initialization. We don't try to do it yet (and indeed kprobes blocks it all). In any case, the method of probe address calculation doesn't affect that issue. We can calculate .init* addresses relative to any Yes, that is generally desirable - each case is usually a question of cost/benefit. One significant requirement for us is to keep ...
Jul 17, 2:33 pm 2008
Frank Ch. Eigler
Re: [RFC] systemtap: begin the process of using proper k ...
Can you explain in detail how you believe this is materially different from offsetting from _stext? - FChE --
Jul 17, 11:30 am 2008
Frank Ch. Eigler
Re: [RFC] systemtap: begin the process of using proper k ...
Hi - Actually, "we" as in systemtap could do it just fine if that were desired. And really _stext is therefore an arbitrary choice - it could be any other reference. My point is that the proposed effort to identify a nearby function symbol to use as a base for each probe's symbol+offset calculation is What's between _text and _stext appears to consist of kernel boot-time functions that are unmapped the time anything like systemtap could By "dangerous" do you only mean that it may ...
Jul 17, 1:26 pm 2008
Jason mclaughlin Jul 17, 11:30 am 2008
Joe Perches
Re: [PATCH] crypto: Cleaning some more minor nits in prng
Perhaps more readable as: if (key) prng_key = key; else { prng_key = DEFAULT_PRNG_KEY; klen = DEFAULT_PRNG_KSZ; } --
Jul 17, 11:43 am 2008
Neil Horman
[PATCH] crypto: Cleaning some more minor nits in prng
Clean up a few more minor nits in the prng Now that we use a plain cipher instead of a blkcipher, we don't need an iv anymore, so remove that parameter from the reset_prng_context function. Make it instead with a legngth parameter, so that we can treat the key as a blob, rather than a string. Also change the get_prng_bytes function to make nbytes a size_t, so we don't have to worry about signed math there Signed-off-by: Neil Horman <nhorman@tuxdriver.com> prng.c | 11 ...
Jul 17, 11:30 am 2008
Marcin Obara
[PATCH] Intel Management Engine Interface
Fixed more issues raised on lkml after previous submission. The Intel Management Engine Interface (aka HECI: Host Embedded Controller Interface ) enables communication between the host OS and the Management Engine firmware. MEI is bi-directional, and either the host or Intel AMT firmware can initiate transactions. The core hardware architecture of Intel Active Management Technology (Intel AMT) is resident in firmware. The micro-controller within the chipset's graphics and memory controller ...
Jul 17, 11:27 am 2008
Paul Fulghum
[PATCH] synclink_gt improve TIOCOUTQ accuracy
Improve the accuracy of TIOCOUTQ value as implemented in chars_in_buffer() method by walking and counting tx DMA buffers, reading controller tx FIFO level and accounting for controller tx shift register. The greatly improves application control of transmit latency at lower data rates. Signed-off-by: Paul Fulghum <paulkf@microgate.com> --- a/drivers/char/synclink_gt.c 2008-07-17 08:39:06.000000000 -0500 +++ b/drivers/char/synclink_gt.c 2008-07-17 12:14:22.000000000 -0500 @@ -214,6 +214,7 @@ ...
Jul 17, 10:23 am 2008
David Brownell
[patch 2.6.26] rtc-cmos: improve HPET IRQ glue
From: David Brownell <dbrownell@users.sourceforge.net> Resolve bugzilla #11051 and other bugs related to the way the HPET glue code in rtc-cmos was incomplete and inconsistent: * Switch the approach so that the basic driver code flow isn't changed by having HPET ... instead, just have HPET shadow the RTC_CONTROL irq enables and RTC_FREQ_SELECT data. It's only coping with IRQ thievery, after all. * Do that consistently (!!) to avoid problems when the HPET code is out of ...
Jul 17, 10:43 am 2008
Michael Halcrow
[PATCH] eCryptfs: Make all persistent file opens delayed
There is no good reason to immediately open the lower file, and that can cause problems with files that the user does not intend to immediately open, such as device nodes. This patch removes the persistent file open from the interpose step and pushes that to the locations where eCryptfs really does need the lower persistent file, such as just before reading or writing the metadata stored in the lower file header. Two functions are jumping to out_dput when they should just be jumping to out ...
Jul 17, 11:16 am 2008
Vegard Nossum
latest -git: assertion !(n_file_size > ROUND_UP(n_new_fi ...
Hi, I just got this with an intentionally corrupted disk image: ReiserFS: loop0: found reiserfs format "3.6" with standard journal ReiserFS: loop0: warning: CONFIG_REISERFS_CHECK is set ON ReiserFS: loop0: warning: - it is slow mode for debugging. ReiserFS: loop0: using ordered data mode ReiserFS: loop0: journal params: device loop0, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 ReiserFS: loop0: checking transaction log ...
Jul 17, 11:14 am 2008
Paul Fulghum
[PATCH] synclink_gt add serial bit order control
Add control of hardware serial bit order between LSB first (default/standard) and MSB first. Signed-off-by: Paul Fulghum <paulkf@microgate.com> --- a/include/linux/synclink.h 2008-07-17 11:45:48.000000000 -0500 +++ b/include/linux/synclink.h 2008-07-17 11:46:52.000000000 -0500 @@ -136,6 +136,7 @@ #define MGSL_INTERFACE_RTS_EN 0x10 #define MGSL_INTERFACE_LL 0x20 #define MGSL_INTERFACE_RL 0x40 +#define MGSL_INTERFACE_MSB_FIRST 0x80 typedef struct _MGSL_PARAMS { --- ...
Jul 17, 9:54 am 2008
Joel Becker
Re: [Ocfs2-devel] [git patches] Ocfs2 and Configfs updat ...
I lied. I'll cleanup the fallout. You can revert it or wait for my revert + PTR_ERR. Let me know if you revert it. Joel -- "Against stupidity the Gods themselves contend in vain." - Friedrich von Schiller Joel Becker Principal Software Developer Oracle E-mail: joel.becker@oracle.com Phone: (650) 506-8127 --
Jul 17, 2:45 pm 2008
Joel Becker
Re: [Ocfs2-devel] [git patches] Ocfs2 and Configfs updat ...
Linus, Pull this to get the revert and the PTR_ERR() version: git://oss.oracle.com/git/jlbec/linux-2.6.git configfs-fixup-ptr-error It's tested with the same testing I did before - ocfs2 and netconsole. Joel -- "But all my words come back to me In shades of mediocrity. Like emptiness in harmony I need someone to comfort me." Joel Becker Principal Software Developer Oracle E-mail: joel.becker@oracle.com Phone: (650) 506-8127 --
Jul 17, 3:30 pm 2008
Linus Torvalds
Re: [git patches] Ocfs2 and Configfs updates for 2.6.27
.. I really dislike how this was done. This commit: 11c3b79218390a139f2d474ee1e983a672d5839a ("configfs: Allow ->make_item() and ->make_group() to return detailed errors.") is just ugly. Returning one value by passing a pointer to a pointer, and the error value by returning an 'int' errno is _not_ how we do things in the kernel. No, we use error pointers. IOW, you should have left the calling convention for "(*make_item)()" and "(*make_group)()" alone, but allowed people ...
Jul 17, 11:01 am 2008
Joel Becker
Re: [git patches] Ocfs2 and Configfs updates for 2.6.27
See, I coded it up with PTR_ERR() first, and everyone I showed I wish you hadn't, because it won't be to difficult to go back to PTR_ERR(). However, don't revert it - that affects some of the follow-on patches that were affected by the change. I'll spin up a new PTR_ERR() change. I have some more cleanups coming too, they need to finish their time in linux-next. Joel -- "The cynics are right nine times out of ten." - H. L. Mencken Joel Becker Principal Software ...
Jul 17, 2:20 pm 2008
Mark Fasheh
[git patches] Ocfs2 and Configfs updates for 2.6.27
These patches were sent out earlier this week for review. The only change I made since then was a small update to Coly's bugfix to remove some code which it obsoleted. Original message and revised diffstat follow: I'm running a bit late with the e-mail this time around, but I think that's ok since there really isn't any major new features here - the bulk of the Ocfs2 update is bug fixes, or cleanups. The same goes for configfs. The only two things that could be described as features would ...
Jul 17, 10:51 am 2008
Vegard Nossum
latest -git: kernel BUG at fs/xfs/support/debug.c:54!
Hi, I got this with an intentionally corrupted filesystem: Filesystem "loop1": Disabling barriers, not supported by the underlying device XFS mounting filesystem loop1 Ending clean XFS mount for filesystem: loop1 Device loop1 - bad inode magic/vsn daddr 9680 #30 (magic=4946) ------------[ cut here ]------------ kernel BUG at fs/xfs/support/debug.c:54! invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC Pid: 12849, comm: grep Not tainted (2.6.26-03414-g33af79d #43) EIP: 0060:[<c0386d89>] ...
Jul 17, 10:46 am 2008
Vegard Nossum
Re: latest -git: kernel BUG at fs/xfs/support/debug.c:54!
Thanks, you are right. I have adjusted my configuration, but I am still able to produce this: BUG: unable to handle kernel paging request at b62a66e0 IP: [<c030ef88>] xfs_alloc_fix_freelist+0x28/0x490 *pde = 00000000 Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC Pid: 4174, comm: rm Not tainted (2.6.26-03414-g33af79d #44) EIP: 0060:[<c030ef88>] EFLAGS: 00210296 CPU: 0 EIP is at xfs_alloc_fix_freelist+0x28/0x490 EAX: f63e8830 EBX: f490a000 ECX: f48e8000 EDX: b62a66e0 ESI: 00000000 EDI: ...
Jul 17, 12:18 pm 2008
Vegard Nossum
Re: latest -git: kernel BUG at fs/xfs/support/debug.c:54!
FWIW, this is fs/xfs/xfs_alloc.c:1817: if (!pag->pagf_init) { Vegard -- "The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's own creation." -- E. W. Dijkstra, EWD1036 --
Jul 17, 12:29 pm 2008
Eric Sandeen
Re: latest -git: kernel BUG at fs/xfs/support/debug.c:54!
running a debug XFS will turn all sorts of tests into panics that would not otherwise crash and burn that way. I think normally when testing intentionally corrupted filesystems, you expect corruptions to be handled gracefully. But in xfs's flavor of debug, I'm not sure it's quite as true. Perhaps the debug variant should not BUG() on disk corruption either, but it'd probably be more relevent to test this on a non-debug build. Does this corrupted fs survive better on non-debug ...
Jul 17, 12:05 pm 2008
Dave Chinner
Re: latest -git: kernel BUG at fs/xfs/support/debug.c:54!
Which kind of implies that we've got a bogus fsbno that we're using as the basis of allocation..... What is the corruption you are inducing? Can you produce a xfs_metadump image of the filesystem and put it up somewhere that we can access it? I suspect that we are not validating the block numbers coming out of the various btrees as landing inside the filesystem.... Cheers, Dave. -- Dave Chinner david@fromorbit.com --
Jul 17, 3:40 pm 2008
Dominik Brodowski
[git pull] PCMCIA bugfixes for 2.6.27
Linus, There are a few PCMCIA bugfixes for 2.6.27 available at git://git.kernel.org/pub/scm/linux/kernel/git/brodo/pcmcia-fixes-2.6/ Please pull from that location. The diffstat and list of changes follows, the individual diffs are sent (at least) to the linux-pcmcia list. Thanks, Dominik ---- drivers/char/pcmcia/cm4000_cs.c | 2 +- drivers/ide/legacy/ide-cs.c | 2 -- drivers/pcmcia/cistpl.c | 2 +- 3 files changed, 2 insertions(+), 4 ...
Jul 17, 10:42 am 2008
Paul Fulghum
[PATCH] synclink_gt add rx DMA buffer fill level control
Add run time control for receive DMA buffer fill level to allow application to control receive latency when using stream oriented serial protocols that pass receive data to application only after a DMA buffer fills. This was previously a compile time option, but run time control is needed when application changes data rate (and latency requirements) or uses different data rates on different ports. Signed-off-by: Paul Fulghum <paulkf@microgate.com> --- a/drivers/char/synclink_gt.c 2008-07-17 ...
Jul 17, 9:37 am 2008
Ingo Molnar
[git pull] x86 fixes
Linus, Please pull the latest x86 fixes git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git x86-fixes-for-linus Thanks, Ingo ------------------> Jack Steiner (1): x86: fix kernel_physical_mapping_init() for large x86 systems Rusty Russell (1): x86: fix asm/e820.h for userspace inclusion Yinghai Lu (1): x86: fix numaq_tsc_disable arch/x86/kernel/numaq_32.c | 2 +- arch/x86/mm/init_64.c | 2 +- ...
Jul 17, 10:32 am 2008
Ingo Molnar
[git pull] tracing fixes
Linus, Please pull the latest tracing fixes git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git tracing-fixes-for-linus Thanks, Ingo ------------------> Ingo Molnar (4): ftrace: fix merge buglet ftrace: fix lockup with MAXSMP ftrace: do not trace scheduler functions ftrace: do not trace library functions arch/x86/kernel/Makefile | 3 +-- kernel/Makefile | 3 +-- lib/Makefile | 14 ...
Jul 17, 10:32 am 2008
Loic Grenie
Typecast problems in SKFP driver
I've just compiled the 2.6.26-git5 kernel and the SKFP driver compilation produces complaints about typecasts. These complaints disappear with the following patch. Thanks, Lo
Jul 17, 10:31 am 2008
Loïc Grenié
Re: Typecast problems in SKFP driver
Indeed. I do not even understand why it was done that way in the I agree... Maybe someone with stronger guts than mine will have read about it and will correct it for some next release. Thanks once again, Loïc --
Jul 17, 1:03 pm 2008
Mikael Pettersson
Re: Typecast problems in SKFP driver
Loic Grenie writes: > I've just compiled the 2.6.26-git5 kernel and the SKFP driver > compilation produces complaints about typecasts. These complaints > disappear with the following patch. NAK, this needs to be done by someone with better understanding of C. > > Thanks, > > Loïc Grenié > diff --git a/drivers/net/skfp/ess.c b/drivers/net/skfp/ess.c > index 889f987..d3a8afc 100644 > --- a/drivers/net/skfp/ess.c > +++ b/drivers/net/skfp/ess.c > @@ ...
Jul 17, 11:38 am 2008
Frantisek Hanzlik
serverworks CSB5 IDE: DMA disabled on secondary channel
Server with Intel SHG2 board, servervorks CSB5 rev. 93: After upgrade from kernel 2.6.22 (IDE serverworks driver) to 2.6.25 (Fedora 9: libata+pata_serverworks driver), SW RAID1 performance is very bad. Problem is probably with secondary IDE channel, which has disabled DMA: # hdparm -Tt /dev/sda /dev/sda: Timing cached reads: 828 MB in 2.00 seconds = 414.26 MB/sec Timing buffered disk reads: 210 MB in 3.01 seconds = 69.83 MB/sec # hdparm -Tt /dev/sdb /dev/sdb: Timing cached ...
Jul 17, 10:12 am 2008
Alex Chiang
[PATCH] PCI: hotplug: fix error path in pci_slot's regis ...
Juha Leppänen noticed that an error path in register_slot() wasn't returning appropriately, leading to a condition where we might access a kfree'ed pointer, so let's fix that. Additionally, fix up the copyright information in the file while we're in there. Signed-off-by: Alex Chiang <achiang@hp.com> diff --git a/drivers/acpi/pci_slot.c b/drivers/acpi/pci_slot.c index b9ab030..dd376f7 100644 --- a/drivers/acpi/pci_slot.c +++ b/drivers/acpi/pci_slot.c @@ -6,8 +6,8 @@ * Thanks to Kenji ...
Jul 17, 10:13 am 2008
Bmw Online Promo
Congratulations!
Attn: We are please to inform You won the sum of £750,000.00 GBP and BMW 5 Series Car in our Seasonal E-mail Programme Award.Fill the details:Full Name,Country,Tel,Sex,Occupation Contact(bmw_claimsunit@btinternet.com)for claims Regards --
Jul 17, 10:03 am 2008
James Bottomley
Re: [PATCH] systemtap: fix up on_each_cpu() for kernels ...
By the way, this is a classic illustration of the fragility problem in holding the systemtap runtime outside of the kernel. If it had been in-kernel, all this would be fixed up and running and no-one would even have noticed. At least with changes in argument numbers, the compile breaks ... it would have been a lot nastier if one of the variables simply changed meaning ... James --
Jul 17, 9:53 am 2008
Stone, Joshua I
RE: [PATCH] systemtap: fix up on_each_cpu() for kernels ...
Believe it or not, we really do understand this sentiment. The whole runtime/time.c in particular is a fairly ugly way for us to get a call-anywhere gettimeofday. I would love to see an in-kernel replacement for this, but I don't have the expertise to know how to approach it myself. Josh --
Jul 17, 10:42 am 2008
Stone, Joshua I
RE: [PATCH] systemtap: fix up on_each_cpu() for kernels ...
On a closer look, the referenced commit wasn't actually merged until sometime between v2.6.26-git2 and -git3. The released v2.6.26 still has 'retry' in on_each_cpu(), so we'll either have to use an autoconf test to detect the change, or wait and key the #ifdef on 2.6.27. Josh --
Jul 17, 4:00 pm 2008
James Bottomley
[PATCH] systemtap: fix up on_each_cpu() for kernels 2.6.26+
In kernel 2.6.26, this patch commit 15c8b6c1aaaf1c4edd67e2f02e4d8e1bd1a51c0d Author: Jens Axboe <jens.axboe@oracle.com> Date: Fri May 9 09:39:44 2008 +0200 on_each_cpu(): kill unused 'retry' parameter means that runtime/time.c is now using the wrong calling conventions. Fix this up and surround it by kernel versioning #ifdefs. Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> --- runtime/time.c | 5 +++++ 1 files changed, 5 insertions(+), 0 ...
Jul 17, 9:51 am 2008
Linus Torvalds
Short update and pause in 2.6.27 merge window
This is just a quick note to let people know that I'll be off for an extended weekend starting later today, so the next few days will be very quiet from a merge standpoint. Feel free to send the merge requests, just don't get worried when I don't act on them ;) (There's also a few merge requests that I didn't act on yet just because I wanted to take a closer look - but if you're worried about it there is nothing wrong with re-sending it. I _do_ just drop requests in the bottomless ...
Jul 17, 9:47 am 2008
Takashi Iwai
[PATCH] fix build error of arch/ia64/kvm/*
Fix calls of smp_call_function*() in arch/ia64/kvm for recent API changes. CC [M] arch/ia64/kvm/kvm-ia64.o arch/ia64/kvm/kvm-ia64.c: In function 'handle_global_purge': arch/ia64/kvm/kvm-ia64.c:398: error: too many arguments to function 'smp_call_function_single' arch/ia64/kvm/kvm-ia64.c: In function 'kvm_vcpu_kick': arch/ia64/kvm/kvm-ia64.c:1696: error: too many arguments to function 'smp_call_function_single' Signed-off-by: Takashi Iwai <tiwai@suse.de> Acked-by Xiantao Zhang ...
Jul 17, 9:09 am 2008
Mathieu Desnoyers
[patch 1/4] kvm move VMCS Encodings to system headers
The VMCS Encodings will be needed by the kvm-trace probes. Put them in system-side headers instead of local header. Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> CC: 'Peter Zijlstra' <peterz@infradead.org> CC: 'Feng(Eric) Liu' <eric.e.liu@intel.com> CC: Avi Kivity <avi@qumranet.com> CC: kvm@vger.kernel.org --- arch/x86/kvm/vmx.h | 142 --------------------------------------------- include/asm-x86/kvm_host.h | 142 +++++++++++++++++++++++++++++++++++++++++++++ 2 ...
Jul 17, 8:57 am 2008
Mathieu Desnoyers
[patch 0/4] Port KVM-trace to tracepoints
Hi, Here is a port of KVM-trace, currently using macros on top of the Linux Markers, to tracepoints. Note that I cleaned up the instrumentation too, so stuff like KVMTRACE_3D(CR_WRITE, vcpu, (u32)cr, (u32)kvm_register_read(vcpu, reg), (u32)((u64)kvm_register_read(vcpu, reg) >> 32), handler); Sprinkled all across the KVM C code becomes : trace_kvm_cr_write(vcpu, cr, reg); Which looks much nicer, IMHO. It applies on top of linux-next ...
Jul 17, 8:57 am 2008
Mathieu Desnoyers
[patch 2/4] kvm move VMCS read to system headers
The VMCS read will be needed by the kvm-trace probes. Put them in static inline functions in system-side headers instead of in the C file. Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> CC: 'Peter Zijlstra' <peterz@infradead.org> CC: 'Feng(Eric) Liu' <eric.e.liu@intel.com> CC: Avi Kivity <avi@qumranet.com> CC: kvm@vger.kernel.org --- arch/x86/kvm/vmx.c | 28 ---------------------------- include/asm-x86/kvm_host.h | 30 ++++++++++++++++++++++++++++++ 2 files ...
Jul 17, 8:57 am 2008
Anthony Liguori
Re: [patch 4/4] KVM-trace port to tracepoints
Hi Mathieu, It's difficult to review your patches because they aren't inlined. At any rate, this patches are unusable with SVM. They try to execute VT Which lived in VT-specific code (vmx.c) Which lives in common code (kvm_trace.c). But vmcs_read32() is VT-specific and should not be used in common code so this motion is wrong. Why not just pass more arguments to probe_kvm_intr()? Then your first two patches can be dropped completely. Regards, Anthony Liguori Mathieu ...
Jul 17, 9:52 am 2008
Mathieu Desnoyers
Re: [patch 4/4] KVM-trace port to tracepoints
Yes, I just noticed that I made a small mistake : the probe code should actually go in arch/x86/kvm/kvm_trace_probes.c, which is x86-specific. The reason why I would try to move the vmcs_read32(VM_EXIT_INTR_INFO) to the probe code is because, unlike the Markers, when a function call with potential side-effects is put within the arguments, it's really an argument to a static inline function. In the markers, since it was a parameter passed to a macro, I could shuffle it into the branch and ...
Jul 17, 10:04 am 2008
Jan Kiszka
Re: [patch 4/4] KVM-trace port to tracepoints
Is it a specific property of KVM-trace that causes this LOC blow-up? Or is this a generic side-effect of tracepoints? [ Hmm, hope I didn't missed too much of the tracepoint discussion... ] Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux --
Jul 17, 9:49 am 2008
Mathieu Desnoyers
Re: [patch 4/4] KVM-trace port to tracepoints
This LOC blow-up is caused by the creation of one probe per instrumentation site. So instead of placing the argument setup of everything that goes in the trace (0 to 5 u32 arguments) in the kvm code, it can be placed separately in a probe object, which could eventually be a dynamically loadable module. The primary objective of tracepoints is to make sure the kernel code does not become harder to read because of added instrumentation and to provide type-checking at compile-time without needing ...
Jul 17, 10:28 am 2008
Mathieu Desnoyers
[patch 4/4] KVM-trace port to tracepoints
Port/cleanup of KVM-trace to tracepoints. Tracepoints allow dormat instrumentation, like the kernel markers, but also allows to describe the trace points in global headers so they can be easily managed. They also do not use format strings. Anything that would involve an action (dereference a pointer, vmcs read, ...) only required when tracing is placed in the probes created in kvm_trace.c This patch depends on the "Tracepoints" patch. Signed-off-by: Mathieu Desnoyers ...
Jul 17, 8:57 am 2008
Mathieu Desnoyers
[patch 3/4] KVM move register read-write to system headers
Needed by kvm_tracer probes, which are outside of arch/x86/kvm. Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> CC: 'Peter Zijlstra' <peterz@infradead.org> CC: 'Feng(Eric) Liu' <eric.e.liu@intel.com> CC: Avi Kivity <avi@qumranet.com> CC: kvm@vger.kernel.org --- arch/x86/kvm/kvm_cache_regs.h | 32 -------------------------------- arch/x86/kvm/lapic.c | 2 +- arch/x86/kvm/svm.c | 2 +- arch/x86/kvm/vmx.c | 2 +- ...
Jul 17, 8:57 am 2008
Heiko Carstens
[GIT PULL] more s390 updates for 2.6.27
Hi Linus, please pull from 'for-linus' branch of git://git390.osdl.marist.edu/pub/scm/linux-2.6.git for-linus Besides a couple of small bugfixes this contains our rewritten qdio driver. This should be the last large s390 patch for this merge window. Thanks. Adrian Bunk (1): [S390] chsc headers userspace cleanup Cornelia Huck (2): [S390] dasd: Fix cleanup in dasd_{fba,diag}_check_characteristics(). [S390] cio: Export chsc_error_from_response(). Frank Munzert ...
Jul 17, 8:55 am 2008
Atsushi Nemoto
[PATCH] Fix build on COMPAT platforms when CONFIG_EPOLL ...
Add missing cond_syscall() entry for compat_sys_epoll_pwait. Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp> --- diff --git a/kernel/sys_ni.c b/kernel/sys_ni.c index 5b9b467..0fea0ee 100644 --- a/kernel/sys_ni.c +++ b/kernel/sys_ni.c @@ -59,6 +59,7 @@ cond_syscall(sys_epoll_create); cond_syscall(sys_epoll_ctl); cond_syscall(sys_epoll_wait); cond_syscall(sys_epoll_pwait); +cond_syscall(compat_sys_epoll_pwait); cond_syscall(sys_semget); cond_syscall(sys_semop); ...
Jul 17, 8:31 am 2008
Alexey Dobriyan
Re: [PATCH] Fix build on COMPAT platforms when CONFIG_EP ...
IIRC, this happens for other syscalls as well. IIRC, timerfd ones. --
Jul 17, 2:29 pm 2008
Andrew Morton
Re: [PATCH] Fix build on COMPAT platforms when CONFIG_EP ...
On Fri, 18 Jul 2008 00:31:08 +0900 (JST) Interesting. It appears that both 2.6.25.x and 2.6.26.x need this fix as well. --
Jul 17, 2:23 pm 2008
Andrew Morton
Re: [PATCH] Fix build on COMPAT platforms when CONFIG_EP ...
On Fri, 18 Jul 2008 01:29:39 +0400 Well it _did_ do this. But I fixed about four such build errors. Please check? --
Jul 17, 2:42 pm 2008
Randy Dunlap
Re: linux-next: Tree for July 17 (net_namespace)
With PROC_FS=n, PROC_SYSCTL=n, SYSCTL_SYSCALL=n, the <sysctls> field of struct net in include/net/net_namespace.h has problems: In file included from /local/linsrc/linux-next-20080717/include/linux/init_task.h:12, from /local/linsrc/linux-next-20080717/kernel/pid.c:37: /local/linsrc/linux-next-20080717/include/net/net_namespace.h:40: error: field 'sysctls' has incomplete type In file included from /local/linsrc/linux-next-20080717/include/linux/netdevice.h:44, ...
Jul 17, 3:34 pm 2008
Rafael J. Wysocki
Re: linux-next: Tree for July 17: early crash on x86-64
This one crashes all of my x86-64 test boxes early during boot. The Linus' tree is not affected. Failing configs: http://www.sisk.pl/kernel/debug/next/20080717/HPC_nx6325-config http://www.sisk.pl/kernel/debug/next/20080717/M3A32-MVP-config It's not very likely that I'll be able to bisect this issue before OLS, so most probably I won't be testing linux-next in the next several days. Thanks, Rafael --
Jul 17, 4:06 pm 2008
Stephen Rothwell
linux-next: Tree for July 17
Hi all, Changes since next-20080716: Temporarily dropped tree: ttydev (it gets too many patch failures). Changed trees: the security-testing tree was moved later in the merge in anticipation of majo merge problems that have been delayed. The vfs tree changed branch names. Most of the differences were conflicts moving from tree to tree as some of the trees are now merged into Linus' tree. Most have been inflicted on the driver-core and usb trees. I have not notified these ...
Jul 17, 8:28 am 2008
Randy Dunlap
Re: linux-next: Tree for July 17 (sysctl/syscall)
Who is making patches to kernel/sysctl.c ? With CONFIG_SYSCTL=y # CONFIG_SYSCTL_SYSCALL is not set linux-next-20080717 produces: linux-next-20080717/kernel/sysctl.c:2970: error: redefinition of 'setup_sysctl_set' linux-next-20080717/kernel/sysctl.c:1963: error: previous definition of 'setup_sysctl_set' was here because one definition of it is bounded by CONFIG_SYSCTL and another definition of it is bounded by CONFIG_SYSCTL_SYSCALL... :( --- ~Randy Linux Plumbers Conference, ...
Jul 17, 3:21 pm 2008
Kyuma Ohta
[PATCH AVAIL.]ivtv:Crash 2.6.26 with KUROTOSIKOU CX2341 ...
Hi, I'm testing 2.6.26/amd64 with Athlon64 x2 Box with KUROTOSIKOU CX23416-STVLP,always crash ivtv driver when loading upd64083 driver. I checked crash dump,this issue cause of loading upd64083.ko with i2c_probed_new_device(). So,I fixed ivtv-i2c.c of 2.6.26 vanilla,and fixed *pretty* differnce memory allocation,structure of upd64083.c. I'm running patched 2.6.26 vanilla with below attached patches over 24hrs,and over 10hrs recording from ivtv, not happend anything;-) Please apply below to ...
Jul 17, 8:20 am 2008
Hans Verkuil
Re: [ivtv-devel] [PATCH AVAIL.]ivtv:Crash 2.6.26 with KU ...
Hi Ohta, Thanks for the patches. If I'm not mistaken there are several variants of this card: without upd* devices, only with upd64083 and with both upd devices. Which one do you have? Can you also show the dmesg output when ivtv loads? Looking at the four patches, I would say that the only relevant patch is the fix-probing patch. If you try it with only that one applied, does it still work correct for you? Note that this patch will not work with a KUROTOSIKOU card that has no upd* ...
Jul 17, 8:58 am 2008
Kyuma Ohta
Re: [ivtv-devel] [PATCH AVAIL.]ivtv:Crash 2.6.26 with KU ...
Dear Hans, Thanx for reply. I have a ivtv card with *both* upd64083 and upd64031a. I don't still try testing apply only one of patch,only apply all of... I attach compressed logs when loading ivtv at boottime, parallel probing saa7134 v4l2 device, both applied (successed) ,not applied (failed). Best regards, Ohta E-Mail: whatisthis.sowhat@gmail.com (Public) Home Page: http://d.hatena.ne.jp/artane/ (Sorry,not maintaining,and written in Japanese only...) Twitter: Artanejp ...
Jul 17, 4:13 pm 2008
Eric W. Biederman
Re: [PATCH 2/2] signals: replace p->pid == 1 check with ...
Sorry that was a half truth. Outside of the context of pid namespaces it is true. In the context of pid namespaces it is false because we haven't merged the patches to drop signals from inside the pid namespace on the way to init. So it is a check that _should_ be redundant. Eric --
Jul 17, 11:51 am 2008
Daniel Hokka Zakrisson
[PATCH 2/2] signals: replace p->pid == 1 check with a ch ...
p->pid == 1 is insufficient when there are multiple pid namespaces. Instead, check whether the task is in the current task's child reaper's thread group. Signed-off-by: Daniel Hokka Zakrisson <daniel@hozac.com> diff --git a/kernel/signal.c b/kernel/signal.c index 93713a5..be932b9 100644 --- a/kernel/signal.c +++ b/kernel/signal.c @@ -1142,10 +1142,20 @@ static int kill_something_info(int sig, struct siginfo *info, int pid) pid ? find_vpid(-pid) : task_pgrp(current)); } else { ...
Jul 17, 7:56 am 2008
Eric W. Biederman
Re: [PATCH 2/2] signals: replace p->pid == 1 check with ...
We should just drop the check for init as it is redundant. Eric --
Jul 17, 10:55 am 2008
Daniel Hokka Zakrisson
Re: [PATCH 2/2] signals: replace p->pid == 1 check with ...
I'm not sure what you mean? Without protecting init here, kill -s 9 -- -1 will kill it (i.e. the init in the pid namespace). E.g.: # vspace --new --pid --mount -- bash # bash -c 'kill -s 9 -- -1' -- Daniel Hokka Zakrisson --
Jul 17, 11:21 am 2008
Daniel Hokka Zakrisson
Re: [PATCH 1/2] signals: kill(-1) should only signal pro ...
ns is from current, and this is currently only called from See my response to Eric. I think that patch looks good... (Well, nr could -- Daniel Hokka Zakrisson --
Jul 17, 11:44 am 2008
Oleg Nesterov
Re: [PATCH 1/2] signals: kill(-1) should only signal pro ...
kill_something_info() can't walk threads, think about the realtime signals. Anyway, I think we should change kill_something_info(-1) to use rcu_read_lock() instead of tasklist. Oleg. --
Jul 17, 10:32 am 2008
Eric W. Biederman
Re: [PATCH 1/2] signals: kill(-1) should only signal pro ...
I knew I had done something like that. Sure let's revive the patch and send it. I don't know why it got lost the first time. Eric --
Jul 17, 11:45 am 2008
Eric W. Biederman
Re: [PATCH 1/2] signals: kill(-1) should only signal pro ...
walking threads is fine delivering signals to non thread group leaders is Being dense I think the locking implications of a correct implementation are more then we are ready to deal with to fix this bug. Although I remember discussing it and seeing something reasonable. Eric --
Jul 17, 10:50 am 2008
Pavel Emelyanov
Re: [PATCH 1/2] signals: kill(-1) should only signal pro ...
This is to be done, indeed, but I do not like the proposed implementation, since you have to walk all the tasks in the system (under tasklist_lock, by the way) to search for a couple of interesting ones. Better look at how zap_pid_ns_processes works (by the way - I saw some patch doing so some --
Jul 17, 8:01 am 2008
Daniel Hokka Zakrisson
Re: [PATCH 1/2] signals: kill(-1) should only signal pro ...
And yet nobody's fixed it... Kind of a critical thing, if you actually want to use them, since most distribution's rc-scripts do a kill(-1, SIGTERM), followed by kill(-1, SIGKILL) when halting (which, needless to The way zap_pid_ns_processes does it is worse, since it signals every thread in the namespace rather than every thread group. So either we walk the global tasklist, or we create a per-namespace one. Is that what we -- Daniel Hokka Zakrisson --
Jul 17, 8:24 am 2008
Daniel Hokka Zakrisson
[PATCH 1/2] signals: kill(-1) should only signal process ...
While moving Linux-VServer to using pid namespaces, I noticed that kill(-1) from inside a pid namespace is currently signalling every process in the entire system, including processes that are otherwise unreachable from the current process. This patch fixes it by making sure that only processes which are in the same pid namespace as current get signalled. Signed-off-by: Daniel Hokka Zakrisson <daniel@hozac.com> diff --git a/include/linux/pid_namespace.h ...
Jul 17, 7:55 am 2008
Eric W. Biederman
Re: [PATCH 1/2] signals: kill(-1) should only signal pro ...
Can you please introduce kill_pidns_info and have both kill_something_info and zap_pid_ns_processes call this common function? We want to walk the set of all pids in a pid namespace. /proc does this and it is the recommended idiom. If walking all of the pids in a pid namespace is not fast enough we can accelerate that. You are correct signalling every thread in a namespace is worse, in fact it is semantically incorrect. zap_pid_ns_processes gets away with it because it is sending ...
Jul 17, 10:45 am 2008
Daniel Hokka Zakrisson
Re: [PATCH 1/2] signals: kill(-1) should only signal pro ...
Looks like you've already done that. :-) (Referring to Sukadev's email.) -- Daniel Hokka Zakrisson --
Jul 17, 11:39 am 2008
Pavel Emelyanov
Re: [PATCH 1/2] signals: kill(-1) should only signal pro ...
It's questionable whether there are more "threads in a pid namespace" than "processes in a system". E.g. on my notebook there are ~110 processes and ~150 threads. So having this setup launched in 10 containers you'll have to walk 1100 tasks, while zap_pid_ns_processes only 150 ;) Some real-life example with containers: on one of our servers with 10 containers serving as git repo, bulding system and some other stuff there are ~200 process totally and ~20 threads in each container. ...
Jul 17, 8:54 am 2008
Eric W. Biederman Jul 17, 11:46 am 2008
sukadev
Re: [PATCH 1/2] signals: kill(-1) should only signal pro ...
Daniel Hokka Zakrisson [daniel@hozac.com] wrote: | While moving Linux-VServer to using pid namespaces, I noticed that | kill(-1) from inside a pid namespace is currently signalling every | process in the entire system, including processes that are otherwise | unreachable from the current process. | | This patch fixes it by making sure that only processes which are in | the same pid namespace as current get signalled. | | Signed-off-by: Daniel Hokka Zakrisson <daniel@hozac.com> | | diff ...
Jul 17, 11:13 am 2008
Paul Fulghum
[PATCH] synclink_gt leave transmitter in reset state aft ...
Leave the transmitter in reset state after configuration so that transmit signal is held at mark until transmitter is explicitly enabled by application, otherwise transmitter sends idle pattern. Signed-off-by: Paul Fulghum <paulkf@microgate.com> --- a/drivers/char/synclink_gt.c 2008-07-17 08:39:06.000000000 -0500 +++ b/drivers/char/synclink_gt.c 2008-07-17 09:05:24.000000000 -0500 @@ -4157,7 +4157,7 @@ static void sync_mode(struct slgt_info * * 01 enable * 00 auto-CTS ...
Jul 17, 7:14 am 2008
Paul Fulghum
[PATCH] make n_hdlc honor O_NONBLOCK on write
Make n_hdlc line discipline honor the O_NONBLOCK file flag on write. Signed-off-by: Paul Fulghum <paulkf@microgate.com> --- a/drivers/char/n_hdlc.c 2008-07-17 08:39:15.000000000 -0500 +++ b/drivers/char/n_hdlc.c 2008-07-17 08:43:58.000000000 -0500 @@ -677,6 +677,10 @@ static ssize_t n_hdlc_tty_write(struct t /* Allocate transmit buffer */ /* sleep until transmit buffer available */ while (!(tbuf = n_hdlc_buf_get(&n_hdlc->tx_free_buf_list))) { + if (file->f_flags & O_NONBLOCK) ...
Jul 17, 6:55 am 2008
Andy Chittenden
why doesn't /proc/self/maps mtime change when memory's a ...
Here's a ruby script that when run on 2.6.25 demonstrates that although the contents of /proc/self/maps changes, its mtime doesn't. --- start ruby script --- #!/usr/bin/ruby -w mapfile = "/proc/self/maps" oldmtime = File.stat(mapfile).mtime oldmaps = File.read(mapfile) arr = Array.new() for k in 1...10*1024*1024 arr.push(k) end newmaps = File.read(mapfile) newmtime = File.stat(mapfile).mtime if (oldmaps != newmaps) if (oldmtime == newmtime) puts("oldmaps ...
Jul 17, 7:36 am 2008
Pierre Ossman
Re: MMC: s3cmci: ensure host stopped on machine shutdown
On Thu, 17 Jul 2008 16:50:37 +0100 Ah, I see. Then it should be just fine. I'll have it queued up. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainer http://www.kernel.org rdesktop, core developer http://www.rdesktop.org WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption. --
Jul 17, 9:22 am 2008
Ben Dooks
Re: MMC: s3cmci: ensure host stopped on machine shutdown
It does depend on the previous patch to fix the section mismatch reports. -- Ben (ben@fluff.org, http://www.fluff.org/) 'a smiley only costs 4 bytes' --
Jul 17, 11:27 am 2008
Ben Dooks
Re: MMC: s3cmci: ensure host stopped on machine shutdown
I'm only removing the card-detect interrupt, the main host one is not being disabled here. -- Ben (ben@fluff.org, http://www.fluff.org/) 'a smiley only costs 4 bytes' --
Jul 17, 8:50 am 2008
Ben Dooks
MMC: s3cmci: ensure host stopped on machine shutdown
Ensure that the s3cmci host controller is turned off when the machine is shutdown, otherwise we end up leaving the card powered and processing insertion and removal events after the system prints "System halted." Signed-off-by: Ben Dooks <ben-linux@fluff.org> Index: linux-2.6.26-quilt3/drivers/mmc/host/s3cmci.c =================================================================== --- linux-2.6.26-quilt3.orig/drivers/mmc/host/s3cmci.c 2008-07-17 15:15:35.000000000 +0100 +++ ...
Jul 17, 7:32 am 2008
Pierre Ossman
Re: MMC: s3cmci: ensure host stopped on machine shutdown
On Thu, 17 Jul 2008 15:32:54 +0100 The core can send requests your way until mmc_remove_host() returns so you can't remove the interrupt before then. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainer http://www.kernel.org rdesktop, core developer http://www.rdesktop.org WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end ...
Jul 17, 8:29 am 2008
Stefano Stabellini
[PATCH] [RESEND] fbcon: simple text blinking implementation
Hi all, at the moment blinking is not supported in fbcon but it is supported in vgacon. Since userspace applications don't distinguish between the two, they just assume that the linux terminal is always capable of blinking text. However implementing blinking in fbcon is not so difficult: this patch provides a very simple (too simple?) implementation of that. I am using the flashcursor function to scan the buffer for blinking text. For the sake of efficiency I added a simple flag mechanism to ...
Jul 17, 6:50 am 2008
Geert Uytterhoeven
Re: [Linux-fbdev-devel] [PATCH] [RESEND] fbcon: simple t ...
Ehrm, there's already blinking support on some platforms? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds --
Jul 17, 11:50 am 2008
Haavard Skinnemoen
Re: [2.6 patch] fix avr32 build errors
On Thu, 17 Jul 2008 16:45:11 +0300 Applied, thanks a lot. Shame on me for not testing all defconfigs before submitting. Haavard --
Jul 17, 12:14 pm 2008
Adrian Bunk
[2.6 patch] fix avr32 build errors
Commit 7d2be0749a59096a334c94dc48f43294193cb8ed (atmel-mci: Driver for Atmel on-chip MMC controllers) causes build errors like: <-- snip --> ... CC arch/avr32/boards/atstk1000/atstk1003.o /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/avr32/boards/atstk1000/atstk1003.c: In function 'atstk1003_init': /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/avr32/boards/atstk1000/atstk1003.c:157: error: too few arguments to function 'at32_add_device_mci' make[2]: *** ...
Jul 17, 6:45 am 2008
Octavian Purdila Jul 17, 6:33 am 2008
Octavian Purdila
Re: [PATCH] tcp: do not promote SPLICE_F_NONBLOCK to soc ...
I am probably missing some usecases here, but usually if you want to use non-blocking I/O you need to use special approach anyway (e.g. code the I don't know... the man page explicitly says that even when you use SPLICE_F_NONBLOCK splice may block because of the underlying fd blocking. But more importantly, how can we solve the deadlock issue described in the patch? Do we need all of the complications of async I/O for such a simple and common usecase? Maybe we can solve both usecases ...
Jul 17, 7:47 am 2008
Evgeniy Polyakov
Re: [PATCH] tcp: do not promote SPLICE_F_NONBLOCK to soc ...
Hi Octavian. Existing behaviour was selected to be able to have a progress if socket does not have enough data to fill the pipe. With your change if socket is not opened with non-blocking mode reading will block not matter if SPLICE_F_NONBLOCK is set or not. This is a quite serious break of the overall idea behind SPLICE_F_NONBLOCK. Socket will not be marked as non-blocking if SPLICE_F_NONBLOCK is specified, only splicing will used non-blocking reading, any read via recv() will use ...
Jul 17, 7:21 am 2008
Evgeniy Polyakov
Re: [PATCH] tcp: do not promote SPLICE_F_NONBLOCK to soc ...
It depends. Splice clearly states that it tries to be nonblocking with I'm not sure I understand how it can deadlock, please explain it in more details. -- Evgeniy Polyakov --
Jul 17, 10:41 am 2008
Octavian Purdila
Re: [PATCH] tcp: do not promote SPLICE_F_NONBLOCK to soc ...
You lost me here :) The way I interpret the man page text is that it is ok for splice to block, even if SPLICE_F_NONBLOCK is set. The comments near SPLICE_F_NONBLOCK says the same thing: #define SPLICE_F_NONBLOCK (0x02) /* don't block on the pipe splicing (but */ /* we may still block on the fd we splice */ /* from/to, of course */ For this "program": x=splice(socket, pipe, size, flags=0); if (x > 0) splice(pipe, ...
Jul 17, 2:52 pm 2008
Zdenek Kabelac
Testing tracer wakeup warning
I've updated git tree to commit 33af79d12e0fa25545d49e86afc67ea8ad5f2f40 (and using two extra patches - for led_trigger & poweroff issue) I wanted to test the new sysprof feature - It looks like the machine is rebooting after memory suspend/resume (if I'll get a trace I'll make a new post) - selinux=off doesn't work anymore - had to use selinux=0 - I've got this Warning from the boot (attached configuration file) Linux version 2.6.26 (kabi@dhcp-lab-220.englab.brq.redhat.com) ...
Jul 17, 6:32 am 2008
Steven Whitehouse
[RFC] parser: add const to parser token table
Hi, Any objections to the following patch? If not I'll send it on to Linus. This patch adds a "const" to the parser token table. I've done an allmodconfig build to see if this produces any warnings/failures and the patch includes a fix for the only warning that was produced. Signed-off-by: Steven Whitehouse <swhiteho@redhat.com> Cc: Alexander Viro <aviro@redhat.com> Cc: Evgeniy Dushistov <dushistov@mail.ru> diff --git a/fs/ufs/super.c b/fs/ufs/super.c index 85b22b5..506f724 ...
Jul 17, 6:22 am 2008
Josef Bacik
Re: ext3 on latest -git: BUG: unable to handle kernel NU ...
Ok, this should do it then. Thanks, Josef Index: linux-2.6/fs/ext3/inode.c =================================================================== --- linux-2.6.orig/fs/ext3/inode.c +++ linux-2.6/fs/ext3/inode.c @@ -2023,13 +2023,27 @@ static void ext3_clear_blocks(handle_t * unsigned long count, __le32 *first, __le32 *last) { __le32 *p; + int ret; + if (try_to_extend_transaction(handle, inode)) { if (bh) { BUFFER_TRACE(bh, "call ...
Jul 17, 7:13 am 2008
Josef Bacik
Re: ext3 on latest -git: BUG: unable to handle kernel NU ...
Yeah thats a hard to answer question, one that I will leave up to others who have been doing this much longer than I. My thought is remount-ro is there to keep you from crashing, so if you have errors=continue then you expect to live with the consequences. Course if that bit gets flipped via corruption thats not good either. Thanks, Josef --
Jul 17, 7:43 am 2008
Vegard Nossum
Re: ext3 on latest -git: BUG: unable to handle kernel NU ...
Ahh, that probably explains it. I didn't realize there was such a thing. I am doing random-corruption tests, so it is quite possible that this bit gets set anywhere along the road... But even so, is it correct that the kernel should crash? It seems quite possible that error behaviour can change (like this) even with "normal" corruption, e.g. outside my test scripts. But I cannot even run dumpe2fs on my image (even with -f switch): dumpe2fs: Bad magic number in super-block while trying ...
Jul 17, 8:00 am 2008
Vegard Nossum
Re: ext3 on latest -git: BUG: unable to handle kernel NU ...
Oh, just 2M. It doesn't contain anything but copies of /bin/bash. I basically just made a crash-tester script that corrupts a dummy filesystem on purpose. But it seems that it might be partly my own fault for not protecting the bits in the filesystem image that say "oh, proceed on error". But I do have a feeling that the filesystem should not be able to say this in the first place. Because those bits can be corrupted legitimately in other ways ...
Jul 17, 8:16 am 2008
Josef Bacik
Re: ext3 on latest -git: BUG: unable to handle kernel NU ...
Thanks for the report, do you happen to have any messages above the panic message that would indicate if there was some sort of fs error that was hit before the panic? That would help me figure out what exactly happened. Thanks, Josef --
Jul 17, 6:13 am 2008
Theodore Tso
Re: ext3 on latest -git: BUG: unable to handle kernel NU ...
Yep: tune2fs -e remount-ro /dev/XXXX I should probably make the default configurable, and not "continue".... - Ted --
Jul 17, 8:40 am 2008
Josef Bacik
Re: ext3 on latest -git: BUG: unable to handle kernel NU ...
Ok run dumpe2fs -h on your image and see if you have a line that says Errors behavior: Continue if you do run tune2fs -e remount-ro and then do the mount. That would explain why you are still having panics even though we should be aborting the journal. Thanks, Josef --
Jul 17, 7:33 am 2008
Josef Bacik
Re: ext3 on latest -git: BUG: unable to handle kernel NU ...
Well this is really odd, after that we call ext3_std_error which calls journal_abort, so when we come into journal_dirty_metadata is_handle_aborted() should have returned 1 and we should have just exited. I'm going to have to think on this for a bit. Josef --
Jul 17, 6:40 am 2008
Josef Bacik
Re: ext3 on latest -git: BUG: unable to handle kernel NU ...
Hmm well the journal should have aborted, but it looks like it didn't, are you mounting with errors=continue by any chance? Thanks much, Josef --
Jul 17, 6:34 am 2008
Vegard Nossum
Re: ext3 on latest -git: BUG: unable to handle kernel NU ...
Nope, seems to be the same problem: kjournald starting. Commit interval 5 seconds EXT3-fs warning: mounting fs with errors, running e2fsck is recommended EXT3 FS on loop0, internal journal EXT3-fs: mounted filesystem with ordered data mode. EXT3-fs error (device loop0): ext3_free_blocks: Freeing blocks in system zones - Block = 16, count = 1 EXT3-fs error (device loop0): ext3_free_blocks: Freeing blocks in system zones - Block = 32, count = 1 EXT3-fs error (device loop0): ext3_free_blocks: ...
Jul 17, 7:25 am 2008
Josef Bacik
Re: ext3 on latest -git: BUG: unable to handle kernel NU ...
Can you try this patch out and see if it fixes the problem? I didn't compile test it, so you may need to tweak somethings, but it should work. Thanks, Signed-off-by: Josef Bacik <jbacik@redhat.com> Index: linux-2.6/fs/ext3/inode.c =================================================================== --- linux-2.6.orig/fs/ext3/inode.c +++ linux-2.6/fs/ext3/inode.c @@ -2023,13 +2023,27 @@ static void ext3_clear_blocks(handle_t * unsigned long count, __le32 *first, __le32 *last) { ...
Jul 17, 6:57 am 2008
Andreas Dilger
Re: ext3 on latest -git: BUG: unable to handle kernel NU ...
Yes, it has been that way on Debian for many years... I was going to say the same thing, but you beat me to it. Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc. --
Jul 17, 4:06 pm 2008
Vegard Nossum
Re: ext3 on latest -git: BUG: unable to handle kernel NU ...
Yeah, the full log exists at http://folk.uio.no/vegardno/linux/log-1216293934.txt I think this is the interesting part: kjournald starting. Commit interval 5 seconds EXT3-fs warning: mounting fs with errors, running e2fsck is recommended EXT3 FS on loop0, internal journal EXT3-fs: mounted filesystem with ordered data mode. EXT3-fs error (device loop0): ext3_free_blocks_sb: bit already cleared for block 1507 EXT3-fs error (device loop0): ext3_free_blocks: Freeing blocks not ...
Jul 17, 6:20 am 2008
Vegard Nossum
Re: ext3 on latest -git: BUG: unable to handle kernel NU ...
-ENOLUCK EXT3-fs error (device loop0): ext3_free_blocks: Freeing blocks not in datazone - block = 524288, count = 1 EXT3-fs error (device loop0) in ext3_free_blocks_sb: IO failure BUG: unable to handle kernel NULL pointer dereference at 0000000c IP: [<c01fd200>] journal_dirty_metadata+0xa0/0x160 It did seem to get further, though. http://folk.uio.no/vegardno/linux/log-1216306142.txt Vegard -- "The animistic metaphor of the bug that maliciously sneaked in while the programmer ...
Jul 17, 7:44 am 2008
Vegard Nossum
Re: ext3 on latest -git: BUG: unable to handle kernel NU ...
Hm, it doesn't apply. Should I revert the previous patch? Vegard -- "The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's own creation." -- E. W. Dijkstra, EWD1036 --
Jul 17, 7:35 am 2008
Vegard Nossum
ext3 on latest -git: BUG: unable to handle kernel NULL p ...
Hi, I get this with both clean v2.6.26 and latest -git (33af79d12e0fa25545d49e86afc67ea8ad5f2f40): BUG: unable to handle kernel NULL pointer dereference at 0000000c IP: [<c01fd1e0>] journal_dirty_metadata+0xa0/0x160 *pde = 00000000 Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC Pid: 4935, comm: rm Not tainted (2.6.26-03414-g33af79d #39) EIP: 0060:[<c01fd1e0>] EFLAGS: 00210246 CPU: 1 EIP is at journal_dirty_metadata+0xa0/0x160 EAX: 00000000 EBX: cca59160 ECX: 00000001 EDX: f5114000 ESI: ...
Jul 17, 5:51 am 2008
Andreas Dilger
Re: ext3 on latest -git: BUG: unable to handle kernel NU ...
It shouldn't cause the kernel to crash, but it should definitely return an error to the application. This is probably one of the code paths that the Coverity folks were reporting on in FAST this year where on-disk errors are not propagated to the application. Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc. --
Jul 17, 4:09 pm 2008
Theodore Tso
Re: ext3 on latest -git: BUG: unable to handle kernel NU ...
Vegard, How big is the filesystem? Is there any chance you can make a compressed e2image of the file? (This will not include file contents, but does reveal the names of the file.) Given the nature of the bug which you are reporting, it should be safe to scramble the names of the filenames using the -s option if that would make you feel more comfortable. The quick version is: e2image -r /dev/loop0 | bzip2 > badfs.e2i.bz2 Then folks like Josef would be able to test your filesystem ...
Jul 17, 8:08 am 2008
Josef Bacik Jul 17, 7:16 am 2008
Vegard Nossum
Re: ext3 on latest -git: BUG: unable to handle kernel NU ...
No, this is the command I used: mount -o loop disk mnt I think this looks interesting: EXT3-fs error (device loop0) in ext3_reserve_inode_write: IO failure The code in ext3_reserve_inode_write() is here: err = ext3_journal_get_write_access(handle, iloc->bh); if (err) { brelse(iloc->bh); iloc->bh = NULL; } Maybe it should do something different here? But I don't know :-) Thanks for helping out! Vegard -- ...
Jul 17, 6:39 am 2008
Marc Zyngier
[BUG][PATCH] nfs_remount oops when rebooting + possible fix
Jeff, Trond, The commit 48b605f83c920d8daa50e43fc2c7f718e04c7bfa (NFS: implement option checking when remounting NFS filesystems (resend)) generate an Oops on my platform when rebooting while its root FS on an NFS share (NFSv3, TCP) : Unmounting local filesystems...done. Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = c3d00000 [00000000] *pgd=a3d72031, *pte=00000000, *ppte=00000000 Internal error: Oops: 17 [#1] Modules linked in: cpufreq_powersave ...
Jul 17, 4:21 am 2008
Jeff Layton
Re: [BUG][PATCH] nfs_remount oops when rebooting + possi ...
On Thu, 17 Jul 2008 13:21:55 +0200 Good catch. Looks reasonable to me... ACK -- Jeff Layton <jlayton@redhat.com> --
Jul 17, 6:43 am 2008
Ben Dooks
MMC: s3cmci.c fixes for section mismatch warnings
Fix the naming of various functions in the s3cmc driver to stop triggering section mismatch warnings. Signed-off-by: Ben Dooks <ben-linux@fluff.org> Index: linux-2.6.26-quilt2/drivers/mmc/host/s3cmci.c =================================================================== --- linux-2.6.26-quilt2.orig/drivers/mmc/host/s3cmci.c 2008-07-15 22:00:55.000000000 +0100 +++ linux-2.6.26-quilt2/drivers/mmc/host/s3cmci.c 2008-07-15 22:04:05.000000000 +0100 @@ -1355,17 +1355,17 @@ static int __devexit ...
Jul 17, 3:54 am 2008
Justin Mattock
Re: Kernel version : what about s.yy.ww.tt scheme ?
What about how porsch does it i.g. 911, 912, 913, 914 -- Justin P. Mattock --
Jul 17, 7:27 am 2008
el es
Re: Kernel version : what about s.yy.ww.tt scheme ?
Yes, master and stable accumulate the same patches, I know. Only master takes new code, whereas -stable does not. This however tells how long did it take to produce the -stable release out of Linus's release ;) And it does not break the current habits - just abuses them a bit ;) And tells you how long the version was around there without another -stable release too. Just by looking onto the version string, quick, sortable in meaningful way, all sorts of pluses there ;) IMO, the kernel ...
Jul 17, 3:38 am 2008
Ben Dooks
Re: [PATCH 3/3] at91_mci: introduce per-mci-revision con ...
How about making it an inline function to avoid the horrible -- Ben (ben@fluff.org, http://www.fluff.org/) 'a smiley only costs 4 bytes' --
Jul 17, 4:04 am 2008
Nicolas Ferre
[PATCH 3/3] at91_mci: introduce per-mci-revision conditi ...
We used to manage features and differences on a per-cpu basis. As several cpus share the same mci revision, this patch aggregates cpus that have the same IP revision in one defined constant. Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com> --- drivers/mmc/host/at91_mci.c | 21 +++++++++++++-------- 1 files changed, 13 insertions(+), 8 deletions(-) diff --git a/drivers/mmc/host/at91_mci.c b/drivers/mmc/host/at91_mci.c index 4e3edf3..a95529c 100644 --- ...
Jul 17, 2:42 am 2008
Nicolas Ferre
[PATCH 2/3] at91_mci: Do a reset after each request
From: Ville Syrjala <syrjala@sci.fi> Reset the controller after each transfer since we're violating the spec sometimes. This is very cheap, so we don't try to be clever. Signed-off-by: Ville Syrjala <syrjala@sci.fi> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com> --- Comment stolen from atmel_mci log. We noticed that AT91SAM9260 board + Marvell 8686 SDIO WLAN adater are not happy without applying the MCI reset trick. drivers/mmc/host/at91_mci.c | 5 ++--- 1 files changed, 2 ...
Jul 17, 2:34 am 2008
Nicolas Ferre
[PATCH 1/3] at91_mci: Enable MMC_CAP_SDIO_IRQ only when ...
According to the datasheets AT91SAM9261 does not support SDIO interrupts, and AT91SAM9260/9263 have an erratum requiring 4bit mode while using slot B for the interrupt to work. Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com> --- Original patch from Ville Syrjala. I removed the rm9200 from the original patch as this chip is not SDIO capable (error in datasheet). drivers/mmc/host/at91_mci.c | 9 ++++++++- 1 files changed, 8 insertions(+), 1 deletions(-) diff --git ...
Jul 17, 2:34 am 2008
Pierre Ossman
Re: [PATCH 1/3] at91_mci: Enable MMC_CAP_SDIO_IRQ only w ...
On Thu, 17 Jul 2008 11:34:07 +0200 Not all SDIO cards use 4-bit mode, so it looks to me like you have to disable it completely (unless there's a third revision where it works without any fine print?). Rgds --=20 -- Pierre Ossman WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption.
Jul 17, 3:55 am 2008
Pascal Terjan
2.6.26 fails to boot on Acer TravelMate 5520 due to PCIE ASPM
When CONFIG_PCIEASPM is activated, Acer TravelMate 5520 will hang at "Setting up standard PCI resources" pcie_noaspm does not seem to help Here is lspci -vvv 00:00.0 Host bridge: ATI Technologies Inc RS690 Host Bridge Subsystem: Acer Incorporated [ALI] Unknown device 0124 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx- Latency: ...
Jul 17, 2:20 am 2008
David Miller
Re: [PATCH net-next] atl1e: Atheros L1E Gigabit Ethernet ...
From: Mariusz Kozlowski <m.kozlowski@tuxland.pl> And these are all entirely superfluous, since they are already defined in linux/ethtool.h --
Jul 17, 2:37 pm 2008
Ben Hutchings
Re: [PATCH net-next] atl1e: Atheros L1E Gigabit Ethernet ...
In fact these are all duplicates of macros defined in <linux/ethtool.h> (except SPEED_0, whatever that means). Ben. -- Ben Hutchings, Senior Software Engineer, Solarflare Communications Not speaking for my employer; that's the marketing department's job. --
Jul 17, 1:23 pm 2008
Mariusz Kozlowski Jul 17, 1:04 pm 2008
jie.yang
[PATCH net-next] atl1e: Atheros L1E Gigabit Ethernet driver
From: Jie Yang <jie.yang@atheros.com> Full patch for the Atheros L1E Gigabit Ethernet driver. Supportring AR8121, AR8113 and AR8114 Signed-off-by: Jie Yang <jie.yang @atheros.com> --- Update on comments: use git-send-email to send non-mangled patches. diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index d85b9d0..70c42d6 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -2383,6 +2383,17 @@ config ATL1 To compile this driver as a module, choose M here. The ...
Jul 17, 2:04 am 2008
Stephen Hemminger
Re: [PATCH net-next] atl1e: Atheros L1E Gigabit Ethernet ...
The use of module parameters to set options is discouraged, especially when there are better choices. All these parameter should be controllable by ethtool. The reason is that users (and tools) shouldn't have to know the special parameters that are specific to that hardware. This version is okay as is for initial inclusion, but the parameters should be removed later. --
Jul 17, 8:44 am 2008
Jie Yang
RE: [PATCH net-next] atl1e: Atheros L1E Gigabit Ethernet ...
On Thursday, July 17, 2008 5:31 PM yes, it do have the limit. Best wishes jie --
Jul 17, 2:41 am 2008
Alexey Dobriyan
Re: [PATCH net-next] atl1e: Atheros L1E Gigabit Ethernet ...
Does it have the same 4G limitation as ATL1 card? If yes, pci_using_64 logic isn't needed, and copying comment from atl1 driver wouldn't hurt, If no, you're setting small DMA mask. --
Jul 17, 2:31 am 2008
el es
Kernel version : what about s.yy.ww.tt scheme ?
Hello, inspired by the bikeshed painting contest, I got the following idea : The scheme to be s.yy.ww.tt, that is : s - series, as it is now (freedom to Linus to bump it to 3 when BKL is removed for example ;) ) yy - two (in a hundred years, three) digits of the year Now the interesting part begins which is ww - the number of the week of the release. This will be between 1 and 52 (53) tt - the number of the week of stable release. As above. I see it like : Take a hypotetical ...
Jul 17, 1:51 am 2008
Jan Engelhardt
Re: Kernel version : what about s.yy.ww.tt scheme ?
-stable usually overlaps with master. But I don't like version numbers long as binutils and "2.8.30.9.01" have. (BTW, IMHO it needs more than just a BKL removal to warrant a jump to 3.x) --
Jul 17, 2:48 am 2008
david
Re: Kernel version : what about s.yy.ww.tt scheme ?
it means that you cannot know what version of the kernel you are getting ready to release. today we can talk that we are working on 2.6.27 or 'this feature was accepted and will be in 2.6.27' any scheme that uses the date of the release means that we can't do this. I see this as a big problem with a fine-grained date scheme. if we use the year in a date-based scheme and have a near end-of-year release slip into the next year (2008.4 is released in Jan 2009) I don't see this as a ...
Jul 17, 4:02 pm 2008
Julian H. Stacey
Re: GPL version 4
------- Blind-Carbon-Copy to: null@berklix.org Subject: Re: GPL version 4 From: "Julian Stacey" <jhs@berklix.com> Organization: http://berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://berklix.com In-reply-to: Your message "Thu, 17 Jul 2008 04:12:50 +0200." <1216260770.10312.21.camel@localhost> Date: Thu, 17 Jul 2008 10:31:07 +0200 Sender: jhs@fire.js.berklix.net Please all, do Not massively cross post this flame ...
Jul 17, 1:31 am 2008
Michael Anderson
personal invitation
thinking of going into hard money? I would like to personally invite you to the largest national event on private money in the country. The contacts you will make will be priceless. Where? Hard Rock Hotel, Las Vegas - Nevada When? Nov 13th 2008 Please go the link provided for addional information. http://biggestnationalevent.com/ or call today: 858 736 7788 to be unsubscribed from our list please: http://biggestnationalevent.com/bye/ or, send us a letter to: PBMSII, 5451 Weuery ...
Jul 17, 1:39 am 2008
Li Zefan
Re: [RFC] [PATCH] cpuset: fix wrong calculation of relax ...
If we all agree on this, I'll send a new patch to fix this. --
Jul 17, 3:13 am 2008
Paul Jackson
Re: [RFC] [PATCH] cpuset: fix wrong calculation of relax ...
In looking at this, I notice something I should have questioned before. The include/linux/sched.h code: struct sched_domain_attr { int relax_domain_level; }; #define SD_ATTR_INIT (struct sched_domain_attr) { \ .relax_domain_level = -1, \ } and the associated passing of relax_domain_level's embedded inside a ...
Jul 17, 1:09 pm 2008
Hidetoshi Seto
Re: [RFC] [PATCH] cpuset: fix wrong calculation of relax ...
I think 1) is correct way. There was a special short path for the top_cpuset's case, but now it is disappeared. I think there are no need to treat the top_cpuset as VIP, so 2) is excessive nurturing. Thanks, H.Seto --
Jul 17, 1:57 am 2008
Li Zefan
[RFC] [PATCH] cpuset: fix wrong calculation of relax dom ...
When multiple cpusets are overlapping in their 'cpus' and hence they form a single sched domain, the largest sched_relax_domain_level among those should be used. But when top_cpuset's sched_load_balance is set, its sched_relax_domain_level is used regardless other sub-cpusets'. There are several proposals to solve this: 1) Travel the cpuset hierarchy to find the largest relax_domain_level in rebuild_sched_domains(). But cpuset avoids hierarchy travelling when ...
Jul 17, 1:07 am 2008
Paul Jackson
Re: [RFC] [PATCH] cpuset: fix wrong calculation of relax ...
This code has gotten too complicated for my modest brain ;). Question: In the case that the top_cpuset's sched_load_balance is -not- set, is there code already present that sets the sched_relax_domain_level in overlapping cpusets to the largest value in any of the overlapping cpusets? If so, where is that code? -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj@sgi.com> ...
Jul 17, 1:28 pm 2008
Roland McGrath
[PATCH 1/6] x86: tracehook_signal_handler
This makes the x86 signal handling code use tracehook_signal_handler() in place of calling into ptrace guts. The call is moved after the sa_mask processing, but there is no other change. This cleanup doesn't matter to existing debuggers, but is the sensible thing: have all facets of the handler setup complete before the debugger inspects the task again. Signed-off-by: Roland McGrath <roland@redhat.com> --- arch/x86/kernel/signal_32.c | 6 ++++-- arch/x86/kernel/signal_64.c | 6 ...
Jul 17, 12:47 am 2008
Roland McGrath
[PATCH 6/6] x86: tracehook: CONFIG_HAVE_ARCH_TRACEHOOK
The x86 arch code has all the prerequisites, so set HAVE_ARCH_TRACEHOOK. Signed-off-by: Roland McGrath <roland@redhat.com> --- arch/x86/Kconfig | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 96e0c2e..dab1735 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -27,6 +27,7 @@ config X86 select HAVE_FTRACE select HAVE_KVM if ((X86_32 && !X86_VOYAGER && !X86_VISWS && !X86_NUMAQ) || X86_64) select HAVE_ARCH_KGDB if ...
Jul 17, 12:50 am 2008
Roland McGrath
[PATCH 4/6] x86 signals: use asm/syscall.h
Replace local inlines with the asm/syscall.h interfaces that do the same things. Signed-off-by: Roland McGrath <roland@redhat.com> --- arch/x86/kernel/signal_64.c | 38 +++++--------------------------------- 1 files changed, 5 insertions(+), 33 deletions(-) diff --git a/arch/x86/kernel/signal_64.c b/arch/x86/kernel/signal_64.c index 5d6c237..e78b97f 100644 --- a/arch/x86/kernel/signal_64.c +++ b/arch/x86/kernel/signal_64.c @@ -27,6 +27,7 @@ #include <asm/proto.h> #include ...
Jul 17, 12:49 am 2008
Roland McGrath
[PATCH 2/6] x86: tracehook syscall
This changes x86 syscall tracing to use the new tracehook.h entry points. There is no change, only cleanup. Signed-off-by: Roland McGrath <roland@redhat.com> --- arch/x86/kernel/ptrace.c | 34 ++++++---------------------------- 1 files changed, 6 insertions(+), 28 deletions(-) diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c index e37dccc..19a7d2c 100644 --- a/arch/x86/kernel/ptrace.c +++ b/arch/x86/kernel/ptrace.c @@ -14,6 +14,7 @@ #include <linux/errno.h> #include ...
Jul 17, 12:48 am 2008
Roland McGrath
[PATCH 0/6] x86 tracehook patches
Hi! Here is the x86 arch work that goes with the "tracehook" patch series that I posted for the generic code. I don't know how the merging will go with that. But when there is a tree containing all that to base it on, you can merge these arch patches on top of that. You can't take these without the generic tracehook series, some will break the build until the generic file is there. This series also requires as a baseline what you have in tip/x86/step. The following changes since commit ...
Jul 17, 12:45 am 2008
Roland McGrath
[PATCH 5/6] x86: tracehook: TIF_NOTIFY_RESUME
This adds TIF_NOTIFY_RESUME support for x86, both 64-bit and 32-bit. When set, we call tracehook_notify_resume() on the way to user mode. Signed-off-by: Roland McGrath <roland@redhat.com> --- arch/x86/kernel/signal_32.c | 5 +++++ arch/x86/kernel/signal_64.c | 5 +++++ include/asm-x86/thread_info.h | 4 +++- 3 files changed, 13 insertions(+), 1 deletions(-) diff --git a/arch/x86/kernel/signal_32.c b/arch/x86/kernel/signal_32.c index 3ffb88f..c17c0cb 100644 --- ...
Jul 17, 12:50 am 2008
Roland McGrath
[PATCH 3/6] x86: tracehook: asm/syscall.h
Add asm/syscall.h for x86 with all the required entry points. This will allow arch-independent tracing code for system calls. Signed-off-by: Roland McGrath <roland@redhat.com> --- include/asm-x86/ptrace.h | 5 + include/asm-x86/syscall.h | 210 +++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 215 insertions(+), 0 deletions(-) diff --git a/include/asm-x86/ptrace.h b/include/asm-x86/ptrace.h index 8a71db8..91a77f5 100644 --- a/include/asm-x86/ptrace.h +++ ...
Jul 17, 12:48 am 2008
Roland McGrath
[PATCH 04/23] tracehook: exit
This moves the PTRACE_EVENT_EXIT tracing into a tracehook.h inline, tracehook_report_exec(). The change has no effect, just clean-up. Signed-off-by: Roland McGrath <roland@redhat.com> --- include/linux/tracehook.h | 15 +++++++++++++++ kernel/exit.c | 6 ++---- 2 files changed, 17 insertions(+), 4 deletions(-) diff --git a/include/linux/tracehook.h b/include/linux/tracehook.h index 6276353..967ab47 100644 --- a/include/linux/tracehook.h +++ ...
Jul 17, 12:28 am 2008
Roland McGrath
[PATCH 03/23] tracehook: unexport ptrace_notify
The ptrace_notify() function should not be called by any modules. It was only ever exported to be called by binfmt exec functions. But that is no longer necessary since fs/exec.c deals with that generically now. There should be no calls to ptrace_notify() from outside the core kernel. Signed-off-by: Roland McGrath <roland@redhat.com> --- kernel/signal.c | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/kernel/signal.c b/kernel/signal.c index 6c0958e..02d3a11 ...
Jul 17, 12:28 am 2008
Roland McGrath
[PATCH 06/23] tracehook: vfork-done
This moves the PTRACE_EVENT_VFORK_DONE tracing into a tracehook.h inline, tracehook_report_vfork_done(). The change has no effect, just clean-up. Signed-off-by: Roland McGrath <roland@redhat.com> --- include/linux/tracehook.h | 18 ++++++++++++++++++ kernel/fork.c | 5 +---- 2 files changed, 19 insertions(+), 4 deletions(-) diff --git a/include/linux/tracehook.h b/include/linux/tracehook.h index 3ebc58b..830e6e1 100644 --- a/include/linux/tracehook.h +++ ...
Jul 17, 12:29 am 2008
Roland McGrath
[PATCH 08/23] tracehook: tracehook_tracer_task
This adds the tracehook_tracer_task() hook to consolidate all forms of "Who is using ptrace on me?" logic. This is used for "TracerPid:" in /proc and for permission checks. We also clean up the selinux code the called an identical accessor. Signed-off-by: Roland McGrath <roland@redhat.com> --- fs/proc/array.c | 9 +++++++-- fs/proc/base.c | 13 +++++++++---- include/linux/tracehook.h | 18 ++++++++++++++++++ security/selinux/hooks.c | 22 ...
Jul 17, 12:29 am 2008
Roland McGrath
[PATCH 05/23] tracehook: clone
This moves all the ptrace initialization and tracing logic for task creation into tracehook.h and ptrace.h inlines. It reorganizes the code slightly, but should not change any behavior. There are four tracehook entry points, at each important stage of task creation. This keeps the interface from the core fork.c code fairly clean, while supporting the complex setup required for ptrace or something like it. Signed-off-by: Roland McGrath <roland@redhat.com> --- include/linux/ptrace.h | ...
Jul 17, 12:29 am 2008
Roland McGrath
[PATCH 12/23] tracehook: tracehook_consider_fatal_signal
This defines tracehook_consider_fatal_signal() has a fine-grained hook for deciding to skip the special cases for a fatal signal, as ptrace does. There is no change, only cleanup. Signed-off-by: Roland McGrath <roland@redhat.com> --- include/linux/tracehook.h | 21 +++++++++++++++++++++ kernel/signal.c | 9 +++++---- 2 files changed, 26 insertions(+), 4 deletions(-) diff --git a/include/linux/tracehook.h b/include/linux/tracehook.h index 8cffd34..8b4c15e 100644 --- ...
Jul 17, 12:30 am 2008
Roland McGrath
[PATCH 22/23] task_current_syscall
This adds the new function task_current_syscall() on machines where the asm/syscall.h interface is supported (CONFIG_HAVE_ARCH_TRACEHOOK). It's exported for modules to use in the future. This function safely samples the state of a blocked thread to collect what system call it is blocked in, and the six system call argument registers. Signed-off-by: Roland McGrath <roland@redhat.com> --- include/linux/ptrace.h | 4 ++ lib/Makefile | 2 + lib/syscall.c | 75 ...
Jul 17, 12:31 am 2008
Andrew Morton
Re: [PATCH 00/23] tracehook
It's pretty simple - it's just piplining. During the -rc's we accumulate stuff for the next release in linux-next and in -mm. During the 2.6.x->2.6.x+1-rc1 merge window we transfer that material into mainline then the cycle starts again. So new code which turns up during the merge window is a problem. It should be reviewed, integrated on top of the already-pending work and should get some testing in linux-next. But during the patch-merging chaos nobody has the time or a suitable tree upon ...
Jul 17, 1:30 am 2008
Alexey Dobriyan
Re: [PATCH 01/23] tracehook: add linux/tracehook.h
ptrace(2) will start calling utrace_* hooks and functions. These tracehooks are generic and utrace is generic as well. --
Jul 17, 2:50 pm 2008
Roland McGrath
[PATCH 20/23] tracehook: CONFIG_HAVE_ARCH_TRACEHOOK
This adds the generic HAVE_ARCH_TRACEHOOK kconfig item. Each arch should add to some Kconfig file: select HAVE_ARCH_TRACEHOOK if the arch code uses all the latest hooks to enable newfangled tracing and debugging code. The comment in arch/Kconfig lists all the prerequisite arch support. When all these are available, setting HAVE_ARCH_TRACEHOOK will allow enabling any new features that depend on the modern arch interfaces. Signed-off-by: Roland McGrath <roland@redhat.com> --- arch/Kconfig ...
Jul 17, 12:31 am 2008
Roland McGrath
[PATCH 10/23] tracehook: tracehook_signal_handler
This defines tracehook_signal_handler() as a hook for the arch signal handling code to call. It gives ptrace the opportunity to stop for a pseudo-single-step trap immediately after signal handler setup is done. Signed-off-by: Roland McGrath <roland@redhat.com> --- include/linux/tracehook.h | 23 +++++++++++++++++++++++ 1 files changed, 23 insertions(+), 0 deletions(-) diff --git a/include/linux/tracehook.h b/include/linux/tracehook.h index e113e09..2d1426f 100644 --- ...
Jul 17, 12:30 am 2008
Roland McGrath
[PATCH 01/23] tracehook: add linux/tracehook.h
This adds the new kernel-internal header file <linux/tracehook.h>. This is not yet used at all. The comments in the header introduce what the following series of patches is about. The aim is to formalize and consolidate all the places that the core kernel code and the arch code now ties into the ptrace implementation. These patches mostly don't cause any functional change. They just move the details of ptrace logic out of core code into tracehook.h inlines, where they are mostly compiled ...
Jul 17, 12:27 am 2008
Christoph Hellwig
Re: [PATCH 01/23] tracehook: add linux/tracehook.h
Even then I don't think it's a good idea. This one should only be touched in very very few places --
Jul 17, 6:34 am 2008
Roland McGrath
[PATCH 00/23] tracehook
This patch series introduces the "tracehook" interface layer of inlines in <linux/tracehook.h>. There are more details in the log entry for patch 01/23 and in the header file comments inside that patch. Most of these changes move code around with little or no change, and they should not break anything or change any behavior. This sets a new standard for uniform arch support to enable clean arch-independent implementations of new debugging and tracing stuff, denoted by ...
Jul 17, 12:25 am 2008
Roland McGrath
[PATCH 21/23] tracehook: wait_task_inactive
This extends wait_task_inactive() with a new argument so it can be used in a "soft" mode where it will check for the task changing state unexpectedly and back off. There is no change to existing callers. This lays the groundwork to allow robust, noninvasive tracing that can try to sample a blocked thread but back off safely if it wakes up. Signed-off-by: Roland McGrath <roland@redhat.com> --- arch/ia64/kernel/perfmon.c | 4 ++-- include/linux/sched.h | 8 ++++++-- ...
Jul 17, 12:31 am 2008
Roland McGrath
Re: [PATCH 00/23] tracehook
> It's a strange time to be sending this. I've never managed to understand how the timing of your cycles works exactly, and I really just work on the "send it when you can" principle. To be honest all I really know is that stuff is going in now, and that I really hope this can be merged in soon (for 2.6.27). I do think its impact is low. The sooner this goes in, the sooner arch folks can round out all their bits and the more time folks like me can spend on actually making something new and ...
Jul 17, 1:11 am 2008
Roland McGrath
[PATCH 09/23] tracehook: tracehook_expect_breakpoints
This adds tracehook_expect_breakpoints() as a formal hook for the nommu code to use for its, "Is text-poking likely?" check at mmap time. This names the actual semantics the code means to test, and documents it. Signed-off-by: Roland McGrath <roland@redhat.com> --- include/linux/tracehook.h | 15 +++++++++++++++ mm/nommu.c | 4 ++-- 2 files changed, 17 insertions(+), 2 deletions(-) diff --git a/include/linux/tracehook.h b/include/linux/tracehook.h index ...
Jul 17, 12:29 am 2008
Roland McGrath
[PATCH 07/23] tracehook: release_task
This moves the ptrace-related logic from release_task into tracehook.h and ptrace.h inlines. It provides clean hooks both before and after locking tasklist_lock, for future tracing logic to do more cleanup without the lock. This also changes release_task() itself in the rare "zap_leader" case to set the leader to EXIT_DEAD before iterating. This maintains the invariant that release_task() only ever handles a task in EXIT_DEAD. This is a common-sense invariant that is already always true except ...
Jul 17, 12:29 am 2008
Alexey Dobriyan
Re: [PATCH 23/23] /proc/PID/syscall
My gut feeling this code needs ptrace_may_access() checks. --
Jul 17, 3:56 pm 2008
Roland McGrath
[PATCH 17/23] tracehook: force signal_pending()
This defines a new hook tracehook_force_sigpending() that lets tracing code decide to force TIF_SIGPENDING on in recalc_sigpending(). This is not used yet, so it compiles away to nothing for now. It lays the groundwork for new tracing code that can interrupt a task synthetically without actually sending a signal. Signed-off-by: Roland McGrath <roland@redhat.com> --- include/linux/tracehook.h | 14 ++++++++++++++ kernel/signal.c | 4 +++- 2 files changed, 17 insertions(+), 1 ...
Jul 17, 12:30 am 2008
Roland McGrath
[PATCH 16/23] tracehook: death
This moves the ptrace logic in task death (exit_notify) into tracehook.h inlines. Some code is rearranged slightly to make things nicer. There is no change, only cleanup. There is one hook called with the tasklist_lock write-locked, as ptrace needs. There is also a new hook called after exit_state changes and without locks. This is a better place for tracing work to be in the future, since it doesn't delay the whole system with locking. Signed-off-by: Roland McGrath ...
Jul 17, 12:30 am 2008
Roland McGrath
[PATCH 11/23] tracehook: tracehook_consider_ignored_signal
This defines tracehook_consider_ignored_signal() has a fine-grained hook for deciding to prevent the normal short-circuit of sending an ignored signal, as ptrace does. There is no change, only cleanup. Signed-off-by: Roland McGrath <roland@redhat.com> --- include/linux/tracehook.h | 19 +++++++++++++++++++ kernel/signal.c | 27 ++++++++++++++++----------- 2 files changed, 35 insertions(+), 11 deletions(-) diff --git a/include/linux/tracehook.h ...
Jul 17, 12:30 am 2008
Roland McGrath
[PATCH 19/23] tracehook: asm/syscall.h
This adds asm-generic/syscall.h, which documents what a real asm-ARCH/syscall.h file should define. This is not used yet, but will provide all the machine-dependent details of examining a user system call about to begin, in progress, or just ended. Each arch should add an asm-ARCH/syscall.h that defines all the entry points documented in asm-generic/syscall.h, as short inlines if possible. This lets us write new tracing code that understands user system call registers, without any new ...
Jul 17, 12:31 am 2008
Roland McGrath
[PATCH 18/23] tracehook: TIF_NOTIFY_RESUME
This adds tracehook.h inlines to enable a new arch feature in support of user debugging/tracing. This is not used yet, but it lays the groundwork for a debugger to be able to wrangle a task that's possibly running, without interrupting its syscalls in progress. Each arch should define TIF_NOTIFY_RESUME, and in their entry.S code treat it much like TIF_SIGPENDING. That is, it causes you to take the slow path when returning to user mode, where you get the full user-mode state accessible as for ...
Jul 17, 12:31 am 2008
Roland McGrath
[PATCH 13/23] tracehook: syscall
This adds standard tracehook.h inlines for arch code to call when TIF_SYSCALL_TRACE has been set. This replaces having each arch implement the ptrace guts for its syscall tracing support. Signed-off-by: Roland McGrath <roland@redhat.com> --- include/linux/tracehook.h | 70 +++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 70 insertions(+), 0 deletions(-) diff --git a/include/linux/tracehook.h b/include/linux/tracehook.h index 8b4c15e..3548694 100644 --- ...
Jul 17, 12:30 am 2008
Andrew Morton
Re: [PATCH 00/23] tracehook
It's a strange time to be sending this. We're in the middle of a massive dump from linux-next into mainline and soon we'll be doing a more modest dump of -mm into mainline and I'm tiptoeing around getting all anxious when people try to sneak wasnt-in-linux-next stuff into mainline thus wrecking all my junk. I'm largely in ignore-new-stuff mode as I'm trying to stabilise the existing stuff for 2.6.27-rc1 and hopefully the subsystem maintainers are in the same mode. So, hum. It's not a ...
Jul 17, 12:39 am 2008
Roland McGrath
Re: [PATCH 00/23] tracehook
All the arch considerations are opt-in, and mostly quite simple. I have arch patches for review by a few arch maintainers who I don't think will mind too much. All others can look into it at their leisure and expect not to get broken. Thanks, Roland --
Jul 17, 1:37 am 2008
Roland McGrath
[PATCH 23/23] /proc/PID/syscall
This adds /proc/PID/syscall and /proc/PID/task/TID/syscall magic files. These use task_current_syscall() to show the task's current system call number and argument registers, stack pointer and PC. For a task blocked but not in a syscall, the file shows "-1" in place of the syscall number, followed by only the SP and PC. For a task that's not blocked, it shows "running". Signed-off-by: Roland McGrath <roland@redhat.com> --- fs/proc/base.c | 26 ++++++++++++++++++++++++++ 1 files changed, ...
Jul 17, 12:31 am 2008
Andrew Morton
Re: [PATCH 00/23] tracehook
Looks sane to me from a quick scan. A ~200 byte increase in i386 allnoconfig .text is liveable with. But nothing defines CONFIG_HAVE_ARCH_TRACEHOOK yet. What effect will that have? I don't like the name! We have ftrace and we have static tracepoints and we have dynamic tracepoints and we have linux trace toolkit and whatever is in kernel/trace/trace.c etc, etc. Now this work comes along with _userspace_ tracing capabilities and it goes and calls it, of all things, "trace"! Things ...
Jul 17, 1:51 am 2008
Alexey Dobriyan
Re: [PATCH 01/23] tracehook: add linux/tracehook.h
And this is suprising wish given one can't predict how exactly those Pointless 1:1 wrapper unless you're going to #ifdef ->ptrace later. --
Jul 17, 1:48 am 2008
Roland McGrath
[PATCH 15/23] tracehook: job control
This defines the tracehook_notify_jctl() hook to formalize the ptrace effects on the job control notifications. There is no change, only cleanup. Signed-off-by: Roland McGrath <roland@redhat.com> --- include/linux/tracehook.h | 20 ++++++++++++++++++++ kernel/signal.c | 10 +++++----- 2 files changed, 25 insertions(+), 5 deletions(-) diff --git a/include/linux/tracehook.h b/include/linux/tracehook.h index 42a0d7b..6dc428d 100644 --- a/include/linux/tracehook.h +++ ...
Jul 17, 12:30 am 2008
Roland McGrath
[PATCH 14/23] tracehook: get_signal_to_deliver
This defines the tracehook_get_signal() hook to allow tracing code to slip in before normal signal dequeuing. This lays the groundwork for new tracing features that can inject synthetic signals outside the normal queue or control the disposition of delivered signals. The calling convention lets tracehook_get_signal() decide both exactly what will happen and what signal number to report in the handler/exit. Signed-off-by: Roland McGrath <roland@redhat.com> --- include/linux/tracehook.h | ...
Jul 17, 12:30 am 2008
Roland McGrath
[PATCH 02/23] tracehook: exec
This moves all the ptrace hooks related to exec into tracehook.h inlines. This also lifts the calls for tracing out of the binfmt load_binary hooks into search_binary_handler() after it calls into the binfmt module. This change has no effect, since all the binfmt modules' load_binary functions did the call at the end on success, and now search_binary_handler() does it immediately after return if successful. We consolidate the repeated code, and binfmt modules no longer need to import ...
Jul 17, 12:28 am 2008
Petr Tesarik
Re: [PATCH 01/23] tracehook: add linux/tracehook.h
Ah, maybe justified, because I don't expect any other re-implementation of the same after utrace is finished, but -- there's still the old ptrace implementation, so _not_ mentioning utrace seems a bit better to And that's exactly what's going to happen. Look at Roland's git. ;) Petr --
Jul 17, 4:06 am 2008
James Morris
Re: [PATCH 3/4] do_wait: return security_task_wait() err ...
Acked-by: James Morris <jmorris@namei.org> -- James Morris <jmorris@namei.org> --
Jul 17, 2:23 am 2008
Roland McGrath
[PATCH 4/4] fix dangling zombie when new parent ignores ...
This fixes an arcane bug that we think was a regression introduced by commit b2b2cbc4b2a2f389442549399a993a8306420baf. When a parent ignores SIGCHLD (or uses SA_NOCLDWAIT), its children would self-reap but they don't if it's using ptrace on them. When the parent thread later exits and ceases to ptrace a child but leaves other live threads in the parent's thread group, any zombie children are left dangling. The fix makes them self-reap then, as they would have done earlier if ptrace had not ...
Jul 17, 12:14 am 2008
Roland McGrath
[PATCH 3/4] do_wait: return security_task_wait() error c ...
This reverts the effect of commit f2cc3eb133baa2e9dc8efd40f417106b2ee520f3 "do_wait: fix security checks". That change reverted the effect of commit 73243284463a761e04d69d22c7516b2be7de096c. The rationale for the original commit still stands. The inconsistent treatment of children hidden by ptrace was an unintended omission in the original change and in no way invalidates its purpose. This makes do_wait return the error returned by security_task_wait() (usually -EACCES) in place of -ECHILD ...
Jul 17, 12:13 am 2008
Roland McGrath
[PATCH 1/4] do_wait reorganization
This breaks out the guts of do_wait into three subfunctions. The control flow is less nonobvious without so much goto. do_wait_thread and ptrace_do_wait contain the main work of the outer loop. wait_consider_task contains the main work of the inner loop. Signed-off-by: Roland McGrath <roland@redhat.com> --- kernel/exit.c | 215 ++++++++++++++++++++++++++++++++++++--------------------- 1 files changed, 135 insertions(+), 80 deletions(-) diff --git a/kernel/exit.c b/kernel/exit.c index ...
Jul 17, 12:12 am 2008
Roland McGrath
[PATCH 0/5] ptrace & wait cleanup
I posted an earlier version of this patch series before, and I believe this has fixed the quibbles there were with it before. These changes pave the way for cleaning up ptrace a lot more in the future. This series is a prerequisite for the following "tracehook" series, but only because of patch conflicts. They can be reviewed separately. This series of patches is also available in GIT at the URL below, and in a mail folder of patch messages (use git-am or formail -s patch -p1) ...
Jul 17, 12:11 am 2008
Roland McGrath
[PATCH 2/4] ptrace children revamp
ptrace no longer fiddles with the children/sibling links, and the old ptrace_children list is gone. Now ptrace, whether of one's own children or another's via PTRACE_ATTACH, just uses the new ptraced list instead. There should be no user-visible difference that matters. The only change is the order in which do_wait() sees multiple stopped children and stopped ptrace attachees. Since wait_task_stopped() was changed earlier so it no longer reorders the children list, we already know this ...
Jul 17, 12:13 am 2008
Roland McGrath
Re: [PATCH 2/4] ptrace children revamp
Yes. After this settles, it will become tractable to change the whole locking plan for ptrace so we don't have this problem and get rid of this kludge altogether. Thanks, Roland --
Jul 17, 12:34 am 2008
Andrew Morton
Re: [PATCH 2/4] ptrace children revamp
/* * Nasty, nasty. * * We want to hold both the task-lock and the * tasklist_lock for writing at the same time. * But that's against the rules (tasklist_lock * is taken for reading by interrupts on other * cpu's that may have task_lock). hm, copying this code didn't do much to improve the world. Is there any prospect of "fixing" this somehow? Perhaps this code should be pulled up into a separate function, not --
Jul 17, 12:30 am 2008
Boris Petkov
Re: [PATCH] Fix collateral damage to top level Makefile
On Thu, Jul 17, 2008 at 10:50 AM, Benjamin Herrenschmidt Oh come on, don't scare the guy more than he is - now he'll be staring frantically at each +-diff line before submitting :). And it's not like it's the end of the world, it's just that Fred has turned 42 or similar :) P.S. If I only knew how such an innocent thing would destroy a man's life i never would've reported it in the first place :). Sorry Grant. -- Regards/Gruß, Boris --
Jul 17, 2:49 am 2008
Benjamin Herrenschmidt
Re: [PATCH] Fix collateral damage to top level Makefile
Well, it's partially my fault for not spotting it when pulling in Grant's git and pushing out to Linus. Anyway, it's a mistake, shit happens, I doubt Grant will do that one twice :-) Cheers, Ben. --
Jul 17, 1:50 am 2008
Grant Likely
[PATCH] Fix collateral damage to top level Makefile
From: Grant Likely <grant.likely@secretlab.ca> The patch named "powerpc/mpc5121: Add clock driver", also contained an unrelated and bogus change to the top-level makefile. This patch backs out the bad bit. SHA1 of offending patch: 137e95906e294913fab02162e8a1948ade49acb5) Signed-off-by: Grant Likely <grant.likely@secretlab.ca> --- If the maintainer who picked up this patch (Grant Likely) had done his job, this cack-up never would have happened. Why do we still have to deal with such ...
Jul 17, 12:06 am 2008
Paul Mundt
Re: [PATCH] Fix collateral damage to top level Makefile
I think the more important question is why the hell would anyone put that in a Makefile, ever? ;-) --
Jul 17, 12:27 am 2008
Grant Likely
Re: [PATCH] Fix collateral damage to top level Makefile
Heh, oh please, I've got a thicker skin that that. I appreciate the error being pointed out. But Ben's right. That mistake will not happen again! :-) Cheers, g. --
Jul 17, 8:11 am 2008
John Rigby
Re: [PATCH] Fix collateral damage to top level Makefile
Grant, I owe you on this one. Sorry. John --
Jul 17, 9:01 am 2008
Randy Dunlap
Re: [PATCH] Fix markers duplicate modpost entry (update)
Agreed, although I would have used [PATCH] modpost: fix duplicate markers entries --- ~Randy Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA http://linuxplumbersconf.org/ --
Jul 17, 3:40 pm 2008
Andrew Morton
Re: [PATCH] Fix markers duplicate modpost entry (update)
On Thu, 17 Jul 2008 10:52:17 -0400 Please prepare the patch titles along the lines of [patch] subsystem-identifer: what i did to it so this one would have been [patch] markers: fix markers duplicate modpost entry It's for consistency, and for ease of reading commits mailing lists and gitk titles and git-shortlog output, etc. Thanks. --
Jul 17, 3:28 pm 2008
Andrew Morton
Re: [PATCH] Fix markers duplicate modpost entry
whoa, what's all that about? Patches can only have one Author: in git, and we indicate that in emails by putting a From: line right at the top of the changelog. (Additional credits can and should be mentioned in the changelog text of course). When that From: line is missing we take the authorship info from the email headers. So according to the above, this patch has three authors. Geeze, even I can type faster than that! --
Jul 17, 12:16 am 2008
Mathieu Desnoyers
Re: [PATCH] Fix markers duplicate modpost entry (update)
When a kernel was rebuilt, the previous Module.markers was not cleared. It caused markers with different format strings to appear as duplicates when a markers was changed. This problem is present since scripts/mod/modpost.c started to generate Module.markers, commit b2e3e658b344c6bcfb8fb694100ab2f2b5b2edb0 It therefore applies to 2.6.25, 2.6.26 and linux-next. I merely merged the patches from Roland, Wenji and Takashi here. Credits to Roland McGrath <roland@redhat.com> Wenji Huang ...
Jul 17, 7:52 am 2008
Mathieu Desnoyers
Re: [PATCH] Fix markers duplicate modpost entry
Yes, it's needed in 2.6.26.x and 2.6.25, but I doubt it is critical : only needed for systemtap users which use markers and rebuild their I took the diffs Roland and Wenji sent in separate emails and created this patch. They are the ones who actually identified the solution. So I guess I should be the author, with credits to them, if they are ok with that. -- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 --
Jul 17, 7:13 am 2008
Mathieu Desnoyers
[PATCH] Fix markers duplicate modpost entry
When a kernel was rebuilt, the previous Module.markers was not cleared. It caused markers with different format strings to appear as duplicates when a markers was changed. I merely merged the patches from Roland and Wenji here. It applies to mainline (and is not intrusive, so will also apply to linux-next). Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> From: Roland McGrath <roland@redhat dot com> From: Wenji Huang <wenji.huang@oracle.com> CC: ...
Jul 17, 12:03 am 2008
Grant Likely
Re: FRED=42
On Thu, Jul 17, 2008 at 12:35 AM, Borislav Petkov Oh crap Yeah, I'll fix that right now. Sorry. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. --
Jul 16, 11:48 pm 2008
Borislav Petkov
FRED=42
Hi John, Grant, can you please remove that "FRED=42" line from the top kernel Makefile since it seems it sneaked in unwanted with the rest of the commit? Thanks. -- Regards/Gruß, Boris. --
Jul 16, 11:35 pm 2008
David Woodhouse
Re: {build fail} firmware: latest Linus tree modules_ins ...
Thank you for the report. Please could you confirm that this fixes it for you? ---- Subject: Update scripts/Makefile.fwinst to cope with older make Also fix unwanted rebuilds of the firmware/ihex2fw tool by including the .ihex2fw.cmd file when present. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> diff --git a/scripts/Makefile.fwinst b/scripts/Makefile.fwinst index 3d2f460..92305a3 100644 --- a/scripts/Makefile.fwinst +++ b/scripts/Makefile.fwinst @@ -28,18 +28,39 @@ ...
Jul 16, 11:44 pm 2008
Wang Chen
{build fail} firmware: latest Linus tree modules_install fail
make[1]: *** No rule to make target `/lib/firmware/$(dir', needed by `/lib/firmware/ttusb-budget/dspbootcode.bin'. Stop. make: *** [_modinst_post] Error 2 This error was outputed when I build the latest git tree of Linus's linux-2.6. --
Jul 16, 10:17 pm 2008
Wang Chen
Re: {build fail} firmware: latest Linus tree modules_ins ...
compile, build, reboot. all ok. It fixed my problem. Thank you. --
Jul 16, 11:55 pm 2008
Phil Pell
Re: [stable] Linux 2.6.25.10
Oh holy hell. Let's get down to brass tacks, folks. Bugs = bad. Bugs that cause my critical systems to crash = worse. Bugs that allow the Croatian mafia to get credit cards in the names of 300,000 of my customers = catastrophic and incredibly costly. Anyone remember Maslow's hierarchy of human needs? It's kind of like that. Let's fix all the bugs we can and give kudos to the people who do. Let's just try to fix the worst ones first if at all possible. Linus, I have nothing but the ...
Jul 16, 9:21 pm 2008
Mathieu Desnoyers
[PATCH linux-next] Blktrace port to tracepoints
Port blktrace to the tracepoint infrastructure. It's just like markers, but without the format strings. Type checking of probes and call sites is done at probe registration. A reference count of blktrace users is kept. As soon as it is higher than 0, the probes are connected, which means that the branch is activated to enable the function calls and that the function addresses are added to the list of function to call for these tracepoints. By the way, I think something is silly with the current ...
Jul 16, 8:59 pm 2008
KAMEZAWA Hiroyuki
[mmtom][BUGFIX] vmscan-second-chance-replacement-for-ano ...
Under memcg, active anon tend not to go to inactive anon. This will cause OOM in memcg easily when tons of anon was used at once. This check was lacked in split-lru. This patch is a fix agaisnt vmscan-second-chance-replacement-for-anonymous-pages.patch Changelog: v1 -> v2: - avoid adding "else". Signed-off-by:KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Acked-by: Rik van Riel <riel@redhat.com> mm/vmscan.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: ...
Jul 16, 8:27 pm 2008
Balbir Singh
Re: [mmtom][BUGFIX] vmscan-second-chance-replacement-for ...
I have not seen this, but looks good to me Acked-by: Balbir Singh <balbir@linux.vnet.ibm.com> -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL --
Jul 17, 12:17 pm 2008
Mathieu Desnoyers
[PATCH ftrace.git] Immedate Values Optimized Jump Fix
Hi Ingo, This fix would apply to the ftrace tree which contains the jump-based immediate values. I don't know if this tree is still under active development, but I guess that it wouldn't hurt to fix it. Caused a kernel OOPS when loading the tracepoint probes once in a while on a 8-way x86_64. Immedate Values Optimized Jump Fix Fix the immediate values optimized jump fallback, which parameters were wrong following the last changes. It should be a 5 bytes instruction (not 2) with a ...
Jul 16, 8:17 pm 2008
Mathieu Desnoyers
Re: [ltt-dev] LTTng 0.11
LTTng 0.11 is released, which contains this bugfix. http://ltt.polymtl.ca/lttng/patch-2.6.26-0.11.tar.bz2 Mathieu -- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 --
Jul 16, 8:10 pm 2008
Mathieu Desnoyers
Immedate Values Optimized Jump Fix
I rarely emit a single patch for a fix wrt LTTng (I usually just release a new version), but this one is worth it. It will be in 0.11 pretty soon, but if you want to apply it to 0.10 meanwhile, it's highly recommended. Caused a kernel OOPS when loading the tracepoint probes once in a while on a 8-way x86_64. Immedate Values Optimized Jump Fix Fix the immediate values optimized jump fallback, which parameters were wrong following the last changes. It should be a 5 bytes instruction (not ...
Jul 16, 7:57 pm 2008
Jan Beulich
Re: ACPI WARNING: at drivers/acpi/tables/tbfadt.c:348 ac ...
I'm not sure how else to express what I already said above: They simply need to get (in ACPI spec terms) the FADT's X_PM1a_EVT_BLK in sync with PM1_EVT_LEN (and they should at once make sure other X_PM*_BLK and X_GPE?_BLK fields are in sync with their respective legacy fields, too - while looking at the dump, it seemed there were more inconsistencies). Jan --
Jul 17, 8:30 am 2008
Andrew Paprocki
Re: ACPI WARNING: at drivers/acpi/tables/tbfadt.c:348 ac ...
Output from acpidump is attached. Also, in this new kernel, the ACPI THRM thermal zone reading for the CPU is incorrect. In 2.6.26-rc8 read a valid value (e.g. 40C) but now reports: [ 0.373987] ACPI: Thermal Zone [THRM] (-127 C) I'm not sure if that is related to this or if it is another patch. I quickly scanned the git log and I don't see any recent change to thermal.c itself. Thanks, -Andrew
Jul 17, 6:03 am 2008
Andrew Paprocki
Re: ACPI WARNING: at drivers/acpi/tables/tbfadt.c:348 ac ...
So does the BIOS owner need to fix the table? If you could give me the exact text to pass along to the mobo mfr, I will forward it and I can get them to release a new BIOS rev. Thanks, -Andrew --
Jul 17, 7:32 am 2008
Jan Beulich
Re: ACPI WARNING: at drivers/acpi/tables/tbfadt.c:348 ac ...
Just as I suspected - the v1 field says 4 bytes, but the v2 field says 8 bits. Jan --
Jul 17, 6:58 am 2008
Jan Beulich
Re: ACPI WARNING: at drivers/acpi/tables/tbfadt.c:348 ac ...
So it's a firmware bug in the system you saw this on. The specification is clear about the width being at least 16 bits, and the warning was added to indicate the problem you now got: Dividing 8 by 16 yields zero for pm1_register_length, which results in acpi_gbl_xpm1a_enable aliasing the address of the respective status register. That won't work, hence the warning. I'd be hesitant to fix this (as I think we should be allowed to expect ACPI tables to not be that fundamentally flawed these ...
Jul 17, 1:59 am 2008
Moore, Robert
RE: ACPI WARNING: at drivers/acpi/tables/tbfadt.c:348acp ...
So far, in the number of the cases like this that I've seen, it's the v2 fields that have problems. Perhaps the heuristic should be something like "if there is an inconsistency between the v1 and v2 fields, fall back to v1". --
Jul 17, 10:20 am 2008
Andi Kleen
Re: ACPI WARNING: at drivers/acpi/tables/tbfadt.c:348acp ...
Yes that makes sense. Jan could you revise the patch to do that please? Thanks, -Andi --
Jul 17, 10:40 am 2008
Andi Kleen
Re: ACPI WARNING: at drivers/acpi/tables/tbfadt.c:348 ac ...
Ok, but we can just get that from a table dump. -Andi --
Jul 17, 5:28 am 2008
Andrew Paprocki
ACPI WARNING: at drivers/acpi/tables/tbfadt.c:348 acpi_t ...
I just saw this for the first time using a kernel built from the git head. This is all the ACPI related printk info around the warning. If more information is needed to figure out what this is, please let me know. [ 0.000000] ACPI: RSDP 000F7CE0, 0024 (r2 RS690 ) [ 0.000000] ACPI: XSDT 3DFE30C0, 004C (r1 RS690 AWRDACPI 42302E31 AWRD 0) [ 0.000000] ACPI: FACP 3DFE7400, 00F4 (r3 RS690 AWRDACPI 42302E31 AWRD 0) [ 0.000000] ------------[ cut here ]------------ [ 0.000000] ...
Jul 16, 7:29 pm 2008
Andi Kleen
Re: ACPI WARNING: at drivers/acpi/tables/tbfadt.c:348 ac ...
When there are systems around where this register is 8 bits then we have to handle it. Real systems beat the specification. The question is just if the hardware is really 8 bits or if the table No it went directly. -Andi --
Jul 17, 2:06 am 2008
Andi Kleen
Re: ACPI WARNING: at drivers/acpi/tables/tbfadt.c:348 ac ...
"Andrew Paprocki" <andrew@ishiboo.com> writes: I'll queue a revert for now until this can be resolved properly. -Andi --
Jul 17, 2:00 am 2008
Andrew Paprocki
Re: ACPI WARNING: at drivers/acpi/tables/tbfadt.c:348 ac ...
This most definitely broke because of: commit 01a5bba576b9364b33f61f0cd9fa70c2cf5535e2 Author: Jan Beulich <jbeulich@novell.com> Date: Wed Jul 16 23:27:08 2008 +0200 Fix FADT parsing I added printk()s and this is what is reported here: printk(KERN_INFO "xpm1a_event_block bit_width=%d pm1_register_length=%d\n", acpi_gbl_FADT.xpm1a_event_block.bit_width, pm1_register_length); acpi_tb_init_generic_address(&acpi_gbl_xpm1a_enable, ...
Jul 16, 8:34 pm 2008
Jan Beulich
Re: ACPI WARNING: at drivers/acpi/tables/tbfadt.c:348 ac ...
What would lspci have to do with this? /proc/acpi/fadt (from an older kernel if the new one fails to come up) would seem to help somewhat, as that would allow comparing the v1 (byte-width) and v2 (bit-width) values - if they're out of sync (and they likely are if the system worked flawlessly with previous kernels), I'd be certain the tables are wrong. Jan --
Jul 17, 2:14 am 2008
Hiroshi Shimamoto
[PATCH] x86_64: ia32_signal.c: remove signal number conversion
From: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com> This was old code that was needed for iBCS and x86-64 never supported that. Signed-off-by: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com> --- arch/x86/ia32/ia32_signal.c | 4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/arch/x86/ia32/ia32_signal.c b/arch/x86/ia32/ia32_signal.c index dc9b9b9..20af4c7 100644 --- a/arch/x86/ia32/ia32_signal.c +++ b/arch/x86/ia32/ia32_signal.c @@ -520,7 +520,6 @@ int ...
Jul 16, 7:21 pm 2008
Li Zefan
[PATCH] ipmi: list_for_each_entry_rcu() cleanup
In the rcu update side, don't use list_for_each_entry_rcu(). Signed-off-by: Li Zefan <lizf@cn.fujitsu.com> --- drivers/char/ipmi/ipmi_msghandler.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/char/ipmi/ipmi_msghandler.c b/drivers/char/ipmi/ipmi_msghandler.c index 8a59aaa..987f3c3 100644 --- a/drivers/char/ipmi/ipmi_msghandler.c +++ b/drivers/char/ipmi/ipmi_msghandler.c @@ -986,7 +986,7 @@ int ipmi_destroy_user(ipmi_user_t user) * synchronize_rcu()) ...
Jul 16, 7:01 pm 2008
Li Zefan
[PATCH] async_tx: list_for_each_entry_rcu() cleanup
In the rcu update side, don't use list_for_each_entry_rcu(). Signed-off-by: Li Zefan <lizf@cn.fujitsu.com> --- crypto/async_tx/async_tx.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/crypto/async_tx/async_tx.c b/crypto/async_tx/async_tx.c index 095c798..17834e5 100644 --- a/crypto/async_tx/async_tx.c +++ b/crypto/async_tx/async_tx.c @@ -295,7 +295,7 @@ dma_channel_add_remove(struct dma_client *client, case DMA_RESOURCE_REMOVED: found = 0; ...
Jul 16, 7:00 pm 2008
Mikulas Patocka
[PATCH] Limit irq nesting
Hi During examination of stack-overflows on sparc64, it was found that there is no limit for a number of nested IRQ handlers. Sparc64 is especially stack-hungry architecture, minimum frame size is 192 bytes and after 75 frames it overflows. If someone provides a legitimate reason for more than 2 nested handlers, you could increase the constant in the patch --- but there really should be some limit, so that many simultaneous interrupts can't blow the stack. Mikulas --- IRQs ...
Jul 16, 6:42 pm 2008
KOSAKI Motohiro
Re: [PATCH] Limit irq nesting
I have no objection to your approach. but I don't know MAX_NESTED_INTERRUPTS is properly or not. Could you explain why MAX_NESTED_INTERRUPTS is two? --
Jul 16, 6:57 pm 2008
Mikulas Patocka
Re: [PATCH] Limit irq nesting
I assume that there is at most one active bad-behaving device with long interrupt processing time. For example IDE disk in PIO mode. If someone starts whining that he is simultaneously using two disks in PIO mode and is losing characters on serial line, we can make an architecture override for this (after we check that the architecture has enough stack space to hold more interrupts). But PIO mode is dead anyway, so there's no need to preemptively care about it. Mikulas --
Jul 17, 4:59 am 2008
Marc Dionne
/proc/mounts unreadable - bisected
With current git, /proc/mounts is unreadable on my system, with any attempts to read it returning EINVAL. This breaks many init scripts, among other things. I bisected it down to this commit: commit 2069f457848f846cb31149c9aa29b330a6b66d1b Author: Eric Paris <eparis@redhat.com> Date: Fri Jul 4 09:47:13 2008 +1000 LSM/SELinux: show LSM mount options in /proc/mounts This patch causes SELinux mount options to show up in /proc/mounts. As with other code in the area ...
Jul 16, 5:53 pm 2008
Eric Paris
Re: /proc/mounts unreadable - bisected
Yes, your SELinux config is hosed. But I'll agree that we should just pass over the LSM options in that case (since clearly there aren't any) and not fail the read altogether. Patch will be forthcoming. -Eric --
Jul 16, 5:59 pm 2008
Yinghai Lu
Re: 2.6.26-rc9-git9 doesn't boot on Macintel
you mean pci=nommconf doesn't work too? 2.6.25 is not using mmconf in your system. lspci -vvxxxx could tell, if it print out 256 or 4096 pci conf space. YH --
Jul 16, 7:59 pm 2008
Justin Mattock
Re: 2.6.26-rc9-git9 doesn't boot on Macintel
O.K. I tried MMCONFIG and it seems to be giving me a: kernel panic VFS: cannot open device sda1 or unkown block (0,0) from what I remember I noticed this as far back as 2.6.22 -- Justin P. Mattock --
Jul 17, 11:39 am 2008
Jack Howarth
Re: 2.6.26-rc9-git9 doesn't boot on Macintel
YH, I have CONFIG_PCIEASPM=y set in .config (since I am using Fedora 9, I copied the .config from the redhat 2.6.26 rpm build as my .config and ran 'make oldconfig'). I'll try rebuilding the kernel with CONFIG_PCIEASPM_DEBUG=y and see if that provides any insights. Jack --
Jul 17, 4:56 am 2008
Yinghai Lu
Re: 2.6.26-rc9-git9 doesn't boot on Macintel
ok, please out lspci -vvxxx under 2.6.25.10 YH --
Jul 16, 7:29 pm 2008
Jack Howarth
Re: 2.6.26-rc9-git9 doesn't boot on Macintel
00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03) Subsystem: Intel Corporation Unknown device 7270 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx- Latency: 0 Capabilities: [e0] Vendor Specific Information <?> 00: 86 80 a0 27 06 00 90 20 03 00 00 06 00 00 00 00 10: 00 ...
Jul 16, 7:40 pm 2008
Jack Howarth
Re: 2.6.26-rc9-git9 doesn't boot on Macintel
YH, Okay, I can confirm that 2.6.25.10 boots okay with pci=nommconf which does disable MMCONFIG. It also works fine by default with MMCONFIG enabled. So there may be two possibly unrelated problems in 2.6.26. The first being that MMCONFIG doesn't start up properly without your patch and the second being that with or without MMCONFIG, the boot process hangs just before when the line... PCI: Transparent bridge - 0000:00:1e.0 should appear. Jack --
Jul 16, 8:44 pm 2008
Yinghai Lu
Re: 2.6.26-rc9-git9 doesn't boot on Macintel
On Wed, Jul 16, 2008 at 11:18 PM, Jack Howarth should get PCI: Fixups for bus 0000:01 PCI: Transparent bridge - 0000:00:01.0 PCI: bridge 0000:00:01.0 io port: [3000, 3fff] PCI: bridge 0000:00:01.0 32bit mmio: ... PCI: Bus scan for 0000:01 returning with max=01 Do you have CONFIG_PCIEASPM in your config? YH --
Jul 16, 11:48 pm 2008
Jack Howarth
Re: 2.6.26-rc9-git9 doesn't boot on Macintel
YH, I am wondering if it might be worthwhile for me to try the various rc releases of 2.6.26 (starting with rc1-git1) to see if I can identify at what point 2.6.26 was broken with regards to booting on my MacBook Pro? In case that would point us towards the checkin of a specific set of patches as the problem. Jack --
Jul 17, 9:26 am 2008
Jack Howarth
Re: 2.6.26-rc9-git9 doesn't boot on Macintel
YH, Using the debug patches and your mmconfig patch as well as the kernel options 'debug initcall_debug apic=verbose pci=routeirq", I see the following messages that don't scroll off screen... PCI: 0000:00:1f.1 reg 10 io port: [ 40d8, 40df] PCI: 0000:00:1f.1 reg 14 io port: [ 40ec, 40ef] PCI: 0000:00:1f.1 reg 18 io port: [ 40d0, 40d7] PCI: 0000:00:1f.1 reg 1c io port: [ 40e8, 40eb] PCI: 0000:00:1f.1 reg 20 io port: [ 40b0, 40bf] pci 0000:00.1f.1: calling ...
Jul 16, 11:18 pm 2008
Justin Mattock
Re: 2.6.26-rc9-git9 doesn't boot on Macintel
No I have not tried the .iso yet. I am more concerned with the PCI option i.g. I'm using Direct, if I change to MMCONFIG will it cause this same bug? right now I'm occupied with drinking at the moment, but tomorrow I am curious as to see if this occurs. keep in mind if I'm going to have to deal with having a stuck system this means I need to use a live cd to recover the system, the problem is SELinux why: chrooting into the hardive and then compiling is going to kind of mess my policy a ...
Jul 16, 6:25 pm 2008
Yinghai Lu Jul 16, 9:04 pm 2008
Yinghai Lu Jul 17, 9:42 am 2008
Jack Howarth
Re: 2.6.26-rc9-git9 doesn't boot on Macintel
YH, A kernel built with CONFIG_PCIEASPM_DEBUG=y and booted with 'debug initcall_debug apic=verbose pci=routeirq' doesn't show any additional messages on booting. Do I need any addition flags? I would note that the hang in 2.6.26 always appears to occur before the line... PCI: Transparent bridge - 0000:00:1e.0 ever appears. It hangs just after the two preceeding lines which always appear in dmesg on 2.6.25.10 and 2.6.26... pci 0000:00:1f.0: quirk: region 0400-047f claimed by ICH6 ...
Jul 17, 5:47 am 2008
Yinghai Lu
Re: 2.6.26-rc9-git9 doesn't boot on Macintel
please boot with debug initcall_debug apic=verbose pci=routeirq? and try pci=nommconf I suspect that could be pci bridge is using 0xf0000000-0xf400000 too after Linus merge pci tree, please try to boot with pci=early_config_dump to see if it is true. please don't drop the cc list. YH --
Jul 16, 5:49 pm 2008
Jack Howarth
Re: 2.6.26-rc9-git9 doesn't boot on Macintel
YH, I am wondering why, on my MacBook Pro, I see a call to... PCI: Scanning behind PCI bridge 0000:00:01.0, config 010100, pass 0 (which 2.6.26 never makes it to on my MacBook Pro)? Might we be able to disable that additional scan behind the PCI bridge of the bus? Jack --
Jul 17, 7:13 am 2008
Jack Howarth
Re: 2.6.26-rc9-git9 doesn't boot on Macintel
Yinghai, As I expected pci=mmconf doesn't allow the MacBook Pro to boot. My understanding is that mmconfig is need for Linux on Macintel (at least for a shared MacOS X/Linux system). I am stuck with regards to the pci_early_config_dump results. The output we need scrolls off the top of the screen and since the boot hangs I can't access with dmesg. Can you suggest a hack right at the end of the code that does pci_early_config_dump that would halt the boot immediately after the ...
Jul 16, 7:35 pm 2008
Jack Howarth
Re: 2.6.26-rc9-git9 doesn't boot on Macintel
Yinghai, Here is what I see with 'debug initcall_debug apci=verbose pci=routeirq'. Hopefully nothing important scrolled off the top of the screen (I've not found a higher resolution vga kernel option that works on my MacBook Pro yet). calling blk_ioc_init+0x0/0x2a initcall blk_ioc_init+0x0/0x2a returned 0 after 0 msecs calling genhd_device_init+0x0/0x55 initcall genhd_device_init+0x0/0x55 returned 0 after 0 msecs calling fbmem_init+0x0/0x8a initcall fbmem_init+0x0/0x8a returned 0 after ...
Jul 16, 6:21 pm 2008
Jack Howarth
Re: 2.6.26-rc9-git9 doesn't boot on Macintel
YH, I meant that pci=nommconf doesn't allow the boot to complete under 2.6.26. I haven't tried that under 2.6.25.10, however the 2.6.5.10 kernel should be using mmconfig since I see... PCI: Using MMCONFIG at f0000000 - ffffffff PCI: Using configuration type 1 ACPI: EC: EC description table is found, configuring boot EC ACPI: EC: non-query interrupt received, switching to interrupt mode ACPI: BIOS _OSI(Linux) query ignored via DMI ACPI: Interpreter enabled ACPI: (supports S0 S3 S4 ...
Jul 16, 8:15 pm 2008
Yinghai Lu
Re: 2.6.26-rc9-git9 doesn't boot on Macintel
please set CONFIG_PCI_DEBUG in your .config and apply attach two patches should get sth like calling acpi_pci_root_init+0x0/0x54 ACPI: PCI Root Bridge [PCI0] (0000:00) PCI: Scanning bus 0000:00 PCI: Found 0000:00:00.0 [10de/005e] 000580 00 PCI: Found 0000:00:01.0 [10de/0051] 000601 00 pci 0000:00:01.0: calling nvidia_force_enable_hpet+0x0/0xe7 PCI: Found 0000:00:01.1 [10de/0052] 000c05 00 PCI: 0000:00:01.1 reg 10 io port: [ee00, ee1f] PCI: 0000:00:01.1 reg 20 io port: [ed00, ed3f] PCI: ...
Jul 16, 9:13 pm 2008
Eduard - Gabriel Mun ...
[RFC PATCH 3/4] kmemtrace: SLUB hooks.
This adds hooks for the SLUB allocator, to allow tracing with kmemtrace. Signed-off-by: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro> --- include/linux/slub_def.h | 9 +++++++- mm/slub.c | 47 ++++++++++++++++++++++++++++++++++++++++----- 2 files changed, 49 insertions(+), 7 deletions(-) diff --git a/include/linux/slub_def.h b/include/linux/slub_def.h index d117ea2..0cef121 100644 --- a/include/linux/slub_def.h +++ b/include/linux/slub_def.h @@ -10,6 +10,7 ...
Jul 16, 5:46 pm 2008
Eduard - Gabriel Mun ...
[RFC PATCH 4/4] kmemtrace: SLOB hooks.
This adds hooks for the SLOB allocator, to allow tracing with kmemtrace. Signed-off-by: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro> --- mm/slob.c | 37 +++++++++++++++++++++++++++++++------ 1 files changed, 31 insertions(+), 6 deletions(-) diff --git a/mm/slob.c b/mm/slob.c index a3ad667..0335c01 100644 --- a/mm/slob.c +++ b/mm/slob.c @@ -65,6 +65,7 @@ #include <linux/module.h> #include <linux/rcupdate.h> #include <linux/list.h> +#include <linux/kmemtrace.h> #include ...
Jul 16, 5:46 pm 2008
Eduard - Gabriel Mun ...
[RFC PATCH 0/4] kmemtrace RFC (resubmit 1)
Hello everybody, I hopefully fixed previous complaints. Also wrote some documentation and fixed some missing stuff in SLAB. Please take a look and comment. BTW, see Documentation/vm/kmemtrace.txt for details on how to use this and for info on design details. Eduard Eduard - Gabriel Munteanu (4): kmemtrace: Core implementation. kmemtrace: SLAB hooks. kmemtrace: SLUB hooks. kmemtrace: SLOB hooks. Documentation/kernel-parameters.txt | 6 + ...
Jul 16, 5:46 pm 2008
Eduard - Gabriel Mun ... Jul 17, 4:49 pm 2008
Matt Mackall
Re: [RFC PATCH 4/4] kmemtrace: SLOB hooks.
Acked-by: Matt Mackall <mpm@selenic.com> -- Mathematics is the supreme nostalgia of our time. --
Jul 17, 8:46 am 2008
Eduard - Gabriel Mun ...
[RFC PATCH 1/4] kmemtrace: Core implementation.
kmemtrace provides tracing for slab allocator functions, such as kmalloc, kfree, kmem_cache_alloc, kmem_cache_free etc.. Collected data is then fed to the userspace application in order to analyse allocation hotspots, internal fragmentation and so on, making it possible to see how well an allocator performs, as well as debug and profile kernel code. Signed-off-by: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro> --- Documentation/kernel-parameters.txt | 6 + ...
Jul 16, 5:46 pm 2008
Pekka Enberg
Re: [RFC PATCH 2/4] kmemtrace: SLAB hooks.
Hi Eduard-Gabriel, On Thu, Jul 17, 2008 at 3:46 AM, Eduard - Gabriel Munteanu We have malloc_sizes[i].cs_size here as the _allocated_ size (which ...here as well. Why? AFAICT, you should always use ->buffer_size as the_allocated_ size. Hmm? --
Jul 17, 12:38 am 2008
Randy Dunlap
Re: [RFC PATCH 1/4] kmemtrace: Core implementation.
Otherwise looks nice. Thanks. --- ~Randy Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA http://linuxplumbersconf.org/ --
Jul 17, 2:34 pm 2008
Eduard - Gabriel Mun ...
[RFC PATCH 2/4] kmemtrace: SLAB hooks.
This adds hooks for the SLAB allocator, to allow tracing with kmemtrace. Signed-off-by: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro> --- include/linux/slab_def.h | 56 +++++++++++++++++++++++++++++++++++++----- mm/slab.c | 61 +++++++++++++++++++++++++++++++++++++++++---- 2 files changed, 104 insertions(+), 13 deletions(-) diff --git a/include/linux/slab_def.h b/include/linux/slab_def.h index 39c3a5e..77b8045 100644 --- a/include/linux/slab_def.h +++ ...
Jul 16, 5:46 pm 2008
Eduard - Gabriel Mun ...
Re: [RFC PATCH 1/4] kmemtrace: Core implementation.
Yes, I'm working on a legible plain Makefile. However, I'd leave both the autoconf variant and the plain Makefile in the package for now. Most developers can use autoconf since it's part of the standard toolset for We keep this here because we see all-zeros events when relay errors occur. I'd like to keep it until I'm sure the relay problem was solved (although I've not seen these errors in a while since I patched You can't add fields at the end, because the struct size will change ...
Jul 17, 11:32 am 2008
Pekka Enberg
Re: [RFC PATCH 1/4] kmemtrace: Core implementation.
Hi, [Adding Randy to cc for the Documentation/ parts and Matt for the core.] On Thu, Jul 17, 2008 at 3:46 AM, Eduard - Gabriel Munteanu As I mentioned in private, I would prefer we drop autoconf from the I think you're supposed to document the actual filesystem in I still think kernel vs. cache is confusing because both allocations So why don't we have the ABI version embedded here like blktrace has so that user-space can check if the format matches its expectations? That should ...
Jul 17, 1:01 am 2008
Pekka Enberg
Re: [RFC PATCH 3/4] kmemtrace: SLUB hooks.
On Thu, Jul 17, 2008 at 3:46 AM, Eduard - Gabriel Munteanu Don't cast flags to unsigned long. The kmemtrace core should use gfp_t --
Jul 17, 12:46 am 2008
Eduard - Gabriel Mun ...
Re: [RFC PATCH 3/4] kmemtrace: SLUB hooks.
Yes, I should cut all these casts off. Will resubmit soon. Eduard --
Jul 17, 11:06 am 2008
Pekka Enberg
Re: [RFC PATCH 4/4] kmemtrace: SLOB hooks.
Hi, [Adding Matt as cc.] On Thu, Jul 17, 2008 at 3:46 AM, Eduard - Gabriel Munteanu --
Jul 17, 12:43 am 2008
Chandra Seetharaman
[scsi_dh] [PATCH] Verify "dev" is a sdev before accessing it.
Before accessing the device data structure in hardware handlers, make sure it is a indeed a sdev device. Yinghai Lu <yhlu.kernel@gmail.com> found the bug on Jul 16, 2008, and later tested/verified the following fix. Signed-off-by: Chandra Seetharaman <sekharan@us.ibm.com> -- Index: linux2.6.26-git3/drivers/scsi/device_handler/scsi_dh_rdac.c =================================================================== --- linux2.6.26-git3.orig/drivers/scsi/device_handler/scsi_dh_rdac.c +++ ...
Jul 16, 5:35 pm 2008
Maciej W. Rozycki
Re: [git pull] PCI pull request for 2.6.27
Conveniently "for" is short enough for indentation like this: for (addr = (u8 *) __va(0xf0000); addr < (u8 *) __va(0x100000); addr += 16) { rt = pirq_check_routing_table(addr); to make the piece of code both well-readable and polite to the right edge of the terminal. That would be my preference -- I hope you agree. Of course, in many cases it may be better to make use of auxiliary variables instead. GCC has to evaluate the expressions used anyway and any ...
Jul 16, 5:23 pm 2008
Linus Torvalds
Re: [git pull] PCI pull request for 2.6.27
I don't actually like that one very much either. It's perfectly readable when looking at things closely, but it's not very nice when quickly "scanning" code visually. It looks like two separate indents. Btw, that "code scanning" is not necessarily a bad idea. It's actually pretty interesting to print code out in a 2-point font (or just open a terminal and do "ctrl -" several times to make the code basically unreadable). See if the code flow makes sense from 10,000 feet - you can ...
Jul 16, 5:38 pm 2008
Linus Torvalds
Re: [git pull] PCI pull request for 2.6.27
Ok, I handled them without checking your branch, just because I actually like feeling like I know what I'm doing. That said, when I inevitably fail, just humor me, and send me a patch to fix it up, mentioning how I missed a really "subtle" thing, and the fact that it didn't even compile wasn't really my fault. That's fine. But do double-check the end result. There's lots of small details (for example, I did try to just undo the damage from the "overlong lines caused somebody ...
Jul 16, 5:28 pm 2008
ZC Miao
Re: Usage of kgdb in v2.6.26
Wow, that's a magic! It works now! I think we should document it in the Documentation of kgdb. Thanks! -- ZC Miao (hellwolf.misty@gmail.com) Blog http://hellwolf.cublog.cn gpg --keyserver pgp.mit.edu --recv-key 0x6B174C6F The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. --
Jul 17, 7:45 am 2008
ZC Miao
Re: Usage of kgdb in v2.6.26
$ cat ../../output/x86.kerneldev/.config| grep CONFIG_DEBUG_RODATA CONFIG_DEBUG_RODATA=y Yes, conigured. -- ZC Miao (hellwolf.misty@gmail.com) Blog http://hellwolf.cublog.cn gpg --keyserver pgp.mit.edu --recv-key 0x6B174C6F Regarding astral projection, Woody Allen once wrote, "This is not a bad way to travel, although there is usually a half-hour wait for luggage." --
Jul 17, 6:21 am 2008
Jason Wessel
Re: Usage of kgdb in v2.6.26
Do you have CONFIG_DEBUG_RODATA=y in your kernel config? There is a presently a known problem where breakpoints will silently fail to plant when this is turned on. Jason. --
Jul 17, 6:14 am 2008
Jeff Garzik
Re: ata error message exception Emask 0x0 SAct 0x0 SErr ...
See http://ata.wiki.kernel.org/index.php/Libata_error_messages An ATA bus error means there is a problem on the ATA bus -- either a cable, cable interference, stuff like that. Jeff --
Jul 17, 12:09 pm 2008
Len Brown
Re: Please pull ACPI updates
Andi, Jesse, Linus, Thanks for working through this while I'm away. Patches with cross-tree dependencies happen, and they continue to be a challenge to our process. We don't really have an organized way to handle them. It seems that every time they are a communication challenge and I'm sorry I wasn't there to hold up my end of the communication on this merge. Jesse, I use Tony Luck's topic-branch scheme, now part of the git ...
Jul 17, 11:49 am 2008
Andi Kleen
Re: Please pull ACPI updates
You only focus only on the merges, but I focus on all the other changes too. The reason I maintain patches in quilt is that it's quite easy to fix them up. Besides as a subsystem maintainer the actual conflict points are very rare because normally people don't change drivers/acpi without What I don't agree on is that a rebased patch had less testing than a patch that got merged by someone else (in this case Linus) into their tree when my tree wasn't at exactly the same point. In both cases ...
Jul 17, 1:29 pm 2008
Andi Kleen
Re: [PATCH] Revert duplicate "dock: bay: Don't call acpi ...
Good catch. Thanks. I'll queue a revert. -Andi --
Jul 17, 4:25 pm 2008
Linus Torvalds
Re: Please pull ACPI updates
No, he rebased it - the three commits you shared are now separate ones. Most of the conflicts seem to have been due tot he x86 tree changes though. But it seems I didn't mess up too much: at least the result booted for me without complaints. So I pushed out my resolution. Jesse, can you please double-check it? Linus --
Jul 16, 5:53 pm 2008
Linus Torvalds
Re: Please pull ACPI updates
Umm. The particular PART of ACPI you depend on needs to go in first, yes. That's the whole point of topic branches. They allow you to separate out work to different areas, so that people who are interested in (say) the PCI-impacting ones can merge with one part, without having to wait for the The PCI tree merged the suspend branch from the ACPI tree. You can see it by lookin gat the PCI merge in gitk: gitk dc7c65db^..dc7c65db and roughly in the middle there you'll find Jesse's ...
Jul 17, 8:18 am 2008
Jesse Barnes
Re: Please pull ACPI updates
Well, I could have misunderstood what we talked about; I guess I just assumed Andi & I would chat before sending out our pull requests. I'll be sure to Just looked, seems fine. I'd pat you on the head to reassure you about it, but my arms aren't quite long enough... I'll dig around some more for git best practices too. Based on what I've seen of the x86 tree I don't have nearly enough branches (though on the plus side, I almost never rebase since I don't want to hose any downstream ...
Jul 16, 7:26 pm 2008
Andi Kleen
Re: Please pull ACPI updates
I originally started with topic branches and imported a few patches this way, but then eventually realized they don't really match my working style. In particular I tend to edit and sometimes delete old patches and that seems to be quite painful with the topic branch setup (or perhaps I just haven't figured out how to do it nicely). Also tried it with guilt, but that also ran into some issues (in particular after merges one cannot manage the patches as a guilt stack anymore) What I did then ...
Jul 16, 11:45 pm 2008
Linus Torvalds
Re: Please pull ACPI updates
Right. And Andi, remember the problems with that one? Remember how I ended up refusing to 'git pull' from you? (Also look at how it failed to work well for Ingo and Thomas as well, and how people complained about that? It's not just you.) In other words, "That is how the old x86-64 tree used to NOT work". Linus --
Jul 17, 8:06 am 2008
Linus Torvalds
Re: Please pull ACPI updates
Don't worry about it. Start small. I think the x86 tree took up some pretty extreme limits, as can be seen by their 29-way merge or whatever it was. They also obviously have a lot more stuff going on than the PCI tree would be expected to have. For most people, I'd expect that a small handful of branches is good. It might be just one, but it might be a couple of independent issues. The point where a topic branch is _really_ useful is when you ask yourself whether that particular ...
Jul 16, 7:56 pm 2008
Linus Torvalds
Re: Please pull ACPI updates
End-point developers can use quilt all thei like. But people cannot and *MUST NOT* destroy other peoples work with quilt, nor make it harder for people to share commits. Len had apparently left a nice topic tree for you. You took that work, and then destroyed it. And yes, it is noticeable: Jesse had shared some of the work from Len by pulling one of the branches (the 'suspend' branch), and then you literally re-wrote _public_ history, so now tohose patches are duplicated. Now, ...
Jul 17, 8:03 am 2008
Ray Lee
Re: Please pull ACPI updates
It matters to us end-testers when we do a git bisect. If you leave the history intact and let the merging happen at Linus' end (or, at least at merge time), then there is a point in history of your tree that someone (or git bisect) can check out and try, validating the patch, and therefore fingering a failed merge. It's the difference between having tested patches and an untested merge, or untested new patches and an untested merge. Your point is the end result is untested either way. The ...
Jul 17, 12:11 pm 2008
Andi Kleen
Re: Please pull ACPI updates
The whole point of the exercise of cleaning up/rewriting the history is to make the tree as bisectable as possible. Otherwise e.g. if I submitted patch + fixup + fixup + revert + fixup etc. everyone doing a bisect would go crazy or rather hit many points with various subtle breakages. Why would you care about the merge and not about the individual patches? The patches are as tested individually as they were before. I don't see how you can call something that was in linux-next for some ...
Jul 17, 12:49 pm 2008
Linus Torvalds
Re: Please pull ACPI updates
Let me do a made-up example of this just to kind of illustrate the point. Let's say that _I_ rebased history to always make it linear. That would obviously make things much "easier" to bisect, since now it's just a linear list of commits, and bisection is just taking the midpoint of that list and trying it. Right? Also, I'd fix up the linear list so that any found bugs are squashed into th code that caused them, so all _known_ bugs are non-issues from the standpoint of bisection: ...
Jul 17, 1:16 pm 2008
Linus Torvalds
Re: Please pull ACPI updates
Actually, it _is_ easier, although apparently the thing that made it easier isn't necessarily widely known or documented. I'm going to quote your whole sequence, because it's not a really odd thing do want to do, and quoting how you do it now also makes the "proper No, what others do (if they know the tricks) is to say something like: git rebase -i <starting-point> ("-i" is short for "--interactive") where the starting point is just where you want to start your work. It might ...
Jul 17, 12:12 pm 2008
Andi Kleen
Re: Please pull ACPI updates
Ok I can do that one separately. I think my main problem was that it seemed so painful to change old commits and I ended up accumulating ugly reverts and incremental changes, but perhaps I just need to do better frontend scripts to make Hmm, perhaps I'm thick, but for me the only difference seems to be that the submitter does the merge that you would do (and safes himself a yelling at if it doesn't build or crashes at boot or similar...). In both cases there's a "untested in that ...
Jul 17, 9:23 am 2008
Andi Kleen
Re: Please pull ACPI updates
Ok I understand this applies to your tree because you have lots of direct users. And also people tend to only submit patches to you which are relatively well tested already and don't really do "raw development" in your tree. But for people lower down the food chain that's not necessarily the case. They usually only get some testing through -mm/linux-next and perhaps occasionally for individual patches posted to verify bugs. They tend to not have many people directly pulling their stuff (and ...
Jul 17, 1:34 pm 2008
Harvey Harrison
Re: Please pull ACPI updates
git rebase --interactive sounds like exactly what you are asking for. Harvey --
Jul 17, 12:12 pm 2008
Andi Kleen
Re: Please pull ACPI updates
The issue I worry about is it hitting between changes and their fixup. e.g. for example if I find that specific change doesn't compile in some special configuration then I amend it to fix that. Alternatively I could put in a fixup commit afterwards, but then if someone did bisect and the bisect hit inbetween the change and the fixup they might end up with a tree that doesn't compile. -Andi --
Jul 17, 1:14 pm 2008
Linus Torvalds
Re: Please pull ACPI updates
No. "git bisect" is perfetly able to handle merges. They are _fine_. The problem with rebasing is that it *changes* something that was already tested (and possibly merged into somebody elses tree) into SOMETHING ELSE. And that means that a large portion of the previous testing is basically thrown away. In particular, if something worked for somebody before, it also removes the "known good state" from a bisection standpoint, so rebasing actually makes things _harder_ to bisect - ...
Jul 17, 1:01 pm 2008
Linus Torvalds
Re: Please pull ACPI updates
Btw, you don't really have to have a lot of them. When it comes to ACPI in particular, I would really prefer to see at least the ACPICA stuff in a separate topic branch. It comes in from a different source, it's maintained separately, and when it causes problems(*) it ends up usually being handled differently too. Len additionally split things like bugzilla entries up into individual topics, and that was really nice to see when merging, but I have to say that it was also "above and ...
Jul 17, 8:47 am 2008
Ray Lee
Re: Please pull ACPI updates
Because sometimes merges are non-trivial. If you roll that merge conflict resolution back into the original patch, then the patch is now different. And in all these rebasings, who's to say there won't be a typo that accidentally changes the original patch that has had more Surely you agree that more testing is better? A rebased patch has had Andi, no offense was intended here. I'm just asking you to walk If you rebase, you're creating new patches that have less testing than the originals. ...
Jul 17, 1:11 pm 2008
Thomas Gleixner
[PATCH] Revert duplicate "dock: bay: Don't call acpi_wal ...
It's not only about destroying work and history, it can be worse than that. For example look at commits: 816c2eda3ce8fa7eb62f22e01e2ec7a3f7d677c0 (merged between 2.6.26-rc8 and -rc9) and cc7e51666d82aedfd6b9a033ca1a10d71c21f1ca (merged now) The export to quilt and the lazy default fuzz setting of quilt added aside of Andi's Signed-off-by the following gem: commit cc7e51666d82aedfd6b9a033ca1a10d71c21f1ca Author: Len Brown <len.brown@intel.com> Date: Tue Jun 24 22:57:12 2008 -0400 ...
Jul 17, 4:11 pm 2008
Linus Torvalds
Re: Please pull ACPI updates
One final note on this: the above is obviously not a problem for simple code that only really does one thing, and in particular for code that you wrote yourself. Moving your own commits around to make them make more sense - or splitting them up etc - is often a _good_ thing, even if it obviously does change history. So using rebase to clean up and simplify and/or fix up stupid ordering issues is good, and "git rebase -i" is actually really good for this thing. No, the problems ...
Jul 17, 1:28 pm 2008
Linus Torvalds
Re: Please pull ACPI updates
Oh, and before anybody goes any further with this: it's a very convenient feature, but it _is_ still technically nothing but a very nice interface to cherry-picking and rebasing history. So all the caveats about _not_ doing this with public history that others have already seen and possibly merged are still in place. That part doesn't change at all. So it's great to do with private changes to clean them up before publicizing them, or possibly with branches that you have explicitly ...
Jul 17, 12:16 pm 2008
Linus Torvalds
Re: Please pull ACPI updates
Well, I haven't actually seen Len's original tree, so maybe the stuff Andi pushed was just the stuff he had queued up independently. I guess I Len wrote it up at one point, but I can't for the life of me remember where. He's not the onyl one to ask, though - Ingo and Thomas seem to have picked up topic branches pretty well (I had some issues with a couple of the topics, but they weren't fundamental and the major one was probably because Ingo tried a bit too hard to make sure that ...
Jul 16, 5:32 pm 2008
J. Bruce Fields
Re: Please pull ACPI updates
Linus's answer (with rebase -i) is probably better, but my habit is to Instead of the above three steps, you can do just: $ edit At this point I do git rebase --onto HEAD old-sha1 name-of-branch-to-rebase (where old-sha1 is the name of the commit we just replaced, which I usually cut-n-paste out of gitk). That rebases the commits in the range old-sha1...name-of-branch-to-rebase onto the new HEAD commit that you That works too. --b. --
Jul 17, 2:15 pm 2008
Andi Kleen
Re: Please pull ACPI updates
Sounds like a nice feature. Thanks for the pointer. -Andi --
Jul 17, 12:50 pm 2008
Andi Kleen
Re: Please pull ACPI updates
I went back to quilt because the topic branches didn't really My plan was to keep everything in quilt and just regenerate for the pull. Please let me know if it's now not allowed anymore to use quilt. -Andi --
Jul 16, 11:40 pm 2008
Linus Torvalds
Re: Please pull ACPI updates
And Andi, before this goes any further, I'd like to say that (a) no, I don't hate you and (b) sorry in advance and in retrospect for my obviously abrasive personality and just being harsh. In particular, this is something that I have gone through with a _lot_ of maintainers. So you don't need to feel bad about it. Ingo and Thomas obviously did the very same thing not that long ago. And Davem had the same issue in the networking tree - most of the times when I pulled, I could tell ...
Jul 17, 9:02 am 2008
Andi Kleen
Re: Please pull ACPI updates
Hmm, but if you're dependent ACPI needs to go in first anyways, doesn't it? I don't think the ACPI tree is dependent on PCI at least. Or at least I didn't notice any problems in this area. -Andi --
Jul 16, 11:47 pm 2008
Lennart Sorensen
Re: [PATCH] : A better approach to compute int_sqrt in l ...
This line overflows while the result is good if changed to: if(((unsigned long long)m * (unsigned long long)m) > (unsigned long long)x) -- Len Sorensen --
Jul 17, 11:00 am 2008
Vadim Lobanov
Re: [PATCH] : A better approach to compute int_sqrt in l ...
Actually, the old version has zero division operators; those are simply right-shifts. -- Vadim Lobanov --
Jul 16, 9:08 pm 2008
Peter Zijlstra
Re: [PATCH] : A better approach to compute int_sqrt in l ...
As Lennart has said, gcc is smart enough to transform a division by a fs/nfs/write.c is init code mm/page_alloc.c is also init code mm/oom_kill.c isn't a hot path which leaves the fbmon case, which after a quick peek is setup code, so not a hot path either. So while that doesn't preclude us from changing it if you can indeed show its a better implementation, its not on anybodies hit-list. --
Jul 17, 11:26 am 2008
Lennart Sorensen
Re: [PATCH] : A better approach to compute int_sqrt in l ...
So so far the line: if((m * m) > x) overflows easily in which case the result is wrong. Also at least on my Athlon 2500, this new algorithm takes 3.5 times longer than the old one to get result when doing all square roots from 0 to 200000000, which is no improvement. -- Len Sorensen --
Jul 17, 11:10 am 2008
H. Peter Anvin
Re: [PATCH] x86: do not grow initial process stack so much
They will fault in the kernel, but only to fill the page tables, so it would cut down on latency. I do *NOT* believe we should make this an x86-only change. If it should be architecture-dependent I'd rather find the architectures that do need it. However, before changing this I really want to see some of the history about why it's that way in the first place. -hpa --
Jul 17, 4:12 pm 2008
Valdis.Kletnieks
Re: GPL version 4
Any mathematician worth their salt will point out you have that bass-ackwards. infinity means there is *always* one more.
Jul 17, 2:24 pm 2008
Alexandre Oliva
Re: GPL version 4
You can do that. There are lots of commercial products containing You are mistaken in several levels. 1. Disrespecting others' freedoms is not a matter of freedom, it's a matter of power. 2. Nothing in the GPL prevents you from doing any of this. If there is something that prevents you from doing this, it's copyright law. You won't find prohibitions in the GPL. 3. If you're unable to combine third-party GPL-incompatible software with GPL software, it's because the third party ...
Jul 17, 4:21 am 2008
Kasper Sandberg
Re: GPL version 4
So you, as a liberated computer user, would like to, for business Oh wait but thats not all, you expect these liberal computer users to give you the chains which will then be used to hold them.. Oh and btw, for business strategic reasons, i now need to clean up my keyboard due to an unfortunate drink accident involving me splurting out --
Jul 16, 7:12 pm 2008
linux-os (Dick Johnson)
Re: GPL version 4
Nah. Should be GPL V-infinity That way there won't be any more. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ **************************************************************** The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is ...
Jul 17, 2:17 pm 2008
Rene Herman
Re: unused Kconfig vars under drivers/
On 16-07-08 22:41, Robert P. J. Day wrote: [ snip ] FWIW, ">" is not a good line prefix and several of them are worse. Some mailers show it as equally many levels of quoted reply. Rene. --
Jul 16, 8:27 pm 2008
Robert P. J. Day
Re: unused Kconfig vars under drivers/
good point. i'll change that. rday -- ======================================================================== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA ======================================================================== --
Jul 17, 12:30 am 2008
Herbert Xu
Re: [PATCH] prng; bring prng into better alignment with ...
We can now kill the iv parameter too. Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --
Jul 17, 12:48 am 2008
Neil Horman
Re: [PATCH] prng; bring prng into better alignment with ...
Yeah, I was trying to decide if I should remove that or not, in the event we wanted to support alternate [blk]ciphers in the future for the cprng. As I think about it, I don't think its a big deal to nix. I'll get rid of it shortly. Thanks -- /*************************************************** *Neil Horman *nhorman@tuxdriver.com *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***************************************************/ --
Jul 17, 4:04 am 2008
Herbert Xu
Re: [PATCH] prng: fix a few misc bugs in prng
Please make the length a parameter instead as it's much more The dreaded firmware makes a comeback :) Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --
Jul 17, 12:46 am 2008
Neil Horman
Re: [PATCH] prng: fix a few misc bugs in prng
Doh! Ment to remove that! My bad :) Thanks -- /*************************************************** *Neil Horman *nhorman@tuxdriver.com *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***************************************************/ --
Jul 17, 4:02 am 2008
Harvey Harrison
Re: [PATCH] dlm: sparse endian annotations
I am curious though, in the general case of taking stuff off the wire and doing work on it in-place. Would you suggest two structs for things like this, one in cpu-order and one with the endian annotations, then the one place where you receive can do appropriate endian conversion using a pointer to a wire-endian struct and the rest of the code just uses the cpu-endian struct everywhere? Just a general design question. In the DLM case, these util functions are only used in 1-2 places ...
Jul 17, 1:00 pm 2008
Jeremy Fitzhardinge
Re: Large increase in context switch rate
OK, just to be sure we're talking about the same thing, is kernbench displaying the context switch *rate*, or the total number of context switches during the build? Peter is looking at vmstat, which is showing cs/sec. J --
Jul 17, 8:45 am 2008
Jeremy Fitzhardinge
Re: Large increase in context switch rate
No, it doesn't seem to be. A CONFIG_PARAVIRT kernel running on bare hardware shows the same context switch rate. Merely turning CONFIG_PARAVIRT on should have no effect on context switch rate (though, Alex, it would be worth double-checking, just to be sure). J --
Jul 17, 8:02 am 2008
Alex Nixon (Intern)
RE: Large increase in context switch rate
I'm talking about total number of context switches - kernbench gets it from time -f "%c" make -j 4 Dividing through it gives me a rate of around 250/sec (vs Peters 3000), but I've set CONFIG_HZ=100 (vs Peters 1000), so they don't wildly conflict. Well spotted :-) - Alex -----Original Message----- From: Jeremy Fitzhardinge [mailto:jeremy@goop.org] Sent: 17 July 2008 16:45 To: Alex Nixon (Intern) Cc: Peter Zijlstra; Ingo Molnar; Linux Kernel Mailing List; Ian Campbell Subject: ...
Jul 17, 9:04 am 2008
Andi Kleen
Re: Large increase in context switch rate
If it's that easily reproducible you could just bisect it? -Andi --
Jul 17, 2:43 pm 2008
Alex Nixon (Intern)
RE: Large increase in context switch rate
Yeah I've checked - the number of context switches seems to be around 60k regardless of whether CONFIG_PARAVIRT is switched on, and regardless of whether it's running in domu or native (-j4 on dual core) -----Original Message----- From: Jeremy Fitzhardinge [mailto:jeremy@goop.org] Sent: 17 July 2008 16:03 To: Peter Zijlstra Cc: Ingo Molnar; Linux Kernel Mailing List; Alex Nixon (Intern); Ian Campbell Subject: Re: Large increase in context switch rate No, it doesn't seem to be. A ...
Jul 17, 8:14 am 2008
Peter Zijlstra
RE: Large increase in context switch rate
I'm seeing: procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ r b swpd free buff cache si so bi bo in cs us sy id wa st 4 0 0 1148916 120340 472040 0 0 0 1912 2225 3662 78 22 0 0 0 4 0 0 1130192 120556 489844 0 0 0 1974 2220 3461 77 22 0 0 0 doing make -j4 This is on x86_64 SMP PREEMPT HZ=1000 !PARAVIRT (Linus' tree as of somewhere earlier today) --
Jul 17, 8:21 am 2008
Peter Zijlstra
Re: Large increase in context switch rate
Is this specific to Xen?, as a native kernel doesn't do more than ~3k cs/s with make -j3 on my dual core. --
Jul 17, 2:17 am 2008
Jeremy Fitzhardinge
Re: Large increase in context switch rate
(Don't top-post.) OK, but that still doesn't account for the relatively large increase from 2.6.18 -> 2.6.26. You're using HZ=100 in both cases, I presume. The other variable is NOHZ and highres timers. You could try turning those off in 2.6.26. Also, CONFIG_PREEMPT could well make a difference. 2.6.18-xen doesn't support CONFIG_PREEMPT at all, but pvops(-xen) does. J --
Jul 17, 9:11 am 2008
Kyle McMartin
Re: 64bit kernel not booting with CONFIG_PRINTK_TIME=y
How about if you boot with printk_time=0, whilst CONFIG_PRINTK_TIME=y? r, Kyle --
Jul 17, 11:33 am 2008
Pekka Enberg
Re: SLUB: simplify re on_each_cpu()
Hi Robin, I think it's actually you who is looking at an older tree. However, while double-checking this, I noticed that for UP, on_each_cpu() enables interrupts unconditionally with local_irq_enable() whereas the call while the old code in SLUB did a local_irq_restore() that preserves the irq mask. Looking at the callers of flush_all() in mm/slub.c, the change looks okay, but it's still bit strange on_each_cpu() works that way on UP. Pekka --
Jul 17, 5:26 am 2008
Robin Holt
Re: SLUB: simplify re on_each_cpu()
I did a git-checkout of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git which got me commit id 33af79d12e0fa25545d49e86afc67ea8ad5f2f40 and looked at include/linux/smp.h line 123. It has: #define on_each_cpu(func,info,wait) \ ({ \ local_irq_disable(); \ func(info); \ local_irq_enable(); \ 0; ...
Jul 17, 5:39 am 2008
Robin Holt
Re: SLUB: simplify re on_each_cpu()
It looks to me like on_each_cpu is a #define for !SMP. Are you certain of the need for this change? Are you looking at a different tree than Linus'? Thanks, --
Jul 17, 4:38 am 2008
Vegard Nossum
Re: SLUB: simplify re on_each_cpu()
That's the function call right there :-) Vegard -- "The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's own creation." -- E. W. Dijkstra, EWD1036 --
Jul 17, 5:55 am 2008
Ondrej Zajicek
Re: kernel oops with framebuffer device vt8623fb
I am sorry for mistake, here is a patch for 2.6.26 fixing the bug: Signed-off-by: Ondrej Zajicek <santiago@crfreenet.org> diff -uprN -X linux-2.6.26-orig/Documentation/dontdiff linux-2.6.26-orig/drivers/video/arkfb.c linux-2.6.26/drivers/video/arkfb.c --- linux-2.6.26-orig/drivers/video/arkfb.c 2008-07-13 23:51:29.000000000 +0200 +++ linux-2.6.26/drivers/video/arkfb.c 2008-07-16 22:56:34.000000000 +0200 @@ -958,20 +958,20 @@ static int __devinit ark_pci_probe(struc /* Prepare PCI device ...
Jul 16, 6:39 pm 2008
MadLoisae@gmx.net
Re: kernel oops with framebuffer device vt8623fb
Hi! this patch fixed my problem completly. thanks a lot! kind regards, Alois --
Jul 17, 4:23 am 2008
Paul Mundt
Re: [2.6 patch] fix sh ptep_get_and_clear breakage
Magnus already fixed this for pg-sh4, but the SH7705 implementation was overlooked, so I applied your patch there. Thanks. --
Jul 16, 10:54 pm 2008
David Miller
Re: [PATCH] net/ipv4/tcp.c: Fix use of PULLHUP instead o ...
From: Will Newton <will.newton@imgtec.com> Applied, thanks. --
Jul 16, 8:13 pm 2008
Oleg Nesterov
Re: [PATCH] posix-timers: Do not modify an already queue ...
Indeed! Thanks Mark. Agreed, this one looks worse. I forgot (if ever knew ;) this code completely, but can't we make a simpler fix? posix_timer_event() can check list_empty() lockless, posix_timer_event() { if (!list_emtpy(sigq->list)) return 0; ... fill and send ->sigq... } When the signal will be dequeued, schedule_next_timer() should afaics set ->it_overrun_last which is copied to ->si_overrun then. Or we can increment timr->it_overrun before return if I misread ...
Jul 17, 6:55 am 2008
Mark McLoughlin
Re: [PATCH] posix-timers: Do not modify an already queue ...
Hi Oleg, The app can reload the timer itself before the signal has been dequeued Yes, this case definitely occurs. Now that I know what's going on, I've finally managed to extract a standalone test case. Try this: http://markmc.fedorapeople.org/test-posix-timer-race.c Yeah, I had considered that, but it's a tad more invasive. See below. I mainly don't like this patch because we may lock the sighand from one thread's task_struct and then unlock it via the group leader's ...
Jul 17, 4:08 am 2008
Tino Keitel
Re: linux-next: Tree for July 16
On Wed, Jul 16, 2008 at 20:15:50 +0200, Takashi Iwai wrote: This is also mentioned in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=490110, but I don't know if the page contains a solution. Regards, Tino --
Jul 17, 12:17 am 2008
Richard Kennedy
Re: [PATCH][RFC] slub: increasing order reduces memory u ...
Mel, Thanks for the info & the script. I'll give it a try & see what we get. Richard --
Jul 17, 2:48 am 2008
Wei Yongjun
Re: [PATCH net-next] atl1e: Atheros L1E Gigabit Ethernet ...
You should use Thunderbird to send you patchs. And check it by send the mail to yourself. Regards. Wei Yongjun --
Jul 16, 8:30 pm 2008
Jie Yang
RE: [PATCH net-next] atl1e: Atheros L1E Gigabit Ethernet ...
On Thursday, July 17, 2008 12:36 AM Hi, Roland I used outlook to send these patches, can you give me some aderise on how to send non-mangled patches. Best wishes jie --
Jul 16, 7:47 pm 2008
Stephen Hemminger
Re: [PATCH net-next] atl1e: Atheros L1E Gigabit Ethernet ...
On Thu, 17 Jul 2008 11:30:27 +0800 Alternatively, use a text file as attachment. It doesn't work as well but then it comes through unmangled. --
Jul 16, 8:34 pm 2008
Randy Dunlap
Re: [PATCH -mm v2 3/3] sysv ipc: use auto_msgmnb to desa ...
--- ~Randy Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA http://linuxplumbersconf.org/ --
Jul 17, 2:14 pm 2008
Randy Dunlap
Re: [PATCH 07/13] kmemcheck: add the kmemcheck core
The rest of the comments/documentation ... ;) --- ~Randy Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA http://linuxplumbersconf.org/ --
Jul 17, 4:32 pm 2008
Randy Dunlap
Re: [PATCH 07/13] kmemcheck: add the kmemcheck core
We would prefer to have kernel-doc on exported functions... --- ~Randy Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA http://linuxplumbersconf.org/ --
Jul 17, 2:49 pm 2008
Vegard Nossum
Re: [PATCH 07/13] kmemcheck: add the kmemcheck core
Uhm, probably relative to my previous patch? About the date, I have no But it's such a nice convention! How can we differentiate between Oops. I will not add a kernel-doc, but I will add an explanation. This function is a drop-in replacement for memset, and the reason for the EXPORT is that the real memset() in fact is just a macro that calls this function. And memset is needed in modules. This function should not actually have any users beside the memset() in x86 headers. Thanks for ...
Jul 17, 4:23 pm 2008
Linus Torvalds
Re: [PATCH] elf loader support for auxvec base platform string
Gaah. Generally we don't, but you're right to ask. The ELF loading keeps on accumulating these things, and I'm not sure we have the right process for things like this. They're all individually small and insignificant, and they are all individually never going away and making the ELF loader messier and messier. I dunno. Linus --
Jul 17, 9:10 am 2008
John Reiser
Re: [PATCH v3] elf loader support for auxvec base platfo ...
[snip] It seems to me that most of the patch conflicts are mechanical and could be merged mechanically. However I believe that the documentation change to this comment is important: ----- I scratched my head for a while to figure out that AT_NOTELF also was a subtraction as far as AT_VECTOR_SIZE_BASE was concerned. -- John Reiser, jreiser@BitWagon.com --
Jul 17, 4:35 pm 2008
Nathan Lynch
[PATCH v3] elf loader support for auxvec base platform string
Some IBM POWER-based platforms have the ability to run in a mode which mostly appears to the OS as a different processor from the actual hardware. For example, a Power6 system may appear to be a Power5+, which makes the AT_PLATFORM value "power5+". This means that programs are restricted to the ISA supported by Power5+; Power6-specific instructions are treated as illegal. However, some applications (virtual machines, optimized libraries) can benefit from knowledge of the underlying CPU model. ...
Jul 17, 3:19 pm 2008
Andrew Morton
Re: [PATCH] elf loader support for auxvec base platform string
It tends to happen. People often don't notice unless it a) crashes or b) spits warnings or c) screws up my tree or d) all the above plus Please add a comment which explains what this is. Please also add a comment telling the world in which header file the architecture *must* define this macro and then ensure that that header is From my reading, this change will result in no additional code generation on non-powerpc architectures. This is good. If poss, could you please verify that ...
Jul 17, 12:09 am 2008
Andrew Morton
Re: [PATCH v3] elf loader support for auxvec base platfo ...
On Thu, 17 Jul 2008 17:19:32 -0500 OK. But it conflicts directly with the already-queued execve-filename-document-and-export-via-auxiliary-vector.patch (which various potential reviewers blithely deleted - don't come complaining to me!): From: John Reiser <jreiser@BitWagon.com> The Linux kernel puts the filename argument of execve() into the new address space. Many developers are surprised to learn this. Those who know and could use it, object "But it's not documented." Those who ...
Jul 17, 3:42 pm 2008
Nathan Lynch
Re: [PATCH] elf loader support for auxvec base platform string
FWIW, I was initially reluctant to do it this way, but the ELF aux vector seems to be the only reasonable mechanism for getting this information to all interested users. And the only reason the patch touches the generic code is because we have to copy a string to userspace (just like AT_PLATFORM). Otherwise it could be done in powerpc's ARCH_DLINFO. --
Jul 17, 12:35 pm 2008
Nathan Lynch
Re: [PATCH] elf loader support for auxvec base platform string
That was the intent, yes. However: $ scripts/bloat-o-meter vmlinux-x86-{before,after} add/remove: 0/0 grow/shrink: 2/0 up/down: 18/0 (18) function old new delta init_mm 784 800 +16 load_elf_binary 11946 11948 +2 (x86_64_defconfig, gcc 4.2.3) The init_mm/mm_struct bloat is expected (although I'd like to avoid that), but evidently it has some small effect on ...
Jul 17, 10:39 am 2008
Benjamin Herrenschmidt
Re: [PATCH] elf loader support for auxvec base platform string
Hi Linus, Andrew ! Should I seek somebody's ack before merging a patch like the one below ? I'm a bit reluctant to merge via the powerpc.git tree some changes to generic files without at least an ack from somebody else :-) There have been some debate on whether this AT_BASE_PLATFORM is the right approach, though I haven't seen them reach any useful conclusion and our toolchain people internally are screaming for it... Cheers, Ben. --
Jul 16, 11:35 pm 2008
Rik van Riel
Re: madvise(2) MADV_SEQUENTIAL behavior
On Thu, 17 Jul 2008 16:14:29 +1000 Do you have any tests in mind that we could use to decide whether the patch I posted Tuesday would do a decent job at protecting frequently used data from streaming data? http://lkml.org/lkml/2008/7/15/465 -- All Rights Reversed --
Jul 17, 7:21 am 2008
Rik van Riel
Re: madvise(2) MADV_SEQUENTIAL behavior
On Wed, 16 Jul 2008 17:05:14 -0400 You want to check the MADV_SEQUENTIAL hint at pageout time and Only if we ignore the referenced bit. Which I guess we can do. -- All Rights Reversed --
Jul 17, 7:20 am 2008
Nick Piggin
Re: madvise(2) MADV_SEQUENTIAL behavior
It's far far easier to tell the kernel "I am no longer using these pages" than to say "I will not use these pages sometime in the future after I have used them". The former can be done synchronously and with a much higher efficiency than it takes to scan through LRU lists to figure this out. We should be using the SEQUENTIAL to open up readahead windows, and ask The slow desktop in the morning should not happen even without such a call, because the kernel should not throw out frequently ...
Jul 16, 11:14 pm 2008
Peter Zijlstra
Re: madvise(2) MADV_SEQUENTIAL behavior
Sorry can't resist... Is there any other kind? :-) --
Jul 17, 11:09 am 2008
Eric Rannaud
Re: madvise(2) MADV_SEQUENTIAL behavior
This approach, instead of invalidating the pages right away would provide a middle ground: a way to tell the kernel "these pages are not too important". Whereas if MADV_SEQUENTIAL just invalidates the pages once per megabyte (say), then it's only doing what is already possible using MADV_DONTNEED ("drop this pages now"). It would automate the process, but it would not provide a more subtle hint, which could be quite useful. As I see it, there are two basic concepts here: - no_reuse (like ...
Jul 16, 5:01 pm 2008
Chris Snook
Re: madvise(2) MADV_SEQUENTIAL behavior
1) start up a memory-hogging Java app 2) run a full-system backup If it works well, the Java app shouldn't slow down much. -- Chris --
Jul 17, 11:04 am 2008
Mathieu Desnoyers
Re: [patch 09/17] LTTng instrumentation - filemap
I never pretended anything like that. Actually, that's what the "immediate values" are for : they allow to patch load immediate value instead of a memory read to decrease d-cache impact. They now allow to patch a jump instead of the memory read/immediate value read + test + conditional branch to skip the function call with fairly minimal impact. I agree with you that eating precious d-cache and jump prediction buffer entries can eventually slow down the system. But this will be _hard_ to show ...
Jul 17, 12:02 am 2008
Nick Piggin
Re: [patch 09/17] LTTng instrumentation - filemap
BTW. this sort of test is practically useless to measure overhead. If a modern CPU is executing out of primed insn/data and branch prediction cache, then yes this sort of thing is pretty well free. I see *real* workloads that have got continually and incrementally slower eg from 2.6.5 to 2.6.20+ as "features" get added. Surprisingly, none of them ever showed up individually on a microbenchmark. OK, for this case if you can configure it out, I guess that's fine. But let's not pretend that ...
Jul 16, 11:25 pm 2008
Nick Piggin
Re: [patch 09/17] LTTng instrumentation - filemap
OK but saying "there is no detectable impact when running hackbench" is I'm not saying you have to reproduce it (although Intel's Oracle OLTP benchmark is very sensitive to that kind of thing and schedule() is near the top). But just acknowledge that it adds some cost. OK you're one of the few people really trying hard to count every cycle so I don't mean to pick on this code in particular. --
Jul 17, 12:11 am 2008
Alexey Starikovskiy Jul 17, 5:30 am 2008
Henrique de Moraes H ...
Re: [PATCH] acpi: Avoid dropping rapid hotkey events (or ...
Well, in that case, it would be best to tack a Cc: stable@kernel.org git footer to it right away, I think. IMHO, it would also be nice if the commit message made it more clear that the issue it solves can affect much more serious ACPI events than just hot key presses. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh --
Jul 17, 9:26 am 2008
Alexey Starikovskiy
Re: [PATCH] acpi: Avoid dropping rapid hotkey events (or ...
Hi Alan, Thanks for the patch, ACK. Regards, Alex. --
Jul 17, 4:49 am 2008
Alan Jenkins
Re: [PATCH] acpi: Avoid dropping rapid hotkey events (or ...
Vacuously so. My patch still applies, but #10919 makes it obsolete. My patch fixed a bug that shows up in polling mode. #10919 kills polling mode. I've tested v2.6.26 + #10919 and it works fine (except for spamming the kernel log - please read my Bugzilla comment). It appears that interrupt mode suffered from a race which is very similar to my original problem. If two GPE interrupts arrive before the workqueue runs, then the second interrupt will be ignored ...
Jul 17, 9:02 am 2008
Alan Jenkins
Re: [PATCH] acpi: Avoid dropping rapid hotkey events (or ...
OK, I'm happy now. However, I'm now worried that I broke the semantics for EC_FLAGS_QUERY_PENDING. In my patch it gets cleared after the first query, even though I'm running queries in a loop until nothing is left. It doesn't cause a problem in my patch, but it's unclean and might cause confusion later on. It'd be better to clear it after the loop has completed. Can I fix my patch? If you ACK the new code below, then I'll resend with a proper changelog, S-o-B, CC's from the -mm mail ...
Jul 17, 11:55 am 2008
Alexey Starikovskiy
Re: [PATCH] acpi: Avoid dropping rapid hotkey events (or ...
Not so, there are two polls in ec.c, first is poll for change in status register, which gave the name to the mode, and still exists; the other is for event in embedded controller, which was introduced to properly solve #9998, and part of The notion of queue in embedded controller is new, it was never mentioned in ACPI spec, so the driver was written with assumption that new query interrupt should not arrive before we service previous one. There is even a chart in how interrupts I think, this is ...
Jul 17, 9:45 am 2008
Alan Jenkins
Re: [PATCH] acpi: Avoid dropping rapid hotkey events (or ...
Actually Alexey has another patch in bugzilla (#10919) which resolves this issue in a better way. It avoids polling altogether, which is good because it means you get events immediately. My laptop has backlight adjustment hotkeys with hardware autorepeat, so it looks really jerky with polling. So I think I should withdraw my patch and leave this to Alexey. I've tested his fix on my laptop and it works fine. It needs some more work though - e.g. at the moment it spams the kernel ...
Jul 17, 9:45 am 2008
Henrique de Moraes H ...
Re: [PATCH] acpi: Avoid dropping rapid hotkey events (or ...
We need to get ALL pending events from the EC, whether in polling mode or in interrupt mode (and we must make sure that we ARE going to queue any new interrupt before we stop checking for an empty pending event queue, otherwise there is a small window where a new event might get queued, and we are still masking the GPE and don't notice it). As long as the fix does that, it is all I care :-) -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the ...
Jul 17, 11:50 am 2008
Henrique de Moraes H ...
Re: [PATCH] acpi: Avoid dropping rapid hotkey events (or ...
This one fixes a potentially bad problem, since we could ignore more than -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh --
Jul 17, 5:13 am 2008
Alan Jenkins
Re: [PATCH] acpi: Avoid dropping rapid hotkey events (or ...
OK, I forgot about that. I need to do some reading on kernel programming, workqueues in particular, and redo my patch again. Sorry, Alexey! AFAICS there's still this (very) small window where events could be dropped. Alan --
Jul 17, 12:07 pm 2008
Alexey Starikovskiy Jul 17, 11:59 am 2008
Alexey Starikovskiy
Re: [PATCH] acpi: Avoid dropping rapid hotkey events (or ...
Hi Alan, Could you please test if your patch works with the last patch in #10919? Thanks, Alex. --
Jul 17, 7:35 am 2008
Greg KH
Re: [PATCH 1/7] dynamic debug v2 - infrastructure
For this reason alone, I see no reason why your patch should not be merged today. You don't need the other subsystems at this point in time in my opinion, it's benifit is huge already. Not to say that you shouldn't also go after these subsystems in your overall scheme here, but please, don't feel it should hold your code up at this point in time :) Because of that, do you want me to try to merge the basic infrastructure and dev_dbg() support through the driver-core tree? This code has ...
Jul 17, 3:32 pm 2008
Greg KH
Re: [PATCH 1/7] dynamic debug v2 - infrastructure
By virtue of this being in debugfs, we can change the user interface I like this as that is what a number of current modules do (usb-serial drivers), but you have to be careful about the module parameter namespace to not get collisions here with existing "debug" files. So for now, I recommend staying in debugfs, it makes more sense. thanks, greg k-h --
Jul 17, 4:35 pm 2008
Jason Baron
Re: [PATCH 1/7] dynamic debug v2 - infrastructure
I don't believe the follow-on patches include "<linux/dynamic_printk.h>". However, some of them do include a subsystem specific #include. For example, the cpufreq subsystem include, <linux/dynamic_debug_cpufreq.h>: +++ b/include/linux/dynamic_debug_cpufreq.h @@ -0,0 +1,8 @@ +#define DYNAMIC_DEBUG_NUM_FLAGS "3" +#define DYNAMIC_DEBUG_FLAG_NAMES "CPUFREQ_DEBUG_CORE,CPUFREQ_DEBUG_DRIVER,CPUFREQ_DEBUG_GOVERNOR" +#define DYNAMIC_DEBUG_TYPE "2" +#define DYNAMIC_DEBUG_MODNAME ...
Jul 17, 2:20 pm 2008
Greg KH
Re: [PATCH 1/7] dynamic debug v2 - infrastructure
In looking at your follow-on patches, where you add this to subsystems, it seems that you have to add a lot of #include <linux/dynamic_printk.h> lines. And in looking at this modification to device.h, I think lots of the kernel should break, but you are getting it "for free" by including the .h file within kernel.h. Why not also include it here in device.h? Also, with this change, code that is already using dev_dbg() today is instantly converted over to this logic now, right? Anyway, ...
Jul 17, 12:01 am 2008
Dominik Brodowski
Re: [PATCH 1/7] dynamic debug v2 - infrastructure
Hi, not to object to this statement, but: what about the user-visible interface? currently, it's based around one big debugfs file. What about doing <debugfs>/dynamic_printk/<module_name>/{enabled[,level][,flag][,modules]} instead, or even <sysfs>/module/<module_name>/debug/{enabled[,level][,flag]} For "shared" modules like cpufreq (only user so far, AFAICS), things might get a bit more interesting, but we found that out already in the other thread ;) Best ...
Jul 17, 3:56 pm 2008
Dominik Brodowski
Re: [PATCH 6/7] dynamic debug v2 - convert cpufreq
Seconded. Makes the cpufreq-related patch even smaller, for we won't have to touch all drivers. Makes sense, and we can discuss depending one thing on another later on. Looking forward to seeing this infrastructure merged. I guess it will help a lot. Best, Dominik --
Jul 17, 2:27 pm 2008
Greg KH
Re: [PATCH 6/7] dynamic debug v2 - convert cpufreq
kernel.h includes dynamic_debug.h right? Then why not just put the _cpufreq.h stuff in the current cpufreq.h file(s)? thanks, greg k-h --
Jul 17, 2:15 pm 2008
Dominik Brodowski
Re: [PATCH 6/7] dynamic debug v2 - convert cpufreq
<within all cpufreq drivers> #define DYNAMIC_DEBUG_CPU_FREQ 1 <dynamic_printk.h> #ifdef DYNAMIC_DEBUG_CPU_FREQ #define DYNAMIC_DEBUG_NUM_FLAGS "3" ... #else ... ... #endif or -- even better -- could we determine the definition of DYNAMIC_DEBUG_CPU_FREQ on the fly? It needs to be set to true for exactly all Not that much of a nuiseance, IMO. Or SELECT CONFIG_DYNAMIC_PRINTK_DEBUG when CONFIG_CPU_FREQ_DEBUG is enabled (if davej agrees ;) ) Best, Dominik --
Jul 17, 3:20 pm 2008
Jason Baron
Re: [PATCH 6/7] dynamic debug v2 - convert cpufreq
We could make CONFIG_CPU_FREQ_DEBUG force CONFIG_DYNAMIC_PRINTK_DEBUG to be on. However, i'm trying to allow CONFIG_CPU_FREQ_DEBUG to be turned on without enabling CONFIG_DYNAMIC_PRINTK_DEBUG. That's consistent with how i'm trying to do this patch series. That is, individual subsystems can turn their respective makes sense. thanks, -Jason diff --git a/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c b/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c index e2d870d..549edbd 100644 --- ...
Jul 17, 2:05 pm 2008
Jason Baron
Re: [PATCH 6/7] dynamic debug v2 - convert cpufreq
yes 1) cpufreq.h is included by other subsystems, and thus those other subsystems potentially have the wrong debugging information. 2) For the case where CONFIG_CPU_FREQ_DEBUG is set and CONFIG_DYNAMIC_PRINTK_DEBUG is not set i need to be able get the proper definition of 'dynamic_dbg_enabled()' out of dynamic_print.h (included by kernel.h). This proper definition is obtained by setting 'DEBUG', and thus i need to define this before the kernel.h include. We can solve #2 by defining ...
Jul 17, 2:46 pm 2008
Ingo Molnar
Re: [PATCH RESEND] xen: fix up config dependencies on PM
applied to tip/xen-64bit, thanks Jeremy. Ingo --
Jul 17, 10:25 am 2008
pageexec
Re: [stable] Linux 2.6.25.10
look at what went into 2.6.25.11 for example. it's a security fix. you do treat them differently: you include them in -stable to the exclusion of many other 'less important' fixes. read Documentation/stable_kernel_rules.txt for how you not treat all fixes as equal (it's not only security ones that anything that breaks the kernel's security model. privilege elevation always does. --
Jul 17, 12:59 am 2008
Mike Galbraith
Re: [stable] Linux 2.6.25.10
That world is not going to comply with your every whim should be perfectly clear by now. Please go spam some other list. P.S. You have a shift key. --
Jul 16, 8:43 pm 2008
Rafael C. de Almeida
Re: [stable] Linux 2.6.25.10
Hey, I have a crazy idea! What if they just mark all the bugs as a security bug (after all they all kinda are for some definition of security anyway)? That way people just apply all the patches and do not have to analyze anything, therefore not wasting their limited human resources at all! Linus' point is exactly that they shouldn't be treated differently, so you shouldn't allocate human resources to other bugs and just apply the security ones. If you want to convince someone you must tell us ...
Jul 17, 12:19 am 2008
Tziporet Koren
Re: [ofa-general] ***SPAM*** InfiniBand/RDMA merge plans ...
If someone is interested to get a FW that implement is please reply to me We should have such a FW next week Tziporet --
Jul 17, 2:03 am 2008
Jesse Barnes
Re: acpi based pci gap calculation - v3
Well it's hardly last minute given that the merge window only opened a couple of days ago... But beyond that, now that I've thought about it a bit more I'm not even sure the patch is really correct (though it works on my test machines). Shouldn't we be looking at _PRS not _CRS? And ideally we should try to find even more space, not less. This patch made one of my machines lose quite a bit of space: ... Allocating PCI resources starting at c0000000 (gap: ...
Jul 16, 5:03 pm 2008
Alok Kataria
Re: acpi based pci gap calculation - v3
Hi Jesse, IMO, the current resource allocations will give us a better idea of which region is free. Besides, from what i read PRS is optional and not all BIOS's may export Yep, we should try to find more space but we should also make sure that this space doesn't clash with any other resource. As explained in my first mail while posting v1 of these patches, the kernel ignores the memory hotplug range while calculating this gap for PCI, and consequently these regions collide. With this ...
Jul 17, 2:31 pm 2008
Masami Hiramatsu
Re: [RFC] systemtap: begin the process of using proper k ...
Sure, inlined functions are embedded in a caller function, so the closest function is the correct owner. However, I meant local-scope functions can have same name if they are defined in different scope. And even though, both of them are shown in kallsyms. This mean, you can see the functions which have real different existence but have same symbol. Would you mean systemtap should not probe those name-conflicted Hmm, here is what I got with your patch; $ stap --kelf -e 'probe ...
Jul 16, 5:05 pm 2008
James Bottomley
Re: [RFC] systemtap: begin the process of using proper k ...
OK, thought about it. There seem to be two possible solutions 1. Get systemtap always to offset from non-static functions. This will use the standard linker to ensure uniqueness (a module qualifier will still need to be added to the struct kprobe for lookup, since modules can duplicate unexported kernel symbols). 2. Add the filename as a discriminator for duplicate symbols in the kallsyms program (would still need module qualifier). This is ...
Jul 17, 7:18 am 2008
James Bottomley
Re: [RFC] systemtap: begin the process of using proper k ...
Just by way of illustration, this is systemtap fixed up according to suggestion number 1. You can see now using your test case that we get: # probes kernel.function("do_open@fs/block_dev.c:929") /* pc=<lookup_bdev+0x90> */ /* <- kernel.function("do_open") */ kernel.function("do_open@fs/nfsctl.c:24") /* pc=<sys_nfsservctl+0x6a> */ /* <- kernel.function("do_open") */ kernel.function("do_open@ipc/mqueue.c:642") /* pc=<sys_mq_unlink+0x130> */ /* <- kernel.function("do_open") */ James From: ...
Jul 17, 9:58 am 2008
James Bottomley
Re: [RFC] systemtap: begin the process of using proper k ...
You mean this particular problem: hobholes:/home/jejb/git/BUILD-2.6# grep do_open /proc/kallsyms c01af160 t do_open c01d5d40 t do_open It's certainly a material defect in the current API. I'll think about You're welcome. James --
Jul 16, 6:49 pm 2008
Masami Hiramatsu
Re: [RFC] systemtap: begin the process of using proper k ...
Hi James, Thank you for updating the patch. Unfortunately, I found another scenario; if someone make a module which has EXPORT_SYMBOL(do_open), it's a non-static function. but there are other static version do_open in kallsyms. Here, I tested it and got below; $ stap --kelf -e 'probe module("test").function("do_open"){}' -p2 # probes module("test").function("do_open@?") /* pc=<do_open+0x0> */ /* <- module("test").function("do_open") */ And I think similar issue will occur even if it is ...
Jul 17, 2:36 pm 2008
James Bottomley
Re: [RFC] systemtap: begin the process of using proper k ...
Actually, no. This is only a module problem ... it's triggered by the fact that the module namespace is different from the kernel's global namespace. To get around this, I think the actual module (or null for Actually not entirely, no, if we go for only global symbols. The compiler is entitled to spit out a section even for a static function as long as it has a real body. If the module loader insterts stubs then I'll cook up a patch and run it by lkml to try to gauge the ...
Jul 17, 3:03 pm 2008
Will Newton
Re: [PATCH 00/11] fsl_usb2_udc: A number of bug fixes an ...
It's actually one of these: http://www.frontier-silicon.com/products/chips/chorus2.htm Support for which is not yet in the mainline kernel. Kconfig updates should follow when the SoC support is merged but I hope these patches --
Jul 17, 2:47 am 2008
Li Yang
RE: [PATCH 00/11] fsl_usb2_udc: A number of bug fixes an ...
Thanks for the patches. Looks like they are ok, but I still need to test them later. What's the SoC you have tested with the driver? Maybe you could also update the Kconfig for that. --
Jul 17, 2:43 am 2008
Tomas Winkler
Re: [GIT PULL] MMC updates for 2.6.26
I take the blame on me. I've copied that file between OSes so it changed executable. It slipped from my attention Will also change my scripts as well. Tomas --
Jul 16, 11:38 pm 2008
Marcel Holtmann
Re: [GIT PULL] MMC updates for 2.6.26
I NAKed these patches and Tomas re-sent them, but it seems you picked the wrong ones from the mailing list. This mess always happens if a FAT filesystem is involved somehow :( Regards Marcel --
Jul 17, 5:04 am 2008
Andrew Morton
Re: [PATCH] remove old broken Cobalt LCD driver
On Tue, 15 Jul 2008 22:31:32 +0900 Why do we remove it, rather than unbreaking it? Did some other driver replace it? Does nobody need the driver any more? --
Jul 16, 5:16 pm 2008
Andrew Morton
Re: [PATCH] remove old broken Cobalt LCD driver
On Wed, 16 Jul 2008 17:16:40 -0700 doh. That's what I get for processing patches in reverse-time-order. So there's no point in retaining both the old driver and the new one for some period of time? --
Jul 16, 5:18 pm 2008
Yoichi Yuasa
Re: [PATCH] remove old broken Cobalt LCD driver
On Wed, 16 Jul 2008 17:18:18 -0700 The old driver was not maintained for a long time and did not work(also it was not used). It was there for someone might fix it. But all function(LED, MTD, Framebuffer) replced by new drivers. It's time to go. Yoichi --
Jul 16, 6:31 pm 2008
Max Krasnyansky
Re: [PATCH] cpu hotplug, sched: Introduce cpu_active_map ...
Yes. btw they are definitely related, because the reason we were blowing away the domains is to avoid "migration to a dead cpu". ie We were relying on the None at this point :). I need to run right now and will try to look at this later today. My knowledge of the internal sched structs is definitely lacking so I need to look at the rq->rd thing to have and opinion. Thanx Max --
Jul 17, 11:52 am 2008
Max Krasnyansky
Re: [PATCH] cpu hotplug, sched: Introduce cpu_active_map ...
Here is the link to the original thread http://lkml.org/lkml/2008/7/11/328 And here is where Linus explained the idea http://lkml.org/lkml/2008/7/12/137 I'll reply to the rest of your email tomorrow (can't keep my yes open any longer :)). Max --
Jul 17, 12:16 am 2008
Gregory Haskins
Re: [PATCH] cpu hotplug, sched: Introduce cpu_active_map ...
>>> On Thu, Jul 17, 2008 at 2:52 PM, in message <487F9509.9050802@qualcomm.com>, Sounds good, Max. Thanks! -Greg --
Jul 17, 12:46 pm 2008
Gregory Haskins
Re: [PATCH] cpu hotplug, sched: Introduce cpu_active_map ...
>>> On Wed, Jul 16, 2008 at 5:44 PM, in message <487E6BD7.3020006@qualcomm.com>, Well, admittedly I am not entirely clear on what problem is being solved as I was not part of the original thread with Linus. My impression of what you were trying to solve was to eliminate the need to rebuild the domains for a hotplug event (which I think is a good problem to solve), thus eliminating some complexity and (iiuc) races there. However, based on what you just said, I am not sure I've got that ...
Jul 16, 7:51 pm 2008
Gregory Haskins
Re: [PATCH] cpu hotplug, sched: Introduce cpu_active_map ...
>>> On Thu, Jul 17, 2008 at 3:16 AM, in message <487EF1E9.2040101@qualcomm.com>, Hi Max, Thanks for the pointers. I see that I did indeed misunderstand the intent of the patch. It seems you already solved the rebuild problem, and were just trying to solve the "migrate to a dead cpu" problem that Linus mentions as a solution with cpu_active_map. In that case, note that rq->rd->online already fits the bill, I believe. In a nutshell, rq->rd->span contains all the cpus within your disjoint ...
Jul 17, 4:57 am 2008
James Bottomley
Re: [PATCH] block: fix q->max_segment_size checking in b ...
Yes and no. The parameter PCI_DMA_BUS_IS_PHYS is set if the platform doesn't have one. Nowadays, that's not enough; with VT and bypass what the system really needs to know is if the device will be using the iommu. The idea of calling into the platform iommu code was considered when all this was done, but it was rejected. Function pointer calls are incredibly expensive on most platforms that at that time had iommus. The best way was to construct a theoretical parametrisation of an ...
Jul 17, 6:56 am 2008
Mikulas Patocka
Re: [PATCH] block: fix q->max_segment_size checking in b ...
We don't know what happens in the future. And that is the problem that we don't know --- but we have two pieces of code (blk-merge and iommu) that try to calculate the same number (number of hw segments) and if they get different result, it will crash. If the calculations were done at one place, there would be no problem with that. Mikulas --
Jul 17, 4:50 am 2008
FUJITA Tomonori
Re: [PATCH] block: fix q->max_segment_size checking in b ...
On Wed, 16 Jul 2008 14:02:27 -0400 (EDT) If the device has 64KB boundary restriction, the device also has max_seg_size restriction of 64KB or under. So the vmerge acounting What is your new restriction? All restrictions that IOMMUs need to know are dma_get_seg_boundary and dma_get_max_seg_size. --
Jul 16, 9:14 pm 2008
Boaz Harrosh
Re: [PATCH] block: fix q->max_segment_size checking in b ...
I have a question. Does the block layer know of the IOMMU in use for the device? can it call into the IOMMU to calculate the restriction? Thanks Boaz --
Jul 17, 6:27 am 2008
FUJITA Tomonori
Re: [PATCH] block: fix q->max_segment_size checking in b ...
On Thu, 17 Jul 2008 07:50:24 -0400 (EDT) I don't think that your argument, 'the problem that we don't know', is true. With the vmerge accounting, we calculate at two places. So if we add a new restriction, we need to handle it at two places. It's a logical result. Of course, it's easier to calculate at one place rather than two places. But 'we don't know what restriction we will need' isn't a problem. BTW, as I've already said, I'm not against removing the vmerge accounting from ...
Jul 17, 6:18 am 2008
Andrew Morton
Re: [PATCH] Compile fix for sa1100_wdt
On Tue, 15 Jul 2008 10:56:42 +0200 Your email client is performing space-stuffing. http://mbligh.org/linuxdocs/Email/Clients/Thunderbird used to have the repair instructions, but that server has been down for a while. http://web.archive.org/web/20070528114159/http://mbligh.org/linuxdocs/Email/Clients/Th... has a copy. --
Jul 17, 4:04 pm 2008
Randy Dunlap
Re: [PATCH] Compile fix for sa1100_wdt
or see if Documentation/email-clients.txt has any useful info for you... --- ~Randy Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA http://linuxplumbersconf.org/ --
Jul 17, 4:09 pm 2008
sasa sasa
[BUG]Set_up irq problem while using gpio
Hi , I think there is a bug in kernel/irq/manage.c file. --- kernel_old/irq/manage.c 2008-02-07 22:11:14.000000000 +0530 +++ kernel_new/irq/manage.c 2008-02-07 22:19:14.000000000 +0530 @@ -349,8 +349,14 @@ /* Setup the type (level, edge polarity) if configured: */ if (new->flags & IRQF_TRIGGER_MASK) { if (desc->chip && desc->chip->set_type) - desc->chip->set_type(irq, - new->flags & IRQF_TRIGGER_MASK); + { ...
Jul 17, 2:20 am 2008
Ingo Molnar
Re: [PATCH] x86: fix asm/e820.h for userspace inclusion ...
applied to tip/x86/urgent, thanks Rusty. Ingo --
Jul 17, 10:28 am 2008
Jan Engelhardt
Re: From 2.4 to 2.6 to 2.7?
Continuing on that thought.. Incrementing the minor number once every 6 to 8 releases or so (resetting the micro number to 0 of course) would nicely mark a group of featureful kernels. --
Jul 17, 10:25 am 2008
Alex Chiang
Re: From 2.4 to 2.6 to 2.7?
The short answer is that HP-UX decided to keep major number 11 as a branding decision, and has released updates such as 11i, 11i v1, 11i v2, etc. Most recent release was 11i v3, and if you do a uname -a, you'll see that you get a "real" version, like 11.31. http://en.wikipedia.org/wiki/Hpux#Versions /ac --
Jul 16, 5:03 pm 2008
Jan Engelhardt
Re: From 2.4 to 2.6 to 2.7?
Follow the thread. :) --
Jul 17, 1:21 pm 2008
Craig Milo Rogers
Re: From 2.4 to 2.6 to 2.7?
Use 2.8 in 2008, 2.9 in 2009, 2.10 in 2010, etc? Craig Milo Rogers --
Jul 17, 12:56 pm 2008
Lennart Sorensen
Re: From 2.4 to 2.6 to 2.7?
So the 11 no longer has any meaning. At least when Sun decided the 5 in SunOS Version 5.x didn't have a meaning anymore, they dropped it. Of course sun also called it solaris 2.x at the same time as SunOS 5.x, so perhaps dropping everything but the x made sense. Version numbers never stay the way they were intended to. -- Len Sorensen --
Jul 17, 5:38 am 2008
Adrian Bunk
Re: From 2.4 to 2.6 to 2.7?
Another point that came into my mind: How many scripts and programs out there parse the kernel version number, know about the 2.6 prefix, and might need an update if it changes? Not a big deal if a change would indicate a big change like with the old development model - but IMHO not worth it if there's no compelling reason why we have to change the numbering at all. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had ...
Jul 17, 3:16 pm 2008
Alex Chiang
Re: From 2.4 to 2.6 to 2.7?
Not exactly. The 11 implies an ABI/API guarantee to ISVs and some sense of "stability" (for whatever that means) to end users. Marketing fluff, yes, but I guess some people out there do care about that stuff. /ac --
Jul 17, 1:02 pm 2008
David Woodhouse
Re: [GIT *] Allow request_firmware() to be satisfied fro ...
I'm very confused. I can do this... make INSTALL_FW_PATH=/tmp/foo firmware_install su otheruser touch firmware/.ihex2fw.cmd (gives EPERM as expected) make INSTALL_FW_PATH=/tmp/foo2 firmware_install And it _works_ for me, after I've made that change in scripts/Makefile.fwinst. But I don't have .ihex2fw.d -- I have .ihex2fw.cmd. What is in your .ihex2fw.d? And does it work if you include _that_ from firmware/Makefile? /me wonders where Sam is hiding... -- dwmw2 --
Jul 17, 2:25 pm 2008
David Miller
Re: [GIT *] Allow request_firmware() to be satisfied fro ...
From: Alan Cox <alan@lxorguk.ukuu.org.uk> That was wrong, but there have been other legal subtexts. request_firmware() itself, although partially done for technical reasons, had some very real legal impetus. Linus has even said that in this thread. --
Jul 17, 2:31 pm 2008
Rafael J. Wysocki
Re: [GIT *] Allow request_firmware() to be satisfied fro ...
HOSTCC firmware/ihex2fw - due to: FORCE /home/rafael/src/linux-next/firmware/ihex2fw.c:268: fatal error: opening dependency file firmware/.ihex2fw.d: Read-only file system compilation terminated. Thanks, Rafael --
Jul 17, 1:42 pm 2008
Rafael J. Wysocki
Re: [GIT *] Allow request_firmware() to be satisfied fro ...
There's no '.ihex2fw.d' under 'firmware' in my O= path. I just do 'make modules_install' on the NFS client, after I have run 'make O=... ... firmware_install' on the server and it prints the above error message. Should I add anything to the 'make modules_install' command line? Rafael --
Jul 17, 3:25 pm 2008
Ingo Molnar
Re: [crash, bisected] I2C, kobject (ffff81003e8c4160): ...
Jean, -tip testing found another (similar) i2c crash with latest -git, on a Core2Duo laptop: calling nforce2_init+0x0/0x1b initcall nforce2_init+0x0/0x1b returned 0 after 0 msecs calling nforce2_s4985_init+0x0/0x275 BUG: unable to handle kernel NULL pointer dereference at 0000000c IP: [<c04af2cf>] i2c_smbus_xfer+0x27/0x3f0 *pdpt = 00000000009cb001 *pde = 0000000000000000 Oops: 0000 [#1] SMP Pid: 1, comm: swapper Not tainted (2.6.26-tip #3033) EIP: 0060:[<c04af2cf>] EFLAGS: ...
Jul 17, 2:26 am 2008
Ingo Molnar
Re: [crash, bisected] I2C, kobject (ffff81003e8c4160): ...
found another bootup crash on an Athlon 64 X2 testsystem: [ 19.610000] bus: 'pci': add driver amd756_smbus [ 19.615204] initcall amd756_init+0x0/0x20 returned 0 after 9 msecs [ 19.620000] calling amd756_s4882_init+0x0/0x2d7 [ 19.624242] ------------[ cut here ]------------ [ 19.628415] WARNING: at kernel/mutex.c:134 mutex_lock_nested+0xc0/0x267() [ 19.630000] Pid: 1, comm: swapper Not tainted 2.6.26-tip #20066 [ 19.630000] [ 19.630000] Call Trace: [ 19.630000] ...
Jul 17, 2:49 am 2008
Alexey Dobriyan
Re: [crash, bisected] I2C, kobject (ffff81003e8c4160): ...
Well, it's pretty easy oops unless I misread something. It happened on not nforce2 motherboard, right? nforce2_init will just register PCI driver, no matching PCI ids => nforce2_set_reference() isn't called => nforce2_smbus stays NULL. Second module loads and tries to i2c_smbus_xfer(NULL, ) in module_init() hook which oopses. --
Jul 17, 2:48 am 2008
Ingo Molnar
Re: [crash, bisected] I2C, kobject (ffff81003e8c4160): ...
can try patches, but got other 5 fresh upstream oopses/hangs/crashes to investigate now. (so i went for the minimal-effort turn-off-the-failing-part approach) Ingo --
Jul 17, 2:59 am 2008
Ingo Molnar
Re: [crash, bisected] I2C, kobject (ffff81003e8c4160): ...
turning off CONFIG_I2C_AMD756_S4882 works around this bug (as expected), via the patch below. Ingo ---------------------------> commit 3f6403ab0bfdfca0cefbbc414afedc62734392f3 Author: Ingo Molnar <mingo@elte.hu> Date: Thu Jul 17 11:52:41 2008 +0200 i2c: work around boot crash in amd756_s4882_init() work around: [ 19.610000] bus: 'pci': add driver amd756_smbus [ 19.615204] initcall amd756_init+0x0/0x20 returned 0 after 9 msecs [ 19.620000] ...
Jul 17, 2:54 am 2008
Ingo Molnar
Re: [crash, bisected] I2C, kobject (ffff81003e8c4160): ...
turning off I2C_NFORCE2_S4985 makes the system boot up fine. Workaround patch below. Ingo -------------------> commit 15e524060d13e8fac3fe2fb6c6519be6de9ab8a8 Author: Ingo Molnar <mingo@elte.hu> Date: Thu Jul 17 11:29:44 2008 +0200 i2c workaround: turn off I2C_NFORCE2_S4985 for now I2C_NFORCE2_S4985 causes this crash: calling nforce2_init+0x0/0x1b initcall nforce2_init+0x0/0x1b returned 0 after 0 msecs calling nforce2_s4985_init+0x0/0x275 ...
Jul 17, 2:33 am 2008
Greg KH
Re: [crash, bisected] I2C, kobject (ffff81003e8c4160): t ...
It is in 2.6.26 as I haven't merged any patches with Linus yet, portions of it might be in older kernels, but not in the same type of format. thanks, greg k-h --
Jul 17, 3:42 pm 2008
Nicholas A. Bellinger
[ANNOUNCE] - VHACS-VM x86_64 Alpha Preview - FOLLOWUP
Greetings all, Just a quick couple of updates since the VHACS-VM announcement (which happened to be a day after after v2.6.26. ;): I) The two VHACS-VM x86_64 images, have been split into 2 compressed ~300 MB images (for the running demo), and a 800 MB BUILD .vmdk disk image containing the source for VHACS v0.8.15. The three archives can be found at the same location: http://linux-iscsi.org/builds/VHACS-VM/x86_64/vmware6/ II) lio-core-2.6.git has been updated to v2.6.26 and loaded ...
Jul 17, 10:44 am 2008
Anton Vorontsov
Re: [PATCH] leds: implement OpenFirmare GPIO LED driver
The label that is written on the board for this particular LED, or Hm.. how could I enumerate them then? Or should I just give them the This is tricky question. Personally I place them inside the gpio controller node that is responsible for the LED. But I think placing the led nodes at top level would be also fine (maybe with "leds { }" node as a parent for all board's LEDs. What would you suggest for a "best practice"? Thanks, -- Anton Vorontsov email: ...
Jul 17, 4:07 am 2008
Grant Likely
Re: [PATCH] leds: implement OpenFirmare GPIO LED driver
I like this idea (a 'leds' parent node). They aren't really children of the GPIO node or any other device/bus in the system. Putting them under a dedicated 'leds' node would make them easy to find and would have the added advantage of making it easier to have a single driver instance manage the whole lot. g. --
Jul 17, 8:07 am 2008
Anton Vorontsov
Re: [PATCH v3] leds: implement OpenFirmare GPIO LED driver
I like the idea, thanks. -- Anton Vorontsov email: cbouatmailru@gmail.com irc://irc.freenode.net/bd2 --
Jul 17, 7:05 am 2008
Sean MacLennan
Re: [PATCH] leds: implement OpenFirmare GPIO LED driver
On Thu, 17 Jul 2008 15:07:30 +0400 I also put the leds under the gpio controller for the Warp. It is then very clear which gpio controller the leds belong to. Putting them at the top level does not associate the leds with the correct gpio controller. Warning: I am *not* using the of gpio led driver, but I hope to move to it once the dust settles and drop the current Warp specific driver ;) Cheers, Sean --
Jul 17, 7:58 am 2008
Anton Vorontsov
Re: [PATCH v3] leds: implement OpenFirmare GPIO LED driver
On Thu, Jul 17, 2008 at 06:05:19PM +0400, Anton Vorontsov wrote: Ugh, no. The idea sounds good, but in practice it isn't, since we'll have to handle suspend/resume ops ourselves. When we stick with the device/driver model we're getting all this for free. -- Anton Vorontsov email: cbouatmailru@gmail.com irc://irc.freenode.net/bd2 --
Jul 17, 7:13 am 2008
Anton Vorontsov
Re: [PATCH v3] leds: implement OpenFirmare GPIO LED driver
Ok. I must admit I'm quite burned out with OF gpio-leds. I was posting the bindings since April, probably four or five times. Last time a week ago, IIRC. During the months I received just a few replies, one from Grant ("Looks good to me."), few from Segher (with a lot of criticism, that I much appreciated and tried to fix all spotted issues), and one from Laurent (about active-low LEDs). Of course, I know we're all busy etc and we don't always read or reply to RFCs, so don't get me wrong, ...
Jul 17, 4:42 pm 2008
Segher Boessenkool
Re: [PATCH] leds: implement OpenFirmare GPIO LED driver
This "compatible" name is a bit too generic. No, I don't know a What is a label? It should be described here. Also, its encoding You show a unit address but have no "reg" value. This is incorrect. What would be the parent node of this, btw? Segher --
Jul 16, 10:59 pm 2008
Anton Vorontsov
Re: [PATCH v3] leds: implement OpenFirmare GPIO LED driver
You didn't count extra platform driver. You can't #ifdef it. The only way you can avoid this is creating leds-gpio-base.c or something, and place the The create_gpio_led() interface is also quite weird, since it implies that we have to pass two GPIO LED "handles": struct gpio_led_data (that we allocated) and temporary struct gpio_led. And this helper function will just assign things from one struct to another, and then will register the led. With OF driver I don't need "struct ...
Jul 17, 6:55 am 2008
Anton Vorontsov
Re: [PATCH v3] leds: implement OpenFirmare GPIO LED driver
Ah. I just wrongly read your message. You're purposing to use gpio leds platform driver... I think this is doable, yes. -- Anton Vorontsov email: cbouatmailru@gmail.com irc://irc.freenode.net/bd2 --
Jul 17, 8:20 am 2008
Trent Piepho
Re: [PATCH v3] leds: implement OpenFirmare GPIO LED driver
Your new driver was 194 lines, not counting docs or Kconfig. My patch added about 104 lines to the existing leds-gpio driver. So yes, about half I guess, in terms of compiled size, the combined platform + of_platform driver is bigger than the of_platform only driver. Though it's much smaller than having both the platform only and of_platform only drivers. In terms of source code, there's less with the combined driver. I don't see why the combined leds-gpio driver can't have an ifdef for ...
Jul 17, 1:01 pm 2008
Trent Piepho
Re: [PATCH v3] leds: implement OpenFirmare GPIO LED driver
Ok, how about adding code the existing leds-gpio driver so that it can creates LEDs from of_platform devices too? I've made a patch to do this and it works ok. The code added to leds-gpio is about half what was involved in Anton's new driver. What I did was re-factor the existing platform device probe function to use a new function that creates a single led. Then a new of_platform probe function can use it too. That way most of the probe code is shared. remove, suspend and resume aren't ...
Jul 16, 10:13 pm 2008
Grant Likely
Re: [PATCH v3] leds: implement OpenFirmare GPIO LED driver
I kind of like the second option better, because there is less chance of doing bad stuff if the gpio specifier was buggered up; but I'm cool with either. However, if the second option is chosen then something like the following might be better as it eliminates the meaningless @<number> specifier. leds { compatible = "gpio-led"; red { gpios = <&mpc8572 6 0>; }; green { gpios = <&mpc8572 7 0>; }; }; Cheers, g. --
Jul 17, 1:49 pm 2008
Trent Piepho
Re: [PATCH v3] leds: implement OpenFirmare GPIO LED driver
Basically what I did then in my patch then, refactor leds-gpio so most of it is shared and there is a block of code that does platform binding and another block that does of_platform binding. I didn't change the OF platform binding syntax so as not to complicate the example, but that's easy to do. Something like: leds { compatible = "gpio-led"; gpios = <&mpc8572 6 0 &mpc8572 7 0>; labels = "red", "green"; }; Or like this, which needs a little more code to ...
Jul 17, 1:18 pm 2008
Grant Likely
Re: [PATCH v3] leds: implement OpenFirmare GPIO LED driver
Ugh; that means registering *2* 'struct device' with the kernel instead of one. One as a platform device and one as an of_platform device. It's bad enough that the LED scheme we're using for OF bindings has a separate registration for every single LED. Now that it comes to it, I worry that this driver takes the wrong approach. The number of resources dedicated per LED in this driver seems pretty loony to me (one of_platform device per LED). The fact that the binding specifies one node per ...
Jul 16, 9:15 pm 2008
Grant Likely
Re: [PATCH v3] leds: implement OpenFirmare GPIO LED driver
On Thu, Jul 17, 2008 at 9:20 AM, Anton Vorontsov Alternately, I would also be okay with a scheme where all LED nodes have a common parent and an of_platform driver would bind against the parent node; not the individual children. Then the leds-gpio driver could be refactored to have both platform and of_platform bus bindings. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. --
Jul 17, 11:05 am 2008
Nate Case
Re: [PATCH v3] leds: implement OpenFirmare GPIO LED driver
How about also supporting a "trigger" property which would set cdev.default_trigger in the same manner? It would be useful for boards to be able to specify this in the device tree (e.g., if a certain LED is meant to be used as a "heartbeat"). -- Nate Case <ncase@xes-inc.com> --
Jul 17, 2:29 pm 2008
Grant Likely
Re: [PATCH v3] leds: implement OpenFirmare GPIO LED driver
Won't the leds-gpio driver give you suspend/resume support? g. --
Jul 17, 8:04 am 2008
Rene Herman
Re: [boot crash, bisected] in 9f240a55 "ALSA: opti93x: u ...
No, please hang on, it's much simpler. Above commit isn't actually itself guilty. Have a patch ready, but am testing a bit. Rene. --
Jul 17, 12:20 pm 2008
Ingo Molnar
[boot crash, bisected] in 9f240a55 "ALSA: opti93x: use c ...
hi Jaroslav, et al, -tip testing found the following bootup crash on latest -git: [ 44.827459] calling alsa_card_opti9xx_init+0x0/0x20 [ 44.830435] bus: 'isa': add driver opti93x [ 44.833503] device: 'opti93x.0': device_add [ 44.837804] bus: 'isa': add device opti93x.0 [ 44.841820] bus: 'isa': driver_probe_device: matched device opti93x.0 with driver opti93x [ 44.845327] bus: 'isa': really_probe: probing driver opti93x with device opti93x.0 [ ...
Jul 17, 10:06 am 2008
Rene Herman
Re: [boot crash, bisected] in 9f240a55 "ALSA: opti93x: u ...
I retract that. Your patch should fix things. I would like to place something on top to make the init isa/pnp choice look more generic but I'll submit that tomorrow. Rene. --
Jul 17, 12:38 pm 2008
Takashi Iwai
Re: [boot crash, bisected] in 9f240a55 "ALSA: opti93x: u ...
At Thu, 17 Jul 2008 19:06:57 +0200, Could you try the patch below? thanks, Takashi --- diff --git a/sound/isa/opti9xx/opti92x-ad1848.c b/sound/isa/opti9xx/opti92x-ad1848.c index 41c047e..d20abb2 100644 --- a/sound/isa/opti9xx/opti92x-ad1848.c +++ b/sound/isa/opti9xx/opti92x-ad1848.c @@ -688,7 +688,7 @@ static void snd_card_opti9xx_free(struct snd_card *card) if (chip) { #ifdef OPTi93X struct snd_cs4231 *codec = chip->codec; - if (codec->irq > 0) { + if (codec && ...
Jul 17, 11:40 am 2008
Hidetoshi Seto
Re: [PATCH] stopmachine: add stopmachine_timeout v2
sysctl.c already has many externs... but I can fix at least Is it better to postpone v4 until your comment comes? Thanks, H.Seto --
Jul 16, 8:40 pm 2008
Jeremy Fitzhardinge Jul 16, 10:37 pm 2008
Hidetoshi Seto
[PATCH] stopmachine: add stopmachine_timeout v4
If stop_machine() invoked while one of onlined cpu is locked up by some reason, stop_machine cannot finish its work because the locked cpu cannot stop. This means all other healthy cpus will be blocked infinitely by one dead cpu. This patch allows stop_machine to return -EBUSY with some printk messages if any of stop_machine's threads cannot start running on its target cpu in time. You can enable this timeout via sysctl. v4: - move extern into linux/stop_machine.h and add include of the ...
Jul 16, 11:12 pm 2008
Max Krasnyansky Jul 17, 12:09 am 2008
Andrew Morton
Re: [patch -mmotm 2/6] fix qla2xxx-use-memory_read_from_ ...
On Thu, 17 Jul 2008 16:44:16 -0700 Sure, no probs. --
Jul 17, 4:46 pm 2008
Andrew Vasquez
Re: [patch -mmotm 2/6] fix qla2xxx-use-memory_read_from_ ...
If needed: Acked-by: Andrew Vasquez <andrew.vasquez@qlogic.com> BTW: is the memory_read_from_buffer() work for qla2xxx going in through the mm tree submission path??? --
Jul 17, 4:12 pm 2008
Andrew Vasquez
Re: [patch -mmotm 2/6] fix qla2xxx-use-memory_read_from_ ...
Would it too bothersome if I were to just collapse the two patches and submit the composite with the my next set of patches??? Seems silly to add the oneliner to the history... --
Jul 17, 4:44 pm 2008
Andrew Morton
Re: [patch -mmotm 2/6] fix qla2xxx-use-memory_read_from_ ...
On Thu, 17 Jul 2008 16:12:35 -0700 FSVO "through", yeah. It's appeared on linux-scsi four times so far. Last time James complained about the fs.h inclusion so Akinobu raised a patch "move memory_read_from_buffer() from fs.h to string.h" which I just merged. I'll just keep pressing send - it'll get there sometime. Or you can merge it if you like. --
Jul 17, 4:28 pm 2008
Renato S. Yamane
Re: Toshiba - Documentation for Linux Developers
[cc'ed Greg KH] Only to remember: Toshiba website to Linux Developers is: <http://linux.toshiba-dme.co.jp/linux/eng/develop.htm> Best regards, Renato S. Yamane --
Jul 17, 4:57 am 2008
Milton Miller
Re: [PATCH/RFC] pci: dynids.use_driver_data considered harmful
Fine, I'll give you a little time. But I want to hear specifics how it helps drivers. I have shown how it hurts many drivers. My arguement is that once we set the flag on the drivers, we will end up with it set on all drivers or the remaining drivers will not care. There were 413+ drivers in linux-next that were compiled by allyesconfig, about 150 used driver data. If the purpose is to enforce range checking, then I'll start working on patches for those 100 drivers to do that. But ...
Jul 17, 7:36 am 2008
Greg KH
Re: [PATCH/RFC] pci: dynids.use_driver_data considered harmful
Sorry, I'm on the road right now and will not get back until Friday. Then I have the big merges with Linus to get through. I'll try to get to this by Monday, but my original point still stands, this was implemented for a reason, saying that not enough drivers use it properly does not make the need for it to go away. It is required for them, so perhaps the other 419 drivers also need to have the flag set. That's pretty trivial to do, right? thanks, greg k-h --
Jul 17, 12:07 am 2008
Randy Dunlap
Re: [PATCH 29/30] W1: Documentation/w1/masters/ds2490 update
Thanks. --- ~Randy Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA http://linuxplumbersconf.org/ --
Jul 17, 2:52 pm 2008
Andre Prendel
Re: ACPI Error under 2.6.26-rc*
Attached. Yes, the e820 table differs, but power off still works. Linux version 2.6.25.10-default (andre@ubuntu) (gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)) #5 Tue Jul 8 21:21:58 CEST 2008 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000001fff0000 (usable) BIOS-e820: ...
Jul 17, 1:41 am 2008
Christoph Hellwig
Re: [PATCH -v2] ftrace: Documentation
The GFDL is never appropriate, and certainly not for the kernel tree. We had some files under it in the past and we decided to relicense them after talking to the authors. --
Jul 17, 7:19 am 2008
Russell King - ARM Linux
Re: [PATCH 10/15] regulator: documentation - consumer in ...
Actually, wrong. "Initialize" is correct spelling in the UK too - I've checked several UK dictionaries printed in the 1960s, 1970s and 1980s sourced from different printers, and they all agree on that. At the same time I checked other words which I thought ended in -ise. The dictionaries all said -ize and didn't list the -ise version. Therefore, I suspect -ise came into use in the late 1980s in the UK. Given my research, I'm intending to use the -ize version myself from now on, to ...
Jul 17, 11:39 am 2008
Mark Brown
Re: [PATCH 10/15] regulator: documentation - consumer in ...
Heh. This fits the general pattern where American and English spellings diverge - usually it's the English spelling which changed rather than the American one. It's not normally so recent, though. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." --
Jul 17, 12:40 pm 2008
Luis R. Rodriguez
Re: 2nd REVISED AGENDA -- Re: Linux Wireless Mini-Summit ...
On Wed, Jul 16, 2008 at 11:48 AM, John W. Linville A couple I can think of: * Compat-wireless, this can be discussed after new MQ patch. We may have to freeze mac80211 for old kernels for compat-wireless after the MQ patch goes through and only leave in it fixes moving forward. This consideration is because porting the MQ patch may be very difficult to maintain. It was expected though that the first MQ patch could not be ported though so we'll see, we just might be able to port ...
Jul 17, 3:16 am 2008
Luis R. Rodriguez
Re: 2nd REVISED AGENDA -- Re: Linux Wireless Mini-Summit ...
On Wed, Jul 16, 2008 at 11:48 AM, John W. Linville I'll cover this. If we can't cover this well in the time frame provided we can discuss this over the course of the week in impromptu sessions. Luis --
Jul 17, 3:05 am 2008
Andrew Morton
Re: [PATCH 04/04] resource: add new IORESOURCE_CLK type
On Tue, 15 Jul 2008 17:19:24 +0900 umm, has there been any comment on all of this yet? Perhaps you should just send everything again with clearer/completer We're all asleep. Please do whatever you think is best and we'll merge it - that'll wake 'em up. --
Jul 17, 4:20 pm 2008
YAMAMOTO Takashi
Re: [PATCH][RFC] dirty balancing for cgroups
i chose min(p_bdi * p_cgroup, p_bdi * p_task) because i couldn't imagine a simple example for which my patch can make some sense is: while :;do dd if=/dev/zero of=file conv=notrunc bs=4096 count=1;done YAMAMOTO Takashi --
Jul 16, 6:43 pm 2008
Mimi Zohar
Re: [Patch 5/5]integrity: IMA as an integrity service provider
On a 32-bit x86, I'm not getting any warnings. I've compiled the code with both Sparse and EXTRA_CFLAGS=-W. [Patch 5/5]integrity: IMA as an integrity service provider This is a re-release of Integrity Measurement Architecture(IMA) as an independent Linunx Integrity Module(LIM) service provider. This version addresses a number of issues discussed on LKML, including: - Corrects the atomic_long_t variable usage, to use the appropriate atomic_long calls. - Added ...
Jul 17, 2:54 pm 2008
Bjorn Helgaas
Re: v2.6.26-rc9: ACPI PCI irq routing on NUMA? + early_i ...
If you could get netconsole working and collect the complete console log from both the working config and the broken one, that would help a lot. Bjorn --
Jul 17, 11:45 am 2008
Vegard Nossum
Re: v2.6.26-rc9: ACPI PCI irq routing on NUMA? + early_i ...
Hah, I actually managed to get netconsole working. This is the log that fails (v2.6.26): http://folk.uio.no/vegardno/linux/numa-netconsole.txt I think this looks really interesting: [ 0.093562] ExtINT not setup in hardware but reported by MP table [ 0.093854] ENABLING IO-APIC IRQs [ 0.094244] ..TIMER: vector=0x31 apic1=-1 pin1=2 apic2=-1 pin2=0 [ 0.094985] ..MP-BIOS bug: 8254 timer not connected to IO-APIC [ 0.094985] ...trying to set up timer (IRQ0) through the 8259A ...
Jul 17, 1:58 pm 2008
Aidan Thornton
Re: [stable] Linux 2.6.25.10
True, there are other serious types of bugs (silent data corruption is one particularly nasty one). However, for *any* serious bug, it's important to be clear on what the likely impact is and what's affected. This goes particularly for the ones that might otherwise not be obvious to the person affected until it's too late, such as security and silent data corruption bugs, but really it applies to all serious bugs. I'm not convinced these descriptions are clear enough. Aidan --
Jul 17, 2:08 pm 2008
Vivek Goyal
Re: [RFC] How to handle the rules engine for cgroups
This is the easy to handle situation and I am hoping it will work in many of the cases. Currently I am writting a patch for libcg which allows querying the destination cgroup based on uid/gid and libcg will also migrate the application there. I am also writing a pam plugin which will move all the login sessions to respective cgroup (as mentioned by rule file). Will also modify "init" so that all the system services to into cgroup belonging to root. Once user is logged in and running into ...
Jul 17, 6:47 am 2008
Kazunaga Ikeno
RE: [RFC] How to handle the rules engine for cgroups
I think a wrapper (move to right group and calls exec) will run by user, not by admin. In explicit placement, user knows what a type of application he/she launch. /mnt/cgroup | | gid1 gid2 | | | | uid1 uid2 uid3 uid4 | | proj1 proj2 [uid1/gid1]% newtask.sh proj1app ... proj1app run under /mnt/cgroup/gid1/uid1 [uid1/gid1]% newtask.sh --type proj1type proj1app ... proj1app run under /mnt/cgroup/gid1/uid1/proj1 In this case, admin sets up limitation of ...
Jul 17, 12:05 am 2008
Brown, Len
RE: Check for BIOS bugs - Original Subject: Re: [PATCH 2 ...
Sure, there may be justification for doing something like this in the kernel, but the issue that started this thread isn't it. The issue that started this thread can be diagnosed by user-space in linuxfirmwarekit. Multiple machines have this bug, which means that it is "common industry practice" and the kernel has to work around it (silently) if we like it or not. ie. the issue, now that it is debugged and worked around, is effectly just firmware lint. thanks, -Len --
Jul 17, 1:31 pm 2008
Ilpo Järvinen
Re: 2.6.25.6: warn_on_slowpath in tcp_input.c
Thanks for the report, I've been away for a while, thus the late response. Please update to get this relevant fix and some other TCP fixes (if you haven't yet): releases/2.6.25.7/tcp-fix-skb-vs-fack_count-out-of-sync-condition.patch ...If you still get them afterwards, please do rereport (and include me as recipient :-)). ...I know there are couple of cases still after that fix where TCP invariant checks trigger but they've been rare enough to evade any of my debugging attempts ...
Jul 17, 8:01 am 2008
Matthew Wilcox
Re: PCI: MSI interrupts masked using prohibited method
OK, here's a patch which does the trick for me. I put a printk_ratelimit into the new mask_ack_msi_irq() function, then hammered my AHCI controller with 16 threads doing directio reads to the same track of a disc. It came up pretty reliably, so I would say it's at least minmally tested. David, does this solve your problem? diff --git a/arch/x86/kernel/io_apic_64.c b/arch/x86/kernel/io_apic_64.c index 6510cde..693de6c 100644 --- a/arch/x86/kernel/io_apic_64.c +++ ...
Jul 17, 9:56 am 2008
Matthew Wilcox
Re: PCI: MSI interrupts masked using prohibited method
I think that exposes us to a race. CPU takes the first interrupt, calls handle_fasteoi_irq(). That calls handle_IRQ_event() which calls the device's interrupt handler. Interrupt handler reads status register to determine what to do next. Device generates second interrupt and changes status register. Second interrupt is never delivered because the ->eoi hasn't been called yet. I plan to keep using the edge handler which solves this race by calling mask_ack(). For MSIs without mask bits, ...
Jul 17, 9:11 am 2008
Thomas Gleixner
Re: PCI: MSI interrupts masked using prohibited method
Yeah, I know. The question is how the hardware works; there is fasteoi capable hardware around (not on x86) which works with edge type Ah, there are ones w/o a mask bit. That detail slipped through. Thanks, tglx --
Jul 17, 10:04 am 2008
Krzysztof Halasa
Re: PCI: MSI interrupts masked using prohibited method
Remember that MSI predates INTX disable bit. -- Krzysztof Halasa --
Jul 17, 5:16 am 2008
David Vrabel
Re: PCI: MSI interrupts masked using prohibited method
From the PCI spec: "This bit disables the device/function from asserting INTx#. A value of 0 enables the assertion of its INTx# signal. A value of 1 disables the assertion of its INTx# signal. This bit’s state after RST# is 0. Refer to Section 6.8.1.3 for control of MSI." Is this really necessary? Any PCI device with MSI that doesn't have the hardware MSI mask bits must have some sort of device specific handshaking for managing when MSIs can be generated. Regardless, doesn't ...
Jul 17, 6:14 am 2008
Matthew Wilcox
Re: PCI: MSI interrupts masked using prohibited method
That's true. MSI was introduced in PCI 2.2 and INTX disable was introduced in PCI 2.3; a 3-year window. -- Intel are signing my paycheques ... these opinions are still mine "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." --
Jul 17, 5:43 am 2008
Matthew Wilcox
Re: PCI: MSI interrupts masked using prohibited method
Yes it is, but we don't touch that bit at this time. When we enable MSIs, we set the INTx disable bit (or at least do a write to it ... as Krzysztof Halasa pointed out, not all devices implement this bit). When we mask MSIs, we clear the MSI enable bit. So a device conforming to PCI 2.3 has both INTx and MSI disabled. Unfortunately, a device conforming to PCI 2.2 has MSI disabled and INTx implicitly Maybe so, but we don't control that. Here's the flow that leads to the problem you've ...
Jul 17, 8:39 am 2008
Thomas Gleixner
Re: PCI: MSI interrupts masked using prohibited method
__do_IRQ() is the old all-in-one handler which is not called on platforms which have GENERIC_HARDIRQS set. You can safely ignore what Right and it is not supposed to know anything about the hardware details at all. The per irq setting can provide NOOP functions for all the mask/mask_ack/unmask things when thats the right way for the That's irrelevant. All the interrupts are handled via Yep. You can also use fasteoi_handler, which just calls ->eoi() after You want to use the ...
Jul 17, 8:58 am 2008
Stephen Rothwell
Re: [xfs-masters] Re: linux-next: Tree for June 24 (XFS x2)
When that happens, could you please make sure that the linux-next tree is updated as well ... I have had a couple of trees where what was merged to Linus did not match what is in linux-next - and that causes me no end of pain when I have to merge the two ... --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/
Jul 17, 1:28 am 2008
Timothy Shimmin
Re: [xfs-masters] Re: linux-next: Tree for June 24 (XFS x2)
Yep, I believe Lachlan is planning to regenerate the xfs git tree before the pull request. --Tim --
Jul 16, 10:26 pm 2008
Greg KH
Re: [PATCH 12/15] driver core: Implement tagged director ...
Ok, I'll work to get these in where applicable. thanks, greg k-h --
Jul 17, 4:08 pm 2008
Thomas Gleixner
Re: [PATCH] Re: AMD Mobile Semprons (3500+, 3600+,...) b ...
Hmm, I don't see how the apic timer is related to that, but it might be a problem with the hpet. Why does it work with 2.6.24 on kubuntu 8.04 ? Oh, that's a different beast, but it might be also a problem with the timer interrupt routing. Thanks, tglx --
Jul 17, 4:05 am 2008
Thomas Gleixner
Re: [PATCH] Re: AMD Mobile Semprons (3500+, 3600+,...) b ...
ouch. I read the whole thread and also checked the suse bugzilla, which confuses the hell out of me as there is reported that kubuntu with 2.6.24 works and everything suse > 2.6.20 does not. Can you please tell me the symptoms of vanilla 2.6.25 without nohz=off on the kernel command line ? Thanks, tglx --
Jul 17, 3:51 am 2008
Richard
Re: [PATCH] Re: AMD Mobile Semprons (3500+, 3600+,...) b ...
The Short story... it was a dark and rainy night :-P oops, wrong mailing list.... so here goes The kernel boots and when init.d starts, the screen switches off, the CPU fan goes to Max speed, and a few minutes later all goes quiet and it appears to have powered off. I usually boot with noapictimer and if I disable ACPI totally, the clock references don't work and the timebase goes wrong. (Playing a MP3 is quite an entertaining event as it sounds like an old vinyl record player with a ...
Jul 17, 4:58 am 2008
Thomas Gleixner
Re: [PATCH] Re: AMD Mobile Semprons (3500+, 3600+,...) b ...
That's with 2.6.25 vanilla, right ? Can you provide a bootlog from that kernel with noapictimer on the kernel command line ? Also as it reaches at least init it would be great to get a bootlog for a boot w/o any command line options via netconsole (see Documentation/networking/netconsole.txt) Thanks, tglx --
Jul 17, 4:11 am 2008
Richard
Re: [PATCH] Re: AMD Mobile Semprons (3500+, 3600+,...) b ...
Hi All, Here is a dump from lspci.... looks completely different :-P and here i was blaming ATI :-) Richard 00:00.0 Host bridge: ATI Technologies Inc RS690 Host Bridge 00:01.0 PCI bridge: ATI Technologies Inc RS690 PCI to PCI Bridge (Internal gfx) 00:04.0 PCI bridge: ATI Technologies Inc Unknown device 7914 00:05.0 PCI bridge: ATI Technologies Inc RS690 PCI to PCI Bridge (PCI Express Port 1) 00:06.0 PCI bridge: ATI Technologies Inc RS690 PCI to PCI Bridge (PCI Express Port ...
Jul 17, 4:44 am 2008
Richard
Re: [PATCH] Re: AMD Mobile Semprons (3500+, 3600+,...) b ...
Prepare to be spammed.... I am using a Sabayon build, but all distros I have tried exibit the same behavior to me. the nohz=off options also works quite well. (I have a 2.6.26 vanilla that behaves the same) but for now, I am off to read and setup the netconsole. Richard --------------- WITH Noapic timer ------------ Jul 14 11:12:23 localhost syslog-ng[11073]: syslog-ng starting up; version='2.0.6' Jul 14 11:12:23 localhost plash=silent,theme:sabayon vga=791 CONSOLE=/dev/tty1 ...
Jul 17, 5:23 am 2008
Thomas Gleixner
Re: [PATCH] Re: AMD Mobile Semprons (3500+, 3600+,...) b ...
Those are the interesting ones :) Questions: Are CONFIG_HIGHRES_TIMERS and CONFIG_NO_HZ enabled ? Is it still necessary to add any command line option ? Is the system stable ? Also please provide the output of # cat /sys/devices/system/clocksource/clocksource0/current_clocksource and # cat /proc/timer_list Thanks, tglx --
Jul 17, 9:59 am 2008
Thomas Renninger
Re: [PATCH] Re: AMD Mobile Semprons (3500+, 3600+,...) b ...
Evgeny's (eumaster) and Uli's chipsets are both: north-bridge: nvidia c51mv south-bridge: nvidia mcp51m Also both are MSI laptops: - MSI-M670, modell MS-1632 - MSI S430x (This could also be a chipset or even an MSI specific BIOS bug? Richard could you compare with your HW, pls if still possible). Some more info: - things break entering C2 or deeper - noapictimer workaround helps to come a bit further, but results in sever other errors, disk(dma error), keyboad, mouse etc., ...
Jul 17, 3:32 am 2008
Richard
Re: [PATCH] Re: AMD Mobile Semprons (3500+, 3600+,...) b ...
Hi All, I am still available to hack away :-) I would also like to get this bug resolved but I feel I am out of my depth with this problem. (Embedded PowerPC's are my toys) As a quick test, I grabbed the 2.6.26 kernel and built it... but alas, it broke... well, from my ill-educated guess, it looked like acpid done something and the machine shut down. Richard --
Jul 16, 11:55 pm 2008
Richard
Re: [PATCH] Re: AMD Mobile Semprons (3500+, 3600+,...) b ...
Here you go.. a 2.6.26-tip dmesg (the top seems to be missing for some reason!) .. just shout if you need the bits on the top. Richard n DSDT [ 0.074620] ACPI: EC: non-query interrupt received, switching to interrupt mode [ 0.338551] ACPI: Interpreter enabled [ 0.338594] ACPI: (supports S0 S3 S4 S5) [ 0.338762] ACPI: Using IOAPIC for interrupt routing [ 0.349915] ACPI: EC: GPE = 0x11, I/O: command/status = 0x66, data = 0x62 [ 0.349980] ACPI: EC: driver started ...
Jul 17, 10:47 am 2008
Thomas Gleixner
Re: [PATCH] Re: AMD Mobile Semprons (3500+, 3600+,...) b ...
We have a fix for that in Linus tree. Any chance to give current mainline a test ride ? Thanks, tglx --
Jul 17, 5:03 am 2008
Mike Snitzer
Re: [PATCH 0 of 7] Block/SCSI Data Integrity Support
On Tue, Jun 10, 2008 at 11:28 AM, Martin K. Petersen Have you made the ext2/3/4 developers aware of this? Could you elaborate on the interaction between the data integrity support in the block layer and a given filesystem? Shouldn't _any_ filesystem "just work" given that the block layer is what is generating the checksums and then verifying them on read? regards, Mike --
Jul 17, 6:55 am 2008
Martin K. Petersen
Re: [PATCH 0 of 7] Block/SCSI Data Integrity Support
Mike> Have you made the ext2/3/4 developers aware of this? Yep. Mike> Shouldn't _any_ filesystem "just work" given that the block Mike> layer is what is generating the checksums and then verifying Mike> them on read? Yep. There are a couple of issues. One problem is that pages are no longer locked down during I/O. Instead the writeback bit is being set to indicate that I/O is in progress. Not all corners of ext* have been adapted to that properly. Especially ext2 suffers and ...
Jul 17, 8:35 am 2008
Geert Uytterhoeven
Re: [Squashfs-devel] Squashfs mainlining status?
Hi Peter, Oops, I've just returned from holidays, and realize I never actually responded to this question. So here is the gist of it: | I had a closer look at the structures and bitfields, and I still think it's | possible to stay compatible with the current little endian layout: | 1. About half of the bitfields are actually bytes or 16-bit words. Hence | these can easily be converted to __u8 or __le16. | 2. Most of the remaining bitfields sit in an 8, 16, or 32 bit integer. | ...
Jul 17, 8:35 am 2008
Robert Lougher
Re: [Squashfs-devel] Squashfs mainlining status?
On Thu, Jul 17, 2008 at 4:35 PM, Geert Uytterhoeven Last time I looked you were not the maintainer of squashfs. Phillip spent a long time examining the possibility of maintaining compatibility but decided asthat there were sufficient advantages in a new layout to warrant the change. --
Jul 17, 8:47 am 2008
Thomas Renninger
[PATCH] Re: cpufreq limits avilable frequencies to 800MH ...
Hi, maybe I found something..., can someone review/test this. Thanks, Thomas ------------ CPUFREQ ACPI: Only call _PPC after cpufreq ACPI init funcs got called already Ingo Molnar provided a fix to not call _PPC at processor driver initialization time. Git commit #e4233dec749a3519069d9390561b5636a75c7579 But it can still happen that _PPC is called at processor driver initialization time. This patch should make sure that this is not possible anymore. Signed-off-by: ...
Jul 17, 6:48 am 2008
Andrew Morton
Re: [PATCH] Re: cpufreq limits avilable frequencies to 8 ...
On Thu, 17 Jul 2008 15:48:02 +0200 There is no actual description of what this fixes, is there? Do machines go oops, or what? How do we proceed from here with this patch? Who should review it, who should test it, who should ack it and who should merge it? e4233dec749a3519069d9390561b5636a75c7579 was in January so this patch is applicable to 2.6.25.x and to 2.6.26.x. But is it needed there? Insufficient info. Ho hum. I queued it, tagged as needed-in-2.6.25.x and 2.6.26.x. But I am ...
Jul 17, 2:40 pm 2008
Oren Laadan
Re: Checkpoint/restart (was Re: [PATCH 0/4] - v2 - Objec ...
Heh .. and it can get much worse. By all means, the functions that analyze and save the VMAs during checkpoint and later reconstruct them during restart are the most complicated logic. The good news, however, is that it works :) --
Jul 17, 4:19 pm 2008
Oren Laadan
Re: Checkpoint/restart (was Re: [PATCH 0/4] - v2 - Objec ...
"Replaying all of the user space actions that took us to get there" - this task is not even always possible without deterministic log/replay mechanism :( --
Jul 17, 4:14 pm 2008
Oren Laadan
Re: Checkpoint/restart (was Re: [PATCH 0/4] - v2 - Objec ...
I'm not sure how this approach integrates with (a) live migration (and the iterative process of sending over memory modified since previous iteration), and (b) incremental checkpoint (where except for the first snapshot, additional snapshots only save what changed since the previous one). --
Jul 17, 4:16 pm 2008
Oren Laadan
Re: Checkpoint/restart (was Re: [PATCH 0/4] - v2 - Obje ...
yes, we probably prefer an intermediate representation to some extent, mainly because we (a) don't want garbage data that we don't use and (b) to make the task of converting from old to new kernel version easier. But only for these two reasons. I see zero value in avoiding representation used internally by the kernel for the sake of avoiding it. In fact, if it's that much easier to stick to that representation in a specific case -- so be it. There shall be userland utilities that will be ...
Jul 17, 4:09 pm 2008
Dave Hansen
Re: KVM overflows the stack
A newer gcc (4.2) makes this a wee bit better, but probably still worrisome. dave@nimitz:~/src/kvm-userspace-virgin/kernel$ objdump -d *.ko | perl /home/dave/kernels/linux-2.6.git-t61/scripts/checkstack.pl i386 0x00007b33 kvm_arch_vm_ioctl [kvm]: 1164 0x000072e8 kvm_arch_vcpu_ioctl [kvm]: 1060 0x00007497 kvm_arch_vcpu_ioctl [kvm]: 1060 0x0000adad kvm_pv_mmu_op [kvm]: 564 0x0000ae6b kvm_pv_mmu_op [kvm]: 564 0x00002553 kvm_vcpu_ioctl [kvm]: 468 0x0000d7e8 paging64_prefetch_page ...
Jul 16, 11:27 pm 2008
Dave Hansen
Re: KVM overflows the stack
$ gcc -v Did you mean dynamic allocation? :) -- Dave --
Jul 16, 11:14 pm 2008
Dave Hansen
Re: KVM overflows the stack
Well, you *better* be able to deal with it. :) This code is also doing a *ton* of copy_to/from_user(). If userspace had one of its input buffers swapped out (or one of its output buffers not faulted in yet) and we're out of memory enough to be failing kmallocs() then we're sure as heck also going to failing the user copies. I think it's a non-issue. -- Dave --
Jul 17, 7:06 am 2008
Avi Kivity
Re: kvm causing memory corruption? now 2.6.26
Well that assert is plain wrong: static int apic_match_dest(struct kvm_vcpu *vcpu, struct kvm_lapic *source, int short_hand, int dest, int dest_mode) { int result = 0; struct kvm_lapic *target = vcpu->arch.apic; apic_debug("target %p, source %p, dest 0x%x, " "dest_mode 0x%x, short_hand 0x%x", target, source, dest, dest_mode, short_hand); ASSERT(!target); It should be ASSERT(target), if anything. -- I have a truly marvellous ...
Jul 16, 10:38 pm 2008
Dave Hansen
[PATCH] update kvm's anon_inodes.c for r/o bind mounts
That also reminds me. kvm somehow has an outdated copy of anon_inodes.c. It needs to be updated for the r/o bind mount patches to add a proper mnt_want/drop_write(). Otherwise, you'll run into warnings about imbalanced mount writer counts. Something like this will do, but it would be best to just stay up to date with mainline for this kind of stuff. diff --git a/kernel/anon_inodes.c b/kernel/anon_inodes.c index 74630ea..a47bc55 100644 --- a/kernel/anon_inodes.c +++ ...
Jul 16, 11:45 pm 2008
Avi Kivity
Re: KVM overflows the stack
Yeah. Too early in the morning for me. Roland's trick might be easier than either, though. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. --
Jul 16, 11:42 pm 2008
Roland Dreier
Re: KVM overflows the stack
> Yes, things like kvm_lapic_state are way too big to be on the stack. I had a quick look at the code, and my worry about dynamic allocation would be that handling allocation failure seems like it might get tricky. Eg for handling struct kvm_pv_mmu_op_buffer (which is 528 bytes on the stack in kvm_pv_mmu_op()) can you deal with an mmu op failing? (maybe in that case you can easily by just setting *ret to 0?) > There's an additional problem here, that apparently your gcc (which > version?) ...
Jul 16, 11:08 pm 2008
Avi Kivity
Re: KVM overflows the stack
Yes, it's designed to be restartable. Returning 0 should be fine. We can reduce the buffer size to 256 though. I wouldn't want an allocation in this hot path. -- error compiling committee.c: too many arguments to function --
Jul 17, 7:15 am 2008
Avi Kivity
Re: KVM overflows the stack
Yes, things like kvm_lapic_state are way too big to be on the stack. There's an additional problem here, that apparently your gcc (which version?) doesn't fold objects in a switch statement into the same stack slot: switch (...) { case x: { struct medium a; ... } case y: struct medium b; ... } }; These could be solved either by stack allocation, or by moving into functions marked noinline. Whichever is easier. -- I ...
Jul 16, 10:52 pm 2008
Andrew Morton
Re: [RFC] [Patch] calgary iommu: Use the first kernel's ...
On Tue, 15 Jul 2008 14:15:27 +0530 Is this needed in 2.6.26? If so, the patch whcih I applied will need a little work because I had to touch up some rejects against already-queued changes. I can fix that issue by applying this _ahead_ of those changes, but I'm just not able to judge whether this is needed from the information which was You don't _have_ to put new includes right at the end of the list! Everyone does this, and it just maximises the probability of merge A couple of ...
Jul 17, 4:14 pm 2008
previous daytodaynext day
July 16, 2008July 17, 2008July 18, 2008