Re: Kernel SCM saga..
Linus Torvalds wrote: On Fri, 8 Apr 2005, Matthias-Christian Ott wrote: But as mentioned you need to _open_ each file (It doesn't matter if it's cached (this speeds up only reading it) -- you need a _slow_ system call and _very slow_ hardware access anyway). Nope. System calls aren't slow. What crappy OS are you running? But they're slower because there're some instances checking them. I hope my idea/opinion is clear now. Numbers talk. I've got something that you can test ;) This doesn't mean it's better just because you had the time develope it ;). But anyhow the folk needs something, they can test to see if it's good or not, most don't believe in concepts. Linus We will see which solutions wins the "race". But I think you're solutions will "win", because you're Linus Torvalds -- the "Boss" of Linux and have to work with this system very day (usualy people are using what they have developed :)) -- and I have not the time develop a database based solution (maybe someone else is interested in developing it). Matthias-Christian - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 SCM saga..
Linus Torvalds wrote: On Fri, 8 Apr 2005, Matthias-Christian Ott wrote: Ok, but if you want to search for information in such big text files it slow, because you do linear search No I don't. I don't search for _anything_. I have my own content-addressable filesystem, and I guarantee you that it's faster than mysql, because it depends on the kernel doing the right thing (which it does). I'm not talking about mysql, i'm talking about fast databases like sqlite or db4. I never do a single "readdir". It's all direct data lookup, no "searching" anywhere. Databases aren't magical. Quite the reverse. They easily end up being _slower_ than doing it by hand, simply because they have to solve a much more generic issue. If you design your data structures and abstractions right, a database is pretty much guaranteed to only incur overhead. The advantage of a database is the abstraction and management it gives you. But I did my own special-case abstraction in git. Yeah, I bet "git" might suck if your OS sucks. I definitely depend on name caching at an OS level so that I know that opening a file is fast. In other words, there _is_ an indexing and caching database in there, and it's called the Linux VFS layer and the dentry cache. The proof is in the pudding. git is designed for _one_ thing, and one thing only: tracking a series of directory states in a way that can be replicated. It's very very fast at that. A database with a more flexible abstraction migt be faster at other things, but the fact is, you do take a hit. The problem with databases are: - they are damn hard to just replicate wildly and without control. The database backing file inherently has a lot of internal state. You may be able to "just copy it", but you have to copy the whole damn thing. This is _not_ true for every database (specialy plain/text databases with meta information). In "git", the data is all there in immutable blobs that you can just rsync. In fact, you don't even need rsync: you can just look at the filenames, and anything new you copy. No need for any fancy "read the files to see that they match". They _will_ match, or you can tell immediately that a file is corrupt. Look at this: [EMAIL PROTECTED]:~/git> sha1sum .dircache/objects/e7/bfaadd5d2331123663a8f14a26604a3cdcb678 e7bfaadd5d2331123663a8f14a26604a3cdcb678 .dircache/objects/e7/bfaadd5d2331123663a8f14a26604a3cdcb678 see a pattern anywhere? Imagine that you know the list of files you have, and the list of files the other side has (never mind the contents), and how _easy_ it is to synchronize. Without ever having to even read the remote files that you know you already have. How do you replicate your database incrementally? I've given you enough clues to do it for "git" in probably five lines of perl. I replicate my database incremently by using a hash list like you (the client sends its hash list, the server compares the lists and acquaints the client behind which data (data = hash + data) the data has to added (this is like your solution -- you also submit the data and the location (you have directories too, right?)). A database is in some cases (like this one) like a filesystem, but it's build one top of better filesystem like xfs, reiser4 or ext3 which support features like LVM, Quotas or Journaling (Is your filesystem also build on top of existing filesystem? I don't think so because you're talking about vfs operatations on the filesystem). - they tend to take time to set up and prime. In contrast, the filesystem is always there. Sure, you effectively have to "prime" that one too, but the thing is, if your OS is doing its job, you basically only need to prime it once per reboot. No need to prime it for each process you start or play games with connecting to servers etc. It's just there. Always. The database -- single file (sqlite or db4) -- is always there too because it's on the filesystem and doesn't need a server. So if you think of the filesystem as a database, you're all set. If you design your data structure so that there is just one index, you make that the name, and the kernel will do all the O(1) hashed lookups etc for you. You do have to limit yourself in some ways. But as mentioned you need to _open_ each file (It doesn't matter if it's cached (this speeds up only reading it) -- you need a _slow_ system call and _very slow_ hardware access anyway). Have a look at this comparison: If you have big chest and lots of small chests containing the same bulk of gold, it's more work to collect the gold from the small chests than from the big one (which would contain as many a cases as little chests exist). You can faster find your gold because you don't have to walk to the other chests and you don't have to open that much caps which saves also time. Oh, and you h
Re: Kernel SCM saga..
Linus Torvalds wrote: On Fri, 8 Apr 2005, Matthias-Christian Ott wrote: SQL Databases like SQLite aren't slow. After applying a patch, I can do a complete "show-diff" on the kernel tree to see the effect of it in about 0.15 seconds. Also, I can use rsync to efficiently replicate my database without having to re-send the whole crap - it only needs to send the new stuff. You do that with an sql database, and I'll be impressed. Linus Ok, but if you want to search for information in such big text files it slow, because you do linear search -- most datases use faster search algorithms like hashing and if you have multiple files (I don't if you're system uses multiple files (like bitkeeper) or not) which need a system call to be opened this will be very slow, because system calls itself are slow. And using rsync is also possible because most databases store their information as plain text with meta information. Mattthias-Christian Ott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 SCM saga..
Linus Torvalds wrote: On Fri, 8 Apr 2005, Andrea Arcangeli wrote: Why not to use sql as backend instead of the tree of directories? Because it sucks? I can come up with millions of ways to slow things down on my own. Please come up with ways to speed things up instead. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ SQL Databases like SQLite aren't slow. But maybe a Berkeley Database v.4 is a better solution. Matthias-Christian Ott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 SCM saga..
Linus Torvalds wrote: On Fri, 8 Apr 2005, Andrea Arcangeli wrote: Why not to use sql as backend instead of the tree of directories? Because it sucks? I can come up with millions of ways to slow things down on my own. Please come up with ways to speed things up instead. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ SQL Databases like SQLite aren't slow. But maybe a Berkeley Database v.4 is a better solution. Matthias-Christian Ott - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 SCM saga..
Linus Torvalds wrote: On Fri, 8 Apr 2005, Matthias-Christian Ott wrote: SQL Databases like SQLite aren't slow. After applying a patch, I can do a complete show-diff on the kernel tree to see the effect of it in about 0.15 seconds. Also, I can use rsync to efficiently replicate my database without having to re-send the whole crap - it only needs to send the new stuff. You do that with an sql database, and I'll be impressed. Linus Ok, but if you want to search for information in such big text files it slow, because you do linear search -- most datases use faster search algorithms like hashing and if you have multiple files (I don't if you're system uses multiple files (like bitkeeper) or not) which need a system call to be opened this will be very slow, because system calls itself are slow. And using rsync is also possible because most databases store their information as plain text with meta information. Mattthias-Christian Ott - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 SCM saga..
Linus Torvalds wrote: On Fri, 8 Apr 2005, Matthias-Christian Ott wrote: Ok, but if you want to search for information in such big text files it slow, because you do linear search No I don't. I don't search for _anything_. I have my own content-addressable filesystem, and I guarantee you that it's faster than mysql, because it depends on the kernel doing the right thing (which it does). I'm not talking about mysql, i'm talking about fast databases like sqlite or db4. I never do a single readdir. It's all direct data lookup, no searching anywhere. Databases aren't magical. Quite the reverse. They easily end up being _slower_ than doing it by hand, simply because they have to solve a much more generic issue. If you design your data structures and abstractions right, a database is pretty much guaranteed to only incur overhead. The advantage of a database is the abstraction and management it gives you. But I did my own special-case abstraction in git. Yeah, I bet git might suck if your OS sucks. I definitely depend on name caching at an OS level so that I know that opening a file is fast. In other words, there _is_ an indexing and caching database in there, and it's called the Linux VFS layer and the dentry cache. The proof is in the pudding. git is designed for _one_ thing, and one thing only: tracking a series of directory states in a way that can be replicated. It's very very fast at that. A database with a more flexible abstraction migt be faster at other things, but the fact is, you do take a hit. The problem with databases are: - they are damn hard to just replicate wildly and without control. The database backing file inherently has a lot of internal state. You may be able to just copy it, but you have to copy the whole damn thing. This is _not_ true for every database (specialy plain/text databases with meta information). In git, the data is all there in immutable blobs that you can just rsync. In fact, you don't even need rsync: you can just look at the filenames, and anything new you copy. No need for any fancy read the files to see that they match. They _will_ match, or you can tell immediately that a file is corrupt. Look at this: [EMAIL PROTECTED]:~/git sha1sum .dircache/objects/e7/bfaadd5d2331123663a8f14a26604a3cdcb678 e7bfaadd5d2331123663a8f14a26604a3cdcb678 .dircache/objects/e7/bfaadd5d2331123663a8f14a26604a3cdcb678 see a pattern anywhere? Imagine that you know the list of files you have, and the list of files the other side has (never mind the contents), and how _easy_ it is to synchronize. Without ever having to even read the remote files that you know you already have. How do you replicate your database incrementally? I've given you enough clues to do it for git in probably five lines of perl. I replicate my database incremently by using a hash list like you (the client sends its hash list, the server compares the lists and acquaints the client behind which data (data = hash + data) the data has to added (this is like your solution -- you also submit the data and the location (you have directories too, right?)). A database is in some cases (like this one) like a filesystem, but it's build one top of better filesystem like xfs, reiser4 or ext3 which support features like LVM, Quotas or Journaling (Is your filesystem also build on top of existing filesystem? I don't think so because you're talking about vfs operatations on the filesystem). - they tend to take time to set up and prime. In contrast, the filesystem is always there. Sure, you effectively have to prime that one too, but the thing is, if your OS is doing its job, you basically only need to prime it once per reboot. No need to prime it for each process you start or play games with connecting to servers etc. It's just there. Always. The database -- single file (sqlite or db4) -- is always there too because it's on the filesystem and doesn't need a server. So if you think of the filesystem as a database, you're all set. If you design your data structure so that there is just one index, you make that the name, and the kernel will do all the O(1) hashed lookups etc for you. You do have to limit yourself in some ways. But as mentioned you need to _open_ each file (It doesn't matter if it's cached (this speeds up only reading it) -- you need a _slow_ system call and _very slow_ hardware access anyway). Have a look at this comparison: If you have big chest and lots of small chests containing the same bulk of gold, it's more work to collect the gold from the small chests than from the big one (which would contain as many a cases as little chests exist). You can faster find your gold because you don't have to walk to the other chests and you don't have to open that much caps which saves also time. Oh, and you have to be willing to waste diskspace. git is _not_ space-efficient. The good news is that it is cache-friendly
Re: Kernel SCM saga..
Linus Torvalds wrote: On Fri, 8 Apr 2005, Matthias-Christian Ott wrote: But as mentioned you need to _open_ each file (It doesn't matter if it's cached (this speeds up only reading it) -- you need a _slow_ system call and _very slow_ hardware access anyway). Nope. System calls aren't slow. What crappy OS are you running? But they're slower because there're some instances checking them. I hope my idea/opinion is clear now. Numbers talk. I've got something that you can test ;) This doesn't mean it's better just because you had the time develope it ;). But anyhow the folk needs something, they can test to see if it's good or not, most don't believe in concepts. Linus We will see which solutions wins the race. But I think you're solutions will win, because you're Linus Torvalds -- the Boss of Linux and have to work with this system very day (usualy people are using what they have developed :)) -- and I have not the time develop a database based solution (maybe someone else is interested in developing it). Matthias-Christian - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][1/7] cifs: dir.c cleanup - spaces
, mode,
+(__u64)-1, (__u64)-1,
+device_number,
+cifs_sb->local_nls);
}
- if(!rc) {
+ if (!rc) {
rc = cifs_get_inode_info_unix(, full_path,
- inode->i_sb,xid);
+ inode->i_sb,xid);
direntry->d_op = _dentry_ops;
- if(rc == 0)
+ if (rc == 0)
d_instantiate(direntry, newinode);
}
}
@@ -390,9 +391,8 @@ struct dentry *cifs_lookup(struct inode
xid = GetXid();
- cFYI(1,
-(" parent inode = 0x%p name is: %s and dentry = 0x%p",
- parent_dir_inode, direntry->d_name.name, direntry));
+ cFYI(1, (" parent inode = 0x%p name is: %s and dentry = 0x%p",
+parent_dir_inode, direntry->d_name.name, direntry));
/* BB Add check of incoming data - e.g. frame not longer than maximum
SMB - let server check the namelen BB */
@@ -405,7 +405,7 @@ struct dentry *cifs_lookup(struct inode
deadlock in the cases (beginning of sys_rename itself)
in which we already have the sb rename sem */
full_path = build_path_from_dentry(direntry);
- if(full_path == NULL) {
+ if (full_path == NULL) {
FreeXid(xid);
return ERR_PTR(-ENOMEM);
}
@@ -415,8 +415,7 @@ struct dentry *cifs_lookup(struct inode
} else {
cFYI(1, (" NULL inode in lookup"));
}
- cFYI(1,
- (" Full path: %s inode = 0x%p", full_path, direntry->d_inode));
+ cFYI(1, (" Full path: %s inode = 0x%p", full_path, direntry->d_inode));
if (pTcon->ses->capabilities & CAP_UNIX)
rc = cifs_get_inode_info_unix(, full_path,
@@ -436,7 +435,8 @@ struct dentry *cifs_lookup(struct inode
rc = 0;
d_add(direntry, NULL);
} else {
- cERROR(1,("Error 0x%x or on cifs_get_inode_info in lookup",rc));
+ cERROR(1, ("Error 0x%x or on cifs_get_inode_info in lookup",
+ rc));
/* BB special case check for Access Denied - watch security
exposure of returning dir info implicitly via different rc
if file exists or not but no access BB */
@@ -462,7 +462,7 @@ int cifs_dir_open(struct inode *inode, s
cifs_sb = CIFS_SB(inode->i_sb);
pTcon = cifs_sb->tcon;
- if(file->f_dentry) {
+ if (file->f_dentry) {
down(>f_dentry->d_sb->s_vfs_rename_sem);
full_path = build_wildcard_path_from_dentry(file->f_dentry);
up(>f_dentry->d_sb->s_vfs_rename_sem);
@@ -491,9 +491,8 @@ static int cifs_d_revalidate(struct dent
return 0;
}
} else {
- cFYI(1,
-("In cifs_d_revalidate with no inode but name = %s and dentry
0x%p",
- direntry->d_name.name, direntry));
+ cFYI(1, ("In cifs_d_revalidate with no inode but name = %s "
+"and dentry 0x%p", direntry->d_name.name, direntry));
}
/*unlock_kernel(); */
@@ -511,7 +510,7 @@ static int cifs_d_revalidate(struct dent
} */
struct dentry_operations cifs_dentry_ops = {
- .d_revalidate = cifs_d_revalidate,
-/* d_delete: cifs_d_delete, *//* not needed except for debugging */
+ .d_revalidate = cifs_d_revalidate,
+/* d_delete: cifs_d_delete, */ /* not needed except for debugging */
/* no need for d_hash, d_compare, d_release, d_iput ... yet. BB confirm
this BB */
};
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
The Subject is wrong it must be: "[PATCH][2/7] cifs: dir.c cleanup - spaces"
Matthias-Christian Ott
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: make OOM more "user friendly"
Diego Calleja schrieb: When people gets OOM messages, many of them don't know what is happening or what OOM means. This brief message explains it. --- stable/mm/oom_kill.c.orig 2005-04-02 17:44:14.0 +0200 +++ stable/mm/oom_kill.c2005-04-02 18:01:02.0 +0200 @@ -189,7 +189,8 @@ return; } task_unlock(p); - printk(KERN_ERR "Out of Memory: Killed process %d (%s).\n", p->pid, p->comm); + printk(KERN_ERR "The system has run Out Of Memory (RAM + swap), a process will be killed to free some memory\n"); + printk(KERN_ERR "OOM: Killed process %d (%s).\n", p->pid, p->comm); /* * We give our sacrificial lamb high priority and access to - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ I disagree this is _not_ usefull. If the user don't knows what OOM means he can use google to get this information. Matthias-Christian Ott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
some questions towards the boot sequence
Hi! I'm currently developing a small OS. But I have some questions towards the boot sequence: Grub (0.9.6) is installed in the MBR of the Harddisk (512 Byte - Stage 1) than grub loads Stage 2 which is located at a fixed address (specified in stage1.h), but how is this location linked to an inode and marked as used (e.g. in the ext2/3 bitmap)? And doesn't it conflict with the file system? And how can I instruct grub to load a file from a not specified location which is maybe splited without updating it every time the location changes? Maybe there are some documents which include the answers to my questions and some additional information. Thanks Matthias-Christian Ott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
some questions towards the boot sequence
Hi! I'm currently developing a small OS. But I have some questions towards the boot sequence: Grub (0.9.6) is installed in the MBR of the Harddisk (512 Byte - Stage 1) than grub loads Stage 2 which is located at a fixed address (specified in stage1.h), but how is this location linked to an inode and marked as used (e.g. in the ext2/3 bitmap)? And doesn't it conflict with the file system? And how can I instruct grub to load a file from a not specified location which is maybe splited without updating it every time the location changes? Maybe there are some documents which include the answers to my questions and some additional information. Thanks Matthias-Christian Ott - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: make OOM more user friendly
Diego Calleja schrieb: When people gets OOM messages, many of them don't know what is happening or what OOM means. This brief message explains it. --- stable/mm/oom_kill.c.orig 2005-04-02 17:44:14.0 +0200 +++ stable/mm/oom_kill.c2005-04-02 18:01:02.0 +0200 @@ -189,7 +189,8 @@ return; } task_unlock(p); - printk(KERN_ERR Out of Memory: Killed process %d (%s).\n, p-pid, p-comm); + printk(KERN_ERR The system has run Out Of Memory (RAM + swap), a process will be killed to free some memory\n); + printk(KERN_ERR OOM: Killed process %d (%s).\n, p-pid, p-comm); /* * We give our sacrificial lamb high priority and access to - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ I disagree this is _not_ usefull. If the user don't knows what OOM means he can use google to get this information. Matthias-Christian Ott - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: YABM (Yet another benchmark)
Jeroen Vreeken schrieb:
Hi,
This benchmark was made in response to a recent post here on lkm were
Linus indicated he would welcom pretty much any benchmark.
Since there are already several database benchmarks, 3d benchmarks I
opted for a more down to earth approach.
As such I am pleased to announce the 'linux kernel hacker benchmark',
a benchmark designed to simulate the activities of the average linux
kernel hacker.
With this benchmark it should be possible to measure the performance
off the kernel for its most important user group, the kernel hacker.
This workload turns out to be relativly simple to simulate as can be
seen in the attached benchmark program 'lkh-bm.c'.
It is compiled with 'gcc -Wall lkh-bm.c -o lkh-bm'.
This test has been run on all 2.6 releases and several older kernels
dating some years back. Unfortunatly 1.1 and lower kernels aren't able
to complete the test.
The compiler used was gcc 3.2.3, the cpu a Celeron @ 2.4GHz.
I plan to run this test daily on all releases, bk, mm and ac snapshots
and maybe more trees on kernel.org asuming nobody objects to me doing
a recursive web-suck with wget.
At the end of this post you will find the already done benchmarks.
As Linus seems to dig pretty pictures a graph has been attached
(lkh-bm.gif) with the same results.
Surprisingly the number seems to be constant during the last years.
This could either indicate that the kernel hasn't regressed for years
in this respect (which would mean somebody is doing a fine job indeed)
or it could mean that the average kernel hacker simply doesn't do much
usufull anyway
Regards,
Jeroen
Benchmark results:
1.1.0 0
1.1.20 0
1.1.40 0
1.1.60 0
1.2.0 603
2.0.0 604
2.0.10 605
2.0.20 600
2.0.30 601
2.2.0 602
2.2.10 603
2.2.20 604
2.4.0 605
2.4.10 600
2.4.20 601
2.6.0 602
2.6.1 603
2.6.2 604
2.6.3 605
2.6.4 600
2.6.5 601
2.6.6 602
2.6.7 603
2.6.8 604
2.6.9 605
2.6.10 600
2.6.11 601
#include
#include
#define MEASUREMENT_TIME60
#define LINUS_CONSTANT 6
/*
* my_integer_pi()
*
* This function calculates the value of PI, and returns
* 3. It does so by adding "1" in a loop three times.
*/
int my_integer_pi(void)
{
int i, pi;
/*
* This is the main loop.
*/
pi = 0;
for (i = 0; i < 3; i++)
pi++;
/* Ok, return it */
return pi;
}
int main(int argc, char **argv)
{
time_t timer, start, prev;
int completed = 0;
int calc;
start = time(NULL);
timer = start;
prev = start;
while ( timer - start <= MEASUREMENT_TIME ) {
/* do some typical kernel hacker stuff... */
calc = my_integer_pi();
timer = time(NULL);
if ((timer - prev) == LINUS_CONSTANT ) {
completed++;
prev = timer;
}
}
printf("endless LKH loops per hour: %ld\n",
completed * 3600 / MEASUREMENT_TIME + (time(NULL) %
LINUS_CONSTANT));
return 0;
}
This is _not_ serious a benchmark! It's just a counter! A _real_
benchmark would test threads, memory management, the schedule, . . . I
guess on a NetBSD or Windows machine with the same Hardware you would
get the same result.
Matthias-Christian Ott
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: YABM (Yet another benchmark)
Jeroen Vreeken schrieb:
Hi,
This benchmark was made in response to a recent post here on lkm were
Linus indicated he would welcom pretty much any benchmark.
Since there are already several database benchmarks, 3d benchmarks I
opted for a more down to earth approach.
As such I am pleased to announce the 'linux kernel hacker benchmark',
a benchmark designed to simulate the activities of the average linux
kernel hacker.
With this benchmark it should be possible to measure the performance
off the kernel for its most important user group, the kernel hacker.
This workload turns out to be relativly simple to simulate as can be
seen in the attached benchmark program 'lkh-bm.c'.
It is compiled with 'gcc -Wall lkh-bm.c -o lkh-bm'.
This test has been run on all 2.6 releases and several older kernels
dating some years back. Unfortunatly 1.1 and lower kernels aren't able
to complete the test.
The compiler used was gcc 3.2.3, the cpu a Celeron @ 2.4GHz.
I plan to run this test daily on all releases, bk, mm and ac snapshots
and maybe more trees on kernel.org asuming nobody objects to me doing
a recursive web-suck with wget.
At the end of this post you will find the already done benchmarks.
As Linus seems to dig pretty pictures a graph has been attached
(lkh-bm.gif) with the same results.
Surprisingly the number seems to be constant during the last years.
This could either indicate that the kernel hasn't regressed for years
in this respect (which would mean somebody is doing a fine job indeed)
or it could mean that the average kernel hacker simply doesn't do much
usufull anyway
Regards,
Jeroen
Benchmark results:
1.1.0 0
1.1.20 0
1.1.40 0
1.1.60 0
1.2.0 603
2.0.0 604
2.0.10 605
2.0.20 600
2.0.30 601
2.2.0 602
2.2.10 603
2.2.20 604
2.4.0 605
2.4.10 600
2.4.20 601
2.6.0 602
2.6.1 603
2.6.2 604
2.6.3 605
2.6.4 600
2.6.5 601
2.6.6 602
2.6.7 603
2.6.8 604
2.6.9 605
2.6.10 600
2.6.11 601
#include stdio.h
#include time.h
#define MEASUREMENT_TIME60
#define LINUS_CONSTANT 6
/*
* my_integer_pi()
*
* This function calculates the value of PI, and returns
* 3. It does so by adding 1 in a loop three times.
*/
int my_integer_pi(void)
{
int i, pi;
/*
* This is the main loop.
*/
pi = 0;
for (i = 0; i 3; i++)
pi++;
/* Ok, return it */
return pi;
}
int main(int argc, char **argv)
{
time_t timer, start, prev;
int completed = 0;
int calc;
start = time(NULL);
timer = start;
prev = start;
while ( timer - start = MEASUREMENT_TIME ) {
/* do some typical kernel hacker stuff... */
calc = my_integer_pi();
timer = time(NULL);
if ((timer - prev) == LINUS_CONSTANT ) {
completed++;
prev = timer;
}
}
printf(endless LKH loops per hour: %ld\n,
completed * 3600 / MEASUREMENT_TIME + (time(NULL) %
LINUS_CONSTANT));
return 0;
}
This is _not_ serious a benchmark! It's just a counter! A _real_
benchmark would test threads, memory management, the schedule, . . . I
guess on a NetBSD or Windows machine with the same Hardware you would
get the same result.
Matthias-Christian Ott
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: AMD64 Machine hardlocks when using memset
a Corporation CK804 USB Controller ehci_hcd :00:02.1: new USB bus registered, assigned bus number 2 ehci_hcd :00:02.1: irq 23, io mem 0xd0105000 PCI: cache line size of 64 is not supported by device :00:02.1 ehci_hcd :00:02.1: park 0 ehci_hcd :00:02.1: USB 2.0 initialized, EHCI 1.00, driver 10 Dec 2004 hub 2-0:1.0: USB hub found hub 2-0:1.0: 10 ports detected ACPI: PCI Interrupt Link [APCJ] enabled at IRQ 22 ACPI: PCI interrupt :00:04.0[A] -> GSI 22 (level, low) -> IRQ 22 PCI: Setting latency timer of device :00:04.0 to 64 intel8x0_measure_ac97_clock: measured 49642 usecs intel8x0: clocking to 46875 usb 1-1: new full speed USB device using ohci_hcd and address 3 usb 1-2: new low speed USB device using ohci_hcd and address 4 usb 1-10: new full speed USB device using ohci_hcd and address 5 cdc_acm 1-1:1.0: ttyACM0: USB ACM device usbcore: registered new driver cdc_acm drivers/usb/class/cdc-acm.c: v0.23:USB Abstract Control Model driver for USB modems and ISDN adapters usbcore: registered new driver hiddev input: USB HID v1.10 Mouse [B16_b_02 USB-PS/2 Optical Mouse] on usb-:00:02.0-2 usbcore: registered new driver usbhid drivers/usb/input/hid-core.c: v2.01:USB HID core driver Bluetooth: Core ver 2.7 NET: Registered protocol family 31 Bluetooth: HCI device and connection manager initialized Bluetooth: HCI socket layer initialized Bluetooth: HCI USB driver ver 2.8 usbcore: registered new driver hci_usb ieee1394: Initialized config rom entry `ip1394' ohci1394: $Rev: 1250 $ Ben Collins <[EMAIL PROTECTED]> ACPI: PCI Interrupt Link [APC1] enabled at IRQ 16 ACPI: PCI interrupt :05:0b.0[A] -> GSI 16 (level, low) -> IRQ 16 ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[16] MMIO=[d0004000-d00047ff] Max Packet=[2048] USB Universal Host Controller Interface driver v2.2 ieee1394: Host added: ID:BUS[0-00:1023] GUID[0011d80a00cc] eth1394: $Rev: 1247 $ Ben Collins <[EMAIL PROTECTED]> eth1394: eth1: IEEE-1394 IPv4 over 1394 Ethernet (fw-host0) You want to allocate a lot of memory (16 GB), you don't have that much space, so the Kernel hangs. Matthias-Christian Ott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AMD64 Machine hardlocks when using memset
, assigned bus number 2 ehci_hcd :00:02.1: irq 23, io mem 0xd0105000 PCI: cache line size of 64 is not supported by device :00:02.1 ehci_hcd :00:02.1: park 0 ehci_hcd :00:02.1: USB 2.0 initialized, EHCI 1.00, driver 10 Dec 2004 hub 2-0:1.0: USB hub found hub 2-0:1.0: 10 ports detected ACPI: PCI Interrupt Link [APCJ] enabled at IRQ 22 ACPI: PCI interrupt :00:04.0[A] - GSI 22 (level, low) - IRQ 22 PCI: Setting latency timer of device :00:04.0 to 64 intel8x0_measure_ac97_clock: measured 49642 usecs intel8x0: clocking to 46875 usb 1-1: new full speed USB device using ohci_hcd and address 3 usb 1-2: new low speed USB device using ohci_hcd and address 4 usb 1-10: new full speed USB device using ohci_hcd and address 5 cdc_acm 1-1:1.0: ttyACM0: USB ACM device usbcore: registered new driver cdc_acm drivers/usb/class/cdc-acm.c: v0.23:USB Abstract Control Model driver for USB modems and ISDN adapters usbcore: registered new driver hiddev input: USB HID v1.10 Mouse [B16_b_02 USB-PS/2 Optical Mouse] on usb-:00:02.0-2 usbcore: registered new driver usbhid drivers/usb/input/hid-core.c: v2.01:USB HID core driver Bluetooth: Core ver 2.7 NET: Registered protocol family 31 Bluetooth: HCI device and connection manager initialized Bluetooth: HCI socket layer initialized Bluetooth: HCI USB driver ver 2.8 usbcore: registered new driver hci_usb ieee1394: Initialized config rom entry `ip1394' ohci1394: $Rev: 1250 $ Ben Collins [EMAIL PROTECTED] ACPI: PCI Interrupt Link [APC1] enabled at IRQ 16 ACPI: PCI interrupt :05:0b.0[A] - GSI 16 (level, low) - IRQ 16 ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[16] MMIO=[d0004000-d00047ff] Max Packet=[2048] USB Universal Host Controller Interface driver v2.2 ieee1394: Host added: ID:BUS[0-00:1023] GUID[0011d80a00cc] eth1394: $Rev: 1247 $ Ben Collins [EMAIL PROTECTED] eth1394: eth1: IEEE-1394 IPv4 over 1394 Ethernet (fw-host0) You want to allocate a lot of memory (16 GB), you don't have that much space, so the Kernel hangs. Matthias-Christian Ott - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Do not misuse Coverity please (Was: sound/oss/cs46xx.c: fix a check after use)
Jean Delvare schrieb: Hi Adrian, There are two cases: 1. NULL is impossible, the check is superfluous 2. this was an actual bug Agreed. In the first case, my patch doesn't do any harm (a superfluous isn't a real bug). The fact that it isn't a bug does not imply that the patch doesn't harm. Tricking the reader into thinking that something can happen when it in fact cannot does possibly harm in the long run. In the second case, it fixed a bug. It might be a bug not many people hit because it might be in some error path of some esoteric driver. True, except that e.g. the sg_mmap() function of scsi/sg hardly falls into this category. Same for fbcon_init() in video/console/fbcon. You don't seem to treat core code any differently than esoteric drivers. If a maintainer of a well-maintained subsystem like i2c says "The check is superfluous." that's the perfect solution. But in less maintained parts of the kernel, even a low possibility that it fixes a possible bug is IMHO worth making such a riskless patch. This is where my opinion strongly differs. The very fact that these "check after use" cases were not fixed yet means that they are not hit frequently, if ever, regardless of how popular the driver is. This means that we have (relatively) plenty of time to fix them. At least Coverity or a similar tool will keep reminding us to take a look and decide what must be done after we carefully checked the code. Your approach will not let us do that. Mass-posting these patches here is likely to make them end in Andrew's tree soon and to Linus' right after that is nobody objects, right? If you can make sure that none of these patches ever reaches Linus' tree without their respective driver maintainer having confirmed that they were the right thing to do, then fine with me, but it doesn't look like the way things will go. I think that you'd be better just telling the maintainers about the problem without providing an arbitrary patch, so that they will actually look into the problem with their advanced knowledge of the driver, rather than merely ack'ing that the patch looks OK, which I think is what will happen with your method. (I'd love to be proven wrong though.) Thanks, Hi! I fully disagree with you opinion. 1. Adrian sent this patches to the LKML _and_ to their maintainers. So the patches can be proved by 2 instances and not Adrian has to do this (of course he has to filter non-sense patches (I think he did so)). 2. I don't know in which case NULL pointers are usefull, but it seems they're. 3. Not only Maintainers have knowledge about the driver and can decide whether a patch is useful or not (this hierarchical structure is outdated (it's adapeted from the middle ages and a reason why many developers (like me) don't want to waste their time on fixing little Kernel bugs (in most cases you have to resend your patch several times to get it appllied))). This only elongates the development time and is not necessary because as mentioned above it's sent to the LKML and the maintainers have subscribed the LKML and can give their comment here and not in a private discussion. Because of this I recommend everybody to use such tools and sent such patches, increasing the quality of the source and fixing problems like the problems Adrians patches fix, to the LKML. Matthias-Christian Ott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Do not misuse Coverity please (Was: sound/oss/cs46xx.c: fix a check after use)
Jean Delvare schrieb: Hi Adrian, There are two cases: 1. NULL is impossible, the check is superfluous 2. this was an actual bug Agreed. In the first case, my patch doesn't do any harm (a superfluous isn't a real bug). The fact that it isn't a bug does not imply that the patch doesn't harm. Tricking the reader into thinking that something can happen when it in fact cannot does possibly harm in the long run. In the second case, it fixed a bug. It might be a bug not many people hit because it might be in some error path of some esoteric driver. True, except that e.g. the sg_mmap() function of scsi/sg hardly falls into this category. Same for fbcon_init() in video/console/fbcon. You don't seem to treat core code any differently than esoteric drivers. If a maintainer of a well-maintained subsystem like i2c says The check is superfluous. that's the perfect solution. But in less maintained parts of the kernel, even a low possibility that it fixes a possible bug is IMHO worth making such a riskless patch. This is where my opinion strongly differs. The very fact that these check after use cases were not fixed yet means that they are not hit frequently, if ever, regardless of how popular the driver is. This means that we have (relatively) plenty of time to fix them. At least Coverity or a similar tool will keep reminding us to take a look and decide what must be done after we carefully checked the code. Your approach will not let us do that. Mass-posting these patches here is likely to make them end in Andrew's tree soon and to Linus' right after that is nobody objects, right? If you can make sure that none of these patches ever reaches Linus' tree without their respective driver maintainer having confirmed that they were the right thing to do, then fine with me, but it doesn't look like the way things will go. I think that you'd be better just telling the maintainers about the problem without providing an arbitrary patch, so that they will actually look into the problem with their advanced knowledge of the driver, rather than merely ack'ing that the patch looks OK, which I think is what will happen with your method. (I'd love to be proven wrong though.) Thanks, Hi! I fully disagree with you opinion. 1. Adrian sent this patches to the LKML _and_ to their maintainers. So the patches can be proved by 2 instances and not Adrian has to do this (of course he has to filter non-sense patches (I think he did so)). 2. I don't know in which case NULL pointers are usefull, but it seems they're. 3. Not only Maintainers have knowledge about the driver and can decide whether a patch is useful or not (this hierarchical structure is outdated (it's adapeted from the middle ages and a reason why many developers (like me) don't want to waste their time on fixing little Kernel bugs (in most cases you have to resend your patch several times to get it appllied))). This only elongates the development time and is not necessary because as mentioned above it's sent to the LKML and the maintainers have subscribed the LKML and can give their comment here and not in a private discussion. Because of this I recommend everybody to use such tools and sent such patches, increasing the quality of the source and fixing problems like the problems Adrians patches fix, to the LKML. Matthias-Christian Ott - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] FUSE: comments for dev.c
Miklos Szeredi schrieb: This adds lots of documentation to dev.c. This file is raised from least documented to most documented status. Signed-off-by: Miklos Szeredi <[EMAIL PROTECTED]> [ . . . ] Put such a big dicumentation to the documentation folder not in the code. Matthias-Christian Ott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] FUSE: comments for dev.c
Miklos Szeredi schrieb: This adds lots of documentation to dev.c. This file is raised from least documented to most documented status. Signed-off-by: Miklos Szeredi [EMAIL PROTECTED] [ . . . ] Put such a big dicumentation to the documentation folder not in the code. Matthias-Christian Ott - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Building server-farm
You'll can use OpenMosix (http://sourceforge.net/project/openmosix) or Mosix (http://www.mosix.org/). Have a look at: http://www.mini-itx.com/projects/cluster/ http://en.wikipedia.org/wiki/Beowulf_%28computing%29 http://de.wikipedia.org/wiki/BeowulfProject2004 (German, it describes howto setup a cluster) http://216.239.39.104/translate_c?hl=de=UTF-8=UTF-8=de%7Cen=http://de.wikipedia.org/wiki/BeowulfProject2004=/language_tools (Translation of the German Article) Matthias-Christian Ott On Mon, 14 Mar 2005, Wiktor wrote: Hi, I'm looking for a way to connect multiple linux systems into one big machine (server-farm) and I can't find any way of enabling it in kernel. Is this feature supported? If not, how can I build cluster from, let's say, 5 machines (I'm interestied in sharing of processes, memory, disk space and network interface). Thanks for replies. -- May the Source be with you Wiktor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Building server-farm
You'll can use OpenMosix (http://sourceforge.net/project/openmosix) or Mosix (http://www.mosix.org/). Have a look at: http://www.mini-itx.com/projects/cluster/ http://en.wikipedia.org/wiki/Beowulf_%28computing%29 http://de.wikipedia.org/wiki/BeowulfProject2004 (German, it describes howto setup a cluster) http://216.239.39.104/translate_c?hl=deie=UTF-8oe=UTF-8langpair=de%7Cenu=http://de.wikipedia.org/wiki/BeowulfProject2004prev=/language_tools (Translation of the German Article) Matthias-Christian Ott On Mon, 14 Mar 2005, Wiktor wrote: Hi, I'm looking for a way to connect multiple linux systems into one big machine (server-farm) and I can't find any way of enabling it in kernel. Is this feature supported? If not, how can I build cluster from, let's say, 5 machines (I'm interestied in sharing of processes, memory, disk space and network interface). Thanks for replies. -- May the Source be with you Wiktor - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Strange Linking Problem
linux-os wrote: On Sat, 12 Mar 2005, Matthias-Christian Ott wrote: Hi! I hope I'm right here. I've the following assembler code: SECTION .DATA hello: db 'Hello world!',10 helloLen: equ $-hello SECTION .TEXT GLOBAL main main: ; Write 'Hello world!' to the screen mov eax,4; 'write' system call mov ebx,1; file descriptor 1 = screen mov ecx,hello; string to write mov edx,helloLen ; length of string to write int 80h ; call the kernel ; Terminate program mov eax,1; 'exit' system call mov ebx,0; exit with error code 0 int 80h ; call the kernel Then I run: nasm -f elf hello.asm I link it with ld and run it: ld -s -o hello hello.o ./hello segmentation fault I link it with the gcc and run it: gcc hello.o -o hello ./hello Hello world! What's wrong with the ld? Nothing at all. Where is _start: ? Remove the 'main' label and substitute _start: It is 'C' convention that programs start with main(). They really don't. With the Linux API, they start at _start: and do some housekeeping before calling main. That's what the crt.o file that the 'C' tool-chain uses, does. Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. Ofcourse you have to edit it, but this is not the problem (the linker will give an error message if you don't change it). Why does it cause a segementation fault? Matthias-Christian Ott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Strange Linking Problem
linux-os wrote: On Sat, 12 Mar 2005, Matthias-Christian Ott wrote: Hi! I hope I'm right here. I've the following assembler code: SECTION .DATA hello: db 'Hello world!',10 helloLen: equ $-hello SECTION .TEXT GLOBAL main main: ; Write 'Hello world!' to the screen mov eax,4; 'write' system call mov ebx,1; file descriptor 1 = screen mov ecx,hello; string to write mov edx,helloLen ; length of string to write int 80h ; call the kernel ; Terminate program mov eax,1; 'exit' system call mov ebx,0; exit with error code 0 int 80h ; call the kernel Then I run: nasm -f elf hello.asm I link it with ld and run it: ld -s -o hello hello.o ./hello segmentation fault I link it with the gcc and run it: gcc hello.o -o hello ./hello Hello world! What's wrong with the ld? Nothing at all. Where is _start: ? Remove the 'main' label and substitute _start: It is 'C' convention that programs start with main(). They really don't. With the Linux API, they start at _start: and do some housekeeping before calling main. That's what the crt.o file that the 'C' tool-chain uses, does. Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. Ofcourse you have to edit it, but this is not the problem (the linker will give an error message if you don't change it). Why does it cause a segementation fault? Matthias-Christian Ott - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Strange Linking Problem
Hi! I hope I'm right here. I've the following assembler code: SECTION .DATA hello: db 'Hello world!',10 helloLen: equ $-hello SECTION .TEXT GLOBAL main main: ; Write 'Hello world!' to the screen mov eax,4; 'write' system call mov ebx,1; file descriptor 1 = screen mov ecx,hello; string to write mov edx,helloLen ; length of string to write int 80h ; call the kernel ; Terminate program mov eax,1; 'exit' system call mov ebx,0; exit with error code 0 int 80h ; call the kernel Then I run: nasm -f elf hello.asm I link it with ld and run it: ld -s -o hello hello.o ./hello segmentation fault I link it with the gcc and run it: gcc hello.o -o hello ./hello Hello world! What's wrong with the ld? Matthias-Christian Ott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Strange Linking Problem
Hi! I hope I'm right here. I've the following assembler code: SECTION .DATA hello: db 'Hello world!',10 helloLen: equ $-hello SECTION .TEXT GLOBAL main main: ; Write 'Hello world!' to the screen mov eax,4; 'write' system call mov ebx,1; file descriptor 1 = screen mov ecx,hello; string to write mov edx,helloLen ; length of string to write int 80h ; call the kernel ; Terminate program mov eax,1; 'exit' system call mov ebx,0; exit with error code 0 int 80h ; call the kernel Then I run: nasm -f elf hello.asm I link it with ld and run it: ld -s -o hello hello.o ./hello segmentation fault I link it with the gcc and run it: gcc hello.o -o hello ./hello Hello world! What's wrong with the ld? Matthias-Christian Ott - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pci_find_class obsolete
Jan Engelhardt wrote:
Hello list,
after switching to 2.6.11-rc5-bk2 (from 2.6.9-rc2), I found that the nvidia
module (1.0-4996, old, I know) does not compile anymore, because it
requires pci_find_class():
nv.c:
static int
nvos_probe_devices(void)
{
...
struct pci_dev *dev;
...
dev = pci_find_class(PCI_CLASS_DISPLAY_VGA << 8, dev);
...
}
What function would I need to use, now that pci_find_class is gone?
Jan Engelhardt
Hi!
you have to use pci_get_class (). But have a look at the patches for
6111 on my webiste:
http://unixforge.org/~matthias-christian-ott/index.php?entry=entry050303-082233
Matthias-Christian Ott
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: pci_find_class obsolete
Jan Engelhardt wrote:
Hello list,
after switching to 2.6.11-rc5-bk2 (from 2.6.9-rc2), I found that the nvidia
module (1.0-4996, old, I know) does not compile anymore, because it
requires pci_find_class():
nv.c:
static int
nvos_probe_devices(void)
{
...
struct pci_dev *dev;
...
dev = pci_find_class(PCI_CLASS_DISPLAY_VGA 8, dev);
...
}
What function would I need to use, now that pci_find_class is gone?
Jan Engelhardt
Hi!
you have to use pci_get_class (). But have a look at the patches for
6111 on my webiste:
http://unixforge.org/~matthias-christian-ott/index.php?entry=entry050303-082233
Matthias-Christian Ott
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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] config option for default loglevel
Matthias Kunze wrote: Hi, I've created a little patch to make the default loglevel a configurable option. Is there a chance that this patch will be included in a future release? diff -Naur linux-2.6.10/drivers/video/console/Kconfig linux-2.6.10-new/drivers/video/console/Kconfig --- linux-2.6.10/drivers/video/console/Kconfig 2004-12-24 22:34:26.0 +0100 +++ linux-2.6.10-new/drivers/video/console/Kconfig 2005-02-26 17:11:03.0 +0100 @@ -186,5 +186,25 @@ big letters (like the letters used in the SPARC PROM). If the standard font is unreadable for you, say Y, otherwise say N. +config DEFAULT_CONSOLE_LOGLEVEL +int "Default Console Loglevel" +range 1 8 +default 7 +help + All Kernel Messages with a loglevel smaller than the console loglevel + will be printed to the console. This value can later be changed with + klogd or other programs. The loglevels are defined as follows: + + 0 (KERN_EMERG)system is unusable + 1 (KERN_ALERT)action must be taken immediately + 2 (KERN_CRIT) critical conditions + 3 (KERN_ERR) error conditions + 4 (KERN_WARNING) warning conditions + 5 (KERN_NOTICE) normal but significant condition + 6 (KERN_INFO) informational + 7 (KERN_DEBUG)debug-level messages + + The console loglevel can be set to a value in the range from 1 to 8. + endmenu diff -Naur linux-2.6.10/kernel/printk.c linux-2.6.10-new/kernel/printk.c --- linux-2.6.10/kernel/printk.c2005-02-26 16:49:03.0 +0100 +++ linux-2.6.10-new/kernel/printk.c2005-02-26 17:32:09.0 +0100 @@ -41,7 +41,7 @@ /* We show everything that is MORE important than this.. */ #define MINIMUM_CONSOLE_LOGLEVEL 1 /* Minimum loglevel we let people use */ -#define DEFAULT_CONSOLE_LOGLEVEL 7 /* anything MORE serious than KERN_DEBUG */ +#define DEFAULT_CONSOLE_LOGLEVEL CONFIG_DEFAULT_CONSOLE_LOGLEVEL DECLARE_WAIT_QUEUE_HEAD(log_wait); --- Matthias Kunze http://elpp.foofighter.de - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Hi! I think this patch is useful and should be included in further Kernel releases. Matthias-Christian Ott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] config option for default loglevel
Matthias Kunze wrote: Hi, I've created a little patch to make the default loglevel a configurable option. Is there a chance that this patch will be included in a future release? diff -Naur linux-2.6.10/drivers/video/console/Kconfig linux-2.6.10-new/drivers/video/console/Kconfig --- linux-2.6.10/drivers/video/console/Kconfig 2004-12-24 22:34:26.0 +0100 +++ linux-2.6.10-new/drivers/video/console/Kconfig 2005-02-26 17:11:03.0 +0100 @@ -186,5 +186,25 @@ big letters (like the letters used in the SPARC PROM). If the standard font is unreadable for you, say Y, otherwise say N. +config DEFAULT_CONSOLE_LOGLEVEL +int Default Console Loglevel +range 1 8 +default 7 +help + All Kernel Messages with a loglevel smaller than the console loglevel + will be printed to the console. This value can later be changed with + klogd or other programs. The loglevels are defined as follows: + + 0 (KERN_EMERG)system is unusable + 1 (KERN_ALERT)action must be taken immediately + 2 (KERN_CRIT) critical conditions + 3 (KERN_ERR) error conditions + 4 (KERN_WARNING) warning conditions + 5 (KERN_NOTICE) normal but significant condition + 6 (KERN_INFO) informational + 7 (KERN_DEBUG)debug-level messages + + The console loglevel can be set to a value in the range from 1 to 8. + endmenu diff -Naur linux-2.6.10/kernel/printk.c linux-2.6.10-new/kernel/printk.c --- linux-2.6.10/kernel/printk.c2005-02-26 16:49:03.0 +0100 +++ linux-2.6.10-new/kernel/printk.c2005-02-26 17:32:09.0 +0100 @@ -41,7 +41,7 @@ /* We show everything that is MORE important than this.. */ #define MINIMUM_CONSOLE_LOGLEVEL 1 /* Minimum loglevel we let people use */ -#define DEFAULT_CONSOLE_LOGLEVEL 7 /* anything MORE serious than KERN_DEBUG */ +#define DEFAULT_CONSOLE_LOGLEVEL CONFIG_DEFAULT_CONSOLE_LOGLEVEL DECLARE_WAIT_QUEUE_HEAD(log_wait); --- Matthias Kunze http://elpp.foofighter.de - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Hi! I think this patch is useful and should be included in further Kernel releases. Matthias-Christian Ott - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB 2.0 Mass storage device
Greg KH wrote: On Thu, Feb 24, 2005 at 08:18:09PM +0100, Lukas Hejtmanek wrote: On Thu, Feb 24, 2005 at 11:12:43AM -0800, Greg KH wrote: When connected through uhci-hcd: T: Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 Your device is only reporting that it can go at 12Mbit (full speed, not 480Mbit, which is high speed.) Is this independent of used driver? Yes, this is read from the descriptor of the device. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ But why does the usb mass storage give this information to the usb driver? Shouldn't it report that it works with 480Mbit too? Matthias-Christian Ott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB 2.0 Mass storage device
Lukas Hejtmanek wrote: Hello, I have a new MSI Mega Stick 511 USB 2.0 Mass storage device. In my laptop I have USB 2.0 port (Acer TM242), when I connect device, only uhci_hcd driver detect device. Does anyone have some suggestions? Thanks. Hi! Is hotplug enabled (it should detect it as a scsi generic mass storage)? Matthias-Christian Ott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.11-rc5
Matt Mackall wrote: On Wed, Feb 23, 2005 at 08:18:08PM -0800, Linus Torvalds wrote: Hey, I hoped -rc4 was the last one, but we had some laptop resource conflicts, various ppc TLB flush issues, some possible stack overflows in networking and a number of other details warranting a quick -rc5 before the final 2.6.11. This time it's really supposed to be a quickie, so people who can, please check it out, and we'll make the real 2.6.11 asap. Mostly pretty small changes (the largest is a new SATA driver that crept in, our bad). But worth another quick round. Very small. [ ] patch-2.6.11-rc5.bz2 23-Feb-2005 20:20 14 [ ] patch-2.6.11-rc5.bz2.sign 23-Feb-2005 20:20 248 [ ] patch-2.6.11-rc5.gz23-Feb-2005 20:20 37 [ ] patch-2.6.11-rc5.gz.sign 23-Feb-2005 20:20 248 [ ] patch-2.6.11-rc5.sign 23-Feb-2005 20:20 248 Seems to have passed the gpg signature test on my end. The file seems to be empty. Matthias-Christian Ott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.11-rc5
Matt Mackall wrote: On Wed, Feb 23, 2005 at 08:18:08PM -0800, Linus Torvalds wrote: Hey, I hoped -rc4 was the last one, but we had some laptop resource conflicts, various ppc TLB flush issues, some possible stack overflows in networking and a number of other details warranting a quick -rc5 before the final 2.6.11. This time it's really supposed to be a quickie, so people who can, please check it out, and we'll make the real 2.6.11 asap. Mostly pretty small changes (the largest is a new SATA driver that crept in, our bad). But worth another quick round. Very small. [ ] patch-2.6.11-rc5.bz2 23-Feb-2005 20:20 14 [ ] patch-2.6.11-rc5.bz2.sign 23-Feb-2005 20:20 248 [ ] patch-2.6.11-rc5.gz23-Feb-2005 20:20 37 [ ] patch-2.6.11-rc5.gz.sign 23-Feb-2005 20:20 248 [ ] patch-2.6.11-rc5.sign 23-Feb-2005 20:20 248 Seems to have passed the gpg signature test on my end. The file seems to be empty. Matthias-Christian Ott - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB 2.0 Mass storage device
Lukas Hejtmanek wrote: Hello, I have a new MSI Mega Stick 511 USB 2.0 Mass storage device. In my laptop I have USB 2.0 port (Acer TM242), when I connect device, only uhci_hcd driver detect device. Does anyone have some suggestions? Thanks. Hi! Is hotplug enabled (it should detect it as a scsi generic mass storage)? Matthias-Christian Ott - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB 2.0 Mass storage device
Greg KH wrote: On Thu, Feb 24, 2005 at 08:18:09PM +0100, Lukas Hejtmanek wrote: On Thu, Feb 24, 2005 at 11:12:43AM -0800, Greg KH wrote: When connected through uhci-hcd: T: Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 Your device is only reporting that it can go at 12Mbit (full speed, not 480Mbit, which is high speed.) Is this independent of used driver? Yes, this is read from the descriptor of the device. thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ But why does the usb mass storage give this information to the usb driver? Shouldn't it report that it works with 480Mbit too? Matthias-Christian Ott - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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.11-rc4-RT-V0.7.39-02 kernel BUG
d+0x94/0xc8 (28) [] kthread+0x0/0xc8 (16) [] kernel_thread_helper+0x5/0xb (16) Code: 8b 6c 24 18 83 c4 1c c3 b8 da ff ff ff c3 90 90 c3 55 39 ca 89 c5 57 89 c8 56 53 74 49 8b 8a f8 04 00 00 8d ba f8 04 00 00 39 cf <8b> 19 74 37 8d b0 f8 04 00 00 eb 08 89 d9 8b 1b 39 cf 74 27 39 <6>note: IRQ 10[1439] exited with preempt_count 3 BUG: scheduling while atomic: IRQ 10/0x0003/1439 caller is do_exit+0x1da/0x34d [] __sched_text_start+0x48e/0x5d7 (8) [] exit_notify+0x60b/0x8f4 (24) [] vprintk+0x101/0x142 (24) [] do_exit+0x1da/0x34d (32) [] do_trap+0x0/0xfe (40) [] do_page_fault+0x0/0x524 (48) [] do_page_fault+0x0/0x524 (12) [] do_page_fault+0x346/0x524 (4) [] preempt_schedule+0x50/0x6b (80) [] try_to_wake_up+0x104/0x106 (20) [] dma_trm_reset+0x36/0x11e [ohci1394] (24) [] __wake_up_common+0x35/0x55 (16) [] do_page_fault+0x0/0x524 (60) [] error_code+0x2b/0x30 (8) [] change_owner+0x1a/0x5a (44) [] set_new_owner+0x17/0x2b (28) [] __up_mutex+0xa4/0x193 (12) [] up+0x35/0x3d (36) [] highlevel_host_reset+0x3b/0x49 [ieee1394] (8) [] ohci_irq_handler+0x576/0x713 [ohci1394] (12) [] __sched_text_start+0x5a/0x5d7 (28) [] __do_IRQ+0xca/0x180 (4) [] handle_IRQ_event+0x5c/0xc8 (36) [] do_hardirq+0x61/0x112 (48) [] do_sched_setscheduler+0x73/0xa0 (4) [] do_irqd+0x0/0x96 (20) [] do_irqd+0x66/0x96 (4) [] kthread+0x94/0xc8 (28) [] kthread+0x0/0xc8 (16) [] kernel_thread_helper+0x5/0xb (16) prev->state: 2 != TASK_RUNNING?? IRQ 10/1439: BUG in __schedule at kernel/sched.c:3028 [] __sched_text_start+0x3fd/0x5d7 (8) [] do_exit+0x1da/0x34d (80) [] do_trap+0x0/0xfe (40) [] do_page_fault+0x0/0x524 (48) [] do_page_fault+0x0/0x524 (12) [] do_page_fault+0x346/0x524 (4) [] preempt_schedule+0x50/0x6b (80) [] try_to_wake_up+0x104/0x106 (20) [] dma_trm_reset+0x36/0x11e [ohci1394] (24) [] __wake_up_common+0x35/0x55 (16) [] do_page_fault+0x0/0x524 (60) [] error_code+0x2b/0x30 (8) [] change_owner+0x1a/0x5a (44) [] set_new_owner+0x17/0x2b (28) [] __up_mutex+0xa4/0x193 (12) [] up+0x35/0x3d (36) [] highlevel_host_reset+0x3b/0x49 [ieee1394] (8) [] ohci_irq_handler+0x576/0x713 [ohci1394] (12) [] __sched_text_start+0x5a/0x5d7 (28) [] __do_IRQ+0xca/0x180 (4) [] handle_IRQ_event+0x5c/0xc8 (36) [] do_hardirq+0x61/0x112 (48) [] do_sched_setscheduler+0x73/0xa0 (4) [] do_irqd+0x0/0x96 (20) [] do_irqd+0x66/0x96 (4) [] kthread+0x94/0xc8 (28) [] kthread+0x0/0xc8 (16) [] kernel_thread_helper+0x5/0xb (16) Linux Kernel Card Services options: [pci] [cardbus] [pm] PCI: Enabling device :00:0a.0 (0005 -> 0007) ACPI: PCI Interrupt Link [LNK5] enabled at IRQ 11 PCI: setting IRQ 11 as level-triggered ACPI: PCI interrupt :00:0a.0[A] -> GSI 11 (level, low) -> IRQ 11 Yenta: CardBus bridge found at :00:0a.0 [103c:0850] Yenta O2: res at 0x94/0xD4: 00/ea Yenta O2: enabling read prefetch/write burst Yenta: ISA IRQ mask 0x00b8, PCI irq 11 Socket status: 3007 cs: IO port probe 0xc00-0xcff: clean. cs: IO port probe 0x100-0x4ff: excluding 0x408-0x40f 0x480-0x48f 0x4d0-0x4d7 cs: IO port probe 0xa00-0xaff: clean. prism2_cs: Ignoring new-style parameters in presence of obsolete ones prism2cs_init: prism2_cs.o: 0.2.1-pre26 Loaded prism2cs_init: dev_info is: prism2_cs PCI: Enabling device :00:06.0 (0005 -> 0007) ACPI: PCI Interrupt Link [LNK7] enabled at IRQ 5 PCI: setting IRQ 5 as level-triggered ACPI: PCI interrupt :00:06.0[A] -> GSI 5 (level, low) -> IRQ 5 usbcore: registered new driver snd-usb-usx2y Realtime LSM initialized (group 81, mlock=1) mtrr: no more MTRRs available Hi! The first bug is in the usbb ohci module (report it to http://buzilla.kernel.org and its Maintainers). The second one is caused by the first one. Matthias-Christian Ott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.11-rc4-RT-V0.7.39-02 kernel BUG
0001 de55a4d4 e00b0bf6 0001 0017 Call Trace: [c0127b5c] set_new_owner+0x17/0x2b (20) [c0127d31] __up_mutex+0xa4/0x193 (12) [c01283f5] up+0x35/0x3d (36) [e00c2cb0] highlevel_host_reset+0x3b/0x49 [ieee1394] (8) [e00b0bf6] ohci_irq_handler+0x576/0x713 [ohci1394] (12) [c029ec06] __sched_text_start+0x5a/0x5d7 (28) [c012d77a] __do_IRQ+0xca/0x180 (4) [c012d634] handle_IRQ_event+0x5c/0xc8 (36) [c012dd86] do_hardirq+0x61/0x112 (48) [c0110dbd] do_sched_setscheduler+0x73/0xa0 (4) [c012de37] do_irqd+0x0/0x96 (20) [c012de9d] do_irqd+0x66/0x96 (4) [c0127018] kthread+0x94/0xc8 (28) [c0126f84] kthread+0x0/0xc8 (16) [c0100791] kernel_thread_helper+0x5/0xb (16) Code: 8b 6c 24 18 83 c4 1c c3 b8 da ff ff ff c3 90 90 c3 55 39 ca 89 c5 57 89 c8 56 53 74 49 8b 8a f8 04 00 00 8d ba f8 04 00 00 39 cf 8b 19 74 37 8d b0 f8 04 00 00 eb 08 89 d9 8b 1b 39 cf 74 27 39 6note: IRQ 10[1439] exited with preempt_count 3 BUG: scheduling while atomic: IRQ 10/0x0003/1439 caller is do_exit+0x1da/0x34d [c029f03a] __sched_text_start+0x48e/0x5d7 (8) [c01163bb] exit_notify+0x60b/0x8f4 (24) [c01148fc] vprintk+0x101/0x142 (24) [c011687e] do_exit+0x1da/0x34d (32) [c010349f] do_trap+0x0/0xfe (40) [c010e8fc] do_page_fault+0x0/0x524 (48) [c010e8fc] do_page_fault+0x0/0x524 (12) [c010ec42] do_page_fault+0x346/0x524 (4) [c029f2ea] preempt_schedule+0x50/0x6b (80) [c010fcdb] try_to_wake_up+0x104/0x106 (20) [e00b0516] dma_trm_reset+0x36/0x11e [ohci1394] (24) [c01106ab] __wake_up_common+0x35/0x55 (16) [c010e8fc] do_page_fault+0x0/0x524 (60) [c0102d57] error_code+0x2b/0x30 (8) [c0127927] change_owner+0x1a/0x5a (44) [c0127b5c] set_new_owner+0x17/0x2b (28) [c0127d31] __up_mutex+0xa4/0x193 (12) [c01283f5] up+0x35/0x3d (36) [e00c2cb0] highlevel_host_reset+0x3b/0x49 [ieee1394] (8) [e00b0bf6] ohci_irq_handler+0x576/0x713 [ohci1394] (12) [c029ec06] __sched_text_start+0x5a/0x5d7 (28) [c012d77a] __do_IRQ+0xca/0x180 (4) [c012d634] handle_IRQ_event+0x5c/0xc8 (36) [c012dd86] do_hardirq+0x61/0x112 (48) [c0110dbd] do_sched_setscheduler+0x73/0xa0 (4) [c012de37] do_irqd+0x0/0x96 (20) [c012de9d] do_irqd+0x66/0x96 (4) [c0127018] kthread+0x94/0xc8 (28) [c0126f84] kthread+0x0/0xc8 (16) [c0100791] kernel_thread_helper+0x5/0xb (16) prev-state: 2 != TASK_RUNNING?? IRQ 10/1439: BUG in __schedule at kernel/sched.c:3028 [c029efa9] __sched_text_start+0x3fd/0x5d7 (8) [c011687e] do_exit+0x1da/0x34d (80) [c010349f] do_trap+0x0/0xfe (40) [c010e8fc] do_page_fault+0x0/0x524 (48) [c010e8fc] do_page_fault+0x0/0x524 (12) [c010ec42] do_page_fault+0x346/0x524 (4) [c029f2ea] preempt_schedule+0x50/0x6b (80) [c010fcdb] try_to_wake_up+0x104/0x106 (20) [e00b0516] dma_trm_reset+0x36/0x11e [ohci1394] (24) [c01106ab] __wake_up_common+0x35/0x55 (16) [c010e8fc] do_page_fault+0x0/0x524 (60) [c0102d57] error_code+0x2b/0x30 (8) [c0127927] change_owner+0x1a/0x5a (44) [c0127b5c] set_new_owner+0x17/0x2b (28) [c0127d31] __up_mutex+0xa4/0x193 (12) [c01283f5] up+0x35/0x3d (36) [e00c2cb0] highlevel_host_reset+0x3b/0x49 [ieee1394] (8) [e00b0bf6] ohci_irq_handler+0x576/0x713 [ohci1394] (12) [c029ec06] __sched_text_start+0x5a/0x5d7 (28) [c012d77a] __do_IRQ+0xca/0x180 (4) [c012d634] handle_IRQ_event+0x5c/0xc8 (36) [c012dd86] do_hardirq+0x61/0x112 (48) [c0110dbd] do_sched_setscheduler+0x73/0xa0 (4) [c012de37] do_irqd+0x0/0x96 (20) [c012de9d] do_irqd+0x66/0x96 (4) [c0127018] kthread+0x94/0xc8 (28) [c0126f84] kthread+0x0/0xc8 (16) [c0100791] kernel_thread_helper+0x5/0xb (16) Linux Kernel Card Services options: [pci] [cardbus] [pm] PCI: Enabling device :00:0a.0 (0005 - 0007) ACPI: PCI Interrupt Link [LNK5] enabled at IRQ 11 PCI: setting IRQ 11 as level-triggered ACPI: PCI interrupt :00:0a.0[A] - GSI 11 (level, low) - IRQ 11 Yenta: CardBus bridge found at :00:0a.0 [103c:0850] Yenta O2: res at 0x94/0xD4: 00/ea Yenta O2: enabling read prefetch/write burst Yenta: ISA IRQ mask 0x00b8, PCI irq 11 Socket status: 3007 cs: IO port probe 0xc00-0xcff: clean. cs: IO port probe 0x100-0x4ff: excluding 0x408-0x40f 0x480-0x48f 0x4d0-0x4d7 cs: IO port probe 0xa00-0xaff: clean. prism2_cs: Ignoring new-style parameters in presence of obsolete ones prism2cs_init: prism2_cs.o: 0.2.1-pre26 Loaded prism2cs_init: dev_info is: prism2_cs PCI: Enabling device :00:06.0 (0005 - 0007) ACPI: PCI Interrupt Link [LNK7] enabled at IRQ 5 PCI: setting IRQ 5 as level-triggered ACPI: PCI interrupt :00:06.0[A] - GSI 5 (level, low) - IRQ 5 usbcore: registered new driver snd-usb-usx2y Realtime LSM initialized (group 81, mlock=1) mtrr: no more MTRRs available Hi! The first bug is in the usbb ohci module (report it to http://buzilla.kernel.org and its Maintainers). The second one is caused by the first one. Matthias-Christian Ott - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with 2.6.11-rc4, Opteron server and MPTBase
Weathers, Norman R. wrote:
To all whom it may concern:
I am having trouble with several of the 2.6 kernels. The last one is
the one that is perhaps most annoying.
I have a dual Opteron based NFS server that keeps crashing when I try to
boot up with 2.6.11-rc4.
The node is trying to boot from an mptbase device, and it is also
loading modules for a qlogic fiber card (module is qla2300, qla2xxx, and
the scsi_transport_fc). Now, as it is scanning the drives, it does a
perfect impersonation of a dying duck and crashes.
Here is the output from the crash:'
Fusion MPT base driver 3.01.18
Loading scsi_modCopyright (c) 1999-2004 LSI Logic Corporation
.ko module
Loadmptbase: Initiating ioc0 bringup
ing sd_mod.ko module
Loading mptbase.ko module
ioc0: 53C1030: Capabilities={Initiator}
Unable to handle kernel paging request at 25b0 RIP:
{vmalloc_fault+557}
PGD 821ad067 PUD 2c50067 PMD 0
Oops: [1] SMP
CPU 0
Modules linked in: mptbase sd_mod scsi_mod
Pid: 0, comm: swapper Not tainted 2.6.11-rc4
RIP: 0010:[] {vmalloc_fault+557}
RSP: :80455230 EFLAGS: 00010212
RAX: 000fe050 RBX: 0001 RCX: 0018
RDX: RSI: 03fff000 RDI: 3fff
RBP: R08: 8100fba3c000 R09: fba3c000
R10: 0008 R11: 810081b44760 R12: 80455338
R13: 0003 R14: c244 R15:
FS: () GS:804c1800()
knlGS:
CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b
CR2: 25b0 CR3: 02c58000 CR4: 06e0
Process swapper (pid: 0, threadinfo 804c8000, task
80358380)
Stack: 801207ce 0001 0001
80455278
80358380 80455338 80317933
000b000e 0082
Call Trace: {do_page_fault+238}
{autoremove
_wake_function+9}
{__wake_up_common+67}
{error_exit+0}
{:mptbase:mpt_interrupt+45}
{update_wall_
time+9}
{handle_IRQ_event+44}
{__do_IRQ+222}
{do_IRQ+66} {ret_from_intr+0}
{thread_return+42}
{default_idle+0
}
{default_idle+36}
{cpu_idle+58}
{start_kernel+416}
{x86_64_start_kernel+4
04}
Code: 48 2b 82 b0 25 00 00 48 8d 34 c5 00 00 00 00 48 29 c6 48 8b
RIP {vmalloc_fault+557} RSP
CR2: 25b0
<0>Kernel panic - not syncing: Aiee, killing interrupt handler!
Has anyone seen this in this kernel? 2.6.7 - 2.6.10 has not had a
problem booting, but there has been other problems that are forcing us
to move up to a newer kernel (2.6.7 has stability issues, 2.6.9 had some
interesting issues with our IBM servers and USB keyboards (complete
lockups), and I had problems with kswapd on 2.6.7 - 2.6.10).
Thanks for any help you may be able to shed on this problem. Please CC
me. I was on the kernel list, but I think my company has blocked that
email due to the volume of the traffic.
Norman Weathers
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Hi!
Did you change some configuration options or did add/remove hardware?
Matthias-Christian Ott
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with 2.6.11-rc4, Opteron server and MPTBase
Weathers, Norman R. wrote:
To all whom it may concern:
I am having trouble with several of the 2.6 kernels. The last one is
the one that is perhaps most annoying.
I have a dual Opteron based NFS server that keeps crashing when I try to
boot up with 2.6.11-rc4.
The node is trying to boot from an mptbase device, and it is also
loading modules for a qlogic fiber card (module is qla2300, qla2xxx, and
the scsi_transport_fc). Now, as it is scanning the drives, it does a
perfect impersonation of a dying duck and crashes.
Here is the output from the crash:'
Fusion MPT base driver 3.01.18
Loading scsi_modCopyright (c) 1999-2004 LSI Logic Corporation
.ko module
Loadmptbase: Initiating ioc0 bringup
ing sd_mod.ko module
Loading mptbase.ko module
ioc0: 53C1030: Capabilities={Initiator}
Unable to handle kernel paging request at 25b0 RIP:
8012064d{vmalloc_fault+557}
PGD 821ad067 PUD 2c50067 PMD 0
Oops: [1] SMP
CPU 0
Modules linked in: mptbase sd_mod scsi_mod
Pid: 0, comm: swapper Not tainted 2.6.11-rc4
RIP: 0010:[8012064d] 8012064d{vmalloc_fault+557}
RSP: :80455230 EFLAGS: 00010212
RAX: 000fe050 RBX: 0001 RCX: 0018
RDX: RSI: 03fff000 RDI: 3fff
RBP: R08: 8100fba3c000 R09: fba3c000
R10: 0008 R11: 810081b44760 R12: 80455338
R13: 0003 R14: c244 R15:
FS: () GS:804c1800()
knlGS:
CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b
CR2: 25b0 CR3: 02c58000 CR4: 06e0
Process swapper (pid: 0, threadinfo 804c8000, task
80358380)
Stack: 801207ce 0001 0001
80455278
80358380 80455338 80317933
000b000e 0082
Call Trace:IRQ 801207ce{do_page_fault+238}
8014c179{autoremove
_wake_function+9}
80131d83{__wake_up_common+67}
8010eddd{error_exit+0}
8802c02d{:mptbase:mpt_interrupt+45}
8013fbd9{update_wall_
time+9}
8015777c{handle_IRQ_event+44}
8015788e{__do_IRQ+222}
80111392{do_IRQ+66} 8010e981{ret_from_intr+0}
EOI 802f7c4a{thread_return+42}
8010c420{default_idle+0
}
8010c444{default_idle+36}
8010c58a{cpu_idle+58}
804ca910{start_kernel+416}
804ca294{x86_64_start_kernel+4
04}
Code: 48 2b 82 b0 25 00 00 48 8d 34 c5 00 00 00 00 48 29 c6 48 8b
RIP 8012064d{vmalloc_fault+557} RSP 80455230
CR2: 25b0
0Kernel panic - not syncing: Aiee, killing interrupt handler!
Has anyone seen this in this kernel? 2.6.7 - 2.6.10 has not had a
problem booting, but there has been other problems that are forcing us
to move up to a newer kernel (2.6.7 has stability issues, 2.6.9 had some
interesting issues with our IBM servers and USB keyboards (complete
lockups), and I had problems with kswapd on 2.6.7 - 2.6.10).
Thanks for any help you may be able to shed on this problem. Please CC
me. I was on the kernel list, but I think my company has blocked that
email due to the volume of the traffic.
Norman Weathers
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Hi!
Did you change some configuration options or did add/remove hardware?
Matthias-Christian Ott
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: proc path_walk glitch ?
Der Herr Hofrat wrote:
HI !
I noticed a slight proc filesystem strangness in the 2.4.2X and 2.6.X
(atleast up to 2.6.8). Assuming that process 8655 exists and is running
long enough (ls -lR / or so)
cd /proc/8655
kill -9 8655
ls
/usr/bin/ls: .: Stale NFS file handle
open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = -1 ESTALE (Stale NFS file
handle) from fs/namei.c -> link_path_walk :
int fastcall link_path_walk(const char * name, struct nameidata *nd)
{
struct dentry *dentry;
struct inode *inode;
int err;
unsigned int lookup_flags = nd->flags;
while (*name=='/')
name++;
if (!*name)
goto return_reval;
...
return_reval:
/*
* We bypassed the ordinary revalidation routines.
* Check the cached dentry for staleness.
*/
dentry = nd->dentry;
if (dentry && dentry->d_op && dentry->d_op->d_revalidate) {
err = -ESTALE;
if (!dentry->d_op->d_revalidate(dentry, 0)) {
d_invalidate(dentry);
break;
}
}
Why does return_reval return -ESTALE instead of -ENOENT here - might need an
extra check on what filesystem this is working on ?
/usr/bin/ls: .: no such file or directory
would seem more meaningfull to me when I find it in a logfile.
thx !
hofrat
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Does it happen in 2.6.10 or are you sing 2.6.8?
Matthias-Christian Ott
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Panic in 2.6.11-rc4
0x427/0x510 [] avc_has_perm_noaudit+0x92/0x140 [] file_read_actor+0x0/0xf0 [] __generic_file_aio_read+0x1f4/0x230 [] file_read_actor+0x0/0xf0 [] generic_file_read+0x95/0xb0 [] autoremove_wake_function+0x0/0x50 [] block_llseek+0x27/0xf0 [] vfs_read+0xc3/0x130 [] sys_read+0x47/0x80 [] sysenter_past_esp+0x52/0x75 scheduling while atomic: linuxrc/0x0002/392 [] schedule+0xb52/0xb60 [] prepare_to_wait+0x20/0x70 [] flush_cpu_workqueue+0x9a/0x1b0 [] invalidate_inode_buffers+0x15/0x90 [] autoremove_wake_function+0x0/0x50 [] autoremove_wake_function+0x0/0x50 [] flush_workqueue+0x62/0xa0 [] release_dev+0x505/0x7c0 [] free_hot_cold_page+0xe9/0x140 [] __pagevec_free+0x1c/0x30 [] release_pages+0x5c/0x150 [] lock_kernel+0x28/0x40 [] invalidate_inode_buffers+0x15/0x90 [] tty_release+0xf/0x20 [] __fput+0x146/0x160 [] filp_close+0x4f/0x80 [] put_files_struct+0x61/0xb0 [] do_exit+0xd1/0x360 [] die+0x179/0x180 [] do_page_fault+0x2d9/0x56a [] autoremove_wake_function+0x0/0x50 [] mempool_alloc+0x76/0x150 [] cache_grow+0x105/0x130 [] submit_bio+0x57/0xe0 [] autoremove_wake_function+0x0/0x50 [] do_page_fault+0x0/0x56a [] error_code+0x2b/0x30 [] cache_alloc_refill+0x20e/0x240 [] kmem_cache_alloc+0x50/0x70 [] __scsi_get_command+0x23/0x80 [scsi_mod] [] scsi_get_command+0x31/0xf0 [scsi_mod] [] scsi_prep_fn+0x133/0x1e0 [scsi_mod] [] elv_next_request+0x4c/0xf0 [] blk_remove_plug+0x3b/0x70 [] __generic_unplug_device+0x22/0x30 [] generic_unplug_device+0x15/0x30 [] blk_backing_dev_unplug+0x0/0x20 [] blk_backing_dev_unplug+0x12/0x20 [] block_sync_page+0x36/0x40 [] sync_page+0x3c/0x50 [] __wait_on_bit_lock+0x5b/0x70 [] sync_page+0x0/0x50 [] wake_bit_function+0x0/0x60 [] __lock_page+0x90/0xa0 [] wake_bit_function+0x0/0x60 [] wake_bit_function+0x0/0x60 [] _spin_unlock_irq+0x20/0x40 [] do_generic_mapping_read+0x427/0x510 [] avc_has_perm_noaudit+0x92/0x140 [] file_read_actor+0x0/0xf0 [] __generic_file_aio_read+0x1f4/0x230 [] file_read_actor+0x0/0xf0 [] generic_file_read+0x95/0xb0 [] autoremove_wake_function+0x0/0x50 [] block_llseek+0x27/0xf0 [] vfs_read+0xc3/0x130 [] sys_read+0x47/0x80 [] sysenter_past_esp+0x52/0x75 Hi! The first one is allocation error (linuxrc wants to get/read memory, but the allocation fails?). The other errors are _maybe_ caused by the first error (the scheduler schedules while a atomic operation is in progress). Is your Kernel configuration different to the configuration of the Fedora Kernel? If so: What did you change? It's strange that you can't change you Bios settings. Is the write protection jumper set to 1 (TRUE/ENABLED)? Is your Bios up2date? Matthias-Christian Ott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.11rc4: irq 5, nobody cared
Rogério Brito wrote: On Feb 20 2005, Matthias-Christian Ott wrote: Rogério Brito wrote: I am willing to test any patch and configuration (let's call me a "guinea pig"), but I don't know what I should do. I have, OTOH, reported my problem many times in the past few days. :-( I will retry sending my message to the list once again, with the details (in my case, the message I get is "irq 10: nobody cared!" and it is regarding my primary HD on my secondary Promise PDC20265 controller). First of all, Matthias-Christian, thank you very much for your kind answer. I have already tried contacting the linux-ide mailing list as a CC to my earlier messages, but I got no response. I am including some details in this e-mail. I included Bartlomiej in the CC, as he is listed as general IDE maintainer in the MAINTAINERS file. Report it to http://bugzilla.kernel.org/. Maybe you'll get help there. Thanks. I will try filing a bug on that system as soon as I get the reply to create my account there. (...) You see it's very difficult to fix such irq problems because some factors can cause such an error. Yes, I understand that. Maybe contacting specific malinglists (e.g. for "broken" pci cards the pci mailinglist, etc.), maintainers or developers would be more efficient (cc the lkml) and solve your problem (faster), because this people are specialists are this type of hardware (e.g. pci). What hardware is connect through irq 5? In my case, my problem is not with irq 5, but with irq 10, as I mentioned earlier. The situation is this: I have an Asus A7V motherboard with 2 VIA vt82c686a controllers and 2 Promise PDC20265 controllers. I recently bought myself a new DVD recorder and since Alan Cox told me[*] that the Promise controllers had problems with ATAPI devices, I decided to arrange my system this way: /dev/hda: the DVD recorder (VIA controller, master) /dev/hdc: an old CD recorder (VIA controller, master) /dev/hde: my first HD (Promise controller, master) /dev/hdg: my second HD (Promise controller, master) The Promise controller is able to control the HDs (which now have exclusive 80-pin cables) at their maximum, but I get the following stack trace if I have /dev/hdg turned on: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ACPI: PCI interrupt :00:11.0[A] -> GSI 10 (level, low) -> IRQ 10 PDC20265: chipset revision 2 PDC20265: 100% native mode on irq 10 PDC20265: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode. ide2: BM-DMA at 0x7400-0x7407, BIOS settings: hde:pio, hdf:pio ide3: BM-DMA at 0x7408-0x740f, BIOS settings: hdg:pio, hdh:pio Probing IDE interface ide2... hde: QUANTUM FIREBALL CX13.0A, ATA DISK drive ide2 at 0x8800-0x8807,0x8402 on irq 10 Probing IDE interface ide3... hdg: QUANTUM FIREBALLlct15 30, ATA DISK drive irq 10: nobody cared! [] __report_bad_irq+0x31/0x77 [] note_interrupt+0x4c/0x71 [] __do_IRQ+0x93/0xbd [] do_IRQ+0x19/0x24 [] common_interrupt+0x1a/0x20 [] __do_softirq+0x2c/0x7d [] do_softirq+0x22/0x26 [] do_IRQ+0x1e/0x24 [] common_interrupt+0x1a/0x20 [] enable_irq+0x88/0x8d [] probe_hwif+0x2da/0x366 [] ata_attach+0xa3/0xbd [] probe_hwif_init_with_fixup+0x10/0x74 [] ide_setup_pci_device+0x72/0x7f [] pdc202xx_init_one+0x15/0x18 [] ide_scan_pcidev+0x34/0x59 [] ide_scan_pcibus+0x1c/0x88 [] probe_for_hwifs+0xb/0xd [] ide_init+0x44/0x59 [] do_initcalls+0x4b/0x99 [] init+0x0/0xce [] init+0x27/0xce [] kernel_thread_helper+0x5/0xb handlers: [] (ide_intr+0x0/0xee) Disabling IRQ #10 irq 10: nobody cared! - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - This is just an excerpt of the messages. I can provide much more details if I know what is relevant. I had already posted some old dmesg logs at my site <http://www.ime.usp.br/~rbrito/ide-problem/>, but this was before I got myself a second 80-ribbon cable (I expected that the problem would go away, but it didn't). Any other comments are more than welcome. Thanks in advance, Rogério Brito. [*] http://infocenter.guardiandigital.com/archive/linux-kernel/2004/Dec/2663.html Hi! I'm not IDE specialist, but what about operating systems? Did you try a Windows or BSD CD (try it with a Windows 2000/XP CD, if you have one, else burn a NetBSD or FreeBSD/DragonflyBSD CD -- this is important to see if it's a linux bug or acpi bug)? Anyway this is very strange. Good luck! Matthias-Christian Ott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.11rc4: irq 5, nobody cared
Rogério Brito wrote: On Feb 20 2005, Folkert van Heusden wrote: My linux laptop says: irq 5: nobody cared! (...) Does anyone care? :-) Well, I'm getting similar stack traces with my system and those are sure scary, but it seems that my e-mails to the list are simply ignored, unfortunately. I am willing to test any patch and configuration (let's call me a "guinea pig"), but I don't know what I should do. I have, OTOH, reported my problem many times in the past few days. :-( I will retry sending my message to the list once again, with the details (in my case, the message I get is "irq 10: nobody cared!" and it is regarding my primary HD on my secondary Promise PDC20265 controller). Thanks for any help, Rogério. P.S.: I have already bought an 80-pin cable just for this drive in the hope that the message would go away, but it didn't. Report it to http://bugzilla.kernel.org/. Maybe you'll get help there. But "bugs" are _very_ hardware specific, so just a few people will have a similar problem and most of this people are just "normal" users -- not Linux Kernel developers. The developer (people who are familiar with the kernel code and who are maybe able to fix this problem) aren't able to reproduce this error and test code to get it working. So they're maybe (without knowing anything about the hardware (maybe it's broken hardware?)) not able to say something specific about the hardware -- they can just guess. You see it's very difficult to fix such irq problems because some factors can cause such an error. Maybe contacting specific malinglists (e.g. for "broken" pci cards the pci mailinglist, etc.), maintainers or developers would be more efficient (cc the lkml) and solve your problem (faster), because this people are specialists are this type of hardware (e.g. pci). What hardware is connect through irq 5? Matthias-Christian Ott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.11rc4: irq 5, nobody cared
Rogério Brito wrote: On Feb 20 2005, Folkert van Heusden wrote: My linux laptop says: irq 5: nobody cared! (...) Does anyone care? :-) Well, I'm getting similar stack traces with my system and those are sure scary, but it seems that my e-mails to the list are simply ignored, unfortunately. I am willing to test any patch and configuration (let's call me a guinea pig), but I don't know what I should do. I have, OTOH, reported my problem many times in the past few days. :-( I will retry sending my message to the list once again, with the details (in my case, the message I get is irq 10: nobody cared! and it is regarding my primary HD on my secondary Promise PDC20265 controller). Thanks for any help, Rogério. P.S.: I have already bought an 80-pin cable just for this drive in the hope that the message would go away, but it didn't. Report it to http://bugzilla.kernel.org/. Maybe you'll get help there. But bugs are _very_ hardware specific, so just a few people will have a similar problem and most of this people are just normal users -- not Linux Kernel developers. The developer (people who are familiar with the kernel code and who are maybe able to fix this problem) aren't able to reproduce this error and test code to get it working. So they're maybe (without knowing anything about the hardware (maybe it's broken hardware?)) not able to say something specific about the hardware -- they can just guess. You see it's very difficult to fix such irq problems because some factors can cause such an error. Maybe contacting specific malinglists (e.g. for broken pci cards the pci mailinglist, etc.), maintainers or developers would be more efficient (cc the lkml) and solve your problem (faster), because this people are specialists are this type of hardware (e.g. pci). What hardware is connect through irq 5? Matthias-Christian Ott - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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.11rc4: irq 5, nobody cared
Rogério Brito wrote: On Feb 20 2005, Matthias-Christian Ott wrote: Rogério Brito wrote: I am willing to test any patch and configuration (let's call me a guinea pig), but I don't know what I should do. I have, OTOH, reported my problem many times in the past few days. :-( I will retry sending my message to the list once again, with the details (in my case, the message I get is irq 10: nobody cared! and it is regarding my primary HD on my secondary Promise PDC20265 controller). First of all, Matthias-Christian, thank you very much for your kind answer. I have already tried contacting the linux-ide mailing list as a CC to my earlier messages, but I got no response. I am including some details in this e-mail. I included Bartlomiej in the CC, as he is listed as general IDE maintainer in the MAINTAINERS file. Report it to http://bugzilla.kernel.org/. Maybe you'll get help there. Thanks. I will try filing a bug on that system as soon as I get the reply to create my account there. (...) You see it's very difficult to fix such irq problems because some factors can cause such an error. Yes, I understand that. Maybe contacting specific malinglists (e.g. for broken pci cards the pci mailinglist, etc.), maintainers or developers would be more efficient (cc the lkml) and solve your problem (faster), because this people are specialists are this type of hardware (e.g. pci). What hardware is connect through irq 5? In my case, my problem is not with irq 5, but with irq 10, as I mentioned earlier. The situation is this: I have an Asus A7V motherboard with 2 VIA vt82c686a controllers and 2 Promise PDC20265 controllers. I recently bought myself a new DVD recorder and since Alan Cox told me[*] that the Promise controllers had problems with ATAPI devices, I decided to arrange my system this way: /dev/hda: the DVD recorder (VIA controller, master) /dev/hdc: an old CD recorder (VIA controller, master) /dev/hde: my first HD (Promise controller, master) /dev/hdg: my second HD (Promise controller, master) The Promise controller is able to control the HDs (which now have exclusive 80-pin cables) at their maximum, but I get the following stack trace if I have /dev/hdg turned on: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ACPI: PCI interrupt :00:11.0[A] - GSI 10 (level, low) - IRQ 10 PDC20265: chipset revision 2 PDC20265: 100% native mode on irq 10 PDC20265: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode. ide2: BM-DMA at 0x7400-0x7407, BIOS settings: hde:pio, hdf:pio ide3: BM-DMA at 0x7408-0x740f, BIOS settings: hdg:pio, hdh:pio Probing IDE interface ide2... hde: QUANTUM FIREBALL CX13.0A, ATA DISK drive ide2 at 0x8800-0x8807,0x8402 on irq 10 Probing IDE interface ide3... hdg: QUANTUM FIREBALLlct15 30, ATA DISK drive irq 10: nobody cared! [c0128fc1] __report_bad_irq+0x31/0x77 [c012906b] note_interrupt+0x4c/0x71 [c0128c86] __do_IRQ+0x93/0xbd [c0104635] do_IRQ+0x19/0x24 [c010335a] common_interrupt+0x1a/0x20 [c011935c] __do_softirq+0x2c/0x7d [c01193cf] do_softirq+0x22/0x26 [c010463a] do_IRQ+0x1e/0x24 [c010335a] common_interrupt+0x1a/0x20 [c0128d89] enable_irq+0x88/0x8d [c021edc0] probe_hwif+0x2da/0x366 [c021a137] ata_attach+0xa3/0xbd [c021ee5c] probe_hwif_init_with_fixup+0x10/0x74 [c0221597] ide_setup_pci_device+0x72/0x7f [c0216f82] pdc202xx_init_one+0x15/0x18 [c039182e] ide_scan_pcidev+0x34/0x59 [c039186f] ide_scan_pcibus+0x1c/0x88 [c039179f] probe_for_hwifs+0xb/0xd [c03917e5] ide_init+0x44/0x59 [c037c6ce] do_initcalls+0x4b/0x99 [c0100272] init+0x0/0xce [c0100299] init+0x27/0xce [c0101245] kernel_thread_helper+0x5/0xb handlers: [c021c2a6] (ide_intr+0x0/0xee) Disabling IRQ #10 irq 10: nobody cared! - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - This is just an excerpt of the messages. I can provide much more details if I know what is relevant. I had already posted some old dmesg logs at my site http://www.ime.usp.br/~rbrito/ide-problem/, but this was before I got myself a second 80-ribbon cable (I expected that the problem would go away, but it didn't). Any other comments are more than welcome. Thanks in advance, Rogério Brito. [*] http://infocenter.guardiandigital.com/archive/linux-kernel/2004/Dec/2663.html Hi! I'm not IDE specialist, but what about operating systems? Did you try a Windows or BSD CD (try it with a Windows 2000/XP CD, if you have one, else burn a NetBSD or FreeBSD/DragonflyBSD CD -- this is important to see if it's a linux bug or acpi bug)? Anyway this is very strange. Good luck! Matthias-Christian Ott - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Panic in 2.6.11-rc4
+0x179/0x180 [c0118fa9] do_page_fault+0x2d9/0x56a [c0135420] autoremove_wake_function+0x0/0x50 [c0144636] mempool_alloc+0x76/0x150 [c0149535] cache_grow+0x105/0x130 [c0249a67] submit_bio+0x57/0xe0 [c0135420] autoremove_wake_function+0x0/0x50 [c0118cd0] do_page_fault+0x0/0x56a [c0103c03] error_code+0x2b/0x30 [c014976e] cache_alloc_refill+0x20e/0x240 [c0149980] kmem_cache_alloc+0x50/0x70 [e0856113] __scsi_get_command+0x23/0x80 [scsi_mod] [e08561a1] scsi_get_command+0x31/0xf0 [scsi_mod] [e085c793] scsi_prep_fn+0x133/0x1e0 [scsi_mod] [c0245f6c] elv_next_request+0x4c/0xf0 [c0247e9b] blk_remove_plug+0x3b/0x70 [c0247ef2] __generic_unplug_device+0x22/0x30 [c0247f15] generic_unplug_device+0x15/0x30 [c0247f30] blk_backing_dev_unplug+0x0/0x20 [c0247f42] blk_backing_dev_unplug+0x12/0x20 [c0163fc6] block_sync_page+0x36/0x40 [c0140d5c] sync_page+0x3c/0x50 [c031155b] __wait_on_bit_lock+0x5b/0x70 [c0140d20] sync_page+0x0/0x50 [c0135470] wake_bit_function+0x0/0x60 [c01414f0] __lock_page+0x90/0xa0 [c0135470] wake_bit_function+0x0/0x60 [c0135470] wake_bit_function+0x0/0x60 [c0311f40] _spin_unlock_irq+0x20/0x40 [c0141cc7] do_generic_mapping_read+0x427/0x510 [c01b5b02] avc_has_perm_noaudit+0x92/0x140 [c0141db0] file_read_actor+0x0/0xf0 [c0142094] __generic_file_aio_read+0x1f4/0x230 [c0141db0] file_read_actor+0x0/0xf0 [c01421c5] generic_file_read+0x95/0xb0 [c0135420] autoremove_wake_function+0x0/0x50 [c0166c07] block_llseek+0x27/0xf0 [c015f4b3] vfs_read+0xc3/0x130 [c015f767] sys_read+0x47/0x80 [c0103109] sysenter_past_esp+0x52/0x75 scheduling while atomic: linuxrc/0x0002/392 [c0310982] schedule+0xb52/0xb60 [c01352f0] prepare_to_wait+0x20/0x70 [c0130eea] flush_cpu_workqueue+0x9a/0x1b0 [c01616c5] invalidate_inode_buffers+0x15/0x90 [c0135420] autoremove_wake_function+0x0/0x50 [c0135420] autoremove_wake_function+0x0/0x50 [c0131062] flush_workqueue+0x62/0xa0 [c020fa05] release_dev+0x505/0x7c0 [c0145789] free_hot_cold_page+0xe9/0x140 [c0145f4c] __pagevec_free+0x1c/0x30 [c014abec] release_pages+0x5c/0x150 [c03121c8] lock_kernel+0x28/0x40 [c01616c5] invalidate_inode_buffers+0x15/0x90 [c021015f] tty_release+0xf/0x20 [c0160526] __fput+0x146/0x160 [c015ebef] filp_close+0x4f/0x80 [c0122cd1] put_files_struct+0x61/0xb0 [c0123931] do_exit+0xd1/0x360 [c0104369] die+0x179/0x180 [c0118fa9] do_page_fault+0x2d9/0x56a [c0135420] autoremove_wake_function+0x0/0x50 [c0144636] mempool_alloc+0x76/0x150 [c0149535] cache_grow+0x105/0x130 [c0249a67] submit_bio+0x57/0xe0 [c0135420] autoremove_wake_function+0x0/0x50 [c0118cd0] do_page_fault+0x0/0x56a [c0103c03] error_code+0x2b/0x30 [c014976e] cache_alloc_refill+0x20e/0x240 [c0149980] kmem_cache_alloc+0x50/0x70 [e0856113] __scsi_get_command+0x23/0x80 [scsi_mod] [e08561a1] scsi_get_command+0x31/0xf0 [scsi_mod] [e085c793] scsi_prep_fn+0x133/0x1e0 [scsi_mod] [c0245f6c] elv_next_request+0x4c/0xf0 [c0247e9b] blk_remove_plug+0x3b/0x70 [c0247ef2] __generic_unplug_device+0x22/0x30 [c0247f15] generic_unplug_device+0x15/0x30 [c0247f30] blk_backing_dev_unplug+0x0/0x20 [c0247f42] blk_backing_dev_unplug+0x12/0x20 [c0163fc6] block_sync_page+0x36/0x40 [c0140d5c] sync_page+0x3c/0x50 [c031155b] __wait_on_bit_lock+0x5b/0x70 [c0140d20] sync_page+0x0/0x50 [c0135470] wake_bit_function+0x0/0x60 [c01414f0] __lock_page+0x90/0xa0 [c0135470] wake_bit_function+0x0/0x60 [c0135470] wake_bit_function+0x0/0x60 [c0311f40] _spin_unlock_irq+0x20/0x40 [c0141cc7] do_generic_mapping_read+0x427/0x510 [c01b5b02] avc_has_perm_noaudit+0x92/0x140 [c0141db0] file_read_actor+0x0/0xf0 [c0142094] __generic_file_aio_read+0x1f4/0x230 [c0141db0] file_read_actor+0x0/0xf0 [c01421c5] generic_file_read+0x95/0xb0 [c0135420] autoremove_wake_function+0x0/0x50 [c0166c07] block_llseek+0x27/0xf0 [c015f4b3] vfs_read+0xc3/0x130 [c015f767] sys_read+0x47/0x80 [c0103109] sysenter_past_esp+0x52/0x75 Hi! The first one is allocation error (linuxrc wants to get/read memory, but the allocation fails?). The other errors are _maybe_ caused by the first error (the scheduler schedules while a atomic operation is in progress). Is your Kernel configuration different to the configuration of the Fedora Kernel? If so: What did you change? It's strange that you can't change you Bios settings. Is the write protection jumper set to 1 (TRUE/ENABLED)? Is your Bios up2date? Matthias-Christian Ott - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: proc path_walk glitch ?
Der Herr Hofrat wrote:
HI !
I noticed a slight proc filesystem strangness in the 2.4.2X and 2.6.X
(atleast up to 2.6.8). Assuming that process 8655 exists and is running
long enough (ls -lR / or so)
cd /proc/8655
kill -9 8655
ls
/usr/bin/ls: .: Stale NFS file handle
open(., O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = -1 ESTALE (Stale NFS file
handle) from fs/namei.c - link_path_walk :
int fastcall link_path_walk(const char * name, struct nameidata *nd)
{
struct dentry *dentry;
struct inode *inode;
int err;
unsigned int lookup_flags = nd-flags;
while (*name=='/')
name++;
if (!*name)
goto return_reval;
...
return_reval:
/*
* We bypassed the ordinary revalidation routines.
* Check the cached dentry for staleness.
*/
dentry = nd-dentry;
if (dentry dentry-d_op dentry-d_op-d_revalidate) {
err = -ESTALE;
if (!dentry-d_op-d_revalidate(dentry, 0)) {
d_invalidate(dentry);
break;
}
}
Why does return_reval return -ESTALE instead of -ENOENT here - might need an
extra check on what filesystem this is working on ?
/usr/bin/ls: .: no such file or directory
would seem more meaningfull to me when I find it in a logfile.
thx !
hofrat
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Does it happen in 2.6.10 or are you sing 2.6.8?
Matthias-Christian Ott
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: I wrote a kernel tool for monitoring / web page
sylvanino b wrote: Hi, I wrote a kernel tool for my personnal usage which goal is to keep a record of recent task preemptions and interruptions that appears under linux. Although the record is short (a few minutes only), It can help to analyse scheduling algorithm efficiency and also driver timing issues. The user can access data from user-space, through proc filesystem and analyze it with a graphics tool. Then, since it's also availlable within KDB, it can give clues and help for debugging. So far, the tool is not a big deal, but not trivial either. When It is running, the tool doesn't overload the system. And when it is not running, it's just transparent. I did a webpage for it, you can check it out at: http://membres.lycos.fr/kernelanalyzer/ If you have any comment/critics, don't hesitate to share it Thanks, Sylvain - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Hi! Lycos is not the right place for such a good project, request hosting at sf.net or developer.berlios.de. Matthias-Christian Ott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: I wrote a kernel tool for monitoring / web page
sylvanino b wrote: Hi, I wrote a kernel tool for my personnal usage which goal is to keep a record of recent task preemptions and interruptions that appears under linux. Although the record is short (a few minutes only), It can help to analyse scheduling algorithm efficiency and also driver timing issues. The user can access data from user-space, through proc filesystem and analyze it with a graphics tool. Then, since it's also availlable within KDB, it can give clues and help for debugging. So far, the tool is not a big deal, but not trivial either. When It is running, the tool doesn't overload the system. And when it is not running, it's just transparent. I did a webpage for it, you can check it out at: http://membres.lycos.fr/kernelanalyzer/ If you have any comment/critics, don't hesitate to share it Thanks, Sylvain - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Hi! Lycos is not the right place for such a good project, request hosting at sf.net or developer.berlios.de. Matthias-Christian Ott - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: spam mails with the same Message-ID
Adrian Bunk wrote: On Thu, Feb 17, 2005 at 10:26:55AM -0500, Parag Warudkar wrote: On Thursday 17 February 2005 10:10 am, Paolo Ornati wrote: ÄúºÃ£º ÎÒÒÑ_ÊÕµ_ÄúµÄÀ_ÐÅ and... what does this means? SPAM. This looks to me like a new way of spamming though, replying to valid mailing list messages. (I too received couple of these in reply to my messages.) The most interesting fact seems to be that these spam messages have the same message ID as the original Mails. If you run a program that automatically discards duplicate mails and the spam message reaches you faster than the original email through linux-kernel (which seems to often happen with these mails), the original email will be discarded. I don't know whether these are known attacks, but the automatic discarding of duplicated emails offers attackers nice opportunities if they know a message ID (as with these emails) or can guess the message ID (since many MUAs have predictable message IDs, an attacker C could use this to suppress a message from person A to person B by sending an email with the message ID to person B bevor person B gets the email from person A). Parag cu Adrian The spamers become always cleverer :-) . Matthias-Christian Ott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re:
Deepti Patel wrote: Hi I am getting an error while inserting an hello world program. [EMAIL PROTECTED] deepti]$ /sbin/insmod hello-2.ko insmod: error inserting 'hello-2.ko': -1 Operation not permitted I haven't logged in as root. For inserting a module do I need to logged in as root? I will really appretiate any suggestions. Thanks in advance Jep you need to be root. Matthias-Christian Ott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re:
Deepti Patel wrote: Hi I am getting an error while inserting an hello world program. [EMAIL PROTECTED] deepti]$ /sbin/insmod hello-2.ko insmod: error inserting 'hello-2.ko': -1 Operation not permitted I haven't logged in as root. For inserting a module do I need to logged in as root? I will really appretiate any suggestions. Thanks in advance Jep you need to be root. Matthias-Christian Ott - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: spam mails with the same Message-ID
Adrian Bunk wrote: On Thu, Feb 17, 2005 at 10:26:55AM -0500, Parag Warudkar wrote: On Thursday 17 February 2005 10:10 am, Paolo Ornati wrote: ÄúºÃ£º ÎÒÒÑ_ÊÕµ_ÄúµÄÀ_ÐÅ and... what does this means? SPAM. This looks to me like a new way of spamming though, replying to valid mailing list messages. (I too received couple of these in reply to my messages.) The most interesting fact seems to be that these spam messages have the same message ID as the original Mails. If you run a program that automatically discards duplicate mails and the spam message reaches you faster than the original email through linux-kernel (which seems to often happen with these mails), the original email will be discarded. I don't know whether these are known attacks, but the automatic discarding of duplicated emails offers attackers nice opportunities if they know a message ID (as with these emails) or can guess the message ID (since many MUAs have predictable message IDs, an attacker C could use this to suppress a message from person A to person B by sending an email with the message ID to person B bevor person B gets the email from person A). Parag cu Adrian The spamers become always cleverer :-) . Matthias-Christian Ott - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Help: kernel option root=/dev/nfs failing 2.6.10
Haven Skys wrote: I am attempting to create network bootable system with 2.6.10 and nfs and am having trouble. I am using grub and the boot goes without a hitch until the kernel attempts to use the commands I've sent. bootp root (nd) kernel (nd)/redhat-2.6.10/kernel root=/dev/nfs ip=bootp nfsroot=10.0.120.1:/diskless/redhat-2.6.10/ baseos Network booting machine X does fine until. It attempts to open the root device. VFS: Cannot open root device "nfs" or unknown-block(0,255) Please append a correct "root=" boot option Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,255) It looks like the kernel isn't recognizing the virtual device /dev/nfs but I've enabled all the NFS options and everything is compiled into the kernel. Any ideas? Thanks Haven FrontBridge introduces Message Archive and Secure Email. Get leading Enterprise Message Security services from FrontBridge. www.frontbridge.com. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Hi! I did you follow the "tutorial" in Documentation/nfsroot.txt? Matthias-Christian Ott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Help: kernel option root=/dev/nfs failing 2.6.10
Haven Skys wrote: I am attempting to create network bootable system with 2.6.10 and nfs and am having trouble. I am using grub and the boot goes without a hitch until the kernel attempts to use the commands I've sent. SNIP from grub.conf bootp root (nd) kernel (nd)/redhat-2.6.10/kernel root=/dev/nfs ip=bootp nfsroot=10.0.120.1:/diskless/redhat-2.6.10/ baseos /SNIP Network booting machine X does fine until. It attempts to open the root device. SNIP VFS: Cannot open root device nfs or unknown-block(0,255) Please append a correct root= boot option Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,255) /SNIP It looks like the kernel isn't recognizing the virtual device /dev/nfs but I've enabled all the NFS options and everything is compiled into the kernel. Any ideas? Thanks Haven FrontBridge introduces Message Archive and Secure Email. Get leading Enterprise Message Security services from FrontBridge. www.frontbridge.com. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Hi! I did you follow the tutorial in Documentation/nfsroot.txt? Matthias-Christian Ott - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: repost: 2.6.11-rc4 BUG: using smp_processor_id() in preemptible [00000001] code: ip/6840
Frank van Maarseveen wrote: On Sun, Feb 06, 2005 at 08:51:11PM +0100, Frank van Maarseveen wrote: While executing iptables -t nat -D OUTPUT -d 80.126.170.174 -p tcp --dport https -j DNAT --to 192.168.0.1 iptables -t nat -D OUTPUT -d 80.126.170.174 -p tcp --dport http -j DNAT --to 192.168.0.1 still present in -rc4: kernel: BUG: using smp_processor_id() in preemptible [0001] code: ip/6351 kernel: caller is get_next_corpse+0x13/0x260 kernel: [] dump_stack+0x1e/0x30 kernel: [] smp_processor_id+0xaf/0xc0 kernel: [] get_next_corpse+0x13/0x260 kernel: [] ip_ct_iterate_cleanup+0x36/0xc0 kernel: [] masq_inet_event+0x3a/0x70 kernel: [] notifier_call_chain+0x2d/0x50 kernel: [] inet_del_ifa+0x99/0x150 kernel: [] inet_rtm_deladdr+0x12b/0x170 kernel: [] rtnetlink_rcv+0x35b/0x420 kernel: [] netlink_data_ready+0x60/0x70 kernel: [] netlink_sendskb+0x31/0x60 kernel: [] netlink_sendmsg+0x261/0x320 kernel: [] sock_sendmsg+0xbb/0xe0 kernel: [] sys_sendmsg+0x1c4/0x230 kernel: [] sys_socketcall+0x21c/0x240 kernel: [] syscall_call+0x7/0xb kernel: BUG: using smp_processor_id() in preemptible [0001] code: ip/6351 kernel: caller is get_next_corpse+0x23f/0x260 kernel: [] dump_stack+0x1e/0x30 kernel: [] smp_processor_id+0xaf/0xc0 kernel: [] get_next_corpse+0x23f/0x260 kernel: [] ip_ct_iterate_cleanup+0x36/0xc0 kernel: [] masq_inet_event+0x3a/0x70 kernel: [] notifier_call_chain+0x2d/0x50 kernel: [] inet_del_ifa+0x99/0x150 kernel: [] inet_rtm_deladdr+0x12b/0x170 kernel: [] rtnetlink_rcv+0x35b/0x420 kernel: [] netlink_data_ready+0x60/0x70 kernel: [] netlink_sendskb+0x31/0x60 kernel: [] netlink_sendmsg+0x261/0x320 kernel: [] sock_sendmsg+0xbb/0xe0 kernel: [] sys_sendmsg+0x1c4/0x230 kernel: [] sys_socketcall+0x21c/0x240 kernel: [] syscall_call+0x7/0xb Than fix it, the way I mentioned. Matthias-Christian Ott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: repost: 2.6.11-rc4 BUG: using smp_processor_id() in preemptible [00000001] code: ip/6840
Frank van Maarseveen wrote: On Sun, Feb 06, 2005 at 08:51:11PM +0100, Frank van Maarseveen wrote: While executing iptables -t nat -D OUTPUT -d 80.126.170.174 -p tcp --dport https -j DNAT --to 192.168.0.1 iptables -t nat -D OUTPUT -d 80.126.170.174 -p tcp --dport http -j DNAT --to 192.168.0.1 still present in -rc4: kernel: BUG: using smp_processor_id() in preemptible [0001] code: ip/6351 kernel: caller is get_next_corpse+0x13/0x260 kernel: [c010385e] dump_stack+0x1e/0x30 kernel: [c024f60f] smp_processor_id+0xaf/0xc0 kernel: [c0408c03] get_next_corpse+0x13/0x260 kernel: [c0408e86] ip_ct_iterate_cleanup+0x36/0xc0 kernel: [c041981a] masq_inet_event+0x3a/0x70 kernel: [c012ee4d] notifier_call_chain+0x2d/0x50 kernel: [c03f02d9] inet_del_ifa+0x99/0x150 kernel: [c03f084b] inet_rtm_deladdr+0x12b/0x170 kernel: [c03b290b] rtnetlink_rcv+0x35b/0x420 kernel: [c03c26c0] netlink_data_ready+0x60/0x70 kernel: [c03c1ad1] netlink_sendskb+0x31/0x60 kernel: [c03c2391] netlink_sendmsg+0x261/0x320 kernel: [c039f16b] sock_sendmsg+0xbb/0xe0 kernel: [c03a0d14] sys_sendmsg+0x1c4/0x230 kernel: [c03a11bc] sys_socketcall+0x21c/0x240 kernel: [c01029f3] syscall_call+0x7/0xb kernel: BUG: using smp_processor_id() in preemptible [0001] code: ip/6351 kernel: caller is get_next_corpse+0x23f/0x260 kernel: [c010385e] dump_stack+0x1e/0x30 kernel: [c024f60f] smp_processor_id+0xaf/0xc0 kernel: [c0408e2f] get_next_corpse+0x23f/0x260 kernel: [c0408e86] ip_ct_iterate_cleanup+0x36/0xc0 kernel: [c041981a] masq_inet_event+0x3a/0x70 kernel: [c012ee4d] notifier_call_chain+0x2d/0x50 kernel: [c03f02d9] inet_del_ifa+0x99/0x150 kernel: [c03f084b] inet_rtm_deladdr+0x12b/0x170 kernel: [c03b290b] rtnetlink_rcv+0x35b/0x420 kernel: [c03c26c0] netlink_data_ready+0x60/0x70 kernel: [c03c1ad1] netlink_sendskb+0x31/0x60 kernel: [c03c2391] netlink_sendmsg+0x261/0x320 kernel: [c039f16b] sock_sendmsg+0xbb/0xe0 kernel: [c03a0d14] sys_sendmsg+0x1c4/0x230 kernel: [c03a11bc] sys_socketcall+0x21c/0x240 kernel: [c01029f3] syscall_call+0x7/0xb Than fix it, the way I mentioned. Matthias-Christian Ott - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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-bk: cpu hotplug + preempt = smp_processor_id warnings galore
Nathan Lynch wrote: Hi- With 2.6.11-rc3-bk7 on ppc64 I am seeing lots of smp_processor_id warnings whenever I hotplug cpus: # echo 0 > /sys/devices/system/cpu/cpu1/online cpu 1 (hwid 1) Ready to die... BUG: using smp_processor_id() in preemptible [0001] code: ksoftirqd/1/5 caller is .ksoftirqd+0xbc/0x1f8 Call Trace: [c000fffbbce0] [] 0x (unreliable) [c000fffbbd60] [c01c9f1c] .smp_processor_id+0x154/0x168 [c000fffbbe20] [c005f414] .ksoftirqd+0xbc/0x1f8 [c000fffbbed0] [c00764cc] .kthread+0x128/0x134 [c000fffbbf90] [c0014248] .kernel_thread+0x4c/0x6c I believe the above warning is caused by the local_softirq_pending call on a "foreign" cpu before ksoftirqd/1 has been stopped. Looking at the code, I think this doesn't indicate a real bug, but it would be better if ksoftirqd didn't check local_softirq_pending after it's been kicked off its cpu, right? # echo 1 > /sys/devices/system/cpu/cpu1/online BUG: using smp_processor_id() in preemptible [0001] code: swapper/0 caller is .dedicated_idle+0x68/0x22c Call Trace: [c000fffafc50] [] 0x (unreliable) [c000fffafcd0] [c01c9f1c] .smp_processor_id+0x154/0x168 [c000fffafd90] [c000f998] .dedicated_idle+0x68/0x22c [c000fffafe80] [c000fce8] .cpu_idle+0x34/0x4c [c000fffaff00] [c003a744] .start_secondary+0x10c/0x150 [c000fffaff90] [c000bd28] .enable_64b_mode+0x0/0x28 Should ppc64 simply use _smp_processor_id() in its idle loop code (like i386)? If I online and offline cpus rapidly enough I can eventually get the following: printk: 49 messages suppressed. BUG: using smp_processor_id() in preemptible [0001] code: events/3/1262 caller is .cache_reap+0x21c/0x2b8 Call Trace: [c000ed67bb90] [] 0x (unreliable) [c000ed67bc10] [c01c9f1c] .smp_processor_id+0x154/0x168 [c000ed67bcd0] [c00938e8] .cache_reap+0x21c/0x2b8 [c000ed67bda0] [c006f4bc] .worker_thread+0x230/0x310 [c000ed67bed0] [c00764cc] .kthread+0x128/0x134 [c000ed67bf90] [c0014248] .kernel_thread+0x4c/0x6c And this will repeat over and over even after I stop hotplugging cpus... from the same events thread so I think it's somehow gotten "stuck"? Anything I can do to further debug? Nathan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Hi! Use get_cpu() (It disables preemption) or __smp_processor_id () (on a smp). Matthias-Christian Ott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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-bk: cpu hotplug + preempt = smp_processor_id warnings galore
Nathan Lynch wrote: Hi- With 2.6.11-rc3-bk7 on ppc64 I am seeing lots of smp_processor_id warnings whenever I hotplug cpus: # echo 0 /sys/devices/system/cpu/cpu1/online cpu 1 (hwid 1) Ready to die... BUG: using smp_processor_id() in preemptible [0001] code: ksoftirqd/1/5 caller is .ksoftirqd+0xbc/0x1f8 Call Trace: [c000fffbbce0] [] 0x (unreliable) [c000fffbbd60] [c01c9f1c] .smp_processor_id+0x154/0x168 [c000fffbbe20] [c005f414] .ksoftirqd+0xbc/0x1f8 [c000fffbbed0] [c00764cc] .kthread+0x128/0x134 [c000fffbbf90] [c0014248] .kernel_thread+0x4c/0x6c I believe the above warning is caused by the local_softirq_pending call on a foreign cpu before ksoftirqd/1 has been stopped. Looking at the code, I think this doesn't indicate a real bug, but it would be better if ksoftirqd didn't check local_softirq_pending after it's been kicked off its cpu, right? # echo 1 /sys/devices/system/cpu/cpu1/online BUG: using smp_processor_id() in preemptible [0001] code: swapper/0 caller is .dedicated_idle+0x68/0x22c Call Trace: [c000fffafc50] [] 0x (unreliable) [c000fffafcd0] [c01c9f1c] .smp_processor_id+0x154/0x168 [c000fffafd90] [c000f998] .dedicated_idle+0x68/0x22c [c000fffafe80] [c000fce8] .cpu_idle+0x34/0x4c [c000fffaff00] [c003a744] .start_secondary+0x10c/0x150 [c000fffaff90] [c000bd28] .enable_64b_mode+0x0/0x28 Should ppc64 simply use _smp_processor_id() in its idle loop code (like i386)? If I online and offline cpus rapidly enough I can eventually get the following: printk: 49 messages suppressed. BUG: using smp_processor_id() in preemptible [0001] code: events/3/1262 caller is .cache_reap+0x21c/0x2b8 Call Trace: [c000ed67bb90] [] 0x (unreliable) [c000ed67bc10] [c01c9f1c] .smp_processor_id+0x154/0x168 [c000ed67bcd0] [c00938e8] .cache_reap+0x21c/0x2b8 [c000ed67bda0] [c006f4bc] .worker_thread+0x230/0x310 [c000ed67bed0] [c00764cc] .kthread+0x128/0x134 [c000ed67bf90] [c0014248] .kernel_thread+0x4c/0x6c And this will repeat over and over even after I stop hotplugging cpus... from the same events thread so I think it's somehow gotten stuck? Anything I can do to further debug? Nathan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Hi! Use get_cpu() (It disables preemption) or __smp_processor_id () (on a smp). Matthias-Christian Ott - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 Virtual Network Device
William Stearns wrote: Good afternoon, Matthias-Christian, (This isn't a linux kernel development issue; please do further discussion on the uml-user mailing list only.) On Mon, 7 Feb 2005, Matthias-Christian Ott wrote: I have the following the problem: I have server which is connected to the internet via a gateway, on this server I want to run some uml machines. I want "equip" every uml machine with virtual network device (virX [e.g.; the name doesn't matter]). The virtual devices should be something like the "lo" device and their ip addresses shouldn't be used by the internet (I'm looking for something like 127.0.0.1). I want to give each uml machine a host name (e.g. xxx.myserver.mydomain.com), requests should be masqueraded (by bind or dnsmasq?) by their dns name (1.myserver.mydomain.com is 127.0.0.2 [vir0]). How to do this? Links or Tutorials are welcome (I just found some outdated stuff on the uml website) Please give these a try as a start. http://www.stearns.org/slartibartfast/uml-coop.current.html#networking http://www.stearns.org/slartibartfast/rc.uml-net Cheers, - Bill --- "Power concedes nothing without a demand. It never did, and it never will. Find out just what people will submit to, and you have found out the exact amount of injustice and wrong which will be imposed upon them; and these will continue until they are resisted with either words or blows, or with both. The limits of tyrants are prescribed by the endurance of those whom they oppress." -- Frederick Douglass, August 4, 1857 (Courtesy of Eric S. Raymond) -- William Stearns ([EMAIL PROTECTED]). Mason, Buildkernel, freedups, p0f, rsync-backup, ssh-keyinstall, dns-check, more at: http://www.stearns.org -- Thanks that was exactly what I'm looking for. But howto get dns masquerading working with bind? Matthias-Christian Ott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 Virtual Network Device
William Stearns wrote: Good afternoon, Matthias-Christian, (This isn't a linux kernel development issue; please do further discussion on the uml-user mailing list only.) On Mon, 7 Feb 2005, Matthias-Christian Ott wrote: I have the following the problem: I have server which is connected to the internet via a gateway, on this server I want to run some uml machines. I want equip every uml machine with virtual network device (virX [e.g.; the name doesn't matter]). The virtual devices should be something like the lo device and their ip addresses shouldn't be used by the internet (I'm looking for something like 127.0.0.1). I want to give each uml machine a host name (e.g. xxx.myserver.mydomain.com), requests should be masqueraded (by bind or dnsmasq?) by their dns name (1.myserver.mydomain.com is 127.0.0.2 [vir0]). How to do this? Links or Tutorials are welcome (I just found some outdated stuff on the uml website) Please give these a try as a start. http://www.stearns.org/slartibartfast/uml-coop.current.html#networking http://www.stearns.org/slartibartfast/rc.uml-net Cheers, - Bill --- Power concedes nothing without a demand. It never did, and it never will. Find out just what people will submit to, and you have found out the exact amount of injustice and wrong which will be imposed upon them; and these will continue until they are resisted with either words or blows, or with both. The limits of tyrants are prescribed by the endurance of those whom they oppress. -- Frederick Douglass, August 4, 1857 (Courtesy of Eric S. Raymond) -- William Stearns ([EMAIL PROTECTED]). Mason, Buildkernel, freedups, p0f, rsync-backup, ssh-keyinstall, dns-check, more at: http://www.stearns.org -- Thanks that was exactly what I'm looking for. But howto get dns masquerading working with bind? Matthias-Christian Ott - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux Virtual Network Device
Hi! I have the following the problem: I have server which is connected to the internet via a gateway, on this server I want to run some uml machines. I want "equip" every uml machine with virtual network device (virX [e.g.; the name doesn't matter]). The virtual devices should be something like the "lo" device and their ip addresses shouldn't be used by the internet (I'm looking for something like 127.0.0.1). I want to give each uml machine a host name (e.g. xxx.myserver.mydomain.com), requests should be masqueraded (by bind or dnsmasq?) by their dns name (1.myserver.mydomain.com is 127.0.0.2 [vir0]). How to do this? Links or Tutorials are welcome (I just found some outdated stuff on the uml website) Thanks Matthias-Christian Ott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux Virtual Network Device
Hi! I have the following the problem: I have server which is connected to the internet via a gateway, on this server I want to run some uml machines. I want equip every uml machine with virtual network device (virX [e.g.; the name doesn't matter]). The virtual devices should be something like the lo device and their ip addresses shouldn't be used by the internet (I'm looking for something like 127.0.0.1). I want to give each uml machine a host name (e.g. xxx.myserver.mydomain.com), requests should be masqueraded (by bind or dnsmasq?) by their dns name (1.myserver.mydomain.com is 127.0.0.2 [vir0]). How to do this? Links or Tutorials are welcome (I just found some outdated stuff on the uml website) Thanks Matthias-Christian Ott - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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.11-rc3 BUG: using smp_processor_id() in preemptible [00000001] code: ip/6840
Frank van Maarseveen wrote: While executing iptables -t nat -D OUTPUT -d 80.126.170.174 -p tcp --dport https -j DNAT --to 192.168.0.1 iptables -t nat -D OUTPUT -d 80.126.170.174 -p tcp --dport http -j DNAT --to 192.168.0.1 ip route del default ip addr del 80.126.170.174 dev eth0 on a dual PIII during a shutdown: kernel: BUG: using smp_processor_id() in preemptible [0001] code: ip/6840 kernel: caller is get_next_corpse+0x13/0x260 kernel: [] dump_stack+0x1e/0x30 kernel: [] smp_processor_id+0xaf/0xc0 kernel: [] get_next_corpse+0x13/0x260 kernel: [] ip_ct_iterate_cleanup+0x36/0xc0 kernel: [] masq_inet_event+0x3a/0x70 kernel: [] notifier_call_chain+0x2d/0x50 kernel: [] inet_del_ifa+0x99/0x150 kernel: [] inet_rtm_deladdr+0x12b/0x170 kernel: [] rtnetlink_rcv+0x347/0x410 kernel: [] netlink_data_ready+0x60/0x70 kernel: [] netlink_sendskb+0x31/0x60 kernel: [] netlink_sendmsg+0x259/0x310 kernel: [] sock_sendmsg+0xbb/0xe0 kernel: [] sys_sendmsg+0x1c4/0x230 kernel: [] sys_socketcall+0x21c/0x240 kernel: [] syscall_call+0x7/0xb kernel: BUG: using smp_processor_id() in preemptible [0001] code: ip/6840 kernel: caller is get_next_corpse+0x23f/0x260 kernel: [] dump_stack+0x1e/0x30 kernel: [] smp_processor_id+0xaf/0xc0 kernel: [] get_next_corpse+0x23f/0x260 kernel: [] ip_ct_iterate_cleanup+0x36/0xc0 kernel: [] masq_inet_event+0x3a/0x70 kernel: [] notifier_call_chain+0x2d/0x50 kernel: [] inet_del_ifa+0x99/0x150 kernel: [] inet_rtm_deladdr+0x12b/0x170 kernel: [] rtnetlink_rcv+0x347/0x410 kernel: [] netlink_data_ready+0x60/0x70 kernel: [] netlink_sendskb+0x31/0x60 kernel: [] netlink_sendmsg+0x259/0x310 kernel: [] sock_sendmsg+0xbb/0xe0 kernel: [] sys_sendmsg+0x1c4/0x230 kernel: [] sys_socketcall+0x21c/0x240 kernel: [] syscall_call+0x7/0xb Hi! You have to use get_cpu() or __smp_processor_id() to avoid this debug message. Have a look at inlcude/linux/smp.h and include/asm-i386/smp.h. Matthias-Christian Ott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.11-rc3 BUG: using smp_processor_id() in preemptible [00000001] code: ip/6840
Frank van Maarseveen wrote: While executing iptables -t nat -D OUTPUT -d 80.126.170.174 -p tcp --dport https -j DNAT --to 192.168.0.1 iptables -t nat -D OUTPUT -d 80.126.170.174 -p tcp --dport http -j DNAT --to 192.168.0.1 ip route del default ip addr del 80.126.170.174 dev eth0 on a dual PIII during a shutdown: kernel: BUG: using smp_processor_id() in preemptible [0001] code: ip/6840 kernel: caller is get_next_corpse+0x13/0x260 kernel: [c010385e] dump_stack+0x1e/0x30 kernel: [c024f13f] smp_processor_id+0xaf/0xc0 kernel: [c0407d83] get_next_corpse+0x13/0x260 kernel: [c0408006] ip_ct_iterate_cleanup+0x36/0xc0 kernel: [c041896a] masq_inet_event+0x3a/0x70 kernel: [c012eded] notifier_call_chain+0x2d/0x50 kernel: [c03ef589] inet_del_ifa+0x99/0x150 kernel: [c03efafb] inet_rtm_deladdr+0x12b/0x170 kernel: [c03b1f47] rtnetlink_rcv+0x347/0x410 kernel: [c03c1b10] netlink_data_ready+0x60/0x70 kernel: [c03c0f71] netlink_sendskb+0x31/0x60 kernel: [c03c17e9] netlink_sendmsg+0x259/0x310 kernel: [c039e87b] sock_sendmsg+0xbb/0xe0 kernel: [c03a0424] sys_sendmsg+0x1c4/0x230 kernel: [c03a08cc] sys_socketcall+0x21c/0x240 kernel: [c01029f3] syscall_call+0x7/0xb kernel: BUG: using smp_processor_id() in preemptible [0001] code: ip/6840 kernel: caller is get_next_corpse+0x23f/0x260 kernel: [c010385e] dump_stack+0x1e/0x30 kernel: [c024f13f] smp_processor_id+0xaf/0xc0 kernel: [c0407faf] get_next_corpse+0x23f/0x260 kernel: [c0408006] ip_ct_iterate_cleanup+0x36/0xc0 kernel: [c041896a] masq_inet_event+0x3a/0x70 kernel: [c012eded] notifier_call_chain+0x2d/0x50 kernel: [c03ef589] inet_del_ifa+0x99/0x150 kernel: [c03efafb] inet_rtm_deladdr+0x12b/0x170 kernel: [c03b1f47] rtnetlink_rcv+0x347/0x410 kernel: [c03c1b10] netlink_data_ready+0x60/0x70 kernel: [c03c0f71] netlink_sendskb+0x31/0x60 kernel: [c03c17e9] netlink_sendmsg+0x259/0x310 kernel: [c039e87b] sock_sendmsg+0xbb/0xe0 kernel: [c03a0424] sys_sendmsg+0x1c4/0x230 kernel: [c03a08cc] sys_socketcall+0x21c/0x240 kernel: [c01029f3] syscall_call+0x7/0xb Hi! You have to use get_cpu() or __smp_processor_id() to avoid this debug message. Have a look at inlcude/linux/smp.h and include/asm-i386/smp.h. Matthias-Christian Ott - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0)
Matthias-Christian Ott wrote: Mirko Parthey wrote: On Mon, Jan 31, 2005 at 05:22:02PM +0100, wrote: My Debian machine hangs during shutdown, with messages like this: unregister_netdevice: waiting for br0 to become free. Usage count = 1 I narrowed it down to the command # brctl delbr br0 which does not return in the circumstances shown below. The problem is reproducible with both 2.6.11-rc2 from kernel.org and the Debian kernel-image-2.6.10-1-686. [...] The problem was introduced between 2.6.8.1 and 2.6.9, and it is still present in 2.6.11-rc2-bk9. Mirko - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Jep it appears in 2.6.8 and above. I don't know the process who's using it: Before shutdown: PID TTY TIME CMD 1 ?00:00:00 init 2 ?00:00:00 ksoftirqd/0 3 ?00:00:00 events/0 4 ?00:00:00 khelper 9 ?00:00:00 kthread 19 ?00:00:00 kacpid 17 ?00:00:00 vesafb 100 ?00:00:00 kblockd/0 164 ?00:00:00 pdflush 165 ?00:00:00 pdflush 166 ?00:00:00 kswapd0 167 ?00:00:00 aio/0 168 ?00:00:00 jfsIO 169 ?00:00:00 jfsCommit 170 ?00:00:00 jfsSync 171 ?00:00:00 xfslogd/0 172 ?00:00:00 xfsdatad/0 173 ?00:00:00 xfsbufd 774 ?00:00:00 kseriod 862 ?00:00:00 ata/0 882 ?00:00:00 kcryptd/0 883 ?00:00:00 kmirrord/0 887 ?00:00:00 xfssyncd 939 ?00:00:00 udevd 1061 ?00:00:00 devfsd 1242 ?00:00:00 khubd 1616 ?00:00:00 syslog-ng 2562 ?00:00:00 khpsbpkt 2646 ?00:00:00 knodemgrd_0 3987 ?00:00:00 crond 4027 tty2 00:00:00 agetty 4028 tty3 00:00:00 agetty 4029 tty4 00:00:00 agetty 4030 tty5 00:00:00 agetty 4031 tty6 00:00:00 agetty 4473 tty1 00:00:00 bash 4553 tty1 00:00:00 ps And my System can't shutdown because of this bug. Currently disabling this checking function seems to be the only solution (see my diff). Matthias-Christian Ott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Well I think my problem was not ipv6 problem Herbert discribed, it was syslog-ng. I replaced it with metalog and it seems to work well (I'll test it with 2.6.11-rc3 today). Matthias-Christian Ott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0)
Matthias-Christian Ott wrote: Mirko Parthey wrote: On Mon, Jan 31, 2005 at 05:22:02PM +0100, wrote: My Debian machine hangs during shutdown, with messages like this: unregister_netdevice: waiting for br0 to become free. Usage count = 1 I narrowed it down to the command # brctl delbr br0 which does not return in the circumstances shown below. The problem is reproducible with both 2.6.11-rc2 from kernel.org and the Debian kernel-image-2.6.10-1-686. [...] The problem was introduced between 2.6.8.1 and 2.6.9, and it is still present in 2.6.11-rc2-bk9. Mirko - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Jep it appears in 2.6.8 and above. I don't know the process who's using it: Before shutdown: PID TTY TIME CMD 1 ?00:00:00 init 2 ?00:00:00 ksoftirqd/0 3 ?00:00:00 events/0 4 ?00:00:00 khelper 9 ?00:00:00 kthread 19 ?00:00:00 kacpid 17 ?00:00:00 vesafb 100 ?00:00:00 kblockd/0 164 ?00:00:00 pdflush 165 ?00:00:00 pdflush 166 ?00:00:00 kswapd0 167 ?00:00:00 aio/0 168 ?00:00:00 jfsIO 169 ?00:00:00 jfsCommit 170 ?00:00:00 jfsSync 171 ?00:00:00 xfslogd/0 172 ?00:00:00 xfsdatad/0 173 ?00:00:00 xfsbufd 774 ?00:00:00 kseriod 862 ?00:00:00 ata/0 882 ?00:00:00 kcryptd/0 883 ?00:00:00 kmirrord/0 887 ?00:00:00 xfssyncd 939 ?00:00:00 udevd 1061 ?00:00:00 devfsd 1242 ?00:00:00 khubd 1616 ?00:00:00 syslog-ng 2562 ?00:00:00 khpsbpkt 2646 ?00:00:00 knodemgrd_0 3987 ?00:00:00 crond 4027 tty2 00:00:00 agetty 4028 tty3 00:00:00 agetty 4029 tty4 00:00:00 agetty 4030 tty5 00:00:00 agetty 4031 tty6 00:00:00 agetty 4473 tty1 00:00:00 bash 4553 tty1 00:00:00 ps And my System can't shutdown because of this bug. Currently disabling this checking function seems to be the only solution (see my diff). Matthias-Christian Ott - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Well I think my problem was not ipv6 problem Herbert discribed, it was syslog-ng. I replaced it with metalog and it seems to work well (I'll test it with 2.6.11-rc3 today). Matthias-Christian Ott - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 Patch] speedstep-lib.c: fix frequency multiplier for Pentium4 models 0&1
The Pentium4 models 0&1 have a longer MSR_EBC_FREQUENCY_ID register as
the models 2&3, so the bit shift must be bigger.
Signed-off-by: Matthias-Christian Ott <[EMAIL PROTECTED]>
diff -Nurp linux-2.6.11-rc3/arch/i386/kernel/cpu/cpufreq/speedstep-lib.c
linux-2.6.11-rc3-ott/arch/i386/kernel/cpu/cpufreq/speedstep-lib.c
--- linux-2.6.11-rc3/arch/i386/kernel/cpu/cpufreq/speedstep-lib.c
2004-12-24 22:35:27.0 +0100
+++ linux-2.6.11-rc3-ott/arch/i386/kernel/cpu/cpufreq/speedstep-lib.c
2005-02-03 16:04:59.0 +0100
@@ -160,7 +160,14 @@ static unsigned int pentium4_get_frequen
printk(KERN_DEBUG "speedstep-lib: couldn't detect FSB speed.
Please send an e-mail to <[EMAIL PROTECTED]>\n");
/* Multiplier. */
-mult = msr_lo >> 24;
+if (c->x86_model < 2)
+{
+mult = msr_lo >> 27;
+}
+else
+{
+mult = msr_lo >> 24;
+}
dprintk("P4 - FSB %u kHz; Multiplier %u; Speed %u kHz\n", fsb,
mult, (fsb * mult));
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 Patch] speedstep-lib.c: fix frequency multiplier for Pentium4 models 01
The Pentium4 models 01 have a longer MSR_EBC_FREQUENCY_ID register as
the models 23, so the bit shift must be bigger.
Signed-off-by: Matthias-Christian Ott [EMAIL PROTECTED]
diff -Nurp linux-2.6.11-rc3/arch/i386/kernel/cpu/cpufreq/speedstep-lib.c
linux-2.6.11-rc3-ott/arch/i386/kernel/cpu/cpufreq/speedstep-lib.c
--- linux-2.6.11-rc3/arch/i386/kernel/cpu/cpufreq/speedstep-lib.c
2004-12-24 22:35:27.0 +0100
+++ linux-2.6.11-rc3-ott/arch/i386/kernel/cpu/cpufreq/speedstep-lib.c
2005-02-03 16:04:59.0 +0100
@@ -160,7 +160,14 @@ static unsigned int pentium4_get_frequen
printk(KERN_DEBUG speedstep-lib: couldn't detect FSB speed.
Please send an e-mail to [EMAIL PROTECTED]\n);
/* Multiplier. */
-mult = msr_lo 24;
+if (c-x86_model 2)
+{
+mult = msr_lo 27;
+}
+else
+{
+mult = msr_lo 24;
+}
dprintk(P4 - FSB %u kHz; Multiplier %u; Speed %u kHz\n, fsb,
mult, (fsb * mult));
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0)
Mirko Parthey wrote: On Mon, Jan 31, 2005 at 05:22:02PM +0100, wrote: My Debian machine hangs during shutdown, with messages like this: unregister_netdevice: waiting for br0 to become free. Usage count = 1 I narrowed it down to the command # brctl delbr br0 which does not return in the circumstances shown below. The problem is reproducible with both 2.6.11-rc2 from kernel.org and the Debian kernel-image-2.6.10-1-686. [...] The problem was introduced between 2.6.8.1 and 2.6.9, and it is still present in 2.6.11-rc2-bk9. Mirko - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Jep it appears in 2.6.8 and above. I don't know the process who's using it: Before shutdown: PID TTY TIME CMD 1 ?00:00:00 init 2 ?00:00:00 ksoftirqd/0 3 ?00:00:00 events/0 4 ?00:00:00 khelper 9 ?00:00:00 kthread 19 ?00:00:00 kacpid 17 ?00:00:00 vesafb 100 ?00:00:00 kblockd/0 164 ?00:00:00 pdflush 165 ?00:00:00 pdflush 166 ?00:00:00 kswapd0 167 ?00:00:00 aio/0 168 ?00:00:00 jfsIO 169 ?00:00:00 jfsCommit 170 ?00:00:00 jfsSync 171 ?00:00:00 xfslogd/0 172 ?00:00:00 xfsdatad/0 173 ?00:00:00 xfsbufd 774 ?00:00:00 kseriod 862 ?00:00:00 ata/0 882 ?00:00:00 kcryptd/0 883 ?00:00:00 kmirrord/0 887 ?00:00:00 xfssyncd 939 ?00:00:00 udevd 1061 ?00:00:00 devfsd 1242 ?00:00:00 khubd 1616 ?00:00:00 syslog-ng 2562 ?00:00:00 khpsbpkt 2646 ?00:00:00 knodemgrd_0 3987 ?00:00:00 crond 4027 tty2 00:00:00 agetty 4028 tty3 00:00:00 agetty 4029 tty4 00:00:00 agetty 4030 tty5 00:00:00 agetty 4031 tty6 00:00:00 agetty 4473 tty1 00:00:00 bash 4553 tty1 00:00:00 ps And my System can't shutdown because of this bug. Currently disabling this checking function seems to be the only solution (see my diff). Matthias-Christian Ott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0)
Mirko Parthey wrote: On Mon, Jan 31, 2005 at 05:22:02PM +0100, wrote: My Debian machine hangs during shutdown, with messages like this: unregister_netdevice: waiting for br0 to become free. Usage count = 1 I narrowed it down to the command # brctl delbr br0 which does not return in the circumstances shown below. The problem is reproducible with both 2.6.11-rc2 from kernel.org and the Debian kernel-image-2.6.10-1-686. [...] The problem was introduced between 2.6.8.1 and 2.6.9, and it is still present in 2.6.11-rc2-bk9. Mirko - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Jep it appears in 2.6.8 and above. I don't know the process who's using it: Before shutdown: PID TTY TIME CMD 1 ?00:00:00 init 2 ?00:00:00 ksoftirqd/0 3 ?00:00:00 events/0 4 ?00:00:00 khelper 9 ?00:00:00 kthread 19 ?00:00:00 kacpid 17 ?00:00:00 vesafb 100 ?00:00:00 kblockd/0 164 ?00:00:00 pdflush 165 ?00:00:00 pdflush 166 ?00:00:00 kswapd0 167 ?00:00:00 aio/0 168 ?00:00:00 jfsIO 169 ?00:00:00 jfsCommit 170 ?00:00:00 jfsSync 171 ?00:00:00 xfslogd/0 172 ?00:00:00 xfsdatad/0 173 ?00:00:00 xfsbufd 774 ?00:00:00 kseriod 862 ?00:00:00 ata/0 882 ?00:00:00 kcryptd/0 883 ?00:00:00 kmirrord/0 887 ?00:00:00 xfssyncd 939 ?00:00:00 udevd 1061 ?00:00:00 devfsd 1242 ?00:00:00 khubd 1616 ?00:00:00 syslog-ng 2562 ?00:00:00 khpsbpkt 2646 ?00:00:00 knodemgrd_0 3987 ?00:00:00 crond 4027 tty2 00:00:00 agetty 4028 tty3 00:00:00 agetty 4029 tty4 00:00:00 agetty 4030 tty5 00:00:00 agetty 4031 tty6 00:00:00 agetty 4473 tty1 00:00:00 bash 4553 tty1 00:00:00 ps And my System can't shutdown because of this bug. Currently disabling this checking function seems to be the only solution (see my diff). Matthias-Christian Ott - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[NDISWRAPPER]: Belkin 6001DE: iwconfig: not able to change parameters
Hi! I have a Belkin 6001DE, I tried get it working with ndiswrapper (I tried 4 different drivers), but I wasn't able to change wireless parameters, e.g. the essid. I followed a instructions from the wiki. Compiling ndiswrapper with debug=3 didn't give an additional information. [EMAIL PROTECTED] ~]# lspci -v 02:01.0 Ethernet controller: Belkin: Unknown device 6001 (rev 20) Subsystem: Belkin: Unknown device 6001 Flags: bus master, medium devsel, latency 32, IRQ 12 I/O ports at 9000 [size=256] Memory at e3003000 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 2 [EMAIL PROTECTED] ~]# cat /proc/pci Bus 2, device 1, function 0: Ethernet controller: Belkin Wireless PCI Card - F5D6001 (rev 32). IRQ 12. Master Capable. Latency=32. Min Gnt=32.Max Lat=64. I/O at 0x9000 [0x90ff]. Non-prefetchable 32 bit memory at 0xe3003000 [0xe30030ff]. How can I get it working? Thanks Matthias-Christian Ott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[NDISWRAPPER]: Belkin 6001DE: iwconfig: not able to change parameters
Hi! I have a Belkin 6001DE, I tried get it working with ndiswrapper (I tried 4 different drivers), but I wasn't able to change wireless parameters, e.g. the essid. I followed a instructions from the wiki. Compiling ndiswrapper with debug=3 didn't give an additional information. [EMAIL PROTECTED] ~]# lspci -v 02:01.0 Ethernet controller: Belkin: Unknown device 6001 (rev 20) Subsystem: Belkin: Unknown device 6001 Flags: bus master, medium devsel, latency 32, IRQ 12 I/O ports at 9000 [size=256] Memory at e3003000 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 2 [EMAIL PROTECTED] ~]# cat /proc/pci Bus 2, device 1, function 0: Ethernet controller: Belkin Wireless PCI Card - F5D6001 (rev 32). IRQ 12. Master Capable. Latency=32. Min Gnt=32.Max Lat=64. I/O at 0x9000 [0x90ff]. Non-prefetchable 32 bit memory at 0xe3003000 [0xe30030ff]. How can I get it working? Thanks Matthias-Christian Ott - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 PATCH] sound/usb/usx2y/usbusx2yaudio.c: remove unused ep
The pointer ep was not used. Signed-off-by: Matthias-Christian Ott <[EMAIL PROTECTED]> diff -Nrup linux-2.6.11-rc2/sound/usb/usx2y/usbusx2yaudio.c linux-2.6.11-rc2-ott/sound/usb/usx2y/usbusx2yaudio.c --- linux-2.6.11-rc2/sound/usb/usx2y/usbusx2yaudio.c2005-01-26 22:27:37.0 +0100 +++ linux-2.6.11-rc2-ott/sound/usb/usx2y/usbusx2yaudio.c2005-01-31 19:56:57.0 +0100 @@ -415,7 +415,6 @@ static int usX2Y_urbs_allocate(snd_usX2Y unsigned int pipe; int is_playback = subs == subs->usX2Y->subs[SNDRV_PCM_STREAM_PLAYBACK]; struct usb_device *dev = subs->usX2Y->chip.dev; -struct usb_host_endpoint *ep; pipe = is_playback ? usb_sndisocpipe(dev, subs->endpoint) : usb_rcvisocpipe(dev, subs->endpoint); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0)
Mirko Parthey wrote: My Debian machine hangs during shutdown, with messages like this: unregister_netdevice: waiting for br0 to become free. Usage count = 1 I narrowed it down to the command # brctl delbr br0 which does not return in the circumstances shown below. The problem is reproducible with both 2.6.11-rc2 from kernel.org and the Debian kernel-image-2.6.10-1-686. My .config is taken from the above mentioned Debian kernel, adapted to 2.6.11-rc2 and the processor type set to Pentium Classic. (I can email the .config on request). How to reproduce the problem (I tried this on a Pentium 4 machine): boot: linux init=/bin/bash [...booting...] # mount proc -t proc /proc # ifconfig lo 127.0.0.1 # brctl addbr br0 # modprobe e100 # also reproducible with 3c5x9 # brctl addif br0 eth0 # ifconfig br0 192.168.1.1 # ifconfig eth0 up # ifconfig lo down # lsmod | grep bridge bridge 4 0 # brctl delif br0 eth0 # ifconfig br0 down # brctl delbr br0 unregister_netdevice: waiting for br0 to become free. Usage count = 1 unregister_netdevice: waiting for br0 to become free. Usage count = 1 [...this message again and again, but no progress...] I'm also surprised that the reference count for the bridge module is zero, even when it is in use. Please let me know if you need any further information, and please Cc me on replies (I am not subscribed to linux-kernel). Thanks, Mirko - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Hi! I have a similar problem with my wlan modul, this patch should fix it (I disables the check function [untested]): diff -Nru linux-2.6.11-rc2/net/core/dev.c linux-2.6.11-rc2-ott/net/core/dev.c --- linux-2.6.11-rc2/net/core/dev.c2005-01-26 22:27:31.0 +0100 +++ linux-2.6.11-rc2-ott/net/core/dev.c2005-01-31 00:47:34.0 +0100 @@ -2974,7 +2974,7 @@ netdev_unregister_sysfs(dev); dev->reg_state = NETREG_UNREGISTERED; -netdev_wait_allrefs(dev); +//netdev_wait_allrefs(dev); /* paranoia */ BUG_ON(atomic_read(>refcnt)); Matthias-Christian Ott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: My System doesn't use swap!
Michael Buesch wrote: Quoting Matthias-Christian Ott <[EMAIL PROTECTED]>: Hi! I have mysterious Problem: 90 % of my Ram are used (340 MB), but 0 Byte of my Swap (2GB) is used and about about 150 MB are swappable. [EMAIL PROTECTED] ~]$ free total used free sharedbuffers cached Mem:383868 362176 21692 0 12 208956 -/+ buffers/cache: 153208 230660 ^^ You have ~230M of 380M free. Nothing mysterious here. Swap: 2097136 02097136 [EMAIL PROTECTED] ~]$ cat /kernel-2.6.10-rc2-ott/config [..] CONFIG_SWAP=y [..] CONFIG_X86_BSWAP=y [..] [EMAIL PROTECTED] ~]$ dmesg [..] Adding 2097136k swap on /dev/discs/disc0/part2. Priority:-1 extents:1 [..] Matthias-Christian Ott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Ok maybe I wasn't able to read the /free/ output correctly, but why is no swap used (more than 60% ram are used)? Matthias-Christian Ott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
My System doesn't use swap!
Hi! I have mysterious Problem: 90 % of my Ram are used (340 MB), but 0 Byte of my Swap (2GB) is used and about about 150 MB are swappable. [EMAIL PROTECTED] ~]$ free total used free sharedbuffers cached Mem:383868 362176 21692 0 12 208956 -/+ buffers/cache: 153208 230660 Swap: 2097136 02097136 [EMAIL PROTECTED] ~]$ cat /kernel-2.6.10-rc2-ott/config [..] CONFIG_SWAP=y [..] CONFIG_X86_BSWAP=y [..] [EMAIL PROTECTED] ~]$ dmesg [..] Adding 2097136k swap on /dev/discs/disc0/part2. Priority:-1 extents:1 [..] Matthias-Christian Ott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 PATCH] sound/usb/usx2y/usbusx2yaudio.c: remove unused ep
The pointer ep was not used. Signed-off-by: Matthias-Christian Ott [EMAIL PROTECTED] diff -Nrup linux-2.6.11-rc2/sound/usb/usx2y/usbusx2yaudio.c linux-2.6.11-rc2-ott/sound/usb/usx2y/usbusx2yaudio.c --- linux-2.6.11-rc2/sound/usb/usx2y/usbusx2yaudio.c2005-01-26 22:27:37.0 +0100 +++ linux-2.6.11-rc2-ott/sound/usb/usx2y/usbusx2yaudio.c2005-01-31 19:56:57.0 +0100 @@ -415,7 +415,6 @@ static int usX2Y_urbs_allocate(snd_usX2Y unsigned int pipe; int is_playback = subs == subs-usX2Y-subs[SNDRV_PCM_STREAM_PLAYBACK]; struct usb_device *dev = subs-usX2Y-chip.dev; -struct usb_host_endpoint *ep; pipe = is_playback ? usb_sndisocpipe(dev, subs-endpoint) : usb_rcvisocpipe(dev, subs-endpoint); - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 patch] add compiler-gcc4.h
Andi Kleen wrote: Adrian Bunk <[EMAIL PROTECTED]> writes: With the release of gcc 4.0 being only a few months away and people already tring compiling with it, it's time for adding a compiler-gcc4.h . This patch contains the following changes: - compiler-gcc+.h: add the missing noinline and __compiler_offsetof - compiler-gcc4.h: new file based on the corrected compiler-gcc+.h - compiler.h: include compiler-gcc4.h for gcc 4 - compiler-gcc3.h: remove __compiler_offsetof (there will never be a gcc 3.5) small indention corrections I don't think it makes much sense right now because it's basically identical to compiler-gcc3.h. I would only add it where there is a need for a real difference. -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/ Hi! But maybe gcc 4 will get different later, so I think this patch makes sense. Matthias-Christian Ott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Preempt & Xfs Question
Chris Wedgwood wrote: On Thu, Jan 27, 2005 at 06:24:13PM +, Matthias-Christian Ott wrote: Well calling such a internal function (__function) is not a cleaning coding style but works best :-) . __foo does NOT mean it's an internal function necessarily or that it's unclean to use it (sadly Linux has pretty vague (nothing consistent) rules on how to interpret __foo versus foo really. Combined with the current_cpu() fixes I mentioned, it looks like this: (1) your patch is mangled/wrapped (2) this is fixed in CVS already (for maybe a week or so now?) I'll submit it to the mailinglist as a seperate patch, so Linus can apply it to the current Kernel. XFS patches/suggestions should go to linux-xfs@oss.sgi.com and the maintainers there can comment as needed. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Hi! I didn't know about the xfs development status. But it's good to hear that it's already fixed. When will it be included to the Kernel? Matthias-Christian Ott -- http://unixforge.org/~matthias-christian-ott/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Preempt & Xfs Question
Chris Wedgwood wrote: On Thu, Jan 27, 2005 at 05:46:54PM +, Matthias-Christian Ott wrote: How did you fix it? I suggested: = fs/xfs/linux-2.6/xfs_stats.h 1.9 vs edited = Index: cw-current/fs/xfs/linux-2.6/xfs_stats.h === --- cw-current.orig/fs/xfs/linux-2.6/xfs_stats.h2005-01-17 16:03:59.656946818 -0800 +++ cw-current/fs/xfs/linux-2.6/xfs_stats.h 2005-01-17 16:06:50.692361597 -0800 @@ -142,9 +142,9 @@ /* We don't disable preempt, not too worried about poking the * wrong cpu's stat for now */ -#define XFS_STATS_INC(count) (__get_cpu_var(xfsstats).count++) -#define XFS_STATS_DEC(count) (__get_cpu_var(xfsstats).count--) -#define XFS_STATS_ADD(count, inc) (__get_cpu_var(xfsstats).count += (inc)) +#define XFS_STATS_INC(count) (per_cpu(xfsstats, __smp_processor_id()).count++) +#define XFS_STATS_DEC(count) (per_cpu(xfsstats, __smp_processor_id()).count--) +#define XFS_STATS_ADD(count, inc) (per_cpu(xfsstats, __smp_processor_id()).count += (inc)) extern void xfs_init_procfs(void); extern void xfs_cleanup_procfs(void); but what was checked in was a bit cleaner. Well calling such a internal function (__function) is not a cleaning coding style but works best :-) . Combined with the current_cpu() fixes I mentioned, it looks like this: diff -Nru linux-2.6.11-rc2/fs/xfs/linux-2.6/xfs_linux.h linux-2.6.11-rc2-ott/fs/xfs/linux-2.6/xfs_linux.h --- linux-2.6.11-rc2/fs/xfs/linux-2.6/xfs_linux.h2004-12-24 21:35:50.0 + +++ linux-2.6.11-rc2-ott/fs/xfs/linux-2.6/xfs_linux.h2005-01-27 18:13:09.0 + @@ -144,7 +144,7 @@ #define xfs_inherit_nosymlinksxfs_params.inherit_nosym.val #define xfs_rotorstepxfs_params.rotorstep.val -#define current_cpu()smp_processor_id() +#define current_cpu()__smp_processor_id() #define current_pid()(current->pid) #define current_fsuid(cred)(current->fsuid) #define current_fsgid(cred)(current->fsgid) diff -Nru linux-2.6.11-rc2/fs/xfs/linux-2.6/xfs_stats.h linux-2.6.11-rc2-ott/fs/xfs/linux-2.6/xfs_stats.h --- linux-2.6.11-rc2/fs/xfs/linux-2.6/xfs_stats.h2004-12-24 21:34:29.0 + +++ linux-2.6.11-rc2-ott/fs/xfs/linux-2.6/xfs_stats.h2005-01-27 18:13:44.0 + @@ -142,9 +142,9 @@ /* We don't disable preempt, not too worried about poking the * wrong cpu's stat for now */ -#define XFS_STATS_INC(count)(__get_cpu_var(xfsstats).count++) -#define XFS_STATS_DEC(count)(__get_cpu_var(xfsstats).count--) -#define XFS_STATS_ADD(count, inc)(__get_cpu_var(xfsstats).count += (inc)) +#define XFS_STATS_INC(count)(per_cpu(xfsstats, __smp_processor_id()).count++) +#define XFS_STATS_DEC(count)(per_cpu(xfsstats, __smp_processor_id()).count--) +#define XFS_STATS_ADD(count, inc)(per_cpu(xfsstats, __smp_processor_id()).count += (inc)) extern void xfs_init_procfs(void); extern void xfs_cleanup_procfs(void); I'll submit it to the mailinglist as a seperate patch, so Linus can apply it to the current Kernel. Matthias-Christian Ott -- http://unixforge.org/~matthias-christian-ott/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Preempt & Xfs Question
Chris Wedgwood wrote: BUG: using smp_processor_id() in preemptible [0001] code: khelper/892 fixed in CVS, I guess it will hit mainline soon How did you fix it? Matthias-Christian Ott -- http://unixforge.org/~matthias-christian-ott/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Preempt & Xfs Question
Steve Lord wrote: Matthias-Christian Ott wrote: Hi! I have a question: Why do I get such debug messages: BUG: using smp_processor_id() in preemptible [0001] code: khelper/892 caller is _pagebuf_lookup_pages+0x11b/0x362 [] smp_processor_id+0xa3/0xb4 [] _pagebuf_lookup_pages+0x11b/0x362 [] _pagebuf_lookup_pages+0x11b/0x362 . Does the XFS Module avoid preemption rules? If so, why? It is probably coming from these macros which keep various statistics inside xfs as per cpu variables. in fs//xfs/linux-2.6/xfs_stats.h: DECLARE_PER_CPU(struct xfsstats, xfsstats); /* We don't disable preempt, not too worried about poking the * wrong cpu's stat for now */ #define XFS_STATS_INC(count)(__get_cpu_var(xfsstats).count++) #define XFS_STATS_DEC(count)(__get_cpu_var(xfsstats).count--) #define XFS_STATS_ADD(count, inc) (__get_cpu_var(xfsstats).count += (inc)) So it knows about the fact that preemption can mess up the result of this, but it does not really matter for the purpose it is used for here. The stats are just informational but very handy for working out what is going on inside xfs. Using a global instead of a per cpu variable would lead to cache line contention. If you want to make it go away on a preemptable kernel, then use the alternate definition of the stat macros which is just below the above code. Steve p.s. try running xfs_stats.pl -f which comes with the xfs-cmds source to watch the stats. Hi! It happens to all functions -- not only to the stat functions -- because of this macro: #define current_cpu() smp_processor_id() But this it not my problem (setting it 0 fixes it or get_cpu()). I just wanted to know why it breaks the preemption rules. Matthias-Christian -- http://unixforge.org/~matthias-christian-ott/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Preempt & Xfs Question
Hi! I have a question: Why do I get such debug messages: BUG: using smp_processor_id() in preemptible [0001] code: khelper/892 caller is _pagebuf_lookup_pages+0x11b/0x362 [] smp_processor_id+0xa3/0xb4 [] _pagebuf_lookup_pages+0x11b/0x362 [] _pagebuf_lookup_pages+0x11b/0x362 [] xfs_buf_get_flags+0x106/0x141 [] xfs_buf_read_flags+0x3e/0xae [] xfs_trans_read_buf+0x18b/0x389 [] xfs_da_do_buf+0x735/0x88c [] run_timer_softirq+0x12d/0x1c7 [] xfs_da_read_buf+0x47/0x4b [] xfs_dir2_block_lookup_int+0x52/0x1b4 [] xfs_dir2_block_lookup_int+0x52/0x1b4 [] vprintk+0x133/0x16a [] kernel_thread_helper+0x5/0xb [] __kernel_text_address+0x28/0x36 [] xfs_dir2_block_lookup+0x2f/0xef [] xfs_dir2_isblock+0x2c/0x74 [] xfs_dir2_lookup+0x176/0x186 [] __print_symbol+0x86/0xef [] xfs_dir_lookup_int+0x4c/0x144 [] _spin_lock+0x16/0x7c [] xfs_lookup+0x55/0x8a [] linvfs_lookup+0x52/0x99 [] real_lookup+0xc2/0xe3 [] do_lookup+0x96/0xa1 [] link_path_walk+0x199/0xe3a [] do_notify_parent+0x108/0x214 [] path_lookup+0x97/0x15f [] open_exec+0x2f/0x102 [] task_rq_lock+0x36/0x66 [] do_execve+0x42/0x201 [] sys_execve+0x46/0x9c [] syscall_call+0x7/0xb [] call_usermodehelper+0xa1/0xc0 [] call_usermodehelper+0x0/0xc0 [] kernel_thread_helper+0x5/0xb Does the XFS Module avoid preemption rules? If so, why? Thanks Matthias-Christian Ott -- http://unixforge.org/~matthias-christian-ott/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Preempt Xfs Question
Hi! I have a question: Why do I get such debug messages: BUG: using smp_processor_id() in preemptible [0001] code: khelper/892 caller is _pagebuf_lookup_pages+0x11b/0x362 [c03119c7] smp_processor_id+0xa3/0xb4 [c02ef802] _pagebuf_lookup_pages+0x11b/0x362 [c02ef802] _pagebuf_lookup_pages+0x11b/0x362 [c02efe31] xfs_buf_get_flags+0x106/0x141 [c02efeaa] xfs_buf_read_flags+0x3e/0xae [c02e0fd5] xfs_trans_read_buf+0x18b/0x389 [c02ada32] xfs_da_do_buf+0x735/0x88c [c0127f46] run_timer_softirq+0x12d/0x1c7 [c02adc1b] xfs_da_read_buf+0x47/0x4b [c02b1b22] xfs_dir2_block_lookup_int+0x52/0x1b4 [c02b1b22] xfs_dir2_block_lookup_int+0x52/0x1b4 [c011f189] vprintk+0x133/0x16a [c0101319] kernel_thread_helper+0x5/0xb [c0130253] __kernel_text_address+0x28/0x36 [c02b1a10] xfs_dir2_block_lookup+0x2f/0xef [c02b0967] xfs_dir2_isblock+0x2c/0x74 [c02aff4e] xfs_dir2_lookup+0x176/0x186 [c01389d9] __print_symbol+0x86/0xef [c02e214e] xfs_dir_lookup_int+0x4c/0x144 [c04cf6aa] _spin_lock+0x16/0x7c [c02e7cc8] xfs_lookup+0x55/0x8a [c02f4736] linvfs_lookup+0x52/0x99 [c01698a2] real_lookup+0xc2/0xe3 [c0169b2c] do_lookup+0x96/0xa1 [c0169cd0] link_path_walk+0x199/0xe3a [c012a2f1] do_notify_parent+0x108/0x214 [c016ac39] path_lookup+0x97/0x15f [c0166612] open_exec+0x2f/0x102 [c011834b] task_rq_lock+0x36/0x66 [c01676ed] do_execve+0x42/0x201 [c0101cc1] sys_execve+0x46/0x9c [c010318b] syscall_call+0x7/0xb [c012e60e] call_usermodehelper+0xa1/0xc0 [c012e56d] call_usermodehelper+0x0/0xc0 [c0101319] kernel_thread_helper+0x5/0xb Does the XFS Module avoid preemption rules? If so, why? Thanks Matthias-Christian Ott -- http://unixforge.org/~matthias-christian-ott/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Preempt Xfs Question
Steve Lord wrote: Matthias-Christian Ott wrote: Hi! I have a question: Why do I get such debug messages: BUG: using smp_processor_id() in preemptible [0001] code: khelper/892 caller is _pagebuf_lookup_pages+0x11b/0x362 [c03119c7] smp_processor_id+0xa3/0xb4 [c02ef802] _pagebuf_lookup_pages+0x11b/0x362 [c02ef802] _pagebuf_lookup_pages+0x11b/0x362 . Does the XFS Module avoid preemption rules? If so, why? It is probably coming from these macros which keep various statistics inside xfs as per cpu variables. in fs//xfs/linux-2.6/xfs_stats.h: DECLARE_PER_CPU(struct xfsstats, xfsstats); /* We don't disable preempt, not too worried about poking the * wrong cpu's stat for now */ #define XFS_STATS_INC(count)(__get_cpu_var(xfsstats).count++) #define XFS_STATS_DEC(count)(__get_cpu_var(xfsstats).count--) #define XFS_STATS_ADD(count, inc) (__get_cpu_var(xfsstats).count += (inc)) So it knows about the fact that preemption can mess up the result of this, but it does not really matter for the purpose it is used for here. The stats are just informational but very handy for working out what is going on inside xfs. Using a global instead of a per cpu variable would lead to cache line contention. If you want to make it go away on a preemptable kernel, then use the alternate definition of the stat macros which is just below the above code. Steve p.s. try running xfs_stats.pl -f which comes with the xfs-cmds source to watch the stats. Hi! It happens to all functions -- not only to the stat functions -- because of this macro: #define current_cpu() smp_processor_id() But this it not my problem (setting it 0 fixes it or get_cpu()). I just wanted to know why it breaks the preemption rules. Matthias-Christian -- http://unixforge.org/~matthias-christian-ott/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Preempt Xfs Question
Chris Wedgwood wrote: BUG: using smp_processor_id() in preemptible [0001] code: khelper/892 fixed in CVS, I guess it will hit mainline soon How did you fix it? Matthias-Christian Ott -- http://unixforge.org/~matthias-christian-ott/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Preempt Xfs Question
Chris Wedgwood wrote: On Thu, Jan 27, 2005 at 05:46:54PM +, Matthias-Christian Ott wrote: How did you fix it? I suggested: = fs/xfs/linux-2.6/xfs_stats.h 1.9 vs edited = Index: cw-current/fs/xfs/linux-2.6/xfs_stats.h === --- cw-current.orig/fs/xfs/linux-2.6/xfs_stats.h2005-01-17 16:03:59.656946818 -0800 +++ cw-current/fs/xfs/linux-2.6/xfs_stats.h 2005-01-17 16:06:50.692361597 -0800 @@ -142,9 +142,9 @@ /* We don't disable preempt, not too worried about poking the * wrong cpu's stat for now */ -#define XFS_STATS_INC(count) (__get_cpu_var(xfsstats).count++) -#define XFS_STATS_DEC(count) (__get_cpu_var(xfsstats).count--) -#define XFS_STATS_ADD(count, inc) (__get_cpu_var(xfsstats).count += (inc)) +#define XFS_STATS_INC(count) (per_cpu(xfsstats, __smp_processor_id()).count++) +#define XFS_STATS_DEC(count) (per_cpu(xfsstats, __smp_processor_id()).count--) +#define XFS_STATS_ADD(count, inc) (per_cpu(xfsstats, __smp_processor_id()).count += (inc)) extern void xfs_init_procfs(void); extern void xfs_cleanup_procfs(void); but what was checked in was a bit cleaner. Well calling such a internal function (__function) is not a cleaning coding style but works best :-) . Combined with the current_cpu() fixes I mentioned, it looks like this: diff -Nru linux-2.6.11-rc2/fs/xfs/linux-2.6/xfs_linux.h linux-2.6.11-rc2-ott/fs/xfs/linux-2.6/xfs_linux.h --- linux-2.6.11-rc2/fs/xfs/linux-2.6/xfs_linux.h2004-12-24 21:35:50.0 + +++ linux-2.6.11-rc2-ott/fs/xfs/linux-2.6/xfs_linux.h2005-01-27 18:13:09.0 + @@ -144,7 +144,7 @@ #define xfs_inherit_nosymlinksxfs_params.inherit_nosym.val #define xfs_rotorstepxfs_params.rotorstep.val -#define current_cpu()smp_processor_id() +#define current_cpu()__smp_processor_id() #define current_pid()(current-pid) #define current_fsuid(cred)(current-fsuid) #define current_fsgid(cred)(current-fsgid) diff -Nru linux-2.6.11-rc2/fs/xfs/linux-2.6/xfs_stats.h linux-2.6.11-rc2-ott/fs/xfs/linux-2.6/xfs_stats.h --- linux-2.6.11-rc2/fs/xfs/linux-2.6/xfs_stats.h2004-12-24 21:34:29.0 + +++ linux-2.6.11-rc2-ott/fs/xfs/linux-2.6/xfs_stats.h2005-01-27 18:13:44.0 + @@ -142,9 +142,9 @@ /* We don't disable preempt, not too worried about poking the * wrong cpu's stat for now */ -#define XFS_STATS_INC(count)(__get_cpu_var(xfsstats).count++) -#define XFS_STATS_DEC(count)(__get_cpu_var(xfsstats).count--) -#define XFS_STATS_ADD(count, inc)(__get_cpu_var(xfsstats).count += (inc)) +#define XFS_STATS_INC(count)(per_cpu(xfsstats, __smp_processor_id()).count++) +#define XFS_STATS_DEC(count)(per_cpu(xfsstats, __smp_processor_id()).count--) +#define XFS_STATS_ADD(count, inc)(per_cpu(xfsstats, __smp_processor_id()).count += (inc)) extern void xfs_init_procfs(void); extern void xfs_cleanup_procfs(void); I'll submit it to the mailinglist as a seperate patch, so Linus can apply it to the current Kernel. Matthias-Christian Ott -- http://unixforge.org/~matthias-christian-ott/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Preempt Xfs Question
Chris Wedgwood wrote: On Thu, Jan 27, 2005 at 06:24:13PM +, Matthias-Christian Ott wrote: Well calling such a internal function (__function) is not a cleaning coding style but works best :-) . __foo does NOT mean it's an internal function necessarily or that it's unclean to use it (sadly Linux has pretty vague (nothing consistent) rules on how to interpret __foo versus foo really. Combined with the current_cpu() fixes I mentioned, it looks like this: (1) your patch is mangled/wrapped (2) this is fixed in CVS already (for maybe a week or so now?) I'll submit it to the mailinglist as a seperate patch, so Linus can apply it to the current Kernel. XFS patches/suggestions should go to linux-xfs@oss.sgi.com and the maintainers there can comment as needed. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Hi! I didn't know about the xfs development status. But it's good to hear that it's already fixed. When will it be included to the Kernel? Matthias-Christian Ott -- http://unixforge.org/~matthias-christian-ott/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Bug 4081] New: OpenOffice crashes while starting due to a threading error
Felipe Alfaro Solana wrote: On 22 Jan 2005, at 18:33, Matthias-Christian Ott wrote: Hi! I'm suing Arch Linux and the Kernel 2.6.11-rc2 -- it works great. Try to recompile your ^ suing? My God! More legal trouble. Didn't you mean "using"? ;-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Oh sorry that's just a typo. Matthias-Christian Ott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Bug 4081] New: OpenOffice crashes while starting due to a threading error
Felipe Alfaro Solana wrote: On 22 Jan 2005, at 18:33, Matthias-Christian Ott wrote: Hi! I'm suing Arch Linux and the Kernel 2.6.11-rc2 -- it works great. Try to recompile your ^ suing? My God! More legal trouble. Didn't you mean using? ;-) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Oh sorry that's just a typo. Matthias-Christian Ott - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Bug 4081] New: OpenOffice crashes while starting due to a threading error
Martin J. Bligh wrote: Please contact bug submitter for more info, not myself. - http://bugme.osdl.org/show_bug.cgi?id=4081 Summary: OpenOffice crashes while starting due to a threading error Kernel Version: 2.6.11-rc2 Status: NEW Severity: blocking Owner: [EMAIL PROTECTED] Submitter: [EMAIL PROTECTED] Distribution: Debian Hardware Environment: Pentum III 733 MHz Software Environment: Debian Sid Problem Description: While starting open Office crashes, it did not happend on 2.6.10, but happend on 2.6.11. rc1 and rc2. The only thing that has changed is the kernel. If i go back to 2.6.10 OpenOffice starts just fine. gdb shows that it crashes during this call: thread_get_info_callback: cannot get thread info: generic error the logs kern.log and messages don't show anything related to this crash. Steps to reproduce: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Hi! I'm suing Arch Linux and the Kernel 2.6.11-rc2 -- it works great. Try to recompile your OO.org. Matthias-Christian Ott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: nvidia driver and Kernel 2.6.11-rc2: compilation error
Jesper Juhl wrote: On Sat, 22 Jan 2005, Matthias-Christian Ott wrote: Hi! If I try to compile the nvidia driver (version: 6629) module I get this: [...] Howto fix this? Complain to NVidia. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Hi! It's solved: http://www.nvnews.net/vbulletin/showthread.php?s=9f3ae8d01f1339d56abdfb6b3b227a16=44469 Matthias-Christian Ott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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]: speedstep-lib: fix frequency multiplier for Pentium4 models 0&1
Arjan van de Ven wrote: On Sat, Jan 22, 2005 at 02:48:52PM +0100, Matthias-Christian Ott wrote: The Pentium4 models 0&1 have a longer MSR_EBC_FREQUENCY_ID register as the models 2&3, so the bit shift must be bigger. I would feel safer if this checked that it was actually a p4 as well... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Hi! If mean my CPU, it's a pentium4 model 1 and the patch is checked with it. All other tests which check if it's a pentium4 are performed by other instances of the cpufreq driver. Matthias-Christian Ott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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]: speedstep-lib: fix frequency multiplier for Pentium4 models 0&1
The Pentium4 models 0&1 have a longer MSR_EBC_FREQUENCY_ID register as
the models 2&3, so the bit shift must be bigger.
Signed-off-by: Matthias-Christian Ott <[EMAIL PROTECTED]>
--- linux-bk/arch/i386/kernel/cpu/cpufreq/speedstep-lib.c.orig
2005-01-21 13:55:37.0 +0100
+++ linux-bk/arch/i386/kernel/cpu/cpufreq/speedstep-lib.c2005-01-22
10:58:34.0 +0100
@@ -160,7 +160,14 @@
printk(KERN_DEBUG "speedstep-lib: couldn't detect FSB speed.
Please send an e-mail to <[EMAIL PROTECTED]>\n");
/* Multiplier. */
-mult = msr_lo >> 24;
+if (c->x86_model < 2)
+{
+mult = msr_lo >> 27;
+}
+else
+{
+mult = msr_lo >> 24;
+}
dprintk("P4 - FSB %u kHz; Multiplier %u; Speed %u kHz\n", fsb,
mult, (fsb * mult));
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
nvidia driver and Kernel 2.6.11-rc2: compilation error
ed at include/linux/module.h:57 8) /tmp/selfgz7663/NVIDIA-Linux-x86-1.0-6629-pkg1/usr/src/nv/os-agp.c: In funct ion `KernTeardownAGP': /tmp/selfgz7663/NVIDIA-Linux-x86-1.0-6629-pkg1/usr/src/nv/os-agp.c:216: erro r: request for member `release' in something not a structure or union /tmp/selfgz7663/NVIDIA-Linux-x86-1.0-6629-pkg1/usr/src/nv/os-agp.c:218: warn ing: `inter_module_put' is deprecated (declared at include/linux/module.h:57 8) /tmp/selfgz7663/NVIDIA-Linux-x86-1.0-6629-pkg1/usr/src/nv/os-agp.c: In funct ion `KernAllocAGPPages': /tmp/selfgz7663/NVIDIA-Linux-x86-1.0-6629-pkg1/usr/src/nv/os-agp.c:265: erro r: request for member `allocate_memory' in something not a structure or unio n /tmp/selfgz7663/NVIDIA-Linux-x86-1.0-6629-pkg1/usr/src/nv/os-agp.c:273: erro r: request for member `bind_memory' in something not a structure or union /tmp/selfgz7663/NVIDIA-Linux-x86-1.0-6629-pkg1/usr/src/nv/os-agp.c:290: erro r: request for member `unbind_memory' in something not a structure or union /tmp/selfgz7663/NVIDIA-Linux-x86-1.0-6629-pkg1/usr/src/nv/os-agp.c:305: erro r: request for member `free_memory' in something not a structure or union /tmp/selfgz7663/NVIDIA-Linux-x86-1.0-6629-pkg1/usr/src/nv/os-agp.c: In funct ion `KernMapAGPPages': /tmp/selfgz7663/NVIDIA-Linux-x86-1.0-6629-pkg1/usr/src/nv/os-agp.c:345: erro r: request for member `unbind_memory' in something not a structure or union /tmp/selfgz7663/NVIDIA-Linux-x86-1.0-6629-pkg1/usr/src/nv/os-agp.c: In funct ion `KernFreeAGPPages': /tmp/selfgz7663/NVIDIA-Linux-x86-1.0-6629-pkg1/usr/src/nv/os-agp.c:444: erro r: request for member `unbind_memory' in something not a structure or union /tmp/selfgz7663/NVIDIA-Linux-x86-1.0-6629-pkg1/usr/src/nv/os-agp.c:445: erro r: request for member `free_memory' in something not a structure or union make[3]: *** [/tmp/selfgz7663/NVIDIA-Linux-x86-1.0-6629-pkg1/usr/src/nv/os-a gp.o] Error 1 make[2]: *** [_module_/tmp/selfgz7663/NVIDIA-Linux-x86-1.0-6629-pkg1/usr/src /nv] Error 2 NVIDIA: left KBUILD. nvidia.ko failed to build! make[1]: *** [module] Error 1 make: *** [module] Error 2 -> Error. Howto fix this? Matthias-Christian Ott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
nvidia driver and Kernel 2.6.11-rc2: compilation error
/module.h:57 8) /tmp/selfgz7663/NVIDIA-Linux-x86-1.0-6629-pkg1/usr/src/nv/os-agp.c: In funct ion `KernTeardownAGP': /tmp/selfgz7663/NVIDIA-Linux-x86-1.0-6629-pkg1/usr/src/nv/os-agp.c:216: erro r: request for member `release' in something not a structure or union /tmp/selfgz7663/NVIDIA-Linux-x86-1.0-6629-pkg1/usr/src/nv/os-agp.c:218: warn ing: `inter_module_put' is deprecated (declared at include/linux/module.h:57 8) /tmp/selfgz7663/NVIDIA-Linux-x86-1.0-6629-pkg1/usr/src/nv/os-agp.c: In funct ion `KernAllocAGPPages': /tmp/selfgz7663/NVIDIA-Linux-x86-1.0-6629-pkg1/usr/src/nv/os-agp.c:265: erro r: request for member `allocate_memory' in something not a structure or unio n /tmp/selfgz7663/NVIDIA-Linux-x86-1.0-6629-pkg1/usr/src/nv/os-agp.c:273: erro r: request for member `bind_memory' in something not a structure or union /tmp/selfgz7663/NVIDIA-Linux-x86-1.0-6629-pkg1/usr/src/nv/os-agp.c:290: erro r: request for member `unbind_memory' in something not a structure or union /tmp/selfgz7663/NVIDIA-Linux-x86-1.0-6629-pkg1/usr/src/nv/os-agp.c:305: erro r: request for member `free_memory' in something not a structure or union /tmp/selfgz7663/NVIDIA-Linux-x86-1.0-6629-pkg1/usr/src/nv/os-agp.c: In funct ion `KernMapAGPPages': /tmp/selfgz7663/NVIDIA-Linux-x86-1.0-6629-pkg1/usr/src/nv/os-agp.c:345: erro r: request for member `unbind_memory' in something not a structure or union /tmp/selfgz7663/NVIDIA-Linux-x86-1.0-6629-pkg1/usr/src/nv/os-agp.c: In funct ion `KernFreeAGPPages': /tmp/selfgz7663/NVIDIA-Linux-x86-1.0-6629-pkg1/usr/src/nv/os-agp.c:444: erro r: request for member `unbind_memory' in something not a structure or union /tmp/selfgz7663/NVIDIA-Linux-x86-1.0-6629-pkg1/usr/src/nv/os-agp.c:445: erro r: request for member `free_memory' in something not a structure or union make[3]: *** [/tmp/selfgz7663/NVIDIA-Linux-x86-1.0-6629-pkg1/usr/src/nv/os-a gp.o] Error 1 make[2]: *** [_module_/tmp/selfgz7663/NVIDIA-Linux-x86-1.0-6629-pkg1/usr/src /nv] Error 2 NVIDIA: left KBUILD. nvidia.ko failed to build! make[1]: *** [module] Error 1 make: *** [module] Error 2 - Error. Howto fix this? Matthias-Christian Ott - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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]: speedstep-lib: fix frequency multiplier for Pentium4 models 01
The Pentium4 models 01 have a longer MSR_EBC_FREQUENCY_ID register as
the models 23, so the bit shift must be bigger.
Signed-off-by: Matthias-Christian Ott [EMAIL PROTECTED]
--- linux-bk/arch/i386/kernel/cpu/cpufreq/speedstep-lib.c.orig
2005-01-21 13:55:37.0 +0100
+++ linux-bk/arch/i386/kernel/cpu/cpufreq/speedstep-lib.c2005-01-22
10:58:34.0 +0100
@@ -160,7 +160,14 @@
printk(KERN_DEBUG speedstep-lib: couldn't detect FSB speed.
Please send an e-mail to [EMAIL PROTECTED]\n);
/* Multiplier. */
-mult = msr_lo 24;
+if (c-x86_model 2)
+{
+mult = msr_lo 27;
+}
+else
+{
+mult = msr_lo 24;
+}
dprintk(P4 - FSB %u kHz; Multiplier %u; Speed %u kHz\n, fsb,
mult, (fsb * mult));
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
