colinux-devel — Cooperative Linux development mailing list

[coLinux-devel] Re: coLinux-devel digest, Vol 1 #9 - 11 msgs

[Jamie A. <jar...@ro...>]

Of course, the fact that I missed Monitor -> Terminate just made my 
whole message useless... Don't mind me, I'm tired -_-

> First off, thanks to Dan Aloni for creating this, I think it'll be 
> really useful in getting people like myself to get into using Linux, 
> and thanks to Ian Blenke for telling how to get past the FSCK issue 
> (though I'm sure it seems obvious to the others on this list).
>
> I'm also experiencing some issues with bluescreens, they seem to 
> happen most when the console screen is updated.  Another issue is that 
> the daemon sometimes freezes if I alt-tab back to the console from 
> another application; not much of an issue by itself but additionally, 
> I can't kill the daemon through the Windows process list or through 
> any other method I can think of.  I think some sort of tag on the 
> daemon to force any existing daemons to terminate (such as 
> colinux-daemon.exe -u) would be useful (I'd do it myself but kernel 
> programming is a bit beyond me).  Or is there another method of 
> forcibly terminating the daemon if it crashes / hangs?
>
> Jamie Arseneault
>

[coLinux-devel] Re: coLinux-devel digest, Vol 1 #9 - 11 msgs

[Jamie A. <jar...@ro...>]

First off, thanks to Dan Aloni for creating this, I think it'll be 
really useful in getting people like myself to get into using Linux, and 
thanks to Ian Blenke for telling how to get past the FSCK issue (though 
I'm sure it seems obvious to the others on this list).

I'm also experiencing some issues with bluescreens, they seem to happen 
most when the console screen is updated.  Another issue is that the 
daemon sometimes freezes if I alt-tab back to the console from another 
application; not much of an issue by itself but additionally, I can't 
kill the daemon through the Windows process list or through any other 
method I can think of.  I think some sort of tag on the daemon to force 
any existing daemons to terminate (such as colinux-daemon.exe -u) would 
be useful (I'd do it myself but kernel programming is a bit beyond me).  
Or is there another method of forcibly terminating the daemon if it 
crashes / hangs?

Jamie Arseneault

Re:[coLinux-devel] file/dir in use

[Ian L. <Ian...@mq...>]

<red faced>
.. of course ... one would be stupid not to notice a dos window
on one's own task bar ... upon the closing of which, one could
rename one's own directory ;-)
</red faced>


On the up-side .. I was clearing some screen space to try out
this little installshield clone;

  http://www.jrsoftware.org/isdl.php

Looks very handy for those who may be looking to bundle 
coLinux in a user-digestable format.



   Is it really free of charge, even for commercial use?

   Yes, it may be used completely free of charge, even when 
   deploying commercial applications. However if you wish to
   show your appreciation and support its development you 
   can make a donation.

   (Note: "Completely free of charge" must not be confused 
   with "completely free". Inno Setup is copyrighted software,
   not public domain software. There are some restrictions on
   distribution and use; see the LICENSE.TXT file for details.)

   http://www.jrsoftware.org/isinfo.php



----- Original Message -----
>From: "Ian Latter" <Ian...@mq...>
>To: <col...@li...>
>Subject:  [coLinux-devel] file/dir in use
>Date: Mon, 02 Feb 2004 20:52:21 +1000
>
> Hello,
> 
>   After successfully starting and stopping coLinux, I wanted to rename
> the directory, and was given the usual windows file locked error of;
> 
> 
>   "Cannot rename coLinux: It is being used by another person or program.
> 
>     Close any programs that might be using the file and try again."
> 
> 
>   I played a little, created a new dir and copied the contents of coLinux
> into it - and changed the default xml file.  Having successfully started 
> and stopped that instance, I began to get the same lock file error 
> message on the new directory when I attempted to change the name.
> The old directory still reports the same error, too.
> 
> Is this because something like the cygwin dll is still loaded?  Just
> curious on this one.
> 
> 
> Thanks,
> 
> 
> 
> 
> --
> Ian Latter
> Internet and Networking Security Officer
> Macquarie University
> 
>  Meet me at the Australian Unix and open systems
>    User Group (AUUG) Security Symposium; 2004
>   http://www.auug.org.au/events/2004/security/
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> coLinux-devel mailing list
> coL...@li...
> https://lists.sourceforge.net/lists/listinfo/colinux-devel
> 

--
Ian Latter
Internet and Networking Security Officer
Macquarie University

 Meet me at the Australian Unix and open systems
   User Group (AUUG) Security Symposium; 2004
  http://www.auug.org.au/events/2004/security/

[coLinux-devel] file/dir in use

[Ian L. <Ian...@mq...>]

Hello,

  After successfully starting and stopping coLinux, I wanted to rename
the directory, and was given the usual windows file locked error of;


  "Cannot rename coLinux: It is being used by another person or program.

    Close any programs that might be using the file and try again."


  I played a little, created a new dir and copied the contents of coLinux
into it - and changed the default xml file.  Having successfully started 
and stopped that instance, I began to get the same lock file error 
message on the new directory when I attempted to change the name.
The old directory still reports the same error, too.

Is this because something like the cygwin dll is still loaded?  Just
curious on this one.


Thanks,




--
Ian Latter
Internet and Networking Security Officer
Macquarie University

 Meet me at the Australian Unix and open systems
   User Group (AUUG) Security Symposium; 2004
  http://www.auug.org.au/events/2004/security/

[coLinux-devel] 3d driver

[Brandon E. B. <be...@uk...>]

Are there any plans to make a generic 3d OpenGL driver for coLinux that wil=
l allow graphics to be rendered by the host operating system?  That would=
 be fantastic!

Re: [coLinux-devel] coLinux 0.5.2

[Ian L. <Ian...@mq...>]

Hello Dan,

"shutdown -g0 -y -i0" works correctly .. "Power Down" is the last item 
displayed.  Detaching the console releases the daemon .. the daemon
exits and the network connection goes into the disconnect state.


You're right - I mustn't have detached from the console first.


Thanks,


----- Original Message -----
>From: "Ian Latter" <Ian...@mq...>
>To: "Dan Aloni" <da...@gm...>
>Subject:  Re: [coLinux-devel] coLinux 0.5.2
>Date: Sun, 01 Feb 2004 17:12:43 +1000
>
> 
> > Use the DDK that closely matches the running system, i.e, the last one.
> 
> Ok, I'll see what I can organise.
> 
> > Note that the console implementation is incomplete.
> 
> Noted :)  So the virtual system "boots" as soon as the coloinux
> daemon is executed?  And, if your virtual system didn't require
> input, you would not need the console at all?
> 
>  
> > Was the console still attached after the virtual system shutdown?
> 
> The shutdown I did was the "shutdown -g0 -y -i0" ... hmm maybe
> I did i6 ...    I'll check these and get back to you tomorrow some
> time.
> 
> 
> > If Linux terminates, the driver sleeps uninterruptedly until you 
> > detach the console, that could be the reason why you couldn't
> > kill the driver or restart the system.
> 
> Ok - I'll do more testing and get back to you with real data.
> 
> One other thing that I've found ... I was in a "cmd" prompt when
> I first started the daemon, last time.  This time I ran it from explorer
> and I just flashes a window up and disappears again.  I think there's
> an error message in there,  but I can't see it - its too fast.  Running
> the daemon from the cmd prompt again, it works without a hitch.
> 
> Hope that helps others.
> 
> 
> 
> --
> Ian Latter
> Internet and Networking Security Officer
> Macquarie University
> 
>  Meet me at the Australian Unix and open systems
>    User Group (AUUG) Security Symposium; 2004
>   http://www.auug.org.au/events/2004/security/
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> coLinux-devel mailing list
> coL...@li...
> https://lists.sourceforge.net/lists/listinfo/colinux-devel
> 

--
Ian Latter
Internet and Networking Security Officer
Macquarie University

 Meet me at the Australian Unix and open systems
   User Group (AUUG) Security Symposium; 2004
  http://www.auug.org.au/events/2004/security/

Re: [coLinux-devel] linux kernel; array size missing in `data'

[Ian L. <Ian...@mq...>]

Hello Dan,

  I've built a RedHat9 workstation machine to try a clean compile.  I
was still having problems in various places, so I cut everything 
back to something that should work;

  - plain 2.4.24 linux kernel
  - 20040131 .config (from coLinux download site @ sourceforge)
  - 20040131 linux patch (from same download).


At this stage the kernel build fails in the very last stage of the
build process (see below).

The build process is very simple ... patch it .. make mrproper .. cp in
the .config .. make oldconfig .. make dep .. make bzImage .. nothing
fancy at all (no openMosix, no IPSec, no other drivers, etc).

I'm going to continue to assume that this is still a compiler issue (you're
certain that the 20040131 release compiles against 2.4.24?  This almost
looks like an include/linking/Makefile issue).  The gcc version that RH9
comes out with;

[root@host linux]# gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --
infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-
system-zlib --enable-__cxa_atexit --host=i386-redhat-linux
Thread model: posix
gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)


  You're showing "gcc version 3.3.3 20040125 (prerelease) (Debian)"
which I cannot get.  I can either get myself to a release 3.3.2 version,
or prerelease 3.3.3 20040131;   ftp://gcc.gnu.org/pub/gcc/

  I'll try the latest prerelease and see what happens.


echo "SECTIONS { .data : { input_len = .; LONG(input_data_end - input_data) input_data = .; *
(.data) input_data_end = .; }}" > $tmppiggy.lnk; 
ld -m elf_i386 -r -o piggy.o -b binary $tmppiggy.gz -b elf32-i386 -T $tmppiggy.lnk; 
rm -f $tmppiggy $tmppiggy.gz $tmppiggy.lnk
gcc -D__ASSEMBLY__ -D__KERNEL__ -I/usr/src/linux-2.4.24/include -traditional -c head.S
gcc -D__KERNEL__ -I/usr/src/linux-2.4.24/include -Wall -Wstrict-prototypes -Wno-trigraphs -
O2 -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i386 -
DKBUILD_BASENAME=misc -c misc.c
ld -m elf_i386 -Ttext 0x100000 -e startup_32 -o bvmlinux head.o misc.o piggy.o
misc.o(.text+0x1b94): In function `puts':
: undefined reference to `co_terminate'
misc.o(.text+0x1ba0): In function `puts':
: undefined reference to `co_terminate'
misc.o(.text+0x1bac): In function `puts':
: undefined reference to `co_terminate'
misc.o(.text+0x1bb8): In function `puts':
: undefined reference to `co_terminate'
make[2]: *** [bvmlinux] Error 1
make[2]: Leaving directory `/usr/src/linux-2.4.24/arch/i386/boot/compressed'
make[1]: *** [compressed/bvmlinux] Error 2
make[1]: Leaving directory `/usr/src/linux-2.4.24/arch/i386/boot'
make: *** [bzImage] Error 2






----- Original Message -----
>From: "Dan Aloni" <da...@gm...>
>To: "Ian Latter" <Ian...@mq...>
>Subject:  Re: [coLinux-devel] linux kernel; array size missing in `data'
>Date: Sun, 01 Feb 2004 07:37:22 +0200
>
> On Sun, Feb 01, 2004 at 09:35:48AM +1000, Ian Latter wrote:
> > Hi Dan,
> > 
> >   See below, using the colinux-20040131 patch, I am getting a kernel
> > compile error, regarding the variable "data" in cooperative.h  ("putcs"
> > structure within the co_console_message_t structure).
> > 
> >   I have decided that if you haven't seen this in your compiles, then it
> > may be compiler related - this is my compiler version;
> > 
> >     [root@host]# gcc --version
> >     2.96
> > 
> >   Has anyone else seen this issue?  If not, which compiler version
> > are you using?
> 
> Please use gcc version 3.
> 
> [07:35 pts/5,callisto ~]% gcc -v
> Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.3/specs
> Configured with: ../src/configure -v --enable-
languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr 
> --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-
dir=/usr/include/c++/3.3 --enable-shared 
> --with-system-zlib --enable-nls --without-included-gettext --enable-__cxa_atexit --enable-
clocale=gnu 
> --enable-debug --enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i486-linux
> Thread model: posix
> gcc version 3.3.3 20040125 (prerelease) (Debian)
> 
> >   Alternatively, if this is supposed to be a single char (put-char-screen?)
> > then how about redefining data[] as data[2]?
> 
> You can define it as data[0] and it may fix the problem for your compiler.
> 
> -- 
> Dan Aloni
> da...@gm...
> 

--
Ian Latter
Internet and Networking Security Officer
Macquarie University

 Meet me at the Australian Unix and open systems
   User Group (AUUG) Security Symposium; 2004
  http://www.auug.org.au/events/2004/security/

Re: networking, was Re: [coLinux-devel] BSOD, DDK dependency

[Ian L. <Ian...@mq...>]

It did - someone here showed me the bridge function as someone
on the list was sending the same solution through.  I hadn't seen 
the bridging option before - very handy. 

I'm currently running apt-get on the Debian install, out through the 
test network here, so it looks good.

Thanks for the post.



----- Original Message -----
>From: "Ballard Jonathan" <sac...@ho...>
>To: "Ian Latter" <Ian...@mq...>, "Richard Goodwin" 
<ric...@ri...>
>Subject:  Re: networking, was Re: [coLinux-devel] BSOD, DDK dependency
>Date: Sun, 01 Feb 2004 22:42:23 -0800
>
> 
> From: "Ian Latter" <Ian...@mq...>
> [...]
> 
> >
> >   I still need to get the TAP interface on the same side as the ethernet
> > interface.  I'm going to continue to look around ... if anyone finds
> > anything, post it up.
> 
> Does the network bridge help you to the setup you want.  Under Network
> Connections, add a bridge and assign it the network numbers to share.  Then
> add all devices to share that network to that bridge.
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> coLinux-devel mailing list
> coL...@li...
> https://lists.sourceforge.net/lists/listinfo/colinux-devel
> 

--
Ian Latter
Internet and Networking Security Officer
Macquarie University

 Meet me at the Australian Unix and open systems
   User Group (AUUG) Security Symposium; 2004
  http://www.auug.org.au/events/2004/security/

Re: networking, was Re: [coLinux-devel] BSOD, DDK dependency

[Ballard J. <sac...@ho...>]

From: "Ian Latter" <Ian...@mq...>
[...]

>
>   I still need to get the TAP interface on the same side as the ethernet
> interface.  I'm going to continue to look around ... if anyone finds
> anything, post it up.

Does the network bridge help you to the setup you want.  Under Network
Connections, add a bridge and assign it the network numbers to share.  Then
add all devices to share that network to that bridge.

Re: [coLinux-devel] BSOD, DDK dependency

[Ian L. <Ian...@mq...>]

> For bridging:
> 1. Turn off ICS (follow step 2 above, disabling ICS)
> 2. Select two interfaces (holding down the control key) and right click
> a menu to select "Bridge Connections".
> 3. Configure /etc/network/interfaces on your colinux image, or
> ifconfig up your eth0 interface with an IP on your segment and add a
> default route through your gateway.
> (Note: if you do happen to use a wireless interface in your testing,
> don't attempt bridging - it doesn't work).
> 
> Both methods above work just fine for me.

I just had one of the Windoze gurus here show me the bridging
option under XP - I hadn't seen that before, very cool.  Works a 
treat.


> On the plus side: no BSODs yet. ;)

Running the coLinux with the deb 1gig yesterday I had two
successful startups.  Today, I got an error -15 from the daemon/exe
telling me that a version was running (I'd just rebooted) .. running it
again it worked fine, but the console/exe showed that I had the 
fsck error.  Interesting.  But still no BSODs.


> PS. I hate Windows, Windows' dialog boxes, and the pain that must be
> taken to describe such trivial procedures. 

There's got to be a tool that performs this via the command line
someplace ... maybe in one of their SDK's ...  I'll see what I can 
find - I'd like to automate the install process (so that it can be
installed from CDROM).




--
Ian Latter
Internet and Networking Security Officer
Macquarie University

 Meet me at the Australian Unix and open systems
   User Group (AUUG) Security Symposium; 2004
  http://www.auug.org.au/events/2004/security/

Re: [coLinux-devel] BSOD, DDK dependency

[Ian C. B. <ia...@bl...>]

I've managed to get the Debian3.0 root image and the binary release of
coLinux running on a WinXP/Pro laptop with only minor issues. 

The block device size issue (30448/262144) causes a warning on mount.
You can of course override it with:

	$ mount -o remount,rw /
	$ exec /sbin/init 3

Still, it will be nice to hunt this one down. I was able to generate a
~1G file on the filesystem with no errors with dd - so the block
limitation reported on boot doesn't appear to be breaking writes past
that point.

The win32 Tap interface is working just fine, and works well with
both ICS and bridging. 

Here's a quick guide for some of the unfamiliar users:

For ICS:
1. Give your Tap Local Area Connection interface an IP of 192.168.0.1
2. Go to Network Settings, open your your "external" 
interface (whatever Local Area or Wireless Connection interface
you use as your default route), click on the Advanced tab,
select Internet Connection Sharing, Allow other network users 
to connect through this comput'ers Internet connection, and select 
the Local Area Connection interface assigned to your Tap driver.
3. The default Debian3.0 root image has an IP of 192.168.0.40
preconfigured in its /etc/network/interfaces file: simply do the
following:
	$ ifup eth0
You should now be able to ping out. 

For bridging:
1. Turn off ICS (follow step 2 above, disabling ICS)
2. Select two interfaces (holding down the control key) and right click
a menu to select "Bridge Connections".
3. Configure /etc/network/interfaces on your colinux image, or
ifconfig up your eth0 interface with an IP on your segment and add a
default route through your gateway.
(Note: if you do happen to use a wireless interface in your testing,
don't attempt bridging - it doesn't work).

Both methods above work just fine for me.

You might also try a direct routed approach, if you're more familiar 
with IP networking and able to add routes on a machine upstream from
your windows box (or configure RIP/OSPF/etc to do the same). It should
work with little effort.

On the plus side: no BSODs yet. ;)

- Ian C. Blenke <ia...@bl...>
PS. I hate Windows, Windows' dialog boxes, and the pain that must be
taken to describe such trivial procedures. 

networking, was Re: [coLinux-devel] BSOD, DDK dependency

[Ian L. <Ian...@mq...>]

> I was fooling quite a bit with the networking, trying to get things working
> without using ICS, unsuccessfully I might add.

I've just started to go on a bit of a hunt for this .. I've found (but not 
tested) the forwarding option for NT/2K/XP .. but this won't help me;


  Registry Settings 

  System Key: 
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters]
  Value Name: IPEnableRouter
  Data Type: REG_DWORD (DWORD Value)
  Value Data: (0 = disabled, 1 = enabled) 

  http://www.winguides.com/registry/display.php/1171/


  I still need to get the TAP interface on the same side as the ethernet
interface.  I'm going to continue to look around ... if anyone finds 
anything, post it up.







--
Ian Latter
Internet and Networking Security Officer
Macquarie University

 Meet me at the Australian Unix and open systems
   User Group (AUUG) Security Symposium; 2004
  http://www.auug.org.au/events/2004/security/

Re: [coLinux-devel] BSOD, DDK dependency

[Richard G. <ric...@ri...>]

I've gotten a STOP 8E and a 50, both on 2k3, both seeming to occur when
coLinux is shutting down. I haven't had the chance to analyze at all yet.

I was fooling quite a bit with the networking, trying to get things working
without using ICS, unsuccessfully I might add.

Richard

----- Original Message ----- 
From: "Steven Edwards" <ste...@ya...>
To: "Dan Aloni" <da...@gm...>; "Cooperative Linux Development"
<col...@li...>
Sent: Sunday, February 01, 2004 6:14 PM
Subject: Re: [coLinux-devel] BSOD, DDK dependency


> --- Dan Aloni <da...@gm...> wrote:
> > DDK dependency
> > --------------
> >
> > Making it possible to compile valid .sys files on Linux is
> > something that can be developed quite separately from coLinux
> > devleopment. ReactOS would also benefit from it (binary
> > compatibility with Windows), although they don't depend on it
> > at the moment.
>
> It could be a bug in the Cygwin cross-compiler. We have no problem
> using the .sys files created by Mingw under Windows. If you can post
> some object files I will try and link it on mingw when I get back on
> the 9th or 10th. In the mean-time try passing the -mno-cygwin flag when
> linking.
>
> Thanks
> Steven
>
> PS Just rip the ReactOS or w32api DDK in to CoLinux.
>
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free web site building tool. Try it!
> http://webhosting.yahoo.com/ps/sb/
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> coLinux-devel mailing list
> coL...@li...
> https://lists.sourceforge.net/lists/listinfo/colinux-devel
>
>

Re: [coLinux-devel] BSOD, DDK dependency

[Steven E. <ste...@ya...>]

--- Dan Aloni <da...@gm...> wrote:
> DDK dependency
> --------------
> 
> Making it possible to compile valid .sys files on Linux is 
> something that can be developed quite separately from coLinux 
> devleopment. ReactOS would also benefit from it (binary 
> compatibility with Windows), although they don't depend on it 
> at the moment.

It could be a bug in the Cygwin cross-compiler. We have no problem
using the .sys files created by Mingw under Windows. If you can post
some object files I will try and link it on mingw when I get back on
the 9th or 10th. In the mean-time try passing the -mno-cygwin flag when
linking.

Thanks
Steven

PS Just rip the ReactOS or w32api DDK in to CoLinux.

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

[coLinux-devel] Re: BSOD, DDK dependency

[Dan A. <da...@gm...>]

On Mon, Feb 02, 2004 at 12:14:17AM +0200, Dan Aloni wrote:

> I ask for anyone who experiences a BSOD with coLinux, please 
> extract useful information out from the tools Microsoft has 
> provided us:

I tried to use test these tools by deliberately causing an exception, 
and it appears they are very useful.

Using linux.pdb, which is also generated in the compilation, I am
able to produce a stacktrace such as:

nt!KiDispatchException+0x30e
nt!CommonDispatchException+0x4d
nt!KiUnexpectedInterruptTail+0x1f4
linux!co_os_file_block_read+0x3c
linux!co_monitor_file_block_service+0xc5
linux!co_monitor_block_request+0x41
linux!co_monitor_device_request+0x70
linux!co_monitor_iteration+0x107
linux!co_monitor_run+0x99
linux!co_monitor_ioctl+0x11e
linux!co_manager_ioctl+0xd5
linux!co_manager_dispatch+0xa4
nt!IopfCallDriver+0x35
nt!IopSynchronousServiceTail+0x60
nt!IopXxxControlFile+0x5e4
nt!NtDeviceIoControlFile+0x28
nt!KiSystemService+0xc4
ntdll!ZwDeviceIoControlFile+0xb
KERNEL32!DeviceIoControl+0x100
WARNING: Stack unwind information not available. Following frames may be 
wrong.
colinux_daemon+0x2f27
colinux_daemon+0x1b7e
colinux_daemon+0x1bb0
colinux_daemon+0x158d
colinux_daemon+0x1767
colinux_daemon+0x401a
colinux_daemon+0x7400
cygwin1!forkpty+0x3688
cygwin1!dll_crt0+0x1ad
colinux_daemon+0x7453
colinux_daemon+0x103c
KERNEL32!BaseProcessStart+0x3d

I'd like to see stack traces such as these, even before I send you a 
matched linux.pdb to the previously distributed linux.sys.

-- 
Dan Aloni
da...@gm...

[coLinux-devel] BSOD, DDK dependency

[Dan A. <da...@gm...>]

Hello,

Currently, there are two issues that stand between us and a more 
stable and easier to develop version of coLinux.


BSOD
----

The BSODs that many people are getting are caused by a bug that
manifests itself only on some machines. Unfortunately, I can't 
reproduce it here. Because of that, you should send me results 
of crash dumps, using tools freely available from Microsoft.

Thanks ePAc for enlightening us about kernel dumps. Me and 
Okajima think it is important for the road ahead.

I'd like you to know something aboue me, which should encourge 
everybody on this developers list to participate in development 
and debugging. When I started coLinux on November, I had almost 
no knowledge in Windows Kernel programming. A few years ago, I 
had no knowledge in Linux kernel programming at all. Don't be 
afraid to try something that you don't know, especially in the
kernel field.

I ask for anyone who experiences a BSOD with coLinux, please 
extract useful information out from the tools Microsoft has 
provided us:

Debug tools at:

    http://www.microsoft.com/whdc/ddk/debugging/installx86.mspx

Debugging symbols at:

    http://www.microsoft.com/whdc/ddk/debugging/symbolpkg.mspx

To enable dumps (as ePAc noted):
    Right click on "My Computer"
    Select "Properties"
    Select "Advanced" tab
    Under "Startup And Recovery" there is some option to setup 
    different type of memory dump (minidump, kernel dump, full 
    memory dump).

Plus, I am planning to add automatic traces to coLinux's build
so it would be even more easier to make something out of these 
dumps.


DDK dependency
--------------

Making it possible to compile valid .sys files on Linux is 
something that can be developed quite separately from coLinux 
devleopment. ReactOS would also benefit from it (binary 
compatibility with Windows), although they don't depend on it 
at the moment.

I know there must be some very talented developers on this list,
so I seek volunteers fir this mini-development. coLinux's source
has a CREDITS file, needless to remind ;)

-- 
Dan Aloni
da...@gm...

Re: [coLinux-devel] Measures to analyze a dump.

[Digital I. Inc. <ok...@di...>]

Hello ePAc.

Thank you for reply.
Your opinion is useful.
Although I dont know if it works for coLinux.
How about this idea, Aloni?

As I wrote, there would be very many ways to do it.
so we have to discuss about many options before we start to develop.
Any opinion is welcome. I need your help, everyone.

   --- Okajima, Jun. President, Digital Infra, Inc. Tokyo, Japan.


>
>> We apparently have to get some measures to get information about
>> what is going on under a blue screen of death. One way is using
>> a memory dump. And there must be many ideas, papers, codes to do it.
>> To prevent re-inventing the wheel, I ask you to post ideas,
>> URLs, papers,,,, about this issue.
>>
>
>how about just using the tools that microsoft is providing us to analyze
>the dumps...
>
>http://www.microsoft.com/whdc/ddk/debugging/installx86.mspx
>
>the "dumpchk.exe" tool will generate a backtrace of what generated the
>BSOD (unless it can't with something like memory corruption).
>
>given the proper symbols, you can get a pretty detailed backtrace of the
>crash.
>
>i'll be producing the debug info from the dump file i have shortly...
>
>Thanks,
>Jok
>
>---
>Nothing is foolproof to a sufficiently talented fool...
>  oo
>,(..)\
>  ~~
>

Re: [coLinux-devel] Measures to analyze a dump.

[ePAc <ep...@ko...>]

> We apparently have to get some measures to get information about
> what is going on under a blue screen of death. One way is using
> a memory dump. And there must be many ideas, papers, codes to do it.
> To prevent re-inventing the wheel, I ask you to post ideas,
> URLs, papers,,,, about this issue.
>

how about just using the tools that microsoft is providing us to analyze
the dumps...

http://www.microsoft.com/whdc/ddk/debugging/installx86.mspx

the "dumpchk.exe" tool will generate a backtrace of what generated the
BSOD (unless it can't with something like memory corruption).

given the proper symbols, you can get a pretty detailed backtrace of the
crash.

i'll be producing the debug info from the dump file i have shortly...

Thanks,
Jok

---
Nothing is foolproof to a sufficiently talented fool...
  oo
,(..)\
  ~~

Re: [coLinux-devel] Linux native drivers/Direct hardware access

[Dan A. <da...@gm...>]

On Sun, Feb 01, 2004 at 12:17:22PM -0800, Steven Edwards wrote:
> --- Dan Aloni <da...@gm...> wrote:
> > On Sun, Feb 01, 2004 at 02:25:21PM +0200, Sat Rookie wrote:
> > 
> > > Is it possible to use native linux drivers to access REAL hardware
> > without 
> > > writing special wrappers for every device type?
> > > 
> > > PS: I mean not 'Windows-Must-Have' hardware like keyboard or mouse
> > but 
> > > ADDITIONAL hardware like MPEG Capture card, DVB TV Card,...
> > 
> > Not currently. coLinux is designed to be a virtual Linux.
> 
> But do you think its possible via a Windows filer driver? I guess I am
> thinking about replacing the Linux PnP implementation and passing it
> off to the Windows PnP Manager and then using Linux network cards and
> such as a quick and dirty wrapper to get Linux driver support for us on
> ReactOS.

It is possible, providing that such adapter-like interface is made.

-- 
Dan Aloni
da...@gm...

Re: [coLinux-devel] Linux native drivers/Direct hardware access

[Steven E. <ste...@ya...>]

--- Dan Aloni <da...@gm...> wrote:
> On Sun, Feb 01, 2004 at 02:25:21PM +0200, Sat Rookie wrote:
> 
> > Is it possible to use native linux drivers to access REAL hardware
> without 
> > writing special wrappers for every device type?
> > 
> > PS: I mean not 'Windows-Must-Have' hardware like keyboard or mouse
> but 
> > ADDITIONAL hardware like MPEG Capture card, DVB TV Card,...
> 
> Not currently. coLinux is designed to be a virtual Linux.

But do you think its possible via a Windows filer driver? I guess I am
thinking about replacing the Linux PnP implementation and passing it
off to the Windows PnP Manager and then using Linux network cards and
such as a quick and dirty wrapper to get Linux driver support for us on
ReactOS.

Thanks
Steven


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

Re: [coLinux-devel] Linux native drivers/Direct hardware access

[Dan A. <da...@gm...>]

On Sun, Feb 01, 2004 at 02:25:21PM +0200, Sat Rookie wrote:

> Is it possible to use native linux drivers to access REAL hardware without 
> writing special wrappers for every device type?
> 
> PS: I mean not 'Windows-Must-Have' hardware like keyboard or mouse but 
> ADDITIONAL hardware like MPEG Capture card, DVB TV Card,...

Not currently. coLinux is designed to be a virtual Linux.

-- 
Dan Aloni
da...@gm...

Re: [coLinux-devel] Colinux for Linux beginners?

[Dan A. <da...@gm...>]

On Mon, Feb 02, 2004 at 12:00:07AM +0800, HandWatch, Inc. wrote:
> I believe Colinux is a very good tool for Linux beginner like me.  However, having colinux compiled correctly isn't a beginner's task.  I've been scrapping my hair off and tried the following.  Just can't get it right.  Can someone lend a hand?
> 
> 1. Setup cygwin.
> 2. Get colinux source code 20040131.
> 3. Get Linux kernel 2.4.24 source code.
> 4. Apply colinux patch to the kernel.
> 5. Use .config in colinux source code to compile the kernel.
> 6. Then...?
> 7. What about cross-compiler?  Do we need to patch it, too?
> 8. How to run colinux daemon?

You also need a Linux machine to compile vmlinux. cygwin gcc isn't 
fit for that task, and making the Linux build system work with
a i686-linux-pc cross compiler is not easy.

The plan is to make coLinux compilation be entirely contained in 
one Linux box using the cygwin cross compiler, without the Windows 
DDK and without cygwin.

This way, once you got an initial version of coLinux running, you
would be able to compile it under itself. coLinux distributions
could come with the source along with a cross compiler already 
ready inside :)

-- 
Dan Aloni
da...@gm...

Re: [coLinux-devel] Still stuck a few threads ago...

[Dan A. <da...@gm...>]

On Sun, Feb 01, 2004 at 09:30:31AM -0500, Remy Porter wrote:
> I just joined the mailinglist, and am still stuck with the failure under 
> XP pro where the kernel driver bails with an exit code -1. There was 
> mention of a patch attatched, and it was stated that the patch had been 
> added to the distro- but the distro I downloaded still doesn't work. I 
> wasn't sure from reading the archives though, whether or not this was 
> resolved, or still being worked on.

http://prdownloads.sourceforge.net/colinux/colinux-daemon-replacement-1.tar.gz?download

-- 
Dan Aloni
da...@gm...

[coLinux-devel] Measures to analyze a dump.

[Digital I. Inc. <ok...@di...>]

Hello every great hacker.

We apparently have to get some measures to get information about
what is going on under a blue screen of death. One way is using
a memory dump. And there must be many ideas, papers, codes to do it.
To prevent re-inventing the wheel, I ask you to post ideas,
URLs, papers,,,, about this issue.

I post my idea. this is taken from a private mail to Aloni.
I hope you post your idea or your knowledge or URLs,,,,.
Any information is useful.
It is better than nothing.

               --- Okajima.

-----------------------

1. see trace log.
   do like this:
     1.   get some physical pages.
     2.   set "signature" on the top of them.
     3.   use the pages as a ring buffer of trace log.
     4.   when BSOD, there is a memory dump.
          you get the file and look for the "signature" inside it.
          after the signature, there must be trace log.

2. see back trace of stack.
   first, change the source like this pseudo code:
--------------
   #pragma LD_OPTION use before_main() as usual main().

   char signature_header[] = "DAN ALONI, THE HACKER";
   const int signature_magic = 1000;

   before_main()
   {
   char *buf, void *func;
   
      buf = alloca(256);

      // add time stamp and magic.
      // for reducing a miss-detection, write magic
      // by different format than an ELF binary.
      // In this case, written by 32bit int in the binary, and ascii in a dump.
      snprintf( buf, 256,
                "%s %d %d", signature_header, signature_magic, get_tick());

      // by this, you can know where the code stays.
      func = before_main;
      main(); 
   }
   
   main()
   {
         .... same as current one.
   }
---------------

and how to see back trace is:

   1. get a memory dump.
   2. find the address of signatures.
   3. Probably you find more than one.
      Signature that have the latest time stamp is right.
   4. then you can fix start address of stack area.
   5. using 'nm' and some perl utilities, you can get plenty of information.
   
   
 

[coLinux-devel] Colinux for Linux beginners?

[HandWatch, Inc. <han...@ha...>]

I believe Colinux is a very good tool for Linux beginner like me.  =
However, having colinux compiled correctly isn't a beginner's task.  =
I've been scrapping my hair off and tried the following.  Just can't get =
it right.  Can someone lend a hand?

1. Setup cygwin.
2. Get colinux source code 20040131.
3. Get Linux kernel 2.4.24 source code.
4. Apply colinux patch to the kernel.
5. Use .config in colinux source code to compile the kernel.
6. Then...?
7. What about cross-compiler?  Do we need to patch it, too?
8. How to run colinux daemon?

Thanks!