I won't say 'fix', because they still look broken, although this will at least allow 'make ARCH=CRIS headers_install' to _complete_. For headers which are exported, we should probably choose between asm/arch-v10 and asm/arch-v32 by something that GCC defines -- we can't rely on a generated symlink. And we certainly can't export an arch/ directory which doesn't even exist. And the only thing that we seem to include from the arch/ directory is <asm/arch/ptrace.h> from <asm/ptrace.h> ... and ...

Let's say I start with this: 1. 'git checkout v2.6.27-rc3' 2. [apply patch] 3. build kernel + reboot If the kernel locks up, you want me to: 4. [un-apply the patch] 5. 'git bisect start' 6. 'git bisect bad' Of course, we both hope that the kernel will NOT lock up, but let's say it does. My confusion is the what step to take next. To use 'git bisect' I have to select the next kernel version manually until I find a "good" and "bad" version... then git can automatically do its ...

Don't think that will help in general. qemu claims its a Pentium II. J --

We have tested the patch in our labs and systems wake from S5 just fine. Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> -- Cheers, Jeff --

On Thu, 14 Aug 2008 23:38:17 +0200 There was a regression in earlier releases caused because some BIOS's are wrong, and device can wakeup. --

From: Rafael J. Wysocki <rjw@sisk.pl> Adapt the skge driver to the reworked PCI PM * Use device_set_wakeup_enable() and friends as needed * Remove an open-coded reference to the standard PCI PM registers * Use pci_prepare_to_sleep() and pci_back_from_sleep() in the ->suspend() and ->resume() callbacks * Use the observation that it is sufficient to call pci_enable_wake() once, unless it fails Tested on Asus L5D (Yukon-Lite rev 7). Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> --- ...

If a kernel thread is preempted in single-cpu mode right after the NOP (nop about to be turned into a lock prefix), then we CPU hotplug a CPU, and then the thread is scheduled back again, a SMP-unsafe atomic operation will be used on shared SMP variables, leading to corruption. No corruption would happen in the reverse case : going from SMP to UP is ok because we split a bit instruction into tiny pieces, which does not present this condition. Changing the 0x90 (single-byte nop) currently used ...

Arkadaşlar Rastgele İnternette Dolaşırken Buldum Ben Çok Geç Kalmışım Benim Arkadaşlarımda Dinliyormuş. Hiç Bana Söylemedi Uyuzlar :( Bende Herkezle Paylaşmak İstedim Ben Çok Sevdim Sizinde Çok Seveceğinize Eminim.. Korkmayın Ben Norton İle Tarattım Temiz ve Ayrıca Kendim Yeniden Upload Ettim... http://rapidshare.com/files/137322215/hakanergun-sonveda.mp3 Saygılarımla Mutlu Kalın : ) --

Thanks for catching this Acked-by: Balbir Singh <balbir@linux.vnet.ibm.com> -- Balbir --

When the logbsize (eg =256k) or logbufs (eg =8) XFS mount options are present in /etc/fstab, the filesystem fails to mount r/w with 2.6.27-rc3, so stays read-only. This seems to be a regression over 2.6.27-rc1 (didn't check -rc2). I'm testing on Ubuntu Intrepid x86-64, thus filesystem was constructed with xfsprogs 2.9.8-1. Have you seen encountered this issue at all? Many thanks, Daniel -- Daniel J Blueman --

[ Changes since v1: regex fix in x86_64 recordmcount.pl. Now it can handle all mcount+0x... mcount-0x... and mcount, where as the original only handled mcount+0x... Made mcount on start-up to simply return. The current mcount is set up to be replaced with a call to ftrace_record_ip. This is no longer necessary. Note: This patch series is focusing on how calls to mcount in the kernel are converted to nops. It does not address what kind of nop ...

This is the infrastructure to the converting the mcount call sites recorded by the __mcount_loc section into nops on boot. It also allows for using these sites to enable tracing as normal. When the __mcount_loc section is used, the "ftraced" kernel thread is disabled. This uses the current infrastructure to record the mcount call sites as well as convert them to nops. The mcount function is kept as a stub on boot up and not converted to the ftrace_record_ip function. We use the ftrace_record_ip ...

x86 now sets up the mcount locations through the build and no longer needs to record the ip when the function is executed. This patch changes the initial mcount to simply return. There's no need to do any other work. If the ftrace start up test fails, the original mcount will be what everything will use, so having this as fast as possible is a good thing. Signed-off-by: Steven Rostedt <srostedt@redhat.com> --- arch/x86/kernel/entry_32.S | 14 -------------- arch/x86/kernel/entry_64.S | ...

You don't actually need the if. The size of section 0 is 0. Rusty. --

When enabling or disabling CONFIG_FTRACE_MCOUNT_RECORD, we want a full kernel compile to handle the adding of the __mcount_loc sections. Signed-off-by: Steven Rostedt <srostedt@redhat.com> --- include/linux/kernel.h | 5 +++++ 1 file changed, 5 insertions(+) Index: linux-tip.git/include/linux/kernel.h =================================================================== --- linux-tip.git.orig/include/linux/kernel.h 2008-08-14 13:55:12.000000000 -0400 +++ ...

Hi Takashi, I am still finding this recording +ve saturation on my ALC883 Intel HDA sound device with 2.6.27-rc3 (ie ALSA 1.0.17 drivers) and ALSA 1.0.16-1 libraries on Ubuntu Intrepid. The previous workaround still 'gets us out of jail': # ./hda-verb /dev/snd/hwC0D0 0x23 SET_AMP_GAIN_MUTE 0x7180 nid = 0x23, verb = 0x300, param = 0x7180 value = 0x0 Note, we see this message "hda_codec: Unknown model for ALC883, trying auto-probe from BIOS..." as before on this Asus P5E-VM ...

Hi, here are the series of patches to help APIC code merging. I've more patches in my queue (~20 for now). But I still playing with them so they too much ugly to be even tested. The patch with subject x86: apic - do not clear APIC twice in lapic_shutdown actually is not merge-helper but rather I found a bit strange of double clearing of APIC in 32bit code. As always I would really appreciate any comments on this series. The patches are over -tip/master commit ...

On Thu, 14 Aug 2008 20:42:23 +0200 It could be deliberate, I forget. Maybe we trimmed nr_nodemap_entries --

That gives me: On node 0 totalpages: 521751 mminit::memmap_init DMA zone: 88 pages used for memmap mminit::memmap_init DMA zone: 1839 pages reserved DMA zone: 2072 pages, LIFO batch:0 mminit::memmap_init Initialising map node 0 zone 0 pfns 0 -> 4096 mminit::memmap_init DMA32 zone: 11127 pages used for memmap DMA32 zone: 506625 pages, LIFO batch:31 mminit::memmap_init Initialising map node 0 zone 1 pfns 4096 -> 521984 mminit::memmap_init Normal zone: 0 pages used for ...

First, I apologize. I see that you were assuming I had KEXEC enabled when you gave me the patch against 2.6.27-rc3. I have only posted parts of my custom .config to LKML, thinking that posting the whole thing was not appropriate. Did you mean CRASH_DUMP instead of "kdump" above? [N] kexec system call (CONFIG_KEXEC) (bool) (Help) [N] kernel crash dumps (EXPERIMENTAL) (CONFIG_CRASH_DUMP) (bool) (Help) My custom .config has both of these disabled -- either because they default to ...

Don't know. Of course really why would you care if a module of a certain name is loaded. You should only care that a module providing the function you want is loaded. Perhaps you need to explain what you are trying to do. -- Len Sorensen --

I can't find any information on how to make a kernel module load another module. Can someone please tell me how to do this? Thanks in advance. -Ryan --

Hello, There is a piece of code in the early initialization of the 2.6 kernel that identifies the cpu type and then tries to eliminate code that does not apply to the current cpu. This is done by writing nop's over sections of code that are not needed (do_cpu_ftr_fixups in arch/ppc/kernel/misc.S) When I try to run the kernel in a ppc emulator, I get a segmentation fault in do_cpu_ftr_fixups. From examining the section headers of the vmlinux, the text section is marked as readonly. The piece ...

Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> --- arch/x86/kernel/amd_iommu.c | 17 ++++++++++------- include/asm-x86/amd_iommu_types.h | 4 ++++ 2 files changed, 14 insertions(+), 7 deletions(-) diff --git a/arch/x86/kernel/amd_iommu.c b/arch/x86/kernel/amd_iommu.c index 22d7d05..028e945 100644 --- a/arch/x86/kernel/amd_iommu.c +++ b/arch/x86/kernel/amd_iommu.c @@ -101,16 +101,13 @@ static int iommu_queue_command(struct amd_iommu *iommu, struct iommu_cmd *cmd) */ static ...

Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> --- arch/x86/kernel/amd_iommu.c | 2 +- include/asm-x86/amd_iommu_types.h | 3 --- 2 files changed, 1 insertions(+), 4 deletions(-) diff --git a/arch/x86/kernel/amd_iommu.c b/arch/x86/kernel/amd_iommu.c index 028e945..de39e1f 100644 --- a/arch/x86/kernel/amd_iommu.c +++ b/arch/x86/kernel/amd_iommu.c @@ -164,7 +164,7 @@ static int iommu_queue_inv_iommu_pages(struct amd_iommu *iommu, address &= PAGE_MASK; CMD_SET_TYPE(&cmd, ...

This patch adds device table initializations which forbids memory accesses for devices per default and disables all page faults. Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> --- arch/x86/kernel/amd_iommu_init.c | 18 ++++++++++++++++++ include/asm-x86/amd_iommu_types.h | 1 + 2 files changed, 19 insertions(+), 0 deletions(-) diff --git a/arch/x86/kernel/amd_iommu_init.c b/arch/x86/kernel/amd_iommu_init.c index d9a9da5..ceba338 100644 --- a/arch/x86/kernel/amd_iommu_init.c +++ ...

Hi Jan, What about moving the allocation before taking the mutex? That way, we even reduce the lock contention and simplify the failure path. Signed-off-by: Ingo Oeser <ioe-lkml@rameria.de> diff --git a/fs/udf/ialloc.c b/fs/udf/ialloc.c index eb9cfa2..76446eb 100644 --- a/fs/udf/ialloc.c +++ b/fs/udf/ialloc.c @@ -90,6 +90,25 @@ struct inode *udf_new_inode(struct inode *dir, int mode, int *err) return NULL; } + if (UDF_QUERY_FLAG(inode->i_sb, UDF_FLAG_USE_EXTENDED_FE)) ...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've just removed the support for AT_EXECFN again from glibc. The information isn't useful because the path name isn't normalized. I.e., it's not the actual binary path if symlinks are followed during the resolution. This makes it unusable for the $ORIGIN handling. This is on top of the problem with relative paths. Unless somebody has another use case where this is useful I suggest removing AT_EXECFN support again. It's just superfluous work ...

or the git-commits list could use what Linus has requested to be used in pull requests: Please use "git diff -M --stat --summary" to generate the diffstat: the -M enables rename detection, and the summary enables a summary of new/deleted or renamed files. --- ~Randy Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA http://linuxplumbersconf.org/ --

I see no particular reason not to do that. I've spent the whole day screwing with magic git scripts on master.kernel.org, fixing the It would be nice, but I'm not sure it's a good idea. They aren't always valid email addresses. Maybe a Reply-To: header, rather than From: ? -- David Woodhouse Open Source Technology Centre David.Woodhouse@intel.com Intel Corporation --

There were 2 omitted readb's used on an iomap space. eliminate them by using ioread8 instead. Signed-off-by: Jiri Slaby <jirislaby@gmail.com> Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Cc: Jesse Brandeburg <jesse.brandeburg@intel.com> Cc: Bruce Allan <bruce.w.allan@intel.com> Cc: PJ Waskiewicz <peter.p.waskiewicz.jr@intel.com> Cc: John Ronciak <john.ronciak@intel.com> --- drivers/net/e100.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/e100.c ...

board->base is increased for CF cards after mapping. Use board->base2 for unmapping the region, since it holds the original/correct address. Signed-off-by: Jiri Slaby <jirislaby@gmail.com> Cc: R.E.Wolff@BitWizard.nl --- drivers/char/sx.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/char/sx.c b/drivers/char/sx.c index c385206..5b8d7a1 100644 --- a/drivers/char/sx.c +++ b/drivers/char/sx.c @@ -2504,7 +2504,7 @@ static void __devexit ...

readl/writel are not expected to accept iomap return value. Replace bogus mapping by standard ioremap. Signed-off-by: Jiri Slaby <jirislaby@gmail.com> --- drivers/char/cyclades.c | 21 ++++++++++++--------- 1 files changed, 12 insertions(+), 9 deletions(-) diff --git a/drivers/char/cyclades.c b/drivers/char/cyclades.c index 33737bb..6e480e8 100644 --- a/drivers/char/cyclades.c +++ b/drivers/char/cyclades.c @@ -4976,12 +4976,14 @@ static int __devinit cy_pci_probe(struct pci_dev *pdev, ...

The functionality is used by the kernel internally anyway so there is no point removing it as it has no cost at all. You can equally call "reboot" by mistake or strcpy with wrong parameters. The interface is also part of our historic ABI/API so shouldn't just get booted out. You might not like it, and it might not be very useful but thats true of stuff like readahead() as well. Alan --

PM_TRACE is stable for quite long. I don't think it needs to depend on experimental. Signed-off-by: Pavel Machek <pavel@suse.cz> --- commit 710f4e9070c453e743fcfa1a6017075026c4967b tree 7f3fe656004f2d21b6a9cbe1264f9f2236572456 parent ea977ecb4f994b0dc2e09cab3dbba87aad030d99 author Pavel <pavel@amd.ucw.cz> Thu, 14 Aug 2008 17:18:07 +0200 committer Pavel <pavel@amd.ucw.cz> Thu, 14 Aug 2008 17:18:07 +0200 kernel/power/Kconfig | 2 +- 1 files changed, 1 insertions(+), 1 ...

applied to tip/sched/urgent - thanks! Ingo --

Hi Linus, Please pull this fix from David Howells: Fix the setting of PF_SUPERPRIV by __capable() as it could corrupt the flags the target process if that is not the current process and it is trying to change its own flags in a different way at the same time. The approach taken involves cleanly separating the way capabilities are checked so that capable() now only refers to the current task and assumes the capability is about to be used, while has_capability() is used to ...

I did: struct irq_desc { struct irq irq; .... } Then to_idesc is just a container_of call. Or simply a type cast but that is rude. Having nr be a field in struct irq is possibly valid. When last we talked about the design Linus was emphatic that what gets exposed to drivers be an opaque token. When I looked for 99%+ of the arch code we can use that same opaque token. irq_desc is something we don't really care about except in do_IRQ(). So I guess the truly ...

Unfortunate gradual accreation of functionality. vector_allocation_domain could perhaps be better named. Round up this cpu to the set of cpus I need to allocate a vector on. Eric --

From 547c9dd238f4412622fb6a2622d81c35c0a9fb85 Mon Sep 17 00:00:00 2001 From: Ingo Molnar <mingo@elte.hu> Date: Thu, 14 Aug 2008 15:32:59 +0200 Subject: [PATCH] irq: sparse irqs, fix MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit fix: drivers/pci/intel-iommu.c: In function ‘dmar_set_interrupt': drivers/pci/intel-iommu.c:918: error: too few arguments to function ‘create_irq' Signed-off-by: Ingo Molnar <mingo@elte.hu> --- ...

We may want an is_valid_isa_irq() for drivers. Otherwise drivers should not be passing in irqs. And the request_irq path should valid the irq number but it should not allocate it. So we will have failures with invalid irq numbers. For acpi, mptables and the like we can easily have a check for some reasonably high value if there is value in that. Last I looked parts s390 is weird. I'm not even convinced they use linux/interrupt.h My mistake. irq_desc() is a bad name for the ...

we don't need pin_map_size and first_free_entry after 64 and 32 bit all put irq_2_pin in irq_cfg. need to remove them. YH --

find below a crash fix discovered by tip/master testing. Robustness of sparse IRQs is looking pretty good otherwise at first glance. Ingo ------------------> From a4a5ec7bbaaaab5fcb86bd348b98bfbed7c6a3b7 Mon Sep 17 00:00:00 2001 From: Ingo Molnar <mingo@elte.hu> Date: Thu, 14 Aug 2008 15:48:50 +0200 Subject: [PATCH] irq: sparse irqs, fix IRQ auto-probe crash fix: [ 10.631533] calling yenta_socket_init+0x0/0x20 [ 10.631533] Yenta: CardBus bridge found at 0000:15:00.0 ...

I haven't looked at callers of this, but... Does it need to be allocated on the stack? Local cpumask_t's are a size problem. Can we build this in .rodata at compile time instead? Is this the caller? + for_each_cpu_mask(cpu, mask) { + cpumask_t domain, new_mask; + int new_cpu; + int vector; + + domain = vector_allocation_domain(cpu); + cpus_and(new_mask, domain, cpu_online_map); If so we could perhaps do static noinline const cpumask_t *vector_allocation_domain(int ...

From: Rocky Craig <rocky.craig@hp.com> The apparent intent of "flush_tlbs" is to invalidate TLB entries that might match in the address range 0 to 0x00400000. A loop counter is set up at the high value and decremented by page size. However, the loop is only done once as the sense of the conditional branch at the loop end does not match the setup/decrement. Signed-off-by: Rocky Craig <rocky.craig@hp.com> --- Source is from 2.6.27 development, but the bug appears as far back as ...

I finished experimenting last night with trying to find the last commit in the gittree that would let me revert the problem successfully... and I got completely raped. The bisecting took me all the way back to the first commit introducing the problem on these motherboards: 3def3d6d... Considering these 3 consecutive commits (according to 'git log')from late Feb. 2008, between kernel versions 2.6.25 and 2.6.26-rc1: --------------------------------------------------------- 700efc1b...: ...

So your patch code protects against problem that Bill is mentioning without using "#ifdef CONFIG_KEXEC", right Yinghai? For the record: my configs, including the kernel I built with Yinghai's revert patch, have CONFIG_KEXEC not set. Some experiments I did last night may render these questions moot, though. My problem is very specific to the hardware on two of my machines, and it has something to do with setting up the system resources that insert_resource() touches. Dave W. --

On Thu, 14 Aug 2008 13:42:09 +0200 So killing off the request with -EOPNOTSUPP is preferred over having a prepare function and stopping it there? Rgds --=20 -- Pierre Ossman Linux kernel, MMC maintainer http://www.kernel.org rdesktop, core developer http://www.rdesktop.org WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption.

Hi Jens, There is one part of the block layer I'm having trouble completely understanding (well there are loads really, but right now there's one in particular :)): Do block drivers need to watch out for requests that aren't "normal" reads and writes? The MMC block driver has a funky prepare function that checks for FS and PC requests and discards anything else. I believe this is wrong in two regards: a) PC requests seem to be prepared SCSI cmds, and the MMC driver just expects normal ...

lockd uses time_before() to determine whether the grace period has expired. This would seem to be enough to avoid timer wrap-around issues, but, unfortunately, that is not the case. The time_* family of comparison functions can be safely used to compare jiffies relatively close in time, but they stop working after approximately LONG_MAX/2 ticks. nfsd can suffer this problem because the time_before() comparison in lockd() is not performed until the first request comes in, which means that if there ...

Hi Russell, Attached is what is arguably an ARM-patch rather than an mm patch. I tried subscribing to the ARM mailing list to post there but no luck so far. If you are not the right person to send this to, point me elsewhere. Thanks ==== Ordinarily, memory holes in flatmem still have a valid memmap and is safe to use. However, an architecture (ARM) frees up the memmap backing memory holes on the assumption it is never used. /proc/pagetypeinfo reads the whole range of pages in a zone ...

Jeremy, Until recently, the maximum number of xvd block devices you could attach to a Xen domU was 16. This limitation turned out to be problematic for some users, so it was expanded to handle a much larger number of disks. However, this requires a couple of changes in the way that blkfront scans for disks. This functionality is already present in the Xen linux-2.6.18-xen.hg tree; the attached patch adds this functionality to the mainline xen-blkfront implementation. I successfully ...

Also, the new page is only added to the rmap _after_ it has been Another case I just looked at is if ptep_clear_flush_young() actually does the clear bit. But the few arches (x86_64, ppc64) that I looked at don't seem to do so. If someone would, you could hit this race. CPU1 CPU2 lock(pte_lock) ptep_clear_flush(ptep) page_mkclean() page_check_address() ...

Yes, that's the part of the protocol I was forgetting. Not exactly relevant to the mprotect case where your hole opens up, but exactly the part of it that synchronizes all the ptes with the struct page, which was worrying me there. I really ought to read all those private messages to Virginia. Yes. The pte is still marked dirty and writable (after briefly being absent) and the page may be modified by userspace without entering the accounting; it will eventually get picked up and written ...

Hi, Wonder if you would be kind enough to verify this? It solves my issues (well still running after several hours wheras it previously would lock up in a few seconds). Thanks, Nick --- There is a race with dirty page accounting where a page may not properly be accounted for. clear_page_dirty_for_io() calls page_mkclean; then TestClearPageDirty. page_mkclean walks the rmaps for that page, and for each one it cleans and write protects the pte if it was dirty. It uses ...

s/synch/sync/ ? Indeed, that does look like a hole, and the proposed fix seems sane. --

I agree completely that should be allowed (within pagetable lock) and is sometimes essential, mprotect being the classic example. So I'll try to think through your case later on, focussing on Yes, that's what I'd missed: with that worry out of the way, I should think a bit clearer. Hugh --

Oh you're right definitely. Thanks. Actually, the bug I am running into is not with a vanilla kernel... I am making several of my own required changes to solve other races I need to plug, so I'm sorry the changelog might be misleading... Hmm, no even in that case I think we get away with it because of the wait_on_page_locked which ensures clearing the page dirty Maybe I've found another one: ppc64's set_pte_at seems to clear the pte, and lots of pte accessors are implemented with ...

Please pull from 'upstream-davem' branch of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream-davem to receive the following updates: drivers/net/Kconfig | 2 +- drivers/net/acenic.c | 1 - drivers/net/arm/ixp4xx_eth.c | 6 +- drivers/net/atl1e/atl1e_ethtool.c | 2 +- drivers/net/atl1e/atl1e_main.c | 4 +- drivers/net/au1000_eth.c | 2 +- drivers/net/ax88796.c ...

* convert goto to simpler while loop; * use rq_end_sector() instead of computing manually; * fix false comments; * remove spurious whitespace; * convert rq_rb_root macro to an inline function. Signed-off-by: Aaron Carroll <aaronc@gelato.unsw.edu.au> --- block/deadline-iosched.c | 26 +++++++++++++------------- 1 files changed, 13 insertions(+), 13 deletions(-) diff --git a/block/deadline-iosched.c b/block/deadline-iosched.c index 07b80e4..fd31117 100644 --- ...

Deadline currently only batches sector-contiguous requests, so except for a few circumstances (e.g. requests in a single direction), it is essentially first come first served. This is bad for throughput, so change it to CSCAN, which means requests in a batch do not need to be sequential and are issued in increasing sector order. Signed-off-by: Aaron Carroll <aaronc@gelato.unsw.edu.au> --- block/deadline-iosched.c | 14 +++----------- 1 files changed, 3 insertions(+), 11 ...

After I issued command "resize" to shell which is running on one of serial port, it doesn't output shell prompt any more, but echo what I inputed. It seems that shell don't know how to end one input line when this issue happened. Anybody has ideas? aaa@(none):~$ resize COLUMNS=125; LINES=39; export COLUMNS LINES; <entery key input> <enter char output> <entery key input> <enter char output> <entery key input> <enter char output> <entery key input> <enter char output> ...

Perhaps after the first loop we should set memory_limit to equal lmb_end_of_DRAM(), then the second loop should work as it is. I think that actually makes memory_limit (the variable) more useful, and avoids more code like we have in numa_enforce_memory_limit(), which doesn't use memory_limit exactly because it isn't the value we're Guilty as charged. I have some tests for that code, but clearly not Would it be that much extra logic to check that the address is less than the limit? ...

Hi all, News: This is the 6 month anniversary of linux-next (the first release was Feb 14). Changes since next-20080813: The usb-current tree lost its conflict. The ubifs tree lost its conflict. The slab tree lost its conflict. The hdlc tree gained a build fix patch. The ttydev tree gained a conflict against the usb tree. The creds tree gained a conflict against the ttydev tree and lost one against Linus' tree. I have also applied the following patches for known ...

And linux-next helped me a lot in finding breakage early. Thanks for your efforts, Stephen! Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds --

Tainted by some prior sysfs warn_on crapola. BUG: unable to handle kernel NULL pointer dereference at 0000000000000248 IP: [<ffffffffa001cb68>] do_cciss_intr+0x627/0xa6c [cciss] PGD 17eba6067 PUD 17eba7067 PMD 0 Oops: 0002 [1] SMP last sysfs file: /sys/block/ram15/dev CPU 2 Modules linked in: cciss(+) ehci_hcd ohci_hcd uhci_hcd Pid: 0, comm: swapper Tainted: G W 2.6.27-rc3-next-20080814 #1 RIP: 0010:[<ffffffffa001cb68>] [<ffffffffa001cb68>] do_cciss_intr+0x627/0xa6c ...

The actual cleverness is in fb_defio[*], which was written by Jaya Kumar (cc'ed). I merely ripped out the old, somewhat racy cleverness I inherited from Anthony Liguori (which you can still admire in Xen's 2.6.18 kernel), and switched over to use fb_defio instead. Because one instance of clever code is enough. My understanding of fb_defio's inner workings is rather limited I fear. I'm just using it. Jaya, could you help? [...] [*] Documentation/fb/deferred_io.txt ...

My understanding is that the driver is doing something a bit clever: it uses the page dirty flags to determine which parts of the framebuffer have been written to, and uses that information to minimize the amount of stuff that needs to be copied out. The writes to the pages are not expected to generate actual page faults. But I haven't really looked at it closely, and I'm not at all familiar with the vm at this layer. I'm not sure how it actually allocates the framebuffer memory for ...

Nor I! Thanks a lot for doing the bisection, but all I can say so far is that I'm utterly flummoxed. (And I do wonder if it's a pvfb bug which has previously been masked; but that's premature, we can't say until we understand how it got here at all.) There's a lot of "?" entries in your backtrace, Jeremy's ones look clearer: CONFIG_FRAME_POINTER=y ought to improve yours. In both cases it's handling a page fault: I'm curious as to what kind of vma this fault is occurring on. Could you ...

--

Hi, Creating a device node on a different filesystem to see if the driver only worked with the safe shmem set_page_dirty and now breaks due to exposure to the generic version. Or if the driver works with the generic version through other mappings and the shmem code screws it up somewhere else. Hannes --

added global external procedure defines. added and updated volatile declarations. added and updated debug_lock synchronization and SSB command support. Signed-off-by: Jeffrey Vernon Merkey (jmerkey@wolfmountaingroup.com) --- a/debug/mdb/mdb-proc.h 1969-12-31 17:00:00.000000000 -0700 +++ b/debug/mdb/mdb-proc.h 2008-08-13 11:56:03.000000000 -0600 @@ -0,0 +1,146 @@ + +/*************************************************************************** +* +* Copyright (c) 2008 Jeff V. Merkey ...

disable the console warning checks if the debugger is active because the debugger is dependent in the console output functions in order to provide console display. Signed-off-by: Jeffrey Vernon Merkey (jmerkey@wolfmountaingroup.com) --- a/include/linux/console.h 2008-08-13 14:22:32.000000000 -0600 +++ b/include/linux/console.h 2008-08-13 11:56:03.000000000 -0600 @@ -141,11 +141,16 @@ void vcs_remove_sysfs(struct tty_struct *tty); /* Some debug stub to catch some of the obvious ...

export the kallsyms lookup functions to the module based debugger. add debugger specific lookup to search for matching strstr text fragments for entered search terms. Signed-off-by: Jeffrey Vernon Merkey (jmerkey@wolfmountaingroup.com) --- a/kernel/kallsyms.c 2008-08-13 14:22:32.000000000 -0600 +++ b/kernel/kallsyms.c 2008-08-13 11:56:03.000000000 -0600 @@ -160,6 +160,9 @@ } return module_kallsyms_lookup_name(name); } +#if ...

change mdb name to "Merkey's Linux Kernel Debugger". update description to add very simple and minimal instructions on entering the debugger and access to the internal help panels. Signed-off-by: Jeffrey Vernon Merkey (jmerkey@wolfmountaingroup.com) --- a/lib/Kconfig.debug 2008-08-13 14:22:32.000000000 -0600 +++ b/lib/Kconfig.debug 2008-08-13 11:56:03.000000000 -0600 @@ -134,6 +134,39 @@ Say Y here if you are developing drivers or trying to debug and identify kernel problems. ...

add the /debug directory to the main Makefile for module-based kernel debuggers. Signed-off-by: Jeffrey Vernon Merkey (jmerkey@wolfmountaingroup.com) --- a/Makefile 2008-08-13 14:22:11.000000000 -0600 +++ b/Makefile 2008-08-13 11:56:03.000000000 -0600 @@ -620,6 +620,7 @@ ifeq ($(KBUILD_EXTMOD),) core-y += kernel/ mm/ fs/ ipc/ security/ crypto/ block/ +core-$(CONFIG_MDB) += debug/ vmlinux-dirs := $(patsubst %/,%,$(filter %/, $(init-y) $(init-m) \ $(core-y) $(core-m) ...

add a notify_die handler to hook the panic entry point prior to Linux "execve"-ing another kernel for crash analysis. Signed-off-by: Jeffrey Vernon Merkey (jmerkey@wolfmountaingroup.com) --- a/kernel/panic.c 2008-08-13 14:22:32.000000000 -0600 +++ b/kernel/panic.c 2008-08-13 11:56:03.000000000 -0600 @@ -21,6 +21,8 @@ #include <linux/debug_locks.h> #include <linux/random.h> #include <linux/kallsyms.h> +#include <linux/kdebug.h> + int panic_on_oops; int tainted; @@ -82,6 +84,13 ...

OK. That's simple and minimal. Jeff --

Well,then please suggest how a kernel debugger can be module based and still be able to get this information some other way that's generic and minimal impact. Jeff --

export the console redirection handle to allow the debugger screen to becoime visible again during exceptions. Export of this variable allows the debugger to switch to the current screen in order to enable the debugging console on systems with a redirected system console. Signed-off-by: Jeffrey Vernon Merkey (jmerkey@wolfmountaingroup.com) --- a/drivers/char/vt.c 2008-08-13 14:22:15.000000000 -0600 +++ b/drivers/char/vt.c 2008-08-13 11:56:03.000000000 -0600 @@ -188,6 +188,10 @@ int ...

added clocksource nmi functions and nmi watchdog update logic to correct soft cpu errors due to nmi watchdog timers. Signed-off-by: Jeffrey Vernon Merkey (jmerkey@wolfmountaingroup.com) --- a/debug/mdb/mdb-os.c 1969-12-31 17:00:00.000000000 -0700 +++ b/debug/mdb/mdb-os.c 2008-08-13 13:18:57.000000000 -0600 @@ -0,0 +1,1125 @@ + +/*************************************************************************** +* +* Copyright (c) 2008 Jeff V. Merkey All Rights Reserved. +* 1058 East ...

added complete notify_die states and state support for SSB command. Signed-off-by: Jeffrey Vernon Merkey (jmerkey@wolfmountaingroup.com) --- a/debug/mdb/mdb-main.c 1969-12-31 17:00:00.000000000 -0700 +++ b/debug/mdb/mdb-main.c 2008-08-13 11:56:03.000000000 -0600 @@ -0,0 +1,648 @@ + +/*************************************************************************** +* +* Copyright (c) 1997, 2008 Jeff V. Merkey All Rights Reserved. +* 1058 East 50 South +* Lindon, Utah 84042 +* ...

added the command registry for registering debugger and accelerator keystroke commands. corrected a large number of checkpatch.pl reported issues. Signed-off-by: Jeffrey Vernon Merkey (jmerkey@wolfmountaingroup.com) --- a/debug/mdb/mdb-list.c 1969-12-31 17:00:00.000000000 -0700 +++ b/debug/mdb/mdb-list.c 2008-08-13 11:56:03.000000000 -0600 @@ -0,0 +1,628 @@ + +/*************************************************************************** +* +* Copyright (c) 2008 Jeff V. Merkey All ...

added JMP, CALL, RET, J%% detection into the ia32 disassembler for SSB support and branch detection. Signed-off-by: Jeffrey Vernon Merkey (jmerkey@wolfmountaingroup.com) --- a/debug/mdb/mdb-ia32-support.c 1969-12-31 17:00:00.000000000 -0700 +++ b/debug/mdb/mdb-ia32-support.c 2008-08-13 11:56:03.000000000 -0600 @@ -0,0 +1,1935 @@ + +/*************************************************************************** +* +* Copyright (c) 2008 Jeff V. Merkey All Rights Reserved. +* 1058 East 50 ...

add top level mdb.h include file. added focus processor internal tracing and debugging defines. Signed-off-by: Jeffrey Vernon Merkey (jmerkey@wolfmountaingroup.com) --- a/debug/mdb/mdb.h 1969-12-31 17:00:00.000000000 -0700 +++ b/debug/mdb/mdb.h 2008-08-13 11:56:03.000000000 -0600 @@ -0,0 +1,54 @@ + +/*************************************************************************** +* +* Copyright (c) 2008 Jeff V. Merkey All Rights Reserved. +* 1058 East 50 South +* Lindon, Utah ...

added includes and external defines for ia32 specific code Signed-off-by: Jeffrey Vernon Merkey (jmerkey@wolfmountaingroup.com) --- a/debug/mdb/mdb-ia32.h 1969-12-31 17:00:00.000000000 -0700 +++ b/debug/mdb/mdb-ia32.h 2008-08-13 11:56:03.000000000 -0600 @@ -0,0 +1,172 @@ + +/*************************************************************************** +* +* Copyright (c) 2008 Jeff V. Merkey All Rights Reserved. +* 1058 East 50 South +* Lindon, Utah 84042 +* ...

add architecture independent external defines. Signed-off-by: Jeffrey Vernon Merkey (jmerkey@wolfmountaingroup.com) --- a/debug/mdb/mdb-base.h 1969-12-31 17:00:00.000000000 -0700 +++ b/debug/mdb/mdb-base.h 2008-08-13 11:56:03.000000000 -0600 @@ -0,0 +1,296 @@ + +/*************************************************************************** +* +* Copyright (c) 2008 Jeff V. Merkey All Rights Reserved. +* 1058 East 50 South +* Lindon, Utah 84042 +* ...

add a debug directory makefile for loadable kernel debugger modules. Signed-off-by: Jeffrey Vernon Merkey (jmerkey@wolfmountaingroup.com) --- a/debug/Makefile 1969-12-31 17:00:00.000000000 -0700 +++ b/debug/Makefile 2008-08-13 11:56:03.000000000 -0600 @@ -0,0 +1,5 @@ +# +# Makefile for kernel debugger modules +# + +obj-$(CONFIG_MDB) += mdb/ --

[Empty message]

Hello, I've been experiencing nasty intermittent boot problems on recent -git kernels. The problem is not readily reproducible; I tried to bisect and couldn't trigger it at all, but if I leave the machine off for at least an hour or so it triggers and is quite obvious (the kernel halts completely after spewing SATA errors). This is a multi-OS machine; if I boot into a 'good' OS (2.6.25.x works, as does Windows XP), then reboot into a recent kernel, the kernel boots fine. So the procedure for ...

Crane, thanks for debugging this. I think we don't need a quirk for this workaround. Checking the config register value for 0xffffffff is safe on all machines. I simplified your patch to the one below and added a printk in case the check times out. One thing I'm a bit wary about is the readout of the HPET_PERIOD register. Is the value correct even _before_ the SMM machinery is started ? Thanks, tglx ----- diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c index ...

nice fix! I've applied it to tip/x86/urgent as the quirk is limited to this platform so it should be safe for v2.6.27 as well. Exactly what kind of failure mode have you seen without the quirk? Do we read out the wrong values and thus hpet_clocksource_register() is calibrated incorrectly and you can get non-functional high-res timers? A quick question: the signoff order indicates that the patch has been authored by XiaoGang Zheng. Or is the reverse order intended? (you wrote the ...

XiaoGang insures that HPET check method in hardware view. I refine the method and generate the patch. Vojtech and Zahir refine the description. This issue is cleared by Joachim and many other persons in SUSE. -Crane --

-- Vojtech Pavlik Director SuSE Labs --

I resolved the following conflict with Linus' tree in: git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6#next-creds commit 4030dcef54030fdb4ad6ff3813ac031d7afbdf35 Merge: 1e058f1... 8d0968a... Author: James Morris <jmorris@namei.org> Date: Thu Aug 14 10:43:47 2008 +1000 Merge branch 'master' into next-creds Conflicts: fs/xfs/xfs_acl.c Signed-off-by: James Morris <jmorris@namei.org> diff --cc fs/xfs/xfs_acl.c index ...

Minor clarifications. The musb_hdrc (*) driver is *currently* used on ARM, specifically a bunch of TI chips (**), but it's an IP core which has been licensed by various other vendors. That is: it's not ARM-specific. We already know about work adding Blackfin 5xx support, which I suspect will appear in the 2.6.28 timeframe, and I've also had queries from folk using this IP on some PowerPC systems too. - Dave (*) Mentor USB Highspeed Dual Role Controller (MUSB HDRC), from Mentor ...

The first util-linux-ng 2.14.1 release candidate is available at ftp://ftp.kernel.org/pub/linux/utils/util-linux-ng/ (Note that 2.14.1 is stable maintenance release.) Feedback and bug reports, as always, are welcomed. Karel Util-linux-ng 2.14.1 Release Notes ================================== ChangeLog between v2.14 and v2.14.1 ----------------------------------- For more details see ChangeLog files at: ...

From: David Miller <davem@davemloft.net> While further testing I noticed a bug which I've pushed into the tree, please repull to fetch it if you haven't already, thanks! The following changes since commit 4f70f7a91bffdcc39f088748dc678953eb9a3fbd: David S. Miller (1): sparc64: Implement IRQ stacks. are available in the git repository at: master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6.git master David S. Miller (1): sparc64: Handle stack trace attempts ...

I have created a Bugzilla entry at http://bugzilla.kernel.org/show_bug.cgi?id=11342 for this problem. I'll close it now, but please reopen if if the problem reappears. Thanks, Rafael --

Add in the CPUID for Nehalem chips. Signed-off-by: Darrick J. Wong <djwong@us.ibm.com> --- drivers/hwmon/coretemp.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/hwmon/coretemp.c b/drivers/hwmon/coretemp.c index 70239ac..93c1722 100644 --- a/drivers/hwmon/coretemp.c +++ b/drivers/hwmon/coretemp.c @@ -413,10 +413,11 @@ static int __init coretemp_init(void) for_each_online_cpu(i) { struct cpuinfo_x86 *c = &cpu_data(i); - /* check if family ...

Hi Darrick, Please update the Documentation too. I have patch for the Intel Atom, but this one seems trivial, so lets push this one first. Thanks, Rudolf --

Can you send me the exact laptop type? Thanks --

OK, that gave me very different kernel/driver versions. uname -r: 2.6.26-rc6-iwl-2.3.5-wl dmesg: iwlagn: Intel(R) Wireless WiFi Link AGN driver for Linux, 2.3.5ks iwlagn: Copyright(c) 2003-2008 Intel Corporation ACPI: PCI Interrupt 0000:07:00.0[A] -> GSI 17 (level, low) -> IRQ 17 PCI: Setting latency timer of device 0000:07:00.0 to 64 iwlagn: Detected Intel Wireless WiFi Link 5300AGN REV=3D0x24 iwlagn: Tunable channels: 13 802.11bg, 24 802.11a channels phy1: Selected rate control ...

5000 This is great news to me - my new Sager laptop has a 5300 card. However, it doesn't seem to work: iwlagn: Intel(R) Wireless WiFi Link AGN driver for Linux, 1.3.27ks iwlagn: Copyright(c) 2003-2008 Intel Corporation iwlagn 0000:07:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 iwlagn 0000:07:00.0: setting latency timer to 64 iwlagn: Detected Intel Wireless WiFi Link 5300AGN REV=3D0x24 iwlagn: Tunable channels: 13 802.11bg, 24 802.11a channels phy7: Selected rate control algorithm ...

applied --

applied these patches to tip/x86/xsave: f65bc21: x86, xsave: use BUG_ON() instead of BUILD_BUG_ON() ed40595: x86, xsave: clear the user buffer before doing fxsave/xsave ee2b92a: x86, xsave: remove the redundant access_ok() in setup_rt_frame() thanks Suresh. Ingo --

We don't have a way of exporting this fact at the moment. I assume Well, if you're willing to try it out, as I've mentioned on my blog[1][2], ext4 is working pretty well on my laptop --- I'm running it as my primary filesystem. There are a few problems with ext3 filesystems converted to use ext4, as opposed to starting afresh via "mke2fs -t ext4dev /dev/hdXX" that we've just found in the past week (and fixed within a day or two, although they haven't been pushed to Linus yet), but overall, ...

"Infected" just means to instantly return an error when the file is opened or if an already opened file descriptor is read or mmap'ed, right? If file is already mmaped(), what's the plan? Send a kill -9 to the process, even if it ends up kill off an emacs or openoffice If a userspace database knows that inode X, i_version Y was checked a day ago, and inode X still has i_version Y, even if that inode has been evicted from memory, the contents will be the same absent root messing about with ...

On Thu, 14 Aug 2008 10:12:13 -0400 well... do you really need a response? I think we need to sort the interface issue on this for sure, and -- If you want to reach me at my work email, use arjan@linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org --

Oops, I'd love to, and it should be very easy. How do I find out if i_version is supported on a given superblock? There's nothing particularly "advanced" about this, by the way--this is a very minor variation on the caching model that nfs has always had, and our nfsv4 server is currently pretty broken without it. Actually, it's pretty broken even on nfsv2/v3 for filesystems with poor time resolution. --b. --

Small misunderstanding because both would block. If you go back to Ted's original post I was replying to, he was worried about how would anti-malware scanning interact with HSM since both may end up using the same interface. HSM, as far as I understand it, needs to block on open and "plant" the right file in place, while anti-malware also needs to block and examine the right content. That is why ordering matters, anti-malware needs to run after the content is put in place. And that is what ...

It is in fact really simple with the proposed inode versioning approach. Any client which wants to invalidate the cache just needs to bump the global version number which will force a rescan on next access. Tvrtko Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon, OX14 3YP, United Kingdom. Company Reg No 2096520. VAT Reg No GB 348 3873 20. --

There needs to be a way to say that an inode in cache needs to be rescanned. 3 states this flag can be. Clean, Dirty, Infected. The current talpa solution involves a global monotomically increasing counter every time you change virus defs or make some "interesting" change. If global == inode flag we are clean. If global == negative inode flag we are infected. if global > inode flag we are dirty and exporting i_version might be useful for better userspace caching, although I've yet to ...

In this case, it seems to be the same kind of requirement that lead to dnotify and inotify, right? So in order to get the third notification syscall interface right, the obvious questions are: 1. How do you make it cleaner than inotify? 2. How do you make it more scalable than inotify? 3. Do you need it to do anything that inotify doesn't do, beyond 1. and 2.? Arnd <>< --

So in essence, what I hear you saying is that all AV products want to work in a mode where the moment the inode falls out of the inode cache, and we lose the "clean" bit, when the inode is brought back into the cache, it will be scanned again. That is, the "clean" bit is never persistent, and never needs to be stored in memory. That seems fair; if it turns out there is an AV product that wants to optimize this a bit further, as long as we provide a persistent inode version/generation number, ...

We don't have a revocation mechanism in linux and this isn't about adding one. Your trying to turn this into something it isn't. If you have it opened and mmap'd you've got that file for as long as you want. I've already said that given Arjan's belief that we can move it read/write instead of open/close we are moving the open->read race to a mmap->fault race. It isn't perfect at stopping bad data flow, but its is i_version an on disk think? didn't realize that and just assumed it was in ...

I honestly don't think we should worry about root. Sure, if the AV scanner happens to catch something (as a consequence of it's implementation), then very well. But designing an antimalware solution which assumes the root is compromised will throw us into security talks for years and I don't think we'll live to hear the end of them. We should focus on the regular users and fix (if needed) the current userland apps (ie. the ones that need root access to do their job). For anymore than ...

Do I understand correctly that everyone agrees scanning whenever an inode gets dirty would be a terrible thing for performance? Another thing we have here is that malware could not be neccessariliy identified until the very last write (one example where it will always be the case are PDF files (I think)). So the whole question is at which point should be performing an async scan. Close seems like a natural point which should be ideal for majority of applications, I don't see how any ...

I'm not sure I understand why "interest in content" means not blocking, and vice versa. However, I think this is a good idea if made more Jon Press --

On Thu, 14 Aug 2008 08:45:04 -0500 looks good to me Acked-by: Arjan van de Ven <arjan@linux.intel.com> -- If you want to reach me at my work email, use arjan@linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org --

When a CPU core is shut down, all of its caches need to be flushed to prevent stale data from causing errors if the core is resumed. Current Linux suspend code performs an assignment after the flush, which can add dirty data back to the cache.  On some AMD platforms, additional speculative reads have caused crashes on resume because of this dirty data. Relocate the cache flush to be the very last thing done before halting.  Tie into an assembly line so the compile will not reorder it.  Add ...

why oops ? it that is not appended to res_kernel... YH --

On Wed, Aug 13, 2008 at 10:19 PM, Guennadi Liakhovetski That is true, but the point is that even the folks who invented the language don't have a problem with making the initialization explicit. I'm not even trying to argue that folks should do it one way or the other, I'm just saying it is unimportant, so let's drop it from checkpatch.pl and save ourselves a lot of pointless code churn. btw, see pg 94 of "The Practice of Programming" where the masters also explicitly initialize statics. --

The core problem is that you insist on a rigid bottom-to-top flow of autosuspensions. That's good for systems like USB and PCI which are trees for PM purposes. It makes no sense for true busses with equal members on the bus. Regards Oliver --

But you cannot make the conclusion that the ultimate children should have any autosuspend attributes. We can implement autosuspend in usb storage and propagate the suspend calls down the tree without SCSI knowing about autosuspend. Such a system would have it drawbacks, but it'd be a lot simpler. Regards Oliver --

Hmm... but suspended devices have very little power budget, right? So unless you have external power supply (2.5" frames generally don't), you can't really suspend and stay spinned up... -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

What can we do?... Real world devices don't always obey the spec. You could argue that the suspend current should be sufficient to maintain the contents of the cache, which would then be written out after resume. But even if that is true, it's a very fragile guarantee Think of it in two parts: idle-timeout detection and autosuspend. Presumably you don't object to the idle-timeout detection (which is needed for powering down links in general), and you don't argue against the ...

My framework is tree-oriented because it's based on the driver model, which uses a tree of devices. Even on a true bus, the members can't be entirely equal -- one of them has to be closer to the CPU than the others are. If that one member is in a low-power state then the CPU can't communicate with anything on the bus, unlike when one of the other members is in a low-power state. (I suppose in theory there could be a situation in which the CPU has direct communication with a bunch of ...

From: Pekka J Enberg <penberg@cs.helsinki.fi> Why create a special purpose lock when the generic networking already is taking a lock for you to proect the TX path? Furthermore, as I just described in another reply, netpoll already knows that it might need to trylock() attempt on this lock in order to avoid the very deadlocks this thread is about. --

...so I guess something like the following (totally untested) patch could work. Pekka Subject: [PATCH] 8139too: avoid deadlock with netconsole From: Pekka Enberg <penberg@cs.helsinki.fi> As explained by Vegard Nossum, the 8139too driver can deadlock with netconsole: I encountered a hard-to-debug deadlock when I pulled out the plug of my RealTek 8139 which was also running netconsole: The driver wants to print a "link down" message. However, this triggers netconsole, which ...

and another one. sysproc gui reads user addresses from the sysprof pipe with null pointers. is this ok or is this a bug in sysprof kernel module? -- Lukáš Hejtmánek --

It spent the time between then and now in the -mm tree. Seems like nobody is building m68k out of -mm. I'm out for the next 3 days, but it seems to me that the easiest fix is to move that code out of the header (i.e. uninline them) so the patch below is only compile tested on x86_64 - I've got to go load a trailer and get moving... Cheers, Dave. -- Dave Chinner david@fromorbit.com Completions: Un-inline try_wait_for_completion and completion_done m68k fails to build with these ...

This change (commit 39d2f1ab2a36ac527a6c41cfe689f50c239eaca3) seems to have broken the m68k build: | CC arch/m68k/kernel/asm-offsets.s | In file included from linux/include/linux/mm_types.h:12, | from linux/include/linux/sched.h:61, | from linux/arch/m68k/kernel/asm-offsets.c:12: | linux/include/linux/completion.h: In function 'try_wait_for_completion': | linux/include/linux/completion.h:80: error: dereferencing pointer to incomplete type | ...

At Wed, 13 Aug 2008 16:40:37 +0200, Today's tree works fine. Thanks! Takashi --

Thanks, I've updated the version in git://linux-nfs.org/~bfields/linux.git for-2.6.28 --

On Wed, Aug 13, 2008 at 10:23 PM, Langsdorf, Mark On the first look the ACPI seems correct. The first two P00x objects have this PSD: Package (0x05) { 0x05, 0x00, 0x00000000, 0x000000FD, 0x00000002 } The other two have 0x00000001 at the third position. But as I don't really have a clue about ACPI, I'm attaching the complete SSDT so you can take look. Just ask, if you need the other ...

I'm still seeing it on 2.6.27-rc2, even with the patch here http://lkml.org/lkml/2008/7/30/171 and the wbinvd_halt code patch applied. Maybe something else broke in some of the recent hotplug changes? -Mark Langsdorf Operating System Research Center AMD --

Disabling MCE did eliminate the error message. -Mark Langsdorf Operating System Research Center AMD --

Can you please try "hpet=disable" on the kernel command line ? Thanks, tglx --

I tried it just now, is performs a bit better than 2.6.26 (e.g. I don't get that "press any key unless nothing happens" states), even reports a bit more reasonable values of wakeups, but the system sometimes becomes rather slow (e.g. when playing video). I was not able to compile fglrx driver, so I had to change it to radeon one. And also, the number of wakeups reported is not very convincing, though, it changes from 300 to 600 (which is ~ two times the sum of wakeups) without any reason, and ...

Hi All I am configuring linux 2.6.26 kernel in laptop and transferring image to desktop. My desktop is IDE drive. I am getting kernel panic try init= option error after booting the kernel. I am trying to setup KGDB on linux 2.6.26 kernel between dev machine and test machine. I have issues and it is not working. I can get the kgdb to communicate but I cannot start init images to start. I am using Redhat grub configuration. Do we need apply any patch for 2.6.26 kernel. I am using 2.4.15.5-kgdb ...

Absolute alignment requirements may never be applied to node-relative offsets. Andreas Herrmann spotted this flaw when a bootmem allocation on an unaligned node was itself not aligned because the combination of an unaligned node with an aligned offset into that node is not garuanteed to be aligned itself. This patch introduces two helper functions that align a node-relative index or offset with respect to the node's starting address so that the absolute PFN or virtual address that results from ...

I said my kernel version was 2.6.27-rc1 but in fact it still applies on last git tree. --

Sidebar again... Alas, I don't remember what Ted's question was, so I tried to see if I could start a discussion about the most general one (;-)) --dave (not an AV guy) c-b -- David Collier-Brown | Always do right. This will gratify Sun Microsystems, Toronto | some people and astonish the rest davecb@sun.com | -- Mark Twain cell: (647) 833-9377, bridge: (877) 385-4099 code: 506 9191# --

Hmm, unless I'm missing something this one is unrelated. There are no cpu hotplug, sched or cpusets paths in the trace besides cpu_maps_update_begin(). But that one is taken in the regular destroy_workqueue() path. The issues is polldev_mutex and cpu_add_remove_lock nesting. I bet you can trigger that without cpusets. CC'ing Dmitry Torokhov. btw It seems to be triggered when X closes polled input device. There aren't that many of them $ git grep input_register_polled_device | wc -l ...

Looks great to me. Thanks Herbert! Best -- /*************************************************** *Neil Horman *nhorman@tuxdriver.com *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***************************************************/ --

Thanks Neil. I've merged this with the original patch and made some small changes on the API side, such as adding a reset helper and adding a krng that just uses get_random_bytes. Here is the final result against cryptodev-2.6. Let me know if you're OK with it and I'll push it out. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: ...

--- --- If it was limited to xfs_fsr, that'd be tolerable -- but its --- The lock-correctness code is described as a feature to provide "provability". It's not called "debugging" and I don't regard that as "debugging" -- but something that any production system that wants operational integrity over a minor 'speed hit', would "theoretically" want. If it is "debug" code, it should be labeled as such -- but code that can mathematically guarantee that parts of the kernel operate correctly ...

I have build-tested alpha with a simple header file move. Can I ask you to do a simple move of all header files for alpha like you did for h8300. [I could set up a git tree etc. but being busy with my new house arm] Thanks, Sam --

applied --

It was in rc1-mm1. Thanks

On Thu, 14 Aug 2008 09:12:01 +0200 (CEST) static inline unsigned scsi_sg_count(struct scsi_cmnd *cmd) --

Yes, I can easily do it this way; fixed below. Right. How did I forget about that? From: Stefan Richter <stefanr@s5r6.in-berlin.de> Subject: ieee1394: sbp2: remove redundant struct members Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> --- drivers/ieee1394/sbp2.c | 14 +++++--------- drivers/ieee1394/sbp2.h | 4 ---- 2 files changed, 5 insertions(+), 13 deletions(-) Index: ...

s390 Dasd ECKD Driver issues a Perform Subsystem Function/Prepare for Read Subsystem Data with a length of 16. However, some hardware (namely 3990/9390 and some version of ESS) only take 12 bytes and therefore, an Incorrect Length indication is returned, breaking CCW Command Chaining and leads to a failure to initialize the DASD. This patch sets the SLI CCW bit to prevent an incorrect length indication to be reported when the control unit expects a length of 12 ...

applied --

Not exactly. But you can do this way, if you need to preserve a direction. What I did is a bit different though. qe_gpio_set_dedicated() actually just restores a mode that firmware had set up, including direction (since direction could be a part of dedicated configuration). That is, upon GPIO controller registration, we save all registers, then driver can set up a pin to a GPIO mode via standard API, and then it can _revert_ a pin to a dedicated function via qe_gpio_set_dedicated() call. ...

=2D-=20 Laurent Pinchart CSE Semaphore Belgium Chaussee de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 =46 +32 (2) 387 42 75

Yes, with the current implementation the field is always zero, but things might change. Instead of passing 0 unconditionally I think we could use a function that extracts/calculates the ioprio of requests. The patch I sent you yesterday is the first step in that direction. Is this a valid approach for you? --

Yes. Obviously it makes more sense for Jens to queue this so: Acked-by: Rusty Russell <rusty@rustcorp.com.au> Thanks! Rusty. --

struct request has an ioprio member but it is never updated because currently bios do not hold io context information. The implication of this is that virtio_blk ends up passing useless information to the backend driver. That said, some IO schedulers such as CFQ do store io context information in struct request, but use private members for that, which means that that information cannot be directly accessed in a IO scheduler-independent way. This patch adds a function to obtain the ioprio of ...

The only problem I can see with this is that you lose efficiency, especially when you have to build your checkpoint image with lots of things that are config-specific. The approach sounds like a good one in theory, but I'm a bit skeptical that we could stick to it in practice, in a mainline kernel where there are billions of config options. It is definitely something to strive for, though. Good point! -- Dave --

[Empty message]

Could this be moved into suspend_freeze_processes? It is related (usermode helper is disabled when no userland), and you will not have to call it from 3 places...? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

A virtualized guest kernel could use that to limit its use of the overall machine CPU resources in different time periods. Policies can determine how many physical CPU a virtual machine can be tied to, and that may change depending on e.g. the workload or time of day. Having the ability to efficiently switch to UP for a long period of time seems important in this use-case. -- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 --

Sure, here are the updated tables. Basically, they show no significant difference between the NOP and the DS segment selector prefix approaches. Xeon 2.0GHz Summary * replace smp lock prefixes with DS segment selector prefixes no lock prefix (s) with lock prefix (s) Speedup make -j1 kernel/ 33.94 +/- 0.07 34.91 +/- 0.27 2.8 % hackbench 50 2.99 +/- 0.01 3.74 +/- 0.01 25.1 % * replace smp lock prefixes with 0x90 ...

I doubt it, because I made a "cache priming" run before the tests, which made sure the data was all populated in memory. But yeah, having different cpu clock calibration values/cpu clock frequency between reboots could also cause that kind of difference. -- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 --

I can't argue about the benefit of using VM CPU pinning to manage resources because I don't use it myself, but I ran some tests out of curiosity to find if uncontended locks were that cheap, and it turns out they aren't. Here are the results : Xeon 2.0GHz Summary no lock prefix (s) with lock prefix (s) Speedup make -j1 kernel/ 33.94 +/- 0.07 34.91 +/- 0.27 2.8 % hackbench 50 2.99 +/- 0.01 3.74 +/- 0.01 25.1 % Detail ...

Not very convinced. Unplugging cpus is a pretty coarse way to control resource use. There are lots of other mechanisms. And it's not like an uncontended lock is all that expensive these days... J --

So should I wait a bit for more comments or straightforwardly submit this as a patch rather than RFC ? Mathieu -- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 --

Using %ds: rather than nop really seems to solve a whole lot of problems, and might even be faster to boot. It really sounds like a no-brainer. -hpa --

I've given up trying to remember what "E5405" might mean, but that feature list suggests a relatively modern microarchitecture. J --

Here are the specs. It's a brand new 64bits dual quad-core (Christmas in August) :-) None of the specs seems to talk about neither Core2 or Pentium 4 though. Those appellations seems to hold for desktop processors, not server processors... processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Xeon(R) CPU E5405 @ 2.00GHz stepping : 6 cpu MHz : 2000.109 cache size : 6144 KB physical id : 0 siblings : 1 core id : 0 cpu cores : ...

Is it a Dell thingy? Turns out my main test box has exactly the same processor. J --

Locking prefetches is definitely wrong :) I don't know if the comment is correct; I've certainly never heard of that myself. -hpa --

OK, let me clarify my point a bit. If you've got a kernel which is switching between UP and SMP on a regular basis, you're going to be taking the hit for the locked instructions whenever you're in the SMP state anyway. It's only going to be a workload where you're mostly UP with occasional excursions into being SMP that patching out the lock prefixes is actually going to make a difference. And that just doesn't seem like a very likely use-case to me. Certainly I don't think it would ...

I guess some testing of this patch under an virtualized Linux would not hurt. Anyone have a setup ready ? The test case is simple : Run a kernel on a multi-CPU virtual guest. export NR_CPUS=... Reading the "Intel Architecture Optimizations Manual" for older Intels : http://developer.intel.com/design/pentium/manuals/242816.htm Chapter 3.7 Prefixed Opcodes The penality for instructions prefixed with other prefixes than 0x0f, 0x66 or 0x67 seems to be 1 added clock cycle to detect the ...

Yeah, I thought about this case yesterday, good thing you ask. include/asm-x86/alternative.h defines LOCK_PREFIX as : #define LOCK_PREFIX \ ".section .smp_locks,\"a\"\n" \ _ASM_ALIGN "\n" \ _ASM_PTR "661f\n" /* address */ \ ".previous\n" \ "661:\n\tlock; " So we have the locked instructions built into the kernel, not the nop'd one. Therefore, the only transition I am doing ...

Absolutely. Locked ops show up not just in microbenchmarks looping over the instruction, they show up in "real" benchmarks too. We added a single locked instruction (maybe it was two) to the page fault handling code some time ago, and the reason I noticed it was that it actually made the page fault cost visibly more expensive in lmbench. That was a _single_ instruction in the hot path (or maybe two). And the page fault path is some of the most timing critical in the whole kernel ...

Matt, Can you please try 2.6.27-rc3 or Linus latest git ? Also please provide a full boot log. Thanks, tglx --

2.6.27_rc3 does not solve the problem either. what can i do to help? -- alex --

(adding cc: stable, the bug is also in 2.6.26.2) yep, thanks. I am running my x60s with this patch now: -- Fix signed parameter in ACPI frequency notifier. static unsigned int ignore_ppc = -1; ... if (event == CPUFREQ_START && ignore_ppc <= 0) { ignore_ppc = 0; ... Signed-off-by: Milan Broz <mbroz@redhat.com> --- drivers/acpi/processor_perflib.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Index: ...

Ok, booted up and not hanged, but those messages below don't show up anywhere. I've tested with CONFIG_NR_CPUS=16 and 8 as well. Just got 8 cpus More than 8 CPUs detected - skipping them. Use CONFIG_X86_GENERICARCH and CONFIG_X86_BIGSMP. # cat /sys/devices/system/cpu/possible 0-7 CONFIG_X86_32=y CONFIG_X86_PC=y Looks like it's not going into this condition + if (def_to_bigsmp && nr_cpu_ids > 8) { Shall this be put back so that it'll show the message? - if ...

But without duplication they are basically free here at least in IO rate. Seems odd? Does it compute them twice in the duplication case perhaps? -Andi --

What sort of script are you using? Basically something like this? for i in `seq 1 30` do mkdir $i; cd $i tar xjf /usr/src/linux-2.6.28.tar.bz2 cd .. done - Ted --

Yes, there are about 5 suid binaries on typical linux system. Link That is does not work? (Neither does LD_PRELOAD; it still has the old mmap problem. Too bad, but at least you get 99.9% coverage of all the apps). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

Hi! Okay, so goal of libmalware.so is to "not allow data in the black list to pass through Linux server". Threat model is windows machines trying to copy infected files through the server. Viruses are not expected to mmap problem: libmalware.so would not offer mmap() to applications (or maybe it would do copy of the file, then allow mmap on the copy). kernel NFS server is not handled; don't use it for serving Windows clients. Not that you need performance for that, anyway. Obviously ...

Yes, that's the part libmalware.so proposal solves. Given scary number Yep, so... why don't you propose something better? I'm pretty sure 100% reliable scanning is impossible without modifying applications, but hey, you can prove me wrong. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

My suggestion was to keep the locking for the write side - so as to avoid stuff stomping on one another, but drop the read side as: spin_lock foo = var; spin_unlock return foo; is kinda useless, it doesn't actually serialize against the usage of foo, that is, once it gets used, var might already have acquired a new value. The only thing it would protect is reading var, but since that is a machine sized read, its atomic anyway (assuming its naturally aligned). So no need for ...

I was confused about this point, as I thought I saw raw_spinlock defined thanks, This code is doing list deletions, insertions and walks / element updates in a multi threaded environment where many processes on many CPU's can be adding removing and updating PM_QOS request, a lot (tm). So I think I still need to locking for the list walking and list element updating code on face value. I'm not supper good with lists, perhaps there is a trick to protecting the lists better than the ...

Almost. Turns out there were two problems: 1) I was setting SW_RFKILL_ALL as a keybit instead of an swbit - so no events reported. Whoops. :-) 2) Maybe this shouldn't surprise me, but the expected switch semantics are that '1' means radios are on and 0 means they are killed - I thought it was the other way round. Now, when I release the kill switch, rfkill-input does indeed turn the radio on. Great. The remaining problem is that rfkill-input is setting it to soft-blocked when the switch ...

Thanks for the response Andrew. Is there a way to check when the cached data has been freed after fadvise has been called? -----Original Message----- From: Andrew Morton [mailto:akpm@linux-foundation.org] Sent: Thursday, 14 August 2008 11:17 AM To: Trevor Woollacott [ MTN - Innovation Centre ] Cc: linux-kernel@vger.kernel.org Subject: Re: POSIX_FADV_DONTNEED On Fri, 1 Aug 2008 17:05:39 +0200 "Trevor Woollacott [ MTN - Innovation It tries to be nonblocking and will mostly succeed in ...

It gives one the creeps seeing a trivially-triggerable panic() call in a non-__init codepath. And lo, one of pda_init's callers is __init and the other is __cpuinit. So this function can at least be made __cpuinit(). But if we can still panic the kernel if a GFP_ATOMIC allocation fails at cpu-hotplug time then that's still a problem. cpu_init() has the same shortcoming. --

Is this still happening in 2.6.27-rc3? Thanks. --

The patch is no longer applicable to current sources. If the bug is sufficiently serious to warrant fixing in 2.6.25.x and in 2.6.26.x then please prepare patches against those kernels, including sufficient description to enable the -stable maintainers to understand why they need to merge it. Cc those patches to stable@kernel.org. Thanks. --

Did I write that comment? I sure don't remember it, sorry :) I don't have any plans on changing this, but I do know people use the /sys/module/MODULE_NAME/parameters interface today, why change it? thanks, greg k-h --

applied to tip/sched/urgent - thanks. Ingo --

From: Tom Tucker <tom@opengridcomputing.com> It's stateless because the full packet traverses the real networking stack and thus can be treated like any other packet. The data placement is a side effect that the networking stack can completely ignore if it chooses to. --

Sure, I read what you wrote before writing (although, frankly, didn't get the idea). But I don't think that overall it would be as efficient The test used Myricom Myri-10G cards (myri10ge driver), which support LRO. And from ethtool -S output I conclude it was enabled. Just in case, I attached it, so you can recheck me. Thus, apparently, LRO doesn't make a fundamental difference. Maybe this particular implementation isn't too efficient, I don't know. I don't have enough information ...

How do you envision programming such a device? It will need TCP and iSCSI state to have any chance of doing useful and productive placement of data. The smarts about the iSCSI stateless offload hw will be in the device driver, probably the iscsi device driver. How will it gather the information from the TCP stack to insert the correct state for a flow into the hw cache? --

From: Steve Wise <swise@opengridcomputing.com> The card can see the entire TCP stream, it doesn't need anything more than that. It can parse every packet header, see what kind of data transfer is being requested or responded to, etc. Look, I'm not going to design this whole friggin' thing for you guys. I've stated clearly what the base requirement is, which is that the packet is fully processed by the networking stack and that the card merely does data placement optimizations that the ...

From: Tom Tucker <tom@opengridcomputing.com> If you're getting packets out of order, data placement optimizations are the least of your concerns. In fact this is exactly where we want all of the advanced loss handling algorithms of the Linux TCP stack to get engaged. --

Well, the first step wrt to this for us software folks is getting the Slicing by 8 algoritim CRC32C into the kernel.. This would be a great benefit for not just traditional iSCSI/TCP, but Linux/SCTP and I have always found this to be the historical case wrt iSCSI on x86 hardware. The rough estimate was that given identical hardware and network configuration, an iSCSI target talking to a SCSI subsystem layer would be able to handle 2x throughput compared to an iSCSI Initiator, Heh, I think ...

No, the kmsg-doc script will prevent that the kmsg message will become of of sync and it checks for duplicate numbers. The idea here is that the kmsg man pages are generated with the kernel compile (just try it Yes, and this has already happened with the s390 device driver messages. With the conversion to kmsg our developers removed a lot of crud from the code, this alone makes it worthwhile. -- blue skies, Martin. "Reality continues to ruin my life." - Calvin. --

Oh, I agree with that. I personally don't care much for the msg ID part of this patch (I mean I don't care either way). It might be nice to have man pages, but I just see it becoming out of sync, duplicate numbers, etc. What I want to see is the elevation of these call-sites from "it's just a printk()" to "it's a report-worthy event and part of our user<->kernel API". I want people to add them when it's appropriate and then not change the strings later. I don't care if, in the end, they ...

Well, why would you do it with the preprocessor? It's simplest to spit it out at runtime. The (offline) catalogger will need to generate them, of course. Rusty. --

Well, if they're to be the same messages under the manual-numbering scheme, someone has to verify that they are really the same anyway. Not much more work to simply fix them in that case, is it? If it improves normal kernel messages, then everyone wins. Rusty. --

I see what you mean. I'll add a check again capable(CAP_SYS_ADMIN). -Mark Langsdorf Operating System Research Center AMD --

The strlen can go - it's no longer necessary. If sscanf isn't safe in this context, there's a lot of code in drivers/cpufreq/cpufreq.c that I cribbed from that needs I don't think so. If it got this far, it is an AMD processor from family 0x10 or later, so it has wbinvd(). -Mark Langsdorf Operating System Research Center AMD --

New versions of AMD processors have support to disable parts of their L3 caches if too many MCEs are generated by the L3 cache.   This patch provides a /sysfs interface under the cache hierarchy to display which caches indices are disabled (if any) and to monitoring applications to disable a cache index. This patch does not set an automatic policy to disable the L3 cache.  Policy decisions would need to be made by a RAS handler.  This patch merely makes it easier to see what indices ...

New versions of AMD processors have support to disable parts of their L3 caches if too many MCEs are generated by the L3 cache.   This patch provides a /sysfs interface under the cache hierarchy to display which caches indices are disabled (if any) and to monitoring applications to disable a cache index. This patch does not set an automatic policy to disable the L3 cache.  Policy decisions would need to be made by a RAS handler.  This patch merely makes it easier to see what indices ...

New versions of AMD processors have support to disable parts of their L3 caches if too many MCEs are generated by the L3 cache.   This patch provides a /sysfs interface under the cache hierarchy to display which caches indices are disabled (if any) and to monitoring applications to disable a cache index. This patch does not set an automatic policy to disable the L3 cache.  Policy decisions would need to be made by a RAS handler.  This patch merely makes it easier to see what indices are ...

<snip> Ok, I got the build problem with the usb-gadget drivers all worked out now, and added this to my driver-core tree. Very nice stuff, again, thanks for doing this. I'll work to clean up the USB drivers to all rely on this and not their separate CONFIG_USB_DEBUG option. Also, would it make sense to add a patch like the one below to this code? It might be nice to know when each module's debugging value is manually changed by the user for the log files. If you like it, I can merge ...

looks good. we might also want to add a message for the cases where are the modules are enabled/disabled too. thanks, -Jason --

As well as deadlocks, in the case of cgroups a big advantage of dirty limits is that it makes it easier to "loan" memory to groups above and beyond what they have been guaranteed. As long as we limit the dirty/locked memory for a cgroup to its guarantee, and require any extra memory to be clean and unlocked, then we can reclaim it in a hurry if another cgroup (that had been guaranteed that memory) needs it. Paul --

It's not really a flush lock at that point - it's a state lock. We've already got one of those, and a set of state flags that it protects. Basically you're suggesting that we keep external state to the completion that tracks whether a completion is in progress or not. You can't use a mutex like you suggested to protect state because you can't hold it while doing a wait_for_completion() and then use it to clear the state flag before calling complete(). We can use the internal inode state ...

Bogus migrate type 6 Usemap for section 0 corrupted paging_init+0xcac/0xd38[arch/sparc64/mm/init.c:1795] 1790 #ifndef CONFIG_NEED_MULTIPLE_NODES 1791 max_mapnr = last_valid_pfn; 1792 #endif 1793 sparse_validate_usemap(__FILE__, __LINE__); 1794 kernel_physical_mapping_init(); 1795 sparse_validate_usemap(__FILE__, __LINE__); 1796 1797 { 1798 unsigned long max_zone_pfns[MAX_NR_ZONES]; 1799 Ultra 10, ...

From: Mikulas Patocka <mpatocka@redhat.com> Thanks, I've tried a lot of things to try and reproduce this myself but to no avail. Let's try to track down exactly where the corruption happens. Please try the debug patch below on your box. It will spit out a message something like: [ 0.000000] BUG: Bogus migrate type 5 [ 0.000000] BUG: Usemap for section 0 corrupted at sparse_init+0x17c/0x218[mm/sparse.c:498] The theory is that some other piece of code is either not allocating a ...

Hi So I tried the patch and found out that the corruption happens in setup_command_line --- the first strcpy call corrupted the migratetype map. Examining the problem further, it turned out that Johannes Weiner committed new bootmem allocator to 2.6.27-rc1 and the allocator is broken. This is the minimal sequence that jams the allocator: void *p, *q, *r; p = alloc_bootmem(PAGE_SIZE); q = alloc_bootmem(64); free_bootmem(p, PAGE_SIZE); p = alloc_bootmem(PAGE_SIZE); r = ...

Looks nice, as I had already implemented a way to turn off kmemtrace when logging. I'll get back to you in a few days, I'm not close to home right now. BTW, did the kmemtrace user app work for you? Pekka seemed to have issues with compiling it. Thanks, Eduard --

This is a NUMA system right? Then we have another mechanism that will avoid off node memory references by allocating new slabs. Can you set the node_defrag parameter to 0? (Noted by Adrian). --

Hi Christoph, This patch hard locks on my 2-way 64-bit x86 machine (sysrq doesn't respond) when I run hackbench. --

Please elaborate. Maciej --

That happend sendmail/quilt sent mail by past :(. I'll fix and resend tomorrow. thanks. --