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-09 21:13:12
|
Bugs item #2748015, was opened at 2009-04-09 15:54 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2748015&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: PuTTY failing after a while with "Server key not valid" Initial Comment: Hi, a few days ago I upgraded my coLinux install to version 0.8.0 snapshot 20090329. While using the ndis-bridge feature I noticed my SSH connections crashing after a while (like 20 minutes, sometimes less, sometimes after hours). PuTTY and WinSCP report the error as "Server's host key did not match the signature supplied". WinSCP is build on the SSH code of PuTTY so it seems to be a low-level error. I tested a few setups to isolate the problem: - coLinux 0.8.0 (20090329) with ndis-bridge: fails after a while. - coLinux 0.8.0 (20090329) with pcap-bridge: fails after a while. - coLinux 0.7.4 rc1 (20090329) with ndis-bridge: fails after a while. - coLinux 0.7.4 rc1 (20090329) with pcap-bridge: fails after a while. - coLinux 0.7.3 (20080608) with pcap-bridge: still going strong after 2 hours and alot of traffic. The fact that I get the same error with the RC1 and the 0.8.0 development version is not supprising as it should be based on the same code. >From searching the net I found these possible causes for the problem: - The cached server key signature is not valid anymore (would prevent me from logging in) - The network traffic gets mauled between server and client - The client or server software can be at fault. My setup specs: - AMD AthlonXP 3800+, 2gb ram - Windows XP Pro SP3 + all updates to date - Network card: NVIDIA nForce 10/100/1000 Mbps Ethernet - Guest OS is ArchLinux (ver 2009.02) (using only prebuild packages from the ArchLinux repositories) - Server software: OpenSSL (0.9.8j pacman package #1) / OpenSSH (5.1p1 pacman package #2) - Client software: PuTTY (0.60) / WinSCP (4.1.7 build 413) I tested the virtual machine on the windows host system. There cannot be any signal decay on the wire cause the bridged network shouldn't use it. This, and the fact I cannot reproduce the problem with version 0.7.3, leads me to believe the newer colinux versions are corrupting the data somewhere in between. I would like to know what you make of this problem. Solutions/workarounds and reproducability confirmations are also welcome. Thanks, Keith ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-04-09 21:12 Message: Thanks for the quick response. Above I wrote: I tested the virtual machine on the windows host system. This means I used the same desktop/computer system to run the virtual machine and to run the client software (PuTTY, WinSCP). Therefore I concluded the traffic does not go over the wire. As for the hours between my bug report and this comment the same virtual machine running under coLinux 0.7.3 is still doing great. I did not experience any corrupted downloads inside the vm, but I will test this later on. Also I noticed my sleep command aborting sometimes while running this bash script (to generate traffic) while true; do echo -n "$RANDOM"; sleep 0.5; done It blurts somekind of assertion not being valid or something in xnanosleep.c on some line, will report the actual error message later on. Maybe this is related, cause I don't get such aborts with the 0.7.3 version. I will investigate the problem further tomorrow or the day after that. Keith ---------------------------------------------------------------------- Comment By: Henry N. (henryn) Date: 2009-04-09 17:18 Message: Hello Keith, do you use PuTTY on same desktop where coLinux is running? Or goes it over the wire? I can not assume, that this is a problem on the network bridge between coLinux and Host. I use PuTTY every day for many hours and never have corrupted data, or such errors. I'm auto logged in with public + private key pairs. PuTTY and coLinux runs on the same desktop. For me, I use PuTTY as connection between Host (Windows) and Guest (coLInux). I also have no errors from network mounts and getting downloads from internet via this bridging interface. coLinux ndis-bridge have heavy tested with "netio" and there are no errors. Please test your network connection without ssh, for example with netio ( http://www.nwlab.net/art/netio/netio.html ). Use the -t option to test only TCP (ssh uses TCP only). Test first from your location where you have detected the errors. Than test the connection between your Host (Windows) and Guest (coLinux). Changes on pcap-bridge betwen 0.7.3 and 0.7.4 are very rarely. Here is the list of changes: http://colinux.svn.sourceforge.net/viewvc/colinux/branches/devel/src/colinux/os/winnt/user/conet-bridged-daemon/?view=log Revision 1057 was the release build for 0.7.3. So, there exist only 4 changes up to version 0.7.4. The biggest change was revision 1222, this is first included in build 20090227. To find the regression, you can use snapshots from http://www.henrynestler.com/colinux/testing/devel-0.8.0/ Henry ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2748015&group_id=98788 |
|
From: SourceForge.net <no...@so...> - 2009-04-09 17:18:41
|
Bugs item #2748015, was opened at 2009-04-09 17:54 Message generated for change (Comment added) made by henryn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2748015&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: PuTTY failing after a while with "Server key not valid" Initial Comment: Hi, a few days ago I upgraded my coLinux install to version 0.8.0 snapshot 20090329. While using the ndis-bridge feature I noticed my SSH connections crashing after a while (like 20 minutes, sometimes less, sometimes after hours). PuTTY and WinSCP report the error as "Server's host key did not match the signature supplied". WinSCP is build on the SSH code of PuTTY so it seems to be a low-level error. I tested a few setups to isolate the problem: - coLinux 0.8.0 (20090329) with ndis-bridge: fails after a while. - coLinux 0.8.0 (20090329) with pcap-bridge: fails after a while. - coLinux 0.7.4 rc1 (20090329) with ndis-bridge: fails after a while. - coLinux 0.7.4 rc1 (20090329) with pcap-bridge: fails after a while. - coLinux 0.7.3 (20080608) with pcap-bridge: still going strong after 2 hours and alot of traffic. The fact that I get the same error with the RC1 and the 0.8.0 development version is not supprising as it should be based on the same code. >From searching the net I found these possible causes for the problem: - The cached server key signature is not valid anymore (would prevent me from logging in) - The network traffic gets mauled between server and client - The client or server software can be at fault. My setup specs: - AMD AthlonXP 3800+, 2gb ram - Windows XP Pro SP3 + all updates to date - Network card: NVIDIA nForce 10/100/1000 Mbps Ethernet - Guest OS is ArchLinux (ver 2009.02) (using only prebuild packages from the ArchLinux repositories) - Server software: OpenSSL (0.9.8j pacman package #1) / OpenSSH (5.1p1 pacman package #2) - Client software: PuTTY (0.60) / WinSCP (4.1.7 build 413) I tested the virtual machine on the windows host system. There cannot be any signal decay on the wire cause the bridged network shouldn't use it. This, and the fact I cannot reproduce the problem with version 0.7.3, leads me to believe the newer colinux versions are corrupting the data somewhere in between. I would like to know what you make of this problem. Solutions/workarounds and reproducability confirmations are also welcome. Thanks, Keith ---------------------------------------------------------------------- >Comment By: Henry N. (henryn) Date: 2009-04-09 19:18 Message: Hello Keith, do you use PuTTY on same desktop where coLinux is running? Or goes it over the wire? I can not assume, that this is a problem on the network bridge between coLinux and Host. I use PuTTY every day for many hours and never have corrupted data, or such errors. I'm auto logged in with public + private key pairs. PuTTY and coLinux runs on the same desktop. For me, I use PuTTY as connection between Host (Windows) and Guest (coLInux). I also have no errors from network mounts and getting downloads from internet via this bridging interface. coLinux ndis-bridge have heavy tested with "netio" and there are no errors. Please test your network connection without ssh, for example with netio ( http://www.nwlab.net/art/netio/netio.html ). Use the -t option to test only TCP (ssh uses TCP only). Test first from your location where you have detected the errors. Than test the connection between your Host (Windows) and Guest (coLinux). Changes on pcap-bridge betwen 0.7.3 and 0.7.4 are very rarely. Here is the list of changes: http://colinux.svn.sourceforge.net/viewvc/colinux/branches/devel/src/colinux/os/winnt/user/conet-bridged-daemon/?view=log Revision 1057 was the release build for 0.7.3. So, there exist only 4 changes up to version 0.7.4. The biggest change was revision 1222, this is first included in build 20090227. To find the regression, you can use snapshots from http://www.henrynestler.com/colinux/testing/devel-0.8.0/ Henry ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2748015&group_id=98788 |
|
From: SourceForge.net <no...@so...> - 2009-04-09 15:54:38
|
Bugs item #2748015, was opened at 2009-04-09 15:54 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2748015&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: PuTTY failing after a while with "Server key not valid" Initial Comment: Hi, a few days ago I upgraded my coLinux install to version 0.8.0 snapshot 20090329. While using the ndis-bridge feature I noticed my SSH connections crashing after a while (like 20 minutes, sometimes less, sometimes after hours). PuTTY and WinSCP report the error as "Server's host key did not match the signature supplied". WinSCP is build on the SSH code of PuTTY so it seems to be a low-level error. I tested a few setups to isolate the problem: - coLinux 0.8.0 (20090329) with ndis-bridge: fails after a while. - coLinux 0.8.0 (20090329) with pcap-bridge: fails after a while. - coLinux 0.7.4 rc1 (20090329) with ndis-bridge: fails after a while. - coLinux 0.7.4 rc1 (20090329) with pcap-bridge: fails after a while. - coLinux 0.7.3 (20080608) with pcap-bridge: still going strong after 2 hours and alot of traffic. The fact that I get the same error with the RC1 and the 0.8.0 development version is not supprising as it should be based on the same code. >From searching the net I found these possible causes for the problem: - The cached server key signature is not valid anymore (would prevent me from logging in) - The network traffic gets mauled between server and client - The client or server software can be at fault. My setup specs: - AMD AthlonXP 3800+, 2gb ram - Windows XP Pro SP3 + all updates to date - Network card: NVIDIA nForce 10/100/1000 Mbps Ethernet - Guest OS is ArchLinux (ver 2009.02) (using only prebuild packages from the ArchLinux repositories) - Server software: OpenSSL (0.9.8j pacman package #1) / OpenSSH (5.1p1 pacman package #2) - Client software: PuTTY (0.60) / WinSCP (4.1.7 build 413) I tested the virtual machine on the windows host system. There cannot be any signal decay on the wire cause the bridged network shouldn't use it. This, and the fact I cannot reproduce the problem with version 0.7.3, leads me to believe the newer colinux versions are corrupting the data somewhere in between. I would like to know what you make of this problem. Solutions/workarounds and reproducability confirmations are also welcome. Thanks, Keith ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2748015&group_id=98788 |
|
From: SourceForge.net <no...@so...> - 2009-04-09 10:18:08
|
Bugs item #2747242, was opened at 2009-04-09 11:18 Message generated for change (Tracker Item Submitted) made by merseyviking You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2747242&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.7.x (release) Status: Open Resolution: None Priority: 5 Private: No Submitted By: MerseyViking (merseyviking) Assigned to: Nobody/Anonymous (nobody) Summary: cofs and cmake Initial Comment: I'm using andLinux to do some cross-platform development using cmake (version 2.4-patch 7) as the makefile generator. If I have a cofs mount pointing to my Windows drive, cmake falls over when trying to compile a simple test app. If the same directory is mounted as a SMB share, it works fine. The error I get from cmake is: $ cmake . -G"Unix Makefiles" -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- broken CMake Error: The C compiler "/usr/bin/gcc" is not able to compile a simple test program. It fails with the following output: make: *** Makefile: No such file or directory. Stop. CMake will not be able to correctly generate this project. -- Configuring done I appreciate this may be an issue with cmake, such as it creating funky filenames that cofs can't deal with, but it makes more sense for a filesystem to support a tool rather than the other way round. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2747242&group_id=98788 |
|
From: coLinux a. <col...@he...> - 2009-03-30 04:18:13
|
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-20090329/ colinux-0.8.0-20090329.src.tgz (684543 Bytes) daemons-0.8.0-20090329.dbg.zip (590995 Bytes) daemons-0.8.0-20090329.zip (477764 Bytes) modules-2.6.22.18-co-0.8.0-20090329.tgz (2639197 Bytes) vmlinux-2.6.22.18-co-0.8.0-20090329.zip (1672600 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 Inside coLinux please update modules as follow: rm -rf /lib/modules/*-co-* tar -xzf modules-*-co-*-20090329.tgz -C / 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.1.2. A service from http://gcc.gnu.org/wiki/CompileFarm -- Lots of fun with newest version, Henry Nestler ------------------------------------------------------------------------ r1240 | henryn | 2009-03-29 14:49:24 +0000 (Sun, 29 Mar 2009) | 1 line Changed paths: M /branches/devel/conf/linux-2.6.22.18-config M /branches/devel/patch/base-2.6.22.diff M /branches/devel/patch/pci-2.6.22.diff M /branches/devel/patch/scsi-2.6.22.diff * Remove CONFIG_ZONE_DMA from config, ignore GFP_DMA in kmalloc. ------------------------------------------------------------------------ |
|
From: Henry N. <hen...@ar...> - 2009-03-29 20:46:09
|
Hello, Next release candidate 0.7.4-rc1 is available from snapshot page under "stable branch". http://www.colinux.org/snapshots/ This is a pure copy from currently branch devel. Users of devel 0.8.0 will not find any differences as only the versions number. Notes about all changes you can read from file NEWS and Changelog there. -- Henry N. |
|
From: coLinux a. <col...@he...> - 2009-03-29 04:11:12
|
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-20090328/ colinux-0.8.0-20090328.src.tgz (684760 Bytes) daemons-0.8.0-20090328.dbg.zip (590996 Bytes) daemons-0.8.0-20090328.zip (477772 Bytes) modules-2.6.22.18-co-0.8.0-20090328.tgz (2639243 Bytes) vmlinux-2.6.22.18-co-0.8.0-20090328.zip (1673986 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 Inside coLinux please update modules as follow: rm -rf /lib/modules/*-co-* tar -xzf modules-*-co-*-20090328.tgz -C / 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.1.2. A service from http://gcc.gnu.org/wiki/CompileFarm -- Lots of fun with newest version, Henry Nestler ------------------------------------------------------------------------ r1239 | henryn | 2009-03-28 22:55:12 +0000 (Sat, 28 Mar 2009) | 1 line Changed paths: M /branches/devel/patch/scsi-2.6.22.diff * scsi: Fix 1gb limit for get_sectorsize. GFP_DMA is not supported. ------------------------------------------------------------------------ |
|
From: Henry N. <hen...@ar...> - 2009-03-28 23:07:48
|
Am 04.03.2009 16:49, schrieb Bill C. Riemers: > On Tue, Mar 3, 2009 at 7:37 PM, Henry Nestler<hen...@ar...> wrote: > Cool. These look like exactly the features needed. However, the > SCSI driver is giving lots of errors. The command > > $ ./colinux-daemon.exe kernel=vmlinux initrd=initrd.cpio.gz mem=256 > eth0=slirp,,tcp:5902:5900 scsi1=cdrom,$(cygpath -wa > //cisco1.local/share/Download/images/Fedora-10-i386-DVD.iso) > scsi0=disk,test.img,4000000000 > > correctly finds CDROM, but validation tests always fail. I've made > it as far as 27% before erroring out. Using my hacked version of > anaconda, I find the cobd devices work as expected: > > $ ./colinux-daemon.exe kernel=vmlinux initrd=initrd.cpio.gz mem=256 > eth0=slirp,,tcp:5902:5900 cobd1=$(cygpath -wa > //cisco1.local/share/Download/images/Fedora-10-i386-DVD.iso) > scsi0=disk,test.img,4000000000 > > I can even get as far as partitioning in text mode, but I see lots of > errors, and there are no recognized disks. Errors like "ERROR; ddf1. > seeking device /dev/sda to 18446744073709551104". > > I thought maybe this was an integer overflow problem, but reducing the > size of scsi0 does not seem to help. Is fixed in SVN revision r1239. Please use todays snapshot. It was an unsupported GFP_DMA inside function get_sectorsize. So the sr driver falls back to "capacity = 0x1fffff". I have checked the Fedora 10 DVD image inside coLinux and all is ok now. :-) debian:~# dd if=/dev/sr0 | sha1sum 086fd570518ac58d3966c43c1b6d146e38919d8d - 7153464+0 records in 7153464+0 records out 3662573568 bytes (3.7 GB) copied, 604.809 seconds, 6.1 MB/s The DVD was configured in colinux config file as: scsi1=cdrom,\Device\Cdrom0 -- Henry N. |
|
From: SourceForge.net <no...@so...> - 2009-03-26 13:51:16
|
Bugs item #2688891, was opened at 2009-03-16 17:36 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2688891&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Using pcap/ndis bridge can't connent to colinux services Initial Comment: Hi, i've upgraded my really old colinux install to the lastest develoment snapshot (20090315 and 20090305 for modules and kernel). Trying to setup networking i've seen that using pcap-bridge or ndis-bridge doesn't let me to connect to the colinux machine: - if i try to do a ping from colinux to host machine all goes ok - if i try to do a ping from my host machine to colinux all goes ok - if i try to download something from the web server that resides on host machine or from internet trought colinux (using wget for example) all goes ok - if i try to connect to a netcat server or an openssh server that resieds on colinux from the host machine it doesn't do anything. - if i try to connect to a netcat server or an openssh server that resides on colinux from a machine in the lan all goes ok Doing more tests revealed that the problem is with TCP packets because i tried to set up a netcat udp server on port 53 and testing it trought nslookup shows that colinux machine recived the request. I get the same problem using ndis-bridge and using pcap-bridge: from kernel messages all seems to be ok! ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-03-26 13:50 Message: Try installing VirtualBox With IP Checksumming enabled on my Realtek adaptor, NDIS Bridging cannot ping each other but with Virtualbox installed and its networking component assigned - it seems that my NDIS Bridge works perfect with no errors.. Its been running my webserver fine for a month :P ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-03-26 10:48 Message: thank you! i hope to give a look this weekend ---------------------------------------------------------------------- Comment By: Henry N. (henryn) Date: 2009-03-25 21:48 Message: Inside Linux kernel exist some options, for example NETIF_F_IP_CSUM and NETIF_F_HW_CSUM. Both are not set, so Linux kernel should calculate the checksum. But I think, it does not. As I see, it does not for TCP and UDP packets. If you grep for these macros you will see how other net-drivers forwards this checksum calculation to the hardware chip. For coLinux we need to add this calculation in conet Linux kernel driver. Some interesting comments will find in Linux kernel header near the macro NETIF_F_IP_CSUM. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-03-17 12:57 Message: Really thanks! But, just a question: where i could look to fix checksum calculation? into conet module or into ndis/pcap-bridge daemon? ---------------------------------------------------------------------- Comment By: Henry N. (henryn) Date: 2009-03-16 20:17 Message: That should be simple. I have the same symptom on my Intel PCI-Express. My card is a "Realtek RTL8102E Family PCI-E Fast Ethernet NIC". I can not connect via ssh from Host to coLinux. tcpdump on coLinux or Wireshark on Windows let's see the problem: The card does not accept packets with checksum errors. To make it usable, go into network card "Hardware options" - "Extensions" - Properties: "Checksum" - and change the Value into "Disable". Here is an example session of ssh connect from host to coLinux (the failed case). tcpdump on coLinux: 20:44:36.847616 arp who-has 192.168.2.100 tell 192.168.2.104 20:44:36.847616 arp reply 192.168.2.100 is-at 00:21:85:56:fb:35 20:44:41.647688 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: TCP (6), length: 48) 192.168.2.104.22 > 192.168.2.100.1057: S, cksum 0xabbc (correct), 1094183181:1094183181(0) ack 309852530 win 5840 20:44:41.657689 IP (tos 0x0, ttl 128, id 434, offset 0, flags [DF], proto: TCP (6), length: 40) 192.168.2.100.1057 > 192.168.2.104.22: ., cksum 0x8637 (incorrect (-> 0xef50), ack 1 win 65535 20:44:53.647869 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: TCP (6), length: 48) 192.168.2.104.22 > 192.168.2.100.1057: S, cksum 0xabbc (correct), 1094183181:1094183181(0) ack 309852530 win 5840 20:44:53.647869 IP (tos 0x0, ttl 128, id 435, offset 0, flags [DF], proto: TCP (6), length: 40) 192.168.2.100.1057 > 192.168.2.104.22: ., cksum 0x8637 (incorrect (-> 0xef50), ack 1 win 65535 The same output with Wireshark on Windows: 6 5.016498 00:ff:99:88:b0:00 00:21:85:56:fb:35 ARP Who has 192.168.2.100? Tell 192.168.2.104 7 5.016521 00:21:85:56:fb:35 00:ff:99:88:b0:00 ARP 192.168.2.100 is at 00:21:85:56:fb:35 8 9.829057 192.168.2.104 192.168.2.100 TCP ssh > startron [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 9 9.829114 192.168.2.100 192.168.2.104 TCP [TCP Dup ACK 3#2] startron > ssh [ACK] Seq=1 Ack=1 Win=65535 [TCP CHECKSUM INCORRECT] Len=0 10 21.814002 192.168.2.104 192.168.2.100 TCP ssh > startron [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 11 21.814062 192.168.2.100 192.168.2.104 TCP [TCP Dup ACK 3#3] startron > ssh [ACK] Seq=1 Ack=1 Win=65535 [TCP CHECKSUM INCORRECT] Len=0 I leave this bug opened, because it would be nicer to calculate the checksum before submit it into the windows network stack. Disable the receiver is a workaround. ---------------------------------------------------------------------- Comment By: daniele_dll (daniele_dll) Date: 2009-03-16 17:45 Message: Note: when i upgraded i've launched the necessary remove/install driver as requested in readme file ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2688891&group_id=98788 |
|
From: SourceForge.net <no...@so...> - 2009-03-26 10:48:18
|
Bugs item #2688891, was opened at 2009-03-16 17:36 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2688891&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Using pcap/ndis bridge can't connent to colinux services Initial Comment: Hi, i've upgraded my really old colinux install to the lastest develoment snapshot (20090315 and 20090305 for modules and kernel). Trying to setup networking i've seen that using pcap-bridge or ndis-bridge doesn't let me to connect to the colinux machine: - if i try to do a ping from colinux to host machine all goes ok - if i try to do a ping from my host machine to colinux all goes ok - if i try to download something from the web server that resides on host machine or from internet trought colinux (using wget for example) all goes ok - if i try to connect to a netcat server or an openssh server that resieds on colinux from the host machine it doesn't do anything. - if i try to connect to a netcat server or an openssh server that resides on colinux from a machine in the lan all goes ok Doing more tests revealed that the problem is with TCP packets because i tried to set up a netcat udp server on port 53 and testing it trought nslookup shows that colinux machine recived the request. I get the same problem using ndis-bridge and using pcap-bridge: from kernel messages all seems to be ok! ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-03-26 10:48 Message: thank you! i hope to give a look this weekend ---------------------------------------------------------------------- Comment By: Henry N. (henryn) Date: 2009-03-25 21:48 Message: Inside Linux kernel exist some options, for example NETIF_F_IP_CSUM and NETIF_F_HW_CSUM. Both are not set, so Linux kernel should calculate the checksum. But I think, it does not. As I see, it does not for TCP and UDP packets. If you grep for these macros you will see how other net-drivers forwards this checksum calculation to the hardware chip. For coLinux we need to add this calculation in conet Linux kernel driver. Some interesting comments will find in Linux kernel header near the macro NETIF_F_IP_CSUM. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-03-17 12:57 Message: Really thanks! But, just a question: where i could look to fix checksum calculation? into conet module or into ndis/pcap-bridge daemon? ---------------------------------------------------------------------- Comment By: Henry N. (henryn) Date: 2009-03-16 20:17 Message: That should be simple. I have the same symptom on my Intel PCI-Express. My card is a "Realtek RTL8102E Family PCI-E Fast Ethernet NIC". I can not connect via ssh from Host to coLinux. tcpdump on coLinux or Wireshark on Windows let's see the problem: The card does not accept packets with checksum errors. To make it usable, go into network card "Hardware options" - "Extensions" - Properties: "Checksum" - and change the Value into "Disable". Here is an example session of ssh connect from host to coLinux (the failed case). tcpdump on coLinux: 20:44:36.847616 arp who-has 192.168.2.100 tell 192.168.2.104 20:44:36.847616 arp reply 192.168.2.100 is-at 00:21:85:56:fb:35 20:44:41.647688 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: TCP (6), length: 48) 192.168.2.104.22 > 192.168.2.100.1057: S, cksum 0xabbc (correct), 1094183181:1094183181(0) ack 309852530 win 5840 20:44:41.657689 IP (tos 0x0, ttl 128, id 434, offset 0, flags [DF], proto: TCP (6), length: 40) 192.168.2.100.1057 > 192.168.2.104.22: ., cksum 0x8637 (incorrect (-> 0xef50), ack 1 win 65535 20:44:53.647869 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: TCP (6), length: 48) 192.168.2.104.22 > 192.168.2.100.1057: S, cksum 0xabbc (correct), 1094183181:1094183181(0) ack 309852530 win 5840 20:44:53.647869 IP (tos 0x0, ttl 128, id 435, offset 0, flags [DF], proto: TCP (6), length: 40) 192.168.2.100.1057 > 192.168.2.104.22: ., cksum 0x8637 (incorrect (-> 0xef50), ack 1 win 65535 The same output with Wireshark on Windows: 6 5.016498 00:ff:99:88:b0:00 00:21:85:56:fb:35 ARP Who has 192.168.2.100? Tell 192.168.2.104 7 5.016521 00:21:85:56:fb:35 00:ff:99:88:b0:00 ARP 192.168.2.100 is at 00:21:85:56:fb:35 8 9.829057 192.168.2.104 192.168.2.100 TCP ssh > startron [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 9 9.829114 192.168.2.100 192.168.2.104 TCP [TCP Dup ACK 3#2] startron > ssh [ACK] Seq=1 Ack=1 Win=65535 [TCP CHECKSUM INCORRECT] Len=0 10 21.814002 192.168.2.104 192.168.2.100 TCP ssh > startron [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 11 21.814062 192.168.2.100 192.168.2.104 TCP [TCP Dup ACK 3#3] startron > ssh [ACK] Seq=1 Ack=1 Win=65535 [TCP CHECKSUM INCORRECT] Len=0 I leave this bug opened, because it would be nicer to calculate the checksum before submit it into the windows network stack. Disable the receiver is a workaround. ---------------------------------------------------------------------- Comment By: daniele_dll (daniele_dll) Date: 2009-03-16 17:45 Message: Note: when i upgraded i've launched the necessary remove/install driver as requested in readme file ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2688891&group_id=98788 |
|
From: coLinux a. <col...@he...> - 2009-03-26 05:07:04
|
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-20090325/ colinux-0.8.0-20090325.src.tgz (684711 Bytes) daemons-0.8.0-20090325.dbg.zip (590992 Bytes) daemons-0.8.0-20090325.zip (477771 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-20090321/ 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.1.2. A service from http://gcc.gnu.org/wiki/CompileFarm -- Lots of fun with newest version, Henry Nestler ------------------------------------------------------------------------ r1238 | henryn | 2009-03-25 21:52:25 +0000 (Wed, 25 Mar 2009) | 2 lines Changed paths: M /branches/devel/doc/colinux-daemon M /branches/devel/src/colinux/os/winnt/user/daemon/misc.c * With 'COLINUX_NO_CPU0_WORKAROUND=Y' coLinux never use first processor. Solves problems with heavy interrupts. ------------------------------------------------------------------------ |
|
From: SourceForge.net <no...@so...> - 2009-03-25 21:49:05
|
Bugs item #2688891, was opened at 2009-03-16 18:36 Message generated for change (Comment added) made by henryn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2688891&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Using pcap/ndis bridge can't connent to colinux services Initial Comment: Hi, i've upgraded my really old colinux install to the lastest develoment snapshot (20090315 and 20090305 for modules and kernel). Trying to setup networking i've seen that using pcap-bridge or ndis-bridge doesn't let me to connect to the colinux machine: - if i try to do a ping from colinux to host machine all goes ok - if i try to do a ping from my host machine to colinux all goes ok - if i try to download something from the web server that resides on host machine or from internet trought colinux (using wget for example) all goes ok - if i try to connect to a netcat server or an openssh server that resieds on colinux from the host machine it doesn't do anything. - if i try to connect to a netcat server or an openssh server that resides on colinux from a machine in the lan all goes ok Doing more tests revealed that the problem is with TCP packets because i tried to set up a netcat udp server on port 53 and testing it trought nslookup shows that colinux machine recived the request. I get the same problem using ndis-bridge and using pcap-bridge: from kernel messages all seems to be ok! ---------------------------------------------------------------------- >Comment By: Henry N. (henryn) Date: 2009-03-25 22:48 Message: Inside Linux kernel exist some options, for example NETIF_F_IP_CSUM and NETIF_F_HW_CSUM. Both are not set, so Linux kernel should calculate the checksum. But I think, it does not. As I see, it does not for TCP and UDP packets. If you grep for these macros you will see how other net-drivers forwards this checksum calculation to the hardware chip. For coLinux we need to add this calculation in conet Linux kernel driver. Some interesting comments will find in Linux kernel header near the macro NETIF_F_IP_CSUM. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-03-17 13:57 Message: Really thanks! But, just a question: where i could look to fix checksum calculation? into conet module or into ndis/pcap-bridge daemon? ---------------------------------------------------------------------- Comment By: Henry N. (henryn) Date: 2009-03-16 21:17 Message: That should be simple. I have the same symptom on my Intel PCI-Express. My card is a "Realtek RTL8102E Family PCI-E Fast Ethernet NIC". I can not connect via ssh from Host to coLinux. tcpdump on coLinux or Wireshark on Windows let's see the problem: The card does not accept packets with checksum errors. To make it usable, go into network card "Hardware options" - "Extensions" - Properties: "Checksum" - and change the Value into "Disable". Here is an example session of ssh connect from host to coLinux (the failed case). tcpdump on coLinux: 20:44:36.847616 arp who-has 192.168.2.100 tell 192.168.2.104 20:44:36.847616 arp reply 192.168.2.100 is-at 00:21:85:56:fb:35 20:44:41.647688 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: TCP (6), length: 48) 192.168.2.104.22 > 192.168.2.100.1057: S, cksum 0xabbc (correct), 1094183181:1094183181(0) ack 309852530 win 5840 20:44:41.657689 IP (tos 0x0, ttl 128, id 434, offset 0, flags [DF], proto: TCP (6), length: 40) 192.168.2.100.1057 > 192.168.2.104.22: ., cksum 0x8637 (incorrect (-> 0xef50), ack 1 win 65535 20:44:53.647869 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: TCP (6), length: 48) 192.168.2.104.22 > 192.168.2.100.1057: S, cksum 0xabbc (correct), 1094183181:1094183181(0) ack 309852530 win 5840 20:44:53.647869 IP (tos 0x0, ttl 128, id 435, offset 0, flags [DF], proto: TCP (6), length: 40) 192.168.2.100.1057 > 192.168.2.104.22: ., cksum 0x8637 (incorrect (-> 0xef50), ack 1 win 65535 The same output with Wireshark on Windows: 6 5.016498 00:ff:99:88:b0:00 00:21:85:56:fb:35 ARP Who has 192.168.2.100? Tell 192.168.2.104 7 5.016521 00:21:85:56:fb:35 00:ff:99:88:b0:00 ARP 192.168.2.100 is at 00:21:85:56:fb:35 8 9.829057 192.168.2.104 192.168.2.100 TCP ssh > startron [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 9 9.829114 192.168.2.100 192.168.2.104 TCP [TCP Dup ACK 3#2] startron > ssh [ACK] Seq=1 Ack=1 Win=65535 [TCP CHECKSUM INCORRECT] Len=0 10 21.814002 192.168.2.104 192.168.2.100 TCP ssh > startron [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 11 21.814062 192.168.2.100 192.168.2.104 TCP [TCP Dup ACK 3#3] startron > ssh [ACK] Seq=1 Ack=1 Win=65535 [TCP CHECKSUM INCORRECT] Len=0 I leave this bug opened, because it would be nicer to calculate the checksum before submit it into the windows network stack. Disable the receiver is a workaround. ---------------------------------------------------------------------- Comment By: daniele_dll (daniele_dll) Date: 2009-03-16 18:45 Message: Note: when i upgraded i've launched the necessary remove/install driver as requested in readme file ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2688891&group_id=98788 |
|
From: coLinux a. <col...@he...> - 2009-03-22 05:11:24
|
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-20090321/ colinux-0.8.0-20090321.src.tgz (683914 Bytes) daemons-0.8.0-20090321.dbg.zip (590772 Bytes) daemons-0.8.0-20090321.zip (477573 Bytes) modules-2.6.22.18-co-0.8.0-20090321.tgz (2639197 Bytes) vmlinux-2.6.22.18-co-0.8.0-20090321.zip (1673991 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 Inside coLinux please update modules as follow: rm -rf /lib/modules/*-co-* tar -xzf modules-*-co-*-20090321.tgz -C / 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.1.2. A service from http://gcc.gnu.org/wiki/CompileFarm -- Lots of fun with newest version, Henry Nestler ------------------------------------------------------------------------ r1237 | henryn | 2009-03-21 23:56:07 +0000 (Sat, 21 Mar 2009) | 3 lines Changed paths: M /branches/devel/patch/base-2.6.22.diff * Remove co_switch_wrapper_protected and all workaround for SSE/MMX on raid modules. Reverts the workaround from SVN r1212, related Bugs #2524658, #2551241. (Idea contributed by Paolo Minazzi) ------------------------------------------------------------------------ |
|
From: SourceForge.net <no...@so...> - 2009-03-18 18:54:13
|
Bugs item #2524658, was opened at 2009-01-20 20:54 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2524658&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: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Arya (aryairani) Assigned to: Henry N. (henryn) Summary: GPF trying to activate raid5 md array in 0.7.3 Initial Comment: I'm using the 0.7.3 release with the Ubuntu 7.10 disk image on XP Pro SP2. I'm very excited about being able to use coLinux to access md arrays under Windows. But I'm having some trouble. I've tried creating arrays using /dev/loopX, and also /dev/cobdX, with varying degrees of failure. sudo apt-get install mdadm mkdir ~/raid for i in ~/raid/{a,b,c,d}; do dd if=/dev/zero of=$i bs=10M count=1; sudo losetup -f $i; done arya@co-calculon:~/raid$ sudo losetup -a /dev/loop0: [7500]:16841 (/home/arya/raid/a) /dev/loop1: [7500]:16843 (/home/arya/raid/b) /dev/loop2: [7500]:16844 (/home/arya/raid/c) /dev/loop3: [7500]:16845 (/home/arya/raid/d) $ sudo modprobe md-mod $ sudo mdadm --create /dev/md0 --level=5 --raid-devices=4 /dev/loop{0,1,2,3} mdadm: array /dev/md0 started. arya@co-calculon:~/raid$ Looks good so far, right? But dmesg shows a GPF: md: bind<loop0> md: bind<loop1> md: bind<loop2> md: bind<loop3> raid5: automatically using best checksumming function: pIII_sse pIII_sse : 2469.600 MB/sec raid5: using function: pIII_sse (2469.600 MB/sec) raid6: int32x1 407 MB/s raid6: int32x2 678 MB/s raid6: int32x4 523 MB/s raid6: int32x8 480 MB/s raid6: mmxx1 1571 MB/s raid6: mmxx2 1866 MB/s raid6: sse1x1 933 MB/s raid6: sse1x2 1696 MB/s raid6: sse2x1 1742 MB/s raid6: sse2x2 2623 MB/s raid6: using algorithm sse2x2 (2623 MB/s) md: raid6 personality registered for level 6 md: raid5 personality registered for level 5 md: raid4 personality registered for level 4 raid5: device loop2 operational as raid disk 2 raid5: device loop1 operational as raid disk 1 raid5: device loop0 operational as raid disk 0 raid5: allocated 4196kB for md0 raid5: raid level 5 set md0 active with 3 out of 4 devices, algorithm 2 RAID5 conf printout: --- rd:4 wd:3 disk 0, o:1, dev:loop0 disk 1, o:1, dev:loop1 disk 2, o:1, dev:loop2 RAID5 conf printout: --- rd:4 wd:3 disk 0, o:1, dev:loop0 disk 1, o:1, dev:loop1 disk 2, o:1, dev:loop2 disk 3, o:1, dev:loop3 md: recovery of RAID array md0 md: minimum _guaranteed_ speed: 1000 KB/sec/disk. md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for recovery. md: using 128k window, over a total of 10176 blocks. general protection fault: 0000 [#1] PREEMPT Modules linked in: raid456 xor md_mod ipv6 fuse CPU: 0 EIP: 0060:[<c0103d46>] Not tainted VLI EFLAGS: 00010002 (2.6.22.18-co-0.7.3 #1) EIP is at math_state_restore+0x26/0x50 eax: 8005003b ebx: d8814ab0 ecx: db4aed00 edx: 00000000 esi: db0a8000 edi: db4add00 ebp: db0a9ce0 esp: db0a9cd8 ds: 007b es: 007b fs: 0000 gs: 0000 ss: 0068 Process md0_raid5 (pid: 2803, ti=db0a8000 task=d8814ab0 task.ti=db0a8000) Stack: db4abd00 db4acd00 db0a9d78 c01038fe db4abd00 db4aed00 00000003 db4acd00 db4add00 db0a9d78 db0a9d2c c146007b d881007b 00000000 ffffffff e0814bf3 00000060 00010206 8005003b db4ae000 00000010 00000000 00000000 00000000 Call Trace: [<c0103bba>] show_trace_log_lvl+0x1a/0x30 [<c0103c79>] show_stack_log_lvl+0xa9/0xd0 [<c01040eb>] show_registers+0x21b/0x3a0 [<c0104365>] die+0xf5/0x210 [<c010534d>] do_general_protection+0x1ad/0x1f0 [<c02a999a>] error_code+0x6a/0x70 [<c01038fe>] device_not_available+0x2e/0x33 [<e081282e>] xor_block+0x6e/0xa0 [xor] [<e095eaf8>] compute_block+0xd8/0x130 [raid456] [<e095fce7>] handle_stripe5+0x1197/0x13c0 [raid456] [<e0961522>] handle_stripe+0x32/0x16f0 [raid456] [<e0964007>] raid5d+0x2f7/0x450 [raid456] [<e094db00>] md_thread+0x30/0x100 [md_mod] [<c0123d32>] kthread+0x42/0x70 [<c01039c7>] kernel_thread_helper+0x7/0x10 ======================= Code: c3 8d 74 26 00 55 89 e5 83 ec 08 89 74 24 04 89 e6 89 1c 24 81 e6 00 e0 ff ff 8b 1e 0f 06 f6 43 0d 20 75 07 89 d8 e8 9a 37 00 00 <0f> ae 8b 10 02 00 00 83 4e 0c 01 fe 83 8d 01 00 00 8b 1c 24 8b EIP: [<c0103d46>] math_state_restore+0x26/0x50 SS:ESP 0068:db0a9cd8 note: md0_raid5[2803] exited with preempt_count 2 For reference: arya@co-calculon:~/raid$ sudo mdadm /dev/md0 /dev/md0: 29.81MiB raid5 4 devices, 1 spare. Use mdadm --detail for more detail. arya@co-calculon:~/raid$ sudo mdadm --detail /dev/md0 /dev/md0: Version : 00.90.03 Creation Time : Tue Jan 20 15:36:06 2009 Raid Level : raid5 Array Size : 30528 (29.82 MiB 31.26 MB) Used Dev Size : 10176 (9.94 MiB 10.42 MB) Raid Devices : 4 Total Devices : 4 Preferred Minor : 0 Persistence : Superblock is persistent Update Time : Tue Jan 20 15:36:06 2009 State : clean, degraded, recovering Active Devices : 3 Working Devices : 4 Failed Devices : 0 Spare Devices : 1 Layout : left-symmetric Chunk Size : 64K Rebuild Status : 0% complete UUID : 106a26c3:fae68f05:bc6a5c1d:79f7e806 (local to host co-calculon) Events : 0.1 Number Major Minor RaidDevice State 0 7 0 0 active sync /dev/loop0 1 7 1 1 active sync /dev/loop1 2 7 2 2 active sync /dev/loop2 4 7 3 3 spare rebuilding /dev/loop3 So due to the GPF the array is stuck in a degraded state. I'm pretty sure it's not actually recovering at this point. arya@co-calculon:~/raid$ sudo mdadm --stop /dev/md0 mdadm: fail to stop array /dev/md0: Device or resource busy arya@co-calculon:~/raid$ dmesg | tail -n 1 md: md0 still in use. arya@co-calculon:~/raid$ ----------------- Anyway, I tried again using block devices mapped to windows files: arya@co-calculon:~/raid$ cat /proc/partitions major minor #blocks name 117 0 2097152 cobd0 117 1 128 cobd1 117 3 2144646 cobd3 117 5 10240 cobd5 117 6 10240 cobd6 117 7 10240 cobd7 117 8 10240 cobd8 117 9 10240 cobd9 7 0 10240 loop0 7 1 10240 loop1 7 2 10240 loop2 7 3 10240 loop3 9 0 30528 md0 arya@co-calculon:~/raid$ sudo mdadm --create /dev/md1 --level=5 --raid-devices=4 /dev/cobd{5,6,7,8} dmesg shows: md: bind<cobd5> md: bind<cobd6> md: bind<cobd7> md: bind<cobd8> raid5: device cobd7 operational as raid disk 2 raid5: device cobd6 operational as raid disk 1 raid5: device cobd5 operational as raid disk 0 raid5: allocated 4196kB for md1 raid5: raid level 5 set md1 active with 3 out of 4 devices, algorithm 2 RAID5 conf printout: --- rd:4 wd:3 disk 0, o:1, dev:cobd5 disk 1, o:1, dev:cobd6 disk 2, o:1, dev:cobd7 RAID5 conf printout: --- rd:4 wd:3 disk 0, o:1, dev:cobd5 disk 1, o:1, dev:cobd6 disk 2, o:1, dev:cobd7 disk 3, o:1, dev:cobd8 md: recovery of RAID array md1 md: minimum _guaranteed_ speed: 1000 KB/sec/disk. md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for recovery. md: using 128k window, over a total of 10176 blocks. general protection fault: 0000 [#2] PREEMPT Modules linked in: raid456 xor md_mod ipv6 fuse CPU: 0 EIP: 0060:[<c0103d46>] Not tainted VLI EFLAGS: 00010002 (2.6.22.18-co-0.7.3 #1) EIP is at math_state_restore+0x26/0x50 eax: 8005003b ebx: daa2d530 ecx: d91a5500 edx: 00000000 esi: d8fbe000 edi: d91a4500 ebp: d8fbfce0 esp: d8fbfcd8 ds: 007b es: 007b fs: 0000 gs: 0000 ss: 0068 Process md1_raid5 (pid: 2888, ti=d8fbe000 task=daa2d530 task.ti=d8fbe000) Stack: d91a2500 d91a3500 d8fbfd78 c01038fe d91a2500 d91a5500 0000000b d91a3500 d91a4500 d8fbfd78 d8fbfd2c 0000007b 0000007b 00000000 ffffffff e0814aa8 00000060 00010202 8005003b d91a5000 00000010 00000000 00000000 00000000 Call Trace: [<c0103bba>] show_trace_log_lvl+0x1a/0x30 [<c0103c79>] show_stack_log_lvl+0xa9/0xd0 [<c01040eb>] show_registers+0x21b/0x3a0 [<c0104365>] die+0xf5/0x210 [<c010534d>] do_general_protection+0x1ad/0x1f0 [<c02a999a>] error_code+0x6a/0x70 [<c01038fe>] device_not_available+0x2e/0x33 [<e081282e>] xor_block+0x6e/0xa0 [xor] [<e095eaf8>] compute_block+0xd8/0x130 [raid456] [<e095fce7>] handle_stripe5+0x1197/0x13c0 [raid456] [<e0961522>] handle_stripe+0x32/0x16f0 [raid456] [<e0964007>] raid5d+0x2f7/0x450 [raid456] [<e094db00>] md_thread+0x30/0x100 [md_mod] [<c0123d32>] kthread+0x42/0x70 [<c01039c7>] kernel_thread_helper+0x7/0x10 ======================= Code: c3 8d 74 26 00 55 89 e5 83 ec 08 89 74 24 04 89 e6 89 1c 24 81 e6 00 e0 ff ff 8b 1e 0f 06 f6 43 0d 20 75 07 89 d8 e8 9a 37 00 00 <0f> ae 8b 10 02 00 00 83 4e 0c 01 fe 83 8d 01 00 00 8b 1c 24 8b EIP: [<c0103d46>] math_state_restore+0x26/0x50 SS:ESP 0068:d8fbfcd8 note: md1_raid5[2888] exited with preempt_count 2 On a previous attempt, I've also had it take colinux-daemon.exe into an infinite loop or something: arya@co-calculon:~$ cat /proc/partitions major minor #blocks name 117 0 2097152 cobd0 117 1 128 cobd1 117 5 10240 cobd5 117 6 10240 cobd6 117 7 10240 cobd7 117 8 10240 cobd8 117 9 10240 cobd9 arya@co-calculon:~$ sudo mdadm --create /dev/md0 --level=5 --raid-devices=4 /dev/cobd{5,6,7,8} mdadm: error opening /dev/md0: No such device or address arya@co-calculon:~$ sudo modprobe md-mod arya@co-calculon:~$ sudo mdadm --create /dev/md0 --level=5 --raid-devices=4 /dev/cobd{5,6,7,8} *crash* Can't kill colinux-daemon.exe, which is using 100% of one HT "cpu". colinux-daemon.exe output shows: md: bind<cobd5> md: bind<cobd6> md: bind<cobd7> md: bind<cobd8> raid5: automatically using best checksumming function: pIII_sse pIII_sse : 2282.400 MB/sec raid5: using function: pIII_sse (2282.400 MB/sec) raid6: int32x1 712 MB/s raid6: int32x2 714 MB/s raid6: int32x4 537 MB/s raid6: int32x8 491 MB/s raid6: mmxx1 1533 MB/s raid6: mmxx2 1893 MB/s raid6: sse1x1 954 MB/s console window shows this much, can't see where it started: [<c0103c79>] show_stack_log_lvl+0xa9/0xd0 [<c01040eb>] show_registers+0x21b/0x3a0 [<c0104365>] die+0xf5/0x210 [<c010b6fc>] do_page_fault+0x38c/0x6e0 [<c02a999a>] error_code+0x6a/0x70 [<c010c3f8>] deactivate_task+0x18/0x30 [<c02a7777>] __sched_text_start+0x377/0x670 [<c01144b4>] do_exit+0x7d4/0x940 [<c010447d>] die+0x20d/0x210 [<c010b6fc>] do_page_fault+0x38c/0x6e0 [<c02a999a>] error_code+0x6a/0x70 [<c010c3f8>] deactivate_task+0x18/0x30 [<c02a7777>] __sched_text_start+0x377/0x670 [<c01144b4>] do_exit+0x7d4/0x940 [<c010447d>] die+0x20d/0x210 [<c010b6fc>] do_page_fault+0x38c/0x6e0 [<c02a999a>] error_code+0x6a/0x70 [<c010c3f8>] deactivate_task+0x18/0x30 [<c02a7777>] __sched_text_start+0x377/0x670 [<c01144b4>] do_exit+0x7d4/0x940 [<c010447d>] die+0x20d/0x210 [<c010b6fc>] do_page_fault+0x38c/0x6e0 [<c02a999a>] error_code+0x6a/0x70 [<c010c3f8>] deactivate_task+0x18/0x30 Thanks for the all the amazing work already! ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2009-03-18 18:53 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Henry N. (henryn) Date: 2009-02-05 22:01 Message: Problems from disabling MMX/XMM in CPU caps we have seen on Bug#2551241. SSE-instructions needs to disable in kernel space only. SSE was used only for raid modules. Userland SSE-instractions should not disable. Eclipse/Java needs SIMD-Exceptions. So, only Raid modules are disabled for such instructions now. Committed as SVN revision r1212. ---------------------------------------------------------------------- Comment By: Henry N. (henryn) Date: 2009-01-24 12:57 Message: SSE2 is an extension of SSE. It is harmless, as long SSE is not enabled. SSE2 operations are not used without SSE support. In the kernel SSE is the macro X86_FEATURE_XMM (Streaming SIMD Extensions). SSE2 is X86_FEATURE_XMM2. The general problem is, that inside usage of MMX or SSE registers we can not allow an OS switch. These registers are not saved for OS switch. In native Linux kernel this is handled by disabling interrupts or by calling the preempt_disable() or kernel_fpu_begin(). But under coLinux we needs an OS switch for example for page allocations. Such will ends in an endless FPU fault loop. I will close this bug now and write some about SSE and MMX into the ToDo list. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-01-24 03:01 Message: The temporary fix seems to be working fine for raid5 and raid6 under the cases I tested before. Thanks! P.S. SSE2 flags is present in /proc/cpuinfo, but the RAID6 benchmark doesn't include sse2 anymore. Was that intentional? Cheers ---------------------------------------------------------------------- Comment By: Henry N. (henryn) Date: 2009-01-22 18:31 Message: Hello Arya, it should be fixed generally now for all raid levels, and all other drivers. You will find the build under http://www.colinux.org/snapshots/ and in autobuild. Please remember to reboot after you have updated modules in your directory /lib/modules, and replace your kernel. In the kernel file "vmlinux" is the most important change. A very simple test for the crash was: while true; do rmmod raid456; rmmod xor; modprobe xor; modprobe raid456; sleep 1; done PS: I don't know why SF has dropped my post from yesterday here. :-( ---------------------------------------------------------------------- Comment By: Henry N. (henryn) Date: 2009-01-21 20:07 Message: > raid6: mmxx1 739 MB/s > raid6: mmxx2 992 MB/s > raid6: sse1x1 462 MB/s > raid6: sse1x2 873 MB/s > raid6: sse2x1 1012 MB/s > raid6: sse2x2 1511 MB/s Oh yea, for raid6 some more "sse" operations are hidden in other files. I will fix it more generic, by disable all XMM/MMX features in the cpu caps. Please stand by and check the next autobuild. > [...] > Works ok with cobdX devices, I don't know why it crashed the firs time? I'm afraid, the old module "xor.ko" was always loaded at the time you have extracted the modules to /lib/modules. You need to reboot after update the modules. For the old raid5 I was testing very simple: while true; do rmmod xor; insmod xor.ko; sleep 1; done After 2...10 loops it's crashing. ---------------------------------------------------------------------- Comment By: Arya (aryairani) Date: 2009-01-21 17:23 Message: Whoops, duplicate post. ---------------------------------------------------------------------- Comment By: Arya (aryairani) Date: 2009-01-21 17:22 Message: Double-check same issue for raid6 (sse2x2?): arya@co-calculon:~/raid-test$ sudo mdadm --create /dev/md0 --level 6 --raid-devices=4 /dev/cobd{5,6,7,8} md: md0: raid array is not clean -- starting background reconstruction raid5: device cobd8 operational as raid disk 3 raid5: device cobd7 operational as raid disk 2 raid5: device cobd6 operational as raid disk 1 raid5: device cobd5 operational as raid disk 0 raid5: allocated 4196kB for md0 raid5: raid level 6 set md0 active with 4 out of 4 devices, algorithm 2 RAID5 conf printout: --- rd:4 wd:4 disk 0, o:1, dev:cobd5 disk 1, o:1, dev:cobd6 disk 2, o:1, dev:cobd7 disk 3, o:1, dev:cobd8 md: resync of RAID array md0 md: minimum _guaranteed_ speed: 1000 KB/sec/disk. md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for resync. md: using 128k window, over a total of 10176 blocks. general protection fault: 0000 [#1] PREEMPT Modules linked in: raid456 xor md_mod ipv6 fuse CPU: 0 <0>EIP: 0060:[<c0103d46>] Not tainted VLI <0>EFLAGS: 00010002 (2.6.22.18-co-0.8.0 #1) EIP is at math_state_restore+0x26/0x50 eax: 8005003b ebx: c15efab0 ecx: ffffffff edx: 00000000 esi: da812000 edi: 000003a0 ebp: da813db8 esp: da813db0 ds: 007b es: 007b fs: 0000 gs: 0000 ss: 0068 Process md0_raid5 (pid: 2795, ti=da812000 task=c15efab0 task.ti=da812000) <0>Stack: da813e3c 000003a0 da813e24 c01038fe da813e3c ffffffff db686000 000003a0 <0> 000003a0 da813e24 db6863a0 0000007b 0000007b da810000 ffffffff e08c2d8b <0> 00000060 00010206 000003a0 00001000 00000004 da813e44 da813e40 db687000 <0>Call Trace: [<c0103bba>] show_trace_log_lvl+0x1a/0x30 [<c0103c79>] show_stack_log_lvl+0xa9/0xd0 [<c01040eb>] show_registers+0x21b/0x3a0 [<c0104365>] die+0xf5/0x210 [<c010534d>] do_general_protection+0x1ad/0x1f0 [<c03057fa>] error_code+0x6a/0x70 [<c01038fe>] device_not_available+0x2e/0x33 [<e08bdf8f>] compute_parity6+0x19f/0x330 [raid456] [<e08bfa40>] handle_stripe+0x1550/0x16f0 [raid456] [<e08c1007>] raid5d+0x2f7/0x450 [raid456] [<e0846b00>] md_thread+0x30/0x100 [md_mod] [<c0124462>] kthread+0x42/0x70 [<c01039c7>] kernel_thread_helper+0x7/0x10 ======================= Code: c3 8d 74 26 00 55 89 e5 83 ec 08 89 74 24 04 89 e6 89 1c 24 81 e6 00 e0 ff ff 8b 1e 0f 06 f6 43 0d 20 75 07 89 d8 e8 ea 38 00 00 <0f> ae 8b 10 02 00 00 83 4e 0c 01 fe 83 8d 01 00 00 8b 1c 24 8b EIP: [<c0103d46>] math_state_restore+0x26/0x50 SS:ESP 0068:da813db0 note: md0_raid5[2795] exited with preempt_count 2 ---------------------------------------------------------------------- Comment By: Arya (aryairani) Date: 2009-01-21 09:47 Message: Double-check same issue for raid6 (sse2x2?): arya@co-calculon:~/raid-test$ sudo mdadm --create /dev/md0 --level 6 --raid-devices=4 /dev/cobd{5,6,7,8} md: md0: raid array is not clean -- starting background reconstruction raid5: device cobd8 operational as raid disk 3 raid5: device cobd7 operational as raid disk 2 raid5: device cobd6 operational as raid disk 1 raid5: device cobd5 operational as raid disk 0 raid5: allocated 4196kB for md0 raid5: raid level 6 set md0 active with 4 out of 4 devices, algorithm 2 RAID5 conf printout: --- rd:4 wd:4 disk 0, o:1, dev:cobd5 disk 1, o:1, dev:cobd6 disk 2, o:1, dev:cobd7 disk 3, o:1, dev:cobd8 md: resync of RAID array md0 md: minimum _guaranteed_ speed: 1000 KB/sec/disk. md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for resync. md: using 128k window, over a total of 10176 blocks. general protection fault: 0000 [#1] PREEMPT Modules linked in: raid456 xor md_mod ipv6 fuse CPU: 0 <0>EIP: 0060:[<c0103d46>] Not tainted VLI <0>EFLAGS: 00010002 (2.6.22.18-co-0.8.0 #1) EIP is at math_state_restore+0x26/0x50 eax: 8005003b ebx: c15efab0 ecx: ffffffff edx: 00000000 esi: da812000 edi: 000003a0 ebp: da813db8 esp: da813db0 ds: 007b es: 007b fs: 0000 gs: 0000 ss: 0068 Process md0_raid5 (pid: 2795, ti=da812000 task=c15efab0 task.ti=da812000) <0>Stack: da813e3c 000003a0 da813e24 c01038fe da813e3c ffffffff db686000 000003a0 <0> 000003a0 da813e24 db6863a0 0000007b 0000007b da810000 ffffffff e08c2d8b <0> 00000060 00010206 000003a0 00001000 00000004 da813e44 da813e40 db687000 <0>Call Trace: [<c0103bba>] show_trace_log_lvl+0x1a/0x30 [<c0103c79>] show_stack_log_lvl+0xa9/0xd0 [<c01040eb>] show_registers+0x21b/0x3a0 [<c0104365>] die+0xf5/0x210 [<c010534d>] do_general_protection+0x1ad/0x1f0 [<c03057fa>] error_code+0x6a/0x70 [<c01038fe>] device_not_available+0x2e/0x33 [<e08bdf8f>] compute_parity6+0x19f/0x330 [raid456] [<e08bfa40>] handle_stripe+0x1550/0x16f0 [raid456] [<e08c1007>] raid5d+0x2f7/0x450 [raid456] [<e0846b00>] md_thread+0x30/0x100 [md_mod] [<c0124462>] kthread+0x42/0x70 [<c01039c7>] kernel_thread_helper+0x7/0x10 ======================= Code: c3 8d 74 26 00 55 89 e5 83 ec 08 89 74 24 04 89 e6 89 1c 24 81 e6 00 e0 ff ff 8b 1e 0f 06 f6 43 0d 20 75 07 89 d8 e8 ea 38 00 00 <0f> ae 8b 10 02 00 00 83 4e 0c 01 fe 83 8d 01 00 00 8b 1c 24 8b EIP: [<c0103d46>] math_state_restore+0x26/0x50 SS:ESP 0068:da813db0 note: md0_raid5[2795] exited with preempt_count 2 ---------------------------------------------------------------------- Comment By: Arya (aryairani) Date: 2009-01-21 09:19 Message: The previous post was with 0.8.0 daily. Here I tried again, creating a new array rather than reassembling like with the previous example. It seems to have worked? md: bind<loop0> md: bind<loop1> md: bind<loop2> md: bind<loop3> raid5: measuring checksumming speed 8regs : 1577.200 MB/sec 8regs_prefetch: 1398.800 MB/sec 32regs : 788.000 MB/sec 32regs_prefetch: 861.600 MB/sec raid5: using function: 8regs (1577.200 MB/sec) raid6: int32x1 323 MB/s raid6: int32x2 321 MB/s raid6: int32x4 277 MB/s raid6: int32x8 258 MB/s raid6: mmxx1 739 MB/s raid6: mmxx2 992 MB/s raid6: sse1x1 462 MB/s raid6: sse1x2 873 MB/s raid6: sse2x1 1012 MB/s raid6: sse2x2 1511 MB/s raid6: using algorithm sse2x2 (1511 MB/s) md: raid6 personality registered for level 6 md: raid5 personality registered for level 5 md: raid4 personality registered for level 4 raid5: device loop2 operational as raid disk 2 raid5: device loop1 operational as raid disk 1 raid5: device loop0 operational as raid disk 0 raid5: allocated 4196kB for md0 raid5: raid level 5 set md0 active with 3 out of 4 devices, algorithm 2 RAID5 conf printout: --- rd:4 wd:3 disk 0, o:1, dev:loop0 disk 1, o:1, dev:loop1 disk 2, o:1, dev:loop2 RAID5 conf printout: --- rd:4 wd:3 disk 0, o:1, dev:loop0 disk 1, o:1, dev:loop1 disk 2, o:1, dev:loop2 disk 3, o:1, dev:loop3 md: recovery of RAID array md0 md: minimum _guaranteed_ speed: 1000 KB/sec/disk. md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for recovery. md: using 128k window, over a total of 10176 blocks. md: md0: recovery done. RAID5 conf printout: --- rd:4 wd:4 disk 0, o:1, dev:loop0 disk 1, o:1, dev:loop1 disk 2, o:1, dev:loop2 disk 3, o:1, dev:loop3 Works ok with cobdX devices, I don't know why it crashed the firs time? ---------------------------------------------------------------------- Comment By: Arya (aryairani) Date: 2009-01-21 08:55 Message: Bad news, md: md0 stopped. md: bind<loop1> md: bind<loop2> md: bind<loop3> md: bind<loop0> md: md0 stopped. md: unbind<loop0> md: export_rdev(loop0) md: unbind<loop3> md: export_rdev(loop3) md: unbind<loop2> md: export_rdev(loop2) md: unbind<loop1> md: export_rdev(loop1) md: bind<loop1> md: bind<loop2> md: bind<loop3> md: bind<loop0> raid5: measuring checksumming speed 8regs : 1292.800 MB/sec 8regs_prefetch: 1210.400 MB/sec 32regs : 1184.000 MB/sec 32regs_prefetch: 1428.800 MB/sec raid5: using function: 32regs_prefetch (1428.800 MB/sec) raid6: int32x1 605 MB/s raid6: int32x2 563 MB/s raid6: int32x4 444 MB/s raid6: int32x8 424 MB/s raid6: mmxx1 1355 MB/s raid6: mmxx2 1579 MB/s raid6: sse1x1 758 MB/s raid6: sse1x2 1541 MB/s raid6: sse2x1 1667 MB/s colinux-console-nt only shows this much, which is missing the registers / EIP dump... [<c0103c79>] show_stack_log_lvl+0xa9/0xd0 [<c01040eb>] show_registers+0x21b/0x3a0 [<c0104365>] die+0xf5/0x210 [<c010b6cc>] do_page_fault+0x38c/0x6e0 [<c03057fa>] error_code+0x6a/0x70 [<c010c5c8>] deactivate_task+0x18/0x30 [<c03035d7>] __sched_text_start+0x377/0x670 [<c0114814>] do_exit+0x7f4/0x960 [<c010447d>] die+0x20d/0x210 [<c010b6cc>] do_page_fault+0x38c/0x6e0 [<c03057fa>] error_code+0x6a/0x70 [<c010c5c8>] deactivate_task+0x18/0x30 [<c03035d7>] __sched_text_start+0x377/0x670 [<c0114814>] do_exit+0x7f4/0x960 [<c010447d>] die+0x20d/0x210 [<c010b6cc>] do_page_fault+0x38c/0x6e0 [<c03057fa>] error_code+0x6a/0x70 [<c010c5c8>] deactivate_task+0x18/0x30 [<c03035d7>] __sched_text_start+0x377/0x670 [<c0114814>] do_exit+0x7f4/0x960 [<c010447d>] die+0x20d/0x210 [<c010b6cc>] do_page_fault+0x38c/0x6e0 [<c03057fa>] error_code+0x6a/0x70 [<c010c5c8>] deactivate_task+0x18/0x30 ---------------------------------------------------------------------- Comment By: Arya (aryairani) Date: 2009-01-21 00:29 Message: Excellent, thanks for tracking that down, henryn. I'll test the daily tomorrow, with the temporary fix, if it will still help? ---------------------------------------------------------------------- Comment By: Henry N. (henryn) Date: 2009-01-20 23:31 Message: Loading and unloading a special version of module "raid456.ko" with only calling the function "calibrate_xor_block" does exactly your results: Crashing in math_state_restore, lots of page faults, and windows can not shutting down. ---------------------------------------------------------------------- Comment By: Henry N. (henryn) Date: 2009-01-20 22:53 Message: I assume, that the "pIII_sse" use a special register, we not have saved and restored in the passage page. That can crash the "math_state_restore". One option would be to support these xmm-registers for "sse", but currently I don't have idea how. The problem can be near the XMMS_SAVE/XMMS_RESTORE in top of include/asm-i386/xor.h: #define XMMS_SAVE do { \ preempt_disable(); \ cr0 = read_cr0(); \ clts(); \ These operations are well known candidate for crash and for endless page faults. Same we know from function math_state_restore in arch/i386/traps.c. A "clts" while hardware interrupts are enabled can crash coLinux. maniputating the register cr0 is also a high risk. The function "xor_block_pIII_sse" with special macros XMMS_SAVE/XMMS_RESTORE needs to check separately in a kernel test module, outside of the raid. Think, there needs something to do. As temporally idea have disabled the usage of xmm- and mmx-registers under coLinux for the xor-raid-functions. Please check the next autobuild. ---------------------------------------------------------------------- Comment By: Arya (aryairani) Date: 2009-01-20 21:09 Message: The 100% cpu crash seems reproducible if the cobd array is the first one I try to create that boot (i.e. the modules are being loaded for the first time?) Also (though not verified), I get the 100% cpu crash when making an array based on loop block devices if the loop devices are created to point to files using relative paths rather than absolute? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2524658&group_id=98788 |
|
From: SourceForge.net <no...@so...> - 2009-03-17 12:57:57
|
Bugs item #2688891, was opened at 2009-03-16 17:36 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2688891&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Using pcap/ndis bridge can't connent to colinux services Initial Comment: Hi, i've upgraded my really old colinux install to the lastest develoment snapshot (20090315 and 20090305 for modules and kernel). Trying to setup networking i've seen that using pcap-bridge or ndis-bridge doesn't let me to connect to the colinux machine: - if i try to do a ping from colinux to host machine all goes ok - if i try to do a ping from my host machine to colinux all goes ok - if i try to download something from the web server that resides on host machine or from internet trought colinux (using wget for example) all goes ok - if i try to connect to a netcat server or an openssh server that resieds on colinux from the host machine it doesn't do anything. - if i try to connect to a netcat server or an openssh server that resides on colinux from a machine in the lan all goes ok Doing more tests revealed that the problem is with TCP packets because i tried to set up a netcat udp server on port 53 and testing it trought nslookup shows that colinux machine recived the request. I get the same problem using ndis-bridge and using pcap-bridge: from kernel messages all seems to be ok! ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-03-17 12:57 Message: Really thanks! But, just a question: where i could look to fix checksum calculation? into conet module or into ndis/pcap-bridge daemon? ---------------------------------------------------------------------- Comment By: Henry N. (henryn) Date: 2009-03-16 20:17 Message: That should be simple. I have the same symptom on my Intel PCI-Express. My card is a "Realtek RTL8102E Family PCI-E Fast Ethernet NIC". I can not connect via ssh from Host to coLinux. tcpdump on coLinux or Wireshark on Windows let's see the problem: The card does not accept packets with checksum errors. To make it usable, go into network card "Hardware options" - "Extensions" - Properties: "Checksum" - and change the Value into "Disable". Here is an example session of ssh connect from host to coLinux (the failed case). tcpdump on coLinux: 20:44:36.847616 arp who-has 192.168.2.100 tell 192.168.2.104 20:44:36.847616 arp reply 192.168.2.100 is-at 00:21:85:56:fb:35 20:44:41.647688 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: TCP (6), length: 48) 192.168.2.104.22 > 192.168.2.100.1057: S, cksum 0xabbc (correct), 1094183181:1094183181(0) ack 309852530 win 5840 20:44:41.657689 IP (tos 0x0, ttl 128, id 434, offset 0, flags [DF], proto: TCP (6), length: 40) 192.168.2.100.1057 > 192.168.2.104.22: ., cksum 0x8637 (incorrect (-> 0xef50), ack 1 win 65535 20:44:53.647869 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: TCP (6), length: 48) 192.168.2.104.22 > 192.168.2.100.1057: S, cksum 0xabbc (correct), 1094183181:1094183181(0) ack 309852530 win 5840 20:44:53.647869 IP (tos 0x0, ttl 128, id 435, offset 0, flags [DF], proto: TCP (6), length: 40) 192.168.2.100.1057 > 192.168.2.104.22: ., cksum 0x8637 (incorrect (-> 0xef50), ack 1 win 65535 The same output with Wireshark on Windows: 6 5.016498 00:ff:99:88:b0:00 00:21:85:56:fb:35 ARP Who has 192.168.2.100? Tell 192.168.2.104 7 5.016521 00:21:85:56:fb:35 00:ff:99:88:b0:00 ARP 192.168.2.100 is at 00:21:85:56:fb:35 8 9.829057 192.168.2.104 192.168.2.100 TCP ssh > startron [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 9 9.829114 192.168.2.100 192.168.2.104 TCP [TCP Dup ACK 3#2] startron > ssh [ACK] Seq=1 Ack=1 Win=65535 [TCP CHECKSUM INCORRECT] Len=0 10 21.814002 192.168.2.104 192.168.2.100 TCP ssh > startron [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 11 21.814062 192.168.2.100 192.168.2.104 TCP [TCP Dup ACK 3#3] startron > ssh [ACK] Seq=1 Ack=1 Win=65535 [TCP CHECKSUM INCORRECT] Len=0 I leave this bug opened, because it would be nicer to calculate the checksum before submit it into the windows network stack. Disable the receiver is a workaround. ---------------------------------------------------------------------- Comment By: daniele_dll (daniele_dll) Date: 2009-03-16 17:45 Message: Note: when i upgraded i've launched the necessary remove/install driver as requested in readme file ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2688891&group_id=98788 |
|
From: SourceForge.net <no...@so...> - 2009-03-16 20:17:48
|
Bugs item #2688891, was opened at 2009-03-16 18:36 Message generated for change (Comment added) made by henryn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2688891&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Using pcap/ndis bridge can't connent to colinux services Initial Comment: Hi, i've upgraded my really old colinux install to the lastest develoment snapshot (20090315 and 20090305 for modules and kernel). Trying to setup networking i've seen that using pcap-bridge or ndis-bridge doesn't let me to connect to the colinux machine: - if i try to do a ping from colinux to host machine all goes ok - if i try to do a ping from my host machine to colinux all goes ok - if i try to download something from the web server that resides on host machine or from internet trought colinux (using wget for example) all goes ok - if i try to connect to a netcat server or an openssh server that resieds on colinux from the host machine it doesn't do anything. - if i try to connect to a netcat server or an openssh server that resides on colinux from a machine in the lan all goes ok Doing more tests revealed that the problem is with TCP packets because i tried to set up a netcat udp server on port 53 and testing it trought nslookup shows that colinux machine recived the request. I get the same problem using ndis-bridge and using pcap-bridge: from kernel messages all seems to be ok! ---------------------------------------------------------------------- >Comment By: Henry N. (henryn) Date: 2009-03-16 21:17 Message: That should be simple. I have the same symptom on my Intel PCI-Express. My card is a "Realtek RTL8102E Family PCI-E Fast Ethernet NIC". I can not connect via ssh from Host to coLinux. tcpdump on coLinux or Wireshark on Windows let's see the problem: The card does not accept packets with checksum errors. To make it usable, go into network card "Hardware options" - "Extensions" - Properties: "Checksum" - and change the Value into "Disable". Here is an example session of ssh connect from host to coLinux (the failed case). tcpdump on coLinux: 20:44:36.847616 arp who-has 192.168.2.100 tell 192.168.2.104 20:44:36.847616 arp reply 192.168.2.100 is-at 00:21:85:56:fb:35 20:44:41.647688 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: TCP (6), length: 48) 192.168.2.104.22 > 192.168.2.100.1057: S, cksum 0xabbc (correct), 1094183181:1094183181(0) ack 309852530 win 5840 20:44:41.657689 IP (tos 0x0, ttl 128, id 434, offset 0, flags [DF], proto: TCP (6), length: 40) 192.168.2.100.1057 > 192.168.2.104.22: ., cksum 0x8637 (incorrect (-> 0xef50), ack 1 win 65535 20:44:53.647869 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: TCP (6), length: 48) 192.168.2.104.22 > 192.168.2.100.1057: S, cksum 0xabbc (correct), 1094183181:1094183181(0) ack 309852530 win 5840 20:44:53.647869 IP (tos 0x0, ttl 128, id 435, offset 0, flags [DF], proto: TCP (6), length: 40) 192.168.2.100.1057 > 192.168.2.104.22: ., cksum 0x8637 (incorrect (-> 0xef50), ack 1 win 65535 The same output with Wireshark on Windows: 6 5.016498 00:ff:99:88:b0:00 00:21:85:56:fb:35 ARP Who has 192.168.2.100? Tell 192.168.2.104 7 5.016521 00:21:85:56:fb:35 00:ff:99:88:b0:00 ARP 192.168.2.100 is at 00:21:85:56:fb:35 8 9.829057 192.168.2.104 192.168.2.100 TCP ssh > startron [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 9 9.829114 192.168.2.100 192.168.2.104 TCP [TCP Dup ACK 3#2] startron > ssh [ACK] Seq=1 Ack=1 Win=65535 [TCP CHECKSUM INCORRECT] Len=0 10 21.814002 192.168.2.104 192.168.2.100 TCP ssh > startron [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 11 21.814062 192.168.2.100 192.168.2.104 TCP [TCP Dup ACK 3#3] startron > ssh [ACK] Seq=1 Ack=1 Win=65535 [TCP CHECKSUM INCORRECT] Len=0 I leave this bug opened, because it would be nicer to calculate the checksum before submit it into the windows network stack. Disable the receiver is a workaround. ---------------------------------------------------------------------- Comment By: daniele_dll (daniele_dll) Date: 2009-03-16 18:45 Message: Note: when i upgraded i've launched the necessary remove/install driver as requested in readme file ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2688891&group_id=98788 |
|
From: SourceForge.net <no...@so...> - 2009-03-16 17:45:42
|
Bugs item #2688891, was opened at 2009-03-16 18:36 Message generated for change (Comment added) made by daniele_dll You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2688891&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Using pcap/ndis bridge can't connent to colinux services Initial Comment: Hi, i've upgraded my really old colinux install to the lastest develoment snapshot (20090315 and 20090305 for modules and kernel). Trying to setup networking i've seen that using pcap-bridge or ndis-bridge doesn't let me to connect to the colinux machine: - if i try to do a ping from colinux to host machine all goes ok - if i try to do a ping from my host machine to colinux all goes ok - if i try to download something from the web server that resides on host machine or from internet trought colinux (using wget for example) all goes ok - if i try to connect to a netcat server or an openssh server that resieds on colinux from the host machine it doesn't do anything. - if i try to connect to a netcat server or an openssh server that resides on colinux from a machine in the lan all goes ok Doing more tests revealed that the problem is with TCP packets because i tried to set up a netcat udp server on port 53 and testing it trought nslookup shows that colinux machine recived the request. I get the same problem using ndis-bridge and using pcap-bridge: from kernel messages all seems to be ok! ---------------------------------------------------------------------- Comment By: daniele_dll (daniele_dll) Date: 2009-03-16 18:45 Message: Note: when i upgraded i've launched the necessary remove/install driver as requested in readme file ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2688891&group_id=98788 |
|
From: SourceForge.net <no...@so...> - 2009-03-16 17:36:33
|
Bugs item #2688891, was opened at 2009-03-16 17:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2688891&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Using pcap/ndis bridge can't connent to colinux services Initial Comment: Hi, i've upgraded my really old colinux install to the lastest develoment snapshot (20090315 and 20090305 for modules and kernel). Trying to setup networking i've seen that using pcap-bridge or ndis-bridge doesn't let me to connect to the colinux machine: - if i try to do a ping from colinux to host machine all goes ok - if i try to do a ping from my host machine to colinux all goes ok - if i try to download something from the web server that resides on host machine or from internet trought colinux (using wget for example) all goes ok - if i try to connect to a netcat server or an openssh server that resieds on colinux from the host machine it doesn't do anything. - if i try to connect to a netcat server or an openssh server that resides on colinux from a machine in the lan all goes ok Doing more tests revealed that the problem is with TCP packets because i tried to set up a netcat udp server on port 53 and testing it trought nslookup shows that colinux machine recived the request. I get the same problem using ndis-bridge and using pcap-bridge: from kernel messages all seems to be ok! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2688891&group_id=98788 |
|
From: coLinux a. <col...@he...> - 2009-03-16 05:07:18
|
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-20090315/ colinux-0.8.0-20090315.src.tgz (685048 Bytes) daemons-0.8.0-20090315.dbg.zip (590784 Bytes) daemons-0.8.0-20090315.zip (477577 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-20090305/ 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.1.2. A service from http://gcc.gnu.org/wiki/CompileFarm -- Lots of fun with newest version, Henry Nestler ------------------------------------------------------------------------ r1236 | henryn | 2009-03-15 20:48:51 +0000 (Sun, 15 Mar 2009) | 1 line Changed paths: M /branches/devel/src/colinux/os/winnt/user/conet-bridged-daemon/main.c * Small typofix in text output. ------------------------------------------------------------------------ r1235 | henryn | 2009-03-15 17:41:18 +0000 (Sun, 15 Mar 2009) | 2 lines Changed paths: M /branches/devel/src/colinux/os/winnt/user/console/head.cpp M /branches/devel/src/colinux/os/winnt/user/console-nt/widget.cpp * Fixup console switching and better handling for ALT and CTRL keys (replacement for SVN r1219, contributed by Vladislav Grishenko) ------------------------------------------------------------------------ |
|
From: Henry N. <hen...@ar...> - 2009-03-15 21:14:50
|
Hello Bill, At 05.03.2009 00:55, wrote Doctor Bill: > Looks like it is not timing errors. With local file, the SCSI driver > is consistently bombing at about 27%. That is pretty close to the > 1GiB boundary, so if there is any math performed on this position > value, it could be integer overflow. > > Bill you are right with problems near 1GB limit. I have configured a 3.1GB iso image file and also have tested as cdrom directly. Both stops reading after 1073741312 (0x3FFFFE00) bytes. Configured as scsi1=cdrom,C:\Fedora.iso or scsi1=cdrom,\Device\Cdrom0 Inside coLinux: debian:~# dd if=/dev/sr0 | md5sum d2546596e7b2378388c14c0cff6a8fe1 - 2097151+0 records in 2097151+0 records out 1073741312 bytes (1.1 GB) copied, 216.493 seconds, 5.0 MB/s My idea was to check corrupted data between the iso-file and the sr0-device driver. But it fails before it was finish. This error will be find. -- Henry N. |
|
From: Henry N. <hen...@ar...> - 2009-03-15 18:58:28
|
Am 15.03.2009 03:42, schrieb Chun-Yu Shei: > I recently made the switch to a Mac, and miss having a full Gnome+XMonad > environment around (Gnome from MacPorts isn't fully working here). I > tried the Parallels/VMWare/VirtualBox thing for a while, but didn't > really like any of them, and I just remembered this little project > called coLinux today. > > So as my spring break starts, I'm left wondering how difficult it would > be to port coLinux to the Mac. It already runs on Linux and Windows, so > it can't be *that* hard, right? Any thoughts on this? Monsti has started to build some, here is his summary: http://colinux.wikia.com/wiki/OSXPort -- Henry N. |
|
From: Henry N. <hen...@ar...> - 2009-03-15 17:43:17
|
Hello Vladislav, theMIROn wrote: > That was not enough, coz console-nt doesn't handle AltGr. > Moreover, current console-fltk implementation of AltGr handling sends LCtrl > release even if there's no AltGr (just right Alt) and LCtrl wasn't at > pressed state, and/or RCtrl was pressed before. > So, here's joined patch > http://www.nabble.com/file/p22518208/console-nt-fix-sticky-alt-shift-altgr.patch > console-nt-fix-sticky-alt-shift-altgr.patch thank you. Committed to SVN as revision 1235. -- Henry N. |
|
From: Chun-Yu S. <cs...@cs...> - 2009-03-15 03:32:16
|
I recently made the switch to a Mac, and miss having a full Gnome+XMonad environment around (Gnome from MacPorts isn't fully working here). I tried the Parallels/VMWare/VirtualBox thing for a while, but didn't really like any of them, and I just remembered this little project called coLinux today. So as my spring break starts, I'm left wondering how difficult it would be to port coLinux to the Mac. It already runs on Linux and Windows, so it can't be *that* hard, right? Any thoughts on this? Chun-Yu |
|
From: theMIROn <the...@ma...> - 2009-03-14 23:04:16
|
That was not enough, coz console-nt doesn't handle AltGr. Moreover, current console-fltk implementation of AltGr handling sends LCtrl release even if there's no AltGr (just right Alt) and LCtrl wasn't at pressed state, and/or RCtrl was pressed before. So, here's joined patch http://www.nabble.com/file/p22518208/console-nt-fix-sticky-alt-shift-altgr.patch console-nt-fix-sticky-alt-shift-altgr.patch -- View this message in context: http://www.nabble.com/Alt%2BKEY-colinux-console-nt-processing-tp22497491p22518208.html Sent from the colinux-devel mailing list archive at Nabble.com. |
|
From: Vladislav G. <the...@ma...> - 2009-03-13 14:22:30
|
Hello, I've noticed that there's no switching into another virtual console on Alt+F2 (F3 etc) in case of using colinux-console-nt.exe from recent coLinux snapshoot 20090305 of version 0.8.0 with kernel 2.6.22.18, compiled with gcc 4.2.1 After some research it seems console sends unexpected left Alt key release on next keycombo keypress while Alt is pressed. The reason is rev.1219 "Fix sticky Alt or Shift after system menu from Alt-Space (nt console)" Here's the patch to solve the prob Best Regards, theMIROn |
81 messages has been excluded from this view by a project administrator.
