diff options
Diffstat (limited to 'Documentation')
68 files changed, 5103 insertions, 1233 deletions
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index 39516f871..dc29ec22b 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX @@ -25,12 +25,16 @@ SMP.txt - notes, and "To Fix" list for multi-processor Linux. (see smp.tex) VGA-softcursor.txt - how to change your VGA cursor from a blinking underscore. +arm/ + - directory with info about Linux on the ARM architecture. binfmt_misc.txt - info on the kernel support for extra binary formats. cdrom/ - directory with information on the CD-ROM drivers that Linux has. +cpqarray.txt + - info on using Compaq's SMART2 Intelligent Disk Array Controllers. devices.tex - - TeX source listing of all the nodes in /dev/ with major minor #'s + - LaTeX source listing of all the nodes in /dev/ with major minor #'s devices.txt - plain ASCII listing of all the nodes in /dev/ with major minor #'s digiboard.txt @@ -39,12 +43,16 @@ digiepca.txt - info on Digi Intl. {PC,PCI,EISA}Xx and Xem series cards. exception.txt - how Linux v2.2 handles exceptions without verify_area etc. +fb/ + - directory with info on the frame buffer graphics abstraction layer. filesystems/ - directory with info on the various filesystems that Linux supports. ftape.txt - notes about the floppy tape device driver hayes-esp.txt - info on using the Hayes ESP serial driver. +i386/ + - directory with info about Linux on the intel ix86 architecture. ide.txt - important info for users of ATA devices (IDE/EIDE disks and CD-ROMS) initrd.txt @@ -57,10 +65,18 @@ java.txt - info on the in-kernel binary support for Java(tm) joystick.txt - info on using joystick devices (and driver) with Linux. +joystick-api.txt + - API specification for applications that will be using the joystick. +joystick-parport.txt + - info on how to hook joysticks/gamepads to the parallel port. kbuild/ - directory with info about the kernel build process +kernel-docs.txt + - listing of various WWW + books that document kernel internals. +kernel-parameters.txt + - summary listing of command line / boot prompt args for the kernel. kmod.txt - - - info on the kernel module loader/unloader (kerneld replacement) + - info on the kernel module loader/unloader (kerneld replacement). locks.txt - info on file locking implementations, flock() vs. fcntl(), etc. logo.gif @@ -79,6 +95,8 @@ md.txt - info on boot arguments for the multiple devices driver memory.txt - info on typical Linux memory problems. +mkdev.ida + - script to make /dev entries for Intelligent Disk Array Controllers. modules.txt - short guide on how to make kernel parts into loadable modules mtrr.txt @@ -101,20 +119,26 @@ pcwd-watchdog.txt - info and sample code for using with the PC Watchdog reset card. powerpc/ - directory with info on using Linux with the PowerPC. +proc.txt + - detailed info on Linux's /proc filesystem. ramdisk.txt - short guide on how to set up and use the RAM disk. riscom8.txt - notes on using the RISCom/8 multi-port serial driver. rtc.txt - notes on how to use the Real Time Clock (aka CMOS clock) driver. +scsi-generic.txt + - info on the sg driver for generic (non-disk/CD/tape) SCSI devices. scsi.txt - short blurb on using SCSI support as a module. serial-console.txt - how to set up Linux with a serial line console as the default. +sgi-visws.txt + - short blurb on the SGI Visual Workstations. smart-config.txt - description of the Smart Config makefile feature. smp.tex - - TeX document describing implementation of Multiprocessor Linux + - LaTeX document describing implementation of Multiprocessor Linux smp.txt - a few more notes on symmetric multi-processing sound/ @@ -127,6 +151,8 @@ stallion.txt - info on using the Stallion multiport serial driver. svga.txt - short guide on selecting video modes at boot via VGA BIOS. +sx.txt + - info on the Specialix SX/SI multiport serial driver. sysctl/ - directory with info on the /proc/sys/* files sysrq.txt @@ -135,6 +161,8 @@ transname.txt - how to use name translation to ease use of diskless systems. unicode.txt - info on the Unicode character/font mapping used in Linux. +video4linux/ + - directory with info regarding video/TV/radio cards and linux. watchdog.txt - how to auto-reboot Linux if it has "fallen and can't get up". ;-) xterm-linux.xpm diff --git a/Documentation/Changes b/Documentation/Changes index ce50723e9..d69f5130f 100644 --- a/Documentation/Changes +++ b/Documentation/Changes @@ -61,7 +61,7 @@ running, the suggested command should tell you. - Bash 1.14.7 ; bash -version - Ncpfs 2.2.0 ; ncpmount -v - Pcmcia-cs 3.0.7 ; cardmgr -V -- PPP 2.3.5 ; pppd --version +- PPP 2.3.9 ; pppd --version - Util-linux 2.9i ; chsh -v Upgrade notes @@ -238,13 +238,12 @@ are you need to upgrade to a more recent net-tools that understands the new /proc/net/dev format. This will also provide support for new features like IPv6. - As of 2.1.102, the IP firewalling code has been replaced; ipfwadm -will no longer work. You need to obtain "ipchains," available from -http://www.rustcorp.com/linux/ipchains/ , and use that instead of -ipfwadm. - - To use masq forwarding you will need to obtain "ipmasqadm," -available from http://juanjox.linuxhq.com/ . + The IP firewalling and NAT code has been replaced again. The +actual modules (including ipfwadm and ipchains backwards-compatibility +modules) are currently distributed separately: see + http://antarctica.penguincomputing.com/~netfilter/ + http://www.samba.org/netfilter/ + http://netfilter.kernelnotes.org DHCP clients for 2.0 do not work with the new networking code in the 2.2 kernel. You will need to upgrade your dhcpcd / dhcpclient. @@ -390,8 +389,8 @@ support utils to the latest release of pcmcia-cs. PPP === - Due to changes in the routing code, those of you using PPP -networking will need to upgrade your pppd. + Due to changes in the PPP driver and routing code, those of you +using PPP networking will need to upgrade your pppd. iBCS ==== @@ -420,9 +419,16 @@ PCI utils ========= Linux PCI utils are available; these include lspci, which displays -the detailed information about your system's PCI devices which used to -be in /proc/pci, and setpci, which allws you to read and write -configuration registers on your PCI devices. +detailed information about your system's PCI devices (much more than +the basic things in /proc/pci), and setpci, which allows you to read +and write PCI configuration registers of your devices. + +Powertweak +========== + + The PCI Bridge Optimization has been removed from the kernel. If you +think your BIOS does a poor job when setting up your chipset, there +is a utility called PowerTweak whose job is to tune chipset parameters. Xosview ======= @@ -689,8 +695,8 @@ ftp://metalab.unc.edu/pub/Linux/system/serial/setserial-2.15.tar.gz PPP === -The 2.3.5 release: -ftp://cs.anu.edu.au/pub/software/ppp/ppp-2.3.5.tar.gz +The 2.3.9 release: +ftp://cs.anu.edu.au/pub/software/ppp/ppp-2.3.9.tar.gz IP Chains ========= @@ -735,9 +741,16 @@ http://www.cs.kuleuven.ac.be/~geert/bin/fbset-2.0-pre-19981104.tar.gz PCI utils ========= -The 1.09 release: -ftp://atrey.karlin.mff.cuni.cz/pub/linux/pci/pciutils-1.09.tar.gz -ftp://metalab.unc.edu/pub/Linux/hardware/pciutils-1.09.tar.gz +The 2.0 release: +ftp://atrey.karlin.mff.cuni.cz/pub/linux/pci/pciutils-2.0.tar.gz +ftp://metalab.unc.edu/pub/Linux/hardware/pciutils-2.0.tar.gz + +Powertweak +========== + +The 0.1.2 release: +http://linux.powertweak.com/files/powertweak-0.1.2.tgz +ftp://atrey.karlin.mff.cuni.cz/pub/linux/pci/powertweak/powertweak-0.1.2.tgz Tunelp ====== diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle index edba24699..e0915bd2c 100644 --- a/Documentation/CodingStyle +++ b/Documentation/CodingStyle @@ -210,3 +210,26 @@ options "-kr -i8" (stands for "K&R, 8 character indents"). "indent" has a lot of options, and especially when it comes to comment re-formatting you may want to take a look at the manual page. But remember: "indent" is not a fix for bad programming. + + + Chapter 7: Configuration-files + +For configuration options (arch/xxx/config.in, and all the Config.in files), +somewhat different indentation is used. + +An indention level of 3 is used in the code, while the text in the config- +options should have an indention-level of 2 to indicate dependencies. The +latter only applies to bool/tristate options. For other options, just use +common sense. An example: + +if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then + tristate 'Apply nitroglycerine inside the keyboard (DANGEROUS)' CONFIG_BOOM + if [ "$CONFIG_BOOM" != "n" ]; then + bool ' Output nice messages when you explode' CONFIG_CHEER + fi +fi + +Generally, CONFIG_EXPERIMENTAL should surround all options not considered +stable. All options that are known to trash data (experimental write- +support for file-systems, for instance) should be denoted (DANGEROUS), other +Experimental options should be denoted (EXPERIMENTAL). diff --git a/Documentation/Configure.help b/Documentation/Configure.help index 5be8caee1..3c6416e8a 100644 --- a/Documentation/Configure.help +++ b/Documentation/Configure.help @@ -1,7 +1,7 @@ # Maintained by Axel Boldt (boldt@math.ucsb.edu) # # This version of the Linux kernel configuration help texts -# corresponds to the kernel versions 2.2.x. +# corresponds to the kernel versions 2.3.x. # # Translations of this file available on the WWW: # @@ -168,6 +168,11 @@ CONFIG_MATHEMU on the Alpha. The only time you would ever not say Y is to say M in order to debug the code. Say Y unless you know what you are doing. +Big memory support +CONFIG_BIGMEM + This option is required if you want to utilize physical memory which + is not covered by the kernel virtual address space (> 1GB). + Normal PC floppy disk support CONFIG_BLK_DEV_FD If you want to use the floppy disk drive(s) of your PC under Linux, @@ -546,6 +551,20 @@ CONFIG_BLK_DEV_IDEDMA_PCI It is safe to say Y to this question. +Use DMA by default when available +CONFIG_IDEDMA_PCI_AUTO + Prior to kernel version 2.1.112, Linux used to automatically use + DMA for IDE drives and chipsets which support it. Due to concerns + about a couple of cases where buggy hardware may have caused damage, + the default is now to NOT use DMA automatically. To revert to the + previous behaviour, say Y to this question. + + If you suspect your hardware is at all flakey, say N here. + Do NOT email the IDE kernel people regarding this issue! + + It is normally safe to answer Y to this question unless your + motherboard uses a VIA VP2 chipset, in which case you should say N. + Good-Bad DMA Model-Firmware (EXPERIMENTAL) IDEDMA_NEW_DRIVE_LISTINGS This test compares both the model and firmware revision for buggy drives @@ -555,23 +574,6 @@ IDEDMA_NEW_DRIVE_LISTINGS If in doubt, say N. -Generic ATA-66 support (DANGEROUS) -CONFIG_IDEDMA_ULTRA_66 - This allows for your Generic IDE control to attempt support for - using ATA-66 or UDMA-66 transfer modes 3/4. If you are not sure what you - are attempting, "DO NOT" even think about this option, unless your - mainboard's chipset is verified. Do not complain to anyone if you - do not know what you are doing and are just playing around. - This option has no known success cases to date. - - Say N, or beware......... - -Winbond SL82c105 support -CONFIG_BLK_DEV_SL82C105 - If you have a Winbond SL82c105 IDE controller, say Y here to enable - special configuration for this chip. This is common on various CHRP - motherboards, but could be used elsewhere. If in doubt, say Y. - Boot off-board chipsets first support CONFIG_BLK_DEV_OFFBOARD Normally, IDE controllers built into the motherboard (on-board @@ -590,96 +592,31 @@ CONFIG_BLK_DEV_OFFBOARD If in doubt, say N. -Use DMA by default when available -CONFIG_IDEDMA_PCI_AUTO - Prior to kernel version 2.1.112, Linux used to automatically use - DMA for IDE drives and chipsets which support it. Due to concerns - about a couple of cases where buggy hardware may have caused damage, - the default is now to NOT use DMA automatically. To revert to the - previous behaviour, say Y to this question. - - If you suspect your hardware is at all flakey, say N here. - Do NOT email the IDE kernel people regarding this issue! - - It is normally safe to answer Y to this question unless your - motherboard uses a VIA VP2 chipset, in which case you should say N. - -Other IDE chipset support -CONFIG_IDE_CHIPSETS - Say Y here if you want to include enhanced support for various IDE - interface chipsets used on motherboards and add-on cards. You can - then pick your particular IDE chip from among the following options. - This enhanced support may be necessary for Linux to be able to - access the 3rd/4th drives in some systems. It may also enable - setting of higher speed I/O rates to improve system performance with - these chipsets. Most of these also require special kernel boot - parameters to actually turn on the support at runtime; you can find - a list of these in the file Documentation/ide.txt. - - People with SCSI-only systems can say N here. - -Generic 4 drives/port support -CONFIG_BLK_DEV_4DRIVES - Certain older chipsets, including the Tekram 690CD, use a single set - of I/O ports at 0x1f0 to control up to four drives, instead of the - customary two drives per port. Support for this can be enabled at - runtime using the "ide0=four" kernel boot parameter if you say Y - here. - -DTC-2278 support -CONFIG_BLK_DEV_DTC2278 - This driver is enabled at runtime using the "ide0=dtc2278" kernel - boot parameter. It enables support for the secondary IDE interface - of the DTC-2278 card, and permits faster I/O speeds to be set as - well. See the Documentation/ide.txt and drivers/block/dtc2278.c - files for more info. +AEC6210 chipset support +CONFIG_BLK_DEV_AEC6210 + This driver adds up to 4 more eide devices sharing a single interrupt. + This add-on card is a bootable PCI UDMA controller. In order to get this + card to initialize correctly in some cases, you should include this driver. -Holtek HT6560B support -CONFIG_BLK_DEV_HT6560B - This driver is enabled at runtime using the "ide0=ht6560b" kernel - boot parameter. It enables support for the secondary IDE interface - of the Holtek card, and permits faster I/O speeds to be set as well. - See the Documentation/ide.txt and drivers/block/ht6560b.c files for - more info. + This prefers CONFIG_IDEDMA_PCI_AUTO to be enabled, regardless. -PROMISE DC4030 support (EXPERIMENTAL) -CONFIG_BLK_DEV_PDC4030 - This driver provides support for the secondary IDE interface and - cache of Promise IDE chipsets, e.g. DC4030 and DC5030. This driver - is known to incur timeouts/retries during heavy I/O to drives - attached to the secondary interface. CDROM and TAPE devices are not - supported yet. This driver is enabled at runtime using the - "ide0=dc4030" kernel boot parameter. See the Documentation/ide.txt - and drivers/block/pdc4030.c files for more info. + Please read the comments at the top of drivers/block/aec6210.c -PS/2 ESDI hard disk support -CONFIG_BLK_DEV_PS2 - Say Y here if you have a PS/2 machine with a MCA bus and an ESDI - hard disk. - - If you want to compile the driver as a module ( = code which can be - inserted in and removed from the running kernel whenever you want), - say M here and read Documentation/modules.txt. The module will be - called ps2esdi.o. +ALI M15x3 chipset support (EXPERIMENTAL) +CONFIG_BLK_DEV_ALI15X3 + This driver ensures (U)DMA support for ALI 1533, 1543 and 1543C + onboard chipsets. It also tests for Simplex mode and enables + normal dual channel support. -Tekram TRM290 chipset support (EXPERIMENTAL) -CONFIG_BLK_DEV_TRM290 - This driver adds support for bus master DMA transfers - using the Tekram TRM290 PCI IDE chip. Volunteers are - needed for further tweaking and development. - Please read the comments at the top of drivers/block/trm290.c. + This requires CONFIG_IDEDMA_PCI_AUTO to be enabled. -OPTi 82C621 enhanced support (EXPERIMENTAL) -CONFIG_BLK_DEV_OPTI621 - This is a driver for the OPTi 82C621 EIDE controller. - Please read the comments at the top of drivers/block/opti621.c. + Please read the comments at the top of drivers/block/alim15x3.c -NS87415 support (EXPERIMENTAL) -CONFIG_BLK_DEV_NS87415 - This driver adds detection and support for the NS87415 chip - (used in SPARC64, among others). + If unsure, say N. - Please read the comments at the top of drivers/block/ns87415.c. +CMD646 chipset support (EXPERIMENTAL) +CONFIG_BLK_DEV_CMD646 + Say Y here if you have an IDE controller like this. CY82C693 chipset support (EXPERIMENTAL) CONFIG_BLK_DEV_CY82C693 @@ -691,37 +628,67 @@ CONFIG_BLK_DEV_CY82C693 Please read the comments at the top of drivers/block/cy82c693.c -VIA82C586 chipset support (EXPERIMENTAL) -CONFIG_BLK_DEV_VIA82C586 - This allows you to to configure your chipset for a better use while - running (U)DMA: it will allow you to enable efficiently the second - channel dma usage, as it is may not be set by BIOS. It allows you to - run a kernel command line at boot time in order to set fifo config. - If no command line is provided, it will try to set fifo configuration - at its best. It will allow you to get a proc/ide/via display - (while running a "cat") provided you enabled "proc" support and - set DISPLAY_APOLLO_TIMINGS in via82c586.c +HPT34X chipset support +CONFIG_BLK_DEV_HPT34X + This driver adds up to 4 more EIDE devices sharing a single + interrupt. The HPT343 chipset in its current form is a non-bootable or + HPT345/HPT363 chipset is bootable (needs BIOS FIX) PCI UDMA controllers. + This driver requires dynamic tuning of the chipset during the ide-probe + at boot. It is reported to support DVD II drives, by the manufacturer. + + Please read the comments at the top of drivers/block/hpt34x.c +HPT34X DMA support (DANGEROUS) +CONFIG_BLK_DEV_HPT34X_DMA This requires CONFIG_IDEDMA_PCI_AUTO to be enabled. - If unsure, say N. + Please read the comments at the top of drivers/block/hpt34x.c -CMD646 chipset support (EXPERIMENTAL) -CONFIG_BLK_DEV_CMD646 - Say Y here if you have an IDE controller like this. +HPT366 chipset support +CONFIG_BLK_DEV_HPT366 + This is an Ultra DMA chipset for ATA-66. + This driver adds up to 4 more EIDE devices sharing a single + interrupt. The HPT366 chipset in its current form is a non-bootable. + This driver requires dynamic tuning of the chipset during the ide-probe + at boot. It is reported to support DVD II drives, by the manufacturer. -ALI M15x3 chipset support (EXPERIMENTAL) -CONFIG_BLK_DEV_ALI15X3 - This driver ensures (U)DMA support for ALI 1533, 1543 and 1543C - onboard chipsets. It also tests for Simplex mode and enables - normal dual channel support. + Please read the comments at the top of drivers/block/hpt366.c - This requires CONFIG_IDEDMA_PCI_AUTO to be enabled. +Intel PIIXn chipsets support +CONFIG_BLK_DEV_PIIX + This driver adds PIO mode setting and tuning for all PIIX IDE + controllers by Intel. Since the BIOS can sometimes improperly tune + PIO 0-4 mode settings, this allows dynamic tuning of the chipset + via the standard end-user tool 'hdparm'. - Please read the comments at the top of drivers/block/alim15x3.c + Please read the comments at the top of drivers/block/piix.c + + If unsure, say N. + +PIIXn Tuning support (EXPERIMENTAL) +CONFIG_BLK_DEV_PIIX_TUNING + This driver extension adds DMA mode setting and tuning for all PIIX IDE + controllers by Intel. Since the BIOS can sometimes improperly setup + the device/adapter combination and speed limits, It has become a necessity + to back/forward speed devices as needed. + + Case 430HX/440FX PIIX3 need speed limits to reduce UDMA to DMA mode 2 + if the BIOS can to perform this task at INIT. If unsure, say N. +NS87415 support (EXPERIMENTAL) +CONFIG_BLK_DEV_NS87415 + This driver adds detection and support for the NS87415 chip + (used in SPARC64, among others). + + Please read the comments at the top of drivers/block/ns87415.c. + +OPTi 82C621 enhanced support (EXPERIMENTAL) +CONFIG_BLK_DEV_OPTI621 + This is a driver for the OPTi 82C621 EIDE controller. + Please read the comments at the top of drivers/block/opti621.c. + PROMISE PDC20246/PDC20262 support CONFIG_BLK_DEV_PDC202XX Promise Ultra33 or PDC20246. @@ -764,54 +731,127 @@ PDC202XX_FORCE_MASTER_MODE Say N. -AEC6210 chipset support -CONFIG_BLK_DEV_AEC6210 - This driver adds up to 4 more eide devices sharing a single interrupt. - This add-on card is a bootable PCI UDMA controller. In order to get this - card to initialize correctly in some cases, you should include this driver. +SiS5513 chipset support +CONFIG_BLK_DEV_SIS5513 + This driver ensures (U)DMA support for SIS5513 chipset based mainboards. + SiS620/530 UDMA mode 4, SiS5600/5597 UDMA mode 2, all other DMA mode 2 + limited chipsets are unsupported to date. - This prefers CONFIG_IDEDMA_PCI_AUTO to be enabled, regardless. + This requires CONFIG_IDEDMA_PCI_AUTO to be enabled. - Please read the comments at the top of drivers/block/aec6210.c + Please read the comments at the top of drivers/block/sis5513.c -Intel PIIXn chipsets support -CONFIG_BLK_DEV_PIIX - This driver adds PIO mode setting and tuning for all PIIX IDE - controllers by Intel. Since the BIOS can sometimes improperly tune - PIO 0-4 mode settings, this allows dynamic tuning of the chipset - via the standard end-user tool 'hdparm'. +Winbond SL82c105 support +CONFIG_BLK_DEV_SL82C105 + If you have a Winbond SL82c105 IDE controller, say Y here to enable + special configuration for this chip. This is common on various CHRP + motherboards, but could be used elsewhere. If in doubt, say Y. - Please read the comments at the top of drivers/block/piix.c +Tekram TRM290 chipset support (EXPERIMENTAL) +CONFIG_BLK_DEV_TRM290 + This driver adds support for bus master DMA transfers + using the Tekram TRM290 PCI IDE chip. Volunteers are + needed for further tweaking and development. + Please read the comments at the top of drivers/block/trm290.c. + +VIA82C586 chipset support (EXPERIMENTAL) +CONFIG_BLK_DEV_VIA82C586 + This allows you to to configure your chipset for a better use while + running (U)DMA: it will allow you to enable efficiently the second + channel dma usage, as it is may not be set by BIOS. It allows you to + run a kernel command line at boot time in order to set fifo config. + If no command line is provided, it will try to set fifo configuration + at its best. It will allow you to get a proc/ide/via display + (while running a "cat") provided you enabled "proc" support and + set DISPLAY_APOLLO_TIMINGS in via82c586.c + + This requires CONFIG_IDEDMA_PCI_AUTO to be enabled. If unsure, say N. -PIIXn Tuning support (EXPERIMENTAL) -CONFIG_BLK_DEV_PIIX_TUNING - This driver extension adds DMA mode setting and tuning for all PIIX IDE - controllers by Intel. Since the BIOS can sometimes improperly setup - the device/adapter combination and speed limits, It has become a necessity - to back/forward speed devices as needed. +Support for PowerMac IDE devices (must also enable IDE) +CONFIG_BLK_DEV_IDE_PMAC + No help for CONFIG_BLK_DEV_IDE_PMAC - Case 430HX/440FX PIIX3 need speed limits to reduce UDMA to DMA mode 2 - if the BIOS can to perform this task at INIT. +PowerMac IDE DMA support +CONFIG_BLK_DEV_IDEDMA_PMAC + No help for CONFIG_BLK_DEV_IDEDMA_PMAC - If unsure, say N. +Use DMA by default +CONFIG_IDEDMA_PMAC_AUTO + No help for CONFIG_IDEDMA_PMAC_AUTO -HPT34X chipset support -CONFIG_BLK_DEV_HPT34X - This driver adds up to 4 more EIDE devices sharing a single - interrupt. The HPT343 chipset in its current form is a non-bootable or - HPT345/HPT363 chipset is bootable (needs BIOS FIX) PCI UDMA controllers. - This driver requires dynamic tuning of the chipset during the ide-probe - at boot. It is reported to support DVD II drives, by the manufacturer. +ICS IDE interface support +CONFIG_BLK_DEV_IDE_ICSIDE + No help for CONFIG_BLK_DEV_IDE_ICSIDE - Please read the comments at the top of drivers/block/hpt343.c +ICS DMA support +CONFIG_BLK_DEV_IDEDMA_ICS + No help for CONFIG_BLK_DEV_IDEDMA_ICS -HPT34X DMA support (DANGEROUS) -CONFIG_BLK_DEV_HPT34X_DMA - This requires CONFIG_IDEDMA_PCI_AUTO to be enabled. +Use ICS DMA by default +CONFIG_IDEDMA_ICS_AUTO + No help for CONFIG_IDEDMA_ICS_AUTO - Please read the comments at the top of drivers/block/hpt343.c +RapIDE interface support +CONFIG_BLK_DEV_IDE_RAPIDE + No help for CONFIG_BLK_DEV_IDE_RAPIDE + +Other IDE chipset support +CONFIG_IDE_CHIPSETS + Say Y here if you want to include enhanced support for various IDE + interface chipsets used on motherboards and add-on cards. You can + then pick your particular IDE chip from among the following options. + This enhanced support may be necessary for Linux to be able to + access the 3rd/4th drives in some systems. It may also enable + setting of higher speed I/O rates to improve system performance with + these chipsets. Most of these also require special kernel boot + parameters to actually turn on the support at runtime; you can find + a list of these in the file Documentation/ide.txt. + + People with SCSI-only systems can say N here. + +Generic 4 drives/port support +CONFIG_BLK_DEV_4DRIVES + Certain older chipsets, including the Tekram 690CD, use a single set + of I/O ports at 0x1f0 to control up to four drives, instead of the + customary two drives per port. Support for this can be enabled at + runtime using the "ide0=four" kernel boot parameter if you say Y + here. + +ALI M14xx support +CONFIG_BLK_DEV_ALI14XX + This driver is enabled at runtime using the "ide0=ali14xx" kernel + boot parameter. It enables support for the secondary IDE interface + of the ALI M1439/1443/1445/1487/1489 chipsets, and permits faster + I/O speeds to be set as well. See the files Documentation/ide.txt + and drivers/block/ali14xx.c for more info. + +DTC-2278 support +CONFIG_BLK_DEV_DTC2278 + This driver is enabled at runtime using the "ide0=dtc2278" kernel + boot parameter. It enables support for the secondary IDE interface + of the DTC-2278 card, and permits faster I/O speeds to be set as + well. See the Documentation/ide.txt and drivers/block/dtc2278.c + files for more info. + +Holtek HT6560B support +CONFIG_BLK_DEV_HT6560B + This driver is enabled at runtime using the "ide0=ht6560b" kernel + boot parameter. It enables support for the secondary IDE interface + of the Holtek card, and permits faster I/O speeds to be set as well. + See the Documentation/ide.txt and drivers/block/ht6560b.c files for + more info. + +PROMISE DC4030 support (EXPERIMENTAL) +CONFIG_BLK_DEV_PDC4030 + This driver provides support for the secondary IDE interface and + cache of Promise IDE chipsets, e.g. DC4030 and DC5030. This driver + is known to incur timeouts/retries during heavy I/O to drives + attached to the secondary interface. CDROM and TAPE devices are not + supported yet. This driver is enabled at runtime using the + "ide0=dc4030" kernel boot parameter. See the Documentation/ide.txt + and drivers/block/pdc4030.c files for more info. QDI QD6580 support CONFIG_BLK_DEV_QD6580 @@ -828,14 +868,6 @@ CONFIG_BLK_DEV_UMC8672 See the files Documentation/ide.txt and drivers/block/umc8672.c for more info. -ALI M14xx support -CONFIG_BLK_DEV_ALI14XX - This driver is enabled at runtime using the "ide0=ali14xx" kernel - boot parameter. It enables support for the secondary IDE interface - of the ALI M1439/1443/1445/1487/1489 chipsets, and permits faster - I/O speeds to be set as well. See the files Documentation/ide.txt - and drivers/block/ali14xx.c for more info. - Amiga builtin Gayle IDE interface support CONFIG_BLK_DEV_GAYLE This is the IDE driver for the builtin IDE interface on some Amiga @@ -845,21 +877,6 @@ CONFIG_BLK_DEV_GAYLE (hard disks, CD-ROM drives, etc.) that are connected to the builtin IDE interface. -Falcon IDE interface support -CONFIG_BLK_DEV_FALCON_IDE - This is the IDE driver for the builtin IDE interface on the Atari Falcon. - Say Y if you have a Falcon and want to use IDE devices (hard disks, - CD-ROM drives, etc.) that are connected to the builtin IDE interface. - -Amiga Buddha/Catweasel IDE interface support (EXPERIMENTAL) -CONFIG_BLK_DEV_BUDDHA - This is the IDE driver for the IDE interfaces on the Buddha and - Catweasel expansion boards. It supports up to two interfaces on the - Buddha and three on the Catweasel. - Say Y if you have a Buddha or Catweasel expansion board and want to - use IDE devices (hard disks, CD-ROM drives, etc.) that are connected - to one of its IDE interfaces. - Amiga IDE Doubler support (EXPERIMENTAL) CONFIG_BLK_DEV_IDEDOUBLER This driver provides support for the so called `IDE doublers' (made by @@ -872,17 +889,20 @@ CONFIG_BLK_DEV_IDEDOUBLER Say Y if you have an IDE doubler. The driver is enabled at kernel runtime using the "ide=doubler" kernel boot parameter. -Support for PowerMac IDE devices (must also enable IDE) -CONFIG_BLK_DEV_IDE_PMAC - No help for CONFIG_BLK_DEV_IDE_PMAC - -PowerMac IDE DMA support -CONFIG_BLK_DEV_IDEDMA_PMAC - No help for CONFIG_BLK_DEV_IDEDMA_PMAC +Amiga Buddha/Catweasel IDE interface support (EXPERIMENTAL) +CONFIG_BLK_DEV_BUDDHA + This is the IDE driver for the IDE interfaces on the Buddha and + Catweasel expansion boards. It supports up to two interfaces on the + Buddha and three on the Catweasel. + Say Y if you have a Buddha or Catweasel expansion board and want to + use IDE devices (hard disks, CD-ROM drives, etc.) that are connected + to one of its IDE interfaces. -Use DMA by default -CONFIG_IDEDMA_PMAC_AUTO - No help for CONFIG_IDEDMA_PMAC_AUTO +Falcon IDE interface support +CONFIG_BLK_DEV_FALCON_IDE + This is the IDE driver for the builtin IDE interface on the Atari Falcon. + Say Y if you have a Falcon and want to use IDE devices (hard disks, + CD-ROM drives, etc.) that are connected to the builtin IDE interface. Macintosh Quadra/Powerbook IDE interface support CONFIG_BLK_DEV_MAC_IDE @@ -894,21 +914,15 @@ CONFIG_BLK_DEV_MAC_IDE (hard disks, CD-ROM drives, etc.) that are connected to the builtin IDE interface. -ICS IDE interface support -CONFIG_BLK_DEV_IDE_ICSIDE - No help for CONFIG_BLK_DEV_IDE_ICSIDE - -ICS DMA support -CONFIG_BLK_DEV_IDEDMA_ICS - No help for CONFIG_BLK_DEV_IDEDMA_ICS - -Use ICS DMA by default -CONFIG_IDEDMA_ICS_AUTO - No help for CONFIG_IDEDMA_ICS_AUTO - -RapIDE interface support -CONFIG_BLK_DEV_IDE_RAPIDE - No help for CONFIG_BLK_DEV_IDE_RAPIDE +PS/2 ESDI hard disk support +CONFIG_BLK_DEV_PS2 + Say Y here if you have a PS/2 machine with a MCA bus and an ESDI + hard disk. + + If you want to compile the driver as a module ( = code which can be + inserted in and removed from the running kernel whenever you want), + say M here and read Documentation/modules.txt. The module will be + called ps2esdi.o. XT hard disk support CONFIG_BLK_DEV_XD @@ -922,6 +936,17 @@ CONFIG_BLK_DEV_XD It's pretty unlikely that you have one of these: say N. +Mylex DAC960/DAC1100 PCI RAID Controller support +CONFIG_BLK_DEV_DAC960 + This driver adds support for the Mylex DAC960, AcceleRAID, and + eXtremeRAID PCI RAID controllers. See README.DAC960 for further + information about this driver. + + If you want to compile the driver as a module ( = code which can be + inserted in and removed from the running kernel whenever you want), + say M here and read Documentation/modules.txt. The module will be + called DAC960.o. + Parallel port IDE device support CONFIG_PARIDE There are many external CD-ROM and disk devices that connect through @@ -1407,43 +1432,28 @@ CONFIG_FILTER file linux/Documentation/networking/filter.txt for more information. If unsure, say N. -Network firewalls -CONFIG_FIREWALL - A firewall is a computer which protects a local network from the - rest of the world: all traffic to and from computers on the local - net is inspected by the firewall first, and sometimes blocked or - modified. The type of firewall you'll get if you say Y here is - called a "packet filter": it can block network traffic based on - type, origin and destination. By contrast, "proxy-based" firewalls - are more secure but more intrusive and more bothersome to set up; - they inspect the network traffic much more closely, modify it and - have knowledge about the higher level protocols, which packet - filters lack. They also often require changes in the programs - running on the local clients. Proxy-based firewalls don't need - support by the kernel, but they are often combined with packet - filters, which only works if you say Y here. - - If you want to configure your Linux box as a packet filter firewall - for a local network, say Y here. If your local network is TCP/IP - based, you will then also have to say Y to "IP: firewalling", below. - - You also need to say Y here and to "IP firewalling" below in order - to be able to use IP masquerading (i.e. local computers can chat - with an outside host, but that outside host is made to think that it - is talking to the firewall box -- makes the local network completely - invisible to the outside world and avoids the need to allocate - globally valid IP host addresses for the machines on the local net) - and IP transparent proxying (makes the computers on the local - network think they're talking to a remote computer, while in reality - the traffic is redirected by your Linux firewall to a local proxy - server). +Network packet filtering +CONFIG_NETFILTER + Netfilter is a framework for filtering and mangling packets. + Various modules exist for netfilter which replace the previous + masquerading (ipmasqadm), packet filtering (ipchains), transparent + proxying, and portforwarding mechanisms. Enabling this option + makes minor alterations to allow these modules to hook into the + packet stream. More information is available from + http://netfilter.kernelnotes.org (to browse the WWW, you need + to have access to a machine on the Internet that has a program like + lynx or netscape). Make sure to say N to "Fast switching" below if you intend to say Y - here. + here, as Fast switching currently bypasses netfilter. Chances are that you should say Y here for every machine which is run as a router and N for every regular host. If unsure, say N. +Network packet filtering debugging +CONFIG_NETFILTER_DEBUG + Say Y to make sure packets aren't leaking. + SYN flood protection CONFIG_SYN_COOKIES Normal TCP/IP networking is open to an attack known as "SYN @@ -1693,32 +1703,6 @@ CONFIG_PCI_GOBIOS kernel will try the direct access method and falls back to the BIOS if that doesn't work. If unsure, go with the default. -PCI quirks -CONFIG_PCI_QUIRKS - If you have a broken BIOS, it may fail to set up the PCI bus in a - correct or optimal fashion. Saying Y here will correct that problem. - If your BIOS is fine you can say N here for a very slightly smaller - kernel. If unsure, say Y. - -PCI bridge optimization (experimental) -CONFIG_PCI_OPTIMIZE - This can improve access times for some hardware devices if you have - a really broken BIOS and your computer uses a PCI bus system. Say Y - if you think it might help, but try turning it off if you experience - any problems with the PCI bus. N is the safe answer. - -Backward-compatible /proc/pci -CONFIG_PCI_OLD_PROC - Older kernels supported a /proc/pci file containing brief textual - descriptions of all PCI devices in the system. Several programs - tried to parse this file, so it became almost impossible to add new - fields without breaking compatibility. So a new /proc interface to - PCI (/proc/bus/pci) has been implemented and the old one is - supported for compatibility reasons only; you'll get the old one (in - addition to the new one) if you say Y here and to "/proc filesystem - support", below. If unsure, say Y. If you say N, you'll only get the - new /proc/bus/pci interface. - MCA support CONFIG_MCA MicroChannel Architecture is found in some IBM PS/2 machines and @@ -2065,10 +2049,12 @@ CONFIG_FB_RETINAZ3 you have a Retina Z3 or plan to get one before you next recompile the kernel. -Amiga CLgen driver (EXPERIMENTAL) +Cirrus Logic generic driver (EXPERIMENTAL) CONFIG_FB_CLGEN This enables support for Cirrus Logic GD542x/543x based boards on Amiga: SD64, Piccolo, Picasso II/II+, Picasso IV, or EGS Spectrum. + If you have a PCI-based system, this enables support for these chips: + GD-543x, GD-544x, GD-5480. Say N unless you have such a graphics board or plan to get one before you next recompile the kernel. @@ -2367,7 +2353,7 @@ CONFIG_FBCON_MAC VGA characters/attributes support CONFIG_FBCON_VGA This is the low level frame buffer console driver for VGA text mode; - it is used if you said Y to "VGA chipset support (text only)" above. + it is used by frame buffer device drivers that support VGA text mode. Parallel-port support CONFIG_PARPORT @@ -2663,64 +2649,6 @@ CONFIG_IP_ROUTER If unsure, say N here. -IP: firewalling -CONFIG_IP_FIREWALL - If you want to configure your Linux box as a packet filter firewall - for a local TCP/IP based network, say Y here. You may want to read - the FIREWALL-HOWTO, available via FTP (user: anonymous) in - ftp://metalab.unc.edu/pub/Linux/docs/HOWTO. - - Also, you will need the ipchains tool (available on the WWW at - http://www.rustcorp.com/linux/ipchains/) to allow selective blocking - of Internet traffic based on type, origin and destination. - Note that the Linux firewall code has changed and the old program - called ipfwadm won't work anymore. Please read the IPCHAINS-HOWTO. - - The type of firewall provided by ipchains and this kernel support is - called a "packet filter". The other type of firewall, a - "proxy-based" one, is more secure but more intrusive and more - bothersome to set up; it inspects the network traffic much more - closely, modifies it and has knowledge about the higher level - protocols, which a packet filter lacks. Moreover, proxy-based - firewalls often require changes to the programs running on the local - clients. Proxy-based firewalls don't need support by the kernel, but - they are often combined with a packet filter, which only works if - you say Y here. - - The firewalling code will only work if IP forwarding is enabled in - your kernel. You can do that by saying Y to "/proc filesystem - support" and "Sysctl support" below and executing the line - - echo "1" > /proc/sys/net/ipv4/ip_forward - - at boot time after the /proc filesystem has been mounted. - - You need to say Y to "IP firewalling" in order to be able to use IP - masquerading (masquerading means that local computers can chat with - an outside host, but that outside host is made to think that it is - talking to the firewall box -- makes the local network completely - invisible to the outside world and avoids the need to allocate - globally valid IP host addresses for the machines on the local net) - and IP packet logging and accounting (keeping track of what is using - all your network bandwidth) and IP transparent proxying (makes the - computers on the local network think they're talking to a remote - computer, while in reality the traffic is redirected by your Linux - firewall to a local proxy server). - - If in doubt, say N here. - -IP: firewall packet netlink device -CONFIG_IP_FIREWALL_NETLINK - If you say Y here, you can use the ipchains tool to copy all or part - of any packet you specify that hits your Linux firewall to optional - user space monitoring software that can then look for attacks and - take actions such as paging the administrator of the site. - - To use this, you need to create a character special file under /dev - with major number 36 and minor number 3 using mknod ("man mknod"), - and you need (to write) a program that reads from that device and - takes appropriate action. - IP: kernel level autoconfiguration CONFIG_IP_PNP This enables automatic configuration of IP addresses of devices and @@ -2790,175 +2718,6 @@ CONFIG_NET_IPGRE_BROADCAST Network), but can be distributed all over the Internet. If you want to do that, say Y here and to "IP: multicast routing" below. -IP: transparent proxying -CONFIG_IP_TRANSPARENT_PROXY - This enables your Linux firewall to transparently redirect any - network traffic originating from the local network and destined - for a remote host to a local server, called a "transparent proxy - server". This makes the local computers think they are talking to - the remote end, while in fact they are connected to the local - proxy. Redirection is activated by defining special input firewall - rules (using the ipchains utility) and/or by doing an appropriate - bind() system call. - -IP: masquerading -CONFIG_IP_MASQUERADE - If one of the computers on your local network for which your Linux - box acts as a firewall wants to send something to the outside, your - box can "masquerade" as that computer, i.e. it forwards the traffic - to the intended outside destination, but makes it look like it came - from the firewall box itself. It works both ways: if the outside - host replies, the Linux firewall will silently forward the traffic - to the corresponding local computer. This way, the computers on your - local net are completely invisible to the outside world, even though - they can reach the outside and can receive replies. This makes it - possible to have the computers on the local network participate on - the Internet even if they don't have officially registered IP - addresses. (This last problem can also be solved by connecting the - Linux box to the Internet using SLiRP [SLiRP is a SLIP/PPP emulator - that works if you have a regular dial up shell account on some UNIX - computer; get it via FTP (user: anonymous) from - ftp://metalab.unc.edu/pub/Linux/system/network/serial/ ].) - - The IP masquerading code will only work if IP forwarding is enabled - in your kernel; you can do this by saying Y to "/proc - filesystem support" and "Sysctl support" below and then executing a - line like - - echo "1" > /proc/sys/net/ipv4/ip_forward - - from a boot time script after the /proc filesystem has been mounted. - - Details on how to set things up are contained in the IP Masquerade - mini-HOWTO, available via FTP (user: anonymous) from - ftp://metalab.unc.edu/pub/Linux/docs/HOWTO/mini; there's also some - information on the WWW at - http://www.tor.shaw.wave.ca/~ambrose/kernel21.html. - - If you say Y here, then the modules ip_masq_ftp.o (for ftp file - transfers), ip_masq_irc.o (for irc chats), ip_masq_quake.o (you - guessed it), ip_masq_vdolive.o (for VDOLive video connections), - ip_masq_cuseeme.o (for CU-SeeMe broadcasts) and ip_masq_raudio.o - (for RealAudio downloads) will automatically be compiled. They are - needed to make masquerading for these protocols work. Modules are - pieces of code which can be inserted in and removed from the running - kernel whenever you want; read Documentation/modules.txt for - details. - -IP: ICMP masquerading -CONFIG_IP_MASQUERADE_ICMP - The basic masquerade code described for "IP: masquerading" above - only handles TCP or UDP packets (and ICMP errors for existing - connections). This option adds additional support for masquerading - ICMP packets, such as ping or the probes used by the Windows 95 - tracert program. - - If you want this, say Y. - -IP: masquerading special modules support -CONFIG_IP_MASQUERADE_MOD - This provides support for special modules that can modify the - rewriting rules used when masquerading. Please note that this - feature adds a little overhead in the input packet processing chain. - - Examples of such modules are ipautofw (allowing the masquerading of - protocols which don't have their own protocol helpers) and port - forwarding (making an incoming port of a local computer visible - through the masquerading host). - - You will need the user space program "ipmasqadm" to use these - additional modules; you can download it from - http://juanjox.linuxhq.com/ - - All this additional code is still under development and so is - currently marked EXPERIMENTAL. - - If you want to try, for example, PORT FORWARDING, say Y. - -IP: ipautofw masquerade support (Experimental) -CONFIG_IP_MASQUERADE_IPAUTOFW - ipautofw is a program which allows the masquerading of protocols - which do not (as yet) have their own protocol helpers. Information - and source for ipautofw is available via FTP (user: anonymous) from - ftp://ftp.netis.com/pub/members/rlynch/ - - You will also need the ipmasqadm tool available from - http://juanjox.linuxhq.com/ . - - The ipautofw code is still under development and so is currently - marked EXPERIMENTAL. If you want to try it, say Y. - - This code is also available as a module ( = code which can be - inserted in and removed from the running kernel whenever you want). - The module will be called ip_masq_autofw.o. If you want to compile - it as a module, say M here and read Documentation/modules.txt. - -IP: ipportfw masquerade support -CONFIG_IP_MASQUERADE_IPPORTFW - Port Forwarding is an addition to IP Masquerading which allows some - forwarding of packets from outside to inside a firewall on given - ports. This could be useful if, for example, you want to run a web - server behind the firewall or masquerading host and that web server - should be accessible from the outside world. An external client - sends a request to port 80 of the firewall, the firewall forwards - this request to the web server, the web server handles the request - and the results are sent through the firewall to the original - client. The client thinks that the firewall machine itself is - running the web server. This can also be used for load balancing if - you have a farm of identical web servers behind the firewall. - - Information about this feature is available from - http://www.monmouth.demon.co.uk/ipsubs/portforwarding.html (to - browse the WWW, you need to have access to a machine on the Internet - that has a program like lynx or netscape). For general info, please - see ftp://ftp.compsoc.net/users/steve/ipportfw/linux21/ - - You will need the user space program "ipmasqadm" which can be - downloaded from http://juanjox.linuxhq.com/ - - The portfw code is still under development and so is currently - marked EXPERIMENTAL. If you want to try it, say Y. - - This code is also available as a module ( = code which can be - inserted in and removed from the running kernel whenever you want). - The module will be called ip_masq_portfw.o. If you want to compile - it as a module, say M here and read Documentation/modules.txt. - -IP: ipmarkfw masquerade support -CONFIG_IP_MASQUERADE_MFW - Firewall Mark Forwarding provides functionality similar to port - forwarding (see "IP: ipportfw masquerade support", above), the - difference being that Firewall Mark Forwarding uses "firewalling - mark" to select which packets must be forwarded (see ipchains(8), - "-m" argument). - - This code is still under development and so is currently marked - EXPERIMENTAL. If you want to try it, say Y. - - This code is also available as a module ( = code which can be - inserted in and removed from the running kernel whenever you want). - The module will be called ip_masq_markfw.o. If you want to compile - it as a module, say M here and read Documentation/modules.txt. - -IP: always defragment (required for masquerading) -CONFIG_IP_ALWAYS_DEFRAG - If you say Y here, then all incoming fragments (parts of IP packets - that arose when some host between origin and destination decided - that the packets were too large and cut them into pieces) will be - reassembled (defragmented) before being processed, even if they are - about to be forwarded. - - You must say Y here if you want to enable "IP: masquerading" or "IP: - transparent proxying". - - When using "IP: firewalling" support, you might also want to say Y - here, to have a more reliable firewall (otherwise second and further - fragments must be dealt with by the firewall, which can be tricky). - - Only say Y here if running either a firewall that is the sole link - to your network or a transparent proxy; never ever say Y here for a - normal router or host. - IP: aliasing support CONFIG_IP_ALIAS Sometimes it is useful to give several IP addresses to a single @@ -3135,8 +2894,8 @@ CONFIG_IPV6 IPv6, see http://playground.sun.com/pub/ipng/html/ipng-main.html (to browse the WWW, you need to have access to a machine on the Internet that has a program like lynx or netscape); for specific information - about IPv6 under Linux read the HOWTO at http://www.terra.net/ipv6/ - and the file net/ipv6/README in the kernel source. + about IPv6 under Linux read http://www.bieringer.de/linux/IPv6/ and + the file net/ipv6/README in the kernel source. If you want to use IPv6, please upgrade to the newest net-tools as given in Documentation/Changes. You will still be able to do regular @@ -3594,6 +3353,13 @@ CONFIG_SCC_DELAY ### Don't know what's going on here. ### # +YAM driver for AX.25 +CONFIG_YAM + Support for the YAM modem on serial port. If you want to compile this + as a module ( = code which can be inserted in and removed from the + running kernel whenever you want), say M here and read + Documentation/modules.txt. + BAYCOM picpar and par96 driver for AX.25 CONFIG_BAYCOM_PAR This is a driver for Baycom style simple amateur radio modems that @@ -3854,14 +3620,12 @@ CONFIG_NETLINK able to read from and write to character special files in the /dev directory having major mode 36. So far, the kernel uses it to publish some network related information if you say Y to "Routing - messages", below. It is also used by the firewall code to publish - information about possible attacks if you say Y to "IP: firewall - packet netlink device" further down. You also need to say Y here if - you want to use arpd, a daemon that helps keep the internal ARP - cache (a mapping between IP addresses and hardware addresses on the - local network) small. The ethertap device, which lets user space - programs read and write raw Ethernet frames, also needs the network - link driver. If unsure, say Y. + messages", below. You also need to say Y here if you want to use + arpd, a daemon that helps keep the internal ARP cache (a mapping + between IP addresses and hardware addresses on the local network) + small. The ethertap device, which lets user space programs read and + write raw Ethernet frames, also needs the network link driver. If + unsure, say Y. Routing messages CONFIG_RTNETLINK @@ -3876,6 +3640,192 @@ CONFIG_NETLINK_DEV This is a backward compatibility option, choose Y for now. This option will be removed soon. +Asynchronous Transfer Mode (ATM) +CONFIG_ATM + Kernel support for ATM. Note that you need a set of user-space programs + to actually make use of ATM. See Documentation/atm.txt for further + details. + +Classical IP over ATM +CONFIG_ATM_CLIP + Classical IP over ATM for PVCs and SVCs, supporting InARP and ATMARP. + Typically you will either use LAN Emulation (LANE) or Classical IP to + communicate with other IP hosts on your ATM network. + +Do NOT send ICMP if no neighbour +CONFIG_ATM_CLIP_NO_ICMP + Normally, an ICMP host unreachable message is sent if a neighbour cannot + be reached because there is no VC to it in the kernel's ATMARP table. + This may cause problems when ATMARP table entries are briefly removed + during revalidation. If this configuration option is set to "yes", + packets to such neighbours are silently discarded instead. + +LAN Emulation (LANE) support +CONFIG_ATM_LANE + LAN Emulation emulates services of existing LANs across an ATM network. + Besides operating as a normal ATM end station client, Linux LANE client + can also act as an proxy client bridging packets between ELAN and + Ethernet segments. You need LANE if you want to try MPOA. + +Multi-Protocol Over ATM (MPOA) support +CONFIG_ATM_MPOA + Multi-Protocol Over ATM allows ATM edge devices such as routers, + bridges and ATM attached hosts establish direct ATM VCs across + subnetwork boundaries. These shortcut connections bypass routers + enhancing overall network performance. + +ATM over TCP +CONFIG_ATM_TCP + ATM over TCP driver. Useful mainly for development and for experiments. + +Efficient Networks ENI155P +CONFIG_ATM_ENI + Driver for the Efficient Networks ENI155p series and SMC ATM Power155 + 155 Mbps ATM adapters. Both, the versions with 512kB and 2MB on-board + RAM (Efficient calls them "C" and "S", respectively), and the FPGA and + the ASIC Tonga versions of the board are supported. The driver works + with MMF (-MF or ...F) and UTP-5 (-U5 or ...D) adapters. + +Enable extended debugging +CONFIG_ATM_ENI_DEBUG + Extended debugging records various events and displays that list when + an inconsistency is detected. This mechanism is faster than generally + using printks, but still has some impact on performance. Note that + extended debugging may create certain race conditions itself. Enable + this ONLY if you suspect problems with the driver. + +Fine-tune burst settings +CONFIG_ATM_ENI_TUNE_BURST + In order to obtain good throughput, the ENI NIC can transfer multiple + words of data per PCI bus access cycle. Such a multi-word transfer is + called a burst. + + The default settings for the burst sizes are suitable for most PCI + chipsets. However, in some cases, large bursts may overrun buffers in + the PCI chipset and cause data corruption. In such cases, large bursts + must be disabled and only (slower) small bursts can be used. The burst + sizes can be set independently in the send (TX) and receive (RX) + direction. + + Note that enabling many different burst sizes in the same direction + may increase the cost of setting up a transfer such that the resulting + throughput is lower than when using only the largest available burst + size. + + Also, sometimes larger bursts lead to lower throughput, e.g. on an + Intel 440FX board, a drop from 135 Mbps to 103 Mbps was observed when + going from 8W to 16W bursts. + +Enable 16W TX bursts (discouraged) +CONFIG_ATM_ENI_BURST_TX_16W + Burst sixteed words at once in the send direction. This may work with + recent PCI chipsets, but is known to fail with older chipsets. + +Enable 8W TX bursts (recommended) +CONFIG_ATM_ENI_BURST_TX_8W + Burst eight words at once in the send direction. This is the default + setting. + +Enable 4W TX bursts (optional) +CONFIG_ATM_ENI_BURST_TX_4W + Burst four words at once in the send direction. You may want to try this + if you have disabled 8W bursts. Enabling 4W if 8W is also set may or may + not improve throughput. + +Enable 2W TX bursts (optional) +CONFIG_ATM_ENI_BURST_TX_2W + Burst two words at once in the send direction. You may want to try this + if you have disabled 4W and 8W bursts. Enabling 2W if 4W or 8W are also + set may or may not improve throughput. + +Enable 16W RX bursts (discouraged) +CONFIG_ATM_ENI_BURST_RX_16W + Burst sixteen words at once in the receive direction. This may work with + recent PCI chipsets, but is known to fail with older chipsets. + +Enable 8W RX bursts (discouraged) +CONFIG_ATM_ENI_BURST_RX_8W + Burst eight words at once in the receive direction. This may work with + recent PCI chipsets, but is known to fail with older chipsets, such as + the Intel Neptune series. + +Enable 4W RX bursts (recommended) +CONFIG_ATM_ENI_BURST_RX_4W + Burst four words at once in the receive direction. This is the default + setting. Enabling 4W if 8W is also set may or may not improve throughput. + +Enable 2W RX bursts (optional) +CONFIG_ATM_ENI_BURST_RX_2W + Burst two words at once in the receive direction. You may want to try + this if you have disabled 4W and 8W bursts. Enabling 2W if 4W or 8W are + also set may or may not improve throughput. + +ZeitNet ZN1221/ZN1225 +CONFIG_ATM_ZATM + Driver for the ZeitNet ZN1221 (MMF) and ZN1225 (UTP-5) 155 Mbps ATM + adapters. + +Enable extended debugging +CONFIG_ATM_ZATM_DEBUG + Extended debugging records various events and displays that list when + an inconsistency is detected. This mechanism is faster than generally + using printks, but still has some impact on performance. Note that + extended debugging may create certain race conditions itself. Enable + this ONLY if you suspect problems with the driver. + +Enable usec resolution timestamps +CONFIG_ATM_ZATM_EXACT_TS + The uPD98401 SAR chip supports a high-resolution timer (approx. 30 MHz) + that is used for very accurate reception timestamps. Because that timer + overflows after 140 seconds, and also to avoid timer drift, time + measurements need to be periodically synchronized with the normal + system time. Enabling this feature will add some general overhead for + timer synchronization and also per-packet overhead for time conversion. + +IDT 77201 (NICStAR) +CONFIG_ATM_NICSTAR + The NICStAR chipset family is used in a large number of ATM NICs for + 25 and for 155 Mbps, including IDT cards and the Fore ForeRunnerLE + series. + +Madge Ambassador (Collage PCI 155 Server) +CONFIG_ATM_AMBASSADOR + This is a driver for ATMizer based ATM card produced by Madge + Networks Ltd. Say Y (or M to compile as a module named ambassador.o) + here if you have one of these cards. + +Enable debugging messages +CONFIG_ATM_AMBASSADOR_DEBUG + Somewhat useful debugging messages are available. The choice of + messages is controlled by a bitmap. This may be specified as a + module argument (kernel command line argument as well?), changed + dynamically using an ioctl (not yet) or changed by sending the + string "Dxxxx" to VCI 1023 (where x is a hex digit). See the file + drivers/atm/ambassador.h for the meanings of the bits in the mask. + + When active, these messages can have a significant impact on the + speed of the driver, and the size of your syslog files! When + inactive, they will have only a modest impact on performance. + +Madge Horizon [Ultra] (Collage PCI 25 and Collage PCI 155 Client) +CONFIG_ATM_HORIZON + This is a driver for the Horizon chipset ATM adapter cards once + produced by Madge Networks Ltd. Say Y (or M to compile as a module + named horizon.o) here if you have one of these cards. + +Enable debugging messages +CONFIG_ATM_HORIZON_DEBUG + Somewhat useful debugging messages are available. The choice of + messages is controlled by a bitmap. This may be specified as a + module argument (kernel command line argument as well?), changed + dynamically using an ioctl (not yet) or changed by sending the + string "Dxxxx" to VCI 1023 (where x is a hex digit). See the file + drivers/atm/horizon.h for the meanings of the bits in the mask. + + When active, these messages can have a significant impact on the + speed of the driver, and the size of your syslog files! When + inactive, they will have only a modest impact on performance. + SCSI support? CONFIG_SCSI If you want to use a SCSI hard disk, SCSI tape drive, SCSI CDROM or @@ -4172,6 +4122,15 @@ CONFIG_AIC7XXX_RESET_DELAY kernel. The default value has been reduced to 5 seconds. If this doesn't work with your hardware, try increasing this value. +IBM ServeRAID Support +CONFIG_SCSI_IPS + This is support for the IBM ServeRAID hardware RAID controllers. + Consult the SCSI-HOWTO, available via anonymous FTP from + ftp://metalab.unc.edu/pub/Linux/docs/HOWTO, and the file + README.ips in drivers/scsi for more information. If this driver + does not work correctly without modification please contact the + author by email at ipslinux@us.ibm.com. + BusLogic SCSI support CONFIG_SCSI_BUSLOGIC This is support for BusLogic MultiMaster and FlashPoint SCSI Host @@ -4935,8 +4894,8 @@ CONFIG_SCSI_AM53C974 AMI MegaRAID support CONFIG_SCSI_MEGARAID - This driver supports the AMI MegaRAID 428 and 438 (and maybe 466) - SCSI host adapters. + This driver supports the AMI MegaRAID 418, 428, 438, 466, 762, 490 + and 467 SCSI host adapters. If you want to compile this driver as a module ( = code which can be inserted in and removed from the running kernel whenever you want), @@ -5238,23 +5197,11 @@ CONFIG_SLIP_MODE_SLIP6 end of the link as well. It's good enough, for example, to run IP over the async ports of a Camtec JNT Pad. If unsure, say N. -PPP (point-to-point) support +PPP (point-to-point protocol) support CONFIG_PPP PPP (Point to Point Protocol) is a newer and better SLIP. It serves the same purpose: sending Internet traffic over telephone (and other - serial) lines. Ask your access provider if they support it, because - otherwise you can't use it (not quite true any more: the free - program SLiRP can emulate a PPP line if you just have a regular dial - up shell account on some UNIX computer; get it via FTP (user: - anonymous) from - ftp://metalab.unc.edu/pub/Linux/system/network/serial/). Note that - you don't need "PPP support" if you just want to run term (term is a - program which gives you almost full Internet connectivity if you - have a regular dial up shell account on some Internet connected UNIX - computer. Read - http://www.bart.nl/~patrickr/term-howto/Term-HOWTO.html (to browse - the WWW, you need to have access to a machine on the Internet that - has a program like lynx or netscape)). + serial) lines. Most ISPs these days support PPP rather than SLIP. To use PPP, you need an additional program called pppd as described in Documentation/networking/ppp.txt and in the PPP-HOWTO, available @@ -5262,19 +5209,55 @@ CONFIG_PPP from an older kernel, you might need to upgrade pppd as well. The PPP option enlarges your kernel by about 16 KB. + Almost always, if you answer Y or M to this question, you should + give the same answer to the next question, about PPP support for + async serial ports. + This driver is also available as a module ( = code which can be inserted in and removed from the running kernel whenever you want). If you said Y to "Version information on all symbols" above, then you cannot compile the PPP driver into the kernel; you can then only - compile it as a module. The module will be called ppp.o. If you want - to compile it as a module, say M here and read + compile it as a module. The module will be called ppp_generic.o. If + you want to compile it as a module, say M here and read Documentation/modules.txt as well as - Documentation/networking/net-modules.txt. Note that, no matter what - you do, the BSD compression code (used to compress the IP packets - sent over the serial line; has to be supported at the other end as - well) will always be compiled as a module; it is called bsd_comp.o - and will show up in the directory modules once you have said "make - modules". If unsure, say N. + Documentation/networking/net-modules.txt. + +PPP support for async serial ports +CONFIG_PPP_ASYNC + Say Y (or M) here if you want to be able to use PPP over standard + asynchronous serial ports, such as COM1 or COM2 on a PC. If you use + a modem (not a synchronous or ISDN modem) to contact your ISP, you + need this option. + + This code is also available as a module (code which can be inserted + into and removed from the running kernel). If you want to compile + it as a module, say M here and read Documentation/modules.txt. + +PPP Deflate compression +CONFIG_PPP_DEFLATE + Support for the Deflate compression method for PPP, which uses the + Deflate algorithm (the same algorithm that gzip uses) to compress + each PPP packet before it is sent over the wire. The peer (the + machine at the other end of the PPP link, usually your ISP) has to + support the Deflate compression method as well for this to be + useful. + + This code is also available as a module (code which can be inserted + into and removed from the running kernel). If you want to compile + it as a module, say M here and read Documentation/modules.txt. + +PPP BSD-Compress compression +CONFIG_PPP_BSDCOMP + Support for the BSD-Compress compression method for PPP, which uses + the LZW compression method to compress each PPP packet before it is + sent over the wire. The peer (the other end of the PPP link) has to + support the BSD-Compress compression method as well for this to be + useful. The PPP Deflate compression method is preferable to + BSD-Compress, because it compresses better and is patent-free. + + Note that the BSD compression code will always be compiled as a + module; it is called bsd_comp.o and will show up in the directory + modules once you have said "make modules". If unsure, say N. Wireless LAN (non-hamradio) CONFIG_NET_RADIO @@ -5377,26 +5360,6 @@ CONFIG_X25_ASY say M here and read Documentation/modules.txt. The module will be called x25_asy.o. If unsure, say N. -Shortwave radio modem driver -CONFIG_HFMODEM - This experimental driver is used by a package (to be released) - that implements the shortwave radio protocols RTTY, Sitor (Amtor), - Pactor 1 and GTOR using a standard PC sound card. If unsure, - say N. - -Shortwave radio modem driver support for Sound Blaster and compatible cards -CONFIG_HFMODEM_SBC - This option enables the hfmodem driver to use Sound Blaster and - compatible cards. It requires a 16bit capable card, i.e. - SB16 or better, or ESS1688 or newer. - -Shortwave radio modem driver support for WSS and Crystal cards -CONFIG_HFMODEM_WSS - This option enables the hfmodem driver to use WindowsSoundSystem - compatible cards. These cards feature a codec chip from either - Analog Devices (such as AD1848, AD1845) or Crystal Semiconductors - (such as CS4248, CS423x). - PLIP (parallel port) support CONFIG_PLIP PLIP (Parallel Line Internet Protocol) is used to create a @@ -5592,14 +5555,14 @@ CONFIG_NET_FASTROUTE Card) data transfers, which is fast. *** This option is NOT COMPATIBLE with several important *** - *** networking options: especially CONFIG*FIREWALL. *** + *** networking options: especially CONFIG_NETFILTER. *** *** Say N here if you intend to use Linux as a firewall. *** However, it will work with all options in CONFIG_IP_ADVANCED_ROUTER section (except for CONFIG_IP_ROUTE_TOS and CONFIG_IP_ROUTE_FWMARK). At the moment, few devices support fast switching (tulip is one of them, modified 8390 can be found at - ftp://ftp.inr.ac.ru/ip-routing/fastroute-8390.tar.gz). + ftp://ftp.inr.ac.ru/ip-routing/fastroute/fastroute-8390.tar.gz). If unsure, say N. @@ -5609,8 +5572,8 @@ CONFIG_NET_HW_FLOWCONTROL during periods of extremal congestion. At the moment only a couple of device drivers support it (really only one -- tulip, modified 8390 can be found at - ftp://ftp.inr.ac.ru/ip-routing/fastroute-8390.tar.gz). Really, this - option is applicable to any machine attached to a fast enough + ftp://ftp.inr.ac.ru/ip-routing/fastroute/fastroute-8390.tar.gz). + Really, this option is applicable to any machine attached to a fast enough network, and even a 10 Mb NIC is able to kill a not very slow box, such as a 120MHz Pentium. @@ -6139,19 +6102,50 @@ CONFIG_YELLOWFIN say M here and read Documentation/modules.txt. This is recommended. The module will be called yellowfin.o. +General Instruments Surfboard 1000 +CONFIG_NET_SB1000 + This is a driver for the General Instrument SURFboard 1000 internal cable + modem. This is an ISA card which is used by a number of cable TV companies + to provide cable modem access. It's a one-way downstream-only cable modem, + meaning that your upstream net link is provided by your regular phone modem. + + At present this driver only compiles as a module, so say M here if you + have this card. Then read Documentation/networking/README.sb1000 for + information on how to use this module, as it needs special ppp scripts for + establishing a connection. Further documentation and the necessary scripts + can be found at: + + http://www.jacksonville.net/~fventuri/ + http://home.adelphia.net/~siglercm/sb1000.html + http://linuxpower.cx/~cable/ + + If you don't have this card, of course say N. + Alteon AceNIC/3Com 3C985/NetGear GA620 Gigabit support CONFIG_ACENIC - Say Y here if you have an Alteon AceNIC or 3Com 3C985 PCI Gigabit - Ethernet adapter. The driver allows for using the Jumbo Frame - option (9000 bytes/frame) however it requires that your switches - can handle this as well. To enable Jumbo Frames, add `mtu 9000' to - your ifconfig line. + Say Y here if you have an Alteon AceNIC, 3Com 3C985(B), NetGear + GA620, SGI Gigabit or Farallon PN9000-SX PCI Gigabit Ethernet + adapter. The driver allows for using the Jumbo Frame option (9000 + bytes/frame) however it requires that your switches can handle this + as well. To enable Jumbo Frames, add `mtu 9000' to your ifconfig + line. If you want to compile this driver as a module ( = code which can be inserted in and removed from the running kernel whenever you want), say M here and read Documentation/modules.txt. This is recommended. The module will be called acenic.o. +Omit support for older Tigon I based AceNICs +CONFIG_ACENIC_OMIT_TIGON_I + Say Y here if you only have Tigon II based AceNICs and want to leave + out support for the older Tigon I based cards which are no longer + being sold (ie. the original Alteon AceNIC and 3Com 3C985 (non B + version)). This will reduce the size of the driver object by + app. 100KB. If you are not sure whether your card is a Tigon I or a + Tigon II, say N here. + + The safe and default value for this is N. + AMD LANCE and PCnet (AT1500 and NE2100) support CONFIG_LANCE If you have a network (Ethernet) card of this type, say Y and read @@ -7312,7 +7306,7 @@ CONFIG_MINIX_FS You don't want to use the minix filesystem on your hard disk because of certain built-in restrictions, but it is sometimes found on older Linux floppy disks. This option will enlarge your kernel by about - 25 kB. If unsure, say N. + 28 kB. If unsure, say N. If you want to compile this as a module ( = code which can be inserted in and removed from the running kernel whenever you want), @@ -7338,7 +7332,7 @@ CONFIG_EXT2_FS ext2fs is a diskless Linux box which mounts all files over the network using NFS (in this case it's sufficient to say Y to "NFS filesystem support" below). Saying Y here will enlarge your kernel - by about 41 kB. + by about 44 kB. The Ext2fs-Undeletion mini-HOWTO, available via FTP (user: anonymous) from ftp://metalab.unc.edu/pub/Linux/docs/HOWTO/mini, @@ -7395,6 +7389,25 @@ CONFIG_JOLIET like lynx or netscape). Say Y here if you want to be able to read Joliet CDROMs under Linux. +UDF Filesystem support +CONFIG_UDF_FS + This is the new filesystem used by some CDROMS and DVD drivers. + Say Y if you intend to mount DVD discs or CDRWs written in packet mode, + or if written to by other UDF utilities, such as DirectCD. + + This filesystem support is also available as a module ( = code which + can be inserted in and removed from the running kernel whenever you + want). The module is called udf.o. If you want to compile it as a + module, say M here and read Documentation/modules.txt. + + If unsure, say N. + +UDF read-write support (EXPERIMENTAL) +CONFIG_UDF_RW + Say Y if you want to test write support for UDF filesystems. + Due to lack of support for writing to CDR/CDRW's, this option + is only supported for Hard Discs, DVD-RAM, and loopback files. + fat fs support CONFIG_FAT_FS If you want to use one of the FAT-based filesystems (the MS-DOS, @@ -7526,7 +7539,7 @@ CONFIG_PROC_FS that has a program like lynx or netscape), and also on the proc(8) manpage ("man 8 proc"). - This option will enlarge your kernel by about 18 KB. Several + This option will enlarge your kernel by about 67 KB. Several programs depend on this, so everyone should say Y here. NFS filesystem support @@ -7819,6 +7832,18 @@ CONFIG_SGI_DISKLABEL Say Y to this only if you plan on mounting disks with SGI disklabels. This is not required to mount EFS-format CDROMs. +EFS filesystem support (experimental) +CONFIG_EFS_FS + EFS is the filesystem used for CDROMs and filesystems by SGI's IRIX. + This implementation only offers read-only access. If you don't know + what all this is about, it's safe to say N. For more information + about EFS see it's homepage at http://aeschi.ch.eu.org/efs. + +SGI disklabel support +CONFIG_SGI_DISKLABEL + Say Y to this only if you plan on mounting disks with SGI disklabels. + This is not required to mount EFS-format CDROMs. + BSD disklabel (FreeBSD partition tables) support CONFIG_BSD_DISKLABEL FreeBSD uses its own hard disk partition scheme on your PC. It @@ -8340,6 +8365,16 @@ CONFIG_NLS_ISO8859_10 letters that were missing in Latin 4 to cover the entire Nordic area. +nls iso8859-14 +CONFIG_NLS_ISO8859_14 + If you want to display filenames with native language characters + from the Microsoft fat filesystem family or from JOLIET CDROMs + correctly on the screen, you need to include the appropriate + input/output character sets. Say Y here for the Latin 8 character + set, which adds the last accented vowels for Welsh (and Manx Gaelic) + that were missing in Latin 1. http://linux.speech.cymru.org/ + has further information. + nls iso8859-15 CONFIG_NLS_ISO8859_15 If you want to display filenames with native language characters @@ -9203,6 +9238,35 @@ CONFIG_DTLK running kernel whenever you want), say M here and read Documentation/modules.txt. The module will be called dtlk.o. +Siemens R3964 serial protocol support +CONFIG_R3964 + This driver allows syncronous communication with devices using the + Siemens R3964 packet protocol. Unless you are dealing with special + hardware like PLCs, you are unlikely to need this. + + To compile this driver as a module ( = code which can be inserted in + and removed from the running kernel whenever you want), say M here + and read Documentation/modules.txt. The module will be called + n_r3964.o. + + If unsure, say N. + +Applicom intelligent fieldbus card support +CONFIG_APPLICOM + This driver provides the kernel-side support for the intelligent + fieldbus cards made by Applicom International. More information + about these cards can be found on the WWW at the address + http://www.applicom-int.com/ (to browse the WWW, you need to have + access to a machine on the Internet that has a program like lynx + or netscape), or by email from David Woodhouse <dwmw2@mvhi.com>. + + To compile this driver as a module ( = code which can be inserted in + and removed from the running kernel whenever you want), say M here + and read Documentation/modules.txt. The module will be called + applicom.o. + + If unsure, say N. + Advanced Power Management CONFIG_APM APM is a BIOS specification for saving power using several different @@ -9462,7 +9526,7 @@ CONFIG_RTC If you run Linux on a multiprocessor machine and said Y to "Symmetric Multi Processing" above, you should say Y here to read - and set the RTC clock in an SMP compatible fashion. + and set the RTC in an SMP compatible fashion. If you think you have a use for such a device (such as periodic data sampling), then say Y here, and read Documentation/rtc.txt for @@ -10158,6 +10222,12 @@ CONFIG_AEDSP16_MPU_IRQ you compiled aedsp16.o as a module you can specify this parameter as 'mpu_irq=NN'. +SGI Visual Workstation on-board audio +CONFIG_SOUND_VWSND + Say Y or M if you have an SGI Visual Workstation and you want to + be able to use its on-board audio. Read Documentation/sound/visws + for more info on this driver's capabilities. + Ensoniq ES1370 based PCI sound cards CONFIG_SOUND_ES1370 Say Y or M if you have a PCI sound card utilizing the Ensoniq @@ -10196,6 +10266,15 @@ CONFIG_SOUND_ES1371_GAMEPORT Leave the default 200 unless you have a joystick not attached to your sound card. +ESS Solo1 based PCI sound cards (eg. SC1938) +CONFIG_SOUND_ESSSOLO1 + Say Y or M if you have a PCI sound card utilizing the ESS Technology + Solo1 chip. To find out if your sound card uses a + Solo1 chip without removing your computer's cover, use + lspci -n and look for the PCI ID 125D:1969. This driver + differs slightly from OSS/Free, so PLEASE READ + Documentation/sound/solo1. + S3 SonicVibes based PCI sound cards CONFIG_SOUND_SONICVIBES Say Y or M if you have a PCI sound card utilizing the S3 @@ -10307,6 +10386,20 @@ CONFIG_ISDN_X25 connections. See Documentation/isdn/README.x25 for more information if you are thinking about using this. +ISDN diversion services support +CONFIG_ISDN_DIVERSION + This option allows you to use some supplementary diversion + services in conjunction with the HiSax driver on an EURO/DSS1 + line. Supported options are CD (call deflection), CFU (Call + forward unconditional), CFB (Call forward when busy) and CFNR + (call forward not reachable). + Additionally the actual CFU, CFB and CFNR state may be + interrogated. The use of CFU, CFB, CFNR and interrogation may + be limited to some countries. The keypad protocol is still not + implemented. + CD should work in all countries if this service has been sub- + scribed. + ICN 2B and 4B support CONFIG_ISDN_DRV_ICN This enables support for two kinds of ISDN-cards made by a German @@ -10533,6 +10626,30 @@ CONFIG_ISDN_DRV_SC you need to have access to a machine on the Internet that has a program like lynx or netscape). +Eicon.Diehl active card support +CONFIG_ISDN_DRV_EICON + Say Y here if you have an Eicon active ISDN card. In order to use + this card, additional firmware is necessary, which has to be loaded + into the card using the eiconctrl utility which is part of the latest + isdn4k-utils package. Please read the file + Documentation/isdn/README.eicon for more information. + +Eicon old-type card support +CONFIG_ISDN_DRV_EICON_ISA + Say Y here if you have an old-type Eicon active ISDN card. In order to + use this card, additional firmware is necessary, which has to be loaded + into the card using the eiconctrl utility which is part of the latest + isdn4k-utils package. Please read the file + Documentation/isdn/README.eicon for more information. + +Support AT-Fax Class 2 commands +CONFIG_ISDN_TTY_FAX + If you say Y here, the modem-emulator will support a subset of the + Fax Class 2 commands. Using a getty with fax-support + (mgetty+sendfax, hylafax), you will be able to use your Linux box + as an ISDN-fax-machine. This must be supported by the lowlevel driver + also. See Documentation/isdn/README.fax for more information. + AVM-B1 with CAPI2.0 support CONFIG_ISDN_DRV_AVMB1 This enables support for the AVM B1 ISDN networking cards. In @@ -10646,11 +10763,23 @@ CONFIG_HP300 If you plan to try to use the kernel on such a machine say Y here. Everybody else says N. +Sun 3 support +CONFIG_SUN3 + This option enables support for the Sun 3 series of workstations. + Be warned that this support is very experimental. You will also + want to say Y to 68020 support and N to the other processors below. + Currently, it is not possible to build a kernel with support for + the Sun 3 and and something else, so make sure you have said N to + all the other machines. This option does not support the sun3x series + of machines (the Sun 3/80 and 3/460). If you don't want to compile a + kernel for a Sun 3, say N. + 68020 support CONFIG_M68020 If you anticipate running this kernel on a computer with a MC68020 processor, say Y. Otherwise, say N. Note that the 68020 requires a - 68851 MMU (Memory Management Unit) to run Linux/m68k. + 68851 MMU (Memory Management Unit) to run Linux/m68k, except on the + Sun 3, which provides its own version. 68030 support CONFIG_M68030 @@ -10670,6 +10799,33 @@ CONFIG_M68060 If you anticipate running this kernel on a computer with a MC68060 processor, say Y. Otherwise, say N. +Math emulation support +CONFIG_M68KFPU_EMU + At some point in the future, this will cause floating-point math + instructions to be emulated by the kernel on machines that lack a + floating-point math coprocessor. Thrill-seekers and chronically + sleep-deprived psychotic hacker types can say Y now, everyone else + should probably wait a while. + +Math emulation only kernel +CONFIG_M68KFPU_EMU_ONLY + This option prevents any floating-point instructions from being + compiled into the kernel, thereby the kernel doesn't save any + floating point context anymore during task switches, so this + kernel will only be usable on machines without a floating-point + math coprocessor. This makes the kernel a bit faster as no tests + needs to be executed whether a floating-point instruction in the + kernel should be executed or not. + +Math emulation extra precision +CONFIG_M68KFPU_EMU_EXTRAPREC + The fpu uses normally a few bit more during calculations for + correct rounding, the emulator can (often) do the same but this + extra calculation can cost quite some time, so you can disable + it here. The emulator will then "only" calculate with a 64 bit + mantissa and round slightly incorrect, what is more then enough + for normal usage. + Advanced processor options CONFIG_ADVANCED_CPU This gives you access to some advanced options for the CPU. The @@ -11075,6 +11231,11 @@ CONFIG_HPLANCE If you want to use the builtin "LANCE" Ethernet controller on an HP300 machine, say Y here. +Sun 3 onboard LANCE support +CONFIG_SUN3LANCE + If you want to use the onboard AMD "LANCE" (le) Ethernet hardware + on a Sun 3, you will need to say Y here. + DIO bus support CONFIG_DIO Say Y here to enable support for the "DIO" expansion bus used in @@ -11182,6 +11343,17 @@ CONFIG_VIDEO_DEV whenever you want). If you want to compile it as a module, say M here and read Documentation/modules.txt. +Direct Rendering Manager (XFree86 DRI support) +CONFIG_DRM + Kernel-level support for the Direct Rendering Infrastructure (DRI) + introduced in XFree86 4.x. These modules provide support for + synchronization, security, and DMA transfers. Select the module that + provides support for your graphics card. + +3dlabs GMX 2000 Direct Rendering Driver (XFree86 DRI support) +CONFIG_DRM_GAMMA + Choose M here if you have a 3dlabs GMX 2000 graphics card. + AIMSlab RadioTrack (aka RadioReveal) support CONFIG_RADIO_RTRACK Choose Y here if you have one of these FM radio cards, and then fill @@ -11744,31 +11916,6 @@ CONFIG_IRCOMM will create two modules called ircomm and ircomm_tty. For more information go to http://www.pluto.dti.ne.jp/~thiguchi/irda/ -IrLPT Protocol -CONFIG_IRLPT - Say Y here if you want to build support for the IrLPT protocol. If - you want to compile it as a module, say M here and read - Documentation/modules.txt. IrLPT makes it possible to print - documents to IrDA capable printers. - -IrLPT Client Protocol -CONFIG_IRLPT_CLIENT - Say Y here if you want to build support for the IrLPT client - protocol. If you want to compile it as a module, say M here and read - Documentation/modules.txt. The IrLPT client protocol can be used to - print documents to IrDA compatible printers like the HP-5MP, or - IrLPT printer adapters like the ACTiSYS IR-100M. - -IrLPT Server Protocol -CONFIG_IRLPT_SERVER - Say Y here if you want to build support for the IrLPT server - protocol. If you want to compile it as a module, say M here and read - Documentation/modules.txt. The IrLPT server protocol makes it - possible to use a Linux machine as an infrared printer server for - other laptops. So if your Linux machine has a cable connection to a - printer, then other laptops can use the Linux machine to print out - documents using infrared communication. - IrTTY IrDA Device Driver CONFIG_IRTTY_SIR Say Y here if you want to build support for the IrTTY line @@ -11863,6 +12010,15 @@ CONFIG_GIRBIL_DONGLE by IrTTY. To activate support for Greenwich dongles you will have to insert "irattach -d girbil" in the /etc/irda/drivers script. +Adaptec Airport 1000 and 2000 dongle +CONFIG_AIRPORT_DONGLE + Say Y here if you want to build support for the Adaptec Airport 1000 + and 2000 dongles. If you want to compile it as a module, say M here + and read Documentation/modules.txt. The Airport dongle attaches to + the normal 9-pin serial port connector, and can currently only be + used by IrTTY. To activate support for Airport dongles you will have + to insert "irattach -d airport" in the /etc/irda/drivers script. + Parallax Litelink dongle CONFIG_LITELINK_DONGLE Say Y here if you want to build support for the Parallax Litelink @@ -11986,7 +12142,7 @@ USB hub support CONFIG_USB_HUB To expand beyond the USB ports on the computer, a device called a hub is used. This driver supports hubs, allowing them to be used. - Say 'Y' + Say 'Y'. USB mouse support CONFIG_USB_MOUSE @@ -11996,27 +12152,80 @@ CONFIG_USB_MOUSE USB keyboard support CONFIG_USB_KBD - This driver allows usb keyboards to work under the USB stack. + This driver allows USB keyboards to work under the USB stack. USB audio parsing support (Preliminary) CONFIG_USB_AUDIO This driver will eventually handle audio devices, such as USB speakers. -USB Abstract Control Model support (Preliminary) +USB Communications Device Class (ACM) support (Preliminary) CONFIG_USB_ACM - This driver allows for devices which support the Abstract Control Model, - including many USB-based modems, ISDN adapters, and network adapters. + This driver handles devices which support the Abstract Control Model, + a subtype of the USB Communications Device Class. This includes many + USB-based modems and ISDN adapters. Add special files with: + mknod /dev/ttyACM0 c 166 0 + mknod /dev/ttyACM1 c 166 1 + mknod /dev/ttyACM2 c 166 2 + mknod /dev/ttyACM3 c 166 3 + +USB Printer Device Class support (Preliminary) +CONFIG_USB_PRINTER + This is a generic driver for USB printers. + +USS720 parport driver +CONFIG_USB_USS720 + This driver is for USB parallel port adapters that use the + Lucent Technologies USS-720 chip. + + The chip has two modes: automatic mode and manual mode. + In automatic mode, it looks like a standard USB printer. Only + Printers may be connected to the USS-720 in this mode. + The generic USB printer driver (CONFIG_USB_PRINTER, above) + may be used in that mode. + + Manual mode is not limited to printers, any parallel port + device should work. This driver utilizes manual mode. + Note however that some operations are three orders of a magnitude + slower than on a PCI/ISA Parallel Port, so timing critical + applications might not work. + + Say Y or M if you own an USS-720 USB->Parport cable and + intend to connect anything other than a printer to it. + +USB /proc filesystem entry support (Preliminary) +CONFIG_USB_PROC + This reports USB drivers and devices in the /proc filesystem. + Entries are located in /proc/bus/usb. + Note that you must enable support for the proc filesystem + for this to work. Support for user-space parallel port device drivers CONFIG_PPDEV - Saying Y to this adds support for /dev/parport device nodes. - NB. You have to make them before you can use them: - mknod /dev/parport00 c 99 0 - mknod /dev/parport01 c 99 1 - mknod /dev/parport10 c 99 16 - mknod /dev/parport11 c 99 17 - etc.. + Saying Y to this adds support for /dev/parport device nodes. This + is needed for programs that want low-level access to the parallel + port, for instance deviceid (which displays Plug-and-Play device + IDs) and vlp (which makes a Linux computer act as though it's a + printer). + + This is the parallel port equivalent of SCSI generic support (sg). + It is safe to say N to this -- it is not needed for normal printing + or parallel port CD-ROM/disk support. + +Kernel httpd acceleration (experimental) +CONFIG_KHTTPD + The kernel httpd acceleration daemon (kHTTPd) is a (limited) + webserver build into the kernel. It is limited since it can only + serve files from the filesystem. Saying "M" here builds the + kHTTPd module; this is NOT enough to have a working kHTTPd. + For safety reasons, the module has to be activated by doing a + "echo 1 > /proc/sys/net/khttpd/start" after inserting the module. + + Before using this, read the README in /usr/src/linux/net/khttpd ! + + The kHTTPd is experimental. Be careful when using it on a production + machine. Also note that kHTTPd doesn't support virtual servers yet. + # # A couple of things I keep forgetting: @@ -12158,7 +12367,7 @@ CONFIG_PPDEV # LocalWords: KERNNAME kname ktype kernelname Kerneltype KERNTYPE Alt RX mdafb # LocalWords: dataless kerneltype SYSNAME Comtrol Rocketport palmtop fbset EGS # LocalWords: nvram SYSRQ SysRq PrintScreen sysrq NVRAMs NvRAM Shortwave RTTY -# LocalWords: HFMODEM shortwave Sitor Amtor Pactor GTOR hfmodem hayes TX TMOUT +# LocalWords: hayes TX TMOUT # LocalWords: IDEPCI IDEDMA idedma PDC pdc TRM trm raidtools luthien nuclecu # LocalWords: unam mx miguel koobera uic EMUL solaris pp ieee lpsg co DMAs TOS # LocalWords: BLDCONFIG preloading jumperless BOOTINIT modutils multipath GRE diff --git a/Documentation/IO-APIC.txt b/Documentation/IO-APIC.txt index 76b939e8a..1a7dbd410 100644 --- a/Documentation/IO-APIC.txt +++ b/Documentation/IO-APIC.txt @@ -1,51 +1,41 @@ -Most (all) Intel SMP boards have the so-called 'IO-APIC', which is -an enhanced interrupt controller, able to route hardware interrupts -to multiple CPUs, or to CPU groups. +Most (all) Intel-MP compliant SMP boards have the so-called 'IO-APIC', +which is an enhanced interrupt controller, it enables us to route +hardware interrupts to multiple CPUs, or to CPU groups. -Linux supports the IO-APIC, but unfortunately there are broken boards -out there which make it unsafe to enable the IO-APIC unconditionally. -The Linux policy thus is to enable the IO-APIC only if it's 100% safe, ie.: +Linux supports all variants of compliant SMP boards, including ones with +multiple IO-APICs. (multiple IO-APICs are used in high-end servers to +distribute IRQ load further). - - the board is on the 'whitelist' +There are (a few) known breakages in certain older boards, which bugs are +usually worked around by the kernel. If your MP-compliant SMP board does +not boot Linux, then consult the linux-smp mailing list archives first. - or - the board does not have PCI pins connected to the IO-APIC - - or - the user has overridden blacklisted settings with the - pirq= boot option line. - -Kernel messages tell you whether the board is 'safe'. If your box -boots with enabled IO-APIC IRQs, then you have nothing else to do. Your +If your box boots fine with enabled IO-APIC IRQs, then your /proc/interrupts will look like this one: ----------------------------> - hell:~> cat /proc/interrupts - CPU0 CPU1 - 0: 90782 0 XT PIC timer - 1: 4135 2375 IO-APIC keyboard - 2: 0 0 XT PIC cascade - 3: 851 807 IO-APIC serial - 9: 6 22 IO-APIC ncr53c8xx - 11: 307 154 IO-APIC NE2000 - 13: 4 0 XT PIC fpu - 14: 56000 30610 IO-APIC ide0 - NMI: 0 - IPI: 0 - <---------------------------- - -some interrupts will still be 'XT PIC', but this is not a problem, none -of those IRQ sources is 'heavy'. - -If one of your boot messages says 'unlisted/blacklisted board, DISABLING -IO-APIC IRQs', then you should do this to get multi-CPU IO-APIC IRQs -running: - - A) if your board is unlisted, then mail to linux-smp to get - it into either the white or the blacklist - B) if your board is blacklisted, then figure out the appropriate - pirq= option to get your system to boot - - -pirq= lines look like the following in /etc/lilo.conf: + hell:~> cat /proc/interrupts + CPU0 + 0: 1360293 IO-APIC-edge timer + 1: 4 IO-APIC-edge keyboard + 2: 0 XT-PIC cascade + 13: 1 XT-PIC fpu + 14: 1448 IO-APIC-edge ide0 + 16: 28232 IO-APIC-level Intel EtherExpress Pro 10/100 Ethernet + 17: 51304 IO-APIC-level eth0 + NMI: 0 + ERR: 0 + hell:~> + <---------------------------- + +some interrupts are still listed as 'XT PIC', but this is not a problem, +none of those IRQ sources is performance-critical. + + +in the unlikely case that your board does not create a working mp-table, +you can use the pirq= boot parameter to 'hand-construct' IRQ entries. This +is nontrivial though and cannot be automated. One sample /etc/lilo.conf +entry: append="pirq=15,11,10" @@ -111,8 +101,7 @@ permute all IRQ numbers properly ... it will take some time though. An won't function properly (if it's inserted as eg. a module). If you have 2 PCI buses, then you can use up to 8 pirq values. Although such -boards tend to have a good configuration and will be included in the -whitelist. +boards tend to have a good configuration. Be prepared that it might happen that you need some strange pirq line: @@ -120,14 +109,6 @@ Be prepared that it might happen that you need some strange pirq line: use smart try-and-err techniques to find out the correct pirq line ... - -the following pirq line can be used to force a board into the whitelist: - - append="pirq=0" - -[if your system works with no problems after this, then it should be added -to the official whitelist, contact us] - good luck and mail to linux-smp@vger.rutgers.edu or linux-kernel@vger.rutgers.edu if you have any problems that are not covered by this document. diff --git a/Documentation/README.DAC960 b/Documentation/README.DAC960 new file mode 100644 index 000000000..2a80042dc --- /dev/null +++ b/Documentation/README.DAC960 @@ -0,0 +1,717 @@ + Mylex DAC960/DAC1100 PCI RAID Controller Driver for Linux + + Version 2.2.4 for Linux 2.2.11 + Version 2.0.4 for Linux 2.0.37 + + PRODUCTION RELEASE + + 23 August 1999 + + Leonard N. Zubkoff + Dandelion Digital + lnz@dandelion.com + + Copyright 1998-1999 by Leonard N. Zubkoff <lnz@dandelion.com> + + + INTRODUCTION + +Mylex, Inc. designs and manufactures a variety of high performance PCI RAID +controllers. Mylex Corporation is located at 34551 Ardenwood Blvd., Fremont, +California 94555, USA and can be reached at 510/796-6100 or on the World Wide +Web at http://www.mylex.com. Mylex RAID Technical Support can be reached by +electronic mail at support@mylex.com (for eXtremeRAID 1100 and older DAC960 +models) or techsup@mylex.com (for AcceleRAID models), by voice at 510/608-2400, +or by FAX at 510/745-7715. Contact information for offices in Europe and Japan +is available on the Web site. + +The latest information on Linux support for DAC960 PCI RAID Controllers, as +well as the most recent release of this driver, will always be available from +my Linux Home Page at URL "http://www.dandelion.com/Linux/". The Linux DAC960 +driver supports all current DAC960 PCI family controllers including the +AcceleRAID models, as well as the eXtremeRAID 1100; see below for a complete +list. For simplicity, in most places this documentation refers to DAC960 +generically rather than explicitly listing all the models. + +Bug reports should be sent via electronic mail to "lnz@dandelion.com". Please +include with the bug report the complete configuration messages reported by the +driver at startup, along with any subsequent system messages relevant to the +controller's operation, and a detailed description of your system's hardware +configuration. + +Please consult the DAC960 RAID controller documentation for detailed +information regarding installation and configuration of the controllers. This +document primarily provides information specific to the Linux DAC960 support. + + + DRIVER FEATURES + +The DAC960 RAID controllers are supported solely as high performance RAID +controllers, not as interfaces to arbitrary SCSI devices. The Linux DAC960 +driver operates at the block device level, the same level as the SCSI and IDE +drivers. Unlike other RAID controllers currently supported on Linux, the +DAC960 driver is not dependent on the SCSI subsystem, and hence avoids all the +complexity and unnecessary code that would be associated with an implementation +as a SCSI driver. The DAC960 driver is designed for as high a performance as +possible with no compromises or extra code for compatibility with lower +performance devices. The DAC960 driver includes extensive error logging and +online configuration management capabilities. Except for initial configuration +of the controller and adding new disk drives, most everything can be handled +from Linux while the system is operational. + +The DAC960 driver is architected to support up to 8 controllers per system. +Each DAC960 controller can support up to 15 disk drives per channel, for a +maximum of 45 drives on a three channel controller. The drives installed on a +controller are divided into one or more "Drive Groups", and then each Drive +Group is subdivided further into 1 to 32 "Logical Drives". Each Logical Drive +has a specific RAID Level and caching policy associated with it, and it appears +to Linux as a single block device. Logical Drives are further subdivided into +up to 7 partitions through the normal Linux and PC disk partitioning schemes. +Logical Drives are also known as "System Drives", and Drive Groups are also +called "Packs". Both terms are in use in the Mylex documentation; I have +chosen to standardize on the more generic "Logical Drive" and "Drive Group". + +DAC960 RAID disk devices are named in the style of the Device File System +(DEVFS). The device corresponding to Logical Drive D on Controller C is +referred to as /dev/rd/cCdD, and the partitions are called /dev/rd/cCdDp1 +through /dev/rd/cCdDp7. For example, partition 3 of Logical Drive 5 on +Controller 2 is referred to as /dev/rd/c2d5p3. Note that unlike with SCSI +disks the device names will not change in the event of a disk drive failure. +The DAC960 driver is assigned major numbers 48 - 55 with one major number per +controller. The 8 bits of minor number are divided into 5 bits for the Logical +Drive and 3 bits for the partition. + + + SUPPORTED DAC960/DAC1100 PCI RAID CONTROLLERS + +The following list comprises the supported DAC960 and DAC1100 PCI RAID +Controllers as of the date of this document. It is recommended that anyone +purchasing a Mylex PCI RAID Controller not in the following table contact the +author beforehand to verify that it is or will be supported. + +eXtremeRAID 1100 (DAC1164P) + 3 Wide Ultra-2/LVD SCSI channels + 233MHz StrongARM SA 110 Processor + 64 Bit PCI (backward compatible with 32 Bit PCI slots) + 16MB/32MB/64MB Parity SDRAM Memory with Battery Backup + +AcceleRAID 250 (DAC960PTL1) + Uses onboard Symbios SCSI chips on certain motherboards + Also includes one onboard Wide Ultra-2/LVD SCSI Channel + 66MHz Intel i960RD RISC Processor + 4MB/8MB/16MB/32MB/64MB/128MB ECC EDO Memory + +AcceleRAID 200 (DAC960PTL0) + Uses onboard Symbios SCSI chips on certain motherboards + Includes no onboard SCSI Channels + 66MHz Intel i960RD RISC Processor + 4MB/8MB/16MB/32MB/64MB/128MB ECC EDO Memory + +AcceleRAID 150 (DAC960PRL) + Uses onboard Symbios SCSI chips on certain motherboards + Also includes one onboard Wide Ultra-2/LVD SCSI Channel + 33MHz Intel i960RP RISC Processor + 4MB Parity EDO Memory + +DAC960PJ 1/2/3 Wide Ultra SCSI-3 Channels + 66MHz Intel i960RD RISC Processor + 4MB/8MB/16MB/32MB/64MB/128MB ECC EDO Memory + +DAC960PG 1/2/3 Wide Ultra SCSI-3 Channels + 33MHz Intel i960RP RISC Processor + 4MB/8MB ECC EDO Memory + +DAC960PU 1/2/3 Wide Ultra SCSI-3 Channels + Intel i960CF RISC Processor + 4MB/8MB EDRAM or 2MB/4MB/8MB/16MB/32MB DRAM Memory + +DAC960PD 1/2/3 Wide Fast SCSI-2 Channels + Intel i960CF RISC Processor + 4MB/8MB EDRAM or 2MB/4MB/8MB/16MB/32MB DRAM Memory + +DAC960PL 1/2/3 Wide Fast SCSI-2 Channels + Intel i960 RISC Processor + 2MB/4MB/8MB/16MB/32MB DRAM Memory + +For the eXtremeRAID 1100, firmware version 5.06-0-52 or above is required. + +For the AcceleRAID 250, 200, and 150, firmware version 4.06-0-57 or above is +required. + +For the DAC960PJ and DAC960PG, firmware version 4.06-0-00 or above is required. + +For the DAC960PU, DAC960PD, and DAC960PL, firmware version 3.51-0-04 or above +is required. + +Note that earlier revisions of the DAC960PU, DAC960PD, and DAC960PL controllers +were delivered with version 2.xx firmware. Version 2.xx firmware is not +supported by this driver and no support is envisioned. Contact Mylex RAID +Technical Support to inquire about upgrading controllers with version 2.xx +firmware to version 3.51-0-04. Upgrading to version 3.xx firmware requires +installation of higher capacity Flash ROM chips, and not all DAC960PD and +DAC960PL controllers can be upgraded. + +Please note that not all SCSI disk drives are suitable for use with DAC960 +controllers, and only particular firmware versions of any given model may +actually function correctly. Similarly, not all motherboards have a BIOS that +properly initializes the AcceleRAID 250, AcceleRAID 200, AcceleRAID 150, +DAC960PJ, and DAC960PG because the Intel i960RD/RP is a multi-function device. +If in doubt, contact Mylex RAID Technical Support (support@mylex.com) to verify +compatibility. Mylex makes available a hard disk compatibility list by FTP at +ftp://ftp.mylex.com/pub/dac960/diskcomp.html. + + + DRIVER INSTALLATION + +This distribution was prepared for Linux kernel version 2.2.11 or 2.0.37. + +To install the DAC960 RAID driver, you may use the following commands, +replacing "/usr/src" with wherever you keep your Linux kernel source tree: + + cd /usr/src + tar -xvzf DAC960-2.2.4.tar.gz (or DAC960-2.0.4.tar.gz) + mv README.DAC960 linux/Documentation + mv DAC960.[ch] linux/drivers/block + patch -p0 < DAC960.patch + cd linux + make config + make depend + make bzImage (or zImage) + +Then install "arch/i386/boot/bzImage" or "arch/i386/boot/zImage" as your +standard kernel, run lilo if appropriate, and reboot. + +To create the necessary devices in /dev, the "make_rd" script included in +"DAC960-Utilities.tar.gz" from http://www.dandelion.com/Linux/ may be used. +LILO 21 and FDISK v2.9 include DAC960 support; also included in this archive +are patches to LILO 20 and FDISK v2.8 that add DAC960 support, along with +statically linked executables of LILO and FDISK. This modified version of LILO +will allow booting from a DAC960 controller and/or mounting the root file +system from a DAC960. + +Red Hat Linux 6.0 and SuSE Linux 6.1 include support for Mylex PCI RAID +controllers. Installing directly onto a DAC960 may be problematic from other +Linux distributions until their installation utilities are updated. + + + INSTALLATION NOTES + +Before installing Linux or adding DAC960 logical drives to an existing Linux +system, the controller must first be configured to provide one or more logical +drives using the BIOS Configuration Utility or DACCF. Please note that since +there are only at most 6 usable partitions on each logical drive, systems +requiring more partitions should subdivide a drive group into multiple logical +drives, each of which can have up to 6 partitions. Also, note that with large +disk arrays it is advisable to enable the 8GB BIOS Geometry (255/63) rather +than accepting the default 2GB BIOS Geometry (128/32); failing to so do will +cause the logical drive geometry to have more than 65535 cylinders which will +make it impossible for FDISK to be used properly. The 8GB BIOS Geometry can be +enabled by configuring the DAC960 BIOS, which is accessible via Alt-M during +the BIOS initialization sequence. + +For maximum performance and the most efficient E2FSCK performance, it is +recommended that EXT2 file systems be built with a 4KB block size and 16 block +stride to match the DAC960 controller's 64KB default stripe size. The command +"mke2fs -b 4096 -R stride=16 <device>" is appropriate. Unless there will be a +large number of small files on the file systems, it is also beneficial to add +the "-i 16384" option to increase the bytes per inode parameter thereby +reducing the file system metadata. Finally, on systems that will only be run +with Linux 2.2 or later kernels it is beneficial to enable sparse superblocks +with the "-s 1" option. + + + DAC960 ANNOUNCEMENTS MAILING LIST + +The DAC960 Announcements Mailing List provides a forum for informing Linux +users of new driver releases and other announcements regarding Linux support +for DAC960 PCI RAID Controllers. To join the mailing list, send a message to +"dac960-announce-request@dandelion.com" with the line "subscribe" in the +message body. + + + CONTROLLER CONFIGURATION AND STATUS MONITORING + +The DAC960 RAID controllers running firmware 4.06 or above include a Background +Initialization facility so that system downtime is minimized both for initial +installation and subsequent configuration of additional storage. The BIOS +Configuration Utility (accessible via Alt-R during the BIOS initialization +sequence) is used to quickly configure the controller, and then the logical +drives that have been created are available for immediate use even while they +are still being initialized by the controller. The primary need for online +configuration and status monitoring is then to avoid system downtime when disk +drives fail and must be replaced. Mylex's online monitoring and configuration +utilities are being ported to Linux and will become available at some point in +the future. Note that with a SAF-TE (SCSI Accessed Fault-Tolerant Enclosure) +enclosure, the controller is able to rebuild failed drives automatically as +soon as a drive replacement is made available. + +The primary interfaces for controller configuration and status monitoring are +special files created in the /proc/rd/... hierarchy along with the normal +system console logging mechanism. Whenever the system is operating, the DAC960 +driver queries each controller for status information every 10 seconds, and +checks for additional conditions every 60 seconds. The initial status of each +controller is always available for controller N in /proc/rd/cN/initial_status, +and the current status as of the last status monitoring query is available in +/proc/rd/cN/current_status. In addition, status changes are also logged by the +driver to the system console and will appear in the log files maintained by +syslog. The progress of asynchronous rebuild or consistency check operations +is also available in /proc/rd/cN/current_status, and progress messages are +logged to the system console at most every 60 seconds. + +Starting with the 2.2.3/2.0.3 versions of the driver, the status information +available in /proc/rd/cN/initial_status and /proc/rd/cN/current_status has been +augmented to include the vendor, model, revision, and serial number (if +available) for each physical device found connected to the controller: + +***** DAC960 RAID Driver Version 2.2.3 of 19 August 1999 ***** +Copyright 1998-1999 by Leonard N. Zubkoff <lnz@dandelion.com> +Configuring Mylex DAC960PRL PCI RAID Controller + Firmware Version: 4.07-0-07, Channels: 1, Memory Size: 16MB + PCI Bus: 1, Device: 4, Function: 1, I/O Address: Unassigned + PCI Address: 0xFE300000 mapped at 0xA0800000, IRQ Channel: 21 + Controller Queue Depth: 128, Maximum Blocks per Command: 128 + Driver Queue Depth: 127, Maximum Scatter/Gather Segments: 33 + Stripe Size: 64KB, Segment Size: 8KB, BIOS Geometry: 255/63 + SAF-TE Enclosure Management Enabled + Physical Devices: + 0:0 Vendor: IBM Model: DRVS09D Revision: 0270 + Serial Number: 68016775HA + Disk Status: Online, 17928192 blocks + 0:1 Vendor: IBM Model: DRVS09D Revision: 0270 + Serial Number: 68004E53HA + Disk Status: Online, 17928192 blocks + 0:2 Vendor: IBM Model: DRVS09D Revision: 0270 + Serial Number: 13013935HA + Disk Status: Online, 17928192 blocks + 0:3 Vendor: IBM Model: DRVS09D Revision: 0270 + Serial Number: 13016897HA + Disk Status: Online, 17928192 blocks + 0:4 Vendor: IBM Model: DRVS09D Revision: 0270 + Serial Number: 68019905HA + Disk Status: Online, 17928192 blocks + 0:5 Vendor: IBM Model: DRVS09D Revision: 0270 + Serial Number: 68012753HA + Disk Status: Online, 17928192 blocks + 0:6 Vendor: ESG-SHV Model: SCA HSBP M6 Revision: 0.61 + Logical Drives: + /dev/rd/c0d0: RAID-5, Online, 89640960 blocks, Write Thru + No Rebuild or Consistency Check in Progress + +To simplify the monitoring process for custom software, the special file +/proc/rd/status returns "OK" when all DAC960 controllers in the system are +operating normally and no failures have occurred, or "ALERT" if any logical +drives are offline or critical or any non-standby physical drives are dead. + +Configuration commands for controller N are available via the special file +/proc/rd/cN/user_command. A human readable command can be written to this +special file to initiate a configuration operation, and the results of the +operation can then be read back from the special file in addition to being +logged to the system console. The shell command sequence + + echo "<configuration-command>" > /proc/rd/c0/user_command + cat /proc/rd/c0/user_command + +is typically used to execute configuration commands. The configuration +commands are: + + flush-cache + + The "flush-cache" command flushes the controller's cache. The system + automatically flushes the cache at shutdown or if the driver module is + unloaded, so this command is only needed to be certain a write back cache + is flushed to disk before the system is powered off by a command to a UPS. + Note that the flush-cache command also stops an asynchronous rebuild or + consistency check, so it should not be used except when the system is being + halted. + + kill <channel>:<target-id> + + The "kill" command marks the physical drive <channel>:<target-id> as DEAD. + This command is provided primarily for testing, and should not be used + during normal system operation. + + make-online <channel>:<target-id> + + The "make-online" command changes the physical drive <channel>:<target-id> + from status DEAD to status ONLINE. In cases where multiple physical drives + have been killed simultaneously, this command may be used to bring them + back online, after which a consistency check is advisable. + + Warning: make-online should only be used on a dead physical drive that is + an active part of a drive group, never on a standby drive. + + make-standby <channel>:<target-id> + + The "make-standby" command changes physical drive <channel>:<target-id> + from status DEAD to status STANDBY. It should only be used in cases where + a dead drive was replaced after an automatic rebuild was performed onto a + standby drive. It cannot be used to add a standby drive to the controller + configuration if one was not created initially; the BIOS Configuration + Utility must be used for that currently. + + rebuild <channel>:<target-id> + + The "rebuild" command initiates an asynchronous rebuild onto physical drive + <channel>:<target-id>. It should only be used when a dead drive has been + replaced. + + check-consistency <logical-drive-number> + + The "check-consistency" command initiates an asynchronous consistency check + of <logical-drive-number> with automatic restoration. It can be used + whenever it is desired to verify the consistency of the redundancy + information. + + cancel-rebuild + cancel-consistency-check + + The "cancel-rebuild" and "cancel-consistency-check" commands cancel any + rebuild or consistency check operations previously initiated. + + + EXAMPLE I - DRIVE FAILURE WITHOUT A STANDBY DRIVE + +The following annotated logs demonstrate the controller configuration and and +online status monitoring capabilities of the Linux DAC960 Driver. The test +configuration comprises 6 1GB Quantum Atlas I disk drives on two channels of a +DAC960PJ controller. The physical drives are configured into a single drive +group without a standby drive, and the drive group has been configured into two +logical drives, one RAID-5 and one RAID-6. Note that these logs are from an +earlier version of the driver and the messages have changed somewhat with newer +releases, but the functionality remains similar. First, here is the current +status of the RAID configuration: + +gwynedd:/u/lnz# cat /proc/rd/c0/current_status +***** DAC960 RAID Driver Version 2.0.0 of 23 March 1999 ***** +Copyright 1998-1999 by Leonard N. Zubkoff <lnz@dandelion.com> +Configuring Mylex DAC960PJ PCI RAID Controller + Firmware Version: 4.06-0-08, Channels: 3, Memory Size: 8MB + PCI Bus: 0, Device: 19, Function: 1, I/O Address: Unassigned + PCI Address: 0xFD4FC000 mapped at 0x8807000, IRQ Channel: 9 + Controller Queue Depth: 128, Maximum Blocks per Command: 128 + Driver Queue Depth: 127, Maximum Scatter/Gather Segments: 33 + Stripe Size: 64KB, Segment Size: 8KB, BIOS Geometry: 255/63 + Physical Devices: + 0:1 - Disk: Online, 2201600 blocks + 0:2 - Disk: Online, 2201600 blocks + 0:3 - Disk: Online, 2201600 blocks + 1:1 - Disk: Online, 2201600 blocks + 1:2 - Disk: Online, 2201600 blocks + 1:3 - Disk: Online, 2201600 blocks + Logical Drives: + /dev/rd/c0d0: RAID-5, Online, 5498880 blocks, Write Thru + /dev/rd/c0d1: RAID-6, Online, 3305472 blocks, Write Thru + No Rebuild or Consistency Check in Progress + +gwynedd:/u/lnz# cat /proc/rd/status +OK + +The above messages indicate that everything is healthy, and /proc/rd/status +returns "OK" indicating that there are no problems with any DAC960 controller +in the system. For demonstration purposes, while I/O is active Physical Drive +1:1 is now disconnected, simulating a drive failure. The failure is noted by +the driver within 10 seconds of the controller's having detected it, and the +driver logs the following console status messages indicating that Logical +Drives 0 and 1 are now CRITICAL as a result of Physical Drive 1:1 being DEAD: + +DAC960#0: Physical Drive 1:2 Error Log: Sense Key = 6, ASC = 29, ASCQ = 02 +DAC960#0: Physical Drive 1:3 Error Log: Sense Key = 6, ASC = 29, ASCQ = 02 +DAC960#0: Physical Drive 1:1 killed because of timeout on SCSI command +DAC960#0: Physical Drive 1:1 is now DEAD +DAC960#0: Logical Drive 0 (/dev/rd/c0d0) is now CRITICAL +DAC960#0: Logical Drive 1 (/dev/rd/c0d1) is now CRITICAL + +The Sense Keys logged here are just Check Condition / Unit Attention conditions +arising from a SCSI bus reset that is forced by the controller during its error +recovery procedures. Concurrently with the above, the driver status available +from /proc/rd also reflects the drive failure. The status message in +/proc/rd/status has changed from "OK" to "ALERT": + +gwynedd:/u/lnz# cat /proc/rd/status +ALERT + +and /proc/rd/c0/current_status has been updated: + +gwynedd:/u/lnz# cat /proc/rd/c0/current_status + ... + Physical Devices: + 0:1 - Disk: Online, 2201600 blocks + 0:2 - Disk: Online, 2201600 blocks + 0:3 - Disk: Online, 2201600 blocks + 1:1 - Disk: Dead, 2201600 blocks + 1:2 - Disk: Online, 2201600 blocks + 1:3 - Disk: Online, 2201600 blocks + Logical Drives: + /dev/rd/c0d0: RAID-5, Critical, 5498880 blocks, Write Thru + /dev/rd/c0d1: RAID-6, Critical, 3305472 blocks, Write Thru + No Rebuild or Consistency Check in Progress + +Since there are no standby drives configured, the system can continue to access +the logical drives in a performance degraded mode until the failed drive is +replaced and a rebuild operation completed to restore the redundancy of the +logical drives. Once Physical Drive 1:1 is replaced with a properly +functioning drive, or if the physical drive was killed without having failed +(e.g., due to electrical problems on the SCSI bus), the user can instruct the +controller to initiate a rebuild operation onto the newly replaced drive: + +gwynedd:/u/lnz# echo "rebuild 1:1" > /proc/rd/c0/user_command +gwynedd:/u/lnz# cat /proc/rd/c0/user_command +Rebuild of Physical Drive 1:1 Initiated + +The echo command instructs the controller to initiate an asynchronous rebuild +operation onto Physical Drive 1:1, and the status message that results from the +operation is then available for reading from /proc/rd/c0/user_command, as well +as being logged to the console by the driver. + +Within 10 seconds of this command the driver logs the initiation of the +asynchronous rebuild operation: + +DAC960#0: Rebuild of Physical Drive 1:1 Initiated +DAC960#0: Physical Drive 1:1 Error Log: Sense Key = 6, ASC = 29, ASCQ = 01 +DAC960#0: Physical Drive 1:1 is now WRITE-ONLY +DAC960#0: Rebuild in Progress: Logical Drive 0 (/dev/rd/c0d0) 1% completed + +and /proc/rd/c0/current_status is updated: + +gwynedd:/u/lnz# cat /proc/rd/c0/current_status + ... + Physical Devices: + 0:1 - Disk: Online, 2201600 blocks + 0:2 - Disk: Online, 2201600 blocks + 0:3 - Disk: Online, 2201600 blocks + 1:1 - Disk: Write-Only, 2201600 blocks + 1:2 - Disk: Online, 2201600 blocks + 1:3 - Disk: Online, 2201600 blocks + Logical Drives: + /dev/rd/c0d0: RAID-5, Critical, 5498880 blocks, Write Thru + /dev/rd/c0d1: RAID-6, Critical, 3305472 blocks, Write Thru + Rebuild in Progress: Logical Drive 0 (/dev/rd/c0d0) 6% completed + +As the rebuild progresses, the current status in /proc/rd/c0/current_status is +updated every 10 seconds: + +gwynedd:/u/lnz# cat /proc/rd/c0/current_status + ... + Physical Devices: + 0:1 - Disk: Online, 2201600 blocks + 0:2 - Disk: Online, 2201600 blocks + 0:3 - Disk: Online, 2201600 blocks + 1:1 - Disk: Write-Only, 2201600 blocks + 1:2 - Disk: Online, 2201600 blocks + 1:3 - Disk: Online, 2201600 blocks + Logical Drives: + /dev/rd/c0d0: RAID-5, Critical, 5498880 blocks, Write Thru + /dev/rd/c0d1: RAID-6, Critical, 3305472 blocks, Write Thru + Rebuild in Progress: Logical Drive 0 (/dev/rd/c0d0) 15% completed + +and every minute a progress message is logged to the console by the driver: + +DAC960#0: Rebuild in Progress: Logical Drive 0 (/dev/rd/c0d0) 32% completed +DAC960#0: Rebuild in Progress: Logical Drive 0 (/dev/rd/c0d0) 63% completed +DAC960#0: Rebuild in Progress: Logical Drive 0 (/dev/rd/c0d0) 94% completed +DAC960#0: Rebuild in Progress: Logical Drive 1 (/dev/rd/c0d1) 94% completed + +Finally, the rebuild completes successfully. The driver logs the status of the +logical and physical drives and the rebuild completion: + +DAC960#0: Rebuild Completed Successfully +DAC960#0: Physical Drive 1:1 is now ONLINE +DAC960#0: Logical Drive 0 (/dev/rd/c0d0) is now ONLINE +DAC960#0: Logical Drive 1 (/dev/rd/c0d1) is now ONLINE + +/proc/rd/c0/current_status is updated: + +gwynedd:/u/lnz# cat /proc/rd/c0/current_status + ... + Physical Devices: + 0:1 - Disk: Online, 2201600 blocks + 0:2 - Disk: Online, 2201600 blocks + 0:3 - Disk: Online, 2201600 blocks + 1:1 - Disk: Online, 2201600 blocks + 1:2 - Disk: Online, 2201600 blocks + 1:3 - Disk: Online, 2201600 blocks + Logical Drives: + /dev/rd/c0d0: RAID-5, Online, 5498880 blocks, Write Thru + /dev/rd/c0d1: RAID-6, Online, 3305472 blocks, Write Thru + Rebuild Completed Successfully + +and /proc/rd/status indicates that everything is healthy once again: + +gwynedd:/u/lnz# cat /proc/rd/status +OK + + + EXAMPLE II - DRIVE FAILURE WITH A STANDBY DRIVE + +The following annotated logs demonstrate the controller configuration and and +online status monitoring capabilities of the Linux DAC960 Driver. The test +configuration comprises 6 1GB Quantum Atlas I disk drives on two channels of a +DAC960PJ controller. The physical drives are configured into a single drive +group with a standby drive, and the drive group has been configured into two +logical drives, one RAID-5 and one RAID-6. Note that these logs are from an +earlier version of the driver and the messages have changed somewhat with newer +releases, but the functionality remains similar. First, here is the current +status of the RAID configuration: + +gwynedd:/u/lnz# cat /proc/rd/c0/current_status +***** DAC960 RAID Driver Version 2.0.0 of 23 March 1999 ***** +Copyright 1998-1999 by Leonard N. Zubkoff <lnz@dandelion.com> +Configuring Mylex DAC960PJ PCI RAID Controller + Firmware Version: 4.06-0-08, Channels: 3, Memory Size: 8MB + PCI Bus: 0, Device: 19, Function: 1, I/O Address: Unassigned + PCI Address: 0xFD4FC000 mapped at 0x8807000, IRQ Channel: 9 + Controller Queue Depth: 128, Maximum Blocks per Command: 128 + Driver Queue Depth: 127, Maximum Scatter/Gather Segments: 33 + Stripe Size: 64KB, Segment Size: 8KB, BIOS Geometry: 255/63 + Physical Devices: + 0:1 - Disk: Online, 2201600 blocks + 0:2 - Disk: Online, 2201600 blocks + 0:3 - Disk: Online, 2201600 blocks + 1:1 - Disk: Online, 2201600 blocks + 1:2 - Disk: Online, 2201600 blocks + 1:3 - Disk: Standby, 2201600 blocks + Logical Drives: + /dev/rd/c0d0: RAID-5, Online, 4399104 blocks, Write Thru + /dev/rd/c0d1: RAID-6, Online, 2754560 blocks, Write Thru + No Rebuild or Consistency Check in Progress + +gwynedd:/u/lnz# cat /proc/rd/status +OK + +The above messages indicate that everything is healthy, and /proc/rd/status +returns "OK" indicating that there are no problems with any DAC960 controller +in the system. For demonstration purposes, while I/O is active Physical Drive +1:2 is now disconnected, simulating a drive failure. The failure is noted by +the driver within 10 seconds of the controller's having detected it, and the +driver logs the following console status messages: + +DAC960#0: Physical Drive 1:1 Error Log: Sense Key = 6, ASC = 29, ASCQ = 02 +DAC960#0: Physical Drive 1:3 Error Log: Sense Key = 6, ASC = 29, ASCQ = 02 +DAC960#0: Physical Drive 1:2 killed because of timeout on SCSI command +DAC960#0: Physical Drive 1:2 is now DEAD +DAC960#0: Physical Drive 1:2 killed because it was removed +DAC960#0: Logical Drive 0 (/dev/rd/c0d0) is now CRITICAL +DAC960#0: Logical Drive 1 (/dev/rd/c0d1) is now CRITICAL + +Since a standby drive is configured, the controller automatically begins +rebuilding onto the standby drive: + +DAC960#0: Physical Drive 1:3 is now WRITE-ONLY +DAC960#0: Rebuild in Progress: Logical Drive 0 (/dev/rd/c0d0) 4% completed + +Concurrently with the above, the driver status available from /proc/rd also +reflects the drive failure and automatic rebuild. The status message in +/proc/rd/status has changed from "OK" to "ALERT": + +gwynedd:/u/lnz# cat /proc/rd/status +ALERT + +and /proc/rd/c0/current_status has been updated: + +gwynedd:/u/lnz# cat /proc/rd/c0/current_status + ... + Physical Devices: + 0:1 - Disk: Online, 2201600 blocks + 0:2 - Disk: Online, 2201600 blocks + 0:3 - Disk: Online, 2201600 blocks + 1:1 - Disk: Online, 2201600 blocks + 1:2 - Disk: Dead, 2201600 blocks + 1:3 - Disk: Write-Only, 2201600 blocks + Logical Drives: + /dev/rd/c0d0: RAID-5, Critical, 4399104 blocks, Write Thru + /dev/rd/c0d1: RAID-6, Critical, 2754560 blocks, Write Thru + Rebuild in Progress: Logical Drive 0 (/dev/rd/c0d0) 4% completed + +As the rebuild progresses, the current status in /proc/rd/c0/current_status is +updated every 10 seconds: + +gwynedd:/u/lnz# cat /proc/rd/c0/current_status + ... + Physical Devices: + 0:1 - Disk: Online, 2201600 blocks + 0:2 - Disk: Online, 2201600 blocks + 0:3 - Disk: Online, 2201600 blocks + 1:1 - Disk: Online, 2201600 blocks + 1:2 - Disk: Dead, 2201600 blocks + 1:3 - Disk: Write-Only, 2201600 blocks + Logical Drives: + /dev/rd/c0d0: RAID-5, Critical, 4399104 blocks, Write Thru + /dev/rd/c0d1: RAID-6, Critical, 2754560 blocks, Write Thru + Rebuild in Progress: Logical Drive 0 (/dev/rd/c0d0) 40% completed + +and every minute a progress message is logged on the console by the driver: + +DAC960#0: Rebuild in Progress: Logical Drive 0 (/dev/rd/c0d0) 40% completed +DAC960#0: Rebuild in Progress: Logical Drive 0 (/dev/rd/c0d0) 76% completed +DAC960#0: Rebuild in Progress: Logical Drive 1 (/dev/rd/c0d1) 66% completed +DAC960#0: Rebuild in Progress: Logical Drive 1 (/dev/rd/c0d1) 84% completed + +Finally, the rebuild completes successfully. The driver logs the status of the +logical and physical drives and the rebuild completion: + +DAC960#0: Rebuild Completed Successfully +DAC960#0: Physical Drive 1:3 is now ONLINE +DAC960#0: Logical Drive 0 (/dev/rd/c0d0) is now ONLINE +DAC960#0: Logical Drive 1 (/dev/rd/c0d1) is now ONLINE + +/proc/rd/c0/current_status is updated: + +***** DAC960 RAID Driver Version 2.0.0 of 23 March 1999 ***** +Copyright 1998-1999 by Leonard N. Zubkoff <lnz@dandelion.com> +Configuring Mylex DAC960PJ PCI RAID Controller + Firmware Version: 4.06-0-08, Channels: 3, Memory Size: 8MB + PCI Bus: 0, Device: 19, Function: 1, I/O Address: Unassigned + PCI Address: 0xFD4FC000 mapped at 0x8807000, IRQ Channel: 9 + Controller Queue Depth: 128, Maximum Blocks per Command: 128 + Driver Queue Depth: 127, Maximum Scatter/Gather Segments: 33 + Stripe Size: 64KB, Segment Size: 8KB, BIOS Geometry: 255/63 + Physical Devices: + 0:1 - Disk: Online, 2201600 blocks + 0:2 - Disk: Online, 2201600 blocks + 0:3 - Disk: Online, 2201600 blocks + 1:1 - Disk: Online, 2201600 blocks + 1:2 - Disk: Dead, 2201600 blocks + 1:3 - Disk: Online, 2201600 blocks + Logical Drives: + /dev/rd/c0d0: RAID-5, Online, 4399104 blocks, Write Thru + /dev/rd/c0d1: RAID-6, Online, 2754560 blocks, Write Thru + Rebuild Completed Successfully + +and /proc/rd/status indicates that everything is healthy once again: + +gwynedd:/u/lnz# cat /proc/rd/status +OK + +Note that the absence of a viable standby drive does not create an "ALERT" +status. Once dead Physical Drive 1:2 has been replaced, the controller must be +told that this has occurred and that the newly replaced drive should become the +new standby drive: + +gwynedd:/u/lnz# echo "make-standby 1:2" > /proc/rd/c0/user_command +gwynedd:/u/lnz# cat /proc/rd/c0/user_command +Make Standby of Physical Drive 1:2 Succeeded + +The echo command instructs the controller to make Physical Drive 1:2 into a +standby drive, and the status message that results from the operation is then +available for reading from /proc/rd/c0/user_command, as well as being logged to +the console by the driver. Within 60 seconds of this command the driver logs: + +DAC960#0: Physical Drive 1:2 Error Log: Sense Key = 6, ASC = 29, ASCQ = 01 +DAC960#0: Physical Drive 1:2 is now STANDBY +DAC960#0: Make Standby of Physical Drive 1:2 Succeeded + +and /proc/rd/c0/current_status is updated: + +gwynedd:/u/lnz# cat /proc/rd/c0/current_status + ... + Physical Devices: + 0:1 - Disk: Online, 2201600 blocks + 0:2 - Disk: Online, 2201600 blocks + 0:3 - Disk: Online, 2201600 blocks + 1:1 - Disk: Online, 2201600 blocks + 1:2 - Disk: Standby, 2201600 blocks + 1:3 - Disk: Online, 2201600 blocks + Logical Drives: + /dev/rd/c0d0: RAID-5, Online, 4399104 blocks, Write Thru + /dev/rd/c0d1: RAID-6, Online, 2754560 blocks, Write Thru + Rebuild Completed Successfully diff --git a/Documentation/atm.txt b/Documentation/atm.txt new file mode 100644 index 000000000..2fc1b5a60 --- /dev/null +++ b/Documentation/atm.txt @@ -0,0 +1,8 @@ +In order to use anything but the most primitive functions of ATM, +several user-mode programs are required to assist the kernel. These +programs and related material can be found via the ATM on Linux Web +page at http://icawww1.epfl.ch/linux-atm/ + +If you encounter problems with ATM, please report them on the ATM +on Linux mailing list. Subscription information, archives, etc., +can be found on http://icawww1.epfl.ch/linux-atm/ diff --git a/Documentation/computone.txt b/Documentation/computone.txt new file mode 100644 index 000000000..c1577ec21 --- /dev/null +++ b/Documentation/computone.txt @@ -0,0 +1,343 @@ + +Computone Intelliport II/Plus Multiport Serial Driver +----------------------------------------------------- + +Release Notes For Linux Kernel 2.2 and higher. +These notes are for the drivers which have already been integrated into the +kernel and have been tested on Linux kernels 2.0, 2.2, and 2.3. + +Version: 1.2.4 +Date: 08/04/99 +Author: Andrew Manison <amanison@america.net> +Testing: larryg@computone.com +Support: support@computone.com +Fixes and Updates: Doug McNash <dmcnash@computone.com> +Proc Filesystem and Kernel Integration: Mike Warfield <mhw@wittsend.com> + + +This file assumes that you are using the Computone drivers which are +integrated into the kernel sources. For updating the drivers or installing +drivers into kernels which do not already have Computone drivers, please +refer to the instructions in the README.computone file in the driver patch. + + +1. INTRODUCTION + +This driver supports the entire family of Intelliport II/Plus controllers +with the exception of the MicroChannel controllers. It does not support +products previous to the Intelliport II. + +This driver was developed on the v2.0.x Linux tree and has been tested up +to v2.2.9; it will probably not work with earlier v1.X kernels,. + + +2. QUICK INSTALLATION + +Hardware - If you have an ISA card, find a free interrupt and io port. + List those in use with `cat /proc/interrupts` and + `cat /proc/ioports`. Set the card dip switches to a free + address. You may need to configure your BIOS to reserve an + irq for an ISA card. PCI and EISA parameters are set + automagically. Insert card into computer with the power off + before or after drivers installation. + + Note the hardware address from the Computone ISA cards installed into + the system. These are required for editing ip2.h or editing + /etc/config.modules, or for specification on the modprobe + command line. + +Software - + +Module installation: + +a) Obtain driver-kernel patch file +b) Copy to the linux source tree root, Run ip2build (if not patch) +c) Determine free irq/address to use if any (configure BIOS if need be) +d) Run "make config" or "make menuconfig" or "make xconfig" + Select (m) module for CONFIG_COMPUTONE under character + devices. CONFIG_PCI and CONFIG_MODULES also may need to be set. +e) Set address on ISA cards then: + edit /usr/src/linux/drivers/char/ip2/ip2.h if needed + or + edit /etc/conf.modules (or /etc/modules.conf) if needed (module). + or both to match this setting. +f) Run "make dep" +g) Run "make modules" +h) Run "make modules_install" +i) Run "/sbin/depmod -a" +j) install driver using `modprobe ip2 <options>` (options listed below) +k) run ip2mkdev (either the script below or the binary version) + + +Kernel installation: + +a) Obtain driver-kernel patch file +b) Copy to the linux source tree root, Run ip2build (if not patch) +c) Determine free irq/address to use if any (configure BIOS if need be) +d) Run "make config" or "make menuconfig" or "make xconfig" + Select (y) kernel for CONFIG_COMPUTONE under character + devices. CONFIG_PCI may need to be set if you have PCI bus. +e) Set address on ISA cards then: + edit /usr/src/linux/drivers/char/ip2/ip2.h +f) Run "make dep" +g) Run "make zImage" or whatever target you prefer. +h) mv /usr/src/linux/arch/i386/boot/zImage to /boot. +i) Add new config for this kernel into /etc/lilo.conf, run "lilo" + or copy to a floppy disk and boot from that floppy disk. +j) Reboot using this kernel +k) run ip2mkdev (either the script below or the binary version) + + +3. INSTALLATION + +Previously, the driver sources were packaged with a set of patch files +to update the character drivers' makefile and configuration file, and other +kernel source files. A build script (ip2build) was included which applies +the patches if needed, and build any utilities needed. +What you recieve may be a single patch file in conventional kernel +patch format build script. That form can also be applied by +running patch -p1 < ThePatchFile. Otherwise run ip2build. + +The driver can be installed as a module (recommended) or built into the +kernel. This is selected as for other drivers through the `make config` +command from the root of the Linux source tree. If the driver is built +into the kernel you will need to edit the file ip2.h to match the boards +you are installing. See that file for instructions. If the driver is +installed as a module the configuration can also be specified on the +modprobe command line as follows: + + modprobe ip2 irq=irq1,irq2,irq3,irq4 io=addr1,addr2,addr3,addr4 + +where irqnum is one of the valid Intelliport II interrupts (3,4,5,7,10,11, +12,15) and addr1-4 are the base addresses for up to four controllers. If +the irqs are not specified the driver uses the default in ip2/ip2.h (which +selects polled mode). If no base addresses are specified the defaults in +ip2.h are used. If you are autoloading the driver module with kerneld or +kmod the base addresses and interrupt number must also be set in ip2/ip2.h +and recompile or just insert and options line in /etc/modules.conf or both. +The options line is equivalent to the command line and takes precidence over +what is in ip2.h. + +/etc/modules.conf sample: + options ip2 io=1,0x328 irq=1,10 + alias char-major-71 ip2 + alias char-major-72 ip2 + alias char-major-73 ip2 + +equivelant ip2.h: +static ip2config_t ip2config = +{ + {1,10,0,0}, + { + 0x0001, // Board 0, ttyF0 - ttyF63 /* PCI card */ + 0x0328, // Board 1, ttyF64 - ttyF127 /* ISA card */ + 0x0000, // Board 2, ttyF128 - ttyF191 /* empty */ + 0x0000 // Board 3, ttyF192 - ttyF255 /* empty */ + } +}; + + +Note: Both io and irq should be updated to reflect YOUR system. An "io" + address of "1/2" indicates a PCI/EISA card in the board table. The + PCI or EISA irq will be assigned automatically. + +Specifying an invalid or in-use irq will default the driver into +running in polled mode for that card. If all irq entries are 0 then +all cards will operate in polled mode. + +If you select the driver as part of the kernel run : + + make depend + make zlilo (or whatever you do to create a bootable kernel) + +If you selected a module run : + + make modules && make modules_install + +The utility ip2mkdev (see 5 and 7 below) creates all the device nodes +required by the driver. For a device to be created it must be configured +in the driver and the board must be installed. Only devices corresponding +to real IntelliPort II ports are created. With multiple boards and expansion +boxes this will leave gaps in the sequence of device names. ip2mkdev uses +Linux tty naming conventions: ttyF0 - ttyF255 for normal devices, and +cuf0 - cuf255 for callout devices. + + +4. USING THE DRIVERS + +As noted above, the driver implements the ports in accordance with Linux +conventions, and the devices should be interchangeable with the standard +serial devices. (This is a key point for problem reporting: please make +sure that what you are trying do works on the ttySx/cuax ports first; then +tell us what went wrong with the ip2 ports!) + +Higher speeds can be obtained using the setserial utility which remaps +38,400 bps (extb) to 57,600 bps, 115,200 bps, or a custom speed. +Intelliport II installations using the PowerPort expansion module can +use the custom speed setting to select the highest speeds: 153,600 bps, +230,400 bps, 307,200 bps, 460,800bps and 921,600 bps. The base for +custom baud rate configuration is fixed at 921,600 for cards/expantion +modules with ST654's and 115200 for those with Cirrus CD1400's. This +corresponds to the maximum bit rates those chips are capable. +For example if the baud base is 921600 and the baud divisor is 18 then +the custom rate is 921600/18 = 51200 bps. See the setserial man page for +complete details. Of course if stty accepts the higher rates now you can +use that as well as the standard ioctls(). + + +5. ip2mkdev and assorted utilities... + +Several utilities, including the source for a binary ip2mkdev utility are +available under .../drivers/char/ip2. These can be build by changing to +that directory and typing "make" after the kernel has be built. If you do +not wish to compile the binary utilities, the shell script below can be +cut out and run as "ip2mkdev" to create the necessary device files. To +use the ip2mkdev script, you must have procfs enabled and the proc file +system mounted on /proc. + +6. NOTES + +This is a release version of the driver, but it is impossible to test it +in all configurations of Linux. If there is any anomalous behaviour that +does not match the standard serial port's behaviour please let us know. + + +7. ip2mkdev shell script + +===== Cut Here ===== +#!/bin/sh - + +# ip2mkdev +# +# Make or remove devices as needed for Computone Intelliport drivers +# +# First rule! If the dev file exists and you need it, don't mess +# with it. That prevents us from screwing up open ttys, ownership +# and permissions on a running system! +# +# This script will NOT remove devices that no longer exist because +# their board or interface box has been removed. If you want to get +# rid of them, you can manually do an "rm -f /dev/ttyF* /dev/cuaf*" +# before running this script, which will then recreate all the valid +# devices +# +# =mhw= +# Michael H. Warfield +# mhw@wittsend.com +# +if test ! -f /proc/tty/drivers +then + echo "\ +Unable to check driver status. +Make sure proc file system is mounted." + + exit 255 +fi + +if test ! -f /proc/tty/driver/ip2 +then + echo "\ +Unable to locate ip2 proc file. +Attempting to load driver" + + if insmod ip2 + then + if test ! -f /proc/tty/driver/ip2 + then + echo "\ +Unable to locate ip2 proc file after loading driver. +Driver initialization failure or driver version error. +" + exit 255 + fi + else + echo "Unable to load ip2 driver." + exit 255 + fi +fi + +# Ok... So we got the driver loaded and we can locate the procfs files. +# Next we need our major numbers. + +TTYMAJOR=`sed -e '/^ip2/!d' -e '/\/dev\/tty/!d' -e 's/.*tty.[ ]*\([0-9]*\)[ ]*.*/\1/' < /proc/tty/drivers` +CUAMAJOR=`sed -e '/^ip2/!d' -e '/\/dev\/cu/!d' -e 's/.*cu.[ ]*\([0-9]*\)[ ]*.*/\1/' < /proc/tty/drivers` +BRDMAJOR=`sed -e '/^Driver: /!d' -e 's/.*IMajor=\([0-9]*\)[ ]*.*/\1/' < /proc/tty/driver/ip2` + +echo "\ +TTYMAJOR = $TTYMAJOR +CUAMAJOR = $CUAMAJOR +BRDMAJOR = $BRDMAJOR +" + +# Ok... Now we should know our major numbers, if appropriate... +# Now we need our boards and start the device loops. + +grep '^Board [0-9]:' /proc/tty/driver/ip2 | while read token number type alltherest +do + # The test for blank "type" will catch the stats lead-in lines + # if they exist in the file + if test "$type" = "vacant" -o "$type" = "Vacant" -o "$type" = "" + then + continue + fi + + BOARDNO=`expr "$number" : '\([0-9]\):'` + PORTS=`expr "$alltherest" : '.*ports=\([0-9]*\)' | tr ',' ' '` + MINORS=`expr "$alltherest" : '.*minors=\([0-9,]*\)' | tr ',' ' '` + + if test "$BOARDNO" = "" -o "$PORTS" = "" + then +# This may be a bug. We should at least get this much information + echo "Unable to process board line" + continue + fi + + if test "$MINORS" = "" + then +# Silently skip this one. This board seems to have no boxes + continue + fi + + echo "board $BOARDNO: $type ports = $PORTS; port numbers = $MINORS" + + if test "$BRDMAJOR" != "" + then + BRDMINOR=`expr $BOARDNO \* 4` + STSMINOR=`expr $BRDMINOR + 1` + if test ! -c /dev/ip2ipl$BOARDNO ; then + mknod /dev/ip2ipl$BOARDNO c $BRDMAJOR $BRDMINOR + fi + if test ! -c /dev/ip2stat$BOARDNO ; then + mknod /dev/ip2stat$BOARDNO c $BRDMAJOR $STSMINOR + fi + fi + + if test "$TTYMAJOR" != "" + then + PORTNO=$BOARDBASE + + for PORTNO in $MINORS + do + if test ! -c /dev/ttyF$PORTNO ; then + # We got the harware but no device - make it + mknod /dev/ttyF$PORTNO c $TTYMAJOR $PORTNO + fi + done + fi + + if test "$CUAMAJOR" != "" + then + PORTNO=$BOARDBASE + + for PORTNO in $MINORS + do + if test ! -c /dev/cuf$PORTNO ; then + # We got the harware but no device - make it + mknod /dev/cuf$PORTNO c $CUAMAJOR $PORTNO + fi + done + fi +done + +exit 0 +===== Cut Here ===== diff --git a/Documentation/devices.tex b/Documentation/devices.tex index 5bd758c0d..d4e10e7f7 100644 --- a/Documentation/devices.tex +++ b/Documentation/devices.tex @@ -1784,6 +1784,16 @@ major number 3). \end{devicelist} \begin{devicelist} +\major{ }{}{block}{Eighth IDE hard disk/CD-ROM interface} + \minor{0}{/dev/hdq}{Master: whole disk (or CD-ROM)} + \minor{64}{/dev/hdr}{Slave: whole disk (or CD-ROM)} +\end{devicelist} + +\noindent +Partitions are handled the same way as for the first interface (see +major number 3). + +\begin{devicelist} \major{91}{}{char }{CAN-Bus controller} \minor{0}{/dev/can0}{First CAN-Bus controller} \minor{1}{/dev/can1}{Second CAN-Bus controller} @@ -1791,6 +1801,16 @@ major number 3). \end{devicelist} \begin{devicelist} +\major{ }{}{block}{Ninth IDE hard disk/CD-ROM interface} + \minor{0}{/dev/hds}{Master: whole disk (or CD-ROM)} + \minor{64}{/dev/hdt}{Slave: whole disk (or CD-ROM)} +\end{devicelist} + +\noindent +Partitions are handled the same way as for the first interface (see +major number 3). + +\begin{devicelist} \major{92}{}{char }{Reserved for ith Kommunikationstechnik MIC ISDN card} \end{devicelist} diff --git a/Documentation/devices.txt b/Documentation/devices.txt index 92b2d621d..9f911d1fc 100644 --- a/Documentation/devices.txt +++ b/Documentation/devices.txt @@ -1241,11 +1241,25 @@ Your cooperation is appreciated. 30 = /dev/mtd15 16th MTD (rw) 31 = /dev/mtdr15 16th MTD (ro) + block Eighth IDE hard disk/CD-ROM interface + 0 = /dev/hdq Master: whole disk (or CD-ROM) + 64 = /dev/hdr Slave: whole disk (or CD-ROM) + + Partitions are handled the same way as for the first + interface (see major number 3). + 91 char CAN-Bus devices 0 = /dev/can0 First CAN-Bus controller 1 = /dev/can1 Second CAN-Bus controller ... + block Ninth IDE hard disk/CD-ROM interface + 0 = /dev/hds Master: whole disk (or CD-ROM) + 64 = /dev/hdt Slave: whole disk (or CD-ROM) + + Partitions are handled the same way as for the first + interface (see major number 3). + 92 char Reserved for ith Kommunikationstechnik MIC ISDN card 93 char IBM Smart Capture Card frame grabber diff --git a/Documentation/fb/00-INDEX b/Documentation/fb/00-INDEX index 4140afb88..32b2e760e 100644 --- a/Documentation/fb/00-INDEX +++ b/Documentation/fb/00-INDEX @@ -1,8 +1,7 @@ Index of files in Documentation/fb. If you think something about frame buffer devices needs an entry here, needs correction or you've written one please mail me. - Geert Uytterhoeven - <Geert.Uytterhoeven@cs.kuleuven.ac.be> + Geert Uytterhoeven <geert@linux-m68k.org> 00-INDEX - this file diff --git a/Documentation/fb/clgenfb.txt b/Documentation/fb/clgenfb.txt new file mode 100644 index 000000000..aad85d9a9 --- /dev/null +++ b/Documentation/fb/clgenfb.txt @@ -0,0 +1,92 @@ + + Framebuffer driver for Cirrus Logic chipsets + Copyright 1999 Jeff Garzik <jgarzik@pobox.com> + + + +{ just a little something to get people going; contributors welcome! } + + + +Chip families supported: + SD64 + Piccolo + Picasso + Spectrum + Alpine (GD-543x/4x) + Picasso4 (GD-5446) + GD-5480 + Laguna (GD-546x) + +Bus's supported: + PCI + Zorro + +Architectures supported: + i386 + Alpha + PPC (Motorola Powerstack) + m68k (Amiga) + + + +Default video modes +------------------- +At the moment, there are two kernel command line arguments supported: + +mode:640x480 + or +mode:1024x768 + +Full support for startup video modes (modedb) will be integrated soon. + + + +Version 1.9.4.4 +--------------- +* Preliminary Laguna support +* Overhaul color register routines. Shifts are now based on offset + values in var.cmap, so as long as those are correctly set for PReP + things should work (knock on wood). +* Associated with the above, console colors are now obtained from a LUT + called 'palette' instead of from the VGA registers. This code was + modeled after that in atyfb and matroxfb. +* Code cleanup, add comments. +* Overhaul SR07 handling. +* Bug fixes. + + +Version 1.9.4.3 +--------------- +* Correctly set default startup video mode. +* Do not override ram size setting. Define + CLGEN_USE_HARDCODED_RAM_SETTINGS if you _do_ want to override the RAM + setting. +* Compile fixes related to new 2.3.x IORESOURCE_IO[PORT] symbol changes. +* Use new 2.3.x resource allocation. +* Some code cleanup. + + +Version 1.9.4.2 +--------------- +* Casting fixes. +* Assertions no longer cause an oops on purpose. +* Bug fixes. + + +Version 1.9.4.1 +--------------- +* Add compatibility support. Now requires a 2.1.x, 2.2.x or 2.3.x kernel. + + +Version 1.9.4 +------------- +* Several enhancements, smaller memory footprint, a few bugfixes. +* Requires kernel 2.3.14-pre1 or later. + + +Version 1.9.3 +------------- +* Bundled with kernel 2.3.14-pre1 or later. + + diff --git a/Documentation/fb/framebuffer.txt b/Documentation/fb/framebuffer.txt index 644a007a5..c268d025a 100644 --- a/Documentation/fb/framebuffer.txt +++ b/Documentation/fb/framebuffer.txt @@ -1,7 +1,7 @@ The Frame Buffer Device ----------------------- -Maintained by Geert Uytterhoeven (Geert.Uytterhoeven@cs.kuleuven.ac.be) +Maintained by Geert Uytterhoeven <geert@linux-m68k.org> Last revised: November 7, 1998 diff --git a/Documentation/fb/internals.txt b/Documentation/fb/internals.txt index 7a6b9e99c..a73d721d7 100644 --- a/Documentation/fb/internals.txt +++ b/Documentation/fb/internals.txt @@ -2,7 +2,7 @@ This is a first start for some documentation about frame buffer device internals. -Geert Uytterhoeven <Geert.Uytterhoeven@cs.kuleuven.ac.be>, 21 July 1998 +Geert Uytterhoeven <geert@linux-m68k.org>, 21 July 1998 -------------------------------------------------------------------------------- diff --git a/Documentation/fb/modedb.txt b/Documentation/fb/modedb.txt new file mode 100644 index 000000000..01fd784a2 --- /dev/null +++ b/Documentation/fb/modedb.txt @@ -0,0 +1,48 @@ + + + modedb default video mode support + + +Currently all frame buffer device drivers have their own video mode databases, +which is a mess and a waste of resources. The main idea of modedb is to have + + - one routine to probe for video modes, which can be used by all frame buffer + devices + - one generic video mode database with a fair amount of standard videomodes + (taken from XFree86) + - the possibility to supply your own mode database for graphics hardware that + needs non-standard modes, like amifb and Mac frame buffer drivers (which + use macmodes.c) + +When a frame buffer device receives a video= option it doesn't know, it should +consider that to be a video mode option. If no frame buffer device is specified +in a video= option, fbmem considers that to be a global video mode option. + +Valid mode specifiers (mode_option argument): + + <xres>x<yres>[-<bpp>][@<refresh>] + <name>[-<bpp>][@<refresh>] + +with <xres>, <yres>, <bpp> and <refresh> decimal numbers and <name> a string. +Things between square brackets are optional. + +To find a suitable video mode, you just call + +int __init fb_find_mode(struct fb_var_screeninfo *var, + struct fb_info *info, const char *mode_option, + const struct fb_videomode *db, unsigned int dbsize, + const struct fb_videomode *default_mode, + unsigned int default_bpp) + +with db/dbsize your non-standard video mode database, or NULL to use the +standard video mode database. + +fb_find_mode() first tries the specified video mode (or any mode that matches, +e.g. there can be multiple 640x480 modes, each of them is tried). If that +fails, the default mode is tried. If that fails, it walks over all modes. + +BTW, only a few drivers use this at the moment. Others are to follow +(feel free to send patches). + + + diff --git a/Documentation/filesystems/00-INDEX b/Documentation/filesystems/00-INDEX index 4e3617e5a..b481c8a67 100644 --- a/Documentation/filesystems/00-INDEX +++ b/Documentation/filesystems/00-INDEX @@ -22,6 +22,8 @@ smbfs.txt - info on using filesystems with the SMB protocol (Windows 3.11 and NT) sysv-fs.txt - info on the SystemV/Coherent filesystem. +udf.txt + - info and mount options for the UDF filesystem. ufs.txt - info on the ufs filesystem. umsdos.txt diff --git a/Documentation/proc.txt b/Documentation/filesystems/proc.txt index ef2246d02..d842f7ed6 100644 --- a/Documentation/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -886,27 +886,53 @@ swapctl 3.6 /proc/sys/dev - Device specific parameters -Currently there is only support for CDROM drives, and for those, there -is only one read only file containing information about the CD-ROM -drives attached to the system: +Currently there is only support for CDROM drives, but other drivers may +wish to register themselves in here in the future. The cdrom/ directory +contains several files that either control or supply information about +the CDROM subsystem. >cat /proc/sys/dev/cdrom/info -CD-ROM information - -drive name: sr0 hdc -drive speed: 0 6 -drive # of slots: 1 0 -Can close tray: 1 1 -Can open tray: 1 1 -Can lock tray: 1 1 -Can change speed: 1 1 -Can select disk: 0 1 -Can read multisession: 1 1 -Can read MCN: 1 1 -Reports media changed: 1 1 -Can play audio: 1 1 - -You see two drives, sr0 and hdc, and their lists of features. +CD-ROM information, Id: cdrom.c 3.04 1999/09/12 + +drive name: hdd hdc hdb hda +drive speed: 32 24 10 0 +drive # of slots: 1 1 1 1 +Can close tray: 1 1 1 1 +Can open tray: 1 1 1 1 +Can lock tray: 1 1 1 1 +Can change speed: 1 1 1 1 +Can select disk: 0 0 0 0 +Can read multisession: 1 1 1 1 +Can read MCN: 1 1 1 1 +Reports media changed: 1 1 1 1 +Can play audio: 1 1 1 1 +Can write CD-R: 0 1 0 0 +Can write CD-RW: 0 1 0 0 +Can read DVD: 0 0 0 1 +Can write DVD-R: 0 0 0 0 +Can write DVD-RAM: 0 0 0 0 + +You see four drives and their lists of features. These are all ATAPI +drives - SCSI drives will be numbered sr0, sr1, and so forth. + +The remaining files all set options in the driver. + +autoclose + Close the drive tray when the drive is accessed. + +autoeject + Eject the tray when the drive is umounted. + +check_media + Verify the media type when opening the device. This is generally + meant for audio CD's. + +debug + Print debugging messages. + +lock + Lock the tray when the drive is in use. + 3.7 /proc/sys/sunrpc - Remote procedure calls diff --git a/Documentation/filesystems/udf.txt b/Documentation/filesystems/udf.txt new file mode 100644 index 000000000..5db0ed332 --- /dev/null +++ b/Documentation/filesystems/udf.txt @@ -0,0 +1,57 @@ +* +* ./Documentation/filesystems/udf.txt +* +UDF Filesystem version 0.8.9 + +If you encounter problems with reading UDF discs using this driver, +please report them to linux_udf@hootie.lvld.hp.com, which is the +developer's list. + +Write support requires a block driver which supports writing. The current +scsi and ide cdrom drivers do not support writing. + +------------------------------------------------------------------------------- +The following mount options are supported: + + gid= Set the default group. + umask= Set the default umask. + uid= Set the default user. + unhide Show otherwise hidden files. + undelete Show deleted files in lists. + strict Set strict conformance (unused) + utf8 (unused) + iocharset (unused) + +The remaining are for debugging and disaster recovery: + + bs= Set the block size. (may not work unless 2048) + novrs Skip volume sequence recognition + +The following expect a offset from 0. + + session= Set the CDROM session (default= last session) + anchor= Override standard anchor location. (default= 256) + volume= Override the VolumeDesc location. (unused) + partition= Override the PartitionDesc location. (unused) + lastblock= Set the last block of the filesystem/ + +The following expect a offset from the partition root. + + fileset= Override the fileset block location. (unused) + rootdir= Override the root directory location. (unused) + WARNING: overriding the rootdir to a non-directory may + yield highly unpredictable results. +------------------------------------------------------------------------------- + + +For more information see: + http://www.trylinux.com/projects/udf/index.html + +For the latest version and toolset see: + http://www.csc.calpoly.edu/~bfennema/udf.html + +Documentation on UDF and ECMA 167 is available FREE from: + http://www.osta.org/ + http://www.ecma.ch/ + +Ben Fennema <bfennema@falcon.csc.calpoly.edu> diff --git a/Documentation/i386/zero-page.txt b/Documentation/i386/zero-page.txt index fd77bfdb8..792ff2791 100644 --- a/Documentation/i386/zero-page.txt +++ b/Documentation/i386/zero-page.txt @@ -30,6 +30,7 @@ Offset Type Description 0xb0 - 0x1df Free. Add more parameters here if you really need them. 0x1e0 unsigned long ALT_MEM_K, alternative mem check, in Kb +0x1e8 char number of entries in E820MAP (below) 0x1f1 char size of setup.S, number of sectors 0x1f2 unsigned short MOUNT_ROOT_RDONLY (if !=0) 0x1f4 unsigned short size of compressed kernel-part in the @@ -64,7 +65,7 @@ Offset Type Description 0x21c unsigned long INITRD_SIZE, size in bytes of ramdisk image 0x220 4 bytes (setup.S) 0x224 unsigned short setup.S heap end pointer -0x226 - 0x7ff setup.S code. +0x2d0 - 0x600 E820MAP 0x800 string, 2K max COMMAND_LINE, the kernel commandline as copied using CL_OFFSET. diff --git a/Documentation/ioctl-number.txt b/Documentation/ioctl-number.txt index ac2af6e3f..cc9e3704b 100644 --- a/Documentation/ioctl-number.txt +++ b/Documentation/ioctl-number.txt @@ -1,37 +1,41 @@ Ioctl Numbers -18 Feb 1998 -Michael Chastain +2 September 1999 +Michael Elizabeth Chastain <mec@shout.net> If you are adding new ioctl's to the kernel, you should use the _IO macros defined in <linux/ioctl.h>: _IO an ioctl with no parameters - _IOW an ioctl with write parameters (from user's point of view) - _IOR an ioctl with read parameters (from user's point of view) + _IOW an ioctl with write parameters (copy_from_user) + _IOR an ioctl with read parameters (copy_to_user) _IOWR an ioctl with both write and read parameters. -'Write' and 'read' are from the user's point of view. This is like the -system calls 'write' and 'read'. For example, a SET_FOO ioctl would be -_IOW, although the kernel would actually read data from user space; a -GET_FOO ioctl would be _IOR, although the kernel would actually write +'Write' and 'read' are from the user's point of view, just like the +system calls 'write' and 'read'. For example, a SET_FOO ioctl would +be _IOW, although the kernel would actually read data from user space; +a GET_FOO ioctl would be _IOR, although the kernel would actually write data to user space. The first argument to _IO, _IOW, _IOR, or _IOWR is an identifying letter -or number from the table below. If you are writing a driver for a new -device and need a letter, pick an unused letter. You can register the -letter by patching this file and submitting the patch to Linus Torvalds. -Or you can e-mail me at <mec@shout.net> and I'll register one for you. +or number from the table below. Because of the large number of drivers, +many drivers share a partial letter with other drivers. + +If you are writing a driver for a new device and need a letter, pick an +unused block with enough room for expansion: 32 to 256 ioctl commands. +You can register the block by patching this file and submitting the +patch to Linus Torvalds. Or you can e-mail me at <mec@shout.net> and +I'll register one for you. The second argument to _IO, _IOW, _IOR, or _IOWR is a sequence number to distinguish ioctls from each other. The third argument is the size of the structure going into the kernel or coming out of the kernel. -Some devices use their major number as the identifier; this is not -recommended. Some devices are even more irregular and don't follow -the convention at all. +Some devices use their major number as the identifier; this is OK, as +long as it is unique. Some devices are irregular and don't follow any +convention at all. -Following the convention is good because: +Following this convention is good because: (1) Keeping the ioctl's globally unique helps error checking: if a program calls an ioctl on the wrong device, it will get an @@ -44,89 +48,124 @@ Following the convention is good because: numbers are unique. (4) People looking for ioctls can grep for them more easily when - the convention is used to define the ioctl numbers. + this convention is used to define the ioctl numbers. (5) When following the convention, the driver code can use generic - code to call verify_area to validate parameters. + code to copy the parameters between user and kernel space. -This table lists ioctls visible from user land for Linux/i386. It is -current to Linux 2.1.15. +This table lists ioctls visible from user land for Linux/i386. It contains +most drivers up to 2.3.14, but I know I am missing some. Code Seq# Include File Comments ======================================================== -0x00 01-02 linux/fs.h conflict! -0x00 01-04 scsi/scsi_ioctl.h conflict! +0x00 00-1F linux/fs.h conflict! +0x00 00-1F scsi/scsi_ioctl.h conflict! +0x00 00-1F linux/fb.h conflict! +0x00 00-1F linux/wavefront.h conflict! 0x02 all linux/fd.h 0x03 all linux/hdreg.h 0x04 all linux/umsdos_fs.h 0x06 all linux/lp.h 0x09 all linux/md.h 0x12 all linux/fs.h -0x20 all linux/cm206.h + linux/blkpg.h +0x20 all drivers/cdrom/cm206.h 0x22 all scsi/sg.h -'A' all linux/apm_bios.h +'1' 00-1F <linux/timepps.h> PPS kit from Ulrich Windl + <ftp://ftp.de.kernel.org/pub/linux/daemons/ntp/PPS/> +'8' all SNP8023 advanced NIC card + <mailto:mcr@solidum.com> +'A' 00-1F linux/apm_bios.h +'B' C0-FF advanced bbus + <mailto:maassen@uni-freiburg.de> 'C' all linux/soundcard.h 'F' all linux/fb.h 'I' all linux/isdn.h +'J' 00-1F drivers/scsi/gdth_ioctl.h 'K' all linux/kd.h -'L' all linux/loop.h -'M' all linux/soundcard.h +'L' 00-1F linux/loop.h +'L' E0-FF linux/ppdd.h encrypted disk device driver + <http://linux01.gwdg.de/~alatham/ppdd.html> +'M' all linux/soundcard.h conflict! +'M' 00-1F linux/isicom.h conflict! 'P' all linux/soundcard.h 'Q' all linux/soundcard.h -'R' all linux/random.h -'S' 00-7F linux/cdrom.h -'S' 80-81 scsi/scsi_ioctl.h -'S' 82-FF scsi/scsi.h +'R' 00-1F linux/random.h +'S' all linux/cdrom.h conflict! +'S' 80-81 scsi/scsi_ioctl.h conflict! +'S' 82-FF scsi/scsi.h conflict! 'T' all linux/soundcard.h conflict! 'T' all asm-i386/ioctls.h conflict! +'U' all linux/drivers/usb/usb.h 'V' all linux/vt.h -'W' 00-1F linux/router.h conflict [Please reallocate] -'W' 00-1F linux/watchdog.h -'W' 20-27 linux/octal-relay.h in development -'W' 28-2F linux/iso16-relay.h in development +'W' 00-1F linux/watchdog.h conflict! +'W' 00-1F linux/wanrouter.h conflict! 'Y' all linux/cyclades.h -'a' all various, see http://lrcwww.epfl.ch/linux-atm/magic.html -'b' 00-FF bit3 vme host bridge in development: +'a' all ATM on linux + <http://lrcwww.epfl.ch/linux-atm/magic.html> +'b' 00-FF bit3 vme host bridge <mailto:natalia@nikhefk.nikhef.nl> -'c' all linux/comstats.h -'f' all linux/ext2_fs.h +'c' 00-7F linux/comstats.h conflict! +'c' 00-7F linux/coda.h conflict! +'d' 00-1F linux/devfs_fs.h conflict! +'d' 00-DF linux/video_decoder.h conflict! +'d' F0-FF linux/digi1.h +'e' all linux/digi1.h conflict! +'e' 00-1F linux/video_encoder.h conflict! +'e' 00-1F net/irda/irtty.h conflict! +'f' 00-1F linux/ext2_fs.h +'i' 00-3F linux/i2o.h 'j' 00-3F linux/joystick.h -'k' all asm-sparc/kbio.h, asm-sparc64/kbio.h -'l' 00-3F linux/tcfs_fs.h in development: +'k' all asm-sparc/kbio.h + asm-sparc64/kbio.h +'l' 00-3F linux/tcfs_fs.h transparent cryptographic file system <http://mikonos.dia.unisa.it/tcfs> 'm' all linux/mtio.h conflict! 'm' all linux/soundcard.h conflict! +'m' all linux/synclink.h conflict! +'m' 00-1F net/irda/irmod.h conflict! 'n' all linux/ncp_fs.h 'p' 00-3F linux/mc146818rtc.h 'p' 40-7F linux/nvram.h -'p' 80-9F user-space parport in development: - <tim@cyberelk.demon.co.uk> -'r' all linux/msdos_fs.h +'p' 80-9F user-space parport + <mailto:tim@cyberelk.demon.co.uk> +'q' 00-1F linux/videotext.h conflict! +'q' 80-FF Internet PhoneJACK, Internet LineJACK + <http://www.quicknet.net> +'r' 00-1F linux/msdos_fs.h 's' all linux/cdk.h 't' 00-7F linux/if_ppp.h 't' 80-8F linux/isdn_ppp.h -'u' all linux/smb_fs.h -'v' all linux/ext2_fs.h -'w' all CERN SCI driver in development -'z' 00-3F CAN bus card in development: +'u' 00-1F linux/smb_fs.h +'v' 00-1F linux/ext2_fs.h conflict! +'v' all linux/videodev.h conflict! +'w' all CERN SCI driver +'z' 00-3F CAN bus card <mailto:hdstich@connectu.ulm.circular.de> -'z' 40-7F CAN bas card in development: +'z' 40-7F CAN bus card <mailto:oe@port.de> -0x89 00-0F asm-i386/sockios.h -0x89 10-DF linux/sockios.h +0x80 00-1F linux/fb.h +0x89 00-06 asm-i386/sockios.h +0x89 0B-DF linux/sockios.h 0x89 E0-EF linux/sockios.h SIOCPROTOPRIVATE range 0x89 F0-FF linux/sockios.h SIOCDEVPRIVATE range 0x8B all linux/wireless.h -0x8C 00-3F WiNRADiO driver in development: +0x8C 00-3F WiNRADiO driver <http://www.proximity.com.au/~brian/winradio/> -0x90 00 linux/sbpcd.h +0x90 00 drivers/cdrom/sbpcd.h 0x93 60-7F linux/auto_fs.h -0x99 00-0F 537-Addinboard driver in development: - <mailto:b.kohl@ipn-b.comlink.apc.org> -0xA0 all Small Device Project in development: - <mailto:khollis@northwest.com> +0x99 00-0F 537-Addinboard driver + <mailto:buk@buks.ipn.de> +0xA0 all linux/sdp/sdp.h Industrial Device Project + <mailto:kenji@bitgate.com> +0xA3 00-1F Philips SAA7146 dirver in development: + <mailto:Andreas.Beckmann@hamburg.sc.philips.com> 0xA3 80-8F Port ACL in development: <mailto:tlewis@mindspring.com> -0xA3 90-9F DoubleTalk driver in development: - <mailto:jrv@vanzandt.mv.com> -0xAB 00-06 Network block device +0xA3 90-9F linux/dtlk.h +0xAB 00-1F linux/nbd.h +0xAC 00-1F linux/raw.h +0xAD 00 Netfilter device in development: + <mailto:rusty@rustcorp.com.au> +0xB0 all RATIO devices in development: + <mailto:vgo@ratio.de> diff --git a/Documentation/isapnp.txt b/Documentation/isapnp.txt new file mode 100644 index 000000000..4054ecf2f --- /dev/null +++ b/Documentation/isapnp.txt @@ -0,0 +1,148 @@ +ISA Plug & Play support by Jaroslav Kysela <perex@suse.cz> +========================================================= + +Interface /proc/isapnp +====================== + +Read commands: +-------------- + +No comment.. + +Write commands: +--------------- + +With the write interface you can simply activate or modify the configuration +for ISA Plug & Play devices. It is mainly useable for drivers which don't +use the ISA Plug & Play kernel support yet. + +card <idx> <vendor> - select PnP device by vendor identification +csn <CSN> - select PnP device by CSN +dev <idx> <logdev> - select logical device +auto - run autoconfigure +activate - activate logical device +deactivate - deactivate logical device +port <idx> <value> - set port 0-7 to value +irq <idx> <value> - set IRQ 0-1 to value +dma <idx> <value> - set DMA 0-1 to value +memory <idx> <value> - set memory 0-3 to value +poke <reg> <value> - poke configuration byte to selected register +pokew <reg> <value> - poke configuration word to selected register +poked <reg> <value> - poke configuration dword to selected register + +Explanation: + - variable <idx> begins with zero + - variable <CSN> begins with one + - <vendor> is in form 'PNP0000' + - <logdev> is in form 'PNP0000' + +Example: + +cat > /proc/isapnp <<EOF +card 0 CSC7537 +dev 0 CSC0000 +port 0 0x534 +port 1 0x388 +port 2 0x220 +irq 0 5 +dma 0 1 +dma 1 3 +poke 0x70 9 +activate +logdev 0 CSC0001 +port 0 0x240 +activate +EOF + +Information for developers +========================== + +Finding appropriate device +-------------------------- + +extern struct pci_bus *isapnp_find_card(unsigned short vendor, + unsigned short device, + struct pci_bus *from); + +The above function finds a ISA PnP card. For the vendor device should +be used ISAPNP_VENDOR(a,b,c) where a,b,c are characters or integers. +For the device number should be used ISAPNP_DEVICE(x) macro where x is +integer value. Both vendor and device numbers can be get from contents +of the /proc/isapnp file. + +extern struct pci_dev *isapnp_find_dev(struct pci_bus *card, + unsigned short vendor, + unsigned short function, + struct pci_dev *from); + +The above function finds the ISA PnP device. If card is NULL, then +the global search mode is used (all devices are used for the searching). +Otherwise only devices which belongs to the specified card are verified. +For the function number can be used ISAPNP_FUNCTION(x) macro which works +similarly as the ISAPNP_DEVICE(x) macro. + +ISA PnP configuration +===================== + +There are two ways how can be ISA PnP interface used. + +First way is lowlevel +--------------------- + +All ISA PNP configuration registers are accessible via lowlevel +isapnp_(read|write)_(byte|word|dword) functions. + +The function isapnp_cfg_begin() must be called before any lowlevel function. +The function isapnp_cfg_end() must be always called after configuration +otherwise the access to the ISA PnP configuration functions will be blocked. + +Second way is auto-configuration +-------------------------------- + +These two functions gives to the driver the real power of the ISA PnP +feature. First function dev->prepare() only initialize the resource +members in the device structure. This structure contains all resources +set to auto configuration values after the initialization. The driver for +ISA PnP device may modify (or not) some resources to skip auto configuration +for the given resource. + +The function isapnp_configure does: + - resources which have the auto configuration value are configured + - the auto configuration is created using ISA PnP resource map + - the function writes configuration to ISA PnP configuration registers + - the function returns to the caller actual used resources + +Example (game port initialization) +================================== + +/*** initialization ***/ + + struct pci_dev *dev; + + /* find the first game port, use standard PnP IDs */ + dev = isapnp_find_dev(NULL, + ISAPNP_VENDOR('P','N','P'), + ISAPNP_FUNCTION(0xb02f), + NULL); + if (!dev) + return -ENODEV; + if (dev->prepare(dev)<0) + return -EAGAIN; + if (!(dev->resource[0].flags & IORESOURCE_IO)) + return -ENODEV; + if (!dev->ro) { + /* override resource */ + if (user_port != USER_PORT_AUTO_VALUE) + isapnp_resource_change(&dev->resource[0], user_port, 1); + } + if (dev->activate(dev)<0) { + printk("isapnp configure failed (out of resources?)\n"); + return -ENOMEM; + } + user_port = dev->resource[0].start; /* get real port */ + +/*** deactivation ***/ + + /* to deactivate use: */ + if (dev) + dev->deactivate(dev); diff --git a/Documentation/isdn/CREDITS b/Documentation/isdn/CREDITS index 9faad9c60..31da77e3b 100644 --- a/Documentation/isdn/CREDITS +++ b/Documentation/isdn/CREDITS @@ -24,7 +24,7 @@ Michael 'Ghandi' Herold (michael@abadonna.franken.de) Michael Hipp (Michael.Hipp@student.uni-tuebingen.de) For his Sync-PPP-code. -Karsten Keil (isdn4@temic-ech.spacenet.de) +Karsten Keil (keil@isdn4linux.de) For adding 1TR6-support to the Teles-driver. For the HiSax-driver. diff --git a/Documentation/isdn/HiSax.cert b/Documentation/isdn/HiSax.cert index b1f8aaa53..de440068f 100644 --- a/Documentation/isdn/HiSax.cert +++ b/Documentation/isdn/HiSax.cert @@ -14,7 +14,8 @@ First: However, if you wish to modify the HiSax sources, please note the following: -HiSax has passed the ITU approval test suite with ELSA Quickstep ISDN cards. +HiSax has passed the ITU approval test suite with ELSA Quickstep ISDN cards +and Eicon Technology Diva 2.01 PCI card. The certification is only valid for the combination of the tested software version and the tested hardware. Any changes to the HiSax source code may therefore affect the certification. @@ -48,13 +49,14 @@ drivers/isdn/hisax/l3dss1.c drivers/isdn/hisax/l3_1tr6.c drivers/isdn/hisax/cert.c drivers/isdn/hisax/elsa.c +drivers/isdn/hisax/diva.c Please send any changes, bugfixes and patches to me rather than implementing them directly into the HiSax sources. This does not reduce your rights granted by the GNU General Public License. If you wish to change the sources, go ahead; but note that then the -certification is invalid even if you use ELSA Quickstep cards. +certification is invalid even if you use one of the approved cards. Here are the certification registration numbers for ELSA Quickstep cards: German D133361J CETECOM ICT Services GmbH 0682 @@ -68,9 +70,9 @@ keil@isdn4linux.de Version: 2.6.3i Charset: noconv -iQCVAwUBNj5OKDpxHvX/mS9tAQFHuQP/WeImlqCcDZ2d132yAvRBWFULlJoSf1P/ -c1lVTeaWvsSaY5Cu9hrKhXXhPzeEaitUbcUBPXdpzFWCA5CE902lnz7AhgRC+HF1 -0qiKgkZZyc/5HKasFymR1+IWSLw30GesP3Di/ZMR3NJi8SlY9PIjx7hnEMunGSRO -1ufPvfWWuu8= -=nGJk +iQCVAwUBN6xoKTpxHvX/mS9tAQF4DAP/efRWym6jvNOND1O9eaEFdP5fd2xKB3XD +Ifh6Iv0DvARcIuxXtEjT+z3FjjQk35eo/wX4C4tpRhYQYdgCxl+iv+5DzhVDpB95 +3QS9E5m0E1eIK3t8XiQTRgb+1JPCMYUThCrakYsX25o3ndGKyDipsCTfkyR38XwC +bUyTfcOYKAk= +=VKyL -----END PGP SIGNATURE----- diff --git a/Documentation/isdn/INTERFACE b/Documentation/isdn/INTERFACE index 213136b55..c2a5494b1 100644 --- a/Documentation/isdn/INTERFACE +++ b/Documentation/isdn/INTERFACE @@ -1,4 +1,4 @@ -$Id: INTERFACE,v 1.11 1999/03/02 12:14:51 armin Exp $ +$Id: INTERFACE,v 1.15 1999/08/25 20:02:13 werner Exp $ Description of the Interface between Linklevel and Hardwarelevel of isdn4linux: @@ -216,7 +216,7 @@ Description of the Interface between Linklevel and Hardwarelevel Until now, the following commands are defined: -***CHANGEI1.34: The parameter "num" has been replaced by a union "para" containing +***CHANGEI1.34: The parameter "num" has been replaced by a union "parm" containing the old "num" and a new setup_type struct used for ISDN_CMD_DIAL and ISDN_STAT_ICALL callback. @@ -235,7 +235,7 @@ Description of the Interface between Linklevel and Hardwarelevel driver = driver-Id. command = ISDN_CMD_IOCTL arg = Original ioctl-cmd - IIOCDRVCTL - para.num = first bytes filled with (unsigned long)arg + parm.num = first bytes filled with (unsigned long)arg Returnvalue: Depending on driver. @@ -251,10 +251,10 @@ Description of the Interface between Linklevel and Hardwarelevel command = ISDN_CMD_DIAL arg = channel-number locally to the driver. (starting with 0) - para.setup.phone = An ASCII-String containing the number to dial. - para.setup.eazmsn = An ASCII-Sting containing the own EAZ or MSN. - para.setup.si1 = The Service-Indicator. - para.setup.si2 = Additional Service-Indicator. + parm.setup.phone = An ASCII-String containing the number to dial. + parm.setup.eazmsn = An ASCII-Sting containing the own EAZ or MSN. + parm.setup.si1 = The Service-Indicator. + parm.setup.si2 = Additional Service-Indicator. If the Line has been designed as SPV (a special german feature, meaning semi-leased-line) the phone has to @@ -272,7 +272,7 @@ Description of the Interface between Linklevel and Hardwarelevel driver = driver-Id. command = ISDN_CMD_ACCEPTD arg = channel-number locally to the driver. (starting with 0) - para = unused. + parm = unused. ISDN_CMD_ACCEPTB: @@ -283,7 +283,7 @@ Description of the Interface between Linklevel and Hardwarelevel driver = driver-Id. command = ISDN_CMD_ACCEPTB arg = channel-number locally to the driver. (starting with 0) - para = unused. + parm = unused. ISDN_CMD_HANGUP: @@ -295,7 +295,7 @@ Description of the Interface between Linklevel and Hardwarelevel driver = driver-Id. command = ISDN_CMD_HANGUP arg = channel-number locally to the driver. (starting with 0) - para = unused. + parm = unused. ISDN_CMD_CLREAZ: @@ -306,7 +306,7 @@ Description of the Interface between Linklevel and Hardwarelevel driver = driver-Id. command = ISDN_CMD_CLREAZ arg = channel-number locally to the driver. (starting with 0) - para = unused. + parm = unused. ISDN_CMD_SETEAZ: @@ -317,7 +317,7 @@ Description of the Interface between Linklevel and Hardwarelevel driver = driver-Id. command = ISDN_CMD_SETEAZ arg = channel-number locally to the driver. (starting with 0) - para.num = ASCII-String, containing the desired EAZ's/MSN's + parm.num = ASCII-String, containing the desired EAZ's/MSN's (comma-separated). If an empty String is given, the HL-driver should respond to ALL incoming calls, regardless of the destination-address. @@ -332,7 +332,7 @@ Description of the Interface between Linklevel and Hardwarelevel driver = driver-Id. command = ISDN_CMD_GETEAZ arg = channel-number locally to the driver. (starting with 0) - para.num = ASCII-String, containing the current EAZ's/MSN's + parm.num = ASCII-String, containing the current EAZ's/MSN's ISDN_CMD_SETSIL: (currently unused) @@ -343,7 +343,7 @@ Description of the Interface between Linklevel and Hardwarelevel driver = driver-Id. command = ISDN_CMD_SETSIL arg = channel-number locally to the driver. (starting with 0) - para.num = ASCII-String, containing the desired Service-Indicators. + parm.num = ASCII-String, containing the desired Service-Indicators. ISDN_CMD_GETSIL: (currently unused) @@ -354,7 +354,7 @@ Description of the Interface between Linklevel and Hardwarelevel driver = driver-Id. command = ISDN_CMD_SETSIL arg = channel-number locally to the driver. (starting with 0) - para.num = ASCII-String, containing the current Service-Indicators. + parm.num = ASCII-String, containing the current Service-Indicators. ISDN_CMD_SETL2: @@ -369,7 +369,7 @@ Description of the Interface between Linklevel and Hardwarelevel arg = channel-number locally to the driver. (starting with 0) logical or'ed with (protocol-Id << 8) protocol-Id is one of the constants ISDN_PROTO_L2... - para = unused. + parm = unused. ISDN_CMD_GETL2: (currently unused) @@ -380,7 +380,7 @@ Description of the Interface between Linklevel and Hardwarelevel driver = driver-Id. command = ISDN_CMD_GETL2 arg = channel-number locally to the driver. (starting with 0) - para = unused. + parm = unused. Returnvalue: current protocol-Id (one of the constants ISDN_L2_PROTO) @@ -397,7 +397,7 @@ Description of the Interface between Linklevel and Hardwarelevel arg = channel-number locally to the driver. (starting with 0) logical or'ed with (protocol-Id << 8) protocol-Id is one of the constants ISDN_PROTO_L3... - para = unused. + parm.fax = Pointer to T30_s fax struct. (fax usage only) ISDN_CMD_GETL2: (currently unused) @@ -408,7 +408,7 @@ Description of the Interface between Linklevel and Hardwarelevel driver = driver-Id. command = ISDN_CMD_GETL3 arg = channel-number locally to the driver. (starting with 0) - para = unused. + parm = unused. Returnvalue: current protocol-Id (one of the constants ISDN_L3_PROTO) @@ -422,7 +422,7 @@ Description of the Interface between Linklevel and Hardwarelevel driver = driver-Id. command = ISDN_CMD_LOCK arg = unused. - para = unused. + parm = unused. ISDN_CMD_UNLOCK: @@ -434,7 +434,70 @@ Description of the Interface between Linklevel and Hardwarelevel driver = driver-Id. command = ISDN_CMD_UNLOCK arg = unused. - para = unused. + parm = unused. + + ISDN_CMD_PROCEED: + + With this command, the HL-driver is told to proceed with a incoming call. + + Parameter: + driver = driver-Id. + command = ISDN_CMD_PROCEED + arg = channel-number locally to the driver. (starting with 0) + setup.eazmsn= empty string or string send as uus1 in DSS1 with + PROCEED message + + ISDN_CMD_ALERT: + + With this command, the HL-driver is told to alert a proceeding call. + + Parameter: + driver = driver-Id. + command = ISDN_CMD_ALERT + arg = channel-number locally to the driver. (starting with 0) + setup.eazmsn= empty string or string send as uus1 in DSS1 with + ALERT message + + ISDN_CMD_REDIR: + + With this command, the HL-driver is told to redirect a call in proceeding + or alerting state. + + Parameter: + driver = driver-Id. + command = ISDN_CMD_REDIR + arg = channel-number locally to the driver. (starting with 0) + setup.eazmsn= empty string or string send as uus1 in DSS1 protocol + setup.screen= screening indicator + setup.phone = redirected to party number + + ISDN_CMD_PROT_IO: + + With this call, the LL-driver invokes protocol specific features through + the LL. + The call is not implicitely bound to a connection. + + Parameter: + driver = driver-Id + command = ISDN_CMD_PROT_IO + arg = The lower 8 Bits define the adressed protocol as defined + in ISDN_PTYPE..., the upper bits are used to differenciate + the protocol specific CMD. + + para = protocol and function specific. See isdnif.h for detail. + + + ISDN_CMD_FAXCMD: + + With this command the HL-driver receives a fax sub-command. + For details refer to INTERFACE.fax + + Parameter: + driver = driver-Id. + command = ISDN_CMD_FAXCMD + arg = channel-number locally to the driver. (starting with 0) + parm = unused. + 3. Description of the events to be signaled by the HL-driver to the LL. @@ -456,11 +519,14 @@ Description of the Interface between Linklevel and Hardwarelevel driver = driver-Id command = ISDN_STAT_STAVAIL arg = length of available data. - para = unused. + parm = unused. ISDN_STAT_ICALL: + ISDN_STAT_ICALLW: With this call, the HL-driver signals an incoming call to the LL. + If ICALLW is signalled the incoming call is a waiting call without + a available B-chan. Parameter: driver = driver-Id @@ -478,15 +544,22 @@ Description of the Interface between Linklevel and Hardwarelevel 1 = At least one device matching this call (RING on ttyI). HL-driver may send ALERTING on the D-channel in this case. 2 = Call will be rejected. - 3 = Incomplete number. - The CalledNumber would match, if more digits are appended. - This feature is needed for Number-Blocks assigned to - a line. In this case, the LL driver should assemble the - CalledNumber by handling keypad protocol and try again - later with a longer CalledNumber. - HL drivers serving ordinary lines should interpret this - return code like 0 (nothing matches). + 3 = Incoming called party number is currently incomplete. + Additional digits are required. + Used for signalling with PtP connections. + 4 = Call will be held in a proceeding state + (HL driver sends PROCEEDING) + Used when a user space prog needs time to interpret a call + para.setup.eazmsn may be filled with an uus1 message of + 30 octets maximum. Empty string if no uus. + 5 = Call will be actively deflected to another party + Only available in DSS1/EURO protocol + para.setup.phone must be set to destination party number + para.setup.eazmsn may be filled with an uus1 message of + 30 octets maximum. Empty string if no uus. -1 = An error happened. (Invalid parameters for example.) + The keypad support now is included in the dial command. + ISDN_STAT_RUN: @@ -497,7 +570,7 @@ Description of the Interface between Linklevel and Hardwarelevel driver = driver-Id command = ISDN_STAT_RUN arg = unused. - para = unused. + parm = unused. ISDN_STAT_STOP: @@ -508,7 +581,7 @@ Description of the Interface between Linklevel and Hardwarelevel driver = driver-Id command = ISDN_STAT_STOP arg = unused. - para = unused. + parm = unused. ISDN_STAT_DCONN: @@ -519,7 +592,7 @@ Description of the Interface between Linklevel and Hardwarelevel driver = driver-Id command = ISDN_STAT_DCONN arg = channel-number, locally to the driver. (starting with 0) - para = unused. + parm = unused. ISDN_STAT_BCONN: @@ -534,7 +607,7 @@ Description of the Interface between Linklevel and Hardwarelevel driver = driver-Id command = ISDN_STAT_BCONN arg = channel-number, locally to the driver. (starting with 0) - para.num = ASCII-String, containing type of connection (for analog + parm.num = ASCII-String, containing type of connection (for analog modem only). This will be appended to the CONNECT message e.g. 14400/V.32bis @@ -549,7 +622,7 @@ Description of the Interface between Linklevel and Hardwarelevel driver = driver-Id command = ISDN_STAT_DHUP arg = channel-number, locally to the driver. (starting with 0) - para = unused. + parm = unused. ISDN_STAT_BHUP: @@ -564,7 +637,7 @@ Description of the Interface between Linklevel and Hardwarelevel driver = driver-Id command = ISDN_STAT_BHUP arg = channel-number, locally to the driver. (starting with 0) - para = unused. + parm = unused. ISDN_STAT_CINF: @@ -575,7 +648,7 @@ Description of the Interface between Linklevel and Hardwarelevel driver = driver-Id command = ISDN_STAT_CINF arg = channel-number, locally to the driver. (starting with 0) - para.num = ASCII string containing charge-units (digits only). + parm.num = ASCII string containing charge-units (digits only). ISDN_STAT_LOAD: (currently unused) @@ -588,7 +661,7 @@ Description of the Interface between Linklevel and Hardwarelevel driver = driver-Id command = ISDN_STAT_UNLOAD arg = unused. - para = unused. + parm = unused. ISDN_STAT_BSENT: @@ -600,7 +673,7 @@ Description of the Interface between Linklevel and Hardwarelevel driver = driver-Id command = ISDN_STAT_BSENT arg = channel-number, locally to the driver. (starting with 0) - para.length = ***CHANGEI.1.21: New field. + parm.length = ***CHANGEI.1.21: New field. the driver has to set this to the original length of the skb at the time of receiving it from the linklevel. @@ -613,21 +686,21 @@ Description of the Interface between Linklevel and Hardwarelevel driver = driver-Id command = ISDN_STAT_NODCH arg = channel-number, locally to the driver. (starting with 0) - para = unused. + parm = unused. - ISDN_STAT_ADDCH: (currently unused) + ISDN_STAT_ADDCH: - This call is planned for HL-drivers, which are unable to check card-type + This call is for HL-drivers, which are unable to check card-type or numbers of supported channels before they have loaded any firmware - using ioctl. Those HL-driver simply set the channel-parameter to zero - or a minimum channel-number when registering, and later if they know + using ioctl. Those HL-driver simply set the channel-parameter to a + minimum channel-number when registering, and later if they know the real amount, perform this call, allocating additional channels. Parameter: driver = driver-Id command = ISDN_STAT_ADDCH - arg = to be defined. - para = to be defined. + arg = number of channels to be added. + parm = unused. ISDN_STAT_CAUSE: @@ -640,7 +713,49 @@ Description of the Interface between Linklevel and Hardwarelevel driver = driver-Id command = ISDN_STAT_NODCH arg = channel-number, locally to the driver. (starting with 0) - para.num = ASCII string containing CAUSE-message. + parm.num = ASCII string containing CAUSE-message. + + ISDN_STAT_DISPLAY: + + With this call, the HL-driver delivers DISPLAY-messages to the LL. + Currently the LL does not use this messages. + + Parameter: + driver = driver-Id + command = ISDN_STAT_DISPLAY + arg = channel-number, locally to the driver. (starting with 0) + para.display= string containing DISPLAY-message. + + ISDN_STAT_PROT: + + With this call, the HL-driver delivers protocol specific infos to the LL. + The call is not implicitely bound to a connection. + + Parameter: + driver = driver-Id + command = ISDN_STAT_PROT + arg = The lower 8 Bits define the adressed protocol as defined + in ISDN_PTYPE..., the upper bits are used to differenciate + the protocol specific STAT. + + para = protocol and function specific. See isdnif.h for detail. + + ISDN_STAT_DISCH: + + With this call, the HL-driver signals the LL to disable or enable the + use of supplied channel and driver. + The call may be used to reduce the available number of B-channels after + loading the driver. The LL has to ignore a disabled channel when searching + for free channels. The HL driver itself never delivers STAT callbacks for + disabled channels. + The LL returns a nonzero code if the operation was not successfull or the + selected channel is actually regarded as busy. + + Parameter: + driver = driver-Id + command = ISDN_STAT_DISCH + arg = channel-number, locally to the driver. (starting with 0) + parm.num[0] = 0 if channel shall be disabled, else enabled. ISDN_STAT_L1ERR: @@ -653,5 +768,16 @@ Description of the Interface between Linklevel and Hardwarelevel driver = driver-Id command = ISDN_STAT_L1ERR arg = channel-number, locally to the driver. (starting with 0) - para.errcode= ISDN_STAT_L1ERR_SEND: Packet lost while sending. + parm.errcode= ISDN_STAT_L1ERR_SEND: Packet lost while sending. ISDN_STAT_L1ERR_RECV: Packet lost while receiving. + ISDN_STAT_FAXIND: + + With this call the HL-driver signals a fax sub-command to the LL. + For details refer to INTERFACE.fax + + Parameter: + driver = driver-Id. + command = ISDN_STAT_FAXIND + arg = channel-number, locally to the driver. (starting with 0) + parm = unused. + diff --git a/Documentation/isdn/INTERFACE.fax b/Documentation/isdn/INTERFACE.fax new file mode 100644 index 000000000..2c9659f0d --- /dev/null +++ b/Documentation/isdn/INTERFACE.fax @@ -0,0 +1,163 @@ +$Id: INTERFACE.fax,v 1.1 1999/08/11 20:30:28 armin Exp $ + + +Description of the fax-subinterface between linklevel and hardwarelevel of + isdn4linux. + + The communication between linklevel (LL) and harwarelevel (HL) for fax + is based on the struct T30_s (defined in isdnif.h). + This struct is allocated in the LL. + In order to use fax, the LL provides the pointer to this struct with the + command ISDN_CMD_SETL3 (parm.fax). This pointer expires in case of hangup + and when a new channel to a new connection is assigned. + + +Data handling: + In send-mode the HL-driver has to handle the <DLE> codes and the bit-order + conversion by itself. + In receive-mode the LL-driver takes care of the bit-order conversion + (specified by +FBOR) + +Structure T30_s description: + + This structure stores the values (set by AT-commands), the remote- + capability-values and the command-codes between LL and HL. + + If the HL-driver receives ISDN_CMD_FAXCMD, all needed information + is in this struct set by the LL. + To signal information to the LL, the HL-driver has to set the + the parameters and use ISDN_STAT_FAXIND. + (Please refer to INTERFACE) + +Structure T30_s: + + All members are 8-bit unsigned (__u8) + + - resolution + - rate + - width + - length + - compression + - ecm + - binary + - scantime + - id[] + Local faxmachine's parameters, set by +FDIS, +FDCS, +FLID, ... + + - r_resolution + - r_rate + - r_width + - r_length + - r_compression + - r_ecm + - r_binary + - r_scantime + - r_id[] + Remote faxmachine's parameters. To be set by HL-driver. + + - phase + Defines the actual state of fax connection. Set by HL or LL + depending on progress and type of connection. + If the phase changes because of an AT command, the LL driver + changes this value. Otherwise the HL-driver takes care of it, but + only neccessary on call establishment (from IDLE to PHASE_A). + (one of the constants ISDN_FAX_PHASE_[IDLE,A,B,C,D,E]) + + - direction + Defines outgoing/send or incoming/receive connection. + (ISDN_TTY_FAX_CONN_[IN,OUT]) + + - code + Commands from LL to HL; possible constants : + ISDN_TTY_FAX_DR signals +FDR command to HL + + ISDN_TTY_FAX_DT signals +FDT command to HL + + ISDN_TTY_FAX_ET signals +FET command to HL + + + Other than that the "code" is set with the hangup-code value at + the end of connection for the +FHNG message. + + - r_code + Commands from HL to LL; possible constants : + ISDN_TTY_FAX_CFR output of +FCFR message. + + ISDN_TTY_FAX_RID output of remote ID set in r_id[] + (+FCSI/+FTSI on send/receive) + + ISDN_TTY_FAX_DCS output of +FDCS and CONNECT message, + switching to phase C. + + ISDN_TTY_FAX_ET signals end of data, + switching to phase D. + + ISDN_TTY_FAX_FCON signals the established, outgoing connection, + switching to phase B. + + ISDN_TTY_FAX_FCON_I signals the established, incoming connection, + switching to phase B. + + ISDN_TTY_FAX_DIS output of +FDIS message and values. + + ISDN_TTY_FAX_SENT signals that all data has been sent + and <DLE><ETX> is acknowledged, + OK message will be sent. + + ISDN_TTY_FAX_PTS signals a msg-confirmation (page sent successful), + depending on fet value: + 0: output OK message (more pages follow) + 1: switching to phase B (next document) + + ISDN_TTY_FAX_TRAIN_OK output of +FDCS and OK message (for receive mode). + + ISDN_TTY_FAX_EOP signals end of data in receive mode, + switching to phase D. + + ISDN_TTY_FAX_HNG output of the +FHNG and value set by code and + OK message, switching to phase E. + + + - badlin + Value of +FBADLIN + + - badmul + Value of +FBADMUL + + - bor + Value of +FBOR + + - fet + Value of +FET command in send-mode. + Set by HL in receive-mode for +FET message. + + - pollid[] + ID-string, set by +FCIG + + - cq + Value of +FCQ + + - cr + Value of +FCR + + - ctcrty + Value of +FCTCRTY + + - minsp + Value of +FMINSP + + - phcto + Value of +FPHCTO + + - rel + Value of +FREL + + - nbc + Value of +FNBC (0,1) + (+FNBC is not a known class 2 fax command, I added this to change the + automatic "best capabilities" connection in the eicon HL-driver) + + +Armin +mac@melware.de + diff --git a/Documentation/isdn/README b/Documentation/isdn/README index 7b17183e0..dcd14151e 100644 --- a/Documentation/isdn/README +++ b/Documentation/isdn/README @@ -149,6 +149,8 @@ README for the ISDN-subsystem AT&X0 BTX-mode and T.70-mode off (default) AT&X1 BTX-mode on. (S13.1=1, S13.5=0 S14=0, S16=7, S18=7, S19=0) AT&X2 T.70-mode on. (S13.1=1, S13.5=1, S14=0, S16=7, S18=7, S19=0) + AT+Rx Resume a suspended call with CallID x (x = 1,2,3...) + AT+Sx Suspend a call with CallID x (x = 1,2,3...) For voice-mode commands refer to README.audio @@ -215,6 +217,9 @@ README for the ISDN-subsystem an incoming call happened (RING) and the remote party hung up before any local ATA was given. + Bit 7: 0 = Don't show display messages from net + 1 = Show display messages from net + (S12 Bit 1 must be 0 too) 14 0 Layer-2 protocol: 0 = X75/LAPB with I-frames 1 = X75/LAPB with UI-frames @@ -225,8 +230,11 @@ README for the ISDN-subsystem 8 = V.110, 19200 baud 9 = V.110, 38400 baud 10 = Analog Modem (only if hardware supports this) - 15 0 Layer-3 protocol: (at the moment always 0) + 11 = Fax G3 (only if hardware supports this) + 15 0 Layer-3 protocol: 0 = transparent + 1 = transparent with audio features (e.g. DSP) + 2 = Fax G3 (S14 has to be set to 11) 16 250 Send-Packet-size/16 17 8 Window-size (not yet implemented) 18 4 Bit coded register, Service-Octet-1 to accept, @@ -255,6 +263,9 @@ README for the ISDN-subsystem Set on incoming call (during RING) to octet 3a of calling party number IE (Screening info) See section 4.5.10 of ITU Q.931 + 23 0 Bit coded register: + Bit 0: 0 = Add CPN to RING message off + 1 = Add CPN to RING message on Last but not least a (at the moment fairly primitive) device to request the line-status (/dev/isdninfo) is made available. diff --git a/Documentation/isdn/README.HiSax b/Documentation/isdn/README.HiSax index 9f48e71e6..7faff4a34 100644 --- a/Documentation/isdn/README.HiSax +++ b/Documentation/isdn/README.HiSax @@ -42,6 +42,7 @@ ELSA Quickstep 3000PCI ELSA PCMCIA ITK ix1-micro Rev.2 Eicon.Diehl Diva 2.0 ISA and PCI (S0 and U interface, no PRO version) +Eicon.Diehl Diva 2.01 ISA and PCI Eicon.Diehl Diva Piccola ASUSCOM NETWORK INC. ISDNLink 128K PC adapter (order code I-IN100-ST-D) Dynalink IS64PH (OEM version of ASUSCOM NETWORK INC. ISDNLink 128K adapter) @@ -54,6 +55,14 @@ USR Sportster internal TA (compatible Stollmann tina-pp V3) ith Kommunikationstechnik GmbH MIC 16 ISA card Traverse Technologie NETjet PCI S0 card Dr. Neuhaus Niccy PnP/PCI +Siemens I-Surf 1.0 +Siemens I-Surf 2.0 (with IPAC, try type 12 asuscom) +ACER P10 +HST Saphir +Berkom Telekom A4T +Scitel Quadro +Gazel ISDN cards +HFC-PCI based cards Note: PCF, PCF-Pro: up to now, only the ISDN part is supported PCC-8: not tested yet @@ -165,6 +174,14 @@ Card types: 27 AVM PnP (Fritz!PnP) irq, io (from isapnp setup) 27 AVM PCI (Fritz!PCI) no parameter 28 Sedlbauer Speed Fax+ irq, io (from isapnp setup) + 29 Siemens I-Surf 1.0 irq, io, memory (from isapnp setup) + 30 ACER P10 irq, io (from isapnp setup) + 31 HST Saphir irq, io + 32 Telekom A4T none + 33 Scitel Quadro subcontroller (4*S0, subctrl 1...4) + 34 Gazel ISDN cards (ISA) irq,io + 34 Gazel ISDN cards (PCI) none + 35 HFC 2BDS0 PCI none At the moment IRQ sharing is only possible with PCI cards. Please make sure @@ -255,12 +272,19 @@ type 22 Sedlbauer Speed Star (PCMCIA) pa=irq, pb=io (set with card manager) 24 Dr. Neuhaus Niccy PnP ONLY WORKS AS A MODULE ! 24 Dr. Neuhaus Niccy PCI no parameter - 25 Teles S0Box irq, io (of the used lpt port) - 26 AVM A1 PCMCIA (Fritz!) irq, io (set with card manager) + 25 Teles S0Box pa=irq, pb=io (of the used lpt port) + 26 AVM A1 PCMCIA (Fritz!) pa=irq, pb=io (set with card manager) 27 AVM PnP (Fritz!PnP) ONLY WORKS AS A MODULE ! 27 AVM PCI (Fritz!PCI) no parameter 28 Sedlbauer Speed Fax+ ONLY WORKS AS A MODULE ! - + 29 Siemens I-Surf 1.0 ONLY WORKS AS A MODULE ! + 30 ACER P10 ONLY WORKS AS A MODULE ! + 31 HST Saphir pa=irq, pb=io + 32 Telekom A4T no parameter + 33 Scitel Quadro subcontroller (4*S0, subctrl 1...4) + 34 Gazel ISDN cards (ISA) pa=irq, pb=io + 34 Gazel ISDN cards (PCI) no parameter + 35 HFC 2BDS0 PCI no parameter Running the driver ------------------ @@ -515,8 +539,7 @@ to e.g. the Internet: /sbin/hisaxctrl HiSax 5 1 Remarks: -a) If you have a CISCO don't forget to switch off the KEEP ALIVE option! -b) Use state of the art isdn4k-utils +a) Use state of the art isdn4k-utils Here an example script: #!/bin/sh @@ -568,7 +591,7 @@ case "$1" in /sbin/isdnctrl encap isdn0s cisco-h fi fi - /sbin/isdnctrl dialmode isdn0 auto + /sbin/isdnctrl dialmode isdn0 manual # configure tcp/ip /sbin/ifconfig isdn0 ${LOCAL_IP} pointopoint ${REMOTE_IP} /sbin/route add -host ${REMOTE_IP} isdn0 @@ -578,6 +601,7 @@ case "$1" in /sbin/hisaxctrl HiSax 5 1 if [ ${I4L_LEASED_128K} = "yes" ]; then # B-CHANNEL 2 + sleep 10; /* Wait for master */ /sbin/hisaxctrl HiSax 5 2 fi ;; @@ -599,4 +623,3 @@ case "$1" in exit 1 esac exit 0 - diff --git a/Documentation/isdn/README.audio b/Documentation/isdn/README.audio index 370806401..8ebca1929 100644 --- a/Documentation/isdn/README.audio +++ b/Documentation/isdn/README.audio @@ -1,4 +1,4 @@ -$Id: README.audio,v 1.7 1998/07/26 18:45:34 armin Exp $ +$Id: README.audio,v 1.8 1999/07/11 17:17:29 armin Exp $ ISDN subsystem for Linux. Description of audio mode. @@ -58,6 +58,17 @@ The following commands are supported: AT+VSD=? Report possible parameters. AT+VSD? Show current parameters. + AT+VDD=x,y Set DTMF-detection parameters. + Only possible if online and during this connection. + Possible parameters: + x = 0 ... 15 sensitivity threshold level. + (default 0 , I4L soft-decode) + (1-15 soft-decode off, hardware on) + y = 0 ... 255 tone duration in units of 5ms. + Not for I4L soft decode (default 8, 40ms) + AT+VDD=? Report possible parameters. + AT+VDD? Show current parameters. + AT+VSM=x Select audio data format. Possible parameters: 2 = ADPCM-2 diff --git a/Documentation/isdn/README.avmb1 b/Documentation/isdn/README.avmb1 index 342532786..34eee2125 100644 --- a/Documentation/isdn/README.avmb1 +++ b/Documentation/isdn/README.avmb1 @@ -1,10 +1,22 @@ +Driver for active AVM Controller. + The driver provides a kernel capi2.0 Interface (kernelcapi) and on top of this a User-Level-CAPI2.0-interface (capi) and a driver to connect isdn4linux with CAPI2.0 (capidrv). +The lowlevel interface can be used to implement a CAPI2.0 +also for passive cards since July 1999. + +The author can be reached at calle@calle.in-berlin.de. +The command avmcapictrl is part of the isdn4k-utils. +t4-files can be found at ftp://ftp.avm.de/cardware/b1/linux/firmware -The Author can be reached at calle@calle.in-berlin.de -The command avmcapictrl is part of the isdn4linux-utils. -t4-files can be found at ftp.avm.de. +Currently supported cards: + B1 ISA (all versions) + B1 PCI + T1/T1B (HEMA card) + M1 + M2 + B1 PCMCIA Installing ---------- @@ -26,32 +38,145 @@ To use the card you need the t4-files to download the firmware. AVM GmbH provides several t4-files for the different D-channel protocols (b1.t4 for Euro-ISDN). Install these file in /lib/isdn. -If you do not compile the driver as modules, you have to add the -card(s) and load them after booting: - -avmcapictrl add 0x150 15 -avmcapictrl load /lib/isdn/b1.t4 1 - -if you configure as modules you have two possibilities: +if you configure as modules load the modules this way: insmod /lib/modules/current/misc/capiutil.o -insmod /lib/modules/current/misc/kernelcapi.o portbase=0x150 irq=15 +insmod /lib/modules/current/misc/b1.o +insmod /lib/modules/current/misc/kernelcapi.o insmod /lib/modules/current/misc/capidrv.o insmod /lib/modules/current/misc/capi.o -avmcapictrl load /lib/isdn/b1.t4 -or +if you have an B1-PCI card load the module b1pci.o +insmod /lib/modules/current/misc/b1pci.o +and load the firmware with +avmcapictrl load /lib/isdn/b1.t4 1 -insmod /lib/modules/current/misc/capiutil.o -insmod /lib/modules/current/misc/kernelcapi.o -insmod /lib/modules/current/misc/capidrv.o -insmod /lib/modules/current/misc/capi.o +if you have an B1-ISA card load the module b1isa.o +and add the card by calling avmcapictrl add 0x150 15 -avmcapictrl load /lib/isdn/b1.t4 +and load the firmware by calling +avmcapictrl load /lib/isdn/b1.t4 1 + +if you have an T1-ISA card load the module t1isa.o +and add the card by calling +avmcapictrl add 0x450 15 T1 0 +and load the firmware by calling +avmcapictrl load /lib/isdn/t1.t4 1 + +if you have an PCMCIA card (B1/M1/M2) load the module b1pcmcia.o +before you insert the card. + +Leased Lines with B1 +-------------------- +Init card and load firmware. +For an D64S use "FV: 1" as phone number +For an D64S2 use "FV: 1" and "FV: 2" for multilink +or "FV: 1,2" to use CAPI channel bundling. + +/proc-Interface +----------------- + +/proc/capi: + dr-xr-xr-x 2 root root 0 Jul 1 14:03 . + dr-xr-xr-x 82 root root 0 Jun 30 19:08 .. + -r--r--r-- 1 root root 0 Jul 1 14:03 applications + -r--r--r-- 1 root root 0 Jul 1 14:03 applstats + -r--r--r-- 1 root root 0 Jul 1 14:03 capi20 + -r--r--r-- 1 root root 0 Jul 1 14:03 capidrv + -r--r--r-- 1 root root 0 Jul 1 14:03 controller + -r--r--r-- 1 root root 0 Jul 1 14:03 contrstats + -r--r--r-- 1 root root 0 Jul 1 14:03 driver + -r--r--r-- 1 root root 0 Jul 1 14:03 ncci + -r--r--r-- 1 root root 0 Jul 1 14:03 users + +/proc/capi/applications: + applid level3cnt datablkcnt datablklen ncci-cnt recvqueuelen + level3cnt: capi_register parameter + datablkcnt: capi_register parameter + ncci-cnt: current number of nccis (connections) + recvqueuelen: number of messages on receive queue + for example: +1 -2 16 2048 1 0 +2 2 7 2048 1 0 + +/proc/capi/applstats: + applid recvctlmsg nrecvdatamsg nsentctlmsg nsentdatamsg + recvctlmsg: capi messages received without DATA_B3_IND + recvdatamsg: capi DATA_B3_IND received + sentctlmsg: capi messages sent without DATA_B3_REQ + sentdatamsg: capi DATA_B3_REQ sent + for example: +1 2057 1699 1721 1699 + +/proc/capi/capi20: statistics of capi.o (/dev/capi20) + minor nopen nrecvdropmsg nrecvctlmsg nrecvdatamsg sentctlmsg sentdatamsg + minor: minor device number of capi device + nopen: number of calls to devices open + nrecvdropmsg: capi messages dropped (messages in recvqueue in close) + nrecvctlmsg: capi messages received without DATA_B3_IND + nrecvdatamsg: capi DATA_B3_IND received + nsentctlmsg: capi messages sent without DATA_B3_REQ + nsentdatamsg: capi DATA_B3_REQ sent + + for example: +1 2 18 0 16 2 + +/proc/capi/capidrv: statistics of capidrv.o (capi messages) + nrecvctlmsg nrecvdatamsg sentctlmsg sentdatamsg + nrecvctlmsg: capi messages received without DATA_B3_IND + nrecvdatamsg: capi DATA_B3_IND received + nsentctlmsg: capi messages sent without DATA_B3_REQ + nsentdatamsg: capi DATA_B3_REQ sent + for example: +2780 2226 2256 2226 + +/proc/capi/controller: + controller drivername state cardname controllerinfo + for example: +1 b1pci running b1pci-e000 B1 3.07-01 0xe000 19 +2 t1isa running t1isa-450 B1 3.07-01 0x450 11 0 +3 b1pcmcia running m2-150 B1 3.07-01 0x150 5 + +/proc/capi/contrstats: + controller nrecvctlmsg nrecvdatamsg sentctlmsg sentdatamsg + nrecvctlmsg: capi messages received without DATA_B3_IND + nrecvdatamsg: capi DATA_B3_IND received + nsentctlmsg: capi messages sent without DATA_B3_REQ + nsentdatamsg: capi DATA_B3_REQ sent + for example: +1 2845 2272 2310 2274 +2 2 0 2 0 +3 2 0 2 0 + +/proc/capi/driver: + drivername ncontroller + for example: +b1pci 1 +t1isa 1 +b1pcmcia 1 +b1isa 0 + +/proc/capi/ncci: + apllid ncci winsize sendwindow + for example: +1 0x10101 8 0 + +/proc/capi/users: kernelmodules that use the kernelcapi. + name + for example: +capidrv +capi20 Questions --------- -Check out the FAQ (ftp.franken.de). +Check out the FAQ (ftp.franken.de) or subscribe to the +linux-avmb1@calle.in-berlin.de mailing list by sending +a mail to majordomo@calle.in-berlin.de with +subscribe linux-avmb1 +in the body. + +German documentaion and several scripts can be found at +ftp://ftp.avm.de/cardware/b1/linux/ Bugs ---- diff --git a/Documentation/isdn/README.concap b/Documentation/isdn/README.concap index 02a99c7dd..a934fe346 100644 --- a/Documentation/isdn/README.concap +++ b/Documentation/isdn/README.concap @@ -118,7 +118,7 @@ struct concap_proto_ops{ or when the device driver resets the interface. All services of the encapsulation protocol may be used after this*/ int (*restart)(struct concap_proto *cprot, - struct device *ndev, + struct net_device *ndev, struct concap_device_ops *dops); /* deactivate an encapsulation protocol instance. The encapsulation @@ -174,7 +174,7 @@ because the encapsulation protocol directly calls netif_rx(). An encapsulation protocol itself is actually the struct concap_proto{ - struct device *net_dev; /* net device using our service */ + struct net_device *net_dev; /* net device using our service */ struct concap_device_ops *dops; /* callbacks provided by device */ struct concap_proto_ops *pops; /* callbacks provided by us */ int flags; @@ -199,7 +199,7 @@ A possible extended device structure which uses the connection controlling encapsulation services could look like this: struct concap_device{ - struct device net_dev; + struct net_device net_dev; struct my_priv /* device->local stuff */ /* the my_priv struct might contain a struct concap_device_ops *dops; @@ -225,9 +225,9 @@ ATM). If general linux network interfaces explicitly supported concap -protocols (e.g. by a member struct concap_proto* in struct device) +protocols (e.g. by a member struct concap_proto* in struct net_device) then the interface of the service function could be changed -by passing a pointer of type (struct device*) instead of +by passing a pointer of type (struct net_device*) instead of type (struct concap_proto*). Doing so would make many of the service functions compatible to network device support functions. @@ -237,7 +237,7 @@ e.g. instead of the concap protocol's service function we could have - int (*encap_and_xmit)(struct device *ndev, struct sk_buff *skb); + int (*encap_and_xmit)(struct net_device *ndev, struct sk_buff *skb); As this is compatible to the dev->hard_start_xmit() method, the device driver could directly register the concap protocol's encap_and_xmit() @@ -247,7 +247,7 @@ procedure call layer. The device's data request function could also be defined as - int (*data_req)(struct device *ndev, struct sk_buff *skb); + int (*data_req)(struct net_device *ndev, struct sk_buff *skb); This might even allow for some protocol stacking. And the network interface might even register the same data_req() function directly diff --git a/Documentation/isdn/README.diversion b/Documentation/isdn/README.diversion new file mode 100644 index 000000000..8e1d7a01b --- /dev/null +++ b/Documentation/isdn/README.diversion @@ -0,0 +1,127 @@ +The isdn diversion services are a supporting module working together with +the isdn4linux and the HiSax module for passive cards. +Active cards, TAs and cards using a own or other driver than the HiSax +module need to be adapted to the HL<->LL interface described in a separate +document. The diversion services may be used with all cards supported by +the HiSax driver. +The diversion kernel interface and controlling tool divertctrl were written +by Werner Cornelius (werner@isdn4linux.de or werner@titro.de) under the +GNU Public License. + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software + Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + +Table of contents +================= + +1. Features of the i4l diversion services + (Or what can the i4l diversion services do for me) + +2. Required hard- and software + +3. Compiling, installing and loading/unloading the module + Tracing calling and diversion information + +4. Tracing calling and diversion information + +5. Format of the divert device ASCII output + + +1. Features of the i4l diversion services + (Or what can the i4l diversion services do for me) + + The i4l diversion services offers call forwarding and logging normally + only supported by isdn phones. Incoming calls may be diverted + unconditionally (CFU), when not reachable (CFNR) or on busy condition + (CFB). + The diversions may be invoked statically in the providers exchange + as normally done by isdn phones. In this case all incoming calls + with a special (or all) service identifiers are forwarded if the + forwarding reason is met. Activated static services may also be + interrogated (queried). + The i4l diversion services additionally offers a dynamic version of + call forwarding which is not preprogrammed inside the providers exchange + but dynamically activated by i4l. + In this case all incoming calls are checked by rules that may be + compared to the mechanism of ipfwadm or ipchains. If a given rule matches + the checking process is finished and the rule matching will be applied + to the call. + The rules include primary and secondary service indentifiers, called + number and subaddress, callers number and subaddress and whether the rule + matches to all filtered calls or only those when all B-channel resources + are exhausted. + Actions that may be invoked by a rule are ignore, proceed, reject, + direct divert or delayed divert of a call. + All incoming calls matching a rule except the ignore rule a reported and + logged as ASCII via the proc filesystem (/proc/net/isdn/divert). If proceed + is selected the call will be held in a proceeding state (without ringing) + for a certain amount of time to let an external program or client decide + how to handle the call. + + +2. Required hard- and software + + For using the i4l diversion services the isdn line must be of a EURO/DSS1 + type. Additionally the i4l services only work together with the HiSax + driver for passive isdn cards. All HiSax supported cards may be used for + the diversion purposes. + The static diversion services require the provider having static services + CFU, CFNR, CFB activated on an MSN-line. The static services may not be + used on a point-to-point connection. Further the static services are only + available in some countries (for example germany). Countries requiring the + keypad protocol for activating static diversions (like the netherlands) are + not supported but may use the tty devices for this purpose. + The dynamic diversion servives may be used in all countries if the provider + enables the feature CF (call forwarding). This should work on both MSN- and + point-to-point lines. + To add and delete rules the additional divertctrl program is needed. This + program is part of the isdn4kutils package. + +3. Compiling, installing and loading/unloading the module + Tracing calling and diversion information + + + To compile the i4l code with diversion support you need to say yes to the + DSS1 diversion services when selecting the i4l options in the kernel + config (menuconfig or config). + After having properly activated a make modules and make modules_install all + required modules will be correctly installed in the needed modules dirs. + As the diversion services are currently not included in the scripts of most + standard distributions you will have to add a "insmod dss1_divert" after + having loaded the global isdn module. + The module can be loaded without any command line parameters. + If the module is actually loaded and active may be checked with a + "cat /proc/modules" or "ls /proc/net/isdn/divert". The divert file is + dynamically created by the diversion module and removed when the module is + unloaded. + + +4. Tracing calling and diversion information + + You also may put a "cat /proc/net/isdn/divert" in the background with the + output redirected to a file. Then all actions of the module are logged. + The divert file in the proc system may be opened more than once, so in + conjunction with inetd and a small remote client on other machines inside + your network incoming calls and reactions by the module may be shown on + every listening machine. + If a call is reported as proceeding an external program or client may + specify during a certain amount of time (normally 4 to 10 seconds) what + to do with that call. + To unload the module all open files to the device in the proc system must + be closed. Otherwise the module (and isdn.o) may not be unloaded. + +5. Format of the divert device ASCII output + + To be done later + diff --git a/Documentation/isdn/README.eicon b/Documentation/isdn/README.eicon index 22669282d..d55cc14ad 100644 --- a/Documentation/isdn/README.eicon +++ b/Documentation/isdn/README.eicon @@ -1,4 +1,4 @@ -$Id: README.eicon,v 1.3 1999/03/29 11:10:04 armin Exp $ +$Id: README.eicon,v 1.4 1999/07/11 17:17:30 armin Exp $ (c) 1999 Cytronics & Melware @@ -21,12 +21,8 @@ It is meant to be used with isdn4linux, an ISDN link-level module for Linux. along with this program; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. -NOTE : Since the eicon driver is still experimental, this README file - may be incomplete and not up to date. -However, the driver should work under following conditions : - Supported Cards --------------- diff --git a/Documentation/isdn/README.fax b/Documentation/isdn/README.fax new file mode 100644 index 000000000..897abd0ef --- /dev/null +++ b/Documentation/isdn/README.fax @@ -0,0 +1,38 @@ + +Fax with isdn4linux +=================== + +When enabled during kernel configuration, the tty emulator +of the ISDN subsystem is capable of the Fax Class 2 commands. + +This only makes sense under the following conditions : + +- You need the commands as dummy, because you are using + hylafax (with patch) for AVM capi. +- You want to use the fax capabillities of your isdn-card. + (supported cards are listed below) + + +NOTE: This implementation does *not* support fax with passive + ISDN-cards (known as softfax). The low-level driver of + the ISDN-card and/or the card itself must support this. + + +Supported ISDN-Cards +-------------------- + +Eicon DIVA Server BRI/PCI (will be ready soon) +Eicon DIVA Server PRI/PCI (will be ready soon) + + + +The command set is known as Class 2 (not Class 2.0) and +can be activated by AT+FCLASS=2 + + +The interface between the link-level-module and the hardware-level driver +is described in the files INTERFACE.fax and INTERFACE. + +Armin +mac@melware.de + diff --git a/Documentation/isdn/README.hfc-pci b/Documentation/isdn/README.hfc-pci new file mode 100644 index 000000000..94e0d4352 --- /dev/null +++ b/Documentation/isdn/README.hfc-pci @@ -0,0 +1,26 @@ +The driver for the HFC-PCI and HFC-PCI-A chips from CCD may be used +for many OEM cards using this chips. +Additionally the driver has a special feature which makes it possible +to read the echo-channel of the isdn bus. So all frames in both directions +may be logged. +When the echo logging feature is used the number of available B-channels +for a HFC-PCI card is reduced to 1. Of course this is only relevant to +the card, not to the isdn line. +To activate the echo mode the following ioctls must be entered: + +hisaxctrl <driver/cardname> 10 1 + +This reduces the available channels to 1. There must not be open connections +through this card when entering the command. +And then: + +hisaxctrl <driver/cardname> 12 1 + +This enables the echo mode. If Hex logging is activated the isdnctrlx +devices show a output with a line beginning of HEX: for the providers +exchange and ECHO: for isdn devices sending to the provider. + +Comments and reports to werner@isdn4linux.de or werner@titro.de . + + + diff --git a/Documentation/joystick-api.txt b/Documentation/joystick-api.txt index 6b7b34129..fe3b6842c 100644 --- a/Documentation/joystick-api.txt +++ b/Documentation/joystick-api.txt @@ -1,7 +1,7 @@ Joystick API Documentation -*-Text-*- Ragnar Hojland Espinosa - <ragnar@lightside.ddns.org> + <ragnar@lightside.dhis.org> 7 Aug 1998 @@ -74,9 +74,10 @@ is, you have both an axis 0 and a button 0). Generally, 2nd Axis Y 3 ...and so on -Hats vary from one joystick type to another. Some can be moved in 8 -directions, some only in 4, however, the driver always reports a hat as two -independent axis, even if the hardware doesn't allow independent movement. +Hats vary from one joystick type to another. Some can be moved in 8 +directions, some only in 4. The driver, however, always reports a hat +as two independent axis, even if the hardware doesn't allow independent +movement. 2.3 js_event.value @@ -85,7 +86,7 @@ independent axis, even if the hardware doesn't allow independent movement. For an axis, ``value'' is a signed integer between -32767 and +32767 representing the position of the joystick along that axis. If you don't read a 0 when the joystick is `dead', or if it doesn't span the -full range, you should recalibrate (with, for example, jscal). +full range, you should recalibrate it (with, for example, jscal). For a button, ``value'' for a press button event is 1 and for a release button event is 0. @@ -93,16 +94,16 @@ button event is 0. Though this if (js_event.type == JS_EVENT_BUTTON) { - buttons_state ^= (1 << js_event.number); + buttons_state ^= (1 << js_event.number); } may work well if you handle JS_EVENT_INIT events separately, if ((js_event.type & ~JS_EVENT_INIT) == JS_EVENT_BUTTON) { - if (js_event.value) - buttons_state |= (1 << js_event.number); - else - buttons_state &= ~(1 << js_event.number); + if (js_event.value) + buttons_state |= (1 << js_event.number); + else + buttons_state &= ~(1 << js_event.number); } is much safer since it can't lose sync with the driver. As you would @@ -112,6 +113,7 @@ snippet, this ends up being shorter. 2.4 js_event.time ~~~~~~~~~~~~~~~~~ + The time an event was generated is stored in ``js_event.time''. It's a time in miliseconds since ... well, since sometime in the past. This eases the task of detecting double clicks, figuring out if movement of axis and button @@ -144,14 +146,14 @@ all events on the queue (that is, until you get a -1). For example, while (1) { - while (read (fd, &e, sizeof(struct js_event)) > 0) { - process_event (e); - } - /* EAGAIN is returned when the queue is empty */ - if (errno != EAGAIN) { - /* error */ - } - /* do something interesting with processed events */ + while (read (fd, &e, sizeof(struct js_event)) > 0) { + process_event (e); + } + /* EAGAIN is returned when the queue is empty */ + if (errno != EAGAIN) { + /* error */ + } + /* do something interesting with processed events */ } One reason for emptying the queue is that if it gets full you'll start @@ -219,6 +221,7 @@ JS_VERSION symbol #ifdef JS_VERSION #if JS_VERSION > 0xsomething + 4.2 JSIOCGNAME ~~~~~~~~~~~~~~ @@ -232,6 +235,7 @@ possible overrun should the name be too long. strncpy(name, "Unknown", sizeof(name)); printf("Name: %s\n", name); + 4.3 JSIOC[SG]CORR ~~~~~~~~~~~~~~~~~ @@ -266,10 +270,10 @@ The driver offers backward compatibility, though. Here's a quick summary: struct JS_DATA_TYPE js; while (1) { - if (read (fd, &js, JS_RETURN) != JS_RETURN) { - /* error */ - } - usleep (1000); + if (read (fd, &js, JS_RETURN) != JS_RETURN) { + /* error */ + } + usleep (1000); } As you can figure out from the example, the read returns immediately, @@ -299,6 +303,7 @@ The v0.8.0.2 driver also had an interface for 'digital joysticks', (now called Multisystem joystick in this driver), under /dev/djsX. This driver doesn't try to be compatible with that interface. + 6. Final Notes ~~~~~~~~~~~~~~ diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index e1392c277..02f1310e7 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -19,7 +19,7 @@ restrictions referred to are that the relevant option is valid if: HW Appropriate hardware is enabled. ISDN Appropriate ISDN support is enabled. JOY Appropriate joystick support is enabled. - LPT Printer support is enabled. + LP Printer support is enabled. MCA MCA bus support is enabled. MDA The MDA console is enabled. MOUSE Appropriate mouse support is enabled. @@ -29,6 +29,7 @@ restrictions referred to are that the relevant option is valid if: PCI PCI bus support is enabled. PCMCIA The PCMCIA subsystem is enabled. PNP Plug & Play support is enabled. + PPT Parallel port support is enabled. PS2 Appropriate PS/2 support is enabled. RAM RAMdisc support is enabled. SCSI Appropriate SCSI support is enabled. @@ -187,7 +188,21 @@ running once the system is up. load_ramdisk= [RAM] - lp= [LPT] Parallel Printer. + lp=0 [LP] Specify parallel ports to use, e.g, +or lp=port[,port...] lp=none,parport0 (lp0 not configured, lp1 uses +or lp=reset first parallel port). 'lp=0' disables the printer +or lp=auto driver. 'lp=reset' (which can be specified in + addition to the ports) causes attached + printers to be reset. Using + lp=port1,port2,... specifies the parallel + ports to associate lp devices with, starting + with lp0. A port specification may be 'none' + to skip that lp device, or a parport name such + as 'parport0'. Specifying 'lp=auto' instead + of a port specification list means that device + IDs from each port should be examined, to see + if an IEEE 1284-compliant printer is attached; + if so, the driver will manage that printer. ltpc= [HW] @@ -244,7 +259,19 @@ running once the system is up. panic= - parport= [HW,LP] + parport=0 [HW,PPT] Specify parallel ports. 0 +or parport=auto disables. Use 'auto' to force the driver +or parport=0xBBB[,IRQ[,DMA]] to use any IRQ/DMA settings detected + (the default is to ignore detected + IRQ/DMA settings because of possible + conflicts). You can specify the base + address, IRQ, and DMA settings; IRQ + and DMA should be numbers or 'auto' + (for using detected settings on that + particular port). Parallel ports are + assigned in the order they are + specified on the command line, + starting with parport0. pas16= [HW,SCSI] @@ -262,7 +289,7 @@ running once the system is up. pirq= [SMP,APIC] - plip= [LP,NET] Parallel port network link. + plip= [PPT,NET] Parallel port network link. profile= diff --git a/Documentation/mca.txt b/Documentation/mca.txt index 9de804532..5ac4ecc26 100644 --- a/Documentation/mca.txt +++ b/Documentation/mca.txt @@ -19,7 +19,7 @@ this. The typical probe code looks like the following: #include <linux/mca.h> unsigned char pos2, pos3, pos4, pos5; - struct device* dev; + struct net_device* dev; int slot; if( MCA_bus ) { @@ -114,7 +114,7 @@ Your typical proc function will look something like this: static int dev_getinfo( char* buf, int slot, void* d ) { - struct device* dev = (struct device*) d; + struct net_device* dev = (struct net_device*) d; int len = 0; len += sprintf( buf+len, "Device: %s\n", dev->name ); diff --git a/Documentation/mkdev.ida b/Documentation/mkdev.ida new file mode 100644 index 000000000..d2764899d --- /dev/null +++ b/Documentation/mkdev.ida @@ -0,0 +1,40 @@ +#!/bin/sh +# Script to create device nodes for SMART array controllers +# Usage: +# mkdev.ida [num controllers] [num log volumes] [num partitions] +# +# With no arguments, the script assumes 1 controller, 16 logical volumes, +# and 16 partitions/volume, which is adequate for most configurations. +# +# If you had 5 controllers and were planning on no more than 4 logical volumes +# each, using a maximum of 8 partitions per volume, you could say: +# +# mkdev.ida 5 4 8 +# +# Of course, this has no real benefit over "mkdev.ida 5" except that it +# doesn't create so many device nodes in /dev/ida. + +NR_CTLR=${1-1} +NR_VOL=${2-16} +NR_PART=${3-16} + +if [ ! -d /dev/ida ]; then + mkdir -p /dev/ida +fi + +C=0; while [ $C -lt $NR_CTLR ]; do + MAJ=`expr $C + 72` + D=0; while [ $D -lt $NR_VOL ]; do + P=0; while [ $P -lt $NR_PART ]; do + MIN=`expr $D \* 16 + $P` + if [ $P -eq 0 ]; then + mknod /dev/ida/c${C}d${D} b $MAJ $MIN + else + mknod /dev/ida/c${C}d${D}p${P} b $MAJ $MIN + fi + P=`expr $P + 1` + done + D=`expr $D + 1` + done + C=`expr $C + 1` +done diff --git a/Documentation/modules.txt b/Documentation/modules.txt index ca9c434f7..cf8b42214 100644 --- a/Documentation/modules.txt +++ b/Documentation/modules.txt @@ -59,7 +59,7 @@ Here is a sample of the available modules included in the kernel sources: Most low-level SCSI drivers: (i.e. aha1542, in2000) All SCSI high-level drivers: disk, tape, cdrom, generic. - Most ethernet drivers: (too many to list, please see the file + Most Ethernet drivers: (too many to list, please see the file ./Documentation/networking/net-modules.txt) Most CDROM drivers: diff --git a/Documentation/mtrr.txt b/Documentation/mtrr.txt index f047b7a28..941da7e91 100644 --- a/Documentation/mtrr.txt +++ b/Documentation/mtrr.txt @@ -52,7 +52,7 @@ reg00: base=0x00000000 ( 0MB), size= 128MB: write-back, count=1 reg01: base=0x08000000 ( 128MB), size= 64MB: write-back, count=1 reg02: base=0xf8000000 (3968MB), size= 4MB: write-combining, count=1 -This is for videoram at base address 0xf8000000 and size 4 MBytes. To +This is for video RAM at base address 0xf8000000 and size 4 megabytes. To find out your base address, you need to look at the output of your X server, which tells you where the linear framebuffer address is. A typical line that you may get is: @@ -68,7 +68,7 @@ know?), the following line will tell you: (--) S3: videoram: 4096k -That's 4 MBytes, which is 0x400000 bytes (in hexadecimal). +That's 4 megabytes, which is 0x400000 bytes (in hexadecimal). A patch is being written for XFree86 which will make this automatic: in other words the X server will manipulate /proc/mtrr using the ioctl() interface, so users won't have to do anything. If you use a diff --git a/Documentation/nbd.txt b/Documentation/nbd.txt index fc488449e..7b7899740 100644 --- a/Documentation/nbd.txt +++ b/Documentation/nbd.txt @@ -4,11 +4,11 @@ means, that it works on my computer, and it worked on one of school computers. - What is it: With this compiled in the kernel, linux can use a remote + What is it: With this compiled in the kernel, Linux can use a remote server as one of its block devices. So every time the client computer wants to read /dev/nd0, it sends a request over TCP to the server, which will reply with the data read. This can be used for stations with - low-disk space (or even diskless - if you boot from floppy) to + low disk space (or even diskless - if you boot from floppy) to borrow disk space from another computer. Unlike NFS, it is possible to put any filesystem on it etc. It is impossible to use NBD as a root filesystem, since it requires a user-level program to start. It also diff --git a/Documentation/networking/00-INDEX b/Documentation/networking/00-INDEX index e3981efff..be39d93e4 100644 --- a/Documentation/networking/00-INDEX +++ b/Documentation/networking/00-INDEX @@ -13,9 +13,9 @@ PLIP.txt alias.txt - info on using alias network devices arcnet-hardware.txt - - tons of info on arcnet, hubs, arcnet card jumper settings, etc. + - tons of info on ARCnet, hubs, jumper settings for ARCnet cards, etc. arcnet.txt - - info on the using the arcnet driver itself. + - info on the using the ARCnet driver itself. ax25.txt - info on using AX.25 and NET/ROM code for Linux baycom.txt @@ -69,13 +69,13 @@ shaper.txt smc9.txt - the driver for SMC's 9000 series of Ethernet cards soundmodem.txt - - Linux driver for soundcards as AX.25 modems + - Linux driver for sound cards as AX.25 modems tcp.txt - short blurb on how TCP output takes place. tulip.txt - info on using DEC 21040/21041/21140 based PCI Ethernet cards. vortex.txt - - info on using 3Com Vortex (3c590, 3c592, 3c595, 3c597) e'net cards. + - info on using 3Com Vortex (3c590, 3c592, 3c595, 3c597) Ethernet cards. wan-router.txt - Wan router documentation wanpipe.txt diff --git a/Documentation/networking/Configurable b/Documentation/networking/Configurable index 62c27457e..a941ca30f 100644 --- a/Documentation/networking/Configurable +++ b/Documentation/networking/Configurable @@ -20,11 +20,11 @@ to Address Resolution Protocol (ARP) are very easily viewed and altered. 7000 Others are already accessible via the related user space programs. -For example, MAX_WINDOW has a default of 32k which is a good choice for -modern hardware, but if you have a slow (8 bit) ethercard and/or a slow +For example, MAX_WINDOW has a default of 32 k which is a good choice for +modern hardware, but if you have a slow (8 bit) Ethernet card and/or a slow machine, then this will be far too big for the card to keep up with fast -Tx'ing machines on the same net, resulting in overruns and receive errors. -A value of about 4k would be more appropriate, which can be set via: +machines transmitting on the same net, resulting in overruns and receive errors. +A value of about 4 k would be more appropriate, which can be set via: # route add -net 192.168.3.0 window 4096 diff --git a/Documentation/networking/DLINK.txt b/Documentation/networking/DLINK.txt index 9dafab262..efbf441ba 100644 --- a/Documentation/networking/DLINK.txt +++ b/Documentation/networking/DLINK.txt @@ -18,8 +18,8 @@ Released 1994-06-13 pocket adapters, for the parallel port on a Linux based machine. Some adapter "clones" will also work. Xircom is _not_ a clone... These drivers _can_ be used as loadable modules, - and were developed for use on Linux v1.1.13 and above. - For use on Linux v1.0.X, or earlier releases, see below. + and were developed for use on Linux 1.1.13 and above. + For use on Linux 1.0.X, or earlier releases, see below. I have used these drivers for NFS, ftp, telnet and X-clients on remote machines. Transmissions with ftp seems to work as @@ -57,7 +57,7 @@ Released 1994-06-13 de620.h Macros for de620.c If you are upgrading from the d-link tar release, there will - also be a "dlink-patches" file that will patch Linux v1.1.18: + also be a "dlink-patches" file that will patch Linux 1.1.18: linux/drivers/net/Makefile linux/drivers/net/CONFIG linux/drivers/net/MODULES @@ -162,10 +162,10 @@ Released 1994-06-13 6. USING THE DRIVERS WITH EARLIER RELEASES. - The later v1.1.X releases of the Linux kernel include some + The later 1.1.X releases of the Linux kernel include some changes in the networking layer (a.k.a. NET3). This affects these drivers in a few places. The hints that follow are - _not_ tested by me, since I don't have the diskspace to keep + _not_ tested by me, since I don't have the disk space to keep all releases on-line. Known needed changes to date: - release patchfile: some patches will fail, but they should diff --git a/Documentation/networking/PLIP.txt b/Documentation/networking/PLIP.txt index b3539f5f9..ad7e3f7c3 100644 --- a/Documentation/networking/PLIP.txt +++ b/Documentation/networking/PLIP.txt @@ -49,17 +49,69 @@ an existing Ethernet. Isn't standard (not even de facto standard, like SLIP). Performance -========== +=========== PLIP easily outperforms Ethernet cards....(ups, I was dreaming, but it *is* getting late. EOB) +PLIP driver details +------------------- + +The Linux PLIP driver is an implementation of the original Crynwr protocol, +that uses the parallel port subsystem of the kernel in order to properly +share parallel ports between PLIP and other services. + +IRQs and trigger timeouts +========================= + +When a parallel port used for a PLIP driver has an IRQ configured to it, the +PLIP driver is signaled whenever data is sent to it via the cable, such that +when no data is available, the driver isn't being used. + +However, on some machines it is hard, if not impossible, to configure an IRQ +to a certain parallel port, mainly because it is used by some other device. +On these machines, the PLIP driver can be used in IRQ-less mode, where +the PLIP driver would constantly poll the parallel port for data waiting, +and if such data is available, process it. This mode is less efficient than +the IRQ mode, because the driver has to check the parallel port many times +per second, even when no data at all is sent. Some rough measurements +indicate that there isn't a noticeable performance drop when using IRQ-less +mode as compared to IRQ mode as far as the data transfer speed is involved. +There is a performance drop on the machine hosting the driver. + +When the PLIP driver is used in IRQ mode, the timeout used for triggering a +data transfer (the maximal time the PLIP driver would allow the other side +before announcing a timeout, when trying to handshake a transfer of some +data) is, by default, 500usec. As IRQ delivery is more or less immediate, +this timeout is quite sufficient. + +When in IRQ-less mode, the PLIP driver polls the parallel port HZ times +per second (where HZ is typically 100 on most platforms, and 1024 on an +Alpha, as of this writing). Between two such polls, there are 10^6/HZ usecs. +On an i386, for example, 10^6/100 = 10000usec. It is easy to see that it is +quite possible for the trigger timeout to expire between two such polls, as +the timeout is only 500usec long. As a result, it is required to change the +trigger timeout on the *other* side of a PLIP connection, to about +10^6/HZ usecs. If both sides of a PLIP connection are used in IRQ-less mode, +this timeout is required on both sides. + +It appears that in practice, the trigger timeout can be shorter than in the +above calculation. It isn't an important issue, unless the wire is faulty, +in which case a long timeout would stall the machine when, for whatever +reason, bits are dropped. + +A utility that can perform this change in Linux is plipconfig, which is part +of the net-tools package (its location can be found in the +Documentation/Changes file). An example command would be +'plipconfig plipX trigger 10000', where plipX is the appropriate +PLIP device. + PLIP hardware interconnection ----------------------------- PLIP uses several different data transfer methods. The first (and the only one implemented in the early version of the code) uses a standard -printer "null" cable to transfers data four bits at a time using +printer "null" cable to transfer data four bits at a time using data bit outputs connected to status bit inputs. The second data transfer method relies on both machines having @@ -138,18 +190,18 @@ PLIP Mode 0 transfer protocol The PLIP driver is compatible with the "Crynwr" parallel port transfer standard in Mode 0. That standard specifies the following protocol: - send header nibble '8' + send header nibble '0x8' count-low octet count-high octet ... data octets checksum octet Each octet is sent as - <wait for rx. '1'> <send 0x10+(octet&0x0F)> - <wait for rx. '0'> <send 0x00+((octet>>4)&0x0F)> + <wait for rx. '0x1?'> <send 0x10+(octet&0x0F)> + <wait for rx. '0x0?'> <send 0x00+((octet>>4)&0x0F)> To start a transfer the transmitting machine outputs a nibble 0x08. -The raises the ACK line, triggering an interrupt in the receiving +That raises the ACK line, triggering an interrupt in the receiving machine. The receiving machine disables interrupts and raises its own ACK line. diff --git a/Documentation/networking/README.sb1000 b/Documentation/networking/README.sb1000 new file mode 100644 index 000000000..37c39a0c8 --- /dev/null +++ b/Documentation/networking/README.sb1000 @@ -0,0 +1,207 @@ +sb1000 is a module network device driver for the General Instrument (also known +as NextLevel) SURFboard1000 internal cable modem board. This is an ISA card +which is used by a number of cable TV companies to provide cable modem access. +It's a one-way downstream-only cable modem, meaning that your upstream net link +is provided by your regular phone modem. + +This driver was written by Franco Venturi <fventuri@mediaone.net>. He deserves +a great deal of thanks for this wonderful piece of code! + +----------------------------------------------------------------------------- + +Support for this device is now a part of the standard Linux kernel. The +driver source code file is drivers/net/sb1000.c. In addition to this +you will need: + +1.) The "cmconfig" program. This is a utility which supplements "ifconfig" +to configure the cable modem and network interface (usually called "cm0"); +and + +2.) Several PPP scripts which live in /etc/ppp to make connecting via your +cable modem easy. + + These utilities can be obtained from: + + http://www.jacksonville.net/~fventuri/ + + in Franco's original source code distribution .tar.gz file. Support for + the sb1000 driver can be found at: + + http://home.adelphia.net/~siglercm/sb1000.html + http://linuxpower.cx/~cable/ + + along with these utilties. + +3.) The standard isapnp tools. These are necessary to configure your SB1000 +card at boot time (or afterwards by hand) since it's a PnP card. + + If you don't have these installed as a standard part of your Linux + distribution, you can find them at: + + http://www.roestock.demon.co.uk/isapnptools/ + + or check your Linux distribution binary CD or their web site. For help with + isapnp, pnpdump, or /etc/isapnp.conf, go to: + + http://www.roestock.demon.co.uk/isapnptools/isapnpfaq.html + +----------------------------------------------------------------------------- + +To make the SB1000 card work, follow these steps: + +1.) Run `make config', or `make menuconfig', or `make xconfig', whichever +you prefer, in the top kernel tree directory to set up your kernel +configuration. Make sure to say "Y" to "Prompt for development drivers" +and to say "M" to the sb1000 driver. Also say "Y" or "M" to all the standard +networking questions to get TCP/IP and PPP networking support. + +2.) *BEFORE* you build the kernel, edit drivers/net/sb1000.c. Make sure +to redefine the value of READ_DATA_PORT to match the I/O address used +by isapnp to access your PnP cards. This is the value of READPORT in +/etc/isapnp.conf or given by the output of pnpdump. + +3.) Build and install the kernel and modules as usual. + +4.) Boot your new kernel following the usual procedures. + +5.) Set up to configure the new SB1000 PnP card by capturing the output +of "pnpdump" to a file and editing this file to set the correct I/O ports, +IRQ, and DMA settings for all your PnP cards. Make sure none of the settings +conflict with one another. Then test this configuration by running the +"isapnp" command with your new config file as the input. Check for +errors and fix as necessary. (As an aside, I use I/O ports 0x110 and +0x310 and IRQ 11 for my SB1000 card and these work well for me. YMMV.) +Then save the finished config file as /etc/isapnp.conf for proper configuration +on subsequent reboots. + +6.) Download the original file sb1000-1.1.2.tar.gz from Franco's site or one of +the others referenced above. As root, unpack it into a temporary directory and +do a `make cmconfig' and then `install -c cmconfig /usr/local/sbin'. Don't do +`make install' because it expects to find all the utilities built and ready for +installation, not just cmconfig. + +7.) As root, copy all the files under the ppp/ subdirectory in Franco's +tar file into /etc/ppp, being careful not to overwrite any files that are +already in there. Then modify ppp@gi-on to set the correct login name, +phone number, and frequency for the cable modem. Also edit pap-secrets +to specify your login name and password and any site-specific information +you need. + +8.) Be sure to modify /etc/ppp/firewall to use ipchains instead of +the older ipfwadm commands from the 2.0.x kernels. There's a neat utility to +convert ipfwadm commands to ipchains commands: + + http://users.dhp.com/~whisper/ipfwadm2ipchains/ + +You may also wish to modify the firewall script to implement a different +firewalling scheme. + +9.) Start the PPP connection via the script /etc/ppp/ppp@gi-on. You must be +root to do this. It's better to use a utility like sudo to execute +frequently used commands like this with root permissions if possible. If you +connect successfully the cable modem interface will come up and you'll see a +driver message like this at the console: + + cm0: sb1000 at (0x110,0x310), csn 1, S/N 0x2a0d16d8, IRQ 11. + sb1000.c:v1.1.2 6/01/98 (fventuri@mediaone.net) + +The "ifconfig" command should show two new interfaces, ppp0 and cm0. +The command "cmconfig cm0" will give you information about the cable modem +interface. + +10.) Try pinging a site via `ping -c 5 www.yahoo.com', for example. You should +see packets received. + +11.) If you can't get site names (like www.yahoo.com) to resolve into +IP addresses (like 204.71.200.67), be sure your /etc/resolv.conf file +has no syntax errors and has the right nameserver IP addresses in it. +If this doesn't help, try something like `ping -c 5 204.71.200.67' to +see if the networking is running but the DNS resolution is where the +problem lies. + +12.) If you still have problems, go to the support web sites mentioned above +and read the information and documentation there. + +----------------------------------------------------------------------------- + +Common problems: + +1.) Packets go out on the ppp0 interface but don't come back on the cm0 +interface. It looks like I'm connected but I can't even ping any +numerical IP addresses. (This happens predominantly on Debian systems due +to a default boot-time configuration script.) + +Solution -- As root `echo 0 > /proc/sys/net/ipv4/conf/cm0/rp_filter' so it +can share the same IP address as the ppp0 interface. Note that this +command should probably be added to the /etc/ppp/cablemodem script +*right*between* the "/sbin/ifconfig" and "/sbin/cmconfig" commands. +You may need to do this to /proc/sys/net/ipv4/conf/ppp0/rp_filter as well. +If you do this to /proc/sys/net/ipv4/conf/default/rp_filter on each reboot +(in rc.local or some such) then any interfaces can share the same IP +addresses. + +2.) I get "unresolved symbol" error messages on executing `insmod sb1000.o'. + +Solution -- You probably have a non-matching kernel source tree and +/usr/include/linux and /usr/include/asm header files. Make sure you +install the correct versions of the header files in these two directories. +Then rebuild and reinstall the kernel. + +3.) When isapnp runs it reports an error, and my SB1000 card isn't working. + +Solution -- There's a problem with later versions of isapnp using the "(CHECK)" +option in the lines that allocate the two I/O addresses for the SB1000 card. +This first popped up on RH 6.0. Delete "(CHECK)" for the SB1000 I/O addresses. +Make sure they don't conflict with any other pieces of hardware first! Then +rerun isapnp and go from there. + +4.) I can't execute the /etc/ppp/ppp@gi-on file. + +Solution -- As root do `chmod ug+x /etc/ppp/ppp@gi-on'. + +5.) The firewall script isn't working (with 2.2.x and higher kernels). + +Solution -- Use the ipfwadm2ipchains script referenced above to convert the +/etc/ppp/firewall script from the deprecated ipfwadm commands to ipchains. + +6.) I'm getting *tons* of firewall deny messages in the /var/kern.log, +/var/messages, and/or /var/syslog files, and they're filling up my /var +partition!!! + +Solution -- First, tell your ISP that you're receiving DoS (Denial of Service) +and/or portscanning (UDP connection attempts) attacks! Look over the deny +messages to figure out what the attack is and where it's coming from. Next, +edit /etc/ppp/cablemodem and make sure the ",nobroadcast" option is turned on +to the "cmconfig" command (uncomment that line). If you're not receiving these +denied packets on your broadcast interface (IP address xxx.yyy.zzz.255 +typically), then someone is attacking your machine in particular. Be careful +out there.... + +7.) Everything seems to work fine but my computer locks up after a while +(and typically during a lengthy download through the cable modem)! + +Solution -- You may need to add a short delay in the driver to 'slow down' the +SURFboard because your PC might not be able to keep up with the transfer rate +of the SB1000. To do this, it's probably best to download Franco's +sb1000-1.1.2.tar.gz archive and build and install sb1000.o manually. You'll +want to edit the 'Makefile' and look for the 'SB1000_DELAY' +define. Uncomment those 'CFLAGS' lines (and comment out the default ones) +and try setting the delay to something like 60 microseconds with: +'-DSB1000_DELAY=60'. Then do `make' and as root `make install' and try +it out. If it still doesn't work or you like playing with the driver, you may +try other numbers. Remember though that the higher the delay, the slower the +driver (which slows down the rest of the PC too when it is actively +used). Thanks to Ed Daiga for this tip! + +----------------------------------------------------------------------------- + +Credits: This README came from Franco Venturi's original README file which is +still supplied with his driver .tar.gz archive. I and all other sb1000 users +owe Franco a tremendous "Thank you!" Additional thanks goes to Carl Patten +and Ralph Bonnell who are now managing the Linux SB1000 web site, and to +the SB1000 users who reported and helped debug the common problems listed +above. + + + Clemmitt Sigler + csigler@vt.edu diff --git a/Documentation/networking/cs89x0.txt b/Documentation/networking/cs89x0.txt index 1da37d5ce..f26fad498 100644 --- a/Documentation/networking/cs89x0.txt +++ b/Documentation/networking/cs89x0.txt @@ -323,20 +323,20 @@ endif d.) In /linux/drivers/net/Space.c file, add the line: -extern int cs89x0_probe(struct device *dev); +extern int cs89x0_probe(struct net_device *dev); Example: - extern int ultra_probe(struct device *dev); - extern int wd_probe(struct device *dev); - extern int el2_probe(struct device *dev); + extern int ultra_probe(struct net_device *dev); + extern int wd_probe(struct net_device *dev); + extern int el2_probe(struct net_device *dev); - extern int cs89x0_probe(struct device *dev); + extern int cs89x0_probe(struct net_device *dev); - extern int ne_probe(struct device *dev); - extern int hp_probe(struct device *dev); - extern int hp_plus_probe(struct device *dev); + extern int ne_probe(struct net_device *dev); + extern int hp_probe(struct net_device *dev); + extern int hp_plus_probe(struct net_device *dev); Also add: diff --git a/Documentation/networking/dgrs.txt b/Documentation/networking/dgrs.txt index d37d1c41a..1aa1bb3f9 100644 --- a/Documentation/networking/dgrs.txt +++ b/Documentation/networking/dgrs.txt @@ -1,4 +1,4 @@ - The Digi Intl. RightSwitch SE-X (dgrs) Device Driver + The Digi International RightSwitch SE-X (dgrs) Device Driver This is a Linux driver for the Digi International RightSwitch SE-X EISA and PCI boards. These are 4 (EISA) or 6 (PCI) port Ethernet diff --git a/Documentation/networking/ip_masq/ip_masq-API-ex.c b/Documentation/networking/ip_masq/ip_masq-API-ex.c deleted file mode 100644 index 4b6999d55..000000000 --- a/Documentation/networking/ip_masq/ip_masq-API-ex.c +++ /dev/null @@ -1,77 +0,0 @@ -/* - There is only 1 optname (see setsockopt(2)), IP_FW_MASQ_CTL that - must be used. - Funcionality depends on your kernel CONFIG options, here is - an example you can use to create an ``incoming'' tunnel: - - See "user.c" module under ipmasqadm tree for a generic example - */ -#undef __KERNEL__ /* Makefile lazyness ;) */ -#include <stdio.h> -#include <stdlib.h> -#include <netinet/in.h> -#include <sys/socket.h> -#include <sys/types.h> -#include <arpa/inet.h> - -#include <asm/types.h> /* For __uXX types */ -#include <net/if.h> -#include <netinet/ip_icmp.h> -#include <netinet/udp.h> -#include <netinet/tcp.h> -#include <linux/ip_fw.h> /* For IP_FW_MASQ_CTL */ -#include <linux/ip_masq.h> /* For specific masq defs */ - - -int create_listening_masq(struct ip_masq_ctl *masq, int proto, u_int32_t src_addr, u_int16_t src_port, u_int32_t dst_addr) -{ - int sockfd; - - sockfd = socket(AF_INET, SOCK_RAW, IPPROTO_RAW); - - if (sockfd<0) { - perror("socket(RAW)"); - return -1; - } - - memset (masq, 0, sizeof (*masq)); - - /* - * Want user tunnel control - */ - masq->m_target = IP_MASQ_TARGET_USER; - - /* - * Want to insert new - */ - masq->m_cmd = IP_MASQ_CMD_INSERT; - - masq->u.user.protocol = proto; - masq->u.user.saddr = src_addr; - masq->u.user.sport = src_port; - masq->u.user.rt_daddr = inet_addr("192.168.21.239"); - - if (setsockopt(sockfd, IPPROTO_IP, - IP_FW_MASQ_CTL, (char *)masq, sizeof(*masq))) { - perror("setsockopt()"); - return -1; - } - /* masq struct now contains tunnel details */ - fprintf(stderr, "PROTO=%d SRC=0x%X:%x - MASQ=0x%X:%x - DST=0x%X:%x\n", - masq->u.user.protocol, - ntohl(masq->u.user.saddr), ntohs(masq->u.user.sport), - ntohl(masq->u.user.maddr), ntohs(masq->u.user.mport), - ntohl(masq->u.user.daddr), ntohs(masq->u.user.dport)); - return 0; -} - -int main(void) { - struct ip_masq_ctl masq_buf; - - return create_listening_masq(&masq_buf, - IPPROTO_TCP, - inet_addr("192.168.1.4"), - htons(23), - inet_addr("192.168.21.3")); -} - diff --git a/Documentation/networking/irda.txt b/Documentation/networking/irda.txt index 1a49505e1..fa455100e 100644 --- a/Documentation/networking/irda.txt +++ b/Documentation/networking/irda.txt @@ -1,13 +1,14 @@ To use the IrDA protocols within Linux you will need to get a suitable copy of the IrDA Utilities. More detailed information about these and associated -programs can be found on http://www.cs.uit.no/~dagb/irda/. +programs can be found on http://www.cs.uit.no/linux-irda/ -For more information about the IrDA protocol stack, see the IR-HOWTO -written by Werner Heuser <r2d2c3po@zedat.fu-berlin.de> +For more information about how to use the IrDA protocol stack, see the +IR-HOWTO (http://www.snafu.de/~wehe/IR-HOWTO.html) written by Werner Heuser +<wehe@snafu.de> -There is an active mailing list for discussing Linux IrDA matters called -linux-irda. To subscribe to it, send a message to Majordomo@list.uit.no -with the words "subscribe linux-irda" in the body of the message, the -subject field is ignored. +There is an active mailing list for discussing Linux-IrDA matters called +linux-irda. To subscribe to it, visit: + + http://www.pasta.cs.uit.no/mailman/listinfo/linux-irda Dag Brattli <dagb@cs.uit.no> diff --git a/Documentation/networking/multicast.txt b/Documentation/networking/multicast.txt index 2bd6fd9ba..d426f36db 100644 --- a/Documentation/networking/multicast.txt +++ b/Documentation/networking/multicast.txt @@ -1,11 +1,13 @@ -Behaviour of cards under Multicast. This is how they currently -behave not what the hardware can do - i.e. the lance driver doesn't -use its filter, even though the code for loading it is in the DEC -lance based driver. +Behaviour of Cards Under Multicast +================================== -The following multicast requirements are needed +This is how they currently behave, not what the hardware can do--for example, +the Lance driver doesn't use its filter, even though the code for loading +it is in the DEC Lance-based driver. + +The following are requirements for multicasting ----------------------------------------------- -Appletalk Multicast hardware filtering not important but +AppleTalk Multicast hardware filtering not important but avoid cards only doing promisc IP-Multicast Multicast hardware filters really help IP-MRoute AllMulti hardware filters are of no help diff --git a/Documentation/networking/soundmodem.txt b/Documentation/networking/soundmodem.txt index 47d1dfc3c..202101d18 100644 --- a/Documentation/networking/soundmodem.txt +++ b/Documentation/networking/soundmodem.txt @@ -42,8 +42,8 @@ driver from the insmod command line (or by means of an option line in /etc/conf.modules). Examples: - insmod soundmodem hw=0 mode=0 iobase=0x220 irq=5 dma=1 - sethdlc -i sm0 -p hw sbc type afsk1200 io 0x220 irq 5 dma 1 + insmod soundmodem mode="sbc:afsk1200" iobase=0x220 irq=5 dma=1 + sethdlc -i sm0 -p mode "sbc:afsk1200" io 0x220 irq 5 dma 1 Both lines configure the first port to drive a soundblaster card in 1200 baud AFSK mode. diff --git a/Documentation/networking/wavelan.txt b/Documentation/networking/wavelan.txt index 77351b4e7..a4a1f7921 100644 --- a/Documentation/networking/wavelan.txt +++ b/Documentation/networking/wavelan.txt @@ -1,7 +1,11 @@ Sun Jul 2 01:38:33 EST 1995 -See also: http://www-uk.hpl.hp.com/people/jt/Linux/Wavelan.html + As the date above certify, this ``readme'' is mostly +obsolete. Please read release notes and change list in +driver/net/wavelan.p.h, and consult my web page at : + http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Wavelan.html + Jean <jt@hpl.hp.com> 1. At present the driver autoprobes for a WaveLAN card only at I/O address 0x390. The version of the card that I use (NCR) supports four I/O addresses diff --git a/Documentation/oops-tracing.txt b/Documentation/oops-tracing.txt index ebdef0873..9673a46e7 100644 --- a/Documentation/oops-tracing.txt +++ b/Documentation/oops-tracing.txt @@ -20,7 +20,7 @@ stable as humanly possible. Full Information ---------------- -From: Linus Torvalds <torvalds@cs.helsinki.fi> +From: Linus Torvalds <torvalds@transmeta.com> How to track down an Oops.. [originally a mail to linux-kernel] diff --git a/Documentation/parport.txt b/Documentation/parport.txt index 854290f15..152e3f3cf 100644 --- a/Documentation/parport.txt +++ b/Documentation/parport.txt @@ -139,8 +139,7 @@ spintime The number of microseconds to busy-loop while waiting peripherals. This is a port-wide setting, i.e. it applies to all devices on a particular port. -timeslice The number of jiffies (FIXME: this should be in - milliseconds or something) that a device driver is +timeslice The number of miliseconds that a device driver is allowed to keep a port claimed for. This is advisory, and driver can ignore it if it must. diff --git a/Documentation/proc_usb_info.txt b/Documentation/proc_usb_info.txt new file mode 100644 index 000000000..e3c705581 --- /dev/null +++ b/Documentation/proc_usb_info.txt @@ -0,0 +1,221 @@ +/proc/bus/usb filesystem output +=============================== +(version 19990722) + + +The /proc filesystem for USB devices generates +/proc/bus/usb/drivers and /proc/bus/usb/devices. + +/proc/bus/usb/drivers just lists the registered drivers, +one per line. Not very interesting or pretty. + +In /proc/bus/usb/devices, each device's output has multiple +lines (except for a root hub) of ASCII output. +I made it ASCII instead of binary on purpose, so that someone +can obtain some useful data from it without the use of an +auxiliary program. However, with an auxiliary program, the numbers +in the first 4 columns of each "T:" line (topology info: +Lev, Prnt, Port, Cnt) can be used to build a USB topology diagram. +(I think. I haven't proved this, but I have tested it with 3 +different topo/connections and it looked possible.) + +Each line is tagged with a one-character ID for that line: + +T = Topology (etc.) +D = Device descriptor info. +P = Product ID info. (from Device descriptor, but they won't fit + together on one line) +C = Configuration descriptor info. (* = active configuration) +I = Interface descriptor info. +E = Endpoint descriptor info. + +======================================================================= + +/proc/bus/usb/devices output format: + +Legend: + d = decimal number (may have leading spaces or 0's) + x = hexadecimal number (may have leading spaces or 0's) + s = string + + +Topology info: + +T: Lev=dd Prnt=dd Port=dd Cnt=dd Dev#=ddd Spd=ddd If#=ddd MxCh=dd Driver=%s +| | | | | | | | | |__DriverName +| | | | | | | | |__MaxChildren +| | | | | | | |__Configured InterfaceNumber +| | | | | | |__Device Speed in Mbps +| | | | | |__DeviceNumber +| | | | |__Count of devices at this level +| | | |__Connector/Port on Parent for this device +| | |__Parent DeviceNumber +| |__Level in topology +|__Topology info tag + + +Device descriptor info & Product ID info: + +D: Ver=x.xx Cls=xx(s) Sub=xx Prot=xx MxPS=dd #Cfgs=dd +P: Vendor=xxxx ProdID=xxxx Rev=xx.xx + +where +D: Ver=x.xx Cls=xx(sssss) Sub=xx Prot=xx MxPS=dd #Cfgs=dd +| | | | | | |__NumberConfigurations +| | | | | |__MaxPacketSize of Default Endpoint +| | | | |__DeviceProtocol +| | | |__DeviceSubClass +| | |__DeviceClass +| |__Device USB version +|__Device info tag #1 + +where +P: Vendor=xxxx ProdID=xxxx Rev=xx.xx +| | | |__Product revision number +| | |__Product ID code +| |__Vendor ID code +|__Device info tag #2 + + +Configuration descriptor info: + +C: #Ifs=dd Cfg#=dd Atr=xx MPwr=dddmA +| | | | |__MaxPower in mA +| | | |__Attributes +| | |__ConfiguratioNumber +| |__NumberOfInterfaces +|__Config info tag + + +Interface descriptor info (can be multiple per Config): + +I: If#=dd Alt=dd #EPs=dd Cls=xx(sssss) Sub=xx Prot=xx +| | | | | | |__InterfaceProtocol +| | | | | |__InterfaceSubClass +| | | | |__InterfaceClass +| | | |__NumberOfEndpoints +| | |__AlternateSettingNumber +| |__InterfaceNumber +|__Interface info tag + + +Endpoint descriptor info (can be multiple per Interface): + +E: Ad=xx(s) Atr=xx(ssss) MxPS=dddd Ivl=dddms +E: Ad=xx(s) Atr=xx(ssss) MxPS=dddd Ivl=dddms +| | | | |__Interval +| | | |__EndpointMaxPacketSize +| | |__Attributes(EndpointType) +| |__EndpointAddress(I=In,O=Out) +|__Endpoint info tag + +======================================================================= + + +If a user or script is interested only in Topology info, for +example, use something like "grep ^T: /proc/bus/usb/devices" +for only the Topology lines. A command like +"grep -i ^[tdp]: /proc/bus/usb/devices" can be used to list +only the lines that begin with the characters in square brackets, +where the valid characters are TDPCIE. With a slightly more able +script, it can display any selected lines (for example, only T, D, +and P lines) and change their output format. (The "procusb" +Perl script is the beginning of this idea. It will list only +selected lines [selected from TDPCIE] or "All" lines from +/proc/bus/usb/devices.) + +The Topology lines can be used to generate a graphic/pictorial +of the USB devices on a system's root hub. (See more below +on how to do this.) + +The Configuration lines could be used to list maximum power +(in milliamps) that a system's USB devices are using. +For example, "grep ^C: /proc/bus/usb/devices". + + +Here's an example, from a system which has a UHCI root hub, +an external hub connected to the root hub, and a mouse and +a video camera connected to the external hub. [The video +camera is listed as (none) since it is not recognized by +any driver.] + + +T: Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= -1 Spd=12 If#= 0 MxCh= 2 Driver=(root hub) +T: Lev=01 Prnt=00 Port=00 Cnt=01 Dev#= 1 Spd=12 If#= 0 MxCh= 4 Driver=hub +D: Ver= 1.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 +P: Vendor=0451 ProdID=1446 Rev= 1.00 +C:* #If= 1 Cfg#= 1 Atr=e0 MxPwr=100mA +I: If#= 0 Alt= 0 #EP= 1 Cls=09(hub ) Sub=00 Prot=00 +E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=255ms +T: Lev=02 Prnt=01 Port=00 Cnt=01 Dev#= 3 Spd=1.5 If#= 0 MxCh= 0 Driver=mouse +D: Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 +P: Vendor=0458 ProdID=0001 Rev= 0.00 +C:* #If= 1 Cfg#= 1 Atr=a0 MxPwr=100mA +I: If#= 0 Alt= 0 #EP= 1 Cls=03(HID ) Sub=01 Prot=02 +E: Ad=81(I) Atr=03(Int.) MxPS= 3 Ivl= 10ms +T: Lev=02 Prnt=01 Port=02 Cnt=02 Dev#= 4 Spd=12 If#= 0 MxCh= 0 Driver=(none) +D: Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 +P: Vendor=04c8 ProdID=0720 Rev= 1.01 +C:* #If= 1 Cfg#= 1 Atr=80 MxPwr=500mA +I: If#= 0 Alt= 0 #EP= 2 Cls=0a(unk. ) Sub=ff Prot=00 +E: Ad=81(I) Atr=01(Isoc) MxPS= 1 Ivl= 1ms +E: Ad=82(I) Atr=01(Isoc) MxPS= 384 Ivl= 1ms +I: If#= 0 Alt= 1 #EP= 2 Cls=0a(unk. ) Sub=ff Prot=00 +E: Ad=81(I) Atr=01(Isoc) MxPS= 1 Ivl= 1ms +E: Ad=82(I) Atr=01(Isoc) MxPS= 240 Ivl= 1ms +I: If#= 0 Alt= 2 #EP= 2 Cls=0a(unk. ) Sub=ff Prot=00 +E: Ad=81(I) Atr=01(Isoc) MxPS= 1 Ivl= 1ms +E: Ad=82(I) Atr=01(Isoc) MxPS= 576 Ivl= 1ms +I: If#= 0 Alt= 3 #EP= 2 Cls=0a(unk. ) Sub=ff Prot=00 +E: Ad=81(I) Atr=01(Isoc) MxPS= 1 Ivl= 1ms +E: Ad=82(I) Atr=01(Isoc) MxPS= 464 Ivl= 1ms +I: If#= 0 Alt= 4 #EP= 2 Cls=0a(unk. ) Sub=ff Prot=00 +E: Ad=81(I) Atr=01(Isoc) MxPS= 1 Ivl= 1ms +E: Ad=82(I) Atr=01(Isoc) MxPS= 688 Ivl= 1ms + + +Selecting only the "T:" lines from this (for example, by using +"procusb t"), we have: + +T: Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= -1 Spd=12 If#= 0 MxCh= 2 Driver=(root hub) +T: Lev=01 Prnt=00 Port=00 Cnt=01 Dev#= 1 Spd=12 If#= 0 MxCh= 4 Driver=hub +T: Lev=02 Prnt=01 Port=00 Cnt=01 Dev#= 3 Spd=1.5 If#= 0 MxCh= 0 Driver=mouse +T: Lev=02 Prnt=01 Port=02 Cnt=02 Dev#= 4 Spd=12 If#= 0 MxCh= 0 Driver=(none) + + +Physically this looks like (or could be converted to): + + +------------------+ + | PC/root_hub (12)| Dev# = -1 + +------------------+ (nn) is Mbps. + Level 0 | CN.0 | CN.1 | [CN = connector/port #] + +------------------+ + / + / + +-----------------------+ + Level 1 | Dev#1: 4-port hub (12)| + +-----------------------+ + |CN.0 |CN.1 |CN.2 |CN.3 | + +-----------------------+ + \ \____________________ + \_____ \ + \ \ + +--------------------+ +--------------------+ + Level 2 | Dev# 3: mouse (1.5)| | Dev# 4: (none) (12)| + +--------------------+ +--------------------+ + + + +Or, in a more tree-like structure (ports [Connectors] without +connections could be omitted): + +PC: Dev# -1, root hub, 2 ports, 12 Mbps +|_ CN.0: Dev# 1, hub, 4 ports, 12 Mbps + |_ CN.0: Dev #3, mouse, 1.5 Mbps + |_ CN.1: + |_ CN.2: Dev #4, (none), 12 Mbps [or use "unknown" for (none)] + |_ CN.3: +|_ CN.1: + + + ### END ### diff --git a/Documentation/scsi-generic.txt b/Documentation/scsi-generic.txt index 17822c4ad..2d26dec9d 100644 --- a/Documentation/scsi-generic.txt +++ b/Documentation/scsi-generic.txt @@ -1,34 +1,38 @@ - Notes on Linux's SG driver version 2.1.30 + Notes on Linux's SG driver version 2.1.34 ----------------------------------------- - 990328 + 990606 Introduction ============ +Sg is one of the four "high level" SCSI device drivers along with +sd, st and sr (disk, tape and CDROM respectively). Sg is more generalized +(but lower level) than its siblings and tends to be used on SCSI devices +that don't fit into the already serviced categories. Thus sg is used for +scanners, cd writers and reading audio cds digitally amongst other things. + These are notes on the Linux SCSI generic packet device driver (sg) -describing version 2.1.30 . The original driver was written by Lawrence -Foard and has remained in place with minimal changes since circa 1992. +describing version 2.1.34 . The original driver was written by Lawrence +Foard and remained in place with minimal changes since circa 1992. Version 2 of this driver remains backward compatible (binary and source **) with the original. It adds scatter gather, command queuing, per file descriptor sequencing, asynchronous notification and better error reporting. -Sg is one of the four "high level" SCSI device drivers along with -sd, st and sr (disk, tape and CDROM respectively). Sg is more generalized -(but lower level) than its sibling and tends to be used on SCSI devices -that don't fit into the already serviced categories. Thus sg is used for -scanners, cd writers and reading audio cds amongst other things. +This is an abridged version of the sg documentation that is targeted +at the linux/Documentation directory. The full document can be found +at http://www.torque.net/sg/p/scsi-generic_long.txt . -The interface and usage of the original sg driver has been documented +The interface and usage of the original sg driver have been documented by Heiko Eissfeldt in a HOWTO called SCSI-Programming-HOWTO. My copy of the document is version 1.5 dated 7th May 1996. It can found at -ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO/SCSI-Programming-HOWTO . -Amongst other things it has a lot of tables from the SCSI-2 standard -that are very useful for programming this interface. +ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO-SCSI-Programming-HOWTO . +A copy of this document can be found at: +http://www.torque.net/sg/p/original/HOWTO-SCSI-Programming-HOWTO . ** It is possible to write applications that perform differently depending on whether they are using the original or this version of -the sg device driver. The author is not aware of any useful applications -that have problems with version 2 (yet). +the sg device driver. The author is not aware of any useful +pre-existing applications that have problems with version 2 (yet). Architecture @@ -38,9 +42,11 @@ It is one of the four high level device driver in the SCSI sub-system; the others are sd (for direct-access devices - disks), st (for tapes) and sr (for data cdroms). The other three devices are block devices. -The unifying layer of the SCSI sub-system in the so-called mid-level. -Below that are all the drivers for the various adapters supported by -Linux. +The unifying layer of the SCSI sub-system is the so-called mid-level. +Below that are the "low level" drivers which are the drivers for the +various adapters supported by Linux. Also at this level are pseudo +adapter drivers such as ide-scsi which converts the SCSI protocol to +ATAPI (which are similar to one another) for use by IDE devices. Since sg is a character device it supports the traditional Unix system calls of open(), close(), read(), write() and ioctl(). Two other @@ -85,8 +91,9 @@ struct sg_header { unsigned char sense_buffer[16]; }; /* this structure is 36 bytes long */ -The 'pack_len' is bizzare and ends up having the 'reply_len' put in it -(perhaps it had a use at some stage). +The 'pack_len' is bizarre and ends up having the 'reply_len' put in it +(perhaps it had a use at some stage). Even though it looks like an +input variable, it is not read by sg internally (only written). The 'reply_len' is the length of the data the corresponding read() will/should request (including the sg_header). @@ -95,14 +102,14 @@ The 'pack_id' is not acted upon by the sg device driver but is conveyed back to the corresponding read() so it can be used for sequencing by an application. -The 'result' is also bizzare, turning certain types of host codes it 0 (no +The 'result' is also bizarre, turning certain types of host codes to 0 (no error), EBUSY or EIO. With better error reporting now available, the 'result' is best ignored. -The 'twelve_byte' field overrides the internal SCSI command length "guessing" +The 'twelve_byte' field overrides the internal SCSI command length detection algorithm for group 6 and 7 commands (ie when 1st byte >= 0xc0) and forces -a command lenth of 12 bytes. -The command length "guessing" algorithm is as follows: +a command length of 12 bytes. +The command length detection algorithm is as follows: Group: 0 1 2 3 4 5 6 7 Length: 6 10 10 12 12 12 10 10 @@ -115,6 +122,7 @@ or COMMAND_TERMINATED [or (driver_status & DRIVER_SENSE) is true]. This buffer should be at least 18 bytes long and arguably 32 bytes; unfortunately this is unlikely to happen in the 2.2.x series of kernels. + The new sg_header offered in this driver is: #define SG_MAX_SENSE 16 struct sg_header @@ -122,15 +130,17 @@ struct sg_header int pack_len; /* [o] reply_len (ie useless) ignored as input */ int reply_len; /* [i] max length of expected reply (inc. sg_header) */ int pack_id; /* [io] id number of packet (use ints >= 0) */ - int result; /* [o] 0==ok, else (+ve) Unix errno code (e.g. EIO) */ + int result; /* [o] 0==ok, else (+ve) Unix errno (best ignored) */ unsigned int twelve_byte:1; /* [i] Force 12 byte command length for group 6 & 7 commands */ unsigned int target_status:5; /* [o] scsi status from target */ unsigned int host_status:8; /* [o] host status (see "DID" codes) */ unsigned int driver_status:8; /* [o] driver status+suggestion */ unsigned int other_flags:10; /* unused */ - unsigned char sense_buffer[SG_MAX_SENSE]; /* [o] when target_status is - CHECK_CONDITION or COMMAND_TERMINATED this is output. */ + unsigned char sense_buffer[SG_MAX_SENSE]; /* [o] Output in 3 cases: + when target_status is CHECK_CONDITION or + when target_status is COMMAND_TERMINATED or + when (driver_status & DRIVER_SENSE) is true. */ }; /* This structure is 36 bytes long on i386 */ Firstly the new header is binary compatible with the original. This is @@ -146,6 +156,9 @@ EAGAIN) until a packet with that 'pack_id' becomes available. In all cases the value of 'pack_id' available after a read() is the value given to that variable in the prior, corresponding write(). +The SCSI command length can now be given directly using the SG_NEXT_CMD_LEN +ioctl(). + The 'target_status' field is always output and is the (masked and shifted 1 bit right) SCSI status code from the target device. The allowable values are (found in <scsi/scsi.h>): @@ -162,28 +175,28 @@ values are (found in <scsi/scsi.h>): When the 'target_status' is CHECK_CONDITION or COMMAND_TERMINATED the 'sense_buffer' is output. Note that when (driver_status & DRIVER_SENSE) is true then the 'sense_buffer' is also output (this seems to occur when -the scsi ide emulation is used). When the 'sense_buffer' is output the +the ide-scsi emulation is used). When the 'sense_buffer' is output the SCSI Sense Key can be found at (sense_buffer[2] & 0x0f) . The 'host_status' field is always output and has the following values -whose "defines" are not visible outside the kernel (unfortunately): +whose "defines" are not visible outside the kernel. A copy of these +defines can be found in sg_err.h (see the utilities section): #define DID_OK 0x00 /* NO error */ #define DID_NO_CONNECT 0x01 /* Couldn't connect before timeout period */ #define DID_BUS_BUSY 0x02 /* BUS stayed busy through time out period */ #define DID_TIME_OUT 0x03 /* TIMED OUT for other reason */ -#define DID_BAD_TARGET 0x04 /* BAD target. */ +#define DID_BAD_TARGET 0x04 /* BAD target, device not responding? */ #define DID_ABORT 0x05 /* Told to abort for some other reason */ #define DID_PARITY 0x06 /* Parity error */ -#define DID_ERROR 0x07 /* Internal error */ +#define DID_ERROR 0x07 /* Internal error [DMA underrun on aic7xxx]*/ #define DID_RESET 0x08 /* Reset by somebody. */ #define DID_BAD_INTR 0x09 /* Got an interrupt we weren't expecting. */ #define DID_PASSTHROUGH 0x0a /* Force command past mid-layer */ -#define DID_SOFT_ERROR 0x0b /* The low level driver just wish a retry */ +#define DID_SOFT_ERROR 0x0b /* The low level driver wants a retry */ The 'driver_status' field is always output. When ('driver_status' & -DRIVER_SENSE) is true the 'sense_buffer' is also output. The following -values whose "defines" are not visible outside the kernel (unfortunately) -can occur: +DRIVER_SENSE) is true the 'sense_buffer' is also output. A copy of these +defines can be found in sg_err.h (see the utilities section): #define DRIVER_OK 0x00 /* Typically no suggestion */ #define DRIVER_BUSY 0x01 #define DRIVER_SOFT 0x02 @@ -192,7 +205,7 @@ can occur: #define DRIVER_INVALID 0x05 #define DRIVER_TIMEOUT 0x06 #define DRIVER_HARD 0x07 -#define DRIVER_SENSE 0x08 +#define DRIVER_SENSE 0x08 /* Implies sense_buffer output */ /* above status 'or'ed with one of the following suggestions */ #define SUGGEST_RETRY 0x10 #define SUGGEST_ABORT 0x20 @@ -200,55 +213,8 @@ can occur: #define SUGGEST_DIE 0x40 #define SUGGEST_SENSE 0x80 -'other_flags' still remains as a 10 bit field, so code that places 0 in it -will still be happy. It is not used. - - -memory -====== -Memory is a scarce resource in any computer. Sg needs to reserve memory -suitable for DMA roughly equal in size to the maximum of the write and -read data buffers for each packet. This DMA memory is obtained at the time -of a write() and released when the corresponding read() is called (although -if memory is tight it may be using the buffer reserved by the open() ). - -Linux obtaining memory a challenge for several reasons. The memory pool -that sg uses is in common with all other device drivers and all user -processes. In this environment the only way to 99.9% guarantee a driver -will have memory in Linux is to build it into the kernel (ie not as a -module) and then reserve it on initialization before user processes get -a chance. [Of course, another driver initialized before sg could take -all available memory ...] Another problem is the biggest contiguous -chunk of memory that can be obtained from the kernel is 32 * PAGE_SIZE -(which is 128KBytes on i386). As memory gets "splintered" there is a good -chance that buffers won't be available (my machine has 64 MBytes of RAM -and has 3 available at the moment). - -The original sg driver used the following technique: grab a SG_BIG_BUFF -sized buffer at driver initialization and use it for all requests greater -than PAGE_SIZE (4096 bytes on i386). By default SG_BIG_BUFF is set to -32 KBytes in the origianl driver but many applications suggest that the -user increases this number. Linux limits the biggest single buffer of -this type to 32 * PAGE_SIZE (128KBytes on i386). Unfortunately if the -sg driver is a module then there is a high chance a contiguous block of -that large size will not be available at module initialization. - -The author has found no "silver bullet" solution but uses multiple -techniques hoping that at least one is able provide memory at the critical -time. Listed below are some of these techniques: - - use scatter gather: then instead of one large buffer needing to - be found, multiple smaller buffer can be used - - use memory above the 16MByte level: the original driver limited - itself to obtaining memory below the 16MByte level (on the i386) - due to the shortcomings of DMA on ISA adapters. Yet more and more - people use PCI adapters that don't have this problem. So make - the decision based on the capabilities of the host adpater - associated with the current SCSI device - - reserve some memory at open() for emergencies but otherwise - fetch and release it on a per packet basis - - if the kernel is short of memory then dip into the SCSI DMA - pool (maintained by the mid-level driver) to a limited amount - +'other_flags' still remains as a 10 bit field (reduced from 31 bits), so +code that places 0 in it will still be happy. It is not used. System Calls @@ -257,16 +223,16 @@ What follows are descriptions of the characteristics of the standard Unix operating system calls when applied to a SCSI generic device using this version of the device driver. -open ----- +open(const char * filename, int flags) +-------------------------------------- The filename should be an 'sg' device such as /dev/sg[a-z] /dev/sg[0,1,2,...] or a symbolic link to one of these. [Devfs has its own sub-directory for -sg devices.] It seems as though SCSI devices are allocated to sg minor -numbers in the same order as they appear in 'cat /proc/scsi/scsi'. -Sg is a "character" based Linux device driver. This means it has an -open/close/read/write/ioctl type interface. +sg devices with entries like: /dev/sg/c1b2t3u4 .] It seems as though SCSI +devices are allocated to sg minor numbers in the same order as they appear +in 'cat /proc/scsi/scsi'. Sg is a "character" based Linux device driver. +This means it has an open/close/read/write/ioctl type interface. Flags can be either O_RDONLY or O_RDWR or-ed with either O_EXCL waits for other opens on sg device to be closed before @@ -279,7 +245,7 @@ O_NONBLOCK Sets non-blocking mode. Calls that would otherwise block The original version of sg did not allow the O_RDONLY (yielding a EACCES error). This version allows it for accessing ioctls (e.g. doing an sg device scan with the SG_GET_SCSI_ID ioctl) but write()s will not be -allowed. +allowed. These flags are found in <fcntl.h> . By default, sequencing is per file descriptor in this version of sg. This means, for example that 2 processes can independently manipulate the same @@ -290,32 +256,38 @@ on the same device at the same time probably wouldn't be a good idea. The previous version of sg supported only per device sequencing and this can still be selected with the SG_SET_MERGE_FD,1 ioctl(). -The driver will attempt to reserve SG_SCATTER_SZ bytes (32KBytes in the -current sg.h) on open() for "emergency" situations. If this is unavailable -it will halve its request and try again. It gives up if PAGE_SIZE bytes -(4096 bytes on i386) cannot be obtained so no memory is reserved. In this -case open() will still return successfully. The actual amount of memory -reserved can be found with the SG_GET_RESERVED_SIZE ioctl(). +The driver will attempt to reserve SG_DEF_RESERVED_SIZE bytes (32KBytes in +the current sg.h) on open(). The size of this reserved buffer can +subsequently be modified with the SG_SET_RESERVED_SIZE ioctl(). In both +cases these are requests subject to various dynamic constraints. The actual +amount of memory obtained can be found by the SG_GET_RESERVED_SIZE ioctl(). +The reserved buffer will be used if: + - it is not already in use (eg when command queuing is in use) + - a write() does not call for a buffer size larger than the + reserved size. Returns a file descriptor if >= 0 , otherwise -1 implies an error. Error codes (value in 'errno' after -1 returned): -ENODEV sg not compiled into kernel or the kernel cannot find the - sg module (or it can't initialize itself (low memory??)) -ENXIO either scsi sub-system is currently processing some error - (eg doing a device reset) or the sg driver/module removed - or corrupted +EACCES Either the user doesn't have appropriate permissions on + 'filename' or attempted to use both O_RDONLY and O_EXCL EBUSY O_NONBLOCK set and some user of this sg device has O_EXCL set while someone is already using this device EINTR while waiting for an "exclusive" lock to clear, a signal is received, just try again ... +ENODEV sg not compiled into kernel or the kernel cannot find the + sg module (or it can't initialize itself (low memory??)) +ENOENT given filename not found ENOMEM An attempt to get memory to store this open's context failed (this was _not_ a request to reserve DMA memory) -EACCES An attempt to use both O_RDONLY and O_EXCL +ENXIO either there is no attached device corresponding to given + filename or scsi sub-system is currently processing some + error (eg doing a device reset) or the sg driver/module + removed or corrupted -write ------ +write(int sg_fd, const void * buffer, size_t count) +--------------------------------------------------- Even though sg is a character-based device driver it sends and receives packets to/from the associated scsi device. Write() is used to send a packet containing 2 mandatory parts and 1 optional part. The mandatory @@ -343,32 +315,33 @@ In this sg driver a write() should return more or less immediately. Returns number of bytes written if > 0 , otherwise -1 implies an error. Error codes (value in 'errno' after -1 returned): -ENXIO either scsi sub-system is currently processing some error - (eg doing a device reset) or the sg driver/module removed - or corrupted EACCES opened with RD_ONLY flag -EIO incoming buffer too short. It should be at least (6 + - sizeof(struct sg_header))==42 bytes long -EDOM a) command queuing off: a packet is already queued - b) command queuing on: too many packets queued - (SG_MAX_QUEUE exceeded) EAGAIN SCSI mid-level out of command blocks (rare), try again. This is more likely to happen when queuing commands, so wait a bit (eg usleep(10000) ) before trying again +EDOM a) command queuing off: a packet is already queued + b) command queuing on: too many packets queued + (SG_MAX_QUEUE exceeded) + c) SCSI command length given in SG_NEXT_CMD_LEN too long +EFAULT 'buffer' for 'count' bytes is an invalid memory range +EIO incoming buffer too short. It should be at least (6 + + sizeof(struct sg_header))==42 bytes long ENOMEM can't get memory for DMA. Take evasive action ... - (see section on memory) +ENXIO either scsi sub-system is currently processing some error + (eg doing a device reset) or the sg driver/module removed + or corrupted -read ----- +read(int sg_fd, void * buffer, size_t count) +-------------------------------------------- Read() is used to receive a packet containing 1 mandatory part and 1 optional part. The mandatory part is: - a control block (an instance of struct sg_header) The optional part is: - incoming data (eg if a SCSI read command was sent by earlier write() ) The buffer given to a read() and its corresponding count should be -sufficient to accommodate this packet to avoid truncation. Truncation has -occurred if count < sg_header::replylen . +sufficient to accommodate this packet to avoid truncation. Truncation occurs +if count < sg_header::replylen . By default, read() will return the oldest packet queued up. If the SG_SET_FORCE_PACK_ID,1 ioctl() is active then read() will attempt to @@ -377,7 +350,6 @@ sg_header::pack_id given to this read(). If not available it will either wait or yield EAGAIN. As a special case, -1 in sg_header::pack_id given to read() will match the oldest packet. - Returns number of bytes read if > 0 , otherwise -1 implies an error. Unfortunately the return value in the non-error case is simply the same as the count argument. It is not the actual number of bytes @@ -385,25 +357,26 @@ DMA-ed by the SCSI device. This driver is currently unable to provide such an underrun indication. Error codes (value in 'errno' after -1 returned): -ENXIO either scsi sub-system is currently processing some error - (eg doing a device reset) or the sg driver/module removed - or corrupted EAGAIN either no waiting packet or requested packet is not available while O_NONBLOCK flag was set +EFAULT 'buffer' for 'count' bytes is an invalid memory range EINTR while waiting for a packet, a signal is received, just try again ... EIO if the 'count' given to read() is < sizeof(struct sg_header) and the 'result' element in sg_header is non-zero. Not a recommended error reporting technique +ENXIO either scsi sub-system is currently processing some error + (eg doing a device reset) or the sg driver/module removed + or corrupted -close ------ +close(int sg_fd) +---------------- Preferably a close() should be done after all issued write()s have had their corresponding read() calls completed. Unfortunately this is not always possible. The semantics of close() in Unix are to return more or less immediately (ie not wait on any event) so the driver needs to -arrange to an orderly cleanup of those packets that are still "in +arrange for an orderly cleanup of those packets that are still "in flight". A process that has an open file descriptor to an sg device may be aborted @@ -411,22 +384,22 @@ A process that has an open file descriptor to an sg device may be aborted (which is called 'sg_release()' in the version 2 driver) to facilitate the cleanup mentioned above. -A problem persists in version 2.1.8 if the sg driver is a module and is -removed while packets are still "in flight". Hopefully this will be soon -fixed. +A problem persists in version 2.1.34 if the sg driver is a module and is +removed while packets are still "in flight". Returns 0 if successful, otherwise -1 implies an error. Error codes (value in 'errno' after -1 returned): ENXIO sg driver/module removed or corrupted -ioctl (sg specific) -------------------- +ioctl(int sg_fd, int command, ...) [sg specific] +------------------------------------------------- Ken Thompson (or perhaps some other Unix luminary) described ioctl() as the "garbage bin of Unix". This driver compounds the situation by adding -around 18 more commands. These commands either yield state information (10 -of them), change the driver's characteristics (8 of them) or allow direct -communication with the common SCSI mid-level driver. +more ... +If a ioctl command is not recognized by sg (and the various lower levels +that it may pass the command on to) then the error EINVAL occurs. If an +invalid address is given (in the 3rd argument) then the error EFAULT occurs. Those commands with an appended "+" are new in version 2. @@ -442,15 +415,38 @@ a manifest constant HZ which is the number of "jiffies" in 1 second. SG_SET_TIMEOUT: Assumes 3rd argument points to an int containing the new timeout value for this file descriptor. The unit is a "jiffy". Packets that are -already "in flight" will not be effected. The default value is set -on open() and is SG_DEFAULT_TIMEOUT (defined in sg.h). +already "in flight" will not be affected. The default value is set +on open() and is SG_DEFAULT_TIMEOUT (defined in sg.h). This default is +currently 1 minute and may not be long enough for formats. SG_EMULATED_HOST: Assumes 3rd argument points to an int and outputs a flag indicating -whether the host (adapter) is connected to a real SCSI bus or is +whether the host (adapter) is connected to a real SCSI bus or is an emulated one (eg ide-scsi device driver). A value of 1 means emulated while 0 is not. +SG_SET_TRANSFORM W: +Third argument is ignored. Only is meaningful when SG_EMULATED host has +yielded 1 (ie the low-level is the ide-scsi device driver); otherwise +an EINVAL error occurs. The default state is to _not_ transform SCSI +commands to the corresponding ATAPI commands but pass them straight +through as is. [Only certain classes of SCSI commands need to be +transformed to their ATAPI equivalents.] Making this ioctl command causes +transforms to occur thereafter. Subsequent calls to this ioctl command +have no additional effect. Beware, this state will affect all devices +(and hence all related sg file descriptors) associated with this ide-scsi +"bus". +The author of ide-scsi has pointed out that this is not the intended +behaviour which is a 3rd argument of 0 to disable transforms and 1 to +enable transforms. Note the 3rd argument is an 'int' not a 'int *'. +Perhaps the intended behaviour will be implemented soon. + +SG_GET_TRANSFORM: +Third argument is ignored. Only is meaningful when SG_EMULATED host has +yielded 1 (ie the low-level is the ide-scsi device driver); otherwise +an EINVAL error occurs. Returns 0 to indicate _not_ transforming SCSI +to ATAPI commands (default). Returns 1 when it is transforming. + SG_SET_FORCE_LOW_DMA +: Assumes 3rd argument points to an int containing 0 or 1. 0 (default) means sg decides whether to use memory above 16 Mbyte level (on i386) @@ -459,10 +455,10 @@ PCI SCSI adapters will indicate they can DMA to the whole 32 bit address space. If 1 is given then the host adapter is overridden and only memory below the 16MB level is used for DMA. A requirement for this should be -extremely rare. If the "reserve" buffer allocated on open() is not in +extremely rare. If the "reserved" buffer allocated on open() is not in use then it will be de-allocated and re-allocated under the 16MB level (and the latter operation could fail yielding ENOMEM). -Only the current file descriptor is effected. +Only the current file descriptor is affected. SG_GET_LOW_DMA +: Assumes 3rd argument points to an int and places 0 or 1 in it. 0 @@ -472,11 +468,11 @@ on this file descriptor. 1 indicates the memory below the 16MB level adapters setting has been overridden by SG_SET_FORCE_LOW_DMA,1 . SG_GET_SCSI_ID +: -Assumes 3rd argument is pointing to an object of type Sg_scsi_id and -populates it. That structure contains ints for host_no, channel, -scsi_id, lun and scsi_type. Most of this information is available from -other sources (eg SCSI_IOCTL_GET_IDLUN and SCSI_IOCTL_GET_BUS_NUMBER) -but tends to be awkward to collect. +Assumes 3rd argument is pointing to an object of type Sg_scsi_id (see +sg.h) and populates it. That structure contains ints for host_no, +channel, scsi_id, lun and scsi_type. Most of this information is +available from other sources (eg SCSI_IOCTL_GET_IDLUN and +SCSI_IOCTL_GET_BUS_NUMBER) but tends to be awkward to collect. SG_SET_FORCE_PACK_ID +: Assumes 3rd argument is pointing to an int. 0 (default) instructs read() @@ -486,9 +482,9 @@ waiting to be read (when command queuing is being used). oldest packet matching that pack_id or wait until it arrives (or yield EAGAIN if O_NONBLOCK is in force). As a special case the pack_id of -1 given to read() in the mode will match the oldest packet. -Only the current file descriptor is effected by this command. +Only the current file descriptor is affected by this command. -SG_GET_LOW_DMA +: +SG_GET_PACK_ID +: Assumes 3rd argument points to an int and places the pack_id of the oldest (written) packet in it. If no packet is waiting to be read then yields -1. @@ -503,30 +499,33 @@ scatter gather elements supported by the host adapter. 0 indicates that the adapter does support scatter gather. SG_SET_RESERVED_SIZE +W: -This is not currently implemented. It is intended for reserving either a -large buffer or scatter gather list that will be available until the -current file descriptor is closed. The requested amount of memory may -not be available so SG_GET_RESERVED_SIZE should be used after this call -to see how much was reserved. (EBUSY error possible) +Assumes 3rd argument is pointing to an int. That value will be used to +request a new reserved buffer of that size. The previous reserved buffer +is freed (if it is not in use; if it was in use -EBUSY is returned). +A new reserved buffer is then allocated and its actual size can be found by +calling the SG_GET_RESERVED_SIZE ioctl(). The reserved buffer is then used +for DMA purposes by subsequent write() commands if it is not already in +use and if the write() is not calling for a buffer size larger than that +reserved. The reserved buffer may well be a series of kernel buffers if the +adapter supports scatter-gather. Large buffers can be requested (eg 1 MB). SG_GET_RESERVED_SIZE +: Assumes 3rd argument points to an int and places the size in bytes of -the DMA buffer reserved on open() for emergencies. If this is 0 then it -is probably not wise to attempt on operation like burning a CD on this -file descriptor. +the reserved buffer from open() or the most recent SG_SET_RESERVED_SIZE +ioctl() call on this fd. The result can be 0 if memory is very tight. In +this case it may not be wise to attempt something like burning a CD on +this file descriptor. SG_SET_MERGE_FD +W: Assumes 3rd argument is pointing to an int. 0 (the default) causes all subsequent sequencing to be per file descriptor. 1 causes all subsequent sequencing to be per device. If this command tries to change the current -state and the is one or more _other_ file descriptors using this sg -device then an EBUSY error occurs. Also if this file descriptor was not -open()ed with the O_RDWR flag then an EACCES error occurs. -Per device sequencing was the original semantics and allowed, for example -different processes to "share" the device, one perhaps write()ing with -the other one read()ing. This command is supplied if anyone needs those -semantics. Per file descriptor sequencing, perhaps with the usage of -the O_EXCL flag, seems more sensible. +state and there is one or more _other_ file descriptors using this sg +device then an EBUSY error occurs. Per device sequencing was the original +semantics and allowed, for example different processes to "share" the +device, one perhaps write()ing with the other one read()ing. This command +is supplied if anyone needs those semantics. Per file descriptor +sequencing, perhaps with the use of the O_EXCL flag, seems more sensible. SG_GET_MERGE_FD +: Assumes 3rd argument points to an int and places 0 or 1 in it. 0 implies @@ -538,14 +537,42 @@ Assumes 3rd argument is pointing to an int. 0 (current default, set by SG_DEF_COMMAND_Q in sg.h) disables command queuing. Attempts to write() a packet while one is already queued will result in a EDOM error. 1 turns command queuing on. -Changing the queuing state only effects write()s done after the change. -Only the current file descriptor is effected by this command. +Changing the queuing state only affects write()s done after the change. +Only the current file descriptor is affected by this command. SG_GET_COMMAND_Q +: Assumes 3rd argument points to an int and places 0 or 1 in it. 0 implies that command queuing is off on this file descriptor. 1 implies command queuing is on. +SG_SET_UNDERRUN_FLAG +: +Assumes 3rd argument is pointing to an int. 0 (current default, set by +SG_DEF_UNDERRUN_FLAG in sg.h) requests underruns be ignored. 1 requests +that underruns be flagged. [The only low level driver that acts on this +at the moment is the aic7xxx which yields a DID_ERROR error on underrun.] +Only the current file descriptor is affected by this command (unless +"per device" sequencing has been selected). + +SG_GET_UNDERRUN_FLAG +: +Assumes 3rd argument points to an int and places 0 or 1 in it. 0 implies +that underruns are not being reported. 1 implies that underruns are being +reported (see SG_SET_UNDERRUN_FLAG for more details). + +SG_NEXT_CMD_LEN +: +Assumes 3rd argument is pointing to an int. The value of the int (if > 0) +will be used as the SCSI command length of the next SCSI command sent to +a write() on this fd. After that write() the SCSI command length logic is +reset to use automatic length detection (ie depending on SCSI command group +and the 'twelve_byte' field). If the current SCSI command length maximum of +12 is exceeded then the affected write() will yield an EDOM error. +Giving this ioctl() a value of 0 will set automatic length detection for +the next write(). N.B. Only the following write() on this fd is affected by +this ioctl(). + +SG_GET_VERSION_NUM +: +Assumes 3rd argument points to an int. The version number is then placed +in that int. A sg version such as 2.1.34 will yield "20134" from this ioctl. + SG_SET_DEBUG +: Assumes 3rd argument is pointing to an int. 0 (default) turns debugging off. Values > 0 cause the SCSI sense buffer to be decoded and output @@ -556,73 +583,53 @@ If you need a _lot_ of the SCSI sub-system debug information (mainly from the mid-level) then try 'echo "scsi dump 0" > /proc/scsi/scsi' and lots of debug will appear in your console/log. -ioctl (in common with sd, st + sr) ----------------------------------- -The following ioctl()s can be called from any high-level scsi device -driver (ie sd, st, sr + sg). Access permissions may differ a bit from -one device to another, the access information given below is specific to -the sg device driver. - -SCSI_IOCTL_GET_IDLUN: -SCSI_IOCTL_GET_BUS_NUMBER: - -SCSI_IOCTL_SEND_COMMAND: W -If open()ed O_RDONLY yields an EACCESS error. Otherwise is forwarded onto -the SCSI mid-level driver for processing. -Don't know much about this one but it looks pretty powerful and -dangerous. Some comments says it is also deprecated. -<any_command_not matching_above>: W -If open()ed O_RDONLY yields an EACCESS error. Otherwise is forwarded onto -the SCSI mid-level driver for processing. - - -poll ----- +poll(struct pollfd * udfds, unsigned int nfds, int timeout_ms) +-------------------------------------------------------------- This is a native call in Linux 2.2 but most of its capabilities are available through the older select() call. Given a choice poll() should probably be used. Typically poll() is used when a sg scsi device is open()ed O_NONBLOCK -for polling; or alternatively with asynchronous notification using the -fcntl() system call (below) and the SIGPOLL (aka SIGIO) signal. +for polling; and optionally with asynchronous notification as well using +the fcntl() system call (below) and the SIGPOLL (aka SIGIO) signal. Only if something drastically is wrong (eg file handle gone stale) will POLLERR ever be set. POLLPRI, POLLHUP and POLLNVAL are never set. POLLIN is set when there is one or more packets waiting to be read. -When POLLIN is set it implies that a read() will not block (or yield +When POLLIN is set it implies that a read() will not block (nor yield EAGAIN in non-blocking mode) but return a packet immediately. POLLOUT (aka POLLWRNORM) is set when write() is able to accept a packet -(ie will _not_ yield an EDOM error). The setting of POLLOUT is effected +(ie will _not_ yield an EDOM error). The setting of POLLOUT is affected by the SG_SET_COMMAND_Q state: if the state is on then POLLOUT will remain set until the number of queued packets reaches SG_MAX_QUEUE, if the state is off then POLLOUT is only set when no packets are queued. Note that a packet can be queued after write()ing but not available to be read(); this typically happens when a SCSI read command is issued while -the data is being retreaved. +the data is being retrieved. Poll() is per file descriptor unless SG_SET_MERGE_FD is set in which case it is per device. -fcntl ------ +fcntl(int sg_fd, int cmd) or fcntl(int sg_fd, int cmd, long arg) +---------------------------------------------------------------- There are several uses for this system call in association with a sg -file descriptor. The first pseudo code shows code that is useful for +file descriptor. The following pseudo code shows code that is useful for scanning the sg devices, taking care not to be caught in a wait for an O_EXCL lock by another process, and when the appropriate device is -found switching to normal blocked io. A working example of this logic -is in the sg_scan.c utility program. +found, switching to normal blocked io. A working example of this logic +is in the sg_scan utility program. open("/dev/sga", O_RDONLY | O_NONBLOCK) /* check device, EBUSY means some other process has O_EXCL lock on it */ -/* one the device you want is found then ... */ +/* when the device you want is found then ... */ flags = fcntl(sg_fd, F_GETFL) fcntl(sg_fd, F_SETFL, flags & (~ O_NONBLOCK)) -/* for simple apps is is easier to use normal blocked io */ +/* since, for simple apps, it is easier to use normal blocked io */ Some work has to be done in Linux to set up for asynchronous notification. -This is a non-blocking mode of operation in which when the driver receives +This is a non-blocking mode of operation in which, when the driver receives data back from a device so that a read() can be done, it sends a SIGPOLL (aka SIGIO) signal to the owning process. A working example of this logic -is in the sg_poll.c test program. +is in the sg_poll test program. sigemptyset(&sig_set) sigaddset(&sig_set, SIGPOLL) @@ -634,3 +641,91 @@ fcntl(sg_fd, F_SETFL, flags | O_ASYNC) Utility and Test Programs ========================= +See the README file in the sg_utils<date>.tgz tarball. At the time of +writing this was sg_utils990527.tgz . + +Briefly, that tarball contains the following utilities: +sg_dd512 'dd' like program that assumes 512 byte blocks size +sg_dd2048 'dd' like program that assumes 2048 byte blocks size +sgq_dd512 like 'sg_dd512' but does command queuing on "if" +sg_scan outputs information (optionally Inquiry) on SCSI devices +sg_rbuf tests SCSI bus transfer speed (without physical IO) +sg_whoami outputs info (optionally capacity) of given SCSI device +sginfo outputs "mode" information about SCSI devices (it is a + re-port of the scsiinfo program onto the sg interface) + +It also contains the following test programs: +sg_debug outputs sg driver state to console/log file +sg_poll tests asynchronous notification +sg_inquiry does a SCSI Inquiry command (from original HOWTO) +sg_tst_med checks presence of media (from original HOWTO) + +There are also 2 source files (sg_err.[hc]) for outputting and categorizing +SCSI 2 errors and warnings. This code is used by most of the above +utility and test programs. + +The following programs: sg_dd512, sg_dd2048, sg_scan, sg_rbuf, sg_tst_med, +sg_inquiry and sginfo, can be compiled either for this new sg driver _or_ +the original sg driver. + + +Header files +============ +User applications need to find the correct "sg.h" header file matching +their kernel in order to write code using the sg device driver. This is +sometimes more difficult than it should be. The correct "sg.h" will usually +be found at /usr/src/linux/include/scsi/sg.h . Another important header +file is "scsi.h" which will be in the same directory. + +Several distributions have taken their own copies of these files and placed +them in /usr/include/scsi which is where "#include <scsi/sg.h>" would go +looking. The directory /usr/include/scsi _should_ be a symbolic link to +/usr/src/linux/include/scsi/ . It was is Redhat 5.1 and 5.2 but it is +not is Redhat 6.0 . Some other distributions have the same problem. To +solve this (as root) do the following: + +# cd /usr/include +# mv scsi scsi_orig +# ln -s ../src/linux/include/scsi scsi + +This doesn't seem to be a problem with /usr/include/linux (at least in +Redhat where it is a symbolic link) so it is hard to understand why +/usr/include/scsi is defined the way it is. The fact the +/usr/include/linux is a symbolic link opens up the following solution +proposed by the author of cdparanoia (Monty): +#include <linux/../scsi/sg.h> + + +Extra information in scsi-generic_long.txt +========================================== +This document is an abridged form of a more comprehensive document called +scsi-generic_long.txt (see www.torque.net/sg/p/scsi-generic_long.txt). + +The longer document contains additional sections on: + - memory issues + - ioctl()s in common with sd, st + sr + - distinguishing the original from the new driver + - SG_BIG_BUFF and friends + - shortcomings + - future directions + - an appendix with some SCSI 2 information in it + + +Conclusion +========== +The SCSI generic packet device driver attempts to make as few assumptions +as possible about the device it is connected to while giving applications +using it as much flexibility as possible on the SCSI command level. Sg +needs to hide the "messy" kernel related details while protecting +the integrity of the kernel against sg "abuse". Some of these aims are +contradictory and some compromises need to be made. For example: should +a sg based application be able to reset a SCSI bus when that could cause +collateral damage to a disk holding the root file system? There is no +easy answer to this and many other related questions. + +If you have any suggestion about sg (or improving (the accuracy of) this +document) please contact me. + + +Douglas Gilbert +dgilbert@interlog.com diff --git a/Documentation/serial-console.txt b/Documentation/serial-console.txt index 2894b8008..5b4168833 100644 --- a/Documentation/serial-console.txt +++ b/Documentation/serial-console.txt @@ -87,7 +87,7 @@ Replace the sample values as needed. 6. Thanks - Thanks to Geert Uytterhoeven <Geert.Uytterhoeven@cs.kuleuven.ac.be> + Thanks to Geert Uytterhoeven <geert@linux-m68k.org> for porting the patches from 2.1.4x to 2.1.6x for taking care of the integration of these patches into m68k, ppc and alpha. diff --git a/Documentation/smart-config.txt b/Documentation/smart-config.txt index b31d252fa..c9bed4cf8 100644 --- a/Documentation/smart-config.txt +++ b/Documentation/smart-config.txt @@ -1,5 +1,5 @@ Smart CONFIG_* Dependencies -Fri 2 Dec 1997 +1 August 1999 Michael Chastain <mec@shout.net> Werner Almesberger <almesber@lrc.di.epfl.ch> @@ -44,22 +44,21 @@ Here is the solution: It now generates these dependencies: drivers/net/foo.c: \ - include/config/foo_autofrob.h \ - include/config/foo_model_two.h + include/config/foo/autofrob.h \ + include/config/foo/model/two.h So drivers/net/foo.c depends only on the CONFIG_* lines that it actually uses. - A new program, split-include.c, runs at the end of make config (also - make oldconfig, make menuconfig, and make xconfig). split-include - reads include/linux/autoconf.h and updates the include/linux/*.h - directory, writing one file per option. It updates only the files - that changed. + A new program, split-include.c, runs at the beginning of + compilation (make bzImage or make zImage). split-include reads + include/linux/autoconf.h and updates the include/config/ tree, + writing one file per option. It updates only the files for options + that have changed. - mkdep.c also generates much better warning messages for missing - or unneeded <linux/config.h> lines. In fact, you can get these - messages without generating dependencies with the new top-level - target 'make checkconfig'. + mkdep.c no longer generates warning messages for missing or unneeded + <linux/config.h> lines. The new top-level target 'make checkconfig' + checks for these problems. Flag Dependencies @@ -68,12 +67,14 @@ Flag Dependencies the compilation flags used to build it. The file foo.o has its flags stored in .flags.foo.o. - Suppose the user changes the foo driver from resident to - modular, 'make' will notice that the foo.o was not compiled - with -DMODULE and will recompile foo.c. + Suppose the user changes the foo driver from resident to modular. + 'make' will notice that the current foo.o was not compiled with + -DMODULE and will recompile foo.c. - All .a and .o files made from C source or with 'ld' or 'ar' - have flag dependencies. .S files do not have flag dependencies. + All .o files made from C source have flag dependencies. So do .o + files made with ld, and .a files made with ar. However, .o files + made from assembly source do not have flag dependencies (nobody + needs this yet, but it would be good to fix). Per-source-file Flags @@ -92,8 +93,8 @@ Credit version of this patch. Michael Chastain picked it up and continued development. He is - now the principal author and maintainer. Report bugs to him, - or to all three people together. + now the principal author and maintainer. Please report any bugs + to him. Martin von Loewis wrote flag dependencies, with some modifications by Michael Chastain. diff --git a/Documentation/sound/AWE32 b/Documentation/sound/AWE32 index 40d655755..edc0b880e 100644 --- a/Documentation/sound/AWE32 +++ b/Documentation/sound/AWE32 @@ -85,7 +85,6 @@ http://members.xoom.com/yar/synthgm.sbk.gz. Copy it to /usr and gunzip it there. 7) Edit /etc/conf.modules, inserting at the end of the file: -alias sound sb alias midi awe_wave post-install awe_wave /usr/bin/sfxload /usr/synthfm.sbk options sb io=0x220 irq=5 dma=1 dma16=5 mpu_io=0x330 diff --git a/Documentation/sound/MAD16 b/Documentation/sound/MAD16 index 6f5f65167..8dda947f0 100644 --- a/Documentation/sound/MAD16 +++ b/Documentation/sound/MAD16 @@ -32,3 +32,22 @@ options sb mad16=1 options mad16 io=0x530 irq=7 dma=0 dma16=1 mpu_io=816 mpu_irq=5 && /usr/local/bin/aumix -w 15 -p 20 -m 0 -1 0 -2 0 -3 0 -i 0 The addition of the "mpu_io=816 mpu_irq=5" to the mad16 options line is + +------------------------------------------------------------------------ +The mad16 module in addition supports the following options: + +option: meaning: default: +joystick=0,1 disabled, enabled disabled +cdtype=0x00,0x02,0x04, disabled, Sony CDU31A, disabled + 0x06,0x08,0x0a Mitsumi, Panasonic, + Secondary IDE, Primary IDE +cdport=0x340,0x320, 0x340 + 0x330,0x360 +cdirq=0,3,5,7,9,10,11 disabled, IRQ3, ... disabled +cddma=0,5,6,7 disabled, DMA5, ... DMA5 for Mitsumi or IDE +cddma=0,1,2,3 disabled, DMA1, ... DMA3 for Sony or Panasonic +opl4=0,1 OPL3, OPL4 OPL3 + +for more details see linux/drivers/sound/mad16.c + +Rui Sousa diff --git a/Documentation/sound/NM256 b/Documentation/sound/NM256 new file mode 100644 index 000000000..edff4c1b4 --- /dev/null +++ b/Documentation/sound/NM256 @@ -0,0 +1,229 @@ +======================================================= +Documentation for the NeoMagic 256AV/256ZX sound driver +======================================================= + +You're looking at version 1.0 of the driver. (Woohoo!) It has been +successfully tested against the following laptop models: + + Sony Z505S/Z505SX/Z505DX + Sony F150, F160, F180, F250, F270, F280, PCG-F26 + Dell Latitude CPi, CPt (various submodels) + +There are a few caveats, which is why you should read the entirety of +this document first. + +This driver was developed without any support or assistance from +NeoMagic. There is no warranty, expressed, implied, or otherwise. It +is free software in the public domain; feel free to use it, sell it, +give it to your best friends, even claim that you wrote it (but why?!) +but don't come whining to me, NeoMagic, Sony, Dell, or anyone else +when it blows up your computer. + +============ +Installation +============ + +Enable the sound drivers, the OSS sound drivers, and then the NM256 +driver. The NM256 driver *must* be configured as a module (it won't +give you any other choice). + +Next, do the usual "make modules" and "make modules_install". +Finally, insmod the soundcore, sound and nm256 modules. + +When the nm256 driver module is loaded, you should see a couple of +confirmation messages in the kernel logfile indicating that it found +the device (the device does *not* use any I/O ports or DMA channels). +Now try playing a wav file, futz with the CD-ROM if you have one, etc. + +The NM256 is entirely a PCI-based device, and all the necessary +information is automatically obtained from the card. It can only be +configured as a module in a vain attempt to prevent people from +hurting themselves. It works correctly if it shares an IRQ with +another device (it normally shares IRQ 9 with the builtin eepro100 +ethernet on the Sony Z505 laptops). + +It does not run the card in any sort of compatibility mode. Thus it +almost certainly will not work on laptops that have the +SB16-compatible codec/mixer; you will want to use the standard SB16 +OSS driver with these chipsets. I cannot provide any assistance with +machines using the SB-16 compatible version. + +The sound support is very basic, but it does include simultaneous +playback and record capability. The mixer support is also quite +simple, although this is in keeping with the rather limited +functionality of the chipset. + +There is no hardware synthesizer available, as the Losedows OPL-3 and +MIDI support is done via hardware emulation. + +Only three recording devices are available on the Sony: the +microphone, the CD-ROM input, and the volume device (which corresponds +to the stereo output). (Other devices may be available on other +models of laptops.) The Z505 series does not have a builtin CD-ROM, +so of course the CD-ROM input doesn't work. It does work on laptops +with a builtin CD-ROM drive. + +Recording is mono 8-bit only. + +The mixer device does not appear to have any tone controls, at least +on the Z505 series. The mixer module checks for tone controls in the +AC97 mixer, and will enable them if they are available. + +============== +Known problems +============== + + * There are known problems with PCMCIA cards and the eepro100 ethernet + driver on the Z505S/Z505SX/Z505DX. Keep reading. + + * There are also potential problems with using a virtual X display, and + also problems loading the module after the X server has been started. + Keep reading. + + * The volume control isn't anywhere near linear. Sorry. This will be + fixed eventually, when I get sufficiently annoyed with it. (I doubt + it will ever be fixed now, since I've never gotten sufficiently + annoyed with it and nobody else seems to care.) + + * There are reports that the CD-ROM volume is very low. Since I do not + have a CD-ROM equipped laptop, I cannot test this (it's kinda hard to + do remotely). + + * Only 8 fixed-rate speeds are supported. This is mainly a chipset + limitation. It may be possible to support other speeds in the future. + + * There is no support for the telephone mixer/codec. There is support + for a phonein/phoneout device if your mixer program supports it; + whether or not it does anything is anyone's guess. (Reports on this + would be appreciated.) + + * This driver was not written with any cooperation or support from + NeoMagic. If you have any questions about this, see their website + for their official stance on supporting open source drivers. + +============ +Video memory +============ + +The NeoMagic sound engine uses a portion of the display memory to hold +the sound buffer. (Crazy, eh?) The NeoMagic video BIOS sets up a +special pointer at the top of video RAM to indicate where the top of +the audio buffer should be placed. + +At the present time XFree86 is apparently not aware of this. It will +thus write over either the pointer or the sound buffer with abandon. +(Accelerated-X seems to do a better job here.) + +This implies a few things: + + * Sometimes the NM256 driver has to guess at where the buffer + should be placed, especially if the module is loaded after the + X server is started. It's usually correct, but it will fail on + the Sony F250. + + * Virtual screens greater than 1024x768x16 under XFree86 are + problematic on laptops with only 2.5MB of screen RAM. This + includes all of the 256AV-equipped laptops. (Virtual displays + may or may not work on the 256ZX, which has at least 4MB of + video RAM.) + +If you start having problems with random noise being output either +constantly (this is the usual symptom on the F250), or when windows +are moved around (this is the usual symptom when using a virtual +screen), the best fix is to + + * Don't use a virtual frame buffer. + * Make sure you load the NM256 module before the X server is + started. + +On the F250, it is possible to force the driver to load properly even +after the XFree86 server is started by doing: + + insmod nm256.o buffertop=0x25a800 + +This forces the audio buffers to the correct offset in screen RAM. + +================= +Official WWW site +================= + +The official site for the NM256 driver is: + + http://www.uglx.org/sony.html + +You should always be able to get the latest version of the driver there, +and the driver will be supported for the foreseeable future. + +============================== +Z505S/Z505SX on-board Ethernet +============================== + +If you're using the on-board Ethernet Pro/100 ethernet support on the Z505 +series, I strongly encourage you to download the latest eepro100 driver from +Donald Becker's site: + + ftp://cesdis.gsfc.nasa.gov/pub/linux/drivers/test/eepro100.c + +There was a reported problem on the Z505SX that if the ethernet +interface is disabled and reenabled while the sound driver is loaded, +the machine would lock up. I have included a workaround that is +working satisfactorily. However, you may occasionally see a message +about "Releasing interrupts, over 1000 bad interrupts" which indicates +that the workaround is doing its job. + +================================== +PCMCIA and the Z505S/Z505SX/Z505DX +================================== + +There is also a known problem with the Sony Z505S and Z505SX hanging +if a PCMCIA card is inserted while the ethernet driver is loaded. +This is caused by tons of spurious IRQ 9s, probably generated from the +PCMCIA or ACPI bridges. There is currently no fix for the problem, +and the only known workaround is to disable the ethernet interface +before inserting or removing a PCMCIA card. + +====== +Thanks +====== + +First, I want to thank everyone (except NeoMagic of course) for their +generous support and encouragement. I'd like to list everyone's name +here that replied during the development phase, but the list is +amazingly long. + +I will be rather unfair and single out a few people, however: + + Justin Maurer, for being the first random net.person to try it, + and for letting me login to his Z505SX to get it working there + + Edi Weitz for trying out several different versions, and giving + me a lot of useful feedback + + Greg Rumple for letting me login remotely to get the driver + functional on the 256ZX, for his assistance on tracking + down all sorts of random stuff, and for trying out Accel-X + + Zach Brown, for the initial AC97 mixer interface design + + Jeff Garzik, for various helpful suggestions on the AC97 + interface + +================= +Previous versions +================= + +Versions prior to 0.3 (aka `noname') had problems with weird artifacts +in the output and failed to set the recording rate properly. These +problems have long since been fixed. + +Versions prior to 0.5 had problems with clicks in the output when +anything other than 16-bit stereo sound was being played, and also had +periodic clicks when recording. + +Version 0.7 first incorporated support for the NM256ZX chipset, which +is found on some Dell Latitude laptops (the CPt, and apparently +some CPi models as well). It also included the generic AC97 +mixer module. + +Version 0.75 renamed all the functions and files with slightly more +generic names. diff --git a/Documentation/sound/solo1 b/Documentation/sound/solo1 new file mode 100644 index 000000000..1c0a641b0 --- /dev/null +++ b/Documentation/sound/solo1 @@ -0,0 +1,48 @@ +ALaw/uLaw sample formats +------------------------ + +This driver does not support the ALaw/uLaw sample formats. +ALaw is the default mode when opening a sound device +using OSS/Free. The reason for the lack of support is +that the hardware does not support these formats, and adding +conversion routines to the kernel would lead to very ugly +code in the presence of the mmap interface to the driver. +And since xquake uses mmap, mmap is considered important :-) +and no sane application uses ALaw/uLaw these days anyway. +In short, playing a Sun .au file as follows: + +cat my_file.au > /dev/dsp + +does not work. Instead, you may use the play script from +Chris Bagwell's sox-12.14 package (or later, available from the URL +below) to play many different audio file formats. +The script automatically determines the audio format +and does do audio conversions if necessary. +http://home.sprynet.com/sprynet/cbagwell/projects.html + + +Blocking vs. nonblocking IO +--------------------------- + +Unlike OSS/Free this driver honours the O_NONBLOCK file flag +not only during open, but also during read and write. +This is an effort to make the sound driver interface more +regular. Timidity has problems with this; a patch +is available from http://www.ife.ee.ethz.ch/~sailer/linux/pciaudio.html. +(Timidity patched will also run on OSS/Free). + + +MIDI UART +--------- + +The driver supports a simple MIDI UART interface, with +no ioctl's supported. + + +MIDI synthesizer +---------------- + +The card has an OPL compatible FM synthesizer. + +Thomas Sailer +sailer@ife.ee.ethz.ch diff --git a/Documentation/sound/vwsnd b/Documentation/sound/vwsnd new file mode 100644 index 000000000..a6ea0a1df --- /dev/null +++ b/Documentation/sound/vwsnd @@ -0,0 +1,293 @@ +vwsnd - Sound driver for the Silicon Graphics 320 and 540 Visual +Workstations' onboard audio. + +Copyright 1999 Silicon Graphics, Inc. All rights reserved. + + +At the time of this writing, March 1999, there are two models of +Visual Workstation, the 320 and the 540. This document only describes +those models. Future Visual Workstation models may have different +sound capabilities, and this driver will probably not work on those +boxes. + +The Visual Workstation has an Analog Devices AD1843 "SoundComm" audio +codec chip. The AD1843 is accessed through the Cobalt I/O ASIC, also +known as Lithium. This driver programs both both chips. + +============================================================================== +QUICK CONFIGURATION + + # insmod soundcore + # insmod vwsnd + +============================================================================== +I/O CONNECTIONS + +On the Visual Workstation, only three of the AD1843 inputs are hooked +up. The analog line in jacks are connected to the AD1843's AUX1 +input. The CD audio lines are connected to the AD1843's AUX2 input. +The microphone jack is connected to the AD1843's MIC input. The mic +jack is mono, but the signal is delivered to both the left and right +MIC inputs. You can record in stereo from the mic input, but you will +get the same signal on both channels (within the limits of A/D +accuracy). Full scale on the Line input is +/- 2.0 V. Full scale on +the MIC input is 20 dB less, or +/- 0.2 V. + +The AD1843's LOUT1 outputs are connected to the Line Out jacks. The +AD1843's HPOUT outputs are connected to the speaker/headphone jack. +LOUT2 is not connected. Line out's maximum level is +/- 2.0 V peak to +peak. The speaker/headphone out's maximum is +/- 4.0 V peak to peak. + +The AD1843's PCM input channel and one of its output channels (DAC1) +are connected to Lithium. The other output channel (DAC2) is not +connected. + +============================================================================== +CAPABILITIES + +The AD1843 has PCM input and output (Pulse Code Modulation, also known +as wavetable). PCM input and output can be mono or stereo in any of +four formats. The formats are 16 bit signed and 8 bit unsigned, +u-Law, and A-Law format. Any sample rate from 4 KHz to 49 KHz is +available, in 1 Hz increments. + +The AD1843 includes an analog mixer that can mix all three input +signals (line, mic and CD) into the analog outputs. The mixer has a +separate gain control and mute switch for each input. + +There are two outputs, line out and speaker/headphone out. They +always produce the same signal, and the speaker always has 3 dB more +gain than the line out. The speaker/headphone output can be muted, +but this driver does not export that function. + +The hardware can sync audio to the video clock, but this driver does +not have a way to specify syncing to video. + +============================================================================== +PROGRAMMING + +This section explains the API supported by the driver. Also see the +Open Sound Programming Guide at http://www.opensound.com/pguide/ . +This section assumes familiarity with that document. + +The driver has two interfaces, an I/O interface and a mixer interface. +There is no MIDI or sequencer capability. + +============================================================================== +PROGRAMMING PCM I/O + +The I/O interface is usually accessed as /dev/audio or /dev/dsp. +Using the standard Open Sound System (OSS) ioctl calls, the sample +rate, number of channels, and sample format may be set within the +limitations described above. The driver supports triggering. It also +supports getting the input and output pointers with one-sample +accuracy. + +The SNDCTL_DSP_GETCAP ioctl returns these capabilities. + + DSP_CAP_DUPLEX - driver supports full duplex. + + DSP_CAP_TRIGGER - driver supports triggering. + + DSP_CAP_REALTIME - values returned by SNDCTL_DSP_GETIPTR + and SNDCTL_DSP_GETOPTR are accurate to a few samples. + +Memory mapping (mmap) is not implemented. + +The driver permits subdivided fragment sizes from 64 to 4096 bytes. +The number of fragments can be anything from 3 fragments to however +many fragments fit into 124 kilobytes. It is up to the user to +determine how few/small fragments can be used without introducing +glitches with a given workload. Linux is not realtime, so we can't +promise anything. (sigh...) + +When this driver is switched into or out of mu-Law or A-Law mode on +output, it may produce an audible click. This is unavoidable. To +prevent clicking, use signed 16-bit mode instead, and convert from +mu-Law or A-Law format in software. + +============================================================================== +PROGRAMMING THE MIXER INTERFACE + +The mixer interface is usually accessed as /dev/mixer. It is accessed +through ioctls. The mixer allows the application to control gain or +mute several audio signal paths, and also allows selection of the +recording source. + +Each of the constants described here can be read using the +MIXER_READ(SOUND_MIXER_xxx) ioctl. Those that are not read-only can +also be written using the MIXER_WRITE(SOUND_MIXER_xxx) ioctl. In most +cases, <sys/soundcard.h> defines constants SOUND_MIXER_READ_xxx and +SOUND_MIXER_WRITE_xxx which work just as well. + +SOUND_MIXER_CAPS Read-only + +This is a mask of optional driver capabilities that are implemented. +This driver's only capability is SOUND_CAP_EXCL_INPUT, which means +that only one recording source can be active at a time. + +SOUND_MIXER_DEVMASK Read-only + +This is a mask of the sound channels. This driver's channels are PCM, +LINE, MIC, CD, and RECLEV. + +SOUND_MIXER_STEREODEVS Read-only + +This is a mask of which sound channels are capable of stereo. All +channels are capable of stereo. (But see caveat on MIC input in I/O +CONNECTIONS section above). + +SOUND_MIXER_OUTMASK Read-only + +This is a mask of channels that route inputs through to outputs. +Those are LINE, MIC, and CD. + +SOUND_MIXER_RECMASK Read-only + +This is a mask of channels that can be recording sources. Those are +PCM, LINE, MIC, CD. + +SOUND_MIXER_PCM Default: 0x5757 (0 dB) + +This is the gain control for PCM output. The left and right channel +gain are controlled independently. This gain control has 64 levels, +which range from -82.5 dB to +12.0 dB in 1.5 dB steps. Those 64 +levels are mapped onto 100 levels at the ioctl, see below. + +SOUND_MIXER_LINE Default: 0x4a4a (0 dB) + +This is the gain control for mixing the Line In source into the +outputs. The left and right channel gain are controlled +independently. This gain control has 32 levels, which range from +-34.5 dB to +12.0 dB in 1.5 dB steps. Those 32 levels are mapped onto +100 levels at the ioctl, see below. + +SOUND_MIXER_MIC Default: 0x4a4a (0 dB) + +This is the gain control for mixing the MIC source into the outputs. +The left and right channel gain are controlled independently. This +gain control has 32 levels, which range from -34.5 dB to +12.0 dB in +1.5 dB steps. Those 32 levels are mapped onto 100 levels at the +ioctl, see below. + +SOUND_MIXER_CD Default: 0x4a4a (0 dB) + +This is the gain control for mixing the CD audio source into the +outputs. The left and right channel gain are controlled +independently. This gain control has 32 levels, which range from +-34.5 dB to +12.0 dB in 1.5 dB steps. Those 32 levels are mapped onto +100 levels at the ioctl, see below. + +SOUND_MIXER_RECLEV Default: 0 (0 dB) + +This is the gain control for PCM input (RECording LEVel). The left +and right channel gain are controlled independently. This gain +control has 16 levels, which range from 0 dB to +22.5 dB in 1.5 dB +steps. Those 16 levels are mapped onto 100 levels at the ioctl, see +below. + +SOUND_MIXER_RECSRC Default: SOUND_MASK_LINE + +This is a mask of currently selected PCM input sources (RECording +SouRCes). Because the AD1843 can only have a single recording source +at a time, only one bit at a time can be set in this mask. The +allowable values are SOUND_MASK_PCM, SOUND_MASK_LINE, SOUND_MASK_MIC, +or SOUND_MASK_CD. Selecting SOUND_MASK_PCM sets up internal +resampling which is useful for loopback testing and for hardware +sample rate conversion. But software sample rate conversion is +probably faster, so I don't know how useful that is. + +SOUND_MIXER_OUTSRC DEFAULT: SOUND_MASK_LINE|SOUND_MASK_MIC|SOUND_MASK_CD + +This is a mask of sources that are currently passed through to the +outputs. Those sources whose bits are not set are muted. + +============================================================================== +GAIN CONTROL + +There are five gain controls listed above. Each has 16, 32, or 64 +steps. Each control has 1.5 dB of gain per step. Each control is +stereo. + +The OSS defines the argument to a channel gain ioctl as having two +components, left and right, each of which ranges from 0 to 100. The +two components are packed into the same word, with the left side gain +in the least significant byte, and the right side gain in the second +least significant byte. In C, we would say this. + + #include <assert.h> + + ... + + assert(leftgain >= 0 && leftgain <= 100); + assert(rightgain >= 0 && rightgain <= 100); + arg = leftgain | rightgain << 8; + +So each OSS gain control has 101 steps. But the hardware has 16, 32, +or 64 steps. The hardware steps are spread across the 101 OSS steps +nearly evenly. The conversion formulas are like this, given N equals +16, 32, or 64. + + int round = N/2 - 1; + OSS_gain_steps = (hw_gain_steps * 100 + round) / (N - 1); + hw_gain_steps = (OSS_gain_steps * (N - 1) + round) / 100; + +Here is a snippet of C code that will return the left and right gain +of any channel in dB. Pass it one of the predefined gain_desc_t +structures to access any of the five channels' gains. + + typedef struct gain_desc { + float min_gain; + float gain_step; + int nbits; + int chan; + } gain_desc_t; + + const gain_desc_t gain_pcm = { -82.5, 1.5, 6, SOUND_MIXER_PCM }; + const gain_desc_t gain_line = { -34.5, 1.5, 5, SOUND_MIXER_LINE }; + const gain_desc_t gain_mic = { -34.5, 1.5, 5, SOUND_MIXER_MIC }; + const gain_desc_t gain_cd = { -34.5, 1.5, 5, SOUND_MIXER_CD }; + const gain_desc_t gain_reclev = { 0.0, 1.5, 4, SOUND_MIXER_RECLEV }; + + int get_gain_dB(int fd, const gain_desc_t *gp, + float *left, float *right) + { + int word; + int lg, rg; + int mask = (1 << gp->nbits) - 1; + + if (ioctl(fd, MIXER_READ(gp->chan), &word) != 0) + return -1; /* fail */ + lg = word & 0xFF; + rg = word >> 8 & 0xFF; + lg = (lg * mask + mask / 2) / 100; + rg = (rg * mask + mask / 2) / 100; + *left = gp->min_gain + gp->gain_step * lg; + *right = gp->min_gain + gp->gain_step * rg; + return 0; + } + +And here is the corresponding routine to set a channel's gain in dB. + + int set_gain_dB(int fd, const gain_desc_t *gp, float left, float right) + { + float max_gain = + gp->min_gain + (1 << gp->nbits) * gp->gain_step; + float round = gp->gain_step / 2; + int mask = (1 << gp->nbits) - 1; + int word; + int lg, rg; + + if (left < gp->min_gain || right < gp->min_gain) + return EINVAL; + lg = (left - gp->min_gain + round) / gp->gain_step; + rg = (right - gp->min_gain + round) / gp->gain_step; + if (lg >= (1 << gp->nbits) || rg >= (1 << gp->nbits)) + return EINVAL; + lg = (100 * lg + mask / 2) / mask; + rg = (100 * rg + mask / 2) / mask; + word = lg | rg << 8; + + return ioctl(fd, MIXER_WRITE(gp->chan), &word); + } + diff --git a/Documentation/sx.txt b/Documentation/sx.txt new file mode 100644 index 000000000..f924f39bd --- /dev/null +++ b/Documentation/sx.txt @@ -0,0 +1,289 @@ + + sx.txt -- specialix SX/SI multiport serial driver readme. + + + + Copyright (C) 1997 Roger Wolff (R.E.Wolff@BitWizard.nl) + + Specialix pays for the development and support of this driver. + Please DO contact support@specialix.co.uk if you require + support. + + This driver was developed in the BitWizard linux device + driver service. If you require a linux device driver for your + product, please contact devices@BitWizard.nl for a quote. + + (History) + There used to be an SI driver by Simon Allan. This is a complete + rewrite from scratch. Just a few lines-of-code have been snatched. + + (Sources) + Specialix document number 6210028: SX Host Card and Download Code + Software Functional Specification. + + (Copying) + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License as + published by the Free Software Foundation; either version 2 of + the License, or (at your option) any later version. + + This program is distributed in the hope that it will be + useful, but WITHOUT ANY WARRANTY; without even the implied + warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR + PURPOSE. See the GNU General Public License for more details. + + You should have received a copy of the GNU General Public + License along with this program; if not, write to the Free + Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, + USA. + + (Addendum) + I'd appreciate it that if you have fixes, that you send them + to me first. + + +Introduction +============ + +This file contains some random information, that I like to have online +instead of in a manual that can get lost. Ever misplace your Linux +kernel sources? And the manual of one of the boards in your computer? + + +Theory of operation +=================== + +An important thing to know is that the driver itself doesn't have the +firmware for the card. This means that you need the separate package +"sx_firmware". For now you can get the source at + + ftp://ftp.bitwizard.nl/specialix/sx_firmware_<version>.tgz + +The firmware load needs a "misc" device, so you'll need to enable the +"Support for user misc device modules" in your kernel configuration. +The misc device needs to be called "/dev/specialix_sxctl". It needs +misc major 10, and minor number 167 (assigned by HPA). The section +on creating device files below also creates this device. + +After loading the sx.o module into your kernel, the driver will report +the number of cards detected, but because it doesn't have any +firmware, it will not be able to determine the number of ports. Only +when you then run "sx_firmware" will the firmware be downloaded and +the rest of the driver initialized. At that time the sx_firmware +program will report the number of ports installed. + +In contrast with many other multi port serial cards, some of the data +structures are only allocated when the card knows the number of ports +that are connected. This means we won't waste memory for 120 port +descriptor structures when you only have 8 ports. If you experience +problems due to this, please report them: I haven't seen any. + + +Interrupts +========== + +A multi port serial card, would generate a horrendous amount of +interrupts if it would interrupt the CPU for every received +character. Even more than 10 years ago, the trick not to use +interrupts but to poll the serial cards was invented. + +The SX card allow us to do this two ways. First the card limits its +own interrupt rate to a rate that won't overwhelm the CPU. Secondly, +we could forget about the cards interrupt completely and use the +internal timer for this purpose. + +Polling the card can take up to a few percent of your CPU. Using the +interrupts would be better if you have most of the ports idle. Using +timer-based polling is better if your card almost always has work to +do. You save the separate interrupt in that case. + +In any case, it doesn't really matter all that much. + +The most common problem with interrupts is that for ISA cards in a PCI +system the BIOS has to be told to configure that interrupt as "legacy +ISA". Otherwise the card can pull on the interrupt line all it wants +but the CPU won't see this. + +If you can't get the interrupt to work, remember that polling mode is +more efficient (provided you actually use the card intensively). + + +Allowed Configurations +====================== + +Some configurations are disallowed. Even though at a glance they might +seem to work, they are known to lockup the bus between the host card +and the device concentrators. You should respect the drivers decision +not to support certain configurations. It's there for a reason. + +Warning: Seriously technical stuff ahead. Executive summary: Don't use +SX cards except configured at a 64k boundary. Skip the next paragraph. + +The SX cards can theoretically be placed at a 32k boundary. So for +instance you can put an SX card at 0xc8000-0xd7fff. This is not a +"recommended configuration". ISA cards have to tell the bus controller +how they like their timing. Due to timing issues they have to do this +based on which 64k window the address falls into. This means that the +32k window below and above the SX card have to use exactly the same +timing as the SX card. That reportedly works for other SX cards. But +you're still left with two useless 32k windows that should not be used +by anybody else. + + +Configuring the driver +====================== + +PCI cards are always detected. The driver auto-probes for ISA cards at +some sensible addresses. Please report if the auto-probe causes trouble +in your system, or when a card isn't detected. + +I'm afraid I haven't implemented "kernel command line parameters" yet. +This means that if the default doesn't work for you, you shouldn't use +the compiled-into-the-kernel version of the driver. Use a module +instead. If you convince me that you need this, I'll make it for +you. Deal? + +I'm afraid that the module parameters are a bit clumsy. If you have a +better idea, please tell me. + +You can specify several parameters: + + sx_poll: number of jiffies between timer-based polls. + + Set this to "0" to disable timer based polls. + Initialization of cards without a working interrupt + will fail. + + Set this to "1" if you want a polling driver. + (on Intel: 100 polls per second). If you don't use + fast baud rates, you might consider a value like "5". + (If you don't know how to do the math, use 1). + + sx_slowpoll: Number of jiffies between timer-based polls. + Set this to "100" to poll once a second. + This should get the card out of a stall if the driver + ever misses an interrupt. I've never seen this happen, + and if it does, that's a bug. Tell me. + + sx_maxints: Number of interrupts to request from the card. + The card normally limits interrupts to about 100 per + second to offload the host CPU. You can increase this + number to reduce latency on the card a little. + Note that if you give a very high number you can overload + your CPU as well as the CPU on the host card. This setting + is inaccurate and not recommended for SI cards (But it + works). + + sx_irqmask: The mask of allowable IRQs to use. I suggest you set + this to 0 (disable IRQs all together) and use polling if + the assignment of IRQs becomes problematic. + + sx_debug: You can enable different sorts of debug traces with this. + At "-1" all debugging traces are active. You'll get several + times more debugging output than you'll get characters + transmitted. + + +Baud rates +========== + +Theoretically new SXDCs should be capable of more than 460k +baud. However the line drivers usually give up before that. Also the +CPU on the card may not be able to handle 8 channels going at full +blast at that speed. Moreover, the buffers are not large enough to +allow operation with 100 interrupts per second. You'll have to realize +that the card has a 256 byte buffer, so you'll have to increase the +number of interrupts per second if you have more than 256*100 bytes +per second to transmit. If you do any performance testing in this +area, I'd be glad to hear from you... + +(Psst Linux users..... I think the Linux driver is more efficient than +the driver for other OSes. If you can and want to benchmark them +against each other, be my guest, and report your findings...... :-) + + +Ports and devices +================= + +Port 0 is the top connector on the module closest to the host +card. Oh, the ports on the SXDCs and TAs are labelled from 1 to 8 +instead of from 0 to 7, as they are numbered by linux. I'm stubborn in +this: I know for sure that I wouldn't be able to calculate which port +is which anymore if I would change that.... + + +Devices: + +You should make the device files as follows: + +#!/bin/sh +# (I recommend that you cut-and-paste this into a file and run that) +cd /dev +t=0 +mknod specialix_sxctl c 10 167 +while [ $t -lt 64 ] + do + echo -n "$t " + mknod ttyX$t c 32 $t + mknod cux$t c 33 $t + t=`expr $t + 1` +done +echo "" +rm /etc/psdevtab +ps > /dev/null + + +This creates 64 devices. If you have more, increase the constant on +the line with "while". The devices start at 0, as is customary on +Linux. Specialix seems to like starting the numbering at 1. + +If your system doesn't come with these devices pre-installed, bug your +linux-vendor about this. They should have these devices +"pre-installed" before the new millennium. The "ps" stuff at the end +is to "tell" ps that the new devices exist. + +Officially the maximum number of cards per computer is 4. This driver +however supports as many cards in one machine as you want. You'll run +out of interrupts after a few, but you can switch to polled operation +then. At about 256 ports (More than 8 cards), we run out of minor +device numbers. Sorry. I suggest you buy a second computer.... (Or +switch to RIO). + +------------------------------------------------------------------------ + + + Fixed bugs and restrictions: + - Hangup processing. + -- Done. + + - the write path in generic_serial (lockup / oops). + -- Done (Ugly: not the way I want it. Copied from serial.c). + + - write buffer isn't flushed at close. + -- Done. I still seem to loose a few chars at close. + Sorry. I think that this is a firmware issue. (-> Specialix) + + - drain hardware before changing termios + - Change debug on the fly. + - ISA free irq -1. (no firmware loaded). + - adding c8000 as a probe address. Added warning. + - Add a RAMtest for the RAM on the card.c + - Crash when opening a port "way" of the number of allowed ports. + (for example opening port 60 when there are only 24 ports attached) + - Sometimes the use-count strays a bit. After a few hours of + testing the use count is sometimes "3". If you are not like + me and can remember what you did to get it that way, I'd + appreciate an Email. Possibly fixed. Tell me if anyone still + sees this. + - TAs don't work right if you don't connect all the modem control + signals. SXDCs do. T225 firmware problem -> Specialix. + (Mostly fixed now, I think. Tell me if you encounter this!) + + Bugs & restrictions: + + - Arbitrary baud rates. Requires firmware update. (-> Specialix) + + - Low latency (mostly firmware, -> Specialix) + + + diff --git a/Documentation/sysrq.txt b/Documentation/sysrq.txt index 40bce4fd7..ab8676faf 100644 --- a/Documentation/sysrq.txt +++ b/Documentation/sysrq.txt @@ -9,8 +9,8 @@ regardless of whatever else it is doing, unless it is completely locked up. * How do I enable the magic SysRQ key? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -You need to say yes to 'Magic SysRq key (CONFIG_MAGIC_SYSRQ)' when -configuring the kernel. This option is only available it 2.1.x or later +You need to say "yes" to 'Magic SysRq key (CONFIG_MAGIC_SYSRQ)' when +configuring the kernel. This option is only available in 2.1.x or later kernels. * How do I use the magic SysRQ key? diff --git a/Documentation/video4linux/bttv/PROBLEMS b/Documentation/video4linux/bttv/PROBLEMS index 744d1155b..0371d2e74 100644 --- a/Documentation/video4linux/bttv/PROBLEMS +++ b/Documentation/video4linux/bttv/PROBLEMS @@ -59,4 +59,4 @@ - Some S3 cards and the Matrox Mystique will produce pixel errors with full resolution in 32-bit mode. -- Some video cards have problems with Accelerated X 4.1
\ No newline at end of file +- Some video cards have problems with Accelerated X 4.1 diff --git a/Documentation/watchdog.txt b/Documentation/watchdog.txt index e328e3c15..599eda965 100644 --- a/Documentation/watchdog.txt +++ b/Documentation/watchdog.txt @@ -77,17 +77,17 @@ int main(int argc, const char *argv[]) Contact Information People keep asking about the WDT watchdog timer hardware: The phone contacts -for Industrial Computer Source are: +for ICS Advent are: US: 619 677 0877 (sales) 0895 (fax) UK: 01243 533900 France (1) 69.18.74.30 -Industrial Computer Source +ICS Advent 9950 Barnes Canyon Road San Diego, CA -http://www.industry.net/indcompsrc +http://www.icsadvent.com and please mention Linux when enquiring. |