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/
Re: [ANNOUNCE] GIT 1.5.0
On Wed, 14 Feb 2007, Bill Lear wrote: This is enabled by passing the --enable=receive-pack to the git-daemon (usually in the [x]?inetd configuration). This has the benefit of: Before you list the benefits, you should always talk about the lack of security! Let nobody enable it without realizing the dangers! Tell people to _only_ do this inside a company firewall, and even then, only if you trust everybody. 2) A less ugly URL to use: git://server/repo, instead of, say, ssh+git://server/path/to/repos/repo. Why do people use that silly ssh+git:// format? It's a cogito thing. Native git has never done it, and only supports it because cogito thought it must make sense. The native git ssh URL is exactly the normal ssh URL: server:/path/to/repos/repo and if you really want to use the xxx:// format, you might as well just use ssh://server/path/to/repos/repo which should also work fine. Linus PS. This is the commit message that added git+ssh://: Author: Linus Torvalds [EMAIL PROTECTED] Date: Fri Oct 14 17:14:56 2005 -0700 Support git+ssh:// and ssh+git:// URL It seemed to be such a stupid syntax. It's both what ssh:// means, and it's what not specifying a protocol at _all_ means. But hey, since we already have two ways of saying use ssh with pack-files, here's two more. so it was deemed stupid from the get-go, and isn't even some legacy thing. It's purely a cogito people thought it makes sense to point out that it's _both_ native git _and_ ssh protocol. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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 hostap_cs (Netgear MA401)
I've got the ieee80211 and hostap code compiled as modules for my MA401 card, and the system locks up when I insert the card. No keyboard, no sysrq, no logs after reboot, no nothing. The same configuration works fine under 2.6.19. If I first insert my old 3com 3c589 card, then eject it and rmmod the 3c589_cs module, the insertion of the MA401 works completely. Preloading the modules with insmod or modprobe doesn't help. Was there a change in the pcmcia or networking initialization code between 2.6.19 and 2.6.20? Here are the relevant modules. #/sbin/lsmod Module Size Used by ieee80211_crypt_wep 5248 0 hostap_cs 59220 3 hostap110852 1 hostap_cs ieee80211_crypt 5632 2 ieee80211_crypt_wep,hostap ... pcmcia 29280 1 hostap_cs firmware_class 9664 1 pcmcia yenta_socket 26892 4 ... rsrc_nonstatic 13248 1 yenta_socket pcmcia_core39056 4 \ hostap_cs,pcmcia,yenta_socket,rsrc_nonstatic - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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 of 4] Generic AIO by scheduling stacks
On Sat, 10 Feb 2007 18:49:56 -0800, Linus Torvalds wrote: And I actually talked about that in one of the emails already. There is no way you can beat an event-based thing for things that _are_ event-based. That means mainly networking. For things that aren't event-based, but based on real IO (ie filesystems etc), event models *suck*. They suck because the code isn't amenable to it in the first place (ie anybody who thinks that a filesystem is like a network stack and can be done as a state machine with packets is just crazy!). So you would be crazy to makea web server that uses this to handle _all_ outstanding IO. Network connections are often slow, and you can have tens of thousands outstanding (and some may be outstanding for hours until they time out, if ever). But that's the whole point: you can easily mix the two, as given in several examples already (ie you can easily make the main loop itself basically do just I don't see any replies to this, so here's my 2¢. The simple model of what a webserver does when sending static data is: 1. local_disk_fd = open() 2. fstat(local_disk_fd) 3. TCP_CORK on 4. send_headers(); 5. LOOP 5a. sendfile(network_con_fd, local_disk_fd) 5b. epoll(network_con_fd) 6. TCP_CORK off ...and here's my personal plan (again, somewhat simplified), which I think will be better: 7. helper_proc_pipe_fd = DO open() + fstat() 8. read_stat_event_data(helper_proc_pipe_fd) 9. TCP_CORK on network_con_fd 10. send_headers(network_con_fd); 11. LOOP 11a. splice(helper_proc_pipe_fd, network_con_fd) 11b. epoll(network_con_fd helper_proc_pipe_fd) 12. TCP_CORK off network_con_fd ...where the helper proc is doing splice() from disk to the pipe, on the other end. This, at least in theory, gives you an async webserver and zero copy disk to network[1]. My assumption is that Evgeniy's aio_sendfile() could fit into that model pretty easily, and would be faster. However, from what you've said above you're only trying to help #1 and #2 (which are likely to be cached in the app. anyway) and apps. that want to sendfile() to the network either do horrible hacks like lighttpd's AIO[2], do a read+write copy loop with AIO or don't use AIO. [1] And allows things like IO limiting, which aio_sendfile() won't. [2] http://illiterat.livejournal.com/2989.html -- James Antill -- [EMAIL PROTECTED] http://www.and.org/and-httpd/ -- $2,000 security guarantee http://www.and.org/vstr/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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, 14 Feb 2007, Pavel Machek wrote: Ouch, yet another interpretter in kernel :-(. Can we reuse acpi or something? Hah. You make the joke! I get it! Mwahahahaa! Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/11] ANNOUNCE: Syslets, generic asynchronous system call support
On Wed, 14 Feb 2007, Ingo Molnar wrote: * 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: IMO it'd be quite simple. We detect the service-thread full condition, *before* entering exec_atom and we queue the atom in an async_head request list. Yes, there is the chance that from the test time in sys_async_exec, to the time we'll end up entering exec_atom and down to schedule, one of the threads would become free, but IMO better that blocking sys_async_exec. - Davide - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SATA-performance part 2
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 ?? this is odd. (but encouraging).. the one thing I can imagine oprofile doing is disabling the nmi_watchdog... you can simulate the same effect by passing nmi_watchdog=0 on the kernel commandline (and there's something in /proc/sys as well to disable it at runtime) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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/7] RFC: Cell SPE logos
On Tue, 13 Feb 2007, James Simmons wrote:
Andrew please apply.
Thanks!
Andrew, I will resend the whole series again, against current linus.git.
Acked-By: James Simmons [EMAIL PROTECTED]
On Mon, 12 Feb 2007, Geert Uytterhoeven wrote:
On Wed, 31 Jan 2007, Geert Uytterhoeven wrote:
I would like to hear your opinions about the patchset below (updated
version
compared to yesterday, lkml added to the CC list).
The Cell Broadband Engine contains a 64-bit PowerPC core with 2 hardware
threads (called PPEs) and 8 Synergistic Processing Engines (called SPEs).
When booting Linux, 2 penguins logos are shown on the graphical console by
the standard frame buffer console logo code.
To emphasize the existence of the SPEs (which can be used under Linux), we
added a second row of (smaller) helper penguin logos, one for each SPE.
I attached a PNG version of the helper penguin logo for reference.
Summaries:
[PATCH 1/7] fbdev: Avoid vertical overflow when making space for the logo
[PATCH 2/7] fbdev: fb_do_show_logo() updates
[PATCH 3/7] fbdev: extract fb_show_logo_line()
[PATCH 4/7] fbdev: move logo externs to header file
[PATCH 5/7] fbdev: Add fb_append_extra_logo()
[PATCH 6/7] fbdev: SPE helper penguin logo
[PATCH 7/7] Cell: Draw SPE helper penguin logos
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: AHCI - remove probing of ata2
Greg Trounson wrote: At the risk of sounding like a me too post: I also have an Asus P5W-DH, with the following drives connected: SATA: ST3250820AS, connected to sata1 PATA: HL-DT-ST GSA-H12N, ATAPI DVD Writer, Primary master On bootup of 2.6.19 and 2.6.20, the kernel stalls for 1 minute when probing sata2, eventually giving up and continuing the boot process. There is no physical sata2 connector on the Motherboard, just solder lugs between sata1 and sata3. From other users I understand this is really a Silicon Image SIL4723 SATA to 2-Port SATA splitter. It is detected by the kernel as a disk, as below. The relevant part of the boot process looks like: ... libata version 2.00 loaded. ahci :00:1f.2: version 2.0 ACPI: PCI Interrupt :00:1f.2[B] - GSI 23 (level, low) - IRQ 22 PCI: Setting latency timer of device :00:1f.2 to 64 ahci :00:1f.2: AHCI 0001.0100 32 slots 4 ports 3 Gbps 0xf impl SATA mode ahci :00:1f.2: flags: 64bit ncq led clo pio slum part ata1: SATA max UDMA/133 cmd 0xF882A900 ctl 0x0 bmdma 0x0 irq 219 ata2: SATA max UDMA/133 cmd 0xF882A980 ctl 0x0 bmdma 0x0 irq 219 ata3: SATA max UDMA/133 cmd 0xF882AA00 ctl 0x0 bmdma 0x0 irq 219 ata4: SATA max UDMA/133 cmd 0xF882AA80 ctl 0x0 bmdma 0x0 irq 219 scsi0 : ahci ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata1.00: ATA-7, max UDMA/133, 488397168 sectors: LBA48 NCQ (depth 31/32) ata1.00: ata1: dev 0 multi count 16 ata1.00: configured for UDMA/133 scsi1 : ahci ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ...waits 20 seconds... ata2.00: qc timeout (cmd 0xec) ata2.00: failed to IDENTIFY (I/O error, err_mask=0x104) ...waits 5 seconds... ata2: port is slow to respond, please be patient (Status 0x80) ...waits 30 seconds... ata2: port failed to respond (30 secs, Status 0x80) ata2: COMRESET failed (device not ready) ata2: hardreset failed, retrying in 5 secs ...waits 5 seconds... ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata2.00: ATA-6, max UDMA/133, 640 sectors: LBA ata2.00: ata2: dev 0 multi count 1 ata2.00: configured for UDMA/133 scsi2 : ahci ata3: SATA link down (SStatus 0 SControl 300) ... A bit of poking about shows: fdisk -l /dev/sdb Disk /dev/sdb: 0 MB, 327680 bytes 255 heads, 63 sectors/track, 0 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk /dev/sdb doesn't contain a valid partition table So it presents itself as a 320k disk, filled with zeroes as below: dd if=/dev/sdb |hexdump 000 * 005 640+0 records in 640+0 records out 327680 bytes (328 kB) copied, 0.0106662 seconds, 30.7 MB/s Note that this is not a fatal error. The machine still boots eventually, but the seemingly mandatory 60 second pause makes startup rather cumbersome for the user. So far none of the suggested fixes have managed to stop ata2 from being detected. (noprobe=ata2, irqpoll, etc). I understand this problem wasn't present in 2.6.16 so the problem must lie in some patch since then. I see Tejun is working towards patches for this and I would be happy to try them here. Is this 320k of cache memory, or in any way some actual storage on the system? Have you tried to write to it out of curiosity? Seems odd that it would be detected if there were nothing at all present, although obviously it could be artifact. -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 06/11] syslets: core, documentation
On Wed, 14 Feb 2007, Russell King wrote:
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.
I was thinking about this yesterday, since I honestly thought that this
whole chaining, and conditions, and parameter lists, and argoument passed
by pointers, etc... was at the end a little clumsy IMO.
Wouldn't a syslet look better like:
long syslet(void *ctx) {
struct sctx *c = ctx;
if (open(c-file, ...) == -1)
return -1;
read();
send();
blah();
...
return 0;
}
That'd be, instead of passing a chain of atoms, with the kernel
interpreting conditions, and parameter lists, etc..., we let gcc
do this stuff for us, and we pass the clet :) pointer to sys_async_exec,
that exec the above under the same schedule-trapped environment, but in
userspace. We setup a special userspace ad-hoc frame (ala signal), and we
trap underneath task schedule attempt in the same way we do now.
We setup the frame and when we return from sys_async_exec, we basically
enter the clet, that will return to a ret_from_async, that will return
to userspace. Or, maybe we can support both. A simple single-syscall exec
in the way we do now, and a clet way for the ones that requires chains and
conditions. Hmmm?
- Davide
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ALSA PATCH] alsa-git merge request
On Wed, 14 Feb 2007, Jaroslav Kysela wrote: Linus, please do an update from: http://www.kernel.org/pub/scm/linux/kernel/git/perex/alsa.git (linus branch) Please fix your script. Not only is the http:// protocol terminally broken (use git:// or master.kernel.org instead), your (linus branch) thing is on the wrong line and hard to see. It's supposed to be something like Please pull from [the linus branch at] master.kernel.org:/pub/scm/linux/kernel/git/perex/alsa.git linus so that I don't even by mistake miss the branch-name (because it's on the same line). And http:// for git really is so broken (slow, unsafe) that you should never use it if you have any choice at all. Pulled. 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: [NFS] [PATCH 001 of 9] knfsd: nfsd4: fix non-terminated string
Ming Zhang wrote: 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.c2007-02-13 09:50:26.0 +1100 +++ ./fs/nfsd/nfs4callback.c2007-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? Some patches are in the works to build in IPv6 support. See the patch series at http://oss.oracle.com/~cel/linux-2.6/2.6.19/patches/ begin:vcard fn:Chuck Lever n:Lever;Chuck org:Oracle Corporation;Corporate Architecture Linux Projects Group email;internet:chuck dot lever at nospam oracle dot com title:Principal Member of Staff tel;work:+1 248 614 5091 x-mozilla-html:FALSE version:2.1 end:vcard
[PATCH] aio: fix kernel bug when page is temporally busy
-wrap lines are fixed. Sorry.
From Leonid Ananiev
Fix kernel bug if IO page is temporally busy:
invalidate_inode_pages2_range() returns EIOCBRETRY but not EIO.
invalidate_inode_pages2() returns EIO as earlier.
Signed-off-by: Leonid Ananiev [EMAIL PROTECTED]
---
--- linux-2.6.20/mm/truncate.c 2007-02-04 10:44:54.0 -0800
+++ linux-2.6.20p/mm/truncate.c 2007-02-08 22:56:52.0 -0800
@@ -366,7 +366,7 @@ static int do_launder_page(struct addres
* Any pages which are found to be mapped into pagetables are unmapped prior to
* invalidation.
*This is path is modified so that invalidate_inode_pages2()
returns EIO as earlier.
Wrap lines are fixed
- From Leonid Ananiev
Fix kernel bug when IO page is temporally busy:
invalidate_inode_pages2_range() returns EIOCBRETRY but not EIO.
invalidate_inode_pages2() returns EIO as earlier.
Signed-off-by: Leonid Ananiev [EMAIL PROTECTED]
---
--- linux-2.6.20/mm/truncate.c 2007-02-04 10:44:54.0 -0800
+++ linux-2.6.20p/mm/truncate.c 2007-02-08 22:56:52.0 -0800
@@ -366,7 +366,7 @@ static int do_launder_page(struct addres
* Any pages which are found to be mapped into pagetables are unmapped prior to
* invalidation.
*
- * Returns -EIO if any pages could not be invalidated.
+ * Returns -EIOCBRETRY if any pages could not be invalidated.
*/
int invalidate_inode_pages2_range(struct address_space *mapping,
pgoff_t start, pgoff_t end)
@@ -423,7 +423,7 @@ int invalidate_inode_pages2_range(struct
}
ret = do_launder_page(mapping, page);
if (ret == 0 !invalidate_complete_page2(mapping,
page))
- ret = -EIO;
+ ret = -EIOCBRETRY;
unlock_page(page);
}
pagevec_release(pvec);
@@ -444,6 +444,7 @@ EXPORT_SYMBOL_GPL(invalidate_inode_pages
*/
int invalidate_inode_pages2(struct address_space *mapping)
{
- return invalidate_inode_pages2_range(mapping, 0, -1);
+ int ret = invalidate_inode_pages2_range(mapping, 0, -1);
+ return (ret 0)?-EIO:ret;
}
EXPORT_SYMBOL_GPL(invalidate_inode_pages2);
- * Returns -EIO if any pages could not be invalidated.
+ * Returns -EIOCBRETRY if any pages could not be invalidated.
*/
int invalidate_inode_pages2_range(struct address_space *mapping,
pgoff_t start, pgoff_t end)
@@ -423,7 +423,7 @@ int invalidate_inode_pages2_range(struct
}
ret = do_launder_page(mapping, page);
if (ret == 0 !invalidate_complete_page2(mapping,
page))
- ret = -EIO;
+ ret = -EIOCBRETRY;
unlock_page(page);
}
pagevec_release(pvec);
@@ -444,6 +444,7 @@ EXPORT_SYMBOL_GPL(invalidate_inode_pages
*/
int invalidate_inode_pages2(struct address_space *mapping)
{
- return invalidate_inode_pages2_range(mapping, 0, -1);
+ int ret = invalidate_inode_pages2_range(mapping, 0, -1);
+ return (ret 0)?-EIO:ret;
}
EXPORT_SYMBOL_GPL(invalidate_inode_pages2);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [PATCH 2.6.21 review I] [4/25] x86: kernel-mode faults pollute current-thead
On Tue, Feb 13, 2007 at 07:52:54AM +, Jan Beulich wrote:
Actually, after a second round of thinking I believe there's still more to do
- your second patch missed fixing i386's do_trap() similarly to x86-64's
and, vice versa, x86-64's do_general_protection() similarly to i386's.
Sigh, here's another go at it - the full patch instead of
incrementally fixing the old one:
Index: linux-2.6/arch/i386/kernel/traps.c
===
--- linux-2.6.orig/arch/i386/kernel/traps.c
+++ linux-2.6/arch/i386/kernel/traps.c
@@ -473,8 +473,6 @@ static void __kprobes do_trap(int trapnr
siginfo_t *info)
{
struct task_struct *tsk = current;
- tsk-thread.error_code = error_code;
- tsk-thread.trap_no = trapnr;
if (regs-eflags VM_MASK) {
if (vm86)
@@ -486,6 +484,9 @@ static void __kprobes do_trap(int trapnr
goto kernel_trap;
trap_signal: {
+ tsk-thread.error_code = error_code;
+ tsk-thread.trap_no = trapnr;
+
if (info)
force_sig_info(signr, info, tsk);
else
@@ -494,8 +495,11 @@ static void __kprobes do_trap(int trapnr
}
kernel_trap: {
- if (!fixup_exception(regs))
+ if (!fixup_exception(regs)) {
+ tsk-thread.error_code = error_code;
+ tsk-thread.trap_no = trapnr;
die(str, regs, error_code);
+ }
return;
}
@@ -600,15 +604,21 @@ fastcall void __kprobes do_general_prote
}
put_cpu();
- current-thread.error_code = error_code;
- current-thread.trap_no = 13;
-
if (regs-eflags VM_MASK)
goto gp_in_vm86;
if (!user_mode(regs))
goto gp_in_kernel;
+ /*
+* We want error_code and trap_no set for userspace faults and
+* kernelspace faults which result in die(), but not
+* kernelspace faults which are fixed up. die() gives the
+* process no chance to handle the signal and notice the
+* kernel fault information, so that won't result in polluting
+* the information about previously queued, but not yet
+* delivered, fault.
+*/
current-thread.error_code = error_code;
current-thread.trap_no = 13;
force_sig(SIGSEGV, current);
@@ -621,6 +631,8 @@ gp_in_vm86:
gp_in_kernel:
if (!fixup_exception(regs)) {
+ current-thread.error_code = error_code;
+ current-thread.trap_no = 13;
if (notify_die(DIE_GPF, general protection fault, regs,
error_code, 13, SIGSEGV) == NOTIFY_STOP)
return;
Index: linux-2.6/arch/x86_64/kernel/traps.c
===
--- linux-2.6.orig/arch/x86_64/kernel/traps.c
+++ linux-2.6/arch/x86_64/kernel/traps.c
@@ -581,10 +581,19 @@ static void __kprobes do_trap(int trapnr
{
struct task_struct *tsk = current;
- tsk-thread.error_code = error_code;
- tsk-thread.trap_no = trapnr;
-
if (user_mode(regs)) {
+ /*
+* We want error_code and trap_no set for userspace faults
+* and kernelspace faults which result in die(), but
+* not kernelspace faults which are fixed up. die()
+* gives the process no chance to handle the signal
+* and notice the kernel fault information, so that
+* won't result in polluting the information about
+* previously queued, but not yet delivered, fault.
+*/
+ tsk-thread.error_code = error_code;
+ tsk-thread.trap_no = trapnr;
+
if (exception_trace unhandled_signal(tsk, signr))
printk(KERN_INFO
%s[%d] trap %s rip:%lx rsp:%lx error:%lx\n,
@@ -605,8 +614,11 @@ static void __kprobes do_trap(int trapnr
fixup = search_exception_tables(regs-rip);
if (fixup)
regs-rip = fixup-fixup;
- else
+ else {
+ tsk-thread.error_code = error_code;
+ tsk-thread.trap_no = trapnr;
die(str, regs, error_code);
+ }
return;
}
}
@@ -682,10 +694,10 @@ asmlinkage void __kprobes do_general_pro
conditional_sti(regs);
- tsk-thread.error_code = error_code;
- tsk-thread.trap_no = 13;
-
if (user_mode(regs)) {
+ tsk-thread.error_code = error_code;
+ tsk-thread.trap_no = 13;
+
if (exception_trace unhandled_signal(tsk, SIGSEGV))
printk(KERN_INFO
%s[%d]
Re: [PATCH x86 for review III] [12/29] x86_64: 32-bit ptrace mangles sixth system call argument
On Mon, Feb 12, 2007 at 05:04:54PM -0500, Chuck Ebbert wrote: See: http://lkml.org/lkml/2005/09/16/261 for the one I proposed instead. That works for me - can we get this into mainline? Jeff -- Work email - jdike at linux dot intel dot 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/
[PATCH] x86_64 ptrace32 needs PTRACE_OLDSETOPTIONS
x86_64 ptrace32 needs to support PTRACE_OLDSETOPTIONS. This patch
just converts the PTRACE_OLDSETOPTIONS request to PTRACE_SETOPTIONS
and falls through to the sys_ptrace call.
Signed-off-by: Jeff Dike [EMAIL PROTECTED]
--
arch/x86_64/ia32/ptrace32.c |2 ++
1 file changed, 2 insertions(+)
Index: linux-2.6/arch/x86_64/ia32/ptrace32.c
===
--- linux-2.6.orig/arch/x86_64/ia32/ptrace32.c
+++ linux-2.6/arch/x86_64/ia32/ptrace32.c
@@ -239,6 +239,8 @@ asmlinkage long sys32_ptrace(long reques
__u32 val;
switch (request) {
+ case PTRACE_OLDSETOPTIONS:
+ request = PTRACE_SETOPTIONS;
case PTRACE_TRACEME:
case PTRACE_ATTACH:
case PTRACE_KILL:
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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 09:52:20AM -0800, Davide Libenzi wrote: That'd be, instead of passing a chain of atoms, with the kernel interpreting conditions, and parameter lists, etc..., we let gcc do this stuff for us, and we pass the clet :) pointer to sys_async_exec, that exec the above under the same schedule-trapped environment, but in userspace. We setup a special userspace ad-hoc frame (ala signal), and we trap underneath task schedule attempt in the same way we do now. We setup the frame and when we return from sys_async_exec, we basically enter the clet, that will return to a ret_from_async, that will return to userspace. Or, maybe we can support both. A simple single-syscall exec in the way we do now, and a clet way for the ones that requires chains and conditions. Hmmm? Which is just the same as using threads. My argument is that once you look at all the details involved, what you end up arriving at is the creation of threads. Threads are relatively cheap, it's just that the hardware currently has several performance bugs with them on x86 (and more on x86-64 with the MSR fiddling that hits the hot path). Architectures like powerpc are not going to benefit anywhere near as much from this exercise, as the state involved is processed much more sanely. IA64 as usual is simply doomed by way of having too many registers to switch. If people really want to go down this path, please make an effort to compare threads on a properly tuned platform. This means that things like the kernel and userland stacks must take into account the cache alignment (we do some of this already, but there are some very definate L1 cache colour collisions between commonly hit data structures amongst threads). The existing AIO ringbuffer suffers from this, as important data is always on the beginning of the first page. Yes, these might be microoptimizations, but accumulated changes of this nature have been known to buy 100%+ improvements in performance. -ben -- Time is of no importance, Mr. President, only life is important. Don't Email: [EMAIL PROTECTED]. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [NFS] [PATCH 001 of 9] knfsd: nfsd4: fix non-terminated string
On Wed, 2007-02-14 at 09:55 -0800, Chuck Lever wrote: Ming Zhang wrote: 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? Some patches are in the works to build in IPv6 support. See the patch series at http://oss.oracle.com/~cel/linux-2.6/2.6.19/patches/ thanks for the info. -- 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/
loosen dependancy on rtc cmos
This option is useful for all of the X86 subarchs afaik (and especially X86_GENERICARCH). Signed-off-by: Dave Jones [EMAIL PROTECTED] --- linux-2.6.20.noarch/drivers/rtc/Kconfig~2007-02-14 13:07:07.0 -0500 +++ linux-2.6.20.noarch/drivers/rtc/Kconfig 2007-02-14 13:07:13.0 -0500 @@ -101,7 +101,7 @@ comment RTC drivers config RTC_DRV_CMOS tristate PC-style 'CMOS' real time clock - depends on RTC_CLASS (X86_PC || ALPHA || ARM26 || ARM \ + depends on RTC_CLASS (X86 || ALPHA || ARM26 || ARM \ || M32R || ATARI || POWERPC) help Say yes here to get direct support for the real time clock -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 8250: make probing for TXEN bug a config option
On Wed, 14 Feb 2007 05:41:53 -0800 Vitaly Wool [EMAIL PROTECTED] wrote: 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? plat_serial8250_port.flags? Dunno, I'm unfamiliar with it. That seems to be how the share_irqs option is handled. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64 ptrace32 needs PTRACE_OLDSETOPTIONS
On Wednesday 14 February 2007 18:55, Jeff Dike wrote: x86_64 ptrace32 needs to support PTRACE_OLDSETOPTIONS. This patch just converts the PTRACE_OLDSETOPTIONS request to PTRACE_SETOPTIONS and falls through to the sys_ptrace call. Hmm, why do we have this at all if it's the same as plain SETOPTIONS ? -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH]: Fix __devinit __devexit declarations in de2104x driver
__devinit __devexit cleanups for de2104x driver.
Fixes MODPOST warnings similar to:
WARNING: drivers/net/tulip/de2104x.o - Section mismatch: reference to
.init.text:de_init_one from .data.rel.local after 'de_driver' (at offset 0x20)
WARNING: drivers/net/tulip/de2104x.o - Section mismatch: reference to
.exit.text:de_remove_one from .data.rel.local after 'de_driver' (at offset 0x28)
Signed-off-by: Prarit Bhargava [EMAIL PROTECTED]
--- linux-2.6.18.ia64.orig/drivers/net/tulip/de2104x.c 2006-09-19
23:42:06.0 -0400
+++ linux-2.6.18.ia64/drivers/net/tulip/de2104x.c 2007-02-14
13:43:55.0 -0500
@@ -1685,7 +1685,7 @@ static struct ethtool_ops de_ethtool_ops
.get_regs = de_get_regs,
};
-static void __init de21040_get_mac_address (struct de_private *de)
+static void __devinit de21040_get_mac_address (struct de_private *de)
{
unsigned i;
@@ -1703,7 +1703,7 @@ static void __init de21040_get_mac_addre
}
}
-static void __init de21040_get_media_info(struct de_private *de)
+static void __devinit de21040_get_media_info(struct de_private *de)
{
unsigned int i;
@@ -1730,7 +1730,7 @@ static void __init de21040_get_media_inf
}
/* Note: this routine returns extra data bits for size detection. */
-static unsigned __init tulip_read_eeprom(void __iomem *regs, int location, int
addr_len)
+static unsigned __devinit tulip_read_eeprom(void __iomem *regs, int location,
int addr_len)
{
int i;
unsigned retval = 0;
@@ -1765,7 +1765,7 @@ static unsigned __init tulip_read_eeprom
return retval;
}
-static void __init de21041_get_srom_info (struct de_private *de)
+static void __devinit de21041_get_srom_info (struct de_private *de)
{
unsigned i, sa_offset = 0, ofs;
u8 ee_data[DE_EEPROM_SIZE + 6] = {};
@@ -1926,7 +1926,7 @@ bad_srom:
goto fill_defaults;
}
-static int __init de_init_one (struct pci_dev *pdev,
+static int __devinit de_init_one (struct pci_dev *pdev,
const struct pci_device_id *ent)
{
struct net_device *dev;
@@ -2082,7 +2082,7 @@ err_out_free:
return rc;
}
-static void __exit de_remove_one (struct pci_dev *pdev)
+static void __devexit de_remove_one (struct pci_dev *pdev)
{
struct net_device *dev = pci_get_drvdata(pdev);
struct de_private *de = dev-priv;
@@ -2160,7 +2160,7 @@ static struct pci_driver de_driver = {
.name = DRV_NAME,
.id_table = de_pci_tbl,
.probe = de_init_one,
- .remove = __exit_p(de_remove_one),
+ .remove = __devexit_p(de_remove_one),
#ifdef CONFIG_PM
.suspend= de_suspend,
.resume = de_resume,
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] mm: NUMA replicated pagecache
On Tue, 13 Feb 2007, Nick Piggin wrote: Just tinkering around with this and got something working, so I'll see if anyone else wants to try it. Not proposing for inclusion, but I'd be interested in comments or results. We would be very interested in such a feature. We have another hack that shows up to 40% performance improvements. At the moment the code is a bit ugly, but it won't take much to make it a completely standalone ~400 line module with just a handful of hooks into the core mm. So if anyone really wants it, it could be quite realistic to get into an includable form. Would be great but I am a bit skeptical regarding the locking and the additonal overhead moving back and forth between replications and non replicated page state. At some point I did take a look at Dave Hansen's page replication patch for ideas, but didn't get far because he was doing a per-inode scheme and I was doing per-page. No judgments on which approach is better, but I feel this per-page patch is quite neat. Definitely looks better. - Would be nice to transfer master on reclaim. This should be quite easy, must transfer relevant flags, and only if !PagePrivate (which reclaim takes care of). Transfer master? Meaning you need to remove the replicated pages? Removing of replicated pages should transfer reference bit? - Should go nicely with lockless pagecache, but haven't merged them yet. When is that going to happen? Soon I hope? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] mm: NUMA replicated pagecache
On Tue, 13 Feb 2007, Nick Piggin wrote: This is a scheme for page replication replicates read-only pagecache pages opportunistically, at pagecache lookup time (at points where we know the page is being looked up for read only). The problem is that you may only have a single page table. One process with multiple threads will just fault in one thread in order to install the mapping to the page. The others threads may be running on different nodes and different processors but will not generate any faults. Pages will not be replicated as needed. The scheme only seems to be working for special cases of multiple processes mapping the same file. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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
On Wed, 14 Feb 2007, Nick Piggin wrote: Can't you have migration without swap? Yes you can. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linus' laptop and Num lock status
According to the lore(1) the reason that the kernel unconditionally turns off the num lock was so that Linus' laptop came up ready to type. The issue is that if you force num lock on, then laptop users are messed up since for most laptops your keyboard changes as follows: 7890 = 789* uiop = 456- jkl; = 123+ m./ = 0./ So the only safe choice is force off or Follow BIOS (preferable). Are there any technical or political reasons why kernel can't change from force off to Follow BIOS? Some distributions implement Follow BIOS in their bootup scripts but the most just follow the kernel. IMHO, it would be very nice if the Follow BIOS was done by the kernel so this would Just Work(tm) everywhere in all situations (such as rescue environments where the normal bootup scripts aren't processed). Thanks, Dax Kelson (1) http://www.redhat.com/archives/fedora-test-list/2003-September/msg00713.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: Linus' laptop and Num lock status
On Wed, 2007-02-14 at 11:12 -0800, Linus Torvalds wrote:
On Wed, 14 Feb 2007, Dax Kelson wrote:
Are there any technical or political reasons why kernel can't change
from force off to Follow BIOS?
How would you query it? I'm not even 100% sure that you can on all
keyboards. We never query the leds, we always set them. I think. I don't
know of any AT kbd command to read the led state out of the keyboard.
Linus
The GPL'd hwinfo command shipped with SUSE queries the BIOS setting by
reading a single byte from /dev/mem.
In src/hd/bios.c around line 262 it has:
if(hd_data-bios_ram.data) {
bios_ram = hd_data-bios_ram.data;
[snip]
bt-led.scroll_lock = bios_ram[0x97] 1;
bt-led.num_lock = (bios_ram[0x97] 1) 1;
bt-led.caps_lock = (bios_ram[0x97] 2) 1;
bt-led.ok = 1;
Cut-n-paste commands to get to the source:
cd /tmp
wget
http://ftp.opensuse.org/pub/opensuse/distribution/SL-OSS-factory/inst-source/suse/src/hwinfo-13.21-3.src.rpm
rpm2cpio hwinfo-13.21-3.src.rpm | cpio -id
tar jxf hwinfo-13.21.tar.bz2
cd hwinfo-13.21/src/hd
Dax Kelson
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
