You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(100) |
Jun
(134) |
Jul
(149) |
Aug
(123) |
Sep
(185) |
Oct
(122) |
Nov
(59) |
Dec
(127) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
(128) |
Feb
(233) |
Mar
(210) |
Apr
(196) |
May
(85) |
Jun
(96) |
Jul
(76) |
Aug
(149) |
Sep
(65) |
Oct
(78) |
Nov
(121) |
Dec
(82) |
2006 |
Jan
(249) |
Feb
(181) |
Mar
(176) |
Apr
(156) |
May
(128) |
Jun
(102) |
Jul
(157) |
Aug
(80) |
Sep
(42) |
Oct
(49) |
Nov
(36) |
Dec
(42) |
2007 |
Jan
(64) |
Feb
(38) |
Mar
(45) |
Apr
(74) |
May
(26) |
Jun
(20) |
Jul
(17) |
Aug
(12) |
Sep
(40) |
Oct
(7) |
Nov
(14) |
Dec
(16) |
2008 |
Jan
(52) |
Feb
(49) |
Mar
(90) |
Apr
(80) |
May
(78) |
Jun
(82) |
Jul
(25) |
Aug
(8) |
Sep
(10) |
Oct
(11) |
Nov
(3) |
Dec
(17) |
2009 |
Jan
(12) |
Feb
(16) |
Mar
(20) |
Apr
(14) |
May
(17) |
Jun
(10) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(10) |
Nov
(30) |
Dec
(1) |
2010 |
Jan
(2) |
Feb
(7) |
Mar
(22) |
Apr
(6) |
May
(33) |
Jun
(5) |
Jul
(4) |
Aug
(38) |
Sep
(46) |
Oct
(23) |
Nov
(9) |
Dec
(5) |
2011 |
Jan
(21) |
Feb
(27) |
Mar
(1) |
Apr
(18) |
May
(12) |
Jun
(12) |
Jul
(10) |
Aug
(30) |
Sep
(4) |
Oct
|
Nov
(9) |
Dec
(19) |
2012 |
Jan
(26) |
Feb
(6) |
Mar
(8) |
Apr
(7) |
May
(3) |
Jun
|
Jul
(10) |
Aug
(1) |
Sep
(18) |
Oct
(5) |
Nov
|
Dec
(1) |
2013 |
Jan
(27) |
Feb
|
Mar
(11) |
Apr
(14) |
May
|
Jun
(1) |
Jul
|
Aug
(7) |
Sep
|
Oct
(1) |
Nov
(2) |
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
(25) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
(2) |
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2025 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Ma Y. Wu(马. <ma...@gh...> - 2009-03-03 04:18:06
|
-----邮件原件----- 发件人: col...@li... [mailto:col...@li...] 发送时间: 2009年3月2日 20:14 收件人: col...@li... 主题: coLinux-users Digest, Vol 35, Issue 1 Send coLinux-users mailing list submissions to col...@li... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/colinux-users or, via email, send a message with subject or body 'help' to col...@li... You can reach the person managing the list at col...@li... When replying, please edit your Subject line so it is more specific than "Re: Contents of coLinux-users digest..." Today's Topics: 1. Fedora 10 build posted (Bill C. Riemers) ---------------------------------------------------------------------- Message: 1 Date: Sun, 1 Mar 2009 19:28:59 -0500 From: "Bill C. Riemers" <do...@fr...> Subject: [coLinux-users] Fedora 10 build posted To: coLinux Users <col...@li...> Message-ID: <23b...@ma...> Content-Type: text/plain; charset=UTF-8 Greetings follow coLinux fans, I just posted a Fedora 10 build on Source Forge. If you are already using a Fedora build, you can probably just upgrade your existing build, rather than installing a new build. Unlike the last few Fedora images I posted, this one is clean install. In fact the image I posted has never been booted. Don't worry, I tested a copy, and the major features work. I did not configure X11 in this image. Instead, I created the aliases "installgnome" and "installkde". Those who do not want X, have nothing to uninstall. Those who want X, can run the respective install command. The "fix.sh" script is now, colinux_fix, and is installed as a service. So if you think you need "fix.sh", instead run "service colinux_fix enable". This time I left SELinux and iptables enabled for better security. If you are willing to trade security for speed, you can disable these features. Bill ------------------------------ ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ------------------------------ _______________________________________________ coLinux-users mailing list coL...@li... https://lists.sourceforge.net/lists/listinfo/colinux-users End of coLinux-users Digest, Vol 35, Issue 1 ******************************************** |
From: Henry N. <hen...@ar...> - 2009-03-02 22:40:28
|
Hello Bill, thanks, that you have made the image for X-less users smaller now. -- Henry N. |
From: Bill C. R. <do...@fr...> - 2009-03-02 00:29:02
|
Greetings follow coLinux fans, I just posted a Fedora 10 build on Source Forge. If you are already using a Fedora build, you can probably just upgrade your existing build, rather than installing a new build. Unlike the last few Fedora images I posted, this one is clean install. In fact the image I posted has never been booted. Don't worry, I tested a copy, and the major features work. I did not configure X11 in this image. Instead, I created the aliases "installgnome" and "installkde". Those who do not want X, have nothing to uninstall. Those who want X, can run the respective install command. The "fix.sh" script is now, colinux_fix, and is installed as a service. So if you think you need "fix.sh", instead run "service colinux_fix enable". This time I left SELinux and iptables enabled for better security. If you are willing to trade security for speed, you can disable these features. Bill |
From: GuyBrush <guy...@gm...> - 2009-02-25 15:52:17
|
Henry Nestler wrote: > Am 11.02.2009 17:27, schrieb GuyBrush: >> Hello, >> I’m a very happy colinux user and have been using it for a while. >> For some reason for the last two months I have been getting heavy HD >> usage which does not allow me to run commands in the “andLinux Console >> (FLTK)” or remote terminal. >> >> I’m using Andlinux which has colinux kernel ver. 2.6.22.18-co-0.7.3 and >> I upgrade to Ubuntu 8.10. I also have the locatedb disabled in cron. I >> tried using iotop but its not supported by the compiled colinux kernel. >> My host OS is XP home sp3 edition. >> >> Is there any more information I could provide that will help give more >> clues? >> I tried looking at syslog and I think this part is where the system >> stops responding with the heavy HD usage. >> [... >> >> mem=256 >> root=/dev/cobd0 >> initrd=initrd.gz >> kernel=vmlinux >> exec0="pulseaudio\pulseaudio.exe" >> cobd0=Drives\base.drv >> cobd1=Drives\swap.drv >> eth0=slirp >> eth1=tuntap,"TAP-Colinux",00:11:22:33:44:55 >> cofs0=C:\ >> >> >> Is there any known problem with colinux and antivirus software on the >> host OS? >> I have a samba mount and I’m using Comodo Firewall, Spybot Tea Timer and >> Avast anti virus. >> >> Also… I could be wrong but I notice the lockups happen when I’m not >> watching or the computer is idling. :o) > > Some security software means *.drv are Windows device drivers and > checks the complete file before you have read/write access. > > Disable one of the Avast daemons to see, that is the problem you have. > There is something in the "expert mode" of Avast, there you can stop > or halt a single of the sub processes. If that is the the problem > exclude the coLinux image file from scanner. > > Rename the files "base.drv" and "swap.drv" into something that not > ends with "drv", for example ".img" and change the names in config > file. Than exclude this extension ".img" from virus scanner runtime scan. This had worked perfectly for the past two days! Thank you The trick was to find the proper place to exclude files from avast scan. Avast has a couple of different places you can exclude files from. Right clicking the "a" icon near the task bar clock and clicking on program settings and exclusion get you to the right place. > > All coLinux related IO counts you can check with > "watch cat /proc/colinux/stats" > (only in the coLinux devel version 0.8.x) > > Or on the windows side you can find the task with "taskman" or the > tool TaskExplorer from http://www.sysinternals.com I tried this one a little bit but It did not tell me it was avast that was acting up. Thanks again and now I can go back on saving the world :o) |
From: Henry N. <hen...@ar...> - 2009-02-11 19:33:35
|
Am 11.02.2009 17:27, schrieb GuyBrush: > Hello, > I’m a very happy colinux user and have been using it for a while. > For some reason for the last two months I have been getting heavy HD > usage which does not allow me to run commands in the “andLinux Console > (FLTK)” or remote terminal. > > I’m using Andlinux which has colinux kernel ver. 2.6.22.18-co-0.7.3 and > I upgrade to Ubuntu 8.10. I also have the locatedb disabled in cron. I > tried using iotop but its not supported by the compiled colinux kernel. > My host OS is XP home sp3 edition. > > Is there any more information I could provide that will help give more > clues? > I tried looking at syslog and I think this part is where the system > stops responding with the heavy HD usage. > [... > > mem=256 > root=/dev/cobd0 > initrd=initrd.gz > kernel=vmlinux > exec0="pulseaudio\pulseaudio.exe" > cobd0=Drives\base.drv > cobd1=Drives\swap.drv > eth0=slirp > eth1=tuntap,"TAP-Colinux",00:11:22:33:44:55 > cofs0=C:\ > > > Is there any known problem with colinux and antivirus software on the > host OS? > I have a samba mount and I’m using Comodo Firewall, Spybot Tea Timer and > Avast anti virus. > > Also… I could be wrong but I notice the lockups happen when I’m not > watching or the computer is idling. :o) Some security software means *.drv are Windows device drivers and checks the complete file before you have read/write access. Disable one of the Avast daemons to see, that is the problem you have. There is something in the "expert mode" of Avast, there you can stop or halt a single of the sub processes. If that is the the problem exclude the coLinux image file from scanner. Rename the files "base.drv" and "swap.drv" into something that not ends with "drv", for example ".img" and change the names in config file. Than exclude this extension ".img" from virus scanner runtime scan. All coLinux related IO counts you can check with "watch cat /proc/colinux/stats" (only in the coLinux devel version 0.8.x) Or on the windows side you can find the task with "taskman" or the tool TaskExplorer from http://www.sysinternals.com -- Henry N. |
From: GuyBrush <guy...@gm...> - 2009-02-11 16:27:54
|
Hello, I’m a very happy colinux user and have been using it for a while. For some reason for the last two months I have been getting heavy HD usage which does not allow me to run commands in the “andLinux Console (FLTK)” or remote terminal. I’m using Andlinux which has colinux kernel ver. 2.6.22.18-co-0.7.3 and I upgrade to Ubuntu 8.10. I also have the locatedb disabled in cron. I tried using iotop but its not supported by the compiled colinux kernel. My host OS is XP home sp3 edition. Is there any more information I could provide that will help give more clues? I tried looking at syslog and I think this part is where the system stops responding with the heavy HD usage. Feb 10 22:36:31 andLinux mysqld[2586]: 090210 22:36:31 [Note] /usr/sbin/mysqld: ready for connections. Feb 10 22:36:31 andLinux mysqld[2586]: Version: '5.0.67-0ubuntu6' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu) Feb 10 22:36:31 andLinux kernel: eth1: no IPv6 routers present Feb 10 22:36:31 andLinux kernel: eth0: no IPv6 routers present Feb 10 22:36:31 andLinux /etc/mysql/debian-start[2634]: Upgrading MySQL tables if necessary. Feb 10 22:36:32 andLinux /etc/mysql/debian-start[2637]: Looking for 'mysql' in: /usr/bin/mysql Feb 10 22:36:32 andLinux /etc/mysql/debian-start[2637]: Looking for 'mysqlcheck' in: /usr/bin/mysqlcheck Feb 10 22:36:32 andLinux /etc/mysql/debian-start[2637]: This installation of MySQL is already upgraded to 5.0.67, use --force if you still n eed to run mysql_upgrade Feb 10 22:36:32 andLinux /etc/mysql/debian-start[2664]: Checking for insecure root accounts. Feb 10 22:36:32 andLinux /etc/mysql/debian-start[2676]: Triggering myisam-recover for all MyISAM tables Feb 10 22:36:45 andLinux /usr/sbin/cron[2903]: (CRON) INFO (pidfile fd = 3) Feb 10 22:36:45 andLinux /usr/sbin/cron[2909]: (CRON) STARTUP (fork ok) Feb 10 22:36:45 andLinux /usr/sbin/cron[2909]: (CRON) INFO (Running @reboot jobs) Feb 10 22:39:01 andLinux /USR/SBIN/CRON[3148]: (root) CMD ( [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 | xargs -n 200 -r -0 rm) Feb 10 22:56:22 andLinux -- MARK -- Feb 10 22:59:54 andLinux init: tty1 main process ended, respawning Feb 10 23:09:01 andLinux /USR/SBIN/CRON[8943]: (root) CMD ( [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 | xargs -n 200 -r -0 rm) Feb 10 23:17:01 andLinux /USR/SBIN/CRON[8952]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Feb 11 09:23:23 andLinux syslogd 1.5.0#2ubuntu6: restart. Feb 11 09:23:24 andLinux kernel: Cannot find map file. Feb 11 09:23:24 andLinux kernel: Loaded 9213 symbols from 2 modules. Feb 11 09:23:24 andLinux kernel: Linux version 2.6.22.18-co-0.7.3 (hn@hn-lt) (gcc version 4.1.2) #1 PREEMPT Wed Apr 16 18:50:10 UTC 2008 Feb 11 09:23:24 andLinux kernel: 256MB LOWMEM available. I think swap is working ok and its 255mb This is my settings.txt file mem=256 root=/dev/cobd0 initrd=initrd.gz kernel=vmlinux exec0="pulseaudio\pulseaudio.exe" cobd0=Drives\base.drv cobd1=Drives\swap.drv eth0=slirp eth1=tuntap,"TAP-Colinux",00:11:22:33:44:55 cofs0=C:\ Is there any known problem with colinux and antivirus software on the host OS? I have a samba mount and I’m using Comodo Firewall, Spybot Tea Timer and Avast anti virus. Also… I could be wrong but I notice the lockups happen when I’m not watching or the computer is idling. :o) Thank you |
From: Henry N. <hen...@ar...> - 2009-02-09 21:11:25
|
Henry Nestler wrote: > Olivier Perron wrote: >> With my XP SP3 box, I've got systematic BSOD with latest development >> snapshot devel-coLinux-20090208 at colinux driver loading. >> This happens first at the end of the installation process and then >> after each reboot of the PC. >> Only way to resolve the issue: start XP in safe mode and uninstall colinux. > > Thanks for this report. I can see it here also. > > The file size of linux.sys is some more bigger as normal. Normal is > 88064 bytes, the linux.sys in broken build is 100352. I will check what' > going wrong there. > > By the while, the autobuild from same source is ok. There file linux.sys > has filesize 87040 bytes there: > http://www.henrynestler.com/colinux/autobuild/devel-20090208 > Ok, solved. linux.sys was build with debugging (-ggdb). I have forgotten to change back this option from last of my debugging the slirp daemon. Seems it was not a good idea for a NT kernel driver. Sorry. New files will upload in some minutes. Build will stamp as 20090209. -- Henry N. |
From: Henry N. <hen...@ar...> - 2009-02-09 19:47:28
|
Olivier Perron wrote: > With my XP SP3 box, I've got systematic BSOD with latest development > snapshot devel-coLinux-20090208 at colinux driver loading. > This happens first at the end of the installation process and then > after each reboot of the PC. > Only way to resolve the issue: start XP in safe mode and uninstall colinux. Thanks for this report. I can see it here also. The file size of linux.sys is some more bigger as normal. Normal is 88064 bytes, the linux.sys in broken build is 100352. I will check what' going wrong there. By the while, the autobuild from same source is ok. There file linux.sys has filesize 87040 bytes there: http://www.henrynestler.com/colinux/autobuild/devel-20090208 -- Henry N. |
From: Olivier P. <oli...@gm...> - 2009-02-09 13:12:49
|
With my XP SP3 box, I've got systematic BSOD with latest development snapshot devel-coLinux-20090208 at colinux driver loading. This happens first at the end of the installation process and then after each reboot of the PC. Only way to resolve the issue: start XP in safe mode and uninstall colinux. Olivier |
From: Shai V. <sva...@gm...> - 2009-02-06 13:25:33
|
Hello Henry, Here's the output from gdb: ====== START GDB OUTPUT ====== C:\Program Files\coLinux>\MinGW\bin\gdb.exe colinux-slirp-net-daemon-dbg.exe GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-mingw32"... (gdb) set args -i 5244 -u 0 (gdb) run Starting program: C:\Program Files\coLinux/colinux-slirp-net-daemon-dbg.exe -i 5 244 -u 0 conet-slirp-daemon: running Program received signal SIGSEGV, Segmentation fault. tcp_input (m=0xaba528, iphlen=20, inso=0xe07ef8) at src/colinux/user/slirp/tcp_input.c:1460 1460 if (ti->ti_len && (unsigned)ti->ti_len <= 5 && (gdb) print ti $1 = (struct tcpiphdr *) 0xaba55c (gdb) print ti->ti_len There is no member named ti_len. (gdb) print ti->ti_i.ih_len Cannot access memory at address 0xaba566 (gdb) print ti->ti_i Cannot access memory at address 0xaba55c (gdb) ====== END GDB OUTPUT ====== As you can see, ti_len is not a member of ti, it's a macro, per file tcpip.h in slirp source directory (see line 40): struct tcpiphdr { struct ipovly ti_i; /* overlaid ip structure */ struct tcphdr ti_t; /* tcp header */ }; #define ti_next ti_i.ih_next #define ti_prev ti_i.ih_prev #define ti_x1 ti_i.ih_x1 #define ti_pr ti_i.ih_pr #define ti_len ti_i.ih_len #define ti_src ti_i.ih_src #define ti_dst ti_i.ih_dst #define ti_sport ti_t.th_sport #define ti_dport ti_t.th_dport And at line 65: /* * Just a clean way to get to the first byte * of the packet */ struct tcpiphdr_2 { struct tcpiphdr dummy; char first_char; }; So I've tried to access using the explicit name for gdb, that is, ti->ti_i.ih_len but it appears ti is pointing to a memory area which is not inside its own memory space, causing a segment fault. That's also why I can't access any of the values in the ti structure. Here's gdb's backtrace: ====== START GDB OUTPUT ====== (gdb) bt #0 tcp_input (m=0xaba528, iphlen=20, inso=0xe07ef8) at src/colinux/user/slirp/tcp_input.c:1460 #1 0x00402b90 in tcp_input (m=0x9ca850, iphlen=2358284, inso=0x23fb08) at src/colinux/user/slirp/tcp_input.c:1403 #2 0x00402b90 in tcp_input (m=0x40cc50, iphlen=206528, inso=0x23ff68) at src/colinux/user/slirp/tcp_input.c:1403 #3 0x00402b90 in tcp_input (m=0xffffffff, iphlen=2147315712, inso=0x23ffb0) at src/colinux/user/slirp/tcp_input.c:1403 #4 0x00402b90 in tcp_input (m=0x23ff68, iphlen=9, inso=0x23fff0) at src/colinux/user/slirp/tcp_input.c:1403 #5 0x00402b90 in tcp_input (m=0xffffffff, iphlen=0, inso=0x7ffd7000) at src/colinux/user/slirp/tcp_input.c:1403 #6 0x00402b90 in tcp_input (m=0x32ac0, iphlen=0, inso=0x78746341) at src/colinux/user/slirp/tcp_input.c:1403 #7 0x00402b90 in tcp_input (m=Cannot access memory at address 0xffffff98 ) at src/colinux/user/slirp/tcp_input.c:1403 Previous frame inner to this frame (corrupt stack?) (gdb) up #1 0x00402b90 in tcp_input (m=0x9ca850, iphlen=2358284, inso=0x23fb08) at src/colinux/user/slirp/tcp_input.c:1403 1403 switch (tp->t_state) { ====== END GDB OUTPUT ====== Thanks, - Shai On Fri, Feb 6, 2009 at 2:07 AM, Henry Nestler <hen...@ar...> wrote: > Hello Shai, > >> Shai Vaingast wrote: >>> >>> I've caused this to happen several times and it seems that the crash >>> happens at the same point (i.e., same IP, same call stack, same >>> disassembly location, etc.) >>> >>> Call stack: >>> COLINUX-SLIRP-NET-DAEMON! 00402b90() >>> COLINUX-SLIRP-NET-DAEMON! 004089db() >>> COLINUX-SLIRP-NET-DAEMON! 00401d77() >>> COLINUX-SLIRP-NET-DAEMON! 0040130d() >>> COLINUX-SLIRP-NET-DAEMON! 00401247() >>> COLINUX-SLIRP-NET-DAEMON! 00401298() >>> KERNEL32! 7c817067() > > The stack with labels: > COLINUX-SLIRP-NET-DAEMON! 00402b90() _tcp_input+0x5f0 > COLINUX-SLIRP-NET-DAEMON! 004089db() _slirp_select_poll+0x11b > COLINUX-SLIRP-NET-DAEMON! 00401d77() _co_slirp_main+0x237 > COLINUX-SLIRP-NET-DAEMON! 0040130d() _main+0x2d > COLINUX-SLIRP-NET-DAEMON! 00401247() ___mingw_CRTStartup+0xf7 > COLINUX-SLIRP-NET-DAEMON! 00401298() _mainCRTStartup+0x18 > >>> Registers: >>> EAX = 00000001 EBX = 00000002 >>> ECX = 77C2C2E3 EDX = 00030608 >>> ESI = 0051B03C EDI = 005143E0 >>> EIP = 00402B90 ESP = 0023FA20 >>> EBP = 0023FA98 EFL = 00000246 >>> [...] >>> CS = 001B DS = 0023 ES = 0023 SS = 0023 >>> FS = 003B GS = 0000 OV=0 UP=0 EI=1 PL=0 >>> ZR=1 AC=0 PE=1 CY=0 >>> >>> 0051B046 = ???? >>> >>> [...] >>> CTRL = 037F STAT = 0000 TAGS = FFFF >>> EIP = 00000000 >>> CS = 0000 DS = 0000 EDO = 00000000 >>> >>> Disassembly (current location is 00402B90, I've added a few lines >>> before as well). >>> 00402B66 je 00402B90 >>> 00402B68 mov ecx,dword ptr [ebp-30h] >>> 00402B6B cmp word ptr [ecx+8],9 >>> 00402B70 jle 00402D67 >>> 00402B76 mov edi,dword ptr [ebp-30h] >>> 00402B79 mov eax,dword ptr [edi+8] >>> 00402B7C sub eax,3 >>> 00402B7F cmp ax,7 >>> 00402B83 jbe 00402D5D >>> 00402B89 lea esi,[esi] >>> ---> 00402B90 movzx eax,word ptr [esi+0Ah] >>> 00402B94 dec eax >>> 00402B95 cmp ax,4 >>> 00402B99 ja 00402BA5 > > OK. I have the same from "objdump": > > src/colinux/user/slirp/tcp_input.c:1403 > 402b76: 8b 7d d0 mov 0xffffffd0(%ebp),%edi > 402b79: 8b 47 08 mov 0x8(%edi),%eax > 402b7c: 83 e8 03 sub $0x3,%eax > 402b7f: 66 83 f8 07 cmp $0x7,%ax > 402b83: 0f 86 d4 01 00 00 jbe 402d5d <_tcp_input+0x7bd> > 402b89: 8d b4 26 00 00 00 00 lea 0x0(%esi),%esi > src/colinux/user/slirp/tcp_input.c:1460 > ===> 402b90: 0f b7 46 0a movzwl 0xa(%esi),%eax <=== > 402b94: 48 dec %eax > 402b95: 66 83 f8 04 cmp $0x4,%ax > 402b99: 77 0a ja 402ba5 <_tcp_input+0x605> > 402b9b: 80 7e 28 1b cmpb $0x1b,0x28(%esi) > 402b9f: 0f 84 e6 01 00 00 je 402d8b <_tcp_input+0x7eb> > src/colinux/user/slirp/tcp_input.c:1468 > 402ba5: 8b 45 b4 mov 0xffffffb4(%ebp),%eax > 402ba8: 85 c0 test %eax,%eax > 402baa: 75 0d jne 402bb9 <_tcp_input+0x619> > 402bac: 8b 4d d0 mov 0xffffffd0(%ebp),%ecx > 402baf: f6 41 1c 01 testb $0x1,0x1c(%ecx) > 402bb3: 0f 84 29 fe ff ff je 4029e2 <_tcp_input+0x442> > src/colinux/user/slirp/tcp_input.c:1469 > > Here is this source line number 1460 on SF: > http://colinux.svn.sourceforge.net/viewvc/colinux/branches/devel/src/colinux/user/slirp/tcp_input.c?view=markup#l_1460 > > I don't see the problem. > This is not the "first_char == (char)27", this I can see later as assembler > "$0x1b". > > I have created a executable [1] with full debug (-ggdb). It would be nice, > if you starts this under gdb.exe. Please use gdb-6.3-2.exe from the "Release > Candidate: gdb-6.3" [2]. > > Install GDB and copy the SLiRP with debug version in your coLinux > installation. The name is different to avoids problems. This special build > you can use with coLinux version 0.7.3 or with one of the 0.8.0. Please use > the coLinux version, you have currently installed, don't change or replace > any coLinux exe files. > > Here is a small step guide for GDB session: > * First run coLinux in normal way. > * Note the current parameters of colinux-slirp-net-daemon.exe, with > "ProcesExplorer" [3] you can do it > * Kill the current colinux-slirp-net-daemon.exe, ignore the warning message > * Open a new windows command prompt, change into coLinux directory and run > GDB.EXE with colinux-slirp-net-daemon-dbg.exe, for example: > C:\colinux> C:\mingw\bin\gdb colinux-slirp-net-daemon-dbg.exe > * Set the parameters you noted on step 2, for example: > (gdb) set args -i 2496 -u 0 > * Run the SLiRP: > (gdb) run > * Now, use your network (SLiRP) in your error case to force the crash. > * After the crash you should see any variable, that was out of range. (I > hope) > * Please print the "backtrace" from such session. > > If GDB needs any source, I think "src/colinux/user/slirp/tcp_input.c" would > need. Then create such source tree under your current install directory > ("C:\colinux" in my example) and store the file tcp_input.c there. Or unpack > the complete source. Than GDB should give some more details about the > variables. So, my hope. > Use the gdb command "print" and try to give us an output from the variables > "ti", "ti->ti_len" and "((struct tcpiphdr_2 *)ti)->first_char". > > [1] > http://www.henrynestler.com/colinux/testing/devel-0.8.0/20090205-Snapshot/packages/colinux-slirp-net-daemon-dbg.zip > [2] > http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=20507&release_id=38019 > [3] technet.microsoft.com/en-us/sysinternals/bb896653.aspx > > -- > Henry N. > |
From: Henry N. <hen...@ar...> - 2009-02-06 00:07:59
|
Hello Shai, > Shai Vaingast wrote: >> I've caused this to happen several times and it seems that the crash >> happens at the same point (i.e., same IP, same call stack, same >> disassembly location, etc.) >> >> Call stack: >> COLINUX-SLIRP-NET-DAEMON! 00402b90() >> COLINUX-SLIRP-NET-DAEMON! 004089db() >> COLINUX-SLIRP-NET-DAEMON! 00401d77() >> COLINUX-SLIRP-NET-DAEMON! 0040130d() >> COLINUX-SLIRP-NET-DAEMON! 00401247() >> COLINUX-SLIRP-NET-DAEMON! 00401298() >> KERNEL32! 7c817067() The stack with labels: COLINUX-SLIRP-NET-DAEMON! 00402b90() _tcp_input+0x5f0 COLINUX-SLIRP-NET-DAEMON! 004089db() _slirp_select_poll+0x11b COLINUX-SLIRP-NET-DAEMON! 00401d77() _co_slirp_main+0x237 COLINUX-SLIRP-NET-DAEMON! 0040130d() _main+0x2d COLINUX-SLIRP-NET-DAEMON! 00401247() ___mingw_CRTStartup+0xf7 COLINUX-SLIRP-NET-DAEMON! 00401298() _mainCRTStartup+0x18 >> Registers: >> EAX = 00000001 EBX = 00000002 >> ECX = 77C2C2E3 EDX = 00030608 >> ESI = 0051B03C EDI = 005143E0 >> EIP = 00402B90 ESP = 0023FA20 >> EBP = 0023FA98 EFL = 00000246 >> [...] >> CS = 001B DS = 0023 ES = 0023 SS = 0023 >> FS = 003B GS = 0000 OV=0 UP=0 EI=1 PL=0 >> ZR=1 AC=0 PE=1 CY=0 >> >> 0051B046 = ???? >> >> [...] >> CTRL = 037F STAT = 0000 TAGS = FFFF >> EIP = 00000000 >> CS = 0000 DS = 0000 EDO = 00000000 >> >> Disassembly (current location is 00402B90, I've added a few lines >> before as well). >> 00402B66 je 00402B90 >> 00402B68 mov ecx,dword ptr [ebp-30h] >> 00402B6B cmp word ptr [ecx+8],9 >> 00402B70 jle 00402D67 >> 00402B76 mov edi,dword ptr [ebp-30h] >> 00402B79 mov eax,dword ptr [edi+8] >> 00402B7C sub eax,3 >> 00402B7F cmp ax,7 >> 00402B83 jbe 00402D5D >> 00402B89 lea esi,[esi] >> ---> 00402B90 movzx eax,word ptr [esi+0Ah] >> 00402B94 dec eax >> 00402B95 cmp ax,4 >> 00402B99 ja 00402BA5 OK. I have the same from "objdump": src/colinux/user/slirp/tcp_input.c:1403 402b76: 8b 7d d0 mov 0xffffffd0(%ebp),%edi 402b79: 8b 47 08 mov 0x8(%edi),%eax 402b7c: 83 e8 03 sub $0x3,%eax 402b7f: 66 83 f8 07 cmp $0x7,%ax 402b83: 0f 86 d4 01 00 00 jbe 402d5d <_tcp_input+0x7bd> 402b89: 8d b4 26 00 00 00 00 lea 0x0(%esi),%esi src/colinux/user/slirp/tcp_input.c:1460 ===> 402b90: 0f b7 46 0a movzwl 0xa(%esi),%eax <=== 402b94: 48 dec %eax 402b95: 66 83 f8 04 cmp $0x4,%ax 402b99: 77 0a ja 402ba5 <_tcp_input+0x605> 402b9b: 80 7e 28 1b cmpb $0x1b,0x28(%esi) 402b9f: 0f 84 e6 01 00 00 je 402d8b <_tcp_input+0x7eb> src/colinux/user/slirp/tcp_input.c:1468 402ba5: 8b 45 b4 mov 0xffffffb4(%ebp),%eax 402ba8: 85 c0 test %eax,%eax 402baa: 75 0d jne 402bb9 <_tcp_input+0x619> 402bac: 8b 4d d0 mov 0xffffffd0(%ebp),%ecx 402baf: f6 41 1c 01 testb $0x1,0x1c(%ecx) 402bb3: 0f 84 29 fe ff ff je 4029e2 <_tcp_input+0x442> src/colinux/user/slirp/tcp_input.c:1469 Here is this source line number 1460 on SF: http://colinux.svn.sourceforge.net/viewvc/colinux/branches/devel/src/colinux/user/slirp/tcp_input.c?view=markup#l_1460 I don't see the problem. This is not the "first_char == (char)27", this I can see later as assembler "$0x1b". I have created a executable [1] with full debug (-ggdb). It would be nice, if you starts this under gdb.exe. Please use gdb-6.3-2.exe from the "Release Candidate: gdb-6.3" [2]. Install GDB and copy the SLiRP with debug version in your coLinux installation. The name is different to avoids problems. This special build you can use with coLinux version 0.7.3 or with one of the 0.8.0. Please use the coLinux version, you have currently installed, don't change or replace any coLinux exe files. Here is a small step guide for GDB session: * First run coLinux in normal way. * Note the current parameters of colinux-slirp-net-daemon.exe, with "ProcesExplorer" [3] you can do it * Kill the current colinux-slirp-net-daemon.exe, ignore the warning message * Open a new windows command prompt, change into coLinux directory and run GDB.EXE with colinux-slirp-net-daemon-dbg.exe, for example: C:\colinux> C:\mingw\bin\gdb colinux-slirp-net-daemon-dbg.exe * Set the parameters you noted on step 2, for example: (gdb) set args -i 2496 -u 0 * Run the SLiRP: (gdb) run * Now, use your network (SLiRP) in your error case to force the crash. * After the crash you should see any variable, that was out of range. (I hope) * Please print the "backtrace" from such session. If GDB needs any source, I think "src/colinux/user/slirp/tcp_input.c" would need. Then create such source tree under your current install directory ("C:\colinux" in my example) and store the file tcp_input.c there. Or unpack the complete source. Than GDB should give some more details about the variables. So, my hope. Use the gdb command "print" and try to give us an output from the variables "ti", "ti->ti_len" and "((struct tcpiphdr_2 *)ti)->first_char". [1] http://www.henrynestler.com/colinux/testing/devel-0.8.0/20090205-Snapshot/packages/colinux-slirp-net-daemon-dbg.zip [2] http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=20507&release_id=38019 [3] technet.microsoft.com/en-us/sysinternals/bb896653.aspx -- Henry N. |
From: Shai V. <sva...@gm...> - 2009-02-05 05:09:55
|
Hi Jacky, Can you ping/telnet/SSH from the other PC to coLinux? Can you ping/telnet/SSH from coLinux to the other PC? The real question is basically, is this a network problem or an NFS configuration issue. - Shai On Thu, Feb 5, 2009 at 3:38 AM, Jacky Lam <jac...@gm...> wrote: > Dear all, > > I setup a NFS server in coLinux. I can mount successfully inside > coLinux. But I have another PC machine inside the same subnet cannot > mount the NFS successfully. Any suggestion? > > My /etc/exports: > /home/nfs_root *(rw,sync) > > The subnet inside coLinux is 192.168.11.0/255.255.255.0 > The subnet hosting coLinux and the other PC is 172.28.6.0/255.255.255.0 > > I know it maybe more related to networking stuff. But I can't find > related solution in Google. Hope coLinux user can help. > > Thanks. > > Br, > Jacky > > ------------------------------------------------------------------------------ > Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) > software. With Adobe AIR, Ajax developers can use existing skills and code to > build responsive, highly engaging applications that combine the power of local > resources and data with the reach of the web. Download the Adobe AIR SDK and > Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com > _______________________________________________ > coLinux-users mailing list > coL...@li... > https://lists.sourceforge.net/lists/listinfo/colinux-users > |
From: Jacky L. <jac...@gm...> - 2009-02-05 02:02:39
|
Dear all, I setup a NFS server in coLinux. I can mount successfully inside coLinux. But I have another PC machine inside the same subnet cannot mount the NFS successfully. Any suggestion? My /etc/exports: /home/nfs_root *(rw,sync) The subnet inside coLinux is 192.168.11.0/255.255.255.0 The subnet hosting coLinux and the other PC is 172.28.6.0/255.255.255.0 I know it maybe more related to networking stuff. But I can't find related solution in Google. Hope coLinux user can help. Thanks. Br, Jacky |
From: Henry N. <hen...@ar...> - 2009-02-02 19:34:29
|
Hello Shai, Shai Vaingast wrote: > I've caused this to happen several times and it seems that the crash > happens at the same point (i.e., same IP, same call stack, same > disassembly location, etc.) > > Call stack: > COLINUX-SLIRP-NET-DAEMON! 00402b90() > COLINUX-SLIRP-NET-DAEMON! 004089db() > COLINUX-SLIRP-NET-DAEMON! 00401d77() > COLINUX-SLIRP-NET-DAEMON! 0040130d() > COLINUX-SLIRP-NET-DAEMON! 00401247() > COLINUX-SLIRP-NET-DAEMON! 00401298() > KERNEL32! 7c817067() > > Registers: > EAX = 00000001 EBX = 00000002 > ECX = 77C2C2E3 EDX = 00030608 > ESI = 0051B03C EDI = 005143E0 > EIP = 00402B90 ESP = 0023FA20 > EBP = 0023FA98 EFL = 00000246 > [...] > CS = 001B DS = 0023 ES = 0023 SS = 0023 > FS = 003B GS = 0000 OV=0 UP=0 EI=1 PL=0 > ZR=1 AC=0 PE=1 CY=0 > > 0051B046 = ???? > > [...] > CTRL = 037F STAT = 0000 TAGS = FFFF > EIP = 00000000 > CS = 0000 DS = 0000 EDO = 00000000 > > Disassembly (current location is 00402B90, I've added a few lines > before as well). > 00402B66 je 00402B90 > 00402B68 mov ecx,dword ptr [ebp-30h] > 00402B6B cmp word ptr [ecx+8],9 > 00402B70 jle 00402D67 > 00402B76 mov edi,dword ptr [ebp-30h] > 00402B79 mov eax,dword ptr [edi+8] > 00402B7C sub eax,3 > 00402B7F cmp ax,7 > 00402B83 jbe 00402D5D > 00402B89 lea esi,[esi] > ---> 00402B90 movzx eax,word ptr [esi+0Ah] > 00402B94 dec eax > 00402B95 cmp ax,4 > 00402B99 ja 00402BA5 > [...] > > The exception is an access violation. Many thanks for the stack backtrace. I will check it. -- Henry N. |
From: Henry N. <hen...@ar...> - 2009-02-02 19:24:28
|
Dave Coventry wrote: > I haven't run my Colinux system for a while but find I'm getting errors: > > ============== snip ======================== > colinux-daemon @gentoo.conf > Cooperative Linux Daemon, 0.7.3 > Daemon compiled on Sat May 24 22:36:07 2008 > > vmlinux: The system cannot find the file specified. > error loading vmlinux file > daemon: exit code 81c09401 > daemon: error - CO_RC_ERROR_ERROR, line 37, file src/colinux/os/winnt/user/file. > c (14) > ============== snip ======================== > > Can anyone see what's going wrong? > It seems as though it cannot find the file 'vmlinux' from within the image file. Yes, that is what the error message means. The file "vmlinux" does not exist or can't open by colinux-daemon.exe The file "vmlinux" typically should exist in same directory as you colinux-daemon.exe. If you have this in an other directoy, you needs to add the path in the config file. Please change into the directory where the current file "vmlinux" exist and than run there "colinux-daemon.exe @gentoo.conf" Check, that the file is not blocked by Virus scanner. Try to access the file with some commands on Windows command prompt, like DIR vmlinux COPY vmlinux dummy.tmp Check, that the config file "gentoo.conf" is only plain text, and not UTF-8 coded, and not saved as Windows Wide Char (two bytes per char). As workarround try the command line overwriter: colinux-daemon.exe kernel=vmlinux @gentoo.conf -- Henry N. |
From: Dave C. <dgc...@gm...> - 2009-02-02 12:19:44
|
I haven't run my Colinux system for a while but find I'm getting errors: ============== snip ======================== colinux-daemon @gentoo.conf Cooperative Linux Daemon, 0.7.3 Daemon compiled on Sat May 24 22:36:07 2008 vmlinux: The system cannot find the file specified. error loading vmlinux file daemon: exit code 81c09401 daemon: error - CO_RC_ERROR_ERROR, line 37, file src/colinux/os/winnt/user/file. c (14) ============== snip ======================== Can anyone see what's going wrong? It seems as though it cannot find the file 'vmlinux' from within the image file. However, I have not changed anything in the image file. In fact I have two or three image files and I cannot start them up either. Many thanks, Dave |
From: Shai V. <sva...@gm...> - 2009-02-02 07:22:49
|
Hi Henry, I've caused this to happen several times and it seems that the crash happens at the same point (i.e., same IP, same call stack, same disassembly location, etc.) Call stack: COLINUX-SLIRP-NET-DAEMON! 00402b90() COLINUX-SLIRP-NET-DAEMON! 004089db() COLINUX-SLIRP-NET-DAEMON! 00401d77() COLINUX-SLIRP-NET-DAEMON! 0040130d() COLINUX-SLIRP-NET-DAEMON! 00401247() COLINUX-SLIRP-NET-DAEMON! 00401298() KERNEL32! 7c817067() Registers: EAX = 00000001 EBX = 00000002 ECX = 77C2C2E3 EDX = 00030608 ESI = 0051B03C EDI = 005143E0 EIP = 00402B90 ESP = 0023FA20 EBP = 0023FA98 EFL = 00000246 MM0 = 0000000000000000 MM1 = 0000000000000000 MM2 = 0000000000000000 MM3 = 0000000000000000 MM4 = 0000000000000000 MM5 = 0000003800000000 MM6 = 0000000000000000 MM7 = 004012A000000000 XMM0 = 00000000000000000000000000000000 XMM1 = 00000000000000000000000000000000 XMM2 = 00000000000000000000000000000000 XMM3 = 00000000000000000000000000000000 XMM4 = 00000000000000000000000000000000 XMM5 = 00000000000000000000000000000000 XMM6 = 00000000000000000000000000000000 XMM7 = 00000000000000000000000000000000 CS = 001B DS = 0023 ES = 0023 SS = 0023 FS = 003B GS = 0000 OV=0 UP=0 EI=1 PL=0 ZR=1 AC=0 PE=1 CY=0 0051B046 = ???? XMM0DL = +0.00000000000000E+000 XMM0DH = +0.00000000000000E+000 XMM1DL = +0.00000000000000E+000 XMM1DH = +0.00000000000000E+000 XMM2DL = +0.00000000000000E+000 XMM2DH = +0.00000000000000E+000 XMM3DL = +0.00000000000000E+000 XMM3DH = +0.00000000000000E+000 XMM4DL = +0.00000000000000E+000 XMM4DH = +0.00000000000000E+000 XMM5DL = +0.00000000000000E+000 XMM5DH = +0.00000000000000E+000 XMM6DL = +0.00000000000000E+000 XMM6DH = +0.00000000000000E+000 XMM7DL = +0.00000000000000E+000 XMM7DH = +0.00000000000000E+000 XMM00 = +0.00000E+000 XMM01 = +0.00000E+000 XMM02 = +0.00000E+000 XMM03 = +0.00000E+000 XMM10 = +0.00000E+000 XMM11 = +0.00000E+000 XMM12 = +0.00000E+000 XMM13 = +0.00000E+000 XMM20 = +0.00000E+000 XMM21 = +0.00000E+000 XMM22 = +0.00000E+000 XMM23 = +0.00000E+000 XMM30 = +0.00000E+000 XMM31 = +0.00000E+000 XMM32 = +0.00000E+000 XMM33 = +0.00000E+000 XMM40 = +0.00000E+000 XMM41 = +0.00000E+000 XMM42 = +0.00000E+000 XMM43 = +0.00000E+000 XMM50 = +0.00000E+000 XMM51 = +0.00000E+000 XMM52 = +0.00000E+000 XMM53 = +0.00000E+000 XMM60 = +0.00000E+000 XMM61 = +0.00000E+000 XMM62 = +0.00000E+000 XMM63 = +0.00000E+000 XMM70 = +0.00000E+000 XMM71 = +0.00000E+000 XMM72 = +0.00000E+000 XMM73 = +0.00000E+000 MXCSR = 00001F80 ST0 = +0.00000000000000000e+0000 ST1 = +0.00000000000000000e+0000 ST2 = +0.00000000000000000e+0000 ST3 = +0.00000000000000000e+0000 ST4 = +0.00000000000000000e+0000 ST5 = +0.00000000000000000e+0000 ST6 = +0.00000000000000000e+0000 ST7 = +0.00000000000000000e+0000 CTRL = 037F STAT = 0000 TAGS = FFFF EIP = 00000000 CS = 0000 DS = 0000 EDO = 00000000 Disassembly (current location is 00402B90, I've added a few lines before as well). 00402B66 je 00402B90 00402B68 mov ecx,dword ptr [ebp-30h] 00402B6B cmp word ptr [ecx+8],9 00402B70 jle 00402D67 00402B76 mov edi,dword ptr [ebp-30h] 00402B79 mov eax,dword ptr [edi+8] 00402B7C sub eax,3 00402B7F cmp ax,7 00402B83 jbe 00402D5D 00402B89 lea esi,[esi] ---> 00402B90 movzx eax,word ptr [esi+0Ah] 00402B94 dec eax 00402B95 cmp ax,4 00402B99 ja 00402BA5 00402B9B cmp byte ptr [esi+28h],1Bh 00402B9F je 00402D8B 00402BA5 mov eax,dword ptr [ebp-4Ch] 00402BA8 test eax,eax 00402BAA jne 00402BB9 00402BAC mov ecx,dword ptr [ebp-30h] 00402BAF test byte ptr [ecx+1Ch],1 00402BB3 je 004029E2 00402BB9 mov ebx,dword ptr [ebp-30h] 00402BBC mov dword ptr [ebp+8],ebx 00402BBF lea esp,[ebp-0Ch] 00402BC2 pop ebx 00402BC3 pop esi 00402BC4 pop edi 00402BC5 pop ebp 00402BC6 jmp 00406460 00402BCB mov ebx,dword ptr [ebp-30h] 00402BCE movsx edx,word ptr [ebx+8] 00402BD2 cmp dx,9 00402BD6 jg 00402B4E 00402BDC mov eax,dword ptr [esi+18h] 00402BDF cmp eax,dword ptr [ebx+6Ch] 00402BE2 jne 00402BEC 00402BE4 cmp dword ptr [ebx],ebx 00402BE6 je 004031AE 00402BEC mov ebx,dword ptr [ebp-68h] 00402BEF sub esp,4 00402BF2 push ebx 00402BF3 push esi The exception is an access violation. Thanks, - Shai On Sun, Feb 1, 2009 at 8:47 PM, Henry Nestler <hen...@ar...> wrote: > Hello Shai, > > Shai Vaingast wrote: >> >> I've been using coLinux for quite some time now without any issues. >> Lately, I've run into problems that cause coLinux to report a "coLinux >> daemon program has encountered a problem and needs to close. We are >> sorry for ...." When I press Debug, VC opens up with >> "colinux-slirp-net-daemon" diassembly. > > So, you have a debugger, that would be nice you give us the instruction > pointer (IP) on the crash point. Please copy the first 3 lines from the > assembler output and post it here. > Additional a stack-backtrace of this task and the register dump would be > nice. > > -- > Henry N. > |
From: Henry N. <hen...@ar...> - 2009-02-01 18:48:18
|
Hello Shai, Shai Vaingast wrote: > I've been using coLinux for quite some time now without any issues. > Lately, I've run into problems that cause coLinux to report a "coLinux > daemon program has encountered a problem and needs to close. We are > sorry for ...." When I press Debug, VC opens up with > "colinux-slirp-net-daemon" diassembly. So, you have a debugger, that would be nice you give us the instruction pointer (IP) on the crash point. Please copy the first 3 lines from the assembler output and post it here. Additional a stack-backtrace of this task and the register dump would be nice. -- Henry N. |
From: Shai V. <sva...@gm...> - 2009-02-01 06:31:57
|
Hi, I've been using coLinux for quite some time now without any issues. Lately, I've run into problems that cause coLinux to report a "coLinux daemon program has encountered a problem and needs to close. We are sorry for ...." When I press Debug, VC opens up with "colinux-slirp-net-daemon" diassembly. My configuration: Gentoo Linux Cygwin running X The application that constantly seems to cause this is Azureus (vuze). I've switched to both IcedTea and Sun-JDK java implementation and it happens in both. My network configuration: I run a local network: eth0 connect to the internet (slirp) eth1 connect to the host (tuntap) Version: Gento 2.6.22.18-co-0.7.3 coLinux 0.7.3 TAP-Win32 version 8.0.0.4 Any help is appreciated. Thanks, - Shai |
From: Jason A. <ja...@co...> - 2009-01-14 23:00:01
|
In the short term, here's a short work around script. Of course, be careful... I've not tested this, but it should achieve the same effect. #!/bin/bash TREE=$1 if [ ! -d $TREE ]; then echo "$TREE is not a directory." exit fi find $TREE -not -type d | xargs rm -f rmdir -p $TREE On Wed, Jan 14, 2009 at 1:17 PM, Henry Nestler <hen...@ar...> wrote: > Tobbe Lundberg wrote: >> Running 'rm -fr' on a directory on a cofs mount doesn't seem to work >> as it should. For me it hangs (or ends up in some infinite loop) and I >> have to stop it with ^C. After stopping it the directory is still >> there. >> >> Deleting the files in the directory with 'rm *' and then deleting the >> dir with 'rmdir' works, but is a bit tedious if you want to delete an >> entire tree structure. > > Yes, it's known as bug #2359423 'cofs: "rm -r" fails on directories with > more as 200 files'. You will find in the tracker: > https://sourceforge.net/tracker/index.php?func=detail&aid=2359423&group_id=98788&atid=622063 > > -- > Henry N. > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > coLinux-users mailing list > coL...@li... > https://lists.sourceforge.net/lists/listinfo/colinux-users > |
From: Tobbe L. <tob...@gm...> - 2009-01-14 22:46:34
|
Yes, that is the bug I'm hitting //Tobbe On Wed, Jan 14, 2009 at 10:17 PM, Henry Nestler <hen...@ar...> wrote: > Tobbe Lundberg wrote: >> >> Running 'rm -fr' on a directory on a cofs mount doesn't seem to work >> as it should. For me it hangs (or ends up in some infinite loop) and I >> have to stop it with ^C. After stopping it the directory is still >> there. >> >> Deleting the files in the directory with 'rm *' and then deleting the >> dir with 'rmdir' works, but is a bit tedious if you want to delete an >> entire tree structure. > > Yes, it's known as bug #2359423 'cofs: "rm -r" fails on directories with > more as 200 files'. You will find in the tracker: > https://sourceforge.net/tracker/index.php?func=detail&aid=2359423&group_id=98788&atid=622063 > > -- > Henry N. > |
From: Jason A. <ja...@co...> - 2009-01-14 22:45:53
|
I screwed it up. Go figure! #!/bin/bash TREE=$1 if [ ! -d $TREE ]; then echo "$TREE is not a directory." exit fi find $TREE -not -type d | xargs rm -f find $TREE -depth | xargs rmdir On Wed, Jan 14, 2009 at 1:27 PM, Jason Ahrens <ja...@co...> wrote: > In the short term, here's a short work around script. Of course, be > careful... I've not tested this, but it should achieve the same > effect. > > #!/bin/bash > TREE=$1 > if [ ! -d $TREE ]; then > echo "$TREE is not a directory." > exit > fi > find $TREE -not -type d | xargs rm -f > rmdir -p $TREE > > On Wed, Jan 14, 2009 at 1:17 PM, Henry Nestler <hen...@ar...> wrote: >> Tobbe Lundberg wrote: >>> Running 'rm -fr' on a directory on a cofs mount doesn't seem to work >>> as it should. For me it hangs (or ends up in some infinite loop) and I >>> have to stop it with ^C. After stopping it the directory is still >>> there. >>> >>> Deleting the files in the directory with 'rm *' and then deleting the >>> dir with 'rmdir' works, but is a bit tedious if you want to delete an >>> entire tree structure. >> >> Yes, it's known as bug #2359423 'cofs: "rm -r" fails on directories with >> more as 200 files'. You will find in the tracker: >> https://sourceforge.net/tracker/index.php?func=detail&aid=2359423&group_id=98788&atid=622063 >> >> -- >> Henry N. >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by: >> SourcForge Community >> SourceForge wants to tell your story. >> http://p.sf.net/sfu/sf-spreadtheword >> _______________________________________________ >> coLinux-users mailing list >> coL...@li... >> https://lists.sourceforge.net/lists/listinfo/colinux-users >> > |
From: Henry N. <hen...@ar...> - 2009-01-14 21:10:54
|
Tobbe Lundberg wrote: > Running 'rm -fr' on a directory on a cofs mount doesn't seem to work > as it should. For me it hangs (or ends up in some infinite loop) and I > have to stop it with ^C. After stopping it the directory is still > there. > > Deleting the files in the directory with 'rm *' and then deleting the > dir with 'rmdir' works, but is a bit tedious if you want to delete an > entire tree structure. Yes, it's known as bug #2359423 'cofs: "rm -r" fails on directories with more as 200 files'. You will find in the tracker: https://sourceforge.net/tracker/index.php?func=detail&aid=2359423&group_id=98788&atid=622063 -- Henry N. |
From: Tobbe L. <tob...@gm...> - 2009-01-14 12:57:36
|
Hi Running 'rm -fr' on a directory on a cofs mount doesn't seem to work as it should. For me it hangs (or ends up in some infinite loop) and I have to stop it with ^C. After stopping it the directory is still there. Deleting the files in the directory with 'rm *' and then deleting the dir with 'rmdir' works, but is a bit tedious if you want to delete an entire tree structure. //Tobbe |
From: John C. <joh...@ho...> - 2009-01-14 03:34:58
|
I came across this issue for Unidentified Network issue with VMWare’s virtual NICs in Vista (http://aspoc.net/archives/2008/10/30/unidentified-network-issue-with-vmwares-virtual-nics-in-vista/) that also seems to apply to the TAP connection that I'm using with CoLinux. I searched my registry for tap0801.sys and tried adding the DWORD Value mentioned in this article where occurances of this file turned up in the registry, but it didn't seem to resolve the issue. Can anyone tell me where in the registry to apply the changes mentioned in this article for the TAP connection? _________________________________________________________________ Windows Live™ Hotmail®: Chat. Store. Share. Do more with mail. http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t1_hm_justgotbetter_howitworks_012009 |