Re: [PATCH debugfs: implement symbolic links
Greg KH [EMAIL PROTECTED] wrote on 14.02.2007 02:27:32: On Tue, Feb 13, 2007 at 12:13:54PM +0100, Peter Oberparleiter wrote: This function can be useful for people moving functionality from /proc to debugfs (e.g. the gcov-kernel patch). You aren't really creating debugfs symlinks from /sys/kernel/debug/ to the /proc directory are you? That's pretty insane... Interesting idea :) But I was thinking more along the lines of replacing existing /proc files and symlinks with files and links in debugfs. Otherwise I have no objection to this, I'll add it to my queue... Great, thanks! Regards, Peter Oberparleiter - 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: CPU load
On Wednesday 14 February 2007 18:28, malc wrote: On Wed, 14 Feb 2007, Con Kolivas wrote: On Wednesday 14 February 2007 09:01, malc wrote: On Mon, 12 Feb 2007, Pavel Machek wrote: Hi! [..snip..] I have (had?) code that 'exploits' this. I believe I could eat 90% of cpu without being noticed. Slightly changed version of hog(around 3 lines in total changed) does that easily on 2.6.18.3 on PPC. http://www.boblycat.org/~malc/apc/load-hog-ppc.png I guess it's worth mentioning this is _only_ about displaying the cpu usage to userspace, as the cpu scheduler knows the accounting of each task in different ways. This behaviour can not be used to exploit the cpu scheduler into a starvation situation. Using the discrete per process accounting to accumulate the displayed values to userspace would fix this problem, but would be expensive. Guess you are right, but, once again, the problem is not so much about fooling the system to do something or other, but confusing the user: Yes and I certainly am not arguing against that. a. Everything is fine - the load is 0%, the fact that the system is overheating and/or that some processes do not do as much as they could is probably due to the bad hardware. b. The weird load pattern must be the result of bugs in my code. (And then a whole lot of time/effort is poured into fixing the problem which is simply not there) The current situation ought to be documented. Better yet some flag can be introduced somewhere in the system so that it exports realy values to /proc, not the estimations that are innacurate in some cases (like hog) I wouldn't argue against any of those either. schedstats with userspace tools to understand the data will give better information I believe. -- -ck - 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/
A problem with the load_elf_interp() in fs/binfmt_elf
Hi ,All When I did some NFS mount operations, I found a problem with the load_elf_interp() in the fs/binfmt_elf. I mounted a number of NFS, after lots of continuous mount operations, the fatal error Segmentation fault happened with the mount.nfs4, as the count of the mount operations reached about 1000~3000. Using the strace, I found the mount.nfs4 fails just at the execve().The strace log is as follows. execve(/sbin/mount.nfs4, [mount.nfs4, 192.168.236.8:/, /mnt/nfspt/num_mount_014847/nfs-...], [/* 24 vars */]) = -1 EINVAL (Invalid argument) --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ I have investigate it, and found the problem exists in the load_elf_interp() when the Segmentation fault happened. When the mount.nfs4 is executed, the execve() in the kernel is invoked as follows. sys_execve | - do_execve | | - search_binary_handler |- linux_binfmt= elf_format |- |- elf_format- load_elf_binary | - elf_entry = load_elf_interp() |- | if (BAD_ADDR(elf_entry)) | force_sig(SIGSEGV, | retval =-EINVAL; In the do_execve(), after setting up some data structure, the do_execve() will invoke the search_binary_handler() to get the corresponding ELF binary loader for the mount.nfs4, and read the ELF executable image into memory. In my test, when the segment fault of mount.nfs4 happened, in the procedure of load_elf_binary(),the address elf_entry of the interp segment read from the load_elf_interp() was judged a BAD_ADDR and afterwards the kernel send a forcible signal SIGSEGV to the process of mount.nfs4, and exit with the retval EINVAL. After I debug the kernel, I have found the cause is the address map_addr in the load_elf_interp(). When the problem happens, the map_addr returned from the elf_map() is judged a valid address by BAD_ADDR() in load_elf_interp() , but unluckily the address elf_entry returned by map_addr - ELF_PAGESTART(eppnt-p_vaddr) is judged an invalid address by BAD_ADDR(), then the problem happens in the load_elf_binary(). By now, I've still not got a good method to resolve this problem in the load_elf_interp(). Any good ideas? Thanks. Best Regards. Shi Chao - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/11] ANNOUNCE: Syslets, generic asynchronous system call support
* Davide Libenzi davidel@xmailserver.org wrote:
There's another problem AFAICS:
- We woke up one of the cachemiss_loop threads in pick_new_async_thread
- The threads wakes up, mark itself as busy, and look at the -work
pointer hoping to find something to work on
But we never set that pointer to a userspace atom AFAICS. Me blind? :)
I still don't see at-work ever set to a valid userspace atom
though...
yeah - i havent added support for 'submit syslet from within a syslet'
support yet :-)
note that current normal syslet operation (both async and sync alike)
does not need at-work at all. When we cachemiss then the new head task
just wants to return a NULL pointer to user-space, to signal that work
is continuing in the background. A ready 'cachemiss' thread is really
not there to do cachemisses, it is a 'new head task in the waiting'. The
name comes from Tux and i guess it's time for a rename :)
but i do plan a SYSLET_ASYNC_CONTINUE flag, roughly along the patch i've
attached below: this would skip to the linearly next syslet and would
let the original syslet execute in the. I have not fully thought this
through though (let alone tested it ;) - can you see any hole in this
approach? This would in essence allow the following construct:
syslet1
syslet2
syslet3
syslet4
submitted in parallel, straight to cachemiss threads, from a syslet
itself.
there's yet another work submission variant that makes sense to do, a
true syslet vector submission: to do a loop over syslet atoms in
sys_async_exec(). That would have the added advantage of enabling
caching. If one vector component generates a cachemiss then the head
would continue with the next vector. (this too needs at-work alike
communication between ex-head and new-head)
maybe the latter would be the cleaner approach - SYSLET_ASYNC_CONTINUE
has no effect in cachemiss context, so it only makes sense if the
submitted syslet is a pure vector of parallel atoms. Alternatively,
SYSLET_ASYNC_CONTINUE would have to be made work from cachemiss contexts
too. (because that makes sense too, to start new async execution from
another async context.)
another not yet clear area is when there's no cachemiss thread
available. Right now SYSLET_ASYNC_CONTINUE will just fail - which makes
it nondeterministic.
Ingo
---
include/linux/async.h | 13 +++--
include/linux/sched.h |3 +--
include/linux/syslet.h | 20 +---
kernel/async.c | 43 +--
kernel/sched.c |2 +-
5 files changed, 56 insertions(+), 27 deletions(-)
# *DOCUMENTATION*
Index: linux/include/linux/async.h
===
--- linux.orig/include/linux/async.h
+++ linux/include/linux/async.h
@@ -1,15 +1,23 @@
#ifndef _LINUX_ASYNC_H
#define _LINUX_ASYNC_H
+
+#include linux/compiler.h
+
/*
* The syslet subsystem - asynchronous syscall execution support.
*
* Generic kernel API definitions:
*/
+struct syslet_uatom;
+struct async_thread;
+struct async_head;
+
#ifdef CONFIG_ASYNC_SUPPORT
extern void async_init(struct task_struct *t);
extern void async_exit(struct task_struct *t);
-extern void __async_schedule(struct task_struct *t);
+extern void
+__async_schedule(struct task_struct *t, struct syslet_uatom __user
*next_uatom);
#else /* !CONFIG_ASYNC_SUPPORT */
static inline void async_init(struct task_struct *t)
{
@@ -17,7 +25,8 @@ static inline void async_init(struct tas
static inline void async_exit(struct task_struct *t)
{
}
-static inline void __async_schedule(struct task_struct *t)
+static inline void
+__async_schedule(struct task_struct *t, struct syslet_uatom __user *next_uatom)
{
}
#endif /* !CONFIG_ASYNC_SUPPORT */
Index: linux/include/linux/sched.h
===
--- linux.orig/include/linux/sched.h
+++ linux/include/linux/sched.h
@@ -83,13 +83,12 @@ struct sched_param {
#include linux/timer.h
#include linux/hrtimer.h
#include linux/task_io_accounting.h
+#include linux/async.h
#include asm/processor.h
struct exec_domain;
struct futex_pi_state;
-struct async_thread;
-struct async_head;
/*
* List of flags we want to share for kernel threads,
* if only because they are not used by them anyway.
Index: linux/include/linux/syslet.h
===
--- linux.orig/include/linux/syslet.h
+++ linux/include/linux/syslet.h
@@ -56,10 +56,16 @@ struct syslet_uatom {
#define SYSLET_ASYNC 0x0001
/*
+ * Queue this syslet asynchronously and continue executing the
+ * next linear atom:
+ */
+#define SYSLET_ASYNC_CONTINUE 0x0002
+
+/*
* Never queue this syslet asynchronously - even if synchronous
* execution causes a context-switching:
*/
-#define SYSLET_SYNC0x0002
+#define
Re: kbuild, localversion (Re: [patch 3/3, resend] kbuild: correctly skip tilded backups in localversion files)
What i currently have is: -- top file 'Linux.version', with first line: 3.0.0-rcX which can be parsed to fill variables, used in build process (how many `.' and/or `-' in it -- doesn't really matter), second line is the name; -- 'MM.version' for MM tree; -- '[a-z]*\.version' for anything else. usual sort will place files in right order. Too much depend on having version in Makefile so this is a no-go to change. This has been like this since very early days so we shall not change it. 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] 8250: make probing for TXEN bug a config option
On Wed, 14 Feb 2007 11:37:52 +0300 Vitaly Wool [EMAIL PROTECTED] wrote: On 2/14/07, Andrew Morton [EMAIL PROTECTED] wrote: I think this should be a module option/boot parameter, not a config-time option. Hmm, why? I can't think of a platform where one 8250-compatible UART is problematic and another isn't :) Is it not possible that the same kernel package can be installed on systems which do and don't need this feature? If so, we don't want to force the provider of that package to create two packages. That, plus the chances of the package creator actually knowing about this option aren't great. Generally, if it can be done at runtime it is better to do so, no? - 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: Pull UBI tree
On Tue, 2007-02-13 at 16:08 +, Christoph Hellwig wrote: Please send out a current version for review instead. Last time I looked at it lots of things looked quite over-engineered, and I'd like to check if this has been improved since. The patch is big and LKML does filtered the mail. Actually the one in -mm tree is almost the latest version, it is OK to look at it as we did not do large changes. -- 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: undefined symbol 'PS3_PS3AV'
On Wed, 14 Feb 2007, Thomas Meyer wrote:
with 93bbad8fe13a25dcf7f3bc628a71d1a7642ae61b:
drivers/video/Kconfig:1604:warning: 'select' used by config symbol 'FB_PS3'
refer to undefined symbol 'PS3_PS3AV'
It's defined in arch/powerpc/platforms/ps3/Kconfig, which is sourced by
arch/powerpc/Kconfig only.
I don't know what's the best way to shut this up. Anyone with a suggestion?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- Sony Network and Software Technology Center Europe (NSCE)
[EMAIL PROTECTED] --- The Corporate Village, Da Vincilaan 7-D1
Voice +32-2-7008453 Fax +32-2-7008622 B-1935 Zaventem, Belgium
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/11] ANNOUNCE: Syslets, generic asynchronous system call support
On Tue, Feb 13, 2007 at 11:18:10PM +0100, Ingo Molnar ([EMAIL PROTECTED]) wrote: * Evgeniy Polyakov [EMAIL PROTECTED] wrote: [...] it still has a problem - syscall blocks and the same thread thus is not allowed to continue execution and fill the pipe - so what if system issues thousands of requests and there are only tens of working thread at most. [...] the same thread is allowed to continue execution even if the system call blocks: take a look at async_schedule(). The blocked system-call is 'put aside' (in a sleeping thread), the kernel switches the user-space context (registers) to a free kernel thread and switches to it - and returns to user-space as if nothing happened - allowing the user-space context to 'fill the pipe' as much as it can. Or did i misunderstand your point? Let me clarify what I meant. There is only limited number of threads, which are supposed to execute blocking context, so when all they are used, main one will block too - I asked about possibility to reuse the same thread to execute queue of requests attached to it, each request can block, but if blocking issue is removed, it would be possible to return. What I'm asking for is how actually kevent IO state machine functions work - each IO request is made not through usual mpage and bio allocations, but with special kevent ones, which do not wait until completion, but instead in destructor it is either rescheduled (if big file is transferred, then it is split into parts for transmission) or committed as ready (thus it becomes possible to read completion through kevent queue or ring), so there are only several threads, each one does small job on each request, but the same request can be rescheduled to it again and again (from bio destructor or -end_io callback for example). So I asked if it is possible to extend this state machine to work not only with blocked syscalls but with non-blocked functions with possibility to reschedule the same item again. -- Evgeniy Polyakov - 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: undefined symbol 'PS3_PS3AV'
On Wed, Feb 14, 2007 at 09:57:46AM +0100, Geert Uytterhoeven wrote: On Wed, 14 Feb 2007, Thomas Meyer wrote: with 93bbad8fe13a25dcf7f3bc628a71d1a7642ae61b: drivers/video/Kconfig:1604:warning: 'select' used by config symbol 'FB_PS3' refer to undefined symbol 'PS3_PS3AV' It's defined in arch/powerpc/platforms/ps3/Kconfig, which is sourced by arch/powerpc/Kconfig only. I don't know what's the best way to shut this up. Anyone with a suggestion? This would seem like a reasonable candidate for a 'depends on' instead of a select.. - 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/
SATA-performance part 2
Dear all, now I installed oprofile as suggested, and very interesting things happend: System: OpenSuSE 10.2 with AHCI on, disk: Solid State Disk (Flash Disk) Test: Write blocks of 1MB. Do fsync() every 1GB. Measure time for each GB. before installation of oprofile: testOpenSuSE 10.2 FreeBSD 6.2 write to raw device 25GB 26+/-1 MB/s at 4-10% CPU48+/-0 MB/s at 1% CPU write to ext3 2GB 39+/-5 MB/s at 10-15% CPU after installation of oprofile: testOpenSuSE 10.2 FreeBSD 6.2 write to raw device 25GB 48+/-0.5 MB/s at 4-10% CPU 49+/-0 MB/s at 1% CPU write to ext3 (writeback) 2GB 40+/-5 MB/s at 10-15% CPU after deinstallation of oprofile and only soft reboots (no hardware power off) these values STAYED (linux 48 MB/s) !! even for a brand new installation of OpenSuSE 10.2 to another partition! After a hardware power off everything was again like before (26 MB/s). So now the interesting questions to me are: 1. What is oprofile doing with my system ?? Especially what is been changed that remains a reboot ?? 2. Buffers: All those that told me, that linux raw devices are totally unbuffered and thus are slower than devices with filesystems. Are you sure? If yes, where do you think comes this increase of speed (26 to 48) ?? 3. Advices using ext3 with writeback option: I do not see an increase of performance with that. Thanks, Martin - 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: kbuild feature/question: default ARCH
On Tue, Feb 13, 2007 at 10:06:19PM -0800, Randy Dunlap wrote: Hi, I'd like for kbuild to default ARCH to the already-symlinked arch in include/asm-$(ARCH) if ARCH is not specified on the command line or in the environment. Another approach I have been toying with previously was to include ARCH in .config. But I somehow failed to get it working and it went on my TODO list. If kconfig get extended to so it can include Kconfig files for all archs then it could be a Kconfig option like anything else to select architecture and this would also solve your issue. As for the export ARCH=i386 proposal this is of no use for people crosscompiling a lot. Think of the 'Al Viro' setup with crosscompile for 5+ different architectures. But as I have no patches this is just cheap talk for now. 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] build error: allnoconfig fails on mincore/swapper_space
Hugh Dickins wrote: On Wed, 14 Feb 2007, Nick Piggin wrote: Can't you have migration without swap? Yes: but then the only swap entry it can find (short of page table corruption, which isn't really the focus of mincore) is a migration entry, isn't it? Just doesn't seem logical to have CONFIG_SWAP ifdef cover the whole thing, regardless that it produces the desired result. I'm going to submit a fixup patch to Linus covering all this stuff, after making a more comprehensive test case (yes I actually did test this patch with a few different cases before submitting it, so I must have been unlucky with uninitialised data). If he wants to apply it rather than back out the patch entirely, its up to him. I don't think there is any reason to panic. I did completely forget the result vector, but AFAIKS that's the only real bug in it. -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com - 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/11] syslets: core code
On Tue, Feb 13, 2007 at 11:41:31PM +0100, Ingo Molnar ([EMAIL PROTECTED]) wrote: Then limit it to a single page and use gup 1024 (512 on 64-bit) is alot but not ALOT. It is also certainly not ALT :-) Really, people will want to have more than 512 disks/spindles in the same box. I have used such a beast myself. For Tux workloads and benchmarks we had parallelism levels of millions of pending requests (!) on a single system - networking, socket limits, disk IO combined with thousands of clients do create such scenarios. I really think that such 'pinned pages' are a pretty natural fit for sys_mlock() and RLIMIT_MEMLOCK, and since the kernel side is careful to use the _inatomic() uaccess methods, it's safe (and fast) as well. This will end up badly - I used the same approach in the early kevent days and was proven to have swapable memory for the ring. I think it would be much better to have userspace allocated ring and use copy_to_user() there. Btw, as a bit of advertisement, the whole completion part can be done through kevent which already has ring buffer, queue operations and non-racy updates... :) Ingo -- Evgeniy Polyakov - 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] Fix d_path for lazy unmounts
On Monday 05 February 2007 00:32, Andreas Gruenbacher wrote: Here is an updated patch that also catches this special case. [...] The d_path change was to not start unreachable paths with slashes. In the extreme case, this leads to an empty string. As it turns out, we are reporting meaningless paths to users in a bunch of places in /proc, like in /proc/$pid/mounts, where we ended up with entries like this: rootfs rootfs rw 0 0 No wonder this immediately broke things; sorry for that. Mountpoints are reported relative to the chroot if they are reachable from the chroot, and relative to the namespace they are defined in otherwise. This is big nonsense, but it's unclear to me how to best fix it: - don't report unreachable mount points, - somehow indicate which mountpoints are reachable and which are not, like by prepending a question flag? What's the point in reporting the rootfs at all -- it's never reachable to an ordinary process? The same issue shows up in a few other places as well: /proc/$pid/mountstats which is similar to /proc/$pid/mounts, and here: /proc/$pid/maps /proc/$pid/smaps /proc/$pid/numa_maps /proc/swaps /proc/mdstat /proc/net/rpc/nfsd.fh/content /proc/net/rpc/nfsd.export/content We surely do not want to hide the entries that have unreachable pathnames here... Thanks, Andreas - 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] Fix d_path for lazy unmounts
On Wed, Feb 14, Andreas Gruenbacher wrote: What's the point in reporting the rootfs at all -- it's never reachable to an ordinary process? /init and its childs has it as root, until it passes control over to /sbin/init - 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] Fix d_path for lazy unmounts
On Wednesday 14 February 2007 00:29, Olaf Hering wrote: On Wed, Feb 14, Andreas Gruenbacher wrote: What's the point in reporting the rootfs at all -- it's never reachable to an ordinary process? /init and its childs has it as root, until it passes control over to /sbin/init Yes, that's why I said ordinary. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] GIT 1.5.0
On Wednesday 2007 February 14 03:14, Junio C Hamano wrote: - There is a configuration variable core.legacyheaders that The above two are not enabled by default and you explicitly have to ask for them, because these two features make repositories It isn't really the case that you have to _enable_ legacyheaders? It defaults to on already. You actually have to disable legacyheaders. Andy -- Dr Andy Parkins, M Eng (hons), MIEE [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: [ANNOUNCE] GIT 1.5.0
Andy Parkins [EMAIL PROTECTED] writes: On Wednesday 2007 February 14 03:14, Junio C Hamano wrote: - There is a configuration variable core.legacyheaders that The above two are not enabled by default and you explicitly have to ask for them, because these two features make repositories It isn't really the case that you have to _enable_ legacyheaders? It defaults to on already. You actually have to disable legacyheaders. Ah, true. What it should have stressed is that we currently default to the safer, backward compatible behaviour, and you have to explicitly ask to use more efficient but incompatible encoding by setting core.legacyheaders to false. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bug in current -git tree causing dbus and gnome to chew up cpu time
On 2/13/07, Greg KH [EMAIL PROTECTED] wrote: Hi, I've used 'git bisect' to track down a change in the latest git tree that is causing dbus-daemon to sit and spin at the time GNOME launches, preventing nautlius from ever running. The bad commit is: commit eb3dfb0cb1f4a44e2d0553f89514ce9f2a9fcaf1 Author: Andreas Gruenbacher [EMAIL PROTECTED] Date: Mon Feb 12 00:51:47 2007 -0800 [PATCH] Fix d_path for lazy unmounts With that patch out, GNOME startup works just fine. I have a strace of the dbus process running showing the problem, if anyone thinks that will help out any. I'm running pretty new GNOME and dbus here: dbus 1.0.2 gnome 2.16.2 hal 0.5.7.1 nautilus 2.16.3 Any ideas of things I can test? Just to add a data point, I see the same problem (startx never completes, gnome-vfs-daemon keeps getting forked by dbus to no end) on 2.6.20-git9 while -git7 is fine, and my pieces are from FC6 updates as of two days ago or so: [EMAIL PROTECTED] ~]$ rpm -q dbus gnome-vfs2 hal nautilus dbus-1.0.1-9.fc6 gnome-vfs2-2.16.2-2.fc6 hal-0.5.8.1-6.fc6 nautilus-2.16.2-7.fc6 Since the patch breaks userspace in a deadly way, I guess it should be reverted until an usable version of the fix can be found. And yes, I'm up for testing of course. --alessandro but I thought that I should let you know the things that I don't always show might not be worth the time it took (Steve Wynn, 'If My Life Was An Open Book') - 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/11] syslets: core code
* Evgeniy Polyakov [EMAIL PROTECTED] wrote: This will end up badly - I used the same approach in the early kevent days and was proven to have swapable memory for the ring. I think it would be much better to have userspace allocated ring and use copy_to_user() there. it is a userspace allocated ring - but pinned down by the kernel. Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bug in current -git tree causing dbus and gnome to chew up cpu time
Hi, I've described the problem and possible fixes in the Re: [PATCH] Fix d_path for lazy unmounts thread, Message-Id: [EMAIL PROTECTED] Thanks, Andreas - 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: undefined symbol 'PS3_PS3AV'
On Wed, 14 Feb 2007, Paul Mundt wrote:
On Wed, Feb 14, 2007 at 09:57:46AM +0100, Geert Uytterhoeven wrote:
On Wed, 14 Feb 2007, Thomas Meyer wrote:
with 93bbad8fe13a25dcf7f3bc628a71d1a7642ae61b:
drivers/video/Kconfig:1604:warning: 'select' used by config symbol
'FB_PS3'
refer to undefined symbol 'PS3_PS3AV'
It's defined in arch/powerpc/platforms/ps3/Kconfig, which is sourced by
arch/powerpc/Kconfig only.
I don't know what's the best way to shut this up. Anyone with a suggestion?
This would seem like a reasonable candidate for a 'depends on' instead of
a select..
That's what we originally had. But for the user it's simler if he can just
enable ps3fb and/or ps3snd (sound driver not yet finished), which both select
PS3_PS3AV.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- Sony Network and Software Technology Center Europe (NSCE)
[EMAIL PROTECTED] --- The Corporate Village, Da Vincilaan 7-D1
Voice +32-2-7008453 Fax +32-2-7008622 B-1935 Zaventem, Belgium
-
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/11] syslets: core code
On Wed, Feb 14, 2007 at 10:46:29AM +0100, Ingo Molnar ([EMAIL PROTECTED]) wrote: * Evgeniy Polyakov [EMAIL PROTECTED] wrote: This will end up badly - I used the same approach in the early kevent days and was proven to have swapable memory for the ring. I think it would be much better to have userspace allocated ring and use copy_to_user() there. it is a userspace allocated ring - but pinned down by the kernel. That's a problem - 1000/512 pages per 'usual' thread ends up with the whole memory locked by malicious/stupid application (at least on Debian and Mandrake there is no locked memory limit by default). And if such a limit exists, this will hurt big-iron applications, which want to used high-order rings legitimely. Ingo -- Evgeniy Polyakov - 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: undefined symbol 'PS3_PS3AV'
On Wed, Feb 14, 2007 at 11:02:06AM +0100, Geert Uytterhoeven wrote: On Wed, 14 Feb 2007, Paul Mundt wrote: This would seem like a reasonable candidate for a 'depends on' instead of a select.. That's what we originally had. But for the user it's simler if he can just enable ps3fb and/or ps3snd (sound driver not yet finished), which both select PS3_PS3AV. Why not just have PS3_PS3AV def_bool y if ps3fb || ps3snd? Or if that doesn't work, just place the PS3FB option in arch/powerpc/platforms/ps3/Kconfig. Of course if select obeyed the depends on, this wouldn't be a problem either.. - 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/11] syslets: core code
(at least on Debian and Mandrake there is no locked memory limit by default). that sounds like 2 very large bugtraq-worthy bugs in these distros.. so bad a bug that I almost find it hard to believe... -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.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/
xfs internal error on a new filesystem
Hello, We got the following xfs internal error on one of our production servers: Feb 14 08:28:52 info6 kernel: [238186.676483] Filesystem sdd8: XFS internal error xfs_trans_cancel at line 1138 of file fs/xfs/xfs_trans.c. Caller 0xf8b906e7 Feb 14 08:28:52 info6 kernel: [238186.869089] [pg0+947617605/1069749248] xfs_trans_cancel+0x115/0x140 [xfs] Feb 14 08:28:52 info6 kernel: [238186.879131] [pg0+947664615/1069749248] xfs_mkdir+0x2ad/0x777 [xfs] Feb 14 08:28:52 info6 kernel: [238186.882517] [pg0+947664615/1069749248] xfs_mkdir+0x2ad/0x777 [xfs] Feb 14 08:28:52 info6 kernel: [238186.882558] [pg0+947708079/1069749248] xfs_vn_mknod+0x46f/0x493 [xfs] Feb 14 08:28:52 info6 kernel: [238186.882625] [pg0+947621368/1069749248] xfs_trans_unlocked_item+0x32/0x50 [xfs] Feb 14 08:28:52 info6 kernel: [238186.882654] [pg0+947428195/1069749248] xfs_da_buf_done+0x73/0xca [xfs] Feb 14 08:28:52 info6 kernel: [238186.882712] [pg0+947623330/1069749248] xfs_trans_brelse+0xd2/0xe5 [xfs] Feb 14 08:28:52 info6 kernel: [238186.882739] [pg0+947686680/1069749248] xfs_buf_rele+0x21/0x77 [xfs] Feb 14 08:28:52 info6 kernel: [238186.882768] [pg0+947428868/1069749248] xfs_da_state_free+0x64/0x6b [xfs] Feb 14 08:28:52 info6 kernel: [238186.882827] [pg0+947468486/1069749248] xfs_dir2_node_lookup+0x85/0xbb [xfs] Feb 14 08:28:52 info6 kernel: [238186.882857] [pg0+947445628/1069749248] xfs_dir_lookup+0x13a/0x13e [xfs] Feb 14 08:28:52 info6 kernel: [238186.882912] [vfs_permission+32/36] vfs_permission+0x20/0x24 Feb 14 08:28:52 info6 kernel: [238186.883395] [__link_path_walk+119/3686] __link_path_walk+0x77/0xe66 Feb 14 08:28:52 info6 kernel: [238186.883413] [pg0+947627458/1069749248] xfs_dir_lookup_int+0x3c/0x121 [xfs] Feb 14 08:28:52 info6 kernel: [238186.883453] [pg0+947708157/1069749248] xfs_vn_mkdir+0x2a/0x2e [xfs] Feb 14 08:28:52 info6 kernel: [238186.883481] [vfs_mkdir+221/299] vfs_mkdir+0xdd/0x12b Feb 14 08:28:52 info6 kernel: [238186.883493] [sys_mkdirat+156/222] sys_mkdirat+0x9c/0xde Feb 14 08:28:52 info6 kernel: [238186.883510] [sys_mkdir+31/35] sys_mkdir+0x1f/0x23 Feb 14 08:28:52 info6 kernel: [238186.883519] [sysenter_past_esp+86/121] sysenter_past_esp+0x56/0x79 Feb 14 08:28:52 info6 kernel: [238186.883804] xfs_force_shutdown(sdd8,0x8) called from line 1139 of file fs/xfs/xfs_trans.c. Return address = 0xf8b84f6b Feb 14 08:28:52 info6 kernel: [238186.945610] Filesystem sdd8: Corruption of in-memory data detected. Shutting down filesystem: sdd8 Feb 14 08:28:52 info6 kernel: [238186.952732] Please umount the filesystem, and rectify the problem(s) We were able to unmount/remount the volume (didn't do xfs_repair because we thought it might take long time, and the server was already in production at the moement) The file system was created less than 48hours ago, and 370G of sensitve production data was moved to the server before it xfs crash. In fact, we have been using reiserfs for a long period of time, and we have suffered from several filesystem corruption incidents, so we decided to switch to xfs hoping that it is more stable and corrupts less than reiserfs, but it was disappointing to get this problem after just 48 hours from reformating a production server using xfs. System details : Kernel: 2.6.18 Controller: 3ware 9550SX-8LP (RAID 10) We are wondering here if this problem is an indicator to data corruption on disk ? is it really necessary to run xfs_repair ? Do u recommend that we switch back to reiserfs ? Could it be a hardware related problems ? any clues how to verify that ? Thanks --Ramy - Free POP3 Email from www.Gawab.com Sign up NOW and get your account @gawab.com!! - 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 06/11] syslets: core, documentation
On Tue, Feb 13, 2007 at 03:20:42PM +0100, Ingo Molnar wrote: +Arguments to the system call are implemented via pointers to arguments. +This not only increases the flexibility of syslet atoms (multiple syslets +can share the same variable for example), but is also an optimization: +copy_uatom() will only fetch syscall parameters up until the point it +meets the first NULL pointer. 50% of all syscalls have 2 or less +parameters (and 90% of all syscalls have 4 or less parameters). + + [ Note: since the argument array is at the end of the atom, and the + kernel will not touch any argument beyond the final NULL one, atoms + might be packed more tightly. (the only special case exception to + this rule would be SKIP_TO_NEXT_ON_STOP atoms, where the kernel will + jump a full syslet_uatom number of bytes.) ] What if you need to increase the number of arguments passed to a system call later? That would be an API change since the size of syslet_uatom would change? Also, what if you have an ABI such that: sys_foo(int fd, long long a) where: arg[0] = fd arg[1] = unused arg[2] = low 32-bits a arg[3] = high 32-bits a it seems you need to point arg[1] to some valid but dummy variable. How do you propose syslet users know about these kinds of ABI issues (including the endian-ness of 64-bit arguments) ? -- 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: xfs internal error on a new filesystem
On Wed, 2007-02-14 10:24:27 +, Ramy M. Hassan [EMAIL PROTECTED] wrote: Feb 14 08:28:52 info6 kernel: [238186.945610] Filesystem sdd8: Corruption of in-memory data detected. Shutting down filesystem: sdd8 [...] We are wondering here if this problem is an indicator to data corruption on disk ? is it really necessary to run xfs_repair ? Do u recommend that we switch back to reiserfs ? Could it be a hardware related problems ? any clues how to verify that ? Running memtest86 for some hours could at least help to verify that you don't see bad memory... MfG, JBG -- Jan-Benedict Glaw [EMAIL PROTECTED] +49-172-7608481 Signature of: 23:53 @jbglaw So, ich kletter' jetzt mal ins Bett. the second : 23:57 @jever2 .oO( kletter ..., hat er noch Gitter vorm Bett, wie früher meine Kinder?) 00:00 @jbglaw jever2: *patsch* 00:01 @jever2 *aua*, wofür, Gedanken sind frei! 00:02 @jbglaw Nee, freie Gedanken, die sind seit 1984 doch aus! 00:03 @jever2 1984? ich bin erst seit 1985 verheiratet! signature.asc Description: Digital signature
Re: [patch 00/11] ANNOUNCE: Syslets, generic asynchronous system call support
* Evgeniy Polyakov [EMAIL PROTECTED] wrote: Let me clarify what I meant. There is only limited number of threads, which are supposed to execute blocking context, so when all they are used, main one will block too - I asked about possibility to reuse the same thread to execute queue of requests attached to it, each request can block, but if blocking issue is removed, it would be possible to return. ah, ok, i understand your point. This is not quite possible: the cachemisses are driven from schedule(), which can be arbitraily deep inside arbitrary system calls. It can be in a mutex_lock() deep inside a driver. It can be due to a alloc_pages() call done by a kmalloc() call done from within ext3, which was called from the loopback block driver, which was called from XFS, which was called from a VFS syscall. Even if it were possible to backtrack i'm quite sure we dont want to do this, for three main reasons: Firstly, backtracking and retrying always has a cost. We construct state on the way in - and we destruct on the way out. The kernel stack we have built up has a (nontrivial) construction cost and thus a construction value - we should preserve that if possible. Secondly, and this is equally important: i wanted the number of async kernel threads to be the natural throttling mechanism. If user-space wants to use less threads and overcommit the request queue then it can be done in user-space: by over-queueing requests into a separate list, and taking from that list upon completion and submitting it. User-space has precise knowledge of overqueueing scenarios: if the event ring is full then all async kernel threads are busy. but note that there's a deeper reason as well for not wanting over-queueing: the main cost of a 'pending request' is the kernel stack of the blocked thread itself! So do we want to allow 'requests' to stay 'pending' even if there are no more threads available? Nope: because letting them 'pend' would essentially (and implicitly) mean an increase of the thread pool. In other words: with the syslet subsystem, a kernel thread /is/ the asynchronous request itself. So 'have more requests pending' means 'have more kernel threads'. And 'no kernel thread available' must thus mean 'no queueing of this request'. Thirdly, there is a performance advantage of this queueing property as well: by letting a cachemiss thread only do a single syslet all work is concentrated back to the 'head' task, and all queueing decisions are immediately known by user-space and can be acted upon. So the work-queueing setup is not symmetric at all, there's a fundamental bias and tendency back towards the head task - this helps caching too. That's what Tux did too - it always tried to queue back to the 'head task' as soon as it could. Spreading out work dynamically and transparently is necessary and nice, but it's useless if the system has no automatic tendency to move back into single-threaded (fully cached) state if the workload becomes less parallel. Without this fundamental (and transparent) 'shrink parallelism' property syslets would only degrade into yet another threading construct. Ingo - 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]microcode update driver rewrite - takes 2
On 6/27/06, Shaohua Li [EMAIL PROTECTED] wrote: With the changes, we should put all intel-ucode/xx-xx-xx microcode files into the firmware dir (I had a tool to split previous big data file into small one and later we will release new style data file). BTW, where this tool can be found? At the moment we seem to have only microcode_ctl, and microcode.dat from it distribution is not understood by the driver. - 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/
Will smp alternative try to patch init text also?
Hi, I just built a 2.6.20 kernel with CONFIG_RELOCATABLE=y. While going through relocation entries for .smp_locks section, I see some relocation entries present w.r.t to init section also. Below I am pasting just few of them. Relocation section '.rel.smp_locks' at offset 0x6079c8 contains 4662 entries: Offset InfoTypeSym.Value Sym. Name c058e000 1201 R_386_32 c0593000 .init.text c058e004 1201 R_386_32 c0593000 .init.text c058e008 1201 R_386_32 c0593000 .init.text So what happens if somebody builds a SMP kernel and runs on a UP machine. Later it hotplus one CPU. Then kernel will switch to SMP mode. Looking at the code it looks like it will also try to patch init text which is no more there and will corrupt something else? Am I missing something? MODPOST whitelists the references from .smp_locks section to .init.text, hence these warnings are not displayed during compilation. Thanks Vivek - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 05/11] syslets: core code
On Wed, Feb 14, 2007 at 11:30:55AM +0100, Arjan van de Ven ([EMAIL PROTECTED]) wrote: (at least on Debian and Mandrake there is no locked memory limit by default). that sounds like 2 very large bugtraq-worthy bugs in these distros.. so bad a bug that I almost find it hard to believe... Well: $ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited max nice(-e) 0 file size (blocks, -f) unlimited pending signals (-i) unlimited max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size(512 bytes, -p) 8 POSIX message queues (bytes, -q) unlimited max rt priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) unlimited virtual memory (kbytes, -v) unlimited file locks (-x) unlimited $ cat /etc/debian_version 4.0 $ ulimit -a core file size(blocks, -c) 0 data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files(-n) 1024 pipe size (512 bytes, -p) 8 stack size(kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes(-u) 7168 virtual memory(kbytes, -v) unlimited $ cat /etc/mandrake-release Mandrake Linux release 10.0 (Community) for i586 Anyway, even if there is a limit like in fc5 - 32kb, so I doubt any unpriveledged userspace application will ever run there. -- Evgeniy Polyakov - 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: xfs internal error on a new filesystem
On 2/14/07, Ramy M. Hassan [EMAIL PROTECTED] wrote: Hello, We got the following xfs internal error on one of our production servers: Hi, I want firstly to make a disclaimer that I am not an XFS or kernel guru, what I am writing now is purely my experience, since I use XFS on all my machines, on different disks and all. I encountered the problem you have now, twice over the past three years. Once it was caused by a faulty disk where the 8MB cache on the disk was faulty, causing corruption, and one time it was cause of, what seems to be, a CPU that couldnt handle XFS. This sounds illogical, and to me too, honestly, but the explanation I got was that XFS writes are quite CPU intensive, especialy when you write with 500MB/s and we tried to do this on a PII-400Mhz. I tried reiserfs aswell, and I honestly cant give you one reason to switch back to it. I love XFS, always did, its fast and reliable. Problems that I had were never related to XFS but to hardware that had to deal with XFS in a way (CPU/disk). And, xfs_repair DID repair my filesystems, the data was on the disks, and valid, XFS just shut down my filesystem cause it found my journal not reliable/corrupted. Again, please be aware that I am just a regular user who likes to play around with linux and the kernel, I am no expert in the field of XFS or its relations. I hope this helps you a bit. Patrick - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.19.2: maybe a bug inside the r8169 network driver (was Re: Linux 2.6.19.2: Freeze with CIFS mount)
On Tuesday 13 February 2007 21:30:47 Francois Romieu wrote: Eric Lacombe [EMAIL PROTECTED] : [...] That problem also remind me that when I compiled this driver without the CONFIG_NET_ETHERNET (in the section Ethernet (10 or 100Mbit)), I have really poor performance with the net device. Maybe it is related, or not ;) If it gives you more ideas ? Maybe it could be interesting to know about the r8169 maintainer, but I dont know who he is. 1. $ ls arch crypto include kernel mm scripts blockDocumentation init lib net security COPYING driversipc MAINTAINERS README sound CREDITS fs Kbuild Makefile REPORTING-BUGS usr The maintainer of the r8169 driver is listed in the MAINTAINERS file. I see, thanks ;) (I thought the MAINTAINERS file was not fully maintained ;) 2. Disabling CONFIG_NET_ETHERNET is a bad idea. Don't do that. ok, but why having it only inside the ethernet 100 menu ? It is misleading, no ? 3. See tethereal -w or tcpdump on the adequate interface to save a traffic dump. yep, but the problem is that I cant do that from the NAS Box. I will try to monitor the traffic via the system that will freeze... For the moment I can't monitor the net traffic from an alternate PC, but soon. 4. Are you using a binary module for your video adapter ? yes, I suppose that I have to unload this one before doing further tests. 5. How does the 2.6.20 version of the r8169 driver behave ? I don't have installed it yet, but I'll do it this evening. 6. You may setup a cron to monitor an ethtool dump of the register of the 8169 at regular interval. ifconfig and /proc/interrupts could exhibit some unusual drift as time passes on too. I will do that. When I could put a third system to monitor the traffic, I will make the system that freeze keep sending that information to it. 7. A dmesg would be welcome. I could do that, this evening. 8. Please open a PR at bugzilla.kernel.org. ok |...] | There are various ways to analyze system hangs including (at least in some cases) getting a system dump which can be used to isolate the failing location - hopefully I would like to have more detailed help, if possible. CONFIG_MAGIC_SYSRQ is set. Check that the magic sysrq is not disabled at runtime through /etc/sysctl.conf. See Documentation/sysrq.txt for details. ok Please keep Steve French in the loop. ok Thanks for your response ;) Eric - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Will smp alternative try to patch init text also?
Vivek Goyal wrote: So what happens if somebody builds a SMP kernel and runs on a UP machine. Later it hotplus one CPU. Then kernel will switch to SMP mode. Looking at the code it looks like it will also try to patch init text which is no more there and will corrupt something else? There are range checks for both kernel (_text - _etext) and modules (.text section). Anything outside isn't patched. cheers, Gerd -- Gerd Hoffmann [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] FAT: DIO-write fallback to normal buffered
On Sat 10-02-07 23:44:01, OGAWA Hirofumi wrote: [RESEND: forget to add [EMAIL PROTECTED] If the DIO write on FAT is expanding the size, it will be fail by -EINVAL, because FAT can't handle it now. This patch fallback it to the normal buffered-write and would return success. Signed-off-by: OGAWA Hirofumi [EMAIL PROTECTED] Signed-off-by: Jan Kara [EMAIL PROTECTED] Just to explain a bit: I think that returning EINVAL is quite unexpected for users in this case (I actually got a bugreport which turned out to be this problem) and fallback to buffered IO seems to be a reasonable thing to do. Probably it's not the cleanest solution but for FAT I think it's good enough ;). Honza --- fs/fat/inode.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff -puN fs/fat/inode.c~fat_direct-io-fallback fs/fat/inode.c --- linux-2.6/fs/fat/inode.c~fat_direct-io-fallback 2007-02-10 22:08:33.0 +0900 +++ linux-2.6-hirofumi/fs/fat/inode.c 2007-02-10 22:08:33.0 +0900 @@ -173,10 +173,12 @@ static ssize_t fat_direct_IO(int rw, str * * But we must fill the remaining area or hole by nul for * updating -mmu_private. + * + * Return 0, and fallback to normal buffered write. */ loff_t size = offset + iov_length(iov, nr_segs); if (MSDOS_I(inode)-mmu_private size) - return -EINVAL; + return 0; } /* _ -- Jan Kara [EMAIL PROTECTED] SuSE CR Labs - 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 06/11] syslets: core, documentation
* Russell King [EMAIL PROTECTED] wrote: On Tue, Feb 13, 2007 at 03:20:42PM +0100, Ingo Molnar wrote: +Arguments to the system call are implemented via pointers to arguments. +This not only increases the flexibility of syslet atoms (multiple syslets +can share the same variable for example), but is also an optimization: +copy_uatom() will only fetch syscall parameters up until the point it +meets the first NULL pointer. 50% of all syscalls have 2 or less +parameters (and 90% of all syscalls have 4 or less parameters). + + [ Note: since the argument array is at the end of the atom, and the + kernel will not touch any argument beyond the final NULL one, atoms + might be packed more tightly. (the only special case exception to + this rule would be SKIP_TO_NEXT_ON_STOP atoms, where the kernel will + jump a full syslet_uatom number of bytes.) ] What if you need to increase the number of arguments passed to a system call later? That would be an API change since the size of syslet_uatom would change? the syslet_uatom has a constant size right now, and space for a maximum of 6 arguments. /If/ the user knows that a specific atom (which for example does a sys_close()) takes only 1 argument, it could shrink the size of the atom down by 4 arguments. [ i'd not actually recommend doing this, because it's generally a volatile thing to play such tricks - i guess i shouldnt have written that side-note in the header file :-) ] there should be no new ABI issues: the existing syscall ABI never changes, it's only extended. New syslets can rely on new properties of new system calls. This is quite parallel to how glibc handles system calls. How do you propose syslet users know about these kinds of ABI issues (including the endian-ness of 64-bit arguments) ? syslet users would preferably be libraries like glibc - not applications - i'm not sure the raw syslet interface should be exposed to applications. Thus my current thinking is that syslets ought to be per-arch structures - no need to pad them out to 64 bits on 32-bit architectures - it's per-arch userspace that makes use of them anyway. system call encodings are fundamentally per-arch anyway - every arch does various fixups and has its own order of system calls. but ... i'd not be against having a 'generic syscall layer' though, and syslets might be a good starting point for that. But that would necessiate a per-arch table of translating syscall numbers into this 'generic' numbering, at minimum - or a separate sys_async_call_table[]. Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/11] ANNOUNCE: Syslets, generic asynchronous system call support
Ohh. OpenVMS lives forever ;) Me likeee ;) hm, i dont know OpenVMS - but googled around a bit for 'VMS asynchronous' and it gave me this: VMS had SYS$QIO which is asynchronous I/O queueing with completions of sorts. You had to specifically remember if you wanted to a synchronous I/O. Nothing afaik quite like series of commands batched async, although VMS has a call for everything else so its possible there is one buried in the back of volume 347 of the grey wall ;) Looking at the completion side I'm not 100% sure we need async_wait given the async batches can include futex operations... Alan - 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 06/11] syslets: core, documentation
On Wed, Feb 14, 2007 at 11:50:39AM +0100, Ingo Molnar wrote: * Russell King [EMAIL PROTECTED] wrote: On Tue, Feb 13, 2007 at 03:20:42PM +0100, Ingo Molnar wrote: +Arguments to the system call are implemented via pointers to arguments. +This not only increases the flexibility of syslet atoms (multiple syslets +can share the same variable for example), but is also an optimization: +copy_uatom() will only fetch syscall parameters up until the point it +meets the first NULL pointer. 50% of all syscalls have 2 or less +parameters (and 90% of all syscalls have 4 or less parameters). + + [ Note: since the argument array is at the end of the atom, and the + kernel will not touch any argument beyond the final NULL one, atoms + might be packed more tightly. (the only special case exception to + this rule would be SKIP_TO_NEXT_ON_STOP atoms, where the kernel will + jump a full syslet_uatom number of bytes.) ] What if you need to increase the number of arguments passed to a system call later? That would be an API change since the size of syslet_uatom would change? the syslet_uatom has a constant size right now, and space for a maximum of 6 arguments. /If/ the user knows that a specific atom (which for example does a sys_close()) takes only 1 argument, it could shrink the size of the atom down by 4 arguments. [ i'd not actually recommend doing this, because it's generally a volatile thing to play such tricks - i guess i shouldnt have written that side-note in the header file :-) ] there should be no new ABI issues: the existing syscall ABI never changes, it's only extended. New syslets can rely on new properties of new system calls. This is quite parallel to how glibc handles system calls. Let me spell it out, since you appear to have completely missed my point. At the moment, SKIP_TO_NEXT_ON_STOP is specified to jump a jump a full syslet_uatom number of bytes. If we end up with a system call being added which requires more than the currently allowed number of arguments (and it _has_ happened before) then either those syscalls are not accessible to syslets, or you need to increase the arg_ptr array. That makes syslet_uatom larger. If syslet_uatom is larger, SKIP_TO_NEXT_ON_STOP increments the syslet_uatom pointer by a greater number of bytes. If we're running a set of userspace syslets built for an older kernel on such a newer kernel, that is an incompatible change which will break. How do you propose syslet users know about these kinds of ABI issues (including the endian-ness of 64-bit arguments) ? syslet users would preferably be libraries like glibc - not applications - i'm not sure the raw syslet interface should be exposed to applications. Thus my current thinking is that syslets ought to be per-arch structures - no need to pad them out to 64 bits on 32-bit architectures - it's per-arch userspace that makes use of them anyway. system call encodings are fundamentally per-arch anyway - every arch does various fixups and has its own order of system calls. but ... i'd not be against having a 'generic syscall layer' though, and syslets might be a good starting point for that. But that would necessiate a per-arch table of translating syscall numbers into this 'generic' numbering, at minimum - or a separate sys_async_call_table[]. Okay - I guess the userspace library approach is fine, but it needs to be documented that applications which build syslets directly are going to be non-portable. -- 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/1] PM: Adds remount fs ro at suspend
Hi! This adds the ability for the file system to remounted as read only during a system suspend. Log the mount points so when the resume occurs, they can be remounted back to their original states. This is so in an advent of a power failure, we try our best to keep data from being corrupted or lost. Can you please explain why this can't be done in userspace? I am sure it can. The idea came from customer inputs, speed is my guess. echo mem /sys/../state seems a whole lot simpler and cleaner than having userspace figure out what it mounted and then doing echo mem. Well, customers have little knowledge of linux kernel, sorry. Do it in userspace, then find out if it is too slow, and if it is, develop extensions to kernel to do it properly. But no, you can't simply do it in kernel. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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: Will smp alternative try to patch init text also?
On Wed, Feb 14, 2007 at 11:51:31AM +0100, Gerd Hoffmann wrote: Vivek Goyal wrote: So what happens if somebody builds a SMP kernel and runs on a UP machine. Later it hotplus one CPU. Then kernel will switch to SMP mode. Looking at the code it looks like it will also try to patch init text which is no more there and will corrupt something else? There are range checks for both kernel (_text - _etext) and modules (.text section). Anything outside isn't patched. Oh... I missed that. Thanks. Vivek - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/11] ANNOUNCE: Syslets, generic asynchronous system call support
On Wed, Feb 14, 2007 at 11:37:31AM +0100, Ingo Molnar ([EMAIL PROTECTED]) wrote: Let me clarify what I meant. There is only limited number of threads, which are supposed to execute blocking context, so when all they are used, main one will block too - I asked about possibility to reuse the same thread to execute queue of requests attached to it, each request can block, but if blocking issue is removed, it would be possible to return. ah, ok, i understand your point. This is not quite possible: the cachemisses are driven from schedule(), which can be arbitraily deep inside arbitrary system calls. It can be in a mutex_lock() deep inside a driver. It can be due to a alloc_pages() call done by a kmalloc() call done from within ext3, which was called from the loopback block driver, which was called from XFS, which was called from a VFS syscall. That's only because of schedule() is a main point where 'rescheduling'/requeuing (task switch in other words) happens - but if it will be possible to bypass schedule()'s decision and not reschedule there, but 'on demand', will it be possible to reuse the same syslet? Let me show an example: consider aio_sendfile() on a big file, so it is not possible to fully get it into VFS, but having spinning on per-page basis (like right now) is no optial solution too. For kevent AIO I created new address space operation aio_getpages() which is essentially mpage_readpages() - it populates several pages into VFS in one BIO (if possible, otherwise in the smallest possible number of chunks) and then in bio destruction callback (actually in bio_endio callback, but for that case it can be considered as the same) I reschedule the same request to some other (not exactly the same as started) thread. When processed data is being sent and next chunk of the file is populated to the VFS using aio_getpages(), which in BIO callback will reschedule the same request again. So it is possible with essentially one thread (or limited number of them) to fill the whole IO pipe. With syslet approach it seems to be impossible due to the fact, that request is a whole sendfile. Even if one uses proper readahed (fadvise) advise, there is no possibility to split sendfile and form it as a set of essentially the same requests with different start/offset/whatever parameters (well, exactly for senfile() it is possible - just setup several calls in one syslet from different offsets and with different lengths and form a proper state machine of them, but for example TCP recv() will not match that scenario). So my main question was about possibility to reuse syslet state machine in kevent AIO instead of own (althtough own one lacks only one good feature of syslets threads currently - its set of threads is global, but not per-task, which does not allow to scale good with number of different processes doing IO) so to not duplicate the code if kevent is ever be possible to get into. -- Evgeniy Polyakov - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bug in current -git tree causing dbus and gnome to chew up cpu time
On 2/14/07, Andreas Gruenbacher [EMAIL PROTECTED] wrote: Hi, I've described the problem and possible fixes in the Re: [PATCH] Fix d_path for lazy unmounts thread, Message-Id: [EMAIL PROTECTED] Yes, I saw that. But there isn't any patch for me to test, and my userspace remains broken. Please don't get me wrong - I'm not bitching about this, but I will effectively not be able to test newer snapshots until either a fix for this new bug gets in, or the commit that introduced the bug gets reverted. Thanks, --alessandro but I thought that I should let you know the things that I don't always show might not be worth the time it took (Steve Wynn, 'If My Life Was An Open Book') - 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/
[pp] kbuild: ARCH-setup (Re: kbuild feature/question: default ARCH)
Hallo. On Wed, Feb 14, 2007 at 10:11:44AM +0100, Sam Ravnborg wrote: On Tue, Feb 13, 2007 at 10:06:19PM -0800, Randy Dunlap wrote: Hi, I'd like for kbuild to default ARCH to the already-symlinked arch in include/asm-$(ARCH) if ARCH is not specified on the command line or in the environment. Another approach I have been toying with previously was to include ARCH in .config. But I somehow failed to get it working and it went on my TODO list. Sam, IMHO this is one inconvenience of the many, due to absence of conf-build, build mechanism (you have my message about just for fun thoughts ;). If kconfig get extended to so it can include Kconfig files for all archs then it could be a Kconfig option like anything else to select architecture and this would also solve your issue. As for the export ARCH=i386 proposal this is of no use for people crosscompiling a lot. Think of the 'Al Viro' setup with crosscompile for 5+ different architectures. While trying to do something with lguest and private asm-offsets on AMD64, i must use ARCH=i386 for testing stuff. Thus, i give you my patch proposition (proposed patch, whatever) that remembers ARCH in Makefile in $(objtree). Once you have setup, you may use just `make target' there. Randy, maybe this is *something* to have, than nothing. Testing is appreciated. ,-*- shell -*- |[EMAIL PROTECTED]:/mnt/work/app-src-build/kernel.org/linux-2.6.20$ |[EMAIL PROTECTED]:/mnt/work/app-src-build/kernel.org/linux-2.6.20$ rm -rf /tmp/linuz |[EMAIL PROTECTED]:/mnt/work/app-src-build/kernel.org/linux-2.6.20$ mkdir /tmp/linuz |[EMAIL PROTECTED]:/mnt/work/app-src-build/kernel.org/linux-2.6.20$ make ARCH=i386 O=/tmp/linu |linux-2.6.20/ linuz/ |[EMAIL PROTECTED]:/mnt/work/app-src-build/kernel.org/linux-2.6.20$ make ARCH=i386 O=/tmp/linuz/ defconfig /dev/null |/mnt/work/app-src-build/kernel.org/linux-2.6.20/arch/i386/defconfig:1122:warning: |trying to assign nonexistent symbol USB_MULTITHREAD_PROBE |[EMAIL PROTECTED]:/mnt/work/app-src-build/kernel.org/linux-2.6.20$ cd /tmp/linuz |[EMAIL PROTECTED]:/tmp/linuz$ make prepare |make -C /mnt/work/app-src-build/kernel.org/linux-2.6.20 O=/dev/shm/linuz prepare |scripts/kconfig/conf -s arch/i386/Kconfig | Using /mnt/work/app-src-build/kernel.org/linux-2.6.20 as source for kernel | CHK include/linux/version.h | UPD include/linux/version.h | CHK include/linux/utsrelease.h | UPD include/linux/utsrelease.h | SYMLINK include/asm - include/asm-i386 | CC arch/i386/kernel/asm-offsets.s | GEN include/asm-i386/asm-offsets.h |[EMAIL PROTECTED]:/tmp/linuz$ arch |x86_64 |[EMAIL PROTECTED]:/tmp/linuz$ `-*- Thanks. --- Changes for mkmakefile: * bugfix: _really_ generate Makefile once '!' * use shell paramenter expansion only where needed, thus Makefile's body is a little bit easy to read and write. Makefile |2 +- scripts/mkmakefile | 26 -- 2 files changed, 17 insertions(+), 11 deletions(-) Index: linux-2.6.20/scripts/mkmakefile === --- linux-2.6.20.orig/scripts/mkmakefile2007-02-14 11:53:43.972144500 +0100 +++ linux-2.6.20/scripts/mkmakefile 2007-02-14 11:55:34.879075750 +0100 @@ -9,12 +9,13 @@ # $3 - version # $4 - patchlevel +# $5 - ARCH - -test ! -r $2/Makefile -o -O $2/Makefile || exit 0 +test ! -r $2/Makefile -o ! -O $2/Makefile || exit 0 echo GEN $2/Makefile -cat EOF $2/Makefile -# Automatically generated by $0: don't edit - +echo # +# Automatically generated by +# $0 +# VERSION = $3 PATCHLEVEL = $4 @@ -22,15 +23,20 @@ PATCHLEVEL = $4 KERNELSRC:= $1 KERNELOUTPUT := $2 +ARCH := $5 + $2/Makefile + +cat EOF $2/Makefile +MAKEFLAGS+= -rR --no-print-directory -MAKEFLAGS += --no-print-directory +export ARCH -.PHONY: all \$(MAKECMDGOALS) +.PHONY: all $(MAKECMDGOALS) all: - \$(MAKE) -C \$(KERNELSRC) O=\$(KERNELOUTPUT) + $(MAKE) -C $(KERNELSRC) O=$(KERNELOUTPUT) Makefile:; -\$(filter-out all Makefile,\$(MAKECMDGOALS)) %/: - \$(MAKE) -C \$(KERNELSRC) O=\$(KERNELOUTPUT) \$@ +$(filter-out all Makefile,$(MAKECMDGOALS)) %/: + $(MAKE) -C $(KERNELSRC) O=$(KERNELOUTPUT) $@ EOF Index: linux-2.6.20/Makefile === --- linux-2.6.20.orig/Makefile 2007-02-14 11:55:50.068025000 +0100 +++ linux-2.6.20/Makefile 2007-02-14 11:56:56.756192750 +0100 @@ -358,5 +358,5 @@ outputmakefile: ifneq ($(KBUILD_SRC),) $(Q)$(CONFIG_SHELL) $(srctree)/scripts/mkmakefile \ - $(srctree) $(objtree) $(VERSION) $(PATCHLEVEL) + $(srctree) $(objtree) $(VERSION) $(PATCHLEVEL) $(ARCH) endif - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.20 13/14] nfnetlink_log: fix reference counting
On Tue, Feb 13, 2007 at 01:58:34PM +0100, Patrick McHardy wrote:
Micha³ Miros³aw wrote:
Fix reference counting (memory leak) problem in __nfulnl_send() and callers
related to packet queueing.
Signed-off-by: Michał Mirosław [EMAIL PROTECTED]
--- linux-2.6.20/net/netfilter/nfnetlink_log.c.11 2007-02-12
17:35:50.0 +0100
+++ linux-2.6.20/net/netfilter/nfnetlink_log.c 2007-02-12
17:58:01.0 +0100
@@ -223,6 +223,11 @@ _instance_destroy2(struct nfulnl_instanc
spin_lock_bh(inst-lock);
if (inst-skb) {
+ /* timer holds one reference (we have one more) */
+ if (timer_pending(inst-timer)) {
+ del_timer(inst-timer);
+ instance_put(inst);
This should be done outside of the locked section and using
del_timer_sync to make sure the timer is not already active
and waiting for the lock.
I found another solution, as this won't work (I explained the case in my
reply to your comment on 07/10). I noticed that we should just check
what del_timer() returns instead of timer_pending().
Heres the patch:
Fix reference counting (memory leak) problem in __nfulnl_send() and callers
related to packet queueing.
Signed-off-by: Michał Mirosław [EMAIL PROTECTED]
--- linux-2.6.20/net/netfilter/nfnetlink_log.c.11 2007-02-12
17:35:50.0 +0100
+++ linux-2.6.20/net/netfilter/nfnetlink_log.c.12 2007-02-14
12:27:09.0 +0100
@@ -223,6 +223,9 @@ _instance_destroy2(struct nfulnl_instanc
spin_lock_bh(inst-lock);
if (inst-skb) {
+ /* timer holds one reference (we have one more) */
+ if (del_timer(inst-timer))
+ instance_put(inst);
if (inst-qlen)
__nfulnl_send(inst);
if (inst-skb) {
@@ -370,9 +373,6 @@ __nfulnl_send(struct nfulnl_instance *in
{
int status;
- if (timer_pending(inst-timer))
- del_timer(inst-timer);
-
if (!inst-skb)
return 0;
@@ -683,6 +683,9 @@ nfulnl_log_packet(unsigned int pf,
* enough room in the skb left. flush to userspace. */
UDEBUG(flushing old skb\n);
+ /* timer holds one reference (we have another one) */
+ if (del_timer(inst-timer))
+ instance_put(inst);
__nfulnl_send(inst);
}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.20 14/14] nfnetlink_log: micro-optimization: inst-skb != NULL in __nfulnl_send()
Patch updated to apply after a new version of 13/14:
No other function calls __nfulnl_send() with inst-skb == NULL than
nfulnl_timer().
Signed-off-by: Michał Mirosław [EMAIL PROTECTED]
--- linux-2.6.20/net/netfilter/nfnetlink_log.c.12 2007-02-14
12:27:09.0 +0100
+++ linux-2.6.20/net/netfilter/nfnetlink_log.c 2007-02-14 12:53:04.0
+0100
@@ -373,9 +373,6 @@ __nfulnl_send(struct nfulnl_instance *in
{
int status;
- if (!inst-skb)
- return 0;
-
if (inst-qlen 1)
inst-lastnlh-nlmsg_type = NLMSG_DONE;
@@ -399,7 +396,8 @@ static void nfulnl_timer(unsigned long d
UDEBUG(timer function called, flushing buffer\n);
spin_lock_bh(inst-lock);
- __nfulnl_send(inst);
+ if (inst-skb)
+ __nfulnl_send(inst);
spin_unlock_bh(inst-lock);
instance_put(inst);
}
-
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: [ANN] Userspace M-on-N threading model implementation. Alpha release.
Hi! How does that work? Switching between kernel threads requires going into the kernel, user level thread switches are all done in user mode. Do you have some way to change o/s threads w/o going into the kernel? But going into kernel is not very expensive on Linux. On the other side, the overhead you need to add for every single syscall that might block for the M:N threads and the associated complications which make it far harder to conform to POSIX IMHO far outweight the costs of going into the kernel for a context switch. That really wasn't my question, Arjan said that switching real threads wasn't a context switch in the hardware sense, and I was asking if I missed something. It may be cheap, but it would seem to be a context switch none-the-less. It is not reloading %cr3. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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] asus_acpi: Add support for Asus Z81SP
From: mitxael [EMAIL PROTECTED] Newsgroups: gmane.linux.kernel Subject: Re: [PATCH] asus_acpi: Add support for Asus Z81SP Date: Tue, 13 Feb 2007 22:30:29 + (UTC) Hi, And how do I can apply this patch?? I tried but i couldn't, patch is word-wrapped, try to mime-decode it first. this works only for kernel 2.6.19 or 2.6.20 too?? thank you It's against 2.6.19, but if it's working, it would work on 2.6.20 as well. If not, contact the author. - 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 9/11] Panic delay fix
On Thu 2007-02-08 07:36:12, Rusty Russell wrote: On Wed, 2007-02-07 at 12:35 +, Pavel Machek wrote: Ugh, it sounds like paravirt is more b0rken then I thought. It should always to the proper delay, then replace those udelays that are not needed on virtualized hardware with something else. Just magically defining udelay into nop is broken. We'd have to audit and figure out what udelays are for hardware and which are not, but the evidence is that the vast majority of them are for hardware and not needed for virtualization. You did not time to do the full audit, so you just did #define. Changing udelay to hardware_udelay or something all over the kernel would have delayed the paravirt_ops merge by an infinite amount 8) And here you claim you could not do the right thing, because people would notice you are doing huge search/replace without audit, and would stop you. So you simply hidden it from them :-(. Plus... udelay() should just work under virtualization, right? You get slightly slower kernel, but still working, so the full audit is not as hard as you are telling me. Just replace udelay() with hardware_udelay() on places that matter in your workload... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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: Free Linux Driver Development!
Hi! This kind of offer has _always_ been there for out-of-tree GPL drivers. I have contacted many different groups and driver authors over the years to offer my help in trying to get their code into the mainline kernel. Some take me up on the offer, others ignore it, and still others activly refuse to do so, saying they want to stay out-of-the tree (lirc is one of these examples...) I think the point is that if we are offering free development effort to write a driver which goes into mainline, maybe we should provide more than providing rules and guidelines so that people can spend engineering $$$ to get the driver into mainline. More specifically, Dave said that it seemed rude to just take the driver and send updates, but maybe the best way of dealing with out-of-tree drivers like lirc is to treat the out-of-tree drivers as a kind of spec release, and just have someone in the community forcibly take the code, fix it up, and then get it merged. Maybe it's being rude, but so is not responding to requests to get it merged. So can I treat Shem's code as a spec release, and merge it? :-). [Okay, so your position is more reasonable than expected, good; but signed-off process strongly discourages merging some code without author's cooperation.] Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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 9/11] Panic delay fix
No, not that. But the virtual keyboard I/O gets processed and converted to physical keyboard I/O when a keyboard is attached to a VM. The result is that the virtual keyboard spinning out of control causes the physical keyboard to receive the same commands, far too rapidly. So the keyboard blinks out of control and acts as if possessed by demons. Which is a good example of why breaking udelay is the wrong thing to do. I bet vmware keyboard emulation isn't the only problematic case. Alan - 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 9/11] Panic delay fix
We'd have to audit and figure out what udelays are for hardware and which are not, but the evidence is that the vast majority of them are for hardware and not needed for virtualization. Which is irrelevant since the hardware drivers won't be used in a virtualised environment with any kind of performance optimisation. Changing udelay to hardware_udelay or something all over the kernel would have delayed the paravirt_ops merge by an infinite amount 8) paravirt_ops has no business fiddling with udelay. Not only does it create more code bloat and stalls in relatively fast paths but its optimising the wrong thing anyway. My performance sucks - optimise out udelay is the wrong approach. My performance sucks, switch to the virtual block driver is the right approach, and a virtual block driver won't be using udelay anyway Alan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/11] ANNOUNCE: Syslets, generic asynchronous system call support
Hi! The boring details: Syslets consist of 'syslet atoms', where each atom represents a single system-call. These atoms can be chained to each other: serially, in branches or in loops. The return value of an executed atom is checked against the condition flags. So an atom can specify 'exit on nonzero' or 'loop until non-negative' kind of constructs. Ouch, yet another interpretter in kernel :-(. Can we reuse acpi or something? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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/11] syslets: core code
Ingo Molnar a écrit : + if (unlikely(signal_pending(t) || need_resched())) + goto stop; So, this is how you'll prevent me from running an infinite loop ;-) The attached patch adds a cond_resched() instead, to allow infinite loops without DoS. I dropped the unlikely() as it's already in the definition of signal_pending(). +asmlinkage long sys_async_wait(unsigned long min_wait_events) Here I would expect: sys_async_wait_for_all(struct syslet_atom *atoms, long nr_atoms) and sys_async_wait_for_any(struct syslet_atom *atoms, long nr_atoms). This way syslets can be used by different parts of a program without having them waiting for each other. Thanks. -- Guillaume --- linux-2.6/kernel/async.c +++ linux-2.6/kernel/async.c @@ -433,9 +433,10 @@ last_uatom = uatom; ret = __exec_atom(t, atom); - if (unlikely(signal_pending(t) || need_resched())) + if (signal_pending(t)) goto stop; + cond_resched(); uatom = next_uatom(atom, uatom, ret); if (uatom) goto run_next;
[RFC] drivers/scsi/advansys.c: Unused variable?
Hi all This may be a petite question but does anyone know what the variable false_overrun (in drivers/scsi/advansys.c) is meant for? While converting the file to generic booleans I saw it is defined without value, can get the value of 'false' and then is used in an if-statement. So even if it is defined as 0 by default the if-statement is always false. Richard Knutsson - 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: somebody dropped a (warning) bomb
Olivier Galibert [EMAIL PROTECTED] writes: On Tue, Feb 13, 2007 at 09:06:24PM +0300, Sergei Organov wrote: [...] May I suggest another definition for a warning being entirely sucks? The warning is entirely sucks if and only if it never has true positives. In all other cases it's only more or less sucks, IMHO. That means a warning that triggers on every line saying there may be a bug there does not entirely suck? You got me. This warning is indeed entirely sucks. My definition is poor. -- Sergei. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [NFS] [PATCH 001 of 9] knfsd: nfsd4: fix non-terminated string
On Tue, 2007-02-13 at 10:44 +1100, NeilBrown wrote:
From: J. Bruce Fields [EMAIL PROTECTED]
The server name is expected to be a null-terminated string, so we can't
pass in the raw client identifier.
What's more, the client identifier is just a binary, not necessarily
printable, blob. Let's just use the ip address instead. The server
name appears to exist just to help debugging by making some printk's
more informative.
Note that the string is copies into the rpc client structure, so
the pointer to the local variable does not outlive the function call.
Signed-off-by: J. Bruce Fields [EMAIL PROTECTED]
Signed-off-by: Neil Brown [EMAIL PROTECTED]
### Diffstat output
./fs/nfsd/nfs4callback.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff .prev/fs/nfsd/nfs4callback.c ./fs/nfsd/nfs4callback.c
--- .prev/fs/nfsd/nfs4callback.c 2007-02-13 09:50:26.0 +1100
+++ ./fs/nfsd/nfs4callback.c 2007-02-13 10:00:59.0 +1100
@@ -387,7 +387,6 @@ nfsd4_probe_callback(struct nfs4_client
.address= (struct sockaddr *)addr,
.addrsize = sizeof(addr),
.timeout= timeparms,
- .servername = clp-cl_name.data,
.program= program,
.version= nfs_cb_version[1]-number,
.authflavor = RPC_AUTH_UNIX,/* XXX: need
AUTH_GSS... */
@@ -397,6 +396,7 @@ nfsd4_probe_callback(struct nfs4_client
.rpc_proc = nfs4_cb_procedures[NFSPROC4_CLNT_CB_NULL],
.rpc_argp = clp,
};
+ char clientname[16];
int status;
if (atomic_read(cb-cb_set))
@@ -419,6 +419,11 @@ nfsd4_probe_callback(struct nfs4_client
memset(program-stats, 0, sizeof(cb-cb_stat));
program-stats-program = program;
+ /* Just here to make some printk's more useful: */
+ snprintf(clientname, sizeof(clientname),
+ %u.%u.%u.%u, NIPQUAD(addr.sin_addr));
can use NIPQUAD_FMT here instead of %u.%u.%u.%u.
btw, will the ip address here possibly be an ipv6 address?
+ args.servername = clientname;
+
/* Create RPC client */
cb-cb_client = rpc_create(args);
if (IS_ERR(cb-cb_client)) {
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
NFS maillist - [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nfs
--
http://blackmagic02881.wordpress.com/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] GIT 1.5.0
Junio C Hamano [EMAIL PROTECTED] writes: Andy Parkins [EMAIL PROTECTED] writes: On Wednesday 2007 February 14 03:14, Junio C Hamano wrote: - There is a configuration variable core.legacyheaders that The above two are not enabled by default and you explicitly have to ask for them, because these two features make repositories It isn't really the case that you have to _enable_ legacyheaders? It defaults to on already. You actually have to disable legacyheaders. Ah, true. What it should have stressed is that we currently default to the safer, backward compatible behaviour, and you have to explicitly ask to use more efficient but incompatible encoding by setting core.legacyheaders to false. So this will be the updated explanation. -- 8 -- diff --git a/Documentation/RelNotes-1.5.0.txt b/Documentation/RelNotes-1.5.0.txt index f0120e1..0989ded 100644 --- a/Documentation/RelNotes-1.5.0.txt +++ b/Documentation/RelNotes-1.5.0.txt @@ -25,12 +25,18 @@ Specifically, the available options are: older clients over dumb transports (e.g. http) using older versions of git will also be affected. + To let git use the new loose object format, you have to + set core.legacyheaders to false. + - Since v1.4.3, configuration repack.usedeltabaseoffset allows packfile to be created in more space efficient format, which cannot be read by git older than that version. -The above two are not enabled by default and you explicitly have -to ask for them, because these two features make repositories + To let git use the new format for packfiles, you have to + set repack.usedeltabaseoffset to true. + +The above two new features are not enabled by default and you +have explicitly to ask for them, because they make repositories unreadable by older versions of git, and in v1.5.0 we still do not enable them by default for the same reason. We will change this default probably 1 year after 1.4.2's release, when it is - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 0/2] natsemi: Support Aculab E1/T1 cPCI carrier cards
These patches add support for the Aculab E1/T1 cPCI carrier card to the natsemi driver. The first patch provides support for using the MII port with no PHY and the second adds the quirk required to configure the card. -- You grabbed my hand and we fell into it, like a daydream - or a fever. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 2/2] natsemi: Support Aculab E1/T1 PMXc cPCI carrier cards
Aculab E1/T1 PMXc cPCI carrier card cards present a natsemi on the cPCI
bus with an oversized EEPROM using a direct MII-MII connection with no
PHY. This patch adds a new device table entry supporting these cards.
Signed-Off-By: Mark Brown [EMAIL PROTECTED]
Index: linux/drivers/net/natsemi.c
===
--- linux.orig/drivers/net/natsemi.c2007-02-12 18:09:44.0 +
+++ linux/drivers/net/natsemi.c 2007-02-12 18:09:59.0 +
@@ -244,6 +244,9 @@
MII_EN_SCRM = 0x0004, /* enable scrambler (tp) */
};
+enum {
+ NATSEMI_FLAG_IGNORE_PHY = 0x1,
+};
/* array of board data directly indexed by pci_tbl[x].driver_data */
static const struct {
@@ -251,10 +254,12 @@
unsigned long flags;
unsigned int eeprom_size;
} natsemi_pci_info[] __devinitdata = {
+ { Aculab E1/T1 PMXc cPCI carrier card, NATSEMI_FLAG_IGNORE_PHY, 128 },
{ NatSemi DP8381[56], 0, 24 },
};
static const struct pci_device_id natsemi_pci_tbl[] __devinitdata = {
+ { PCI_VENDOR_ID_NS, 0x0020, 0x12d9, 0x000c, 0, 0, 0 },
{ PCI_VENDOR_ID_NS, 0x0020, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
{ } /* terminate list */
};
@@ -811,7 +816,11 @@
np-hands_off = 0;
np-intr_status = 0;
np-eeprom_size = natsemi_pci_info[chip_idx].eeprom_size;
- np-ignore_phy = 0;
+ if (natsemi_pci_info[chip_idx].flags NATSEMI_FLAG_IGNORE_PHY) {
+ np-ignore_phy = 1;
+ } else {
+ np-ignore_phy = 0;
+ }
/* Initial port:
* - If configured to ignore the PHY set up for external.
--
You grabbed my hand and we fell into it, like a daydream - or a fever.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 1/2] natsemi: Add support for using MII port with no PHY
This patch provides code paths which allow the natsemi driver to use the
external MII port on the chip but ignore any PHYs that may be attached to it.
The link state will be left as it was when the driver started and can be
configured via ethtool. Any PHYs that are present can be accessed via the MII
ioctl()s.
This is useful for systems where the device is connected without a PHY
or where either information or actions outside the scope of the driver
are required in order to use the PHYs.
Signed-Off-By: Mark Brown [EMAIL PROTECTED]
---
Previous versions of this patch exposed the new functionality as a module
option. This has been removed. Any hardware that needs this should be
identifiable by a quirk since it unlikely to behave correctly with an
unmodified driver.
Index: linux/drivers/net/natsemi.c
===
--- linux.orig/drivers/net/natsemi.c2007-02-12 17:44:33.0 +
+++ linux/drivers/net/natsemi.c 2007-02-12 18:09:44.0 +
@@ -568,6 +568,8 @@
u32 intr_status;
/* Do not touch the nic registers */
int hands_off;
+ /* Don't pay attention to the reported link state. */
+ int ignore_phy;
/* external phy that is used: only valid if dev-if_port != PORT_TP */
int mii;
int phy_addr_external;
@@ -696,7 +698,10 @@
struct netdev_private *np = netdev_priv(dev);
u32 tmp;
- netif_carrier_off(dev);
+ if (np-ignore_phy)
+ netif_carrier_on(dev);
+ else
+ netif_carrier_off(dev);
/* get the initial settings from hardware */
tmp= mdio_read(dev, MII_BMCR);
@@ -806,8 +811,10 @@
np-hands_off = 0;
np-intr_status = 0;
np-eeprom_size = natsemi_pci_info[chip_idx].eeprom_size;
+ np-ignore_phy = 0;
/* Initial port:
+* - If configured to ignore the PHY set up for external.
* - If the nic was configured to use an external phy and if find_mii
* finds a phy: use external port, first phy that replies.
* - Otherwise: internal port.
@@ -815,7 +822,7 @@
* The address would be used to access a phy over the mii bus, but
* the internal phy is accessed through mapped registers.
*/
- if (readl(ioaddr + ChipConfig) CfgExtPhy)
+ if (np-ignore_phy || readl(ioaddr + ChipConfig) CfgExtPhy)
dev-if_port = PORT_MII;
else
dev-if_port = PORT_TP;
@@ -825,7 +832,9 @@
if (dev-if_port != PORT_TP) {
np-phy_addr_external = find_mii(dev);
- if (np-phy_addr_external == PHY_ADDR_NONE) {
+ /* If we're ignoring the PHY it doesn't matter if we can't
+* find one. */
+ if (!np-ignore_phy np-phy_addr_external == PHY_ADDR_NONE) {
dev-if_port = PORT_TP;
np-phy_addr_external = PHY_ADDR_INTERNAL;
}
@@ -891,6 +900,8 @@
printk(%02x, IRQ %d, dev-dev_addr[i], irq);
if (dev-if_port == PORT_TP)
printk(, port TP.\n);
+ else if (np-ignore_phy)
+ printk(, port MII, ignoring PHY\n);
else
printk(, port MII, phy ad %d.\n,
np-phy_addr_external);
}
@@ -1571,42 +1582,45 @@
{
struct netdev_private *np = netdev_priv(dev);
void __iomem * ioaddr = ns_ioaddr(dev);
- int duplex;
+ int duplex = np-duplex;
u16 bmsr;
- /* The link status field is latched: it remains low after a temporary
-* link failure until it's read. We need the current link status,
-* thus read twice.
-*/
- mdio_read(dev, MII_BMSR);
- bmsr = mdio_read(dev, MII_BMSR);
+ /* If we are ignoring the PHY then don't try reading it. */
+ if (!np-ignore_phy) {
+ /* The link status field is latched: it remains low
+* after a temporary link failure until it's read. We
+* need the current link status, thus read twice.
+*/
+ mdio_read(dev, MII_BMSR);
+ bmsr = mdio_read(dev, MII_BMSR);
- if (!(bmsr BMSR_LSTATUS)) {
- if (netif_carrier_ok(dev)) {
+ if (!(bmsr BMSR_LSTATUS)) {
+ if (netif_carrier_ok(dev)) {
+ if (netif_msg_link(np))
+ printk(KERN_NOTICE %s: link down.\n,
+ dev-name);
+ netif_carrier_off(dev);
+ undo_cable_magic(dev);
+ }
+ return;
+ }
+ if (!netif_carrier_ok(dev)) {
if (netif_msg_link(np))
- printk(KERN_NOTICE %s:
[Xen-devel] Re: [patch 05/21] Xen-paravirt: paravirt_ops: allocate a fixmap slot
Jeremy Fitzhardinge [EMAIL PROTECTED] 14.02.07 02:36 Dan Hecht wrote: Why doesn't Xen allocate the shared_info page from the pseudo-physical space? Doesn't it already have to steal pages from the pseudo-physical space for e.g. initial page tables, console, etc? Why not do the same for shared_info, and then you don't need a reserve the fixmap slot. Unlike the pagetable pages or the console page, the shared info page doesn't have a pseudo-physical address, so in order to map it we need to directly construct a pte containing the mfn for that page. Inserting this mapping into the fixmap space seems like the easiest way to do this. It's not like a fixmap slot costs anything. Otoh there are many fixmap slots not used under Xen, perhaps it would be possible to use one of those... One slot certainly doesn't cost a lot, but many (like the IO-APIC group) may already matter, especially on PAE systems with lots of memory). Consequently, if these can't be squeezed out as needed, re-using would seem more appropriate than adding. (I would certainly favor [conditionally] removing them, but can't easily see how to do this under CONFIG_PARAVIRT. Background being that we've already been hit by those [namely the LAPIC one] remaining present, hence the build not being able to detect that accesses to the LAPIC page can't work. While no such access was ever left in the base kernel, modules are more susceptible to this, and in our case it was the [native, i.e. pre-xenoprof] oprofile driver that had been forgotten to be disabled.) Jan - 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/21] Xen-paravirt: paravirt_ops: allocate a fixmap slot
Dan Hecht wrote: Right. But that is only because Xen decides to allocate the page from the (machine) physical space, rather than from the pseudo-physical space. My question is: why doesn't Xen allocate shared_info from the pseudo-physical space? Historical reasons ... If it had, then this page wouldn't need to be treated specially. I'm not sure, but I seem to remember on 64-bit Xen/XenLinux allocated shared_info from pseudo-physical space already... Yep, the ia64 port which came later handles some things differently, specifically some magic pages are allocated more clever ;) Changing that for x86 would break existing guests though. cheers, Gerd -- Gerd Hoffmann [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/
[Xen-devel] Re: [patch 16/21] Xen-paravirt: Add code into head.S to handle being booted by Xen
@@ -528,7 +532,7 @@ ENTRY(_stext)
/*
* BSS section
*/
-.section .bss.page_aligned,w
+.section .bss.page_aligned
Why?
I got complaints about section attribute mismatches without it.
Then perhaps ... aw is meant?
+fastcall unsigned long long xen_pgd_val(pgd_t pgd)
+{
+ unsigned long long ret = pgd.pgd;
+ if (ret)
+ ret = machine_to_phys(XMADDR(ret)).paddr | 1;
Why can they be 0 here anyways?
Normally they are all considered undefined when not present
Not sure.
This should probably get sync-ed up with the page table handling changes
submitted to xen-devel yesterday. Using zero/non-zero tests in contexts
like this was always broken; should check for _PAGE_PRESENT.
Jan
-
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: [Xen-devel] Re: [patch 05/21] Xen-paravirt: paravirt_ops: allocate a fixmap slot
On Wed, Feb 14, 2007 at 08:37:26AM +, Jan Beulich wrote: Jeremy Fitzhardinge [EMAIL PROTECTED] 14.02.07 02:36 Dan Hecht wrote: Why doesn't Xen allocate the shared_info page from the pseudo-physical space? Doesn't it already have to steal pages from the pseudo-physical space for e.g. initial page tables, console, etc? Why not do the same for shared_info, and then you don't need a reserve the fixmap slot. Unlike the pagetable pages or the console page, the shared info page doesn't have a pseudo-physical address, so in order to map it we need to directly construct a pte containing the mfn for that page. Inserting this mapping into the fixmap space seems like the easiest way to do this. It's not like a fixmap slot costs anything. Otoh there are many fixmap slots not used under Xen, perhaps it would be possible to use one of those... One slot certainly doesn't cost a lot, I don't have a problem with reserving one page for this. -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 02/21] Xen-paravirt: Handle a zero-sized VT console
Jeremy Fitzhardinge wrote: If we're running under Xen, then there's no VT console. This results in vc-vc_screenbuf_size == 0, which causes alloc_bootmem to panic. Don't bother allocating a vc_screenbuf if its going to be 0 sized. NAK. The *real* problem is that the real-mode boot code never ever runs, thus SCREEN_INFO is not initialized (all zeros), and vgacon doesn't catch that case. Instead it thinks it runs on a EGA card with 0 lines and 0 columns. So better fix vgacon to catch this and switch to the 80x25 dummy console instead, patch attached. cheers, Gerd --- drivers/video/console/vgacon.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) Index: paravirt-2.6.20-hg749/drivers/video/console/vgacon.c === --- paravirt-2.6.20-hg749.orig/drivers/video/console/vgacon.c +++ paravirt-2.6.20-hg749/drivers/video/console/vgacon.c @@ -372,7 +372,8 @@ static const char *vgacon_startup(void) } /* VGA16 modes are not handled by VGACON */ - if ((ORIG_VIDEO_MODE == 0x0D) ||/* 320x200/4 */ + if ((ORIG_VIDEO_MODE == 0x00) ||/* SCREEN_INFO not initialized */ + (ORIG_VIDEO_MODE == 0x0D) ||/* 320x200/4 */ (ORIG_VIDEO_MODE == 0x0E) ||/* 640x200/4 */ (ORIG_VIDEO_MODE == 0x10) ||/* 640x350/4 */ (ORIG_VIDEO_MODE == 0x12) ||/* 640x480/4 */
Re: [PATCH 3/7] containers (V7): Add generic multi-subsystem API to containers
[EMAIL PROTECTED] wrote: This patch removes all cpuset-specific knowlege from the container system, replacing it with a generic API that can be used by multiple subsystems. Cpusets is adapted to be a container subsystem. Signed-off-by: Paul Menage [EMAIL PROTECTED] Hi, Paul, This patch fails to apply for me [EMAIL PROTECTED]:~/ocbalbir/images/kernels/containers/linux-2.6.20$ pushpatch patching file include/linux/container.h patching file include/linux/cpuset.h patching file kernel/container.c patch: malformed patch at line 640: @@ -202,15 +418,18 @@ static DEFINE_MUTEX(callback_mutex); multiuser_container does not apply Is anybody else seeing this problem? -- Balbir Singh 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: [GIT PATCH] ACPI patches for 2.6.21
Hi! Not including another /proc/acpi/ibm -like nightmare, is it? Don't worry, I am already on my way to kill /proc/acpi/ibm... :-) Great, thanks! Pavel None of the platform/hwmon/led driver model code landed there yet, but it should be available at: http://repo.or.cz/w/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git queue/waiting eventually. Note, I push a lot to that branch, and it is a stgit head, so it gets rewond if a change that makes sense in an earlier patch shows up. Great... if you want some testing, just mail me patch against mainline or whatever... (I don't think I can handle stgit). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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/11] syslets: core code
Hi Ingo, On Tue, 13 Feb 2007 15:20:35 +0100 Ingo Molnar [EMAIL PROTECTED] wrote: From: Ingo Molnar [EMAIL PROTECTED] the core syslet / async system calls infrastructure code. It occurred to me that the 32 compat code for 64 bit architectures for all this could be very hairy ... -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgp4jYBa0DQxj.pgp Description: PGP signature
Re: [PATCH 0/4] coredump: core dump masking support v2
Hi, I'm sorry that I couldn't reply you sooner. Pavel Machek wrote: Okay, I'll adopt your idea in the next version. I'm going to provide the proc entry as follows: (1) /proc/pid/core_flags/flags (2) /proc/pid/core_flags/omit_anon_shared (1) is the same as current core_flags. It is for expert users. (2) corresponds to one bit in (1). If (2) is set to 1, anonymous shared memory of the process is never dumped. Now, that's what I call an ugly interface. I considered for a while, and then I decided not to use the above-stated interfaces. Instead, I'll create just one proc entry to access to one core dump flag: /proc/pid/coredump_omit_anonymous_shared I think it is simple enough. Would you think it is still ugly? Can we simply add ulimit with boolean value, that says dump anon_shared... or not? It will be simpler and faster, because you'll not need locking. Yes, using ulimit will be simpler and faster, but less flexible. The core dump flags can be changed only before running the program. If the user modifies the program, the user will be able to change the flags anytime. But the user can't always modify the program. I need the ability to change the core dump flags anytime. Thanks, -- Hidehiro Kawai Hitachi, Ltd., Systems Development Laboratory - 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/4] coredump: core dump masking support v2
Hi! Can we simply add ulimit with boolean value, that says dump anon_shared... or not? It will be simpler and faster, because you'll not need locking. Yes, using ulimit will be simpler and faster, but less flexible. It is prefered in this case. The core dump flags can be changed only before running the program. If the user modifies the program, the user will be able to change the flags anytime. But the user can't always modify the program. You can do ulimit then exec from wrapper. I need the ability to change the core dump flags anytime. Then maybe right solution is to extend _ulimit_ to change anything anytime. But that's definitely separate patch. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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] 8250: make probing for TXEN bug a config option
On 2/14/07, Andrew Morton [EMAIL PROTECTED] wrote: On Wed, 14 Feb 2007 11:37:52 +0300 Vitaly Wool [EMAIL PROTECTED] wrote: Hmm, why? I can't think of a platform where one 8250-compatible UART is problematic and another isn't :) Is it not possible that the same kernel package can be installed on systems which do and don't need this feature? If so, we don't want to force the provider of that package to create two packages. That, plus the chances of the package creator actually knowing about this option aren't great. Generally, if it can be done at runtime it is better to do so, no? Okay, yes, I see your point. The same kernel might actually be supporting several machines. But having that as a config option doesn't look too attractive to me. What about adding a new flag to plat_serial 8250 stuff instead? Vitaly - 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 6/6] automatic tuning applied to some kernel components
ebiederm wrote: At a quick glance max_threads and max_files appear even more to be DOS limits and not tunables and even less applicable to needing any tuning at all. My gut feel is at worst these values may need a little better boot time defaults but otherwise they the should be good. Autotuning max_threads and max_files by using some sort of rate-limiter could possibly be more useful than any kind of fixed default. Thanks! -- Al - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] TOMOYO Linux 1.3.2 released
Hello! TOMOYO Linux is an access control enhancement patch utilizing struct task_struct. http://tomoyo.sourceforge.jp/ It supports 2.4.30 and later/2.6.11 and later vanilla kernels and some of distributor's kernels. Kickstarting page for CentOS 4.4, Fedora Core 6, Debian Sarge, and Ubuntu 6.10 are available at http://tomoyo.sourceforge.jp/en/1.3.2/1st-step/ . You can feel what TOMOYO Linux is even if you are not using distributions listed above. I'm sorry for using this ml for advertisement purpose, but I'm also searching for developers. Please reply if you are interested in and wish to help developing/verifying TOMOYO Linux. Thank you. - 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: PROBLEM: 2.6.19.1 Oops while doing Disk IO + playing sound, 2.6.20 too
On Sun 11-02-07 14:59:53, Frank Hartmann wrote:
Jan Kara [EMAIL PROTECTED] writes:
OK, thanks for the news. Please, write me when you try out 2.6.20. Just
if it rings bell to someone on this list: It looks like the page had no
buffers but PagePrivate was set. Strange.
Hi Jan,
below is what I got using 2.6.20.
Is there any correlation to my previous reports? Should I focus
testing memory/disks/etc. further(and how?)? Or should I focus modifying
kernel
parameters(and which)?
Yes I see some correlation. Again it seems there is a problem with buffers
attached to a page which got truncated but Private flag of the page stayed.
It's probably not important but just out of curiosity - do you have
CONFIG_LBD (large block device) set? I'd just like to verify that page_bufs
was NULL when it was passed to walk_page_buffers().
You said 2.6.17 worked for you, didn't you? How long does it take to
reproduce the problem? If it is reasonably easy (e.g. a few hours), could
you trace back when the problem started happening? If you could narrow that
problem down to a single patch (using git-bisect), that would be great.
Bye
Honza
Feb 11 14:30:47 fantasio kernel: BUG: unable to handle kernel NULL pointer
dereference at virtual address 002d
Feb 11 14:30:47 fantasio kernel: printing eip:
Feb 11 14:30:47 fantasio kernel: e0c55b16
Feb 11 14:30:47 fantasio kernel: *pde =
Feb 11 14:30:47 fantasio kernel: Oops: [#1]
Feb 11 14:30:48 fantasio kernel: Modules linked in: cbc blkcipher binfmt_misc
bnep rfcomm l2cap nfs nfsd exportfs lockd sunrpc ip_tables bridge llc
cryptoloop loop sha256 aes it87 hwmon_vid i2c_isa i2c_core md5 ipv6 af_packet
radeon drm dm_crypt dm_mod snd_via82xx snd_ac97_codec ac97_bus snd_pcm_oss
snd_mixer_oss snd_pcm snd_timer snd_page_alloc analog snd_mpu401_uart rtc
gameport snd_rawmidi snd via_agp agpgart prism54 8250_pnp 8250 serial_core
evdev soundcore firmware_class sd_mod ext3 jbd mbcache raid1 raid0 multipath
linear md_mod ide_cd cdrom ide_disk usbhid usb_storage via82cxxx ide_core
via_rhine mii ehci_hcd uhci_hcd usbcore sym53c8xx scsi_transport_spi scsi_mod
unix
Feb 11 14:30:48 fantasio kernel: CPU:0
Feb 11 14:30:48 fantasio kernel: EIP:0060:[pg0+546224918/1070154752]
Not tainted VLI
Feb 11 14:30:48 fantasio kernel: EFLAGS: 00010202 (2.6.20 #1)
Feb 11 14:30:48 fantasio kernel: EIP is at walk_page_buffers+0x1e/0x87 [ext3]
Feb 11 14:30:48 fantasio kernel: eax: c38df601 ebx: 2000 ecx:
0029 edx: c38df601
Feb 11 14:30:48 fantasio kernel: esi: 2000 edi: c38df6ec ebp:
esp: c14f5dbc
Feb 11 14:30:48 fantasio kernel: ds: 007b es: 007b ss: 0068
Feb 11 14:30:48 fantasio kernel: Process pdflush (pid: 134, ti=c14f4000
task=dfc04a70 task.ti=c14f4000)
Feb 11 14:30:48 fantasio kernel: Stack: 0029 1000 dce96734
c104f700 c38df6ec dce96734 dce96734
Feb 11 14:30:48 fantasio kernel:e0c5629b 1000 e0c561b1
c14f5e38 000e c14f5f58 000a
Feb 11 14:30:48 fantasio kernel:c104f700 000e c14f5f58 c0133584
000e 0001
Feb 11 14:30:48 fantasio kernel: Call Trace:
Feb 11 14:30:48 fantasio kernel: [pg0+546226843/1070154752]
ext3_ordered_writepage+0xcc/0x158 [ext3]
Feb 11 14:30:48 fantasio kernel: [pg0+546226609/1070154752] bget_one+0x0/0x6
[ext3]
Feb 11 14:30:48 fantasio kernel: [generic_writepages+380/690]
generic_writepages+0x17c/0x2b2
Feb 11 14:30:48 fantasio kernel: [pg0+546226639/1070154752]
ext3_ordered_writepage+0x0/0x158 [ext3]
Feb 11 14:30:48 fantasio kernel: [do_writepages+41/48]
do_writepages+0x29/0x30
Feb 11 14:30:48 fantasio kernel: [__sync_single_inode+81/406]
__sync_single_inode+0x51/0x196
Feb 11 14:30:48 fantasio kernel: [__writeback_single_inode+312/320]
__writeback_single_inode+0x138/0x140
Feb 11 14:30:48 fantasio kernel: [schedule_timeout+121/141]
schedule_timeout+0x79/0x8d
Feb 11 14:30:48 fantasio kernel: [process_timeout+0/5]
process_timeout+0x0/0x5
Feb 11 14:30:48 fantasio kernel: [apic_timer_interrupt+40/48]
apic_timer_interrupt+0x28/0x30
Feb 11 14:30:48 fantasio kernel: [congestion_wait+107/117]
congestion_wait+0x6b/0x75
Feb 11 14:30:48 fantasio kernel: [autoremove_wake_function+0/51]
autoremove_wake_function+0x0/0x33
Feb 11 14:30:48 fantasio kernel: [sync_sb_inodes+361/511]
sync_sb_inodes+0x169/0x1ff
Feb 11 14:30:48 fantasio kernel: [writeback_inodes+67/100]
writeback_inodes+0x43/0x64
Feb 11 14:30:48 fantasio kernel: [pdflush+0/40] pdflush+0x0/0x28
Feb 11 14:30:48 fantasio kernel: [background_writeout+88/137]
background_writeout+0x58/0x89
Feb 11 14:30:48 fantasio kernel: [pdflush+0/40] pdflush+0x0/0x28
Feb 11 14:30:48 fantasio kernel: [__pdflush+179/309] __pdflush+0xb3/0x135
Feb 11 14:30:48 fantasio kernel:
Re: [KJ] Basics of linux kernel development.
On 14/02/07, RIz Khan [EMAIL PROTECTED] wrote: Dear Sir/Madam, I have an interview at symantec and i need to knw about Linux kernel development using C. I have done prgramming in C++ but in windows enviorment but i dont kknw nothing about linux and especially about kernel development. I would be greatfull if u can tell me something about it and recomend me a vry vry basic book. So you want to learn a new programming language (C), a new operating system (Linux) and dive into kernel development as well, all at the same time - that's no small task :) As for the C language bit, starting with KR's The C programming language, second edition is not a bad place to start. http://www.amazon.co.uk/C-Programming-Language-2nd/dp/0131103628/sr=8-1/qid=1171463251/ref=pd_ka_1/203-7856448-7676754?ie=UTF8s=books As for the linux kernel, Linux Kernel Development, second editionby Robert Love is a good introduction that gives a good overview of most aspects of the kernel. http://www.amazon.co.uk/Linux-Kernel-Development-Novell-Press/dp/0672327201/sr=1-1/qid=1171463315/ref=sr_1_1/203-7856448-7676754?ie=UTF8s=books You probably also want to read the file Documentation/HOWTO in the Linux kernel source dir (as well as all the files it refers you to - an online copy can be read here: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/HOWTO And probably also won't hurt you to read Linux in a Nutshell by Ellen Siever, Aaron Weber Stephen Figgins if you want a good general Linux reference. http://www.amazon.co.uk/Linux-Nutshell-OReilly-Ellen-Siever/dp/0596009305/ref=pd_bxgy_b_img_b/203-7856448-7676754 -- Jesper Juhl [EMAIL PROTECTED] Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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(Experimental) 0/4] Freezer based Cpu-hotplug
Hello Everybody, This is an experiment towards process_freezer based implementation of cpu-hotplug. This is mainly based on ideas of Andrew Morton, Ingo Molnar and Paul Mckenney featured in the discussion http://lkml.org/lkml/2007/1/31/323. This is an absolute bare-minimal implementation to check the feasibility of using process freezer for cpu-hotplug. The patchset comprises of four patches. o PATCH 1/4: Core implementation of freezer-based-hotplug. o PATCH 2/4: Revert changes to workqueue to make it work with the freezer-cpu-hotplug. o PATCH 3/4: Eliminate hotcpu subsystem mutexes from sched and slab. o PATCH 4/4: Eliminate lock_cpu_hotplug from the kernel. These patches have been stress tested on i386 SMP box, with cpu-hotplug operations in a tight-loop and make -jN (kernel compile) running parallely. The cpu hotplug operations have been pretty stable. Observation: - Certain threads like ksoftirqd/1, firmware.agent were not frozen during the hotplug operations. However, these were rare occurances. This implementation is by no means perfect or complete. Things that are yet to be done are as follows: - Most of Paul's suggestions including introduction of new states for process freezer like PFE_SUSPEND, PFE_KPROBES, PFE_HOTPLUG so that processes which are not concerned with these events can be exempted from being frozen. - Ensure the working of cpu_hotplug on all architectures on which it is supported. At present, it has been tested only on i386. - Updated documentation for cpu-hotplug. Any feedback would be greatly appreciated. Thanks and Regards gautham. -- Gautham R Shenoy Linux Technology Center IBM India. Freedom comes with a price tag of responsibility, which is still a bargain, because Freedom is priceless! - 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(Experimental) 1/4] freezer-cpu-hotplug core
This patch implements process_freezer based cpu-hotplug
core.
The sailent features are:
o No more (un)lock_cpu_hotplug.
o No more CPU_LOCK_ACQUIRE and CPU_LOCK_RELEASE. Hence no per-subsystem
hotcpu mutexes.
o Calls freeze_process/thaw_processes at the beginning/end of
the hotplug operation.
o Splits CPU_DEAD into two events namely
- CPU_DEAD: which will be handled while the processes are still
frozen.
- CPU_DEAD_KILL_THREADS: To be handled after we thaw_processes.
This split is required because stopping of the per-cpu threads
using kthread_stop cannot be done while the system is in the frozen
state. Hence we need subsystems which have created per-cpu threads
have to stop them once thaw_processes have been called.
o Handles CPU_DEAD and CPU_DEAD_KILL_THREADS for subsystems which
create per-cpu threads.
Points to ponder:
o Can calling CPU_DOWN_PREPARE/CPU_UP_PREPARE in the
frozen context create any dirty dependencies in the future?
o Can the SYSTEM_RUNNING hack in _cpu_up be avoided by some cleaner means.
Signed-off-by : Srivatsa Vaddagiri [EMAIL PROTECTED]
Signed-off-by : Gautham R Shenoy [EMAIL PROTECTED]
--
include/linux/notifier.h |3 --
kernel/cpu.c | 68 +++
kernel/sched.c |7 +++-
kernel/softirq.c | 10 --
kernel/softlockup.c |3 +-
kernel/workqueue.c | 16 ++-
6 files changed, 58 insertions(+), 49 deletions(-)
Index: hotplug/kernel/cpu.c
===
--- hotplug.orig/kernel/cpu.c
+++ hotplug/kernel/cpu.c
@@ -14,6 +14,7 @@
#include linux/kthread.h
#include linux/stop_machine.h
#include linux/mutex.h
+#include linux/freezer.h
/* This protects CPUs going up and down... */
static DEFINE_MUTEX(cpu_add_remove_lock);
@@ -28,38 +29,15 @@ static int cpu_hotplug_disabled;
#ifdef CONFIG_HOTPLUG_CPU
-/* Crappy recursive lock-takers in cpufreq! Complain loudly about idiots */
-static struct task_struct *recursive;
-static int recursive_depth;
-
void lock_cpu_hotplug(void)
{
- struct task_struct *tsk = current;
-
- if (tsk == recursive) {
- static int warnings = 10;
- if (warnings) {
- printk(KERN_ERR Lukewarm IQ detected in hotplug
locking\n);
- WARN_ON(1);
- warnings--;
- }
- recursive_depth++;
- return;
- }
- mutex_lock(cpu_bitmask_lock);
- recursive = tsk;
+ return;
}
EXPORT_SYMBOL_GPL(lock_cpu_hotplug);
void unlock_cpu_hotplug(void)
{
- WARN_ON(recursive != current);
- if (recursive_depth) {
- recursive_depth--;
- return;
- }
- recursive = NULL;
- mutex_unlock(cpu_bitmask_lock);
+ return;
}
EXPORT_SYMBOL_GPL(unlock_cpu_hotplug);
@@ -133,7 +111,11 @@ static int _cpu_down(unsigned int cpu)
if (!cpu_online(cpu))
return -EINVAL;
- raw_notifier_call_chain(cpu_chain, CPU_LOCK_ACQUIRE, hcpu);
+ if (freeze_processes()) {
+ thaw_processes();
+ return -EBUSY;
+ }
+
err = __raw_notifier_call_chain(cpu_chain, CPU_DOWN_PREPARE,
hcpu, -1, nr_calls);
if (err == NOTIFY_BAD) {
@@ -141,8 +123,8 @@ static int _cpu_down(unsigned int cpu)
nr_calls, NULL);
printk(%s: attempt to take down CPU %u failed\n,
__FUNCTION__, cpu);
- err = -EINVAL;
- goto out_release;
+ thaw_processes();
+ return -EINVAL;
}
/* Ensure that we are not runnable on dying cpu */
@@ -151,9 +133,7 @@ static int _cpu_down(unsigned int cpu)
cpu_clear(cpu, tmp);
set_cpus_allowed(current, tmp);
- mutex_lock(cpu_bitmask_lock);
p = __stop_machine_run(take_cpu_down, NULL, cpu);
- mutex_unlock(cpu_bitmask_lock);
if (IS_ERR(p) || cpu_online(cpu)) {
/* CPU didn't die: tell everyone. Can't complain. */
@@ -161,9 +141,12 @@ static int _cpu_down(unsigned int cpu)
hcpu) == NOTIFY_BAD)
BUG();
+ set_cpus_allowed(current, old_allowed);
+ thaw_processes();
+
if (IS_ERR(p)) {
err = PTR_ERR(p);
- goto out_allowed;
+ return err;
}
goto out_thread;
}
@@ -185,13 +168,12 @@ static int _cpu_down(unsigned int cpu)
check_for_tasks(cpu);
+ thaw_processes();
+
+ if (raw_notifier_call_chain(cpu_chain, CPU_DEAD_KILL_THREADS, hcpu) ==
NOTIFY_BAD)
+ BUG();
out_thread:
err = kthread_stop(p);
-out_allowed:
-
[RFC PATCH(Experimental) 2/4] Revert changes to workqueue.c
This patch reverts all the recent workqueue hacks added to make it
hotplug safe.
Signed-off-by : Srivatsa Vaddagiri [EMAIL PROTECTED]
Signed-off-by : Gautham R Shenoy [EMAIL PROTECTED]
kernel/workqueue.c | 225 +++--
1 files changed, 98 insertions(+), 127 deletions(-)
Index: hotplug/kernel/workqueue.c
===
--- hotplug.orig/kernel/workqueue.c
+++ hotplug/kernel/workqueue.c
@@ -47,7 +47,6 @@ struct cpu_workqueue_struct {
struct workqueue_struct *wq;
struct task_struct *thread;
- int should_stop;
int run_depth; /* Detect run_workqueue() recursion depth */
} cacheline_aligned;
@@ -65,7 +64,7 @@ struct workqueue_struct {
/* All the per-cpu workqueues on the system, for hotplug cpu to add/remove
threads to each one as cpus come/go. */
-static DEFINE_MUTEX(workqueue_mutex);
+static DEFINE_SPINLOCK(workqueue_lock);
static LIST_HEAD(workqueues);
static int singlethread_cpu __read_mostly;
@@ -344,24 +343,6 @@ static void run_workqueue(struct cpu_wor
spin_unlock_irqrestore(cwq-lock, flags);
}
-/*
- * NOTE: the caller must not touch *cwq if this func returns true
- */
-static int cwq_should_stop(struct cpu_workqueue_struct *cwq)
-{
- int should_stop = cwq-should_stop;
-
- if (unlikely(should_stop)) {
- spin_lock_irq(cwq-lock);
- should_stop = cwq-should_stop list_empty(cwq-worklist);
- if (should_stop)
- cwq-thread = NULL;
- spin_unlock_irq(cwq-lock);
- }
-
- return should_stop;
-}
-
static int worker_thread(void *__cwq)
{
struct cpu_workqueue_struct *cwq = __cwq;
@@ -392,7 +373,7 @@ static int worker_thread(void *__cwq)
siginitset(sa.sa.sa_mask, sigmask(SIGCHLD));
do_sigaction(SIGCHLD, sa, (struct k_sigaction *)0);
- for (;;) {
+ while (!kthread_should_stop()) {
if (cwq-wq-freezeable) {
try_to_freeze();
if (cpu_is_offline(bind_cpu))
@@ -400,14 +381,12 @@ static int worker_thread(void *__cwq)
}
prepare_to_wait(cwq-more_work, wait, TASK_INTERRUPTIBLE);
- if (!cwq-should_stop list_empty(cwq-worklist))
+ if (list_empty(cwq-worklist))
schedule();
finish_wait(cwq-more_work, wait);
- if (cwq_should_stop(cwq))
- break;
-
- run_workqueue(cwq);
+ if (!list_empty(cwq-worklist))
+ run_workqueue(cwq);
}
return 0;
@@ -445,9 +424,6 @@ static void insert_wq_barrier(struct cpu
insert_work(cwq, barr-work, tail);
}
-/* optimization, we could use cpu_possible_map */
-static cpumask_t cpu_populated_map __read_mostly;
-
static void flush_cpu_workqueue(struct cpu_workqueue_struct *cwq)
{
if (cwq-thread == current) {
@@ -492,7 +468,7 @@ void fastcall flush_workqueue(struct wor
else {
int cpu;
- for_each_cpu_mask(cpu, cpu_populated_map)
+ for_each_online_cpu(cpu)
flush_cpu_workqueue(per_cpu_ptr(wq-cpu_wq, cpu));
}
}
@@ -552,7 +528,7 @@ void flush_work(struct workqueue_struct
else {
int cpu;
- for_each_cpu_mask(cpu, cpu_populated_map)
+ for_each_online_cpu(cpu)
wait_on_work(per_cpu_ptr(wq-cpu_wq, cpu), work);
}
}
@@ -737,43 +713,25 @@ init_cpu_workqueue(struct workqueue_stru
static int create_workqueue_thread(struct cpu_workqueue_struct *cwq, int cpu)
{
struct task_struct *p;
+ struct workqueue_struct *wq = cwq-wq;
+ const char *fmt = is_single_threaded(wq) ? %s : %s/%d;
- spin_lock_irq(cwq-lock);
- cwq-should_stop = 0;
- p = cwq-thread;
- spin_unlock_irq(cwq-lock);
-
- if (!p) {
- struct workqueue_struct *wq = cwq-wq;
- const char *fmt = is_single_threaded(wq) ? %s : %s/%d;
-
- p = kthread_create(worker_thread, cwq, fmt, wq-name, cpu);
- /*
-* Nobody can add the work_struct to this cwq,
-* if (caller is __create_workqueue)
-* nobody should see this wq
-* else // caller is CPU_UP_PREPARE
-* cpu is not on cpu_online_map
-* so we can abort safely.
-*/
- if (IS_ERR(p))
- return PTR_ERR(p);
-
- cwq-thread = p;
- if (!is_single_threaded(wq))
- kthread_bind(p, cpu);
- /*
-* Cancels affinity if the caller is CPU_UP_PREPARE.
-* Needs a cleanup, but OK.
-*/
-
[RFC PATCH(Experimental) 3/4] Revert changes to sched.c and slab.c
This patch removes the per-subsystem hotcpu mutexes from sched and
slab subsystems.
Signed-off-by : Gautham R Shenoy [EMAIL PROTECTED]
--
kernel/sched.c | 16
mm/slab.c |6 --
2 files changed, 22 deletions(-)
Index: hotplug/kernel/sched.c
===
--- hotplug.orig/kernel/sched.c
+++ hotplug/kernel/sched.c
@@ -280,7 +280,6 @@ struct rq {
};
static DEFINE_PER_CPU(struct rq, runqueues);
-static DEFINE_MUTEX(sched_hotcpu_mutex);
static inline int cpu_of(struct rq *rq)
{
@@ -4454,13 +4453,11 @@ long sched_setaffinity(pid_t pid, cpumas
struct task_struct *p;
int retval;
- mutex_lock(sched_hotcpu_mutex);
read_lock(tasklist_lock);
p = find_process_by_pid(pid);
if (!p) {
read_unlock(tasklist_lock);
- mutex_unlock(sched_hotcpu_mutex);
return -ESRCH;
}
@@ -4487,7 +4484,6 @@ long sched_setaffinity(pid_t pid, cpumas
out_unlock:
put_task_struct(p);
- mutex_unlock(sched_hotcpu_mutex);
return retval;
}
@@ -4544,7 +4540,6 @@ long sched_getaffinity(pid_t pid, cpumas
struct task_struct *p;
int retval;
- mutex_lock(sched_hotcpu_mutex);
read_lock(tasklist_lock);
retval = -ESRCH;
@@ -4560,7 +4555,6 @@ long sched_getaffinity(pid_t pid, cpumas
out_unlock:
read_unlock(tasklist_lock);
- mutex_unlock(sched_hotcpu_mutex);
if (retval)
return retval;
@@ -5483,9 +5477,6 @@ migration_call(struct notifier_block *nf
struct rq *rq;
switch (action) {
- case CPU_LOCK_ACQUIRE:
- mutex_lock(sched_hotcpu_mutex);
- break;
case CPU_UP_PREPARE:
p = kthread_create(migration_thread, hcpu, migration/%d,cpu);
@@ -5549,9 +5540,6 @@ migration_call(struct notifier_block *nf
rq-migration_thread = NULL;
break;
#endif
- case CPU_LOCK_RELEASE:
- mutex_unlock(sched_hotcpu_mutex);
- break;
}
return NOTIFY_OK;
}
@@ -6895,10 +6883,8 @@ int arch_reinit_sched_domains(void)
{
int err;
- mutex_lock(sched_hotcpu_mutex);
detach_destroy_domains(cpu_online_map);
err = arch_init_sched_domains(cpu_online_map);
- mutex_unlock(sched_hotcpu_mutex);
return err;
}
@@ -7003,12 +6989,10 @@ void __init sched_init_smp(void)
{
cpumask_t non_isolated_cpus;
- mutex_lock(sched_hotcpu_mutex);
arch_init_sched_domains(cpu_online_map);
cpus_andnot(non_isolated_cpus, cpu_possible_map, cpu_isolated_map);
if (cpus_empty(non_isolated_cpus))
cpu_set(smp_processor_id(), non_isolated_cpus);
- mutex_unlock(sched_hotcpu_mutex);
/* XXX: Theoretical race here - CPU may be hotplugged now */
hotcpu_notifier(update_sched_domains, 0);
Index: hotplug/mm/slab.c
===
--- hotplug.orig/mm/slab.c
+++ hotplug/mm/slab.c
@@ -1179,9 +1179,6 @@ static int __cpuinit cpuup_callback(stru
int memsize = sizeof(struct kmem_list3);
switch (action) {
- case CPU_LOCK_ACQUIRE:
- mutex_lock(cache_chain_mutex);
- break;
case CPU_UP_PREPARE:
/*
* We need to do this right in the beginning since
@@ -1342,9 +1339,6 @@ free_array_cache:
drain_freelist(cachep, l3, l3-free_objects);
}
break;
- case CPU_LOCK_RELEASE:
- mutex_unlock(cache_chain_mutex);
- break;
}
return NOTIFY_OK;
bad:
--
Gautham R Shenoy
Linux Technology Center
IBM India.
Freedom comes with a price tag of responsibility, which is still a bargain,
because Freedom is priceless!
-
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(Experimental) 4/4] Rip out lock_cpu_hotplug from linux.
This patch rips out lock_cpu_hotplug from the kernel.
Good Riddance!! (hopefully :) )
Signed-off-by : Gautham R Shenoy [EMAIL PROTECTED]
--
arch/i386/kernel/cpu/mtrr/main.c |6 --
arch/i386/kernel/microcode.c |8
arch/mips/kernel/mips-mt.c |5 -
arch/powerpc/platforms/pseries/hotplug-cpu.c |5 -
arch/powerpc/platforms/pseries/rtasd.c |4
include/linux/cpu.h | 20
kernel/cpu.c | 17 -
kernel/rcutorture.c |3 ---
kernel/stop_machine.c|3 ---
net/core/flow.c |2 --
10 files changed, 73 deletions(-)
Index: hotplug/include/linux/cpu.h
===
--- hotplug.orig/include/linux/cpu.h
+++ hotplug/include/linux/cpu.h
@@ -76,18 +76,6 @@ extern struct sysdev_class cpu_sysdev_cl
#ifdef CONFIG_HOTPLUG_CPU
/* Stop CPUs going up and down. */
-static inline void cpuhotplug_mutex_lock(struct mutex *cpu_hp_mutex)
-{
- mutex_lock(cpu_hp_mutex);
-}
-
-static inline void cpuhotplug_mutex_unlock(struct mutex *cpu_hp_mutex)
-{
- mutex_unlock(cpu_hp_mutex);
-}
-
-extern void lock_cpu_hotplug(void);
-extern void unlock_cpu_hotplug(void);
#define hotcpu_notifier(fn, pri) { \
static struct notifier_block fn##_nb = \
{ .notifier_call = fn, .priority = pri }; \
@@ -100,14 +88,6 @@ int cpu_down(unsigned int cpu);
#else /* CONFIG_HOTPLUG_CPU */
-static inline void cpuhotplug_mutex_lock(struct mutex *cpu_hp_mutex)
-{ }
-static inline void cpuhotplug_mutex_unlock(struct mutex *cpu_hp_mutex)
-{ }
-
-#define lock_cpu_hotplug() do { } while (0)
-#define unlock_cpu_hotplug() do { } while (0)
-#define lock_cpu_hotplug_interruptible() 0
#define hotcpu_notifier(fn, pri) do { (void)(fn); } while (0)
#define register_hotcpu_notifier(nb) do { (void)(nb); } while (0)
#define unregister_hotcpu_notifier(nb) do { (void)(nb); } while (0)
Index: hotplug/kernel/cpu.c
===
--- hotplug.orig/kernel/cpu.c
+++ hotplug/kernel/cpu.c
@@ -18,7 +18,6 @@
/* This protects CPUs going up and down... */
static DEFINE_MUTEX(cpu_add_remove_lock);
-static DEFINE_MUTEX(cpu_bitmask_lock);
static __cpuinitdata RAW_NOTIFIER_HEAD(cpu_chain);
@@ -27,22 +26,6 @@ static __cpuinitdata RAW_NOTIFIER_HEAD(c
*/
static int cpu_hotplug_disabled;
-#ifdef CONFIG_HOTPLUG_CPU
-
-void lock_cpu_hotplug(void)
-{
- return;
-}
-EXPORT_SYMBOL_GPL(lock_cpu_hotplug);
-
-void unlock_cpu_hotplug(void)
-{
- return;
-}
-EXPORT_SYMBOL_GPL(unlock_cpu_hotplug);
-
-#endif /* CONFIG_HOTPLUG_CPU */
-
/* Need to know about CPUs going up/down? */
int __cpuinit register_cpu_notifier(struct notifier_block *nb)
{
Index: hotplug/arch/i386/kernel/cpu/mtrr/main.c
===
--- hotplug.orig/arch/i386/kernel/cpu/mtrr/main.c
+++ hotplug/arch/i386/kernel/cpu/mtrr/main.c
@@ -346,8 +346,6 @@ int mtrr_add_page(unsigned long base, un
error = -EINVAL;
replace = -1;
- /* No CPU hotplug when we change MTRR entries */
- lock_cpu_hotplug();
/* Search for existing MTRR */
mutex_lock(mtrr_mutex);
for (i = 0; i num_var_ranges; ++i) {
@@ -403,7 +401,6 @@ int mtrr_add_page(unsigned long base, un
error = i;
out:
mutex_unlock(mtrr_mutex);
- unlock_cpu_hotplug();
return error;
}
@@ -492,8 +489,6 @@ int mtrr_del_page(int reg, unsigned long
return -ENXIO;
max = num_var_ranges;
- /* No CPU hotplug when we change MTRR entries */
- lock_cpu_hotplug();
mutex_lock(mtrr_mutex);
if (reg 0) {
/* Search for existing MTRR */
@@ -534,7 +529,6 @@ int mtrr_del_page(int reg, unsigned long
error = reg;
out:
mutex_unlock(mtrr_mutex);
- unlock_cpu_hotplug();
return error;
}
/**
Index: hotplug/arch/i386/kernel/microcode.c
===
--- hotplug.orig/arch/i386/kernel/microcode.c
+++ hotplug/arch/i386/kernel/microcode.c
@@ -435,7 +435,6 @@ static ssize_t microcode_write (struct f
return -EINVAL;
}
- lock_cpu_hotplug();
mutex_lock(microcode_mutex);
user_buffer = (void __user *) buf;
@@ -446,7 +445,6 @@ static ssize_t microcode_write (struct f
ret = (ssize_t)len;
mutex_unlock(microcode_mutex);
- unlock_cpu_hotplug();
return ret;
}
@@ -609,14 +607,12 @@ static ssize_t reload_store(struct sys_d
old = current-cpus_allowed;
- lock_cpu_hotplug();
Re: [RFC PATCH(Experimental) 2/4] Revert changes to workqueue.c
On Wed, Feb 14, 2007 at 08:13:05PM +0530, Gautham R Shenoy wrote: This patch reverts all the recent workqueue hacks added to make it hotplug safe. Oleg, This patch probably needs review for any races we may have missed to account for. Also we have considered only workqueue.c present in 2.6.20-rc6-mm3, which means some recent patches in mm tree which are yet to be published arent accounted for. Also I expect almost all worker threads to be frozen for hotplug. The only exception I have found so far is kthread workqueue, which needs to remain unfrozen for cpu hotplug because kthread_create (in CPU_UP_PREPARE and stop_machine) relies on its services (while everyone else is frozen). -- Regards, vatsa - 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, RFC] adjust legacy IDE resource setting
The change to force legacy mode IDE channels' resources to fixed
non-zero values confuses (at least some versions of) X, because the
values reported by the kernel and those readable from PCI config space
aren't consistent anymore. Therefore, this patch arranges for the
respective BARs to also get updated if possible.
Signed-off-by: Jan Beulich [EMAIL PROTECTED]
--- linux-2.6.20/drivers/pci/probe.c2007-02-04 19:44:54.0 +0100
+++ 2.6.20-pci-ide-legacy/drivers/pci/probe.c 2007-02-14 15:54:58.0
+0100
@@ -639,7 +639,29 @@ static void pci_read_irq(struct pci_dev
dev-irq = irq;
}
-#define LEGACY_IO_RESOURCE (IORESOURCE_IO | IORESOURCE_PCI_FIXED)
+static void change_legacy_io_resource(struct pci_dev * dev, unsigned index,
+ unsigned start, unsigned end)
+{
+ unsigned base = start PCI_BASE_ADDRESS_IO_MASK;
+ unsigned len = (end | ~PCI_BASE_ADDRESS_IO_MASK) - base + 1;
+
+ if (!(pci_resource_flags(dev, index) IORESOURCE_IO))
+ printk(KERN_WARNING %s: cannot adjust BAR%u (not I/O)\n,
+ pci_name(dev), index);
+ else if (pci_resource_len(dev, index) != len)
+ printk(KERN_WARNING %s: cannot adjust BAR%u (size %04X)\n,
+ pci_name(dev), index, (unsigned)pci_resource_len(dev,
index));
+ else {
+ printk(KERN_INFO %s: trying to change BAR%u from %04X to
%04X\n,
+ pci_name(dev), index,
+ (unsigned)pci_resource_start(dev, index), base);
+ pci_write_config_dword(dev, PCI_BASE_ADDRESS_0 + index * 4,
base);
+ }
+ pci_resource_start(dev, index) = start;
+ pci_resource_end(dev, index) = end;
+ pci_resource_flags(dev, index) =
+ IORESOURCE_IO | IORESOURCE_PCI_FIXED |
PCI_BASE_ADDRESS_SPACE_IO;
+}
/**
* pci_setup_device - fill in class and map information of a device
@@ -692,20 +714,12 @@ static int pci_setup_device(struct pci_d
u8 progif;
pci_read_config_byte(dev, PCI_CLASS_PROG, progif);
if ((progif 1) == 0) {
- dev-resource[0].start = 0x1F0;
- dev-resource[0].end = 0x1F7;
- dev-resource[0].flags = LEGACY_IO_RESOURCE;
- dev-resource[1].start = 0x3F6;
- dev-resource[1].end = 0x3F6;
- dev-resource[1].flags = LEGACY_IO_RESOURCE;
+ change_legacy_io_resource(dev, 0, 0x1F0, 0x1F7);
+ change_legacy_io_resource(dev, 1, 0x3F6, 0x3F6);
}
if ((progif 4) == 0) {
- dev-resource[2].start = 0x170;
- dev-resource[2].end = 0x177;
- dev-resource[2].flags = LEGACY_IO_RESOURCE;
- dev-resource[3].start = 0x376;
- dev-resource[3].end = 0x376;
- dev-resource[3].flags = LEGACY_IO_RESOURCE;
+ change_legacy_io_resource(dev, 2, 0x170, 0x177);
+ change_legacy_io_resource(dev, 3, 0x376, 0x376);
}
}
break;
-
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/
Problem with 2.6.20 and highmem64
Hello, I have an issue with latest 2.6.20 kernel.. my last kernel was a 2.6.18 and I wanted to upgrade to a 2.6.20, I copied .config and did a make menuconfig, then save/quit. I compiled new kernel, all went fine. I installed it and at boot time, I had a hang just after Freeing unused kernel memory where INIT is supposed to start. After searching the web, I found that it is usually the case when wrong process type is configured.. I verified that, but all was fine there. After 10ish compiled kernel, I found that it is when I select highmem64. Diff between working and non working kernel : 181,182c181,182 # CONFIG_HIGHMEM4G is not set CONFIG_HIGHMEM64G=y --- CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set 185d184 CONFIG_X86_PAE=y 191c190 CONFIG_RESOURCES_64BIT=y --- # CONFIG_RESOURCES_64BIT is not set (I just witching highmem 4G and highmem64g). I'll attach the full .config. it used to work fine with highmem64g with a kernel 2.6.18 and 2.6.19 (I'm sure it was ok with .20-rc2 but I'll double check that). Is this a bug ? or something I did wrong ? Oh, I probably should add that this hang doesn't occur on all hardware, but it happen on Dell PE 850 at least. If you need additional informations, just ask :) config Description: Binary data
Re: [RFC PATCH(Experimental) 2/4] Revert changes to workqueue.c
On Wed, Feb 14, 2007 at 08:13:05PM +0530, Gautham R Shenoy wrote:
+ switch (action) {
+ case CPU_UP_PREPARE:
+ /* Create a new workqueue thread for it. */
+ list_for_each_entry(wq, workqueues, list) {
Its probably safe to take the workqueue (spin) lock here (and other
notifiers as well), before traversing the list.
+ cwq = per_cpu_ptr(wq-cpu_wq, hotcpu);
+ if (create_workqueue_thread(cwq, hotcpu)) {
+ printk(workqueue for %i failed\n, hotcpu);
+ return NOTIFY_BAD;
+ }
+ }
+ break;
--
Regards,
vatsa
-
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/
Measuring cpu time using getrusage
Hello, currently i'm trying to measure the cpu times for numerical algorithms written in C using two calls of getrusage() and then calculating the time difference. According to the man page of getrusage i looked at the user time of my process. Surprisingly the measured user times vary strongly depending on the system load of the machine. A heavy system load nearly doubles the measured time for my routine. Does anyone know a better way to measure the used cpu cycles of a given process (or part of a program) or can anyone give me a hint if i missed some important fact. Any help appreciated. Thank you in advance. Johann Schuster - 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] adjust legacy IDE resource setting
On Wed, 14 Feb 2007 15:05:24 + Jan Beulich [EMAIL PROTECTED] wrote: The change to force legacy mode IDE channels' resources to fixed non-zero values confuses (at least some versions of) X, because the values reported by the kernel and those readable from PCI config space aren't consistent anymore. Therefore, this patch arranges for the respective BARs to also get updated if possible. If X is getting confused fix X. Those BARs are *undefined* in legacy mode. The value in them is undefined, the results that end up there if you do write to them are undefined too. If X believes those BAR values blindly it'll do the wrong thing in some freaky cases. Which specific versions of X are problematic ? As to the implementation: start and end as passed are the real I/O values so you don't need to mask them that I can see. I've no fundamental problem with writing the BAR values back to avoid confusing some apparently broken X, but I'd like to know what X, what circumstances and that X is also getting fixed. Alan - 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(Experimental) 1/4] freezer-cpu-hotplug core
On Wed, Feb 14, 2007 at 08:12:29PM +0530, Gautham R Shenoy wrote: o Can the SYSTEM_RUNNING hack in _cpu_up be avoided by some cleaner means. Basically freeze_processes doesnt seem to work at the early stages of bootup (during smp_init) and hence the hack. One option is to investigate why it didnt work and possibly make it work at that early stage as well .. -- Regards, vatsa - 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/
atmel-wlan-driver in 2.6.20-rt5
hi to the list! i have problems getting the at76c503a-driver running on linux-2.6.20-rt5. since i did not subscribed to the list, please add my email address as CC for all postings which are related to this one, so that i receive it. the problem is this: i just build the 2.6.20 kernel and applied the realtime patch from ingo molnar: http://people.redhat.com/mingo/realtime-preempt/older/ before i was using 2.6.18 also patched with the rt-patch and everything was running fine. with the 2.6.20 i am able to build the atmel-driver but it works very unstable. the real problem is that when the atmel driver crashes, i am not able to `rmmod` and than doing modprobe again, when i type `rmmod at76_usb` in the console, just nothing happens. lately than, when i try to stop the network protocol which is started with: #!/bin/sh iwconfig wlan0 mode ad-hoc essid olsr.freifunk.net channel 10 ifconfig wlan0 104.130.30.9 ifconfig wlan0 up olsrd i don´t get the right response in the console, but the cursor moves down in a very fast speed. than i have to make a hard-reset. since i already talked to the people from debian and the developer from berlios, i guess that there is some kernel-thing going up, because if the driver is crashing, i think that i should be able to `rmmod´ but it looks like the driver crash takes the hole kernel into an crash too. here is the output of dmesg, well the last part which appears when the driver crashes: divide error: [#1] PREEMPT Modules linked in: thermal fan button processor ac battery snd_intel8x0m at76_usb uhci_hcd snd_intel8x0 snd_ac97_codec ac97_bus e100 ipw2200 ieee80211 ieee80211_crypt yenta_socket rsrc_nonstatic pcmcia_core i2c_i801 ide_cd cdrom snd_hdsp snd_pcm_oss snd_mixer_oss snd_pcm snd_page_alloc snd_hwdep snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device snd rtc CPU:0 EIP:0060:[e025dfb7]Not tainted VLI EFLAGS: 00010246 (2.6.20-rt5Centrino #1) EIP is at update_wstats+0x6c/0xb6 [at76_usb] eax: ebx: ecx: edx: esi: dea222c0 edi: dea22326 ebp: dc0d5000 esp: df681e3c ds: 007b es: 007b ss: 0068 preempt: 0001 Process softirq-tasklet (pid: 8, ti=df681000 task=c147f550 task.ti=df681000) Stack: dea224e8 0080 dc0d500c e02607b7 0001 0006 df3bc740 de9d2d40 df425000 dedbcc00 c0124d19 dea222c0 de0046fc df6c61c0 0002 0002 e022a7a5 0001 0001 0001 dc0d504d 0021 Call Trace: [e02607b7] rx_mgmt+0x80/0x113a [at76_usb] [c0124d19] __queue_work+0x54/0x5e [e022a7a5] ipw_rx_queue_restock+0x8c/0xb9 [ipw2200] [c011e357] __get_nsec_offset+0xd/0x44 [c01557d9] __kmalloc+0x73/0x7e [c02a9041] __alloc_skb+0x4f/0xf6 [e02600e1] submit_rx_urb+0x1d6/0x26f [at76_usb] [c01135c8] __activate_task+0x1c/0x28 [e02656d0] rx_tasklet+0x10bc/0x1146 [at76_usb] [c012767e] autoremove_wake_function+0x15/0x35 [c01132b4] __wake_up_common+0x32/0x55 [c0114c1a] __wake_up+0x36/0x59 [c011b390] __tasklet_action+0xe2/0x121 [c030d752] schedule+0xe0/0xfa [c011b79d] ksoftirqd+0x0/0x14f [c011b86d] ksoftirqd+0xd0/0x14f [c01275ae] kthread+0xa0/0xca [c012750e] kthread+0x0/0xca [c0103857] kernel_thread_helper+0x7/0x10 === Code: 86 a0 07 00 00 0f af 86 a4 07 00 00 0f b6 5f 01 0f af d8 a1 60 c3 3a c0 e8 05 cd eb df 89 c2 89 d8 2b 96 a8 07 00 00 89 d1 31 d2 f7 f1 88 46 66 a1 60 c3 3a c0 e8 e8 cc eb df c7 86 a4 07 00 00 EIP: [e025dfb7] update_wstats+0x6c/0xb6 [at76_usb] SS:ESP 0068:df681e3c 3ipw2200: Failed to send SCAN_ABORT: Command timed out. ipw2200: Failed to send CARD_DISABLE: Command timed out. ipw2200: Failed to send TX_POWER: Command timed out. ipw2200: Failed to send TX_POWER: Command timed out. ipw2200: Failed to send TX_POWER: Command timed out. /home/nowhiskey/software/wlan/at76c503a/at76c503.c: wlan0: lost beacon bssid 02:ca:ff:ee:ba:be ipw2200: Failed to send TX_POWER: Command timed out. ipw2200: Failed to send TX_POWER: Command timed out. ipw2200: Unable to initialize device after 5 attempts. ipw2200: Failed to up device [EMAIL PROTECTED]:~$ and here is another one, they differ a little: divide error: [#1] PREEMPT Modules linked in: thermal fan button processor ac battery snd_intel8x0m at76_usb uhci_hcd snd_intel8x0 snd_ac97_codec ac97_bus e100 ipw2200 ieee80211 ieee80211_crypt yenta_socket rsrc_nonstatic pcmcia_core i2c_i801 ide_cd cdrom snd_hdsp snd_pcm_oss snd_mixer_oss snd_pcm snd_page_alloc snd_hwdep snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device snd rtc CPU:0 EIP:0060:[e025dfb7]Not tainted VLI EFLAGS: 00010246 (2.6.20-rt5Centrino #1) EIP is at update_wstats+0x6c/0xb6 [at76_usb] eax: 02bc ebx: 02bc ecx: edx: esi: dde412c0 edi: dde41326 ebp: dd535000 esp: df681e3c ds: 007b es: 007b ss: 0068 preempt: 0001 Process softirq-tasklet
Re: [PATCH, RFC] adjust legacy IDE resource setting
Alan [EMAIL PROTECTED] 14.02.07 16:40 On Wed, 14 Feb 2007 15:05:24 + Jan Beulich [EMAIL PROTECTED] wrote: The change to force legacy mode IDE channels' resources to fixed non-zero values confuses (at least some versions of) X, because the values reported by the kernel and those readable from PCI config space aren't consistent anymore. Therefore, this patch arranges for the respective BARs to also get updated if possible. If X is getting confused fix X. Those BARs are *undefined* in legacy mode. The value in them is undefined, the results that end up there if you do write to them are undefined too. If X believes those BAR values blindly it'll do the wrong thing in some freaky cases. Which specific versions of X are problematic ? The one I ran into problems with is reporting X Window System Version 6.9.0 Release Date: 21 December 2005 (used in SLES10, the specific package version is xorg-x11-6.9.0-50.14) As to the implementation: start and end as passed are the real I/O values so you don't need to mask them that I can see. The masking is done primarily to (a) calculate the correct length (from a BAR's perspective), as I don't want to write the BAR if its length doesn't match the expectation, and (b) to properly report the new value in the printk. I've no fundamental problem with writing the BAR values back to avoid confusing some apparently broken X, but I'd like to know what X, what circumstances and that X is also getting fixed. Of course I also opened a bug against X, as I too think it's doing something wrong here. Jan - 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] adjust legacy IDE resource setting
The masking is done primarily to (a) calculate the correct length (from a BAR's perspective), as I don't want to write the BAR if its length doesn't match the expectation, and (b) to properly report the new value in the printk. Ok I guess you have to do something like that since you can't properly encode BAR 1 and BAR 3. Of course I also opened a bug against X, as I too think it's doing something wrong here. If you can add a comment about why it is done (X problem) then it looks fine to me. Alan - 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/
no swap!
Hi ! After compiling the kernel, I discover that my computer don't use the swap. So, I try a cat .config |grep SW, and I got : CONFIG_SWAP=y # CONFIG_X86_VISWS is not set CONFIG_X86_BSWAP=y CONFIG_SUSPEND2_SWAP=y CONFIG_SUSPEND2_REPLACE_SWSUSP=y # CONFIG_AGP_SWORKS is not set CONFIG_USB_AUERSWALD=m This is my fstab : # /etc/fstab: static file system information. # # file system mount point type options dump pass proc/proc procdefaults0 0 # /dev/hda1 -- converted during upgrade to edgy UUID=c0808eb9-790a-4a20-a3a2-26a4204d0fb2 / ext3 defaults,errors=remount-ro 0 1 # /dev/hda5 -- converted during upgrade to edgy UUID=dfcca30e-3b78-4110-b578-9b8835ecf062 none swap sw 0 0 #/dev/hda5 noneswapsw 0 0 /dev/hdc/media/cdrom0 udf,iso9660 user,noauto 0 0 /dev/fd0/media/floppy0 autorw,user,noauto 0 0 Is it a problem of LVM or RAID ? I don't understand that very well... Thanks a lot, Thibaud. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] [RFC][PATCH] PM: Document requirements for basic PM support in drivers
On Tue, 2007-02-13 at 10:47 +1100, ext Nigel Cunningham wrote: Hi. On Tue, 2007-02-13 at 00:23 +0100, Rafael J. Wysocki wrote: Hi, Here's my attempt to document the requirements with respect to the basic PM support in drivers and the testing of that. Comments welcome. Greetings, Rafael --- Documentation/SubmittingDrivers | 10 ++ Documentation/power/drivers-testing.txt | 119 2 files changed, 129 insertions(+) Index: linux-2.6.20-git4/Documentation/SubmittingDrivers === --- linux-2.6.20-git4.orig/Documentation/SubmittingDrivers +++ linux-2.6.20-git4/Documentation/SubmittingDrivers @@ -87,6 +87,16 @@ Clarity: It helps if anyone can see how driver that intentionally obfuscates how the hardware works it will go in the bitbucket. +PM support:Since Linux is used on many portable and desktop systems, your + driver is likely to be used on such a system and therefore it + should support basic power management by implementing, if + necessary, the .suspend and .resume methods used during the + system-wide suspend and resume transitions. You should verify + that your driver correctly handles the suspend and resume, but + if you are unable to ensure that, please at least define the + .suspend method returning the -ENOSYS (Function not + implemented) error. + Control: In general if there is active maintainance of a driver by the author then patches will be redirected to them unless they are totally obvious and without need of checking. Index: linux-2.6.20-git4/Documentation/power/drivers-testing.txt === --- /dev/null +++ linux-2.6.20-git4/Documentation/power/drivers-testing.txt @@ -0,0 +1,119 @@ +Testing suspend and resume support in drivers + (C) 2007 Rafael J. Wysocki [EMAIL PROTECTED] + +Unfortunately, to effectively test the support for the system-wide suspend and +resume transitions in a driver, it is necessary to suspend and resume a fully +functional system with this driver loaded. Moreover, that should be done many +times, preferably many times in a row, and separately for the suspend to disk +(STD) and the suspend to RAM (STR) transitions, because each of these cases +involves different ordering of operations and different interactions with the +machine's BIOS. + +Of course, for this purpose the test system has to be known to suspend and +resume without the driver being tested. Thus, if possible, you should first +resolve all suspend/resume-related problems in the test system before you start +testing the new driver. + +I. Preparing the test system + +1. To verify that the STD works, you can try to suspend in the reboot mode: + +# echo reboot /sys/power/disk +# echo disk /sys/power/state + +and the system should suspend, reboot, resume and get back to the command prompt +where you have started the transition. If that happens, the STD is most likely +to work correctly, but you can repeat the test a couple of times in a row for +confidence. You should also test the platform and shutdown modes of I would say you need to repeat the test at least a couple of times..., perhaps adding something along the lines of This is necessary because some problems only show up on a second attempt at suspending and resuming a driver. You can think of it as the driver coming back 'dazed and confused' after the first cycle, and only being properly killed by the second attempt. at least a couple of times sounds very optimistic :-D +suspend: + +# echo platform /sys/power/disk +# echo disk /sys/power/state + +or + +# echo shutdown /sys/power/disk +# echo disk /sys/power/state + +in which cases you will have to press the power button to make the system +resume. If that works, you are ready to test the STD with the new driver +loaded. Otherwise, you have to identify what is wrong. + +a) To verify if there are any drivers that cause problems you can run the STD +in the test mode: + +# echo test /sys/power/disk +# echo disk /sys/power/state + +in which case the system should freeze tasks, suspend devices, disable nonboot +CPUs (if any), wait for 5 seconds, enable nonboot CPUs, resume devices, thaw +tasks and return to your command prompt. If that fails, most likely there is +a driver that fails to either suspend or resume (in the latter case the system +may hang or be unstable after the test, so please take that into consideration). +To find this driver, you can carry out a binary search according to the rules: +- if the test fails, unload a half of
Re: no swap!
On 2/14/07, Thibaud Hulin [EMAIL PROTECTED] wrote: Hi ! distro related: check https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/66637 and all the duplicates After compiling the kernel, I discover that my computer don't use the swap. So, I try a cat .config |grep SW, and I got : CONFIG_SWAP=y # CONFIG_X86_VISWS is not set CONFIG_X86_BSWAP=y CONFIG_SUSPEND2_SWAP=y CONFIG_SUSPEND2_REPLACE_SWSUSP=y # CONFIG_AGP_SWORKS is not set CONFIG_USB_AUERSWALD=m This is my fstab : # /etc/fstab: static file system information. # # file system mount point type options dump pass proc/proc procdefaults0 0 # /dev/hda1 -- converted during upgrade to edgy UUID=c0808eb9-790a-4a20-a3a2-26a4204d0fb2 / ext3 defaults,errors=remount-ro 0 1 # /dev/hda5 -- converted during upgrade to edgy UUID=dfcca30e-3b78-4110-b578-9b8835ecf062 none swap sw 0 0 #/dev/hda5 noneswapsw 0 0 /dev/hdc/media/cdrom0 udf,iso9660 user,noauto 0 0 /dev/fd0/media/floppy0 autorw,user,noauto 0 0 Is it a problem of LVM or RAID ? I don't understand that very well... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bug in current -git tree causing dbus and gnome to chew up cpu time
On Wed, Feb 14, 2007 at 12:13:52PM +0100, Alessandro Suardi wrote: On 2/14/07, Andreas Gruenbacher [EMAIL PROTECTED] wrote: Hi, I've described the problem and possible fixes in the Re: [PATCH] Fix d_path for lazy unmounts thread, Message-Id: [EMAIL PROTECTED] Yes, I saw that. But there isn't any patch for me to test, and my userspace remains broken. Please don't get me wrong - I'm not bitching about this, but I will effectively not be able to test newer snapshots until either a fix for this new bug gets in, or the commit that introduced the bug gets reverted. The commit was reverted, the latest git tree should work just fine. thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/8] lguest: trivial guest network driver
On Wed, Feb 14, 2007 at 03:47:55PM +1100, Rusty Russell wrote:
It's also used to generate dma structs for outgoing packets. In that
case, skb_headlen() == 0:
I see, in that case you're guaranteed to have no fragments.
Still it feels a bit weird to have a length field that only
applies to the header part.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] GIT 1.5.0
On Tuesday, February 13, 2007 at 19:14:16 (-0800) Junio C Hamano writes: The latest feature release GIT 1.5.0 is available at the usual places: ... I do think worth pointing out that, quite significantly, you can now use git-daemon to push changes into a repo, something very handy for private networks. This is enabled by passing the --enable=receive-pack to the git-daemon (usually in the [x]?inetd configuration). This has the benefit of: 1) More efficient git transport for both pushes and pulls. 2) A less ugly URL to use: git://server/repo, instead of, say, ssh+git://server/path/to/repos/repo. 3) Ability to easily move your repo without changing the URL in each client, by changing the URL in the git-daemon config file (xinetd) --- say, if you want to move your repo to a striped disk, or similar. Bill - 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] Fix d_path for lazy unmounts
On Wed, 14 Feb 2007, Andreas Gruenbacher wrote: Mountpoints are reported relative to the chroot if they are reachable from the chroot, and relative to the namespace they are defined in otherwise. This is big nonsense, but it's unclear to me how to best fix it: Well, it's also what a traditional pwd implementation would do, so it's not nonsense in that sense. - don't report unreachable mount points, - somehow indicate which mountpoints are reachable and which are not, like by prepending a question flag? We could prepend another '/' (so that you'd have a path that starts with //). That's still a legal path, but it's also somethign that even POSIX says is valid to mean something else (eg //ftp/.. or //socket/.. to escape into another namespace). But the fact is, some things just want a path. And it's generally *better* to get them a - path that looks ok and starts from '/' than it is to give them something that looks strange and doesn't start from root (because the latter gives many many more possible attack vectors: if somebody actually looks up the path, a bad user can much more easily fake a relative path than fake an absolute one). - the path we've historically always given them. What's the point in reporting the rootfs at all -- it's never reachable to an ordinary process? All the paths are generally useful for USER INFORMATION. That's the primary use of paths for anything but getcwd(). And the primary use for getcwd() is to do the same thing that any traditional cwd implementation has done, except faster (and _possibly_ better, but compatibility is more important than extensions - so the better is mainly an issue about non-readable or non-executable path component that we can show, and about being able to tell _how_ you got to a point that has multiple ways of getting there). 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: smp and irq conflict
Benny Amorsen wrote: BD == Bill Davidsen [EMAIL PROTECTED] writes: BD You may be able to move one board to another slot, but looking at BD the bandwidth I suspect you may need a server motherboard with BD multiple busses, preferably running at 66MHz 64bit. I don't think BD this is a interrupt problem, but you can just try capture on two BD channels which share an interrupt, like bttv0 and bttv7 to verify BD that. 66MHz 64bit isn't much fun when the capture cards are 33MHz 32bit. It doesn't help the video to bus, but multiple busses to give a bus per card would help, and assuming the data are being saved to disk using a decent disk controller which can use the additional bandwidth, at least some conflict is avoided or reduced. This is really a case of using general hardware to the utmost, I suspect more m/b bandwidth will be needed somewhere. -- bill davidsen [EMAIL PROTECTED] CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - 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/
