summaryrefslogtreecommitdiffstats
path: root/sys/amd64/conf
Commit message (Collapse)AuthorAgeFilesLines
* Change over the usb kernel options to the new stack (retaining existingthompsa2009-02-232-90/+29
| | | | naming). The old usb stack can be compiled in my prefixing the name with 'o'.
* Add uslcom to the build too.thompsa2009-02-151-0/+1
| | | | Reminded by: Michael Butler
* Switch over GENERIC kernels to USB2 by default.thompsa2009-02-151-31/+87
| | | | Tested by: make universe
* Add option GEOM_PART_EBR by default on amd64 and i386.marcel2009-02-101-0/+1
|
* Tidy NOTES a bit:wkoszek2009-02-071-3/+6
| | | | | | | | | | - remove misleading nve/nfe comments, which make it hard to distinguish those two at a first glance - bring pbio documentation to the block comment together with other drivers I also brought commented out line responsible for si(4), since it seems to compile and already has respective comment in this file.
* ural(4) is already present in global NOTES, thus there is nowkoszek2009-02-061-2/+0
| | | | | | | | | need to explicitly list it here once again. This removes: WARNING: duplicate option `DEV_URAL' encountered. WARNING: duplicate device `ural' encountered. Warnings when compiling LINT on amd64.
* Fix AGP debugging code:wkoszek2009-02-061-0/+5
| | | | | | | | | | | | - correct format strings - fill opt_agp.h if AGP_DEBUG is defined - bring AGP_DEBUG to LINT by mentioning it in NOTES This should hopefully fix a warning that was... Found by: Coverity Prevent(tm) CID: 3676 Tested on: amd64, i386
* Take NTFS option out to match i386 GENERIC.sobomax2009-01-191-1/+0
| | | | Suggested by: phk, luigi
* asr(4) is not amd64-clean, not amr(4).sobomax2009-01-191-3/+3
| | | | | Pointy hat to: myself Submitted by: scottl
* Comment amr(4) out - according to scottl it's not 64-bit clean.sobomax2009-01-191-1/+2
|
* Whitespace-only: reduce diff to the i386 GENERIC.sobomax2009-01-191-4/+4
|
* Add asr(4) and stge(4) from i386 GENERIC. Both drivers compile on amd64 andsobomax2009-01-191-0/+2
| | | | | | there is no particular reason for them to be i386-only. MFC after: 2 weeks
* MFp4: //depot/projects/usb@155990thompsa2009-01-131-0/+4
| | | | | | Add USB scanner support to USB2 config files. Submitted by: Hans Petter Selasky
* Documentation-only change:luigi2009-01-131-2/+8
| | | | | | | | | | | | | | | | | | | | - add a reference to the config(5) manpage; - hopefully clarify the format of the 'env FILENAME' directive. I am putting these notes in sys/${arch}/conf/GENERIC and not in sys/conf/NOTES because: 1. i386/GENERIC already had reference to a similar option (hints..) and to documentation (handbook) 2. GENERIC is what most users look at when they have to modify or create a new kernel config, so having the suggestion there is more effective. I am only touching i386 and amd64 because the other GENERIC files are already out of sync, and I am not sure what is the overall plan. MFC after: 3 days
* Add commented out options KDTRACE_HOOKS and, for amd64, KDRACE_FRAME,rwatson2009-01-051-0/+2
| | | | | | | to GENERIC configuration files. This brings what's in 8.x in sync with what is in 7.x, but does not change any current defaults. Possibly they should now be enabled in head by default?
* Disable USB bluetooth (needs netgraph built in) and USB audio (doesn'trpaulo2008-12-301-3/+3
| | | | compile).
* Add a kernel config file so that users have less difficulty testingrpaulo2008-12-301-0/+110
| | | | | | USBng. If it makes sense, it could be done for arm/mips too.
* Make gpart the default partitioning class on all platforms.marcel2008-12-171-2/+2
| | | | | | | Both ia64 and powerpc were using gpart exclusively already so there's no change for those two. Discussed on: arch@
* Remove "[KEEP THIS!]" from COMPAT_43TTY. It's not really that important.ed2008-12-021-1/+1
| | | | | | | Sgtty is a programming interface that has been replaced by termios over the years. In June we already removed <sgtty.h>, which exposes the ioctl()'s that are implemented by this interface. The importance of this flag is overrated right now.
* Switch to ath hal source code. Note this removes the ath_halsam2008-12-012-8/+8
| | | | | | | | | | | | | | | | | module; the ath module now brings in the hal support. Kernel config files are almost backwards compatible; supplying device ath_hal gives you the same chip support that the binary hal did but you must also include options AH_SUPPORT_AR5416 to enable the extended format descriptors used by 11n parts. It is now possible to control the chip support included in a build by specifying exactly which chips are to be supported in the config file; consult ath_hal(4) for information.
* Add ale(4), a driver for Atheros AR8121/AR8113/AR8114 PCIe ethernetyongari2008-11-121-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | controller. The controller is also known as L1E(AR8121) and L2E(AR8113/AR8114). Unlike its predecessor Attansic L1, AR8121/AR8113/AR8114 uses completely different Rx logic such that it requires separate driver. Datasheet for AR81xx is not available to open source driver writers but it shares large part of Tx and PHY logic of L1. I still don't understand some part of register meaning and some MAC statistics counters but the driver seems to have no critical issues for performance and stability. The AR81xx requires copy operation to pass received frames to upper stack such that ale(4) consumes a lot of CPU cycles than that of other controller. A couple of silicon bugs also adds more CPU cycles to address the known hardware bug. However, if you have fast CPU you can still saturate the link. Currently ale(4) supports the following hardware features. - MSI. - TCP Segmentation offload. - Hardware VLAN tag insertion/stripping with checksum offload. - Tx TCP/UDP checksum offload and Rx IP/TCP/UDP checksum offload. - Tx/Rx interrupt moderation. - Hardware statistics counters. - Jumbo frame. - WOL. AR81xx PCIe ethernet controllers are mainly found on ASUS EeePC or P5Q series of ASUS motherboards. Special thanks to Jeremy Chadwick who sent the hardware to me. Without his donation writing a driver for AR81xx would never have been possible. Big thanks to all people who reported feedback or tested patches. HW donated by: koitsu Tested by: bsam, Joao Barros <joao.barros <> gmail DOT com > Jan Henrik Sylvester <me <> janh DOT de > Ivan Brawley < ivan <> brawley DOT id DOT au >, CURRENT ML
* - Add driver for Attansic L2 FastEthernet controller found onstas2008-10-031-0/+1
| | | | | | | | | Asus EeePC and some Asus mainboards. Reviewed by: yongari, rpaulo, jhb Tested by: many Approved by: kib (mentor) MFC after: 1 week
* Integrate the new MPSAFE TTY layer to the FreeBSD operating system.ed2008-08-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The last half year I've been working on a replacement TTY layer for the FreeBSD kernel. The new TTY layer was designed to improve the following: - Improved driver model: The old TTY layer has a driver model that is not abstract enough to make it friendly to use. A good example is the output path, where the device drivers directly access the output buffers. This means that an in-kernel PPP implementation must always convert network buffers into TTY buffers. If a PPP implementation would be built on top of the new TTY layer (still needs a hooks layer, though), it would allow the PPP implementation to directly hand the data to the TTY driver. - Improved hotplugging: With the old TTY layer, it isn't entirely safe to destroy TTY's from the system. This implementation has a two-step destructing design, where the driver first abandons the TTY. After all threads have left the TTY, the TTY layer calls a routine in the driver, which can be used to free resources (unit numbers, etc). The pts(4) driver also implements this feature, which means posix_openpt() will now return PTY's that are created on the fly. - Improved performance: One of the major improvements is the per-TTY mutex, which is expected to improve scalability when compared to the old Giant locking. Another change is the unbuffered copying to userspace, which is both used on TTY device nodes and PTY masters. Upgrading should be quite straightforward. Unlike previous versions, existing kernel configuration files do not need to be changed, except when they reference device drivers that are listed in UPDATING. Obtained from: //depot/projects/mpsafetty/... Approved by: philip (ex-mentor) Discussed: on the lists, at BSDCan, at the DevSummit Sponsored by: Snow B.V., the Netherlands dcons(4) fixed by: kan
* - Add cpuctl(4) pseudo-device driver to provide access to some low-levelstas2008-08-081-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | features of CPUs like reading/writing machine-specific registers, retrieving cpuid data, and updating microcode. - Add cpucontrol(8) utility, that provides userland access to the features of cpuctl(4). - Add subsequent manpages. The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX is created for each cpu present in the systems. The pseudo-device minor number corresponds to the cpu number in the system. The cpuctl(4) pseudo- device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID and UPDATE. The first pair alows the caller to read/write machine-specific registers from the correspondent CPU. cpuid data could be retrieved using the CPUID call, and microcode updates are applied via UPDATE. The permissions are inforced based on the pseudo-device file permissions. RDMSR/CPUID will be allowed when the caller has read access to the device node, while WRMSR/UPDATE will be granted only when the node is opened for writing. There're also a number of priv(9) checks. The cpucontrol(8) utility is intened to provide userland access to the cpuctl(4) device features. The utility also allows one to apply cpu microcode updates. Currently only Intel and AMD cpus are supported and were tested. Approved by: kib Reviewed by: rpaulo, cokane, Peter Jeremy MFC after: 1 month
* Disconnect drivers that haven't been ported to MPSAFE TTY yet.ed2008-08-032-54/+0
| | | | | | | | | | | | | As clearly mentioned on the mailing lists, there is a list of drivers that have not been ported to the MPSAFE TTY layer yet. Remove them from the kernel configuration files. This means people can now still use these drivers if they explicitly put them in their kernel configuration file, which is good. People should keep in mind that after August 10, these drivers will not work anymore. Even though owners of the hardware are capable of getting these drivers working again, I will see if I can at least get them to a compilable state (if time permits).
* Add igb to the default kerneljfv2008-07-301-1/+2
| | | | MFC after:ASAP
* Make uart(4) the default serial port driver on i386 and amd64.ed2008-07-132-16/+15
| | | | | | | | | | | The uart(4) driver has the advantage of supporting a wider variety of hardware on a greater amount of platforms. This driver has already been the standard on platforms such as ia64, powerpc and sparc64. I've decided not to change anything on pc98. I'd rather let people from the pc98 team look at this. Approved by: philip (mentor), marcel
* Add HWPMC_HOOKS to GENERIC kernels, this makes hwpmc.ko work outdelphij2008-07-071-0/+1
| | | | of the box.
* Add et(4), a port of DragonFly's Agere ET1310 10/100/Gigabitdelphij2008-06-201-0/+1
| | | | | | | | Ethernet device driver, written by sephe@ Obtained from: DragonFly Sponsored by: iXsystems MFC after: 2 weeks
* Add jme(4) to the list of drivers supported by GENERIC kernel.yongari2008-05-271-0/+1
|
* Remove ISDN4BSD (I4B) from HEAD as it is not MPSAFE andbz2008-05-261-114/+0
| | | | | | | | | | | | | | | | | | parts relied on the now removed NET_NEEDS_GIANT. Most of I4B has been disconnected from the build since July 2007 in HEAD/RELENG_7. This is what was removed: - configuration in /etc/isdn - examples - man pages - kernel configuration - sys/i4b (drivers, layers, include files) - user space tools - i4b support from ppp - further documentation Discussed with: rwatson, re
* Add age(4) to the list of drivers supported by GENERIC kernel.yongari2008-05-191-0/+1
|
* Resort the if_ti driver to match the PCI Network cards instead of placingremko2008-05-171-1/+1
| | | | | | | | | it under the mii devices list. PR: kern/123147 Submitted by: gavin Approved by: imp (mentor, implicit) MFC after: 3 days
* enable IEEE80211_DEBUG and IEEE80211_AMPDU_AGE by defaultsam2008-05-031-0/+2
|
* Intel 4965 wireless driver (derived from openbsd driver of the same name)sam2008-04-291-0/+2
|
* Multi-bss (aka vap) support for 802.11 devices.sam2008-04-201-2/+0
| | | | | | | | | | | Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
* move awi to the Attic; it will not make the jump to the new world ordersam2008-04-201-1/+0
| | | | Reviewed by: imp
* Connect k8temp(4) to the build.rpaulo2008-04-121-0/+2
|
* Add kernel module support for nfslockd and krpc. Use the module systemdfr2008-03-271-0/+1
| | | | | | | to detect (or load) kernel NLM support in rpc.lockd. Remove the '-k' option to rpc.lockd and make kernel NLM the default. A user can still force the use of the old user NLM by building a kernel without NFSLOCKD and/or removing the nfslockd.ko module.
* Back in the good old days, PC's had random pieces of rock forphk2008-03-261-13/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | frequency generation and what frequency the generated was anyones guess. In general the 32.768kHz RTC clock x-tal was the best, because that was a regular wrist-watch Xtal, whereas the X-tal generating the ISA bus frequency was much lower quality, often costing as much as several cents a piece, so it made good sense to check the ISA bus frequency against the RTC clock. The other relevant property of those machines, is that they typically had no more than 16MB RAM. These days, CPU chips croak if their clocks are not tightly within specs and all necessary frequencies are derived from the master crystal by means if PLL's. Considering that it takes on average 1.5 second to calibrate the frequency of the i8254 counter, that more likely than not, we will not actually use the result of the calibration, and as the final clincher, we seldom use the i8254 for anything besides BEL in syscons anyway, it has become time to drop the calibration code. If you need to tell the system what frequency your i8254 runs, you can do so from the loader using hw.i8254.freq or using the sysctl kern.timecounter.tc.i8254.frequency.
* Belatedly add BPF_JITTER in NOTES for supported architectures.jkim2008-03-241-0/+4
|
* Remove kernel support for M:N threading.jeff2008-03-121-3/+0
| | | | | | | | While the KSE project was quite successful in bringing threading to FreeBSD, the M:N approach taken by the kse library was never developed to its full potential. Backwards compatibility will be provided via libmap.conf for dynamically linked binaries and static binaries will be broken.
* Import uslcom(4) from OpenBSD - this is a driver for Silicon Laboratoriesrink2008-03-051-0/+1
| | | | | | | | CP2101/CP2102 based USB serial adapters. Reviewed by: imp, emaste Obtained from: OpenBSD MFC after: 2 weeks
* Eliminate whitespace diffs to the i386 version.ru2008-02-191-2/+1
|
* Remove the rr232x driver. It has been superceded by the hptrr driver.scottl2008-02-032-6/+0
|
* Add COMPAT_FREEBSD7 and enable it in configs that have COMPAT_FREEBSD6.jhb2008-01-071-0/+1
|
* Add asmc(4).rpaulo2007-12-281-1/+2
| | | | Requested by: njl (mentor)
* Add the 'hptrr' driver for supporting the following Highpoint RocketRAIDscottl2007-12-152-2/+7
| | | | | | | | | | | | | | | | | | | cards: o RocketRAID 172x series o RocketRAID 174x series o RocketRAID 2210 o RocketRAID 222x series o RocketRAID 2240 o RocketRAID 230x series o RocketRAID 231x series o RocketRAID 232x series o RocketRAID 2340 o RocketRAID 2522 Many thanks to Highpoint for their continued support of FreeBSD. Submitted by: Highpoint
* Break out stack(9) from ddb(4):rwatson2007-12-021-0/+1
| | | | | | | | | | | | | | | | | | | | - Introduce per-architecture stack_machdep.c to hold stack_save(9). - Introduce per-architecture machine/stack.h to capture any common definitions required between db_trace.c and stack_machdep.c. - Add new kernel option "options STACK"; we will build in stack(9) if it is defined, or also if "options DDB" is defined to provide compatibility with existing users of stack(9). Add new stack_save_td(9) function, which allows the capture of a stacktrace of another thread rather than the current thread, which the existing stack_save(9) was limited to. It requires that the thread be neither swapped out nor running, which is the responsibility of the consumer to enforce. Update stack(9) man page. Build tested: amd64, arm, i386, ia64, powerpc, sparc64, sun4v Runtime tested: amd64 (rwatson), arm (cognet), i386 (rwatson)
* Remove XRPU driver, after asking all the users.phk2007-12-011-2/+0
|
OpenPOWER on IntegriCloud