You can subscribe to this list here.
2004 |
Jan
(64) |
Feb
(530) |
Mar
(266) |
Apr
(580) |
May
(360) |
Jun
(161) |
Jul
(185) |
Aug
(164) |
Sep
(123) |
Oct
(160) |
Nov
(59) |
Dec
(84) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
(156) |
Feb
(95) |
Mar
(124) |
Apr
(81) |
May
(79) |
Jun
(179) |
Jul
(35) |
Aug
(64) |
Sep
(56) |
Oct
(57) |
Nov
(18) |
Dec
(41) |
2006 |
Jan
(65) |
Feb
(37) |
Mar
(59) |
Apr
(73) |
May
(65) |
Jun
(27) |
Jul
(54) |
Aug
(76) |
Sep
(103) |
Oct
(23) |
Nov
(45) |
Dec
(29) |
2007 |
Jan
(41) |
Feb
(47) |
Mar
(61) |
Apr
(24) |
May
(14) |
Jun
(6) |
Jul
(23) |
Aug
(30) |
Sep
(16) |
Oct
(9) |
Nov
(53) |
Dec
(36) |
2008 |
Jan
(19) |
Feb
(49) |
Mar
(74) |
Apr
(21) |
May
(24) |
Jun
(5) |
Jul
(9) |
Aug
(53) |
Sep
(26) |
Oct
(23) |
Nov
(32) |
Dec
(19) |
2009 |
Jan
(47) |
Feb
(49) |
Mar
(39) |
Apr
(61) |
May
(28) |
Jun
(19) |
Jul
(12) |
Aug
(10) |
Sep
(31) |
Oct
(16) |
Nov
(60) |
Dec
(26) |
2010 |
Jan
(17) |
Feb
(9) |
Mar
(32) |
Apr
(11) |
May
(24) |
Jun
(33) |
Jul
(5) |
Aug
(2) |
Sep
(7) |
Oct
(8) |
Nov
(17) |
Dec
(7) |
2011 |
Jan
(12) |
Feb
(16) |
Mar
(2) |
Apr
(12) |
May
(5) |
Jun
(10) |
Jul
(3) |
Aug
(3) |
Sep
(2) |
Oct
(1) |
Nov
(17) |
Dec
(1) |
2012 |
Jan
(9) |
Feb
(9) |
Mar
(8) |
Apr
(4) |
May
(2) |
Jun
(1) |
Jul
(4) |
Aug
(8) |
Sep
(11) |
Oct
(1) |
Nov
(2) |
Dec
(2) |
2013 |
Jan
|
Feb
(7) |
Mar
(4) |
Apr
(10) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(5) |
Dec
(3) |
2016 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
From: SourceForge.net <no...@so...> - 2010-04-15 20:26:56
|
Bugs item #2985260, was opened at 2010-04-11 05:58 Message generated for change (Comment added) made by henryn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2985260&group_id=98788 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Daemons (Windows) Group: v0.8.x (devel) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Shai (vshai) Assigned to: Nobody/Anonymous (nobody) Summary: Slirp daemon crashing Initial Comment: This seems similar to the bug reported here: http://sourceforge.net/tracker/index.php?func=detail&aid=2055697&group_id=98788&atid=622063 that was fixed and closed. The difference is the rate. It's very hard to reproduce nowadays but it still happens once in a while. Bbefore, the bug could be reproduced after 5-10 minutes of heavy network, now it happens after 20+ hours or so. So this is probably a different bug. Happens with coLinux 0.8.0 but I suspect with other versions as well. Although slirp crashes, coLinux still works properly albeit no networking. ---------------------------------------------------------------------- >Comment By: Henry N. (henryn) Date: 2010-04-15 22:26 Message: I have changed wiki. If not understand now, than feel free to change it. ---------------------------------------------------------------------- Comment By: Shai (vshai) Date: 2010-04-15 15:07 Message: Henry, I have found the problem. I was using the PID of the slirp-daemon I killed instead of using the PID of the colinux-daemon.exe process. This is a bit misleading, maybe a note should be added to the Wiki? Now is time to find the bug... - Shai ---------------------------------------------------------------------- Comment By: Henry N. (henryn) Date: 2010-04-15 00:17 Message: colinux-slirp-net-daemon-dbg.exe was an other example, where colinux-slirp-net-daemon-dbg.exe and colinux-slirp-net-daemon.exe exist in same directory. Sorry. Your way was ok. To see the faulting line, you can run "colinux-debug-daemon.exe -e 8a86f401". But this will only say you, that daemon can't open the driver. Try to run the daemon without debugger, like cd C:\Program Files\coLinux-devel\debug colinux-slirp-net-daemon.exe -i 3044 -u 0 You runs coLinux as service? If so, then please try to start colinux-daemon from command line. What Windows is it? Windows7 or Vista?, then open CMD.EXE as Admin (for the gdb session). The error "monitor open failed" comes also, if the current PID (your 3044) is wrong. The number is the PID from currently running colinux-daemon.exe. You can see this number in ProcessExplorer, Taskmanager and in first lines on colinux-daemon boots. Maybe the debug build I have pointed you, is not exactly the same as you running currently? You can check the build date by running "colinux-daemon --status-driver" from directory debug and your other directory. The other small thing I saw as text "no debugging symbols found". It is not important for running SLiRP daemon. This is interesting later, to see source line numbers. A option "-Wl,--strip-debug" has removed some informations for GDB. Now, I know why it was named ...-gdb.exe. colinux-slirp-net-daemon-gdb.exe is not the same binary as colinux-slirp-net-daemon.exe, because build flag -ggdb was added. "debug/colinux-slirp-net-daemon.exe" is the normal exe file with debugging symbols. The non debug colinux-slirp-net-daemon.exe was created from "debug/colinux-slirp-net-daemon.exe" by stripping out all symbol names stuff. "colinux-slirp-net-daemon-gdb.exe" is an extra build with '-ggdb' for line-nubers and some more informations. I have uploaded the slirp with full debug: http://www.henrynestler.com/colinux/testing/devel-0.8.0/20100305-Snapshot/packages/colinux-slirp-net-daemon-gdb-20100415.zip ---------------------------------------------------------------------- Comment By: Shai (vshai) Date: 2010-04-14 19:51 Message: Hi Henry, I seem to be having difficulties running the slirp daemon in debug mode. Here's an output of gdb: C:\Program Files\coLinux-devel\debug>gdb -se colinux-slirp-net-daemon.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"...(no debugging symbols found) (gdb) run -i 3044 -u 0 Starting program: C:\Program Files\coLinux-devel\debug/colinux-slirp-net-daemon. exe -i 3044 -u 0 conet-slirp-daemon: monitor open failed conet-slirp-daemon: exitcode 8a86f401 Program exited with code 037777777777. (gdb) C:\Program Files\coLinux-devel\debug>dir Any suggestions? Also, the example in Wiki uses the file colinux-slirp-net-daemon-dbg.exe whereas the debug releases do have debug version of slirp, however, the filename doesn't contain the -dbg extension: colinux-slirp-net-deamon.exe. Could this be related? Thanks, - Shai ---------------------------------------------------------------------- Comment By: Henry N. (henryn) Date: 2010-04-13 09:19 Message: Packages for latest devel version finds here: http://www.henrynestler.com/colinux/testing/devel-0.8.0/ ...-Snapshot/packages/ ---------------------------------------------------------------------- Comment By: Shai (vshai) Date: 2010-04-13 05:39 Message: Hi Henry, Where can I get the debug version of coLinux 0.8.0? The Wikia talks about debug version for the current release only (0.7.6). Thanks, - Shai ---------------------------------------------------------------------- Comment By: Henry N. (henryn) Date: 2010-04-11 22:54 Message: Hello Shai, please try to debug it. Here is the help: http://colinux.wikia.com/wiki/Debugging_Daemons ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2985260&group_id=98788 |
From: SourceForge.net <no...@so...> - 2010-04-15 13:07:19
|
Bugs item #2985260, was opened at 2010-04-11 06:58 Message generated for change (Comment added) made by vshai You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2985260&group_id=98788 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Daemons (Windows) Group: v0.8.x (devel) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Shai (vshai) Assigned to: Nobody/Anonymous (nobody) Summary: Slirp daemon crashing Initial Comment: This seems similar to the bug reported here: http://sourceforge.net/tracker/index.php?func=detail&aid=2055697&group_id=98788&atid=622063 that was fixed and closed. The difference is the rate. It's very hard to reproduce nowadays but it still happens once in a while. Bbefore, the bug could be reproduced after 5-10 minutes of heavy network, now it happens after 20+ hours or so. So this is probably a different bug. Happens with coLinux 0.8.0 but I suspect with other versions as well. Although slirp crashes, coLinux still works properly albeit no networking. ---------------------------------------------------------------------- Comment By: Shai (vshai) Date: 2010-04-15 16:07 Message: Henry, I have found the problem. I was using the PID of the slirp-daemon I killed instead of using the PID of the colinux-daemon.exe process. This is a bit misleading, maybe a note should be added to the Wiki? Now is time to find the bug... - Shai ---------------------------------------------------------------------- Comment By: Henry N. (henryn) Date: 2010-04-15 01:17 Message: colinux-slirp-net-daemon-dbg.exe was an other example, where colinux-slirp-net-daemon-dbg.exe and colinux-slirp-net-daemon.exe exist in same directory. Sorry. Your way was ok. To see the faulting line, you can run "colinux-debug-daemon.exe -e 8a86f401". But this will only say you, that daemon can't open the driver. Try to run the daemon without debugger, like cd C:\Program Files\coLinux-devel\debug colinux-slirp-net-daemon.exe -i 3044 -u 0 You runs coLinux as service? If so, then please try to start colinux-daemon from command line. What Windows is it? Windows7 or Vista?, then open CMD.EXE as Admin (for the gdb session). The error "monitor open failed" comes also, if the current PID (your 3044) is wrong. The number is the PID from currently running colinux-daemon.exe. You can see this number in ProcessExplorer, Taskmanager and in first lines on colinux-daemon boots. Maybe the debug build I have pointed you, is not exactly the same as you running currently? You can check the build date by running "colinux-daemon --status-driver" from directory debug and your other directory. The other small thing I saw as text "no debugging symbols found". It is not important for running SLiRP daemon. This is interesting later, to see source line numbers. A option "-Wl,--strip-debug" has removed some informations for GDB. Now, I know why it was named ...-gdb.exe. colinux-slirp-net-daemon-gdb.exe is not the same binary as colinux-slirp-net-daemon.exe, because build flag -ggdb was added. "debug/colinux-slirp-net-daemon.exe" is the normal exe file with debugging symbols. The non debug colinux-slirp-net-daemon.exe was created from "debug/colinux-slirp-net-daemon.exe" by stripping out all symbol names stuff. "colinux-slirp-net-daemon-gdb.exe" is an extra build with '-ggdb' for line-nubers and some more informations. I have uploaded the slirp with full debug: http://www.henrynestler.com/colinux/testing/devel-0.8.0/20100305-Snapshot/packages/colinux-slirp-net-daemon-gdb-20100415.zip ---------------------------------------------------------------------- Comment By: Shai (vshai) Date: 2010-04-14 20:51 Message: Hi Henry, I seem to be having difficulties running the slirp daemon in debug mode. Here's an output of gdb: C:\Program Files\coLinux-devel\debug>gdb -se colinux-slirp-net-daemon.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"...(no debugging symbols found) (gdb) run -i 3044 -u 0 Starting program: C:\Program Files\coLinux-devel\debug/colinux-slirp-net-daemon. exe -i 3044 -u 0 conet-slirp-daemon: monitor open failed conet-slirp-daemon: exitcode 8a86f401 Program exited with code 037777777777. (gdb) C:\Program Files\coLinux-devel\debug>dir Any suggestions? Also, the example in Wiki uses the file colinux-slirp-net-daemon-dbg.exe whereas the debug releases do have debug version of slirp, however, the filename doesn't contain the -dbg extension: colinux-slirp-net-deamon.exe. Could this be related? Thanks, - Shai ---------------------------------------------------------------------- Comment By: Henry N. (henryn) Date: 2010-04-13 10:19 Message: Packages for latest devel version finds here: http://www.henrynestler.com/colinux/testing/devel-0.8.0/ ...-Snapshot/packages/ ---------------------------------------------------------------------- Comment By: Shai (vshai) Date: 2010-04-13 06:39 Message: Hi Henry, Where can I get the debug version of coLinux 0.8.0? The Wikia talks about debug version for the current release only (0.7.6). Thanks, - Shai ---------------------------------------------------------------------- Comment By: Henry N. (henryn) Date: 2010-04-11 23:54 Message: Hello Shai, please try to debug it. Here is the help: http://colinux.wikia.com/wiki/Debugging_Daemons ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2985260&group_id=98788 |
From: SourceForge.net <no...@so...> - 2010-04-14 22:17:05
|
Bugs item #2985260, was opened at 2010-04-11 05:58 Message generated for change (Comment added) made by henryn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2985260&group_id=98788 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Daemons (Windows) Group: v0.8.x (devel) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Shai (vshai) Assigned to: Nobody/Anonymous (nobody) Summary: Slirp daemon crashing Initial Comment: This seems similar to the bug reported here: http://sourceforge.net/tracker/index.php?func=detail&aid=2055697&group_id=98788&atid=622063 that was fixed and closed. The difference is the rate. It's very hard to reproduce nowadays but it still happens once in a while. Bbefore, the bug could be reproduced after 5-10 minutes of heavy network, now it happens after 20+ hours or so. So this is probably a different bug. Happens with coLinux 0.8.0 but I suspect with other versions as well. Although slirp crashes, coLinux still works properly albeit no networking. ---------------------------------------------------------------------- >Comment By: Henry N. (henryn) Date: 2010-04-15 00:17 Message: colinux-slirp-net-daemon-dbg.exe was an other example, where colinux-slirp-net-daemon-dbg.exe and colinux-slirp-net-daemon.exe exist in same directory. Sorry. Your way was ok. To see the faulting line, you can run "colinux-debug-daemon.exe -e 8a86f401". But this will only say you, that daemon can't open the driver. Try to run the daemon without debugger, like cd C:\Program Files\coLinux-devel\debug colinux-slirp-net-daemon.exe -i 3044 -u 0 You runs coLinux as service? If so, then please try to start colinux-daemon from command line. What Windows is it? Windows7 or Vista?, then open CMD.EXE as Admin (for the gdb session). The error "monitor open failed" comes also, if the current PID (your 3044) is wrong. The number is the PID from currently running colinux-daemon.exe. You can see this number in ProcessExplorer, Taskmanager and in first lines on colinux-daemon boots. Maybe the debug build I have pointed you, is not exactly the same as you running currently? You can check the build date by running "colinux-daemon --status-driver" from directory debug and your other directory. The other small thing I saw as text "no debugging symbols found". It is not important for running SLiRP daemon. This is interesting later, to see source line numbers. A option "-Wl,--strip-debug" has removed some informations for GDB. Now, I know why it was named ...-gdb.exe. colinux-slirp-net-daemon-gdb.exe is not the same binary as colinux-slirp-net-daemon.exe, because build flag -ggdb was added. "debug/colinux-slirp-net-daemon.exe" is the normal exe file with debugging symbols. The non debug colinux-slirp-net-daemon.exe was created from "debug/colinux-slirp-net-daemon.exe" by stripping out all symbol names stuff. "colinux-slirp-net-daemon-gdb.exe" is an extra build with '-ggdb' for line-nubers and some more informations. I have uploaded the slirp with full debug: http://www.henrynestler.com/colinux/testing/devel-0.8.0/20100305-Snapshot/packages/colinux-slirp-net-daemon-gdb-20100415.zip ---------------------------------------------------------------------- Comment By: Shai (vshai) Date: 2010-04-14 19:51 Message: Hi Henry, I seem to be having difficulties running the slirp daemon in debug mode. Here's an output of gdb: C:\Program Files\coLinux-devel\debug>gdb -se colinux-slirp-net-daemon.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"...(no debugging symbols found) (gdb) run -i 3044 -u 0 Starting program: C:\Program Files\coLinux-devel\debug/colinux-slirp-net-daemon. exe -i 3044 -u 0 conet-slirp-daemon: monitor open failed conet-slirp-daemon: exitcode 8a86f401 Program exited with code 037777777777. (gdb) C:\Program Files\coLinux-devel\debug>dir Any suggestions? Also, the example in Wiki uses the file colinux-slirp-net-daemon-dbg.exe whereas the debug releases do have debug version of slirp, however, the filename doesn't contain the -dbg extension: colinux-slirp-net-deamon.exe. Could this be related? Thanks, - Shai ---------------------------------------------------------------------- Comment By: Henry N. (henryn) Date: 2010-04-13 09:19 Message: Packages for latest devel version finds here: http://www.henrynestler.com/colinux/testing/devel-0.8.0/ ...-Snapshot/packages/ ---------------------------------------------------------------------- Comment By: Shai (vshai) Date: 2010-04-13 05:39 Message: Hi Henry, Where can I get the debug version of coLinux 0.8.0? The Wikia talks about debug version for the current release only (0.7.6). Thanks, - Shai ---------------------------------------------------------------------- Comment By: Henry N. (henryn) Date: 2010-04-11 22:54 Message: Hello Shai, please try to debug it. Here is the help: http://colinux.wikia.com/wiki/Debugging_Daemons ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2985260&group_id=98788 |
From: SourceForge.net <no...@so...> - 2010-04-14 17:51:48
|
Bugs item #2985260, was opened at 2010-04-11 06:58 Message generated for change (Comment added) made by vshai You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2985260&group_id=98788 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Daemons (Windows) Group: v0.8.x (devel) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Shai (vshai) Assigned to: Nobody/Anonymous (nobody) Summary: Slirp daemon crashing Initial Comment: This seems similar to the bug reported here: http://sourceforge.net/tracker/index.php?func=detail&aid=2055697&group_id=98788&atid=622063 that was fixed and closed. The difference is the rate. It's very hard to reproduce nowadays but it still happens once in a while. Bbefore, the bug could be reproduced after 5-10 minutes of heavy network, now it happens after 20+ hours or so. So this is probably a different bug. Happens with coLinux 0.8.0 but I suspect with other versions as well. Although slirp crashes, coLinux still works properly albeit no networking. ---------------------------------------------------------------------- >Comment By: Shai (vshai) Date: 2010-04-14 20:51 Message: Hi Henry, I seem to be having difficulties running the slirp daemon in debug mode. Here's an output of gdb: C:\Program Files\coLinux-devel\debug>gdb -se colinux-slirp-net-daemon.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"...(no debugging symbols found) (gdb) run -i 3044 -u 0 Starting program: C:\Program Files\coLinux-devel\debug/colinux-slirp-net-daemon. exe -i 3044 -u 0 conet-slirp-daemon: monitor open failed conet-slirp-daemon: exitcode 8a86f401 Program exited with code 037777777777. (gdb) C:\Program Files\coLinux-devel\debug>dir Any suggestions? Also, the example in Wiki uses the file colinux-slirp-net-daemon-dbg.exe whereas the debug releases do have debug version of slirp, however, the filename doesn't contain the -dbg extension: colinux-slirp-net-deamon.exe. Could this be related? Thanks, - Shai ---------------------------------------------------------------------- Comment By: Henry N. (henryn) Date: 2010-04-13 10:19 Message: Packages for latest devel version finds here: http://www.henrynestler.com/colinux/testing/devel-0.8.0/ ...-Snapshot/packages/ ---------------------------------------------------------------------- Comment By: Shai (vshai) Date: 2010-04-13 06:39 Message: Hi Henry, Where can I get the debug version of coLinux 0.8.0? The Wikia talks about debug version for the current release only (0.7.6). Thanks, - Shai ---------------------------------------------------------------------- Comment By: Henry N. (henryn) Date: 2010-04-11 23:54 Message: Hello Shai, please try to debug it. Here is the help: http://colinux.wikia.com/wiki/Debugging_Daemons ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2985260&group_id=98788 |
From: SourceForge.net <no...@so...> - 2010-04-13 07:19:37
|
Bugs item #2985260, was opened at 2010-04-11 05:58 Message generated for change (Comment added) made by henryn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2985260&group_id=98788 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Daemons (Windows) Group: v0.8.x (devel) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Shai (vshai) Assigned to: Nobody/Anonymous (nobody) Summary: Slirp daemon crashing Initial Comment: This seems similar to the bug reported here: http://sourceforge.net/tracker/index.php?func=detail&aid=2055697&group_id=98788&atid=622063 that was fixed and closed. The difference is the rate. It's very hard to reproduce nowadays but it still happens once in a while. Bbefore, the bug could be reproduced after 5-10 minutes of heavy network, now it happens after 20+ hours or so. So this is probably a different bug. Happens with coLinux 0.8.0 but I suspect with other versions as well. Although slirp crashes, coLinux still works properly albeit no networking. ---------------------------------------------------------------------- >Comment By: Henry N. (henryn) Date: 2010-04-13 09:19 Message: Packages for latest devel version finds here: http://www.henrynestler.com/colinux/testing/devel-0.8.0/ ...-Snapshot/packages/ ---------------------------------------------------------------------- Comment By: Shai (vshai) Date: 2010-04-13 05:39 Message: Hi Henry, Where can I get the debug version of coLinux 0.8.0? The Wikia talks about debug version for the current release only (0.7.6). Thanks, - Shai ---------------------------------------------------------------------- Comment By: Henry N. (henryn) Date: 2010-04-11 22:54 Message: Hello Shai, please try to debug it. Here is the help: http://colinux.wikia.com/wiki/Debugging_Daemons ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2985260&group_id=98788 |
From: SourceForge.net <no...@so...> - 2010-04-13 03:39:34
|
Bugs item #2985260, was opened at 2010-04-11 06:58 Message generated for change (Comment added) made by vshai You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2985260&group_id=98788 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Daemons (Windows) Group: v0.8.x (devel) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Shai (vshai) Assigned to: Nobody/Anonymous (nobody) Summary: Slirp daemon crashing Initial Comment: This seems similar to the bug reported here: http://sourceforge.net/tracker/index.php?func=detail&aid=2055697&group_id=98788&atid=622063 that was fixed and closed. The difference is the rate. It's very hard to reproduce nowadays but it still happens once in a while. Bbefore, the bug could be reproduced after 5-10 minutes of heavy network, now it happens after 20+ hours or so. So this is probably a different bug. Happens with coLinux 0.8.0 but I suspect with other versions as well. Although slirp crashes, coLinux still works properly albeit no networking. ---------------------------------------------------------------------- >Comment By: Shai (vshai) Date: 2010-04-13 06:39 Message: Hi Henry, Where can I get the debug version of coLinux 0.8.0? The Wikia talks about debug version for the current release only (0.7.6). Thanks, - Shai ---------------------------------------------------------------------- Comment By: Henry N. (henryn) Date: 2010-04-11 23:54 Message: Hello Shai, please try to debug it. Here is the help: http://colinux.wikia.com/wiki/Debugging_Daemons ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2985260&group_id=98788 |
From: SourceForge.net <no...@so...> - 2010-04-11 21:11:17
|
Bugs item #2965587, was opened at 2010-03-08 19:23 Message generated for change (Comment added) made by henryn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2965587&group_id=98788 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: MASQUERADE works only for first 1-3 TCP packets Initial Comment: having the following config: eth0 - bridged with windows LAN0 eth1 - bridged with windows LAN1 PPPoE connection established from coLinux through eth0. pings/HTTP and etc work perfectly from coLinux. trying to get Internet from Windows (iptables configured POSTROUTING/MASQUERADE thru ppp0): pings from windows work OK; but TCP - does not. According to Wireshark only couple packets in the begging of TCP session are masqueraded. Others go unchanged with local IPs in source field. So TCP connection can be established from windows, but w/o further communication. ---------------------------------------------------------------------- Comment By: Henry N. (henryn) Date: 2010-04-11 23:11 Message: I hope, eth0 and eth1 have a different number for the first "x" in "192.168.x.x"? And the hardware cables on LAN0 and LAN1 are not connected - so packets from ISP can not find any way directly to network on LAN1. Additional you needs to remember, that LAN0 and LAN1 runs in promiscuous mode so Windows gets all packets from both networks. In this case your Wireshark on LAN0 and LAN1 can confuse you. You can not difference between packets coLinxu has injected and packets Windows has injected. You should trace the packets only under Linux on eth1 and the home network on an additional PC, to see what is truly o the wire. And you should not enable IP forwarding under Windows (a registry hack). Check the Source-MAC of packet you means it is wrong. It is truly from coLinux? - And last: I hope, you have configured different MAC for coLinux devices, and they are unique all 4 network adapters (LAN0, LAN1, eth0, eth1)? ---------------------------------------------------------------------- Comment By: Gowa (kamyshnikov) Date: 2010-04-10 07:31 Message: Hm... I think I've involved the problem. CoLinux eth1 <-bridge-> Windows LAN1 - connects home LAN CoLinux eth0 <-bridge-> Windows LAN0 - connects to ISP's LAN (and provides internet access for home LAN). Windows LAN0 has all protocols disabled. Windows LAN0 has no IP at all. LAN1, LAN0 - are both gigabit ethernet cards. CoLinux has a DHCP server for eth1. So Windows gets its IP for LAN1 from eth1. CoLinux eth0 receives IP address (like 192.168.x.x) from ISP. CoLinux connects PPPoE through eth0 to get real IP address. >> Do you really wand to provide your coLinux as Router for other machines on LAN1? YES >>The connection eth1 - LAN1 can made problems, if your network adapter have hardware checksum. This typically a problem on Gigabit cards. Currently I cannot understand this problem because I can sniff that packets with Wireshark in windows and with tcpdump in coLinux. And my sniffer shows the following: the packet that goes from Windows ETH1 reaches eth1 and then goes to eth0. But its source address is not changed. But, again, this apllies to 2nd or 3rd packet of TCP connection. This means that 1st packet goes off eth0 into internet with modified source IP address. And coLinux receives the response from internet hosts. Each other packet in established TCP connection goes with unmodified, local source ip address (192.168.x.x) that's why remote side cannot correctly reply. Thank you very much for your kind help! ---------------------------------------------------------------------- Comment By: Henry N. (henryn) Date: 2010-03-31 01:41 Message: The connection eth1 - LAN1 can made problems, if your network adapter have hardware checksum. This typically a problem on Gigabit cards. Why you used bridge for eth1 - LAN1? Do you really wand to provide your coLinux as Router for other machines on LAN1? If you use coLinux router only for the host self, then a TAP would better work for eth1. The other problem I would see with the IP address on LAN0. If the network stack will find any way without masquerading, then the packets will send directly. So the best way would be, that Windows does not have an ip address in the network of eth0. Give LAN0 no network address, Under Windows you should disable all network protocols for LAN0. ---------------------------------------------------------------------- Comment By: Gowa (kamyshnikov) Date: 2010-03-14 18:13 Message: Thanks for your answer! You understand right - coLinux is intended to act as router. You're suggesting me to have other configuration than I want. In fact both LAN0 and LAN1 in Windows have IP addresses. LAN0 gets IP from ISP's DHCP srv (there is no ADSL modem in my network - I have ethernet LAN with private IP). LAN1 gets IP from coLinux. coLinux on LAN0 can establish PPPoE connection to provide Internet to itself and Windows. Windows uses LAN1 coLinux's IP as main gateway. Currently I have absolutely the same configuration with VirtualBOX (because I didn't manage to get coLinux work propertly) - and it works. I did really sniffed my LAN interfaces with Wireshark. coLinux had an access to internet. Windows has managed to PING internet machines through coLinux (so masquerading partially worked). Windows even managed to open telnet connections!!! But no more - every subsequent packet after successfully opened (ACKnowledged TCP connection) has gone out of coLinux with LOCAL source IP address. It was not replaced by PPPoE's WAN IP. ---------------------------------------------------------------------- Comment By: Henry N. (henryn) Date: 2010-03-08 23:21 Message: If I understand right, then use wand to use coLinux as router for the windows host? LAN0 you have connected only with an ADSL-Modem, and LAN1 is your internal network. Check, that LAN1 does not have an IP address on Window side. Check, that Windows host must use the IP address of coLinux eth1 as default gateway. Have you enabled ip forward? Simple NAT works with these commands: iptables -A POSTROUTING -j MASQUERADE -t nat echo "1" > /proc/sys/net/ipv4/ip_forward It's very simple and natting in both directions. Please lets see your firewall rules for the NAT, you can get it with iptables-restore. The traffic way for TCP packets you can check with "watch iptables -L -v". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2965587&group_id=98788 |
From: SourceForge.net <no...@so...> - 2010-04-11 20:54:03
|
Bugs item #2985260, was opened at 2010-04-11 05:58 Message generated for change (Comment added) made by henryn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2985260&group_id=98788 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Daemons (Windows) Group: v0.8.x (devel) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Shai (vshai) Assigned to: Nobody/Anonymous (nobody) Summary: Slirp daemon crashing Initial Comment: This seems similar to the bug reported here: http://sourceforge.net/tracker/index.php?func=detail&aid=2055697&group_id=98788&atid=622063 that was fixed and closed. The difference is the rate. It's very hard to reproduce nowadays but it still happens once in a while. Bbefore, the bug could be reproduced after 5-10 minutes of heavy network, now it happens after 20+ hours or so. So this is probably a different bug. Happens with coLinux 0.8.0 but I suspect with other versions as well. Although slirp crashes, coLinux still works properly albeit no networking. ---------------------------------------------------------------------- >Comment By: Henry N. (henryn) Date: 2010-04-11 22:54 Message: Hello Shai, please try to debug it. Here is the help: http://colinux.wikia.com/wiki/Debugging_Daemons ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2985260&group_id=98788 |
From: SourceForge.net <no...@so...> - 2010-04-11 03:58:52
|
Bugs item #2985260, was opened at 2010-04-11 06:58 Message generated for change (Tracker Item Submitted) made by vshai You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2985260&group_id=98788 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Daemons (Windows) Group: v0.8.x (devel) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Shai (vshai) Assigned to: Nobody/Anonymous (nobody) Summary: Slirp daemon crashing Initial Comment: This seems similar to the bug reported here: http://sourceforge.net/tracker/index.php?func=detail&aid=2055697&group_id=98788&atid=622063 that was fixed and closed. The difference is the rate. It's very hard to reproduce nowadays but it still happens once in a while. Bbefore, the bug could be reproduced after 5-10 minutes of heavy network, now it happens after 20+ hours or so. So this is probably a different bug. Happens with coLinux 0.8.0 but I suspect with other versions as well. Although slirp crashes, coLinux still works properly albeit no networking. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2985260&group_id=98788 |
From: SourceForge.net <no...@so...> - 2010-04-10 05:31:45
|
Bugs item #2965587, was opened at 2010-03-08 21:23 Message generated for change (Comment added) made by kamyshnikov You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2965587&group_id=98788 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: MASQUERADE works only for first 1-3 TCP packets Initial Comment: having the following config: eth0 - bridged with windows LAN0 eth1 - bridged with windows LAN1 PPPoE connection established from coLinux through eth0. pings/HTTP and etc work perfectly from coLinux. trying to get Internet from Windows (iptables configured POSTROUTING/MASQUERADE thru ppp0): pings from windows work OK; but TCP - does not. According to Wireshark only couple packets in the begging of TCP session are masqueraded. Others go unchanged with local IPs in source field. So TCP connection can be established from windows, but w/o further communication. ---------------------------------------------------------------------- Comment By: Gowa (kamyshnikov) Date: 2010-04-10 09:31 Message: Hm... I think I've involved the problem. CoLinux eth1 <-bridge-> Windows LAN1 - connects home LAN CoLinux eth0 <-bridge-> Windows LAN0 - connects to ISP's LAN (and provides internet access for home LAN). Windows LAN0 has all protocols disabled. Windows LAN0 has no IP at all. LAN1, LAN0 - are both gigabit ethernet cards. CoLinux has a DHCP server for eth1. So Windows gets its IP for LAN1 from eth1. CoLinux eth0 receives IP address (like 192.168.x.x) from ISP. CoLinux connects PPPoE through eth0 to get real IP address. >> Do you really wand to provide your coLinux as Router for other machines on LAN1? YES >>The connection eth1 - LAN1 can made problems, if your network adapter have hardware checksum. This typically a problem on Gigabit cards. Currently I cannot understand this problem because I can sniff that packets with Wireshark in windows and with tcpdump in coLinux. And my sniffer shows the following: the packet that goes from Windows ETH1 reaches eth1 and then goes to eth0. But its source address is not changed. But, again, this apllies to 2nd or 3rd packet of TCP connection. This means that 1st packet goes off eth0 into internet with modified source IP address. And coLinux receives the response from internet hosts. Each other packet in established TCP connection goes with unmodified, local source ip address (192.168.x.x) that's why remote side cannot correctly reply. Thank you very much for your kind help! ---------------------------------------------------------------------- Comment By: Henry N. (henryn) Date: 2010-03-31 03:41 Message: The connection eth1 - LAN1 can made problems, if your network adapter have hardware checksum. This typically a problem on Gigabit cards. Why you used bridge for eth1 - LAN1? Do you really wand to provide your coLinux as Router for other machines on LAN1? If you use coLinux router only for the host self, then a TAP would better work for eth1. The other problem I would see with the IP address on LAN0. If the network stack will find any way without masquerading, then the packets will send directly. So the best way would be, that Windows does not have an ip address in the network of eth0. Give LAN0 no network address, Under Windows you should disable all network protocols for LAN0. ---------------------------------------------------------------------- Comment By: Gowa (kamyshnikov) Date: 2010-03-14 20:13 Message: Thanks for your answer! You understand right - coLinux is intended to act as router. You're suggesting me to have other configuration than I want. In fact both LAN0 and LAN1 in Windows have IP addresses. LAN0 gets IP from ISP's DHCP srv (there is no ADSL modem in my network - I have ethernet LAN with private IP). LAN1 gets IP from coLinux. coLinux on LAN0 can establish PPPoE connection to provide Internet to itself and Windows. Windows uses LAN1 coLinux's IP as main gateway. Currently I have absolutely the same configuration with VirtualBOX (because I didn't manage to get coLinux work propertly) - and it works. I did really sniffed my LAN interfaces with Wireshark. coLinux had an access to internet. Windows has managed to PING internet machines through coLinux (so masquerading partially worked). Windows even managed to open telnet connections!!! But no more - every subsequent packet after successfully opened (ACKnowledged TCP connection) has gone out of coLinux with LOCAL source IP address. It was not replaced by PPPoE's WAN IP. ---------------------------------------------------------------------- Comment By: Henry N. (henryn) Date: 2010-03-09 01:21 Message: If I understand right, then use wand to use coLinux as router for the windows host? LAN0 you have connected only with an ADSL-Modem, and LAN1 is your internal network. Check, that LAN1 does not have an IP address on Window side. Check, that Windows host must use the IP address of coLinux eth1 as default gateway. Have you enabled ip forward? Simple NAT works with these commands: iptables -A POSTROUTING -j MASQUERADE -t nat echo "1" > /proc/sys/net/ipv4/ip_forward It's very simple and natting in both directions. Please lets see your firewall rules for the NAT, you can get it with iptables-restore. The traffic way for TCP packets you can check with "watch iptables -L -v". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2965587&group_id=98788 |
From: SourceForge.net <no...@so...> - 2010-03-30 23:41:54
|
Bugs item #2965587, was opened at 2010-03-08 19:23 Message generated for change (Comment added) made by henryn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2965587&group_id=98788 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: MASQUERADE works only for first 1-3 TCP packets Initial Comment: having the following config: eth0 - bridged with windows LAN0 eth1 - bridged with windows LAN1 PPPoE connection established from coLinux through eth0. pings/HTTP and etc work perfectly from coLinux. trying to get Internet from Windows (iptables configured POSTROUTING/MASQUERADE thru ppp0): pings from windows work OK; but TCP - does not. According to Wireshark only couple packets in the begging of TCP session are masqueraded. Others go unchanged with local IPs in source field. So TCP connection can be established from windows, but w/o further communication. ---------------------------------------------------------------------- >Comment By: Henry N. (henryn) Date: 2010-03-31 01:41 Message: The connection eth1 - LAN1 can made problems, if your network adapter have hardware checksum. This typically a problem on Gigabit cards. Why you used bridge for eth1 - LAN1? Do you really wand to provide your coLinux as Router for other machines on LAN1? If you use coLinux router only for the host self, then a TAP would better work for eth1. The other problem I would see with the IP address on LAN0. If the network stack will find any way without masquerading, then the packets will send directly. So the best way would be, that Windows does not have an ip address in the network of eth0. Give LAN0 no network address, Under Windows you should disable all network protocols for LAN0. ---------------------------------------------------------------------- Comment By: Gowa (kamyshnikov) Date: 2010-03-14 18:13 Message: Thanks for your answer! You understand right - coLinux is intended to act as router. You're suggesting me to have other configuration than I want. In fact both LAN0 and LAN1 in Windows have IP addresses. LAN0 gets IP from ISP's DHCP srv (there is no ADSL modem in my network - I have ethernet LAN with private IP). LAN1 gets IP from coLinux. coLinux on LAN0 can establish PPPoE connection to provide Internet to itself and Windows. Windows uses LAN1 coLinux's IP as main gateway. Currently I have absolutely the same configuration with VirtualBOX (because I didn't manage to get coLinux work propertly) - and it works. I did really sniffed my LAN interfaces with Wireshark. coLinux had an access to internet. Windows has managed to PING internet machines through coLinux (so masquerading partially worked). Windows even managed to open telnet connections!!! But no more - every subsequent packet after successfully opened (ACKnowledged TCP connection) has gone out of coLinux with LOCAL source IP address. It was not replaced by PPPoE's WAN IP. ---------------------------------------------------------------------- Comment By: Henry N. (henryn) Date: 2010-03-08 23:21 Message: If I understand right, then use wand to use coLinux as router for the windows host? LAN0 you have connected only with an ADSL-Modem, and LAN1 is your internal network. Check, that LAN1 does not have an IP address on Window side. Check, that Windows host must use the IP address of coLinux eth1 as default gateway. Have you enabled ip forward? Simple NAT works with these commands: iptables -A POSTROUTING -j MASQUERADE -t nat echo "1" > /proc/sys/net/ipv4/ip_forward It's very simple and natting in both directions. Please lets see your firewall rules for the NAT, you can get it with iptables-restore. The traffic way for TCP packets you can check with "watch iptables -L -v". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2965587&group_id=98788 |
From: coLinux a. <col...@he...> - 2010-03-15 05:07:00
|
The autobuild system has detected a new revision in the source repository. Review last changed from changelog.txt, also attached in mail. Download the compiled version: http://www.henrynestler.com/colinux/autobuild/devel-20100314/ colinux-0.8.0-20100314.src.tgz (1058825 Bytes) daemons-0.8.0-20100314.dbg.zip (591826 Bytes) daemons-0.8.0-20100314.zip (478333 Bytes) Note, the autobuild compilation does not include an installer. Remember to reload the driver with these commands: colinux-daemon.exe --remove-driver colinux-daemon.exe --install-driver The vmlinux and modules are up to date. Please use last version from http://www.henrynestler.com/colinux/autobuild/devel-20100306/ The autobuild compilations are not official releases of Cooperative Linux software. There is no warranty that any autobuild version is stable. If use this autobuild version, please give us feedback of your experience. Job runs on machine with 64 bit version of gcc 4.3.2. A service from http://gcc.gnu.org/wiki/CompileFarm -- Lots of fun with newest version, Henry Nestler ------------------------------------------------------------------------ r1389 | henryn | 2010-03-14 12:32:43 +0000 (Sun, 14 Mar 2010) | 1 line Changed paths: M /branches/devel/NEWS M /branches/devel/conf/linux-2.6.22.18-config M /branches/stable/NEWS M /branches/stable/conf/linux-2.6.22.18-config * 2.6.22.18 config: Disable CONFIG_SYSFS_DEPRECATED. (El Topo) ------------------------------------------------------------------------ |
From: SourceForge.net <no...@so...> - 2010-03-14 17:13:41
|
Bugs item #2965587, was opened at 2010-03-08 21:23 Message generated for change (Comment added) made by kamyshnikov You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2965587&group_id=98788 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: MASQUERADE works only for first 1-3 TCP packets Initial Comment: having the following config: eth0 - bridged with windows LAN0 eth1 - bridged with windows LAN1 PPPoE connection established from coLinux through eth0. pings/HTTP and etc work perfectly from coLinux. trying to get Internet from Windows (iptables configured POSTROUTING/MASQUERADE thru ppp0): pings from windows work OK; but TCP - does not. According to Wireshark only couple packets in the begging of TCP session are masqueraded. Others go unchanged with local IPs in source field. So TCP connection can be established from windows, but w/o further communication. ---------------------------------------------------------------------- Comment By: Gowa (kamyshnikov) Date: 2010-03-14 20:13 Message: Thanks for your answer! You understand right - coLinux is intended to act as router. You're suggesting me to have other configuration than I want. In fact both LAN0 and LAN1 in Windows have IP addresses. LAN0 gets IP from ISP's DHCP srv (there is no ADSL modem in my network - I have ethernet LAN with private IP). LAN1 gets IP from coLinux. coLinux on LAN0 can establish PPPoE connection to provide Internet to itself and Windows. Windows uses LAN1 coLinux's IP as main gateway. Currently I have absolutely the same configuration with VirtualBOX (because I didn't manage to get coLinux work propertly) - and it works. I did really sniffed my LAN interfaces with Wireshark. coLinux had an access to internet. Windows has managed to PING internet machines through coLinux (so masquerading partially worked). Windows even managed to open telnet connections!!! But no more - every subsequent packet after successfully opened (ACKnowledged TCP connection) has gone out of coLinux with LOCAL source IP address. It was not replaced by PPPoE's WAN IP. ---------------------------------------------------------------------- Comment By: Henry N. (henryn) Date: 2010-03-09 01:21 Message: If I understand right, then use wand to use coLinux as router for the windows host? LAN0 you have connected only with an ADSL-Modem, and LAN1 is your internal network. Check, that LAN1 does not have an IP address on Window side. Check, that Windows host must use the IP address of coLinux eth1 as default gateway. Have you enabled ip forward? Simple NAT works with these commands: iptables -A POSTROUTING -j MASQUERADE -t nat echo "1" > /proc/sys/net/ipv4/ip_forward It's very simple and natting in both directions. Please lets see your firewall rules for the NAT, you can get it with iptables-restore. The traffic way for TCP packets you can check with "watch iptables -L -v". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2965587&group_id=98788 |
From: SourceForge.net <no...@so...> - 2010-03-13 22:42:03
|
Patches item #1210391, was opened at 2005-05-28 15:33 Message generated for change (Settings changed) made by henryn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622065&aid=1210391&group_id=98788 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: A. Alper ATICI (ulpair) Assigned to: Nobody/Anonymous (nobody) Summary: Squashfs + Unionfs patch Initial Comment: Hello, I've put together a private patch against 0.6.3-pre13 for Squashfs 2.1 and Unionfs 0.12a available at: http://cvs.sourceforge.net/viewcvs.py/*checkout*/colonist/colinux/patch/linux-private.patch?rev=1.2 Kernel config file (which differs by 2 lines only) is: http://cvs.sourceforge.net/viewcvs.py/*checkout*/colonist/colinux/conf/linux-config?rev=1.2 Colonist project (http://colonist.sf.net) would benefit a lot from a statically linked squashfs module. Unionfs is bonus. :-) ---------------------------------------------------------------------- Comment By: George P Boutwell (gboutwel) Date: 2005-06-01 16:30 Message: Logged In: YES user_id=30412 Rather than as an linux-private-patch, what about doing these as 'seperate' make targets? With the cloop module I'm hoping to add to coLinux, I'm going to do it as an 'seperate' make target, the goal being to keep the coLinux functionality (since it's still very much changing) seperated from other things that we add to the kernel for other reasons. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622065&aid=1210391&group_id=98788 |
From: SourceForge.net <no...@so...> - 2010-03-13 21:14:41
|
Feature Requests item #1489544, was opened at 2006-05-16 15:16 Message generated for change (Comment added) made by henryn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622066&aid=1489544&group_id=98788 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: fedora core installation Initial Comment: Hey, there should be a version of colinux that basicly runs a full version of fedora core on top of windows. Also it needs to be easy to setup. I know this is alot to ask but fedora core is awsome and very useful. I would like to switch to fedora core as my primary operating system but numerous things keep me from doing so. This seems like a good solution to my problem and I'm sure there are allot of other people in the same boat. ---------------------------------------------------------------------- >Comment By: Henry N. (henryn) Date: 2010-03-13 22:14 Message: Since network and disk (scsi) drivers are listed as PCI device. This should work now. ---------------------------------------------------------------------- Comment By: Dr Bill C Riemers (docbill) Date: 2007-07-19 05:03 Message: Logged In: YES user_id=290784 Originator: NO The images work well, but it would be really nice to figure out a way to run anaconda under coLinux. Then it would be possible to just do a network install of any Fedora, Red Hat, or CentOS version. ---------------------------------------------------------------------- Comment By: Danny Staple (orionrobots) Date: 2006-07-03 12:36 Message: Logged In: YES user_id=748225 Its interesting you should mention that furyy, as it seems to be very similar, or may contribute to what this post: http://www.linuxquestions.org/questions/showthread.php?t=460083&highlight=boot+iso was asking. It would be pretty amazing (but it may require more integration work) to get colinux to be able to boot from a Knoppix or similar ISO. Danny ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-07-03 12:27 Message: Logged In: NO I made a guide at http://wiki.colinux.org/mediawiki/index.php/Fedora4MinimalInstall071 how you can install your own fedora with qemu. After installing with your own options you convert it to colinux. It tells also about how to setup your x-server to use xdmcp. For Fedora core 5 you need to do some adjustments for udev http://wiki.colinux.org/mediawiki/index.php/Fedora5MinimalInstall071 which somebody told at the mailinglist and I tried. It works. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-05-25 23:36 Message: Logged In: NO I have made a Fedora Core 5 2GB image. Anyone wanting to test it for bugs are welcome as Henry is at holidays : http://www.freewebtown.com/cobd/ Image is in rar as the host seems to have 260mb diskusage limit :P Any future version might get published at ftp.funet.fi. Return email from staff pending... ---------------------------------------------------------------------- Comment By: FurYy (furyy) Date: 2006-05-16 17:48 Message: Logged In: YES user_id=1419670 Maybe it would be more smart to just make some base root fs image and some scripts so that the user could install any flavor of linux he/she wants by just downloading a iso and extracting the vmlinux from the iso. I'll look into it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622066&aid=1489544&group_id=98788 |
From: SourceForge.net <no...@so...> - 2010-03-13 21:11:16
|
Feature Requests item #1898496, was opened at 2008-02-21 09:05 Message generated for change (Settings changed) made by henryn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622066&aid=1898496&group_id=98788 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: prepackaged GUI image Initial Comment: The slashdot discussion (http://developers.slashdot.org/developers/04/04/12/211236.shtml?tid=106) shows quite well that many users would find it easier if there was a prepackaged version that comes with all the necessary programs and configs to easily run a UI (i.e. X11/KDE) version on top of coLinux. Something like this would preferably come with the necessary X server for the windows side of things and be sufficiently preconfigured ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-02-23 06:42 Message: I would agree, this really isn't the scope of the project, there are already such pre-packaged versions provided by 3rd parties (i.e. andLinux). ---------------------------------------------------------------------- Comment By: George P Boutwell (gboutwel) Date: 2008-11-21 20:59 Message: The original author and I had a few discussions about this back when we first started the port to 2.6 kernels... The current developers may have different opinions, but I tend to agree with what was decided then. To summarize: coLinux project's main purpose is to provide the patched kernel and host machine drivers necessary to accomplish fast (near native performance) virtualized Linux. With the few developers working on the project is is completely unrealistic to expect or extend this purpose beyond that. Focusing on that, it was decided that coLinux as a project would not go out of it's way to build and support an installer which included everything for graphical images, this in turn allowed several projects to be built on coLinux that servered that purpose similar to that of andLinux (used to be one called Colonize or something like that too but couldn't find it on Source Forge today when I looked). Henry, you think this choice to continue to focus on our main goal of providing the kernel and drivers for a fast virtualized linux is the right one, then you can probably consider this request resolved. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-08-31 22:33 Message: Logged In: NO this is a rather academic discussion, those who tackle this idea are going to decide what tools and languages they use ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-08-31 19:29 Message: Logged In: NO " Most mainstream scripting languages are well-supported on a rather wide number of platforms, unlike C# development tools, which still require numerous non-standard dependencies to be properly installed and set up for each platform individually. " Sorry, but this isin't true! To develope using C# you can use mono to compile the stuff you write on all supported platform, windows too. You can write it with any ide/rad you like, naturally there are tools to do like monodevelop on linux and sharpdevelop/visual studio (express) on windows. This is the same for any scripting language: you need the runtime to execute the script and any editor to write the stuff I didn't see any kinda of non-standard dependencies: - On windows, you have the runtime simply doing updates - On linux, many major distros has it ((open)suse, ubuntu, fedora, gentoo) Another example: if you use GTK you need binding ... like any other programming language that doesn't resides directly on the libraries (note: technically you can compile in the bindings using a couple of mono tools) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-08-31 07:55 Message: Logged In: NO I think, this frontend would be Win32-specific in any way, so it really doesn't matter what language is used for implementation, however it may be easier to favor an implementation language that is commonly and widely known within the community of potential contributors, so that future maintenance of such a frontend would not be limited to an unnecessarily small group of contributor who are sufficiently familiar with the corresponding language. Using a scripting language such as Python or Ruby on the other hand, brings the added advantage that potential contributors/maintainers of such a frontend would not necessarily have to install any complex dependencies (think IDE, compilers, runtime libs). Most mainstream scripting languages are well-supported on a rather wide number of platforms, unlike C# development tools, which still require numerous non-standard dependencies to be properly installed and set up for each platform individually. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-08-29 21:16 Message: Logged In: NO Just a note to the previous comment ... if necessary you can use python too for development using ironpython! ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-08-29 21:14 Message: Logged In: NO Python is awesome, i know, but why not C#? Mono is distribuited with major linux systems and on windows you're fully integrated with .NET! I think that a lot of users are windows based so a fully native interface and a fully integrated application can do better than a python application Another really important stuff is that with .NET you can easely build two interfaces and load the preferred at startup time simply checking the operative system ... with the interfaces that relies on a set of functionalities implemented in a backend ---------------------------------------------------------------------- Comment By: Henry N. (henryn) Date: 2008-08-29 20:50 Message: Logged In: YES user_id=579204 Originator: NO If somebody has knowledges about Python, then here are some of GUI scripts for coLinux configuration, that has to be finish: http://colinux.svn.sourceforge.net/viewvc/colinux/branches/devel/src/colinux/user/configurator/ It's very old. First needs to remove the outdated XML from that. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-08-29 18:26 Message: Logged In: NO The following site contains a listing of available GUI toolkit bindings for python, including a section about UI-building toolkits (e.g. dialog editors): http://wiki.python.org/moin/GuiProgramming In addition, here's a site providing a full tutorial about PyQT programming: http://www.commandprompt.com/community/pyqt/book1 http://wiki.python.org/moin/PyQt PythonStudio includes a full GUI editor, as well: http://www.codeplex.com/IronPythonStudio ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-08-29 08:57 Message: Logged In: NO thinking about it, the most promising approach would probably be to simply implement this totally separate, using a scripting language and a GUI toolkit, i.e. something like python or ruby with GTK/QT bindings. This way, it would not unnecessarily affect any of the existing code, would be very much straight forward and also flexible and easily extendsible for future changes ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-08-29 08:24 Message: Logged In: NO something like this would probably be best implemented as a separate, standaline "profile manager", so that creating/editing and deleting profiles can be done via this app, and starting a profile would only entail passing the stored parameters to the corresponding binaries, this would keep the overhead to a minimum. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-08-29 08:03 Message: Logged In: NO see "andLinux" however, usability could still be somewhat improved for users with a non-nix background, in particular the whole setup process should either be more intuitive or simply provide some more GUI frontends, i.e. by allowing the most common actions to be directly done from the executables via UI means, rather than requiring users to pass lots of cryptic options via command line parameters. In this context, it would already be a significant improvement if the most basic and relevant parameters could be configured via some sort of GUI frontend, be it embedded or not, so that running a process without REQUIRED parameters automatically brings up a dialog for users to configure the most important parameters, and optionally save them as startup profiles, so that they may next time select a startup profile or create a new one. Similar to how firefox starts actually: provide a way for customization, preferably using lots of nifty tooltips and explanations and once a user has a working config, enable them to save and reuse configs ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622066&aid=1898496&group_id=98788 |
From: SourceForge.net <no...@so...> - 2010-03-13 21:09:19
|
Feature Requests item #2813562, was opened at 2009-06-28 17:52 Message generated for change (Settings changed) made by henryn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622066&aid=2813562&group_id=98788 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Priority: 5 Private: No Submitted By: MitzaPiticu (mitzampt) Assigned to: Nobody/Anonymous (nobody) Summary: Linux coLinux Initial Comment: I'm interested in the linux port/version of coLinux, i know somebody is working on it, but i don't know if you are, guys ---------------------------------------------------------------------- Comment By: Henry N. (henryn) Date: 2009-06-28 20:50 Message: Please have a look into file "doc/building", section "5.3. For Linux as host". The file you will find in SVN here: http://colinux.svn.sourceforge.net/viewvc/colinux/branches/devel/doc/building But this mode is only for development coLinux basics and testing, not all functions are supported, and it works only on 32 bit Linux hosts. Better you use the usermode Linux (UML). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622066&aid=2813562&group_id=98788 |
From: SourceForge.net <no...@so...> - 2010-03-13 21:08:29
|
Feature Requests item #2896324, was opened at 2009-11-12 01:40 Message generated for change (Comment added) made by henryn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622066&aid=2896324&group_id=98788 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Interface Improvements (example) Group: None >Status: Closed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Simple conditions in cofig file Initial Comment: Sometimes one or another option in config file depends of command line parameters or other options in config file. It will be usefull to add condional processing of options: if $CONSOLE == 'fltk' # $CONSOLE - predefined variable with name of console from -t <...> cocon=150x65 else cocon=150x69 endif ---------------------------------------------------------------------- >Comment By: Henry N. (henryn) Date: 2010-03-13 22:08 Message: This is doable also without IF conditions. Simple move the conditions from inside config file to the command line, for example: A) colinux-daemon -t fltk cocon=150x65 @colinux.conf B) colinux-daemon -t nt cocon=150x69 @colinux.conf Or, create 3 configs. colinux-basic.conf : with all your stuff colinux-fltk.conf : with options only in fltk console colinux-nt.conf : with options only for nt console Than run two different versions from batch or shortcut: A) colinux-daemon -t fltk @colinux-fltk.conf @colinux-basic.conf B) colinux-daemon -t nt @colinux-nt.conf @colinux-basic.conf ---------------------------------------------------------------------- Comment By: Henry N. (henryn) Date: 2009-11-12 20:47 Message: For this move the cocon into the batch from where you should set also fltk or nt. for example FLTK.BAT: colinux_daemon -t fltk cocon=150x65 @colinux.conf and the other NT.BAT: colinux_daemon -t nt cocon=150x69 @colinux.conf ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622066&aid=2896324&group_id=98788 |
From: SourceForge.net <no...@so...> - 2010-03-13 21:01:15
|
Feature Requests item #2884303, was opened at 2009-10-23 00:56 Message generated for change (Settings changed) made by henryn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622066&aid=2884303&group_id=98788 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: U3 Support (coLinux on a USB stick) ? Initial Comment: Is there any chance for coLinux to run as a self-contained service from a USB memory stick? There's a corresponding standard called U3: http://en.wikipedia.org/wiki/U3 ---------------------------------------------------------------------- Comment By: Henry N. (henryn) Date: 2009-10-28 22:55 Message: This is not doable. coLinux needs to install a hardware driver (linux.sys), and this is not allowed by U3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622066&aid=2884303&group_id=98788 |
From: SourceForge.net <no...@so...> - 2010-03-13 20:57:58
|
Bugs item #1770815, was opened at 2007-08-09 15:39 Message generated for change (Comment added) made by henryn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=1770815&group_id=98788 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: v0.8.x (devel) >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Problems with Cisco VPN client and CoLinux ethertap Initial Comment: Hi all, I noticed a problem with the Cisco VPN client and CoLinux ethertap. My Colinux has two virtual devices: 1) A slirpd (this is used for Internet/Default GW) 2) A tun/tap devices (used for speeding up X11) After I installed the Cisco VPN Client for Windows XP (32bit) I have some troubles. This goes away after deinstalling the VPN Client. My ethertap device has the IP 192.168.55.40 inside CoLinux and 192.168.55.1 on the windows side. The strange thing is i can ping the 192.168.55.40 IP from windows, but the Colinux side can't ping anymore the 192.168.55.1 Windows IP. That is strange. I can also ssh in Colinux using the 192.168.55.40 IP. Any ideas? Is this a ethertap problem? Bye and happy hacking. ---------------------------------------------------------------------- >Comment By: Henry N. (henryn) Date: 2010-03-13 21:57 Message: last comment give the resolution. Close this now. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-12-15 21:34 Message: This problem is indeed fixed by disabling the stateful firewall in the (UCLA) Cisco VPN Client via Options->Stateful Firewall (always on). ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-08-09 21:44 Message: Logged In: NO Hi! Maybe I have an idea about this problem. If you install Cisco VPN Client for Windows XP, it also installs parts of the ZoneAlarm-Firewall as the intern firewall of the VPN client, as I remember. If you have a firewall installed on Windows (not ZoneAlarm), this situation can cause many problems, because the ZoneAlarm-Firewall sometimes activates itself for whole Windows and not only for the VPN-Connection. It can go so far that you have no more network connection any more because ZoneAlarm is blocking all connection. The only possibility you have, is searching the ZoneAlarm-Firewall driver in your system32-directory (a .sys file) and deactivate it in registry. If you have done this, and after an reboot, you can delete the driver and all other dll's from ZoneAlarm. Cisco VPN-Client is still working, but you should not have problems any more. Another advice with using Cisco VPN-Client and Colinux is, not using tun/tap on colinux while activating the VPN-tunnel, because you are loosing all your connections between Windows and Colinux over this connection. If you only use slirpd, everything works well. Bye ---------------------------------------------------------------------- Comment By: Henry N. (henryn) Date: 2007-08-09 21:00 Message: Logged In: YES user_id=579204 Originator: NO Does VPN cliend perhaps enable a firewall for the tap on Windows side? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=1770815&group_id=98788 |
From: SourceForge.net <no...@so...> - 2010-03-13 20:55:28
|
Bugs item #986327, was opened at 2004-07-07 03:35 Message generated for change (Comment added) made by henryn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=986327&group_id=98788 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: BJH (californiakidd) Assigned to: Nobody/Anonymous (nobody) Summary: install aborts over remote desktop Initial Comment: I grabbed the coLinux-20040622.exe and executed it over NT's remote desktop connection. When the installer started to process the TAP installation, the network connection was shutdown. The installation, additionally, aborted due to the shutdown of the network. A manual install of the network drivers does work without the shutdown events. [This needs further verification if the installer shutdowns the network for anybody or just a random few with similar configurations.] ---------------------------------------------------------------------- >Comment By: Henry N. (henryn) Date: 2010-03-13 21:55 Message: This can't fix, because all network connections will receive a short re-connect at the time the TAP driver installs. This is from internally work of Windows. You can try to install the TAP driver manually with device manager. ---------------------------------------------------------------------- Comment By: George P Boutwell (gboutwel) Date: 2005-02-24 21:23 Message: Logged In: YES user_id=30412 I was able to install 0.6.2 final over Remote Desktop on a Win2k Server box. It was the form of Terminal Server for Remote Administration, not an True multiple person Terminal Server. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=986327&group_id=98788 |
From: SourceForge.net <no...@so...> - 2010-03-13 20:50:26
|
Bugs item #2899522, was opened at 2009-11-18 02:28 Message generated for change (Comment added) made by henryn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2899522&group_id=98788 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installer Group: v0.7.x (release) >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Can't install or uninstall driver (upgrade from old version) Initial Comment: I just recently upgraded to CoLinux 0.7.5 from 0.6.3. (I hadn't run CoLinux in a long time, and the old version immediately rebooted the computer upon trying to run it.) However, the new version won't run, saying it can't contact the driver. When I try to install the driver, it says it is already installed. Mostly it complains it can't read a file, but won't tell me what file. When I used Process Monitor, there aren't any obvious file open failures. (Some registry Name Not Found, but none obvious as the source of the problem.) I tried doing a full uninstall, then re-installing and uninstalling 0.6.3, and re-installing 0.7.5 again, but there was no change. C:\Program Files\coLinux>colinux-daemon.exe --status-driver Cooperative Linux Daemon, 0.7.5 Daemon compiled on Mon Sep 14 22:26:21 2009 checking if the driver is installed colinux: manager open: The system cannot find the file specified. couldn't get driver handle C:\Program Files\coLinux>colinux-daemon.exe --install-driver Cooperative Linux Daemon, 0.7.5 Daemon compiled on Mon Sep 14 22:26:21 2009 driver already installed daemon: driver installed C:\Program Files\coLinux>colinux-debug-daemon.exe -d colinux: manager open: The system cannot find the file specified. ---------------------------------------------------------------------- >Comment By: Henry N. (henryn) Date: 2010-03-13 21:50 Message: Close this now. Description for manually remove the broken driver exist in manual "colinux-daemon.txt". ---------------------------------------------------------------------- Comment By: Henry N. (henryn) Date: 2009-11-18 22:03 Message: Some times have res such case you have. The problem is, that the driver is installed, but it is not runnng, so the daemon can not open the file. The "file" is not a real file, it is a device "CoLinuxDriver". You should follow the steps from colinux-daemon.txt: """ You can also remove the linux.sys driver with standard Windows tools and many mouse clicks. Open your System settings - control panel - hardware device manager - under "View" options enable "view hidden drivers" - open the non PnP drivers - locate and uninstall the device entry "CoLinuxDriver" and reboot Windows. """ Here is a Screenshot from hardware device manager: http://www.henrynestler.com/colinux/screenshoots/HardwareDeviceManager.png Essential are the steps: Remove coLinux driver - reboot Windows - install coLinux driver. Because sometimes the driver can not remove, while it is in use, for example by a "coLinux as service". ---------------------------------------------------------------------- Comment By: Mike Frysinger (vapier) Date: 2009-11-18 02:41 Message: try reading colinux-daemon.txt. it covers uninstalling the driver (automatically and manually). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2899522&group_id=98788 |
From: SourceForge.net <no...@so...> - 2010-03-13 20:45:38
|
Bugs item #2921083, was opened at 2009-12-25 15:25 Message generated for change (Comment added) made by henryn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2921083&group_id=98788 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Configuration >Group: v0.7.x (release) >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: crashed when building android Initial Comment: colinux crashed when building android system, the log is as below: C:\Documents and Settings\Administrator>cd c:\coLinux C:\coLinux>debian.bat C:\coLinux>colinux-daemon -t nt @e:\colinux\debian.conf Cooperative Linux Daemon, 0.7.3 Daemon compiled on Sat May 24 22:36:07 2008 PID: 1420 colinux: booting console: Coopeartive Linux console started Linux version 2.6.22.18-co-0.7.3 (hn@coLinux) (gcc version 4.1.2) #1 PREEMPT Sat May 24 22:27:30 UTC 2008 colinux-net-daemon: searching TAP device named "tuntap" colinux-net-daemon: found TAP device named "tuntap" colinux-net-daemon: opening TAP: "tuntap" colinux-net-daemon: TAP driver version 8.4 colinux-net-daemon: enabling TAP... 800MB LOWMEM available. initrd enabled: start: 0xf1f9a000 size: 0x00065881 Entering add_active_range(0, 0, 204800) 0 entries of 256 used Zone PFN ranges: DMA 0 -> 0 Normal 0 -> 204800 early_node_map[1] active PFN ranges 0: 0 -> 204800 On node 0 totalpages: 204800 DMA zone: 0 pages used for memmap Normal zone: 1600 pages used for memmap Normal zone: 203200 pages, LIFO batch:31 Built 1 zonelists. Total pages: 203200 Kernel command line: cdrom0=\Device\Cdrom0 root=/dev/cobd0 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 Setting proxy interrupt vectors PID hash table entries: 4096 (order: 12, 16384 bytes) Console: colour CoCON 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 807680k/819200k available (1705k kernel code, 0k reserved, 470k data, 12 8k init, 0k highmem) virtual kernel memory layout: fixmap : 0xffffc000 - 0xfffff000 ( 12 kB) vmalloc : 0xf2800000 - 0xffffa000 ( 215 MB) lowmem : 0xc0000000 - 0xf2000000 ( 800 MB) .init : 0xc0322000 - 0xc0342000 ( 128 kB) .data : 0xc02aa638 - 0xc031ffe4 ( 470 kB) .text : 0xc0100000 - 0xc02aa638 (1705 kB) Calibrating delay loop... 10197.40 BogoMIPS (lpj=50987008) Mount-cache hash table entries: 512 CPU: After generic identify, caps: bfebfbff 00100000 00000000 00000000 0000451d 00000000 00000000 monitor/mwait feature present. using mwait in idle threads. CPU: Trace cache: 12K uops, L1 D cache: 16K CPU: L2 cache: 256K CPU: After all inits, caps: bfebf3ff 00100000 00000000 0000b180 0000451d 0000000 0 00000000 Compat vDSO mapped to ffffe000. CPU: Intel Genuine Intel(R) CPU 3.06GHz stepping 01 Checking 'hlt' instruction... OK. NET: Registered protocol family 16 NET: Registered protocol family 2 IP route cache hash table entries: 32768 (order: 5, 131072 bytes) TCP established hash table entries: 131072 (order: 8, 1048576 bytes) TCP bind hash table entries: 65536 (order: 6, 262144 bytes) TCP: Hash tables configured (established 131072 bind 65536) TCP reno registered checking if image is initramfs...it isn't (no cpio magic); looks like an initrd Freeing initrd memory: 406k freed VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) cofuse init 0.1 (API version 2.2) io scheduler noop registered io scheduler anticipatory registered (default) io scheduler deadline registered io scheduler cfq registered RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize cobd: loaded (max 32 devices) loop: module loaded conet: loaded (max 16 devices) conet0: initialized serio: cokbd at irq 1 mice: PS/2 mouse device common for all mice input: AT Translated Set 2 keyboard as /class/input/input0 TCP cubic registered NET: Registered protocol family 1 NET: Registered protocol family 17 Using IPI Shortcut mode RAMDISK: Compressed image found at block 0 VFS: Mounted root (ext2 filesystem). ReiserFS: cobd0: warning: sh-2021: reiserfs_fill_super: can not find reiserfs on cobd0 kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on cobd0, internal journal EXT3-fs: mounted filesystem with ordered data mode. VFS: Mounted root (ext3 filesystem). Trying to move old root to /initrd ... /initrd does not exist. Ignored. Unmounting old root Trying to free ramdisk memory ... okay Freeing unused kernel memory: 128k freed Adding 131064k swap on /dev/cobd1. Priority:-1 extents:1 across:131064k EXT3 FS on cobd0, internal journal device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: dm-...@re... kjournald starting. Commit interval 5 seconds EXT3-fs warning: maximal mount count reached, running e2fsck is recommended EXT3 FS on loop0, internal journal EXT3-fs: mounted filesystem with ordered data mode. NET: Registered protocol family 10 lo: Disabled Privacy Extensions eth0: no IPv6 routers present colinux: Linux VM terminated colinux: BUG at ...le-0.7.3-snapshot/linux-2.6.22.18-source/mm/page_alloc.c:310 console: Monitor1420: Detached C:\coLinux>debian.bat C:\coLinux>colinux-daemon -t nt @e:\colinux\debian.conf Cooperative Linux Daemon, 0.7.3 Daemon compiled on Sat May 24 22:36:07 2008 PID: 2676 console: Coopeartive Linux console started colinux: booting colinux-net-daemon: searching TAP device named "tuntap" Linux version 2.6.22.18-co-0.7.3 (hn@coLinux) (gcc version 4.1.2) #1 PREEMPT Sat May 24 22:27:30 UTC 2008 800MB LOWMEM available. initrd enabled: start: 0xf1f9a000 size: 0x00065881 Entering add_active_range(0, 0, 204800) 0 entries of 256 used Zone PFN ranges: DMA 0 -> 0 Normal 0 -> 204800 early_node_map[1] active PFN ranges 0: 0 -> 204800 On node 0 totalpages: 204800 DMA zone: 0 pages used for memmap Normal zone: 1600 pages used for memmap Normal zone: 203200 pages, LIFO batch:31 Built 1 zonelists. Total pages: 203200 Kernel command line: cdrom0=\Device\Cdrom0 root=/dev/cobd0 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 Setting proxy interrupt vectors PID hash table entries: 4096 (order: 12, 16384 bytes) Console: colour CoCON 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) colinux-net-daemon: found TAP device named "tuntap" colinux-net-daemon: opening TAP: "tuntap" colinux-net-daemon: TAP driver version 8.4 colinux-net-daemon: enabling TAP... Memory: 807680k/819200k available (1705k kernel code, 0k reserved, 470k data, 12 8k init, 0k highmem) virtual kernel memory layout: fixmap : 0xffffc000 - 0xfffff000 ( 12 kB) vmalloc : 0xf2800000 - 0xffffa000 ( 215 MB) lowmem : 0xc0000000 - 0xf2000000 ( 800 MB) .init : 0xc0322000 - 0xc0342000 ( 128 kB) .data : 0xc02aa638 - 0xc031ffe4 ( 470 kB) .text : 0xc0100000 - 0xc02aa638 (1705 kB) Calibrating delay loop... 2785.28 BogoMIPS (lpj=13926400) Mount-cache hash table entries: 512 CPU: After generic identify, caps: bfebfbff 00100000 00000000 00000000 0000451d 00000000 00000000 monitor/mwait feature present. using mwait in idle threads. CPU: Trace cache: 12K uops, L1 D cache: 16K CPU: L2 cache: 256K CPU: After all inits, caps: bfebf3ff 00100000 00000000 0000b180 0000451d 0000000 0 00000000 Compat vDSO mapped to ffffe000. CPU: Intel Genuine Intel(R) CPU 3.06GHz stepping 01 Checking 'hlt' instruction... OK. NET: Registered protocol family 16 NET: Registered protocol family 2 IP route cache hash table entries: 32768 (order: 5, 131072 bytes) TCP established hash table entries: 131072 (order: 8, 1048576 bytes) TCP bind hash table entries: 65536 (order: 6, 262144 bytes) TCP: Hash tables configured (established 131072 bind 65536) TCP reno registered checking if image is initramfs...it isn't (no cpio magic); looks like an initrd Freeing initrd memory: 406k freed VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) cofuse init 0.1 (API version 2.2) io scheduler noop registered io scheduler anticipatory registered (default) io scheduler deadline registered io scheduler cfq registered RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize cobd: loaded (max 32 devices) loop: module loaded conet: loaded (max 16 devices) conet0: initialized serio: cokbd at irq 1 mice: PS/2 mouse device common for all mice input: AT Translated Set 2 keyboard as /class/input/input0 TCP cubic registered NET: Registered protocol family 1 NET: Registered protocol family 17 Using IPI Shortcut mode RAMDISK: Compressed image found at block 0 VFS: Mounted root (ext2 filesystem). ReiserFS: cobd0: warning: sh-2021: reiserfs_fill_super: can not find reiserfs on cobd0 EXT3-fs: INFO: recovery required on readonly filesystem. EXT3-fs: write access will be enabled during recovery. kjournald starting. Commit interval 5 seconds EXT3-fs: recovery complete. EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on cobd0, internal journal EXT3-fs: mounted filesystem with ordered data mode. VFS: Mounted root (ext3 filesystem). Trying to move old root to /initrd ... /initrd does not exist. Ignored. Unmounting old root Trying to free ramdisk memory ... okay Freeing unused kernel memory: 128k freed Adding 131064k swap on /dev/cobd1. Priority:-1 extents:1 across:131064k EXT3 FS on cobd0, internal journal device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: dm-...@re... kjournald starting. Commit interval 5 seconds EXT3-fs warning: maximal mount count reached, running e2fsck is recommended EXT3 FS on loop0, internal journal EXT3-fs: recovery complete. EXT3-fs: mounted filesystem with ordered data mode. NET: Registered protocol family 10 lo: Disabled Privacy Extensions eth0: no IPv6 routers present colinux: Linux VM terminated colinux: BUG at ...le-0.7.3-snapshot/linux-2.6.22.18-source/mm/page_alloc.c:310 console: Monitor2676: Detached C:\coLinux>debian.bat C:\coLinux>colinux-daemon -t nt @e:\colinux\debian.conf Cooperative Linux Daemon, 0.7.5 Daemon compiled on Mon Sep 14 22:26:21 2009 PID: 1408 error 0x2 in execution WARNING: error launching network daemon! colinux: booting console: Cooperative Linux console started Linux version 2.6.22.18-co-0.7.5 (hn@hn-dt) (gcc version 4.2.1 (SUSE Linux)) #1 PREEMPT Mon Sep 14 22:21:15 UTC 2009 800MB LOWMEM available. initrd enabled: start: 0xf1f9a000 size: 0x00065881 Entering add_active_range(0, 0, 204800) 0 entries of 256 used Zone PFN ranges: Normal 0 -> 204800 early_node_map[1] active PFN ranges 0: 0 -> 204800 On node 0 totalpages: 204800 Normal zone: 1600 pages used for memmap Normal zone: 0 pages reserved Normal zone: 203200 pages, LIFO batch:31 Built 1 zonelists. Total pages: 203200 Kernel command line: cdrom0=\Device\Cdrom0 root=/dev/cobd0 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 Setting proxy interrupt vectors PID hash table entries: 4096 (order: 12, 16384 bytes) Console: colour CoCON 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 807296k/819200k available (1956k kernel code, 0k reserved, 559k data, 13 6k init, 0k highmem) virtual kernel memory layout: fixmap : 0xffffc000 - 0xfffff000 ( 12 kB) vmalloc : 0xf2800000 - 0xffffa000 ( 215 MB) lowmem : 0xc0000000 - 0xf2000000 ( 800 MB) .init : 0xc0378000 - 0xc039a000 ( 136 kB) .data : 0xc02e9006 - 0xc0374fe4 ( 559 kB) .text : 0xc0100000 - 0xc02e9006 (1956 kB) Calibrating delay loop... 2660.76 BogoMIPS (lpj=13303808) Security Framework v1.0.0 initialized SELinux: Disabled at boot. Capability LSM initialized Mount-cache hash table entries: 512 CPU: After generic identify, caps: bfebfbff 00100000 00000000 00000000 0000451d 00000000 00000000 monitor/mwait feature present. using mwait in idle threads. CPU: Trace cache: 12K uops, L1 D cache: 16K CPU: L2 cache: 256K CPU: After all inits, caps: bfebfbff 00100000 00000000 0000b180 0000451d 0000000 0 00000000 Compat vDSO mapped to ffffe000. CPU: Intel Genuine Intel(R) CPU 3.06GHz stepping 01 Checking 'hlt' instruction... OK. NET: Registered protocol family 16 SCSI subsystem initialized PCI: Probing PCI hardware PCI: Probing PCI hardware (bus 00) NET: Registered protocol family 2 IP route cache hash table entries: 32768 (order: 5, 131072 bytes) TCP established hash table entries: 131072 (order: 8, 1048576 bytes) TCP bind hash table entries: 65536 (order: 6, 262144 bytes) TCP: Hash tables configured (established 131072 bind 65536) TCP reno registered checking if image is initramfs...it isn't (no cpio magic); looks like an initrd Freeing initrd memory: 406k freed audit: initializing netlink socket (disabled) audit(1261750554.460:1): initialized VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) cofuse init 0.1 (API version 2.2) io scheduler noop registered io scheduler anticipatory registered (default) io scheduler deadline registered io scheduler cfq registered RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize cobd: loaded (max 32 devices) loop: module loaded conet0: irq 10, HWAddr 00:ff:cc:a1:fc:00 serio: cokbd at irq 1 mice: PS/2 mouse device common for all mice input: Cooperative Mouse as /class/input/input0 comouse: initialized. TCP cubic registered NET: Registered protocol family 1 NET: Registered protocol family 17 Using IPI Shortcut mode input: AT Translated Set 2 keyboard as /class/input/input1 RAMDISK: Compressed image found at block 0 VFS: Mounted root (ext2 filesystem). ReiserFS: cobd0: warning: sh-2021: reiserfs_fill_super: can not find reiserfs on cobd0 EXT3-fs: INFO: recovery required on readonly filesystem. EXT3-fs: write access will be enabled during recovery. kjournald starting. Commit interval 5 seconds EXT3-fs: recovery complete. EXT3-fs: mounted filesystem with ordered data mode. EXT3 FS on cobd0, internal journal kjournald starting. Commit interval 5 seconds EXT3 FS on cobd0, internal journal EXT3-fs: mounted filesystem with ordered data mode. VFS: Mounted root (ext3 filesystem). Trying to move old root to /initrd ... /initrd does not exist. Ignored. Unmounting old root Trying to free ramdisk memory ... okay Freeing unused kernel memory: 136k freed Adding 131064k swap on /dev/cobd1. Priority:-1 extents:1 across:131064k EXT3 FS on cobd0, internal journal device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: dm-...@re... kjournald starting. Commit interval 5 seconds EXT3-fs warning: maximal mount count reached, running e2fsck is recommended EXT3 FS on loop0, internal journal EXT3-fs: recovery complete. EXT3-fs: mounted filesystem with ordered data mode. NET: Registered protocol family 10 lo: Disabled Privacy Extensions BUG: unable to handle kernel paging request at virtual address d4f68d58 printing eip: c01d413b *pde = 2206b063 *pte = 080e0000 Oops: 0000 [#1] PREEMPT Modules linked in: ipv6 dm_snapshot dm_mirror dm_mod CPU: 0 <0>EIP: 0060:[<c01d413b>] Not tainted VLI <0>EFLAGS: 00010282 (2.6.22.18-co-0.7.5 #1) EIP is at ext3_get_branch+0x9b/0xe0 eax: d4f68d58 ebx: d0d1bc88 ecx: d0d1bc88 edx: d0d1bcc0 esi: f130d13c edi: d0d1bc7c ebp: d0d1bc00 esp: d0d1bbe8 ds: 007b es: 007b fs: 0000 gs: 0033 ss: 0068 Process java (pid: 4442, ti=d0d1a000 task=f18a1030 task.ti=d0d1a000) <0>Stack: 00000001 f1de8a00 d0d1bcbc 00000000 00000010 d1fd7cf4 d0d1bce8 c01d437 d <0> d0d1bc7c d0d1bcd8 4d26b000 d0388f44 c15670e0 d0d1bc4c d0d1bc7c d0d1bc3 0 <0> d0d1bc50 00000362 d1fd7cf4 00000000 d0d1bc40 c0150465 00000002 c15670e 0 <0>Call Trace: [<c0103b7a>] show_trace_log_lvl+0x1a/0x30 [<c0103c3b>] show_stack_log_lvl+0xab/0xd0 [<c0104020>] show_registers+0x1e0/0x350 [<c010428c>] die+0xfc/0x210 [<c010b4d2>] do_page_fault+0x292/0x690 [<c02e82ea>] error_code+0x6a/0x70 [<c01d437d>] ext3_get_blocks_handle+0x8d/0xa40 [<c01d502c>] ext3_get_block+0x6c/0xe0 [<c0189447>] do_mpage_readpage+0x357/0x550 [<c018980a>] mpage_readpages+0x7a/0x150 [<c01d4259>] ext3_readpages+0x19/0x20 [<c0144b0a>] __do_page_cache_readahead+0x17a/0x290 [<c0144fc3>] do_page_cache_readahead+0x43/0x60 [<c0140970>] filemap_nopage+0x140/0x350 [<c014b352>] __handle_mm_fault+0x132/0xa00 [<c010b591>] do_page_fault+0x351/0x690 [<c02e82ea>] error_code+0x6a/0x70 ======================= Code: dc ee fa ff 85 c0 89 c6 74 3d 89 da 89 f8 e8 5d f4 ff ff 85 c0 74 3b 8b 55 f0 83 c3 0c 8b 42 04 83 c2 04 c1 e0 02 03 46 14 89 03 <8b> 00 89 73 08 89 43 04 89 55 f0 8b 43 04 85 c0 74 9b 83 6d e8 EIP: [<c01d413b>] ext3_get_branch+0x9b/0xe0 SS:ESP 0068:d0d1bbe8 BUG: unable to handle kernel paging request at virtual address d6c35008 printing eip: c015a726 *pde = 332a3063 Oops: 0002 [#2] PREEMPT Modules linked in: ipv6 dm_snapshot dm_mirror dm_mod CPU: 0 <0>EIP: 0060:[<c015a726>] Not tainted VLI <0>EFLAGS: 00010206 (2.6.22.18-co-0.7.5 #1) EIP is at cache_alloc_refill+0x3a6/0x550 eax: 000002c0 ebx: d6c35000 ecx: f1ff7dc0 edx: f1ff7dc0 esi: 00000000 edi: d6c35000 ebp: c17cbd88 esp: c17cbd3c ds: 007b es: 007b fs: 0000 gs: 0000 ss: 0068 Process pdflush (pid: 39, ti=c17ca000 task=c175b5b0 task.ti=c17ca000) <0>Stack: 00000000 c17ca000 c17553c8 c17553d0 00000050 f1ff7dc0 00000000 c17553c 0 <0> f1ff8000 c17553c0 00000000 00000010 00000050 f1cae718 00000046 0000000 3 <0> 00000286 f1ff7dc0 00000050 c17cbd9c c015a376 fffffff4 f1cae6c0 d02b828 c <0>Call Trace: [<c0103b7a>] show_trace_log_lvl+0x1a/0x30 [<c0103c3b>] show_stack_log_lvl+0xab/0xd0 [<c0104020>] show_registers+0x1e0/0x350 [<c010428c>] die+0xfc/0x210 [<c010b4d2>] do_page_fault+0x292/0x690 [<c02e82ea>] error_code+0x6a/0x70 [<c015a376>] kmem_cache_alloc+0x56/0x60 [<c01e4f5b>] journal_start+0x9b/0x100 [<c01dc168>] ext3_journal_start_sb+0x48/0x50 [<c01d6694>] ext3_ordered_writepage+0xa4/0x1d0 [<c01436db>] __writepage+0xb/0x30 [<c0143c2a>] write_cache_pages+0x1fa/0x2f0 [<c0143d43>] generic_writepages+0x23/0x30 [<c0143d99>] do_writepages+0x49/0x50 [<c017d00d>] __writeback_single_inode+0x9d/0x3e0 [<c017d723>] sync_sb_inodes+0x1c3/0x2b0 [<c017dc45>] writeback_inodes+0xb5/0x110 [<c0144206>] background_writeout+0x76/0x90 [<c0144757>] pdflush+0xe7/0x1e0 [<c0124202>] kthread+0x42/0x70 [<c0103997>] kernel_thread_helper+0x7/0x10 ======================= Code: 89 c7 81 ef 00 00 00 40 0f 84 69 01 00 00 8b 4d c8 0f af 75 dc 8b 41 18 85 c0 0f 88 b4 00 00 00 8b 55 c8 89 f0 8d 1c 37 03 42 34 <89> 43 08 8d 97 00 00 00 40 be 01 00 00 00 8d 04 07 c7 43 10 00 EIP: [<c015a726>] cache_alloc_refill+0x3a6/0x550 SS:ESP 0068:c17cbd3c BUG: unable to handle kernel paging request at virtual address d4f6a000 printing eip: c0142df9 *pde = 2206b063 *pte = 08bdbab0 Oops: 0002 [#3] PREEMPT Modules linked in: ipv6 dm_snapshot dm_mirror dm_mod CPU: 0 <0>EIP: 0060:[<c0142df9>] Not tainted VLI <0>EFLAGS: 00010287 (2.6.22.18-co-0.7.5 #1) EIP is at get_page_from_freelist+0x299/0x420 eax: 00000000 ebx: c129ed40 ecx: 00000400 edx: c9280000 esi: c129ed40 edi: d4f6a000 ebp: c9281ec0 esp: c9281e78 ds: 007b es: 007b fs: 0000 gs: 0033 ss: 0068 Process cc1plus (pid: 5861, ti=c9280000 task=c170ba30 task.ti=c9280000) <0>Stack: 00000000 00000044 00000000 00000000 c9280000 c0361ba0 00000000 0000000 0 <0> 000280d2 c0361ce0 00000246 00000001 0050cc00 00000000 00000000 d89b394 0 <0> c170ba30 000280d2 c9281f08 c0142fda 00000044 c1641430 c9281ee8 c015349 4 <0>Call Trace: [<c0103b7a>] show_trace_log_lvl+0x1a/0x30 [<c0103c3b>] show_stack_log_lvl+0xab/0xd0 [<c0104020>] show_registers+0x1e0/0x350 [<c010428c>] die+0xfc/0x210 [<c010b4d2>] do_page_fault+0x292/0x690 [<c02e82ea>] error_code+0x6a/0x70 [<c0142fda>] __alloc_pages+0x5a/0x330 [<c014b70e>] __handle_mm_fault+0x4ee/0xa00 [<c010b591>] do_page_fault+0x351/0x690 [<c02e82ea>] error_code+0x6a/0x70 ======================= Code: 00 00 00 89 4d c8 b8 01 00 00 00 e8 02 9c fc ff 89 df 31 c0 2b 3d 38 5e 3c c0 b9 00 04 00 00 c1 ff 05 c1 e7 0c 81 ef 00 00 00 40 <f3> ab b0 01 e8 2e 9b fc ff 8b 55 c8 8b 42 08 a8 08 0f 85 26 01 EIP: [<c0142df9>] get_page_from_freelist+0x299/0x420 SS:ESP 0068:c9281e78 note: cc1plus[5861] exited with preempt_count 1 BUG: scheduling while atomic: cc1plus/0x10000001/5861 [<c0103b7a>] show_trace_log_lvl+0x1a/0x30 [<c0103cb2>] show_trace+0x12/0x20 [<c0104b15>] dump_stack+0x15/0x20 [<c02e62d1>] schedule+0x4d1/0x670 [<c010caab>] __cond_resched+0x1b/0x30 [<c02e65ca>] cond_resched+0x2a/0x40 [<c014a227>] unmap_vmas+0x4b7/0x4f0 [<c014d5d8>] exit_mmap+0x68/0x110 [<c010eb75>] mmput+0x35/0xb0 [<c01127f1>] exit_mm+0x81/0x100 [<c0113f81>] do_exit+0x111/0x950 [<c010439d>] die+0x20d/0x210 [<c010b4d2>] do_page_fault+0x292/0x690 [<c02e82ea>] error_code+0x6a/0x70 [<c0142fda>] __alloc_pages+0x5a/0x330 [<c014b70e>] __handle_mm_fault+0x4ee/0xa00 [<c010b591>] do_page_fault+0x351/0x690 [<c02e82ea>] error_code+0x6a/0x70 ======================= BUG: scheduling while atomic: cc1plus/0x10000001/5861 [<c0103b7a>] show_trace_log_lvl+0x1a/0x30 [<c0103cb2>] show_trace+0x12/0x20 [<c0104b15>] dump_stack+0x15/0x20 [<c02e62d1>] schedule+0x4d1/0x670 [<c010caab>] __cond_resched+0x1b/0x30 [<c02e65ca>] cond_resched+0x2a/0x40 [<c014a227>] unmap_vmas+0x4b7/0x4f0 [<c014d5d8>] exit_mmap+0x68/0x110 [<c010eb75>] mmput+0x35/0xb0 [<c01127f1>] exit_mm+0x81/0x100 [<c0113f81>] do_exit+0x111/0x950 [<c010439d>] die+0x20d/0x210 [<c010b4d2>] do_page_fault+0x292/0x690 [<c02e82ea>] error_code+0x6a/0x70 [<c0142fda>] __alloc_pages+0x5a/0x330 [<c014b70e>] __handle_mm_fault+0x4ee/0xa00 [<c010b591>] do_page_fault+0x351/0x690 [<c02e82ea>] error_code+0x6a/0x70 ======================= BUG: scheduling while atomic: cc1plus/0x10000001/5861 [<c0103b7a>] show_trace_log_lvl+0x1a/0x30 [<c0103cb2>] show_trace+0x12/0x20 [<c0104b15>] dump_stack+0x15/0x20 [<c02e62d1>] schedule+0x4d1/0x670 [<c010caab>] __cond_resched+0x1b/0x30 [<c02e65ca>] cond_resched+0x2a/0x40 [<c014a227>] unmap_vmas+0x4b7/0x4f0 [<c014d5d8>] exit_mmap+0x68/0x110 [<c010eb75>] mmput+0x35/0xb0 [<c01127f1>] exit_mm+0x81/0x100 [<c0113f81>] do_exit+0x111/0x950 [<c010439d>] die+0x20d/0x210 [<c010b4d2>] do_page_fault+0x292/0x690 [<c02e82ea>] error_code+0x6a/0x70 [<c0142fda>] __alloc_pages+0x5a/0x330 [<c014b70e>] __handle_mm_fault+0x4ee/0xa00 [<c010b591>] do_page_fault+0x351/0x690 [<c02e82ea>] error_code+0x6a/0x70 ======================= BUG: scheduling while atomic: cc1plus/0x10000001/5861 [<c0103b7a>] show_trace_log_lvl+0x1a/0x30 [<c0103cb2>] show_trace+0x12/0x20 [<c0104b15>] dump_stack+0x15/0x20 [<c02e62d1>] schedule+0x4d1/0x670 [<c010caab>] __cond_resched+0x1b/0x30 [<c02e65ca>] cond_resched+0x2a/0x40 [<c014a227>] unmap_vmas+0x4b7/0x4f0 [<c014d5d8>] exit_mmap+0x68/0x110 [<c010eb75>] mmput+0x35/0xb0 [<c01127f1>] exit_mm+0x81/0x100 [<c0113f81>] do_exit+0x111/0x950 [<c010439d>] die+0x20d/0x210 [<c010b4d2>] do_page_fault+0x292/0x690 [<c02e82ea>] error_code+0x6a/0x70 [<c0142fda>] __alloc_pages+0x5a/0x330 [<c014b70e>] __handle_mm_fault+0x4ee/0xa00 [<c010b591>] do_page_fault+0x351/0x690 [<c02e82ea>] error_code+0x6a/0x70 ======================= BUG: scheduling while atomic: cc1plus/0x10000001/5861 [<c0103b7a>] show_trace_log_lvl+0x1a/0x30 [<c0103cb2>] show_trace+0x12/0x20 [<c0104b15>] dump_stack+0x15/0x20 [<c02e62d1>] schedule+0x4d1/0x670 [<c010caab>] __cond_resched+0x1b/0x30 [<c02e65ca>] cond_resched+0x2a/0x40 [<c014a227>] unmap_vmas+0x4b7/0x4f0 [<c014d5d8>] exit_mmap+0x68/0x110 [<c010eb75>] mmput+0x35/0xb0 [<c01127f1>] exit_mm+0x81/0x100 [<c0113f81>] do_exit+0x111/0x950 [<c010439d>] die+0x20d/0x210 [<c010b4d2>] do_page_fault+0x292/0x690 [<c02e82ea>] error_code+0x6a/0x70 [<c0142fda>] __alloc_pages+0x5a/0x330 [<c014b70e>] __handle_mm_fault+0x4ee/0xa00 [<c010b591>] do_page_fault+0x351/0x690 [<c02e82ea>] error_code+0x6a/0x70 ======================= BUG: unable to handle kernel paging request at virtual address d4f68f38 printing eip: c01d413b *pde = 2206b063 *pte = 080e0000 Oops: 0000 [#4] PREEMPT Modules linked in: ipv6 dm_snapshot dm_mirror dm_mod CPU: 0 <0>EIP: 0060:[<c01d413b>] Not tainted VLI <0>EFLAGS: 00010282 (2.6.22.18-co-0.7.5 #1) EIP is at ext3_get_branch+0x9b/0xe0 eax: d4f68f38 ebx: d1c5bc88 ecx: d1c5bc88 edx: d1c5bcc0 esi: f130d13c edi: d1c5bc7c ebp: d1c5bc00 esp: d1c5bbe8 ds: 007b es: 007b fs: 0000 gs: 0033 ss: 0068 Process java (pid: 4385, ti=d1c5a000 task=f1df30b0 task.ti=d1c5a000) <0>Stack: 00000001 f1de8a00 d1c5bcbc 00000000 0000001e d1fd7cf4 d1c5bce8 c01d437 d <0> d1c5bc7c d1c5bcd8 d1c5bc24 c0220377 f1dcfb80 e9baaa14 d1c5bc7c d1c5bc3 8 <0> c02287a3 000003da d1fd7cf4 00000000 d1c5bc4c c0229227 00000002 f1c323b 8 <0>Call Trace: [<c0103b7a>] show_trace_log_lvl+0x1a/0x30 [<c0103c3b>] show_stack_log_lvl+0xab/0xd0 [<c0104020>] show_registers+0x1e0/0x350 [<c010428c>] die+0xfc/0x210 [<c010b4d2>] do_page_fault+0x292/0x690 [<c02e82ea>] error_code+0x6a/0x70 [<c01d437d>] ext3_get_blocks_handle+0x8d/0xa40 [<c01d502c>] ext3_get_block+0x6c/0xe0 [<c0189447>] do_mpage_readpage+0x357/0x550 [<c018980a>] mpage_readpages+0x7a/0x150 [<c01d4259>] ext3_readpages+0x19/0x20 [<c0144b0a>] __do_page_cache_readahead+0x17a/0x290 [<c0144fc3>] do_page_cache_readahead+0x43/0x60 [<c0140970>] filemap_nopage+0x140/0x350 [<c014b352>] __handle_mm_fault+0x132/0xa00 [<c010b591>] do_page_fault+0x351/0x690 [<c02e82ea>] error_code+0x6a/0x70 ======================= Code: dc ee fa ff 85 c0 89 c6 74 3d 89 da 89 f8 e8 5d f4 ff ff 85 c0 74 3b 8b 55 f0 83 c3 0c 8b 42 04 83 c2 04 c1 e0 02 03 46 14 89 03 <8b> 00 89 73 08 89 43 04 89 55 f0 8b 43 04 85 c0 74 9b 83 6d e8 EIP: [<c01d413b>] ext3_get_branch+0x9b/0xe0 SS:ESP 0068:d1c5bbe8 BUG: scheduling while atomic: cc1plus/0x10000001/5861 [<c0103b7a>] show_trace_log_lvl+0x1a/0x30 [<c0103cb2>] show_trace+0x12/0x20 [<c0104b15>] dump_stack+0x15/0x20 [<c02e62d1>] schedule+0x4d1/0x670 [<c010caab>] __cond_resched+0x1b/0x30 [<c02e65ca>] cond_resched+0x2a/0x40 [<c014a227>] unmap_vmas+0x4b7/0x4f0 [<c014d5d8>] exit_mmap+0x68/0x110 [<c010eb75>] mmput+0x35/0xb0 [<c01127f1>] exit_mm+0x81/0x100 [<c0113f81>] do_exit+0x111/0x950 [<c010439d>] die+0x20d/0x210 [<c010b4d2>] do_page_fault+0x292/0x690 [<c02e82ea>] error_code+0x6a/0x70 [<c0142fda>] __alloc_pages+0x5a/0x330 [<c014b70e>] __handle_mm_fault+0x4ee/0xa00 [<c010b591>] do_page_fault+0x351/0x690 [<c02e82ea>] error_code+0x6a/0x70 ======================= BUG: scheduling while atomic: cc1plus/0x10000001/5861 [<c0103b7a>] show_trace_log_lvl+0x1a/0x30 [<c0103cb2>] show_trace+0x12/0x20 [<c0104b15>] dump_stack+0x15/0x20 [<c02e62d1>] schedule+0x4d1/0x670 [<c010caab>] __cond_resched+0x1b/0x30 [<c02e65ca>] cond_resched+0x2a/0x40 [<c014a227>] unmap_vmas+0x4b7/0x4f0 [<c014d5d8>] exit_mmap+0x68/0x110 [<c010eb75>] mmput+0x35/0xb0 [<c01127f1>] exit_mm+0x81/0x100 [<c0113f81>] do_exit+0x111/0x950 [<c010439d>] die+0x20d/0x210 [<c010b4d2>] do_page_fault+0x292/0x690 [<c02e82ea>] error_code+0x6a/0x70 [<c0142fda>] __alloc_pages+0x5a/0x330 [<c014b70e>] __handle_mm_fault+0x4ee/0xa00 [<c010b591>] do_page_fault+0x351/0x690 [<c02e82ea>] error_code+0x6a/0x70 ======================= BUG: scheduling while atomic: cc1plus/0x10000001/5861 [<c0103b7a>] show_trace_log_lvl+0x1a/0x30 [<c0103cb2>] show_trace+0x12/0x20 [<c0104b15>] dump_stack+0x15/0x20 [<c02e62d1>] schedule+0x4d1/0x670 [<c010caab>] __cond_resched+0x1b/0x30 [<c02e65ca>] cond_resched+0x2a/0x40 [<c014a227>] unmap_vmas+0x4b7/0x4f0 [<c014d5d8>] exit_mmap+0x68/0x110 [<c010eb75>] mmput+0x35/0xb0 [<c01127f1>] exit_mm+0x81/0x100 [<c0113f81>] do_exit+0x111/0x950 [<c010439d>] die+0x20d/0x210 [<c010b4d2>] do_page_fault+0x292/0x690 [<c02e82ea>] error_code+0x6a/0x70 [<c0142fda>] __alloc_pages+0x5a/0x330 [<c014b70e>] __handle_mm_fault+0x4ee/0xa00 [<c010b591>] do_page_fault+0x351/0x690 [<c02e82ea>] error_code+0x6a/0x70 ======================= Eeek! page_mapcount(page) went negative! (-1) colinux: Linux VM terminated colinux: BUG at /home/hn/colinux/build/stable-gcc412.svn/linux-2.6.22.18-source/ mm/rmap.c:628 console: Monitor1408: Detached C:\coLinux> ---------------------------------------------------------------------- >Comment By: Henry N. (henryn) Date: 2010-03-13 21:45 Message: Close this now, because "out of memory" can't needs to change in config. ---------------------------------------------------------------------- Comment By: Henry N. (henryn) Date: 2010-01-16 20:33 Message: This is not a real bug. Unless the output is not very nice. The right message would be "Out of host memory". You have started coLinux with enough free memory on host and some times later the host says "have no more memory for this application". This can be, if you started some more applications after coLinux is running. Please close some of your other programs on host, Internet browsers and some other memory hungry applications. Please try to reduce the total memory usage for coLinux. Set the parameter "mem=..." to a half of your total memory of host, and add a swap file with same size. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-12-25 15:27 Message: I reinstalled coLInux from 0.7.3 to 0.7.5, both crashed ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2921083&group_id=98788 |
From: Henry N. <hen...@ar...> - 2010-03-13 20:33:49
|
Hello all, after backport the Ubuntu kernel source to coLinux, it's working now. Thanks to Sergio for searching sources and testing. The problem was, that Ubuntu gutsy 7.10 used Unionfs 1.3 user land programs, and this is not compatible to kernel Unionfs 2.x A pre-build kernel modul and sources for coLinux 0.7.6 with kernel 2.6.22.18 exist here: http://www.henrynestler.com/colinux/testing/unionfs-1.4/ -- Henry N. |
From: coLinux a. <col...@he...> - 2010-03-13 05:06:58
|
The autobuild system has detected a new revision in the source repository. Review last changed from changelog.txt, also attached in mail. Download the compiled version: http://www.henrynestler.com/colinux/autobuild/devel-20100312/ colinux-0.8.0-20100312.src.tgz (1058811 Bytes) daemons-0.8.0-20100312.dbg.zip (591838 Bytes) daemons-0.8.0-20100312.zip (478340 Bytes) Note, the autobuild compilation does not include an installer. Remember to reload the driver with these commands: colinux-daemon.exe --remove-driver colinux-daemon.exe --install-driver The vmlinux and modules are up to date. Please use last version from http://www.henrynestler.com/colinux/autobuild/devel-20100306/ The autobuild compilations are not official releases of Cooperative Linux software. There is no warranty that any autobuild version is stable. If use this autobuild version, please give us feedback of your experience. Job runs on machine with 64 bit version of gcc 4.3.2. A service from http://gcc.gnu.org/wiki/CompileFarm -- Lots of fun with newest version, Henry Nestler ------------------------------------------------------------------------ r1387 | henryn | 2010-03-12 22:40:33 +0000 (Fri, 12 Mar 2010) | 1 line Changed paths: M /branches/cofb/TODO M /branches/devel/TODO * TODO: Remove odd top line from xxfiff, move OS parts down. ------------------------------------------------------------------------ r1386 | henryn | 2010-03-12 21:07:19 +0000 (Fri, 12 Mar 2010) | 1 line Changed paths: M /branches/cofb/TODO M /branches/devel/TODO * Merge TODO lists cofb and devel. ------------------------------------------------------------------------ |