colinux-devel-request@lists.sourceforge.net wrote:
Send coLinux-devel mailing list submissions to
colinux-devel@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/colinux-devel
or, via email, send a message with subject or body 'help' to
colinux-devel-request@lists.sourceforge.net

You can reach the person managing the list at
colinux-devel-admin@lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of coLinux-devel digest..."


Today's Topics:

1. TAP driver link speed (Nuno Lucas)
2. Re: TAP driver link speed (Ian Bonnycastle)
3. do_exit workaround (gboutwel)
4. Re: do_exit workaround (Henry Nestler)
5. RE: do_exit workaround (Ben Voigt)
6. Re: ReactOS update (Florian Schlachter)
7. Re: TAP driver link speed (Nuno Lucas)

--__--__--

Message: 1
Date: Tue, 29 Mar 2005 09:21:23 +0100
From: Nuno Lucas
To: coLinux Devel
Cc: Dan Aloni , gboutwel
Subject: [coLinux-devel] TAP driver link speed

While googling i found a message about setting the link speed of a
network driver. Basically it was just handling OID_GEN_LINK_SPEED in the
right way.

After some browsing of the code, this is handled by the driver here:
http://lxr.xpto.ath.cx/source/src/colinux/os/winnt/kernel/tap-win32/tapdrvr.c#L1015

And according with MSDN:
"The OID_GEN_LINK_SPEED OID specifies the maximum speed of the NIC in
kbps. The unit of measurement is 100 bps, so a value of 100,000
represents a hardware bit rate of 10 Mbps."

I wonder if simply replacing the 100000 with 1000000 would not stop
some users of asking us to increase this value.

I didn't tried it, as I don't know how to build the tap driver with
the new build system (and I haven't tried to).

Any thoughts? (like should we bother?)

Regards,
~Nuno Lucas



--__--__--

Message: 2
Date: Tue, 29 Mar 2005 09:50:53 -0500
From: Ian Bonnycastle
Reply-To: Ian Bonnycastle
To: Nuno Lucas
Subject: Re: [coLinux-devel] TAP driver link speed
Cc: coLinux Devel ,
Dan Aloni , gboutwel

The tap driver isn't built with the colinux system at all, is it?
Every time I build, it never rebuilds the tap driver.

Ian


On Tue, 29 Mar 2005 09:21:23 +0100, Nuno Lucas wrote:
> While googling i found a message about setting the link speed of a
> network driver. Basically it was just handling OID_GEN_LINK_SPEED in the
> right way.
>
> After some browsing of the code, this is handled by the driver here:
> http://lxr.xpto.ath.cx/source/src/colinux/os/winnt/kernel/tap-win32/tapdrvr.c#L1015
>
> And according with MSDN:
> "The OID_GEN_LINK_SPEED OID specifies the maximum speed of the NIC in
> kbps. The unit of measurement is 100 bps, so a value of 100,000
> represents a hardware bit rate of 10 Mbps."
>
> I wonder if simply replacing the 100000 with 1000000 would not stop
> some users of asking us to increase this value.
>
> I didn't tried it, as I don't know how to build the tap driver with
> the new build system (and I haven't tried to).
>
> Any thoughts? (like should we bother?)
>
> Regards,
> ~Nuno Lucas
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> coLinux-devel mailing list
> coLinux-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/colinux-devel
>


--__--__--

Message: 3
Date: 29 Mar 2005 18:56:11 -0000
From: "gboutwel"
To: colinux-devel@lists.sf.net
CC: da-x@colinux.org
Subject: [coLinux-devel] do_exit workaround

Hey,



Here's an situation where the user is hitting the do_exit work
around code that prints check_rlimit debug info. I'm forwarding
it to the devel list and Dan to see if it helps in acutally tacking
down the problem.



HTH,

George



ctoriger@yahoo.co.uk wrote:

> Hi George, well sadly not so good news. If my

> 'emerge' of glibc is any test case it fails. No panic

> this time or BSOD but instead the entire machine just

> locks and no response to the keyboard or mouse.

>

> I also saw something perhaps interesting and relevent

> in my log files. Here it is:

>

>

> - Last output repeated 2 times -

> Mar 23 21:35:32 [kernel] kernel/sched.c:2317:

> check_rlimit: p->signal=NULL p=c7c

> ba0a0 pid=29180 exit_code=0 exit_signal=11

> Mar 23 21:37:34 [kernel] kernel/sched.c:2317:

> check_rlimit: p->signal=NULL p=c9e

> 4d590 pid=30273 exit_code=0 exit_signal=11

>

> Well, sorry not better luck and for me after a two

> hour build that then fails :-(.

> Cheers, Christopher



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

Want to talk to other Christians?

Get the Christian Instant Messenger

http://www.praize.com/IM/



--__--__--

Message: 4
Date: Tue, 29 Mar 2005 21:12:57 +0200
From: Henry Nestler
To: colinux-devel@lists.sourceforge.net
Subject: Re: [coLinux-devel] do_exit workaround

gboutwel wrote:

> Hey,
>
> Here's an situation where the user is hitting the do_exit work
> around code that prints check_rlimit debug info. I'm forwarding
> it to the devel list and Dan to see if it helps in acutally tacking
> down the problem.
>
> HTH,
> George
>
> ctoriger@yahoo.co.uk wrote:
>
>>Hi George, well sadly not so good news. If my
>>'emerge' of glibc is any test case it fails. No panic
>>this time or BSOD but instead the entire machine just
>>locks and no response to the keyboard or mouse.
>>I also saw something perhaps interesting and relevent
>>in my log files. Here it is:
>> - Last output repeated 2 times -
>>Mar 23 21:35:32 [kernel] kernel/sched.c:2317:
>>check_rlimit: p->signal=NULL p=c7cba0a0
>> pid=29180 exit_code=0 exit_signal=11
>>Mar 23 21:37:34 [kernel] kernel/sched.c:2317:
>>check_rlimit: p->signal=NULL p=c9e4d590
>> pid=30273 exit_code=0 exit_signal=11
>>Well, sorry not better luck and for me after a two
>>hour build that then fails :-(.
>
>>Cheers, Christopher

exit_signal=11:
SIGSEGV 11 Core Invalid memory reference

What he doing to increment process number pid from pid=29180 to
pid=30273 in ~2 minutes?

I have also do a test with simple script.
This create a lot of processes, but never fails:
>>> run.sh >>>
#!/bin/sh

count=1
while [ $count -lt 10000 ]
do
let count++
( sleep 5; ) &
done
ps
<<< run.sh <<<


--
Henry Nestler


--__--__--

Message: 5
From: "Ben Voigt"
To: "'Henry Nestler'" ,

Subject: RE: [coLinux-devel] do_exit workaround
Date: Tue, 29 Mar 2005 15:23:48 -0500

> -----Original Message-----
> From: colinux-devel-admin@lists.sourceforge.net
> [mailto:colinux-devel-admin@lists.sourceforge.net]On Behalf
> Of Henry Nestler
> Sent: Tuesday, March 29, 2005 2:13 PM
> To: colinux-devel@lists.sourceforge.net
> Subject: Re: [coLinux-devel] do_exit workaround
>
>
> gboutwel wrote:
>
> > Hey,
> >
> > Here's an situation where the user is hitting the do_exit work
> > around code that prints check_rlimit debug info. I'm forwarding
> > it to the devel list and Dan to see if it helps in acutally tacking
> > down the problem.
> >
> > HTH,
> > George
> >
> > ctoriger@yahoo.co.uk wrote:
> >
> >>Hi George, well sadly not so good news. If my
> >>'emerge' of glibc is any test case it fails. No panic
> >>this time or BSOD but instead the entire machine just
> >>locks and no response to the keyboard or mouse.
> >>I also saw something perhaps interesting and relevent
> >>in my log files. Here it is:
> >> - Last output repeated 2 times -
> >>Mar 23 21:35:32 [kernel] kernel/sched.c:2317:
> >>check_rlimit: p->signal=NULL p=c7cba0a0
> >> pid=29180 exit_code=0 exit_signal=11
> >>Mar 23 21:37:34 [kernel] kernel/sched.c:2317:
> >>check_rlimit: p->signal=NULL p=c9e4d590
> >> pid=30273 exit_code=0 exit_signal=11
> >>Well, sorry not better luck and for me after a two
> >>hour build that then fails :-(.
> >
> >>Cheers, Christopher
>
> exit_signal=11:
> SIGSEGV 11 Core Invalid memory reference
>
> What he doing to increment process number pid from pid=29180 to
> pid=30273 in ~2 minutes?

Running make.

Some makefiles run, for example, rm for each file in a long list, all as
separate processes. Certainly each file compiled also requires a few
processes (driver, preprocessor, and several stages, depending on
optimization I think). It seems to be very common for a makefile to spawn
thousands of processes in a very short timespan. autoconf-generated
configure scripts expecially compile many tiny files to test for the
existence of particular keywords or header files.

>
> I have also do a test with simple script.
> This create a lot of processes, but never fails:
> >>> run.sh >>>
> #!/bin/sh
>
> count=1
> while [ $count -lt 10000 ]
> do
> let count++
> ( sleep 5; ) &
> done
> ps
> <<< run.sh <<<
>
>

Perhaps the processes in question have significant cleanup code that must be
done, which the kernel chooses to do after clearing the process descriptor?
For example, are file descriptors and memory cleaned up before or after
setting p->signal = NULL? How about the C runtime library atexit()
callbacks? Maybe one of the processes invoked by the makefile actually sets
p->signal = NULL in user code? (Is this the signal handler managed by
signal() and raise(), or a kernel-internal one?)

Also, is this structure mapped into a writeable page in userspace? Perhaps
a stray pointer is trashing it. (And this would be very
toolchain-dependent, different versions of the compiler and linker would
leave different garbage in memory at a location that might later be
dereference as an lval-pointer). I should think that security concerns
would require kernel-internal data structures to be kept in protected mode
and not mapped as user pages, in which case this wouldn't be a concern, but
if the call is made only from user-mode then maybe it isn't considered a
security risk.


> --
> Henry Nestler
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from
> real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> coLinux-devel mailing list
> coLinux-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/colinux-devel
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.308 / Virus Database: 266.8.4 - Release Date: 3/27/2005
>



--__--__--

Message: 6
Date: Wed, 30 Mar 2005 00:30:16 +0200
From: Florian Schlachter
To: colinux-devel@lists.sourceforge.net
Subject: Re: [coLinux-devel] ReactOS update

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig7FB4132DAD7440A6856635A4
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi Steven,
hi list,

Steven Edwards wrote:
> Just wanted to let y'all know CoLinux now starts on ReactOS. There are still issues that need to
> be addressed with painting of the CoLinux Console's and we lack a proper implementation of the
> service control manager so the driver has to be started by hand. This combined with the fact that
> the Xming server and Win32 VNC client and qusi-working on ROS means in a few months we should be
> able to fully support it.
> [...]

great work! Thank you for that.

-- Florian

--------------enig7FB4132DAD7440A6856635A4
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)

iD8DBQFCSdb4xaun7BQXImgRAhROAKCkMOaFN9v2Gzn0T04IBNo89/6avwCfYytz
rflHHimQzsuia+S/jXL4jR0=
=rQl8
-----END PGP SIGNATURE-----

--------------enig7FB4132DAD7440A6856635A4--


--__--__--

Message: 7
Date: Tue, 29 Mar 2005 23:43:21 +0100
From: Nuno Lucas
To: Ian Bonnycastle
Cc: coLinux Devel
Subject: Re: [coLinux-devel] TAP driver link speed

Ian Bonnycastle, dando pulos de alegria, escreveu :
> The tap driver isn't built with the colinux system at all, is it?
> Every time I build, it never rebuilds the tap driver.
>
> Ian

It is built for the package release, but I confess I don't know what
script does it. That's why it has a different name - "TAP Win32 Adapter
V8 (coLinux)".

I suppose Dan uses some script to build the release packages, but i
never tried to figure out what was it.

Regards,
~Nuno Lucas



--__--__--

_______________________________________________
coLinux-devel mailing list
coLinux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/colinux-devel


End of coLinux-devel Digest


Do you Yahoo!?
Yahoo! Mail - 250MB free storage. Do more. Manage less.