summaryrefslogtreecommitdiffstats
path: root/usr.sbin/sade/devices.c
Commit message (Collapse)AuthorAgeFilesLines
* Ugh. Back out local changes that crept in with my last commit. :(jhb2000-07-141-1/+0
|
* MFS: (yes, from -stable) Note that current.FreeBSD.org is a 5.0 snap serverjhb2000-07-141-0/+1
| | | | now, and replace the releng3 3.0 snap entry with releng4.
* Replace phk's commit with code from my local tree which I happenjkh2000-07-051-1/+3
| | | | to like better (it's commented and easier to read).
* Ignore all md disks, installing on them would be particularly pointless.phk2000-07-041-2/+6
| | | | Its not fatal to find hardware we don't know.
* - Remove obsolete PC-card boot.flp hack. It was for making both PC-cardnyan2000-06-051-0/+6
| | | | | | | | | | | | | | boot.flp and plain boot.flp. - Clean up crunchgen related routine. - Add PC-98 support. TODO: o Documentation o Fix some messages for PC-98 o Decrease the size of fixit.flp to 1.2MB o I18N (See: http://www.jp.FreeBSD.org/BootAsia/index.html) No response from jkh
* Remove all of the block devices, correct major numbers to point to themsmith2000-05-251-21/+13
| | | | | corresponding character devices. This is (currently) untested, but should be correct.
* Teach sysinstall about 'twe' disks. Note that this is currentlymsmith2000-05-251-0/+1
| | | | | untested, and with the current state of flux surrounding the death of bdevs other things here may need to change.
* Add Compaq Arraysjlemon2000-03-081-0/+2
|
* Make sysinstall use the new debug.boothowto OID. It will now gojkh2000-02-251-9/+28
| | | | | | | | straight into debug mode if you boot -v. Also conditionalize some annoying debugging output now that we have this ability. Partially submitted by: msmith Approved by: jkh [to make certain wise-acres happy ;)]
* Added sn driver to network interface menu.hosokawa2000-01-151-0/+1
|
* Add device driver support for USB ethernet adapters based on the CATCwpaul2000-01-141-0/+1
| | | | | | | | | | | | | | | | USB-EL1202A chipset. Between this and the other two drivers, we should have support for pretty much every USB ethernet adapter on the market. The only other USB chip that I know of is the SMC USB97C196, and right now I don't know of any adapters that use it (including the ones made by SMC :/ ). Note that the CATC chip supports a nifty feature: read and write combining. This allows multiple ethernet packets to be transfered in a single USB bulk in/out transaction. However I'm again having trouble with large bulk in transfers like I did with the ADMtek chip, which leads me to believe that our USB stack needs some work before we can really make use of this feature. When/if things improve, I intend to revisit the aue and cue drivers. For now, I've lost enough sanity points.
* Add device driver support for USB ethernet adapters based on thewpaul2000-01-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | Kawasaki LSI KL5KUSB101B chip, including the LinkSys USB10T, the Entrega NET-USB-E45, the Peracom USB Ethernet Adapter, the 3Com 3c19250 and the ADS Technologies USB-10BT. This device is 10mbs half-duplex only, so there's miibus or ifmedia support. This device also requires firmware to be loaded into it, however KLSI allows redistribution of the firmware images (I specifically asked about this; they said it was ok). Special thanks to Annelise Anderson for getting me in touch with KLSI (eventually) and thanks to KLSI for providing the necessary programming info. Highlights: - Add driver files to /sys/dev/usb - update usbdevs and regenerate attendate files - update usb_quirks.c - Update HARDWARE.TXT and RELNOTES.TXT for i386 and alpha - Update LINT, GENERIC and others for i386, alpha and pc98 - Add man page - Add module - Update sysinstall and userconfig.c
* This commit adds device driver support for the ADMtek AN986 Pegasuswpaul1999-12-281-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | USB ethernet chip. Adapters that use this chip include the LinkSys USB100TX. There are a few others, but I'm not certain of their availability in the U.S. I used an ADMtek eval board for development. Note that while the ADMtek chip is a 100Mbps device, you can't really get 100Mbps speeds over USB. Regardless, this driver uses miibus to allow speed and duplex mode selection as well as autonegotiation. Building and kldloading the driver as a module is also supported. Note that in order to make this driver work, I had to make what some may consider an ugly hack to sys/dev/usb/usbdi.c. The usbd_transfer() function will use tsleep() for synchronous transfers that don't complete right away. This is a problem since there are times when we need to do sync transfers from an interrupt context (i.e. when reading registers from the MAC via the control endpoint), where tsleep() us a no-no. My hack allows the driver to have the code poll for transfer completion subject to the xfer->timeout timeout rather that calling tsleep(). This hack is controlled by a quirk entry and is only enabled for the ADMtek device. Now, I'm sure there are a few of you out there ready to jump on me and suggest some other approach that doesn't involve a busy wait. The only solution that might work is to handle the interrupts in a kernel thread, where you may have something resembling a process context that makes it okay to tsleep(). This is lovely, except we don't have any mechanism like that now, and I'm not about to implement such a thing myself since it's beyond the scope of driver development. (Translation: I'll be damned if I know how to do it.) If FreeBSD ever aquires such a mechanism, I'll be glad to revisit the driver to take advantage of it. In the meantime, I settled for what I perceived to be the solution that involved the least amount of code changes. In general, the hit is pretty light. Also note that my only USB test box has a UHCI controller: I haven't I don't have a machine with an OHCI controller available. Highlights: - Updated usb_quirks.* to add UQ_NO_TSLEEP quirk for ADMtek part. - Updated usbdevs and regenerated generated files - Updated HARDWARE.TXT and RELNOTES.TXT files - Updated sysinstall/device.c and userconfig.c - Updated kernel configs -- device aue0 is commented out by default - Updated /sys/conf/files - Added new kld module directory
* In retrospect, msgNotify() should leave its contents on the screenjkh1999-12-171-0/+1
| | | | | longer to give the user something to look at while things are happening. Change it to do so and insert the appropriate screen saves elsewhere.
* Remove references to ze and zp drivers.phk1999-12-101-2/+0
|
* Remove sysinstall knowledge of the wd based devices..sos1999-12-081-6/+0
|
* Add the if_dc driver and remove all of the al, ax, dm, pn and mx driverswpaul1999-12-041-5/+1
| | | | | | | | which it replaces. The new driver supports all of the chips supported by the ones it replaces, as well as many DEC/Intel 21143 10/100 cards. This also completes my quest to convert things to miibus and add Alpha support.
* Add support for the AMI MegaRAID and Mylex drivers to sysinstall.msmith1999-11-271-0/+4
| | | | | There are reports that installs to these controllers still don't work, but this is at least one step closer.
* Add devices from the ATA driver (ad, acd, afd, ast).sos1999-11-091-1/+6
|
* Spruce up the ADMtek driver: conver to newbus, miibus and add supportwpaul1999-09-221-1/+1
| | | | | | | | | | | | | | | for the AN985 "Centaur" chip, which is apparently the next genetation of the "Comet." The AN985 is also a tulip clone and is similar to the AL981 except that it uses a 99C66 EEPROM and a serial MII interface (instead of direct access to the PHY registers). Also updated various documentation to mention the AN985 and created a loadable module. I don't think there are any cards that use this chip on the market yet: the datasheet I got from ADMtek has boxes with big X's in them where the diagrams should be, and the sample boards I got have chips without any artwork on them.
* This commit adds driver support for PCI fast ethernet NICs based onwpaul1999-09-061-0/+1
| | | | | | | | | | | | | | | | the Davicom DM9100 and DM9102 chipsets, including the Jaton Corporation XPressNet. Datasheet is available from www.davicom8.com. The DM910x chips are still more tulip clones. The API is reproduced pretty faithfully, unfortunately the performance is pretty bad. The transmitter seems to have a lot of problems DMAing multi-fragment packets. The only way to make it work reliably is to coalesce transmitted packets into a single contiguous buffer. The Linux driver (written by Davicom) actually does something similar to this. I can't recomment this NIC as anything more than a "connectivity solution." This driver uses newbus and miibus and is supported on both i386 and alpha platforms.
* This commit adds driver support for the Silicon Integrated Systemswpaul1999-09-051-0/+1
| | | | | | | | | | | | SiS 900 and SiS 7016 PCI fast ethernet chipsets. Full manuals for the SiS chips can be found at www.sis.com.tw. This is a fairly simple chipset. The receiver uses a 128-bit multicast hash table and single perfect entry for the station address. Transmit and receive DMA and FIFO thresholds are easily tuneable. Documentation is pretty decent and performance is not bad, even on my crufty 486. This driver uses newbus and miibus and is supported on both the i386 and alpha architectures.
* Oh crud, did I ever screw the pooch! Rather than sync this with -stable,jkh1999-09-021-7/+8
| | | | | | | | | | I backed-out the changes in -current and didn't touch stable at all (I thought I had my patch order reversed, not what actually happened). AIEEE! I can't even blame the crack for this one since I broke my crack pipe a few weeks ago. I think sleep deprivation gets the blame for this one. Medal for noticing this one goes to: Jim Bloom <bloom@acm.org>
* MFC: Catch 3.2-stable sysinstall up to 4.0-current level functionality,jkh1999-09-011-8/+7
| | | | | | | bringing in DHCP support. The only thing I left out were Poul-Henning's newfs changes since I'm not sure if he's brought the rest of that support into -stable yet. If it turns out that this is the case, I'll MFC those changes too.
* $Id$ -> $FreeBSD$peter1999-08-281-1/+1
|
* This commit adds device driver support for the Sundance Technologies ST201wpaul1999-08-211-1/+2
| | | | | | | | | | | | | PCI fast ethernet controller. Currently, the only card I know that uses this chip is the D-Link DFE-550TX. (Don't ask me where to buy these: the only cards I have are samples sent to me by D-Link.) This driver is the first to make use of the miibus code once I'm sure it all works together nicely, I'll start converting the other drivers. The Sundance chip is a clone of the 3Com 3c90x Etherlink XL design only with its own register layout. Support is provided for ifmedia, hardware multicast filtering, bridging and promiscuous mode.
* This commit adds device driver support for Adaptec Duralink PCI fastwpaul1999-07-251-1/+2
| | | | | | | | | | | | | | | | | | | | | ethernet controllers based on the AIC-6915 "Starfire" controller chip. There are single port, dual port and quad port cards, plus one 100baseFX card. All are 64-bit PCI devices, except one single port model. The Starfire would be a very nice chip were it not for the fact that receive buffers have to be longword aligned. This requires buffer copying in order to achieve proper payload alignment on the alpha. Payload alignment is enforced on both the alpha and x86 platforms. The Starfire has several different DMA descriptor formats and transfer mechanisms. This driver uses frame descriptors for transmission which can address up to 14 packet fragments, and a single fragment descriptor for receive. It also uses the producer/consumer model and completion queues for both transmit and receive. The transmit ring has 128 descriptors and the receive ring has 256. This driver supports both FreeBSD/i386 and FreeBSD/alpha, and uses newbus so that it can be compiled as a loadable kernel module. Support for BPF and hardware multicast filtering is included.
* The matcd driver is acting strange (returning a successful open evenjkh1999-07-201-1/+3
| | | | when it fails). Disable it in sysinstall for now.
* This commit adds driver support for the SysKonnect SK-984x serieswpaul1999-07-091-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | gigabit ethernet adapters. This includes two single port cards (single mode and multimode fiber) and two dual port cards (also single mode and multimode fiber). SysKonnect is currently the only vendor with a dual port gigabit ethernet NIC. The ports on dual port adapters are treated as separate network interfaces. Thus, if you have an SK-9844 dual port SX card, you should have both sk0 and sk1 interfaces attached. Dual port cards are implemented using two XMAC II chips connected to a single SysKonnect GEnesis controller. Hence, dual port cards are really one PCI device, as opposed to two separate PCI devices connected through a PCI to PCI bridge. Note that SysKonnect's drivers use the two ports for failover purposes rather that as two separate interfaces, plus they don't support jumbo frames. This applies to their Linux driver too. :) Support is provided for hardware multicast filtering, BPF and jumbo frames. The SysKonnect cards support TCP checksum offload however this feature is not currently enabled (hopefully it will be once we get checksum offload support). There are still a few things that need to be implemeted, like the ability to communicate with the on-board LM80 voltage/temperature monitor, but I wanted to get the driver under CVS control and into -current so people could bang on it. A big thanks for SysKonnect for making all their programming info for these cards (and for their FDDI and token ring cards) available without NDA (see www.syskonnect.com).
* update fla related entries.phk1999-07-061-3/+3
|
* wcd -> acdmharo1999-07-031-2/+2
| | | | Submitted by: Ruslan Ermilov <ru@ucb.crimea.ua>
* Add bits of PAO that are non-controversial.markm1999-06-171-7/+8
| | | | Submitted by: Tatsumi HOSOKAWA
* Do a clean-up pass on error/warning messages.jkh1999-05-271-10/+7
|
* This commit adds driver support for PCI fast ethernet cards based on thewpaul1999-05-211-1/+2
| | | | | | | | | | | | | | | | | | | | | | | ADMtek AL981 "Comet" chipset. The AL981 is yet another DEC tulip clone, except with simpler receive filter options. The AL981 has a built-in transceiver, power management support, wake on LAN and flow control. This chip performs extremely well; it's on par with the ASIX chipset in terms of speed, which is pretty good (it can do 11.5MB/sec with TCP easily). I would have committed this driver sooner, except I ran into one problem with the AL981 that required a workaround. When the chip is transmitting at full speed, it will sometimes wedge if you queue a series of packets that wrap from the end of the transmit descriptor list back to the beginning. I can't explain why this happens, and none of the other tulip clones behave this way. The workaround this is to just watch for the end of the transmit ring and make sure that al_start() breaks out of its packet queuing loop and waiting until the current batch of transmissions completes before wrapping back to the start of the ring. Fortunately, this does not significantly impact transmit performance. This is one of those things that takes weeks of analysis just to come up with two or three lines of code changes.
* Add driver support for gigabit ethernet adapters based on the Alteonwpaul1999-04-061-1/+2
| | | | | | | | | | | | | | | | | | | | | | | Networks Tigon 1 and Tigon 2 chipsets. There are a _lot_ of OEM'ed gigabit ethernet adapters out there which use the Alteon chipset so this driver covers a fair amount of hardware. I know that it works with the Alteon AceNIC, 3Com 3c985 and Netgear GA620, however it should also work with the DEC/Compaq EtherWORKS 1000, Silicon Graphics Gigabit ethernet board, NEC Gigabit Ethernet board and maybe even the IBM and and Sun boards. The Netgear board is the cheapest (~$350US) but still yields fairly good performance. Support is provided for jumbo frames with all adapters (just set the MTU to something larger than 1500 bytes), as well as hardware multicast filtering and vlan tagging (in conjunction with the vlan support in -current, which I should merge into -stable soon). There are some hooks for checksum offload support, but they're turned off for now since FreeBSD doesn't have an officially sanctioned way to support checksum offloading (yet). I have not added the 'device ti0' entry to GENERIC since the driver with all the firmware compiled in is quite large, and it doesn't really fit into the category of generic hardware.
* Add an option for resetting and rescanning the probed device list, perhapsjkh1999-04-061-1/+28
| | | | | | | | to now detect that CD you just remembered to put in the drive or that pccard NIC that you've inserted (anybody can put pccardd in an mfsroot image now you know.. :) Requested by: Annelise Anderson <andrsn@andrsn.Stanford.EDU>
* Add driver support (and man page) for PCI fast ethernet cards basedwpaul1999-01-091-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | on the ASIX AX88140A chip. Update /sys/conf/files, RELNOTES.TXT, /sys/i388/i386/userconfig.c, sysinstall/devices.c, GENERIC and LINT accordingly. For now, the only board that I know of that uses this chip is the Alfa Inc. GFC2204. (Its predecessor, the GFC2202, was a DEC tulip card.) Thanks again to Ulf for obtaining the board for me. If anyone runs across another, please feel free to update the man page and/or the release notes. (The same applies for the other drivers.) FreeBSD should now have support for all of the DEC tulip workalike chipsets currently on the market (Macronix, Lite-On, Winbond, ASIX). And unless I'm mistaken, it should also have support for all PCI fast ethernet chipsets in general (except maybe the SMC FEAST chip, which nobody seems to ever use, including SMC). Now if only we could convince 3Com, Intel or whoever to cough up some documentation for gigabit ethernet hardware. Also updated RELNOTEX.TXT to mention that the SVEC PN102TX is supported by the Macronix driver (assuming you actually have an SVEC PN102TX with a Macronix chip on it; I tried to order a PN102TX once and got a box labeled 'Hawking Technology PN102TX' that had a VIA Rhine board inside it).
* An early Christmas present: add driver support for a whole bunch ofwpaul1998-12-041-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PCI fast ethernet adapters, plus man pages. if_pn.c: Netgear FA310TX model D1, LinkSys LNE100TX, Matrox FastNIC 10/100, various other PNIC devices if_mx.c: NDC Communications SOHOware SFA100 (Macronix 98713A), various other boards based on the Macronix 98713, 98713A, 98715, 98715A and 98725 chips if_vr.c: D-Link DFE530-TX, other boards based on the VIA Rhine and Rhine II chips (note: the D-Link and certain other cards that actually use a Rhine II chip still return the PCI device ID of the Rhine I. I don't know why, and it doesn't really matter since the driver treats both chips the same anyway.) if_wb.c: Trendware TE100-PCIE and various other cards based on the Winbond W89C840F chip (the Trendware card is identical to the sample boards Winbond sent me, so who knows how many clones there are running around) All drivers include support for ifmedia, BPF and hardware multicast filtering. Also updated GENERIC, LINT, RELNOTES.TXT, userconfig and sysinstall device list. I also have a driver for the ASIX AX88140A in the works.
* Add entries for DiskOnChip2000 Flash device.jkh1998-10-191-1/+3
| | | | Submitted by: phk
* Add driver support for PCI fast ethernet adapters based on thewpaul1998-10-181-1/+2
| | | | | | | | | RealTek 8129/8139 chipset like I've been threatening. Update kernel configs, userconfig.c, relnotes and sysinstall. No man page yet; comming soon. I consider this driver stable enough that I want to give it some exposure in -current.
* Fix typo in message.danny1998-09-301-2/+2
|
* Remove support for floppy tape installs. I'm sorry, we're outtajkh1998-09-261-2/+1
| | | | | space, and it's either this or the DOS installs. I think that the DOS installs are somehow more important. :)
* Device name cleanup for CAM.gibbs1998-09-151-6/+4
|
* Add device list entries for the tl and xl PCI ethernet devices.wpaul1998-09-131-2/+4
|
* MF22: Paul Traina's changes.jkh1998-07-181-3/+8
|
* Crank the max possible disks/slices constants way down.jkh1998-06-291-6/+6
| | | | | The probe for this sometimes makes IDE drives chatter their guts out and takes an inordinately long time in such cases..
* Merge updates from 2.2jkh1998-05-241-1/+2
|
* Make Mitsumi and Sony CDROM devs also use the `a' device. I thinkjkh1998-05-111-3/+3
| | | | | they'll have (or are having) similar problems to those described for the matcd device in PR#6576
* It was incorrect to use the `c' device for the matcd driver;jkh1998-05-111-2/+2
| | | | | | | | | | apparently, unlike the IDE or SCSI CDROM drivers, this is magically special-cased for audio CDs. This also might explain what happened with scd (Sony) CDs also since I made the same change there. A follow-up commit will fix that. Thanks, Dave! PR: 6576 Submitted by: Dave Marquardt <marquard@zilker.net>
* MF22: create raw slice entries.jkh1998-03-201-3/+9
|
OpenPOWER on IntegriCloud