Julian Elischer wrote:
but if you did find some old ksocket based code sitting around,
i'd love to try it in -current and work on the bottlenecks..
I'm sure I don't have it any more, unfortunately. It was six years old,
and I just moved into a smaller house and threw out a half dozen old
co
Julian Elischer wrote:
I would actually like to address the performance issues.
is there any chance the oldest version (4.x based) might be released,
or at least it would be nice to get the code snippet that attaches to eh
ng_ksocket and
reads and writes the stream..
I could make a TCP ECHO
Nicolas Cormier wrote:
Thanks a lot for your answer, a last question "why did you not used
so* functions ?"
Using ng_ksocket is almost the same as using the so* functions, since
the ksocket methods call the so* functions. But by using netgraph, you
get a nice management interface, too.
F
ocketvar.h (so*).
What's the easy way to create a basic tcp server
(create/bind/listen/accept/send/recv) : use netgraph's ksocket or so*
?
Thanks in advance !
PS: the whole job must be done in the kernel.
yes it can (and has been) done..
John Polstra did it many years ago.. using netgr
On 17-Jul-2006 Alex Zbyslaw wrote:
> I was monitoring a machine with "systat -vmstat" and noticed something
> about the interrupts and I don't know if it's a problem or not. If it
> is a problem, is there anything I can do about it?
>
> The interrupts for the network interface (em0) on irq 64 exac
On 05-Apr-2005 Matthew D. Fuller wrote:
> I've noticed some strange behavior suddenly out of CVSup. I refuse
> all Attic files in ports, and that doesn't seem to be working right
> all of a sudden.
>
> My best guess is that it's something due to the recent patch to cvsupd
> to handle INDEX issues
On 18-Nov-2003 Brett L. Brown wrote:
>
> I'm looking for help on with a CVSUP problem.
>
> I'm trying to run CVSUP with a supfile, I'm typing:
>
> cvsup ports-supfile
>
> and receiving the following:
>
> Cannot get IP address of my own host -- is its hostname correct?
This problem is discusse
On 17-Sep-2003 Michael Edenfield wrote:
> * John Polstra <[EMAIL PROTECTED]> [030916 21:27]:
>
>> True, we could probably do it. I guess we'd have to generate a few
>> random and unlikely queries, try them, and see if all/most of them
>> resolve to the same
On 17-Sep-2003 M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> John Polstra <[EMAIL PROTECTED]> writes:
>: On 16-Sep-2003 M. Warner Losh wrote:
>: > I think we should put a filter for this nonsense into the base
>: > system. Hack the resolv
On 16-Sep-2003 M. Warner Losh wrote:
> I think we should put a filter for this nonsense into the base
> system. Hack the resolve to filter out the adddress, and hack bind to
> filter it out too. that way we can leverage our position in the name
> servers in the world to do something about this BS
On 16-Sep-2003 Dan Langille wrote:
> On 16 Sep 2003 at 10:23, Clifton Royston wrote:
>
>> In the meantime I'm trying to figure out if there's some simple hack
>> to disregard these wildcard A records, short of requesting zone
>> transfers of the root nameservers (e.g. via peering with
>> f.root-
In article <[EMAIL PROTECTED]>,
Brian Reichert <[EMAIL PROTECTED]> wrote:
> On Sat, Aug 02, 2003 at 03:22:06PM -0700, John Polstra wrote:
> > Yes: look for a different approach, or at least backup your local
> > repository frequently. There are known bugs in CVSup whic
se issues any time soon. So my advice is,
don't use the CVS_LOCAL_BRANCH_NUM feature.
John
--
John Polstra
John D. Polstra & Co., Inc.Seattle, Washington USA
"Two buttocks cannot avoid friction." -- Malawi saying
ut making them
common.
That last paragraph suggests that maybe FreeBSD's compiler is
configured slightly wrong, such that it does not do what the
paragraph says. In any case, try adding this option to your
compiles on FreeBSD and see i
that was not generated by the kill() function,
the sigqueue() function, or the raise() function as defined by
the C Standard.
It's in ANSI/IEEE Std 1003.1 section 3.3.1.3.
POSIX permits the FreeBSD behavior but does not mandate it.
John
--
John Polstra
John D. Polstra & Co., Inc.
n issue. In -current only netstat and systat
needed to be recompiled. I haven't heard about it affecting any
ports.
John
--
John Polstra
John D. Polstra & Co., Inc.Seattle, Washington USA
"Disappointment is a good sign of basic intelligence." -- C
In article <[EMAIL PROTECTED]>,
Doug White <[EMAIL PROTECTED]> wrote:
> While we're nitpicking:
>
> On Wed, 11 Sep 2002, John Polstra wrote:
>
> > All of the documentation and errata for the BCM570x chips are
> > protected by NDA, just like every ot
In article <[EMAIL PROTECTED]>,
Nate Lawson <[EMAIL PROTECTED]> wrote:
> On Mon, 9 Sep 2002, John Polstra wrote:
> >
> > BSD/OS has a little state machine in its sio driver which notices
> > if something looking like a kgdb packet comes in and interrupts
&g
In article <[EMAIL PROTECTED]>,
Doug Ambrisko <[EMAIL PROTECTED]> wrote:
> John Polstra writes:
> | If you want a gigabit interface that is likely to keep working in
> | FreeBSD, your only option is to use the Intel chips and the "em"
> | driver. It's ou
to keep working in
FreeBSD, your only option is to use the Intel chips and the "em"
driver. It's our only gigabit driver that's maintained by somebody
who has unrestricted access to the documentation and errata.
John
--
John Polstra
John D. Polstra & Co., Inc.
> Yes, the bge driver in 4.6 is broken. John Polstra put fixes into
> -stable which will show up in 4.7.
I doubt that those fixes will solve Birger's problem, unfortunately.
John
--
John Polstra
John D. Polstra & Co., Inc.Seattle, Washington
e had this feature too. It
should obviously be under the control of a sysctl to protect against
accidental entry into the debugger.
Another nice thing about BSD/OS is that when you exit kgdb, the target
OS automatically starts running again. So you can enter and exit the
debugger painlessly, as man
them -- I believe before 4.5
was released. There have been recent reports that there are still
problems when newreno is enabled. So your best bet is to update at
least to 4.5-RELEASE and turn newreno off.
John
--
John Polstra
John D. Polstra & Co., Inc.S
try the
new driver to confirm that it really solves the problem?
John
--
John Polstra
John D. Polstra & Co., Inc.Seattle, Washington USA
"Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa
To Unsubscribe: send mail to [EMAIL P
of the packet, i.e., the first two bytes
of the destination ethernet address. If we could ignore promiscuous
mode and multicast, we could guess those bytes based on our own
Ethernet address ... nah, that's Just Too Evil. :-)
John
--
John Polstra
John D. Polstra & Co., Inc.
ther experiments I need
done currently.
I agree with you about the noise. I think I'd rather spend the day
in a room with a swarm of hornets than with the Dell 2650. When I
was working with that machine I wore a pair of industrial-strength
ear-protecting headphones, and my ears were st
hread.php3?subject=Broadcom+BCM5701+GigE+Ethernet+problems%3F%3F&list=159
>
> I grabed the latest -STABLE branch but it still doesn't work for the Dell
> 2650. Any clues?
Just one clue. Saying that something "doesn't work" without providing
any details doesn't m
In article <[EMAIL PROTECTED]>,
Dan Langille <[EMAIL PROTECTED]> wrote:
> On 4 Jun 2002 at 8:37, John Polstra wrote:
> > I'll help you figure this out if you'll send me the following
> > information:
>
> Thanks John.
>
> >
> > Th
line used to invoke cvsup on the client machine.
The output of
find /usr/websites/freshports/sup -name 'refuse*'
on the client machine.
The output of "cvsup -v" on the client and "cvsupd -v" on the
server. Please be careful to ensure th
rve fbsd-phpAds
>
> Normally a refuse file would go into /home/freebsddiary/sup/ where
> col is the name of the collection (in this case it's fbsd-phpAds). With
> the above setup I can have only one refuse file. I need two.
Simply use different "base&
eemed
promising. Even better might be to use -gdwarf -g3, which in theory
at least would provide information about #defines.
For well-behaved structs, it's possible that rpcgen could be hacked up
to do what you want.
John
--
John Polstra
John D. Polstra & Co., Inc.
as a dumb idea: broaden your minds. It's
extremely useful for certain specialized applications. One obvious
example is as part of a testbed for performance testing various kinds
of network appliances.
John
--
John Polstra
John D. Polstra & Co., Inc.Seattle, Washi
ainer of the dynamic
linker. :-)
Sorry I haven't replied to your earlier posting yet. I haven't
really had time to give it much thought yet.
John
--
John Polstra
John D. Polstra & Co., Inc.Seattle, Washington USA
"Disappointment is a good sign of bas
ot;which is" in that last one is just because
C lets you get sloppy with the ordering of the outermost keywords.
The pedantically correct way to declare a pointer to volatile struct
is like this:
struct timecounter volatile *timecounter;
/* "Timecounter is a pointer to a volatile
and the other acting as the server) it can generate
around 5 (actually I think it's more than that) full web sessions
per second. Also, you can dial in any rate you want, and it will
generate that rate very precisely. Lots of fun!
John
--
John Polstra
John D. Polstra & Co., Inc.
In article <[EMAIL PROTECTED]>,
Poul-Henning Kamp <[EMAIL PROTECTED]> wrote:
> In message <[EMAIL PROTECTED]>, John Polstra writes:
> Could you try this combination:
>
> NTIMECOUNTER = HZ (or even 5 * HZ)
> tco_method = 0
> no splhigh prot
In article <[EMAIL PROTECTED]>,
Poul-Henning Kamp <[EMAIL PROTECTED]> wrote:
> In message <[EMAIL PROTECTED]>, John Polstra writes:
> >I don't follow that. As I read the code, the "current" timecounter
> >is only advanced every second -- not ev
y second -- not every 1/HZ seconds. Why should
more of them be needed when HZ is large?
> You didn't say if you ran with standard NTIMECOUNTER right now,
> but 5 would be awfully short time at HZ=1: 500 usec...
Well, microseconds aren't what they used to be ... :-) But isn
In article <[EMAIL PROTECTED]>,
Poul-Henning Kamp <[EMAIL PROTECTED]> wrote:
> In message <[EMAIL PROTECTED]>, John Polstra writes:
> >Yes, I think you're onto something now. It's a 550 MHz. machine, so
> >the TSC increments every 1.82 nsec. And 1.82
In article <[EMAIL PROTECTED]>,
Poul-Henning Kamp <[EMAIL PROTECTED]> wrote:
>
> Sanity-check: this is NOT a multi-CPU system, right ?
Right. These are all single-CPU systems with non-SMP -stable
kernels.
John
--
John Polstra
John D. Polstra & Co., Inc.
In article <[EMAIL PROTECTED]>,
Poul-Henning Kamp <[EMAIL PROTECTED]> wrote:
> In message <[EMAIL PROTECTED]>, John Polstra writes:
> >In article <[EMAIL PROTECTED]>,
> >John Polstra <[EMAIL PROTECTED]> wrote:
> >
> >Another interestin
In article <[EMAIL PROTECTED]>,
John Polstra <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> Poul-Henning Kamp <[EMAIL PROTECTED]> wrote:
> > In message <[EMAIL PROTECTED]>, John Polstra writes:
> >
> > Can you try to MFC
In article <[EMAIL PROTECTED]>,
Poul-Henning Kamp <[EMAIL PROTECTED]> wrote:
> In message <[EMAIL PROTECTED]>, John Polstra writes:
>
> Can you try to MFC rev 1.111 and see if that changes anything ?
That produced some interesting results. I am still testing under
v
In article <[EMAIL PROTECTED]>,
Poul-Henning Kamp <[EMAIL PROTECTED]> wrote:
> In message <[EMAIL PROTECTED]>, John Polstra writes:
>
> >Agreed. But in the cases I'm worrying about right now, the
> >timecounter is the TSC.
>
> Now, *that* is ve
In article <[EMAIL PROTECTED]>,
Poul-Henning Kamp <[EMAIL PROTECTED]> wrote:
> In message <[EMAIL PROTECTED]>, John Polstra writes:
> >In article <[EMAIL PROTECTED]>,
> >John Baldwin <[EMAIL PROTECTED]> wrote:
> >>
> >> &g
In article <[EMAIL PROTECTED]>,
Poul-Henning Kamp <[EMAIL PROTECTED]> wrote:
> In message <[EMAIL PROTECTED]>, John Polstra writes:
> >That's the global variable named "timecounter", right? I did notice
> >one potential problem: that variab
layed by much. The only thing that can block hardclock is another
hardclock, an splclock, or an splhigh. And, maybe, splstatclock. I'm
talking about -stable here, which is where I'm doing my experiments.
John
--
John Polstra
John D. Polstra & Co., Inc.
t updates
> the timecounter proper. If you save the delta value in the timecounter
> and zero it when it's updated, you can catch this.
>
> You can rule this out by using getmicroptime() rather than
> microuptime(); it may return the same value twice, which isn't
>
In article <[EMAIL PROTECTED]>,
Dominic Marks <[EMAIL PROTECTED]> wrote:
> On Mon, Feb 04, 2002 at 01:21:25PM -0800, John Polstra wrote:
> > I'm trying to understand the timecounter code, and in particular the
> > reason for the "microuptime went backwards&qu
I'm trying to understand the timecounter code, and in particular the
reason for the "microuptime went backwards" messages which I see on
just about every machine I have, whether running -stable or -current.
This problem is usually attributed to too much interrupt latency. My
question is, how much
relationships between the shared objects. That's done
using the "dldags" and "dlmembers" members of the Obj_Entry structure.
John
--
John Polstra
John D. Polstra & Co., Inc.Seattle, Washington USA
"Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
ing
properly with the 5701, including understanding and eliminating those
"gigabit link up" messages.
John
--
John Polstra
John D. Polstra & Co., Inc.Seattle, Washington USA
"Disappointment is a good sign of basic intelligence." -- Chögyam Trung
Well, it seems to work OK with the Linux driver.
> Where can you get the Linux driver from?
I believe it's in the standard Linux kernel. Just grab the latest one
from kernel.org.
John
--
John Polstra
John D. Polstra & Co., Inc.Seattle, Washingt
some 5701 revs'; and forces master
> mode in some revs, to avoid a CRC bug. Caveat emptor.)
Yes, there are quite a few mysterious workarounds in that driver.
John
--
John Polstra
John D. Polstra & Co., Inc.Seattle, Washington USA
"Disappointment is a
In article <[EMAIL PROTECTED]>,
E.B. Dreger <[EMAIL PROTECTED]> wrote:
>
> I'd like to load an executable, .so, or .o, and _manually_ handle
> the symbol fixups. I looked at dlfcn.c, but found next to
> nothing there. Next stop: kernel source?
Look in "src/l
obably native. Linux programs use the Linux dynamic linker, not
ours.
John
--
John Polstra
John D. Polstra & Co., Inc.Seattle, Washington USA
"Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa
To Unsubscribe: send mail to
ithout an outcry so I don't
> see much justification for putting them into the security branch.
>
> -Matt
Yep, I agree 100%. The purpose of the security branch was spelled
out clearly from day one. People who want something else ca
In article <[EMAIL PROTECTED]>,
Andre Oppermann <[EMAIL PROTECTED]> wrote:
> John Polstra wrote:
> > Maybe you have an old version of the driver. I have
> > e1000-3.1.23.tar.gz, which I grabbed from developer.intel.com a few
> > weeks ago. I grepped all of t
In article <[EMAIL PROTECTED]>,
Andre Oppermann <[EMAIL PROTECTED]> wrote:
> John Polstra wrote:
> > That last bit is incorrect. The Intel driver for Linux is released
> > under a 3-clause BSD license.
>
> I doesn't look like a clean BSD license thought..
her alternative I've found.
John
--
John Polstra
John D. Polstra & Co., Inc.Seattle, Washington USA
"Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
BSD license.
John
--
John Polstra
John D. Polstra & Co., Inc.Seattle, Washington USA
"Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
structure is valid, including sin_zero. *Grumble* I wish they had
never put the sin_zero member in there in the first place.
John
--
John Polstra
John D. Polstra & Co., Inc.Seattle, Washington USA
"Disappointment is a good sign of basic intelligence." -- C
d be
possible to add a new signal SIGFAULT which could be caught to handle
this case. Then the wrappers wouldn't be needed. It could still be
backward compatible; an application which didn't install a SIGFAULT
handler would get EFAULT returns in the traditional way. "One Of
Thes
IL PROTECTED]>.
Thanks,
John
--
John Polstra [EMAIL PROTECTED]
John D. Polstra & Co., Inc.Seattle, Washington USA
"Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa
To Unsubscribe: se
In article <[EMAIL PROTECTED]>,
Terry Lambert <[EMAIL PROTECTED]> wrote:
> John Polstra wrote:
> > I have had this on my to-do list for a long time, but I have no idea
> > if or when it'll ever get implemented. It would require a focused
> > period of work
In article <[EMAIL PROTECTED]>, Nate
Williams <[EMAIL PROTECTED]> wrote:
> So, you're saying that the person would choose the branch (which may
> be RELENG_4 *OR* HEAD).
Yep. For instance, a company might have a product that's based on
RELENG_4, but with some local mods. So FreeBSD-4.x is in e
lemented. It would require a focused
period of working on it that I just don't have these days. Maybe if
the economy gets worse ...
John
--
John Polstra [EMAIL PROTECTED]
John D. Polstra & Co., Inc.Seattle, Washingto
n't want to use multiple vendor branches -- trust me. :-)
Use two repositories instead, or use perforce.
John
--
John Polstra [EMAIL PROTECTED]
John D. Polstra & Co., Inc.Seattle, Washington USA
"Disappointme
Correcting myself ...
In article <[EMAIL PROTECTED]>,
John Polstra <[EMAIL PROTECTED]> wrote:
> There is very little bulk copying in the IP forwarding path of the
> kernel, so the higher bandwidth of RAMBUS would not provide much
> benefit. I suppose it would speed up the
r. There is very little bulk copying in the IP forwarding path
of the kernel, so the higher bandwidth of RAMBUS would not provide
much benefit. I suppose it would speed up the DMA transfers between
the NICs and RAM. But I still bet overall performance wouldn't be
improved by the use of RAMBU
that's in
> the base system, or would that be overkill?
I'm more or less neutral on that, but since the files are so big I
bet bzip2 would be almost too slow to bear at reboot time.
John
--
John Polstra [EMAIL PROTECTED]
John D. Polstr
r. I tested it with both gzipped and full-size kernels, in
-current and -stable on the i386 and in -slightlystale on the Alpha.
John
--
John Polstra [EMAIL PROTECTED]
John D. Polstra & Co., Inc.Seattle, Washington US
In article <[EMAIL PROTECTED]>,
John Baldwin <[EMAIL PROTECTED]> wrote:
>
> Looks good to me, but I'm only somewhat familiar with libstand. :)
Thanks for taking a look at it. Matt Dillon also reviewed it and gave
it a clean bill of health. He made a suggestion for making the code a
bit smalle
y avoiding a reverse seek
on the gzipped data stream.
The bug is present in both -current and -stable. This patch is
relative to -stable, but it applies cleanly to -current too.
John
--
John Polstra [EMAIL PROTECTED]
John D
estion there which directly addresses this problem.
John
--
John Polstra [EMAIL PROTECTED]
John D. Polstra & Co., Inc.Seattle, Washington USA
"Disappointment is a good sign of basic intelligence." -- Chögyam Trun
In article <[EMAIL PROTECTED]>,
Julian Elischer <[EMAIL PROTECTED]> wrote:
[concerning my fixes for ng_ksocket nodes to handle TCP operations]
> If you send me the files I can diff them and commit them.
> (of course you are welcome to do it yourself at your own pace if you wish)
Hmm, I just mi
In article <[EMAIL PROTECTED]>,
Julian Elischer <[EMAIL PROTECTED]> wrote:
>
> The netgraph 'accept' handling IS implemented by someone..
> I can find it and add it if needed..
I've got that all fixed, and will commit it as soon as I can --
within the ne
> with `L'.
>
> I ask because I'm porting something to Solaris and it seems rather
> odd that the solaris ld doesn't have this option.
It's not important. It just makes the output file smaller. I
wouldn't be surprised if the
In article <[EMAIL PROTECTED]>,
Jonathan Chen <[EMAIL PROTECTED]> wrote:
>
> Incidentally, I'm still curious, what does the POSIX spec say all this?
As far as I know, poll is not described by any POSIX standards.
John
--
John Polstra
reap any additional benefit from knowing.
Opinions on that seem to vary wildly. Mike said just the opposite.
Since that was not the point I addressed, I'll let the two of you
debate it out.
John
--
John Polstra [EMAIL PROTECTED]
John D. Pols
. As far as I can tell, it works
> :for the Pentium Pro and subsequent processors.
> :
> :John
> :--
> : John Polstra [EMAIL PROTECTED]
>
> Well, first of all the page coloring is not pointless with the
> size
s at least on the i386 with the CPUID instruction,
initial %eax == 2? It returns cache size, associativity, and line
size for both the L1 and L2 caches. As far as I can tell, it works
for the Pentium Pro and subsequent processors.
John
--
John Polstra
In article <[EMAIL PROTECTED]>,
Sheldon Hearn <[EMAIL PROTECTED]> wrote:
> On Sun, 29 Jul 2001 14:26:41 MST, John Polstra wrote:
>
> > I don't understand what this has to do with how the kernel is
> > stripped.
>
> The current modules build attached
is why it's worth going to all this trouble.
>
> Why not simply build all the modules with debugging support compiled in
> (assuming debugging support was requested for the kernel), and strip
> them at install time (install -s)?
I don
rw 2 2
In each case the other system's root filesystem is mounted as
"/stable" or "/current" so you can tweak one system from the other.
This is particularly handy on the Alpha, where -current periodically
falls on its spear and makes a bloody mess.
John
--
ADONLY
20 .note 0050 000015c4 2**0
CONTENTS, READONLY
John
--
John Polstra [EMAIL PROTECTED]
John D. Polstra & Co., Inc.Seattle, Washington USA
"
y doing things that hackish way. But it can be prone to
> error. The proper way is to ``cvs add'' them in a directory checked out
> on the branch.
I agree, that's the proper way to do it. The net effect is the same:
it adds the RELENG_4 tag to the files.
John
--
pkg-descr,v
> SetAttrs ports/emulators/sim6811/pkg-plist,v
> TreeList failed: Read failure from "/usr/sup/ports-all/checkouts.cvs": Input/output
>error
This is an I/O error happening on your own system when cvsup is trying
to read the file mentioned in the message.
John
-
In article <[EMAIL PROTECTED]>,
Alfred Perlstein <[EMAIL PROTECTED]> wrote:
> I can't seem to get a crashdump, is there a way to take a
> ddb crash address: "Stopped at lf_setlock+0x52"
> and boot later and see what line of code that's on?
Assuming you have a corresponding kernel with debuggin
devices;
> >
> > Yes. It's not a lot of work.
>
> that would be GREAT for cd recording on IDE CD-RW (one will be able to
> use cdrdao and cdrecord instead of burncd)
Yes! It would definitely be nice if cdrecord worked with ATAPI
CD-RW drives on Fre
gt; code-in-progress.
No, I wish I had time for that, but I don't.
Another option for you would be to build src/libexec/rtld-elf with -g
and try to debug it yourself using gdb.
John
--
John Polstra [EMAIL PROTECTED]
John D. Polstra & Co.,
list, since we are exiting. */
}
If you can come up with a reasonably self-contained test case that
shows a bug in this, I'll be happy to take a look at it.
John
--
John Polstra [EMAIL PROTECTED]
John D. Polstra & Co., Inc.
t implemented by other means. The folks who run the mirrors in Japan
have a very nice setup which uses SNMP to query the number of active
CVSup clients on each mirror. They don't do automatic load balancing
with it currently, but they make some nice graphs available on the web
for people
Just a note to let you know that cvsup7.freebsd.org is back in
service.
John
--
John Polstra [EMAIL PROTECTED]
John D. Polstra & Co., Inc.Seattle, Washington USA
"Disappointment is a good sign of basic int
In article <[EMAIL PROTECTED]>,
John Polstra <[EMAIL PROTECTED]> wrote:
> CVSup7.FreeBSD.org will be down for at least a few hours this
> afternoon (Pacific time) so that we can perform a hardware upgrade.
> It may be down again later in the week as we rearrange things on
CVSup7.FreeBSD.org will be down for at least a few hours this
afternoon (Pacific time) so that we can perform a hardware upgrade.
It may be down again later in the week as we rearrange things on
the disks and bring the OS up to date. Thanks in advance for your
patience.
John
--
John Polstra
and
the dynamic linker (all together in one shared library) were mapped
between 0x800 and 0x8048000. But that is just a guess. Most
modern libcs wouldn't fit in that amount of space these days.
John
--
John Polstra [EMAIL PROTECTED]
0, thereby avoiding the need to do any
run-time relocations on them.
In any case, all ELF-based systems on the x86 architecture seem to
use this same address. On other architecutures such as the Alpha
it is entirely different, of course.
John
--
John Polstra
In article <[EMAIL PROTECTED]>,
John Polstra <[EMAIL PROTECTED]> wrote:
>
> I've got a Belkin OmniView Pro 8-Port KVM switch which thinks it's
> much smarter than it really is. When I try to use the mouse through
> it with FreeBSD (-current from around Christm
In article <[EMAIL PROTECTED]>,
jack <[EMAIL PROTECTED]> wrote:
>
> I have a Brand X KVM which also claims Intellimouse support.
> I've found that if the switch is set to a machine when that
> machine boots all is well, if I boot a machine with a different
> one active on the KVM when I go to
1 - 100 of 266 matches
Mail list logo
