Re: Linux 2.6.20-rc2: forgot how to make a zImage on powerpc?
Linus Torvalds wrote: (much of the latter syntactic cleanups). And arm and powerpc updates. Hmm. I'm trying to build 2.6.20-rc2 on a little powerpc box with arch/powerpc/configs/linkstation_defconfig, and I get: [EMAIL PROTECTED] /usr/src/linux $ make zImage HOSTCC scripts/basic/fixdep HOSTCC scripts/basic/docproc HOSTCC scripts/kconfig/conf.o HOSTCC scripts/kconfig/kxgettext.o [snip lots of buildspam] LD lib/zlib_deflate/built-in.o LD lib/zlib_inflate/built-in.o GEN .version LD .tmp_vmlinux1 KSYM.tmp_kallsyms1.S AS .tmp_kallsyms1.o LD .tmp_vmlinux2 KSYM.tmp_kallsyms2.S AS .tmp_kallsyms2.o LD vmlinux SYSMAP System.map SYSMAP .tmp_System.map MODPOST vmlinux ln: accessing `arch/powerpc/boot/zImage': No such file or directory make[1]: *** [arch/powerpc/boot/zImage] Error 1 make: *** [zImage] Error 2 So, uh, are we forgetting to go into the right subdirectory to make the actual zImage, or what? If I'm just doing something wrong, I'd love to know what it is. I'll follow up here on lkml if I diagnose this further. Thanks, Mark - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc2: forgot how to make a zImage on powerpc?
Mark Glines wrote: Hmm. I'm trying to build 2.6.20-rc2 on a little powerpc box with arch/powerpc/configs/linkstation_defconfig, and I get: ... MODPOST vmlinux ln: accessing `arch/powerpc/boot/zImage': No such file or directory make[1]: *** [arch/powerpc/boot/zImage] Error 1 make: *** [zImage] Error 2 So, uh, are we forgetting to go into the right subdirectory to make the actual zImage, or what? If I'm just doing something wrong, I'd love to know what it is. I'll follow up here on lkml if I diagnose this further. Thanks, Followup: Yeah, it looks like it just doesn't know which format of zImage to produce for linkstation. I'm not sure what image should be used by default. I guess it depends on the bootloader. Maybe default to uImage, as uBoot seems to be fairly common on these devices? Mark - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] powerpc: linkstation uses uimage style zImages
Guennadi Liakhovetski wrote: On Mon, 25 Dec 2006, Mark Glines wrote: Followup: Yeah, it looks like it just doesn't know which format of zImage to produce for linkstation. I'm not sure what image should be used by default. I guess it depends on the bootloader. Maybe default to uImage, as uBoot seems to be fairly common on these devices? Yes, uImage is the format used on linkstation. Is there a way to cleanly specify this in the kernel sources apart from a comment in Kconfig? Yep. Kconfig just needs to select DEFAULT_UIMAGE, and then the system tries to build a uImage. Once I tracked down and installed a "mkimage" command (dependency needed by the WRAP line), my "make zImage" succeeded. So, I hope you guys apply this. ... GEN .version LD .tmp_vmlinux1 KSYM.tmp_kallsyms1.S AS .tmp_kallsyms1.o LD .tmp_vmlinux2 KSYM.tmp_kallsyms2.S AS .tmp_kallsyms2.o LD vmlinux SYSMAP System.map SYSMAP .tmp_System.map MODPOST vmlinux WRAParch/powerpc/boot/uImage Image Name: Linux-2.6.20-rc2-kuroboxHG Created: Sun Dec 24 19:24:12 2006 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1673973 Bytes = 1634.74 kB = 1.60 MB Load Address: 0x Entry Point: 0x [EMAIL PROTECTED] /usr/src/linux $ Signed-off-by: Mark Glines <[EMAIL PROTECTED]> --- linux-2.6.20-rc2/arch/powerpc/platforms/embedded6xx/Kconfig.orig 2006-12-24 19:13:49.0 -0800 +++ linux-2.6.20-rc2/arch/powerpc/platforms/embedded6xx/Kconfig 2006-12-24 19:14:02.0 -0800 @@ -79,6 +79,7 @@ select MPIC select FSL_SOC select PPC_UDBG_16550 if SERIAL_8250 + select DEFAULT_UIMAGE help Select LINKSTATION if configuring for one of PPC- (MPC8241) based NAS systems from Buffalo Technology. So far only
Re: [PATCH] powerpc: linkstation uses uimage style zImages
Guennadi Liakhovetski wrote: Mark Thanks for the patch. Are you actually going to test this kernel on a real hardware or just testing builds? If it is going to be a real life test, I'd be interested to know what exactly hardware, U-boot version, dts, and what results. Yes, I do very much intend to test it on real hardware. I have a couple of Kurobox HGs which desperately need a 21st century kernel. I still need to install U-boot on it, but first I'm just going to test the vmlinux with the loader.o kernel module. (And my rs232 voltage converters haven't gotten here yet, so I'm being a little conservative about all of this.) BTW, ack-ing your patch would be a bit easier if you sent it inline. Yeah, thunderbird sucks for this stuff. Keep nagging me and I'll set up mutt again. :) Thanks! Mark - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] ip_local_port_range sysctl has annoying default
On a powerpc machine (kurobox) I have here with 128M of RAM, the default
value of /proc/sys/net/ipv4/ip_local_port_range is:
20484999
This setting affects the port assigned to an application by default
when the application doesn't specify a port to use, like, for instance,
an outgoing connection. It affects both TCP and UDP. The default
values for this sysctl vary depending on the size of the tcp bind hash,
which in turn, varies depending on the size of the system RAM (I think).
By a one-in-a-million coincidence, this machine has a default port
range starting with 2048, and this breaks things for me. I'm trying to
run both klive and nfs on this box, but klive starts first (probably
because of the filename sort order), and claims UDP port 2049 for its
own purposes, causing the nfs server to fail to start.
If the bind hash size is over a certain threshold, the range
32768-61000 is used. If it is under a certain threshold, a range
like (1024|2048|3072)-4999 is used, depending on exactly how small it
is. Thix box happened to get the 2048-4999 range, which broke nfs.
A comment just above the code that does this says, "Try to be a bit
smarter and adjust defaults depending on available memory." "smarter"?
Maybe, maybe not. Either way, it's unexpected.
Following the principle of least astonishment, I think it seems better
to use high, out-of-the-way port numbers regardless of how much RAM the
system has. So, the following patch changes this behavior slightly.
The system still picks a dynamic range depending on the bind hash size,
but now, all ranges start with 32768. I suppose another reasonable way
to do this would be to end all ranges with 61000, or something like
that.
It also seems funny to me that this would be in tcp_init(), when it
affects both TCP and UDP. But hey, it is where it is.
Signed-off-by: Mark Glines <[EMAIL PROTECTED]>
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index bd4c295..4431b87 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -2464,14 +2464,14 @@ void __init tcp_init(void)
(tcp_hashinfo.bhash_size * sizeof(struct
inet_bind_hashbucket));
order++)
;
+ sysctl_local_port_range[0] = 32768;
if (order >= 4) {
- sysctl_local_port_range[0] = 32768;
sysctl_local_port_range[1] = 61000;
tcp_death_row.sysctl_max_tw_buckets = 18;
sysctl_tcp_max_orphans = 4096 << (order - 4);
sysctl_max_syn_backlog = 1024;
} else if (order < 3) {
- sysctl_local_port_range[0] = 1024 * (3 - order);
+ sysctl_local_port_range[1] = 32768 + (1024 * order);
tcp_death_row.sysctl_max_tw_buckets >>= (3 - order);
sysctl_tcp_max_orphans >>= (3 - order);
sysctl_max_syn_backlog = 128;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] ip_local_port_range sysctl has annoying default
On Sat, 12 May 2007 00:06:45 UTC David Miller <[EMAIL PROTECTED]> wrote: > All ports above and including 1024 are non-privileged and available to > anyone. > > Applications which have some requirements in this area need to work > those things out themselves. Hi David, I agree completely. My issue is that an application which doesn't care which port it binds to (twistd, on klive's behalf) stomped on the port of an application which cares very much about which port it binds to (nfs). I will gladly accept *any* solution to this problem. I agree that it would be preferable to change the port NFS decides to bind to. If you have a patch to do this, I will happily apply it and go on my merry way. However, the world we live in does have port numbers exceeding 1024 listed in /etc/services. What I'd like to know is, for applications which don't care what port they get, the kernel will assign values of 32768 and above on some machines, but not others. (Based on their bind hash size.) Starting from 32768 seems like very sane behavior to me, because it minimizes the chances of a collision, and (as far as I know) doesn't cost anything. A configuration which stomps on a not-entirely-unknown application like nfs *by default* isn't necessarily a bug, but it is a worst case scenario, from the perspective of a lowly user like me, who wants things to Just Work. :) Is there a compelling reason not to assign random ports starting from 32768 everywhere regardless of their bind hash size, like my patch attempts to do? Does it consume any extra resources to do so? Thanks, Mark - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] ip_local_port_range sysctl has annoying default
On Fri, 11 May 2007 19:12:15 -0700
"H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> > Following the principle of least astonishment, I think it seems
> > better to use high, out-of-the-way port numbers regardless of how
> > much RAM the system has. So, the following patch changes this
> > behavior slightly. The system still picks a dynamic range depending
> > on the bind hash size, but now, all ranges start with 32768. I
> > suppose another reasonable way to do this would be to end all
> > ranges with 61000, or something like that.
> >
>
> Yes, that would be better. The IANA recommended port range for
> dynamic ports are 49152-65535; Linux extends this to 32768 and chops
> off some of the really high ports, but keeping them in the high range
> is thus the right thing to do.
Well, in that case, is there anything wrong with just using the
range IANA recommends, in all cases?
Please consider this patch instead of my previous one.
Signed-off-by: Mark Glines <[EMAIL PROTECTED]>
diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
index 43fb160..b04b167 100644
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -34,7 +34,7 @@ EXPORT_SYMBOL(inet_csk_timer_bug_msg);
* For high-usage systems, use sysctl to change this to
* 32768-61000
*/
-int sysctl_local_port_range[2] = { 1024, 4999 };
+int sysctl_local_port_range[2] = { 49152, 65535 };
int inet_csk_bind_conflict(const struct sock *sk,
const struct inet_bind_bucket *tb)
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index bd4c295..33ef0e7 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -2465,13 +2465,10 @@ void __init tcp_init(void)
order++)
;
if (order >= 4) {
- sysctl_local_port_range[0] = 32768;
- sysctl_local_port_range[1] = 61000;
tcp_death_row.sysctl_max_tw_buckets = 18;
sysctl_tcp_max_orphans = 4096 << (order - 4);
sysctl_max_syn_backlog = 1024;
} else if (order < 3) {
- sysctl_local_port_range[0] = 1024 * (3 - order);
tcp_death_row.sysctl_max_tw_buckets >>= (3 - order);
sysctl_tcp_max_orphans >>= (3 - order);
sysctl_max_syn_backlog = 128;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] ip_local_port_range sysctl has annoying default
On Sat, 12 May 2007 12:12:38 -0700
"H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> Mark Glines wrote:
> >
> > Well, in that case, is there anything wrong with just using the
> > range IANA recommends, in all cases?
> >
>
> I think the IANA range is considered too small in most cases; I
> suspect there is also a feeling that "there be dragons" near the very
> top.
Ok, thanks for the explanation. Sounds like we're using high port
numbers in the "spirit" of the IANA recommendation, without using
their actual numbers.
I still haven't gotten an answer to this: is there a performance
issue (or memory usage or security or something) with using the same
port range in all cases, even on memory-constrained systems? And if
there is, can't we *still* use big numbers, even if the range isn't
as wide?
If there's no reason not to (security, resource consumption,
whatever), I think it would be an improvement to use high, out of the
way port numbering in all cases. (Especially since the kernel already
does this on most of my machines, anyway.)
There was a comment in there about how 32768-61000 should be used on
high-use systems; is there a drawback to just using this range
*everywhere*? (It's already the default in non-memory-constrained
cases, because of what tcp_init() was doing.)
Thanks,
Signed-off-by: Mark Glines <[EMAIL PROTECTED]>
diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
index 43fb160..12d9ddc 100644
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -29,12 +29,7 @@ const char inet_csk_timer_bug_msg[] = "inet_csk BUG: unknown
timer value\n";
EXPORT_SYMBOL(inet_csk_timer_bug_msg);
#endif
-/*
- * This array holds the first and last local port number.
- * For high-usage systems, use sysctl to change this to
- * 32768-61000
- */
-int sysctl_local_port_range[2] = { 1024, 4999 };
+int sysctl_local_port_range[2] = { 32768, 61000 };
int inet_csk_bind_conflict(const struct sock *sk,
const struct inet_bind_bucket *tb)
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index bd4c295..33ef0e7 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -2465,13 +2465,10 @@ void __init tcp_init(void)
order++)
;
if (order >= 4) {
- sysctl_local_port_range[0] = 32768;
- sysctl_local_port_range[1] = 61000;
tcp_death_row.sysctl_max_tw_buckets = 18;
sysctl_tcp_max_orphans = 4096 << (order - 4);
sysctl_max_syn_backlog = 1024;
} else if (order < 3) {
- sysctl_local_port_range[0] = 1024 * (3 - order);
tcp_death_row.sysctl_max_tw_buckets >>= (3 - order);
sysctl_tcp_max_orphans >>= (3 - order);
sysctl_max_syn_backlog = 128;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: select(0, ..) is valid ?
On Tue, 15 May 2007 10:29:18 -0700 Badari Pulavarty <[EMAIL PROTECTED]> wrote: > Hi, > > Is select(0, ..) is a valid operation ? select(0, ..) is rather commonly used as a portable sleep() with microsecond granularity. Disabling it will break lots of things. Mark - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
On Wed, 18 Apr 2007 10:22:59 -0700 (PDT) Linus Torvalds <[EMAIL PROTECTED]> wrote: > So if you have 2 users on a machine running CPU hogs, you should > *first* try to be fair among users. If one user then runs 5 programs, > and the other one runs just 1, then the *one* program should get 50% > of the CPU time (the users fair share), and the five programs should > get 10% of CPU time each. And if one of them uses two threads, each > thread should get 5%. This sounds great, to me. One minor question: is it even possible to be completely fair on SMP? For instance, if you have a 2-way SMP box running 3 applications, one of which has 2 threads, will the threaded app have an advantage here? (The current system seems to try to keep each thread on a specific CPU, to reduce cache thrashing, which means threads and processes alike each get 50% of the CPU.) Mark - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: RSDL v0.31
On Sat, 17 Mar 2007 09:46:27 +0100 Mike Galbraith <[EMAIL PROTECTED]> wrote: > On Fri, 2007-03-16 at 23:44 -0800, David Lang wrote: > > > why isn't niceing X to -10 an acceptable option? > > Xorg's priority is only part of the problem. Every client that needs > a substantial quantity of cpu while a hog is running will also need > to be negative nice, no? I don't suppose you can be a bit more specific, and define how much CPU constitutes a "substantial quantity"? It looks to me like X already got about half of a CPU. > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ P COMMAND > 6599 root 26 0 174m 30m 8028 R 51 3.1 7:08.70 0 Xorg I'm hoping that actually quantifying this issue will result in a better understanding of the issue... Thanks, Mark - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: RSDL v0.31
On Sat, 17 Mar 2007 15:33:41 +0100 Mike Galbraith <[EMAIL PROTECTED]> wrote: > > > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ P > > > COMMAND 6599 root 26 0 174m 30m 8028 R 51 3.1 > > > 7:08.70 0 Xorg > > > > This is a snippet from a hacked up by me version of RSDL.30, not > stock. Oops. Thanks, sorry about my confusion. What does it look like without your patches? (I'm not sure if you've already sent this... I can't find any in the list archives.) Mark - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
