From zaphod001 at gmail.com Tue Apr 1 04:41:45 2008 From: zaphod001 at gmail.com (Gery) Date: Tue, 01 Apr 2008 07:41:45 -0400 Subject: ported busybox 1.10.0 segmentation fault In-Reply-To: <200803311651.22435.vda.linux@googlemail.com> References: <47F14E94.40209@gmail.com> <200803311651.22435.vda.linux@googlemail.com> Message-ID: <47F21F79.2030002@gmail.com> Denys Vlasenko wrote: > On Monday 31 March 2008 22:50, Gery wrote: >> Please, help with the issue :) >> >> I made port of bb 1.10.0 on ppc 405 with montavista tools >> >> export ARCH=ppc.405 >> make CROSS_COMPILE=ppc_405- >> make CROSS_COMPILE=ppc_405- install >> >> now from my target with nfs mount did >> cd /mnt/flash/ >> strace ./ls > [snip] > > Do all applets segfault in the same way? E.g. what strace ./true shows? > Also, please post your .config file > -- > vda thank you for help. Here is segfault for true. I believe all applets do it. My config attached also. [/mnt/flash/busybox]$ strace ./true execve("./true", ["./true"], [/* 10 vars */]) = 0 uname({sys="Linux", node="gxk_irp", ...}) = 0 brk(0) = 0x10063000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x30018000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/usr/local/lib/tls/libcrypt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/local/lib/tls", 0x7ffff190) = -1 ENOENT (No such file or directory) open("/usr/local/lib/libcrypt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/local/lib", {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0 open("/etc/ld.so.cache", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/libcrypt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/lib/tls", 0x7ffff190) = -1 ENOENT (No such file or directory) open("/lib/libcrypt.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\0\t"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=30008, ...}) = 0 mmap(0xffb3000, 246336, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xffb3000 mprotect(0xffb8000, 225856, PROT_NONE) = 0 mmap(0xffc3000, 24576, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = 0xffc3000 mmap(0xffc9000, 156224, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xffc9000 close(3) = 0 open("/usr/local/lib/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\1\310"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1222180, ...}) = 0 mmap(0xfe67000, 1292764, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xfe67000 mprotect(0xff88000, 109020, PROT_NONE) = 0 mmap(0xff97000, 40960, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x120000) = 0xff97000 mmap(0xffa1000, 6620, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xffa1000 close(3) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x30019000 mprotect(0xff97000, 24576, PROT_READ) = 0 mprotect(0xffc7000, 4096, PROT_READ) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: .config Url: http://busybox.net/lists/busybox/attachments/20080401/8f5ab178/attachment-0001.txt From G.Schardt at fz-juelich.de Tue Apr 1 08:20:27 2008 From: G.Schardt at fz-juelich.de (Schardt, Georg) Date: Tue, 1 Apr 2008 17:20:27 +0200 Subject: init / console Message-ID: Hi all, first i want to say hello to all of you. i'm a beginner with embedded linux and busybox and i have still many questions and problems :) i use a virtex4fx12 minimodul with an embedded powerpc. u-boot works fine, kernel boots up but output from the busybox init does not appears on the console. i have one uartlite, giving the consol=ttyUL0 command to the kernel. i can see the bootup messages but after the "Freeing unused kernel memory: 104k " message i see only a "lo". it seems that the console dies at this moment. is it possible to use one serial connection for console and a login ? what devices do i need and how does the inittab looks like ? regards georg ------------------------------------------------------------------- ------------------------------------------------------------------- Forschungszentrum J?lich GmbH 52425 J?lich Sitz der Gesellschaft: J?lich Eingetragen im Handelsregister des Amtsgerichts D?ren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in B?rbel Brumme-Bothe Gesch?ftsf?hrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt, Dr. Sebastian M. Schmidt ------------------------------------------------------------------- ------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20080401/4b53ffd4/attachment.htm From khollan at daktronics.com Tue Apr 1 08:35:43 2008 From: khollan at daktronics.com (Kevin Holland) Date: Tue, 01 Apr 2008 10:35:43 -0500 Subject: init / console In-Reply-To: References: Message-ID: <1207064143.6570.3.camel@kevin-laptop> Hi, This is probably not the best forum to ask this question, but try writing out console=ttyUL0, 115200 or whatever your baud rate is. Second what kernel and drivers are you using? For further help I would consult the linuxppc-embedded at ozlabs.org they have lots of xilinx related questions. Here is the link for viewing old messages http://www.nabble.com/linuxppc-embedded-f15994.html Kevin On Tue, 2008-04-01 at 17:20 +0200, Schardt, Georg wrote: > > Hi all, > > first i want to say hello to all of you. i'm a beginner with embedded > linux and busybox and i have still many questions and problems :) > > i use a virtex4fx12 minimodul with an embedded powerpc. u-boot works > fine, kernel boots up but output from the busybox init does not > appears on the console. i have one uartlite, giving the consol=ttyUL0 > command to the kernel. i can see the bootup messages but > after the "Freeing unused kernel memory: 104k " message i see only a > "lo". it seems that the console dies at this moment. > > is it possible to use one serial connection for console and a login ? > what devices do i need and how does the inittab looks like ? > > regards > georg > > > > > > > > --------------------------------------------------------------- > ----------------- > ------------------------------------------------------- > ------------------------- > Forschungszentrum J?lich GmbH > 52425 J?lich > > Sitz der Gesellschaft: J?lich > Eingetragen im Handelsregister des Amtsgerichts D?ren Nr. HR B 3498 > Vorsitzende des Aufsichtsrats: MinDir'in B?rbel Brumme-Bothe > Gesch?ftsf&u uml;hrung: Prof. Dr. Achim Bachem (Vorsitzender), > Dr. Ulrich Krafft (ste llv. Vorsitzender), Prof. Dr. Harald Bolt, > Dr. Sebastian M. Schmidt > - > ---------------------------------------------------------------------------- --- > --------------------------------------------------------------------- > ----------- > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://busybox.net/cgi-bin/mailman/listinfo/busybox From dronnikov at gmail.com Tue Apr 1 10:32:52 2008 From: dronnikov at gmail.com (dronnikov at gmail.com) Date: Tue, 01 Apr 2008 10:32:52 -0700 (PDT) Subject: =?utf-8?B?eGZ1bmNfZGllOiB3aGVyZSBpcyBpdD8=?= Message-ID: <47f271c4.0216300a.5cc8.0e0b@mx.google.com> Hello! Where has xfunc_die() gone?! -- Vladimir From vda.linux at googlemail.com Tue Apr 1 10:44:26 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 1 Apr 2008 19:44:26 +0200 Subject: xfunc_die: where is it? In-Reply-To: <47f271c4.0216300a.5cc8.0e0b@mx.google.com> References: <47f271c4.0216300a.5cc8.0e0b@mx.google.com> Message-ID: <200804011944.26060.vda.linux@googlemail.com> On Tuesday 01 April 2008 19:32, dronnikov at gmail.com wrote: > Where has xfunc_die() gone?! In the interest of increasing reliability of busybox, dying unexpectedly is not allowed from now on. -- vda From somlo at cmu.edu Tue Apr 1 14:09:18 2008 From: somlo at cmu.edu (L. Gabriel Somlo) Date: Tue, 1 Apr 2008 17:09:18 -0400 Subject: PATCH: udhcpc -- don't request set of options by default Message-ID: <20080401210918.GB12632@hedwig.net.cmu.edu> Denys & All, I noticed that udhcpc sends a default list of options in its request (i.e., all options listed with flag OPTION_REQ in options.c) That's bad, at least when used with some versions of isc dhcpd, which will only include the requested options in a reply. I know about the -O flag that can get udhcpc to request extra options, but what if I want to see options I didn't think about asking for ? Including a default option list in the request will always preclude me from seeing options I didn't know to ask for. I've added the '-o' command line flag to udhcpc, which inhibits inclusion of default options in the request. Options can still be explicitly requested with -O. I have also added a mechanism to request '-o' (actually, its long form --no-default-options) from ifupdown's /etc/network/interfaces: auto eth0 iface eth0 inet dhcp nodefaultopts --no-default-options Last, but not least, a slightly more complex sample udhcpc.script, which attempts to react to changes in parameters returned by the dhcp server in a minimal-effort sort of way (i.e. don't reconfigure the interface if the only change was in the list of ntp servers, etc.) Please note that I did not change anything in the default behavior, although I'd like to propose that udhcpc should not ask for a default list of options unless we explicitly tell it to do so... Please let me know what you think, and apply if you agree. Regards, --Gabriel -------------- next part -------------- diff -NarU5 busybox-svn-21617.orig/examples/udhcp/udhcpc.script busybox-svn-21617/examples/udhcp/udhcpc.script --- busybox-svn-21617.orig/examples/udhcp/udhcpc.script 1969-12-31 19:00:00.000000000 -0500 +++ busybox-svn-21617/examples/udhcp/udhcpc.script 2008-04-01 16:25:24.000000000 -0400 @@ -0,0 +1,88 @@ +#!/bin/busybox sh + +# a more "complex" udhcpc script that attempts to handle option changes with minimal work +# Gabriel Somlo , 04/01/2008 + +[ -z "$1" ] && echo 'Error: should be called from udhcpc' && exit 1 + +CFG="/var/run/udhcpc.${interface}.cfg" +RESOLV_CONF='/etc/resolv.conf' +NTP_CONF='/etc/ntp.conf' +# which interface configures DNS and NTP ? Comment out if none: +PEERDNS_IF=eth0 +PEERNTP_IF=eth0 + +case "$1" in + deconfig) + ip addr flush dev $interface + ip link set up dev $interface + rm -f $CFG + if [ "$PEERDNS_IF" == "$interface" ] ; then + [ -f ${RESOLV_CONF}.dhcsave ] && mv -f ${RESOLV_CONF}.dhcsave $RESOLV_CONF + fi + if [ "$PEERNTP_IF" == "$interface" ] ; then + [ -f ${NTP_CONF}.dhcsave ] && mv -f ${NTP_CONF}.dhcsave $NTP_CONF + fi + ;; + bound) + set > $CFG + ip addr flush dev $interface + [ -n "$mtu" ] && ip link set mtu $mtu dev $interface + ip addr add ${ip}/${mask} dev $interface + [ -n "$router" ] && ip route add default via ${router%% *} dev $interface + if [ "$PEERDNS_IF" == "$interface" ] ; then + [ -f $RESOLV_CONF ] && mv -f $RESOLV_CONF ${RESOLV_CONF}.dhcsave + [ -n "$domain" ] && echo search $domain > $RESOLV_CONF + for i in $dns ; do + echo nameserver $i >> $RESOLV_CONF + done + fi + if [ "$PEERNTP_IF" == "$interface" ] ; then + [ -f $NTP_CONF ] && mv -f $NTP_CONF ${NTP_CONF}.dhcsave + > $NTP_CONF + for i in $ntpsrv ; do + echo server $i >> $NTP_CONF + done + fi + ;; + renew) + set > ${CFG}.new + for i in $(diff -U1 $CFG ${CFG}.new | grep -E ^[+-] \ + | tail +3 \ + | awk -F[+-=] '{print $2}') ; do + case "$i" in + ip|mask|router|mtu) + REDO_NET='yes' + ;; + domain|dns) + REDO_DNS='yes' + ;; + ntpsrv) + REDO_NTP='yes' + ;; + esac + done + mv -f ${CFG}.new $CFG + if [ -n "$REDO_NET" ] ; then + ip addr flush dev $interface + [ -n "$mtu" ] && ip link set mtu $mtu dev $interface + ip addr add ${ip}/${mask} dev $interface + [ -n "$router" ] && ip route add default via ${router%% *} dev $interface + fi + if [ -n "$REDO_DNS" -a "$PEERDNS_IF" == "$interface" ] ; then + [ -n "$domain" ] && echo search $domain > $RESOLV_CONF + for i in $dns ; do + echo nameserver $i >> $RESOLV_CONF + done + fi + if [ -n "$REDO_NTP" -a "$PEERNTP_IF" == "$interface" ] ; then + > $NTP_CONF + for i in $ntpsrv ; do + echo server $i >> $NTP_CONF + done + # FIXME: RELOAD NTP DAEMON HERE + fi + ;; +esac + +exit 0 diff -NarU5 busybox-svn-21617.orig/include/usage.h busybox-svn-21617/include/usage.h --- busybox-svn-21617.orig/include/usage.h 2008-04-01 14:47:29.000000000 -0400 +++ busybox-svn-21617/include/usage.h 2008-04-01 15:20:40.000000000 -0400 @@ -4114,11 +4114,11 @@ "[-T last-check-time] [-U UUID] device" #define tune2fs_full_usage \ "Adjust filesystem options on ext[23] filesystems" #define udhcpc_trivial_usage \ - "[-Cfbnqtv] [-c CID] [-V VCLS] [-H HOSTNAME] [-i INTERFACE]\n" \ + "[-Cfbnqtvo] [-c CID] [-V VCLS] [-H HOSTNAME] [-i INTERFACE]\n" \ " [-p pidfile] [-r IP] [-s script] [-O dhcp-option]..." USE_FEATURE_UDHCP_PORT(" [-P N]") #define udhcpc_full_usage \ USE_GETOPT_LONG( \ " -V,--vendorclass=CLASSID Vendor class identifier" \ "\n -i,--interface=INTERFACE Interface to use (default eth0)" \ @@ -4142,10 +4142,11 @@ "\n -P,--client-port N Use port N instead of default 68" \ ) \ USE_FEATURE_UDHCPC_ARPING( \ "\n -a,--arping Use arping to validate offered address" \ ) \ + "\n -o,--no-default-options Do not request options by default" \ ) \ SKIP_GETOPT_LONG( \ " -V CLASSID Vendor class identifier" \ "\n -i INTERFACE Interface to use (default: eth0)" \ "\n -H,-h HOSTNAME Client hostname" \ diff -NarU5 busybox-svn-21617.orig/networking/ifupdown.c busybox-svn-21617/networking/ifupdown.c --- busybox-svn-21617.orig/networking/ifupdown.c 2008-04-01 14:47:25.000000000 -0400 +++ busybox-svn-21617/networking/ifupdown.c 2008-04-01 16:09:02.000000000 -0400 @@ -474,11 +474,11 @@ { "pump", "pump -i %iface%[[ -h %hostname%]][[ -l %leasehours%]]", "pump -i %iface% -k", }, { "udhcpc", - "udhcpc -R -n -p /var/run/udhcpc.%iface%.pid -i %iface%[[ -H %hostname%]][[ -c %clientid%]][[ -s %script%]][[ -t %retries%]]", + "udhcpc -R -n -p /var/run/udhcpc.%iface%.pid -i %iface%[[ -H %hostname%]][[ -c %clientid%]][[ -s %script%]][[ -t %retries%]][[ %nodefaultopts%]]", "kill `cat /var/run/udhcpc.%iface%.pid` 2>/dev/null", }, }; #endif /* ENABLE_FEATURE_IFUPDOWN_EXTERNAL_DHCPC */ @@ -505,11 +505,11 @@ /* ip doesn't up iface when it configures it (unlike ifconfig) */ if (!execute("ip link set %iface% up", ifd, exec)) return 0; #endif return execute("udhcpc -R -n -p /var/run/udhcpc.%iface%.pid " - "-i %iface%[[ -H %hostname%]][[ -c %clientid%]][[ -s %script%]][[ -t %retries%]]", + "-i %iface%[[ -H %hostname%]][[ -c %clientid%]][[ -s %script%]][[ -t %retries%]][[ %nodefaultopts%]]", ifd, exec); } #else static int dhcp_up(struct interface_defn_t *ifd ATTRIBUTE_UNUSED, execfn *exec ATTRIBUTE_UNUSED) diff -NarU5 busybox-svn-21617.orig/networking/udhcp/clientpacket.c busybox-svn-21617/networking/udhcp/clientpacket.c --- busybox-svn-21617.orig/networking/udhcp/clientpacket.c 2008-04-01 14:47:25.000000000 -0400 +++ busybox-svn-21617/networking/udhcp/clientpacket.c 2008-04-01 15:04:18.000000000 -0400 @@ -62,11 +62,11 @@ int end = end_option(packet->options); int i, len = 0; packet->options[end + OPT_CODE] = DHCP_PARAM_REQ; for (i = 0; (c = dhcp_options[i].code) != 0; i++) { - if ((dhcp_options[i].flags & OPTION_REQ) + if (((dhcp_options[i].flags & OPTION_REQ) && !client_config.no_default_options) || (client_config.opt_mask[c >> 3] & (1 << (c & 7))) ) { packet->options[end + OPT_DATA + len] = c; len++; } diff -NarU5 busybox-svn-21617.orig/networking/udhcp/dhcpc.c busybox-svn-21617/networking/udhcp/dhcpc.c --- busybox-svn-21617.orig/networking/udhcp/dhcpc.c 2008-04-01 14:47:25.000000000 -0400 +++ busybox-svn-21617/networking/udhcp/dhcpc.c 2008-04-01 15:01:01.000000000 -0400 @@ -180,10 +180,11 @@ #if ENABLE_FEATURE_UDHCPC_ARPING OPT_a = 1 << 20, OPT_W = 1 << 21, #endif OPT_P = 1 << 22, + OPT_o = 1 << 23, }; #if ENABLE_GETOPT_LONG static const char udhcpc_longopts[] ALIGN1 = "clientid\0" Required_argument "c" "clientid-none\0" No_argument "C" @@ -209,10 +210,11 @@ #endif "request-option\0" Required_argument "O" #if ENABLE_FEATURE_UDHCP_PORT "client-port\0" Required_argument "P" #endif + "no-default-options\0" No_argument "o" ; #endif /* Default options. */ #if ENABLE_FEATURE_UDHCP_PORT SERVER_PORT = 67; @@ -228,11 +230,11 @@ applet_long_options = udhcpc_longopts; #endif opt = getopt32(argv, "c:CV:fbH:h:F:i:np:qRr:s:T:t:vSA:" USE_FEATURE_UDHCPC_ARPING("aW:") USE_FEATURE_UDHCP_PORT("P:") - "O:" + "O:o:" , &str_c, &str_V, &str_h, &str_h, &str_F , &client_config.interface, &client_config.pidfile, &str_r , &client_config.script , &discover_timeout, &discover_retries, &tryagain_timeout USE_FEATURE_UDHCPC_ARPING(, &str_W) @@ -289,10 +291,12 @@ if (opt & OPT_P) { CLIENT_PORT = xatou16(str_P); SERVER_PORT = CLIENT_PORT - 1; } #endif + if (opt & OPT_o) + client_config.no_default_options = 1; while (list_O) { int n = index_in_strings(dhcp_option_strings, list_O->data); if (n < 0) bb_error_msg_and_die("unknown option '%s'", list_O->data); n = dhcp_options[n].code; diff -NarU5 busybox-svn-21617.orig/networking/udhcp/dhcpc.h busybox-svn-21617/networking/udhcp/dhcpc.h --- busybox-svn-21617.orig/networking/udhcp/dhcpc.h 2008-04-01 14:47:25.000000000 -0400 +++ busybox-svn-21617/networking/udhcp/dhcpc.h 2008-04-01 14:56:12.000000000 -0400 @@ -19,10 +19,11 @@ char foreground; /* Do not fork */ char quit_after_lease; /* Quit after obtaining lease */ char release_on_quit; /* Perform release on quit */ char abort_if_no_lease; /* Abort if no lease */ char background_if_no_lease; /* Fork to background if no lease */ + char no_default_options; /* Do not include default optins in request */ const char *interface; /* The name of the interface to use */ char *pidfile; /* Optionally store the process ID */ const char *script; /* User script to run at dhcp events */ uint8_t *clientid; /* Optional client id to use */ uint8_t *vendorclass; /* Optional vendor class-id to use */ From harald-tuxbox at arcor.de Tue Apr 1 14:41:23 2008 From: harald-tuxbox at arcor.de (Harald Kuethe) Date: Tue, 1 Apr 2008 23:41:23 +0200 Subject: [PATCH] init.c, halt command not working References: <47EFFC15.5040706@arcor.de> <47F142A8.70805@arcor.de> <200803312152.14808.vda.linux@googlemail.com> Message-ID: <001301c89441$2666de40$0a02a8c0@houdinineu> > ----- Original Message ----- > From: "Denys Vlasenko" > To: > Cc: "Harald K?the" > Sent: Monday, March 31, 2008 9:52 PM > Subject: Re: [PATCH] init.c, halt command not working > On Monday 31 March 2008 21:59, Harald K?the wrote: > > > The sequence of events is: > > > SIGUSR1 is received > > > halt_reboot_pwoff(SIGUSR1) calls > > > kill_all_processes() calls > > > run_actions(SHUTDOWN): > > > if (a->action_type & (SYSINIT | WAIT | > > CTRLALTDEL | SHUTDOWN | RESTART)) { > > > waitfor(run(a)); > > > delete_init_action(a); > > > run(a) vforks... and this is somehow doesn't work very well > > > > It looks as if SIGUSR1 is !!not!! received because halt_reboot_pwoff() > > is not processed. > Please confirm that you added a debug printout to > halt_reboot_pwoff and it is not triggering when halt > sends SIGUSR1 to init. Yes, confirmed! > In this case, can you do this change int init.c: > static pid_t run(const struct init_action *a) > { > ... > if (pid) > +{ > + bb_signals(0 > + + (1 << SIGUSR1) /* halt */ > + + (1 << SIGUSR2) /* poweroff */ > + + (1 << SIGTERM) /* reboot */ > + , halt_reboot_pwoff); > return pid; > +} > Basically, it restores SIGUSR1 handling in the parent > after child sets it to SIG_DFL. > Does this fix things? No, it stays the same. > -- > vda One interesting thing is that a lets the system shut down and restart. Regards Harald From vda.linux at googlemail.com Tue Apr 1 14:51:58 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 1 Apr 2008 23:51:58 +0200 Subject: [PATCH] init.c, halt command not working In-Reply-To: <001301c89441$2666de40$0a02a8c0@houdinineu> References: <47EFFC15.5040706@arcor.de> <200803312152.14808.vda.linux@googlemail.com> <001301c89441$2666de40$0a02a8c0@houdinineu> Message-ID: <200804012351.58135.vda.linux@googlemail.com> On Tuesday 01 April 2008 23:41, Harald Kuethe wrote: > > ----- Original Message ----- > > From: "Denys Vlasenko" > > To: > > Cc: "Harald K?the" > > Sent: Monday, March 31, 2008 9:52 PM > > Subject: Re: [PATCH] init.c, halt command not working > > > > On Monday 31 March 2008 21:59, Harald K?the wrote: > > > > The sequence of events is: > > > > SIGUSR1 is received > > > > halt_reboot_pwoff(SIGUSR1) calls > > > > kill_all_processes() calls > > > > run_actions(SHUTDOWN): > > > > if (a->action_type & (SYSINIT | WAIT | > > > CTRLALTDEL | SHUTDOWN | RESTART)) { > > > > waitfor(run(a)); > > > > delete_init_action(a); > > > > run(a) vforks... and this is somehow doesn't work very well > > > > > > It looks as if SIGUSR1 is !!not!! received because halt_reboot_pwoff() > > > is not processed. > > > Please confirm that you added a debug printout to > > halt_reboot_pwoff and it is not triggering when halt > > sends SIGUSR1 to init. > > Yes, confirmed! And also it doesn't trigger when you send signal by hand - "kill -USR1 1" ? -- vda From vda.linux at googlemail.com Tue Apr 1 15:14:14 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Wed, 2 Apr 2008 00:14:14 +0200 Subject: PATCH: udhcpc -- don't request set of options by default In-Reply-To: <20080401210918.GB12632@hedwig.net.cmu.edu> References: <20080401210918.GB12632@hedwig.net.cmu.edu> Message-ID: <200804020014.14424.vda.linux@googlemail.com> On Tuesday 01 April 2008 23:09, L. Gabriel Somlo wrote: > Last, but not least, a slightly more complex sample udhcpc.script, > which attempts to react to changes in parameters returned by the dhcp > server in a minimal-effort sort of way (i.e. don't reconfigure the > interface if the only change was in the list of ntp servers, etc.) Imagine that I have *two* interfaces, both sit on DHCP configured networks (*different* networks). Here one "deconfig"-ed iface will happily nuke /etc/resolv.conf created by another interface: +case "$1" in + deconfig) + ip addr flush dev $interface + ip link set up dev $interface + rm -f $CFG + if [ "$PEERDNS_IF" == "$interface" ] ; then + [ -f ${RESOLV_CONF}.dhcsave ] && mv -f ${RESOLV_CONF}.dhcsave $RESOLV_CONF + fi + if [ "$PEERNTP_IF" == "$interface" ] ; then + [ -f ${NTP_CONF}.dhcsave ] && mv -f ${NTP_CONF}.dhcsave $NTP_CONF + fi + ;; + bound) + set > $CFG + ip addr flush dev $interface + [ -n "$mtu" ] && ip link set mtu $mtu dev $interface + ip addr add ${ip}/${mask} dev $interface + [ -n "$router" ] && ip route add default via ${router%% *} dev $interface + if [ "$PEERDNS_IF" == "$interface" ] ; then + [ -f $RESOLV_CONF ] && mv -f $RESOLV_CONF ${RESOLV_CONF}.dhcsave + [ -n "$domain" ] && echo search $domain > $RESOLV_CONF + for i in $dns ; do + echo nameserver $i >> $RESOLV_CONF + done + fi Attempt to correctly express configurational logic in dhcp scripts is doomed to fail IMO. It will only get more and more contrived when you try to cater for more and more weird races. I tried to explain it here: http://busybox.net/~vda/no_ifup.txt -- vda From somlo at cmu.edu Tue Apr 1 15:37:38 2008 From: somlo at cmu.edu (L. Gabriel Somlo) Date: Tue, 1 Apr 2008 18:37:38 -0400 Subject: PATCH: udhcpc -- don't request set of options by default In-Reply-To: <200804020014.14424.vda.linux@googlemail.com> References: <20080401210918.GB12632@hedwig.net.cmu.edu> <200804020014.14424.vda.linux@googlemail.com> Message-ID: <20080401223738.GE12632@hedwig.net.cmu.edu> On Wed, Apr 02, 2008 at 12:14:14AM +0200, Denys Vlasenko wrote: > On Tuesday 01 April 2008 23:09, L. Gabriel Somlo wrote: > > Last, but not least, a slightly more complex sample udhcpc.script, > > which attempts to react to changes in parameters returned by the dhcp > > server in a minimal-effort sort of way (i.e. don't reconfigure the > > interface if the only change was in the list of ntp servers, etc.) > > Imagine that I have *two* interfaces, both sit on DHCP configured > networks (*different* networks). > Here one "deconfig"-ed iface will happily nuke /etc/resolv.conf > created by another interface: I agree with your no_ifup blurb in principle. However, this is not about ifupdown at all (adding a way to pass no-default-options to udhcpc from ifupdown was an afterthought since I happen to use ifupdown, but totally unrelated to the udhcpc sample script). The real question is, who "wins" w.r.t. /etc/resolv.conf when multiple dhcp-configured interfaces are up simultaneously ? This is already a fun problem for laptops that connect both on wireless and on wired ethernet, and it's a trainwreck, ifupdown or not... > +case "$1" in > + deconfig) > + if [ "$PEERDNS_IF" == "$interface" ] ; then > + [ -f ${RESOLV_CONF}.dhcsave ] && mv -f ${RESOLV_CONF}.dhcsave $RESOLV_CONF > + fi > + if [ "$PEERNTP_IF" == "$interface" ] ; then > + [ -f ${NTP_CONF}.dhcsave ] && mv -f ${NTP_CONF}.dhcsave $NTP_CONF > + fi In my udhcpc.script sample I declare an interface to be the "owner" of resolv.conf (e.g. PEERDNS_IF=eth0), and only when eth0 goes down does resolv.conf get nuked. Deconfig-ing eth1 doesn't do anything to resolv.conf. This does have its own drawbacks, for sure, but we first need to have a rule about what what happens in this scenario: - eth0 comes up - we request a dhcp lease, and receive back a bunch of stuff (e.g. nameservers) - we populate /etc/resolv.conf with these nameservers - now, while eth0 stays up, eth1 comes up also - we request a dhcp lease for eth1, and receive back a bunch of stuff (including a *different* set of nameservers) - ??? Do we overwrite resolv.conf, or do we add the new nameservers to the list (and if we add them, where, at the front or back of the list ?) If we add them to the front, it's almost like we overwrote resolv.conf (the new nameserver gets queried for *everything* with precendence). If we add to the back, it's like we didn't overwrite resolv.conf at all (eth0's nameserver gets queried for *everything* with precedence). So, what I'm trying to say, this is not really an ifupdown is bad/good/ugly problem, but rather "how do we reconcile information received via dhcp on multiple interfaces?"; My (yes, possibly flawed) answer was "hardcode a winner", but what's the right thing to do ? Thanks, Gabriel PS. Here's a simplified patch that only addresses the '-o' or '--no-default-options' change to udhcpc, leaving out ifupdown and the sample udhcpc.script, since they are really totally separate issues. Please apply this one while we figure out what to do with resolv.conf :) -------------- next part -------------- diff -NarU5 busybox-svn-21617.orig/include/usage.h busybox-svn-21617/include/usage.h --- busybox-svn-21617.orig/include/usage.h 2008-04-01 14:47:29.000000000 -0400 +++ busybox-svn-21617/include/usage.h 2008-04-01 15:20:40.000000000 -0400 @@ -4114,11 +4114,11 @@ "[-T last-check-time] [-U UUID] device" #define tune2fs_full_usage \ "Adjust filesystem options on ext[23] filesystems" #define udhcpc_trivial_usage \ - "[-Cfbnqtv] [-c CID] [-V VCLS] [-H HOSTNAME] [-i INTERFACE]\n" \ + "[-Cfbnqtvo] [-c CID] [-V VCLS] [-H HOSTNAME] [-i INTERFACE]\n" \ " [-p pidfile] [-r IP] [-s script] [-O dhcp-option]..." USE_FEATURE_UDHCP_PORT(" [-P N]") #define udhcpc_full_usage \ USE_GETOPT_LONG( \ " -V,--vendorclass=CLASSID Vendor class identifier" \ "\n -i,--interface=INTERFACE Interface to use (default eth0)" \ @@ -4142,10 +4142,11 @@ "\n -P,--client-port N Use port N instead of default 68" \ ) \ USE_FEATURE_UDHCPC_ARPING( \ "\n -a,--arping Use arping to validate offered address" \ ) \ + "\n -o,--no-default-options Do not request options by default" \ ) \ SKIP_GETOPT_LONG( \ " -V CLASSID Vendor class identifier" \ "\n -i INTERFACE Interface to use (default: eth0)" \ "\n -H,-h HOSTNAME Client hostname" \ diff -NarU5 busybox-svn-21617.orig/networking/udhcp/clientpacket.c busybox-svn-21617/networking/udhcp/clientpacket.c --- busybox-svn-21617.orig/networking/udhcp/clientpacket.c 2008-04-01 14:47:25.000000000 -0400 +++ busybox-svn-21617/networking/udhcp/clientpacket.c 2008-04-01 15:04:18.000000000 -0400 @@ -62,11 +62,11 @@ int end = end_option(packet->options); int i, len = 0; packet->options[end + OPT_CODE] = DHCP_PARAM_REQ; for (i = 0; (c = dhcp_options[i].code) != 0; i++) { - if ((dhcp_options[i].flags & OPTION_REQ) + if (((dhcp_options[i].flags & OPTION_REQ) && !client_config.no_default_options) || (client_config.opt_mask[c >> 3] & (1 << (c & 7))) ) { packet->options[end + OPT_DATA + len] = c; len++; } diff -NarU5 busybox-svn-21617.orig/networking/udhcp/dhcpc.c busybox-svn-21617/networking/udhcp/dhcpc.c --- busybox-svn-21617.orig/networking/udhcp/dhcpc.c 2008-04-01 14:47:25.000000000 -0400 +++ busybox-svn-21617/networking/udhcp/dhcpc.c 2008-04-01 15:01:01.000000000 -0400 @@ -180,10 +180,11 @@ #if ENABLE_FEATURE_UDHCPC_ARPING OPT_a = 1 << 20, OPT_W = 1 << 21, #endif OPT_P = 1 << 22, + OPT_o = 1 << 23, }; #if ENABLE_GETOPT_LONG static const char udhcpc_longopts[] ALIGN1 = "clientid\0" Required_argument "c" "clientid-none\0" No_argument "C" @@ -209,10 +210,11 @@ #endif "request-option\0" Required_argument "O" #if ENABLE_FEATURE_UDHCP_PORT "client-port\0" Required_argument "P" #endif + "no-default-options\0" No_argument "o" ; #endif /* Default options. */ #if ENABLE_FEATURE_UDHCP_PORT SERVER_PORT = 67; @@ -228,11 +230,11 @@ applet_long_options = udhcpc_longopts; #endif opt = getopt32(argv, "c:CV:fbH:h:F:i:np:qRr:s:T:t:vSA:" USE_FEATURE_UDHCPC_ARPING("aW:") USE_FEATURE_UDHCP_PORT("P:") - "O:" + "O:o:" , &str_c, &str_V, &str_h, &str_h, &str_F , &client_config.interface, &client_config.pidfile, &str_r , &client_config.script , &discover_timeout, &discover_retries, &tryagain_timeout USE_FEATURE_UDHCPC_ARPING(, &str_W) @@ -289,10 +291,12 @@ if (opt & OPT_P) { CLIENT_PORT = xatou16(str_P); SERVER_PORT = CLIENT_PORT - 1; } #endif + if (opt & OPT_o) + client_config.no_default_options = 1; while (list_O) { int n = index_in_strings(dhcp_option_strings, list_O->data); if (n < 0) bb_error_msg_and_die("unknown option '%s'", list_O->data); n = dhcp_options[n].code; diff -NarU5 busybox-svn-21617.orig/networking/udhcp/dhcpc.h busybox-svn-21617/networking/udhcp/dhcpc.h --- busybox-svn-21617.orig/networking/udhcp/dhcpc.h 2008-04-01 14:47:25.000000000 -0400 +++ busybox-svn-21617/networking/udhcp/dhcpc.h 2008-04-01 14:56:12.000000000 -0400 @@ -19,10 +19,11 @@ char foreground; /* Do not fork */ char quit_after_lease; /* Quit after obtaining lease */ char release_on_quit; /* Perform release on quit */ char abort_if_no_lease; /* Abort if no lease */ char background_if_no_lease; /* Fork to background if no lease */ + char no_default_options; /* Do not include default optins in request */ const char *interface; /* The name of the interface to use */ char *pidfile; /* Optionally store the process ID */ const char *script; /* User script to run at dhcp events */ uint8_t *clientid; /* Optional client id to use */ uint8_t *vendorclass; /* Optional vendor class-id to use */ From vda.linux at googlemail.com Tue Apr 1 16:11:02 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Wed, 2 Apr 2008 01:11:02 +0200 Subject: PATCH: udhcpc -- don't request set of options by default In-Reply-To: <20080401223738.GE12632@hedwig.net.cmu.edu> References: <20080401210918.GB12632@hedwig.net.cmu.edu> <200804020014.14424.vda.linux@googlemail.com> <20080401223738.GE12632@hedwig.net.cmu.edu> Message-ID: <200804020111.02151.vda.linux@googlemail.com> On Wednesday 02 April 2008 00:37, L. Gabriel Somlo wrote: > I agree with your no_ifup blurb in principle. However, this is not > about ifupdown at all (adding a way to pass no-default-options to > udhcpc from ifupdown was an afterthought since I happen to use > ifupdown, but totally unrelated to the udhcpc sample script). > > The real question is, who "wins" w.r.t. /etc/resolv.conf when multiple > dhcp-configured interfaces are up simultaneously ? This is already a > fun problem for laptops that connect both on wireless and on wired > ethernet, and it's a trainwreck, ifupdown or not... I though I explained it on that page... my DHCP client's script basically just dumps obtained into in a file in this form: /var/run/service/fw/dhcp_if.ipconf ============== let cfg=cfg+1 if[$cfg]='if' ip[$cfg]='89.102.207.196' ipmask[$cfg]='89.102.207.196/24' gw[$cfg]='89.102.207.1' dns[$cfg]='213.46.172.36 213.46.172.37' net[$cfg]='0/0' and then executes "sv u /var/service/fw" (sv is a busybox applet, works in concert with runsv). /var/service/fw is a runsv-controlled service with service script which starts as: /var/service/fw/run: =================== #!/bin/sh # Make ourself one-shot sv o . <================ CRUCIAL ... I will omit the details. Important things are: * /var/service/fw/run is ran _anytime_ network config is changed, and it sees _entire_ config state. For example, it can go through /var/run/service/fw/*.ipconf files and find out ALL INTERFACES' addresses; this does not cover only dhcp, but pppd, openvpn, you name it (and of course static ones). * this script cat decide _globally_ what to write to /etc/resolv.conf [and there is no need to save it], what will be set as default route, how to configure DNS, NTP, firewall, trafic shaping, etc.... * Execution of /var/service/fw/run is _serialized_ (by nature how "sv u" + "sv o" interact). If many dhcpc's, openvpn's, pppd's etc are racing to run it, it can be executed several times, but NEVER IN PARALLEL. (basically, if e.g. openvpn does "sv u /var/service/fw" while it still runs because of earlier dhcp config, it will rerun again... ...and set itself to "one shot, do not rerun until 'sv upped' again" mode with that "sv o ." cmd). Yes, the script can get complex, but it does not need to worry about races, and therefore conceptually it is simple: * Lets take a look at the state of ALL links and decide what to do. * Deconfigure everything: ip a f dev $EVERY_IF ip r f dev $EVERY_IF root 0/0 iptables --flush iptables --delete-chain iptables -t nat --flush iptables -t nat --delete-chain iptables -t mangle --flush iptables -t mangle --delete-chain ... * Configure everything back. You can try and play with "if changes are small, dont deconf everything" but I don't find it useful - script gets more complex. -- vda From vda.linux at googlemail.com Tue Apr 1 16:25:51 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Wed, 2 Apr 2008 01:25:51 +0200 Subject: PATCH: udhcpc -- don't request set of options by default In-Reply-To: <20080401223738.GE12632@hedwig.net.cmu.edu> References: <20080401210918.GB12632@hedwig.net.cmu.edu> <200804020014.14424.vda.linux@googlemail.com> <20080401223738.GE12632@hedwig.net.cmu.edu> Message-ID: <200804020125.51546.vda.linux@googlemail.com> On Wednesday 02 April 2008 00:37, L. Gabriel Somlo wrote: > In my udhcpc.script sample I declare an interface to be the "owner" of > resolv.conf (e.g. PEERDNS_IF=eth0), and only when eth0 goes down does > resolv.conf get nuked. Deconfig-ing eth1 doesn't do anything to > resolv.conf. > > This does have its own drawbacks, for sure, but we first need to have > a rule about what what happens in this scenario: > > - eth0 comes up > - we request a dhcp lease, and receive back a bunch of stuff (e.g. > nameservers) > - we populate /etc/resolv.conf with these nameservers > - now, while eth0 stays up, eth1 comes up also > - we request a dhcp lease for eth1, and receive back a bunch of stuff > (including a *different* set of nameservers) > - ??? > > Do we overwrite resolv.conf, or do we add the new nameservers to the > list (and if we add them, where, at the front or back of the list ?) > > If we add them to the front, it's almost like we overwrote resolv.conf > (the new nameserver gets queried for *everything* with precendence). > If we add to the back, it's like we didn't overwrite resolv.conf at > all (eth0's nameserver gets queried for *everything* with precedence). > > So, what I'm trying to say, this is not really an ifupdown is > bad/good/ugly problem, but rather "how do we reconcile information > received via dhcp on multiple interfaces?"; My (yes, possibly flawed) > answer was "hardcode a winner", but what's the right thing to do ? To completely rewrite /etc/resolv.conf when either of eth0/1/99 changes state, taking in consideration the state of all links. No appending, prependind or parsing of /etc/resolv.conf is necessary. Just regenerate it. It should be possible, because you have all necessary data to decide. How to break ties is an admin task, and it's usually easy: "I prefer eth3" or "I prefer ppp0". However I can imagine some people will even want to set up multipath routing if many links are up. -- vda From vda.linux at googlemail.com Tue Apr 1 16:51:08 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Wed, 2 Apr 2008 01:51:08 +0200 Subject: PATCH: udhcpc -- don't request set of options by default In-Reply-To: <20080401210918.GB12632@hedwig.net.cmu.edu> References: <20080401210918.GB12632@hedwig.net.cmu.edu> Message-ID: <200804020151.08059.vda.linux@googlemail.com> On Tuesday 01 April 2008 23:09, L. Gabriel Somlo wrote: > Denys & All, > > I noticed that udhcpc sends a default list of options in its request > (i.e., all options listed with flag OPTION_REQ in options.c) > > That's bad, at least when used with some versions of isc dhcpd, which > will only include the requested options in a reply. > > I know about the -O flag that can get udhcpc to request extra options, > but what if I want to see options I didn't think about asking for ? > Including a default option list in the request will always preclude me > from seeing options I didn't know to ask for. USE_FEATURE_UDHCPC_ARPING( \ "\n -a,--arping Use arping to validate offered address" \ ) \ + "\n -o,--no-default-options Do not request options by default" \ ) \ SKIP_GETOPT_LONG( \ SKIP_GETOPT_LONG case also needs -o covered. - "O:" + "O:o:" -o does not take a param, should be "O:o". packet->options[end + OPT_CODE] = DHCP_PARAM_REQ; for (i = 0; (c = dhcp_options[i].code) != 0; i++) { - if ((dhcp_options[i].flags & OPTION_REQ) + if (((dhcp_options[i].flags & OPTION_REQ) && !client_config.no_default_options) //vda || (client_config.opt_mask[c >> 3] & (1 << (c & 7))) ) { packet->options[end + OPT_DATA + len] = c; len++; } so, you create "empty" DHCP_PARAM_REQ. Why not just omitting it at all like this? - add_param_req_option(&packet); + if (!client_config.no_default_options) + add_param_req_option(&packet); > I've added the '-o' command line flag to udhcpc, which inhibits > inclusion of default options in the request. Options can still be > explicitly requested with -O. I am thinking - maybe we should just junk the idea of "default" options to ask for? We can ask user to always provide explicit list of -O OPTs to ask. What do you think? > I have also added a mechanism to request '-o' (actually, its long form > --no-default-options) from ifupdown's /etc/network/interfaces: > > auto eth0 > iface eth0 inet dhcp > nodefaultopts --no-default-options Please take a look at attached patch - will this work for you? -- vda -------------- next part -------------- A non-text attachment was scrubbed... Name: 4.patch Type: text/x-diff Size: 6718 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080402/d7f5b6d6/attachment.patch From somlo at cmu.edu Tue Apr 1 17:58:37 2008 From: somlo at cmu.edu (L. Gabriel Somlo) Date: Tue, 1 Apr 2008 20:58:37 -0400 Subject: PATCH: udhcpc -- don't request set of options by default In-Reply-To: <200804020151.08059.vda.linux@googlemail.com> References: <20080401210918.GB12632@hedwig.net.cmu.edu> <200804020151.08059.vda.linux@googlemail.com> Message-ID: <20080402005837.GB23521@hedwig.net.cmu.edu> > I am thinking - maybe we should just junk the idea of "default" > options to ask for? We can ask user to always provide explicit > list of -O OPTs to ask. What do you think? I agree. Although others might yell at us if we change default behavior :) > Please take a look at attached patch - will this work for you? > ... > > + if (client_config.no_default_options) > + return; > + This returns before -O explicit options have a chance to be added, doesn't it ? > packet->options[end + OPT_CODE] = DHCP_PARAM_REQ; > for (i = 0; (c = dhcp_options[i].code) != 0; i++) { > if ((dhcp_options[i].flags & OPTION_REQ) > @@ -107,7 +110,9 @@ int send_discover(uint32_t xid, uint32_t > /* Explicitly saying that we want RFC-compliant packets helps > * some buggy DHCP servers to NOT send bigger packets */ > add_simple_option(packet.options, DHCP_MAX_SIZE, htons(576)); Junking default options altogether definitely feels cleaner, no need to monkey around with all this '-o' stuff... :) Would anyone be truly horrified to see that happen ? BTW, I really did like the [[ %udhcpc_opts%]] idea, I'd like that at least to stay... :) Thanks, --Gabriel From g.schardt at fz-juelich.de Tue Apr 1 22:53:37 2008 From: g.schardt at fz-juelich.de (Georg Schardt) Date: Wed, 02 Apr 2008 07:53:37 +0200 Subject: init / console In-Reply-To: <1207064143.6570.3.camel@kevin-laptop> References: <1207064143.6570.3.camel@kevin-laptop> Message-ID: <47F31F61.1040605@fz-juelich.de> thanks kevin i will try it on the other mailing list :) georg Kevin Holland schrieb: > Hi, > > This is probably not the best forum to ask this question, but try > writing out console=ttyUL0, 115200 or whatever your baud rate is. > Second what kernel and drivers are you using? For further help I would > consult the linuxppc-embedded at ozlabs.org they have lots of xilinx > related questions. Here is the link for viewing old messages > http://www.nabble.com/linuxppc-embedded-f15994.html > > Kevin > > On Tue, 2008-04-01 at 17:20 +0200, Schardt, Georg wrote: > >> Hi all, >> >> first i want to say hello to all of you. i'm a beginner with embedded >> linux and busybox and i have still many questions and problems :) >> >> i use a virtex4fx12 minimodul with an embedded powerpc. u-boot works >> fine, kernel boots up but output from the busybox init does not >> appears on the console. i have one uartlite, giving the consol=ttyUL0 >> command to the kernel. i can see the bootup messages but >> after the "Freeing unused kernel memory: 104k " message i see only a >> "lo". it seems that the console dies at this moment. >> >> is it possible to use one serial connection for console and a login ? >> what devices do i need and how does the inittab looks like ? >> >> regards >> georg >> >> >> >> >> >> >> >> --------------------------------------------------------------- >> ----------------- >> ------------------------------------------------------- >> ------------------------- >> Forschungszentrum J?lich GmbH >> 52425 J?lich >> >> Sitz der Gesellschaft: J?lich >> Eingetragen im Handelsregister des Amtsgerichts D?ren Nr. HR B 3498 >> Vorsitzende des Aufsichtsrats: MinDir'in B?rbel Brumme-Bothe >> Gesch?ftsf&u uml;hrung: Prof. Dr. Achim Bachem (Vorsitzender), >> Dr. Ulrich Krafft (ste llv. Vorsitzender), Prof. Dr. Harald Bolt, >> Dr. Sebastian M. Schmidt >> - >> ---------------------------------------------------------------------------- --- >> --------------------------------------------------------------------- >> ----------- >> _______________________________________________ >> busybox mailing list >> busybox at busybox.net >> http://busybox.net/cgi-bin/mailman/listinfo/busybox >> > > -- --------------------------------- Dipl. Ing. Georg Schardt Forschungszentrum J?lich GmbH ZEL Tel.: +49-2461-614512 schardt at fz-juelich.de --------------------------------- ------------------------------------------------------------------- ------------------------------------------------------------------- Forschungszentrum J?lich GmbH 52425 J?lich Sitz der Gesellschaft: J?lich Eingetragen im Handelsregister des Amtsgerichts D?ren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in B?rbel Brumme-Bothe Gesch?ftsf?hrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt, Dr. Sebastian M. Schmidt ------------------------------------------------------------------- ------------------------------------------------------------------- From roy at marples.name Wed Apr 2 00:27:29 2008 From: roy at marples.name (Roy Marples) Date: Wed, 2 Apr 2008 08:27:29 +0100 Subject: PATCH: udhcpc -- don't request set of options by default In-Reply-To: <20080401223738.GE12632@hedwig.net.cmu.edu> References: <20080401210918.GB12632@hedwig.net.cmu.edu> <200804020014.14424.vda.linux@googlemail.com> <20080401223738.GE12632@hedwig.net.cmu.edu> Message-ID: <200804020827.29193.roy@marples.name> On Tuesday 01 April 2008 23:37:38 L. Gabriel Somlo wrote: > On Wed, Apr 02, 2008 at 12:14:14AM +0200, Denys Vlasenko wrote: > > Imagine that I have *two* interfaces, both sit on DHCP configured > > networks (*different* networks). > > Here one "deconfig"-ed iface will happily nuke /etc/resolv.conf > > created by another interface: >> > The real question is, who "wins" w.r.t. /etc/resolv.conf when multiple > dhcp-configured interfaces are up simultaneously ? This is already a > fun problem for laptops that connect both on wireless and on wired > ethernet, and it's a trainwreck, ifupdown or not... This fun problem has already been resolved by resolvconf. I have an implementation called openresolv that works on POSIX shells and tools, unlike the Debian original. You can read about it some more here. http://roy.marples.name/openresolv Thanks Roy From external.Torsten.Tetz at de.bosch.com Wed Apr 2 05:31:36 2008 From: external.Torsten.Tetz at de.bosch.com (EXTERNAL Tetz Torsten (Praktikant; ST-FIR/ENG1)) Date: Wed, 2 Apr 2008 14:31:36 +0200 Subject: AW: AW: AW: AW: segfaults with ver 1.10.0 on sh3 based board In-Reply-To: <200804011850.09432.vda.linux@googlemail.com> References: <200804011724.06702.vda.linux@googlemail.com> <200804011850.09432.vda.linux@googlemail.com> Message-ID: Denys Vlasenko wrote: > On Tuesday 01 April 2008 17:40, EXTERNAL Tetz Torsten (Praktikant; > ST-FIR/ENG1) wrote: >>> # patch -p1 <12.diff >>> patching file Config.in >>> patching file Rules.mak >>> patching file archival/Makefile.in >>> patching file include/platform.h >>> patching file libbb/Makefile.in >>> patching file miscutils/Makefile.in >>> >>> the resulting tree produces segfaulting binary? >> >> Yes, patching 1.2.1 with 12.diff produces a segfaulting binary. > > As you see, you are down to only six files with differences. > Can you find out which file (and then which chunk) breaks it? Hello, it is this change that makes a segfaulting version out of 1.2.1. --- busybox-1.2.1/Rules.mak Sat Jul 29 00:55:51 2006 +++ busybox-1.2.2/Rules.mak Tue Oct 24 22:22:03 2006 (...) @@ -265,7 +265,7 @@ (...) - CHECKED_LDFLAGS += $(call check_ld,--gc-sections,) + CHECKED_LDFLAGS += $(call check_ld,$(LD),--gc-sections,) (...) I made a test by removing "$(LD)," from the 1.2.2. version and it worked (produced no segfault). Regards, Torsten From vda.linux at googlemail.com Wed Apr 2 06:05:17 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Wed, 2 Apr 2008 15:05:17 +0200 Subject: PATCH: udhcpc -- don't request set of options by default In-Reply-To: <20080402005837.GB23521@hedwig.net.cmu.edu> References: <20080401210918.GB12632@hedwig.net.cmu.edu> <200804020151.08059.vda.linux@googlemail.com> <20080402005837.GB23521@hedwig.net.cmu.edu> Message-ID: <200804021505.17414.vda.linux@googlemail.com> On Wednesday 02 April 2008 02:58, L. Gabriel Somlo wrote: > > I am thinking - maybe we should just junk the idea of "default" > > options to ask for? We can ask user to always provide explicit > > list of -O OPTs to ask. What do you think? > > I agree. Although others might yell at us if we change default > behavior :) Yup. So I will not... Patch is applied, thanks! -- vda From vda.linux at googlemail.com Wed Apr 2 06:18:30 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Wed, 2 Apr 2008 15:18:30 +0200 Subject: AW: AW: AW: AW: segfaults with ver 1.10.0 on sh3 based board In-Reply-To: References: <200804011850.09432.vda.linux@googlemail.com> Message-ID: <200804021518.30508.vda.linux@googlemail.com> On Wednesday 02 April 2008 14:31, EXTERNAL Tetz Torsten (Praktikant; ST-FIR/ENG1) wrote: > Hello, > > it is this change that makes a segfaulting version out of 1.2.1. > > --- busybox-1.2.1/Rules.mak Sat Jul 29 00:55:51 2006 > +++ busybox-1.2.2/Rules.mak Tue Oct 24 22:22:03 2006 > (...) > @@ -265,7 +265,7 @@ > (...) > - CHECKED_LDFLAGS += $(call check_ld,--gc-sections,) > + CHECKED_LDFLAGS += $(call check_ld,$(LD),--gc-sections,) > (...) > > > I made a test by removing "$(LD)," from the 1.2.2. version > and it worked (produced no segfault). Ok. Now we need to figure out how to fix that in 1.10.0. 1.10.0 build system is very different, so you will have to find how the change above affect link command line (how "good" and "bad" ones differ). Please make two 1.2.2 trees which have only the aboce difference and build both with "make V=1". The output will end with something like: ... ... gcc -I/.local/tmp/busybox-1.2.2.1/include -I/.local/tmp/busybox-1.2.2.1/include -I/.local/tmp/busybox-1.2.2.1/libbb -D_GNU_SOURCE -Wall -Wstrict-prototypes -Wshadow -funsigned-char -fno-builtin-strlen -DNDEBUG -Os -march=i386 -mpreferred-stack-boundary=2 -falign-functions=1 -falign-jumps=1 -falign-loops=1 -fno-tree-loop-optimize -fno-tree-dominator-opts -fno-strength-reduce -fno-branch-count-reg -fomit-frame-pointer -ffunction-sections -fdata-sections -Wall -Wstrict-prototypes -Wshadow -funsigned-char -fno-builtin-strlen -Wl,--warn-common -Wl,--sort-common -Wl,--gc-sections -o busybox_unstripped -Wl,--start-group /.local/tmp/busybox-1.2.2.1/applets/applets.c /.local/tmp/busybox-1.2.2.1/applets/busybox.c /.local/tmp/busybox-1.2.2.1/applets/version.c /.local/tmp/busybox-1.2.2.1/applets/applets.a /.local/tmp/busybox-1.2.2.1/archival/libunarchive/libunarchive.a /.local/tmp/busybox-1.2.2.1/coreutils/coreutils.a /.local/tmp/busybox-1.2.2.1/libpwdgrp/libpwdgrp.a /.local/tmp/busybox-1.2.2.1/libbb/libbb.a -Wl,--end-group cp busybox_unstripped busybox strip -s --remove-section=.note --remove-section=.comment busybox /bin/sh /.local/tmp/busybox-1.2.2.1/applets/busybox.mkll include/bb_config.h /.local/tmp/busybox-1.2.2.1/include/applets.h >busybox.links mkdir -p docs ( cat /.local/tmp/busybox-1.2.2.1/docs/busybox_header.pod ; \ /.local/tmp/busybox-1.2.2.1/docs/autodocifier.pl /.local/tmp/busybox-1.2.2.1/include/usage.h ; \ cat /.local/tmp/busybox-1.2.2.1/docs/busybox_footer.pod ; ) > docs/busybox.pod mkdir -p docs pod2text docs/busybox.pod > docs/BusyBox.txt mkdir -p docs pod2man --center=BusyBox --release="version 1.2.2" \ docs/busybox.pod > docs/BusyBox.1 mkdir -p docs/busybox.net pod2html --noindex docs/busybox.pod > \ docs/busybox.net/BusyBox.html rm -f pod2htm* mkdir -p docs rm -f docs/BusyBox.html cp docs/busybox.net/BusyBox.html docs/BusyBox.html that last gcc command calls the linker, and I bet it will be slightly different. What exactly will be the difference? -- vda From external.Torsten.Tetz at de.bosch.com Wed Apr 2 07:30:53 2008 From: external.Torsten.Tetz at de.bosch.com (EXTERNAL Tetz Torsten (Praktikant; ST-FIR/ENG1)) Date: Wed, 2 Apr 2008 16:30:53 +0200 Subject: AW: AW: AW: AW: AW: segfaults with ver 1.10.0 on sh3 based board In-Reply-To: <200804021518.30508.vda.linux@googlemail.com> References: <200804011850.09432.vda.linux@googlemail.com> <200804021518.30508.vda.linux@googlemail.com> Message-ID: Denys Vlasenko wrote: > On Wednesday 02 April 2008 14:31, EXTERNAL Tetz Torsten (Praktikant; > ST-FIR/ENG1) wrote: >> Hello, >> >> it is this change that makes a segfaulting version out of 1.2.1. >> >> --- busybox-1.2.1/Rules.mak Sat Jul 29 00:55:51 2006 >> +++ busybox-1.2.2/Rules.mak Tue Oct 24 22:22:03 2006 (...) >> @@ -265,7 +265,7 @@ >> (...) >> - CHECKED_LDFLAGS += $(call check_ld,--gc-sections,) >> + CHECKED_LDFLAGS += $(call check_ld,$(LD),--gc-sections,) (...) >> >> >> I made a test by removing "$(LD)," from the 1.2.2. version >> and it worked (produced no segfault). > > Ok. Now we need to figure out how to fix that in 1.10.0. > 1.10.0 build system is very different, so you > will have to find how the change above affect link command line > (how "good" and "bad" ones differ). > > Please make two 1.2.2 trees which have only the aboce difference > and build both with "make V=1". The output will end with something > like: > that last gcc command calls the linker, > and I bet it will be slightly different. > What exactly will be the difference? Hello, I attached the output of the last gcc command of builds with and without the change. I kompared them and only found one difference in the commands. The option "-Wl,--gc-sections " is only used in the segfaulting build. The following messages only present in the segfaulting build (also included in the attached "V-1.2.2_segfaults" file) and not to be seen without the "V=1" make option seem to indicate that some needed sections have been removed. Regards, Torsten -------------- next part -------------- A non-text attachment was scrubbed... Name: V-1.2.2_working Type: application/octet-stream Size: 1308 bytes Desc: V-1.2.2_working Url : http://busybox.net/lists/busybox/attachments/20080402/f461468e/attachment-0002.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: V-1.2.2_segfaults Type: application/octet-stream Size: 12184 bytes Desc: V-1.2.2_segfaults Url : http://busybox.net/lists/busybox/attachments/20080402/f461468e/attachment-0003.obj From stefan at the2masters.de Wed Apr 2 08:40:16 2008 From: stefan at the2masters.de (Stefan Hellermann) Date: Wed, 02 Apr 2008 17:40:16 +0200 Subject: PATCH: udhcpc -- don't request set of options by default In-Reply-To: <20080402005837.GB23521@hedwig.net.cmu.edu> References: <20080401210918.GB12632@hedwig.net.cmu.edu> <200804020151.08059.vda.linux@googlemail.com> <20080402005837.GB23521@hedwig.net.cmu.edu> Message-ID: <47F3A8E0.2000809@the2masters.de> L. Gabriel Somlo schrieb: >> I am thinking - maybe we should just junk the idea of "default" >> options to ask for? We can ask user to always provide explicit >> list of -O OPTs to ask. What do you think? > > I agree. Although others might yell at us if we change default > behavior :) > >> Please take a look at attached patch - will this work for you? >> > ... >> >> + if (client_config.no_default_options) >> + return; >> + > > This returns before -O explicit options have a chance to be added, > doesn't it ? > >> packet->options[end + OPT_CODE] = DHCP_PARAM_REQ; >> for (i = 0; (c = dhcp_options[i].code) != 0; i++) { >> if ((dhcp_options[i].flags & OPTION_REQ) >> @@ -107,7 +110,9 @@ int send_discover(uint32_t xid, uint32_t >> /* Explicitly saying that we want RFC-compliant packets helps >> * some buggy DHCP servers to NOT send bigger packets */ >> add_simple_option(packet.options, DHCP_MAX_SIZE, htons(576)); > > Junking default options altogether definitely feels cleaner, no need > to monkey around with all this '-o' stuff... :) Would anyone be truly > horrified to see that happen ? I think I was the one that requested this feature some time ago, and I've no problem with this change, as long as it is mentioned on busybox.net :) Cheers Stefan > > BTW, I really did like the [[ %udhcpc_opts%]] idea, I'd like that at > least to stay... :) > > Thanks, > --Gabriel > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://busybox.net/cgi-bin/mailman/listinfo/busybox From rep.dot.nop at gmail.com Wed Apr 2 09:44:39 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Wed, 2 Apr 2008 18:44:39 +0200 Subject: AW: AW: AW: AW: segfaults with ver 1.10.0 on sh3 based board In-Reply-To: References: <200804011850.09432.vda.linux@googlemail.com> <200804021518.30508.vda.linux@googlemail.com> Message-ID: <20080402164439.GF9436@mx.loc> On Wed, Apr 02, 2008 at 04:30:53PM +0200, EXTERNAL Tetz Torsten (Praktikant; ST-FIR/ENG1) wrote: >Denys Vlasenko wrote: >> that last gcc command calls the linker, >> and I bet it will be slightly different. >> What exactly will be the difference? > >Hello, > >I attached the output of the last gcc command of builds with and >without the change. > >I kompared them and only found one difference in the commands. >The option "-Wl,--gc-sections " is only used in the segfaulting build. > >The following messages only present in the segfaulting build >(also included in the attached "V-1.2.2_segfaults" file) >and not to be seen without the "V=1" make option seem to >indicate that some needed sections have been removed. Can you please send a diff of the two logs? TIA, Bernhard From vda.linux at googlemail.com Wed Apr 2 11:22:39 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Wed, 2 Apr 2008 20:22:39 +0200 Subject: AW: AW: AW: AW: AW: segfaults with ver 1.10.0 on sh3 based board In-Reply-To: References: <200804021518.30508.vda.linux@googlemail.com> Message-ID: <200804022022.39365.vda.linux@googlemail.com> On Wednesday 02 April 2008 16:30, EXTERNAL Tetz Torsten (Praktikant; ST-FIR/ENG1) wrote: > Denys Vlasenko wrote: > > On Wednesday 02 April 2008 14:31, EXTERNAL Tetz Torsten (Praktikant; > > ST-FIR/ENG1) wrote: > >> Hello, > >> > >> it is this change that makes a segfaulting version out of 1.2.1. > >> > >> --- busybox-1.2.1/Rules.mak Sat Jul 29 00:55:51 2006 > >> +++ busybox-1.2.2/Rules.mak Tue Oct 24 22:22:03 2006 (...) > >> @@ -265,7 +265,7 @@ > >> (...) > >> - CHECKED_LDFLAGS += $(call check_ld,--gc-sections,) > >> + CHECKED_LDFLAGS += $(call check_ld,$(LD),--gc-sections,) (...) > >> > >> > >> I made a test by removing "$(LD)," from the 1.2.2. version > >> and it worked (produced no segfault). > > > > Ok. Now we need to figure out how to fix that in 1.10.0. > > 1.10.0 build system is very different, so you > > will have to find how the change above affect link command line > > (how "good" and "bad" ones differ). > > > > Please make two 1.2.2 trees which have only the aboce difference > > and build both with "make V=1". The output will end with something > > like: > > > that last gcc command calls the linker, > > and I bet it will be slightly different. > > What exactly will be the difference? > > Hello, > > I attached the output of the last gcc command of builds with and > without the change. > > I kompared them and only found one difference in the commands. > The option "-Wl,--gc-sections " is only used in the segfaulting build. Yes, and it also complains a lot: `optind@@GLIBC_2.2' referenced in section `.text.ls_main' of /home/...../coreutils.a(ls.o): defined in discarded section `.dynbss' of ..../crt1.o That's not good. Which version of ld is that? Run "ld -v"... ohh, I mean, /opt/crosstool/gcc-4.1.2-glibc-2.3.6/sh3-unknown-linux-gnu/lib/gcc/sh3-unknown-linux-gnu/4.1.2/../../../../sh3-unknown-linux-gnu/bin/ld -v -- vda From jsimmons at infradead.org Wed Apr 2 13:03:04 2008 From: jsimmons at infradead.org (James Simmons) Date: Wed, 2 Apr 2008 21:03:04 +0100 (BST) Subject: [PATCH] dd fsync support Message-ID: Support to physically write output file data before finishing. Index: dd.c =================================================================== --- dd.c (revision 21619) +++ dd.c (working copy) @@ -87,6 +87,7 @@ FLAG_NOTRUNC = 1 << 2, FLAG_TWOBUFS = 1 << 3, FLAG_COUNT = 1 << 4, + FLAG_FSYNC = 1 << 5, }; static const char keywords[] ALIGN1 = "bs=\0""count=\0""seek=\0""skip=\0""if=\0""of=\0" @@ -108,6 +109,7 @@ OP_conv_notrunc, OP_conv_sync, OP_conv_noerror, + OP_conv_fsync, #endif }; int exitcode = EXIT_FAILURE; @@ -185,6 +187,8 @@ flags |= FLAG_SYNC; if (what == OP_conv_noerror) flags |= FLAG_NOERROR; + if (what == OP_conv_fsync) + flags |= FLAG_FSYNC; if (!key) /* no ',' left, so this was the last specifier */ break; arg = key + 1; /* skip this keyword and ',' */ @@ -304,6 +308,11 @@ } } else if (write_and_stats(ibuf, n, obs, outfile)) goto out_status; + + if (flags & FLAG_FSYNC) { + if (fsync(ofd) < 0) + goto die_outfile; + } } if (ENABLE_FEATURE_DD_IBS_OBS && oc) { From harald-tuxbox at arcor.de Wed Apr 2 13:50:55 2008 From: harald-tuxbox at arcor.de (Harald Kuethe) Date: Wed, 2 Apr 2008 22:50:55 +0200 Subject: [PATCH] init.c, halt command not working References: <47EFFC15.5040706@arcor.de> <200803312152.14808.vda.linux@googlemail.com> <001301c89441$2666de40$0a02a8c0@houdinineu> <200804012351.58135.vda.linux@googlemail.com> Message-ID: <000601c89503$44d7e820$0a02a8c0@houdinineu> > ----- Original Message ----- > From: "Denys Vlasenko" > To: "Harald Kuethe" > Cc: > Sent: Tuesday, April 01, 2008 11:51 PM > Subject: Re: [PATCH] init.c, halt command not working > On Tuesday 01 April 2008 23:41, Harald Kuethe wrote: > > > ----- Original Message ----- > > > From: "Denys Vlasenko" > > > To: > > > Cc: "Harald K?the" > > > Sent: Monday, March 31, 2008 9:52 PM > > > Subject: Re: [PATCH] init.c, halt command not working > > > > > > > On Monday 31 March 2008 21:59, Harald K?the wrote: > > > > > The sequence of events is: > > > > > SIGUSR1 is received > > > > > halt_reboot_pwoff(SIGUSR1) calls > > > > > kill_all_processes() calls > > > > > run_actions(SHUTDOWN): > > > > > if (a->action_type & (SYSINIT | WAIT | > > > > CTRLALTDEL | SHUTDOWN | RESTART)) { > > > > > waitfor(run(a)); > > > > > delete_init_action(a); > > > > > run(a) vforks... and this is somehow doesn't work very well > > > > > > > > It looks as if SIGUSR1 is !!not!! received because halt_reboot_pwoff() > > > > is not processed. > > > > Please confirm that you added a debug printout to > > > halt_reboot_pwoff and it is not triggering when halt > > > sends SIGUSR1 to init. > > > > Yes, confirmed! > > And also it doesn't trigger when you send signal by hand - > "kill -USR1 1" ? Yes no trigger with this > -- > vda I attached a strace output of the killall init (which restarts the system) as well as of the kill 1 (which does not) Maybe this helps. / # strace -fF killall init execve("/bin/killall", ["killall", "init"], [/* 7 vars */]) = 0 brk(0) = 0x10068a24 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x30017000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/libcrypt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/lib/tls", 0x7ffff230) = -1 ENOENT (No such file or directory) open("/lib/libcrypt.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\0\t"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=30349, ...}) = 0 mmap(0xffb3000, 246400, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xffb3000 mprotect(0xffb8000, 225920, PROT_NONE) = 0 mmap(0xffc7000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE,3, 0x4000) = 0xffc7000 mmap(0xffc9000, 156288, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xffc9000 close(3) = 0 open("/lib/libgcc_s_nof.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\0\31"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=193993, ...}) = 0 mmap(0xff86000, 116660, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xff86000 mprotect(0xff93000, 63412, PROT_NONE) = 0 mmap(0xffa2000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE,3, 0xc000) = 0xffa2000 close(3) = 0 open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\1\316"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1352446, ...}) = 0 mmap(0xfe53000, 1191204, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xfe53000 mprotect(0xff5f000, 93476, PROT_NONE) = 0 mmap(0xff6e000, 24576, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x10b000) = 0xff6e000 mmap(0xff74000, 7460, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS,-1, 0) = 0xff74000 close(3) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x30018000 mprotect(0xff6e000, 8192, PROT_READ) = 0 mprotect(0xffc7000, 4096, PROT_READ) = 0 mprotect(0x30026000, 4096, PROT_READ) = 0 getuid() = 0 getpid() = 91 brk(0) = 0x10068a24 brk(0x10089a24) = 0x10089a24 brk(0x1008a000) = 0x1008a000 open("/dev/null", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1 ENOTDIR (Not a directory) open("/proc", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3 fstat64(3, {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 getdents64(3, /* 35 entries */, 1024) = 1024 getdents64(3, /* 17 entries */, 1024) = 408 open("/proc/1/stat", O_RDONLY|O_LARGEFILE) = 4 read(4, "1 (init) D 0 0 0 0 -1 256 12 236"..., 1023) = 183 close(4) = 0 open("/proc/2/stat", O_RDONLY|O_LARGEFILE) = 4 read(4, "2 (keventd) S 1 1 1 0 -1 64 0 0 "..., 1023) = 121 close(4) = 0 open("/proc/3/stat", O_RDONLY|O_LARGEFILE) = 4 read(4, "3 (ksoftirqd_CPU0) S 1 1 1 0 -1 "..., 1023) = 126 close(4) = 0 open("/proc/4/stat", O_RDONLY|O_LARGEFILE) = 4 read(4, "4 (kswapd) S 1 1 1 0 -1 2112 0 0"..., 1023) = 118 close(4) = 0 open("/proc/5/stat", O_RDONLY|O_LARGEFILE) = 4 read(4, "5 (bdflush) S 1 1 1 0 -1 64 0 0 "..., 1023) = 117 close(4) = 0 open("/proc/6/stat", O_RDONLY|O_LARGEFILE) = 4 read(4, "6 (kupdated) S 1 1 1 0 -1 64 0 0"..., 1023) = 118 close(4) = 0 open("/proc/7/stat", O_RDONLY|O_LARGEFILE) = 4 read(4, "7 (cifsoplockd) S 1 1 1 0 -1 64 "..., 1023) = 112 close(4) = 0 open("/proc/8/stat", O_RDONLY|O_LARGEFILE) = 4 read(4, "8 (mtdblockd) S 1 1 1 0 -1 2112 "..., 1023) = 121 close(4) = 0 open("/proc/9/stat", O_RDONLY|O_LARGEFILE) = 4 read(4, "9 (rpciod) S 1 1 1 0 -1 64 0 0 0"..., 1023) = 117 close(4) = 0 open("/proc/21/stat", O_RDONLY|O_LARGEFILE) = 4 read(4, "21 (inetd) S 1 21 21 0 -1 320 27"..., 1023) = 176 close(4) = 0 open("/proc/56/stat", O_RDONLY|O_LARGEFILE) = 4 read(4, "56 (avia_av_wdt) S 1 1 1 0 -1 64"..., 1023) = 124 close(4) = 0 open("/proc/60/stat", O_RDONLY|O_LARGEFILE) = 4 read(4, "60 (avia_gt_wdt) S 1 1 1 0 -1 64"..., 1023) = 124 close(4) = 0 open("/proc/80/stat", O_RDONLY|O_LARGEFILE) = 4 read(4, "80 (sh) S 1 80 80 1088 90 0 75 8"..., 1023) = 176 close(4) = 0 open("/proc/81/stat", O_RDONLY|O_LARGEFILE) = 4 read(4, "81 (init) S 1 81 81 1026 81 64 0"..., 1023) = 163 close(4) = 0 open("/proc/90/stat", O_RDONLY|O_LARGEFILE) = 4 read(4, "90 (strace) R 80 90 80 1088 90 0"..., 1023) = 178 close(4) = 0 open("/proc/91/stat", O_RDONLY|O_LARGEFILE) = 4 read(4, "91 (killall) R 90 90 80 1088 90 "..., 1023) = 162 close(4) = 0 getdents64(3, /* 0 entries */, 1024) = 0 brk(0x10089000) = 0x10089000 close(3) = 0 kill(1, SIGTERM) = 0 HK: halt_reboot_pwoff (my debug printout in halt_reboot_pwoff) = 0 call bb_signals exit(0) = ? The system is going down NOW! Sending SIGTERM to all processes Sending SIGKILL to all processes Requesting system reboot / # strace -fF kill 1 execve("/bin/kill", ["kill", "1"], [/* 7 vars */]) = 0 brk(0) = 0x10068a24 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x30017000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/tls/libcrypt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/lib/tls", 0x7ffff230) = -1 ENOENT (No such file or directory) open("/lib/libcrypt.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\0\t"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=30349, ...}) = 0 mmap(0xffb3000, 246400, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xffb3000 mprotect(0xffb8000, 225920, PROT_NONE) = 0 mmap(0xffc7000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE,3, 0x4000) = 0xffc7000 mmap(0xffc9000, 156288, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xffc9000 close(3) = 0 open("/lib/libgcc_s_nof.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\0\31"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=193993, ...}) = 0 mmap(0xff86000, 116660, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xff86000 mprotect(0xff93000, 63412, PROT_NONE) = 0 mmap(0xffa2000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE,3, 0xc000) = 0xffa2000 close(3) = 0 open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\1\316"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1352446, ...}) = 0 mmap(0xfe53000, 1191204, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xfe53000 mprotect(0xff5f000, 93476, PROT_NONE) = 0 mmap(0xff6e000, 24576, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x10b000) = 0xff6e000 mmap(0xff74000, 7460, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS,-1, 0) = 0xff74000 close(3) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x30018000 mprotect(0xff6e000, 8192, PROT_READ) = 0 mprotect(0xffc7000, 4096, PROT_READ) = 0 mprotect(0x30026000, 4096, PROT_READ) = 0 getuid() = 0 kill(1, SIGTERM) = 0 exit(0) = ? From vda.linux at googlemail.com Wed Apr 2 14:21:37 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Wed, 2 Apr 2008 23:21:37 +0200 Subject: [PATCH] dd fsync support In-Reply-To: References: Message-ID: <200804022321.37671.vda.linux@googlemail.com> On Wednesday 02 April 2008 22:03, James Simmons wrote: > Support to physically write output file data before finishing. > > Index: dd.c > =================================================================== > --- dd.c (revision 21619) > +++ dd.c (working copy) > @@ -87,6 +87,7 @@ > FLAG_NOTRUNC = 1 << 2, > FLAG_TWOBUFS = 1 << 3, > FLAG_COUNT = 1 << 4, > + FLAG_FSYNC = 1 << 5, > }; > static const char keywords[] ALIGN1 = > "bs=\0""count=\0""seek=\0""skip=\0""if=\0""of=\0" > @@ -108,6 +109,7 @@ > OP_conv_notrunc, > OP_conv_sync, > OP_conv_noerror, > + OP_conv_fsync, > #endif > }; > int exitcode = EXIT_FAILURE; > @@ -185,6 +187,8 @@ > flags |= FLAG_SYNC; > if (what == OP_conv_noerror) > flags |= FLAG_NOERROR; > + if (what == OP_conv_fsync) > + flags |= FLAG_FSYNC; > if (!key) /* no ',' left, so this was the last specifier */ > break; > arg = key + 1; /* skip this keyword and ',' */ > @@ -304,6 +308,11 @@ > } > } else if (write_and_stats(ibuf, n, obs, outfile)) > goto out_status; > + > + if (flags & FLAG_FSYNC) { > + if (fsync(ofd) < 0) > + goto die_outfile; > + } > } > > if (ENABLE_FEATURE_DD_IBS_OBS && oc) { Seems like the string "fsync\0" is not added by this patch... I fixed it up. Applied to current svn. Thanks. -- vda From vda.linux at googlemail.com Wed Apr 2 14:41:44 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Wed, 2 Apr 2008 23:41:44 +0200 Subject: [PATCH] init.c, halt command not working In-Reply-To: <000601c89503$44d7e820$0a02a8c0@houdinineu> References: <47EFFC15.5040706@arcor.de> <200804012351.58135.vda.linux@googlemail.com> <000601c89503$44d7e820$0a02a8c0@houdinineu> Message-ID: <200804022341.44253.vda.linux@googlemail.com> On Wednesday 02 April 2008 22:50, Harald Kuethe wrote: > > ----- Original Message ----- > > From: "Denys Vlasenko" > > To: "Harald Kuethe" > > Cc: > > Sent: Tuesday, April 01, 2008 11:51 PM > > Subject: Re: [PATCH] init.c, halt command not working > > > > On Tuesday 01 April 2008 23:41, Harald Kuethe wrote: > > > > ----- Original Message ----- > > > > From: "Denys Vlasenko" > > > > To: > > > > Cc: "Harald K?the" > > > > Sent: Monday, March 31, 2008 9:52 PM > > > > Subject: Re: [PATCH] init.c, halt command not working > > > > > > > > > > On Monday 31 March 2008 21:59, Harald K?the wrote: > > > > > > The sequence of events is: > > > > > > SIGUSR1 is received > > > > > > halt_reboot_pwoff(SIGUSR1) calls > > > > > > kill_all_processes() calls > > > > > > run_actions(SHUTDOWN): > > > > > > if (a->action_type & (SYSINIT | WAIT | > > > > > CTRLALTDEL | SHUTDOWN | RESTART)) { > > > > > > waitfor(run(a)); > > > > > > delete_init_action(a); > > > > > > run(a) vforks... and this is somehow doesn't work very well > > > > > > > > > > It looks as if SIGUSR1 is !!not!! received because halt_reboot_pwoff() > > > > > is not processed. > > > > > > Please confirm that you added a debug printout to > > > > halt_reboot_pwoff and it is not triggering when halt > > > > sends SIGUSR1 to init. > > > > > > Yes, confirmed! > > > > And also it doesn't trigger when you send signal by hand - > > "kill -USR1 1" ? > > Yes no trigger with this > > > -- > > vda > > I attached a strace output of the killall init (which restarts the system) as well as of the kill 1 (which does not) > Maybe this helps. > > / # strace -fF killall init > execve("/bin/killall", ["killall", "init"], [/* 7 vars */]) = 0 > brk(0) = 0x10068a24 > mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x30017000 > ... > mprotect(0xffc7000, 4096, PROT_READ) = 0 > mprotect(0x30026000, 4096, PROT_READ) = 0 > getuid() = 0 > getpid() = 91 > brk(0) = 0x10068a24 > brk(0x10089a24) = 0x10089a24 > brk(0x1008a000) = 0x1008a000 > open("/dev/null", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1 ENOTDIR (Not a directory) > open("/proc", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3 > fstat64(3, {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0 > fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 > getdents64(3, /* 35 entries */, 1024) = 1024 > getdents64(3, /* 17 entries */, 1024) = 408 > open("/proc/1/stat", O_RDONLY|O_LARGEFILE) = 4 > read(4, "1 (init) D 0 0 0 0 -1 256 12 236"..., 1023) = 183 > close(4) = 0 > open("/proc/2/stat", O_RDONLY|O_LARGEFILE) = 4 > read(4, "2 (keventd) S 1 1 1 0 -1 64 0 0 "..., 1023) = 121 > close(4) = 0 > open("/proc/3/stat", O_RDONLY|O_LARGEFILE) = 4 > read(4, "3 (ksoftirqd_CPU0) S 1 1 1 0 -1 "..., 1023) = 126 > close(4) = 0 > open("/proc/4/stat", O_RDONLY|O_LARGEFILE) = 4 > read(4, "4 (kswapd) S 1 1 1 0 -1 2112 0 0"..., 1023) = 118 > close(4) = 0 > open("/proc/5/stat", O_RDONLY|O_LARGEFILE) = 4 > read(4, "5 (bdflush) S 1 1 1 0 -1 64 0 0 "..., 1023) = 117 > close(4) = 0 > open("/proc/6/stat", O_RDONLY|O_LARGEFILE) = 4 > read(4, "6 (kupdated) S 1 1 1 0 -1 64 0 0"..., 1023) = 118 > close(4) = 0 > open("/proc/7/stat", O_RDONLY|O_LARGEFILE) = 4 > read(4, "7 (cifsoplockd) S 1 1 1 0 -1 64 "..., 1023) = 112 > close(4) = 0 > open("/proc/8/stat", O_RDONLY|O_LARGEFILE) = 4 > read(4, "8 (mtdblockd) S 1 1 1 0 -1 2112 "..., 1023) = 121 > close(4) = 0 > open("/proc/9/stat", O_RDONLY|O_LARGEFILE) = 4 > read(4, "9 (rpciod) S 1 1 1 0 -1 64 0 0 0"..., 1023) = 117 > close(4) = 0 > open("/proc/21/stat", O_RDONLY|O_LARGEFILE) = 4 > read(4, "21 (inetd) S 1 21 21 0 -1 320 27"..., 1023) = 176 > close(4) = 0 > open("/proc/56/stat", O_RDONLY|O_LARGEFILE) = 4 > read(4, "56 (avia_av_wdt) S 1 1 1 0 -1 64"..., 1023) = 124 > close(4) = 0 > open("/proc/60/stat", O_RDONLY|O_LARGEFILE) = 4 > read(4, "60 (avia_gt_wdt) S 1 1 1 0 -1 64"..., 1023) = 124 > close(4) = 0 > open("/proc/80/stat", O_RDONLY|O_LARGEFILE) = 4 > read(4, "80 (sh) S 1 80 80 1088 90 0 75 8"..., 1023) = 176 > close(4) = 0 > open("/proc/81/stat", O_RDONLY|O_LARGEFILE) = 4 > read(4, "81 (init) S 1 81 81 1026 81 64 0"..., 1023) = 163 > close(4) = 0 > open("/proc/90/stat", O_RDONLY|O_LARGEFILE) = 4 > read(4, "90 (strace) R 80 90 80 1088 90 0"..., 1023) = 178 > close(4) = 0 > open("/proc/91/stat", O_RDONLY|O_LARGEFILE) = 4 > read(4, "91 (killall) R 90 90 80 1088 90 "..., 1023) = 162 > close(4) = 0 > getdents64(3, /* 0 entries */, 1024) = 0 > brk(0x10089000) = 0x10089000 > close(3) = 0 > kill(1, SIGTERM) = 0 > > HK: halt_reboot_pwoff (my debug printout in halt_reboot_pwoff) > = 0 > call bb_signals > exit(0) = ? > > The system is going down NOW! > Sending SIGTERM to all processes > Sending SIGKILL to all processes > Requesting system reboot Yes, apparently SIGTERM got caught by init. > / # strace -fF kill 1 > execve("/bin/kill", ["kill", "1"], [/* 7 vars */]) = 0 > brk(0) = 0x10068a24 > mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x30017000 ... > mprotect(0xff6e000, 8192, PROT_READ) = 0 > mprotect(0xffc7000, 4096, PROT_READ) = 0 > mprotect(0x30026000, 4096, PROT_READ) = 0 > getuid() = 0 > kill(1, SIGTERM) = 0 > exit(0) = ? kill() returns 0 (success), so the system thinks that SIGTERM is delivered. But init does not print your debug message. Very strange. killall did the very same thing: "kill(1, SIGTERM)" and it worked... Please try attached idagnostic patch. It will spam your console if it will detect that init has TERM blocked or set to unexpected handler. Try to "kill 1" and "kill -USR1 1" and report what init says. -- vda -------------- next part -------------- A non-text attachment was scrubbed... Name: 7.patch Type: text/x-diff Size: 800 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080402/8608eb66/attachment-0001.patch From external.Torsten.Tetz at de.bosch.com Thu Apr 3 02:29:13 2008 From: external.Torsten.Tetz at de.bosch.com (EXTERNAL Tetz Torsten (Praktikant; ST-FIR/ENG1)) Date: Thu, 3 Apr 2008 11:29:13 +0200 Subject: AW: AW: AW: AW: AW: segfaults with ver 1.10.0 on sh3 based board In-Reply-To: <20080402164439.GF9436@mx.loc> References: <200804011850.09432.vda.linux@googlemail.com><200804021518.30508.vda.linux@googlemail.com> <20080402164439.GF9436@mx.loc> Message-ID: Hello Bernhard, > Can you please send a diff of the two logs? Here is the requested diff. Thanks for looking into this. Regards, Torsten -------------- next part -------------- A non-text attachment was scrubbed... Name: diff Type: application/octet-stream Size: 29464 bytes Desc: diff Url : http://busybox.net/lists/busybox/attachments/20080403/0ba015b4/attachment-0001.obj From external.Torsten.Tetz at de.bosch.com Thu Apr 3 02:31:31 2008 From: external.Torsten.Tetz at de.bosch.com (EXTERNAL Tetz Torsten (Praktikant; ST-FIR/ENG1)) Date: Thu, 3 Apr 2008 11:31:31 +0200 Subject: AW: AW: AW: AW: AW: AW: segfaults with ver 1.10.0 on sh3 based board In-Reply-To: <200804022022.39365.vda.linux@googlemail.com> References: <200804021518.30508.vda.linux@googlemail.com> <200804022022.39365.vda.linux@googlemail.com> Message-ID: Hello Denys, > That's not good. Which version of ld is that? > > Run "ld -v"... ohh, I mean, > > /opt/crosstool/gcc-4.1.2-glibc-2.3.6/sh3-unknown-linux-gnu/lib/gcc/sh3-u nknown-linux-gnu/4.1.2/../../../../sh3-unknown-linux-gnu/bin/ld > -v Version of ld is: "GNU ld version 2.16.1" Thanks for your dedication. Regards, Torsten From jsimmons at infradead.org Thu Apr 3 06:35:10 2008 From: jsimmons at infradead.org (James Simmons) Date: Thu, 3 Apr 2008 14:35:10 +0100 (BST) Subject: [PATCH] dd fsync support In-Reply-To: <200804022321.37671.vda.linux@googlemail.com> References: <200804022321.37671.vda.linux@googlemail.com> Message-ID: > Seems like the string "fsync\0" is not added by this patch... > > I fixed it up. Applied to current svn. Thanks. Thanks. I aslo forgot the changes to usage.h. Index: include/usage.h =================================================================== --- include/usage.h (revision 21626) +++ include/usage.h (working copy) @@ -623,7 +623,7 @@ #define dd_trivial_usage \ "[if=FILE] [of=FILE] " USE_FEATURE_DD_IBS_OBS("[ibs=N] [obs=N] ") "[bs=N] [count=N] [skip=N]\n" \ - " [seek=N]" USE_FEATURE_DD_IBS_OBS(" [conv=notrunc|noerror|sync]") + " [seek=N]" USE_FEATURE_DD_IBS_OBS(" [conv=notrunc|noerror|sync|fsync]") #define dd_full_usage \ "Copy a file with converting and formatting\n" \ "\nOptions:" \ @@ -640,7 +640,8 @@ USE_FEATURE_DD_IBS_OBS( \ "\n conv=notrunc Don't truncate output file" \ "\n conv=noerror Continue after read errors" \ - "\n conv=sync Pad blocks with zeros") \ + "\n conv=sync Pad blocks with zeros" \ + "\n conv=fsync physically write output file data before finishing") \ "\n" \ "\nNumbers may be suffixed by c (x1), w (x2), b (x512), kD (x1000), k (x1024)," \ "\nMD (x1000000), M (x1048576), GD (x1000000000) or G (x1073741824)" \ From jsimmons at infradead.org Thu Apr 3 08:46:38 2008 From: jsimmons at infradead.org (James Simmons) Date: Thu, 3 Apr 2008 16:46:38 +0100 (BST) Subject: progress bar to share problems. Message-ID: In busybox 1.61. I moved the progress status bar out of wget into libbb. Then I had dd use the progress bar as well as wget. I attempted to port that change to 1.10 but now there is a struct global now so I don't know how to expose values in the progress bar to both wget and dd. Here is what I have so far. Basically all the global options for wget needs to be shared with dd but dd has its own global options. Any clean ideas to how to approach this. /* vi: set sw=4 ts=4: */ /* * progress meter - a generic progress meter * * Stolen from BusyBox wget.c, originally by * Chip Rosenthal Covad Communications */ #include #include #include #include #include #include #include #include #include "libbb.h" /* Stuff below is from BSD rcp util.c, as added to openshh. * Original copyright notice is retained at the end of this file. */ static void bb_progressmeter(int flag) { /* We can be called from signal handler */ int save_errno = errno; off_t abbrevsize; unsigned since_last_update, elapsed; unsigned ratio; int barlength, i; if (flag == -1) { /* first call to bb_progressmeter */ start_sec = monotonic_sec(); lastupdate_sec = start_sec; lastsize = 0; totalsize = content_len + beg_range; /* as content_len changes.. */ } ratio = 100; if (totalsize != 0 && !chunked) { /* long long helps to have it working even if !LFS */ ratio = (unsigned) (100ULL * (transferred+beg_range) / totalsize); if (ratio > 100) ratio = 100; } fprintf(stderr, "\r%-20.20s%4d%% ", curfile, ratio); get_terminal_width_height(0, &barlength, NULL); barlength -= 49; if (barlength > 0) { /* god bless gcc for variable arrays :) */ i = barlength * ratio / 100; { char buf[i+1]; memset(buf, '*', i); buf[i] = '\0'; fprintf(stderr, "|%s%*s|", buf, barlength - i, ""); } } i = 0; abbrevsize = transferred + beg_range; while (abbrevsize >= 100000) { i++; abbrevsize >>= 10; } /* see http://en.wikipedia.org/wiki/Tera */ fprintf(stderr, "%6d%c ", (int)abbrevsize, " kMGTPEZY"[i]); // Nuts! Ain't it easier to update progress meter ONLY when we transferred++? elapsed = monotonic_sec(); since_last_update = elapsed - lastupdate_sec; if (transferred > lastsize) { lastupdate_sec = elapsed; lastsize = transferred; if (since_last_update >= stalltime) { /* We "cut off" these seconds from elapsed time * by adjusting start time */ start_sec += since_last_update; } since_last_update = 0; /* we are un-stalled now */ } elapsed -= start_sec; /* now it's "elapsed since start" */ if (since_last_update >= stalltime) { fprintf(stderr, " - stalled -"); } else { off_t to_download = totalsize - beg_range; if (transferred <= 0 || (int)elapsed <= 0 || transferred > to_download || chunked) { fprintf(stderr, "--:--:-- ETA"); } else { /* to_download / (transferred/elapsed) - elapsed: */ int eta = (int) ((unsigned long long)to_download*elapsed/transferred - elapsed); /* (long long helps to have working ETA even if !LFS) */ i = eta % 3600; fprintf(stderr, "%02d:%02d:%02d ETA", eta / 3600, i / 60, i % 60); } } if (flag == 0) { /* last call to bb_progressmeter */ alarm(0); transferred = 0; fputc('\n', stderr); } else { if (flag == -1) { /* first call to bb_progressmeter */ signal_SA_RESTART_empty_mask(SIGALRM, bb_progressmeter); } alarm(1); } errno = save_errno; } /* Original copyright notice which applies to the CONFIG_FEATURE_PROGRESSMETER * stuff, much of which was blatently stolen from openssh. */ /*- * Copyright (c) 1992, 1993 * The Regents of the University of California. All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * 3. * * 4. Neither the name of the University nor the names of its contributors * may be used to endorse or promote products derived from this software * without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * */ /* Local Variables: c-file-style: "linux" c-basic-offset: 4 tab-width: 4 End: */ From gerickson at nuovations.com Thu Apr 3 09:10:17 2008 From: gerickson at nuovations.com (Grant Erickson) Date: Thu, 03 Apr 2008 09:10:17 -0700 Subject: BOOTP Support in BusyBox udhcp Client In-Reply-To: Message-ID: Russ and/or Magnus, Sometime ago, in December 2002 to be exact, there was discussion of a patch submitted by Magnus integrating BOOTP support into the udhcp client: http://www.busybox.net/lists/udhcp/2002-December/000002.html However, it looks like as of BusyBox-1.9.1, this patch never made it into the mainline code base. Do you have any additional insight or background on what happened with the patch in the intervening five years? Best, Grant Erickson From harald-tuxbox at arcor.de Thu Apr 3 14:33:27 2008 From: harald-tuxbox at arcor.de (Harald Kuethe) Date: Thu, 3 Apr 2008 23:33:27 +0200 Subject: [PATCH] init.c, halt command not working References: <47EFFC15.5040706@arcor.de> <200804012351.58135.vda.linux@googlemail.com> <000601c89503$44d7e820$0a02a8c0@houdinineu> <200804022341.44253.vda.linux@googlemail.com> Message-ID: <000b01c895d2$64d17ae0$0a02a8c0@houdinineu> > ----- Original Message ----- > From: "Denys Vlasenko" > To: "Harald Kuethe" > Cc: > Sent: Wednesday, April 02, 2008 11:41 PM > Subject: Re: [PATCH] init.c, halt command not working ... > kill() returns 0 (success), so the system thinks that SIGTERM is delivered. > But init does not print your debug message. Very strange. > killall did the very same thing: "kill(1, SIGTERM)" and it worked... > Please try attached idagnostic patch. > It will spam your console if it will detect that init > has TERM blocked or set to unexpected handler. > Try to "kill 1" and "kill -USR1 1" and report what init says. > -- > vda This patch adds no additional output :-/ I put some more debugging output into the init_main function to find out where it hangs. It showed that init_main does not return from the run_actions(ASKFIRST); call, this explains that the additional diagnostics didn't come up. Following lines are copied from our inittab: ... ::askfirst:-/bin/sh vc/2::askfirst:-/bin/sh vc/3::askfirst:-/bin/sh ... It looks as if the init process is replaced by the shell without finishing generating the virtual consoles and waiting in the while loop because there are only 2 init processes here (there were some more (one for each vc) with the fork() instead of the vfork()) Regards Harald From vda.linux at googlemail.com Thu Apr 3 16:32:52 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 4 Apr 2008 01:32:52 +0200 Subject: AW: AW: AW: AW: AW: AW: segfaults with ver 1.10.0 on sh3 based board In-Reply-To: References: <200804022022.39365.vda.linux@googlemail.com> Message-ID: <200804040132.52346.vda.linux@googlemail.com> On Thursday 03 April 2008 11:31, EXTERNAL Tetz Torsten (Praktikant; ST-FIR/ENG1) wrote: > Hello Denys, > > > That's not good. Which version of ld is that? > > > > Run "ld -v"... ohh, I mean, > > > > > /opt/crosstool/gcc-4.1.2-glibc-2.3.6/sh3-unknown-linux-gnu/lib/gcc/sh3-u > nknown-linux-gnu/4.1.2/../../../../sh3-unknown-linux-gnu/bin/ld > > -v > > Version of ld is: "GNU ld version 2.16.1" This can be a problem. Either upgrade your ld to newest version, or go to scripts/trylink and replace GC_SECTION=... here: # Static linking against glibc produces buggy executables # (glibc does not cope well with ld --gc-sections). # See sources.redhat.com/bugzilla/show_bug.cgi?id=3400 # Note that glibc is unsuitable for static linking anyway. # We are removing -Wl,--gc-sections from link command line. GC_SECTION=`( . ./.config if test x"$CONFIG_STATIC" = x"y"; then check_libc_is_glibc "" "-Wl,--gc-sections" else echo "-Wl,--gc-sections" fi )` by just GC_SECTION="" Note: not using --gc-sections will make bbox ~6 kb bigger. -- vda From vda.linux at googlemail.com Thu Apr 3 18:06:27 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 4 Apr 2008 03:06:27 +0200 Subject: [PATCH] init.c, halt command not working In-Reply-To: <000b01c895d2$64d17ae0$0a02a8c0@houdinineu> References: <47EFFC15.5040706@arcor.de> <200804022341.44253.vda.linux@googlemail.com> <000b01c895d2$64d17ae0$0a02a8c0@houdinineu> Message-ID: <200804040306.27980.vda.linux@googlemail.com> On Thursday 03 April 2008 23:33, Harald Kuethe wrote: > > ----- Original Message ----- > > From: "Denys Vlasenko" > > To: "Harald Kuethe" > > Cc: > > Sent: Wednesday, April 02, 2008 11:41 PM > > Subject: Re: [PATCH] init.c, halt command not working > > ... > > > kill() returns 0 (success), so the system thinks that SIGTERM is delivered. > > But init does not print your debug message. Very strange. > > killall did the very same thing: "kill(1, SIGTERM)" and it worked... > > > Please try attached idagnostic patch. > > It will spam your console if it will detect that init > > has TERM blocked or set to unexpected handler. > > > Try to "kill 1" and "kill -USR1 1" and report what init says. > > -- > > vda > > This patch adds no additional output :-/ > I put some more debugging output into the init_main function to find out where it hangs. > It showed that init_main does not return from the run_actions(ASKFIRST); call, > this explains that the additional diagnostics didn't come up. > > Following lines are copied from our inittab: > ... > ::askfirst:-/bin/sh > vc/2::askfirst:-/bin/sh > vc/3::askfirst:-/bin/sh > ... > > It looks as if the init process is replaced by the shell without finishing generating the virtual consoles and waiting in the while loop > because there are only 2 init processes here (there were some more (one for each vc) with the fork() instead of the vfork()) Huh. Soulds almost as if vfork() never returns in parent... ?! Can you check? static pid_t run(const struct init_action *a) { pid_t pid; sigset_t nmask, omask; /* Block sigchild while forking (why?) */ sigemptyset(&nmask); sigaddset(&nmask, SIGCHLD); sigprocmask(SIG_BLOCK, &nmask, &omask); pid = vfork(); +bb_error_msg("vfork returned %d", (int)pid); sigprocmask(SIG_SETMASK, &omask, NULL); ... and here: static void run_actions(int action_type) { struct init_action *a, *tmp; for (a = init_action_list; a; a = tmp) { tmp = a->next; if (a->action_type == action_type) { // Pointless: run() will error out if open of device fails. ///* a->terminal of "" means "init's console" */ //if (a->terminal[0] && access(a->terminal, R_OK | W_OK)) { // //message(L_LOG | L_CONSOLE, "Device %s cannot be opened in RW mode", a->terminal /*, strerror(errno)*/); // delete_init_action(a); //} else if (a->action_type & (SYSINIT | WAIT | CTRLALTDEL | SHUTDOWN | RESTART)) { +bb_error_msg("before waitfor(run(a))"); waitfor(run(a)); +bb_error_msg("after waitfor(run(a))"); delete_init_action(a); } else if (a->action_type & ONCE) { +bb_error_msg("before run(a)"); run(a); +bb_error_msg("after run(a)"); delete_init_action(a); } else if (a->action_type & (RESPAWN | ASKFIRST)) { /* Only run stuff with pid==0. If they have * a pid, that means it is still running */ if (a->pid == 0) { +bb_error_msg("before a->pid = run(a)"); a->pid = run(a); +bb_error_msg("after a->pid = run(a)"); } } and here: static void waitfor(pid_t pid) { /* waitfor(run(x)): protect against failed fork inside run() */ if (pid <= 0) return; +bb_error_msg("waiting for %d", (int)pid); /* Wait for any child (prevent zombies from exiting orphaned processes) * but exit the loop only when specified one has exited. */ while (wait(NULL) != pid) continue; } -- vda From external.Torsten.Tetz at de.bosch.com Fri Apr 4 02:04:05 2008 From: external.Torsten.Tetz at de.bosch.com (EXTERNAL Tetz Torsten (Praktikant; ST-FIR/ENG1)) Date: Fri, 4 Apr 2008 11:04:05 +0200 Subject: AW: AW: AW: AW: AW: AW: AW: segfaults with ver 1.10.0 on sh3 based board In-Reply-To: <200804040132.52346.vda.linux@googlemail.com> References: <200804022022.39365.vda.linux@googlemail.com> <200804040132.52346.vda.linux@googlemail.com> Message-ID: Hello Denys, >> Version of ld is: "GNU ld version 2.16.1" > > This can be a problem. Either upgrade your ld to newest version, > or go to scripts/trylink and replace GC_SECTION=... here: > > # Static linking against glibc produces buggy executables > # (glibc does not cope well with ld --gc-sections). > # See sources.redhat.com/bugzilla/show_bug.cgi?id=3400 > # Note that glibc is unsuitable for static linking anyway. > # We are removing -Wl,--gc-sections from link command line. > GC_SECTION=`( > . ./.config > if test x"$CONFIG_STATIC" = x"y"; then > check_libc_is_glibc "" "-Wl,--gc-sections" > else > echo "-Wl,--gc-sections" > fi > )` > > > by just > > GC_SECTION="" > > Note: not using --gc-sections will make bbox ~6 kb bigger. I tried to build version 1.10.0 with a replaced GC_SECTION=... and got a working binary. The size of my binary with some buildin applets increased by 11,9 kb from 294,8kb to 306,7kb. Right now that would be no problem with my board but I still want to test the official code with a newer LD. I will need some time now to prepare and test a new cross compiler toolchain for my board with a newer LD version. Thanks for your help. I will post again when I know how bbox builds with a newer LD version. Regards, Torsten From michele.sanges at otomelara.it Fri Apr 4 02:27:57 2008 From: michele.sanges at otomelara.it (Michele Sanges) Date: Fri, 04 Apr 2008 11:27:57 +0200 Subject: [patch] fbsplash Message-ID: <1207301277.2666.32.camel@pigreco> Hello, while fbsplash works well in root fs, it doesn't work when started from an initrd. It exhibits this behavior: 1. the nash shell, used in initrd, can't start the applet in background; it blocks forever the loading process. ==> I added back the code to fork the process (if this can be acceptable). 2. once started with the above fork code, if I want to redirect the messages from the console to the uart, passing to the kernel the option 'console=uart', it doesn't receive the commands from the fifo. ==> I substitute the file manipulation library functions (fopen, fgetline, fclose..) with the system one (open, read, close..) and thus it works. Il giorno ven, 28/03/2008 alle 09.06 -0400, Paul Fox ha scritto: > is the proper solution simply to open it twice, once for reading, > and once for writing? this guarantees a writer (which will never > write anything). Following the suggestion of Paul, now I open the fifo twice to use the opportunity to make the read blocking. After reading, the buffer is scanned in order to take the last command line. If the commands comes from the stdin, when the function returns 0 it assumes that has reached the EOF and it exits. Please, can you consider the attached patch? Thanks. Michele -------------- next part -------------- A non-text attachment was scrubbed... Name: fbsplash_040408.diff Type: text/x-patch Size: 6133 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080404/f385f3c8/attachment.bin From _mammoth_ at scarlet.be Fri Apr 4 02:53:24 2008 From: _mammoth_ at scarlet.be (Paul Stynen) Date: Fri, 04 Apr 2008 11:53:24 +0200 Subject: busybox 1.10.0 : tail Message-ID: <47F5FA94.6090807@scarlet.be> Hi, > uname -a : Linux ipbox 2.6.17-relook400 #1 Sun Mar 23 22:56:51 CET 2008 ppc unknown Problem : --------- > tail returns without any output. Version 1.9.2 on the same works as expected (shows 10 last lines). Best regards, Paul. From WHarms at bfs.de Fri Apr 4 04:07:07 2008 From: WHarms at bfs.de (walter harms) Date: Fri, 04 Apr 2008 13:07:07 +0200 Subject: AW: AW: AW: AW: AW: AW: AW: segfaults with ver 1.10.0 on sh3 based board In-Reply-To: References: <200804022022.39365.vda.linux@googlemail.com> <200804040132.52346.vda.linux@googlemail.com> Message-ID: <47F60BDB.5020108@bfs.de> please do not forget to inform the ld maintainer if the problem persists. re, wh EXTERNAL Tetz Torsten (Praktikant; ST-FIR/ENG1) wrote: > Hello Denys, > >>> Version of ld is: "GNU ld version 2.16.1" >> This can be a problem. Either upgrade your ld to newest version, >> or go to scripts/trylink and replace GC_SECTION=... here: >> >> # Static linking against glibc produces buggy executables >> # (glibc does not cope well with ld --gc-sections). >> # See sources.redhat.com/bugzilla/show_bug.cgi?id=3400 >> # Note that glibc is unsuitable for static linking anyway. >> # We are removing -Wl,--gc-sections from link command line. >> GC_SECTION=`( >> . ./.config >> if test x"$CONFIG_STATIC" = x"y"; then >> check_libc_is_glibc "" "-Wl,--gc-sections" >> else >> echo "-Wl,--gc-sections" >> fi >> )` >> >> >> by just >> >> GC_SECTION="" >> >> Note: not using --gc-sections will make bbox ~6 kb bigger. > > I tried to build version 1.10.0 with a replaced GC_SECTION=... > and got a working binary. > > The size of my binary with some buildin applets increased > by 11,9 kb from 294,8kb to 306,7kb. Right now that would be > no problem with my board but I still want to test the official > code with a newer LD. > > I will need some time now to prepare and test a new cross compiler > toolchain for my board with a newer LD version. > > Thanks for your help. > I will post again when I know how bbox builds with a newer LD version. > > Regards, > Torsten > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://busybox.net/cgi-bin/mailman/listinfo/busybox > > > From jsimmons at infradead.org Fri Apr 4 07:24:03 2008 From: jsimmons at infradead.org (James Simmons) Date: Fri, 4 Apr 2008 15:24:03 +0100 (BST) Subject: [PATCH] ping with timeouts and deadlines. Message-ID: This patch allows use to timeout for outgoing and incoming packets. See ping man pages for more details. Index: networking/ping.c =================================================================== --- networking/ping.c (revision 21635) +++ networking/ping.c (working copy) @@ -224,15 +224,17 @@ /* full(er) version */ -#define OPT_STRING ("qvc:s:I:4" USE_PING6("6")) +#define OPT_STRING ("qvc:s:w:W:I:4" USE_PING6("6")) enum { OPT_QUIET = 1 << 0, OPT_VERBOSE = 1 << 1, OPT_c = 1 << 2, OPT_s = 1 << 3, - OPT_I = 1 << 4, - OPT_IPV4 = 1 << 5, - OPT_IPV6 = (1 << 6) * ENABLE_PING6, + OPT_w = 1 << 4, + OPT_W = 1 << 5, + OPT_I = 1 << 6, + OPT_IPV4 = 1 << 7, + OPT_IPV6 = (1 << 8) * ENABLE_PING6, }; @@ -246,6 +248,9 @@ uint16_t myid; unsigned tmin, tmax; /* in us */ unsigned long long tsum; /* in us, sum of all times */ + unsigned deadline; + unsigned timeout; + unsigned sum; const char *hostname; const char *dotted; union { @@ -271,6 +276,9 @@ #define tmin (G.tmin ) #define tmax (G.tmax ) #define tsum (G.tsum ) +#define deadline (G.deadline ) +#define timeout (G.timeout ) +#define sum (G.sum ) #define hostname (G.hostname ) #define dotted (G.dotted ) #define pingaddr (G.pingaddr ) @@ -280,6 +288,8 @@ if (sizeof(G) > COMMON_BUFSIZE) \ BUG_ping_globals_too_big(); \ pingsock = -1; \ + datalen = DEFDATALEN; \ + timeout = MAXWAIT; \ tmin = UINT_MAX; \ } while (0) @@ -311,7 +321,7 @@ tavg / 1000, tavg % 1000, tmax / 1000, tmax % 1000); } - exit(nreceived == 0); /* (nreceived == 0) is true (1) -- 'failure' */ + exit(nreceived == 0 || (deadline && nreceived < pingcount)); /* (nreceived == 0) is true (1) -- 'failure' */ } static void sendping_tail(void (*sp)(int), const void *pkt, int size_pkt) @@ -327,13 +337,23 @@ if (sz != size_pkt) bb_error_msg_and_die(bb_msg_write_error); - signal(SIGALRM, sp); - if (pingcount == 0 || ntransmitted < pingcount) { /* schedule next in 1s */ + if (pingcount == 0 || deadline || ntransmitted < pingcount) { /* schedule next in 1s */ + if (deadline && ((sum += PINGINTERVAL) >= deadline)) + signal(SIGALRM, pingstats); + else + signal(SIGALRM, sp); alarm(PINGINTERVAL); - } else { /* done, wait for the last ping to come back */ - /* todo, don't necessarily need to wait so long... */ + } else { + /* done, wait for the last ping to come back */ + unsigned expire = timeout; + + if (nreceived) { + expire = 2 * tmax / 1000; + if (expire == 0) + expire = 1; + } signal(SIGALRM, pingstats); - alarm(MAXWAIT); + alarm(expire); } } @@ -686,20 +706,22 @@ int ping_main(int argc ATTRIBUTE_UNUSED, char **argv) { len_and_sockaddr *lsa; - char *opt_c, *opt_s; + char *opt_c, *opt_s, *opt_w, *opt_W; USE_PING6(sa_family_t af = AF_UNSPEC;) INIT_G(); - datalen = DEFDATALEN; - /* exactly one argument needed, -v and -q don't mix */ opt_complementary = "=1:q--v:v--q"; - getopt32(argv, OPT_STRING, &opt_c, &opt_s, &opt_I); + getopt32(argv, OPT_STRING, &opt_c, &opt_s, &opt_w, &opt_W, &opt_I); if (option_mask32 & OPT_c) pingcount = xatoul(opt_c); // -c if (option_mask32 & OPT_s) datalen = xatou16(opt_s); // -s + if (option_mask32 & OPT_w) + deadline = xatou16(opt_w); // -w + if (option_mask32 & OPT_W) + timeout = xatou16(opt_W); // -W if (option_mask32 & OPT_I) { // -I if_index = if_nametoindex(opt_I); if (!if_index) { Index: include/usage.h =================================================================== --- include/usage.h (revision 21635) +++ include/usage.h (working copy) @@ -2921,9 +2921,14 @@ "Send ICMP ECHO_REQUEST packets to network hosts\n" \ "\nOptions:" \ "\n -4, -6 Force IPv4 or IPv6 hostname resolution" \ - "\n -c CNT Send only CNT pings" \ + "\n -c CNT Send only CNT pings. With deadline we wait " \ + "\n for count reply packets, until the timeout expires " \ "\n -s SIZE Send SIZE data bytes in packets (default=56)" \ "\n -I iface/IP Use interface or IP address as source" \ + "\n -w deadline Specify a timeout, in seconds, before ping exits " \ + "\n even if all the count packets are sent" \ + "\n -W timeout Time to wait for a response, in seconds, otherwise wait " \ + "\n for two round trip times" \ "\n -q Quiet, only displays output at start" \ "\n and when finished" \ From vda.linux at googlemail.com Fri Apr 4 10:17:01 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 4 Apr 2008 19:17:01 +0200 Subject: [patch] fbsplash In-Reply-To: <1207301277.2666.32.camel@pigreco> References: <1207301277.2666.32.camel@pigreco> Message-ID: <200804041917.01371.vda.linux@googlemail.com> On Friday 04 April 2008 11:27, Michele Sanges wrote: > Hello, > > while fbsplash works well in root fs, it doesn't work when started from > an initrd. It exhibits this behavior: > > 1. the nash shell, used in initrd, can't start the applet in background; > it blocks forever the loading process. > > ==> I added back the code to fork the process (if this can be > acceptable). I'm sorry, but it is not acceptable. In Unix, each tool should do one thing. fbsplash should not be hardwired for one application (boot splash). What is someone needs to want for fbsplash to finish? Make it so that people who want to background it, can do it, and the rest is not forced to do so. If you are using a shell which is incapable of backgrounding processes, write a helper tool, say: daemon which forks, child execs " ", and parent exits. + if (*fifo_filename != '-') { You disallow names like "-foo"? + // opens the fifo twice + fd_r = xopen(fifo_filename, O_RDONLY); + fd_w = xopen(fifo_filename, O_WRONLY); // only for make the 'read' blocking + } + else { + fd_r = xopen("/dev/stdin", O_RDONLY); How about just using file descriptor 0? > 2. once started with the above fork code, if I want to redirect the > messages from the console to the uart, passing to the kernel the option > 'console=uart', it doesn't receive the commands from the fifo. Why? > ==> I substitute the file manipulation library functions (fopen, > fgetline, fclose..) with the system one (open, read, close..) and thus > it works. Well, it would be nice to understand why it makes a difference. > Il giorno ven, 28/03/2008 alle 09.06 -0400, Paul Fox ha scritto: > > is the proper solution simply to open it twice, once for reading, > > and once for writing? this guarantees a writer (which will never > > write anything). > > Following the suggestion of Paul, now I open the fifo twice to use the > opportunity to make the read blocking. How about achieving it like this: fp = xfopen_stdin(fifo_filename); + if (fp != stdin) + open(fifo_filename, O_WRONLY); and removing this part: // We got EOF/error on fp if (ferror(fp)) goto exit_cmd; fclose(fp); if (LONE_DASH(fifo_filename) || stat(fifo_filename, &statbuf) != 0 || !S_ISFIFO(statbuf.st_mode) ) { goto exit_cmd; } // It's really a named pipe! // For named pipes, we want to support this: // mkfifo cmd_pipe // fbsplash -f cmd_pipe .... & // ... // echo 33 >cmd_pipe // ... // echo 66 >cmd_pipe // This means that on EOF, we need to close/open cmd_pipe // (just reading again works too, but it hogs CPU) fp = xfopen_stdin(fifo_filename); // blocks on open > After reading, the buffer is > scanned in order to take the last command line. + cmd_buf[nlen] = '\0'; + + // when we have many buffered lines already in the pipe, takes the last one. + p = cmd_buf; + last_cmd = cmd_buf; + while (((p = strchr(last_cmd, '\n')) != (cmd_buf + nlen - 1)) && (p != NULL)) { + last_cmd = (p + 1); + } This will break if we get, say, 34 byte long string: "1\n2\n3\n.....\n34\n" read will eat 32 bytes: "1\n2\n3\n.....\n3" and you will display 3% bar. -- vda From vda.linux at googlemail.com Fri Apr 4 10:20:20 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 4 Apr 2008 19:20:20 +0200 Subject: busybox 1.10.0 : tail In-Reply-To: <47F5FA94.6090807@scarlet.be> References: <47F5FA94.6090807@scarlet.be> Message-ID: <200804041920.20998.vda.linux@googlemail.com> On Friday 04 April 2008 11:53, Paul Stynen wrote: > Hi, > > > uname -a : > Linux ipbox 2.6.17-relook400 #1 Sun Mar 23 22:56:51 CET 2008 ppc unknown > > Problem : > --------- > > tail returns without any output. > > Version 1.9.2 on the same works as expected (shows 10 last lines). There is a fix for it in http://busybox.net/downloads/fixes-1.10.0/ Can you confirm that it works? -- vda From vda.linux at googlemail.com Fri Apr 4 13:22:03 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 4 Apr 2008 22:22:03 +0200 Subject: [patch] fbsplash In-Reply-To: <200804041917.01371.vda.linux@googlemail.com> References: <1207301277.2666.32.camel@pigreco> <200804041917.01371.vda.linux@googlemail.com> Message-ID: <200804042222.03551.vda.linux@googlemail.com> On Friday 04 April 2008 19:17, Denys Vlasenko wrote: > > while fbsplash works well in root fs, it doesn't work when started from > > an initrd. It exhibits this behavior: > > > > 1. the nash shell, used in initrd, can't start the applet in background; > > it blocks forever the loading process. > > > > ==> I added back the code to fork the process (if this can be > > acceptable). > > I'm sorry, but it is not acceptable. In Unix, each tool should do > one thing. fbsplash should not be hardwired for one application > (boot splash). What is someone needs to want for fbsplash to finish? I meant "needs to WAIT for fbsplash to finish" - i.e. what if someone doesn't want fbsplash to daemonize. -- vda From harald-tuxbox at arcor.de Fri Apr 4 13:40:02 2008 From: harald-tuxbox at arcor.de (Harald Kuethe) Date: Fri, 4 Apr 2008 22:40:02 +0200 Subject: [PATCH] init.c, halt command not working References: <47EFFC15.5040706@arcor.de> <200804022341.44253.vda.linux@googlemail.com> <000b01c895d2$64d17ae0$0a02a8c0@houdinineu> <200804040306.27980.vda.linux@googlemail.com> Message-ID: <000801c89694$1a5fc7b0$0a02a8c0@houdinineu> ----- Original Message ----- From: "Denys Vlasenko" To: "Harald Kuethe" Cc: Sent: Friday, April 04, 2008 3:06 AM Subject: Re: [PATCH] init.c, halt command not working > On Thursday 03 April 2008 23:33, Harald Kuethe wrote: >> > ----- Original Message ----- >> > From: "Denys Vlasenko" >> > To: "Harald Kuethe" >> > Cc: >> > Sent: Wednesday, April 02, 2008 11:41 PM >> > Subject: Re: [PATCH] init.c, halt command not working >> >> ... >> >> > kill() returns 0 (success), so the system thinks that SIGTERM is delivered. >> > But init does not print your debug message. Very strange. >> > killall did the very same thing: "kill(1, SIGTERM)" and it worked... >> >> > Please try attached idagnostic patch. >> > It will spam your console if it will detect that init >> > has TERM blocked or set to unexpected handler. >> >> > Try to "kill 1" and "kill -USR1 1" and report what init says. >> > -- >> > vda >> >> This patch adds no additional output :-/ >> I put some more debugging output into the init_main function to find out where it hangs. >> It showed that init_main does not return from the run_actions(ASKFIRST); call, >> this explains that the additional diagnostics didn't come up. >> >> Following lines are copied from our inittab: >> ... >> ::askfirst:-/bin/sh >> vc/2::askfirst:-/bin/sh >> vc/3::askfirst:-/bin/sh >> ... >> >> It looks as if the init process is replaced by the shell without finishing generating the virtual consoles and waiting in the while loop >> because there are only 2 init processes here (there were some more (one for each vc) with the fork() instead of the vfork()) > > Huh. Soulds almost as if vfork() never returns in parent... ?! > Can you check? > > static pid_t run(const struct init_action *a) > { > pid_t pid; > sigset_t nmask, omask; > > /* Block sigchild while forking (why?) */ > sigemptyset(&nmask); > sigaddset(&nmask, SIGCHLD); > sigprocmask(SIG_BLOCK, &nmask, &omask); > pid = vfork(); > +bb_error_msg("vfork returned %d", (int)pid); > sigprocmask(SIG_SETMASK, &omask, NULL); > ... > > > and here: > > > static void run_actions(int action_type) > { > struct init_action *a, *tmp; > > for (a = init_action_list; a; a = tmp) { > tmp = a->next; > if (a->action_type == action_type) { > // Pointless: run() will error out if open of device fails. > ///* a->terminal of "" means "init's console" */ > //if (a->terminal[0] && access(a->terminal, R_OK | W_OK)) { > // //message(L_LOG | L_CONSOLE, "Device %s cannot be opened in RW mode", a->terminal /*, strerror(errno)*/); > // delete_init_action(a); > //} else > if (a->action_type & (SYSINIT | WAIT | CTRLALTDEL | SHUTDOWN | RESTART)) { > +bb_error_msg("before waitfor(run(a))"); > waitfor(run(a)); > +bb_error_msg("after waitfor(run(a))"); > delete_init_action(a); > } else if (a->action_type & ONCE) { > +bb_error_msg("before run(a)"); > run(a); > +bb_error_msg("after run(a)"); > delete_init_action(a); > } else if (a->action_type & (RESPAWN | ASKFIRST)) { > /* Only run stuff with pid==0. If they have > * a pid, that means it is still running */ > if (a->pid == 0) { > +bb_error_msg("before a->pid = run(a)"); > a->pid = run(a); > +bb_error_msg("after a->pid = run(a)"); > } > } > > > and here: > > static void waitfor(pid_t pid) > { > /* waitfor(run(x)): protect against failed fork inside run() */ > if (pid <= 0) > return; > +bb_error_msg("waiting for %d", (int)pid); > /* Wait for any child (prevent zombies from exiting orphaned processes) > * but exit the loop only when specified one has exited. */ > while (wait(NULL) != pid) > continue; > } > > > -- > vda Ok, here's the result: The first part is with a vfork() call in static pid_t run(const struct init_action *a) the second part uses fork() Freeing unused kernel memory: 68k init *Start init_main init: waiting for 10 *console_init init started init started: BusyBox v1.10.0 (2008-04-01 22:01:03 CEST) *single? *run_actions init: before waitfor(run(a)) init: run vfork returned 0 init: run vfork returned 11 *call bb_signals init: waiting for 11 ... init: after waitfor(run(a)) *signals *RESPAWN *ASKFIRST init: before a->pid = run(a) init: run vfork returned 0 Please press Enter to activate this console. init: run vfork returned 80 *call bb_signals init: after a->pid = run(a) init: before a->pid = run(a) init: run vfork returned 0 BusyBox v1.10.0 (2008-04-01 22:01:03 CEST) built-in shell (ash) Enter 'help' for a list of built-in commands. / # / # / # ps -ef PID USER VSZ STAT COMMAND 1 root 0 D init 2 root 0 S [keventd] 3 root 0 S [ksoftirqd_CPU0] 4 root 0 S [kswapd] 5 root 0 S [bdflush] 6 root 0 S [kupdated] 7 root 0 S [cifsoplockd] 8 root 0 S [mtdblockd] 9 root 0 S [rpciod] 21 root 0 S inetd 56 root 0 S [avia_av_wdt] 60 root 0 S [avia_gt_wdt] 80 root 0 S -/bin/sh 81 root 0 S init 83 root 0 R ps -ef / # / # kill 1 / # kill -SIGUSR1 1 / # halt / # killall init *HK: halt_reboot_pwoff init: before waitfor(run(a)) init: run vfork returned 0 init: run vfork returned 86 *call bb_signals init: waiting for 86 init: after waitfor(run(a)) The system is going down NOW! init: waiting for 95 Sending SIGTERM to all processes Sending SIGKILL to all processes Requesting system reboot *************************************************************** with fork() instead of vfork() Freeing unused kernel memory: 68k init *Start init_main init: waiting for 10 *console_init *init started init started: BusyBox v1.10.0 (2008-04-01 22:01:03 CEST) *single? run_actions init: before waitfor(run(a)) init: run fork returned 11 *call bb_signals init: waiting for 11 init: run fork returned 0 ... init: after waitfor(run(a)) *signals *RESPAWN *ASKFIRST init: before a->pid = run(a) init: run fork returned 80 *call bb_signals init: after a->pid = run(a) init: before a->pid = run(a) init: run fork returned 81 init: run fork returned 0 Please press Enter to activate this console. init: run fork returned 0 call bb_signals init: after a->pid = run(a) init: before a->pid = run(a) init: run fork returned 82 BusyBox v1.10.0 (2008-04-01 22:01:03 CEST) built-in shell (ash) Enter 'help' for a list of built-in commands. init: run fork returned 0 *call bb_signals init: after a->pid = run(a) init: before a->pid = run(a) init: run fork returned 0 init: run fork returned 84 *call bb_signals init: after a->pid = run(a) init: before a->pid = run(a) init: run fork returned 85 init: run fork returned 0 *call bb_signals init: after a->pid = run(a) init: before a->pid = run(a) init: run fork returned 0 init: run fork returned 86 *call bb_signals init: after a->pid = run(a) *sleep(5) correct TERM handler: 0x1004144c TERM is not blocked TERM is not pending / # ps -ef PID USER VSZ STAT COMMAND 1 root 0 S init 2 root 0 S [keventd] 3 root 0 S [ksoftirqd_CPU0] 4 root 0 S [kswapd] 5 root 0 S [bdflush] 6 root 0 S [kupdated] 7 root 0 S [cifsoplockd] 8 root 0 S [mtdblockd] 9 root 0 S [rpciod] 21 root 0 S inetd 56 root 0 S [avia_av_wdt] 60 root 0 S [avia_gt_wdt] 80 root 0 S -/bin/sh 81 root 0 S init 82 root 0 S init 84 root 0 S init 85 root 0 S init 86 root 0 S init 87 root 0 R ps -ef / # / # / # halt *HK: halt_reboot_pwoff init: before waitfor(run(a)) init: run fork returned 89 init: run fork returned 0 *call bb_signals init: waiting for 89 init: after waitfor(run(a)) The system is going down NOW! init: waiting for 98 Sending SIGTERM to all processes Sending SIGKILL to all processes Requesting system halt System halted. *something => my debug printouts Thanks four your help Harald From vda.linux at googlemail.com Fri Apr 4 13:40:18 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 4 Apr 2008 22:40:18 +0200 Subject: [patch] fbsplash In-Reply-To: <1207301277.2666.32.camel@pigreco> References: <1207301277.2666.32.camel@pigreco> Message-ID: <200804042240.18312.vda.linux@googlemail.com> On Friday 04 April 2008 11:27, Michele Sanges wrote: > Il giorno ven, 28/03/2008 alle 09.06 -0400, Paul Fox ha scritto: > > is the proper solution simply to open it twice, once for reading, > > and once for writing? this guarantees a writer (which will never > > write anything). > > Following the suggestion of Paul, now I open the fifo twice to use the > opportunity to make the read blocking. This seems to be a good idea. I am committing the attached patch to svn. Saves ~70 bytes. -- vda -------------- next part -------------- A non-text attachment was scrubbed... Name: 7.patch Type: text/x-diff Size: 2981 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080404/27883eef/attachment.patch From pgf at brightstareng.com Fri Apr 4 13:54:40 2008 From: pgf at brightstareng.com (Paul Fox) Date: Fri, 04 Apr 2008 16:54:40 -0400 Subject: [patch] fbsplash In-Reply-To: vda.linux's message of Fri, 04 Apr 2008 22:40:18 +0200. <200804042240.18312.vda.linux@googlemail.com> Message-ID: <6944.1207342480@brightstareng.com> denys wrote: > On Friday 04 April 2008 11:27, Michele Sanges wrote: > > Il giorno ven, 28/03/2008 alle 09.06 -0400, Paul Fox ha scritto: > > > is the proper solution simply to open it twice, once for reading, > > > and once for writing? this guarantees a writer (which will never > > > write anything). > > > > Following the suggestion of Paul, now I open the fifo twice to use the > > opportunity to make the read blocking. > > This seems to be a good idea. I am committing the attached