I didn't manage to get through a bisection run for the warning - thanks to Sitsofe for doing it. The patch does eliminate the warning for me. Thanks, -- Kevin Winchester --

Add members for memory reclaim delay to taskstats, and accumulate them in __delayacct_add_tsk() . Signed-off-by: Keika Kobayashi <kobayashi.kk@ncos.nec.co.jp> --- include/linux/taskstats.h | 4 ++++ kernel/delayacct.c | 3 +++ 2 files changed, 7 insertions(+), 0 deletions(-) diff --git a/include/linux/taskstats.h b/include/linux/taskstats.h index 5d69c07..87aae21 100644 --- a/include/linux/taskstats.h +++ b/include/linux/taskstats.h @@ -81,6 +81,10 @@ struct taskstats { ...

Hi. This is v2 of accounting memory reclaim patch series. Thanks to Kosaki-san, Kamezawa-san, Andrew for comments and advice! These patches were fixed about the following. Against: next-20080605 1) Change Log o Add accounting memory reclaim delay from memcgroup. For accounting both global and cgroup memory reclaim, accounting point was moved from try_to_free_pages() to do_try_to_free_pages. o Drop the patch regarding /proc export for memory reclaim delay. Because it seems ...

Almost all users of this field need a PFN instead of a physical address, so replace node_boot_start with node_min_pfn. Signed-off-by: Johannes Weiner <hannes@saeureba.de> CC: linux-arch@vger.kernel.org --- arch/alpha/mm/numa.c | 2 +- arch/arm/plat-omap/fb.c | 4 +--- arch/avr32/mm/init.c | 3 +-- arch/ia64/mm/discontig.c | 19 ++++++++++--------- arch/m32r/mm/discontig.c | 3 +-- arch/m32r/mm/init.c | 4 +--- arch/mn10300/mm/init.c | 6 +++--- ...

__alloc_bootmem_node already does this, make the interface consistent. Signed-off-by: Johannes Weiner <hannes@saeurebad.de> CC: Ingo Molnar <mingo@elte.hu> CC: Yinghai Lu <yhlu.kernel@gmail.com> CC: Andi Kleen <andi@firstfloor.org> --- mm/bootmem.c | 25 ++++++++++++++++--------- 1 file changed, 16 insertions(+), 9 deletions(-) --- a/mm/bootmem.c +++ b/mm/bootmem.c @@ -610,6 +610,19 @@ void * __init __alloc_bootmem_low(unsign return ___alloc_bootmem(size, align, goal, ...

Introduce new helpers that mark a range that resides completely on a node or node-agnostic ranges that might also span node boundaries. The free/reserve API functions will then directly use these helpers. Note that the free/reserve semantics become more strict: while the prior code took basically arbitrary range arguments and marked the PFNs that happen to fall into that range, the new code requires node-specific ranges to be completely on the node. The node-agnostic requests might span node ...

alloc_bootmem_core has become quite nasty to read over time. This is a clean rewrite that keeps the semantics. bdata->last_pos has been dropped. bdata->last_success has been renamed to hint_idx and it is now an index relative to the node's range. Since further block searching might start at this index, it is now set to the end of a succeeded allocation rather than its beginning. bdata->last_offset has been renamed to last_end_off to be more clear that it represents the ending address of ...

link_bootmem handles an insertion of a new descriptor into the sorted list in more or less three explicit branches; empty list, insert in between and append. These cases can be expressed implicite. Also mark the sorted list as initdata as it can be thrown away after boot as well. Signed-off-by: Johannes Weiner <hannes@saeurebad.de> --- mm/bootmem.c | 23 ++++++++++------------- 1 file changed, 10 insertions(+), 13 deletions(-) --- a/mm/bootmem.c +++ b/mm/bootmem.c @@ -23,7 +23,6 ...

Introduce the bootmem_debug kernel parameter that enables very verbose diagnostics regarding all range operations of bootmem as well as the initialization and release of nodes. Signed-off-by: Johannes Weiner <hannes@saeurebad.de> --- mm/bootmem.c | 51 ++++++++++++++++++++++++++++++++++++++++++++------- 1 file changed, 44 insertions(+), 7 deletions(-) --- a/mm/bootmem.c +++ b/mm/bootmem.c @@ -34,6 +34,22 @@ unsigned long saved_max_pfn; bootmem_data_t ...

Change the description, move a misplaced comment about the allocator itself and add me to the list of copyright holders. Signed-off-by: Johannes Weiner <hannes@saeurebad.de> CC: Ingo Molnar <mingo@elte.hu> --- mm/bootmem.c | 14 +++++--------- 1 file changed, 5 insertions(+), 9 deletions(-) --- a/mm/bootmem.c +++ b/mm/bootmem.c @@ -1,12 +1,12 @@ /* - * linux/mm/bootmem.c + * bootmem - A boot-time physical memory allocator and configurator * * Copyright (C) 1999 Ingo ...

Hi, This is a complete overhaul of the bootmem allocator while preserving most of its original functionality. free_bootmem and reserve_bootmem become a bit stricter than they are right now, callsites have to make sure that the PFN range is contiguous but it might go across node boundaries. alloc_bootmem satisfying the allocation goal is more likely as the routines will try to allocate on the node holding the goal first before falling back as opposed to the original behaviour ...

I've consistently experienced the following bizarre problem since 2.6.20, all the way up to 2.6.25.3 (regressed yesterday and each of these kernels exposes this behaviour): /sys/devices/system/cpu/cpu0/cpufreq # grep . * affected_cpus:0 cpuinfo_cur_freq:800000 cpuinfo_max_freq:1866000 cpuinfo_min_freq:800000 scaling_available_frequencies:1866000 1600000 1333000 1066000 800000 scaling_available_governors:ondemand ...

Hi Linus, This is another series of fixes for V4L/DVB. This series is a little bigger, since I got some days in vacation, and, after that, it took me some time to process tons of emails and merge requests. Please pull from: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git master For several fixes (most are trivial ones): - Fix compat32 for ivtv and cx18; - several fixes on the newer cx18 and au0828 drivers; - several Kbuild fixes; - fix several ...

Peter Zijlstra found that taking down and bringing up a new CPU caused ftrace to crash the kernel. This was due to some arch calls that were being traced by the function tracer before the smp_processor_id was set up. Since the function tracer uses smp_processor_id it caused a triple fault. Instead of adding notrace all over the architecture code to prevent this problem, it is easier to simply disable the function tracer when bringing up a new CPU. Signed-off-by: Steven Rostedt ...

This patch increases size of driver internal response buffers. Some TPM responses defined in TCG TPM Specification Version 1.2 Revision 103 have increased size and do not fit previously defined buffers. Some TPM responses do not have fixed size, so bigger response buffers have to be allocated. 200B buffers should be enough. Signed-off-by: Marcin Obara <marcin_obara@users.sourceforge.net> --- linux/drivers/char/tpm/tpm.c 2008-06-05 22:12:47.000000000 +0200 +++ ...

This adds a USR1 signal handler to getdelays.c, which causes getdelays to close its logfile and reopen it (if '-w logfile' is specified). This is useful in situations when getdelays is running for a long time (i.e, the log file growing) and you need to rotate the logs but don't want to lose any log data. Signed-off-by: Scott Wiersdorf <scott@perlcode.org> --- --- Documentation/accounting/getdelays.c 2008-05-15 09:00:12.000000000 -0600 +++ Documentation/accounting/getdelays.c 2008-06-05 ...

2008-6-6 - 4:3 山p鉧t科y技C網v頁2設s計 我L們m的K宗f旨c：客戶的每ㄧ件小事情，都是山鉧的大事情 我9們6S在r推出企業形象網站包含前台網頁美工+後台管理程式 限P時L限o量b專案價 只要$24,900 (在送ㄧ年100MB 不限流量網站空間) 我l們k做a的8不W只0是l網X站，而m是9您N企y業Z的z入I口 ㄧv個t好Y的s企k業j網e站3資9料d即M時R更J新w的Z速6度X是P很U重7要l的 企C業ｅ化N高M品3質D團l隊，打w造x您a的D網t路K門y面 選5擇4山F鉧C成V就4您o的H夢36想 歡迎來電洽詢黃專員：0_9_8_0_1_1_9_8_1_2 ←4×v℃b＋E∴

Not in the drivers/pci/pci-driver.c case because the setting of cpus_allowed to nodecpumask is only temporary (as is the disabling of the mempolicy). It's just done for the probe callback and then reset to the old cpumask. So any migration here would be lost. I can't speculate about the net/sunrpc/svc.c case because I don't know if user migration is harmful or discouraged. The behavior with my patch is the same for any calls to set_cpus_allowed_ptr() for tasks that haven't called ...

Kthreads that have called kthread_bind() are bound to specific cpus, so other tasks should not be able to change their cpus_allowed from under them. Otherwise, it is possible to move kthreads, such as the migration or software watchdog threads, so they are not allowed access to the cpu they work on. Cc: Peter Zijlstra <peterz@infradead.org> Cc: Paul Menage <menage@google.com> Cc: Paul Jackson <pj@sgi.com> Signed-off-by: David Rientjes <rientjes@google.com> --- include/linux/sched.h | 1 ...

Having central servers (and having to worry about the redundancy of said Hmm, not bad. I usually have to go for a walk or two to come up with good project names.. :-) --

from: Jaroslav Franek When the Linux kernel is compiled with CONFIG_DEBUG_SHIRQ=y, the Soundblaster Audigy2 ZS Notebook PCMCIA card causes the system hang during boot (udev stage) or when the card is hot-plug. The CONFIG_DEBUG_SHIRQ flag is by default 'y' with all Fedora kernels since 2.6.23. The problem was reported as https://bugzilla.redhat.com/show_bug.cgi?id=326411 The issue was hunted down to the snd_emu10k1_create() routine: /* pseudo-code */ snd_emu10k1_create(...) ...

On Thu, 5 Jun 2008 13:07:35 -0700 (PDT) The options above GOANY are included in GOANY. Previously, GOANY did not support GOOLPC, so GOOLPC was listed after it. Now that GOANY supports GOOLPC, it can be listed above w/ the others. Plus, _I_ think it looks nicer. :) That hunk can easily be removed from the patch if others disagree. --

So the Salomonic solution is: You pick it up and send it either to Jesse or x86@kernel.org :) I put it into my urgent bucket just to be on the safe side. Thanks, tglx --

-- ~Randy --

If the user tries to read from a position that is not a multiple of 8, or read a number of bytes that is not a multiple of 8, they have passed an invalid argument to read, for the purpose of reading these files. It's not an IO error because we didn't encounter any trouble finding the data they asked for. Signed-off-by: Thomas Tuttle --- fs/proc/proc_misc.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/proc/proc_misc.c b/fs/proc/proc_misc.c index ...

Since pagemap is all about examining pages mapped into processes' memory spaces, it makes sense for kpagecount to return the map counts, not the reference counts. Signed-off-by: Thomas Tuttle --- fs/proc/proc_misc.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/fs/proc/proc_misc.c b/fs/proc/proc_misc.c index 32dc14c..5a16090 100644 --- a/fs/proc/proc_misc.c +++ b/fs/proc/proc_misc.c @@ -726,7 +726,7 @@ static ssize_t kpagecount_read(struct file *file, char ...

On Thu, 5 Jun 2008 14:38:10 -0400 This one is for 2.6.25.x? Is so, the maintainers are going to wonder why the heck we sent it to them. It does fix a bug, but it is far from clear what that bug is. Please include <ttuttle@google.com> in the signoffs. --

This one is for 2.6.26. Something more like this for 2.6.25.x: Because put_user bases its copy size on the size of the target pointer, not the source, it was copying only 1 byte rather than the intended 8. Spotted-by: Thomas Tuttle <ttuttle@google.com> Signed-off-by: Matt Mackall <mpm@selenic.com> diff -r 5030869d9ded fs/proc/task_mmu.c --- a/fs/proc/task_mmu.c Thu Jun 05 04:01:40 2008 +0000 +++ b/fs/proc/task_mmu.c Thu Jun 05 15:45:00 2008 -0500 @@ -531,7 +531,7 @@ return ...

-- Greetings Michael. --

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> --- 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 deletions(-) 0bae6d3f656139602f96e0ace2766a40d9da5725 diff --git ...

Hi Andrew, This removes quite a few instances of BKL usage in the bfs driver. Given the purpose and the user base of this driver, I do not believe that a finer-granularity lock than the big fat filesystem-wide mutex I have implemented here is needed. Please consider. Thanks, Dmitri --

This patch makes the following cleanups: o removing an unused variable from bfs_fill_super(); o removing unneeded blank spaces from pointer definitions. Signed-off-by: Dmitri Vorobiev <dmitri.vorobiev@movial.fi> --- fs/bfs/bfs.h | 4 ++-- fs/bfs/inode.c | 3 +-- 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a/fs/bfs/bfs.h b/fs/bfs/bfs.h index 70f5d3a..d1a6cd1 100644 --- a/fs/bfs/bfs.h +++ b/fs/bfs/bfs.h @@ -16,8 +16,8 @@ struct bfs_sb_info { unsigned ...

Commit 0f475b2abed6cbccee1da20a0bef2895eb2a0edd (ocfs2/net: Silence build warnings) made sense as far as it fixed compile warnings, but it was not required that it made the functions global. Signed-off-by: Adrian Bunk <bunk@kernel.org> --- fs/ocfs2/cluster/tcp.c | 44 ++++++++++++++++++++++++++------ fs/ocfs2/cluster/tcp_internal.h | 32 ----------------------- 2 files changed, 37 insertions(+), 39 deletions(-) dd88fbb63c1952663eed2f1d93b85a95938cf37c diff --git ...

This patch removes the obsolete and no longer used include/linux/pm_legacy.h Reported-by: Robert P. J. Day <rpjday@crashcourse.ca> Signed-off-by: Adrian Bunk <bunk@kernel.org> --- BTW: arch/arm/mach-sa1100/h3600.c:h3800_pm_callback() still tries to handle PM_{SUSPEND,RESUME}, but that's not touched by this patch. arch/frv/kernel/pm.c | 1 arch/mips/au1000/common/power.c | 1 arch/x86/kernel/apm_32.c | 1 include/linux/pm_legacy.h | 35 ...

From: Randy Dunlap <randy.dunlap@oracle.com> Note: for -next only, not mainline. Fix setup.c printk format warning: linux-next-20080605/arch/x86/kernel/setup.c: In function 'setup_per_cpu_areas': linux-next-20080605/arch/x86/kernel/setup.c:173: warning: format '%lu' expects type 'long unsigned int', but argument 2 has type 'ssize_t' Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> --- arch/x86/kernel/setup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- ...

Yep. will do... I'll report back as soon as I have tried.. -- Thomas --

Can you please verify with latest wireless-testing. git Thanks --

Hi list, I am trying to evaluate the performance of a Linux box when working as IP forwarder. I have a hardware traffic generator IXIA T400 on one end. On the other end, I have a Linux box with kernel 2.6.16 and quad-core xeon CPU. These two systems are connected through two crossover Gigabit cables and NICs. The traffic is sent from IXIA through one NIC to the forwarding machine and then it is forwarded back through the other NIC to IXIA. I have two issues related to SMP affinity. The ...

On Thu, Jun 5, 2008 at 10:16 AM, Anton Vorontsov Personally I think your v2 was better, and if I'm interpreting Pierre's comments correctly I think his main point is that instead of using the 'stock' probe/remove hooks for the spi mmc driver, the driver should be mildly reworked to provide a common block of code that can be used by both the OF and non-OF versions of the probe/remove routines. I also think that is the way to go. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab ...

Well, I mentioned the usb_add_hcd()-alike approach for the mmc_spi host... The absence of enthusiasm I equaled to "no". Heh. p.s. Btw, you forgot another downside of v2 approach: struct spi_driver duplication... Not sure if everyone will be happy about it. Though, v2 is only version where we can make modular OF_MMC_SPI. -- Anton Vorontsov email: cbouatmailru@gmail.com irc://irc.freenode.net/bd2 --

Ok, I also mentioned drivers/ata/pata_of_platform.c (OF version is using common code from drivers/ata/pata_platform.c). Please look there, and tell me if this is what you have in mind. (ignore _probe in the __pata_platform_probe name. Imagine I understand this. -- Anton Vorontsov email: cbouatmailru@gmail.com irc://irc.freenode.net/bd2 --

Here it is http://lkml.org/lkml/2008/5/23/299 + static struct spi_driver of_mmc_spi_driver = { ^^^ That reminds me v1. Here http://lkml.org/lkml/2008/5/25/5 you answered though, but there was no bottom line. I hope the bottom line is that we're now all happy to create another spi_driver to handle "OF MMC-o-SPI" devices..? -- Anton Vorontsov email: cbouatmailru@gmail.com irc://irc.freenode.net/bd2 --

ip_fast_csum() requires a memory clobber on its inline asm as it accesses memory in a fashion that gcc can't predict. The GCC manual says: If your assembler instructions access memory in an unpredictable fashion, add `memory' to the list of clobbered registers. This will cause GCC to not keep memory values cached in registers across the assembler instruction and not optimize stores or loads to that memory. The bug hasn't been noticed in FRV, but it has been seen in ...

From: Andrea Arcangeli <andrea@qumranet.com> Indeed, I meant mm_all_locks_mutex, this will fix it, or if you prefer a resubmit of the 2/3 let me know. Thanks! Signed-off-by: Andrea Arcangeli <andrea@qumranet.com> --- diff -r 082f312bc682 mm/mmap.c --- a/mm/mmap.c Thu Jun 05 17:30:17 2008 +0200 +++ b/mm/mmap.c Thu Jun 05 18:40:23 2008 +0200 @@ -2263,7 +2263,7 @@ static void vm_lock_anon_vma(struct anon if (!test_bit(0, (unsigned long *) &anon_vma->head.next)) { /* * The LSB of ...

From: Andrea Arcangeli <andrea@qumranet.com> With KVM/GFP/XPMEM there isn't just the primary CPU MMU pointing to pages. There are secondary MMUs (with secondary sptes and secondary tlbs) too. sptes in the kvm case are shadow pagetables, but when I say spte in mmu-notifier context, I mean "secondary pte". In GRU case there's no actual secondary pte and there's only a secondary tlb because the GRU secondary MMU has no knowledge about sptes and every secondary tlb miss event in the MMU always ...

This splits the list.h changes in patch number 1, mm_take_all_locks patch 2, and mmu-notifier-core becomes patch 3 as requested. mm_take/drop_all_locks have been cleaned up as requested to move the bitflips in proper methods outside the main vma loop. --

Hmm? There's 11 bits available - why would anyone want to assign bits from the sufficiently official (at least as far as AMD is concerned, I'm not sure I saw a precise statement on Intel's side) frame number bits? And even if they would, it would certainly take some control register bit to enable the feature, so shrinking the mask if that would ever happen would seem more appropriate. Bottom line - I'd suggest pushing both 32- and 64-bits up to 52. Jan --

When a 64-bit x86 processor runs in 32-bit PAE mode, a pte can potentially have the same number of physical address bits as the 64-bit host ("Enhanced Legacy PAE Paging"). This is a bugfix for two cases: 1. running a 32-bit PAE kernel on a machine with more than 64GB RAM. 2. running a 32-bit PAE Xen guest on a host machine with more than 64GB RAM In both cases, a pte could need to have more than 36 bits of physical, and masking it to 36-bits will cause fairly severe havoc. The ...

It should either be 52 bits or dynamic based on CPUID information. The latter is very expensive. If there end up being additional control bits assigned in this space we won't use them since we know the size of the address space (which won't include the control bits) and thus will leave them at zero. It's largely theoretical, since I believe Linux on x86-64 relies on virtual >= physical+N, where I believe N is about 3 bits, and the page table format or page size need to change to ...

If a process tries to read at a position that's not a multiple of 8, or for a count that's not a multiple of 8, they've passed an invalid argument to read (for this file), so we should return EINVAL.

I suppose you're right, people usually don't check those return codes. -- Mathematics is the supreme nostalgia of our time. --

This doesn't require that they read exactly 8 bytes, just that they read some multiple of 8 bytes. (They can read 8, 16, 24, etc..., just not something like 12.) --ttuttle --

Oh. I would seriously question doing that, because it would allow reads that are improperly split up to fail silently. What happens if someone tries to read 40 bytes, and (for some reason) it gets split into two 20-byte reads? Instead of "12345" they'll get "12.34." (where . is 4 zero or garbage bytes). I'd rather they get an error. --ttuttle --

I also got these after upgrading from 2.6.25.4 and also these messages: Jun 5 16:26:58 ps3 [ 20.763385] AER service couldn't init device 0000:00:02.0:pcie01 - no _OSC support Jun 5 16:26:58 ps3 [ 20.763385] AER service couldn't init device 0000:00:03.0:pcie01 - no _OSC support Jun 5 16:26:58 ps3 [ 20.763385] AER service couldn't init device 0000:00:04.0:pcie01 - no _OSC support Jun 5 16:26:58 ps3 [ 20.763385] AER service couldn't init device 0000:00:05.0:pcie01 - no _OSC support Jun ...

When trying to use pagemap to calculate the "proportional set size" [1] of a process, I discovered that there were often references to pages that could not be discovered by kpagecount. I changed kpagecount to return the number of times a page is mapped, rather than referenced, so kpagecount is more useful for determining how many processes are using a page. [1] PSS is the amount of memory used by a process, weighted by 1 / the number of processes sharing the memory -- so a 128K library ...

On Thu, 5 Jun 2008 11:04:21 -0400 so... afaict we have some fairly significant problems in here and a version 2 of the patchset is in order? If so, when preparing that patchset please do have a think about which of the fixes you believe should be backported into 2.6.25.x and prepare the patches so that those fixes come first, to ease that backporting. Thanks. --

While fiddling with pagemap, I discovered a bug in add_to_pagemap. When it is copying an entry that is not at the end of the buffer, it uses put_user to copy a u64 into a char* buffer. The problem is that put_user determines how much to copy based on the size of the *destination*, not the source, so it only copied one byte. To fix this, I replaced the call to put_user with a call to copy_to_user, as is used when copying the last (possibly partial) PFN into the buffer.

Okay, I've written a new patchset. Patch 1/4 simply changes things to use u64 pointers. It's not that big a patch, but if you're really uncomfortable backporting it, just stick a (u64*) before pm->out in 2.6.25.x. Other than that, I don't believe any of the other fixes need to be backported. They just tweak a couple of things (error code on unaligned reads, and which values show up in kpagecount), but don't repair any particularly broken bits. Please take a look at the new patchset and ...

Hmm, I read this backwards the first time through then. Rather than finding a small bug at the end of the buffer, you've found a REALLY BIG WEAR-A-BROWN-PAPER-BAG-ON-MY-HEAD BUG. Sigh. Some clever person (me?) probably removed a cast or changed a pointer type somewhere along the way and didn't notice the fallout because the MSBs still came through. I'm pretty sure we want to do the put_user because it's faster. On a 64-bit system, it boils down to a simple assignment. If we ...

But if the low-level driver has to handle all that, what are all the Well, I did try to implement it as an ALSA driver, but a) it didn't work, b) it was impossible to debug, and c) it ended up at about 10x the size of the OSS driver. So I figured it wasn't really worth the Hmm...I take it you're talking about the SSC driver? That is supposed to be usable on AT91 as well, so perhaps the right thing to do is porting the AT91 driver over to use it. I see you've added a few SSC-related ...

There is AC97 support in ASoC but there's no sound/soc/ac97? Briefly, the generic ALSA AC97 support is focused on handling standard AC97 parts without additional features while the ASoC layer requires more per-board setup but supports codecs with large extensions to the AC97 standard such as the additional of secondary I2S interfaces that can't readily be accomodated in the vanilla AC97 driver. For systems using only AC97 codecs with only small non-standard features the vanilla AC97 driver ...

At Thu, 5 Jun 2008 18:24:09 +0200, Mostly because of the difference of the target hardware design. From the very beginning, ASoC is designed specifically for mobile devices while ALSA is designed as a more generic abstraction. Ideally, more fusion would be possible, but practically it's not always worth. I don't think you want to merge codes between ext3 and reiserfs although both have similar "design goals" :) Takashi --

Ok, but why write a whole new driver instead of extending the existing Sounds like it could be solved by a thin adapter layer on top of a more Again, that sounds very useful in general, not only for SoCs. Power consumption is perhaps _more_ important on embedded systems than PCs, but I very much doubt that anyone would complain if their laptop The SSC hardware is essentially identical on the two platforms, and there's also a common driver of sorts in drivers/misc/atmel-ssc.c. So it ...

The daily built armel versatile D-I images [1] worked fine for me in qemu just a few days ago. They use 2.6.24. There's one issue [2] related to serial console, but graphics mode works fine. Cheers, FJP [1] http://wiki.debian.org/ArmEabiHowto [2] http://bugs.debian.org/484366 --

Following patch fixes the below warning message : arch/x86/boot/a20.c:118: warning: unused variable 'loops' ================================================= Signed-off-by : Manish Katiyar <mkatiyar@gmail.com> diff --git a/arch/x86/boot/a20.c b/arch/x86/boot/a20.c index 90943f8..d9f13bf 100644 --- a/arch/x86/boot/a20.c +++ b/arch/x86/boot/a20.c @@ -115,8 +115,6 @@ static void enable_a20_fast(void) int enable_a20(void) { - int loops = A20_ENABLE_LOOPS; - #if ...

I agree that 96bit truncation is obsolete and 128 bit should be used. However people might be using the current implementation and this patch could cause trouble for them. The question is if anybody really depends on the current behavior. Adrian --

You could register a new SADB algorithm id in pfkeyv2.h and add a new entry to the aalg_list analogous to how GCM is doing that in the aead_list. --

Hi! Here's do-while loop from generic arch_get_unmapped_area_topdown() from mm/mmap.c: do { /* * Lookup failure means no vma is above this address, * else if new region fits below vma->vm_start, * return with success: */ vma = find_vma(mm, addr); if (!vma || addr+len <= vma->vm_start) /* remember the address as a hint for next time */ ...

Signed-off-by: Jan Kara <jack@suse.cz> --- include/linux/quota.h | 5 +++- include/linux/quotaops.h | 65 +++++++++++++++++++++++++++++++++++---------- 2 files changed, 54 insertions(+), 16 deletions(-) diff --git a/include/linux/quota.h b/include/linux/quota.h index f9983ea..4e004fe 100644 --- a/include/linux/quota.h +++ b/include/linux/quota.h @@ -223,7 +223,10 @@ struct super_block; #define DQF_INFO_DIRTY (1 << DQF_INFO_DIRTY_B) /* Is info dirty? */ extern void ...

Hi; One of our buildfarm servers (HP Proliant DL380g5) gaves following BUG output and fails to boot while trying to "modprobe hpwdt" module with 2.6.25.4 + current stable-queue patchset + and some distro specific patches (but none of the patches touches drivers/watchdog/hpwdt.c) [...] hpwdt: New timer passed in is 30 seconds. BUG: unable to handle kernel paging request at 003ac122 IP: [<c0100009>] *pde = 00000000· Oops: 0000 [#1] SMP· Modules linked in: bnx2(+) joydev ipmi_si(+) ...

[Empty message]

For now, I'm keen to keep the firmware within the kernel, in the firmware/ directory where it can be included directly with no 'regressions'. I don't want the potential debate about firmware being in the kernel tree to get in the way of the real cleanups -- so if it's OK with you, I'll apply your patch and also move the firmware into the firmware/ directory? -- dwmw2 --

In message <1212667633.32207.205.camel@pmac.infradead.org>,David Woodhouse writ yes, it is troubling. along the same lines, this patch removes the pca200e/sba200e firmware from the kernel. the firmware will be in the next release of the userspace atm tools. i could move the ambassador firmware there as well if you would like. commit 7c3f98c136041deb6b9c02bed4481860b1e515d1 Author: Chas Williams - CONTRACTOR <chas@relax.cmf.nrl.navy.mil> Date: Thu Jun 5 12:01:03 2008 -0400 atm: ...

Since it had various regions to be loaded to separate addresses, and it wanted to do them in fairly small chunks anyway, switch it to use the new ihex code. Encode the start address in the first record. Signed-off-by: David Woodhouse <dwmw2@infradead.org> --- Not entirely sure how we can claim that the firmware is under GPL without providing its source in the preferred form for modification -- but transplanted the copyright blurb to the HEX file unmolested, nonetheless. drivers/atm/Kconfig ...

Commit 05f2d12c3563dea8c81b301f9f3cf7919af23b13 (x86: change GET_APIC_ID() from an inline function to an out-of-line function) introduced a compile warning arch/x86/kernel/io_apic_64.c: In function 'print_local_APIC': arch/x86/kernel/io_apic_64.c:1152: warning: 'v' is used uninitialized in this function in some debug code -- which is not enabled by default. This patch reverts the code changes in print_local_APIC. Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com> -- diff ...

I got this right after resuming from hibernation. Unfortunatelly, I don't have the kernel-sources anymore as I've actually upgraded to 2.6.25.4. Buffer I/O error on device sda1, logical block 0 lost page write due to I/O error on sda1 scsi 1:0:0:0: Direct-Access WD 5000AAKS Externa 106a PQ: 0 ANSI: 4 sd 1:0:0:0: [sdb] 976773168 512-byte hardware sectors (500108 MB) sd 1:0:0:0: [sdb] Write Protect is off sd 1:0:0:0: [sdb] Mode Sense: 11 00 00 00 sd 1:0:0:0: [sdb] Assuming drive ...

Hi. RFC. Rewrite the vmap allocator to use rbtrees and lazy tlb flushing, and provide a fast, scalable percpu frontend for small vmaps. XEN and PAT and such do not like deferred TLB flushing. They just need to call vm_unmap_aliases() in order to flush any deferred mappings. That call is very expensive (well, actually not a lot more expensive than a single vunmap under the old scheme), however it should be OK if not called too often. The existing vmalloc API is implemented on top of the ...

so it could fallback to normal numa. also decouple genericarch numa with acpi. Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 3105e40..ef48cb9 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -310,12 +310,12 @@ config X86_VISWS and vice versa. See <file:Documentation/sgi-visws.txt> for details. config X86_GENERICARCH - bool "Generic architecture (Summit, bigsmp, ES7000, default)" + bool "Generic ...

Hi Yinghai Lu. Some random comments after skimming through the diff. In general I like the simplification moving numaq. But there is too much ifdef going on - and it can be done better. Part of this may belong in a followup patch - other parts I counted several places where you test for the above. Can we move these dependencies to Kconfig? It should looks roughtly like this in the Makefile: obj-$(CONFIG_X86_NUMAQ) += numaq_32.o This ifdef should be found in a .h file ...

If we can be sure that elevating the page_count on a pagecache page will pin it, we can speculatively run this operation, and subsequently check to see if we hit the right page rather than relying on holding a lock or otherwise pinning a reference to the page. This can be done if get_page/put_page behaves consistently throughout the whole tree (ie. if we "get" the page after it has been used for something else, we must be able to free it with a put_page). Actually, there is a period where the ...

[Empty message]

[Empty message]

So I'd certainly like to see these early in the 2.6.27 series. Nick, will you just re-send them once 2.6.26 is out? Or do they cause problems for Andrew and he wants to be part of the chain? I'm fine with either. Linus --

Oh that's actually anothr thing I remember now that I posted the scalable vmap code... The lock I ended up hitting next in the XFS large directory workload that improved so much with the vmap patches was tree_lock of the buffer cache. So lockless pagecache gave a reasonable improvement there too IIRC :) --

Well, I should ask, is this purely an internal build detail? The developer (and user) should never ever see a .ihex file, outside of an active kernel compile. Wrapping the original firmware makes it more difficult to verify, compare and/or change. In-tree, we should see the vendor firmware blobs as shipped, with no wrapping or modification or anything. Any metadata can be added as a separate file. If .ihex is purely a temporary thing during compile, no big deal, ignore me. ...

I have an emi26/emi62 patch that I need to clean up a little ... Regards, Clemens --

IMO, if-and-only-if you are touching driver firmwares, you should not do anything but render them into their preferred form. It is useless churn that increases maintenance annoyances to convert an in-tree firmware to something other than the form it's in now, so you might as well get it right. Jeff --

Right. And now you are creating Yet Another Format, rather than rendering the firmware back into the preferred format: binary blob. _If_ you are changing form of current in-tree firmwares at all, there is no excuse not use direct binary blob -- the least common denominator for all relevant operations. Storing the firmware in .ihex is just as bad as storing the firmware in source code -- it's a pointless wrapper that makes firmware verification and updates far more difficult than they ...

If the sha1 sum of what is in the kernel tree differs from what the vendor provided, then it is OBVIOUSLY more difficult to verify that you have the original firmware as provided by the vendor. Put the binary blobs into the git tree, __without modification or wrapping__. Jeff --

It's a build-and-shipping detail, at least in the kernel source tree. Rather than putting binary blobs into git (which admittedly we could, but it's suboptimal), we just run them through 'objcopy -Oihex' first. It's not 'wrapped'; it's not any more difficult to verify, compare or change. -- dwmw2 --

Why do we need the .ihex format? We should be loading firmwares exactly as they come from the vendor, without any wrappers. Jeff --

Consider you added a 'c foo:bar r' permission to some cgroup and then (a bit later) 'c'foo:bar w' for it. After this you'll see a c foo:bar r c foo:bar w lines in a devices.list file. Another example - consider you added 10 'c foo:bar r' permissions to some cgroup (e.g. by mistake). After this you'll see 10 c foo:bar r lines in a list file. This is weird. This situation also has one more annoying consequence. Having many items in a white list makes permissions checking slower, sine it ...

Acked-by: Serge Hallyn <serue@us.ibm.com> Thanks. I suppose if it was deemed worth it, the other thing you could do would be to detect when you have a rule c foo:bar r and you add a rule c foo:(all) r --

Yes, I specifically wanted to make sure that the pgd was on the list from before it had any entries until after it has any, to make sure that no pmds escape visibility from xen_mm_pin_all(). (Note to self: put a memory barrier to make sure the list update is complete before/after I don't think so. When saving with preemption enabled, it first puts all processes in the freezer before entering stop_machine_run(); a process constructing a pagetable should be finished by the time it can ...

QWNrZWQtYnk6IEVyaWMgTWlhbyA8ZXJpYy5taWFvQG1hcnZlbGwuY29tPg0KDQpBbmQgdGhpcyBz aG91bGQgcmVhbGx5IGdvIHRocm91Z2ggdGhlIEFSTSB0cmVlLCBwbGVhc2Ugc3VibWl0IHRoZSBw YXRjaA0KdG8gUk1LJ3MgcGF0Y2ggc3lzdGVtLiBUaGFua3MuDQoNCkNoZWVycw0KLSBlcmljDQoN Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogR3Vlbm5hZGkgTGlha2hvdmV0 c2tpIFttYWlsdG86Zy5saWFraG92ZXRza2lAcGVuZ3V0cm9uaXguZGVdDQo+IFNlbnQ6IFRodXJz ZGF5LCBKdW5lIDA1LCAyMDA4IDQ6MzcgUE0NCj4gVG86IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5l bC5vcmcNCj4gQ2M6IGRicm93bmVsbEB1c2Vycy5z ...

Crud. Tested and confirmed, and this patches fixes it. Acked-by: Serge Hallyn <serue@us.ibm.com> Tested-by: Serge Hallyn <serue@us.ibm.com> thanks, --

Acked-by: Eric Miao <eric.miao@marvell.com> And this should really go through the ARM tree, please submit the patch to RMK's patch system. Thanks. (I have to send this again through my gmail account, please ignore the other copy if any, sorry for this) On Thu, Jun 5, 2008 at 4:37 PM, Guennadi Liakhovetski -- Cheers - eric --

Hi all, Changes since next-20080604: The hid tree fixed the conflicts with Linus' tree. The v4l-dvb tree no longer needed the fixup patch. The galak tree gained a conflict with the net tree. The wireless tree now has the same conflict (in the ps3_gelic driver) as the semaphore-removal tree. The rr tree gained a conflict with the net-current tree. The ldp tree suffered from the v4l-dvb struct members renaming. I have applied the following temporary patch for known build ...

Ok. Patch follows: Add a new optional module parameter 'cache_file' which causes nandsim to use that file instead of memory to cache nand data. Using a file allows the simulation of NAND that is bigger than the available memory. Signed-off-by: Adrian Hunter <ext-adrian.hunter@nokia.com> --- drivers/mtd/nand/nandsim.c | 214 +++++++++++++++++++++++++++++++++++++++----- 1 files changed, 190 insertions(+), 24 deletions(-) diff --git a/drivers/mtd/nand/nandsim.c ...

Back in the 2.2.13 kernel days, I would hook up 2 computers via serial ports and could use ddd/gdb to walk through the kernel on the 2nd computer. My old notes tells me I would enabled "Kernel Hacking -> Kernel support for GDB" when running "make menuconfig", and then add "gdb gdbttyS=1 gdbbaud=115200" when booting the 2nd computer. Is this still the way to do it? I'd like to play around with this again after many years of not having looked at the kernel internals. One of the things I ...

- need_forkexit_callback will be read only after system boot. - use_task_css_set_links will be read only after it's set. And these 2 variables are checked when a new process is forked. Signed-off-by: Li Zefan <lizf@cn.fujitsu.com> --- kernel/cgroup.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/cgroup.c b/kernel/cgroup.c index 15ac0e1..f5a1273 100644 --- a/kernel/cgroup.c +++ b/kernel/cgroup.c @@ -118,7 +118,7 @@ static int root_count; * extra ...

Hi Nishimura-san, your are right. Yes, of cource. I'll fix it. Thanks! --

On Thu, 05 Jun 2008 13:43:06 +0900 This will cause dead lock. And it seems this doesn't handle "attach failure". It will be helpful Documentation somewhere. Thanks, -Kame --

Oh, nice point out. good idea :) I'll fix it at next post. --

You are not handling task migration between groups, i.e.: # echo $$ > /cgroup/1/tasks Maybe you need to add this in cgroup_init_subsys(): - need_forkexit_callback |= ss->fork || ss->exit; + need_forkexit_callback |= ss->fork || ss->exit || ss->can_fork; and then we can do: if (need_forkexit_callback) { for (i = 0; i < CGROUP_SUBSYS_COUNT; i++) { ... } --

How does this controller affect performance? Do you have some numbers? Thanks, -- regards, Dhaval --

Yep, Tony Luck reported this yesterday as well. I'll work up a patch this morning. Bjorn --

Tested-by: Olaf Hering <olaf@aepfle.de> --

SATA on a dualcore G5 is broken, it happend between c3b25b32e8bef526cca748e1ba023c6bdd705a99..53c8ba95402be65d412a806cda3430f0e72cd107 irq 18: nobody cared (try booting with the "irqpoll" option) Disabling IRQ #18 ctrl alt del on the USB keyboard does not trigger a reboot. Sometimes the cursor stops blinking, sometimes just nothing happens after ctrl alt del. Does 53c8ba95402be65d412a806cda3430f0e72cd107 work for others on G5? --

Here's the patch. I reproduced the problem and verified that this fixes it. This should not add conflicts with any of the PNP patches that are currently in -mm (let me know if it does, of course). After all those patches, IORESOURCE_UNSET is never set by PNP, but it should still be harmless to check for it. PNP: skip UNSET MEM resources as well as DISABLED ones We don't need to reserve "unset" resources. Trying to reserve them results in messages like this, which are ugly but ...

Is it too early to ask how long before 2.6.26 is released? -- Ben (ben@fluff.org, http://www.fluff.org/) 'a smiley only costs 4 bytes' --

El Wed, 4 Jun 2008 20:36:24 -0700 (PDT) I got this on my dmesg; is this expected/harmaless? (btw The wireless driver oops that i reported is gone as it is the bluetooth one ;) [ 0.232963] system 00:08: ioport range 0x4d0-0x4d1 has been reserved [ 0.233020] system 00:08: ioport range 0x4000-0x40bf could not be reserved [ 0.233075] system 00:08: ioport range 0x40c0-0x40df has been reserved [ 0.233131] system 00:08: ioport range 0x400-0x40f has been reserved [ 0.233186] system ...

I've been bisecting that on Quad G5 (sata_svw): irq 18: nobody cared ..., then later endless ata1.00: exception..., blah blah, ata1: EH complete. It comes down to: commit a57c1bade5a0ee5cd8b74502db9cbebb7f5780b2 Author: Alan Cox <alan@lxorguk.ukuu.org.uk> Date: Thu May 29 22:10:58 2008 +0100 libata-sff: Fix oops reported in kerneloops.org for pnp devices with no ctl And the patch I'm finding successful is below: I won't sign it off, for all I know it's reverting part of what Alan is ...

i get the following oops trying to mount an ntfs partition on thinkpad t61 running a 64-bit kernel: BUG: unable to handle kernel paging request at ffffc20005bb0000 IP: [<ffffffffa004fd83>] :ntfs:load_system_files+0x6ce/0x1892 PGD 13bc0b067 PUD 13bc0c067 PMD 139491067 PTE 0 Oops: 0000 [1] PREEMPT SMP CPU 1 Modules linked in: nls_utf8 ntfs loop i2c_i801 i2c_core ehci_hcd uhci_hcd video output joydev evdev Pid: 1884, comm: mount Not tainted 2.6.26-rc5 #10 RIP: ...

kernel/built-in.o: In function `pick_next': /home/lizf/linux-2.6.26-rc4/kernel/sched_fair.c:738: undefined reference to `wakeup_preempt_entity' kernel/built-in.o: In function `check_preempt_wakeup': /home/lizf/linux-2.6.26-rc4/kernel/sched_fair.c:1194: undefined reference to `wakeup_preempt_entity' This patch: sched-delete-dead-stuff.patch ------------------------------------------------ From: Andrew Morton <akpm@linux-foundation.org> kernel/sched_fair.c:1170: warning: ...

"Smarter retry of costly-order allocations" patch series change behaver of do_try_to_free_pages(). but unfortunately ret variable tyep unchanged. thus, overflow problem is possible. Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> --- mm/vmscan.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: b/mm/vmscan.c =================================================================== --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -1317,7 +1317,7 @@ static unsigned long ...

sorry, this patch already get Rik-san's ACK. I'll append it and resend by this mail. ------------------------------------ introduce get_vm_event() new function for easy use vm statics. Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Acked-by: Rik van Riel <riel@redhat.com> --- include/linux/vmstat.h | 7 ++++++- mm/vmstat.c | 16 ++++++++++++++++ 2 files changed, 22 insertions(+), 1 deletion(-) Index: ...

add throttle to shrink_zone() for performance improvement and prevent incorrect oom. Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> --- include/linux/mmzone.h | 2 + include/linux/sched.h | 1 mm/Kconfig | 10 +++++++ mm/page_alloc.c | 3 ++ mm/vmscan.c | 62 ++++++++++++++++++++++++++++++++++++++++++++++++- 5 files changed, 77 insertions(+), 1 deletion(-) Index: ...

Hi I post latest version of page reclaim patch series. This patch is holding up very well under usex stress test over 24+ hours :) Against: 2.6.26-rc2-mm1 changelog ======================================== v6 -> v7 o rebase to 2.6.26-rc2-mm1 o get_vm_stat: make cpu-unplug safety. o mark vm_max_nr_task_per_zone __read_mostly. o add check __GFP_FS, __GFP_IO for avoid deadlock. o fixed compile error on x86_64. v5 -> v6 o rebase to 2.6.25-mm1 ...

change function return type for following enhancement. this patch have no behaver change. Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> --- mm/vmscan.c | 71 +++++++++++++++++++++++++++++++++++++----------------------- 1 file changed, 44 insertions(+), 27 deletions(-) Index: b/mm/vmscan.c =================================================================== --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -51,6 +51,9 @@ struct scan_control { /* Incremented by the number of ...

A lot of little things in here, a large chunk of it is backlog that accumulated while I've been (still) travelling. I should be done changing timezones every other day next week. Highlights: 1) Wired driver fixes from Jeff Garzik and co. 2) Wireless driver fixes from John Linville and co. 3) IPV6 bug fixes from HIDEAKI Yoshifuji et al. 4) IPSEC algorithm string name fix from Adrian-Ken Rueegsegger 5) Bluetooth rfcomm deadlock fix from Dave Young 6) Netfilter bug fixes via ...

This doesn't resolve the issue, alas. I'll hunker down to the bisection in the next few days. Thanks, Daniel -- Daniel J Blueman --

This patch will break some other parts of the DRM interface, I'll try and come up with one that is less likely do stop all the drivers working. The problem is there are binaries out there with bad userspace ioctl bits.. What I'll change it to do is at least allocate the size from the kernel definition not what the user passed in. The big problem we have with malformed requests is that userspace asks for one thing and expects another, so I should key the userspace from the ioctl nr and ...

Hi, Hm, like this? diff --git a/drivers/char/drm/drm_drv.c b/drivers/char/drm/drm_drv.c index fc54140..019bf1f 100644 --- a/drivers/char/drm/drm_drv.c +++ b/drivers/char/drm/drm_drv.c @@ -475,6 +475,9 @@ int drm_ioctl(struct inode *inode, struct file *filp, else goto err_i1; + /* Do not trust userspace, use our own definition */ + cmd = ioctl->cmd; + func = ioctl->func; /* is there a local override? */ if ((nr == DRM_IOCTL_NR(DRM_IOCTL_DMA)) && ...

Now that I'm digging into this a bit I'm thinking my issue has to do with the fix you put in place from back in Aug 2007 (commit 405849610fd96b4f34cd1875c4c033228fea6c0f): [MATH-EMU]: Fix underflow exception reporting. 2) we ended up rounding back up to normal (this is the case where we set the exponent to 1 and set the fraction to zero), this should set inexact too ... Another example, "0x0.0000000000001p-1022 / 16.0", should signal both inexact and underflow. ...

In that case the fix should be integrated into the patch which it is fixing. Well, it doesn't _have_ to be integrated because in this case it can precede acpi-pci-slot-detection-driver.patch. But we might as well fold it, to keep the commit noise level down. --

Hi Alex-san, I tried to test your patch using latest linux-next, but I could not apply your patch with the following messages: $ quilt push Applying patch patches/fakephp-construct-one-fakephp-slot-per-pci-slot.patch (Stripping trailing CRs from patch.) patching file drivers/pci/hotplug/fakephp.c Hunk #2 succeeded at 102 (offset 1 line). Hunk #3 FAILED at 116. Hunk #4 succeeded at 154 (offset 4 lines). Hunk #5 succeeded at 299 (offset 1 line). Hunk #6 succeeded at 314 (offset 4 ...

Alex-san, Thank you for updated patch. I'll try it. Unfortunately, I'm a little busy on the other jobs, so the test report might be delayed until the beginning of next week. Thanks, Kenji Kaneshige --

Hi Kenji-san, Sorry, that latest patch series was against Linus' tree, not Yes, thanks for pointing this out. I've fixed patch 1/4. I verified that patches 2, 3 and 4 apply cleanly against linux-next, so this should be the only fix you'll need. Sorry for the confusion. /ac commit c0175afea14cdaff3c33d894eb474eed1dcfa65d Author: Alex Chiang <achiang@hp.com> Date: Wed Jun 4 21:04:46 2008 -0600 Construct one fakephp slot per PCI slot Register one slot per slot, ...

This is what I am talking about. The SIGNAL_UNKILLABLE task (init) dequeues the pending SIGKILL and just ignores it. Then it returns to the user space with -EIO. But when we send SIGKILL, the sender wakes up the TASK_KILLABLE task, and after that fatal_signal_pending() is true. Once again, it is not hard to fix this problem in kernel/signal.c, but _perhaps_ the change in filemap.c makes sense anyway. Oleg. --

Think about ptrace_notify(). Don't get me wrong. As I said, I think this change would be nice (but I didn't think thoroughly yet), and it also allows us to cleanup (or fix?) ptrace_stop(). If I knew a better solution, I wouldn't have sent this patch ;) Yes, we can change all users of TASK_KILLABLE. But personally I think this would be wrong. I strongly believe this code current->state = TASK_KILLABLE; schedule(); should work "as expected". Btw, I don't completely agree with ...

You are right, write_cache_pages() is correct - I've wrongly undrestood Hmm, the fact is I've seen in my tests writepage() being called on a page which had its buffers removed. And because we attach buffers to a page in page_mkwrite() and in write_begin() I think we should not see such page. I've added more debug printings to the code to verify that the page has Honza -- Jan Kara <jack@suse.cz> SUSE Labs, CR --

See, this is what I meant. After your patch we have: #ifdef arch_provides_topology_pointers #define define_siblings_show_map(name) \ static ssize_t show_##name(struct sys_device *dev, char *buf) \ { \ unsigned int cpu = dev->id; \ cpumask_t siblings = topology_##name(cpu); \ return show_cpumap(0, &siblings, buf); \ } #define define_siblings_show_list(name) \ static ssize_t show_##name##_list(struct sys_device *dev, char *buf) \ { \ unsigned int cpu ...

um, what does this mean. Will you be sending an updated patch or should I drop those two or...? --

thanks for your reply. I appended five of the bunch of errors to this mail. They all lock the CPU for 11 seconds (just like the nfsd errors we had in February/April), so that could be a sign of them being the same bug. It seems to be the same problem. We've only seen this behaviour once on the one machine though. I'll keep a couple of webservers on 2.6.24.2 and some on 2.6.25.4, just to see what happens. Thanks! Kind regards, Tristan Jun 4 15:08:38 web10.c1.internal kernel: ...

map_page, actually, but effectively the same thing. However, all Not necessarily ... there's a safety vs performance issue here. As long as the iotlb mapping persists, the device can use it to write to the memory. If you fail to flush, you lose the ability to detect device dma after free (because the iotlb may still be valid). On standard systems, this happens so infrequently as to be worth the tradeoff. However, in virtualised systems, which is what the intel iommu is aimed at, ...

On Wed, 04 Jun 2008 18:56:35 +0200 If we use 4GB virtual DMA address space (as the patch does), we need 128 KB for the bitmap for one domain. With the RB tree, the memory consumption depends on how many addresses are mapped (it needs one entry for one address though we could merge multiple addresses). --

it seems that there is no definition of memory_read_from_buffer. Where is the function of memory_read_from_buffer defined? Is there a bug about the current function of acpi_table_show? --

Thanks Jean, I'll queue it in linux-next. Jesse --

It uses order-only in this line: $(objhdr-y) $(subdir-y) $(header-y) $(unifdef-y): | $(INSTALL_HDR_PATH)/$(_dst) $(unwanted) Not a big deal as this is only used during make headers_* Sam --

The make version used is # make -v GNU Make 3.80 Thanks the patch, the build failure is fixed but the kernel panics while booting the machine BUG: unable to handle kernel paging request at 0000000000003708 IP: [<ffffffff8026cd89>] __alloc_pages_internal+0xc0/0x3d3 PGD 0 Oops: 0000 [1] SMP last sysfs file: CPU 0 Modules linked in: Pid: 1, comm: swapper Not tainted 2.6.26-rc4-next-20080604-autotest #1 RIP: 0010:[<ffffffff8026cd89>] [<ffffffff8026cd89>] ...

You assume the interrupt is not shared. You can never do that on a normal x86 PC, for example. E.g. for a PCI card you don't know which irq Stuff that is useful for other driver writers and not only for userspace people should be added to Documentation/Docbook/uio_howto.tmpl. Unfortunately, I forgot to ask Uwe to do this, so I'll probably have to You have to write code there anyway, e.g. code that configures your GPIO as input, makes it generate interrupts and so on. And of course, ...

So your main objection against this patch is that you cannot use it Ever heard about system on chip? Not all platform devices need board How is this changing the UIO behavior? I'm modifying the uio_pdrv driver, which is a driver that you didn't even write yourself. And yet You don't have to accept it. I'll just repost my original driver and let someone else merge it then. / magnus --

Exactly what in my patch makes this platform driver only suitable for I'm not sure if silently and blindly are the first words that pop into my mind, but sure. Documentation is a good idea. Just let me know You propose that I put the callbacks in my board support code instead of modifying the driver. I don't think the board support level is the proper place for this code. The patch contains no board specific code, We can reuse this driver for _many_ different SuperH processor models. Most ...

Documentation/controllers/memory.txt is good guide :) <abstract> try_to_free_pages(): global reclaim entry point try_to_free_mem_cgroup_pages(): memcgroup reclaim entry point do_try_to_free_pages(): common layer Unfortunately, I don't know your requirement and memcgroup reclaim shold be mesured. I hope you explain your purpose and benefit more. Thanks. --

thanks, and playing with this is good too. I see the point that, on memcgroup enabled system, there are memcgroup memory reclaim points and try_to_free_mem_cgroup_pages() is called when the page charge reach the limit. So if we want to account delay for memory reclaim, we should account at both of try_to_free_pages() and try_to_free_mem_cgroup_pages(). Ah, sure. We have an issue that a process which accesses a DB sometime slows down. We want to know what causes it, without the ...

Thanks for the feedback Ingo. I'll test the above config and look at splitting up the patch. The difficulty is making each patch independently compilable and testable. Mike --

Does the below fix it? Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> --- kernel/sched.c | 15 +++++-- kernel/sched_rt.c | 109 +++++++++++++++++++++++++++++++++++++++++++++++++++--- 2 files changed, 115 insertions(+), 9 deletions(-) Index: linux-2.6/kernel/sched_rt.c =================================================================== --- linux-2.6.orig/kernel/sched_rt.c +++ linux-2.6/kernel/sched_rt.c @@ -280,6 +280,9 @@ static int balance_runtime(struct rt_rq ...

pid 4502's current affinity list: 3 pid 4502's current affinity list: 0,1,3 (above command now hangs) (ps output) 0xe0000060b5650000 4502 4349 0 2 S 0xe0000060b5650390 bash 0xe0000060b8da0000 4843 4502 0 2 D 0xe0000060b8da0390 bash Stack traceback for pid 4843 0xe0000060b8da0000 4843 4502 0 2 D 0xe0000060b8da0390 bash 0xa0000001007d44b0 schedule+0x1210 args (0xe0000060ba470ce4, 0xa000000100dae190, 0xe000006003129200, ...

That wouldn't help, as it runs on top of an hypervisor API. The wired part may be merged back with spider_net one day... With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft Centre The Corporate Village

Does this really only apply on top of 2.6.22? Which of the bewildering blizzard of time-fixup patches we've been exchanging do I need? :) -- `If you are having a "ua luea luea le ua le" kind of day, I can only assume that you are doing no work due [to] incapacitating nausea caused by numerous lazy demons.' --- Frossie --

It comes with glibc, and even ls uses it (for clock_gettime(), to determine what format to use for date display). Rebuilding for a test now. -- `If you are having a "ua luea luea le ua le" kind of day, I can only assume that you are doing no work due [to] incapacitating nausea caused by numerous lazy demons.' --- Frossie --

I think it's in there because it's part of the POSIX realtime extensions, so you should have to, as it were, assent to using something that's not as portable as just using libc. It makes more sense than libm, anyway. (It's completely moot for UML of course :) ) -- `If you are having a "ua luea luea le ua le" kind of day, I can only assume that you are doing no work due [to] incapacitating nausea caused by numerous lazy demons.' --- Frossie --

Signed-off-by: Robert Richter <robert.richter@amd.com> --- arch/x86/kernel/cpu/amd.c | 1 - arch/x86/kernel/cpu/amd_64.c | 1 + arch/x86/kernel/setup.c | 4 ++-- arch/x86/kernel/setup_64.c | 2 -- include/asm-x86/mmconfig.h | 6 ------ 5 files changed, 3 insertions(+), 11 deletions(-) diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c index 656b40a..99221f9 100644 --- a/arch/x86/kernel/cpu/amd.c +++ b/arch/x86/kernel/cpu/amd.c @@ -4,7 +4,6 @@ ...

ah yes, I thought this rang a bell... Happily I find that kerneloops now has links to bugzilla -- sorry i didn't my previous message... This issue should be gone as of 2.6.25, please let me know if it isn't. https://bugzilla.novell.com/show_bug.cgi?id=350017 http://bugzilla.kernel.org/show_bug.cgi?id=10252 thanks, -Len --

I gotcha! :-) max -= PFN_DOWN(bdata->node_boot_start); start -= PFN_DOWN(bdata->node_boot_start); + fallback -= PFN_DOWN(bdata->node_boot_start); if (bdata->last_success > start) { - /* Set goal here to trigger a retry on failure */ - start = goal = ALIGN(bdata->last_success, step); + fallback = start; -------------------------------- (*) + start = ALIGN(bdata->last_success, step); } (*) is root cause. "fallback" is set as 0, because start is index of bitmap at here. ...

Last_sidx is ok. But, last_offset seems to be used to manage some allocated smaller chunks than one page. I'm not sure last_eidx is ok. Bye. -- Yasunori Goto --

Even that blows. People all too easily forget about the end-to-end principle. If you want a system that scales well, you have to push as much work as possible to the ends and do as little as possible in the center. Applies here as well as in networking. If CELF funds 20 people to do such tests, they may be able to cope today. But the stream of developers keeps swelling, so even those 20 won't be able to cope long-term. Instead we have to enable everyone in the stream of developers to ...

Hi Peter and Mathieu, If so, I'd like to suggest below changes, - introduce below macro in marker.h #define DEFINE_TRACE(name, vargs, args...) \ static inline void trace_##name vargs \ { \ trace_mark(name, #vargs, ##args); \ } - remove __marker_check_format from __trace_mark - and write a definition in sched_trace.h DEFINE_TRACE(sched_switch, (struct task_struct *prev, struct task_struct *next), prev, next); Thus, we can remove fmt string and also ensure the type ...

Not sure how I missed the signed-off-by, but resent to Linus with your ack. Thanks --

Hi Peter. It looks like a simplification but there is actually a reason why it is done with a temporary fil in this way. Consider a kernel build that is being terminated with ctrl-c in the middle. If we when ctrl-c are hit are doing the final steps of genksyms then we will next time we type make consider all done and we will not redo the modversioning part of the rule because we have an updated .o file. We have this issue in other places in the build system but I have not audited the use ...

My patch doesn't change the policy. JBD aborts the journal when it detects I/O error in file data since 2.6.11. Perhaps this patch: http://marc.info/?l=linux-kernel&m=110483888632225 I agree. I understood that there is a case where we don't want to make the fs read-only when writing file data failed. OTOH there are people who want to make the fs read-only to avoid the damage from expanding. Introducing the tunable would be better. I'm going to send a patch to make this behavior tunable ...

I'm not completely sure which "it" you mean in "it is the default today" (seems like you mean errors=continue) but isn't remount-ro already the ext3 default? see commit: 1eca93f9cafdec4a332ace9b0fc0d3886d430c28 --

OK, you've convinced me that aborting journal because of EIO on data block isn't the best thing to do. But it is a bit problematic to return EIO to userspace - we usually find this in commit code so we work on behalf of kjournald and user already thinks the write has succeeded (which is basically problem of any cached write). So the best thing we can do is set AS_EIO on the mapping and hope userspace will notice (we report such error when user does fsync/sync/sync_file_range). Sending some ...

One difference between volanoMark and hackbench is cpu context switch. cpu context switch looks stable when I run volanoMark, but dones't look stable with hackbench. running queue is another difference. With volanoMark, running queue is quite stable. I tested it by #hackbench process 2000 with/without schedtool. If I don't kill most background processes (services), the result is still not stable. If I kill background processes, the fluctuation is within 0.5 seconds with or without ...

Thanks for the detailed tutorial Max. I'm personally still very skeptical. I really don't believe you'll ever be able to run multiple _demanding_ RT environments on the same machine. Now matter how many processors you've got. But even though I might be wrong there, thats actually OK with me. I, and I'm sure most, don't have a problem with dedicating a machine to a single RT env. You've got to hold your tongue just right, look at the right spot on the wall, and be running the RT patched ...

I add this type of class before sched_rt, so the next of sched_edf I think it can be done with an rb tree. The only tricky By now I'm facing some problems. I still have not clear what parameters a task forked from a sched_edf task should get, as it would involve some form of admission control, and how to deal with tasks that run longer than their nominal execution time (i.e., should we use some server mechanism to limit the amount of cpu they're using, or handle that in some other ...

Sorry, my math was bad. I gave you 0xffffffff8021d44f + 7 + 0x6f9cba, but it should have been 0xffffffff8021d44f - 17 + 0x6f9cba. Which is correct (as one would hope, it was a grasp at straws). Oh, wait. Is this a laptop? Do you suspend/resume? Suspend will free svm_data, and on resume, any launching a guest will definitely hit the oops you are seeing. Do you ever see this in dmesg? svm_cpu_init: svm_data is NULL on 0 thanks, chris --

Almost: ranma@melchior:~/src/linux-2.6.26-rc4.forcedwol$ gdb -q vmlinux Using host libthread_db library "/lib/libthread_db.so.1". (gdb) p/x 0xffffffff8021d456 + 0x6f9cba $1 = 0xffffffff80917110 (gdb) p/x &per_cpu__svm_data $2 = 0xffffffff809170f8 HTH, -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 --

Yeah, this is broken. What happens is: suspend: hardware_disable svm_hardware_disable kfree(svm_data) per_cpu(svm_data) = NULL resume: hardware_enable svm_hardware_enable if(!svm_data) printk("svm_cpu_init: svm_data is NULL on 0") at this point it is broken. Same would happen on an SMP box by simply doing offline/online of a CPU. This is definitely busted, looking into a patch. thanks, -chris --

I vaguely recall discussing this one before. Doesn't seem to have caused any problems in practice, but yeah, should go ahead and be more spec compliant here. Signed-off-by: Jarod Wilson <jwilson@redhat.com> -- Jarod Wilson jwilson@redhat.com --

OHCI 1.1 clause 5.10 requires that selfIDBufferPtr is valid when a 1 is written into LinkControl.rcvSelfID. This driver bug has so far not been known to cause harm because most chips obviously accept a later selfIDBufferPtr write. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> --- drivers/firewire/fw-ohci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux/drivers/firewire/fw-ohci.c =================================================================== --- ...

Thanks, closed. Rafael --

I think he means power down the g-sensors and related filters and A/D circuitry. The out-of-tree version of the HDAPS driver can do it as well. For what is it worth, I think drivers/accel is a good idea, and I think the other accel drivers should be moved there. -- "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 --

These chips are connected to either I2C or SPI - This is the 4th driver for (apparently) these same chips: http://docwiki.gumstix.org/Lis3lv02dq_spi.c http://svn.openmoko.org/branches/src/target/kernel/2.6.24.x/patches/lis302dl.patch Perhaps it would make more sense implement support for SPI bus on the laptop and use the SPI interface directly instead or --

Great to hear that you have started the new subsystem! It's also nice that you are still hesitant about the name because "industrialio" sounds for me too... let's say... industrial ;-) For accelerometers found in laptops and mobile phones, it will sound strange (although a name is just a name). Maybe "physicsio" (physics as "the Yes, so I'll keep my plan of first submitting the driver with the current interface, and latter updating the interface to the new subsystem when you have stabilised its ...

Agreed. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

Patch looks reasonable, although my head's spinning a bit over the Beware that the version becomes essentially meaningless once the code is merged into mainline. It cannot be used to identify the exact source code which a user is running - this is done via the main kernel version instead. All these comments you have sort-of look like kerneldoc only they aren't. I suggest that either they be converted to kerneldoc or the /** and This wakes up every 30 milliseconds which will make ...

This thread reminds me of another question about interfaces for using PAT. Are there any plans for making pgprot_writecombine() a generic interface that portable drivers can use to map PCI memory into userspace with WC turned on? (Falling back to uncached when WC is not available for whatever reason is fine for the case I have in mind) Maybe it's better to ask at a higher level: what's the right thing for a driver to do in an mmap method when it wants to expose PCI memory to userspace with WC ...

That's _one_ possible implementation. Quite frankly, I think it's the less likely one. It's much more likely that the cache read access and the store buffer probe happen in parallel (this is a really important hotpath for any CPU, but even more so x86 where there are more of loads and stores that are spills). And then the store buffer logic would return the data and a bytemask mask (where the mask would be all zeroes for a miss), and the returned value is just the You'd have to ...

I'd be very surprised if that was the case. But the unlock code needn't do that anyway. It could do movb reg,(byteptr) # clear PG_locked movb (byteptr+1),reg # load PG_waiters --

On Sat, May 31, 2008 at 10:41:13AM -0700, Greg KH wrote: > On Sat, May 31, 2008 at 10:47:15AM -0400, Dave Jones wrote: > > On Fri, May 30, 2008 at 05:32:50PM -0700, Greg KH wrote: > > > > > > Looks like this adds a new device id, I have no idea why they remove > > > another one at the same time... > > > > I sent a patch adding the missing ident to airlied a few weeks back. > > I think it's currently in -mm. > > Great. > > > The removal of the other id is a mystery to me. ...

[Empty message]

Great idea! This will allow us to clean up some of the dependency mess in the shared AVR32/AT91 drivers and get better compile-testing coverage. Acked-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com> --

--

ACK. Thanks, --mgross --

Can you merge it? --

I can reproduce the hang, except with a slightly different options. I have spotted the places where the watchdog is set up incorrectly. I shall post fixes shortly, once I have got them polished and tested. Feel free to throw them at your qemu. Also it's worth noting there's more breakage of the NMI watchdog for this configuration ("maxcpus=1 noapic") -- it fails to tick on the CPU #0 on my system for some reason, but that's well beyond the scope of this series, so I am not going to look ...

find them here: http://redhat.com/~mingo/misc/config-Thu_Jun__5_16_40_50_CEST_2008.bad http://redhat.com/~mingo/misc/log-Thu_Jun__5_16_40_50_CEST_2008.bad NOTE: you need to copy out and use the boot parameters from the boot log: [ 0.000000] Command line: root=/dev/sda6 console=ttyS0,115200 earlyprintk=se rial,ttyS0,115200 debug initcall_debug apic=verbose sysrq_always_enabled ignore _loglevel selinux=0 nmi_watchdog=1 profile=0 maxcpus=1 nosmp no_hz=off highres =0 noapic ...

Thanks. I figured out I cannot build an x86-64 kernel, because my i386 compiler does not support the target. Probably because of target library dependencies at the time I built my compiler. I would have to build a bare-iron cross-compiler for the x86-64 which I'd rather not to just to fix this small problem -- it usually takes a few days to sort out all the pesky details when doing such a build from scratch, so it better be well justified. However, the reason is quite clear to me -- the ...

Here is a patch for autofs4 to, hopefully, resolve this. Keep in mind this doesn't address any other autofs4 issues but I it should allow us to identify if this was in fact the root cause of the problem Jesper reported. autofs4 - leave rehashed dentry positive From: Ian Kent <raven@themaw.net> Correct the error of making a positive dentry negative after it has been instantiated. This involves removing the code in autofs4_lookup_unhashed() that makes the dentry negative and ...

Yes, I'll apply it an report back. Dont expect anything before early next week. Jesper -- Jesper --

i unapplied the reverts then applied your fix, and got this hang after 1.5 hours of testing: titan:~> netstat -nt Active Internet connections (w/o servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 65032 10.0.1.14:39454 10.0.1.19:3632 ESTABLISHED 10.0.1.14 is this box, Core2Duo dual-core. 10.0.1.19 is another box with 16 CPUs. Ingo --

On Thu, 5 Jun 2008, Ilpo J

It's still not in mainline as of rc5. -- Martin Michlmayr http://www.cyrius.com/ --

On Mon, 2 Jun 2008 16:53:37 +0400 I'm not necessarily against that idea. What I don't like is using a function for different things. So you'd need to restructure things a platform_get_attr("ocr") perhaps? I'm afraid I have not dealt enough with the embedded parts of the kernel to give a complete suggestion as to how this might be solved. My concern is building something OF specific right now, only to have to restructure things when the next firmware interface shows up and having to deal ...

Hi, Thanks Peter for the explanation... I agree with the above and that is the reason why I did not see weird values with cpu_time. But, run_delay still would suffer skews as the end points for delta could be taken on different cpus due to migration (more so on RT kernel due to the push-pull operations). With the below patch, I could not reproduce the issue I had seen earlier. After every dequeue, we take the delta and start wait measurements from zero when moved to a different rq. ...

Hm, I think without utrace, it gets out-of-sync once, so syscall entries and exits are swapped from that point on. With utrace, it gets out-of-sync _twice_, so it eventually looks fine. But the strace output definitely looks incorrect even with utrace: 5718 execve("./test2.sh", [], [/* 23 vars */]) = 1 5718 execve("", [0x840c001000100003, 0x26230c14203032, 0x8cb0008800140a81, 0xa643100801808402, 0x2400905000040088, 0x11600a0072000001, 0xad814a00402e0, 0x2200012464009344, 0x1180418512c40026, ...

Hi Jesse, I am going to take a stab at implementing this so we can see how much of an impact it will have. Cheers, Jes --

Thst isn't a simple question and rather depends upon the contractual arrangements don't you think ? If I offer to supply it by CD your software will be delivered by the postal service, from whom you did not buy the product. A company might have liability for the failure of its agents to perform Let me propose a different theory: ASUS thought a smaller 12MB download It's a mini virtual machine using the cpu extensions. It really shouldn't need any deeply magical kernel patches except maybe ...

On Mon, 19 May 2008 10:08:37 +0200 You might want to consider using the LED subsystem now that the MMC core exports a trigger. Look at my next tree for how sdhci uses it. Rgds Pierre

On Mon, 19 May 2008 11:49:53 +0200 So who should push this to Linus? If this set is the only patches depending on it, it would be easiest if I carry it in my tree. Rgds Pierre

Ack, we will gain at most 1-4 assembly instructions, in a function that WARN_ON(ret > 0 && ret != 1 || ret == INT_MIN) will do ;) I agree with you once more, I never thinked about a runtime check. I don't really want to see a WARN_ON(foo) after each call to get_ro or get_cd. But I'm sure if we specify "give me a positive value when a card is detected", someone will write gpio & bit, and three years later, someone will fall in the (gpio & lastbit < 0 case). So we should specify: "give ...

For the sake of safety, document that drivers should return only 1 or 0 from the get_ro() and get_cd() callbacks. Also document context in which these callbacks should be executed. wbsd driver modified to comply with this requirement. Also, fix mmc_spi driver to not return raw values from the platform get_cd hook (oops). Suggested-by: Marc Pignat <marc.pignat@hevs.ch> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com> --- On Thu, Jun 05, 2008 at 05:58:59PM +0200, Marc Pignat ...

Sorry it took me so long... Pavel 2.6.26-rc5: flash card is at /dev/hdc. Linux version 2.6.26-rc5 (pavel@amd) (gcc version 4.1.3 20071209 (prerelease) (Debian 4.1.2-18)) #303 SMP Thu Jun 5 12:04:18 CEST 2008 PAT disabled. Not yet verified on this CPU type. BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009f000 (usable) BIOS-e820: 000000000009f000 - 00000000000a0000 (reserved) BIOS-e820: 00000000000d2000 - 00000000000d4000 (reserved) BIOS-e820: ...

Hello Sathya, It took some time before I could have a closer look at the system on which I observed the strange kernel messages. Apparently the RAID controller (LSISAS3081E ?) is not connected directly to the 16 disks but via a SAS expander (Super Micro SC836 SAS Backplane with two LSI SASX28 Expander Chips -- http://www.supermicro.com/products/chassis/3U/836/SC836E2-R800.cfm). It will be a challenge to find out which component triggered the kernel messages and how to make the storage ...

Hmm, now "N" could be mistaken for "no access at all". From: Stefan Richter <stefanr@s5r6.in-berlin.de> Here is an attempt to translate the prompt and help text into something which is legible and, as a bonus, correct. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> --- arch/x86/Kconfig.debug | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) Index: ...

I'm going to bring this up one last time. Google currently already shows 1060 hits for this new error: http://www.google.com/search?q=%22unable+to+enumerate+USB+device%22&ie=UTF-8&o... This one is particularly interesting as it shows quite a few systems are affected: https://bugzilla.redhat.com/show_bug.cgi?id=446845 Given its apparent prevalence I'm still wondering whether this is really broken hardware in all cases or that there could be an error in detection in some cases. Note ...

Linus, was it your intention to signal that you would veto any uses of the current trace_mark mechanism, and wait for this hypothetical function-recompilation-splicing widget as a replacement? This is how some people are interpreting this old thread. A number of problems with the new idea were brought up, and no one appears to have taken interest in trying to build it to see if they can be overcome or if there are more. On the other hand, a number of concerns with the markers have ...

Hi all, Natalie reported that patch wasn't accepted. Please check this out. If I need to correct it somehow then pls let me know. V. ---------- Forwarded message ---------- From: Vitaliy Ivanov <vitalivanov@gmail.com> Date: Wed, Apr 16, 2008 at 3:34 AM Subject: [PATCH] Adding dummy release functions to avoid warnings. To: linux-kernel@vger.kernel.org, devzero@web.de, jsun@junsun.net, dwmw2@infradead.org Subject: [PATCH] Adding dummy release functions to avoid warnings. From: ...

Please see Documentation/kobject.txt - search for the text I expect that hgafb-convert-to-new-platform-driver-api-bugzilla-9689.patch which I merged yesterday will help here. --