Re: [PATCH 2.6.13rc3] IPv6: Check interface bindings on IPv6 raw socket reception
Patrick McHardy wrote:
Andrew McDonald wrote:
Take account of whether a socket is bound to a particular device when
selecting an IPv6 raw socket to receive a packet. Also perform this
check when receiving IPv6 packets with router alert options.
I guess this one makes sense on top.
[IPV4/6]: Check if packet was actually delivered to a raw socket to decide
whether to send an ICMP unreachable
The Last patch didn't handle ICMP socket filters correctly, here is a
better one.
If a raw socket is bound to a single device the packet might not be
delivered even though there is a socket in the protocol hash. Send
back an ICMP protocol unreachable in this case.
[IPV4/6]: Check if packet was actually delivered to a raw socket to decide whether to send an ICMP unreachable
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit eb82d02518ac3a400663163995097749d91c7c4c
tree 1719713411b5e656ab5926ee633c39c0edfb1108
parent 36245c9aaddbed7e50d9600c8d1889ebee48a90f
author Patrick McHardy <[EMAIL PROTECTED]> Sun, 24 Jul 2005 06:54:32 +0200
committer Patrick McHardy <[EMAIL PROTECTED]> Sun, 24 Jul 2005 06:54:32 +0200
include/net/raw.h|2 +-
include/net/rawv6.h |2 +-
net/ipv4/ip_input.c |4 ++--
net/ipv4/raw.c |5 -
net/ipv6/ip6_input.c |4 ++--
net/ipv6/raw.c |5 -
6 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/include/net/raw.h b/include/net/raw.h
--- a/include/net/raw.h
+++ b/include/net/raw.h
@@ -37,6 +37,6 @@ extern struct sock *__raw_v4_lookup(stru
unsigned long raddr, unsigned long laddr,
int dif);
-extern void raw_v4_input(struct sk_buff *skb, struct iphdr *iph, int hash);
+extern int raw_v4_input(struct sk_buff *skb, struct iphdr *iph, int hash);
#endif /* _RAW_H */
diff --git a/include/net/rawv6.h b/include/net/rawv6.h
--- a/include/net/rawv6.h
+++ b/include/net/rawv6.h
@@ -7,7 +7,7 @@
extern struct hlist_head raw_v6_htable[RAWV6_HTABLE_SIZE];
extern rwlock_t raw_v6_lock;
-extern void ipv6_raw_deliver(struct sk_buff *skb, int nexthdr);
+extern int ipv6_raw_deliver(struct sk_buff *skb, int nexthdr);
extern struct sock *__raw_v6_lookup(struct sock *sk, unsigned short num,
struct in6_addr *loc_addr, struct in6_addr *rmt_addr,
diff --git a/net/ipv4/ip_input.c b/net/ipv4/ip_input.c
--- a/net/ipv4/ip_input.c
+++ b/net/ipv4/ip_input.c
@@ -225,8 +225,8 @@ static inline int ip_local_deliver_finis
/* If there maybe a raw socket we must check - if not we
* don't care less
*/
- if (raw_sk)
- raw_v4_input(skb, skb->nh.iph, hash);
+ if (raw_sk && !raw_v4_input(skb, skb->nh.iph, hash))
+ raw_sk = NULL;
if ((ipprot = rcu_dereference(inet_protos[hash])) != NULL) {
int ret;
diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c
--- a/net/ipv4/raw.c
+++ b/net/ipv4/raw.c
@@ -150,10 +150,11 @@ static __inline__ int icmp_filter(struct
* RFC 1122: SHOULD pass TOS value up to the transport layer.
* -> It does. And not only TOS, but all IP header.
*/
-void raw_v4_input(struct sk_buff *skb, struct iphdr *iph, int hash)
+int raw_v4_input(struct sk_buff *skb, struct iphdr *iph, int hash)
{
struct sock *sk;
struct hlist_head *head;
+ int delivered = 0;
read_lock(_v4_lock);
head = _v4_htable[hash];
@@ -164,6 +165,7 @@ void raw_v4_input(struct sk_buff *skb, s
skb->dev->ifindex);
while (sk) {
+ delivered = 1;
if (iph->protocol != IPPROTO_ICMP || !icmp_filter(sk, skb)) {
struct sk_buff *clone = skb_clone(skb, GFP_ATOMIC);
@@ -177,6 +179,7 @@ void raw_v4_input(struct sk_buff *skb, s
}
out:
read_unlock(_v4_lock);
+ return delivered;
}
void raw_err (struct sock *sk, struct sk_buff *skb, u32 info)
diff --git a/net/ipv6/ip6_input.c b/net/ipv6/ip6_input.c
--- a/net/ipv6/ip6_input.c
+++ b/net/ipv6/ip6_input.c
@@ -166,8 +166,8 @@ resubmit:
nexthdr = skb->nh.raw[nhoff];
raw_sk = sk_head(_v6_htable[nexthdr & (MAX_INET_PROTOS - 1)]);
- if (raw_sk)
- ipv6_raw_deliver(skb, nexthdr);
+ if (raw_sk && !ipv6_raw_deliver(skb, nexthdr))
+ raw_sk = NULL;
hash = nexthdr & (MAX_INET_PROTOS - 1);
if ((ipprot = rcu_dereference(inet6_protos[hash])) != NULL) {
diff --git a/net/ipv6/raw.c b/net/ipv6/raw.c
--- a/net/ipv6/raw.c
+++ b/net/ipv6/raw.c
@@ -141,11 +141,12 @@ static __inline__ int icmpv6_filter(stru
*
* Caller owns SKB so we must make clones.
*/
-void ipv6_raw_deliver(struct sk_buff *skb, int nexthdr)
+int ipv6_raw_deliver(struct sk_buff *skb, int nexthdr)
{
struct in6_addr *saddr;
struct in6_addr *daddr;
struct sock *sk;
+ int delivered = 0;
__u8 hash;
saddr = >nh.ipv6h->saddr;
@@ -167,6 +168,7 @@ void ipv6_raw_deliver(struct sk_buff *sk
sk = __raw_v6_lookup(sk, nexthdr, daddr, saddr, skb->dev->ifindex);
while (sk) {
+ delivered = 1;
if (nexthdr != IPPROTO_ICMPV6 || !icmpv6_filter(sk, skb)) {
struct sk_buff *clone = skb_clone(skb, GFP_ATOMIC);
@@ -179,6 +181,7 @@ void ipv6_raw_deliver(struct sk_buff *sk
}
out:
RE: [patch 1/] timers: tsc using for cpu scheduling
I should underline that patch deal with the alternative which timer to
use for task priority calculation when both TSC and PMT function.
You writes
> it will need some additional documentation and its likely you don't
want
> to use the cycles_2_ns() functions.
It is not need any additional documentation because using CPU
time as a measure of CPU work for scheduling is described in the Linux
kernel books. But when PMT was added in computers it was nominated for
scheduling time measurement because TSC may miss 2-3 clocks during CPU
frequency variation. But in that frequency variation period instruction
ticks are missed as well as TSC ticks. So TSC using is more correct in
this case. My patch returns only to original way scheduling time
calculation.
About NUMA Chen Kenneth gives argument:
> It is safe to use cpu local rdtsc since the scheduler will never
consume > > two timestamps taken from two different cpus.
I have added a comment in the patched source code according to your
recommends:
+ * It is not recommended to use this function for other than scheduler
purposes
+ * when time marks may be get on different cpus or cpu frequency is
varied.
You write
> As it was written it would have broken NUMAQ and other systems that do
> not have usable TSCs (ie: i386/i486).
According to documentation TSC presents in IA32 any computer. But:
* NOTE: this doesn't yet handle SMP 486 machines where
only
* some CPU's have a TSC. Thats never worked and nobody has
* moaned if you have the only one in the world - you fix
it!
- says arch/i386/kernel/timers/timer_tsc.c
You are right. It is good to save check and I restored it:
+ if (!cyc2ns_scale)
+ return jiffies_64 * (10 / HZ);
The patch:
diff -ur a/arch/i386/kernel/timers/common.c
b/arch/i386/kernel/timers/common.c
--- a/arch/i386/kernel/timers/common.c 2005-06-17 23:48:29.0
+0400
+++ b/arch/i386/kernel/timers/common.c 2005-07-17 23:02:16.0
+0400
@@ -138,6 +138,48 @@
return 0;
}
#endif
+/* convert from cycles(64bits) => nanoseconds (64bits)
+ * basic equation:
+ * ns = cycles / (freq / ns_per_sec)
+ * ns = cycles * (ns_per_sec / freq)
+ * ns = cycles * (10^9 / (cpu_mhz * 10^6))
+ * ns = cycles * (10^3 / cpu_mhz)
+ *
+ * Then we use scaling math (suggested by george@mvista.com) to
get:
+ * ns = cycles * (10^3 * SC / cpu_mhz) / SC
+ * ns = cycles * cyc2ns_scale / SC
+ *
+ * And since SC is a constant power of two, we can convert the div
+ * into a shift.
+ * [EMAIL PROTECTED] "math is hard, lets go
shopping!"
+ */
+unsigned long cyc2ns_scale;
+#define CYC2NS_SCALE_FACTOR 10 /* 2^10, carefully chosen */
+
+inline void set_cyc2ns_scale(unsigned long cpu_mhz)
+{
+ cyc2ns_scale = (1000 << CYC2NS_SCALE_FACTOR)/cpu_mhz;
+}
+inline unsigned long long cycles_2_ns(unsigned long long cyc)
+{
+ return (cyc * cyc2ns_scale) >> CYC2NS_SCALE_FACTOR;
+}
+/*
+ * Scheduler clock - returns current time in nanosec units.
+ * It is not recommended to use this function for other than scheduler
purposes
+ * when time marks may be get on different cpus or cpu frequency is
varied.
+ */
+unsigned long long sched_clock(void)
+{
+ unsigned long long this_offset;
+
+ if (!cyc2ns_scale)
+ /* no locking but a rare wrong value is not a big deal
*/
+ return jiffies_64 * (10 / HZ);
+
+ rdtscll(this_offset);
+ return cycles_2_ns(this_offset);
+}
/* calculate cpu_khz */
void init_cpu_khz(void)
@@ -156,6 +198,7 @@
"0" (eax), "1" (edx));
printk("Detected %lu.%03lu MHz
processor.\n", cpu_khz / 1000, cpu_khz % 1000);
}
+ set_cyc2ns_scale(cpu_khz/1000);
}
}
}
diff -ur a/arch/i386/kernel/timers/timer_hpet.c
b/arch/i386/kernel/timers/timer_hpet.c
--- a/arch/i386/kernel/timers/timer_hpet.c 2005-06-17
23:48:29.0 +0400
+++ b/arch/i386/kernel/timers/timer_hpet.c 2005-07-17
22:28:00.0 +0400
@@ -26,34 +26,6 @@
static unsigned long long monotonic_base;
static seqlock_t monotonic_lock = SEQLOCK_UNLOCKED;
-/* convert from cycles(64bits) => nanoseconds (64bits)
- * basic equation:
- * ns = cycles / (freq / ns_per_sec)
- * ns = cycles * (ns_per_sec / freq)
- * ns = cycles * (10^9 / (cpu_mhz * 10^6))
- * ns = cycles * (10^3 / cpu_mhz)
- *
- * Then we use scaling math (suggested by george@mvista.com) to
get:
- * ns = cycles * (10^3 * SC / cpu_mhz) / SC
- * ns = cycles * cyc2ns_scale / SC
- *
- * And since SC is a constant power of two, we can convert the div
- * into a shift.
- * [EMAIL PROTECTED] "math is hard, lets go
shopping!"
- */
-static unsigned long
Re: [cpufreq] ondemand works, conservative doesn't
>> currently, i'm using the ondemand governor. My CPU supports the >> frequencies 800, 1800 and 2000 MHz (AMD Athlon64 Desktop with >> Cool). The simple bash commands >> > > In my case, I have a Pentium M 1.8ghz 400 FSB. In powersave, it goes to > 1.19ghz, in conservative, it goes to 1.20GHZ and of course performance > goes to 1.8ghz if plugged. > > Conservative works well here, and so far, lt moved slowly from > frequencies, 1.2 then in 5 seconds 1.4, 2 seconds 1.8. Then it took the > CPU like 10 seconds to move back from 1.8ghz to 1.2.. Yes. Pentium M CPUs offer frequencies is 200MHz steps. And I was pretty sure, that the conservative govenor works in that case. > Mine did reach the full cpu in a moment, yours looks like it not going > over 2.0ghz. Maybe is not needing that much CPU? Running an "while true; do true; done" will result in process named "bash" that uses 100% of the cpu. The problem i see is, that the conservative govenor never considers to switch from 800MHz to 1800MHz because it's a 1000MHz jump! (i'd consider that as a bug, since the govenor is non-functional in such an environment) > If it only supports 800, 1800 and 2000 MHz, then it will only jump to > those frequencies. I use the CPU Frequency Scaling Monitor included in > gnome to switch between these options a lot. Maybe you could play with > this a bit more and see how it behaves. It does look like it might need > more frequencies, but you would need to check what does you CPU support. I would be very glad, if the conservative-govenor would switch to the three frequencies i listet. The problem is: it doesn't. AFAIK, AMD Desktop CPUs really support 3 frequencies only :-( - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [cpufreq] ondemand works, conservative doesn't
Sven Köhler wrote: Hi, currently, i'm using the ondemand governor. My CPU supports the frequencies 800, 1800 and 2000 MHz (AMD Athlon64 Desktop with Cool). The simple bash commands In my case, I have a Pentium M 1.8ghz 400 FSB. In powersave, it goes to 1.19ghz, in conservative, it goes to 1.20GHZ and of course performance goes to 1.8ghz if plugged. Conservative works well here, and so far, lt moved slowly from frequencies, 1.2 then in 5 seconds 1.4, 2 seconds 1.8. Then it took the CPU like 10 seconds to move back from 1.8ghz to 1.2.. Mine did reach the full cpu in a moment, yours looks like it not going over 2.0ghz. Maybe is not needing that much CPU? If it only supports 800, 1800 and 2000 MHz, then it will only jump to those frequencies. I use the CPU Frequency Scaling Monitor included in gnome to switch between these options a lot. Maybe you could play with this a bit more and see how it behaves. It does look like it might need more frequencies, but you would need to check what does you CPU support. .Alejandro - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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: NFS mount hangs when attempting to copy file
On 7/23/05, Trond Myklebust <[EMAIL PROTECTED]> wrote: > I beg to disagree. A lot of these VPN solutions are unfriendly to MTU > path discovery over UDP. Sun uses TCP by default when mounting NFS > partitions. Have you tried this on your Linux box? I changed the protocol to TCP and changed rsize and wsize to 1024. I don't know which of those fixed it, but I'm going to leave it for now. As for MTU, yeah, the Watchguard box seems to have some hard-coded limits, and for whatever reason KDE and GNOME graphical logins do something that exceeds those limits, completely independent of NFS, and hang up hard. Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] autofs4 - fix infamous "Busy inodes after umount ..." message.
If the automount daemon receives a signal which causes it to sumarily
terminate the autofs4 module leaks dentries. The same problem exists with
detached mount requests without the warning.
This patch cleans these dentries at umount.
Signed-off-by: Ian Kent <[EMAIL PROTECTED]>
diff -Nurp linux-2.6.11.orig/fs/autofs4/autofs_i.h
linux-2.6.11/fs/autofs4/autofs_i.h
--- linux-2.6.11.orig/fs/autofs4/autofs_i.h 2005-07-02 19:23:37.0
+0800
+++ linux-2.6.11/fs/autofs4/autofs_i.h 2005-07-02 19:15:11.0 +0800
@@ -92,6 +92,7 @@
struct autofs_sb_info {
u32 magic;
+ struct dentry *root;
struct file *pipe;
pid_t oz_pgrp;
int catatonic;
--- linux-2.6.11.orig/fs/autofs4/inode.c2005-07-02 19:19:37.0
+0800
+++ linux-2.6.11/fs/autofs4/inode.c 2005-07-09 13:16:13.0 +0800
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include "autofs_i.h"
#include
@@ -76,6 +77,66 @@
kfree(ino);
}
+/*
+ * Deal with the infamous "Busy inodes after umount ..." message.
+ *
+ * Clean up the dentry tree. This happens with autofs if the user
+ * space program goes away due to a SIGKILL, SIGSEGV etc.
+ */
+static void autofs4_force_release(struct autofs_sb_info *sbi)
+{
+ struct dentry *this_parent = sbi->root;
+ struct list_head *next;
+
+ spin_lock(_lock);
+repeat:
+ next = this_parent->d_subdirs.next;
+resume:
+ while (next != _parent->d_subdirs) {
+ struct dentry *dentry = list_entry(next, struct dentry,
d_child);
+
+ /* Negative dentry - don`t care */
+ if (!simple_positive(dentry)) {
+ next = next->next;
+ continue;
+ }
+
+ if (!list_empty(>d_subdirs)) {
+ this_parent = dentry;
+ goto repeat;
+ }
+
+ next = next->next;
+ spin_unlock(_lock);
+
+ DPRINTK("dentry %p %.*s",
+ dentry, (int)dentry->d_name.len, dentry->d_name.name);
+
+ dput(dentry);
+ spin_lock(_lock);
+ }
+
+ if (this_parent != sbi->root) {
+ struct dentry *dentry = this_parent;
+
+ next = this_parent->d_child.next;
+ this_parent = this_parent->d_parent;
+ spin_unlock(_lock);
+ DPRINTK("parent dentry %p %.*s",
+ dentry, (int)dentry->d_name.len, dentry->d_name.name);
+ dput(dentry);
+ spin_lock(_lock);
+ goto resume;
+ }
+ spin_unlock(_lock);
+
+ dput(sbi->root);
+ sbi->root = NULL;
+ shrink_dcache_sb(sbi->sb);
+
+ return;
+}
+
static void autofs4_put_super(struct super_block *sb)
{
struct autofs_sb_info *sbi = autofs4_sbi(sb);
@@ -85,6 +146,10 @@
if ( !sbi->catatonic )
autofs4_catatonic_mode(sbi); /* Free wait queues, close pipe */
+ /* Clean up and release dangling references */
+ if (sbi)
+ autofs4_force_release(sbi);
+
kfree(sbi);
DPRINTK("shutting down");
@@ -199,6 +264,7 @@
s->s_fs_info = sbi;
sbi->magic = AUTOFS_SBI_MAGIC;
+ sbi->root = NULL;
sbi->catatonic = 0;
sbi->exp_timeout = 0;
sbi->oz_pgrp = process_group(current);
@@ -267,6 +333,13 @@
sbi->pipe = pipe;
/*
+* Take a reference to the root dentry so we get a chance to
+* clean up the dentry tree on umount.
+* See autofs4_force_release.
+*/
+ sbi->root = dget(root);
+
+ /*
* Success! Install the root dentry now to indicate completion.
*/
s->s_root = root;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Supermount
On Sat, 23 Jul 2005, Oliver Neukum wrote: > Am Freitag, 22. Juli 2005 18:38 schrieb Lasse Kärkkäinen / Tronic: > > > Supermount is obsolete there are other tools in userspace that do the > > > job perfectly. > > > e.g ivman which uses hal and dbus. > > > > They cannot mount on demand, thus cannot do the same job. The boot > > partition, for example, is something that should only be mounted when > > required. The same obviously also goes for network filesystems in many > > cases (i.e. avoid having zillion idling connections to the server). > > To mount on demand use autofs. Unmounting and dealing with media removal > is the problem. That's not the only problem. We can't do owner mounts of the floppy, for example. smb mounts have similar problems in needing to identify the requester in order to get authentication info. But that's on the agenda to be fixed. Ian
Re: Supermount
On Sat, 23 Jul 2005, Lasse K??rkk??inen / Tronic wrote: > > To mount on demand use autofs. Unmounting and dealing with media removal > > is the problem. > > Granted, that can get pretty close. However, having to use /auto/* > instead of mounting directly where required often limits using it quite > a bit. Thus, I don't see it as a real alternative. What do you mean "/auto/*"? Ian
diskstat 0.1: simple tool to study io patterns via relayfs
It is with distinct lack of pride that I release version 0.1 of diskstat 'Geeks in Black Thorn', a tool that allows you to generate the kinds of graphs as presented in my OLS talk 'On faster application startup times: Cache stuffing, seek profiling, adaptive preloading'. The lack of pride is because this release is more a promise of what is to come than how things should be. The presentation, paper, and software can be found on http://ds9a.nl/diskstat and http://ds9a.nl/diskstat/diskstat-0.1.tar.gz >From the README: The quality of this code is abysmal, for which I squarely blame the fun people at OLS who've been keeping me from my code! (...) The next version will be based on k/jprobes, and will make better use of relayfs features. This also means you won't have to patch your kernel anymore, as long as you compiled with kprobes support. Sample command lines: # mkdir /relay # mount -t relayfs none /relay # ./dumpdiskstat /relay/diskstat0 > dump This will output something like: I think we skipped at 90867, ret=0 I think we hit end at 143016, ret=-1 I think we hit the break again 90867, ret=0 Process the stats. $ ./dswalk < dump It will print out huge latencies encountered: > Large latency 163.352 on line 14146 Total read started: 33888768, total ended: 33888768 Total write started: 1372160, total ended: 1372160 Waiting time: 10.695 seconds Make pretty plots gnuplot plot 'startplaces.dat', 'headplaces.dat' plot 'inflight.dat' Continue reading on http://ds9a.nl/diskstat/README -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Lack of Documentation about SA_RESTART...
On Mon, 11 Jul 2005, Theodore Ts'o wrote: > > According to the Single Unix Specification V3, all functions that > return EINTR are supposed to restart if a process receives a signal > where signal handler has been installed with the SA_RESTART flag. That can't be right. Some operations, like "select()" and "pause()" always return EINTR, and indeed, real applications will break if you always restart. Restarting a pause() would be nonsensical. This is why the kernel has ERESTARTSYS (restart always) and ERESTARTNOHAND (restart if the signal had no handler) which will be turned into EINTR if SA_RESTART isn't set. And even then, there are some ops that just always use EINTR and don't even try to restart. > There may be a few places in the kernel where this isn't happenning, > that's what the specification states. The specs are broken, and apparently don't take real life (or sanity - pause() in particular just doesn't make sense if restarted) into account. Afaik, the historical BSD behaviour (which is what SA_RESTART is all about) always was to just restart some system calls, not all of them. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.13rc3] IPv6: Check interface bindings on IPv6 raw socket reception
Andrew McDonald wrote:
Take account of whether a socket is bound to a particular device when
selecting an IPv6 raw socket to receive a packet. Also perform this
check when receiving IPv6 packets with router alert options.
I guess this one makes sense on top.
[IPV4/6]: Check if packet was actually delivered to a raw socket to decide
whether to send an ICMP unreachable
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit 0fc074eed6ad201d76392dcabbc156784570ea64
tree 913c87ad866f4abb23e9788c0170b81b564cfe7a
parent 36245c9aaddbed7e50d9600c8d1889ebee48a90f
author Patrick McHardy <[EMAIL PROTECTED]> Sun, 24 Jul 2005 02:23:25 +0200
committer Patrick McHardy <[EMAIL PROTECTED]> Sun, 24 Jul 2005 02:23:25 +0200
include/net/raw.h|2 +-
include/net/rawv6.h |2 +-
net/ipv4/ip_input.c |4 ++--
net/ipv4/raw.c |8 ++--
net/ipv6/ip6_input.c |4 ++--
net/ipv6/raw.c |8 ++--
6 files changed, 18 insertions(+), 10 deletions(-)
diff --git a/include/net/raw.h b/include/net/raw.h
--- a/include/net/raw.h
+++ b/include/net/raw.h
@@ -37,6 +37,6 @@ extern struct sock *__raw_v4_lookup(stru
unsigned long raddr, unsigned long laddr,
int dif);
-extern void raw_v4_input(struct sk_buff *skb, struct iphdr *iph, int hash);
+extern int raw_v4_input(struct sk_buff *skb, struct iphdr *iph, int hash);
#endif /* _RAW_H */
diff --git a/include/net/rawv6.h b/include/net/rawv6.h
--- a/include/net/rawv6.h
+++ b/include/net/rawv6.h
@@ -7,7 +7,7 @@
extern struct hlist_head raw_v6_htable[RAWV6_HTABLE_SIZE];
extern rwlock_t raw_v6_lock;
-extern void ipv6_raw_deliver(struct sk_buff *skb, int nexthdr);
+extern int ipv6_raw_deliver(struct sk_buff *skb, int nexthdr);
extern struct sock *__raw_v6_lookup(struct sock *sk, unsigned short num,
struct in6_addr *loc_addr, struct in6_addr
*rmt_addr,
diff --git a/net/ipv4/ip_input.c b/net/ipv4/ip_input.c
--- a/net/ipv4/ip_input.c
+++ b/net/ipv4/ip_input.c
@@ -225,8 +225,8 @@ static inline int ip_local_deliver_finis
/* If there maybe a raw socket we must check - if not we
* don't care less
*/
- if (raw_sk)
- raw_v4_input(skb, skb->nh.iph, hash);
+ if (raw_sk && !raw_v4_input(skb, skb->nh.iph, hash))
+ raw_sk = NULL;
if ((ipprot = rcu_dereference(inet_protos[hash])) != NULL) {
int ret;
diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c
--- a/net/ipv4/raw.c
+++ b/net/ipv4/raw.c
@@ -150,10 +150,11 @@ static __inline__ int icmp_filter(struct
* RFC 1122: SHOULD pass TOS value up to the transport layer.
* -> It does. And not only TOS, but all IP header.
*/
-void raw_v4_input(struct sk_buff *skb, struct iphdr *iph, int hash)
+int raw_v4_input(struct sk_buff *skb, struct iphdr *iph, int hash)
{
struct sock *sk;
struct hlist_head *head;
+ int delivered = 0;
read_lock(_v4_lock);
head = _v4_htable[hash];
@@ -168,8 +169,10 @@ void raw_v4_input(struct sk_buff *skb, s
struct sk_buff *clone = skb_clone(skb, GFP_ATOMIC);
/* Not releasing hash table! */
- if (clone)
+ if (clone) {
raw_rcv(sk, clone);
+ delivered = 1;
+ }
}
sk = __raw_v4_lookup(sk_next(sk), iph->protocol,
iph->saddr, iph->daddr,
@@ -177,6 +180,7 @@ void raw_v4_input(struct sk_buff *skb, s
}
out:
read_unlock(_v4_lock);
+ return delivered;
}
void raw_err (struct sock *sk, struct sk_buff *skb, u32 info)
diff --git a/net/ipv6/ip6_input.c b/net/ipv6/ip6_input.c
--- a/net/ipv6/ip6_input.c
+++ b/net/ipv6/ip6_input.c
@@ -166,8 +166,8 @@ resubmit:
nexthdr = skb->nh.raw[nhoff];
raw_sk = sk_head(_v6_htable[nexthdr & (MAX_INET_PROTOS - 1)]);
- if (raw_sk)
- ipv6_raw_deliver(skb, nexthdr);
+ if (raw_sk && !ipv6_raw_deliver(skb, nexthdr))
+ raw_sk = NULL;
hash = nexthdr & (MAX_INET_PROTOS - 1);
if ((ipprot = rcu_dereference(inet6_protos[hash])) != NULL) {
diff --git a/net/ipv6/raw.c b/net/ipv6/raw.c
--- a/net/ipv6/raw.c
+++ b/net/ipv6/raw.c
@@ -141,11 +141,12 @@ static __inline__ int icmpv6_filter(stru
*
* Caller owns SKB so we must make clones.
*/
-void ipv6_raw_deliver(struct sk_buff *skb, int nexthdr)
+int ipv6_raw_deliver(struct sk_buff *skb, int nexthdr)
{
struct in6_addr *saddr;
struct in6_addr *daddr;
struct sock *sk;
+ int delivered = 0;
__u8 hash;
saddr = >nh.ipv6h->saddr;
@@ -171,14 +172,17 @@ void ipv6_raw_deliver(struct sk_buff *sk
struct sk_buff *clone =
[-mm PATCH] v4l: hybrid dvb: move #defines to Makefile
This patch moves #define from cx88-dvb.c and saa7134-dvb.c into Makefile as CFLAGS, allowing code compatability with video4linux cvs. Signed-off-by: Michael Krufky <[EMAIL PROTECTED]> linux/drivers/media/video/cx88/Makefile | 12 linux/drivers/media/video/cx88/cx88-dvb.c |7 ++- linux/drivers/media/video/saa7134/Makefile |6 ++ linux/drivers/media/video/saa7134/saa7134-dvb.c |5 ++--- 4 files changed, 22 insertions(+), 8 deletions(-) diff -u linux-2.6.13/drivers/media/video/cx88/cx88-dvb.c linux/drivers/media/video/cx88/cx88-dvb.c --- linux-2.6.13/drivers/media/video/cx88/cx88-dvb.c2005-07-23 19:19:52.0 + +++ linux/drivers/media/video/cx88/cx88-dvb.c 2005-07-23 19:42:45.0 + @@ -1,5 +1,5 @@ /* - * $Id: cx88-dvb.c,v 1.49 2005/07/20 05:38:09 mkrufky Exp $ + * $Id: cx88-dvb.c,v 1.50 2005/07/23 10:08:00 mkrufky Exp $ * * device driver for Conexant 2388x based TV cards * MPEG Transport Stream (DVB) routines @@ -29,11 +29,8 @@ #include #include #include +#include -#define CONFIG_DVB_MT352 1 -#define CONFIG_DVB_CX22702 1 -#define CONFIG_DVB_OR51132 1 -#define CONFIG_DVB_LGDT3302 1 #include "cx88.h" #include "dvb-pll.h" diff -u linux-2.6.13/drivers/media/video/saa7134/saa7134-dvb.c linux/drivers/media/video/saa7134/saa7134-dvb.c --- linux-2.6.13/drivers/media/video/saa7134/saa7134-dvb.c 2005-07-23 19:19:52.0 + +++ linux/drivers/media/video/saa7134/saa7134-dvb.c 2005-07-23 19:42:45.0 + @@ -1,5 +1,5 @@ /* - * $Id: saa7134-dvb.c,v 1.18 2005/07/04 16:05:50 mkrufky Exp $ + * $Id: saa7134-dvb.c,v 1.22 2005/07/23 10:08:00 mkrufky Exp $ * * (c) 2004 Gerd Knorr <[EMAIL PROTECTED]> [SuSE Labs] * @@ -29,9 +29,8 @@ #include #include #include +#include -#define CONFIG_DVB_MT352 1 -#define CONFIG_DVB_TDA1004X 1 #include "saa7134-reg.h" #include "saa7134.h" diff -u linux-2.6.13/drivers/media/video/cx88/Makefile linux/drivers/media/video/cx88/Makefile --- linux-2.6.13/drivers/media/video/cx88/Makefile 2005-06-17 19:48:29.0 + +++ linux/drivers/media/video/cx88/Makefile 2005-07-23 19:42:45.0 + @@ -9,3 +9,15 @@ EXTRA_CFLAGS += -I$(src)/.. EXTRA_CFLAGS += -I$(srctree)/drivers/media/dvb/dvb-core EXTRA_CFLAGS += -I$(srctree)/drivers/media/dvb/frontends +ifneq ($(CONFIG_DVB_CX22702),n) + EXTRA_CFLAGS += -DCONFIG_DVB_CX22702=1 +endif +ifneq ($(CONFIG_DVB_OR51132),n) + EXTRA_CFLAGS += -DCONFIG_DVB_OR51132=1 +endif +ifneq ($(CONFIG_DVB_LGDT3302),n) + EXTRA_CFLAGS += -DCONFIG_DVB_LGDT3302=1 +endif +ifneq ($(CONFIG_DVB_MT352),n) + EXTRA_CFLAGS += -DCONFIG_DVB_MT352=1 +endif diff -u linux-2.6.13/drivers/media/video/saa7134/Makefile linux/drivers/media/video/saa7134/Makefile --- linux-2.6.13/drivers/media/video/saa7134/Makefile 2005-06-17 19:48:29.0 + +++ linux/drivers/media/video/saa7134/Makefile 2005-07-23 19:42:45.0 + @@ -9,3 +9,9 @@ EXTRA_CFLAGS += -I$(src)/.. EXTRA_CFLAGS += -I$(srctree)/drivers/media/dvb/dvb-core EXTRA_CFLAGS += -I$(srctree)/drivers/media/dvb/frontends +ifneq ($(CONFIG_DVB_MT352),n) + EXTRA_CFLAGS += -DCONFIG_DVB_MT352=1 +endif +ifneq ($(CONFIG_DVB_TDA1004X),n) + EXTRA_CFLAGS += -DCONFIG_DVB_TDA1004X=1 +endif
[-mm PATCH] v4l: hybrid dvb: fix warnings with -Wundef
This patch adds a missing #ifdef to saa7134-dvb.c
(thanks to Mauro Carvalho Chehab)
and changes #if to #ifdef in both files.
Signed-off-by: Michael Krufky <[EMAIL PROTECTED]>
linux/drivers/media/video/cx88/cx88-dvb.c | 24
linux/drivers/media/video/saa7134/saa7134-dvb.c | 15 +-
2 files changed, 20 insertions(+), 19 deletions(-)
diff -u linux-2.6.13/drivers/media/video/cx88/cx88-dvb.c
linux/drivers/media/video/cx88/cx88-dvb.c
--- linux-2.6.13/drivers/media/video/cx88/cx88-dvb.c2005-07-23
18:54:34.0 +
+++ linux/drivers/media/video/cx88/cx88-dvb.c 2005-07-23 19:06:49.0
+
@@ -38,17 +38,17 @@
#include "cx88.h"
#include "dvb-pll.h"
-#if CONFIG_DVB_MT352
+#ifdef CONFIG_DVB_MT352
# include "mt352.h"
# include "mt352_priv.h"
#endif
-#if CONFIG_DVB_CX22702
+#ifdef CONFIG_DVB_CX22702
# include "cx22702.h"
#endif
-#if CONFIG_DVB_OR51132
+#ifdef CONFIG_DVB_OR51132
# include "or51132.h"
#endif
-#if CONFIG_DVB_LGDT3302
+#ifdef CONFIG_DVB_LGDT3302
# include "lgdt3302.h"
#endif
@@ -107,7 +107,7 @@
/* -- */
-#if CONFIG_DVB_MT352
+#ifdef CONFIG_DVB_MT352
static int dvico_fusionhdtv_demod_init(struct dvb_frontend* fe)
{
static u8 clock_config [] = { CLOCK_CTL, 0x38, 0x39 };
@@ -177,7 +177,7 @@
};
#endif
-#if CONFIG_DVB_CX22702
+#ifdef CONFIG_DVB_CX22702
static struct cx22702_config connexant_refboard_config = {
.demod_address = 0x43,
.pll_address = 0x60,
@@ -191,7 +191,7 @@
};
#endif
-#if CONFIG_DVB_OR51132
+#ifdef CONFIG_DVB_OR51132
static int or51132_set_ts_param(struct dvb_frontend* fe,
int is_punctured)
{
@@ -208,7 +208,7 @@
};
#endif
-#if CONFIG_DVB_LGDT3302
+#ifdef CONFIG_DVB_LGDT3302
static int lgdt3302_pll_set(struct dvb_frontend* fe,
struct dvb_frontend_parameters* params,
u8* pllbuf)
@@ -259,7 +259,7 @@
/* init frontend */
switch (dev->core->board) {
-#if CONFIG_DVB_CX22702
+#ifdef CONFIG_DVB_CX22702
case CX88_BOARD_HAUPPAUGE_DVB_T1:
dev->dvb.frontend = cx22702_attach(_novat_config,
>core->i2c_adap);
@@ -270,7 +270,7 @@
>core->i2c_adap);
break;
#endif
-#if CONFIG_DVB_MT352
+#ifdef CONFIG_DVB_MT352
case CX88_BOARD_DVICO_FUSIONHDTV_DVB_T1:
dev->core->pll_addr = 0x61;
dev->core->pll_desc = _pll_lg_z201;
@@ -292,13 +292,13 @@
>core->i2c_adap);
break;
#endif
-#if CONFIG_DVB_OR51132
+#ifdef CONFIG_DVB_OR51132
case CX88_BOARD_PCHDTV_HD3000:
dev->dvb.frontend = or51132_attach(_hd3000,
>core->i2c_adap);
break;
#endif
-#if CONFIG_DVB_LGDT3302
+#ifdef CONFIG_DVB_LGDT3302
case CX88_BOARD_DVICO_FUSIONHDTV_3_GOLD_Q:
dev->ts_gen_cntrl = 0x08;
{
diff -u linux-2.6.13/drivers/media/video/saa7134/saa7134-dvb.c
linux/drivers/media/video/saa7134/saa7134-dvb.c
--- linux-2.6.13/drivers/media/video/saa7134/saa7134-dvb.c 2005-07-23
18:39:40.0 +
+++ linux/drivers/media/video/saa7134/saa7134-dvb.c 2005-07-23
19:06:49.0 +
@@ -36,11 +36,11 @@
#include "saa7134-reg.h"
#include "saa7134.h"
-#if CONFIG_DVB_MT352
+#ifdef CONFIG_DVB_MT352
# include "mt352.h"
# include "mt352_priv.h" /* FIXME */
#endif
-#if CONFIG_DVB_TDA1004X
+#ifdef CONFIG_DVB_TDA1004X
# include "tda1004x.h"
#endif
@@ -54,7 +54,7 @@
/* -- */
-#if CONFIG_DVB_MT352
+#ifdef CONFIG_DVB_MT352
static int pinnacle_antenna_pwr(struct saa7134_dev *dev, int on)
{
u32 ok;
@@ -153,7 +153,7 @@
/* -- */
-#if CONFIG_DVB_TDA1004X
+#ifdef CONFIG_DVB_TDA1004X
static int philips_tu1216_pll_init(struct dvb_frontend *fe)
{
struct saa7134_dev *dev = fe->dvb->priv;
@@ -385,7 +385,7 @@
return 0;
}
-
+#ifdef CONFIG_DVB_TDA1004X
static struct tda1004x_config medion_cardbus = {
.demod_address = 0x08,
.invert= 1,
@@ -398,6 +398,7 @@
.pll_sleep = philips_fmd1216_analog,
.request_firmware = NULL,
};
+#endif
/* -- */
@@ -547,14 +548,14 @@
dev);
switch (dev->board) {
-#if CONFIG_DVB_MT352
+#ifdef CONFIG_DVB_MT352
case SAA7134_BOARD_PINNACLE_300I_DVBT_PAL:
printk("%s: pinnacle 300i dvb setup\n",dev->name);
dev->dvb.frontend = mt352_attach(_300i,
>i2c_adap);
break;
Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt
On 7/24/05, randy_dunlap <[EMAIL PROTECTED]> wrote:
> On Fri, 15 Jul 2005 05:46:44 +0200 Jesper Juhl wrote:
>
> > +static int __init jiffies_increment_setup(char *str)
> > +{
> > + printk(KERN_NOTICE "setting up jiffies_increment : ");
> > + if (str) {
> > + printk("kernel_hz = %s, ", str);
> > + } else {
> > + printk("kernel_hz is unset, ");
> > + }
> > + if (!strncmp("100", str, 3)) {
>
> BTW, if someone enters "kernel_hz=1000", this check (above) for "100"
> matches (detects) 100, not 1000.
>
ouch. You are right - thanks. I'll be sure to fix that.
I haven't had time to look more at this little thing for the last few
days, but I'll get back to it soon. Thank you for the feedback.
--
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt
On Fri, 15 Jul 2005 05:46:44 +0200 Jesper Juhl wrote:
> +static int __init jiffies_increment_setup(char *str)
> +{
> + printk(KERN_NOTICE "setting up jiffies_increment : ");
> + if (str) {
> + printk("kernel_hz = %s, ", str);
> + } else {
> + printk("kernel_hz is unset, ");
> + }
> + if (!strncmp("100", str, 3)) {
BTW, if someone enters "kernel_hz=1000", this check (above) for "100"
matches (detects) 100, not 1000.
> + jiffies_increment = 10;
> + printk("jiffies_increment set to 10, effective HZ will be
> 100\n");
> + } else if (!strncmp("250", str, 3)) {
> + jiffies_increment = 4;
> + printk("jiffies_increment set to 4, effective HZ will be
> 250\n");
> + } else {
> + jiffies_increment = 1;
> + printk("jiffies_increment set to 1, effective HZ will be
> 1000\n");
> + }
> +
> + return 1;
> +}
---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: fix suspend/resume irq request free for yenta..
hi
the patch is wrong. yenta_request_irq() registers the wrong handler.
plus yenta_probe_cb_irq() has nothing to do with suspend/resume
(besides it frees the irq in the very same function). correct patch below.
somebody cares to explain me why the free_irq() is necessary before
a suspend?
rgds
-daniel
---
[PATCH] yenta: free_irq() on suspend.
Resume doesn't seem to work without.
Signed-off-by: Daniel Ritz <[EMAIL PROTECTED]>
diff --git a/drivers/pcmcia/yenta_socket.c b/drivers/pcmcia/yenta_socket.c
--- a/drivers/pcmcia/yenta_socket.c
+++ b/drivers/pcmcia/yenta_socket.c
@@ -1107,6 +1107,8 @@ static int yenta_dev_suspend (struct pci
pci_read_config_dword(dev, 17*4, >saved_state[1]);
pci_disable_device(dev);
+ free_irq(dev->irq, socket);
+
/*
* Some laptops (IBM T22) do not like us putting the Cardbus
* bridge into D3. At a guess, some other laptop will
@@ -1132,6 +1134,13 @@ static int yenta_dev_resume (struct pci_
pci_enable_device(dev);
pci_set_master(dev);
+ if (socket->cb_irq)
+ if (request_irq(socket->cb_irq, yenta_interrupt,
+ SA_SHIRQ, "yenta", socket)) {
+ printk(KERN_WARNING "Yenta: request_irq()
failed on resume!\n");
+ socket->cb_irq = 0;
+ }
+
if (socket->type && socket->type->restore_state)
socket->type->restore_state(socket);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] i386: Selectable Frequency of the Timer Interrupt
On Sat, 16 Jul 2005 23:55:17 -0400 Lee Revell wrote:
> On Sat, 2005-07-16 at 19:35 -0700, Nish Aravamudan wrote:
> > As you've seen, I think it depends on the timesource: for the PIT, it
> > would be arch/i386/kernel/timers/timer_pit.c::setup_pit_timer().
>
> That one looks pretty straightforward.
> arch/i386/kernel/timers/timer_tsc.c really looks like fun. So many
> corner cases...
>
> BTW shouldn't this code from mark_offset_tsc():
>
> 402 if (pit_latch_buggy) {
> 403 /* get center value of last 3 time lutch */
> 404 if ((count2 >= count && count >= count1)
> 405 || (count1 >= count && count >= count2)) {
> 406 count2 = count1; count1 = count;
> 407 } else if ((count1 >= count2 && count2 >= count)
> 408|| (count >= count2 && count2 >= count1)) {
> 409 countmp = count;count = count2;
> 410 count2 = count1;count1 = countmp;
> 411 } else {
> 412 count2 = count1; count1 = count; count = count1;
> 413 }
> 414 }
>
> use an ifdef? It only applies to cyrix_55x0, and mark_offset_tsc is a
> pretty hot path.
I see your point, but several distros build kernels that run on
almost any x86-32 machine, so I think that it's there as is
for universal-kernel support.
---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Memory Management
Neil, The best way I can think to do that is take a look at /proc/slabinfo. That will likely give you a pointer to which area of code is eating up your memory. OK. I will monitor the /proc/slabinfo file. Based on the sysrq-m info you posted it looks like due to fragmentation the largest chunk of memory you can allocate is 2MB (perhaps less depending on address space availability). If you can build a test kernel to do a show_state rather than a show_mem at the beginning of oom_kil, then you should be able to tell who is trying to do an allocation that leads to kswapd calling out_of_memory. Neil, I'm trying to recompile the kernel source 2.4.21-32.0.1 and get some error messages: In file included from /usr/src/linux-2.4.21-32.0.1.EL/include/linux/prefetch.h:13, from /usr/src/linux-2.4.21-32.0.1.EL/include/linux/list.h:6, from /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:12, from 3w-.c:172: /usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:61: warning: parameter names (without types) in function declaration /usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:61: field `loops_per_jiffy_R_ver_str' declared as a function /usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:84: invalid suffix on integer constant /usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:84: syntax error before numeric constant /usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:84: warning: function declaration isn't a prototype /usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:269: invalid suffix on integer constant /usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:269: syntax error before numeric constant /usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:269: warning: function declaration isn't a prototype /usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:273: warning: parameter names (without types) in function declaration In file included from 3w-.c:172: /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:190: invalid suffix on integer constant /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:190: syntax error before numeric constant /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:190: `inter_module_register_R_ver_str' declared as function returning a function /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:190: warning: function declaration isn't a prototype /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:191: invalid suffix on integer constant /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:191: syntax error before numeric constant /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:191: `inter_module_unregister_R_ver_str' declared as function returning a function /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:191: warning: function declaration isn't a prototype /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:192: `inter_module_get_R_ver_str' declared as function returning a function /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:192: warning: parameter names (without types) in function declaration /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:193: `inter_module_get_request_R_ver_str' declared as function returning a function /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:193: warning: parameter names (without types) in function declaration /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:194: invalid suffix on integer constant /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:194: syntax error before numeric constant /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:194: `inter_module_put_R_ver_str' declared as function returning a function /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:194: warning: function declaration isn't a prototype /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:203: `try_inc_mod_count_R_ver_str' declared as function returning a function /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:203: warning: parameter names (without types) in function declaration make[3]: *** [3w-_10200033.o] Error 1 make[3]: Leaving directory `/usr/src/linux-2.4.21-32.0.1.EL/drivers/addon/3w-_10200033' make[2]: *** [_modsubdir_3w-_10200033] Error 2 make[2]: Leaving directory `/usr/src/linux-2.4.21-32.0.1.EL/drivers/addon' make[1]: *** [_modsubdir_addon] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4.21-32.0.1.EL/drivers' make: *** [_mod_drivers] Error 2 Is there any relationship between the sysrq-m changes to do show_state() rather than a show_mem() and the compiling erros? /usr/src/linux-2.4.21-32.0.1.EL/include/linux/prefetch.h, line 13: #include /usr/src/linux-2.4.21-32.0.1.EL/include/linux/list.h ,line 6: #include /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h, line 12: #include 3w-.c, line 172: #include Any ideia about the kernel compiling erros? (If I try to recompile a kernel.org kernel, it
Re: fix suspend/resume irq request free for yenta..
. > > > > What if some other driver is sharing the IRQ, and requires IRQs to be > > enabled for the resume to complete? All drivers re-enable IRQs on their way back up in their resume code, they shouldn't be doing anything before that point.. > This certainly is the case on many laptops. Well at the moment on my laptop without this patch we don't make it back, and we've done a lot of talking at OLS about this.. patches like this will be popping up for most drivers soon Dave. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] reset VGA adapters via BIOS on resume... (non-fbdev/con)
> > For Intel at least the recommendation is to use the BIOS "save > mode"/"restore mode" interface. I'm going to see about implementing that on my PC when I get back to home, it doesn't seem like too bad an idea either... We are also going to provide some hooks out to userspace as well.. but I'd be interested in trying as many in-kernel solutions before going down that road... Dave. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 2.6.13-rc3] i386: add alternative_output() for altinstructions
This patch adds alternative_output() for altinstructions that
have output. Only one output is allowed.
It also cleans up the comments for alternative_input().
With this patch in place, I cleaned up the i387 save/restore in
my local copy so it now looks like this:
===
static inline void restore_fpu( struct task_struct *tsk )
{
alternative_input(
"frstor %1 ; nop",
"fxrstor %1",
X86_FEATURE_FXSR,
"m" (tsk->thread.i387.fxsave));
}
static inline void __save_init_fpu( struct task_struct *tsk )
{
alternative_output(
"fnsave %0 ; nop ; fwait ; nop",
"fxsave %0 ; fnclex",
X86_FEATURE_FXSR,
"=m" (tsk->thread.i387.fxsave));
tsk->thread_info->status &= ~TS_USEDFPU;
}
===
Signed-off-by: Chuck Ebbert <[EMAIL PROTECTED]>
Index: 2.6.13-rc3a/include/asm-i386/system.h
===
--- 2.6.13-rc3a.orig/include/asm-i386/system.h 2005-06-24 00:50:33.0
-0400
+++ 2.6.13-rc3a/include/asm-i386/system.h 2005-07-23 15:36:02.0
-0400
@@ -313,13 +313,13 @@
/*
* Alternative inline assembly with input.
- *
- * Pecularities:
- * No memory clobber here.
+ *
+ * Peculiarities:
+ * No memory clobber here.
* Argument numbers start with 1.
* Best is to use constraints that are fixed size (like (%1) ... "r")
- * If you use variable sized constraints like "m" or "g" in the
- * replacement maake sure to pad to the worst case length.
+ * If you use variable sized constraints like "m" or "g" in the
+ * replacement make sure to pad to the worst case length.
*/
#define alternative_input(oldinstr, newinstr, feature, input...)
\
asm volatile ("661:\n\t" oldinstr "\n662:\n"
\
@@ -336,6 +336,27 @@
".previous" :: "i" (feature), ##input)
/*
+ * Alternative inline assembly with output.
+ *
+ * Same as alternative_input, except:
+ * No inputs.
+ * Only one output: 0.
+ */
+#define alternative_output(oldinstr, newinstr, feature, output...)
\
+ asm volatile ("661:\n\t" oldinstr "\n662:\n"
\
+ ".section .altinstructions,\"a\"\n"
\
+ " .align 4\n"
\
+ " .long 661b\n"/* label */
\
+ " .long 663f\n"/* new instruction */
\
+ " .byte %c1\n" /* feature bit */
\
+ " .byte 662b-661b\n" /* sourcelen */
\
+ " .byte 664f-663f\n" /* replacementlen */
\
+ ".previous\n"
\
+ ".section .altinstr_replacement,\"ax\"\n"
\
+ "663:\n\t" newinstr "\n664:\n" /* replacement */
\
+ ".previous" : output : "i" (feature))
+
+/*
* Force strict CPU ordering.
* And yes, this is required on UP too when we're talking
* to devices.
__
Chuck
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] DEBUG_FS must depend on SYSFS
CONFIG_DEBUG_FS=y and CONFIG_SYSFS=n results in the following compile error: <-- snip --> ... LD vmlinux fs/built-in.o: In function `debugfs_init': inode.c:(.init.text+0x31be): undefined reference to `kernel_subsys' make: *** [vmlinux] Error 1 <-- snip --> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- linux-2.6.13-rc3-mm1-full/lib/Kconfig.debug.old 2005-07-23 22:20:35.0 +0200 +++ linux-2.6.13-rc3-mm1-full/lib/Kconfig.debug 2005-07-23 22:20:49.0 +0200 @@ -170,7 +170,7 @@ config DEBUG_FS bool "Debug Filesystem" - depends on DEBUG_KERNEL + depends on DEBUG_KERNEL && SYSFS help debugfs is a virtual file system that kernel developers use to put debugging files into. Enable this option to be able to read and - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 page size explanation
Hi, Jesper, RE: > > 2. how can one tune it (for 2.6.*)? > > For some archs the page size can be set at compile-time with > CONFIG_PAGE_SIZE_4KB, CONFIG_PAGE_SIZE_8KB etc - mips is an example of > such an arch (also take a look at CONFIG_HUGETLB_PAGE and friends). OK, now i figured it out. On AMD opteron 64 bit processors the only option is the default: 4Kb. For itanium and mips, indeed, there are multiple options. My CPUs are opteron 64 bit ones; that is why i was not able to find this feature (of tuning it). > > How can i figure out the page size of the kernel i am currently using? > > > You can > A) look in the .config file for your current kernel (if your arch > supports different page sizes at all). Not there. > C) You can look at /proc/cpuinfo or /proc/meminfo , IIRC some archs > report page size there - not quite sure, can't remember... Probably not in meminfo, but possibly in cpuinfo: cat /proc/cpuinfo ... TLB size: 1024 4K pages ... cat /proc/meminfo MemTotal: 4010956 kB MemFree: 3848060 kB Buffers: 0 kB Cached: 45696 kB SwapCached: 0 kB Active: 90432 kB Inactive: 4820 kB HighTotal: 0 kB HighFree:0 kB LowTotal: 4010956 kB LowFree: 3848060 kB SwapTotal: 7823576 kB SwapFree: 7823352 kB Dirty: 20 kB Writeback: 0 kB Mapped: 78668 kB Slab:46216 kB CommitLimit: 9829052 kB Committed_AS: 142036 kB PageTables: 3252 kB VmallocTotal: 34359738367 kB VmallocUsed: 5724 kB VmallocChunk: 34359732179 kB HugePages_Total: 0 HugePages_Free: 0 Hugepagesize: 2048 kB Cheers Gaspar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] merge some from Rusty's trivial patches
This patch contains the most trivial from Rusty's trivial patches:
- spelling fixes
- remove duplicate includes
I don't see a reason why they shouldn't be merged now.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
Documentation/mono.txt |2 +-
Documentation/pci.txt|2 +-
Documentation/sysrq.txt |2 +-
arch/ppc/kernel/cpu_setup_6xx.S |1 -
arch/ppc/kernel/cpu_setup_power4.S |1 -
arch/ppc/kernel/dma-mapping.c|2 +-
arch/ppc64/kernel/cpu_setup_power4.S |1 -
drivers/ide/ide-io.c |6 +++---
drivers/md/md.c |4 ++--
drivers/parisc/lasi.c|1 -
drivers/scsi/ibmmca.c|1 -
ipc/mqueue.c |2 +-
12 files changed, 10 insertions(+), 15 deletions(-)
--- linux-2.6.12-rc6-git6/Documentation/mono.txt2005-02-04
18:45:51.0 +1100
+++ .31090.trivial/Documentation/mono.txt 2005-06-14 09:39:28.007622592
+1000
@@ -30,7 +30,7 @@ other program after you have done the fo
Read the file 'binfmt_misc.txt' in this directory to know
more about the configuration process.
-3) Add the following enries to /etc/rc.local or similar script
+3) Add the following entries to /etc/rc.local or similar script
to be run at system startup:
# Insert BINFMT_MISC module into the kernel
--- linux-2.6.12-rc6-git6/Documentation/pci.txt 2005-06-10 09:16:18.0
+1000
+++ .31090.trivial/Documentation/pci.txt2005-06-14 09:39:28.076612104
+1000
@@ -84,7 +84,7 @@ Each entry consists of:
Most drivers don't need to use the driver_data field. Best practice
for use of driver_data is to use it as an index into a static list of
-equivalant device types, not to use it as a pointer.
+equivalent device types, not to use it as a pointer.
Have a table entry {PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID}
to have probe() called for every PCI device known to the system.
--- linux-2.6.12-rc6-git6/Documentation/sysrq.txt 2005-06-10
09:16:19.0 +1000
+++ .31090.trivial/Documentation/sysrq.txt 2005-06-14 09:39:28.145601616
+1000
@@ -166,7 +166,7 @@ the header 'include/linux/sysrq.h', this
Next, you must create a sysrq_key_op struct, and populate it with A) the key
handler function you will use, B) a help_msg string, that will print when SysRQ
prints help, and C) an action_msg string, that will print right before your
-handler is called. Your handler must conform to the protoype in 'sysrq.h'.
+handler is called. Your handler must conform to the prototype in 'sysrq.h'.
After the sysrq_key_op is created, you can call the macro
register_sysrq_key(int key, struct sysrq_key_op *op_p) that is defined in
--- linux-2.6.12-rc6-git6/arch/ppc/kernel/cpu_setup_6xx.S 2005-06-10
09:16:30.0 +1000
+++ .31090.trivial/arch/ppc/kernel/cpu_setup_6xx.S 2005-06-14
09:39:28.307576992 +1000
@@ -14,7 +14,6 @@
#include
#include
#include
-#include
#include
#include
--- linux-2.6.12-rc6-git6/arch/ppc/kernel/cpu_setup_power4.S2005-02-04
18:48:44.0 +1100
+++ .31090.trivial/arch/ppc/kernel/cpu_setup_power4.S 2005-06-14
09:39:28.376566504 +1000
@@ -14,7 +14,6 @@
#include
#include
#include
-#include
#include
#include
--- linux-2.6.12-rc6-git6/arch/ppc/kernel/dma-mapping.c 2005-06-10
09:16:30.0 +1000
+++ .31090.trivial/arch/ppc/kernel/dma-mapping.c2005-06-14
09:39:27.794654968 +1000
@@ -393,7 +393,7 @@ EXPORT_SYMBOL(__dma_sync);
* __dma_sync_page() implementation for systems using highmem.
* In this case, each page of a buffer must be kmapped/kunmapped
* in order to have a virtual address for __dma_sync(). This must
- * not sleep so kmap_atmomic()/kunmap_atomic() are used.
+ * not sleep so kmap_atomic()/kunmap_atomic() are used.
*
* Note: yes, it is possible and correct to have a buffer extend
* beyond the first page.
--- linux-2.6.12-rc6-git6/arch/ppc64/kernel/cpu_setup_power4.S 2005-02-04
18:49:52.0 +1100
+++ .31090.trivial/arch/ppc64/kernel/cpu_setup_power4.S 2005-06-14
09:39:28.236587784 +1000
@@ -14,7 +14,6 @@
#include
#include
#include
-#include
#include
#include
--- linux-2.6.12-rc6-git6/drivers/ide/ide-io.c 2005-06-10 09:16:55.0
+1000
+++ .31090.trivial/drivers/ide/ide-io.c 2005-06-14 09:39:27.867643872 +1000
@@ -560,7 +560,7 @@ ide_startstop_t __ide_abort(ide_drive_t
EXPORT_SYMBOL_GPL(__ide_abort);
/**
- * ide_abort - abort pending IDE operatins
+ * ide_abort - abort pending IDE operations
* @drive: drive the error occurred on
* @msg: message to report
*
@@ -623,7 +623,7 @@ static void ide_cmd (ide_drive_t *drive,
* @drive: drive the completion interrupt occurred on
*
* drive_cmd_intr() is invoked on completion of a special DRIVE_CMD.
- * We do any necessary daya reading and then wait for the drive to
+ * We do
[2.6 patch] FB_INTEL must depend on HW_CONSOLE
CONFIG_FB_INTEL=y and CONFIG_HW_CONSOLE results in the following compile error: <-- snip --> ... LD vmlinux drivers/built-in.o: In function `intelfb_pci_register': intelfbdrv.c:(.text+0x171960): undefined reference to `color_table' intelfbdrv.c:(.text+0x171971): undefined reference to `default_red' intelfbdrv.c:(.text+0x17197e): undefined reference to `default_grn' intelfbdrv.c:(.text+0x17198b): undefined reference to `default_blu' intelfbdrv.c:(.text+0x17199a): undefined reference to `color_table' make: *** [vmlinux] Error 1 <-- snip --> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- linux-2.6.13-rc3-mm1-full/drivers/video/Kconfig.old 2005-07-23 22:12:18.0 +0200 +++ linux-2.6.13-rc3-mm1-full/drivers/video/Kconfig 2005-07-23 22:12:51.0 +0200 @@ -756,7 +756,7 @@ config FB_INTEL tristate "Intel 830M/845G/852GM/855GM/865G support (EXPERIMENTAL)" - depends on FB && EXPERIMENTAL && PCI && X86 && !X86_64 + depends on FB && HW_CONSOLE && EXPERIMENTAL && PCI && X86 && !X86_64 select AGP select AGP_INTEL select FB_MODE_HELPERS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] SECURITY must depend on SYSFS
CONFIG_SECURITY=y and CONFIG_SYSFS=n results in the following compile error: <-- snip --> ... LD vmlinux security/built-in.o: In function `securityfs_init': inode.c:(.init.text+0x1c2): undefined reference to `kernel_subsys' make: *** [vmlinux] Error 1 <-- snip --> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- linux-2.6.13-rc3-mm1-full/security/Kconfig.old 2005-07-23 20:21:09.0 +0200 +++ linux-2.6.13-rc3-mm1-full/security/Kconfig 2005-07-23 20:22:22.0 +0200 @@ -35,6 +35,7 @@ config SECURITY bool "Enable different security models" + depends on SYSFS help This allows you to choose different security modules to be configured into your kernel. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] net/ipv4/: possible cleanups
This patch contains the following possible cleanups:
- make needlessly global code static
- #if 0 the following unused global function:
- xfrm4_state.c: xfrm4_state_fini
- remove the following unneeded EXPORT_SYMBOL's:
- ip_output.c: ip_finish_output
- ip_output.c: sysctl_ip_default_ttl
- fib_frontend.c: ip_dev_find
- inetpeer.c: inet_peer_idlock
- ip_options.c: ip_options_compile
- ip_options.c: ip_options_undo
- net/core/request_sock.c: sysctl_max_syn_backlog
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch was already sent on:
- 26 Jun 2005
include/net/ip.h |2 --
include/net/route.h |4
include/net/xfrm.h |1 -
net/core/request_sock.c |1 -
net/ipv4/fib_frontend.c |1 -
net/ipv4/inetpeer.c |2 --
net/ipv4/ip_options.c|3 ---
net/ipv4/ip_output.c |7 +--
net/ipv4/multipath_drr.c |2 +-
net/ipv4/route.c |4 +++-
net/ipv4/xfrm4_state.c |2 ++
11 files changed, 7 insertions(+), 22 deletions(-)
--- linux-2.6.12-rc3-mm2-full/include/net/ip.h.old 2005-05-05
02:35:00.0 +0200
+++ linux-2.6.12-rc3-mm2-full/include/net/ip.h 2005-05-05 02:35:07.0
+0200
@@ -140,8 +140,6 @@
void ip_send_reply(struct sock *sk, struct sk_buff *skb, struct ip_reply_arg
*arg,
unsigned int len);
-extern int ip_finish_output(struct sk_buff *skb);
-
struct ipv4_config
{
int log_martians;
--- linux-2.6.12-rc3-mm2-full/net/ipv4/multipath_drr.c.old 2005-05-05
02:37:58.0 +0200
+++ linux-2.6.12-rc3-mm2-full/net/ipv4/multipath_drr.c 2005-05-05
02:38:06.0 +0200
@@ -107,7 +107,7 @@
return NOTIFY_DONE;
}
-struct notifier_block drr_dev_notifier = {
+static struct notifier_block drr_dev_notifier = {
.notifier_call = drr_dev_event,
};
--- linux-2.6.12-rc3-mm3-full/net/ipv4/ip_output.c.old 2005-05-05
21:43:22.0 +0200
+++ linux-2.6.12-rc3-mm3-full/net/ipv4/ip_output.c 2005-05-05
21:44:36.0 +0200
@@ -216,7 +216,7 @@
return -EINVAL;
}
-int ip_finish_output(struct sk_buff *skb)
+static int ip_finish_output(struct sk_buff *skb)
{
struct net_device *dev = skb->dst->dev;
@@ -1351,12 +1351,7 @@
#endif
}
-EXPORT_SYMBOL(ip_finish_output);
EXPORT_SYMBOL(ip_fragment);
EXPORT_SYMBOL(ip_generic_getfrag);
EXPORT_SYMBOL(ip_queue_xmit);
EXPORT_SYMBOL(ip_send_check);
-
-#ifdef CONFIG_SYSCTL
-EXPORT_SYMBOL(sysctl_ip_default_ttl);
-#endif
--- linux-2.6.12-rc3-mm3-full/net/ipv4/route.c.old 2005-05-05
21:21:21.0 +0200
+++ linux-2.6.12-rc3-mm3-full/net/ipv4/route.c 2005-05-05 21:22:14.0
+0200
@@ -209,7 +209,9 @@
static int rt_hash_log;
static unsigned intrt_hash_rnd;
-struct rt_cache_stat *rt_cache_stat;
+static struct rt_cache_stat *rt_cache_stat;
+#define RT_CACHE_STAT_INC(field) \
+ (per_cpu_ptr(rt_cache_stat, _smp_processor_id())->field++)
static int rt_intern_hash(unsigned hash, struct rtable *rth,
struct rtable **res);
--- linux-2.6.12-rc3-mm3-full/include/net/xfrm.h.old2005-05-05
21:26:56.0 +0200
+++ linux-2.6.12-rc3-mm3-full/include/net/xfrm.h2005-05-05
21:27:01.0 +0200
@@ -799,7 +799,6 @@
extern void xfrm6_fini(void);
extern void xfrm_state_init(void);
extern void xfrm4_state_init(void);
-extern void xfrm4_state_fini(void);
extern void xfrm6_state_init(void);
extern void xfrm6_state_fini(void);
--- linux-2.6.12-rc3-mm3-full/net/ipv4/xfrm4_state.c.old2005-05-05
21:27:09.0 +0200
+++ linux-2.6.12-rc3-mm3-full/net/ipv4/xfrm4_state.c2005-05-05
21:27:24.0 +0200
@@ -119,8 +119,10 @@
xfrm_state_register_afinfo(_state_afinfo);
}
+#if 0
void __exit xfrm4_state_fini(void)
{
xfrm_state_unregister_afinfo(_state_afinfo);
}
+#endif /* 0 */
--- linux-2.6.12-rc3-mm3-full/net/ipv4/fib_frontend.c.old 2005-05-05
21:38:28.0 +0200
+++ linux-2.6.12-rc3-mm3-full/net/ipv4/fib_frontend.c 2005-05-05
21:38:40.0 +0200
@@ -607,5 +607,4 @@
}
EXPORT_SYMBOL(inet_addr_type);
-EXPORT_SYMBOL(ip_dev_find);
EXPORT_SYMBOL(ip_rt_ioctl);
--- linux-2.6.12-rc3-mm3-full/net/ipv4/inetpeer.c.old 2005-05-05
21:41:06.0 +0200
+++ linux-2.6.12-rc3-mm3-full/net/ipv4/inetpeer.c 2005-05-05
21:41:14.0 +0200
@@ -456,5 +456,3 @@
peer_total / inet_peer_threshold * HZ;
add_timer(_periodic_timer);
}
-
-EXPORT_SYMBOL(inet_peer_idlock);
--- linux-2.6.12-rc3-mm3-full/net/ipv4/ip_options.c.old 2005-05-05
21:42:02.0 +0200
+++ linux-2.6.12-rc3-mm3-full/net/ipv4/ip_options.c 2005-05-05
21:42:33.0 +0200
@@ -620,6 +620,3 @@
}
return 0;
}
-
-EXPORT_SYMBOL(ip_options_compile);
-EXPORT_SYMBOL(ip_options_undo);
--- linux-2.6.12-mm1-full/include/net/route.h.old 2005-06-26
[-mm patch] DLM must depend on SYSFS
CONFIG_DLM=y and CONFIG_SYSFS=n results in the following compile error: <-- snip --> ... LD vmlinux drivers/built-in.o:(.data+0x271e80): undefined reference to `kernel_subsys' make: *** [vmlinux] Error 1 <-- snip --> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- linux-2.6.13-rc3-mm1-full/drivers/dlm/Kconfig.old 2005-07-23 22:24:35.0 +0200 +++ linux-2.6.13-rc3-mm1-full/drivers/dlm/Kconfig 2005-07-23 22:26:00.0 +0200 @@ -3,6 +3,7 @@ config DLM tristate "Distributed Lock Manager (DLM)" + depends on SYSFS select IP_SCTP help A general purpose distributed lock manager for kernel or userspace - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 optimization
I submit that sparse switch jump table's are not an "unusual" construct in the Linux kernel/drivers. GCC only creates a table large enough to cover the largest of the sparse values - it doesn't have to be 0...255. 0...60 with 10 values sparsely scattered would generate a 61 element jump table. There's many K of locked memory in these sparse jump tables. About 2K worth in the VT102 code alone. - Original Message - From: "Alan Cox" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "Adrian Bunk" <[EMAIL PROTECTED]>; Sent: Saturday, July 23, 2005 15:50 Subject: Re: kernel optimization > On Sad, 2005-07-23 at 02:30 -0400, [EMAIL PROTECTED] wrote: > > Larger does not always mean slower. If it did, nobody would implement a > > loop unrolling optimization. > > Generally speaking nowdays it does. Almost all loop unrolls are a loss > on PIV. > > > ex. Look at how GCC generates jump tables for switch() when there's about > > 10-12 (or more) case's sparsely scattered in the rage from 0 through 255. > > You are comparing with very expensive jump operations its an unusual > case. For the majority of situations the TLB/cache overhead of misses > vastly outweighs the odd clock cycle gained by verbose output. > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[cpufreq] ondemand works, conservative doesn't
Hi, currently, i'm using the ondemand governor. My CPU supports the frequencies 800, 1800 and 2000 MHz (AMD Athlon64 Desktop with Cool). The simple bash commands while true do true done cause 100% CPU usage, and the CPU immediatly switched from 800 to 2000MHz. Using the conservative govenor, nothing happens. I would expect, that the cpu switches to 1800 and than to 2000 Mhz after some seconds of full CPU usage. What's wrong? My guess is, that the conservative govenor would need more frequencies between 800 and 1800MHz to work properly. Thx Sven signature.asc Description: OpenPGP digital signature
Re: [2.6 patch] drivers/ieee1394/sbp2.c: fix warnings with -Wundef
On 22 Jul, Adrian Bunk wrote:
> drivers/ieee1394/sbp2.c:202:5: warning: "CONFIG_IEEE1394_SBP2_DEBUG" is not
> defined
> drivers/ieee1394/sbp2.c:207:7: warning: "CONFIG_IEEE1394_SBP2_DEBUG" is not
> defined
> drivers/ieee1394/sbp2.c:2053:6: warning: "CONFIG_IEEE1394_SBP2_DEBUG" is not
> defined
> drivers/ieee1394/sbp2.c:2623:5: warning: "CONFIG_IEEE1394_SBP2_DEBUG" is not
> defined
Here is a minimally improved version of the patch. I kept your sign-off.
- - - - - - - - - - - - 8< - - - - - - - - - - - -
sbp2: fix compiler warnings with -Wundef
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
Index: linux-2.6.13-rc3/drivers/ieee1394/sbp2.c
===
--- linux-2.6.13-rc3/drivers/ieee1394/sbp2.c(revision 1316)
+++ linux-2.6.13-rc3/drivers/ieee1394/sbp2.c(working copy)
@@ -171,10 +171,12 @@
/* #define CONFIG_IEEE1394_SBP2_DEBUG_ORBS */
/* #define CONFIG_IEEE1394_SBP2_DEBUG_DMA */
-/* #define CONFIG_IEEE1394_SBP2_DEBUG 1 */
-/* #define CONFIG_IEEE1394_SBP2_DEBUG 2 */
/* #define CONFIG_IEEE1394_SBP2_PACKET_DUMP */
+/* increase to 1 for verbose logging, to 2 for even more logging */
+#define CONFIG_IEEE1394_SBP2_DEBUG 0
+
+
#ifdef CONFIG_IEEE1394_SBP2_DEBUG_ORBS
#define SBP2_ORB_DEBUG(fmt, args...) HPSB_ERR("sbp2(%s): "fmt, __FUNCTION__,
## args)
static u32 global_outstanding_command_orbs = 0;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kill bio->bi_set
On Sat, Jul 23 2005, Peter Osterlund wrote:
> Jens Axboe <[EMAIL PROTECTED]> writes:
>
> > Dunno why I didn't notice before, but ->bi_set is totally unnecessary
> > bloat of struct bio. Just define a proper destructor for the bio and it
> > already knows what bio_set it belongs too.
>
> This causes crashes on my computer.
Did I neglect to mention it was untested? :)
> > +void bio_free(struct bio *bio, struct bio_set *bio_set)
> > {
> > const int pool_idx = BIO_POOL_IDX(bio);
> > - struct bio_set *bs = bio->bi_set;
> >
> > BIO_BUG_ON(pool_idx >= BIOVEC_NR_POOLS);
> >
> > - mempool_free(bio->bi_io_vec, bs->bvec_pools[pool_idx]);
> > - mempool_free(bio, bs->bio_pool);
> > + mempool_free(bio->bi_io_vec, fs_bio_set->bvec_pools[pool_idx]);
> > + mempool_free(bio, fs_bio_set->bio_pool);
> > +}
>
> This function uses fs_bio_set instead of the function parameter
> bio_set.
Clear mistake, thanks.
> > @@ -171,8 +175,6 @@ struct bio *bio_alloc_bioset(unsigned in
> > bio->bi_max_vecs = bvec_slabs[idx].nr_vecs;
> > }
> > bio->bi_io_vec = bvl;
> > - bio->bi_destructor = bio_destructor;
> > - bio->bi_set = bs;
> > }
>
> This change means that all code that calls bio_alloc_bioset() must now
Correct. The alternative was to require a destructor function passed
into bio_alloc_bioset().
> set bi_destructor, but this is forgotten in bio_clone() in bio.c and
> in split_bvec() in dm.c.
Thanks, I'll go over these and submit a fixed version.
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Add schedule_timeout_{interruptible,uninterruptible}{,_msecs}() interfaces
Hi,
On Sat, 23 Jul 2005, Nishanth Aravamudan wrote:
> > What's wrong with just:
> >
> >
> > schedule_timeout_{,un}interruptible(msecs_to_jiffies(some_constant_msecs));
>
> Nothing, I suppose. I just prefer directly using msecs. I understand
> your point more now, I think. You are worried about those people that
> actually use the return value of schedule_timeout().
It's only half the point:
> > The majority of users use a constant, which can already be converted at
> > compile tile.
The kernel time unit is and will be jiffies and the kernel time functions
should be in ticks with some optional wrappers in other time units, not
the other way around.
> 2) Sleep in a loop, keeping track of remaining timeout each iteration:
>
> while (timeout) {
> do_some_stuff();
> timeout = schedule_timeout(timeout);
> if (some_condition)
> break;
> }
This actually is a pre-preempt construct and should probably use
time_before() now.
bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add schedule_timeout_{interruptible,uninterruptible}{,_msecs}() interfaces
Hi,
On Sat, 23 Jul 2005, Nishanth Aravamudan wrote:
> > Jiffies are the basic time unit for kernel timers, hiding that fact gives
> > users only wrong expectations about them.
>
> We already have msleep() and msleep_interruptible(), which hide jiffies
> in milliseconds. These interfaces are their parallel in the wait-queue
> case. If you don't want to use them, or their use is not appropriate,
> then the callers won't be changed.
I'm not exactly impressed with their implementation, it's completely silly
that there is no such convience function based on jiffies, e.g. if you
look at the msleep_interruptible(), you'll find quite a few
"msleep_interruptible(jiffies_to_msecs())".
msleep_interruptible() is especially bad as there are a few users who
check the return value and since it adds one to the timeout, you can
create loops which may never timeout (as e.g. in drivers/w1/w1_therm.c:
w1_therm_read_bin()), this is nice example of a bad interface.
These two function should actually look like this:
static inline void msleep(unsigned int msecs)
{
sleep(msecs_to_jiffies(msecs));
}
static inline int msleep_interruptible(unsigned int msecs)
{
sleep_interruptible(msecs_to_jiffies(msecs)) != 0;
}
> My goal is to distinguish between these cases in sleeping-logic:
>
> 1) tick-oriented
> use schedule_timeout(), add_timer(), etc.
>
> 2) time-oriented
> use schedule_timeout_msecs()
There is _no_ difference, the scheduler is based on ticks. Even if we soon
have different time sources, the scheduler will continue to measure the
time in ticks and for a simple reason - portability. Jiffies _are_ simple,
don't throw that away.
bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.13-rc3] pcmcia: pcmcia_request_irq for !IRQ_HANDLE_PRESENT
Hi,
> When a driver calls pcmcia_request_irq with IRQ_HANDLE_PRESENT unset, it looks
> for an open IRQ by request_irq()ing with a dummy handler and NULL dev_info.
> free_irq uses dev_info as a key for identifying the handler to free among
> those
> sharing an IRQ, so request_irq returns -EINVAL if dev_info is NULL and the IRQ
> may be shared. That unknown error code is the -EINVAL.
>
> It looks like only pcnet_cs and axnet_cs are affected. Most other drivers let
> pcmcia_request_irq install their interrupt handlers. sym53c500_cs requests
> its
> IRQ manually, but it cannot share an IRQ.
>
> The appended patch changes pcmcia_request_irq to pass an arbitrary, unique,
> non-NULL dev_info with the dummy handler.
Thanks for the excellent debugging. Your patch seems to work, however it
might be better to do just this:
Index: 2.6.13-rc3-git2/drivers/pcmcia/pcmcia_resource.c
===
--- 2.6.13-rc3-git2.orig/drivers/pcmcia/pcmcia_resource.c
+++ 2.6.13-rc3-git2/drivers/pcmcia/pcmcia_resource.c
@@ -800,7 +800,7 @@ int pcmcia_request_irq(struct pcmcia_dev
} else {
int try;
u32 mask = s->irq_mask;
- void *data = NULL;
+ void *data = test_action;
for (try = 0; try < 64; try++) {
irq = try % 32;
Thanks,
Dominik
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] pcibios_bus_to_resource for parisc [Was: Re: [PATCH 8/8] pci and yenta: pcibios_bus_to_resource]
On Mon, Jul 18, 2005 at 01:42:16PM -0600, Grant Grundler wrote:
> On Tue, Jul 12, 2005 at 12:21:38AM +0200, Dominik Brodowski wrote:
> > In yenta_socket, we default to using the resource setting of the CardBus
> > bridge. However, this is a PCI-bus-centric view of resources and thus
> > needs to be converted to generic resources first. Therefore, add a call
> > to pcibios_bus_to_resource() call in between. This function is a mere
> > wrapper on x86 and friends, however on some others it already exists, is
> > added in this patch (alpha, arm, ppc, ppc64) or still needs to be
> > provided (parisc -- where is its pcibios_resource_to_bus() ?).
>
> in arch/parisc/kernel/pci.c?
> At least, it seems to be present in the 2.6.13-rc1 tree
> on cvs.parisc-linux.org tree.
Oh, yes, I seem to have missed it. Sorry. Does this patch look good?
Add pcibios_bus_to_resource for parisc.
Signed-off-by: Dominik Brodowski <[EMAIL PROTECTED]>
Index: 2.6.13-rc3-git2/arch/parisc/kernel/pci.c
===
--- 2.6.13-rc3-git2.orig/arch/parisc/kernel/pci.c
+++ 2.6.13-rc3-git2/arch/parisc/kernel/pci.c
@@ -255,8 +255,26 @@ void __devinit pcibios_resource_to_bus(s
pcibios_link_hba_resources(>lmmio_space, bus->resource[1]);
}
+void pcibios_bus_to_resource(struct pci_dev *dev, struct resource *res,
+ struct pci_bus_region *region)
+{
+ struct pci_bus *bus = dev->bus;
+ struct pci_hba_data *hba = HBA_DATA(bus->bridge->platform_data);
+
+ if (res->flags & IORESOURCE_MEM) {
+ res->start = PCI_HOST_ADDR(hba, region->start);
+ res->end = PCI_HOST_ADDR(hba, region->end);
+ }
+
+ if (res->flags & IORESOURCE_IO) {
+ res->start = region->start;
+ res->end = region->end;
+ }
+}
+
#ifdef CONFIG_HOTPLUG
EXPORT_SYMBOL(pcibios_resource_to_bus);
+EXPORT_SYMBOL(pcibios_bus_to_resource);
#endif
/*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Device supported by the OSS trident driver not supported by ALSA
I'm currently creating a list of OSS drivers where all the hardware
supported by them is also supported by ALSA. The goal is to schedule
them for removal (except someone tells that for one or more of them ALSA
support is inferior).
The OSS trident driver has 5 different pci_device_id entries.
For 4 of them there seems to be similar ALSA support, but I can't find
any ALSA equivalent for the following entry:
{PCI_VENDOR_ID_INTERG, PCI_DEVICE_ID_INTERG_5050,
PCI_ANY_ID, PCI_ANY_ID, 0, 0, CYBER5050},
Can anyone tell my why this device is supported by the OSS trident
driver but not by ALSA?
TIA
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kill bio->bi_set
Jens Axboe <[EMAIL PROTECTED]> writes:
> Dunno why I didn't notice before, but ->bi_set is totally unnecessary
> bloat of struct bio. Just define a proper destructor for the bio and it
> already knows what bio_set it belongs too.
This causes crashes on my computer.
> +void bio_free(struct bio *bio, struct bio_set *bio_set)
> {
> const int pool_idx = BIO_POOL_IDX(bio);
> - struct bio_set *bs = bio->bi_set;
>
> BIO_BUG_ON(pool_idx >= BIOVEC_NR_POOLS);
>
> - mempool_free(bio->bi_io_vec, bs->bvec_pools[pool_idx]);
> - mempool_free(bio, bs->bio_pool);
> + mempool_free(bio->bi_io_vec, fs_bio_set->bvec_pools[pool_idx]);
> + mempool_free(bio, fs_bio_set->bio_pool);
> +}
This function uses fs_bio_set instead of the function parameter
bio_set.
> @@ -171,8 +175,6 @@ struct bio *bio_alloc_bioset(unsigned in
> bio->bi_max_vecs = bvec_slabs[idx].nr_vecs;
> }
> bio->bi_io_vec = bvl;
> - bio->bi_destructor = bio_destructor;
> - bio->bi_set = bs;
> }
This change means that all code that calls bio_alloc_bioset() must now
set bi_destructor, but this is forgotten in bio_clone() in bio.c and
in split_bvec() in dm.c.
--
Peter Osterlund - [EMAIL PROTECTED]
http://web.telia.com/~u89404340
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Mouse Freezes in Xorg on ASUS P4C800 Deluxe
I've posted the original mail to [EMAIL PROTECTED], too. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] reset VGA adapters via BIOS on resume... (non-fbdev/con)
On Sad, 2005-07-23 at 00:17 +0100, Matthew Garrett wrote: > Dave Airlie <[EMAIL PROTECTED]> wrote: > > > At OLS at lot of people were giving out about cards not resuming, > > so using a patch from Michael Marineau and help from lots of people > > sitting around in a circle at OLS I've gotten a patch that restores video > > on my laptop by going into real mode and re-posting the BIOS during > > resume, > > On laptops, the code at c000:0003 may jump to BIOS code that isn't > present after system boot. In userspace, this isn't too much of a > problem - the userspace code tends to just fall over rather than hanging > the machine. What happens if the kernel hits illegal or inappropriate > code on resume? For Intel at least the recommendation is to use the BIOS "save mode"/"restore mode" interface. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: HPT370 errors under 2.6.13-rc3-mm1
On Sad, 2005-07-23 at 14:28 +1200, mdew wrote:
> I'm unable to mount an ext2 drive using the hpt370A raid card.
>
> upon mounting the drive, dmesg will spew these errors..I've tried
> different cables and drive is fine.
> Jul 23 01:30:21 localhost kernel: hdf: dma timeout error: status=0x25
> { DeviceFault CorrectedError Error }
> Jul 23 01:30:21 localhost kernel: hdf: dma timeout error: error=0x25 {
> DriveStatusError AddrMarkNotFound }, LBAsect=8830589412645,
> high=526344, low=2434341, sector=390715711
Your drive disagrees with you. Note that it said
"Device fault"
"Error"
"Drive Status Error"
"Address Mark Not Found"
that came from the drive not the OS.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 optimization
On Sad, 2005-07-23 at 02:30 -0400, [EMAIL PROTECTED] wrote: > Larger does not always mean slower. If it did, nobody would implement a > loop unrolling optimization. Generally speaking nowdays it does. Almost all loop unrolls are a loss on PIV. > ex. Look at how GCC generates jump tables for switch() when there's about > 10-12 (or more) case's sparsely scattered in the rage from 0 through 255. You are comparing with very expensive jump operations its an unusual case. For the majority of situations the TLB/cache overhead of misses vastly outweighs the odd clock cycle gained by verbose output. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: HPT370 errors under 2.6.13-rc3-mm1
On Gwe, 2005-07-22 at 22:47 -0400, Bartlomiej Zolnierkiewicz wrote:
> Hi,
>
> Does vanilla kernel 2.6.12 work for you?
> It doesn't contain hpt366 driver update.
Its nothing to do with the driver. Read the trace Bartlomiej
> > Jul 23 01:30:21 localhost kernel: hdf: dma timeout error: status=0x25
> > { DeviceFault CorrectedError Error }
> > Jul 23 01:30:21 localhost kernel: hdf: dma timeout error: error=0x25 {
> > DriveStatusError AddrMarkNotFound }, LBAsect=8830589412645,
> > high=526344, low=2434341, sector=390715711
It timed out because the drive took a very long time to recover a bad
address mark but was able to do so.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[BUG] Tulip for ULi M5263: No packets transmitted
Hello, the tulip driver isn't work out for my ULi M5263 network adapter. The driver loads and the interface receives packets but it won't transmit any. Running a packet capture on it shows no outbound packets, so I guess the driver thinks the card is screwed up and can't transmit. I have a 939 AX8-M Motherboard with integrated ULi M5263 network adapter and the kernel version is 2.6.12.3. Another person with the same motherboard and problem was able to get the adapter running with ULi's GPL driver for 2.6.8 (haven't tryed that yet) but since the kernel driver's code explitly refers the M5262/3, I guess it's supposed to be supported. On dmesg, the following messages apear when the driver is loaded: Linux Tulip driver version 1.1.13 (May 11, 2002) ACPI: PCI Interrupt :00:0d.0[A] -> GSI 17 (level, low) -> IRQ 17 tulip0: EEPROM default media type Autosense. tulip0: Index #0 - Media MII (#11) described by a 21140 MII PHY (1) block. tulip0: Index #1 - Media 10baseT (#0) described by a (128) block. tulip0: Index #2 - Media 10baseT (#0) described by a 21140 non-MII (0) block. tulip0: Index #3 - Media 10base2 (#1) described by a 21140 non-MII (0) block. tulip0: Index #4 - Media 10baseT-FDX (#4) described by a 21140 non-MII (0) block. tulip0: Index #5 - Media 100baseTx-FDX (#5) described by a 21140 non-MII (0) block. tulip0: MII transceiver #31 config status 7849 advertising 01e1. When the interface is configured, the following message apears in dmesg: eth0: Invalid media table selection 128. A full copy of dmesg is attached. Thanks for your attention. -- Ricardo Linux version 2.6.12.3 ([EMAIL PROTECTED]) (gcc version 3.3.6 (Debian 1:3.3.6-7)) #1 Sun Jul 17 23:26:55 WEST 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e8000 - 0010 (reserved) BIOS-e820: 0010 - 3ffb (usable) BIOS-e820: 3ffb - 3ffc (ACPI data) BIOS-e820: 3ffc - 3fff (ACPI NVS) BIOS-e820: 3fff - 4000 (reserved) BIOS-e820: ff7c - 0001 (reserved) Warning only 896MB will be used. Use a HIGHMEM enabled kernel. 896MB LOWMEM available. found SMP MP-table at 000ff780 On node 0 totalpages: 229376 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 225280 pages, LIFO batch:31 HighMem zone: 0 pages, LIFO batch:1 DMI 2.3 present. ACPI: RSDP (v000 ACPIAM) @ 0x000f9e50 ACPI: RSDT (v001 A M I OEMRSDT 0x05000510 MSFT 0x0097) @ 0x3ffb ACPI: FADT (v001 A M I OEMFACP 0x05000510 MSFT 0x0097) @ 0x3ffb0200 ACPI: MADT (v001 A M I OEMAPIC 0x05000510 MSFT 0x0097) @ 0x3ffb0390 ACPI: OEMB (v001 A M I AMI_OEM 0x05000510 MSFT 0x0097) @ 0x3ffc0040 ACPI: DSDT (v001 939A8 939A8133 0x0133 INTL 0x02002026) @ 0x ACPI: PM-Timer IO Port: 0x808 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 15:15 APIC version 16 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x81] disabled) ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 1, version 17, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 4000 (gap: 4000:bf7c) Built 1 zonelists Kernel command line: ro root=/dev/hda3 single mapped APIC to d000 (fee0) mapped IOAPIC to c000 (fec0) Initializing CPU#0 PID hash table entries: 4096 (order: 12, 65536 bytes) Detected 1799.791 MHz processor. Using pmtmr for high-res timesource Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 903724k/917504k available (1533k kernel code, 13204k reserved, 719k data, 180k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay loop... 3579.90 BogoMIPS (lpj=1789952) Security Framework v1.0.0 initialized Capability LSM initialized Mount-cache hash table entries: 512 CPU: After generic identify, caps: 078bfbff e3d3fbff 0001 0001 CPU: After vendor identify, caps: 078bfbff e3d3fbff 0001 0001 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 512K (64 bytes/line) CPU: After all inits, caps: 078bfbff e3d3fbff 0010 0001 0001 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: AMD Athlon(tm) 64 Processor 3000+ stepping 00 Enabling fast FPU save and restore... done.
Re: tx queue start entry x dirty entry y (was 8139too PCI IRQ issues)
Mark Burton <[EMAIL PROTECTED]> writes: > Hi, > I'm getting similar results to Nick Warne, in that when my ethernet is > stressed at all (for instance by NFS), I end up with > nfs: server. not responding, still trying > nfs: server OK > > With a realtec card, I get errors in /var/spool/messages along the > lines of: > Jul 3 14:31:13 localhost kernel: eth1: Transmit timeout, status 0c > 0005 c07f media 00. > Jul 3 14:31:13 localhost kernel: eth1: Tx queue start entry 1160 > dirty entry 1156. > Jul 3 14:31:13 localhost kernel: eth1: Tx descriptor 0 is > 0008a03c. (queue head) Probably it's the miss config of PIC. Can you post more info? - /proc/interrupt - mptable - 8259A.pl - lspci -vvv -- OGAWA Hirofumi <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add schedule_timeout_{interruptible,uninterruptible}{,_msecs}() interfaces
On 23.07.2005 [19:01:57 +0200], Roman Zippel wrote:
> Hi,
>
> On Sat, 23 Jul 2005, Nishanth Aravamudan wrote:
>
> > set_current_state(TASK_{,UN}INTERRUPTIBLE);
> > schedule_timeout(msecs_to_jiffies(some_constant_msecs));
> >
> > just have an interface that allows
> >
> > schedule_timeout_msecs_{,un}interruptible(some_constant_msecs);
> >
> > and push the jiffies conversion to common code?
>
> What's wrong with just:
>
>
> schedule_timeout_{,un}interruptible(msecs_to_jiffies(some_constant_msecs));
Nothing, I suppose. I just prefer directly using msecs. I understand
your point more now, I think. You are worried about those people that
actually use the return value of schedule_timeout().
> The majority of users use a constant, which can already be converted at
> compile tile.
> Additionally such an interface also had to return a ms value and instead
> of that constant conversion, the user is better off to work with jiffies
> directly.
So, I just spent a good hour looking at every caller of
schedule_timeout() which actually stores the return value. Beyond the
other wrappers for it (wait_event(), wait_for_completion(),
sys_nanosleep(), etc., which I will leave alone using schedule_timeout()
until I can change *their* parameters ;) ), I found two cases.
1) Sleep, see if you actually slept the whole time:
remainder = schedule_timeout(some_value_in_jiffies);
if (!remaining)
report_timeout();
2) Sleep in a loop, keeping track of remaining timeout each iteration:
while (timeout) {
do_some_stuff();
timeout = schedule_timeout(timeout);
if (some_condition)
break;
}
Clearly, neither needs to use jiffies. The former only wants to know if
the full timeout elapsed. I didn't find anyone returning that stored
value (again, excepting wrapper interfaces) to the caller. They just
want to know if they should return -ETIME{,DOUT}. The latter just is a
means to guarantee the entire time is slept, but doesn't care about the
units.
Now, some of these might depend on structures which have members with
jiffy-unit values. But I will be more than happy to try and either leave
them alone or convert those structures. We'll see about that on a
case-by-case basis?
Thanks,
Nish
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Add schedule_timeout_{interruptible,uninterruptible}{,_msecs}() interfaces
On 23.07.2005 [19:17:37 +0200], Roman Zippel wrote:
> Hi,
>
> On Sat, 23 Jul 2005, Nishanth Aravamudan wrote:
>
> > > Keep the thing as simple as possible and jiffies _are_ simple. Please
> > > show
> > > me the problem, that needs to be fixed.
> >
> > I am not sure why jiffies are any simpler than milliseconds. In the
> > millisecond case, conversion happens in common code and only needs to be
> > audited once. In the jiffies case, I have to check *every* caller to see
> > if they are doing stupid math :)
>
> Jiffies are the basic time unit for kernel timers, hiding that fact gives
> users only wrong expectations about them.
We already have msleep() and msleep_interruptible(), which hide jiffies
in milliseconds. These interfaces are their parallel in the wait-queue
case. If you don't want to use them, or their use is not appropriate,
then the callers won't be changed.
> I don't mind using helper functions, but constant conversion can already
> happen at compile time and for variable timeouts the user should seriously
> consider using jiffies directly instead of constantly converting time
> values.
My goal is to distinguish between these cases in sleeping-logic:
1) tick-oriented
use schedule_timeout(), add_timer(), etc.
2) time-oriented
use schedule_timeout_msecs()
I am not going to run some global sed script to change the whole kernel.
I may not always be successful, but I do try to be cautious in my
patches. Only those callers that can benefit from using a millisecond
interface will be changed.
Another question (actually the same question expressed again), do Andrew
or Arjan think I should reinsert the
schedule_timeout_{,un}interruptible() functions for the 1) case above?
Thanks,
Nish
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: relayfs as infrastructure, ltt, systemtap, diskstat
On Fri, Jul 22, 2005 at 10:33:21PM +0200, bert hubert wrote: > On Fri, Jul 22, 2005 at 01:01:32PM -0700, Paul Jackson wrote: > > Another vote in favor of relayfs here ... > > At OLS the 'SystemTAP' idea was presented, which has been partially > implemented already, and it builds on relayfs as well. It dovetails nicely > with kprobes. And what exactly is this systemtap thing supposed to be? And why the heck do they announce it at some conference and we should suddenly care about it? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Re: relayfs documentation sucks?
On Fri, Jul 22, 2005 at 01:01:32PM -0700, Paul Jackson wrote: > Another vote in favor of relayfs here ... > > I am reminded by my good colleagues at SGI that relayfs is a key > to the Linux Trace Toolkit (LTT), which is in turn an important > technology for some product(s) on which SGI is working. I don't think anyone cares for product plans of particular companies. That beein said I wish LTT folks would make a little more progress so we could actually include it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Memory Management
On Fri, Jul 22, 2005 at 08:23:19PM -0300, Márcio Oliveira wrote: > > > Roger, thanks for the information. > > I'm using Update 4 kernels (2.4.21-27.ELsmp - This kernel have some > mm / oom fixes) and don't have big problems when create large files, > plus the server is a 32-bit machine. > > Neil said that the problem can be Low Memory and I think it too. > > I read the following message on the list: > > http://marc.theaimsgroup.com/?l=linux-kernel=112044530919567=4 > > The problem seems like a I/O issue. Can I/O (like storage devices) > consume a large amount of low memory? Neil also said that the kernel is > trying to move lots of data to the disk and it's a module might require > such large memory. Somebody know how can I identify what is using Low > Memory on my system? > The best way I can think to do that is take a look at /proc/slabinfo. That will likely give you a pointer to which area of code is eating up your memory. > The older questions in the message are: > > The server has 16GB RAM and 16GB swap. When the OOM kill conditions > happens, the system has ~6GB RAM used, ~10GB RAM cached and 16GB free swap. > Is that indicate that the server can't allocate Low Memory and starts OOM > conditions? Because the High Memory is OK, right? > Based on the sysrq-m info you posted it looks like due to fragmentation the largest chunk of memory you can allocate is 2MB (perhaps less depending on address space availability). If you can build a test kernel to do a show_state rather than a show_mem at the beginning of oom_kil, then you should be able to tell who is trying to do an allocation that leads to kswapd calling out_of_memory. > Thanks to all! > > Regards, > Márcio > > -- /*** *Neil Horman *Software Engineer *Red Hat, Inc. [EMAIL PROTECTED] *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.13-rc3a] i386: inline restore_fpu
On Sat, 23 Jul 2005, Arjan van de Ven wrote: > > For the kernel the runtime measurement is obviously tricky (kgprof > anyone?) Ehh, doesn't "opgprof" do that already? Anyway, judging by real life, people just don't _do_ profile runs. Any build automation that depends on the user profiling the result is a total wet dream by compiler developers - it just doesn't happen in real life. So: > but the static analysis method really shouldn't be too hard. I really think that the static analysis is the only one that actually would matter in real life. It's also the only one that is repeatable, which is a big big bonus, since at least that way different people are running basically the same code (heisenbugs, anyone?) and benchmarks are actually meaningful, since they don't depend on whatever load was picked to generate the layout. So dynamic analysis with dynamic profile data is just one big theoretical compiler-writer masturbation session, in my not-so-humble opinion. I bet static analysis (with possibly some hints from the programmer, the same way we use likely/unlikely) gets you 90% of the way, without all the downsides. 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/
[PATCH 2.6.13rc3] IPv6: Check interface bindings on IPv6 raw socket reception
Take account of whether a socket is bound to a particular device when
selecting an IPv6 raw socket to receive a packet. Also perform this
check when receiving IPv6 packets with router alert options.
Signed-off-by: Andrew McDonald <[EMAIL PROTECTED]>
diff -uprN linux-2.6.13-rc3.orig/include/net/rawv6.h
linux-2.6.13-rc3/include/net/rawv6.h
--- linux-2.6.13-rc3.orig/include/net/rawv6.h 2004-10-18 22:53:52.0
+0100
+++ linux-2.6.13-rc3/include/net/rawv6.h2005-07-23 13:18:46.0
+0100
@@ -10,7 +10,8 @@ extern rwlock_t raw_v6_lock;
extern void ipv6_raw_deliver(struct sk_buff *skb, int nexthdr);
extern struct sock *__raw_v6_lookup(struct sock *sk, unsigned short num,
- struct in6_addr *loc_addr, struct in6_addr
*rmt_addr);
+ struct in6_addr *loc_addr, struct in6_addr
*rmt_addr,
+ int dif);
extern int rawv6_rcv(struct sock *sk,
struct sk_buff *skb);
diff -uprN linux-2.6.13-rc3.orig/net/ipv6/icmp.c
linux-2.6.13-rc3/net/ipv6/icmp.c
--- linux-2.6.13-rc3.orig/net/ipv6/icmp.c 2005-07-23 10:28:47.0
+0100
+++ linux-2.6.13-rc3/net/ipv6/icmp.c2005-07-23 13:23:03.0 +0100
@@ -551,7 +551,8 @@ static void icmpv6_notify(struct sk_buff
read_lock(_v6_lock);
if ((sk = sk_head(_v6_htable[hash])) != NULL) {
- while((sk = __raw_v6_lookup(sk, nexthdr, daddr, saddr))) {
+ while((sk = __raw_v6_lookup(sk, nexthdr, daddr, saddr,
+ skb->dev->ifindex))) {
rawv6_err(sk, skb, NULL, type, code, inner_offset,
info);
sk = sk_next(sk);
}
diff -uprN linux-2.6.13-rc3.orig/net/ipv6/ip6_output.c
linux-2.6.13-rc3/net/ipv6/ip6_output.c
--- linux-2.6.13-rc3.orig/net/ipv6/ip6_output.c 2005-07-23 10:29:40.0
+0100
+++ linux-2.6.13-rc3/net/ipv6/ip6_output.c 2005-07-23 12:37:34.0
+0100
@@ -321,7 +321,9 @@ static int ip6_call_ra_chain(struct sk_b
read_lock(_ra_lock);
for (ra = ip6_ra_chain; ra; ra = ra->next) {
struct sock *sk = ra->sk;
- if (sk && ra->sel == sel) {
+ if (sk && ra->sel == sel &&
+ (!sk->sk_bound_dev_if ||
+sk->sk_bound_dev_if == skb->dev->ifindex)) {
if (last) {
struct sk_buff *skb2 = skb_clone(skb,
GFP_ATOMIC);
if (skb2)
diff -uprN linux-2.6.13-rc3.orig/net/ipv6/raw.c linux-2.6.13-rc3/net/ipv6/raw.c
--- linux-2.6.13-rc3.orig/net/ipv6/raw.c2005-07-23 10:29:40.0
+0100
+++ linux-2.6.13-rc3/net/ipv6/raw.c 2005-07-23 17:07:58.0 +0100
@@ -81,7 +81,8 @@ static void raw_v6_unhash(struct sock *s
/* Grumble... icmp and ip_input want to get at this... */
struct sock *__raw_v6_lookup(struct sock *sk, unsigned short num,
-struct in6_addr *loc_addr, struct in6_addr
*rmt_addr)
+struct in6_addr *loc_addr, struct in6_addr
*rmt_addr,
+int dif)
{
struct hlist_node *node;
int is_multicast = ipv6_addr_is_multicast(loc_addr);
@@ -94,6 +95,9 @@ struct sock *__raw_v6_lookup(struct sock
!ipv6_addr_equal(>daddr, rmt_addr))
continue;
+ if (sk->sk_bound_dev_if && sk->sk_bound_dev_if != dif)
+ continue;
+
if (!ipv6_addr_any(>rcv_saddr)) {
if (ipv6_addr_equal(>rcv_saddr, loc_addr))
goto found;
@@ -160,7 +164,7 @@ void ipv6_raw_deliver(struct sk_buff *sk
if (sk == NULL)
goto out;
- sk = __raw_v6_lookup(sk, nexthdr, daddr, saddr);
+ sk = __raw_v6_lookup(sk, nexthdr, daddr, saddr, skb->dev->ifindex);
while (sk) {
if (nexthdr != IPPROTO_ICMPV6 || !icmpv6_filter(sk, skb)) {
@@ -170,7 +174,8 @@ void ipv6_raw_deliver(struct sk_buff *sk
if (clone)
rawv6_rcv(sk, clone);
}
- sk = __raw_v6_lookup(sk_next(sk), nexthdr, daddr, saddr);
+ sk = __raw_v6_lookup(sk_next(sk), nexthdr, daddr, saddr,
+skb->dev->ifindex);
}
out:
read_unlock(_v6_lock);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.13-rc3a] i386: inline restore_fpu
On Sat, 2005-07-23 at 10:38 -0700, Linus Torvalds wrote: > So maybe a few hints to the binutils people might just make them go: "try > this patch/cmdline flag", and solve many more problems. They likely have a > lot of this kind of code _already_, or have at least been thinking about > it. > > I personally believe that there's likely a lot more to be had from code > (and data) layout than there is from things like alias analysis or > aggressive inlining. for userland it's not that complex and exists already; basically gprof has this analysis capability, and from that there's tooling (well I wrote it and I'm sure others did too) to create a linker script automatically to order things according to their gprof desired order. This gprof based approach is taking actual runtime patterns into account not just static callgraph analysis. For the kernel the runtime measurement is obviously tricky (kgprof anyone?) but the static analysis method really shouldn't be too hard. (well I guess "optimal" will be NP complete, but "pretty damn close" ought to be reasonable) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.13-rc3a] i386: inline restore_fpu
On Sat, 23 Jul 2005, Chuck Ebbert wrote: > > This patch (may not apply cleanly to unpatched -rc3) drops overhead > a few more percent: That really is pretty ugly. I'd rather hope for something like function-sections to just make games like this be unnecessary. The linker really should be able to do things like this for us (ie if it sees that the only reference to a function is from another function, it should be able to just put them next to each other anyway). And yes, I realize that "should be able" isn't the same thing as "does", but the thing is, doing it by hand ends up being a maintenance problem in the long run. It also misses all the other cases where it might be beneficial, but where you don't happen to run the right benchmark or look at the right place. So maybe a few hints to the binutils people might just make them go: "try this patch/cmdline flag", and solve many more problems. They likely have a lot of this kind of code _already_, or have at least been thinking about it. I personally believe that there's likely a lot more to be had from code (and data) layout than there is from things like alias analysis or aggressive inlining. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Supermount
> To mount on demand use autofs. Unmounting and dealing with media removal > is the problem. Granted, that can get pretty close. However, having to use /auto/* instead of mounting directly where required often limits using it quite a bit. Thus, I don't see it as a real alternative. - Tronic - signature.asc Description: OpenPGP digital signature
Re: [patch 2.6.13-rc3a] i386: inline restore_fpu
On Sat, 23 Jul 2005, Chuck Ebbert wrote: > >Probably a very minor point, but shouldn't it be > > "m" ((tsk)->thread.i387.fxsave)) > > because that's the largest possible operand that could end up being read? Yes, I ended up fixing that already (along with handling the fxsave case too). > Is that function called __save_init_fpu because it saves and then > initializes the fpu? Unlike fsave, fxsave does not init the fpu after > it saves the state; to make the behavior match it should be "fxsave ; fninit" The "init" part is really just "reset_exceptions" - we don't care about the rest of the state, and the naming is historical (ie it's really called "init" because "fnsave" does the reset by re-initializing everything, ie there's an implied "fninit"). So for the fxsave path, we just use fnclex, since that's faster than a full fninit. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.6.13rc3: RLIMIT_RTPRIO broken
Lee Revell wrote: > On Sat, 2005-07-23 at 13:42 +0200, Andreas Steinmetz wrote: > >>RLIMIT_RTPRIO is supposed to grant non privileged users the right to use >>SCHED_FIFO/SCHED_RR scheduling policies with priorites bounded by the >>RLIMIT_RTPRIO value via sched_setscheduler(). This is usually used by >>audio users. >> >>Unfortunately this is broken in 2.6.13rc3 as you can see in the excerpt >>from sched_setscheduler below: > > > Please provide the Signed-Off-By line. Also I have cc'ed Matt Mackall, > the original author of the patch. Sorry, I do forget this all the time... Signed-off-by: Andreas Steinmetz <[EMAIL PROTECTED]> -- Andreas Steinmetz SPAMmers use [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [RFT] solve "swsusp plays yoyo" with disks
Hi, On Thursday, 21 of July 2005 21:20, Pavel Machek wrote: > hi! > > > >>I'd like to get this tested under as many configurations as > > >>possible. With this, your hdd should no longer do "yoyo" (spindown, > > >>spinup, spindown) during suspend... > > > > > > > > >It looks like the patch is now in -mm (I use 2.6.13-rc3-mm1). > > >But my disks still yoyo during suspend. What more is needed? Some patch > > >to ide-disk.c ? > > > > I think I've found the problem. > > The attached patch stops the disks from spinning down and up on suspend. > > The patch applies to 2.6.13-rc3-mm1. > > > > Signed-off-by: Michal Schmidt <[EMAIL PROTECTED]> > > Thanks, applied, I'll eventually propagate it. FYI, tested and works (on 2.6.13-rc3). :-) Greets, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll "Alice's Adventures in Wonderland" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Add schedule_timeout_{interruptible,uninterruptible}{,_msecs}() interfaces
Hi, On Sat, 23 Jul 2005, Nishanth Aravamudan wrote: > > Keep the thing as simple as possible and jiffies _are_ simple. Please show > > me the problem, that needs to be fixed. > > I am not sure why jiffies are any simpler than milliseconds. In the > millisecond case, conversion happens in common code and only needs to be > audited once. In the jiffies case, I have to check *every* caller to see > if they are doing stupid math :) Jiffies are the basic time unit for kernel timers, hiding that fact gives users only wrong expectations about them. I don't mind using helper functions, but constant conversion can already happen at compile time and for variable timeouts the user should seriously consider using jiffies directly instead of constantly converting time values. bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.6.13rc3: RLIMIT_RTPRIO broken
On Sat, 2005-07-23 at 13:42 +0200, Andreas Steinmetz wrote: > RLIMIT_RTPRIO is supposed to grant non privileged users the right to use > SCHED_FIFO/SCHED_RR scheduling policies with priorites bounded by the > RLIMIT_RTPRIO value via sched_setscheduler(). This is usually used by > audio users. > > Unfortunately this is broken in 2.6.13rc3 as you can see in the excerpt > from sched_setscheduler below: Please provide the Signed-Off-By line. Also I have cc'ed Matt Mackall, the original author of the patch. This should definitely make it in 2.6.13. Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] sound/core/memalloc.c: fix PROC_FS=n compilation
This patch fixes the following compile error with CONFIG_PROC_FS=n: <-- snip --> ... CC sound/core/memalloc.o sound/core/memalloc.c: In function 'snd_mem_exit': sound/core/memalloc.c:657: error: 'snd_mem_proc' undeclared (first use in this function) sound/core/memalloc.c:657: error: (Each undeclared identifier is reported only once sound/core/memalloc.c:657: error: for each function it appears in.) make[2]: *** [sound/core/memalloc.o] Error 1 <-- snip --> Since snd_mem_proc was needlessly global, I've also made it static. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- linux-2.6.13-rc3-mm1-full/sound/core/memalloc.c.old 2005-07-23 01:25:03.0 +0200 +++ linux-2.6.13-rc3-mm1-full/sound/core/memalloc.c 2005-07-23 01:30:35.0 +0200 @@ -505,13 +505,13 @@ up(_mutex); } +static struct proc_dir_entry *snd_mem_proc; #ifdef CONFIG_PROC_FS /* * proc file interface */ #define SND_MEM_PROC_FILE "driver/snd-page-alloc" -struct proc_dir_entry *snd_mem_proc; static int snd_mem_proc_read(char *page, char **start, off_t off, int count, int *eof, void *data) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] drivers/net/hamradio/: cleanups
On Sun, Jun 26, 2005 at 07:00:13PM -0400, Jeff Garzik wrote: > randy_dunlap wrote: > >On Sun, 26 Jun 2005 18:26:49 -0400 Jeff Garzik wrote: > > > >| Adrian Bunk wrote: > >| > This patch contains the following cleanups: > >| > - dmascc.c: remove the unused global function dmascc_setup > >| > >| Better to use it, then remove it. > > > >than ?? > > Yes. Use it via __setup() or similar. Hi Jeff, I still haven't gotten any answer from you regarding the following question: Can you give me a hint how it should be used? Why doesn't dmascc_init together with the MODULE_PARM(io,...) work in the non-modular case? > Jeff cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add schedule_timeout_{interruptible,uninterruptible}{,_msecs}() interfaces
Hi,
On Sat, 23 Jul 2005, Nishanth Aravamudan wrote:
> set_current_state(TASK_{,UN}INTERRUPTIBLE);
> schedule_timeout(msecs_to_jiffies(some_constant_msecs));
>
> just have an interface that allows
>
> schedule_timeout_msecs_{,un}interruptible(some_constant_msecs);
>
> and push the jiffies conversion to common code?
What's wrong with just:
schedule_timeout_{,un}interruptible(msecs_to_jiffies(some_constant_msecs));
The majority of users use a constant, which can already be converted at
compile tile.
Additionally such an interface also had to return a ms value and instead
of that constant conversion, the user is better off to work with jiffies
directly.
bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] sound drivers select'ing ISAPNP must depend on PNP && ISA
On Tue, Jul 19, 2005 at 10:50:53PM +0200, Bodo Eggert wrote: > On Tue, 19 Jul 2005, Adrian Bunk wrote: > > On Sun, Jul 17, 2005 at 05:07:48PM +0200, Bodo Eggert wrote: > > > > In sound/isa/Kconfig, select ISAPNP and depend on ISAPNP are intermixed, > > > resulting in funny behaviour. (Soundcarts get selectable if other > > > soundcards are selected). > > > > > > This patch changes the "depend on ISAPNP"s to select. > > >... > > > > I like the idea of this patch, but it brings to more drivers to a > > violation of the "if you select something, you have to ensure that the > > dependencies of what you select are fulfilled" rule causing link errors > > with invalid .config's. > > That should be mentioned in kconfig-language.txt. OTOH, the build system > should automatically propagate the dependencies. I asume that should be > easy, except for having the time to implement that. >... There are nontrivial problems: E.g. what should happen if you select option A that depends on (B || C)? There's one opinion that options should be either select'able _or_ user visible. The current policy in the kernel is not 100% dogmatic regarding this issue, but it shouldn't be violated without a good reason. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Giving developers clue how many testers verified certain kernel version
On Sat, 2005-07-23 at 19:05 +1000, Con Kolivas wrote: > Indeed, and the purpose of the benchmark is to quantify something rather than > leave it to subjective feeling. Fortunately if I was to quantify the current > kernel's situation I would say everything is fine. Agreed. Unfortunately everything in userspace is not fine. I think a lot of these interactivity problems are due to X and broken/bloated apps. Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add schedule_timeout_{interruptible,uninterruptible}{,_msecs}() interfaces
On 23.07.2005 [15:29:42 +0200], Roman Zippel wrote: > Hi, > > On Sat, 23 Jul 2005, Arjan van de Ven wrote: > > > jiffies/HZ is the more powerful API. The msec one which also sets > > current to (un)interruptible is the simplified wrapper on top. > > So why do you want to hide it? Make the jiffies based API the primary one > and add some convenience functions, where we BTW could convert already > constants at compile time. We are not hiding anything; we are providing an alternative for those users that would like to request wall-time (human-time) units -- those users do not (or should not, if nothing else) expect any kind of precision from the sleeping path. Thanks, Nish - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Add schedule_timeout_{interruptible,uninterruptible}{,_msecs}() interfaces
On 23.07.2005 [15:04:44 +0200], Roman Zippel wrote: > Hi, > > On Sat, 23 Jul 2005, Arjan van de Ven wrote: > > > > > > What's wrong with using jiffies? > > > > > > > > A lot of the (driver) users want a wallclock based timeout. For that, > > > > miliseconds is a more obvious API with less chance to get the jiffies/HZ > > > > conversion wrong by the driver writer. > > > > > > We have helper functions for that. > > > > I think we just disagree then... I consider this one a helper function > > as well, one with a simpler API that wraps the more complex and powerful > > api. > > How is it more powerful? The next step in introducing such API is that > people start complaining, they don't get ms precision, which of course is > fixed by the next patch, with then results in that the whole timer system > becomes more complex for a few misguided users. Do people complain about not getting jiffy precision? I think the whole idea of discussing precision in this particular sleeping path is ludicrous. Some users of this are requesting up to 100s of millisecond delays! And, please, don't confuse this patch with my other work. The soft-timer rework was an RFC, meaning I was hoping to start a discussion and get some comments. I got comments from you and others, which I greatly appreciate. But, I think you interpret that patch as being a final version, which is ready for mainline. It very explicitly is not. I am intent on dealing with your issues (perhaps moving to usecs...), but this patch has nothing to do with that. It has everything to do with my experience replacing caller after caller of schedule_timeout() and a request from Andrew for a compact interface (the milliseconds were admittedly my idea, but he hasn't said no to that yet :) ). > Keep the thing as simple as possible and jiffies _are_ simple. Please show > me the problem, that needs to be fixed. I am not sure why jiffies are any simpler than milliseconds. In the millisecond case, conversion happens in common code and only needs to be audited once. In the jiffies case, I have to check *every* caller to see if they are doing stupid math :) Thanks, Nish - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Add schedule_timeout_{interruptible,uninterruptible}{,_msecs}() interfaces
On 23.07.2005 [13:55:58 +0200], Roman Zippel wrote:
> Hi,
>
> On Sat, 23 Jul 2005, Arjan van de Ven wrote:
>
> > > What's wrong with using jiffies?
> >
> > A lot of the (driver) users want a wallclock based timeout. For that,
> > miliseconds is a more obvious API with less chance to get the jiffies/HZ
> > conversion wrong by the driver writer.
>
> We have helper functions for that. The point about using jiffies is to
> make it _very_ clear, that the timeout is imprecise and for most users
> this is sufficient.
We do have helper functions for human-time <-> jiffies (I keep adding
new ones :) ). But why not, instead of
set_current_state(TASK_{,UN}INTERRUPTIBLE);
schedule_timeout(msecs_to_jiffies(some_constant_msecs));
just have an interface that allows
schedule_timeout_msecs_{,un}interruptible(some_constant_msecs);
and push the jiffies conversion to common code?
There are some 300 or so users of schedule_timeout() in 2.6.12. I would
say about half are doing something along the lines of
set_current_state(TASK_{,UN}INTERRUPTIBLE);
schedule_timeout(HZ/some_constant);
These would be replaced with
schedule_timeout_msecs_{,un}interruptible(1000/some_constant);
I would *not* be changing the callers that do
set_current_state(TASK_{,UN}INTERRUPTIBLE);
schedule_timeout(some_other_constant);
even though I think most of these are 2.4 remnants that don't need
short, e.g. 1 or 2 timer interrupt, sleeps, but actually can use a 10
or 20 millisecond (HZ=100, 1 or 2 jiffies) sleep.
This emphasizes another advantage of adding these new interfaces, the
delay requested does not change with HZ. Internally it does, certainly,
but the callers don't need to know that :)
Thanks,
Nish
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Add schedule_timeout_{interruptible,uninterruptible}{,_msecs}() interfaces
On 23.07.2005 [12:50:45 +0200], Roman Zippel wrote:
> Hi,
>
> On Fri, 22 Jul 2005, Arjan van de Ven wrote:
>
> > Also I'd rather not add the non-msec ones... either you're raw and use
> > HZ, or you are "cooked" and use the msec variant.. I dont' see the point
> > of adding an "in the middle" one. (Yes this means that several users
> > need to be transformed to msecs but... I consider that progress ;)
>
> What's wrong with using jiffies? It's simple and the current timeout
> system is based on it. Calling it something else doesn't suddenly give you
> more precision.
I agree, and for users that want a certain number of ticks (they are the
minority, in my experience), they can still use schedule_timeout() (so
maybe I should add back in the schedule_timeout_{,un}interruptible()
wrappers?
As far as precision, we *are* talking about a sleeping path, where the
concept of precision is vague at best :) Consider these functions
expressing the completeness of what msleep() and msleep_interruptible()
started, i.e. for the wait-queue case. And to be honest, we are not
changing the semantics of the schedule_timeout() family of functions.
The caller expresses their request in some units, the kenrel then does
what it can to satisfy the request, but is at liberty to be late (or
even early in these two cases).
Thanks,
Nish
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[UPDATE PATCH] Add schedule_timeout_{interruptible,uninterruptible}_msecs() interfaces
On 23.07.2005 [12:30:00 +1000], Andrew Morton wrote:
> Nishanth Aravamudan <[EMAIL PROTECTED]> wrote:
> >
> >
> > +/*
> > + * schedule_timeout_msecs - sleep until timeout
> > + * @timeout_msecs: timeout value in milliseconds
> > + *
> > + * A human-time (but otherwise identical) alternative to
> > + * schedule_timeout() The state, therefore, *does* need to be set before
> > + * calling this function, but this function should *never* be called
> > + * directly. Use the nice wrappers, schedule_{interruptible,
> > + * uninterruptible}_timeout_msecs().
> > + *
> > + * See the comment for schedule_timeout() for details.
> > + */
> > +inline unsigned int __sched schedule_timeout_msecs(unsigned int
> > timeout_msecs)
> > +{
>
> Making this inline will add more kernel text.Can't we uninline it?
Uninlined in the latest version (see below).
> I'm surprised that this function is not implemented as a call to the
> existing schedule_timeout()?
Well, I was considering doing that, but I tried to make this new
interface a little more sane. I don't think we need to worry about
signedness of the parameter any more (and thus we don't need to consider
returning a negative value). Calling schedule_timeout() underneath
schedule_timeout_msecs() will require us to do those conditional checks;
I guess this isn't criticial in a sleeping path.
Also, I would need to make some modifications (not critical, really), so
that MAX_SCHEDULE_TIMEOUT_MSECS would map 1:1 to MAX_SCHEDULE_TIMEOUT
(which is in jiffies).
But I'm happy to change this, also done below -- does that map better to
what you were thinking?
> > + init_timer();
> > + timer.expires = expire_jifs;
> > + timer.data = (unsigned long) current;
> > + timer.function = process_timeout;
>
> hm, if we add the needed typecast to TIMER_INITIALIZER() the above could be
>
> timer = TIMER_INITIALIZER(process_timeout, expire_jifs,
> (unsigned long)current);
Done as well below.
Thanks,
Nish
Description: Add millisecond wrapper for schedule_timeout(),
schedule_timeout_msecs(). Add wrappers for interruptible/uninterruptible
schedule_timeout_msecs() callers.
Signed-off-by: Nishanth Aravamudan <[EMAIL PROTECTED]>
---
include/linux/sched.h |7
kernel/timer.c| 75 ++
2 files changed, 81 insertions(+), 1 deletion(-)
diff -urpN 2.6.13-rc3/include/linux/sched.h
2.6.13-rc3-new_interfaces/include/linux/sched.h
--- 2.6.13-rc3/include/linux/sched.h2005-07-13 15:52:14.0 -0700
+++ 2.6.13-rc3-new_interfaces/include/linux/sched.h 2005-07-22
18:06:36.0 -0700
@@ -181,8 +181,13 @@ extern void scheduler_tick(void);
/* Is this address in the __sched functions? */
extern int in_sched_functions(unsigned long addr);
-#defineMAX_SCHEDULE_TIMEOUTLONG_MAX
+#defineMAX_SCHEDULE_TIMEOUTLONG_MAX
+#defineMAX_SCHEDULE_TIMEOUT_MSECS UINT_MAX
extern signed long FASTCALL(schedule_timeout(signed long timeout));
+extern unsigned int schedule_timeout_msecs_interruptible
+ (unsigned int timeout_msecs);
+extern unsigned int schedule_timeout_msecs_uninterruptible
+ (unsigned int timeout_msecs);
asmlinkage void schedule(void);
struct namespace;
diff -urpN 2.6.13-rc3/kernel/timer.c 2.6.13-rc3-new_interfaces/kernel/timer.c
--- 2.6.13-rc3/kernel/timer.c 2005-07-13 15:52:14.0 -0700
+++ 2.6.13-rc3-new_interfaces/kernel/timer.c2005-07-23 09:20:51.0
-0700
@@ -1153,6 +1153,81 @@ fastcall signed long __sched schedule_ti
EXPORT_SYMBOL(schedule_timeout);
+/*
+ * schedule_timeout_msecs - sleep until timeout
+ * @timeout_msecs: timeout value in milliseconds
+ *
+ * A human-time (but otherwise identical) alternative to
+ * schedule_timeout() The state, therefore, *does* need to be set before
+ * calling this function, but this function should *never* be called
+ * directly. Use the nice wrappers, schedule_{interruptible,
+ * uninterruptible}_timeout_msecs().
+ *
+ * See the comment for schedule_timeout() for details.
+ */
+unsigned int __sched schedule_timeout_msecs(unsigned int timeout_msecs)
+{
+ unsigned long expire_jifs;
+
+ if (timeout_msecs == MAX_SCHEDULE_TIMEOUT_MSECS) {
+ expire_jifs = MAX_SCHEDULE_TIMEOUT;
+ } else {
+ /*
+* msecs_to_jiffies() is a unit conversion, which truncates
+* (rounds down), so we need to add 1.
+*/
+ expire_jifs = msecs_to_jiffies(timeout_msecs) + 1;
+ }
+
+ expire_jifs = schedule_timeout(expire_jifs);
+
+ /*
+* don't need to add 1 here, even though there is truncation,
+* because we will add 1 if/when the value is sent back in
+*/
+ return jiffies_to_msecs(expire_jifs);
+}
+
+/**
+ * schedule_timeout_msecs_interruptible - sleep
Re: kernel oops with x64_86 crossing 4Gb boundary
Francois Pepin <[EMAIL PROTECTED]> writes: > Hi, > > I am getting pseudo-random kernel oops on my Opteron box (Tyan Thunder > K8W) with 4Gb RAM. I am running RedHad FC3 with kernel > 2.6.11-1.35_FC3smp. > > It runs well with default BIOS settings, but only 3.5Gb RAM are visible. > Using the "Software Memory Hole" option in the BIOS (version 3.02) > remaps the last 2Gb to 4-6Gb. This causes kernel oops with various > applications, generally killing them. > > I can reproduce it by loading lots of data into R (which caused the oops > below). Various other applications have caused it Software memory hole is broken in the BIOS. Don't use it. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: HELP: NFS mount hangs when attempting to copy file
on den 20.07.2005 Klokka 18:56 (-0400) skreiv Timothy Miller: > My research suggests that NFS client mounting is kernel-based, so > that's why I'm posting here. If there's a more appropriate list to > post to, I apologise, but I am not a list member. > > I'm having a bit of a problem doing simple copies over an NFS mount. > The client is running Linux (2.6.11), and the server is running > Solaris (5.8). > > When I first boot the client, getting NFS directory listings works > just fine. But the instant I try to copy a file (to or from), the NFS > mount hangs. While I can still do other network activity (even rlogin > to the server), any NFS access I try to do after that point hangs, > including directory listings. > > I have had this same client and server working flawlessly for years. > The only change is that the client is now on a VPN (Watchguard SOHO > box). However, I have a Sun machine on the same VPN network segment, > and it can copy files with no problem, so it's not the router/SOHO > that's blocking anything. (NIS and DNS also work just fine for both > machines.) I beg to disagree. A lot of these VPN solutions are unfriendly to MTU path discovery over UDP. Sun uses TCP by default when mounting NFS partitions. Have you tried this on your Linux box? Cheers, Trond > Also, after it hangs like that, I cannot reboot the machine normally. > When attempting to unmount the network filesystems, the shutdown > hangs, and I have to hard-reset the machine. > > Is there anyone who could please help me to debug this problem? As > far as I know, I have NFS setup properly, but I don't know enough > about it to know what options I might try. I don't even care if the > fix degrades performance; I just want it to not hang. > > Does anyone have any ideas? > > Thanks very much in advance! > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message 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: CheckFS: Checkpoints and Block Level Incremental Backup (BLIB)
On Sat, Jul 23, 2005 at 11:30:07AM +0530, Amit S. Kale wrote: > > We started it from 2.6.7 last year and then it was sitting idle for several > months for lack of resources. We'll go back to that version and generate a > diff that's easier to read. > > Yes, changing the name has made the task of rebasing wrt. changing kernels > lot > difficult. Our original intention was to make testing easier by keeping ext3 > and checkfs filesystems in the same kernel. Had we continued it at that > point, we would have posted differences wrt. ext3 sources themselves. There > was compelling reason to change the name. One easier way of doing development, particularly for people doing filesystem work, is to compile the kernel with the test filesystem code using user-mode linux (UML) architecture. This significantly shortens your edit-compile-debug cycle time, and it makes it easier to run your filesystem code under a debugger. That way you also don't have to worry about your filesystem changes toasting your system, either. This technique doesn't work all that well for people doing architecture-specific code or for device drivers, but for filesystems, it's ideal. Regards, - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add schedule_timeout_{interruptible,uninterruptible}{,_msecs}() interfaces
Hi, On Sat, 23 Jul 2005, Arjan van de Ven wrote: > > > jiffies/HZ is the more powerful API. The msec one which also sets > > > current to (un)interruptible is the simplified wrapper on top. > > > > So why do you want to hide it? > > I don't want to hide it at all. I want to provide a simpler variant for > it for the cases where a simpler variant is enough. Then I don't understand your initial comment and I don't understand the point in adding a ms variant of this interface. If someone does care about the return value, he is better off to convert the initial value into jiffies and continue with that. > It really is a > helper to take some common task and get that closer to what the > programmer wants (wallclock time delay) And that's not what he gets... bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: oz6812, yenta_socket and madwifi
hi
since i'm the one that put that code there in the first place i guess
i have to comment on it :)
the attached patch should also fix your problem. and it cleans up the
magic numbers a bit.
rgds
-daniel
-
[PATCH] disable read prefetch/write burst on old O2Micro bridges
older O2Micro bridges have problems with both read prefetch and write burst
depending on the combination of the chipset, bridge, cardbus card. safest
is to disable read prefetch and write burst on those old bridges.
Signed-off-by: Daniel Ritz <[EMAIL PROTECTED]>
diff --git a/drivers/pcmcia/o2micro.h b/drivers/pcmcia/o2micro.h
--- a/drivers/pcmcia/o2micro.h
+++ b/drivers/pcmcia/o2micro.h
@@ -120,11 +120,16 @@
#define O2_MODE_E_LED_OUT 0x08
#define O2_MODE_E_SKTA_ACTV 0x10
+#define O2_RESERVED1 0x94
+#define O2_RESERVED2 0xD4
+#define O2_RES_READ_PREFETCH 0x02
+#define O2_RES_WRITE_BURST 0x08
+
static int o2micro_override(struct yenta_socket *socket)
{
/*
-* 'reserved' register at 0x94/D4. chaning it to 0xCA (8 bit) enables
-* read prefetching which for example makes the RME Hammerfall DSP
+* 'reserved' register at 0x94/D4. allows setting read prefetch and
write
+* bursting. read prefetching for example makes the RME Hammerfall DSP
* working. for some bridges it is at 0x94, for others at 0xD4. it's
* ok to write to both registers on all O2 bridges.
* from Eric Still, 02Micro.
@@ -132,20 +137,35 @@ static int o2micro_override(struct yenta
u8 a, b;
if (PCI_FUNC(socket->dev->devfn) == 0) {
- a = config_readb(socket, 0x94);
- b = config_readb(socket, 0xD4);
+ a = config_readb(socket, O2_RESERVED1);
+ b = config_readb(socket, O2_RESERVED2);
printk(KERN_INFO "Yenta O2: res at 0x94/0xD4: %02x/%02x\n", a,
b);
switch (socket->dev->device) {
+ /*
+* older bridges have problems with both read prefetch and write
+* bursting depending on the combination of the chipset, bridge
+* and the cardbus card. so disable them to be on the safe side.
+*/
+ case PCI_DEVICE_ID_O2_6729:
+ case PCI_DEVICE_ID_O2_6730:
+ case PCI_DEVICE_ID_O2_6812:
case PCI_DEVICE_ID_O2_6832:
- printk(KERN_INFO "Yenta O2: old bridge, not enabling
read prefetch / write burst\n");
+ case PCI_DEVICE_ID_O2_6836:
+ printk(KERN_INFO "Yenta O2: old bridge, disabling read
prefetch/write burst\n");
+ config_writeb(socket, O2_RESERVED1,
+ a & ~(O2_RES_READ_PREFETCH |
O2_RES_READ_PREFETCH));
+ config_writeb(socket, O2_RESERVED2,
+ b & ~(O2_RES_READ_PREFETCH |
O2_RES_READ_PREFETCH));
break;
default:
printk(KERN_INFO "Yenta O2: enabling read
prefetch/write burst\n");
- config_writeb(socket, 0x94, a | 0x0a);
- config_writeb(socket, 0xD4, b | 0x0a);
+ config_writeb(socket, O2_RESERVED1,
+ a | O2_RES_READ_PREFETCH |
O2_RES_READ_PREFETCH);
+ config_writeb(socket, O2_RESERVED2,
+ b | O2_RES_READ_PREFETCH |
O2_RES_READ_PREFETCH);
}
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Mouse Freezes in Xorg on ASUS P4C800 Deluxe
On 7/23/05, Jesper Juhl <[EMAIL PROTECTED]> wrote: > On 7/23/05, cengizkirli <[EMAIL PROTECTED]> wrote: > > distro: Debian Unstable > > kernels tested with: 2.6.13-rc3, 2.6.13-rc3-git5, 2.6.13-rc3-mm1 > > compiler used: Debian gcc-4.0.1-2 > > Xorg: Debian xorg-6.8.2-4 > > ASUS P4C800 Deluxe BIOS: 1019 (2005-11-08) > > > > with or wihout ACPI enabled (acpi=off or not) the /dev/input/mice USB > > mouse freezes after not being used for some time and can only be > > awakened by switching to the text-console and back. > > > What's the last kernel it works OK with? none I can remember as I did not run linux that much on this box prior to last winter. this also happened before the Debian Unstable Xorg switch and therefore with XFree86. > Why do you suspect this to be a kernel problem and not a X.org problem? because they told me in the Xorg IRC channel to believe in a kernel problem. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ckrm-tech] Re: 2.6.13-rc3-mm1 (ckrm)
> > if CKRM is just extensions, I think it should be an external patch. > > if it provides a path towards unifying the many disparate RM mechanisms > > already in the kernel, great! > > OK, so if it provides a path towards unifying these, what should happen > to the old interfaces when they conflict with those offered by CKRM? I don't think the name matters, as long as the RM code is simplified/unified. that is, the only difference at first would be a change in name - same behavior. > For instance, I'm considering how a per-class (re)nice setting would > work. What should happen when the user (re)nices a process to a > different value than the nice of the process' class? Should CKRM: it has to behave as it does now, unless the admin has imposed some class structure other than the normal POSIX one (ie, nice pertains only to a process and is inherited by future children.) > a) disable the old interface by > i) removing it > ii) return an error when CKRM is active > iii) return an error when CKRM has specified a nice value for the > process via membership in a class > iv) return an error when the (re)nice value is inconsistent with the > nice value assigned to the class some interfaces must remain (renice), and if their behavior is implemented via CKRM, it must, by default, act as before. other interfaces (say overcommit_ratio) probably don't need to remain. > b) trust the user, ignore the class nice value, and allow the new nice > value users can only nice up, and that policy needs to remain, obviously. you appear to be asking what happens when the scope of the old mechanism conflicts with the scope determined by admin-set CKRM classes. I'd say that nicing a single process should change the nice of the whole class that the process is in, if any. otherwise, it acts to rip that process out of the class, which is probably even less 'least surprise'. > This sort of question would probably come up for any other CKRM > "embraced-and-extended" tunables. Should they use the answer to this > one, or would it go on a case-by-case basis? I don't see that CKRM should play by rules different from other kernel improvements - preserve standard/former behavior when that behavior is documented (certainly nice is). in the absense of admin-set classes, nice would behave the same. all CKRM is doing here is providing a broader framework to hang the tunables on. it should be able to express all existing tunables in scope. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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: Opaque kernel bug in work with bzip2(?)
On Sat, 23 Jul 2005, [koi8-r] ? ? wrote: > The letter itself is in an attached file. Run memtest, it sounds like you have failing hardware.
Re: fix suspend/resume irq request free for yenta..
On Sat, 23 Jul 2005, Russell King wrote: > On Sat, Jul 23, 2005 at 02:29:24AM +0200, Pavel Machek wrote: > > > Is it necessary to do free_irq for suspend? Shouldn't disable_irq > > > be enough? > > > > Due to recent changes in ACPI, yes, it is neccessary. > > What if some other driver is sharing the IRQ, and requires IRQs to be > enabled for the resume to complete? This certainly is the case on many laptops. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Mouse Freezes in Xorg on ASUS P4C800 Deluxe
On 7/23/05, cengizkirli <[EMAIL PROTECTED]> wrote: > distro: Debian Unstable > kernels tested with: 2.6.13-rc3, 2.6.13-rc3-git5, 2.6.13-rc3-mm1 > compiler used: Debian gcc-4.0.1-2 > Xorg: Debian xorg-6.8.2-4 > ASUS P4C800 Deluxe BIOS: 1019 (2005-11-08) > > with or wihout ACPI enabled (acpi=off or not) the /dev/input/mice USB > mouse freezes after not being used for some time and can only be > awakened by switching to the text-console and back. > What's the last kernel it works OK with? Why do you suspect this to be a kernel problem and not a X.org problem? -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.13-rc3a] i386: inline restore_fpu
Andrew Morton <[EMAIL PROTECTED]> writes: > > We do have the `used_math' optimisation in there which attempts to avoid > doing the FP save/restore if the app isn't actually using math. But > there's code in glibc startup which always does a > bit of float, so that optimisation is always defeated. There was some > discussion about periodically setting tasks back into !used_math state to > try to restore the optimisation for tasks which only do a little bit of FP, > but nothing actually got done. Actually we reset the flag on every context switch, so that works just fine. But I was considering to do it less often so that we switch the FP state non lazily for FP intensive processes and avoid the overhead of all these exceptions. -Andi P.S.: Original profile data looks a bit fishy. Normally avoiding a single function call should not make tht much difference unless you call it in a inner loop, but that is not the case here. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 optimization
christos gentsis skrev: so if i want to play with and see what happens i have to change it manually in each make file... good i may create a kernel like that to see what will happens (just for test) ;) thanks Chris Just edit the top level Makefile and add your custom CFLAGS there. But you are risking the stability of your system and don't expect it to be faster. -- Simon Strandman <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2/2] Touchscreen support for sharp sl-5500
Hi!
> > This adds support for touchscreen on Sharp Zaurus sl-5500. Vojtech,
> > please apply,
>
> I have couple more commnets...
Sorry, I never really worked with kthreads. Applied all those,
> > +static int ucb1x00_ts_open(struct input_dev *idev)
> > +{
> > + struct ucb1x00_ts *ts = (struct ucb1x00_ts *)idev;
> > + int ret = 0;
> > + struct task_struct *task;
> > +
> > + if (ts->rtask)
> > + panic("ucb1x00: rtask running?");
> > +
>
> Do you really need to panic here???
Does BUG_ON() seem better :-). We could also just return failure here,
but I do not see how it could happen => I guess I'd better catch it
with BUG().
Here's what I did, updated patch will follow.
Pavel
diff --git a/drivers/input/touchscreen/collie_ts.c
b/drivers/input/touchscreen/collie_ts.c
--- a/drivers/input/touchscreen/collie_ts.c
+++ b/drivers/input/touchscreen/collie_ts.c
@@ -41,7 +41,6 @@ struct ucb1x00_ts {
struct ucb1x00 *ucb;
struct semaphoreirq_wait;
- struct completion init_exit;
struct task_struct *rtask;
u16 x_res;
u16 y_res;
@@ -160,7 +159,6 @@ static int ucb1x00_thread(void *_ts)
int valid;
ts->rtask = tsk;
- allow_signal(SIGKILL);
/*
* We run as a real-time thread. However, thus far
@@ -169,10 +167,7 @@ static int ucb1x00_thread(void *_ts)
tsk->policy = SCHED_FIFO;
tsk->rt_priority = 1;
- complete(>init_exit);
-
valid = 0;
-
for (;;) {
unsigned int x, y, p, val;
@@ -237,12 +232,12 @@ static int ucb1x00_thread(void *_ts)
msleep_interruptible(10);
}
- if (signal_pending(tsk))
+ if (kthread_should_stop())
break;
}
ts->rtask = NULL;
- complete_and_exit(>init_exit, 0);
+ return 0;
}
/*
@@ -262,8 +257,7 @@ static int ucb1x00_ts_open(struct input_
int ret = 0;
struct task_struct *task;
- if (ts->rtask)
- panic("ucb1x00: rtask running?");
+ BUG_ON(ts->rtask);
sema_init(>irq_wait, 0);
ret = ucb1x00_hook_irq(ts->ucb, UCB_IRQ_TSPX, ucb1x00_ts_irq, ts);
@@ -279,10 +273,8 @@ static int ucb1x00_ts_open(struct input_
ts->y_res = ucb1x00_ts_read_yres(ts);
ucb1x00_adc_disable(ts->ucb);
- init_completion(>init_exit);
task = kthread_run(ucb1x00_thread, ts, "ktsd");
if (!IS_ERR(task)) {
- wait_for_completion(>init_exit);
ret = 0;
} else {
ucb1x00_free_irq(ts->ucb, UCB_IRQ_TSPX, ts);
@@ -300,10 +292,8 @@ static void ucb1x00_ts_close(struct inpu
{
struct ucb1x00_ts *ts = (struct ucb1x00_ts *)idev;
- if (ts->rtask) {
- send_sig(SIGKILL, ts->rtask, 1);
- wait_for_completion(>init_exit);
- }
+ if (ts->rtask)
+ kthread_stop(ts->rtask);
ucb1x00_enable(ts->ucb);
ucb1x00_free_irq(ts->ucb, UCB_IRQ_TSPX, ts);
--
teflon -- maybe it is a trademark, but it should not be.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Add schedule_timeout_{interruptible,uninterruptible}{,_msecs}() interfaces
On Sat, 2005-07-23 at 15:29 +0200, Roman Zippel wrote: > Hi, > > On Sat, 23 Jul 2005, Arjan van de Ven wrote: > > > jiffies/HZ is the more powerful API. The msec one which also sets > > current to (un)interruptible is the simplified wrapper on top. > > So why do you want to hide it? I don't want to hide it at all. I want to provide a simpler variant for it for the cases where a simpler variant is enough. It really is a helper to take some common task and get that closer to what the programmer wants (wallclock time delay) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Add schedule_timeout_{interruptible,uninterruptible}{,_msecs}() interfaces
Hi, On Sat, 23 Jul 2005, Arjan van de Ven wrote: > jiffies/HZ is the more powerful API. The msec one which also sets > current to (un)interruptible is the simplified wrapper on top. So why do you want to hide it? Make the jiffies based API the primary one and add some convenience functions, where we BTW could convert already constants at compile time. bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2/2] Touchscreen support for sharp sl-5500
This adds support for touchscreen on Sharp Zaurus sl-5500. Please
apply,
Pavel
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
diff --git a/drivers/input/touchscreen/Kconfig
b/drivers/input/touchscreen/Kconfig
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -36,6 +36,15 @@ config TOUCHSCREEN_CORGI
To compile this driver as a module, choose M here: the
module will be called ads7846_ts.
+config TOUCHSCREEN_COLLIE
+ tristate "Collie touchscreen (for Sharp SL-5500)"
+ depends on MCP_UCB1200
+ help
+ Say Y here to enable the driver for the touchscreen on the
+ Sharp SL-5500 series of PDAs.
+
+ If unsure, say N.
+
config TOUCHSCREEN_GUNZE
tristate "Gunze AHL-51S touchscreen"
select SERIO
diff --git a/drivers/input/touchscreen/Makefile
b/drivers/input/touchscreen/Makefile
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -6,6 +6,7 @@
obj-$(CONFIG_TOUCHSCREEN_BITSY)+= h3600_ts_input.o
obj-$(CONFIG_TOUCHSCREEN_CORGI)+= corgi_ts.o
+obj-$(CONFIG_TOUCHSCREEN_COLLIE)+= collie_ts.o
obj-$(CONFIG_TOUCHSCREEN_GUNZE)+= gunze.o
obj-$(CONFIG_TOUCHSCREEN_ELO) += elo.o
obj-$(CONFIG_TOUCHSCREEN_MTOUCH) += mtouch.o
diff --git a/drivers/input/touchscreen/collie_ts.c
b/drivers/input/touchscreen/collie_ts.c
new file mode 100644
--- /dev/null
+++ b/drivers/input/touchscreen/collie_ts.c
@@ -0,0 +1,367 @@
+/*
+ * linux/drivers/input/touchscreen/collie_ts.c
+ *
+ * Copyright (C) 2001 Russell King, All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 21-Jan-2002 <[EMAIL PROTECTED]> :
+ *
+ * Added support for synchronous A/D mode. This mode is useful to
+ * avoid noise induced in the touchpanel by the LCD, provided that
+ * the UCB1x00 has a valid LCD sync signal routed to its ADCSYNC pin.
+ * It is important to note that the signal connected to the ADCSYNC
+ * pin should provide pulses even when the LCD is blanked, otherwise
+ * a pen touch needed to unblank the LCD will never be read.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+
+
+struct ucb1x00_ts {
+ struct input_devidev;
+ struct ucb1x00 *ucb;
+
+ struct semaphoreirq_wait;
+ struct task_struct *rtask;
+ u16 x_res;
+ u16 y_res;
+
+ int restart:1;
+ int adcsync:1;
+};
+
+/*
+ * Switch to interrupt mode.
+ */
+static inline void ucb1x00_ts_mode_int(struct ucb1x00_ts *ts)
+{
+ int val = UCB_TS_CR_TSMX_POW | UCB_TS_CR_TSPX_POW |
+ UCB_TS_CR_TSMY_GND | UCB_TS_CR_TSPY_GND |
+ UCB_TS_CR_MODE_INT;
+ if (ts->ucb->id == UCB_ID_1400_BUGGY)
+ val &= ~(UCB_TS_CR_TSMX_POW | UCB_TS_CR_TSPX_POW);
+ ucb1x00_reg_write(ts->ucb, UCB_TS_CR, val);
+}
+
+/*
+ * Switch to pressure mode, and read pressure. We don't need to wait
+ * here, since both plates are being driven.
+ */
+static inline unsigned int ucb1x00_ts_read_pressure(struct ucb1x00_ts *ts)
+{
+ ucb1x00_reg_write(ts->ucb, UCB_TS_CR,
+ UCB_TS_CR_TSMX_POW | UCB_TS_CR_TSPX_POW |
+ UCB_TS_CR_TSMY_GND | UCB_TS_CR_TSPY_GND |
+ UCB_TS_CR_MODE_PRES | UCB_TS_CR_BIAS_ENA);
+
+ return ucb1x00_adc_read(ts->ucb, UCB_ADC_INP_TSPY, ts->adcsync);
+}
+
+/*
+ * Switch to X position mode and measure Y plate. We switch the plate
+ * configuration in pressure mode, then switch to position mode. This
+ * gives a faster response time. Even so, we need to wait about 55us
+ * for things to stabilise.
+ */
+static inline unsigned int ucb1x00_ts_read_xpos(struct ucb1x00_ts *ts)
+{
+ ucb1x00_reg_write(ts->ucb, UCB_TS_CR,
+ UCB_TS_CR_TSMX_GND | UCB_TS_CR_TSPX_POW |
+ UCB_TS_CR_MODE_PRES | UCB_TS_CR_BIAS_ENA);
+ ucb1x00_reg_write(ts->ucb, UCB_TS_CR,
+ UCB_TS_CR_TSMX_GND | UCB_TS_CR_TSPX_POW |
+ UCB_TS_CR_MODE_PRES | UCB_TS_CR_BIAS_ENA);
+ ucb1x00_reg_write(ts->ucb, UCB_TS_CR,
+ UCB_TS_CR_TSMX_GND | UCB_TS_CR_TSPX_POW |
+ UCB_TS_CR_MODE_POS | UCB_TS_CR_BIAS_ENA);
+
+ udelay(55);
+
+ return ucb1x00_adc_read(ts->ucb, UCB_ADC_INP_TSPY, ts->adcsync);
+}
+
+/*
+ * Switch to Y position mode and measure X plate. We switch the plate
+ * configuration in pressure mode, then switch to position mode. This
+ * gives a faster response time. Even so, we need to wait about 55us
+
Re: [PATCH] Add schedule_timeout_{interruptible,uninterruptible}{,_msecs}() interfaces
On Sat, 2005-07-23 at 15:04 +0200, Roman Zippel wrote: > Hi, > > On Sat, 23 Jul 2005, Arjan van de Ven wrote: > > > > > > What's wrong with using jiffies? > > > > > > > > A lot of the (driver) users want a wallclock based timeout. For that, > > > > miliseconds is a more obvious API with less chance to get the jiffies/HZ > > > > conversion wrong by the driver writer. > > > > > > We have helper functions for that. > > > > I think we just disagree then... I consider this one a helper function > > as well, one with a simpler API that wraps the more complex and powerful > > api. > > How is it more powerful? jiffies/HZ is the more powerful API. The msec one which also sets current to (un)interruptible is the simplified wrapper on top. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Add schedule_timeout_{interruptible,uninterruptible}{,_msecs}() interfaces
Hi, On Sat, 23 Jul 2005, Arjan van de Ven wrote: > > > > What's wrong with using jiffies? > > > > > > A lot of the (driver) users want a wallclock based timeout. For that, > > > miliseconds is a more obvious API with less chance to get the jiffies/HZ > > > conversion wrong by the driver writer. > > > > We have helper functions for that. > > I think we just disagree then... I consider this one a helper function > as well, one with a simpler API that wraps the more complex and powerful > api. How is it more powerful? The next step in introducing such API is that people start complaining, they don't get ms precision, which of course is fixed by the next patch, with then results in that the whole timer system becomes more complex for a few misguided users. Keep the thing as simple as possible and jiffies _are_ simple. Please show me the problem, that needs to be fixed. bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add schedule_timeout_{interruptible,uninterruptible}{,_msecs}() interfaces
On Sat, 2005-07-23 at 13:55 +0200, Roman Zippel wrote: > Hi, > > On Sat, 23 Jul 2005, Arjan van de Ven wrote: > > > > What's wrong with using jiffies? > > > > A lot of the (driver) users want a wallclock based timeout. For that, > > miliseconds is a more obvious API with less chance to get the jiffies/HZ > > conversion wrong by the driver writer. > > We have helper functions for that. I think we just disagree then... I consider this one a helper function as well, one with a simpler API that wraps the more complex and powerful api. Sure sleeps are imprecise. All sleeps are even mdelay() (due to preemption). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.12.3] dyntick 050610-1 breaks makes S3 suspend
On Saturday 23 July 2005 14:35, Jan De Luyck wrote: > Hello, > > I recently tried out dyntick 050610-1 against 2.6.12.3, works great, it > actually makes a noticeable difference on my laptop's battery life. I don't > have hard numbers, lets just say that instead of the usual ~3 hours i get > out of it, i was ~4 before it started nagging, usual use pattern at work. > > The only gripe I have with it that it stops S3 from working. If the patch > is compiled in the kernel, it makes S3 suspend correctly, but resuming goes > into a solid hang (nothing get's it back alive, have to keep the > powerbutton for ~5 secs to shutdown the system) > > Anything I could test? The logs don't give anything useful.. I reported this some time ago [1], but there's no sulution so far... [1] http://groups.google.com/groups?selm=4b4NI-7mJ-9%40gated-at.bofh.it -- Christian pgpyBhP39QXNl.pgp Description: PGP signature
[2.6.12.3] dyntick 050610-1 breaks makes S3 suspend
Hello, I recently tried out dyntick 050610-1 against 2.6.12.3, works great, it actually makes a noticeable difference on my laptop's battery life. I don't have hard numbers, lets just say that instead of the usual ~3 hours i get out of it, i was ~4 before it started nagging, usual use pattern at work. The only gripe I have with it that it stops S3 from working. If the patch is compiled in the kernel, it makes S3 suspend correctly, but resuming goes into a solid hang (nothing get's it back alive, have to keep the powerbutton for ~5 secs to shutdown the system) Anything I could test? The logs don't give anything useful.. Thanks, Jan -- Yow! I'm having a quadrophonic sensation of two winos alone in a steel mill! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 cached memory
On Saturday 23 July 2005 00:43, John Pearson wrote:
> Wouldn't having (practically) all your memory used for cache slow down
> starting a new program? First it would have to free up that space, and then
> put stuff in that space, taking potentially twice as long. I think there
> should be a system call for freeing cached memory, for those that do want to
> do it.
I think this one is good enough:
#include
int main() {
void *p;
unsigned size = 1<<20;
unsigned long total=0;
while(size) {
p = malloc(size);
if(!p) size>>=1;
else {
memset(p, 0x77, size);
total+=size;
printf("Allocated %9u bytes, %12lu total\n",size,total);
}
}
return 0;
}
You may want to adapt it so that it takes an argument now many megabytes
to eat before it dies.
--
vda
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: HPT370 errors under 2.6.13-rc3-mm1
On Sat, Jul 23, 2005 at 11:50:43PM +1200, mdew wrote: > looks like 2.6.12 does the same sort of thing.. > As a data-point, my dual HPT374 controllers are fine with 2.6.13-rc3-mm1. One onboard, one in a pci-slot in an Epox 4PCA3+ (socket 478, i875 chipset) motherboard. Linux adsl-gate 2.6.13-rc3-mm1 #1 SMP Sat Jul 16 07:13:24 CEST 2005 i686 GNU/Linux Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx HPT374: IDE controller at PCI slot :02:00.0 ACPI: PCI Interrupt :02:00.0[A] -> GSI 16 (level, low) -> IRQ 16 HPT374: chipset revision 7 HPT374: 100% native mode on irq 16 HPT37X: using 33MHz PCI clock ide2: BM-DMA at 0x9400-0x9407, BIOS settings: hde:DMA, hdf:pio HPT37X: using 33MHz PCI clock ide3: BM-DMA at 0x9408-0x940f, BIOS settings: hdg:DMA, hdh:pio ACPI: PCI Interrupt :02:00.1[A] -> GSI 16 (level, low) -> IRQ 16 HPT37X: using 33MHz PCI clock ide4: BM-DMA at 0x9900-0x9907, BIOS settings: hdi:DMA, hdj:pio HPT37X: using 33MHz PCI clock ide5: BM-DMA at 0x9908-0x990f, BIOS settings: hdk:DMA, hdl:pio Probing IDE interface ide2... hde: WDC WD2000JB-00FUA0, ATA DISK drive ide2 at 0x9000-0x9007,0x9102 on irq 16 Probing IDE interface ide3... hdg: WDC WD2500JB-00FUA0, ATA DISK drive ide3 at 0x9200-0x9207,0x9302 on irq 16 Probing IDE interface ide4... hdi: WDC WD2000BB-00DAA1, ATA DISK drive ide4 at 0x9500-0x9507,0x9602 on irq 16 Probing IDE interface ide5... hdk: ST3300831A, ATA DISK drive ide5 at 0x9700-0x9707,0x9802 on irq 16 HPT374: IDE controller at PCI slot :02:05.0 ACPI: PCI Interrupt :02:05.0[A] -> GSI 21 (level, low) -> IRQ 21 HPT374: chipset revision 7 HPT374: 100% native mode on irq 21 HPT37X: using 33MHz PCI clock ide6: BM-DMA at 0x9f00-0x9f07, BIOS settings: hdm:pio, hdn:DMA HPT37X: using 33MHz PCI clock ide7: BM-DMA at 0x9f08-0x9f0f, BIOS settings: hdo:pio, hdp:DMA ACPI: PCI Interrupt :02:05.1[A] -> GSI 21 (level, low) -> IRQ 21 HPT37X: using 33MHz PCI clock ide8: BM-DMA at 0xa400-0xa407, BIOS settings: hdq:DMA, hdr:pio HPT37X: using 33MHz PCI clock ide9: BM-DMA at 0xa408-0xa40f, BIOS settings: hds:pio, hdt:DMA Probing IDE interface ide6... hdn: Maxtor 4A300J0, ATA DISK drive ide6 at 0x9b00-0x9b07,0x9c02 on irq 21 Probing IDE interface ide7... hdp: Maxtor 6Y200P0, ATA DISK drive ide7 at 0x9d00-0x9d07,0x9e02 on irq 21 Probing IDE interface ide8... hdq: WDC WD2500JB-00FUA0, ATA DISK drive ide8 at 0xa000-0xa007,0xa102 on irq 21 Probing IDE interface ide9... hdt: Maxtor 4A300J0, ATA DISK drive ide9 at 0xa200-0xa207,0xa302 on irq 21 hda: max request size: 1024KiB hda: 241254720 sectors (123522 MB) w/7965KiB Cache, CHS=16383/255/63, UDMA(100) hda: cache flushes supported hda: hda1 hda2 hdc: max request size: 1024KiB hdc: 241254720 sectors (123522 MB) w/7965KiB Cache, CHS=16383/255/63, UDMA(100) hdc: cache flushes supported hdc: hdc1 hdc2 hde: max request size: 1024KiB hde: 390721968 sectors (200049 MB) w/8192KiB Cache, CHS=24321/255/63, UDMA(33) hde: cache flushes supported hde: hde1 hdg: max request size: 1024KiB hdg: 488397168 sectors (250059 MB) w/8192KiB Cache, CHS=30401/255/63, UDMA(100) hdg: cache flushes supported hdg: hdg1 hdi: max request size: 1024KiB hdi: 390721968 sectors (200049 MB) w/2048KiB Cache, CHS=24321/255/63, UDMA(100) hdi: cache flushes supported hdi: hdi1 hdk: max request size: 1024KiB hdk: 586072368 sectors (300069 MB) w/8192KiB Cache, CHS=36481/255/63, UDMA(100) hdk: cache flushes supported hdk: hdk1 hdn: max request size: 1024KiB hdn: 585940320 sectors (31 MB) w/2048KiB Cache, CHS=36473/255/63, UDMA(100) hdn: cache flushes supported hdn: hdn1 hdp: max request size: 1024KiB hdp: 398297088 sectors (203928 MB) w/7936KiB Cache, CHS=24792/255/63, UDMA(100) hdp: cache flushes supported hdp: hdp1 hdq: max request size: 1024KiB hdq: 488397168 sectors (250059 MB) w/8192KiB Cache, CHS=30401/255/63, UDMA(100) hdq: cache flushes supported hdq: hdq1 hdt: max request size: 1024KiB hdt: 585940320 sectors (31 MB) w/2048KiB Cache, CHS=36473/255/63, UDMA(100) hdt: cache flushes supported hdt: hdt1 Kind regards, Jurriaan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Add schedule_timeout_{interruptible,uninterruptible}{,_msecs}() interfaces
Hi, On Sat, 23 Jul 2005, Arjan van de Ven wrote: > > What's wrong with using jiffies? > > A lot of the (driver) users want a wallclock based timeout. For that, > miliseconds is a more obvious API with less chance to get the jiffies/HZ > conversion wrong by the driver writer. We have helper functions for that. The point about using jiffies is to make it _very_ clear, that the timeout is imprecise and for most users this is sufficient. bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: HPT370 errors under 2.6.13-rc3-mm1
looks like 2.6.12 does the same sort of thing..
On 7/23/05, Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Does vanilla kernel 2.6.12 work for you?
> It doesn't contain hpt366 driver update.
>
> Bartlomiej
>
> On 7/22/05, mdew <[EMAIL PROTECTED]> wrote:
> > I'm unable to mount an ext2 drive using the hpt370A raid card.
> >
> > upon mounting the drive, dmesg will spew these errors..I've tried
> > different cables and drive is fine.
> >
> > Jul 23 01:30:11 localhost kernel: hdf: dma_timer_expiry: dma status == 0x41
> > Jul 23 01:30:21 localhost kernel: hdf: DMA timeout error
> > Jul 23 01:30:21 localhost kernel: hdf: dma timeout error: status=0x25
> > { DeviceFault CorrectedError Error }
> > Jul 23 01:30:21 localhost kernel: hdf: dma timeout error: error=0x25 {
> > DriveStatusError AddrMarkNotFound }, LBAsect=8830589412645,
> > high=526344, low=2434341, sector=390715711
> > Jul 23 01:30:21 localhost kernel: ide: failed opcode was: unknown
> > Jul 23 01:30:21 localhost kernel: hdf: DMA disabled
> > Jul 23 01:30:21 localhost kernel: ide2: reset: master: error (0x0a?)
> > Jul 23 01:30:21 localhost kernel: end_request: I/O error, dev hdf,
> > sector 390715711
> > Jul 23 01:30:21 localhost kernel: end_request: I/O error, dev hdf,
> > sector 390715712
> > [...]
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.6.13rc3: RLIMIT_RTPRIO broken
RLIMIT_RTPRIO is supposed to grant non privileged users the right to use
SCHED_FIFO/SCHED_RR scheduling policies with priorites bounded by the
RLIMIT_RTPRIO value via sched_setscheduler(). This is usually used by
audio users.
Unfortunately this is broken in 2.6.13rc3 as you can see in the excerpt
from sched_setscheduler below:
/*
* Allow unprivileged RT tasks to decrease priority:
*/
if (!capable(CAP_SYS_NICE)) {
/* can't change policy */
if (policy != p->policy)
return -EPERM;
After the above unconditional test which causes sched_setscheduler to
fail with no regard to the RLIMIT_RTPRIO value the following check is made:
/* can't increase priority */
if (policy != SCHED_NORMAL &&
param->sched_priority > p->rt_priority &&
param->sched_priority >
p->signal->rlim[RLIMIT_RTPRIO].rlim_cur)
return -EPERM;
Thus I do believe that the RLIMIT_RTPRIO value must be taken into
account for the policy check, especially as the RLIMIT_RTPRIO limit is
of no use without this change.
The attached patch fixes this problem. I would appreciate it if the fix
would make it into 2.6.13.
--
Andreas Steinmetz SPAMmers use [EMAIL PROTECTED]
--- linux.orig/kernel/sched.c 2005-07-22 19:45:05.0 +0200
+++ linux/kernel/sched.c2005-07-22 19:45:42.0 +0200
@@ -3528,7 +3528,8 @@
*/
if (!capable(CAP_SYS_NICE)) {
/* can't change policy */
- if (policy != p->policy)
+ if (policy != p->policy &&
+ !p->signal->rlim[RLIMIT_RTPRIO].rlim_cur)
return -EPERM;
/* can't increase priority */
if (policy != SCHED_NORMAL &&
Re: [PATCH] Add schedule_timeout_{interruptible,uninterruptible}{,_msecs}() interfaces
On Sat, 2005-07-23 at 12:50 +0200, Roman Zippel wrote: > Hi, > > On Fri, 22 Jul 2005, Arjan van de Ven wrote: > > > Also I'd rather not add the non-msec ones... either you're raw and use > > HZ, or you are "cooked" and use the msec variant.. I dont' see the point > > of adding an "in the middle" one. (Yes this means that several users > > need to be transformed to msecs but... I consider that progress ;) > > What's wrong with using jiffies? A lot of the (driver) users want a wallclock based timeout. For that, miliseconds is a more obvious API with less chance to get the jiffies/HZ conversion wrong by the driver writer. > It's simple and the current timeout > system is based on it. Calling it something else doesn't suddenly give you > more precision. It's not about precision, it's about making the new API (which is intended to be a simplification already due to sucking in the state setting) match the intent closer. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Add schedule_timeout_{interruptible,uninterruptible}{,_msecs}() interfaces
Hi, On Fri, 22 Jul 2005, Arjan van de Ven wrote: > Also I'd rather not add the non-msec ones... either you're raw and use > HZ, or you are "cooked" and use the msec variant.. I dont' see the point > of adding an "in the middle" one. (Yes this means that several users > need to be transformed to msecs but... I consider that progress ;) What's wrong with using jiffies? It's simple and the current timeout system is based on it. Calling it something else doesn't suddenly give you more precision. bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel cached memory
Am Freitag, 22. Juli 2005 19:58 schrieb Lee Revell: > On Fri, 2005-07-22 at 15:25 +0200, Gábor Lénárt wrote: > > Anyway, want to have 'free memory' is a thing like having dozens of cars > > in your garage which don't want to be used ... > > > > Really? I thought it was good to leave some memory free to speed up > application startup, so we don't have to evict a bunch of pages first. Eviction is cheap when the pages are clean. Regards Oliver - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Supermount
Am Freitag, 22. Juli 2005 18:38 schrieb Lasse Kärkkäinen / Tronic: > > Supermount is obsolete there are other tools in userspace that do the > > job perfectly. > > e.g ivman which uses hal and dbus. > > They cannot mount on demand, thus cannot do the same job. The boot > partition, for example, is something that should only be mounted when > required. The same obviously also goes for network filesystems in many > cases (i.e. avoid having zillion idling connections to the server). To mount on demand use autofs. Unmounting and dealing with media removal is the problem. Regards Oliver - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
