Menu
▾
▴
colinux-devel — Cooperative Linux development mailing list
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...> - 2009-04-29 06:57:19
|
Bugs item #2760666, was opened at 2009-04-14 04:50 Message generated for change (Comment added) made by juergen_01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2760666&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: Crash / BSOD Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: VirtualBOX causes BSOD Initial Comment: Running Parallels or VMWare to virtualise a virtual machine doesnt result in crashing. Trying to boot Windows XP on VirtualBOX at the same time as running COLinux causes it to BSOD the host system (Windows Vista) Its strange but why does VBox BSOD the system whereas Parallels/VMWare can virtualise fine alongside COLinux.. Reproduction: Install VirtualBox Install COLinux V8 Run COLinux Create a new Windows VM In Virtualbox Attempt to Boot the new VM Into Windows setup. BSOD ---------------------------------------------------------------------- Comment By: Juergen (juergen_01) Date: 2009-04-29 08:57 Message: Some time ago, a had the same problem with randomly getting a kernel stack overflow. The problem was caused by too many enabled network services on a network interface. I had installed VirtualBox, MS Virtual PC, Norton Internet Security, Cisco VPN Client and MS Network Monitor. All these programs installed a network service. After I disabled 2 or 3 of the network services I was not using at that time, I solved the problem with the kernel stack overflow. You have to disable the services it on every network interface. Well, a BSOD can also be caused by the virtualization features of the CPU. If I am running a VM in VBox with Intel-VT enabled and then starting only the Virtual PC application, my computer is crashing with a BSOD. On an older CPU with no Intel-VT I never had this problem. On this older CPU, I never had any problems with running VBox VMs and colinux instances concurrently. If you do not get a crash dump, this might be caused by the Data-Execution-Prevention in Windows. If this is also enabled for normal applications and not only for windows services, then you will never get a crash dump. Windows is still writing crash dump information to pagefile.sys but it does not generate a crash dump file on next startup. I had the same problem while getting the kernel stack overflow. After disabling DEP for every application Windows created crash dump files again. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-04-29 03:21 Message: Double fault A double fault occurs when an exception occurs while trying to call the handler for a prior exception. Normally, the two exceptions can be handled serially, however there are several exceptions that cannot be handled serially and in this situation the processor signals a double fault. The two primary causes for this are hardware and kernel stack overflows. Hardware problems are usually related to CPU, RAM, or bus. Kernel stack overflows are almost always caused by faulty kernel-mode drivers. I can rule out my CPU/RAM since they are relatively new components.. VMWare/Parallels work alongside COLinux just not VirtualBox. I've stress tested this thing for over 72 hours about 2 weeks back since I installed a new CPU cooler.. So I'm guessing its the Kernel Stack Overflow? Any chance you can attempt to reproduce? My Vista is being a pain, its set to do a full mem dump on BSOD but that crash doesnt generate one. ---------------------------------------------------------------------- Comment By: Henry N. (henryn) Date: 2009-04-28 23:49 Message: > STOP: 0x0000007F (0x00000008, 0x801B1000, 0x00000000, 0x00000000) STOP 0x0000007F : UNEXPECTED_KERNEL_MODE_TRAP (sse [1]) 0x00000008 : Double Fault 0x801B1000 : I found no references for that value. [1] http://support.microsoft.com/kb/137539 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-04-28 18:04 Message: The system doesnt generate a Minidump from this crash even though configured to. Error is as follows: STOP: 0x0000007F (0x00000008, 0x801B1000, 0x00000000, 0x00000000) With no further details ---------------------------------------------------------------------- Comment By: Henry N. (henryn) Date: 2009-04-14 19:57 Message: It would be nice to get an analyze from minidump of that BSOD, so we can see, what caused this crash. Please read "Howto use Windows crash dump" in your colinux file "debugging.txt" or here from source: http://colinux.svn.sourceforge.net/viewvc/colinux/branches/devel/doc/debugging Henry ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2760666&group_id=98788 |
|
From: SourceForge.net <no...@so...> - 2009-04-29 03:58:35
|
Support Requests item #2783377, was opened at 2009-04-29 03:58 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622064&aid=2783377&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: v1.0 (example) Status: Open Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Grom Initial Comment: Very good resourse : [url=http://vivat.isuisse.com/www.jackbutterfield.com.html]www.jackbutterfield.com[/url] [url=http://bolika.isuisse.com/imbackoffice.com.html]imbackoffice.com[/url] <a href=http://lione.ibelgique.com/dixieechoes.com.html>dixieechoes.com</a> http://teyri.isuisse.com/www.mypartywishes.com.html Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622064&aid=2783377&group_id=98788 |
|
From: SourceForge.net <no...@so...> - 2009-04-29 03:53:59
|
Feature Requests item #2783376, was opened at 2009-04-29 03:53 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622066&aid=2783376&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: Open Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Grom Initial Comment: Very good resourse : [url=http://damgo.isuisse.com/wibw.com.html]wibw.com[/url] <a href=http://kiozy.isuisse.com/mrdavers.com.html>mrdavers.com</a> <a href=http://makire.isuisse.com/www.mda.state.mn.us.nh3.htm.html>www.mda.state.mn.us.nh3.htm</a> http://diolia.isuisse.com/blackwhitepleasures.com.html http://lirofen.iquebec.com/januarysacademyofdance.com.html Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622066&aid=2783376&group_id=98788 |
|
From: SourceForge.net <no...@so...> - 2009-04-29 01:21:17
|
Bugs item #2760666, was opened at 2009-04-14 02:50 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2760666&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: Crash / BSOD Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: VirtualBOX causes BSOD Initial Comment: Running Parallels or VMWare to virtualise a virtual machine doesnt result in crashing. Trying to boot Windows XP on VirtualBOX at the same time as running COLinux causes it to BSOD the host system (Windows Vista) Its strange but why does VBox BSOD the system whereas Parallels/VMWare can virtualise fine alongside COLinux.. Reproduction: Install VirtualBox Install COLinux V8 Run COLinux Create a new Windows VM In Virtualbox Attempt to Boot the new VM Into Windows setup. BSOD ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-04-29 01:21 Message: Double fault A double fault occurs when an exception occurs while trying to call the handler for a prior exception. Normally, the two exceptions can be handled serially, however there are several exceptions that cannot be handled serially and in this situation the processor signals a double fault. The two primary causes for this are hardware and kernel stack overflows. Hardware problems are usually related to CPU, RAM, or bus. Kernel stack overflows are almost always caused by faulty kernel-mode drivers. I can rule out my CPU/RAM since they are relatively new components.. VMWare/Parallels work alongside COLinux just not VirtualBox. I've stress tested this thing for over 72 hours about 2 weeks back since I installed a new CPU cooler.. So I'm guessing its the Kernel Stack Overflow? Any chance you can attempt to reproduce? My Vista is being a pain, its set to do a full mem dump on BSOD but that crash doesnt generate one. ---------------------------------------------------------------------- Comment By: Henry N. (henryn) Date: 2009-04-28 21:49 Message: > STOP: 0x0000007F (0x00000008, 0x801B1000, 0x00000000, 0x00000000) STOP 0x0000007F : UNEXPECTED_KERNEL_MODE_TRAP (sse [1]) 0x00000008 : Double Fault 0x801B1000 : I found no references for that value. [1] http://support.microsoft.com/kb/137539 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-04-28 16:04 Message: The system doesnt generate a Minidump from this crash even though configured to. Error is as follows: STOP: 0x0000007F (0x00000008, 0x801B1000, 0x00000000, 0x00000000) With no further details ---------------------------------------------------------------------- Comment By: Henry N. (henryn) Date: 2009-04-14 17:57 Message: It would be nice to get an analyze from minidump of that BSOD, so we can see, what caused this crash. Please read "Howto use Windows crash dump" in your colinux file "debugging.txt" or here from source: http://colinux.svn.sourceforge.net/viewvc/colinux/branches/devel/doc/debugging Henry ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2760666&group_id=98788 |
|
From: SourceForge.net <no...@so...> - 2009-04-28 21:49:39
|
Bugs item #2760666, was opened at 2009-04-14 04:50 Message generated for change (Comment added) made by henryn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2760666&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: Crash / BSOD Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: VirtualBOX causes BSOD Initial Comment: Running Parallels or VMWare to virtualise a virtual machine doesnt result in crashing. Trying to boot Windows XP on VirtualBOX at the same time as running COLinux causes it to BSOD the host system (Windows Vista) Its strange but why does VBox BSOD the system whereas Parallels/VMWare can virtualise fine alongside COLinux.. Reproduction: Install VirtualBox Install COLinux V8 Run COLinux Create a new Windows VM In Virtualbox Attempt to Boot the new VM Into Windows setup. BSOD ---------------------------------------------------------------------- >Comment By: Henry N. (henryn) Date: 2009-04-28 23:49 Message: > STOP: 0x0000007F (0x00000008, 0x801B1000, 0x00000000, 0x00000000) STOP 0x0000007F : UNEXPECTED_KERNEL_MODE_TRAP (sse [1]) 0x00000008 : Double Fault 0x801B1000 : I found no references for that value. [1] http://support.microsoft.com/kb/137539 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-04-28 18:04 Message: The system doesnt generate a Minidump from this crash even though configured to. Error is as follows: STOP: 0x0000007F (0x00000008, 0x801B1000, 0x00000000, 0x00000000) With no further details ---------------------------------------------------------------------- Comment By: Henry N. (henryn) Date: 2009-04-14 19:57 Message: It would be nice to get an analyze from minidump of that BSOD, so we can see, what caused this crash. Please read "Howto use Windows crash dump" in your colinux file "debugging.txt" or here from source: http://colinux.svn.sourceforge.net/viewvc/colinux/branches/devel/doc/debugging Henry ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2760666&group_id=98788 |
|
From: SourceForge.net <no...@so...> - 2009-04-28 16:04:04
|
Bugs item #2760666, was opened at 2009-04-14 02:50 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2760666&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: Crash / BSOD Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: VirtualBOX causes BSOD Initial Comment: Running Parallels or VMWare to virtualise a virtual machine doesnt result in crashing. Trying to boot Windows XP on VirtualBOX at the same time as running COLinux causes it to BSOD the host system (Windows Vista) Its strange but why does VBox BSOD the system whereas Parallels/VMWare can virtualise fine alongside COLinux.. Reproduction: Install VirtualBox Install COLinux V8 Run COLinux Create a new Windows VM In Virtualbox Attempt to Boot the new VM Into Windows setup. BSOD ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-04-28 16:04 Message: The system doesnt generate a Minidump from this crash even though configured to. Error is as follows: STOP: 0x0000007F (0x00000008, 0x801B1000, 0x00000000, 0x00000000) With no further details ---------------------------------------------------------------------- Comment By: Henry N. (henryn) Date: 2009-04-14 17:57 Message: It would be nice to get an analyze from minidump of that BSOD, so we can see, what caused this crash. Please read "Howto use Windows crash dump" in your colinux file "debugging.txt" or here from source: http://colinux.svn.sourceforge.net/viewvc/colinux/branches/devel/doc/debugging Henry ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2760666&group_id=98788 |
|
From: Alexey E. <al...@gm...> - 2009-04-26 23:00:06
|
BTW: Henry asked if VMX is MMX. Answer: Well, no - MMX is MultiMedia Extensions, while VMX is Virtual Machine Extensions. Both developed by Intel. MMX in 1996 and VMX in 2005. VMX is also know as VT-x or Vanderpool Technology. VMX has very serious implications on the functionality of CPUs and OSes, protection levels, and everything. Basically it adds an extra memory protection ring. It allows for hardware-assisted virtualization of x86 instructions. To make use of VMX, a driver needs to be written. VirtualBox's virtualization driver, aka "vboxdrv", can _optionally_ use VMX. Alone it works fine, but for some strange reason it dislikes cooperating with coLinux. :( -- -Alexey Eromenko "Technologov", 27.4.2009. |
|
From: Alexey E. <al...@gm...> - 2009-04-26 22:49:26
|
The Good news: I have added /var/log/messages from coLinux -0.7.4-rc2 before crash. http://www.virtualbox.org/ticket/3724 The Bad news: Crash is so hard that no core dumps get generated. Mini dumps generation is set, but there are no mini-dumps from year 2009 exists in "\WINDOWS\Minidump". ..and The ugly: I have no idea what to do next. -- -Alexey Eromenko "Technologov", 27.4.2009. |
|
From: Alexey E. <al...@gm...> - 2009-04-26 22:26:45
|
Allright ! I'm back ! I am still using the same distro - i.e. Portable Ubuntu but now manually upgraded coLinux kernel according to Henry's instructions. Here is it: pubuntu@pubuntu:~$ uname -a Linux pubuntu 2.6.22.18-co-0.7.4 #1 PREEMPT Wed Apr 15 18:57:39 UTC 2009 i686 GNU/Linux BTW: It is supposed to be 0.7.4-rc2 I think... -- -Alexey Eromenko "Technologov" |
|
From: Benjamin H. <bh...@ud...> - 2009-04-26 09:42:57
|
Hi, I want to have a small distrib with a colinux kernel and a openwrt rootfs. What kind of requirements do I need on the rootfs side to support colinux? Any special module? Does the rootfs has to be in a special format, or ext2 is enough? Best, -- Benjamin Henrion <bhenrion at ffii.org> FFII Brussels - +32-484-566109 - +32-2-4148403 |
|
From: Benjamin H. <bh...@ud...> - 2009-04-26 09:41:14
|
Hi, I was just trying to compile the latest snapshot of colinux 20090415, binutils seems to fail: ================================================================ gcc -DHAVE_CONFIG_H -I. -I../../binutils-2.17.50-20070129-1/binutils -I. -D_GNU_SOURCE -I. -I../../binutils-2.17.50-20070129-1/binutils -I../bfd -I../../binutils-2.17.50-20070129-1/binutils/../bfd -I../../binutils-2.17.50-20070129-1/binutils/../include -DLOCALEDIR="\"/home/zoobab/soft/colinux/mingw32/share/locale\"" -Dbin_dummy_emulation=bin_vanilla_emulation -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -O2 -c ../../binutils-2.17.50-20070129-1/binutils/not-strip.c gcc -DHAVE_CONFIG_H -I. -I../../binutils-2.17.50-20070129-1/binutils -I. -D_GNU_SOURCE -I. -I../../binutils-2.17.50-20070129-1/binutils -I../bfd -I../../binutils-2.17.50-20070129-1/binutils/../bfd -I../../binutils-2.17.50-20070129-1/binutils/../include -DLOCALEDIR="\"/home/zoobab/soft/colinux/mingw32/share/locale\"" -Dbin_dummy_emulation=bin_vanilla_emulation -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -O2 -c ../../binutils-2.17.50-20070129-1/binutils/wrstabs.c /bin/sh ./libtool --mode=link gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -O2 -s -o objcopy objcopy.o not-strip.o rename.o rddbg.o debug.o stabs.o ieee.o rdcoff.o wrstabs.o bucomm.o version.o filemode.o ../bfd/libbfd.la ../libiberty/libiberty.a gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -O2 -s -o objcopy objcopy.o not-strip.o rename.o rddbg.o debug.o stabs.o ieee.o rdcoff.o wrstabs.o bucomm.o version.o filemode.o ../bfd/.libs/libbfd.a ../libiberty/libiberty.a gcc -DHAVE_CONFIG_H -I. -I../../binutils-2.17.50-20070129-1/binutils -I. -D_GNU_SOURCE -I. -I../../binutils-2.17.50-20070129-1/binutils -I../bfd -I../../binutils-2.17.50-20070129-1/binutils/../bfd -I../../binutils-2.17.50-20070129-1/binutils/../include -DLOCALEDIR="\"/home/zoobab/soft/colinux/mingw32/share/locale\"" -Dbin_dummy_emulation=bin_vanilla_emulation -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -O2 -c -DDLLTOOL_I386 ../../binutils-2.17.50-20070129-1/binutils/dlltool.c make[5]: Leaving directory `/home/zoobab/soft/colinux/build/binutils-i686-pc-mingw32/binutils' make[4]: Leaving directory `/home/zoobab/soft/colinux/build/binutils-i686-pc-mingw32/binutils' make[3]: Leaving directory `/home/zoobab/soft/colinux/build/binutils-i686-pc-mingw32/binutils' make[2]: Leaving directory `/home/zoobab/soft/colinux/build/binutils-i686-pc-mingw32' make[1]: Leaving directory `/home/zoobab/soft/colinux/build/binutils-i686-pc-mingw32' -e --- ERROR LOG /home/zoobab/soft/colinux/log/build-colinux-19821.err: ../../binutils-2.17.50-20070129-1/libiberty/pex-unix.c:346: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result ../../binutils-2.17.50-20070129-1/libiberty/pex-unix.c:347: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result ../../binutils-2.17.50-20070129-1/libiberty/pex-unix.c:348: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result ../../binutils-2.17.50-20070129-1/libiberty/pex-unix.c:349: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result ../../binutils-2.17.50-20070129-1/libiberty/pex-unix.c:350: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result ../../binutils-2.17.50-20070129-1/libiberty/ternary.c:144: warning: ‘ternary_recursivesearch’ defined but not used ../../../binutils-2.17.50-20070129-1/bfd/doc/chew.c: In function ‘write_buffer’: ../../../binutils-2.17.50-20070129-1/bfd/doc/chew.c:169: warning: ignoring return value of ‘fwrite’, declared with attribute warn_unused_result arlex.c:1397: warning: ‘yyunput’ defined but not used arlex.c:1440: warning: ‘input’ defined but not used cc1: warnings being treated as errors ../../binutils-2.17.50-20070129-1/binutils/dlltool.c: In function ‘run’: ../../binutils-2.17.50-20070129-1/binutils/dlltool.c:1206: error: format not a string literal and no format arguments ../../binutils-2.17.50-20070129-1/binutils/dlltool.c: In function ‘gen_exp_file’: ../../binutils-2.17.50-20070129-1/binutils/dlltool.c:1992: error: ignoring return value of ‘fread’, declared with attribute warn_unused_result make[5]: *** [dlltool.o] Error 1 make[4]: *** [all-recursive] Error 1 make[3]: *** [all] Error 2 make[2]: *** [all-binutils] Error 2 make[1]: *** [all] Error 2 make binutils failed make: *** [cross] Error 1 zoobab@gierek /home/zoobab/soft/colinux/devel-colinux-20090415 [31]$ ================================================================ -- Benjamin Henrion <bhenrion at ffii.org> FFII Brussels - +32-484-566109 - +32-2-4148403 |
|
From: David R. <dr...@gm...> - 2009-04-25 03:11:14
|
Well, I got the colinux debug daemon thing running, and it produced some logs, but I'm not sure it's telling me anything useful. Maybe I just didn't enable the right debug levels? I uploaded the file here, if you want to look at it: http://davr.org/dbg.xml.bz2 Please let me know if there's anything else I can try. Maybe I should just buy a separate low-specced PC and use that as a standalone linux server, instead of trying to be clever and run it all in one box ;) Thanks On Fri, Apr 24, 2009 at 1:26 PM, David Rorex <dr...@gm...> wrote: > On Fri, Apr 24, 2009 at 12:41 PM, Henry Nestler <hen...@ar...> wrote: > >> Hello David, >> >> David Rorex wrote: >> >>> I'm having trouble writing a quick way to reproduce it, it seems the >>> same problem doesn't happen if I just use loop devices. That means the >>> minimal way to reproduce might be for you to have three separate actual >>> partitions to use for a raid-5 test :( >>> >>> I'll see if I can write the minimal steps for reproducing, assuming you >>> create 3 small empty partitions on your disk first. >>> >> >> Creating partitions on a disk is a problem for mostly testers. >> An older Bug #1569947 has some instructions and testing steps. Perhaps you >> can use these also for your test here? >> >> see: >> "Data corruption on md/raid5 under 0.6.3 and also 0.7.1-hn14" >> >> https://sourceforge.net/tracker/?func=detail&aid=1569947&group_id=98788&atid=622063 >> >> > Hi Henry, > > I tried the test in that page, and it does appear to reproduce the problem. > My problem is different than his...in his case he has data corruption, seg > fault, kernel panic. In my case, the dd commands write the files with no > errors reported, but the md5sum hangs on trying to read the first file. > > 1. Create 3 files of 500MB filled with zeros in windows > 2. Assign these files to colinux as block devices using cobd > 3. Create the raid (x,y,z are the # of the cobd device set in the colinux > config file) > modprobe raid5 > mdadm --create /dev/md1 /dev/cobdX /dev/cobdY /dev/cobdZ > mkfs.ext3 /dev/md1 > mkdir /raidtst > mount /dev/md1 /raidtst > 4. Run test > while true; do > for i in 1 2 3; do dd_rescue -m 300M /dev/zero /raidtst/f.$i; done > for i in 1 2 3; do ls -la /raidtst/f.$i; md5sum /raidtst/f.$i; done > for i in 1 2 3; do rm -f /raidtst/f.$i; done > done > 5. In my case, the last thing I see is the output of "ls -la /raidtst/f.1", > the md5sum command never completes. Colinux is not crashed, if I run 'top', > I see 75-99% cpu under 'wa' (aka IO Wait). I can still access /raidtst via > ls, and copying a small 100 byte file over there works fine & I can read it > back. > > Maybe sometimes it works directly after writing the file and reading it > back, due to the data being cached in RAM? It seems like with creating a lot > of small test files, it works ok, but creating a very large file exposes the > problem quicker. So if you can't reproduce, maybe try increasing the file > size even more? > > I will try running the debug daemon and see if I can get it to show > anything that looks useful. > > Thanks > |
|
From: David R. <dr...@gm...> - 2009-04-24 20:26:53
|
On Fri, Apr 24, 2009 at 12:41 PM, Henry Nestler <hen...@ar...> wrote: > Hello David, > > David Rorex wrote: > >> I'm having trouble writing a quick way to reproduce it, it seems the >> same problem doesn't happen if I just use loop devices. That means the >> minimal way to reproduce might be for you to have three separate actual >> partitions to use for a raid-5 test :( >> >> I'll see if I can write the minimal steps for reproducing, assuming you >> create 3 small empty partitions on your disk first. >> > > Creating partitions on a disk is a problem for mostly testers. > An older Bug #1569947 has some instructions and testing steps. Perhaps you > can use these also for your test here? > > see: > "Data corruption on md/raid5 under 0.6.3 and also 0.7.1-hn14" > > https://sourceforge.net/tracker/?func=detail&aid=1569947&group_id=98788&atid=622063 > > Hi Henry, I tried the test in that page, and it does appear to reproduce the problem. My problem is different than his...in his case he has data corruption, seg fault, kernel panic. In my case, the dd commands write the files with no errors reported, but the md5sum hangs on trying to read the first file. 1. Create 3 files of 500MB filled with zeros in windows 2. Assign these files to colinux as block devices using cobd 3. Create the raid (x,y,z are the # of the cobd device set in the colinux config file) modprobe raid5 mdadm --create /dev/md1 /dev/cobdX /dev/cobdY /dev/cobdZ mkfs.ext3 /dev/md1 mkdir /raidtst mount /dev/md1 /raidtst 4. Run test while true; do for i in 1 2 3; do dd_rescue -m 300M /dev/zero /raidtst/f.$i; done for i in 1 2 3; do ls -la /raidtst/f.$i; md5sum /raidtst/f.$i; done for i in 1 2 3; do rm -f /raidtst/f.$i; done done 5. In my case, the last thing I see is the output of "ls -la /raidtst/f.1", the md5sum command never completes. Colinux is not crashed, if I run 'top', I see 75-99% cpu under 'wa' (aka IO Wait). I can still access /raidtst via ls, and copying a small 100 byte file over there works fine & I can read it back. Maybe sometimes it works directly after writing the file and reading it back, due to the data being cached in RAM? It seems like with creating a lot of small test files, it works ok, but creating a very large file exposes the problem quicker. So if you can't reproduce, maybe try increasing the file size even more? I will try running the debug daemon and see if I can get it to show anything that looks useful. Thanks |
|
From: Henry N. <hen...@ar...> - 2009-04-24 19:41:54
|
Hello David, David Rorex wrote: > I'm having trouble writing a quick way to reproduce it, it seems the > same problem doesn't happen if I just use loop devices. That means the > minimal way to reproduce might be for you to have three separate actual > partitions to use for a raid-5 test :( > > I'll see if I can write the minimal steps for reproducing, assuming you > create 3 small empty partitions on your disk first. Creating partitions on a disk is a problem for mostly testers. An older Bug #1569947 has some instructions and testing steps. Perhaps you can use these also for your test here? see: "Data corruption on md/raid5 under 0.6.3 and also 0.7.1-hn14" https://sourceforge.net/tracker/?func=detail&aid=1569947&group_id=98788&atid=622063 -- Henry N. |
|
From: David R. <dr...@gm...> - 2009-04-24 16:47:57
|
I'm having trouble writing a quick way to reproduce it, it seems the same problem doesn't happen if I just use loop devices. That means the minimal way to reproduce might be for you to have three separate actual partitions to use for a raid-5 test :( I'll see if I can write the minimal steps for reproducing, assuming you create 3 small empty partitions on your disk first. Thanks On Fri, Apr 24, 2009 at 12:34 AM, Paolo Minazzi <pao...@gm...>wrote: > Hi David, > are you sure the problem is not related to FPU or MMX ? > If you are sure as you have said in your email, probably it is a new > problem. > I know a little about raid. > All I know is about MMX and FPU problem. > I use raid to do all test. > To semplify our work, can you give us the MINIMAL steps to see the problem > ? > Bye, > Paolo > > > ------------------------------------------------------------------------------ > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensign option that enables unlimited > royalty-free distribution of the report engine for externally facing > server and web deployment. > http://p.sf.net/sfu/businessobjects > _______________________________________________ > coLinux-devel mailing list > coL...@li... > https://lists.sourceforge.net/lists/listinfo/colinux-devel > |
|
From: SourceForge.net <no...@so...> - 2009-04-24 08:43:28
|
Bugs item #2780261, was opened at 2009-04-24 08:43 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2780261&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: Crash / BSOD Group: v0.7.x (release) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: BUG: scheduling while atomic Initial Comment: I'm developing a serial driver for NTPD that opens a symbolic link to /dev/ttyS0, and copies some bytes to a PTY. After a few minutes of operation, it crashes NTPD (although sshd and vncserver continue to work). My kernel command line is simply root=/dev/cobd0, and the serial port is set up with ttys0=COM3,"BAUD=9600 PARITY=n DATA=8 STOP=1 dtr=on rts=on". I have attached the text of the bug notification. I'm using Windows 2000 as the host system, with Debian 5.0 running on coLinux 0.7.4-rc1. Incidentally, this bug seems to be a less severe form of one I encountered under 0.7.3, which occured under exactly the same circumstances, but brought the entire system crashing instead of just NTPD and the coLinux console. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2780261&group_id=98788 |
|
From: Paolo M. <pao...@gm...> - 2009-04-24 07:34:38
|
Hi David, are you sure the problem is not related to FPU or MMX ? If you are sure as you have said in your email, probably it is a new problem. I know a little about raid. All I know is about MMX and FPU problem. I use raid to do all test. To semplify our work, can you give us the MINIMAL steps to see the problem ? Bye, Paolo |
|
From: David R. <dr...@gm...> - 2009-04-23 22:01:20
|
Hi, I'm trying to use colinux to access linux software raid-5 partitions from windows. I've got coliunx setup & running fine, and raid-1 works well, but with raid-5 there is an odd problem. I can assemble the raid array, mount the array, list files inside it, and even access very small files (not sure exact size, but things like 1 or 2KB max). But as soon as I try to open/copy/md5sum (just to test) a file that's a couple KB or larger, the command hangs. Colinux is still running fine, there are no errors in the console, it's just the command accessing the files is hung. I cannot even kill the command (cp, md5sum, or whatever I used). I saw there were some fixes for raid-5 in the very latest 0.7.4-rc2, which is what I'm using now, and I have confirmed that it is NOT using mmx or sse checksumming commands (from dmesg): > md: raid1 personality registered for level 1 raid5: measuring checksumming speed 8regs : 4271.200 MB/sec 8regs_prefetch: 4348.400 MB/sec 32regs : 2592.400 MB/sec 32regs_prefetch: 2247.600 MB/sec raid5: using function: 8regs_prefetch (4348.400 MB/sec) raid6: int32x1 865 MB/s raid6: int32x2 839 MB/s raid6: int32x4 667 MB/s raid6: int32x8 622 MB/s raid6: using algorithm int32x1 (865 MB/s) I'm using the Ubuntu-7.10.ext3.2gb root filesystem, and I'm using Xming to access X11 apps. Here's a snippet from my colinux.conf file, I'm using cobd to access drive partitions directly. The colinux wiki is very confusing on this matter, with some conflicting info, depending on which page you view, so it may be there is a better way to access native partitions than "cobd2=\Device\Harddisk1\Partition3" which I am using. > # File contains the root file system. # Download and extract preconfigured file from SF "Images for 2.6". cobd0="Ubuntu-7.10.ext3.2gb.fs" > # Swap device, should be an empty file with 128..512MB. cobd1="swap128.fs" > # large ext3 partition - works fine cobd2=\Device\Harddisk1\Partition3 > # raid-5 - has mentioned problem cobd3=\Device\Harddisk1\Partition1 cobd4=\Device\Harddisk2\Partition1 cobd5=\Device\Harddisk3\Partition1 > # raid-1 - works fine # cobd6=\Device\Harddisk1\Partition2 cobd7=\Device\Harddisk2\Partition2 Please let me know the best way to go about debugging this, if you would like me to run the colinux debugging tool, or if there are other tests I can run to try and solve this issue. Thanks for the help, and thanks for colinux, it's really a wonderful idea. -David R |
|
From: Henry N. <hen...@ar...> - 2009-04-23 19:36:46
|
Philip Bliss wrote: > I am developing a serial driver for linux using coLinux 0.7.4 on a > Windows 2000 machine, and I get this error message seemingly at random: > > BUG: scheduling while atomic: events/0/0x00010000/4 > [<c0103b7a>] show_trace_log_lvl+0x1a/0x30 > [<c0103cb2>] show_trace+0x12/0x20 > [<c0104ae5>] dump_stack+0x15/0x20 > [<c02e61e1>] schedule+0x4d1/0x670 > [<c02e7e63>] __down+0xa3/0x140 > [<c02e7d4a>] __down_failed+0xa/0x10 > [<c025612a>] cocd_interrupt+0x8a/0x100 > [<c013ab91>] handle_IRQ_event+0x31/0x60 > [<c013aeb9>] __do_IRQ+0x79/0x100 > [<c013d0ba>] co_callback+0x16a/0x390 > [<c010a593>] proxy_interrupt_handler+0x43/0x60 > [<c0103873>] common_interrupt+0x23/0x30 > [<c025631d>] cocd_unit_task+0xfd/0x1b0 > [<c0120be4>] run_workqueue+0x84/0x170 > [<c012141c>] worker_thread+0x6c/0xa0 > [<c01241b2>] kthread+0x42/0x70 > [<c0103997>] kernel_thread_helper+0x7/0x10 > ======================= > > It does not totally bring the system down, but it does end my debugging > session. Does this make sense to anyone? Yes, of curse. Please create a Bug entry for this. Please add your "cat /proc/cmdline" into the report. Please add the config line for this device also. I think, there is a coding error in the interrupt handler. -- Henry N. |
|
From: Philip B. <pb...@pe...> - 2009-04-23 14:55:21
|
Hi there I am developing a serial driver for linux using coLinux 0.7.4 on a Windows 2000 machine, and I get this error message seemingly at random: BUG: scheduling while atomic: events/0/0x00010000/4 [<c0103b7a>] show_trace_log_lvl+0x1a/0x30 [<c0103cb2>] show_trace+0x12/0x20 [<c0104ae5>] dump_stack+0x15/0x20 [<c02e61e1>] schedule+0x4d1/0x670 [<c02e7e63>] __down+0xa3/0x140 [<c02e7d4a>] __down_failed+0xa/0x10 [<c025612a>] cocd_interrupt+0x8a/0x100 [<c013ab91>] handle_IRQ_event+0x31/0x60 [<c013aeb9>] __do_IRQ+0x79/0x100 [<c013d0ba>] co_callback+0x16a/0x390 [<c010a593>] proxy_interrupt_handler+0x43/0x60 [<c0103873>] common_interrupt+0x23/0x30 [<c025631d>] cocd_unit_task+0xfd/0x1b0 [<c0120be4>] run_workqueue+0x84/0x170 [<c012141c>] worker_thread+0x6c/0xa0 [<c01241b2>] kthread+0x42/0x70 [<c0103997>] kernel_thread_helper+0x7/0x10 ======================= It does not totally bring the system down, but it does end my debugging session. Does this make sense to anyone? Regards Philip Bliss Disclaimer: http://www.peralex.com/disclaimer.html |
|
From: Alexey E. <al...@gm...> - 2009-04-21 16:48:16
|
>Henry wrote: > > coLinux parallel to VirtualBox: > +-- Windows (Host) ---------------------+ > | | > | +-- VirtualBox --+ +-- coLinux --+ | > | | | | | | > | | Any other OS? | | Linux OS | | > | | | | | | > | | | | | | > | +----------------+ +-------------+ | > +---------------------------------------+ Parralel, like this. Very nice ASCII art BTW :) ! -- -Alexey Eromenko "Technologov" |
|
From: Alexey E. <al...@gm...> - 2009-04-21 12:15:03
|
On Tue, Apr 21, 2009 at 2:57 PM, Paolo Minazzi <pao...@gm...> wrote: > Hi, > Please explain where there is the BUG. > At startup ? > Can you say (about) where is the kernel last line of boot ? > Please try to be more precise as possible. It is the only way to try > to understand. There is no last line of boot. As soon as I start coLinux + VirtualBox in VMX mode I get BSOD instantly. > Maybe we misunderstand. I understand what you said. I assumed that you want to reproduce the collision on VMware. I'm just saying that it is not possible to reproduce this crash under VMware. -- -Alexey Eromenko "Technologov" |
|
From: Paolo M. <pao...@gm...> - 2009-04-21 11:57:54
|
Hi, Please explain where there is the BUG. At startup ? Can you say (about) where is the kernel last line of boot ? Please try to be more precise as possible. It is the only way to try to understand. Bye, Paolo On Tue, Apr 21, 2009 at 1:44 PM, Alexey Eremenko <al...@gm...> wrote: > On Tue, Apr 21, 2009 at 2:34 PM, Paolo Minazzi <pao...@gm...> wrote: >> Hi Alexey, >> I have took a look at link you have shown us. >> >> I use everyday vmware. I use colinux under windows under vmware. >> In this way I can test my colinux without crush my PC. >> If I do bad things, I can crash only vmware. >> > This trick will not allow you to run VirtualBox in VMX mode under > VMware. Only real hardware will do. This is because VMware cannot > virtualize VMX yet. > >> The problem is that it is not easy understand this bug. >> - is it a virtualbox bug ? >> - is it a colinux bug ? >> > > I don't know if it's coLinux or virtualbox bug, but I would like to find out. > > -- > -Alexey Eromenko "Technologov" > > ------------------------------------------------------------------------------ > Stay on top of everything new and different, both inside and > around Java (TM) technology - register by April 22, and save > $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. > 300 plus technical and hands-on sessions. Register today. > Use priority code J9JMT32. http://p.sf.net/sfu/p > _______________________________________________ > coLinux-devel mailing list > coL...@li... > https://lists.sourceforge.net/lists/listinfo/colinux-devel > |
|
From: Alexey E. <al...@gm...> - 2009-04-21 11:44:15
|
On Tue, Apr 21, 2009 at 2:34 PM, Paolo Minazzi <pao...@gm...> wrote: > Hi Alexey, > I have took a look at link you have shown us. > > I use everyday vmware. I use colinux under windows under vmware. > In this way I can test my colinux without crush my PC. > If I do bad things, I can crash only vmware. > This trick will not allow you to run VirtualBox in VMX mode under VMware. Only real hardware will do. This is because VMware cannot virtualize VMX yet. > The problem is that it is not easy understand this bug. > - is it a virtualbox bug ? > - is it a colinux bug ? > I don't know if it's coLinux or virtualbox bug, but I would like to find out. -- -Alexey Eromenko "Technologov" |
|
From: Paolo M. <pao...@gm...> - 2009-04-21 11:34:28
|
Hi Alexey, I have took a look at link you have shown us. I use everyday vmware. I use colinux under windows under vmware. In this way I can test my colinux without crush my PC. If I do bad things, I can crash only vmware. The problem is that it is not easy understand this bug. - is it a virtualbox bug ? - is it a colinux bug ? Some time ao I have tried to use virtualbox instead vmware to do my test. At that time I was unable to try colinux under windows under virtualbox. It could be interesting know if virtualbox show a new colinux error that is not easy see on a real PC. But it could be that it is a virtualbox error, or better, virtualbox cannot manages correctly colinux. To be honest, I prefer to use vmware because for now it is more stable. Bye, Paolo On Tue, Apr 21, 2009 at 10:14 AM, Alexey Eremenko <al...@gm...> wrote: > Hi, > > I had a Host crash (BSOD) when running coLinux together with > VirtualBox in VMX mode. > > Can you take a look at it ? > http://www.virtualbox.org/ticket/3724 > > -- > -Alexey Eromenko "Technologov", 21.4.2009. > > ------------------------------------------------------------------------------ > Stay on top of everything new and different, both inside and > around Java (TM) technology - register by April 22, and save > $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. > 300 plus technical and hands-on sessions. Register today. > Use priority code J9JMT32. http://p.sf.net/sfu/p > _______________________________________________ > coLinux-devel mailing list > coL...@li... > https://lists.sourceforge.net/lists/listinfo/colinux-devel > |
81 messages has been excluded from this view by a project administrator.
