(This applies on top of Nick's second tiny-shmem patch, which hasn't made it to mainline yet(!). But as this deletes tiny-shmem.c, you can probably ignore the rejects.) tiny-shmem shares most of its 130 lines of code with shmem and tends to break when particular bits of shmem get modified. Unifying saves code and makes keeping these two in sync much easier. before: 14367 392 24 14783 39bf mm/shmem.o 396 72 8 476 1dc mm/tiny-shmem.o after: 14367 ...

it seems should group them and then provide one index section... YH --

change enable_mtrr_cleanup to mtrr-cleanup, disable_mtrr_cleanup to nomtrr-cleanup. Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- Documentation/kernel-parameters.txt | 4 ++-- arch/x86/Kconfig | 2 +- arch/x86/kernel/cpu/mtrr/main.c | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-) Index: linux-2.6/Documentation/kernel-parameters.txt =================================================================== --- ...

That does collide with the (not always kept) convention of prefixing "no" to disable a boolean option, though. -hpa --

Especially since blk_start_queueing() is used as the unplug_fn() callback by the cfq scheduler, we'd better make it behave like a proper unplug function. That is to say, return immediately if the queue is stopped. Cc: stable <stable@kernel.org> Signed-off-by: Elias Oltmanns <eo@nebensachen.de> --- This is not a recent regression, so it might not be accepted as an rc fix. However, it most definitely is a bug and should go into a stable release. Applies to 2.6.27-rc8. block/blk-core.c | 6 ...

I'm not sure what this is supposed to do. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> diff -r 52e0cb95ef98 arch/x86/kernel/io_apic_32.c --- a/arch/x86/kernel/io_apic_32.c Sat Sep 06 15:18:06 2008 +1000 +++ b/arch/x86/kernel/io_apic_32.c Thu Sep 18 14:30:01 2008 +1000 @@ -346,9 +346,7 @@ static void set_ioapic_affinity_irq(unsi if (cpus_empty(tmp)) tmp = TARGET_CPUS; - cpus_and(cpumask, tmp, CPU_MASK_ALL); - - apicid_value = cpu_mask_to_apicid(cpumask); + apicid_value = ...

I have an USB wireless card: Netgear WG111v2. It is reported in syslog as: usb 4-2: Product: NETGEAR WG111v2 usb 4-2: Manufacturer: NETGEAR WG111v2 usb 4-2: SerialNumber: 000FB5D51ECA phy1: Selected rate control algorithm 'pid' phy1: hwaddr 00:0f:b5:d5:1e:ca, RTL8187vB (default) V1 + rtl8225 usbcore: registered new interface driver rtl8187 On ifconfig up, the card always locks up two very different systems: a relatively modern P4 desktop and P-MMX laptop with UHCI ...

On my EeePC 900 when the wired and wireless ethernet are enabled and the system is booted with pciehp.pciehp_force=1 the following when booting with the quiet parameter: pciehp: Device 0000:03:00.0 already exists at 3:0, cannot hot-add pciehp: Cannot add device 0x3:0 pciehp: Device 0000:01:00.0 already exists at 1:0, cannot hot-add pciehp: Cannot add device 0x1:0 This changed prevents the messages turning up during a quiet boot. Signed-off-by: Sitsofe Wheeler <sitsofe@yahoo.com> --

Could you split that into two patches, please? -hpa --

Looks good to me. Acked-by: H. Peter Anvin <hpa@zytor.com> I'll add it to tip:x86/mtrr in a bit. -hpa --

Of course. However since I unmounted and remounted /home the 'buffer' line is now only 59megs, and they are still not dropped when a program tries to malloc all the memory. I'll tell next time the problem shows up (it can take ten days) MemTotal: 190356 kB MemFree: 12300 kB Buffers: 59652 kB Cached: 21612 kB SwapCached: 5508 kB Active: 84868 kB Inactive: 78116 kB HighTotal: 0 kB HighFree: 0 kB LowTotal: ...

Hi lists, I'd like to report the following problem : after ~ 10 days' uptime on a Debian 2.6.26-1-686 kernel, my system becomes extremely sluggish and unresponsive and the OOM-killer starts targeting even innocent processes like identd or rsync (when the swap is disabled). The machine is low on RAM (192 MB) but this has never been a problem before. As for the slowness, strace shows that the brk() syscall takes ages to complete; the blocking processes are in the D state (and for some reason the ...

Hmm, sorry, for all of these new hooks which you introduce, you do not define empty cap_* versions and assign them when need in security_fixup_ops(). But you unconditionally call them if CONFIG_SECURITY=y. So if you compile a kernel with CONFIG_SECURITY=y --

Hi all, since I don't really understand the algorithm in jiffies_to_msecs() for HZ values that are not divisors or multiples of 1000 right now, I'd like to ask if somebody can tell me something about it. In particular, I'd like to know what we can assume wrt rounding, i.e. always round up / down, etc. In fact, I'm most interested in the case where the argument of jiffies_to_msecs() is close to zero. Can I safely assume that a non-zero argument will *always* result in a non-zero return ...

More often than not, on a warm boot I see something like this msg.new:[ 1.940031] Using local APIC timer interrupts. msg.new:[ 1.944031] APIC timer calibration result 466046 msg.new:[ 1.944031] Detected 0.466 MHz APIC timer. msg.new:[ 1.944031] APIC frequency too slow, disabling apic timer On cold boots it may see 12.5MHz, or may not... [ 2.000584] Using local APIC timer interrupts. [ 2.004067] APIC timer calibration result 12500236 [ 2.004080] Detected 12.500 MHz APIC ...

sys_kill has the per thread counterpart sys_tgkill. sigqueueinfo is missing a thread directed counterpart. Such an interface is important for migrating applications from other OSes which have the per thread delivery implemented. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> --- kernel/signal.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) Index: linux-2.6-tip/kernel/signal.c =================================================================== --- ...

sys_kill has a counterpart sys_tgkill which allows to send signals to a particular thread. sys_rt_sigqueueinfo is lacking such a counterpart. Aside of the asymetry it is a show stopper for migrating applications from other unix-alike RTOSes. The following patch series implements rt_tgsigqueueinfo and hooks it up for x86. Find below the raw documentation. Thanks, tglx ---- NAME rt_tgsigqueueinfo - Send signal information to a signal to a thread SYNOPSIS long ...

Not correct. MAX_DMA_ADDRESS is a virtual address. ISA_DMA_THRESHOLD is the last byte of _physical_ memory which ISA DMA can transfer: include/asm-x86/scatterlist.h:#define ISA_DMA_THRESHOLD (0x00ffffff) Incorrect. MAX_DMA_ADDRESS is the highest possible virtual DMA address: include/asm-x86/dma.h:#define MAX_DMA_ADDRESS (PAGE_OFFSET + 0x1000000) As we have already covered in the past, CONFIG_ZONE_DMA has to always be enabled on ARM because ARM always puts all memory in the ...

I have implemented highmem for ARM. To catch wrong usage of __pa() and __va() with out of range values, I added a range check when CONFIG_DEBUG_HIGHMEM is set. One issue is that bootmem.h uses __pa(MAX_DMA_ADDRESS). However MAX_DMA_ADDRESS on ARM is defined as 0xffffffff because there is usually no restriction on the maximum DMA-able address. RMK suggested that those places should be using ISA_DMA_THRESHOLD So what about this patch? diff --git a/include/linux/bootmem.h ...

Hi, The incremental patches at http://www.kernel.org/pub/linux/kernel/v2.6/incr/ seem to be missing all .1 patches, for example there are patches to take 2.6.25 from EXTRAVERSION = .2 to .17 but no patch for .0 > .1, attempting to apply patch-2.6.25.1-2 to 2.6.25 will fail on the Makefile as it does not have the correct starting version. I assume the patches are generated from a script and there is a bug, easily worked around by downloading the full 2.6.25.1 tarball but the full incremental ...

The per cpu clock events device output of timer_list lacks an association of the device to the cpu which is annoying when looking at the output of /proc/timer_list from a 128 way system. Add the CPU number info and mark the broadcast device in the device list printout. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> --- kernel/time/timer_list.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) Index: ...

/proc/timer_list resp. sysrq-Q is an important debug helper to analyse timer related problems. Make it more useful. Thanks, tglx --

In yesterday's linux-tip I was able to provoke this backtrace by repeatedly disabling and enabling the wifi on my EeePC 900: [ 786.455830] uvcvideo 1-8:1.0: no reset_resume for driver uvcvideo? [ 786.455835] uvcvideo 1-8:1.1: no reset_resume for driver uvcvideo? [ 786.458642] uvcvideo: Found UVC 1.00 device CNF7129 (04f2:b071) [ 786.485835] Restarting tasks ... <6>pciehp: Card not present on Slot(3) [ 787.160420] done. [ 787.197658] Trying to free already-free IRQ 18 [ 787.197726] ...

For a few seconds I thought it was diff going mad diff'ing exactly similar lines. This one could actually use some capitalization to reduce the possibility of similar problems in future - rename to write_IDT_entry and write_LDT_entry perhaps? Parag --

This turned up in a linux-tip from yesterday after resuming from a suspend on an EeePC 900: [ 1176.720189] ACPI: Preparing to enter system sleep state S3 [ 1176.745011] Intel machine check architecture supported. [ 1176.745011] Intel machine check reporting enabled on CPU#0. [ 1176.745011] Back to C! [ 1176.745011] BUG: sleeping function called from invalid context at kernel/mutex.c:207 [ 1176.745011] in_atomic(): 0, irqs_disabled(): 1, pid: 4513, name: pm-suspend [ 1176.745011] 3 locks ...

x86_64 does not do the lazy io-bitmap dance. Putting it in its own function makes i386's do_general_protection look much more like x86_64's. Signed-off-by: Alexander van Heukelum <heukelum@fastmail.fm> --- arch/x86/kernel/traps_32.c | 76 +++++++++++++++++++++++++------------------- 1 files changed, 43 insertions(+), 33 deletions(-) diff --git a/arch/x86/kernel/traps_32.c b/arch/x86/kernel/traps_32.c index dd183a2..78113d3 100644 --- a/arch/x86/kernel/traps_32.c +++ ...

Mark the exception handlers with "dotraplinkage" to hide the calling convention differences between i386 and x86_64. Signed-off-by: Alexander van Heukelum <heukelum@fastmail.fm> --- arch/x86/kernel/entry_64.S | 2 +- arch/x86/kernel/traps_32.c | 28 +++++++++------- arch/x86/kernel/traps_64.c | 31 +++++++++++------- include/asm-x86/traps.h | 73 +++++++++++++++++++++---------------------- 4 files changed, 72 insertions(+), 62 deletions(-) diff --git ...

Split out math_error from do_coprocessor_error and simd_math_error from do_simd_coprocessor_error, like on i386. While at it, add the "error_code" parameter to do_coprocessor_error, do_simd_coprocessor_error and do_spurious_interrupt_bug. This does not change the generated code, but brings the declarations in line with all the other trap handlers. Signed-off-by: Alexander van Heukelum <heukelum@fastmail.fm> --- arch/x86/kernel/traps_64.c | 36 +++++++++++++++++++++--------------- ...

Hi Oleg, As you stated in an earlier mail, the following code should handle all cases. I think delay==0 is fine now, we take the costly (but rare) path. int queue_update_delayed_work(struct workqueue_struct *wq, struct delayed_work *dwork, unsigned long delay) { int ret = 1; while (queue_delayed_work(wq, dwork, delay)) { unsigned long when = jiffies + delay; ret = 0; if (delay && ...

I'd say that the entry should just be for MISC DEVICES. MOUSE is covered/handled by INPUT DRIVERS. The L: and S: look OK to me. Please send a patch to linux-kernel@vger.kernel.org and to akpm@linux-foundation.org . Thanks, --- ~Randy --

Hello, I just wrote to Alessandro in order to have some suggestions about a misc device I wish to propose to this list, but he told me that he wants leave his maintanership. So which is the person should I send my requests about misc devices? He also asked to me to propose to this list a "patch" to remove him from the MAINTANERS file... if so the new entry should be: MOUSE AND MISC DEVICES [GENERAL] L: linux-kernel@vger.kernel.org S: Maintained Is taht ...

It is. Generic mice interface is maintained by Dmitry as part of linux input subsystem, and USB mice (usb hid) is maintained by me. -- Jiri Kosina SUSE Labs --

That's fascinating. I tried a simple test case in userspace: #include <stdarg.h> #include <stdio.h> void p(char *fmt, ...) { va_list args; va_start(args, fmt); vprintf(fmt, args); va_end(args); } On 32-bit, I'm seeing 32 bytes of stack vs 216 on 64-bit. Disassembly suggests it's connected to va_list fiddling with XMM registers, which seems quite odd. -- Mathematics is the supreme nostalgia of our time. --

Really 208 bytes for a va arg parameter declaration? I expected it to be simply a null terminated pointer list. --

Cool! I once did the same, although the code has severely bitrotted by now. Is the code available somewhere? Jörn -- "Error protection by error detection and correction." -- from a university class --

(Funny, I added vprintk precisely to fix the extra buffer issue in ext2/3 years ago, but never hit the rest of the kernel..) Use vprintk rather that vsnprintf where possible This does away with lots of large static and on-stack buffers as well as a few associated locks. Signed-off-by: Matt Mackall <mpm@selenic.com> diff -r 6841f3ce32be -r 9ac0727d59d8 drivers/cpufreq/cpufreq.c --- a/drivers/cpufreq/cpufreq.c Mon Sep 29 17:28:44 2008 -0500 +++ b/drivers/cpufreq/cpufreq.c Tue Sep 30 ...

I've got a better idea: use vprintk. -- Mathematics is the supreme nostalgia of our time. --

This seems like the right approach to me. I have pointed out a few stylistic issues below. On Tue, 2008-09-30 at 09:53 -0500, Jon Tollefson wrote: CodingStyle dictates that this should be: unsigned long end_pfn = ((physbase + size - 1) >> PAGE_SHIFT); Bad style. I think the convention would be to write it like this: struct node_active_region * Since this is using the early_node_map[], should we mark the function __mminit? -- Adam Litke - (agl at us.ibm.com) IBM Linux ...

Can you resend it with a proper Signed-off-by: line ? Thanks ! Cheers, --

Forgot to include Rafael on the previous one. Parag --

What's up with ksoftirqd? I'm pretty sure it hasn't used 14,676 years of CPU time. Linus current git on a Q6600 64b. jonsmirl@terra:~/fs$ ps aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.0 4016 884 ? Ss 07:27 0:01 /sbin/init root 2 0.0 0.0 0 0 ? S< 07:27 0:00 [kthreadd] root 3 0.0 0.0 0 0 ? S< 07:27 0:00 [migration/0] root 4 0.0 0.0 0 0 ? S< ...

[1.] One line summary of the problem Processes claim CPU indefinitely on Intel(R) Core(TM)2 Quad CPU Q6600 [2.] Full description of the problem/report Processes hang indefinitely (but might recover after 10min. or so) while executing forked tasks like sed, touch, mv, uic (Qt), grep etc. The processes claim a CPU, which may be for 2min. or 30min. and continue later on. This happens very often and changing the preemption model does not make a difference (be it Preemptible Kernel or Voluntary ...

On Tue, 30 Sep 2008 13:22:30 -0400 to be honest, this is really a case of panic("This stuff is really borken") if it passes some random value, what other api's does it pass a random value to ? (and in addition, random values to security critical APIs deserve a process kill, because it could well be an exploit attempt at guessing something. At least by not letting it live it's harder to get such type of exploits to be able to guess things. So imo, BUG() is the right answer) -- ...

The firegl ATI/AMD closed source proprietary driver has some 2,733 panics registered on kerneloops.org and recently SELinux was blamed for BUGing because of this driver. http://www.kerneloops.org/search.php?search=firegl_ioctl&btnG=Function+Search Basically it looks like the firegl_ioctl() function is calling capable() with a huge value. cap_capable dereferences an array (64 bits long) WAY off the end. I know a specific example would be referencing the array c.cap[0x7B4BB01]. As dumb luck ...

Well, you save a branch and won't get the pagefault so it does 'fix' the pagefault/panic from cap code. It doesn't tell us when others screw up and SELinux is still possibly going to BUG(). We are also going to actually be returning a permission decision not on what was requested but on something wholely different. I like mine better, but I'm ok with yours and can just do my changes in SELinux if this is how cap wants to handle it. I don't really like the idea of mutating the inputs and ...

I don't know, looking at the feelings on "Can userspace bugs be kernel regressions" leads me to believe that when we break something that once worked we are supposed to fix it. http://lwn.net/Articles/292143/ I don't think the proprietary closed source nature of the driver makes it any less our problem to not make changes which cause the kernel to Discouraging people who open source their drivers and put them in the kernel? obviously not. encouraging crap? well, I hope we fix Well, ...

----- Original Message ----- From: "Ray Lee" <ray-lk@madrabbit.org> To: "Janos Haar" <djani22@netcenter.hu> Cc: <linux-kernel@vger.kernel.org> Sent: Friday, September 26, 2008 11:12 PM No. :-) Thank you. If i will have a little time, i will do that.... Thanks, Janos Haar --

hi, at first: no, I didn't brick my thinkpad x61 :-) But: I have severe problems since 2.6.26 (jes) kernel: textmode consoles doesn't work most(!) of the time, sometimes the notebook crashes on boot, displaying garbage. The 2.6.24/xen kernel from ubuntu doesn't work with X, too. Suspend/resume doesn't work anymore with the 2.6.26/27 kernel, too (garbage on display) Its a x3100 chipset with 4GB ram, I don't use a highmem-kernel, so I've only 3 GB. Perhaps something with mem sharing between ...

You need to add O_DIRECT to the open call in the flags parameter (the second argument). (My brother tested this a year or so ago, and it worked for him). milton --

Haavard, On Tue, Sep 30, 2008 at 1:55 PM, Haavard Skinnemoen Are there other Atmel designs with this bug or only the chip with this CFI ID? I ask, because the check in u-boot is too generic; I found u-boot wrongly assumes wrong order for another Atmel part, not checking on a specific CFI ID. (Need to lookup the part numbers later at home). Regards, -- Leon --

applied to tip/x86/traps: # 9bb2b4f: x86_64: split out dumpstack code from traps_64.c # f616942: i386: split out dumpstack code from traps_32.c there were some interactions with other branches: 054efa5: Merge branch 'tracing/nmisafe' into x86/traps 9ecb7cf: Merge branch 'kmemcheck' into x86/traps 8955b63: Merge branch 'core/signal' into x86/traps ff1b7a8: Merge branch 'x86/signal' into x86/traps 76b22d8: Merge commit 'v2.6.27-rc8' into x86/traps b58c936: Merge branch ...

Hi Ingo, I intend to keep looking for possibilities to bring traps_32.c and traps_64.c closer to each-other. One trivial way (from my point of view) is to split out code into separate files. These two patches split out a large piece of code that has nothing to do with hardware traps. Are you willing to take those two patches? Or are they to intrusive? Patches are against the current master branch of the tip tree. The defconfigs compile fine and I ran some simple configs ...

The dumpstack code is logically quite independent from the hardware traps. Split it out into its own file. Signed-off-by: Alexander van Heukelum <heukelum@fastmail.fm> --- arch/x86/kernel/Makefile | 4 +- arch/x86/kernel/dumpstack_64.c | 567 ++++++++++++++++++++++++++++++++++++++++ arch/x86/kernel/traps_64.c | 549 -------------------------------------- 3 files changed, 569 insertions(+), 551 deletions(-) create mode 100644 arch/x86/kernel/dumpstack_64.c diff --git ...

looks useful to me. This hardcodes a "BKL is tied to preempt-off" assumption but that should be OK - when get rid of the BKL by turning it into a plain mutex we have to remember to remove this. applied the commit below to tip/core/locking, thanks Nick! Peter, does it look good to you too? Ingo ---------------> From 7317d7b87edb41a9135e30be1ec3f7ef817c53dd Mon Sep 17 00:00:00 2001 From: Nick Piggin <nickpiggin@yahoo.com.au> Date: Tue, 30 Sep 2008 20:50:27 +1000 Subject: [PATCH] ...

Hi, I'm late reporting this mainly because until now I wasn't sure whether this was a kernel issue or not. Since 2.6.27 I've had several times, but not always, that after I open the CD tray by pressing the eject button it spontaneously closes after a short delay. The delay varies between ~0 and ~2 seconds. A few times this has resulted in a DVD getting stuck halfway out because I had already staring taking it out after playing it with vlc. I've now also seen this happen two times ...

Yes, I'd seen that new rule, but: - that fix is already included in the udev version I'm using - I'm seeing the issue on /dev/hda (IDE DVD drive), not on /dev/sr* --

Does: /sbin/udevadm monitor --env print something while you see the tray closing? Does this also happen when you set: /proc/sys/dev/cdrom/autoclose to 0? Kay --

Thanks for the link. It cannot be hal in my case as I've disabled polling by hal for both drives using the 'hal-disable-polling' command. The bug report also mentions udev, but I'm not sure if that's it either as the bit in the report is about sr* devices, which is SCSI/SATA and the patch linked there is in Debian's udev. The udev changelog for Debian has: udev (0.125-4) unstable; urgency=medium * 60-persistent-storage.rules: do not run vol_id on media tray open events or the kernel ...

Finally, the goal of all these changes, add a hard SDIO interrupt handler which will be called directly from interrupt context. Nothing really tricky here, the patch adds a new function sdio_claim_hard_irq and moves the common code from sdio_hard_irq into __sdio_claim_irq. It also adds some code that calls the hard interrupt handler directly from interrupt context. One very important thing here is that since the hard interrupt handler will return immediately, it has to call sdio_release_host ...

To improve the latency of the SDIO operations, I've add asynchronous versions of sdio operations that split a blocking sdio call into a _start call which takes a callback and a _result function which gets the result from the last operation. The callback is called directly from interrupt context so this avoids the scheduling overhead from waking up the calling thread all the time. This makes a noticeable difference in latency and CPU load on slow embedded systems. To begin with the patch ...

Actually there is one call of virt_to_phys in the patch I sent. I don't know any way to replace virt_to_phys and still use remap_pfn_range. If all architectures support virt_to_phys, I see no reason to replace it with something else. The driver is legacy. --

Hi Artem OneNAND can support for full block read also in sync burst block read mode ,so why u want to limit bulk read only for 4 pages , with sync burst enable u can read max 64 pages. so in place of max 4 pages , u can set max to 64 it will be improve performance if sync burst mode is upported. Rgs Amit ----- Original Message ----- From: "Artem Bityutskiy" <dedekind@infradead.org> To: <linux-fsdevel@vger.kernel.org> Cc: <linux-mtd@lists.infradead.org>; "Adrian Hunter" ...

Yes, you're right. The pertinent part of the manual is: The `volatile' keyword indicates that the instruction has important side-effects. GCC will not delete a volatile `asm' if it is reachable. (The instruction can still be deleted if GCC can prove that control-flow will never reach the location of the instruction.) Note that even a volatile `asm' instruction can be moved relative to other code, including across jump instructions. I normally do my "asm ...

From: Adrian Hunter <ext-adrian.hunter@nokia.com> sync_fs can be called even if the file system is mounted read-only. Ensure the commit is not run in that case. Reported-by: Zoltan Sogor <weth@inf.u-szeged.hu> Signed-off-by: Adrian Hunter <ext-adrian.hunter@nokia.com> --- fs/ubifs/super.c | 19 ++++++++++--------- 1 files changed, 10 insertions(+), 9 deletions(-) diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c index 7e1f3ef..7fd759d 100644 --- a/fs/ubifs/super.c +++ ...

From: Adrian Hunter <ext-adrian.hunter@nokia.com> Bulk-read skips uptodate pages but this was putting its array index out and causing it to treat subsequent pages as holes. Signed-off-by: Adrian Hunter <ext-adrian.hunter@nokia.com> --- fs/ubifs/file.c | 16 +++++++++++----- 1 files changed, 11 insertions(+), 5 deletions(-) diff --git a/fs/ubifs/file.c b/fs/ubifs/file.c index 2f20a49..51cf511 100644 --- a/fs/ubifs/file.c +++ b/fs/ubifs/file.c @@ -595,7 +595,7 @@ out: static int ...

From: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> The "bulk_read" and "no_chk_data_crc" have only 2 values - 0 and 1. We already have bit-fields in corresponding data structers, so make "bulk_read" and "no_chk_data_crc" bit-fields as well. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> --- fs/ubifs/ubifs.h | 24 +++++++++++------------- 1 files changed, 11 insertions(+), 13 deletions(-) diff --git a/fs/ubifs/ubifs.h b/fs/ubifs/ubifs.h index d6ae3f7..542cbaf 100644 --- ...

From: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> --- fs/ubifs/super.c | 9 +++------ 1 files changed, 3 insertions(+), 6 deletions(-) diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c index cf078b5..dae1c62 100644 --- a/fs/ubifs/super.c +++ b/fs/ubifs/super.c @@ -1465,12 +1465,9 @@ out: * commit_on_unmount - commit the journal when un-mounting. * @c: UBIFS file-system description object * - * This function is ...

From: Adrian Hunter <ext-adrian.hunter@nokia.com> Also add debugging checks for LPT size and separate out c->check_lpt_free from unrelated bitfields. Signed-off-by: Adrian Hunter <ext-adrian.hunter@nokia.com> --- fs/ubifs/debug.c | 37 ++++++++++ fs/ubifs/debug.h | 6 ++ fs/ubifs/lpt.c | 3 +- fs/ubifs/lpt_commit.c | 185 ++++++++++++++++++++++++++++++++++++++++++++++--- fs/ubifs/ubifs.h | 10 ++- 5 files changed, 228 insertions(+), 13 deletions(-) diff ...

From: Adrian Hunter <ext-adrian.hunter@nokia.com> 'is_a_node()' function was reading from a buffer before checking the buffer length, resulting in an OOPS as follows: BUG: unable to handle kernel paging request at f8f74002 IP: [<f8f9783f>] :ubifs:ubifs_unpack_bits+0xca/0x233 *pde = 19e95067 *pte = 00000000 Oops: 0000 [#1] PREEMPT SMP Modules linked in: ubifs ubi mtdchar bio2mtd mtd brd video output [last unloaded: mtd] Pid: 6414, comm: integck Not tainted (2.6.27-rc6ubifs34 #23) EIP: ...

From: Adrian Hunter <ext-adrian.hunter@nokia.com> UBIFS read performance can be improved by skipping the CRC check when data nodes are read. This option can be used if the underlying media is considered to be highly reliable. Note that CRCs are always checked for metadata. Read speed on Arm platform with OneNAND goes from 19 MiB/s to 27 MiB/s with data CRC checking disabled. Signed-off-by: Adrian Hunter <ext-adrian.hunter@nokia.com> --- Documentation/filesystems/ubifs.txt | 6 ...

From: Adrian Hunter <ext-adrian.hunter@nokia.com> Signed-off-by: Adrian Hunter <ext-adrian.hunter@nokia.com> --- fs/ubifs/file.c | 10 ++++++++-- fs/ubifs/ubifs-media.h | 1 - 2 files changed, 8 insertions(+), 3 deletions(-) diff --git a/fs/ubifs/file.c b/fs/ubifs/file.c index cdcfe95..2f20a49 100644 --- a/fs/ubifs/file.c +++ b/fs/ubifs/file.c @@ -147,6 +147,12 @@ static int do_readpage(struct page *page) err = ret; if (err != -ENOENT) break; + } else if ...

From: Adrian Hunter <ext-adrian.hunter@nokia.com> Make garbage collection try to keep data nodes from the same inode together and in ascending order. This improves performance when reading those nodes especially when bulk-read is used. Signed-off-by: Adrian Hunter <ext-adrian.hunter@nokia.com> --- fs/ubifs/gc.c | 82 ++++++++++++++++++++++++++++++++++++++++++++++++++------- 1 files changed, 72 insertions(+), 10 deletions(-) diff --git a/fs/ubifs/gc.c b/fs/ubifs/gc.c index ...

From: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Znode may refer both data nodes and indexing nodes Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> --- fs/ubifs/ubifs.h | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/ubifs/ubifs.h b/fs/ubifs/ubifs.h index c3ac5a8..49b06c9 100644 --- a/fs/ubifs/ubifs.h +++ b/fs/ubifs/ubifs.h @@ -707,8 +707,8 @@ struct ubifs_jhead { * struct ubifs_zbranch - key/coordinate/length branch stored in znodes. ...

From: Julien Brunel <brunel@diku.dk> In case of error, the function kthread_create returns an ERR pointer, but never returns a NULL pointer. So a NULL test that comes before an IS_ERR test should be deleted. The semantic match that finds this problem is as follows: (http://www.emn.fr/x-info/coccinelle/) // <smpl> @match_bad_null_test@ expression x, E; statement S1,S2; @@ x = kthread_create(...) ... when != x = E * if (x == NULL) S1 else S2 // </smpl> Signed-off-by: Julien Brunel ...

From: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Commit the journal when the FS is sync'ed. This will make statfs provide better free space report. And we anyway advice our users to sync the FS if they want better statfs report. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> --- fs/ubifs/super.c | 12 ++++++++++++ 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c index dae1c62..7e1f3ef 100644 --- ...

I am getting my desired numbers. get_cycles()/cpu_khz gives the right time interval on x86 system. Parav --

applied to tip/tracing/ftrace, thanks Mathieu! Ingo --

Make tracepoints use rcu sched. (cleanup) Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> CC: Ingo Molnar <mingo@elte.hu> CC: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> --- kernel/tracepoint.c | 15 ++++++--------- 1 file changed, 6 insertions(+), 9 deletions(-) Index: linux-2.6-lttng/kernel/tracepoint.c =================================================================== --- linux-2.6-lttng.orig/kernel/tracepoint.c 2008-09-30 01:36:26.000000000 -0400 +++ ...

could you please send a delta patch against tip/master? Lai's patch is already applied and is tested. Thanks, Ingo --

Hrm, Most of Lai "simplifications" to use synchronize_sched() instead of call_rcu_sched() will make batch registration/unregistration much slower (very noticeable on ~50 markers on a loaded machine). It also contains two different fixes in one, one of which has been nacked. The correct list of changes against tip now becomes : Revert commit d587284c1d26b796bf52a6e3d3f783db4e462119 Apply patch "Markers : marker_synchronize_unregister()" Apply patch "Markers : probe example fix ...

Hi all, I am trying to find the entry point of USB data in the kernel. I have a USB device and I would like to find the latency between the time the data enters the kernel, and I read it in userspace. My first goal is to find where it actually enters the kernel. The host device driver obtains a URB and reads the data from urb->buffer. From digging around the kernel code, I had assumed the entry point for all USB data was in drivers/usb/core/devio.c::usbdev_read() ... but it seems ...

Yes, I am not filtering really. But if this code is for usbfs, then this is definitely not what I am looking for. I think what I am looking for might be in devices.c::usb_device_read() ... poking around there now. It calls usb_device_dump() which takes a user space buffer as a parameter for which it dumps data in to. Thanks for the response! - George --

Hi Linus ! The following changes since commit 94aca1dac6f6d21f4b07e4864baf7768cabcc6e7: Linus Torvalds (1): Linux 2.6.27-rc8 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge Those are two fixes for regressions introduced recently, the first one due to some change in the timer code becoming more sensitive to timer interrupts taken from offlined CPUs and the second is an update to a board device-tree to fix some ...

hm, in tip/master we already have ftrace_printk(), which allows such debug output to any of the active tracers. That is a far more useful way of debugging such things. See: http://people.redhat.com/mingo/tip.git/README and: http://redhat.com/~mingo/sched-devel.git/readme-tracer.txt note how much cleaner and more usable it will also become: no silly module flags or recompilation to activate this debug output, and no debug clutter in the syslog. if you enable tracing in the ...

currently if the driver notices a bad checksum it will fail to load. This patch allows the driver load process to continue with an invalid mac address and could allow the user to use ethtool or another app to fix the eeprom. copied from implementation in e1000 Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> --- drivers/net/e1000e/netdev.c | 81 ++++++++++++++++++++++++++++++++++++------- 1 files changed, 67 insertions(+), 14 deletions(-) diff --git ...

From: Bruce Allan <bruce.w.allan@intel.com> Set the hardware to ignore all write/erase cycles to the GbE region in the ICHx NVM. This feature can be disabled by the WriteProtectNVM module parameter (enabled by default) though that is not recommended. Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> --- drivers/net/e1000e/e1000.h | 2 ++ drivers/net/e1000e/ethtool.c | 3 +++ drivers/net/e1000e/ich8lan.c | 46 ...

applied to tip/x86/exports, thanks Jesse. Ingo --

From: Bruce Allan <bruce.w.allan@intel.com> Export set_memory_ro() and set_memory_rw() calls for use by drivers that need to have more debug information about who might be writing to memory space. this was initially developed for use while debugging a memory corruption problem with e1000e. patch was modified with this suggestion. Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Acked-by: Ingo Molnar <mingo@elte.hu> --- ...

Here's a patch that adds range checking to the sysfs mappings at least. This patch should catch the case where X (or some other process) tries to map beyond the specific BAR it's (supposedly) trying to access, making things safer in general. FWIW both my F9 and development versions of X start up fine with this patch applied. DaveM, will this work for you on sparc? It looked like your code was allowing bridge window mappings, but that behavior should be preserved as long as your bridge ...

BTW wouldn't something like if (e1000_validate_nvm_checksum(hw) >= 0 || e1000_validate_nvm_checksum(hw) >= 0) { /* copy the MAC address out of the NVM */ if (e1000e_read_mac_addr(&adapter->hw)) e_err("NVM Read Error reading MAC address\n"); } else { e_err("The NVM Checksum Is Not Valid\n"); e1000e_dump_eeprom(adapter); /* * set MAC address to all zeroes to invalidate and * temporary disable this device for the user. This * blocks regular traffic while still ...

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 ...

dumping the eeprom for now seems like a bit of a verbose hack, but might be useful when we want to restore it. if syslogd (or something like) isn't running it won't be kept however. Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> --- drivers/net/e1000e/netdev.c | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c index 48b0ded..57cead3 100644 --- a/drivers/net/e1000e/netdev.c +++ ...

in the process of debugging things, noticed that the swflag is not reset by the driver after reset, and the swflag is probably not reset unless management firmware clears it after 100ms. Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> --- drivers/net/e1000e/ich8lan.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/net/e1000e/ich8lan.c b/drivers/net/e1000e/ich8lan.c index 9e38452..a076079 100644 --- a/drivers/net/e1000e/ich8lan.c +++ ...

[Empty message]

Hi Steven, This is great news. I have some questions below. On Mon, 29 Sep 2008 23:02:42 -0400 I've read this paragraph over and over, and I can't really understand "only storing the size of the ... event". Maybe you are trying to say that now we are not consuming more ring space than the actual size of the event? Oh! I misunderstood also the last sentence, it's not generating extra I'm just wondering, does this hold for both 32- and 64-bit kernels? Long type is quite common in the ...

hm, why? It is ordered locking based on the cpu value. This is exactly what ftrace did as well. The unlock even goes backwards max_cpu to 0. But version 2 of this code will drop both ring_buffer_lock and unlock, but that will come later. -- Steve --

This is a unified tracing buffer that implements a ring buffer that hopefully everyone will eventually be able to use. The events recorded into the buffer have the following structure: struct ring_buffer_event { u32 type:2, len:3, time_delta:27; u32 array[]; }; The minimum size of an event is 8 bytes. All events are 4 byte aligned inside the buffer. There are 4 types (all internal use for the ring buffer, only the data type is exported to the interface ...

It is possible that the testing thread in the ftrace wakeup test does not run before we stop the trace. This will cause the trace to fail since nothing will be in the buffers. This patch adds a small wait in the wakeup test to allow for the woken task to run and be traced. Signed-off-by: Steven Rostedt <srostedt@redhat.com> --- kernel/trace/trace_selftest.c | 3 +++ 1 file changed, 3 insertions(+) Index: ...

ok, -tip testing found a serious-looking locking bug: [ 4.044005] calling init_irqsoff_tracer+0x0/0x11 @ 1 [ 4.048005] Testing tracer irqsoff: [ 4.056202] ============================================= [ 4.060000] [ INFO: possible recursive locking detected ] [ 4.060000] 2.6.27-rc8-tip-00917-g01214de-dirty #37512 [ 4.060000] --------------------------------------------- [ 4.060000] swapper/1 is trying to acquire lock: [ 4.060000] (&cpu_buffer->lock){++..}, at: ...

FYI, triggered on a number of 32-bit test-systems as well - see the log below. Ingo [ 0.564008] calling tracer_alloc_buffers+0x0/0x16b @ 1 [ 0.574504] ------------[ cut here ]------------ [ 0.576002] WARNING: at kernel/lockdep.c:2880 check_flags+0x5a/0x155() [ 0.576002] Modules linked in: [ 0.576002] Pid: 1, comm: swapper Not tainted 2.6.27-rc8-tip-00915-g8cb18a9-dirty #37502 [ 0.576002] [<c01536c4>] warn_on_slowpath+0x46/0x6a [ 0.576002] [<c0170b14>] ? ...

-tip testing found that tip/tracing/ring-buffer causes a new lockdep splat: [ 0.000000] Linux version 2.6.27-rc8-tip-00915-g8cb18a9-dirty (mingo@dione) (gcc version 4.2.3) #37501 SMP Tue Sep 30 10:10:10 CEST 2008 [...] [ 0.268001] calling tracer_alloc_buffers+0x0/0x1e5 @ 1 [ 0.270983] ------------[ cut here ]------------ [ 0.271100] WARNING: at kernel/lockdep.c:2880 check_flags+0x63/0x179() [ 0.271219] Modules linked in: [ 0.271356] Pid: 1, comm: swapper ...

Mathieu Desnoyers pointed out that the freeing of the page frame needs to be reset otherwise we might trigger BUG_ON in the page free code. Signed-off-by: Steven Rostedt <srostedt@redhat.com> --- kernel/trace/ring_buffer.c | 19 +++++++++++++++---- 1 file changed, 15 insertions(+), 4 deletions(-) Index: linux-tip.git/kernel/trace/ring_buffer.c =================================================================== --- linux-tip.git.orig/kernel/trace/ring_buffer.c 2008-09-29 19:59:24.000000000 ...

It seems my previous e-mail was not sent properly. So resending it. Thanks, Kenji Kaneshige --

btw., now that we've got wide enough exposure (a kernel release), could we please flip around the default of CONFIG_MTRR_SANITIZER and make it default-y? This feature should only produce a worse result if there's a bug in that code, right? Ingo --

Applied series to tip:x86/mtrr, thanks! -hpa --

tested them and pushed it out into tip/master. Ingo --

last entry is really sick... YH --

applied to tip/x86/urgent, thanks! Ingo --

These options are also named inconsistently with all other options. The standard way to name an boolean option is "foo" versus "nofoo", in this case, "mtrrcleanup" vs "nomtrrcleanup". -hpa --

And this e1000e must be ICH*, right? I.e. not a separate e1000e chip/card? -- Krzysztof Halasa --

Btw, the _real_ bug is clearly in the hardware design that allows you to brick those things without apparently even having a lock bit. I'm hoping Intel doesn't treat this as just a software bug. Some hw designer should be thinking hard about which orifice they put their head up in. It used to be that you could fry some monitors by feeding them out-of-range signals. The _monitors_ got fixed. Linus --

Dashes seem to be used more than underscores, so it probably should be "mtrr-cleanup" and "nomtrr-cleanup" if you want a separator. -hpa --

Mostly. I think you can still do bad things to internal LCD's on at least some laptops. Although I hope I'm wrong. Linus --

So far it seems to be that you need 1) something close to xorg 7.4 and 2) 2.6.27-rcX kernel to trigger it. Not every system having e1000e is affected. Apparently it is some kind of race, as it usually takes multiple cycles to trigger (on one of our testing machines this took three attempts to trigger for the first time, and then after unbricking the machine and restarting testing, the reproduction tests have been running for several hours). It always seems to happen when X is ...

On Tue, 30 Sep 2008 11:59:58 +1000 we have a patch to save/restore now, in final testing stages (obviously we want to be really careful with this) Note that so far it seems to mostly hit with "new" distros, so both new kernel and new X... ;( -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org --

my current status mail was posted earlier today to lkml from this address, since then we've had a local reproduction and are going for number two. The reproduction seems racy, i.e. it doesn't happen every time, so we put it in a loop doing detect, check eeprom, detect, etc, and we'll see if it fails. Reproduction seems to consistently be around X probing time, no firm leads yet. As for Intel we have keithp and jbarnes as well as arjan, auke, myself and a few others involved. We have some ...

On Mon, 29 Sep 2008 19:21:02 -0700 (PDT) btw, we're also working on making some parts of the kernel more robust against certain types of bugs; for example the ioremap checks and sysfs resource checks. There's a set of checks and API changes we can do to make it less likely that drivers end up doing bad stuff; but that's obviously more for 2.6.28 than for .27 -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit ...

That is very probably completely separate issue, and shoudl have been I think that not many peeople are suspecting bug in e1000e directly. Rather a combination of X bug, kernel allowing X to do bad things (for example the missing check in drivers/pci/pci-sysfs.c:pci_mmap_resource() looks particularly suspicious) and a "bug-friendly" hardware behavior. -- Jiri Kosina SUSE Labs --

heh. Could you send a patch with a changelog please? Ingo --

I am confident they will, because right now some more malicious virus writers will be thinking 'whoopeee party time'. --

Em Tue, 30 Sep 2008 09:58:56 +0200 Eric Piel <eric.piel@tremplin-utc.net> escreveu: | Jiri Kosina schreef: | > On Mon, 29 Sep 2008, Linus Torvalds wrote: | > | >>> If it is X related then its both a kernel + X server issue, the e1000e | >>> driver opens the barn door, the X server drives the horses through it. | >> Are you sure? There was a mandriva report abou NVM corruption on an e100 | >> too (that one apparently just caused PXE failure, the networking worked | >> fine). | > | > ...

If we're fixing a typo anyway I'd suggest so. We know we're not breaking anyone's working setup... -hpa --

i need to document the mtrr_cleanup_debug too...change it to mtrrcleanup_debug ? just like initcall_debug? YH --

For "we" == Thomas, yes. ;-) --

Ah, so we found and fixed these ? Linus, those bugs are actually a regression from when we didn't use the new timer code (which isn't that long ago). It would be nice to have the fixes in .27 (and thus in the various distros that will derive from it) but I would understand if the size of the patch made you choke that late in the -rc cycle... In which case we'll be in for more backports :-) Cheers, Ben. --

hm, i just re-ran the pushout script - see below. Ingo ---------> Linus, Please pull the latest timers-fixes-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git timers-fixes-for-linus Thanks, Ingo ------------------> Thomas Gleixner (4): hrtimer: migrate pending list on cpu offline hrtimer: fix migration of CB_IRQSAFE_NO_SOFTIRQ hrtimers hrtimer: mark migration state hrtimer: prevent migration of per ...

applied to tip/x86/xen, thanks! (hand-applied it as this portion already changed relative to mainline) Ingo --

could you please uncomment "#define DEBUG" in the beginning of drivers/acpi/ec.c? please also open bug report in bugzilla.kernel.org against ACPI and attach dmesg from working and broken kernel with enabled DEBUG. Let me know the number of bug report. Thanks, Alex. --

Tried it out, works great. Added to x86/mtrr. Thanks! -hpa --

True. On my hardware, the smbus controller doesn't advertise power Very cool. netbsd-current apparently has this already (and a kernel-wide topological representation of PCI power management I sure would like to have it back, if only just for experimentation. Right now, I don't even know what kind of power savings could be achieved from D3, I'm just speculating. As you rightfully point out, it's possible that the driver could put the device into an ultra-low power saving state while ...

Yes, this would be nice but unfortunately the presence of the memory section directories that are referenced by the symlinks also depend on CONFIG_MEMORY_HOTPLUG_SPARSE being enabled. Removal of the memory hotplug dependency for the code in drivers/base/memory.c will require more than a simple CONFIG_MEMORY_HOTPLUG_SPARSE to CONFIG_SPARSEMEM dependency change. I am still looking at this. Thanks for the review and testing. Gary -- Gary Hade System x Enablement IBM Linux Technology ...

: I think this patch is convenience even when memory hotplug is disabled. If the first page of the section is not valid, then this section_nr_to_nid() doesn't return correct value. I tested this patch. In my box, the start_pfn of node 1 is 1200400, but section_nr_to_pfn(mem_blk->phys_index) returns 1200000. As a result, the section is linked to node 0. Bye. -- Yasunori Goto --

I think you're confusing it to "nr_units" or, alternatively, I need new glasses. --

This is the number of units available from the cpu allocator. Its determined on bootup and the bitmap is sized correspondingly. --

Hi Christoph, I'm not particularly attached to the allocator in module.c, and yours is Yerch. OK, it *is* better than nothing. Thanks for digging into this again, Rusty. --

applied to tip/x86/debug, thanks Adam! Ingo --

Opps, I mean the find_next_entry_inc will do the lock. The ring_buffer_lock locks all CPU buffers, and the find_next_entry_inc will read from the ring buffer which will also lock the buffer. Hence a deadlock. --

yes, please do. One too many patch is far better than one too few ;-) Ingo --

OK, I'll nuke the ring_buffer_lock :-/ The trace_pipe calls that and then calls print_trace_line which will eventually lock the buffer again. This is a bug on my part. I'll fix that today. Thanks, -- Steve --

Oops sorry... Cut in the middle.... --

heh, just fixed that as well, latest tip/master should have the fix. Have you seen any weirdness due to this uninitialized variable? Ingo --

Actually it's a "5 format". Why not unify... --

If "asm volatile" changes the code and fixes the bug, it seems like you're making use of an undocumented - or at least non-portable - behaviour. Does adding a "memory" clobber also fix the problem? That would have better defined characteristics. --

That doesn't help, does it? If gcc thinks it can get away with evaluating have_cpuid_p() once, then that's the same as: if (!have_cpuid_p()) { identify_cpu_without_cpuid(c); return; } even though identify_cpu_without_cpuid() can cause the cpu to suddenly start supporting cpuid. The trouble is that flag_is_changeable_p() doesn't have any obvious global dependencies; it just takes a constant argument and returns a result. The asm() needs to be updated to have a "memory" ...

minor namespace nit i noticed while looking at actual usage of cpus_copy(): could you please rename it cpumask_set(dst, src)? That streamlines it to have the same naming concept as atomic_set(), node_set(), zero_fd_set(), etc. the patch-set looks quite nice otherwise already, the changes are straightforward and the end result already looks a lot more maintainable and not fragile at all. In what way will Rusty's changes differ? Since you incorporate some of Rusty's changes already, ...

Oh yeah, I forgot the other major point of Rusty's approach. He wants the patchset to be completely bisectable. That's far from true in my version. Thanks, Mike --

A little more here :) "Say Y here if you want security label attribute support for NFS version 4. Security labels allow security modules like SELinux and Smack to label files to facilitate enforcement of their policies. If you do not wish to enforce SELinux or Smack policies on NFSv4 files, say N." Or something... the idea being to make it clear to anyone configuring --

On Mon, 29 Sep 2008 23:20:05 +0200 At first look, replacing zone->lru_lock with zone->lock is enough... This function is an only one function which use zone->lru_lock in page_alloc.c And zone_watermark_ok() which access zone->pages_min/low/high is not under any locks. So, taking zone->lru_lock here doesn't seem to be necessary... Thanks, -Kame --

Hell no. We do not want any implicit parallelism in the initcalls. That way lies madness. The probe functions that explicitly know that they are slow (like USB detection and/or other individual drivers that have timeouts) should put themselves in the background. We should _not_ use the dependency chain to do so automatically, because for most cases drivers are totally independent, but we still want a _reliable_ and _repeatable_ ordering. Which means that I will not accept stuff ...

I think you got the logic the wrong way around: + /* have we been registered already? */ + if (pci_res->parent) + continue; This ignores resources that are _registered_, but it should be the other way around - we should ignore resources that aren't (because they may be invalid or they may move around) + pci_start = pci_res->start; + pci_end = pci_res->end; + + ...

On Tue, 30 Sep 2008 12:51:07 -0700 (PDT) just to avoid any confusion; the current -fastboot tree does not do this parallel stuff. At all. (so please don't judge it as doing that) -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org --

It doesn't. With the test negated it triggers for all PCI resources (and ofcourse my soundcard driver fails again). If the simple res->start == 0/SOME_ARCH_DEFINE definitely won't do and the issue with Bjorn's approach is the bus hammering the solution might be to set a per resource flag in pci_dev at parse time? (that's PCI though and I can't really be here at the moment so over to someone else). Rene. --

Right. The point of this quirk (quirk_system_pci_resources()) is to prevent the PNP system driver from claiming resources that are actually used by PCI. So I don't think there's any reason to run it before we bind the driver to the device. PNP doesn't currently have any early/ late concept for quirks, but we probably should add one. Feels like a post-2.6.27 project though. Bjorn --

Why calculate this at boot time? Do you expect this to change between bootups? Eike

Sorry for the delay in responding -- I'm officially on vacation yesterday and today. I agree that for 2.6.27 the "res->start == 0 means disabled" check in the PNP quirk seems safest. I don't like it long-term, because (a) I'd like that knowledge to at least be in PCI, not PNP, and (b) res->start is the CPU address, not necessarily the PCI bus address, and the BAR value (== PCI bus address) is what we're trying to check. Even if we looked at the BAR value instead of res->start, I think ...

It does, but that said... placing the attached small debug printk's on which does still feel rather clunky (especially the missing "middle" resources 7, 8 and 9 for 01.0, my AGP bridge, look a little weird). (0a.0 is ofcourse my soundcard that is the issue) The resources array for pci_dev is static -- a pci_dev bitmask of enabled resources does sound somewhat nice-ish still perhaps. Rene.

well, as i mentioned it was and is on the backburner, because we went over the same list of problems that you mentioned: harder to read and interpret and debug, harder to reproduce boot ordering, etc. but i'd still like the address the above specific point: it would be silly to propagate Kconfig dependencies into the initcall dependencies, why do you assume we'd do that? When PROCFS or PNP is turned off, then their initcall symbols should naturally alias to some NOP definition, a ...

It looks like both of these will fall afoul of the fact that ACPI currently seems to _expect_ to be called in the old order, ie I get some oops in acpi_irq_penalty_init() apparently because it knew that it got called later (thanks to being called from pci_acpi_init in the arch-specific directory), and knew that the other ACPI subsys setup routines had been done before. Dang. I guess we'll have to bite the bullet some day and actually create some explicit topological ordering of ...

applied to tip/x86/core, thanks Jack. small patch submission request, could you please use this format in future patches: Subject: [PATCH] x86, UV: new genapic functions for x2apic instead of: Subject: [PATCH] - New UV genapic functions for x2apic that follows the typical subject line patterns in x86 commits more closely. Fixed it up in this patch, no need to resend. Thanks, Ingo --

hi, the IO-APIC code got unified in the x86 tree for v2.6.28. So could you please send the fix against tip/master: http://people.redhat.com/mingo/tip.git/README Thanks, Ingo --

This is conding-style fixed version. Thank you, Nishimura-san. -Kmae == There are not-on-LRU pages which can be mapped and they are not worth to be accounted. (becasue we can't shrink them and need dirty codes to handle specical case) We'd like to make use of usual objrmap/radix-tree's protcol and don't want to account out-of-vm's control pages. When special_mapping_fault() is called, page->mapping is tend to be NULL and it's charged as Anonymous page. insert_page() also handles some special ...

Thats a good question. Its kind of arguable and I wasn't sure if everyone will be happy if I removed more arguments from wake_affine() than what I did in my patch (because of the recalculations required). wake_affine() currently has 11 arguments and I thought it may make sense in reducing it to a sane number. For that I chose arguments which I thought can be recalculated with minimum overhead (involves single struct dereference, a simple per cpu variable and/or a simple arithmetic). And one ...

As mentioned in http://lkml.org/lkml/2008/9/30/141 , this is the new patch. sched: Minor optimizations in wake_affine and select_task_rq_fair This patch does following: o Removes unused variable and argument "rq". o Optimizes one of the "if" conditions in wake_affine() - i.e. if "balanced" is true, we need not do rest of the calculations in the condition. o If this cpu is same as the previous cpu (on which woken up task was running when it went to sleep), no need to call ...

Ok. I will resubmit the patch with other suggested changes only. It won't try to reduce wake_affine's arguments (besides the first argument "rq" which is not being used at all). Regards, --

Paul, does this API extension look good to you? i'll apply it to tip/core/rcu if yes. Ingo --

applied this cleanup on top of the fix from Lai Jiangshan, thanks Matthieu! here are the new commits in tip/tracing/markers: 2396ac3: sputrace: use marker_synchronize_unregister() a16801c: markers: documentation fix for teardown b05d9cf: markers: probe example, fix teardown 4b0b16f: markers: fix unregister bug and reenter bug, cleanup 1638da5: markers: marker_synchronize_unregister() b211730: Merge branch 'core/rcu' into tracing/markers 1c50b72: rcu: add rcu_read_lock_sched() / ...

d'oh, right you are. Should I leave this in your hands to merge? Cheers, Jeremy --

marker_synchronize_unregister must be called _also_ between unregistration and destruction the data that unregistration-ed probes need to make sure --

Looks like a very good addition to me! Thanx, Paul --

Hum, yes it does separate unregistration and synchronization in two steps for a very precise purpose : I don't want unregistration of 100 free(old) is only done in call_rcu. the rcu callback is forced by a rcu_barrier() if two consecutive operations are done on the same I don't see any reentrancy bug here. Have you actually experienced such an issue ? Can you give me an example of a bogus execution trace (step-by-step operations) ? Thanks, -- Mathieu Desnoyers OpenPGP key ...

Oleg Nesterov <oleg@tv-sign.ru> wrote on 09/29/2008 07:57:34 PM: The reason I had coded this way was to avoid an unnecessary call - unnecessary since the update function should be usually called to update a work and hence the work is almost always pending. But I will make this change as it is more work. I had tried to capture this information in the comment above, maybe it needs Correct. But the behavior is the same as the existing (say driver) code which calls cancel (which ...

I don't understand where you are going with this... With the ->splice_read(), we can move relay data into a pipe and pass that to a user application (or send it off using sendfile() or splice to a socket). So it's a way to get the data to user space, instead of using read(). With a ->splice_write(), you could support adding data to relayfs from userspace. Why? You want the ->splice_write() on the output end, for your socket or file or wherever you want to send to relay data TO. So as long ...

This was the first time I've seen this, I can apply the patch myself, but first I need to figure why dbus can be such a bitch : ) Need to figure out how to write dbus rules(if this is the case) keep getting the permissions denied crap. -- Justin P. Mattock --

Jeff --

Ah, sorry, maybe I misread this. No data with no event ids, etc is fairly useless. 4 bytes data including space to record event ids is OK. --

In Steven's scheme, the event IDs in the 4 bytes are reserved for (useless) internal use ;) They can therefore not be used for specific tracer event IDs, which I think is a misuse of the precious bits otherwise available to store really useful event IDs. Mathieu -- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 --

You are actually using them to put redundant information that could be encoded differently and thus save 4 bits per event records, more or less what will be needed by most tracers (15 IDs, 1 reserved for an extended ID field). So the fact that you use them does not mean they are really required, and I don't think such duplicated information actually makes things more solid. Maybe just more obscure ? Mathieu -- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 ...

Stuff like irq_exit has 0 byte payload, is very high rate, and useful, Probably pointers on 32 bits archs. Any "int" value, on 32 or 64 bits, will need careful attention if we want only to export the 28 LSBs. It Yup. Mathieu -- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 --

Hi - That's fine for a ring buffer that only ever contains data from one event source. How do you imagine multiplexing working, where one wants to grep a single debugfs file that contains data from different event sources? Punt to another layer? - FChE --

I'm using them, so they must not be totally useless. ;-) But ftrace has its own event ids and I don't want the ring buffer to ever have to know about them. -- Steve --

Same questions here that I had for the ARI stuff. Does this dev_info add value, or is it more noise, and is this message Do you want to emit a kobject_uevent here after success? Alternatively, have you investigated making these virtual functions into real struct device's? You get a lot of sysfs stuff for free if you do so, including correct place in sysfs hierarchy and uevents, etc. My major complaints from last round (more documentation, shouldn't be a PCI hotplug driver) have been ...

This is user-visible, so my questions are: 1) Does this really add value for the user? Or is this just more noise? 2) Is this output string informative enough for the user? Thanks. /ac --

T24gOS8yOS8yMDA4IDU6NTg6MDEgUE0sIEguIFBldGVyIEFudmluIHdyb3RlOg0KPiBOYWthamlt YSwgSnVuIHdyb3RlOg0KPiA+ID4gPg0KPiA+ID4gV2UgZG9uJ3QgaGF2ZSBhIHF1b3J1bSB0byBj cmVhdGUgYSBjb25zZW5zdXMsIHNpbmNlIHdlIG9ubHkgaGF2ZSBhDQo+ID4gPiBzdWJzZXQgb2Yg dGhlIHJlbGV2YW50IHBhcnRpZXMgcHJlc2VudC4NCj4gPg0KPiA+IFdobyBlbHNlIGRvIHdlIG5l ZWQgaGVyZT8NCj4gPg0KPg0KPiBBdCBsZWFzdCBQYXJhbGxlbHMgYW5kIFZpcnR1YWwgUEMvVmly dHVhbCBTZXJ2ZXIuDQo+DQo+ICAgICAgICAgLWhwYQ0KDQpUaGF0IHNob3VsZCBiZSBkb2FibGUu IEFsdGhvdWdoIEknbSBub3Qgc3VyZSBpZiB0aGVp ...

Hi Gerd, I really fail to see your point here. Maybe you can point out what am i missing. Think about the current situation, whenever there is migration to such a tsc-is-different system , how does the guest come to know about the frequency change, either through a $event or if it reboots it runs the calibration algorithm. How does asking the hypervisor for tsc instead of calibrating it, breaks the semantics for this migration. What special things does Xen do at migration, which would be ...

No, I don't think we are. Under the circumstances I do not think anything other than positive identification is unacceptable. If someone had the power to proclaim it by fatwa we wouldn't have much to worry about. Intel might have the power, but we as a group in this thread definitely do not. However, it is clear the virtualization industry doesn't have their act together to the point where one can rely on anything but positive identification, unlike in the hardware space, where ...

Sure, some leaves have been defined already, but it's not too late to try to go the generic route for the remaining leaves. The longer we wait to come to a consensus on generic leaves, the more I don't agree that this solution makes any difference OTOH, it just complicates the situation. Here is why.... 1. This solution really bloats the kernel, below are few observations i) What happens if two ABI signature blocks define a cpuid leaf which have similar semantics, how does the kernel ...

Well, that should be clearly defined, that is my point. When asking the hypervisor for the tsc instead of running a calibration loop, then we have a small bit of paravirtualization: The guest is aware that it runs on a hypervisor and just asks it directly. So while we are at it we can also define a way to communicate tsc freq changes between host and guest, so the cost of trap'n'emulate tsc reads can be avoided. Or we define "tsc is constant" and leave it to the hypervisor to make sure ...

. Jun Nakajima | Intel Open Source Technology Center

On Tue, 30 Sep 2008 23:24:50 -0600 I'm fine with pci_iomap_bar()... it meets my goals Would be nice if I'd be allowed to make it only work on MEM bars not IO bars (so that drivers don't accidentally end up calling this on an IO bar and then using readl() etc) -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org --

great - i've added your Acked-by to the patches and have activated the tip/core/futexes branch for tip/auto-core-next linux-next integration. here are the commits: 42569c3: futex: fixup get_futex_key() for private futexes c2f9f20: futex: cleanup fshared 734b05b: futex: use fast_gup() 6127070: futex: reduce mmap_sem usage 38d47c1: futex: rely on get_user_pages() for shared futexes Thanks, Ingo --

inter-process futexes are still used for pthread creation/join (aka clear_child_tid / CLONE_CHILD_CLEARTID) kernel/fork.c, functions mm_release() & sys_set_tid_address() I am not sure how it could be converted to private futexes, since Sorry I am lost... --

It is enough to guarantee enough to function normally I guess. Actually futex syscalls are interesting in that they logically perform 2 totally different operations and actually want 2 keys but it manages to mash them into one (the user address). They need a futex identifier, on which to wait/wake/etc. For anonymous futexes, this is basically an arbitrary number which is taken from the user address (but note that if that address is subsequently mremap()ed for example, then the futex ...

On Tue, 30 Sep 2008 00:00:11 -0400 (EDT) Perhaps I'm speaking out of turn, but I have to wonder: am I the only one who gets uncomfortable looking at these hacks to overload struct page? It seems fragile as all hell; woe to he who tries to make a change to struct page someday and has to track all of this stuff down. Are the savings gained by using struct page this way really worth the added complexity? jon --

Its not that complex IMHO, the thing that is ugly are those struct page overloads, what we could do is try and sanitize the regular struct page and pull all these things in. Because the only reason people are doing these overloads is because struct page in mm_types.h is becomming an unreadable mess. Trouble is, looking at it I see no easy way out, --

Actually my resize does free the buffers and I did test this. I probably never ran the trace when testing the freeing which means those pointers could have luckily not have been changed. -- Steve --

I also got some corruption of the offset field in the struct page I use. I think it might be related to the fact that I don't set the PG_private bit (slob does set it when the page is in its free pages list). However, given I'd like to pass the buffer pages to disk I/O and for network socket and still keep the ability to re-use it when the I/O has been performed, I wonder where I should put my struct list_head list; /* linked list of buf pages */ ...

That's not the scary part. The scary part is that somebody may well want to access the trace buffer pages in complex ways. If you mmap them, for example, you can use VM_PFNMAP to make sure that nobody should ever look at the "struct page", but if you want to do things like direct-to-disk IO on the trace pages (either with splice() or with The "unreadable mess" has exactly the same issues, though: people need to realize that when you overload fields in the page structure, you can ...

Regardless, there's more info we want to store for each page than the list head. Especially when we start converting this to lockless. I rather get out of the overlaying of the page frames, its nice to save the space, but really scares the hell out of me. I can just imagine this blowing up if we redo the paging, and I dislike this transparent coupling between the tracer buffer and the pages. -- Steve --

The list_head in the page frame should be available regardless of splice() stuffs. --

Ah, I believe the disk IO uses the page frame. That might be a bit more difficult to pass the data to disk and still keep information on the page frame. -- Steve --

Hi, I have access to Power6 and x86_64 boxes and so far I could only reproduce the bug on PPC64. The bug arised from 2.6.26.3-rt6 since sched-only-push-if-pushable.patch and sched-only-push-once-per-queue.patch. Whereas sbrk_mutex definetly shows up the problem, it also can occur randomly, sometimes during the boot period. At the beginning, I had system hangs or this (very similar to Chirag's and not necessarly in sbrk_mutex): cpu 0x3: Vector: 700 (Program Check) at ...

Hi Kosaki-san, This should be: write 0x21 to the process's proc file. Except for this, it seems OK. Thanks. -- Hidehiro Kawai Hitachi, Systems Development Laboratory Linux Technology Center --

Boot configurations, too, can be tested in automated setups, and there is benefit to being able to do that without compilation. However, what we'd need is a machine-readable description that one can select a configuration from. -hpa --

Yes, I had similar problems... for me it blanked screen on closing For me CONFIG_ACPI_VIDEO never really worked... -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

Does the problem occur w/o ath5k? I don't really see how ata_piix can trigger the WARN_ON(). Thanks. -- tejun --

It isn't a hard rule; there are already some hooks that occur before the DAC checking, e.g. setattr, because the DAC checking happens in the fs code as part of the inode op. But when possible, we prefer DAC before MAC for SELinux so that we don't get noise in the audit logs from harmless application/library probing that would be denied by DAC anyway. Same issue would seemingly apply for learning modes of TOMOYO or -- Stephen Smalley National Security Agency --

I now have more information. The if statement that triggers the message is as follows: if (hub->hdev->parent || !hcd->driver->port_handed_over || !(hcd->driver->port_handed_over)(hcd, port1)) For all the messages that I have captured, the first condition (hub->hdev->parent) is always true. For the isolated message that occurs at bootup, the second condition (!hcd->driver->port_handed_over) is true and the third is false. When the message storm occurs, the second condition is ...

OK, thanks for testing. I'm going to submit the sky2 patch for merging too. Thanks, Rafael --

Yes. I will change it. Joerg -- | AMD Saxony Limited Liability Company & Co. KG Operating | Wilschdorfer Landstr. 101, 01109 Dresden, Germany System | Register Court Dresden: HRA 4896 Research | General Partner authorized to represent: Center | AMD Saxony LLC (Wilmington, Delaware, US) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy --

I assume you are talking about the source size, because the generated code size should be exactly the same. In any case, arguing where to place the semi-colon is a waste of time. Do as you see fit. Cheers, Muli -- The First Workshop on I/O Virtualization (WIOV '08) Dec 2008, San Diego, CA, http://www.usenix.org/wiov08/ xxx SYSTOR 2009---The Israeli Experimental Systems Conference http://www.haifa.il.ibm.com/conferences/systor2009/ --

It might be possible to have a per-device slow or fast path, where the fast path is for devices which have no DMA limitations (high-end It should be possible to reduce the number and overhead of hypercalls to the point where their cost is immaterial. I think that's fundamentally a better approach. Cheers, Muli -- The First Workshop on I/O Virtualization (WIOV '08) Dec 2008, San Diego, CA, http://www.usenix.org/wiov08/ xxx SYSTOR 2009---The Israeli Experimental ...

Don't know if this is the original poster's problem, but if the drive is spun down, then enabling SMART or trying to read SMART attributes causes the drive to spin up and the command is delayed until this has occurred. The fix is to increase the timeout given to scsi_execute() in drivers/ata/libata-scsi.c. ie, current code (2.6.26.5) is: /* Good values for timeout and retries? Values below from scsi_ioctl_send_command() for default case... */ cmd_result = ...

This is actually three problems in one :-(. If you try to suspend with minimum config, will resume still take 30 seconds? Is the problem still there in 2.6.27-rc7? Is there chance to bisect it? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

What about the piece leading up to that: cat-7717 [000] 1392.752092: del_timer <-schedule_timeout cat-7717 [000] 1392.772263: account_scheduler_latency <-enqueue_task_fair cat-7717 [000] 1392.773224: __tasklet_schedule <-kbd_event cat-7717 [000] 1392.773225: schedule_console_callback <-kbd_event cat-7717 [000] 1392.773225: schedule_work <-schedule_console_callback cat-7717 [000] 1392.773226: ...

ok, that would be a clear ftrace bug i guess? Ingo --

Frans, There is no relationship between the two patches. First patch (track memtype for RAM in page struct) will fix the behavior you observed and the second patch addresses some error conditions which were noticed by Venki. Both should have been pushed independently. thanks, suresh --

I'd rather we didn't add any more uses of PageReserved without a really good reason. At this point in time (or at least last time I looked, a year or two ago), it isn't a whole lot of work to remove PG_reserved completely. If the waters get muddied up again, it could require another significant rework to remove it in future... Thanks, Nick --

Thanks! --

You know, I just knew I had a brain around here _somewhere_. Weirdly, this didn't fall over on any of my testing. The gods know what it was actually doing, though. I'm picking up tip/master right now and will test your fix for this shortly. -- Frank Mayhar <fmayhar@google.com> Google, Inc. --

I understand all of this, but can't see why you would care about floating point formats in the kernel (when specifically you know that vsnprintf() & Co aren't able to handle it anyway). So I think rather than widening the set of specifiers checkpatch looks for, the check should rather be removed altogether. Jan --

[...] Yes that looks entirly reasonable to me. Will queue it up with my next batch for Andrew. Thanks. -apw --

On Tue, 30 Sep 2008 14:16:09 +0900 (JST) setting timerslack to 0 has no real negative effects on the system on the one hand, on the other hand, it'll be multimedia apps and games who want to do this. Requiring this type of app to be root doesn't sound like a good idea, especially since all you get by "cheating" is ... the exact behavior you ask for anyway. "Increased power consumption" isn't a root privilege, the app can consume much more power just by a "while (1);" loop for ...

Ah.. okay, so generic is not the only one affected by the original hardreset problem. Can you please post the result of "lspci -nn"? -- tejun --

00:00.0 Host bridge [0600]: nVidia Corporation nForce3 250Gb Host Bridge [10de:00e1] (rev a1) 00:01.0 ISA bridge [0601]: nVidia Corporation nForce3 250Gb LPC Bridge [10de:00e0] (rev a2) 00:01.1 SMBus [0c05]: nVidia Corporation nForce 250Gb PCI System Management [10de:00e4] (rev a1) 00:02.0 USB Controller [0c03]: nVidia Corporation CK8S USB Controller [10de:00e7] (rev a1) 00:02.1 USB Controller [0c03]: nVidia Corporation CK8S USB Controller [10de:00e7] (rev a1) 00:02.2 USB Controller [0c03]: ...

btw., are the resulting instructions also expected to be the same? If yes then you might want to verify it all by making sure the md5's of the .o's do not change. (If that's not possible (gcc decides to compile it a bit differently) then no big deal, just wanted to mention the possibility.) Ingo --

Umm. The const has different One is typedef const struct __cpumask_s *const_cpumask_t; which becomes (const struct __cpumask_s) * while the other is const cpumask_t xxx which is const (struct __cpumask_s *) and if you look a bit more closely, you'll see that they are _obviously_ not the same thing at all. Quite frankly, I personally do hate typedefs that end up being pointers, and used as pointers, without showing that in the source code. When you ...

Thanks, yes that explains what I should have figured out. (Nice way to I agree, and as I mentioned, Rusty was working towards an alternative method of declaring cpumask's which does not hide this. My goal was to create an (apparent) opaque handle for cpumask_t and modify Perhaps then defining the cpumask as a list of unsigned longs (remove the outer struct) would play more "naturally". Lists by definition are always referenced by pointers. I have another version of the patchset that ...

Just one more question. What do you mean by non-OEM? It didn't come with the listed harddrive? -- tejun --

Date: Tue, 30 Sep 2008 23:16:24 +0900 From: Tejun Heo <tj@kernel.org> MIME-Version: 1.0 CC: linux-kernel@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Robert Krawitz wrote: > Date: Mon, 29 Sep 2008 16:22:51 +0900 > From: Tejun Heo <tj@kernel.org> > > Robert Krawitz wrote: > > This is for a Dell Inspiron E1705/9400. I'm using a non-OEM disk (a > > Hitachi 320 GB drive). > > > > Note that matching on "MP061" doesn't ...

added -- tejun --

Oops, no. I was busy and I forgot, sorry. Let me review the sysctl vs namespace part. Thanks -- Daniel --

Fixed in SVN; pull a copy and try again. [Mein Gott, that bug was just embarrassing] Monty --

Oh, good catch. Platform/drive combination that hadn't been tripped here. Fixing in SVN now. (you're on bigendian or using an old bigendian SCSI drive?) Monty --

Hi Monty, Yep. This is on PS3, which is ppc64 (albeit most userland is ppc32). With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft Centre Europe The Corporate Village

It happens on anything after 2.6.24 (cfr. http://bugzilla.kernel.org/show_bug.cgi?id=10974). The difficult part is who's to blame: Linux commit Which hard starting/stopping do you mean? Thanks! With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft Centre Europe The Corporate Village

Hi Monty, But the patch above doesn't help. Now cdparanoia crashes with a segmentation fault: | 0x0ffd5730 in cdda_read_timed () from /usr/lib/libcdda_interface.so.0 | (gdb) bt | #0 0x0ffd5730 in cdda_read_timed () from /usr/lib/libcdda_interface.so.0 | #1 0x0ffa7624 in i_read_c_block () from /usr/lib/libcdda_paranoia.so.0 | #2 0x0ffa9114 in paranoia_read_limited () from /usr/lib/libcdda_paranoia.so.0 | #3 0x10004da0 in ?? () | #4 0x0fd46704 in ?? () from /lib/libc.so.6 | #5 ...

With latest cdparanoia git-^H^H^H^Hsvn, the problem still happens. After applying the patch below, there's no more crash thanks to your last commit, and It Just Works(tm): eject; sg_start -i -l /dev/scd0; cdparanoia -d /dev/scd0 -Z -q 1-1[:1] /dev/null || echo failed diff --git a/interface/scan_devices.c b/interface/scan_devices.c index bfe5403..df08906 100644 --- a/interface/scan_devices.c +++ b/interface/scan_devices.c @@ -614,7 +614,7 @@ cdrom_drive *cdda_identify_scsi(const char ...

Rules according to permit_mount: if CAP_SYS_ADMIN, allowed if fs type is not marked safe for user mounts (and not bind), -EPERM if target is a link, -EPERM if target is labeled with new nosubmnt flag, -EPERM if target is not a user mount owned by current->uid, -EPERM You mean if we rm something, do the same thing we do for a lazy umount? That sounds reasonble, if the implementation is doable. And should The rename issue here being what you mentioned above about losing a --