You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(100) |
Jun
(134) |
Jul
(149) |
Aug
(123) |
Sep
(185) |
Oct
(122) |
Nov
(59) |
Dec
(127) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
(128) |
Feb
(233) |
Mar
(210) |
Apr
(196) |
May
(85) |
Jun
(96) |
Jul
(76) |
Aug
(149) |
Sep
(65) |
Oct
(78) |
Nov
(121) |
Dec
(82) |
2006 |
Jan
(249) |
Feb
(181) |
Mar
(176) |
Apr
(156) |
May
(128) |
Jun
(102) |
Jul
(157) |
Aug
(80) |
Sep
(42) |
Oct
(49) |
Nov
(36) |
Dec
(42) |
2007 |
Jan
(64) |
Feb
(38) |
Mar
(45) |
Apr
(74) |
May
(26) |
Jun
(20) |
Jul
(17) |
Aug
(12) |
Sep
(40) |
Oct
(7) |
Nov
(14) |
Dec
(16) |
2008 |
Jan
(52) |
Feb
(49) |
Mar
(90) |
Apr
(80) |
May
(78) |
Jun
(82) |
Jul
(25) |
Aug
(8) |
Sep
(10) |
Oct
(11) |
Nov
(3) |
Dec
(17) |
2009 |
Jan
(12) |
Feb
(16) |
Mar
(20) |
Apr
(14) |
May
(17) |
Jun
(10) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(10) |
Nov
(30) |
Dec
(1) |
2010 |
Jan
(2) |
Feb
(7) |
Mar
(22) |
Apr
(6) |
May
(33) |
Jun
(5) |
Jul
(4) |
Aug
(38) |
Sep
(46) |
Oct
(23) |
Nov
(9) |
Dec
(5) |
2011 |
Jan
(21) |
Feb
(27) |
Mar
(1) |
Apr
(18) |
May
(12) |
Jun
(12) |
Jul
(10) |
Aug
(30) |
Sep
(4) |
Oct
|
Nov
(9) |
Dec
(19) |
2012 |
Jan
(26) |
Feb
(6) |
Mar
(8) |
Apr
(7) |
May
(3) |
Jun
|
Jul
(10) |
Aug
(1) |
Sep
(18) |
Oct
(5) |
Nov
|
Dec
(1) |
2013 |
Jan
(27) |
Feb
|
Mar
(11) |
Apr
(14) |
May
|
Jun
(1) |
Jul
|
Aug
(7) |
Sep
|
Oct
(1) |
Nov
(2) |
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
(25) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
(2) |
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2025 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Clemens E. <lin...@gm...> - 2011-02-09 20:44:03
|
Hi, Will coLinux attend the Google Summer of Code? Do you think porting coLinux to Windows-x64 would be a suitable project for GSoC? Thanks, Clemens |
From: Kevin H. <har...@ya...> - 2011-02-09 18:12:09
|
Is there any way to configure slirp so that it can allow the host to see the vm? Thanks. |
From: qnx4ever <qnx...@gm...> - 2011-02-09 17:31:45
|
You can specify port forwarding in colinux.conf file, e.g. for ssh eth0=slirp,,tcp:22:22 On 9 February 2011 15:06, <col...@li...> wrote: > Send coLinux-users mailing list submissions to > col...@li... > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/colinux-users > or, via email, send a message with subject or body 'help' to > col...@li... > > You can reach the person managing the list at > col...@li... > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of coLinux-users digest..." > > > Today's Topics: > > 1. Colinux network 2 way comm question (Kevin Hardiek) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 8 Feb 2011 08:50:57 -0800 (PST) > From: Kevin Hardiek <har...@ya...> > Subject: [coLinux-users] Colinux network 2 way comm question > To: col...@li... > Message-ID: <858...@we...> > Content-Type: text/plain; charset="us-ascii" > > I am a newly registered member and I have just installed colinux onto Windows XP > which is working great with slirp. I know that slirp is great for one way comm, > but I am needing 2 way comm. > > > What is the best way to set up 2 way comm between my XP host and the Colinux > Ubuntu Install I have setup? I am developing a website using LAMP which will be > installed onto the Colinux Ubuntu Install. I want to test the LAMP via > browsers in XP. What is the best way to set this up? > > > Thanks. > > Kevin > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > > ------------------------------ > > _______________________________________________ > coLinux-users mailing list > coL...@li... > https://lists.sourceforge.net/lists/listinfo/colinux-users > > > End of coLinux-users Digest, Vol 58, Issue 5 > ******************************************** > |
From: Kevin H. <har...@ya...> - 2011-02-08 16:51:04
|
I am a newly registered member and I have just installed colinux onto Windows XP which is working great with slirp. I know that slirp is great for one way comm, but I am needing 2 way comm. What is the best way to set up 2 way comm between my XP host and the Colinux Ubuntu Install I have setup? I am developing a website using LAMP which will be installed onto the Colinux Ubuntu Install. I want to test the LAMP via browsers in XP. What is the best way to set this up? Thanks. Kevin |
From: Henry N. <hen...@ar...> - 2011-02-07 20:12:04
|
Hello, the "bs=512 skip=63" depents on the size of boot sectors. It is not the same in all cases. Under Linux you can check the consistens of your image. For example the command "file foo.dat" should detect your file as "filesystem data" and should print the used filesystem (ext3, Reisser or so). Remember, that ReisserFs and ext4 is not compiled in in all coLinux kernels. So it can be your problem here. Rootfilesystems for coLinux should be formated with ext3 Second check: You can mount the file as loop: mount -o loop,ro foo.dat /mnt If that works, your Image file is ok. If the loop does not mount, then the image file is corrupt. A safer way to create such image: Create an additional big disk (vdi), that is 10% or more than the disk you wand to copy. Run Xubuntu Format the new disk with ext2 (ext2 has less overhead as ext3/4 or Reisser) Reboot Xubuntu in a maintaince text mode or single user mode. I don't know exactly how it is named in Ubuntu. But it should be a mode with less of all startup and no X11 running. Mount your new disk, for example to mount point /mnt. Try to mount the root filesystem to readonly. If that not can it is no big problem. But it would be better. Now make a raw backup from your root filesystem. Is your rootfilesystem is on device /dev/sda1, you shoult run a comman like: dd if=/dev/sda1 of=/mnt/MyRawImage.img This make a while. Wait to finish, and copy the file "MyRawImage.img" to your Windows. If you not have enough disk space, you can compress the image file: dd if=/dev/sda1 | bzip2 > /mnt/MyRawImage.img.bz2 -- Henry On 05.02.2011 18:22, 卍\(^o^)/卐 wrote: > Hello, I'm a new baby to coLinux. Thanks for your wonderful job! > now, i have some trouble in creating disk image! > here is my steps: > > first, I installed a xubuntu system in VirtualBox(my host OS is Windows7) > second, I turn off the Virtual machine, using VBoxManage.exe covert the "vdi" disk file to RAW format > third, I use dd coverting the RAW image with para "bs=512 skip=63" > > could you tell me whether these steps has something wrong? And How to make rootfs image? > > wish to hear from you ! > > Happy new year! > > Err info: > VFS: Mounted root (ext2 filesystem) on device1:0. =========================================================================== # This process will install (if necessary) the coLinux modules for the # coLinux kernel. input: AT Translated Set 2 keyboard as /devices/serio0/input/input0 =========================================================================== Determining /, Found. Mounting / EXT3-fs (cobd0): error: can't find ext3 filesystem on dev cobd0. EXT2-fs (cobd0): error: can't find an ext2 filesystem on dev cobd0. EXT4-fs (cobd0): VFS: Can't find ext4 filesystem ISOFS: Unable to identify CD-ROM format. mount: Mounting /dev/cobd0 on /mnt/linux failed: Invalid argument List of all partitions: 7500 4194272 cobd0 (driver?) No filesystem could mount root, tried: ext3 ext2 ext4 iso9660 Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(117,0)Pid: 1, comm: swapper Not tainted 2.6.33.5-co-0.7.8 #1 Call Trace: > [<c122f6af>] ? printk+0x18/0x21 [<c122f681>] panic+0x4e/0x64 [<c12eea9c>] mount_block_root+0x242/0x254 [<c108dac7>] ? sys_mknod+0x27/0x30 [<c12ee0c7>] ? kernel_init+0x0/0xea [<c12eeb07>] mount_root+0x59/0x5f [<c12ef66f>] initrd_load+0x277/0x38c [<c12ee0c7>] ? kernel_init+0x0/0xea [<c12eebcb>] prepare_namespace+0xbe/0x183 [<c1080d40>] ? sys_access+0x20/0x30 > > thanks > > |
From: 卍\(^o^)/卐 <gol...@qq...> - 2011-02-05 17:22:51
|
Hello, I'm a new baby to coLinux. Thanks for your wonderful job! now, i have some trouble in creating disk image! here is my steps: first, I installed a xubuntu system in VirtualBox(my host OS is Windows7) second, I turn off the Virtual machine, using VBoxManage.exe covert the "vdi" disk file to RAW format third, I use dd coverting the RAW image with para "bs=512 skip=63" could you tell me whether these steps has something wrong? And How to make rootfs image? wish to hear from you ! Happy new year! Err info: VFS: Mounted root (ext2 filesystem) on device1:0. =========================================================================== # This process will install (if necessary) the coLinux modules for the # coLinux kernel. input: AT Translated Set 2 keyboard as /devices/serio0/input/input0 =========================================================================== Determining /, Found. Mounting / EXT3-fs (cobd0): error: can't find ext3 filesystem on dev cobd0. EXT2-fs (cobd0): error: can't find an ext2 filesystem on dev cobd0. EXT4-fs (cobd0): VFS: Can't find ext4 filesystem ISOFS: Unable to identify CD-ROM format. mount: Mounting /dev/cobd0 on /mnt/linux failed: Invalid argument List of all partitions: 7500 4194272 cobd0 (driver?) No filesystem could mount root, tried: ext3 ext2 ext4 iso9660 Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(117,0)Pid: 1, comm: swapper Not tainted 2.6.33.5-co-0.7.8 #1 Call Trace: [<c122f6af>] ? printk+0x18/0x21 [<c122f681>] panic+0x4e/0x64 [<c12eea9c>] mount_block_root+0x242/0x254 [<c108dac7>] ? sys_mknod+0x27/0x30 [<c12ee0c7>] ? kernel_init+0x0/0xea [<c12eeb07>] mount_root+0x59/0x5f [<c12ef66f>] initrd_load+0x277/0x38c [<c12ee0c7>] ? kernel_init+0x0/0xea [<c12eebcb>] prepare_namespace+0xbe/0x183 [<c1080d40>] ? sys_access+0x20/0x30 thanks |
From: Clemens E. <lin...@gm...> - 2011-02-02 04:33:54
|
Hi Henry, > Yes, of curse, inside Linux kernel you have full access to all files. On the > Windows side you needs to implement a virtual file-system driver. > >> - How could IPC be done between my driver-kernel-module and the linux >> kernel? > > Inside coLinux we have a message queue with destination direct to the driver > or userland on both OS sides. So you can post messages from Linux to Windows > and from Windows to Linux. A message contains a command, controls and data. > For big data (>4K) we use shared memory, so you not need to copy memory. Excellent, coLinux offers more than I've could hoped =) Now I "only" need to find an university professor to sponsor this master thesis, I fear this will be the hard part. Once that step is done, I guess I need to install windows and try to get a working build environment ;) >> - Are there plans to support newer linux kernel releases too? > Here you needs to wait a half year or mor. Or try self to import the current > patches to a newer kernel version. As long as there are updates from time to time, it shouldn't matter that much. Thanks again, Clemens |
From: Henry N. <hen...@ar...> - 2011-02-01 21:37:23
|
On 01.02.2011 15:05, Clemens Eisserer wrote: > I currently evaluating the possibility of writing a file-system-driver > (ifs) for windows that internally uses a virtualized linux kernel to > read the files. > CoLinux seems to be the most promising (and least resource intensive) > way to run a linux-kernel. > > - Would it be possible to use coLinux as basis for this project? Yes, of curse, inside Linux kernel you have full access to all files. On the Windows side you needs to implement a virtual file-system driver. > - How could IPC be done between my driver-kernel-module and the linux kernel? Inside coLinux we have a message queue with destination direct to the driver or userland on both OS sides. So you can post messages from Linux to Windows and from Windows to Linux. A message contains a command, controls and data. For big data (>4K) we use shared memory, so you not need to copy memory. > - Are there plans to support newer linux kernel releases too? Here you needs to wait a half year or mor. Or try self to import the current patches to a newer kernel version. -- Henry N. |
From: Clemens E. <lin...@gm...> - 2011-02-01 18:24:30
|
Hi Carsten, > CoLinux is a 0.x-Version, it doesn't run on x64 Windows versions for example, > it only uses one cpu core, etc. Yes, the missing amd64 support hurts most, the need for patched kernel's is not a problem, as long as there are new kernels available from time to time ;) On the pro side compared to full-blown Virtualization-Environments are: - Able to run in kernel-space, no need to switch arround like mad between user/kernel space - Open-Source and gui-less, all other full-blown VMs are closed-source and cannot be easily made gui-less or shipped as part of my driver. - Small footprint. At least I am not willed to trade 128mb ram just to access my ext4/btrfs file system ;) >> - How could IPC be done between my driver-kernel-module and the linux kernel? > TCP-Connection to windows Is there no other way? Since I am in kernel-space, I could run the ifs-driver code in the same kernel-thread as coLinux. I guess the networking code/glue code should show how it is beeing done. > As far as I know one Colinux version matches 1-2 kernel versions that are able to run. > If you want a new kernel you have to wait for a new Colinux version. Thats no big problem, as long as new versions keep coming =) Thanks, Clemens |
From: Clemens E. <lin...@gm...> - 2011-02-01 14:05:18
|
Hi, I currently evaluating the possibility of writing a file-system-driver (ifs) for windows that internally uses a virtualized linux kernel to read the files. CoLinux seems to be the most promising (and least resource intensive) way to run a linux-kernel. - Would it be possible to use coLinux as basis for this project? - How could IPC be done between my driver-kernel-module and the linux kernel? - Are there plans to support newer linux kernel releases too? Thank you in advance, Clemens |
From: Henry N. <hen...@ar...> - 2011-01-31 23:17:58
|
On 31.01.2011 05:59, Arturo R. wrote: > On Sun, Jan 30, 2011 at 1:14 PM, Henry Nestler wrote: >> nice, you have found a bug inside libc or with SSE2. Google for this text >> "segfault in multiarch string function (__strlen_sse2)" and you will find >> many of these bugs. Mostly not solved or not reproduce later. > This one on Ubuntu's Launchpad looked specially attractive, since it > includes a test case. Alas, I don't know how to compile/use the test > case. There is a foo.cc file, but when I try to compile it, it > complains about missing foo.h, which isn't in the tar archive. > > https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/544109 This test is for testing "cpp", that produced the bug while cpmpiling this code snip. This is not a source to create a test. >> Maybe we have a problem with FPU save/restore code for SSE2 instructions >> inside coLinux? >> Here you need to find a testcase, that produce code like "pxor %xmm0, >> %xmm0". Run this under coLinux to check it. > Can you point me in the right direction of how to do this? A simple .c > program that runs strlen on a string doesn't seem to be calling the > assembly optimized code, and if it is, it's not causing a crash. No, sorry I don't have such, and I also not found any usable code. >> Boot coLinux with kernel option "nofxsr". This should disable all MMX and >> SSE/SSE2 instructions. > I tried it, but coLinux just crashes (coLinux .log and .conf > attached). I have tested "nofxsr" on my machine and it has no effect. It's normal working. No crashing. Maybe an other use with same Intel U7300 can check the usage of "nofxsr" udner coLinux. > Should I try with a development snapshot? This would do no matter here. > Do you think it makes sense to file a bug report for the Debian > package at this point? Only, if you can reproduce this under native Linux, for example with debian boot cdrom and the kernel parameter "nofxsr". -- Henry N. |
From: Henry N. <hen...@ar...> - 2011-01-31 21:47:26
|
On 31.01.2011 06:21, Arturo R. wrote: > > C:\coLinux>colinux-daemon.exe @debian-dev.conf > Cooperative Linux Daemon, 0.7.8 > Daemon compiled on Wed Sep 1 22:59:30 2010 > > PID: 372 > colinux: booting > Linux version 2.6.33.5-co-0.7.8 (hn@hn-dt) (gcc version 4.4.1 [gcc-4_4-branch revision 150839] (SUSE Linux) ) #1 PREEMPT Wed Sep 1 22:49:51 UTC 2010 > > [...snip...] > > Kernel command line: root=/dev/cobd0 ro debug nofxsr > PID hash table entries: 2048 (order: 1, 8192 bytes) > Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) > Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) > Initializing CPU#0 > xsave/xrstor: enabled xstate_bv 0x3, cntxt size 0x240 > > [...snip...] > > CPU: Genuine Intel(R) CPU U7300 @ 1.30GHz stepping 0a > > [...snip...] > > VFS: Mounted root (ext3 filesystem) readonly on device 117:0. > Freeing unused kernel memory: 140k freed > kjournald starting. Commit interval 5 seconds > Kernel panic - not syncing: Attempted to kill init! > Pid: 1, comm: init Not tainted 2.6.33.5-co-0.7.8 #1 > Call Trace: > [<c122f6af>] ? printk+0x18/0x21 > [<c122f681>] panic+0x4e/0x64 > colinux: Linux VM terminated > colinux: Kernel panic: Attempted to kill init! Ok. You bootet kernel without support for sse2 and than init does not start or kills him self at very top. I can not exclude that coLinux has an error here. But I feel it is a bug with libc and sse2 detection. -- Henry N. |
From: Henry N. <hen...@ar...> - 2011-01-31 21:29:17
|
On 31.01.2011 07:24, Arturo R. wrote: >> I tried it, but coLinux just crashes (coLinux .log and .conf >> attached). Should I try with a development snapshot? No, not need. There are no changes on floating point. > > Tried downloading devel-coLinux-20110125.exe, but I'm getting a > truncated executable. > > <http://sourceforge.net/projects/colinux/files/Snapshots/devel-20110125-Snapshot/devel-coLinux-20110125.exe/download> Oh, yes I see too. The file on server is ok. But the server terminates after some bytes are loaded. It is a problem on SF. They have many problems currently. It begun with an attack Jan 27 last week. Read more ... https://sourceforge.net/apps/wordpress/sourceforge/ By the while the snapshot is available site: http://www.henrynestler.com/colinux/testing/devel-0.7.9/20110125-Snapshot/ -- Henry N. |
From: Paolo M. <pao...@gm...> - 2011-01-31 12:33:39
|
> Maybe we have a problem with FPU save/restore code for SSE2 instructions > inside coLinux? > Here you need to find a testcase, that produce code like "pxor %xmm0, > %xmm0". Run this under coLinux to check it. > > Boot coLinux with kernel option "nofxsr". This should disable all MMX and > SSE/SSE2 instructions. > > Henry Hi Henry and Arturo, If I remember correcly FXSAVE and FXRSTOR save and restore all FPU/MMX/SSE2 state. This problem seems very interesting ... Paolo |
From: Arturo R. <ja...@gm...> - 2011-01-31 06:24:49
|
> I tried it, but coLinux just crashes (coLinux .log and .conf > attached). Should I try with a development snapshot? Tried downloading devel-coLinux-20110125.exe, but I'm getting a truncated executable. <http://sourceforge.net/projects/colinux/files/Snapshots/devel-20110125-Snapshot/devel-coLinux-20110125.exe/download> -- Arturo R. |
From: Arturo R. <ja...@gm...> - 2011-01-31 05:21:50
|
> I tried it, but coLinux just crashes (coLinux .log and .conf > attached). Should I try with a development snapshot? Sorry, meant to attach this colinux.log -- Arturo R. |
From: Arturo R. <ja...@gm...> - 2011-01-31 04:59:56
|
Henry: On Sun, Jan 30, 2011 at 1:14 PM, Henry Nestler <hen...@ar...> wrote: > nice, you have found a bug inside libc or with SSE2. Google for this text > "segfault in multiarch string function (__strlen_sse2)" and you will find > many of these bugs. Mostly not solved or not reproduce later. This one on Ubuntu's Launchpad looked specially attractive, since it includes a test case. Alas, I don't know how to compile/use the test case. There is a foo.cc file, but when I try to compile it, it complains about missing foo.h, which isn't in the tar archive. https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/544109 > Please check, that your CPU supports SSE2. You can do it under native Linux, > or with knoppix by checking the flags from "/proc/cpuinfo". I think your > Intel has this. Yeah, looks like my CPU supports it (cpuinfo.log attached). > Maybe we have a problem with FPU save/restore code for SSE2 instructions > inside coLinux? > Here you need to find a testcase, that produce code like "pxor %xmm0, > %xmm0". Run this under coLinux to check it. Can you point me in the right direction of how to do this? A simple .c program that runs strlen on a string doesn't seem to be calling the assembly optimized code, and if it is, it's not causing a crash. > Boot coLinux with kernel option "nofxsr". This should disable all MMX and > SSE/SSE2 instructions. I tried it, but coLinux just crashes (coLinux .log and .conf attached). Should I try with a development snapshot? Do you think it makes sense to file a bug report for the Debian package at this point? Thank you. -- Arturo R. |
From: Henry N. <hen...@ar...> - 2011-01-30 21:14:35
|
Hello Arturo, nice, you have found a bug inside libc or with SSE2. Google for this text "segfault in multiarch string function (__strlen_sse2)" and you will find many of these bugs. Mostly not solved or not reproduce later. http://en.wikipedia.org/wiki/SSE2 Please check, that your CPU supports SSE2. You can do it under native Linux, or with knoppix by checking the flags from "/proc/cpuinfo". I think your Intel has this. Maybe we have a problem with FPU save/restore code for SSE2 instructions inside coLinux? Here you need to find a testcase, that produce code like "pxor %xmm0, %xmm0". Run this under coLinux to check it. Boot coLinux with kernel option "nofxsr". This should disable all MMX and SSE/SSE2 instructions. Henry On 30.01.2011 08:16, Arturo R. wrote: > New development. After I changed the way the kernel names the > coredumps, I realized that bash was also crashing on the exact same > function (__strlen_sse2 () at > ../sysdeps/i386/i686/multiarch/strlen.S:75). > > Armed with this information, I decided to remove the libc6-i686 > package and now the system no longer crashes when resuming from > standby. > > I would still love to help out in figuring out a proper fix, if you > Henry, or anyone else, would like to work with me. > > Thanks again. > > gdb-bash.log > > > root@colinux:~/src# gdb --quiet /bin/bash coredump.bash.1296369722 > Reading symbols from /bin/bash...done. > [New Thread 1592] > > warning: Can't read pathname for load map: Input/output error. > Reading symbols from /lib/libncurses.so.5...(no debugging symbols found)...done. > Loaded symbols for /lib/libncurses.so.5 > Reading symbols from /lib/i686/cmov/libdl.so.2...done. > Loaded symbols for /lib/i686/cmov/libdl.so.2 > Reading symbols from /lib/i686/cmov/libc.so.6...done. > Loaded symbols for /lib/i686/cmov/libc.so.6 > Reading symbols from /lib/ld-linux.so.2...done. > Loaded symbols for /lib/ld-linux.so.2 > Reading symbols from /lib/i686/cmov/libnss_compat.so.2...done. > Loaded symbols for /lib/i686/cmov/libnss_compat.so.2 > Reading symbols from /lib/i686/cmov/libnsl.so.1...done. > Loaded symbols for /lib/i686/cmov/libnsl.so.1 > Reading symbols from /lib/i686/cmov/libnss_nis.so.2...done. > Loaded symbols for /lib/i686/cmov/libnss_nis.so.2 > Reading symbols from /lib/i686/cmov/libnss_files.so.2...done. > Loaded symbols for /lib/i686/cmov/libnss_files.so.2 > Core was generated by `-bash'. > Program terminated with signal 11, Segmentation fault. > #0 __strlen_sse2 () at ../sysdeps/i386/i686/multiarch/strlen.S:75 > 75 pxor %xmm0, %xmm0 /* 16 null chars */ |
From: Arturo R. <ja...@gm...> - 2011-01-30 07:17:07
|
New development. After I changed the way the kernel names the coredumps, I realized that bash was also crashing on the exact same function (__strlen_sse2 () at ../sysdeps/i386/i686/multiarch/strlen.S:75). Armed with this information, I decided to remove the libc6-i686 package and now the system no longer crashes when resuming from standby. I would still love to help out in figuring out a proper fix, if you Henry, or anyone else, would like to work with me. Thanks again. -- Arturo R. |
From: Arturo R. <ja...@gm...> - 2011-01-29 16:20:44
|
Henry: On Thu, Jan 27, 2011 at 12:08 PM, Henry Nestler <hen...@ar...> wrote: > > On 27.01.2011 05:06, Arturo R. wrote: >> >> #4<signal handler called> >> #5 0xb75d5417 in ?? () from /lib/i686/cmov/libc.so.6 >> #6 0x08049f87 in print (s=0x804eb45 "\rINIT: ") at init.c:820 >> #7 0x0804a0ef in initlog (loglevel=1, >> s=0x804e854 "Id \"%s\" respawning too fast: disabled for %d minutes") >> at init.c:858 > > You should see the text 'INIT: Id "foo" respawning too fast: disabled for 5 > minutes'. > But the print self creates a segfault inside libc. > > Please locate the lines 820 to 858. Maybe the variable for the first %s has > no value or a wrong pointer. > > To see the called function in libc, can you build "init" with debug and all > libraries as static? Attached is a backtrace with all the libraries init uses built with debugging symbols, which gives the output I think you're looking for. I'm stumped by another thing though. I commented out the offending code from init.c and the system still hung, it just didn't print that message. Does that make sense? Thanks again for your help and patience. I'm learning a lot here that will help me debug these kinds of things in the future. -- Arturo R. |
From: Henry N. <hen...@ar...> - 2011-01-27 20:08:24
|
On 27.01.2011 05:06, Arturo R. wrote: > #4<signal handler called> > #5 0xb75d5417 in ?? () from /lib/i686/cmov/libc.so.6 > #6 0x08049f87 in print (s=0x804eb45 "\rINIT: ") at init.c:820 > #7 0x0804a0ef in initlog (loglevel=1, > s=0x804e854 "Id \"%s\" respawning too fast: disabled for %d minutes") > at init.c:858 You should see the text 'INIT: Id "foo" respawning too fast: disabled for 5 minutes'. But the print self creates a segfault inside libc. Please locate the lines 820 to 858. Maybe the variable for the first %s has no value or a wrong pointer. To see the called function in libc, can you build "init" with debug and all libraries as static? -- Henry N. |
From: Bill C R. <do...@gm...> - 2011-01-27 14:30:11
|
On 01/26/2011 06:26 PM, Henry Nestler wrote: > On 26.01.2011 18:19, Bill C Riemers wrote: >> Hi, >> >> It looks like most of the image builds for coLinux desperately need updating. For example, the last Fedora image I built was Fedora 10. Since Fedora 10 has been end-of-life for more than a year now, the scripts for installing gnome no-longer work. >> >> The problem of course is that coLinux does not support 64 bit operating systems. I retired my last 32 bit Windows machine 2 years ago. As such I am unable to run coLinux to build a newer image. >> >> So I have two requests: >> >> 1. Can we depreciate the links to the Fedora builds. I added a readme file to the image directory that tells users they are end of life, but since you have scroll down to see the readme, many users will probably waste time downloading the images before noticing the readme. > > I can rename the folder like "Fedora 10 (depreciate)". > Or I can move all folders into a subfolder "depreciate"? > > Fedora 11 exist here: > http://blog.gbraad.nl/2009/07/fedora-11-on-colinux.html Ironically, some of the older builds are probably more useful than this build. The fundamental problem is that sometime after the a release is end of life, the update repositories are cleared. e.g. http://mirror.cpsc.ucalgary.ca/mirror/fedora/linux/releases/ You'll see currently anything earlier than Fedora 12 is just directory structures and maybe a repo file with broken links. Some of the older Fedora builds might be useful, because they were non-minimal. Which means they might have the packages a person needs already installed. The Fedora 11 build is very minimal, so it is probably no more useful than a busybox system. A good lesson here, is it is probably a good idea to make sure Fedora builds have preupgrade installed on them, so at least they can be upgraded to a more current build after end of life. Of course, it is possible to upgrade the repositories by hand and upgrade with yum. But in the end it is probably about the same level of effort as doing a fresh image. Bill |
From: Arturo R. <ja...@gm...> - 2011-01-27 04:06:20
|
Hi Henry. On Wed, Jan 26, 2011 at 4:14 PM, Henry Nestler <hen...@ar...> wrote: > > You should have debug symbols for init, or an init with debug symbols. Than > you can load init into gdb and locate the code snip for address 0xb766d417, > or you can run "objdump -Dr /sbin/init >dump.txt" and find out the address > manually. The addr2line should also work for this. > Thank you very much for the reply. I guess I misspoke. When I said that the crash is reproducible all the time, I mean that putting the laptop to standby always causes init to crash, but the address given in the error message changes. I've rebuilt an sysvinit package with debug symbols and I can attach to it with gdb, but when the process crashes gdb becomes unresponsive too. I was able to get a coredump and I think I have a little more information about the crash this time, but I'm not sure how to interpret it. I've attached the output of gdb in case it's helpful to you or anybody else. Thanks again. -- Arturo R. |
From: Henry N. <hen...@ar...> - 2011-01-27 00:15:05
|
Hello Arturo, On 25.01.2011 18:46, Arturo R. wrote: > Running Debian sid on a coLinux 0.7.8 (uname -a: "Linux colinux > 2.6.33.5-co-0.7.8 #1 PREEMPT Wed Sep 1 22:49:51 UTC 2010 i686 > GNU/Linux") inside of Windows XP Pro SP3. The error is reproducible > 100% of the time. When the machine goes into standby, either > automatically or manually, init (or something else? see below), > crashes and takes the system down with it. > > I've read that gdb can't attach to init by design, so I tried strace. > Output is attached as strace.log > > Now, since I assumed the problem was with init, I switched to upstart, > but that's not working either. See upstart.log, attached. > > I've also ruled out coLinux (and with it, its kernel) by trying one of > the filesystem images they provide. When using that, there is no > problem bringing the machine in and out of standby repeatedly. > > Does anyone have any idea of how I could further narrow down where the > problem lies You should have debug symbols for init, or an init with debug symbols. Than you can load init into gdb and locate the code snip for address 0xb766d417, or you can run "objdump -Dr /sbin/init >dump.txt" and find out the address manually. The addr2line should also work for this. -- Henry N. |
From: Henry N. <hen...@ar...> - 2011-01-26 23:26:55
|
On 26.01.2011 18:19, Bill C Riemers wrote: > Hi, > > It looks like most of the image builds for coLinux desperately need updating. For example, the last Fedora image I built was Fedora 10. Since Fedora 10 has been end-of-life for more than a year now, the scripts for installing gnome no-longer work. > > The problem of course is that coLinux does not support 64 bit operating systems. I retired my last 32 bit Windows machine 2 years ago. As such I am unable to run coLinux to build a newer image. > > So I have two requests: > > 1. Can we depreciate the links to the Fedora builds. I added a readme file to the image directory that tells users they are end of life, but since you have scroll down to see the readme, many users will probably waste time downloading the images before noticing the readme. I can rename the folder like "Fedora 10 (depreciate)". Or I can move all folders into a subfolder "depreciate"? Fedora 11 exist here: http://blog.gbraad.nl/2009/07/fedora-11-on-colinux.html > 2. Can we maybe get a list of what we need volunteers to do to generate a version of coLinux that runs under a 64 bit OS? I've seen the 64 bit development page referenced by the FAQ. It looks like at least some of the issues are what is required for coLinux to run a 64 bit OS. For now, I would be happy to run a 32 bit version of Fedora under Windows 7 - 64 bit. It sounds like the main problem right may just be the drivers? I would be happy to volunteer my own time, but I don't know a thing about windows drivers, and I would also not want to step on someone else's toes. This all is in Wiki: http://colinux.wikia.com/wiki/Dashboard_for_developing_a_64_bit_coLinux#TODO_list Maybe you can add your request in the top of this wiki page? -- Henry N. |