Re: [RFC, PATCH 2/4] SoC base drivers: ASIC3 SoC hardware definitions
On Tue, 1 May 2007 08:08:39 +0300 Paul Sokolovsky <[EMAIL PROTECTED]> wrote: > Hello linux-kernel, > > Intro: This is a header with hardware definitions for ASIC3 chip, > contributed by HP/Compaq. It is provided as-is, as a vendor-originated > header. > - > > ipaq-asic3.h: Hardware definitions for ASIC3 chip, found in ~12 > handheld devices from HP/Compaq and HTC. > > Signed-off-by: Paul Sokolovsky <[EMAIL PROTECTED]> > > > include/asm-arm/hardware/ipaq-asic3.h | 609 > + > 1 files changed, 609 insertions(+), 0 deletions(-) > > diff --git a/include/asm-arm/hardware/ipaq-asic3.h > b/include/asm-arm/hardware/ipaq-asic3.h > new file mode 100644 > index 000..789bb16 > --- /dev/null > +++ b/include/asm-arm/hardware/ipaq-asic3.h > @@ -0,0 +1,609 @@ > +/* > + * > + * Definitions for the HTC ASIC3 chip found in several handheld devices > + * > + * Copyright 2001 Compaq Computer Corporation. > + * > + * Use consistent with the GNU GPL is permitted, > + * provided that this copyright notice is > + * preserved in its entirety in all copies and derived works. > + * > + * COMPAQ COMPUTER CORPORATION MAKES NO WARRANTIES, EXPRESSED OR IMPLIED, > + * AS TO THE USEFULNESS OR CORRECTNESS OF THIS CODE OR ITS > + * FITNESS FOR ANY PARTICULAR PURPOSE. > + * > + * Author: Andrew Christian > + * > + */ > + > +#ifndef IPAQ_ASIC3_H > +#define IPAQ_ASIC3_H > + > +// > +/* IPAQ, ASIC #3, replaces ASIC #1 */ > + > +#define IPAQ_ASIC3(_b,s,x,y) \ > + (*((volatile s *) (_b + _IPAQ_ASIC3_ ## x ## _Base + (_IPAQ_ASIC3_ ## x > ## _ ## y > +#define IPAQ_ASIC3_N(_b,s,x,y,z) \ > + (*((volatile s *) (_b + _IPAQ_ASIC3_ ## x ## _ ## y ## _Base + > (_IPAQ_ASIC3_ ## x ## _ ## z > + > +#define IPAQ_ASIC3_GPIO(_b,s,x,y)\ > + (*((volatile s *) (_b + _IPAQ_ASIC3_GPIO_ ## x ## _Base + > (_IPAQ_ASIC3_GPIO_ ## y > + > +#define IPAQ_ASIC3_OFFSET(x,y) (_IPAQ_ASIC3_ ## x ## _Base + _IPAQ_ASIC3_ ## > x ## _ ## y) > +#define IPAQ_ASIC3_GPIO_OFFSET(x,y) (_IPAQ_ASIC3_GPIO_ ## x ## _Base + > _IPAQ_ASIC3_GPIO_ ## y) Oh my eyes. What are these doing? The volatiles are a worry - volatile is said to be basically-always-wrong in-kernel, although we've never managed to document why, and i386 cheerfully uses it in readb() and friends. Perhaps if you can describe presisely what's going on here, alternatives might be suggested. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC, PATCH 1/4] SoC base drivers: SoC helper API
On Tue, 1 May 2007 08:08:27 +0300 Paul Sokolovsky <[EMAIL PROTECTED]> wrote:
> diff --git a/drivers/soc/soc-core.c b/drivers/soc/soc-core.c
> new file mode 100644
> index 000..24c654c
> --- /dev/null
> +++ b/drivers/soc/soc-core.c
> @@ -0,0 +1,106 @@
> +/*
> + * drivers/soc/soc-core.c
> + *
> + * core SoC support
> + * Copyright (c) 2006 Ian Molton
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This file contains functionality used by many SoC type devices.
> + *
> + * Created: 2006-11-28
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include "soc-core.h"
> +
> +void soc_free_devices(struct platform_device *devices, int nr_devs)
> +{
> + struct platform_device *dev = devices;
> + int i;
> +
> + for (i = 0; i < nr_devs; i++) {
> + struct resource *res = dev->resource;
> + platform_device_unregister(dev++);
> + kfree(res);
> + }
> + kfree(devices);
> +}
> +EXPORT_SYMBOL_GPL(soc_free_devices);
> +
> +#define SIGNED_SHIFT(val, shift) ((shift) >= 0 ? ((val) << (shift)) : ((val)
> >> -(shift)))
This will do bad things with
SIGNED_SHIFT(val, distance++);
So either
a) take a copy of the args inside the macro or, better
b) use a static inline.
It's probably worth putting the result into include/linux/kernel.h as well.
It's quite generic. If so, that's a standalone patch, please. Or keep it
here if you can't be bothered with that.
> +struct platform_device *soc_add_devices(struct platform_device *dev,
> + struct soc_device_data *soc, int
> nr_devs,
> + struct resource *mem,
> + int relative_addr_shift, int irq_base)
> +{
> + struct platform_device *devices;
> + int i, r, base;
> +
> + devices = kzalloc(nr_devs * sizeof(struct platform_device), GFP_KERNEL);
> + if (!devices)
> + return NULL;
> +
> + for (i = 0; i < nr_devs; i++) {
> + struct platform_device *sdev = &devices[i];
> + struct soc_device_data *blk = &soc[i];
> + struct resource *res;
> +
> + sdev->id = -1;
> + sdev->name = blk->name;
> +
> + sdev->dev.parent = &dev->dev;
> + sdev->dev.platform_data = (void *)blk->hwconfig;
> + sdev->num_resources = blk->num_resources;
> +
> + /* Allocate space for the subdevice resources */
> + res = kzalloc (blk->num_resources * sizeof (struct resource),
> GFP_KERNEL);
> + if (!res)
> + goto fail;
> +
> + for (r = 0 ; r < blk->num_resources ; r++) {
> + res[r].name = blk->res[r].name; // Fixme - should copy
fix me then ;)
With kstrdup(), presumably.
> +
> + /* Find out base to use */
> + base = 0;
> + if (blk->res[r].flags & IORESOURCE_MEM) {
> + base = mem->start;
mem->start is of type resource_size_t, and `base' should be of that type as
well.
> + } else if ((blk->res[r].flags & IORESOURCE_IRQ) &&
> + (blk->res[r].flags &
> IORESOURCE_IRQ_SOC_SUBDEVICE)) {
> + base = irq_base;
> + }
> +
> + /* Adjust resource */
> + if (blk->res[r].flags & IORESOURCE_MEM) {
> + res[r].parent = mem;
> + res[r].start = base +
> SIGNED_SHIFT(blk->res[r].start, relative_addr_shift);
> + res[r].end = base +
> SIGNED_SHIFT(blk->res[r].end, relative_addr_shift);
Which means that SIGNED_SHIFT really has to be a macro, as it needs to
handle resource_size_t's and you don't know what type they have.
Also, things get interesting when working out how to handle right-shift of
a negative quantity of unknown type.
> + } else {
> + res[r].start = base + blk->res[r].start;
> + res[r].end = base + blk->res[r].end;
> + }
> + res[r].flags = blk->res[r].flags;
> + }
> +
> + sdev->resource = res;
> + if (platform_device_register(sdev)) {
> + kfree(res);
> + goto fail;
> + }
> +
> + printk(KERN_INFO "SoC: registering %s\n", blk->name);
> + }
> + return devices;
> +
> +fail:
> + soc_free_devices(devices, i + 1);
> + return NULL;
> +}
> +EXPORT_SYMBOL_GPL(soc_add_devices);
> diff --git a/drivers/soc/soc-core.h b/drivers/soc/soc-core.h
> new file mode 100644
> index 000..8659f7e
> --- /dev/null
> +++ b/drivers/soc/soc-core.h
Re: VMware, x86_64 and 2.6.21.
I'm having the same problem. I think it has to do with timer problems... Does /sbin/hwclock --show freeze your box? It "sometimes" works on mine, but it more often than not locks it hard (especially as user, not root) with no hints in syslog or anywhere else as to what happened. This is a turion x2 with nvidia mcp51 On 5/1/07, Nigel Cunningham <[EMAIL PROTECTED]> wrote: Hi. Does anyone have VMware working on x86_64 with 2.6.21? It's working fine for me with 2.6.20, but freezes the whole computer with 2.6.21. Before I - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header.
On Mon, Apr 30, 2007 at 11:54:22PM -0600, Eric W. Biederman wrote: > Andi Kleen <[EMAIL PROTECTED]> writes: > > > On Mon, Apr 30, 2007 at 11:26:50PM -0600, Eric W. Biederman wrote: > >> Vivek Goyal <[EMAIL PROTECTED]> writes: > >> > >> > >> >> At least without a core file it is working on with gdb 6.4. > >> >> > >> > > >> > This seems to be a problem with gdb 6.5. I transferred the dump to a > >> > different machine having GNU gdb 6.4, and it works fine there. > >> > >> Ok. The difference between those two symbols didn't seem to make > >> any sense, so a gdb bug makes sense. > >> > >> Cool. Then the patch is good. :) > > > > It would still make any gdb 6.5 users unhappy. If no workaround can be found > > I guess we'll need a CONFIG of some sort? > > It is probably worth reproducing this bug with a PIE executable. > But it looks very much like gdb got it wrong, or else there is some > slight mismatch between our core dump and gdb. > > Given that gdb 6.5 handles the vmlinux fine when it isn't in conjunction > with a core dump I would not say the problem is in vmlinux. > > Rather there seems to be something messed up when gdb 6.5 tries to match > up the kernel core dump with the kernel. The offset for the symbol > Vivek gave was 0x7fff70e9. ??? Although that is almost 2M... > > Vivek could we see the program headers of your core file? > Hi Eric, Following are program headers of my core file. They look sane. Program Headers: Type Offset VirtAddr PhysAddr FileSizMemSiz Flags Align NOTE 0x0190 0x 0x 0x0b20 0x0b20 0 LOAD 0x0cb0 0x8020 0x0020 0x00742000 0x00742000 RWE0 LOAD 0x00742cb0 0x8100 0x 0x000a 0x000a RWE0 LOAD 0x007e2cb0 0x8110 0x0010 0x00f0 0x00f0 RWE0 LOAD 0x016e2cb0 0x81000900 0x0900 0xc6f8dc80 0xc6f8dc80 RWE0 LOAD 0xc8670930 0x8101 0x0001 0x00013000 0x00013000 RWE0 First PT_LOAD header is mapping kernel text/data and others just mapping physical memory in kernel linear virtual address range. > >From what I can tell what is left to figure out is do we have > a bug in gdb 6.5 or do we have a bug in our core file generation. > Given the fact it works well with gdb 6.4 as well as 6.1 (crash uses gdb 6.1 as backend and crash is working fine). I would think that it is gdb bug. > Right now I'm inclined to believe that the fedora core 6? gdb 6.5 got it > wrong. I'm probably just burnt out with binutils problems whenever > I try and do something interesting. But I'm just not inclined that > the bleeding edge tools are working properly while there kernel > core dump mechanism would mess up with a two byte field change. > > It does make sense to root cause this if we can. If it's a gdb > problem it should also apply to PIE executables, and should irritate > a few users. > > Regardless last I heard it was crash that was the primary analysis > tool and not gdb anyway. With gdb serving as the double check to make > certain that the kernel core dump was in a reasonably standard format. I would consider gdb to be equally important, especially because many a times crash is broken with latest version of kernels (as some data structures or some mechanism has changed) and gdb is the only one who can open the dump. Thanks Vivek - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
On 30/04/07 22:17, Markus Rechberger wrote: Trent Piepho wrote another patch for it, it just completes Uwe's patch in the end. From my side I do not see any problem with that patch, if someone else has a problem with it please state out the reason. I have no problem with the patch since it has nothing to do with my DVB card but you're only encouraging Uwe to be abusive since it seems to help get him what he wants: On 01/05/07 00:05, Uwe Bugla wrote: Piepho, you are a devil, and your links do not work at all! Uwe On 01/05/07 00:40, Uwe Bugla wrote: Go to hell, Manuel Abraham, and do not return at all to absolutely no thinkable condition at all, and never come back to this place once more again Just goto hell, you goddamn deeply asocial miserable sonofabitch!! Uwe On 4/30/07, Markus Rechberger <[EMAIL PROTECTED]> wrote: it's enough, I told him that I'll look at it and try to get some other people involved if it really breaks something it should get stated out; and I'll refuse any further help if he starts to write any more abusive mail. It's not working. Patches should still be applied on the basis of what they do and how, not why they were made, of course. -- Simon Arlott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VMware, x86_64 and 2.6.21.
Hi. On Tue, 2007-05-01 at 14:13 +0800, Jeff Chua wrote: > On 5/1/07, Nigel Cunningham <[EMAIL PROTECTED]> wrote: > > Hi. > > > > Does anyone have VMware working on x86_64 with 2.6.21? It's working fine > > for me with 2.6.20, but freezes the whole computer with 2.6.21. Before I > > > I'm on i386 and noticed it makes the "guest" very unresponsive. > > Uncheck "disable write-caching" solves the problem. Thanks for the reply. x86_64 seems to have a completely different issue. I think something in the changes that went in for x86 might have broken x86_64 completely. Guess I'll have to try a bisect. Regards, Nigel signature.asc Description: This is a digitally signed message part
Re: [PATCH] md: Remove broken SIGKILL support
Neil Brown <[EMAIL PROTECTED]> writes:
> On Thursday April 19, [EMAIL PROTECTED] wrote:
>> From: Eric W. Biederman <[EMAIL PROTECTED]>
>>
>> Currently md_thread calls allow_signal so it can receive a
>> SIGKILL but then does nothing with it except flush the
>> sigkill so that it not can use an interruptible sleep.
>>
>> This whole dance is silly so remove the unnecessary
>> and broken signal handling logic.
>
> (sorry of the delay in replying)
>
> You missed some related code which should help you see that it is -
> maybe - not completely 'silly' (though I confess it might be slightly
> broken).
> In md_check_recovery:
>
> if (signal_pending(current)) {
> if (mddev->pers->sync_request) {
> printk(KERN_INFO "md: %s in immediate safe mode\n",
> mdname(mddev));
> mddev->safemode = 2;
> }
> flush_signals(current);
> }
Thanks.
> The idea is that alt-sysrq-K will send SIGKILL to all processes
> including the md support threads, which will cause them to enter
> "immediate safe mode" so that the metadata will be marked clean
> immediately at every opportunity. That way you can use alt-sysrq:
> sync,unmount,kill,reboot
> and be fairly sure that you md array will be shut down cleanly.
>
> I'd be just as happy to link this into Unmount (aka
> do_emergency_remount), but that doesn't seem at all straight forward,
> and in any case should be done before the current code is ripped out.
>
> While we do have a reboot_notifier which tries to stop all arrays,
> I've never been comfortable with that. A reboot really should just
> reboot...
>
> What I would REALLY like is for the block device to know whether it is
> open read-only or read-write. Then I could mark it clean when it
> becomes read-only as would happen when do_emergency_remount remounts
> it read-only.
>
> I might see how hard that would be...
My goal to get signals to kernel threads out of the user space interface
especially for non-privileged processes, so everything that we do with
kernel threads can just be an unimportant implementation detail to user
space.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: VMware, x86_64 and 2.6.21.
On 5/1/07, Nigel Cunningham <[EMAIL PROTECTED]> wrote: Hi. Does anyone have VMware working on x86_64 with 2.6.21? It's working fine for me with 2.6.20, but freezes the whole computer with 2.6.21. Before I I'm on i386 and noticed it makes the "guest" very unresponsive. Uncheck "disable write-caching" solves the problem. Jeff. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage
Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes: > Eric W. Biederman wrote: >> I'm not going to worry about going farther until the patches in flight >> settle down a little bit, but this looks promising. >> > > Is there any value in adding an "early-putchar" function pointer into > the structure somehow? I could easily arrange for the domain builder to > put a bit of code into the domain so that the early boot code can emit > something. I don't think so. Once we know what subarch it is we can do a specific hypervisor call if we need to for early printing. There are weird issues like physical vs virtual that would seem to make anything more generic very difficult to get right, because the code pointed at would need to be fully pic. So as a trivial hypervisor call certainly, but I'm pretty doubtful about a function pointer. Then we can do: if (xen) blah else if (lguest) blah2 Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage
"H. Peter Anvin" <[EMAIL PROTECTED]> writes: > Rusty Russell wrote: >> >> BTW, wrt. a new "platform type" field, should it go something like this? >> >> -0235/3 N/A pad2Unused >> +0235/1 2.07+ platform_type Runtime platform (see below) >> +0236/2 N/A pad2Unused >> ... >> + platform_type: >> +For kernels which can boot on multiple platforms. Currently >> +0 == native (normal), 1 == lguest (paravirtualized). >> > > Well, yes, but we need to think about if there is more things that > should be added. There *definitely* should be space for a platform data > pointer, to start out with. I would also like to see a platform data > field, as well as a bootloader extension field (we're going to have that > problem soon enough.) Well in the paravirt case since we are starting virtually mapped if we don't start with vmlinux but bzImage we need to define what that virtual address space should contain, and where in the address space it is safe to put those page tables. Of the requirements I have heard so far that is the trickiest one. Because it basically requires us to have a reasonable worst case estimate of how much memory we are going to use before we start using the bootmem allocator. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [8/30] x86_64: Add vDSO for x86-64 with gettimeofday/clock_gettime/getcpu
Andi Kleen wrote:
> This implements new vDSO for x86-64. The concept is similar
> to the existing vDSOs on i386 and PPC. x86-64 has had static
> vsyscalls before, but these are not flexible enough anymore.
>
> A vDSO is a ELF shared library supplied by the kernel that is mapped into
> user address space. The vDSO mapping is randomized for each process
> for security reasons.
>
> Doing this was needed for clock_gettime, because clock_gettime
> always needs a syscall fallback and having one at a fixed
> address would have made buffer overflow exploits too easy to write.
>
> The vdso can be disabled with vdso=0
>
> It currently includes a new gettimeofday implemention and optimized
> clock_gettime(). The gettimeofday implementation is slightly faster
> than the one in the old vsyscall. clock_gettime is significantly faster
> than the syscall for CLOCK_MONOTONIC and CLOCK_REALTIME.
>
> The new calls are generally faster than the old vsyscall.
>
> TBD: add new benchmarks
>
> Advantages over the old x86-64 vsyscalls:
> - Extensible
> - Randomized
> - Cleaner
> - Easier to virtualize (the old static address range previously causes
> overhead e.g. for Xen because it has to create special page tables for it)
>
> Weak points:
> - glibc support still to be written
>
> The VM interface is partly based on Ingo Molnar's i386 version.
>
> Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
>
> ---
> Documentation/kernel-parameters.txt |2
> arch/x86_64/Makefile|3
> arch/x86_64/ia32/ia32_binfmt.c |1
> arch/x86_64/kernel/time.c |1
> arch/x86_64/kernel/vmlinux.lds.S| 12 +++
> arch/x86_64/kernel/vsyscall.c | 22 +
> arch/x86_64/mm/init.c | 17
> arch/x86_64/vdso/Makefile | 49
> arch/x86_64/vdso/vclock_gettime.c | 120 +++
> arch/x86_64/vdso/vdso-note.S| 25 ++
> arch/x86_64/vdso/vdso-start.S |2
> arch/x86_64/vdso/vdso.S |2
> arch/x86_64/vdso/vdso.lds.S | 77
> arch/x86_64/vdso/vextern.h | 16
> arch/x86_64/vdso/vgetcpu.c | 50 +
> arch/x86_64/vdso/vma.c | 137
>
> arch/x86_64/vdso/voffset.h |1
> arch/x86_64/vdso/vvar.c | 12 +++
> include/asm-x86_64/auxvec.h |2
> include/asm-x86_64/elf.h| 13 +++
> include/asm-x86_64/mmu.h|1
> include/asm-x86_64/pgtable.h|8 +-
> include/asm-x86_64/vgtod.h | 29 +++
> include/asm-x86_64/vsyscall.h |3
> 24 files changed, 583 insertions(+), 22 deletions(-)
>
> Index: linux/arch/x86_64/ia32/ia32_binfmt.c
> ===
> --- linux.orig/arch/x86_64/ia32/ia32_binfmt.c
> +++ linux/arch/x86_64/ia32/ia32_binfmt.c
> @@ -38,6 +38,7 @@
>
> int sysctl_vsyscall32 = 1;
>
> +#undef ARCH_DLINFO
> #define ARCH_DLINFO do { \
> if (sysctl_vsyscall32) { \
> NEW_AUX_ENT(AT_SYSINFO, (u32)(u64)VSYSCALL32_VSYSCALL); \
> Index: linux/arch/x86_64/kernel/vmlinux.lds.S
> ===
> --- linux.orig/arch/x86_64/kernel/vmlinux.lds.S
> +++ linux/arch/x86_64/kernel/vmlinux.lds.S
> @@ -94,6 +94,9 @@ SECTIONS
>.vsyscall_gtod_data : AT(VLOAD(.vsyscall_gtod_data))
> { *(.vsyscall_gtod_data) }
>vsyscall_gtod_data = VVIRT(.vsyscall_gtod_data);
> + .vsyscall_clock : AT(VLOAD(.vsyscall_clock))
> + { *(.vsyscall_clock) }
> + vsyscall_clock = VVIRT(.vsyscall_clock);
>
>
>.vsyscall_1 ADDR(.vsyscall_0) + 1024: AT(VLOAD(.vsyscall_1))
> @@ -153,6 +156,8 @@ SECTIONS
>
>. = ALIGN(4096); /* Init code and data */
>__init_begin = .;
> +
> +
>.init.text : AT(ADDR(.init.text) - LOAD_OFFSET) {
> _sinittext = .;
> *(.init.text)
> @@ -190,6 +195,12 @@ SECTIONS
>.exit.text : AT(ADDR(.exit.text) - LOAD_OFFSET) { *(.exit.text) }
>.exit.data : AT(ADDR(.exit.data) - LOAD_OFFSET) { *(.exit.data) }
>
> +/* vdso blob that is mapped into user space */
> + vdso_start = . ;
> + .vdso : AT(ADDR(.vdso) - LOAD_OFFSET) { *(.vdso) }
> + . = ALIGN(4096);
> + vdso_end = .;
> +
> #ifdef CONFIG_BLK_DEV_INITRD
>. = ALIGN(4096);
>__initramfs_start = .;
> @@ -202,6 +213,7 @@ SECTIONS
>.data.percpu : AT(ADDR(.data.percpu) - LOAD_OFFSET) { *(.data.percpu) }
>__per_cpu_end = .;
>. = ALIGN(4096);
> +
>__init_end = .;
>
>. = ALIGN(4096);
> Index: linux/arch/x86_64/mm/init.c
> ===
> --- linux.orig/arch/x86_64/mm/init.c
> +++ linux/arch/x86_64/mm/init.c
> @@ -159,6 +159,14 @@ static __init void set_pte_phys(unsigned
> __flush_tlb_one(vaddr);
> }
>
> +void __init
> +set_kernel_map(void *vaddr,unsigned long len,unsigned long
Re: 2.6.21 frozen for a few minutes, swapping to disk
Andrew Morton wrote: On Tue, 01 May 2007 15:42:30 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote: hm, a genuine oom on an all-ext3 data=ordered i386 system, just like a million other people. How very weird. I assume all those pages on the LRU are pagecache pages which for some reason we're unable to reclaim. It looks like it used up all swap? I'd guess a memory leak in some application, or maybe a page refcount leak somewhere. yes, I missed that. The number of mapped pages is tiny so the thing has been trying to swap out like. I didn't quite parse this :) If the memory is leaking slowly, it could be eventually pushing everything out to swap without having a large amount of mapped pages. Or if something is slowly writing stuff to tmpfs, that may not show up in mapped pages either. The question is: how much memory is free after the oom-killing storm? If it's "lots" then it's probably an application problem. If it's "not much" then perhaps there's a kernel leak. Yeah, or a tmpfs filesystem being filled up (what does `df` say?). -- SUSE Labs, Novell Inc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header.
Andi Kleen <[EMAIL PROTECTED]> writes: > On Mon, Apr 30, 2007 at 11:26:50PM -0600, Eric W. Biederman wrote: >> Vivek Goyal <[EMAIL PROTECTED]> writes: >> >> >> >> At least without a core file it is working on with gdb 6.4. >> >> >> > >> > This seems to be a problem with gdb 6.5. I transferred the dump to a >> > different machine having GNU gdb 6.4, and it works fine there. >> >> Ok. The difference between those two symbols didn't seem to make >> any sense, so a gdb bug makes sense. >> >> Cool. Then the patch is good. :) > > It would still make any gdb 6.5 users unhappy. If no workaround can be found > I guess we'll need a CONFIG of some sort? It is probably worth reproducing this bug with a PIE executable. But it looks very much like gdb got it wrong, or else there is some slight mismatch between our core dump and gdb. Given that gdb 6.5 handles the vmlinux fine when it isn't in conjunction with a core dump I would not say the problem is in vmlinux. Rather there seems to be something messed up when gdb 6.5 tries to match up the kernel core dump with the kernel. The offset for the symbol Vivek gave was 0x7fff70e9. ??? Although that is almost 2M... Vivek could we see the program headers of your core file? >From what I can tell what is left to figure out is do we have a bug in gdb 6.5 or do we have a bug in our core file generation. Right now I'm inclined to believe that the fedora core 6? gdb 6.5 got it wrong. I'm probably just burnt out with binutils problems whenever I try and do something interesting. But I'm just not inclined that the bleeding edge tools are working properly while there kernel core dump mechanism would mess up with a two byte field change. It does make sense to root cause this if we can. If it's a gdb problem it should also apply to PIE executables, and should irritate a few users. Regardless last I heard it was crash that was the primary analysis tool and not gdb anyway. With gdb serving as the double check to make certain that the kernel core dump was in a reasonably standard format. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86_64: support poll() on /dev/mcelog (try #2)
From: Tim Hockin <[EMAIL PROTECTED]>
Background:
/dev/mcelog is typically polled manually. This is less than optimal for
situations where accurate accounting of MCEs is important. Calling
poll() on /dev/mcelog does not work.
Description:
This patch adds support for poll() to /dev/mcelog. This results in
immediate wakeup of user apps whenever the poller finds MCEs. Because
the exception handler can not take any locks, it can not call the wakeup
itself. Instead, it uses a thread_info flag (TIF_MCE_NOTIFY) which is
caught at the next return from interrupt or exit from idle, calling the
mce_user_notify() routine.
This patch also does some small cleanup for essentially unused variables,
and moves the user notification into the body of the poller, so it is
only called once per poll, rather than once per CPU.
Result:
Applications can now poll() on /dev/mcelog. When an error is logged
(whether through the poller or through an exception) the applications are
woken up promptly. This should not affect any previous behaviors. If no
MCEs are being logged, there is no overhead.
Alternatives:
I considered simply supporting poll() through the poller and not using
TIF_MCE_NOTIFY at all. However, the time between an uncorrectable error
happening and the user application being notified is *the*most* critical
window for us. Many uncorrectable errors can be logged to the network if
given a chance.
I also considered doing the MCE poll directly from the idle notifier, but
decided that was overkill.
Testing:
I used an error-injecting DIMM to create lots of correctable DRAM errors
and verified that my user app is woken up in sync with the polling interval.
I also used the northbridge to inject uncorrectable ECC errors, and
verified (printk() to the rescue) that the notify routine is called and the
user app does wake up.
Caveats:
I have seen a soft lockup with a call trace always similar to:
Call Trace:
[] wake_up_process+0x10/0x20
[] softlockup_tick+0xea/0x110
[] run_local_timers+0x13/0x20
[] update_process_times+0x57/0x90
[] mcheck_check_cpu+0x0/0x40
[] smp_local_timer_interrupt+0x34/0x60
[] smp_apic_timer_interrupt+0x4e/0x70
[] apic_timer_interrupt+0x66/0x70
I regressed this to the vanilla kernel, and it still happens. It only
crops up in the face of multiple uncorrectable errors.
Patch:
This patch is against 2.6.21-rc7.
Signed-off-by: Tim Hockin <[EMAIL PROTECTED]>
---
This is the second version version of this patch. The TIF_* approach was
suggested by Mike Waychison and Andi did not yell at me when I suggested
it. Hooking the idle notifier was born of an Andrew Morton suggestion
and, no surprise, seems to work well.
diff -pruN linux-2.6.20+th/arch/x86_64/kernel/entry.S
linux-2.6.20+th2v3/arch/x86_64/kernel/entry.S
--- linux-2.6.20+th/arch/x86_64/kernel/entry.S 2007-04-24 22:46:19.0
-0700
+++ linux-2.6.20+th2v3/arch/x86_64/kernel/entry.S 2007-04-30
10:57:43.0 -0700
@@ -282,7 +282,7 @@ sysret_careful:
sysret_signal:
TRACE_IRQS_ON
sti
- testl $(_TIF_SIGPENDING|_TIF_NOTIFY_RESUME|_TIF_SINGLESTEP),%edx
+ testl
$(_TIF_SIGPENDING|_TIF_NOTIFY_RESUME|_TIF_SINGLESTEP|_TIF_MCE_NOTIFY),%edx
jz1f
/* Really a signal */
@@ -375,7 +375,7 @@ int_very_careful:
jmp int_restore_rest
int_signal:
- testl $(_TIF_NOTIFY_RESUME|_TIF_SIGPENDING|_TIF_SINGLESTEP),%edx
+ testl
$(_TIF_NOTIFY_RESUME|_TIF_SIGPENDING|_TIF_SINGLESTEP|_TIF_MCE_NOTIFY),%edx
jz 1f
movq %rsp,%rdi # &ptregs -> arg1
xorl %esi,%esi # oldset -> arg2
@@ -597,9 +597,9 @@ retint_careful:
cli
TRACE_IRQS_OFF
jmp retint_check
-
+
retint_signal:
- testl $(_TIF_SIGPENDING|_TIF_NOTIFY_RESUME|_TIF_SINGLESTEP),%edx
+ testl
$(_TIF_SIGPENDING|_TIF_NOTIFY_RESUME|_TIF_SINGLESTEP|_TIF_MCE_NOTIFY),%edx
jzretint_swapgs
TRACE_IRQS_ON
sti
diff -pruN linux-2.6.20+th/arch/x86_64/kernel/mce.c
linux-2.6.20+th2v3/arch/x86_64/kernel/mce.c
--- linux-2.6.20+th/arch/x86_64/kernel/mce.c2007-04-27 14:19:08.0
-0700
+++ linux-2.6.20+th2v3/arch/x86_64/kernel/mce.c 2007-04-30 22:19:25.0
-0700
@@ -20,12 +20,15 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
#include
#include
#include
+#include
#define MISC_MCELOG_MINOR 227
#define NR_BANKS 6
@@ -39,8 +42,7 @@ static int mce_dont_init;
static int tolerant = 1;
static int banks;
static unsigned long bank[NR_BANKS] = { [0 ... NR_BANKS-1] = ~0UL };
-static unsigned long console_logged;
-static int notify_user;
+static unsigned long notify_user;
static int rip_msr;
static int mce_bootlog = 1;
static atomic_t mce_events;
@@ -48,6 +50,8 @@ static atomic_t mce_events;
static char trigge
Re: 2.6.21 frozen for a few minutes, swapping to disk
On Tue, 01 May 2007 15:42:30 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote: > > hm, a genuine oom on an all-ext3 data=ordered i386 system, just like a > > million other people. How very weird. > > > > I assume all those pages on the LRU are pagecache pages which for some > > reason we're unable to reclaim. > > It looks like it used up all swap? I'd guess a memory leak in some > application, or maybe a page refcount leak somewhere. yes, I missed that. The number of mapped pages is tiny so the thing has been trying to swap out like. The question is: how much memory is free after the oom-killing storm? If it's "lots" then it's probably an application problem. If it's "not much" then perhaps there's a kernel leak. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
VMware, x86_64 and 2.6.21.
Hi. Does anyone have VMware working on x86_64 with 2.6.21? It's working fine for me with 2.6.20, but freezes the whole computer with 2.6.21. Before I start a git-bisect, I thought I might ask if anyone knew of some compilation option I might have missed. Regards, Nigel signature.asc Description: This is a digitally signed message part
Re: 2.6.21 frozen for a few minutes, swapping to disk
Andrew Morton wrote:
On Sun, 29 Apr 2007 11:28:05 +0100 Miguel Figueiredo <[EMAIL PROTECTED]> wrote:
Hi all,
today, with 2.6.21, my laptop had a really odd behaviour. It started
writing to disk for a few minutes with no interactivity at all (no
redraw on screen, only hdd led on). It's the first time i noticed
OOM-killer started do kill programs.
It was totally unresponsive for minutes, after back to life it had a
load of ~19.0, and 300+ MB on swap (first time i saw this).
It's an HP pavillon core duo 2.0 GHz, 1 GB RAM
kern.log details:
http://www.debianpt.org/~elmig/pool/kernel/20070429/kern.log
.config: http://www.debianpt.org/~elmig/pool/kernel/20070429/2.6.21.config
dmesg: http://www.debianpt.org/~elmig/pool/kernel/20070429/dmesg
As this is the first time it happened and it felt odd i am reporting.
If aditional info is needed please CC me as i am not on the list.
hm, a genuine oom on an all-ext3 data=ordered i386 system, just like a
million other people. How very weird.
I assume all those pages on the LRU are pagecache pages which for some
reason we're unable to reclaim.
It looks like it used up all swap? I'd guess a memory leak in some
application, or maybe a page refcount leak somewhere.
If some privileged application went berzerk mlock()ing everything then that
might explain it. It sounds improbable, but then, something improbable has
happened.
We cleverly managed to not display the pagecache totals in the oom-killer
output. Could you please take a copy of /proc/meminfo after an
oom-killing, send that? And /proc/vmstat, I guess.
If you're keen, we could eliminate the mlock possibility by adding this:
--- a/mm/mlock.c~a
+++ a/mm/mlock.c
@@ -127,6 +127,8 @@ asmlinkage long sys_mlock(unsigned long
unsigned long lock_limit;
int error = -ENOMEM;
+ return 0;
+
if (!can_do_mlock())
return -EPERM;
@@ -151,6 +153,8 @@ asmlinkage long sys_munlock(unsigned lon
{
int ret;
+ return 0;
+
down_write(¤t->mm->mmap_sem);
len = PAGE_ALIGN(len + (start & ~PAGE_MASK));
start &= PAGE_MASK;
_
--
SUSE Labs, Novell Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc7-mm2 hangs in boot (netconsole)
On Tue, 1 May 2007 08:24:56 +0200 Andi Kleen <[EMAIL PROTECTED]> wrote:
> > The bug is in firstfloor only, and the fix (if present) will be there too.
> >
> >
> >
> > Nope,
> >
> > ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt/patches/sched-clock-share
> >
> > is identical to
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc7/2.6.21-rc7-mm2/broken-out/x86_64-mm-sched-clock-share.patch
>
> Or perhaps the deadlock is in the cpufrequency handler. Does it happen
> without CONFIG_CPUFREQ
> too?
>
> [cpufreq handler calls ktime_get which might take xtime lock for reading]
>
Sounds right. That's what was happening to me for a while.
Randy, it'd be interesting to try:
--- a/arch/x86_64/kernel/tsc.c~a
+++ a/arch/x86_64/kernel/tsc.c
@@ -84,8 +84,8 @@ static int time_cpufreq_notifier(struct
cpufreq_scale(loops_per_jiffy_ref, ref_freq, freq->new);
tsc_khz = cpufreq_scale(tsc_khz_ref, ref_freq, freq->new);
- if (!(freq->flags & CPUFREQ_CONST_LOOPS))
- mark_tsc_unstable("cpufreq changes");
+// if (!(freq->flags & CPUFREQ_CONST_LOOPS))
+// mark_tsc_unstable("cpufreq changes");
}
return 0;
_
and if that "fixes" it, disable netconsole and do
--- a/arch/x86_64/kernel/tsc.c~a
+++ a/arch/x86_64/kernel/tsc.c
@@ -85,7 +85,7 @@ static int time_cpufreq_notifier(struct
tsc_khz = cpufreq_scale(tsc_khz_ref, ref_freq, freq->new);
if (!(freq->flags & CPUFREQ_CONST_LOOPS))
- mark_tsc_unstable("cpufreq changes");
+ dump_stack();
}
return 0;
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage
Eric W. Biederman wrote: > I'm not going to worry about going farther until the patches in flight > settle down a little bit, but this looks promising. > Is there any value in adding an "early-putchar" function pointer into the structure somehow? I could easily arrange for the domain builder to put a bit of code into the domain so that the early boot code can emit something. J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [30/30] x86_64: Add missing !X86_PAE dependincy to the 2G/2G split.
William Lee Irwin III <[EMAIL PROTECTED]> writes: > On Tue, May 01, 2007 at 05:58:29AM +0200, Andi Kleen wrote: >> From: [EMAIL PROTECTED] >> When in PAE mode we require that the user kernel divide to be >> on a 1G boundary. The 2G/2G split does not have that property >> so require !X86_PAE >> Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]> >> --- >> arch/i386/Kconfig |1 + >> 1 files changed, 1 insertions(+), 0 deletions(-) > > What on earth? > > config PAGE_OFFSET > hex > default 0xB000 if VMSPLIT_3G_OPT > default 0x7800 if VMSPLIT_2G > default 0x4000 if VMSPLIT_1G > default 0xC000 > > This appears to have been introduced by: > commit 975b3d3d5b983eb60706d35f0d24cd19f6badabf > Author: Mark Lord <[EMAIL PROTECTED]> > Date: Wed Feb 1 03:06:11 2006 -0800 > [PATCH] VMSPLIT config options > > There's some sort of insanity going on here. Since when is 0x7800 > a 2GB/2GB split? Mark, dare I ask what you were thinking? That should > be VMSPLIT_2G_OPT for 2GB laptops analogously to VMSPLIT_3G_OPT, if > nothing else, as it's certainly not 2GB/2GB. It makes a little more sense when you realize all of the options were originally !X86_PAE. So they were designed with highmem disabled. > These VMSPLIT config options vs. PAE are foul as they're now done in > any event. If they were done properly, they'd properly set up the pmd > within which the division point between user and kernelspace falls. They were designed to avoid highmem a totally different design point. > This patch, I suppose, stops people from shooting themselves in the > foot, but (IMHO) the VMSPLIT patches shouldn't have been merged > without handling the partial pmd case. 2MB/4MB resolution is enough > granularity for any reasonable purpose, so split ptes aren't worth the > effort, but this nonsense with PAE vs. VMSPLIT is just preposterous. > If you're going to play the VMSPLIT game at all, handle split pmd's. What I find telling is that I fixed this based on code review not based on bug reports. > I'll see what else is pending in the i386 pagetable arena and clear > this up if there aren't other objections (this is where Andi gets to > complain that things are too complex already and preemptively NAK to > save me the effort, if it's not seen to be desirable). Eric, your patch > is a reasonable stop-gap measure for the original deficiency. Frankly rather then putting much effort into this I suspect we should just delete these options entirely. We are long past the point where they matter. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage
Rusty Russell wrote: > > BTW, wrt. a new "platform type" field, should it go something like this? > > -0235/3 N/A pad2Unused > +0235/1 2.07+ platform_type Runtime platform (see below) > +0236/2 N/A pad2Unused > ... > + platform_type: > + For kernels which can boot on multiple platforms. Currently > + 0 == native (normal), 1 == lguest (paravirtualized). > Well, yes, but we need to think about if there is more things that should be added. There *definitely* should be space for a platform data pointer, to start out with. I would also like to see a platform data field, as well as a bootloader extension field (we're going to have that problem soon enough.) -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc7-mm2 hangs in boot (netconsole)
> The bug is in firstfloor only, and the fix (if present) will be there too. > > > > Nope, > > ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt/patches/sched-clock-share > > is identical to > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc7/2.6.21-rc7-mm2/broken-out/x86_64-mm-sched-clock-share.patch Or perhaps the deadlock is in the cpufrequency handler. Does it happen without CONFIG_CPUFREQ too? [cpufreq handler calls ktime_get which might take xtime lock for reading] -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header.
Vivek Goyal <[EMAIL PROTECTED]> writes: >> At least without a core file it is working on with gdb 6.4. >> > > This seems to be a problem with gdb 6.5. I transferred the dump to a > different machine having GNU gdb 6.4, and it works fine there. Ok. The difference between those two symbols didn't seem to make any sense, so a gdb bug makes sense. Cool. Then the patch is good. :) Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header.
On Mon, Apr 30, 2007 at 11:26:50PM -0600, Eric W. Biederman wrote: > Vivek Goyal <[EMAIL PROTECTED]> writes: > > > >> At least without a core file it is working on with gdb 6.4. > >> > > > > This seems to be a problem with gdb 6.5. I transferred the dump to a > > different machine having GNU gdb 6.4, and it works fine there. > > Ok. The difference between those two symbols didn't seem to make > any sense, so a gdb bug makes sense. > > Cool. Then the patch is good. :) It would still make any gdb 6.5 users unhappy. If no workaround can be found I guess we'll need a CONFIG of some sort? -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [30/30] x86_64: Add missing !X86_PAE dependincy to the 2G/2G split.
On Tue, May 01, 2007 at 06:26:23AM +0200, Eric Dumazet wrote: > Andi Kleen a ?crit : > >From: [EMAIL PROTECTED] > > > >When in PAE mode we require that the user kernel divide to be > >on a 1G boundary. The 2G/2G split does not have that property > >so require !X86_PAE > > > >Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]> > >--- > > arch/i386/Kconfig |1 + > > 1 files changed, 1 insertions(+), 0 deletions(-) > > > >diff --git a/arch/i386/Kconfig b/arch/i386/Kconfig > >index 1a94a73..80003de 100644 > >--- a/arch/i386/Kconfig > >+++ b/arch/i386/Kconfig > >@@ -570,6 +570,7 @@ choice > > depends on !HIGHMEM > > bool "3G/1G user/kernel split (for full 1G low memory)" > > config VMSPLIT_2G > >+depends on !X86_PAE > > bool "2G/2G user/kernel split" > > config VMSPLIT_1G > > bool "1G/3G user/kernel split" > > Hum... We lose a usefull 2G/2G split. Should'nt we use a patch to change > PAGE_OFFSET to 0x800 instead of 0x7800 and keep 2G/2G split ? I dropped the patch for now. > [PATCH] i386 : Adjust CONFIG_PAGE_OFFSET in case of 2G/2G split and X86_PAE > > When in PAE mode we require that the user kernel divide to be > on a 1G boundary. We must therefore make sure PAGE_OFFSET is correctlty > defined in the 2G/2G split and PAE mode. Looks reasonable. Did you test both cases? wli, ok for you too? -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc7-mm2 hangs in boot (netconsole)
On Mon, 30 Apr 2007 22:16:24 -0700 Randy Dunlap <[EMAIL PROTECTED]> wrote: > > > I was hitting the same thing on i386 uniprocessor, but I thought it got > > > fixed. > > > > Yes. > > Fixed where? Merged into mainline or in your firstfloor patches? The bug is in firstfloor only, and the fix (if present) will be there too. Nope, ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt/patches/sched-clock-share is identical to ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc7/2.6.21-rc7-mm2/broken-out/x86_64-mm-sched-clock-share.patch - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc7-mm2 hangs in boot (netconsole)
On Mon, Apr 30, 2007 at 10:16:24PM -0700, Randy Dunlap wrote: > On Tue, 1 May 2007 05:43:30 +0200 Andi Kleen wrote: > > > > Andi: unprocessor x86_64 running rc7-mm2 is hanging early in boot at > > > randomish times (presumably in the timer irq handler) when netconsole and > > > printk-time are enabled. > > > > A backtrace would be good. Does nmi_watchdog=2 show anything > > interesting or if not sysrq-t? > > I can't get anything from sysrq or nmi_watchdog. Hmm, ok when the console locks up those likely don't work. > > > > I was hitting the same thing on i386 uniprocessor, but I thought it got > > > fixed. > > > > Yes. > > Fixed where? Merged into mainline or in your firstfloor patches? None of the sched-clock changes are in mainline yet. Can you perhaps test latest firstfloor alone (without rest of -mm)? -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [30/30] x86_64: Add missing !X86_PAE dependincy to the 2G/2G split.
William Lee Irwin III a ?crit : >> There's some sort of insanity going on here. Since when is 0x7800 >> a 2GB/2GB split? Mark, dare I ask what you were thinking? That should >> be VMSPLIT_2G_OPT for 2GB laptops analogously to VMSPLIT_3G_OPT, if >> nothing else, as it's certainly not 2GB/2GB. On Tue, May 01, 2007 at 06:57:19AM +0200, Eric Dumazet wrote: > Please could you stop saying others are insane ? > They are like you and can fail sometime. Apparently when the patch came, > nobody (including you) commented. > It's not that difficult to think about VMALLOC space (I might be wrong > about this, but I feel this explains 7800 vs 8000) I'm obviously aware of vmallocspace. Read carefully: >> a 2GB/2GB split? Mark, dare I ask what you were thinking? That should >> be VMSPLIT_2G_OPT for 2GB laptops analogously to VMSPLIT_3G_OPT, if >> nothing else, as it's certainly not 2GB/2GB. The meaning of "for laptops" is that it's carving out a chunk of user virtualspace to use for vmallocspace in lieu of carving out a piece of the 1:1 mapping of physical memory for the same purpose. -- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc7-mm2 hangs in boot (netconsole)
On Tue, 1 May 2007 05:43:30 +0200 Andi Kleen wrote: > > Andi: unprocessor x86_64 running rc7-mm2 is hanging early in boot at > > randomish times (presumably in the timer irq handler) when netconsole and > > printk-time are enabled. > > A backtrace would be good. Does nmi_watchdog=2 show anything > interesting or if not sysrq-t? I can't get anything from sysrq or nmi_watchdog. > > I was hitting the same thing on i386 uniprocessor, but I thought it got > > fixed. > > Yes. Fixed where? Merged into mainline or in your firstfloor patches? > My current sched_clock does not take any locks anymore and it was removed > from the cpufreq handler too. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC, PATCH 3/4] SoC base drivers: ASIC3 driver
Hello linux-kernel,
Note: This driver depends on ds1wm.h header, recently submitted, and which by
now should be in -mm tree.
-
asic3_base: SoC base driver for ASIC3 chip.
Signed-off-by: Paul Sokolovsky <[EMAIL PROTECTED]>
drivers/soc/Kconfig| 22 +
drivers/soc/Makefile |5 +
drivers/soc/asic3_base.c | 1177
include/linux/soc/asic3_base.h | 100
include/linux/soc/tmio_mmc.h | 17 +
5 files changed, 1321 insertions(+), 0 deletions(-)
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
new file mode 100644
index 000..2c9d846
--- /dev/null
+++ b/drivers/soc/Kconfig
@@ -0,0 +1,22 @@
+#
+# SoC drivers
+#
+# System-on-Chip are chips that implement a number of virtually unrelated
+# functions but sharing some common circuitry, for example power management
+# or an auxiliary interrupt controller.
+#
+
+menu "SoC drivers"
+
+config SOC_ASIC3
+ tristate "HTC ASIC3 SoC support (iPAQ & HTC PDAs)"
+
+config SOC_ASIC3_DS1WM
+ bool "Support HTC ASIC3 builtin DS1WM block"
+ depends on SOC_ASIC3
+ help
+ Choose Y here if you want to include support for ASIC3's builtin
+ W1 controller. Some devices do not use it, and yet other have
+ separate DS1WM controller. For them, choose N.
+
+endmenu
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
new file mode 100644
index 000..13031b1
--- /dev/null
+++ b/drivers/soc/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for SoC drivers.
+#
+
+obj-$(CONFIG_SOC_ASIC3)+= asic3_base.o soc-core.o
diff --git a/drivers/soc/asic3_base.c b/drivers/soc/asic3_base.c
new file mode 100644
index 000..ca0f862
--- /dev/null
+++ b/drivers/soc/asic3_base.c
@@ -0,0 +1,1177 @@
+/*
+ * Driver interface to HTC "ASIC3"
+ *
+ * Copyright 2001 Compaq Computer Corporation.
+ * Copyright 2004-2005 Phil Blundell
+ *
+ * Use consistent with the GNU GPL is permitted,
+ * provided that this copyright notice is
+ * preserved in its entirety in all copies and derived works.
+ *
+ * COMPAQ COMPUTER CORPORATION MAKES NO WARRANTIES, EXPRESSED OR IMPLIED,
+ * AS TO THE USEFULNESS OR CORRECTNESS OF THIS CODE OR ITS
+ * FITNESS FOR ANY PARTICULAR PURPOSE.
+ *
+ * Author: Andrew Christian
+ * <[EMAIL PROTECTED]>
+ * October 2001
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#ifdef CONFIG_PLAT_S3C24XX
+#include
+#define clk_register(clk) s3c24xx_register_clock(clk)
+#define clk_unregister(clk)
+#else
+#include
+#endif
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include "soc-core.h"
+
+
+struct asic3_data
+{
+ void *mapping;
+ unsigned int bus_shift;
+ int irq_base;
+ int irq_nr;
+
+ u16 irq_bothedge[4];
+ struct device *dev;
+
+ struct platform_device *mmc_dev;
+};
+
+static spinlock_t asic3_gpio_lock;
+
+static int asic3_remove(struct platform_device *dev);
+
+static inline unsigned long asic3_address(struct device *dev,
+ unsigned int reg)
+{
+ struct asic3_data *adata;
+
+ adata = (struct asic3_data *)dev->driver_data;
+
+ return (unsigned long)adata->mapping + (reg >> (2 - adata->bus_shift));
+}
+
+void asic3_write_register(struct device *dev, unsigned int reg, u32 value)
+{
+ __raw_writew(value, asic3_address(dev, reg));
+}
+EXPORT_SYMBOL(asic3_write_register);
+
+u32 asic3_read_register(struct device *dev, unsigned int reg)
+{
+ return __raw_readw(asic3_address(dev, reg));
+}
+EXPORT_SYMBOL(asic3_read_register);
+
+static inline void __asic3_write_register(struct asic3_data *asic,
+ unsigned int reg, u32 value)
+{
+ __raw_writew(value, (unsigned long)asic->mapping
+ + (reg >> (2 - asic->bus_shift)));
+}
+
+static inline u32 __asic3_read_register(struct asic3_data *asic,
+ unsigned int reg)
+{
+ return __raw_readw((unsigned long)asic->mapping
+ + (reg >> (2 - asic->bus_shift)));
+}
+
+#define ASIC3_GPIO_FN(get_fn_name, set_fn_name, REG) \
+u32 get_fn_name(struct device *dev)\
+{ \
+ return asic3_read_register(dev, REG); \
+} \
+EXPORT_SYMBOL(get_fn_name);\
+ \
+void set_fn_name(struct device *dev, u32 bits, u32 val)
\
+{ \
+ unsigned long flags;\
+ \
+
[RFC, PATCH 4/4] SoC base drivers: ASIC3 support for iPaq rx3715
Hello linux-kernel,
mach-rx3715: Add support for builtin ASIC3 chip, based on the
asic3_base driver.
arch/arm/mach-s3c2440/mach-rx3715.c | 84 +++
include/asm-arm/arch-s3c2410/rx3000-asic3.h | 63
include/asm-arm/arch-s3c2410/rx3000.h | 19 ++
3 files changed, 166 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s3c2440/mach-rx3715.c
b/arch/arm/mach-s3c2440/mach-rx3715.c
index ae1d0a8..0c7285f 100644
--- a/arch/arm/mach-s3c2440/mach-rx3715.c
+++ b/arch/arm/mach-s3c2440/mach-rx3715.c
@@ -2,6 +2,7 @@
*
* Copyright (c) 2003,2004 Simtec Electronics
* Ben Dooks <[EMAIL PROTECTED]>
+ * Copyright 2006 Roman Moravcik <[EMAIL PROTECTED]>
*
* http://www.handhelds.org/projects/rx3715.html
*
@@ -50,6 +51,11 @@
#include
#include
+#include
+#include
+#include
+#include
+
static struct map_desc rx3715_iodesc[] __initdata = {
/* dump ISA space somewhere unused */
@@ -107,6 +113,84 @@ static struct s3c2410_uartcfg rx3715_uartcfgs[] = {
}
};
+/* ASIC3 SoC data */
+static struct asic3_platform_data rx3715_asic3_cfg = {
+ .gpio_a = {
+ .dir= 0x,
+ .init = 0x0028,
+ .sleep_mask = 0x,
+ .sleep_out = 0x0030,
+ .batt_fault_out = 0x0030,
+ .alt_function = 0x,
+ .sleep_conf = 0x0008,
+ },
+ .gpio_b = {
+ .dir= 0x,
+ .init = 0x1a02,
+ .sleep_mask = 0x,
+ .sleep_out = 0x0402,
+ .batt_fault_out = 0x0402,
+ .alt_function = 0x,
+ .sleep_conf = 0x0008,
+ },
+ .gpio_c = {
+ .dir= 0x,
+ .init = 0x0600,
+ .sleep_mask = 0x,
+ .sleep_out = 0x,
+ .batt_fault_out = 0x,
+ .alt_function = 0x0007,
+ .sleep_conf = 0x0008,
+ },
+ .gpio_d = {
+ .dir= 0xfff0,
+ .init = 0x0040,
+ .sleep_mask = 0xfff0,
+ .sleep_out = 0x,
+ .batt_fault_out = 0x,
+ .alt_function = 0x,
+ .sleep_conf = 0x0008,
+ },
+ .irq_base = RX3000_ASIC3_IRQ_BASE,
+
+ /*.child_platform_devs = child_devices,
+ .num_child_platform_devs = ARRAY_SIZE(child_devices),*/
+};
+
+static struct resource s3c_asic3_resources[] = {
+ [0] = {
+ .start = 0x0800,
+ .end= 0x0800 + IPAQ_ASIC3_MAP_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = IRQ_EINT12,
+ .end= IRQ_EINT12,
+ .flags = IORESOURCE_IRQ,
+ },
+ /* SD part */
+ [2] = {
+ .start = 0x1000,
+ .end= 0x1000 + IPAQ_ASIC3_MAP_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [3] = {
+ .start = IRQ_EINT14,
+ .end= IRQ_EINT14,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+struct platform_device s3c_device_asic3 = {
+ .name = "asic3",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(s3c_asic3_resources),
+ .resource = s3c_asic3_resources,
+ .dev = { .platform_data = &rx3715_asic3_cfg, }
+};
+
+EXPORT_SYMBOL(s3c_device_asic3);
+
/* framebuffer lcd controller information */
static struct s3c2410fb_mach_info rx3715_lcdcfg __initdata = {
diff --git a/include/asm-arm/arch-s3c2410/rx3000-asic3.h
b/include/asm-arm/arch-s3c2410/rx3000-asic3.h
new file mode 100644
index 000..5ffbeb4
--- /dev/null
+++ b/include/asm-arm/arch-s3c2410/rx3000-asic3.h
@@ -0,0 +1,63 @@
+/*
+ * linux/include/asm-arm/arch-s3c2410/rx3000-asic3.h
+ *
+ * Written by Roman Moravcik <[EMAIL PROTECTED]>
+ *
+ * Use consistent with the GNU GPL is permitted,
+ * provided that this copyright notice is
+ * preserved in its entirety in all copies and derived works.
+ *
+ */
+
+#ifndef __ASM_ARCH_RX3000_ASIC3_H
+#define __ASM_ARCH_RX3000_ASIC3_H "rx3000-asic3.h"
+
+#include
+
+/* GPIOA */
+#define ASIC3_GPA0 (1 << 0) /* charger enable, 0 =
disable, 1 = enable */
+#define ASIC3_GPA1 (1 << 1) /* audio mute, 0 = mute, 1 =
unmute */
+#define ASIC3_GPA2 (1 << 2) /* audio reset, 0 = disable,
1 = enable */
+#define ASIC3_GPA3 (1 << 3) /* usb d+ pullup, 0 =
disable, 1 = enable */
+#define ASIC3_GPA13(1 << 13) /* charger mode, 0 = slow, 1
= fast */
+#define ASIC3_GPA15(1 << 15) /* bluetooth clock 32kHz, 0 =
disable, 1 = enable */
+
+/* GPIOB */
+#define ASIC3_GPB1 (
[RFC, PATCH 0/4] SoC base drivers
Hello linux-kernel, In contemporary systems, lots of functionality oftentimes handled by various kinds of SoCs (system-on-chip), representing a number of deversified controllers packaged in one chip. Handling them is arguably an ongoing problem, as diversity and number of devices included make it hard to come with maintainable and reusable solution for writing drivers. Common examples are developing one monolithic driver for all internal devices, or making one of device drivers export functions required by others, leading to not very clean dependencies like touchscreen driver depending on a sound one. Handhelds.org kernel project (dealing with Linux porting to consumer, real-world embedded devices, and majority of our devices have different kinds of SoCs) for few years developed a more clean approach to handling SoCs - using the concept of "SoC base drivers". This is not the first time we're submitting these patches, with reworking and elaborating them based on the feedback received. We also extend supported machine base for these drivers (for example, asic3_base driver in the following patches is used by a dozen of machines). SoC base drivers - concept -- A SoC base driver is a special kind of driver which manages a SoC chip's common and shared resources and functionality, and provides interfaces for subdevice drivers to use. This in particukar solves "tangled dependencies" issues mentioned above - different subdevices now depend not on each other, but on a common foundation, forming a hierarchial structure. Term "interfaces" is used intentionally, as besides offering an API adhoc to specific SoC functionality, the intent is to reuse existing kernel susbystems/interfaces as much as possible, essentially breaking tight coupledness of subdevice drivers and base driver. For example, Generic IRQ Subsystem is used to handle SoC interrupts, so subdevice drivers just use existing generic API to request and free IRQs. More importantly, existing driver model is used to handle subdevices of a SoC. For each subdevice, a standard struct device is allocated, and LDM is used to handle driver binding and further lifecycle. So, this is a special trair of SoC base drivers: these are the drivers which register other devices (note that it is not a case of "legacy" driver where single module registers both a device and a driver serving it - SoC base driver registers other devices to be handled by other driver, namely SoC individual subdevices and drivers for them). Initial implementation from few years ago registered per-SoC bus for the purpose of attaching subdevices, but during LKML reviews it was pointed out that there're no good reasons for that, as such bus does not have any special functionality attached, so now platform_bus is used instead, for good. For the most part, subdevices are allocated dynamically, and SoC base driver calculates/fixes up resources and parameters for them, to be suitable for specific configuration (for example, different base address of SoC). What exact functionality and API a SoC base driver provides depends largely on specific chip, there's no specific API a SoC driver should implement. Here is a list of common tasks the driver usually would do: 1. Access handling to the chip (serialization, locking, etc.) 2. Managing common chip resources: 2.1. Interrupts control, demultiplexing, etc. (using Generic IRQ subsystem) 2.2. GPIO handling (adhoc, while eagerly waiting for an extensible GPIO API, we posted our implementation at http://lkml.org/lkml/2007/4/10/299 ). 2.3. Clocks (Using Platform Clock API) 2.4. Other kinds of "enable" and "power" switches (in adhoc manner or (ab)using the Clocks API, and waiting for generalization of it). 3. Calculating properties and registerting subdevices. There's a helper soc-core API to help SoC base drivers with common tasks, like registering subdevices. The implementation and patches following is structured as follows: 1. include/linux/soc/ and drivers/soc/ directories are created to keep namespaces clean (we have around 10 SoC base drivers now). Note that these dirs are for base drivers only, subdevice drivers go to one of standard dirs based on their functionality (for a example, video driver goes to driver/video/). 2. soc-core.c, soc-core.h: helper API to calculate subdevice resources and register them based on template definitions provided by SoC drivers. 3. asic3_base.c and associated headers: SoC base driver for HTC ASIC3, a popular SoC for ARM-based handheld devices, currently known to be used in 12 machines, including one machine which is already in mainline. 4. mach-3715.c: A patch for HP iPaq rx3715 machine, already in mainline, to add ASIC3 support using asic3_base driver. I would like to end this RFC with the fact that mainline of course already contains drivers for non-CPU SoC chips. arch/arm/common/sa.c and arch/arm/common/locomo.c are two examples from the ARM realm. This RFC grows from th
[RFC, PATCH 1/4] SoC base drivers: SoC helper API
Hello linux-kernel,
soc-core: Helper API for SoC base drivers to register/unregister
subdevices.
Signed-off-by: Paul Sokolovsky <[EMAIL PROTECTED]>
arch/arm/Kconfig |2 +
drivers/Makefile |1 +
drivers/soc/soc-core.c | 106
drivers/soc/soc-core.h | 30 +
include/linux/ioport.h |3 +
5 files changed, 142 insertions(+), 0 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e7baca2..da7d318 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -997,6 +997,8 @@ source "drivers/mmc/Kconfig"
source "drivers/rtc/Kconfig"
+source "drivers/soc/Kconfig"
+
endmenu
source "fs/Kconfig"
diff --git a/drivers/Makefile b/drivers/Makefile
index 920c975..3fb8cf1 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -80,3 +80,4 @@ obj-$(CONFIG_GENERIC_TIME)+= clocksource/
obj-$(CONFIG_DMA_ENGINE) += dma/
obj-$(CONFIG_HID) += hid/
obj-$(CONFIG_PPC_PS3) += ps3/
+obj-y += soc/
diff --git a/drivers/soc/soc-core.c b/drivers/soc/soc-core.c
new file mode 100644
index 000..24c654c
--- /dev/null
+++ b/drivers/soc/soc-core.c
@@ -0,0 +1,106 @@
+/*
+ * drivers/soc/soc-core.c
+ *
+ * core SoC support
+ * Copyright (c) 2006 Ian Molton
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This file contains functionality used by many SoC type devices.
+ *
+ * Created: 2006-11-28
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include "soc-core.h"
+
+void soc_free_devices(struct platform_device *devices, int nr_devs)
+{
+ struct platform_device *dev = devices;
+ int i;
+
+ for (i = 0; i < nr_devs; i++) {
+ struct resource *res = dev->resource;
+ platform_device_unregister(dev++);
+ kfree(res);
+ }
+ kfree(devices);
+}
+EXPORT_SYMBOL_GPL(soc_free_devices);
+
+#define SIGNED_SHIFT(val, shift) ((shift) >= 0 ? ((val) << (shift)) : ((val)
>> -(shift)))
+
+struct platform_device *soc_add_devices(struct platform_device *dev,
+ struct soc_device_data *soc, int
nr_devs,
+ struct resource *mem,
+ int relative_addr_shift, int irq_base)
+{
+ struct platform_device *devices;
+ int i, r, base;
+
+ devices = kzalloc(nr_devs * sizeof(struct platform_device), GFP_KERNEL);
+ if (!devices)
+ return NULL;
+
+ for (i = 0; i < nr_devs; i++) {
+ struct platform_device *sdev = &devices[i];
+ struct soc_device_data *blk = &soc[i];
+ struct resource *res;
+
+ sdev->id = -1;
+ sdev->name = blk->name;
+
+ sdev->dev.parent = &dev->dev;
+ sdev->dev.platform_data = (void *)blk->hwconfig;
+ sdev->num_resources = blk->num_resources;
+
+ /* Allocate space for the subdevice resources */
+ res = kzalloc (blk->num_resources * sizeof (struct resource),
GFP_KERNEL);
+ if (!res)
+ goto fail;
+
+ for (r = 0 ; r < blk->num_resources ; r++) {
+ res[r].name = blk->res[r].name; // Fixme - should copy
+
+ /* Find out base to use */
+ base = 0;
+ if (blk->res[r].flags & IORESOURCE_MEM) {
+ base = mem->start;
+ } else if ((blk->res[r].flags & IORESOURCE_IRQ) &&
+ (blk->res[r].flags &
IORESOURCE_IRQ_SOC_SUBDEVICE)) {
+ base = irq_base;
+ }
+
+ /* Adjust resource */
+ if (blk->res[r].flags & IORESOURCE_MEM) {
+ res[r].parent = mem;
+ res[r].start = base +
SIGNED_SHIFT(blk->res[r].start, relative_addr_shift);
+ res[r].end = base +
SIGNED_SHIFT(blk->res[r].end, relative_addr_shift);
+ } else {
+ res[r].start = base + blk->res[r].start;
+ res[r].end = base + blk->res[r].end;
+ }
+ res[r].flags = blk->res[r].flags;
+ }
+
+ sdev->resource = res;
+ if (platform_device_register(sdev)) {
+ kfree(res);
+ goto fail;
+ }
+
+ printk(KERN_INFO "SoC: registering %s\n", blk->name);
+ }
+ return devices;
+
+fail:
+ soc_free_devices(devices, i + 1);
+ return NULL;
+}
+EXPORT_SYMBOL_GPL(soc_add_devices);
diff --git a/drivers/soc/soc-core.h
[RFC, PATCH 2/4] SoC base drivers: ASIC3 SoC hardware definitions
Hello linux-kernel, Intro: This is a header with hardware definitions for ASIC3 chip, contributed by HP/Compaq. It is provided as-is, as a vendor-originated header. - ipaq-asic3.h: Hardware definitions for ASIC3 chip, found in ~12 handheld devices from HP/Compaq and HTC. Signed-off-by: Paul Sokolovsky <[EMAIL PROTECTED]> include/asm-arm/hardware/ipaq-asic3.h | 609 + 1 files changed, 609 insertions(+), 0 deletions(-) diff --git a/include/asm-arm/hardware/ipaq-asic3.h b/include/asm-arm/hardware/ipaq-asic3.h new file mode 100644 index 000..789bb16 --- /dev/null +++ b/include/asm-arm/hardware/ipaq-asic3.h @@ -0,0 +1,609 @@ +/* + * + * Definitions for the HTC ASIC3 chip found in several handheld devices + * + * Copyright 2001 Compaq Computer Corporation. + * + * Use consistent with the GNU GPL is permitted, + * provided that this copyright notice is + * preserved in its entirety in all copies and derived works. + * + * COMPAQ COMPUTER CORPORATION MAKES NO WARRANTIES, EXPRESSED OR IMPLIED, + * AS TO THE USEFULNESS OR CORRECTNESS OF THIS CODE OR ITS + * FITNESS FOR ANY PARTICULAR PURPOSE. + * + * Author: Andrew Christian + * + */ + +#ifndef IPAQ_ASIC3_H +#define IPAQ_ASIC3_H + +// +/* IPAQ, ASIC #3, replaces ASIC #1 */ + +#define IPAQ_ASIC3(_b,s,x,y) \ + (*((volatile s *) (_b + _IPAQ_ASIC3_ ## x ## _Base + (_IPAQ_ASIC3_ ## x ## _ ## y +#define IPAQ_ASIC3_N(_b,s,x,y,z) \ + (*((volatile s *) (_b + _IPAQ_ASIC3_ ## x ## _ ## y ## _Base + (_IPAQ_ASIC3_ ## x ## _ ## z + +#define IPAQ_ASIC3_GPIO(_b,s,x,y) \ + (*((volatile s *) (_b + _IPAQ_ASIC3_GPIO_ ## x ## _Base + (_IPAQ_ASIC3_GPIO_ ## y + +#define IPAQ_ASIC3_OFFSET(x,y) (_IPAQ_ASIC3_ ## x ## _Base + _IPAQ_ASIC3_ ## x ## _ ## y) +#define IPAQ_ASIC3_GPIO_OFFSET(x,y) (_IPAQ_ASIC3_GPIO_ ## x ## _Base + _IPAQ_ASIC3_GPIO_ ## y) + + +/* All offsets below are specified with this address bus shift */ +#define ASIC3_DEFAULT_ADDR_SHIFT 2 + +#define _IPAQ_ASIC3_GPIO_A_Base 0x +#define _IPAQ_ASIC3_GPIO_B_Base 0x0100 +#define _IPAQ_ASIC3_GPIO_C_Base 0x0200 +#define _IPAQ_ASIC3_GPIO_D_Base 0x0300 + +#define _IPAQ_ASIC3_GPIO_Mask 0x00/* R/W 0:don't mask, 1:mask interrupt */ +#define _IPAQ_ASIC3_GPIO_Direction 0x04/* R/W 0:input, 1:output */ +#define _IPAQ_ASIC3_GPIO_Out 0x08/* R/W 0:output low, 1:output high*/ +#define _IPAQ_ASIC3_GPIO_TriggerType 0x0c/* R/W 0:level, 1:edge */ +#define _IPAQ_ASIC3_GPIO_EdgeTrigger 0x10/* R/W 0:falling, 1:rising */ +#define _IPAQ_ASIC3_GPIO_LevelTrigger 0x14/* R/W 0:low, 1:high level detect */ +#define _IPAQ_ASIC3_GPIO_SleepMask 0x18/* R/W 0:don't mask, 1:mask trigger in sleep mode */ +#define _IPAQ_ASIC3_GPIO_SleepOut 0x1c/* R/W level 0:low, 1:high in sleep mode */ +#define _IPAQ_ASIC3_GPIO_BattFaultOut 0x20/* R/W level 0:low, 1:high in batt_fault */ +#define _IPAQ_ASIC3_GPIO_IntStatus 0x24/* R/W 0:none, 1:detect */ +#define _IPAQ_ASIC3_GPIO_AltFunction 0x28/* R/W 0:normal control 1:LED register control */ +#define _IPAQ_ASIC3_GPIO_SleepConf 0x2c/* R/W bit 1: autosleep 0: disable gposlpout in normal mode, enable gposlpout in sleep mode */ +#define _IPAQ_ASIC3_GPIO_Status0x30/* R Pin status */ + +#define IPAQ_ASIC3_GPIO_A_MASK(_b)IPAQ_ASIC3_GPIO( _b, u16, A, Mask ) +#define IPAQ_ASIC3_GPIO_A_DIR(_b) IPAQ_ASIC3_GPIO( _b, u16, A, Direction ) +#define IPAQ_ASIC3_GPIO_A_OUT(_b) IPAQ_ASIC3_GPIO( _b, u16, A, Out ) +#define IPAQ_ASIC3_GPIO_A_LEVELTRI(_b)IPAQ_ASIC3_GPIO( _b, u16, A, TriggerType ) +#define IPAQ_ASIC3_GPIO_A_RISING(_b) IPAQ_ASIC3_GPIO( _b, u16, A, EdgeTrigger ) +#define IPAQ_ASIC3_GPIO_A_LEVEL(_b) IPAQ_ASIC3_GPIO( _b, u16, A, LevelTrigger ) +#define IPAQ_ASIC3_GPIO_A_SLEEP_MASK(_b) IPAQ_ASIC3_GPIO( _b, u16, A, SleepMask ) +#define IPAQ_ASIC3_GPIO_A_SLEEP_OUT(_b) IPAQ_ASIC3_GPIO( _b, u16, A, SleepOut ) +#define IPAQ_ASIC3_GPIO_A_BATT_FAULT_OUT(_b) IPAQ_ASIC3_GPIO( _b, u16, A, BattFaultOut ) +#define IPAQ_ASIC3_GPIO_A_INT_STATUS(_b) IPAQ_ASIC3_GPIO( _b, u16, A, IntStatus ) +#define IPAQ_ASIC3_GPIO_A_ALT_FUNCTION(_b)IPAQ_ASIC3_GPIO( _b, u16, A, AltFunction ) +#define IPAQ_ASIC3_GPIO_A_SLEEP_CONF(_b) IPAQ_ASIC3_GPIO( _b, u16, A, SleepConf ) +#define IPAQ_ASIC3_GPIO_A_STATUS(_b) IPAQ_ASIC3_GPIO( _b, u16, A, Status ) + +#define IPAQ_ASIC3_GPIO_B_MASK(_b)IPAQ_ASIC3_GPIO( _b, u16, B, Mask ) +#define IPAQ_ASIC3_GPIO_B_DIR(_b) IPAQ_ASIC3_GPIO( _b, u16, B, Direction ) +#define IPAQ_ASIC3_GPIO_B_OUT(_b)
Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header.
On Mon, Apr 30, 2007 at 10:20:53PM -0600, Eric W. Biederman wrote: > Vivek Goyal <[EMAIL PROTECTED]> writes: > > > On Mon, Apr 30, 2007 at 05:17:07PM +0200, Andi Kleen wrote: > >> On Monday 30 April 2007 17:12:39 Eric W. Biederman wrote: > >> > > >> > Currently because vmlinux does not reflect that the kernel is relocatable > >> > we still have to support CONFIG_PHYSICAL_START. So this patch adds a > >> > small > >> > c program to do what we cannot do with a linker script set the elf header > >> > type to ET_DYN. > >> > > >> > Since last time I have fixed the type to be in my code ET_DYN (oops), > >> > and verified this works with kexec. I realized while testing that we > >> > don't have anyway of identifying a kernel vmlinux as linux so we > >> > probably want to add an ELF note but that will be another patch. > >> > >> The patch is ok for me, but does it pass Vivek's usual testing? > > > > I am facing one issue with this patch. gdb can not analyze the > > resulting kernel core file. Looks like gdb treats vmlinux differently if > > ELF header type is "ET_DYN". It reads the symbol values incorrectly. > > Weird. > > > For example, symbol value of "panic_timeout" is 0x808a1fa8 but > > gdb somehow things that it is 0x008aaebf. Looks like it is > > performing some relocation. > > > > I am using GNU gdb Red Hat Linux (6.5-5.fc6rh). > > Does it take a kernel core file to reproduce this problem? > Or can you just open up gdb on a vmlinux and look at the symbol > address? It takes a core file to reproduce the problem. Without core file gdb can get right symbol addresses. > > At least without a core file it is working on with gdb 6.4. > This seems to be a problem with gdb 6.5. I transferred the dump to a different machine having GNU gdb 6.4, and it works fine there. Thanks Vivek - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CONFIG_HIGHMEM4G and 1GB RAM
William Lee Irwin III wrote: >> The CONFIG_VMSPLIT config options were merged for such cases. >> It should be able to split on any 4MB-aligned boundary in >> CONFIG_HIGHMEM4G. CONFIG_VMSPLIT_3G_OPT appears to do something of >> this sort to use an entire 1GB RAM with minimal user address space >> reduction. >> This is an ELF ABI violation but the number of major applications >> that break is apparently low. On Mon, Apr 30, 2007 at 11:18:28PM +0100, Matt Keenan wrote: > wine and some java implementations being two of the big caveats. If this is really true, then I think it critical to be mentioned in the Kconfig help text. Thanks! -- Al - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [stable] to something appropriate (was Re: 2.6.22 -mm merge plans)
On Mon, Apr 30, 2007 at 08:45:25PM -0400, Jeff Garzik wrote: > Chris Wright wrote: > > 2) you can add them > > runtime in userspace (and for pcmcia too after patch in question is > > applied), so we've historically avoided that kind of patch for -stable. > > > Due to distro installer environments, and very poor support for making > dynamic PCI IDs persistent once added, what you describe is more of a > goal than reality. But distros can easily add the device id to their kernel if needed, it isn't something that the -stable tree shoud be accepting. Otherwise, we will be swamped with those types of patches... thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Killing a User thread from another User Thread
Hi. I am working on an audio device driver development on Linux (sh4 architecture). I have a userthread which makes ioctl calls to the kernel and once it reaches inside the kernel it waits on a semaphore. It then does some work inside the kernel and continuously keeps looping between the kernel and user space in an endless while loop. I want to kill that thread from another user thread while the former is waiting on a semaphore in kernel (which it will never get) coz I want a clean exit of my driver. Please suggest me a way. I did try the use of pthread_cancel, but that is possible only if the target thread is executing in user space and making use of a pthread_testcancel call (with cancelability enabled ofcourse). Kindly suggest something. Regards, Bhuvan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [30/30] x86_64: Add missing !X86_PAE dependincy to the 2G/2G split.
William Lee Irwin III a écrit : On Tue, May 01, 2007 at 05:58:29AM +0200, Andi Kleen wrote: From: [EMAIL PROTECTED] When in PAE mode we require that the user kernel divide to be on a 1G boundary. The 2G/2G split does not have that property so require !X86_PAE Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]> --- arch/i386/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) What on earth? config PAGE_OFFSET hex default 0xB000 if VMSPLIT_3G_OPT default 0x7800 if VMSPLIT_2G default 0x4000 if VMSPLIT_1G default 0xC000 This appears to have been introduced by: commit 975b3d3d5b983eb60706d35f0d24cd19f6badabf Author: Mark Lord <[EMAIL PROTECTED]> Date: Wed Feb 1 03:06:11 2006 -0800 [PATCH] VMSPLIT config options There's some sort of insanity going on here. Since when is 0x7800 a 2GB/2GB split? Mark, dare I ask what you were thinking? That should be VMSPLIT_2G_OPT for 2GB laptops analogously to VMSPLIT_3G_OPT, if nothing else, as it's certainly not 2GB/2GB. Please could you stop saying others are insane ? They are like you and can fail sometime. Apparently when the patch came, nobody (including you) commented. It's not that difficult to think about VMALLOC space (I might be wrong about this, but I feel this explains 7800 vs 8000) These VMSPLIT config options vs. PAE are foul as they're now done in any event. If they were done properly, they'd properly set up the pmd within which the division point between user and kernelspace falls. This patch, I suppose, stops people from shooting themselves in the foot, but (IMHO) the VMSPLIT patches shouldn't have been merged without handling the partial pmd case. 2MB/4MB resolution is enough granularity for any reasonable purpose, so split ptes aren't worth the effort, but this nonsense with PAE vs. VMSPLIT is just preposterous. If you're going to play the VMSPLIT game at all, handle split pmd's. I'll see what else is pending in the i386 pagetable arena and clear this up if there aren't other objections (this is where Andi gets to complain that things are too complex already and preemptively NAK to save me the effort, if it's not seen to be desirable). Eric, your patch is a reasonable stop-gap measure for the original deficiency. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[git pull] Input updates for post-2.6.21
Hi Linus,
Please consider pulling from:
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git
or
master.kernel.org:/pub/scm/linux/kernel/git/dtor/input.git
to receive updates for input subsystem.
Changelog:
--
Andres Salomon (1):
Input: psmouse - allow disabing certain protocol extensions
Cliff Brake (1):
Input: ucb1400 - make delays configurable
Dmitry Torokhov (44):
Input: psmouse - do not force stream mode
Input: export 'uniq' in /proc/bus/input/devices
Input: let driver core create class device attribute groups
Input: simplify input_free_device()
Input: i8042 - add HP Pavilion DV4017EA to the MUX blacklist
Input: rework handle creation code
Input: handlers - rename 'list' to 'client'
Input: handlers - handle errors from input_open_device()
Input: synaptics - export model bits
Input: keyboard handler - use printk_ratelimit()
Input: ALPS - handle errors from input_register_device()
Input: mousedev - fix sudden warps with touchpads
Input: i8042 - disable interfaces when switching to legacy mode
Input: logips2pp - ignore mice reporting model as 0
Input: gtco - handle errors from input_register_device()
Input: logips2pp - add model 1 information
Input: remove old USB touchscreen drivers
Input: USB devices - handle errors when registering input devices
Input: add input_{get|set}_drvdata() helpers
Input: drivers/input/mice - don't access dev->private directly
Input: drivers/input/touchscreen - don't access dev->private directly
Input: drivers/input/joystick - don't access dev->private directly
Input: drivers/input/keyboard - don't access dev->private directly
Input: drivers/input/misc - don't access dev->private directly
Input: drivers/usb/input - don't access dev->private directly
Input: prepare to switching to struct device
Input: keyboards - switch to using input_dev->dev.parent
Input: USB devices - switch to using input_dev->dev.parent
Input: mice - switch to using input_dev->dev.parent
Input: touchscreens - switch to using input_dev->dev.parent
Input: joysticks - switch to using input_dev->dev.parent
Input: misc devices - switch to using input_dev->dev.parent
Input: cobalt buttons - separate device and driver registration
Input: lifebook - work properly on Panasonic CF-18
Input: lifebook - activate 6-byte protocol on select models
Input: lifebook - add signature of Panasonic CF-29
Input: lifebook - split into 2 devices
Input: i8042 - add Panasonic CF-29 to nomux list
Input: i8042 - add Fujitsu touchscreen/touchpad PNP IDs
Input: add input_set_capability() helper
Input: update some documentation
Input: add skeleton for simple polled devices
Input: cobalt_btns - convert to use polldev library
Merge master.kernel.org:/.../torvalds/linux-2.6
Eric Piel (5):
Input: wistron - add support for TravelMate 610
Input: wistron - add acerhk laptop database
Input: wistron - introduce generic keymap
Input: wistron - declare keymaps as initdata
Input: wistron - fix typo in keymap for Acer TM610
Helge Deller (3):
Input: HIL - various fixes for HIL drivers
Input: HIL - cleanup coding style
Input: HIL - fix rwlock recursion bug
Johann Deneux (1):
Input: iforce - use usb_kill_urb instead of usb_unlink_urb
Karl Pickett (1):
Input: ati_remote - make button repeat sensitivity configurable
Marvin Raaijmakers (1):
Input: add getkeycode and setkeycode methods
Nicolas Ferre (1):
Input: ads7846 - add support for the ads7843 touchscreen
Peter Osterlund (1):
Input: sermouse - improve protocol error recovery
Peter Stokes (1):
Input: add logical channel support for ATI Remote Wonder II
Robert P. J. Day (1):
Input: remove no longer used power.c handler
Rodolfo Giometti (1):
Input: add support for PXA27x keyboard controller
Roman Moravcik (1):
Input: gpio_keys - add support for switches (EV_SW)
Stefan Lucke (1):
Input: psmouse - add support for eGalax PS/2 touchscreen controller
Thomas Gleixner (1):
Input: pxa27x - do not use deprecated SA_INTERRUPT flag
Yoichi Yuasa (1):
Input: add driver for MIPS Cobalt back panel buttons
Diffstat:
-
Documentation/input/input-programming.txt | 125 +++--
arch/mips/cobalt/Makefile |2 +-
arch/mips/cobalt/buttons.c | 54 ++
drivers/char/keyboard.c| 101 ++--
drivers/input/Makefile |1 -
drivers/input/evbug.c | 32 +-
drivers/input/evdev.c | 233 +
drivers/input/input.c | 266 +++---
drivers/input/joydev.c | 185 ---
drivers/input/jo
Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage
On Mon, 2007-04-30 at 21:00 -0700, H. Peter Anvin wrote: > H. Peter Anvin wrote: > > Rusty Russell wrote: > >> It'd be nicer if there were a "struct boot_params" declaration, but we > >> can't have everything. > > > > It's in my patchset-under-development. > > > > (Preview snapshot: > > http://userweb.kernel.org/~hpa/setup-snapshot-2007.04.30.patch) > > Just pushed out a git tree: > > http://git.kernel.org/?p=linux/kernel/git/hpa/linux-2.6-newsetup.git;a=summary Any chance of splitting off a "struct boot_params" header (includable by non-kernel code) for inclusion immediately? The rest can wait until 2.6.23, but it'd be sweet to get this in place sooner. BTW, wrt. a new "platform type" field, should it go something like this? -0235/3 N/A pad2Unused +0235/1 2.07+ platform_type Runtime platform (see below) +0236/2 N/A pad2Unused ... + platform_type: + For kernels which can boot on multiple platforms. Currently + 0 == native (normal), 1 == lguest (paravirtualized). Thanks, Rusty. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [30/30] x86_64: Add missing !X86_PAE dependincy to the 2G/2G split.
On Tue, May 01, 2007 at 05:58:29AM +0200, Andi Kleen wrote: > From: [EMAIL PROTECTED] > When in PAE mode we require that the user kernel divide to be > on a 1G boundary. The 2G/2G split does not have that property > so require !X86_PAE > Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]> > --- > arch/i386/Kconfig |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) What on earth? config PAGE_OFFSET hex default 0xB000 if VMSPLIT_3G_OPT default 0x7800 if VMSPLIT_2G default 0x4000 if VMSPLIT_1G default 0xC000 This appears to have been introduced by: commit 975b3d3d5b983eb60706d35f0d24cd19f6badabf Author: Mark Lord <[EMAIL PROTECTED]> Date: Wed Feb 1 03:06:11 2006 -0800 [PATCH] VMSPLIT config options There's some sort of insanity going on here. Since when is 0x7800 a 2GB/2GB split? Mark, dare I ask what you were thinking? That should be VMSPLIT_2G_OPT for 2GB laptops analogously to VMSPLIT_3G_OPT, if nothing else, as it's certainly not 2GB/2GB. These VMSPLIT config options vs. PAE are foul as they're now done in any event. If they were done properly, they'd properly set up the pmd within which the division point between user and kernelspace falls. This patch, I suppose, stops people from shooting themselves in the foot, but (IMHO) the VMSPLIT patches shouldn't have been merged without handling the partial pmd case. 2MB/4MB resolution is enough granularity for any reasonable purpose, so split ptes aren't worth the effort, but this nonsense with PAE vs. VMSPLIT is just preposterous. If you're going to play the VMSPLIT game at all, handle split pmd's. I'll see what else is pending in the i386 pagetable arena and clear this up if there aren't other objections (this is where Andi gets to complain that things are too complex already and preemptively NAK to save me the effort, if it's not seen to be desirable). Eric, your patch is a reasonable stop-gap measure for the original deficiency. -- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20 libata cdrom
[cc'ing linux-ide and Albert, Hi!] William Thompson wrote: > On Mon, Apr 30, 2007 at 12:22:21PM +0200, Tejun Heo wrote: >> William Thompson wrote: >>> I've been playing with libata on a few machines and I found that this >>> machine >>> (An old Dell Dimension L866r) gives me this when it loads and does not give >>> me >>> access to the cdrom. This is the only machine that I've tested that I know >>> for a fact cannot do DMA on the cdrom. I searched and noticed a similar >>> problem with 2.6.19-rc versions but I'm not sure if it's the same problem. >>> >>> dmesg output: >>> libata version 2.00 loaded. >>> ata_piix :00:1f.1: version 2.00ac7 >>> PCI: Setting latency timer of device :00:1f.1 to 64 >>> ata1: PATA max UDMA/66 cmd 0x1F0 ctl 0x3F6 bmdma 0xFFA0 irq 14 >>> ata2: PATA max UDMA/66 cmd 0x170 ctl 0x376 bmdma 0xFFA8 irq 15 >>> scsi0 : ata_piix >>> ata1.00: ATA-4, max UDMA/33, 10018890 sectors: LBA >>> ata1.00: ata1: dev 0 multi count 16 >>> ata1.00: configured for UDMA/33 >>> scsi1 : ata_piix >>> ata2.00: failed to IDENTIFY (I/O error, err_mask=0x1) >> Hmm... IDENTIFY failed on the second port. How reproducible is the >> problem? Every time? Does it work with the IDE driver? If so, please >> post the result of 'hdparm -I /dev/hdX'. > > Reproducible? Everytime > > Yes, it works fine with the IDE driver, so long as DMA is disabled. > > hdparm -I: > /dev/hdc: > > ATAPI CD-ROM, with removable media > Model Number: Lite-On LTN483S 48x Max > Serial Number: > Firmware Revision: PD02 > Standards: > Used: ATAPI for CD-ROMs, SFF-8020i, r2.5 > Supported: CD-ROM ATAPI-1 > Configuration: > DRQ response: <=10ms with INTRQ > Packet size: 12 bytes > Capabilities: > LBA, IORDY(can be disabled) > DMA: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2 udma0 udma1 *udma2 > Cycle time: min=120ns recommended=120ns > PIO: pio0 pio1 pio2 pio3 pio4 > Cycle time: no flow control=120ns IORDY flow control=120ns The err_mask is AC_ERR_DEV indicating that the device raised aborted the IDENTIFY command. I wonder what's going on. Can you change "#undef ATA_DEBUG" in include/linux/libata.h to "#define ATA_DEBUG" and report the resulting dmesg? There will be a LOT of messages so you probably want to increase printk buffer size and detach other devices if possible. It would be best if your root device isn't driven by libata so that you can just insert the module and store the resulting dmesg. Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.6.21: Kernel won't boot with either/both of CONFIG_NO_HZ, CONFIG_HIGH_RES_TIMERS
On Mon, 2007-04-30 at 23:33 -0400, Mark Lord wrote: > Daniel Walker wrote: > > > > I'm interested in which clocksource is getting used, which is in the > > boot log. > > Well then, send me a patch that dumps that information out just before it > locks up. > We know (first post in this thread) that the lockup occurs just after > these two messages: > > "switched to high resolution mode on cpu 1" > "switched to high resolution mode on cpu 0" > > So just dump out anything else you need to see at the same time, > and it'll still be on my screen when the darned thing locks up. > > Simple, eh. We both get to run around a treadmill this way. ;) I guess I could make due with the successful boot (less running for us both).. It's using the hpet clocksource .. You could try adding clocksource=acpi_pm to the boot args , in the off chance it's an hpet clock issue. Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: old buffer overflow in moxa driver
Wow, I'd forgotten all about this one. Signed-off-by: Andres Salomon <[EMAIL PROTECTED]> dann frazier wrote: > hey, > I noticed that the moxa input checking security bug described by > CVE-2005-0504 appears to remain unfixed upstream. > > The issue is described here: > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0504 > > Debian has been shipping the following patch from Andres Salomon. I > tried contacting the listed maintainer a few months ago but received > no response. > > I've tested that this still applies to and compiles against 2.6.21. > > Signed-off-by: dann frazier <[EMAIL PROTECTED]> > > diff --git a/drivers/char/moxa.c b/drivers/char/moxa.c > index 7dbaee8..e0d35c2 100644 > --- a/drivers/char/moxa.c > +++ b/drivers/char/moxa.c > @@ -1582,7 +1582,7 @@ copy: > > if(copy_from_user(&dltmp, argp, sizeof(struct dl_str))) > return -EFAULT; > - if(dltmp.cardno < 0 || dltmp.cardno >= MAX_BOARDS) > + if(dltmp.cardno < 0 || dltmp.cardno >= MAX_BOARDS || dltmp.len < 0) > return -EINVAL; > > switch(cmd) > @@ -2529,6 +2529,8 @@ static int moxaloadbios(int cardno, unsigned char > __user *tmp, int len) > void __iomem *baseAddr; > int i; > > + if(len < 0 || len > sizeof(moxaBuff)) > + return -EINVAL; > if(copy_from_user(moxaBuff, tmp, len)) > return -EFAULT; > baseAddr = moxa_boards[cardno].basemem; > @@ -2576,7 +2578,7 @@ static int moxaload320b(int cardno, unsigned char > __user *tmp, int len) > void __iomem *baseAddr; > int i; > > - if(len > sizeof(moxaBuff)) > + if(len < 0 || len > sizeof(moxaBuff)) > return -EINVAL; > if(copy_from_user(moxaBuff, tmp, len)) > return -EFAULT; > @@ -2596,6 +2598,8 @@ static int moxaloadcode(int cardno, unsigned char > __user *tmp, int len) > void __iomem *baseAddr, *ofsAddr; > int retval, port, i; > > + if(len < 0 || len > sizeof(moxaBuff)) > + return -EINVAL; > if(copy_from_user(moxaBuff, tmp, len)) > return -EFAULT; > baseAddr = moxa_boards[cardno].basemem; > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.6.21: Kernel won't boot with either/both of CONFIG_NO_HZ, CONFIG_HIGH_RES_TIMERS
On Mon, 2007-04-30 at 23:33 -0400, Mark Lord wrote: > Daniel Walker wrote: > > > > I'm interested in which clocksource is getting used, which is in the > > boot log. > > Well then, send me a patch that dumps that information out just before it > locks up. > We know (first post in this thread) that the lockup occurs just after > these two messages: > > "switched to high resolution mode on cpu 1" > "switched to high resolution mode on cpu 0" > > So just dump out anything else you need to see at the same time, > and it'll still be on my screen when the darned thing locks up. > > Simple, eh. We both get to run around a treadmill this way. ;) Forgot it's an SMP system .. So would have to be clocksource=tsc . Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH CFS V7] Fix warnings in sched and sched_debug
The first patch I sent out did not have a sign-off; I had trouble with my patch tools. This patch fixes all warnings seen on powerpc during compilation of the CFS patch. It also fixes errors (side-effect of the warnings), where some of the data is printed as negative values. Applies on top of cfs v7 Signed-off-by: Balbir Singh <[EMAIL PROTECTED]> --- kernel/sched.c | 34 +- kernel/sched_debug.c | 16 2 files changed, 25 insertions(+), 25 deletions(-) diff -puN kernel/sched.c~cfs-v7-fix-sched-debug-warnings kernel/sched.c --- linux-2.6.21/kernel/sched.c~cfs-v7-fix-sched-debug-warnings 2007-05-01 09:55:14.0 +0530 +++ linux-2.6.21-balbir/kernel/sched.c 2007-05-01 09:55:14.0 +0530 @@ -229,7 +229,7 @@ char * sched_print_task_state(struct tas unsigned long long t0, t1; #define P(F) \ - buffer += sprintf(buffer, "%-25s:%20Ld\n", #F, p->F) + buffer += sprintf(buffer, "%-25s:%20Ld\n", #F, (long long)p->F) P(wait_start); P(wait_start_fair); @@ -248,22 +248,22 @@ char * sched_print_task_state(struct tas t0 = sched_clock(); t1 = sched_clock(); - buffer += sprintf(buffer, "%-25s:%20Ld\n", "clock-delta", t1-t0); - buffer += sprintf(buffer, "%-25s:%20Ld\n", - "rq-wait_runtime", this_rq->wait_runtime); - buffer += sprintf(buffer, "%-25s:%20Ld\n", - "rq-fair_clock", this_rq->fair_clock); - buffer += sprintf(buffer, "%-25s:%20Ld\n", - "rq-clock", this_rq->clock); - buffer += sprintf(buffer, "%-25s:%20Ld\n", - "rq-prev_clock_raw", this_rq->prev_clock_raw); - buffer += sprintf(buffer, "%-25s:%20Ld\n", - "rq-clock_max_delta", this_rq->clock_max_delta); - buffer += sprintf(buffer, "%-25s:%20u\n", - "rq-clock_warps", this_rq->clock_warps); - buffer += sprintf(buffer, "%-25s:%20u\n", - "rq-clock_unstable_events", - this_rq->clock_unstable_events); + buffer += sprintf(buffer, "%-25s:%20Ld\n", "clock-delta", + (long long)t1-t0); + buffer += sprintf(buffer, "%-25s:%20Ld\n", "rq-wait_runtime", + (long long)this_rq->wait_runtime); + buffer += sprintf(buffer, "%-25s:%20Ld\n", "rq-fair_clock", + (long long)this_rq->fair_clock); + buffer += sprintf(buffer, "%-25s:%20Ld\n", "rq-clock", + (long long)this_rq->clock); + buffer += sprintf(buffer, "%-25s:%20Ld\n", "rq-prev_clock_raw", + (long long)this_rq->prev_clock_raw); + buffer += sprintf(buffer, "%-25s:%20Ld\n", "rq-clock_max_delta", + (long long)this_rq->clock_max_delta); + buffer += sprintf(buffer, "%-25s:%20u\n", "rq-clock_warps", + this_rq->clock_warps); + buffer += sprintf(buffer, "%-25s:%20u\n", "rq-clock_unstable_events", + this_rq->clock_unstable_events); return buffer; } diff -puN kernel/sched_debug.c~cfs-v7-fix-sched-debug-warnings kernel/sched_debug.c --- linux-2.6.21/kernel/sched_debug.c~cfs-v7-fix-sched-debug-warnings 2007-05-01 09:55:14.0 +0530 +++ linux-2.6.21-balbir/kernel/sched_debug.c2007-05-01 09:55:14.0 +0530 @@ -45,13 +45,13 @@ print_task(struct seq_file *m, struct rq SEQ_printf(m, "%14s %5d %12Ld %11Ld %10Ld %9Ld %5d " "%13Ld %13Ld %13Ld\n", p->comm, p->pid, - p->fair_key, p->fair_key - rq->fair_clock, - p->wait_runtime, - p->nr_switches, + (long long)p->fair_key, (long long)p->fair_key - rq->fair_clock, + (long long)p->wait_runtime, + (long long)p->nr_switches, p->prio, - p->wait_start_fair - rq->fair_clock, - p->sum_exec_runtime, - p->sum_wait_runtime); + (long long)p->wait_start_fair - rq->fair_clock, + (long long)p->sum_exec_runtime, + (long long)p->sum_wait_runtime); } static void print_rq(struct seq_file *m, struct rq *rq, u64 now) @@ -83,7 +83,7 @@ static void print_cpu(struct seq_file *m SEQ_printf(m, "\ncpu: %d\n", cpu); #define P(x) \ - SEQ_printf(m, " .%-22s: %Ld\n", #x, (u64)(rq->x)) + SEQ_printf(m, " .%-22s: %Lu\n", #x, (unsigned long long)(rq->x)) P(nr_running); P(raw_weighted_load); @@ -110,7 +110,7 @@ static int sched_debug_show(struct seq_f int cpu; SEQ_printf(m, "Sched Debug Version: v0.02\n"); - SEQ_printf(m, "now at %Ld nsecs\n", (unsigned long long)now); + SEQ_printf(m, "now at %Lu nsecs\n", (unsigned long long)now); for_each_online_c
Re: [PATCH] [30/30] x86_64: Add missing !X86_PAE dependincy to the 2G/2G split.
Andi Kleen a écrit : From: [EMAIL PROTECTED] When in PAE mode we require that the user kernel divide to be on a 1G boundary. The 2G/2G split does not have that property so require !X86_PAE Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]> --- arch/i386/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/i386/Kconfig b/arch/i386/Kconfig index 1a94a73..80003de 100644 --- a/arch/i386/Kconfig +++ b/arch/i386/Kconfig @@ -570,6 +570,7 @@ choice depends on !HIGHMEM bool "3G/1G user/kernel split (for full 1G low memory)" config VMSPLIT_2G + depends on !X86_PAE bool "2G/2G user/kernel split" config VMSPLIT_1G bool "1G/3G user/kernel split" Hum... We lose a usefull 2G/2G split. Should'nt we use a patch to change PAGE_OFFSET to 0x800 instead of 0x7800 and keep 2G/2G split ? Maybe the following patch is better ? [PATCH] i386 : Adjust CONFIG_PAGE_OFFSET in case of 2G/2G split and X86_PAE When in PAE mode we require that the user kernel divide to be on a 1G boundary. We must therefore make sure PAGE_OFFSET is correctlty defined in the 2G/2G split and PAE mode. Signed-off-by: Eric Dumazet <[EMAIL PROTECTED]> diff --git a/arch/i386/Kconfig b/arch/i386/Kconfig index 53d6237..32356f2 100644 --- a/arch/i386/Kconfig +++ b/arch/i386/Kconfig @@ -578,7 +578,8 @@ endchoice config PAGE_OFFSET hex default 0xB000 if VMSPLIT_3G_OPT - default 0x7800 if VMSPLIT_2G + default 0x7800 if (VMSPLIT_2G && !X86_PAE) + default 0x8000 if (VMSPLIT_2G && X86_PAE) default 0x4000 if VMSPLIT_1G default 0xC000
Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header.
Vivek Goyal <[EMAIL PROTECTED]> writes: > On Mon, Apr 30, 2007 at 05:17:07PM +0200, Andi Kleen wrote: >> On Monday 30 April 2007 17:12:39 Eric W. Biederman wrote: >> > >> > Currently because vmlinux does not reflect that the kernel is relocatable >> > we still have to support CONFIG_PHYSICAL_START. So this patch adds a small >> > c program to do what we cannot do with a linker script set the elf header >> > type to ET_DYN. >> > >> > Since last time I have fixed the type to be in my code ET_DYN (oops), >> > and verified this works with kexec. I realized while testing that we >> > don't have anyway of identifying a kernel vmlinux as linux so we >> > probably want to add an ELF note but that will be another patch. >> >> The patch is ok for me, but does it pass Vivek's usual testing? > > I am facing one issue with this patch. gdb can not analyze the > resulting kernel core file. Looks like gdb treats vmlinux differently if > ELF header type is "ET_DYN". It reads the symbol values incorrectly. Weird. > For example, symbol value of "panic_timeout" is 0x808a1fa8 but > gdb somehow things that it is 0x008aaebf. Looks like it is > performing some relocation. > > I am using GNU gdb Red Hat Linux (6.5-5.fc6rh). Does it take a kernel core file to reproduce this problem? Or can you just open up gdb on a vmlinux and look at the symbol address? At least without a core file it is working on with gdb 6.4. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] megaraid: fix CONFIG_PROC_FS compile errors
Andrew Morton wrote: On Mon, 30 Apr 2007 08:44:14 -0700 Randy Dunlap <[EMAIL PROTECTED]> wrote: On Mon, 30 Apr 2007 07:35:00 -0700 (PDT) David Rientjes wrote: Only declare mega_proc_dir_entry() in CONFIG_PROC_FS. We should call mega_create_proc_entry() only in this configuration so make sure it's defined if we call it. Only define mega_adapinq() in CONFIG_PROC_FS. mega_internal_dev_inquiry() and mega_print_inquiry() were never declared without CONFIG_PROC_FS so make sure we don't have prototypes for them if we aren't going to define them. Move the declaration of 'buf' in mega_remove_one() because we only use it in the CONFIG_PROC_FS case. Just noting the presence of: http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc7/2.6.21-rc7-mm2/broken-out/megaraid-fix-warnings-when-config_proc_fs=n.patch That patch has been submitted fourteen times in the past year, and was completely ignored each time. Oh, and that SCSI patches need to go to the linux-scsi mailing list. There seem to be little point in doing that. Yes, I guess I was speaking theory instead of reality. I suppose that one alternative is for you to merge those long-queued patches instead of sending them on to linux-scsi over and over again. -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] get_property returns const
This is the last place that needs changing since get_property was changed
to return "const void *".
Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
---
drivers/net/ehea/ehea_main.c | 13 ++---
1 files changed, 6 insertions(+), 7 deletions(-)
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index c7a5614..519bb9f 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -2603,14 +2603,13 @@ static int ehea_setup_ports(struct ehea_adapter
*adapter)
{
struct device_node *lhea_dn;
struct device_node *eth_dn = NULL;
-
- u32 *dn_log_port_id;
+ const u32 *dn_log_port_id;
int i = 0;
lhea_dn = adapter->ebus_dev->ofdev.node;
while ((eth_dn = of_get_next_child(lhea_dn, eth_dn))) {
- dn_log_port_id = (u32*)get_property(eth_dn, "ibm,hea-port-no",
+ dn_log_port_id = get_property(eth_dn, "ibm,hea-port-no",
NULL);
if (!dn_log_port_id) {
ehea_error("bad device node: eth_dn name=%s",
@@ -2645,12 +2644,12 @@ static struct device_node *ehea_get_eth_dn(struct
ehea_adapter *adapter,
{
struct device_node *lhea_dn;
struct device_node *eth_dn = NULL;
- u32 *dn_log_port_id;
+ const u32 *dn_log_port_id;
lhea_dn = adapter->ebus_dev->ofdev.node;
while ((eth_dn = of_get_next_child(lhea_dn, eth_dn))) {
- dn_log_port_id = (u32*)get_property(eth_dn, "ibm,hea-port-no",
+ dn_log_port_id = get_property(eth_dn, "ibm,hea-port-no",
NULL);
if (dn_log_port_id)
if (*dn_log_port_id == logical_port_id)
@@ -2774,7 +2773,7 @@ static int __devinit ehea_probe_adapter(struct
ibmebus_dev *dev,
const struct of_device_id *id)
{
struct ehea_adapter *adapter;
- u64 *adapter_handle;
+ const u64 *adapter_handle;
int ret;
if (!dev || !dev->ofdev.node) {
@@ -2791,7 +2790,7 @@ static int __devinit ehea_probe_adapter(struct
ibmebus_dev *dev,
adapter->ebus_dev = dev;
- adapter_handle = (u64*)get_property(dev->ofdev.node, "ibm,hea-handle",
+ adapter_handle = get_property(dev->ofdev.node, "ibm,hea-handle",
NULL);
if (adapter_handle)
adapter->handle = *adapter_handle;
--
1.5.1.2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] Rename get_property to of_get_property: drivers
These are all the remaining instances of get_property. Simple rename of
get_property to of_get_property.
Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
---
drivers/ata/sata_svw.c |2 +-
drivers/char/agp/uninorth-agp.c|2 +-
drivers/char/briq_panel.c |2 +-
drivers/char/tpm/tpm_atmel.h |2 +-
drivers/hwmon/ams/ams-core.c |2 +-
drivers/hwmon/ams/ams-i2c.c|2 +-
drivers/hwmon/ams/ams-pmu.c|2 +-
drivers/ide/ppc/pmac.c |4 ++--
drivers/infiniband/hw/ehca/ehca_main.c |2 +-
drivers/mtd/maps/physmap_of.c |8
drivers/net/bmac.c |5 +++--
drivers/net/ehea/ehea_main.c |6 +++---
drivers/net/mace.c |4 ++--
drivers/net/pasemi_mac.c |2 +-
drivers/net/spider_net.c |4 ++--
drivers/net/sungem.c |2 +-
drivers/net/sungem_phy.c |2 +-
drivers/net/ucc_geth.c | 18 +-
drivers/net/ucc_geth_mii.c |4 ++--
drivers/pci/hotplug/rpaphp_core.c | 10 +-
drivers/scsi/ibmvscsi/ibmvstgt.c |8
drivers/scsi/ibmvscsi/rpa_vscsi.c |4 ++--
drivers/scsi/mac53c94.c|2 +-
drivers/scsi/mesh.c|2 +-
drivers/serial/mpc52xx_uart.c |2 +-
drivers/serial/of_serial.c |4 ++--
drivers/serial/pmac_zilog.c|6 +++---
drivers/video/aty/radeon_base.c|6 +++---
drivers/video/aty/radeon_monitor.c | 11 ++-
drivers/video/aty/radeon_pm.c |2 +-
drivers/video/nvidia/nv_of.c |8
drivers/video/offb.c | 28 ++--
drivers/video/riva/fbdev.c |4 ++--
33 files changed, 87 insertions(+), 85 deletions(-)
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
diff --git a/drivers/ata/sata_svw.c b/drivers/ata/sata_svw.c
index cc07aac..1724673 100644
--- a/drivers/ata/sata_svw.c
+++ b/drivers/ata/sata_svw.c
@@ -288,7 +288,7 @@ static int k2_sata_proc_info(struct Scsi_Host *shost, char
*page, char **start,
/* Match it to a port node */
index = (ap == ap->host->ports[0]) ? 0 : 1;
for (np = np->child; np != NULL; np = np->sibling) {
- const u32 *reg = get_property(np, "reg", NULL);
+ const u32 *reg = of_get_property(np, "reg", NULL);
if (!reg)
continue;
if (index == *reg)
diff --git a/drivers/char/agp/uninorth-agp.c b/drivers/char/agp/uninorth-agp.c
index 91b0621..42c0a60 100644
--- a/drivers/char/agp/uninorth-agp.c
+++ b/drivers/char/agp/uninorth-agp.c
@@ -613,7 +613,7 @@ static int __devinit agp_uninorth_probe(struct pci_dev
*pdev,
uninorth_node = of_find_node_by_name(NULL, "u3");
}
if (uninorth_node) {
- const int *revprop = get_property(uninorth_node,
+ const int *revprop = of_get_property(uninorth_node,
"device-rev", NULL);
if (revprop != NULL)
uninorth_rev = *revprop & 0x3f;
diff --git a/drivers/char/briq_panel.c b/drivers/char/briq_panel.c
index c70d52a..ed53f54 100644
--- a/drivers/char/briq_panel.c
+++ b/drivers/char/briq_panel.c
@@ -206,7 +206,7 @@ static int __init briq_panel_init(void)
const char *machine;
int i;
- machine = get_property(root, "model", NULL);
+ machine = of_get_property(root, "model", NULL);
if (!machine || strncmp(machine, "TotalImpact,BRIQ-1", 18) != 0) {
of_node_put(root);
return -ENODEV;
diff --git a/drivers/char/tpm/tpm_atmel.h b/drivers/char/tpm/tpm_atmel.h
index 3c85200..377bc60 100644
--- a/drivers/char/tpm/tpm_atmel.h
+++ b/drivers/char/tpm/tpm_atmel.h
@@ -52,7 +52,7 @@ static void __iomem * atmel_get_base_addr(unsigned long
*base, int *region_size)
return NULL;
}
- reg = get_property(dn, "reg", ®len);
+ reg = of_get_property(dn, "reg", ®len);
naddrc = of_n_addr_cells(dn);
nsizec = of_n_size_cells(dn);
diff --git a/drivers/hwmon/ams/ams-core.c b/drivers/hwmon/ams/ams-core.c
index f5ebad5..93b963f 100644
--- a/drivers/hwmon/ams/ams-core.c
+++ b/drivers/hwmon/ams/ams-core.c
@@ -144,7 +144,7 @@ int ams_sensor_attach(void)
const u32 *prop;
/* Get orientation */
- prop = get_property(ams_info.of_node, "orientation", NULL);
+ prop = of_get_property(ams_info.of_node, "orientation", NULL);
if (!prop)
return -ENODEV;
ams_info.orient1 = *prop;
diff --git a/drivers/hwmon/ams/ams-i2c.c b/drivers/hwmon/ams/ams-i2c.c
index 485d333..ccd5cef 100644
--- a/drivers/hwmon/ams/ams-i2c.c
+++ b/drivers/hwmon/ams/ams-i2c.c
@@ -27
[PATCH] [26/30] i386: Drop noisy e820 debugging printks
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
arch/i386/kernel/e820.c | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
Index: linux/arch/i386/kernel/e820.c
===
--- linux.orig/arch/i386/kernel/e820.c
+++ linux/arch/i386/kernel/e820.c
@@ -393,10 +393,8 @@ int __init sanitize_e820_map(struct e820
33__
__4_
*/
- printk("sanitize start\n");
/* if there's only one memory region, don't bother */
if (*pnr_map < 2) {
- printk("sanitize bail 0\n");
return -1;
}
@@ -405,7 +403,6 @@ int __init sanitize_e820_map(struct e820
/* bail out if we find any unreasonable addresses in bios map */
for (i=0; isize;
unsigned long long end = start + size;
unsigned long type = biosmap->type;
- printk("copy_e820_map() start: %016Lx size: %016Lx end: %016Lx
type: %ld\n", start, size, end, type);
/* Overflow in 64 bits? Ignore the memory map. */
if (start > end)
@@ -543,17 +538,11 @@ int __init copy_e820_map(struct e820entr
* Not right. Fix it up.
*/
if (type == E820_RAM) {
- printk("copy_e820_map() type is E820_RAM\n");
if (start < 0x10ULL && end > 0xAULL) {
- printk("copy_e820_map() lies in range...\n");
- if (start < 0xAULL) {
- printk("copy_e820_map() start <
0xAULL\n");
+ if (start < 0xAULL)
add_memory_region(start,
0xAULL-start, type);
- }
- if (end <= 0x10ULL) {
- printk("copy_e820_map() end <=
0x10ULL\n");
+ if (end <= 0x10ULL)
continue;
- }
start = 0x10ULL;
size = end - start;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [18/30] x86_64: Don't enable NUMA for a single node in K8 NUMA scanning
This was supposed to see the full memory on a ASUS A8SX motherboard with 4GB RAM where the northbridge reports less memory, but it didn't help there. But it's a reasonable change so let's include it anyways. Signed-off-by: Andi Kleen <[EMAIL PROTECTED]> --- arch/x86_64/mm/k8topology.c |2 ++ 1 file changed, 2 insertions(+) Index: linux/arch/x86_64/mm/k8topology.c === --- linux.orig/arch/x86_64/mm/k8topology.c +++ linux/arch/x86_64/mm/k8topology.c @@ -62,6 +62,8 @@ int __init k8_scan_nodes(unsigned long s reg = read_pci_config(0, nb, 0, 0x60); numnodes = ((reg >> 4) & 0xF) + 1; + if (numnodes <= 1) + return -1; printk(KERN_INFO "Number of nodes %d\n", numnodes); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [25/30] x86_64: Fix allnoconfig error in genapic_flat.c
Fix: In file included from include2/asm/apic.h:5, from include2/asm/smp.h:15, from linux/arch/x86_64/kernel/genapic_flat.c:18: linux/include/linux/pm.h: In function âcall_platform_enable_wakeupâ: linux/include/linux/pm.h:331: error: âEIOâ undeclared (first use in this function) linux/include/linux/pm.h:331: error: (Each undeclared identifier is reported only once linux/include/linux/pm.h:331: error: for each function it appears in.) Signed-off-by: Andi Kleen <[EMAIL PROTECTED]> --- arch/x86_64/kernel/genapic_flat.c |1 + 1 file changed, 1 insertion(+) Index: linux/arch/x86_64/kernel/genapic_flat.c === --- linux.orig/arch/x86_64/kernel/genapic_flat.c +++ linux/arch/x86_64/kernel/genapic_flat.c @@ -8,6 +8,7 @@ * Martin Bligh, Andi Kleen, James Bottomley, John Stultz, and * James Cleverdon. */ +#include #include #include #include - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
console font limits
I'm having problems with a font I just created. It's a rather big one,
intended for a framebuffer console in UTF-8 mode. The strace program
reports that /bin/setfont fails on a KDFONTOP ioctl with EINVAL.
In reading the kernel code, I find this:
vt.c:static int con_font_set(struct vc_data *vc, struct console_font_op *op)
vt.c-{
vt.c- struct console_font font;
vt.c- int rc = -EINVAL;
vt.c- int size;
vt.c-
vt.c- if (vc->vc_mode != KD_TEXT)
vt.c- return -EINVAL;
vt.c- if (!op->data)
vt.c- return -EINVAL;
vt.c- if (op->charcount > 512)
vt.c- return -EINVAL;
Ouch. Why is the old VGA limit being applied to the framebuffer console?
Could this just get removed? I dearly hope we aren't still storing the
framebuffer data as two bytes per character+attribute pair.
I nearly hit the 32-pixel height limit as well, yet another relic from
the VGA hardware. I also nearly hit the 64 KB font size limit.
Currently I'm doing a 15x30 font with 870 glyphs to represent 978
different Unicode code points. This is for a 200 DPI display with
an anti-aliasing filter, so fonts need to be big. I'm considering 15x36
so that I'll have more room for double-accented letters, but clearly
the kernel would block that too.
BTW, the PSF font format documentation seems to suggest that
there is a way to make the kernel handle combining accents:
http://www.win.tue.nl/~aeb/linux/kbd/font-formats-1.html
Does anybody know if that really works? I could sure use that.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage
H. Peter Anvin wrote: > Rusty Russell wrote: >> It'd be nicer if there were a "struct boot_params" declaration, but we >> can't have everything. > > It's in my patchset-under-development. > > (Preview snapshot: > http://userweb.kernel.org/~hpa/setup-snapshot-2007.04.30.patch) Just pushed out a git tree: http://git.kernel.org/?p=linux/kernel/git/hpa/linux-2.6-newsetup.git;a=summary -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [19/30] i386: Little cleanups in smpboot.c
- Remove #if that is always set
- Fix warning
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
arch/i386/kernel/smpboot.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
Index: linux/arch/i386/kernel/smpboot.c
===
--- linux.orig/arch/i386/kernel/smpboot.c
+++ linux/arch/i386/kernel/smpboot.c
@@ -516,7 +516,6 @@ static void unmap_cpu_to_logical_apicid(
unmap_cpu_to_node(cpu);
}
-#if APIC_DEBUG
static inline void __inquire_remote_apic(int apicid)
{
int i, regs[] = { APIC_ID >> 4, APIC_LVR >> 4, APIC_SPIV >> 4 };
@@ -548,14 +547,13 @@ static inline void __inquire_remote_apic
switch (status) {
case APIC_ICR_RR_VALID:
status = apic_read(APIC_RRR);
- printk("%08x\n", status);
+ printk("%lx\n", status);
break;
default:
printk("failed\n");
}
}
}
-#endif
#ifdef WAKE_SECONDARY_VIA_NMI
/*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [20/30] i386: Remove copy_*_user BUG_ONs for (size < 0)
access_ok checks this case anyways, no need to check twice.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
arch/i386/lib/usercopy.c |7 ---
1 file changed, 7 deletions(-)
Index: linux/arch/i386/lib/usercopy.c
===
--- linux.orig/arch/i386/lib/usercopy.c
+++ linux/arch/i386/lib/usercopy.c
@@ -716,7 +716,6 @@ do {
\
unsigned long __copy_to_user_ll(void __user *to, const void *from,
unsigned long n)
{
- BUG_ON((long) n < 0);
#ifndef CONFIG_X86_WP_WORKS_OK
if (unlikely(boot_cpu_data.wp_works_ok == 0) &&
((unsigned long )to) < TASK_SIZE) {
@@ -785,7 +784,6 @@ EXPORT_SYMBOL(__copy_to_user_ll);
unsigned long __copy_from_user_ll(void *to, const void __user *from,
unsigned long n)
{
- BUG_ON((long)n < 0);
if (movsl_is_ok(to, from, n))
__copy_user_zeroing(to, from, n);
else
@@ -797,7 +795,6 @@ EXPORT_SYMBOL(__copy_from_user_ll);
unsigned long __copy_from_user_ll_nozero(void *to, const void __user *from,
unsigned long n)
{
- BUG_ON((long)n < 0);
if (movsl_is_ok(to, from, n))
__copy_user(to, from, n);
else
@@ -810,7 +807,6 @@ EXPORT_SYMBOL(__copy_from_user_ll_nozero
unsigned long __copy_from_user_ll_nocache(void *to, const void __user *from,
unsigned long n)
{
- BUG_ON((long)n < 0);
#ifdef CONFIG_X86_INTEL_USERCOPY
if ( n > 64 && cpu_has_xmm2)
n = __copy_user_zeroing_intel_nocache(to, from, n);
@@ -825,7 +821,6 @@ unsigned long __copy_from_user_ll_nocach
unsigned long __copy_from_user_ll_nocache_nozero(void *to, const void __user
*from,
unsigned long n)
{
- BUG_ON((long)n < 0);
#ifdef CONFIG_X86_INTEL_USERCOPY
if ( n > 64 && cpu_has_xmm2)
n = __copy_user_intel_nocache(to, from, n);
@@ -853,7 +848,6 @@ unsigned long __copy_from_user_ll_nocach
unsigned long
copy_to_user(void __user *to, const void *from, unsigned long n)
{
- BUG_ON((long) n < 0);
if (access_ok(VERIFY_WRITE, to, n))
n = __copy_to_user(to, from, n);
return n;
@@ -879,7 +873,6 @@ EXPORT_SYMBOL(copy_to_user);
unsigned long
copy_from_user(void *to, const void __user *from, unsigned long n)
{
- BUG_ON((long) n < 0);
if (access_ok(VERIFY_READ, from, n))
n = __copy_from_user(to, from, n);
else
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [23/30] x86_64: Share identical video.S between i386 and x86-64
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]> --- arch/x86_64/boot/setup.S |2 arch/x86_64/boot/video.S | 2043 --- 2 files changed, 1 insertion(+), 2044 deletions(-) Index: linux/arch/x86_64/boot/setup.S === --- linux.orig/arch/x86_64/boot/setup.S +++ linux/arch/x86_64/boot/setup.S @@ -807,7 +807,7 @@ gdt_48: # Include video setup & detection code -#include "video.S" +#include "../../i386/boot/video.S" # Setup signature -- must be last setup_sig1:.word SIG1 Index: linux/arch/x86_64/boot/video.S === --- linux.orig/arch/x86_64/boot/video.S +++ /dev/null @@ -1,2043 +0,0 @@ -/* video.S - * - * Display adapter & video mode setup, version 2.13 (14-May-99) - * - * Copyright (C) 1995 -- 1998 Martin Mares <[EMAIL PROTECTED]> - * Based on the original setup.S code (C) Linus Torvalds and Mats Anderson - * - * Rewritten to use GNU 'as' by Chris Noe <[EMAIL PROTECTED]> May 1999 - * - * For further information, look at Documentation/svga.txt. - * - */ - -/* Enable autodetection of SVGA adapters and modes. */ -#undef CONFIG_VIDEO_SVGA - -/* Enable autodetection of VESA modes */ -#define CONFIG_VIDEO_VESA - -/* Enable compacting of mode table */ -#define CONFIG_VIDEO_COMPACT - -/* Retain screen contents when switching modes */ -#define CONFIG_VIDEO_RETAIN - -/* Enable local mode list */ -#undef CONFIG_VIDEO_LOCAL - -/* Force 400 scan lines for standard modes (hack to fix bad BIOS behaviour */ -#undef CONFIG_VIDEO_400_HACK - -/* Hack that lets you force specific BIOS mode ID and specific dimensions */ -#undef CONFIG_VIDEO_GFX_HACK -#define VIDEO_GFX_BIOS_AX 0x4f02 /* 800x600 on ThinkPad */ -#define VIDEO_GFX_BIOS_BX 0x0102 -#define VIDEO_GFX_DUMMY_RESOLUTION 0x6425 /* 100x37 */ - -/* This code uses an extended set of video mode numbers. These include: - * Aliases for standard modes - * NORMAL_VGA (-1) - * EXTENDED_VGA (-2) - * ASK_VGA (-3) - * Video modes numbered by menu position -- NOT RECOMMENDED because of lack - * of compatibility when extending the table. These are between 0x00 and 0xff. - */ -#define VIDEO_FIRST_MENU 0x - -/* Standard BIOS video modes (BIOS number + 0x0100) */ -#define VIDEO_FIRST_BIOS 0x0100 - -/* VESA BIOS video modes (VESA number + 0x0200) */ -#define VIDEO_FIRST_VESA 0x0200 - -/* Video7 special modes (BIOS number + 0x0900) */ -#define VIDEO_FIRST_V7 0x0900 - -/* Special video modes */ -#define VIDEO_FIRST_SPECIAL 0x0f00 -#define VIDEO_80x25 0x0f00 -#define VIDEO_8POINT 0x0f01 -#define VIDEO_80x43 0x0f02 -#define VIDEO_80x28 0x0f03 -#define VIDEO_CURRENT_MODE 0x0f04 -#define VIDEO_80x30 0x0f05 -#define VIDEO_80x34 0x0f06 -#define VIDEO_80x60 0x0f07 -#define VIDEO_GFX_HACK 0x0f08 -#define VIDEO_LAST_SPECIAL 0x0f09 - -/* Video modes given by resolution */ -#define VIDEO_FIRST_RESOLUTION 0x1000 - -/* The "recalculate timings" flag */ -#define VIDEO_RECALC 0x8000 - -/* Positions of various video parameters passed to the kernel */ -/* (see also include/linux/tty.h) */ -#define PARAM_CURSOR_POS 0x00 -#define PARAM_VIDEO_PAGE 0x04 -#define PARAM_VIDEO_MODE 0x06 -#define PARAM_VIDEO_COLS 0x07 -#define PARAM_VIDEO_EGA_BX 0x0a -#define PARAM_VIDEO_LINES 0x0e -#define PARAM_HAVE_VGA 0x0f -#define PARAM_FONT_POINTS 0x10 - -#define PARAM_LFB_WIDTH0x12 -#define PARAM_LFB_HEIGHT 0x14 -#define PARAM_LFB_DEPTH0x16 -#define PARAM_LFB_BASE 0x18 -#define PARAM_LFB_SIZE 0x1c -#define PARAM_LFB_LINELENGTH 0x24 -#define PARAM_LFB_COLORS 0x26 -#define PARAM_VESAPM_SEG 0x2e -#define PARAM_VESAPM_OFF 0x30 -#define PARAM_LFB_PAGES0x32 -#define PARAM_VESA_ATTRIB 0x34 -#define PARAM_CAPABILITIES 0x36 - -/* Define DO_STORE according to CONFIG_VIDEO_RETAIN */ -#ifdef CONFIG_VIDEO_RETAIN -#define DO_STORE call store_screen -#else -#define DO_STORE -#endif /* CONFIG_VIDEO_RETAIN */ - -# This is the main entry point called by setup.S -# %ds *must* be pointing to the bootsector -video: pushw %ds # We use different segments - pushw %ds # FS contains original DS - popw%fs - pushw %cs # DS is equal to CS - popw%ds - pushw %cs # ES is equal to CS - popw%es - xorw%ax, %ax - movw%ax, %gs# GS is zero - cld - callbasic_detect# Basic adapter type testing (EGA/VGA/MDA/CGA) -#ifdef CONFIG_VIDEO_SELECT - movw%fs:(0x01fa), %ax # User selected video mode - cmpw$ASK_VGA, %ax # Bring up the menu - jz vid2 - - callmode_set# Set the mode - jc vid1 - - leawbadmdt, %si # Invalid
[PATCH] [22/30] x86_64: Remove CONFIG_REORDER
The option never worked well and functionlist wasn't well maintained. Also it made the build very slow on many binutils version. So just remove it. Cc: [EMAIL PROTECTED] Signed-off-by: Andi Kleen <[EMAIL PROTECTED]> --- arch/x86_64/Kconfig |8 arch/x86_64/Makefile |1 arch/x86_64/kernel/functionlist | 1284 --- arch/x86_64/kernel/vmlinux.lds.S |3 4 files changed, 1296 deletions(-) Index: linux/arch/x86_64/Kconfig === --- linux.orig/arch/x86_64/Kconfig +++ linux/arch/x86_64/Kconfig @@ -660,14 +660,6 @@ config CC_STACKPROTECTOR_ALL source kernel/Kconfig.hz -config REORDER - bool "Function reordering" - default n - help - This option enables the toolchain to reorder functions for a more - optimal TLB usage. If you have pretty much any version of binutils, -this can increase your kernel build time by roughly one minute. - config K8_NB def_bool y depends on AGP_AMD64 || IOMMU || (PCI && NUMA) Index: linux/arch/x86_64/Makefile === --- linux.orig/arch/x86_64/Makefile +++ linux/arch/x86_64/Makefile @@ -40,7 +40,6 @@ cflags-y += -m64 cflags-y += -mno-red-zone cflags-y += -mcmodel=kernel cflags-y += -pipe -cflags-kernel-$(CONFIG_REORDER) += -ffunction-sections cflags-y += -Wno-sign-compare cflags-y += -fno-asynchronous-unwind-tables ifneq ($(CONFIG_DEBUG_INFO),y) Index: linux/arch/x86_64/kernel/functionlist === --- linux.orig/arch/x86_64/kernel/functionlist +++ /dev/null @@ -1,1284 +0,0 @@ -*(.text.flush_thread) -*(.text.check_poison_obj) -*(.text.copy_page) -*(.text.__set_personality) -*(.text.gart_map_sg) -*(.text.kmem_cache_free) -*(.text.find_get_page) -*(.text._raw_spin_lock) -*(.text.ide_outb) -*(.text.unmap_vmas) -*(.text.copy_page_range) -*(.text.kprobe_handler) -*(.text.__handle_mm_fault) -*(.text.__d_lookup) -*(.text.copy_user_generic) -*(.text.__link_path_walk) -*(.text.get_page_from_freelist) -*(.text.kmem_cache_alloc) -*(.text.drive_cmd_intr) -*(.text.ia32_setup_sigcontext) -*(.text.huge_pte_offset) -*(.text.do_page_fault) -*(.text.page_remove_rmap) -*(.text.release_pages) -*(.text.ide_end_request) -*(.text.__mutex_lock_slowpath) -*(.text.__find_get_block) -*(.text.kfree) -*(.text.vfs_read) -*(.text._raw_spin_unlock) -*(.text.free_hot_cold_page) -*(.text.fget_light) -*(.text.schedule) -*(.text.memcmp) -*(.text.touch_atime) -*(.text.__might_sleep) -*(.text.__down_read_trylock) -*(.text.arch_pick_mmap_layout) -*(.text.find_vma) -*(.text.__make_request) -*(.text.do_generic_mapping_read) -*(.text.mutex_lock_interruptible) -*(.text.__generic_file_aio_read) -*(.text._atomic_dec_and_lock) -*(.text.__wake_up_bit) -*(.text.add_to_page_cache) -*(.text.cache_alloc_debugcheck_after) -*(.text.vm_normal_page) -*(.text.mutex_debug_check_no_locks_freed) -*(.text.net_rx_action) -*(.text.__find_first_zero_bit) -*(.text.put_page) -*(.text._raw_read_lock) -*(.text.__delay) -*(.text.dnotify_parent) -*(.text.do_path_lookup) -*(.text.do_sync_read) -*(.text.do_lookup) -*(.text.bit_waitqueue) -*(.text.file_read_actor) -*(.text.strncpy_from_user) -*(.text.__pagevec_lru_add_active) -*(.text.fget) -*(.text.dput) -*(.text.__strnlen_user) -*(.text.inotify_inode_queue_event) -*(.text.rw_verify_area) -*(.text.ide_intr) -*(.text.inotify_dentry_parent_queue_event) -*(.text.permission) -*(.text.memscan) -*(.text.hpet_rtc_interrupt) -*(.text.do_mmap_pgoff) -*(.text.current_fs_time) -*(.text.vfs_getattr) -*(.text.kmem_flagcheck) -*(.text.mark_page_accessed) -*(.text.free_pages_and_swap_cache) -*(.text.generic_fillattr) -*(.text.__block_prepare_write) -*(.text.__set_page_dirty_nobuffers) -*(.text.link_path_walk) -*(.text.find_get_pages_tag) -*(.text.ide_do_request) -*(.text.__alloc_pages) -*(.text.generic_permission) -*(.text.mod_page_state_offset) -*(.text.free_pgd_range) -*(.text.generic_file_buffered_write) -*(.text.number) -*(.text.ide_do_rw_disk) -*(.text.__brelse) -*(.text.__mod_page_state_offset) -*(.text.rotate_reclaimable_page) -*(.text.find_vma_prepare) -*(.text.find_vma_prev) -*(.text.lru_cache_add_active) -*(.text.__kmalloc_track_caller) -*(.text.smp_invalidate_interrupt) -*(.text.handle_IRQ_event) -*(.text.__find_get_block_slow) -*(.text.do_wp_page) -*(.text.do_select) -*(.text.set_user_nice) -*(.text.sys_read) -*(.text.do_munmap) -*(.text.csum_partial) -*(.text.__do_softirq) -*(.text.may_open) -*(.text.getname) -*(.text.get_empty_filp) -*(.text.__fput) -*(.text.remove_mapping) -*(.text.filp_ctor) -*(.text.poison_obj) -*(.text.unmap_region) -*(.text.test_set_page_writeback) -*(.text.__do_page_cache_readahead) -*(.text.sock_def_readable) -*(.text.ide_outl) -*(.text.shrink_zone) -*(.text.rb_insert_color) -*(.text.get_request) -*(.text.sys_pread64) -*(.text.spin_bug) -*(.text.ide_outsl) -*
[PATCH] [21/30] x86_64: Print type and size correctly for unknown compat ioctls
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
fs/compat.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
Index: linux/fs/compat.c
===
--- linux.orig/fs/compat.c
+++ linux/fs/compat.c
@@ -371,13 +371,14 @@ static void compat_ioctl_error(struct fi
fn = "?";
}
- sprintf(buf,"'%c'", (cmd>>24) & 0x3f);
+ sprintf(buf,"'%c'", (cmd>>_IOC_TYPESHIFT) & _IOC_TYPEMASK);
if (!isprint(buf[1]))
sprintf(buf, "%02x", buf[1]);
compat_printk("ioctl32(%s:%d): Unknown cmd fd(%d) "
- "cmd(%08x){%s} arg(%08x) on %s\n",
+ "cmd(%08x){t:%s;sz:%u} arg(%08x) on %s\n",
current->comm, current->pid,
(int)fd, (unsigned int)cmd, buf,
+ (cmd >> _IOC_SIZESHIFT) & _IOC_SIZEMASK,
(unsigned int)arg, fn);
if (path)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [12/30] i386: Verify important CPUID bits in real mode
Check some CPUID bits that are needed for compiler generated early in boot. When the system is still in real mode before changing the VESA BIOS mode it is possible to still display an visible error message on the screen. Similar to x86-64. Includes cleanups from Eric Biederman Signed-off-by: Andi Kleen <[EMAIL PROTECTED]> --- arch/i386/Kconfig.cpu| 22 ++- arch/i386/boot/setup.S | 17 arch/i386/kernel/verify_cpu.S| 68 +++ include/asm-i386/cpufeature.h|3 + include/asm-i386/required-features.h | 34 + 5 files changed, 142 insertions(+), 2 deletions(-) Index: linux/arch/i386/kernel/verify_cpu.S === --- /dev/null +++ linux/arch/i386/kernel/verify_cpu.S @@ -0,0 +1,65 @@ +/* Check if CPU has some minimum CPUID bits + This runs in 16bit mode so that the caller can still use the BIOS + to output errors on the screen */ +#include + +verify_cpu: + pushfl # Save caller passed flags + pushl $0 # Kill any dangerous flags + popfl + +#if CONFIG_X86_MINIMUM_CPU_MODEL >= 4 + pushfl + orl $(1<<18),(%esp) # try setting AC + popfl + pushfl + popl%eax + testl $(1<<18),%eax + jz bad +#endif +#if REQUIRED_MASK1 != 0 + pushfl # standard way to check for cpuid + popl%eax + movl%eax,%ebx + xorl$0x20,%eax + pushl %eax + popfl + pushfl + popl%eax + cmpl%eax,%ebx + pushfl # standard way to check for cpuid + popl%eax + movl%eax,%ebx + xorl$0x20,%eax + pushl %eax + popfl + pushfl + popl%eax + cmpl%eax,%ebx + jz bad # REQUIRED_MASK1 != 0 requires CPUID + + movl$0x0,%eax # See if cpuid 1 is implemented + cpuid + cmpl$0x1,%eax + jb bad # no cpuid 1 + + movl$0x1,%eax # Does the cpu have what it takes + cpuid + +#if CONFIG_X86_MINIMUM_CPU_MODEL > 4 +#error add proper model checking here +#endif + + andl$REQUIRED_MASK1,%edx + xorl$REQUIRED_MASK1,%edx + jnz bad +#endif /* REQUIRED_MASK1 */ + + popfl + xor %eax,%eax + ret + +bad: + popfl + movl$1,%eax + ret Index: linux/arch/i386/Kconfig.cpu === --- linux.orig/arch/i386/Kconfig.cpu +++ linux/arch/i386/Kconfig.cpu @@ -240,14 +240,19 @@ config X86_L1_CACHE_SHIFT default "5" if MWINCHIP3D || MWINCHIP2 || MWINCHIPC6 || MCRUSOE || MEFFICEON || MCYRIXIII || MK6 || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || M586 || MVIAC3_2 || MGEODE_LX default "6" if MK7 || MK8 || MPENTIUMM || MCORE2 || MVIAC7 +config X86_XADD + bool + depends on !M386 + default y + config RWSEM_GENERIC_SPINLOCK bool - depends on M386 + depends on !X86_XADD default y config RWSEM_XCHGADD_ALGORITHM bool - depends on !M386 + depends on X86_XADD default y config ARCH_HAS_ILOG2_U32 @@ -331,3 +336,16 @@ config X86_TSC bool depends on (MWINCHIP3D || MWINCHIP2 || MCRUSOE || MEFFICEON || MCYRIXIII || MK7 || MK6 || MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || MK8 || MVIAC3_2 || MVIAC7 || MGEODEGX1 || MGEODE_LX || MCORE2) && !X86_NUMAQ default y + +# this should be set for all -march=.. options where the compiler +# generates cmov. +config X86_CMOV + bool + depends on (MK7 || MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || MVIAC3_2 || MVIAC7) + default y + +config X86_MINIMUM_CPU_MODEL + int + default "4" if X86_XADD || X86_CMPXCHG || X86_BSWAP + default "0" + Index: linux/arch/i386/boot/setup.S === --- linux.orig/arch/i386/boot/setup.S +++ linux/arch/i386/boot/setup.S @@ -302,7 +302,24 @@ good_sig: loader_panic_mess: .string "Wrong loader, giving up..." +# check minimum cpuid +# we do this here because it is the last place we can actually +# show a user visible error message. Later the video modus +# might be already messed up. loader_ok: + call verify_cpu + testl %eax,%eax + jz cpu_ok + lea cpu_panic_mess,%si + callprtstr +1: jmp 1b + +cpu_panic_mess: + .asciz "PANIC: CPU too old for this kernel." + +#include "../kernel/verify_cpu.S" + +cpu_ok: # Get memory size (extended mem, kB) xorl%eax, %eax Index: linux/include/asm-i386/cpufeature.h ===
[PATCH] [13/30] i386: Evaluate constant cpu features at runtime
Redefine cpu_has() to evaluate cpu features already checked in early boot at compile time. This way the compiler might eliminate some dead code. Signed-off-by: Andi Kleen <[EMAIL PROTECTED]> --- include/asm-i386/cpufeature.h |8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) Index: linux/include/asm-i386/cpufeature.h === --- linux.orig/include/asm-i386/cpufeature.h +++ linux/include/asm-i386/cpufeature.h @@ -106,8 +106,12 @@ #define X86_FEATURE_LAHF_LM(6*32+ 0) /* LAHF/SAHF in long mode */ #define X86_FEATURE_CMP_LEGACY (6*32+ 1) /* If yes HyperThreading not valid */ -#define cpu_has(c, bit)test_bit(bit, (c)->x86_capability) -#define boot_cpu_has(bit) test_bit(bit, boot_cpu_data.x86_capability) +#define cpu_has(c, bit)\ + ((__builtin_constant_p(bit) && (bit) < 32 &&\ + (1UL << (bit)) & REQUIRED_MASK1) ? \ + 1 : \ + test_bit(bit, (c)->x86_capability)) +#define boot_cpu_has(bit) cpu_has(&boot_cpu_data, bit) #define cpu_has_fpuboot_cpu_has(X86_FEATURE_FPU) #define cpu_has_vmeboot_cpu_has(X86_FEATURE_VME) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [17/30] x86: Use RDTSCP for synchronous get_cycles if possible
RDTSCP is already synchronous and doesn't need an explicit CPUID. This is a little faster and more importantly avoids VMEXITs on Hypervisors. Original patch from Joerg Roedel, but reworked by AK Also includes miscompilation fix by Eric Biederman Cc: "Joerg Roedel" <[EMAIL PROTECTED]> Signed-off-by: Andi Kleen <[EMAIL PROTECTED]> --- include/asm-i386/tsc.h |9 + 1 file changed, 9 insertions(+) Index: linux/include/asm-i386/tsc.h === --- linux.orig/include/asm-i386/tsc.h +++ linux/include/asm-i386/tsc.h @@ -38,6 +38,15 @@ static __always_inline cycles_t get_cycl unsigned eax; /* +* Use RDTSCP if possible; it is guaranteed to be synchronous +* and doesn't cause a VMEXIT on Hypervisors +*/ + alternative_io(ASM_NOP3, ".byte 0x0f,0x01,0xf9", X86_FEATURE_RDTSCP, +"=A" (ret), "0" (0ULL) : "ecx", "memory"); + if (ret) + return ret; + + /* * Don't do an additional sync on CPUs where we know * RDTSC is already synchronous: */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [15/30] i386: Implement X86_FEATURE_SYNC_RDTSC on i386
Syncs up with x86-64.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
arch/i386/kernel/cpu/intel.c |4 +++-
include/asm-i386/cpufeature.h |1 +
include/asm-i386/tsc.h|4
3 files changed, 4 insertions(+), 5 deletions(-)
Index: linux/arch/i386/kernel/cpu/intel.c
===
--- linux.orig/arch/i386/kernel/cpu/intel.c
+++ linux/arch/i386/kernel/cpu/intel.c
@@ -188,8 +188,10 @@ static void __cpuinit init_intel(struct
}
#endif
- if (c->x86 == 15)
+ if (c->x86 == 15) {
set_bit(X86_FEATURE_P4, c->x86_capability);
+ set_bit(X86_FEATURE_SYNC_RDTSC, c->x86_capability);
+ }
if (c->x86 == 6)
set_bit(X86_FEATURE_P3, c->x86_capability);
if ((c->x86 == 0xf && c->x86_model >= 0x03) ||
Index: linux/include/asm-i386/cpufeature.h
===
--- linux.orig/include/asm-i386/cpufeature.h
+++ linux/include/asm-i386/cpufeature.h
@@ -79,6 +79,7 @@
#define X86_FEATURE_PEBS (3*32+12) /* Precise-Event Based Sampling */
#define X86_FEATURE_BTS(3*32+13) /* Branch Trace Store */
#define X86_FEATURE_LAPIC_TIMER_BROKEN (3*32+ 14) /* lapic timer broken in C1
*/
+#define X86_FEATURE_SYNC_RDTSC (3*32+15) /* RDTSC synchronizes the CPU */
/* Intel-defined CPU features, CPUID level 0x0001 (ecx), word 4 */
#define X86_FEATURE_XMM3 (4*32+ 0) /* Streaming SIMD Extensions-3 */
Index: linux/include/asm-i386/tsc.h
===
--- linux.orig/include/asm-i386/tsc.h
+++ linux/include/asm-i386/tsc.h
@@ -35,7 +35,6 @@ static inline cycles_t get_cycles(void)
static __always_inline cycles_t get_cycles_sync(void)
{
unsigned long long ret;
-#ifdef X86_FEATURE_SYNC_RDTSC
unsigned eax;
/*
@@ -44,9 +43,6 @@ static __always_inline cycles_t get_cycl
*/
alternative_io("cpuid", ASM_NOP2, X86_FEATURE_SYNC_RDTSC,
"=a" (eax), "0" (1) : "ebx","ecx","edx","memory");
-#else
- sync_core();
-#endif
rdtscll(ret);
return ret;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [16/30] i386: Add X86_FEATURE_RDTSCP
Following x86-64 Signed-off-by: Andi Kleen <[EMAIL PROTECTED]> --- include/asm-i386/cpufeature.h |1 + 1 file changed, 1 insertion(+) Index: linux/include/asm-i386/cpufeature.h === --- linux.orig/include/asm-i386/cpufeature.h +++ linux/include/asm-i386/cpufeature.h @@ -52,6 +52,7 @@ #define X86_FEATURE_MP (1*32+19) /* MP Capable. */ #define X86_FEATURE_NX (1*32+20) /* Execute Disable */ #define X86_FEATURE_MMXEXT (1*32+22) /* AMD MMX extensions */ +#define X86_FEATURE_RDTSCP (1*32+27) /* RDTSCP */ #define X86_FEATURE_LM (1*32+29) /* Long Mode (x86-64) */ #define X86_FEATURE_3DNOWEXT (1*32+30) /* AMD 3DNow! extensions */ #define X86_FEATURE_3DNOW (1*32+31) /* 3DNow! */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [14/30] i386: Implement alternative_io for i386
Ported from x86-64.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
include/asm-i386/alternative.h | 15 +++
1 file changed, 15 insertions(+)
Index: linux/include/asm-i386/alternative.h
===
--- linux.orig/include/asm-i386/alternative.h
+++ linux/include/asm-i386/alternative.h
@@ -82,6 +82,21 @@ static inline void alternatives_smp_swit
"663:\n\t" newinstr "\n664:\n" /* replacement */\
".previous" :: "i" (feature), ##input)
+/* Like alternative_input, but with a single output argument */
+#define alternative_io(oldinstr, newinstr, feature, output, input...) \
+ asm volatile ("661:\n\t" oldinstr "\n662:\n"\
+ ".section .altinstructions,\"a\"\n" \
+ " .align 4\n"\
+ " .long 661b\n"/* label */ \
+ " .long 663f\n"/* new instruction */ \
+ " .byte %c[feat]\n"/* feature bit */ \
+ " .byte 662b-661b\n" /* sourcelen */ \
+ " .byte 664f-663f\n" /* replacementlen */ \
+ ".previous\n" \
+ ".section .altinstr_replacement,\"ax\"\n" \
+ "663:\n\t" newinstr "\n664:\n" /* replacement */ \
+ ".previous" : output : [feat] "i" (feature), ##input)
+
/*
* Alternative inline assembly for SMP.
*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [7/30] x86_64: Avoid overflows during apic timer calibration
From: David P. Reed <[EMAIL PROTECTED]>
- Use 64bit TSC calculations to avoid handling overflow
- Use 32bit unsigned arithmetic for the APIC timer. This
way overflows are handled correctly.
- Fix exit check of loop to account for apic timer counting down
Signed-off-by: [EMAIL PROTECTED]
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/apic.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
Index: linux/arch/x86_64/kernel/apic.c
===
--- linux.orig/arch/x86_64/kernel/apic.c
+++ linux/arch/x86_64/kernel/apic.c
@@ -839,14 +839,15 @@ static void setup_APIC_timer(unsigned in
static int __init calibrate_APIC_clock(void)
{
- int apic, apic_start, tsc, tsc_start;
+ unsigned apic, apic_start;
+ unsigned long tsc, tsc_start;
int result;
/*
* Put whatever arbitrary (but long enough) timeout
* value into the APIC clock, we just want to get the
* counter running for calibration.
*/
- __setup_APIC_LVTT(10);
+ __setup_APIC_LVTT(40);
apic_start = apic_read(APIC_TMCCT);
#ifdef CONFIG_X86_PM_TIMER
@@ -857,13 +858,13 @@ static int __init calibrate_APIC_clock(v
} else
#endif
{
- rdtscl(tsc_start);
+ rdtscll(tsc_start);
do {
apic = apic_read(APIC_TMCCT);
- rdtscl(tsc);
+ rdtscll(tsc);
} while ((tsc - tsc_start) < TICK_COUNT &&
- (apic - apic_start) < TICK_COUNT);
+ (apic_start - apic) < TICK_COUNT);
result = (apic_start - apic) * 1000L * tsc_khz /
(tsc - tsc_start);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [8/30] x86_64: Add vDSO for x86-64 with gettimeofday/clock_gettime/getcpu
This implements new vDSO for x86-64. The concept is similar
to the existing vDSOs on i386 and PPC. x86-64 has had static
vsyscalls before, but these are not flexible enough anymore.
A vDSO is a ELF shared library supplied by the kernel that is mapped into
user address space. The vDSO mapping is randomized for each process
for security reasons.
Doing this was needed for clock_gettime, because clock_gettime
always needs a syscall fallback and having one at a fixed
address would have made buffer overflow exploits too easy to write.
The vdso can be disabled with vdso=0
It currently includes a new gettimeofday implemention and optimized
clock_gettime(). The gettimeofday implementation is slightly faster
than the one in the old vsyscall. clock_gettime is significantly faster
than the syscall for CLOCK_MONOTONIC and CLOCK_REALTIME.
The new calls are generally faster than the old vsyscall.
TBD: add new benchmarks
Advantages over the old x86-64 vsyscalls:
- Extensible
- Randomized
- Cleaner
- Easier to virtualize (the old static address range previously causes
overhead e.g. for Xen because it has to create special page tables for it)
Weak points:
- glibc support still to be written
The VM interface is partly based on Ingo Molnar's i386 version.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
Documentation/kernel-parameters.txt |2
arch/x86_64/Makefile|3
arch/x86_64/ia32/ia32_binfmt.c |1
arch/x86_64/kernel/time.c |1
arch/x86_64/kernel/vmlinux.lds.S| 12 +++
arch/x86_64/kernel/vsyscall.c | 22 +
arch/x86_64/mm/init.c | 17
arch/x86_64/vdso/Makefile | 49
arch/x86_64/vdso/vclock_gettime.c | 120 +++
arch/x86_64/vdso/vdso-note.S| 25 ++
arch/x86_64/vdso/vdso-start.S |2
arch/x86_64/vdso/vdso.S |2
arch/x86_64/vdso/vdso.lds.S | 77
arch/x86_64/vdso/vextern.h | 16
arch/x86_64/vdso/vgetcpu.c | 50 +
arch/x86_64/vdso/vma.c | 137
arch/x86_64/vdso/voffset.h |1
arch/x86_64/vdso/vvar.c | 12 +++
include/asm-x86_64/auxvec.h |2
include/asm-x86_64/elf.h| 13 +++
include/asm-x86_64/mmu.h|1
include/asm-x86_64/pgtable.h|8 +-
include/asm-x86_64/vgtod.h | 29 +++
include/asm-x86_64/vsyscall.h |3
24 files changed, 583 insertions(+), 22 deletions(-)
Index: linux/arch/x86_64/ia32/ia32_binfmt.c
===
--- linux.orig/arch/x86_64/ia32/ia32_binfmt.c
+++ linux/arch/x86_64/ia32/ia32_binfmt.c
@@ -38,6 +38,7 @@
int sysctl_vsyscall32 = 1;
+#undef ARCH_DLINFO
#define ARCH_DLINFO do { \
if (sysctl_vsyscall32) { \
NEW_AUX_ENT(AT_SYSINFO, (u32)(u64)VSYSCALL32_VSYSCALL); \
Index: linux/arch/x86_64/kernel/vmlinux.lds.S
===
--- linux.orig/arch/x86_64/kernel/vmlinux.lds.S
+++ linux/arch/x86_64/kernel/vmlinux.lds.S
@@ -94,6 +94,9 @@ SECTIONS
.vsyscall_gtod_data : AT(VLOAD(.vsyscall_gtod_data))
{ *(.vsyscall_gtod_data) }
vsyscall_gtod_data = VVIRT(.vsyscall_gtod_data);
+ .vsyscall_clock : AT(VLOAD(.vsyscall_clock))
+ { *(.vsyscall_clock) }
+ vsyscall_clock = VVIRT(.vsyscall_clock);
.vsyscall_1 ADDR(.vsyscall_0) + 1024: AT(VLOAD(.vsyscall_1))
@@ -153,6 +156,8 @@ SECTIONS
. = ALIGN(4096); /* Init code and data */
__init_begin = .;
+
+
.init.text : AT(ADDR(.init.text) - LOAD_OFFSET) {
_sinittext = .;
*(.init.text)
@@ -190,6 +195,12 @@ SECTIONS
.exit.text : AT(ADDR(.exit.text) - LOAD_OFFSET) { *(.exit.text) }
.exit.data : AT(ADDR(.exit.data) - LOAD_OFFSET) { *(.exit.data) }
+/* vdso blob that is mapped into user space */
+ vdso_start = . ;
+ .vdso : AT(ADDR(.vdso) - LOAD_OFFSET) { *(.vdso) }
+ . = ALIGN(4096);
+ vdso_end = .;
+
#ifdef CONFIG_BLK_DEV_INITRD
. = ALIGN(4096);
__initramfs_start = .;
@@ -202,6 +213,7 @@ SECTIONS
.data.percpu : AT(ADDR(.data.percpu) - LOAD_OFFSET) { *(.data.percpu) }
__per_cpu_end = .;
. = ALIGN(4096);
+
__init_end = .;
. = ALIGN(4096);
Index: linux/arch/x86_64/mm/init.c
===
--- linux.orig/arch/x86_64/mm/init.c
+++ linux/arch/x86_64/mm/init.c
@@ -159,6 +159,14 @@ static __init void set_pte_phys(unsigned
__flush_tlb_one(vaddr);
}
+void __init
+set_kernel_map(void *vaddr,unsigned long len,unsigned long phys,pgprot_t prot)
+{
+ void *end = vaddr + ALIGN(len, PAGE_SIZE);
+ for (; vaddr < end; vaddr += PAGE_SIZE, phys += PAGE_SIZE)
+ set_pte_phys((unsigned long)vaddr, phys, prot);
+}
+
/* NOTE: this is meant to be run only at
[PATCH] [3/30] i386: Clean up NMI watchdog code
- Introduce a wd_ops structure
- Convert the various nmi watchdogs over to it
- This allows to split the perfctr reservation from the watchdog
setup cleanly.
- Do perfctr reservation globally as it should have always been
- Remove dead code referenced only by unused EXPORT_SYMBOLs
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
arch/i386/kernel/cpu/Makefile |2
arch/i386/kernel/cpu/perfctr-watchdog.c | 658 +
arch/i386/kernel/nmi.c | 829 ++--
include/asm-i386/nmi.h |8
4 files changed, 721 insertions(+), 776 deletions(-)
Index: linux/arch/i386/kernel/nmi.c
===
--- linux.orig/arch/i386/kernel/nmi.c
+++ linux/arch/i386/kernel/nmi.c
@@ -20,7 +20,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -28,30 +27,14 @@
#include
#include
#include
-#include
#include "mach_traps.h"
int unknown_nmi_panic;
int nmi_watchdog_enabled;
-/* perfctr_nmi_owner tracks the ownership of the perfctr registers:
- * evtsel_nmi_owner tracks the ownership of the event selection
- * - different performance counters/ event selection may be reserved for
- * different subsystems this reservation system just tries to coordinate
- * things a little
- */
-
-/* this number is calculated from Intel's MSR_P4_CRU_ESCR5 register and it's
- * offset from MSR_P4_BSU_ESCR0. It will be the max for all platforms (for
now)
- */
-#define NMI_MAX_COUNTER_BITS 66
-#define NMI_MAX_COUNTER_LONGS BITS_TO_LONGS(NMI_MAX_COUNTER_BITS)
-
-static DEFINE_PER_CPU(unsigned long, perfctr_nmi_owner[NMI_MAX_COUNTER_LONGS]);
-static DEFINE_PER_CPU(unsigned long, evntsel_nmi_owner[NMI_MAX_COUNTER_LONGS]);
-
static cpumask_t backtrace_mask = CPU_MASK_NONE;
+
/* nmi_active:
* >0: the lapic NMI watchdog is active, but can be disabled
* <0: the lapic NMI watchdog has not been set up, and cannot
@@ -63,203 +46,11 @@ atomic_t nmi_active = ATOMIC_INIT(0); /
unsigned int nmi_watchdog = NMI_DEFAULT;
static unsigned int nmi_hz = HZ;
-struct nmi_watchdog_ctlblk {
- int enabled;
- u64 check_bit;
- unsigned int cccr_msr;
- unsigned int perfctr_msr; /* the MSR to reset in NMI handler */
- unsigned int evntsel_msr; /* the MSR to select the events to handle */
-};
-static DEFINE_PER_CPU(struct nmi_watchdog_ctlblk, nmi_watchdog_ctlblk);
+static DEFINE_PER_CPU(short, wd_enabled);
/* local prototypes */
static int unknown_nmi_panic_callback(struct pt_regs *regs, int cpu);
-/* converts an msr to an appropriate reservation bit */
-static inline unsigned int nmi_perfctr_msr_to_bit(unsigned int msr)
-{
- /* returns the bit offset of the performance counter register */
- switch (boot_cpu_data.x86_vendor) {
- case X86_VENDOR_AMD:
- return (msr - MSR_K7_PERFCTR0);
- case X86_VENDOR_INTEL:
- if (cpu_has(&boot_cpu_data, X86_FEATURE_ARCH_PERFMON))
- return (msr - MSR_ARCH_PERFMON_PERFCTR0);
-
- switch (boot_cpu_data.x86) {
- case 6:
- return (msr - MSR_P6_PERFCTR0);
- case 15:
- return (msr - MSR_P4_BPU_PERFCTR0);
- }
- }
- return 0;
-}
-
-/* converts an msr to an appropriate reservation bit */
-static inline unsigned int nmi_evntsel_msr_to_bit(unsigned int msr)
-{
- /* returns the bit offset of the event selection register */
- switch (boot_cpu_data.x86_vendor) {
- case X86_VENDOR_AMD:
- return (msr - MSR_K7_EVNTSEL0);
- case X86_VENDOR_INTEL:
- if (cpu_has(&boot_cpu_data, X86_FEATURE_ARCH_PERFMON))
- return (msr - MSR_ARCH_PERFMON_EVENTSEL0);
-
- switch (boot_cpu_data.x86) {
- case 6:
- return (msr - MSR_P6_EVNTSEL0);
- case 15:
- return (msr - MSR_P4_BSU_ESCR0);
- }
- }
- return 0;
-}
-
-/* checks for a bit availability (hack for oprofile) */
-int avail_to_resrv_perfctr_nmi_bit(unsigned int counter)
-{
- int cpu;
- BUG_ON(counter > NMI_MAX_COUNTER_BITS);
- for_each_possible_cpu (cpu) {
- if (test_bit(counter, &per_cpu(perfctr_nmi_owner, cpu)[0]))
- return 0;
- }
- return 1;
-}
-
-/* checks the an msr for availability */
-int avail_to_resrv_perfctr_nmi(unsigned int msr)
-{
- unsigned int counter;
- int cpu;
-
- counter = nmi_perfctr_msr_to_bit(msr);
- BUG_ON(counter > NMI_MAX_COUNTER_BITS);
-
- for_each_possible_cpu (cpu) {
- if (test_bit(counter, &per_cpu(perfctr_nmi_owner, cpu)[0]))
- return 0;
- }
- return 1;
-}
-
-static int __reserve_perfctr_nmi(int cpu, unsigned int msr)
-{
- unsigned int
[PATCH] [11/30] i386: Drop -traditional in arch/i386/boot
Needed for followon patch Signed-off-by: Andi Kleen <[EMAIL PROTECTED]> --- arch/i386/boot/Makefile |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Index: linux/arch/i386/boot/Makefile === --- linux.orig/arch/i386/boot/Makefile +++ linux/arch/i386/boot/Makefile @@ -36,9 +36,9 @@ HOSTCFLAGS_build.o := $(LINUXINCLUDE) # --- $(obj)/zImage: IMAGE_OFFSET := 0x1000 -$(obj)/zImage: EXTRA_AFLAGS := -traditional $(SVGA_MODE) $(RAMDISK) +$(obj)/zImage: EXTRA_AFLAGS := $(SVGA_MODE) $(RAMDISK) $(obj)/bzImage: IMAGE_OFFSET := 0x10 -$(obj)/bzImage: EXTRA_AFLAGS := -traditional $(SVGA_MODE) $(RAMDISK) -D__BIG_KERNEL__ +$(obj)/bzImage: EXTRA_AFLAGS := $(SVGA_MODE) $(RAMDISK) -D__BIG_KERNEL__ $(obj)/bzImage: BUILDFLAGS := -b quiet_cmd_image = BUILD $@ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [2/30] x86_64: set node_possible_map at runtime - try 2
From: Suresh Siddha <[EMAIL PROTECTED]>
Set the node_possible_map at runtime on x86_64. On a non NUMA system,
num_possible_nodes() will now say '1'.
Signed-off-by: Suresh Siddha <[EMAIL PROTECTED]>
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
Cc: Eric Dumazet <[EMAIL PROTECTED]>
Cc: David Rientjes <[EMAIL PROTECTED]>
Cc: Christoph Lameter <[EMAIL PROTECTED]>
---
---
arch/x86_64/mm/k8topology.c |7 ++-
arch/x86_64/mm/numa.c | 10 --
arch/x86_64/mm/srat.c |8 +---
3 files changed, 15 insertions(+), 10 deletions(-)
Index: linux/arch/x86_64/mm/k8topology.c
===
--- linux.orig/arch/x86_64/mm/k8topology.c
+++ linux/arch/x86_64/mm/k8topology.c
@@ -49,11 +49,8 @@ int __init k8_scan_nodes(unsigned long s
int found = 0;
u32 reg;
unsigned numnodes;
- nodemask_t nodes_parsed;
unsigned dualcore = 0;
- nodes_clear(nodes_parsed);
-
if (!early_pci_allowed())
return -1;
@@ -102,7 +99,7 @@ int __init k8_scan_nodes(unsigned long s
nodeid, (base>>8)&3, (limit>>8) & 3);
return -1;
}
- if (node_isset(nodeid, nodes_parsed)) {
+ if (node_isset(nodeid, node_possible_map)) {
printk(KERN_INFO "Node %d already present. Skipping\n",
nodeid);
continue;
@@ -155,7 +152,7 @@ int __init k8_scan_nodes(unsigned long s
prevbase = base;
- node_set(nodeid, nodes_parsed);
+ node_set(nodeid, node_possible_map);
}
if (!found)
Index: linux/arch/x86_64/mm/numa.c
===
--- linux.orig/arch/x86_64/mm/numa.c
+++ linux/arch/x86_64/mm/numa.c
@@ -295,7 +295,7 @@ static int __init setup_node_range(int n
ret = -1;
}
nodes[nid].end = *addr;
- node_set_online(nid);
+ node_set(nid, node_possible_map);
printk(KERN_INFO "Faking node %d at %016Lx-%016Lx (%LuMB)\n", nid,
nodes[nid].start, nodes[nid].end,
(nodes[nid].end - nodes[nid].start) >> 20);
@@ -479,7 +479,7 @@ out:
* SRAT.
*/
remove_all_active_ranges();
- for_each_online_node(i) {
+ for_each_node_mask(i, node_possible_map) {
e820_register_active_regions(i, nodes[i].start >> PAGE_SHIFT,
nodes[i].end >> PAGE_SHIFT);
setup_node_bootmem(i, nodes[i].start, nodes[i].end);
@@ -494,20 +494,25 @@ void __init numa_initmem_init(unsigned l
{
int i;
+ nodes_clear(node_possible_map);
+
#ifdef CONFIG_NUMA_EMU
if (cmdline && !numa_emulation(start_pfn, end_pfn))
return;
+ nodes_clear(node_possible_map);
#endif
#ifdef CONFIG_ACPI_NUMA
if (!numa_off && !acpi_scan_nodes(start_pfn << PAGE_SHIFT,
end_pfn << PAGE_SHIFT))
return;
+ nodes_clear(node_possible_map);
#endif
#ifdef CONFIG_K8_NUMA
if (!numa_off && !k8_scan_nodes(start_pfn
[PATCH] [10/30] x86_64: Drop -traditional for arch/x86_64/boot
Follows i386 and useful cleanup. Signed-off-by: Andi Kleen <[EMAIL PROTECTED]> --- arch/x86_64/boot/Makefile |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux/arch/x86_64/boot/Makefile === --- linux.orig/arch/x86_64/boot/Makefile +++ linux/arch/x86_64/boot/Makefile @@ -36,7 +36,7 @@ subdir- := compressed/ #Let make clean # --- $(obj)/bzImage: IMAGE_OFFSET := 0x10 -$(obj)/bzImage: EXTRA_AFLAGS := -traditional $(SVGA_MODE) $(RAMDISK) -D__BIG_KERNEL__ +$(obj)/bzImage: EXTRA_AFLAGS := $(SVGA_MODE) $(RAMDISK) -D__BIG_KERNEL__ $(obj)/bzImage: BUILDFLAGS := -b quiet_cmd_image = BUILD $@ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [9/30] x86_64: Use symbolic CPU features in early CPUID check
Dead to magic numbers! Generated code is the same. Signed-off-by: Andi Kleen <[EMAIL PROTECTED]> --- arch/x86_64/kernel/verify_cpu.S | 23 --- 1 file changed, 16 insertions(+), 7 deletions(-) Index: linux/arch/x86_64/kernel/verify_cpu.S === --- linux.orig/arch/x86_64/kernel/verify_cpu.S +++ linux/arch/x86_64/kernel/verify_cpu.S @@ -30,18 +30,27 @@ * appropriately. Either display a message or halt. */ -verify_cpu: +#include +verify_cpu: pushfl # Save caller passed flags pushl $0 # Kill any dangerous flags popfl - /* minimum CPUID flags for x86-64 */ - /* see http://www.x86-64.org/lists/discuss/msg02971.html */ -#define SSE_MASK ((1<<25)|(1<<26)) -#define REQUIRED_MASK1 ((1<<0)|(1<<3)|(1<<4)|(1<<5)|(1<<6)|(1<<8)|\ - (1<<13)|(1<<15)|(1<<24)) -#define REQUIRED_MASK2 (1<<29) + /* minimum CPUID flags for x86-64 as defined by AMD */ +#define M(x) (1<<(x)) +#define M2(a,b) M(a)|M(b) +#define M4(a,b,c,d) M(a)|M(b)|M(c)|M(d) + +#define SSE_MASK \ + (M2(X86_FEATURE_XMM,X86_FEATURE_XMM2)) +#define REQUIRED_MASK1 \ + (M4(X86_FEATURE_FPU,X86_FEATURE_PSE,X86_FEATURE_TSC,X86_FEATURE_MSR)|\ +M4(X86_FEATURE_PAE,X86_FEATURE_CX8,X86_FEATURE_PGE,X86_FEATURE_CMOV)|\ +M(X86_FEATURE_FXSR)) +#define REQUIRED_MASK2 \ + (M(X86_FEATURE_LM - 32)) + pushfl # standard way to check for cpuid popl%eax movl%eax,%ebx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [4/30] x86_64: Use the 32bit wd_ops for 64bit too.
This mainly removes a lot of code, replacing it with calls into the new 32bit
perfctr-watchdog.c
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/Makefile |3
arch/x86_64/kernel/nmi.c| 678 ++--
include/asm-x86_64/nmi.h|9
3 files changed, 44 insertions(+), 646 deletions(-)
Index: linux/arch/x86_64/kernel/Makefile
===
--- linux.orig/arch/x86_64/kernel/Makefile
+++ linux/arch/x86_64/kernel/Makefile
@@ -9,7 +9,7 @@ obj-y := process.o signal.o entry.o trap
x8664_ksyms.o i387.o syscall.o vsyscall.o \
setup64.o bootflag.o e820.o reboot.o quirks.o i8237.o \
pci-dma.o pci-nommu.o alternative.o hpet.o tsc.o sched-clock.o \
- bugs.o
+ bugs.o perfctr-watchdog.o
obj-$(CONFIG_STACKTRACE) += stacktrace.o
obj-$(CONFIG_X86_MCE) += mce.o therm_throt.o
@@ -59,3 +59,4 @@ msr-$(subst m,y,$(CONFIG_X86_MSR)) += .
alternative-y += ../../i386/kernel/alternative.o
pcspeaker-y+= ../../i386/kernel/pcspeaker.o
sched-clock-y += ../../i386/kernel/sched-clock.o
+perfctr-watchdog-y += ../../i386/kernel/cpu/perfctr-watchdog.o
Index: linux/include/asm-x86_64/nmi.h
===
--- linux.orig/include/asm-x86_64/nmi.h
+++ linux/include/asm-x86_64/nmi.h
@@ -80,4 +80,13 @@ extern int unknown_nmi_panic;
void __trigger_all_cpu_backtrace(void);
#define trigger_all_cpu_backtrace() __trigger_all_cpu_backtrace()
+
+void lapic_watchdog_stop(void);
+int lapic_watchdog_init(unsigned nmi_hz);
+int lapic_wd_event(unsigned nmi_hz);
+unsigned lapic_adjust_nmi_hz(unsigned hz);
+int lapic_watchdog_ok(void);
+void disable_lapic_nmi_watchdog(void);
+void enable_lapic_nmi_watchdog(void);
+
#endif /* ASM_NMI_H */
Index: linux/arch/x86_64/kernel/nmi.c
===
--- linux.orig/arch/x86_64/kernel/nmi.c
+++ linux/arch/x86_64/kernel/nmi.c
@@ -27,28 +27,11 @@
#include
#include
#include
-#include
int unknown_nmi_panic;
int nmi_watchdog_enabled;
int panic_on_unrecovered_nmi;
-/* perfctr_nmi_owner tracks the ownership of the perfctr registers:
- * evtsel_nmi_owner tracks the ownership of the event selection
- * - different performance counters/ event selection may be reserved for
- * different subsystems this reservation system just tries to coordinate
- * things a little
- */
-
-/* this number is calculated from Intel's MSR_P4_CRU_ESCR5 register and it's
- * offset from MSR_P4_BSU_ESCR0. It will be the max for all platforms (for
now)
- */
-#define NMI_MAX_COUNTER_BITS 66
-#define NMI_MAX_COUNTER_LONGS BITS_TO_LONGS(NMI_MAX_COUNTER_BITS)
-
-static DEFINE_PER_CPU(unsigned, perfctr_nmi_owner[NMI_MAX_COUNTER_LONGS]);
-static DEFINE_PER_CPU(unsigned, evntsel_nmi_owner[NMI_MAX_COUNTER_LONGS]);
-
static cpumask_t backtrace_mask = CPU_MASK_NONE;
/* nmi_active:
@@ -63,191 +46,11 @@ int panic_on_timeout;
unsigned int nmi_watchdog = NMI_DEFAULT;
static unsigned int nmi_hz = HZ;
-struct nmi_watchdog_ctlblk {
- int enabled;
- u64 check_bit;
- unsigned int cccr_msr;
- unsigned int perfctr_msr; /* the MSR to reset in NMI handler */
- unsigned int evntsel_msr; /* the MSR to select the events to handle */
-};
-static DEFINE_PER_CPU(struct nmi_watchdog_ctlblk, nmi_watchdog_ctlblk);
+static DEFINE_PER_CPU(short, wd_enabled);
/* local prototypes */
static int unknown_nmi_panic_callback(struct pt_regs *regs, int cpu);
-/* converts an msr to an appropriate reservation bit */
-static inline unsigned int nmi_perfctr_msr_to_bit(unsigned int msr)
-{
- /* returns the bit offset of the performance counter register */
- switch (boot_cpu_data.x86_vendor) {
- case X86_VENDOR_AMD:
- return (msr - MSR_K7_PERFCTR0);
- case X86_VENDOR_INTEL:
- if (cpu_has(&boot_cpu_data, X86_FEATURE_ARCH_PERFMON))
- return (msr - MSR_ARCH_PERFMON_PERFCTR0);
- else
- return (msr - MSR_P4_BPU_PERFCTR0);
- }
- return 0;
-}
-
-/* converts an msr to an appropriate reservation bit */
-static inline unsigned int nmi_evntsel_msr_to_bit(unsigned int msr)
-{
- /* returns the bit offset of the event selection register */
- switch (boot_cpu_data.x86_vendor) {
- case X86_VENDOR_AMD:
- return (msr - MSR_K7_EVNTSEL0);
- case X86_VENDOR_INTEL:
- if (cpu_has(&boot_cpu_data, X86_FEATURE_ARCH_PERFMON))
- return (msr - MSR_ARCH_PERFMON_EVENTSEL0);
- else
- return (msr - MSR_P4_BSU_ESCR0);
- }
- return 0;
-}
-
-/* checks for a bit availability (hack for oprofile) */
-int avail_to_resrv_perfctr_nmi_bit(unsigned i
[PATCH] [5/30] x86_64: Define IGNORE_IOCTL() macro for compat_ioctls
Define a new IGNORE_IOCTL() to let a compat ioctl not be warned about even when
it is not implemented.
This is the same as COMPATIBLE_IOCTL internally, but better self documentng.
Valid reasons to use this:
- It is implemented with ->compat_ioctl on some device, but programs
call it on others too.
- The ioctl is not implemented in the native kernel, but programs
call it commonly anyways.
Most other reasons are not valid.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
fs/compat_ioctl.c |8
1 file changed, 8 insertions(+)
Index: linux/fs/compat_ioctl.c
===
--- linux.orig/fs/compat_ioctl.c
+++ linux/fs/compat_ioctl.c
@@ -2396,6 +2396,14 @@ lp_timeout_trans(unsigned int fd, unsign
#define ULONG_IOCTL(cmd) \
{ (cmd), (ioctl_trans_handler_t)sys_ioctl },
+/* ioctl should not be warned about even if it's not implemented.
+ Valid reasons to use this:
+ - It is implemented with ->compat_ioctl on some device, but programs
+ call it on others too.
+ - The ioctl is not implemented in the native kernel, but programs
+ call it commonly anyways.
+ Most other reasons are not valid. */
+#define IGNORE_IOCTL(cmd) COMPATIBLE_IOCTL(cmd)
struct ioctl_trans ioctl_start[] = {
#include
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [6/30] x86_64: Shut up 32bit emulation for SIOCGIFCOUNT
The kernel doesn't implement it, but some programs like java use it anyways. Shut the code up. Signed-off-by: Andi Kleen <[EMAIL PROTECTED]> --- fs/compat_ioctl.c |2 ++ 1 file changed, 2 insertions(+) Index: linux/fs/compat_ioctl.c === --- linux.orig/fs/compat_ioctl.c +++ linux/fs/compat_ioctl.c @@ -2602,6 +2602,8 @@ HANDLE_IOCTL(SIOCGIWENCODEEXT, do_wirele HANDLE_IOCTL(SIOCSIWPMKSA, do_wireless_ioctl) HANDLE_IOCTL(SIOCSIFBR, old_bridge_ioctl) HANDLE_IOCTL(SIOCGIFBR, old_bridge_ioctl) +/* Not implemented in the native kernel */ +IGNORE_IOCTL(SIOCGIFCOUNT) HANDLE_IOCTL(RTC_IRQP_READ32, rtc_ioctl) HANDLE_IOCTL(RTC_IRQP_SET32, rtc_ioctl) HANDLE_IOCTL(RTC_EPOCH_READ32, rtc_ioctl) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage
On Mon, 2007-04-30 at 20:45 -0700, H. Peter Anvin wrote: > Rusty Russell wrote: > > > > It'd be nicer if there were a "struct boot_params" declaration, but we > > can't have everything. > > It's in my patchset-under-development. Ah ha: excellent! > > +typedef unsigned long long u64; > > typedef uint32_t u32; > > typedef uint16_t u16; > > typedef uint8_t u8; > > Why not uint64_t to go along with all the other defines? Because then it's a PITA to printf(): x86-64 has uint64_t as "unsigned long". So the lguest64 guys will add all kinds of horrible casts. This has the same effect, but ironically is more portable. Rusty. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: How to make mmap'ed kernel buffer non-cacheable
Hi Alan,Nick Thanks for your inputs. I was able to solve the problem of mapping kernel buffer to user space. Just FYI, I am working on a sh4 based architecture proprietary board with Linux kernel 2.6.17.3 Initially I was adopting the following approach: 1.The kernel thread was copying some data and waiting on a semaphore for the user task to make an ioctl into the kernel space and relieve the wait. 2. Then the user task was getting spawned and taking the data from kernel. ---> This was resulting in some initial data drop coz the kernel task was overwhelming and outspeeding the user task (Maybe someone can explain how) How I solved the problem? Instead of making the kernel wait for the user task, I reversed the sequence and did not let the kernel task be activated till the user task was spawned and waiting in kernel space(after making ioctl) for the kernel task. Then I started the kernel task and the problem of data dropping was resolved. In continuation to this, I have another query: As mentioned above, If there is a kernel task waiting on a semaphore (maybe even in hung state) and I wish to kill the kernel task from user space by making an ioctl call into the kernel, then how is it possible? Is it feasible at all? Regards, Bhuvan On 20 Apr, 14:20, Bhuvan Kumar MITTAL <[EMAIL PROTECTED]> wrote: > Hi, > I am working on an audio device driver development on Linux. I have > a kernel buffer which I have mapped to user space using mmap call from > user space. My problem is that the data which comes to the kernel > buffer is getting dropped in user space and I get only 50-60% of the > data which is randomly ordered. The user to kernel level buffer > address translation code is fine and I suspect this data dropping is > occurring coz the kernel buffer is cacheable. Please suggest me some > way of making the entire buffer non cacheable. I am stuck on this for quite a > while now. You can use rdmsr() in your driver to check if the page attribute table MSR is available, then find and/or add the right entry in the table to set in each page's flags. This is documented in the Intel IA-32 Intel Architecture Software Developer's Manuals at intel.com. -Original Message- From: Nick Piggin [mailto:[EMAIL PROTECTED] Sent: Monday, April 23, 2007 9:56 AM To: Bhuvan Kumar MITTAL Cc: 'Alan Cox'; linux-kernel@vger.kernel.org Subject: Re: How to make mmap'ed kernel buffer non-cacheable Bhuvan Kumar MITTAL wrote: > Hi Alan, > > I believe that dma_alloc_coherent will mark the kernel buffer as uncached at > alocation time. > But that is not my intention. I have mapped some user space memory to the > kernel buffer and I wish to ensure that the contents of both are coherent and > correctly ordered. > > In other words I wish to flush the contents of the kernel buffer to user > space as soon as new data is available in my kernel buffer. How to do that? > Will doing mysnc from the user space help? msync is only for pagecache. If you modify user mapped RAM from the kernel, or wish to read user modified RAM from the kernel, you should issue a flush_dcache_page after and before, respectively. See Documentation/cachetlb.h. Does that fix it? What are the details of your platform? -- SUSE Labs, Novell Inc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [24/30] x86_64: Shut up warnings for vfat compat ioctls on other file systems
vfat implements compat handlers for these ioctls, but when they
were executed on other file systems the kernel would still complain
about an unknown compat ioctl. Just declare them as compatible
and let them be rejected when not needed by the normal path.
This makes wine runs a lot quieter
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
fs/compat_ioctl.c |9 +
1 file changed, 9 insertions(+)
Index: linux/fs/compat_ioctl.c
===
--- linux.orig/fs/compat_ioctl.c
+++ linux/fs/compat_ioctl.c
@@ -2627,6 +2627,15 @@ COMPATIBLE_IOCTL(LPRESET)
/*LPGETSTATS not implemented, but no kernels seem to compile it in anyways*/
COMPATIBLE_IOCTL(LPGETFLAGS)
HANDLE_IOCTL(LPSETTIMEOUT, lp_timeout_trans)
+
+/* fat 'r' ioctls. These are handled by fat with ->compat_ioctl,
+ but we don't want warnings on other file systems. So declare
+ them as compatible here. */
+#define VFAT_IOCTL_READDIR_BOTH32 _IOR('r', 1, struct compat_dirent[2])
+#define VFAT_IOCTL_READDIR_SHORT32 _IOR('r', 2, struct compat_dirent[2])
+
+IGNORE_IOCTL(VFAT_IOCTL_READDIR_BOTH32)
+IGNORE_IOCTL(VFAT_IOCTL_READDIR_SHORT32)
};
int ioctl_table_size = ARRAY_SIZE(ioctl_start);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [30/30] x86_64: Add missing !X86_PAE dependincy to the 2G/2G split.
From: [EMAIL PROTECTED] When in PAE mode we require that the user kernel divide to be on a 1G boundary. The 2G/2G split does not have that property so require !X86_PAE Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]> --- arch/i386/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/i386/Kconfig b/arch/i386/Kconfig index 1a94a73..80003de 100644 --- a/arch/i386/Kconfig +++ b/arch/i386/Kconfig @@ -570,6 +570,7 @@ choice depends on !HIGHMEM bool "3G/1G user/kernel split (for full 1G low memory)" config VMSPLIT_2G + depends on !X86_PAE bool "2G/2G user/kernel split" config VMSPLIT_1G bool "1G/3G user/kernel split" -- 1.5.1.1.181.g2de0 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [27/30] i386: white space fixes in i387.h
From: Jan Kiszka <[EMAIL PROTECTED]>
Signed-off-by: Jan Kiszka <[EMAIL PROTECTED]>
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
include/asm-i386/i387.h |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Index: linux/include/asm-i386/i387.h
===
--- linux.orig/include/asm-i386/i387.h
+++ linux/include/asm-i386/i387.h
@@ -83,8 +83,8 @@ static inline void __save_init_fpu( stru
#define __clear_fpu( tsk ) \
do { \
- if (task_thread_info(tsk)->status & TS_USEDFPU) { \
- asm volatile("fnclex ; fwait"); \
+ if (task_thread_info(tsk)->status & TS_USEDFPU) { \
+ asm volatile("fnclex ; fwait"); \
task_thread_info(tsk)->status &= ~TS_USEDFPU; \
stts(); \
} \
@@ -113,7 +113,7 @@ static inline void save_init_fpu( struct
__clear_fpu( tsk ); \
preempt_enable(); \
} while (0)
- \
+
/*
* FPU state interaction...
*/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [29/30] x86_64: Don't exclude asm-offsets.c in Documentation/dontdiff
asm-offsets.c is valid source code and needs to be diffed. Signed-off-by: Andi Kleen <[EMAIL PROTECTED]> --- Documentation/dontdiff |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Index: linux/Documentation/dontdiff === --- linux.orig/Documentation/dontdiff +++ linux/Documentation/dontdiff @@ -55,8 +55,8 @@ aic7*seq.h* aicasm aicdb.h* asm -asm-offsets.* -asm_offsets.* +asm-offsets.h +asm_offsets.h autoconf.h* bbootsect bin2c - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [28/30] i386: avoid redundant preempt_disable in __unlazy_fpu
From: Jan Kiszka <[EMAIL PROTECTED]>
There are two callers of __unlazy_fpu, unlazy_fpu and __switch_to, and
none of them appear to require additional preempt_disable/enable here.
Let's open-code save_init_fpu in __unlazy_fpu to save a few ops.
Signed-off-by: Jan Kiszka <[EMAIL PROTECTED]>
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
include/asm-i386/i387.h | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
Index: linux/include/asm-i386/i387.h
===
--- linux.orig/include/asm-i386/i387.h
+++ linux/include/asm-i386/i387.h
@@ -74,11 +74,12 @@ static inline void __save_init_fpu( stru
task_thread_info(tsk)->status &= ~TS_USEDFPU;
}
-#define __unlazy_fpu( tsk ) do { \
- if (task_thread_info(tsk)->status & TS_USEDFPU) \
- save_init_fpu( tsk ); \
- else\
- tsk->fpu_counter = 0; \
+#define __unlazy_fpu( tsk ) do { \
+ if (task_thread_info(tsk)->status & TS_USEDFPU) { \
+ __save_init_fpu(tsk); \
+ stts(); \
+ } else \
+ tsk->fpu_counter = 0; \
} while (0)
#define __clear_fpu( tsk ) \
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage
Rusty Russell <[EMAIL PROTECTED]> writes: > On Mon, 2007-04-30 at 09:34 -0600, Eric W. Biederman wrote: >> Reading this it occurs to me what I object to wasn't that clear. >> >> I have no problem with the testing of %cs to see if we are not in ring0. >> That part while a little odd is fine, and we will certainly need a test >> to skip the protected instructions in head.S >> >> What I object to in particular is having (struct lguest_info?) instead >> of using the standard format for kernel parameters pointed to in %esi. > > Here's a rough patch to see what it looks like from an lguest POV. It's > an improvement in many ways: I chose to hardcode the search for matching > backend rather than use paravirt_probe-style magic. Cool. > It'd be nicer if there were a "struct boot_params" declaration, but we > can't have everything. Well it will come. I have an old one in kexec-tools and HPA looks like he has one in his C rewrite. I'm not going to worry about going farther until the patches in flight settle down a little bit, but this looks promising. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [0/30] x86 candidate patches for review VII: VDSO, CPUID, NMI watchdog, MCE, misc
The last batch of x86 patches for .22 to review. This one contains various patches that haven't hit l-k yet. Please review closely. - Finally vDSO support for x86-64 * glibc support still missing unfortunately - New early CPUID checking for i386 - Restructured NMI watchdog code - Dynamic MCE polling interval adaption from Tim Hockin - Some NUMA changes - Use RDTSCP for synchronous get_cycles if possible - Fix APIC timer calibration on x86-64 (stable candidate too) - Drop CONFIG_REORDER as announced earlier - Misc stuff Happy reviewing! -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [1/30] x86_64: Dynamically adjust machine check interval
From: Tim Hockin <[EMAIL PROTECTED]>
Background:
We've found that MCEs (specifically DRAM SBEs) tend to come in bunches,
especially when we are trying really hard to stress the system out. The
current MCE poller uses a static interval which does not care whether it
has or has not found MCEs recently.
Description:
This patch makes the MCE poller adjust the polling interval dynamically.
If we find an MCE, poll 2x faster (down to 10 ms). When we stop finding
MCEs, poll 2x slower (up to check_interval seconds). The check_interval
tunable becomes the max polling interval. The "Machine check events
logged" printk() is rate limited to the check_interval, which should be
identical behavior to the old functionality.
Result:
If you start to take a lot of correctable errors (not exceptions), you
log them faster and more accurately (less chance of overflowing the MCA
registers). If you don't take a lot of errors, you will see no change.
Alternatives:
I considered simply reducing the polling interval to 10 ms immediately
and keeping it there as long as we continue to find errors. This felt a
bit heavy handed, but does perform significantly better for the default
check_interval of 5 minutes (we're using a few seconds when testing for
DRAM errors). I could be convinced to go with this, if anyone felt it
was not too aggressive.
Testing:
I used an error-injecting DIMM to create lots of correctable DRAM errors
and verified that the polling interval accelerates. The printk() only
happens once per check_interval seconds.
Patch:
This patch is against 2.6.21-rc7.
Signed-Off-By: Tim Hockin <[EMAIL PROTECTED]>
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
Documentation/x86_64/machinecheck |7 ++-
arch/x86_64/kernel/mce.c | 32
2 files changed, 30 insertions(+), 9 deletions(-)
Index: linux/Documentation/x86_64/machinecheck
===
--- linux.orig/Documentation/x86_64/machinecheck
+++ linux/Documentation/x86_64/machinecheck
@@ -36,7 +36,12 @@ between all CPUs.
check_interval
How often to poll for corrected machine check errors, in seconds
- (Note output is hexademical). Default 5 minutes.
+ (Note output is hexademical). Default 5 minutes. When the poller
+ finds MCEs it triggers an exponential speedup (poll more often) on
+ the polling interval. When the poller stops finding MCEs, it
+ triggers an exponential backoff (poll less often) on the polling
+ interval. The check_interval variable is both the initial and
+ maximum polling interval.
tolerant
Tolerance level. When a machine check exception occurs for a non
Index: linux/arch/x86_64/kernel/mce.c
===
--- linux.orig/arch/x86_64/kernel/mce.c
+++ linux/arch/x86_64/kernel/mce.c
@@ -323,10 +323,13 @@ void mce_log_therm_throt_event(unsigned
#endif /* CONFIG_X86_MCE_INTEL */
/*
- * Periodic polling timer for "silent" machine check errors.
+ * Periodic polling timer for "silent" machine check errors. If the
+ * poller finds an MCE, poll 2x faster. When the poller finds no more
+ * errors, poll 2x slower (up to check_interval seconds).
*/
static int check_interval = 5 * 60; /* 5 minutes */
+static int next_interval; /* in jiffies */
static void mcheck_timer(struct work_struct *work);
static DECLARE_DELAYED_WORK(mcheck_work, mcheck_timer);
@@ -339,7 +342,6 @@ static void mcheck_check_cpu(void *info)
static void mcheck_timer(struct work_struct *work)
{
on_each_cpu(mcheck_check_cpu, NULL, 1, 1);
- schedule_delayed_work(&mcheck_work, check_interval * HZ);
/*
* It's ok to read stale data here for notify_user and
@@ -349,17 +351,30 @@ static void mcheck_timer(struct work_str
* writes.
*/
if (notify_user && console_logged) {
+ static unsigned long last_print;
+ unsigned long now = jiffies;
+
+ /* if we logged an MCE, reduce the polling interval */
+ next_interval = max(next_interval/2, HZ/100);
notify_user = 0;
clear_bit(0, &console_logged);
- printk(KERN_INFO "Machine check events logged\n");
+ if (time_after_eq(now, last_print + (check_interval*HZ))) {
+ last_print = now;
+ printk(KERN_INFO "Machine check events logged\n");
+ }
+ } else {
+ next_interval = min(next_interval*2, check_interval*HZ);
}
+
+ schedule_delayed_work(&mcheck_work, next_interval);
}
static __init int periodic_mcheck_init(void)
{
- if (check_interval)
- schedule_delayed_work(&mcheck_work, check_interval*HZ);
+ next_interval = check_interval * HZ;
+ if (next_interval)
+ schedule_delayed_work(&mcheck_work, ne
Re: Natsemi DP83815 driver spaming
On Mon, 30 Apr 2007 22:58:47 +0200 Rafał Bilski <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I have Wyse 3360SE terminal running Linux 2.6.21-rc7. Everything
> works great with one small exception. Natsemi DP83815 driver is
> filling log with:
> > ezri user.info kernel: eth0: DSPCFG accepted after 0 usec.
> > ezri user.notice kernel: eth0: Wake-up event 0x8a
> > ezri user.info kernel: eth0: Setting full-duplex based on negotiated link
> > capability.
> every 5 seconds. I can comment out these messages, but I would
> like to turn off the source of wake up event. It is a bit
> strange to see wakeup event on running system.
>
> Please CC me.
>
> Thank You
> Rafał
>
> natsemi dp8381x driver, version 2.1, Sept 11, 2006
> originally by Donald Becker <[EMAIL PROTECTED]>
> http://www.scyld.com/network/natsemi.html
> 2.4.x kernel port by Jeff Garzik, Tjeerd Mulder
> PCI: Setting latency timer of device :00:0f.0 to 64
> natsemi eth0: NatSemi DP8381[56] at 0x1001 (:00:0f.0),
> 00:80:64:10:c6:09, IRQ 10, port TP.
>
> 00:0f.0 Ethernet controller: National Semiconductor Corporation DP83815
> (MacPhyter) Ethernet Controller
> Subsystem: National Semiconductor Corporation DP83815 (MacPhyter)
> Ethernet Controller
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B-
> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
> SERR-Latency: 64 (2750ns min, 13000ns max)
> Interrupt: pin A routed to IRQ 10
> Region 0: I/O ports at f800 [size=256]
> Region 1: Memory at 1001 (32-bit, non-prefetchable) [size=4K]
> [virtual] Expansion ROM at 1000 [disabled] [size=64K]
> Capabilities: [40] Power Management version 2
> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=320mA
> PME(D0+,D1+,D2+,D3hot+,D3cold+)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME+
>
>
It seems to be repeatedly setting the same duplex setting. The closest
thing I can see in there in recent times is
68c90166e4aaa15ddcdd4778ad30bfb8b32534be, "Add support for using MII port
with no PHY".
Does applying the below backout patch fix things?
diff -puN drivers/net/natsemi.c~a drivers/net/natsemi.c
--- a/drivers/net/natsemi.c~a
+++ a/drivers/net/natsemi.c
@@ -573,8 +573,6 @@ struct netdev_private {
u32 intr_status;
/* Do not touch the nic registers */
int hands_off;
- /* Don't pay attention to the reported link state. */
- int ignore_phy;
/* external phy that is used: only valid if dev->if_port != PORT_TP */
int mii;
int phy_addr_external;
@@ -703,10 +701,7 @@ static void __devinit natsemi_init_media
struct netdev_private *np = netdev_priv(dev);
u32 tmp;
- if (np->ignore_phy)
- netif_carrier_on(dev);
- else
- netif_carrier_off(dev);
+ netif_carrier_off(dev);
/* get the initial settings from hardware */
tmp= mdio_read(dev, MII_BMCR);
@@ -816,13 +811,8 @@ static int __devinit natsemi_probe1 (str
np->hands_off = 0;
np->intr_status = 0;
np->eeprom_size = natsemi_pci_info[chip_idx].eeprom_size;
- if (natsemi_pci_info[chip_idx].flags & NATSEMI_FLAG_IGNORE_PHY)
- np->ignore_phy = 1;
- else
- np->ignore_phy = 0;
/* Initial port:
-* - If configured to ignore the PHY set up for external.
* - If the nic was configured to use an external phy and if find_mii
* finds a phy: use external port, first phy that replies.
* - Otherwise: internal port.
@@ -830,7 +820,7 @@ static int __devinit natsemi_probe1 (str
* The address would be used to access a phy over the mii bus, but
* the internal phy is accessed through mapped registers.
*/
- if (np->ignore_phy || readl(ioaddr + ChipConfig) & CfgExtPhy)
+ if (readl(ioaddr + ChipConfig) & CfgExtPhy)
dev->if_port = PORT_MII;
else
dev->if_port = PORT_TP;
@@ -840,9 +830,7 @@ static int __devinit natsemi_probe1 (str
if (dev->if_port != PORT_TP) {
np->phy_addr_external = find_mii(dev);
- /* If we're ignoring the PHY it doesn't matter if we can't
-* find one. */
- if (!np->ignore_phy && np->phy_addr_external == PHY_ADDR_NONE) {
+ if (np->phy_addr_external == PHY_ADDR_NONE) {
dev->if_port = PORT_TP;
np->phy_addr_external = PHY_ADDR_INTERNAL;
}
@@ -908,8 +896,6 @@ static int __devinit natsemi_probe1 (str
printk("%02x, IRQ %d", dev->dev_addr[i], irq);
if (dev->if_port == PORT_TP)
printk(", port TP.\n");
- else if (np->ignore_phy)
- printk(", port MII, ignoring PHY\n");
else
Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header.
On Mon, Apr 30, 2007 at 05:17:07PM +0200, Andi Kleen wrote: > On Monday 30 April 2007 17:12:39 Eric W. Biederman wrote: > > > > Currently because vmlinux does not reflect that the kernel is relocatable > > we still have to support CONFIG_PHYSICAL_START. So this patch adds a small > > c program to do what we cannot do with a linker script set the elf header > > type to ET_DYN. > > > > Since last time I have fixed the type to be in my code ET_DYN (oops), > > and verified this works with kexec. I realized while testing that we > > don't have anyway of identifying a kernel vmlinux as linux so we > > probably want to add an ELF note but that will be another patch. > > The patch is ok for me, but does it pass Vivek's usual testing? I am facing one issue with this patch. gdb can not analyze the resulting kernel core file. Looks like gdb treats vmlinux differently if ELF header type is "ET_DYN". It reads the symbol values incorrectly. For example, symbol value of "panic_timeout" is 0x808a1fa8 but gdb somehow things that it is 0x008aaebf. Looks like it is performing some relocation. I am using GNU gdb Red Hat Linux (6.5-5.fc6rh). Thanks Vivek - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
On Mon, Apr 30, 2007 at 06:33:09PM -0700, H. Peter Anvin wrote: >Hi all, > >I'm rewriting the i386 setup code in C, instead of assembly, and before >I spend a very large amount of time translating all the various >card-specific probes, I want to ask the following question... > >Does *anyone* care about these anymore? I think this is a good work, but it is not easy. Hope you can do that well. ;) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
Eric W. Biederman wrote: > > I would be very surprised if the high volume commodity boards have > exceeded 8 megabits. > Most of the high-capacity chips are used on laptops, not conventional motherboards. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage
Rusty Russell wrote: > > It'd be nicer if there were a "struct boot_params" declaration, but we > can't have everything. It's in my patchset-under-development. (Preview snapshot: http://userweb.kernel.org/~hpa/setup-snapshot-2007.04.30.patch) > diff -r 9a673a220ad6 Documentation/lguest/lguest.c > --- a/Documentation/lguest/lguest.c Mon Apr 30 20:10:26 2007 +1000 > +++ b/Documentation/lguest/lguest.c Tue May 01 13:19:02 2007 +1000 > @@ -30,10 +30,12 @@ > #include > #include > #include > +typedef unsigned long long u64; > typedef uint32_t u32; > typedef uint16_t u16; > typedef uint8_t u8; Why not uint64_t to go along with all the other defines? -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
"H. Peter Anvin" <[EMAIL PROTECTED]> writes: > Eric W. Biederman wrote: >> Andi Kleen <[EMAIL PROTECTED]> writes: >> Not that the x86 BIOS is bad. It is nearly a marvel in it's simplicity and ubiquitousness, >>> Simplicity? That must be why x86 motherbords are shipping with (compressed) >>> 8MB BIOS flash chips now. >> >> Those would be 8 megabit chips, and those would be server motherboards >> you are looking. Most likely the ones that are starting to think ahead >> to EFI support. >> > > No, 4-8 MB chips are starting to be deployed, but the bulk is for > OS-less applications. I don't doubt that there are some rare systems with very large capacity flash chips. However the size of all BIOS chips are measured in bits. Anyone talking about the capacity of BIOS chips in bytes and not bits always raises a red flag with me because that is a very common mistake. I would be very surprised if the high volume commodity boards have exceeded 8 megabits. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage
On Mon, 2007-04-30 at 09:34 -0600, Eric W. Biederman wrote:
> Reading this it occurs to me what I object to wasn't that clear.
>
> I have no problem with the testing of %cs to see if we are not in ring0.
> That part while a little odd is fine, and we will certainly need a test
> to skip the protected instructions in head.S
>
> What I object to in particular is having (struct lguest_info?) instead
> of using the standard format for kernel parameters pointed to in %esi.
Here's a rough patch to see what it looks like from an lguest POV. It's
an improvement in many ways: I chose to hardcode the search for matching
backend rather than use paravirt_probe-style magic.
It'd be nicer if there were a "struct boot_params" declaration, but we
can't have everything.
Cheers,
Rusty.
diff -r 9a673a220ad6 Documentation/lguest/lguest.c
--- a/Documentation/lguest/lguest.c Mon Apr 30 20:10:26 2007 +1000
+++ b/Documentation/lguest/lguest.c Tue May 01 13:19:02 2007 +1000
@@ -30,10 +30,12 @@
#include
#include
#include
+typedef unsigned long long u64;
typedef uint32_t u32;
typedef uint16_t u16;
typedef uint8_t u8;
#include "../../include/linux/lguest_launcher.h"
+#include "../../include/asm-i386/e820.h"
#define PAGE_PRESENT 0x7 /* Present, RW, Execute */
#define NET_PEERNUM 1
@@ -915,10 +917,10 @@ static void usage(void)
int main(int argc, char *argv[])
{
- unsigned long mem, pgdir, start, page_offset;
+ unsigned long mem, pgdir, start, page_offset, initrd_size = 0;
int c, lguest_fd, waker_fd;
struct device_list device_list;
- struct lguest_boot_info *boot = (void *)0;
+ void *boot = (void *)0;
const char *initrd_name = NULL;
device_list.max_infd = -1;
@@ -966,15 +968,24 @@ int main(int argc, char *argv[])
map_device_descriptors(&device_list, mem);
/* Map the initrd image if requested */
- if (initrd_name)
- boot->initrd_size = load_initrd(initrd_name, mem);
+ if (initrd_name) {
+ initrd_size = load_initrd(initrd_name, mem);
+ *(unsigned long *)(boot+0x218) = mem - initrd_size;
+ *(unsigned long *)(boot+0x21c) = initrd_size;
+ }
/* Set up the initial linar pagetables. */
- pgdir = setup_pagetables(mem, boot->initrd_size, page_offset);
-
- /* Give the guest the boot information it needs. */
- concat(boot->cmdline, argv+optind+2);
- boot->max_pfn = mem/getpagesize();
+ pgdir = setup_pagetables(mem, initrd_size, page_offset);
+
+ /* E820 memory map: ours is a simple, single region. */
+ *(char*)(boot+E820NR) = 1;
+ *((struct e820entry *)(boot+E820MAP))
+ = ((struct e820entry) { 0, mem, E820_RAM });
+ /* Command line pointer and command line (at 4096) */
+ *(void **)(boot + 0x228) = boot + 4096;
+ concat(boot + 4096, argv+optind+2);
+ /* Paravirt type: 1 == lguest */
+ *(int *)(boot + 0x23c) = 1;
lguest_fd = tell_kernel(pgdir, start, page_offset);
waker_fd = setup_waker(&device_list);
diff -r 9a673a220ad6 arch/i386/kernel/head.S
--- a/arch/i386/kernel/head.S Mon Apr 30 20:10:26 2007 +1000
+++ b/arch/i386/kernel/head.S Tue May 01 12:29:55 2007 +1000
@@ -504,34 +504,17 @@ ignore_int:
#ifdef CONFIG_PARAVIRT
startup_paravirt:
cld
+ movl %esi, %eax
+ addl $__PAGE_OFFSET, %eax
movl $(init_thread_union+THREAD_SIZE),%esp
- /* We take pains to preserve all the regs. */
- pushl %edx
- pushl %ecx
- pushl %eax
-
- pushl $__start_paravirtprobe
-1:
- movl0(%esp), %eax
- cmpl$__stop_paravirtprobe, %eax
- je unhandled_paravirt
- pushl (%eax)
- movl8(%esp), %eax
- call*(%esp)
- popl%eax
-
- movl4(%esp), %eax
- movl8(%esp), %ecx
- movl12(%esp), %edx
-
- addl$4, (%esp)
- jmp 1b
-
-unhandled_paravirt:
+#ifdef CONFIG_LGUEST_GUEST
+ cmpl$1, 0x23c(%eax)
+ je lguest_init
+#endif
/* Nothing wanted us: we're screwed. */
ud2
-#endif
+#endif /* CONFIG_PARAVIRT */
/*
* Real beginning of normal "text" segment
diff -r 9a673a220ad6 drivers/lguest/lguest.c
--- a/drivers/lguest/lguest.c Mon Apr 30 20:10:26 2007 +1000
+++ b/drivers/lguest/lguest.c Tue May 01 13:28:06 2007 +1000
@@ -53,7 +53,6 @@ struct lguest_data lguest_data = {
.blocked_interrupts = { 1 }, /* Block timer interrupts */
};
struct lguest_device_desc *lguest_devices;
-static __initdata const struct lguest_boot_info *boot = __va(0);
static enum paravirt_lazy_mode lazy_mode;
static void lguest_lazy_mode(enum paravirt_lazy_mode mode)
@@ -378,8 +377,7 @@ static __init char *lguest_memory_setup(
/* We do this here because lockcheck barfs if before start_kernel */
atomic_notifier_chain_register(&panic_notifier_list, &paniced);
- e820
Re: arch/i386/boot rewrite, and all the hard-coded video cards
Andi Kleen wrote: > > At least my Asus board with 8Mb flash doesn't have anything called that. > There is also no special preboot environment > > iirc Asus ships dual BIOS though, but even half that compressed is a lot. > 8 Mb or 8 MB? Big difference... So you have 512K worth of compressed code, most of which is running the configuration menus and code to do initialization and setup of the runtime environment (build tables, and so on.) That's not really BIOS, per se, in the sense of an interface; any firmware has to do that stuff no matter what. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.6.21: Kernel won't boot with either/both of CONFIG_NO_HZ, CONFIG_HIGH_RES_TIMERS
Daniel Walker wrote: I'm interested in which clocksource is getting used, which is in the boot log. Well then, send me a patch that dumps that information out just before it locks up. We know (first post in this thread) that the lockup occurs just after these two messages: "switched to high resolution mode on cpu 1" "switched to high resolution mode on cpu 0" So just dump out anything else you need to see at the same time, and it'll still be on my screen when the darned thing locks up. Simple, eh. We both get to run around a treadmill this way. ;) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [NFS] [PATCH] RPC: add wrapper for svc_reserve to account for checksum
On Tue, May 01, 2007 at 12:14:11PM +1000, Neil Brown wrote: > I don't think this BUG_ON is correct. If a readdir finds zero entries, > then will be some trailer information in the 'tail', but page_len will > be 0. I think the following patch is correct and could fix that. Yep. > Bruce: does it look OK to you? It looks sensible, but it's a little late for me--I'll take another look at it and run some tests tommorow. --b. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
On Mon, Apr 30, 2007 at 07:54:27PM -0700, H. Peter Anvin wrote: > Andi Kleen wrote: > >> Not that the x86 BIOS is bad. It is nearly a marvel in it's simplicity > >> and ubiquitousness, > > > > Simplicity? That must be why x86 motherbords are shipping with (compressed) > > 8MB BIOS flash chips now. > > Very little of that is the actual BIOS, though. Most of it is generally > QuickPlay, which tends to be a Linux system... At least my Asus board with 8Mb flash doesn't have anything called that. There is also no special preboot environment iirc Asus ships dual BIOS though, but even half that compressed is a lot. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] pci: type may be unused in pci_access_init()
On Mon, 30 Apr 2007 19:46:12 -0700 (PDT) David Rientjes <[EMAIL PROTECTED]>
wrote:
> So, due to the whacky implementation of __attribute_used__, we can just do
> this:
> ---
> arch/i386/pci/init.c |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/i386/pci/init.c b/arch/i386/pci/init.c
> index b21b6da..508d6fd 100644
> --- a/arch/i386/pci/init.c
> +++ b/arch/i386/pci/init.c
> @@ -6,7 +6,9 @@
> in the right sequence from here. */
> static __init int pci_access_init(void)
> {
> +#if defined(CONFIG_PCI_DIRECT) || defined(CONFIG_PCI_MMCONFIG)
> int type = 0;
> +#endif
Drat, I was hoping someone would unwhacky __attribute_used__.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
