Installing -current
Hi, What is the easiest way to install FreeBSD-current? Do I have to install a 3.x release and then cvsup to the -current followed by a make world? Before I ran into trouble I want to ask if 4.0 supports the 3CCFE574BT NIC? (3com 3c574). Right now I'm running this NIC with FreeBSD3.3+PAO on a Thinkpad570 and it works great. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Mailing list search engine at www.freebsd.org down for repair.
Hi all, Our primary mail server, using the special type of evil ESP abilities which all critical hardware items possess, took advantage of everyone (including our postmaster) being away at LinuxWorld in New York to exhibit the "F" in "MTBF" with respect to hard drive specifications. We have mail services running again on a backup system but it will take a little while longer until all other mail-related services (like web search) are restored. We apologize for the inconvenience and hope to have this problem fixed shortly. A situation almost exactly like this (disk hardware failure) occurred with freefall during FreeBSDCon '99, incidently, and with this second incident we've certainly gotten the message: All critical freebsd.org assets will use (hardware) RAID arrays for storage in the future and we'll begin implementing that just as soon as we return. Regards, - Jordan
open ref counts in CAM and vn
A collegue fo mine had the problem that it was possible to vnconfig -u a vn device that was currently in use. This strikes me as odd. When looking through the da device code, I notice a similar problem. Suppose I have a zip fdisk mounted with a disklabel and 2 ufs partitions on it. When I mount both partitions, the disk will be locked. But it will be unlocked at the first unmount. I guess there should be a refcounter that keeps track of the amount of opens and only unlock devices at the last close. Same for vn.c. Any comments? -Guido To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to catch a wildrunning pointer
Alfred Perlstein [EMAIL PROTECTED] on 28.01.2000 11:49:34
To: Thomas Klein/Aachen/Utimaco/DE@utimaco
cc: [EMAIL PROTECTED]
Subject: Re: how to catch a wildrunning pointer
Hi
My Problem:
Within a kernel timeout routine I allocate memory and fill it with data.
After a while I lock at this data again and realize that it it was modifyted
(but not by me).
How can I set a kernel mode watch point to that data to see which function
change the data.
Any Ideas
Look at the vm code, you can probably write protect the pages while
you aren't accessing them, this will cause offending code to panic
the machine so you can figure out who is twiddling your bits.
Of course you'll have to unprotect the memory when you want to access
it for legitimate reasons.
You owe the oracle a how-to on acually doing this, a paragraph or two
would suffice.
thanks,
-Or^H^HAlfred
If I understand this correctly I have to use the pmap_protect function.
For testing I integrate the following sequence within a device driver
attach routine.
{
int i;
char * t_ptr;
t_ptr = (char*) malloc(1027,M_DEVBUF,M_NOWAIT);
for(i=0;i1027,i++)
*t_ptr = 'x';
pmap_protect(kmem_map,t_ptr,t_prt + 1027,VM_PROT_READ);
*t_ptr = 'A';
printf("I can see this\n");
}
No exception ocured.
What is wrong?
Wy dosn't it work?
Regards Thomas
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Removing interfaces
if_kue, if_aue or ask Doug Ambrisko for a copy of the udbp (USB double bulk pipe) driver that should have that as well. Nick On Wed, 2 Feb 2000, Archie Cobbs wrote: With all the PCMCIA card stuff going on, is it now possible to remove a networking interface in FreeBSD (from within the kernel)? If so could someone show me an example how. I'd like to implement this in the ng_iface(8) netgraph node type. Thanks, -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: porting linux app. Syscalls
what confuses me is that you don't support bootstrapping from the system C compiler. How do you propose to do that with an all pascal source? Marco van de Voort ([EMAIL PROTECTED]) http://www.stack.nl/~marcov/xtdlib.htm To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: porting linux app. Syscalls
see: http://www.freebsd.org/cgi/man.cgi you can view linux syscalls from the slackware docs. Thank you that seems to be a good lead to start with. The problem was that I couldn't find any documentation :_) Marco van de Voort ([EMAIL PROTECTED]) http://www.stack.nl/~marcov/xtdlib.htm To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Re/Fwd: freebsd specific search
On Wed, Feb 02, 2000 at 09:59:08PM -0800, Alex Zepeda wrote: On Wed, 2 Feb 2000, Michael Bacarella wrote: Not to start a flame-fest or anything (but who doesn't love em?), I hear the above quite a lot. I'm under the firm belief that a decent sys admin can rub either system to do whatever they want it to do. Not that I am questioning your abilities. I just get the "yeah, Linux is good, but just try to use it in a production environment and you'll understand" a lot. Needless to say I think that FreeBSD makes a great desktop environment too. What contributes to server sanity also makes things much less confusing for a desktop user too :) True; but linux has support for a bigger variety of soundcards (my Win98^H^H^H^H^H^HEverQuest machine now has a Live! in it; supported under Linux but not under FreeBSD AFAIK; so the other half of the disk may turn turn into ext2 rather than ffs) The other 2 boxes will, of course, stay FreeBSD. I generally get the feeling that `Workstation Hardware'[1] has a better chance of being supported under Linux than FreeBSD. I may be talking rubbish, though ;-) [1] SoundCards; funky USB magic to talk to your digital camera; that kind of thing. -- Mike Bristow, Geek At Large ``Beware of Invisible Cows'' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: open ref counts in CAM and vn
On Thu, Feb 03, 2000 at 10:26:15AM +0100, Guido van Rooij wrote: A collegue fo mine had the problem that it was possible to vnconfig -u a vn device that was currently in use. This strikes me as odd. When trying to add some refcounting in sys/dev/vn.c, I wanted to switch to using the kernel module for vn, which brought another problem forward, tried to send-pr it, but unfortunately that doesn't work with hub being replaced temporarily.Anyway: on a current machine: dd if=/dev/zero of=/tmp/vntest bs=1024 count=1440 kldload vn vnconfig -c vn0 /tmp/vntest vnconfig -u vn0 kldunload -i SOMENUMBER (found with kldstat) kldload vn vnconfig -c vn0 /tmp/vntest crash, kernelpanic,kabang, kaputt :-( We tried to trace this back somewhere but failed. Mark -- Nice testing in little China... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: porting linux app. Syscalls
In article [EMAIL PROTECTED], Chuck Robey [EMAIL PROTECTED] wrote: The modula-3 port is about the same size as yours, and it bootstraps, but (like you said) it does it from C. Actually, the standard Modula-3 bootstraps contain assembly-language sources generated by a cross-compiler, not C. 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: Removing interfaces
Nick Hibma writes: | | if_kue, if_aue or ask Doug Ambrisko for a copy of the udbp (USB double | bulk pipe) driver that should have that as well. The udbp doesn't do it since it just creates a netgraph node. Then you tie that netgraph node to an interface. At that point netgraph makes an interface called ngX. When you remove the USB widget then a new netgraph node is created (the old one destroyed) and then you connect this netgraph node to an interface which is ng(X+1)). This is what Archie is trying to avoid. So no udbp is not a example until Archie fixes netgraph. However, he could look at if_kue, if_aue, or the various pccard ethernet adapters in -current since they all seem to work. Archie you should upgrade your laptop to -current. Then you could go wireless with it and see the anX interface come an go. Also you could play with USB ethernet widgets and USB modem floating around here (BTW Nick it almost works with your umodem.c driver on your web page. The only problem I see is that it doesn't see loss of CD). Doug A. | On Wed, 2 Feb 2000, Archie Cobbs wrote: | | With all the PCMCIA card stuff going on, is it now possible to | remove a networking interface in FreeBSD (from within the kernel)? | | If so could someone show me an example how. I'd like to implement | this in the ng_iface(8) netgraph node type. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: open ref counts in CAM and vn
On Thu, Feb 03, 2000 at 10:26:15 +0100, Guido van Rooij wrote: A collegue fo mine had the problem that it was possible to vnconfig -u a vn device that was currently in use. This strikes me as odd. When looking through the da device code, I notice a similar problem. Suppose I have a zip fdisk mounted with a disklabel and 2 ufs partitions on it. When I mount both partitions, the disk will be locked. But it will be unlocked at the first unmount. I guess there should be a refcounter that keeps track of the amount of opens and only unlock devices at the last close. Same for vn.c. Any comments? The reference counting should be handled by PHK's disk layer (which sits above CAM), and the da driver's close routine should only get called on final close. I don't know about the vn device, though. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: porting linux app. Syscalls
Marco van de Voort wrote: what confuses me is that you don't support bootstrapping from the system C compiler. How do you propose to do that with an all pascal source? I probably don't need to tell you this, but there is ports/lang/p2c. I've never used p2c, so I can't make any claims about its quality. You might be able to use p2c to bootstrap you compiler. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Suggestions for Gigabit cards for -CURRENT
The FreeBSD driver (written by Matt Jacob) is based on the Linux driver, which Intel wrote, and he hasn't yet managed to get decent throughput through the cards. (Maybe Matt will comment.) They also only have 64K of memory on board, which is insufficient for a heavily loaded server, IMO. That's not memory- that's FIFO- there are two of them, I believe, one for receive, the other for xmit. You can devote 64k to ring descriptors for receive- that's 4096 descriptors- each able to manage a 2k buffer. And you can have two receive rings. You can have the same size for xmit. So, the receive performance bottleneck for this chip/board will be in how good your PCI implementation is at first followed by how low an amount of interrupt latency for reinstruct. If your PCI implementation can keep up with Gigabit speeds, you're fine. If not, I'm not sure that 512K or 1MB buffering buys you much. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Suggestions for Gigabit cards for -CURRENT
On Thu, Feb 03, 2000 at 10:50:32 -0800, Matthew Jacob wrote: The FreeBSD driver (written by Matt Jacob) is based on the Linux driver, which Intel wrote, and he hasn't yet managed to get decent throughput through the cards. (Maybe Matt will comment.) They also only have 64K of memory on board, which is insufficient for a heavily loaded server, IMO. That's not memory- that's FIFO- there are two of them, I believe, one for receive, the other for xmit. You can devote 64k to ring descriptors for receive- that's 4096 descriptors- each able to manage a 2k buffer. And you can have two receive rings. You can have the same size for xmit. So, the receive performance bottleneck for this chip/board will be in how good your PCI implementation is at first followed by how low an amount of interrupt latency for reinstruct. If your PCI implementation can keep up with Gigabit speeds, you're fine. If not, I'm not sure that 512K or 1MB buffering buys you much. I think the memory would come in handy on a heavily loaded system, since you would gain a little extra time in case you were a little late servicing interrupts. i.e. it would smooth out the bumps a little bit. If your PCI implementation won't keep up with gigabit speeds, you'll just go slower. :) Most newer systems (e.g. 440BX) shouldn't have any trouble doing a reasonable amount of speed over gigabit ethernet, though. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Suggestions for Gigabit cards for -CURRENT
I think the memory would come in handy on a heavily loaded system, since you would gain a little extra time in case you were a little late servicing interrupts. i.e. it would smooth out the bumps a little bit. Yes, but that's what having 8192 2KByte descriptors handy is for... (that's 16MB of buffering). If your PCI implementation won't keep up with gigabit speeds, you'll just go slower. :) Most newer systems (e.g. 440BX) shouldn't have any trouble doing a reasonable amount of speed over gigabit ethernet, though. Typically I don't see higher than 60 or 70MB/s real throughput on most systems. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Suggestions for Gigabit cards for -CURRENT
On Thu, Feb 03, 2000 at 11:23:45 -0800, Matthew Jacob wrote: I think the memory would come in handy on a heavily loaded system, since you would gain a little extra time in case you were a little late servicing interrupts. i.e. it would smooth out the bumps a little bit. Yes, but that's what having 8192 2KByte descriptors handy is for... (that's 16MB of buffering). Are those all in card memory, or in host memory? What happens when you've got some other traffic on the PCI bus, and the card gets a little behind in DMAing its data into host memory? They're in host memory, and that's why I said "performance is contingent on PCI bus implementation". I think that 64K of FIFO is adequate flow control for PCI traffic avoidance. If your PCI implementation won't keep up with gigabit speeds, you'll just go slower. :) Most newer systems (e.g. 440BX) shouldn't have any trouble doing a reasonable amount of speed over gigabit ethernet, though. Typically I don't see higher than 60 or 70MB/s real throughput on most systems. I've seen 100MB/sec on Pentium II 450's (440BX), and 90MB/sec on Pentium II 350's (440BX). Aw, it just means your employers buy you up to date systemsunlike po' lil' me... :-( To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Suggestions for Gigabit cards for -CURRENT
On Thu, Feb 03, 2000 at 11:23:45 -0800, Matthew Jacob wrote: I think the memory would come in handy on a heavily loaded system, since you would gain a little extra time in case you were a little late servicing interrupts. i.e. it would smooth out the bumps a little bit. Yes, but that's what having 8192 2KByte descriptors handy is for... (that's 16MB of buffering). Are those all in card memory, or in host memory? What happens when you've got some other traffic on the PCI bus, and the card gets a little behind in DMAing its data into host memory? If your PCI implementation won't keep up with gigabit speeds, you'll just go slower. :) Most newer systems (e.g. 440BX) shouldn't have any trouble doing a reasonable amount of speed over gigabit ethernet, though. Typically I don't see higher than 60 or 70MB/s real throughput on most systems. I've seen 100MB/sec on Pentium II 450's (440BX), and 90MB/sec on Pentium II 350's (440BX). Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
IPFW / IP Filter question
A quick question, is it possible to copy all traffic coming into a particular interface to a divert socket, while still having the traffic also running normally and taking normal routes etc. I would have thought you would use the tee option in ipfw for this, but its not implemented yet according to my man pages, so I was wondering if there was another way to do this, cause it makes traffic analysis a hell of a lot easier if I can do this rather than having to sniff it with bpf or something. Any help would be appreciated Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IPFW / IP Filter question
On Thu, Feb 03, 2000 at 11:28:49PM +0200, [EMAIL PROTECTED] wrote: A quick question, is it possible to copy all traffic coming into a particular interface to a divert socket, while still having the traffic also running normally and taking normal routes etc. I would have thought you would use the tee option in ipfw for this, but its not implemented yet according to my man pages, so I was wondering if there was another way to do this, cause it makes traffic analysis a hell of a lot easier if I can do this rather than having to sniff it with bpf or something. I can;t answer this for ipfw (though IIRC there does exist a tee option in -current for ipfw). With ipfilter you can dup al traffic to an alternate device, like a tunnel device. e.g: pass in on lo0 dup-to tun0 from localhost to localhost or: pass in on lo0 dup-to ed0:1.2.3.4 from localhost to localhost where 1.2.3.4 is a machine on the same lan as ed0. -Guido To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: porting linux app. Syscalls
The modula-3 port is about the same size as yours, and it bootstraps, but (like you said) it does it from C. Actually, the standard Modula-3 bootstraps contain assembly-language sources generated by a cross-compiler, not C. Actually that is the first plan too for fpc. This because the port of the required libraries and stubs probably will be ready earlier than the actual compiler support (adding of a target in the compiler source), specially because we want to redo the linux definitions to some unix-general and create linux and freebsd as special cases. Marco van de Voort ([EMAIL PROTECTED]) http://www.stack.nl/~marcov/xtdlib.htm To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IBM releases JFS for Linux.
Thomas David Rivers wrote: This came across the Linux/390 mailing list today, I thought it might be interesting for people: The URL there is incorrect - the correct one is: http://oss.software.ibm.com/developerworks/opensource/jfs This has been reported on daily.daemonnews.org. Read the comment I wrote; IBM has an "Open Source Survey" you should respond to as well. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IBM releases JFS for Linux.
Greg Lehey wrote: On Wednesday, 2 February 2000 at 22:18:02 -0500, Thomas David Rivers wrote: This came across the Linux/390 mailing list today, I thought it might be interesting for people: "IBM makes JFS technology available for Linux - Technology based on OS/2 Warp Journaled File System goes open source". See http://oss.software.ibm.com/developerworks/opensource/features/jfs_feature.html The URL there is incorrect - the correct one is: http://oss.software.ibm.com/developerworks/opensource/jfs Interesting. I'm downloading and will take a look. Our hero! ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IBM releases JFS for Linux.
On Thursday, 3 February 2000 at 19:24:07 -0700, Wes Peters wrote: Greg Lehey wrote: On Wednesday, 2 February 2000 at 22:18:02 -0500, Thomas David Rivers wrote: This came across the Linux/390 mailing list today, I thought it might be interesting for people: "IBM makes JFS technology available for Linux - Technology based on OS/2 Warp Journaled File System goes open source". See http://oss.software.ibm.com/developerworks/opensource/features/jfs_feature.html The URL there is incorrect - the correct one is: http://oss.software.ibm.com/developerworks/opensource/jfs Interesting. I'm downloading and will take a look. Our hero! ;^) Wait until I deliver. I've taken a look, and there's as good as no docco. It's an OS/2 version, which suggests to me that it would be more difficult to port than the original AIX version. I might get back to it again later on, but don't hold your breath. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IBM releases JFS for Linux.
Wait until I deliver. I've taken a look, and there's as good as no docco. It's an OS/2 version, which suggests to me that it would be more difficult to port than the original AIX version. I might get back to it again later on, but don't hold your breath. I was informed, at Veritas, that indeed this is the OS/2 vs. the AIX version, which really stumped me. JFS for AIX is really not bad. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Re/Fwd: freebsd specific search
Mike Bristow wrote: True; but linux has support for a bigger variety of soundcards (my Win98^H^H^H^H^H^HEverQuest machine now has a Live! in it; supported under Linux but not under FreeBSD AFAIK; so the other half of the disk may turn turn into ext2 rather than ffs) The other 2 boxes will, of course, stay FreeBSD. You'd switch operating systems for the sake of a sound card? That seems backwards to this correspondent. Just buy a reasonable sound card that works under your system of choice; they're less expensive than a system installation. I generally get the feeling that `Workstation Hardware'[1] has a better chance of being supported under Linux than FreeBSD. I may be talking rubbish, though ;-) [1] SoundCards; funky USB magic to talk to your digital camera; that kind of thing. USB? Linux? I don't think so. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Installing -current
Jonas Bülow [EMAIL PROTECTED] writes: Hi, Hej. What is the easiest way to install FreeBSD-current? Grab floopies and install over FTP from current.freebsd.org. And then run cvsup if you want to update to even more current code. Before I ran into trouble I want to ask if 4.0 supports the 3CCFE574BT NIC? (3com 3c574). It looks that way. I haven't had the occasion to try myself. /assar To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
mounting openbsd disks
I have a need to mount a disk that was partitioned and labeled on OpenBSD. I'm getting the following errors when I try: # disklabel ad2 disklabel: ioctl DIOCGDINFO: Invalid argument Any chance I can tweak something small and get access to these disks. Here's what fdisk has to say: Information from DOS bootblock is: The data for partition 1 is: sysid 4,(Primary DOS with 16 bit FAT (= 32MB)) start 63, size 20480 (10 Meg), flag 80 (active) beg: cyl 0/ sector 1/ head 1; end: cyl 20/ sector 5/ head 6 The data for partition 2 is: sysid 166,(OpenBSD) start 20543, size 4198945 (2050 Meg), flag 0 beg: cyl 1023/ sector 63/ head 255; end: cyl 1023/ sector 63/ head 255 The data for partition 3 is: UNUSED The data for partition 4 is: UNUSED Of course I can mount slice 1, but have had no luck with slice 2. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Suggestions for Gigabit cards for -CURRENT
Of all the gin joints in all the towns in all the world, Kenneth D. Merry had to walk into mine and say: On Wed, Feb 02, 2000 at 13:03:09 -0500, Thomas Stromberg wrote: We're currently looking at upgrading several of our FreeBSD servers (dual PIII-600's, 66MHz PCI) and some Sun Ultra's to Gigabit Ethernet. We plan to hook these machines into our Cisco Catalyst 5000 server. They will most likely move to be running FreeBSD 4.x by the time that we actually get our budget approved. What experiences do you guys have with the cards? Currently we're looking at the ~$1000 range, specifically at Alteon 512k's ($1000) for the FreeBSD servers and Sun Gigabit 2.0's ($2000) for the Sun servers. I was interested in the Myrinet cards (for obvious reasons), but they appear to require a Myrinet switch (though I found myself slightly confused so I may be wrong) rather then being able to hook into our Catalyst 5000. The Intel PRO/1000 Gigabit cards look rather nice too, but I haven't seen drivers yet for FreeBSD (Linux yes). I'm pretty much purchasing on marketing and reputation rather then any experience here, so any help would be much appreciated. I would recommend getting Alteon boards. It is likely that the Sun boards are Alteon OEM, although I'm not positive. I think the first gigabit cards Sun had on the market were OEMed from Alteon, but I've been told that their newer cards are something else entirely. I don't know exactly what, but they're not Tigon-based. One thing to keep in mind is that both Netgear and 3Com are OEMing Alteon boards, and you'll get them much cheaper that way. The boards are pretty much identical to the Alteon branded boards (which have no identifying marks on them). The performance is the same, at least for the Netgear boards. (I don't have any 3Com boards.) There are a number of companies selling OEM'ed alteon boards for various prices. IBM sells two cards, one for PC-based hardware and one for RS/6000s which I think are basically the same hardware with different driver kits. Of course, the RS/6000 card is $2100 while the PC-based one is probably around $600 or so. My guess is they're Alteon cards with different PCI device IDs, but I can't confirm this as I don't have one. The SGI gigabit adapter, NEC gigabit adapter, DEC EtherWORKS/1000, 3Com 3c985 and 3c985B, and the Netgear GA620 are all Tigon boards (not to mention the Alteon ACEnic) and should all work fine with the ti driver. Oh, I found another one recently: Farallon also sells a gigabit PCI NIC for the Mac which is Tigon-based. The Netgear GA620 is a 512K Tigon 2 board, and generally goes for around $300 or so. The 3Com boards have 1MB of SRAM, but I'm not sure whether they're Tigon 1 or Tigon 2. You really want a Tigon 2 board. Maybe someone who has one can comment. The original 3Com 3c985 was a Tigon 1 board (I have one) and the 3c985B is a Tigon 2. The Tigon 1 is no longer in production, though of course I try to maintain support for it for those people who still have them. The Tigon 1 had only a single R4000 CPU in it while the Tigon 2 has two. The Netgear GA620 is by far the cheapest at about $320. The various OEM cards sold for the PC are usually around $600, give or take $100. The GA620 only has 512K of SRAM compared to 1MB on most of the others, however you're not likely to notice a problem with that unless you try to push the card really hard with a really big TCP window size and jumbo frames. The Intel cards may look nice, and there is a FreeBSD driver for them, but I wouldn't get one. The first problem with the Intel boards is that there are no docs for them. Supposedly they're using a Cisco chip, and the specs for the chip are top secret. This is why I don't buy or recommend Intel NICs. But that's just my personal bias. The FreeBSD driver (written by Matt Jacob) is based on the Linux driver, which Intel wrote, and he hasn't yet managed to get decent throughput through the cards. (Maybe Matt will comment.) They also only have 64K of memory on board, which is insufficient for a heavily loaded server, IMO. Even with the 512K Alteon boards, you have a minimum of about 200K, and probably more like 300K of cache for transmit and receive. The Alteon cards also need a certain amount of SRAM to run the firmware. The Intel boards also don't have the features necessary to really support zero copy TCP receive. The Alteon boards, on the other hand, have most of the features necessary, and if I get some time, I may add the last feature (header splitting) to the firmware. The other alternative is SysKonnect, and that might actually be a good alternative. I haven't seen the boards, don't know how much they cost, etc. etc. You might want to ask Bill Paul about them, he wrote the driver. The SysKonnect cards aren't bad. A single port multimode fiber card is around $700, I think. The single mode cards are more expensive. However
Re: Suggestions for Gigabit cards for -CURRENT
[ Thanks for the info Bill! ] On Thu, Feb 03, 2000 at 21:29:27 -0500, Bill Paul wrote: Of all the gin joints in all the towns in all the world, Kenneth D. Merry had to walk into mine and say: The Netgear GA620 is a 512K Tigon 2 board, and generally goes for around $300 or so. The 3Com boards have 1MB of SRAM, but I'm not sure whether they're Tigon 1 or Tigon 2. You really want a Tigon 2 board. Maybe someone who has one can comment. The original 3Com 3c985 was a Tigon 1 board (I have one) and the 3c985B is a Tigon 2. The Tigon 1 is no longer in production, though of course I try to maintain support for it for those people who still have them. The Tigon 1 had only a single R4000 CPU in it while the Tigon 2 has two. Ahh, that's good to know, I was wondering whether they had a Tigon 2 board out, since it would make a cheaper alternative to the 1MB ACEnic. The Netgear GA620 is by far the cheapest at about $320. The various OEM cards sold for the PC are usually around $600, give or take $100. The GA620 only has 512K of SRAM compared to 1MB on most of the others, however you're not likely to notice a problem with that unless you try to push the card really hard with a really big TCP window size and jumbo frames. That has been my experience as well. The FreeBSD driver (written by Matt Jacob) is based on the Linux driver, which Intel wrote, and he hasn't yet managed to get decent throughput through the cards. (Maybe Matt will comment.) They also only have 64K of memory on board, which is insufficient for a heavily loaded server, IMO. Even with the 512K Alteon boards, you have a minimum of about 200K, and probably more like 300K of cache for transmit and receive. The Alteon cards also need a certain amount of SRAM to run the firmware. Yep, thus the 200K-300K number. The minimum amount of buffer that the board will configure is 64K for transmit buffers and 128K for receive buffers. It looks at the size of the firmware and associated data structures, and allocates the rest of the card memory for transmit and receive buffer space. Both the Alteon and SysKonnect NICs are 64-bit PCI cards. (Actually, I'm pretty sure all of the PCI gigabit NICs are 64-bit.) Both kinds of cards can do jumbograms on FreeBSD. Also, both vendors have released pretty good hardware documentation, which makes them good choices for custom applications, if you're into that sort of thing. Alteon also provides firmware source, which can really come in handy. Do you know if SysKonnect has released firmware? Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Suggestions for Gigabit cards for -CURRENT
Of all the gin joints in all the towns in all the world, Kenneth D. Merry had to walk into mine and say: [ Thanks for the info Bill! ] No problemo. [...] Both the Alteon and SysKonnect NICs are 64-bit PCI cards. (Actually, I'm pretty sure all of the PCI gigabit NICs are 64-bit.) Both kinds of cards can do jumbograms on FreeBSD. Also, both vendors have released pretty good hardware documentation, which makes them good choices for custom applications, if you're into that sort of thing. Alteon also provides firmware source, which can really come in handy. Do you know if SysKonnect has released firmware? The SysKonnect GEnesis controller and the XaQti XMAC II chips are both static devices and do not require firmware. If you go to www.syskonnect.com and search their online knowledge base for the word "manual" you should be able to find the gigabit NIC programmer's manual. Similarly, XaQti has the full datasheet for the XMAC II at www.xaqti.com somewhere. (As I recall, you have to go through a brief registration procedure to get it, but once that's done you should be able to download it right away.) Talking of the XMAC II, there's one other thing I forgot to mention earlier. The FreeBSD sk driver does jumbo frames, but the SysKonnect drivers don't. At least, not yet. The XMAC II's receive FIFO is 8K. By default, the chip operates in 'store and forward' mode in order to perform error checking on received frames (it has to get the entire frame in the FIFO in order to do a CRC on it, I think). This is fine for normal frames, but if you want to handle jumbograms larger than 8192 bytes, you have to put the chip into 'streaming' mode, otherwise any frame larger than 8192 bytes will be truncated. To get 'streaming' mode to work, you have to disable all of the RX error checking. Also, the default TX FIFO threshold on the XMAC is very small (8 bytes, I think). The FreeBSD sk driver bumps this up a bit (to 512 bytes, if I remember correctly). This is to deal with the case where you have a dual port card and are pumping data through both XMAC chips at once: with the default FIFO threshold, I would often see TX FIFO underruns from one of the XMACs and performance on that port would get spotty. I think the total TX FIFO memory on the XMAC II is 2K. -Bill -- = -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: [EMAIL PROTECTED] | Center for Telecommunications Research Home: [EMAIL PROTECTED] | Columbia University, New York City = "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
bug in vn, a pnaic and how to debug modules (was Re: open ref counts in CAM and vn)
On Thu, Feb 03, 2000 at 10:05:22AM -0700, Kenneth D. Merry wrote: The reference counting should be handled by PHK's disk layer (which sits above CAM), and the da driver's close routine should only get called on final close. ok. I don't know about the vn device, though. That was the reason fro the posting. vnconfig -u goes directly to the vn device but that device has no track of open count. I don't see any code to notify the upper layer that the device is gove. That is wrong of course. In fact, one can vnconfig -u a device, while the device is used in a mount. The ufs layer doesn't even know that the device is gone and accessing the mount is still possible. Unmounting is not. So in this case, I guess vnconfig -u should fail. I think this is best achieved by using a ref counter in the vn device code. There is another bug in the vn code as well, which has tom do with modules. The following will panic on a page fault in vnsetcred (in the VOP_UNLOCK call): kldload vn vnconfig -c something vnconfig -u something kldunload vn kldload vn vnconfig -c something --- instant panic I have not been able to debug this further, because it seems (but I have to recheck to be sure), that add-symbol-file /modules/vn correct address does not allow one to look at variables delcared inside the vn module. Is there an easy way btw to determine address? I looked inside the debugger in the linker_files queue and then use the load address there, plus the start address of .text as found by objdump of the vn module. -Guido To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
