summaryrefslogtreecommitdiffstats
path: root/usr.sbin/sade/devices.c
Commit message (Collapse)AuthorAgeFilesLines
* Remove old wdc driver completely.nyan2005-01-041-6/+0
|
* Due to unknown reasons, Disk_Names() returns SCSI CDROM as a validyongari2004-12-221-0/+14
| | | | | | | | | | | | | disk. This is main reason why sysinstall presents SCSI CDROM to available disks in Fdisk/Label menu. In addition, adding a blank SCSI CDROM to the menu generates floating point exception in sparc64. Disk_Names() just extracts sysctl "kern.disks". Why GEOM treats SCSI CDROM as a disk is beyond me and that should be investigated. For temporary workaround, ignore SCSI CDROM device. PR: sparc64/72962 Tested by: R. Tyler Ballance < tyler AT tamu DOT edu> MFC after: 1 week
* Catch up with PHK's sio(4) cuaa->cuad rework [sys/dev/sio/sio.c rev. 1.456].obrien2004-11-191-1/+1
| | | | | PR: 73878 Submitted by: Steve Kargl <sgk@troutmask.apl.washington.edu>
* Add device driver support for the VIA Networking Technologieswpaul2004-09-101-0/+1
| | | | | | | | | | | | VT6122 gigabit ethernet chip and integrated 10/100/1000 copper PHY. The vge driver has been added to GENERIC for i386, pc98 and amd64, but not to sparc or ia64 since I don't have the ability to test it there. The vge(4) driver supports VLANs, checksum offload and jumbo frames. Also added the lge(4) and nge(4) drivers to GENERIC for i386 and pc98 since I was in the neighborhood. There's no reason to leave them out anymore.
* Fix installing from SCSI tape drives by catching up device names withbmah2004-08-161-1/+1
| | | | | | | reality. PR: 70279 Submitted by: Gavin Atkinson <gavin.atkinson@ury.york.ac.uk>
* Move the inclusion of libdisk.h from sysinstall.h to the source filesmarcel2004-08-021-0/+1
| | | | | | | that actually need it. This makes it easier for a platform porter to find the files that may need tweaking to support whatever MD specific partitioning is needed. It also helps to prevent that the libdisk API gets exposed and/or used where it's not needed.
* Remove reference to fla driver.phk2004-07-201-1/+0
|
* Add 'fwe' so one doesn't get "<unknown network interface type>".obrien2004-01-041-0/+1
|
* Add a device driver for the Broadcom BCM4401 ethernet controller,wpaul2003-09-091-0/+1
| | | | | | | | | | | | | | written by Stuart Walsh and Duncan Barclay (with some kibbitzing by me). I'm checking it in on Stuart's behalf. The BCM4401 is built into several x86 laptop and desktop systems. For the moment, I have only enabled it in the x86 kernel config because although it's a PCI device, I haven't heard of any standalone NICs that use it. If somebody knows of one, we can easily add it to the other arches. This driver uses register/structure data gleaned from the Linux driver released by Broadcom, but does not contain any of the code from the Linux driver itself. It uses busdma.
* Take the support for the 8139C+/8169/8169S/8110S chips out of thewpaul2003-09-081-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | rl(4) driver and put it in a new re(4) driver. The re(4) driver shares the if_rlreg.h file with rl(4) but is a separate module. (Ultimately I may change this. For now, it's convenient.) rl(4) has been modified so that it will never attach to an 8139C+ chip, leaving it to re(4) instead. Only re(4) has the PCI IDs to match the 8169/8169S/8110S gigE chips. if_re.c contains the same basic code that was originally bolted onto if_rl.c, with the following updates: - Added support for jumbo frames. Currently, there seems to be a limit of approximately 6200 bytes for jumbo frames on transmit. (This was determined via experimentation.) The 8169S/8110S chips apparently are limited to 7.5K frames on transmit. This may require some more work, though the framework to handle jumbo frames on RX is in place: the re_rxeof() routine will gather up frames than span multiple 2K clusters into a single mbuf list. - Fixed bug in re_txeof(): if we reap some of the TX buffers, but there are still some pending, re-arm the timer before exiting re_txeof() so that another timeout interrupt will be generated, just in case re_start() doesn't do it for us. - Handle the 'link state changed' interrupt - Fix a detach bug. If re(4) is loaded as a module, and you do tcpdump -i re0, then you do 'kldunload if_re,' the system will panic after a few seconds. This happens because ether_ifdetach() ends up calling the BPF detach code, which notices the interface is in promiscuous mode and tries to switch promisc mode off while detaching the BPF listner. This ultimately results in a call to re_ioctl() (due to SIOCSIFFLAGS), which in turn calls re_init() to handle the IFF_PROMISC flag change. Unfortunately, calling re_init() here turns the chip back on and restarts the 1-second timeout loop that drives re_tick(). By the time the timeout fires, if_re.ko has been unloaded, which results in a call to invalid code and blows up the system. To fix this, I cleared the IFF_UP flag before calling ether_ifdetach(), which stops the ioctl routine from trying to reset the chip. - Modified comments in re_rxeof() relating to the difference in RX descriptor status bit layout between the 8139C+ and the gigE chips. The layout is different because the frame length field was expanded from 12 bits to 13, and they got rid of one of the status bits to make room. - Add diagnostic code (re_diag()) to test for the case where a user has installed a broken 32-bit 8169 PCI NIC in a 64-bit slot. Some NICs have the REQ64# and ACK64# lines connected even though the board is 32-bit only (in this case, they should be pulled high). This fools the chip into doing 64-bit DMA transfers even though there is no 64-bit data path. To detect this, re_diag() puts the chip into digital loopback mode and sets the receiver to promiscuous mode, then initiates a single 64-byte packet transmission. The frame is echoed back to the host, and if the frame contents are intact, we know DMA is working correctly, otherwise we complain loudly on the console and abort the device attach. (At the moment, I don't know of any way to work around the problem other than physically modifying the board, so until/unless I can think of a software workaround, this will have do to.) - Created re(4) man page - Modified rlphy.c to allow re(4) to attach as well as rl(4). Note that this code works for the sample 8169/Marvell 88E1000 NIC that I have, but probably won't work for the 8169S/8110S chips. RealTek has sent me some sample NICs, but they haven't arrived yet. I will probably need to add an rlgphy driver to handle the on-board PHY in the 8169S/8110S (it needs special DSP initialization).
* Teach sysinstall about the ServeRAID disk device.scottl2003-05-111-0/+1
|
* Add device driver support for the ASIX Electronics AX88172 USB 2.0wpaul2003-04-201-0/+1
| | | | | | | | | | | ethernet controller. The driver has been tested with the LinkSys USB200M adapter. I know for a fact that there are other devices out there with this chip but don't have all the USB vendor/device IDs. Note: I'm not sure if this will force the driver to end up in the install kernel image or not. Special magic needs to be done to exclude it to keep the boot floppies from bloating again, someone please advise.
* Use correct interface name (it's different on -current).sobomax2003-03-051-1/+1
| | | | | Submitted by: Brooks Davis <brooks@one-eyed-alien.net> MFC after: 20 days
* Remove local hack that somehow slipped into the previous commit.sobomax2003-03-051-1/+1
| | | | MFC after: 20 days
* Add missed description for the `ds' (disc(4)) pseudo-interface.sobomax2003-03-051-1/+2
| | | | | Sponsored by: Porta Software Ltd MFC after: 20 days
* Teach sysinstall about the em(4) device.trhodes2003-01-271-0/+1
| | | | | | | | PR: 46439 Submitted by: Dan Lukes <dan@obluda.cz> Approved by: re (murray) Tested? yes MFC: 1 day
* Add 'vlan' as a network device.jhb2003-01-171-0/+1
| | | | Tested by: dcs
* Don't use fake 'c' or 'a' BSD partitions for CD-ROM devices. This fixesjhb2002-11-271-5/+5
| | | | | | | sysinstall to create /cdrom entries in /etc/fstab that just use the raw CD-ROM device /dev/cd0, etc. Approved by: re
* Also test for type efi everywhere we currently test for type fat.marcel2002-11-131-1/+1
| | | | | | | With this change there's no a priori difference between EFI and FAT partitions. With this change and the corresponding change to libdisk, we can create EFI partitions, just like regular FAT partitions.
* debugMsg() should end with "\n".kuriyama2002-11-011-1/+1
|
* Add lge(4) to the list of drivers. It was present in 4-stable but not injhb2002-07-021-0/+1
| | | | -current.
* Fix /dev/acdNc minor device number. This bug prevents installing FreeBSDmatusita2002-03-301-1/+1
| | | | | | | | | from CD-ROM in 4-stable. Note that in 5-current, we use devfs so this change (hopefully) shouldn't change anything. I'll MFC to 4-stable later. Tested with: FreeBSD/i386, 4.5-STABLE-20020330-JPSNAP
* Add wireless devices to device_names array. Now that ifconfig can setmurray2002-03-171-0/+3
| | | | | | | session IDs, and sysinstall can load modules from the MFSROOT, it should be possible to install FreeBSD over a wireless link. MFC after: 2 weeks
* Close all open file descriptors before restarting sysinstall.murray2001-09-301-0/+2
| | | | | PR: bin/30737 Submitted by: Alexey V. Neyman <alex.neyman@auriga.ru>
* Add device driver support for the Broadcom BCM570x family of gigabitwpaul2001-09-271-0/+1
| | | | | | | | | | | | | | ethernet controllers. This adds support for the 3Com 3c996-T, the SysKonnect SK-9D21 and SK-9D41, and the built-in gigE NICs on Dell PowerEdge 2550 servers. The latter configuration hauls ass: preliminary measurements show TCP speeds of over 900Mbps using only normal size frames. TCP/IP checksum offload, jumbo frames and VLAN tag insertion/stripping are supported, as well as interrupt moderation. Still need to fix autonegotiation support for 1000baseSX NICs, but beyond that, driver is pretty solid.
* You were knocked senseless by the Boomerang, spun around by the Cyclone,wpaul2001-07-231-0/+1
| | | | | | | | | | | | | | | | | | blown over by the Hurricane and had a house dropped on you by the Tornado. Now it's time to have your parade rained on by... the Typhoon! This commit adds driver support for 3Com 3cR990 10/100 ethernet adapters based on the Typhoon I and Typhoon II chipsets. This is actually a port of the OpenBSD driver with many hacks by me. No Virginia, there isn't any support for the hardware crypto yet. However there is support for TCP/IP checksum offload and VLANs. Special thanks go to Jason Wright, Aaron Campbell and Theo de Raadt for squeezing enough info out of 3Com to get this written, and for doing most of the hard work. Manual page is included. Compiled as a module and included in GENERIC.
* Introduce DEVICE_INIT, DEVICE_GET, and DEVICE_SHUTDOWN macros. As thedd2001-07-021-1/+1
| | | | | | | | | names suggest, they perform methods on Device's. In addition, they check that the pointer passed to them is valid; if it isn't, they pretend that the action failed. This fixes some crashes due to NULL dereferences (e.g., PR 26509). Approved by: jkh (some time ago)
* Add support for gigabit ethernet cards based on the NatSemi DP83820wpaul2001-05-111-0/+1
| | | | | | | | | | | | | | | | | | | and DP83821 gigabit ethernet MAC chips and the NatSemi DP83861 10/100/1000 copper PHY. There are a whole bunch of very low cost cards available with this chipset selling for $150USD or less. This includes the SMC9462TX, D-Link DGE-500T, Asante GigaNIX 1000TA and 1000TPC, and a couple cards from Addtron. This chip supports TCP/IP checksum offload, VLAN tagging/insertion. 2048-bit multicast filter, jumbograms and has 8K TX and 32K RX FIFOs. I have not done serious performance testing with this driver. I know it works, and I want it under CVS control so I can keep tabs on it. Note that there's no serious mutex stuff in here yet either: I need to talk more with jhb to figure out the right way to do this. That said, I don't think there will be any problems. This driver should also work on the alpha. It's not turned on in GENERIC.
* Moved the snc driver position before the sn driver.nyan2000-12-091-1/+3
| | | | Submitted by: Tomokazu HARADA <tkhara@osk4.3web.ne.jp>
* Added Intel Gigabit Ethernet card to device menu.hosokawa2000-11-071-0/+1
|
* Add the ATA RAID device 'ar'.sos2000-10-291-0/+1
|
* Added NEC PC-9801-83, 84, PC-9801-103, 104, PC-9801N-25 and PC-9801N-J02Rnyan2000-10-021-0/+1
| | | | | | | | support which use National Semiconductor DP8393X (SONIC) as ethernet controller. Currently, this driver is used on only PC-98. Submitted by: Motomichi Matsuzaki <mzaki@e-mail.ne.jp> Obtained from: NetBSD/pc98
* add ``xe'' driversanpei2000-09-221-0/+1
| | | | Approved by: jkh
* Add a new driver for the AMD PCnet/FAST, FAST+ and Home PCI adapters.wpaul2000-09-201-0/+1
| | | | | | | | | | | | | | Previously, these cards were supported by the lnc driver (and they still are, but the pcn driver will claim them first), which is fine except the lnc driver runs them in 16-bit LANCE compatibility mode. The pcn driver runs these chips in 32-bit mode and uses the RX alignment feature to achieve zero-copy receive. (Which puts it in the same class as the xl, fxp and tl chipsets.) This driver is also MI, so it will work on the x86 and alpha platforms. (The lnc driver is still needed to support non-PCI cards. At some point, I'll need to newbusify it so that it too will me MI.) The Am79c978 HomePNA adapter is also supported.
* Teach sysinstall about 'aac'.msmith2000-09-131-0/+1
|
* Remove device type field - there are no block devices left.jkh2000-08-221-41/+32
|
* 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.
OpenPOWER on IntegriCloud