Greg Black [EMAIL PROTECTED] types:
| On Fri, Aug 31, 2001 at 10:36:44AM +1000, Greg Black wrote:
| Why not do it the Unix way? Create a new application, e.g.,
| url(1), to parse the URLs and use it like so:
| Sometimes the solution is so obvious. :-) Well, part of it. I'm
| thinking
Leo Bicknell writes:
On Fri, Aug 31, 2001 at 10:36:44AM +1000, Greg Black wrote:
Why not do it the Unix way? Create a new application, e.g.,
url(1), to parse the URLs and use it like so:
Sometimes the solution is so obvious. :-) Well, part of it. I'm
thinking it's worth creating
Hi,
I tested your patch and it solved our problem 100%. There's no
timedrift anymore.
Do you think the patch will make it in 4.4R. ? We need it urgently.
Thanks a lot for your analysis and your fast work !
Martin
--- apic_vector.s.old Fri Mar 2 13:47:31 2001
+++ apic_vector.s Fri Aug
I wrote:
The problem here is that CPU#1 fails to hold clock_lock while setting
clkintr_pending, causing i8254_offset to be stepped twice, first due
to clkintr_pending, then due to i8254_lastcount being larger than count.
With this patch applied to RELENG_4, the clock speedup seems to
--On Thursday, August 30, 2001 16:15:05 +0100 Ceri [EMAIL PROTECTED]
wrote:
On Thu, Aug 30, 2001 at 11:10:18AM -0400, Leo Bicknell said:
I ran into a pair of all too common annoyances this morning that
got me thinking. Via the magic of cut and paste I ended up with
the following two sorts
You probably have the system default libstdc++.so.3 in your library search
path before the GCC 3 libstdc++.so.3. Try setting LD_LIBRARY_PATH to the
GCC 3 lib directory.
Jan Mikkelsen
-Original Message-
From: Benjamin Gross [EMAIL PROTECTED]
To: [EMAIL PROTECTED] [EMAIL PROTECTED]
Date:
On Thu, Aug 30, 2001 at 07:42:24PM +0530, Sridhar M wrote:
fxp0 : ip : 10.1.6.160/24
fxp1: ip 10.1.6.161/24
default gateway : ip : 10.1.6.1
gateway and routed was enabled .
routed is for dynamic routing (RIP).
You don't need it if you are doing static routing.
our setup is freebsd system
On Fri, Aug 31, 2001 at 12:28:44PM +0100, Paul Richards wrote:
On the other hand, what exactly is http://www.ufp.org supposed to be useful
for when www.ufp.org is the same thing.
The specific problem I ran into that started this is that the 'copy link
location' option in browers (correctly)
snip
Yeah. As long as you avoid motherboards with the VIA KT133A/KT133
chipset and the VIA 686B Southbridge, you're probably fine (not all such
motherboards supposedly have problems, but how do you tell the
difference?). For more info, check out:
Well, I've been using an abit
On Fri, 31 Aug 2001, Paul Richards wrote:
A URI is a Universial Resource Indicator, it's not a web browser address.
On the other hand, what exactly is http://www.ufp.org supposed to be useful
for when www.ufp.org is the same thing.
Why not parse it literally? For instance,
--On Friday, August 31, 2001 09:58:21 -0700 Richard Hodges
[EMAIL PROTECTED] wrote:
On Fri, 31 Aug 2001, Paul Richards wrote:
A URI is a Universial Resource Indicator, it's not a web browser address.
On the other hand, what exactly is http://www.ufp.org supposed to be
useful for when
snip
Yeah. As long as you avoid motherboards with the VIA KT133A/KT133
chipset and the VIA 686B Southbridge, you're probably fine (not all such
motherboards supposedly have problems, but how do you tell the
difference?). For more info, check out:
Well, I've been using
On Fri, Aug 31, 2001 at 09:28:22AM -0400, Leo Bicknell wrote:
In any case if all the info needed wasn't there, the command would fail,
a-la mutt http://www.ufp.org (no user portion).
I believe that http://www.ufp.org is a valid local email address.
--
Ben
An art scene of delight
I
Steve Roome wrote:
On Thu, Aug 30, 2001 at 11:17:08AM -0400, Keith Stevenson wrote:
Ick. If I wanted this kind of integration I would run Windows, KDE, or GNOME
instead of my nice, stable, predictable, lightweight desktop environment.
This entire email is very IMHO
Why? a URI is by
On Fri, Aug 31, 2001 at 02:15:09PM -0400, Michael Sinz wrote:
open(nfs://server.name.dom/directory/file.txt)
and have it work. That would be nice. (Replace the above with
ftp: or http: or whatever other protocol would provide read and/or write
access.)
Anyway, I don't see it
On Friday, August 31, 2001, Michael Sinz wrote:
I too have been hoping for (and building internal tools) that work
this way. I really wish you could just do:
open(nfs://server.name.dom/directory/file.txt)
and have it work. That would be nice. (Replace the above with
ftp: or
On Friday, August 31, 2001, Joseph Mallett wrote:
Check out ftpfs in the HURD. That might be a better way to do it.
No, I think that we're better off with NFS...
--
+---+--+
| Chris Costello| Help support helpless victims
On Fri, Aug 31, 2001 at 01:52:33PM -0500, Chris Costello wrote:
Whatever happened to not distinguishing different types of file
systems from one another in pathnames? And are you suggesting that
we add network overhead (I'd still imagine lo0 can't help speeding
things up...) to file
On Friday, August 31, 2001, Leo Bicknell wrote:
Presumably 'file:/etc/passwd' would not go through lo0.
I understood his statement (`the network includes the local
machine') to imply that he wants to do nfs://localhost/etc/passwd
rather than file:/etc/passwd.
--
On Fri, Aug 31, 2001 at 02:08:14PM -0500, Chris Costello wrote:
I understood his statement (`the network includes the local
machine') to imply that he wants to do nfs://localhost/etc/passwd
rather than file:/etc/passwd.
I would expect both to work, with differing levels of performance.
If
Jan Mikkelsen wrote:
You probably have the system default libstdc++.so.3 in your library search
path before the GCC 3 libstdc++.so.3. Try setting LD_LIBRARY_PATH to the
GCC 3 lib directory.
NOTE:
If you are using the FreeBSD .mk files to build this, and you
are setting DESTDIR, you can
What is the file system that uses VT_TFS in vnode.h? Is it still available
on FreeBSD? Thanks.
-Zhihui
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
On 31-Aug-01 [EMAIL PROTECTED] wrote:
I wrote:
The problem here is that CPU#1 fails to hold clock_lock while setting
clkintr_pending, causing i8254_offset to be stepped twice, first due
to clkintr_pending, then due to i8254_lastcount being larger than count.
The corresponding patch
On Fri, 31 Aug 2001 [EMAIL PROTECTED] wrote:
I wrote:
The problem here is that CPU#1 fails to hold clock_lock while setting
clkintr_pending, causing i8254_offset to be stepped twice, first due
to clkintr_pending, then due to i8254_lastcount being larger than count.
With this patch
On Thu, Aug 30, 2001 at 11:21:09PM +0100, Steve Roome wrote:
ping http://www.myserver.wherever/
instead of telnet wherever 80, just to see if I get a connected or
not ?
Do you have *ANY* clue how ping works? Ping uses ICMP packets; not TCP,
not UDP -- thus there is NO concept of ports.
On Fri, Aug 31, 2001 at 09:58:21AM -0700, Richard Hodges wrote:
On the other hand, what exactly is http://www.ufp.org supposed to be useful
for when www.ufp.org is the same thing.
Why not parse it literally? For instance, http://www.ufp.org
would imply TCP, dest port 80, and host
David O'Brien wrote:
Do you know how traceroute works?? For one, the destination host cannot
be listening on the port used. And you know that each progressive
traceroute packet sent out bumps the destination port by one, to help
trace the ICMP time exceeded / port unreachable responses.
Erik Greenwald writes:
[Erik Greenwald too]
I'm using both of those (iwill kk266) with a thunderbird 850, and
haven't had problems in fbsd. Linux flakes out a bit when I tell
it I have a k7 processor, so I told it I have a k6 and it works fine.
sorry, this thread was supposed to stay in
If memory serves me right, Hroi Sigurdsson wrote:
David O'Brien wrote:
Do you know how traceroute works?? For one, the destination host cannot
be listening on the port used. And you know that each progressive
traceroute packet sent out bumps the destination port by one, to help
trace
On Fri, Aug 31, 2001 at 06:34:55PM -0700, Bruce A. Mah wrote:
People are proposing to do various hacks to existing utilities and
applications without having any real idea of the impact of their ideas,
or even in some cases what semantic sense these hacks have.
For what it's worth, my original
I think this is EXACTLY what happened. We give the customer two upstream
GigE connections and the customer is preferentially using one. Routes are
actually staticly routed to both GigE interfaces.
Is there an RFC you know of that says this is bad behavior? I guess we'll
have to filter ICMP
I remember this a bit better after reading my log message for rev.1.134
of clock.c :-).
At the time, the clock interrupt handler was not fast. However, it
could be delayed for a while by a fast interrupt handler (it still
can). Since it is delayed, it can't set clkintr_pending and we
Hmm, does -current even need clkintr_pending anymore? What is its purpose?
There is a problem if i8254_get_timecount locks clock_lock right
before a rollover but reads the timer right afterwards. In that case,
a too low value can be returned (resulting in 1/Hz too small time
value) although
On Fri, 31 Aug 2001 [EMAIL PROTECTED] wrote:
Hmm, does -current even need clkintr_pending anymore? What is its purpose?
There is a problem if i8254_get_timecount locks clock_lock right
before a rollover but reads the timer right afterwards. In that case,
a too low value can be
I see (amost).
Please format the macro the same as the other macros in the file.
Index: apic_vector.s
===
RCS file: /home/ncvs/src/sys/i386/isa/apic_vector.s,v
retrieving revision 1.47.2.4
diff -u -r1.47.2.4 apic_vector.s
---
On Fri, Aug 31, 2001 at 12:48:12PM -0700, Julian Elischer wrote:
value) although the result will still be monotonous.
hmm monotonus? That explains the sudden bursts of sleepiness I
occasionally get when seated in front of the terminal!
(monatomicly increasing maybe?)
It increases by
On Fri, 31 Aug 2001 [EMAIL PROTECTED] wrote:
For RELENG_4, which uses Xintr0, this problem is reduced by adding the
clkintr_pending variable (cf. revision 1.134 of clock.c and revision
1.38 of apic_vector.s)
Looking more at the code, I now see that clkintr_pending is never set
in -current
Deepak Jain wrote:
We've got a customer running a FreeBSD router with 2 x 1GE interfaces [ti0
and ti1]. At no point was bandwidth an issue.
The router was under some kind of ICMP attack:
For about 30 minutes:
icmp-response bandwidth limit 96304/200 pps
I've seen this happen in a lab
tor, will you commit this?
On Fri, 31 Aug 2001 [EMAIL PROTECTED] wrote:
I wrote:
The problem here is that CPU#1 fails to hold clock_lock while setting
clkintr_pending, causing i8254_offset to be stepped twice, first due
to clkintr_pending, then due to i8254_lastcount being larger
On Fri, 31 Aug 2001, Leo Bicknell wrote:
On Fri, Aug 31, 2001 at 12:48:12PM -0700, Julian Elischer wrote:
value) although the result will still be monotonous.
hmm monotonus? That explains the sudden bursts of sleepiness I
occasionally get when seated in front of the terminal!
40 matches
Mail list logo
