Re: Driver removals
On Fri, Feb 15, 2008 at 08:52:27PM -0500, [EMAIL PROTECTED] wrote: > On Fri, 15 Feb 2008 20:08:13 EST, Bill Davidsen said: > > > can never make you see why technological extortion is evil. People have > > always moved to new drivers without pushing because they were *better*, > > guess that model is dead. > > And the drivers get better because the Code Fairy comes and sprinkles magic > bugfix dust all over them? And the Code Fairy knows where to sprinkle bugfix > dust because it can see where the Bugreport Fairy sprinkled Bugreport Dust? > > Yes, people will move without pushing when the drivers are better. However, > remember that a major cultural motivation for the GPL is the concept of "give > back". And if a user can't be bothered to even give back enough to say > "wow, this blows, my Frobnozz9800 doesn't work with this driver", that's a > problem with the user. I don't understand why kernel developers always think that users spend their whole time testing their new stuff. That is mostly true for a lot of desktop users, but definitely not for servers. On a server, you may *ignore* that a new driver exists for years. The basic make oldconfig does the stuff right. An old driver must spend some time marked "deprecated", if possible with the config option changed so that at least *something* informs the admin that it may soon be removed. It looks like this is something that people building a kernel every day and never getting more than one week of uptime do not understand. But there are many people who build once a year and upgrade that often at most, unless there is a big security issue. If the old driver simply keeps silently building when marked deprecated, noone will notice. And as Bill pointed it out, we should also make sure that when marked deprecated, the old one always refers to the new one so that the guy noticing this during the build has time to set up a test machine to try that new driver. Not everyone has a mouse and a joystick attached to the computers he builds kernels for... Willy -- 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: Driver removals
On Fri, Feb 15, 2008 at 08:08:13PM -0500, Bill Davidsen wrote: >... > If you don't see an ethical problem in removing a working driver which > is not taking support resources, in order to force people to test and > debug a driver they don't now and never would need, so that it might in > time offer them the same functionality those users already had... then I > can never make you see why technological extortion is evil. >... You miss one basic principle of free software: Forks are allowed, so when you don't like the way some software is developed you can always release a version of the software that is in your eyes better. And that's nothing evil, after all each distribution kernel is a fork of the upstream kernel. Hey, you can even use the 2.6.16 branch *I* do maintain to avoid what you claim was an "ethical problem". And if you don't like 2.6.16 either for whatever reason there's still no ethical problem but only the technical problem of you not getting your ass up and doing whatever is "better" in your opinion. After all, free software is not driven by people whining but by people doing stuff. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- 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 07/30] r/o bind mounts: stub functions
On Sat, 16 Feb 2008 07:31:29 +0100 Christoph Hellwig <[EMAIL PROTECTED]> wrote: > On Fri, Feb 15, 2008 at 05:11:19PM -0800, Andrew Morton wrote: > > > It would be nice if an initial patch which introduces the new > > > functionality you need for r/o bind mounts could get introduced into > > > mainline *first*, and then people could add patches that call > > > mnt_want_write(), et. al into their trees gradually. > > > > Yes, I expect that merging a handful of do-nothing mnt_foo_write() > > functions into mainline right now would ease life. > > > > > otherwise akpm gets grumpy > > > > itym "less than usually cheery" > > Haha, > > once we put pieces in the first three patches would be useful aswell, > to easily catch additions in the next cycle that might be adding > NULL-vfsmount calls to dentry_open. hrm, well, how about putting up a complete and suitably-changelogged patch series for Linus to look at? That's be a Dave thing I guess. I wasn't overawed by the initial patch - why not make those stubs inlined to truly add zero cost?? -- 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/
aacraid: Host adapter reset request. SCSI hang ?
Hi there, We're having issues with our Adaptec RAID controller and I was wondering if anyone would be able to advise on how to go about resolving them. :) The system: RHEL 5.1 x86_64 Kernel 2.6.18-53.1.4.el5 aacraid 1.1-5[2437]-mh4 (The default module shipped with the RHEL kernel) The controller: Adaptec 3405 + BBU BIOS : 5.2-0 (12415) Firmware : 5.2-0 (12415) Driver : 1.1-5 (2437) Boot Flash : 5.2-0 (12415) The disks: 4x Seagate ST373455SS (Firmware 0002) in a RAID10 The issue: We continually get what seem to be adapter lockups with the error: aacraid: Host adapter abort request (3,0,0,0) aacraid: Host adapter reset request. SCSI hang ? The controller hangs for a while, recovers, and everything continues normally. We've tried a replacement controller and a replacement set of disks (we swapped out all 4 disks) to no avail. The problem seems (?) to happen during spikes of IO -- like when the PostgreSQL autovacuum daemon kicks in. But not always. >From searching around LKML and Google, this seems to be a fairly common issue, but I'm not quite clear on the cause (hardware? software? firmware?) or the resolution. Any help would be greatly appreciated. Thanks! Regards, Omar -- 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 5/6] h8300 IRQ handling update
Signed-off-by: Yoshinori Sato <[EMAIL PROTECTED]>
At Sat, 16 Feb 2008 01:13:58 -0500,
Yoshinori Sato wrote:
>
> - add missing file and declare.
> - remove unused file and macros.
> - some cleanup.
>
> arch/h8300/kernel/irq.c |4 +-
> arch/h8300/platform/h8300h/Makefile |2 +-
> arch/h8300/platform/h8300h/irq.c| 82 ++
> arch/h8300/platform/h8s/ints.c | 304
> ---
> arch/h8300/platform/h8s/ints_h8s.c | 104
> arch/h8300/platform/h8s/irq.c | 104
> include/asm-h8300/hardirq.h |2 +
> include/asm-h8300/irq.h | 19 +--
> 8 files changed, 194 insertions(+), 427 deletions(-)
> create mode 100644 arch/h8300/platform/h8300h/irq.c
> delete mode 100644 arch/h8300/platform/h8s/ints.c
> delete mode 100644 arch/h8300/platform/h8s/ints_h8s.c
> create mode 100644 arch/h8300/platform/h8s/irq.c
>
> diff --git a/arch/h8300/kernel/irq.c b/arch/h8300/kernel/irq.c
> index 5a1b4cf..ef4f004 100644
> --- a/arch/h8300/kernel/irq.c
> +++ b/arch/h8300/kernel/irq.c
> @@ -26,7 +26,7 @@
>
> extern unsigned long *interrupt_redirect_table;
> extern const int h8300_saved_vectors[];
> -extern const unsigned long h8300_trap_table[];
> +extern const h8300_vector h8300_trap_table[];
> int h8300_enable_irq_pin(unsigned int irq);
> void h8300_disable_irq_pin(unsigned int irq);
>
> @@ -116,7 +116,7 @@ static void __init setup_vector(void)
> {
> int i;
> unsigned long *ramvec,*ramvec_p;
> - const unsigned long *trap_entry;
> + const h8300_vector *trap_entry;
> const int *saved_vector;
>
> ramvec = get_vector_address();
> diff --git a/arch/h8300/platform/h8300h/Makefile
> b/arch/h8300/platform/h8300h/Makefile
> index c509636..420f73b 100644
> --- a/arch/h8300/platform/h8300h/Makefile
> +++ b/arch/h8300/platform/h8300h/Makefile
> @@ -4,4 +4,4 @@
> # Reuse any files we can from the H8/300H
> #
>
> -obj-y := irq_pin.o ptrace_h8300h.o
> +obj-y := irq.o ptrace_h8300h.o
> diff --git a/arch/h8300/platform/h8300h/irq.c
> b/arch/h8300/platform/h8300h/irq.c
> new file mode 100644
> index 000..e977345
> --- /dev/null
> +++ b/arch/h8300/platform/h8300h/irq.c
> @@ -0,0 +1,82 @@
> +/*
> + * Interrupt handling H8/300H depend.
> + * Yoshinori Sato <[EMAIL PROTECTED]>
> + *
> + */
> +
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +const int __initdata h8300_saved_vectors[] = {
> +#if defined(CONFIG_GDB_DEBUG)
> + TRAP3_VEC, /* TRAPA #3 is GDB breakpoint */
> +#endif
> + -1,
> +};
> +
> +const h8300_vector __initdata h8300_trap_table[] = {
> + 0, 0, 0, 0, 0, 0, 0, 0,
> + system_call,
> + 0,
> + 0,
> + trace_break,
> +};
> +
> +int h8300_enable_irq_pin(unsigned int irq)
> +{
> + int bitmask;
> + if (irq < EXT_IRQ0 || irq > EXT_IRQ5)
> + return 0;
> +
> + /* initialize IRQ pin */
> + bitmask = 1 << (irq - EXT_IRQ0);
> + switch(irq) {
> + case EXT_IRQ0:
> + case EXT_IRQ1:
> + case EXT_IRQ2:
> + case EXT_IRQ3:
> + if (H8300_GPIO_RESERVE(H8300_GPIO_P8, bitmask) == 0)
> + return -EBUSY;
> + H8300_GPIO_DDR(H8300_GPIO_P8, bitmask, H8300_GPIO_INPUT);
> + break;
> + case EXT_IRQ4:
> + case EXT_IRQ5:
> + if (H8300_GPIO_RESERVE(H8300_GPIO_P9, bitmask) == 0)
> + return -EBUSY;
> + H8300_GPIO_DDR(H8300_GPIO_P9, bitmask, H8300_GPIO_INPUT);
> + break;
> + }
> +
> + return 0;
> +}
> +
> +void h8300_disable_irq_pin(unsigned int irq)
> +{
> + int bitmask;
> + if (irq < EXT_IRQ0 || irq > EXT_IRQ5)
> + return;
> +
> + /* disable interrupt & release IRQ pin */
> + bitmask = 1 << (irq - EXT_IRQ0);
> + switch(irq) {
> + case EXT_IRQ0:
> + case EXT_IRQ1:
> + case EXT_IRQ2:
> + case EXT_IRQ3:
> + *(volatile unsigned char *)IER &= ~bitmask;
> + H8300_GPIO_FREE(H8300_GPIO_P8, bitmask);
> + break ;
> + case EXT_IRQ4:
> + case EXT_IRQ5:
> + *(volatile unsigned char *)IER &= ~bitmask;
> + H8300_GPIO_FREE(H8300_GPIO_P9, bitmask);
> + break;
> + }
> +}
> diff --git a/arch/h8300/platform/h8s/ints.c b/arch/h8300/platform/h8s/ints.c
> deleted file mode 100644
> index ac10b97..000
> --- a/arch/h8300/platform/h8s/ints.c
> +++ /dev/null
> @@ -1,304 +0,0 @@
> -/*
> - * linux/arch/h8300/platform/h8s/ints.c
> - *
> - * Yoshinori Sato <[EMAIL PROTECTED]>
> - *
> - * Based on linux/arch/$(ARCH)/platform/$(PLATFORM)/ints.c
> - *
> - * This file is subject to the terms and conditions of the GNU General Public
> - * License. See the file COPYING in the main directory of this archive
> - * for more details.
> - *
> - * Copyright 1996 Roman Zippel
> - * Copyright 1999 D. Jeff Dionne <[EMAIL PROTECTED]>
> - */
> -
>
Re: [PATCH 07/30] r/o bind mounts: stub functions
On Fri, Feb 15, 2008 at 05:11:19PM -0800, Andrew Morton wrote: > > It would be nice if an initial patch which introduces the new > > functionality you need for r/o bind mounts could get introduced into > > mainline *first*, and then people could add patches that call > > mnt_want_write(), et. al into their trees gradually. > > Yes, I expect that merging a handful of do-nothing mnt_foo_write() > functions into mainline right now would ease life. > > > otherwise akpm gets grumpy > > itym "less than usually cheery" Haha, once we put pieces in the first three patches would be useful aswell, to easily catch additions in the next cycle that might be adding NULL-vfsmount calls to dentry_open. -- 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 4/6] h8300 CONFIG_KALLSYMS fix
On Sat, 16 Feb 2008 01:13:47 -0500 Yoshinori Sato <[EMAIL PROTECTED]> wrote: > Please comment "C_SYMBOL_PREFIX". > > Makefile |3 ++- > arch/h8300/Kconfig |4 > 2 files changed, 6 insertions(+), 1 deletions(-) > > diff --git a/Makefile b/Makefile > index c162370..745e31f 100644 > --- a/Makefile > +++ b/Makefile > @@ -751,7 +751,8 @@ endef > # Generate .S file with all kernel symbols > quiet_cmd_kallsyms = KSYM$@ >cmd_kallsyms = $(NM) -n $< | $(KALLSYMS) \ > - $(if $(CONFIG_KALLSYMS_ALL),--all-symbols) > $@ > + $(if $(CONFIG_KALLSYMS_ALL),--all-symbols) \ > + $(if $(CONFIG_C_SYMBOL_PREFIX),--symbol-prefix='_') > $@ > > .tmp_kallsyms1.o .tmp_kallsyms2.o .tmp_kallsyms3.o: %.o: %.S scripts FORCE > $(call if_changed_dep,as_o_S) > diff --git a/arch/h8300/Kconfig b/arch/h8300/Kconfig > index 085dc6e..2804edd 100644 > --- a/arch/h8300/Kconfig > +++ b/arch/h8300/Kconfig > @@ -87,6 +87,10 @@ config HZ > int > default 100 > > +config C_SYMBOL_PREFIX > + bool > + default y > + > source "init/Kconfig" > > source "arch/h8300/Kconfig.cpu" > -- Sam looks after that code. None of these patches added your Signed-off-by:. Please confirm that it is OK if I add it. -- 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 3/6] h8300 setup.c initrd support fix
On Sat, 16 Feb 2008 01:13:37 -0500 Yoshinori Sato <[EMAIL PROTECTED]> wrote:
> initrd setting fix.
>
> arch/h8300/kernel/setup.c |5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/h8300/kernel/setup.c b/arch/h8300/kernel/setup.c
> index b1f25c2..75712ec 100644
> --- a/arch/h8300/kernel/setup.c
> +++ b/arch/h8300/kernel/setup.c
> @@ -57,6 +57,7 @@ extern int _stext, _etext, _sdata, _edata, _sbss, _ebss,
> _end;
> extern int _ramstart, _ramend;
> extern char _target_name[];
> extern void h8300_gpio_init(void);
> +extern void *initrd_start, *initrd_end;
>
> #if (defined(CONFIG_H8300H_SIM) || defined(CONFIG_H8S_SIM)) \
> && defined(CONFIG_GDB_MAGICPRINT)
> @@ -99,8 +100,8 @@ void __init setup_arch(char **cmdline_p)
> /* allow for ROMFS on the end of the kernel */
> if (memcmp((void *)memory_start, "-rom1fs-", 8) == 0) {
> #if defined(CONFIG_BLK_DEV_INITRD)
> - initrd_start = memory_start;
> - initrd_end = memory_start += be32_to_cpu(((unsigned long *)
> (memory_start))[2]);
> + initrd_start = (void *)memory_start;
> + initrd_end = (void *)(memory_start += be32_to_cpu(((unsigned
> long *) (memory_start))[2]));
> #else
> memory_start += be32_to_cpu(((unsigned long *)
> memory_start)[2]);
> #endif
But include/linux/initrd.h declares:
extern unsigned long initrd_start, initrd_end;
--
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] Best method to control a "transmit-only" mode on fiber NICs (specifically sky2)
Kyle Moffett wrote:
Hi,
The company I'm working for has an unusual fiber NIC configuration
that we use for one of our network appliances. We connect only a
single fiber from the TX port on one NIC to the RX port on another
NIC, providing a physically-one-way path for enhanced security.
Unfortunately this doesn't work with most NIC drivers, as even with
auto-negotiation off they look for link probe pulses before they
consider the link "up" and are willing to send packets. We have been
able to use Myricom 10GigE NICs with a custom firmware image. More
recently we have patched the sky2 driver to turn on the FIB_FORCE_LNK
flag in the PHY control register; this seems to work on the
Marvell-chipset boards we have here.
What would be the preferred way to control this "force link" flag?
Right now we are accessing it using ethtool; we have added an
additional "duplex" mode: "DUPLEX_TXONLY", with a value of 2. When
you specify a speed and turn off autonegotiation ("./patched-ethtool
-s eth2 speed 1000 autoneg off duplex txonly"), it will turn on the
specified bit in the PHY control register and the link will
automatically come up. We also have one related bug-fix^Wdirty hack
for sky2 to reset the PHY a second time during netif-up after enabling
interrupts; otherwise the immediate "link up" interrupt gets lost.
Once I get approval from the company I will patch the post itself for
review.
I look forward to your comments and suggestions
Cheers,
Kyle Moffett
For the second problem, you could just change the code to check the
status immediately,
by calling the same code the irq does. It might need some refactoring
but should only be minor surgery.
I was thinking about doing that anyway for the forced link (no
negotiation case).
--
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 6/6] h8300 defconfig update
Signed-off-by: Yoshinori Sato <[EMAIL PROTECTED]> At Sat, 16 Feb 2008 01:14:03 -0500, Yoshinori Sato wrote: > > defconfig update. > This update is depend CONFIG_KALLSYMS fix. > > arch/h8300/defconfig | 263 ++--- > 1 files changed, 140 insertions(+), 123 deletions(-) > > diff --git a/arch/h8300/defconfig b/arch/h8300/defconfig > index 8f1ec32..8901cdb 100644 > --- a/arch/h8300/defconfig > +++ b/arch/h8300/defconfig > @@ -1,51 +1,98 @@ > # > # Automatically generated make config: don't edit > -# Linux kernel version: 2.6.11-rc1 > -# Sun Jan 16 17:24:38 2005 > +# Linux kernel version: 2.6.25-rc1 > +# Fri Feb 15 17:13:14 2008 > # > CONFIG_H8300=y > # CONFIG_MMU is not set > # CONFIG_SWAP is not set > +CONFIG_ZONE_DMA=y > # CONFIG_FPU is not set > -CONFIG_UID16=y > CONFIG_RWSEM_GENERIC_SPINLOCK=y > # CONFIG_RWSEM_XCHGADD_ALGORITHM is not set > +# CONFIG_ARCH_HAS_ILOG2_U32 is not set > +# CONFIG_ARCH_HAS_ILOG2_U64 is not set > +CONFIG_GENERIC_FIND_NEXT_BIT=y > +CONFIG_GENERIC_HWEIGHT=y > +CONFIG_GENERIC_HARDIRQS=y > CONFIG_GENERIC_CALIBRATE_DELAY=y > +CONFIG_GENERIC_TIME=y > +CONFIG_TIME_LOW_RES=y > +CONFIG_ARCH_SUPPORTS_AOUT=y > +CONFIG_NO_IOPORT=y > +CONFIG_NO_DMA=y > CONFIG_ISA=y > # CONFIG_PCI is not set > +CONFIG_HZ=100 > +CONFIG_C_SYMBOL_PREFIX=y > +CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" > > # > -# Code maturity level options > +# General setup > # > CONFIG_EXPERIMENTAL=y > -CONFIG_CLEAN_COMPILE=y > CONFIG_BROKEN_ON_SMP=y > - > -# > -# General setup > -# > +CONFIG_INIT_ENV_ARG_LIMIT=32 > CONFIG_LOCALVERSION="" > +# CONFIG_LOCALVERSION_AUTO is not set > +# CONFIG_SYSVIPC is not set > # CONFIG_BSD_PROCESS_ACCT is not set > -# CONFIG_SYSCTL is not set > -# CONFIG_AUDIT is not set > -CONFIG_LOG_BUF_SHIFT=14 > -# CONFIG_HOTPLUG is not set > # CONFIG_IKCONFIG is not set > +CONFIG_LOG_BUF_SHIFT=14 > +# CONFIG_CGROUPS is not set > +# CONFIG_FAIR_GROUP_SCHED is not set > +# CONFIG_SYSFS_DEPRECATED is not set > +# CONFIG_RELAY is not set > +# CONFIG_NAMESPACES is not set > +# CONFIG_BLK_DEV_INITRD is not set > +CONFIG_CC_OPTIMIZE_FOR_SIZE=y > +CONFIG_SYSCTL=y > CONFIG_EMBEDDED=y > +# CONFIG_UID16 is not set > +# CONFIG_SYSCTL_SYSCALL is not set > # CONFIG_KALLSYMS is not set > +# CONFIG_HOTPLUG is not set > +CONFIG_PRINTK=y > +CONFIG_BUG=y > +CONFIG_ELF_CORE=y > +# CONFIG_COMPAT_BRK is not set > +# CONFIG_BASE_FULL is not set > # CONFIG_FUTEX is not set > # CONFIG_EPOLL is not set > -CONFIG_CC_OPTIMIZE_FOR_SIZE=y > -CONFIG_CC_ALIGN_FUNCTIONS=0 > -CONFIG_CC_ALIGN_LABELS=0 > -CONFIG_CC_ALIGN_LOOPS=0 > -CONFIG_CC_ALIGN_JUMPS=0 > +# CONFIG_SIGNALFD is not set > +# CONFIG_TIMERFD is not set > +# CONFIG_EVENTFD is not set > +# CONFIG_VM_EVENT_COUNTERS is not set > +# CONFIG_SLAB is not set > +# CONFIG_SLUB is not set > +CONFIG_SLOB=y > +# CONFIG_PROFILING is not set > +# CONFIG_MARKERS is not set > +# CONFIG_HAVE_OPROFILE is not set > +# CONFIG_HAVE_KPROBES is not set > CONFIG_TINY_SHMEM=y > +CONFIG_BASE_SMALL=1 > +# CONFIG_MODULES is not set > +CONFIG_BLOCK=y > +# CONFIG_LBD is not set > +# CONFIG_BLK_DEV_IO_TRACE is not set > +# CONFIG_LSF is not set > +# CONFIG_BLK_DEV_BSG is not set > > # > -# Loadable module support > +# IO Schedulers > # > -# CONFIG_MODULES is not set > +CONFIG_IOSCHED_NOOP=y > +# CONFIG_IOSCHED_AS is not set > +# CONFIG_IOSCHED_DEADLINE is not set > +# CONFIG_IOSCHED_CFQ is not set > +# CONFIG_DEFAULT_AS is not set > +# CONFIG_DEFAULT_DEADLINE is not set > +# CONFIG_DEFAULT_CFQ is not set > +CONFIG_DEFAULT_NOOP=y > +CONFIG_DEFAULT_IOSCHED="noop" > +CONFIG_CLASSIC_RCU=y > +# CONFIG_PREEMPT_RCU is not set > > # > # Processor type and features > @@ -62,14 +109,26 @@ CONFIG_H8300H_GENERIC=y > # Detail Selection > # > # CONFIG_H83002 is not set > -# CONFIG_H83007 is not set > +CONFIG_H83007=y > # CONFIG_H83048 is not set > -CONFIG_H83068=y > +# CONFIG_H83068 is not set > CONFIG_CPU_CLOCK=2 > -# CONFIG_RAMKERNEL is not set > -CONFIG_ROMKERNEL=y > +CONFIG_RAMKERNEL=y > +# CONFIG_ROMKERNEL is not set > CONFIG_CPU_H8300H=y > # CONFIG_PREEMPT is not set > +CONFIG_SELECT_MEMORY_MODEL=y > +CONFIG_FLATMEM_MANUAL=y > +# CONFIG_DISCONTIGMEM_MANUAL is not set > +# CONFIG_SPARSEMEM_MANUAL is not set > +CONFIG_FLATMEM=y > +CONFIG_FLAT_NODE_MEM_MAP=y > +# CONFIG_SPARSEMEM_STATIC is not set > +# CONFIG_SPARSEMEM_VMEMMAP_ENABLE is not set > +CONFIG_SPLIT_PTLOCK_CPUS=4 > +# CONFIG_RESOURCES_64BIT is not set > +CONFIG_ZONE_DMA_FLAG=1 > +CONFIG_VIRT_TO_BUS=y > > # > # Executable file formats > @@ -77,34 +136,42 @@ CONFIG_CPU_H8300H=y > CONFIG_BINFMT_FLAT=y > CONFIG_BINFMT_ZFLAT=y > # CONFIG_BINFMT_SHARED_FLAT is not set > -# CONFIG_BINFMT_MISC is not set > +CONFIG_BINFMT_MISC=y > > # > -# Generic Driver Options > +# Networking > # > -# CONFIG_STANDALONE is not set > -# CONFIG_PREVENT_FIRMWARE_BUILD is not set > -# CONFIG_FW_LOADER is not set > -# CONFIG_DEBUG_DRIVER is not set > +# CONFIG_NET is
Re: [PATCH 4/6] h8300 CONFIG_KALLSYMS fix
Signed-off-by: Yoshinori Sato <[EMAIL PROTECTED]> At Sat, 16 Feb 2008 01:13:47 -0500, Yoshinori Sato wrote: > > Please comment "C_SYMBOL_PREFIX". > > Makefile |3 ++- > arch/h8300/Kconfig |4 > 2 files changed, 6 insertions(+), 1 deletions(-) > > diff --git a/Makefile b/Makefile > index c162370..745e31f 100644 > --- a/Makefile > +++ b/Makefile > @@ -751,7 +751,8 @@ endef > # Generate .S file with all kernel symbols > quiet_cmd_kallsyms = KSYM$@ >cmd_kallsyms = $(NM) -n $< | $(KALLSYMS) \ > - $(if $(CONFIG_KALLSYMS_ALL),--all-symbols) > $@ > + $(if $(CONFIG_KALLSYMS_ALL),--all-symbols) \ > + $(if $(CONFIG_C_SYMBOL_PREFIX),--symbol-prefix='_') > $@ > > .tmp_kallsyms1.o .tmp_kallsyms2.o .tmp_kallsyms3.o: %.o: %.S scripts FORCE > $(call if_changed_dep,as_o_S) > diff --git a/arch/h8300/Kconfig b/arch/h8300/Kconfig > index 085dc6e..2804edd 100644 > --- a/arch/h8300/Kconfig > +++ b/arch/h8300/Kconfig > @@ -87,6 +87,10 @@ config HZ > int > default 100 > > +config C_SYMBOL_PREFIX > + bool > + default y > + > source "init/Kconfig" > > source "arch/h8300/Kconfig.cpu" > -- > 1.5.4.1 > > -- > Yoshinori Sato > <[EMAIL PROTECTED]> -- 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 2/6] h8300 uaccess.h update
Signed-off-by: Yoshinori Sato <[EMAIL PROTECTED]>
At Sat, 16 Feb 2008 01:13:27 -0500,
Yoshinori Sato wrote:
>
> get_user const *ptr access fix.
>
> include/asm-h8300/uaccess.h |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/asm-h8300/uaccess.h b/include/asm-h8300/uaccess.h
> index ebe58c6..a22350e 100644
> --- a/include/asm-h8300/uaccess.h
> +++ b/include/asm-h8300/uaccess.h
> @@ -91,7 +91,7 @@ extern int __put_user_bad(void);
> #define get_user(x, ptr) \
> ({ \
> int __gu_err = 0;\
> -typeof(*(ptr)) __gu_val = 0; \
> +uint32_t __gu_val = 0; \
> switch (sizeof(*(ptr))) {\
> case 1: \
> case 2: \
> @@ -106,7 +106,7 @@ extern int __put_user_bad(void);
> __gu_err = __get_user_bad();\
> break; \
> }\
> -(x) = __gu_val; \
> +(x) = (typeof(*(ptr)))__gu_val; \
> __gu_err;\
> })
> #define __get_user(x, ptr) get_user(x, ptr)
> --
> 1.5.4.1
>
> --
> Yoshinori Sato
> <[EMAIL PROTECTED]>
--
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 3/6] h8300 setup.c initrd support fix
Signed-off-by: Yoshinori Sato <[EMAIL PROTECTED]>
At Sat, 16 Feb 2008 01:13:37 -0500,
Yoshinori Sato wrote:
>
> initrd setting fix.
>
> arch/h8300/kernel/setup.c |5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/h8300/kernel/setup.c b/arch/h8300/kernel/setup.c
> index b1f25c2..75712ec 100644
> --- a/arch/h8300/kernel/setup.c
> +++ b/arch/h8300/kernel/setup.c
> @@ -57,6 +57,7 @@ extern int _stext, _etext, _sdata, _edata, _sbss, _ebss,
> _end;
> extern int _ramstart, _ramend;
> extern char _target_name[];
> extern void h8300_gpio_init(void);
> +extern void *initrd_start, *initrd_end;
>
> #if (defined(CONFIG_H8300H_SIM) || defined(CONFIG_H8S_SIM)) \
> && defined(CONFIG_GDB_MAGICPRINT)
> @@ -99,8 +100,8 @@ void __init setup_arch(char **cmdline_p)
> /* allow for ROMFS on the end of the kernel */
> if (memcmp((void *)memory_start, "-rom1fs-", 8) == 0) {
> #if defined(CONFIG_BLK_DEV_INITRD)
> - initrd_start = memory_start;
> - initrd_end = memory_start += be32_to_cpu(((unsigned long *)
> (memory_start))[2]);
> + initrd_start = (void *)memory_start;
> + initrd_end = (void *)(memory_start += be32_to_cpu(((unsigned
> long *) (memory_start))[2]));
> #else
> memory_start += be32_to_cpu(((unsigned long *)
> memory_start)[2]);
> #endif
> --
> 1.5.4.1
>
> --
> Yoshinori Sato
> <[EMAIL PROTECTED]>
--
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/6] h8300 signal.c typo fix.
Sorry.
I forget Signed-off.
Signed-off-by: Yoshinori Sato <[EMAIL PROTECTED]>
At Sat, 16 Feb 2008 01:12:58 -0500,
Yoshinori Sato wrote:
>
> typo fix.
>
> arch/h8300/kernel/signal.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/h8300/kernel/signal.c b/arch/h8300/kernel/signal.c
> index 62ea12d..cf3472f 100644
> --- a/arch/h8300/kernel/signal.c
> +++ b/arch/h8300/kernel/signal.c
> @@ -352,7 +352,7 @@ static void setup_frame (int sig, struct k_sigaction *ka,
> ret = (unsigned char *)(ka->sa.sa_restorer);
> else {
> /* sub.l er0,er0; mov.b #__NR_sigreturn,r0l; trapa #0 */
> - err != __put_user(0x1a80f800 + (__NR_sigreturn & 0xff),
> + err |= __put_user(0x1a80f800 + (__NR_sigreturn & 0xff),
> (unsigned long *)(frame->retcode + 0));
> err |= __put_user(0x5700, (unsigned short *)(frame->retcode +
> 4));
> }
> @@ -428,7 +428,7 @@ static void setup_rt_frame (int sig, struct k_sigaction
> *ka, siginfo_t *info,
> ret = (unsigned char *)(ka->sa.sa_restorer);
> else {
> /* sub.l er0,er0; mov.b #__NR_sigreturn,r0l; trapa #0 */
> - err != __put_user(0x1a80f800 + (__NR_sigreturn & 0xff),
> + err |= __put_user(0x1a80f800 + (__NR_sigreturn & 0xff),
> (unsigned long *)(frame->retcode + 0));
> err |= __put_user(0x5700, (unsigned short *)(frame->retcode +
> 4));
> }
> --
> 1.5.4.1
>
> --
> Yoshinori Sato
> <[EMAIL PROTECTED]>
--
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.25-rc1] jerky mouse cursor and randoooom key repeats
On Sat, 2008-02-16 at 02:23 +0100, Gabriel C wrote: > Pavel Machek wrote: > > Hi! > > Hi , > > >> I'd not really done any real wor under 2.6.25 yet, but now while > >> running > >> a kernel compile with -j4 (single processor, dual core Pentium D), I see > >> this behavior. The mouse cursor moves a bit jerky and I sometimes get key > >> presses repeated. > > > > I see this one, too... x60, too... > > > > I have that problem on my Dell Precision WorkStation , as soon I stress the > box > a bit keyboard is going mad. Sounds like you may have CONFIG_GROUP_SCHED set? Bisection fingered 6b2d7700266b9402e12824e11e0099ae6a4a6a79 as the source here. -Mike -- 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/6] h8300 defconfig update
defconfig update. This update is depend CONFIG_KALLSYMS fix. arch/h8300/defconfig | 263 ++--- 1 files changed, 140 insertions(+), 123 deletions(-) diff --git a/arch/h8300/defconfig b/arch/h8300/defconfig index 8f1ec32..8901cdb 100644 --- a/arch/h8300/defconfig +++ b/arch/h8300/defconfig @@ -1,51 +1,98 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.11-rc1 -# Sun Jan 16 17:24:38 2005 +# Linux kernel version: 2.6.25-rc1 +# Fri Feb 15 17:13:14 2008 # CONFIG_H8300=y # CONFIG_MMU is not set # CONFIG_SWAP is not set +CONFIG_ZONE_DMA=y # CONFIG_FPU is not set -CONFIG_UID16=y CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_RWSEM_XCHGADD_ALGORITHM is not set +# CONFIG_ARCH_HAS_ILOG2_U32 is not set +# CONFIG_ARCH_HAS_ILOG2_U64 is not set +CONFIG_GENERIC_FIND_NEXT_BIT=y +CONFIG_GENERIC_HWEIGHT=y +CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_GENERIC_TIME=y +CONFIG_TIME_LOW_RES=y +CONFIG_ARCH_SUPPORTS_AOUT=y +CONFIG_NO_IOPORT=y +CONFIG_NO_DMA=y CONFIG_ISA=y # CONFIG_PCI is not set +CONFIG_HZ=100 +CONFIG_C_SYMBOL_PREFIX=y +CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # -# Code maturity level options +# General setup # CONFIG_EXPERIMENTAL=y -CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y - -# -# General setup -# +CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" +# CONFIG_LOCALVERSION_AUTO is not set +# CONFIG_SYSVIPC is not set # CONFIG_BSD_PROCESS_ACCT is not set -# CONFIG_SYSCTL is not set -# CONFIG_AUDIT is not set -CONFIG_LOG_BUF_SHIFT=14 -# CONFIG_HOTPLUG is not set # CONFIG_IKCONFIG is not set +CONFIG_LOG_BUF_SHIFT=14 +# CONFIG_CGROUPS is not set +# CONFIG_FAIR_GROUP_SCHED is not set +# CONFIG_SYSFS_DEPRECATED is not set +# CONFIG_RELAY is not set +# CONFIG_NAMESPACES is not set +# CONFIG_BLK_DEV_INITRD is not set +CONFIG_CC_OPTIMIZE_FOR_SIZE=y +CONFIG_SYSCTL=y CONFIG_EMBEDDED=y +# CONFIG_UID16 is not set +# CONFIG_SYSCTL_SYSCALL is not set # CONFIG_KALLSYMS is not set +# CONFIG_HOTPLUG is not set +CONFIG_PRINTK=y +CONFIG_BUG=y +CONFIG_ELF_CORE=y +# CONFIG_COMPAT_BRK is not set +# CONFIG_BASE_FULL is not set # CONFIG_FUTEX is not set # CONFIG_EPOLL is not set -CONFIG_CC_OPTIMIZE_FOR_SIZE=y -CONFIG_CC_ALIGN_FUNCTIONS=0 -CONFIG_CC_ALIGN_LABELS=0 -CONFIG_CC_ALIGN_LOOPS=0 -CONFIG_CC_ALIGN_JUMPS=0 +# CONFIG_SIGNALFD is not set +# CONFIG_TIMERFD is not set +# CONFIG_EVENTFD is not set +# CONFIG_VM_EVENT_COUNTERS is not set +# CONFIG_SLAB is not set +# CONFIG_SLUB is not set +CONFIG_SLOB=y +# CONFIG_PROFILING is not set +# CONFIG_MARKERS is not set +# CONFIG_HAVE_OPROFILE is not set +# CONFIG_HAVE_KPROBES is not set CONFIG_TINY_SHMEM=y +CONFIG_BASE_SMALL=1 +# CONFIG_MODULES is not set +CONFIG_BLOCK=y +# CONFIG_LBD is not set +# CONFIG_BLK_DEV_IO_TRACE is not set +# CONFIG_LSF is not set +# CONFIG_BLK_DEV_BSG is not set # -# Loadable module support +# IO Schedulers # -# CONFIG_MODULES is not set +CONFIG_IOSCHED_NOOP=y +# CONFIG_IOSCHED_AS is not set +# CONFIG_IOSCHED_DEADLINE is not set +# CONFIG_IOSCHED_CFQ is not set +# CONFIG_DEFAULT_AS is not set +# CONFIG_DEFAULT_DEADLINE is not set +# CONFIG_DEFAULT_CFQ is not set +CONFIG_DEFAULT_NOOP=y +CONFIG_DEFAULT_IOSCHED="noop" +CONFIG_CLASSIC_RCU=y +# CONFIG_PREEMPT_RCU is not set # # Processor type and features @@ -62,14 +109,26 @@ CONFIG_H8300H_GENERIC=y # Detail Selection # # CONFIG_H83002 is not set -# CONFIG_H83007 is not set +CONFIG_H83007=y # CONFIG_H83048 is not set -CONFIG_H83068=y +# CONFIG_H83068 is not set CONFIG_CPU_CLOCK=2 -# CONFIG_RAMKERNEL is not set -CONFIG_ROMKERNEL=y +CONFIG_RAMKERNEL=y +# CONFIG_ROMKERNEL is not set CONFIG_CPU_H8300H=y # CONFIG_PREEMPT is not set +CONFIG_SELECT_MEMORY_MODEL=y +CONFIG_FLATMEM_MANUAL=y +# CONFIG_DISCONTIGMEM_MANUAL is not set +# CONFIG_SPARSEMEM_MANUAL is not set +CONFIG_FLATMEM=y +CONFIG_FLAT_NODE_MEM_MAP=y +# CONFIG_SPARSEMEM_STATIC is not set +# CONFIG_SPARSEMEM_VMEMMAP_ENABLE is not set +CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_RESOURCES_64BIT is not set +CONFIG_ZONE_DMA_FLAG=1 +CONFIG_VIRT_TO_BUS=y # # Executable file formats @@ -77,34 +136,42 @@ CONFIG_CPU_H8300H=y CONFIG_BINFMT_FLAT=y CONFIG_BINFMT_ZFLAT=y # CONFIG_BINFMT_SHARED_FLAT is not set -# CONFIG_BINFMT_MISC is not set +CONFIG_BINFMT_MISC=y # -# Generic Driver Options +# Networking # -# CONFIG_STANDALONE is not set -# CONFIG_PREVENT_FIRMWARE_BUILD is not set -# CONFIG_FW_LOADER is not set -# CONFIG_DEBUG_DRIVER is not set +# CONFIG_NET is not set # -# Memory Technology Devices (MTD) +# Generic Driver Options # +CONFIG_STANDALONE=y +# CONFIG_PREVENT_FIRMWARE_BUILD is not set +# CONFIG_SYS_HYPERVISOR is not set CONFIG_MTD=y # CONFIG_MTD_DEBUG is not set +# CONFIG_MTD_CONCAT is not set CONFIG_MTD_PARTITIONS=y -CONFIG_MTD_CONCAT=y -# CONFIG_MTD_REDBOOT_PARTS is not set +CONFIG_MTD_REDBOOT_PARTS=y +CONFIG_MTD_REDBOOT_DIRECTORY_BLOCK=-1 +# CONFIG_MTD_REDBOOT_PARTS_UNALLOCATED is not set +# CON
[PATCH 5/6] h8300 IRQ handling update
- add missing file and declare.
- remove unused file and macros.
- some cleanup.
arch/h8300/kernel/irq.c |4 +-
arch/h8300/platform/h8300h/Makefile |2 +-
arch/h8300/platform/h8300h/irq.c| 82 ++
arch/h8300/platform/h8s/ints.c | 304 ---
arch/h8300/platform/h8s/ints_h8s.c | 104
arch/h8300/platform/h8s/irq.c | 104
include/asm-h8300/hardirq.h |2 +
include/asm-h8300/irq.h | 19 +--
8 files changed, 194 insertions(+), 427 deletions(-)
create mode 100644 arch/h8300/platform/h8300h/irq.c
delete mode 100644 arch/h8300/platform/h8s/ints.c
delete mode 100644 arch/h8300/platform/h8s/ints_h8s.c
create mode 100644 arch/h8300/platform/h8s/irq.c
diff --git a/arch/h8300/kernel/irq.c b/arch/h8300/kernel/irq.c
index 5a1b4cf..ef4f004 100644
--- a/arch/h8300/kernel/irq.c
+++ b/arch/h8300/kernel/irq.c
@@ -26,7 +26,7 @@
extern unsigned long *interrupt_redirect_table;
extern const int h8300_saved_vectors[];
-extern const unsigned long h8300_trap_table[];
+extern const h8300_vector h8300_trap_table[];
int h8300_enable_irq_pin(unsigned int irq);
void h8300_disable_irq_pin(unsigned int irq);
@@ -116,7 +116,7 @@ static void __init setup_vector(void)
{
int i;
unsigned long *ramvec,*ramvec_p;
- const unsigned long *trap_entry;
+ const h8300_vector *trap_entry;
const int *saved_vector;
ramvec = get_vector_address();
diff --git a/arch/h8300/platform/h8300h/Makefile
b/arch/h8300/platform/h8300h/Makefile
index c509636..420f73b 100644
--- a/arch/h8300/platform/h8300h/Makefile
+++ b/arch/h8300/platform/h8300h/Makefile
@@ -4,4 +4,4 @@
# Reuse any files we can from the H8/300H
#
-obj-y := irq_pin.o ptrace_h8300h.o
+obj-y := irq.o ptrace_h8300h.o
diff --git a/arch/h8300/platform/h8300h/irq.c b/arch/h8300/platform/h8300h/irq.c
new file mode 100644
index 000..e977345
--- /dev/null
+++ b/arch/h8300/platform/h8300h/irq.c
@@ -0,0 +1,82 @@
+/*
+ * Interrupt handling H8/300H depend.
+ * Yoshinori Sato <[EMAIL PROTECTED]>
+ *
+ */
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+const int __initdata h8300_saved_vectors[] = {
+#if defined(CONFIG_GDB_DEBUG)
+ TRAP3_VEC, /* TRAPA #3 is GDB breakpoint */
+#endif
+ -1,
+};
+
+const h8300_vector __initdata h8300_trap_table[] = {
+ 0, 0, 0, 0, 0, 0, 0, 0,
+ system_call,
+ 0,
+ 0,
+ trace_break,
+};
+
+int h8300_enable_irq_pin(unsigned int irq)
+{
+ int bitmask;
+ if (irq < EXT_IRQ0 || irq > EXT_IRQ5)
+ return 0;
+
+ /* initialize IRQ pin */
+ bitmask = 1 << (irq - EXT_IRQ0);
+ switch(irq) {
+ case EXT_IRQ0:
+ case EXT_IRQ1:
+ case EXT_IRQ2:
+ case EXT_IRQ3:
+ if (H8300_GPIO_RESERVE(H8300_GPIO_P8, bitmask) == 0)
+ return -EBUSY;
+ H8300_GPIO_DDR(H8300_GPIO_P8, bitmask, H8300_GPIO_INPUT);
+ break;
+ case EXT_IRQ4:
+ case EXT_IRQ5:
+ if (H8300_GPIO_RESERVE(H8300_GPIO_P9, bitmask) == 0)
+ return -EBUSY;
+ H8300_GPIO_DDR(H8300_GPIO_P9, bitmask, H8300_GPIO_INPUT);
+ break;
+ }
+
+ return 0;
+}
+
+void h8300_disable_irq_pin(unsigned int irq)
+{
+ int bitmask;
+ if (irq < EXT_IRQ0 || irq > EXT_IRQ5)
+ return;
+
+ /* disable interrupt & release IRQ pin */
+ bitmask = 1 << (irq - EXT_IRQ0);
+ switch(irq) {
+ case EXT_IRQ0:
+ case EXT_IRQ1:
+ case EXT_IRQ2:
+ case EXT_IRQ3:
+ *(volatile unsigned char *)IER &= ~bitmask;
+ H8300_GPIO_FREE(H8300_GPIO_P8, bitmask);
+ break ;
+ case EXT_IRQ4:
+ case EXT_IRQ5:
+ *(volatile unsigned char *)IER &= ~bitmask;
+ H8300_GPIO_FREE(H8300_GPIO_P9, bitmask);
+ break;
+ }
+}
diff --git a/arch/h8300/platform/h8s/ints.c b/arch/h8300/platform/h8s/ints.c
deleted file mode 100644
index ac10b97..000
--- a/arch/h8300/platform/h8s/ints.c
+++ /dev/null
@@ -1,304 +0,0 @@
-/*
- * linux/arch/h8300/platform/h8s/ints.c
- *
- * Yoshinori Sato <[EMAIL PROTECTED]>
- *
- * Based on linux/arch/$(ARCH)/platform/$(PLATFORM)/ints.c
- *
- * This file is subject to the terms and conditions of the GNU General Public
- * License. See the file COPYING in the main directory of this archive
- * for more details.
- *
- * Copyright 1996 Roman Zippel
- * Copyright 1999 D. Jeff Dionne <[EMAIL PROTECTED]>
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-/*
- * This structure has only 4 elements for speed reasons
- */
-typedef struct irq_handler {
- irqreturn_t (*
[PATCH 3/6] h8300 setup.c initrd support fix
initrd setting fix.
arch/h8300/kernel/setup.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/h8300/kernel/setup.c b/arch/h8300/kernel/setup.c
index b1f25c2..75712ec 100644
--- a/arch/h8300/kernel/setup.c
+++ b/arch/h8300/kernel/setup.c
@@ -57,6 +57,7 @@ extern int _stext, _etext, _sdata, _edata, _sbss, _ebss, _end;
extern int _ramstart, _ramend;
extern char _target_name[];
extern void h8300_gpio_init(void);
+extern void *initrd_start, *initrd_end;
#if (defined(CONFIG_H8300H_SIM) || defined(CONFIG_H8S_SIM)) \
&& defined(CONFIG_GDB_MAGICPRINT)
@@ -99,8 +100,8 @@ void __init setup_arch(char **cmdline_p)
/* allow for ROMFS on the end of the kernel */
if (memcmp((void *)memory_start, "-rom1fs-", 8) == 0) {
#if defined(CONFIG_BLK_DEV_INITRD)
- initrd_start = memory_start;
- initrd_end = memory_start += be32_to_cpu(((unsigned long *)
(memory_start))[2]);
+ initrd_start = (void *)memory_start;
+ initrd_end = (void *)(memory_start += be32_to_cpu(((unsigned
long *) (memory_start))[2]));
#else
memory_start += be32_to_cpu(((unsigned long *)
memory_start)[2]);
#endif
--
1.5.4.1
--
Yoshinori Sato
<[EMAIL PROTECTED]>
--
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/6] h8300 CONFIG_KALLSYMS fix
Please comment "C_SYMBOL_PREFIX". Makefile |3 ++- arch/h8300/Kconfig |4 2 files changed, 6 insertions(+), 1 deletions(-) diff --git a/Makefile b/Makefile index c162370..745e31f 100644 --- a/Makefile +++ b/Makefile @@ -751,7 +751,8 @@ endef # Generate .S file with all kernel symbols quiet_cmd_kallsyms = KSYM$@ cmd_kallsyms = $(NM) -n $< | $(KALLSYMS) \ - $(if $(CONFIG_KALLSYMS_ALL),--all-symbols) > $@ + $(if $(CONFIG_KALLSYMS_ALL),--all-symbols) \ + $(if $(CONFIG_C_SYMBOL_PREFIX),--symbol-prefix='_') > $@ .tmp_kallsyms1.o .tmp_kallsyms2.o .tmp_kallsyms3.o: %.o: %.S scripts FORCE $(call if_changed_dep,as_o_S) diff --git a/arch/h8300/Kconfig b/arch/h8300/Kconfig index 085dc6e..2804edd 100644 --- a/arch/h8300/Kconfig +++ b/arch/h8300/Kconfig @@ -87,6 +87,10 @@ config HZ int default 100 +config C_SYMBOL_PREFIX + bool + default y + source "init/Kconfig" source "arch/h8300/Kconfig.cpu" -- 1.5.4.1 -- Yoshinori Sato <[EMAIL PROTECTED]> -- 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/6] h8300 uaccess.h update
get_user const *ptr access fix.
include/asm-h8300/uaccess.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/asm-h8300/uaccess.h b/include/asm-h8300/uaccess.h
index ebe58c6..a22350e 100644
--- a/include/asm-h8300/uaccess.h
+++ b/include/asm-h8300/uaccess.h
@@ -91,7 +91,7 @@ extern int __put_user_bad(void);
#define get_user(x, ptr) \
({ \
int __gu_err = 0; \
-typeof(*(ptr)) __gu_val = 0; \
+uint32_t __gu_val = 0; \
switch (sizeof(*(ptr))) { \
case 1:\
case 2:\
@@ -106,7 +106,7 @@ extern int __put_user_bad(void);
__gu_err = __get_user_bad();\
break; \
} \
-(x) = __gu_val;\
+(x) = (typeof(*(ptr)))__gu_val;\
__gu_err; \
})
#define __get_user(x, ptr) get_user(x, ptr)
--
1.5.4.1
--
Yoshinori Sato
<[EMAIL PROTECTED]>
--
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/6] h8300 signal.c typo fix.
typo fix.
arch/h8300/kernel/signal.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/h8300/kernel/signal.c b/arch/h8300/kernel/signal.c
index 62ea12d..cf3472f 100644
--- a/arch/h8300/kernel/signal.c
+++ b/arch/h8300/kernel/signal.c
@@ -352,7 +352,7 @@ static void setup_frame (int sig, struct k_sigaction *ka,
ret = (unsigned char *)(ka->sa.sa_restorer);
else {
/* sub.l er0,er0; mov.b #__NR_sigreturn,r0l; trapa #0 */
- err != __put_user(0x1a80f800 + (__NR_sigreturn & 0xff),
+ err |= __put_user(0x1a80f800 + (__NR_sigreturn & 0xff),
(unsigned long *)(frame->retcode + 0));
err |= __put_user(0x5700, (unsigned short *)(frame->retcode +
4));
}
@@ -428,7 +428,7 @@ static void setup_rt_frame (int sig, struct k_sigaction
*ka, siginfo_t *info,
ret = (unsigned char *)(ka->sa.sa_restorer);
else {
/* sub.l er0,er0; mov.b #__NR_sigreturn,r0l; trapa #0 */
- err != __put_user(0x1a80f800 + (__NR_sigreturn & 0xff),
+ err |= __put_user(0x1a80f800 + (__NR_sigreturn & 0xff),
(unsigned long *)(frame->retcode + 0));
err |= __put_user(0x5700, (unsigned short *)(frame->retcode +
4));
}
--
1.5.4.1
--
Yoshinori Sato
<[EMAIL PROTECTED]>
--
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/
[BUG] Linux 2.6.25-rc2 - Regression from 2.6.24-rc1-git1 softlockup while bootup on powerpc
Hi,
The softlockup is seen from 2.6.25-rc1-git{1,3} and is visible in the
2.6.24-rc2 kernel,
While booting up with the 2.6.25-rc1-git{1,3} and 2.6.25-rc2 kernel(s) on the
powerbox
Loading st.ko module
BUG: soft lockup - CPU#1 stuck for 61s! [insmod:379]
NIP: c01b0620 LR: c01a5dcc CTR: 0040
REGS: c0077caab8a0 TRAP: 0901 Not tainted (2.6.25-rc2-autotest)
MSR: 80009032 CR: 84004088 XER: 2000
TASK = c0077cb450a0[379] 'insmod' THREAD: c0077caa8000 CPU: 1
GPR00: c0077c9d4000 c0077caabb20 c0538a40 000b
GPR04: ffc0 c0077e0c 0036 000a
GPR08: 0040 c0077c9d4250 c000
GPR12: c0077c9d4230 c0481d00
NIP [c01b0620] .radix_tree_gang_lookup+0x100/0x1e4
LR [c01a5dcc] .call_for_each_cic+0x50/0x10c
Call Trace:
[c0077caabb20] [c01a5e2c] .call_for_each_cic+0xb0/0x10c (unreliable)
[c0077caabc60] [c019dba4] .exit_io_context+0xf0/0x110
[c0077caabcf0] [c0061e38] .do_exit+0x820/0x850
[c0077caabda0] [c0061f34] .do_group_exit+0xcc/0xe8
[c0077caabe30] [c000872c] syscall_exit+0x0/0x40
Instruction dump:
7d296214 39290018 e809 7caa2038 39290008 2fa0 409e0018 7caa4215
396b0001 418200cc 424000b8 4bdc <79691f24> 7d296214 e9690018 2fab
INFO: task insmod:387 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
insmodD 1000e144 12144 387 1
Call Trace:
[c0077cb97600] [c08fae80] 0xc08fae80 (unreliable)
[c0077cb977d0] [c0010c7c] .__switch_to+0x11c/0x154
[c0077cb97860] [c0344498] .schedule+0x5d0/0x6b0
[c0077cb97950] [c03447d8] .schedule_timeout+0x3c/0xe8
[c0077cb97a20] [c0343d34] .wait_for_common+0x150/0x22c
[c0077cb97ae0] [c008ef00] .__stop_machine_run+0xbc/0xf0
[c0077cb97bb0] [c008ef70] .stop_machine_run+0x3c/0x80
[c0077cb97c50] [c00891f0] .sys_init_module+0x14e4/0x1af4
[c0077cb97e30] [c000872c] syscall_exit+0x0/0x40
-- 0:conmux-control -- time-stamp -- Feb/15/08 16:04:12 --
INFO: task insmod:387 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
insmodD 1000e144 12144 387 1
Call Trace:
[c0077cb97600] [c08fae80] 0xc08fae80 (unreliable)
[c0077cb977d0] [c0010c7c] .__switch_to+0x11c/0x154
[c0077cb97860] [c0344498] .schedule+0x5d0/0x6b0
[c0077cb97950] [c03447d8] .schedule_timeout+0x3c/0xe8
[c0077cb97a20] [c0343d34] .wait_for_common+0x150/0x22c
[c0077cb97ae0] [c008ef00] .__stop_machine_run+0xbc/0xf0
[c0077cb97bb0] [c008ef70] .stop_machine_run+0x3c/0x80
[c0077cb97c50] [c00891f0] .sys_init_module+0x14e4/0x1af4
[c0077cb97e30] [c000872c] syscall_exit+0x0/0x40
-- 0:conmux-control -- time-stamp -- Feb/15/08 16:06:21 --
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
--
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/5] x86: validate against acpi motherboard resources
On Fri, Feb 15, 2008 at 9:52 PM, Robert Hancock <[EMAIL PROTECTED]> wrote: > Andi Kleen wrote: > > > Yinghai Lu <[EMAIL PROTECTED]> writes: > >> [EMAIL PROTECTED]: many fixes and cleanups] > >> Signed-off-by: Robert Hancock <[EMAIL PROTECTED]> > >> Signed-off-by: Andi Kleen <[EMAIL PROTECTED]> > >> Tested-by: Andi Kleen <[EMAIL PROTECTED]> > > > > iirc it really was > > Tested-and-didnt-pass-test-by: Andi Kleen > > unfortunately. I have not rechecked recently, but on the one Intel > > box the original patch and the other mcfg heuristics removed didn't work. > > With just this patch you will have this problem. You need either the > patch to disable decode during BAR sizing, or the patch to use MMCONFIG > for extended config space only, if you don't have them already. linus already apply the the patch to "use MMCONFIG for extended config space only" to mainline. the last two near 2.6.25-rc1. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a0ca9909609470ad779b9b9cc68ce96e975afff7 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b6ce068a1285a24185b01be8a49021827516b3e1 Andi, can you double check this patch with your test system? YH -- 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: more iommu sg merging fallout
Sorry for the late response,
On Mon, 11 Feb 2008 21:40:36 -0800 (PST)
David Miller <[EMAIL PROTECTED]> wrote:
> From: FUJITA Tomonori <[EMAIL PROTECTED]>
> Date: Thu, 07 Feb 2008 10:38:01 +0900
>
> > Great, thanks! SPARC IOMMUs use bitmap for the free area management
> > like POWER IOMMUs so it could use lib/iommu-helper as POWER does.
>
> Please look at Linus's current tree, I believe I have things
> in a working state, and the DMA mask portions should be easier
> to add now.
Thanks! It looks great.
iommu->page_table_map_base is on IO_PAGE_SIZE boundary? If so, the
following patch works, I think (sorry, it's only compile tested
again).
Thanks,
=
>From 91af83802c30d071f98444846e85310a8d58ab3d Mon Sep 17 00:00:00 2001
From: FUJITA Tomonori <[EMAIL PROTECTED]>
Date: Sat, 16 Feb 2008 14:29:02 +0900
Subject: [PATCH] sparc64: make IOMMU code respect the segment boundary limits
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
---
arch/sparc64/kernel/iommu.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/sparc64/kernel/iommu.c b/arch/sparc64/kernel/iommu.c
index d3276eb..ffefbf7 100644
--- a/arch/sparc64/kernel/iommu.c
+++ b/arch/sparc64/kernel/iommu.c
@@ -134,7 +134,8 @@ unsigned long iommu_range_alloc(struct device *dev,
else
boundary_size = ALIGN(1UL << 32, 1 << IO_PAGE_SHIFT);
- n = iommu_area_alloc(arena->map, limit, start, npages, 0,
+ n = iommu_area_alloc(arena->map, limit, start, npages,
+iommu->page_table_map_base >> IO_PAGE_SHIFT,
boundary_size >> IO_PAGE_SHIFT, 0);
if (n == -1) {
if (likely(pass < 1)) {
--
1.5.3.4
--
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: PCI Bursting with PIO
Dan Gora wrote:
Hi,
I am trying to optimize a driver for a slave only PCI device and am
having a lot of trouble getting any kind of PCI burst transactions in
either the read or the write direction. Using bcopy/memcpy or even a
hand-crafted while (len) { *pdst++ = *psrc++} (with pdst and psrc
unsigned long*) I can only get writes to burst and even in that case
only for 2 data phases (8 bytes) and only on 64 bit machines. The
best that I have managed is to use a hand crafted asm function which
copies the data through mmx registers on i386 machines, but that still
only bursts a maximum of 16 bytes in the write direction and not at
all in the read direction. The source and destination pointers are
both aligned to 8 byte boundaries, so I don't think that it's an
alignment issue.
The chipset is being limited by what the CPU is giving it. If the CPU
sends only a small amount of data in one access then the chipset usually
does not try to burst more than that.
Is there any way to get PIO to burst over the PCI bus in the read and
write direction? My device has 4 BAR registers, but the area where I
am transferring data is marked 'prefetchable' (although the others are
not). I read here: http://lkml.org/lkml/2004/9/23/393 that this was a
prerequisite, but it is apparently not sufficient. He also mentioned
that the area had to be marked as write-back, but it's not clear how
you can tell (no /proc/mtrr doesn't tell you) or that it has anything
to do with bursting reads.
Any ideas would be really appreciated,
Well, in order for the CPU to batch up more writes you'd have to map the
BAR as either write-combining or write-back. If it's not listed in
/proc/mtrr it will be the default setting of uncacheable. X has code to
set up the video memory on the video card as write-combining so it can
get better write performance, you could do something similar.
Setting it as write-back might allow you to get the reads to do bursting
as well (since the CPU will do a cache-line fill instead of individual
accesses) but this if the device is modifying this memory area, unless
you add code to invalidate those cache lines before reading the data
you'll get stale data back. You could run into some other less obvious
issues as well, as normally device memory regions are not mapped write-back.
In general, especially if you need to read data back from the device,
implementing a DMA engine would be by far the better option. Most
chipsets seem not at all optimized for handling sequential reads from
PCI memory from the CPU. (Even in the DMA case, you have to be careful
with what type of memory read transaction you use when transferring from
host memory - some chipsets don't like to burst more than one cycle if
you use normal Memory Read instead of Memory Read Line or Memory Read
Multiple.)
--
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/8] Scaling msgmni to the amount of lowmem
On Mon, 11 Feb 2008 15:16:47 +0100 [EMAIL PROTECTED] wrote: > [PATCH 01/08] > > This patch computes msg_ctlmni to make it scale with the amount of lowmem. > msg_ctlmni is now set to make the message queues occupy 1/32 of the available > lowmem. > > Some cleaning has also been done for the MSGPOOL constant: the msgctl man page > says it's not used, but it also defines it as a size in bytes (the code > expresses it in Kbytes). > Something's wrong here. Running LTP's msgctl08 (specifically: ltp-full-20070228) cripples the machine. It's a 4-way 4GB x86_64. http://userweb.kernel.org/~akpm/config-x.txt http://userweb.kernel.org/~akpm/dmesg-x.txt Normally msgctl08 will complete in a second or two. With this patch I don't know how long it will take to complete, and the machine is horridly bogged down. It does recover if you manage to kill msgctl08. Feels like a terrible memory shortage, but there's plenty of memory free and it isn't swapping. -- 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/5] x86: validate against acpi motherboard resources
Andi Kleen wrote: Yinghai Lu <[EMAIL PROTECTED]> writes: [EMAIL PROTECTED]: many fixes and cleanups] Signed-off-by: Robert Hancock <[EMAIL PROTECTED]> Signed-off-by: Andi Kleen <[EMAIL PROTECTED]> Tested-by: Andi Kleen <[EMAIL PROTECTED]> iirc it really was Tested-and-didnt-pass-test-by: Andi Kleen unfortunately. I have not rechecked recently, but on the one Intel box the original patch and the other mcfg heuristics removed didn't work. With just this patch you will have this problem. You need either the patch to disable decode during BAR sizing, or the patch to use MMCONFIG for extended config space only, if you don't have them already. -- 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/
[BUG] Linux 2.6.25-rc2 - Kernel Ooops while running dbench
Hi, The 2.6.25-rc2 kernel oopses while running dbench on ext3 filesystem mounted with mount -o data=writeback,nobh option on the x86_64 box BUG: unable to handle kernel NULL pointer dereference at IP: [] kmem_cache_alloc+0x3a/0x6c PGD 1f6860067 PUD 1f5d64067 PMD 0 Oops: [1] SMP CPU 3 Modules linked in: Pid: 4271, comm: dbench Not tainted 2.6.25-rc2-autotest #1 RIP: 0010:[] [] kmem_cache_alloc+0x3a/0x6c RSP: :8101fb041dc8 EFLAGS: 00010246 RAX: RBX: 810180033c00 RCX: 8027b269 RDX: RSI: 80d0 RDI: 80632d70 RBP: 80d0 R08: 0001 R09: R10: 8101feb36e50 R11: 0190 R12: 0001 R13: R14: 8101f8f38000 R15: ff9c FS: () GS:8101fff0f000(0063) knlGS:f7e41460 CS: 0010 DS: 002b ES: 002b CR0: 80050033 CR2: CR3: 0001f562 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process dbench (pid: 4271, threadinfo 8101fb04, task 8101fb18) Stack: 0001 8101fb041ea8 0001 8027b269 8101fb041ea8 80281fe8 0001 8101fb041ea8 ff9c 000b 0001 Call Trace: [] get_empty_filp+0x55/0xf9 [] __path_lookup_intent_open+0x22/0x8f [] open_namei+0x86/0x5a7 [] vfs_stat_fd+0x3c/0x4a [] do_filp_open+0x1c/0x3d [] get_unused_fd_flags+0x79/0x111 [] do_sys_open+0x46/0xca [] ia32_sysret+0x0/0xa Code: 24 00 00 00 48 98 48 8b 9c c7 d8 02 00 00 48 8b 13 f6 c2 01 74 12 83 ca ff 49 89 d8 89 ee e8 1f fb ff ff 48 89 c2 eb 13 8b 43 14 <48> 8b 34 c2 48 89 d0 48 0f b1 33 48 39 d0 75 d3 c1 ed 0f 31 c0 RIP [] kmem_cache_alloc+0x3a/0x6c RSP CR2: BUG: unable to handle kernel paging request at f51f3e1c IP: [] tg3_poll+0x10c/0x82e PGD 1f6860067 PUD 1f37a5067 PMD 0 Oops: [2] SMP CPU 3 Modules linked in: Pid: 4271, comm: dbench Tainted: G D 2.6.25-rc2-autotest #1 RIP: 0010:[] [] tg3_poll+0x10c/0x82e RSP: :8100e3b6fe60 EFLAGS: 00010206 RAX: f51f3e18 RBX: 8101ff1d4f50 RCX: 32e1 RDX: 32e1 RSI: 0246 RDI: 806aaad8 RBP: 8101ff67e6c0 R08: 8100e3b6fedc R09: 8100e3b6fee0 R10: 0282 R11: 0282 R12: 014f R13: 8101f51f3d80 R14: R15: 014f FS: () GS:8101fff0f000(0063) knlGS:f7e41460 CS: 0010 DS: 002b ES: 002b CR0: 80050033 CR2: f51f3e1c CR3: 0001f562 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process dbench (pid: 4271, threadinfo 8101fb04, task 8101fb18) Stack: 8101fb041d18 8101feb83040 8100e3b6ff20 80228bd0 8100e3b6feec fff0ff80 8101ff0c4000 0246 8101ff0c4000 0040 8101ff67e758 8101ff67e758 Call Trace: [] run_rebalance_domains+0x162/0x432 [] net_rx_action+0x75/0x14a [] __do_softirq+0x50/0xbb [] call_softirq+0x1c/0x28 [] do_softirq+0x2f/0x84 [] smp_apic_timer_interrupt+0x8b/0x9e [] apic_timer_interrupt+0x66/0x70 [] flat_send_IPI_mask+0x0/0x4c [] oops_end+0x38/0x6a [] do_page_fault+0x716/0x7bf [] error_exit+0x0/0x51 [] get_empty_filp+0x55/0xf9 [] kmem_cache_alloc+0x3a/0x6c [] get_empty_filp+0x55/0xf9 [] __path_lookup_intent_open+0x22/0x8f [] open_namei+0x86/0x5a7 [] vfs_stat_fd+0x3c/0x4a [] do_filp_open+0x1c/0x3d [] get_unused_fd_flags+0x79/0x111 [] do_sys_open+0x46/0xca [] ia32_sysret+0x0/0xa Code: 8b 05 a3 2e 29 00 41 ff c4 45 31 f6 41 81 e4 ff 01 00 00 ff 50 28 48 c7 03 00 00 00 00 41 8b 85 a0 00 00 00 49 03 85 a8 00 00 00 <0f> b7 40 04 39 44 24 2c 0f 8d 95 00 00 00 44 89 e0 48 6b d8 18 RIP [] tg3_poll+0x10c/0x82e RSP CR2: f51f3e1c -- Thanks & Regards, Kamalesh Babulal, Linux Technology Center, IBM, ISTL. -- 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] ufs: [bl]e*_add_cpu conversion
On Wed, 13 Feb 2008 10:41:44 +0100 Roel Kluin <[EMAIL PROTECTED]> wrote:
> you may also want these:
> ---
> [bl]e_add_cpu conversion in return
>
> Signed-off-by: Roel Kluin <[EMAIL PROTECTED]>
> ---
> diff --git a/fs/ufs/swab.h b/fs/ufs/swab.h
> index 1683d2b..a1e3000 100644
> --- a/fs/ufs/swab.h
> +++ b/fs/ufs/swab.h
> @@ -44,18 +44,22 @@ static __inline u32
> fs64_add(struct super_block *sbp, u32 *n, int d)
> {
> if (UFS_SB(sbp)->s_bytesex == BYTESEX_LE)
> - return *n = cpu_to_le64(le64_to_cpu(*n)+d);
> + le64_add_cpu(n, d);
> else
> - return *n = cpu_to_be64(be64_to_cpu(*n)+d);
> + be64_add_cpu(n, d);
> +
> + return *n;
> }
>
> static __inline u32
> fs64_sub(struct super_block *sbp, u32 *n, int d)
> {
> if (UFS_SB(sbp)->s_bytesex == BYTESEX_LE)
> - return *n = cpu_to_le64(le64_to_cpu(*n)-d);
> + le64_add_cpu(n, -d);
> else
> - return *n = cpu_to_be64(be64_to_cpu(*n)-d);
> + be64_add_cpu(n, -d);
> +
> + return *n;
> }
>
> static __inline u32
upsets powerpc (at least):
fs/ufs/swab.h: In function `fs64_add':
fs/ufs/swab.h:47: warning: passing arg 1 of `le64_add_cpu' from incompatible
pointer type
fs/ufs/swab.h:49: warning: passing arg 1 of `be64_add_cpu' from incompatible
pointer type
fs/ufs/swab.h: In function `fs64_sub':
fs/ufs/swab.h:58: warning: passing arg 1 of `le64_add_cpu' from incompatible
pointer type
fs/ufs/swab.h:60: warning: passing arg 1 of `be64_add_cpu' from incompatible
pointer type
--
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: pci_device_id definition cleanups
On Sat, Feb 16, 2008 at 03:23:36AM +0100, Sam Ravnborg wrote:
> On Sat, Feb 16, 2008 at 12:21:40AM +0100, Jonas Bonn wrote:
> > I've done some work on cleaning up the definitions of pci_device_id to
> > make them "static const" (where possible) and to make sure they go into
> > __devinitconst. There are about 350 changes of the type shown in the
> > diff at the end of this mail.
> >
> > ???All these changes are in my public GIT tree at:
> >
> > git://www.southpole.se/~jonas/git/linux.git
> >
> > (Based on 2.6.25-rc2)
> >
> > In addition to these pci_device_id changes, there are a few changesets
> > that move "const" data from __devinitdata to __devinitconst.
> >
> > The tree above builds with both allmodconfig and allyesconfig.
>
> Hi Jonas.
>
> Can I ask you to try the same with ARCH=powerpc
> (or alpha or ia64).
> Becasue it is for these architectures we see issues with
> defining data const.
I pulled his tree and tried building on powerpc w/ gcc 4.3, it passed.
I'm not too excited about the extremely long open-coded variable
definitions everywhere now though. Wouldn't it be better to just do a
macro for it?
Something like:
#define PCI_DEVICE_TABLE(_var) static const struct pci_device_id _var[]
__devinitconst
And then just:
PCI_DEVICE_TABLE(mydevice_tbl) = {
...
};
-Olof
--
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.24-git16 Oops @ sysfs_move_dir w/ btdelconn
On Fri, Feb 15, 2008 at 6:15 PM, Dave Young <[EMAIL PROTECTED]> wrote: > > On Fri, Feb 15, 2008 at 8:04 AM, Barnaby <[EMAIL PROTECTED]> wrote: > > Answers at the bottom.. > > > > > > > > On 2/13/08, Dave Young <[EMAIL PROTECTED]> wrote: > > > On Feb 8, 2008 12:57 AM, Barnaby <[EMAIL PROTECTED]> wrote: > > > > Hello Dave, > > > > > > Add someone to cc-list > > > > > > > > > > > > > > Got your name and email from the 2.6.24-git16 changelog. > > > > > > > > I get these Oops when suspending or doing.. > > > > > > > > echo disable > /proc/acpi/ibm/bluetooth > > > > or > > > > echo 0 > /sys/devices/platform/thinkpad_acpi/bluetooth_enable > > > > > > > > # - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > > > > > > > Feb 7 09:19:47 BUG: unable to handle kernel NULL pointer > dereference > > > > at 0008 > > > > Feb 7 09:19:47 IP: [] sysfs_move_dir+0x16/0x1ab > > > > Feb 7 09:19:47 *pde = > > > > Feb 7 09:19:47 Oops: [#1] PREEMPT > > > > Feb 7 09:19:47 Modules linked in: xt_tcpudp hidp l2cap snd_seq > > > > snd_seq_device snd_pcm_oss snd_mixer_oss sr_mod cdrom iptable_filter > > > > iptable_nat nf_conntrack_ipv4 iptable_mangle ipt_LOG xt_state ipt_ttl > > > > ipt_MASQUERADE nf_nat nf_conntrack xt_DSCP ip_tables x_tables > usbhid > > > > ipw2200 ieee80211 ieee80211_crypt thinkpad_acpi backlight > acpi_cpufreq > > > > radeon drm intel_agp agpgart snd_intel8x0 snd_ac97_codec ac97_bus > > > > snd_pcm snd_timer snd soundcore snd_page_alloc button > > > > thermal processor hci_usb bluetooth > > > > Feb 7 09:19:47 > > > > Feb 7 09:19:47 Pid: 1412, comm: btdelconn Not tainted > (2.6.24-git16 #1) > > > > Feb 7 09:19:47 EIP: 0060:[] EFLAGS: 00010246 CPU: 0 > > > > Feb 7 09:19:47 EIP is at sysfs_move_dir+0x16/0x1ab > > > > Feb 7 09:19:47 EAX: c039476c EBX: f7dd0480 ECX: f6da9f58 EDX: > f7dd0480 > > > > Feb 7 09:19:47 ESI: EDI: f5ea0c40 EBP: fff4 ESP: > f6da9f30 > > > > Feb 7 09:19:47 DS: 007b ES: 007b FS: GS: SS: 0068 > > > > Feb 7 09:19:47 Process btdelconn (pid: 1412, ti=f6da8000 > > > > task=f6fd1550 task.ti=f6da8000) > > > > Feb 7 09:19:47 Stack: f56f4ea4 f7dd0480 f5ea0c40 f56f4ea4 f7dd0480 > > > > f5ea0c40 fff4 c01c71a0 > > > > Feb 7 09:19:47 f5ea0800 c034a793 f5ea0c40 f5ea0800 f5ea0800 > > > > > f56f4e3c > > > > Feb 7 09:19:47 f7dd0480 c0219d48 f56f4ea4 ffea > f56f4e3c > > > > f5fc7c88 f5fc7c00 > > > > Feb 7 09:19:47 Call Trace: > > > > Feb 7 09:19:47 [] kobject_move+0x9e/0xeb > > > > Feb 7 09:19:47 [] device_move+0x41/0xdf > > > > Feb 7 09:19:47 [] del_conn+0x0/0x43 [bluetooth] > > > > Feb 7 09:19:47 [] del_conn+0x11/0x43 [bluetooth] > > > > Feb 7 09:19:47 [] run_workqueue+0x83/0x10e > > > > Feb 7 09:19:47 [] worker_thread+0x0/0xb5 > > > > Feb 7 09:19:47 [] worker_thread+0xab/0xb5 > > > > Feb 7 09:19:47 [] autoremove_wake_function+0x0/0x2d > > > > Feb 7 09:19:47 [] kthread+0x36/0x5c > > > > Feb 7 09:19:47 [] kthread+0x0/0x5c > > > > Feb 7 09:19:47 [] kernel_thread_helper+0x7/0x10 > > > > Feb 7 09:19:47 === > > > > Feb 7 09:19:47 Code: ff b8 6c 47 39 c0 e8 64 f1 15 00 89 f0 83 c4 > 10 > > > > 5b 5e 5f 5d c3 55 57 56 53 89 d3 83 ec 0c 8b 70 1c b8 6c 47 39 c0 e8 > > > > 3a f1 15 00 <8b> 56 08 85 d2 75 04 0f 0b eb fe 8b 5b 1c b8 a0 47 39 > c0 > > > > 85 db > > > > Feb 7 09:19:47 EIP: [] sysfs_move_dir+0x16/0x1ab SS:ESP > > > > 0068:f6da9f30 > > > > Feb 7 09:19:47 ---[ end trace e0c3df2b167f1367 ]--- > > > > Feb 7 09:27:44 usb 4-1: new full speed USB device using uhci_hcd > and address 4 > > > > Feb 7 09:27:44 usb 4-1: configuration #1 chosen from 1 choice > > > > Feb 7 09:28:06 BUG: unable to handle kernel NULL pointer > dereference > > > > at 0020 > > > > Feb 7 09:28:06 IP: [] sysfs_addrm_start+0x1e/0x7a > > > > Feb 7 09:28:06 *pde = > > > > Feb 7 09:28:06 Oops: [#2] PREEMPT > > > > Feb 7 09:28:06 Modules linked in: xt_tcpudp hidp l2cap snd_seq > > > > snd_seq_device snd_pcm_oss snd_mixer_oss sr_mod cdrom iptable_filter > > > > iptable_nat nf_conntrack_ipv4 iptable_mangle ipt_LOG xt_state ipt_ttl > > > > ipt_MASQUERADE nf_nat nf_conntrack xt_DSCP ip_tables x_tables > usbhid > > > > ipw2200 ieee80211 ieee80211_crypt thinkpad_acpi backlight > acpi_cpufreq > > > > radeon drm intel_agp agpgart snd_intel8x0 snd_ac97_codec ac97_bus > > > > snd_pcm snd_timer snd soundcore snd_page_alloc button > > > > thermal processor hci_usb bluetooth > > > > Feb 7 09:28:06 > > > > Feb 7 09:28:06 Pid: 11774, comm: hidd Tainted: G D > (2.6.24-git16 #1) > > > > Feb 7 09:28:06 EIP: 0060:[] EFLAGS: 00010246 CPU: 0 > > > > Feb 7 09:28:06
common watchdog interface: handling of suspend/resume
i'm not sure if it is possible to integrate this into the common code (be great if we could), but we should codify the expected behavior for the suspend/resume functions. from looking at the 8 that implement the pm functions, they seem to all do: suspend(): turn off the watchdog resume(): turn on the watchdog if it was running some other issues raised: - this device should not be able to be selective suspended ... in other words, you only want to "suspend" the watchdog if the whole system is going to be suspend - should the nowayout option be checked at all ? -mike -- 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] (02/15/08 Linus git) Smack unlabeled outgoing ambient packets - v4
--- Paul Moore <[EMAIL PROTECTED]> wrote: > On Friday 15 February 2008 6:24:25 pm Casey Schaufler wrote: > > From: Casey Schaufler <[EMAIL PROTECTED]> > > > > Smack uses CIPSO labeling, but allows for unlabeled packets > > by specifying an "ambient" label that is applied to incoming > > unlabeled packets. Because the other end of the connection > > may dislike IP options, and ssh is one know application that > > behaves thus, it is prudent to respond in kind. This patch > > changes the network labeling behavior such that an outgoing > > packet that would be given a CIPSO label that matches the > > ambient label is left unlabeled. An "unlbl" domain is added > > and the netlabel defaulting mechanism invoked rather than > > assuming that everything is CIPSO. Locking has been added > > around changes to the ambient label as the mechanisms used > > to do so are more involved. > > > > Cleaned up some issues noted in review. > > Make smk_cipso_doi() static. > > Create a hook for the new security_secctx_to_secid() > > using existing underlying code. > > Fill in audit data for netlbl domain calls. > > Collapse unnecessary multiple assignments. > > > > Signed-off-by: Casey Schaufler <[EMAIL PROTECTED]> > > Looks good to me, thanks for making those changes. > > Acked-by: Paul Moore <[EMAIL PROTECTED]> Thank you for the insights. Casey Schaufler [EMAIL PROTECTED] -- 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] correct inconsistent ntp interval/tick_length usage
Hi, On Wed, 13 Feb 2008, john stultz wrote: > Oh! So your issue is that since time_freq is stored in ppm, or in effect > a usecs per sec offset, when we add it to something other then 1 second > we mis-apply what NTP tells us to. Is that right? Pretty much everything is centered around that 1sec, so the closer the update frequency is to it the better. > Right, so if NTP has us apply a 10ppm adjustment, instead of doing: > NSEC_PER_SEC + 10,000 > > We're doing: > NSEC_PER_SEC + CLOCK_TICK_ADJUST + 10,000 > > Which, if I'm doing my math right, results in a 10.002ppm adjustment > (using the 999847467ns number above), instead of just a 10ppm > adjustment. > > Now, true, this is an error, but it is a pretty small one. Even at the > maximum 500ppm value, it only results in an error of 76 parts per > billion. As you'll see below, that tends to be less error then what we > get from the clock granularity. Is there something else I'm missing here > or is this really the core issue you're concerned with? The error accumulates and there is no good reason to do this for the common case. > > In consequence this means, if we want to improve timekeeping, we first set > > the (update_cycles * NTP_INTERVAL_FREQ) interval as close as possible to > > the real frequency. It doesn't has to be perfect as we usually don't know > > the real frequency with 100% certainty anyway. > > This might need some more explanation, as I'm not certain I know what > update_cycles refers to. Do you mean cycle_interval? I guess I'm not > completely sure how you're suggesting we change things here. clock->cycle_interval > > Second, we drop the tick > > adjustment if possible and leave the adjustments to the NTP daemon and as > > long as the drift is within the 500ppm limit it has no problem to manage > > this. > > Dropping the tick adjustment? By that do you mean the tick_usec value > set by adjtimex()? I don't quite see why we want that. Could you expand > here? CLOCK_TICK_ADJUST > HZ=1000 CLOCK_TICK_ADJUST=-152533 > jiffies 467 ppb error > jiffies NOHZ 467 ppb error > pit 0 ppb error > pit NOHZ 0 ppb error > acpi_pm -280 ppb error > acpi_pm NOHZ 279 ppb error > > HZ=1000 CLOCK_TICK_ADJUST=0 > jiffies 153000 ppb error > jiffies NOHZ 153000 ppb error > pit 152533 ppb error > pit NOHZ 0 ppb error > acpi_pm -127112 ppb error > acpi_pm NOHZ 279 ppb error > > So you are right, w/ pit & NO_HZ, the granularity error is always very > small both with or without CLOCK_TICK_ADJUST. If you change the frequency of acpi_pm to 3579000 you'll get this: HZ=1000 CLOCK_TICK_ADJUST=0 jiffies 153000 ppb error jiffies NOHZ153000 ppb error pit 152533 ppb error pit NOHZ0 ppb error acpi_pm 0 ppb error acpi_pm NOHZ0 ppb error HZ=1000 CLOCK_TICK_ADJUST=-152533 jiffies 0 ppb error jiffies NOHZ466 ppb error pit -467 ppb error pit NOHZ-1 ppb error acpi_pm 126407 ppb error acpi_pm NOHZ22 ppb error CLOCK_TICK_ADJUST has only any meaning for PIT (and indirectly for jiffies). For every other clock you just add some random value, where it doesn't do _any_ good. The worst case error there will always be (ntp_hz/freq/2*10^9nsec), all you do with CLOCK_TICK_ADJUST is to do shift it around, but it doesn't actually fix the error - it's still there. > However, without CLOCK_TICK_ADJUST, the jiffies error increases for all > values of HZ except 100 (which at first seems odd, but seems to be due > to loss from rounding in the ACTHZ calculation). jiffies depends on the timer resolution, so it will practically produce the same results as PIT (assuming it's used to generate the timer tick). > One interesting surprise in the data: With CLOCK_TICK_ADJUST=0, the > acpi_pm's error frequency shot up in the !NO_HZ cases. This ends up > being due to the acpi_pm being a very close to a multiple (3x) of the > pit frequency, so CLOCK_TICK_ADJUST helps it as well. What exactly does it help with? All you are doing is number cosmetics, it has _no_ practically value and only decreases the quality of timekeeping. > Further it seems to point that if we are going to be chasing down small > sub-100ppb errors (which I think would be great to do, but lets not make > users to endure 200+ppm errors while we debate the fine-tuning :) we > might want to consider a method where we let ntp_update_freq take into > account the current clocksource's interval length, so it becomes the > base value against which we apply adjustments (scaled appropriately). The error at least is real, the use value of CLOCK_TICK_ADJUST for the common case is not existent. > There are 3 sources of error that we've discussed here: > 1) The large (280ppm) error seen with no-NTP adjustment, caused by the > inconsistent (A!=B) interval comparisons which started this discussion, > which my patch does address. Part of the error is caused by CLOCK
Re: [RFC][PATCH 0/7] CGroup API: More structured API for CGroups control files
On Fri, 15 Feb 2008 12:44:18 -0800 Paul Menage <[EMAIL PROTECTED]> wrote: > > This set of patches makes the Control Groups API more structured and > self-describing. > > 1) Allows control files to be associated with data types such as > "u64", "string", "map", etc. These types show up in a new cgroup.api > file in each cgroup directory, along with a user-readable > string. Files that use cgroup-provided data accessors have these file > types inferred automatically. > > 2) Moves various files in cpusets and the memory controller from using > custom-written file handlers to cgroup-defined handlers > > 3) Adds the "cgroup." prefix for existing cgroup-provided control > files (tasks, release_agent, releasable, notify_on_release). Given > than we've already had 2.6.24 go out without this prefix, I guess this > could be a little contentious - but it seems like a good move to > prevent name clashes in the future. (Note that this doesn't affect > mounting the legacy cpuset filesystem, since the compatibility layer > disables all prefixes when mounted with filesystem type "cpuset"). If > people object too strongly, we could just make this the case for *new* > cgroup API files, but I think this is a case where consistency would > be better than compatibility - I'd be surprised if anyone has written > major legacy apps yet that rely on 2.6.24 cgroup control file names. > Hi, I like this direction very much. thank you for your work. Self-describing cgroup.api file is a good idea! One request from me is add "mode" bit to cftype for allowing write-only/read-only files. Thanks, -Kame -- 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] udf: fix sparse warning in namei.c
Let's use bsize instead.
fs/udf/namei.c:960:12: warning: symbol 'elen' shadows an earlier one
fs/udf/namei.c:937:15: originally declared here
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
fs/udf/namei.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/udf/namei.c b/fs/udf/namei.c
index 112a5fb..e1c1492 100644
--- a/fs/udf/namei.c
+++ b/fs/udf/namei.c
@@ -957,7 +957,7 @@ static int udf_symlink(struct inode *dir, struct dentry
*dentry,
if (iinfo->i_alloc_type != ICBTAG_FLAG_AD_IN_ICB) {
kernel_lb_addr eloc;
- uint32_t elen;
+ uint32_t bsize;
block = udf_new_block(inode->i_sb, inode,
iinfo->i_location.partitionReferenceNum,
@@ -970,9 +970,9 @@ static int udf_symlink(struct inode *dir, struct dentry
*dentry,
eloc.logicalBlockNum = block;
eloc.partitionReferenceNum =
iinfo->i_location.partitionReferenceNum;
- elen = inode->i_sb->s_blocksize;
- iinfo->i_lenExtents = elen;
- udf_add_aext(inode, &epos, eloc, elen, 0);
+ bsize = inode->i_sb->s_blocksize;
+ iinfo->i_lenExtents = bsize;
+ udf_add_aext(inode, &epos, eloc, bsize, 0);
brelse(epos.bh);
block = udf_get_pblock(inode->i_sb, block,
--
1.5.4.1.1278.gc75be
--
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.25-rc2 vdso_install breaks user "make install"
On 16-02-08 04:42, Roland McGrath wrote: Perhaps it makes more sense to have vdso_install be a dependency of modules_install rather than install, since they both put things in /lib/modules. Would work for me -- modules_install ofcourse runs as root. The installed vdso images are potentially useful for a kernel when you aren't bothering to build or install any modules, but those images are only ever useful for sophisticated debugging uses anyway. Sam, any thoughts? (See arch/x86/Makefile and arch/powerpc/Makefile.) Or maybe update the installkernel "protocol" to add these in? The only kind of install runs I actually care about are for packaging system builds. There the packaged build does 'make vdso_install' explicitly anyway (at least Fedora rpms' .spec does). So if the consensus is just to drop the dependency on vdso_install completely, I don't object. Did that for now... Rene. -- 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] Preempt realtime Oops syslog
Add bust_spinlocks when kernel die from do_trap to flush Oops
dump to syslog immediatly. Oops is missing from syslog if it is from
non-preemptible section, because on PREEMPT_RT kernel, Oops printk
doesn't wake up klogd from non-preemptible context; see
release_console_sem in kernel/printk.c.
Tested by Oops in module_init and insmod that kernel module. The
Oops is in non-preemptive context because modules are loaded from
inside a realtime priority thread in a preemptive realtime kernel.
Only apply to PPC arch because bust_spinlocks has already been used
by x86 and other architectures
Signed-off-by: Min Zhang <[EMAIL PROTECTED]>
Index: rt-2.6/arch/ppc/kernel/traps.c
===
--- rt-2.6.orig/arch/ppc/kernel/traps.c
+++ rt-2.6/arch/ppc/kernel/traps.c
@@ -92,6 +92,7 @@ int die(const char * str, struct pt_regs
if (nl)
printk("\n");
show_regs(fp);
+ bust_spinlocks(0);
add_taint(TAINT_DIE);
spin_unlock_irq(&die_lock);
/* do_exit() should take care of panic'ing from an interrupt
--
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] Preempt realtime printk syslog
Add 50s timeout in do_syslog to poll printk from non-preemptible
section. printk is missing from syslog if from non-preemptible
section, because on PREEMPT_RT kernels, printk doesn't wake up syslogd
from non-preemptible section; see release_console_sem in
kernel/printk.c.
Tested by printk in module_init and insmod that kernel module. The
printk is in non-preemptive context because modules are loaded from
inside a realtime priority thread in a preemptive realtime kernel.
Signed-off-by: Min Zhang <[EMAIL PROTECTED]>
Index: rt-2.6/kernel/printk.c
===
--- rt-2.6.orig/kernel/printk.c
+++ rt-2.6/kernel/printk.c
@@ -116,6 +116,12 @@ static int preferred_console = -1;
/* Flag: console code may call schedule() */
static int console_may_schedule;
+/* minimum time in jiffies between messages */
+int printk_ratelimit_jiffies = 5 * HZ;
+
+/* number of messages we send before ratelimiting */
+int printk_ratelimit_burst = 10;
+
#ifdef CONFIG_PRINTK
static char __log_buf[__LOG_BUF_LEN];
@@ -313,10 +319,26 @@ int do_syslog(int type, char __user *buf
error = -EFAULT;
goto out;
}
+#ifdef CONFIG_PREEMPT_RT
+ /*
+* On PREEMPT_RT kernels release_console_sem wakes us only if
+* in preemptible section, so timeout to poll for printk from
+* non-preemptible sections.
+*/
+ i = printk_ratelimit_burst * printk_ratelimit_jiffies;
+ error = wait_event_interruptible_timeout(log_wait,
+(log_start - log_end),
+i);
+ if (error < 0)
+ goto out;
+ else
+ error = 0;
+#else
error = wait_event_interruptible(log_wait,
(log_start - log_end));
if (error)
goto out;
+#endif
i = 0;
spin_lock_irq(&logbuf_lock);
while (!error && (log_start != log_end) && i < len) {
@@ -1272,12 +1294,6 @@ int __printk_ratelimit(int ratelimit_jif
}
EXPORT_SYMBOL(__printk_ratelimit);
-/* minimum time in jiffies between messages */
-int printk_ratelimit_jiffies = 5 * HZ;
-
-/* number of messages we send before ratelimiting */
-int printk_ratelimit_burst = 10;
-
int printk_ratelimit(void)
{
return __printk_ratelimit(printk_ratelimit_jiffies,
--
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.25-rc2 vdso_install breaks user "make install"
Perhaps it makes more sense to have vdso_install be a dependency of modules_install rather than install, since they both put things in /lib/modules. The installed vdso images are potentially useful for a kernel when you aren't bothering to build or install any modules, but those images are only ever useful for sophisticated debugging uses anyway. Sam, any thoughts? (See arch/x86/Makefile and arch/powerpc/Makefile.) The only kind of install runs I actually care about are for packaging system builds. There the packaged build does 'make vdso_install' explicitly anyway (at least Fedora rpms' .spec does). So if the consensus is just to drop the dependency on vdso_install completely, I don't object. Thanks, Roland -- 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] Best method to control a "transmit-only" mode on fiber NICs (specifically sky2)
Hi,
The company I'm working for has an unusual fiber NIC configuration
that we use for one of our network appliances. We connect only a
single fiber from the TX port on one NIC to the RX port on another
NIC, providing a physically-one-way path for enhanced security.
Unfortunately this doesn't work with most NIC drivers, as even with
auto-negotiation off they look for link probe pulses before they
consider the link "up" and are willing to send packets. We have been
able to use Myricom 10GigE NICs with a custom firmware image. More
recently we have patched the sky2 driver to turn on the FIB_FORCE_LNK
flag in the PHY control register; this seems to work on the
Marvell-chipset boards we have here.
What would be the preferred way to control this "force link" flag?
Right now we are accessing it using ethtool; we have added an
additional "duplex" mode: "DUPLEX_TXONLY", with a value of 2. When
you specify a speed and turn off autonegotiation ("./patched-ethtool
-s eth2 speed 1000 autoneg off duplex txonly"), it will turn on the
specified bit in the PHY control register and the link will
automatically come up. We also have one related bug-fix^Wdirty hack
for sky2 to reset the PHY a second time during netif-up after enabling
interrupts; otherwise the immediate "link up" interrupt gets lost.
Once I get approval from the company I will patch the post itself for
review.
I look forward to your comments and suggestions
Cheers,
Kyle Moffett
--
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 5/6] mmu_notifier: Support for drivers with revers maps (f.e. for XPmem)
On Thu, 14 Feb 2008 22:49:04 -0800 Christoph Lameter <[EMAIL PROTECTED]> wrote:
> These special additional callbacks are required because XPmem (and likely
> other mechanisms) do use their own rmap (multiple processes on a series
> of remote Linux instances may be accessing the memory of a process).
> F.e. XPmem may have to send out notifications to remote Linux instances
> and receive confirmation before a page can be freed.
>
> So we handle this like an additional Linux reverse map that is walked after
> the existing rmaps have been walked. We leave the walking to the driver that
> is then able to use something else than a spinlock to walk its reverse
> maps. So we can actually call the driver without holding spinlocks while
> we hold the Pagelock.
>
> However, we cannot determine the mm_struct that a page belongs to at
> that point. The mm_struct can only be determined from the rmaps by the
> device driver.
>
> We add another pageflag (PageExternalRmap) that is set if a page has
> been remotely mapped (f.e. by a process from another Linux instance).
> We can then only perform the callbacks for pages that are actually in
> remote use.
>
> Rmap notifiers need an extra page bit and are only available
> on 64 bit platforms. This functionality is not available on 32 bit!
>
> A notifier that uses the reverse maps callbacks does not need to provide
> the invalidate_page() method that is called when locks are held.
>
hrm.
> +#define mmu_rmap_notifier(function, args...) \
> + do {\
> + struct mmu_rmap_notifier *__mrn;\
> + struct hlist_node *__n; \
> + \
> + rcu_read_lock();\
> + hlist_for_each_entry_rcu(__mrn, __n,\
> + &mmu_rmap_notifier_list, hlist) \
> + if (__mrn->ops->function) \
> + __mrn->ops->function(__mrn, args); \
> + rcu_read_unlock(); \
> + } while (0);
> +
buggy macro: use locals.
> +#define mmu_rmap_notifier(function, args...) \
> + do {\
> + if (0) {\
> + struct mmu_rmap_notifier *__mrn;\
> + \
> + __mrn = (struct mmu_rmap_notifier *)(0x00ff); \
> + __mrn->ops->function(__mrn, args); \
> + } \
> + } while (0);
> +
Same observation as in the other patch.
> ===
> --- linux-2.6.orig/mm/mmu_notifier.c 2008-02-14 21:17:51.0 -0800
> +++ linux-2.6/mm/mmu_notifier.c 2008-02-14 21:21:04.0 -0800
> @@ -74,3 +74,37 @@ void mmu_notifier_unregister(struct mmu_
> }
> EXPORT_SYMBOL_GPL(mmu_notifier_unregister);
>
> +#ifdef CONFIG_64BIT
> +static DEFINE_SPINLOCK(mmu_notifier_list_lock);
> +HLIST_HEAD(mmu_rmap_notifier_list);
> +
> +void mmu_rmap_notifier_register(struct mmu_rmap_notifier *mrn)
> +{
> + spin_lock(&mmu_notifier_list_lock);
> + hlist_add_head_rcu(&mrn->hlist, &mmu_rmap_notifier_list);
> + spin_unlock(&mmu_notifier_list_lock);
> +}
> +EXPORT_SYMBOL(mmu_rmap_notifier_register);
> +
> +void mmu_rmap_notifier_unregister(struct mmu_rmap_notifier *mrn)
> +{
> + spin_lock(&mmu_notifier_list_lock);
> + hlist_del_rcu(&mrn->hlist);
> + spin_unlock(&mmu_notifier_list_lock);
> +}
> +EXPORT_SYMBOL(mmu_rmap_notifier_unregister);
>
> +/*
> + * Export a page.
> + *
> + * Pagelock must be held.
> + * Must be called before a page is put on an external rmap.
> + */
> +void mmu_rmap_export_page(struct page *page)
> +{
> + BUG_ON(!PageLocked(page));
> + SetPageExternalRmap(page);
> +}
> +EXPORT_SYMBOL(mmu_rmap_export_page);
The other patch used EXPORT_SYMBOL_GPL.
--
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 2/6] mmu_notifier: Callbacks to invalidate address ranges
On Thu, 14 Feb 2008 22:49:01 -0800 Christoph Lameter <[EMAIL PROTECTED]> wrote: > The invalidation of address ranges in a mm_struct needs to be > performed when pages are removed or permissions etc change. hm. Do they? Why? If I'm in the process of zero-copy writing a hunk of memory out to hardware then do I care if someone write-protects the ptes? Spose so, but some fleshing-out of the various scenarios here would clarify things. > If invalidate_range_begin() is called with locks held then we > pass a flag into invalidate_range() to indicate that no sleeping is > possible. Locks are only held for truncate and huge pages. This is so bad. I supposed in the restricted couple of cases which you're focussed on it works OK. But is it generally suitable? What if IO is in progress? What if other cluster nodes need to be talked to? Does it suit RDMA? > In two cases we use invalidate_range_begin/end to invalidate > single pages because the pair allows holding off new references > (idea by Robin Holt). Assuming that there is a missing "within the range" in this description, I assume that all clients will just throw up theior hands in horror and will disallow all references to all parts of the mm. Of course, to do that they will need to take a sleeping lock to prevent other threads from establishing new references. whoops. > do_wp_page(): We hold off new references while we update the pte. > > xip_unmap: We are not taking the PageLock so we cannot > use the invalidate_page mmu_rmap_notifier. invalidate_range_begin/end > stands in. What does "stands in" mean? > Signed-off-by: Andrea Arcangeli <[EMAIL PROTECTED]> > Signed-off-by: Robin Holt <[EMAIL PROTECTED]> > Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> > > --- > mm/filemap_xip.c |5 + > mm/fremap.c |3 +++ > mm/hugetlb.c |3 +++ > mm/memory.c | 35 +-- > mm/mmap.c|2 ++ > mm/mprotect.c|3 +++ > mm/mremap.c |7 ++- > 7 files changed, 51 insertions(+), 7 deletions(-) > > Index: linux-2.6/mm/fremap.c > === > --- linux-2.6.orig/mm/fremap.c2008-02-14 18:43:31.0 -0800 > +++ linux-2.6/mm/fremap.c 2008-02-14 18:45:07.0 -0800 > @@ -15,6 +15,7 @@ > #include > #include > #include > +#include > > #include > #include > @@ -214,7 +215,9 @@ asmlinkage long sys_remap_file_pages(uns > spin_unlock(&mapping->i_mmap_lock); > } > > + mmu_notifier(invalidate_range_begin, mm, start, start + size, 0); > err = populate_range(mm, vma, start, size, pgoff); > + mmu_notifier(invalidate_range_end, mm, start, start + size, 0); To avoid off-by-one confusion the changelogs, documentation and comments should be very careful to tell the reader whether the range includes the byte at start+size. I don't thik that was done? -- 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 3/6] mmu_notifier: invalidate_page callbacks
On Thu, 14 Feb 2008 22:49:02 -0800 Christoph Lameter <[EMAIL PROTECTED]> wrote:
> Two callbacks to remove individual pages as done in rmap code
>
> invalidate_page()
>
> Called from the inner loop of rmap walks to invalidate pages.
>
> age_page()
>
> Called for the determination of the page referenced status.
>
> If we do not care about page referenced status then an age_page callback
> may be be omitted. PageLock and pte lock are held when either of the
> functions is called.
The age_page mystery shallows.
It would be useful to have some rationale somewhere in the patchset for the
existence of this callback.
> #include
>
> @@ -287,7 +288,8 @@ static int page_referenced_one(struct pa
> if (vma->vm_flags & VM_LOCKED) {
> referenced++;
> *mapcount = 1; /* break early from loop */
> - } else if (ptep_clear_flush_young(vma, address, pte))
> + } else if (ptep_clear_flush_young(vma, address, pte) |
> +mmu_notifier_age_page(mm, address))
> referenced++;
The "|" is obviously deliberate. But no explanation is provided telling us
why we still call the callback if ptep_clear_flush_young() said the page
was recently referenced. People who read your code will want to understand
this.
> /* Pretend the page is referenced if the task has the
> @@ -455,6 +457,7 @@ static int page_mkclean_one(struct page
>
> flush_cache_page(vma, address, pte_pfn(*pte));
> entry = ptep_clear_flush(vma, address, pte);
> + mmu_notifier(invalidate_page, mm, address);
I just don't see how ths can be done if the callee has another thread in
the middle of establishing IO against this region of memory.
->invalidate_page() _has_ to be able to block. Confused.
--
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] do_signal_stop: use signal_group_exit()
ug. On about the fourth boot with the current -mm lineup I hit: : security: permission sendto in class node not defined in policy : security: permission dccp_recv in class netif not defined in policy : security: permission dccp_send in class netif not defined in policy : security: permission ingress in class netif not defined in policy : security: permission egress in class netif not defined in policy : security: permission setfcap in class capability not defined in policy : security: permission forward_in in class packet not defined in policy : security: permission forward_out in class packet not defined in policy : SELinux: policy loaded with handle_unknown=deny : type=1403 audit(1203124656.152:3): policy loaded auid=4294967295 ses=4294967295 : BUG: unable to handle kernel paging request at 00200200 : IP: [] free_pid+0x35/0x8e : PGD 2574cb067 PUD 257561067 PMD 0 : Oops: 0002 [1] SMP : last sysfs file: /sys/class/net/eth0/address : CPU 2 : Modules linked in: ipv6 dm_mirror dm_multipath dm_mod sbs sbshc dock battery ac parport_pc lp parport snd_hda_intel snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq shpchp snd_seq_device sg snd_pcm_oss snd_mixer_oss snd_pcm floppy snd_timer button i2c_i801 snd soundcore ide_cd_mod cdrom serio_raw i2c_core snd_page_alloc pcspkr ehci_hcd ohci_hcd uhci_hcd : Pid: 3132, comm: ifup-eth Not tainted 2.6.25-rc2-mm1 #5 : RIP: 0010:[] [] free_pid+0x35/0x8e : RSP: 0018:81025754de58 EFLAGS: 00010046 : RAX: RBX: 81025f268840 RCX: 81025f263f08 : RDX: 00200200 RSI: 0046 RDI: : RBP: 81025f263ec0 R08: 81025f268b18 R09: 81025f268b08 : R10: 81025f268b08 R11: R12: 810259853140 : R13: 0c78 R14: R15: : FS: 7f8f9ba7d6f0() GS:81025f16f0c0() knlGS: : CS: 0010 DS: ES: CR0: 8005003b : CR2: 00200200 CR3: 0002598d CR4: 06e0 : DR0: DR1: DR2: : DR3: DR6: 0ff0 DR7: 0400 : Process ifup-eth (pid: 3132, threadinfo 81025754c000, task 81025d467620) : Stack: 81025f268b08 81025f268840 81025994b660 80237727 : 81025994b660 81025994b660 80237f81 : 05d0 810257561018 7fffa3aa9514 : Call Trace: : [] ? release_task+0x152/0x2e5 : [] ? do_wait+0x6c7/0xa1c : [] ? default_wake_function+0x0/0xe : [] ? sys_rt_sigaction+0x7a/0x98 : [] ? sys_wait4+0x8a/0xa1 : [] ? system_call_after_swapgs+0x7b/0x80 : : : Code: 80 53 41 51 e8 83 d4 28 00 31 ff 48 89 c6 eb 2e 48 63 c7 48 c1 e0 05 48 8d 44 28 40 48 8d 48 08 48 8b 40 08 48 8b 51 08 48 85 c0 <48> 89 02 74 04 48 89 50 08 48 c7 41 08 00 02 20 00 ff c7 3b 7d : RIP [] free_pid+0x35/0x8e : RSP : CR2: 00200200 : ---[ end trace efde415d3f801416 ]--- : BUG: sleeping function called from invalid context at kernel/rwsem.c:21 : in_atomic():0, irqs_disabled():1 : Pid: 3132, comm: ifup-eth Tainted: G D 2.6.25-rc2-mm1 #5 : : Call Trace: : [] down_read+0x15/0x23 : [] acct_collect+0x40/0x180 : [] do_exit+0x1f3/0x6ba : [] sync_regs+0x0/0x67 : [] do_page_fault+0x755/0x80e : [] error_exit+0x0/0x51 : [] free_pid+0x35/0x8e : [] free_pid+0x13/0x8e : [] release_task+0x152/0x2e5 : [] do_wait+0x6c7/0xa1c : [] default_wake_function+0x0/0xe : [] sys_rt_sigaction+0x7a/0x98 : [] sys_wait4+0x8a/0xa1 : [] system_call_after_swapgs+0x7b/0x80 : : eth0: no IPv6 routers present : and I don't have a clue which patch caused it and I won't be near this machine again for over a week. -- 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/6] mmu_notifier: Core code
On Thu, 14 Feb 2008 22:49:00 -0800 Christoph Lameter <[EMAIL PROTECTED]> wrote: > MMU notifiers are used for hardware and software that establishes > external references to pages managed by the Linux kernel. These are > page table entriews or tlb entries or something else that allows > hardware (such as DMA engines, scatter gather devices, networking, > sharing of address spaces across operating system boundaries) and > software (Virtualization solutions such as KVM, Xen etc) to > access memory managed by the Linux kernel. > > The MMU notifier will notify the device driver that subscribes to such > a notifier that the VM is going to do something with the memory > mapped by that device. The device must then drop references for the > indicated memory area. The references may be reestablished later. > > The notification scheme is much better than the current schemes of > avoiding the danger of the VM removing pages that are externally > mapped. We currently either mlock pages used for RDMA, XPmem etc > in memory or increase the refcount to pin the pages. Increasing > the refcount makes it impossible for the VM to reclaim the page. > > Mlock causes problems with reclaim and may lead to OOM if too many > pages are pinned in memory. It is also incorrect in terms what the POSIX > specificies for what role mlock should play. Mlock does *not* pin pages in > memory. Mlock just means do not allow the page to be moved to swap. > > Linux can move pages in memory (for example through the page migration > mechanism). These pages can be moved even if they are mlocked(). > The current approach of page pinning in use by RDMA etc is conceptually > broken but there are currently no other easy solutions. > > The alternate of increasing the page count to pin pages is also not > that enticing since there will be continual attempts to reclaim > or migrate these pages. > > The solution here allows us to finally fix this issue by requiring > such devices to subscribe to a notification chain that will allow > them to work without pinning. The VM gains control of its memory again > and the memory that has external references can be managed like regular > memory. > > This patch: Core portion > What is the status of getting infiniband to use this facility? How important is this feature to KVM? To xpmem? Which other potential clients have been identified and how important it it to those? > Index: linux-2.6/Documentation/mmu_notifier/README > === > --- /dev/null 1970-01-01 00:00:00.0 + > +++ linux-2.6/Documentation/mmu_notifier/README 2008-02-14 > 22:27:19.0 -0800 > @@ -0,0 +1,105 @@ > +Linux MMU Notifiers > +--- > + > +MMU notifiers are used for hardware and software that establishes > +external references to pages managed by the Linux kernel. These are > +page table entriews or tlb entries or something else that allows > +hardware (such as DMA engines, scatter gather devices, networking, > +sharing of address spaces across operating system boundaries) and > +software (Virtualization solutions such as KVM, Xen etc) to > +access memory managed by the Linux kernel. > + > +The MMU notifier will notify the device driver that subscribes to such > +a notifier that the VM is going to do something with the memory > +mapped by that device. The device must then drop references for the > +indicated memory area. The references may be reestablished later. > + > +The notification scheme is much better than the current schemes of > +dealing with the danger of the VM removing pages. > +We currently mlock pages used for RDMA, XPmem etc in memory or > +increase the refcount of the pages. > + > +Both cause problems with reclaim and may lead to OOM if too many > +pages are pinned in memory. Mlock is also incorrect in terms of the POSIX > +specification of the role of mlock. Mlock does *not* pin pages in > +memory. It just does not allow the page to be moved to swap. > +The page refcount is used to track current users of a page struct. > +Artificially inflating the refcount means that the VM cannot track > +down all references to a page. It will not be able to reclaim or > +move a page. However, the core code will try again and again because > +the assumption is that an elevated refcount is a temporary situation. > + > +Linux can move pages in memory (for example through the page migration > +mechanism). These pages can be moved even if they are mlocked(). > +So the current approach in use by RDMA etc etc is conceptually broken > +but there are currently no other easy solutions. > + > +The solution here allows us to finally fix this issue by requiring > +such devices to subscribe to a notification chain that will allow > +them to work without pinning. > + > +The notifier chains provide two callback mechanisms. The > +first one is required for any device that establishes external mappings. > +The second (rmap) mechanism is require
Re: include/linux/pcounter.h
- First up, why was this added at all? We have percpu_counter.h which has several years development invested in it. afaict it would suit the present applications of pcounters. If some deficiency in percpu_counters has been identified, is it possible to correct that deficiency rather than implementing a whole new counter type? That would be much better. - The comments in pcounter.h appear to indicate that there is a performance advantage (and we infer that the advantage is when the statically-allocated flavour of pcounters is used). When compared with percpu_counters the number of data-reference indirections is the same as with percpu_counters, so no advantage there. And, bizarrely, because of a quite inappropriate abstraction toy, both flavours of pcounters add an indirect function call which I believe is significantly more expensive than a plain old pointer indirection. So it's quite possible that DEFINE_PCOUNTER-style counters consume more memory and are slower than percpu_counters. They will surely be much slower on the read side. More below. If we really want to put some helper wrappers around DEFINE_PER_CPU(s32) then I'd suggest that we should do that as a standalone thing and not attempt to graft the same interface onto two quite different types of storage (DEFINE_PER_CPU and alloc_per_cpu) - The comment "2)" in pcounter.h (which overflows 80 cols and probably wasn't passed through checkpatch) indicates that some other implementation (presumably plain old DEFINE_PER_CPU) will use NR_CPUS*(32+sizeof(void *)) bytes of storage. But DEFINE_PCOUNTER will use as much memory as DEFINE_PER_CPU(s32) and both pcounter_alloc()-style pcounters and percpu_counters use num_possible_cpus()*sizeof(s32)+epsilon. - The CONFIG_SMP=n stubs in pcounter.h are cheesy and are vulnerable to several well-known compilation risks which I always forget. Should be converted to regular static inlines. - the comment in lib/pcounter.c needlessly exceeds 80 cols. - pcounter_dyn_add() will spew a use-of-smp_processor_id()-in-preemptible-code warning if used in places where one could reasonably use it. The interface could do with a bit of a rethink. Or at least some justification and documentation. - pcounter_getval() will be disastrously inefficient if num_possible_cpus() is much greater than num_online_cpus(). It should use for_each_online_cpu() (as does percpu_counter), and implement a CPU hotplug notifier (as does percpu_counter). It will remain grossly inefficient at high CPU counts, unlike percpu_counters, which solved this problem by doing a batched spill into a central counter at add/sub time. The danger here is that someone will actually use this interface in new code. Six months later (when it's too late to fix it) the big-NUMA guys come up and say "whaa, when our user does it disabled interrupts for N milliseconds". - pcounter_getval() can return incorrect negative numbers. This can cause caller malfunctions in very rare situations because callers just don't expect the things which they're counting to go negative. We experienced this during the evolution of percpu_counter. See percpu_counter_sum_positive() and friends. - pcounter_alloc() should return -ENOMEM on allocation error, not "1". - pcounter_free() perhaps shouldn't test for (self->per_cpu_values != NULL), because callers shouldn't be calling it if pcounter_alloc() failed (arguable). afaict the whole implementation can and should be removed and replaced with percpu_counters. I don't think there's much point in its ability to manage DEFINE_PER_CPU counters: pcounter_getval() remains grossly inefficient (and can return negative values) and quite a bit of new code will need to be put in place to address that. But perhaps there are plans to evolve it into something further in the future, I don't know. But I would suggest that the people who have worked upon percpu_counters (principally Gautham, Peter Z, clameter and me) be involved in that work. -- 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 v2] SCSI/gdth: convert to PCI hotplug API
Version 2:
- rediff'd against latest kernel (fix akpm-noticed conflicts)
- remove PCI device sort, which greatly simplifies PCI probe,
permitting direct, per-HBA function calls rather than an indirect
route to the same end result.
- remove need for pcistr[]
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
---
NOTE: MAXHA is still used after this, and must be removed in a separate
patch (after other code is updated).
drivers/scsi/gdth.c | 196 --
1 files changed, 94 insertions(+), 102 deletions(-)
diff --git a/drivers/scsi/gdth.c b/drivers/scsi/gdth.c
index 56c2b91..ad9aff2 100644
--- a/drivers/scsi/gdth.c
+++ b/drivers/scsi/gdth.c
@@ -595,123 +595,111 @@ static int __init gdth_search_isa(ulong32 bios_adr)
#endif /* CONFIG_ISA */
#ifdef CONFIG_PCI
-static void gdth_search_dev(gdth_pci_str *pcistr, ushort *cnt,
-ushort vendor, ushort dev);
+static bool gdth_pci_registered;
-static int __init gdth_search_pci(gdth_pci_str *pcistr)
+static bool gdth_search_vortex(ushort device)
{
-ushort device, cnt;
-
-TRACE(("gdth_search_pci()\n"));
-
-cnt = 0;
-for (device = 0; device <= PCI_DEVICE_ID_VORTEX_GDT6555; ++device)
-gdth_search_dev(pcistr, &cnt, PCI_VENDOR_ID_VORTEX, device);
-for (device = PCI_DEVICE_ID_VORTEX_GDT6x17RP;
- device <= PCI_DEVICE_ID_VORTEX_GDTMAXRP; ++device)
-gdth_search_dev(pcistr, &cnt, PCI_VENDOR_ID_VORTEX, device);
-gdth_search_dev(pcistr, &cnt, PCI_VENDOR_ID_VORTEX,
-PCI_DEVICE_ID_VORTEX_GDTNEWRX);
-gdth_search_dev(pcistr, &cnt, PCI_VENDOR_ID_VORTEX,
-PCI_DEVICE_ID_VORTEX_GDTNEWRX2);
-gdth_search_dev(pcistr, &cnt, PCI_VENDOR_ID_INTEL,
-PCI_DEVICE_ID_INTEL_SRC);
-gdth_search_dev(pcistr, &cnt, PCI_VENDOR_ID_INTEL,
-PCI_DEVICE_ID_INTEL_SRC_XSCALE);
-return cnt;
+ if (device <= PCI_DEVICE_ID_VORTEX_GDT6555)
+ return true;
+ if (device >= PCI_DEVICE_ID_VORTEX_GDT6x17RP &&
+ device <= PCI_DEVICE_ID_VORTEX_GDTMAXRP)
+ return true;
+ if (device == PCI_DEVICE_ID_VORTEX_GDTNEWRX ||
+ device == PCI_DEVICE_ID_VORTEX_GDTNEWRX2)
+ return true;
+ return false;
}
+static int gdth_pci_probe_one(gdth_pci_str *pcistr, gdth_ha_str **ha_out);
+static int gdth_pci_init_one(struct pci_dev *pdev,
+const struct pci_device_id *ent);
+static void gdth_pci_remove_one(struct pci_dev *pdev);
+static void gdth_remove_one(gdth_ha_str *ha);
+
/* Vortex only makes RAID controllers.
* We do not really want to specify all 550 ids here, so wildcard match.
*/
-static struct pci_device_id gdthtable[] __maybe_unused = {
-{PCI_VENDOR_ID_VORTEX,PCI_ANY_ID,PCI_ANY_ID, PCI_ANY_ID},
-{PCI_VENDOR_ID_INTEL,PCI_DEVICE_ID_INTEL_SRC,PCI_ANY_ID,PCI_ANY_ID},
-
{PCI_VENDOR_ID_INTEL,PCI_DEVICE_ID_INTEL_SRC_XSCALE,PCI_ANY_ID,PCI_ANY_ID},
-{0}
+static const struct pci_device_id gdthtable[] = {
+ { PCI_VDEVICE(VORTEX, PCI_ANY_ID) },
+ { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_SRC) },
+ { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_SRC_XSCALE) },
+ { } /* terminate list */
};
-MODULE_DEVICE_TABLE(pci,gdthtable);
+MODULE_DEVICE_TABLE(pci, gdthtable);
-static void __init gdth_search_dev(gdth_pci_str *pcistr, ushort *cnt,
- ushort vendor, ushort device)
+static struct pci_driver gdth_pci_driver = {
+ .name = "gdth",
+ .id_table = gdthtable,
+ .probe = gdth_pci_init_one,
+ .remove = gdth_pci_remove_one,
+};
+
+static void gdth_pci_remove_one(struct pci_dev *pdev)
{
-ulong base0, base1, base2;
-struct pci_dev *pdev;
+ gdth_ha_str *ha = pci_get_drvdata(pdev);
+
+ pci_set_drvdata(pdev, NULL);
+
+ list_del(&ha->list);
+ gdth_remove_one(ha);
+
+ pci_disable_device(pdev);
+}
+
+static int gdth_pci_init_one(struct pci_dev *pdev,
+ const struct pci_device_id *ent)
+{
+ ushort vendor = pdev->vendor;
+ ushort device = pdev->device;
+ ulong base0, base1, base2;
+ int rc;
+ gdth_pci_str gdth_pcistr;
+ gdth_ha_str *ha = NULL;
-TRACE(("gdth_search_dev() cnt %d vendor %x device %x\n",
- *cnt, vendor, device));
+ TRACE(("gdth_search_dev() cnt %d vendor %x device %x\n",
+ gdth_ctr_count, vendor, device));
-pdev = NULL;
-while ((pdev = pci_get_device(vendor, device, pdev))
- != NULL) {
-if (pci_enable_device(pdev))
-continue;
-if (*cnt >= MAXHA) {
-pci_dev_put(pdev);
-return;
-}
+ memset(&gdth_pcistr, 0, sizeof(gdth_pcistr));
+
+ if (vendor == PCI_VENDOR_ID_VORTEX && !gdth_search_vortex(device))
+ return -ENODEV;
+
+ rc = pc
[PATCH 1/2] SCSI/gdth: PCI probe cleanups, prep for PCI hotplug API conversion
- Reduce uses of gdth_pci_str::pdev, preferring a local variable
(or function arg) 'pdev' instead.
- Reduce uses of gdth_pcistr array, preferring local variable
(or function arg) 'pcistr' instead.
- Eliminate lone use of gdth_pci_str::irq, using equivalent
pdev->irq instead
- Eliminate assign-only gdth_pci_str::io_mm
Note: If the indentation seems weird, that's because a line was
converted from spaces to tabs, when it was modified.
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
---
NOTE: this patch series supercedes the previous "gdth: convert to PCI
hotplug API" patch.
drivers/scsi/gdth.c | 59 --
drivers/scsi/gdth.h |2 -
2 files changed, 28 insertions(+), 33 deletions(-)
diff --git a/drivers/scsi/gdth.c b/drivers/scsi/gdth.c
index 6d67f5c..56c2b91 100644
--- a/drivers/scsi/gdth.c
+++ b/drivers/scsi/gdth.c
@@ -653,7 +653,6 @@ static void __init gdth_search_dev(gdth_pci_str *pcistr,
ushort *cnt,
/* GDT PCI controller found, resources are already in pdev */
pcistr[*cnt].pdev = pdev;
-pcistr[*cnt].irq = pdev->irq;
base0 = pci_resource_flags(pdev, 0);
base1 = pci_resource_flags(pdev, 1);
base2 = pci_resource_flags(pdev, 2);
@@ -668,7 +667,6 @@ static void __init gdth_search_dev(gdth_pci_str *pcistr,
ushort *cnt,
!(base1 & IORESOURCE_IO))
continue;
pcistr[*cnt].dpmem = pci_resource_start(pdev, 2);
-pcistr[*cnt].io_mm = pci_resource_start(pdev, 0);
pcistr[*cnt].io= pci_resource_start(pdev, 1);
}
TRACE2(("Controller found at %d/%d, irq %d, dpmem 0x%lx\n",
@@ -913,7 +911,8 @@ static int __init gdth_init_isa(ulong32
bios_adr,gdth_ha_str *ha)
#endif /* CONFIG_ISA */
#ifdef CONFIG_PCI
-static int __init gdth_init_pci(gdth_pci_str *pcistr,gdth_ha_str *ha)
+static int __init gdth_init_pci(struct pci_dev *pdev, gdth_pci_str *pcistr,
+ gdth_ha_str *ha)
{
register gdt6_dpram_str __iomem *dp6_ptr;
register gdt6c_dpram_str __iomem *dp6c_ptr;
@@ -925,14 +924,14 @@ static int __init gdth_init_pci(gdth_pci_str
*pcistr,gdth_ha_str *ha)
TRACE(("gdth_init_pci()\n"));
-if (pcistr->pdev->vendor == PCI_VENDOR_ID_INTEL)
+if (pdev->vendor == PCI_VENDOR_ID_INTEL)
ha->oem_id = OEM_ID_INTEL;
else
ha->oem_id = OEM_ID_ICP;
-ha->brd_phys = (pcistr->pdev->bus->number << 8) | (pcistr->pdev->devfn &
0xf8);
-ha->stype = (ulong32)pcistr->pdev->device;
-ha->irq = pcistr->irq;
-ha->pdev = pcistr->pdev;
+ha->brd_phys = (pdev->bus->number << 8) | (pdev->devfn & 0xf8);
+ha->stype = (ulong32)pdev->device;
+ha->irq = pdev->irq;
+ha->pdev = pdev;
if (ha->pdev->device <= PCI_DEVICE_ID_VORTEX_GDT6000B) { /* GDT6000/B */
TRACE2(("init_pci() dpmem %lx irq %d\n",pcistr->dpmem,ha->irq));
@@ -960,8 +959,7 @@ static int __init gdth_init_pci(gdth_pci_str
*pcistr,gdth_ha_str *ha)
continue;
}
iounmap(ha->brd);
-pci_write_config_dword(pcistr->pdev,
- PCI_BASE_ADDRESS_0, i);
+ pci_write_config_dword(pdev, PCI_BASE_ADDRESS_0, i);
ha->brd = ioremap(i, sizeof(gdt6_dpram_str));
if (ha->brd == NULL) {
printk("GDT-PCI: Initialization error (DPMEM remap
error)\n");
@@ -1070,8 +1068,7 @@ static int __init gdth_init_pci(gdth_pci_str
*pcistr,gdth_ha_str *ha)
continue;
}
iounmap(ha->brd);
-pci_write_config_dword(pcistr->pdev,
- PCI_BASE_ADDRESS_2, i);
+ pci_write_config_dword(pdev, PCI_BASE_ADDRESS_2, i);
ha->brd = ioremap(i, sizeof(gdt6c_dpram_str));
if (ha->brd == NULL) {
printk("GDT-PCI: Initialization error (DPMEM remap
error)\n");
@@ -1163,16 +1160,16 @@ static int __init gdth_init_pci(gdth_pci_str
*pcistr,gdth_ha_str *ha)
}
/* manipulate config. space to enable DPMEM, start RP controller */
-pci_read_config_word(pcistr->pdev, PCI_COMMAND, &command);
+ pci_read_config_word(pdev, PCI_COMMAND, &command);
command |= 6;
-pci_write_config_word(pcistr->pdev, PCI_COMMAND, command);
-if (pci_resource_start(pcistr->pdev, 8) == 1UL)
-pci_resource_start(pcistr->pdev, 8) = 0UL;
+ pci_write_config_word(pdev, PCI_COMMAND, command);
+ if (pci_resource_start(pdev, 8) == 1UL)
+ pci_resource_start(pdev, 8) = 0UL;
i = 0xFEFF0001UL;
-pci_write_config_dword(pcistr->pdev, PCI_ROM_ADDRESS, i);
+ pci_write_config_dword(pdev, PCI_ROM_ADDRESS, i);
gdth_delay(1);
-pci_write_config_dword(pcistr->pdev, PCI_ROM_ADDRESS,
- pci_
[PATCH] lockd: fix sparse warning in svcshare.c
fs/lockd/svcshare.c:74:50: warning: Using plain integer as NULL pointer
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
fs/lockd/svcshare.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/lockd/svcshare.c b/fs/lockd/svcshare.c
index 068886d..c42fcf0 100644
--- a/fs/lockd/svcshare.c
+++ b/fs/lockd/svcshare.c
@@ -71,7 +71,7 @@ nlmsvc_unshare_file(struct nlm_host *host, struct nlm_file
*file,
struct nlm_share*share, **shpp;
struct xdr_netobj *oh = &argp->lock.oh;
- for (shpp = &file->f_shares; (share = *shpp) != 0; shpp =
&share->s_next) {
+ for (shpp = &file->f_shares; (share = *shpp) != NULL; shpp =
&share->s_next) {
if (share->s_host == host && nlm_cmp_owner(share, oh)) {
*shpp = share->s_next;
kfree(share);
--
1.5.4.1.1278.gc75be
--
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/
2.6.25-rc2 vdso_install breaks user "make install"
Good day. I have a ~/bin/installkernel which installs the kernel when I as user do a make install at the end of compilation but 2.6.25-rc2 seems to break this: [EMAIL PROTECTED]:~/src/linux/local$ make V=1 install make -f scripts/Makefile.build obj=arch/x86/vdso vdso_install mkdir: cannot create directory `/lib/modules/2.6.25-rc2': Permission denied How to fix? Rene. -- 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: [PATCHv2] autofs4: fix sparse warning in root.c
On Fri, 2008-02-15 at 18:51 -0800, Harvey Harrison wrote:
> fs/autofs4/root.c:536:23: warning: symbol 'ino' shadows an earlier one
> fs/autofs4/root.c:510:22: originally declared here
>
> There is no need to redeclare, we are at the end of the loop and in
> the next iteration of the loop, ino will be reset.
>
> Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
Acked-by: Ian Kent <[EMAIL PROTECTED]>
> ---
> fs/autofs4/root.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/fs/autofs4/root.c b/fs/autofs4/root.c
> index a54a946..aa4c5ff 100644
> --- a/fs/autofs4/root.c
> +++ b/fs/autofs4/root.c
> @@ -533,9 +533,9 @@ static struct dentry *autofs4_lookup_unhashed(struct
> autofs_sb_info *sbi, struct
> goto next;
>
> if (d_unhashed(dentry)) {
> - struct autofs_info *ino = autofs4_dentry_ino(dentry);
> struct inode *inode = dentry->d_inode;
>
> + ino = autofs4_dentry_ino(dentry);
> list_del_init(&ino->rehash);
> dget(dentry);
> /*
--
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 3/4] jffs2: fix sparse warning in write.c
fs/jffs2/write.c:585:28: warning: symbol 'fd' shadows an earlier one
fs/jffs2/write.c:536:27: originally declared here
No need to redeclare fd, use the original one, after this point,
fd is always reassigned before it used again.
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
fs/jffs2/write.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/jffs2/write.c b/fs/jffs2/write.c
index 776f13c..beade55 100644
--- a/fs/jffs2/write.c
+++ b/fs/jffs2/write.c
@@ -582,9 +582,9 @@ int jffs2_do_unlink(struct jffs2_sb_info *c, struct
jffs2_inode_info *dir_f,
jffs2_add_fd_to_list(c, fd, &dir_f->dents);
up(&dir_f->sem);
} else {
- struct jffs2_full_dirent *fd = dir_f->dents;
uint32_t nhash = full_name_hash(name, namelen);
+ fd = dir_f->dents;
/* We don't actually want to reserve any space, but we do
want to be holding the alloc_sem when we write to flash */
down(&c->alloc_sem);
--
1.5.4.1.1278.gc75be
--
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/4] jffs2: fix sparse warning in nodemgmt.c
fs/jffs2/nodemgmt.c:60:8: warning: symbol 'ret' shadows an earlier one
fs/jffs2/nodemgmt.c:45:6: originally declared here
Use a different var (gc) in the inner loop to test the condition.
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
fs/jffs2/nodemgmt.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/jffs2/nodemgmt.c b/fs/jffs2/nodemgmt.c
index a0313fa..96faa70 100644
--- a/fs/jffs2/nodemgmt.c
+++ b/fs/jffs2/nodemgmt.c
@@ -57,7 +57,7 @@ int jffs2_reserve_space(struct jffs2_sb_info *c, uint32_t
minsize,
/* this needs a little more thought (true :)) */
while(ret == -EAGAIN) {
while(c->nr_free_blocks + c->nr_erasing_blocks < blocksneeded) {
- int ret;
+ int gc;
uint32_t dirty, avail;
/* calculate real dirty size
@@ -116,9 +116,9 @@ int jffs2_reserve_space(struct jffs2_sb_info *c, uint32_t
minsize,
c->free_size + c->dirty_size + c->wasted_size
+ c->used_size + c->erasing_size + c->bad_size, c->flash_size));
spin_unlock(&c->erase_completion_lock);
- ret = jffs2_garbage_collect_pass(c);
- if (ret)
- return ret;
+ gc = jffs2_garbage_collect_pass(c);
+ if (gc)
+ return gc;
cond_resched();
--
1.5.4.1.1278.gc75be
--
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/4] jffs2: fix sparse warnings in gc.c
fs/jffs2/gc.c:1147:29: warning: symbol 'jeb' shadows an earlier one
fs/jffs2/gc.c:1084:89: originally declared here
fs/jffs2/gc.c:1197:29: warning: symbol 'jeb' shadows an earlier one
fs/jffs2/gc.c:1084:89: originally declared here
Add an sb_ prefix to the inner jeb variables as they are taken from
the super_blocks list.
It appears jffs2_garbage_collect_dnode never uses its jeb argument,
so as an alternative that could be dropped and the one caller adusted
then the inner variables would not need to be touched.
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
fs/jffs2/gc.c | 24
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/fs/jffs2/gc.c b/fs/jffs2/gc.c
index 32ff037..855ca05 100644
--- a/fs/jffs2/gc.c
+++ b/fs/jffs2/gc.c
@@ -1144,24 +1144,24 @@ static int jffs2_garbage_collect_dnode(struct
jffs2_sb_info *c, struct jffs2_era
If not, cover it anyway. */
struct jffs2_raw_node_ref *raw =
frag->node->raw;
- struct jffs2_eraseblock *jeb;
+ struct jffs2_eraseblock *sb_jeb;
- jeb = &c->blocks[raw->flash_offset /
c->sector_size];
+ sb_jeb = &c->blocks[raw->flash_offset /
c->sector_size];
- if (jeb == c->gcblock) {
+ if (sb_jeb == c->gcblock) {
D1(printk(KERN_DEBUG "Expanding down to
cover frag (0x%x-0x%x) in gcblock at %08x\n",
frag->ofs,
frag->ofs+frag->size, ref_offset(raw)));
start = frag->ofs;
break;
}
- if (!ISDIRTY(jeb->dirty_size +
jeb->wasted_size)) {
+ if (!ISDIRTY(sb_jeb->dirty_size +
sb_jeb->wasted_size)) {
D1(printk(KERN_DEBUG "Not expanding
down to cover frag (0x%x-0x%x) in clean block %08x\n",
- frag->ofs,
frag->ofs+frag->size, jeb->offset));
+ frag->ofs,
frag->ofs+frag->size, sb_jeb->offset));
break;
}
D1(printk(KERN_DEBUG "Expanding down to cover
frag (0x%x-0x%x) in dirty block %08x\n",
- frag->ofs,
frag->ofs+frag->size, jeb->offset));
+ frag->ofs,
frag->ofs+frag->size, sb_jeb->offset));
start = frag->ofs;
break;
}
@@ -1194,24 +1194,24 @@ static int jffs2_garbage_collect_dnode(struct
jffs2_sb_info *c, struct jffs2_era
If not, cover it anyway. */
struct jffs2_raw_node_ref *raw =
frag->node->raw;
- struct jffs2_eraseblock *jeb;
+ struct jffs2_eraseblock *sb_jeb;
- jeb = &c->blocks[raw->flash_offset /
c->sector_size];
+ sb_jeb = &c->blocks[raw->flash_offset /
c->sector_size];
- if (jeb == c->gcblock) {
+ if (sb_jeb == c->gcblock) {
D1(printk(KERN_DEBUG "Expanding up to
cover frag (0x%x-0x%x) in gcblock at %08x\n",
frag->ofs,
frag->ofs+frag->size, ref_offset(raw)));
end = frag->ofs + frag->size;
break;
}
- if (!ISDIRTY(jeb->dirty_size +
jeb->wasted_size)) {
+ if (!ISDIRTY(sb_jeb->dirty_size +
sb_jeb->wasted_size)) {
D1(printk(KERN_DEBUG "Not expanding up
to cover frag (0x%x-0x%x) in clean block %08x\n",
- frag->ofs,
frag->ofs+frag->size, jeb->offset));
+ frag->ofs,
frag->ofs+frag->size, sb_jeb->offset));
break;
}
D1(printk(KERN_DEBUG "Expanding up to cover
frag (0x%x-0x%x) in dirty block %08x\n",
- frag->ofs,
frag->ofs+frag->size, jeb->offset));
+ frag->ofs,
frag->ofs+frag->size, sb_jeb->offset));
end = frag->ofs + frag->size;
break;
}
--
1.5.4.1.1278.gc75be
--
To unsubscri
[PATCH 1/4] jffs2: include function prototype for jffs2_ioctl
fs/jffs2/ioctl.c:14:5: warning: symbol 'jffs2_ioctl' was not declared. Should it be static? Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]> --- fs/jffs2/ioctl.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/fs/jffs2/ioctl.c b/fs/jffs2/ioctl.c index f4d525b..e217721 100644 --- a/fs/jffs2/ioctl.c +++ b/fs/jffs2/ioctl.c @@ -10,6 +10,7 @@ */ #include +#include "nodelist.h" int jffs2_ioctl(struct inode *inode, struct file *filp, unsigned int cmd, unsigned long arg) -- 1.5.4.1.1278.gc75be -- 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] (02/15/08 Linus git) Smack unlabeled outgoing ambient packets - v4
On Friday 15 February 2008 6:24:25 pm Casey Schaufler wrote:
> From: Casey Schaufler <[EMAIL PROTECTED]>
>
> Smack uses CIPSO labeling, but allows for unlabeled packets
> by specifying an "ambient" label that is applied to incoming
> unlabeled packets. Because the other end of the connection
> may dislike IP options, and ssh is one know application that
> behaves thus, it is prudent to respond in kind. This patch
> changes the network labeling behavior such that an outgoing
> packet that would be given a CIPSO label that matches the
> ambient label is left unlabeled. An "unlbl" domain is added
> and the netlabel defaulting mechanism invoked rather than
> assuming that everything is CIPSO. Locking has been added
> around changes to the ambient label as the mechanisms used
> to do so are more involved.
>
> Cleaned up some issues noted in review.
> Make smk_cipso_doi() static.
> Create a hook for the new security_secctx_to_secid()
> using existing underlying code.
> Fill in audit data for netlbl domain calls.
> Collapse unnecessary multiple assignments.
>
> Signed-off-by: Casey Schaufler <[EMAIL PROTECTED]>
Looks good to me, thanks for making those changes.
Acked-by: Paul Moore <[EMAIL PROTECTED]>
> ---
>
> security/smack/smack_lsm.c | 36
> security/smack/smackfs.c | 61 ++-
> 2 files changed, 74 insertions(+), 23 deletions(-)
>
> diff -uprN -X linux-2.6.25-g0215-base//Documentation/dontdiff
> linux-2.6.25-g0215-base/security/smack/smackfs.c
> linux-2.6.25-g0215/security/smack/smackfs.c ---
> linux-2.6.25-g0215-base/security/smack/smackfs.c 2008-02-15
> 14:25:37.0 -0800 +++
> linux-2.6.25-g0215/security/smack/smackfs.c 2008-02-15 14:30:36.0
> -0800 @@ -24,6 +24,7 @@
> #include
> #include
> #include
> +#include
> #include "smack.h"
>
> /*
> @@ -45,6 +46,7 @@ enum smk_inos {
> */
> static DEFINE_MUTEX(smack_list_lock);
> static DEFINE_MUTEX(smack_cipso_lock);
> +static DEFINE_MUTEX(smack_ambient_lock);
>
> /*
> * This is the "ambient" label for network traffic.
> @@ -342,6 +344,9 @@ void smk_cipso_doi(void)
> struct cipso_v4_doi *doip;
> struct netlbl_audit audit_info;
>
> + audit_info.loginuid = audit_get_loginuid(current);
> + audit_info.secid = smack_to_secid(current->security);
> +
> rc = netlbl_cfg_map_del(NULL, &audit_info);
> if (rc != 0)
> printk(KERN_WARNING "%s:%d remove rc = %d\n",
> @@ -363,6 +368,30 @@ void smk_cipso_doi(void)
> __func__, __LINE__, rc);
> }
>
> +/**
> + * smk_unlbl_ambient - initialize the unlabeled domain
> + */
> +void smk_unlbl_ambient(char *oldambient)
> +{
> + int rc;
> + struct netlbl_audit audit_info;
> +
> + audit_info.loginuid = audit_get_loginuid(current);
> + audit_info.secid = smack_to_secid(current->security);
> +
> + if (oldambient != NULL) {
> + rc = netlbl_cfg_map_del(oldambient, &audit_info);
> + if (rc != 0)
> + printk(KERN_WARNING "%s:%d remove rc = %d\n",
> +__func__, __LINE__, rc);
> + }
> +
> + rc = netlbl_cfg_unlbl_add_map(smack_net_ambient, &audit_info);
> + if (rc != 0)
> + printk(KERN_WARNING "%s:%d add rc = %d\n",
> +__func__, __LINE__, rc);
> +}
> +
> /*
> * Seq_file read operations for /smack/cipso
> */
> @@ -709,7 +738,6 @@ static ssize_t smk_read_ambient(struct f
> size_t cn, loff_t *ppos)
> {
> ssize_t rc;
> - char out[SMK_LABELLEN];
> int asize;
>
> if (*ppos != 0)
> @@ -717,23 +745,18 @@ static ssize_t smk_read_ambient(struct f
> /*
>* Being careful to avoid a problem in the case where
>* smack_net_ambient gets changed in midstream.
> - * Since smack_net_ambient is always set with a value
> - * from the label list, including initially, and those
> - * never get freed, the worst case is that the pointer
> - * gets changed just after this strncpy, in which case
> - * the value passed up is incorrect. Locking around
> - * smack_net_ambient wouldn't be any better than this
> - * copy scheme as by the time the caller got to look
> - * at the ambient value it would have cleared the lock
> - * and been changed.
>*/
> - strncpy(out, smack_net_ambient, SMK_LABELLEN);
> - asize = strlen(out) + 1;
> + mutex_lock(&smack_ambient_lock);
>
> - if (cn < asize)
> - return -EINVAL;
> + asize = strlen(smack_net_ambient) + 1;
> +
> + if (cn >= asize)
> + rc = simple_read_from_buffer(buf, cn, ppos,
> + smack_net_ambient, asize);
> + else
> + rc = -EINVAL;
>
> - rc = simple_read_from_buffer(buf, cn, ppos, out, asize);
> + mutex_unlock(&smack_ambient_lock);
>
> return rc;
> }
> @@ -751,6 +774,7 @@ static ssize_t smk_write
Re: [PATCH] Remove the new perl dependency from build.
Rob Landley wrote: Removed the special case "canned" logic from the perl script (it always requires Math::bigint when it runs now). Moved the list of canned values into kernel/Makefile. (It's already a selection menu in kconfig, so you can't just feed arbitrary values into it anyway. If you add a new value to kconfig, add it to kernel/Makefile as well and delete kernel/timeconst.h so the build recreates it.) The problem is that for at least one architecture, CONFIG_HZ is settable to arbitrary values, so you need a way to invoke the generic code if you don't have a pre-canned value available. I have to admit to having very little interest in this kind of minimality exercises, which seem to have pretty much academic value only -- in reality, people cross-compile the kernel to go onto this kind of minimal boxes. -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: [PATCHv2] autofs4: fix sparse warning in root.c
fs/autofs4/root.c:536:23: warning: symbol 'ino' shadows an earlier one
fs/autofs4/root.c:510:22: originally declared here
There is no need to redeclare, we are at the end of the loop and in
the next iteration of the loop, ino will be reset.
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
fs/autofs4/root.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/autofs4/root.c b/fs/autofs4/root.c
index a54a946..aa4c5ff 100644
--- a/fs/autofs4/root.c
+++ b/fs/autofs4/root.c
@@ -533,9 +533,9 @@ static struct dentry *autofs4_lookup_unhashed(struct
autofs_sb_info *sbi, struct
goto next;
if (d_unhashed(dentry)) {
- struct autofs_info *ino = autofs4_dentry_ino(dentry);
struct inode *inode = dentry->d_inode;
+ ino = autofs4_dentry_ino(dentry);
list_del_init(&ino->rehash);
dget(dentry);
/*
--
1.5.4.1.1278.gc75be
--
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] autofs4: fix sparse warning in root.c
On Fri, 2008-02-15 at 17:49 -0800, Harvey Harrison wrote:
> fs/autofs4/root.c:536:23: warning: symbol 'ino' shadows an earlier one
> fs/autofs4/root.c:510:22: originally declared here
>
> There is no need to redeclare, we are at the end of the loop and in
> the next iteration of the loop, ino will be reset.
Of course, this is fine.
But I like to leave a blank line between declarative and procedural
statements or no blank line at all if it looks natural, usually when
there are only a few lines of code.
Picky I know, but in this case I'd prefer moving the assignment down one
line.
>
> Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
> ---
> fs/autofs4/root.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/fs/autofs4/root.c b/fs/autofs4/root.c
> index a54a946..1b43456 100644
> --- a/fs/autofs4/root.c
> +++ b/fs/autofs4/root.c
> @@ -533,8 +533,8 @@ static struct dentry *autofs4_lookup_unhashed(struct
> autofs_sb_info *sbi, struct
> goto next;
>
> if (d_unhashed(dentry)) {
> - struct autofs_info *ino = autofs4_dentry_ino(dentry);
> struct inode *inode = dentry->d_inode;
> + ino = autofs4_dentry_ino(dentry);
>
> list_del_init(&ino->rehash);
> dget(dentry);
--
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.25-rc1 xen pvops regression
Joel Becker wrote: On Thu, Feb 14, 2008 at 06:50:52PM +1100, Jeremy Fitzhardinge wrote: I'm seeing the same problem, with no messages at all from xen other than "domain crashed, restart disabled" in xend.log. I got a different commit in my bisect, 0947b2f31ca1ea1211d3cde2dbd8fcec579ef395 (i386 boot: replace boot_ioremap with enhanced bt_ioremap - enhance bt_ioremap). I started from yesterday's 96b5a46e2a72dc1829370c87053e0cd558d58bc0 (WMI: initialize wmi_blocks.list even if ACPI is disabled) and a known good 9b73e76f3cf63379dcf45fcd4f112f5812418d0a (Merge git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6). Is the domain ending up in the crashed state? Do you get a register dump with xm dmesg? That would be very useful in determining what went wrong. You may need to compile Xen with debug=y in Config.mk. I didn't know xm dmesg existed :-) Regarding debug=y, I'm using a prepackaged dom0 set. Here's what I find in xm dmesg: Joel (XEN) mm.c:1825:d109 Bad type (saw 2801 != exp e000) for mfn 3a2f0f (pfn f0) (XEN) mm.c:649:d109 Error getting mfn 3a2f0f (pfn f0) from L1 entry 0003a2f0f063 for dom109 (XEN) mm.c:1825:d109 Bad type (saw 2801 != exp e000) for mfn 3a2f0f (pfn f0) (XEN) mm.c:649:d109 Error getting mfn 3a2f0f (pfn f0) from L1 entry 0003a2f0f063 for dom109 (XEN) mm.c:3331:d109 ptwr_emulate: could not get_page_from_l1e() Hm, I have a suspicion about what this might be. I'll haven't tried reproducing it yet though. (XEN) Unhandled page fault in domain 109 on VCPU 0 (ec=0003) (XEN) Pagetable walk from c01687f0: (XEN) L4[0x000] = 0003a2933027 06cc (XEN) L3[0x003] = 00039afea027 0005 (XEN) L2[0x000] = 00039bfb7067 1048 (XEN) L1[0x168] = 0003a2e97061 0168 (XEN) domain_crash_sync called from entry.S (XEN) Domain 109 (vcpu#0) crashed on cpu#2: (XEN) [ Xen-3.1.3-rc3 x86_64 debug=n Not tainted ] (XEN) CPU:2 (XEN) RIP:e019:[] What does this EIP correspond to in your kernel? Also: c01687f0 c0417ab6 c040288f c040299a c0403270 (as guesses of potential callers to try and work out a stack trace). Thanks, 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/
[RFC-PATCH] cifs: remove GLOBAL_EXTERN macro
Just use extern, saves a lot of sparse warnings. fs/cifs/cifsglob.h:603:33: warning: symbol 'GlobalUidList' was not declared. Should it be static? fs/cifs/cifsglob.h:606:32: warning: symbol 'GlobalSMBSessionList' was not declared. Should it be static? fs/cifs/cifsglob.h:607:32: warning: symbol 'GlobalTreeConnectionList' was not declared. Should it be static? fs/cifs/cifsglob.h:608:24: warning: symbol 'GlobalSMBSeslock' was not declared. Should it be static? fs/cifs/cifsglob.h:610:32: warning: symbol 'GlobalOplock_Q' was not declared. Should it be static? fs/cifs/cifsglob.h:613:32: warning: symbol 'GlobalDnotifyReqList' was not declared. Should it be static? fs/cifs/cifsglob.h:615:32: warning: symbol 'GlobalDnotifyRsp_Q' was not declared. Should it be static? fs/cifs/cifsglob.h:620:28: warning: symbol 'GlobalCurrentXid' was not declared. Should it be static? fs/cifs/cifsglob.h:621:28: warning: symbol 'GlobalTotalActiveXid' was not declared. Should it be static? fs/cifs/cifsglob.h:622:28: warning: symbol 'GlobalMaxActiveXid' was not declared. Should it be static? fs/cifs/cifsglob.h:623:26: warning: symbol 'GlobalMid_Lock' was not declared. Should it be static? fs/cifs/cifsglob.h:625:20: warning: symbol 'Local_System_Name' was not declared. Should it be static? fs/cifs/cifsglob.h:630:24: warning: symbol 'sesInfoAllocCount' was not declared. Should it be static? fs/cifs/cifsglob.h:631:24: warning: symbol 'tconInfoAllocCount' was not declared. Should it be static? fs/cifs/cifsglob.h:632:24: warning: symbol 'tcpSesAllocCount' was not declared. Should it be static? fs/cifs/cifsglob.h:633:24: warning: symbol 'tcpSesReconnectCount' was not declared. Should it be static? fs/cifs/cifsglob.h:634:24: warning: symbol 'tconInfoReconnectCount' was not declared. Should it be static? fs/cifs/cifsglob.h:637:24: warning: symbol 'bufAllocCount' was not declared. Should it be static? fs/cifs/cifsglob.h:639:24: warning: symbol 'totBufAllocCount' was not declared. Should it be static? fs/cifs/cifsglob.h:640:24: warning: symbol 'totSmBufAllocCount' was not declared. Should it be static? fs/cifs/cifsglob.h:642:24: warning: symbol 'smBufAllocCount' was not declared. Should it be static? fs/cifs/cifsglob.h:643:24: warning: symbol 'midCount' was not declared. Should it be static? fs/cifs/cifsglob.h:646:28: warning: symbol 'multiuser_mount' was not declared. Should it be static? fs/cifs/cifsglob.h:650:28: warning: symbol 'oplockEnabled' was not declared. Should it be static? fs/cifs/cifsglob.h:651:28: warning: symbol 'experimEnabled' was not declared. Should it be static? fs/cifs/cifsglob.h:652:28: warning: symbol 'lookupCacheEnabled' was not declared. Should it be static? fs/cifs/cifsglob.h:653:28: warning: symbol 'extended_security' was not declared. Should it be static? fs/cifs/cifsglob.h:655:28: warning: symbol 'sign_CIFS_PDUs' was not declared. Should it be static? fs/cifs/cifsglob.h:656:28: warning: symbol 'linuxExtEnabled' was not declared. Should it be static? fs/cifs/cifsglob.h:657:28: warning: symbol 'CIFSMaxBufSize' was not declared. Should it be static? fs/cifs/cifsglob.h:658:28: warning: symbol 'cifs_min_rcv' was not declared. Should it be static? fs/cifs/cifsglob.h:659:28: warning: symbol 'cifs_min_small' was not declared. Should it be static? fs/cifs/cifsglob.h:660:28: warning: symbol 'cifs_max_pending' was not declared. Should it be static? Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]> --- fs/cifs/cifsglob.h | 76 1 files changed, 35 insertions(+), 41 deletions(-) diff --git a/fs/cifs/cifsglob.h b/fs/cifs/cifsglob.h index 5d32d8d..bb6ddf3 100644 --- a/fs/cifs/cifsglob.h +++ b/fs/cifs/cifsglob.h @@ -583,79 +583,73 @@ require use of the stronger protocol */ * / -#ifdef DECLARE_GLOBALS_HERE -#define GLOBAL_EXTERN -#else -#define GLOBAL_EXTERN extern -#endif - /* * The list of servers that did not respond with NT LM 0.12. * This list helps improve performance and eliminate the messages indicating * that we had a communications error talking to the server in this list. */ /* Feature not supported */ -/* GLOBAL_EXTERN struct servers_not_supported *NotSuppList; */ +/* extern struct servers_not_supported *NotSuppList; */ /* * The following is a hash table of all the users we know about. */ -GLOBAL_EXTERN struct smbUidInfo *GlobalUidList[UID_HASH]; +extern struct smbUidInfo *GlobalUidList[UID_HASH]; -/* GLOBAL_EXTERN struct list_head GlobalServerList; BB not implemented yet */ -GLOBAL_EXTERN struct list_head GlobalSMBSessionList; -GLOBAL_EXTERN struct list_head GlobalTreeConnectionList; -GLOBAL_EXTERN rwlock_t GlobalSMBSeslock; /* protects list inserts on 3 above */ +/* extern struct list_head GlobalServerList; BB not implemented yet */ +extern struct list_head GlobalSMBSessionList; +extern struct list_head GlobalTreeConnectionList;
Re: pci_device_id definition cleanups
On Sat, Feb 16, 2008 at 12:21:40AM +0100, Jonas Bonn wrote: > I've done some work on cleaning up the definitions of pci_device_id to > make them "static const" (where possible) and to make sure they go into > __devinitconst. There are about 350 changes of the type shown in the > diff at the end of this mail. > > All these changes are in my public GIT tree at: > > git://www.southpole.se/~jonas/git/linux.git > > (Based on 2.6.25-rc2) > > In addition to these pci_device_id changes, there are a few changesets > that move "const" data from __devinitdata to __devinitconst. > > The tree above builds with both allmodconfig and allyesconfig. Hi Jonas. Can I ask you to try the same with ARCH=powerpc (or alpha or ia64). Becasue it is for these architectures we see issues with defining data const. Sam -- 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] Remove the new perl dependency from build.
From: Rob Landley <[EMAIL PROTECTED]> Remove perl dependency introduced in 2.6.25-rc1, by shipping kernel/timeconst.h with all the "canned" values so perl is only used to regenerate it if that file is deleted. Removed the special case "canned" logic from the perl script (it always requires Math::bigint when it runs now). Moved the list of canned values into kernel/Makefile. (It's already a selection menu in kconfig, so you can't just feed arbitrary values into it anyway. If you add a new value to kconfig, add it to kernel/Makefile as well and delete kernel/timeconst.h so the build recreates it.) Signed-off-by: Rob Landley <[EMAIL PROTECTED]> --- kernel/Makefile |6 kernel/timeconst.h | 537 ++ kernel/timeconst.pl | 281 ++--- 3 files changed, 567 insertions(+), 257 deletions(-) I have a build system that's been happily building kernels since 2.6.16, which can't build 2.6.25-rc1: > TIMEC kernel/timeconst.h > /bin/sh: perl: not found > make[1]: *** [kernel/timeconst.h] Error 127 > make: *** [kernel] Error 2 > make: *** Waiting for unfinished jobs Building the kernel has never required perl before, and it's a large change to need to build perl on x86, arm, mips, powerpc, m68k, sh4, and so on to get a native build environment that can compile a kernel, when I didn't need to do this for 2.6.24 or any previous version. For the record, a self-bootstrapping system (built from linux, busybox, uClibc, binutils, gcc, make, and bash) requires the following commands to natively recompile everything: At absolute paths: /bin/bash, /bin/sh, and /lib/ld-uClinux.so.0 In $PATH: ar, as, awk, basename, cat, cc, chmod, chown, cmp, cp, cut, date, dd, diff, dirname, echo, egrep, env, expr, find, gcc, grep, gzip, hostname, id, install, ld, ln, ls, make, mkdir, mktemp, mv, nm, od, patch, pwd, readlink, rm, rmdir, sed, sha1sum, sleep, sort, tail, tar, touch, tr, true, uname, uniq, wc, which, whoami. (It also needs some /dev stuff and shared libraries, of course. But no bison, no lexx, and no perl.) diff -ru linux-2.6.25-rc1/kernel/timeconst.pl linux-2.6.25-new/kernel/timeconst.pl --- linux-2.6.25-rc1/kernel/timeconst.pl2008-02-10 16:18:14.0 -0600 +++ linux-2.6.25-new/kernel/timeconst.pl2008-02-15 17:52:02.0 -0600 @@ -11,210 +11,10 @@ # # -# Usage: timeconst.pl HZ > timeconst.h +# Usage: timeconst.pl HZ... > timeconst.h # -# Precomputed values for systems without Math::BigInt -# Generated by: # timeconst.pl --can 24 32 48 64 100 122 128 200 250 256 300 512 1000 1024 1200 -%canned_values = ( - 24 => [ - '0xa6ab','0x2aa',26, - '0xa6ab','0x2aa',58, - 125,3, - '0xc49ba5e4','0x1fbe76c8b4',37, - '0xc49ba5e353f7ceda','0x1fbe76c8b439581062',69, - 3,125, - '0xa2c2aaab','0x',16, - '0xa2c2aaab','0x',48, - 125000,3, - '0xc9539b89','0x7fffbce4217d',47, - '0xc9539b8887229e91','0x7fffbce4217d2849cb25',79, - 3,125000, - ], 32 => [ - '0xfa00','0x600',27, - '0xfa00','0x600',59, - 125,4, - '0x83126e98','0xfdf3b645a',36, - '0x83126e978d4fdf3c','0xfdf3b645a1cac0831',68, - 4,125, - '0xf424','0x0',17, - '0xf424','0x0',49, - 31250,1, - '0x8637bd06','0x3fff79c842fa',46, - '0x8637bd05af6c69b6','0x3fff79c842fa5093964a',78, - 1,31250, - ], 48 => [ - '0xa6ab','0x6aa',27, - '0xa6ab','0x6aa',59, - 125,6, - '0xc49ba5e4','0xfdf3b645a',36, - '0xc49ba5e353f7ceda','0xfdf3b645a1cac0831',68, - 6,125, - '0xa2c2aaab','0x1',17, - '0xa2c2aaab','0x1',49, - 62500,3, - '0xc9539b89','0x3fffbce4217d',46, - '0xc9539b8887229e91','0x3fffbce4217d2849cb25',78, - 3,62500, - ], 64 => [ - '0xfa00','0xe00',28, - '0xfa00','0xe00',60, - 125,8, - '0x83126e98','0x7ef9db22d',35, - '0x83126e978d4fdf3c','0x7ef9db22d0e560418',67, - 8,125, - '0xf424','0x0',18, - '0xf424','0x0',50, - 15625,1, - '0x8637bd06','0x1fff79c842fa',45, - '0x8637bd05af6c69b6','0x1fff79c842fa5093964a',77, - 1,15625, - ], 100 => [ - '0xa000','0x0',28, - '0xa000','0x0',60, - 10,1, - '0xcccd','0x7',35, -
Re: Linux 2.6.25-rc2
On Friday, 15 of February 2008, Linus Torvalds wrote:
>
> Ok,
> this kernel is a winner.
>
> Just to show how _much_ of a winner it is, it's been awarded a coveted
> "weasel" series name, which should tell you just how good it's going to
> be. It's a name revered in Linux kernel history, and as such this brings
> back the good old days where if you find a bug, you're almost certainly
> simply mistaken, and you probably just did something wrong.
>
> But hey, you can try to prove me wrong. I dare you.
Here you go.
commit 45b503548210fe6f23e92b856421c2a3f05fd034
Author: Laszlo Attila Toth <[EMAIL PROTECTED]>
Date: Tue Feb 12 22:42:09 2008 -0800
[RTNETLINK]: Send a single notification on device state changes.
contains the following gem:
if (tb[IFLA_LINKMODE]) {
- write_lock_bh(&dev_base_lock);
- dev->link_mode = nla_get_u8(tb[IFLA_LINKMODE]);
- write_unlock_bh(&dev_base_lock);
+ if (dev->link_mode != nla_get_u8(tb[IFLA_LINKMODE])) {
+ write_lock_bh(&dev_base_lock);
+ dev->link_mode = nla_get_u8(tb[IFLA_LINKMODE]);
+ write_lock_bh(&dev_base_lock);
+ modified = 1;
+ }
}
and even with that fixed it breaks NetworkManager (on my test box it apparently
can't get the IP address using DHCP). Reverting this commit makes things
work again.
Well, it looks like this patch went to you untested and unreviewed, so may I
gently request that it be reverted from your tree, pretty please?
Thanks,
Rafael
--
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 PATCH 0/2] ocfs2: Fix endian bug in o2dlm negotiation
These patches fix up two outstanding issues from commit d24fbcda0c4988322949df3d759f1cfb32b32953 (ocfs2: Negotiate locking protocol versions). The first patch cleans up the comparison functions based on Andrew's review. The second fixes a byte-order bug in heterogeneous clusters. I've tested the changes in said hetergeneous envirnoment. Comments and review welcome. Mark, you can pull these into ocfs2.git if they meet your approval. The changes are available via git from git://oss.oracle.com/git/jlbec/linux-2.6.git proto-version-fixup Joel -- 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] ocfs2: Clean up locking protocol negotiation.
The comparison functions for protocol negotiation (introduced in commit
d24fbcda0c4988322949df3d759f1cfb32b32953) were confusing.
Separate out the comparison and value update parts.
Signed-off-by: Joel Becker <[EMAIL PROTECTED]>
---
fs/ocfs2/dlm/dlmdomain.c | 102 ++
1 files changed, 49 insertions(+), 53 deletions(-)
diff --git a/fs/ocfs2/dlm/dlmdomain.c b/fs/ocfs2/dlm/dlmdomain.c
index 638d2eb..de802a7 100644
--- a/fs/ocfs2/dlm/dlmdomain.c
+++ b/fs/ocfs2/dlm/dlmdomain.c
@@ -144,8 +144,6 @@ static int dlm_cancel_join_handler(struct o2net_msg *msg,
u32 len, void *data,
void **ret_data);
static int dlm_exit_domain_handler(struct o2net_msg *msg, u32 len, void *data,
void **ret_data);
-static int dlm_protocol_compare(struct dlm_protocol_version *existing,
- struct dlm_protocol_version *request);
static void dlm_unregister_domain_handlers(struct dlm_ctxt *dlm);
@@ -681,36 +679,48 @@ void dlm_unregister_domain(struct dlm_ctxt *dlm)
}
EXPORT_SYMBOL_GPL(dlm_unregister_domain);
+/*
+ * Compare a requested locking protocol version against the current one.
+ *
+ * If the major numbers are different, they are incompatible.
+ * If the current minor is greater than the request, they are incompatible.
+ * If the current minor is less than or equal to the request, they are
+ * compatible, and the requester should run at the current minor version.
+ */
+static int dlm_protocol_compatible(struct dlm_protocol_version *existing,
+ struct dlm_protocol_version *request)
+{
+ if (existing->pv_major != request->pv_major)
+ return 0;
+
+ if (existing->pv_minor > request->pv_minor)
+ return 0;
+
+ return 1;
+}
+
static int dlm_query_join_proto_check(char *proto_type, int node,
struct dlm_protocol_version *ours,
struct dlm_protocol_version *request)
{
- int rc;
- struct dlm_protocol_version proto = *request;
+ int compatible = dlm_protocol_compatible(ours, request);
- if (!dlm_protocol_compare(ours, &proto)) {
+ if (compatible)
mlog(0,
"node %u wanted to join with %s locking protocol "
"%u.%u, we respond with %u.%u\n",
node, proto_type,
-request->pv_major,
-request->pv_minor,
-proto.pv_major, proto.pv_minor);
- request->pv_minor = proto.pv_minor;
- rc = 0;
- } else {
+request->pv_major, request->pv_minor,
+ours->pv_major, ours->pv_minor);
+ else
mlog(ML_NOTICE,
"Node %u wanted to join with %s locking "
"protocol %u.%u, but we have %u.%u, disallowing\n",
node, proto_type,
-request->pv_major,
-request->pv_minor,
-ours->pv_major,
-ours->pv_minor);
- rc = 1;
- }
+request->pv_major, request->pv_minor,
+ours->pv_major, ours->pv_minor);
- return rc;
+ return compatible;
}
static int dlm_query_join_handler(struct o2net_msg *msg, u32 len, void *data,
@@ -806,21 +816,23 @@ static int dlm_query_join_handler(struct o2net_msg *msg,
u32 len, void *data,
/* Make sure we speak compatible locking protocols. */
if (dlm_query_join_proto_check("DLM", bit,
&dlm->dlm_locking_proto,
- &query->dlm_proto)) {
- response.packet.code =
- JOIN_PROTOCOL_MISMATCH;
- } else if (dlm_query_join_proto_check("fs", bit,
-
&dlm->fs_locking_proto,
-
&query->fs_proto)) {
- response.packet.code =
- JOIN_PROTOCOL_MISMATCH;
- } else {
+ &query->dlm_proto) &&
+ dlm_query_join_proto_check("fs", bit,
+ &dlm->fs_locking_proto,
+ &query->fs_proto)) {
+ /*
+* We're compatible, return our
+* minor number
+*/
response.packet.dlm_minor =
- query->dlm_proto.pv_minor;
+
[PATCH 2/2] ocfs2: Fix endian bug in o2dlm protocol negotiation.
struct dlm_query_join_packet is made up of four one-byte fields. They
are effectively in big-endian order already. However, little-endian
machines swap them before putting the packet on the wire (because
query_join's response is a status, and that status is treated as a u32
on the wire). Thus, a big-endian and little-endian machines will
treat this structure differently.
The solution is to have little-endian machines swap the structure when
converting from the structure to the u32 representation.
Signed-off-by: Joel Becker <[EMAIL PROTECTED]>
---
fs/ocfs2/dlm/dlmcommon.h | 20 +
fs/ocfs2/dlm/dlmdomain.c | 95 +++---
2 files changed, 75 insertions(+), 40 deletions(-)
diff --git a/fs/ocfs2/dlm/dlmcommon.h b/fs/ocfs2/dlm/dlmcommon.h
index 9843ee1..1f93963 100644
--- a/fs/ocfs2/dlm/dlmcommon.h
+++ b/fs/ocfs2/dlm/dlmcommon.h
@@ -602,17 +602,19 @@ enum dlm_query_join_response_code {
JOIN_PROTOCOL_MISMATCH,
};
+struct dlm_query_join_packet {
+ u8 code;/* Response code. dlm_minor and fs_minor
+ are only valid if this is JOIN_OK */
+ u8 dlm_minor; /* The minor version of the protocol the
+ dlm is speaking. */
+ u8 fs_minor;/* The minor version of the protocol the
+ filesystem is speaking. */
+ u8 reserved;
+};
+
union dlm_query_join_response {
u32 intval;
- struct {
- u8 code;/* Response code. dlm_minor and fs_minor
- are only valid if this is JOIN_OK */
- u8 dlm_minor; /* The minor version of the protocol the
- dlm is speaking. */
- u8 fs_minor;/* The minor version of the protocol the
- filesystem is speaking. */
- u8 reserved;
- } packet;
+ struct dlm_query_join_packet packet;
};
struct dlm_lock_request
diff --git a/fs/ocfs2/dlm/dlmdomain.c b/fs/ocfs2/dlm/dlmdomain.c
index de802a7..e77f5d8 100644
--- a/fs/ocfs2/dlm/dlmdomain.c
+++ b/fs/ocfs2/dlm/dlmdomain.c
@@ -723,14 +723,46 @@ static int dlm_query_join_proto_check(char *proto_type,
int node,
return compatible;
}
+/*
+ * struct dlm_query_join_packet is made up of four one-byte fields. They
+ * are effectively in big-endian order already. However, little-endian
+ * machines swap them before putting the packet on the wire (because
+ * query_join's response is a status, and that status is treated as a u32
+ * on the wire). Thus, a big-endian and little-endian machines will treat
+ * this structure differently.
+ *
+ * The solution is to have little-endian machines swap the structure when
+ * converting from the structure to the u32 representation. This will
+ * result in the structure having the correct format on the wire no matter
+ * the host endian format.
+ */
+static void dlm_query_join_packet_to_wire(struct dlm_query_join_packet *packet,
+ u32 *wire)
+{
+ union dlm_query_join_response response;
+
+ response.packet = *packet;
+ *wire = cpu_to_be32(response.intval);
+}
+
+static void dlm_query_join_wire_to_packet(u32 wire,
+ struct dlm_query_join_packet *packet)
+{
+ union dlm_query_join_response response;
+
+ response.intval = cpu_to_be32(wire);
+ *packet = response.packet;
+}
+
static int dlm_query_join_handler(struct o2net_msg *msg, u32 len, void *data,
void **ret_data)
{
struct dlm_query_join_request *query;
- union dlm_query_join_response response = {
- .packet.code = JOIN_DISALLOW,
+ struct dlm_query_join_packet packet = {
+ .code = JOIN_DISALLOW,
};
struct dlm_ctxt *dlm = NULL;
+ u32 response;
u8 nodenum;
query = (struct dlm_query_join_request *) msg->buf;
@@ -747,11 +779,11 @@ static int dlm_query_join_handler(struct o2net_msg *msg,
u32 len, void *data,
mlog(0, "node %u is not in our live map yet\n",
query->node_idx);
- response.packet.code = JOIN_DISALLOW;
+ packet.code = JOIN_DISALLOW;
goto respond;
}
- response.packet.code = JOIN_OK_NO_MAP;
+ packet.code = JOIN_OK_NO_MAP;
spin_lock(&dlm_domain_lock);
dlm = __dlm_lookup_domain_full(query->domain, query->name_len);
@@ -770,7 +802,7 @@ static int dlm_query_join_handler(struct o2net_msg *msg,
u32 len, void *data,
mlog(0, "disallow join as node %u does not "
"have node %u in its nodemap\n",
query->node_idx, nodenum);
- response.packet.code = JOIN_DISALLOW;
+ packet.code = JOIN_DISALLOW;
[PATCH 3/3][RFC] Introduce CLOCK_MONOTONIC_RAW representaiton of time
In talking with Josip Loncaric, and his work on clock synchronization
(see btime.sf.net), he mentioned that for really close synchronization,
it is useful to have access to "hardware time", that is a notion of time
that is not in any way adjusted by the clock slewing done to keep close
time sync.
Part of the issue is if we are using the kernel's ntp adjusted
representation of time in order to measure how we should correct time,
we can run into what Paul McKenney aptly described as "Painting a road
using the lines we're painting as the guide".
I had been thinking of a similar problem, and was trying to come up with
a way to give users access to a purely hardware based time
representation that avoided users having to know the underlying
frequency and mask values needed to deal with the wide variety of
possible underlying hardware counters.
My solution is to introduce CLOCK_MONOTONIC_RAW. This exposes a
nanosecond based time value, that increments starting at bootup and has
no frequency adjustments made to it what so ever.
The time is accessed from userspace via the posix_clock_gettime()
syscall, passing CLOCK_MONOTONIC_RAW as the clock_id.
This patch very much depends on the mult/mult_adj split patch in this
series.
Thoughts comments would be greatly appreciated!
thanks
-john
Signed-off-by: John Stultz <[EMAIL PROTECTED]>
diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h
index e917a30..1460803 100644
--- a/include/linux/clocksource.h
+++ b/include/linux/clocksource.h
@@ -79,6 +79,7 @@ struct clocksource {
/* timekeeping specific data, ignore */
cycle_t cycle_interval;
u64 xtime_interval;
+ u64 raw_interval;
/*
* Second part is written at each timer interrupt
* Keep it in a different cache line to dirty no
diff --git a/include/linux/time.h b/include/linux/time.h
index 2091a19..9548eb4 100644
--- a/include/linux/time.h
+++ b/include/linux/time.h
@@ -116,6 +116,7 @@ extern int do_setitimer(int which, struct itimerval *value,
extern unsigned int alarm_setitimer(unsigned int seconds);
extern int do_getitimer(int which, struct itimerval *value);
extern void getnstimeofday(struct timespec *tv);
+extern void getrawmonotonic(struct timespec *ts);
extern void getboottime(struct timespec *ts);
extern void monotonic_to_bootbased(struct timespec *ts);
@@ -214,6 +215,7 @@ struct itimerval {
#define CLOCK_MONOTONIC1
#define CLOCK_PROCESS_CPUTIME_ID 2
#define CLOCK_THREAD_CPUTIME_ID3
+#define CLOCK_MONOTONIC_RAW4
/*
* The IDs of various hardware clocks:
diff --git a/kernel/posix-timers.c b/kernel/posix-timers.c
index 022c9c3..91a6c19 100644
--- a/kernel/posix-timers.c
+++ b/kernel/posix-timers.c
@@ -224,6 +224,15 @@ static int posix_ktime_get_ts(clockid_t which_clock,
struct timespec *tp)
}
/*
+ * Get monotonic time for posix timers
+ */
+static int posix_get_monotonic_raw(clockid_t which_clock, struct timespec *tp)
+{
+ getrawmonotonic(tp);
+ return 0;
+}
+
+/*
* Initialize everything, well, just everything in Posix clocks/timers ;)
*/
static __init int init_posix_timers(void)
@@ -236,9 +245,15 @@ static __init int init_posix_timers(void)
.clock_get = posix_ktime_get_ts,
.clock_set = do_posix_clock_nosettime,
};
+ struct k_clock clock_monotonic_raw = {
+ .clock_getres = hrtimer_get_res,
+ .clock_get = posix_get_monotonic_raw,
+ .clock_set = do_posix_clock_nosettime,
+ };
register_posix_clock(CLOCK_REALTIME, &clock_realtime);
register_posix_clock(CLOCK_MONOTONIC, &clock_monotonic);
+ register_posix_clock(CLOCK_MONOTONIC_RAW, &clock_monotonic_raw);
posix_timers_cache = kmem_cache_create("posix_timers_cache",
sizeof (struct k_itimer), 0, SLAB_PANIC,
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index cb17979..fc70529 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -44,6 +44,7 @@ __cacheline_aligned_in_smp DEFINE_SEQLOCK(xtime_lock);
*/
struct timespec xtime __attribute__ ((aligned (16)));
struct timespec wall_to_monotonic __attribute__ ((aligned (16)));
+struct timespec monotonic_raw;
static unsigned long total_sleep_time; /* seconds */
static struct timespec xtime_cache __attribute__ ((aligned (16)));
@@ -106,6 +107,39 @@ void getnstimeofday(struct timespec *ts)
EXPORT_SYMBOL(getnstimeofday);
/**
+ * getrawmonotonic - Returns the raw monotonic time in a timespec
+ * @ts:pointer to the timespec to be set
+ *
+ * Returns the raw monotonic time (completely un-modified by ntp)
+ */
+void getrawmonotonic(struct timespec *ts)
+{
+ unsigned long seq;
+ s64 nsecs;
+ cycle_t cycle_now, cycle_delta;
+
+ do {
+ seq = read_seqbegin(&xtime_lock);
+
+ /*
Re: Driver removals
On Fri, 15 Feb 2008 20:08:13 EST, Bill Davidsen said: > can never make you see why technological extortion is evil. People have > always moved to new drivers without pushing because they were *better*, > guess that model is dead. And the drivers get better because the Code Fairy comes and sprinkles magic bugfix dust all over them? And the Code Fairy knows where to sprinkle bugfix dust because it can see where the Bugreport Fairy sprinkled Bugreport Dust? Yes, people will move without pushing when the drivers are better. However, remember that a major cultural motivation for the GPL is the concept of "give back". And if a user can't be bothered to even give back enough to say "wow, this blows, my Frobnozz9800 doesn't work with this driver", that's a problem with the user. They're getting it for free, they should at least give the developers the kindness of a bug report if something is broken... pgp9oUXSku79J.pgp Description: PGP signature
[PATCH] autofs4: fix sparse warning in root.c
fs/autofs4/root.c:536:23: warning: symbol 'ino' shadows an earlier one
fs/autofs4/root.c:510:22: originally declared here
There is no need to redeclare, we are at the end of the loop and in
the next iteration of the loop, ino will be reset.
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
fs/autofs4/root.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/autofs4/root.c b/fs/autofs4/root.c
index a54a946..1b43456 100644
--- a/fs/autofs4/root.c
+++ b/fs/autofs4/root.c
@@ -533,8 +533,8 @@ static struct dentry *autofs4_lookup_unhashed(struct
autofs_sb_info *sbi, struct
goto next;
if (d_unhashed(dentry)) {
- struct autofs_info *ino = autofs4_dentry_ino(dentry);
struct inode *inode = dentry->d_inode;
+ ino = autofs4_dentry_ino(dentry);
list_del_init(&ino->rehash);
dget(dentry);
--
1.5.4.1.1278.gc75be
--
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 v3 PATCH] RTTIME watchdog timer proc interface
From: Hiroshi Shimamoto <[EMAIL PROTECTED]>
Introduce new proc interface for RTTIME watchdog.
It makes administrator able to set RTTIME watchdog to existing real-time
applications without impact. It's useful we don't want to change software
stack, but use RTTIME watchdog for that software.
New proc files:
/proc//rttime
/proc//task//rttime
these files has same content.
$ cat /proc//rttime
1000 2000
It shows current RLIMIT_RTTIME values, and the unit is nsec.
If the value is RLIM_INFINITY, it prints "unlmited".
$ echo "1000" > /proc//rttime
It sets RTTIME current value to 1000.
$ echo "1000 2000" > /proc//rttime
It sets RTTIME current value to 1000 and max value to 2000.
$ echo "0 0" > /proc//rttime
It sets RTTIME values to unlimited.
Signed-off-by: Hiroshi Shimamoto <[EMAIL PROTECTED]>
---
fs/proc/base.c | 103
1 files changed, 103 insertions(+), 0 deletions(-)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index 88f8edf..34b485e 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -381,6 +381,107 @@ static const struct file_operations
proc_lstats_operations = {
#endif
+static int rttime_show_proc(struct seq_file *m, void *v)
+{
+ struct inode *inode = m->private;
+ struct task_struct *task = get_proc_task(inode);
+ struct rlimit *rt;
+
+ if (!task)
+ return -ESRCH;
+
+ rt = &task->signal->rlim[RLIMIT_RTTIME];
+
+ if (rt->rlim_cur == RLIM_INFINITY)
+ seq_printf(m, "unlimited ");
+ else
+ seq_printf(m, "%lu ", rt->rlim_cur);
+
+ if (rt->rlim_max == RLIM_INFINITY)
+ seq_printf(m, "unlimited\n");
+ else
+ seq_printf(m, "%lu\n", rt->rlim_max);
+
+ put_task_struct(task);
+
+ return 0;
+}
+
+static int rttime_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, rttime_show_proc, inode);
+}
+
+static ssize_t rttime_do_write(struct task_struct *task,
+ const char __user *buf,
+ size_t count)
+{
+ char buffer[PROC_NUMBUF], *end;
+ struct rlimit new_rlim, *old_rlim;
+ size_t bufsz;
+ int ret;
+
+ old_rlim = task->signal->rlim + RLIMIT_RTTIME;
+ new_rlim = *old_rlim;
+ memset(buffer, 0, sizeof(buffer));
+ bufsz = min(count, sizeof(buffer) - 1);
+ if (copy_from_user(buffer, buf, bufsz))
+ return -EFAULT;
+ new_rlim.rlim_cur = simple_strtoul(buffer, &end, 0);
+ if (end - buffer == 0)
+ return -EINVAL;
+ /* 0 means unlimited */
+ if (new_rlim.rlim_cur == 0)
+ new_rlim.rlim_cur = RLIM_INFINITY;
+ if (*end == ' ') {
+ ++end;
+ buf += end - buffer;
+ memset(buffer, 0, sizeof(buffer));
+ bufsz = min(count - (end - buffer), sizeof(buffer) - 1);
+ if (copy_from_user(buffer, buf, bufsz))
+ return -EFAULT;
+ ret = strict_strtoul(buffer, 0, &new_rlim.rlim_max);
+ if (ret)
+ return ret;
+ /* 0 means unlimited */
+ if (new_rlim.rlim_max == 0)
+ new_rlim.rlim_max = RLIM_INFINITY;
+ }
+ if (new_rlim.rlim_cur > new_rlim.rlim_max)
+ return -EINVAL;
+ if ((new_rlim.rlim_max > old_rlim->rlim_max) &&
+ !__capable(task, CAP_SYS_RESOURCE))
+ return -EPERM;
+ task_lock(task->group_leader);
+ *old_rlim = new_rlim;
+ task_unlock(task->group_leader);
+
+ return count;
+}
+
+static ssize_t rttime_write(struct file *file,
+ const char __user *buf,
+ size_t count,
+ loff_t *ppos)
+{
+ struct task_struct *task = get_proc_task(file->f_dentry->d_inode);
+ int ret;
+
+ if (!task)
+ return -ESRCH;
+ ret = rttime_do_write(task, buf, count);
+ put_task_struct(task);
+ return ret;
+}
+
+static const struct file_operations proc_rttime_operations = {
+ .open = rttime_open,
+ .read = seq_read,
+ .write = rttime_write,
+ .llseek = seq_lseek,
+ .release= single_release,
+};
+
/* The badness from the OOM killer */
unsigned long badness(struct task_struct *p, unsigned long uptime);
static int proc_oom_score(struct task_struct *task, char *buffer)
@@ -2293,6 +2394,7 @@ static const struct pid_entry tgid_base_stuff[] = {
LNK("exe",exe),
REG("mounts", S_IRUGO, mounts),
REG("mountstats", S_IRUSR, mountstats),
+ REG("rttime", S_IRUSR|S_IWUSR, rttime),
#ifdef CONFIG_PROC_PAGE_MONITOR
REG("clear_refs", S_IWUSR, clear_refs),
REG("smaps", S_IRUGO, smaps),
@@ -2623,6 +2725,7 @@ static const st
[PATCH 2/3] Fixup ntp interval len merges
My first version of the ntp_interval/tick_length inconsistent usage patch was recently merged as bbe4d18ac2e058c56adb0cd71f49d9ed3216a405 http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=bbe4d18ac2e058c56adb0cd71f49d9ed3216a405 While the fix did greatly improve the situation, Roman correctly pointed out that it does have a small bug: If the users change clocksources after the system has been running and NTP has made corrections, the correctoins made against the old clocksource will be applied against the new clocksource, causing error. This patch reverts this previous fix. My second attempt, which corrects the issue in the NTP_INTERVAL_LENGTH definition has also made it up-stream as commit e13a2e61dd5152f5499d2003470acf9c838eab84 http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e13a2e61dd5152f5499d2003470acf9c838eab84 However, due to the original patch going upstream, the second has no effect. So by reverting the first fix, the second will be in use. It should be noted that Roman has voiced objections to this second patch as well, and we are continuing to work out the details. However, due to the severity of the ntp error which both of these patches tries to address, I'd recommend the second patch remain in place until we come to an agreed solution. thanks -john Signed-off-by: John Stultz <[EMAIL PROTECTED]> diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c index 5b11b0f..cb17979 100644 --- a/kernel/time/timekeeping.c +++ b/kernel/time/timekeeping.c @@ -187,8 +187,7 @@ static void change_clocksource(void) clock->error = 0; clock->xtime_nsec = 0; - clocksource_calculate_interval(clock, - (unsigned long)(current_tick_length()>>TICK_LENGTH_SHIFT)); + clocksource_calculate_interval(clock, NTP_INTERVAL_LENGTH); tick_clock_notify(); @@ -245,8 +244,7 @@ void __init timekeeping_init(void) ntp_clear(); clock = clocksource_get_next(); - clocksource_calculate_interval(clock, - (unsigned long)(current_tick_length()>>TICK_LENGTH_SHIFT)); + clocksource_calculate_interval(clock, NTP_INTERVAL_LENGTH); clock->cycle_last = clocksource_read(clock); xtime.tv_sec = sec; -- 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] r/o bind mounts: stub functions
Linus,
We've been causing Ted a lot of pain having to keep different copies of
his patches for mainline and for -mm since -mm has these functions and
mainline doesn't. I'm pretty darn sure at that these are the right API
and we just need another run in -mm to make sure that the reset of the
series in in good shape.
Could we bump this one in a bit ahead of the rest to ease Ted's pain? I
think the odds of this breaking anything by itself are pretty low.
---
This patch adds two functions: mnt_want_write() and mnt_drop_write().
These are used like a lock pair around and fs operations that might
cause a write to the filesystem.
Note that these will replace many of the uses of IS_RDONLY(inode)
currently in the kernel.
Before these can become useful, we must first cover each place in the VFS
where writes are performed with a want/drop pair. When that is complete, we
can actually introduce code that will safely check the counts before allowing
r/w<->r/o transitions to occur.
Acked-by: Serge Hallyn <[EMAIL PROTECTED]>
Acked-by: Al Viro <[EMAIL PROTECTED]>
Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
linux-2.6.git-dave/fs/namespace.c| 54 +++
linux-2.6.git-dave/include/linux/mount.h |3 +
2 files changed, 57 insertions(+)
diff -puN fs/namespace.c~r-o-bind-mounts-stub-functions fs/namespace.c
--- linux-2.6.git/fs/namespace.c~r-o-bind-mounts-stub-functions 2008-02-15
13:25:45.0 -0800
+++ linux-2.6.git-dave/fs/namespace.c 2008-02-15 13:25:45.0 -0800
@@ -80,6 +80,60 @@ struct vfsmount *alloc_vfsmnt(const char
return mnt;
}
+/*
+ * Most r/o checks on a fs are for operations that take
+ * discrete amounts of time, like a write() or unlink().
+ * We must keep track of when those operations start
+ * (for permission checks) and when they end, so that
+ * we can determine when writes are able to occur to
+ * a filesystem.
+ */
+/**
+ * mnt_want_write - get write access to a mount
+ * @mnt: the mount on which to take a write
+ *
+ * This tells the low-level filesystem that a write is
+ * about to be performed to it, and makes sure that
+ * writes are allowed before returning success. When
+ * the write operation is finished, mnt_drop_write()
+ * must be called. This is effectively a refcount.
+ */
+int mnt_want_write(struct vfsmount *mnt)
+{
+ if (__mnt_is_readonly(mnt))
+ return -EROFS;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(mnt_want_write);
+
+/**
+ * mnt_drop_write - give up write access to a mount
+ * @mnt: the mount on which to give up write access
+ *
+ * Tells the low-level filesystem that we are done
+ * performing writes to it. Must be matched with
+ * mnt_want_write() call above.
+ */
+void mnt_drop_write(struct vfsmount *mnt)
+{
+}
+EXPORT_SYMBOL_GPL(mnt_drop_write);
+
+/*
+ * __mnt_is_readonly: check whether a mount is read-only
+ * @mnt: the mount to check for its write status
+ *
+ * This shouldn't be used directly ouside of the VFS.
+ * It does not guarantee that the filesystem will stay
+ * r/w, just that it is right *now*. This can not and
+ * should not be used in place of IS_RDONLY(inode).
+ */
+int __mnt_is_readonly(struct vfsmount *mnt)
+{
+ return (mnt->mnt_sb->s_flags & MS_RDONLY);
+}
+EXPORT_SYMBOL_GPL(__mnt_is_readonly);
+
int simple_set_mnt(struct vfsmount *mnt, struct super_block *sb)
{
mnt->mnt_sb = sb;
diff -puN include/linux/mount.h~r-o-bind-mounts-stub-functions
include/linux/mount.h
--- linux-2.6.git/include/linux/mount.h~r-o-bind-mounts-stub-functions
2008-02-15 13:25:45.0 -0800
+++ linux-2.6.git-dave/include/linux/mount.h2008-02-15 13:25:45.0
-0800
@@ -70,9 +70,12 @@ static inline struct vfsmount *mntget(st
return mnt;
}
+extern int mnt_want_write(struct vfsmount *mnt);
+extern void mnt_drop_write(struct vfsmount *mnt);
extern void mntput_no_expire(struct vfsmount *mnt);
extern void mnt_pin(struct vfsmount *mnt);
extern void mnt_unpin(struct vfsmount *mnt);
+extern int __mnt_is_readonly(struct vfsmount *mnt);
static inline void mntput(struct vfsmount *mnt)
{
_
--
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/3] split clocksource mult into mult and mult_adj
The clocksource frequency is represented by
clocksource->mult/2^(clocksource->shift). Currently, when NTP makes
adjustments to the clock frequency, they are made directly to the mult
value.
This has the drawback that once changed, we cannot know what the orignal
mult value was, or how much adjustment has been applied.
This property causes problems in calculating proper ntp intervals when
switching back and forth between clocksources.
This patch separates the current mult value into a mult and mult_adj
pair. The mult value stays constant, while the ntp clocksource
adjustments are done only to the mult_adj value.
This allows for correct ntp interval calculation and additionally lays
the groundwork for a new notion of time, what I'm calling the
monotonic-raw time, which is introduced in a following patch.
Thoughts or comments would be appreciated.
thanks
-john
Signed-off-by: John Stultz <[EMAIL PROTECTED]>
diff --git a/arch/ia64/kernel/time.c b/arch/ia64/kernel/time.c
index 17fda52..37851e1 100644
--- a/arch/ia64/kernel/time.c
+++ b/arch/ia64/kernel/time.c
@@ -357,7 +357,7 @@ void update_vsyscall(struct timespec *wall, struct
clocksource *c)
/* copy fsyscall clock data */
fsyscall_gtod_data.clk_mask = c->mask;
-fsyscall_gtod_data.clk_mult = c->mult;
+fsyscall_gtod_data.clk_mult = c->mult + c->mult_adj;
fsyscall_gtod_data.clk_shift = c->shift;
fsyscall_gtod_data.clk_fsys_mmio = c->fsys_mmio;
fsyscall_gtod_data.clk_cycle_last = c->cycle_last;
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 3b26fbd..36aa8da 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -814,7 +814,7 @@ void update_vsyscall(struct timespec *wall_time, struct
clocksource *clock)
/* XXX this assumes clock->shift == 22 */
/* 4611686018 ~= 2^(20+64-22) / 1e9 */
- t2x = (u64) clock->mult * 4611686018ULL;
+ t2x = (u64) (clock->mult + clock->mult_adj) * 4611686018ULL;
stamp_xsec = (u64) xtime.tv_nsec * XSEC_PER_SEC;
do_div(stamp_xsec, 10);
stamp_xsec += (u64) xtime.tv_sec * XSEC_PER_SEC;
diff --git a/arch/x86/kernel/vsyscall_64.c b/arch/x86/kernel/vsyscall_64.c
index 3f82427..14afd48 100644
--- a/arch/x86/kernel/vsyscall_64.c
+++ b/arch/x86/kernel/vsyscall_64.c
@@ -83,7 +83,7 @@ void update_vsyscall(struct timespec *wall_time, struct
clocksource *clock)
vsyscall_gtod_data.clock.vread = clock->vread;
vsyscall_gtod_data.clock.cycle_last = clock->cycle_last;
vsyscall_gtod_data.clock.mask = clock->mask;
- vsyscall_gtod_data.clock.mult = clock->mult;
+ vsyscall_gtod_data.clock.mult = clock->mult + clock->mult_adj;
vsyscall_gtod_data.clock.shift = clock->shift;
vsyscall_gtod_data.wall_time_sec = wall_time->tv_sec;
vsyscall_gtod_data.wall_time_nsec = wall_time->tv_nsec;
diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h
index 85778a4..e917a30 100644
--- a/include/linux/clocksource.h
+++ b/include/linux/clocksource.h
@@ -45,7 +45,8 @@ struct clocksource;
* @read: returns a cycle value
* @mask: bitmask for two's complement
* subtraction of non 64 bit counters
- * @mult: cycle to nanosecond multiplier
+ * @mult: cycle to nanosecond multiplier (unadjusted)
+ * @mult_adj: NTP adjustment factor added to the multiplier
* @shift: cycle to nanosecond divisor (power of two)
* @flags: flags describing special properties
* @vread: vsyscall based read
@@ -63,6 +64,7 @@ struct clocksource {
cycle_t (*read)(void);
cycle_t mask;
u32 mult;
+ s32 mult_adj;
u32 shift;
unsigned long flags;
cycle_t (*vread)(void);
@@ -179,7 +181,7 @@ static inline cycle_t clocksource_read(struct clocksource
*cs)
static inline s64 cyc2ns(struct clocksource *cs, cycle_t cycles)
{
u64 ret = (u64)cycles;
- ret = (ret * cs->mult) >> cs->shift;
+ ret = (ret * (cs->mult + cs->mult_adj)) >> cs->shift;
return ret;
}
@@ -199,7 +201,7 @@ static inline void clocksource_calculate_interval(struct
clocksource *c,
{
u64 tmp;
- /* XXX - All of this could use a whole lot of optimization */
+ /* Do the ns -> cycle conversion first, ignoring mult_adj */
tmp = length_nsec;
tmp <<= c->shift;
tmp += c->mult/2;
@@ -209,7 +211,8 @@ static inline void clocksource_calculate_interval(struct
clocksource *c,
if (c->cycle_interval == 0)
c->cycle_interval = 1;
- c->xtime_interval = (u64)c->cycle_interval * c->mult;
+ /* Go back from cycles -> shifted ns, this time include mult_adj */
+ c->xtime_interval = (u64)c->cycle_interval * (c->mult + c->mult_adj);
}
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 1af9fb0..5b11b0f 100644
Re: [PATCH 1/2] remove rcu_assign_pointer(NULL) penalty with type/macro safety
On Fri, Feb 15, 2008 at 04:40:24PM -0800, Andrew Morton wrote:
> On Wed, 13 Feb 2008 14:00:24 -0800
> "Paul E. McKenney" <[EMAIL PROTECTED]> wrote:
>
> > Hello!
> >
> > This is an updated version of the patch posted last November:
> >
> > http://archives.free.net.ph/message/20071201.003721.cd6ff17c.en.html
> >
> > This new version permits arguments with side effects, for example:
> >
> > rcu_assign_pointer(global_p, p++);
> >
> > and also verifies that the arguments are pointers, while still avoiding
> > the unnecessary memory barrier when assigning NULL to a pointer.
> > This memory-barrier avoidance means that rcu_assign_pointer() is now only
> > permitted for pointers (not array indexes), and so this version emits a
> > compiler warning if the first argument is not a pointer. I built a "make
> > allyesconfig" version on an x86 system, and received no such warnings.
> > If RCU is ever applied to array indexes, then the second patch in this
> > series should be applied, and the resulting rcu_assign_index() be used.
> >
> > Given the rather surprising history of subtlely broken implementations of
> > rcu_assign_pointer(), I took the precaution of generating a full set of
> > test cases and verified that memory barriers and compiler warnings were
> > emitted when required. I guess it is the simple things that get you...
> >
> > Signed-off-by: Paul E. McKenney <[EMAIL PROTECTED]>
> > ---
> >
> > rcupdate.h | 16
> > 1 file changed, 12 insertions(+), 4 deletions(-)
> >
> > diff -urpNa -X dontdiff linux-2.6.24/include/linux/rcupdate.h
> > linux-2.6.24-rap/include/linux/rcupdate.h
> > --- linux-2.6.24/include/linux/rcupdate.h 2008-01-24 14:58:37.0
> > -0800
> > +++ linux-2.6.24-rap/include/linux/rcupdate.h 2008-02-13
> > 13:36:47.0 -0800
> > @@ -270,12 +270,20 @@ extern struct lockdep_map rcu_lock_map;
> > * structure after the pointer assignment. More importantly, this
> > * call documents which pointers will be dereferenced by RCU read-side
> > * code.
> > + *
> > + * Throws a compiler warning for non-pointer arguments.
> > + *
> > + * Does not insert a memory barrier for a NULL pointer.
> > */
> >
> > -#define rcu_assign_pointer(p, v) ({ \
> > - smp_wmb(); \
> > - (p) = (v); \
> > - })
> > +#define rcu_assign_pointer(p, v) \
> > + ({ \
> > + typeof(*p) *_p1 = (v); \
> > + \
> > + if (!__builtin_constant_p(v) || (_p1 != NULL)) \
> > + smp_wmb(); \
> > + (p) = _p1; \
> > + })
> >
>
> umm...
>
> net/netfilter/core.c: In function 'nf_register_afinfo':
> net/netfilter/core.c:39: warning: initialization discards qualifiers from
> pointer target type
> net/netfilter/nf_log.c: In function 'nf_log_register':
> net/netfilter/nf_log.c:37: warning: initialization discards qualifiers from
> pointer target type
> net/netfilter/nf_queue.c: In function 'nf_register_queue_handler':
> net/netfilter/nf_queue.c:38: warning: initialization discards qualifiers from
> pointer target type
Hmmm... Netfilter compiles cleanly here. My guess is that your gcc
is more fastidious about const declarations. Could you please either
let me know what arch/gcc-settings you are using, or, alternatively,
see if the following patch fixes things up? The comparison against
NULL should at least emit warnings for non-pointer types -- not as
good as an error, but better than emitting bogus warnings.
So I guess I should stick with simple things like preemptable RCU instead
of the much more difficult task of outsmarting gcc...
Signed-off-by: Paul E. McKenney <[EMAIL PROTECTED]>
---
rcupdate.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- rcupdate.h.old 2008-02-15 17:18:50.0 -0800
+++ rcupdate.h 2008-02-15 17:18:52.0 -0800
@@ -176,7 +176,7 @@ struct rcu_head {
#define rcu_assign_pointer(p, v) \
({ \
- typeof(*p) *_p1 = (v); \
+ typeof(p) _p1 = (v); \
\
if (!__builtin_constant_p(v) || ((_p1) != NULL)) \
smp_wmb(); \
--
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.25-rc1] jerky mouse cursor and randoooom key repeats
Pavel Machek wrote: > Hi! Hi , >> I'd not really done any real wor under 2.6.25 yet, but now while running >> a kernel compile with -j4 (single processor, dual core Pentium D), I see >> this behavior. The mouse cursor moves a bit jerky and I sometimes get key >> presses repeated. > > I see this one, too... x60, too... > I have that problem on my Dell Precision WorkStation , as soon I stress the box a bit keyboard is going mad. Gabriel -- 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] libata: Add MMIO support to pata_sil680
On 15 Feb 2008, at 21:45, Benjamin Herrenschmidt wrote: On Fri, 2008-02-15 at 15:53 +, Alan Cox wrote: That's strange though. Somebody with knowledge of that HW (or specs) who can spot something ? Could it be an issue with timing ? I don't have HW access to this machine. If somebody could send one to me I could do more investigation. Ben, would an ssh access to such a machine and to a terminal server suffice? It says clearly in the code where to start. See the FIXME notes in both libata-sff and libata-core about MMIO. Neither the DMA transfer start or the probe SRST sequence are correct with MMIO posting and this hasn't been fixed as I pointed out was needed when I originally NAKked the change. Without those being fixed (especially SRST) on any device with heavy PCI posting of mmio your controller *wont work*. The dbdma start is mostly harmless (things don't get posted for -that- long), though I suppose it's worth fixing. Would reading back dmactl do in that case or do you foresee any kind of side effect ? (Maybe only doing it for MMIO ?) As for SRST, I'm not totally confident how safe it is to read back there while doing the reset sequence, so I'm tempted to really only do it for MMIO and use altstat rather than ctl/stat (the later tends to have side effects which we don't want here). What do you think ? The main problem from here is that I don't know whether we are using MMIO or PIO from libata-core. Maybe I can add a host flag indicate that such flushing is needed ? In the meantime, Guennadi, can you check if that patch helps for you (to see if that is indeed the problem): diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c index 004dae4..1451a52 100644 --- a/drivers/ata/libata-core.c +++ b/drivers/ata/libata-core.c @@ -3461,10 +3461,13 @@ static int ata_bus_softreset(struct ata_port *ap, unsigned int devmask, /* software reset. causes dev0 to be selected */ iowrite8(ap->ctl, ioaddr->ctl_addr); + ioread16(ioaddr->nsect_addr); udelay(20); /* FIXME: flush */ iowrite8(ap->ctl | ATA_SRST, ioaddr->ctl_addr); + ioread16(ioaddr->nsect_addr); udelay(20); /* FIXME: flush */ iowrite8(ap->ctl, ioaddr->ctl_addr); + ioread16(ioaddr->nsect_addr); /* wait a while before checking status */ ata_wait_after_reset(ap, deadline); diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c index 60cd4b1..81d5828 100644 --- a/drivers/ata/libata-sff.c +++ b/drivers/ata/libata-sff.c @@ -273,6 +273,7 @@ void ata_bmdma_start(struct ata_queued_cmd *qc) * FIXME: The posting of this write means I/O starts are * unneccessarily delayed for MMIO */ + ioread8(ap->ioaddr.bmdma_addr + ATA_DMA_CMD); } /** Cheers, Ben. Unfortunately this patch appears to give same result as in the original post. Guennadi and I are looking into arranging access to a device. Thanks! <7>pata_sil680 :00:0c.0: version 0.4.8 <6>sil680: 133MHz clock. <6>scsi0 : pata_sil680 <6>scsi1 : pata_sil680 <6>ata1: PATA max UDMA/133 irq 18 <6>ata2: PATA max UDMA/133 irq 18 Tim -- 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 07/30] r/o bind mounts: stub functions
On Fri, 15 Feb 2008 20:00:30 -0500 Theodore Tso <[EMAIL PROTECTED]> wrote: > On Fri, Feb 15, 2008 at 04:49:39PM -0800, Dave Hansen wrote: > > On Fri, 2008-02-15 at 19:32 -0500, Theodore Tso wrote: > > > On Fri, Feb 15, 2008 at 02:37:30PM -0800, Dave Hansen wrote: > > > > > > > > This patch adds two function mnt_want_write() and mnt_drop_write(). > > > > These are used like a lock pair around and fs operations that might > > > > cause a write to the filesystem. > > > > > > Argh, is there some reason why this couldn't have gotten merged in > > > -rc1, ahead of the rest of the patch series? This one is going to > > > cause more cross-tree merge pain with any filesystem tree that have > > > changes to fs/*/ioctl.c. > > > > I wasn't meaning for this to hit the 2.6.25-rc series. We had some > > review comments just when the merge window opened, and I was expecting > > them to get stuck back in -mm for another round. > > Yeah, but it means that I need one set of patches for -mm, and another > set of patches for Linus's mainline. I notice that your patchset is > currently missing changes for fs/ext4/ioctl.c --- I think because you > dropped them when Mingming picked them up, and then I dropped them > when I was trying to prepare the set of patches to push to Linus. > > No problem, I'm sure I can ressurect them, but it's still the same > basic problem that when there are patchsets such as yours which touch > multiple trees in -mm, there are almost inevitably patch conflicts. > > It would be nice if an initial patch which introduces the new > functionality you need for r/o bind mounts could get introduced into > mainline *first*, and then people could add patches that call > mnt_want_write(), et. al into their trees gradually. Yes, I expect that merging a handful of do-nothing mnt_foo_write() functions into mainline right now would ease life. > otherwise akpm gets grumpy itym "less than usually cheery" -- 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 00/14] [ISDN] HiSax hotplug conversion
On Tue, 17 Jul 2007 23:04:04 -0400 Jeff Garzik <[EMAIL PROTECTED]> wrote: > This is a refresh of an on-going work-in-progress: convert the last > remaining users of pci_find_device() to the ISA/PCI/etc. hotplug APIs > now in standard use. After SCSI's gdth, ISDN's HiSax suite of drivers > are just about the last place using the older API. > > A few rough edges remain, and I'm not sure how much of ISDN userland > will explode (I have no ISDN hardware, nor much want any:)), but this > should get us almost all the way there. > > The patches are diff'd against 2.6.25-rc1. > > Comments/review/testing welcome. Especially "it works" or "its dead" > testing. When `make modules_install' runs depmod using http://userweb.kernel.org/~akpm/config-akpm2.txt these patches cause this: WARNING: Module /lib/modules/2.6.25-rc2-mm1/kernel/drivers/isdn/hisax/teles_cs.ko ignored, due to loop WARNING: Module /lib/modules/2.6.25-rc2-mm1/kernel/drivers/isdn/hisax/hisax_st5481.ko ignored, due to loop WARNING: Module /lib/modules/2.6.25-rc2-mm1/kernel/drivers/isdn/hisax/elsa_cs.ko ignored, due to loop WARNING: Module /lib/modules/2.6.25-rc2-mm1/kernel/drivers/isdn/hisax/hfc4s8s_l1.ko ignored, due to loop WARNING: Module /lib/modules/2.6.25-rc2-mm1/kernel/drivers/isdn/hisax/hisax_isac.ko ignored, due to loop WARNING: Module /lib/modules/2.6.25-rc2-mm1/kernel/drivers/isdn/hisax/avma1_cs.ko ignored, due to loop WARNING: Module /lib/modules/2.6.25-rc2-mm1/kernel/drivers/isdn/hisax/libhisax.ko ignored, due to loop WARNING: Loop detected: /lib/modules/2.6.25-rc2-mm1/kernel/drivers/isdn/hisax/hisax.ko needs libhisax.ko which needs hisax.ko again! WARNING: Module /lib/modules/2.6.25-rc2-mm1/kernel/drivers/isdn/hisax/hisax.ko ignored, due to loop WARNING: Module /lib/modules/2.6.25-rc2-mm1/kernel/drivers/isdn/hisax/sedlbauer_cs.ko ignored, due to loop WARNING: Module /lib/modules/2.6.25-rc2-mm1/kernel/drivers/isdn/hisax/hisax_fcpcipnp.ko ignored, due to loop -- 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] acpi: sparse fix, replace macro with static function
replace acpi_util_eval_error macro with static function.
Avoid these sparse warnings due to using buffer within the macro.
drivers/acpi/utils.c:273:3: warning: symbol 'buffer' shadows an earlier one
drivers/acpi/utils.c:259:21: originally declared here
drivers/acpi/utils.c:279:3: warning: symbol 'buffer' shadows an earlier one
drivers/acpi/utils.c:259:21: originally declared here
drivers/acpi/utils.c:368:3: warning: symbol 'buffer' shadows an earlier one
drivers/acpi/utils.c:348:21: originally declared here
drivers/acpi/utils.c:375:3: warning: symbol 'buffer' shadows an earlier one
drivers/acpi/utils.c:348:21: originally declared here
drivers/acpi/utils.c:382:3: warning: symbol 'buffer' shadows an earlier one
drivers/acpi/utils.c:348:21: originally declared here
drivers/acpi/utils.c:402:4: warning: symbol 'buffer' shadows an earlier one
drivers/acpi/utils.c:348:21: originally declared here
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
drivers/acpi/utils.c | 18 +++---
1 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/acpi/utils.c b/drivers/acpi/utils.c
index 34f1575..eba55b7 100644
--- a/drivers/acpi/utils.c
+++ b/drivers/acpi/utils.c
@@ -36,16 +36,20 @@ ACPI_MODULE_NAME("utils");
/* --
Object Evaluation Helpers
--
*/
+static void
+acpi_util_eval_error(acpi_handle h, acpi_string p, acpi_status s)
+{
#ifdef ACPI_DEBUG_OUTPUT
-#define acpi_util_eval_error(h,p,s) {\
- char prefix[80] = {'\0'};\
- struct acpi_buffer buffer = {sizeof(prefix), prefix};\
- acpi_get_name(h, ACPI_FULL_PATHNAME, &buffer);\
- ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Evaluate [%s.%s]: %s\n",\
- (char *) prefix, p, acpi_format_exception(s))); }
+ char prefix[80] = {'\0'};
+ struct acpi_buffer buffer = {sizeof(prefix), prefix};
+ acpi_get_name(h, ACPI_FULL_PATHNAME, &buffer);
+ ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Evaluate [%s.%s]: %s\n",
+ (char *) prefix, p, acpi_format_exception(s)));
#else
-#define acpi_util_eval_error(h,p,s)
+ return;
#endif
+}
+
acpi_status
acpi_extract_package(union acpi_object *package,
struct acpi_buffer *format, struct acpi_buffer *buffer)
--
1.5.4.1.1278.gc75be
--
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: Driver removals
Adrian Bunk wrote: On Fri, Feb 15, 2008 at 02:07:41PM -0500, Bill Davidsen wrote: Adrian Bunk wrote: On Wed, Feb 13, 2008 at 09:26:26PM -0500, Bill Davidsen wrote: ... In general, if a driver works and is being used, until it *needs* attention I see no reason to replace it. I don't agree that "it forces people to try the new driver" is a valid reason, being unmaintained is only a problem if it needs maintenance. I am not going to reopen that topic, I'm simply noting a general opposition to unfunded mandates, and requiring changes to kernel, module and/or rc.local config is just that. Keeping a working unmaintained driver in the tree is not a big deal - we have hundreds of them. But you miss the main point that removal of an obsolete driver with a new replacement driver forces people to finally report their problems with the new driver, thus making the new driver better. You sure are proud of that new driver! People won't use it because the old one is working fine, so you think it's fine to force them to make changes in their system to use the new driver. Sometimes what is best in the global picture is not what everyone subjectively considers to be the best thing for him. Well, our whole society is based on this principle... Best case is it works after costing the user some time, worst case it doesn't and breaks their system, so they stop upgrading the kernel and don't get security fixes. ... Instead of sending a bug report? To get the system working. When removing an obsolete driver adult people suddenly start whining "the new driver didn't work for me when I tried it one year ago". And when asking where they reported the bug in the new driver the answer is that they didn't report it. Driver development heavily relies on getting bug reports when something doesn't work. If you don't see an ethical problem in removing a working driver which is not taking support resources, in order to force people to test and debug a driver they don't now and never would need, so that it might in time offer them the same functionality those users already had... then I can never make you see why technological extortion is evil. People have always moved to new drivers without pushing because they were *better*, guess that model is dead. -- Bill Davidsen <[EMAIL PROTECTED]> "Woe unto the statesman who makes war without a reason that will still be valid when the war is over..." Otto von Bismark -- 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: pci_device_id definition cleanups
On Fri, Feb 15, 2008 at 07:55:07PM -0500, Jeff Garzik wrote: > Greg KH wrote: >> On Sat, Feb 16, 2008 at 12:21:40AM +0100, Jonas Bonn wrote: >>> I've done some work on cleaning up the definitions of pci_device_id to >>> make them "static const" (where possible) and to make sure they go into >>> __devinitconst. There are about 350 changes of the type shown in the >>> diff at the end of this mail. >>> >>> ???All these changes are in my public GIT tree at: >>> >>> git://www.southpole.se/~jonas/git/linux.git >>> >>> (Based on 2.6.25-rc2) >>> >>> In addition to these pci_device_id changes, there are a few changesets >>> that move "const" data from __devinitdata to __devinitconst. >>> >>> The tree above builds with both allmodconfig and allyesconfig. >> Hm, does this save us any memory on any type of configuration? >> What about drivers that end up writing to these structures (I know some >> USB drivers do, not sure about PCI ones.) > > I don't recall ever seeing a PCI driver do that... and if it exists on the > PCI side, I would be motivated to create patches to "fix" such behavior :) > > That information is exported to utilities that expect that table to be > static. Messing around with it is just hacky, and bound to produce > unwanted edge cases. Well, the USB drivers used to add an additional NULL entry at the end of the list, and then populate it based on module parameters. That way the userspace tools would always work just fine, and you could add additional device ids at run-time. Now we have a way to do this for all USB and PCI drivers through sysfs, so it's not needed, but we have to keep the backwards compatiblity for a while in a number of USB drivers. Hopefully PCI drivers didn't do the same thing, but I haven't looked at all of them to verify this or not :) 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/
Re: [PATCH 07/30] r/o bind mounts: stub functions
On Fri, Feb 15, 2008 at 04:49:39PM -0800, Dave Hansen wrote: > On Fri, 2008-02-15 at 19:32 -0500, Theodore Tso wrote: > > On Fri, Feb 15, 2008 at 02:37:30PM -0800, Dave Hansen wrote: > > > > > > This patch adds two function mnt_want_write() and mnt_drop_write(). > > > These are used like a lock pair around and fs operations that might > > > cause a write to the filesystem. > > > > Argh, is there some reason why this couldn't have gotten merged in > > -rc1, ahead of the rest of the patch series? This one is going to > > cause more cross-tree merge pain with any filesystem tree that have > > changes to fs/*/ioctl.c. > > I wasn't meaning for this to hit the 2.6.25-rc series. We had some > review comments just when the merge window opened, and I was expecting > them to get stuck back in -mm for another round. Yeah, but it means that I need one set of patches for -mm, and another set of patches for Linus's mainline. I notice that your patchset is currently missing changes for fs/ext4/ioctl.c --- I think because you dropped them when Mingming picked them up, and then I dropped them when I was trying to prepare the set of patches to push to Linus. No problem, I'm sure I can ressurect them, but it's still the same basic problem that when there are patchsets such as yours which touch multiple trees in -mm, there are almost inevitably patch conflicts. It would be nice if an initial patch which introduces the new functionality you need for r/o bind mounts could get introduced into mainline *first*, and then people could add patches that call mnt_want_write(), et. al into their trees gradually. As it is, I can't see a way around this other than maintaining two separate patch sets, one that works with r/o bind mounts, and one for mainline, since otherwise akpm gets grumpy and starts dropping either your patchset or the ext4 patchset because *he* has to manually fix up the patch conflicts. (So instead I have to deal with it by hand, and then *I* get grumpy. :-/) - Ted -- 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] (02/15/08 Linus git) Smack unlabeled outgoing ambient packets - v4
From: Casey Schaufler <[EMAIL PROTECTED]>
Smack uses CIPSO labeling, but allows for unlabeled packets
by specifying an "ambient" label that is applied to incoming
unlabeled packets. Because the other end of the connection
may dislike IP options, and ssh is one know application that
behaves thus, it is prudent to respond in kind. This patch
changes the network labeling behavior such that an outgoing
packet that would be given a CIPSO label that matches the
ambient label is left unlabeled. An "unlbl" domain is added
and the netlabel defaulting mechanism invoked rather than
assuming that everything is CIPSO. Locking has been added
around changes to the ambient label as the mechanisms used
to do so are more involved.
Cleaned up some issues noted in review.
Make smk_cipso_doi() static.
Create a hook for the new security_secctx_to_secid()
using existing underlying code.
Fill in audit data for netlbl domain calls.
Collapse unnecessary multiple assignments.
Signed-off-by: Casey Schaufler <[EMAIL PROTECTED]>
---
security/smack/smack_lsm.c | 36
security/smack/smackfs.c | 61 ++-
2 files changed, 74 insertions(+), 23 deletions(-)
diff -uprN -X linux-2.6.25-g0215-base//Documentation/dontdiff
linux-2.6.25-g0215-base/security/smack/smackfs.c
linux-2.6.25-g0215/security/smack/smackfs.c
--- linux-2.6.25-g0215-base/security/smack/smackfs.c2008-02-15
14:25:37.0 -0800
+++ linux-2.6.25-g0215/security/smack/smackfs.c 2008-02-15 14:30:36.0
-0800
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include "smack.h"
/*
@@ -45,6 +46,7 @@ enum smk_inos {
*/
static DEFINE_MUTEX(smack_list_lock);
static DEFINE_MUTEX(smack_cipso_lock);
+static DEFINE_MUTEX(smack_ambient_lock);
/*
* This is the "ambient" label for network traffic.
@@ -342,6 +344,9 @@ void smk_cipso_doi(void)
struct cipso_v4_doi *doip;
struct netlbl_audit audit_info;
+ audit_info.loginuid = audit_get_loginuid(current);
+ audit_info.secid = smack_to_secid(current->security);
+
rc = netlbl_cfg_map_del(NULL, &audit_info);
if (rc != 0)
printk(KERN_WARNING "%s:%d remove rc = %d\n",
@@ -363,6 +368,30 @@ void smk_cipso_doi(void)
__func__, __LINE__, rc);
}
+/**
+ * smk_unlbl_ambient - initialize the unlabeled domain
+ */
+void smk_unlbl_ambient(char *oldambient)
+{
+ int rc;
+ struct netlbl_audit audit_info;
+
+ audit_info.loginuid = audit_get_loginuid(current);
+ audit_info.secid = smack_to_secid(current->security);
+
+ if (oldambient != NULL) {
+ rc = netlbl_cfg_map_del(oldambient, &audit_info);
+ if (rc != 0)
+ printk(KERN_WARNING "%s:%d remove rc = %d\n",
+ __func__, __LINE__, rc);
+ }
+
+ rc = netlbl_cfg_unlbl_add_map(smack_net_ambient, &audit_info);
+ if (rc != 0)
+ printk(KERN_WARNING "%s:%d add rc = %d\n",
+ __func__, __LINE__, rc);
+}
+
/*
* Seq_file read operations for /smack/cipso
*/
@@ -709,7 +738,6 @@ static ssize_t smk_read_ambient(struct f
size_t cn, loff_t *ppos)
{
ssize_t rc;
- char out[SMK_LABELLEN];
int asize;
if (*ppos != 0)
@@ -717,23 +745,18 @@ static ssize_t smk_read_ambient(struct f
/*
* Being careful to avoid a problem in the case where
* smack_net_ambient gets changed in midstream.
-* Since smack_net_ambient is always set with a value
-* from the label list, including initially, and those
-* never get freed, the worst case is that the pointer
-* gets changed just after this strncpy, in which case
-* the value passed up is incorrect. Locking around
-* smack_net_ambient wouldn't be any better than this
-* copy scheme as by the time the caller got to look
-* at the ambient value it would have cleared the lock
-* and been changed.
*/
- strncpy(out, smack_net_ambient, SMK_LABELLEN);
- asize = strlen(out) + 1;
+ mutex_lock(&smack_ambient_lock);
- if (cn < asize)
- return -EINVAL;
+ asize = strlen(smack_net_ambient) + 1;
+
+ if (cn >= asize)
+ rc = simple_read_from_buffer(buf, cn, ppos,
+smack_net_ambient, asize);
+ else
+ rc = -EINVAL;
- rc = simple_read_from_buffer(buf, cn, ppos, out, asize);
+ mutex_unlock(&smack_ambient_lock);
return rc;
}
@@ -751,6 +774,7 @@ static ssize_t smk_write_ambient(struct
size_t count, loff_t *ppos)
{
char in[SMK_LABELLEN];
+ char *oldambient;
char *smack;
if (!capable(CAP_MAC_ADMIN))
@@ -766,7 +790,13 @@ static ssize_t smk_write_ambient(struct
if (smack == NULL)
return -EINVAL;
+ mutex_lock(&smack_ambient_l
Re: pci_device_id definition cleanups
Greg KH wrote: On Sat, Feb 16, 2008 at 12:21:40AM +0100, Jonas Bonn wrote: I've done some work on cleaning up the definitions of pci_device_id to make them "static const" (where possible) and to make sure they go into __devinitconst. There are about 350 changes of the type shown in the diff at the end of this mail. ???All these changes are in my public GIT tree at: git://www.southpole.se/~jonas/git/linux.git (Based on 2.6.25-rc2) In addition to these pci_device_id changes, there are a few changesets that move "const" data from __devinitdata to __devinitconst. The tree above builds with both allmodconfig and allyesconfig. Hm, does this save us any memory on any type of configuration? What about drivers that end up writing to these structures (I know some USB drivers do, not sure about PCI ones.) I don't recall ever seeing a PCI driver do that... and if it exists on the PCI side, I would be motivated to create patches to "fix" such behavior :) That information is exported to utilities that expect that table to be static. Messing around with it is just hacky, and bound to produce unwanted edge cases. You're going to need to send out patches for these to the different developers, a git tree isn't going to help much. Agreed. 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: [2.6.25-rc1] jerky mouse cursor and randoooom key repeats
Frans & Pavel;
I too saw the random key repeats you are seeing with 2.6.25-rc1 -
however, I saw it (or something very much like the problem you are
reporting - I am not smart enough to determine if the root cause is the
same) with 2.6.25-git15
A number of corrispondents on this list offered troubleshooting
suggestions, most of which centered arund the high performance timer.
If you too feel that the issue you are seeing might be releated to the
one I saw the following clips from the email I received might be of
interest to you.
>From Jiri Kosina:
It could be some timing problem. Does this happen also in console, or
only when running X?
Could you please try to
- boot with 'nohpet' kernel parameter
- taskset -p 0x0002 if this is a multi-CPU/core
machine and you are experiencing the problems only in X
>From Thomas Gleixner:
Can you please apply the following patch, boot w/o nohpet and provide
the dmesg output ?
diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
index 429d084..4e98241 100644
--- a/arch/x86/kernel/hpet.c
+++ b/arch/x86/kernel/hpet.c
@@ -375,8 +375,10 @@ int __init hpet_enable(void)
{
unsigned long id;
- if (!is_hpet_capable())
+ if (!is_hpet_capable()) {
+ printk(KERN_INFO "HPET not available\n");
return 0;
+ }
hpet_set_mapping();
@@ -392,6 +394,7 @@ int __init hpet_enable(void)
* information and the number of channels
*/
id = hpet_readl(HPET_ID);
+ printk(KERN_INFO "HPET available. ID = %lx\n", id);
#ifdef CONFIG_HPET_EMULATE_RTC
/*
@@ -412,6 +415,7 @@ int __init hpet_enable(void)
return 0;
out_nohpet:
+ printk(KERN_INFO "HPET disabled\n");
hpet_clear_mapping();
boot_hpet_disable = 1;
return 0;
I have been trying to narrow it down using bisect (my first attempt at
using this utility) with mixed results - just when I think I understand
where the problem was introduced I hit a brick wall.
However, you comment on system loading may have turned the old light
bulb on - that is one area where I have not been consistant.
Chris
--
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: [git patches] net driver fixes
David Miller wrote: From: Jeff Garzik <[EMAIL PROTECTED]> Date: Fri, 15 Feb 2008 11:03:14 -0500 Please pull from 'upstream-davem' branch of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream-davem Pulled and pushed out. As I mentioned to John Linville just now, I'm going to try and keep net-2.6 running as long as I can without rebasing. So you can just keep piling patches into your upstream-davem branch without fear of my turning your world upside down with a rebase :-) Thanks, it's appreciated! 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: [PATCH 07/30] r/o bind mounts: stub functions
On Fri, 2008-02-15 at 19:32 -0500, Theodore Tso wrote: > On Fri, Feb 15, 2008 at 02:37:30PM -0800, Dave Hansen wrote: > > > > This patch adds two function mnt_want_write() and mnt_drop_write(). > > These are used like a lock pair around and fs operations that might > > cause a write to the filesystem. > > Argh, is there some reason why this couldn't have gotten merged in > -rc1, ahead of the rest of the patch series? This one is going to > cause more cross-tree merge pain with any filesystem tree that have > changes to fs/*/ioctl.c. I wasn't meaning for this to hit the 2.6.25-rc series. We had some review comments just when the merge window opened, and I was expecting them to get stuck back in -mm for another round. -- Dave -- 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: Announce: Linux-next (Or Andrew's dream :-))
On Sat, 16 Feb 2008 00:31:36 + Russell King <[EMAIL PROTECTED]> wrote: > > so would a stupid `for i in arch/arm/configs/*' script be sufficient > > coverage? > > It will certainly improve the situation significantly, and pick up > on some non-ARM problems like (badge4_defconfig, since 2.6.24-git2): OK, I'll toss something together. > the latter seems to be because the PCMCIA changes were lost > on the linux-pcmcia list and the trizeps folk have probably given up. I appear to be pcmcia maintainer lately so if someone wants to dust them off and send them over we can see what we can do? -- 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: Announce: Linux-next (Or Andrew's dream :-))
On Fri, Feb 15, 2008 at 04:21:21PM -0800, Andrew Morton wrote: > On Sat, 16 Feb 2008 00:09:43 + > Russell King <[EMAIL PROTECTED]> wrote: > > > For reference, even _I_ don't build test the entire set of ARM defconfigs - > > at about 7 minutes a build, 75 defconfigs, that's about 9 hours... I > > just build those which are important to myself, hope that the others are > > fine, and rely on kautobuild finding any breakage. > > > > you need a better box ;) > > cerfcube_defconfig: 35 seconds > carmeva_defconfig:23 seconds > spitz_defconfig (one of the biggest): 45 seconds > > so would a stupid `for i in arch/arm/configs/*' script be sufficient > coverage? I do this wildcard together with yes '' | make ARCH=arm ... oldconfig make Sans toolchain issues, it's pretty good -- Russell larts you when some defconfig becomes broken anyway. :^) -- 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/
Kernel oops with bluetooth usb dongle
Hi, Since the rc's of 2.6.24, my machine crashes when I try to use the USB dongle. No other activity seems to create a crash. The system is stable with 2.6.23.1. It is a Dell Dimension 8400 updated daily to mandriva cooker. I am not subscribed to this list, so please CC me if there is any more information I can provide. Here is the Oops with 2.6.25-rc1: BUG: unable to handle kernel NULL pointer dereference at IP: [] get_next_timer_interrupt+0xfe/0x210 *pde = Oops: [#1] SMP Modules linked in: hidp rfcomm l2cap nfsd auth_rpcgss exportfs nfs lockd nfs_acl sunrpc af_packet binfmt_misc loop nls_iso8859_1 nls_cp437 vfat fat dm_mod piix ide_core fuse snd_pcm_oss snd_mixer_oss hci_usb snd_intel8x0 snd_ac97_codec ac97_bus thermal button snd_pcm i2c_i801 snd_timer parport_pc processor snd parport pcspkr i2c_core evdev dcdbas tg3 soundcore rtc_cmos bluetooth snd_page_alloc iTCO_wdt sr_mod iTCO_vendor_support sg ata_piix ahci libata sd_mod scsi_mod ext3 jbd uhci_hcd ohci_hcd ssb pcmcia pcmcia_core ehci_hcd usbcore [last unloaded: scsi_wait_scan] Pid: 0, comm: swapper Not tainted (2.6.25-rc1 #1) EIP: 0060:[] EFLAGS: 00010097 CPU: 0 EIP is at get_next_timer_interrupt+0xfe/0x210 EAX: EBX: ECX: c047e7dc EDX: ESI: 0026 EDI: c047e6ac EBP: c03f5f60 ESP: c03f5f28 DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 Process swapper (pid: 0, ti=c03f4000 task=c03c9300 task.ti=c03f4000) Stack: 0005a600 0005a55b c047dea0 0001 0026 05a6 c047e6ac c047e8ac c047eaac c047ecac c1808340 ffc484c0 0005a55b c03f5fa4 c014627c ffd3c700 c03c9300 c03c947c c180b420 ffc4cdde 009b ffc484c0 009b Call Trace: [] ? tick_nohz_stop_sched_tick+0x13c/0x350 [] ? tick_nohz_restart_sched_tick+0xfc/0x140 [] ? default_idle+0x0/0xa0 [] ? cpu_idle+0x34/0x110 [] ? rest_init+0x49/0x50 === Code: e0 89 c6 89 45 dc 8d b4 26 00 00 00 00 8b 04 f7 8b 10 0f 18 02 90 8d 0c f7 39 c8 0f 84 83 00 00 00 8b 40 08 39 d8 0f 48 d8 89 d0 <8b> 12 0f 18 02 90 39 c1 75 ec c7 45 d4 01 00 00 00 8b 7d dc 85 EIP: [] get_next_timer_interrupt+0xfe/0x210 SS:ESP 0068:c03f5f28 ---[ end trace 5fb484ad8037e593 ]--- Kernel panic - not syncing: Attempted to kill the idle task! $ lsub -vvv 00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 (rev 03) (prog-if 00 [UHCI]) Subsystem: Dell Dimension 8400 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] remove rcu_assign_pointer(NULL) penalty with type/macro safety
On Wed, 13 Feb 2008 14:00:24 -0800
"Paul E. McKenney" <[EMAIL PROTECTED]> wrote:
> Hello!
>
> This is an updated version of the patch posted last November:
>
> http://archives.free.net.ph/message/20071201.003721.cd6ff17c.en.html
>
> This new version permits arguments with side effects, for example:
>
> rcu_assign_pointer(global_p, p++);
>
> and also verifies that the arguments are pointers, while still avoiding
> the unnecessary memory barrier when assigning NULL to a pointer.
> This memory-barrier avoidance means that rcu_assign_pointer() is now only
> permitted for pointers (not array indexes), and so this version emits a
> compiler warning if the first argument is not a pointer. I built a "make
> allyesconfig" version on an x86 system, and received no such warnings.
> If RCU is ever applied to array indexes, then the second patch in this
> series should be applied, and the resulting rcu_assign_index() be used.
>
> Given the rather surprising history of subtlely broken implementations of
> rcu_assign_pointer(), I took the precaution of generating a full set of
> test cases and verified that memory barriers and compiler warnings were
> emitted when required. I guess it is the simple things that get you...
>
> Signed-off-by: Paul E. McKenney <[EMAIL PROTECTED]>
> ---
>
> rcupdate.h | 16
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff -urpNa -X dontdiff linux-2.6.24/include/linux/rcupdate.h
> linux-2.6.24-rap/include/linux/rcupdate.h
> --- linux-2.6.24/include/linux/rcupdate.h 2008-01-24 14:58:37.0
> -0800
> +++ linux-2.6.24-rap/include/linux/rcupdate.h 2008-02-13 13:36:47.0
> -0800
> @@ -270,12 +270,20 @@ extern struct lockdep_map rcu_lock_map;
> * structure after the pointer assignment. More importantly, this
> * call documents which pointers will be dereferenced by RCU read-side
> * code.
> + *
> + * Throws a compiler warning for non-pointer arguments.
> + *
> + * Does not insert a memory barrier for a NULL pointer.
> */
>
> -#define rcu_assign_pointer(p, v) ({ \
> - smp_wmb(); \
> - (p) = (v); \
> - })
> +#define rcu_assign_pointer(p, v) \
> + ({ \
> + typeof(*p) *_p1 = (v); \
> + \
> + if (!__builtin_constant_p(v) || (_p1 != NULL)) \
> + smp_wmb(); \
> + (p) = _p1; \
> + })
>
umm...
net/netfilter/core.c: In function 'nf_register_afinfo':
net/netfilter/core.c:39: warning: initialization discards qualifiers from
pointer target type
net/netfilter/nf_log.c: In function 'nf_log_register':
net/netfilter/nf_log.c:37: warning: initialization discards qualifiers from
pointer target type
net/netfilter/nf_queue.c: In function 'nf_register_queue_handler':
net/netfilter/nf_queue.c:38: warning: initialization discards qualifiers from
pointer target type
--
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 07/30] r/o bind mounts: stub functions
On Fri, Feb 15, 2008 at 02:37:30PM -0800, Dave Hansen wrote: > > This patch adds two function mnt_want_write() and mnt_drop_write(). > These are used like a lock pair around and fs operations that might > cause a write to the filesystem. Argh, is there some reason why this couldn't have gotten merged in -rc1, ahead of the rest of the patch series? This one is going to cause more cross-tree merge pain with any filesystem tree that have changes to fs/*/ioctl.c. - Ted -- 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: Announce: Linux-next (Or Andrew's dream :-))
On Fri, Feb 15, 2008 at 04:21:21PM -0800, Andrew Morton wrote: > On Sat, 16 Feb 2008 00:09:43 + > Russell King <[EMAIL PROTECTED]> wrote: > > > For reference, even _I_ don't build test the entire set of ARM defconfigs - > > at about 7 minutes a build, 75 defconfigs, that's about 9 hours... I > > just build those which are important to myself, hope that the others are > > fine, and rely on kautobuild finding any breakage. > > > > you need a better box ;) Maybe - it's a lowly 2.6GHz P4 with 1GB RAM, ICH5, and SATA disk. > cerfcube_defconfig: 35 seconds > carmeva_defconfig:23 seconds > spitz_defconfig (one of the biggest): 45 seconds > > so would a stupid `for i in arch/arm/configs/*' script be sufficient > coverage? It will certainly improve the situation significantly, and pick up on some non-ARM problems like (badge4_defconfig, since 2.6.24-git2): drivers/built-in.o: In function `v4l2_i2c_attach': drivers/media/video/v4l2-common.c:1035: undefined reference to `i2c_attach_client' Currently, the defconfigs known to fail (long term) in Linus' tree are clps7500_defconfig and trizeps4_defconfig - the former I'm tempted to remove, the latter seems to be because the PCMCIA changes were lost on the linux-pcmcia list and the trizeps folk have probably given up. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- 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: Announce: Linux-next (Or Andrew's dream :-))
Russell King wrote: On Fri, Feb 15, 2008 at 03:47:24PM -0800, Randy Dunlap wrote: On Fri, 15 Feb 2008 15:37:32 -0800 Andrew Morton wrote: I wonder why I didn't see any of this - I build arm allmodconfig at least once a week, usually more frequently. Basically, you don't build any of the PXA platforms, which is what was affected. So either the offending patches weren't in my pile or arm allmodconfig is worse than I thought :( It really is in arch maintainers' best interest to keep their allmodconfig in good shape, for this reason. arm's _isn't_ in good shape: the compile fails for several long-standing reasons (eg: no hope of building DRM) and I don't think the coverage is very broad either. I think that Russell has said that allmodconfig isn't very realistic for ARM, with its 70+ config files. Nevertheless, having a usable allmodconfig would be very helpful. Which is quite impossible. I've said all along that all*config is bad news for ARM and folk haven't listened. allmodconfig can (and does) work on some platform configurations such as the one Andrew builds - which will be based on the Versatile platform. However, that doesn't get _any_ of the PXA SoC drivers scattered throughout the tree, the PXA SoC support in arch/arm/mach-pxa, none of the PXA platform support files. If you built an allmodconfig PXA configuration, you'd get those, but you wouldn't get the OMAP SoC drivers, nor the ARM Primecell drivers found on ARMs Integrator, Versatile and Realview platforms and the Cirrus EP93xx SoCs. Nor the Atmel AT91 drivers... and so the list goes on. Each family of platforms are, unfortunately, quite distinct from each other. Does that mean that an artificial allarmconfig can't be made to build? We clearly don't care whether it can boot or work, but we would just as clearly like to be able to build more ARM stuff without N (N > 10) configs. -- ~Randy -- 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: Announce: Linux-next (Or Andrew's dream :-))
On Fri, Feb 15, 2008 at 03:47:24PM -0800, Randy Dunlap wrote: > On Fri, 15 Feb 2008 15:37:32 -0800 Andrew Morton wrote: > > I wonder why I didn't see any of this - I build arm allmodconfig at least > > once a week, usually more frequently. Basically, you don't build any of the PXA platforms, which is what was affected. > > So either the offending patches weren't in my pile or arm allmodconfig is > > worse than I thought :( > > > > It really is in arch maintainers' best interest to keep their allmodconfig > > in good shape, for this reason. arm's _isn't_ in good shape: the compile > > fails for several long-standing reasons (eg: no hope of building DRM) and I > > don't think the coverage is very broad either. > > I think that Russell has said that allmodconfig isn't very realistic > for ARM, with its 70+ config files. Nevertheless, having a usable > allmodconfig would be very helpful. Which is quite impossible. I've said all along that all*config is bad news for ARM and folk haven't listened. allmodconfig can (and does) work on some platform configurations such as the one Andrew builds - which will be based on the Versatile platform. However, that doesn't get _any_ of the PXA SoC drivers scattered throughout the tree, the PXA SoC support in arch/arm/mach-pxa, none of the PXA platform support files. If you built an allmodconfig PXA configuration, you'd get those, but you wouldn't get the OMAP SoC drivers, nor the ARM Primecell drivers found on ARMs Integrator, Versatile and Realview platforms and the Cirrus EP93xx SoCs. Nor the Atmel AT91 drivers... and so the list goes on. Each family of platforms are, unfortunately, quite distinct from each other. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- 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: Announce: Linux-next (Or Andrew's dream :-))
On Sat, 16 Feb 2008 00:09:43 + Russell King <[EMAIL PROTECTED]> wrote: > For reference, even _I_ don't build test the entire set of ARM defconfigs - > at about 7 minutes a build, 75 defconfigs, that's about 9 hours... I > just build those which are important to myself, hope that the others are > fine, and rely on kautobuild finding any breakage. > you need a better box ;) cerfcube_defconfig: 35 seconds carmeva_defconfig: 23 seconds spitz_defconfig (one of the biggest): 45 seconds so would a stupid `for i in arch/arm/configs/*' script be sufficient coverage? -- 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: pci_device_id definition cleanups
On Sat, Feb 16, 2008 at 12:21:40AM +0100, Jonas Bonn wrote: > I've done some work on cleaning up the definitions of pci_device_id to > make them "static const" (where possible) and to make sure they go into > __devinitconst. There are about 350 changes of the type shown in the > diff at the end of this mail. > > ???All these changes are in my public GIT tree at: > > git://www.southpole.se/~jonas/git/linux.git > > (Based on 2.6.25-rc2) > > In addition to these pci_device_id changes, there are a few changesets > that move "const" data from __devinitdata to __devinitconst. > > The tree above builds with both allmodconfig and allyesconfig. Hm, does this save us any memory on any type of configuration? What about drivers that end up writing to these structures (I know some USB drivers do, not sure about PCI ones.) You're going to need to send out patches for these to the different developers, a git tree isn't going to help much. 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/
Re: [git patches] net driver fixes
From: Jeff Garzik <[EMAIL PROTECTED]> Date: Fri, 15 Feb 2008 11:03:14 -0500 > Please pull from 'upstream-davem' branch of > master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git > upstream-davem Pulled and pushed out. As I mentioned to John Linville just now, I'm going to try and keep net-2.6 running as long as I can without rebasing. So you can just keep piling patches into your upstream-davem branch without fear of my turning your world upside down with a rebase :-) -- 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/
