Hi, During a hibernate cycle on my G5, while machine was powering down after saving the image, I just had a NULL dereference in clockevents_program_event when accessing dev->mode, dev was NULL. Unfortunately the machine rebooted before I was able to write down more than the fact that it was called from tick_program_event(); the problem doesn't seem to be easily reproducible. =46rom what I can see when doing the same thing, the shutdown attempts to offline all CPUs. Because the snapshot was...

This patch adds and changes a few sanity checks in dmar.c. 1. The haw field in ACPI DMAR table in VT-d spec doesn't describe the range of haw. But since DMA page size is 4KB in DMA remapping, haw should be at least 4KB. The current VT-d code in dmar.c returns failure when haw==0. This sanity check is not accurate and execution can pass when haw is less than one page size 4KB. This patch changes the haw sanity check to validate if haw is less than 4KB. 2. Add dmar_rmrr_units verification. 3. Add ...

Hi, Here follows a highly experimental patch for the kernel that catches uses of uninitialized memory. (Also see the commit message below for more technical information.) This is a very early stage implementation. In fact, don't even expect it to work for you. The only supported arch is x86_32 and even qemu-0.9.0 gets it wrong (use qemu-cvs if you want to test it). I am mainly interested in comments and feedback. I'm sure there are a lot of things that could be done differently (and better). F...

Woah, the linux-usb-devel@sf.net list is NOT a subscriber-only list at all. It's wide open with a bunch of mailman rule filter to try to handle the worst of the spam. It does complain if you try to add too many cc:s to it, but that's it, an admin (me or Stephen) will usually get around to aproving them within 24 hours. But, I have no objection to moving to vger if you want to handle the admin load. If so, should I send you a list of addresses that were on the sf.net list so that people can b...

Patch 3 of 3 This patch bumps the version of the driver from .14 to .18 to more closely match the driver that HP ships. This driver already supports all the hardware that the HP 3.6.18 version supports. So the versions should match, also. Please consider this for inclusion. Signed-off-by: Mike Miller <mike.miller@hp.com> diff --git a/Documentation/cciss.txt b/Documentation/cciss.txt index e65736c..0467639 100644 --- a/Documentation/cciss.txt +++ b/Documentation/cciss.txt @@ -21,6 +21,7...

Remove errnoeous x character from dev_dbg() call that stops the driver compiling under debug. Signed-off-by: Ben Dooks <ben-linux@fluff.org> Index: linux-2.6.22-quilt2/drivers/mfd/sm501.c =================================================================== --- linux-2.6.22-quilt2.orig/drivers/mfd/sm501.c 2007-07-09 00:32:17.000000000 +0100 +++ linux-2.6.22-quilt2/drivers/mfd/sm501.c 2007-07-28 10:38:39.000000000 +0100 @@ -156,7 +156,7 @@ static void sm501_dump_clk(struct sm501_ dev_dbg...

The following patches do a bunch of cleanup and rejiggering to the x86 vDSO implementation, but don't change any actual code in the routines in the vDSO. They consolidate the 32-bit vDSO code and support for it between i386 and x86_64/ia32. This makes them behave the same where they didn't before (placement), and reduces a lot of duplication. They simplify the magic for tracking addresses inside the vDSO, which makes it possible to remove the fragile kludges in the layout of the vDSO images. They...

This reorders the code in the 32-bit vDSO images to put the signal trampolines first and __kernel_vsyscall after them. The order does not matter to userland, it just uses what AT_SYSINFO or e_entry says. Since the signal trampolines are the same size in both versions of the vDSO, putting them first is the simplest way to get the addresses to line up. This makes it work to use a more compact layout for the vDSO. Signed-off-by: Roland McGrath <roland@redhat.com> --- arch/x86/vdso/vdso32...

This puts the syscall version of the 32-bit vDSO in arch/x86/vdso/vdso32/ for 64-bit IA32 support. This is not used yet, but it paves the way for consolidating the 32-bit vDSO source and build logic all in one place. Signed-off-by: Roland McGrath <roland@redhat.com> --- arch/x86/vdso/Makefile | 1 + arch/x86/vdso/vdso32/sigreturn.S | 9 +++-- arch/x86/vdso/vdso32/syscall.S | 69 ++++++++++++++++++++++++++++++++++++++ 3 files changed, 76 insertions(+), 3 deletions(-) ...

This changes the 64-bit kernel's support for the 32-bit sysenter instruction to use stored fields rather than constants for the user-mode return address, as the 32-bit kernel does. This adds a sysenter_return field to struct thread_info, as 32-bit has. There is no observable effect from this yet. It makes the assembly code independent of the 32-bit vDSO mapping address, paving the way for making the vDSO address vary as it does on the 32-bit kernel. Signed-off-by: Roland McGrath <roland@red...

This makes the i386 kernel use the new vDSO build in arch/x86/vdso/vdso32/ to replace the old one from arch/x86/kernel/. Signed-off-by: Roland McGrath <roland@redhat.com> --- arch/x86/Makefile_32 | 3 +- arch/x86/kernel/Makefile_32 | 43 +-------------- arch/x86/kernel/asm-offsets_32.c | 2 - arch/x86/kernel/signal_32.c | 5 +- arch/x86/kernel/sysenter_32.c | 6 +- arch/...

This enables 'make vdso_install' for i386 as on x86_64 and powerpc. Signed-off-by: Roland McGrath <roland@redhat.com> --- arch/x86/Makefile_32 | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/arch/x86/Makefile_32 b/arch/x86/Makefile_32 index 99dc511..4c869ef 100644 --- a/arch/x86/Makefile_32 +++ b/arch/x86/Makefile_32 @@ -153,9 +153,13 @@ zdisk bzdisk: vmlinux fdimage fdimage144 fdimage288 isoimage: vmlinux $(Q)$(MAKE) $(build)=$(boot) BOOTIMAGE=$(KBUIL...

This builds the 32-bit vDSO images in the arch/x86/vdso subdirectory. Nothing uses the images yet, but this paves the way for consolidating the vDSO build logic all in one place. The new images use a linker script sharing the layout parts from vdso-layout.lds.S with the 64-bit vDSO. A new vdso32-syms.lds is generated in the style of vdso-syms.lds. Signed-off-by: Roland McGrath <roland@redhat.com> --- arch/x86/vdso/Makefile | 76 +++++++++++++++++++++++++++++++++++- arch/x86...

This revamps the vDSO linker script to lay things out with the best packing of the data and good, separate alignment of the code. The rigid layout using VDSO_TEXT_OFFSET no longer matters to the kernel. I've moved the layout parts of the linker script into a new include file, vdso-layout.lds.S; this is in preparation for sharing the script for the 32-bit vDSO builds too. Signed-off-by: Roland McGrath <roland@redhat.com> --- arch/x86/vdso/vdso-layout.lds.S | 64 ++++++++++++++++++++++++ ...

Get rid of vdso-syms.o from the kernel link. We don't need it any more. Signed-off-by: Roland McGrath <roland@redhat.com> --- arch/x86/vdso/Makefile | 15 ++------------- 1 files changed, 2 insertions(+), 13 deletions(-) diff --git a/arch/x86/vdso/Makefile b/arch/x86/vdso/Makefile index d2ec170..6a665dd 100644 --- a/arch/x86/vdso/Makefile +++ b/arch/x86/vdso/Makefile @@ -6,13 +6,13 @@ vobjs-y := vdso-note.o vclock_gettime.o vgetcpu.o vvar.o # files to link into kernel -obj-y...

This patch adds a new way of extracting symbols from the built vDSO image. This is much simpler and less fragile than using ld -R; it removes the need to control the DSO layout quite so exactly. I was clearly unduly distracted by clever ld uses when I did the original vDSO implementation. Signed-off-by: Roland McGrath <roland@redhat.com> --- arch/x86/vdso/Makefile | 14 ++++++++++++++ arch/x86/vdso/vdso.lds.S | 10 ++++++++++ 2 files changed, 24 insertions(+), 0 deletions(-) dif...

This message contains a list of some regressions from 2.6.23 which have been reported since 2.6.24-rc1 was released and for which there are no fixes in the mainline that I know of.  If any of them have been fixed already, please let me know. If you know of any other unresolved regressions from 2.6.23, please let me know either and I'll add them to the list. Subject : On 2.6.24-rc1-gc9927c2b BUG: unable to handle kernel paging request at virtual address 3d15b925 Submitter : Giacomo Catenazzi &...

Yes, I'm working on this. There should be a patch by tomorrow. -

There is a kind of ongoing project to support the panel buttons in FSC Lifebook laptops. This is another approach since the apanel driver does not work for me. They are partly similar, though. It seperates I2C chip support from the handling of the table information. That improves readability a lot (at least for me) and allows one driver per chip and reusability of those drivers. The components include: * the oz99x driver to make the buttons on a Lifebook C-6637 work * the fjkeyinf driver to read...

No the merge window for 2.6.24 closed a few weeks ago. TTM wasn't in -mm for the 2.6.23 cycle as we hadn't finished the API stabilisation work in time. So I don't expect we'll see it before 2.6.25. I also have a few AGP changes I need to line up to support the chipset flushing work I've done to support TTM properly.. Dave. > [1] http://userweb.kernel.org/~akpm/mmotm/broken-out/git-drm.patch

Sharp Zaurus SL-C3200 with CONFIG_MTD=m and CONFIG_MTD_SHARP_SL=y (as it is bool) lost support for the ROM flash. With CONFIG_MTD=y it has no problems. It is caused by losing of compiled code of drivers/mtd/maps/sharpsl-flash.o. It was linked to drivers/mtd/maps/built-in.o and drivers/mtd/built-in.o, but lost and not linked to drivers/built-in.o (because CONFIG_MTD!=y). Patch below fixes this problem by creating sharpsl-flash.ko (and the code works correctly as a module). This is second try (...

Hi! I think that this worked before: root@amd:/proc# find . -name "timer_info" find: WARNING: Hard link count is wrong for ./net: this may be a bug in your filesystem driver. Automatically turning on find's -noleaf option. Earlier results may have failed to include directories that should have been searched. root@amd:/proc# Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -

Hi! On unloaded x60 system, 2.6.24-rc3 (tainted-pavel-so if someone can reproduce it, it would be helpful): pavel@amd:~$ while true; do time sleep 0.01; done 0.00user 0.00system 0.01 (0m0.013s) elapsed 30.71%CPU 0.00user 0.00system 0.02 (0m0.024s) elapsed 8.36%CPU 0.00user 0.00system 0.01 (0m0.013s) elapsed 15.53%CPU 0.00user 0.00system 0.02 (0m0.026s) elapsed 7.75%CPU 0.00user 0.00system 0.01 (0m0.013s) elapsed 23.34%CPU 0.00user 0.00system 0.20 (0m0.207s) elapsed 1.45%CPU 0.00user 0.00system...

hpet-disable helps.. a bit. 200msec latencies are gone. (What is used for wakeups in this case?) pavel@amd:~$ while true; do time sleep 0.01; done 0.00user 0.00system 0.01 (0m0.013s) elapsed 22.96%CPU 0.00user 0.00system 0.01 (0m0.018s) elapsed 11.05%CPU 0.00user 0.00system 0.01 (0m0.013s) elapsed 15.54%CPU 0.00user 0.00system 0.03 (0m0.037s) elapsed 8.05%CPU 0.00user 0.00system 0.01 (0m0.013s) elapsed 23.34%CPU 0.00user 0.00system 0.03 (0m0.037s) elapsed 8.14%CPU 0.00user 0.00system 0.01 (0m0....

There is an unmatched parenthesis in the locking commentary of radix_tree.h which is trivially fixed by the patch below. Signed-off-by: Tim Pepper <lnxninja@linux.vnet.ibm.com> Cc: Nick Piggin <npiggin@suse.de> --- diff --git a/include/linux/radix-tree.h b/include/linux/radix-tree.h --- a/include/linux/radix-tree.h +++ b/include/linux/radix-tree.h @@ -91,7 +91,7 @@ do { \ * * For API usage, in general, * - any function _modifying_ the tree or tags (inserting or del...