Re: in-kernel tcp server
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 computers as well as my ancient backup tapes. I'll certainly look at what I can do about the queue items. I may make a per-cpu cache of them. That would probably help a lot. Each webserver or webclient is tied to one network interface, and I get the best performance when there is one CPU core per interface. I'm not using CPU affinity yet, but I'll probably put that in before long. John ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: in-kernel tcp server
Julian Elischer wrote: Nicolas Cormier wrote: Hi, I'm trying to write a little tcp-server kernel module (like tftp). I didn't find a lot of documents about the kernel network programming, just one thread which talks about netgraph. In the freebsd includes I found /usr/include/sys/socketvar.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 netgraph ksockets. He had an in-kernel web server. At least I THINK it was him :-) Yes, that's right. I started out using netgraph ksockets, but later on it evolved, mainly for performance reasons. (I needed it to be really, really fast.) The first change was that I eliminated the ksockets and worked directly at the link layer, using ng_ether nodes. I implemented a small, stripped down TCP stack and bypassed the FreeBSD native TCP/IP/socket layers. This was still done with netgraph, using just the ng_ether nodes talking to my own ng_webclient / ng_webserver nodes. It improved the performance immensely. More recently I restructured it quite a bit to get better MP performance using FreeBSD 7.x. (The original version was based on 4.x). I found that the netgraph locking and internode communication mechanism impacted performance too much under 7.x. So I eliminated the ng_ether nodes and made the webserver / webclient nodes talk directly to the interfaces via the if_input / if_output hooks. It still uses netgraph, but really only as a configuration and management mechanism. No actual network traffic flows between netgraph nodes. This change also resulted in a big performance improvement. Unfortunately, my contract forbids me to release the source code publicly. John ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: in-kernel tcp server
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. For my application, I found that going through the socket layer (the so* functions and/or ng_ksocket) hurt performance too much. That's why I ended up bypassing them. John ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: in-kernel tcp server
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 node that way and use it for tracking down the bottlenecks I'm not too interested in the actual webserver itself. I don't have the ksocket version any more. It was an early experiment (in 2001) that I discarded pretty quickly. The later 4.x-based version that bypassed the TCP stack and socket layer performed well on uniprocessor systems. I didn't feel netgraph was a performance problem at all on that version. But as multiprocessor systems became more mainstream, the 4.x version wasn't able to take advantage of the added CPUs. Also, it didn't support ACPI and had trouble booting on some of the newer hardware. For those reasons, I updated to a 7.x-based system. At that point, the newer SMP-friendly netgraph started to impact performance pretty seriously. The allocation/deallocation of netgraph's queue items seemed to be a big part of the problem. In 4.x we just passed mbufs around, without any other allocations or deallocations. In 7.x, the mbufs are wrapped up in queue items that have to be allocated and freed, and that added a lot of overhead. I think also that the reader-writer locking in netgraph was impacting performance. It's a really elegant locking scheme, but my node graphs were so simple that I didn't really need it. I don't view netgraph as having serious performance problems. It's just that I was aiming for maximal performance (in terms of HTTP sessions per second), and was willing to do otherwise unreasonable things to get it. John ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: [Fwd: Interrupts question]
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 exactly match those for a uhc device on irq 16. And the interrupts for the hardware raid (amr) on irq 46 exactly match those for a uhc device on irq 18. The problem involving the em device was solved in -current around January by making the device use a fast interrupt handler. If you can update to the latest driver from -current (if it will build on whatever version you are running), you can solve that part of the problem. I don't think there's an equivalent fix for the amr driver, though. John ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: CVSup and Attic files
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, since I can't think of anything else that would make it suddenly change, You are right. The patch took away the ability to refuse Attic files. I know that's an inconvenience for some folks, but I think it better matches CVSup's overall philosophy of Attic files -- namely, that the Attic is a historical CVS quirk that ought to be hidden as much as possible. John ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: CVSUP error...
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 discussed in the CVSup FAQ at www.cvsup.org. John ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Any workarounds for Verisign .com/.net highjacking?
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-servers.net) and purging those records out of the zone before
loading it. Any ideas, either under djbdns or Bind 9?
Sorry, only for bind8, as was posted to my local LUG list:
http://achurch.org/bind-verisign-patch.html
I think the patch will cause named to leak memory, though, unless you
add a call db_detach(dp); somewhere before the continue. I think
the corrected patch should look like this:
Index: ns_resp.c
===
RCS file: /home/ncvs/src/contrib/bind/bin/named/ns_resp.c,v
retrieving revision 1.1.1.2.2.10
diff -u -r1.1.1.2.2.10 ns_resp.c
--- ns_resp.c 25 Aug 2003 21:07:49 - 1.1.1.2.2.10
+++ ns_resp.c 16 Sep 2003 21:37:56 -
@@ -955,6 +955,16 @@
type = dp-d_type;
if (i ancount) {
/* Answer section. */
+ /* HACK to kill Verisign stupidity
+* [EMAIL PROTECTED]
+* see http://www.imperialviolet.org/dnsfix.html */
+ static char IP_TO_KILL[] = {64,94,110,11};
+ if (type == ns_t_a
+ memcmp(dp-d_data, IP_TO_KILL, 4) == 0) {
+ db_detach(dp);
+ validanswer = 0;
+ continue;
+ }
/*
* Check for attempts to overflow the buffer in
* getnameanswer.
That's just from looking at the nearby code. I haven't tested it
extensively.
I have notified the original author of the patch about this.
John
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Any workarounds for Verisign .com/.net highjacking?
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. I think so too, in principle. But we need something better than a hard-coded IP address. It would take Verisign about an hour to figure out they need to change the address frequently. (Well, OK, a day ... it's Verisign, after all.) John ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Any workarounds for Verisign .com/.net highjacking?
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 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. : : I think so too, in principle. But we need something better than a : hard-coded IP address. It would take Verisign about an hour to figure : out they need to change the address frequently. (Well, OK, a day ... : it's Verisign, after all.) Agreed. but it wouldn't be too hard to determine at boot/hourly doing a bogus query to find the address of the moment. Even they would be hard pressed to change things more than hourly. 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 address. Or maybe the to the same small set of addresses, depending on how determined Verisign is to make this work. I just _love_ how Verisign doesn't even have a reverse DNS record for that address. Jerks. I sincerely hope that for once, the herds of cattle who use AOL and MSN and think internet and web are synonyms will realize this just ain't right and raise a fuss about it. But given their meek response to spam, pop-ups, and spyware, I'm not all that optimistic. John ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Any workarounds for Verisign .com/.net highjacking?
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 address. Or maybe the to the same small set of addresses, depending on how determined Verisign is to make this work. *.net should work, since they basically added a * A record to .com and .net. Yep, that should work. I just _love_ how Verisign doesn't even have a reverse DNS record for that address. Jerks. [EMAIL PROTECTED]:/usr/src# host 64.94.110.11 11.110.94.64.IN-ADDR.ARPA domain name pointer sitefinder-idn.verisign.com When I wrote the above, host 64.94.110.11 didn't return anything. John ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: messing with CVS_LOCAL_BRANCH_NUM
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 which can cause it to throw away your local branch under certain circumstances. I won't have time to fix those issues any time soon. So my advice is, don't use the CVS_LOCAL_BRANCH_NUM feature. Darn. :/ [...] So, can the 'certain circumstances' be described, so that I might avoid them? Or is that just due to inherent wierdness in the whole CVSup process? The main situation in which it will occur is when somebody has directly manipulated or replaced an RCS file in the master CVS repository. CVSup notices that the client and server have entirely different RCS files, so it does a full replace instead of trying to send just deltas. Ideally this situation should never arise, but in the real world it happens all the time. That's actually the only scenario I know of where the problem should crop up. But on the other hand, I've had some suspicious-sounding reports of CVS_LOCAL_BRANCH_NUM lossage that can't be explained by this alone. Bottom line is, if you value your local branch then you should back it up before every update. John -- John Polstra John D. Polstra Co., Inc.Seattle, Washington USA Two buttocks cannot avoid friction. -- Malawi saying ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: messing with CVS_LOCAL_BRANCH_NUM
In article [EMAIL PROTECTED], Brian Reichert [EMAIL PROTECTED] wrote: I'm exploring the 'local repository' tactics as described in: http://www.scriptkiddie.org/freebsd/setting_up_local_repo.html which makes use of the CVS_LOCAL_BRANCH_NUM evironment variable. [...] Any advice? Yes: look for a different approach, or at least backup your local repository frequently. There are known bugs in CVSup which can cause it to throw away your local branch under certain circumstances. I won't have time to fix those 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 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Raising SIGSEGV in SIGSEGV handler makes FreeBSD loop
In article [EMAIL PROTECTED], Terry Lambert [EMAIL PROTECTED] wrote: Vaclav Haisman wrote: Besides, this doesn't explain anything. I see I haven't asked any question in my previous post. So, why does FreeBSD behave different? Because POSIX mandates that it do so? man 3 signal tells us: The handled signal is unblocked when the function returns and the process continues from where it left off when the signal occurred. Unlike previ- ous signal facilities, the handler func() remains installed after a sig- nal has been delivered. POSIX mandates no such thing. You missed the part of the POSIX spec that says: The behavior of a process is undefined after it returns normally from a signal-catching function for a SIGFPE, SIGILL, SIGSEGV, or SIGBUS signal 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.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
Re: Changing socket buffer timeout to a u_long?
In article [EMAIL PROTECTED], David G. Andersen [EMAIL PROTECTED] wrote: Are there compelling reasons not to change the socket buffer timeout to a u_long from a u_short? This variable stores the number of ticks before the socket operation times out. I already changed it from short to int in -current in July. (It has never been unsigned in FreeBSD, as far as I know.) Making it long is overkill since that means it is 64 bits on the Alpha and Sparc64 platforms. I didn't change it in -stable for compatibility reasons, though I doubt it is much of an 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. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: bge problems (was: gigabit NIC of choice?)
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 other gigabit MAC in current production. Through the graciousness of Intel we also have a contributed driver for their gig-e cards (em). Thanks to all who lined that up, it works great. What is it you are nitpicking about? My posting you quoted mentioned the em driver as the only game in town if you want a supported driver. I too am grateful to Intel for providing this and for keeping it up to date. It's more than the other vendors do for us. However, just like almost all the other gigabit chips, if you want to get docs or errata on the Intel devices you are going to have to sign an NDA. That's true even for their 10/100 chips. But broadcom does take the cake for being anal about NDAs. Intel is pretty anal about them too. :-( 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
Re: bge problems (was: gigabit NIC of choice?)
In article p05111a10b9a45ebf5047@[10.1.1.73], Mark Peek [EMAIL PROTECTED] wrote: At 12:51 PM +0200 9/10/02, Birger Toedtmann wrote: So it seems there is some problem with the bge driver/card/64bit bus. Does the scenario ring a bell to someone of you? 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 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
Re: bge problems (was: gigabit NIC of choice?)
In article [EMAIL PROTECTED],
Birger Toedtmann [EMAIL PROTECTED] wrote:
just as this comes up, I have a question. Has anyone had experiences
with the bge driver and related cards? We had some weird problems here
lately:
- bought two 3com 996-SX (fiber) cards and plugged them into
ASUS A7M266-D boards with AMD Athlon 1.8GHz CPUs,
- brought up FBSD 4.6 and tried some networking
-- All packets (to and fro) that where bigger than total IP length
of 214 bytes were garbled. To be more specific, it seemed to
us that some 8 byte regions haven't been copied correctly from
the cards at some point when the packets were larger.
(The boards worked fine with normal 100Mbit cards, BTW.)
To make matters more interesting, we then put the (Gbit) cards into
AMD-Duron-700MHz-Systems with 32bit bus only - as apposed to the A7M266-D
which had a 64bit bus:
-- The cards worked just fine with all sorts (and sizes) of packets,
but performance was - surpise, surprise - limited to 0.25 Gbit.
So it seems there is some problem with the bge driver/card/64bit bus.
I use the 3c996B-T cards without any problems on a 64-bit bus. It's
an Intel-based machine (Dell 1550) rather than an Athlon, though.
It's possible that the problems you're seeing have something to do
with the chipset rather than with the width of the PCI bus.
All of the documentation and errata for the BCM570x chips are
protected by NDA, just like every other gigabit MAC in current
production. That makes it very difficult for us to maintain a working
driver. The only information we have is obtained by staring at
the Linux driver (which originates from Broadcom), making educated
guesses, and trying experiments. For example, in the Linux driver
obtained from the 3com web site, I see that there is a function
LM_DmaTest() which transfers a known data pattern using DMA and checks
for data corruption. This code might be present in the driver to
detect exactly the problem you've reported -- or maybe not. The only
way to find out is to try it.
It looks like if LM_DmaTest() finds corruption, it works around it by
putting a certain value into certain bits of a certain register.
You could try the equivalent in our driver and see if it works. In
if_bge.c, find the last occurrance of BGE_PCI_DMA_RW_CTL in
bge_chipinit():
#ifdef __brokenalpha__
/*
* Must insure that we do not cross an 8K (bytes) boundary
* for DMA reads. Our highest limit is 1K bytes. This is a
* restriction on some ALPHA platforms with early revision
* 21174 PCI chipsets, such as the AlphaPC 164lx
*/
PCI_SETBIT(sc, BGE_PCI_DMA_RW_CTL, BGE_PCI_READ_BNDRY_1024, 4);
#endif
After that, add this code (untested):
{ /* XXX experiment */
u_int32_t r;
r = CSR_READ_4(sc, BGE_PCI_DMA_RW_CTL);
r = (r ~BGE_PCIDMARWCTL_WRADDR_BNDRY) | BGE_PCI_WRITE_BNDRY_16BYTES;
CSR_WRITE_4(sc, BGE_PCI_DMA_RW_CTL, r);
}
Who knows? Maybe you'll get lucky. :-)
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 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.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
Re: bge problems (was: gigabit NIC of choice?)
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 our only gigabit driver that's maintained by somebody | who has unrestricted access to the documentation and errata. Atleast one potential exception to this it that so far National seems to keep their programming on line without needed an NDA. Whoops, thanks for the correction. That's good news. 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
Re: interrupting target kernel using single sio
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 the target automatically. It's extremely handy. You just type target remote /dev/tty00 into kgdb and the target breaks into the debugger -- no muss, no fuss. I wish we 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 many times as you'd like. Any chance of getting that from BSD/OS? If not, perhaps we could reimplement. We used to have the BSD/OS sources on-line, and we had carte blanche to take things from them and put them into FreeBSD. I don't know what the situation is now. 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
Re: interrupting target kernel using single sio
In article [EMAIL PROTECTED], Hanspeter Roth [EMAIL PROTECTED] wrote: using a single serial cable I can pass control to the remote kgdb pressing ctl-alt-del at the target host. I'm looking for a means to interrupt the target kernel from the remote host. I got suggestions using a second serial cable or using ipgdb instead. Setting remotechat didn't help me. Is it intended to be able to interrupt the target kernel from the remote kgdb by some means at all? Or is this a wrong expectation? BSD/OS has a little state machine in its sio driver which notices if something looking like a kgdb packet comes in and interrupts the target automatically. It's extremely handy. You just type target remote /dev/tty00 into kgdb and the target breaks into the debugger -- no muss, no fuss. I wish we 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 many times as you'd like. 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
Re: ftp and mail much slower into fbsd 4.4 vs and old BSDi
In article [EMAIL PROTECTED], Len Conrad [EMAIL PROTECTED] wrote: Sorry, hackers, I posted this twice in -questions and got no response. [...] FreeBSD 4.4-RELEASE #0 FreeBSD-4.4 had terrible performance bugs in the TCP stack, with or without newreno. Matt Dillon fixed 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.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
Re: bge driver not working in Dell 2650
In article [EMAIL PROTECTED], Lai Yiu Fai [EMAIL PROTECTED] wrote: Anyone get the Broadcom BCM5701 gigibit ethernet working on new Dell 2650? I noted it has been fixed in latest STABLE branch from freebsd-hacker list. http://www.geocrawler.com/mail/thread.php3?subject=Broadcom+BCM5701+GigE+Ethernet+problems%3F%3Flist=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 make it possible for anybody to help you. 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
Re: Re: bge driver issue
In article [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: John. Thanks for the tip. I changed ETHER_ALIGN to 0 and the driver started to work. I'm glad to hear it. Thanks for the report. I am not sure about the performance since I seem to get only 50 Mbit over a 100 Mbit line. However this is much better than the timeout warnings... On the i386, living with the misalignment is probably the best solution, unfortunately. The only alternatives I can think of are: - bcopy the packet up by 2 bytes after reception to align the payload, or - disable PCI-X mode on the bus Both of those would probably be worse. Do you need any other experiments done? We're going to ship the 2650 back to Dell for other reasons (form factor and noise). Thanks for the offer. I don't know of any other 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 still buzzing at the end of the day. 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
Re: Re: bge driver issue
In article [EMAIL PROTECTED], Andrew Gallatin [EMAIL PROTECTED] wrote: If the bge's API allows it, you could setup a receive descriptor with a length of 14 bytes (size of ethernet header), and start the next descripter 2 bytes after it (at a 16 byte offset from the front of the mbuf). When the receive is done, just copy the 14 bytes. That was my first thought too, but unfortunately the device doesn't appear to support scatter-gather for received packets. I had another totally evil idea which isn't really feasible. Empirically, it appears that the buffer has to be aligned to an 8-byte boundary. Also empirically, it seems that when the buffer isn't aligned, only the part before the first 8-byte boundary is corrupted. So we could offset the buffer by 6 bytes. Then the only corruption would be in the first 2 bytes 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.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
Re: cvsup doesn't get me what I want
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. The cvsupd server config files for the collection (releases and the list file). [dan@xeon:/home/repositories/sup/freshports-phpAds] $ less list.cvs upgrade phpPgAds [dan@xeon:/home/repositories/sup/freshports-phpAds] $ less releases cvs list=list.cvs prefix=/home/repositories/freebsddiary OK, this says the server is getting its files from /home/repositories/freebsddiary. But ... The full pathname of the ChangeLog RCS file you used as your example, on the server machine. /home/repositories/freshports-1/phpPgAds/ChangeLog,v That is a different file! It's under /home/repositories/freshports-1, which is not where the releases file tells the server to look. I think that's 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 PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: cvsup doesn't get me what I want
In article [EMAIL PROTECTED], Dan Langille [EMAIL PROTECTED] wrote: Folks, I'm having trouble understanding this problem. I'm trying to use cvsup to get stuff onto my website. This supfile gets things out of the tree $ less ~/phpAdsNew-supfile *default host=xeon *default base=/usr/websites/freshports *default release=cvs *default delete use-rel-suffix *default umask=007 *default preserve *default tag=. freshports-phpAds But what I really want is tag=FreshPorts2 but if I use that, I don't get anything out of the repo. The tags exist: However, for example: $ cvs stat -v ChangeLog === File: ChangeLog Status: Up-to-date Working revision:1.1.1.1 Tue Jun 4 01:01:32 2002 Repository revision: 1.1.1.1 /home/repositories/freshports- 1/phpPgAds/ChangeLog,v Sticky Tag: FreshPorts2 (revision: 1.1.1.1) Sticky Date: (none) Sticky Options: (none) Existing Tags: cvs (revision: 1.1.1.1) FreshPorts2 (revision: 1.1.1.1) I just don't get it. Why doesn't tag=FreshPorts2 work? You should get rid of the preserve keyword in your supfile. It doesn't really make any sense when working in checkout mode. But that's probably not the problem. I'll help you figure this out if you'll send me the following information: The cvsupd server config files for the collection (releases and the list file). The full pathnames of the cvsupd server config files for the collection. The command line used to invoke cvsupd. The full pathname of the ChangeLog RCS file you used as your example, on the server machine. The output of rlog -h ChangeLog,v on that file on the server. The command 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 that your PATH is really finding the same copies of these programs that your cron job or other mechanism normally executes. 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
Re: using cvsup to put the same collection in two places
In article [EMAIL PROTECTED], Dan Langille [EMAIL PROTECTED] wrote: The objective: I want the same collection in two different places, but I want to use two different refuse files. Some parts of the collection I don't want in one location. [...] At present I have these two supfiles: This puts the collection in the https section of the website: less ~/phpAdsAdmin-supfile *default host=localhost *default base=/home/freebsddiary/admin *default release=cvs tag=. *default delete use-rel-suffix *default umask=007 *default preserve fbsd-phpAds This puts the collection in the http section of the website: $ less ~/phpAds-supfile *default host=localhost *default base=/home/freebsddiary *default release=cvs tag=. *default delete use-rel-suffix *default umask=007 *default preserve fbsd-phpAds Normally a refuse file would go into /home/freebsddiary/sup/col 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 directories in the two supfiles. 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
Re: C-struct dismantling tool...
In article [EMAIL PROTECTED], Poul-Henning Kamp [EMAIL PROTECTED] wrote: Does anyone know of an existing tool which for a given C struct can output a list of elements, their types, size and byteoffset ? No, but I'd like one too -- one that can handle the files in /usr/include with all their idiosyncrasies. I have considered parsing the information out of .stabs records from gcc -g output, but if an existing tool already exists that would save me quite some time. I thought about the .stabs approach too, and thought it seemed 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.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
Re: in-kernel HTTP Server for FreeBSD?
In article [EMAIL PROTECTED], Julian Elischer [EMAIL PROTECTED] wrote: there is one. Written by [EMAIL PROTECTED] I think it's proprietary but maybe not.. (CC'd) Yes, I wrote one. Yes, it's proprietary. To those who dismissed it 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, 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
Re: A question about timecounters
In article [EMAIL PROTECTED], John Baldwin [EMAIL PROTECTED] wrote: like, If X is never locked out for longer than Y, this problem cannot happen. I'm looking for definitions of X and Y. X might be hardclock() or softclock() or non-interrupt kernel processing. Y would be some measure of time, probably a function of HZ and/or the timecounter frequency. X is hardclock I think, since hardclock() calls tc_windup(). That makes sense, but on the other hand hardclock seems unlikely to be delayed 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.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
Re: A question about timecounters
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 variable is not declared volatile. So in this part ... This may be a problem, I have yet to see GCC make different code for that but I should probably have committed the volatile anyway. It should be committed, but it is not causing the problem in this case. I changed it and then compared MD5s of the object files. The only changes that resulted were unimportant. I also noticed this in tco_forward(): tco = timecounter; tc = sync_other_counter(); [...] if (tco-tc_poll_pps) But sync_other_counter() loads its own copy of timecounter, and there's no guarantee it hasn't changed from the value that tco_forward() saved in its local variable. I'm not sure yet if that's a potential problem. It could corrected by passing tco as an argument to sync_other_counter. I'll try that too. This code is actually correct, the tc_poll_pps needs to be done on the old timecounter, because that would be the reference for any captured hardware timestamps, if I did it on the new timecounter I might get negative deltas which would complicate things. Also the new timecounter may have a changed frequency/offset (tickadj/ntpd and all that). I don't think I follow your reasoning here. If the call to sync_other_counter were inlined, we'd have something like this: tco = timecounter; tco_in_sync_other_counter = timecounter; [...] if (tco-tc_poll_pps) Obviously tco and tco_in_sync_other_counter will have the same value almost all of the time, so the code can't be relying on them being different. Anyway, I realize now that this also isn't the problem, because tco_forward is only ever called at splclock. It can't be interrupted or re-entered, at least not on the uniprocessor -stable systems I'm looking at. There is one more failure mode which you have overlooked: The individual timecounters maintain a binary counter of a certain width, if interrupt latency gets too bad, this may overflow. This is a non-issue for the TSC, which is 64bit wide in hardware. Many of the systems where I see this problem are using the TSC as the timecounter. They don't have APM in the kernel, and they aren't running ntpd. I.e., it's not only the i8254 that's the problem. The fastest of these systems is a 1.13 GHz PIII, and it would take the 32 bits of the TSC which are actually used 3.8 seconds to wrap around. Hope this helps... Yep, thanks. I have some ideas of other things to try. 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
Re: A question about timecounters
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: like, If X is never locked out for longer than Y, this problem cannot happen. I'm looking for definitions of X and Y. X might be hardclock() or softclock() or non-interrupt kernel processing. Y would be some measure of time, probably a function of HZ and/or the timecounter frequency. X is hardclock I think, since hardclock() calls tc_windup(). That makes sense, but on the other hand hardclock seems unlikely to be delayed 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. Try swapping so you use the RTC for hardclock statclock. Let the i8254 run with 65536 divisor and do only timecounter service. That would be a very interresting experiment. Agreed. But in the cases I'm worrying about right now, the timecounter is the TSC. 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
Re: A question about timecounters
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 very interesting, how reproducible is it ? I can reproduce it pretty easily. This is from a PIII/550: web1# uptime 5:23PM up 37 mins, 2 users, load averages: 0.08, 0.05, 0.01 web1# dmesg | grep microuptime microuptime() went backwards (1992.7347381 - 1991.587620) microuptime() went backwards (1992.7347381 - 1991.620385) microuptime() went backwards (1992.7347381 - 1991.621582) microuptime() went backwards (2016.7063298 - 2015.272466) microuptime() went backwards (2286.7346482 - 2285.587587) microuptime() went backwards (2286.7346482 - 2285.593646) microuptime() went backwards (2286.7346482 - 2285.595103) microuptime() went backwards (2286.7346482 - 2285.617023) Now, two things are unusual about this system. First, I have it pumping packets from inside the kernel (with a special netgraph node) at a rate which is keeping the system about 95% busy processing interrupts. (That's about 330K packets/second.) That definitely makes it happen more often. But I also see it occasionally when the system is sitting idle. Second, I have HZ set to 1. I think that also contributes to the problem. It shouldn't, though. Not even a PII/400 breathes hard at HZ=1. On another system which is mostly idle, I see it about 4 times a day. That system also has HZ set to 1. It's a PIII/1.13 GHz: microuptime() went backwards (200671.582473 - 200671.582472) microuptime() went backwards (222622.358518 - 222622.358517) microuptime() went backwards (228934.897839 - 228934.897838) microuptime() went backwards (246166.386301 - 246166.386300) microuptime() went backwards (263484.488575 - 263484.488574) Notice the difference on this system that's fairly idle. On the other system, it was the seconds going backward. Here it's the microseconds. These may be two entirely different problems. Can you try to MFC rev 1.111 and see if that changes anything ? Sure. I'll let you know. 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
Re: A question about timecounters
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 very heavy network interrupt load. With the change from 1.111, I still get the microuptime messages about as often. But look how much larger the reported backwards jumps are: microuptime() went backwards (896.225603 - 888.463636) microuptime() went backwards (896.225603 - 888.494440) microuptime() went backwards (896.225603 - 888.500875) microuptime() went backwards (1184.392277 - 1176.603001) microuptime() went backwards (1184.392277 - 1176.603749) 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
Re: A question about timecounters
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 rev 1.111 and see if that changes anything ? That produced some interesting results. I am still testing under very heavy network interrupt load. With the change from 1.111, I still get the microuptime messages about as often. But look how much larger the reported backwards jumps are: microuptime() went backwards (896.225603 - 888.463636) microuptime() went backwards (896.225603 - 888.494440) microuptime() went backwards (896.225603 - 888.500875) microuptime() went backwards (1184.392277 - 1176.603001) microuptime() went backwards (1184.392277 - 1176.603749) Another interesting thing is that the jumps are always 7.7x seconds back -- usually 7.79 seconds. This is even true with more data points from two different machines. 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
Re: A question about timecounters
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 interesting thing is that the jumps are always 7.7x seconds back -- usually 7.79 seconds. This is even true with more data points from two different machines. Yes, I noticed, but didn't dare draw conclusions based on two data points. It's pretty consistent -- always 7.7somthing. This points to an arithmetic overflow (ie: point 3 in my previous email) 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 nsec * 2^32 is 7.81 seconds. :-) I'll try the things you suggested in your other mail. 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
Re: A question about timecounters
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.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
Re: A question about timecounters
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 nsec * 2^32 is 7.81 seconds. :-) In that case I'm almost willing to put an AnchorSteam on microuptime() being interrupted for more than good is in which case the splhigh() should cure it. I'm testing that now. But for how long would microuptime have to be interrupted to make this happen? Surely not 7.81 seconds! On this same machine I have a curses application running which is updating the screen once a second. It never misses a beat, and userland is very responsive. 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
Re: A question about timecounters
OK, adding the splhigh() around the body of microuptime seems to have solved the problem. After 45 minutes of running the same test as before, I haven't gotten a single message. If I get one later, I'll let you know. I'm testing that now. But for how long would microuptime have to be interrupted to make this happen? Surely not 7.81 seconds! On this same machine I have a curses application running which is updating the screen once a second. It never misses a beat, and userland is very responsive. Well, that is what I don't understand yet either :-) The fact that the delta is not exactly 2^32 * cpu clock is probably blindingly obviously indicative of why, but I havn't solved the puzzle yet... I've been staring at the code, but I haven't gotten it yet either. Since you are running with a 1 HZ, NTIMECOUNTER should probably be considerably increased. (Actually it might be a good idea to simply set NTIMECOUNTER == hz ... hmmm...) I don't follow that. As I read the code, the current timecounter is only advanced every 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't it true that the current timecounter only advances every second? I think I have 5 seconds, not 5/HZ seconds. 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
Re: A question about timecounters
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 every 1/HZ seconds. Why should
more of them be needed when HZ is large?
No, only if you have set tco_method to one, if tco_method is zero (default)
we update the timecounter every HZ.
Oh, you're right. Sorry, I misread the code. My tco_method is 0,
so it will do the update every HZ.
Could you try this combination:
NTIMECOUNTER = HZ (or even 5 * HZ)
tco_method = 0
no splhigh protection for microuptime() ?
Yep, I'll try that.
If I do
extern volatile struct timecounter *timecounter;
microtime()
{
struct timecounter *tc;
tc = timecounter;
The compiler complains about loosing the volatile thing.
How do I tell it that it is the contents of the timecounter pointer which
is volatile, but now what it points at ?
You want:
extern struct timecounter *volatile timecounter;
and also change the definition of the variable in the .c file. You
won't get any warnings from that.
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
Re: A question about timecounters
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 protection for microuptime() ? After 25 minutes testing that with NTIMECOUNTER=5, I haven't gotten any microuptime messages. So it appears that my problem was just that the current timecounter wrapped all the way around the ring while microuptime was interrupted, due to the high HZ value and the heavy interrupt load. I'm sorry I didn't try this sooner, when you suggested it. After lunch I'll try NTIMECOUNTER=HZ (1 in my case). That sounds like a nice default value to me. It would be interesting to see whether this same fix also works in -current. I'm not sure yet if I can test that here or not. I haven't tried building my netgraph module under -current yet. 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
Re: A question about timecounters
In article [EMAIL PROTECTED], Poul-Henning Kamp [EMAIL PROTECTED] wrote: Well, either way I will commit the volatile and this NTIMECOUNTER to -current now, it's certainly better than what is there now. Great, thanks. Thanks for the help, I owe you one at BSDcon! I'll look forward to it! Ohh, and btw: do I need to say that I'm dying to know what the heck you are doing with that box ? :-) Making the room a good bit warmer, that's for sure. :-) First I should mention for the benefit of those listening in that it isn't something I can release publicly, and it will probably never be open source. It's a simulated web client and web server, running inside the kernel. It's good for load-testing and performance-testing many kinds of network devices. With two 1-GHz PIII boxes (one acting as the client 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.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
Re: A question about timecounters
In article [EMAIL PROTECTED], Bakul Shah [EMAIL PROTECTED] wrote: [I see that jdp has answered your question but] cdecl is your friend! $ cdecl Type `help' or `?' for help cdecl explain volatile struct timecounter *timecounter declare timecounter as pointer to volatile struct timecounter cdecl declare timecounter as volatile pointer to struct timecounter struct timecounter * volatile timecounter Is C a great language, or what? ;-) The way I always remember it is that you read the declaration inside-out: starting with the variable name and then heading toward the outside while obeying the precedence rules. When you hit a *, you say pointer to; when you hit [], you say array of; and when you hit () you say function returning. For example: struct timecounter * volatile timecounter; /* Timecounter is a volatile pointer to a struct timecounter. */ volatile struct timecounter *timecounter; /* Timecounter is a pointer to a struct timecounter which is volatile. */ The reason for the awkward 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 struct timecounter. */ 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
Re: [patch] using ldd on shared libraries
In article [EMAIL PROTECTED], Bjoern Fischer [EMAIL PROTECTED] wrote: I had to closer look into shared objects wrt self-containedness. Here is a patch for ldd(1), that extends it to be used w/ shared libraries, too. Thanks. Strangely enough, Maxim Sobolev committed changes to -current to do exactly the same thing (in a different way) just yesterday. Your patch won't be needed, but I do appreciate your having worked on it. You'd better watch your step if you don't want to wake up one morning and find that you've become the new maintainer 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 basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
A question about timecounters
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 latency is too much? Which interrupt has to be locked out for how long in order to see these messages? John To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: A question about timecounters
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 messages which I see on just about every machine I have, whether running -stable or -current. I see them everywhere with -CURRENT, but not at all with -STABLE. This is with two seperate machines. Perhaps that may add clues. I'm looking for something less empirical than that. When somebody says this problem is caused by too much interrupt latency, I assume they have a mental model of what is going wrong when this excessive latency occurs. Given that, it should be possible to make a statement like, If X is never locked out for longer than Y, this problem cannot happen. I'm looking for definitions of X and Y. X might be hardclock() or softclock() or non-interrupt kernel processing. Y would be some measure of time, probably a function of HZ and/or the timecounter frequency. 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
Re: A question about timecounters
In article [EMAIL PROTECTED], Mike Smith [EMAIL PROTECTED] wrote: It's not necessarily caused by interrupt latency. Here's the assumption that's being made. [...] Thanks for the superb explanation! I appreciate it. There is a ring of timecounter structures, of some size. In testing, I've used sizes of a thousand or more, but still seen this problem. There is a pointer to the current timecounter structure. That's the global variable named timecounter, right? I did notice one potential problem: that variable is not declared volatile. So in this part ... When one wishes to read the current time, one proceeds as follows: - Get the current pointer and save it locally. - Read the timecounter structure via the local current pointer. ... the compiler is perfectly free to reread the global multiple times in the function rather than using the saved local copy. If the current pointer has moved in that time, we'll an inconsistent view of the timecounter. In looking at the generated code I haven't found any actual instances of that. But I'll try making it volatile just to make sure. Even if it doesn't cause any problems currently, I think we should change it to volatile since it could start to cause problems some day. I also noticed this in tco_forward(): tco = timecounter; tc = sync_other_counter(); [...] if (tco-tc_poll_pps) But sync_other_counter() loads its own copy of timecounter, and there's no guarantee it hasn't changed from the value that tco_forward() saved in its local variable. I'm not sure yet if that's a potential problem. It could corrected by passing tco as an argument to sync_other_counter. I'll try that too. There are a couple of possible problems with this mechanism. One is that the ring catches up with your saved copy of the current pointer, ie. inbetween fetching the pointer and reading the timecounter contents, the next pointer passes over you again in such a fashion that you get garbage out of the structure. As you mentioned, with a large enough ring this should be impossible. If I read the code correctly, the current pointer is only moved once per second. So in the current ring of 4 counters (number 0 is special), it would take 4 seconds to wrap around the ring. That's a pretty long time. Another is that there is a race between multiple updaters of the timecounter; if two parties are both updating the next timecounter along with another party trying to get the current time, this could cause corruption. All that interrupt latency will do is make the updates late; I can't actually see how it could cause corruption. Corruption has to be caused by mishandling of the timecounter ring in some fashion. I agree. Note that you can probably eliminate the ring loop theory by allocating a very large number of entries in the ring by setting NTIMECOUNTER (kern/kern_tc.c) higher. The structures are small; try 100,000 or so. OK, but even the thousand you tried should give a cushion of more than 16 minutes. If you can reproduce under these circumstances, try adding some checks to make sure the current timecounter pointer is behaving monotonically; just save the last timecounter pointer in microtime() et. al. Another test worth performing is to look at the tco_delta function for the timecounter and make sure that it returns a sane value, and one that doesn't behave out of synch with the interrupt handler that 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 desirable, but that would be better than nothing. Hope this helps a bit. Yep, thanks again. 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
Re: problem w/ dlopen(); bug or feature?
In article [EMAIL PROTECTED], Bjoern Fischer [EMAIL PROTECTED] wrote: On Fri, Feb 01, 2002 at 09:10:18PM +0100, Bjoern Fischer wrote: I have a problem with dlopen() on FreeBSD: When dlopen()ed shared objects dlopen() a shared object themselves, the DT_RPATH, that is hardcoded into the first dlopen()ed object is *not* searched. Ok, I've looked into /usr/src/libexec/rtld-elf/rtld.c:dlopen(). It is obvious why dlopen-test does not work: The runtime linker only searches in DT_RPATH of the main object obj_main. John, is it possible to find out in dlopen() which object in the linked list has issued the dlopen() call? Then a fix would be easy. Yes, it's possible to find out which shared object the dlopen call was made from. There's already a function obj_from_addr() in rtld.c which does that. But as far as I know, it is not standard behavior to search the RPATH of the object which issued the dlopen call. I try to follow the ELF specification and/or the behavior of Sun's dynamic linker, and I don't think either one specifies this sort of dynamic scoping. It's risky to get too creative in this area. Usually doing so breaks several random ports. BTW, isn't the method of using a linked list for the objects a bit limiting? Wouldn't be a tree structure better? If you're talking about efficiency, it doesn't matter very much. It's a rare program that loads more than, say, 20 shared libraries. If you're talking about functionality, the linked list isn't the only data structure. Each shared object is also inserted into a doubly-linked tree structure (actually a DAG) which represents the hierarchical 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
Re: Broadcom 5701 (3com 3c996B-T) phy support in 4.5?
In article [EMAIL PROTECTED], Jonathan Stone [EMAIL PROTECTED] wrote: Apologies if this is the wrong place to ask this I just got a 3com 3c996B-T with a bcm5701 chip. It doesn't work with a kernel built from 4.5-RC source pulled Friday: the gigabit phy goes unrecognized, gets attached as a ukphy, which (obviously) doesn't support 1000baseTX. Is this expected to work? Its hard to tell from if_bge. I discovered a suitable value for lines for sys/dev/mii/miidevs in the Debian Linux driver: +model xxBROADCOM BCM5701 0x0011 BCM5701 10/100/1000baseTX PHY rebuilt the .h file, and added corresponding lines to the probe routine in bgrphy.c. That gets the builtin 5400-compatible gigabit PHY recognized -- it auto-negotiates with my gigabit switch, and gives the same ttcp same speed as a 5700-- but i still get another 30-odd ukphy devices attached on that miibus instance. Yep, I went through the same exercise. Apparently the 5701 doesn't bother to decode the phy address. The driver just has to know to use phy number 1. (Boo, hiss!) I worked around it by making bge_miibus_readreg and bge_miibus_writereg return 0 if the device is a 5701 and the phy number isn't 1. That way, the extra phys never get probed. With that change, it works except that I'm getting frequent bogus bge0: gigabit link up messages. I haven't been able to figure out why yet. They don't appear to affect packet flow at all. From investigating the Linux driver, I gather there are a few features in these chips which may need workarounds (e.g., the Debian driver includes a new firmware image for 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 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
Re: Broadcom 5701 (3com 3c996B-T) phy support in 4.5?
In article [EMAIL PROTECTED], David Malone [EMAIL PROTECTED] wrote: We've had alot of trouble with the builtin card in our Dell 2550s. I'm going to try swapping hardware to see if we've got a bad machine, but I suspect the chip is just plain broken. 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, 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
Re: Broadcom 5701 (3com 3c996B-T) phy support in 4.5?
In article [EMAIL PROTECTED], Jonathan Stone [EMAIL PROTECTED] wrote: Thanks for the responses. Any chance the miidevs hack and phy workarounds will make it into -current or FreeBSD 4.5? I'm not going to commit anything unless/until I get the driver working 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 Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: dynamic linking: want to play with fire
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/libexec/rtld-elf. 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
Re: detecting linux emulation in rtld.c?
In article [EMAIL PROTECTED], Lamont Granquist [EMAIL PROTECTED] wrote: can anyone suggest a method of determining inside libexec/rtld-elf/rtld.c if a binary being run is native or linux emulation? If the FreeBSD dynamic linker is running at all, the binary is probably 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 [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Can TCP changes be put in RELENG_4?
In article [EMAIL PROTECTED], Matthew Dillon [EMAIL PROTECTED] wrote: These changes are performance fixes, not security fixes. I consider them fairly significant performance fixes, but these bugs have been in the TCP stack for literally a whole year without 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 can move to -stable. 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
Re: Intel gigabit driver
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... But it's also not under the GPL as such... Anyway, after the rants here on this list from time to time about Intel's strict NDA and Open Source driver problems I was surprised to see such a move from them. Part of the Intel Linux GiGE driver License: This license shall include changes to the Software that are error corrections or other minor changes to the Software that do not add functionality or features when the Software is incorporated in any version of a operating system that has been distributed under the GNU General Public License 2.0 or later. This patent license shall [...] 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 the files in it, and the word GNU doesn't appear anywhere. There is a file named LICENSE which is just a standard BSD license. I'll append it below. John Copyright (c) 1999 - 2001, Intel Corporation All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. Neither the name of Intel Corporation nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. [end] -- 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
Re: Intel gigabit driver
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 the files in it, and the word GNU doesn't appear anywhere. There is a file named LICENSE which is just a standard BSD license. I'll append it below. You've got an old one. The newest Linux driver on intel.com is e1000-3.5.19.tar.gz. And it talks about the GPL. Whoops! :-} Thanks for straightening me out! 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
Re: Intel gigabit driver
In article [EMAIL PROTECTED], Andre Oppermann [EMAIL PROTECTED] wrote: What happend at Intel? Their driver is even released under the BSD license! (and the Linux one under the GPL) That last bit is incorrect. The Intel driver for Linux is released under a 3-clause 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
Netgraph performance
In article [EMAIL PROTECTED], Julian Elischer [EMAIL PROTECTED] wrote: Netgraph is a prototyping tool, which has enough performance to be useful in non-performance-critical applications. (such as all sync interfaces). It is not designed for gigabit interfaces etc. You are selling Netgraph way too short. I've been using it intensively with gigabit interfaces, and it performs very, very well. For my application (which involves generating and responding to a whole bunch of network traffic) it has yielded a good 4-5 times better performance than any other 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
Re: distinguising read faults and write faults
In article [EMAIL PROTECTED], Nick Barnes [EMAIL PROTECTED] wrote: I am in the process of porting an incremental garbage collector to FreeBSD on x86. This garbage collector uses read barriers and write barriers for incrementality. The details are irrelevant; the key part is that I want to protect parts of memory and handle faults on the protected pages. On FreeBSD, I will be using mmap(MAP_ANON) to obtain memory, and mprotect() to raise the barriers, with a signal handler to handle barrier hits. The garbage collector in Modula-3 is constructed this way exactly. It works pretty well. I have worked out that I need to handle SIGBUS (not SIGSEGV, which surprised me), and that ucontext-mcontext.mc_trapno will be 12 (T_PAGEFLT, not T_PROTFLT, which surprised me). However, I don't see any way of distinguishing between read faults and write faults. This information doesn't appear to be anywhere in the ucontext or the siginfo. Is there any way of distingushing read faults from write faults (other than by decoding the instruction at mc_eip)? I don't know of a way. I notice that the collector in Modula-3 protects some regions as read-only and other regions as inaccessible (unreadable and unwritable). There is one thing you need to be aware of. You will need to wrap every system call which takes a pointer as an argument. If you pass a pointer to inaccessible memory to a system call, you don't get a signal. Instead, the call returns EFAULT. So you have to wrap every such system call and make sure its arguments have been made accessible before issuing the call. There is an example of this in the Modula-3 code (look for RTHeapDepC.c). It's a pain, because any little change in the prototype of a system call (e.g., addition of const) breaks compilation of the corresponding wrapper. As far as I can tell, the whole EFAULT mess is a relic from the days before system calls became restartable in Unix. Today it would 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 These Days I'm going to add this to FreeBSD. 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: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: cvsup14 (cvsup.above.net) not up to date
In article [EMAIL PROTECTED], Julian Elischer [EMAIL PROTECTED] wrote: It seems to be not updating.. maybe they didn't get the new version of cvsup (or installed the wrong one like I did to start with) telnet cvsup14.freebsd.org 5999 shows that they are running the corrected version of CVSup. If they are still out of date, could you please drop a note to the maintainer? All maintainers are listed in the handbook: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvsup.html#CVSUP-MIRRORS In the case of cvsup14, the address is [EMAIL 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: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: local changes to CVS tree
In article [EMAIL PROTECTED], Peter Pentchev [EMAIL PROTECTED] wrote: Also, I'm not really sure if CVS would allow having two vendor branches (say, RELENG_4 and RELENG_5) and two corresponding working branches (your changes to RELENG_4 and your changes to RELENG_5, which might be *way* different). CVS claims to support multiple vendor branches, but in practice it doesn't work in any useful sense. There's at least one place in the CVS sources where the vendor branch is hard-coded as 1.1.1. You really don'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 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
Re: local changes to CVS tree
In article [EMAIL PROTECTED], Nate Williams [EMAIL PROTECTED] wrote: Any chance of getting CVSup to transfer from a remote repository to a local vendor branch, instead of from a remote repository to a local repository? The problem is that you aren't just transferring bits from the HEAD, but from multiple active branches. As John already stated, CVS doesn't handle multiple 'vendor' branches well (and in this case, the FreeBSD tree has vendor (CSRG) branches, FreeBSD vendor branches (RELENG_2, RELENG_3, ..., contrib vendor branches (TCSH, GCC, etc..) CVS is simply not setup to do what you ask. :( No, Terry's idea is sound as long as you only try to track one branch of FreeBSD. I.e., you consider FreeBSD to be your vendor, and you do a checkout-mode type of fetch from a branch of the FreeBSD repository and directly import it onto your own vendor branch. This would meet the needs of a lot of people, e.g., companies who make products based on FreeBSD. 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 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, 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
Re: local changes to CVS tree
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 effect that company's vendor. I can see how that would work for RELENG_4, but for the HEAD, many of the files on the HEAD in /usr/src/contrib are on vendor branches, which means it would be a *nightmare* to get that right (IMO). It would still work just the same. You're just checking out -current and importing it onto your own vendor branch. You don't know or care about FreeBSD's vendor branch. Of course (and this is one of the big complications), CVSup would have to map the version numbers somehow. Another big complication would be that at some point in the future a user would want to switch from being based on RELENG_4 to being based on RELENG_5. I have a feeling that could get tricky for CVSup to deal with. Although, it may not be as useful to developers, who often have to track development in multiple branches (for MFC's). Right, it would be pretty worthless for FreeBSD developers. Maybe if the economy gets worse ... *sigh* Let's hope it doesn't come down to that. Just looking for that silver lining. Mom would be so proud of me. :-) John To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: local changes to CVS tree
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 working on it that I just don't have these days. Maybe if the economy gets worse ... [...] I guess a better question would be whether funding would help? Sure -- that would take care of the my real jobs take priority problem. But I'm currently on two open-ended jobs, which is the most I can manage effectively. So right now I can't guess when I could do it even if I had funding. I'd very much like to do it, but I can't until I've met my existing commitments. John To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Routing Performance?
In article [EMAIL PROTECTED], Deepak Jain [EMAIL PROTECTED] wrote: The new P4s are shipping with 800mhz RAMBUS memory modules. Wouldn't 2GB of 800mhz RAM go a long way to evening out the performance between a PC/FreeBSD box and all but the most specialized, packet-pushing ASICs? I doubt it. My understanding is that RAMBUS memory is faster for long burst transfers, but that its random access latency is actually worse than that of conventional memory. Your routing table lookups (random accesses into a huge data structure) would be slower, not faster. 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 RAMBUS memory. 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: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Routing Performance?
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 DMA transfers between the NICs and RAM. Actually, it wouldn't help the DMA transfers either. They'd be limited by the PCI bus bandwidth, not the memory bandwidth. 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: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gzipped crashdumps
In article [EMAIL PROTECTED], Kris Kennaway [EMAIL PROTECTED] wrote: Anyone else think this patch from NetBSD is worthwhile? Yes yes yes yes yes! That's 5 votes in favor of it already. :-) Should I also extend it to support bzip2'ed dumps now that 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. 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
PLEASE REVIEW: loader fix for gzipped kernels
I would appreciate another pair of eyes on the attached patch before
I commit it.
I have been working with gzipped kernels a lot lately, and have
noticed that when the loader tries to load certain kernels, it fails
with the message elf_loadexec: cannot seek. I tracked this down to
a bug in src/lib/libstand/lseek.c, which is fixed by this patch.
Here is the bug that it fixed. Libstand maintains a read-ahead buffer
for each open file, so that it can read in chunks of 512 bytes for
greater efficiency. When the loader tries to lseek forward in a file
by a small amount, it sometimes happens that the target file offset is
already in the read-ahead buffer. But the existing code in lseek.c
simply discards the contents of that buffer and does a seek directly
on the underlying file. This results in an attempt to seek backwards
in the file, since some of the data has already been read into the
read-ahead buffer. Gzipped data streams cannot seek backwards, so an
error is returned.
The code added by the patch checks to see if the desired file offset
is already in the read-ahead buffer. If it is, the code simply
adjusts the buffer pointer and length, thereby 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. Polstra Co., Inc.Seattle, Washington USA
Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa
Index: lseek.c
===
RCS file: /home/ncvs/src/lib/libstand/lseek.c,v
retrieving revision 1.1.1.1.6.1
diff -u -r1.1.1.1.6.1 lseek.c
--- lseek.c 2000/09/10 01:32:06 1.1.1.1.6.1
+++ lseek.c 2001/08/29 17:45:21
@@ -70,6 +70,8 @@
off_t
lseek(int fd, off_t offset, int where)
{
+struct stat sb;
+off_t bufpos, filepos, target;
struct open_file *f = files[fd];
if ((unsigned)fd = SOPEN_MAX || f-f_flags == 0) {
@@ -94,6 +96,39 @@
return (-1);
}
return (f-f_offset);
+}
+
+/*
+ * If there is some unconsumed data in the readahead buffer and it
+ * contains the desired offset, simply adjust the buffer pointers.
+ */
+if (f-f_ralen != 0) {
+ if ((filepos = (f-f_ops-fo_seek)(f, (off_t)0, SEEK_CUR)) == -1)
+ return (-1);
+ bufpos = filepos - f-f_ralen;
+ switch (where) {
+ case SEEK_SET:
+ target = offset;
+ break;
+ case SEEK_CUR:
+ target = bufpos + offset;
+ break;
+ case SEEK_END:
+ if ((f-f_ops-fo_stat)(f, sb) == -1 || sb.st_size == -1) {
+ errno = EOFFSET;
+ return (-1);
+ }
+ target = sb.st_size + offset;
+ break;
+ default:
+ errno = EINVAL;
+ return (-1);
+ }
+ if (bufpos = target target filepos) {
+ f-f_raoffset += target - bufpos;
+ f-f_ralen -= target - bufpos;
+ return (target);
+ }
}
/*
Re: PLEASE REVIEW: loader fix for gzipped kernels
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 smaller. I'll incorporate that and then commit it to -current. John To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: PLEASE REVIEW: loader fix for gzipped kernels
In article [EMAIL PROTECTED], Matt Dillon [EMAIL PROTECTED] wrote: I'll give it a quick test after you commit it (I can combine the test with some other work I'm doing). Thanks. I've committed it, and it should hit the mirrors within the next hour. 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 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
Re: cvsup ports always failed
In article 000d01c12d7d$24fb5ea0$0245a8c0@chojin, Chojin [EMAIL PROTECTED] wrote: *** *** runtime error: ***gc: Could not extend the traced heap *** Please read the CVSup FAQ at http://www.polstra.com/projects/freeware/CVSup/ There is a question 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 Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Kernel level inet socket handling
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 next couple of weeks. 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: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Kernel level inet socket handling
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 might take you up on that. :-) The biggest obstacle is that I have been working on the -stable branch, so the changes will have to be made compatible with -current. I know you added some locking in -current, but I had the impression that it's fairly well hidden from most nodes. Is that right? John To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ld -X == important or not?
In article 3B7FE5C2.18273.16C3288@localhost, Dan Langille [EMAIL PROTECTED] wrote: How important is the -X option on ld? -X Delete all temporary local symbols. For most tar- gets, this is all local symbols whose names begin 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 Solaris linker did this by default. 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: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: pthreads and poll()
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 [EMAIL PROTECTED] 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
Re: Page Coloring
In article [EMAIL PROTECTED], Mike Smith [EMAIL PROTECTED] wrote: It looks about right, but page colouring is pointless unless and until we can determine the processor cache characteristics at runtime. Which we can't. Why can't we do this 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 [EMAIL PROTECTED] 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
Re: Page Coloring
In article [EMAIL PROTECTED], Matt Dillon [EMAIL PROTECTED] wrote: :In article [EMAIL PROTECTED], :Mike Smith [EMAIL PROTECTED] wrote: : : It looks about right, but page colouring is pointless unless and until we : can determine the processor cache characteristics at runtime. : : Which we can't. : :Why can't we do this 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 [EMAIL PROTECTED] Well, first of all the page coloring is not pointless with the sizes hardwired. The cache characteristics do not have to match exactly for page coloring to work. The effectiveness is like a log-graph, and you don't lose a lot by guessing wrong. Once you get past a designated cache size of 4-pages or so you've already reaped 90% of the benefit on systems which use N-way (2, 4, 8) associative caches (which is most systems these days). For systems with direct-mapped caches you reap 90% of the benefits once you get past 16 pages or so. Since most L1 caches these days are at least 16K and most L2 caches these days are at least 64K (and often much higher, such as on the IA32), our hardwired page coloring constants wind up being about 95% effective across the entire range of chips our OS currently runs on. Yes, I understand that. I'm just trying to find out why Mike keeps saying we cannot determine the processor cache characteristics at runtime. 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: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Page Coloring
In article [EMAIL PROTECTED], Matt Dillon [EMAIL PROTECTED] wrote: :Yes, I understand that. I'm just trying to find out why Mike keeps :saying we cannot determine the processor cache characteristics at :runtime. : :John You can find out from the cpuid or something like that, Yes. As I said, you can find out from the CPUID instruction by passing it the value 2 in %eax. but it's probably easier to simply do it programmatically, or not bother at all. It's not worth the effort. We would not 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. 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
Re: Why objcopy --strip-debug instead of strip?
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 to buildkernel doesn't generate modules with debugging symbols, regardless of whether CONFIGARGS='-g' was specified. I want to fix that. OK, sounds good to me. In your private mail you seemed to be asking why only the debugging symbols are stripped from the kernel instead of stripping all symbols. I think the modules should be stripped the same way as the kernel: with --strip-debug. That way you end up with the same set of symbols as if they were statically linked into the kernel. 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: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Why objcopy --strip-debug instead of strip?
In article [EMAIL PROTECTED], Sheldon Hearn [EMAIL PROTECTED] wrote: When the kernel is built as kernel.debug, why is it passed through objcopy --strip-debug before being installed, instead of being passed through strip? If you strip all of the symbols from the kernel then nothing that uses libkvm will work. Background: I recently found that the Handbook instructions for Debugging Loadable Modules Using GDB is mostly useless for post-mortem crash dump analysis, because buildkernel doesn't build modules with debugging support, even when CONFIGARGS=-g. The attached patch (for the i386 only) fixes this so that, if kernel.debug is built, foo.ko.debug etc. are built. For each foo.ko.debug, we produce foo.ko with objcopy --strip-debug and install foo.ko. What I'm unsure of 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't understand what this has to do with how the kernel is stripped. 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: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: dual booting -stable -current
In article [EMAIL PROTECTED], David O'Brien [EMAIL PROTECTED] wrote: On Fri, Jul 20, 2001 at 06:32:29PM +0200, Wilko Bulte wrote: I'm probably completely dim today so please bear with me :/ Thing is I want to setup a dual-boot box, running -stable -current. This box, a P2/266 has a 30G IDE disk. What I did is create ad0s1 - 256MB - holds root for -stable ad0s2 - 256MB - was supposed to hold root for -current ad0s3 - roughly 14G holds tmp,var,usr,usr/obj for -stable ad0s4 - ditto for -current You are getting bit by the root aliasing code (IIRC this is the right way to describe the problem). This makes it impossible to install multiple copies of FreeBSD on a single disk w/o hacking around the system. :-( The way to do this, is 1st install -stable. Create all four slices in the disk slice editor. In the label editor, do your normal thing, but don't bother doing anything with ad0s2. Continue with install as usual. Boot again from CDROM or floppies and enter the slice editor. Change the partition type of ad0s1 from 165 (FreeBSD FFS) to something else. Write this change to disk and exit from sysinstall. [...] The other way to do it is to install both -current and -stable on the same slice, but in different partitions within the slice. That works even on the Alpha, which doesn't have slices. For example, my dual-boot Alpha is set up like this: da0a/ and /usr and /var for -current da0bswap for both -current and -stable da0e/a (user files) for both -current and -stable da0f/ and /usr and /var for -stable da0g/c (user files) for both -current and -stable By default this boots into -current. If I want to boot stable, I press a key while the loader's spinner is spinning, and then type: unload set currdev=disk0f set module_path=/modules boot /kernel Of course if you want to boot into -stable by default, you can put this into your /boot/loader.conf file: currdev=disk0f bootfile=/kernel module_path=/modules Note, this stuff should go into -current's /boot/loader.conf, because current's loader is used even when booting -stable. You should make sure you arrange things so that the a partition holds -current's root filesystem rather than -stable's. The theory here is that -current's loader is more likely to be able to load -stable than vice versa. (This may not matter as much on the i386, but it seems to be important on the Alpha.) (If it seems like I have some minor details wrong in the above, I probably do. Things have been changing fast in -current.) Then you just have to set up your /etc/fstab files right for each system. In my case, -current's looks like this (irrelevant lines omitted): /dev/da0b noneswapsw 0 0 /dev/da0a / ufs rw 1 1 /dev/da0f /stable ufs rw 2 2 /dev/da0e /a ufs rw 2 2 /dev/da0g /c ufs rw 2 2 and -stable's looks like this: /dev/da0b noneswapsw 0 0 /dev/da0f / ufs rw 1 1 /dev/da0a /currentufs rw 2 2 /dev/da0e /a ufs rw 2 2 /dev/da0g /c ufs 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 -- 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: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ELF p_offset p_vaddr
In article [EMAIL PROTECTED], milunovic [EMAIL PROTECTED] wrote: I'm little confused.I'm reading ELF specification and I found that p_offset and p_vaddr should be congrunet to module PAGE_SIZE. So is this correct ? If it isn't can anybody tell me what is correct. It is correct. It is done that way so that the file can be loaded into memory simply by mapping it. Mapping occurs on page boundaries. #define PAGE_SIZE 4096 p_offset % PAGE_SIZE == p_vaddr % PAGE_SIZE Yes, that's correct. For example, notice that the final 3 digits are the same here in the VMA and File off columns. PAGE_SIZE == 4096 == 0x1000. blake$ objdump -h /usr/bin/id /usr/bin/id: file format elf32-i386 Sections: Idx Name Size VMA LMA File off Algn 0 .interp 0019 080480f4 080480f4 00f4 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 1 .note.ABI-tag 0018 08048110 08048110 0110 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .hash 00d8 08048128 08048128 0128 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .dynsym 0230 08048200 08048200 0200 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .dynstr 0138 08048430 08048430 0430 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 5 .rel.bss 0010 08048568 08048568 0568 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .rel.plt 0098 08048578 08048578 0578 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 7 .init 000b 08048610 08048610 0610 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 8 .plt 0140 0804861c 0804861c 061c 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 9 .text 0928 0804875c 0804875c 075c 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 10 .fini 0006 08049084 08049084 1084 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 11 .rodata 035a 080490a0 080490a0 10a0 2**5 CONTENTS, ALLOC, LOAD, READONLY, DATA 12 .data 000c 0804a3fc 0804a3fc 13fc 2**2 CONTENTS, ALLOC, LOAD, DATA 13 .eh_frame 0004 0804a408 0804a408 1408 2**2 CONTENTS, ALLOC, LOAD, DATA 14 .ctors0008 0804a40c 0804a40c 140c 2**2 CONTENTS, ALLOC, LOAD, DATA 15 .dtors0008 0804a414 0804a414 1414 2**2 CONTENTS, ALLOC, LOAD, DATA 16 .got 0058 0804a41c 0804a41c 141c 2**2 CONTENTS, ALLOC, LOAD, DATA 17 .dynamic 0088 0804a474 0804a474 1474 2**2 CONTENTS, ALLOC, LOAD, DATA 18 .bss 0130 0804a4fc 0804a4fc 14fc 2**3 ALLOC 19 .comment 00c8 14fc 2**0 CONTENTS, READONLY 20 .note 0050 15c4 2**0 CONTENTS, READONLY 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: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: MFC'ing new md(4) functionality?
In article [EMAIL PROTECTED], David O'Brien [EMAIL PROTECTED] wrote: On Tue, Jun 05, 2001 at 07:10:56AM -0500, Jacques A. Vidrine wrote: Dumb question: Can we just add a RELENG_4 tag to the files in such a case? You could get by 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 -- 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: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: cvsup.freebsd.org I/O error
In article [EMAIL PROTECTED], Matt Dillon [EMAIL PROTECTED] wrote: Not sure who to notify here... I tried twice, this looks like a real error. -Matt /usr/local/bin/cvsup -g -r 20 -L 2 -h cvsup.freebsd.org /usr/share/examples/cvsup/cvs-supfile SetAttrs ports/emulators/sim6811/distinfo,v SetAttrs ports/emulators/sim6811/files/patch-aa,v SetAttrs ports/emulators/sim6811/files/patch-ab,v SetAttrs ports/emulators/sim6811/pkg-comment,v SetAttrs ports/emulators/sim6811/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 -- 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: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ddb - gdb help?
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 debugging symbols, you can do "gdb -k kernel.debug" and use the "info line" command to get that information. John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SCSI-over-* hacks
In article Pine.BSF.4.21.0103211840550.79471-10@localhost, Max Khon [EMAIL PROTECTED] wrote: hi, there! On Tue, 20 Mar 2001, Mike Smith wrote: Has anyone implemented/thought of implementing: - a CAM transport for ATAPI 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 FreeBSD. John, who just bought an ATAPI CD-RW drive -- 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: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: exit() does not do dlclose()?
In article [EMAIL PROTECTED],
Brian McGovern [EMAIL PROTECTED] wrote:
I'm playing with an application that uses dlopen() to load some libraries. I
use the _init function to set the libraries up. I've also set up the _fini
functions to shut things down.
I see, in the man page, that dlclose() will unload the libraries and call
_fini.
My question is whether or not exit() does the same thing? It currently does
not appear to, although that would seem rather odd to me, given the other
types of cleanup it does.
It should clean them up including calling their _fini functions. From
src/libexec/rtld-elf/rtld.c:
/*
* Cleanup procedure. It will be called (by the atexit mechanism) just
* before the process exits.
*/
static void
rtld_exit(void)
{
Obj_Entry *obj;
dbg("rtld_exit()");
wlock_acquire();
/* Clear all the reference counts so the fini functions will be called. */
for (obj = obj_list; obj != NULL; obj = obj-next)
obj-refcount = 0;
wlock_release();
objlist_call_fini(list_fini);
/* No need to remove the items from the 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.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
Re: CVSup7.FreeBSD.org is back in service
In article [EMAIL PROTECTED], Julian Elischer [EMAIL PROTECTED] wrote: I have the folowing suggestion for CVSup.. the ability to specify several servers. Cvsup can have a quick exchange with each to inquire about load and check the latency and bandwidth and the last time updated, and choose the best Since you control both ends this is possible.. This is a frequently requested feature, but I've always been reluctant to provide it. Human nature being what it is, I'm afraid soon everybody would have 15 servers listed in their supfiles. So 15 servers would get hit on each update instead of just one. It is true that the load query wouldn't hit the servers nearly as hard as an actual update. But it would require forking a process at least. (Yes, it could be done by creating a thread, but experience has shown that to be a bad idea. All you need is one client doing something weird to trigger a bug in the server, and poof, the master server has crashed. It's a lot safer to isolate each client in its own process as quickly as possible.) Also, the loads on the mirrors I've observed vary erratically and rapidly. Servers can and do go from 20 clients to 3 clients in a matter of seconds. So the results of a load query 15 seconds ago aren't all that valuable, nor are figures representing load averages over time. I would rather leave load balancing out of the CVSup protocol and have it 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 to use. (Sorry, I don't remember the URL.) 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: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
CVSup7.FreeBSD.org is back in service
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 intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
cvsup7.freebsd.org downtime for upgrades
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 [EMAIL PROTECTED] 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
Re: cvsup7.freebsd.org downtime for upgrades
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 the disks and bring the OS up to date. Thanks in advance for your patience. This has unfortunately escalated to "downtime for repairs." :-( CVSup7 will be down for at least a few days. People who rely on it should switch to one of the other mirrors for the time being. There are 14 others (cvsup1 - cvsup15) in the US to choose from. I apologize for the inconvenience. The NetBSD, OpenBSD, and gcc collections which existed only on cvsup7 will be unavailable until it comes back up. 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: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Process virtual memory question
In article Pine.SOL.4.21.010008490.22923-10@jade, Zhiui Zhang [EMAIL PROTECTED] wrote: Although the 4.4 BSD design and implementation book says the text part of a process starts from 0x,, it actually starts from some place around 0x800, (or 0x8048000 to be exact). What's in the area between 0 - 0x800,? Why do we not use it if it is left empty as shown by /proc/pid/map? How is the magic number 0x8048000 determined? Thanks. Processes used to be mapped at address 0 when we used the a.out object file format. We changed the starting address to 0x8048000 when we switched to the ELF format. That magic address came from SVR4, the first system to use ELF. I am not 100% sure why the SVR4 developers chose that address. I think it may have been so that they could map libc and the dynamic linker at the fixed address 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 [EMAIL PROTECTED] 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
Re: Process virtual memory question
In article Pine.SOL.4.21.010352290.24593-10@jade, Zhiui Zhang [EMAIL PROTECTED] wrote: Thanks. It just occurs to me that Linux kernel used to have something like this in routine BUG(): * ((char *) 0) = 0; It is called when there is a kernel bug. So address 0 should not be mapped writable, otherwise all C statements " char * p = NULL; * p = value; " would be legal. Right. Address 0 is not mapped writable in FreeBSD. The book "Unix Internals - A Practical Approach" by S.D. Pate has a figure showing in ELF format, the stack lies BELOW the code segment and grows downwards. This might have something to do with code starting from 0x8048000. Yes, I think you are right, now that my memory is returning. :-) In SVR4 the stack grew downwards from 0x800. I think that libc 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] 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
KVM switch vs. FreeBSD psm driver
I realize this is a well-known problem. Although there's much discussion about it in the mailing list archives, I couldn't find an actual solution. 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 Christmas, but I also had problems with -stable) it doesn't work right at all. It's got the same symptoms everybody else has reported: the cursor jumps around, and lots of "psmintr: out of sync" messages get logged. I found a posting in -hackers where Kazutaka YOKOTA [EMAIL PROTECTED] said: You can force FreeBSD to use the mouse as the standard PS/2 mouse by specifying the flags 0x200 to the psm driver. This way, the mouse should always work. But, you cannot use the wheel. However, setting that flag hasn't helped me at all. Here are the relevant parts of "/var/run/dmesg.boot" from a verbose boot-up: psm0: current command byte:0047 psm0: PS/2 Mouse flags 0x200 irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 255-, 2 buttons psm0: config:0200, flags:, packet size:3 psm0: syncmask:c0, syncbits:00 The mouse itself is a no-name 2-button PS/2 mouse. It doesn't have a wheel or anything else "extra". It works fine when connected directly to the computer. I have also tried various combinations of flags 0x100 (NOCHECKSYNC) and 0x400 (NORESET) without any luck. The useless mouse behavior happens with moused and with XFree86 + no moused. It happens whether I specify the protocol as "ps/2" or as "auto". The KVM switch claims to have "Microsoft Intellimouse support and emulation." However, in the troubleshooting section of its manual it says you should make sure your driver is "either for a Standard PS/2 or Microsoft-compatible PS/2" mouse." I don't care about wheels, and I'm even willing to get by with only 2 buttons. I don't mind hacking up the psm driver if necessary. I just want the mouse to work with this switch. Any suggestions? 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: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KVM switch vs. FreeBSD psm driver
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 the one that was booted the mouse jumps, psm errors, etc. That doesn't seem to help in my case, unfortunately. John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KVM switch vs. FreeBSD psm driver (Solved!)
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 Christmas, but I also had problems with -stable) it doesn't work right at all. It's got the same symptoms everybody else has reported: the cursor jumps around, and lots of "psmintr: out of sync" messages get logged. I'm happy to report that this problem is solved now. After one fellow wrote to me and reported that his switch of the same model worked OK, I hunted around on the Belkin web site. It turns out that Belkin assembled a few thousand of the units with two EPROMs swapped, and mine was one of them. I moved the chips to their proper sockets, and now everything works fine. You can find the gory details here: http://www.belkin.com/support/downloads/manuals/Omnipro.pdf 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: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/rtld.c:2033
In article [EMAIL PROTECTED],
Russell L. Carter [EMAIL PROTECTED] wrote:
Bingo!
Thanks guys!
Not so fast there, fella. You're not getting off that easily. ;-)
Could you please try the patch below? It is like the patch that Paul
sent, except it should handle error conditions better.
This patch is against -current, but I think it will apply cleanly to
-stable too.
Thanks,
John
Index: rtld.c
===
RCS file: /home/ncvs/src/libexec/rtld-elf/rtld.c,v
retrieving revision 1.50
diff -u -r1.50 rtld.c
--- rtld.c 2000/11/07 22:41:53 1.50
+++ rtld.c 2001/01/05 00:13:18
@@ -77,6 +77,8 @@
static Obj_Entry *digest_phdr(const Elf_Phdr *, int, caddr_t, const char *);
static Obj_Entry *dlcheck(void *);
static bool donelist_check(DoneList *, const Obj_Entry *);
+static void errmsg_restore(char *);
+static char *errmsg_save(void);
static char *find_library(const char *, const Obj_Entry *);
static const char *gethints(void);
static void init_dag(Obj_Entry *);
@@ -457,6 +459,30 @@
va_end(ap);
}
+/*
+ * Return a dynamically-allocated copy of the current error message, if any.
+ */
+static char *
+errmsg_save(void)
+{
+return error_message == NULL ? NULL : xstrdup(error_message);
+}
+
+/*
+ * Restore the current error message from a copy which was previously saved
+ * by errmsg_save(). The copy is freed.
+ */
+static void
+errmsg_restore(char *saved_msg)
+{
+if (saved_msg == NULL)
+ error_message = NULL;
+else {
+ _rtld_error("%s", saved_msg);
+ free(saved_msg);
+}
+}
+
static const char *
basename(const char *name)
{
@@ -696,7 +722,7 @@
if (obj == (Obj_Entry *) handle)
break;
-if (obj == NULL || obj-dl_refcount == 0) {
+if (obj == NULL || obj-refcount == 0 || obj-dl_refcount == 0) {
_rtld_error("Invalid shared object handle %p", handle);
return NULL;
}
@@ -1184,13 +1210,20 @@
objlist_call_fini(Objlist *list)
{
Objlist_Entry *elm;
+char *saved_msg;
+/*
+ * Preserve the current error message since a fini function might
+ * call into the dynamic linker and overwrite it.
+ */
+saved_msg = errmsg_save();
STAILQ_FOREACH(elm, list, link) {
if (elm-obj-refcount == 0) {
dbg("calling fini function for %s", elm-obj-path);
(*elm-obj-fini)();
}
}
+errmsg_restore(saved_msg);
}
/*
@@ -1202,11 +1235,18 @@
objlist_call_init(Objlist *list)
{
Objlist_Entry *elm;
+char *saved_msg;
+/*
+ * Preserve the current error message since an init function might
+ * call into the dynamic linker and overwrite it.
+ */
+saved_msg = errmsg_save();
STAILQ_FOREACH(elm, list, link) {
dbg("calling init function for %s", elm-obj-path);
(*elm-obj-init)();
}
+errmsg_restore(saved_msg);
}
static void
@@ -2030,7 +2070,8 @@
{
const Needed_Entry *needed;
-assert(root-refcount != 0);
+if (root-refcount == 0)
+ return;
root-refcount--;
if (root-refcount == 0)
for (needed = root-needed; needed != NULL; needed = needed-next)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/rtld.c:2033
%Could you please try the patch below? It is like the patch that Paul %sent, except it should handle error conditions better. % %This patch is against -current, but I think it will apply cleanly to %-stable too. My pleasure. This patch applies cleanly against a two day old -stable, and works just as well as the first patch, i.e., my program works as expected. Thanks, Russell! I'll commit it to -current and MFC in a few days. 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: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/rtld.c:2033
In article [EMAIL PROTECTED], Russell L. Carter [EMAIL PROTECTED] wrote: On a fairly recent -STABLE I am getting this failure: ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/rtld.c:2033 I assume I'm doing something stupid, however the same code works on Linux gcc-2.95.2, so I'm looking for what the difference might be. The program is an ACE/TAO C++ program that dlsym()s an object, uses it happily, and then gets the assertion when dlclose()ing from the containing object's dtor. The assertion is that the refcount != 0. What should I do to fix that? There is a bug in the dynamic linker in connection with calling dlopen or dlclose from a static constructor or destructor, and this sounds like it's related to that. I came up with a fix for it which Peter Wemm was testing at Yahoo. That was a few months ago, and I'll have to dig it out again after the holiday madness has subsided. If you haven't heard from me by Saturday Jan. 6, I'd appreciate a gentle reminder to [EMAIL PROTECTED]. 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: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
