Re: gif(4) question
[This question is more appropriate for -net IMHO] -On [20010322 03:00], David E. Cross ([EMAIL PROTECTED]) wrote: >I recently tried (for the first time) to get gif running under FreeBSD >4.3-BETA (cvsup-ed yesterday). I noticed the following: > >gifconfig gif0 inet 10.1.1.1 10.1.2.1 >ifconfig gif0 192.168.1.1 192.168.1.2 netmask 0xff00 > >and then I 'ping 192.168.1.1' it will try to route the packet instead of >reply directly. I need to 'route add 192.168.1.1 127.0.0.1' to have it >reply to the packet directly. I don't need to do this for other types >of interfaces... did I mess something up, is this how it is supposed to >be (doesn't seem to be documented as such). I think that's how it is supposed to be given that gif's main function is to tunnel things and it works on a point-to-point basis. I might be wrong, in which case I am sure UMEMOTO-san or ITOJUN-san will correct me. -- Jeroen Ruigrok van der Werven/Asmodai .oUo. asmodai@[wxs.nl|freebsd.org] Documentation nutter/C-rated Coder BSD: Technical excellence at its best D78D D0AD 244D 1D12 C9CA 7152 035C 1138 546A B867 What is to be, will be. And what isn't to be sometimes happens... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Routing latency
On Monday 19 March 2001 4:36, Will Andrews wrote: > On Mon, Mar 19, 2001 at 07:46:53PM -0500, Dennis wrote: > > I never got an answer (as usual) from bill paul when I made the > > suggestions, and noone seemed interested in getting it fixed. He seems to > > get insulted when I infer that he did something wrong. > > It's like they say: "money talks". Similarly, "patches talk". > Suggestions don't really do that. I'm not defending Dennis here, but this statement infers that nothing gets done unless maintainers are a) paid or b) someone else does the work for them. I certainly hope this is not the case. -- Regards, Devin. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: tuning a VERY heavily (30.0) loaded s cerver
On Wed, Mar 21, 2001 at 04:14:32PM -0300, Rik van Riel wrote: > The (maybe too lightweight) structure I have in my patch > looks like this: > > struct pte_chain { > struct pte_chain * next; > pte_t * ptep; > }; > > Each pte_chain hangs off a page of physical memory and the > ptep is a pointer to a page table entry. > > The page struct of the page table page itself is used to > note down which address space and offset we have. This means > that FreeBSD's pv_pmap, pv_va and pv_ptem are in the page > table page and NOT in each pte_chain structure... How about portability? It maybe efficient, but it is not easy to port to other platforms. -- [EMAIL PROTECTED] Branda Open Site (BOS) [EMAIL PROTECTED] http://www.branda.to/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Help please (Server crash)
I have server under FreeBSD 4.2 with apache fired simple C++ CGI for each connection. Aproximately every 12H uptime server stop responding. Kernel answers to ping, establish TCP connection but unable to fork process. (no messages in /var/log/messages) This is statisitics (netstat -nm & top ) just before crash. Any ideas? Thank you! # Thu Mar 22 00:50:00 MSK 2001 # 4945/6928/40960 mbufs in use (current/peak/max): #2604 mbufs allocated to data #2341 mbufs allocated to packet headers # 2530/3804/10240 mbuf clusters in use (current/peak/max) # 9340 Kbytes allocated to network (30% of mb_map in use) # 0 requests for memory denied # 0 requests for memory delayed # 0 calls to protocol drain routines # last pid: 44768; load averages: 0.47, 0.38, 0.35 up 0+10:24:07 00:50:00 # 175 processes: 1 running, 163 sleeping, 11 zombie # Mem: 22M Active, 35M Inact, 42M Wired, 6516K Cache, 35M Buf, 144M Free # Swap: 500M Total, 6220K Used, 494M Free, 1% Inuse -- Dmitry Samersoff, [EMAIL PROTECTED], ICQ:3161705 http://devnull.wplus.net * There will come soft rains ... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Help please (Server crash)
On Thu, Mar 22, 2001 at 03:33:14PM +0300, Dmitry Samersoff wrote: > Any ideas? With hangs like this using the debugger to find out what the kernel is doing is often the best bet. You'll need to compile the debugger into the kernel and then leave the server on a vty that doesn't have X running. When it hangs try breakin into the debugger (ctl-alt-esc) and get a trace (type trace). You may need to do this a few times to get an idea of what's going on. The kernel debugging section of the handbook has more details on this sort of thing. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Attemt to compile with INVARIANTS failed
root@ds101:DS101#make linking kernel.debug vm_zone.o: In function `zalloci': /sys/compile/DS101/../../vm/vm_zone.h:81: undefined reference to `zerror' /sys/compile/DS101/../../vm/vm_zone.h:91: undefined reference to `zerror' vm_zone.o: In function `zfreei': /sys/compile/DS101/../../vm/vm_zone.h:106: undefined reference to `zerror' vm_zone.o: In function `_zget': /sys/compile/DS101/../../vm/vm_zone.c:380: undefined reference to `zerror' *** Error code 1 -- Dmitry Samersoff, [EMAIL PROTECTED], ICQ:3161705 http://devnull.wplus.net * There will come soft rains ... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Remote boot, but not diskless operation
> > they've done this, but their newest BIOS (8 days old) still has a 0.78 > PXE revision (I've seen more recent DELL machines with a 0.99 - I assume > this is better) I have many intel MBs with built-in fxp nics that have 0.78 that work with 4.2's pxeboot just fine - I'm not trying to boot kernel remotely for local filesystesm, but I can't see why it wouldn't work. Off hand I'd guess that you have to put the right options in your dhcp server to tell it to find a 'local' root disk. Good luck. Fred -- Fred Clift - [EMAIL PROTECTED] -- Remember: If brute force doesn't work, you're just not using enough. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: tuning a VERY heavily (30.0) loaded s cerver
On Thu, 22 Mar 2001, thinker wrote: > On Wed, Mar 21, 2001 at 04:14:32PM -0300, Rik van Riel wrote: > > The (maybe too lightweight) structure I have in my patch > > looks like this: > > > > struct pte_chain { > > struct pte_chain * next; > > pte_t * ptep; > > }; > > > > Each pte_chain hangs off a page of physical memory and the > > ptep is a pointer to a page table entry. > > > > The page struct of the page table page itself is used to > > note down which address space and offset we have. This means > > that FreeBSD's pv_pmap, pv_va and pv_ptem are in the page > > table page and NOT in each pte_chain structure... > > How about portability? It maybe efficient, but it is not easy > to port to other platforms. IIRC the pmap layer is in the architecture-dependent code in the BSDs. For Linux we have forward pagetables in every architecture, whether it be in software or hardware. They turn out to be quite adequate as an alternative to vnodes ;) regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
question about BPF programming
Hi I read bpf(4) man page and have one question about BPF. Suppose I open one of free BPF devices /dev/bpf??. I can dup(2) descriptor of opened BPF device and get so called shared interface. Can I setup different filters on each descriptor for opened BPF device? If I can do it, how can I do the same with pcap(3) library? Thanks for answers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Intel driver doc's Take 2.
I just got off the phone with Linda Sanchez at our favorite company Intel. She is a Sr. "Marketing Engineer" (What is a marketing engineer?) for their LAN products. She is itnerested in helping us get the information we need to write drivers for their cards. But she also knows NDA's are not going away. She wants to meet us halfway in the short term. Somewhere between a datasheet and a programming manual, that we can get with no NDA. I know alot of you are totally fed up with Intel and at this point couldnt give two hoots about Intel or their cards. But she is willing to work with us to get us what we need. I told her it sounds like an all or nothing proposition that we NEED the programming manuals. Not datasheets, not fluffy reference drivers. But for the short term that is not going to happen. Sigh. She does want to try and help us like I said. She need's specific information that we need that we cant get unless we sign NDA's for the doc's so she can try and get them merged into a reference product somewhere between the datasheet (worthless) and the programming manual (NDA). I know this is not ideal or what bill, jonathon, or others want. They would rather Intel just get a friggin clue and stop being anal. And while in the long term this may change it isn't going to be soon. She is willing to compromise and try and get us doc's on the bits we need. Is anyone willing to try and work on a middle of the road to keep support current for Intel nic's? Or has everyone decided to just not waste the effort or time on Intel idiocy anymore? Either way is fine. It's not like we only support one brand of NIC's. I'm just making an offer, the only offer from Intel, to help work with OS developers. I completely understand everyone's attitude towards Intel and I think it's totally justified. And I am usually an all or nothing person. I don't do middle of the road. But thats the offer on the table. Try and get us what we need in manual in between the datasheet and the programming doc's. But it will be available without an NDA. This is the option we currently have. Any takers? If there are she want's me to collect specific item's that are needed. Like the recent PHY debacle. What item's do we need programming doc's on? Specific parts? Etc. In the long term maybe Intel will get a clue but I am not holding my breath. But this is a chance to try and get what we need under a non-NDA arrangement. So if anyone has any care whatsoever to make one last effort to support Intel hardware and wants to work on getting the information we need. Let me know. I *think* we can get her to piecemeal the info we need into a non NDA doc for us, piece by piece that is as good or better as the programming doc's. Anyway if there are any takers that want to work with me on getting the doc's required let me know. Otherwise i'm just like everyone else I dont have a 50 megaton nuclear device to beat Intel with to get them to do the right thing. And Intel support can be dropped. = -Chris Watson (316) 326-3862 | FreeBSD Consultant, FreeBSD Geek Work: [EMAIL PROTECTED] | Open Systems Inc., Wellington, Kansas Home: [EMAIL PROTECTED] | http://open-systems.net = WINDOWS: "Where do you want to go today?" LINUX: "Where do you want to go tomorrow?" BSD: "Are you guys coming or what?" = irc.openprojects.net #FreeBSD -Join the revolution! ICQ: 20016186 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
Random idea from the peanut gallery... Find someone who is NDA'd and knows both the programming manual and the needs of the device driver. Have that person compose a list of those bits of the manual most necessary for getting a working driver. This would be an explicit list of figures, diagrams, tables and text sections. I would assume that Intel legal would then go through the list and give a yea/nay for each item requested. For the contested items, perhaps a redacted/simplified version could be proposed instead, but hopefully the bulk of the request would accepted. Just my $0.02 -JohnG (neither NDA'd or working on the driver) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
[EMAIL PROTECTED] wrote: > > She need's specific information that we need that we cant get > unless we sign NDA's for the doc's so she can try and get them merged into > a reference product somewhere between the datasheet (worthless) and the > programming manual (NDA). I know this is not ideal or what bill, jonathon, > or others want. They would rather Intel just get a friggin clue and stop > being anal. And while in the long term this may change it isn't going to > be soon. She is willing to compromise and try and get us doc's on the bits > we need. Let me just pipe in a bit. Compromise seems just like the kind of thing marketing or legal would want to do. The problem is that _we_ cannot compromise because one cannot write a "half-way there" driver. It's a technical impossibility. Now, if Bill Paul, Jonathan Lemon or whoever can come up with a "compromise" that would work, fine. But otherwise, and I think otherwise is likely, please explain the above to this person. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] It's a rewarding life, but hey, somebody has to have all the fun, right? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
In article [EMAIL PROTECTED]> you write: > She need's specific information that we need that we cant get >unless we sign NDA's for the doc's so she can try and get them merged into >a reference product somewhere between the datasheet (worthless) and the >programming manual (NDA). Well, I applaud your effort, but I can't really think of how this would work. The information in the programming manual is required to program the chip. It is already a fairly concise manual, and if you axe anything out of it, it would mean that feature wouldn't be supported. A programming manual generally looks something like the following (completely made up) example: control register:offset 0, length 2 words bit 31:MWI enable bit 29-30: duplex settings 00 = full duplex 01 = half duplex 1x = auto negotiate In order for duplex settings to take effect, the chip must first be be reset to idle state, then the link settings changed bit 28:receiver enable 0 = disable 1 = enable before enabling the receiver, the receive control register must be set up appropriately, as well as the receive ring base and length registers. Exactly what in the above (fictional) example is it possible to axe out and still come up with a functional driver? Descriptions of each bit and their position in the register? The rules/caveats associated with each bit? I hate to say it, but anything that gets axed out of the manual basically means that those features of the chip will not be used. I honestly don't think that the marketer you talked to really understands this; I can't for the life of me see how anything less than the programming manual will be sufficient. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
On Fri, 23 Mar 2001, Daniel C. Sobral wrote: > Let me just pipe in a bit. Compromise seems just like the kind of thing > marketing or legal would want to do. The problem is that _we_ cannot > compromise because one cannot write a "half-way there" driver. It's a > technical impossibility. I agree 100%. I don't think this will fly either. I am just making the effort to work with Intel to get what we need. It's not going to happen overnight. Period. They are not going to change their NDA policy. In the future maybe. Actually I will forward the email she sent me this last time after I got off the phone with her an hour ago. I mentioned the problems Jonathan had with the GigE card. That's why she refers to him. Anyway I will forward it in a sec to the list. > Now, if Bill Paul, Jonathan Lemon or whoever can come up with a > "compromise" that would work, fine. But otherwise, and I think otherwise > is likely, please explain the above to this person. Well I have a feeling if bill even reads this, which he will probably see Intel in the subject and delete it, or has a procmail filter for 'Intel' :-) he will probably just get more frustrated then he is. Jonathan, I dont know. He is probably as fed up as everyone else. = -Chris Watson (316) 326-3862 | FreeBSD Consultant, FreeBSD Geek Work: [EMAIL PROTECTED] | Open Systems Inc., Wellington, Kansas Home: [EMAIL PROTECTED] | http://open-systems.net = WINDOWS: "Where do you want to go today?" LINUX: "Where do you want to go tomorrow?" BSD: "Are you guys coming or what?" = irc.openprojects.net #FreeBSD -Join the revolution! ICQ: 20016186 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Help please (Server crash)
Dmitry Samersoff writes: > I have server under FreeBSD 4.2 with apache fired simple C++ CGI for > each connection. > > Aproximately every 12H uptime server stop responding. > > Kernel answers to ping, establish TCP connection but unable to fork > process. > (no messages in /var/log/messages) Looks like you reach some of limits, may be maxproc for user httpd runs as. -- @BABOLO http://links.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: information on Intel Fast Ethernet and Gigabit (fwd)
-- Forwarded message -- Hello Mr. Chris Watson Thanks for taking the time to discuss with me your concerns. Could you take the the time to forward me some sort of representative list of the types of information that FreeBSD developers require to do driver development? Would like to focus on the pieces not covered by data sheet and non-NDA type documentation that you are using today, as we discussed. I would like to review this list and see if there's something that we can do about this. Also could you forward me more specific info on the issues with the FreeBSD driver written by J. Lemon. I would like to see what I can do to help out with these issues too. In the meantime, if you have any questions, please do not hesitate to call me. Thanks Linda P. Sanchez Sr. Product Marketing Engineer Network Communications Group LAN Access Division To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
For what it's worth, I believe I'm still committed to work on the GigE driver. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
btw- *I* have no problem with an NDA as long as it includes a rider that says what we could release as open source. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
In article [EMAIL PROTECTED]> you write: > >btw- *I* have no problem with an NDA as long as it includes a rider that says >what we could release as open source. Hah, me neither. In fact, if you want to try out a binary of my Intel GigE driver, it is at http://www.flugsvamp.com/~jlemon/fbsd/drivers -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
> [EMAIL PROTECTED] wrote: > > > > She need's specific information that we need that we cant get > > unless we sign NDA's for the doc's so she can try and get them merged into > > a reference product somewhere between the datasheet (worthless) and the > > programming manual (NDA). I know this is not ideal or what bill, jonathon, > > or others want. They would rather Intel just get a friggin clue and stop > > being anal. And while in the long term this may change it isn't going to > > be soon. She is willing to compromise and try and get us doc's on the bits > > we need. > > Let me just pipe in a bit. Compromise seems just like the kind of thing > marketing or legal would want to do. The problem is that _we_ cannot > compromise because one cannot write a "half-way there" driver. It's a > technical impossibility. No, no, no, no, no. You can write an open source driver that contains all the basic features one would want (i.e., Networking works). But advanced features in the manuals that a company considers valuable IP might not be open sourced (e.g., vlan tagging, teaming, crc offloading). Frankly, that's dumb, but as long as the basic reasonable support for a NIC is there I believe that meets a reasonable 'support' test. > > Now, if Bill Paul, Jonathan Lemon or whoever can come up with a > "compromise" that would work, fine. But otherwise, and I think otherwise > is likely, please explain the above to this person. > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
> > I hate to say it, but anything that gets axed out of the manual basically > means that those features of the chip will not be used. I honestly don't > think that the marketer you talked to really understands this; I can't > for the life of me see how anything less than the programming manual > will be sufficient. You should be allowed the whole manual, but some list of what can be made visible should not be all that hard to do- certainly after you've looked over the manual and you work with Intel to figure what is and isn't releasable. I have a personal contact with a manager in the LAN group at Intel who I'm visiting this weekend. We'll see if he has some influence in this matter. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
On Thu, Mar 22, 2001 at 10:39:58AM -0800, Matthew Jacob wrote: > > > > I hate to say it, but anything that gets axed out of the manual basically > > means that those features of the chip will not be used. I honestly don't > > think that the marketer you talked to really understands this; I can't > > for the life of me see how anything less than the programming manual > > will be sufficient. > > You should be allowed the whole manual, but some list of what can be made > visible should not be all that hard to do- certainly after you've looked over > the manual and you work with Intel to figure what is and isn't releasable. Sure. If intel would simply say: " we don't want the driver to support cisco ISL, checksum offloading, VLAN, or Wake On Lan features " I suppose I could work with that. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: 4.3-BETA world crashing 4.2-RELEASE kernel ?
> -Original Message- > From: David O'Brien [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, March 21, 2001 8:41 PM > To: Matt Simerson > Cc: [EMAIL PROTECTED] > Subject: Re: 4.3-BETA world crashing 4.2-RELEASE kernel ? > > First let me say to anyone reading the email I am replying to: > > don't do this > > On Wed, Mar 21, 2001 at 12:58:04PM -0700, Matt Simerson wrote: > > # cd /usr/src > > # make buildkernel KERNEL= > > # cd /usr/src; make buildworld > > # make installworld > > # make installkernel > > # mergemaster > > # reboot > > The order or "make buildworld" and "make buildkernel" are 100% totally > BACKWARDS. Actually, they aren't backwards. You've gone and snipped the parts of my original message that show that the commands are being executed at the same time. If either fails (for one reason or another as may happen) then I'll be able to plainly see why the build failed and correct it or go about fixing it manually. > Lets explain why: There are times when the kernel source is changed to > use constructs of newer compiler/assembler/linker tools. Thus the kernel > will not build with an older set of tools. The what "make buildkernel" > does is use the tools (ie, those built from the most up to date sources) > that are built during "make buildworld" to compile a new kernel. Thus > "make buildworld" must PROCEED "make buildkernel". Maybe I'm understanding you incorrectly here but according to what you just said, a "make buildkernel" will fail unless you have a set of compiler/assembler/linker tools in /usr/obj that were built from the make buildworld process. This is inaccurate at best and I suspect it's just plain wrong. I can "rm -r /usr/obj/*", "cd /usr/src; make clean", and then "make buildkernel KERNEL=" and it will succeed and build a happy little fully functionaly kernel. I've done this hundreds of times with success. So, I guess I'm not understanding your logic here. Would you care to explain further why this doesn't work? > Second, the install order above is not the conservative, careful > approach. One should issue "make installkernel && reboot" after the > "make buildkernel" to ensure the new kernel works > sufficiently well. Maybe that's _YOUR_ method for installing but it's not necessarily the best one. Kernel's are not guaranteed to be backwards compatible and I've installed a shiny new kernel that worked just fine and allowed my machine to come up single user but because of some rude change in /etc/rc, ipfw, or any of a number of places the machine couldn't make it to multi-user and allow me to get back in (via the network). When most of your servers are in a data-center 50 miles away and the rest are thousands of miles away, you'd rather not spend the next two hours talking a NOC monkey through a 10 minute process (if you have console). I prefer to do everything possible to make sure the system is going to boot correctly the first time and let me regain access. Success at building and installing the kernel, world, AND running mergemaster gives me a reasonably good chance that when I issue the reboot, it'll come up nice and happy. Second, if I'm going through the bother of compiling a buildworld it's because I want the latest version of world on my system. If there are some problems with the new kernel, I'm not going to revert back to world.old. I'll fix whatever is screwed up with kernel and proceed. Last, but not least, is that I don't have a warm body near all of my servers. I often want to do the make buildworld & kernel, installworld & kernel, and mergemaster and NOT reboot. Then I'll pop an email off to a warm body nearby and, at his leisure, have him give it a CTRL-ALT-DEL on the console and watch it to make sure it comes back up. > If not, one can always fall back to ``kernel.old''. One can fall back to kernel.old regardless. Even if I happen to have world.new installed, kernel.old will still work. There may be issues but if there is, they are surely no worse than running kernel.new with world.old. So, which is worse, the cart without a horse or a horse without a cart? > Since there is no > ``world.old''; after one does the "make installworld" backup tapes are > the only way of taking the system back to its previous state. I don't know many people who do buildworlds just for fun. If I'm doing a buildworld it's because I want the newer world installed. If I'm doing it on a server, it's because I've tested it on a dev box and I know it works the way I want. At that point, I have no reason to fall back to the previous world. Matt > -- > -- David ([EMAIL PROTECTED]) > GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 4MB pages
* Terry Lambert <[EMAIL PROTECTED]> [010322 11:47] wrote: > I know that this is going to look like I should have posted it > on the "-arch-questions" list, but there isn't one, and it > involves future work (I think), so here goes... > > > Has anyone tried playing with 4MB pages for doing other things? > [snip] > As usual, I'm playing with 4.x, not 5.x, so feel free to tell > me that this has already been thought of, and therefore is not > an issue for -arch. I think -hackers is more appropriate. As far as using 4MB pages, it would be nice to be able to add it for: 1) shm segements 2) mlock'd regions. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] Represent yourself, show up at BABUG http://www.babug.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Attemt to compile with INVARIANTS failed
On 22-Mar-01 Dmitry Samersoff wrote: > > root@ds101:DS101#make > linking kernel.debug > vm_zone.o: In function `zalloci': > /sys/compile/DS101/../../vm/vm_zone.h:81: undefined reference to > `zerror' > /sys/compile/DS101/../../vm/vm_zone.h:91: undefined reference to > `zerror' > vm_zone.o: In function `zfreei': > /sys/compile/DS101/../../vm/vm_zone.h:106: undefined reference to > `zerror' > vm_zone.o: In function `_zget': > /sys/compile/DS101/../../vm/vm_zone.c:380: undefined reference to > `zerror' > *** Error code 1 INARIANTS requires INVARIANT_SUPPORT, there is a note to this effect in LINT. -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: tuning a VERY heavily (30.0) loaded s cerver
Just an update on the lovely loaded BBS server. We made our record-breaking number of users last night. After implementing the changes suggested, and kqueue'ifying the BBS daemon. We saw a dramatic increase in server power. Top number of users was 4704 users. Serving SSH, HTTP, SMTP, innd, BBSD with no delays. (Meanwhile, we had kernel profiling ON :) ) We had peak load averages of 100.0, read: no delay. I am certain that we could taken on 6000 users had we had that many users. (It died due to unrelated reason, not because of the load since the number of users had gone down to 4400.) iostat became a fraction of what it used to be before we set vfs.vmiodirenable=1. (Why is vfs.vmiodirenable=1 not enabled by default?) We used to die at about 4200 users with average loads of 200.0 even 300.0 For those still interested in kq'ed BBSD stats: http://zoo.ee.ntu.edu.tw/~keichii I'm ponder if this should have been posted to FreeBSD-Advocacy. :^) -- +---+ | [EMAIL PROTECTED] | [EMAIL PROTECTED] | | http://iteration.net/~keichii | Yes, BSD is a conspiracy. | +---+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: tuning a VERY heavily (30.0) loaded s cerver
* Michael C . Wu <[EMAIL PROTECTED]> [010322 12:29] wrote: > Just an update on the lovely loaded BBS server. > We made our record-breaking number of users last night. > > After implementing the changes suggested, and kqueue'ifying > the BBS daemon. We saw a dramatic increase in server power. > > Top number of users was 4704 users. Serving SSH, HTTP, SMTP, innd, BBSD > with no delays. (Meanwhile, we had kernel profiling ON :) ) > We had peak load averages of 100.0, read: no delay. I am certain > that we could taken on 6000 users had we had that many users. > (It died due to unrelated reason, not because of the load since the > number of users had gone down to 4400.) iostat became a fraction of what > it used to be before we set vfs.vmiodirenable=1. > > (Why is vfs.vmiodirenable=1 not enabled by default?) It's not a good thing for boxes with < 128megs of ram IMO. It wastes a bunch of ram. When I get a chance I'm going to look at having FreeBSD auto tune such things as maxusers and things like vfs.vmiodirenable for large installs. Actually, i'm tempted to change the defaults for large installs then leave the "optimizations" for small machines to the people who have small machines. :) > We used to die at about 4200 users with average loads of 200.0 even 300.0 > For those still interested in kq'ed BBSD stats: > http://zoo.ee.ntu.edu.tw/~keichii > > I'm ponder if this should have been posted to FreeBSD-Advocacy. :^) Why not write up an article about this BBS scene and get it posted to slashdot or daemonnews? It would really make good press: "FreeBSD community responds to BBS problem with spectacular results." or something. :) -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
> On Fri, 23 Mar 2001, Daniel C. Sobral wrote: > > > Let me just pipe in a bit. Compromise seems just like the kind of thing > > marketing or legal would want to do. The problem is that _we_ cannot > > compromise because one cannot write a "half-way there" driver. It's a > > technical impossibility. > > I agree 100%. I don't think this will fly either. I am just making the > effort to work with Intel to get what we need. It's not going to happen > overnight. Period. They are not going to change their NDA policy. In the > future maybe. Actually I will forward the email she sent me this last time > after I got off the phone with her an hour ago. I mentioned the problems > Jonathan had with the GigE card. That's why she refers to him. Anyway I > will forward it in a sec to the list. [Speaking here from some experience with this set of issues.] The compromise that you want to strike, and really the *only* compromise that is going to work, is that the *documents* will remain undisclosed, but information from the documents that is necessary to produce a functional, high-performance driver may be disclosed, but *only* through the source code of the driver. Thus one or a small group of people sign the NDA, and keep the documentation. The driver is then developed and maintained by this team, who also have the opportunity to interact with Intel's engineering people. The source code resulting from this effort is then released publically. Intel should probably retain the right to veto code that you might want to put in the driver if they feel that it risks disclosure they don't want, but you don't have to suggest this to them unless you feel you need it as a bargaining chip. This would put them in the same situation as they are already in with their source-available Linux driver; it should not present any more intellectual property risks than they already face, and as a bonus, it gets us a better-supported driver. Regards, Mike -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: 4.3-BETA world crashing 4.2-RELEASE kernel ?
On 22-Mar-01 Matt Simerson wrote: >> Lets explain why: There are times when the kernel source is changed to >> use constructs of newer compiler/assembler/linker tools. Thus the kernel >> will not build with an older set of tools. The what "make buildkernel" >> does is use the tools (ie, those built from the most up to date sources) >> that are built during "make buildworld" to compile a new kernel. Thus >> "make buildworld" must PROCEED "make buildkernel". > > Maybe I'm understanding you incorrectly here but according to what you just > said, a "make buildkernel" will fail unless you have a set of > compiler/assembler/linker tools in /usr/obj that were built from the make > buildworld process. This is inaccurate at best and I suspect it's just plain > wrong. I can "rm -r /usr/obj/*", "cd /usr/src; make clean", and then "make > buildkernel KERNEL=" and it will succeed and build a happy little > fully functionaly kernel. I've done this hundreds of times with success. > > So, I guess I'm not understanding your logic here. Would you care to explain > further why this doesn't work? Hmm, maybe because you've been lucky to have done it wrong? Case in point: for 4.1 release, we upgraded to a new set of binutils (assembler, linker, etc.). Because the old asssembler was so broken, the new assembler could not compile the old code that had hacks in it to work around the bugs in the old assembler. Thus, if you tried to build a kernel without building world with the new assembler, the compile would fail. Thus, one needs to do the buildworld first to ensure the tools to compile the kernel are up to date. Please go read the archives if you want more of the hairy details. The process David described (which is the one that is in src/UPDATING) is the one that is supported. Other methods may work some of the time, but they won't work all of the time, and if it breaks for you it is your fault for not following the rather clear instructions that have been provided. :) >> Second, the install order above is not the conservative, careful >> approach. One should issue "make installkernel && reboot" after the >> "make buildkernel" to ensure the new kernel works >> sufficiently well. > > Maybe that's _YOUR_ method for installing but it's not necessarily the best > one. Kernel's are not guaranteed to be backwards compatible and I've Breakges of this time or very rare, and only in -current that I can remember. In fact, the only bad ones I've seen are when struct ucred changes causing mountd to start doing stupid things, but that has been permamently fixed in -current. However, as other people have pointed out, it is much easier to boot kernel.old if your new kernel is hosed and use that stable kernel to fix either the new kernel or the new world as appropriate. Really, if you wish to blow your own foot off that is fine, but do be aware that a) you shouldn't tell others to blow their feet off, and b) if you blow your own feet off it's your fault. :) In fact, if you are careful, you will note that src/UPDATING recommends that you do the installworld and /etc update in single user mode, not multiuser, which would avoid the problems you have seen with new kernels and old worlds. >> If not, one can always fall back to ``kernel.old''. > > One can fall back to kernel.old regardless. Even if I happen to have > world.new installed, kernel.old will still work. There may be issues but if > there is, they are surely no worse than running kernel.new with world.old. > So, which is worse, the cart without a horse or a horse without a cart? > >> Since there is no >> ``world.old''; after one does the "make installworld" backup tapes are >> the only way of taking the system back to its previous state. > > I don't know many people who do buildworlds just for fun. If I'm doing a > buildworld it's because I want the newer world installed. If I'm doing it on > a server, it's because I've tested it on a dev box and I know it works the > way I want. At that point, I have no reason to fall back to the previous > world. You don't run -current much it seems. :) (Not that I blame you, it is not for production machines.) The procedure described is the most robust one that has been come up with thus far. It has the greatest chance of success, though it is also somewhat painful (installworld in single user for example). You can do it differently if you wish (I do), but realize that if you do, you are on your own. -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 4.3-BETA world crashing 4.2-RELEASE kernel ?
On Thu, Mar 22, 2001 at 12:51:00PM -0700, Matt Simerson wrote: > Actually, they aren't backwards. You've gone and snipped the parts of my > original message that show that the commands are being executed at the same > time. I read you message twice and came away with the same idea. You should write more clearly. > Maybe I'm understanding you incorrectly here but according to what you just > said, a "make buildkernel" will fail unless you have a set of > compiler/assembler/linker tools in /usr/obj that were built from the make > buildworld process. This is inaccurate at best and I suspect it's just plain > wrong. I can "rm -r /usr/obj/*", "cd /usr/src; make clean", and then "make > buildkernel KERNEL=" and it will succeed and build a happy little > fully functionaly kernel. I've done this hundreds of times with success. The ability to do a `make buildkernel' with an empty /usr/obj is a new feature. But back to your misunderstanding. What part about "if the kernel source is changed to use language features not supported by the existing installed tools, you cannot build a kernel with them" do you not understand?? You obviously was not active when 4.x upgraded Binutils from 2.9.1 to 2.10.0 and the many of the asm bits were changed at the same time to remove work arounds and bogusness done to satisfy Binutils 2.9.1. > > Second, the install order above is not the conservative, careful > > approach. One should issue "make installkernel && reboot" after the > > "make buildkernel" to ensure the new kernel works > > sufficiently well. > > Maybe that's _YOUR_ method for installing but it's not necessarily the best > one. Kernel's are not guaranteed to be backwards compatible and I've > installed a shiny new kernel that worked just fine and allowed my machine to > come up single user but because of some rude change in /etc/rc, ipfw, or any > of a number of places the machine couldn't make it to multi-user and allow > me to get back in (via the network). That you're doing this remotely is your problem. Ask any of the developers living on -CURRENT where often one wants to back out of a newly compiled world. The method I gave is the most sure and careful way. That you don't have consoles on your machines so you could do this properly doesn't mean what I posted isn't the safest and should be followed unless has special needs. > Success at building and installing the kernel, world, AND running > mergemaster gives me a reasonably good chance that when I issue the reboot, > it'll come up nice and happy. I'm happy for you. But you have major flaws in your method where problems can bite you hard. As I said, I want users to know and use the safest method. I've seen enough email from users that were all confused about the right steps -- often getting confused from posts such as yours where you [hopefully] understand the consequences of your method and can deal with them. Many do not want to or cannot. > Second, if I'm going through the bother of compiling a buildworld it's > because I want the latest version of world on my system. Want != ability. I want a latest version of 5-CURRENT on my laptop, but CardBus is broken right now, so I am living with a Dec world. Such is life. > If there are some problems with the new kernel, I'm not going to revert > back to world.old. I'll fix whatever is screwed up with kernel and > proceed. Oh! Want a job as a kernel hacker then? I'd like to have my CardBus working again (in current). Also my AHA-2930u2 on a K6-2 machine... -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: tuning a VERY heavily (30.0) loaded s cerver
hello there! On Thu, 22 Mar 2001, Michael C . Wu wrote: >(Why is vfs.vmiodirenable=1 not enabled by default?) By the way, is there any all-in-one-place description of sysctl tuneables? Looking all the man pages and collecting notices about MIB variables seems rather tiresome and, I think, pointless. I doubt if they are all documented in man pages. # Alexey To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: tuning a VERY heavily (30.0) loaded s cerver
:(Why is vfs.vmiodirenable=1 not enabled by default?) : The only reason it isn't enabled by default is some unresolved filesystem corruption that occurs very rarely (with or without it) that Kirk and I are still trying to nail down. I want to get that figured out first. It is true that some people have brought up memory use issues, but I don't consider memory use to really be that much of an issue. This is a cache, after all, so the blocks can be reused at just about any time. And directory blocks do not get cached well at all with vmiodirenable turned off. So the net result should be an increase in performance even on low-memory boxes. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
The "right" way to build a new world WAS: 4.3-BETA worldcrashin g 4.2-RELEASE kernel ?
OK, let's approach this from a little different angle: Below is the appropriate entries from /usr/src/UPDATING on a FreeBSD 4-stable machine. As of 2/2/2001, the most correct and safest method for updating your FreeBSD machine is as follows: cd /usr/src make buildworld make kernel KERNCONF= reboot (single user) make installworld mergemaster reboot I have found that there IS a variety of reasons NOT to do it that way. The most obvious is that you might not have console access, thus making it pretty hard to access the machine while it's in single user mode. I can also think of a couple instances where this method could cause pain. The first is changing of any of the files used at boot time. I don't allow telnet access to any of my machines so SSH is often as close as I can get to console. If anything changes enough that we don't cleanly make it through rc and friends, processing stops, sshd won't be running and I can't get in. The one time this happened the machine didn't make it multi user. Fortunately that machine was in my basement so I walked down, looked at the errors on the console and finished the upgrade. IPFW changes. This one isn't quite obvious but if you don't compile your kernel with IPFW_DEFAULT_TO_ACCEPT and changes are made to the kernel or userland portions and not the other (as will happen in the above scenario) then upon reboot, if your ruleset doesn't get applied, you won't be able to access your machine via the network. Ouch. I always compile in the DEFAULT_TO_ACCEPT for this reason and then add a default deny rule to the IFPW ruleset. Even so, I find it's best to get my kernel, world, and config files synced before rebooting. Changes like that aren't terribly infrequent and if you aren't paying attention, can bite you. This (and a few other things) have prompted me to completely skip the first reboot. Also, I tend to keep everything I use in a location (/usr/local) other than the default places installworld wants to be touching. So, I can almost always get away with doing an installworld without changing my runlevel. The last thing, which is seldom mentioned but which I habitually do is another make installkernel after the system comes back up and is happy. The reason(s) should be obvious. So, my procedure looks a lot like this: cd /usr/src make buildworld make kernel KERNCONF= make installworld mergemaster reboot cd /usr/src make installkernel KERNEL= One can also often get away with making a new kernel without first building world but do so at your own peril (as I often do). :-) I often issue the buildkernel and buildworld at the same time and then leave for the day. My reasons for doing this are: laziness, impatience, and wanting to have the entire compilation done when I return. Doing so can be risky but in my experience, works just fine with the -stable tree. Others have been quick to point out the possible hazards of doing so but they mostly apply when playing with -current. Matt >From /usr/src/UPDATING (on FreeBSD 4-STABLE): COMMON ITEMS: To build a kernel - cd /usr/src # If you have not already done so, please buildworld here # You will also need to update your config file to 4.x. Usually # people tend to start with GENERIC from 4.x and hack from there. make buildkernel KERNCONF= make installkernel KERNCONF= # Verify that the new kernel works, it will be installed as # /kernel To rebuild disk /dev entries MAKEDEV should be copied from src/etc/MAKEDEV to /dev before starting the following: For N in the list of disks MAKEDEV N # eg ad0 for M in the list of slices MAKEDEV NsMa# eg ad0s1a To rebuild everything - make world Except when it doesn't work :-) To update from 4.0-RELEASE or later to the most current 4.x-STABLE -- make buildworld make buildkernel KERNCONF=YOUR_KERNEL_HERE make installkernel KERNCONF=YOUR_KERNEL_HERE reboot (in single user) [1] make installworld mergemaster reboot [1] You can often get away without doing this step as the system will be properly updated. During the running of the installworld, however, system components may break and other oddities may happen. Don't do this on systems that aren't otherwise quiet as unpredictable results may happen. If in doubt, reboot into single user. For remote installs, keep a separate kernel around and use a serial console if at all possible. > -Original Message- > From: David O'Brien [mailto:[EMAIL PROTECTED]] > Sent: Thursday, March 22, 2001 12:
Re: Intel driver doc's Take 2.
Jonathan Lemon wrote: > > In article >[EMAIL PROTECTED]> > you write: > > She need's specific information that we need that we cant get > >unless we sign NDA's for the doc's so she can try and get them merged into > >a reference product somewhere between the datasheet (worthless) and the > >programming manual (NDA). > > Well, I applaud your effort, but I can't really think of how this > would work. The information in the programming manual is required > to program the chip. It is already a fairly concise manual, and if > you axe anything out of it, it would mean that feature wouldn't be > supported. How about meeting half-way in a different way ? Suppose they provide the manual with NDA but in the NDA agreement they state that the source code of the driver developed using this manual may be published. To reiterate, the manual itself would still be their trade secret but the results of development done based on this manual would be free. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: The "right" way to build a new world WAS: 4.3-BETA world cra
On 23-Mar-01 Matt Simerson wrote: > OK, let's approach this from a little different angle: > > Below is the appropriate entries from /usr/src/UPDATING on a FreeBSD > 4-stable machine. As of 2/2/2001, the most correct and safest method for > updating your FreeBSD machine is as follows: > >cd /usr/src >make buildworld >make kernel KERNCONF= >reboot (single user) >make installworld >mergemaster >reboot > > I have found that there IS a variety of reasons NOT to do it that way. The > most obvious is that you might not have console access, thus making it > pretty hard to access the machine while it's in single user mode. I can also > think of a couple instances where this method could cause pain. All of the ones you list below are not a problem if one has a serial console (single user implies console access). :) It _is_ the safest and most correct way, but it's not always convenient and/or feasible. And while you can deviate from it, you should only do so once you are comfortable with the process and know how to get yourself out of a jam if it blows up in your face. New users don't have all this background yet, so following the directions above is the best thing for them to do. Make sense? -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SCSI-over-* hacks
In article, 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