Re: [patch] CFS scheduler, -v8
On Thu, May 03, 2007 at 10:50:15AM +0200, Ingo Molnar wrote: - EEVDF concentrates on real-time (SCHED_RR-alike) workloads where they know the length of work units This is what I was thinking when I wrote earlier that EEVDF expects each task will specify length of each new request (http://lkml.org/lkml/2007/5/2/339). The other observation that I have of EEVDF is that it tries to be fair in the virtual time scale (each client will get 'wi' real units in 1 virtual unit), whereas sometimes fairness in real-time scale also matters? For ex: a multi-media app would call scheduler fair to it, it it recvs atleast 1 ms cpu time every 10 *real* milleseconds (frame-time). A rogue user (or workload) that does a fork bomb may skew this fairness for that multi-media app in real-time scale under EEVDF? -- 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/
Re: netfront for review
Gerd Hoffmann wrote: Gerd, in change 11196:b85da7cd9ea5 front: Fix rx buffer leak when tearing down an interface. you added a call to add_id_to_freelist(np-rx_skbs, id);. However, rx_skbs doesn't have an extra entry for the list head, and there's never any corresponding get_id_from_freelist(np-rx_skbs). What should it be? The function has an effect in page flipping mode only. It walks the whole list of rx skbufs (id is the loop variable ...), checks whenever they are handed out to the frontend driver to fill in packet data and not returned yet, and if so reclaim them ... Yes, but why use add_id_to_freelist? rx_skbs are not being used on a freelist anywhere else. It just means the rx_skb array gets filled with small integers, but the rest of the code assumes they're either NULL or an skb pointer. J - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: netfront for review
On 3/5/07 15:27, Jeremy Fitzhardinge [EMAIL PROTECTED] wrote: The function has an effect in page flipping mode only. It walks the whole list of rx skbufs (id is the loop variable ...), checks whenever they are handed out to the frontend driver to fill in packet data and not returned yet, and if so reclaim them ... Yes, but why use add_id_to_freelist? rx_skbs are not being used on a freelist anywhere else. It just means the rx_skb array gets filled with small integers, but the rest of the code assumes they're either NULL or an skb pointer. The need for it went away when Herbert Xu made the mapping between receive-ring slots and receive-request/response identifiers static. I think there was a race between Gerd writing his patch, Herbert removing the need for add_id_to_freelist, and Gerd's patch being checked in. -- Keir - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: console font limits
On May 3 2007 10:14, Albert Cahalan wrote: On 5/3/07, Jan Engelhardt [EMAIL PROTECTED] wrote: On May 3 2007 02:17, Albert Cahalan wrote: Those sizes are unreadable on the 200 dpi OLPC XO screen, Hm that should have read, for you: I don't object implementing support for larger sizes. (But I wonder how that should work without FB/CVIDIX/SVGA/VESA extensions.) Note that I was assuming that no FB is used: I'm assuming that the FB is used. Neither of my two computers can do VGA text mode. Some non-x86 boxes like sparc? Even for computers which can do VGA text mode, if you want large fonts (either by number of characters or by character width) you need to use FB. That's just a requirement; anything else would be insane. For everything beyond Latin, fbiterm should work a lot better. Then, as with X, you have problems with kernel messages. Reliably sending printk through a userspace console is not even possible. (consider a panic, OOM, or runaway RT task) Actually, the kernel could just jump in. That is, when you start in fb mode, you get the regular 8x16 vga font - on your choice of resolution, and can also set it with setfont. So far so nice. Now, when you start fbiterm -- for example to read CJK --, fbiterm presents you with what looks like a 12x24 font. Also good. It _looks_ to me like fbiterm does the drawing itself; ok too. Now when the kernel is oopsing, it could just spew out the oops trace in the regular font (vga8x16 or in case you use CONFIG_FONTS, then that), possibly obstructing some output generated by fbiterm, but in case of oops, I think this is ok. 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: [linux-cifs-client] Re: SMB2 file system - should it be a distinct module
On Thu, 2007-05-03 at 15:17 +0100, Christoph Hellwig wrote: On Thu, May 03, 2007 at 09:21:29AM -0400, simo wrote: Separate modules would mean the user have to know which protocol to choose each time. And this make little sense. Of course it makes a lot of sense. We don't have anyfs.ko either because some ubuntu users are too braindead to know what's on their disk. You really want to auto-negotiate which protocol to use, because you could have at the same time a connection to a Vista/Longhorn (SMB2) machine and one to a Windows 2000 server (plain SMB) in the same domain using the same credentials. So what? I guess DFS referrals can work cross protocol, so if you are redirected from a longhorn server to a windoes 2000 or a samba server you want to be able to follow the DFS referral and not return an error. To do that you need to have either 1 module that support both protocols or a way from one module to call the other. Just separating the 2 without any glue will not work (or you will have to add some userspace upcall hack to make it work). Simo. -- Simo Sorce Samba Team GPL Compliance Officer email: [EMAIL PROTECTED] http://samba.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: netfront for review
Jeremy Fitzhardinge wrote: Gerd Hoffmann wrote: Gerd, in change 11196:b85da7cd9ea5 front: Fix rx buffer leak when tearing down an interface. you added a call to add_id_to_freelist(np-rx_skbs, id);. However, rx_skbs doesn't have an extra entry for the list head, and there's never any corresponding get_id_from_freelist(np-rx_skbs). What should it be? The function has an effect in page flipping mode only. It walks the whole list of rx skbufs (id is the loop variable ...), checks whenever they are handed out to the frontend driver to fill in packet data and not returned yet, and if so reclaim them ... Yes, but why use add_id_to_freelist? rx_skbs are not being used on a freelist anywhere else. It just means the rx_skb array gets filled with small integers, but the rest of the code assumes they're either NULL or an skb pointer. Hmm, good point. Have to look at the code again, it has been some time I've written that, and it took me some time to figure how all the grant table stuff works ... Maybe the add_id_to_freelist() call can simply be dropped. The whole interface is released shortly thereafter, probably thats why filling the freelist with yunk never caused any problems ... cheers, Gerd - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] crypto: convert crypto.h to UTF-8
Besides, based on the actual binary representation of UTF-8, it's extremely unlikely for any ISO-8859-1 string to be detected as UTF-8. VIm already does this: UTF-8 it handles natively, but open up one of these unpatched files in VIm and you'll see [converted] at the bottom of your screen. Should happen if you open the attached .patch.bin file in VIm. Yes, I agree that heuristics can be used to determine the coding system used with a high degree of probability. I'm just suggesting we make the coding system explicit, in order to spare other applications that do visual presentation of Linux source code having to perform their own heuristics. But hey, if I'm the only one wanting to see this particular bike shed painted blue... In any other case, I would agree completely, but like I said, the entire tree will be one encoding anyway, which will be UTF-8. Many tools would already have these heuristics, and even if they don't, the code itself will be perfectly legible no matter which encoding is used to view it, and only some things like circuit diagrams and peoples' names may be slightly mangled. Any byte which is 0x7F or less is identical in both encodings, so all normal ASCII is unchanged. It's an issue only in transition. No new non-UTF-8 patches should be accepted, of course. And I won't be doing any changes that break anything other than a live person reading it and wondering why it looks weird if they don't have the right tools. A line in Documentation/CodingStyle explicitly requiring UTF-8 sounds like a good idea. I shall submit one later if I remember. Many mail clients do this conversion automatically, which causes me headaches and requires me to attach the patches separately. Quite annoying really. I'm exploring the possibility of hacking together a simple SMTP client if that'll help me with these fool binary patches. Or maybe setting up a little mini git repository with UTF-8 changes is a good idea? Hmm, I'll research that, and try it. Then I could just cc it to trivial and the list and they can just pull it in one go. One more week until summer vacation! I shall have time to do this then. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 -v2 1/1] Misc: add sensable phantom driver
Andrew Morton napsal(a): +static int phantom_ioctl(struct inode *inode, struct file *file, u_int cmd, +u_long arg) Could we please use standard-looking types in this driver? u32 and u64 and things? However in this case, as it's an ioctl handler it should be int and unsigned long. actually, according to file_operations struct: int (*ioctl) (struct inode *, struct file *, unsigned int, unsigned long); *unsigned* int and unsigned long are correct types... regards, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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-cifs-client] Re: SMB2 file system - should it be a distinct module
On Thu, May 03, 2007 at 10:36:53AM -0400, simo wrote: I guess DFS referrals can work cross protocol, so if you are redirected from a longhorn server to a windoes 2000 or a samba server you want to be able to follow the DFS referral and not return an error. To do that you need to have either 1 module that support both protocols or a way from one module to call the other. Just separating the 2 without any glue will not work (or you will have to add some userspace upcall hack to make it work). You can easily redirect from one filesystem to another through -follow_link, and you can mount new filesystems instances from there. Can we please stop the bullshitting now? And can you please get a realname before playing smart ass on filesystem developers lists? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
Uwe Bugla wrote: On the technical layer I noticed that I heard some Pinnacle relais click during testing, but there were some i2c_bus symbols missing during compilation. So I guess those missing symbols are responsible for getting neither picture nor sound. Can you send your compile warnings ? I couldn't find the same in my mailbox any report on the same. Maybe my mail filter did something. A. If you are really interested I can send you my basic puzzle parts in short, opening a new thread on this issue. Just give me a short response if you are interested. B. If you want to continue the cx878 project please drop me a short note where I can download it to test and enlarge it with my own ideas as good as I can. Must not be immediately (no sweat please), but I am looking forward to receive a response from you. What i would like to do is like this: Have the current state frozen as it is, such that there is a fallback case (The dst is quite fragile and change at some place would break another. ie, what looks good for one DST variant is bad for the other). Work on a new tree (CX878) and migrate stuff to it. Remove the old one, once things are done. I wouldn't want to mess up the current working situation and hence. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] CFS scheduler, -v8
On Thu, May 03, 2007 at 03:29:32PM +0200, Damien Wyart wrote: What are your thoughts/plans concerning merging CFS into mainline ? Is it a bit premature to get it into 2.6.22 ? I remember Linus was ok to change the default scheduler rapidly (the discussion was about sd at that time) to get more testing than in -mm. And what about group scheduling extensions? Do you have plans to work on it? I was begining to work on a prototype to do group scheduling based on CFS, basically on the lines of what you and Linus had outlined earlier: http://lkml.org/lkml/2007/4/18/271 http://lkml.org/lkml/2007/4/18/244 -- 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/
Re: [linux-usb-devel] [BUG] usb/core/hub.c loops forever on resume from ram due to bluetooth
On Thu, 3 May 2007, Mark Lord wrote: If the code never gets stuck in a loop, then there's no need to check whether the loop is unbounded! :-) Yes, except here we know it does actually get stuck in a loop, and having unbounded loops in device-driver code is a known baddy. One cannot predict perfectly exactly how devices will fail, but one can program defensively against them with simple precautions like limiting list traversals and the like. :) Sure, Marcel may eventually look at the bluetooth code and fix it to not get confused, but some other USB device may then show up in the future with similar issues. I'd agree, except that the problem isn't in the bluetooth code. And it probably doesn't have anything in particular to do with the fact that this is a bluetooth device; the TT code gets used with USB hubs only. More accurately, the code helps manage the TT embedded in a high-speed USB hub, allowing the hub to communicate with a full- or low-speed USB device plugged into it. The messages are still there so we'll know about any future failure, but it won't just silently crash the machine on resume this way. Remember, resume is a very tough operation to debug at the best of times, so adding some harmless robustness to the more troublesome drives is a very Good Thing(tm) here. Alan Stern - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22 -mm merge plans
* Christoph Hellwig ([EMAIL PROTECTED]) wrote: On Wed, May 02, 2007 at 07:11:04PM -0400, Mathieu Desnoyers wrote: My statement was probably not clear enough. The actual marker code is useful as-is without any further kernel patching required : SystemTAP is an example where they use external modules to load probes that can connect either to markers or through kprobes. LTTng, in its current state, has a mostly modular core that also uses the markers. That just mean you have to load an enormous emount of exernal crap that replaces the missing kernel functionality. It's exactly the situation we want to avoid. It makes sense to use -mm to hold the hole usable infrastructure before submitting it to mainline. I will submit my core LTTng patches to Andrew in the following weeks. There is no hurry, in the LTTng perspective, to merge the markers sooner, although they could be useful to other (external) projects meanwhile. Mathieu -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22 -mm merge plans
Hi Andi, This plan makes sense. I will split the patched in enabled/disable flags part into a separate piece (good idea!) and then submit the LTTng core to Andrew. Christoph's has a good point about wanting a usable infrastructure to go ini. Regarding your plan, I must argue that blktrace is not a general purpose tracing infrastructure, but one dedicated to block io tracing. Therefore, it makes sense to bring in the generic infrastructure first and then convert blktrace to it. Mathieu * Andi Kleen ([EMAIL PROTECTED]) wrote: If we are looking at current potential users that are already in mainline, we could change blktrace to make it use the markers. Ok, but do it step by step: - split out useful pieces like the patched in enable/disable flags and submit them separate with an example user or two [I got a couple of candidates e.g. with some of the sysctls in VM or networking] - post and merge that. - don't implement anything initially that is not needed by blktrace - post a minimal marker patch together with the blktrace conversion for review again on linux-kernel - await review comments. This review would not cover the basic need of markers, just the specific implementation. - then potentially merge incorporate review comments - then merge - later add features with individual review/discussion as new users in the kernel are added. -Andi -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] revoke: rename to can_revoke_{file|vma}
From: Pekka Enberg [EMAIL PROTECTED]
The inode_matches and need_revoke functions have confusing names so
rename them to can_revoke_file and can_revoke_vma respectively.
Signed-off-by: Pekka Enberg [EMAIL PROTECTED]
---
fs/revoke.c | 33 -
1 file changed, 16 insertions(+), 17 deletions(-)
Index: 26-mm/fs/revoke.c
===
--- 26-mm.orig/fs/revoke.c 2007-05-03 16:46:00.0 +0300
+++ 26-mm/fs/revoke.c 2007-05-03 17:09:52.0 +0300
@@ -75,10 +75,13 @@ filp-f_pos = 0;
return NULL;
}
-static inline int inode_matches(struct file *file, struct inode *inode,
- struct file *to_exclude)
+static inline bool can_revoke_file(struct file *file, struct inode *inode,
+ struct file *to_exclude)
{
- return file file != to_exclude file-f_dentry-d_inode == inode;
+ if (!file || file == to_exclude)
+ return false;
+
+ return file-f_dentry-d_inode == inode;
}
static inline bool revoke_table_is_full(struct revoke_table *table)
@@ -116,7 +119,7 @@ for (fd = 0; fd fdt-max_fds; fd++) {
struct inode *new_inode;
filp = fcheck_files(files, fd);
- if (!inode_matches(filp, inode, to_exclude))
+ if (!can_revoke_file(filp, inode, to_exclude))
continue;
if (!filp-f_op-revoke) {
@@ -159,22 +162,18 @@ for (fd = 0; fd fdt-max_fds; fd++) {
return err;
}
-static inline bool need_revoke(struct vm_area_struct *vma,
- struct inode *inode,
- struct file *to_exclude)
+static inline bool can_revoke_vma(struct vm_area_struct *vma,
+ struct inode *inode, struct file *to_exclude)
{
struct file *file = vma-vm_file;
if (vma-vm_flags VM_REVOKED)
return false;
- if (!file)
- return false;
-
- if (file-f_path.dentry-d_inode != inode)
+ if (!file || file == to_exclude)
return false;
- return file != to_exclude;
+ return file-f_path.dentry-d_inode == inode;
}
static int __revoke_break_cow(struct task_struct *tsk, struct inode *inode,
@@ -191,7 +190,7 @@ int err = 0;
if (vma-vm_flags VM_SHARED)
continue;
- if (!need_revoke(vma, inode, to_exclude))
+ if (!can_revoke_vma(vma, inode, to_exclude))
continue;
ret = get_user_pages(tsk, tsk-mm, vma-vm_start,
@@ -287,7 +286,7 @@ int err = 0;
if (!(vma-vm_flags VM_SHARED))
continue;
- if (!need_revoke(vma, mapping-host, to_exclude))
+ if (!can_revoke_vma(vma, mapping-host, to_exclude))
continue;
err = revoke_vma(vma, details);
@@ -320,7 +319,7 @@ vma_prio_tree_foreach(vma, iter, mapp
if (!(vma-vm_flags VM_SHARED))
continue;
- if (likely(!need_revoke(vma, mapping-host, to_exclude)))
+ if (likely(!can_revoke_vma(vma, mapping-host, to_exclude)))
continue;
err = revoke_mm(vma-vm_mm, mapping, to_exclude);
@@ -348,7 +347,7 @@ int try_again = 0;
list_for_each_entry(vma, mapping-i_mmap_nonlinear,
shared.vm_set.list) {
int err;
- if (likely(!need_revoke(vma, mapping-host, to_exclude)))
+ if (likely(!can_revoke_vma(vma, mapping-host, to_exclude)))
continue;
err = revoke_mm(vma-vm_mm, mapping, to_exclude);
@@ -470,7 +469,7 @@ for (fd = 0; fd fdt-max_fds; fd++)
struct file *file;
file = fcheck_files(files, fd);
- if (inode_matches(file, inode, to_exclude)) {
+ if (can_revoke_file(file, inode, to_exclude)) {
nr_fds += fdt-max_fds;
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/
[PATCH 2/2] revoke: change revoke_table to fileset and revoke_details
From: Pekka Enberg [EMAIL PROTECTED]
The revoke_table struct is overloaded because it serves two purposes:
it manages the pre-allocated set of files and tracks the revoke
operation so that we know where to start restore if the operation
fails. This splits file set management to separate struct fileset and
renames struct revoke_table to revoke_details.
Signed-off-by: Pekka Enberg [EMAIL PROTECTED]
---
fs/revoke.c | 171 +++-
1 file changed, 101 insertions(+), 70 deletions(-)
Index: 26-mm/fs/revoke.c
===
--- 26-mm.orig/fs/revoke.c 2007-05-03 17:10:56.0 +0300
+++ 26-mm/fs/revoke.c 2007-05-03 17:14:49.0 +0300
@@ -18,19 +18,71 @@ * Copyright (C) 2006-2007 Pekka Enberg
#include linux/revoked_fs_i.h
#include linux/syscalls.h
-/*
- * This is used for pre-allocating an array of file pointers so that we don't
- * have to do memory allocation under tasklist_lock.
+/**
+ * fileset - an array of file pointers.
+ * @files:the array of file pointers
+ * @nr: number of elements in the array
+ * @end: index to next unused file pointer
+ */
+struct fileset {
+ struct file **files;
+ unsigned long nr;
+ unsigned long end;
+};
+
+/**
+ * revoke_details - details of the revoke operation
+ * @inode:invalidate open file descriptors of this inode
+ * @fset: set of files that point to a revoked inode
+ * @restore_start:index to the first file pointer that is currently in
+ *use by a file descriptor but the real file has not
+ *been revoked
*/
-struct revoke_table {
- struct file **files;
- unsigned long size;
- unsigned long end;
- unsigned long restore_start;
+struct revoke_details {
+ struct fileset *fset;
+ unsigned long restore_start;
};
static struct kmem_cache *revokefs_inode_cache;
+static inline bool fset_is_full(struct fileset *set)
+{
+ return set-nr == set-end;
+}
+
+static inline struct file *fset_get_filp(struct fileset *set)
+{
+ return set-files[set-end++];
+}
+
+static struct fileset *alloc_fset(unsigned long size)
+{
+ struct fileset *fset;
+
+ fset = kzalloc(sizeof *fset, GFP_KERNEL);
+ if (!fset)
+ return NULL;
+
+ fset-files = kcalloc(size, sizeof(struct file *), GFP_KERNEL);
+ if (!fset-files) {
+ kfree(fset);
+ return NULL;
+ }
+ fset-nr = size;
+ return fset;
+}
+
+static void free_fset(struct fileset *fset)
+{
+ int i;
+
+ for (i = fset-end; i fset-nr; i++)
+ fput(fset-files[i]);
+
+ kfree(fset-files);
+ kfree(fset);
+}
+
/*
* Revoked file descriptors point to inodes in the revokefs filesystem.
*/
@@ -84,22 +136,12 @@ static inline bool can_revoke_file(struc
return file-f_dentry-d_inode == inode;
}
-static inline bool revoke_table_is_full(struct revoke_table *table)
-{
- return table-end == table-size;
-}
-
-static inline struct file *revoke_table_get(struct revoke_table *table)
-{
- return table-files[table-end++];
-}
-
/*
* LOCKING: task_lock(owner)
*/
static int revoke_fds(struct task_struct *owner,
struct inode *inode,
- struct file *to_exclude, struct revoke_table *table)
+ struct file *to_exclude, struct fileset *fset)
{
struct files_struct *files;
struct fdtable *fdt;
@@ -127,12 +169,12 @@ for (fd = 0; fd fdt-max_fds; fd++) {
goto failed;
}
- if (revoke_table_is_full(table)) {
+ if (fset_is_full(fset)) {
err = -ENOMEM;
goto failed;
}
- new_filp = revoke_table_get(table);
+ new_filp = fset_get_filp(fset);
/*
* Replace original struct file pointer with a pointer to
@@ -208,17 +250,17 @@ if (ret 0) {
return err;
}
-static int revoke_break_cow(struct revoke_table *table, struct inode *inode,
+static int revoke_break_cow(struct fileset *fset, struct inode *inode,
struct file *to_exclude)
{
unsigned long i;
int err = 0;
- for (i = 0; i table-end; i++) {
+ for (i = 0; i fset-end; i++) {
struct revokefs_inode_info *info;
struct file *this;
- this = table-files[i];
+ this = fset-files[i];
info = revokefs_i(this-f_dentry-d_inode);
err = __revoke_break_cow(info-owner, inode, to_exclude);
@@ -399,32 +441,32 @@ static void restore_file(struct revokefs
info-owner = NULL; /* To avoid double-restore. */
}
-static void restore_files(struct revoke_table *table)
+static
Re: [linux-cifs-client] Re: SMB2 file system - should it be a distinct module
On Thu, 2007-05-03 at 15:43 +0100, Christoph Hellwig wrote: On Thu, May 03, 2007 at 10:36:53AM -0400, simo wrote: I guess DFS referrals can work cross protocol, so if you are redirected from a longhorn server to a windoes 2000 or a samba server you want to be able to follow the DFS referral and not return an error. To do that you need to have either 1 module that support both protocols or a way from one module to call the other. Just separating the 2 without any glue will not work (or you will have to add some userspace upcall hack to make it work). You can easily redirect from one filesystem to another through -follow_link, and you can mount new filesystems instances from there. Can we please stop the bullshitting now? And can you please get a realname before playing smart ass on filesystem developers lists? I guess you just had a bad day and are in a bad mood, I am have no interest in arguing with you if this is the tone of the discussion. Simo. -- Simo Sorce Samba Team GPL Compliance Officer email: [EMAIL PROTECTED] http://samba.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-cifs-client] Re: SMB2 file system - should it be a distinct module
On Thu, 2007-05-03 at 09:46 -0500, Gerald Carter wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Simo, I guess DFS referrals can work cross protocol, so if you are redirected from a longhorn server to a windoes 2000 or a samba server you want to be able to follow the DFS referral and not return an error. To do that you need to have either 1 module that support both protocols or a way from one module to call the other. Just separating the 2 without any glue will not work (or you will have to add some userspace upcall hack to make it work). Long term I agree that CIFS and SMB2 should be in the same .ko But NTLM 0.12 still works for Vista and DFS referrals. Breaking out SMB2 initially means that it will not clutter the working cifs.ko code. Remember that an SMB2 client fs is mostly research at this point, and not engineering. Well, development can happen in any way Steve or any other like to do it, but it seemed to me that the proposal was to split them long term. I think this would be bad wrt supporting DFS referrals. That said, it I'll shut up as kindly requested from someone that seem to know better than Samba/CIFS developers. Simo. -- Simo Sorce Samba Team GPL Compliance Officer email: [EMAIL PROTECTED] http://samba.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] synclink_gt use dynamic tty device registration
On Thu, 2007-05-03 at 00:05 -0700, Andrew Morton wrote:
On Wed, 02 May 2007 11:17:33 -0500 Paul Fulghum [EMAIL PROTECTED] wrote:
Change synclink_gt driver to use dynamic tty device registration.
...
+ for (i=0; i port_count; ++i)
+ tty_register_device(serial_driver, port_array[i]-line,
(port_array[i]-pdev-dev));
...
+ for (info=slgt_device_list ; info != NULL ;
info=info-next_device)
+ tty_unregister_device(serial_driver, info-line);
...
+ if ((rc = pci_register_driver(pci_driver)) 0) {
hm, not a big fan of kernel coding style, I see.
It varies. If this idiom bothers you, I can split it into 2 lines.
What's going to happen here if tty_register_device() fails?
Then the device will not be accessible as a tty device.
It may still be accessible as a network device.
On driver unload, tty_unregister_device() does nothing because
the device was never created.
In this case, tracking the return value does not change anything.
I could add a printk on error to better inform the user that the
kernel's plumbing went south.
--
Paul Fulghum
Microgate Systems, Ltd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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] CFS scheduler, -v7
Hi, Ingo
This is the test case that I think worth discuss and it leads me to
find 2 things.
[...] but there are still some nice issues.
Try running 3 chew.c's, then renicing one to -10, starves others for
some seconds while switching prio-level. Now renice it back to 10, it
starves for up to 45sec.
ok - to make sure i understood you correctly: does this starvation only
occur right when you renice it (when switching prio levels), and it gets
rectified quickly once they get over a few reschedules?
The main problem of what Al Boldi saw might come from this piece of code
in sched_fair.c, which scales of fair_key difference needed to preempt
the current task:
+rescale_load(struct task_struct *p, u64 value)
+{
+int load_shift = p-load_shift;
+
+if (load_shift == SCHED_LOAD_SHIFT)
+return value;
+
+return (value load_shift) SCHED_LOAD_SHIFT;
+}
+
+static u64
+niced_granularity(struct rq *rq, struct task_struct *curr,
+ unsigned long granularity)
+{
+return rescale_load(curr, granularity);
+}
Here is the checking for pre-emption:
+static inline void
+__check_preempt_curr_fair(struct rq *rq, struct task_struct *p,
+ struct task_struct *curr, unsigned long granularity)
+{
+s64 __delta = curr-fair_key - p-fair_key;
+
+/*
+ * Take scheduling granularity into account - do not
+ * preempt the current task unless the best task has
+ * a larger than sched_granularity fairness advantage:
+ */
+if (__delta niced_granularity(rq, curr, granularity))
+resched_task(curr);
+}
This code actually now says, the difference of fair_key needed to
preempt the current task is amplified by a facto of its weigh (in Al
Boldi's example 32). However, the weighted task already advance its
p-fair_key by its weight, (also 32 here). The combination of them
becomes quadratic!
Let's starting from three nice 0 tasks p1, p2, p3, at time t=0, with
niced_granularity set to be 5ms:
Originally each task executes 5 ms in turn:
5ms for p1, 5ms for p2, 5ms p3, 5ms for p1, 5ms for
p2, 5ms for p3 ...
If somehow p3 is re-niced to -10 _right before_ the 16th ms, we run
into the worst case after p3 gets the cpu:
p1-fair_key = p2 -fair_key = 10, p3-fair_key = 5.
Now, in order for p3 to be preempted, it has to make its fair_key 5
* 32 larger than p1 and p2's fair_key. Furthermore, p3 now is higher
weight, push its fair_key to increase by 1 now needs 32ms,
thus p3 will stay one cpu for 5 * 32 *32ms, which is about 5 second!
Besides this quadratic effect, another minor issue amplified this a
little bit further: p-wait_runtime accumulated before. During renice it
is not adjusted to match the new nice value. The p-wait_runtime earned
using previous weight has to be paid off using the current weight. If
renice to larger weight you pay more than you need, otherwise you paid
less, which introduces unfairness.
Ingo, now, partially solved this problem by clearing
p-wait_runtime when a task is reniced, but the quadratic effect of
scaling is still there.
Thanks
Ting
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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] CFS scheduler, -v8
Ingo Molnar wrote: * Ting Yang [EMAIL PROTECTED] wrote: Authors of this paper proposed a scheduler: Earlist Eligible Virtual Deadline First (EEVDF). EEVDF uses exactly the same method as CFS to track the execution of each running task. The only difference between EEVDF and CFS is that EEVDF tries to _deadline_ fair while CFS is _start-time_ fair. [...] Well, this is a difference but note that it's far from being the 'only difference' between CFS and EEVDF: I re-ordered comments a little bit to make my discussion easier: - in CFS you have to earn your right to be on the CPU, while EEVDF gives out timeslices (quanta) - thus in CFS there's no concept of deadline either (the 'D' from EEVDF). These two are needed to implement the deadline fair policy, therefore are cover in the difference I mentioned. Due to the way that authors using different terms, the paper may leads to certain confusion, here 3 important concepts needed: - the scheduling quanta *q* in the paper: it refers to the minimum unit that a scheduler can schedules tasks. For system ticks 1000 per second, q is 1ms. For system ticks 100 per second (old linux), q is 10ms. - the length of a request submitted by a task: it refers to the amount of work needed to process a request. EEVDF _does_ not need this information for scheduling at all. - the timesliced used to process requests, which denoted as *r* in the paper: it refers to the unit that scheduler uses to process a request. If the length of a request is larger than timeslice r, the request is effectively divided into pieces of length r. The scheduler can use a suitable timeslice at will to handle a process. Using the timeslice, it can estimate the deadline based on the weight of a task, which tells how urgent the task is. and therefore remove the potential O(n). (but it comes with a cost: more context switches) - EEVDF concentrates on real-time (SCHED_RR-alike) workloads where they know the length of work units That is _not_ really the case, although authors of this paper used a quite aggressive title and reclaimed so. Look carefully at the Theorem 3 and its Corollary on pg 16, it says If not request of client k is larger than a time quanta, then at any time t the lag is bounded by -q lag_k(t) q It gives three facts: 1. For the system to be hard real-time, the length of request (note, not the quanta q, timeslice r) of any task at any time, must be less than the quanta of schedule, which in modern Linux is 1ms. This make EEVDF effectively useless for hard real-time system, where application can not miss deadline 2. For the system to be soft real-time: EEVDF needs to first fixed the bandwidth of a task, so that it does not varies when tasks join and leave. Then EEVDF can give a soft real-time guarantee with bounded delay of max(timeslice r). Authors mentioned this, but unfortunately this feature was never actually implemented. 3. EEVDF does gives a proportional time-share system that any task running on it will has not delay longer than max(timeslice t) w.r.t the ideal fluid-flow system. Authors of this paper only developed framework that can possibly used by real-time system (either hard or soft), their main attempt was to glue real-time and proportional time-share together. I think the real-time part of this paper does not actually ring the bell to me. However, isn't the fact 3 listed above really what we needed ? - while CFS does not need any knowledge about 'future work', it measures 'past behavior' and makes its decisions based on that. So CFS is purely 'history-based'. As I explained about, EEVDF does not need any future knowledge, instead it uses a unit (timeslice) to process request from tasks, by predicting the deadline of when this unit has to be finished. There is a firm theoretic base behind this guess:, which did not appear in the paper: as long as the total bandwidth needed by all active tasks does not exceeds the bandwidth of CPU, the predicted virtual deadline vt, if mapped back to real time t in system, then that t is exactly the deadline for the chosen unit in the ideal system. Since EEVDF is proportionally share, the bandwidth for each task is scaled based on the weight, the sum of them does not exceeds cpu capacity. Therefore the guess of EEVDF is always right :-) Predicting future taking weight into account, makes it choose better tasks to execute. Smaller timeslice make it stick to the ideal system closer in the cost of more context switches. - EEVDF seems to be calculating timeslices in units of milliseconds, while CFS follows a very strict 'precise' accounting scheme on the nanoseconds scale. This is just an implementation issue, right? It is possible to implement EEVDF in finer granularity. - the EEVDF paper is also silent on SMP issues.
Broken process startup times after suspend (regression)
Hi, the commits 411187fb05cd11676b0979d9fbf3291db69dbce2 (GTOD: persistent clock support) c1d370e167d66b10bca3b602d3740405469383de (i386: use GTOD persistent clock support) caused a change in the way uptime is measured and introduced a regression such that it's no longer possible to obtain a correct process start time or the system boot time. These two commits make the monotonic time not jump by hudreds of seconds after the kernel resumes from suspend, but they achieve it by moving the wall_to_monotonic offset, which is used for all boot time / uptime calculations. It's not possible to read the real boot time / process start time then. I was thinking about a solution and I am posting the least intrusive one I found. I add a total_sleep_time variable which is to be added to wall_to_monotonic when one wants the proper boot time. I do by no means say it's the best one, I expect comments. This requires a patch to procps that makes it use /proc/stat's btime instead of now - uptime. This was written by Tomas Smetana and I'm attaching it as well. (It was posted upstream as it fixes another bug in ps as well.) Or we could just make the /proc/uptime contain now - btime like it used to before those two commits. --- fs/proc/proc_misc.c |2 +- include/linux/time.h |1 + kernel/fork.c|1 + kernel/timer.c |6 ++ 4 files changed, 9 insertions(+), 1 deletions(-) diff --git a/fs/proc/proc_misc.c b/fs/proc/proc_misc.c index e2c4c0a..a29309e 100644 --- a/fs/proc/proc_misc.c +++ b/fs/proc/proc_misc.c @@ -456,7 +456,7 @@ static int show_stat(struct seq_file *p, void *v) user = nice = system = idle = iowait = irq = softirq = steal = cputime64_zero; - jif = - wall_to_monotonic.tv_sec; + jif = - (wall_to_monotonic.tv_sec + total_sleep_time); if (wall_to_monotonic.tv_nsec) --jif; diff --git a/include/linux/time.h b/include/linux/time.h index 8ea8dea..cb87616 100644 --- a/include/linux/time.h +++ b/include/linux/time.h @@ -90,6 +90,7 @@ static inline struct timespec timespec_sub(struct timespec lhs, extern struct timespec xtime; extern struct timespec wall_to_monotonic; +extern unsigned long total_sleep_time; extern seqlock_t xtime_lock __attribute__((weak)); extern unsigned long read_persistent_clock(void); diff --git a/kernel/fork.c b/kernel/fork.c index 6af959c..c051f17 100644 --- a/kernel/fork.c +++ b/kernel/fork.c @@ -1056,6 +1056,7 @@ static struct task_struct *copy_process(unsigned long clone_flags, p-lock_depth = -1; /* -1 = no lock */ do_posix_clock_monotonic_gettime(p-start_time); + p-start_time.tv_sec += total_sleep_time; p-security = NULL; p-io_context = NULL; p-io_wait = NULL; diff --git a/kernel/timer.c b/kernel/timer.c index dd6c2c1..13eb201 100644 --- a/kernel/timer.c +++ b/kernel/timer.c @@ -759,9 +759,13 @@ unsigned long next_timer_interrupt(void) * at zero at system boot time, so wall_to_monotonic will be negative, * however, we will ALWAYS keep the tv_nsec part positive so we can use * the usual normalization. + * + * One needs to add total_sleep_time to wall_to_monotonic to get the real boot + * time. */ struct timespec xtime __attribute__ ((aligned (16))); struct timespec wall_to_monotonic __attribute__ ((aligned (16))); +unsigned long total_sleep_time; EXPORT_SYMBOL(xtime); @@ -975,6 +979,7 @@ void __init timekeeping_init(void) xtime.tv_nsec = 0; set_normalized_timespec(wall_to_monotonic, -xtime.tv_sec, -xtime.tv_nsec); + total_sleep_time = 0; write_sequnlock_irqrestore(xtime_lock, flags); } @@ -1004,6 +1009,7 @@ static int timekeeping_resume(struct sys_device *dev) xtime.tv_sec += sleep_length; wall_to_monotonic.tv_sec -= sleep_length; + total_sleep_time += sleep_length; } /* re-base the last cycle value */ clock-cycle_last = clocksource_read(clock); Regards, -- Tomas Janousek, SW Engineer, Red Hat, Inc. --- procps-3.2.7/ps/output.c.jitter 2007-04-26 13:15:47.0 +0200 +++ procps-3.2.7/ps/output.c2007-04-26 13:31:24.0 +0200 @@ -77,7 +77,6 @@ static int wide_signals; /* true if we have room */ static unsigned long seconds_since_1970; -static unsigned long time_of_boot; static unsigned long page_shift; @@ -1952,7 +1951,6 @@ // available space: page_size*outbuf_pages-SPACE_AMOUNT seconds_since_1970 = time(NULL); - time_of_boot = seconds_since_1970 - seconds_since_boot; meminfo(); --- procps-3.2.7/ps/common.h.jitter 2005-01-27 04:43:22.0 +0100 +++ procps-3.2.7/ps/common.h2007-04-26 12:44:01.0 +0200 @@ -302,6 +302,7 @@ extern int screen_cols; extern int screen_rows; extern unsigned long seconds_since_boot; +extern unsigned long time_of_boot; extern selection_node *selection_list; extern
Re: [PATCH 0/6] UDF cleanup and fixes
On Fri 27-04-07 16:54:20, Eric Sandeen wrote: Jan Kara wrote: Hello, the patches attached to six following emails implement some cleanup and fixes in the UDF code. The main two fixes are: 1) UDF now works correctly for files larger than 1GB. 2) Deleting a directory updates number of links to the parent directory correctly. See headers of following patches for details. The patches sustained some torturing so I hope that I did not introduce more bugs than I've fixed ;). Andrew, could you please put the patches into -mm kernels for testing? Thanks. Honza Jan - I ran 2.6.21 + your udf patches from -mm through some udf tests which, oddly enough, can be found in the xfstests test suite in xfsprogs cvs from sgi. It looks much better than before, but I was able to trip some of your asserts. They were generated while fsx was running. The good news, though, is that fsx passed. :) I haven't looked into it much further yet, but wanted to let you know. Thanks for the news. I'll try running fsx to see if I'll be able to reproduce the problem (I think I was testing the patches with fsx but maybe it didn't run long enough). Honza BUG: at /src/linux-2.6.21-rc5/fs/udf/truncate.c:123 udf_discard_prealloc() [de969274] udf_discard_prealloc+0x2d8/0x2ed [udf] [de95eea5] udf_release_file+0x15/0x1e [udf] [c046f5f0] __fput+0xa5/0x15b [c046d0d2] generic_file_open+0x0/0x45 [c046d3f3] __dentry_open+0x115/0x17a [c046d4d2] nameidata_to_filp+0x24/0x33 [c046d513] do_filp_open+0x32/0x39 [c046d278] get_unused_fd+0x50/0xb6 [c046d55c] do_sys_open+0x42/0xbe [c046d611] sys_open+0x1c/0x1e [c0404db8] syscall_call+0x7/0xb === BUG: at /src/linux-2.6.21-rc5/fs/udf/truncate.c:123 udf_discard_prealloc() [de969274] udf_discard_prealloc+0x2d8/0x2ed [udf] [de9632ae] udf_clear_inode+0x1b/0x34 [udf] [c047eb56] clear_inode+0xb2/0x100 [c0459a95] truncate_inode_pages+0x17/0x1a [c047edfe] dispose_list+0x33/0xb1 [c047f1f3] invalidate_inodes+0xa8/0xbd [c046fff2] generic_shutdown_super+0x31/0xb7 [c0470095] kill_block_super+0x1d/0x2d [c047013d] deactivate_super+0x52/0x65 [c0480de8] sys_umount+0x1f2/0x21a [c044e33f] audit_syscall_entry+0x10d/0x137 [c0480e27] sys_oldumount+0x17/0x1a [c0404db8] syscall_call+0x7/0xb -- 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: 2.6.22 -mm merge plans
* Andrew Morton ([EMAIL PROTECTED]) wrote:
Although some, like Christoph and myself, think that it would benefit to
the kernel community to have a common infrastructure for more than just
markers (meaning common serialization and buffering mechanism), it does
not change the fact that the markers, being in mainline, are usable by
projects through additional kernel modules.
If we are looking at current potential users that are already in
mainline, we could change blktrace to make it use the markers.
That'd be a useful demonstration.
Here is a proof of concept patch, for demonstration purpose, of moving
blktrace to the markers.
A few remarks : this patch has the positive effect of removing some code
from the block io tracing hot paths, minimizing the i-cache impact in a
system where the io tracing is compiled in but inactive.
It also moves the blk tracing code from a header (and therefore from the
body of the instrumented functions) to a separate C file.
There, as soon as one device has to be traced, every devices have to
fall into the tracing function call. This is slower than the previous
inline function which tested the condition quickly. If it becomes a
show stopper, it could be fixed by having the possibility to test a
supplementary condition, dependant of the marker context, at the marker
site, just after the enable/disable test.
It does not make the code smaller, since I left all the specialized
tracing functions for requests, bio, generic, remap, which would go away
once a generic infrastructure is in place to serialize the information
passed to the marker. This is mostly why I consider it a proof a
concept.
Patch named markers-port-blktrace-to-markers.patch, can be placed
after the marker patches in the 2.6.21-rc7-mm2 series.
Signed-off-by: Mathieu Desnoyers [EMAIL PROTECTED]
Index: linux-2.6-lttng/block/elevator.c
===
--- linux-2.6-lttng.orig/block/elevator.c 2007-05-02 20:33:22.0
-0400
+++ linux-2.6-lttng/block/elevator.c2007-05-02 20:33:49.0 -0400
@@ -32,7 +32,7 @@
#include linux/init.h
#include linux/compiler.h
#include linux/delay.h
-#include linux/blktrace_api.h
+#include linux/marker.h
#include linux/hash.h
#include asm/uaccess.h
@@ -571,7 +571,7 @@
unsigned ordseq;
int unplug_it = 1;
- blk_add_trace_rq(q, rq, BLK_TA_INSERT);
+ MARK(blk_request_insert, %p %p, q, rq);
rq-q = q;
@@ -757,7 +757,7 @@
* not be passed by new incoming requests
*/
rq-cmd_flags |= REQ_STARTED;
- blk_add_trace_rq(q, rq, BLK_TA_ISSUE);
+ MARK(blk_request_issue, %p %p, q, rq);
}
if (!q-boundary_rq || q-boundary_rq == rq) {
Index: linux-2.6-lttng/block/ll_rw_blk.c
===
--- linux-2.6-lttng.orig/block/ll_rw_blk.c 2007-05-02 20:33:32.0
-0400
+++ linux-2.6-lttng/block/ll_rw_blk.c 2007-05-02 23:21:02.0 -0400
@@ -28,6 +28,7 @@
#include linux/task_io_accounting_ops.h
#include linux/interrupt.h
#include linux/cpu.h
+#include linux/marker.h
#include linux/blktrace_api.h
#include linux/fault-inject.h
@@ -1551,7 +1552,7 @@
if (!test_and_set_bit(QUEUE_FLAG_PLUGGED, q-queue_flags)) {
mod_timer(q-unplug_timer, jiffies + q-unplug_delay);
- blk_add_trace_generic(q, NULL, 0, BLK_TA_PLUG);
+ MARK(blk_plug_device, %p %p %d, q, NULL, 0);
}
}
@@ -1617,7 +1618,7 @@
* devices don't necessarily have an -unplug_fn defined
*/
if (q-unplug_fn) {
- blk_add_trace_pdu_int(q, BLK_TA_UNPLUG_IO, NULL,
+ MARK(blk_pdu_unplug_io, %p %p %d, q, NULL,
q-rq.count[READ] + q-rq.count[WRITE]);
q-unplug_fn(q);
@@ -1628,7 +1629,7 @@
{
request_queue_t *q = container_of(work, request_queue_t, unplug_work);
- blk_add_trace_pdu_int(q, BLK_TA_UNPLUG_IO, NULL,
+ MARK(blk_pdu_unplug_io, %p %p %d, q, NULL,
q-rq.count[READ] + q-rq.count[WRITE]);
q-unplug_fn(q);
@@ -1638,7 +1639,7 @@
{
request_queue_t *q = (request_queue_t *)data;
- blk_add_trace_pdu_int(q, BLK_TA_UNPLUG_TIMER, NULL,
+ MARK(blk_pdu_unplug_timer, %p %p %d, q, NULL,
q-rq.count[READ] + q-rq.count[WRITE]);
kblockd_schedule_work(q-unplug_work);
@@ -2148,7 +2149,7 @@
rq_init(q, rq);
- blk_add_trace_generic(q, bio, rw, BLK_TA_GETRQ);
+ MARK(blk_get_request, %p %p %d, q, bio, rw);
out:
return rq;
}
@@ -2178,7 +2179,7 @@
if (!rq) {
struct io_context *ioc;
- blk_add_trace_generic(q, bio, rw, BLK_TA_SLEEPRQ);
Re: [PATCH] [16/34] i386: fix mtrr sections
Andi Kleen wrote: As Andy already submitted it to Linus with http://lkml.org/lkml/2007/5/2/346 we may have to create a patch which reverts this patch. Ok thanks for the explanation. I will queue a revert patch I'm also planning to add some function headers to the MTRR functions and also fix the existing and upcoming function headers to be complant to kernel-doc. Thanks -Andi Thanks from me also. -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-cifs-client] Re: SMB2 file system - should it be a distinct module
Christoph Hellwig wrote: Can we please stop the bullshitting now? And can you please get a realname before playing smart ass on filesystem developers lists? Simo's full name is in his .sig - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22 -mm merge plans
On Thu, May 03, 2007 at 11:04:15AM -0400, Mathieu Desnoyers wrote:
- blk_add_trace_rq(q, rq, BLK_TA_INSERT);
+ MARK(blk_request_insert, %p %p, q, rq);
I don't really like the shouting MARK name very much. Can we have
a less-generic, less shouting name, e.g. trace_marker? The aboe would then
be:
trace_mark(blk_request_insert, %p %p, q, rq);
+#define NUM_PROBES ARRAY_SIZE(probe_array)
just get rid of this and use ARRAY_SIZE diretly below.
+int blk_probe_connect(void)
+{
+ int result;
+ uint8_t i;
just use an int for for loops. it's easy to read and probably faster
on most systems (it the compiler isn't smart enough and promotes it
to int anyway during code generation)
+void blk_probe_disconnect(void)
+{
+ uint8_t i;
+
+ for (i = 0; i NUM_PROBES; i++) {
+ marker_remove_probe(probe_array[i].name);
+ }
+ synchronize_sched();/* Wait for probes to finish */
kprobes does this kind of synchronization internally, so the marker
wrapper should probabl aswell.
+static int blk_probes_ref = 0;
no need to initialize this.
/*
* Send out a notify message.
*/
@@ -229,6 +233,12 @@
blk_remove_tree(bt-dir);
free_percpu(bt-sequence);
kfree(bt);
+ mutex_lock(blk_probe_mutex);
+ if (blk_probes_ref == 1) {
+ blk_probe_disconnect();
+ blk_probes_ref--;
+ }
if (--blk_probes_ref == 0)
blk_probe_disconnect();
would probably be a tad cleaner.
+ if (!blk_probes_ref) {
+ blk_probe_connect();
+ blk_probes_ref++;
+ }
Dito here with a:
if (!blk_probes_ref++)
blk_probe_connect();
also the connect in the name seems rather add, what about arm/disarm instead?
static __init int blk_trace_init(void)
{
mutex_init(blk_tree_mutex);
+ mutex_init(blk_probe_mutex);
both should use DEFINE_MUTEX for compile-time initialization isntead.
Also it's probably better to put the trace points into blktrace.c,
that means all blktrace code can be static and self-contained. And we
can probably do some additional cleanups by simplifying things later on.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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] CFS scheduler, -v7
* Ting Yang [EMAIL PROTECTED] wrote: +s64 __delta = curr-fair_key - p-fair_key; + +/* + * Take scheduling granularity into account - do not + * preempt the current task unless the best task has + * a larger than sched_granularity fairness advantage: + */ +if (__delta niced_granularity(rq, curr, granularity)) +resched_task(curr); +} This code actually now says, the difference of fair_key needed to preempt the current task is amplified by a facto of its weigh (in Al Boldi's example 32). However, the weighted task already advance its p-fair_key by its weight, (also 32 here). The combination of them becomes quadratic! it's not quadratic in terms of CPU share: the first factor impacts the CPU share, the second factor impacts the granularity. This means that reniced workloads will be preempted in a more finegrained way - but otherwise there's _no_ quadratic effect for CPU time - which is a completely separate metric. Remember: there are no timeslices in CFS, so a task can be preempted any number of times without being at a disadvantage. Besides this quadratic effect, another minor issue amplified this a little bit further: p-wait_runtime accumulated before. [...] actually, this 'minor issue' was the main issue that caused the bug ;-) 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: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
Mauro Carvalho Chehab wrote: Em Qua, 2007-05-02 Ã s 04:10 -0700, Trent Piepho escreveu: On Tue, 1 May 2007, Mauro Carvalho Chehab wrote: However, when dst is selected, I got those errors: When I made this patch I was basing it off a patch I made around 9 months ago. I thought since that one was ok, this would be ok too, and in my hurry to get it done I've clearly put too little effort into checking it, and I'm sorry to have wasted your time. I promise, this time it's right! http://linuxtv.org/hg/~tap/dst-new Confirmed. Now the patch is properly working. My tests were done with a board with DST. Those are the results: 1) when DST is unselected, on a board with DST, it will print the errors indicating that the Kconfig items were not selected: DVB: registering new adapter (bttv0). DVB: Unable to find symbol dst_attach() frontend_init: Could not find a Twinhan DST. dvb-bt8xx: A frontend driver was not found for device 109e/0878 subsystem fbfb/f800 The only issue is the wrong printk msg, stating that a frontend driver were not found. As this issue also happens with the current driver, due the usage of dvb_attach() macro, I don't see any regressions. It would be nice, however, to have a patch making dvb_attach more generic, by e.g. having a variant that allows passing another message. Trying to run dvb programs like scan and kaffeine will properly fail. 2) With DST selected, the driver works properly. The changes also solved the issue of removing the dst drivers. Before the patch, sometimes it is required to force removal of dst module with the '-f' flag, since the module count were wrong. --- I'll risk to make a briefing of the technical points: SUMMARY Current issues: 1) allow deselecting DST/DST_CA support, since this is not needed by some supported boards; 2) sometimes, module removal don't work with dst, since usage count becomes wrong; 3) if dst or dst_ca is not properly loaded, the printk message wrongly indicates that A frontend driver was not found The Trent's original patch were written on Aug, 2006 (*). The current version fixes (1) and (2). It doesn't touch on (3). There aren't any other patches properly fixing (1) and (2). There's an argument against the prototype changes on dst_attach and dst_ca_attach since they aren't frontend. /SUMMARY (*) Notice: I can't remember why the patches were not applied on that time. I think somebody nacked they, although I didn't found any record about the patch on my mailbox. About the usage of frontend support for a non-frontend module, I really can't see any issues at the current implementation, since even before the patch, all DST initialization are done by a routine called frontend_init(). *Wrong*. Frontend Init sends a command to the whole system to initialize the frontend, Not initialize the DST Whatever frontend naming conventions are in there are a relic from Andrew's FE_REFACTORING changesets. Even dst not being a frontend, the initialization gets the result of the attachment process, using it as a frontend: state = kmalloc(sizeof (struct dst_state), GFP_KERNEL); state-config = dst_config; state-i2c = card-i2c_adapter; state-bt = card-bt; state-dst_ca = NULL; dvb_attach(dst_attach, state, card-dvb_adapter); card-fe = state-frontend; (comments and error checks removed to make code cleaner) The patch basically moved state initialization to dst_attach. The above code, after the patch is: card-fe = dvb_attach(dst_attach, dst_config, card-bt, card-i2c_adapter); So, I didn't noticed any regressions by running the modified driver nor I couldn't identify any regressions by inspecting the source code. The end result seems also cleaner and easier to understand, preserving all characteristics of the original code. Also, it uses dvb_attach the same way as the other dvb helper modules. If later any changes will be needed to allow using DST on different configurations, future patches probably will need to move dst initialization to other places, and use different callbacks for it, altering the above initialization. I can't see why those changes would possibly avoid any further changes at the driver. That's said, I intend to commit the two patches, fixing the current issues, at this weekend. I did explain my stand in a previous mail. NACK - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: netfront for review
On Thu, May 03, 2007 at 09:33:43AM +0200, Gerd Hoffmann wrote: Guess so. It defaults to flip. I simplified the rx_copy/flip module parameter to a simple rx_mode=0/1, but this is preserved from the original. My guess is that originally there was only flip, and copy was added later. Yep, page flipping is the old (pre xen 3.0.3) way, copy was added (and made the default) later. So can we please just rip out the obsolete code completely? There's no point adding this code anymore. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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-cifs-client] Re: SMB2 file system - should it be a distinct module
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Simo, I guess DFS referrals can work cross protocol, so if you are redirected from a longhorn server to a windoes 2000 or a samba server you want to be able to follow the DFS referral and not return an error. To do that you need to have either 1 module that support both protocols or a way from one module to call the other. Just separating the 2 without any glue will not work (or you will have to add some userspace upcall hack to make it work). Long term I agree that CIFS and SMB2 should be in the same .ko But NTLM 0.12 still works for Vista and DFS referrals. Breaking out SMB2 initially means that it will not clutter the working cifs.ko code. Remember that an SMB2 client fs is mostly research at this point, and not engineering. cheers, jerry = Samba--- http://www.samba.org Centeris --- http://www.centeris.com What man is a man who does not make the world better? --Balian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGOfWsIR7qMdg1EfYRAk35AJ9bCG/s2rIn2HVB4XehxBMY8XH1AQCgkQUj Jy522rF0YIdICgd70IWKj4s= =EWTL -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] CFS scheduler, -v8
Srivatsa Vaddagiri wrote: On Thu, May 03, 2007 at 10:50:15AM +0200, Ingo Molnar wrote: - EEVDF concentrates on real-time (SCHED_RR-alike) workloads where they know the length of work units This is what I was thinking when I wrote earlier that EEVDF expects each task will specify length of each new request (http://lkml.org/lkml/2007/5/2/339). This is not very true based on my understanding of EEVDF, please look at the email I just sent out to Ingo for explanation. The other observation that I have of EEVDF is that it tries to be fair in the virtual time scale (each client will get 'wi' real units in 1 virtual unit), whereas sometimes fairness in real-time scale also matters? For ex: a multi-media app would call scheduler fair to it, it it recvs atleast 1 ms cpu time every 10 *real* milleseconds (frame-time). A rogue user (or workload) that does a fork bomb may skew this fairness for that multi-media app in real-time scale under EEVDF? First of all, CFS does not seems to address this issue to. This is a typical real-time or soft real-time question, that is not only the bandwidth of a task has to be fixed, i.e. 10% of cpu bandwidth (which proportional shared system, like CFS, EEVDF does not do), and the work need to satisfy a deadline. In both CFS, EEVDF, the scheduler have keep tweaking weights to give a fixed bandwidth to application. Authors of EEVDF claims this can be done, but never implemented :-( Ting - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] crypto: convert crypto.h to UTF-8
On May 3 2007 09:21, John Anthony Kazos Jr. wrote: There's no reason for any non-UTF-8 to be in the tree at all, so eventually it won't be a problem. I'm (slowly but surely) working on converting everything in the tree. GCC handles UTF-8 just fine, and all In fact, GCC gives a crap about comments :) and otherwise sees things as octets, not characters. I think GCJ is the only one that really pays attention to encoding. non-stupid/non-broken distributions of GNU/Linux and other major Un*ces should be based on (or at least compatible with) UTF-8 in basic operations. Files like the keymaps will be more work to convert, but they can be as well. I'm operating on the assumption that anything in the tree that isn't UTF-8 is ISO-8859-1. Of course, I'm also checking it by hand to make sure a small-O-with-umlaut doesn't become the Klingon logo... This is probably all you'll ever see: http://lkml.org/lkml/2007/1/8/222 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/
[PATCH 1/1] Misc: phantom, diff to -v3
Andrew, there are suggested changes in the attached patch. Maybe merge it with
misc-add-sensable-phantom-driver.patch if possible.
--
phantom, diff to -v3
Signed-off-by: Jiri Slaby [EMAIL PROTECTED]
---
commit b5c1fc64195b18d3919bfa7dddfb76e9f2a05786
tree 0d7e83a45f816b146b3b99ea0fe096ff1456b72f
parent d8cb58f904b80e250383e68832204fafaf02da8b
author Jiri Slaby [EMAIL PROTECTED] Thu, 03 May 2007 16:45:33 +0200
committer Jiri Slaby [EMAIL PROTECTED] Thu, 03 May 2007 16:45:33 +0200
drivers/misc/phantom.c | 24 ++--
include/linux/Kbuild |1 +
2 files changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/misc/phantom.c b/drivers/misc/phantom.c
index bca00a0..35b139b 100644
--- a/drivers/misc/phantom.c
+++ b/drivers/misc/phantom.c
@@ -21,6 +21,7 @@
#include linux/cdev.h
#include linux/phantom.h
+#include asm/atomic.h
#include asm/io.h
#define PHANTOM_VERSIONn0.9.5
@@ -40,7 +41,7 @@ struct phantom_device {
u32 __iomem *iaddr;
u32 __iomem *oaddr;
unsigned long status;
- unsigned int counter;
+ atomic_t counter;
wait_queue_head_t wait;
struct cdev cdev;
@@ -55,6 +56,7 @@ static int phantom_status(struct phantom_device *dev,
unsigned long newstat)
pr_debug(phantom_status %lx %lx\n, dev-status, newstat);
if (!(dev-status PHB_RUNNING) (newstat PHB_RUNNING)) {
+ atomic_set(dev-counter, 0);
iowrite32(PHN_CTL_IRQ, dev-iaddr + PHN_CONTROL);
iowrite32(0x43, dev-caddr + PHN_IRQCTL);
} else if ((dev-status PHB_RUNNING) !(newstat PHB_RUNNING))
@@ -145,6 +147,8 @@ static int phantom_open(struct inode *inode, struct file
*file)
struct phantom_device *dev = container_of(inode-i_cdev,
struct phantom_device, cdev);
+ nonseekable_open(inode, file);
+
if (mutex_lock_interruptible(dev-open_lock))
return -ERESTARTSYS;
@@ -165,8 +169,7 @@ static int phantom_release(struct inode *inode, struct file
*file)
{
struct phantom_device *dev = file-private_data;
- if (mutex_lock_interruptible(dev-open_lock))
- return -ERESTARTSYS;
+ mutex_lock(dev-open_lock);
dev-opened = 0;
phantom_status(dev, dev-status ~PHB_RUNNING);
@@ -181,14 +184,14 @@ static unsigned int phantom_poll(struct file *file,
poll_table *wait)
struct phantom_device *dev = file-private_data;
unsigned int mask = 0;
- pr_debug(phantom_poll: %u\n, dev-counter);
+ pr_debug(phantom_poll: %d\n, atomic_read(dev-counter));
poll_wait(file, dev-wait, wait);
- if (dev-counter) {
+ if (atomic_read(dev-counter)) {
mask = POLLIN | POLLRDNORM;
- dev-counter--;
+ atomic_dec(dev-counter);
} else if ((dev-status PHB_RUNNING) == 0)
mask = POLLIN | POLLRDNORM | POLLERR;
- pr_debug(phantom_poll end: %x/%u\n, mask, dev-counter);
+ pr_debug(phantom_poll end: %x/%d\n, mask, atomic_read(dev-counter));
return mask;
}
@@ -210,7 +213,7 @@ static irqreturn_t phantom_isr(int irq, void *data)
iowrite32(0, dev-iaddr);
iowrite32(0xc0, dev-iaddr);
- dev-counter++;
+ atomic_inc(dev-counter);
wake_up_interruptible(dev-wait);
return IRQ_HANDLED;
@@ -367,6 +370,9 @@ static int phantom_resume(struct pci_dev *pdev)
return 0;
}
+#else
+#define phantom_suspendNULL
+#define phantom_resume NULL
#endif
static struct pci_device_id phantom_pci_tbl[] __devinitdata = {
@@ -381,10 +387,8 @@ static struct pci_driver phantom_pci_driver = {
.id_table = phantom_pci_tbl,
.probe = phantom_probe,
.remove = __devexit_p(phantom_remove),
-#ifdef CONFIG_PM
.suspend = phantom_suspend,
.resume = phantom_resume
-#endif
};
static ssize_t phantom_show_version(struct class *cls, char *buf)
diff --git a/include/linux/Kbuild b/include/linux/Kbuild
index e81badd..0aa1c55 100644
--- a/include/linux/Kbuild
+++ b/include/linux/Kbuild
@@ -122,6 +122,7 @@ header-y += pci_regs.h
header-y += personality.h
header-y += pfkeyv2.h
header-y += pg.h
+header-y += phantom.h
header-y += pkt_cls.h
header-y += pkt_sched.h
header-y += posix_types.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: Back to the future.
Hi! The kernel can already do compression and encryption. Yes, if we all could agree on _which_ compression and encryption Any of those available in the kernel. Where's the problem? gzip is too slow for this. lzf works okay. Oh and swsusp wants rsa crypto. 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: Back to the future.
Hi! 1) if the kernel threads are frozen, we know that they don't hold any locks that could interfere with the freezing of device drivers, 2) if they are frozen, we know, for example, that they won't call user mode helpers or do similar things, 3) if they are frozen, we know that they won't submit I/O to disks and potentially damage filesystems (suspend2 has much more problems with that than swsusp, but still. And yes, there have been bug reports related to it, so it's not just my fantasy). NONE of these are valid explanations at all. You're listing totally theoretical problems, and ignoring all the _real_ problems that trying to freeze kernel threads has _caused_. xfs problem was real. And I do not see that many problems caused by freezing kernel threads: at least you get deadlocks, not silent fs corruption. And no, kernel threads do not submit IO to disks on their own. You just made that up. Yes, they can be involved in that whole disk submission thing, but in a good way - they can be required in order to make disk writing work! Yep, so we have md doing io while we are doing atomic copy. That probably means it will continue when atomic copy is done... getting image out of sync with disk. (Plus we used to have bdflush, doing periodic writes to disk). The problem that suspend has had is that it's done everything totally the wrong way around. Do kernel threads do disk IO? Sure, if asked to do so. For example, kernel threads can be involved in md etc, but that's a *good* thing. The way to shut them up is not to freeze the threads, but to freeze the *disk*. Well, if freezing the disk was available, I'd gladly do it. Is there easy way to implement that? 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: Back to the future.
Hi! It makes it harder to debug (wouldn't it be *nice* to just ssh in, and do gdb -p snapshotter Make the machine being suspended a VM and you can already do that. when something goes wrong?) but we also *depend* on user space for various things (the same way we depend on kernel threads, and why it has been such a total disaster to try to freeze the kernel threads too!). For example, if you want to do graphical stuff, just using X would be quite nice, wouldn't it? But in doing so you make the contents of the disk inconsistent with the state you've just snapshotted, leading to filesystem corruption. Even if you modify filesystems to do checkpointing (which is what we're really talking about), you still also have the problem that your snapshot has to be stored somewhere before you write it to disk, so you also have to either [snip] Actually, it's a lot simpler than that. We can just combine the device-mapper snapshot with a VM+kernel snapshot system call and be almost done: sys_snapshot(dev_t snapblockdev, int __user *snapshotfd); When sys_snapshot is run, the kernel does: 1) Sequentially freeze mounted filesystems using blockdev freezing. If it's an fs that doesn't support freezing then either fail or force- remount-ro that fs and downgrade all its filedescriptors to RO. Doesn't need extra locking since process which try to do IO either succeed before the freeze call returns for that blockdev or sleep on the unfreeze of that blockdev. Filesystems are synchronized and made clean. How mature is freezing filesystems -- will it work on at least ext2/3 and vfat? What happens if you try to boot and filesystems are frozen from previous run? 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: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
Original-Nachricht Datum: Thu, 03 May 2007 18:44:36 +0400 Von: Manu Abraham [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: linux-kernel@vger.kernel.org, [EMAIL PROTECTED] Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical pointsabout ...) Uwe Bugla wrote: On the technical layer I noticed that I heard some Pinnacle relais click during testing, but there were some i2c_bus symbols missing during compilation. So I guess those missing symbols are responsible for getting neither picture nor sound. Can you send your compile warnings ? I couldn't find the same in my mailbox any report on the same. Maybe my mail filter did something. I can certainly send compile warnings and dmesg and whatever you need. But at first I need another link WHERE I can download the actual cx878 code. Is it thaddathil.net or where the hell has it gone? Just send me one link please, otherwise I do not have any chance to help you, OK? A. If you are really interested I can send you my basic puzzle parts in short, opening a new thread on this issue. Just give me a short response if you are interested. B. If you want to continue the cx878 project please drop me a short note where I can download it to test and enlarge it with my own ideas as good as I can. Must not be immediately (no sweat please), but I am looking forward to receive a response from you. What i would like to do is like this: Have the current state frozen as it is, such that there is a fallback case (The dst is quite fragile and change at some place would break another. ie, what looks good for one DST variant is bad for the other). Work on a new tree (CX878) and migrate stuff to it. Remove the old one, once things are done. I wouldn't want to mess up the current working situation and hence. Hi Manu, But it would be an acceptable compromise FOR NOW, wouldn't it? So please don't turn your back on it, even if it may be incomplete for your needs. Just add your SOB and then focus on cx878 with full power, OK? Anything else would be terrible in pschological terms, you know? Just think about Trent, Markus, me, so many others, you know. Do I expect too much? Hope I do not! Plus: If I should help you it would be a pleasure for me if you could offer an acceptable time window that fulfills the following aims: a. not to exhaust or threaten or bug you or nerve you (noone wants that, you know) b. give me and others a feeling for when things of whatever issue are done and resolved, you know. So at least for me it's very hard to continue if the whole thing looks like a never ending story, you know? So please give us a chance. And please do better this time. Just learn and develop, you know. And be more transparent and eloquent this time, but do not crawl back into a snail house, OK? Waiting for your link meanwhile to download that hopeful project... CCing some other persons who are perhaps interested in this Yours sincerely Uwe -- Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Back to the future.
Hi! While that would certainly be nifty, I think we're arguably starting from the wrong point here. Why are we booting a kernel, trying to poke the hardware back into some sort of mock-quiescent state, freeing memory and then (finally) overwriting the entire contents of RAM rather than just doing all of this from the bootloader? Doing it from the bootloader sounds attractive... but it is lot of work. I'm essentially using linux as a bootloader. Patch for grub welcome. Sure, you could make suspend generate a complete bootable kernel image containing all RAM. Doesn't sound too hard to me. You know, from over here on the sidelines. Ah, so we have a volunteer :-). 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: [linux-cifs-client] Re: SMB2 file system - should it be a distinct module
To clarify: 1) SMB2 is negotiated like a new dialect (of SMB/CIFS). The new dialects is sent in the same SMB negotiate protocol request that has been used for years. The protocol header format changes to that of SMB2 (if accepted by the server) on all subsequent requests. 2) If the server does not support SMB2, the client should fall back to using CIFS (as existing SMB2 clients do). 3) So far, all servers which support SMB2 also support CIFS. If SMB2 protocol support were coded as a distinct module, the smb2.ko would need to load cifs.ko to complete session setup in many cases (presumably when mounting to NetApp, EMC, most older Windows servers and some Samba servers - at least for a few years). Because we (Samba, Linux client and even MacOS, HP/UX) have added optional extensions to CIFS which are not present in SMB2 (although we should add them), the difficulty is simply which to try first: 1) If we knew the server did not support the CIFS Unix Exensions (CIFS POSIX Protocol Extensions) but the server was new enough to support SMB2 then we should request SMB2 (as soon as a stable SMB2 Linux kernel client were written/tested). SMB2 has increased limits on file handles, and should perform marginally better (if the client were well implemented, unlike some non-Linux clients ...) But we don't know until the response from the SMB Negotiate Protocol what the server capabilities are. Eventually this problem goes away, when we specify and code Unix Protocol Extensions to SMB2 for Samba etc. as we have done for CIFS, but in the meantime, I am leaning toward: 1) trying SMB/CIFS only (not including SMB2 dialect) on DFS referrals by default (unless the user configures the client differently at run time) 2) On mount trying smb2 only if the user mounted explicitly with -t smb2 (but fallback to CIFS if the server does not support SMB2) - otherwise (for -t cifs) mount is unchanged. In any case SMB2 would be considered experimental (for a Linux client) for quite some time, so there is no hurry to decide until there is feedback from users. I am pleased that SMB2 does clean up the protocol header format - and it should be easier to code in some ways since there are so few operations to support/optimize (and almost all are handlebased), but it is way to early to tell which is better (as far as I know, no one has even proved whether SMB2 is faster than CIFS or Vista to Vista mounts). On 5/3/07, simo [EMAIL PROTECTED] wrote: On Thu, 2007-05-03 at 09:46 -0500, Gerald Carter wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Simo, I guess DFS referrals can work cross protocol, so if you are redirected from a longhorn server to a windoes 2000 or a samba server you want to be able to follow the DFS referral and not return an error. To do that you need to have either 1 module that support both protocols or a way from one module to call the other. Just separating the 2 without any glue will not work (or you will have to add some userspace upcall hack to make it work). Long term I agree that CIFS and SMB2 should be in the same .ko But NTLM 0.12 still works for Vista and DFS referrals. Breaking out SMB2 initially means that it will not clutter the working cifs.ko code. Remember that an SMB2 client fs is mostly research at this point, and not engineering. Well, development can happen in any way Steve or any other like to do it, but it seemed to me that the proposal was to split them long term. I think this would be bad wrt supporting DFS referrals. That said, it I'll shut up as kindly requested from someone that seem to know better than Samba/CIFS developers. Simo. -- Simo Sorce Samba Team GPL Compliance Officer email: [EMAIL PROTECTED] http://samba.org -- Thanks, Steve - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
Original-Nachricht Datum: Thu, 03 May 2007 19:15:32 +0400 Von: Manu Abraham [EMAIL PROTECTED] An: Mauro Carvalho Chehab [EMAIL PROTECTED] CC: [EMAIL PROTECTED], Trent Piepho [EMAIL PROTECTED], linux-kernel@vger.kernel.org Betreff: Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Criticalpoints about ...) Mauro Carvalho Chehab wrote: Em Qua, 2007-05-02 Ã s 04:10 -0700, Trent Piepho escreveu: On Tue, 1 May 2007, Mauro Carvalho Chehab wrote: However, when dst is selected, I got those errors: When I made this patch I was basing it off a patch I made around 9 months ago. I thought since that one was ok, this would be ok too, and in my hurry to get it done I've clearly put too little effort into checking it, and I'm sorry to have wasted your time. I promise, this time it's right! http://linuxtv.org/hg/~tap/dst-new Confirmed. Now the patch is properly working. My tests were done with a board with DST. Those are the results: 1) when DST is unselected, on a board with DST, it will print the errors indicating that the Kconfig items were not selected: DVB: registering new adapter (bttv0). DVB: Unable to find symbol dst_attach() frontend_init: Could not find a Twinhan DST. dvb-bt8xx: A frontend driver was not found for device 109e/0878 subsystem fbfb/f800 The only issue is the wrong printk msg, stating that a frontend driver were not found. As this issue also happens with the current driver, due the usage of dvb_attach() macro, I don't see any regressions. It would be nice, however, to have a patch making dvb_attach more generic, by e.g. having a variant that allows passing another message. Trying to run dvb programs like scan and kaffeine will properly fail. 2) With DST selected, the driver works properly. The changes also solved the issue of removing the dst drivers. Before the patch, sometimes it is required to force removal of dst module with the '-f' flag, since the module count were wrong. --- I'll risk to make a briefing of the technical points: SUMMARY Current issues: 1) allow deselecting DST/DST_CA support, since this is not needed by some supported boards; 2) sometimes, module removal don't work with dst, since usage count becomes wrong; 3) if dst or dst_ca is not properly loaded, the printk message wrongly indicates that A frontend driver was not found The Trent's original patch were written on Aug, 2006 (*). The current version fixes (1) and (2). It doesn't touch on (3). There aren't any other patches properly fixing (1) and (2). There's an argument against the prototype changes on dst_attach and dst_ca_attach since they aren't frontend. /SUMMARY (*) Notice: I can't remember why the patches were not applied on that time. I think somebody nacked they, although I didn't found any record about the patch on my mailbox. About the usage of frontend support for a non-frontend module, I really can't see any issues at the current implementation, since even before the patch, all DST initialization are done by a routine called frontend_init(). *Wrong*. Frontend Init sends a command to the whole system to initialize the frontend, Not initialize the DST Whatever frontend naming conventions are in there are a relic from Andrew's FE_REFACTORING changesets. Even dst not being a frontend, the initialization gets the result of the attachment process, using it as a frontend: state = kmalloc(sizeof (struct dst_state), GFP_KERNEL); state-config = dst_config; state-i2c = card-i2c_adapter; state-bt = card-bt; state-dst_ca = NULL; dvb_attach(dst_attach, state, card-dvb_adapter); card-fe = state-frontend; (comments and error checks removed to make code cleaner) The patch basically moved state initialization to dst_attach. The above code, after the patch is: card-fe = dvb_attach(dst_attach, dst_config, card-bt, card-i2c_adapter); So, I didn't noticed any regressions by running the modified driver nor I couldn't identify any regressions by inspecting the source code. The end result seems also cleaner and easier to understand, preserving all characteristics of the original code. Also, it uses dvb_attach the same way as the other dvb helper modules. If later any changes will be needed to allow using DST on different configurations, future patches probably will need to move dst initialization to other places, and use different callbacks for it, altering the above initialization. I can't see why those changes would possibly avoid any further changes at the driver. That's said, I intend to commit the two patches, fixing the current issues, at this weekend. I did explain my stand in a previous mail. NACK Technically may be OK, psychologically this decision is
Re: [PATCH] crypto: convert crypto.h to UTF-8
There's no reason for any non-UTF-8 to be in the tree at all, so eventually it won't be a problem. I'm (slowly but surely) working on converting everything in the tree. GCC handles UTF-8 just fine, and all In fact, GCC gives a crap about comments :) and otherwise sees things as octets, not characters. I think GCJ is the only one that really pays attention to encoding. The changes to the keymap files and so forth aren't quite as simple though. Have to convert the latin1 characters within character-constant expressions to \0 notation, while the comments can be left as utf8. non-stupid/non-broken distributions of GNU/Linux and other major Un*ces should be based on (or at least compatible with) UTF-8 in basic operations. Files like the keymaps will be more work to convert, but they can be as well. I'm operating on the assumption that anything in the tree that isn't UTF-8 is ISO-8859-1. Of course, I'm also checking it by hand to make sure a small-O-with-umlaut doesn't become the Klingon logo... This is probably all you'll ever see: http://lkml.org/lkml/2007/1/8/222 Does this mean you're doing it and I'll be ignored, or that few people care and I'll be ignored? I figure if I just repost my patches to LKML once per month, they'll eventually get merged (or at least I'll get comments on how people actually want them). Things are tough on a high-volume list. I think the git method may have the best chance of success. We'll see. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Execute in place
On Thu, 3 May 2007 13:38:22 +0200, Erik Mouw wrote: On Wed, May 02, 2007 at 03:04:44PM +0100, Hugh Dickins wrote: Only ext2 supports it today: see Documentation/filesystems/xip.txt IIRC JFFS2 also supports XIP. Definitely not. AXFS does, if you want to consider out-of-tree patches. Jörn -- Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it. -- Perlis's Programming Proverb #58, SIGPLAN Notices, Sept. 1982 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: netfront for review
Christoph Hellwig wrote: On Thu, May 03, 2007 at 09:33:43AM +0200, Gerd Hoffmann wrote: Guess so. It defaults to flip. I simplified the rx_copy/flip module parameter to a simple rx_mode=0/1, but this is preserved from the original. My guess is that originally there was only flip, and copy was added later. Yep, page flipping is the old (pre xen 3.0.3) way, copy was added (and made the default) later. So can we please just rip out the obsolete code completely? There's no point adding this code anymore. Drawback is that the guest kernel wouldn't work with older xen versions (dom0 netback driver to be exact) any more. Probably wouldn't be a showstopper though, given that xen 3.0.3 probably is almost one year out by the time 2.6.22 will be released ... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] [POWERPC] 8xx: mpc885ads pcmcia support
+ [EMAIL PROTECTED] {
+ compatible = 8xx;
The compatible property should be a little more specific, imho. Since
there
are differences in how things are done depending on the board, it
would be
good to tell the exact method from the pcmcia node itself.
Just 8xx isn't good enough -- at a very minimum it
needs to say this is a PCMCIA controller!
For example, you could make this
compatible = 8xx\0mpc885ads;
mpc885ads-pcmcia\0mpc8xx-pcmcia or something like that.
Segher
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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-cifs-client] Re: SMB2 file system - should it be a distinct module
On Thu, May 03, 2007 at 10:35:41AM -0500, Steve French wrote: If SMB2 protocol support were coded as a distinct module, the smb2.ko would need to load cifs.ko to complete session setup in many cases (presumably when mounting to NetApp, EMC, most older Windows servers and some Samba servers - at least for a few years). Umm, no. If the user tries mount -t smb2 it would try only that and if it can't support the server it would fail. Similar for mount -t cifs if the server only supports modern dialects, which AFAIK none does. If you feel fancy add autoprobing to mount, similar to how we do automatic testing of superblocks for disk filesystems. In any case SMB2 would be considered experimental (for a Linux client) for quite some time, so there is no hurry to decide until there is feedback from users. I am pleased that SMB2 does clean up the protocol header format - and it should be easier to code in some ways since there are so few operations to support/optimize (and almost all are handlebased), but it is way to early to tell which is better (as far as I know, no one has even proved whether SMB2 is faster than CIFS or Vista to Vista mounts). Beeing handle based means it actually starts to get useable for Unix based client, so even if the protocol is not inherently faster the client side implementation will be a lot faster at least on big systems because the expensive path generation will go away. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] working 3D/DRI intel-agp.ko resume for i815 chip; Intel chipset testers wanted! (was: Re: intel-agp PM experiences ...)
On Wed, May 02, 2007 at 12:17:18PM +0200, Pavel Machek wrote:
#define INTEL_I820_RDCR 0x51
@@ -664,7 +671,7 @@
if ((pg_start + mem-page_count) num_entries)
goto out_err;
- /* The i830 can't check the GTT for entries since its read only,
+ /* The i830 can't check the GTT for entries since it's read-only,
* depend on the caller to make the correct offset decisions.
*/
@@ -787,7 +794,7 @@
if ((pg_start + mem-page_count) num_entries)
goto out_err;
- /* The i915 can't check the GTT for entries since its read only,
+ /* The i915 can't check the GTT for entries since it's read-only,
* depend on the caller to make the correct offset decisions.
*/
You should not do cleanups at the same time as code changes.
Indeed.
@@ -1103,8 +1110,8 @@
/* attbase - aperture base */
/* the Intel 815 chipset spec. says that bits 29-31 in the
* ATTBASE register are reserved - try not to write them */
- if (agp_bridge-gatt_bus_addr INTEL_815_ATTBASE_MASK) {
- printk (KERN_EMERG PFX gatt bus addr too high);
+ if (agp_bridge-gatt_bus_addr I815_ATTBASE_MASK) {
+ printk (KERN_EMERG PFX gatt bus addr too high\n);
return -EINVAL;
}
@@ -1119,7 +1126,7 @@
agp_bridge-gart_bus_addr = (temp PCI_BASE_ADDRESS_MEM_MASK);
pci_read_config_dword(agp_bridge-dev, INTEL_ATTBASE, addr);
- addr = INTEL_815_ATTBASE_MASK;
+ addr = I815_ATTBASE_MASK;
addr |= agp_bridge-gatt_bus_addr;
pci_write_config_dword(agp_bridge-dev, INTEL_ATTBASE, addr);
And I guess macro searchreplace counts as cleanup, too. It would be
nice to submit them separately and first.
I'm not a big fan of the s/INTEL_/I_/ change to be honest.
I'd prefer we didn't change this, as a) there may be additional
patches in flight which touch intel-agp.c depending on those defines,
b) it'll make future changes to intel-agp.c harder to backport to
-stable releases, and c) it doesn't really add any value.
@@ -1355,7 +1362,7 @@
pci_write_config_dword(agp_bridge-dev, INTEL_ATTBASE,
agp_bridge-gatt_bus_addr);
/* agpctrl */
- pci_write_config_dword(agp_bridge-dev, INTEL_AGPCTRL, 0x);
+ pci_write_config_dword(agp_bridge-dev, INTEL_AGPCTRL, 0x);
Huh?
harmless, but ok.
+ pci_read_config_dword(pdev, p-reg, p-value);
+ }
+ return 1;
+}
Should this betwo functions, one for save, one for restore, with to
save array being global?
yes.
+/*
+ * set DEBUG_AGP_PM to 1 if your AGP chipset has issues resuming
+ * (machine lockups due to non-restored hardware registered values),
+ * then figure out from the log which registers have to be restored
manually,
+ * then add specific support for your chipset, similar to what already
exists
Can we get debugging stuff separately?
ACK.
@@ -2106,6 +2282,12 @@
{
if (agp_off)
return -EINVAL;
+ /* let people know that this is an important place to investigate at in
case of resume lockups */
+ printk(KERN_INFO PFX
+ suspend/resume of intel-agp.ko is NOT always stable for all
Intel AGP\n
+ chipset/BIOS combos, may cause resume lockups when DRI (3D
accel) active,\n
+ in AGP (non-PCI) mode! (see DEBUG_AGP_PM in intel-agp.c source
to investigate)\n
+ );
I'm not sure if we want such big/ugly warnings. Can you get it to one
line, at least?
I'd drop this completely. The majority of users will never see it anyway,
and the boot process already spews so much stuff that it'll just get lost
in the noise.
Thanks,
Dave
--
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Per-CPU data as a structure
Hello, At the moment, data specific to a CPU is stored in different, fixed- size separate arrays by means of the percpu framework. I'm working on some changes to modify the way some CPUs are represented, and I'm wondering what's the rationale behind such a representation. At first sight, it'd seem more reasonable to have a structure holding all the information that is CPU-specific (as is done with any object represented within the system). After searching the mail archives, I see that similar changes were proposed before, but those threads did not seem to get any reply (so I'm assuming that the changes were not desired). Similarly, and if I understood it correctly, the PDA (Per-processor Data Area) also aims to do the above, but at the moment it only contains some fields and is not defined in all platforms. There are still a lot of usages of the percpu functionality (such as, e.g., in kernel/sched.c). Part of my changes introduce a new structure that is able to represent any kind of CPU (and which each platform can extend to add new information to it). It is supposed to supersede the per-cpu definitions. I bet this could also be redone by using percpu in some way... The thing is I am willing to share my work when I've finished it (it is still very much work-in-progress), but first I'm interested to know if adding this new structure is a crazy idea (meaning I should stick to percpu wherever possible) or something that can be accepted later on. Summarizing, my questions are: - Why is the code currently using multiple separate arrays (percpu) to hold CPU information instead of a structure? - Could this structure-based approach (instead of all these separate arrays) be considered for inclusion into the system? As far as I can tell, the advantage of percpu is that you can define new fields anywhere in the code and independently from the rest of the system. Also, I seem to understand that there are performance advantages related to this. But on the other hand, percpu seems like an unnatural approach to reimplement regular structures. Thank you very much. -- Julio M. Merino Vidal [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: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
Uwe Bugla wrote: Hi Manu, But it would be an acceptable compromise FOR NOW, wouldn't it? The reason is i do not wish to make changes to it, till i can fix it. It is indeed hard to fix things that support a lot of devices, with different issues. There are enough of issues in there. You can look at all those frontend not found issues on the DVB ML. The people who make all these noise, do nothing but just play politics. Just do a search on the linux-dvb ML at gmane.org. You can easily find them. Waiting for your link meanwhile to download that hopeful project... http://thadathil.net:8000/cgi-bin/hgwebdir.cgi/cx878_41?ca=43abfe89c2c9;type=bz2 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] CFS scheduler, -v8
On Thu, May 03, 2007 at 03:29:32PM +0200, Damien Wyart wrote: What are your thoughts/plans concerning merging CFS into mainline ? Is it a bit premature to get it into 2.6.22 ? I remember Linus was ok to change the default scheduler rapidly (the discussion was about sd at that time) to get more testing than in -mm. On Thu, May 03, 2007 at 08:23:18PM +0530, Srivatsa Vaddagiri wrote: And what about group scheduling extensions? Do you have plans to work on it? I was begining to work on a prototype to do group scheduling based on CFS, basically on the lines of what you and Linus had outlined earlier: http://lkml.org/lkml/2007/4/18/271 http://lkml.org/lkml/2007/4/18/244 Tong Li's Trio scheduler does a bit of this, though it doesn't seem to have the mindshare cfs seems to have acquired. The hyperlink seems to have broken, though: http://www.cs.duke.edu/~tongli/linux/linux-2.6.19.2-trio.patch -- wli - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: swap-prefetch: 2.6.22 -mm merge plans
* Andrew Morton [EMAIL PROTECTED] wrote: - If replying, please be sure to cc the appropriate individuals. Please also consider rewriting the Subject: to something appropriate. i'm wondering about swap-prefetch: mm-implement-swap-prefetching.patch swap-prefetch-avoid-repeating-entry.patch add-__gfp_movable-for-callers-to-flag-allocations-from-high-memory-that-may-be-migrated-swap-prefetch.patch The swap-prefetch feature is relatively compact: 10 files changed, 745 insertions(+), 1 deletion(-) it is contained mostly to itself: mm/swap_prefetch.c| 581 i've reviewed it once again and in the !CONFIG_SWAP_PREFETCH case it's a clear NOP, while in the CONFIG_SWAP_PREFETCH=y case all the feedback i've seen so far was positive. Time to have this upstream and time for a desktop-oriented distro to pick it up. I think this has been held back way too long. It's .config selectable and it is as ready for integration as it ever is going to be. So it's a win/win scenario. Acked-by: Ingo Molnar [EMAIL PROTECTED] 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/
[MCA] fix bus matching
There's a bug in the MCA bus matching algorithm in that it promotes from
signed short to int before comparing with the actual id and does sign
extension on anything 0x7fff (which means that pos ids 0x7fff never
get correctly matched).
Signed-off-by: James Bottomley [EMAIL PROTECTED]
---
diff --git a/drivers/mca/mca-bus.c b/drivers/mca/mca-bus.c
index da862e4..a70fe00 100644
--- a/drivers/mca/mca-bus.c
+++ b/drivers/mca/mca-bus.c
@@ -47,7 +47,7 @@ static int mca_bus_match (struct device *dev, struct
device_driver *drv)
{
struct mca_device *mca_dev = to_mca_device (dev);
struct mca_driver *mca_drv = to_mca_driver (drv);
- const short *mca_ids = mca_drv-id_table;
+ const unsigned short *mca_ids = mca_drv-id_table;
int i;
if (!mca_ids)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: e1000 issue on DQ965GF board (was 24 lost ticks with 2.6.20.10 kernel)
Yes, this was discovered through code inspection last week and I've already made a fix (as I mentioned to Auke off-thread). It should be submitted upstream shortly. -Original Message- From: Kok, Auke [mailto:[EMAIL PROTECTED] Sent: Thursday, May 03, 2007 8:37 AM To: Michel Lespinasse Cc: Kok, Auke-jan H; Chuck Ebbert; linux-kernel@vger.kernel.org; Dave Jones; cramerj; Ronciak, John; Brandeburg, Jesse; Kirsher, Jeffrey T; Allan, Bruce W Subject: Re: e1000 issue on DQ965GF board (was 24 lost ticks with 2.6.20.10 kernel) [Adding Bruce to the Cc, reply below] Michel Lespinasse wrote: On Wed, May 02, 2007 at 11:14:52AM -0700, Kok, Auke wrote: I just checked and the fix I was referring to earlier didn't make it into 2.6.21-final. You can get 2.6.21-git1 from kernel.org which has the fix. See http://www.kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.21-git1. log Good. So I tried that patch (well, actually only the change visible at http://lkml.org/lkml/2007/3/6/268). I patched it into a 2.6.20.11 kernel, using the same config file as previously. The good news is that this fixes my issue: there are no lost ticks anymore, and the link does negotiate a gigabit connection. This is a great improvement for me :) I still seem to hit an issue if using the ethtool command, though. when using 'ethtool -s eth0 autoneg on', the link comes up at gigabit speed, but a couple seconds later is comes down again, and then up at 100 megabits: e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex e1000: eth0: e1000_watchdog: NIC Link is Down e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex e1000: eth0: e1000_watchdog: 10/100 speed: disabling TSO The same thing happens if I use ifdown eth0; ifup eth0 too. Once again, I only observe this on my DQ965GF motherboard, the DG965RY board is fine (stays at gigabit speed when I issue these commands). Is this something you could easily reproduce at Intel or would you want me to look into that issue on my system ? I think we have confirmed this issue and I'll work with Bruce on seeing where the fix went. I might give you another patch to try. Auke - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] UBI: dereference after kfree in create_vtbl
Coverity (CID 1614) spotted new_seb being dereferenced after kfree() in
create_vtbl's write_error path.
Signed-off-by: Florin Malita [EMAIL PROTECTED]
---
vtbl.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/mtd/ubi/vtbl.c b/drivers/mtd/ubi/vtbl.c
index b6fd6bb..91e3619 100644
--- a/drivers/mtd/ubi/vtbl.c
+++ b/drivers/mtd/ubi/vtbl.c
@@ -317,14 +317,13 @@ retry:
return err;
write_error:
- kfree(new_seb);
- /* May be this physical eraseblock went bad, try to pick another one */
- if (++tries = 5) {
+ /* Maybe this physical eraseblock went bad, try to pick another one */
+ if (++tries = 5)
err = ubi_scan_add_to_list(si, new_seb-pnum, new_seb-ec,
si-corr);
- if (!err)
- goto retry;
- }
+ kfree(new_seb);
+ if (!err)
+ goto retry;
out_free:
ubi_free_vid_hdr(ubi, vid_hdr);
return err;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
On 5/3/07, Manu Abraham [EMAIL PROTECTED] wrote: Uwe Bugla wrote: Hi Manu, But it would be an acceptable compromise FOR NOW, wouldn't it? The reason is i do not wish to make changes to it, till i can fix it. It is indeed hard to fix things that support a lot of devices, with different issues. There are enough of issues in there. You can look at all those frontend not found issues on the DVB ML. The people who make all these noise, do nothing but just play politics. Just do a search on the linux-dvb ML at gmane.org. You can easily find them. Manu, to me it looks like your attitude is not acceptable here, I sent several mails already which you just use to ignore. If you don't change that attitude immediatelly I'd really wish to get you banned of this community until you're open for discussions. http://www.mail-archive.com/linux-dvb%40linuxtv.org/msg22943.html there's a bugreport and you fully ignore it, and you blame it on the politicians here, telling me that there are mails out there somewhere shows that you're not interested in getting forward. I'm waiting for your response here. Markus Waiting for your link meanwhile to download that hopeful project... http://thadathil.net:8000/cgi-bin/hgwebdir.cgi/cx878_41?ca=43abfe89c2c9;type=bz2 -- Markus Rechberger - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: console font limits
On Thu, 3 May 2007, Jan Engelhardt wrote:
On May 3 2007 10:14, Albert Cahalan wrote:
On 5/3/07, Jan Engelhardt [EMAIL PROTECTED] wrote:
On May 3 2007 02:17, Albert Cahalan wrote:
Those sizes are unreadable on the 200 dpi OLPC XO screen,
Hm that should have read, for you:
I don't object implementing support for larger sizes.
(But I wonder how that should work without FB/CVIDIX/SVGA/VESA
extensions.)
Note that I was assuming that no FB is used:
I'm assuming that the FB is used. Neither of my two
computers can do VGA text mode.
Some non-x86 boxes like sparc?
OLPC is x86 ;-)
Then, as with X, you have problems with kernel messages.
Reliably sending printk through a userspace console is not
even possible. (consider a panic, OOM, or runaway RT task)
Actually, the kernel could just jump in. That is, when you start
in fb mode, you get the regular 8x16 vga font - on your choice of
resolution, and can also set it with setfont. So far so nice.
Now, when you start fbiterm -- for example to read CJK --, fbiterm
presents you with what looks like a 12x24 font. Also good.
It _looks_ to me like fbiterm does the drawing itself; ok too.
Now when the kernel is oopsing, it could just spew out the oops
trace in the regular font (vga8x16 or in case you use CONFIG_FONTS,
then that), possibly obstructing some output generated by fbiterm,
but in case of oops, I think this is ok.
Funny, that's exactly how kernel messages where handled in the early
fbdev days: just draw them to the frame buffer, whatever mode it is
in...
Just like on the SunOS boxes ;-)
Put people didn't like that, and disabled text output when the console
is in KD_GRAPHICS mode...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: netfront for review
Gerd Hoffmann wrote: Drawback is that the guest kernel wouldn't work with older xen versions (dom0 netback driver to be exact) any more. Probably wouldn't be a showstopper though, given that xen 3.0.3 probably is almost one year out by the time 2.6.22 will be released ... I don't think we've decided how backwards-compatible the pv_ops guest should be. I've been working on the basis as much as possible, so long as it isn't a large burden. J - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] CFS scheduler, -v7
Hi, Ingo I wrote that email in a hurry, therefore might not explain the problem clearly. However I do think there is a problem for this part, after I carefully read the code again. Now I want to try again :-) Hopefully, this time I will do a right job. Starting from the following code: +if (__delta niced_granularity(rq, curr, granularity)) +resched_task(curr); Suppose, curr has nice value -10, then curr-load_shift = 15. Granularity passed into this function is fixed 2,000,000 (for CFS -v8). Let's just divide everything by 1,000,000 for simplicity, say granularity used is 2. Now, we look at how granularity is rescaled: +int load_shift = p-load_shift; + +if (load_shift == SCHED_LOAD_SHIFT) +return value; + +return (value load_shift) SCHED_LOAD_SHIFT; it returns (2 15) 10 = 2 * 32 = 64, therefore __delta has to be larger than 64 so that the current process can be preempted. Suppose, curr executes for 1 tick, an timer interrupts comes. It executes about 1,000,000 (roughly speaking, since timer interrupts come 1000/second). Since we divided everything by 1,000,000, it becomes 1 in this discussion. After this execution, how much will curr increments its fair_key? It is weighted: 1/32. then how much time is needed for curr to build a 2 * 32 difference on fair_key, with every 1 ms it updates fair_key by 1/32 ?2 * 32 * 32 ! On the other hand, for a task has nice value 1, the amount work needed to preemption is 2 * 1 *1. If we have only 2 task running, p1 with nice value -10, p2 with nice value 0. p1 get cup share: (32 * 32) / (32 * 32 + 1 *1) p2 get cpu share: ( 1* 1) / (32 * 32 + 1 * 1) I do see a quadratic effect here. Did I missed anything? sorry to bother you again, I just want to help :-) Thanks a lot ! Ting - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] CFS scheduler, -v7
Hi, Ingo
This is the test case that I think worth discuss and it leads me to
find 2 things.
[...] but there are still some nice issues.
Try running 3 chew.c's, then renicing one to -10, starves others for
some seconds while switching prio-level. Now renice it back to 10, it
starves for up to 45sec.
ok - to make sure i understood you correctly: does this starvation only
occur right when you renice it (when switching prio levels), and it gets
rectified quickly once they get over a few reschedules?
The main problem of what Al Boldi saw might come from this piece of code
in sched_fair.c, which scales of fair_key difference needed to preempt the
current task:
+rescale_load(struct task_struct *p, u64 value)
+{
+int load_shift = p-load_shift;
+
+if (load_shift == SCHED_LOAD_SHIFT)
+return value;
+
+return (value load_shift) SCHED_LOAD_SHIFT;
+}
+
+static u64
+niced_granularity(struct rq *rq, struct task_struct *curr,
+ unsigned long granularity)
+{
+return rescale_load(curr, granularity);
+}
Here is the checking for pre-emption:
+static inline void
+__check_preempt_curr_fair(struct rq *rq, struct task_struct *p,
+ struct task_struct *curr, unsigned long granularity)
+{
+s64 __delta = curr-fair_key - p-fair_key;
+
+/*
+ * Take scheduling granularity into account - do not
+ * preempt the current task unless the best task has
+ * a larger than sched_granularity fairness advantage:
+ */
+if (__delta niced_granularity(rq, curr, granularity))
+resched_task(curr);
+}
This code actually now says, the difference of fair_key needed to preempt
the current task is amplified by a facto of its weigh (in Al Boldi's
example 32). However, the weighted task already advance its p-fair_key by
its weight, (also 32 here). The combination of them becomes quadratic!
Let's starting from three nice 0 tasks p1, p2, p3, at time t=0, with
niced_granularity set to be 5ms:
Originally each task executes 5 ms in turn:
5ms for p1, 5ms for p2, 5ms p3, 5ms for p1, 5ms for p2, 5ms for p3 ...
If somehow p3 is re-niced to -10 _right before_ the 16th ms, we run
into the worst case after p3 gets the cpu:
p1-fair_key = p2 -fair_key = 10, p3-fair_key = 5.
Now, in order for p3 to be preempted, it has to make its fair_key 5 *
32 larger than p1 and p2's fair_key. Furthermore, p3 now is higher weight,
push its fair_key to increase by 1 now needs 32ms,
thus p3 will stay one cpu for 5 * 32 *32ms, which is about 5 second!
Besides this quadratic effect, another minor issue amplified this a
little bit further: p-wait_runtime accumulated before. During renice it
is not adjusted to match the new nice value. The p-wait_runtime earned
using previous weight has to be paid off using the current weight. If
renice to larger weight you pay more than you need, otherwise you paid
less, which introduces unfairness.
Ingo, now, partially solved this problem by clearing p-wait_runtime
when a task is reniced, but the quadratic effect of scaling is still
there.
Thanks
Ting
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RELEASE] Lguest for 2.6.21
On Thu, May 03, 2007 at 12:43:48AM +1000, Rusty Russell wrote: Hi all, Lguest is a simple hypervisor which runs Linux under Linux, without needing VT hardware. Two people asked if I had a version of lguest which worked on other-than-bleeding-edge-mm kernels, so I did a backport of the latest version to 2.6.21. http://lguest.ozlabs.org/lguest-2.6.21-254.patch.gz See Documentation/lguest/lguest.txt for how to run, drivers/lguest/README for the draft code documentation journey. Your lguest readme is quite lacking in the area of how to configure a guest kernel as opposed to the host kernel. More hand-holding, please. Maybe it's obvious once I've actually applied the patch and run menuconfig, but I'm loathe to attempt anything that isn't a cake walk at my current loadavg, especially given the fits of blind rage trying to do anything nontrivial with Xen tends to provoke in me. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why ssse3?
PNI (Prescott New Instructions) was the original engineering code name. Unfortunately it was added too early before the marketing name was known and then it couldn't be changed anymore. ... and just to make things more fun, SSE4 is sometimes called Penryn New Instructions -- PNI all over again. - R. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[MCA] add integrated device bus matching
The MCA bus has a few integrated functions, which are effectively
virtual slots on the bus. The problem is that these special functions
don't have dedicated pos IDs, so we have to manufacture ids for them
outside the pos space ... and these ids can't be matched by the standard
matching function, so add a special registration that requests a list of
pos ids or a particular integrated function.
Signed-off-by: James Bottomley [EMAIL PROTECTED]
This is actually needed by the ibmmca.c driver update.
James
Index: BUILD-voyager/drivers/mca/mca-driver.c
===
--- BUILD-voyager.orig/drivers/mca/mca-driver.c 2007-05-03 08:52:36.0
-0500
+++ BUILD-voyager/drivers/mca/mca-driver.c 2007-05-03 08:54:57.0
-0500
@@ -36,12 +36,25 @@ int mca_register_driver(struct mca_drive
mca_drv-driver.bus = mca_bus_type;
if ((r = driver_register(mca_drv-driver)) 0)
return r;
+ mca_drv-integrated_id = 0;
}
return 0;
}
EXPORT_SYMBOL(mca_register_driver);
+int mca_register_driver_integrated(struct mca_driver *mca_driver,
+ int integrated_id)
+{
+ int r = mca_register_driver(mca_driver);
+
+ if (!r)
+ mca_driver-integrated_id = integrated_id;
+
+ return r;
+}
+EXPORT_SYMBOL(mca_register_driver_integrated);
+
void mca_unregister_driver(struct mca_driver *mca_drv)
{
if (MCA_bus)
Index: BUILD-voyager/include/linux/mca.h
===
--- BUILD-voyager.orig/include/linux/mca.h 2007-05-03 08:52:41.0
-0500
+++ BUILD-voyager/include/linux/mca.h 2007-05-03 08:58:45.0 -0500
@@ -94,6 +94,7 @@ struct mca_bus {
struct mca_driver {
const short *id_table;
void*driver_data;
+ int integrated_id;
struct device_driverdriver;
};
#define to_mca_driver(mdriver) container_of(mdriver, struct mca_driver, driver)
@@ -125,6 +126,7 @@ extern enum MCA_AdapterStatus mca_device
extern struct bus_type mca_bus_type;
extern int mca_register_driver(struct mca_driver *drv);
+extern int mca_register_driver_integrated(struct mca_driver *, int);
extern void mca_unregister_driver(struct mca_driver *drv);
/* WARNING: only called by the boot time device setup */
Index: BUILD-voyager/drivers/mca/mca-bus.c
===
--- BUILD-voyager.orig/drivers/mca/mca-bus.c2007-05-03 08:47:46.0
-0500
+++ BUILD-voyager/drivers/mca/mca-bus.c 2007-05-03 09:03:11.0 -0500
@@ -59,7 +59,14 @@ static int mca_bus_match (struct device
return 1;
}
}
-
+ /* If the integrated id is present, treat it as though it were an
+* additional id in the id_table (it can't be because by definition,
+* integrated id's overflow a short */
+ if (mca_drv-integrated_id mca_dev-pos_id ==
+ mca_drv-integrated_id) {
+ mca_dev-index = i;
+ return 1;
+ }
return 0;
}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
Original-Nachricht Datum: Thu, 03 May 2007 19:48:50 +0400 Von: Manu Abraham [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: [EMAIL PROTECTED], linux-kernel@vger.kernel.org, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical pointsabout ...) Uwe Bugla wrote: Hi Manu, But it would be an acceptable compromise FOR NOW, wouldn't it? The reason is i do not wish to make changes to it, till i can fix it. It is indeed hard to fix things that support a lot of devices, with different issues. There are enough of issues in there. You can look at all those frontend not found issues on the DVB ML. The people who make all these noise, do nothing but just play politics. Just do a search on the linux-dvb ML at gmane.org. You can easily find them. Waiting for your link meanwhile to download that hopeful project... http://thadathil.net:8000/cgi-bin/hgwebdir.cgi/cx878_41?ca=43abfe89c2c9;type=bz2 Sorry Manu, incorrect link! Why? If you download the thing as tar.bz2 you get a zero file down. However, if you download the thing as tar.gz you will succeed in getting it. I'll sit down this evening, try to make changes to imply it into the actual mercurial tree, produce necessary patches and give you a bug report as far as the compilation errors are concerned. I am really looking forward to see this fantastic thing finished It's worth it for a thousands of very good reasons, not only RAM optimization, but also stability and many many others... So gimme some time, and perhaps please supply a tar.bz2 version if you can, or fix the download error (zero file) if there is any other reason that I cannot see. OKIDOK so far? Uwe -- Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Oops on 2.6.18-1.2869.fc6 is this a bug?
Thanks. On 5/3/07, Michal Piotrowski [EMAIL PROTECTED] wrote: Hi Gary, On 03/05/07, Gary Martin [EMAIL PROTECTED] wrote: I have a system running Fedora Core 6 on a Dell PE4400 that crashed and became unresponsive, I captured the following kernel oops in /var/log/messages: Apr 30 08:52:11 hostname kernel: list_del corruption. prev-next should be d5507478, but was 008f Apr 30 08:52:11 hostname kernel: [ cut here ] Apr 30 08:52:11 hostname kernel: kernel BUG at lib/list_debug.c:65! Apr 30 08:52:11 hostname kernel: invalid opcode: [#1] Apr 30 08:52:11 hostname kernel: SMP Apr 30 08:52:11 hostname kernel: last sysfs file: /devices/pci:00/:00:04.0/irq Apr 30 08:52:11 hostname kernel: Modules linked in: ipv6 autofs4 dm_multipath video sbs i2c_ec button battery ac lp i2c_piix4 sr_mod i2c_core st cdrom e100 sg floppy pcspkr mii parport_pc tg3 parport serio_raw dm_snapshot dm_zero dm_mirror dm_mod aic7xxx scsi_transport_spi aacraid sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd Apr 30 08:52:11 hostname kernel: CPU:0 Apr 30 08:52:11 hostname kernel: EIP:0060:[c04e5913]Not tainted VLI Apr 30 08:52:11 hostname kernel: EFLAGS: 00010296 (2.6.18-1.2869.fc6 #1) Apr 30 08:52:11 hostname kernel: EIP is at list_del+0x23/0x6c Apr 30 08:52:11 hostname kernel: eax: 0048 ebx: d5507478 ecx: c0671c50 edx: 0096 Apr 30 08:52:11 hostname kernel: esi: d5507428 edi: f7d98e40 ebp: 0282 esp: f7feff38 Apr 30 08:52:11 hostname kernel: ds: 007b es: 007b ss: 0068 Apr 30 08:52:11 hostname kernel: Process events/0 (pid: 8, ti=f7fef000 task=c2ec05c0 task.ti=f7fef000) Apr 30 08:52:11 hostname kernel: Stack: c063707b d5507478 008f d5507420 c04b7ae6 d5507420 d5507428 f7d98e40 Apr 30 08:52:11 hostname kernel:c04b772c c067ece0 c067ece4 c042fa34 0246 f7d98e40 f7d98e60 c04b7675 Apr 30 08:52:11 hostname kernel: f7d98e60 f7d98e40 f7d98e58 c043032c 0001 Apr 30 08:52:11 hostname kernel: Call Trace: Apr 30 08:52:11 hostname kernel: [c04b7ae6] keyring_destroy+0x28/0x65 Apr 30 08:52:11 hostname kernel: [c04b772c] key_cleanup+0xb7/0xd0 Apr 30 08:52:11 hostname kernel: [c042fa34] run_workqueue+0x83/0xc5 Apr 30 08:52:11 hostname kernel: [c043032c] worker_thread+0xd9/0x10d Apr 30 08:52:11 hostname kernel: [c04327f3] kthread+0xc0/0xed Apr 30 08:52:11 hostname kernel: [c0405447] kernel_thread_helper+0x7/0x10 Apr 30 08:52:11 hostname kernel: DWARF2 unwinder stuck at kernel_thread_helper+0x7/0x10 Apr 30 08:52:11 hostname kernel: Leftover inexact backtrace: Apr 30 08:52:11 hostname kernel: === Apr 30 08:52:11 hostname kernel: Code: 00 00 89 c3 eb e8 90 90 53 89 c3 83 ec 0c 8b 40 04 8b 00 39 d8 74 1c 89 5c 24 04 89 44 24 08 c7 04 24 7b 70 63 c0 e8 df bc f3 ff 0f 0b 41 00 b8 70 63 c0 8b 03 8b 40 04 39 d8 74 1c 89 5c 24 04 Apr 30 08:52:11 hostname kernel: EIP: [c04e5913] list_del+0x23/0x6c SS:ESP 0068:f7feff38 Apr 30 08:52:20 hostname kernel: 3BUG: soft lockup detected on CPU#0! Apr 30 08:52:20 hostname kernel: [c0405876] dump_trace+0x69/0x1af Apr 30 08:52:20 hostname kernel: [c04059d4] show_trace_log_lvl+0x18/0x2c Apr 30 08:52:20 hostname kernel: [c0405f83] show_trace+0xf/0x11 Apr 30 08:52:20 hostname kernel: [c0406080] dump_stack+0x15/0x17 Apr 30 08:52:20 hostname kernel: [c04498a9] softlockup_tick+0xad/0xc4 Apr 30 08:52:20 hostname kernel: [c042a39a] update_process_times+0x39/0x5c Apr 30 08:52:20 hostname kernel: [c04148c5] smp_apic_timer_interrupt+0x5b/0x62 Apr 30 08:52:20 hostname kernel: [c040512f] apic_timer_interrupt+0x1f/0x30 Apr 30 08:52:20 hostname kernel: DWARF2 unwinder stuck at apic_timer_interrupt+0x1f/0x30 Apr 30 08:52:20 hostname kernel: Leftover inexact backtrace: Apr 30 08:52:20 hostname kernel: [c0609f2f] __write_lock_failed+0xf/0x20 Apr 30 08:52:20 hostname kernel: [c04e57f9] _raw_write_lock+0x5d/0x74 Apr 30 08:52:20 hostname kernel: [c04b7ffd] keyring_publish_name+0x2c/0x6d Apr 30 08:52:20 hostname kernel: [c04b804c] keyring_instantiate+0xe/0x13 Apr 30 08:52:20 hostname kernel: [c04b6fa4] __key_instantiate_and_link+0x2f/0xa8 Apr 30 08:52:20 hostname kernel: [c04b820d] keyring_alloc+0x53/0x6a Apr 30 08:52:20 hostname kernel: [c04b9888] alloc_uid_keyring+0x4c/0xb2 Apr 30 08:52:20 hostname kernel: [c042a80d] alloc_uid+0x95/0x13c Apr 30 08:52:20 hostname kernel: [c042d66f] set_user+0xb/0x8e Apr 30 08:52:20 hostname kernel: [c042ef3a] sys_setresuid+0x111/0x1dd Apr 30 08:52:20 hostname kernel: [c0404027] syscall_call+0x7/0xb Apr 30 08:52:20 hostname kernel: === Is this a bug? Yes, it is. Please let me know if I can provide any other information to determine the cause of this crash. Thanks. You need to upgrade the kernel yum upgrade kernel.i686 If the problem still appears, fill bug report in RedHat bugzilla https://bugzilla.redhat.com/bugzilla/index.cgi
Re: swap-prefetch: 2.6.22 -mm merge plans
Hi, On 03/05/07, Ingo Molnar [EMAIL PROTECTED] wrote: * Andrew Morton [EMAIL PROTECTED] wrote: - If replying, please be sure to cc the appropriate individuals. Please also consider rewriting the Subject: to something appropriate. i'm wondering about swap-prefetch: mm-implement-swap-prefetching.patch swap-prefetch-avoid-repeating-entry.patch add-__gfp_movable-for-callers-to-flag-allocations-from-high-memory-that-may-be-migrated-swap-prefetch.patch The swap-prefetch feature is relatively compact: 10 files changed, 745 insertions(+), 1 deletion(-) it is contained mostly to itself: mm/swap_prefetch.c| 581 i've reviewed it once again and in the !CONFIG_SWAP_PREFETCH case it's a clear NOP, while in the CONFIG_SWAP_PREFETCH=y case all the feedback i've seen so far was positive. Time to have this upstream and time for a desktop-oriented distro to pick it up. I think this has been held back way too long. It's .config selectable and it is as ready for integration as it ever is going to be. So it's a win/win scenario. I'm using SWAP_PREFETCH since 2.6.17-mm1 (I don't have earlier configs) http://www.stardust.webpages.pl/files/tbf/euridica/2.6.17-mm1/mm-config and I don't recall _any_ problems. It's very stable for me. Acked-by: Ingo Molnar [EMAIL PROTECTED] Ingo Regards, Michal -- Michal K. K. Piotrowski Kernel Monkeys (http://kernel.wikidot.com/start) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
Uwe Bugla wrote: Original-Nachricht Datum: Thu, 03 May 2007 19:48:50 +0400 Von: Manu Abraham [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: [EMAIL PROTECTED], linux-kernel@vger.kernel.org, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...) Uwe Bugla wrote: Hi Manu, But it would be an acceptable compromise FOR NOW, wouldn't it? The reason is i do not wish to make changes to it, till i can fix it. It is indeed hard to fix things that support a lot of devices, with different issues. There are enough of issues in there. You can look at all those frontend not found issues on the DVB ML. The people who make all these noise, do nothing but just play politics. Just do a search on the linux-dvb ML at gmane.org. You can easily find them. Waiting for your link meanwhile to download that hopeful project... http://thadathil.net:8000/cgi-bin/hgwebdir.cgi/cx878_41?ca=43abfe89c2c9;type=bz2 Sorry Manu, incorrect link! Why? If you download the thing as tar.bz2 you get a zero file down. I think could be a bug in hgweb probably. However, if you download the thing as tar.gz you will succeed in getting it. Ok. The gzip archive should be as good as the bzip archive, just that it is slightly larger. I'll sit down this evening, try to make changes to imply it into the actual mercurial tree, produce necessary patches and give you a bug report as far as the compilation errors are concerned. I am really looking forward to see this fantastic thing finished It's worth it for a thousands of very good reasons, not only RAM optimization, but also stability and many many others... So gimme some time, and perhaps please supply a tar.bz2 version if you can, or fix the download error (zero file) if there is any other reason that I cannot see. Let me see why hgweb gives a zero length archive - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
Markus Rechberger wrote: Manu, to me it looks like your attitude is not acceptable here, I sent several mails already which you just use to ignore. You very well know the reason why i am ignoring your mails. You just tend to flame people for nothing. I tend to ignore the flamers. If you don't change that attitude immediatelly I'd really wish to get you banned of this community until you're open for discussions. http://www.mail-archive.com/linux-dvb%40linuxtv.org/msg22943.html there's a bugreport and you fully ignore it, and you blame it on the politicians here, telling me that there are mails out there somewhere shows that you're not interested in getting forward. That bug report very well proves my point. I'm waiting for your response here. Markus Waiting for your link meanwhile to download that hopeful project... http://thadathil.net:8000/cgi-bin/hgwebdir.cgi/cx878_41?ca=43abfe89c2c9;type=bz2 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] lib/hexdump
On Thu, 3 May 2007 09:01:31 +0200 (MEST) Jan Engelhardt wrote: On May 2 2007 15:35, Randy Dunlap wrote: Add hex_dumper() to lib/hexdump.c and linux/kernel.h. Right - we've got the second user already, namely the PANIC/OOPS code print. (The last line, aka bytes at EIP under Windows.) Jan 6 14:40:14 deekin kernel: Call Trace: Jan 6 14:40:14 deekin kernel: [c02060b3] is_complete+0x2c3/0x310 Jan 6 14:40:14 deekin kernel: [c02037c0] run+0x30/0x40 Jan 6 14:40:14 deekin kernel: [c0125b6d] worker_thread+0x1bd/0x2b0 Jan 6 14:40:14 deekin kernel: [c0203790] run+0x0/0x40 Jan 6 14:40:14 deekin kernel: [c0113b10] default_wake_function+0x0/0x20 Jan 6 14:40:14 deekin kernel: [c0108fd6] ret_from_fork+0x6/0x20 Jan 6 14:40:14 deekin kernel: [c0113b10] default_wake_function+0x0/0x20 Jan 6 14:40:14 deekin kernel: [c01259b0] worker_thread+0x0/0x2b0 Jan 6 14:40:14 deekin kernel: [c0107175] kernel_thread_helper+0x5/0x10 Jan 6 14:40:14 deekin kernel: Code: 89 02 8b 41 04 8b 40 3c 8b 53 04 89 42 3c 8b 41 04 plus intel wireless drivers, 2 MTD/flash drivers, and search kernel tree for hexdump (function name that I wanted to use, but it's already used), hex_dump, dump_hex, dump_mem, etc. Andrew says that he knew of 9 hex dumpers in-tree. :) --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** (sorry about email address change; other address not working for some reason) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: swap-prefetch: 2.6.22 -mm merge plans
On 03/05/07, Michal Piotrowski [EMAIL PROTECTED] wrote: Hi, On 03/05/07, Ingo Molnar [EMAIL PROTECTED] wrote: * Andrew Morton [EMAIL PROTECTED] wrote: - If replying, please be sure to cc the appropriate individuals. Please also consider rewriting the Subject: to something appropriate. i'm wondering about swap-prefetch: mm-implement-swap-prefetching.patch swap-prefetch-avoid-repeating-entry.patch add-__gfp_movable-for-callers-to-flag-allocations-from-high-memory-that-may-be-migrated-swap-prefetch.patch The swap-prefetch feature is relatively compact: 10 files changed, 745 insertions(+), 1 deletion(-) it is contained mostly to itself: mm/swap_prefetch.c| 581 i've reviewed it once again and in the !CONFIG_SWAP_PREFETCH case it's a clear NOP, while in the CONFIG_SWAP_PREFETCH=y case all the feedback i've seen so far was positive. Time to have this upstream and time for a desktop-oriented distro to pick it up. I think this has been held back way too long. It's .config selectable and it is as ready for integration as it ever is going to be. So it's a win/win scenario. I'm using SWAP_PREFETCH since 2.6.17-mm1 (I don't have earlier configs) since 2.6.14-mm2 :) http://lkml.org/lkml/2005/11/11/260 Regards, Michal -- Michal K. K. Piotrowski Kernel Monkeys (http://kernel.wikidot.com/start) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Per-CPU data as a structure
Julio M. Merino Vidal [EMAIL PROTECTED] writes: Similarly, and if I understood it correctly, the PDA (Per-processor Data Area) also aims to do the above, but at the moment it only contains some fields and is not defined in all platforms. There are still a lot of usages of the percpu functionality (such as, e.g., in kernel/sched.c). PDA is an earlier version of percpu; it still can be more efficiently accessed so it is kept for some low level code. As far as I can tell, the advantage of percpu is that you can define new fields anywhere in the code and independently from the rest of the system. - Independent maintenance as you noted - Fast access and relatively compact code - Avoids false sharing by keeping cache lines of different CPUs separate - Doesn't waste a lot of memory in padding like NR_CPUs arrays usually need to to avoid the previous point. Any replacement that doesn't have these properties too will probably be not useful. -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: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage
Eric W. Biederman wrote: Yes. I guess in this context, I am generally for building the ELF headers by hand instead of with a linker script, because then we know exactly what is happening and can ensure everything is just so. Yes, it seems easiest - particularly given how flaky binutils can get when you really try to control its ELF generation. Sorry, for not being clear I have been expecting to do this for years, it is one of the reasons I keep coming back to putting an ELF header on the bzImage. OK. It seems obvious, but I just wanted to make sure ;) In the Xen case, its obviously the domain builder who creates the mappings, and we can easily implement p != v mappings. But when booting native, presumably paging is off at this stage, and only identity maps can be implemented. I guess the rough rule is that if paging is enabled on entry, the kernel should expect all the bzImage mappings to be in place, but if paging is off, well, the question is moot. Right. Except that there is a bit of a catch 22 in the para-virtualized environments of setting up the page tables, I'm not at all certain what the gain of setting up p != v mappings are. Well, that's more or less it. If the decompressor ends up jumping to startup_32, and that immediately goes into xen_start_kernel(), then we're still running on the initial bzImage p=v pagetables. At the moment, when the domain builder maps the kernel's vmlinux to the vaddrs in its Phdrs, so there's no need to do any more boot-time pagetable manipulation. If we come out of bzImage with only identity mappings, then obviously the Xen case will need to do the same pagetable setup as the native case - which is good so long as we can work out how to share the code to do so. For i386, it looks like this will be tricky because at this point: * we're not running at the linked address, so C code will be tricky and non-standard * we need to deal with multiple hypervisors and their constraints on what can be in a pagetable * we could be running with no paging, or paging in either non-PAE or PAE modes Writing some code which can deal with all of those at once will be an interesting exercise. Part of what I find compelling about this is our initial page tables for linux have always had more going on than the virtual addresses just being at a constant offset from of the physical addresses, so the actions of the current domain builders have me concerned that they may be violating some early linux booting assumptions and are currently just getting lucky. Moving the page table setup code into the kernel removes that dependency from the domain builders. The nice thing about having the domain builder create the pagetables is that it turns it from a tricky bootstrap problem into a relatively easy job. The main thing is that the domain builder can create a scaffolding pagetable which is enough to get everything started. Once you have that in place, its pretty easy to update it to set precisely the right bits in the ptes, etc. It also means that the path for Xen vs native will be more similar, because the bzImage code won't need to deal with pagetable setup at all: for native it won't matter, and for Xen it has already been done. It only matters once we hit the 32-bit kernel-proper code, and we diverge at that point anyway. J - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
Original-Nachricht Datum: Thu, 3 May 2007 17:59:18 +0200 Von: Markus Rechberger [EMAIL PROTECTED] An: Manu Abraham [EMAIL PROTECTED] CC: Uwe Bugla [EMAIL PROTECTED], [EMAIL PROTECTED], linux-kernel@vger.kernel.org, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...) On 5/3/07, Manu Abraham [EMAIL PROTECTED] wrote: Uwe Bugla wrote: Hi Manu, But it would be an acceptable compromise FOR NOW, wouldn't it? The reason is i do not wish to make changes to it, till i can fix it. It is indeed hard to fix things that support a lot of devices, with different issues. There are enough of issues in there. You can look at all those frontend not found issues on the DVB ML. The people who make all these noise, do nothing but just play politics. Just do a search on the linux-dvb ML at gmane.org. You can easily find them. Manu, to me it looks like your attitude is not acceptable here, I sent several mails already which you just use to ignore. If you don't change that attitude immediatelly I'd really wish to get you banned of this community until you're open for discussions. http://www.mail-archive.com/linux-dvb%40linuxtv.org/msg22943.html there's a bugreport and you fully ignore it, and you blame it on the politicians here, telling me that there are mails out there somewhere shows that you're not interested in getting forward. I'm waiting for your response here. Markus Hey Markus, fine chap: Please cool down! I just downloaded this cx878 thing which will beat a couple of flies with one attack once it is finished. It will be more stable than every preceding driver, it will revolutionize RAM usage extraordinarily, and it will solve all outstanding technical problems involved in the current DST driver concept, if I did understand Manu right, which is different sometimes, but, as it seems, not impossible. So he just changed his priorities, and if this thing is finished we all will be winning a lot in the end I guess... So please at least try to get yourself involved into that project, even if there are outstanding human drawbacks - its hard with him, I know, but it is not impossible at all. And the cx878 project is worth to engage oneself in for a thousands of very good reasons - just believe me, as I have already done a lot of testing work on it. It's fine, and it will revolutionize the whole bt8xx driver concept. So if there are many many people helping to finish it, that will be the best thing ever seen... And as far Manu is concerned: he is a primadonna, as I am. Primadonnas are real extraordinary people, you know. So please do not beat him or treat him like this. Yours sincerely Uwe Peace, brother! Waiting for your link meanwhile to download that hopeful project... http://thadathil.net:8000/cgi-bin/hgwebdir.cgi/cx878_41?ca=43abfe89c2c9;type=bz2 -- Markus Rechberger -- Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22 -mm merge plans: slub
On Thu, 3 May 2007, William Lee Irwin III wrote: I've seen this crash in flush_old_exec() before. ISTR it being due to slub vs. pagetable alignment or something on that order. From from other discussion regarding SLAB: It may be necessary for powerpc to set the default alignment to 8 bytes on 32 bit powerpc because it requires that alignemnt for 64 bit value. SLUB will *not* disable debugging like SLAB if you do that. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
Manu Abraham wrote: Uwe Bugla wrote: If you download the thing as tar.bz2 you get a zero file down. I think could be a bug in hgweb probably. [snip] Let me see why hgweb gives a zero length archive Manu, We reported this bug to the selenic guys quite a long time ago... You should inherit the fix if you upgrade mercurial on your server. Regards, Mike - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git pull] New firewire stack
On Thu, May 03, 2007 at 03:30:36PM +0200, Stefan Richter wrote: Olaf Hering wrote: On Thu, May 03, Stefan Richter wrote: ieee1394-old Noone will seriously ship two firewire stacks, so that cant be the issue (for distributors). I don't actively watch distributions, but I believe there are frequently alternative drivers shipped. How much sense that makes for FireWire is another question. Once there is a way to easily switch between kernel releases, I'm ok with whatever module names you pick. It may actually be easier to let problem reporters (who cannot or don't want to compile kernels) compare between different kernel releases, rather than to ask them to compare between different stacks on top of the same kernel. Still, it potentially reduces the testers base. Adrian wrote: | An advantage of changing the names is that they are now prefixed. Is the opportunity to clean up module names compelling enough, vs. (the wish for) minimized trouble with scripts which refer to module names? ... How big is the trouble actually? We have never and cannot guarantee stable module names (think of e.g. PATA, e100 or sky2/skge), so changed names are always possible when upgrading kernels. Module aliases can solve many issues. And sometimes it might even be an advantage that different drivers for the same hardware get different names (consider especially PATA). Not changing the module names also has the problem that the old code must be removed from the kernel tree before the new one can be added since two different modules with the same names could easily cause trouble - consider a user first compiling and installing the one modular, and then compiling and installing the other one modular (e.g. due to problems with the one he tried first). Which module will now be loaded by modprobe? Stefan Richter cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
Michael Krufky wrote: Manu Abraham wrote: Uwe Bugla wrote: If you download the thing as tar.bz2 you get a zero file down. I think could be a bug in hgweb probably. [snip] Let me see why hgweb gives a zero length archive Manu, We reported this bug to the selenic guys quite a long time ago... You should inherit the fix if you upgrade mercurial on your server. Cool. Thanks. I think it is a newer version .. [EMAIL PROTECTED] ~]$ hg --version Mercurial Distributed SCM (version 0.9) Copyright (C) 2005 Matt Mackall [EMAIL PROTECTED] This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. You have an account on that machine. Would you like to take a look ? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22 -mm merge plans: slub
H...There are a gazillion configs to choose from. It works fine with cell_defconfig. If I switch to 2 processors I can enable SLUB if I switch to 4 I cannot. I saw some other config weirdness like being unable to set SMP if SLOB is enabled with some configs. This should not work and does not work but the menus are then vanishing and one can still configure lots of processors while not having enabled SMP. It works as far as I can tell... The rest is arch weirdness. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22 -mm merge plans -- vm bugfixes
On Thu, 03 May 2007 11:32:23 +1000 Nick Piggin [EMAIL PROTECTED] wrote:
void fastcall unlock_page(struct page *page)
{
+ VM_BUG_ON(!PageLocked(page));
smp_mb__before_clear_bit();
- if (!TestClearPageLocked(page))
- BUG();
- smp_mb__after_clear_bit();
- wake_up_page(page, PG_locked);
+ ClearPageLocked(page);
+ if (unlikely(test_bit(PG_waiters, page-flags))) {
+ clear_bit(PG_waiters, page-flags);
+ wake_up_page(page, PG_locked);
+ }
}
Why is that significantly faster than plain old wake_up_page(), which
tests waitqueue_active()?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Back to the future.
On May 03, 2007, at 11:10:47, Pavel Machek wrote: How mature is freezing filesystems -- will it work on at least ext2/3 and vfat? I'm pretty sure it works on ext2/3 and xfs and possibly others, I don't know either way about VFAT though. Essentially the freeze part involves telling the filesystem to sync all data, flush the journal, and mark the filesystem clean. The intent under dm/LVM was to allow you to make snapshots without having to fsck the just- created snapshot before you mounted it. What happens if you try to boot and filesystems are frozen from previous run? If you're just doing a fresh boot then the filesystem is already clean due to the dm freeze and so it mounts up normally. All you need to do then is have a little startup script which purges the saved image before you fsck or remount things read-write since either case means the image is no longer safe to resume. If the kernel is later modified to purge all filesystem data (dcache/ pagecache) during snapshot and effectively remount and reopen all the files by path during restore then you could remove that requirement. You'd just need to make sure that the restore-from-disk scripts did an fsck or journal-restore before reloading the old kernel data. Cheers, Kyle Moffett - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/36] Use menuconfig objects II - hwmon
Hi Jan, On Mon, 30 Apr 2007 13:28:29 +0200 (MEST), Jan Engelhardt wrote: Change Kconfig objects from menu, config into menuconfig so that the user can disable the whole feature without having to enter the menu first. Signed-off-by: Jan Engelhardt [EMAIL PROTECTED] --- drivers/hwmon/Kconfig | 109 -- 1 file changed, 53 insertions(+), 56 deletions(-) Applied, thanks. -- Jean Delvare - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bechmarking kernel code
On 5/3/07, kernel coder [EMAIL PROTECTED] wrote: I'm profiling some part of kernel code.Mine profiling mechanism is based on rdtsc instruction. Why dont you use oprofile? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 04/33] m68k: Atari keyboard and mouse support.
+static unsigned char rep_scancode;
+static struct timer_list atakeyb_rep_timer = {
+ .function = atakeyb_rep,
+};
Is there a problem with repeat implementation in input core that
requres custom-made repeater here?
Apparently not - the homebrew repeater has not been active pretty much
since I started to work on Atari in 2.6... time to kill that code.
+
+ // handle_scancode(scancode, !break_flag);
The code looks a bit dirty (old code commented out, C++ style comments).
You got that right.
+
+
+int atari_kbdrate(struct kbd_repeat *k)
+{
+ if (k-delay 0) {
+ /* convert from msec to jiffies */
+ key_repeat_delay = (k-delay * HZ + 500) / 1000;
If this is really needed - msecs_to_jiffies().
That has to go as well (together with the repeater).
+config KEYBOARD_ATARI
+ tristate Atari keyboard
+ depends on ATARI
+ select ATARI_KBD_CORE
+ help
+ Say Y here if you are running Linux on any Atari and have a
keyboard
+ attached.
+
+ To compile this driver as a module, choose M here: the
+ module will be called atakbd.
Can we spell it out: atarikbd or atari_kbd?
Could do that, yes. Christoph suggested to fold everythig into atakeyb.c
so modularization would go away here.
+
+ if (!(atakbd_dev = input_allocate_device()))
+ return -ENOMEM;
+
+ // need to init core driver if not already done so
+ if (atari_keyb_init())
Memory leak
How so? If the core has been initialized already this will just return ...
+ for (i = 1; i 0x72; i++) {
+ atakbd_keycode[i] = i;
+ set_bit(atakbd_keycode[i], atakbd_dev-keybit);
It looks like this driver is not using standard input event codes. If
Roman does not want to adjust keymaps on Amiga and Atari that should
be handled in legacy keyboard driver (drivers/char/keyboard.c). As it
is programs using /dev/input/eventX have no chance of working.
The translation map should not have been overwritten like above, is that
what you mean?
My original patch didn't have that bit; scancodes were translated to
input keycodes using atakbd_keycode[scancode] instead. I'll have that
reverted...
+ }
+
+ input_register_device(atakbd_dev);
Error handling.
Oops.
+
+static int mouse_threshold[2] = {2,2};
+
+#ifdef __MODULE__
+MODULE_PARM(mouse_threshold, 2i);
MODULE_PARM is so 20th century...
Never tested, sorry.
+
+static int atamouse_open(struct input_dev *dev)
+{
+ if (atamouse_used++)
+ return 0;
No need to count, input core takes care of this.
OK; I'll delete this.
+
+ printk(KERN_INFO input: %s at keyboard ACIA\n,
atamouse_dev-name);
Input core already logs every input device registered, do we need to
repeat it in the driver?
Not really ... I'll merge atakeyb.c, atakbd.c and atamouse.c and send a
new patch to Geert.
Thanks,
Michael
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: console font limits
On Tue, May 01, 2007 at 12:09:46AM -0400, Albert Cahalan wrote:
I'm having problems with a font I just created. It's a rather big one,
intended for a framebuffer console in UTF-8 mode. The strace program
reports that /bin/setfont fails on a KDFONTOP ioctl with EINVAL.
In reading the kernel code, I find this:
vt.c:static int con_font_set(struct vc_data *vc, struct console_font_op *op)
vt.c-{
vt.c- struct console_font font;
vt.c- int rc = -EINVAL;
vt.c- int size;
vt.c-
vt.c- if (vc-vc_mode != KD_TEXT)
vt.c- return -EINVAL;
vt.c- if (!op-data)
vt.c- return -EINVAL;
vt.c- if (op-charcount 512)
vt.c- return -EINVAL;
Ouch. Why is the old VGA limit being applied to the framebuffer console?
This is common code, for both framebuffer and vga.
If you want you can push this check into the individual foo-con_font_set
routines. Have some check here that the total size is not ridiculous.
(There is a loop
for (i = 0; i op-charcount; i++)
that must have some bounded length. Easiest is to test against the total
font size some lines later:
size = (op-width+7)/8 * 32 * op-charcount;
if (size max_font_size)
return -ENOSPC;
E.g., move this up so that it becomes
if (op-width = 0 || op-width 32)
return -EINVAL;
if (op-charcount max_font_size / 32 / ((op-width+7)/8))
return -ENOSPC;
.)
I nearly hit the 32-pixel height limit as well, yet another relic from
the VGA hardware. I also nearly hit the 64 KB font size limit.
Of course you can make everything more general if you want to and need to.
Some of this code was written when average machines had 4 or 8 MB of memory.
On the other hand, for VGA some of the limits are hardware restrictions.
Currently I'm doing a 15x30 font with 870 glyphs to represent 978
different Unicode code points. This is for a 200 DPI display with
an anti-aliasing filter, so fonts need to be big. I'm considering 15x36
so that I'll have more room for double-accented letters, but clearly
the kernel would block that too.
In case you generalize stuff in such a way that also the kbd package
needs an update, write.
BTW, the PSF font format documentation seems to suggest that
there is a way to make the kernel handle combining accents:
http://www.win.tue.nl/~aeb/linux/kbd/font-formats-1.html
Does anybody know if that really works? I could sure use that.
Well, the PSF font format documentation shows that there is a way
to document in a font that some font position represents a
sequence of Unicode values. Whether the kernel is able to
use such information depends on the kernel version - maybe vanilla
kernels cannot.
[Very long ago I wrote Yiddish songs on the console, German on the left,
Yiddish on the right, and made a bidirectional console for this purpose.
Long ago I wrote Tibetan on the console and added enough input- and
output stuff to make that work. Only a small part of this has ended up
in the vanilla kernel. Adding features to the console is not a popular idea.]
Get the kbd package and read kdmapop.c for the docs on the kbd ioctls.
Tell me if these docs are outdated. I read
/*
* Linux pre-0.96 defined GIO_SCRNMAP, PIO_SCRNMAP:
typedef char scrnmap_t;
#define E_TABSZ 256
#define GIO_SCRNMAP 0x4B40
#define PIO_SCRNMAP 0x4B41
* and Linux 0.99.14y first implemented them.
* Usage:
scrnmap_t map[E_TABSZ];
ioctl(fd,GIO_SCRNMAP,map);
ioctl(fd,PIO_SCRNMAP,map);
* to read or write the kernel translation table that is
* applied to user application output before displaying.
*
* Before 1.3.1, the character set was completely undetermined,
* and if the font was in an order different from the character
* set in use, the user screen map was used to map application
* codes to font indices. (To be more precise: there were four
* translation tables, and this ioctl would get/set the fourth
* table, while the other three tables are built-in and constant.)
*/
/*
* Linux 1.3.1 introduces GIO_UNISCRNMAP, PIO_UNISCRNMAP:
#define GIO_UNISCRNMAP 0x4B69
#define PIO_UNISCRNMAP 0x4B6A
* Usage:
unsigned short umap[E_TABSZ];
ioctl(fd,GIO_UNISCRNMAP,umap);
ioctl(fd,PIO_UNISCRNMAP,umap);
* to read or write the kernel translation table that is
* applied to user application output before displaying.
* (When the console is not in utf8 mode.)
*
* The idea is that the umap values are 16-bit unicode (ucs2)
* values, and that the fonts will have an index giving the
* unicode value for each glyph, so that the kernel can match up
* application codes to font positions.
#define UNI_DIRECT_BASE 0xF000
#define UNI_DIRECT_MASK 0x01FF
* For compatibility, and for fonts without table, the unicode
* values 0xF000+n, 0 = n = 0x01FF, acts as direct font indices.
* In the new scheme, the old PIO_SCRNMAP fills the kernel umap
* table
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
On 5/3/07, Manu Abraham [EMAIL PROTECTED] wrote: Markus Rechberger wrote: Manu, to me it looks like your attitude is not acceptable here, I sent several mails already which you just use to ignore. You very well know the reason why i am ignoring your mails. You just tend to flame people for nothing. I tend to ignore the flamers. You should stop to rely on the history, since such a flame needs at least 2 parties and back then you were also involved. There's nothing else to say about that. If you don't change that attitude immediatelly I'd really wish to get you banned of this community until you're open for discussions. http://www.mail-archive.com/linux-dvb%40linuxtv.org/msg22943.html there's a bugreport and you fully ignore it, and you blame it on the politicians here, telling me that there are mails out there somewhere shows that you're not interested in getting forward. That bug report very well proves my point. Well it would be nice if you could answer the question in that mail then, I don't see any reason why you shouldn't answer it. It's just a guess, but it seems like that you had a problem with other developers at that part and it seems like it didn't get to an end (probably because both parties didn't agree with each other) Markus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22 -mm merge plans
Here is the reworked patch, except a comment :
* Christoph Hellwig ([EMAIL PROTECTED]) wrote:
+void blk_probe_disconnect(void)
+{
+ uint8_t i;
+
+ for (i = 0; i NUM_PROBES; i++) {
+ marker_remove_probe(probe_array[i].name);
+ }
+ synchronize_sched();/* Wait for probes to finish */
kprobes does this kind of synchronization internally, so the marker
wrapper should probabl aswell.
The problem appears on heavily loaded systems. Doing 50
synchronize_sched() calls in a row can take up to a few seconds on a
4-way machine. This is why I prefer to do it in the module to which
the callbacks belong.
Here is the reviewed patch. It depends on a newer version of markers
I'll send to Andrew soon.
Signed-off-by: Mathieu Desnoyers [EMAIL PROTECTED]
Index: linux-2.6-lttng/block/elevator.c
===
--- linux-2.6-lttng.orig/block/elevator.c 2007-05-03 12:27:12.0
-0400
+++ linux-2.6-lttng/block/elevator.c2007-05-03 12:54:58.0 -0400
@@ -32,7 +32,7 @@
#include linux/init.h
#include linux/compiler.h
#include linux/delay.h
-#include linux/blktrace_api.h
+#include linux/marker.h
#include linux/hash.h
#include asm/uaccess.h
@@ -571,7 +571,7 @@
unsigned ordseq;
int unplug_it = 1;
- blk_add_trace_rq(q, rq, BLK_TA_INSERT);
+ trace_mark(blk_request_insert, %p %p, q, rq);
rq-q = q;
@@ -757,7 +757,7 @@
* not be passed by new incoming requests
*/
rq-cmd_flags |= REQ_STARTED;
- blk_add_trace_rq(q, rq, BLK_TA_ISSUE);
+ trace_mark(blk_request_issue, %p %p, q, rq);
}
if (!q-boundary_rq || q-boundary_rq == rq) {
Index: linux-2.6-lttng/block/ll_rw_blk.c
===
--- linux-2.6-lttng.orig/block/ll_rw_blk.c 2007-05-03 12:27:12.0
-0400
+++ linux-2.6-lttng/block/ll_rw_blk.c 2007-05-03 12:54:58.0 -0400
@@ -28,6 +28,7 @@
#include linux/task_io_accounting_ops.h
#include linux/interrupt.h
#include linux/cpu.h
+#include linux/marker.h
#include linux/blktrace_api.h
#include linux/fault-inject.h
@@ -1551,7 +1552,7 @@
if (!test_and_set_bit(QUEUE_FLAG_PLUGGED, q-queue_flags)) {
mod_timer(q-unplug_timer, jiffies + q-unplug_delay);
- blk_add_trace_generic(q, NULL, 0, BLK_TA_PLUG);
+ trace_mark(blk_plug_device, %p %p %d, q, NULL, 0);
}
}
@@ -1617,7 +1618,7 @@
* devices don't necessarily have an -unplug_fn defined
*/
if (q-unplug_fn) {
- blk_add_trace_pdu_int(q, BLK_TA_UNPLUG_IO, NULL,
+ trace_mark(blk_pdu_unplug_io, %p %p %d, q, NULL,
q-rq.count[READ] + q-rq.count[WRITE]);
q-unplug_fn(q);
@@ -1628,7 +1629,7 @@
{
request_queue_t *q = container_of(work, request_queue_t, unplug_work);
- blk_add_trace_pdu_int(q, BLK_TA_UNPLUG_IO, NULL,
+ trace_mark(blk_pdu_unplug_io, %p %p %d, q, NULL,
q-rq.count[READ] + q-rq.count[WRITE]);
q-unplug_fn(q);
@@ -1638,7 +1639,7 @@
{
request_queue_t *q = (request_queue_t *)data;
- blk_add_trace_pdu_int(q, BLK_TA_UNPLUG_TIMER, NULL,
+ trace_mark(blk_pdu_unplug_timer, %p %p %d, q, NULL,
q-rq.count[READ] + q-rq.count[WRITE]);
kblockd_schedule_work(q-unplug_work);
@@ -2148,7 +2149,7 @@
rq_init(q, rq);
- blk_add_trace_generic(q, bio, rw, BLK_TA_GETRQ);
+ trace_mark(blk_get_request, %p %p %d, q, bio, rw);
out:
return rq;
}
@@ -2178,7 +2179,7 @@
if (!rq) {
struct io_context *ioc;
- blk_add_trace_generic(q, bio, rw, BLK_TA_SLEEPRQ);
+ trace_mark(blk_sleep_request, %p %p %d, q, bio, rw);
__generic_unplug_device(q);
spin_unlock_irq(q-queue_lock);
@@ -2252,7 +2253,7 @@
*/
void blk_requeue_request(request_queue_t *q, struct request *rq)
{
- blk_add_trace_rq(q, rq, BLK_TA_REQUEUE);
+ trace_mark(blk_requeue, %p %p, q, rq);
if (blk_rq_tagged(rq))
blk_queue_end_tag(q, rq);
@@ -2937,7 +2938,7 @@
if (!ll_back_merge_fn(q, req, bio))
break;
- blk_add_trace_bio(q, bio, BLK_TA_BACKMERGE);
+ trace_mark(blk_bio_backmerge, %p %p, q, bio);
req-biotail-bi_next = bio;
req-biotail = bio;
@@ -2954,7 +2955,7 @@
if (!ll_front_merge_fn(q, req, bio))
break;
- blk_add_trace_bio(q, bio, BLK_TA_FRONTMERGE);
+
Re: [patch 08/10] mips: tlbex: use __attribute_unused__
On Tue, May 01, 2007 at 09:28:45PM -0700, David Rientjes wrote: Replace function instances of __attribute__((unused)) with __attribute_unused__. Cc: Ralf Baechle [EMAIL PROTECTED] Signed-off-by: David Rientjes [EMAIL PROTECTED] Acked-by: Ralf Baechle [EMAIL PROTECTED] Ralf - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22 -mm merge plans
On Thu, May 03, 2007 at 01:16:46PM -0400, Mathieu Desnoyers wrote: kprobes does this kind of synchronization internally, so the marker wrapper should probabl aswell. The problem appears on heavily loaded systems. Doing 50 synchronize_sched() calls in a row can take up to a few seconds on a 4-way machine. This is why I prefer to do it in the module to which the callbacks belong. We recently had a discussion on batch unreistration interface for kprobes. I'm not very happy with having so different interfaces for different kind of probe registrations. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] cm4000_cs: fix error paths
This patch fixes error paths in module_init and probe
functions in cm4000_cs and cm4040_cs drivers.
Cc: Harald Welte [EMAIL PROTECTED]
Signed-off-by: Akinobu Mita [EMAIL PROTECTED]
---
drivers/char/pcmcia/cm4000_cs.c |9 +++--
drivers/char/pcmcia/cm4040_cs.c |7 ++-
2 files changed, 13 insertions(+), 3 deletions(-)
Index: 2.6-git/drivers/char/pcmcia/cm4000_cs.c
===
--- 2.6-git.orig/drivers/char/pcmcia/cm4000_cs.c
+++ 2.6-git/drivers/char/pcmcia/cm4000_cs.c
@@ -1881,8 +1881,11 @@ static int cm4000_probe(struct pcmcia_de
init_waitqueue_head(dev-readq);
ret = cm4000_config(link, i);
- if (ret)
+ if (ret) {
+ dev_table[i] = NULL;
+ kfree(dev);
return ret;
+ }
class_device_create(cmm_class, NULL, MKDEV(major, i), NULL,
cmm%d, i);
@@ -1907,7 +1910,7 @@ static void cm4000_detach(struct pcmcia_
cm4000_release(link);
dev_table[devno] = NULL;
- kfree(dev);
+ kfree(dev);
class_device_destroy(cmm_class, MKDEV(major, devno));
@@ -1956,12 +1959,14 @@ static int __init cmm_init(void)
if (major 0) {
printk(KERN_WARNING MODULE_NAME
: could not get major number\n);
+ class_destroy(cmm_class);
return major;
}
rc = pcmcia_register_driver(cm4000_driver);
if (rc 0) {
unregister_chrdev(major, DEVICE_NAME);
+ class_destroy(cmm_class);
return rc;
}
Index: 2.6-git/drivers/char/pcmcia/cm4040_cs.c
===
--- 2.6-git.orig/drivers/char/pcmcia/cm4040_cs.c
+++ 2.6-git/drivers/char/pcmcia/cm4040_cs.c
@@ -636,8 +636,11 @@ static int reader_probe(struct pcmcia_de
setup_timer(dev-poll_timer, cm4040_do_poll, 0);
ret = reader_config(link, i);
- if (ret)
+ if (ret) {
+ dev_table[i] = NULL;
+ kfree(dev);
return ret;
+ }
class_device_create(cmx_class, NULL, MKDEV(major, i), NULL,
cmx%d, i);
@@ -708,12 +711,14 @@ static int __init cm4040_init(void)
if (major 0) {
printk(KERN_WARNING MODULE_NAME
: could not get major number\n);
+ class_destroy(cmx_class);
return major;
}
rc = pcmcia_register_driver(reader_driver);
if (rc 0) {
unregister_chrdev(major, DEVICE_NAME);
+ class_destroy(cmx_class);
return rc;
}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] cm4000_cs: use bitrev
Cleanup using bitrev8 in cm4000_cs driver.
Cc: Harald Welte [EMAIL PROTECTED]
Signed-off-by: Akinobu Mita [EMAIL PROTECTED]
---
drivers/char/pcmcia/Kconfig |1 +
drivers/char/pcmcia/cm4000_cs.c | 35 ++-
2 files changed, 7 insertions(+), 29 deletions(-)
Index: 2.6-git/drivers/char/pcmcia/Kconfig
===
--- 2.6-git.orig/drivers/char/pcmcia/Kconfig
+++ 2.6-git/drivers/char/pcmcia/Kconfig
@@ -21,6 +21,7 @@ config SYNCLINK_CS
config CARDMAN_4000
tristate Omnikey Cardman 4000 support
depends on PCMCIA
+ select BITREVERSE
help
Enable support for the Omnikey Cardman 4000 PCMCIA Smartcard
reader.
Index: 2.6-git/drivers/char/pcmcia/cm4000_cs.c
===
--- 2.6-git.orig/drivers/char/pcmcia/cm4000_cs.c
+++ 2.6-git/drivers/char/pcmcia/cm4000_cs.c
@@ -31,6 +31,7 @@
#include linux/init.h
#include linux/fs.h
#include linux/delay.h
+#include linux/bitrev.h
#include asm/uaccess.h
#include asm/io.h
@@ -194,41 +195,17 @@ static inline unsigned char xinb(unsigne
}
#endif
-#defineb_ 15
-#defineb_0001 14
-#defineb_0010 13
-#defineb_0011 12
-#defineb_0100 11
-#defineb_0101 10
-#defineb_0110 9
-#defineb_0111 8
-#defineb_1000 7
-#defineb_1001 6
-#defineb_1010 5
-#defineb_1011 4
-#defineb_1100 3
-#defineb_1101 2
-#defineb_1110 1
-#defineb_ 0
-
-static unsigned char irtab[16] = {
- b_, b_1000, b_0100, b_1100,
- b_0010, b_1010, b_0110, b_1110,
- b_0001, b_1001, b_0101, b_1101,
- b_0011, b_1011, b_0111, b_
-};
+static inline unsigned char invert_revert(unsigned char ch)
+{
+ return bitrev8(~ch);
+}
static void str_invert_revert(unsigned char *b, int len)
{
int i;
for (i = 0; i len; i++)
- b[i] = (irtab[b[i] 0x0f] 4) | irtab[b[i] 4];
-}
-
-static unsigned char invert_revert(unsigned char ch)
-{
- return (irtab[ch 0x0f] 4) | irtab[ch 4];
+ b[i] = invert_revert(b[i]);
}
#defineATRLENCK(dev,pos) \
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] use simple_read_from_buffer() in fs/
From: Akinobu Mita [EMAIL PROTECTED]
Cleanup using simple_read_from_buffer() in binfmt_misc,
configfs, and sysfs.
Cc: Greg Kroah-Hartman [EMAIL PROTECTED]
Cc: Joel Becker [EMAIL PROTECTED]
Signed-off-by: Akinobu Mita [EMAIL PROTECTED]
---
fs/binfmt_misc.c | 13 +
fs/configfs/file.c | 33 ++---
fs/sysfs/file.c| 33 ++---
3 files changed, 5 insertions(+), 74 deletions(-)
Index: 2.6-git/fs/configfs/file.c
===
--- 2.6-git.orig/fs/configfs/file.c
+++ 2.6-git/fs/configfs/file.c
@@ -77,36 +77,6 @@ static int fill_read_buffer(struct dentr
return ret;
}
-
-/**
- * flush_read_buffer - push buffer to userspace.
- * @buffer:data buffer for file.
- * @userbuf: user-passed buffer.
- * @count: number of bytes requested.
- * @ppos: file position.
- *
- * Copy the buffer we filled in fill_read_buffer() to userspace.
- * This is done at the reader's leisure, copying and advancing
- * the amount they specify each time.
- * This may be called continuously until the buffer is empty.
- */
-static int flush_read_buffer(struct configfs_buffer * buffer, char __user *
buf,
-size_t count, loff_t * ppos)
-{
- int error;
-
- if (*ppos buffer-count)
- return 0;
-
- if (count (buffer-count - *ppos))
- count = buffer-count - *ppos;
-
- error = copy_to_user(buf,buffer-page + *ppos,count);
- if (!error)
- *ppos += count;
- return error ? -EFAULT : count;
-}
-
/**
* configfs_read_file - read an attribute.
* @file: file pointer.
@@ -139,7 +109,8 @@ configfs_read_file(struct file *file, ch
}
pr_debug(%s: count = %zd, ppos = %lld, buf = %s\n,
__FUNCTION__, count, *ppos, buffer-page);
- retval = flush_read_buffer(buffer,buf,count,ppos);
+ retval = simple_read_from_buffer(buf, count, ppos, buffer-page,
+buffer-count);
out:
up(buffer-sem);
return retval;
Index: 2.6-git/fs/sysfs/file.c
===
--- 2.6-git.orig/fs/sysfs/file.c
+++ 2.6-git/fs/sysfs/file.c
@@ -112,36 +112,6 @@ static int fill_read_buffer(struct dentr
return ret;
}
-
-/**
- * flush_read_buffer - push buffer to userspace.
- * @buffer:data buffer for file.
- * @buf: user-passed buffer.
- * @count: number of bytes requested.
- * @ppos: file position.
- *
- * Copy the buffer we filled in fill_read_buffer() to userspace.
- * This is done at the reader's leisure, copying and advancing
- * the amount they specify each time.
- * This may be called continuously until the buffer is empty.
- */
-static int flush_read_buffer(struct sysfs_buffer * buffer, char __user * buf,
-size_t count, loff_t * ppos)
-{
- int error;
-
- if (*ppos buffer-count)
- return 0;
-
- if (count (buffer-count - *ppos))
- count = buffer-count - *ppos;
-
- error = copy_to_user(buf,buffer-page + *ppos,count);
- if (!error)
- *ppos += count;
- return error ? -EFAULT : count;
-}
-
/**
* sysfs_read_file - read an attribute.
* @file: file pointer.
@@ -178,7 +148,8 @@ sysfs_read_file(struct file *file, char
}
pr_debug(%s: count = %zd, ppos = %lld, buf = %s\n,
__FUNCTION__, count, *ppos, buffer-page);
- retval = flush_read_buffer(buffer,buf,count,ppos);
+ retval = simple_read_from_buffer(buf, count, ppos, buffer-page,
+buffer-count);
out:
up(buffer-sem);
return retval;
Index: 2.6-git/fs/binfmt_misc.c
===
--- 2.6-git.orig/fs/binfmt_misc.c
+++ 2.6-git/fs/binfmt_misc.c
@@ -675,19 +675,8 @@ static ssize_t
bm_status_read(struct file *file, char __user *buf, size_t nbytes, loff_t
*ppos)
{
char *s = enabled ? enabled : disabled;
- int len = strlen(s);
- loff_t pos = *ppos;
- if (pos 0)
- return -EINVAL;
- if (pos = len)
- return 0;
- if (len pos + nbytes)
- nbytes = len - pos;
- if (copy_to_user(buf, s + pos, nbytes))
- return -EFAULT;
- *ppos = pos + nbytes;
- return nbytes;
+ return simple_read_from_buffer(buf, nbytes, ppos, s, strlen(s));
}
static ssize_t bm_status_write(struct file * file, const char __user * buffer,
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
[PATCH] use simple_read_from_buffer in kernel/
Cleanup using simple_read_from_buffer() for /dev/cpuset/tasks
and /proc/config.gz.
Cc: Paul Jackson [EMAIL PROTECTED]
Cc: Randy Dunlap [EMAIL PROTECTED]
Signed-off-by: Akinobu Mita [EMAIL PROTECTED]
---
kernel/configs.c | 15 +++
kernel/cpuset.c |7 +--
2 files changed, 4 insertions(+), 18 deletions(-)
Index: 2.6-git/kernel/cpuset.c
===
--- 2.6-git.orig/kernel/cpuset.c
+++ 2.6-git/kernel/cpuset.c
@@ -1751,12 +1751,7 @@ static ssize_t cpuset_tasks_read(struct
{
struct ctr_struct *ctr = file-private_data;
- if (*ppos + nbytes ctr-bufsz)
- nbytes = ctr-bufsz - *ppos;
- if (copy_to_user(buf, ctr-buf + *ppos, nbytes))
- return -EFAULT;
- *ppos += nbytes;
- return nbytes;
+ return simple_read_from_buffer(buf, nbytes, ppos, ctr-buf, ctr-bufsz);
}
static int cpuset_tasks_release(struct inode *unused_inode, struct file *file)
Index: 2.6-git/kernel/configs.c
===
--- 2.6-git.orig/kernel/configs.c
+++ 2.6-git/kernel/configs.c
@@ -61,18 +61,9 @@ static ssize_t
ikconfig_read_current(struct file *file, char __user *buf,
size_t len, loff_t * offset)
{
- loff_t pos = *offset;
- ssize_t count;
-
- if (pos = kernel_config_data_size)
- return 0;
-
- count = min(len, (size_t)(kernel_config_data_size - pos));
- if (copy_to_user(buf, kernel_config_data + MAGIC_SIZE + pos, count))
- return -EFAULT;
-
- *offset += count;
- return count;
+ return simple_read_from_buffer(buf, len, offset,
+ kernel_config_data + MAGIC_SIZE,
+ kernel_config_data_size);
}
static const struct file_operations ikconfig_file_ops = {
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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 04/33] m68k: Atari keyboard and mouse support.
Hi,
On Thu, 3 May 2007, Michael Schmitz wrote:
+ for (i = 1; i 0x72; i++) {
+ atakbd_keycode[i] = i;
+ set_bit(atakbd_keycode[i], atakbd_dev-keybit);
It looks like this driver is not using standard input event codes.
Actually it does, it just sort of works because Atari generates mostly
AT keycodes.
If
Roman does not want to adjust keymaps on Amiga and Atari that should
be handled in legacy keyboard driver (drivers/char/keyboard.c). As it
is programs using /dev/input/eventX have no chance of working.
I explained already at a earlier occasion, why this generic keycode
thing is broken by design, which makes connecting multiple keyboards with
different mappings impossible.
bye, Roman
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] tty add compat_ioctl
Add compat_ioctl method for tty code to allow processing
of 32 bit ioctl calls on 64 bit systems by tty core,
tty drivers, and line disciplines.
Based on patch by Arnd Bergmann:
http://www.uwsg.iu.edu/hypermail/linux/kernel/0511.0/1732.html
Signed-off-by: Paul Fulghum [EMAIL PROTECTED]
CC: Arnd Bergmann [EMAIL PROTECTED]
--- a/drivers/char/n_tty.c 2007-04-25 22:08:32.0 -0500
+++ b/drivers/char/n_tty.c 2007-05-01 11:00:47.0 -0500
@@ -1544,21 +1544,18 @@ static unsigned int normal_poll(struct t
}
struct tty_ldisc tty_ldisc_N_TTY = {
- TTY_LDISC_MAGIC,/* magic */
- n_tty,/* name */
- 0, /* num */
- 0, /* flags */
- n_tty_open, /* open */
- n_tty_close,/* close */
- n_tty_flush_buffer, /* flush_buffer */
- n_tty_chars_in_buffer, /* chars_in_buffer */
- read_chan, /* read */
- write_chan, /* write */
- n_tty_ioctl,/* ioctl */
- n_tty_set_termios, /* set_termios */
- normal_poll,/* poll */
- NULL, /* hangup */
- n_tty_receive_buf, /* receive_buf */
- n_tty_write_wakeup /* write_wakeup */
+ .magic = TTY_LDISC_MAGIC,
+ .name= n_tty,
+ .open= n_tty_open,
+ .close = n_tty_close,
+ .flush_buffer= n_tty_flush_buffer,
+ .chars_in_buffer = n_tty_chars_in_buffer,
+ .read= read_chan,
+ .write = write_chan,
+ .ioctl = n_tty_ioctl,
+ .set_termios = n_tty_set_termios,
+ .poll= normal_poll,
+ .receive_buf = n_tty_receive_buf,
+ .write_wakeup= n_tty_write_wakeup
};
--- a/include/linux/tty_driver.h2007-04-25 22:08:32.0 -0500
+++ b/include/linux/tty_driver.h2007-05-03 10:03:52.0 -0500
@@ -52,6 +52,11 @@
* This routine allows the tty driver to implement
* device-specific ioctl's. If the ioctl number passed in cmd
* is not recognized by the driver, it should return ENOIOCTLCMD.
+ *
+ * long (*compat_ioctl)(struct tty_struct *tty, struct file * file,
+ * unsigned int cmd, unsigned long arg);
+ *
+ * implement ioctl processing for 32 bit process on 64 bit system
*
* void (*set_termios)(struct tty_struct *tty, struct ktermios * old);
*
@@ -132,6 +137,8 @@ struct tty_operations {
int (*chars_in_buffer)(struct tty_struct *tty);
int (*ioctl)(struct tty_struct *tty, struct file * file,
unsigned int cmd, unsigned long arg);
+ long (*compat_ioctl)(struct tty_struct *tty, struct file * file,
+unsigned int cmd, unsigned long arg);
void (*set_termios)(struct tty_struct *tty, struct ktermios * old);
void (*throttle)(struct tty_struct * tty);
void (*unthrottle)(struct tty_struct * tty);
@@ -193,6 +200,8 @@ struct tty_driver {
int (*chars_in_buffer)(struct tty_struct *tty);
int (*ioctl)(struct tty_struct *tty, struct file * file,
unsigned int cmd, unsigned long arg);
+ long (*compat_ioctl)(struct tty_struct *tty, struct file * file,
+unsigned int cmd, unsigned long arg);
void (*set_termios)(struct tty_struct *tty, struct ktermios * old);
void (*throttle)(struct tty_struct * tty);
void (*unthrottle)(struct tty_struct * tty);
--- a/drivers/char/tty_io.c 2007-04-25 22:08:32.0 -0500
+++ b/drivers/char/tty_io.c 2007-05-03 10:42:35.0 -0500
@@ -153,6 +153,11 @@ static int tty_open(struct inode *, stru
static int tty_release(struct inode *, struct file *);
int tty_ioctl(struct inode * inode, struct file * file,
unsigned int cmd, unsigned long arg);
+#ifdef CONFIG_COMPAT
+long tty_compat_ioctl(struct file * file, unsigned int cmd, unsigned long arg);
+#else
+#define tty_compat_ioctl NULL
+#endif
static int tty_fasync(int fd, struct file * filp, int on);
static void release_tty(struct tty_struct *tty, int idx);
static struct pid *__proc_set_tty(struct task_struct *tsk,
@@ -1145,8 +1150,8 @@ static unsigned int hung_up_tty_poll(str
return POLLIN | POLLOUT | POLLERR | POLLHUP | POLLRDNORM | POLLWRNORM;
}
-static int hung_up_tty_ioctl(struct inode * inode, struct file * file,
-unsigned int cmd, unsigned long arg)
+static long hung_up_tty_ioctl(struct file * file,
+ unsigned int cmd, unsigned long arg)
{
return cmd == TIOCSPGRP ? -ENOTTY : -EIO;
}
@@ -1157,6 +1162,7 @@ static const struct file_operations tty_
.write = tty_write,
.poll = tty_poll,
.ioctl = tty_ioctl,
+ .compat_ioctl = tty_compat_ioctl,
.open =
Re: [ext3][kernels = 2.6.20.7 at least] KDE going comatose when FS is under heavy write load (massive starvation)
Andrew Morton wrote:
We can make great improvements here, and I've (twice) previously decribed
how: hoist the entire ordered-mode data handling out of ext3, and out of
the buffer_head layer and move it up into the VFS pagecache layer.
Basically, do ordered-data with a commit-time inode walk, calling
do_sync_mapping_range().
Do it in the VFS. Make reiserfs use it, remove reiserfs ordered-mode too.
Make XFS use it, fix the hey-my-files-are-all-full-of-zeroes problem there.
I'm not sure it's that easy.
if we move to pages, then we have to mark pages to be flushed holding
transaction open. now take delayed allocation into account: we need
to allocate number of blocks at once and then mark all pages mapped,
again within context of the same transaction. so, an implementation
would look like the following?
generic_writepages() {
/* collect set of contig. dirty pages */
foo_get_blocks() {
foo_journal_start();
foo_new_blocks();
foo_attach_blocks_to_inode();
generic_mark_pages_mapped();
foo_journal_stop();
}
}
another question is will it scale well given number of dirty inodes
can be much larger than number of inodes with dirty mapped blocks
(in delayed allocation case, for example) ?
thanks, Alex
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -v2 1/1] Misc: add sensable phantom driver
On Thu, 03 May 2007 14:40:01 +0200 Jiri Slaby [EMAIL PROTECTED] wrote:
+static int phantom_release(struct inode *inode, struct file *file)
+{
+ struct phantom_device *dev = file-private_data;
+
+ if (mutex_lock_interruptible(dev-open_lock))
+ return -ERESTARTSYS;
+
+ dev-opened = 0;
+ phantom_status(dev, dev-status ~PHB_RUNNING);
+
+ mutex_unlock(dev-open_lock);
+
+ return 0;
+}
The mutex_lock_interruptible() is wrong, I think. This function is called
when we do the final close(). If the signal _is_ taken then it's game
over: the device can no longer be opened.
Yes, starving at sys_close, I think so.
fast searching in drivers/*
Wouldn't this be a problem here too:
drivers/media/dvb/cinergyT2/cinergyT2.c
drivers/usb/misc/auerswald.c
at least that the device won't be stopped or something like that?
Yes, those drivers appear to have the same problem. I'll fix 'em.
+/*
+ * Init and deinit driver
+ */
+
+static unsigned int __devinit phantom_get_free(void)
+{
+ unsigned int i;
+
+ for (i = 0; i PHANTOM_MAX_MINORS; i++)
+ if (phantom_devices[i] == 0)
+ break;
+
+ return i;
+}
This function assumes that the phantom_devices[] array will never have any
holes in it. But if phantom_remove() is called out-of-order, it _will_
have holes. Perhaps - I didn't look too hard.
I'm afraid I didn't get this. It goes through all phantom_devices and
returns first free index. If a hole is present it will return i which
corresponds to the hole, because phantom_devices[i] is 0. Note that it is
unsigned char array.
I guess I must have misread the code.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Execute in place
Al Boldi wrote: Dmitry Krivoschekov wrote: Al Boldi wrote: Now, if there were only an easy way to make tmpfs persistent? It would be not a tmpfs (*temporary* fs)then, Isn't everything really just temporary? Would you like to talk about this? Not with me, I'm not a psychoanalyst :) but something like this http://pramfs.sourceforge.net/ Thanks a lot, but this seems to rely on a non-volatile RAM. No, it relies on a battery-backed normal RAM, which of course may be considered as non-volatile. Thanks, Dmitry - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 pull] New firewire stack
Adrian Bunk wrote: | An advantage of changing the names is that they are now prefixed. Is the opportunity to clean up module names compelling enough, vs. (the wish for) minimized trouble with scripts which refer to module names? ... How big is the trouble actually? Exactly. In Fedora we've just added a fw-sbp2 case to mkinitrd, it's only a couple of lines of extra shell code: elif [ $modName = fw-sbp2 ]; then findmodule fw-core findmodule fw-ohci modName=fw-sbp2 and that's the extent of the changes. The sbp2 case for the old drivers is still in there and in the end mkinitrd works with either stack. Kristian - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 01/10] compiler: define __attribute_unused__
On Wed, May 02, 2007 at 10:16:15AM -0700, David Rientjes wrote: On Wed, 2 May 2007, Adrian Bunk wrote: If we don't want any warnings with CONFIG_PCI=n, CONFIG_SYSFS=n or CONFIG_PROC_FS=n, we'd have to annotate _many_ functions. If the lonterm goal is to compile the kernel with -Werror then we need -Wno-unused-function, not annotating individual functions. That's only addressing part of the issue. What about automatic or static external variables that are declared but may go unreferenced depending on This is only about static code. For non-static code it would be impossible for gcc to issue warnings. preprocessor macros? You need to annotate them with __attribute__ ((unused)) to suppress compiler warnings. Globally disabling such warnings would eventually cause unused code to go unnoticed. But looking at a kernel build it seems there are far few warnings than I remembered, so it might actually be possible to annotate all code accordingly. David cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Remove apparently dead CONFIG_NO_ATA_LEGACY code.
Remove the single snippet of code conditional on the non-existent
CONFIG_NO_ATA_LEGACY Kconfig variable.
Signed-off-by: Robert P. J. Day [EMAIL PROTECTED]
---
i would have mailed a note about this to the ATA maintainer but it
wasn't clear who that was. this is the only dead CONFIG_ variable
under drivers/ata so i figured i'd just submit the patch.
diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
index d211db6..5a4821a 100644
--- a/drivers/ata/libata-sff.c
+++ b/drivers/ata/libata-sff.c
@@ -985,16 +985,6 @@ int ata_pci_init_one (struct pci_dev *pdev, struct
ata_port_info **port_info,
mask = (1 2) | (1 0);
if ((tmp8 mask) != mask)
legacy_mode = (1 3);
-#if defined(CONFIG_NO_ATA_LEGACY)
- /* Some platforms with PCI limits cannot address compat
- port space. In that case we punt if their firmware has
- left a device in compatibility mode */
- if (legacy_mode) {
- printk(KERN_ERR ata: Compatibility mode ATA is not
supported on this platform, skipping.\n);
- rc = -EOPNOTSUPP;
- goto err_out;
- }
-#endif
}
/* alloc and init host */
--
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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 0/3] readahead statistics slimmed down
This patch set simplifies the statistics code of the adaptive readahead feature by using the proposed statistic infrastructure. Patches are against 2.6.21-rc7-mm2. [RFC] [Patch 1/3] readahead statistics slimmed down, statistics prereq [RFC] [Patch 2/3] readahead statistics slimmed down, adapt zfcp [RFC] [Patch 3/3] readahead statistics slimmed down Signed-off-by: Martin Peschke [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/
