I start some performance tests on -stable and on SuSE 7.1 / 2.4.17. I
don't comment about 'bzero' performance, but when RAM is over, Linux
is much faster. I have no idea what is the algorithm of swapping but it seems that the
granularity of swapping pieces is the key or the importance of
* Dimitar Peikov [EMAIL PROTECTED] [020307 00:45] wrote:
I start some performance tests on -stable and on SuSE 7.1 / 2.4.17. I
don't comment about 'bzero' performance, but when RAM is over, Linux
is much faster. I have no idea what is the algorithm of swapping but it seems that
the
On Wed, Mar 06, 2002 at 09:38:42PM -0600, Mike Meyer wrote:
That is true. C++ is as ugly as C, but has all the problems of Object
Orient Languages.
What are you smoking? :-) No language in this world fits OS development
better than C. IMHO is one of the most beautiful languages ever created.
On Thu, 7 Mar 2002, Dimitar Peikov wrote:
I start some performance tests on -stable and on SuSE 7.1 / 2.4.17. I
don't comment about 'bzero' performance, but when RAM is over, Linux
is much faster. I have no idea what is the algorithm of swapping but it seems that
the granularity of swapping
Please review attached patch, which adds long overdue feature to our
loader(8), allowing it to load sequence of files as a single object.
I don't like this. I would much rather see support for 'split' files
implemented as a stacking filesystem layer like the gzip support, with
the simple
* Dimitar Peikov [EMAIL PROTECTED] [020307 00:45] wrote:
I start some performance tests on -stable and on SuSE 7.1 / 2.4.17. I
don't comment about 'bzero' performance, but when RAM is over, Linux
is much faster. I have no idea what is the algorithm of swapping but it seems that
the
Michael Smith wrote:
Please review attached patch, which adds long overdue feature to our
loader(8), allowing it to load sequence of files as a single object.
I don't like this. I would much rather see support for 'split' files
implemented as a stacking filesystem layer like the gzip
On Wed, Mar 06, 2002 at 05:07:55PM -0800, Terry Lambert wrote:
There are redundant calls to the in_pcblookup_hash() in the
ip_fw_chk() function called via (*ip_fw_chk_ptr)() in the
ip_input path.
in addition to what you're talking about, ipfw will repeat the hash
lookup for every rule it
On Thursday 07 March 2002 12:59 am, Poul-Henning Kamp wrote:
| In message [EMAIL PROTECTED], David O'Brien writes:
| Implies??? I thought I was quite explicit:
|
| to prevent is if (!strcmp(a,b)) which when read is extremely wrong
| of that is actually happening.
|
| ! is pronounced NOT.
Please review attached patch, which adds long overdue feature to our
loader(8), allowing it to load sequence of files as a single object.
I don't like this. I would much rather see support for 'split' files
implemented as a stacking filesystem layer like the gzip support, with
On Wed, 6 Mar 2002, David O'Brien wrote:
Why isn't Eiffel (one of those pure OOL's) used more? BECAUSE IT ISN'T
C. Got it?
I thought it was, because you can't write an event loop without using
(infinite) recursion :-)
jan
PS. This is all very amusing.
--
jan grant, ILRT, University of
On Mar 06, at 11:39 PM, Mike Meyer wrote:
D J Hawkey Jr [EMAIL PROTECTED] types:
First, you're ascribing me to a group I don't belong. While I don't know
Eiffel, or Lisp, or Modula, Snobol, etc., I don't demean them, nor do I
bitch about such-and-such being written with them (well, not
I'd like to develop a kernel module for FreeBSD, able to read write
directly to VGA text-mode screen buffer. I know that this buffer is located
at 0xB8000 in physical address space. But in kernel I must address it using
kernel virtual address space.
Thus, the question is: how can I _correctly_
what would be even nicer is if ipfw found the cached entry and passed it
back to ip_input so it didn't need to :-)
On Thu, 7 Mar 2002, Bill Fumerola wrote:
On Wed, Mar 06, 2002 at 05:07:55PM -0800, Terry Lambert wrote:
There are redundant calls to the in_pcblookup_hash() in the
On 04-Mar-02 Valery N. Khromov wrote:
I'd like to develop a kernel module for FreeBSD, able to read write
directly to VGA text-mode screen buffer. I know that this buffer is located
at 0xB8000 in physical address space. But in kernel I must address it using
kernel virtual address space.
Michael Smith wrote:
Please review attached patch, which adds long overdue feature to our
loader(8), allowing it to load sequence of files as a single object.
I don't like this. I would much rather see support for 'split' files
implemented as a stacking filesystem layer like
On Thu, Mar 07, 2002 at 01:09:40PM +0100, Andy Sporner wrote:
Andy, what were you trying to say?
sarcasm
Or is that the way the Linux kernel converts addresses?
/sarcasm
Cheers,
--
Miguel Mendez - [EMAIL PROTECTED]
GPG Public Key :: http://energyhq.homeip.net/files/pubkey.txt
he said -stable..
what are the malloc options on -stable?
maybe we should make sure that they are null
ln -s /etc/malloc.conf
(I hope that helps) :)
On Thu, 7 Mar 2002, Alfred Perlstein wrote:
* Dimitar Peikov [EMAIL PROTECTED] [020307 00:45] wrote:
I start some performance tests on
Ok :-)
I am caught. I hit the send key by accident when I realized I had misread
the question.
Andy, what were you trying to say?
sarcasm
Or is that the way the Linux kernel converts addresses?
/sarcasm
Probably! :-)
Have you a name yet for 'fish?'
Andy
To Unsubscribe: send mail to
On Thu, 7 Mar 2002 04:01:58 -0800 (PST)
Julian Elischer [EMAIL PROTECTED] wrote:
he said -stable..
what are the malloc options on -stable?
maybe we should make sure that they are null
ln -s /etc/malloc.conf
(I hope that helps) :)
I've tested it with :
cc -O6 -o malloc_test
[This is probably -chat material ...]
On Wed, Mar 06, 2002 at 09:38:42PM -0600, Mike Meyer wrote:
That is true. C++ is as ugly as C, but has all the problems of Object
Orient Languages.
I love this quote (from http://www.paulgraham.com/noop.html):
Object-oriented programming generates a
On Thu, 7 Mar 2002 14:27:59 +0200
Dimitar Peikov [EMAIL PROTECTED] wrote:
On Thu, 7 Mar 2002 04:01:58 -0800 (PST)
Julian Elischer [EMAIL PROTECTED] wrote:
he said -stable..
what are the malloc options on -stable?
maybe we should make sure that they are null
ln -s
On Tue, 5 Mar 2002, Mark Murray wrote:
We did make some enhancements that serve our needs, but may not be
best for everyone. We actually need entropy in quantity since we could be
doing a lot of crypto operations back to back and it can easily become our
worst bottleneck.
Have you
On Thu, Mar 07, 2002 at 08:09:06AM -0600, GB Clark wrote:
On Thu, 7 Mar 2002 14:27:59 +0200
Dimitar Peikov [EMAIL PROTECTED] wrote:
On Thu, 7 Mar 2002 04:01:58 -0800 (PST)
Julian Elischer [EMAIL PROTECTED] wrote:
he said -stable..
what are the malloc options on -stable?
On Thu, 7 Mar 2002 08:09:06 -0600
GB Clark [EMAIL PROTECTED] wrote:
On Thu, 7 Mar 2002 14:27:59 +0200
Dimitar Peikov [EMAIL PROTECTED] wrote:
On Thu, 7 Mar 2002 04:01:58 -0800 (PST)
Julian Elischer [EMAIL PROTECTED] wrote:
he said -stable..
what are the malloc options on
This is a comparison of how fast Linux can do something
STUPID versus how fast a real OS can do something intelligently. Your
test is giving you misleading, and dangerous numbers. Do not go waving them
around until you have actually looked at mallocs behavior on the different
systems.
Here's
On Thu, 7 Mar 2002, cjp wrote:
You are probably misinformed, because FreeBSD also does overcommit of
memory. If you look up the mail archives you will find long battles about
the pros and cons of this.
harti
cThis is a comparison of how fast Linux can do something
cSTUPID versus how fast a
On Thu, 7 Mar 2002 09:42:44 -0500
cjp [EMAIL PROTECTED] wrote:
This is a comparison of how fast Linux can do something
STUPID versus how fast a real OS can do something intelligently. Your
test is giving you misleading, and dangerous numbers. Do not go waving
them around until you have
On Thu, Mar 07, 2002 at 09:42:44AM -0500, cjp wrote:
This is a comparison of how fast Linux can do something
STUPID versus how fast a real OS can do something intelligently. Your
test is giving you misleading, and dangerous numbers. Do not go waving them
around until you have actually
On Thu, Mar 07, 2002 at 04:47:24PM +0200, Peter Pentchev wrote:
On Thu, Mar 07, 2002 at 08:09:06AM -0600, GB Clark wrote:
On Thu, 7 Mar 2002 14:27:59 +0200
Dimitar Peikov [EMAIL PROTECTED] wrote:
On Thu, 7 Mar 2002 04:01:58 -0800 (PST)
Julian Elischer [EMAIL PROTECTED] wrote:
On Thu, 7 Mar 2002 16:36:15 +0100 Erik Trulsson [EMAIL PROTECTED] wrote:
I've tested it with :
cc -O6 -o malloc_test malloc_test.c
That -O6 does not look right from here. Do we support anything over -O2?
ISTR that -On is exactly the same for -O2 for n 2; or is this
Something odd seems to be happening; I'd appreciate look here
suggestions. I suspect mmapped pages aren't being flushed but gawd alone
knows why.
Situation: vmware2, with a fake disk, files in the /external FS
(/external/vmware1/nt1.*).
FBSD-stable. Behaviour's been like this for quite some
Is there any fundamental reason why a page can not be owned by more than
one VM object? If that was the case, the bogus page stuff in vfs_bio.c
could be made cleaner IMHO.
-Zhihui
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
* Jan Grant [EMAIL PROTECTED] [020307 08:12] wrote:
Something odd seems to be happening; I'd appreciate look here
suggestions. I suspect mmapped pages aren't being flushed but gawd alone
knows why.
Situation: vmware2, with a fake disk, files in the /external FS
(/external/vmware1/nt1.*).
* Zhihui Zhang [EMAIL PROTECTED] [020307 08:28] wrote:
Is there any fundamental reason why a page can not be owned by more than
one VM object? If that was the case, the bogus page stuff in vfs_bio.c
could be made cleaner IMHO.
There is only enough linkage in the vm page to support it being
On Thu, 7 Mar 2002, Alfred Perlstein wrote:
* Jan Grant [EMAIL PROTECTED] [020307 08:12] wrote:
Something odd seems to be happening; I'd appreciate look here
suggestions. I suspect mmapped pages aren't being flushed but gawd alone
knows why.
Situation: vmware2, with a fake disk, files
On Thu, 7 Mar 2002, cjp wrote:
In order to handle the kruft that occurs, there is the out of memory killer,
oom_killer.
Which merrily goes through the list of processes, killing off the low priority
processes
until enough memory is free to satisfy what was most recently used. It's the
Maxim Sobolev wrote:
Michael Smith wrote:
Please review attached patch, which adds long overdue feature to our
loader(8), allowing it to load sequence of files as a single object.
I don't like this. I would much rather see support for 'split' files
implemented as a stacking
This is a comparison of how fast Linux can do something
STUPID versus how fast a real OS can do something intelligently. Your
test is giving you misleading, and dangerous numbers. Do not go waving
them around until you have actually looked at mallocs behavior on the
different systems.
On Thu, 7 Mar 2002, Tom wrote:
But when you lose that data, do you not get burnt by that same situation?
I have written a 1GB file to a linux box, and then within 5 seconds of it
finishing, yanked the power cord. When I booted it back up, the file was
*JUST NOT THERE*, I tried it a few
Once Dimitar posts his test program, we'll be able to generate a more
clear picture about what's really happening. Until then, please control
the ranting.
Am I the only one who saw that he attached it to his 1st mail?
Here you go:
#include stdlib.h
#include string.h
#include stdio.h
#define
At any rate, my key point is that the splitting should be invisible, and
*definitely* not pushed up into the loader.
Ok, sounds reasonably. I'll try to reimplement the feature this way.
Thank you for suggestion.
Thanks for doing the real work!
= Mike
--
To announce that there must
Julian Elischer wrote:
what would be even nicer is if ipfw found the cached entry and passed it
back to ip_input so it didn't need to :-)
This is the approach I intended.
The problem is that there are cases where you want the inpcb
for additional processing (e.g. ipfw), and cases where there
On Thu, 7 Mar 2002, Rogier R. Mulhuijzen wrote:
Once Dimitar posts his test program, we'll be able to generate a more
clear picture about what's really happening. Until then, please control
the ranting.
Am I the only one who saw that he attached it to his 1st mail?
Apparently not, I
On Thu, Mar 07, 2002 at 08:09:06AM -0600, GB Clark wrote:
I've tested it with :
cc -O6 -o malloc_test malloc_test.c
That -O6 does not look right from here. Do we support anything over -O2?
And how about some source for malloc_test.c? The fact of running
something at -O6 started
I don't like this. I would much rather see support for 'split' files
implemented as a stacking filesystem layer like the gzip support, with
the simple recognition of 'foo.gz.aa' as the first part of a split
version of 'foo.gz', which in turn is recognised as a compressed version
Simon 'corecode' Schubert wrote:
to everybody who doesn't believe that: it really generates bad code.
i've been having severe problems with my tcp and udp stack lately (on a
i586/mmx machine). guess what, -O2 resulted in code which sometimes
generated bad tcp and/or udp checksums (depending
On Thu, Mar 07, 2002 at 11:41:28AM +, Mike Silbersack wrote:
In any case, we can't make any useful comparisons until Dimitar posts the
source to his test program.
Dimitar, post the source for the test program!
Does your MTA strip attachments?
- I 1 no description
Zhihui Zhang wrote:
Is there any fundamental reason why a page can not be owned by more than
one VM object? If that was the case, the bogus page stuff in vfs_bio.c
could be made cleaner IMHO.
When you need to reclaim the page, you would have to identify
all owners, rather than a single
I'd like to develop a kernel module for FreeBSD, able to read write
directly to VGA text-mode screen buffer. I know that this buffer is located
at 0xB8000 in physical address space. But in kernel I must address it using
kernel virtual address space.
Thus, the question is: how can I
:...
: This is a comparison of how fast Linux can do something
: STUPID versus how fast a real OS can do something intelligently. Your
: test is giving you misleading, and dangerous numbers. Do not go waving
: them around until you have actually looked at mallocs behavior on the
:
which one does the data come from?
On Thu, 7 Mar 2002, Zhihui Zhang wrote:
Is there any fundamental reason why a page can not be owned by more than
one VM object? If that was the case, the bogus page stuff in vfs_bio.c
could be made cleaner IMHO.
-Zhihui
To Unsubscribe: send mail
Hmm. well, I don't think this test is very meaningful. If the machines
have 256M of ram and the test is doing a two-swipe access of 256M of VM.
This doesn't represent any real test and I would not be surprised by
the difference in timing.
It all comes down to how much
The bogus page is owned by the system object, not by individual objects
associated with the files. If a page could be owned by more than one
objects, then we could let the object associated with a file to own the
bogus page.
-Zhihui
On Thu, 7 Mar 2002, Julian Elischer wrote:
which one does
#include stdlib.h
#include string.h
#include stdio.h
#define MALLOC_SIZE 1024*1024*256
int main(int argc, char **argv) {
char *ptr;
int i, i_count;
int j;
ptr = (char *) malloc(MALLOC_SIZE);
bzero(ptr, MALLOC_SIZE);
The bzero is unnecessary on FreeBSD. Allocated
:which one does the data come from?
:
:On Thu, 7 Mar 2002, Zhihui Zhang wrote:
:
:
: Is there any fundamental reason why a page can not be owned by more than
: one VM object? If that was the case, the bogus page stuff in vfs_bio.c
: could be made cleaner IMHO.
:
: -Zhihui
:
I think
Michael Smith wrote:
I don't like this. I would much rather see support for 'split' files
implemented as a stacking filesystem layer like the gzip support, with
the simple recognition of 'foo.gz.aa' as the first part of a split
version of 'foo.gz', which in turn is recognised as
:ptr = (char *) malloc(MALLOC_SIZE);
:bzero(ptr, MALLOC_SIZE);
:
:The bzero is unnecessary on FreeBSD. Allocated pages start out
:zero'ed. Part of the performance issue might be that FreeBSD is
:being asked to zero the pages twice, instead of once.
malloc() does not guarentee a
On Thu, 07 Mar 2002 10:49:22 -0800 Terry Lambert [EMAIL PROTECTED] wrote:
Simon 'corecode' Schubert wrote:
to everybody who doesn't believe that: it really generates bad code.
i've been having severe problems with my tcp and udp stack lately (on a
i586/mmx machine). guess what, -O2
Matthew Dillon wrote:
:The bzero is unnecessary on FreeBSD. Allocated pages start out
:zero'ed. Part of the performance issue might be that FreeBSD is
:being asked to zero the pages twice, instead of once.
malloc() does not guarentee a zero'd page, even though the
side effect of
Michael Smith wrote:
I don't like this. I would much rather see support for 'split' files
implemented as a stacking filesystem layer like the gzip support, wit
h
the simple recognition of 'foo.gz.aa' as the first part of a split
version of 'foo.gz', which in turn is
Simon 'corecode' Schubert wrote:
Are you using NAT?
yep.
The libalias incremental checksum calculation is incorrect;
it assumes that a two's complement network order underflow
will result in the same value as a one's complement host
order underflow. This results in off-by-one
Michael Smith wrote:
Should you care to be informed rather than playing from the sidelines,
see the primitive 'stacking' used to implement transparent gzipped file
support in libstand.
The only place this is referred to as a stack at all is in
one comment in the libstand.3 man page, which
Michael Smith wrote:
Should you care to be informed rather than playing from the sidelines,
see the primitive 'stacking' used to implement transparent gzipped file
support in libstand.
The only place this is referred to as a stack at all is in
one comment in the libstand.3 man page,
On Thu, Feb 28, 2002 at 01:26:49AM -0500, Clark C . Evans wrote:
| | http://people.freebsd.org/~bsd/cdroot/
|
| Ok. I've tried this route and it seems to be working,
| thank you all so much for your help and pointers.
Thus far, cdroot has worked well for me. I have a PleXwriter
23/10/40A and
At 2:16 AM -0500 3/7/02, Brian T.Schellenberger wrote:
Maybe your brain has gotten used to it, but to us ordinary
mortals, even us ordinary mortals who've been slogging C
code for time periods that can be measured in decades
(yikes!), it is very tempting to read
if (!strcmp(a,b,l))
as if the
In a message written on Thu, Mar 07, 2002 at 03:27:49PM -0500, Garance A Drosihn wrote:
As to the wording, PHK suggested that the wording for this
rule in style(9) be changed:
- - -
get rid of the word boolean, ie: change
Do not use ! for tests unless it is a boolean, e.g. use
to
Another point that I should bring up in regards to swap performance:
systems that require good swap performance will almost always have
more then one physical disk to swap to. FreeBSD is very good at
paging to swap with a single disk, but it kicks ass paging to swap
with
Miguel Mendez [EMAIL PROTECTED] types:
On Wed, Mar 06, 2002 at 09:38:42PM -0600, Mike Meyer wrote:
That is true. C++ is as ugly as C, but has all the problems of Object
Orient Languages.
What are you smoking? :-) No language in this world fits OS development
better than C. IMHO is one of
Michael Smith wrote:
The only place this is referred to as a stack at all is in
one comment in the libstand.3 man page, which hardly excuses
you ripping me a new one.
So because I called it a stack I *must* have been referring to the
kernel, not actually the loader (since that's only
In message: 009c01c1c356$93e13be0$c80ca8c0@khromovv
Valery N. Khromov [EMAIL PROTECTED] writes:
: I'd like to develop a kernel module for FreeBSD, able to read write
: directly to VGA text-mode screen buffer. I know that this buffer is located
: at 0xB8000 in physical address space.
[reposted from FreeBSD-questions]
I'm writing a network device driver. I'm using FreeBSD 4.4-RELEASE.
I can't get BPF to work; it dereferences a nil pointer.
Attached below is some BPF code. As I read it, bpfattach() is passed
an ifp (struct ifnet *). It mallocs a 'bpf_if' (1) and installs
On Thu, Mar 07, 2002 at 03:29:44PM -0800, David Boggs wrote:
Attached below is some BPF code. As I read it, bpfattach() is passed
an ifp (struct ifnet *). It mallocs a 'bpf_if' (1) and installs the ifp
in it (2). Then it uses this pointer to ZERO a pointer in the ifp named
if_bpf (3)
On Thu, Mar 07, 2002 at 03:51:41AM -0800, Julian Elischer wrote:
what would be even nicer is if ipfw found the cached entry and passed it
back to ip_input so it didn't need to :-)
i think this entire idea of cacheing it in ip_input() is a bad idea, no
offense terry.
first, having a uid or
A couple of comments:
- You can always cache the pcb the first time it's used, and then have it
available for future use. I agree with your concerns about generating
it every time -- that would be a disaster for routers where no packets
are even delivered locally. :-)
- The uid/gid code
On Thu, Mar 07, 2002 at 11:03:19PM -0500, Robert Watson wrote:
A couple of comments:
- You can always cache the pcb the first time it's used, and then have it
available for future use. I agree with your concerns about generating
it every time -- that would be a disaster for routers
Bill Fumerola wrote:
On Thu, Mar 07, 2002 at 03:51:41AM -0800, Julian Elischer wrote:
what would be even nicer is if ipfw found the cached entry and passed it
back to ip_input so it didn't need to :-)
i think this entire idea of cacheing it in ip_input() is a bad idea, no
offense terry.
Bill Fumerola wrote:
i think that ip_fw_chk() taking _8_ arguments is getting a bit obscene.
ip_fw_chk should be obscene and not heard? 8-).
we're talking about an optimization that less then .1% of our userbase
will ever take advantage of v. a pessimization (additional argument in
the
* Terry Lambert [EMAIL PROTECTED] [020307 22:24] wrote:
If it were just the pcbhash, I think I'd go with a btree...
or to make Alfred happy... a skiplist... ;^).
Argh, someone hand me the firehose, Terry seems really thirsty...
--
-Alfred Perlstein [[EMAIL PROTECTED]]
To Unsubscribe: send
On Thu, 7 Mar 2002 11:41:28 + (GMT)
Mike Silbersack [EMAIL PROTECTED] wrote:
On Thu, 7 Mar 2002, cjp wrote:
In order to handle the kruft that occurs, there is the out of memory
killer, oom_killer.
Which merrily goes through the list of processes, killing off the low
priority
On Thu, 7 Mar 2002 10:42:05 -0800
David O'Brien [EMAIL PROTECTED] wrote:
On Thu, Mar 07, 2002 at 08:09:06AM -0600, GB Clark wrote:
I've tested it with :
cc -O6 -o malloc_test malloc_test.c
That -O6 does not look right from here. Do we support anything over
-O2?
And how
On Thu, 7 Mar 2002, Alfred Perlstein wrote:
* Terry Lambert [EMAIL PROTECTED] [020307 22:24] wrote:
If it were just the pcbhash, I think I'd go with a btree...
or to make Alfred happy... a skiplist... ;^).
Argh, someone hand me the firehose, Terry seems really thirsty...
--
-Alfred
On Thu, 07 Mar 2002 11:19:25 -0800
Terry Lambert [EMAIL PROTECTED] wrote:
#include stdlib.h
#include string.h
#include stdio.h
#define MALLOC_SIZE 1024*1024*256
int main(int argc, char **argv) {
char *ptr;
int i, i_count;
int j;
ptr = (char *)
On Thu, 7 Mar 2002 11:12:03 -0800 (PST)
Matthew Dillon [EMAIL PROTECTED] wrote:
Hmm. well, I don't think this test is very meaningful. If the
machines have 256M of ram and the test is doing a two-swipe access of
256M of VM. This doesn't represent any real test and I would not be
* Mike Silbersack [EMAIL PROTECTED] [020307 22:35] wrote:
On Thu, 7 Mar 2002, Alfred Perlstein wrote:
* Terry Lambert [EMAIL PROTECTED] [020307 22:24] wrote:
If it were just the pcbhash, I think I'd go with a btree...
or to make Alfred happy... a skiplist... ;^).
Argh, someone
On Thu, 7 Mar 2002, Alfred Perlstein wrote:
Do a web search. It's basically a way to have a linked list that
you can do nearly a binary search on, however it costs several
additional linkages. It was also the pool on the roof trick
we'd do to the new guy at clickarray.
Hm, did you guys
I'm trying to debug a KLD in -stable and I can't get gdb to show me a
stack trace with the extra info (variable names, line numbers etc..)
I've built a debugging kernel and copied it to the debug machine and I
can connect to the machine to be debugged OK, but none of the back
traces have the
87 matches
Mail list logo
