[uClinux-dev] uClinux-dist patches to include linux-2.6.30 kernel
Hi All, I have put a new patch set up on www.uclinux.org that updates the uClinux-dist with the latest linux-2.6.30 kernel. You can get the patches from: http://www.uclinux.org/pub/uClinux/dist/patches/ The latest is uClinux-dist-20090618-20090810. Regards Greg -- Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] interrupt handler changes for m68knommu
Hi All, I have a set of changes that effect interrupt processing on the ColdFire parts. Cleans it up alot, and makes driver porting much easier. You can see them in the for-linus branch of: git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git for-linus if you want to have a look. Comments welcome. I plan on pushing these to Linus in the 2.6.32 merge window. Regards Greg Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] uClinux-dist patches to include linux-2.6.30 kernel
Dear Greg, Greg Ungerer wrote: I have put a new patch set up on www.uclinux.org that updates the uClinux-dist with the latest linux-2.6.30 kernel. You can get the patches from: http://www.uclinux.org/pub/uClinux/dist/patches/ The latest is uClinux-dist-20090618-20090810. Please note that there were NOMMU patches for ARM posted on the ARM-linux-kernel mailing list [1] that take another approach to your consistent-nommu.c fixes. The patches posted there makes the dmaengine framework compile, while with your current patches using the dmaframework ends up giving compilation errors. Just wanted to give you a heads up before they are merged in during the next merge window. [1]: http://lists.arm.linux.org.uk/lurker/message/20090710.115013.fc81fe5e.en.html#linux-arm-kernel Regards, Ithamar R. Adema http://www.team-embedded.nl ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Problems loading uClinux from some 2GB SD cards
Hi Bob, On Sun, 2009-08-09 at 17:22 -0700, Bob Furber wrote: I am not sure where to turn on this baffling problem. It seems that ext2fs partition layout or information on 2GB SD cards has changed over time. I have been using an old Fedora Linux PC (Fedora Core 2.6.15) to partition SD cards and load uClinux onto them and our SBCs are quite happy booting uClinux from these cards; even 2GB SD cards. The problem started when we started using a new Ubuntu LinuxPC (2.6.27). Our SBCs are quite happy booting uClinux from these cards ..EXCEPT for 2GB SD cards. A SD card partitioned on the old Fedora Linux PC is unreadable on the new UbuntuPC A SD card partitioned on the UbuntuPC is READABLE on the old Fedora Linux PC Our SBCs cannot find /boot/linix.bin on a 2GB SD card prepared (partitioned loaded with uClinux) on the new UbuntuPC Our SBCs CAN find /boot/linix.bin on a 256MB SD card prepared on the new UbuntuPC Our SBCs CAN find /boot/linix.bin on a 2GB SD card prepared on the old Fedora Linux PC And, yes, the same scripts are used on both Linux PCs and we have taken into account the csd.rd_bl_len kludge used by 2GB SD cards to represent the greater capacity. This is why 2GB SD cards loaded on our old Fedora Linux PC happily boot on our PCs. The SBCs use a modified dBUG monitor to boot uClinux from an SD card. The modifications to dBUG were carried out in 2005 and consisted of adding some SD card APIs and files lifted from U-boot and massaged: cmd_ext2.c, ext2fs.c, dev.c, part.c part_dos.c. Has anyone come across this problem? Thanks, Bob Furber ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev I can't really give any specific help other than what you already tried, but I have been in a similar situation. I got some Olin 2 GB cards a little while ago and existing firmware I had running (using SPI) totally refused to run properly. Like you, I allowed the hack on the block length in CSD. My good old trusty card reader doesn't like the cards either. I spent a bit of time stepping around further in my code but I never pinned it down as to where these 2 GB cards went to lala land. I gave up I must say... too irritating. A look at the card vendor's URL revealed they expect the consumer to buy their card reader products, which of course is a joke. The last I checked, the consensus is/was that the 2 GB cards arena is a big mess. Apparently, more don't work than ones that actually do Seemed to me might as well move to HC... ? I certainly appreciate/sympathise - I found it very irritating to say the least : These cards are sold with the SD spec logo - but they don't __comply__ !!! -- Best regards, Kris ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] uClinux-dist patches to include linux-2.6.30 kernel
Hi Ithamar, On 08/11/2009 06:44 PM, Ithamar R. Adema wrote: Greg Ungerer wrote: I have put a new patch set up on www.uclinux.org that updates the uClinux-dist with the latest linux-2.6.30 kernel. You can get the patches from: http://www.uclinux.org/pub/uClinux/dist/patches/ The latest is uClinux-dist-20090618-20090810. Please note that there were NOMMU patches for ARM posted on the ARM-linux-kernel mailing list [1] that take another approach to your consistent-nommu.c fixes. The patches posted there makes the dmaengine framework compile, while with your current patches using the dmaframework ends up giving compilation errors. Just wanted to give you a heads up before they are merged in during the next merge window. I saw those. They will merge through when I integrate 2.6.31 (and I will replace the existing patches in uClinux-dist kernels). Thanks Greg Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Shell exits while running a program.
Michael Schnell wrote: I now have a Futex testing program up and running. You may wish to look at Glibc's pthread tests too. They did a lot of testing to make sure the NPTL futex usage is correct with all kind of primitives, not just thread mutexes, but condition variables, rwlocks, and inter-process versions too. They also did a lot of benchmarks, which is why sys_futex was changed from an elegant simple thing to what it is today. Also, you may wish to look at the robust real-time mutexes with priority inheritance (RT and PI are keywords), which works alongside RT kernels. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Shell exits while running a program.
Michael Schnell wrote: Michael Schnell wrote: disables the global interrupt for the next three instructions. True for the NIOS, that does not use Flags - but register compares - for conditional jumps, with an architecture that uses flags, I suppose you need a lock for four instructions. That sounds right. Three instructions is also enough for atomic-add, atomic-sub, atomic-and etc. in addition to compare-exchange. Although compare-exchange is universal, sometimes it takes more time busy spinning compared with an atomic arithmetic or logical operation, when under high contention with multiple CPUs. Four instructions is enough for a versatile logic sequence: LOAD [addr], reg AND #xxx, reg XOR #yyy, reg STORE reg, [addr] -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Shell exits while running a program.
Jamie Lokier wrote: Although compare-exchange is universal, sometimes it takes more time busy spinning compared with an atomic arithmetic or logical operation, when under high contention with multiple CPUs. I'm being a bit stupid here. The interrupt-disabling method doesn't work with multiple CPUs anyway. compare-exchange spinning is reduced, probably to virtually zero, when there's only one CPU and you're not getting interrupts at an extreme rate. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Shell exits while running a program.
Michael Schnell wrote: Jim Donelson wrote: All that is really required is an atomic exchange. Suppose 1 means taken, 0 means free. I do an exchange with a 1. If I got back a zero, it's mine. True with a Mutex, not true with a Futex. Here you need a second bit in user-space that tells the releaser that it is to wake up a sleeping waiter. Otherwise, any release would need a system call. Indeed. A atomic-swap instruction provides enough bits, but it's hard to get the algorithm right. Seemingly the best instruction to handle these bits is atomic compare and exchange (e.g. provided by the X86 CPU). It's actually not the best, because when it returns did not match you have to loop and try again. The amount of looping depends on contention level. Ideal would be an atomic-do-what-I-need-for-my-algorithm operation. However, atomic-compare-exchange can be used for everything, so it's a useful instruction if you have to pick one. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Shell exits while running a program.
It's actually not the best, because when it returns did not match you have to loop and try again. Not sure what else you would do? The purpose of a spin lock is to avoid a more expensive kernel call if the mutex is released quickly (or not taken at all). Presumably you enter the kernel after n tries and sleep so that you are not using up quanta while spinning. The amount of looping depends on contention level. The real secret is to reduce the time spent holding the mutex in general. As for priority inversion (where a lower priority task gets to execute because is it holding a mutex that a higher priority thread is waiting on) that should be addressed in the kernel. The lower priority thread should get temporary priority elevation. On Tue, Aug 11, 2009 at 9:34 AM, Jamie Lokier ja...@shareable.org wrote: Michael Schnell wrote: Jim Donelson wrote: All that is really required is an atomic exchange. Suppose 1 means taken, 0 means free. I do an exchange with a 1. If I got back a zero, it's mine. True with a Mutex, not true with a Futex. Here you need a second bit in user-space that tells the releaser that it is to wake up a sleeping waiter. Otherwise, any release would need a system call. Indeed. A atomic-swap instruction provides enough bits, but it's hard to get the algorithm right. Seemingly the best instruction to handle these bits is atomic compare and exchange (e.g. provided by the X86 CPU). It's actually not the best, because when it returns did not match you have to loop and try again. The amount of looping depends on contention level. Ideal would be an atomic-do-what-I-need-for-my-algorithm operation. However, atomic-compare-exchange can be used for everything, so it's a useful instruction if you have to pick one. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] build problem with sshd in the 2.4 kernel
I'm using the uClinux 2.4 kernel with a Coldfire MC5275 and I'm trying to build in the sshd application and I'm getting a build failure. I used make menuconfig and selected sshd under the networking applications option. In the build process I'm getting the following error; Has anyone been successful in getting sshd to build? I'm wondering if I'm missing something or if there is a patch available. Any help is greatly appreciated. -- make[2]: Entering directory `/home/uClinux-dist/user/sh' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/uClinux-dist/user/sh' make[2]: Entering directory `/home/uClinux-dist/user/ssh' (cd openbsd-compat make) make[3]: Entering directory `/home/uClinux-dist/user/ssh/openbsd-compat' ucfront-gcc m68k-elf-gcc -m5200 -DCONFIG_COLDFIRE -Os -g -fomit-frame-pointer -fno-common -fno-builtin -Wall -DEMBED -msep-data -Dlinux -D__linux__ -Dunix -D__uClinux__ -g -O2 -Wall -D_SSH_PROGRAM=\/bin/ssh\ -DSSH_ASKPASS_DEFAULT=\/bin/ssh-askpass\ -I. -DHAVE_CONFIG_H -I. -I..-c -o bsd-arc4random.o bsd-arc4random.c In file included from bsd-arc4random.c:25: ../includes.h:168: openssl/opensslv.h: No such file or directory bsd-arc4random.c:32: openssl/rand.h: No such file or directory bsd-arc4random.c:33: openssl/rc4.h: No such file or directory bsd-arc4random.c:34: openssl/err.h: No such file or directory make[3]: *** [bsd-arc4random.o] Error 1 make[3]: Leaving directory `/home/uClinux-dist/user/ssh/openbsd-compat' make[2]: *** [subdirs] Error 2 make[2]: Leaving directory `/home/uClinux-dist/user/ssh' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/uClinux-dist/user' make: *** [subdirs] Error 1 ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Shell exits while running a program.
Jim Donelson wrote:
It's actually not the best, because when it returns did not match
you have to loop and try again.
Not sure what else you would do? The purpose of a spin lock is to
avoid a more expensive kernel call
It's not a spinlock.
This loop is for a different reason. You can tell it's different
because it spins when *unlocking* too; a spinlock never does that.
The did not match case for compare-exchange is to simulate an atomic
operation like this example:
int atomic_dec_test(unsigned *mem)
{
do {
old = *mem;
new = old+1;
} while (!compare_exchange(mem, old, new));
return (new != 0);
}
void mutex_unlock(unsigned *mem)
{
if (atomic_dec_test(mem))
futex(FUTEX_WAKE, mem);
}
The amount of looping depends on contention level.
The real secret is to reduce the time spent holding the mutex in general.
Think about the code above. The amount of looping in
atomic_dec_test(), above, is not reduced by reducing the time spent
holding the mutex.
If you hold the mutex for shorter times in more places (moving the
mutex from large regions to small ones), paradoxically it will
*increase* the average amount of looping in atomic_dec_test() and the
other atomic ops. Usually not by enough to care, but it depends on
the program.
That why compare-exchange (and load-locked/store-conditional CPU
instructions), though universally usable, doesn't have the same
performance characteristics as atomic read-modify-writed ops. Though,
atomic ops are sometimes implemented as lock-locked/store-conditional
in the chip anyway.. it's a subtle area.
The purpose of a spin lock is to avoid a more expensive kernel call
if the mutex is released quickly (or not taken at all). Presumably
you enter the kernel after n tries and sleep so that you are not
using up quanta while spinning.
That doesn't work with a single processor. While you are spinning,
it's impossible for the other thread to release the mutex until you
are preempted, so potential benefit from spinning is marginal and
often outweight by the benefit of not spinning.
As for priority inversion (where a lower priority task gets to execute
because is it holding a mutex that a higher priority thread is waiting
on) that should be addressed in the kernel. The lower priority thread
should get temporary priority elevation.
Yes, that's what the robust PI mutexes implemention does.
It uses futexes in userspace to avoid entering the kernel just like
the standard futex algorithms, but priority inheritance if it enters
the kernel, and cleverly if a thread or process crashes, the mutex is
safely recoverable too.
-- Jamie
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] build problem with sshd in the 2.4 kernel
Hello b2112!
I'm using the uClinux 2.4 kernel with a Coldfire MC5275 and I'm trying
to build in the sshd application and I'm getting a build failure. I
used make menuconfig and selected sshd under the networking
applications option.
In the build process I'm getting the following error;
Has anyone been successful in getting sshd to build? I'm wondering if
I'm missing something or if there is a patch available.
Any help is greatly appreciated.
You can look at my patches for uClinux-20090302 for openssl and ssh.
--
Igor Plyatov
diff --git a/lib/libssl/makefile b/lib/libssl/makefile
index b6039b1..68fa4a0 100644
--- a/lib/libssl/makefile
+++ b/lib/libssl/makefile
@@ -68,13 +68,13 @@ CONFIG_OPTS += no-err
# REVISIT: It would be better to have OPENSSL config options
# which turn on this support as needed
ifeq ($(CONFIG_USER_NESSUS_NASL)$(CONFIG_USER_SSH_SSH),)
-CONFIG_OPTS += no-ripemd
-CONFIG_OPTS += no-cast
-CONFIG_OPTS += no-rc4
+#CONFIG_OPTS += no-ripemd
+#CONFIG_OPTS += no-cast
+#CONFIG_OPTS += no-rc4
endif
ifeq ($(CONFIG_USER_NESSUS_NASL)$(CONFIG_USER_SSH_SSH)$(CONFIG_PROP_SSCEP_SSCEP),)
-CONFIG_OPTS += no-bf
+#CONFIG_OPTS += no-bf
endif
ifeq ($(CONFIG_USER_OPENVPN_OPENVPN)$(CONFIG_USER_WGET),)
@@ -140,6 +140,7 @@ $(SRC_DIR)/Configure $(SRC_DIR)/config: makefile $(SRC_DIR).tar.gz \
rm -rf $(SRC_DIR) build
gunzip $(SRC_DIR).tar.gz | tar xf -
patch -p0 patches/$(SRC_DIR).patch
+ patch -p0 patches/speed.patch
touch $(SRC_DIR)/Configure $(SRC_DIR)/config
else
diff --git a/lib/libssl/patches/speed.patch b/lib/libssl/patches/speed.patch
new file mode 100644
index 000..a3f4c6c
--- /dev/null
+++ b/lib/libssl/patches/speed.patch
@@ -0,0 +1,11 @@
+--- openssl-0.9.8i/apps/speed.c 2009-05-05 16:31:08.0 +0400
openssl-0.9.8i/apps/speed.c 2009-05-05 16:19:25.0 +0400
+@@ -254,7 +254,7 @@
+ # endif
+ #endif
+
+-#if !defined(OPENSSL_SYS_VMS) !defined(OPENSSL_SYS_WINDOWS) !defined(OPENSSL_SYS_MACINTOSH_CLASSIC) !defined(OPENSSL_SYS_OS2) !defined(OPENSSL_SYS_NETWARE)
++#if !defined(OPENSSL_SYS_VMS) !defined(OPENSSL_SYS_WINDOWS) !defined(OPENSSL_SYS_MACINTOSH_CLASSIC) !defined(OPENSSL_SYS_OS2) !defined(OPENSSL_SYS_NETWARE) !defined(CONFIG_COLDFIRE)
+ # define HAVE_FORK 1
+ #endif
+
diff --git a/user/ssh/auth-pam.c b/user/ssh/auth-pam.c
index 1b39552..054aedf 100644
--- a/user/ssh/auth-pam.c
+++ b/user/ssh/auth-pam.c
@@ -187,7 +187,11 @@ pthread_create(sp_pthread_t *thread, const void *attr,
struct pam_ctxt *ctx = arg;
sshpam_thread_status = -1;
+#ifdef __uClinux__
+ switch ((pid = vfork())) {
+#else
switch ((pid = fork())) {
+#endif
case -1:
error(fork(): %s, strerror(errno));
return (-1);
diff --git a/user/ssh/entropy.c b/user/ssh/entropy.c
index 8b70539..fe471cf 100644
--- a/user/ssh/entropy.c
+++ b/user/ssh/entropy.c
@@ -91,8 +91,13 @@ seed_rng(void)
fatal(pipe: %s, strerror(errno));
old_sigchld = signal(SIGCHLD, SIG_DFL);
- if ((pid = fork()) == -1)
+#ifdef __uClinux__
+ if ((pid = vfork()) == -1) {
+#else
+ if ((pid = fork()) == -1) {
+#endif
fatal(Couldn't fork: %s, strerror(errno));
+ }
if (pid == 0) {
dup2(devnull, STDIN_FILENO);
dup2(p[1], STDOUT_FILENO);
diff --git a/user/ssh/openbsd-compat/daemon.c b/user/ssh/openbsd-compat/daemon.c
index e3a6886..5006dc3 100644
--- a/user/ssh/openbsd-compat/daemon.c
+++ b/user/ssh/openbsd-compat/daemon.c
@@ -53,7 +53,11 @@ daemon(int nochdir, int noclose)
{
int fd;
+#ifdef __uClinux__
+ switch (vfork()) {
+#else
switch (fork()) {
+#endif
case -1:
return (-1);
case 0:
diff --git a/user/ssh/scp.c b/user/ssh/scp.c
index a685c93..4e4dc52 100644
--- a/user/ssh/scp.c
+++ b/user/ssh/scp.c
@@ -172,13 +172,21 @@ do_local_cmd(arglist *a)
fprintf(stderr, %s, a-list[i]);
fprintf(stderr, \n);
}
- if ((pid = fork()) == -1)
+#ifdef __uClinux__
+ if ((pid = vfork()) == -1) {
+#else
+ if ((pid = fork()) == -1) {
+#endif
fatal(do_local_cmd: fork: %s, strerror(errno));
-
+}
if (pid == 0) {
execvp(a-list[0], a-list);
perror(a-list[0]);
+#ifdef __uClinux__
+ _exit(1);
+#else
exit(1);
+#endif
}
do_cmd_pid = pid;
diff --git a/user/ssh/sftp.c b/user/ssh/sftp.c
index 66bd111..3087e60 100644
--- a/user/ssh/sftp.c
+++ b/user/ssh/sftp.c
@@ -253,9 +253,13 @@ local_do_shell(const char *args)
if ((shell = getenv(SHELL)) == NULL)
shell = _PATH_BSHELL;
- if ((pid = fork()) == -1)
+#ifdef __uClinux__
+ if ((pid = vfork()) == -1) {
+#else
+ if ((pid = fork()) == -1) {
+#endif
fatal(Couldn't fork: %s, strerror(errno));
-
+ }
if (pid == 0) {
/* XXX: child has pipe fds to ssh subproc open - issue? */
if (args) {
@@ -1630,8 +1634,13 @@ connect_to_server(char *path, char **args, int *in, int *out)
c_in = c_out = inout[1];
#endif /* USE_PIPES */
- if ((sshpid = fork()) == -1)
+#ifdef __uClinux__
+ if ((sshpid = vfork()) == -1) {
+#else
+ if ((sshpid = fork()) == -1) {
+#endif
fatal(fork: %s, strerror(errno));
+ }
else if (sshpid ==
Re: [uClinux-dev] Shell exits while running a program.
On Tue, Aug 11, 2009 at 12:27 PM, Jamie Lokier ja...@shareable.org wrote:
Jim Donelson wrote:
It's actually not the best, because when it returns did not match
you have to loop and try again.
Not sure what else you would do? The purpose of a spin lock is to
avoid a more expensive kernel call
It's not a spinlock.
This loop is for a different reason. You can tell it's different
because it spins when *unlocking* too; a spinlock never does that.
The did not match case for compare-exchange is to simulate an atomic
operation like this example:
int atomic_dec_test(unsigned *mem)
{
do {
old = *mem;
new = old+1;
} while (!compare_exchange(mem, old, new));
return (new != 0);
}
void mutex_unlock(unsigned *mem)
{
if (atomic_dec_test(mem))
futex(FUTEX_WAKE, mem);
}
I'd like to see the code for compare_exchange and the lock function.
The amount of looping depends on contention level.
The real secret is to reduce the time spent holding the mutex in general.
Think about the code above. The amount of looping in
atomic_dec_test(), above, is not reduced by reducing the time spent
holding the mutex.
If you hold the mutex for shorter times in more places (moving the
mutex from large regions to small ones), paradoxically it will
*increase* the average amount of looping in atomic_dec_test() and the
other atomic ops. Usually not by enough to care, but it depends on
the program.
That why compare-exchange (and load-locked/store-conditional CPU
instructions), though universally usable, doesn't have the same
performance characteristics as atomic read-modify-writed ops. Though,
atomic ops are sometimes implemented as lock-locked/store-conditional
in the chip anyway.. it's a subtle area.
The purpose of a spin lock is to avoid a more expensive kernel call
if the mutex is released quickly (or not taken at all). Presumably
you enter the kernel after n tries and sleep so that you are not
using up quanta while spinning.
That doesn't work with a single processor. While you are spinning,
it's impossible for the other thread to release the mutex until you
are preempted, so potential benefit from spinning is marginal and
often outweight by the benefit of not spinning.
Of course it does - sleeping on a sp means preempt me now.
As for priority inversion (where a lower priority task gets to execute
because is it holding a mutex that a higher priority thread is waiting
on) that should be addressed in the kernel. The lower priority thread
should get temporary priority elevation.
Yes, that's what the robust PI mutexes implemention does.
It uses futexes in userspace to avoid entering the kernel just like
the standard futex algorithms, but priority inheritance if it enters
the kernel, and cleverly if a thread or process crashes, the mutex is
safely recoverable too.
-- Jamie
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Shell exits while running a program.
Jim Donelson wrote: I'd like to see the code for compare_exchange and the lock function. compare_exchange is a single architecture-specific instruction; that's what we're discussing. Lock functions are described in Ulrich Drepper's futex paper. The purpose of a spin lock is to avoid a more expensive kernel call if the mutex is released quickly (or not taken at all). Presumably you enter the kernel after n tries and sleep so that you are not using up quanta while spinning. That doesn't work with a single processor. While you are spinning, it's impossible for the other thread to release the mutex until you are preempted, so potential benefit from spinning is marginal and often outweight by the benefit of not spinning. Of course it does - sleeping on a sp means preempt me now. Yes, but *spinning* on a spinlock does not. You propose spinning n times before sleeping. The mutex will only be released during spin time if you are randomly preempted during that short time. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Problem in dma_map
On Wed, Aug 12, 2009 at 12:03:55AM +0200, Ithamar R. Adema wrote: As you can see, the vm_start address has been clobbered. It seems this is due to the 3 parameter to remap_pfn_range, where vma-vm_pgoff get passed, whilst the documentation of remap_pfn_page suggests this should be a physical address of kernel memory I've been asking about the remap_pfn_range behavior some time ago on this list but got no reply... IMHO remap_pfn_range on nommu is broken and does not serve the same function as on mmu. Daniel ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] What toolchain for ARM w/o MMU (non-XIP)?
Jeff Bacon wrote: Note that for some builds where I'm not using XIP, I've switched to the code sorcery 4.3.3 toolchain for arm (2009q1-163) and it seems to work just fine for non-xip code. Thanks Jeff. I grabbed the code sourcery toolchain and no longer have the issues with busybox. However I am still seeing the gotpic flag set on apps that link with zlib as shown below: # file testapp testapp: BFLT executable - version 4 gotpic Are you using zlib on your non-xip builds or do you have any suggestions on how to build it to prevent this problem? Thanks, Lance ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] uclinux and ethernet bridging support
Hi @ all, I have noticed that there is no networking - 802.1d Ethernet Bridging support in the ucLinux Kernel nor as module. I also have noticed that is impossible to compile the bridge-utils ( http://sourceforge.net/projects/bridge/files/) it crashs with an compile error (I have tried every version of the last 3 years). I use the moxa em-1220-LX Arm9 So does anyone has succeded in using ethernet bridging? If so how you have achieved that? Any hint is great, if one can provide me with an image that also supports ethernet bridging even greater, Best Regards Michael ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Problem in dma_map
Hi Daniel, Daniel Glöckner wrote: I've been asking about the remap_pfn_range behavior some time ago on this list but got no reply... IMHO remap_pfn_range on nommu is broken and does not serve the same function as on mmu. For now, I've found a simple workaround by changing remap_pfn_range in mm/nommu.c from vma-vm_start = vma-vm_pgoff PAGE_SHIFT; to vma-vm_start += vma-vm_pgoff PAGE_SHIFT; This takes care of the wrongly changing vm_start, but I have not tested it with mmap-ing from a non-zero offset. To be continued... HTH, Ithamar Adema http://www.team-embedded.nl ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Problems loading uClinux from some 2GB SD cards
Microbit_Ubuntu wrote: My problem is not with the SD card quality, but, with the way they have been partitioned. Linux/dumpe2fs showed that the bootable [Fedora-2.6.15] 2GB SD cards had inode_size = 128, whereas the delinquent [Ubuntu-2.6.27] SD cards had inode_size = 256. Adding a -I 128 switch to mkfs.ext3 in the script that prepares and loads the SD cards solved the problem. That is, our SBCs can now boot from Ubuntu prepared SD cards. However, this brings up the point that, somewhere along the line, the default inode_size for SD cards is no longer 128 bytes. It could be double, quadruple or more. There is some suspicious code in the U-Boot ext2fs.c/ext2fs_read_inode(): inodes_per_block = EXT2_BLOCK_SIZE (data) / 128; However, when this was replaced by inodes_per_block = EXT2_BLOCK_SIZE (data) / INODE_SIZE(data); ..the 2GB/128 byte inode SD cards booted and the 2GB/256 byte inode SD cards didn't. Obviously there is something else at play which eludes me. I have posted on the http://www.denx.de/wiki/U-Boot mailing list, in the hopes they can shed some light on the subject. I shall keep you informed if there is any progress. Bfn, Bob Furber Hi Bob, On Sun, 2009-08-09 at 17:22 -0700, Bob Furber wrote: I am not sure where to turn on this baffling problem. It seems that ext2fs partition layout or information on 2GB SD cards has changed over time. I have been using an old Fedora Linux PC (Fedora Core 2.6.15) to partition SD cards and load uClinux onto them and our SBCs are quite happy booting uClinux from these cards; even 2GB SD cards. The problem started when we started using a new Ubuntu LinuxPC (2.6.27). Our SBCs are quite happy booting uClinux from these cards ..EXCEPT for 2GB SD cards. A SD card partitioned on the old Fedora Linux PC is unreadable on the new UbuntuPC A SD card partitioned on the UbuntuPC is READABLE on the old Fedora Linux PC Our SBCs cannot find /boot/linix.bin on a 2GB SD card prepared (partitioned loaded with uClinux) on the new UbuntuPC Our SBCs CAN find /boot/linix.bin on a 256MB SD card prepared on the new UbuntuPC Our SBCs CAN find /boot/linix.bin on a 2GB SD card prepared on the old Fedora Linux PC And, yes, the same scripts are used on both Linux PCs and we have taken into account the csd.rd_bl_len kludge used by 2GB SD cards to represent the greater capacity. This is why 2GB SD cards loaded on our old Fedora Linux PC happily boot on our PCs. The SBCs use a modified dBUG monitor to boot uClinux from an SD card. The modifications to dBUG were carried out in 2005 and consisted of adding some SD card APIs and files lifted from U-boot and massaged: cmd_ext2.c, ext2fs.c, dev.c, part.c part_dos.c. Has anyone come across this problem? Thanks, Bob Furber ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev I can't really give any specific help other than what you already tried, but I have been in a similar situation. I got some Olin 2 GB cards a little while ago and existing firmware I had running (using SPI) totally refused to run properly. Like you, I allowed the hack on the block length in CSD. My good old trusty card reader doesn't like the cards either. I spent a bit of time stepping around further in my code but I never pinned it down as to where these 2 GB cards went to lala land. I gave up I must say... too irritating. A look at the card vendor's URL revealed they expect the consumer to buy their card reader products, which of course is a joke. The last I checked, the consensus is/was that the 2 GB cards arena is a big mess. Apparently, more don't work than ones that actually do Seemed to me might as well move to HC... ? I certainly appreciate/sympathise - I found it very irritating to say the least : These cards are sold with the SD spec logo - but they don't __comply__ !!! ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] build problem with sshd in the 2.4 kernel
Jivin b2112 lays it down ... I'm using the uClinux 2.4 kernel with a Coldfire MC5275 and I'm trying to build in the sshd application and I'm getting a build failure. I used make menuconfig and selected sshd under the networking applications option. In the build process I'm getting the following error; Has anyone been successful in getting sshd to build? I'm wondering if I'm missing something or if there is a patch available. Any help is greatly appreciated. You don't appear to have the openssl lib build enabled (or perhaps not included depending on your version of the dist). Which uClinux-dist version do you have ? Check that CONFIG_LIB_LIBSSL is enabled in your config/.config Check you have libssl or a smart makefile in lib/libssl You can get patches to add openssl back into an older dist from http://ftp.snapgear.org/pub/patches/ , newer dists should have patches and download scripts within the makefile to do it for you, Cheers, Davidm -- make[2]: Entering directory `/home/uClinux-dist/user/sh' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/uClinux-dist/user/sh' make[2]: Entering directory `/home/uClinux-dist/user/ssh' (cd openbsd-compat make) make[3]: Entering directory `/home/uClinux-dist/user/ssh/openbsd-compat' ucfront-gcc m68k-elf-gcc -m5200 -DCONFIG_COLDFIRE -Os -g -fomit-frame-pointer -fno-common -fno-builtin -Wall -DEMBED -msep-data -Dlinux -D__linux__ -Dunix -D__uClinux__ -g -O2 -Wall -D_SSH_PROGRAM=\/bin/ssh\ -DSSH_ASKPASS_DEFAULT=\/bin/ssh-askpass\ -I. -DHAVE_CONFIG_H -I. -I..-c -o bsd-arc4random.o bsd-arc4random.c In file included from bsd-arc4random.c:25: ../includes.h:168: openssl/opensslv.h: No such file or directory bsd-arc4random.c:32: openssl/rand.h: No such file or directory bsd-arc4random.c:33: openssl/rc4.h: No such file or directory bsd-arc4random.c:34: openssl/err.h: No such file or directory make[3]: *** [bsd-arc4random.o] Error 1 make[3]: Leaving directory `/home/uClinux-dist/user/ssh/openbsd-compat' make[2]: *** [subdirs] Error 2 make[2]: Leaving directory `/home/uClinux-dist/user/ssh' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/uClinux-dist/user' make: *** [subdirs] Error 1 ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev -- David McCullough, david_mccullo...@securecomputing.com, Ph:+61 734352815 McAfee - SnapGear http://www.snapgear.comhttp://www.uCdot.org ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Problem in dma_map
Hi Ithamar, Ithamar R. Adema wrote: I'm debugging some code where mmap() from userland gets back an invalid address. I traced it down into dma_mmap(), specificly the following piece of code: /* Equivalent to: vma-vm_start = vma-vm_pgoff PAGE_SHIFT; */ ret = remap_pfn_range(vma, vma-vm_start, vma-vm_pgoff, user_size PAGE_SHIFT, vma-vm_page_prot); When I get in here, vma has the following values: vm_start: 0xa114 vm_end: 0xa1166000 vm_pgoff: 0x However, when I get out of dma_map() the values are: vm_start= vm_end=a1166000 vm_pgoff= As you can see, the vm_start address has been clobbered. It seems this is due to the 3 parameter to remap_pfn_range, where vma-vm_pgoff get passed, whilst the documentation of remap_pfn_page suggests this should be a physical address of kernel memory Is this indeed a bug or could it be a misconfiguration/definition in the arch that's wrong? What kernel version is this? Regards Greg Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Problem in dma_map
Dear Greg, Greg Ungerer wrote: As you can see, the vm_start address has been clobbered. It seems this is due to the 3 parameter to remap_pfn_range, where vma-vm_pgoff get passed, whilst the documentation of remap_pfn_page suggests this should be a physical address of kernel memory Is this indeed a bug or could it be a misconfiguration/definition in the arch that's wrong? What kernel version is this? This is kernel 2.6.30.4-uc0, on ARM, using a heavily modified lpc22xx architecture. The buffer is allocated with dma_alloc_writecombine(), as it is a framebuffer. Ithamar. ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Shell exits while running a program.
On Tue, Aug 11, 2009 at 4:58 PM, Jamie Lokier ja...@shareable.org wrote: Jim Donelson wrote: I'd like to see the code for compare_exchange and the lock function. compare_exchange is a single architecture-specific instruction; that's what we're discussing. Lock functions are described in Ulrich Drepper's futex paper. In the context of Drepper's paper, you code looks bugged. You add, not subtract, and you never set mem to 0. The purpose of a spin lock is to avoid a more expensive kernel call if the mutex is released quickly (or not taken at all). Presumably you enter the kernel after n tries and sleep so that you are not using up quanta while spinning. That doesn't work with a single processor. While you are spinning, it's impossible for the other thread to release the mutex until you are preempted, so potential benefit from spinning is marginal and often outweight by the benefit of not spinning. Of course it does - sleeping on a sp means preempt me now. Yes, but *spinning* on a spinlock does not. You propose spinning n times before sleeping. The mutex will only be released during spin time if you are randomly preempted during that short time. Obviously, in the case of an SP, n = 1. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
