ports (audio) candidate

http://www.speech.kth.se/snack/ I came across this today. It compiles and runs under freeBSD ok, bit seems to have some small hickups and stuff I can't figure out. If there is a tcl/tk guru out there who can take a quick look.. This is a rather awesome sound analysis program designed to allow an

Re: Should URL's be pervasive.

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 origin

Re: Should URL's be pervasive.

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

Re: FreeBSD and Athlon Processors

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 s

Re: Should URL's be pervasive.

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" respon

Re: Should URL's be pervasive.

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 w

Re: Should URL's be pervasive.

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.

Re: Clock speedup on 4.X FreeBSD SMP and serverworks chipset

> 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 w

RE: FW: Interesting Router Question

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 packe

Re: Clock speedup on 4.X FreeBSD SMP and serverworks chipset

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

What is VT_TFS?

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

Re: FW: Interesting Router Question

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

Re: Clock speedup on 4.X FreeBSD SMP and serverworks chipset

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 -cur

Re: Clock speedup on 4.X FreeBSD SMP and serverworks chipset

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 incre

Re: Clock speedup on 4.X FreeBSD SMP and serverworks chipset

> 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 ---

Re: Undefined symbol "_ZTVN10__cxxabiv117__class_type_infoE"

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

Re: Clock speedup on 4.X FreeBSD SMP and serverworks chipset

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

Re: Clock speedup on 4.X FreeBSD SMP and serverworks chipset

> 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

Re: Should URL's be pervasive.

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. I

Re: Clock speedup on 4.X FreeBSD SMP and serverworks chipset

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 p

Re: Should URL's be pervasive.

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. -- +---+--

Re: Should URL's be pervasive.

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 sy

Re: Should URL's be pervasive.

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

Re: Should URL's be pervasive.

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:

Re: Should URL's be pervasive.

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

Re: Clock speedup on 4.X FreeBSD SMP and serverworks chipset

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 correspondin

Re: Should URL's be pervasive.

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 UR

Re: Should URL's be pervasive.

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 is a valid local email address. -- Ben "An art scene of delight I

Re: FreeBSD and Athlon Processors

> > > > > > > > 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

Re: Clock speedup on 4.X FreeBSD SMP and serverworks chipset

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 l

Re: Should URL's be pervasive.

--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 f

Re: Should URL's be pervasive.

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, http://www.u

Re: FreeBSD and Athlon Processors

> > > > 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 a

Re: Should URL's be pervasive.

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) i

Re: [Fwd: Help me regarding IP forwarding]

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 sy

Re: Undefined symbol "_ZTVN10__cxxabiv117__class_type_infoE"

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]> Da

Re: Should URL's be pervasive.

--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

Re: memory + apache

Dan writes: > > I will give it a try. > touch /var/account/acct > accton > > how long does it take for anything to get written to that file? > > As far as fork storms, I did noticed 1. I had the junior admin write > a script to restart apache if LA got to high doing a truss on the

Re: Clock speedup on 4.X FreeBSD SMP and serverworks chipset

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 Au

Re: Clock speedup on 4.X FreeBSD SMP and serverworks chipset

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 disa