We are presently searching for Representatives/Collection Agents who can help us establish a medium of getting to our customers in the Americas, precisely USA and Canada and Europe as well. If interested, Please contact me on (mr.chofat@gmail.com) Respectfully Submitted, Mr. Cho Fat --

The balloon driver doesn't have any externally callable functions at the moment, so remove the (effectively empty) header. We can add it back if we need to. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- drivers/xen/balloon.c | 1 include/xen/balloon.h | 61 ------------------------------------------------- 2 files changed, 62 deletions(-) =================================================================== --- a/drivers/xen/balloon.c +++ ...

Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> --- drivers/net/e1000e/netdev.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c index 01e9558..b81c423 100644 --- a/drivers/net/e1000e/netdev.c +++ b/drivers/net/e1000e/netdev.c @@ -47,7 +47,7 @@ #include "e1000.h" -#define DRV_VERSION "0.3.3.3-k4" +#define DRV_VERSION "0.3.3.3-k6" char e1000e_driver_name[] = "e1000e"; const char ...

This series of patches fixes several bugs found by putting a mutex inside e1000_acquire_swfw_flag, and then the patch from Thomas actually adds this mutex to help find any further bugs. Like Jesse Barnes said, "totally up to you (obviously) whether we stuff this into 2.6.27 or hold on it until 2.6.28." Linus, since you mentioned this exact same issue that Thomas (and Dave Airlie) spotted I figured I should just send these. Testing will continue over the next couple of days and I'll let you ...

the stats lock is left over from e1000, e1000e no longer has the adjust tbi stats function that required the addition of the stats lock to begin with. adding a mutex to acquire_swflag helped catch this one too. Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> CC: Thomas Gleixner <tglx@linutronix.de> --- drivers/net/e1000e/e1000.h | 1 - drivers/net/e1000e/netdev.c | 18 ------------------ 2 files changed, 0 insertions(+), 19 deletions(-) diff --git ...

thanks to tglx, we're finding some interesting reentrancy issues. this patch removes the phy read from inside a spinlock, paving the way for removing the spinlock completely. The phy read was only feeding a statistic that wasn't used. Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> CC: Thomas Gleixner <tglx@linutronix.de> --- drivers/net/e1000e/ethtool.c | 6 +++++- drivers/net/e1000e/netdev.c | 13 ------------- 2 files changed, 5 insertions(+), 14 deletions(-) diff ...

I don't disagree with any of that. I followed the printk.time example closely. All those things are equally true of that option. Thanks, Roland --

This adds the printk.caller=[0|1] boot parameter, default setting controlled by CONFIG_PRINTK_CALLER. (This is modelled on printk.time and CONFIG_PRINTK_TIME.) When this is set, each printk line is automagically prefixed with "{0x123abc} " giving the PC address of that printk call (actually the PC address just after the call). As a kernel hacker, I always hate having to grep for some fragment of a message to find the code that generated it. But I always have my -g vmlinux handy, ...

On Thu, 2 Oct 2008 16:21:48 -0700 I think so. As I understand it, net-next-2.6 is Dave Miller's git tree for stuff destined for 2.6.28. --

Nice, so that means it's going to be in 2.6.28? thanks, greg k-h --

On Thu, 2 Oct 2008 16:02:46 -0700 Hi Greg, It's in net-next-2.6. http://marc.info/?l=linux-netdev&m=122144021209242&w=2 Best, Jay --

On Thu, 2 Oct 2008 16:02:41 -0700 (PDT) Yeah, that was a quick push so I could wave some patches under the noses of various maintainers who have been cheerily ignoring the needed-in-2.6.27 patches which I keep on sending them. --

Yeah, looks much better. I was using this silly test program to see if the earlier code worked. Just pass in both valid and invalid sizes. Jesse

[patch] x86: Trivial printk fix in efi.c The following line is lacking a space between "memdesc" and "doesn't". "Kernel-defined memdescdoesn't match the one from EFI!" Fixed the printk by adding a space. Signed-off-by: Russ Anderson <rja@sgi.com> --- arch/x86/kernel/efi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux/arch/x86/kernel/efi.c =================================================================== --- linux.orig/arch/x86/kernel/efi.c 2008-10-02 ...

Greetings all, I just wanted to mention that I made the commit that renamed the source and header files in drivers/lio-core/Makefile:target_core_mod-objs to use the target_core_* prefix. http://git.kernel.org/?p=linux/kernel/git/nab/lio-core-2.6.git;a=commit;h=e53c989a9f0d... This should make things alot easier for folks who are reading the code to see and understand the split between target_core_mod and iscsi_target_mod, as well as the split between target_core_mod ...

There is no sane way to query the personality flags of arbitrary process from userspace. This adds the flags to the /proc/$pid/status file. For example, to detect READ_IMPLIES_EXEC: $ ./32bit-sleeper & [1] 6732 $ grep ^Pers /proc/6732/status Personality: 00000000 $ execstack -s 32bit-sleeper $ ./32bit-slepper & [2] 6735 $ grep ^Pers /proc/6735/status Personality: 00040000 Signed-off-by: Kees Cook <kees.cook@canonical.com> --- fs/proc/array.c | 6 ++++-- ...

I have not followed all of this too closely, and installed linux-2.6.27-rc7-33 (OpenSUSE's KOTD) kernel in an attempt to get its wireless card going. When I booted I briefly saw a NVRAM warning and my laptop ended hanging on Firewall Initialization, without ever getting to a login prompt. I immediately remembered this bug, but strangely seem not to be affected, since I could still use the card to connect to the internet after rebooting in 2.6.26. My laptop's a Lenovo W500 with a fairly ...

Sounds good. Here is the commit: http://git.kernel.org/?p=linux/kernel/git/nab/lio-core-2.6.git;a=commit;h=374e8ace84ca... Thanks for your comments! --nab --

Why not use the built-in list.h functions here? Other than that, looks good, thanks. greg k-h --

From: Rafael J. Wysocki <rjw@sisk.pl> sky2: Fix recent WOL regression Since dev->power.should_wakeup bit is used by the PCI core to decide whether the device should wake up the system from sleep states, set/unset this bit whenever WOL is enabled/disabled using sky2_set_wol() (this fixes a regression from 2.6.26 on the Tino's machine). Remove an open-coded reference to the standard PCI PM registers that is not used any more. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Reported-by: ...

Hello, Below is my patch for an issue on Dell E6500 notebooks with the Sigmatel stac92hd71b7 codec. In the default snd-hda-intel configuration, the sound going to the headphone jack goes comes directly from the DAC, resulting in very low volume output. The patch changes the codec's widget connections so that the internal mixer is put in between and sets its input amplifiers to the maximum value. The output to the internal speaker port has been left untouched. I have tested this and it gives a much ...

Including <linux/ktime.h> eliminates the following error: include/linux/ftrace.h:220: error: expected specifier-qualifier-list before 'ktime_t' Signed-off-by: Steven Noonan <steven@uplinklabs.net> --- include/linux/ftrace.h | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h index deded11..ed53265 100644 --- a/include/linux/ftrace.h +++ b/include/linux/ftrace.h @@ -3,6 +3,7 @@ #include <linux/linkage.h> #include ...

You could be interested by this thread http://lkml.org/lkml/2008/9/16/290 - Cyrill - --

Thanks, Somehow I missed that thread. Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) --

On Thu, 2 Oct 2008 17:19:56 +0100 gad. Wouldn't it be clearer to do for (i = 1; i < nr_pages; i++) { struct page *p = pfn_to_page(i); __SetPageTail(p); p->first_page = page; } Oh well, I guess we can go with the obfuscated, uncommented version for now :( This patch applies to 2.6.26 (and possibly earlier) but I don't think those kernels can trigger the bug? --

Make sure that ->request_fn() really isn't called on queues that are supposed to be stopped. While at it, don't remove the plug in __blk_run_queue() unconditionally since this might lead to system hangs. Signed-off-by: Elias Oltmanns <eo@nebensachen.de> --- Applies to your devel tree. block/blk-core.c | 6 +++--- block/elevator.c | 12 +++++++----- 2 files changed, 10 insertions(+), 8 deletions(-) diff --git a/block/blk-core.c b/block/blk-core.c index 2d053b5..ecc5443 100644 --- ...

Fyi, lenovo/ibm(Canada) are replacing the Motherboard on my T61 (6465-9TU) Intel®82566DC Gigabit Network Card. MAC ADDRR now read's FF:FF:FF:FF:FF:FF:FF:FF (wink) I did not advise them that it may have been caused by a hiccup/glitch in the Linux Kernel and/or the e1000e driver for said system. Perhap's those of you still under warrenty could obtain the same service. --

Sounds like you need a priority class besides sync and async. --

Like other kernel developers, I compile kernels several times a day with various configs. Some are for testing, others are given to me by others to debug some code. I like to look at any warnings that gcc gives me, and lately I've been irritated by the same warnings appearing in the same places that has nothing to do with my code. The biggest offender is the Xen code. I figured that I'll take a look at what these warnings are and if they are trivial, I'll fix them. The thing that got me ...

J --

Investigating the unused static files in the balloon code, I discovered that the balloon code is not used at all. The header file is one big #if 0 and all the functions in the C file is static. There is no caller like init_module to hook to any of these functions. Basically, this code is one big patch of dead code wasting space on my hard drive. This patch removes the balloon code altogether since there are no users. CC: Jeremy Fitzhardinge <jeremy@xensource.com> CC: Chris Wright ...

In enlighten.c there's a macro that is defined to jump to a label. This macro is only used in an ifdef CONFIG_X86_32 section, and the label is outside that define conditional, which causes warnings. This patch pushes the label inside the define condition. CC: Jeremy Fitzhardinge <jeremy@xensource.com> CC: Chris Wright <chrisw@sous-sol.org> Signed-off-by: Steven Rostedt <srostedt@redhat.com> --- arch/x86/xen/enlighten.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Index: ...

Yep, IIRC we both asked for that the last time as well... Nikanth? -- Jens Axboe --

q->max_sectors MUST always be <= q->max_hw_sectors, otherwise we could be sending down requests that are too large for the device to handle. So that condition would be a big bug. The sysfs interface checks for this, and blk_queue_max_sectors() makes sure that is true as well. The fixes proposed still look weird. There is no phys vs hw segment constraints, the request must adhere to the limits set by both. It's mostly a moot point anyway, as 2.6.28 will get rid of the hw ...

Yes, that seems always to be enforced. Perhaps there are other ways of tripping this problem ... I'm still sure if it occurs it's because we do Agree all three proposed fixes look wrong. However, if it's what I think, just getting rid of hw accounting won't fix the problem because we'll still have the case where a physical merge is forbidden by iommu constraints ... this still needs to be accounted for. What we really need is a demonstration of what actually is going wrong ...

applied to tip/x86/microcode, thanks Dmitry! Ingo --

[ cc'd: lkml ] Right, I've been looking at the wrong tree. Please find the fix enclosed. Compiles ok, shouldn't break anything else. > > Ingo > -- Best regards, Dmitry Adamushko --

Implement all the new swapfile a_ops for NFS. This will set the NFS socket to SOCK_MEMALLOC and run socket reconnect under PF_MEMALLOC as well as reset SOCK_MEMALLOC before engaging the protocol ->connect() method. PF_MEMALLOC should allow the allocation of struct socket and related objects and the early (re)setting of SOCK_MEMALLOC should allow us to receive the packets required for the TCP connection buildup. (swapping continues over a server reset during heavy network ...

This is needed to allow network softirq packet processing to make use of PF_MEMALLOC. Currently softirq context cannot use PF_MEMALLOC due to it not being associated with a task, and therefore not having task flags to fiddle with - thus the gfp to alloc flag mapping ignores the task flags when in interrupts (hard or soft) context. Allowing softirqs to make use of PF_MEMALLOC therefore requires some trickery. We basically borrow the task flags from whatever process happens to be preempted by ...

Add reserves for INET. The two big users seem to be the route cache and ip-fragment cache. Reserve the route cache under generic RX reserve, its usage is bounded by the high reclaim watermark, and thus does not need further accounting. Reserve the ip-fragement caches under SKB data reserve, these add to the SKB RX limit. By ensuring we can at least receive as much data as fits in the reassmbly line we avoid fragment attack deadlocks. Adds to the reserve tree: total network reserve ...

This makes that ip6_route_net_init() does all of the route init code. There used to be a race between ip6_route_net_init() and ip6_net_init() and someone relying on the combined result was left out cold. Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> --- net/ipv6/af_inet6.c | 8 -------- net/ipv6/route.c | 9 +++++++++ 2 files changed, 9 insertions(+), 8 deletions(-) Index: ...

Toss all emergency packets not for a SOCK_MEMALLOC socket. This ensures our precious memory reserve doesn't get stuck waiting for user-space. The correctness of this approach relies on the fact that networks must be assumed lossy. Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> --- net/core/filter.c | 3 +++ 1 file changed, 3 insertions(+) Index: linux-2.6/net/core/filter.c =================================================================== --- ...

There is a small race between the procfs caller and the memory hotplug caller of setup_per_zone_pages_min(). Not a big deal, but the next patch will add yet another caller. Time to close the gap. Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Reviewed-by: Pekka Enberg <penberg@cs.helsinki.fi> --- mm/page_alloc.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) Index: ...

Change the skb allocation api to indicate RX usage and use this to fall back to the reserve when needed. SKBs allocated from the reserve are tagged in skb->emergency. Teach all other skb ops about emergency skbs and the reserve accounting. Use the (new) packet split API to allocate and track fragment pages from the emergency reserve. Do this using an atomic counter in page->index. This is needed because the fragments have a different sharing semantic than that indicated by ...

Provide means to reserve a specific amount of pages. The emergency pool is separated from the min watermark because ALLOC_HARDER and ALLOC_HIGH modify the watermark in a relative way and thus do not ensure a strict minimum. Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> --- include/linux/mmzone.h | 6 ++- mm/page_alloc.c | 84 +++++++++++++++++++++++++++++++++++++++++++------ mm/vmstat.c | 6 +-- 3 files changed, 82 insertions(+), 14 deletions(-) Index: ...

GFP_NOFS is _more_ permissive than GFP_NOIO in that it will initiate IO, just not of any filesystem data. The problem is that previuosly NOFS was correct because that avoids recursion into the NFS code, it now is not, because also IO (swap) can lead to this recursion. Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> --- fs/nfs/pagelist.c | 2 +- fs/nfs/write.c | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) Index: ...

With the introduction of the shared dirty page accounting in .19, NFS should not be able to surpise the VM with all dirty pages. Thus it should always be able to free some memory. Hence no more need for mempools. Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> --- fs/nfs/read.c | 15 +++------------ fs/nfs/write.c | 27 +++++---------------------- 2 files changed, 8 insertions(+), 34 deletions(-) Index: ...

Tag pages allocated from the reserves with a non-zero page->reserve. This allows us to distinguish and account reserve pages. Since low-memory situations are transient, and unrelated the the actual page (any page can be on the freelist when we run low), don't mark the page in any permanent way - just pass along the information to the allocatee. Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> --- include/linux/mm_types.h | 1 + mm/page_alloc.c | 4 +++- 2 files ...

Add some packet-split receive hooks. For one this allows to do NUMA node affine page allocs. Later on these hooks will be extended to do emergency reserve allocations for fragments. Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> --- drivers/net/bnx2.c | 8 +++----- drivers/net/e1000/e1000_main.c | 8 ++------ drivers/net/e1000e/netdev.c | 7 ++----- drivers/net/igb/igb_main.c | 9 ++------- drivers/net/ixgbe/ixgbe_main.c | 10 +++------- ...

Restrict objects from reserve slabs (ALLOC_NO_WATERMARKS) to allocation contexts that are entitled to it. This is done to ensure reserve pages don't leak out and get consumed. The basic pattern used for all # allocators is the following, for each active slab page we store if it came from an emergency allocation. When we find it did, make sure the current allocation context would have been able to allocate page from the emergency reserves as well. In that case allow the allocation. If not, force ...

The reserve is proportionally distributed over all (!highmem) zones in the system. So we need to allow an emergency allocation access to all zones. In order to do that we need to break out of any mempolicy boundaries we might have. In my opinion that does not break mempolicies as those are user oriented and not system oriented. That is, system allocations are not guaranteed to be within mempolicy boundaries. For instance IRQs don't even have a mempolicy. So breaking out of mempolicy ...

Clean up the code by factoring out the gfp to alloc_flags mapping. [neilb@suse.de says] As the test: - if (((p->flags & PF_MEMALLOC) || unlikely(test_thread_flag(TIF_MEMDIE))) - && !in_interrupt()) { - if (!(gfp_mask & __GFP_NOMEMALLOC)) { has been replaced with a slightly weaker one: + if (alloc_flags & ALLOC_NO_WATERMARKS) { we need to ensure we don't recurse when PF_MEMALLOC is set Signed-off-by: Peter Zijlstra ...

I don't think we're really able to get any MM balls rolling until we get all the split-LRU stuff landed. Is anyone testing it? Is it good? --

Patches are against: v2.6.27-rc5-mm1 This release features more comments and (hopefully) better Changelogs. Also the netns stuff got sorted and ipv6 will now build and not oops on boot ;-) The first 4 patches are cleanups and can go in if the respective maintainers agree. The code is lightly tested but seems to work on my default config. Let's get this ball rolling... --

From 9a083f0e9a81f5bc31ea49f37112f1945830fc7c Mon Sep 17 00:00:00 2001 From: Matthew Fleming <matthew.fleming@imgtec.com> Date: Thu, 2 Oct 2008 12:24:05 +0100 Subject: [PATCH 2/2] MMC: CSD and CID timeout values The MMC spec states that the timeout for accessing the CSD and CID registers is 64 clock cycles. Signed-off-by: Matthew Fleming <matthew.fleming@imgtec.com> --- drivers/mmc/core/mmc_ops.c | 8 ++++++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git ...

applied to tip/tracing/fastboot, thanks Frederic, Ingo --

BTW I forgot to cc Arjan. Arjan if you have some time to test it, I would be interested by your feeling about it since the boot tracer has now an output which is parsable by bootgraph.pl. Thanks! --

applied to tip/tracing/fastboot, thanks Frederic! Ingo --

Is the new chip requires some changes in handling (e.g. diffrent clock ranges/setting, etc)? There is nothing about timings in the patch (aside 230MHz). Kind regards, ---------------------------------------------------------------------- Zapytaj o Milosc, Prace, Zdrowie, Rodzine ... Sprawdz >> http://link.interia.pl/f1f27 --

Advanced Linux Sound System = ALSS? How about switching it to --

I would expect Andrew to merge it. If he doesn't, then I'll try to merge it. :) ~Randy --

--- ~Randy --

Signed-off-by: Rodolfo Giometti <giometti@linux.it> --- Documentation/tty.txt | 4 ++++ include/linux/tty_ldisc.h | 8 ++++++++ 2 files changed, 12 insertions(+), 0 deletions(-) diff --git a/Documentation/tty.txt b/Documentation/tty.txt index 8e65c44..3fc812a 100644 --- a/Documentation/tty.txt +++ b/Documentation/tty.txt @@ -100,6 +100,10 @@ write_wakeup() - May be called at any point between open and close. is permitted to call the driver write method from this function. ...

Why limit this to just DCD change, and not any of the other status bits (DCD, RI, DSR, CTS)? -hpa --

Add a new line discipline for "pulse per second" devices connected to a serial port. Signed-off-by: Rodolfo Giometti <giometti@linux.it> --- include/linux/tty.h | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/include/linux/tty.h b/include/linux/tty.h index 826d695..1857db2 100644 --- a/include/linux/tty.h +++ b/include/linux/tty.h @@ -24,7 +24,7 @@ */ #define NR_UNIX98_PTY_DEFAULT 4096 /* Default maximum for Unix98 ptys */ #define NR_UNIX98_PTY_MAX (1 ...

Here some utilities and examples about the PPS API and the LinuxPPS support. * ppsldisc.c shows how to manage PPS line discipline; * ppstest.c implements an useful testing program, while * ppsfind tries to help the user into finding a specific PPS source by using its name or path. Signed-off-by: Rodolfo Giometti <giometti@linux.it> --- Documentation/pps/Makefile | 28 ++++++++ Documentation/pps/ppsfind | 17 +++++ Documentation/pps/ppsldisc.c | 46 +++++++++++++ ...

This patch adds into the PPS's documentation directory a possible implementation of the PPS API (RFC 2783) by using the LinuxPPS's char devices. This file is not just an example but it can be used into real systems. :) Signed-off-by: Rodolfo Giometti <giometti@linux.it> --- Documentation/pps/timepps.h | 195 +++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 195 insertions(+), 0 deletions(-) create mode 100644 Documentation/pps/timepps.h diff --git ...

Each PPS source can be registered/deregistered into the system by using special modules called "clients". They simply define the PPS sources' attributes and implement the time signal registartion mechanism. This patch adds a special directory for such clients and adds a dummy client that can be useful to test system integrity on real systems. Signed-off-by: Rodolfo Giometti <giometti@linux.it> --- drivers/pps/Kconfig | 2 + drivers/pps/Makefile | 1 + ...

drivers/gpio/bt8xxgpio.c: In function `bt8xxgpio_remove': drivers/gpio/bt8xxgpio.c:247: warning: ignoring return value of `gpiochip_remove', declared with attribute warn_unused_result Following patch removes the above warning. Thanks. Signed-off-by: Md.Rakib H. Mullick (rakib.mullick@gmail.com) --- linux-2.6.27-rc8.orig/drivers/gpio/bt8xxgpio.c 2008-10-01 19:20:59.000000000 +0600 +++ linux-2.6.27-rc8/drivers/gpio/bt8xxgpio.c 2008-10-02 12:30:26.374544032 +0600 @@ -242,9 +242,14 @@ ...

Yes, but it will notice through KERN_ERR that something bad has happened. And if we don't get out of it then it will continue its execution and will finish with a kfree ( I think which --

At a guess I'd say that the hrtimer data structures got wrecked. If possible, please see if we fixed it in 2.6.27-rc8. If so, there might be a patch we need to backport (although is might have been backported into later 2.6.25.x's as well). --

Correction: It's vfs_create that fails to check return codes properly. /* * Create - we need to know the parent. */ error = path_lookup_create(dfd, pathname, LOOKUP_PARENT, &nd, flag, mode); //// If ERROR is a positive value, ERR_PTR fails to convert it to a negative value. This causes the EDI register to get set to "1" after do_filp_open returns. //// if (error) return ...

From: Matti Linnanvuori <matti.linnanvuori@ascom.com> Retina G.703 and G.SHDSL driver. Signed-off-by: Matti Linnanvuori <matti.linnanvuori@ascom.com> --- This patch is on top of jgarzik's netdev-2.6.git retina branch, also in URL: http://groups.google.com/group/pcidriver/web/retina.patch This patch replaces an erroneous io_remap_pfn_range call with an remap_pfn_range call. --- linux/drivers/net/wan/retina.c 2008-10-02 09:32:42.187347800 +0300 +++ ...

Syncppp is to be removed shortly, please use generic HDLC instead. See the "next" branch for up-to-date details. -- Krzysztof Halasa --

Hi, I'm currently writing two modules related to XEN. Both modules need to acquire dynamic memory (via __get_free_pages() and kmalloc() ). In order to reuse some code, I wrote a third module which can provide simple memory-services to other modules: * Allocated pages and memories of each client-module gets tracked * When a module is about to exit, it can issue one function call to release all of its memories * Before first using the memory manager, each module has to obtain a unique owner id ...

The best way to get a useful response is to post the patches and see what happens. There's no way to really evaluate what you're proposing in the abstract. J --

On Mon, 29 Sep 2008, Yinghai Lu wrote: | results: Thanks for posting all these examples. More test cases for mtrr-uncover. I've made some changes to mtrr-uncover so that it comes up with solutions for all of these without any hints (i.e. the user no longer has to specify the address range for the MTRR that must be uncovered, the program guesses). ftp://ftp.cs.utoronto.ca/pub/hugh/mtrr-uncover-2008oct01.tgz | 1. hpa | reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, ...

Sorry, I think I am completely out of context w.r.t. discussion. Any hints/URLs to the old discussion would be nice. -- Balbir --

my reproducer is sadly very simple (claws-mail is my mail client that uses maildir) Process claws-mail (4896) Total: 2829.7 msec EXT3: Waiting for journal access 2491.0 msec 88.4 % Writing back inodes 160.9 msec 5.7 % synchronous write 78.8 msec 3.0 % is an example of such a trace (this is with patch, without patch the numbers are about 3x bigger) Waiting for journal access is ...

On Thu, 2 Oct 2008 15:47:37 +0200 argh. "0" means both "not set" and "highest priority". how about we fix this? right now "query + set" isn't idempotent..... it should be able to be that. -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org --

On Wed, 1 Oct 2008 21:56:38 -0700 Jens didn't like the APi I used back then. Since then the kernel grew (by Jens) a clean API to do the same... -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org --

You can do that for submit_bio() by calling bio_set_prio() before submision - I did that for elevating only the XFS journal I/O. submit_bh() doesn't have any way of passing a priority through to it right now... I should resurrect the XFS patches I had an retest them.... Cheers, Dave. -- Dave Chinner david@fromorbit.com --

On Thu, 2 Oct 2008 09:46:59 -0400 yes; I have mount -o remount,relatime / & for i in `pidof kjournald` ; do ionice -c1 -p $i ; done I'll try (sadly I'm in a training session all day today so I might not interesting testcase of the markers concept. -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org --

On Thu, 2 Oct 2008 11:45:37 +0200 I looked at 0 but it appears the 0 is the default for everyone... if everyone just defaulted to > 0 then yes I would have picked 0. -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org --

From: Arjan van de Ven <arjan@linux.intel.com> Date: Wed, 1 Oct 2008 19:58:18 -0700 Subject: [PATCH] Give kjournald a IOPRIO_CLASS_RT io priority With latencytop, I noticed that the (in memory) atime updates during a kernel build had latencies of 6 seconds or longer; this is obviously not so nice behavior. Other EXT3 journal related operations had similar or even longer latencies. Digging into this a bit more, it appears to be an interaction between EXT3 and CFQ in that CFQ tries to be ...

On Thu, 2 Oct 2008 15:27:47 +0200 ok I checked not by looking at the code, but running ionice -p <pid> on a -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org --

Are you running with noatime or relatime? One quick thing to try that might show what is going on is to run debugfs on the device where your mail directory is located, while claws is running, and then use the debugfs command "logdump -a" to dump out the contents of the journal. You can then use ncheck and icheck to take the FS block numbers from logdump and translate them to inode numbers, and then from inode numbers to pathnames. That might give us some insight as to what is going on. I ...

Maybe. And maybe marking all journal writeout and all commit activity as sync would have the same effect with less downside. But it'd be better to not wait on this IO at all, if poss.. --

Agree, would be much better... -- Jens Axboe --

Yes, it'll report '0' which means 'not set'. The kernel inteprets 'not set' as the default values, BE/4. There's a big diffence, since '0' means that we track CPU nice values where as if it returned be/4 then that is a strict/fixed setting. -- Jens Axboe --

On Thu, 2 Oct 2008 21:22:23 +0200 This change will cause _all_ kjournald writeout to have elevated priority. The majority of that writeout (in data=ordered mode) is file data, which we didn't intend to change. The risk here is that this will *worsen* latency for plain old read(), because now kjournald writeout will be favoured. There is in fact a good argument for _reducing_ kjournald's IO priority, not increasing it! A better approach might be to mark the relevant buffers/bios as ...

This is true unless the journal gets too full, and we need to do a checkpoint operation --- at which point, everything stops. If this was metadata-intensive a benchmark, and the journal wasn't large enough, this could be the problem. (And if you make the journal bigger, then when you *do* finally get forced to do a checkpoint operation, things get stalled for even longer.) Arjan, is this *really* about atime updates? I thought most poeple these days run with noatime or relatime. If people ...

Actually I don't think I changed anything, did I? IIRC, I just pointed you at the API :-) -- Jens Axboe --

That's what XFS has always done - mark the journal I/O as sync. Still, once you load up the elevator, the sync I/O can still get delayed for hundreds of milliseconds before dispatch, which was why I started looking at boosting the priority of the log I/O. It proved to be much more effective at getting the log I/O dispatched than the existing "mark it sync" technique.... The RT folk were happy with the idea of journal I/O using the highest non-RT priority for the journal, but I never got ...

Well, jiffies should also be monotonic, but I don't know their exact Something like do_posix_clock_monotonic_gettime() in linux/time.h. I I just created two patches which instrument RCU callbacks and call_rcu in classic and preempt RCU to the -lttng tree to show how simple it is once the LTTng infrastructure is in place. Basically, all you need to do is to pull this tree (branch 2.6.27-rc8-lttng-0.31) : git://git.kernel.org/pub/scm/linux/kernel/git/compudj/linux-2.6-lttng.git And ...

Hello! This patch adds stalled-CPU detection to Classic RCU. This capability is enabled by a new config variable CONFIG_RCU_CPU_STALL_DETECTOR, which defaults disabled. This is a debugging feature to detect infinite loops in kernel code, not something that non-kernel-hackers would be expected to care about. This feature can detect looping CPUs in !PREEMPT builds and looping CPUs with preemption disabled in PREEMPT builds. This is essentially a port of this functionality from the treercu ...

There will be at least one non-dyntick CPU if there are RCU callbacks pending. If there are no RCU callbacks pending, then RCU won't be OK, I think I see the disconnection here... When RCU detects a stall, that often indicates that some CPU is spinning in the kernel (for !CONFIG_PREEMPT) or that some CPU is spinning in the kernel with preemption disabled (for CONFIG_PREEMPT). The stack trace will normally show what is spinning. Tracing the RCU activity in this case will not help -- it ...

OK. I thought jiffies were monotonic (though not perfectly correlated to the passage of time). This is a warning timeout, so does not need better than a few percent accuracy, as long as time never jumps too far. I just dump stack, which historically worked pretty well. Could you please tell me more about what you think should be added? --

could you be a bit more specific, why do those warnings show up and why dont we care about them? There are things like networking that i think this is a very good idea in general - often the question comes up whether a hang seen in the RCU code is indeed caused by RCU or other factors. Could you perhaps rebase it against tip/core/rcu ? [or tip/master for convenience] Ingo --

Hi, I just did some modifications to drivers/hwmon/it87.c in order to handle the IT8720 chipset and I would like to know where I can propose my modifications. Thanks, Regards, Jean-Marc --

It may be a little odd, but I have a 64-bit x86 that I'm running 32-bit kernel. Mostly because I had some odd problems with various programs I was using. But was what more odd was the fact that I had a little less memory (~100mb) with a 64-bit kernel than with a 32-bit PAE kernel. -- Lab tests show that use of micro$oft causes cancer in lab animals Got Gas??? --

Please apply to 2.6.27 This is related to regression bugzilla: http://bugzilla.kernel.org/show_bug.cgi?id=11382 This patch is meant to prevent all future corruptions of the e1000e NVM (non volatile memory) after the driver is loaded. The registers stay locked until the machine is power cycled. This should allow us to move forward with debugging without allowing any other bad element or the e1000e driver, to write to the NVM area unexpectedly. Currently we (Intel Ethernet) are ...

Hi, thanks. We have been running our tests with complete pileup of 12 patches from Intel, and the bug didn't trigger so far (and it triggers now pretty reliably with the unpatched kernel in the setup Karsten has established in our testing environment). So the patches really seem, as far as our current testing goes, to at least workaround the problem. I will now try to isolate which of the patches really fixes the problem, so that we could understand better what is going on and who ...

From: Bruce Allan <bruce.w.allan@intel.com> Set the hardware to ignore all write/erase cycles to the GbE region in the ICHx NVM. This feature can be disabled by the WriteProtectNVM module parameter (enabled by default) only after a hardware reset, but the machine must be power cycled before trying to enable writes. Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> CC: arjan@linux.intel.com --- drivers/net/e1000e/e1000.h | ...

there's quite a few of that yes. These are all fixed afaik but these fixes are being queued for 2.6.28 rather than being snuck in late into .27 (the patches have been posted to lkml a few times the last week) --

Support the Matrox G200eV chip, based on timings that I found in the X.org matrox driver. Signed-off-by: Darrick J. Wong <djwong@us.ibm.com> --- drivers/video/matrox/matroxfb_base.c | 9 +++++++++ include/linux/pci_ids.h | 1 + 2 files changed, 10 insertions(+), 0 deletions(-) diff --git a/drivers/video/matrox/matroxfb_base.c b/drivers/video/matrox/matroxfb_base.c index c021362..8e7a275 100644 --- a/drivers/video/matrox/matroxfb_base.c +++ ...

This patch adds a config option for the 9P RDMA transport. Signed-off-by: Tom Tucker <tom@opengridcomputing.com> Signed-off-by: Latchesar Ionkov <lionkov@lanl.gov> --- net/9p/Kconfig | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/net/9p/Kconfig b/net/9p/Kconfig index ff34c5a..c42c0c4 100644 --- a/net/9p/Kconfig +++ b/net/9p/Kconfig @@ -20,6 +20,12 @@ config NET_9P_VIRTIO This builds support for a transports between guest partitions and a host ...

This file implements the RDMA transport provider for 9P. It allows mounts to be performed over iWARP and IB capable network interfaces and uses the OpenFabrics API to perform I/O. Signed-off-by: Tom Tucker <tom@opengridcomputing.com> Signed-off-by: Latchesar Ionkov <lionkov@lanl.gov> --- net/9p/trans_rdma.c | 1025 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 1025 insertions(+), 0 deletions(-) diff --git a/net/9p/trans_rdma.c b/net/9p/trans_rdma.c new file mode ...

yeah - and we already have the additional_cpus=x boot option, but a boot option is not generally useful to a distribution. Ingo --

Well then something is broken, but the fix is not to lower num_possible_cpus(), but to fix the root cause. How did you measure? And you mean total right? If it's total then it's ~32KB/CPU which is roughly similar to my 40k number (probably depends on CONFIG options) The standard way is __per_cpu_start - __per_cpu_end (on 64bit; or the other way round on 32bit). That segment is duplicated per CPU. Ok there are some dynamic data structures that scale too, so it's possible a little ...

On Thu, 2 Oct 2008 21:44:09 +0200 The prefix rewriting doesn't happen unless I boot with additional_cpus=0, maxcpus=1, or with this patch applied and the config option set. I think the rules for when/if the rewriting happens changed a while ago to avoid multiple switches and now it's not happening at all on this machine by default. Oh, and with NR_CPUS=512 I am seeing 1.6MB per-cpu data (I'll have to check that, but I remember being surprised at how big the number was.) --

Wouldn't this be better to have a runtime option? -hpa --

What do you mean with single cpu mode? e.g. the lock prefix rewriting is only determined by online CPUs, not possible CPUs. And this only affects the possible ones. I'm not aware of any other special mode with num_possible_cpus() == 1, An extra possible CPU is not that costly. A 64bit kernel with my old defconfig has about 40k of per CPU data which would be duplicated. And having real hotplug always require that option would be nasty. What you could probably do if you really worry ...

Is that going to fly? For the vast majority of task_structs this is now a wasted 4/8 bytes that won't be used. Jon. --

Do you purposely fall through to the next case statement here? If so, could you please add a comment. /* fall through */ -- Steve --

Sven and I started poking at the various USB host drivers on the flight back from Plumbers. I'll see if I can convert over a few here on the systems that I have and send over some patches. Jon. --

Clearly you have neither clue about real time nor about operating systems in general. Solaris, some BSDs and MacOSX use interrupt threads. Where exactly is the relation to realtime? The concept of interrupt threads is nothing which is in any way related to real time. It is a well known and pretty old concept in operating system design. The fact that real time operating systems benefit from interrupt threads is a totally different topic. tglx --

On Thu, 2 Oct 2008 14:31:46 -0700 one of the things irq threads gives you is that 'top' will show you which ones are eating cpu ;-) -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org --

You contradict yourself .. I said "Clearly threading irq handlers does have something to do with real time" then you say "they can be used for RT too" .. So my comments are clearly correct , they have "something" to do with real time. There exists a relationship of some kind or type. We need less insults on this list not more.. Maybe I could understand his reaction had I insulted him, but I didn't.. "Fair reaction" doesn't fit in this case .. Daniel --

Well, that's clearly wrong: threaded IRQ handlers are not tied to real-time in any way. Yes, they can be used for RT too but as far as the upstream kernel is involved that's at most an afterthought. and the "unless this patch isn't actually threading anything" bit does not parse at all. The patches execute hard-IRQ handlers from special what Thomas said was a strong but fair reaction to your obviously incorrect statement. What reaction did you expect? Ingo --

I'm concerned about the connection between the two, which is what I'm If they are connected (which I think we established) , then it's not out of line for me to discuss the direction of these changes as related to You know Steven, often times you start a conversation and you have no idea where it will end up.. You can't always control which direction it We already debated this fact Steven. real time and this type of threading are connected. It's not off topic to discuss ...

Here we go again Thomas.. You think you can have a conversation without The very fact that you mention it in your release notes .. You mention The fact that a direct relationship exists means that any threaded interrupt system needs to take into account the inevitable connection to real time since it will be used in that system as a core component.. If you can't effectively achieve real time with your system , than that's a problem that needs to be addressed. Daniel --

Why are you bringing up real time in this thread?? The thread has absolutely nothing to do with real time. This thread is about a better Again, this thread has nothing to do with removing spinlock level latency. You brought in this relationship with real time, just because real time uses threaded interrupts. This thread has nothing to do with real time. That is what Ingo, Thomas and myself are trying to ge through to you. The strong reaction from Thomas is that you just brought up ...

Your speaking for a lot of developers.. It's an RFC, it's coming from real time developers, it's real time connected, and this is the real time development list .. The issues I've brought up are specifically design comments/concerns related to future directions.. I was not at all speaking to your real Real time forum ? That's what this list is .. If you want this thread to People that don't care about real time related comments, they can stop reading the thread.. That's the nature ...

Thomas, Nice work, thanks for doing this. Little comments below. It would be nice to still keep the name of the parameters here. The above reads funny. How about something like: @quick_check_handler: Function called before the real interrupt handler. It checks if the interrupt originated from the device. This can be NULL. --

When we originally discussed this, there was an idea to modify the request_irq API to take this handler and an IRQF_THREADED type to mark the interrupt accordingly. I understand why it's a separate function in this implementation for ease of migration, but what do you think should happen in the end? Also, I suggest calling this something like "quiesce_device" because the quickcheck also needs to do that. We probably need some documentation eventually so people realize what this "quickcheck" ...

You know, it's funny you suggested that because I thought about going there. But there's probably some silly patent on that groundshattering Microsoft solution to the halting problem. Anyway, I like to think we in the Linux community trust developers to do the right thing more than Microsoft does :) Jon. --

On Wed, 1 Oct 2008 15:09:40 -0700 Your assumption was correct, disabling the group scheduler has fixed all the problems (except for the fact that when xruns do occur the values are still extremely large - but that's probably just version incompatibility between ALSA drivers in the kernel and libasound). Of course this suggests that the group scheduler is still borked, at least on amd64. Thanks for your help! Best regards, -- MS --

At one point there were other patches floating around to "fix" arm which were not correct. Are these problems seen on a pristine 2.6.27-rc4 kernel, or with other special arm patches applied? -Eric --

Ok, actually: first - sorry for the scattershot replies. I thought userspace was updated earlier, but: xfsprogs-2.10.1 (5 September 2008)... - Add packed on-disk shortform directory for ARM's old ABI, thanks to Eric Sandeen. and the original kernel change: [XFS] Pack some shortform dir2 structures for the ARM old ABI architecture. ... Note that userspace needs a similar treatment, and any filesystems which were running with the previous rogue "fix" will now see ...

I just added the wlan-ng usb driver (and stack) to the drivers/staging/ tree a few hours ago :) So yes, we do need to do this kind of migration, at the moment I am trying to track down all out-of-tree drivers that distros and users are relying on to get them into staging/ and then we can work on cleaning them up and moving them to the proper place in the kernel tree. Sound good? So, for this driver, should I do the same thing, as I don't think these devices are covered by any other ...

TJ you can answer me using arvidjaar (at) newmail dot ru. Hopefully one of them works. Re WPA2 - there is no information how to setup CCMP/AES (even if firmware supports it); so no WPA2. I do not mind but it is likely makes no sense for H-I now; and I do not own H-II myself so cannot work on it. If we are focusing on H-2/2.5, it would make more sense to make similar modifications to 7.22 driver set from Agere to avoid overlap with Orinoco. firmware download functionality (which is supported ...

I was hoping we could get it into David Woodhouses firmware tree. However I haven't had a response to my original message. I'll try again with a patch. Dave. --

My bad. Openpandora just opened for preorders *today* (PST) and sold out all 3000 units. I'm sure I mentioned it well after most of them were sold, so it's not my fault their Sounds like it *should* be a nice, modest, achievable goal, right? Something tells me it won't be that easy! More power to you. - Dave --

Cool. I'll post some patches against mainline kernel for booting minimal omap3 boards within next few days. So we should get at least beagle and overo booting to some extent, maybe with serial and musb. Tony --

We need to do start the journal before locking the page with jbd2. That prevent us from doing any block allocation in writepage() call back. So with ext4/jbd2 we do block allocation only in writepages() call back where we start the journal with credit needed to write a single extent. Then we look for contiguous unallocated logical block and request the block allocator for 'x' blocks. If we get less than that. The rest of the pages which we iterated in writepages are redirtied so that we try ...

For metadata, it makes sense. Pages get dirtied in strange order, and if writeback_index is jumping around, we'll get the seeky metadata writeback. Data makes less sense, especially the very high extent count from ext4. An extra printk shows that ext4 is calling redirty_page_for_writepage quite a bit in ext4_da_writepage. This should be enough to make us jump around in the file. For a 4.5GB streaming buffered write, this printk inside ext4_da_writepage shows up 37,2429 times in ...

That workload shouldn't be using that code path much at all. It's supposed to be the case that pdflush and balance_dirty_pages() do most of the writeback work. And that _used_ to be the case, but we broke it. It happened several years ago and I wasn't able to provoke anyone into finding out why. iirc the XFS guys noticed it because their throughput was fairly badly affected. --

Tested-by: Yasunori Goto <y-goto@jp.fujitsu.com> -- Yasunori Goto --

No. *Noone*, including the manufacturers, know the speed of the oscillator which is modulating the clock. What you have to do is average over a timespan which is long enough that the SSM averages out (a relatively small fraction of a second.) As for trusting the BIOS on this, that's a total joke. Firmware vendors You have to calibrate over a sample interval long enough that the SSM No, I'm saying the frequency modulation may be up to 2%. Typically it is something like ...

I'm not suggesting using the nominal value. I'm suggesting the measurement be done in the one and only place where there is perfect control of the system, the processor boot-strapping in the BIOS. Only the platform designers themselves know the speed of the oscillator which is modulating the clock and so only they should be calibrating the speed of the TSC. If this modulation really does alter the frequency by +/- 2% (seems high to me, but hey, I don't design motherboards), using an LFO, ...

It's not fixed for newer hardware. Larger systems still have multiple tsc frequencies. -- error compiling committee.c: too many arguments to function --

T24gMTAvMS8yMDA4IDM6NDY6NDUgUE0sIEguIFBldGVyIEFudmluIHdyb3RlOg0KPiBBbG9rIEth dGFyaWEgd3JvdGU6DQo+ID4gPiBObywgdGhhdCdzIGFsd2F5cyBhIHRlcnJpYmxlIGlkZWEuICBT dXJlLCBpdHMgbmVjZXNzYXJ5IHRvIGRlYWwNCj4gPiA+IHdpdGggc29tZSBiYWNrd2FyZC1jb21w YXRpYmlsaXR5IGlzc3VlcywgYnV0IHdlIHNob3VsZCBldmVuDQo+ID4gPiBjb25zaWRlciBhIG5l dyBpbnRlcmZhY2Ugd2hpY2ggYXNzdW1lcyB0aGlzIGtpbmQgb2YgdGhpbmcuICBXZQ0KPiA+ID4g d2FudCBwcm9wZXJseSBlbnVtZXJhYmxlIGludGVyZmFjZXMuDQo+ID4NCj4gPiBUaGUgcmVhc29u IHdlIHN0aWxsIGhhdmUgdG8gZG8gdGhpcyBpcyBi ...

This patch adds clflush_cache_range(), but it's not used anywhere. If you do need it, it'd be nice if the arguments were the same types as for flush_icache_range(), and if there were a comment describing why it is necessary for VT-d. And maybe the name could be more like Please use dev_info() here. I see you just copied this from x86, but we should fix x86, too. Or better, since this doesn't appear to be arch-specific, maybe this should be moved to drivers/pci/quirks.c Shouldn't ...

hm, that's not too nice - why not add it to arch/ia64/include/? Ingo --

Can you split this patch up? It contains several logically separate changes: - casting things to unsigned long long - adding stuff under #ifdef CONFIG_IA64 - page size changes This printk should include a clue, like the IOMMU ID and/or address These printks should include an IOMMU ID also (I assume a system can This should probably be a "dev_err(&pdev->dev," and include the These are pretty generic names (IOMMU_PAGE_SHIFT, IOVA_PFN, etc), but the definitions seem to be ...

hm, only the first patch applies to tip/master - the rest is already applied. So i applied the first patch to tip/tracing/markers: # a2b4a6c: markers: re-enable fast batch registration Could you please check latest tip/master: http://people.redhat.com/mingo/tip.git/README to make sure that i sorted them out correctly. Thanks, Ingo --

At Wed, 1 Oct 2008 23:47:34 +0300, No, it wasn't because it's not clear whether the patches are regression fixes. Mariusz, try sound git tree. Risto's patches are already there. git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git If it works, then try to cherry-pick the following two commits onto the vanilla kernel: - 8352a6fe67a0f804302b93178f2e13b66004a693 ALSA: snd-powermac: mixers for PowerMac G4 AGP - e25ae4fd3ccba79cfd5628642754a145394225f6 ALSA: ...

Hello. TOMOYO Linux is now trying to use CRED API, but some troubles were found. Thus, I want the below patch for TOMOYO Linux. Regards. ----- Subject: Add hooks for notifying of start/finish of an execve operation. This patch adds two hooks, security_start_execve() / security_finish_execve(), for notifying an LSM module of an execve operation is about to start and finish. TOMOYO Linux checks read and/or write permissions at security_dentry_open() if security_dentry_open() is called ...

Whatever in the driver uses lots of stack space needs to be fixed, plain an simple... no excuse for that. --

Not entirely, some pages could get trapped there for sure. But it is parallel allocations we are trying to guard against. Plus we already flush the pcp during reclaim for higher orders. -apw --

On Wed, 1 Oct 2008 13:30:59 +0100 Reviewed-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> --

On Wed, 1 Oct 2008 13:31:00 +0100 Reviewed-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> --

Hmmm. I would not expect to see any significant impact for this kind of workload as we should not be triggering capture for the lower order allocations at all. Something screwey must be occuring. I will go and reproduce this here and see if I can figure out just what causes this. -apw --

On Wed, 1 Oct 2008 13:30:58 +0100 Reviewed-by: KAMEZAWA Hiroyuki <kamezawa.hiruyo@jp.fujitsu.com> --

On a short look it looks okay to me. It seems to depend on the previous (or some other?) patch, so it did not apply to me.... But if you have only moved code, that should not break anything, right? ;-). -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

unrelated change that belongs into a separate patch. patch looks quite clean otherwise. Ingo --

Provide a means for UV interrupt MMRs to be setup with the message to be sent when an MSI is raised. Signed-off-by: Dean Nelson <dcn@sgi.com> --- Good question. Sometimes the obvious gets overlooked in the midst of Agreed. The change is needed by drivers/misc/sgi-xp once it has been modified to call uv_setup_irq() and uv_teardown_irq(). I'll move this change into that patch (or should it be in a patch all by itself?). Agreed and changed. The patch to drivers/misc/sgi-xp to call ...

The purpose of this call was to make sure that the page behind the virtual address has an associated struct page. That is the assumption: virt_to_page() will return something meaningful if and only if 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 --

btw., you can send a Reviewed-by: Roland McGrath <roland@redhat.com> line in that case - i'm sure Thomas will appreciate it. Ingo --

thanks for sorting it out! A CONFIG_CC_DISABLE_WARNING_ANNOTATIONS=y might be useful as well, which could be used periodically (by gcc folks) to check which warnings are hidden by annotations? Ingo --

Thank yoy for review! On Wed, 1 Oct 2008 09:38:04 -0700 It's unstable state. If someone frees some page, it's not full. But "seems" is not good, I'll remove "seems". Thanks, -Kame --

Looks good, I've applied patches 1-5. -- Jens Axboe --

Well, I would not have added it in the first place, but it was there. I already did the bdev_get_integrity() addon instead of the revert, so Do we need any on top of current for-2.6.28? I'll apply your series with the modified patch #5, it'll probably need a hand edit or two since I didn't revert the commit in question, but should be trivial to resolve. -- Jens Axboe --

>>>>> "Jens" == Jens Axboe <jens.axboe@oracle.com> writes: Jens> Too may BUG's there, me thinks, and the interface looks Jens> fragile. What if the bio is alreday done (bi_idx == bi_vcnt)? Good point! Obviously I've only used the function for bio splitting and not at completion time. Updated patch below. block: Find bio sector offset given idx and offset Helper function to find the sector offset in a bio given bvec index and page offset. Signed-off-by: Martin K. Petersen ...

Linus must have missed it I guess, because I think I did address it to him. If you or Matt or Andrew push it up, it might get taken seriously ;) --

I agree, it's pretty hard to see a situation where you'd want full swap-backed shm and not full swap-backed tmpfs. I'll spin up a patch to follow on my unification. -- Mathematics is the supreme nostalgia of our time. --

We actually fixed one in 6be2ded1d7c51b39144b9f07d2c839e1bd8707f1. It is not really a memory leak. But yes it was not releasing some the prealloc space memory. -aneesh --

Ok. Can you please add apic=verbose to the kernel command line so we get more detailed info about that ? Thanks, tglx --

OK. Of course since you asked for it, the problem refused to show up. It took about a dozen reboots before it appeared again. And then it took 3-4 reboots to make it go away. Full dmesg output is here: http://www.highlandsun.com/hyc/msg.rc7.bad.gz http://www.highlandsun.com/hyc/msg.rc7.ok.gz -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --

Right. Lets do it. MAX_DMA32 needs to be changed too. While you are at it: Could you make the association with the zones clearer? MAX_ZONE_DMA32_ADDRESS MAX_ZONE_DMA_ADDRESS, MAX_ZONE_DMA_PFN, MAX_ZONE_DMA32_PFN .... --

On Tue, 30 Sep 2008 12:23:13 +0200 Did you see the response I sent to the previous thread? Rgds --=20 -- 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.

Nevertheless I vote strongly for putting that check in _NOW_. It has proven that there is concurrent access and that's definitely a bug by Well, timing of events changes slightly over time and we definitely had some major changes in the last three years which influence timing (high res timers, dynticks, NAPI ....) Thanks, tglx --

I think that is possible, which is why the mutex patch would be good for the future. However we have not shown that to be happening as a root cause, but I don't rule it out. so, why now? Drivers since before the e1000/e1000e split had this same code, with no reports of problems. This code has been heavily tested, and one of the platforms easily reproducing this has been available for The flash control registers are documented in the ICH documentation, and are located at physical memory ...

A few minutes ago, I have actually just hit this, while debugging the issue on a kernel that had this patch included. I was not successful reproducing it yet though, but still it might be a pointer into direction where the real bug is. 15:49:07 linux-pr0e dhclient: Listening on LPF/eth1/00:15:58:c6:4a:ff 15:49:07 linux-pr0e dhclient: Sending on LPF/eth1/00:15:58:c6:4a:ff 15:49:07 linux-pr0e dhclient: Sending on Socket/fallback 15:49:07 linux-pr0e dhclient: DHCPDISCOVER on eth1 to ...

That was openSuse 11.1 without any patches Olaf -- Neo didn't bring down the Matrix. SOA did. --soafacts.com --

Ping DaveM. Does this look ok? What else would we need for you to remove your range checking from sparc? Thanks, Jesse -- Jesse Barnes, Intel Open Source Technology Center --

Yes, I've changed pci_get_pci_slot() to acquire the pci_bus_sem semaphore. Thank you for pointing this out. It will be fixed in v4 of this patch series, which I will send out after I receive the rest of your review comments. Thanks! /ac --

Alex-san, I noticed that changing pci_get_pci_slot() to acquire the pci_bus_sem might be not enough. If slot was created between pci_get_pci_slot() and pci_create_slot() by another thread in the following code, something wrong would happen I think. pci_slot = pci_get_pci_slot(bus, slot_nr); if (pci_slot) { if (pci_slot->hotplug) { result = -EBUSY; goto err; } if ...

| From: Yinghai Lu <yinghai@kernel.org> | can you boot with mtrr_cleanup_debug? | | also what is /proc/mtrr with disable_mtrr_cleanup? Shouldn't mtrr_cleanup_debug show the pre-cleanup MTRR settings? --

ah.. please pick up all of them from tip/master... x86: don't need to go to chunksize to 4G x86: mtrr_cleanup optimization, v2 x86: add mtrr_cleanup_debug command line x86: cleanup, remove extra ifdef x86: mtrr_cleanup hole size should be less than half of chunk_size, v2 x86: mtrr_cleanup safe to get more spare regs now x86: mtrr_cleanup prepare to make gran_size to less 1M x86: mtrr_cleanup try gran_size to less than 1M x86: change ...

Also, on a 64 bit box with 4Gb, it gives this: cicely:~# cat /proc/mtrr reg00: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 reg01: base=0x100000000 (4096MB), size=1024MB: write-back, count=1 reg02: base=0x140000000 (5120MB), size= 512MB: write-back, count=1 reg03: base=0x160000000 (5632MB), size= 256MB: write-back, count=1 reg04: base=0x80000000 (2048MB), size=2048MB: uncachable, count=1 Patch below cleans up formatting, with space for big bases and sizes (64 Gb). diff -p ...

can you boot with mtrr_cleanup_debug? also what is /proc/mtrr with disable_mtrr_cleanup? YH --

are you on latest tip/master? YH --

Yeah, it goes right on the Xeon: reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1 reg01: base=0x7ff00000 (2047MB), size= 1MB: uncachable, count=1 Will try your patch now. -- J.A. Magallon <jamagallon()ono!com> \ Software is like sex: \ It's better when it's free Mandriva Linux release 2009.0 (Cooker) for i586 Linux 2.6.25-jam18 (gcc 4.3.1 20080626 (GCC) #1 SMP --

I think I got the lesson although the assymetry matter is still not that clear to me. Anyway I also know that when you talk about code you prefer patches to plain english so I expect you'd like others do the same ;) Thank you, Domenico -----[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 --

I think it's great. The only nit I would change is to use "[%#llx-%#llx]" as we do in pci_request_region(). Bjorn --

Ok, just added new commits to make target_core_mod be able to run independently of iscsi_target_mod. This means that all mkdir(2) calls under $TARGET do not require iscsi_target_mod to be loaded. Next, following Joel's advice from LPC, I made target_core_configfs.c:target_core_register_fabric(), call request_module() to load $FABRIC_MOD instead of using do_configfs_mkdir() to kick off the registration process. This means that $FABRIC_MOD's init_module() is responsible for ...

Well, the idea is not necessarily making the configfs interface the easiest to use in the world by user directly through $CONFIGFS, but to make the CLI scripts that speak $CONFIGFS/target CLI, and of course the actual UIs for user that interact with generic target core and $FABRIC_MODs be as simple and elegent as possible. That is what I believe the balance that a configfs enabled generic target core provides to both the $CONFIGFS/target API and to $FABRIC_MOD maintainers looking to port ...

The the Initiator Port ACLs need to go under /sys/kernel/config/target/$FABRIC because the struct fabric_acl * will always contain fabric dependent config items. For example, Since these struct fabric_acl_t do *NOT* symlink directly back to target_core_mod under /sys/kernel/config/target/core/$HBA/$DEV, but to fabric_lun_t (iscsi_lun_t in my case) to Symlink to a /sys/kernel/config/target/core/$HBA/$DEV that has been registered with the generic target configfs infrastructure. Here is what I ...

Thanks, it's reasonably nice. The task of hitting all those cpumask_t users Not yet. Committing untested patches into git is the enemy of bisection; if one of my patches breaks an architecture, they lose the ability to bisect until its fixed. If it's a series of patches, we can go back and fix it. Now, once it's been tested a little, it's better for you to git-ize it and I'll send you patches instead. But I want some more people banging on it, and a run through linux-next ...

Thanks! -- Yasunori Goto --

Hi Ingo, I didn't see any follow up, so for clarification: there is nothing to fix in tip but the bug is there in kernels between 2.6.24 and 2.6.27. Could you push it to 2.6.27 and possibly to the stable trees? Stefan --

Applied to my linux-next branch, thanks. I assume you'll have Linus pull the driver updates later? Thanks, Jesse --

sure - applied to tip/x86/iommu, thanks guys. Ingo --

Those APIs are for drivers ... this is internal. I don't have any objection of my own, though I agree with Alex's remark that the printk is unnecessary and just adds clutter to the boot process. -- Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." --

Applied -- Jens Axboe --

Usual way socket stuff covers for that is to stick unsigned int __unused[8]; That is the normal socket approach. Eg in traditional BSD interfaces for Not really. Lots of socket types have operations that are essentially fd = socket(...) ioctl(fd, ....); close(fd); or similar. Traditionally ioctl is used for system changing stuff but that is just tradition. --

Please don't touch efi_runtime_services_t, if you do not go through UEFI standard procedure. It can not be extended in a non-standard way. Thinking about someone else adds another new field to efi_runtime_services_t in a conflict way. Best Regards, Huang Ying --

Hi, Russ, Yes. efi_call_virt6() is tied with standard EFI runtime services, so it may be not suitable for your need. What you need is just to do calling convention converting, like efi_call6 does. So I think it is better to just use your current implementation. Acked-by: Huang Ying <ying.huang@intel.com> Best Regards, Huang Ying --

Hello Jens, I have been following this thread trying to grasp a very nifty use case (high speed acquisition and storage of data) of splice. I think it would make a perfect example of splice functionality. What would the user space part look like to exercise this interface? And whoever writes Linux Device Drivers 4th edition or one of the kernel books; make sure this topic in is :-) Regards, -- Leon --

yes, that's very likely broken too in a standalone way as well - but to get the exact tree i tested i'd suggest: git checkout tip/master git merge tip/tracing/ring-buffer Ingo --

That should have been: "when the number of pages allocated for the buffers exceeded the number -- Steve --

As Ingo mentioned, you don't have this yet. And be happy that you don't ;-) Because the ring_buffer now allows for variable length entries, having a one size fits all entry is not optimal. But because C is not the best for typecasting, we have this macro to help solve the issue. Instead of registering everything into a single union and causing small fields to be large, we have a macro you can register your type with instead. -- Steve --

My original patch had a compile bug when NUMA was configured. I referenced cpu when it should have been cpu_buffer->cpu. Ingo quickly fixed this bug by replacing cpu with 'i' because that was the loop counter. Unfortunately, the 'i' was the counter of pages, not CPUs. This caused a crash when the number of pages allocated for the buffers exceeded the number of pages, which would usually be the case. Signed-off-by: Steven Rostedt <srostedt@redhat.com> --- kernel/trace/ring_buffer.c | 2 ...

that was for the type filter commit. The 3 patches i've picked up into tip/tracing/ring-buffer are: b6eeea4: ftrace: preempt disable over interrupt disable 52abc82: ring_buffer: allocate buffer page pointer da78331: ftrace: type cast filter+verifier Thanks, Ingo --

attached. You can get the broken tree by doing this in tip/master: git-merge tip/tracing/ring-buffer Ingo

ok, these latest ring-buffer updates cause more serious trouble, i just got this boot crash on a testbox: [ 0.324003] calling tracer_alloc_buffers+0x0/0x14a @ 1 [ 0.328008] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 [ 0.332001] IP: [<ffffffff8027d28b>] ring_buffer_alloc+0x207/0x3fc [ 0.332001] PGD 0 [ 0.332001] Oops: 0000 [1] SMP [ 0.332001] CPU 0 [ 0.332001] Modules linked in: [ 0.332001] Pid: 1, comm: swapper Not tainted ...

Hi, I could reproduce the bug on an intel architecture. I found where the problem is. I'll post the patch in a few hours. Gilles. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Gilles.Carry Linux Project team mailto: gilles.carry@bull.net Phone: +33 (0)4 76 29 74 27 Addr.: BULL S.A. 1 rue de Provence, B.P. 208 38432 Echirolles ...

On Thu, 25 Sep 2008 17:25:44 +0800 <looks> <regrets it> Why does this: t = DIV_ROUND_UP(EHCI_SHRINK_FRAMES * HZ, 1000) + 1; add "1000" to a jiffies value when it doesn't know what HZ is? It'll be adding anywhere from one second up to ten seconds to the timeout interval depending upon compile-time options. I suspect s/1000/HZ/ would improve things here. Or just delete it - doesn't the subsequent round_jiffies() do the same thing, only better? This code needs help, I ...

It's pointless doing !! on something which is already 0 or 1. --

brelse(0) is legal. Please do an fs-wide review for this. It shouldn't affect code generation because brelse() is inlined. --

Please don't split this up, it's always been a really stupid idea in extN. The only difference between secure, trusted and user attrs is that they go into a different namespace bit (and have different permission checking, but that's handled in the VFS). I have some upcoming patches to store a fs private flag in struct xattr_handler so that even those flags wrappers can go away, and each of the namespaces will just be five lines of code for the xattr_handler You seem to need the handler ...

Is there a documentation update for these? --

I've made some changes to the readdir(2) and getdents(2) man pages to make it clearer that the "dirent" structures used by these to syscalls are different from one another (old_linux_dirent vs linux_dirent), and also different from that used by glibc's readdir(3). (dirent) The changes are already pushed out to man-pages git. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; ...

The two basic and almost always necessary parts of a patch changelog are a) what was changed and b) why the change was made Your changelog had no b), hence nobody is likely to apply the patch. --

You mean do MAC checks in security_path_*() and return error code of security_path_*() in security_inode_*()? Then, method for passing the error code to security_inode_*() is a problem. It was possible to store the error code into current->security-> something. But now, it is impossible to store the error code into current->cred->security->something because current->cred is shared by multiple processes. To solve this problem, we everytime need to copy current->cred in security_path_*() and ...

I was just shooting in the dark ;-) I found the patch floating around Actually I have only that card... I'll try to borrow another one for testing. Btw, that card works fine under windows (on the same machine) and my N800 is happy with it too. Luca --

Please don't send multiple patches with identical titles - think up a good, unique, meaningful title for each patch. Please include a full changelog with each iteration of each patch. That changelog should explain the reason for playing games with This sequence appears twice and it would probably be clearer to This is copied three times and perhaps also should be factored out. Please note that an effort has been made to make mm/filemap.c look This sequence is repeated three or ...

hi, Tracepoints and markers seem to both have their place, with tracepoints being integral to kernel users, and markers being important for userspace. However, it seems to me like there is overlap in the code and an extra level of indirection when markers are layered on tracespoints. could they be merged a bit more? What if we extended DEFINE_TRACE() to also create a 'set_marker(marker_cb)' function where 'marker_cb' has the function signature: marker_cb(<tracepoint prototype>, ...

I seen your remark above about disabling timer interrupt on idle cpus. That's exactly nohz functionality, right? Maybe I misunderstood you and you meant "my monitoring interrupt" and not "generic system timer interrupt"? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

Hi, I am extremely satisfied with my intel dg33fb MB. Only two issues I have is onboard nic won't WOL and iTCO watchdog timer doesn't reboot the system. Steve, -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) --

Appears to work fine for me on my K8V Deluxe and K8V SE Deluxe.. anyway, i have a gigabyte X48 DQ6 board. the two realtek NIC's initially had problems, but fixes have been merged and it works excellent. Audio works(not the two separate channels for front), usb works, sensors work, ahci on both the jmicron and ICH works. --

The A8V on the other hand works flawlessly. I have been running one for My mythtv box runs a Q6600 on an Asus P5K which so for works great. It does have the occational odd message abour CRC errors from the network port (atl) although networking is working just fine. No idea what that is about, so I am not too concerned about it. I have used Asus boards for 15 years now, and I am not switching. Enough other boards have given weird problems that should be that I don't want to deal with ...

On Wed, 24 Sep 2008 12:16:02 +0100 Hmm... What do you mean manipulate? They all just read it, so I don't Right, they left that out of the simplified spec. Sneaky bastards. It's data->timeout_* is undefined when this function is invoked, so this card->host->ios.clock is just the upper bound on the clock, it might be running slower. This is why the host driver needs to calculate it (well that, and the fact that different controllers treat timeouts in If you put the calculation somewhere ...

On Sun, 14 Sep 2008 20:11:27 +0200 David, Alessandro: can we please have a review-n-ack of this one for 2.6.27 and earlier? Thanks. From: Marcin Slusarz <marcin.slusarz@gmail.com> When userspace uses SIGIO notification and forgets to disable it before closing file descriptor, rtc->async_queue contains stale pointer to struct file. When user space enables again SIGIO notification in different process, kernel dereferences this (poisoned) pointer and crashes. So disable SIGIO ...

For the archives, there is some public info on this now: http://lwn.net/Articles/299483/ cheers, Pádraig. --

great, thanks for checking! it has not caused any new problems in -tip testing either, and that means a couple of thousand test builds and test boots so far in the past week, so we've got the usual codepaths covered pretty well. With your test of the less common codepaths we should be pretty good in general. Ingo --

And I of course forgot to actually attach the patch. -- tejun

Tejun. Sorry, I'm not familiar with git. Would you please send me a link to download? In addition, I'm on vacation between 10/3 ~ 10/12. I will test it after I'm back. BRs, Joseph Chan -----Original Message----- From: Tejun Heo [mailto:tj@kernel.org] Sent: Thursday, October 02, 2008 9:43 AM To: Andrew Morton Cc: Scott Pitcher; linux-kernel@vger.kernel.org; linux-ide@vger.kernel.org; Joseph Chan Subject: Re: VIA SATA id 5372 & Pioneer DVR-215 DVD burner problem And I of ...

> I have AT91SAM9260-based board, kernel is 2.6.26.3. I'm using my RTC-patch with the same CPU. Custom AT91SAM9260 board, I'm using it with ".max_speed_hz = 1 * 1000 * 1000," instead of 2 MHz. Can you try with slower speed? My patch (rev 3) and this small ek_spi_devices[] modification should be enough. I have it on bus = 0, chip_select = 1, so I've also removed dataflash parts from ek_spi_devices[] (we're using NOR flash). But for you this is not needed. I also have a patch to add ...