Hi all again, Here it is another little Oops we found: echo 0 > /dev/cgroups/0/cpu.rt_period_us or echo 4294967296 > /dev/cgroups/0/cpu.rt_period_us [ 205.509825] divide error: 0000 [#1]=20 [ 205.510151] Modules linked in: [ 205.510151]=20 [ 205.510151] Pid: 2339, comm: bash Not tainted (2.6.26-rc8 #33) [ 205.510151] EIP: 0060:[<c030c6ef>] EFLAGS: 00000293 CPU: 0 [ 205.510151] EIP is at div64_u64+0x5f/0x70 [ 205.510151] EAX: 0000389f EBX: 00000000 ECX: 00000000 EDX: 00000000 [ ...

From: "Willy Tarreau" <w@1wt.eu> Willy, you make a bold assertion here. Your assertion would hold a That is why there are the closed, and flakey, drivers for so many products. Rather than make ideological assertions sit down and prove your points. Address cases where there is an intellectual property holder involved who has chosen Trade Secret rather than Patent as a protection on their proprietary code. Show how they will stay in business if they give away their code. Presume that their ...

Agreed. Thanks. -- Hi, I'm a .signature virus, please copy/paste me to help me spread all over the world. --

uh-oh! absolutely right shame on me. --

This patch series adds a new interface /sys/firmware/memmap to export the BIOS (Firmware) provided memory map via sysfs for usage with kexec. While the first patch adds the generic interface, the second patch implements that interface for E820 on x86. EFI is on the TODO list, and other architectures can be added later. This patch is RFC. It has been tested on x86-64 and i386 and replaces my previous attemt that adds such an interface via procfs. Signed-off-by: Bernhard Walle ...

Hi Bernhard, Thanks for the patch. Couple of thoughts. Do we really need another CONFIG option (CONFIG_FIRMWARE_MEMMAP)? To, me this does not seem to be a big chunk of code at the same time I am assuming that most of the people will use it (because of kexec). So probably, it might not make lot of sense to put additional CONFIG option. How about leaving the decision of memory type on arch dependent code? How about letting arch code pass you an string while adding entry and that string ...

Yes, PAT works equally well on my earlier model 6. The setup's already changed in linux-next though and now blacklists some Intel models only: http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git;a=blob;f=arch/x86/kernel/... Rene. --

Great, thanks! Cheers, Bernd --

Hi Oleg, I'm currently porting -rt to 26-rc7 and I came across this change: Commit: 8e60e05fdc7344415fa69a3883b11f65db967b47 With the - double_spin_lock(&new_base->lock, &old_base->lock, - smp_processor_id() < cpu); + spin_lock(&new_base->lock); + spin_lock_nested(&old_base->lock, SINGLE_DEPTH_NESTING); What's the reason that this is possible? Is it because the migration happens only on CPU hotplugging and that the CPU hotplugging code has locks that would prevent a ...

This patch brings back limiting of the E820 map when a user-defined E820 map is specified. While the behaviour of i386 (32 bit) was to limit the E820 map (and /proc/iomem), the behaviour of x86-64 (64 bit) was not to limit. That patch limits the E820 map again for both x86 architectures. Code was tested for compilation and booting on a 32 bit and 64 bit system. Signed-off-by: Bernhard Walle <bwalle@suse.de> --- arch/x86/kernel/e820.c | 5 +++++ 1 files changed, 5 insertions(+), 0 ...

I have seen past postings on this topic and there still seems to be issues. Since adding process i/o stats to collectl I've been looking more closely at process stats in general and have been digging deeper into how memory is being accounted for on my current test system which is running a 2.6.23 kernel on top of a rhel4.2 distribution and have been using 'man proc' as a guide. Specifically, I realize stats are reported in /proc/pid/stat, /proc/pid/statm and /proc/pid/status and ...

your /proc/interrutps showed just eth1, and it was on IRQ 177 -- was that from a different boot than this dmesg? in any case, when you boot these on a new kernel they should both show up on IRQ 18 (because they're on GSI 18). Also, these IOAPIC interrupts are not programmable -- they are hard-coded, so the issue is not in the ACPI PCI interrupt link programming code. -Len --

I would like to attend and I'd like to discuss the new framework for suspending and resuming devices and related things (like example implemetations of the new callbacks, the handling of wake-up etc.). Thanks, Rafael --

Hi Andrew. quirk_system_pci_resources() disables a PnP mem resource that overlaps a PCI BAR so as to not keep the PCI driver from claiming the resource. Have it do the same for io resources. Here, ACPI claims ports that overlap with my soundcard causing the soundcard driver to fail to load. It's unknown why my ACPI BIOS claims those ports; it did not use to but this is not a (kernel) regression. Some odd BIOS reconfig triggered by temporarily removing the card seems to have brought this ...

Yes, did notice but pnp_get_resource() then takes those same flags as an unsigned int -- had to pick one or the other and "the smallest one" then seemed best... Rene. --

some functions need to be moved to setup_numa.c after we merge setup32/64.c, some funcs need to be moved back to setup.c Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c deleted file mode 100644 index a81d82c..0000000 --- a/arch/x86/kernel/setup.c +++ /dev/null @@ -1,525 +0,0 @@ -#include <linux/kernel.h> -#include <linux/module.h> -#include <linux/init.h> -#include <linux/bootmem.h> -#include ...

Linus, Arjan has been observing lots of softlockup reports on kerneloops.org and would like to have the patch below in v2.6.26 to narrow the real source of it down some more, and has asked for this patch to be applied sooner than planned. The patch is queued up for the next merge window at the moment. It's well-tested and obvious. The module list is printed here the same way it's printed for oopses. Discard it if you feel in any way nervous about ...

This patch contains the following cleanups: - make the following needlessly global variables static: - required_kernelcore - zone_movable_pfn[] - make the following needlessly global functions static: - move_freepages() - move_freepages_block() - setup_pageset() - find_usable_zone_for_movable() - adjust_zone_range_for_zone_movable() - __absent_pages_in_range() - find_min_pfn_for_node() - find_zone_movable_pfns_for_nodes() Signed-off-by: Adrian Bunk ...

applied. thanks, -len --

This patch makes the needlessly global register_page_bootmem_info_section() static. Signed-off-by: Adrian Bunk <bunk@kernel.org> --- This patch has been sent on: - 5 May 2008 070dc3db481a222a79755b6a06fb300f022ff56e diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c index b3fd604..6a9a28a 100644 --- a/mm/memory_hotplug.c +++ b/mm/memory_hotplug.c @@ -86,7 +86,7 @@ void put_page_bootmem(struct page *page) } -void register_page_bootmem_info_section(unsigned long ...

When the driver was removed back in 2002 the option was forgotten. Reported-by: Robert P. J. Day <rpjday@crashcourse.ca> Signed-off-by: Adrian Bunk <bunk@kernel.org> --- 7698eb0f092f61d2f1d4d99cd7150018d4ddb6fe diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig index 55ea52f..8012ff7 100644 --- a/arch/m68k/Kconfig +++ b/arch/m68k/Kconfig @@ -578,18 +578,6 @@ config MAC_HID depends on INPUT_ADBHID default y -config ADB_KEYBOARD - bool "Support for ADB keyboard (old ...

The h8300 and sparc options somehow survived when the code stopped using CONFIG_UNIX98_PTY_COUNT. Reported-by: Robert P. J. Day <rpjday@crashcourse.ca> Signed-off-by: Adrian Bunk <bunk@kernel.org> --- arch/h8300/Kconfig | 14 -------------- arch/sparc/Kconfig | 14 -------------- 2 files changed, 28 deletions(-) 153f95e9cbfc5292daf1b115392e5fb231490aaf diff --git a/arch/h8300/Kconfig b/arch/h8300/Kconfig index 085dc6e..396ab05 100644 --- a/arch/h8300/Kconfig +++ ...

This option was forgotten when the SCSI_QLOGIC_FC driver was removed. Reported-by: Robert P. J. Day <rpjday@crashcourse.ca> Signed-off-by: Adrian Bunk <bunk@kernel.org> --- 92547181b79610ddd207a9cdbea35653a1d63b8a diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig index 81ccbd7..a72993c 100644 --- a/drivers/scsi/Kconfig +++ b/drivers/scsi/Kconfig @@ -1305,14 +1305,6 @@ config SCSI_QLOGIC_FAS To compile this driver as a module, choose M here: the module will be called ...

I just pulled from Linus and now it stalls to boot at [ 0.616031] pnp: PnP ACPI init [ 0.628031] ACPI: bus type pnp registered [ 0.640031] pnp: PnP ACPI: found 7 devices [ 0.652031] ACPI: ACPI bus type pnp unregistered [ 0.660031] SCSI subsystem initialized [ 0.664031] PCI: Using ACPI for IRQ routing [ 0.692031] PCI-GART: No AMD northbridge found. The kvm process is at 100% time. Taking the many problems I already reported about, 2.6.26 probably will be entirely ...

On Wed, 25 Jun 2008 17:32:36 +0200 the answer is: you don't use AVX in drivers just as you don't use SSE in drivers. Let me repeat this loud and clear: It is not allowed to use floating point, SSE of AVX in device drivers. (there are few places that very carefully do this anyway, the raid5 a patch introducing xsave/xrestor is being discussed already here... this is not correct; the library functions are provided by the kernel and do not use AVX etc. -- If you want to reach me ...

The announced future Intel AVX instruction set extends the 128-bit XMM registers to 256-bit YMM registers. Intel has proposed relevant ABI extensions, which I assume will be adopted in the System V ABI. See references below. Some details are not covered in the Intel documents. I have discussed this with an Intel engineer who has supplied all the details I asked for. I have listed the necessary ABI changes in detail in my manual on calling conventions (see below). One problem that has ...

Hmm, that's quite odd. There's some recent work in this area in linux-next -- do you have means to try that tree instead? Did any older version of Linux work on this board? Either way, please send .config and a full log from a bootstrap with the "noapic" option -- while this piece of code is not reached in such a scenario, various configuration tables will be dumped at the beginning regardless and that may give us hints. Maciej --

Dave, Here is the latest round of wireless fixes for 2.6.26. The EU regulatory domain patch is straight-forward and should not affect anyone who doesn't choose to use it. It is already queued in net-next-2.6, but upon reflection I think it makes sense to include it as a fix. I don't think git will choke on it at all. The iwlwifi patch is physically bigger than I would like to see at this point of the release, but it is isolated to the iwlwifi drivers and it should avoid problems with ...

Greetings all; I got a rather unpleasant surprise this morning while rebooting to 2.6.26-rc8 The drive I use for amanda's virtual tapes is a 400GB Deathstar on a sata_sil based pci card. I didn't think too much of it when the bootup said it had been mounted 26 times, check forced. So I knew I was in for a 30+ minute wait, but e2fsck normally outputs about the first 24% of the check's progress on that particular drive fairly quickly before entering a silent phase that may last 15+ ...

That looks fine. The si_utime and si_stime fields have never been standardized and I don't really know of anything that's ever actually used them. I'm sure whatever it has meant for ages is fine for it to mean now, and certainly today's clock_t is what matches what this code meant when it was written. It seems unlikely that cutime rather than utime was ever desired here. If anything, it should probably be the group-wide utime sum rather than the thread's, but that is not so trivial to sample ...

Oleg, Thomas, In the switch to configurable HZ in 2.6, the treatment of the si_utime and si_stime fields that are exposed to userland via the siginfo structure looks to have been botched. As things stand, these fields report times in units of HZ, so that userland gets information that varies depending on the HZ that the kernel was configured with. This (trivial, untested) patch changes the reported values to use USER_HZ units. What do you think of making this change? Signed-off-by: ...

Greetings, this is the first batch of patches of our project to document all s390 specific kernel messages. The first step is to cleanup the existing messages: remove debugging messages, convert messages to BUG_ON / WARN_ON and convert messages to debug feature entries. The second step will be to introduce a new family of print macros that are then uniformly used in the s390 device drivers. The third step are the Documentation files and a script that is used to check the messages and to create ...

From: Jan Glauber <jang@linux.vnet.ibm.com> Signed-off-by: Jan Glauber <jang@linux.vnet.ibm.com> --- arch/s390/crypto/prng.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) Index: quilt-2.6/arch/s390/crypto/prng.c =================================================================== --- quilt-2.6.orig/arch/s390/crypto/prng.c +++ quilt-2.6/arch/s390/crypto/prng.c @@ -185,11 +185,8 @@ static int __init prng_init(void) prng_seed(16); ret = misc_register(&prng_dev); - if ...

From: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> --- drivers/s390/char/con3215.c | 23 +---------------------- 1 file changed, 1 insertion(+), 22 deletions(-) Index: quilt-2.6/drivers/s390/char/con3215.c =================================================================== --- quilt-2.6.orig/drivers/s390/char/con3215.c +++ quilt-2.6/drivers/s390/char/con3215.c @@ -93,9 +93,6 @@ struct raw3215_info { struct raw3215_req ...

From: Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> --- arch/s390/appldata/appldata.h | 14 -------- arch/s390/appldata/appldata_base.c | 39 ++--------------------- arch/s390/appldata/appldata_mem.c | 43 +------------------------ arch/s390/appldata/appldata_net_sum.c | 39 ----------------------- arch/s390/appldata/appldata_os.c | 57 ...

From: Hongjie Yang <hongjie@us.ibm.com> Signed-off-by: Hongjie Yang <hongjie@us.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> --- drivers/s390/block/dcssblk.c | 22 +++------------------- 1 file changed, 3 insertions(+), 19 deletions(-) Index: quilt-2.6/drivers/s390/block/dcssblk.c =================================================================== --- quilt-2.6.orig/drivers/s390/block/dcssblk.c +++ quilt-2.6/drivers/s390/block/dcssblk.c @@ -167,10 +167,8 @@ ...

The message descriptions are still missing though .. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> --- drivers/s390/char/vmlogrdr.c | 29 +++-------------------------- 1 file changed, 3 insertions(+), 26 deletions(-) Index: quilt-2.6/drivers/s390/char/vmlogrdr.c =================================================================== --- quilt-2.6.orig/drivers/s390/char/vmlogrdr.c +++ quilt-2.6/drivers/s390/char/vmlogrdr.c @@ -216,9 +216,7 @@ static int ...

Does that really need to be a panic? Bastian -- Extreme feminine beauty is always disturbing. -- Spock, "The Cloud Minders", stardate 5818.4 --

From: Frank Blaschka <frank.blaschka@de.ibm.com> Cc: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> --- drivers/s390/net/qeth_core_main.c | 3 +-- drivers/s390/net/qeth_l3_main.c | 9 +-------- 2 files changed, 2 insertions(+), 10 deletions(-) Index: quilt-2.6/drivers/s390/net/qeth_core_main.c =================================================================== --- ...

From: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> --- drivers/s390/char/vmwatchdog.c | 16 +++------------- 1 file changed, 3 insertions(+), 13 deletions(-) Index: quilt-2.6/drivers/s390/char/vmwatchdog.c =================================================================== --- quilt-2.6.orig/drivers/s390/char/vmwatchdog.c +++ quilt-2.6/drivers/s390/char/vmwatchdog.c @@ -92,23 +92,15 @@ static int vmwdt_keepalive(void) func ...

From: Michael Holzheu <holzheu@de.ibm.com> Signed-off-by: Michael Holzheu <holzheu@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> --- arch/s390/kernel/debug.c | 9 --------- 1 file changed, 9 deletions(-) Index: quilt-2.6/arch/s390/kernel/debug.c =================================================================== --- quilt-2.6.orig/arch/s390/kernel/debug.c +++ quilt-2.6/arch/s390/kernel/debug.c @@ -1079,7 +1079,6 @@ __init debug_init(void) ...

From: Felix Beck <felix.beck@de.ibm.com> Signed-off-by: Felix Beck <felix.beck@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> --- drivers/s390/crypto/zcrypt_api.c | 24 ++---------- drivers/s390/crypto/zcrypt_api.h | 28 -------------- drivers/s390/crypto/zcrypt_cex2a.c | 3 - drivers/s390/crypto/zcrypt_error.h | 6 --- drivers/s390/crypto/zcrypt_pcica.c | 3 - drivers/s390/crypto/zcrypt_pcicc.c | 15 +------ ...

Hi all, Changes since next-20080624: The tip-core tree gained three conflicts against Linus' tree. The sched tree gained a conflict against the cpus4096 tree. The x86 tree gained a conflict against the ftrace tree. It also required three patches that Ingo supplied. The pci tree gained two conflicts against the x86 tree. The v4l-dvb tree has had another commit reverted for a build problem, however that may have been due to a mismerge in yesterday's tree. The acpi tree gained two ...

Lets move the error assignment inside that loop, ala - error = 0; while (spd.nr_pages < nr_pages) { + error = 0; Perhaps we can abstract that bit out into a small helper function, tied in with your previous patch. -- Jens Axboe --

Moin moin! May I just add a resounding YES-YES-YES to the message which was posted earlier today as Message-ID: <> oh b*gger, that doesn't help when snarfing from a web archive (voluntary use as a non-subscirber of a webmail interface prevents me from including a References: header without more effort than I care to do now, not that this would help) I was actually just about to post an almost identical message today to clean out my repository of hacks, with almost the same ...

Fair enough, I won't press the matter. I'm just one of those old f*rts who still remembers the american WWV talking clock and how unnerving it was after years to be hearing ``Coordinated Universal Time'' so I deserve to wither and drop off the vine. Also, in case of all my consumer equipment, I think 100% of it refers to GMT+2 (in my present time zone), so I wonder if in different languages, there's a preference for casual use of the phrase GMT (a quick look in my dictionary shows an entry ...

This patch was created by git grep -l '[vV]araible' | xargs -r -t perl -p -i -e 's/\b([Vv]ar)ai(bles?)\b/$1ia$2/g' Signed-off-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com> --- drivers/input/mouse/gpio_mouse.c | 2 +- drivers/net/skfp/h/hwmtm.h | 2 +- drivers/net/wan/farsync.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/input/mouse/gpio_mouse.c b/drivers/input/mouse/gpio_mouse.c index 3392901..f8095a0 100644 --- ...

set_type returns an int but currently setup_irq ignores that. To save me from undoing some changes setting the IRQ_NO_BALANCING bit in desc->flags, setting IRQ_PER_CPU in desc->status and adding the new action to desc is only done after set_type succeeded. Signed-off-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com> --- Hello, in my case set_type returns an error because gpio-key tries to use IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING and my irq-chip can only do one of these. Best ...

From: Mikulas Patocka <mpatocka@redhat.com> The extra 16 bytes of space allocated is so that GCC can perform a secondary reload of a quad floating point value. It always has to be present, because we can't satisfy a secondary reload by emitting yet another reload, it's the end of the possible level of recursions allowed by the reload pass. GCC could be smart and eliminate that slot when it's not used, but such a thing is not implemented yet. It would also require quite a bit of new code ...

From: Paul Jackson <pj@sgi.com> Fix some problems with (and applies on top of) a previous patch: x86 boot: show pfn addresses in hex not decimal in some kernel info printks Primarily change "0x%8lx" format, which displays with a right aligned space filled hex number (spaces between the "0x" prefix and the number), into "%0#10lx" format, which zero fills instead of space fills, and which uses the printf flag '#' to request the "0x" prefix instead of hard coding it. Also replace some other ...

Well, it wasn't that hard to fix just this issue. I tested the following two patches, and verified that splice-in and splice-out now always return full counts, even if pages are invalidated during the splicing. The ClearPageUptodate() thing in 1/2 needs a bit of careful attention from VM hackers (Hugh and Nick added to CC). I still see small issues with generic_file_splice_read() (more in a separate email) and I don't quite see how this async thing is going to work out, but that's another ...

This looks good to me, page locking is also consistent. You can add my acked-by, I'm assuming Linus will just take it directly for 2.6.26. -- Jens Axboe --

AFAICS it does. And I agree, that splice should handle truncation better. But as I said, this affects every single filesystem out there. And yes, my original patch wouldn't solve this (although it wouldn't make it harder to solve either). However the page invalidation issue is completely orthogonal, and only affects a few filesystems which call invalidate_complete_page2(), namely: 9p, afs, fuse and nfs. Miklos --

I really think we should just change splice itself at this point. The VM people may end up removing the clearing of the uptodate bit for other reasons, but there's no way I'll do this kind of thing which affects unknown number of cases for just the splice kind of reason, when we could just change the one place you care about right now - which is just FUSE/NFSD/page_cache_pipe_buf_confirm. I also really don't think this even fixes the problems you have with FUSE/NFSD - because you'll ...

I want the page fully invalidated, and I also want splice and nfs exporting to work as for other filesystems. Miklos --

I do not know fuse good enough, but it looks like if your patch only fixes issue for pages which are in splice buffer during invalidation, any subsequent call for splice() will get correct new data (at least invoke readpage(s)), but in the description of error there was a long timeout between reading and writing, so it was a fresh splice() call, which suddenly started to return errors. Is it possible that by having uptodate bit in place, but page was actually freed but not removed from all ...

Then why not fix filesystems to set error bit on all broken reads, if you sure it is the case? -- Evgeniy Polyakov --

Umm, it doesn't make any sense to try to always get fresh data. If you do read() on a file, the data may become old and invalid a millisecond after the read finished. We can't and needn't do anything about this. Miklos --

Yes, it is possible to check mapping, but it does not exist and it is correct, that there is no mapping - we are just writing into page in ram, kind of loop device, but without binding page into mapping. Page reading from disk is atomic in respect that page is always locked, now readpage(s) may not be called in some cases... -- Evgeniy Polyakov --

We discussed this yesterday. My conclusion was (which I still think is true) that it can't be fixed in page_cache_pipe_buf_confirm(), because due to current practice of not setting PG_error for I/O errors for read, it is impossible to distinguish between a never-been-uptodate page and a was-uptodate-before-invalidation page. And it's not just an nfsd issue. Userspace might also expect that if a zero count is returned, that means it went beyond EOF, and not that it should retry the splice, ...

Bug in copy_user can be used from userspace on RHEL-4 and other distributions with similar kernel base (CVE-2008-0598). Patch with fixed copy_user attached, it falls into byte copy loop on faults and returns correct count for uncopied bytes. Patch also fixes incorrect passing of zero flag in copy_to_user (%eax was used instead of %ecx). Also there's script for systemtap, it tests corner cases in both copy_user realizations (unrolled and string).

From: Haavard Skinnemoen <hskinnemoen@atmel.com> Set the 'parent' field of channel class devices to point to the physical DMA device initialized by the DMA engine driver. This allows drivers to use chan->dev.parent for syncing DMA buffers and adds a 'device' symlink to the real device in /sys/class/dma/dmaXchanY. Signed-off-by: Haavard Skinnemoen <hskinnemoen@atmel.com> --- drivers/dma/dmaengine.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git ...

Hi, I noticed a bug with respect to time drifting after multiple sleep/wakeup sequence. We have an embedded ARM11 based platform on which we have successfuly ported Linux. We also have a RTC on board. Hence we have implemented the read_persistent_clock() function overriding the one defined in kernel/time/timekeeping.c. What we observed was that after doing multiple sleep/wakeup sequences, the time reported by RTC and gettimeofday was drifting. After about 10 iterations the gettimeofday was lagging by ...

This patch brings back limiting of the E820 map when a user-defined E820 map is specified. While the behaviour of i386 (32 bit) was to limit the E820 map (and /proc/iomem), the behaviour of x86-64 (64 bit) was not to limit. That patch limits the E820 map again for both x86 architectures. Code was tested for compilation and booting on a 32 bit and 64 bit system. Signed-off-by: Bernhard Walle <bwalle@suse.de> --- arch/x86/kernel/e820.c | 3 +++ 1 files changed, 3 insertions(+), 0 ...

only this one is needed now. but please change ULLONG_MAX to ULLONG_MAX - mem_size YH --

Why can't we add that check at the beginning of e820_update_range() as you suggested? Bernhard --

Okay, thanks for review and comments. Patch sent. Bernhard -- Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development --

Hi all, I'm no kernel expert, I hope I made no mistakes in this report. It seems to me that a bug was added to the MPT Fusion driver in 2.6.26 (rc7). I compiled 2.6.26-rc7 on a machine with controller LSI53C1080 and it cannot boot. Doing the same with 2.6.25, very similar config file, boots without problems. I tried to forward-port the Fusion driver from 2.6.25 to 2.6.26-rc7 by simply copying over the directory drivers/message/fusion/ from 2.6.25 to 2.6.26-rc7 but unfortunately this doesn't ...

Yes there are. Still, I think it should be feasible which is why I personally would prefer to drop the second patch in the series for the time being. But then I can keep it around for reference locally and the original infrastructure can be found in the history after all. Even though the patch series currently doesn't fully restore the intended functionality, I'd like to merge it now. Command aborting didn't work reliably (if at all) before and now, at least, a simple ioctl won't harm a ...

Make sure that each error condition during the execution of an HDIO_DRIVE_RESET ioctl is actually reported to the calling process. Also, unify the exit path of reset_pollfunc() when returning ide_stopped since the need of ->port_ops->reset_poll() to be treated specially has vanished (way back, it seems). Signed-off-by: Elias Oltmanns <eo@nebensachen.de> --- Documentation/ioctl/hdio.txt | 2 ++ drivers/ide/ide-iops.c | 18 +++++++++++------- drivers/ide/ide.c | 10 ...

Currently, the code path executing an HDIO_DRIVE_RESET ioctl is broken in various ways. Most importantly, it is treated as an out of band request in an illegal way which may very likely lead to system lock ups. Use the drive's request queue to avoid this problem (and fix a locking issue for free along the way). Signed-off-by: Elias Oltmanns <eo@nebensachen.de> --- drivers/ide/ide-io.c | 23 ++++++++++++++++++++++- drivers/ide/ide-iops.c | 18 +++++++++++++----- drivers/ide/ide.c ...

Small whitespace cleanups for wireless drivers Signed-off-by: Pavel Machek <pavel@suse.cz> --- commit ac537c3b8a8dda4adcbf7810c4b86474e054f48c tree d638e3fbcb6d6c35109661f908d84cb81df95322 parent 7f80fda409c75b32b46a06b371fe504805188395 author Pavel <pavel@amd.ucw.cz> Wed, 25 Jun 2008 12:23:00 +0200 committer Pavel <pavel@amd.ucw.cz> Wed, 25 Jun 2008 12:23:00 +0200 drivers/net/wireless/airo.c | 41 +++++++++++++++++---------------------- drivers/net/wireless/ath5k/hw.c | 4 ...

= From: Rik van Riel <riel@redhat.com> Fix typo in show_free_areas. Debugged-by: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com> Signed-off-by: Rik van Riel <riel@redhat.com> Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> --- mm/page_alloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: b/mm/page_alloc.c =================================================================== --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -1931,7 +1931,7 @@ void ...

Yes. I ran my stress load with Nishimura-san's cpuset migration test on x86_64 and ia64 platforms overnight. I didn't have all of the memcgroup patches applied--just the unevictable lru related patches. Tests ran for ~19 hours--including 70k-80k passes through the cpuset migration test--until I shut them down w/o error. OK, I did see two oom kills on the ia64. My stress load was already pretty close to edge, but they look suspect because I still had a couple of MB free on each node ...

I'm updating the unevictable-lru doc in Documentation/vm. I have a question, below, on the removal of page_lock() from __mlock_vma_pages_range(). The document discusses how we hold the page lock when calling mlock_vma_page() to prevent races with migration [addressed by putback_lru_page() rework] and truncation. I'm wondering if we're properly protected from truncation now... If we're not holding the page locked here, can the page be truncated out from under us? If so, I think we could ...

> Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroy@jp.fujitsu.com> Agghh, typo to kamezawa-san's e-mail. resend this patch. =========================================================== putback_lru_page()/unevictable page handling rework. Changelog ================ V3 -> V4 o fix broken recheck logic in putback_lru_page(). o fix shmem_lock() prototype. V2 -> V3 o remove lock_page() from scan_mapping_unevictable_pages() and scan_zone_unevictable_pages(). o revert ...

Hi, Andrew and mm guys! this is mm related fixes patchset for 2.6.26-rc5-mm3 v2. Unfortunately, this version has several bugs and some bugs depend on each other. So, I collect, sort, and fold these patchs. btw: I wrote "this patch still crashed" last midnight. but it works well today. umm.. I was dreaming? Anyway, I believe this patchset improve robustness and provide better testing baseline. enjoy! Andrew, this patchset is my silver-spoon. if you like it, I'm glad ...

= From: Lee Schermerhorn <lee.schermerhorn@hp.com> Against: 2.6.26-rc5-mm3 Offset 'lru' by 'NR_LRU_BASE' to obtain global page state for lru list 'lru'. Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com> Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> fs/proc/proc_misc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: b/fs/proc/proc_misc.c =================================================================== --- a/fs/proc/proc_misc.c +++ ...

= From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> mem_cgroup_uncharge() against old page is done after radix-tree-replacement. And there were special handling to ingore swap-cache page. But, shmem can be swap-cache and file-cache at the same time. Chekcing PageSwapCache() is not correct here. Check PageAnon() instead. Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Acked-by: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp> Signed-off-by: KOSAKI Motohiro ...

= From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> In speculative page cache lookup protocol, page_count(page) is set to 0 while radix-tree modification is going on, truncation, migration, etc... While page migration, a page fault to page under migration should wait unlock_page() and migration_entry_wait() waits for the page from its pte entry. It does get_page() -> wait_on_page_locked() -> put_page() now. In page migration, page_freeze_refs() -> page_unfreeze_refs() is ...

When i used seq_file to read a proc file, i got a bug of seq_read. If show() skip the first element or the size of first element is 0, and the size of second element is larger than the seq_file->size at the same time, seq_read will return 0, so nothing can be read from the proc file. So, if seq_read will return because it finds the element is biger than the m->buf, it must make sure either some date was filled to m->buf by show(), or some data was flushed to the user buf before, if not,it ...

Referring to this commit in mainline: commit ac1623625c5818bbdf5c68973098ba386ba7a004 Author: Ben Dooks <ben-linux@fluff.org> Date: Fri Jun 20 20:53:35 2008 +0200 BAST: Remove old IDE driver Remove the old BAST IDE driver, as we are now using the platform-pata support. Signed-off-by: Ben Dooks <ben-linux@fluff.org> Cc: Jeff Garzik <jgarzik@pobox.com> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> I've recieved a couple of patches for the next ...

Hi, The libata part is already in, we just need an arch part. [ Looks like we need this patch from 2008-05-29: I think that it is up to arch maintainer to decide, either way is fine This was a special case as indicated in pull request: ... [ not strictly -rc stuff but as we are now using the platform-pata support lets not confuse people with having this driver around ] ... I somehow missed 'the next release' part (please indicate it more clearly when sending patches and ...

I believe that using "%-p" instead of "%#p" would work. The canonical meaning of "%-p" should be the very same as "%p", but gcc should not complain because it is ready to parse a format string like "%-10p" (which is of course different than "%10p"). A bit too tricky, perhaps?! Tested on gcc 4.1.2. Marco -- Marco Cesati <cesati@uniroma2.it> Universita' degli Studi di Roma Tor Vergata - DISP via del Politecnico 1, 00133 Roma --

Hm, no. I admit to having improved the process of compilation somewhat; I compiled only the affected files, or in case a CONFIG prevents a file from being built, the complete parent directory. I find that this works well in practice; the compiler usually warns about implicit declarations (which would otherwise show up as linker errors), so there is no need to link everything. (Sadly, this is not true when declarations are provided regardless of definition -- I think this is actually a case ...

Hi, Ingo, can you please drop the "softirq softlockup debugging" patch and apply this instead? This much, much prettier, reuses existing debugging infrastructure, and is a lot more generic. (Compile tested on allyesconfig, allnoconfig, allnoconfig + softlockup debugging.) Vegard From: Vegard Nossum <vegard.nossum@gmail.com> Date: Wed, 25 Jun 2008 08:50:10 +0200 Subject: [PATCH] softlockup: show irqtrace This patch adds some information about when interrupts were last enabled and ...

Remove the #ifdef conditional because this comparison is already done in user_mode_vm(). Signed-off-by: Gustavo F. Padovan <gustavo@las.ic.unicamp.br> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c --- a/arch/x86/mm/fault.c +++ b/arch/x86/mm/fault.c @@ -55,11 +55,7 @@ static inline int notify_page_fault(struct pt_regs *regs) int ret = 0; /* kprobe_running() needs smp_processor_id() */ -#ifdef CONFIG_X86_32 if (!user_mode_vm(regs)) { -#else - if (!user_mode(regs)) ...

What do you mean close gracefully? If you are doing IO to the disk you can wait for the host to reconnect and execute the IO. If you are going to wait for as long as it takes (or for whatever you have setup in the host (see the iscsi documentation/README on open-iscsi.org about the replacement_timeout)), and you do not want to see the dump then you can do what the dump says and do this I think: echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. If you want to just ...

Please find the kernel log attached. I was using the open-iscsi initiator on kernel 2.6.25.6 with a chelsio iSCSI target and the crash happened on the initiator machine. connection5:0: ping timeout of 5 secs expired, last rx 4309640121, last ping 4309645121, now 4309650121 connection5:0: detected conn error (1011) connection5:0: ping timeout of 5 secs expired, last rx 4309652882, last ping 4309657882, now 4309662882 connection5:0: detected conn error (1011) connection5:0: detected conn ...

The time zone handling seems racy. e.g. consider the case DST changes on that day. You convert before the switch over and suddenly the time offset is different. I'm actually not sure someone in user space is even updating the kernel idea of the timezone for DST on a switch (generally it was assumed it's some obsolete BSD concept and that all real programs only use the user space glibc implementation that knows all the rules). So DST might not be supported at all. Also even if it worked ...

Are you saying that the tz code is racy in general (I saw the following thread that you responded to as well): http://marc.info/?l=linux-kernel&m=115954057716441&w=2 Or are you saying that the proposed "utc" option makes things racy? All the "utc" option does (with this patch) is disable application of the kernel's "tz_minuteswest" offset, so using it actually should remove races with I am not sure about that either (i.e. whether tz_minuteswest is altered on DST changes or if it is ...

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- include/asm-x86/mach-bigsmp/mach_apic.h | 2 +- include/asm-x86/mach-default/mach_apic.h | 4 ++++ 2 files changed, 5 insertions(+), 1 deletion(-) Index: linux-2.6/include/asm-x86/mach-bigsmp/mach_apic.h =================================================================== --- linux-2.6.orig/include/asm-x86/mach-bigsmp/mach_apic.h +++ linux-2.6/include/asm-x86/mach-bigsmp/mach_apic.h @@ -81,7 +81,7 @@ static inline int ...

Ingo want make setup_32.c have everything (in 10 patches), and then rename setup_32.c to setup.c and delete setup_64.c will move numa related to setup_numa.c or numa.c YH --

x86 64 bit that they are same. num_phypages = max_pfn 32 bit when HIGHMEM=y, it is same.num_phypages = max_pfn when HIGHMEM=n, num_phypages = max_low_pfn YH --

One thing I was trying to do was to merge more stuff from setup_32/64 into setup.c. Unfortunately, there was some test failures on i386 that I did not have time to debug. But the file existed before my time. ;-) Why does the current setup.c need to be renamed and not simply add the merged changes into it? Thanks, Mike --

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/kernel/Makefile | 2 arch/x86/kernel/setup.c | 676 ++++++++++++++++++++++++++++++++++++++++++++- arch/x86/kernel/setup_32.c | 543 ------------------------------------ arch/x86/kernel/setup_64.c | 381 ------------------------- include/asm-x86/setup.h | 2 5 files changed, 670 insertions(+), 934 deletions(-) Index: ...

OK, that makes sense. Thanks, J --

and use max_pfn directly. Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/kernel/aperture_64.c | 6 ++++-- arch/x86/kernel/e820.c | 2 +- arch/x86/kernel/early-quirks.c | 2 +- arch/x86/kernel/machine_kexec_64.c | 2 +- arch/x86/kernel/pci-calgary_64.c | 4 ++-- arch/x86/kernel/pci-dma.c | 4 ++-- arch/x86/kernel/pci-gart_64.c | 4 ++-- arch/x86/kernel/pci-swiotlb_64.c | 2 +- arch/x86/kernel/setup_64.c ...

64bit setup_arch assign num_physpages with end_pfn... and max_pfn is defined in linux/bootmem.h num_physpages is defined in linux/mm.h YH --

Add sync_cmpxchg to match 32-bit's sync_cmpxchg. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- include/asm-x86/cmpxchg_64.h | 37 +++++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/include/asm-x86/cmpxchg_64.h b/include/asm-x86/cmpxchg_64.h --- a/include/asm-x86/cmpxchg_64.h +++ b/include/asm-x86/cmpxchg_64.h @@ -93,6 +93,39 @@ return old; } +/* + * Always use locked operations when touching memory shared with a + * ...

OK, we're in vehement agreement then. J --

No, looks like my fault. The non-PARAVIRT version of paravirt_pgd_free() is: static inline void paravirt_pgd_free(struct mm_struct *mm, pgd_t *) {} but C doesn't like missing parameter names, even if unused. This should fix it: diff -r 19b73cc5fdf4 include/asm-x86/pgalloc.h --- a/include/asm-x86/pgalloc.h Wed Jun 25 11:24:41 2008 -0400 +++ b/include/asm-x86/pgalloc.h Wed Jun 25 13:11:56 2008 -0700 @@ -11,7 +11,7 @@ #include <asm/paravirt.h> #else #define ...

What does Linux expect to scale up to? Reserving 16 PML4 entries leaves the kernel with 120TB of available 'negative' address space. Should be plenty, I would think. -- Keir --

It's never safe to call a swapgs pvop when the user stack is current - it must be inline replaced. Rather than making a call, the SWAPGS_UNSAFE_STACK pvop always just puts "swapgs" as a placeholder, which must either be replaced inline or trap'n'emulated (somehow). Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- include/asm-x86/irqflags.h | 2 +- include/asm-x86/paravirt.h | 10 ++++++++++ 2 files changed, 11 insertions(+), 1 deletion(-) diff --git ...

Hi Ingo, This series lays the groundwork for 64-bit Xen support. It follows the usual pattern: a series of general cleanups and improvements, followed by additions and modifications needed to slide Xen in. Most of the 64-bit paravirt-ops work has already been done and integrated for some time, so the changes are relatively minor. Interesting and potentially hazardous changes in this series are: "paravirt/x86_64: move __PAGE_OFFSET to leave a space for hypervisor" This moves ...

How so? What kind of failure do think might occur? Some effect on how the wrmsr arguments are evaluated? barrier() is specifically a compiler optimisation barrier, so the barrier before would prevent the compiler from moving anything logically before the wrmsr to afterwards. That said, making the wrmsr itself a memory clobber may be simpler understand with a comment, rather than separate barriers... J --

On Wed, 25 Jun 2008 00:18:59 -0400 it's more readable for several of these cases to stick a barrier(); in front and after it to be honest; that makes it more explicit that these are deliberate compiler barriers rather than "actual" memory access... -- 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 --

We must do this because load_TLS() may need to clear %fs and %gs, such (e.g. under Xen). Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- arch/x86/kernel/process_64.c | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c --- a/arch/x86/kernel/process_64.c +++ b/arch/x86/kernel/process_64.c @@ -579,6 +579,7 @@ ...

Add hooks which are called at pgd_alloc/free time. The pgd_alloc hook may return an error code, which if non-zero, causes the pgd allocation to be failed. The hooks may be used to allocate/free auxillary per-pgd information. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- arch/x86/kernel/paravirt.c | 4 ++++ arch/x86/mm/pgtable.c | 13 ++++++++----- arch/x86/xen/enlighten.c | 4 ++++ include/asm-x86/paravirt.h | 19 ++++++++++++++++++- ...

Don't conflate sysret and sysexit; they're different instructions with different semantics, and may be in use at the same time (at least within the same kernel, depending on whether its an Intel or AMD system). sysexit - just return to userspace, does no register restoration of any kind; must explicitly atomically enable interrupts. sysret - reloads flags from r11, so no need to explicitly enable interrupts on 64-bit, responsible for restoring usermode %gs Signed-off-by: Jeremy ...

This makes a few of changes to the construction of the initial pagetables to work better with paravirt_ops/Xen. The main areas are: 1. Support non-PSE mapping of memory, since Xen doesn't currently allow 2M pages to be mapped in guests. 2. Make sure that the ioremap alias of all pages are dropped before attaching the new page to the pagetable. This avoids having writable aliases of pagetable pages. 3. Preserve existing pagetable entries, rather than overwriting. Its ...

Use write_gdt_entry to generate the special vgetcpu descriptor in the vsyscall page. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- arch/x86/kernel/vsyscall_64.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/x86/kernel/vsyscall_64.c b/arch/x86/kernel/vsyscall_64.c --- a/arch/x86/kernel/vsyscall_64.c +++ b/arch/x86/kernel/vsyscall_64.c @@ -250,7 +250,7 @@ doesn't violate that. We'll find out if it does. */ static void ...

Yes, it's Eduardo's. Huh, I have the From line here; must have got stripped off by my script... J --

A bit, but not "significantly". We'd already discussed that if the amount of physical starts approaching 2^48 then we'd hope that the chips will grow some more virtual bits. J --

Jan Beulich points out that vmalloc_sync_all() assumes that the kernel's pmd is always expected to be present in the pgd. The current pgd construction code will add the pgd to the pgd_list before its pmds have been pre-populated, thereby making it visible to vmalloc_sync_all(). However, because pgd_prepopulate_pmd also does the allocation, it may block and cannot be done under spinlock. The solution is to preallocate the pmds out of the spinlock, then populate them while holding the ...

On 32-bit it's best to use a %cs: prefix to access memory where the other segments may not bet set up properly yet. On 64-bit it's best to use a rip-relative addressing mode. Define PARA_INDIRECT() to abstract this and generate the proper addressing mode in each case. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- include/asm-x86/paravirt.h | 30 ++++++++++++++++-------------- 1 file changed, 16 insertions(+), 14 deletions(-) diff --git ...

patch logistics detail: the signoff order suggests it's been authored by Eduardo - but there's no From line to that effect - should i change it accordingly? Ingo --

Some amount of asm-x86/mmu_context.h can be unified, including activate_mm paravirt hook. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- include/asm-x86/mmu_context.h | 32 ++++++++++++++++++++++++++++++++ include/asm-x86/mmu_context_32.h | 28 ---------------------------- include/asm-x86/mmu_context_64.h | 18 ------------------ 3 files changed, 32 insertions(+), 46 deletions(-) diff --git a/include/asm-x86/mmu_context.h ...

Add "memory" clobbers to savesegment and loadsegment, since they can affect memory accesses and we never want the compiler to reorder them with respect to memory references. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- include/asm-x86/system.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/asm-x86/system.h b/include/asm-x86/system.h --- a/include/asm-x86/system.h +++ b/include/asm-x86/system.h @@ -157,14 +157,14 @@ ...

64-bit Xen pushes a couple of extra words onto an exception frame. Add a hook to deal with them. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- arch/x86/kernel/asm-offsets_64.c | 1 + arch/x86/kernel/entry_64.S | 2 ++ arch/x86/kernel/paravirt.c | 3 +++ arch/x86/xen/enlighten.c | 3 +++ include/asm-x86/paravirt.h | 9 +++++++++ include/asm-x86/processor.h | 2 ++ 6 files changed, 20 insertions(+) diff --git ...

vmalloc_sync_all() is only called from register_die_notifier and alloc_vm_area. Neither is on any performance-critical paths, so vmalloc_sync_all() itself is not on any hot paths. Given that the optimisations in vmalloc_sync_all add a fair amount of code and complexity, and are fairly hard to evaluate for correctness, it's better to just remove them to simplify the code rather than worry about its absolute performance. Signed-off-by: Jeremy Fitzhardinge ...

Yes, but why build something non scalable now that you have to fix in a few years? Especially when it comes with "i have no justification" in Yes, because getting more than 48bits of VA will be extremly costly in terms of infrastructure and assuming continuing growth rates and very large machines 46bits is not all that much. -Andi --

Reasons for replacement: - they're semantically identical - end_pfn is a bad name for a global identifier - small step towards unification Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Cc: Andi Kleen <andi@firstfloor.org> Cc: Vivek Goyal <vgoyal@in.ibm.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> --- arch/x86/kernel/aperture_64.c | 4 ++-- arch/x86/kernel/e820.c | 2 +- arch/x86/kernel/early-quirks.c | 2 +- ...

pgd_index is common for 32 and 64-bit, so move it to a common place. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- include/asm-x86/pgtable.h | 20 ++++++++++++++++++++ include/asm-x86/pgtable_32.h | 20 -------------------- include/asm-x86/pgtable_64.h | 3 --- 3 files changed, 20 insertions(+), 23 deletions(-) diff --git a/include/asm-x86/pgtable.h b/include/asm-x86/pgtable.h --- a/include/asm-x86/pgtable.h +++ b/include/asm-x86/pgtable.h @@ -357,6 ...

In a 64-bit system, we need separate sysret/sysexit operations to return to a 32-bit userspace. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citirx.com> --- arch/x86/ia32/ia32entry.S | 21 +++++++++--- arch/x86/kernel/asm-offsets_64.c | 4 +- arch/x86/kernel/entry_64.S | 4 +- arch/x86/kernel/paravirt.c | 12 ++++--- arch/x86/kernel/paravirt_patch_64.c | 9 +++-- include/asm-x86/irqflags.h | 14 ++++++-- ...

Rather than just jumping to 0 when there's a missing operation, raise a BUG. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- arch/x86/Kconfig | 7 +++++++ include/asm-x86/paravirt.h | 8 ++++++++ 2 files changed, 15 insertions(+) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -433,6 +433,13 @@ the kernel is theoretically slower and slightly larger. endif + +config PARAVIRT_DEBUG + ...

This removes a pile of buggy open-coded implementations of savesegment and loadsegment. (They are buggy because they don't have memory barriers to prevent them from being reordered with respect to memory accesses.) Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- arch/x86/kernel/cpu/common_64.c | 3 ++- arch/x86/kernel/process_64.c | 28 +++++++++++++++------------- 2 files changed, 17 insertions(+), 14 deletions(-) diff --git ...

Misc fixes + several obvious cleanups + dcache.c locking annotation fixes. Please, pull from git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6.git/ for-linus Diffstat: fs/block_dev.c | 12 +++++++- fs/dcache.c | 68 ++++++++++++++++++++++++------------------------ fs/locks.c | 6 ---- fs/namei.c | 26 +++++++++--------- fs/pipe.c | 10 +++---- fs/utimes.c | 59 +++++++++++++++++++---------------------- ...

Please pull from 'davem-next' branch of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git davem-next to receive the following updates: Documentation/networking/dm9000.txt | 167 ++++ arch/blackfin/mach-bf527/boards/ezkit.c | 7 +- arch/blackfin/mach-bf533/boards/H8606.c | 7 +- arch/blackfin/mach-bf537/boards/generic_board.c | 7 +- drivers/net/Kconfig | 28 +- drivers/net/cxgb3/cxgb3_offload.c ...

OK, Thank you for your work. Best regards, Nobuhiro --

尊贵的先生（小姐）: 您好!推出此项业务是双方公司的利益，是一项双赢的业务，本公司每月都有税票剩余，因此愿为有需要的客户代理开具fa票。 本公司有增值税专用票(17%)、普通票，还可提供多家公司及不同性质的税票、海关进口增值、建筑业、广告业、运输业、商品服务等。 若有不明，欢迎来电洽谈，若有打搅、敬请谅解！ 联系电话：13570266109 陈瑛 QQ：869885017 Mail:flower-chen88@163.com 建议您保留本邮件 382008-6-25 --

Do you have a guestimate of which kernel you'll be targeting these The whole point is to identify the flow and redirect your Rx filtering to the CPU it came from. So if you did this properly, the ACKs would be landing on the CPU that originally opened the TCP flow. I don't follow why the scheduler would move the process if the Rx traffic is returning to that core. I also understand the infrastructure is going away. But without knowing when things are being changed, we can't be expected ...

Daniel, I'm not sure what to think,.. you were told how broken this approach was, you were told to give proper justification for this change. You did neither and just reposted the same old broken shite again. Wake up. (Just in case you missed it, that's a NAK) --

Broken approach ? Never heard that before, in fact the problem is whether or not the changes are needed (not weather their broken).. I gave justification in the last thread, and I'm not sure why it's unclear to you.. Daniel --

I suggest you re-read some of Thomas' emails from last time... You failed to convince, also justification goes in the changelog, not in random lkml threads. --

Most of what he's saying there is that it breaks real time, and I provided a real time fix in this set of patches. I don't have a problem with the state mixing, since 99.9% of the time we're dealing operations It boils down to POSIX compliance which was discussed in the last thread. POSIX requires the waiters to be sorts for 5-10 different API's which ultimately use the futex (most of which aren't at all related to PI). And yes I can add it to the headers, before it goes up ...

Latest RC i tried was rc6. I can attempt latest rc possibly tomorow night or in 2 days.. im waiting mvh. Kasper Sandberg --

David CHANIAL <david.ml@euro-web.fr> : Yes, please send the unabbreviated output of 'lspci -vx' and 'dmesg'. -- Ueimor --

This code looks just like the 64-bit code (I guess it's becoming prime for unification), and I'd just spent some time debugging a bug in Xen64 caused by an overrun of the allocated area when creating non-PSE mappings of physical memory. I didn't observe a specific problem with this code, but consistency and pattern matching made it seem like a necessary addition. It only ends up reserving the amount of space actually used, so there's no wasted memory. If you use PSE to create the ...

You're right, I guess I should have disabled kvm clock for 2.6.26 (which makes up the bulk of the changes) and re-enabled it for 2.6.27, but ended up not resisting the temptation. -- error compiling committee.c: too many arguments to function --

I thought it was in linux-next, wasn't it? Rafael --

Yes we will parse e820 several times, but we don't initialize pci_mem_start in every pass. It will be initialized only twice once via the e820_setup_gap code path and once via pci_setup_gap. And i think you agree that both of these are required ? During the gap calculation the previous code or the code now in e820_setup_gap does this... calculates a gap in e820_map from 0 to 2^32. Initializes pci_mem_start. And now with this patch, the code in pci_setup_gap does this... for each ...

In the patch the address obtained from the _CRS object will be passed into the function of e820_search_gap. In such case maybe we will get the In the function of setup_arch the pci_mem_start will be parsed by searching the e820 table. After the patch is applied, we will parse the pci_mem_start again in the function of pci_acpi_scan_init and it will override the value parsed in the function of setup_arch. If the pci_mem_start is incorrect in the second case, maybe it will have ...

Hi Yakui, What do you mean by the PCI0 _CRS being incorrect ? Why would the BIOS give a incorrect _CRS object ? Also we don't just take the value given from the _CRS method, we still read the e820_map to search for an unallocated resource. So even if (by chance) the _CRS method returns incorrect value we would still Yes pci_mem_start would be initialized in 2 different ways but we still have to parse the e820_map the old way because there could be Yeah, The result is different in my ...

Hi Ingo, As mentioned in this mail, http://marc.info/?l=linux-kernel&m=121441312409978&w=2 I have also added a end_addr parameter to e820_search_gap to search only till the CRS objects end_addr instead of 2^32. In the normal case via e820_setup_gap we search till 2^32. Please apply this too. Patch on top of tip/master -- e820_search_gap also take a end_addr parameter to limit search from start_addr to end_addr. Signed-off-by: AloK N Kataria <akataria@vmware.com> Index: ...

Most likely BIOS is not exporting relevant ACPI tables for the driver to detect the frequencies and such. Latest BIOS and enabling Speedstep in BIOS options will be the things to check. Thanks, --

Thanks, works. I added this to my patch series and reposted them. Bernhard -- Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development --

ok - i'll wait for v2 of these patches, which will have the feedback from Yinghai incorporated - agreed? (Please Cc: Yinghai on the next submission of this series) Thanks, Ingo --

So, my scenario is realistic. Process 2 only locks "B"'s inode in lookup_create() ("B" is the parent of the new directory "C"), and never has= to lock "A" or "A"'s parent. IOW, process 2 does not have to wait on any i_mut= ex locked by process 1. Back to the two solutions that I've suggested (copy-pasted below), which one would you prefer? If I'm right, two kinds of solutions for issue 1 (new item created while attaching a default group hierarchy): i/ tag new directories with ...

>>> On Tue, Jun 24, 2008 at 10:16 AM, in message <20080624141602.28487.81775.stgit@lsg.lsg.lab.novell.com>, Gregory Haskins Hmm...after thinking about this some more, I think I was wrong and this is unfounded. The code would eventually terminate when the f_b_g()/f_b_q() cant find a good target. Pls ignore this patch. Regards, --

Hi Andrew, thanks for the reminder, I checked and think there are a few These haven't port to ext4 yet. I could port them to ext4 if no one wants to do so. --

Yeah, it's probably quite a bit slower too (I assume you're talking about io_apic_64's msi_mask_irq). Seems like masking this at the ioapic level Great, thanks. Jesse --

Hi peter, I agree with you. but if application's virtual address space is big, we have a hard problem with mlockall since memory pressure might be a big. Absolutely. It is another example. So, I suggest following patch. It's based on idea of Takenori Nagano's memory reclaim more efficiently. I expect It will reduce application latency and will not have a regression. How about you ? Signed-off-by: MinChan Kim <minchan.kim@gmail.com> --- mm/vmscan.c | 10 ++++++++-- 1 files changed, ...

Yup. Agreed with latency is as important as throughput. if anyone explain that patch have reduce some latency and no throughput degression by benchmark result, I have no objection, Of cource. Can you post any performance result? --

I have a concern about application latency. If lru list have many pages, it take a very long time to scan pages. More system have many ram, More many time to scan pages. Of course I know this is trade-off between memory efficiency VS latency. But In embedded, some application think latency is more important thing than memory efficiency. We need some mechanism to cut off scanning time. I think Takenori Nagano's "memory reclaim more efficiently patch" is proper to reduce application ...

with my mistake, I omit following message. :( So, we need cut-off mechanism to reduce application latency. So In my opinion, If we modify some code of Takenori's patch, we can -- Kinds regards, MinChan Kim --

Hi Mauro, On Wed, 25 Jun 2008 13:28:10 +1000 Stephen Rothwell <sfr@canb.auug.org.au> = Although, on reflection, this may have been caused by the mismerge yesterday. I will leave it in tomorrow unless I am told otherwise. --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/

It never should have made the merge in that state. Niv, I suggest you stop using that broken script of yours to do checkins because you do nothing but break stuff with it. Change logs like: xiaki pmod2git xfs-linux-melb:xfs-kern:31210a (http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_stats.h?f=h#rev1.18) in the CVS tree and busted git logs make it just about impossible to track where something came from. Cheers, Dave. -- Dave Chinner david@fromorbit.com --

We knew this checkin was stuffed up and I was planning to fix it in the for-linus branch before pushing to mainline. The merge tools had kittens when it came across it too. I think we need to rip it out of ptools and re-checkin it in with the --

XFS shows 2 build problems today. 1. xfs_stats.h problem CC fs/xfs/xfs_rtalloc.o In file included from /local/linsrc/linux-next-20080624/fs/xfs/linux-2.6/xfs_linux.h:91, from /local/linsrc/linux-next-20080624/fs/xfs/xfs.h:44, from /local/linsrc/linux-next-20080624/fs/xfs/xfs_rtalloc.c:18: /local/linsrc/linux-next-20080624/fs/xfs/linux-2.6/xfs_stats.h: In function 'xfs_init_procfs': /local/linsrc/linux-next-20080624/fs/xfs/linux-2.6/xfs_stats.h:150: ...

Hi Kamalesh, On Tue, 24 Jun 2008 23:23:56 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ib= .o', needed by `drivers/media/dvb/frontends/built-in.o'. Stop. I am pretty sure that these were caused by me stuffing up the merging of the v4l-dvb tree yesterday. It should be OK today. --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/

So we could move up the acl defines in xfs_acl.h. Unless Christoph wants some other rearrangement... Index: 2.6.x-xfs-quilt/fs/xfs/xfs_acl.h =================================================================== --- 2.6.x-xfs-quilt.orig/fs/xfs/xfs_acl.h 2008-06-25 10:46:42.000000000 +1000 +++ 2.6.x-xfs-quilt/fs/xfs/xfs_acl.h 2008-06-25 11:45:25.221045485 +1000 @@ -46,6 +46,8 @@ typedef struct xfs_acl { #define SGI_ACL_FILE_SIZE (sizeof(SGI_ACL_FILE)-1) #define ...

Currently, ext3 in mainline Linux doesn't have the freeze feature which suspends write requests. So, we cannot take a backup which keeps the filesystem's consistency with the storage device's features (snapshot and replication) while it is mounted. In many case, a commercial filesystem (e.g. VxFS) has the freeze feature and it would be used to get the consistent backup. If Linux's standard filesytem ext3 has the freeze feature, we can do it without a commercial filesystem. So I have ...

On Wed, Jun 25, 2008 at 6:08 AM, Michael Kerrisk Maybe "size of a jiffy" should be replaced by "duration of a jiffy" ? An explanation of the impact of CONFIG_NO_HZ is missing. You also missed the fact that since the 2.6 kernel there are two constants related to time resolution, namely HZ and USER_HZ. HZ is the frequency of the timer interrupt, and 1/USER_HZ is the time resolution for system calls that use jiffies as time unit (e.g. the five values returned by the times() system call). The ...

Hmm, that's a bit backwards. We changed the internal handling of those interfaces to hrtimers in 2.6.16, but the accuracy is still jiffies unless you have CONFIG_HIGH_RES_TIMERS enabled (which is only possible Also you might point out that you can check whether high resolution timers are active via clock_getres() or by checking the resolution entry in /proc/timer_list. Thanks, tglx --

Thomas, So then it's simply enough to say: Since Linux 2.6.17, Linux optionaly supports high-resolution timers (configurable via CONFIG_HIGH_RES_TIMERS). Okay -- thanks. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html --

Hi Bart, Just following up a little further here. On Wed, Jun 25, 2008 at 8:32 AM, Bart Van Assche As far as I can tell, times() is the only system call that employs USER_HZ. Let me know if you think I'm wrong. The only othe place where USER_HZ seems to come into play is the time fields displayed in /proc/PID/stat and /poc/stat. (My point of verification here is looking at usages of cputime_to_clock_t() and cputime64_to_clock_t() Yes. So I think what I'll do is just add some text ...

From: Denys Vlasenko <vda.linux@googlemail.com> The thing to do in these kinds of scenerios is to provide top-level routes in kernel/sched.c where all the inlining occurs, rather than doing it in header files and thus expanding this stuff in multiple places. --

So now every call to wake_up_bit(word, bit) now is converted to: __wake_up_bit(bit_waitqueue(word, bit), word, bit); which is in turn converted to (looking into your next patch): { wait_queue_head_t *wq = bit_waitqueue(word, bit); struct wait_bit_key key = __WAIT_BIT_KEY_INITIALIZER(word, bit); if (waitqueue_active(wq)) __wake_up(wq, TASK_NORMAL, 1, &key); } which is in turn converted to (looking into your other patch): { ...

Now this is a better approach - to actually see how many callsites are there, and inlining only where makes sense. But in practice it's hard to do and also is changing all the time during development. What is optimal today won't be optimal in 2.6.45 :) Ingo's suggestion to talk to gcc people to remedy insane call convention sounds as a more workable solution. BTW, i386 uses regparm call convention, is similar trick Yes, probably... If you can simplify it, everyone will be ...

Yes, that's 0.2% code size increase (or none increase, if drop inline-__wake_up_bit.patch and apply only the other patches). To me it seems crazy, how this code was refactored again and again over time, up to 8 levels of functions (including passing a pointer to a method). In 2.0.x kernel series, it was just a single call to wake up a queue. Mikulas --

I don't think bi_idx is a fantastic idea, I could easily imagine the bi_end_io function wanting to do a segment loop on the bio. Use bi_phys_segments instead (or bi_hw_segemnts, no difference), they should only be used when queuing and building IO, not for completion purposes. And put a big fat comment there explaining the overload. Plus they are just a cache, so if you use either of those and at the same time clear BIO_SEG_VALID in bi_flags, then it's guarenteed to be safe. Also please put ...

i've applied them to tip/x86/setup-memory, replacing the larger patch - thanks Yinghai. Ingo --

My intentioon in this case. Yes, this should be. THERMAL_HWMON is a bool (as in, not a tristate) that just changes THERMAL. If THERMAL=y, we need HWMON=y or we'd get a link failure. If THERMAL=m, we're okay with either HWMON=y and HWMON=m and if THERMAL=n, we don't care one hoot about THERMAL_HWMON... Rene. --

So far I own two ATAPI devices, IDE disks are quire rare nowadays, No, it's not Intel I/O APIC. IRQ18 is the virtual "Linux IRQ", no Hardirq preemption is on, of course. The whole problem is when hardirqs What do you mean by doesn't mask off? With hardirqs preemption it does mask off IDE interrupt, and then sends an EOI. But it doesn't mask processors' IRQs (i.e. local_irq_disable()), true. And MPIC is using It is PowerPC MPC8610 + ULi "Super South Bridge" connected through PCI Express. ...

Are you sure the kernel isn't touching the status register and so clearing the IRQ condition at the controller ? --

Nope. But I don't think that I can configure it anyway. The thing is that this particular setup doesn't use ULi's i8259 PIC (it is disabled by one of PCI quirks), and IDE interrupt is a sideband PCI-E interrupt (also configured by the PCI quirk). So IDE interrupt is "directly" connected to OpenPIC interrupt line (through the SOC PCI-E controller, of course). If that ULi bridge (M1575) provides some other means of configuring, I could try it... with the specifications. -- Anton ...

Thanks for the drive, and the result is: hda: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest } ide: failed opcode was: unknown -- Anton Vorontsov email: cbouatmailru@gmail.com irc://irc.freenode.net/bd2 --

applied --

From: "Ray Lee" <ray-lk@madrabbit.org> See if firefox is stuck in disk wait when things get wedged like this. --

I agree, after playing around with different applications I'm noticing this around firefox and flash as well. When watching T.V. through mplayer there is no problem at all i.g. having three T.V. stations playing all at once plus music streaming gives me no errors or pauses at all, not even any pops in the music. But as soon as I load firefox the pauses occur, and so forth(ussually have to restart firefox a couple of times to have it run smooth). Maybe there is something in about:config ...

Hmm, well I really don't know what to say with the tcp connection(issue), It seems to go in and out of phases i.g. at first running music, and t.v.(through flash) there's moments of pauses,(around 5 secs or so) then after a while the tcp seems to even itself out, but then after a while(5min or so) the same pauses begin. Maybe due to some missing packet, or some deadlock if this is proper to say. regards; -- Justin P. Mattock --

Hi, Please merge this instead, it's based on linux-next. Your change wasn't enough. And I don't think Tom Zanussi should be Cc-ed on patches 1 and 2, these are mere prereqs for the 3rd. So add the Cc for Tom just for the third. You could add yourself as Cc to the other two, or whoever you think is responsible for such core stuff. Cheers, Eduard --

On Mon, 23 Jun 2008 18:52:21 +0800 Acked-by: Alessandro Zummo <a.zummo@towertech.it> -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it --

Hi, Cool, thanks for testing! I think the above patch is right but not enough. Dave, what do you think about the following? --- From: Johannes Weiner <hannes@saeurebad.de> Subject: cpufreq: cancel self-rearming work synchroneuously The ondemand and conservative governor workers are self-rearming. Cancel them synchroneously to avoid nasty races. Reported-by: Nageswara R Sastry <rnsastry@linux.vnet.ibm.com> Signed-off-by: Johannes Weiner <hannes@saeurebad.de> --- diff --git ...

Thanks Thomas -- that's what I was beginning to understand, butit's nice to have confirmation. -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html --

Actually, it is worse. On thinkpad, PCMCIA card is only detected once. If I remove it and reinsert it, it will not be detected, and machine will not reboot. Thinkpad X60. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

Hmm, hitting sysrq-w produces no blocked task until I eject pcmcia card. Backtrace there is: Greg, I believe some traces lead to sysfs, can you help here? Pavel SysRq : Show Blocked State task PC stack pid father pccardd D f7fb53b8 0 1121 2 f6d37e30 00000086 00000000 f7fb53b8 00000002 f7c71ef0 c2015e80 c2015e80 00000282 834ba19e 0000001a f7fb53b8 f7fb5618 c2015e80 f6d36000 f68ccdc0 f6d37e08 00013c4d 00000000 c085d5dd ...

ide_unregister() does not complete :-(. device_unregister(&hwif->gendev); + printk("ide_unregister: waiting for rel_comp\n"); wait_for_completion(&hwif->gendev_rel_comp); ...that wait_for_completion never returns. I added some debug prints: Jun 25 23:59:21 amd cardmgr[1389]: start cmd exited with status 1 Jun 25 23:59:25 amd kernel: pccard: card ejected from slot 0 Jun 25 23:59:25 amd kernel: ide_unregister Jun 25 23:59:25 amd kernel: ide_unregister: have ...

On Sun, 22 Jun 2008 20:42:13 -0700 Acked-by: Alessandro Zummo <a.zummo@towertech.it> -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it --

It's in MM now too ... are all the bkl-removal patches going in I was just copying that usage from drivers/rtc/interface.c ... all users there return -EBUSY. If it's wrong in this patch it's probably wrong there too. I suspect EINTR is the answer in all cases. - Dave --

On Wed, 25 Jun 2008 16:39:28 -0600 For an ioctl case which should never be blocking for long periods it shouldn't be _interruptible in the first place, that will just introduce bizarre and weird bugs in application code. If there are slow ops they should drop and retake the lock. Alan --

On Sun, 22 Jun 2008 19:55:42 -0700 Acked-by: Alessandro Zummo <a.zummo@towertech.it> -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it --

OK, here you go: -- adamw

Please also set the debug module parameter for the ipaq module. Regards Oliver --

Sorry for taking some time, I've been struggling with the init system. I now see that the problem still is in 2.6.26-rc8, I will do that I run "udev" that starts "gpsd" when I plug in a gps. The gps is then connected to /dev/ttyUSB0. I then run "gpxlogger" that simply contact gpsd and prints coordinates to stdout. I also run "xgps" that contact gpsd in order to show some info about the gps satellites in use. All software from debian testing. The problem is triggered by bending the USB cable ...

Hi, Well, I guess I'm just lucky it didn't turn into a heisenbug with all Unfortunately I could only run a small test today. I added some simple debugging code for the spinlock usage in hcd.c (see attached diff) and I get the following message at lockup (I tried it twice just to be sure): HCD URB list locked by usb_hcd_link_urb_to_ep! As far as I understand the matter this only can happen if usb_hcd_link_urb_to_ep() gets interrupted while holding the spinlock. But according to the ...

So maybe a use-after-free bug in the I/O error handling caused an inode to be overwritten and then passed to an I/O function that used an invalid inode->i_blkbits? Arnd <>< --

That doesn't work - gcc warns about it. That turns out to be a problem with %#p too. It's really irritating how we cannot extend on the printk strings without either having to throw out gcc warnings altogether. gcc has no extension mechanism to the built-in rules ;/ The format warnings are too useful to drop entirely. I guess sparse could be taught to do them, and then we could drop the gcc support for them. But that would still limit coverage a _lot_. Linus --

Yes, zero padding. What we really should have is %p produce this format. For some odd reason, right now %p produces numbers without the 0x prefix. -h --

We should probably start working on getting this fixed. In networking, we've gone through various incarnations of print_mac() which is similar to the sym() macro Paul proposed, and it turned out to be undesirable because of the way it interacts with static inlines that only optionally contain code at all, the print_mac() function call is still emitted by the compiler. People experimented with marking it __pure but that had other problems. It would be nice to be able to say u8 ...

You're right, I didn't. I still think the 0x%p's and -- even worse -- 0x%08lx's (what about 64 bits?!) we currently have *all over the kernel* suck, but yes, that's a minor problem and getting the symbolic info would be a very nice thing. It looks like gcc will warn about just about ever modifier to %p. I wondered whose diseased brain came up with that idea. Overall, I think the glibc people have botched their printf extensions horribly, failing to pick up the very useful %I ...

Ah so. How about the following "sym(addr, buf)" macro? This could make it more practical to include kernel symbols within ordinary printk's. On a silly little test with: { char b1[32], b2[32], b3[32]; printk(">>>>>> Testing sym(): A. %s, B. %s, C. %s\n", sym(&pid_max, b1), sym(0xffffffff80615750, b2), /* an addr in my System.map */ sym(0, b3)); } the kernel printed: >>>>>> Testing sym(): A. pid_max+0x0/0x4, B. trampoline_base+0x0/0x10, C. ...

Hmmm ... the '#' is a good idea, instead of an explicit "0x". Do we want zero padding as well, with "0#8lx" ? Zone PFN ranges: DMA 0x00000000 -> 0x00001000 DMA32 0x00001000 -> 0x00100000 Normal 0x00100000 -> 0x00428000 or right aligned, space padded: Zone PFN ranges: DMA 0x0 -> 0x1000 DMA32 0x1000 -> 0x100000 Normal 0x100000 -> 0x428000 I like the zero padding here myself. -- I won't rest till it's the ...

Any reason we can't just re-define %p to print the 0x prefix, just as glibc does? It'd be easy enough to go and sed out all the 0x%p's currently in the kernel. -hpa --

You don't even have to go that esoteric. Just printing things like "sector_t" or "u64" is painful, because the For special things, I do think we should extend the format more, and forget about single-character names. It would be lovely to do them as %[mac], %[u64], %[symbol] or similar. Because once you don't rely on gcc checking the string, you can do it. The problem is that right now we absolutely _do_ rely on gcc checking the string, and as such we're forced to use standard ...

You didn't listen. I want #p to do the _symbolic_ address. The thing we have in the backtraces etc. With nice symbol offset information etc. The '0x<hex>' thing isn't all that interesting. You can do it by adding the '0x' by hand, or by using a cast and using %#lx instead. Linus --

It's ok if nr_cpu_ids is an overestimate, isn't it? But for this corner case, I think clearing cpu_possible_map is wrong. Cheers, Rusty. --

Andrew might complain that the above function is too big to be inlined. I'm not really sure where he draws the borderline but I believe Here should be __func__ as well - not your fault, I know... Anyway, Apart from (char *) thing, you also don't need braces above. Maybe the whole while loop would be nicer as: de2 = de; while (de2 != NULL && de2 < top) { de = de2; de2 = ext3_next_entry(__func__, dir, de, bh, 0); Honza -- Jan Kara <jack@suse.cz> SuSE CR Labs --

For what it's worth, you can add Acked-by: Jan Kara <jack@suse.cz> -- Jan Kara <jack@suse.cz> SUSE Labs, CR --

And I can't write a patch without learning a lot more about how the Is it? What does the block layer do when it receives an I/O request that don't satisfy the other constraints (max_sectors or Why do you think I think that USB can't? I didn't ask whether it was _possible_; I asked whether it was _reasonable_. Alan Stern --

On Tue, 24 Jun 2008 10:57:13 -0400 (EDT) I can't say that it's easy to implement a clean mechanism to break up a request into multiple requests until I see a patch. What I said is that you think that this is about extending something in the block layer but it's about adding a new concept to the block The block layer does. Why do you think that USB can't? --

Hi, Ivo and John (again). Just for your information, I just compiled the -rc7 kernel on x86-64 (where rt2500usb works if I boot with kernel 2.6.25) and still doesn't work (I'm not even mentioning here PowerPC). The "doesn't work" part means that the usual procedure of bringing the interface up, setting the key (I'm using WEP), setting the essid (at which point it should already be associated with the AP) and then using a dchp client on the interface doesn't get a DHCP lease. The DHCP ...

** note : early RFC. This patch applies on a unreleased LTTng for 2.6.26-rc8 patchset. Scheduler tracepoint probes Only a single probe is implement as a POC. Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> CC: 'Peter Zijlstra' <peterz@infradead.org> CC: "Frank Ch. Eigler" <fche@redhat.com> CC: 'Ingo Molnar' <mingo@elte.hu> CC: 'Hideo AOKI' <haoki@redhat.com> CC: Takashi Nishiie <t-nishiie@np.css.fujitsu.com> CC: 'Steven Rostedt' <rostedt@goodmis.org> --- init/Kconfig ...

On Fri, 20 Jun 2008 08:38:19 -0700 This is one helluva large (security!) patch for so late in -rc. Could we please split out the bugfix for 2.6.26 (is it needed in 2.6.25 too?) and hold the refactoring back for 2.6.27? --

On Fri, 20 Jun 2008 20:31:42 +0530 The comment and the function name imply that thins function will "Add the value val to the resource counter". But it doesn't do that at all. In fact the first arg could be a `const struct res_counter *'. Perhaps res_counter_can_add() would be more accurate. --

I did look at that and use that code, but we initialize ret = -EINVAL and then we have the checks for if (flags & ~(MREMAP_FIXED | MREMAP_MAYMOVE)) goto out; if (addr & ~PAGE_MASK) goto out; In out, we check for ret & ~PAGE_MASK That's OK for vm_unacct_memory, since charged is set to 0, but not for mem_cgroup_uncharge_as as we uncharge (new_len - old_len) >> PAGE_SHIFT); Yes, that is nasty and a bad miss. It should ...

In fact this issue is related with the following factors: a. when acpi is disabled, OS won't initialize the ACPI mutex, which is accessed by many ACPI interface functions. For example: acpi_walk_namespace, acpi_install_fixed_event_handler. b. When acpi is disabled, some drivers will call the ACPI interface functions. For example: The acpi_walk_namespace is called in dock_init/bay_init. The acpi_install_fixed_event_handler is called in the acpi_rtc_init. Although the following ...

On Tue, 24 Jun 2008 22:34:25 -0400 (EDT) Please do not use warn_on_slowpath() directly! Please use WARN_ON() or WARN(). The later has printk semantics so this could turn into WARN(1, "ACPI Error (%s-%0d): \n", module_name, line_number); and kerneloops.org and various other tools will pick up the printk like arguments as part of the warning message. -- If you want to reach me at my work email, use arjan@linux.intel.com For development, discussion and tips for power savings, ...

No, that commit was not a bug, it was correct, and still is, for pnpACPI and pnpBIOS must be mutually exclusive. The thing that changed was the RTC specific code. -Len --

I think most current uses of acpi_walk_namespace() are indications that the ACPI or PNP core is missing something. In dock_init() and bay_init(), it's used to bind a driver to a device. I think it would be better if we could figure out how to use the usual acpi_bus_register_driver() interface. Actually, it looks like this is already 90% done: acpi_dock_match() does the same thing as is_dock(), so it looks like dock_init() could easily be converted to register as a driver for ...

Yes. That particular quirk getting ignored was a bug. Below patch fixes the bug, until we have the dynamic banks support. sysfs choice configuration should not have any issues with the earlier patch as we look for NR_SYSFS_BANKS in do_machine_check(). Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> --- arch/x86/kernel/cpu/mcheck/mce_64.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) Index: ...

Sorry about the delay, but here's /proc/interrupts: CPU0 0: 1342021 IO-APIC-edge timer 1: 416 IO-APIC-edge i8042 6: 6 IO-APIC-edge floppy 8: 1 IO-APIC-edge rtc 12: 13367 IO-APIC-edge i8042 169: 1 IO-APIC-level acpi 177: 8882 IO-APIC-level libata, eth1 185: 75633 IO-APIC-level uhci_hcd:usb1, i915@pci:0000:00:02.0 193: 0 IO-APIC-level uhci_hcd:usb2 NMI: 0 LOC: ...

Hi Rusty, I see two options how to do this -- either I can make 'value' input parameter too, so that find_symbol_in_section() could perform lookup either according to address or according to name (whatever is specified in the passed struct find_symbol_arg), or I can do a completely new lookup function for address-wise lookups. What would you prefer? I don't have any strong preference either way. Thanks, -- Jiri Kosina SUSE Labs --

I seem to remember actively making the code work the way it does when I originally wrote it, what I can't remember is why I did that :/. Anyhow, I have no objections to the change and will probably queue it for the next merge window, its post 2.6.26 material. Cheers, Richard --

applied --

Mostly just being a sanity check. We can remove that if it easier. Eric --

This patch allows torturing RCU from irq handlers (timers, in this case). A new module parameter irqreader enables such additional torturing, and is enabled by default. Variants of RCU that do not tolerate readers being called from irq handlers (e.g., SRCU) ignore irqreader. (No failures observed, but only short tests thus far. And no failures observed thus far from about 10 hours of running stock rcutorture in parallel with 170 kernel builds on a two-CPU machine.) Signed-off-by: Paul E. ...

Ralf, I assume you're ok with this? Thanks, --

Version two works for me too. I am not seeing the reserve value become negative when running the libhuge tests. Jon --

Very cool tool, I like it a lot, thanks for pushing this. greg k-h --

The original patch used /proc/ (/proc/meminfo had badpage summary info and /proc/badram had detailed info. It was suggested that /sys was a better place. FWIW, I'm more than happy to put it anywhere deemed "best" by the community. It is currently /sys/kernel/badram. Thanks, -- Russ Anderson, OS RAS/Partitioning Project Lead SGI - Silicon Graphics Inc rja@sgi.com --

Manfred Spraul writes: > > Humm... now this make me think that you did not change the MSGMNB > > value when you changed MSGMNI and MSGMAX. > > Maybe that was on purpose? > > > > > I was afraid that it might break user space applications that queue a > few kb of messages. Ok, the choice of a maximum value of 65536 which is already is use for several months/years was made partly for the same concern. Beside, as the values are not enforced, we should be relatively safe. Searching ...

--- Add better explanation to pci-gart. Signed-off-by: Pavel Machek <pavel@suse.cz> diff --git a/arch/x86/kernel/pci-gart_64.c b/arch/x86/kernel/pci-gart_64.c index 838a1d3..e72e583 100644 --- a/arch/x86/kernel/pci-gart_64.c +++ b/arch/x86/kernel/pci-gart_64.c @@ -800,10 +800,10 @@ #endif wbinvd(); /* - * Try to workaround a bug (thanks to BenH) + * Try to workaround a bug (thanks to BenH): * Set unmapped entries to a scratch page instead of 0. * Any prefetches that ...

With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft Centre The Corporate Village

> > And we are not talking about something to be done once, as soon as you > leave x86 there are tons of regular breakages. Could automated builds and build error reporting be used to help resolve these problems? The good people at Simtec have an automated build report available as an e-mail digest. I use it to watch for architecture build breakages in subsystems or drivers that I use or touch. It covers defconfigs of ARM and MIPS architectures and reports compile errors/warnings, ...

Thanks a lot, Ingo --