diff --git a/[refs] b/[refs] index 909ee69dbd81..5b141289f95d 100644 --- a/[refs] +++ b/[refs] @@ -1,2 +1,2 @@ --- -refs/heads/master: f43a64c5e1a65d12b9b53a35ed2d5db441fcb64c +refs/heads/master: 14f8351a313f364afbc565f1ddcd43f8cfdccf52 diff --git a/trunk/CREDITS b/trunk/CREDITS index 3b7a1548aaf9..9bd099d960f3 100644 --- a/trunk/CREDITS +++ b/trunk/CREDITS @@ -1880,13 +1880,6 @@ S: Schlehenweg 9 S: D-91080 Uttenreuth S: Germany -N: Jaya Kumar -E: jayalk@intworks.biz -W: http://www.intworks.biz -D: Arc monochrome LCD framebuffer driver, x86 reboot fixups -S: Gurgaon, India -S: Kuala Lumpur, Malaysia - N: Gabor Kuti M: seasons@falcon.sch.bme.hu M: seasons@makosteszta.sote.hu @@ -2380,10 +2373,9 @@ E: tmolina@cablespeed.com D: bug fixes, documentation, minor hackery N: James Morris -E: jmorris@redhat.com +E: jmorris@intercode.com.au W: http://www.intercode.com.au/jmorris/ -D: Netfilter, Linux Security Modules (LSM), SELinux, IPSec, -D: Crypto API, general networking, miscellaneous. +D: Netfilter, Linux Security Modules (LSM). S: PO Box 707 S: Spit Junction NSW 2088 S: Australia @@ -2483,9 +2475,13 @@ S: Potsdam, New York 13676 S: USA N: Dave Neuer -E: dave.neuer@pobox.com +E: dneuer@innovation-charter.com +E: mr_fred_smoothie@yahoo.com D: Helped implement support for Compaq's H31xx series iPAQs D: Other mostly minor tweaks & bugfixes +S: 325 E. Main St., Suite 3 +S: Carnegie, PA 15105 +S: USA N: Michael Neuffer E: mike@i-Connect.Net diff --git a/trunk/Documentation/00-INDEX b/trunk/Documentation/00-INDEX index f28a24e0279b..8de8a01a2474 100644 --- a/trunk/Documentation/00-INDEX +++ b/trunk/Documentation/00-INDEX @@ -138,8 +138,6 @@ java.txt - info on the in-kernel binary support for Java(tm). kbuild/ - directory with info about the kernel build process. -kdumpt.txt - - mini HowTo on getting the crash dump code to work. kernel-doc-nano-HOWTO.txt - mini HowTo on generation and location of kernel documentation files. kernel-docs.txt diff --git a/trunk/Documentation/Changes b/trunk/Documentation/Changes index dfec7569d450..57542bc25edd 100644 --- a/trunk/Documentation/Changes +++ b/trunk/Documentation/Changes @@ -44,9 +44,9 @@ running, the suggested command should tell you. Again, keep in mind that this list assumes you are already functionally running a Linux 2.4 kernel. Also, not all tools are -necessary on all systems; obviously, if you don't have any ISDN -hardware, for example, you probably needn't concern yourself with -isdn4k-utils. +necessary on all systems; obviously, if you don't have any PCMCIA (PC +Card) hardware, for example, you probably needn't concern yourself +with pcmcia-cs. o Gnu C 2.95.3 # gcc --version o Gnu make 3.79.1 # make --version @@ -57,14 +57,13 @@ o e2fsprogs 1.29 # tune2fs o jfsutils 1.1.3 # fsck.jfs -V o reiserfsprogs 3.6.3 # reiserfsck -V 2>&1|grep reiserfsprogs o xfsprogs 2.6.0 # xfs_db -V -o pcmciautils 004 o pcmcia-cs 3.1.21 # cardmgr -V o quota-tools 3.09 # quota -V o PPP 2.4.0 # pppd --version o isdn4k-utils 3.1pre1 # isdnctrl 2>&1|grep version o nfs-utils 1.0.5 # showmount --version o procps 3.2.0 # ps --version -o oprofile 0.9 # oprofiled --version +o oprofile 0.5.3 # oprofiled --version Kernel compilation ================== @@ -187,20 +186,13 @@ architecture independent and any version from 2.0.0 onward should work correctly with this version of the XFS kernel code (2.6.0 or later is recommended, due to some significant improvements). -PCMCIAutils ------------ - -PCMCIAutils replaces pcmcia-cs (see below). It properly sets up -PCMCIA sockets at system startup and loads the appropriate modules -for 16-bit PCMCIA devices if the kernel is modularized and the hotplug -subsystem is used. Pcmcia-cs --------- PCMCIA (PC Card) support is now partially implemented in the main -kernel source. The "pcmciautils" package (see above) replaces pcmcia-cs -for newest kernels. +kernel source. Pay attention when you recompile your kernel ;-). +Also, be sure to upgrade to the latest pcmcia-cs release. Quota-tools ----------- @@ -357,13 +349,9 @@ Xfsprogs -------- o -Pcmciautils ------------ -o - Pcmcia-cs --------- -o +o Quota-tools ---------- diff --git a/trunk/Documentation/DocBook/Makefile b/trunk/Documentation/DocBook/Makefile index fa3e29ad8a46..e69b3d2e7884 100644 --- a/trunk/Documentation/DocBook/Makefile +++ b/trunk/Documentation/DocBook/Makefile @@ -8,7 +8,7 @@ DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.xml \ kernel-hacking.xml kernel-locking.xml deviceiobook.xml \ - procfs-guide.xml writing_usb_driver.xml \ + procfs-guide.xml writing_usb_driver.xml scsidrivers.xml \ sis900.xml kernel-api.xml journal-api.xml lsm.xml usb.xml \ gadget.xml libata.xml mtdnand.xml librs.xml @@ -49,7 +49,7 @@ installmandocs: mandocs KERNELDOC = scripts/kernel-doc DOCPROC = scripts/basic/docproc -XMLTOFLAGS = -m $(srctree)/Documentation/DocBook/stylesheet.xsl +XMLTOFLAGS = -m Documentation/DocBook/stylesheet.xsl #XMLTOFLAGS += --skip-validation ### diff --git a/trunk/Documentation/DocBook/kernel-api.tmpl b/trunk/Documentation/DocBook/kernel-api.tmpl index d650ce36485f..757cef8f8491 100644 --- a/trunk/Documentation/DocBook/kernel-api.tmpl +++ b/trunk/Documentation/DocBook/kernel-api.tmpl @@ -266,7 +266,7 @@ X!Ekernel/module.c Hardware Interfaces Interrupt Handling -!Ikernel/irq/manage.c +!Iarch/i386/kernel/irq.c Resources Management @@ -338,6 +338,7 @@ X!Earch/i386/kernel/mca.c X!Iinclude/linux/device.h --> !Edrivers/base/driver.c +!Edrivers/base/class_simple.c !Edrivers/base/core.c !Edrivers/base/firmware_class.c !Edrivers/base/transport_class.c diff --git a/trunk/Documentation/DocBook/libata.tmpl b/trunk/Documentation/DocBook/libata.tmpl index 375ae760dc1e..cf2fce7707da 100644 --- a/trunk/Documentation/DocBook/libata.tmpl +++ b/trunk/Documentation/DocBook/libata.tmpl @@ -14,7 +14,7 @@ - 2003-2005 + 2003 Jeff Garzik @@ -44,38 +44,30 @@ - - Introduction + + Thanks - libATA is a library used inside the Linux kernel to support ATA host - controllers and devices. libATA provides an ATA driver API, class - transports for ATA and ATAPI devices, and SCSI<->ATA translation - for ATA devices according to the T10 SAT specification. + The bulk of the ATA knowledge comes thanks to long conversations with + Andre Hedrick (www.linux-ide.org). - This Guide documents the libATA driver API, library functions, library - internals, and a couple sample ATA low-level drivers. + Thanks to Alan Cox for pointing out similarities + between SATA and SCSI, and in general for motivation to hack on + libata. + + + libata's device detection + method, ata_pio_devchk, and in general all the early probing was + based on extensive study of Hale Landis's probe/reset code in his + ATADRVR driver (www.ata-atapi.com). libata Driver API - - struct ata_port_operations is defined for every low-level libata - hardware driver, and it controls how the low-level driver - interfaces with the ATA and SCSI layers. - - - FIS-based drivers will hook into the system with ->qc_prep() and - ->qc_issue() high-level hooks. Hardware which behaves in a manner - similar to PCI IDE hardware may utilize several generic helpers, - defining at a bare minimum the bus I/O addresses of the ATA shadow - register blocks. - struct ata_port_operations - Disable ATA port void (*port_disable) (struct ata_port *); @@ -84,19 +76,8 @@ void (*port_disable) (struct ata_port *); Called from ata_bus_probe() and ata_bus_reset() error paths, as well as when unregistering from the SCSI module (rmmod, hot unplug). - This function should do whatever needs to be done to take the - port out of use. In most cases, ata_port_disable() can be used - as this hook. - - - Called from ata_bus_probe() on a failed probe. - Called from ata_bus_reset() on a failed bus reset. - Called from ata_scsi_release(). - - - Post-IDENTIFY device configuration void (*dev_config) (struct ata_port *, struct ata_device *); @@ -106,17 +87,7 @@ void (*dev_config) (struct ata_port *, struct ata_device *); found. Typically used to apply device-specific fixups prior to issue of SET FEATURES - XFER MODE, and prior to operation. - - Called by ata_device_add() after ata_dev_identify() determines - a device is present. - - - This entry may be specified as NULL in ata_port_operations. - - - - Set PIO/DMA mode void (*set_piomode) (struct ata_port *, struct ata_device *); void (*set_dmamode) (struct ata_port *, struct ata_device *); @@ -137,9 +108,6 @@ void (*post_set_mode) (struct ata_port *ap); ->set_dma_mode() is only called if DMA is possible. - - - Taskfile read/write void (*tf_load) (struct ata_port *ap, struct ata_taskfile *tf); void (*tf_read) (struct ata_port *ap, struct ata_taskfile *tf); @@ -150,13 +118,8 @@ void (*tf_read) (struct ata_port *ap, struct ata_taskfile *tf); registers / DMA buffers. ->tf_read() is called to read the hardware registers / DMA buffers, to obtain the current set of taskfile register values. - Most drivers for taskfile-based hardware (PIO or MMIO) use - ata_tf_load() and ata_tf_read() for these hooks. - - - ATA command execute void (*exec_command)(struct ata_port *ap, struct ata_taskfile *tf); @@ -164,53 +127,19 @@ void (*exec_command)(struct ata_port *ap, struct ata_taskfile *tf); causes an ATA command, previously loaded with ->tf_load(), to be initiated in hardware. - Most drivers for taskfile-based hardware use ata_exec_command() - for this hook. - - - Per-cmd ATAPI DMA capabilities filter - -int (*check_atapi_dma) (struct ata_queued_cmd *qc); - - - -Allow low-level driver to filter ATA PACKET commands, returning a status -indicating whether or not it is OK to use DMA for the supplied PACKET -command. - - - This hook may be specified as NULL, in which case libata will - assume that atapi dma can be supported. - - - - - Read specific ATA shadow registers u8 (*check_status)(struct ata_port *ap); -u8 (*check_altstatus)(struct ata_port *ap); -u8 (*check_err)(struct ata_port *ap); +void (*dev_select)(struct ata_port *ap, unsigned int device); - Reads the Status/AltStatus/Error ATA shadow register from - hardware. On some hardware, reading the Status register has - the side effect of clearing the interrupt condition. - Most drivers for taskfile-based hardware use - ata_check_status() for this hook. + Reads the Status ATA shadow register from hardware. On some + hardware, this has the side effect of clearing the interrupt + condition. - - Note that because this is called from ata_device_add(), at - least a dummy function that clears device interrupts must be - provided for all drivers, even if the controller doesn't - actually have a taskfile status register. - - - - Select ATA device on bus void (*dev_select)(struct ata_port *ap, unsigned int device); @@ -218,19 +147,9 @@ void (*dev_select)(struct ata_port *ap, unsigned int device); Issues the low-level hardware command(s) that causes one of N hardware devices to be considered 'selected' (active and - available for use) on the ATA bus. This generally has no - meaning on FIS-based devices. + available for use) on the ATA bus. - - Most drivers for taskfile-based hardware use - ata_std_dev_select() for this hook. Controllers which do not - support second drives on a port (such as SATA contollers) will - use ata_noop_dev_select(). - - - - Reset ATA bus void (*phy_reset) (struct ata_port *ap); @@ -241,54 +160,19 @@ void (*phy_reset) (struct ata_port *ap); for device presence (PATA and SATA), typically a soft reset (SRST) will be performed. Drivers typically use the helper functions ata_bus_reset() or sata_phy_reset() for this hook. - Many SATA drivers use sata_phy_reset() or call it from within - their own phy_reset() functions. - - - Control PCI IDE BMDMA engine void (*bmdma_setup) (struct ata_queued_cmd *qc); void (*bmdma_start) (struct ata_queued_cmd *qc); -void (*bmdma_stop) (struct ata_port *ap); -u8 (*bmdma_status) (struct ata_port *ap); -When setting up an IDE BMDMA transaction, these hooks arm -(->bmdma_setup), fire (->bmdma_start), and halt (->bmdma_stop) -the hardware's DMA engine. ->bmdma_status is used to read the standard -PCI IDE DMA Status register. + When setting up an IDE BMDMA transaction, these hooks arm + (->bmdma_setup) and fire (->bmdma_start) the hardware's DMA + engine. - -These hooks are typically either no-ops, or simply not implemented, in -FIS-based drivers. - - -Most legacy IDE drivers use ata_bmdma_setup() for the bmdma_setup() -hook. ata_bmdma_setup() will write the pointer to the PRD table to -the IDE PRD Table Address register, enable DMA in the DMA Command -register, and call exec_command() to begin the transfer. - - -Most legacy IDE drivers use ata_bmdma_start() for the bmdma_start() -hook. ata_bmdma_start() will write the ATA_DMA_START flag to the DMA -Command register. - - -Many legacy IDE drivers use ata_bmdma_stop() for the bmdma_stop() -hook. ata_bmdma_stop() clears the ATA_DMA_START flag in the DMA -command register. - - -Many legacy IDE drivers use ata_bmdma_status() as the bmdma_status() hook. - - - - - High-level taskfile hooks void (*qc_prep) (struct ata_queued_cmd *qc); int (*qc_issue) (struct ata_queued_cmd *qc); @@ -306,30 +190,20 @@ int (*qc_issue) (struct ata_queued_cmd *qc); ->qc_issue is used to make a command active, once the hardware and S/G tables have been prepared. IDE BMDMA drivers use the helper function ata_qc_issue_prot() for taskfile protocol-based - dispatch. More advanced drivers implement their own ->qc_issue. + dispatch. More advanced drivers roll their own ->qc_issue + implementation, using this as the "issue new ATA command to + hardware" hook. - - ata_qc_issue_prot() calls ->tf_load(), ->bmdma_setup(), and - ->bmdma_start() as necessary to initiate a transfer. - - - - Timeout (error) handling void (*eng_timeout) (struct ata_port *ap); -This is a high level error handling function, called from the -error handling thread, when a command times out. Most newer -hardware will implement its own error handling code here. IDE BMDMA -drivers may use the helper function ata_eng_timeout(). + This is a high level error handling function, called from the + error handling thread, when a command times out. - - - Hardware interrupt handling irqreturn_t (*irq_handler)(int, void *, struct pt_regs *); void (*irq_clear) (struct ata_port *); @@ -341,25 +215,7 @@ void (*irq_clear) (struct ata_port *); before the interrupt handler is registered, to be sure hardware is quiet. - - The second argument, dev_instance, should be cast to a pointer - to struct ata_host_set. - - - Most legacy IDE drivers use ata_interrupt() for the - irq_handler hook, which scans all ports in the host_set, - determines which queued command was active (if any), and calls - ata_host_intr(ap,qc). - - - Most legacy IDE drivers use ata_bmdma_irq_clear() for the - irq_clear() hook, which simply clears the interrupt and error - flags in the DMA status register. - - - - SATA phy read/write u32 (*scr_read) (struct ata_port *ap, unsigned int sc_reg); void (*scr_write) (struct ata_port *ap, unsigned int sc_reg, @@ -369,12 +225,8 @@ void (*scr_write) (struct ata_port *ap, unsigned int sc_reg, Read and write standard SATA phy registers. Currently only used if ->phy_reset hook called the sata_phy_reset() helper function. - sc_reg is one of SCR_STATUS, SCR_CONTROL, SCR_ERROR, or SCR_ACTIVE. - - - Init and shutdown int (*port_start) (struct ata_port *ap); void (*port_stop) (struct ata_port *ap); @@ -385,32 +237,18 @@ void (*host_stop) (struct ata_host_set *host_set); ->port_start() is called just after the data structures for each port are initialized. Typically this is used to alloc per-port DMA buffers / tables / rings, enable DMA engines, and similar - tasks. Some drivers also use this entry point as a chance to - allocate driver-private memory for ap->private_data. + tasks. - Many drivers use ata_port_start() as this hook or call - it from their own port_start() hooks. ata_port_start() - allocates space for a legacy IDE PRD table and returns. + ->host_stop() is called when the rmmod or hot unplug process + begins. The hook must stop all hardware interrupts, DMA + engines, etc. ->port_stop() is called after ->host_stop(). It's sole function is to release DMA/memory resources, now that they are no longer - actively being used. Many drivers also free driver-private - data from port at this time. - - - Many drivers use ata_port_stop() as this hook, which frees the - PRD table. + actively being used. - - ->host_stop() is called after all ->port_stop() calls -have completed. The hook must finalize hardware shutdown, release DMA -and other resources, etc. - This hook may be specified as NULL, in which case it is not called. - - - @@ -441,24 +279,4 @@ and other resources, etc. !Idrivers/scsi/sata_sil.c - - Thanks - - The bulk of the ATA knowledge comes thanks to long conversations with - Andre Hedrick (www.linux-ide.org), and long hours pondering the ATA - and SCSI specifications. - - - Thanks to Alan Cox for pointing out similarities - between SATA and SCSI, and in general for motivation to hack on - libata. - - - libata's device detection - method, ata_pio_devchk, and in general all the early probing was - based on extensive study of Hale Landis's probe/reset code in his - ATADRVR driver (www.ata-atapi.com). - - - diff --git a/trunk/Documentation/DocBook/scsidrivers.tmpl b/trunk/Documentation/DocBook/scsidrivers.tmpl new file mode 100644 index 000000000000..d058e65daf19 --- /dev/null +++ b/trunk/Documentation/DocBook/scsidrivers.tmpl @@ -0,0 +1,193 @@ + + + + + + SCSI Subsystem Interfaces + + + + Douglas + Gilbert + +
+ dgilbert@interlog.com +
+
+
+
+ 2003-08-11 + + + 2002 + 2003 + Douglas Gilbert + + + + + This documentation 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., 59 Temple Place, Suite 330, Boston, + MA 02111-1307 USA + + + + For more details see the file COPYING in the source + distribution of Linux. + + + +
+ + + + + Introduction + +This document outlines the interface between the Linux scsi mid level +and lower level drivers. Lower level drivers are variously called HBA +(host bus adapter) drivers, host drivers (HD) or pseudo adapter drivers. +The latter alludes to the fact that a lower level driver may be a +bridge to another IO subsystem (and the "ide-scsi" driver is an example +of this). There can be many lower level drivers active in a running +system, but only one per hardware type. For example, the aic7xxx driver +controls adaptec controllers based on the 7xxx chip series. Most lower +level drivers can control one or more scsi hosts (a.k.a. scsi initiators). + + +This document can been found in an ASCII text file in the linux kernel +source: Documentation/scsi/scsi_mid_low_api.txt . +It currently hold a little more information than this document. The +drivers/scsi/hosts.h and +drivers/scsi/scsi.h headers contain descriptions of members +of important structures for the scsi subsystem. + + + + + Driver structure + +Traditionally a lower level driver for the scsi subsystem has been +at least two files in the drivers/scsi directory. For example, a +driver called "xyz" has a header file "xyz.h" and a source file +"xyz.c". [Actually there is no good reason why this couldn't all +be in one file.] Some drivers that have been ported to several operating +systems (e.g. aic7xxx which has separate files for generic and +OS-specific code) have more than two files. Such drivers tend to have +their own directory under the drivers/scsi directory. + + +scsi_module.c is normally included at the end of a lower +level driver. For it to work a declaration like this is needed before +it is included: + + static Scsi_Host_Template driver_template = DRIVER_TEMPLATE; + /* DRIVER_TEMPLATE should contain pointers to supported interface + functions. Scsi_Host_Template is defined hosts.h */ + #include "scsi_module.c" + + + +The scsi_module.c assumes the name "driver_template" is appropriately +defined. It contains 2 functions: + + + init_this_scsi_driver() called during builtin and module driver + initialization: invokes mid level's scsi_register_host() + + + exit_this_scsi_driver() called during closedown: invokes + mid level's scsi_unregister_host() + + + + +When a new, lower level driver is being added to Linux, the following +files (all found in the drivers/scsi directory) will need some attention: +Makefile, Config.help and Config.in . It is probably best to look at what +an existing lower level driver does in this regard. + + + + + Interface Functions +!EDocumentation/scsi/scsi_mid_low_api.txt + + + + Locks + +Each Scsi_Host instance has a spin_lock called Scsi_Host::default_lock +which is initialized in scsi_register() [found in hosts.c]. Within the +same function the Scsi_Host::host_lock pointer is initialized to point +at default_lock with the scsi_assign_lock() function. Thereafter +lock and unlock operations performed by the mid level use the +Scsi_Host::host_lock pointer. + + +Lower level drivers can override the use of Scsi_Host::default_lock by +using scsi_assign_lock(). The earliest opportunity to do this would +be in the detect() function after it has invoked scsi_register(). It +could be replaced by a coarser grain lock (e.g. per driver) or a +lock of equal granularity (i.e. per host). Using finer grain locks +(e.g. per scsi device) may be possible by juggling locks in +queuecommand(). + + + + + Changes since lk 2.4 series + +io_request_lock has been replaced by several finer grained locks. The lock +relevant to lower level drivers is Scsi_Host::host_lock and there is one +per scsi host. + + +The older error handling mechanism has been removed. This means the +lower level interface functions abort() and reset() have been removed. + + +In the 2.4 series the scsi subsystem configuration descriptions were +aggregated with the configuration descriptions from all other Linux +subsystems in the Documentation/Configure.help file. In the 2.5 series, +the scsi subsystem now has its own (much smaller) drivers/scsi/Config.help +file. + + + + + Credits + +The following people have contributed to this document: + + +Mike Anderson andmike@us.ibm.com + + +James Bottomley James.Bottomley@steeleye.com + + +Patrick Mansfield patmans@us.ibm.com + + + + + +
diff --git a/trunk/Documentation/DocBook/stylesheet.xsl b/trunk/Documentation/DocBook/stylesheet.xsl index 64be9f7ee3bb..e14c21dda403 100644 --- a/trunk/Documentation/DocBook/stylesheet.xsl +++ b/trunk/Documentation/DocBook/stylesheet.xsl @@ -2,5 +2,4 @@ 1 ansi -80 diff --git a/trunk/Documentation/IPMI.txt b/trunk/Documentation/IPMI.txt index 84d3d4d10c17..90d10e708ca3 100644 --- a/trunk/Documentation/IPMI.txt +++ b/trunk/Documentation/IPMI.txt @@ -25,10 +25,9 @@ subject and I can't cover it all here! Configuration ------------- -The Linux IPMI driver is modular, which means you have to pick several +The LinuxIPMI driver is modular, which means you have to pick several things to have it work right depending on your hardware. Most of -these are available in the 'Character Devices' menu then the IPMI -menu. +these are available in the 'Character Devices' menu. No matter what, you must pick 'IPMI top-level message handler' to use IPMI. What you do beyond that depends on your needs and hardware. @@ -36,30 +35,33 @@ IPMI. What you do beyond that depends on your needs and hardware. The message handler does not provide any user-level interfaces. Kernel code (like the watchdog) can still use it. If you need access from userland, you need to select 'Device interface for IPMI' if you -want access through a device driver. - -The driver interface depends on your hardware. If your system -properly provides the SMBIOS info for IPMI, the driver will detect it -and just work. If you have a board with a standard interface (These -will generally be either "KCS", "SMIC", or "BT", consult your hardware -manual), choose the 'IPMI SI handler' option. A driver also exists -for direct I2C access to the IPMI management controller. Some boards -support this, but it is unknown if it will work on every board. For -this, choose 'IPMI SMBus handler', but be ready to try to do some -figuring to see if it will work on your system if the SMBIOS/APCI -information is wrong or not present. It is fairly safe to have both -these enabled and let the drivers auto-detect what is present. +want access through a device driver. Another interface is also +available, you may select 'IPMI sockets' in the 'Networking Support' +main menu. This provides a socket interface to IPMI. You may select +both of these at the same time, they will both work together. + +The driver interface depends on your hardware. If you have a board +with a standard interface (These will generally be either "KCS", +"SMIC", or "BT", consult your hardware manual), choose the 'IPMI SI +handler' option. A driver also exists for direct I2C access to the +IPMI management controller. Some boards support this, but it is +unknown if it will work on every board. For this, choose 'IPMI SMBus +handler', but be ready to try to do some figuring to see if it will +work. + +There is also a KCS-only driver interface supplied, but it is +depracated in favor of the SI interface. You should generally enable ACPI on your system, as systems with IPMI -can have ACPI tables describing them. +should have ACPI tables describing them. If you have a standard interface and the board manufacturer has done their job correctly, the IPMI controller should be automatically -detected (via ACPI or SMBIOS tables) and should just work. Sadly, -many boards do not have this information. The driver attempts -standard defaults, but they may not work. If you fall into this -situation, you need to read the section below named 'The SI Driver' or -"The SMBus Driver" on how to hand-configure your system. +detect (via ACPI or SMBIOS tables) and should just work. Sadly, many +boards do not have this information. The driver attempts standard +defaults, but they may not work. If you fall into this situation, you +need to read the section below named 'The SI Driver' on how to +hand-configure your system. IPMI defines a standard watchdog timer. You can enable this with the 'IPMI Watchdog Timer' config option. If you compile the driver into @@ -71,18 +73,6 @@ closed (by default it is disabled on close). Go into the 'Watchdog Cards' menu, enable 'Watchdog Timer Support', and enable the option 'Disable watchdog shutdown on close'. -IPMI systems can often be powered off using IPMI commands. Select -'IPMI Poweroff' to do this. The driver will auto-detect if the system -can be powered off by IPMI. It is safe to enable this even if your -system doesn't support this option. This works on ATCA systems, the -Radisys CPI1 card, and any IPMI system that supports standard chassis -management commands. - -If you want the driver to put an event into the event log on a panic, -enable the 'Generate a panic event to all BMCs on a panic' option. If -you want the whole panic string put into the event log using OEM -events, enable the 'Generate OEM events containing the panic string' -option. Basic Design ------------ @@ -90,7 +80,7 @@ Basic Design The Linux IPMI driver is designed to be very modular and flexible, you only need to take the pieces you need and you can use it in many different ways. Because of that, it's broken into many chunks of -code. These chunks (by module name) are: +code. These chunks are: ipmi_msghandler - This is the central piece of software for the IPMI system. It handles all messages, message timing, and responses. The @@ -103,26 +93,18 @@ ipmi_devintf - This provides a userland IOCTL interface for the IPMI driver, each open file for this device ties in to the message handler as an IPMI user. -ipmi_si - A driver for various system interfaces. This supports KCS, -SMIC, and BT interfaces. Unless you have an SMBus interface or your -own custom interface, you probably need to use this. +ipmi_si - A driver for various system interfaces. This supports +KCS, SMIC, and may support BT in the future. Unless you have your own +custom interface, you probably need to use this. ipmi_smb - A driver for accessing BMCs on the SMBus. It uses the I2C kernel driver's SMBus interfaces to send and receive IPMI messages over the SMBus. -ipmi_watchdog - IPMI requires systems to have a very capable watchdog -timer. This driver implements the standard Linux watchdog timer -interface on top of the IPMI message handler. - -ipmi_poweroff - Some systems support the ability to be turned off via -IPMI commands. +af_ipmi - A network socket interface to IPMI. This doesn't take up +a character device in your system. -These are all individually selectable via configuration options. - -Note that the KCS-only interface has been removed. The af_ipmi driver -is no longer supported and has been removed because it was impossible -to do 32 bit emulation on 64-bit kernels with it. +Note that the KCS-only interface ahs been removed. Much documentation for the interface is in the include files. The IPMI include files are: @@ -442,7 +424,7 @@ at module load time (for a module) with: modprobe ipmi_smb.o addr=,[,,[,...]] dbg=,... - [defaultprobe=1] [dbg_probe=1] + [defaultprobe=0] [dbg_probe=1] The addresses are specified in pairs, the first is the adapter ID and the second is the I2C address on that adapter. @@ -550,67 +532,3 @@ Once you open the watchdog timer, you must write a 'V' character to the device to close it, or the timer will not stop. This is a new semantic for the driver, but makes it consistent with the rest of the watchdog drivers in Linux. - - -Panic Timeouts --------------- - -The OpenIPMI driver supports the ability to put semi-custom and custom -events in the system event log if a panic occurs. if you enable the -'Generate a panic event to all BMCs on a panic' option, you will get -one event on a panic in a standard IPMI event format. If you enable -the 'Generate OEM events containing the panic string' option, you will -also get a bunch of OEM events holding the panic string. - - -The field settings of the events are: -* Generator ID: 0x21 (kernel) -* EvM Rev: 0x03 (this event is formatting in IPMI 1.0 format) -* Sensor Type: 0x20 (OS critical stop sensor) -* Sensor #: The first byte of the panic string (0 if no panic string) -* Event Dir | Event Type: 0x6f (Assertion, sensor-specific event info) -* Event Data 1: 0xa1 (Runtime stop in OEM bytes 2 and 3) -* Event data 2: second byte of panic string -* Event data 3: third byte of panic string -See the IPMI spec for the details of the event layout. This event is -always sent to the local management controller. It will handle routing -the message to the right place - -Other OEM events have the following format: -Record ID (bytes 0-1): Set by the SEL. -Record type (byte 2): 0xf0 (OEM non-timestamped) -byte 3: The slave address of the card saving the panic -byte 4: A sequence number (starting at zero) -The rest of the bytes (11 bytes) are the panic string. If the panic string -is longer than 11 bytes, multiple messages will be sent with increasing -sequence numbers. - -Because you cannot send OEM events using the standard interface, this -function will attempt to find an SEL and add the events there. It -will first query the capabilities of the local management controller. -If it has an SEL, then they will be stored in the SEL of the local -management controller. If not, and the local management controller is -an event generator, the event receiver from the local management -controller will be queried and the events sent to the SEL on that -device. Otherwise, the events go nowhere since there is nowhere to -send them. - - -Poweroff --------- - -If the poweroff capability is selected, the IPMI driver will install -a shutdown function into the standard poweroff function pointer. This -is in the ipmi_poweroff module. When the system requests a powerdown, -it will send the proper IPMI commands to do this. This is supported on -several platforms. - -There is a module parameter named "poweroff_control" that may either be zero -(do a power down) or 2 (do a power cycle, power the system off, then power -it on in a few seconds). Setting ipmi_poweroff.poweroff_control=x will do -the same thing on the kernel command line. The parameter is also available -via the proc filesystem in /proc/ipmi/poweroff_control. Note that if the -system does not support power cycling, it will always to the power off. - -Note that if you have ACPI enabled, the system will prefer using ACPI to -power off. diff --git a/trunk/Documentation/SubmittingDrivers b/trunk/Documentation/SubmittingDrivers index c3cca924e94b..de3b252e717d 100644 --- a/trunk/Documentation/SubmittingDrivers +++ b/trunk/Documentation/SubmittingDrivers @@ -13,14 +13,13 @@ Allocating Device Numbers ------------------------- Major and minor numbers for block and character devices are allocated -by the Linux assigned name and number authority (currently this is -Torben Mathiasen). The site is http://www.lanana.org/. This +by the Linux assigned name and number authority (currently better +known as H Peter Anvin). The site is http://www.lanana.org/. This also deals with allocating numbers for devices that are not going to be submitted to the mainstream kernel. -See Documentation/devices.txt for more information on this. -If you don't use assigned numbers then when your device is submitted it will -be given an assigned number even if that is different from values you may +If you don't use assigned numbers then when you device is submitted it will +get given an assigned number even if that is different from values you may have shipped to customers before. Who To Submit Drivers To @@ -33,8 +32,7 @@ Linux 2.2: If the code area has a general maintainer then please submit it to the maintainer listed in MAINTAINERS in the kernel file. If the maintainer does not respond or you cannot find the appropriate - maintainer then please contact the 2.2 kernel maintainer: - Marc-Christian Petersen . + maintainer then please contact Alan Cox Linux 2.4: The same rules apply as 2.2. The final contact point for Linux 2.4 @@ -50,7 +48,7 @@ What Criteria Determine Acceptance Licensing: The code must be released to us under the GNU General Public License. We don't insist on any kind - of exclusive GPL licensing, and if you wish the driver + of exclusively GPL licensing, and if you wish the driver to be useful to other communities such as BSD you may well wish to release under multiple licenses. diff --git a/trunk/Documentation/SubmittingPatches b/trunk/Documentation/SubmittingPatches index 6761a7b241a5..9838d32b2fe7 100644 --- a/trunk/Documentation/SubmittingPatches +++ b/trunk/Documentation/SubmittingPatches @@ -35,7 +35,7 @@ not in any lower subdirectory. To create a patch for a single file, it is often sufficient to do: - SRCTREE= linux-2.6 + SRCTREE= linux-2.4 MYFILE= drivers/net/mydriver.c cd $SRCTREE @@ -48,18 +48,17 @@ To create a patch for multiple files, you should unpack a "vanilla", or unmodified kernel source tree, and generate a diff against your own source tree. For example: - MYSRC= /devel/linux-2.6 + MYSRC= /devel/linux-2.4 - tar xvfz linux-2.6.12.tar.gz - mv linux-2.6.12 linux-2.6.12-vanilla - diff -uprN -X linux-2.6.12-vanilla/Documentation/dontdiff \ - linux-2.6.12-vanilla $MYSRC > /tmp/patch + tar xvfz linux-2.4.0-test11.tar.gz + mv linux linux-vanilla + wget http://www.moses.uklinux.net/patches/dontdiff + diff -uprN -X dontdiff linux-vanilla $MYSRC > /tmp/patch + rm -f dontdiff "dontdiff" is a list of files which are generated by the kernel during the build process, and should be ignored in any diff(1)-generated -patch. The "dontdiff" file is included in the kernel tree in -2.6.12 and later. For earlier kernel versions, you can get it -from . +patch. dontdiff is maintained by Tigran Aivazian Make sure your patch does not include any extra files which do not belong in a patch submission. Make sure to review your patch -after- @@ -67,20 +66,18 @@ generated it with diff(1), to ensure accuracy. If your changes produce a lot of deltas, you may want to look into splitting them into individual patches which modify things in -logical stages. This will facilitate easier reviewing by other +logical stages, this will facilitate easier reviewing by other kernel developers, very important if you want your patch accepted. -There are a number of scripts which can aid in this: +There are a number of scripts which can aid in this; Quilt: http://savannah.nongnu.org/projects/quilt Randy Dunlap's patch scripts: -http://www.xenotime.net/linux/scripts/patching-scripts-002.tar.gz +http://developer.osdl.org/rddunlap/scripts/patching-scripts.tgz Andrew Morton's patch scripts: -http://www.zip.com.au/~akpm/linux/patches/patch-scripts-0.20 - - +http://www.zip.com.au/~akpm/linux/patches/patch-scripts-0.16 2) Describe your changes. @@ -135,6 +132,21 @@ which require discussion or do not have a clear advantage should usually be sent first to linux-kernel. Only after the patch is discussed should the patch then be submitted to Linus. +For small patches you may want to CC the Trivial Patch Monkey +trivial@rustcorp.com.au set up by Rusty Russell; which collects "trivial" +patches. Trivial patches must qualify for one of the following rules: + Spelling fixes in documentation + Spelling fixes which could break grep(1). + Warning fixes (cluttering with useless warnings is bad) + Compilation fixes (only if they are actually correct) + Runtime fixes (only if they actually fix things) + Removing use of deprecated functions/macros (eg. check_region). + Contact detail and documentation fixes + Non-portable code replaced by portable code (even in arch-specific, + since people copy, as long as it's trivial) + Any fix by the author/maintainer of the file. (ie. patch monkey + in re-transmission mode) + 5) Select your CC (e-mail carbon copy) list. @@ -166,8 +178,6 @@ patches. Trivial patches must qualify for one of the following rules: since people copy, as long as it's trivial) Any fix by the author/maintainer of the file. (ie. patch monkey in re-transmission mode) -URL: - @@ -261,7 +271,7 @@ patch, which certifies that you wrote it or otherwise have the right to pass it on as a open-source patch. The rules are pretty simple: if you can certify the below: - Developer's Certificate of Origin 1.1 + Developer's Certificate of Origin 1.0 By making a contribution to this project, I certify that: @@ -281,32 +291,15 @@ can certify the below: person who certified (a), (b) or (c) and I have not modified it. - (d) I understand and agree that this project and the contribution - are public and that a record of the contribution (including all - personal information I submit with it, including my sign-off) is - maintained indefinitely and may be redistributed consistent with - this project or the open source license(s) involved. - then you just add a line saying - Signed-off-by: Random J Developer + Signed-off-by: Random J Developer Some people also put extra tags at the end. They'll just be ignored for now, but you can do this to mark internal company procedures or just point out some special detail about the sign-off. - -12) More references for submitting patches - -Andrew Morton, "The perfect patch" (tpp). - - -Jeff Garzik, "Linux kernel patch submission format." - - - - ----------------------------------- SECTION 2 - HINTS, TIPS, AND TRICKS ----------------------------------- @@ -375,5 +368,7 @@ and 'extern __inline__'. 4) Don't over-design. Don't try to anticipate nebulous future cases which may or may not -be useful: "Make it as simple as you can, and no simpler." +be useful: "Make it as simple as you can, and no simpler" + + diff --git a/trunk/Documentation/basic_profiling.txt b/trunk/Documentation/basic_profiling.txt index 8764e9f70821..65e3dc2d4437 100644 --- a/trunk/Documentation/basic_profiling.txt +++ b/trunk/Documentation/basic_profiling.txt @@ -27,13 +27,9 @@ dump output readprofile -m /boot/System.map > captured_profile Oprofile -------- - -Get the source (see Changes for required version) from -http://oprofile.sourceforge.net/ and add "idle=poll" to the kernel command -line. - +Get the source (I use 0.8) from http://oprofile.sourceforge.net/ +and add "idle=poll" to the kernel command line Configure with CONFIG_PROFILING=y and CONFIG_OPROFILE=y & reboot on new kernel - ./configure --with-kernel-support make install @@ -50,7 +46,7 @@ start opcontrol --start stop opcontrol --stop dump output opreport > output_file -To only report on the kernel, run opreport -l /boot/vmlinux > output_file +To only report on the kernel, run opreport /boot/vmlinux > output_file A reset is needed to clear old statistics, which survive a reboot. diff --git a/trunk/Documentation/block/ioprio.txt b/trunk/Documentation/block/ioprio.txt deleted file mode 100644 index 96ccf681075e..000000000000 --- a/trunk/Documentation/block/ioprio.txt +++ /dev/null @@ -1,176 +0,0 @@ -Block io priorities -=================== - - -Intro ------ - -With the introduction of cfq v3 (aka cfq-ts or time sliced cfq), basic io -priorities is supported for reads on files. This enables users to io nice -processes or process groups, similar to what has been possible to cpu -scheduling for ages. This document mainly details the current possibilites -with cfq, other io schedulers do not support io priorities so far. - -Scheduling classes ------------------- - -CFQ implements three generic scheduling classes that determine how io is -served for a process. - -IOPRIO_CLASS_RT: This is the realtime io class. This scheduling class is given -higher priority than any other in the system, processes from this class are -given first access to the disk every time. Thus it needs to be used with some -care, one io RT process can starve the entire system. Within the RT class, -there are 8 levels of class data that determine exactly how much time this -process needs the disk for on each service. In the future this might change -to be more directly mappable to performance, by passing in a wanted data -rate instead. - -IOPRIO_CLASS_BE: This is the best-effort scheduling class, which is the default -for any process that hasn't set a specific io priority. The class data -determines how much io bandwidth the process will get, it's directly mappable -to the cpu nice levels just more coarsely implemented. 0 is the highest -BE prio level, 7 is the lowest. The mapping between cpu nice level and io -nice level is determined as: io_nice = (cpu_nice + 20) / 5. - -IOPRIO_CLASS_IDLE: This is the idle scheduling class, processes running at this -level only get io time when no one else needs the disk. The idle class has no -class data, since it doesn't really apply here. - -Tools ------ - -See below for a sample ionice tool. Usage: - -# ionice -c -n -p - -If pid isn't given, the current process is assumed. IO priority settings -are inherited on fork, so you can use ionice to start the process at a given -level: - -# ionice -c2 -n0 /bin/ls - -will run ls at the best-effort scheduling class at the highest priority. -For a running process, you can give the pid instead: - -# ionice -c1 -n2 -p100 - -will change pid 100 to run at the realtime scheduling class, at priority 2. - ----> snip ionice.c tool <--- - -#include -#include -#include -#include -#include -#include -#include - -extern int sys_ioprio_set(int, int, int); -extern int sys_ioprio_get(int, int); - -#if defined(__i386__) -#define __NR_ioprio_set 289 -#define __NR_ioprio_get 290 -#elif defined(__ppc__) -#define __NR_ioprio_set 273 -#define __NR_ioprio_get 274 -#elif defined(__x86_64__) -#define __NR_ioprio_set 251 -#define __NR_ioprio_get 252 -#elif defined(__ia64__) -#define __NR_ioprio_set 1274 -#define __NR_ioprio_get 1275 -#else -#error "Unsupported arch" -#endif - -_syscall3(int, ioprio_set, int, which, int, who, int, ioprio); -_syscall2(int, ioprio_get, int, which, int, who); - -enum { - IOPRIO_CLASS_NONE, - IOPRIO_CLASS_RT, - IOPRIO_CLASS_BE, - IOPRIO_CLASS_IDLE, -}; - -enum { - IOPRIO_WHO_PROCESS = 1, - IOPRIO_WHO_PGRP, - IOPRIO_WHO_USER, -}; - -#define IOPRIO_CLASS_SHIFT 13 - -const char *to_prio[] = { "none", "realtime", "best-effort", "idle", }; - -int main(int argc, char *argv[]) -{ - int ioprio = 4, set = 0, ioprio_class = IOPRIO_CLASS_BE; - int c, pid = 0; - - while ((c = getopt(argc, argv, "+n:c:p:")) != EOF) { - switch (c) { - case 'n': - ioprio = strtol(optarg, NULL, 10); - set = 1; - break; - case 'c': - ioprio_class = strtol(optarg, NULL, 10); - set = 1; - break; - case 'p': - pid = strtol(optarg, NULL, 10); - break; - } - } - - switch (ioprio_class) { - case IOPRIO_CLASS_NONE: - ioprio_class = IOPRIO_CLASS_BE; - break; - case IOPRIO_CLASS_RT: - case IOPRIO_CLASS_BE: - break; - case IOPRIO_CLASS_IDLE: - ioprio = 7; - break; - default: - printf("bad prio class %d\n", ioprio_class); - return 1; - } - - if (!set) { - if (!pid && argv[optind]) - pid = strtol(argv[optind], NULL, 10); - - ioprio = ioprio_get(IOPRIO_WHO_PROCESS, pid); - - printf("pid=%d, %d\n", pid, ioprio); - - if (ioprio == -1) - perror("ioprio_get"); - else { - ioprio_class = ioprio >> IOPRIO_CLASS_SHIFT; - ioprio = ioprio & 0xff; - printf("%s: prio %d\n", to_prio[ioprio_class], ioprio); - } - } else { - if (ioprio_set(IOPRIO_WHO_PROCESS, pid, ioprio | ioprio_class << IOPRIO_CLASS_SHIFT) == -1) { - perror("ioprio_set"); - return 1; - } - - if (argv[optind]) - execvp(argv[optind], &argv[optind]); - } - - return 0; -} - ----> snip ionice.c tool <--- - - -March 11 2005, Jens Axboe diff --git a/trunk/Documentation/cciss.txt b/trunk/Documentation/cciss.txt index c8f9a73111da..d599beb9df8a 100644 --- a/trunk/Documentation/cciss.txt +++ b/trunk/Documentation/cciss.txt @@ -17,7 +17,6 @@ This driver is known to work with the following cards: * SA P600 * SA P800 * SA E400 - * SA E300 If nodes are not already created in the /dev/cciss directory, run as root: diff --git a/trunk/Documentation/cdrom/sbpcd b/trunk/Documentation/cdrom/sbpcd index b3ba63f4ce3e..d1825dffca34 100644 --- a/trunk/Documentation/cdrom/sbpcd +++ b/trunk/Documentation/cdrom/sbpcd @@ -419,7 +419,6 @@ into the file "track01": */ #include #include -#include #include static struct cdrom_tochdr hdr; @@ -430,7 +429,7 @@ static int datafile, drive; static int i, j, limit, track, err; static char filename[32]; -int main(int argc, char *argv[]) +main(int argc, char *argv[]) { /* * open /dev/cdrom @@ -517,7 +516,6 @@ entry[track+1].cdte_addr.lba=entry[track].cdte_addr.lba+300; } arg.addr.lba++; } - return 0; } /*===================== end program ========================================*/ @@ -566,16 +564,15 @@ Appendix -- the "cdtester" utility: #include #include #include -#include #include #ifdef AZT_PRIVATE_IOCTLS #include -#endif /* AZT_PRIVATE_IOCTLS */ +#endif AZT_PRIVATE_IOCTLS #ifdef SBP_PRIVATE_IOCTLS #include #include -#endif /* SBP_PRIVATE_IOCTLS */ +#endif SBP_PRIVATE_IOCTLS struct cdrom_tochdr hdr; struct cdrom_tochdr tocHdr; @@ -593,7 +590,7 @@ union struct cdrom_msf msf; unsigned char buf[CD_FRAMESIZE_RAW]; } azt; -#endif /* AZT_PRIVATE_IOCTLS */ +#endif AZT_PRIVATE_IOCTLS int i, i1, i2, i3, j, k; unsigned char sequence=0; unsigned char command[80]; @@ -741,7 +738,7 @@ void display(int size,unsigned char *buffer) } } -int main(int argc, char *argv[]) +main(int argc, char *argv[]) { printf("\nTesting tool for a CDROM driver's audio functions V0.1\n"); printf("(C) 1995 Eberhard Moenkeberg \n"); @@ -1049,13 +1046,12 @@ int main(int argc, char *argv[]) rc=ioctl(drive,CDROMAUDIOBUFSIZ,j); printf("%d frames granted.\n",rc); break; -#endif /* SBP_PRIVATE_IOCTLS */ +#endif SBP_PRIVATE_IOCTLS default: printf("unknown command: \"%s\".\n",command); break; } } - return 0; } /*==========================================================================*/ diff --git a/trunk/Documentation/cpu-freq/cpufreq-stats.txt b/trunk/Documentation/cpu-freq/cpufreq-stats.txt deleted file mode 100644 index e2d1e760b4ba..000000000000 --- a/trunk/Documentation/cpu-freq/cpufreq-stats.txt +++ /dev/null @@ -1,128 +0,0 @@ - - CPU frequency and voltage scaling statictics in the Linux(TM) kernel - - - L i n u x c p u f r e q - s t a t s d r i v e r - - - information for users - - - - Venkatesh Pallipadi - -Contents -1. Introduction -2. Statistics Provided (with example) -3. Configuring cpufreq-stats - - -1. Introduction - -cpufreq-stats is a driver that provices CPU frequency statistics for each CPU. -This statistics is provided in /sysfs as a bunch of read_only interfaces. This -interface (when configured) will appear in a seperate directory under cpufreq -in /sysfs (/devices/system/cpu/cpuX/cpufreq/stats/) for each CPU. -Various statistics will form read_only files under this directory. - -This driver is designed to be independent of any particular cpufreq_driver -that may be running on your CPU. So, it will work with any cpufreq_driver. - - -2. Statistics Provided (with example) - -cpufreq stats provides following statistics (explained in detail below). -- time_in_state -- total_trans -- trans_table - -All the statistics will be from the time the stats driver has been inserted -to the time when a read of a particular statistic is done. Obviously, stats -driver will not have any information about the the frequcny transitions before -the stats driver insertion. - --------------------------------------------------------------------------------- -:/sys/devices/system/cpu/cpu0/cpufreq/stats # ls -l -total 0 -drwxr-xr-x 2 root root 0 May 14 16:06 . -drwxr-xr-x 3 root root 0 May 14 15:58 .. --r--r--r-- 1 root root 4096 May 14 16:06 time_in_state --r--r--r-- 1 root root 4096 May 14 16:06 total_trans --r--r--r-- 1 root root 4096 May 14 16:06 trans_table --------------------------------------------------------------------------------- - -- time_in_state -This gives the amount of time spent in each of the frequencies supported by -this CPU. The cat output will have "