Re: 2.6.23-rc8-mm2
From: Greg KH <[EMAIL PROTECTED]> Date: Sat, Sep 29, 2007 at 08:19:42AM -0700 > On Sat, Sep 29, 2007 at 05:37:29PM +0800, Dave Young wrote: > > Hi, > > The kernel report warnings about sysfs filename duplicate under > > rc8-mm1 and rc8-mm2. > > 1. > > cut > > sysfs: duplicate filename 'usbcore' can not be created > > WARNING: at fs/sysfs/dir.c:433 sysfs_add_one() > > [] dump_trace+0x1bf/0x1d0 > > [] show_trace_log_lvl+0x18/0x30 > > [] show_trace+0xf/0x20 I get some identical warnings from iftab in userspace: eth1 renamed to switch sysfs: duplicate filename 'switch' can not be created WARNING: at fs/sysfs/dir.c:433 sysfs_add_one() Call Trace: [] sysfs_add_one+0xac/0xe0 [] sysfs_create_link+0xac/0x140 [] device_rename+0x1c2/0x220 [] dev_change_name+0xbc/0x250 [] dev_ifsioc+0x338/0x3a0 [] dev_ioctl+0x36d/0x3c0 [] handle_mm_fault+0x1a5/0x6f0 [] sock_ioctl+0x7d/0x250 [] do_ioctl+0x31/0x90 [] vfs_ioctl+0x21b/0x2d0 [] sys_ioctl+0x4a/0x80 [] system_call+0x7e/0x83 net switch: device_rename: sysfs_create_symlink failed (-17) eth2 renamed to adsl sysfs: duplicate filename 'adsl' can not be created WARNING: at fs/sysfs/dir.c:433 sysfs_add_one() Call Trace: [] sysfs_add_one+0xac/0xe0 [] sysfs_create_link+0xac/0x140 [] device_rename+0x1c2/0x220 [] dev_change_name+0xbc/0x250 [] dev_ifsioc+0x338/0x3a0 [] dev_ioctl+0x36d/0x3c0 [] handle_mm_fault+0x1a5/0x6f0 [] sock_ioctl+0x7d/0x250 [] do_ioctl+0x31/0x90 [] vfs_ioctl+0x21b/0x2d0 [] sys_ioctl+0x4a/0x80 [] system_call+0x7e/0x83 net adsl: device_rename: sysfs_create_symlink failed (-17) switch: no link during initialization. ip_tables: (C) 2000-2006 Netfilter Core Team this happens when iftab renames my network interfaces. Booting 2.6.21-rc1-mm2 said: eth1 renamed to switch eth2 renamed to adsl ip_tables: (C) 2000-2006 Netfilter Core Team 2.6.23-rc4-mm1 said: eth1 renamed to switch net switch: device_rename: sysfs_create_symlink failed (-17) eth2 renamed to adsl net adsl: device_rename: sysfs_create_symlink failed (-17) ip_tables: (C) 2000-2006 Netfilter Core Team .config attached below. Kind regards, Jurriaan # # Automatically generated make config: don't edit # Linux kernel version: 2.6.23-rc8-mm2 # Sat Sep 29 07:37:07 2007 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_NONIRQ_WAKEUP=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_ZONE_DMA32=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_DMI=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=18 # CONFIG_CGROUPS is not set CONFIG_FAIR_GROUP_SCHED=y CONFIG_FAIR_USER_SCHED=y CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_PROC_PAGE_MONITOR=y CONFIG_PROC_KPAGEMAP=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_BLK_DEV_BSG is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="anticipatory" # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_X86_PC=y # CONFIG_X86_VSMP is not set CONFIG_MK8=y # CONFIG_MPSC is not set # CONFIG_MCORE2 is not
Re: 2.6.23-rc8-mm2 - PowerPC link failure at arch/powerpc/kernel/head_64.o
Hi Andrew, The compilation with the cross compiler for the PowerPC-405 on the powerbox fails at linking LD init/built-in.o LD .tmp_vmlinux1 ld: arch/powerpc/kernel/head_64.o(.text+0x80c8): sibling call optimization to `.text.init.refok' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `.text.init.refok' extern ld: arch/powerpc/kernel/head_64.o(.text+0x8160): sibling call optimization to `.text.init.refok' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `.text.init.refok' extern ld: arch/powerpc/kernel/head_64.o(.text+0x81c4): sibling call optimization to `.text.init.refok' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `.text.init.refok' extern ld: final link failed: Bad value make: *** [.tmp_vmlinux1] Error 1 -- 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] 0/3 coding standards documentation/code updates
In message <[EMAIL PROTECTED]>, Linus Torvalds writes:
>
>
> On Sat, 29 Sep 2007, Erez Zadok wrote:
> >
> > Would you prefer if CodingStyle was reorganized or even split into (1)
> > general principles and (2) details? Perhaps we need a CodingStylePrinciples
> > and a CodingStyleDetails?
>
> I'm certainly ok with the split into two files.
>
> What I'm not ok with is really important stuff (indentation), and then
> mixing in silly rules ("parenthesis are bad in printk's"?)
>
> Linus
OK, looking at CodingStyle, I see two kinds of chapters. The first is stuff
that's more generic to C, and the other is more specific to Linux and how
one codes in the linux kernel. So I propose the following:
1. we create a new file called CodingSuggestions
2. we keep in CodingStyle the following chapters
Chapter 1: Indentation
Chapter 2: Breaking long lines and strings
Chapter 3: Placing Braces and Spaces
Chapter 4: Naming
Chapter 5: Typedefs
Chapter 6: Functions
Chapter 7: Centralized exiting of functions
Chapter 8: Commenting
Chapter 9: You've made a mess of it
Note: I'd suggest we rename the title of ch9 to "Custom Editor
Programming/Indentation Modes" or something more descriptive.
Chapter 10: Kconfig configuration files
Chapter 11: Data structures
Chapter 12: Macros, Enums and RTL
Chapter 15: The inline disease
Chapter 16: Function return values and names
Chapter 18: Editor modelines and other cruft
3. move the following chapters to CodingSuggestions:
Chapter 13: Printing kernel messages
Note: ch13 is the one which mentions the don't put parentheses around %d.
Chapter 14: Allocating memory
Chapter 17: Don't re-invent the kernel macros
Chapter 19: branch prediction optimizations (the un/likely debacle)
4. We go through checkpatch.pl and ensure that every test in checkpatch is
documented either in CodingStyle or in CodingSuggestions, determined by
whether checkpatch considers it an ERROR, WARNING, or just CHECK.
I think the above chapter split will be a reasonable start, and of course we
can tweak things over time. The general idea is that CodingStyle will
remain largely unchanged (until such day as the kernel is rewritten in Java
:-), while CodingSuggestions will evolve over time and be kept in sync with
checkpatch.
But, there's something really nice abuot having to point people to just one
file instead of two. We could also keep it all in one file, but split it
into two parts:
Part 1: Mandatory Coding Style
Chapter 1: indentation
...
Part 2: Coding Style Suggestions
Chapter n: printing kernel messages
...
Erez.
-
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] 0/3 coding standards documentation/code updates
On Sun, 30 Sep 2007 04:27:24 BST, Al Viro said: > ... and no matter how many rules you put down, it's still possible to > write a code that will be awful stylistically while adhering to all of > them. Religiously. I've run into those sort of programmers. Unfortunately, there's no real cure for them short of a baseball/cricket bat or similar implement. pgpC71d7KAGTn.pgp Description: PGP signature
Re: [PATCH] 0/3 coding standards documentation/code updates
On Sat, 29 Sep 2007, [EMAIL PROTECTED] wrote: > > I kind of meant the *maintainers* couldn't whine about things not in > CodingStyle ;) No, I understood you. I'm personally of the opinion that the automated style checking, and having detailed rules is always a mistake. It's *much* better to teach people the big things. And the small things will vary from person to person _anyway_, so it's not like you can really document them. Linus - 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] 0/3 coding standards documentation/code updates
On Sat, 29 Sep 2007 20:00:01 PDT, Linus Torvalds said: > On Sat, 29 Sep 2007, [EMAIL PROTECTED] wrote: > > I think there needs to be a "sense of fairness" attached here - CodingStyle > > should cover all the stuff maintainers/reviewers are allowed to whinge > > about. > > No. > > People whine too much as is. Don't give them *license* to do so. I kind of meant the *maintainers* couldn't whine about things not in CodingStyle ;) pgpiMnd0i9uPO.pgp Description: PGP signature
Re: [PATCH] 0/3 coding standards documentation/code updates
In message <[EMAIL PROTECTED]>, Theodore Tso writes: > On Sat, Sep 29, 2007 at 03:56:38PM -0400, J. Bruce Fields wrote: > > It'd be a start just to revert CodingStyle to its original content and > > move the rest to CodingStyleReference. But someone would want to skim > > through the CodingStyle history for any legimate corrections that we > > want to keep. > > How about CodingStyleSuggestions? And let's make it clear they are > suggestions, and not things that checkpatch should be flaming about > unless people request the all of the annoying associated false > positives via --spam-me-harder. :-) FWIW, the checkpatch script is woefully out of sync with CodingStyle. I assume that checkpatch.pl is generally more authoritative (sans "(%d)" :-) > - Ted Erez. - 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] 0/3 coding standards documentation/code updates
On Sat, Sep 29, 2007 at 10:24:01PM -0400, [EMAIL PROTECTED] wrote: > On Sat, 29 Sep 2007 11:18:05 PDT, Linus Torvalds said: > > > "CodingStyle" should be about the big issues, not about details. Yes, > > we've messed that up over the years, but let's not continue that. > > > > In other words, I'd suggest *removing* lines from CodingStyle, not adding > > them. The file has already gone from a "good general principles" to "lots > > of stupid details". Let's not make it worse. > > I think there needs to be a "sense of fairness" attached here - CodingStyle > should cover all the stuff maintainers/reviewers are allowed to whinge about. > Otherwise, we get maintainers whinging about undocumented style rules, and > we get code submitters who are unhappy because they have no real way to tell > if their code really *is* stylistically lacking, or if they just have a > jerk maintainer who wants to keep their code out-of-tree for political > reasons. ... and no matter how many rules you put down, it's still possible to write a code that will be awful stylistically while adhering to all of them. Religiously. IOW, it's not going to eliminate that kind of fights. - 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] Add Documentation/{w1,w1/masters}/00-INDEX
From: Rob Landley <[EMAIL PROTECTED]> Two 00-INDEX files under Documentation/w1 Signed-off-by: Rob Landley <[EMAIL PROTECTED]> --- Documentation/w1/00-INDEX |8 Documentation/w1/masters/00-INDEX |6 ++ 2 files changed, 14 insertions(+) --- /dev/null 2007-04-23 10:59:00.0 -0500 +++ kdocs/Documentation/w1/00-INDEX 2007-09-29 13:24:40.0 -0500 @@ -0,0 +1,8 @@ +00-INDEX + - This file +masters/ + - Individual chips providing 1-wire busses. +w1.generic + - The 1-wire (w1) bus +w1.netlink + - Userspace communication protocol over connector [1]. --- /dev/null 2007-04-23 10:59:00.0 -0500 +++ kdocs/Documentation/w1/masters/00-INDEX 2007-09-29 13:23:28.0 -0500 @@ -0,0 +1,6 @@ +00-INDEX + - This file +ds2482 + - The Maixm/Dallas Semiconductor DS2482 provides 1-wire busses. +ds2490 + - The Maixm/Dallas Semiconductor DS2490 builds USB <-> W1 bridges. -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. - 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] Add missing entries to top level Documentation/00-INDEX
From: Rob Landley <[EMAIL PROTECTED]> Add missing entries to Documentation/00-INDEX Signed-off-by: Rob Landley <[EMAIL PROTECTED]> --- Documentation/00-INDEX | 17 - 1 file changed, 16 insertions(+), 1 deletion(-) diff -r dc28e4e17791 Documentation/00-INDEX --- a/Documentation/00-INDEXWed Sep 26 15:52:17 2007 -0700 +++ b/Documentation/00-INDEXSat Sep 29 14:07:39 2007 -0500 @@ -22,6 +21,8 @@ CodingStyle - how the boss likes the C code in the kernel to look. DMA-API.txt - DMA API, pci_ API & extensions for non-consistent memory machines. +DMA-ISA-LPC.txt + - How to do DMA with ISA (and LPC) devices. DMA-mapping.txt - info for PCI drivers using DMA portably across all platforms. DocBook/ @@ -50,6 +51,8 @@ README.cycladesZ - info on Cyclades-Z firmware loading. SAK.txt - info on Secure Attention Keys. +SM501.txt + - Silicon Motion SM501 multimedia companion chip SecurityBugs - procedure for reporting security bugs found in the kernel. SubmitChecklist @@ -248,6 +251,8 @@ md.txt - info on boot arguments for the multiple devices driver. memory-barriers.txt - info on Linux kernel memory barriers. +memory-hotplug.txt + - Hotpluggable memory support, how to use and current status. memory.txt - info on typical Linux memory problems. mips/ @@ -298,6 +303,8 @@ pm.txt - info on Linux power management support. pnp.txt - Linux Plug and Play documentation. +power_supply_class.txt + - Tells userspace about battery, UPS, AC or DC power supply properties power/ - directory with info on Linux PCI power management. powerpc/ @@ -334,8 +341,12 @@ sched-coding.txt - reference for various scheduler-related methods in the O(1) scheduler. sched-design.txt - goals, design and implementation of the Linux O(1) scheduler. +sched-design-CFS.txt + - goals, design and implementation of the Complete Fair Scheduler. sched-domains.txt - information on scheduling domains. +sched-nice-design.txt + - How and why the scheduler's nice levels are implemented. sched-stats.txt - information on schedstats (Linux Scheduler Statistics). scsi/ @@ -380,6 +391,8 @@ stallion.txt - info on using the Stallion multiport serial driver. svga.txt - short guide on selecting video modes at boot via VGA BIOS. +sysfs-rules.txt + - How not to use sysfs. sx.txt - info on the Specialix SX/SI multiport serial driver. sysctl/ @@ -410,6 +423,8 @@ video4linux/ - directory with info regarding video/TV/radio cards and linux. vm/ - directory with info on the Linux vm code. +volatile-considered-harmful.txt + - Why the "volatile" type class should not be used voyager.txt - guide to running Linux on the Voyager architecture. w1/ -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rfc][patch] i386: remove comment about barriers
On Sat, Sep 29, 2007 at 03:28:48PM +0200, Nick Piggin wrote:
> Hi,
>
> OK this was going to be a quick patch, but after sleeping on it, I think
> it deserves a better analysis... I can prove the comment is incorrect with a
> test program, but I'm not as sure about my thinking that leads me to call it
> also misleading.
>
> The comment being removed by this patch is incorrect and misleading (I
> think).
>
> 1. load ...
> 2. store 1 -> X
> 3. wmb
> 4. rmb
> 5. load a <- Y
> 6. store ...
>
> 4 will only ensure ordering of 1 with 5.
> 3 will only ensure ordering of 2 with 6.
>
> Further, a CPU with strictly in-order stores will still only provide that
> 2 and 6 are ordered (effectively, it is the same as a weakly ordered CPU
> with wmb after every store).
>
> In all cases, 5 may still be executed before 2 is visible to other CPUs!
Yes, even on x86.
> The additional piece of the puzzle that mb() provides is the store/load
> ordering, which fundamentally cannot be achieved with any combination of
> rmb()s
> and wmb()s.
True.
> This can be an unexpected result if one expected any sort of global ordering
> guarantee to barriers (eg. that the barriers themselves are sequentially
> consistent with other types of barriers). However sfence or lfence barriers
> need only provide an ordering partial ordering of meomry operations --
> Consider
> that wmb may be implemented as nothing more than inserting a special barrier
> entry in the store queue, or, in the case of x86, it can be a noop as the
> store
> queue is in order. And an rmb may be implemented as a directive to prevent
> subsequent loads only so long as their are no previous outstanding loads
> (while
> there could be stores still in store queues).
>
> I can actually see the occasional load/store being reordered around lfence on
> my core2. That doesn't prove my above assertions, but it does show the comment
> is wrong (unless my program is -- can send it out by request).
>
> So:
> mb() and smp_mb() always have and always will require a full mfence or lock
> prefixed instruction on x86. And we should remove this comment.
Yes, because x86 allows loads to be executed before earlier stores,
so load-store ordering must be explicitly enforced.
> [ This is true for x86's sfence/lfence, but raises a question about Linux's
> memory barriers. Does anybody expect that a sequence of smp_wmb and smp_rmb
> would ever provide a full smp_mb barrier? I've always assumed no, but I
> don't know if it is actually documented? ]
Anyone that does expect this needs to adjust their expectations. ;-)
Acked-by: Paul E. McKenney <[EMAIL PROTECTED]>
> Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
>
> ---
> Index: linux-2.6/include/asm-i386/system.h
> ===
> --- linux-2.6.orig/include/asm-i386/system.h
> +++ linux-2.6/include/asm-i386/system.h
> @@ -214,11 +214,6 @@ static inline unsigned long get_limit(un
> */
>
>
> -/*
> - * Actually only lfence would be needed for mb() because all stores done
> - * by the kernel should be already ordered. But keep a full barrier for now.
> - */
> -
> #define mb() alternative("lock; addl $0,0(%%esp)", "mfence",
> X86_FEATURE_XMM2)
> #define rmb() alternative("lock; addl $0,0(%%esp)", "lfence",
> X86_FEATURE_XMM2)
>
-
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] Tweak Documentation/SM501.txt
From: Rob Landley <[EMAIL PROTECTED]> The existing Documentation/SM501.txt gives no clue what the chip is or does, so copy the description from Kconfig help text. cc: Ben Dooks <[EMAIL PROTECTED]> Signed-off-by: Rob Landley <[EMAIL PROTECTED]> --- Documentation/SM501.txt |5 + 1 file changed, 5 insertions(+) diff -r dc28e4e17791 Documentation/SM501.txt --- a/Documentation/SM501.txt Wed Sep 26 15:52:17 2007 -0700 +++ b/Documentation/SM501.txt Sat Sep 29 14:01:43 2007 -0500 @@ -2,6 +2,11 @@ Copyright 2006, 2007 Simtec Electronics + +The Silicon Motion SM501 multimedia companion chip is a multifunction device +which may provide numerous interfaces including USB host controller USB gadget, +Asyncronous Serial ports, Audio functions and a dual display video interface. +The device may be connected by PCI or local bus with varying functions enabled. Core -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. - 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 RFC 6/9] RCU priority boosting for preemptible RCU
On Fri, Sep 28, 2007 at 07:05:14PM -0400, Steven Rostedt wrote: > > > -- > On Fri, 28 Sep 2007, Gautham R Shenoy wrote: > > > > > > > +#ifdef CONFIG_PREEMPT_RCU_BOOST > > > +/* > > > + * Task state with respect to being RCU-boosted. This state is changed > > > + * by the task itself in response to the following three events: > > ^^^ > > > + * 1. Preemption (or block on lock) while in RCU read-side critical > > > section. > > > > I am wondering, can a task block on a lock while in RCU read-side > > critical section? > > I think this may be specific to the -rt patch. In the -rt patch, > spin_locks turn into mutexes, and therefor can block a read-side critical > section. Yep! I do need to fix the comment. > > > + * 2. Outermost rcu_read_unlock() for blocked RCU read-side critical > > > section. > > > + * > > > > Event #3. is missing? > > I guess Paul needs to answer that one ;-) An older version had three, the new one has two, and I forgot to s/three/two/. Thanx, Paul - 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] Extending kbuild syntax
On Sat, Sep 29, 2007 at 10:11:45PM +0200, Sam Ravnborg wrote:
>...
> The second is the more controversial suggestion.
> In several Makefile we have simple if expression of the variants:
> if ($(CONFIG_FOO),y)
> obj-$(CONFIG_BAR) += fubar.o
> endif
>
> The pattern varies over this theme.
> The suggestion here is to introduce a few helpers:
>
> obj-y-if-$(CONFIG_FOO) += fubar.o
> This one shall read:
> if $(CONFIG_FOO) is y or m then set += to obj-y
IMHO for people who are not kbuild junkies the pattern is more clear
with the current syntax.
But you should better ask some guinea pigs who have not already seen as
many kernel Makefiles as I have...
> In several cases we will need it to be more complicated like the this:
> obj-y-ify-$(CONFIG_FOO) += fubar.o
> This one shall read:
> if $(CONFIG_FOO) is y (thats the ify thing) then += to obj-y
>
> And we can mix it like the following:
> obj-$(CONFIG_BAR)-ify-$(CONFIG_FOO) += fubar.o
> This one shall read:
> if $(CONFIG_FOO) equal y then += to obj-$(CONFIG_BAR)
>
>
> The full list of new variables are (for obj-y):
> obj-y-if-y
> obj-y-if-m
>
> obj-y-ify-y
> obj-y-ifm-m
>
> obj-y-ifn-
>
> And similar for obj-m:
> obj-m-if-y
> obj-m-if-m
>
> obj-m-ify-y
> obj-m-ifm-m
>
> obj-m-ifn-
>
> The 'y' and 'm' can be replaced by $(CONFIG_FOO) but the one right
> to the if are not supposed to be replaced.
>
>
> To better express how to use it I have tried to update a few Makefiles
> to use the new syntax. See below.
>
> On MAJOR drawback is the linking order.
> I have no way to keep the link order if the new syntax are sued. The
> .o files will either be put before .o files specified with obj-y or obj-m or
> after the same.
>
> For some places this does not matter but for other places (fs/Makefile)
> I will expect it to matter a lot.
>
> Comments?
> Is this just to magic for bare humans to grasp.
> Or mabe the linking order is so important that we do not want it?
>...
Some of the cases have the following pattern:
config X86_POWERNOW_K8_ACPI
bool
depends on X86_POWERNOW_K8 && ACPI_PROCESSOR
depends on !(X86_POWERNOW_K8 = y && ACPI_PROCESSOR = m)
default y
Your suggested syntax has to be enhanced with three additional
variables for handling such cases.
The complicated cases can be handled either in kconfig or in kbuild,
and I think kconfig is the better place for them:
Handling it in kconfig has the advantage that we also get a variable we
can use in C code.
For all the *-if-m and *-m-if{,n}-* cases this is a huge advantage over
having to express the whole dependency in each #if.
Compare
#if defined(CONFIG_ACPI_PROCESSOR) || (defined(CONFIG_ACPI_PROCESSOR_MODULE
&& defined(MODULE))
with
#ifdef CONFIG_X86_POWERNOW_K8_ACPI
> Sam
>...
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] 0/3 coding standards documentation/code updates
On Sat, 29 Sep 2007, [EMAIL PROTECTED] wrote: > > I think there needs to be a "sense of fairness" attached here - CodingStyle > should cover all the stuff maintainers/reviewers are allowed to whinge about. No. People whine too much as is. Don't give them *license* to do so. Linus - 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.23-rc8-mm2
On Thu, 27 Sep 2007 02:22:20 PDT, Andrew Morton said: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc8/2.6.23-rc8-mm2/ Locks up hard at very early boot on my Dell Latitude - grub says loading kernel, the screen clears, and we lock up before we get penguins. -rc8-mm1 was OK. I'm off to go bisect, figured I'd drop a heads-up. pgpHvQvpzYjP1.pgp Description: PGP signature
Re: [PATCH] 0/3 coding standards documentation/code updates
On Sat, 29 Sep 2007 11:18:05 PDT, Linus Torvalds said: > "CodingStyle" should be about the big issues, not about details. Yes, > we've messed that up over the years, but let's not continue that. > > In other words, I'd suggest *removing* lines from CodingStyle, not adding > them. The file has already gone from a "good general principles" to "lots > of stupid details". Let's not make it worse. I think there needs to be a "sense of fairness" attached here - CodingStyle should cover all the stuff maintainers/reviewers are allowed to whinge about. Otherwise, we get maintainers whinging about undocumented style rules, and we get code submitters who are unhappy because they have no real way to tell if their code really *is* stylistically lacking, or if they just have a jerk maintainer who wants to keep their code out-of-tree for political reasons. pgpnY4Om4XIrN.pgp Description: PGP signature
Re: [PATCH] CodingStyle: Printing numbers in parentheses is fine
On Sat, 29 Sep 2007 03:51:56 PDT, Andrew Morton said: > Printing something like > > bytes remaining: 0x12 (18) > > is a quite logical thing to do, although pretty darm pointless. On the other hand, printing this: magic number: 0x2710 probably doesn't ring any bells, but if you changed that format to be "magic number: %x (%d)",foo,foo you'll almost certainly sit up and ask "Where the fsck did *that* come from?" (unless you're a *lot* better at doing hex conversions in your head than I). Yeah, *usually* pointless, but it has its place sometimes pgpAcOhi5ovzR.pgp Description: PGP signature
Re: [PATCH] 0/3 coding standards documentation/code updates
On Sat, Sep 29, 2007 at 03:56:38PM -0400, J. Bruce Fields wrote: > It'd be a start just to revert CodingStyle to its original content and > move the rest to CodingStyleReference. But someone would want to skim > through the CodingStyle history for any legimate corrections that we > want to keep. How about CodingStyleSuggestions? And let's make it clear they are suggestions, and not things that checkpatch should be flaming about unless people request the all of the annoying associated false positives via --spam-me-harder. :-) - 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/
bluetooth: hci_sysfs work queue problem
Hi, The hci_sysfs uses work queue to finish the sysfs add/del fuction. But when the same device connection failed, if another connection of same device come in before the delete work finish, sysfs will warn about duplicate filename creating. Sep 19 12:30:27 darkstar kernel: sysfs: duplicate filename 'acl00194FDB6C71' can not be created Sep 19 12:30:27 darkstar kernel: WARNING: at fs/sysfs/dir.c:433 sysfs_add_one() Sep 19 12:30:27 darkstar kernel: [] sysfs_add_one+0xa0/0xe0 Sep 19 12:30:27 darkstar kernel: [] create_dir+0x48/0xb0 Sep 19 12:30:27 darkstar kernel: [] __slab_alloc+0x205/0x250 Sep 19 12:30:27 darkstar kernel: [] sysfs_create_dir+0x29/0x50 Sep 19 12:30:27 darkstar kernel: [] create_dir+0x1b/0x50 Sep 19 12:30:27 darkstar kernel: [] kobject_add+0x46/0x150 Sep 19 12:30:27 darkstar kernel: [] kobject_set_name+0x84/0xf0 Sep 19 12:30:27 darkstar kernel: [] device_add+0x95/0x350 Sep 19 12:30:27 darkstar kernel: [] add_conn+0x0/0x90 [bluetooth] Sep 19 12:30:27 darkstar kernel: [] add_conn+0xf/0x90 [bluetooth] Sep 19 12:30:27 darkstar kernel: [] vmstat_update+0x0/0x30 Sep 19 12:30:27 darkstar kernel: [] run_workqueue+0x5e/0x110 Sep 19 12:30:27 darkstar kernel: [] worker_thread+0xac/0x100 Sep 19 12:30:27 darkstar kernel: [] autoremove_wake_function+0x0/0x50 Sep 19 12:30:27 darkstar kernel: [] autoremove_wake_function+0x0/0x50 Sep 19 12:30:27 darkstar kernel: [] worker_thread+0x0/0x100 Sep 19 12:30:27 darkstar kernel: [] kthread+0x59/0xa0 Sep 19 12:30:27 darkstar kernel: [] kthread+0x0/0xa0 Sep 19 12:30:27 darkstar kernel: [] kernel_thread_helper+0x7/0x14 Sep 19 12:30:27 darkstar kernel: === Sep 19 12:30:27 darkstar kernel: kobject_add failed for acl00194FDB6C71 with -EEXIST, don't try to register things with the same name in the same directory. Sep 19 12:30:27 darkstar kernel: [] kobject_add+0xf6/0x150 Sep 19 12:30:27 darkstar kernel: [] device_add+0x95/0x350 Sep 19 12:30:27 darkstar kernel: [] add_conn+0x0/0x90 [bluetooth] Sep 19 12:30:27 darkstar kernel: [] add_conn+0xf/0x90 [bluetooth] Sep 19 12:30:27 darkstar kernel: [] vmstat_update+0x0/0x30 Sep 19 12:30:27 darkstar kernel: [] run_workqueue+0x5e/0x110 Sep 19 12:30:27 darkstar kernel: [] worker_thread+0xac/0x100 Sep 19 12:30:27 darkstar kernel: [] autoremove_wake_function+0x0/0x50 Sep 19 12:30:27 darkstar kernel: [] autoremove_wake_function+0x0/0x50 Sep 19 12:30:27 darkstar kernel: [] worker_thread+0x0/0x100 Sep 19 12:30:27 darkstar kernel: [] kthread+0x59/0xa0 Sep 19 12:30:27 darkstar kernel: [] kthread+0x0/0xa0 Sep 19 12:30:27 darkstar kernel: [] kernel_thread_helper+0x7/0x14 Sep 19 12:30:27 darkstar kernel: === Sep 19 12:30:27 darkstar kernel: add_conn: Failed to register connection device Sep 19 12:41:36 darkstar kernel: [] kernel_thread_helper+0x7/0x14 Marcel, how to resolve this problem? do you have some ideas? Regards 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: [patch] x86: improved memory barrier implementation
On Fri, Sep 28, 2007 at 05:07:19PM +0100, Alan Cox wrote: > > Winchip: can any of these CPUs with ooostores do SMP? If not, then smp_wmb > > can also be a simple barrier on i386 too. > > The IDT Winchip can do SMP apparently. >From the Winchip3 (which was the final winchip) specs.. "The IDT WinChip 3 processor also omits the software interface to the Intel-proprietary symmetric multiprocessing support: APIC. This bus function is omitted since the target market for the IDT WinChip 3 processor is typical desktop systems (which do not support APIC multiprocessing)." It didn't offer any alternative DIY-SMP either (or at least none that's documented). Centaur only became SMP capable with some of the C3 Nehemiah's a year or two back. Dave -- http://www.codemonkey.org.uk - 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/5] Linux Kernel Markers
On Fri, 2007-09-28 at 10:28 -0400, Mathieu Desnoyers wrote: > +struct __mark_marker; Hi Mathieu, How about, "struct marker". You've taken the "marker*" namespace, so all these underscores are __gratuitious__ :) > +/* > + * module_mutex nests inside markers_mutex. Markers mutex protects the > builtin > + * and module markers, the hash table and deferred_sync. > + */ > +DEFINE_MUTEX(markers_mutex); This can be static AFAICT. The rest looks fine. Cheers, Rusty. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm2
>On 9/29/07, Greg KH <[EMAIL PROTECTED]> wrote: > On Sat, Sep 29, 2007 at 05:37:29PM +0800, Dave Young wrote: > > Hi, > > The kernel report warnings about sysfs filename duplicate under > > rc8-mm1 and rc8-mm2. > > 1. > > cut > > NET: Registered protocol family 16 > > ACPI: bus type pci registered > > PCI: PCI BIOS revision 2.10 entry at 0xfb93e, last bus=3 > > PCI: Using configuration type 1 > > Setting up standard PCI resources > > sysfs: duplicate filename 'usbcore' can not be created > > WARNING: at fs/sysfs/dir.c:433 sysfs_add_one() > > [] dump_trace+0x1bf/0x1d0 > > [] show_trace_log_lvl+0x18/0x30 > > [] show_trace+0xf/0x20 > > [] dump_stack+0x12/0x20 > > [] sysfs_add_one+0xa0/0xe0 > > [] create_dir+0x48/0xb0 > > [] sysfs_create_dir+0x29/0x50 > > [] create_dir+0x1b/0x50 > > [] kobject_add+0x46/0x150 > > [] kernel_param_sysfs_setup+0x50/0xb0 > > [] param_sysfs_builtin+0xee/0x130 > > [] param_sysfs_init+0x24/0x60 > > [] do_initcalls+0x46/0x1e0 > > [] kernel_init+0x62/0xb0 > > [] kernel_thread_helper+0x7/0x14 > > === > > kobject_add failed for usbcore with -EEXIST, don't try to register > > things with the same name in the same directory. > > That is very wierd, do you have both USB built in and as a module > somehow? I dont think so, below is my .config file: (It works under rc8 tree) # # Automatically generated make config: don't edit # Linux kernel version: 2.6.23-rc8-mm2 # Sat Sep 29 16:55:51 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=16 # CONFIG_CGROUPS is not set CONFIG_FAIR_GROUP_SCHED=y CONFIG_FAIR_USER_SCHED=y CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_PROC_PAGE_MONITOR=y CONFIG_PROC_KPAGEMAP=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y CONFIG_LBD=y # CONFIG_BLK_DEV_IO_TRACE is not set CONFIG_LSF=y CONFIG_BLK_DEV_BSG=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="anticipatory" CONFIG_PREEMPT_NOTIFIERS=y # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_SMP=y CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y # CONFIG_PARAVIRT is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set CONFIG_MPENTIUM4=y # CONFIG_MCORE2 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set CONFIG_X86_GENERIC=y CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=7
[ANNOUNCE] GIT 1.5.3.3
The latest maintenance release GIT 1.5.3.3 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.5.3.3.tar.{gz,bz2} (tarball)
git-htmldocs-1.5.3.3.tar.{gz,bz2} (preformatted docs)
git-manpages-1.5.3.3.tar.{gz,bz2} (preformatted docs)
RPMS/$arch/git-*-1.5.3.3-1.$arch.rpm (RPM)
GIT v1.5.3.3 Release Notes
==
Fixes since v1.5.3.2
* git-quiltimport did not like it when a patch described in the
series file does not exist.
* p4 importer missed executable bit in some cases.
* The default shell on some FreeBSD did not execute the
argument parsing code correctly and made git unusable.
* git-svn incorrectly spawned pager even when the user user
explicitly asked not to.
* sample post-receive hook overquoted the envelope sender
value.
* git-am got confused when the patch contained a change that is
only about type and not contents.
* git-mergetool did not show our and their version of the
conflicted file when started from a subdirectory of the
project.
* git-mergetool did not pass correct options when invoking diff3.
* git-log sometimes invoked underlying "diff" machinery
unnecessarily.
Changes since v1.5.3.2 are as follows:
Carlos Rica (1):
Move make_cache_entry() from merge-recursive.c into read-cache.c
Dan Nicholson (1):
quiltimport: Skip non-existent patches
David Brown (1):
Detect exec bit in more cases.
David Kastrup (1):
Supplant the "while case ... break ;; esac" idiom
Eric Wong (1):
git-svn: don't attempt to spawn pager if we don't want one
Glenn Rempe (1):
Fixed minor typo in t/t9001-send-email.sh test command line.
J. Bruce Fields (1):
user-manual: don't assume refs are stored under .git/refs
Jakub Narebski (2):
gitweb: Remove parse_from_to_diffinfo code from git_patchset_body
gitweb: No difftree output for trivial merge
Jim Meyering (2):
unexpected Make output (e.g. from --debug) causes build failure
Do not over-quote the -f envelopesender value.
Johannes Schindelin (1):
apply: get rid of --index-info in favor of --build-fake-ancestor
Johannes Sixt (2):
gitattributes.txt: Remove a duplicated paragraph about 'ident' and 'crlf'
interaction.
gitattributes.txt: Be more to the point in the filter driver description.
Junio C Hamano (3):
Documentation/git-lost-found.txt: drop unnecessarily duplicated name.
Mergetool generating blank files (1.5.3)
GIT 1.5.3.3
Linus Torvalds (1):
Fix revision log diff setup, avoid unnecessary diff generation
Matt Kraai (2):
Move the paragraph specifying where the .idx and .pack files should be
Conjugate "search" correctly in the git-prune-packed man page.
Michael Smith (1):
user-manual: Explain what submodules are good for.
Miklos Vajna (2):
User Manual: add a chapter for submodules
git-bundle: fix commandline examples in the manpage
Randy Dunlap (1):
core-tutorial: correct URL
Shawn Bohrer (1):
Fix spelling of overridden in documentation
Theodore Ts'o (2):
mergetool: fix emerge when running in a subdirectory
mergetool: Fix typo in options passed to kdiff3
-
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: getting FUSD compiled with current kernels
On 9/29/07, Florian Schmidt <[EMAIL PROTECTED]> wrote: > My goal is to hack up oss2jack [3] to use ALSA pcm devices.. And a later goal > is to create a virtual ALSA soundcard [which would multiplex access to a real > non hw-mixing capable soundcard] to finally end the dmix software mixing woes > linux users have to endure for the last years :) What problems with ALSA's userspace mixing are you trying to solve? Lee - 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] make unicode default
On Sat, 2007-09-29 at 10:36 +0200, Jan Engelhardt wrote: > Make the vt return to the system default when it is reset. > Also make UTF-8 the system default. It's about time we do, so this is fine with me. Tony - 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] 0/3 coding standards documentation/code updates
On Sat, 29 Sep 2007, Erez Zadok wrote:
>
> Would you prefer if CodingStyle was reorganized or even split into (1)
> general principles and (2) details? Perhaps we need a CodingStylePrinciples
> and a CodingStyleDetails?
I'm certainly ok with the split into two files.
What I'm not ok with is really important stuff (indentation), and then
mixing in silly rules ("parenthesis are bad in printk's"?)
Linus
-
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: F_DUPFD_CLOEXEC implementation
Hi Ulrich, On Friday 28 September 2007 18:34, Ulrich Drepper wrote: > One more small change to extend the availability of creation of > file descriptors with FD_CLOEXEC set. Adding a new command to > fcntl() requires no new system call and the overall impact on > code size if minimal. Tangential question: do you have any idea how userspace can safely do nonblocking read or write on a potentially-shared fd? IIUC, currently it cannot be done without races: old_flags = fcntl(fd, F_GETFL); ...other process may change flags!... fcntl(fd, F_SETFL, old_flags | O_NONBLOCK); read(fd, ...) ...other process may see flags changed under its feet!... fcntl(fd, F_SETFL, old_flags); Can this be fixed? -- vda - 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] 0/3 coding standards documentation/code updates
In message <[EMAIL PROTECTED]>, Linus Torvalds writes: > > > On Fri, 28 Sep 2007, Erez Zadok wrote: > > > > Documentation/CodingStyle | 88 > > +- > > I'm not very happy with this. > > "CodingStyle" should be about the big issues, not about details. Yes, > we've messed that up over the years, but let's not continue that. > > In other words, I'd suggest *removing* lines from CodingStyle, not adding > them. The file has already gone from a "good general principles" to "lots > of stupid details". Let's not make it worse. > > Linus There's a lot of good value in having all those details, as it helps people standardize on more common practices, including details. I think removing all those details may only increase the amount-of less-accepted code to be posted, resulting in more lkml people having to repeat themselves on what not to do. Only now, they won't be able to point people to the CodingStyle file for what they should do right. Would you prefer if CodingStyle was reorganized or even split into (1) general principles and (2) details? Perhaps we need a CodingStylePrinciples and a CodingStyleDetails? IOW, where should that very useful info live? Erez. - 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] CodingStyle: Printing numbers in parentheses is fine
David Brownell <[EMAIL PROTECTED]> writes: >> > > Let's kill it, please. (i.e., ACK) >> > >> > But ... why? What value could needless parens provide? >> >> Who says that needless parens could provide value? > > Jean, which is why he submitted the patch. > You, implicitly, by acking a patch saying those parens are bad. > But not me ... I don't think this patch is merge-worthy. Would also add rules like "don't put parens around the word device" etc? There are countless silly things one could do, and we can't explicitly prohibit all of them. -- Måns Rullgård [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] CodingStyle: Printing numbers in parentheses is fine
On Sat, 29 Sep 2007 15:30:15 -0700 David Brownell wrote: > > > > Let's kill it, please. (i.e., ACK) > > > > > > But ... why? What value could needless parens provide? > > > > Who says that needless parens could provide value? > > Jean, which is why he submitted the patch. > You, implicitly, by acking a patch saying those parens are bad. > But not me ... I don't think this patch is merge-worthy. Thanks for clearing that up. Yes, you did have me confused. Sure, if something is needless, it doesn't provide value. So we disagree that some parens are needless. OK. > > > "Yet Another Subtle And Hard To Fix Source Of Bloat" is > > > not a plus. > > > > ISTM that we agree. > > Evidently not, since removing it would promote such bloat. > Explicitly removing disapproval is a form of approval... > > > > > I'd kind of think a change like this should have some > > > positive motivation. > > > > "Me, I agree that numbers in parens don't usually make sense for > > kernel messages." > > > > It's too trivial to be included in CodingStyle. > > So the reason to remove that guideline, and thereby encourage > proliferation of needless parens, is ... that some OTHER way > to get rid of them is working? Andrew listed some cases where parens make sense. He didn't say (and I don't say) [oops, parens] that they always make sense, but the statement in CodingStyle is too strict. Sometimes they make sense. > I would agree that line could be improved to say that messages > should not be needlessly large. Excess parens are one example; > wordiness is another (including printing 8 bit fields as 0x%08x), > and I'm sure there are more. --- ~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: regression in 2.6.23-rc8 - power off failed
Wolfgang Erig wrote: > Hi Peter, > > On Sat, Sep 29, 2007 at 11:35:53AM +0200, Wolfgang Erig wrote: >> I start again with a fresh tree and better controlled experiments. > > now the result of bisection seems to be consistent. > > The last good commit is > f2d98ae63dc64dedb00499289e13a50677f771f9 Linker script for the new x86 setup > code > > The first bad commit (no power off) is > 4fd06960f120e02e9abc802a09f9511c400042a5 Use the new x86 setup code for i386 > > Now I try the things written in > http://marc.info/[EMAIL PROTECTED] > OK, that makes more sense. I'll look at this on Monday. -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: [PATCH] CodingStyle: Printing numbers in parentheses is fine
> > > Let's kill it, please. (i.e., ACK) > > > > But ... why? What value could needless parens provide? > > Who says that needless parens could provide value? Jean, which is why he submitted the patch. You, implicitly, by acking a patch saying those parens are bad. But not me ... I don't think this patch is merge-worthy. > > "Yet Another Subtle And Hard To Fix Source Of Bloat" is > > not a plus. > > ISTM that we agree. Evidently not, since removing it would promote such bloat. Explicitly removing disapproval is a form of approval... > > I'd kind of think a change like this should have some > > positive motivation. > > "Me, I agree that numbers in parens don't usually make sense for > kernel messages." > > It's too trivial to be included in CodingStyle. So the reason to remove that guideline, and thereby encourage proliferation of needless parens, is ... that some OTHER way to get rid of them is working? I would agree that line could be improved to say that messages should not be needlessly large. Excess parens are one example; wordiness is another (including printing 8 bit fields as 0x%08x), and I'm sure there are more. - 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] Combine path_put and path_put_conditional
Hi Andreas, On Friday 28 September 2007, Andreas Gruenbacher wrote: > The name path_put_conditional (formerly, dput_path) is a little unclear. > Replace (path_put_conditional + path_put) with path_walk_put_both, > "put a pair of paths after a path_walk" (see the kerneldoc). ^ So why not name it path_walk_put_pair() then? Rationale: "_both" is just counting, "_pair" means they are related somehow. Best regards Ingo Oeser - 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.23-rc8-mm2] kernel BUG at mm/slab.c:591! | invalid opcode: 0000 [#1] SMP
On Friday 28 September 2007, you wrote: > My Toshiba Satellite A40 (i386, P4 Mobile) hangs during boot after: With 'hpet-force-enable-on-ich34' reverted the system boots OK again. We're not yet done though. It now fails to resume from suspend and there's also the BUG (see subject) during power off. Possibly these are related. Attached a diff of dmesg between 2.6.23-6 and 2.6.23-8. Nothing spectacular AFAICT, except that I activated netconsole. The details of that BUG are at the end of the diff. I have some idea where to start looking for this one. If I'm not mistaken, it should be somewhere between these two changes: # good: [01762341418efa818f28dc69426ca7cc582cdc8c] git-wireless # good: [ecdd2a3cb73af8b4659a4cb150bdf2a3ac908791] i386-pit-remove-the-useless-ifdefs Cheers, FJP --- 2.6.23-rc6-686.dmesg 2007-09-19 19:32:00.0 +0200 +++ strider2.log 2007-09-29 23:55:18.0 +0200 @@ -1,335 +1,360 @@ -Linux version 2.6.23-rc6 ([EMAIL PROTECTED]) (gcc version 4.2.1 (Debian 4.2.1-4)) #1 SMP Wed Sep 19 16:31:00 CEST 2007 +Linux version 2.6.23-rc8-mm2 ([EMAIL PROTECTED]) (gcc version 4.2.1 (Debian 4.2.1-4)) #1 SMP Sat Sep 29 23:22:39 CEST 2007 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e - 000eee00 (reserved) BIOS-e820: 000eee00 - 000ef000 (ACPI NVS) BIOS-e820: 000ef000 - 0010 (reserved) BIOS-e820: 0010 - 1ef4 (usable) BIOS-e820: 1ef4 - 1ef5 (ACPI data) BIOS-e820: 1ef5 - 1f00 (reserved) BIOS-e820: fec0 - fec01000 (reserved) BIOS-e820: fec1 - fec2 (reserved) BIOS-e820: feda - fedc (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: ffb0 - ffc0 (reserved) BIOS-e820: ffe8 - 0001 (reserved) 0MB HIGHMEM available. 495MB LOWMEM available. -Entering add_active_range(0, 0, 126784) 0 entries of 256 used Zone PFN ranges: DMA 0 -> 4096 Normal 4096 -> 126784 HighMem126784 -> 126784 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 -> 126784 -On node 0 totalpages: 126784 - DMA zone: 32 pages used for memmap - DMA zone: 0 pages reserved - DMA zone: 4064 pages, LIFO batch:0 - Normal zone: 958 pages used for memmap - Normal zone: 121730 pages, LIFO batch:31 - HighMem zone: 0 pages used for memmap - Movable zone: 0 pages used for memmap DMI 2.3 present. ACPI: RSDP 000F0180, 0014 (r0 TOSHIB) ACPI: RSDT 1EF4, 0038 (r1 TOSHIB 750970814 TASM 401) ACPI: FACP 1EF40060, 0084 (r2 TOSHIB 750 20030101 TASM 401) ACPI: DSDT 1EF40558, 4B72 (r1 TOSHIB A000C20031216 MSFT 10E) ACPI: FACS 000EEE00, 0040 ACPI: SSDT 1EF402CA, 0082 (r1 TOSHIB A000C20030917 MSFT 10E) ACPI: DBGP 1EF400E4, 0034 (r1 TOSHIB 750970814 TASM 401) ACPI: BOOT 1EF40038, 0028 (r1 TOSHIB 750970814 TASM 401) ACPI: APIC 1EF40118, 0062 (r1 TOSHIB 750970814 TASM 401) ACPI: PM-Timer IO Port: 0xd808 -ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 15:2 APIC version 20 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] disabled) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 1, version 32, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) -ACPI: IRQ0 used by override. -ACPI: IRQ2 used by override. -ACPI: IRQ9 used by override. Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 2000 (gap: 1f00:dfc0) swsusp: Registered nosave memory region: 0009f000 - 000a swsusp: Registered nosave memory region: 000a - 000e swsusp: Registered nosave memory region: 000e - 000ee000 swsusp: Registered nosave memory region: 000ee000 - 000ef000 swsusp: Registered nosave memory region: 000ef000 - 0010 -Built 1 zonelists in Zone order. Total pages: 125794 -Kernel command line: root=/dev/hda3 ro vga=791 -mapped APIC to b000 (fee0) -mapped IOAPIC to a000 (fec0) +Built 1 zonelists in Zone order, mobility grouping on. Total pages: 125794 +Kernel command line: root=/dev/hda3 resume=/dev/hda6 ro vga=791 [EMAIL PROTECTED]/,@10.19.66.12/ Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 PID hash table entries: 2048 (order: 11, 8192 bytes) -Detected 2793.139 MHz processor. +Detected 2793.094 MHz
Re: [PATCHSET 3/4] sysfs: divorce sysfs from kobject and driver model
Hello, Eric. Eric W. Biederman wrote: > Mostly I am thinking that any non-object model users should have > their own dedicated wrapper layer. To help keep things consistent > and to make it hard enough to abuse the system that people will > find that it is usually easier to do it the right way. Hmmm... I think most current non-driver-model sysfs users are deep in kernel anyway, but I think not exporting sysfs interface at all might be a bit too restrictive. I think we need to examine the current non-driver-model sysfs users thoroughly to determine what to do about this. But, yes, I do agree that we need to put restrictions one way or the other. > Does it look like we can resolve Tejun's work for 2.6.24? > If not does it make sense to push my patches that allow > multiple mounts of sysfs for 2.6.24? So I can allow > network namespaces in the presence of sysfs. > > Outside of sysfs and the device model I'm only talk maybe 30 lines > of code...So I could easily merge that patch later in the > merge window after the other pieces have gone in. I think it would be better if namespace comes after interface update and other new features, especially symlink renaming, but, under the current circumstance, it might delay namespace unnecessarily and I have no problem with your patches going in first. My concerns are... * Do you think you can use new rename implementation contained in this series? It borrows basic ideas from the implementation you used for namespace but is more generic. It would be great if you can use it without too much modification. * I'm still against using callbacks to determine namespace tags because callbacks need to be coupled with sysfs internals more tightly and are more difficult to grasp interface-wise. > - Farther down the road we have the device namespace. > The bounding requirements are: > - We want to restrict which set of devices a subset of process > can access. > - When we migrate an application we want to preserve the device > numbers of all devices that show up in the new location. > So filesystems whose block devices reside on a SAN, ramdisks, > ttys, etc. > Other devices that really are different we can handle with > hotplug remove and add events, during the migration. > > So while there is lower hanging fruit the requirements for a > device namespace are becoming clear, and don't look like something > we will ultimately be able to dodge. > > For sysfs the implication is that we will need to filter the > hotplug events based upon the device namespace of the recipient, and > we will need to restrict the set of devices that show up in sysfs > based on who mounts it (as the prototype patches with the network > namespace are doing). > > Also fun is that the dev file implementation needs to be able to > report different major:minor numbers based on which mount of > sysfs we are dealing with. Ah... Coming few months will be fun, won't they? :-) -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: FW: [patch 01/02] vfs: variant symlinks
On Sat, 2007-09-29 at 12:40 -0700, Schmidt, Kenneth P wrote: > The best example of how this can be useful is to allow a heterogeneous > environment which uses a common filesystem. For example, both x86_64 and > power systems could mount a root nfs share and execute with a common set of > configurations and data, but the binary directories (bin and lib) could > point to architecture specific directories. That would hardly be a portable NFS environment. Boot a Solaris, or older Linux kernel, and watch your applications barf... This sort of stuff belongs in the automounter, not the kernel. Trond - 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] 0/3 coding standards documentation/code updates
On Sat, 29 Sep 2007, Linus Torvalds wrote: > > > On Fri, 28 Sep 2007, Erez Zadok wrote: > > > > Documentation/CodingStyle | 88 > > +- > > I'm not very happy with this. > > "CodingStyle" should be about the big issues, not about details. > Yes, we've messed that up over the years, but let's not continue > that. > > In other words, I'd suggest *removing* lines from CodingStyle, not > adding them. The file has already gone from a "good general > principles" to "lots of stupid details". Let's not make it worse. here's a radical idea -- what about splitting the content across two documents? you know ... perhaps "coding style aesthetics" versus "coding distinctions" or something like that. oh, wait ... http://lkml.org/lkml/2007/1/1/18 :-) rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca - 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: regression in 2.6.23-rc8 - power off failed
On Saturday, 29 September 2007 22:47, Bill Davidsen wrote:
> Alexey Starikovskiy wrote:
>
> > -static void
> > -acpi_power_off (void)
> > -{
> > - printk("%s called\n",__FUNCTION__);
> > - /* Some SMP machines only can poweroff in boot CPU */
> > - set_cpus_allowed(current, cpumask_of_cpu(0));
> > ACPI in kernel 2.6.12 did disable non-boot cpus too in powe_off.
> > Later only comment was left for some reason...
> >
> Am I midreading that code, or does it really assume that the boot cpu is
> always zero? Or just that zero will be able to do the power off?
>
> In any case I have had an SMP machine which did not have a CPU zero, and
> it was discussed here, I believe. Wonder what happens if you set
> affinity to a CPU you don't have...
Good question, but it also caused other problems to appear, IIRC.
IMHO, it's better to call disable_nonboot_cpus() in an appropriate place
anyway.
Greetings,
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/
Re: 2.6.23-rc8-mm2 - tcp_fastretrans_alert() WARNING
On Sat, 29 Sep 2007, Cedric Le Goater wrote: > Ilpo Järvinen wrote: > > On Fri, 28 Sep 2007, Ilpo Järvinen wrote: > >> On Fri, 28 Sep 2007, Cedric Le Goater wrote: > >> > >>> I just found that warning in my logs. It seems that it's been > >>> happening since rc7-mm1 at least. > >>> > >>> WARNING: at /home/legoater/linux/2.6.23-rc8-mm2/net/ipv4/tcp_input.c:2314 > >>> tcp_fastretrans_alert() > >>> > >>> Call Trace: > >>>[] tcp_ack+0xcd6/0x1894 > >>> ...snip... > >> ...Thanks for the report, I'll have look what could still break > >> fackets_out... > > > > I think this one is now clear to me, tcp_fragment/collapse adjusts > > fackets_out (incorrectly) also for reno flow when there were some dupACKs > > that made sacked_out != 0. Could you please try if patch below proves all > > them to be of non-SACK origin... In case that's true, it's rather > > harmless, I'll send a fix on Monday or so (this would anyway be needed)... > > If you find out that them occur with SACK enabled flow, that would be > > more interesting and requires more digging... > > I'm trying now to reproduce this WARNING. > > It seems that the n/w behaves differently during the week ends. Probably > taking a break. Thanks. Of course there are other means too to determine if TCP flows do negotiate SACK enabled or not. Depending on your test case (which is fully unknown to me) they may or may not be usable... At least the value of tcp_sack sysctl on both systems or tcpdump catching SYN packets should give that detail. ...If you know to which hosts TCP could be connected (and active) to, while the WARNING triggers, it's really easy to test what is being negotiated as it's unlikely to change at short notice and any TCP flow to that host will get us the same information though the WARNING would not be triggered with it at this time. Obviously if at least one of the remotes is not known or the set ends up being mixture of reno and SACK flows, then we'll just have to wait and see which fish we get... -- i.
Re: regression in 2.6.23-rc8 - power off failed
Alexey Starikovskiy wrote:
-static void
-acpi_power_off (void)
-{
- printk("%s called\n",__FUNCTION__);
- /* Some SMP machines only can poweroff in boot CPU */
- set_cpus_allowed(current, cpumask_of_cpu(0));
ACPI in kernel 2.6.12 did disable non-boot cpus too in powe_off.
Later only comment was left for some reason...
Am I midreading that code, or does it really assume that the boot cpu is
always zero? Or just that zero will be able to do the power off?
In any case I have had an SMP machine which did not have a CPU zero, and
it was discussed here, I believe. Wonder what happens if you set
affinity to a CPU you don't have...
--
Bill Davidsen <[EMAIL PROTECTED]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
-
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: [spi-devel-general] IT8716F SPI driver submission?
> The IT8716F accepts commands byte-wise and does all of the lifting on > the SPI bus as well. There are limitations, though: > - It can send 1,2,4,5 bytes (including command byte) to the slave and > read 0,1,2,3 bytes back. Other values are not possible. > - Bus clock rate is either 33 MHz or 16.5 MHz. > > Is there any driver I can start from as reference? None that I know of. You might find it's easier to just work with a bastardized version of the (latest, with the 2.6.24 MTD updates so it handleds even more chips) m25p80 driver and not go through the SPI framework. It doesn't look like you could even bitbang SPI there, since not all those pins are usable for bit-level I/O. As you note, that hardware doesn't support all that a SPI controller does. It's provided for accessing a single serial flash chip; and not even to do that very smoothly. You'd have to somehow prevent that driver from reading or writing normal size blocks. And you'd need to defend against drivers trying to do full duplex or multi-segment I/O requests, etc. Lots more work than a bastardized m25p80 driver. ;) My limited exposure to SPI on PC hardware -- LPC chips like this, and newer southbridges -- suggests they tend to be just as, erm, "limited" as this one in terms of supporting anything other than one particular variety of serial flash interface. I think the idea was just to let board makers use cheaper flash chips when loading the BIOS. For that, they don't need the kind of flexible expansion bus SPI is on most SOC chips; or much throughput. - 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: FW: [patch 01/02] vfs: variant symlinks
On Sat, Sep 29, 2007 at 12:40:23PM -0700, Schmidt, Kenneth P wrote: > The best example of how this can be useful is to allow a heterogeneous > environment which uses a common filesystem. For example, both x86_64 and > power systems could mount a root nfs share and execute with a common set of > configurations and data, but the binary directories (bin and lib) could > point to architecture specific directories. mount --bind /usr/$(ARCH)/bin /usr/bin mount --bind /usr/$(ARCH)/lib /usr/lib or corresponding ones in /etc/fstab. BFD... - 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: [OT] kbuild syntax extension for ccflags and asflags (was: [PATCH 1/3] CodingStyle updates)
> > Lately I have considered extending the kbuild syntax a bit. > > > > Introducing > > ccflags-y > > asflags-y > > > > [with same functionality as the EXTRA_CFLAGS, EXTRA_AFLAGS] > > would allow us to do: > > > > ccflags-$(CONFIG_WHATEVER_DEBUG) := -DDEBUG > > Please do! > > That is very useful for testing and developing new modules. > I learnt a lot from you in this regard and used that kind > of syntax to the extreme in some other non-kernel project > of mine. There it included also ccflags, asflags and so on. > > I further split that into -debug-y and -optimize-y flags, > but that was just for my own convenience. Thanks for feedback Ingo. I just started a new thread were I outlined the ideas I have for further extending (some may say uglifying) the kbuild syntax. I will see the outcome of this thread before implmenting something. PS. The implementation part is obviously trivial, the hard part is the documentation :-) 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/
[OT] kbuild syntax extension for ccflags and asflags (was: [PATCH 1/3] CodingStyle updates)
Hi Sam, On Saturday 29 September 2007, Sam Ravnborg wrote: > Lately I have considered extending the kbuild syntax a bit. > > Introducing > ccflags-y > asflags-y > > [with same functionality as the EXTRA_CFLAGS, EXTRA_AFLAGS] > would allow us to do: > > ccflags-$(CONFIG_WHATEVER_DEBUG) := -DDEBUG Please do! That is very useful for testing and developing new modules. I learnt a lot from you in this regard and used that kind of syntax to the extreme in some other non-kernel project of mine. There it included also ccflags, asflags and so on. I further split that into -debug-y and -optimize-y flags, but that was just for my own convenience. Best Regards Ingo Oeser - 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] CodingStyle: Printing numbers in parentheses is fine
On Sat, 29 Sep 2007 11:53:06 -0700 David Brownell wrote: > > From [EMAIL PROTECTED] Sat Sep 29 11:40:17 2007 > > > > Let's kill it, please. (i.e., ACK) > > But ... why? What value could needless parens provide? Who says that needless parens could provide value? > "Yet Another Subtle And Hard To Fix Source Of Bloat" is > not a plus. ISTM that we agree. > I'd kind of think a change like this should have some > positive motivation. "Me, I agree that numbers in parens don't usually make sense for kernel messages." It's too trivial to be included in CodingStyle. --- ~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: [PATCH] 0/3 coding standards documentation/code updates
On Sat, 29 Sep 2007 15:56:38 -0400 J. Bruce Fields wrote: > On Sat, Sep 29, 2007 at 11:18:05AM -0700, Linus Torvalds wrote: > > I'm not very happy with this. > > > > "CodingStyle" should be about the big issues, not about details. Yes, > > we've messed that up over the years, but let's not continue that. > > > > In other words, I'd suggest *removing* lines from CodingStyle, not adding > > them. The file has already gone from a "good general principles" to "lots > > of stupid details". Let's not make it worse. > > It'd be nice to split the current CodingStyle into two documents: I agree. This is just what I was thinking during lunch. > - A shorter CodingStyle that gives the spirit of the style > (short functions, minimal nesting, logic as straightforward as > possible, etc.), and addresses the most commonly repeated > mistakes, without so much detail that people's eyes glaze > over. You want to be able to recommend it to your students > (or whoever) in reasonable confidence that they'll actually > read it and have fun (leave the jokes in!). Currently I'm > suspicious that it's becoming something that everybody > recommends but noone bothers to sit down and read anymore > unless they're working on it. > > - A CodingStyleReference that's just a long dry list of rules, > organized to make it easy to look up an individual rule when > needed. That'd also take the pressure of CodingStyle to > accept every new detail. > > It'd be a start just to revert CodingStyle to its original content and > move the rest to CodingStyleReference. But someone would want to skim > through the CodingStyle history for any legimate corrections that we > want to keep. --- ~Randy Phaedrus says that Quality is about caring. - 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] Extending kbuild syntax
Over the last few weeks I have pondered with the idea to extend the current kbuild syntax. The idea have existed for long but only recently I started to think how to do this in a truely flexible manner. Two areas are in need for a bit of attention to improve current kbuild files in the kernel. The first issue is the EXTRA_CFLAGS. They are often conditionally assigned like in the following example: ifeq ($(DEBUG),y) EXTRA_CFLAGS := -DDEBUG endif Introducing the following new variable could make this a oneliner: ccflags-y ccflags-$(DEBUG) := -DDEBUG grep -r -C 1 -B 1 EXTRA_CFLAGS shows that the above is a very common pattern especially in drivers/ The kbuild variable is named 'ccflags' to match the CC prefix for the C compiler used in non-verose output. And then it does not clash with current cflags-y usage too. The second is the more controversial suggestion. In several Makefile we have simple if expression of the variants: if ($(CONFIG_FOO),y) obj-$(CONFIG_BAR) += fubar.o endif The pattern varies over this theme. The suggestion here is to introduce a few helpers: obj-y-if-$(CONFIG_FOO) += fubar.o This one shall read: if $(CONFIG_FOO) is y or m then set += to obj-y In several cases we will need it to be more complicated like the this: obj-y-ify-$(CONFIG_FOO) += fubar.o This one shall read: if $(CONFIG_FOO) is y (thats the ify thing) then += to obj-y And we can mix it like the following: obj-$(CONFIG_BAR)-ify-$(CONFIG_FOO) += fubar.o This one shall read: if $(CONFIG_FOO) equal y then += to obj-$(CONFIG_BAR) The full list of new variables are (for obj-y): obj-y-if-y obj-y-if-m obj-y-ify-y obj-y-ifm-m obj-y-ifn- And similar for obj-m: obj-m-if-y obj-m-if-m obj-m-ify-y obj-m-ifm-m obj-m-ifn- The 'y' and 'm' can be replaced by $(CONFIG_FOO) but the one right to the if are not supposed to be replaced. To better express how to use it I have tried to update a few Makefiles to use the new syntax. See below. On MAJOR drawback is the linking order. I have no way to keep the link order if the new syntax are sued. The .o files will either be put before .o files specified with obj-y or obj-m or after the same. For some places this does not matter but for other places (fs/Makefile) I will expect it to matter a lot. Comments? Is this just to magic for bare humans to grasp. Or mabe the linking order is so important that we do not want it? PS. The coming x86 merge triggered this. I would like to make the Makefiles readable and the above can help here. Sam fs/Makefile | 10 +++--- kernel/Makefile |8 ++-- mm/Makefile |7 +++ sound/Makefile |4 +--- sound/core/seq/Makefile |9 +++-- sound/i2c/Makefile |4 +--- sound/isa/sb/Makefile |6 ++ sound/oss/Makefile |4 +--- 8 files changed, 16 insertions(+), 36 deletions(-) diff --git a/fs/Makefile b/fs/Makefile index 720c29d..1b0a48e 100644 --- a/fs/Makefile +++ b/fs/Makefile @@ -13,11 +13,8 @@ obj-y := open.o read_write.o file_table.o super.o \ pnode.o drop_caches.o splice.o sync.o utimes.o \ stack.o -ifeq ($(CONFIG_BLOCK),y) -obj-y += buffer.o bio.o block_dev.o direct-io.o mpage.o ioprio.o -else -obj-y += no-block.o -endif +obj-y-ify-$(CONFIG_BLOCK) := buffer.o bio.o block_dev.o direct-io.o mpage.o ioprio.o +obj-y-ifn-$(CONFIG_BLOCK) := no-block.o obj-$(CONFIG_INOTIFY) += inotify.o obj-$(CONFIG_INOTIFY_USER) += inotify_user.o @@ -28,8 +25,7 @@ obj-$(CONFIG_TIMERFD) += timerfd.o obj-$(CONFIG_EVENTFD) += eventfd.o obj-$(CONFIG_COMPAT) += compat.o compat_ioctl.o -nfsd-$(CONFIG_NFSD):= nfsctl.o -obj-y += $(nfsd-y) $(nfsd-m) +obj-y-if-$(CONFIG_NFSD)+= nfsctl.o obj-$(CONFIG_BINFMT_AOUT) += binfmt_aout.o obj-$(CONFIG_BINFMT_EM86) += binfmt_em86.o diff --git a/kernel/Makefile b/kernel/Makefile index 2a99983..5d7706e 100644 --- a/kernel/Makefile +++ b/kernel/Makefile @@ -15,13 +15,9 @@ obj-$(CONFIG_STACKTRACE) += stacktrace.o obj-y += time/ obj-$(CONFIG_DEBUG_MUTEXES) += mutex-debug.o obj-$(CONFIG_LOCKDEP) += lockdep.o -ifeq ($(CONFIG_PROC_FS),y) -obj-$(CONFIG_LOCKDEP) += lockdep_proc.o -endif +obj-$(CONFIG_LOCKDEP)-if-$(CONFIG_PROC_FS) += lockdep_proc.o obj-$(CONFIG_FUTEX) += futex.o -ifeq ($(CONFIG_COMPAT),y) -obj-$(CONFIG_FUTEX) += futex_compat.o -endif +obj-$(CONFIG_FUTEX)-if-$(CONFIG_COMPAT) += futex_compat.o obj-$(CONFIG_RT_MUTEXES) += rtmutex.o obj-$(CONFIG_DEBUG_RT_MUTEXES) += rtmutex-debug.o obj-$(CONFIG_RT_MUTEX_TESTER) += rtmutex-tester.o diff --git a/mm/Makefile b/mm/Makefile index 245e33a..3a55991 100644 --- a/mm/Makefile +++ b/mm/Makefile @@ -2,16 +2,15 @@ # Makefile for the linux memory manager. # -mmu-y := nommu.o -mmu-$(CONFIG_MMU) := fremap.o highmem.o madvise.o memory.o mincore.o \ +obj-y-ifn-$(CONFIG_MMU) := nommu.o
[PATCH 4/4] hpt366: MWDMA filter for SATA cards (take 2)
The Marvell bridge chips used on HighPoint SATA cards do not seem to support
the MWDMA modes (at least that caould be seen in their so-called drivers :-),
so the driver needs to account for this -- to achieve this:
- add mdma_filter() method from the original patch by Bartlomiej Zolnierkewicz
with his consent, also adding the method callout to ide_rate_filter();
- install the method for all chips to only return empty mask if a SATA drive
is detected on HPT372{AN]/374 chips...
Signed-off-by: Sergei Shtylyov <[EMAIL PROTECTED]>
---
This patch is against the current Linus' tree.
It has not been tested on a real SATA card...
drivers/ide/ide-dma.c|9 +++--
drivers/ide/ide.c|1 +
drivers/ide/pci/hpt366.c | 23 +--
include/linux/ide.h |1 +
4 files changed, 30 insertions(+), 4 deletions(-)
Index: linux-2.6/drivers/ide/ide-dma.c
===
--- linux-2.6.orig/drivers/ide/ide-dma.c
+++ linux-2.6/drivers/ide/ide-dma.c
@@ -674,8 +674,13 @@ static unsigned int ide_get_mode_mask(id
mask &= 0x07;
break;
case XFER_MW_DMA_0:
- if (id->field_valid & 2)
- mask = id->dma_mword & hwif->mwdma_mask;
+ if ((id->field_valid & 2) == 0)
+ break;
+ if (hwif->mdma_filter)
+ mask = hwif->mdma_filter(drive);
+ else
+ mask = hwif->mwdma_mask;
+ mask &= id->dma_mword;
break;
case XFER_SW_DMA_0:
if (id->field_valid & 2) {
Index: linux-2.6/drivers/ide/ide.c
===
--- linux-2.6.orig/drivers/ide/ide.c
+++ linux-2.6/drivers/ide/ide.c
@@ -398,6 +398,7 @@ static void ide_hwif_restore(ide_hwif_t
hwif->tuneproc = tmp_hwif->tuneproc;
hwif->speedproc = tmp_hwif->speedproc;
+ hwif->mdma_filter = tmp_hwif->mdma_filter;
hwif->udma_filter = tmp_hwif->udma_filter;
hwif->selectproc= tmp_hwif->selectproc;
hwif->reset_poll= tmp_hwif->reset_poll;
Index: linux-2.6/drivers/ide/pci/hpt366.c
===
--- linux-2.6.orig/drivers/ide/pci/hpt366.c
+++ linux-2.6/drivers/ide/pci/hpt366.c
@@ -1,5 +1,5 @@
/*
- * linux/drivers/ide/pci/hpt366.c Version 1.12Aug 19, 2007
+ * linux/drivers/ide/pci/hpt366.c Version 1.13Sep 29, 2007
*
* Copyright (C) 1999-2003 Andre Hedrick <[EMAIL PROTECTED]>
* Portions Copyright (C) 2001 Sun Microsystems, Inc.
@@ -114,7 +114,7 @@
* unify HPT36x/37x timing setup code and the speedproc handlers by joining
* the register setting lists into the table indexed by the clock selected
* - set the correct hwif->ultra_mask for each individual chip
- * - add UltraDMA mode filtering for the HPT37[24] based SATA cards
+ * - add Ultra and MW DMA mode filtering for the HPT37[24] based SATA cards
* Sergei Shtylyov, <[EMAIL PROTECTED]> or <[EMAIL PROTECTED]>
*/
@@ -562,6 +562,24 @@ static u8 hpt3xx_udma_filter(ide_drive_t
return check_in_drive_list(drive, bad_ata33) ? 0x00 : mask;
}
+static u8 hpt3xx_mdma_filter(ide_drive_t *drive)
+{
+ ide_hwif_t *hwif= HWIF(drive);
+ struct hpt_info *info = pci_get_drvdata(hwif->pci_dev);
+
+ switch (info->chip_type) {
+ case HPT372 :
+ case HPT372A:
+ case HPT372N:
+ case HPT374 :
+ if (ide_dev_is_sata(drive->id))
+ return 0x00;
+ /* Fall thru */
+ default:
+ return 0x07;
+ }
+}
+
static u32 get_speed_setting(u8 speed, struct hpt_info *info)
{
int i;
@@ -1257,6 +1275,7 @@ static void __devinit init_hwif_hpt366(i
hwif->busproc = _busproc;
hwif->udma_filter = _udma_filter;
+ hwif->mdma_filter = _mdma_filter;
/*
* HPT3xxN chips have some complications:
Index: linux-2.6/include/linux/ide.h
===
--- linux-2.6.orig/include/linux/ide.h
+++ linux-2.6/include/linux/ide.h
@@ -723,6 +723,7 @@ typedef struct hwif_s {
/* driver soft-power interface */
int (*busproc)(ide_drive_t *, int);
#endif
+ u8 (*mdma_filter)(ide_drive_t *);
u8 (*udma_filter)(ide_drive_t *);
void (*ata_input_data)(ide_drive_t *, void *, u32);
-
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.23-rc8-mm2] System hangs (loops?) during boot
On Sat, 29 Sep 2007 21:40:22 +0200 Frans Pop <[EMAIL PROTECTED]> wrote: > On Saturday 29 September 2007, you wrote: > > On Sat, 29 Sep 2007 02:32:44 +0200 Frans Pop <[EMAIL PROTECTED]> wrote: > > > On Friday 28 September 2007, Frans Pop wrote: > > > > My Toshiba Satellite A40 (i386, P4 Mobile) hangs during boot after: > > > > Marking TSC unstable due to: possible TSC halt in C2. > > > > Time: acpi_pm clocksource has been installed. > > > > > > A few new boot attempts show the problem is more likely at: > > > Probing IDE interface ide0... > > Looks like it is both: hpet killing IDE? > > > Two iterations should get you into the culprit zone. > > Thanks for the pointers. Luckily I ended up in a quite narrow zone between > two of the points you indicated (10 iterations). > > And the winner is: > > 3fe6c0016fd863b233097a8219a0d8577c2fd503 is first bad commit > commit 3fe6c0016fd863b233097a8219a0d8577c2fd503 > Author: Udo A. Steinberg <...> > hpet-force-enable-on-ich34 > > Guess the comments about thin ice and testing were justified :-) > > lspci and a 2.6.23-rc6 dmesg for this system can be found in: > http://lkml.org/lkml/2007/9/19/300 Great, thanks for doing that. I guess I'll drop the patch for now in that 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: Write-back from inside FS - need suggestions
On Sat, 29 Sep 2007 22:10:42 +0300 Artem Bityutskiy <[EMAIL PROTECTED]> wrote: > Andrew Morton wrote: > > I'd have thought that a suitable wrapper around a suitably-modified > > sync_sb_inodes() would be appropriate for both filesystems? > > Ok, I've modified sync_inodes_sb() so that I can pass it my own wbc, > where I set wcb->nr_to_write = 20. It gives me _exactly_ what I want. > It just flushes a bit more then 20 pages and returns. I use > WB_SYNC_ALL. Great! ok.. > Now I would like to understand why it works :-) To my surprise, it > does not deadlock! I call it from ->prepare_write where I'm holding > i_mutex, and it works just fine. It calls ->writepage() without trying > to lock i_mutex! This looks like some witchcraft for me. writepage under i_mutex is commonly done on the sys_write->alloc_pages->direct-reclaim path. It absolutely has to work, and you'll be fine relying upon that. However ->prepare_write() is called with the page locked, so you are vulnerable to deadlocks there. I suspect you got lucky because the page which you're holding the lock on is not dirty in your testing. But in other applications (eg: 1k blocksize ext2/3/4) the page _can_ be dirty while we're trying to allocate more blocks for it, in which case the lock_page() deadlock can happen. One approach might be to add another flag to writeback_control telling write_cache_pages() to skip locked pages. Or even put a page* into wrietback_control and change it to skip *this* page. > This means that if I'm in the middle of an operation or ino #X, I own > its i_mutex, but not I_LOCK, I can be preempted and ->writepage can > be called for a dirty page belonging to this inode #X? yup. Or another CPU can do the same. > I haven't seen > this in practice and I do not believe this may happen. Why? Perhaps a heavier workload is needed. There is code in the VFS which tries to prevent lots of CPUs from getting in and fighting with each other (see writeback_acquire()) which will have the effect of serialising things for some extent. But writeback_acquire() is causing scalability problems on monster IO systems and might be removed, and it is only a partial thing - there are other ways in which concurrent writeout can occur (fsync, sync, page reclaim, ...) > Could you or someone please give me a hint what exactly > inode->i_flags & I_LOCK protects? err, it's basically an open-coded mutex via which one thread can get exclusive access to some parts of an inode's internals. Perhaps it could literally be replaced with a mutex. Exactly what I_LOCK protects has not been documented afaik. That would need to be reverse engineered :( > What is its relationship to i_mutex? On a regular file i_mutex is used mainly for protection of the data part of the file, although it gets borrowed for other things, like protecting f_pos of all the inode's file*'s. I_LOCK is used to serialise access to a few parts of the inode itself. - 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] 0/3 coding standards documentation/code updates
On Sat, Sep 29, 2007 at 11:18:05AM -0700, Linus Torvalds wrote: > I'm not very happy with this. > > "CodingStyle" should be about the big issues, not about details. Yes, > we've messed that up over the years, but let's not continue that. > > In other words, I'd suggest *removing* lines from CodingStyle, not adding > them. The file has already gone from a "good general principles" to "lots > of stupid details". Let's not make it worse. It'd be nice to split the current CodingStyle into two documents: - A shorter CodingStyle that gives the spirit of the style (short functions, minimal nesting, logic as straightforward as possible, etc.), and addresses the most commonly repeated mistakes, without so much detail that people's eyes glaze over. You want to be able to recommend it to your students (or whoever) in reasonable confidence that they'll actually read it and have fun (leave the jokes in!). Currently I'm suspicious that it's becoming something that everybody recommends but noone bothers to sit down and read anymore unless they're working on it. - A CodingStyleReference that's just a long dry list of rules, organized to make it easy to look up an individual rule when needed. That'd also take the pressure of CodingStyle to accept every new detail. It'd be a start just to revert CodingStyle to its original content and move the rest to CodingStyleReference. But someone would want to skim through the CodingStyle history for any legimate corrections that we want to keep. --b. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Write-back from inside FS - need suggestions
Andrew Morton wrote: I'd have thought that a suitable wrapper around a suitably-modified sync_sb_inodes() would be appropriate for both filesystems? Ok, I've modified sync_inodes_sb() so that I can pass it my own wbc, where I set wcb->nr_to_write = 20. It gives me _exactly_ what I want. It just flushes a bit more then 20 pages and returns. I use WB_SYNC_ALL. Great! Now I would like to understand why it works :-) To my surprise, it does not deadlock! I call it from ->prepare_write where I'm holding i_mutex, and it works just fine. It calls ->writepage() without trying to lock i_mutex! This looks like some witchcraft for me. This means that if I'm in the middle of an operation or ino #X, I own its i_mutex, but not I_LOCK, I can be preempted and ->writepage can be called for a dirty page belonging to this inode #X? I haven't seen this in practice and I do not believe this may happen. Why? Could you or someone please give me a hint what exactly inode->i_flags & I_LOCK protects? What is its relationship to i_mutex? -- Best Regards, Artem Bityutskiy (Артём Битюцкий) - 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: Out of memory management in embedded systems
On 9/29/07, Daniel Spång <[EMAIL PROTECTED]> wrote: > > An embedded system is NOT an ordinary system that happens to > > boot from flash. An embedded system requires intelligent design. > > We might be talking about slightly different systems. I agree that > systems that are really embedded, in the classic meaning often with > real time constraints, should be designed as you suggests. But there > are a lot of other systems that almost actually are ordinary systems > but with limited memory and often without demand paging. [snip] > For those systems I think we need a method to dynamically decrease the > working set of a process when memory is scarce, and not just accept > that we "are screwed" and let the OOM killer solve the problem. In certain cases, I guess it could be a problem in the embedded environment. Especially while running general purpose applications with carefully designed real-time tasks. An OOM in such a case is unacceptable. The whole problem looks like an extension of page frame reclamation in user space. If the user application's cache was owned by the kernel (something like vmsplice with SPLICE_F_GIFT?), and the application managed it accordingly, then they could probably be brought under the purview of kernel's memory reclamation. This would mean that applications wouldn't need to be triggered on low memory, and leave memory freeing to the kernel (simpler and uniform). Perhaps it is even possible to do this in the kernel currently somehow...? -- Abhishek Sagar - > 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/ - 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/
[FYI] 2.6.23-rc8-git3 misc observations
Running FC6 (updated this am) the temp sensors GNOME applet works with the kernel.org kernel, not the FC6 kernel. This has been true for a while, and I've stopped chasing it, I don't really care right now, since the sensors command works fine and that's what my daemon checks. Using 2.6.23-rc8 (no git) the NIC came up at 100Mbit instead of gigE once, not reproducible. Just in case this kicks off a bunch of "mee too" replies. lspci info follows text. Boot times: I occasionally boot repeatedly for various tests, these are the fastest of three (or more) boots of a given kernel, ID is what uname gives. 2.6.21-sd04655.29 2.6.21-cfs-v6 55.93 2.6.20-1.2944.fc6 64.71 2.6.23-rc8-git3 65.06 2.6.22.7-57.fc6 69.02 lspci: 02:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet Controller Subsystem: ASUSTeK Computer Inc. Unknown device 81c2 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- R- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 223 Region 0: Memory at cffe (32-bit, non-prefetchable) [size=128K] Region 2: I/O ports at d800 [size=32] Capabilities: [c8] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=1 PME- Capabilities: [d0] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable+ Address: fee0200c Data: 41d1 Capabilities: [e0] Express Endpoint IRQ 0 Device: Supported: MaxPayload 256 bytes, PhantFunc 0, ExtTag- Device: Latency L0s <512ns, L1 <64us Device: AtnBtn- AtnInd- PwrInd- Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ Device: MaxPayload 128 bytes, MaxReadReq 512 bytes Link: Supported Speed 2.5Gb/s, Width x1, ASPM unknown, Port 0 Link: Latency L0s <128ns, L1 <64us Link: ASPM Disabled RCB 64 bytes CommClk+ ExtSynch- Link: Speed 2.5Gb/s, Width x1 Capabilities: [100] Advanced Error Reporting Capabilities: [140] Device Serial Number De-LE-TE-D -- Bill Davidsen He was a full-time professional cat, not some moonlighting ferret or weasel. He knew about these things. - 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: regression in 2.6.23-rc8 - power off failed
Hi Peter, On Sat, Sep 29, 2007 at 08:07:21PM +0200, Wolfgang Erig wrote: > > Now I try the things written in > http://marc.info/[EMAIL PROTECTED] I have dumped a memory region which is my understanding what you want to see. The difference between the good and the bad case is only the patch "4fd06960f120e02e9abc802a09f9511c400042a5 Use the new x86 setup code for i386" I modified arch/i386/kernel/setup.c and dumped 4K of /dev/kmem at the address of boot_params. Good case: c0457340 > 00 08 fc ff 00 00 03 50 8c c8 03 00 8e c0 19 01 < ...P c0457350 > 10 00 7c fb fc be 31 00 ac 20 c0 74 09 b4 0e bb < ..|...1.. .t c0457360 > 07 00 cd 10 eb f2 31 c0 cd 16 cd 19 ea f0 ff 00 < ..1. c0457370 > f0 < . c0457371 "Direct booting " c0457380 > 02 01 00 f0 ff 96 00 00 00 f0 40 00 03 00 ff ff < [EMAIL PROTECTED] c0457390 > ff ff ff ff < c0457394 "nger supported." c04573a3 > 0d 0a< .. c04573a5 "Please use a boot loader prp4" c04573c2 > 0f 00 00 00 00 00 08 00 00 00 70 34 3f < ..p4? c04573cf11 * 00 c04573e0 > 08 00 fc 01 00 74 00 00 00 00 < .t c04573ea " key to reboot . . ." c04573fe > 0d 0a< .. c0457400 121 * 00 c0457521 > fc 01 00 00 00 09 00 05 00 00 00 00 00 00 00 00 < c0457531 > 0e 01 00 f4 a4 01 00 00 00 00 0f 02 08 55 aa eb < .U.. c0457541 ":HdrS" c0457546 > 06 02 00 00 00 00 00 10 7f 11 71 81 00 80 00 00 < ..q. c0457556 > 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8e < c0457566 > 00 00 00 90 09 00 ff ff ff 1f 00 00 10 00 00 00 < c0457576 > 00 00 ff 07 00 00 e8 c1 0c 90 < .. c045758099 * 00 c0457619 > fc 09 00 00 00 00 00 01 00 00 00 00 fc 09 00 00 < c0457629 > 00 00 00 00 04 00 00 00 00 00 00 02 00 00 00 3a < ...: c0457639 > 12 0f 00 00 00 00 00 c6 ed 00 00 00 00 00 00 02 < c0457649 > 00 00 00 00 00 10 00 00 00 00 00 00 00 f0 07 00 < c0457659 > 00 00 00 01 00 00 00 3a 12 ff ff 00 00 00 00 c6 < ...: c0457669 > ed 00 00 00 00 00 00 02 < c0457671 bcf * 00 c0458240 > b8 00 15 b2 81 cd 13 8c c8 8e d8 81 3e a5 1b 55 < >..U c0458250 > aa 75 4c 81 3e a7 1b < .uL.>.. c0458257 "ZZuD" c045825b > eb 40 ac 20 c0 74 05 e8 08 00 eb f6 c3 e8 00 00 < [EMAIL PROTECTED] .t.. c045826b > b0 20 50 51 bb 07 00 b9 01 00 b4 0e cd 10 59 58 < . PQ..YX c045827b > c3 b0 07 eb ed < . c0458280 "No setup signature found ..." c045829c > 00 eb 4f 8c c8 83 e8 20 8e d8 30 ff 8a 1e f1 01 < ..O ..0. c04582ac > 83 eb 04 c1 e3 08 89 d9 c1 eb 03 81 c3 00 10 2e < c04582bc > 89 1e 0c 00 bf 00 08 29 f6 0e 07 b8 00 10 8e d8 < ...) c04582cc > f3 a5 8c c8 8e d8 81 3e a5 1b 55 aa 75 0a 81 3e < ...>..U.u..> c04582dc > a7 1b 5a 5a 75 02 eb 0a 8d 36 40 0d e8 72 ff f4 < [EMAIL PROTECTED] c04582ec > eb fd 8c c8 83 e8 20 8e d8 2e f6 06 11 00 01 74 < .. t c04582fc > 2e 2e 80 3e 10 00 00 75 26 0e 1f 8d 36 d0 0d e8 < ...>...u&...6... c045830c > 4f ff eb db < O... c0458310 "Wrong loader, giving up..." c045832a > 00 e8 36 00 66 85 c0 74 61 8c c8 8e d8 8d 36 00 < ..6.f..ta.6. c045833a > 0e e8 1f ff eb fe< .. Bad case: c0457340 > 00 08 00 00 00 00 03 50 00 00 03 00 00 00 19 01 < ...P c0457350 > 10 < . c04573514f * 00 c04573a0 > 80 86 00 00 00 00 00 00 00 00 00 00 < c04573ac "CISG" c04573b030 * 00 c04573e0 > 08 00 fc 01 00 74< .t c04573e6 13e * 00 c0457524 > e0 29 09 00 05 00 00 00 00 00 00 00 00 13 01 00 < .).. c0457534 > fa a4 01 00 00 00 ff ff 02 08 55 aa eb < ..U.. c0457541 ":HdrS" c0457546 > 06 02 00 00 00 00 00 10 3c 23 71 81 00 80 00 00 < <#q. c0457556 > 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8e < c0457566 > 00 00 00 90 09 00 ff ff ff 1f 00 00 10 < . c0457573a6 * 00 c0457619 > fc 09 00 00 00 00 00 01 00 00 00 00 fc 09 00 00 < c0457629 > 00 00 00 00 04 00 00 00 00 00 00 02 00 00 00 3a < ...: c0457639 > 12 0f 00 00 00 00 00 c6 ed 00 00 00 00 00 00 02 < c0457649 > 00 00 00 00 00 10 00 00 00 00 00 00 00 f0 07 00 < c0457659 > 00 00 00 01 00 00 00 3a 12 ff ff 00 00 00 00 c6 < ...: c0457669 > ed 00 00 00 00 00 00 02 < c0457671 ccf * 00 $ cat /proc/cmdline root=/dev/hda1 Wolfgang - To unsubscribe from this list: send
FW: [patch 01/02] vfs: variant symlinks
On 9/28/07 11:22 AM, "Jan Dittmer" <[EMAIL PROTECTED]> wrote: > Ken Schmidt wrote: >> Variant symlinks add the ability to embed variables in to the >> contents of symbolic links so their targets can change based on >> outside sources (user environment, uts, filesystems, etc.) > > Could you elaborate why this is needed and what part cannot > be solved in userspace (linkfarm on tmpfs or intelligent > scripts)? Several networked filesystems (i.e. afs) have similar concepts. This just moves it into the vfs layer so that it can be used on all of them and even local filesystems. The best example of how this can be useful is to allow a heterogeneous environment which uses a common filesystem. For example, both x86_64 and power systems could mount a root nfs share and execute with a common set of configurations and data, but the binary directories (bin and lib) could point to architecture specific directories. - 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: [15/17] SLUB: Support virtual fallback via SLAB_VFALLBACK
On Sat, 29 Sep 2007 06:19:33 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote: > On Saturday 29 September 2007 19:27, Andrew Morton wrote: > > On Sat, 29 Sep 2007 11:14:02 +0200 Peter Zijlstra <[EMAIL PROTECTED]> > wrote: > > > > oom-killings, or page allocation failures? The latter, one hopes. > > > > > > Linux version 2.6.23-rc4-mm1-dirty ([EMAIL PROTECTED]) (gcc version 4.1.2 > > > (Ubuntu > > > 4.1.2-0ubuntu4)) #27 Tue Sep 18 15:40:35 CEST 2007 > > > > > > ... > > > > > > > > > mm_tester invoked oom-killer: gfp_mask=0x40d0, order=2, oomkilladj=0 > > > Call Trace: > > > 611b3878: [<6002dd28>] printk_ratelimit+0x15/0x17 > > > 611b3888: [<60052ed4>] out_of_memory+0x80/0x100 > > > 611b38c8: [<60054b0c>] __alloc_pages+0x1ed/0x280 > > > 611b3948: [<6006c608>] allocate_slab+0x5b/0xb0 > > > 611b3968: [<6006c705>] new_slab+0x7e/0x183 > > > 611b39a8: [<6006cbae>] __slab_alloc+0xc9/0x14b > > > 611b39b0: [<6011f89f>] radix_tree_preload+0x70/0xbf > > > 611b39b8: [<600980f2>] do_mpage_readpage+0x3b3/0x472 > > > 611b39e0: [<6011f89f>] radix_tree_preload+0x70/0xbf > > > 611b39f8: [<6006cc81>] kmem_cache_alloc+0x51/0x98 > > > 611b3a38: [<6011f89f>] radix_tree_preload+0x70/0xbf > > > 611b3a58: [<6004f8e2>] add_to_page_cache+0x22/0xf7 > > > 611b3a98: [<6004f9c6>] add_to_page_cache_lru+0xf/0x24 > > > 611b3ab8: [<6009821e>] mpage_readpages+0x6d/0x109 > > > 611b3ac0: [<600d59f0>] ext3_get_block+0x0/0xf2 > > > 611b3b08: [<6005483d>] get_page_from_freelist+0x8d/0xc1 > > > 611b3b88: [<600d6937>] ext3_readpages+0x18/0x1a > > > 611b3b98: [<60056f00>] read_pages+0x37/0x9b > > > 611b3bd8: [<60057064>] __do_page_cache_readahead+0x100/0x157 > > > 611b3c48: [<60057196>] do_page_cache_readahead+0x52/0x5f > > > 611b3c78: [<60050ab4>] filemap_fault+0x145/0x278 > > > 611b3ca8: [<60022b61>] run_syscall_stub+0xd1/0xdd > > > 611b3ce8: [<6005eae3>] __do_fault+0x7e/0x3ca > > > 611b3d68: [<6005ee60>] do_linear_fault+0x31/0x33 > > > 611b3d88: [<6005f149>] handle_mm_fault+0x14e/0x246 > > > 611b3da8: [<60120a7b>] __up_read+0x73/0x7b > > > 611b3de8: [<60013177>] handle_page_fault+0x11f/0x23b > > > 611b3e48: [<60013419>] segv+0xac/0x297 > > > 611b3f28: [<60013367>] segv_handler+0x68/0x6e > > > 611b3f48: [<600232ad>] get_skas_faultinfo+0x9c/0xa1 > > > 611b3f68: [<60023853>] userspace+0x13a/0x19d > > > 611b3fc8: [<60010d58>] fork_handler+0x86/0x8d > > > > OK, that's different. Someone broke the vm - order-2 GFP_KERNEL > > allocations aren't supposed to fail. > > > > I'm suspecting that did_some_progress thing. > > The allocation didn't fail -- it invoked the OOM killer because the kernel > ran out of unfragmented memory. We can't "run out of unfragmented memory" for an order-2 GFP_KERNEL allocation in this workload. We go and synchronously free stuff up to make it work. How did this get broken? > Probably because higher order > allocations are the new vogue in -mm at the moment ;) That's a different bug. bug 1: We shouldn't be doing higher-order allocations in slub because of the considerable damage this does to atomic allocations. bug 2: order-2 GFP_KERNEL allocations shouldn't fail like this. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rfc][patch] i386: remove comment about barriers
On Sat, 29 Sep 2007, Nick Piggin wrote: > [ This is true for x86's sfence/lfence, but raises a question about Linux's > memory barriers. Does anybody expect that a sequence of smp_wmb and smp_rmb > would ever provide a full smp_mb barrier? I've always assumed no, but I > don't know if it is actually documented? ] No, that can't be. rmb+wmb can't be considered a full mb. There was a recent discussion about this in the thread originated by peterz scalable rw_mutex patches. - Davide - 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] CodingStyle: Printing numbers in parentheses is fine
> From [EMAIL PROTECTED] Sat Sep 29 11:40:17 2007 > > Let's kill it, please. (i.e., ACK) But ... why? What value could needless parens provide? "Yet Another Subtle And Hard To Fix Source Of Bloat" is not a plus. I'd kind of think a change like this should have some positive motivation. - 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: Versioning file system
Interesting that you mention the multitude of file systems because I was very surprised to see NILFS being promoted in the latest Linux Magazine but no mention of the other more important file systems currently in work like UnionFS ChunkFS or ext4 so publisized. I can say I was disapointed of the article. I still didn't see any real prove that NILFS is the best file system since bread. Neither I see any comments on nilfs from Andrew and others and yet this is the best new file system coming to Linux. Maybe I missed something that happened in Ottawa. /Sorin On Mon, 18 Jun 2007 05:45:24 -0400, Andreas Dilger <[EMAIL PROTECTED]> wrote: On Jun 16, 2007 16:53 +0200, Jörn Engel wrote: On Fri, 15 June 2007 15:51:07 -0700, alan wrote: > >Thus, in the end it turns out that this stuff is better handled by > >explicit version-control systems (which require explicit operations to > >manage revisions) and atomic snapshots (for backup.) > > ZFS is the cool new thing in that space. Too bad the license makes it > hard to incorporate it into the kernel. It may be the coolest, but there are others as well. Btrfs looks good, nilfs finally has a cleaner and may be worth a try, logfs will get snapshots sooner or later. Heck, even my crusty old cowlinks can be viewed as snapshots. If one has spare cycles to waste, working on one of those makes more sense than implementing file versioning. Too bad everyone is spending time on 10 similar-but-slightly-different filesystems. This will likely end up with a bunch of filesystems that implement some easy subset of features, but will not get polished for users or have a full set of features implemented (e.g. ACL, quota, fsck, etc). While I don't think there is a single answer to every question, it does seem that the number of filesystem projects has climbed lately. Maybe there should be a BOF at OLS to merge these filesystem projects (btrfs, chunkfs, tilefs, logfs, etc) into a single project with multiple people working on getting it solid, scalable (parallel readers/writers on lots of CPUs), robust (checksums, failure localization), recoverable, etc. I thought Val's FS summits were designed to get developers to collaborate, but it seems everyone has gone back to their corners to work on their own filesystem? Working on getting hooks into DM/MD so that the filesystem and RAID layers can move beyond "ignorance is bliss" when talking to each other would be great. Not rebuilding empty parts of the fs, limit parity resync to parts of the fs that were in the previous transaction, use fs-supplied checksums to verify on-disk data is correct, use RAID geometry when doing allocations, etc. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- Best Regards Sorin Faibish Senior Technologist Senior Consulting Software Engineer Network Storage Group EMC² where information lives Phone: 508-435-1000 x 48545 Cellphone: 617-510-0422 Email : [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/
2.6.22/realtek bug in hardware, any kernel work-around?
Package: samba Version: 3.0.26a-1 Kernel: 2.6.22 samba 3.0.26a-1 performance < 900 KiB/s, but FTP = 30-90 MiB/s Let me start out by saing this is an oddball problem: SAMBA: LINUX -> WINDOWS = < 900 KiB/s (varies between 100 - 900 KiB/s) WINDOWS -> LINUX = 30-90 MiB/s (always) FTP: Either direction, 30-90 MiB/s (always) I do not see any nasty errors in the logs even with verbose = 5. Any ideas here? I am not using any special options. # cat /etc/samba/smb.conf [global] log level = 5 workgroup = WORKGROUP server string = %h - Pentium IV 3.4GHZ security = user encrypt passwords = true [user] comment = user path= /home/user writable= yes valid users = user create mask = 644 -- Here, FTP for pulling files from Linux. ftp> mget * 200 TYPE is now 8-bit binary 200 PORT command successful 150-Connecting to port 1255 150 715924.0 kbytes to download 226-File successfully transferred 226 13.687 seconds (measured here), 51.08 Mbytes per second ftp: 733106176 bytes received in 13.69Seconds 53562.23Kbytes/sec. 200 PORT command successful 150-Connecting to port 1256 150 716272.0 kbytes to download 226-File successfully transferred 226 13.032 seconds (measured here), 53.67 Mbytes per second ftp: 733462528 bytes received in 13.05Seconds 56216.95Kbytes/sec. 200 PORT command successful 150-Connecting to port 1257 150 713200.0 kbytes to download 226-File successfully transferred 226 12.869 seconds (measured here), 54.12 Mbytes per second ftp: 730316800 bytes received in 12.88Seconds 56723.63Kbytes/sec. Here, FTP for pushing files to Linux. ftp> mput 1 2 3 200 PORT command successful 150 Connecting to port 1263 226-File successfully transferred 226 12.802 seconds (measured here), 54.61 Mbytes per second ftp: 733106176 bytes sent in 12.80Seconds 57287.35Kbytes/sec. 200 PORT command successful 150 Connecting to port 1264 226-File successfully transferred 226 12.949 seconds (measured here), 54.02 Mbytes per second ftp: 733462528 bytes sent in 12.95Seconds 56624.92Kbytes/sec. 200 PORT command successful 150 Connecting to port 1265 226-File successfully transferred 226 15.400 seconds (measured here), 45.23 Mbytes per second ftp: 730316800 bytes sent in 15.38Seconds 47500.28Kbytes/sec. But (all I can offer is packet dumps/traces or bandwidth measurements): Incoming: Outgoing: Curr: 0.00 MByte/s Curr: 0.07 MByte/s Avg: 0.00 MByte/s Avg: 0.07 MByte/s Min: 0.00 MByte/s Min: 0.07 MByte/s Max: 0.00 MByte/s Max: 0.07 MByte/s Ttl: 1898.08 MByte Ttl: 2954.92 MByte LOCAL <-> REMOTE TXBPS RXBPS TOTALBPS (IP) PORT PROTO (IP) PORT TX RX TOTAL linuxbox <-> p4w.internal.lan 546k/s 4.74k/s 551k/s 192.168.0.1 445TCP 192.168.0.212596.88m106k 6.99m Why do I get such poor performance when trying to retrieve a file off the Linux box? This is a very strange problem. Linux: $ netstat -i Kernel Interface table Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVRTX-OK TX-ERR TX-DRP TX-OVR Flg eth0 1500 0 14049682 0 0 0 11354070 0 0 0 BMRU lo16436 0 45335 0 0 045335 0 0 0 LRU Windows: netstat -s IPv4 Statistics Packets Received = 5053597 Received Header Errors = 0 Received Address Errors= 19 Datagrams Forwarded= 0 Unknown Protocols Received = 0 Received Packets Discarded = 2 Received Packets Delivered = 5053595 Output Requests= 3655144 Routing Discards = 0 Discarded Output Packets = 0 Output Packet No Route = 0 Reassembly Required= 0 Reassembly Successful = 0 Reassembly Failures= 0 Datagrams Successfully Fragmented = 0 Datagrams Failing Fragmentation= 3 Fragments Created = 0 ICMPv4 Statistics ReceivedSent Messages 47 24 Errors0 0 Destination Unreachable 25 2 Time Exceeded 0 0 Parameter Problems0 0 Source Quenches 0 0 Redirects 0 0 Echos 0 22 Echo Replies 22 0 Timestamps0 0 Timestamp Replies 0 0 Address Masks 0 0 Address Mask Replies 0 0 TCP Statistics for IPv4 Active Opens= 204 Passive Opens = 14 Failed Connection Attempts = 16 Reset Connections = 59 Current Connections = 3 Segments
Re: Bonnie++ with 1024k stripe SW/RAID5 causes kernel to goto D-state
Justin Piszcz wrote: Kernel: 2.6.23-rc8 (older kernels do this as well) When running the following command: /usr/bin/time /usr/sbin/bonnie++ -d /x/test -s 16384 -m p34 -n 16:10:16:64 It hangs unless I increase various parameters md/raid such as the stripe_cache_size etc.. # ps auxww | grep D USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND root 276 0.0 0.0 0 0 ?D12:14 0:00 [pdflush] root 277 0.0 0.0 0 0 ?D12:14 0:00 [pdflush] root 1639 0.0 0.0 0 0 ?D< 12:14 0:00 [xfsbufd] root 1767 0.0 0.0 8100 420 ?Ds 12:14 0:00 root 2895 0.0 0.0 5916 632 ?Ds 12:15 0:00 /sbin/syslogd -r See the bottom for more details. Is this normal? Does md only work without tuning up to a certain stripe size? I use a RAID 5 with 1024k stripe which works fine with many optimizations, but if I just boot the system and run bonnie++ on it without applying the optimizations, it will hang in d-state. When I run the optimizations, then it exits out of D-state, pretty weird? Not at all. 1024k stripes are way outside the norm. If you do something way outside the norm, and don't tune for it in advance, don't be terribly surprised when something like bonnie++ brings your box to its knees. That's not to say we couldn't make md auto-tune itself more intelligently, but this isn't really a bug. With a sufficiently huge amount of RAM, you'd be able to dynamically allocate the buffers that you're not pre-allocating with stripe_cache_size, but bonnie++ is eating that up in this case. -- 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: [PATCH] CodingStyle: Printing numbers in parentheses is fine
On Sat, 29 Sep 2007 03:51:56 -0700 Andrew Morton wrote: > On Sat, 29 Sep 2007 12:25:30 +0200 Jean Delvare <[EMAIL PROTECTED]> wrote: > > > Remove a not particularly relevant rule from CodingStyle. > > Sometimes, printing numbers in parentheses doesn't add value, but in > > some (most?) cases it makes the message easier to read. As a matter of > > fact, this practice is widely used in the kernel: > > > > linux-2.6.23-rc8$ quilt grep -I '(%l*[du])' | wc -l > > 3166 > > linux-2.6.23-rc8$ > > > > Signed-off-by: Jean Delvare <[EMAIL PROTECTED]> > > --- > > Documentation/CodingStyle |2 -- > > 1 file changed, 2 deletions(-) > > > > --- linux-2.6.23-rc8.orig/Documentation/CodingStyle 2007-07-23 > > 16:44:32.0 +0200 > > +++ linux-2.6.23-rc8/Documentation/CodingStyle 2007-09-28 > > 23:53:23.0 +0200 > > @@ -638,8 +638,6 @@ concise, clear, and unambiguous. > > > > Kernel messages do not have to be terminated with a period. > > > > -Printing numbers in parentheses (%d) adds no value and should be avoided. > > - > > There are a number of driver model diagnostic macros in > > which you should use to make sure messages are matched to the right device > > and driver, and are tagged with the right level: dev_err(), dev_warn(), > > I wonder how that got there. http://linux.bkbits.net:8080/linux-2.6/?PAGE=cset=4034429a6JsOCMNXT3tTPAX1kX40bg Let's kill it, please. (i.e., ACK) --- ~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: [PATCH 1/3] CodingStyle updates
On Sat, Sep 29, 2007 at 11:01:29AM -0700, Randy Dunlap wrote: > On Fri, 28 Sep 2007 17:32:00 -0400 Erez Zadok wrote: > > > 1. Updates chapter 13 (printing kernel messages) to expand on the use of > >pr_debug()/pr_info(), what to avoid, and how to hook your debug code with > >kernel.h. > > > > Signed-off-by: Erez Zadok <[EMAIL PROTECTED]> > > --- > > Documentation/CodingStyle | 88 > > +++- > > 1 files changed, 86 insertions(+), 2 deletions(-) > > > > diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle > > index 7f1730f..00b29e4 100644 > > --- a/Documentation/CodingStyle > > +++ b/Documentation/CodingStyle > > @@ -643,8 +643,26 @@ Printing numbers in parentheses (%d) adds no value and > > should be avoided. > > There are a number of driver model diagnostic macros in > > which you should use to make sure messages are matched to the right device > > and driver, and are tagged with the right level: dev_err(), dev_warn(), > > -dev_info(), and so forth. For messages that aren't associated with a > > -particular device, defines pr_debug() and pr_info(). > > +dev_info(), and so forth. > > + > > +A number of people often like to define their own debugging printf's, > > +wrapping printk's in #ifdef's that get turned on only when subsystem > > +debugging is compiled in (e.g., dprintk, Dprintk, DPRINTK, etc.). Please > > +don't reinvent the wheel but use existing mechanisms. For messages that > > +aren't associated with a particular device, defines > > +pr_debug() and pr_info(); the latter two translate to printk(KERN_DEBUG) > > and > > +printk(KERN_INFO), respectively. However, to get pr_debug() to actually > > +emit the message, you'll need to turn on DEBUG in your code, which can be > > +done as follows in your subsystem Makefile: > > + > > +ifeq ($(CONFIG_WHATEVER_DEBUG),y) > > +EXTRA_CFLAGS += -DDEBUG > > +endif The abvoe hurst my eyes each time I see it. Lately I have considered extending the kbuild syntax a bit. Introducing ccflags-y asflags-y [with same functionality as the EXTRA_CFLAGS, EXTRA_AFLAGS] would allow us to do: ccflags-$(CONFIG_WHATEVER_DEBUG) := -DDEBUG Much nicer IMHO. 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/
Re: [PATCH] 0/3 coding standards documentation/code updates
On Fri, 28 Sep 2007, Erez Zadok wrote: > > Documentation/CodingStyle | 88 > +- I'm not very happy with this. "CodingStyle" should be about the big issues, not about details. Yes, we've messed that up over the years, but let's not continue that. In other words, I'd suggest *removing* lines from CodingStyle, not adding them. The file has already gone from a "good general principles" to "lots of stupid details". Let's not make it worse. Linus - 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: regression in 2.6.23-rc8 - power off failed
Hi Peter, On Sat, Sep 29, 2007 at 11:35:53AM +0200, Wolfgang Erig wrote: > > I start again with a fresh tree and better controlled experiments. now the result of bisection seems to be consistent. The last good commit is f2d98ae63dc64dedb00499289e13a50677f771f9 Linker script for the new x86 setup code The first bad commit (no power off) is 4fd06960f120e02e9abc802a09f9511c400042a5 Use the new x86 setup code for i386 Now I try the things written in http://marc.info/[EMAIL PROTECTED] Wolfgang - 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/1] Kernel compile bug in 2.6.22.6/7 {maybe more} ARM/StrongARM
On Wed, Sep 26, 2007 at 04:53:14PM -0400, Dave Jones wrote: > Following up on this from yesterday, Linus please revert the above cset. > It doesn't seem to be necessary (it was added to fix a miscompile in > 'make allnoconfig' which doesn't seem to be repeatable with it reverted) > and actively breaks the ARM SA1100 framebuffer driver. > > (If you'd prefer a patch reverting it, I'll send one, but I'm > hoping that git-revert will just dtrt). Dave, Thanks for checking this out on x86, and getting it reverted. -- 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: [PATCH 1/3] CodingStyle updates
On Fri, 28 Sep 2007 17:32:00 -0400 Erez Zadok wrote: > 1. Updates chapter 13 (printing kernel messages) to expand on the use of >pr_debug()/pr_info(), what to avoid, and how to hook your debug code with >kernel.h. > > Signed-off-by: Erez Zadok <[EMAIL PROTECTED]> > --- > Documentation/CodingStyle | 88 +++- > 1 files changed, 86 insertions(+), 2 deletions(-) > > diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle > index 7f1730f..00b29e4 100644 > --- a/Documentation/CodingStyle > +++ b/Documentation/CodingStyle > @@ -643,8 +643,26 @@ Printing numbers in parentheses (%d) adds no value and > should be avoided. > There are a number of driver model diagnostic macros in > which you should use to make sure messages are matched to the right device > and driver, and are tagged with the right level: dev_err(), dev_warn(), > -dev_info(), and so forth. For messages that aren't associated with a > -particular device, defines pr_debug() and pr_info(). > +dev_info(), and so forth. > + > +A number of people often like to define their own debugging printf's, > +wrapping printk's in #ifdef's that get turned on only when subsystem > +debugging is compiled in (e.g., dprintk, Dprintk, DPRINTK, etc.). Please > +don't reinvent the wheel but use existing mechanisms. For messages that > +aren't associated with a particular device, defines > +pr_debug() and pr_info(); the latter two translate to printk(KERN_DEBUG) and > +printk(KERN_INFO), respectively. However, to get pr_debug() to actually > +emit the message, you'll need to turn on DEBUG in your code, which can be > +done as follows in your subsystem Makefile: > + > +ifeq ($(CONFIG_WHATEVER_DEBUG),y) > +EXTRA_CFLAGS += -DDEBUG > +endif Alternatively, that can be done in your source file, but doing this in the Makefile makes good sense if you have more than one source file. At any rate, it is done in some source files, and when it's done in source files, #define-ing DEBUG should be done before #include so that the macros are defined as expected. > +In this way, you can create a Kconfig parameter to turn on debugging at > +compile time, which will also turn on DEBUG, to enable pr_debug() to emit > +actual messages; conversely, when CONFIG_WHATEVER_DEBUG is off, DEBUG is > +off, and pr_debug() will display nothing. > > Coming up with good debugging messages can be quite a challenge; and once > you have them, they can be a huge help for remote troubleshooting. Such --- ~Randy Phaedrus says that Quality is about caring. - 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.23-rc8 - Hangcheck on resume from x2mem
I find this in dmesg after resume from s2mem: Hangcheck: hangcheck value past margin! System: ASUS P5LD2-VM board, Intel 6600 CPU at 2.40 GHz (no o/c) 2GB RAM, 3x320GB SATA sw RAID-5. FC6 distribution, fully updated, suspend via "system" menu pulldown. Just in case this is of interest, the resume and suspend work without suspend2 patching, although since it's a server and has mains power it's only of interest for testing. USB backup devices were *not* connected. -- Bill Davidsen He was a full-time professional cat, not some moonlighting ferret or weasel. He knew about these things. - 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] fix console change race exposed by CFS
From: Jan Lübbe <[EMAIL PROTECTED]>
The new behaviour of CFS exposes a race which occurs if a switch is
requested when vt_mode.mode is VT_PROCESS.
The process with vc->vt_pid is signaled before vc->vt_newvt is set. This
causes the switch to fail when triggered by the monitoing process
because the target is still -1.
Signed-off-by: Jan Lübbe <[EMAIL PROTECTED]>
---
Index: linux-2.6.22/drivers/char/vt_ioctl.c
===
--- linux-2.6.22.orig/drivers/char/vt_ioctl.c
+++ linux-2.6.22/drivers/char/vt_ioctl.c
@@ -1208,15 +1208,18 @@
/*
* Send the signal as privileged - kill_pid() will
* tell us if the process has gone or something else
-* is awry
+* is awry.
+*
+* We need to set vt_newvt *before* sending the signal or we
+* have a race.
*/
+ vc->vt_newvt = new_vc->vc_num;
if (kill_pid(vc->vt_pid, vc->vt_mode.relsig, 1) == 0) {
/*
* It worked. Mark the vt to switch to and
* return. The process needs to send us a
* VT_RELDISP ioctl to complete the switch.
*/
- vc->vt_newvt = new_vc->vc_num;
return;
}
-
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] module: return error when mod_sysfs_init() failed
On Sun, Sep 30, 2007 at 12:37:10AM +0900, Akinobu Mita wrote: > 2007/9/29, Greg KH <[EMAIL PROTECTED]>: > > > Index: 2.6-git/kernel/module.c > > > === > > > --- 2.6-git.orig/kernel/module.c > > > +++ 2.6-git/kernel/module.c > > > @@ -1782,7 +1782,8 @@ static struct module *load_module(void _ > > > module_unload_init(mod); > > > > > > /* Initialize kobject, so we can reference it. */ > > > - if (mod_sysfs_init(mod) != 0) > > > + err = mod_sysfs_init(mod); > > > + if (err) > > > goto cleanup; > > > > I must be still asleep this morning, but I think this patch does the > > exact same thing as the original code does, right? Otherwise, this > > code would always be failing. > > > > Or do I just need to go get my morning coffee to wake up and see the > > problem here? > > Hello, > > In the original code, the "err" is zero before goto cleanup. > This "err" will be the return value of load_module(). Ah, ok, that makes sense now, thanks. It was the error not getting returned, it was not the fact that we were incorrectly checking the return value of mod_sysfs_init. thanks for clearing this up. 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] CodingStyle: Printing numbers in parentheses is fine
> > -Printing numbers in parentheses (%d) adds no value and should be avoided. > > I wonder how that got there. Well, the only place that numbers "naturally" appear wrapped in parenthesis is tables of credits and debits... as a debit, sort of a literal "add no value" situation. ;) Oh, and for footnotes, in typographically challenged contexts. Me, I agree that numbers in parens don't usually make sense for kernel messages. - 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: getting FUSD compiled with current kernels
On Sat, Sep 29, 2007 at 06:37:51PM +0200, Florian Schmidt wrote: > On Saturday 29 September 2007, Florian Schmidt wrote: > > On Saturday 29 September 2007, Florian Schmidt wrote: > > > Hi, > > > > > > I'm trying to build FUSD [1] against current kernels [2.6.22]. I get > > > errors [2]: > > > > Oh i forgot to show the code snippets in question. I put them to the > > Oh and i also forget to mention that i get the same errors when using: > > KDIR=/usr/src/linux-source-2.6.22/ make > > [Where the ubuntu kernel package put the source. I configured it with the > default ubuntu .config and make oldconfig]. I get one more message though: > > ~/source/build_stuff/fusd/kfusd$ KDIR=/usr/src/linux-source-2.6.22/ make > make -C /usr/src/linux-source-2.6.22/ > SUBDIRS=/home/tapas/source/build_stuff/fusd/kfusd > EXTRA_CFLAGS=-I/home/tapas/source/build_stuff/fusd/kfusd/../include modules > make[1]: Entering directory `/usr/src/linux-source-2.6.22' > > WARNING: Symbol version dump /usr/src/linux-source-2.6.22/Module.symvers >is missing; modules will have no dependencies and modversions. This is because you build using a kernel with a non-complete build. Maybe ubuntu locate output files somewhere else? If thats the case use: export KBUILD_OUTPUT=dir make to tell kbuild where to find the output files for the kernel source. 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/
Bonnie++ with 1024k stripe SW/RAID5 causes kernel to goto D-state
Kernel: 2.6.23-rc8 (older kernels do this as well) When running the following command: /usr/bin/time /usr/sbin/bonnie++ -d /x/test -s 16384 -m p34 -n 16:10:16:64 It hangs unless I increase various parameters md/raid such as the stripe_cache_size etc.. # ps auxww | grep D USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND root 276 0.0 0.0 0 0 ?D12:14 0:00 [pdflush] root 277 0.0 0.0 0 0 ?D12:14 0:00 [pdflush] root 1639 0.0 0.0 0 0 ?D< 12:14 0:00 [xfsbufd] root 1767 0.0 0.0 8100 420 ?Ds 12:14 0:00 root 2895 0.0 0.0 5916 632 ?Ds 12:15 0:00 /sbin/syslogd -r See the bottom for more details. Is this normal? Does md only work without tuning up to a certain stripe size? I use a RAID 5 with 1024k stripe which works fine with many optimizations, but if I just boot the system and run bonnie++ on it without applying the optimizations, it will hang in d-state. When I run the optimizations, then it exits out of D-state, pretty weird? (again, without this, bonnie++ will hang in d-state.. until this is run) Optimization script: #!/bin/bash # source profile . /etc/profile # Tell user what's going on. echo "Optimizing RAID Arrays..." # Define DISKS. cd /sys/block DISKS=$(/bin/ls -1d sd[a-z]) # This step must come first. # See: http://www.3ware.com/KB/article.aspx?id=11050 echo "Setting max_sectors_kb to 128 KiB" for i in $DISKS do echo "Setting /dev/$i to 128 KiB..." echo 128 > /sys/block/"$i"/queue/max_sectors_kb done # This step comes next. echo "Setting nr_requests to 512 KiB" for i in $DISKS do echo "Setting /dev/$i to 512K KiB" echo 512 > /sys/block/"$i"/queue/nr_requests done # Set read-ahead. echo "Setting read-ahead to 64 MiB for /dev/md3" blockdev --setra 65536 /dev/md3 # Set stripe-cache_size for RAID5. echo "Setting stripe_cache_size to 16 MiB for /dev/md3" echo 16384 > /sys/block/md3/md/stripe_cache_size # Set minimum and maximum raid rebuild speed to 30MB/s. echo "Setting minimum and maximum resync speed to 30 MiB/s..." echo 3 > /sys/block/md0/md/sync_speed_min echo 3 > /sys/block/md0/md/sync_speed_max echo 3 > /sys/block/md1/md/sync_speed_min echo 3 > /sys/block/md1/md/sync_speed_max echo 3 > /sys/block/md2/md/sync_speed_min echo 3 > /sys/block/md2/md/sync_speed_max echo 3 > /sys/block/md3/md/sync_speed_min echo 3 > /sys/block/md3/md/sync_speed_max # Disable NCQ on all disks. echo "Disabling NCQ on all disks..." for i in $DISKS do echo "Disabling NCQ on $i" echo 1 > /sys/block/"$i"/device/queue_depth done -- Once this runs, everything works fine again. -- # mdadm -D /dev/md3 /dev/md3: Version : 00.90.03 Creation Time : Wed Aug 22 10:38:53 2007 Raid Level : raid5 Array Size : 1318680576 (1257.59 GiB 1350.33 GB) Used Dev Size : 146520064 (139.73 GiB 150.04 GB) Raid Devices : 10 Total Devices : 10 Preferred Minor : 3 Persistence : Superblock is persistent Update Time : Sat Sep 29 13:05:15 2007 State : active, resyncing Active Devices : 10 Working Devices : 10 Failed Devices : 0 Spare Devices : 0 Layout : left-symmetric Chunk Size : 1024K Rebuild Status : 8% complete UUID : e37a12d1:1b0b989a:083fb634:68e9eb49 (local to host p34.internal.lan) Events : 0.4211 Number Major Minor RaidDevice State 0 8 330 active sync /dev/sdc1 1 8 491 active sync /dev/sdd1 2 8 652 active sync /dev/sde1 3 8 813 active sync /dev/sdf1 4 8 974 active sync /dev/sdg1 5 8 1135 active sync /dev/sdh1 6 8 1296 active sync /dev/sdi1 7 8 1457 active sync /dev/sdj1 8 8 1618 active sync /dev/sdk1 9 8 1779 active sync /dev/sdl1 -- NOTE: This bug is reproducible every time: Example: $ /usr/bin/time /usr/sbin/bonnie++ -d /x/test -s 16384 -m p34 -n 16:10:16:64 Writing with putc()... It writes for 4-5 minutes and then.. SILENCE + D-STATE, I was too late this time :( $ ps auxww | grep D USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND root 276 1.2 0.0 0 0 ?D12:50 0:03 [pdflush] root 2901 0.0 0.0 5916 632 ?Ds 12:50 0:00 /sbin/syslogd - r user 4571 48.0 0.0 11644 1084 pts/1D+ 12:51 1:55 /usr/sbin/bonn ie++ -d /x/test -s 16384 -m p34 -n 16:10:16:64 root 4612 1.0 0.0 0 0 ?D12:52 0:01 [pdflush] root 4624 5.0 0.0 40964 7436 ?D12:55 0:00 /usr/bin/perl - w /app/rrd-cputemp/bin/rrd_cputemp.pl root 4684 0.0 0.0 31968 1416 ?
Re: [patch 0/2] suspend/resume regression fixes
Mark Lord wrote: Linus Torvalds wrote: On Sat, 22 Sep 2007, Thomas Gleixner wrote: My final enlightment was, when I removed the ACPI processor module, which controls the lower idle C-states, right before resume; this worked fine all the time even without all the workaround hacks. I really hope that this two patches finally set an end to the "jinxed VAIO heisenbug series", which started when we removed the periodic tick with the clockevents/dyntick patches. Ok, so the patches look fine, but I somehow have this slight feeling that you gave up a bit too soon on the "*why* does this happen?" question. On a closely related note: I just now submitted a patch to fix SMP-poweroff, by having it do disable_nonboot_cpus before doing poweroff. Which has led me to thinking.. ..are similar precautions perhaps necessary for *all* ACPI BIOS calls? Because one never knows what the other CPUs are doing at the same time, and what the side effects may be on the ACPI BIOS functions. And also, I wonder if at a minimum we should be guaranteeing ACPI BIOS calls only ever happen from CPU#0 (or the "boot" CPU)? Or do we do that already? Boot CPU, and AFAIK suspend is the only place which does it. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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.22.6 + oprofile oops
On Sat, Sep 22, 2007 at 14:23:35 +0300, Sami Farin wrote: > x86_64 SMP kernel v2.6.22.6 (not using callgraph). > sometimes oprofile works for a longer time... but not this time. > > 2007-09-22 13:53:32.52723 <1>[ 3372.390188] Unable to handle kernel NULL > pointer dereference at 0650 RIP: > 2007-09-22 13:53:32.527245948 <1>[ 3372.390195] [] > _spin_lock+0x4/0x20 > 2007-09-22 13:53:32.527247694 <4>[ 3372.390211] PGD 13a6c067 PUD 3ad91067 PMD > 0 > 2007-09-22 13:53:32.527249371 <0>[ 3372.390216] Oops: 0002 [1] SMP > 2007-09-22 13:53:32.527250837 <4>[ 3372.390220] CPU 0 > 2007-09-22 13:53:32.527252304 <4>[ 3372.390227] ... > 2007-09-22 13:53:32.527385634 <4>[ 3372.390442] Call Trace: > 2007-09-22 13:53:32.527390314 <4>[ 3372.390457] [] > get_task_mm+0x18/0x60 > 2007-09-22 13:53:32.527391990 <4>[ 3372.390484] [] > :oprofile:sync_buffer+0xf4/0x480 > 2007-09-22 13:53:32.527393666 <4>[ 3372.390544] [] > :oprofile:wq_sync_buffer+0x0/0x60 > 2007-09-22 13:53:32.527399673 <4>[ 3372.390576] [] > :oprofile:wq_sync_buffer+0x33/0x60 > 2007-09-22 13:53:32.527401419 <4>[ 3372.390602] [] > run_workqueue+0xcd/0x170 > 2007-09-22 13:53:32.527406238 <4>[ 3372.390635] [] > worker_thread+0xb3/0x120 > 2007-09-22 13:53:32.527421324 <4>[ 3372.390652] [] > autoremove_wake_function+0x0/0x40 > 2007-09-22 13:53:32.527423140 <4>[ 3372.390684] [] > worker_thread+0x0/0x120 > 2007-09-22 13:53:32.527424816 <4>[ 3372.390697] [] > kthread+0x4d/0x80 > 2007-09-22 13:53:32.527426423 <4>[ 3372.390730] [] > child_rip+0xa/0x12 > 2007-09-22 13:53:32.527428099 <4>[ 3372.390810] [] > kthread+0x0/0x80 > 2007-09-22 13:53:32.527444931 <4>[ 3372.390822] [] > child_rip+0x0/0x12 This is easy to trigger with "ping -f 127.0.0.1" (as root). Oopses inside 0.1s. If you can't reproduce, try more events and/or smaller sample count. May I suggest something: if system is too slow to process events, find out which event is triggering too often, double the sample count for it, reset all counters, and log an informative kernel message. If that's why it's crashing... if it's some other reason, tough luck :) > 2007-09-22 13:53:32.527446817 <4>[ 3372.390844] > 2007-09-22 13:53:32.527448144 <4>[ 3372.390846] > 2007-09-22 13:53:32.527449541 <4>[ 3372.390846] Code: f0 ff 0f 79 09 f3 90 83 > 3f 00 7e f9 eb f2 c9 c3 66 66 66 2e > 2007-09-22 13:53:32.527455757 <1>[ 3372.390866] RIP [] > _spin_lock+0x4/0x20 > 2007-09-22 13:53:32.527457433 <4>[ 3372.390876] RSP > 2007-09-22 13:53:32.527463090 <0>[ 3372.390878] CR2: 0650 > > BTW. does somebody have callgraph working on x86_64 with oprofile? > I get instant freeze and I need to power cycle system... (callgraph worked on > IA-32) -- Do what you love because life is too short for anything else. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] paravirt_ops: refactor struct paravirt_ops into smaller pv_*_ops
Nakajima, Jun wrote:
> To me such atomicity is provided by the "sti" instruction (i.e. the
> processor begins responding to external, maskable interrupts _after_ the
> next instruction is executed), and there is nothing special with that
> combination "sti; hlt" (you can also have like "sti; ret", for example).
>
Sure, but there's no particular value in "sti; ret". While the sti mask
window works everywhere, its only cases like "sti; hlt" where it's
needed to avoid a race condition.
> So if you define a PV ops like STI(next_instruction), "safe_halt" for
> the native should be defined as STI("hlt"), and inlined as "sti; hlt".
>
That's only meaningful if the pv_op is implemented directly in x86
instructions - ie, the native (or almost native) case.
> If it's hard or we don't need to expose the semantics of "sti" other
> than that, I think it's okay to have a PV operation for safe_halt.
>
Yeah, the general form would be hard to support for a hypervisor. Xen,
for example, has an "atomically enable events and block" operation, but
no other "atomically enable events and do X" operations.
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH RFC] paravirt_ops: refactor struct paravirt_ops into smaller pv_*_ops
Jeremy Fitzhardinge wrote:
> Nakajima, Jun wrote:
> > Yes. For the native, "safe_halt" is "sti; hlt". The "native_halt" is
> > just "hlt". So the para_virt part of "hlt" could be moved to
pv_cpu_ops,
> > and the "sti" part stays in pv_irq_ops.
> >
>
> By "sti part", you mean the full "sti; hlt" sequence of safe_halt,
> right? Since it needs to be an atomic sequence to avoid race
> conditions, so the native sequence has to be precisely "sti; hlt" to
> take advantage of the sti shadow, and other pv-backends will need
their
> own way to guarantee this atomicity.
To me such atomicity is provided by the "sti" instruction (i.e. the
processor begins responding to external, maskable interrupts _after_ the
next instruction is executed), and there is nothing special with that
combination "sti; hlt" (you can also have like "sti; ret", for example).
So if you define a PV ops like STI(next_instruction), "safe_halt" for
the native should be defined as STI("hlt"), and inlined as "sti; hlt".
If it's hard or we don't need to expose the semantics of "sti" other
than that, I think it's okay to have a PV operation for safe_halt.
Jun
---
Intel Open Source Technology Center
-
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/backport] CFS scheduler, -v22, for v2.6.23-rc8, v2.6.22.8, v2.6.21.7, v2.6.20.20
El Fri, 28 Sep 2007 23:20:13 -0300 Henrique de Moraes Holschuh <[EMAIL PROTECTED]> escribió: > On Fri, 28 Sep 2007, Alejandro Riveira Fernández wrote: > > I feel it better than 20.5 but the later is more stable. Let me explain. > > > > I patched a 2.6.22.9 kernel with both versions 22 and 20.5[1]. With the 22 > > version if i lock the screen (run screensaver) or i try to run a wine > > program > > i experience a hard lock up no keyboard or mouse and i have to reboot the > > machine (i can not try to access it via ssh because i do not have a second > > machine). > Thanks for the response :D > I have seen that twice with v20.5 under 2.6.22.7/.8. Didn't see it yet with > v22. xterm would get pissed if I tried to "secure keyboard", so something > stole the keyboard focus and wouldn't give it back to xorg. Maybe a locking > bug in xorg somewhere? > > Anyway, my kernel is NOT tainted, so rest assured that at least this one is > not nVidia's fault. > > BTW, v20.5 in 2.6.21.7 would sometimes cause dmcrypt to oops when first > mounting a LUKS volume if there was some non-extra-light disk activity going > on. Probably something missing in the backport to 2.6.21... > > Sorry, days down here have been very busy, so I didn't have time to send a > proper bug report. I can add another data point 2.6.23-rc8-cfs-v22-g1bef7dc0-dirty does not have any problem with wine or xscreensaver is working fine. Again i use nvidia and a 3 party gpl driver for my wifi rt2500 which have compiled fine with the new kernel (surprise surprise!) If you need any more info just ask. Thanks P.S: I use ubuntu feisty fwiw -- Nunca discutas con un idiota. Al final te hacen rebajarte a su nivel y entonces te acaban ganando debido a su mayor experiencia. - 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: getting FUSD compiled with current kernels
On Saturday 29 September 2007, Florian Schmidt wrote: > On Saturday 29 September 2007, Florian Schmidt wrote: > > Hi, > > > > I'm trying to build FUSD [1] against current kernels [2.6.22]. I get > > errors [2]: > > Oh i forgot to show the code snippets in question. I put them to the Oh and i also forget to mention that i get the same errors when using: KDIR=/usr/src/linux-source-2.6.22/ make [Where the ubuntu kernel package put the source. I configured it with the default ubuntu .config and make oldconfig]. I get one more message though: ~/source/build_stuff/fusd/kfusd$ KDIR=/usr/src/linux-source-2.6.22/ make make -C /usr/src/linux-source-2.6.22/ SUBDIRS=/home/tapas/source/build_stuff/fusd/kfusd EXTRA_CFLAGS=-I/home/tapas/source/build_stuff/fusd/kfusd/../include modules make[1]: Entering directory `/usr/src/linux-source-2.6.22' WARNING: Symbol version dump /usr/src/linux-source-2.6.22/Module.symvers is missing; modules will have no dependencies and modversions. CC [M] /home/tapas/source/build_stuff/fusd/kfusd/kfusd.o /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c: In function ‘to_kobj’: /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:135: error: dereferencing pointer to incomplete type [...] Regards, Flo -- Palimm Palimm! http://tapas.affenbande.org - 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: getting FUSD compiled with current kernels
On Saturday 29 September 2007, Florian Schmidt wrote:
> Hi,
>
> I'm trying to build FUSD [1] against current kernels [2.6.22]. I get errors
> [2]:
Oh i forgot to show the code snippets in question. I put them to the
crresponding error below [matching line number is marked with [*]]:
>
> [2] ~/source/build_stuff/fusd$ make
> make -C libfusd
> make[1]: Entering directory `/home/tapas/source/build_stuff/fusd/libfusd'
> make[1]: Nothing to be done for `default'.
> make[1]: Leaving directory `/home/tapas/source/build_stuff/fusd/libfusd'
> make -C kfusd
> make[1]: Entering directory `/home/tapas/source/build_stuff/fusd/kfusd'
> make -C /lib/modules/2.6.22-11-generic/build
> SUBDIRS=/home/tapas/source/build_st
> uff/fusd/kfusd
> EXTRA_CFLAGS=-I/home/tapas/source/build_stuff/fusd/kfusd/../inclu
> de modules
> make[2]: Entering directory `/usr/src/linux-headers-2.6.22-11-generic'
> CC [M] /home/tapas/source/build_stuff/fusd/kfusd/kfusd.o
> /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c: In function ‘to_kobj’:
> /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:135: error: dereferencing
> poin
> ter to incomplete type
static inline struct kobject * to_kobj(struct dentry * dentry)
{
struct sysfs_dirent * sd = dentry->d_fsdata;
if(sd)
return ((struct kobject *) sd->s_element); [*]
else
return NULL;
}
> /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c: In
> function ‘fusd_register_de
> vice’:
> /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:2049: error: ‘struct
> kset’ has
> no member named ‘kset’
[...]
if(classdir2){
// jackpot. extract the class.
struct kobject *ko = to_kobj(classdir2);
sys_class = (ko?to_class(ko):NULL); [*]
if(!sys_class)
RDEBUG(2, "WARNING: sysfs entry for %s has no kobject!
\n",register_msg.clazz);
}
[...]
> /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:2049: warning: type
> defaults t
> o ‘int’ in declaration of ‘__mptr’
> /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:2049: warning:
> initialization
>
> >from incompatible pointer type
>
> /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:2049: error: ‘struct
> kset’ has
> no member named ‘kset’
> /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c: At top level:
> /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:2603: error: unknown
> field ‘wr
> itev’ specified in initializer
STATIC struct file_operations fusd_fops = {
owner:THIS_MODULE,
open: fusd_open,
read: fusd_read,
write:fusd_write,
writev: fusd_writev, [*]
release: fusd_release,
poll: fusd_poll,
};
> /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:2603: warning:
> initialization
>
> >from incompatible pointer type
>
> make[3]: *** [/home/tapas/source/build_stuff/fusd/kfusd/kfusd.o] Error 1
> make[2]: *** [_module_/home/tapas/source/build_stuff/fusd/kfusd] Error 2
> make[2]: Leaving directory `/usr/src/linux-headers-2.6.22-11-generic'
> make[1]: *** [default] Error 2
> make[1]: Leaving directory `/home/tapas/source/build_stuff/fusd/kfusd'
> make: *** [default] Error 2
>
> [3] http://fort.xdas.com/~kor/oss2jack/
--
Palimm Palimm!
http://tapas.affenbande.org
-
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/
getting FUSD compiled with current kernels
Hi, I'm trying to build FUSD [1] against current kernels [2.6.22]. I get errors [2]: I tried looking into it but not being a kernel hacker i must admit i didn't even find out where sysfs_dentry is defined (so i can make the type complete). Or whether this would even be the correct way to fix it.. My goal is to hack up oss2jack [3] to use ALSA pcm devices.. And a later goal is to create a virtual ALSA soundcard [which would multiplex access to a real non hw-mixing capable soundcard] to finally end the dmix software mixing woes linux users have to endure for the last years :) I don't expect you to fix it for me. I would just be glad about infos on where to get more infos enabling me to fix this :) Of course the more concise and practical the advice the better :) Regards, Flo [1] http://svn.xiph.org/trunk/fusd [2] ~/source/build_stuff/fusd$ make make -C libfusd make[1]: Entering directory `/home/tapas/source/build_stuff/fusd/libfusd' make[1]: Nothing to be done for `default'. make[1]: Leaving directory `/home/tapas/source/build_stuff/fusd/libfusd' make -C kfusd make[1]: Entering directory `/home/tapas/source/build_stuff/fusd/kfusd' make -C /lib/modules/2.6.22-11-generic/build SUBDIRS=/home/tapas/source/build_st uff/fusd/kfusd EXTRA_CFLAGS=-I/home/tapas/source/build_stuff/fusd/kfusd/../inclu de modules make[2]: Entering directory `/usr/src/linux-headers-2.6.22-11-generic' CC [M] /home/tapas/source/build_stuff/fusd/kfusd/kfusd.o /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c: In function ‘to_kobj’: /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:135: error: dereferencing poin ter to incomplete type /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c: In function ‘fusd_register_de vice’: /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:2049: error: ‘struct kset’ has no member named ‘kset’ /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:2049: warning: type defaults t o ‘int’ in declaration of ‘__mptr’ /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:2049: warning: initialization from incompatible pointer type /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:2049: error: ‘struct kset’ has no member named ‘kset’ /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c: At top level: /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:2603: error: unknown field ‘wr itev’ specified in initializer /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:2603: warning: initialization from incompatible pointer type make[3]: *** [/home/tapas/source/build_stuff/fusd/kfusd/kfusd.o] Error 1 make[2]: *** [_module_/home/tapas/source/build_stuff/fusd/kfusd] Error 2 make[2]: Leaving directory `/usr/src/linux-headers-2.6.22-11-generic' make[1]: *** [default] Error 2 make[1]: Leaving directory `/home/tapas/source/build_stuff/fusd/kfusd' make: *** [default] Error 2 [3] http://fort.xdas.com/~kor/oss2jack/ -- Palimm Palimm! http://tapas.affenbande.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rfc][patch] i386: remove comment about barriers
On Sat, 29 Sep 2007, Nick Piggin wrote: > > OK this was going to be a quick patch, but after sleeping on it, I think > it deserves a better analysis... I can prove the comment is incorrect with a > test program, but I'm not as sure about my thinking that leads me to call it > also misleading. You're 100% right, that comment is total crap. An lfence is *not* a memory barrier, it's just a read memory barrier. Although on some microarchitectures they may of course end up being the same thing. Linus - 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] x86: improved memory barrier implementation
On Sat, 29 Sep 2007, Nick Piggin wrote: > > > > The non-temporal stores should be basically considered to be "IO", not any > > normal memory operation. > > Maybe you're thinking of uncached / WC? Non-temporal stores to cacheable > RAM apparently can go out of order too, and they are being used in the kernel > for some things. I'm really saying that people to a first approximation should think "NT is an IO (DMA) thing". Whether cached or not. Exactly because they do not honor the normal memory ordering. It may be worth noting that "clflush" falls under that heading too - even if all the actual *writes* were done with totally normal writes, if anybody does a clflush instruction, that breaks the ordering, and that turns it to "DMA ordering" again - ie we're not talking about the normal SMP ordering rules at all. So all the spinlocks and all the smp_*mb() barriers have never really done *anything* for those things (in particular, "smp_wmb()" has *always* ignored them on i386!) > Likewise for rep stos, apparently. No. As far as I can tell, the fast string operations are unordered *within*themselves*, but not wrt the operations around it. In other words, you cannot depend on the ordering of stores *in* the memcpy() or memset() when it is implemented by "rep movs/stos" - but that is 100% equivalent to the fact that you cannot depend on the ordering even when it isn't - since the "memcpy()" library routine might be copying memory backwards for all you know! The Intel memory ordering paper doesn't talk about the fast string instructions (except to say that the rules it *does* speak about do not hold), but the regular IA manuals do say (for example): "Code dependent upon sequential store ordering should not use the string operations for the entire data structure to be stored. Data and semaphores should be separated. Order dependent code should use a discrete semaphore uniquely stored to after any string operations to allow correctly ordered data to be seen by all processors." and note how it says you should just store to the semaphore. If you think about it, that semahore will be involving all the memory ordering requirements that we *already* depend on, so if a semaphore is sufficient to order the fast string instruction, then by definition using a spinlock around them must be the same thing! In other words, by Intels architecture manual, fast string instructions cannot escape a "semaphore" - but that means that they cannot escape a spinlock either (since the two are exactly the same wrt memory ordering rules! In other words, whenever the Intel docs say "semaphore", think "mutual exclusion lock", not necessarily the kernel kind of "sleeping semaphore"). But it might be good to have that explicitly mentioned in the IA memory ordering thing, so I'll ask the Intel people about that. However, I'd say that given our *current* documentation, string instructions may be *internally* out-of-order, but they would not escape a lock. > But this means they are already at odds with spin_unlock, unless they > are enclosed with mfences everywhere they are used (of which I think > most are not). So this is an existing bug in the kernel. See above. I do not believe that it's an existing bug, but the basic point that the change to "smp_rmb()" doesn't change our existing rules is true. Linus - 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/3] CodingStyle updates
A couple of comments interspersed... On 9/28/07, Erez Zadok <[EMAIL PROTECTED]> wrote: ... > There are a number of driver model diagnostic macros in > which you should use to make sure messages are matched to the right device --- I think this "which" is non-restrictive, so it should have a comma after it (I realize that's not part of your patch). It's also possible to read it as restrictive, in which case "that" would be preferable. --- > and driver, and are tagged with the right level: dev_err(), dev_warn(), > -dev_info(), and so forth. For messages that aren't associated with a > -particular device, defines pr_debug() and pr_info(). > +dev_info(), and so forth. > + > +A number of people often like to define their own debugging printf's, --- "A number of people often like to..." is awkward. How about "Developers sometimes..." or "Too many people..." --- > +wrapping printk's in #ifdef's that get turned on only when subsystem > + Chapter 19: branch prediction optimizations > + > +The kernel includes macros called likely() and unlikely(), which can be used --- You might say "The kernel provides the macros likely()..." --- > +as hints to the compiler to optimize branch prediction. They operate by ... > +A good example of this is the above kmalloc(GFP_KERNEL) call. The chances > +of kmalloc() returning NULL are rather small, because even if it doesn't > +have memory to return to you at the moment, with GFP_KERNEL/__GFP_WAIT > +passed, kmalloc() will wait and suspend your thread, while it goes off to --- The commas after "passed" and "thread" is unnecessary. --- > +find some free memory (purging caches, flushing buffers, etc.). In other > +words, kmalloc() tries very hard to give you the memory you asked for by the > +time it return. --- "...by the time it return." should be "...by the time it returns." --- > + > +Consider the next, bad example. Suppose you're developing a file system > +which performs logically different actions on different types of entities: --- This "which" is restrictive; it would be preferable to use "that" instead. --- > +files, directories, symlinks, devices, etc. and you use this code: > + ... > +be penalized heavily for going [sic] down the wrong path... Therefore, you > +should consider also whether a seemingly-rare condition is indeed rare ALL --- The hyphen isn't necessary when the first word of the compount adjective is an adverb ending in "-ly", so, just "seemingly rare"; or switch to "apparently rare". --- > +the time. ... -- scott preece - 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: Strange system hangs
On Sat, 29 Sep 2007, Nick Piggin wrote: On Friday 28 September 2007 18:42, Krzysztof Oledzki wrote: Hello, I am experiencing weird system hangs. Once about 2-5 weeks system freezes and stops accepting remote connections, so it is no longer possible to connect to most important services: smtp (postfix), www (squid) or even ssh. Such connection is accepted but then it hangs. What is strange, that previously established ssh session is usable. It is possible to work on such system until you do something stupid like "less /var/log/all.log". Using strace I found that process blocks on: Is this a regression? If so, what's the most recent kernel that didn't show the problem? I don't know. First kernel I ran was 2.6.20.x. This is quite fresh system. The symptoms could be consistent with some place doing a balance_dirty_pages while holding a lock that is required for IO, but I can't see a smoking gun (you've got contention on i_mutex, but that should be OK). Can you see if there is any memory under writeback that isn't being completed (sysrq+M), also a list the locks held after the hang might be helpful (compile in lockdep and sysrq+D) OK. I'll try to do it next time if there will be a chance. It may take some time, BTW. Is anything currently running? (sysrq+P and even a full sysrq+T task list could be useful). I'll have to check - maybe I have this captured. If not I'll check it next time. Are any IO errors occurring at all? Didn't notice - so no. Thank you. Best regards, Krzysztof Olędzki
Re: [PATCH] module: return error when mod_sysfs_init() failed
2007/9/29, Greg KH <[EMAIL PROTECTED]>:
> > Index: 2.6-git/kernel/module.c
> > ===
> > --- 2.6-git.orig/kernel/module.c
> > +++ 2.6-git/kernel/module.c
> > @@ -1782,7 +1782,8 @@ static struct module *load_module(void _
> > module_unload_init(mod);
> >
> > /* Initialize kobject, so we can reference it. */
> > - if (mod_sysfs_init(mod) != 0)
> > + err = mod_sysfs_init(mod);
> > + if (err)
> > goto cleanup;
>
> I must be still asleep this morning, but I think this patch does the
> exact same thing as the original code does, right? Otherwise, this
> code would always be failing.
>
> Or do I just need to go get my morning coffee to wake up and see the
> problem here?
Hello,
In the original code, the "err" is zero before goto cleanup.
This "err" will be the return value of load_module().
load_module() is the function which returns error as pointer
and the expression IS_ERR(NULL) is false. So the caller of load_module()
cannot catch that error.
I found this problem when I was running the fault injection test
script in Documentation/fault-injection/fault-injection.txt with
random module.
#!/bin/bash
FAILTYPE=failslab
echo Y > /debug/$FAILTYPE/task-filter
echo 10 > /debug/$FAILTYPE/probability
echo 100 > /debug/$FAILTYPE/interval
echo -1 > /debug/$FAILTYPE/times
echo 0 > /debug/$FAILTYPE/space
echo 2 > /debug/$FAILTYPE/verbose
echo 0 > /debug/$FAILTYPE/ignore-gfp-wait
faulty_system()
{
bash -c "echo 1 > /proc/self/make-it-fail && exec $*"
}
if [ $# -eq 0 ]
then
echo "Usage: $0 modulename [ modulename ... ]"
exit 1
fi
for m in $*
do
echo inserting $m...
faulty_system modprobe $m
echo removing $m...
faulty_system modprobe -r $m
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: 2.6.23-rc8-mm2
On Sat, Sep 29, 2007 at 05:37:29PM +0800, Dave Young wrote: > Hi, > The kernel report warnings about sysfs filename duplicate under > rc8-mm1 and rc8-mm2. > 1. > cut > NET: Registered protocol family 16 > ACPI: bus type pci registered > PCI: PCI BIOS revision 2.10 entry at 0xfb93e, last bus=3 > PCI: Using configuration type 1 > Setting up standard PCI resources > sysfs: duplicate filename 'usbcore' can not be created > WARNING: at fs/sysfs/dir.c:433 sysfs_add_one() > [] dump_trace+0x1bf/0x1d0 > [] show_trace_log_lvl+0x18/0x30 > [] show_trace+0xf/0x20 > [] dump_stack+0x12/0x20 > [] sysfs_add_one+0xa0/0xe0 > [] create_dir+0x48/0xb0 > [] sysfs_create_dir+0x29/0x50 > [] create_dir+0x1b/0x50 > [] kobject_add+0x46/0x150 > [] kernel_param_sysfs_setup+0x50/0xb0 > [] param_sysfs_builtin+0xee/0x130 > [] param_sysfs_init+0x24/0x60 > [] do_initcalls+0x46/0x1e0 > [] kernel_init+0x62/0xb0 > [] kernel_thread_helper+0x7/0x14 > === > kobject_add failed for usbcore with -EEXIST, don't try to register > things with the same name in the same directory. That is very wierd, do you have both USB built in and as a module somehow? > [] dump_trace+0x1bf/0x1d0 > [] show_trace_log_lvl+0x18/0x30 > [] show_trace+0xf/0x20 > [] dump_stack+0x12/0x20 > [] kobject_add+0xf6/0x150 > [] kernel_param_sysfs_setup+0x50/0xb0 > [] param_sysfs_builtin+0xee/0x130 > [] param_sysfs_init+0x24/0x60 > [] do_initcalls+0x46/0x1e0 > [] kernel_init+0x62/0xb0 > [] kernel_thread_helper+0x7/0x14 > === > Module 'usbcore' failed to be added to sysfs, error number -17 I think I need to clean up the double stack trace here, that's reall not needed :) 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: regression in 2.6.23-rc8 - power off failed
Mark Lord wrote:
Wolfgang Erig wrote:
On Sat, Sep 29, 2007 at 01:30:33AM -0700, H. Peter Anvin wrote:
Wolfgang Erig wrote:
Both are bad.
Two different systems and two different bisections.
I sent the last step of each.
$ git bisect good Bisecting: 0 revisions left to test after this
[626073132b381684c4983e0d911e9aceb32e2cbc] Assembly header and
main routine for new x86 setup code
OK, so which one is the bad one?
This problem (no power off) persists after pull some minutes ago.
Sorry for the confusion.
I believe there must have been something wrong here (possibly
inconsistent experiments?) This checkin has *zero code changes* from
the previous one (and next one) -- the kernel should have been binarily
identical to the previous one. The code introduced in this checkin
doesn't even get compiled until two checkins later,
4fd06960f120e02e9abc802a09f9511c400042a5.
I have done two bisections simultanously and it was late at night.
I start again with a fresh tree and better controlled experiments.
If this is an SMP system, then you could just be getting random results,
depending upon which CPU is attempting the poweroff.
I have a newish patch in Andrew's tree now to fix SMP poweroff
(has been broken forever), reproduced here below in case you missed it.
* * *
We need to disable all CPUs other than the boot CPU (usually 0)
before attempting to power-off modern SMP machines.
This fixes the hang-on-poweroff issue on my MythTV SMP box,
and also on Thomas Gleixner's new toybox.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
Acked-by: Thomas Gleixner <[EMAIL PROTECTED]>
---
--- linux/kernel/sys.c.orig2007-09-13 09:49:11.0 -0400
+++ linux/kernel/sys.c2007-09-28 15:48:54.0 -0400
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
@@ -878,6 +879,7 @@
kernel_shutdown_prepare(SYSTEM_POWER_OFF);
if (pm_power_off_prepare)
pm_power_off_prepare();
+disable_nonboot_cpus();
sysdev_shutdown();
printk(KERN_EMERG "Power down.\n");
machine_power_off();
-static void
-acpi_power_off (void)
-{
- printk("%s called\n",__FUNCTION__);
- /* Some SMP machines only can poweroff in boot CPU */
- set_cpus_allowed(current, cpumask_of_cpu(0));
ACPI in kernel 2.6.12 did disable non-boot cpus too in powe_off.
Later only comment was left for some reason...
Regards,
Alex.
-
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/
Chroot bug take 3
/. I hope I haven't crossed the line between determined and annoying. I thought we were done, but now I find meat still on this bone. Posit a normal process having some filesystem root, and a current working directory (pwd) lying within that root subtree. When chroot is performed, pwd is left unchanged. This means it can (and often will) lie outside of the new root. How much of the filesystem lying outside of root should a process be allowed to access? Currently it is the complete filesystem. It is perfectly reasonable for a process to execute chroot multiple times, each time pruning off access to further parts of the filesystem. What is *not reasonable* is chroot unavoidably returning access which previously had been dropped. Similarly, performing fchdir on a directory opened prior to chroot should not grant access to more of the filesystem than was accessible when the directory was opened. Although chroot can result in pwd lying outside of the new root, is must still lie within some root. A new quantity, openfdroot, will be recorded by chroot, to be used as the limit when walking dotdot outside of the current root. The initial value for openfdroot is the complete filesystem. After completing each chroot, as well as chdir, fchdir and close, openfdroot will be set to root iff all open directories and pwd lie within that root; otherwise it remains unchanged. In an ideal world a separate openfdroot would be recorded for each open directory, and another for pwd, however this is extreme. A single value permits chroot to perform its fundamental promise, namely to prune the root The following might replace the last two paragraphs in chroot(2)'s description: This call does not change the current working directory. After the call, '.' can be outside of path, thus files, accessible to the process before the call, remain accessible (via relative pathnames) afterwards. This access is intrinsicly dropped by changing directory to within the new root. This call does not close open file descriptors, and such descriptors may allow access to files outside the chroot tree. A successful open(2) on a directory outside of path yields a descriptor that can subsequently be passed to fchdir(2) to escape the new root. This will only provide access to as much of the filesystem as was accessable when the directory was opened. Closing all such files (and changing directory to within path) drops this access. Would there be any point in working up a patch? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/12] mm: trylock_page
On Fri, 2007-09-28 at 13:11 +1000, Nick Piggin wrote: > On Friday 28 September 2007 17:42, Peter Zijlstra wrote: > > Replace raw TestSetPageLocked() usage with trylock_page() > > I have such a thing queued too, for the lock bitops patches for when 2.6.24 > opens, Andrew promises me :). > > I guess they should be identical, except I don't like doing trylock_page in > place of SetPageLocked, for memory ordering performance and aesthetic > reasons... I've got an init_page_locked (or set_page_locked... I can't > remember, the patch is at home). Sure, that might work, or we could just make it so that add_to_*_cache is never passed an unlocked page. But sure... > Fine idea to lockdep the page lock, anyway. Does it show up any of the > buffered write deadlock possibilities? :) Not yet, it might just be that the concessions done to annotate this type of lock were too severe. What I basically did was treat all the page locks as a single recursive lock. > buffer lock is another notable bit-mutex that might be converted (I have > the patch to do the similar nice !tas->trylock conversion for that too). I > think it is used widely enough by tricky code that it would be useful to > annotate as well. Not at all familiar with that lock, but yeah, we could have a look at doing that too. > Unfortunately we can't convert bit_spinlock.h easily, I guess? Yeah, the space constraints make that rather hard. Each of these locks needs some form of external meta-data. For the page lock I used one lock instance per file system 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: 2.6.23-rc8-mm2 - tcp_fastretrans_alert() WARNING
Ilpo Järvinen wrote: > On Fri, 28 Sep 2007, Ilpo Järvinen wrote: >> On Fri, 28 Sep 2007, Cedric Le Goater wrote: >> >>> I just found that warning in my logs. It seems that it's been >>> happening since rc7-mm1 at least. >>> >>> WARNING: at /home/legoater/linux/2.6.23-rc8-mm2/net/ipv4/tcp_input.c:2314 >>> tcp_fastretrans_alert() >>> >>> Call Trace: >>>[] tcp_ack+0xcd6/0x1894 >>> ...snip... >> ...Thanks for the report, I'll have look what could still break >> fackets_out... > > I think this one is now clear to me, tcp_fragment/collapse adjusts > fackets_out (incorrectly) also for reno flow when there were some dupACKs > that made sacked_out != 0. Could you please try if patch below proves all > them to be of non-SACK origin... In case that's true, it's rather > harmless, I'll send a fix on Monday or so (this would anyway be needed)... > If you find out that them occur with SACK enabled flow, that would be > more interesting and requires more digging... I'm trying now to reproduce this WARNING. It seems that the n/w behaves differently during the week ends. Probably taking a break. C. - 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] module: return error when mod_sysfs_init() failed
On Sat, Sep 29, 2007 at 07:06:53PM +0900, Akinobu Mita wrote: > load_module() returns zero when mod_sysfs_init() fails, > then the module loading will succeed accidentally. > > This patch makes load_module() return error correctly in that case. > > Cc: Greg Kroah-Hartman <[EMAIL PROTECTED]> > Cc: Rusty Russell <[EMAIL PROTECTED]> > Signed-off-by: Akinobu Mita <[EMAIL PROTECTED]> > > --- > kernel/module.c |3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > Index: 2.6-git/kernel/module.c > === > --- 2.6-git.orig/kernel/module.c > +++ 2.6-git/kernel/module.c > @@ -1782,7 +1782,8 @@ static struct module *load_module(void _ > module_unload_init(mod); > > /* Initialize kobject, so we can reference it. */ > - if (mod_sysfs_init(mod) != 0) > + err = mod_sysfs_init(mod); > + if (err) > goto cleanup; I must be still asleep this morning, but I think this patch does the exact same thing as the original code does, right? Otherwise, this code would always be failing. Or do I just need to go get my morning coffee to wake up and see the problem here? 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: A unresponsive file system can hang all I/O in the system on linux-2.6.23-rc6 (dirty_thresh problem?)
On Sat, 2007-09-29 at 20:28 +0800, Fengguang Wu wrote: > On Sat, Sep 29, 2007 at 01:48:01PM +0200, Peter Zijlstra wrote: > > On the patch itself, not sure if it would have been enough. As soon as > > there is a single dirty inode on the list one would get caught in the > > same problem as before. > > That should not be a problem. Normally the few new dirty inodes will > be all cleaned in one go and there are no more dirty inodes left(at > least for a moment). Hmm, I guess the new 'break' should be moved > immediately after writeback_inodes()... > > > That is, if NFS_dirty+NFS_unstable+NFS_writeback > dirty_limit this > > break won't fix it. > > In fact this patch exactly targets at this condition. > When NFS* < dirty_limit, Chakri won't see the lockup at all. > The problem was, there are only two 'break's in the loop, and neither > one evaluates to true for his dd command. Yeah indeed, when put in the loop, after writeback_inodes() it makes sense. No idea what I was thinking, must be one of those days... :-/ - 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/3] CodingStyle updates
On Fri, Sep 28, 2007 at 05:32:00PM -0400, Erez Zadok wrote: > 1. Updates chapter 13 (printing kernel messages) to expand on the use of >pr_debug()/pr_info(), what to avoid, and how to hook your debug code with >kernel.h. > > 2. New chapter 19, branch prediction optimizations, discusses the whole >un/likely issue. > > Cc: "Kok, Auke" <[EMAIL PROTECTED]> > Cc: Kyle Moffett <[EMAIL PROTECTED]> > Cc: Jan Engelhardt <[EMAIL PROTECTED]> > Cc: Adrian Bunk <[EMAIL PROTECTED]> > Cc: roel <[EMAIL PROTECTED]> > > Signed-off-by: Erez Zadok <[EMAIL PROTECTED]> > --- > Documentation/CodingStyle | 88 +++- > 1 files changed, 86 insertions(+), 2 deletions(-) > > diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle > index 7f1730f..00b29e4 100644 > --- a/Documentation/CodingStyle > +++ b/Documentation/CodingStyle > @@ -643,8 +643,26 @@ Printing numbers in parentheses (%d) adds no value and > should be avoided. > There are a number of driver model diagnostic macros in > which you should use to make sure messages are matched to the right device > and driver, and are tagged with the right level: dev_err(), dev_warn(), > -dev_info(), and so forth. For messages that aren't associated with a > -particular device, defines pr_debug() and pr_info(). > +dev_info(), and so forth. > + > +A number of people often like to define their own debugging printf's, > +wrapping printk's in #ifdef's that get turned on only when subsystem > +debugging is compiled in (e.g., dprintk, Dprintk, DPRINTK, etc.). Please > +don't reinvent the wheel but use existing mechanisms. For messages that > +aren't associated with a particular device, defines > +pr_debug() and pr_info(); the latter two translate to printk(KERN_DEBUG) and The latter two? Since there are only two presented I think there is no reason to say "latter". > +printk(KERN_INFO), respectively. However, to get pr_debug() to actually > +emit the message, you'll need to turn on DEBUG in your code, which can be > +done as follows in your subsystem Makefile: > + > +ifeq ($(CONFIG_WHATEVER_DEBUG),y) > +EXTRA_CFLAGS += -DDEBUG > +endif > + > +In this way, you can create a Kconfig parameter to turn on debugging at > +compile time, which will also turn on DEBUG, to enable pr_debug() to emit > +actual messages; conversely, when CONFIG_WHATEVER_DEBUG is off, DEBUG is > +off, and pr_debug() will display nothing. > > Coming up with good debugging messages can be quite a challenge; and once > you have them, they can be a huge help for remote troubleshooting. Such > @@ -779,6 +797,69 @@ includes markers for indentation and mode configuration. > People may use their > own custom mode, or may have some other magic method for making indentation > work correctly. > > + Chapter 19: branch prediction optimizations > + > +The kernel includes macros called likely() and unlikely(), which can be used > +as hints to the compiler to optimize branch prediction. They operate by > +asking gcc to shuffle the code around so that the more favorable outcome > +executes linearly, avoiding a JMP instruction; this can improve cache > +pipeline efficiency. For technical details how these macros work, see the > +References section at the end of this document. > + > +An example use of this as as follows: ^^ > + > + ptr = kmalloc(size, GFP_KERNEL); > + if (unlikely(!ptr)) > + ... > + > +or > + err = some_function(...); > + if (likely(!err)) > + ... -- Shawn - 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: x86-64 sporadic hang in 2.6.23rc7 and 2.6.22
Thomas Gleixner wrote: On Mon, 2007-09-24 at 23:08 +0200, Helge Hafting wrote: The two kernels mentioned hangs occationally. Typically when I compile something and pass the time by surfing the web. A few minutes and then I notice that the mouse (and everything else in X) stops. kbd LEDs does not react to numlock/capslock. The only thing that still works is sysrq+B So far this has happened while running X, so no messages. I have gone back to 2.6.22rc4, which seems to work. This is a single opteron, although on a dual-slot board. Can you switch to serial console, so we can get some information out of that box? Sysrq-B is working, so we can get info from other sysrq functions as well. I didn't need the serial - it crashes during console work too. I think a "make clean" was in progress at the time. There must be work going on in order to crash. This time 2.6.22rc4 died on me with a general protection fault I got two reports, the first one scrolled partially off screen but the whole trace was there: shrink_dcache_memory shrink_slab kswapd autoremove_wake_function thread_return trace_hardirqs_on kswapd kswapd kthtread child_rip restore_args kthread child_rip Then I got: spinlock lockup on cpu #0, kswapd 0/212 _raw_spin_lock shrink_dcache_parent shrink_dcache_parent proc_flush_task release_task do_exit die error_exit prune_dcache [From here on, it continues exactly like the first report:] shrink_dcache_memory shrink_slab kswapd autoremove_wake_function thread_return trace_hardirqs_on kswapd kswapd kthtread child_rip restore_args kthread child_rip sysrq P says: cpu 0 pid 212 comm: kswapd0 not tainted 2.6.22-rc4 #18 RIP: __delay I took a picture of the screen, in case the register dumps are interesting. Wonder what this is - dcache trouble? swap trouble? Helge Hafting - 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] module: return error when mod_sysfs_init() failed
On Sat, 2007-09-29 at 19:06 +0900, Akinobu Mita wrote: > load_module() returns zero when mod_sysfs_init() fails, > then the module loading will succeed accidentally. > > This patch makes load_module() return error correctly in that case. Thanks, applied. Cheers, Rusty. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
IT8716F SPI driver submission?
Hi! I have written a rough code skeleton to be able to use the ITE IT8716F Super I/O chip as SPI host/master. The code works fine in userspace, but the Linux kernel SPI framework looks like it could save me from implementing full support for SPI flash clients/slaves. That's why I'd like to rewrite my code in a manner that's suitable for kernel inclusion. The IT8716F accepts commands byte-wise and does all of the lifting on the SPI bus as well. There are limitations, though: - It can send 1,2,4,5 bytes (including command byte) to the slave and read 0,1,2,3 bytes back. Other values are not possible. - Bus clock rate is either 33 MHz or 16.5 MHz. Is there any driver I can start from as reference? Regards, Carl-Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[rfc][patch] i386: remove comment about barriers
Hi,
OK this was going to be a quick patch, but after sleeping on it, I think
it deserves a better analysis... I can prove the comment is incorrect with a
test program, but I'm not as sure about my thinking that leads me to call it
also misleading.
The comment being removed by this patch is incorrect and misleading (I think).
1. load ...
2. store 1 -> X
3. wmb
4. rmb
5. load a <- Y
6. store ...
4 will only ensure ordering of 1 with 5.
3 will only ensure ordering of 2 with 6.
Further, a CPU with strictly in-order stores will still only provide that
2 and 6 are ordered (effectively, it is the same as a weakly ordered CPU
with wmb after every store).
In all cases, 5 may still be executed before 2 is visible to other CPUs!
The additional piece of the puzzle that mb() provides is the store/load
ordering, which fundamentally cannot be achieved with any combination of rmb()s
and wmb()s.
This can be an unexpected result if one expected any sort of global ordering
guarantee to barriers (eg. that the barriers themselves are sequentially
consistent with other types of barriers). However sfence or lfence barriers
need only provide an ordering partial ordering of meomry operations -- Consider
that wmb may be implemented as nothing more than inserting a special barrier
entry in the store queue, or, in the case of x86, it can be a noop as the store
queue is in order. And an rmb may be implemented as a directive to prevent
subsequent loads only so long as their are no previous outstanding loads (while
there could be stores still in store queues).
I can actually see the occasional load/store being reordered around lfence on
my core2. That doesn't prove my above assertions, but it does show the comment
is wrong (unless my program is -- can send it out by request).
So:
mb() and smp_mb() always have and always will require a full mfence or lock
prefixed instruction on x86. And we should remove this comment.
[ This is true for x86's sfence/lfence, but raises a question about Linux's
memory barriers. Does anybody expect that a sequence of smp_wmb and smp_rmb
would ever provide a full smp_mb barrier? I've always assumed no, but I
don't know if it is actually documented? ]
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
---
Index: linux-2.6/include/asm-i386/system.h
===
--- linux-2.6.orig/include/asm-i386/system.h
+++ linux-2.6/include/asm-i386/system.h
@@ -214,11 +214,6 @@ static inline unsigned long get_limit(un
*/
-/*
- * Actually only lfence would be needed for mb() because all stores done
- * by the kernel should be already ordered. But keep a full barrier for now.
- */
-
#define mb() alternative("lock; addl $0,0(%%esp)", "mfence", X86_FEATURE_XMM2)
#define rmb() alternative("lock; addl $0,0(%%esp)", "lfence", X86_FEATURE_XMM2)
-
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/
