Re: poor ethernet performance?
Of all the gin joints in all the towns in all the world, crypt0genic had to walk into mine and say: > Hey all, > I have two freeBSD machines one 3.1 -STABLE and the other 3.2 -STABLE, 3.2-STABLE *FROM WHEN*. What date does it say when you run uname -a! > I was ftping a very large file from one machine to abother over are > lan, it began to get extremely slow and began to stall. I suspected two > much traffic on our hub (A Netgear 24port 10base-T) so i switched the > two machines onto a 8 port Compaq Nettelligent hub. Now there are only > these two machines on the hub and they are still stalling. I tried > ftping both ways but it was the same thing. You changed out the "hub" just because one FTP transfer didn't go as fast as you would have liked? Did you reset the interfaces (or reboot the machines) when you reconnected them? It sounds a lot to me like you have the duplex modes on the cards set wrong, or that the cards are autonegotiating wrong (which is not impossible -- some switches that have full duplex ports don't do NWAY correctly). The cards must agree with their link partners: if you have them plugged into full duplex ports, then they must also be set to full duplex. If the cards are plugged into half duplex ports, then they also have to be half duplex. Now you're going to ask me how to set the duplex mode on the interface because why read the instructions when you can just ask somebody "on the web" instead, right? Grrr. # ifconfig xl0 media 10baseT/UTP mediaopt full-duplex # ifconfig xl0 media 10baseT/UTP mediaopt half-duplex > By looking at the lights on the hob it seems that a burst of data > would come for 2 seconds and then it would be dead for 10. I have 3com > 3c905b FastEthernet cards in both machines, and up until now I have > never had these kind of problems. Er. I don't get it. You're implying that the bug fairy just visited you one night while you were asleep. This doesn't happen. If you're having trouble now and you weren't before, then you changed something. Stands to reason, doesn't it? -Bill -- = -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: wp...@ctr.columbia.edu | Center for Telecommunications Research Home: wp...@skynet.ctr.columbia.edu | 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 majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Call for testers: Adaptec AIC-6915 fast ethernet driver
A driver for FreeBSD 3.x and 4.0-current is now available for testing for fast ethernet adapters based on the Adaptec AIC-6915 "Starfire" ethernet controller. This includes the following Adaptec "Duralink" models: - ANA-62011 single port 64-bit adapter - ANA-62022 dual port 64-bit adapter - ANA-62044 quad port 64-bit adapter - ANA-69011 single port 32-bit adapter - ANA-62020 single port 100baseFX These are Adaptec's replacements for its older DEC 21x4x-based multiport line of adapters. All cards support 10/100 speeds in full or half duplex. The multiport cards consist of multiple AIC-6915 chips linkec via a PCI to PCI bridge. Currently I have only tested the ANA-62022 dual port card, however all of them should work equally well. The 64-bit cards will work in a 32-bit slot on most newer machines. The Starfire supports a great many features including a 16-entry perfect RX filter, a 512-bit multicast hash table filter, a 512-bit high priority hash table, VLAN filtering, multiple RX and TX queues, and several different descriptor formats. There is also a programmable frame processor, however I haven't figured out how to use it. The FreeBSD driver uses a frame-based transmit descriptor (up to 14 packet fragments in one descriptor) and the producer/consumer queueing model with TX and RX completion descriptor queues. The perfect filter and hash filter are used for hardware multicast filtering. Support for BPF mode and promiscuous mode is also provided. The Starfire also supports TCP/IP checksum offload, however this is not yet implemented in this driver. The receive ring is programmed to have 256 descriptors. The transmit ring uses 128. This should be plenty for most server-based applications. Unfortunately, in spite of all the features in the Starfire, the chip requires receive buffers to be longword aligned, which means that received packets have to be copied in order to achieve proper payload alignemnt (which is handy on the x86 and required on the alpha). You'd think if they could go to the trouble of designing in special descriptor formats for MS-DOS and OS/2, they could handle DMAing to unaligned addresses. Oh well. This driver should work on both FreeBSD/i386 and FreeBSD/alpha. To add the driver to an existing FreeBSD 3.x system, do the following: - Download if_sf.c and if_sfreg.h from http://www.freebsd.org/~wpaul/Adaptec/3.0 and put them in /sys/pci. - Edit /sys/conf/files and add a line that says: pci/if_sf.c optional sf device-driver - Edit your kernel config file (e.g. /sys/i386/conf) and add a line that says: device sf0 - Config and compile a new kernel and boot it. To add the driver to an existing FreeBSD 4.0-current system, do one the following: - Download if_sf.c and if_sfreg.h from http://www.freebsd.org/~wpaul/Adaptec/4.0 and put them in /sys/pci. - Edit /sys/conf/files and add a line that says: pci/if_sf.c optional sf - Edit your kernel config file (e.g. /sys/i386/conf) and add a line that says: device sf0 - Config and compile a new kernel and boot it. Alternatively, if you have FreeBSD 4.0-current running on the x86 platform and don't want to recompile your kernel, you can try the following: - Download sf.ko from http://www.freebsd.org/~wpaul/Adaptec/4.0 and put it in /modules. - Edit /boot/defaults/loader.conf and add a line to the device driver modules section that says: sf_load="YES" # Adaptec PCI ethernet - Reboot The sf.ko module is compiled without BPF support. A Makefile is provided in the 4.0 directory which should allow you to recompile the module on both the x86 and alpha platforms. As usual, if you have any problems, please report them to wp...@skynet.ctr.columbia.edu. Remember to provide lots of detailed information. Vote early and vote often. The sooner people bang on this a little, the sooner it will go into the tree. No user-servicable parts inside. Offer void where prohibited by law. Operators are standing by. -Bill -- ===== -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: wp...@ctr.columbia.edu | Center for Telecommunications Research Home: wp...@skynet.ctr.columbia.edu | 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 majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: [FreeBSD-net-jp 1746] [FYI] Adaptec AIC-6915 "Starfire" ethernet controller driver and plus question compaq presario dec et
Of all the gin joints in all the towns in all the world, morita had to walk into mine and say: > $B?9ED$G$9!#(B > > > > These are Adaptec's replacements for its older DEC 21x4x-based multiport > > $B$3$N%I%i%$%P!<$OL5$/$J$k$N$G$7$g$&$+!)(B->DEC 21x4x-based > no more supllyed ->DEC 21x4x-based Sorry, but I'm just a dumb american: I can't read this. > > line of adapters. All cards support 10/100 speeds in full or half duplex. > > The multiport cards consist of multiple AIC-6915 chips linkec via a PCI > > to PCI bridge. Currently I have only tested the ANA-62022 dual port card, > > however all of them should work equally well. The 64-bit cards will work > > in a 32-bit slot on most newer machines. > > > > $B%3%s%Q%C%/!!(BPRESARIO$B!!(B2274$B!!$K(BFreeBSD3.2$B%$%s%9%H!<%k$7$?$N$G$9$,!"(B > NIC$B!'!!(BDEC 21143-based > $B$H%S%G%*%+!<%I!'(bsis5598$...@_dj$,$&$^$/$$$-$^$;$s!"8=:_(B > $BF0$+$7$F$k(B > $BJ}$,$$$i$7$?$i65$($F$/$...@$5$$!#(B I can't read this either. :( -Bill -- = -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: wp...@ctr.columbia.edu | Center for Telecommunications Research Home: wp...@skynet.ctr.columbia.edu | 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 majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Update on Adaptec AIC-6915 "starfire" driver
I haven't received any feedback yet on the Adaptec "Starfire" driver, however I made a few updates that people should know about: - I created a version of the driver for FreeBSD 2.2.x. You can find it at http://www.freebsd.org/~wpaul/Adaptec/2.2. Note: while I have verified that this code compiles, I have not been able to test it. There should not be any problems, but as always, Murphy's Law applies. - I found a bug today which is that sf_stats_update() required splimp() protection. I use the indirect register access method which is done in two stages: first you set the indirect address register to the register offset that you want to play with, then you access it via the indirect data register. However sf_stats_update() was interruptible which means that it was possible for the interrupt handler to run in between the first and second stages, which caused the stats updater to modify incorrect register locations. This bug would manifest itself in the form of watchdog timeouts and the 'collisions' counter sometimes reporting wildly incorrect values. I corrected this problem and updated the driver sources for each FreeBSD version (including 2.2.x) and recompiled the KLD module for FreeBSD 4.0-current. - The pre-compiled KLD module for FreeBSD 4.0-current now includes BPF support, since I have been told that there stubs that should allow BPF-enabled drivers to work even if BPF support isn't compiled into the kernel. - I added a README at http://www.freebsd.org/~wpaul/Adaptec which explains how to install the driver on FreeBSD 2.2.x, 3.x and 4.0. Also, a quick note about the Adaptec cards. I said previously that the Duralink adapters were Adaptec's replacement for their older DEC tulip-based cards. Adaptec still sells multiport adapters based on the 21x4x chip, however I believe they use the 21143 now since Intel discontinued production of the 21140 and supplies are drying up. It is possible that Adaptec may stop production on the older cards though now that they have their own high performance chipset. The Duralink cards may also be preferable in some cases since they are 64-bit PCI devices. Anyway: I would appreciate it if people could test the driver and get back to me with some feedback. I hope to merge this into the -current branch soon. -Bill -- ===== -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: wp...@ctr.columbia.edu | Center for Telecommunications Research Home: wp...@skynet.ctr.columbia.edu | 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 majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: How do you allocate dma channel with newbus?
Of all the gin joints in all the towns in all the world, Mike Smith had to walk into mine and say: > > > > I am feeling a little dense today, how do you allocate a > > dma channel for a PCI busmaster device with newbus? > > It's a bus master, so you don't. The logical conclusion is that Larry really does have a question, but he asked it badly. Since he asked it so badly that we really don't know what he meant, we should attempt to throw information at him in the hopes that we'll end up telling him what he wants. This is not as efficient as asking the question correctly the first time, but communication seems to be a lost art these days, so what can you do. First of all, with newbus, you now have pci_read_config() and pci_write_config() instead of pci_conf_read() and pci_conf_write(). The former accept a device_t and let you specify the register width (as opposed to forcing to you to use 32-bit accesses all the time). You may need to enable bus mastering and PIO/memory mapping mode in the PCI command register as before. Once you do that, you have to allocate the "resources" that you need. The first resource is the register access space. This can be either an I/O address in iospace or a memory base address. The second is the interrupt. You need to keep track of these resources in your softc structure. They are allocated with bus_alloc_resource(). For PCI devices, you used to use pci_map_port() or pci_map_mem(); now you use bus_alloc_resource() instead, which ultimately has the same effect. When you allocate the register space resource, you have to pass a pointer to a resource ID, which for PCI devices is the register to use. For the SYS_RES_IOPORT resource type, you specify the PCI iobase address register. For SYS_RES_MEMORY, you specify the the memory base address register. Once you have allocated the iospace resource, you can then use rman_get_bustag() and rman_get_bushandle() to get the bustag and bushandle that you can use with the bus_space_read()/bus_space_write() routines to read/write the device registers. The bustag and bushandle should be treated as opaque; they will let you read from iospace or memory mapped space depending on the resource type that you allocated. You also use bus_space_alloc() to allocate the interrupt resource using SYS_RES_IRQ (the resource ID is 0). To actually map the interrupt to a handler function, you need to use bus_setup_intr(). Resources can be released with bus_release_resource(), and the interrupt handler can be detached with bus_teardown_intr(). This allows you to unload drivers. For bus master DMA, you can still use vtophys() to map kernel virtual addresses to physical addresses as before. Ideally one should use the busdma routines for that, however I haven't figured out how to use them with network device drivers yet, and nobody has come forward with a nice simple example that shows how to do it (and no, I don't mean a NetBSD driver: I mean an example which will actually work in FreeBSD). The fxp, xl, sf, sk, ti and other drivers have been newbused and use bus master DMA; hopefully these should provide decent examples. -Bill -- ===== -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: wp...@ctr.columbia.edu | Center for Telecommunications Research Home: wp...@skynet.ctr.columbia.edu | 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 majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Gigabit ethernet support?
Of all the gin joints in all the towns in all the world, Charles Randall had to walk into mine and say: > Bill Paul has developed a driver for the Alteon Tigon 1 and 2 cards. > > http://www.freebsd.org/~wpaul/Alteon/ > > FYI, > Charles > > -Original Message- > From: David Miller [mailto:dmil...@search.sparks.net] > Sent: Wednesday, August 18, 1999 1:55 PM > To: freebsd-hackers@freebsd.org > Subject: Gigabit ethernet support? > > > Any supported cards in 3.2.x? The HCL pages don't list any:( The ti driver supports several cards, including the Alteon AceNIC, the 3Com 3c985-SX, the Netgear GA620, the DEC EtherWORKS 1000, the SGI PCI gigabit ethernet card, the NEC gigabit ethernet card and possibly some from IBM as well, though I don't know the PCI vendor/device IDs for those so I can't be sure (if you find them out, you can try hacking them into the driver). All of these are supported by the same driver because they're all OEMed from Alteon. Also, there is a driver for the SysKonnect gigabit ethernet cards (www.syskonnect.com). The driver sk was merged into the 3.x branch recently. SysKonnect has both single port and dual port cards with multimode and single mode fiber interfaces. All types are supported. -Bill -- ===== -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: wp...@ctr.columbia.edu | Center for Telecommunications Research Home: wp...@skynet.ctr.columbia.edu | 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 majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Gigabit ethernet support?
Of all the gin joints in all the towns in all the world, David Malone had to walk into mine and say: > On Wed, Aug 18, 1999 at 06:43:24PM -0400, Bill Paul wrote: > > Just out of curiosity, I thought I saw that you could get Intel > Etherexpress 1Gb/s cards. Do these exist and if so would they work > with the fxp driver as it is? > > David. The Intel gigabit ethernet cards are nothing like the EtherExpress fast ethernet adapters. Getting information out of Intel is like trying to squeeze blood from a stone. Either they want you to sign a non disclosure agreement that prevents you from releasing driver source (or makes it hard) or they won't give you any information at all. Sometimes they also play a different game where they release some information and pretend they're being 'open' but in reality the stuff they release is just fluff and you still have to sign an NDA to get your hands on the good stuff. As an aside, there are bound to be extra problems with the Intel gigabit NICs because, if I'm not mistaken, then use an on-board i960 processor to drive them. This means that in order to make the NIC work, you have to load firmware into it, and with firmware comes sticky licensing issues. The Alteon Tigon chipset also requires firmware (it has embedded MIPS R4000 CPUs) but Alteon actually released the firmware source code along with all the other Tigon development information. They even have a mailing list where you can send in questions regarding the firmware and get answers from a real live developer. Until such time as Intel gets its head out of its ass in this regard, I refuse to have anything to do with their networking products, especially when I have two other sources of perfectly good gigabit ethernet NICs available to me with full, unencumbered documentation. Initially this was not true of SysKonnect: they had a Linux driver for their cards but no programming info available. Much to my surprise, after a lengthy e-mail discussion, they actually agreed to release the manual for their GEnesis ASIC not just to me but to anybody without NDA on their web site. You would think that Intel would be prepared to make the same commitment to their customers, but so far as I know, they're still stuck in their proprietary ways. -Bill -- = -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: wp...@ctr.columbia.edu | Center for Telecommunications Research Home: wp...@skynet.ctr.columbia.edu | 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 majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Call for testers, new driver, blah blah blah...
This is a call for testers for a new device driver for yet another PCI fast ethernet controller: the Sundance Technologies ST201. This chipset is currently being used on the D-Link DFE-550TX. The chip on the D-Link is labeled DL10050, but it's actually an ST201. I don't know what other cards use this chip; D-Link contacted me about writing a driver and sent me two sample cards, and do far theirs is the only one that I know of. The driver is set up to recognize the stock Sundance PCI vendor/device ID as well as D-Link's. The Sundance ST201 is a clone of (wait for it) the 3Com 3c90x Etherlink XL series. No, really. Honest and for true. It uses the same DMA descriptor format and operation is very similar to the 3Com cards, although the actual register layout is different. The ST201 also has only a 64-bit multicast hash filtering table where the 3Com cards have a 256-bit table. Also, the ST201 supports only an MII transceiver interface and has no built in BNC/10baseT/AUI ports like the 3Coms. One thing that is a lot like the 3Coms is the fact that packet fragment buffers can be aligned on any byte boundaries, which means that there's no copying required to assure proper payload alignment on the alpha. Performance seems good so far though I haven't really torture tested it yet. Currently, there are drivers for 3.2+ and 4.0 available. You can download them from: http://www.freebsd.org/~wpaul/Sundance/3.0 http://www.freebsd.org/~wpaul/Sundance/4.0 Both versions support FreeBSD/i386 and FreeBSD/alpha and the 4.0 version uses newbus and can be compiled as a loadable module. There's no README yet, so here are some quick instructions: - Download the version of if_ste.c and if_stereg.h for your FreeBSD installation. - Copy if_ste.c and if_stereg.h to /sys/pci - Edit /sys/conf/files and add a line that says: pci/if_ste.coptional ste0 device-driver NOTE: for FreeBSD 4.0, leave out the "device-driver" part. It's no longer needed. - Edit your kernel config file, e.g. /sys/i386/conf/GENERIC and add a line that says: device ste0 - Config and compile a new kernel and boot it. Note that I chose the name "ste" so as not to get it confused with the SCSI tape device "st". I realize we use sa instead of st now, but I'll probably create a driver version for 2.2.x soon, and st is still used there. As usual, report problems or send large bags of cash to wp...@skynet.ctr.columbia.edu. I plan to merge this driver into the -current branch just as soon as I can whip up a man page for it. Share and enjoy! -Bill -- ===== -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: wp...@ctr.columbia.edu | Center for Telecommunications Research Home: wp...@skynet.ctr.columbia.edu | 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 majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Tulip device driver question
Of all the gin joints in all the towns in all the world, Jason Thorpe had to walk into mine and say: > On Fri, 03 Sep 1999 16:23:00 -0600 > Wes Peters wrote: > > > > > See, for instance, the al, ax, mx, pn, vr, and wb drivers. ;^) > > > ^^ > > > Especially this one.. it's not a Tulip clone :-) > > > > Oh? vr(4) disagrees: > > > > The VIA Rhine chips use bus master DMA and have a software interface > de- > > signed to resemble that of the DEC 21x4x "tulip" chips. > > I don't care what the manual page says; take a look at the respective > programming manuals for the chips. Hell, take a look at if_vrreg.h and > if_pnreg.h. The vast differences are *very* obvious. > > Really, the only thing that's even vaguely similar is that both of them > use chained descriptors which are 16 bytes long, with similar layout (but > not compatible bits within each longword). It sure looks to me like somebody was trying to duplicate the tulip descriptor layout though. No, it's not an exact copy, but there is a pretty close resemblance. > The registers are totally different. True. > ...tho, I guess he did say "resemble" ... The SiS 900 "resembles" a Tulip, > too (uses chained descriptors!), and the Tulip "resembles" the DEC SGEC > (a lot more than the Rhine "resembles" the Tulip, tho :-) The SiS 900 only has one combined status/control word in its descriptor structure (some of the bits mean different things depending on whether the descriptors are in the RX ring or TX ring) instead of a separate status and control word. The descriptors are also only 3 longwords in size. > The various Tulip clones are actually somewhat close to Tulips (e.g. same > registers, for the most part, same bits in the registers), and can be driven > by the same driver, with various special cases in them for the (usually > slight) > differences [this is the approach I'm taking in NetBSD; why Bill didn't write > a single driver for all the clones I'm not sure I'll ever know...] I thought about that. But after seeing just how many tulip workalikes there are and just how many differences and peculiarities there were, I decided that I just couldn't combine everything into one driver and keep it all working right without the code ending up looking really ugly. There are also more than just a few slight differences between chipsets. Some of them have the standard tulip receive filter mechanism (DMA the setup frame via the TX DMA engine). Some of them have just a couple of registers to program, but there are at least three different variations of this. At least one of them uses the DEC RX filter scheme but with only a 128 bit multicast hash table (the PNIC II -- damned if I know why they did that). The ones that use only the register programming method only have a 64 bit hash table. At least one of them has its registers spaced only 4 bytes apart instead of 8 (the Winbond). Some of them can have either an MII transceiver accessed via an MDIO bit-bang interface, or a serial transceiver. Some of them have built-in MII-like transceivers, but out of those, some of them use the bit-bang interface while others let you access the PHY registers directly. Some of them have built-in NWAY implemented without using an MII-like interface (PNIC, Macronix). Some of them have built-in NWAY designed to look like an MII interface (Macronix 98713) while the next revision up uses custom registers (Macronix 98713A). Some of them have built-in NWAY that doesn't work right (PNIC 82c168). Some of them use the standard DEC serial I/O interface to access the EEPROM. Some of them have custom registers (PNIC). Some of them have bugs that require some off the wall software workarounds (PNIC, Winbond, Davicom). Some of them obey the DEC SROM spec. Some don't. Many of them have additional custom registers for various purposes usually related to wake on lan. And that's just the PCI devices: who knows what other oddities will turn up once we have cardbus support. (And we will have cardbus support some day soon, right Warner? Hello? Warner? You okay? Hm. Somebody want to call an ambulance for Warner? Thank you. Breathe, Warner. _Breathe._ That's better.) Is it possible to cram all this stuff into one driver? Well, sure: the Linux tulip driver does it, although I can't say whether or not the Linux driver handles all of the supported cards correctly all of the time. Could you do it? Sure, why not. Could *I* do it? I don't think so, at least not in an elegant fashion. I can only handle one catastrophe at a time. -Bill -- ===
Re: Tulip device driver question
Of all the gin joints in all the towns in all the world, Jason Thorpe had to walk into mine and say: > [ snip ... all the quirks ] > > ...I'm well aware of all of these :-) > > Amusingly, these are the same kinds of quirks you have to deal with for > a unified *genuine DEC Tulip* driver. E.g. 21143s have internal NWAY and > MII; board manufacturer gets to choose which to use. Well, the older chipsets make it even harder on you: you have to know just the right way to twiddle the bits in the GPIO register in order to program the media settings, and to figure that out you're supposed to read the media description from the SROM, which is sometimes wrong. This opens up a whole other set of quirks. > In any case, I have a single driver for NetBSD that works with both the PNIC > and Winbond clones, and I'm working on support for the other clones. I'm assuming you actually have a Winbond card. If you do, try this for me: connect the Winbond to a link partner who's media settings you can easily control, like a managed switch port or another NIC via crossover cable. Set the Winbond and its link partner to 100Mbps half-duplex. Exchange a little traffic; a couple of pings should be enough. Then go to the link partner and change the media settings to 10Mbps half-duplex. Observe the Winbond closely. (Alternatively, start out with both devices set to 10Mbps half-duplex and then set the other end to 100Mbps half-duplex. I don't remember if both cases have the same result.) Initially I do traffic tests by plugging in the new device directly to another NIC with a driver that supports ifmedia using a crossover cable. This lets me test the card in all media settings. I noticed with the Winbond that if I changed the link partner's speed settings, it would start DMAing all kinds of crap into the host's memory. Furthermore, I think it ignores the RX buffer lengths specified in the receive descriptor ring and trashes various chunks of memory that it shouldn't, leading to a crash. Given that I never observed this behavior with any of the other tulip clones using similar code, I was pretty sure this was a chip bug and not some horrible coding error that I had made somewhere. I saw this with at least three separate Winbond cards and I tried my best to detect the condition and smack the chip upside the head to make it stop, but I'd be interested to see somebody else duplicate the problem and give me their take on it. Also, just out of curiosity, have you ever observed the PNIC receiver bug that gave me so many fits? > > And that's just the PCI devices: who knows what other oddities will > > turn up once we have cardbus support. (And we will have cardbus support > > some day soon, right Warner? Hello? Warner? You okay? Hm. Somebody want to > > call an ambulance for Warner? Thank you. Breathe, Warner. _Breathe._ > > That's better.) > > I think most of the Tulip-like CardBus boards use 21143s. Thankfully. > AFAIK, none of the current sets of clones are designed for CardBus > applications. There's at least one that has a cardbus version... darnit, which is is it. Oh: it's the ADMtek. There's an AL982 designed for PCMCIA and cardbus use. Unfortunately, the data sheet for it is not on ADMtek's server, but it's probably the same core as the AL981. In any case, I don't know of any boards that use the AL982. For that matter, I'm not even sure which boards use the AL981: the only cards I have are the samples that ADMtek sent me, and I haven't seen any board resellers claiming to use it. > BTW, you forgot EISA (DE-425) ... when I finish all the clone support > in my unified driver, I'm going to migrate support for the genuine DEC > chips, as well. If you can actually get it all to work and retain some portion of your sanity, I'll be mighty impressed. -Bill -- = -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: wp...@ctr.columbia.edu | Center for Telecommunications Research Home: wp...@skynet.ctr.columbia.edu | 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 majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Tulip device driver question
le. The LinkSys LNE100TX v2.0 card that I have and the sample 98715A card look almost identical. If you have a 98715A datasheet handy, you can use that as a reference when programming this chip; just remember about the smaller hash table. I'll stick a copy of my PNIC II datasheet at www.freebsd.org for you a little later -- I originally got my copy from LinkSys. As for ADMtek, I originally went looking at www.admtek.com.tw and just e-mailed one of the contacts that they list asking where I could buy a board in the U.S., since I already had the datasheet (the AL981 sheet is on their server). They turned out to be really eager to help me and sent me two cards directly. Again, I have to grope through my back e-mail to find the name of the guy I spoke too, but you can easily get in touch with them using the contact info on their site. Cnet makes a couple of cards using clone tulip chips: the Pro110 and 120 series. One of them uses the ASIX chip and the others use Macronix. I've been told you can sometimes find these at Fry's. Jaton Corporation makes a board called the Jaton XpressNet what uses the Davicom DM9102. This is another chip with a pretty cruddy DMA engine. -Bill -- = -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: wp...@ctr.columbia.edu | Center for Telecommunications Research Home: wp...@skynet.ctr.columbia.edu | 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 majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Tulip device driver question
for the Macronix, > > I would appreciate this... I haven't been able to find '168 boards at all. Okay, I just dug one out of my pile (it says Matrox on the back but it's identical to the LinkSys one). Give me an address where I should send it and I'll try to drop it in the mail sometime this week. > > ideally you need one each of the 98713, 98713A and 98715A. The 98713 > > I have a '15A board... I know of a NetBSD user who has a '13 board (he > sent in patches to make it work with the `de' driver initially). Unfortunately I only have one each of the Macronix cards. You can still find some of the 98713 and 98713A cards around though. > Doing the NWAY register stuff as a simulated PHY is a good idea... should > sort-of work for the PNIC, too, and would save duplicating all that logic > that MII code already implements. Depends a bit on how hard it is to fake up the pseudo registers. I'm pretty sure I can do it but I'm not looking forward to it. > > Also, the PNIC II (LC82c115) is actually a Macronix chip with wake > > on lan and only a 128-bit multicast hash table. The LinkSys LNE100TX v2.0 > > card that I have and the sample 98715A card look almost identical. > > ...I'll have to hunt down one of these cards. These are easy to find: the LNE100TX v2.0 is what LinkSys is currently shipping. They come in a blue and orange box, unlike the old one which was mostly white. Any place that was selling the older LNE100TX is probably selling the LNE100TX v2.0 now. You might also be able to hit up Greg Lapolla at LinkSys for a sample board. (I sent you his e-mail address in a separate mail.) > > If you have a 98715A datasheet handy, you can use that as a reference > > when programming this chip; just remember about the smaller hash table. > > I'll stick a copy of my PNIC II datasheet at www.freebsd.org for you > > a little later -- I originally got my copy from LinkSys. > > That's be great... Okay. It's at http://www.freebsd.org/~wpaul/Macronix/PNIC_II.PDF. Note that when you pull this up in a PDF viewer and examine the document properties, it will tell you the document name is "MX9815A." :) > > a board called the Jaton XpressNet what uses the Davicom DM9102. This > > is another chip with a pretty cruddy DMA engine. > > Davicom ... Winbond-like? No, the Davicom DM9102 is a pretty close copy of the tulip: it uses the setup frame mechanism for programming the RX filter. You can find the datasheet at http://www.davicom8.com. They also have a Linux driver up there somewhere (it's kind of gnarly, but then so are most Linux drivers). The DM9102 also has a built-in PHY so there's no ambiguity about the media. Don't confuse this with the DM9101 which is a PHY only. -Bill -- = -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: wp...@ctr.columbia.edu | Center for Telecommunications Research Home: wp...@skynet.ctr.columbia.edu | 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 majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Call for testers: Aironet wireless adapters
This is a call for testers for users with Aironet 4500 or 4800 series wireless adapters. A device driver for these NICs is now available. PCMCIA, PCI and ISA devices should all be supported. Note however that I personally only have access to the 4800 series cards so I may have missed some of the PCI and/or ISA Plug and Play IDs for the 4500 cards. The Aironet cards are 802.11 devices. The 4500 series cards have a maximum data rate of 2Mbps. The 4800 series have a maximum speed of 11Mbps, or so they claim. In my tests, I tend to see around 600KB/sec (kilobytes per second). This is in ad-hoc mode only; I don't know if infrastructure mode would be faster since I don't have an access point. Driver support is currently available for FreeBSD 3.2 and up. I plan to make a 4.0 driver once the plug and play code in -current settles down a little. The driver is available aT: http://www.freebsd.org/~wpaul/Aironet There is a README which explains how to add the driver to an existing system and configure a new kernel. Pay careful attention to the step marked *IMPORTANT* if you have a PCMCIA card: you must make a small change to /sys/pccard/pccard.c in order to get the PCMCIA card activated correctly (you have to apply +5 volts to the vpp1 and vpp2 pins, which FreeBSD doesn't do by default). The Aironet ISA and PCI cards appear to the host as ordinary ISA or PCI devices. This is a big improvement over the WaveLAN/IEEE ISA card which looks like a PCMCIA controller with a PCMCIA card inserted, and required pccard support even on a desktop system. The ISA card can be set for Plug and Play mode or hard-wired to a particular I/O address or IRQ; the driver supports both modes. If your system supports ISA Plug and Play devices, then it should "just work" without any tweaking. Sharp-eyed readers may notice a striking similarity between the Aironet driver code and the WaveLAN code. Strangely, they have very similar programming interfaces. I don't know why. Note that the Aironet supports multicast reception, but it has no multicast filter: the only possible option is 'receive all multicasts' mode. Also, promiscuous mode only seems to work when the NIC is in infrastructure mode, not in ad-hoc mode. Also, unlike the WaveLAN/IEEE cards, Aironet stations in ad-hoc mode must be on the same SSID in order to communicate. This can be done with the ancontrol utility (i.e. ancontrol -i an0 -n "MY_NETWORK"). As usual, report problems or send free large bags of cash to wp...@skynet.columbia.edu. Include lots of details. -Bill -- ===== -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: wp...@ctr.columbia.edu | Center for Telecommunications Research Home: wp...@skynet.ctr.columbia.edu | 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 majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: xl driver for 3Com
Of all the gin joints in all the towns in all the world, Dennis had to walk into mine and say: > Note that this card/driver seems to have serious problems under heavy load. > Just so you know. This is statement is nothing more than baseless slander, just so *you* know. I really hate it when: - People claim to be having earth-shattering difficulties and then fail to provide *any* useful debugging information. You don't even tell us what version of FreeBSD you're having trouble with, or what version of the driver. (Nevermind exactly what card or what kind of machine you have it plugged into.) For all we know, your "serious problems under heavy load" may be due to you dropping a safe on the computer. - People have problems, fail to report them, and then wonder why things don't get fixed. If you have a real, detailed and accurate bug report to submit, then fine: let's hear it. But if you just want to make vague and unsubstantiated complaints, do me a favor and just keep it to yourself. -Bill -- ===== -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: wp...@ctr.columbia.edu | Center for Telecommunications Research Home: wp...@skynet.ctr.columbia.edu | 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 majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: xl driver for 3Com
Of all the gin joints in all the towns in all the world, Dennis had to walk into mine and say: > I dunno what it is, but we've had customers experiencing packet loss at > high usage on 100Mb's nets...and the problem goes away when replacing them > with intels. I dont know the details. Then *FIND THEM OUT*! Replacing the cards does not fix the problem! How is anybody supposed to be able to help you if a) you never tell anybody about the trouble, b) you destroy the test configuration where the problem occurs, thereby assuring that nobody will be able to duplicate it again, and c) you don't even lift a finger to investigate! This is ridiculous! People ask me to fix stuff, they expect the world! You ask them what's going on, they don't know the details! That's just wonderful! You know, I should use that myself! "Hey Bill: my network crashed." "Well, there's probably something you could do to fix that but I don't know the details." Yes! I like it! Instead of trying to help people, I'll be maddeningly vague! I'll pretend to be helpful but stop short of actually providing any useful information! Then everyone else will go insane instead of me, society will collapse, and I can take over the world while everyone's distracted! You know if they ever find a way to harness sarcasm as an energy source, you people are all going to owe me big. -Bill -- = -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: wp...@ctr.columbia.edu | Center for Telecommunications Research Home: wp...@skynet.ctr.columbia.edu | 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 majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: xl driver for 3Com
Of all the gin joints in all the towns in all the world, Dennis had to walk into mine and say: > >Then *FIND THEM OUT*! Replacing the cards does not fix the problem! How > >is anybody supposed to be able to help you if a) you never tell anybody > >about the trouble, b) you destroy the test configuration where the problem > >occurs, thereby assuring that nobody will be able to duplicate it again, > >and c) you don't even lift a finger to investigate! > > I dont want help, That's too bad because you really need it! > I recommended Intel cards, the customer used 3coms > because "someone told them they were good cards", they had problems, and I > said "I told you so". Im just relaying the info..if I had REAL info as the > what the problem was I would have told you, but commercial sites are not > the place to be debugging problems. They are the *perfect* place to be debugging problems! Who do you think causes most of them!? And just what kind of information did you think you were relaying? Couldn't you be bothered to invest a few seconds to at least find out what version of FreeBSD they had? > I have no stake in 3com cards (they are > problematic in LINUX as well)...maybe the cards are flawed? Its not my > problem. It *is* your problem. Supposing you can't get Intel cards anymore. Then what're you going to do. > Not that I wouldnt like to help, but when I have a company president > calling me to complain that the box is going down Im in no position to say > "stick with the 3com cards, they'll have them running soon." Its the way > it is. No, that's not the way it is. You can't play musical hardware forever. Sooner or later you're going to run into a situation where you won't have another hardware option, and then your company president is going to find out just how useless you are and replace you. > You need to find beta test sights (gee, columbia might be a good > one, huh?) to do testing. Commercial sites are no place for such things. You just don't get it do you! In order to be able to fix a problem, you have to be able to duplicate it! I have tons of 3Coms here and they all work perfectly! If somebody has a problem with one, it's because they've put together a particular hardware and software configuration that triggers some pathological behavior. It's not fair then to expect somebody to be able to fix your problem if you don't make even the tiniest effort to explain what kind of configuration you have! Just who the hell are these famous customers of yours? Didn't it occur to you suggest that they file a bug report so that maybe their problem could be fixed and save them from having to buy new cards? This would not take a huge amount of time or effort! > I used to recommend DEC cards, and now the driver sucks, so I dont. I > recommend DEC or Intel in LINUX, because they work best. I dont care what > they use, and Im not concerned about the 35 drivers that have problems > under load. I cant be. I dont have time, and what's the difference? All > cards have the same functionality. The difference is that not everybody has access to all hardware! The difference is that not everybody can afford all hardware! The difference is that all cards don't get manufactured forever! The difference is that if you can't be bothered to get off you ass and actually report bugs properly and take some time to try testing a fix, pretty soon nobody will want to be bothered writing software for you anymore! > hey, you want to be famous, you gotta take some punches. When my drivers > have bugs, I take it on the chin. Part of the developer experience. :-) Don't you smiley at me! How would you feel if people just gradually stopped buying your products, and then one day you found out that it was was because of some silly little bug in your code that you could have fixed in fiv minutes if only somebody had cared enough to actually tell you about it? You'd be pretty pissed off, wouldn't you! More than that, your boss would be pretty pissed off too! So, tell me: just how many of you other people reading this have been having problems with 'drivers under load' and couldn't be bothered to actually report the problem? Hm? Well what're you waiting for?! Go on: speak up! Take two minutes of your precious time! I dare you! I double-dare you! No, I *triple*-dare you! Take your best shot! -Bill -- = -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: wp...@ctr.columbia.edu | Center for Telecommunications Research Home: wp...@skynet.ctr.columbia.edu | Columbia University, New York City
Re: xl driver for 3Com
Of all the gin joints in all the towns in all the world, Alexander Maret had to walk into mine and say: > Hi, > > > > If you have a real, detailed and accurate bug report to > > submit, then fine: > > let's hear it. But if you just want to make vague and unsubstantiated > > complaints, do me a favor and just keep it to yourself. > > I'm having serious problems with my 3COM Card too. The problem is > that there are many many collisions on the network. If i for > example transfer 30MB via samba from one computer to the other i get > about 900 collisions. I even get those collissions when only those > two computers are connected to one hub. If i transfer too many data > the NT machine crashes. If I transfer only a few bytes - say I'm > listening to an mp3 audio file which is on the server - then there > are no collissions. Frankly, 900 collisions for transfering a 30MB file isn't bad. Given that an ethernet frame can hold a maximum of 1500, that works out to around 20,000 packets. If you got 900 collisions out of 20,000 packets doesn't sound unreasonable. The reason you get collisions even if only those two machines are active is that they're only attached at half duplex. That means that if both machines transmit at the same time, they will trigger a collision. You don't have to have many hosts on a single ethernet segment in order to see collisions. For example, with a TCP transfer (which is what samba is doing), the server host will be sending enough packets to fill the TCP window (maybe 16K or so). The other side will then have to reply with an ACK for each segment that the server sends, It's possible that the ACK will be sent by the LoseNT host at the same time that the server is still sending data: that means there will almost certainly be collisions. If you had a full duplex switch, of if you had both machines wired back to back with a crossover cable and set both NICs to 100Mbps full-duplex mode, then you would never get any collisions at all (full duplex implies that both hosts can send simultaneously without ever colliding; in fact most chips disable collision detection when you program then for full duplex mode). How many collisions you see depends on a number of factors, including how fast the two machines are and how fast they can transmit data. If the receiving host is slow, then it will send ACKs slower, which will cause the sending host to throttle back a little (it can't send the next TCP segment until the previous ones are acknowledged). What you need to check is how fast the transfers are going. Observe the activity LEDs on the NICs and on the hubs while a transfer is in progress: if the LEDs keep flashing steadily throughout the whole transfer, then the NICs are working ok. If you see pauses during the transfer, where the LEDs stop flashing for a few seconds or more, then one of the NICs is getting stuck somewhere and having to reset itself. Run netstat -in on the FreeBSD host and look at the oerrors section of the output. If there are no output errors, then the NIC is probably working ok. Also, try and time the transfer: cound how many seconds it takes to transfer all 30MB of data. Ideally, you should be seeing several MBs per second. You can also try FTPing a file from the FreeBSD host to the LoseNT host; the FTP client should give you an approximation of the transfer rate. Bear in mind though that this will include the overhead of copying files to and from the disks. You can attempt to avoid this by FTPing the same file several times in succession (after you read it once, it should be cached on the server). Also, you can FTP the file to NUL: on the LoseNT host: this is equivalent to writing the file to /dev/null on UNIX and will not generate any disk activity. As for the LoseNT machine crashing, I can't really help you with that. You also didn't explain exactly what you meant by 'crash.' Does it just lock up completely (mouse doesn't move)? Does it 'panic' with a 'blue screen of death' (register dump)? Does the machine keep working but the networking stop (you can't ping it anymore)? -Bill -- = -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: wp...@ctr.columbia.edu | Center for Telecommunications Research Home: wp...@skynet.ctr.columbia.edu | 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 majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: xl driver for 3Com
Of all the gin joints in all the towns in all the world, Alexander Maret had to walk into mine and say: > Hmm, > > I'm no expert and this all sounds reasonable to me, but there are > things I haven't mentioned yet: Grrr. What were you waiting for. You should have mentioned them to start with. > When I boot linux on my FreeBSD server and I transfer the same > 30MB of Data via Samba, I only get 4 (!) collisions (HalfDuplex). Well maybe FreeBSD is transmitting packets much faster than Linux. :) You still haven't actually measured the transfer speed, so there's no way for us to know. > The collisions are measured with the 3COM NIC-Doctor. > I don't know if I can trust the output of NIC Doctor but > I'm (as a newbie) highly alerted by the difference of those two > values. Anyway - I will try what you told me and look at the > leds and at the netstat output. I also would like to know > how I can set up my FreeBSD system to support Full Duplex. Grrr. This tells me that you may not understand what full duplex really means. You're not allowed to fiddle with the full-duplex/half-duplex setting like it's some performance knob that you can crank up to "make things work better." If all you have is a hub, then the hub only supports half duplex. You can't set the machines to full duplex if the hub is only half duplex. You'll get rotten performance. On the other hand, if you have a *switch* -- which is *NOT* the same thing as a hub! -- and the switch ports support full duplex operation (which most do), *then* you can set the hosts for full duplex. Usually though, switches support NWAY autonegotiation, which means the NICs should autodetect the fact that the switch supports full duplex and the switch port and the NIC will both agree to use full duplex automatically. You can also use full duplex if you wire the machines back to back with a crossover cable. As to how you set the interface to full duplex, there are man pages to read which will tell you that. Naturally, being a newbie, you feel you have a god given right to ignore the man pages and go rummaging around with your web browser chewing up bandwidth instead of reading the instructions right under your nose. If you read the ifconfig(8) man page and the xl(4) man page, you would learn that the right way to do it is: # ifconfig xl0 media 100baseTX mediaopt full-duplex > Another interesting thing: If i switch the my NT client to > FullDuplex and FreeBSD is in HalfDuplex mode then my > FreeBSD server resets immidiately. Grrr. I'm sorry, but I really don't think you're putting the pieces together correctly. Setting the NT machine to full duplex should have absolutely no effect on the FreeBSD host. It will completely screw up performance since the LoseNT host will then no longer be set to match the hub, but that's another problem. I strongly suspect that you're not making the proper observations when your problem manifests and just leaping to the conclusion that setting the LoseNT host to full duplex crashes the FreeBSD host. I don't think that's true. If both machines are sitting idle (not transmitting any data) and you just suddenly set the LoseNT host to full duplex, the FreeBSD machine isn't going to just say "Hey! The LoseNT host changed modes! I better crash now!" There must be more to it than that, but you're not going into any detail. Remember when I said I wanted *detailed* problem reports? This is why. How do we know there isn't some really explicit panic message on the console that's screaming: "I crashed because of the following reason: ?" Maybe there's a message like that there, but we'll never know unless you tell us! So don't tell me "it resets immediately." Tell me *EXACTLY* what appears on the console (or if!) it crashes, word for word. Not your interpretation of what it says: *EXACTLY* what it says. And you still haven't explained what you meant about the LoseNT machine crashing before. -Bill -- = -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: wp...@ctr.columbia.edu | Center for Telecommunications Research Home: wp...@skynet.ctr.columbia.edu | 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 majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Using newbus to hang a custom bus off a device
h is not what I want. Is there some way to weight the drivers such that the specific ones will have a higher priority than the generic one, thereby forcing the specific probes to be called first? -Bill -- ===== -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: wp...@ctr.columbia.edu | Center for Telecommunications Research Home: wp...@skynet.ctr.columbia.edu | 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 majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: xl driver for 3Com
other, the the problem is with the first NT host. If the two NT hosts can still communicate, but neither of them can talk to the FreeBSD server then the problem is with the FreeBSD server. If you have tcpdump running on the FreeBSD server and you still see traffic coming from the NT hosts, then the problem is that the FreeBSD server is receiving but not transmitting. In this case, you should do ifconfig xl0 and see if the OACTIVE flag is set. If it is, it means the driver has used up all its DMA desciptors and the NIC hasn't acknowledged transmissions so it hasn't been able to free any of them. -Bill -- = -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: wp...@ctr.columbia.edu | Center for Telecommunications Research Home: wp...@skynet.ctr.columbia.edu | 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 majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Q: xl0: no memory for rx list -- packet dropped!
Of all the gin joints in all the towns in all the world, Anthony Bourov had to walk into mine and say: > Hi, > > I am running a FreeBSD server, and I am running into this problem very > often. The machine stops responding and instead outputs 1000s of > xl0: no memory for rx list -- packet dropped! > xl0: no memory for rx list -- packet dropped! > xl0: no memory for rx list -- packet dropped! > xl0: no memory for rx list -- packet dropped! > messages. The machine is usually pulling about 4-5 megabits but there is > usually a traffic spike right before this happens so an attack is not out > of the question, but I was wondering if there was any way I can raise the > threshold for this (would more BUFFERs do the trick?). You don't say what version of FreeBSD this is, or what driver version you have. Sorry, but my mind reading helmet is in the shop this week. If you're running something older than 3.2-RELEASE, try the latest driver from http://www.freebsd.org/~wpaul/3Com. The newer version has a larger RX and TX ring sizes. If you are running 3.2-RELEASE or later or changing the ring sizes doesn't help, then try compiling a new kernel with a larger value for NMBCLUSTERS, i.e.: options "NMBCLUSTERS=2" Actually, for newer versions of FreeBSD, you may have to do: options NMBCLUSTERS="2" If config(8) complains about the first syntax, try the second. This will greatly increase the size of the mbuf cluster pool, which should at least hold off the starvation condition for a while longer. You might want to check the traffic on the line with tcpdump. I would look for lots of ICMP or UDP traffic, or maybe lots of TCP segments directed at ports where there's nothing listening. Note: each mbuf cluster is 2K in size. 2 * 2048 == 40MB of RAM, so you better have a lot of memory in this server. If not, try something smaller. -Bill -- ===== -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: wp...@ctr.columbia.edu | Center for Telecommunications Research Home: wp...@skynet.ctr.columbia.edu | 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 majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Call for testers: SysKonnect gigabit ethernet driver
This is a call for testers for yet another gigabit ethernet driver. If you happen to have a SysKonnect gigabit ethernet server adapter and want to use it with FreeBSD, then please try the driver code at: http://www.freebsd.org/~wpaul/SysKonnect Currently I only have a driver for FreeBSD 3.0 and up. The following cards are supported: - SK-9841 1000baseLX, single port, single mode fiber - SK-9842 1000baseSX, single port, multimode fiber - SK-9843 1000baseLX, dual port, single mode fiber - SK-9844 1000baseSX, dual port, multimode fiber Yes, that's right: dual port gigabit ethernet. :) SysKonnect's driver software currently only uses the dual port adapters in a failover configuration, where the second port is monitored by the driver and only activated if the link on the primary port fails. This driver doesn't use that approach: instead, both ports are treated as separate and independent logical network interfaces. This means you should see something like the the following: skc0: rev 0x10 int a irq 11 on pci0.14.0 skc0: SysKonnect SK-NET Gigabit Ethernet Adapter SK-9844 SX dual link sk0: at skc0 port 0 sk0: Ethernet address: 00:00:5a:98:21:6c sk1: at skc0 port 1 sk1: Ethernet address: 00:00:5a:98:21:6d Yes, you can have both interfaces up and running at once. The SysKonnect cards use the XaQti XMAC II gigabit ethernet MAC and a controller designed by SysKonnect called the GEnesis. It is the GEnesis controller that provides all the PCI logic, plus other functions. The GEnesis controller can have up to two XMACs connected; single port cards have only one, of course. Information about the cards, including programming manuals for the GEnesis controller, can be found at http://www.syskonnect.com. The datasheet for the XaQti XMAC II can be found at http://www.xaqti.com. The sk driver supports hardware multicast filtering, BPF, promiscuous mode and jumbo frames up to 9000 bytes. It should also work on both FreeBSD/i386 and FreeBSD/alpha. To add the driver to an existing system: - Download if_sk.c, if_skreg.h, xmaciireg.h and if_media.h from http://www.freebsd.org/~wpaul/SysKonnect/3.0. - Copy if_sk.c, if_skreg.h and xmaciireg.h to /sys/pci - If you have a version of FreeBSD older than 3.2-RELEASE, copy if_media.h to /sys/net and /usr/include/net. You may also want to recompile ifconfig at this point, though it's not mandatory. - Edit /sys/conf/files and add a line that says: pci/if_sk.c optional sk device-driver - Edit your kernel config file (e.g. /sys/i386/conf/GENERIC) and add a line that says: device sk0 - Compile a new kernel and boot it. NOTE: make sure to recompile if_media.c now that the new if_media.h is in place. If you have problems, please send them to wp...@skynet.ctr.columbia.edu. Include lots of details. -Bill -- ===== -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: wp...@ctr.columbia.edu | Center for Telecommunications Research Home: wp...@skynet.ctr.columbia.edu | 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 majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
PCCARD and Vpp voltage
Today I started experimenting with the Aironet 4800 series 11Mbps wireless networking cards. Aironet makes PCMCIA, ISA and PCI adapters. I happen to have the PCMCIA and ISA ones. Like the Lucent WaveLAN/IEEE cards, the ISA and PCI cards are really PCMCIA cards fitted into a bridge adapter. Unlike the WaveLAN/IEEE cards, the bridge adapters look like real ISA or PCI devices to the host, so you don't need PCCARD support to use them. (The Lucent WaveLAN/IEEE ISA card requires PCCARD support in order to work.) Anyway, that's not why I'm here. My problem is the PCMCIA adapter. I'm testing it on a Dell Latitude Cpi D300XT, which has both LoseNT 4.0 and FreeBSD 3.2 installed. I decided to install the PCMCIA card in the laptop using the LoseNT drivers so that I could have a known working machine with which to generate traffic so that I could properly test the ISA card. However much to my surprise (well, not really), LoseNT failed to detect the card. The 'PC Card (PCMCIA)' icon in the control shows the PCMCIA modem in slot 1, but shows slot 0 as empty. Naturally, the drivers from Aironet fail to attach the card. So I decided to boot FreeBSD instead. Unfortunately, it didn't detect the card either. After reading the Aironet manual (which I don't really have -- s), I found in the section on starting the card that you have to "Enable power (VCC) to the socket and also set VPP1, VPP2 = 5V." Looking in /sys/pccard/pccard.c:insert(), I found the following code: /* * Enable 5V to the card so that the CIS can be read. */ slt->pwr.vcc = 50; slt->pwr.vpp = 0; So, I changed this to slt->pwr.vcc = 50; slt->pwr.vpp = 50; And now pccardc dumpcis shows all of the proper CIS information, pccardd finds the card and life is good. (Frankly, I was stunned that I figured this out; I'm not really that bright, you know.) Apparently, the Aironet card wants VPP turned on before it will let you read the CIS table. So, here are my questions: - Why is the vpp voltage alwats left at 0? - Is it safe for me to change the code so that it's set to 5 volts? Obviously I'm going to need this change in order to make the Aironet PCMCIA cards work. - If it's not safe to default vpp to 5 volts, is there a safe way to detect when it needs to be turned on and do it only for those cards that need it? -Bill -- ===== -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: wp...@ctr.columbia.edu | Center for Telecommunications Research Home: wp...@skynet.ctr.columbia.edu | 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 majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
patch for if_sis to support SiS630E, need testers
http://www.freebsd.org/~wpaul/SiS/sis.diff This patch adds support for reading the station address from the ATC CMOS RAM for board with the SiS 630E chipset with integrated SiS 900 ethernet. I've verified that the patch compiles and doesn't make the system explode, and it should have no effect on standalone SiS 900 devices, however I don't currently have access to a host with this chipset in it so I'm not 100% positive it does the right thing. Those who have such hardware running 4.2-RELEASE, 4.2-STABLE or -current, please apply the patch and let me know if the MAC address is read correctly. Note that the changes are hidden under #ifdef __i386__. The hacks to make this work are specific to the x86 architecture, and the SiS 630E chipset is only for x86 motherboards anyway. PCI adapters based on the SiS 900 should still work on the alpha. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
call for testers: port aggregation netgraph module
http://www.freebsd.org/~wpaul/FEC/4.x/fec.tar.gz http://www.freebsd.org/~wpaul/FEC/5.x/fec.tar.gz This is a call for testers for a netgraph module that can be used to aggregate 2 or 4 ethernet interfaces into a single interface. Basically, it lets you do things like the following: # kldload ./ng_fec.ko # ngctl mkpeer fec dummy fec # ngctl msg fec0: add_iface '"dc0"' # ngctl msg fec0: add_iface '"dc1"' # ngctl msg fec0: add_iface '"dc2"' # ngctl msg fec0: add_iface '"dc3"' # ngctl msg fec0: set_mode_inet The fec module will work with *any* combination of interfaces, not just multiport ethernet cards, however the port failover mechanism will not work unless the interface supports ifmedia and is able to report the link status. Cards that use the fxp, de, xl, tl, rl, sis, dc, wb, ste, sf, vr, ti and sk drivers should work. Yes, that means you can aggregate RealTek cards and gigabit ethernet cards together. The channel bonding is done using the Cisco fast etherchannel mechanism. The default hashing mechanism uses the MAC address, however you can select IP address hashing as well. IPv4 and IPv6 address *should* work, though I must admit I've been using IPv4 until now. If someone actually has a Cisco switch that implements fast ethetchannel, I'd be interested to know if it works with this module. At the moment, my test environment consist of two machines with multiport ethernet cards wired up using four crossover cables. Each link is checked once every second to see if the link is still up. An attempt to send a packet over a dead link will cause the packet to be shifted over to the next link in the bundle. There are tarballs for 4.x and 5.x systems. The 4.x tarball should work on 4.2-RELEASE or later. The 5.x one will work on -current. Both source and pre-compiled modules for x86 are provided. This code should work on the alpha as well. You can create more than one bundle by using more than one mkpeer command with ngctl(8). You can delete interfaces from a bundle using the del_iface command, which works just like the add_iface command. The fec0 pseudo-interface will inherit the MAC address of the first real interface to be added to the bundle, and that same MAC address will be propagated to all subsequent interfaces that are added. The MAC addresses are restored when an interface is removed from a bundle. Once the bundle is created, you can manipulate the fec0 interface as though it were a real ethernet interface. You must have either 2 or 4 NICs in the bundle. Share, enjoy, test, and report back to me any problems you encounter. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: call for testers: port aggregation netgraph module
> On Fri, 9 Feb 2001, Chris Dillon wrote: > > > On Fri, 9 Feb 2001, Dan Nelson wrote: > > > Cool, if thats all it will take, I'll give it a try. But, whatever > > method Compaq/Intel is using doesn't require me to set up the ports on > > the switch as being part of a trunk. It "just works". And IIRC, when > Its not real trunking. Your incoming traffic will still come on a single > link, only outbound traffic will be shared. (Or at least that's how I > think compaq stuff will work). That doesn't make any sense. If a host on one side of the channel can transmit over multiple links, then the host on the other end by definintion has to be able to receive over multiple links. The ng_fec module does an XOR of the bottom few bits of the source and destination addresses of a packet. (You can use either the ethernet addresses or the IP addresses.) The resulting value is used to select a port from the bundle and the packet is transmitted over that port. This means that all traffic in a given 'flow' will use the same link. (If the link is dead, the next link over is used instead.) For reception, all the traffic received from all of the interfaces in the bundle is simply dumped into the input queue for the fec0 pseudo-interface. This involves intercepting frames at the top of ether_input() using one of the netgraph vectors that was added there, and chancing the rcvif pointer in the mbuf header. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: if_fxp - the real point
NICs. Netgear is using the NatSemi DP83815 chipset on their FA311 and FA312 cards. D-Link uses RealTek 8139 and VIA Rhine II chips depending on just which model NIC you happen to get. The D-Link DFE-570TX quad port card uses the Intel 21143, and it's dirt cheap compared to the ZNYX and Adaptec cards of similar design, assuming you can find them. The interesting thign is that *all* of these chips have manuals available from their respective vendors WITHOUT NDAs, so I don't want to hear people telling me that NDAs are "just the price of doing business." I have stacks of unencumbered manuals here, and I'd be more than happy to smack people upside the head with them to prove them wrong. I'm getting really tired of being the only one beating this drum. I keep telling people to complain to whoever will listen inside these companies in the hopes that *somebody* will get the point. I also keep hoping that other people will appear and demonstrate some driver fu so that I don't have to be the only one people will turn to when they have a NIC that they want supported. I'm only one person, not a code generating machine, and I don't spend 24 hours a day agonizing over how I'm going to support every single network card on the planet. I tried it and it sucked, and not getting any support from the really big vendors or from inside BSDi doesn't make it any more appealing. All I can say is, Johnathan, I'm glad it's you and not me. And Dennis, you deserve a working driver. I really hope you get it. Part of me even wishes I could fix the problems for you, but my hands are tied and my patience has word thin. -Bill = -Bill Paul(925) 691-2800 | Systems Programmer, Master of Unix-Fu [EMAIL PROTECTED] | BSDi Open Source Solutions = "I like zees guys. Zey are fonny guys. Just keel one of zem." -- The 3 Amigos = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: if_fxp - the real point
> > I think its been mentioned several times in this and other threads that > intel has a driver for LINUX that is effective documentation on the board, > and the code is public (although you may have to stick an intel copyright > in the code also). Whoever mentioned this was not thinking clearly. A manual is effective documentation for a NIC. Sample driver code alone is not. It's handy, but it's not enough. When you write a driver, you make certain design decisions based on the information in the manual and the OS you're developing for. By forcing someone to rely soley on your driver to see how the board works, you're limiting their ability to make their own design decisions. What works well for Windows or Linux may be mediocre for BSD. Besides, Intel engineers have a knack for choosing really confusing register names. And again, saying "but there's a Linux driver" just gives vendors an excuse to perpetuate their stupidity. I'm not keen to give them this opportunity. > You guys continue not to understand why companies dont disclose board info > freely. You end up competing with your own customers. They dont want people > buying gray market parts and selling $9. boards. Its very easy to clone a > board with 2 chips on it these days. I'm sorry, that doesn't wash. *I* am not trying to compete with anyone. Lord knows I can't afford to fabricate my own controller chips on my salary. The users who just want to use the cards certainly don't want to compete with anybody. If anything, I want to help them make money. If your method for squashing competition also angers your allaged 'partners' and costs you money, then you need to come up with a better mechanism. Besides, there's supposed to be competition: it's a free market, remember? If I sell a car with a gas pedal, steering wheel and gear shift, I can't tell all the other car manufacturers not to make their cars with gas pedals, steering wheels and gear shifts, or swear all the people who drive my cars to secrecy so they can't tell anyone how they're meant to be driven. Just because other companies make cars with the same features, that doesn't make them better cars than mine: the consumer should do some research to find the best one instead of buying whatever's cheapest. Naturally, consumers are never that bright. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: call for testers: port aggregation netgraph module
> >Each link is checked once every second to see if the link is still up. > >An attempt to send a packet over a dead link will cause the packet to > >be shifted over to the next link in the bundle. > > Any chance this can be done through an async event rather > than by polling? If there was, I would have done it. MII transceivers can't send an interrupt back through the MAC unless the MAC supports it, and many don't. Consequently, the MII spec says nothing about async notification of anything. You have to poll. Resistance is futile. Gigabit MII transceivers are another matter. Polling and gigabit speeds don't go to gether very well. All of the GMII transceivers I've seen (Tigon and SysKonnect cards) have an signal pin of some kind that's wired to an external interrupt source pin on the MAC. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: call for testers: port aggregation netgraph module
> >> >Each link is checked once every second to see if the link is still up. > >> >An attempt to send a packet over a dead link will cause the packet to > >> >be shifted over to the next link in the bundle. > >> > >> Any chance this can be done through an async event rather > >> than by polling? > > > >If there was, I would have done it. > > Perhaps it would be best to create an interface that allows async > notification but to provide a default implementation of the interface > that polls? This would allow hardware that has a mechanism to detect > the state change to override the default method while all other > cards "just work" without modification by polling. Perhaps somebody who is not me should investigate this then. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: device driver dev. book
> Some body just told me that williams Paul from Columbia University (Bill > Paul @ Freebsd.org) has written that > kind of book. But I can't get his exact email address at FreeBSD.org to > ask him the reference. GR. Look, I have not now nor have I *ever* written a book of any kind. Whoever told you I had was wrong! Dead wrong, okay? Let me repeat: there is no book. Alright? Satisfied? Understand now? Good. Let us never speak of this again. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
sendfile() vs. gigabit ethernet
People are constantly asking me about the performance of gigabit ethernet cards with FreeBSD. I'm constantly wishing they would all go to hell -- directly to hell, without passing "GO" or collecting $200 -- but their persistence has led me to ask a few questions of my own. One thing everyone notices right away is that some of FreeBSD's defaults aren't terribly optimal for gigabit ethernet, the main one being socket buffer sizes. At least as far as TCP is concerned, you can do one of two things: - Change your application to call setsockopt() and increase the SO_SNDBUF and SO_RCVBUF values. - Use sysctl to change the net.inet.tcp.sendspace and net.inet.tcp.recvspace values. The former option affectly only a given application, while the latter affects the entire system. Most people will bump the sendspace and recvspace variables since it's easier than modifying their application. Changing the default from 16K to 64K usually has a drastic effect on performance with something like ttcp, which is what I typically use for testing. You can also use the -B flag to ttcp to have it increase the SNDBUF/RCVBUF values just for itself and achieve the same effect. But then what usually happens is people will attempt to perform a file transfer test using, of all things. FTP, and suddenly they notice that performance doesn't really improve all that much. I could never understand just why this was so, until I realized that /usr/libexec/ftpd in FreeBSD now uses sendfile(). The ttcp utility on the other hand uses write(2) (as does netperf for that matter). So my question is: has anyone done any tests with sendfile() over a high speed network link and tried to vary the sendspace/recvspace defaults to improve performance? If so, does it make any difference? My feeling is that it should, but from what I can tell, sendfile() only passes data to sosend() in page-sized chunks, and this is somehow negating the effect of increasing the socket buffer size. Am I right, or am I just missing something obvious, as usual? -Bill = -Bill Paul(925) 691-2800 | Systems Programmer, Master of Unix-Fu [EMAIL PROTECTED] | BSDi Open Source Solutions = "I like zees guys. Zey are fonny guys. Just keel one of zem." -- The 3 Amigos = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Call for testers: NatSemi DP83821 gigE driver
Thanks to the nice people at SMC, I finally got my hands on a couple of gigE NICs and have a preliminary driver available for one of them. The if_nge driver supports the NatSemi DP83820 gigabit ethernet MAC, which is used on the EZ Card 1000 (SMC9462TX), the D-Link DFE-500T, the Asante FriendlyNet Giganix 1000TA and 1000TPC, and (I believe) a couple of Addtron cards. These cards also use a NatSemi DP83861 PHY. The driver source is available from the following locations: http://www.freebsd.org/~wpaul/National/4.x 4.x if_nge source http://www.freebsd.org/~wpaul/National/5.x 5.x if_nge source http://www.freebsd.org/~wpaul/National/PHY nsgphy source (4.x and 5.x) Note that this is very alpha code. I can't test it very well as I have only one halfway working test box in the office right now. Don't ask me how well it performs because I DON'T KNOW. I *do* know the following: - 10/100 autoneg works - 1000mbps autoneg with an Alteon AceNIC seems to work - RX and TX at 10/100 works - RX and TX at 1000 works - jumbograms work Note that I'm not supplying a whole checklist of instructions that show how to add the driver to your system, because I want to insure that only the people who already know how to do this will send me bug reports. :) It's possible to build the driver directly into your kernel or compile it as a module. You also must have the nsgphy driver loaded in order for the if_nge driver to work. (It will actually work with the ukphy driver -- but only at 100mbps.) Anyway, if you have one of these cards and can test the code, please do, and let me know the results. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Call for testers: NatSemi DP83821 gigE driver
> > Is there a POC we can all send thanks to for supplying the neccessary HW > and doco? Since they seem to be a more friendly company then Intel it > would do us well IMO to thank them for it. Actually, it was my contact at Intel who put me in touch with the right people at SMC. As for the documentation, National has all the manuals for their stuff online: http://www.national.com/ds/DP/DP83820.pdf http://www.national.com/ds/DP/DP83821.pdf http://www.national.com/ds/DP/DP83861.pdf Those are the controller and PHY manuals, respectively. (The 83821 is actually the same as the 83820, but 32-bit only. I think Addtron is the only one that uses the 32-bit version.) Note that the DP83861 PHY seems strikingly similar to the LSI Logic L80600 PHY. At least, the manuals look a lot alike. Don't ask me why, I just work here. That said, Intel also agreed to let D-Link release the LXT1001 manual to me, so I have that too. Both D-Link and SMC sell cards using both these chips; SMC got me their cards first, so I'm using them for my testing. I sent a confirmation of receipt and thank you note to the SMC people today. I'm not sure if I should be posting their e-mail addresses all over the lists though. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Call for testers: NatSemi DP83821 gigE driver
> > On Tue, 8 May 2001, Bill Paul wrote: > > > I sent a confirmation of receipt and thank you note to the SMC > > people today. I'm not sure if I should be posting their e-mail addresses > > all over the lists though. > > Perhaps in this type of situation, someone needs to simply collate a list > of names/organisations that have said "thanks", which could be sent as a > thank-you by someone in actual contact, such as yourself? > > We'd just need a mailbox somewhere to collect them. > > Comments? No, no more comments. Guys? You're doing it again. Call for testers I said. So test. No more noise. Test. Talk later. Test now. K PLZ THX. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Is 3COM 3C996-T supported via Alteon Driver?
> > Hello All: > > > > I'm in the process of configuring a cluster and noticed that 3COM > > had recently purchased Alteon and was making a 3C996-T 10/100/1000 BaseT > > cards. Can the Alteon Tigon drivers support this card? > > After a bit of poking around, and discussion with 3Com's tech support, > they have confirmed that this card is NOT Alteon based. In fact, > most of the current crop of 10/100/1000 BaseT cards are based on > broadcom's recent chipset, (I'm not sure which chip, possibly > the BMC5401 or the BMC5402). I don't think that there are FreeBSD > drivers for these cards (due in some part to reasons discussed below). > > Other FreeBSD friendly vendors (I'm not sure if I'm allowed to give names > here) have confirmed that they too are preparing cards with the same > technology. I've heard rumors that the chip supplies are currently limited, > so that card availability might be limited until late May. The 3c996 uses the Broadcom BCM5700, also known as the Tigon 3. Apparently, Alteon 'outsourced' the development of the Tigon 3 to Broadcom, and 3Com has some right to it now that they own Alteon's NIC division. The BCM5400 and 5401 are PHY (transceiver) chips, not MACs. I have been trying to get Broadcom to give me a copy of the BCM5700 programming manual, but have been left somewhat out if left field. My last contact with them was a few weeks ago, when they told me they needed approval from yet another management droid of some kind, who hasn't responded to either my phone messages or my e-mail. The Tigon 3 doesn't look *too* different from the Tigon 2, based on what I've seen in the Linux driver. (Yes, they wrote a Linux driver, but not a BSD driver.) One major difference is that the firmware seems to now reside in the chip itself, which saves you from having to load it from the driver. In the meantime, I'm currently working on drivers for the National Semiconductor DP83820 and Level 1 LXT1001 gigabig MAC chips. The Level 1 part can be found on the D-Link DGE-500SX and a couple of SMC cards. The NatSemi chip is being used on cards by D-Link (DGE-500T), Asante and Addtron. Getting the DP83820 manual was easy (it's on National's web site). Getting the LXT1001 manual took some arm twisting, but Intel (who now owns Level 1) finally agreed to let D-Link release it to me without NDA. Unfortunately, the BSDi/Wind River deal still hasn't quite closed yet, which is preventing me from ordering hardware. I'm doing as much of the gruntwork as I can, but I can't do actual testing until I can get some sample NICs. Everyone will know once I'm done. -Bill = -Bill Paul(925) 691-2800 | Systems Programmer, Master of Unix-Fu [EMAIL PROTECTED] | BSDi Open Source Solutions = "I like zees guys. Zey are fonny guys. Just keel one of zem." -- The 3 Amigos = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sysKonnect dual gig adapter
> Looking at the description of the sysKonnect dual adapter, its not clear if > this is a real 2 port nic or that the second port is only a failover port. I > have 2 questions for anyone who has one: > > 1) Can this be used as a 2 port gigabit NIC? Yes. You will have two interfaces, sk0 and sk1, which represent the two ports. Each interface operates independently of the other. > 2) Does this NIC have hardware failover (that is, when power is cut the 2 > ports will be physically tied together. I dont know of any PC plug in that > does this, but its a neat feature. No. SysKonnect advertises the cards for use in failover applications with their Windows (and Linux) drivers. However this is a feature of their driver software only: it has nothing to do with the hardware. When I wrote the if_sk driver, I decided that setting it up as a real dual port NIC was more useful. (If you're really curious, go to www.syskonnect.com and download their Linux driver source. It has all of their failover magic in it.) The SysKonnect cards consist of the SysKonnect GEnesis chip and the XaQti XMAC II chip. (XaQti no longer exists, it was assimilated by Vitesse.) The XMAC is a gigabit MAC with a generic bus interface. The GEnesis provides the PCI interface, DMA support, some packet buffering and arbitration. Basically, the GEnesis is what lets you connect the XMAC to a PCI bus. But the GEnesis is designed to support _two_ XMAC chips: it has two sets of DMA queues and two register windows so you can twiddle both XMACs at once. That's how the dual link cards work: there's one GEnesis and two XMACs, and if you have a copper card, two Broadcom copper gigabit PHYs. This is a bit different from the usual multiport NIC design where you have two PCI-based MAC chips and a PCI-PCI bridge. Functionally, this is the same as having a bunch of single-port PCI NICs in their own slots. The SysKonnect multiplexes both MACs through a single PCI slot instead. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IP checksum offloading with intel 82559 fast ethernet.
> > Don't some of the Gigabit FreeBSD drivers actually utilize > > the on-board > > checksum processing??? FreeBSD 5.0-current has support for TCP/IP checksum offload, and the if_ti driver makes use of it. The Tigon NICs do this in firmware though. I attempted to add support to the SysKonnect driver, however the transmit side checksum offload support apparently doesn't work, and the receive side offloading has a bug which requires a bit of a workaround. The 3Com 3c90xB/3c90xC chips are also supposed to support checksum offload, but as of yet I haven't had much luck getting this to work either. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Multiple MAC addresses per NIC
> Hello all, > > This issue was discussed last year, but I can't find any information on > a resolution. We're trying to create a high availability FreeBSD > cluster with a standby machine being able to take over for a failed host, > and need the standby machine to have its own MAC address, plus the MAC > address of the failed host. The NICs we use are RealTek and Intel > EtherExpress 100. We find hints in the NIC chip databooks but no > information for us mere programmers. So, I have two questions: > > 1. Does anybody have sample driver code that sets up the multiple hardware > address features of these NICs? > > 2. Does anybody have documentation that could help me create the driver > changes? (book, PDF, publication number, anything?) > > We have tried to get more documentation out of Intel, and the salesmen > are willing, but we need a publication number to get anything. They keep > giving us the databook, which list pinouts, various electrical specs, > and some theory, but it's no programmer reference. This is very hardware dependent. Most cheap ethernet chips offer the following receive filter options: - single perfect filter entry for one MAC address (the station address) - multicast hash table (usually 64 bits, sometimes 128 or 512) - promiscuous mode (receive everything) Other more sophisticated chips may offer additional perfect filter entries. (The ThunderLAN has 4, the Adaptec AIC-6915 "Starfire" has 16. The tulip can be programmed to use additional entries depending on the filter type you select. Not all clones support the same filter options.) The only portable thing to do is put the chip in promiscuous mode and let the software sort everything out, however this will force the OS to do extra work. I wouldn't bother with Intel. They have a bug up their ass about releasing info and you would do better to just tell them "sorry, you're giving us too much shit so we're switching to a different vendor" rather than continue playing footsie with them. Not that RealTek is much better. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 3Com 10/100 Mini PCI Ethernet
> Mike Smith wrote: > > > > I think the ep driver (which does some funny things to the eeprom) managed > > > to overwrite part of the eeprom so that the xl driver failed to recognize > > > the card. I then tried to add it to the vx driver (at that point i think > > > i started to know what i did) which failed too, so i wrote a subroutine > > > to display the eeprom contents which (because i did not understood the > > > the OP and SubOP command fields before running it) finally erased the > > > eeprom contents to 0x in all locations (which now prevents the card > > > from being initialized by the BIOS - has anybody an idea how to revive > > > such a PCI card ). > > > > You would need to write the original EEPROM contents back into the > > EEPROM, after manually configuring it. Very difficult. > > Am i right assuming that pciconf is the right tool for this (manually > configuring) job ? No, you are wrong. The only way to write to the EEPROM (that I know of anyway) is via the usual EEPROM control registers in the card's I/O space, which won't be mapped if the card is so fubared that the BIOS won't initialize it. > > > Do i understand you right in that you would do a fresh start with this > > > card using the xl driver ? I'm a bit concerned about again accidentially > > > overwriting the eeprom, its an _expensive_ card ... ;-) Then you should have been more careful with it. > > That's correct. The xl driver is not likely to trash the eeprom, > > although I'm quite surprised that the 'ep' driver did. > > > > What possessed you to start with an ISA-only driver when the device is so > > clearly a PCI device? > > It was the device ID 0x6055 in the ep driver which is identical to the > device ID in the Mini PCI version. I'm sorry, but after reading this thread, I'm having a hard time coming up with an explanation for this nonsense which doesn't involve you being a dumbass. The device ID in question is in if_ep_pccard.c which is for PCMCIA devices only! Not PCI! There is no way that the ep driver will probe a PCI device unless you go to some lengths to twist its arm! Why you resorted to this arm-twisting instead of the blazingly obvious action of trying an actual PCI driver is beyond me. (_How_ you even managed to twist its arm is also beyond me. Obviously you decided not to tell us exactly what you did for fear of being found out. Too late.) This is not one of those "it's nobody's fault" situations. You did not make an innocent mistake: you screwed up. In front of god and everything. You ignored all of the signs, portents, and the dude with the spooky black robe and scythe standing over your shoulder. And then you tried to cover it up. Now, get out a piece of paper, write "I damaged this card because I'm a dumbass" on it, stick it to the card, then take it back to where you got it and try to get it replaced. Alternatively, tell us where you got it so I can order one and try to get it supported properly instead of having my blood pressure driven off the scale by yet another tale of foot-shooting idiocy. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 3Com 10/100 Mini PCI Ethernet
> AFAIK, this card is a 3Com OEM product which is not available for purchase,
> all i can give you is an HP part number. It is also not a "normal" PCI card
> but a so called "Mini PCI" card and its about as large as a matchbox or
> even a bit smaller.
>
> Anyway, i have replaced the card, and i will try hard not to make the same
> mistakes again (before this whole mess, i was under the impression that
> only monitors can be destroyed by software, now i know better ...).
>
> But, i want to get this card supported. In case you have one or the other
> good suggestion (except "stay away from the card, don't even look at it !!")
> on how to proceed in a more orderly fashion, please let me hear them.
Type "pciconf -l" and show us the results so we can actually see the
vendor/device ID data. If it is indeed vendor ID 0x10B7 and device ID
0x6055, then try the patch included with this e-mail. To apply it, do
the following:
- Save this message to a file, e.g. /tmp/xl.diff
- cd /sys/pci
- patch < /tmp/xl.diff
Then make a new kernel and/or if_xl.ko module and test it. If it works
correctly, you should see the ethernet address and proper media selections
in the dmesg output. And, more importantly, you should be able to send
and receive traffic. If it doesn't probe correctly, then it's probably
not a Cyclone/Hurricane/Tornado chipset and the xl driver won't support
it. I believe that it is a Cyclone/Hurricane/Tornado chipset though,
since 3Com doesn't make any other 10/100 devices except for what's on
the 3CR990 card, which is a) undocumented and b) overkill for an embedded
laptop ethernet adapter.
-Bill
*** if_xl.c.origMon Aug 7 14:25:39 2000
--- if_xl.c Mon Aug 7 14:25:03 2000
***
*** 55,60
--- 55,61
* 3Com 3c980C-TX 10/100Mbps server adapter (Tornado ASIC)
* 3Com 3cSOHO100-TX 10/100Mbps/RJ-45 (Hurricane ASIC)
* 3Com 3c450-TX 10/100Mbps/RJ-45 (Tornado ASIC)
+ * 3Com 3cN3AV155610/100Mpps/RJ-45 HP laptop ethernet (Tornado ASIC?)
* Dell Optiplex GX1 on-board 3c918 10/100Mbps/RJ-45
* Dell on-board 3c920 10/100Mbps/RJ-45
* Dell Precision on-board 3c905B 10/100Mbps/RJ-45
***
*** 184,189
--- 185,192
"3Com 3cSOHO100-TX OfficeConnect" },
{ TC_VENDORID, TC_DEVICEID_TORNADO_HOMECONNECT,
"3Com 3c450-TX HomeConnect" },
+ { TC_VENDORID, TC_DEVICEID_3CN3AV1556,
+ "3Com 3CN3AV1556 Fast Etherlink XL" },
{ 0, 0, NULL }
};
***
*** 1142,1147
--- 1145,1151
case TC_DEVICEID_HURRICANE_SOHO100TX: /* 3cSOHO100-TX */
case TC_DEVICEID_TORNADO_10_100BT: /* 3c905C-TX */
case TC_DEVICEID_TORNADO_HOMECONNECT: /* 3c450-TX */
+ case TC_DEVICEID_3CN3AV1556:/* 3cN3AV1556 */
sc->xl_media = XL_MEDIAOPT_BTX;
sc->xl_xcvr = XL_XCVR_AUTO;
if (verbose)
*** if_xlreg.h.orig Mon Aug 7 14:25:39 2000
--- if_xlreg.h Mon Aug 7 14:20:14 2000
***
*** 641,646
--- 641,647
#define TC_DEVICEID_TORNADO_10_100BT_SERV 0x9805
#define TC_DEVICEID_HURRICANE_SOHO100TX 0x7646
#define TC_DEVICEID_TORNADO_HOMECONNECT 0x4500
+ #define TC_DEVICEID_3CN3AV15560x6055
/*
* PCI low memory base and low I/O base register, and
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: getpeereid() syscall patch for FreeBSD 4.0
> * William E. Baxter <[EMAIL PROTECTED]> [000808 09:27] wrote: > > A patch implementing a getpeereid() syscall in FreeBSD 4.0 is > > available at > > > > http://www.superscript.com/patches/freebsd_4_0.getpeereid > > > > A local-domain server uses getpeereid() to obtain client credentials. > > Based on getpeereid() I created ucspi-ipc, a local-domain analogue to > > Dan Bernstein's ucspi-tcp. The project came about after I read the > > "Wiping out setuid programs" discussion the the BugTraq archives. At > > present, ucspi-ipc runs on patched OpenBSD, patched FreeBSD, and on > > Linux kernels that support SO_PEERCRED with getsockopt(). > > I haven't used the credential passing feature of sendmsg(), but I > was wondering what advantages this has over being able to pass > kernel verified id's through a unix domain socket using SCM_CREDS. > My reading of UNP seems to indicate that it offers the same features. The implementation of SCM_CREDS in FreeBSD is my doing, and I did it that way for a reason. At the time, I wanted a way to perform RPCs via UNIX domain sockets and have the server know with reasonable certainty the identity of the client. And I wanted to do it without using AUTH_DES authentication because I was trying to bootstrap AUTH_DES authentication in keyserv. The problem is that RPCs are by definition messages. Things are handled at the application layer on a per-message basis, not on a per-socket basis, even for TCP connections. The problem with having credentials established once when a socket is opened is that the client process can conceivably fork, at which point you will have two clients sharing one socket with the same credential data. This isn't likely, but it's possible, and it bothered me. By having the credentials inserted into the message each time by each process, there's no ambiguity, even though you only have one socket. However this may not be the ideal solution for everyone. You may be satisfied with the "create credentials once when you open the socket" method, in which case the best thing is to support both approaches with hopefully similar code. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: RPC not taking the same service twice: a bug or a security measure?
> A coworker seems to have found an issue with portmap on FreeBSD. > Aparently, if you try and register the same service twice, but with > different protocols (UDP vs TCP), it doesn't work. I'm not entirely sure > I believe this, and I am digging for more details, but I am writing to > see if anyone can tell me anything that will save me having to do the > investigative work. :-) I'll follow up with more details as I can. No you won't, because both you and your cow-orker are smoking entirely too much crack. (Him for hallucinating this problem in the first place, and you for believing him enough to post this query here.) Do rpcinfo -p on a FreeBSD host running NFS, NIS, AMD, or whatever, and you'll see both UDP and TCP entries for each service. If it didn't work, somebody would have screamed bloody murder about it long before now. You don't explain how your cow-orker is trying to register these services (it's probably a custom RPC application, but he could be using a hammer and chisel for all we know), nor do you go into any detail at all about what "doesn't work" means. The correct procedure here is to take away his crack pipe and pump him for more details, *then* post here only after you're sure he's not imagining things. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Legacy ethernet cards in FreeBSD
[Charset iso-8859-1 unsupported, filtering to ASCII...] > Dear All, > > Last night I cvsupped my trusty old Compaq Deskpro XL 6200 from 4.0-release > to 4.2-beta. As part of that process, I seem to have lost support for the > on-board NIC (lnc0: PCNet/PCI Ethernet Adapter, PC-net-32 VL-Bus). Ok, "seem to have lost support" is about the vaguest thing you could have said. I've killed people for less. Please explain in detail how you arrived at the conclusion that the card was no longer supported. Show us the dmesg output from your machine. Explain what you tried to do and what results you observed. Don't just say "it doesn't work." You've not going to help anyone that way. FreeBSD 4.2 has a new driver for AMD PCnet/PCI devices, in particular the 10/100 cards, because the lnc driver runs these cards in 16-bit LANCE compatibility mode which really impairs their performance. Did you check to see if a pcn0 device was detected? Did you attempt to use it? If not, why not? If so, what happened? > What is the newest version of FreeBSD that will propely support that card? You're soaking in it. > If there are people who are cleaning up the support for older network cards > in FreeBSD I'd like to help out by sending you my old NICs. It's not like > they're any good to me without OS support. > > Please contact me off-list for any of the following cards: > > 3Com 3c503ISA Should work with the ed driver, *provided* you get its I/O address set correctly so that the ed driver will detect it. I haven't used one of these since FreeBSD 2.x though. > DEC EtherworksISA > DEC DE205 ISA Don't know about these. > SMC EtherEZ ISA Should also work with the ed driver, though you may have to turn off plug and play mode using the SMC EZSetup utility. > RealTek "TP-Link" PCI If this is a 10mbps card, it should be an NE2000 clone, and will work with the ed driver. If it's a 100Mbps card, it should work with the rl driver. > I'll be happy to try out patches for the lnc driver to fix the problem of > the Deskpro, or to give remote access to it if you want to work on it. I'd be happier if you told me whether the pcn driver works or not. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: More detail on Deskpro XL6200 NIC (was: Legacy ethernet cards in FreeBSD)
[Charset iso-8859-1 unsupported, filtering to ASCII...] > Dear Bill, others, > > I've been working on getting my Deskpros to use their NIC under 4.2, but no > luck. The problem is as follows: I installed 4.0, and the NIC came up under > the lnc driver, reports its MAC address and works fine. > [...] > In 4.2, the lnc driver still probes and finds the NIC, but does not report > finding a MAC address, and the NIC remains dead. [...] > Compiling a kernel with the pcn driver does not help. Booting a lnc+pcn > kernel causes the behaviour described above, booting a pcn-only kernel makes > the NIC show up as an unknown device, vendor 0x1022, device 0x2000. *ahem* How about compiling a kernel *without* the pcn driver? I want to know why you didn't consider this combination. (Well, I know why: because giving me the answer straight away rather than making me drag it out of you would have been too easy. I would never be that lucky.) The pcn driver does *not* want this card. It specifically checks for the device code in the probe routine and rejects cards it doesn't like. Note that this is *not* the PCI vendor/device ID: the way AMD did it, the PCI ID is the same for all the PCnet devices. You need to read a register in I/O space to determine exactly what device this is. That said, I think I know what the problem is. The pcn driver is probing the card first and setting it to 32-bit mode. The lnc driver wants the device to be in 16-bit mode: if it isn't, it won't be able to properly access any of its registers. This is why reading the card type and MAC address fails. Next time, *remove* the pcn device from the kernel config and leave the lnc driver. That should work. In the meantime, I need to get out the PCnet manual and check how to put the device back into 16-bit mode at the end of pcn_probe() so that the lnc driver will play nice with it. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: More detail on Deskpro XL6200 NIC (was: Legacy ethernet cards in FreeBSD)
Well this sucks. According to the manual, once you select 32-bit mode,
the only way to get the chip back to 16-bit mode is a hardware reset.
I suppose the quick fix for now is to not let if_pcn switch the chip
into 32-bit mode during the probe routine. Please try the patch for
if_pcn.c included with this message. It should fix things so if you
have both the pcn and lnc drivers in your kernel, the lnc driver will
attach properly.
I'm cc'ing this to jkh for his approval to have this patch added to
the -stable tree in time for 4.2-RELEASE.
-Bill
*** if_pcn.c.orig Thu Nov 2 16:37:45 2000
--- if_pcn.cThu Nov 16 11:48:43 2000
***
*** 110,115
--- 110,116
};
static u_int32_t pcn_csr_read __P((struct pcn_softc *, int));
+ static u_int16_t pcn_csr_read16 __P((struct pcn_softc *, int));
static void pcn_csr_write __P((struct pcn_softc *, int, int));
static u_int32_t pcn_bcr_read __P((struct pcn_softc *, int));
static void pcn_bcr_write __P((struct pcn_softc *, int, int));
***
*** 203,208
--- 204,217
return(CSR_READ_4(sc, PCN_IO32_RDP));
}
+ static u_int16_t pcn_csr_read16(sc, reg)
+ struct pcn_softc*sc;
+ int reg;
+ {
+ CSR_WRITE_2(sc, PCN_IO16_RAP, reg);
+ return(CSR_READ_2(sc, PCN_IO16_RDP));
+ }
+
static void pcn_csr_write(sc, reg, val)
struct pcn_softc*sc;
int reg;
***
*** 401,410
mtx_init(&sc->pcn_mtx,
device_get_nameunit(dev), MTX_DEF);
PCN_LOCK(sc);
! pcn_reset(sc);
! chip_id = pcn_csr_read(sc, PCN_CSR_CHIPID1);
chip_id <<= 16;
! chip_id |= pcn_csr_read(sc, PCN_CSR_CHIPID0);
bus_release_resource(dev, PCN_RES,
PCN_RID, sc->pcn_res);
PCN_UNLOCK(sc);
--- 410,429
mtx_init(&sc->pcn_mtx,
device_get_nameunit(dev), MTX_DEF);
PCN_LOCK(sc);
! /*
!* Note: we can *NOT* put the chip into
!* 32-bit mode yet. The lnc driver will only
!* work in 16-bit mode, and once the chip
!* goes into 32-bit mode, the only way to
!* get it out again is with a hardware reset.
!* So if pcn_probe() is called before the
!* lnc driver's probe routine, the chip will
!* be locked into 32-bit operation and the lnc
!* driver will be unable to attach to it.
!*/
! chip_id = pcn_csr_read16(sc, PCN_CSR_CHIPID1);
chip_id <<= 16;
! chip_id |= pcn_csr_read16(sc, PCN_CSR_CHIPID0);
bus_release_resource(dev, PCN_RES,
PCN_RID, sc->pcn_res);
PCN_UNLOCK(sc);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Ethernet de driver problem on 3.5 stable
> > I have run into an issue with the de driver and Dlink quad cards under > 3.5 stable. > > Despite the messages from the driver, claiming to be in full duplex, [...] > Is there a known problem with the Dlinks or is this a possible > issue in the driver? [...] > Probing for devices on PCI bus 2: > de0: rev 0x41 int a irq 11 on pci2.4.0 [...] It's a driver bug, although it's partly Intel's fault for screwing up the 21143 design. To enable full duplex mode, you're supposed to set the full duplex bit in in CSR6. In the 21140A, that's all this bit does; it's not affected by anything else. But in the 21143 design, this bit performs two functions, depending on the setting of the autoneg enable bit in CSR14. If the autoneg enable bit is off, then the full duplex bit works as expected. But if the autoneg enable bit is turned on, the full duplex bit controls whether or not the 21143 will advertise 10Mbps/full-duplex during an NWAY exchange. Unfortunately, after a software reset, the autoneg enable bit in CSR14 is turned on by default, and the de driver never bothers to clear it. The stupid thing is that there are plenty of unused bits in other registers that Intel could have used rather than overloading the full duplex bit in CSR6 to perform two functions. Anyway. The dc driver in FreeBSD 4.0 and later should get this right. If you want to try and fix it in the de driver, you need to add a line somewhere that says: TULIP_CSR_WRITE(sc, csr_14, 0); It should probably at the end of tulip_init(), or possibly near the end of tulip_reset(), the point being to do it immediately after invoking a software reset in order to clear the autoneg enable flag. Either that, or upgrade to FreeBSD 4.2. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: National Semiconductor 82c168/82c169 driver
> I haven't been able to find a driver for this ethernet card, That's because it doesn't exist. There is no such thing as a "National Semiconductor 82c168/82c169." There is such a thing as a National Semiconductor DP83815 (MacPHYter), and there's also such a thing as a Lite-On 82c168/82c169 (PNIC). You appear to have gotten the two confused. Also, this is a chip, not a card. What you really meant to say was: "I just bought this new Netgear FA311-TX (or FA312-TX) card and it has a National Semiconductor chip on it. This has me all confused because the last Netgear card I bought (an FA310-TX) had a PNIC chip on it." If you have FreeBSD 4.1.1 or later, then the NatSemi chip will work with the "sis" driver. (It has a similar programming interface to the SiS 900 so I decided to just modify the sis driver to support it rather than writing a whole new one.) I've tested a Netgear FA312-TX in the office and from what I can tell it works fine. The PNIC chip works with the dc driver. > so I'm > working on porting the Linux driver over. It seems to have "natsemi" > coded in as the default device mnenomic. You mean: "The source file appears to be called netsemi.c." Linux network interfaces are all called ethX. > Is it a good idea to pull this > name directly over to FreeBSD? So my Ethernet interface would be natsemi0 > instead of fxp0 (for an Intel card)... No, it's a good idea to try a newer FreeBSD release, or grab if_sis.c and if_sisreg.h from a newer release and put it on your older system. It's also a good idea to tell us what version of FreeBSD you're using so we don't have to guess. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [PATCH available] TI-RPC and NetBSD's rpc.lockd
> On Tue, Dec 26, 2000 at 02:20:46AM +0100, Martin Blapp wrote: > [snip] > > Issues with the code: > > > > 1.) NETBSD sets in svc_tcp.c some LOCAL_CREDS which we don't have in our > > src/sys/kern/uipc_usrreq.c. They have a FLAG which - if set - > > automatically sends the credentials on AF_UNIX sockets connections > > if we do a recvmsg(). We have to implement this to have rpcbind properly > > working. AF_UNIX socket operations are broken at the moment, but > > with compability-mode 'rpcbind -Li' rpcbind works. > > We have something analogous ... look for SCM_CREDS. It's a shame these > aren't the same on both (Net|Free)BSD. I'm responsible for implementing this feature. When I sat down to try and make secure RPC work, I was unaware of the existence of the LOCAL_CREDS feature that had been implemented in BSD/OS at about the same time. What I wanted was a way to provide credentials for each *message* rather than for each socket, since RPC is more or less message-based. I was also concerned with avoding problems that might arise if a client process fork()ed while holding open a socket to which credential info had been assigned. You obviously don't want the parent and the child process to return the same credential info. Using the SCM_CREDS 'hack' was a) expedient, as it only involved a minor change to the kernel and b) it seemed to agree with the way RPC worked, i.e. each RPC needs the credential info for authentication. The reason you need the LOCAL_CREDS/SCM_CREDS stuff at all is that keyserv needs to know the identity of the user that's talking to it. It must not allow access to a user's diffie-helman key pair to anyone other than the user to whom it belongs (and, potentially, the superuser). The problem is the original sockets API did not provide any way for this authentication do be done. Many alternatives were discussed and rejected because they were too complex or just plain didn't work. The notion of using credentials was new in TI-RPC because STREAMS/TLI offers a way to do it. In SunOS 4, there was instead a terrible kludge based on the ugly and bletcherous keyenvoy program. I made keyenvoy work, but it struck me that it had a potentially serious weakness: it depended on the "only root can bind to port numbers less than 1024" property of UNIX TCP/IP networking, and it distinguished local connections from remote ones by comparing the origin IP address with 127.0.0.1. (Can you say IP spoofing? I knew you could.) Anyway, imagine my surprise when, after going to all the trouble of thinking up the SCM_CREDS hack, making it work, and then patting myself on the back for being clever, I opened up my brand new copy of _UNIX Network Programming, 2nd Edition, Vol I_ and found that some fool at BSDi had come up with the idea first. :) NetBSD uses the BSD/OS approach rather than the FreeBSD approach. In theory, you could have both. I still say the per-message credential mechanism works better with RPC, but I'm just a crotchety old fart anyway. Relatively speaking. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [PATCH available] TI-RPC and NetBSD's rpc.lockd
[chop] > Switching gears back to the BSD/OS approach you mentioned, UNPv1 says, > > On a datagram socket, the credentials accompany every datagram. On > a stream socket, the credentials are sent only once, the first time > data is sent. > > So as long as one is using a SOCK_DGRAM socket, the BSD/OS-NetBSD > approach should be analogous to what we have currently in FreeBSD? What if the client creates a TCP socket, the credentials are sent, then the process fork()s. Yeah, I know: why in the hell would you do that? Who knows, but you have to account for all cases. Even though you may have a TCP stream socket, you're still sending discrete requests and replies over it. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
NatSemi DP83820 gigE driver kit for 4.2 and 4.3
For those who have gigabit ethernet NICs based on the National Semiconductor DP83820 and DP83821 controller chips and want to use them with FreeBSD 4.2 and 4.3, there is a driver kit now available at the following URL: http://www.freebsd.org/~wpaul/National/dp83820_drv.tar.gz This kit contains source and precompiled KLD modules for both the x86 and alpha platforms. This driver supports the following cards: SMC EZ Card 1000 (SMC9462TX) D-Link DGE-500T Asante FriendlyNet GigaNIX 1000TA and 1000TPC Addtron AEG320T LinkSys EG1032 (32-bit PCI) and EG1064 (64-bit PCI) Surecom Technology EP-320G-TX Netgear GA622T These cards are all extremely cheap (some can be had for under $100) and fairly easy to find. (I now have one in my workstation.) They could potentially become extremely popular, which is why I'm making a driver retrofit kit available. Anyone running a recent 4-STABLE or 5.0-CURRENT system should already have the necessary driver support. Note that you must have the kernel sources installed to recompile the driver. Share and enjoy! -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: NatSemi DP83820 gigE driver kit for 4.2 and 4.3
> > On Fri, 13 Jul 2001, Bill Paul wrote: > > > For those who have gigabit ethernet NICs based on the National > > Semiconductor DP83820 and DP83821 controller chips and want to use > > them with FreeBSD 4.2 and 4.3, there is a driver kit now available > > at the following URL: > ... > > These cards are all extremely cheap (some can be had for under $100) > > and fairly easy to find. (I now have one in my workstation.) They could > > potentially become extremely popular, which is why I'm making a driver > > retrofit kit available. Anyone running a recent 4-STABLE or 5.0-CURRENT > > system should already have the necessary driver support. > > How do these perform compared to the more expensive gigabit cards? > > Mike "Silby" Silbersack > They're "okay." The NatSemi chip has one flaw, which is that RX buffers must be aligned on a 64-bit boundary. None of the more expensive NICs have this restriction. The correct way to deal with this is to copy frames on receive to fixup the alignment, but I decided to make this conditional for this driver: on the i386 platform, the driver omits the copy since unaligned accesses are allowed, and the performance hit for copying is severe when you're using jumbo frames. On the alpha, you have to do the copy. The chip has some nifty features though: hardware VLAN tag insertion and removal, TCP/IP checksum offload on receive and transmit, 2048-bit multicast hash filter, and 4 pattern match buffers for use with WOL. The transmit checksum offload has to be turned off if you use jumbo frames larger than about 8K, because the chip only has an 8K transmit FIFO. There is also support for interrupt moderation. For $90 to $120, they're a good bargain. You should be able get at least 300 to 400Mbps on good x86 hardware (with TCP). -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: NatSemi DP83820 gigE driver kit for 4.2 and 4.3
> > On Monday, July 16, 2001, at 12:57 PM, Bill Paul wrote: > [...] > > The chip has some nifty features though: hardware VLAN tag insertion > > and removal, TCP/IP checksum offload on receive and transmit, 2048-bit > > multicast hash filter, and 4 pattern match buffers for use with WOL. > > What is WOL? Wake on LAN. > > The transmit checksum offload has to be turned off if you use jumbo > > frames larger than about 8K, because the chip only has an 8K transmit > > FIFO. There is also support for interrupt moderation. > > Does it automatically not checksum packets >8K, or does A Bad Thing > happen if you fail to turn it off first? It does a Bad Thing (tm). In my testing, trying to send a frame larger than 8170 bytes puts the transmitter to sleep. Normally, the chip acknowledges transmit commands with three interrupt indications: TX DMA done (packet was transfered to the chip), TX done (packet made it to the wire), TX idle (TX queue empty, waiting for more packets). If you have transmit checksums enabled and send a frame larger than 8170 bytes, you get the TX DMA done interrupt, but nothing else. The transmitter stops responding after that, and eventually a watchdog timeout is triggered which resets the NIC. The driver disables TX checksum offloading if you set the MTU above a certain threshold. I think at that point, the performance gain from using jumbo frames is greater than that of using TX checksum offload anyway (for sustained transfers anyway). For the record, the chip allows TX checksum offload on a global or per-packet basis. I use the per-packet method, and simply don't set the "I want TX checksums computed" bits in the TX DMA descriptors once the MTU is set above the threshold (I also clear the if_hwassist flags so the OS will go back to computing the checksums itself). -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: NatSemi DP83820 gigE driver kit for 4.2 and 4.3
> On Mon, 16 Jul 2001, Bill Paul wrote: > > > They're "okay." The NatSemi chip has one flaw, which is that RX buffers > > must be aligned on a 64-bit boundary. None of the more expensive NICs have > > this restriction. > > Go ahead and beat me up if you have to :-) But why is there _any_ issue > with RX buffer alignment? I get some mbufs and set the data pointer to > any point I want, or I get a cluster, which is always on a 2k boundary. The OS wants the _payload_ to be aligned on a 32-bit boundary. It tries to do 32-bit accesses to the IP header, and the NFS code also does 32-bit accesses when trying to un-XDR NFS requests. In both cases, the code assumes that the data will be aligned on a 32-bit boundary. On the x86, the alignment doesn't matter: you can do 32-bit loads and stores from arbitrary boundaries and the CPU will fake things up for you so that you won't generate an unaligned access trap, though there will be a slight performance penalty. But on other CPUs such as the alpha, SPARC, PPC and (I suspect) the IA-64, unaligned accesses in the kernel generate a fatal trap and a panic. In user space, an unaligned access may result in a bus error, unless the OS is kind enough to handle the trap, which I believe FreeBSD/alpha does. The problem is that the ethernet frame header is only 14 bytes, which means when the chip DMAs to a 32-bit or 64-bit aligned buffer, the payload, which immediately follows the ethernet frame header, ends up on a 16-bit boundary, which is not what we want. You can fix this in one of two ways: if the chip allows it, you can offset the RX buffer address by two bytes and thereby force the payload to be 32-bit aligned, or you can copy the data to a new buffer with the right alignment. Having the chip do it for you is obviously the prefered approach. The chips supported by the fxp, xl, pcn, tl, ste, ti, sk, wx and lge drivers support this. The latter four are all gigE chipsets. Now, before any of you armchair geniuses out there start chiming in with your incredibly brilliant solutions for this problem which you just made up on the spot, forget it. This issue has been discussed to death and there's just no easy way around it. Terry Lambert and Alfred Perlstein, this means you. I mean it. Put down the keyboard and back away from the computer or *blam!* I'll shoot. > Now TX buffers are a problem - I have to take what I get and just > "deal with it". If both start address and length need to be aligned, > then I'm pretty much screwed - I have to copy... Most chips place no restrictions on the alignment of TX buffers. The only exceptions I know of where the chip API simply doesn't permit it are the RealTek 8139/if_rl (surprise) and the VIA Rhine I and Rhine II/if_vr. -Bill = -Bill Paul(925) 691-2800 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = "I like zees guys. Zey are fonny guys. Just keel one of zem." -- The 3 Amigos = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: NatSemi DP83820 gigE driver kit for 4.2 and 4.3
> > The OS wants the _payload_ to be aligned on a 32-bit boundary. It tries > > to do 32-bit accesses to the IP header, and the NFS code also does 32-bit > > accesses when trying to un-XDR NFS requests. > > Oh... I see... I guess you could grab an mbuf and copy just the IP > header for that, no? (Just curious at this point :-) That doesn't work for the NFS case: an XDR-encoded packet may contain lots of different fields separated by 32-bit length markers. Also, there's a religious issue, namely a violation of protocol boundaries. This is an ethernet driver: it's not supposed to have any really intimate knowledge of IP or TCP or UDP, so you really don't want to go mucking about with the frame payload if you can avoid it. (Lastly, my goal here is to make the card work, not re-write the innards of the networking stack or NFS. I really don't want intimate knowledge of IP, TCP or UDP either. :) > > But on other CPUs such as the alpha, SPARC, PPC and (I suspect) the > > IA-64, unaligned accesses in the kernel generate a fatal trap and a > > panic. In user space, an unaligned access may result in a bus error, > > unless the OS is kind enough to handle the trap, which I believe > > FreeBSD/alpha does. > > I don't think that is the case. I seem to remember FreeBSD Alpha 4.3 > sysinstall croaking on me once with an alignment error. No no: an unaligned access trap in the kernel is fatal, but an unaligned access trap in a *user-space* process is not. Once in a while you will see messages on the console about unaligned access traps generated by user programs, but these don't panic the system. In the case of FreeBSD/alpha, we fake it up so know about the problem but the process keeps running. Some OSes (e.g. Solaris) clobber the process with a SIGBUS. Some would argue the latter behavior is better since it makes it easier to find and fix what is probably a bug in the first place. -Bill -- = -Bill Paul(925) 691-2800 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = "I like zees guys. Zey are fonny guys. Just keel one of zem." -- The 3 Amigos = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Where to put new bus_dmamap_load_mbuf() code
Okay, I decided today to write a bus_dmamap_load_mbuf() routine to make it a little easier to convert the PCI NIC drivers to use the busdma API. It's not the same as the NetBSD code. There are four new functions: bus_dmamap_load_mbuf() bus_dmamap_unload_mbuf() bus_dmamap_sync_mbuf() bus_dmamap_destroy_mbuf() This is more or less in keeping with the existing API, except the new routines work exclusively on mbuf lists. The thing I need to figure out now is where to put the code. The current suggestion from jhb is to create the following two new files: sys/kern/kern_busdma.c sys/sys/busdma.h The functions are machine-independent, so they shouldn't be in sys///busdma_machdep.c. I mean, they could go there, but that would just result in code duplication. If somebody has a better suggestion, now's the time to speak up. Please let's avoid creating another bikeshed over this. Current code snapshot resides at: http://www.freebsd.org/~wpaul/busdma There's also a modified version if the Adaptec "starfire" driver there which uses the new routines. I'm running this version of the driver on a test box in the lab right now. -Bill -- ===== -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = "I like zees guys. Zey are fonny guys. Just keel one of zem." -- The 3 Amigos = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Where to put new bus_dmamap_load_mbuf() code
> > Another thing- maybe I'm confused- but I still don't see why you want to > require the creating of a map each time you want to load an mbuf > chain. Wouldn't it be better and more efficient to let the driver decide when > and where the map is created and just use the common code for loads/unloads? Every hear the phrase "you get what you pay for?" The API isn't all that clear, and we don't have a man page or document that describes in detail how to use it properly. Rather than whining about that, I decided to tinker with it and Use The Source, Luke (tm). This is the result. My understanding is that you need a dmamap for every buffer that you want to map into bus space. Each mbuf has a single data buffer associated with it (either the data area in the mbuf itself, or external storage). We're not allowed to make assumptions about where these buffers are. Also, a single ethernet frame can be fragmented across multiple mbufs in a list. So unless I'm mistaken, for each mbuf in an mbuf list, what we have to do is this: - create a bus_dmamap_t for the data area in the mbuf using bus_dmamap_create() - do the physical to bus mapping with bus_dmamap_load() - call bus_dmamap_sync() as needed (might handle copying if bounce buffers are required) - - do post-DMA sync as needed (again, might require bounce copying) - call bus_dmamap_unload() to un-do the bus mapping (which might free bounce buffers if some were allocated by bus_dmamap_load()) - destroy the bus_dmamap_t One memory region, one DMA map. It seems to me that you can't use a single dmamap for multiple memory buffers, unless you make certain assumptions about where in physical memory those buffers reside, and I thought the idea of busdma was to provide a consistent, opaque API so that you would not have to make any assumptions. Now if I've gotten any of this wrong, please tell me how I should be doing it. Remember to show all work. I don't give partial credit, nor do I grade on a curve. > > Yay! > > > > The current suggestion is fine except that each platform might have a more > > efficient, or even required, actual h/w mechanism for mapping mbufs. It might, but right now, it doesn't. All I have to work with is the existing API. I'm not here to stick my fingers in it and change it all around. I just want to add a bit of code on top of it so that I don't have to go through quite so many contortions when I use the API in network adapter drivers. > > I'd also be a little concerned with the way you're overloading stuff into mbuf > > itself- but I'm a little shakier on this. I thought about this. Like it says in the comments, at the device driver level, you're almost never going to be using some of the pointers in the mbuf header. On the RX side, *we* (i.e. the driver) are allocating the mbufs, so we can do whatever the heck we want with them until such time as we hand them off to ether_input(), and by then we will have put things back the way they were. For the TX side, by the time we get the mbufs off the send queue, we always know we're going to have just an mbuf list (and not an mbuf chain), and we're going to toss the mbufs once we're done with them, so we can trample on certain things that we know don't matter to the OS or network stack anymore. The alternatives are: - Allocate some extra space in the DMA descriptor structures for the necessary bus_dmamap_t pointers. This is tricky with this particular NIC, and a little awkward. - Allocate my own private arrays of bus_dmamap_t that mirror the DMA rings. This is yet more memory I need to allocate and free at device attach and detach time. I've got space in the mbuf header. It's not being used. It's right where I need it. Why not take advantage of it? > > Finally- why not make this an inline? Er... because that idea offended my delicate sensibilities? :) -Bill -- = -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = "I like zees guys. Zey are fonny guys. Just keel one of zem." -- The 3 Amigos = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Where to put new bus_dmamap_load_mbuf() code
> >My understanding is that you need a dmamap for every buffer that you want > >to map into bus space. > > You need one dmamap for each independantly manageable mapping. A > single mapping may result in a long list of segments, regardless > of whether you have a single KVA buffer or multiple KVA buffers > that might contribute to the mapping. Yes yes, I understand that. But that's only if you want to map a buffer that's larger than PAGE_SIZE bytes, like, say, a 64K buffer being sent to a disk controller. What I want to make sure everyone understands here is that I'm not typically dealing with buffers this large: instead I have lots of small buffers that are smaller than PAGE_SIZE bytes. A single mbuf alone is only 256 bytes, of which only a fraction is used for data. An mbuf cluster buffer is usually only 2048 bytes. Transmitted packets are typically fragmented across 2 or 3 mbufs: the first mbuf contains the header, and the other two contain data. (Or the first one contains part of the header, the second one contains additional header data, and the third contains data -- whatever.) At most I will have 1500 bytes of data to send, which is less than PAGE_SIZE, and that 1500 bytes will be fragmented across a bunch of smaller buffers that are also smaller than PAGE_SIZE. Therefore I will not have one dmamap with multiple segments: I will have a bunch of dmamaps with one segment each. (I can hear somebody out there saying: "What about jumbo frames?" Yes, with jumbo frames, I will have 9K buffers to deal with, and in that case, you could have one dmamap with several segments, and I am taking this into account with the updated code I've written.) > >So unless I'm mistaken, for each mbuf in an mbuf list, what we > >have to do is this: > > > >- create a bus_dmamap_t for the data area in the mbuf using > > bus_dmamap_create() > > Creating a dmamap, depending on the architecture, could be expensive. > You really want to create them in advance (or pool them), with at most > one dmamap per concurrent transaction you support in your driver. The only problem here is that I can't really predict how many transactions will be going at one time. I will have at least RX_DMA_RING maps (one for each mbuf in the RX DMA ring), and some fraction of TX_DMA_RING maps. I could have the TX DMA ring completely filled with packets waiting to be DMA'ed and transmitted, or I may have only one entry in the ring currently in use. So I guess I have to allocate RX_DMA_RING + TX_DMA_RING dmamaps in order to be safe. > >- do the physical to bus mapping with bus_dmamap_load() > > bus_dmamap_load() only understands how to map a single buffer. > You will have to pull pieces of bus_dmamap_load into a new > function (or create inlines for common bits) to do this > correctly. The algorithm goes something like this: > > foreach mbuf in the mbuf chain to load > /* >* Parse this contiguous piece of KVA into >* its bus space regions. >*/ > foreach "bus space" discontiguous region > if (too_many_segs) > return (error); > Add new S/G element > > With the added complications of deferring the mapping if we're > out of space, issuing the callback, etc. Why can't I just call bus_dmamap_load() multiple times, once for each mbuf in the mbuf list? (Note: for the record, an mbuf list usually contains one packet fragmented across multiple mbufs. An mbuf chain contains several mbuf lists, linked together via the m_nextpkt pointer in the header of the first mbuf in each list. By the time we get to the device driver, we always have mbuf lists only.) > Chances are you are going to use the map again soon, so destroying > it on every transaction is a waste. Ok, I spent some more time on this. I updated the code at: http://www.freebsd.org/~wpaul/busdma The changes are: - Tried to account for the case where an mbuf data region is larger than a page, i.e. when we have an mbuf with a 9K external buffer attached for use a jumbo ethernet frame. - Added routines to allocate a chunk of maps in a singly linked list, from which the other routines can grab them as needed. The driver attach routine calls bus_dmamap_list_init() with the max number of dmamaps that it will need, then the detach routine calls bus_dmamap_list_destroy() to nuke them when the driver is unloaded. The bus_dmamap_load_mbuf() routine uses the pre-allocated dmamaps from the list and bus_dmamap_list_destroy() returns them to the list when the transaction is completed. - Updated the modified if_sf driver to use the new code. Again, I've got this code running on the test box in the lab, so it's correct inasmuch
Re: Where to put new bus_dmamap_load_mbuf() code
> The fact that the data is less than a page in size matters little > to the bus dma concept. In other words, how is this packet presented > to the hardware? Does it care that all of the component pieces are > < PAGE_SIZE in length? Probably not. It just wants the list of > address/length pairs that compose that packet and there is no reason > that each chunk needs to have it own, and potentially expensive, dmamap. Maybe, but bus_dmamap_load() only lets you map one buffer at a time. I want to map a bunch of little buffers, and the API doesn't let me do that. And I don't want to change the API, because that would mean modifying busdma_machdep.c on each platform, which is a hell that I would rather avoid. > >Why can't I just call bus_dmamap_load() multiple times, once for > >each mbuf in the mbuf list? > > Due to the cost of the dmamaps, the cost of which is platform and > bus-dma implementation dependent - e.g. could be a 1-1 mapping to > a hardware resource. Consider the case of having a full TX and RX > ring in your driver. Instead of #TX*#RX dmamaps, you will now have > three or more times that number. > > There is also the issue of coalessing the discontiguous chunks if > there are too many chunks for your driver to handle. Bus dma is > supposed to handle that for you (the x86 implementation doesn't > yet, but it should) but it can't if it doesn't understand the segment > limit per transaction. You've hidden that from bus dma by using a > map per segment. Ok, a slightly different question: what happens if I call bus_dmamap_load() more than once with different buffers but with the same dmamap? > >(Note: for the record, an mbuf list usually contains one packet > >fragmented across multiple mbufs. An mbuf chain contains several > >mbuf lists, linked together via the m_nextpkt pointer in the > >header of the first mbuf in each list. By the time we get to > >the device driver, we always have mbuf lists only.) > > Okay, so I haven't written a network driver yet, but you got the idea, > right? 8-) Just don't get 3c509 and 3c905 misxed up and we'll be fine. :) > >- Added routines to allocate a chunk of maps in a singly linked list, > > from which the other routines can grab them as needed. > > Are these hung off the dma tag or something? dmamaps may hold settings > that are peculuar to the device that allocated them, so they cannot > be shared with other clients of bus_dmamap_load_mbuf. It's a separate list. The driver is reponsible for allocating the head of the list, then it hands it to bus_dmamap_list_alloc() along with the required dma tag. bus_dmamap_list_alloc() then calls bus_dmapap_create() to populate the list. The driver doesn't have to manipulate the list itself, until time comes to destroy it. -Bill -- = -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = "I like zees guys. Zey are fonny guys. Just keel one of zem." -- The 3 Amigos = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Where to put new bus_dmamap_load_mbuf() code
> >Maybe, but bus_dmamap_load() only lets you map one buffer at a time. > >I want to map a bunch of little buffers, and the API doesn't let me > >do that. And I don't want to change the API, because that would mean > >modifying busdma_machdep.c on each platform, which is a hell that I > >would rather avoid. > > bus_dmamap_load() is only one part of the API. bus_dmamap_load_mbuf > or bus_dmamap_load_uio or also part of the API. They just don't happen > to be impmeneted yet. 8-) Perhaps there should be an MD primitive > that knows how to append to a mapping? This would allow you to write > an MI loop that does exactly what you want. Any one of those ideas would be just fine. I eagerly await their realization. :) > >It's a separate list. The driver is reponsible for allocating the > >head of the list, then it hands it to bus_dmamap_list_alloc() along > >with the required dma tag. bus_dmamap_list_alloc() then calls > >bus_dmapap_create() to populate the list. The driver doesn't have > >to manipulate the list itself, until time comes to destroy it. > > Okay, but does this mean that bus_dmamap_load_mbuf no longer takes > a dmamap? Drivers may want to allocate/manage the dmamaps in a > different way. Yes, bus_dmamap_load_mbuf() accepts a dma tag, the head of the dmamap list, an mbuf, an segment array and a segment count. The Driver allocates the segment array with a certain number of members. It passes the array and segment count to bus_dmamap_load_mbuf(), which treats the segment count as the maximum number of segments that it can return to the caller. Once all the mappings have been done, it updates the segment count to indicate how many segments were actually needed. Then the driver transfers the info from the segment array into its DMA descriptor structures and kicks off the DMA operation. Once the device signals the transfer is done, the driver calls bus_dmamap_unload_mbuf() and bus_dmamap_destroy_mbuf() to unload the maps and return them to the map list for later use. It isn't until the driver calls bus_dmamap_list_destroy() that the dmamaps are actually released and the list free()ed. -Bill -- = -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = "I like zees guys. Zey are fonny guys. Just keel one of zem." -- The 3 Amigos = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Patches for Conexant LANfinity support
Phil Kernick ([EMAIL PROTECTED]) has been kind enough (and brave enough) to sit down and produce patches for the dc(4) driver to add support for the Conexant LANfinity miniPCI fast ethernet controller. Those of you that have laptops with this chipset can test the patches at: http://www.freebsd.org/~wpaul/conexant.patch.gz http://www.freebsd.org/~wpaul/conexant_5.0.patch.gz The latter file is for 5.0-current, the former for -stable. Apply the patch as follows: # cd /tmp # fetch http://www.freebsd.org/~wpaul/conexant.patch.gz # gunzip conexant.patch.gz # cd /sys/pci # patch < conexant.patch Then compile a new kernel and/or if_dc.ko kernel module. I intend to commit the patch for -current when I get back to work next week, however the patch for -stable will probably have to wait until the code freeze for 4.4-RELEASE is lifted (sorry guys). In the meantime, success/failure/whatever reports would be much appreciated. -Bill -- ==== -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems "I like zees guys. Zey are fonny guys. Just keel one ofzem." -- The 3 Amigos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Need testers, Broadcom BCM570x gigE driver
Ok, it's taken some doing, but I finally have a preliminary driver for the Broadcom BCM570x gigE controllers ready for testing. The code is at: http://www.freebsd.org/~wpaul/Broadcom/4.x This is for people with the following hardware: 3Com 3c996-T gigE NIC SysKonnect 9D21 gigE NIC Dell PowerEdge 2550 server with integrated BCM5700 I should have a FreeBSD 5.0-current driver ready soon (like, probably tomorrow). For now, only the source is available, and you need to perform the following steps to use it: 1) Install FreeBSD 4.3-RELEASE or later 2) Make sure you have the kernel source installed in /usr/src 3) Copy brgphy.c and brgphyreg.h to /sys/dev/mii. These files replace the copies that are already there. (You can save the older versions if you want.) 4) mkdir /sys/dev/bge 5) Copy if_bge.c and if_bgereg.h to /sys/dev/bge 6) Edit /sys/conf/files and add the following line: dev/bge/if_bge.coptional bge 7) Edit your kernel config file (e.g. /sys/i386/conf/MYKERNEL) and add the following line device bge # Broadcom BCM570x gigabit ethernet 8) Config and compile a new kernel Preliminary tests have yielded the following results: TCP, normal size frames: 440Mbps TCP, jumbo frames: 650Mbps UDP TX, normal frames: 710Mbps UDP TX, jumbo frames: 915Mbps Hardware checksum offload is enabled by default. These tests were done with the card in a 64-bit PCI slot. Anyone who has one of these cards and can test this driver for me, please do so and let me know your results. There may be one or two rough edges, so don't be too surprised if you run into an unusual problem. Only problem I've observed so far: on my 32-bit test box, RX checksum offload sometimes didn't behave right. To disable checksum offload, #define BGE_CSUM_FEATURES to 0, then recompile. -Bill -- ===== -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = "I like zees guys. Zey are fonny guys. Just keel one of zem." -- The 3 Amigos = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Need testers, Broadcom BCM570x gigE driver
Ack. Ok, I realized that I forgot to upload a couple of files to http://www.freebsd.org/~wpaul/Broadcom/4.x yesterday. The brgphy driver needs an updated version of the miidevs file, and the ones generated from it. I have placed these on the web site along with all the other stuff. In addition to the steps I mentioned yesterday for installing the driver, you'll need to copy the updated miidevs files to /sys/dev/mii. Also: if you're going to perform tests, please tell me everything about how you do them. Tell me what hardware you're using. Tell me exactly which card you have. Tell me what software you're using to perform tests. If you observe a problem, don't evaluate it for me: just tell me what you see and let me work it out. I don't want to hear people say "it drops packets." Tell me how you observed the packets being dropped. I'm going to cook up a -current version of the code presently. Watch this space. -Bill -- ===== -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = "I like zees guys. Zey are fonny guys. Just keel one of zem." -- The 3 Amigos = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Need testers, Broadcom BCM570x gigE driver
There is now a -current version of the bge driver at the following URL: http://www.freebsd.org/~wpaul/Broadcom/5.x The brgphy driver in -current has already been updated so support the BCM5401 and BCM5411 PHYs, so no other changes are necessary. Share and enjoy. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: any reason to use m_devget in the "dc" driver ?
> I probably missed some emails ? And you can't go back and read them from the archives because...? > In any case i was only concerned about the additional copy > done by m_devget when the controller can already DMA into > an mbuf, and there are no alignment constraints. I don't know what you're talking about. There are no cases where we use m_devget() when there *aren't* any alignment constraints. Show us exactly what line of code you're talking about please, otherwise drop this topic, because it's been discussed to death and I'm tired of somebody trying to argue it with me every few months. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: TCP&IP cksum offload on FreeBSD 4.2
> > On the other hand, the Tigon III > > is capable of 960 megabits -- about the wire rate limit -- > > with normal size packets, if you implement software interrupt > > coelescing (which doesn't help, unless you crank the load up > > to close to wire speed and/or do more of the stack processing > > at interrupt time). I've been able to get 906Mbps between two Dell PowerEdge 2550 servers with built-in BCM5700/Tigon III chipsets with a stock FreeBSD kernel and the bge driver. > Having downloadable firmware is actually a huge advantage. You can do > things with the Tigon II that just aren't possible with any other chip, > either because they don't have downloadable firmware, or because the vendor > won't release firmware source. > > This is a problem with the Broadcom Tigon III boards, and to some extent > with the Tigon II. Basically it looks like the firmware for the Tigon II > is very hard to get now that 3Com has control of it, and I don't think > Broadcom will release the Tigon III firmware. (Assuming it is a > firmware-based chip.) I still have a copy of the last release of the Tigon II firmware and the development environment (which is what I used to generate the firmware image included with FreeBSD). As for the Tigon III, there is a default firmware image included in the EEPROM on the card, which is auto-loaded when the chip powers up. It is possible for a driver to load a custom image into the NIC's memory which will override the auto-loaded one, and it's also possible to load a new image into the EEPROM, however this requires an additional manual on top of the BCM5700 driver developer's guide as well as the firmware development kit, which you can only get from Broadcom/3Com/whatever under NDA. These custom images are called "value-add" firmware which are used to provide features like TCP segmentation, which you can't do with the default firmware image. Note that the BCM5700/Tigon III only has a limited amount of on-board RAM (256KB, I think). You're supposed to be able to attach up to 16MB of static SRAM to the BCM5700. The BCM5701 doesn't support external SSRAM at all, which I find a little confusing. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Driver kit for BCM570x gigE NICs
I have made a driver retrofit kit available for Broadcom BCM570x-based gigabit ethernet cards at the following URL: http://www.freebsd.org/~wpaul/Broadcom/4.x/bcm570x_drv.tar.gz This kit contains source and pre-compiled driver modules for FreeBSD 4.3-RELEASE and later. This should make it easier for people to test the bge driver on existing 4.x systems without having to recompile the kernel. Again, I would appreciate hearing from people who have cards that use this chipset and can test the driver. If you can run speed tests with things like netperf, ttcp or just plain file/data transfers, I'd be interested to see the results. Share and enjoy! -Bill -- ===== -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = "You stole fizzy lifting drinks. You broke the rules. You LOSE." -W. Wonka = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: TCP&IP cksum offload on FreeBSD 4.2
> Hi, > I'm using the Netgear GA620 Gig ethernet NIC with Tigon II chip. > > Do you know if it is possible to increase the buffer size for standard sized > ethernet frames from 512 buffers to say, 1024? > > I assume I'd have to modify the firmware and the host driver to accomodate > these buffers. I dont plan to use Jumbo frames at all, and I can reduce the > buffers allocated for them if necessary. You would need to change the firmware in order to increase the size of any of the RX rings. All of the Tigon II manuals and a snapshot of my firmware development tree is at the following URL: http://www.freebsd.org/~wpaul/Alteon Note that I'm not sure how this will affect the layout of data structures in the NIC's on-board SRAM. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Ax88172 vs FreeBSD USB stack
So. I picked up a Linksys USB200M USB 2.0 ethernet adapter that uses the ASIX Electronics AX88172 chip, and I started cobbling together a driver. This chip uses a series of vendor specific commands to do things like read/write the MII management interface on the MAC, read/write the SROM, set the RX filter, multicast hash table, etc. I can do all this no problem. The Linksys NIC uses a RealTek 8201L PHY, and I can attach it and negotiate a link. However I can't send or receive any packets. Like all the other USB NICs, packet transfer is supposed to done via bulk in/bulk out endpoints, and I can open these endpoints and initiate transfers just fine, but nothing ever happens. Transmit attempts don't yield any packets on the wire, and I never get any RX transfer completions. (I can see the activity LED on the NIC blink when a frame arrives though.) One thing I have not attempted to do yet (but may try this weekend) is to directly read the RX or TX SRAM (there are commands to let you do this). Frankly, I'm a bit stumped. It looks as though I'm doing everything correctly, but I can't explain why the bulk transfers don't work. Clearly, the control endpoint works, since I can issue commands. There doesn't appear to be any special command that one has to issue to enable/disable the receiver or transmitter on the MAC. I have only one possible explanation. The manual for the AX88172 (http://www.freebsd.org/~wpaul/ASIX/Ax88172.PDF) says the following: "The AX88172 supports 2 interfaces, the interface 0 is Data Interface and interface 1 is for Communication interface." However the USB stack disagrees with the manual on this point: it steadfastly insists that configuration 1 has only 1 interface. So my question, for any USB gurus out there, is: is it possible that the USB stack is wrong on this point, and I really need to be using interface 1 for bulk in/out transfers? I'm a little suspicious at this point, because the stack can't seem to even read the device ID string correctly. (It identifies the chip only as "vendor 0x77b, device 0x2226".) -Bill -- ===== -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = "If stupidity were a handicap, you'd have the best parking spot." = ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ax88172 vs FreeBSD USB stack
> On Fri, Mar 28, 2003 at 11:16:55AM -0800, Maksim Yevmenkin wrote: > > Just FYI > > > > ng_ubt(4) (/sys/netgraph/bluetooth/drivers/ubt) driver > > (Bluetooth USB devices) makes use of two interfaces. > > >From a look into the driver these interfaces serve different > protocols. > I asume they are unrelated from a logical standpoint, but I don't > know bluetooth technology. > We have a similar situation with ulpt, where we usually have up > to three interfaces with different capabilities. > ulpt currently pics one of them, but we could also have three different > ulpt instances taking each one of them. The uplcom driver also uses two interfaces, but in that case, they put the interrupt endpoint on interface 0 and the bulk in/out endpoints on interface 1. When I saw that the AX88172 manual said that the device was supposed to have two interfaces, I wondered if maybe it had a similar setup, but I couldn't figure out how to access the second interface structure. For that matter, I didn't know for sure how to tell if it actually had one. (Sometimes manuals lie.) Hopefully when I try usbutils when I get home after work, I will learn more. > Well the AC88172 PDF is very clear about having 2 interfaces. > The document also speaks about 4 endpoints, which I expect to be on > interface 0 as they also have listed endpoint number 0 - they don't > tell in the document. > What I currently don't know is why there are 2 interfaces. > The document also mentions some homenet capabilities on RJ11 - whatever > it means. The AX88172 supports both regular ethernet and HomePNA (ethernet over cat3 telephone wiring) transceivers. You don't need a second USB interface for this though: you send/receive packets the same way regardless of what kind of transceiver you have. (The ADMtek Pegasus (if_aue) supports the same feature and only uses one set of endpoints.) > Maybe it's an hardware optional interface, which is disabled in this > special device. > > For the ID strings - it seems that the hardware vendor just left the > string empty in the eeprom. There is a UQ_NO_STRINGS quirk for this. Perhaps I should use it. -Bill -- = -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = "If stupidity were a handicap, you'd have the best parking spot." = ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ax88172 vs FreeBSD USB stack
Ok, I figured it out. Turns out the AX88172 only has one interface after all, in spite of what the manual says. Maybe the info about the second interface was a holdover from the AX88170 datasheet which they forgot to expunge. Or maybe ASIX is on crack. Anyway, I discovered I was doing two things wrong: 1) The RX control register has to be set correctly to enable the RX filter on the MAC. The AX88172 datasheet doesn't tell you what the bits in the RX control byte mean. The AX88170 datasheet does, but only documents bits 0 through 4. It forgets to mention that you must also turn on bit 7. If you don't set this bit, you don't receive any packets. 2) For transmission, you must initialize the three inter-packet gap (IPG) registers correctly. They are unset by default, and until they are set, the MAC won't send any frames. Now that I fixed these two things, the driver works. In fact, I'm using it to type this e-mail right now. :) I uploaded a copy to: http://www.freebsd.org/~wpaul/ASIX/USB All it really needs is for me to fix the multicast filtering. Right now, it defaults to all multicast mode. I need to fill in the axe_setmulti() function so that it sets up the hash table correctly. I think I also need to fix promisc mode. This code is for 5.0-RELEASE or better. -Bill -- ===== -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = "If stupidity were a handicap, you'd have the best parking spot." = ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Rrrrrr.....
Ok, I've gotten enough e-mail about this now that it's starting to be annoying, so I'm going to nip this in the bud right now. People have started asking me about the Broadcom 4400 series chips. They have noticed that there's this "if_bge" driver with the word "Broadcom" associated with it, and seem to think it may somehow be coerced into working with the 44xx chipset, even though the documentation implies nothing of the sort. So everybody listen up: *NO*, the 44xx chips are *NOT* the same as the 57xx chips. The 57xx devices are 10/100/1000. The 44xx are 10/100 *ONLY*. *NO* they do *NOT* have the same programming API. *NO*, the bge(4) driver will *NOT* work with the 44xx chips. Ever. I don't care how much you whine. *NO* I don't have any programming manuals for the 44xx chips and don't know (or care) if I ever will. *NO* I will *NOT* port the Linux driver to FreeBSD. Is everyone clear on this now? Good, because any further questions along these lines will be summarily ignored. -Bill -- = -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = "If stupidity were a handicap, you'd have the best parking spot." = ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Looking for RealTek 8169-based NIC for testing
I've decided to pick up one of the projects I let lapse some time ago, which was to add support for the RealTek 8139C+ chipset to the rl(4) driver. The 8139C+ is, by default, backwards compatible with the 8139A/B/C/D/etc... but also supports a descriptor-based DMA mechanism, TCP/IP checksum offload, VLAN tagging and extraction, and TCP large send. RealTek also has an 8169 gigabit ethernet chipset with almost the same programming mechanism as the 8139C+, so I decided to support that too. However, while I have a sample 8139C+ NIC for testing, I don't have an 8169 gigE card. I can probably pick one up, but I don't know who sells cards with this chip on it. If anyone can positively identify a card that has uses this chip, i.e. from D-Link, Netgear, or whoever, I'd appreciate it if you could point it me at it. If it's something that can quickly be acquired from CompUSA, even better. Note: RealTek also has an 8110 LOM (Lan On Motherboard) chip, which I _think_ is register compatible with the 8169, however I don't want to buy a whole new motherboard. Ultimately, I may need to find someone who does have one of these so they can verify that the driver does in fact work with it though, so if you've got one, save this e-mail and watch for a call for testers. -Bill -- = -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = "If stupidity were a handicap, you'd have the best parking spot." = ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Call for testers: rl(4) optimized for 8139C+
Somehow I doubt I'm going to get a lot of responses to this, since I'm not sure how many people besides me actually have an 8139C+ NIC. That said, if you have one, and you're running FreeBSD 5.1 or later, please try the driver code at: http://www.freebsd.org/~wpaul/RealTek/cplus If you actually have a C+ card, it will show up like this: rl0: port 0xc000-0xc0ff mem 0xdc001000-0xdc0010ff irq 11 at device 13.0 on pci0 rl0: Ethernet address: 00:e0:4c:00:00:1b miibus5: on rl0 rlphy0: on miibus5 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Also, ifconfig rl0 will show this: rl0: flags=8802 mtu 1500 options=1b The 8139C+ uses real descriptor-based DMA and actually exhibits pretty good performance. (With my Athlon 900Mhz test machine, I can achieve 143000 frames/sec raw transmit speed.) This driver supports the following features: - RX and TX descriptor lists - RX and TX TCP/IP checksum offload - RX and TX hardware vlan tagging - TX interrupt moderation (using the 8139C+'s on-board timer) The chip supports TCP large send, but there's no driver support for that because there's no way to exploit it in FreeBSD. The chip also supports two TX DMA queues (normal and high priority), but the driver only takes advantage of one. If you have a -current system, please compile this code with -DNEW_BUSDMA_API (this enables the use of the two new arguments to the bus_dma_tag_create() function which appeared a couple of days ago). I'm mostly looking for performance reports and success/failure reports concerning VLANs. (I don't have an easy way to test the VLAN support at home. I think I did everything right, but I want to be sure before I commit to the tree.) There is preliminary support for the 8169 gigE chip, but I don't have a card to test with, so don't expect RealTek gigE NICs to work yet. Lastly, I'm also interested to see just what NICs are out there that use the 8139C+. The only way to spot the presence of such a chip raw transmit speed.) This driver supports the following features: - RX and TX descriptor lists - RX and TX TCP/IP checksum offload - RX and TX hardware vlan tagging - TX interrupt moderation (using the 8139C+'s on-board timer) The chip supports TCP large send, but there's no driver support for that because there's no way to exploit it in FreeBSD. The chip also supports two TX DMA queues (normal and high priority), but the driver only takes advantage of one. If you have a -current system, please compile this code with -DNEW_BUSDMA_API (this enables the use of the two new arguments to the bus_dma_tag_create() function which appeared a couple of days ago). I'm mostly looking for performance reports and success/failure reports concerning VLANs. (I don't have an easy way to test the VLAN support at home. I think I did everything right, but I want to be sure before I commit to the tree.) There is preliminary support for the 8169 gigE chip, but I don't have a card to test with, so don't expect RealTek gigE NICs to work yet. Lastly, I'm also interested to see just what NICs are out there that use the 8139C+. The only way to tell if you have the chip is to check the part number on it. (It should in fact say 8139C+.) I hope RealTek has actually sold this chip well, because it actually seems to perform really well. -Bill -- = -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = "If stupidity were a handicap, you'd have the best parking spot." = ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
MCT USB<->RS232 driver
While wandering around CompUSA today, I came upon what I consider to be an incredibly useful little device: the Targus USB mobile port replicator with ethernet. This device is basically a multi-port USB hub with a bunch of peripherals attached, including: - PS/2 keyboard port - PS/2 mouse port - parallel printer port - RS-232 serial port - 10/100 ethernet port - Two USB 1.1 ports for any other USB devices you care to use For someone like me, who owns a 'legacy free' laptop that has no parallel or serial ports, or external keyboard/mouse ports, this struck me as a pretty clever idea. When I got it home, I found that almost everything is supported in FreeBSD 5.x, except for one thing: the serial port. The chip is a MCT USB-232 device, which is supported in NetBSD, but not FreeBSD. Not to be denied, I grabbed the umct(4) driver from NetBSD and got it working well enough that I can run userland PPP over it with my US Robotics external 56K modem. (If fact, I'm composing this e-mail over it right now.) It's not perfect. One major problem is that unlike all the other USB serial devices, this one provides incoming data via the interrupt endpoint instead of the bulk IN endpoint. Somehow in NetBSD, both the ucom(4) support module and the driver itself are able to read from the interrupt endpoint, but this trick doesn't work in FreeBSD. Consequently, I had to kludge things up to stuff data into the terminal device from the umct(4) driver's interrupt pipe handler. This is messy, but it works. It anyone else wants to use this driver, you can download it from: http://www.freebsd.org/~wpaul/MCT/mct.tar.gz To use it, download the tarball, then do the following: # cd /sys # cat /path/to/mct.tar.gz | gzip -d | tar -xvf - # cd modules/umct # make; make install; make load You need the ucom(4) module loaded as well. I'm not going to commit this yet because there's one thing I haven't been able to test, which is that I'm not sure how this device is supposed to signal changes in the modem status register. It's supposed to signal changes via the interrupt pipe, but I don't see how that can work if the interrupt pipe is also being used for incoming data. There's no easy way for me to figure it out either since I have no datasheet for this chip. In the meantime, I consider this useful enough that I should make it available for others who might have a USB<->RS232 adapter with the same chip. Share and enjoy! -Bill -- = -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = "If stupidity were a handicap, you'd have the best parking spot." = ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: MCT USB<->RS232 driver
> Bill Paul wrote this message on Sun, Jul 06, 2003 at 21:36 -0700: > > When I got it home, I found that almost everything is supported in > > FreeBSD 5.x, except for one thing: the serial port. The chip is a > > MCT USB-232 device, which is supported in NetBSD, but not FreeBSD. > > > > Not to be denied, I grabbed the umct(4) driver from NetBSD and got > > it working well enough that I can run userland PPP over it with my > > Anything wrong with umct in -current? (scottl commited it just 9 days > ago.) Or is this a different driver that is not compatible? Argh. Yes, this is the same device. And yes, Scott's driver is much nicer than the monstrosity I created. I need to update my local copy of the -current USB code more often. :/ Ah well. At least now this port expander is fully supported. -Bill ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: MCT USB<->RS232 driver
> In message: <[EMAIL PROTECTED]>
> [EMAIL PROTECTED] (Bill Paul) writes:
> : When I got it home, I found that almost everything is supported in
> : FreeBSD 5.x, except for one thing: the serial port. The chip is a
> : MCT USB-232 device, which is supported in NetBSD, but not FreeBSD.
>
> But Scott Long already committed his umct driver a few days ago... :-)
>
> Warner
>
Yes, so I have been told. :P
And guess what. It has a bug. :)
Well ok, to be fair, it doesn't really have a bug: it lacks a workaround
for a buggy chip. The driver determines the bulk output buffer size
by checking the data returned by the chip in its bulk out endpoint
descriptor. This is right in most cases, but not for the
USB_PRODUCT_MCT_SITECOM_USB232 device (which, unfortunately, is what
they put in the port replicator I bought). The value it returns for
wMaxPacketSize is 32, but in reality, you must use 16. If you don't,
the chip drops data under certain circumstances. A good example: attach
a modem to the serial adapter and set up a PPP link over it, then try
to ssh to a remote host somewhere. Ssh will get about halfway through
the connection attempt and then hang. I observed a similar problem
with my IRC client.
It turns out the NetBSD driver that I hacked up worked because it has
a workaround for this chip bug. I applied a similar workaround to Scott's
driver and now PPP works again. Here's a patch:
--- umct.c.orig Thu Jul 3 18:50:39 2003
+++ umct.c Mon Jul 7 00:52:55 2003
@@ -241,7 +241,10 @@
if (UE_GET_DIR(ed->bEndpointAddress) == UE_DIR_OUT) {
ucom->sc_bulkout_no = ed->bEndpointAddress;
- ucom->sc_obufsize = UGETW(ed->wMaxPacketSize);
+ if (uaa->product == USB_PRODUCT_MCT_SITECOM_USB232)
+ ucom->sc_obufsize = 16; /* device is broken */
+ else
+ ucom->sc_obufsize = UGETW(ed->wMaxPacketSize);
continue;
}
This is almost literally what NetBSD does. Barring any objections, I'd
like to check this in. (CC'ing Scott on this e-mail.)
-Bill
--
=
-Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu
[EMAIL PROTECTED] | Wind River Systems
=
"If stupidity were a handicap, you'd have the best parking spot."
=
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Nvidia Licensing Question
> Hi, > > I was talking to someone recently about why there isn't > support for Nvidia's Nforce drivers under FreeBSD yet. > > He said: > > "This might have something to do with the fact that the NIC driver is not > GPL licensed. See the "License" section of the nForce Linux readme: [...] It has nothing to do with licensing. The NIC driver is _NOT_ provided in source code form. Yes, they may have stuck it in a section that says 'driver source code,' but if you actually download it and look at it, you'll find that all of the brains of the driver is inside an object module for which there is no source code. If the driver source code was available, then one of two things would occur: - We would discover that the chip is in fact not nVidia's own design, but a some other vendor's design which they have licensed (this is what they did previously, when they licensed a NIC from 3Com). If this turned out to be the case, and the NIC is already supported by another FreeBSD driver, we could tweak it to handle nVidia's chip. - We would be able to strip out all of the register and DMA structure info from the Linux driver and write a FreeBSD driver (assuming the engineer who wrote the driver didn't try to obfuscate the code or was lazy about transcribing register info from the programming manual). I would prefer being able to just get the programming manual from nVidia and write a driver from scratch, but I don't have any nVidia contacts or any info about why nVidia is being such a pain in the ass about releasing info concerning this NIC. -Bill -- = -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = "If stupidity were a handicap, you'd have the best parking spot." = ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
nVidia nForce2 potential owners please read
___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
nVidia nForce2 potential owners please read (take two)
This only made it to one list the first time, trying again. These newfangled computer things clearly can't be trusted. - Ok, so, it occured to me recently to try to convince nVidia to cough up programming documentation for their MCP ethernet controller. However, in order to do that, I need to be able to show that there is in fact sufficient demand for a FreeBSD (or even NetBSD or OpenBSD) driver to make it worth their while. nVidia doesn't listen to end users, only OEMs, and if the OEMs don't ask for support for a given OS, then support will not materialize. My goal is to convince them to pull their heads far enough out from between their legs to realize that Linux is not the be-all, end-all of open source, and that just because OEMs haven't mentioned FreeBSD, NetBSD or OpenBSD by name doesn't mean there aren't people who want MCP ethernet support in BSD. For this, I need your help. What I need is to gather proof of demand. What I want you do to is e-mail me (oh god, I can't believe I'm setting myself up for this) if: - You wanted to purchase a computer system with an nVidia nForce2 chipset but _didn't_ once you realized there was no BSD driver support for the on-board ethernet. - You bought an nVidia nForce2 system without realizing the on-board ethernet wasn't supported in BSD, were really disappointed once you found out, and complained to the manufacturer _OR_ you wanted to complain but didn't (because you weren't sure who to complain to, or you didn't get around to it yet, or you forgot, or you were abducted by aliens, or your dog ate your homework, or whatever). - You are in a position to approve or recommend the purchase of a computer system (or several systems) for your company, research group, espionage organization or other institution with money to spend, but won't because there's no BSD driver support for the on-board ethernet. - You never heard of nVidia, the nForce2 or the MCP ethernet controller until I mentioned them, but now that you have, and you've gone out and searched the interweb or visited your local computer store, you think they're all really spiffy and would happily buy an nForce2 system, but will hold off until there's a BSD driver for the on-board ethernet. - You want to give me free large bags of cash. Do *NOT* e-mail me if: - You want me to help you transfer a large sum of money out of Nigeria or some other African nation. - You think I'm dying of cancer and my dying wish is to collect e-mails from all over the world. - You think I want to MAKE MONEY FAST (if I wanted to do that, I wouldn't be writing device drivers for free). - You work for SCO or the RIAA. I think you get the idea. Consider it a petition of sorts. All I need is an e-mail from you, with a line or two explaining your particular circumstances. If you did not buy an nForce2-based computer due to lack of BSD support, say so. If you did, but you were pissed by the lack of BSD support, say so. If you told your friends, relatives, cow-orkers or purchasing office not to buy nForce2-based computers because of the lack of BSD support, say so. Cite the OEM vendor of the computer (or computer) and the model (or models) where appropriate. If more than one computer was involved, say how many. Every lost sale or dissatisfied customer I can present as evidence makes it that much easier to convince nVidia to unclench its tight... fists... and provide the documentation needed to write a BSD driver. NOTE: Please do make up phony e-mails just to bloat the figures or or cobble together a perl script to send me hundreds of auto-generated messages from forged addresses. Play nice, you scum. So, send your cards and letters to [EMAIL PROTECTED] And don't be afraid to spread the word. Ask other people on other mailing lists. Ask your friends. Ask your enemies. Ask not what your OS can do for you: ask what you can do for your OS. -Bill -- = -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = "If stupidity were a handicap, you'd have the best parking spot." = ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Update on nVidia/MCP ethernet
First off, response to my announcement has been amazing. I've received 150 e-mails so far, and they're still coming. Thanks to everyone who has responded. An extra special thanks to those people who agreed to talk to contacts they have within nVidia. I'm still waiting for for info from these people. As soon as I learn something new, I'll pass it along. I have also made some progress on another front. It occured to me that since nVidia is known for GPU expertise rather than networking expertise that maybe their 'proprietary design' wasn't really anything of the sort. Well, I was right: what nVidia calls "MCP ethernet" is really a Conexant CX25870/1 "jedi" controller. I have contacted Conexant and am in the process of trying to obtain a copy of the programming manual for this device. There are some NDA issues to deal with, however I've been told they will not prevent me from releasing driver source. I hope to get this resolved soon. Stay tuned. -Bill -- ===== -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = "If stupidity were a handicap, you'd have the best parking spot." = ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: MIIBUS_MEDIAINIT method
> Hi! > > I was just thinking about the purpose of this method... What is it? > > It used to be used by NIC drivers to add something like AUI beside MII > provided media, correct? It is _still_ used that way. See if_xl.c. There exists a 3c905B-Combo card which supports a 10/100 RJ-45 port, a 10Mbps-only BNC port and a 10Mbps only AUI port. Why did I concoct MEDIAINIT for this? Because each device can have only one ifmedia structure. When a driver uses miibus, the ifmedia struct is initialized by the underlying PHY driver, and that initialization does not happen until after we leave the MAC driver's attach routine. It's not a problem to add additional media types to the ifmedia struct later, but we need to have the PHY driver call back to the MAC driver to do this, which is why every PHY driver has a call to MIIBUS_MEDIAINIT() in its attach routine. If the parent MAC driver does not implement this method, nothing happens. But if it does implement this method, the parent can use it to do some extra ifmedia_add()s to tack on some extra media types. > But it looks like every PHY's driver thinks it must call MEDIAINIT in its > attach() routine. So, if there would be two PHY on MII (can this happen?), Yes, though it's rare, and not always useful. > then the method will be called twice, and some NIC drivers (tx, xl, dc, > maybe more) will not behave well. They work fine if the author of the MAC driver was smart enough to check for this in his mediainit method and just return immmediately if the auxilliary media types have already been ifmedia_add()ed. Right now, the only card that uses this feature is the 3c905B-Combo, and its hardware configuration does not permit the sort of edge condition you are fretting over. > Isn't it reasonable to stop all PHY drivers from calling MEDIAINIT, and > call it once per miibus instance in miibus_attach() or miibus_probe() > instead? No. We want the PHY driver to set up its media types in the ifmedia struct first, and then add our own after those, which means we have to wait until the end of the PHY's attach routine, and it's newbus that calls the attach routines, not the miibus code. If you have a card or hardware configuration which is actually causing the scenario you describe, then say so. Otherwise, keep your fingers out of this code. No user-servicable parts inside. Keep out of children. Do not look into laser optics with remaining eye. -Bill -- ===== -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = God was my co-pilot, until we crashed in the mountains and I had to eat him. = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Call for testers: SysKonnect gigabit ethernet driver
This is a call for testers for yet another gigabit ethernet driver. If you happen to have a SysKonnect gigabit ethernet server adapter and want to use it with FreeBSD, then please try the driver code at: http://www.freebsd.org/~wpaul/SysKonnect Currently I only have a driver for FreeBSD 3.0 and up. The following cards are supported: - SK-9841 1000baseLX, single port, single mode fiber - SK-9842 1000baseSX, single port, multimode fiber - SK-9843 1000baseLX, dual port, single mode fiber - SK-9844 1000baseSX, dual port, multimode fiber Yes, that's right: dual port gigabit ethernet. :) SysKonnect's driver software currently only uses the dual port adapters in a failover configuration, where the second port is monitored by the driver and only activated if the link on the primary port fails. This driver doesn't use that approach: instead, both ports are treated as separate and independent logical network interfaces. This means you should see something like the the following: skc0: rev 0x10 int a irq 11 on pci0.14.0 skc0: SysKonnect SK-NET Gigabit Ethernet Adapter SK-9844 SX dual link sk0: at skc0 port 0 sk0: Ethernet address: 00:00:5a:98:21:6c sk1: at skc0 port 1 sk1: Ethernet address: 00:00:5a:98:21:6d Yes, you can have both interfaces up and running at once. The SysKonnect cards use the XaQti XMAC II gigabit ethernet MAC and a controller designed by SysKonnect called the GEnesis. It is the GEnesis controller that provides all the PCI logic, plus other functions. The GEnesis controller can have up to two XMACs connected; single port cards have only one, of course. Information about the cards, including programming manuals for the GEnesis controller, can be found at http://www.syskonnect.com. The datasheet for the XaQti XMAC II can be found at http://www.xaqti.com. The sk driver supports hardware multicast filtering, BPF, promiscuous mode and jumbo frames up to 9000 bytes. It should also work on both FreeBSD/i386 and FreeBSD/alpha. To add the driver to an existing system: - Download if_sk.c, if_skreg.h, xmaciireg.h and if_media.h from http://www.freebsd.org/~wpaul/SysKonnect/3.0. - Copy if_sk.c, if_skreg.h and xmaciireg.h to /sys/pci - If you have a version of FreeBSD older than 3.2-RELEASE, copy if_media.h to /sys/net and /usr/include/net. You may also want to recompile ifconfig at this point, though it's not mandatory. - Edit /sys/conf/files and add a line that says: pci/if_sk.c optional sk device-driver - Edit your kernel config file (e.g. /sys/i386/conf/GENERIC) and add a line that says: device sk0 - Compile a new kernel and boot it. NOTE: make sure to recompile if_media.c now that the new if_media.h is in place. If you have problems, please send them to [EMAIL PROTECTED] Include lots of details. -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
PCCARD and Vpp voltage
Today I started experimenting with the Aironet 4800 series 11Mbps wireless networking cards. Aironet makes PCMCIA, ISA and PCI adapters. I happen to have the PCMCIA and ISA ones. Like the Lucent WaveLAN/IEEE cards, the ISA and PCI cards are really PCMCIA cards fitted into a bridge adapter. Unlike the WaveLAN/IEEE cards, the bridge adapters look like real ISA or PCI devices to the host, so you don't need PCCARD support to use them. (The Lucent WaveLAN/IEEE ISA card requires PCCARD support in order to work.) Anyway, that's not why I'm here. My problem is the PCMCIA adapter. I'm testing it on a Dell Latitude Cpi D300XT, which has both LoseNT 4.0 and FreeBSD 3.2 installed. I decided to install the PCMCIA card in the laptop using the LoseNT drivers so that I could have a known working machine with which to generate traffic so that I could properly test the ISA card. However much to my surprise (well, not really), LoseNT failed to detect the card. The 'PC Card (PCMCIA)' icon in the control shows the PCMCIA modem in slot 1, but shows slot 0 as empty. Naturally, the drivers from Aironet fail to attach the card. So I decided to boot FreeBSD instead. Unfortunately, it didn't detect the card either. After reading the Aironet manual (which I don't really have -- s), I found in the section on starting the card that you have to "Enable power (VCC) to the socket and also set VPP1, VPP2 = 5V." Looking in /sys/pccard/pccard.c:insert(), I found the following code: /* * Enable 5V to the card so that the CIS can be read. */ slt->pwr.vcc = 50; slt->pwr.vpp = 0; So, I changed this to slt->pwr.vcc = 50; slt->pwr.vpp = 50; And now pccardc dumpcis shows all of the proper CIS information, pccardd finds the card and life is good. (Frankly, I was stunned that I figured this out; I'm not really that bright, you know.) Apparently, the Aironet card wants VPP turned on before it will let you read the CIS table. So, here are my questions: - Why is the vpp voltage alwats left at 0? - Is it safe for me to change the code so that it's set to 5 volts? Obviously I'm going to need this change in order to make the Aironet PCMCIA cards work. - If it's not safe to default vpp to 5 volts, is there a safe way to detect when it needs to be turned on and do it only for those cards that need it? -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
Re: poor ethernet performance?
Of all the gin joints in all the towns in all the world, crypt0genic had to walk into mine and say: > Hey all, > I have two freeBSD machines one 3.1 -STABLE and the other 3.2 -STABLE, 3.2-STABLE *FROM WHEN*. What date does it say when you run uname -a! > I was ftping a very large file from one machine to abother over are > lan, it began to get extremely slow and began to stall. I suspected two > much traffic on our hub (A Netgear 24port 10base-T) so i switched the > two machines onto a 8 port Compaq Nettelligent hub. Now there are only > these two machines on the hub and they are still stalling. I tried > ftping both ways but it was the same thing. You changed out the "hub" just because one FTP transfer didn't go as fast as you would have liked? Did you reset the interfaces (or reboot the machines) when you reconnected them? It sounds a lot to me like you have the duplex modes on the cards set wrong, or that the cards are autonegotiating wrong (which is not impossible -- some switches that have full duplex ports don't do NWAY correctly). The cards must agree with their link partners: if you have them plugged into full duplex ports, then they must also be set to full duplex. If the cards are plugged into half duplex ports, then they also have to be half duplex. Now you're going to ask me how to set the duplex mode on the interface because why read the instructions when you can just ask somebody "on the web" instead, right? Grrr. # ifconfig xl0 media 10baseT/UTP mediaopt full-duplex # ifconfig xl0 media 10baseT/UTP mediaopt half-duplex > By looking at the lights on the hob it seems that a burst of data > would come for 2 seconds and then it would be dead for 10. I have 3com > 3c905b FastEthernet cards in both machines, and up until now I have > never had these kind of problems. Er. I don't get it. You're implying that the bug fairy just visited you one night while you were asleep. This doesn't happen. If you're having trouble now and you weren't before, then you changed something. Stands to reason, doesn't it? -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
Call for testers: Adaptec AIC-6915 fast ethernet driver
A driver for FreeBSD 3.x and 4.0-current is now available for testing for fast ethernet adapters based on the Adaptec AIC-6915 "Starfire" ethernet controller. This includes the following Adaptec "Duralink" models: - ANA-62011 single port 64-bit adapter - ANA-62022 dual port 64-bit adapter - ANA-62044 quad port 64-bit adapter - ANA-69011 single port 32-bit adapter - ANA-62020 single port 100baseFX These are Adaptec's replacements for its older DEC 21x4x-based multiport line of adapters. All cards support 10/100 speeds in full or half duplex. The multiport cards consist of multiple AIC-6915 chips linkec via a PCI to PCI bridge. Currently I have only tested the ANA-62022 dual port card, however all of them should work equally well. The 64-bit cards will work in a 32-bit slot on most newer machines. The Starfire supports a great many features including a 16-entry perfect RX filter, a 512-bit multicast hash table filter, a 512-bit high priority hash table, VLAN filtering, multiple RX and TX queues, and several different descriptor formats. There is also a programmable frame processor, however I haven't figured out how to use it. The FreeBSD driver uses a frame-based transmit descriptor (up to 14 packet fragments in one descriptor) and the producer/consumer queueing model with TX and RX completion descriptor queues. The perfect filter and hash filter are used for hardware multicast filtering. Support for BPF mode and promiscuous mode is also provided. The Starfire also supports TCP/IP checksum offload, however this is not yet implemented in this driver. The receive ring is programmed to have 256 descriptors. The transmit ring uses 128. This should be plenty for most server-based applications. Unfortunately, in spite of all the features in the Starfire, the chip requires receive buffers to be longword aligned, which means that received packets have to be copied in order to achieve proper payload alignemnt (which is handy on the x86 and required on the alpha). You'd think if they could go to the trouble of designing in special descriptor formats for MS-DOS and OS/2, they could handle DMAing to unaligned addresses. Oh well. This driver should work on both FreeBSD/i386 and FreeBSD/alpha. To add the driver to an existing FreeBSD 3.x system, do the following: - Download if_sf.c and if_sfreg.h from http://www.freebsd.org/~wpaul/Adaptec/3.0 and put them in /sys/pci. - Edit /sys/conf/files and add a line that says: pci/if_sf.c optional sf device-driver - Edit your kernel config file (e.g. /sys/i386/conf) and add a line that says: device sf0 - Config and compile a new kernel and boot it. To add the driver to an existing FreeBSD 4.0-current system, do one the following: - Download if_sf.c and if_sfreg.h from http://www.freebsd.org/~wpaul/Adaptec/4.0 and put them in /sys/pci. - Edit /sys/conf/files and add a line that says: pci/if_sf.c optional sf - Edit your kernel config file (e.g. /sys/i386/conf) and add a line that says: device sf0 - Config and compile a new kernel and boot it. Alternatively, if you have FreeBSD 4.0-current running on the x86 platform and don't want to recompile your kernel, you can try the following: - Download sf.ko from http://www.freebsd.org/~wpaul/Adaptec/4.0 and put it in /modules. - Edit /boot/defaults/loader.conf and add a line to the device driver modules section that says: sf_load="YES" # Adaptec PCI ethernet - Reboot The sf.ko module is compiled without BPF support. A Makefile is provided in the 4.0 directory which should allow you to recompile the module on both the x86 and alpha platforms. As usual, if you have any problems, please report them to [EMAIL PROTECTED] Remember to provide lots of detailed information. Vote early and vote often. The sooner people bang on this a little, the sooner it will go into the tree. No user-servicable parts inside. Offer void where prohibited by law. Operators are standing by. -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
Re: [FreeBSD-net-jp 1746] [FYI] Adaptec AIC-6915 "Starfire" ethernet controller driver and plus question compaq presario dec et
Of all the gin joints in all the towns in all the world, morita had to walk into mine and say: > $B?9ED$G$9!#(B > > > > These are Adaptec's replacements for its older DEC 21x4x-based multiport > > $B$3$N%I%i%$%P!<$OL5$/$J$k$N$G$7$g$&$+!)(B->DEC 21x4x-based > no more supllyed ->DEC 21x4x-based Sorry, but I'm just a dumb american: I can't read this. > > line of adapters. All cards support 10/100 speeds in full or half duplex. > > The multiport cards consist of multiple AIC-6915 chips linkec via a PCI > > to PCI bridge. Currently I have only tested the ANA-62022 dual port card, > > however all of them should work equally well. The 64-bit cards will work > > in a 32-bit slot on most newer machines. > > > > >$B%3%s%Q%C%/!!(BPRESARIO$B!!(B2274$B!!$K(BFreeBSD3.2$B%$%s%9%H!<%k$7$?$N$G$9$,!"(B > NIC$B!'!!(BDEC 21143-based >$B$H%S%G%*%+!<%I!'(BSiS5598$B$N@_Dj$,$&$^$/$$$-$^$;$s!"8=:_(B > $BF0$+$7$F$k(B > $BJ}$,$$$i$7$?$i65$($F$/$@$5$$!#(B I can't read this either. :( -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
Update on Adaptec AIC-6915 "starfire" driver
I haven't received any feedback yet on the Adaptec "Starfire" driver, however I made a few updates that people should know about: - I created a version of the driver for FreeBSD 2.2.x. You can find it at http://www.freebsd.org/~wpaul/Adaptec/2.2. Note: while I have verified that this code compiles, I have not been able to test it. There should not be any problems, but as always, Murphy's Law applies. - I found a bug today which is that sf_stats_update() required splimp() protection. I use the indirect register access method which is done in two stages: first you set the indirect address register to the register offset that you want to play with, then you access it via the indirect data register. However sf_stats_update() was interruptible which means that it was possible for the interrupt handler to run in between the first and second stages, which caused the stats updater to modify incorrect register locations. This bug would manifest itself in the form of watchdog timeouts and the 'collisions' counter sometimes reporting wildly incorrect values. I corrected this problem and updated the driver sources for each FreeBSD version (including 2.2.x) and recompiled the KLD module for FreeBSD 4.0-current. - The pre-compiled KLD module for FreeBSD 4.0-current now includes BPF support, since I have been told that there stubs that should allow BPF-enabled drivers to work even if BPF support isn't compiled into the kernel. - I added a README at http://www.freebsd.org/~wpaul/Adaptec which explains how to install the driver on FreeBSD 2.2.x, 3.x and 4.0. Also, a quick note about the Adaptec cards. I said previously that the Duralink adapters were Adaptec's replacement for their older DEC tulip-based cards. Adaptec still sells multiport adapters based on the 21x4x chip, however I believe they use the 21143 now since Intel discontinued production of the 21140 and supplies are drying up. It is possible that Adaptec may stop production on the older cards though now that they have their own high performance chipset. The Duralink cards may also be preferable in some cases since they are 64-bit PCI devices. Anyway: I would appreciate it if people could test the driver and get back to me with some feedback. I hope to merge this into the -current branch soon. -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
Re: How do you allocate dma channel with newbus?
Of all the gin joints in all the towns in all the world, Mike Smith had to walk into mine and say: > > > > I am feeling a little dense today, how do you allocate a > > dma channel for a PCI busmaster device with newbus? > > It's a bus master, so you don't. The logical conclusion is that Larry really does have a question, but he asked it badly. Since he asked it so badly that we really don't know what he meant, we should attempt to throw information at him in the hopes that we'll end up telling him what he wants. This is not as efficient as asking the question correctly the first time, but communication seems to be a lost art these days, so what can you do. First of all, with newbus, you now have pci_read_config() and pci_write_config() instead of pci_conf_read() and pci_conf_write(). The former accept a device_t and let you specify the register width (as opposed to forcing to you to use 32-bit accesses all the time). You may need to enable bus mastering and PIO/memory mapping mode in the PCI command register as before. Once you do that, you have to allocate the "resources" that you need. The first resource is the register access space. This can be either an I/O address in iospace or a memory base address. The second is the interrupt. You need to keep track of these resources in your softc structure. They are allocated with bus_alloc_resource(). For PCI devices, you used to use pci_map_port() or pci_map_mem(); now you use bus_alloc_resource() instead, which ultimately has the same effect. When you allocate the register space resource, you have to pass a pointer to a resource ID, which for PCI devices is the register to use. For the SYS_RES_IOPORT resource type, you specify the PCI iobase address register. For SYS_RES_MEMORY, you specify the the memory base address register. Once you have allocated the iospace resource, you can then use rman_get_bustag() and rman_get_bushandle() to get the bustag and bushandle that you can use with the bus_space_read()/bus_space_write() routines to read/write the device registers. The bustag and bushandle should be treated as opaque; they will let you read from iospace or memory mapped space depending on the resource type that you allocated. You also use bus_space_alloc() to allocate the interrupt resource using SYS_RES_IRQ (the resource ID is 0). To actually map the interrupt to a handler function, you need to use bus_setup_intr(). Resources can be released with bus_release_resource(), and the interrupt handler can be detached with bus_teardown_intr(). This allows you to unload drivers. For bus master DMA, you can still use vtophys() to map kernel virtual addresses to physical addresses as before. Ideally one should use the busdma routines for that, however I haven't figured out how to use them with network device drivers yet, and nobody has come forward with a nice simple example that shows how to do it (and no, I don't mean a NetBSD driver: I mean an example which will actually work in FreeBSD). The fxp, xl, sf, sk, ti and other drivers have been newbused and use bus master DMA; hopefully these should provide decent examples. -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
Re: Gigabit ethernet support?
Of all the gin joints in all the towns in all the world, Charles Randall had to walk into mine and say: > Bill Paul has developed a driver for the Alteon Tigon 1 and 2 cards. > > http://www.freebsd.org/~wpaul/Alteon/ > > FYI, > Charles > > -Original Message- > From: David Miller [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, August 18, 1999 1:55 PM > To: [EMAIL PROTECTED] > Subject: Gigabit ethernet support? > > > Any supported cards in 3.2.x? The HCL pages don't list any:( The ti driver supports several cards, including the Alteon AceNIC, the 3Com 3c985-SX, the Netgear GA620, the DEC EtherWORKS 1000, the SGI PCI gigabit ethernet card, the NEC gigabit ethernet card and possibly some from IBM as well, though I don't know the PCI vendor/device IDs for those so I can't be sure (if you find them out, you can try hacking them into the driver). All of these are supported by the same driver because they're all OEMed from Alteon. Also, there is a driver for the SysKonnect gigabit ethernet cards (www.syskonnect.com). The driver sk was merged into the 3.x branch recently. SysKonnect has both single port and dual port cards with multimode and single mode fiber interfaces. All types are supported. -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
Re: Gigabit ethernet support?
Of all the gin joints in all the towns in all the world, David Malone had to walk into mine and say: > On Wed, Aug 18, 1999 at 06:43:24PM -0400, Bill Paul wrote: > > Just out of curiosity, I thought I saw that you could get Intel > Etherexpress 1Gb/s cards. Do these exist and if so would they work > with the fxp driver as it is? > > David. The Intel gigabit ethernet cards are nothing like the EtherExpress fast ethernet adapters. Getting information out of Intel is like trying to squeeze blood from a stone. Either they want you to sign a non disclosure agreement that prevents you from releasing driver source (or makes it hard) or they won't give you any information at all. Sometimes they also play a different game where they release some information and pretend they're being 'open' but in reality the stuff they release is just fluff and you still have to sign an NDA to get your hands on the good stuff. As an aside, there are bound to be extra problems with the Intel gigabit NICs because, if I'm not mistaken, then use an on-board i960 processor to drive them. This means that in order to make the NIC work, you have to load firmware into it, and with firmware comes sticky licensing issues. The Alteon Tigon chipset also requires firmware (it has embedded MIPS R4000 CPUs) but Alteon actually released the firmware source code along with all the other Tigon development information. They even have a mailing list where you can send in questions regarding the firmware and get answers from a real live developer. Until such time as Intel gets its head out of its ass in this regard, I refuse to have anything to do with their networking products, especially when I have two other sources of perfectly good gigabit ethernet NICs available to me with full, unencumbered documentation. Initially this was not true of SysKonnect: they had a Linux driver for their cards but no programming info available. Much to my surprise, after a lengthy e-mail discussion, they actually agreed to release the manual for their GEnesis ASIC not just to me but to anybody without NDA on their web site. You would think that Intel would be prepared to make the same commitment to their customers, but so far as I know, they're still stuck in their proprietary ways. -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
Call for testers, new driver, blah blah blah...
This is a call for testers for a new device driver for yet another PCI fast ethernet controller: the Sundance Technologies ST201. This chipset is currently being used on the D-Link DFE-550TX. The chip on the D-Link is labeled DL10050, but it's actually an ST201. I don't know what other cards use this chip; D-Link contacted me about writing a driver and sent me two sample cards, and do far theirs is the only one that I know of. The driver is set up to recognize the stock Sundance PCI vendor/device ID as well as D-Link's. The Sundance ST201 is a clone of (wait for it) the 3Com 3c90x Etherlink XL series. No, really. Honest and for true. It uses the same DMA descriptor format and operation is very similar to the 3Com cards, although the actual register layout is different. The ST201 also has only a 64-bit multicast hash filtering table where the 3Com cards have a 256-bit table. Also, the ST201 supports only an MII transceiver interface and has no built in BNC/10baseT/AUI ports like the 3Coms. One thing that is a lot like the 3Coms is the fact that packet fragment buffers can be aligned on any byte boundaries, which means that there's no copying required to assure proper payload alignment on the alpha. Performance seems good so far though I haven't really torture tested it yet. Currently, there are drivers for 3.2+ and 4.0 available. You can download them from: http://www.freebsd.org/~wpaul/Sundance/3.0 http://www.freebsd.org/~wpaul/Sundance/4.0 Both versions support FreeBSD/i386 and FreeBSD/alpha and the 4.0 version uses newbus and can be compiled as a loadable module. There's no README yet, so here are some quick instructions: - Download the version of if_ste.c and if_stereg.h for your FreeBSD installation. - Copy if_ste.c and if_stereg.h to /sys/pci - Edit /sys/conf/files and add a line that says: pci/if_ste.coptional ste0 device-driver NOTE: for FreeBSD 4.0, leave out the "device-driver" part. It's no longer needed. - Edit your kernel config file, e.g. /sys/i386/conf/GENERIC and add a line that says: device ste0 - Config and compile a new kernel and boot it. Note that I chose the name "ste" so as not to get it confused with the SCSI tape device "st". I realize we use sa instead of st now, but I'll probably create a driver version for 2.2.x soon, and st is still used there. As usual, report problems or send large bags of cash to [EMAIL PROTECTED] I plan to merge this driver into the -current branch just as soon as I can whip up a man page for it. Share and enjoy! -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
Re: Tulip device driver question
Of all the gin joints in all the towns in all the world, Jason Thorpe had to walk into mine and say: > On Fri, 03 Sep 1999 16:23:00 -0600 > Wes Peters <[EMAIL PROTECTED]> wrote: > > > > > See, for instance, the al, ax, mx, pn, vr, and wb drivers. ;^) > > > ^^ > > > Especially this one.. it's not a Tulip clone :-) > > > > Oh? vr(4) disagrees: > > > > The VIA Rhine chips use bus master DMA and have a software interface de- > > signed to resemble that of the DEC 21x4x "tulip" chips. > > I don't care what the manual page says; take a look at the respective > programming manuals for the chips. Hell, take a look at if_vrreg.h and > if_pnreg.h. The vast differences are *very* obvious. > > Really, the only thing that's even vaguely similar is that both of them > use chained descriptors which are 16 bytes long, with similar layout (but > not compatible bits within each longword). It sure looks to me like somebody was trying to duplicate the tulip descriptor layout though. No, it's not an exact copy, but there is a pretty close resemblance. > The registers are totally different. True. > ...tho, I guess he did say "resemble" ... The SiS 900 "resembles" a Tulip, > too (uses chained descriptors!), and the Tulip "resembles" the DEC SGEC > (a lot more than the Rhine "resembles" the Tulip, tho :-) The SiS 900 only has one combined status/control word in its descriptor structure (some of the bits mean different things depending on whether the descriptors are in the RX ring or TX ring) instead of a separate status and control word. The descriptors are also only 3 longwords in size. > The various Tulip clones are actually somewhat close to Tulips (e.g. same > registers, for the most part, same bits in the registers), and can be driven > by the same driver, with various special cases in them for the (usually slight) > differences [this is the approach I'm taking in NetBSD; why Bill didn't write > a single driver for all the clones I'm not sure I'll ever know...] I thought about that. But after seeing just how many tulip workalikes there are and just how many differences and peculiarities there were, I decided that I just couldn't combine everything into one driver and keep it all working right without the code ending up looking really ugly. There are also more than just a few slight differences between chipsets. Some of them have the standard tulip receive filter mechanism (DMA the setup frame via the TX DMA engine). Some of them have just a couple of registers to program, but there are at least three different variations of this. At least one of them uses the DEC RX filter scheme but with only a 128 bit multicast hash table (the PNIC II -- damned if I know why they did that). The ones that use only the register programming method only have a 64 bit hash table. At least one of them has its registers spaced only 4 bytes apart instead of 8 (the Winbond). Some of them can have either an MII transceiver accessed via an MDIO bit-bang interface, or a serial transceiver. Some of them have built-in MII-like transceivers, but out of those, some of them use the bit-bang interface while others let you access the PHY registers directly. Some of them have built-in NWAY implemented without using an MII-like interface (PNIC, Macronix). Some of them have built-in NWAY designed to look like an MII interface (Macronix 98713) while the next revision up uses custom registers (Macronix 98713A). Some of them have built-in NWAY that doesn't work right (PNIC 82c168). Some of them use the standard DEC serial I/O interface to access the EEPROM. Some of them have custom registers (PNIC). Some of them have bugs that require some off the wall software workarounds (PNIC, Winbond, Davicom). Some of them obey the DEC SROM spec. Some don't. Many of them have additional custom registers for various purposes usually related to wake on lan. And that's just the PCI devices: who knows what other oddities will turn up once we have cardbus support. (And we will have cardbus support some day soon, right Warner? Hello? Warner? You okay? Hm. Somebody want to call an ambulance for Warner? Thank you. Breathe, Warner. _Breathe._ That's better.) Is it possible to cram all this stuff into one driver? Well, sure: the Linux tulip driver does it, although I can't say whether or not the Linux driver handles all of the supported cards correctly all of the time. Could you do it? Sure, why not. Could *I* do it? I don't think so, at least not in an elegant fashion. I can only handle one catastrophe at a time. -Bill -- ==
Re: Tulip device driver question
Of all the gin joints in all the towns in all the world, Jason Thorpe had to walk into mine and say: > [ snip ... all the quirks ] > > ...I'm well aware of all of these :-) > > Amusingly, these are the same kinds of quirks you have to deal with for > a unified *genuine DEC Tulip* driver. E.g. 21143s have internal NWAY and > MII; board manufacturer gets to choose which to use. Well, the older chipsets make it even harder on you: you have to know just the right way to twiddle the bits in the GPIO register in order to program the media settings, and to figure that out you're supposed to read the media description from the SROM, which is sometimes wrong. This opens up a whole other set of quirks. > In any case, I have a single driver for NetBSD that works with both the PNIC > and Winbond clones, and I'm working on support for the other clones. I'm assuming you actually have a Winbond card. If you do, try this for me: connect the Winbond to a link partner who's media settings you can easily control, like a managed switch port or another NIC via crossover cable. Set the Winbond and its link partner to 100Mbps half-duplex. Exchange a little traffic; a couple of pings should be enough. Then go to the link partner and change the media settings to 10Mbps half-duplex. Observe the Winbond closely. (Alternatively, start out with both devices set to 10Mbps half-duplex and then set the other end to 100Mbps half-duplex. I don't remember if both cases have the same result.) Initially I do traffic tests by plugging in the new device directly to another NIC with a driver that supports ifmedia using a crossover cable. This lets me test the card in all media settings. I noticed with the Winbond that if I changed the link partner's speed settings, it would start DMAing all kinds of crap into the host's memory. Furthermore, I think it ignores the RX buffer lengths specified in the receive descriptor ring and trashes various chunks of memory that it shouldn't, leading to a crash. Given that I never observed this behavior with any of the other tulip clones using similar code, I was pretty sure this was a chip bug and not some horrible coding error that I had made somewhere. I saw this with at least three separate Winbond cards and I tried my best to detect the condition and smack the chip upside the head to make it stop, but I'd be interested to see somebody else duplicate the problem and give me their take on it. Also, just out of curiosity, have you ever observed the PNIC receiver bug that gave me so many fits? > > And that's just the PCI devices: who knows what other oddities will > > turn up once we have cardbus support. (And we will have cardbus support > > some day soon, right Warner? Hello? Warner? You okay? Hm. Somebody want to > > call an ambulance for Warner? Thank you. Breathe, Warner. _Breathe._ > > That's better.) > > I think most of the Tulip-like CardBus boards use 21143s. Thankfully. > AFAIK, none of the current sets of clones are designed for CardBus > applications. There's at least one that has a cardbus version... darnit, which is is it. Oh: it's the ADMtek. There's an AL982 designed for PCMCIA and cardbus use. Unfortunately, the data sheet for it is not on ADMtek's server, but it's probably the same core as the AL981. In any case, I don't know of any boards that use the AL982. For that matter, I'm not even sure which boards use the AL981: the only cards I have are the samples that ADMtek sent me, and I haven't seen any board resellers claiming to use it. > BTW, you forgot EISA (DE-425) ... when I finish all the clone support > in my unified driver, I'm going to migrate support for the genuine DEC > chips, as well. If you can actually get it all to work and retain some portion of your sanity, I'll be mighty impressed. -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
Re: Tulip device driver question
le. The LinkSys LNE100TX v2.0 card that I have and the sample 98715A card look almost identical. If you have a 98715A datasheet handy, you can use that as a reference when programming this chip; just remember about the smaller hash table. I'll stick a copy of my PNIC II datasheet at www.freebsd.org for you a little later -- I originally got my copy from LinkSys. As for ADMtek, I originally went looking at www.admtek.com.tw and just e-mailed one of the contacts that they list asking where I could buy a board in the U.S., since I already had the datasheet (the AL981 sheet is on their server). They turned out to be really eager to help me and sent me two cards directly. Again, I have to grope through my back e-mail to find the name of the guy I spoke too, but you can easily get in touch with them using the contact info on their site. Cnet makes a couple of cards using clone tulip chips: the Pro110 and 120 series. One of them uses the ASIX chip and the others use Macronix. I've been told you can sometimes find these at Fry's. Jaton Corporation makes a board called the Jaton XpressNet what uses the Davicom DM9102. This is another chip with a pretty cruddy DMA engine. -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
Re: Tulip device driver question
r the Macronix, > > I would appreciate this... I haven't been able to find '168 boards at all. Okay, I just dug one out of my pile (it says Matrox on the back but it's identical to the LinkSys one). Give me an address where I should send it and I'll try to drop it in the mail sometime this week. > > ideally you need one each of the 98713, 98713A and 98715A. The 98713 > > I have a '15A board... I know of a NetBSD user who has a '13 board (he > sent in patches to make it work with the `de' driver initially). Unfortunately I only have one each of the Macronix cards. You can still find some of the 98713 and 98713A cards around though. > Doing the NWAY register stuff as a simulated PHY is a good idea... should > sort-of work for the PNIC, too, and would save duplicating all that logic > that MII code already implements. Depends a bit on how hard it is to fake up the pseudo registers. I'm pretty sure I can do it but I'm not looking forward to it. > > Also, the PNIC II (LC82c115) is actually a Macronix chip with wake > > on lan and only a 128-bit multicast hash table. The LinkSys LNE100TX v2.0 > > card that I have and the sample 98715A card look almost identical. > > ...I'll have to hunt down one of these cards. These are easy to find: the LNE100TX v2.0 is what LinkSys is currently shipping. They come in a blue and orange box, unlike the old one which was mostly white. Any place that was selling the older LNE100TX is probably selling the LNE100TX v2.0 now. You might also be able to hit up Greg Lapolla at LinkSys for a sample board. (I sent you his e-mail address in a separate mail.) > > If you have a 98715A datasheet handy, you can use that as a reference > > when programming this chip; just remember about the smaller hash table. > > I'll stick a copy of my PNIC II datasheet at www.freebsd.org for you > > a little later -- I originally got my copy from LinkSys. > > That's be great... Okay. It's at http://www.freebsd.org/~wpaul/Macronix/PNIC_II.PDF. Note that when you pull this up in a PDF viewer and examine the document properties, it will tell you the document name is "MX9815A." :) > > a board called the Jaton XpressNet what uses the Davicom DM9102. This > > is another chip with a pretty cruddy DMA engine. > > Davicom ... Winbond-like? No, the Davicom DM9102 is a pretty close copy of the tulip: it uses the setup frame mechanism for programming the RX filter. You can find the datasheet at http://www.davicom8.com. They also have a Linux driver up there somewhere (it's kind of gnarly, but then so are most Linux drivers). The DM9102 also has a built-in PHY so there's no ambiguity about the media. Don't confuse this with the DM9101 which is a PHY only. -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
Call for testers: Aironet wireless adapters
This is a call for testers for users with Aironet 4500 or 4800 series wireless adapters. A device driver for these NICs is now available. PCMCIA, PCI and ISA devices should all be supported. Note however that I personally only have access to the 4800 series cards so I may have missed some of the PCI and/or ISA Plug and Play IDs for the 4500 cards. The Aironet cards are 802.11 devices. The 4500 series cards have a maximum data rate of 2Mbps. The 4800 series have a maximum speed of 11Mbps, or so they claim. In my tests, I tend to see around 600KB/sec (kilobytes per second). This is in ad-hoc mode only; I don't know if infrastructure mode would be faster since I don't have an access point. Driver support is currently available for FreeBSD 3.2 and up. I plan to make a 4.0 driver once the plug and play code in -current settles down a little. The driver is available aT: http://www.freebsd.org/~wpaul/Aironet There is a README which explains how to add the driver to an existing system and configure a new kernel. Pay careful attention to the step marked *IMPORTANT* if you have a PCMCIA card: you must make a small change to /sys/pccard/pccard.c in order to get the PCMCIA card activated correctly (you have to apply +5 volts to the vpp1 and vpp2 pins, which FreeBSD doesn't do by default). The Aironet ISA and PCI cards appear to the host as ordinary ISA or PCI devices. This is a big improvement over the WaveLAN/IEEE ISA card which looks like a PCMCIA controller with a PCMCIA card inserted, and required pccard support even on a desktop system. The ISA card can be set for Plug and Play mode or hard-wired to a particular I/O address or IRQ; the driver supports both modes. If your system supports ISA Plug and Play devices, then it should "just work" without any tweaking. Sharp-eyed readers may notice a striking similarity between the Aironet driver code and the WaveLAN code. Strangely, they have very similar programming interfaces. I don't know why. Note that the Aironet supports multicast reception, but it has no multicast filter: the only possible option is 'receive all multicasts' mode. Also, promiscuous mode only seems to work when the NIC is in infrastructure mode, not in ad-hoc mode. Also, unlike the WaveLAN/IEEE cards, Aironet stations in ad-hoc mode must be on the same SSID in order to communicate. This can be done with the ancontrol utility (i.e. ancontrol -i an0 -n "MY_NETWORK"). As usual, report problems or send free large bags of cash to [EMAIL PROTECTED] Include lots of details. -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
Re: Cool little 100BaseTX switch - they're coming down in price
Of all the gin joints in all the towns in all the world, Matthew Dillon had to walk into mine and say: > :At work I've got experience with 32-port D-Link 10/100 switched > :hub. It works fine except that it hangs occasionally (can be > :reset by power-cycling). So we don't buy them any more. Also > :at my pre-previous employer we had small 8-port 10Mpbs hubs from > :D-Link and they had the same problem, so it seems to be a family > :problem. With about 20 hubs there was a hang approximately every > :other day. > : > :-SB > > Oh joy. Well, we'll see what happens with this one. I > had a Sohoware superflex 10/100 hub and it hung nearly > every day. I'm also testing out a linksys switch (I > bought a D-Link switch and a LinkSys switch). > Unfortunately the NIC cards that came with the LinkSys > switch, as far as I can tell, are no longer supported > in -current. Uhm uhm uhm. You do *not* want to say things like that within earshot of me. Describe the cards better. Describe how you came to the conclusion that they aren't supported. What chip is on them? If it's the LC82C115 then these are the LNE100TX Version 2.0 with Wake On LAN, and they *are* supported: you need to use the if_dc driver. It should be in the GENERIC kernel. This same driver now also supports the older LNE100TX with the 82c168/82c169 PNIC chips. In fact the dc driver now supports all of the DEC tulip workalike chipsets. (Well, except for the Winbond W89C840F, which is still supported by the wb driver.) The really really old LNE100TX cards were based on the DEC 21140, and LinkSys doesn't sell those anymore, so I doubt you have one of those. -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
Re: Cool little 100BaseTX switch - they're coming down in price
Of all the gin joints in all the towns in all the world, Matthew Dillon had to walk into mine and say: > :Uhm uhm uhm. You do *not* want to say things like that within earshot > :of me. Describe the cards better. Describe how you came to the > :conclusion that they aren't supported. What chip is on them? If it's > :the LC82C115 then these are the LNE100TX Version 2.0 with Wake On LAN, > :and they *are* supported: you need to use the if_dc driver. > Heh heh. Indeed, they are LNE100TX V2.0 cards. > > I'll try adding 'dc' in. If it works, can I add a comment about > 'LNE100TX' cards to the comments in LINT for 'dc'? Sure, if you like, however note that "man 4 dc" should also yield a list of supported cards, including the LNE100TX v2.0. -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
USB ethernet hacking
ek/USB/4.0 This directory contains the source for the if_aue driver, plus a patch for usbdi.c with the changes I made to get sync transfers to work properly in interrupt context. The code is still very grotty. The datasheet for the ADMtek Pegasus chip is at http://www.admtek.com.tw. -Bill P.S.: Please don't write me asking for help getting your USB ethernet adapter work with FreeBSD. Don't ask me when/if the driver will be done. Don't ask me if your favorite adapter will be supported. Don't ask me how to make the code work with FreeBSD 3.x. -- = -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
