ACPI: Atlas ACPI driver | jayakumar.acpi@gmail.com | Mon, 22 May 2006 14:24:53 -0700 | 3 files changed, 206 insertions(+) | 7057 Bytes |
An ACPI driver for Atlas boards, including input support. Signed-off-by: Jaya Kumar <jayakumar.acpi@gmail.com> Signed-off-by: Andrew Morton <akpm@osdl.org> |
s390: Hypervisor File System | Michael Holzheu | Fri, 28 Apr 2006 23:39:21 -0700 | 7 files changed, 1151 insertions(+), 1 deletion(-) | 30740 Bytes |
s390: Rename hypfs to s390-hypfs | Michael Holzheu | Wed, 10 May 2006 01:39:52 -0700 | 3 files changed, 3 insertions(+), 3 deletions(-) | 1987 Bytes |
On zSeries machines there exists an interface which allows the operating system to retrieve LPAR hypervisor accounting data. For example, it is possible to get usage data for physical and virtual cpus. In order to provide this information to user space programs, I implemented a new virtual Linux file system named 'hypfs' using the Linux 2.6 libfs framework. The name 'hypfs' stands for 'Hypervisor Filesystem'. All the accounting information is put into different virtual files which can be accessed from user space. All data is represented as ASCII strings. When the file system is mounted the accounting information is retrieved and a file system tree is created with the attribute files containing the cpu information. The content of the files remains unchanged until a new update is made. An update can be triggered from user space through writing 'something' into a special purpose update file. We create the following directory structure: - cpus/: Directory for all physical cpus - cpus/<cpu-id>/: Directory for one physical cpu. - cpus/<cpu-id>/type: Type name of physical zSeries cpu. - cpus/<cpu-id>/mgmtime: Physical-LPAR-management time in microseconds. - hyp/: Directory for hypervisor information - hyp/type: Typ of hypervisor (currently only 'LPAR Hypervisor') - systems/: Directory for all LPARs - systems/<lpar-name>/: Directory for one LPAR. - systems/<lpar-name>/cpus/<cpu-id>/: Directory for the virtual cpus - systems/<lpar-name>/cpus/<cpu-id>/type: Typ of cpu. - systems/<lpar-name>/cpus/<cpu-id>/mgmtime:< Accumulated number of microseconds during which a physical CPU was assigned to the logical cpu and the cpu time was consumed by the hypervisor and was not provided to the LPAR (LPAR overhead). - systems/<lpar-name>/cpus/<cpu-id>/cputime: Accumulated number of microseconds during which a physical CPU was assigned to the logical cpu and the cpu time was consumed by the LPAR. - systems/<lpar-name>/cpus/<cpu-id>/onlinetime: Accumulated number of microseconds during which the logical CPU has been online. The update process is triggered when writing 'something' into the 'update' file at the top level hypfs directory. You can do this e.g. with 'echo 1 > update'. During the update the whole directory structure is deleted and built up again. Signed-off-by: Michael Holzheu <holzheu@de.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> |
Add /sys/hypervisor subsystem | Michael Holzheu | Wed, 10 May 2006 01:41:11 -0700 | 2 files changed, 23 insertions(+), 5 deletions(-) | 2206 Bytes |
Add /sys/hypervisor/s390 as mount point for s390-hypfs | Michael Holzheu | Wed, 10 May 2006 01:40:29 -0700 | 1 files changed, 11 insertions(+), 10 deletions(-) | 1864 Bytes |
Creates /sys/hypervisor as a home for all hypervisors. s390-hypfs is the first hypervisor that actually makes use of it. Acked-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Michael Holzheu <holzheu@de.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> |
Add new generic HW RNG core | Michael Buesch | Mon, 15 May 2006 15:07:30 -0700 | 6 files changed, 433 insertions(+) | 11797 Bytes |
Add AMD HW RNG driver | Michael Buesch | Mon, 15 May 2006 15:07:34 -0700 | 3 files changed, 166 insertions(+) | 5252 Bytes |
Add Geode HW RNG driver | Michael Buesch | Mon, 15 May 2006 15:07:37 -0700 | 3 files changed, 143 insertions(+) | 4897 Bytes |
Add Intel HW RNG driver | Michael Buesch | Mon, 15 May 2006 15:07:32 -0700 | 3 files changed, 204 insertions(+) | 6514 Bytes |
Add TI OMAP CPU family HW RNG driver | Michael Buesch | Mon, 15 May 2006 15:07:43 -0700 | 3 files changed, 223 insertions(+) | 6583 Bytes |
Add VIA HW RNG driver | Michael Buesch | Mon, 15 May 2006 15:07:39 -0700 | 3 files changed, 198 insertions(+) | 6863 Bytes |
This patch series replaces the old non-generic Hardware Random Number Generator support by a fully generic RNG API. This makes it possible to register additional RNGs from modules. With this patch series applied, Laptops with a bcm43xx chip (PowerBook) have a HW RNG available now. Additionally two new RNG drivers are added for the "ixp4xx" and "omap" devices (Written by Deepak Saxena). This patch series includes the old patches by Deepak Saxena. The old x86-rng driver has beed split. The userspace RNG daemon can later be updated to select the RNG through /sys/class/misc/hw_random/ for convenience. For now it is sufficient to use cat and echo -n on the sysfs attributes. Signed-off-by: Michael Buesch <mb@bu3sch.de> Signed-off-by: Andrew Morton <akpm@osdl.org> |
Apple Motion Sensor driver | Stelian Pop | Wed, 24 May 2006 14:53:47 -0700 | 3 files changed, 537 insertions(+) | 14752 Bytes |
This driver provides support for the Apple Motion Sensor (ams), which provides an accelerometer and other misc. data. Some Apple PowerBooks (the series the PowerBook 5,6 falls into, later ones have a slightly different one the driver doesn't handle) are supported. The accelerometer data is readable via sysfs. This driver also provides an absolute input class device, allowing the laptop to act as a pinball machine-esque joystick. In the future (once the proper API exist in the block layer) this driver will tell the laptop disk to protect its heads in the event of a catastrophic fall. Signed-off-by: Stelian Pop <stelian@popies.net> Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Andrew Morton <akpm@osdl.org> |
areca-raid-linux-scsi-driver update6 for 2.6.17-rc1-mm3 | Erich Chen | Thu, 27 Apr 2006 14:51:23 -0700 | 4 files changed, 942 insertions(+), 4838 deletions(-) | 304336 Bytes |
1- merge the patch files of Christoph Hellwig 2- by Matthew Wilcox comments modify arcmsr and arcmsr_spec.txt Note: Most of the changes in this patch remove documentation, so the impact on the code is far lower than the size of the patch. Signed-off-by: Erich Chen <erich@areca.com.tw> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Andrew Morton <akpm@osdl.org> |
Avoid disk sector_t overflow for >2TB ext3 filesystem | Mingming Cao | Mon, 22 May 2006 11:43:59 -0700 | 2 files changed, 19 insertions(+) | 2052 Bytes |
If ext3 filesystem is larger than 2TB, and sector_t is a u32 (i.e. CONFIG_LBD <Note: Large Block Devices> not defined in the kernel), the calculation of the disk sector will overflow. Add check at ext3_fill_super() and ext3_group_extend() to prevent mount/remount/resize >2TB ext3 filesystem if sector_t size is 4 bytes. Verified this patch on a 32 bit platform without CONFIG_LBD defined (sector_t is 32 bits long), mount refuse to mount a 10TB ext3. Signed-off-by: Mingming Cao<cmm@us.ibm.com> Cc: Andreas Dilger <adilger@clusterfs.com> Signed-off-by: Andrew Morton <akpm@osdl.org> |
bcm43xx: Fix array overrun in bcm43xx_geo_init | Michael Buesch | Wed, 10 May 2006 20:37:48 -0700 | 2 files changed, 30 insertions(+), 19 deletions(-) | 2928 Bytes |
The problem here is that the bcm34xx driver and the ieee80211 stack do not agree on what channels are possible for 802.11a. The ieee80211 stack only wants channels between 34 and 165, while the bcm43xx driver accepts anything from 0 to 200. I made the bcm43xx driver comply with the ieee80211 stack expectations, by using the proper constants. Signed-off-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Michael Buesch <mb@bu3sch.de> Signed-off-by: Andrew Morton <akpm@osdl.org> |
deprecate smbfs in favour of cifs | Andrew Morton | Thu, 11 May 2006 00:15:10 -0700 | 1 files changed, 7 insertions(+) | 3429 Bytes |
smbfs is a bit buggy and has no maintainer. Change it to shout at the user on the first five mount attempts - tell them to switch to CIFS. Come November we'll mark it BROKEN and see what happens. Signed-off-by: Andrew Morton <akpm@osdl.org> |
Driver for Apple Cinema Display | Michael Hanselmann | Fri, 26 May 2006 13:17:09 -0700 | 4 files changed, 391 insertions(+) | 12714 Bytes |
This is a driver to control the brightness of an Apple Cinema Display over USB. It updates the local brightness value if the user presses a button on the display. Signed-off-by: Michael Hanselmann <linux-kernel@hansmi.ch> Signed-off-by: Andrew Morton <akpm@osdl.org> |
ecryptfs: crypto functions | Phillip Hellewell | Sat, 13 May 2006 00:25:59 -0700 | 1 files changed, 1508 insertions(+) | 48131 Bytes |
ecryptfs: file operations | Phillip Hellewell | Sat, 13 May 2006 00:25:51 -0700 | 1 files changed, 620 insertions(+) | 18329 Bytes |
ecryptfs: keystore | Phillip Hellewell | Sat, 13 May 2006 00:25:57 -0700 | 1 files changed, 1043 insertions(+) | 34569 Bytes |
ecryptfs: main module functions | Phillip Hellewell | Sat, 13 May 2006 00:25:43 -0700 | 1 files changed, 767 insertions(+) | 23939 Bytes |
ecryptfs: superblock operations | Phillip Hellewell | Sat, 13 May 2006 00:25:47 -0700 | 1 files changed, 212 insertions(+) | 7469 Bytes |
This patchset adds the code from http://ecryptfs.sourceforge.net/ to the Linux kernel. A short excerpt from the project homepage: "eCryptfs (SourceForge page) is a POSIX-compliant enterprise-class stacked cryptographic filesystem for Linux. It is derived from Erez Zadok's Cryptfs, implemented through the FiST framework for generating stacked filesystems. eCryptfs extends Cryptfs to provide advanced key management and policy features. eCryptfs stores cryptographic metadata in the header of each file written, so that encrypted files can be copied between hosts; the file will be decryptable with the proper key, and there is no need to keep track of any additional information aside from what is already in the encrypted file itself. Think of eCryptfs as a sort of 'gnupgfs'" Signed-off-by: Phillip Hellewell <phillip@hellewell.homeip.net> Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> |
EDD isn't EXPERIMENTAL anymore | Chris Wedgwood | Sun, 21 May 2006 14:00:58 -0700 | 1 files changed, 1 insertion(+), 2 deletions(-) | 749 Bytes |
Note: EDD stands for "Enhanced Disk Drive" (former ANSI/INCITS 407-2005 ) and allows the system to get detailed information about mass storage devices from the BIOS. This allows the operating system to e.g. get information about boot devices and is not limited to ATA/S-ATA/SCSI. Lots of people use this. Apparently RedHat has for over 18 months so lets drop EXPERIMENTAL. Signed-off-by: Chris Wedgwood <cw@f00f.org> Signed-off-by: Andrew Morton <akpm@osdl.org> |
Fix broken suspend/resume in ohci1394 | Robert Hancock | Mon, 22 May 2006 17:04:19 -0700 | 1 files changed, 3 insertions(+) | 783 Bytes |
I've been experimenting to track down the cause of suspend/resume problems on my Compaq Presario X1050 laptop: http://bugzilla.kernel.org/show_bug.cgi?id=6075 Essentially the ACPI Embedded Controller and keyboard controller would get into a bizarre, confused state after resume. I found that unloading the ohci1394 module before suspend and reloading it after resume made the problem go away. Diffing the dmesg output from resume, with and without the module loaded, I found that with the module loaded I was missing these: PM: Writing back config space on device 0000:02:00.0 at offset 1. (Was 2100080, writing 2100007) PM: Writing back config space on device 0000:02:00.0 at offset 3. (Was 0, writing 8008) PM: Writing back config space on device 0000:02:00.0 at offset 4. (Was 0, writing 90200000) PM: Writing back config space on device 0000:02:00.0 at offset 5. (Was 1, writing 2401) PM: Writing back config space on device 0000:02:00.0 at offset f. (Was 20000100, writing 2000010a) The default PCI driver performs the pci_restore_state when no driver is loaded for the device. When the ohci1394 driver is loaded, it is supposed to do this, however it appears not to do so. I created the patch below and tested it, and it appears to resolve the suspend problems I was having with the module loaded. I only added in the pci_save_state and pci_restore_state - however, though I know little of this hardware, surely the driver should really be doing more than this when suspending and resuming? Currently it does almost nothing, what if there are commands in progress, etc? Signed-off-by: Robert Hancock <hancockr@shaw.ca> Signed-off-by: Andrew Morton <akpm@osdl.org> |
FS-Cache: Generic filesystem caching facility | David Howells | Thu, 11 May 2006 09:56:29 -0700 | 13 files changed, 3883 insertions(+) | 125194 Bytes |
FS-Cache: Make kAFS use FS-Cache | David Howells | Thu, 11 May 2006 09:56:32 -0700 | 19 files changed, 658 insertions(+), 412 deletions(-) | 661 Bytes |
Add a generic intermediary (FS-Cache) by which filesystems may call on local caching capabilities, and by which local caching backends may make caches available. The cache backend API to FS-Cache can be found in: Documentation/filesystems/caching/backend-api.txt Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> |
FS-Cache: CacheFiles: A cache that backs onto a mounted filesystem | David Howells | Thu, 11 May 2006 09:56:37 -0700 | 17 files changed, 4217 insertions(+) | 118687 Bytes |
Add a cache backend that permits a mounted filesystem to be used as a backing store for the cache. CacheFiles uses a userspace daemon to do some of the cache management - such as reaping stale nodes and culling. This is called cachefilesd and lives in /sbin. The source for the daemon can be downloaded from: http://people.redhat.com/~dhowells/cachefs/cachefilesd.c and an example configuration from: http://people.redhat.com/~dhowells/cachefs/cachefilesd.conf The filesystem and data integrity of the cache are only as good as those of the filesystem providing the backing services. Note that CacheFiles does not attempt to journal anything since the journalling interfaces of the various filesystems are very specific in nature. CacheFiles creates a proc-file - "/proc/fs/cachefiles" - that is used for communication with the daemon. Only one thing may have this open at once, and whilst it is open, a cache is at least partially in existence. The daemon opens this and sends commands down it to control the cache. CacheFiles is currently limited to a single cache. CacheFiles attempts to maintain at least a certain percentage of free space on the filesystem, shrinking the cache by culling the objects it contains to make space if necessary - see the "Cache Culling" section. This means it can be placed on the same medium as a live set of data, and will expand to make use of spare space and automatically contract when the set of data requires more space. Documentation is added by the patch to: Documentation/filesystems/caching/cachefiles.txt Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> |
hptiop: HighPoint RocketRAID 3xxx controller driver | HighPoint Linux Team | Fri, 12 May 2006 09:59:37 -0700 | 6 files changed, 2086 insertions(+) | 59823 Bytes |
From: HighPoint Linux Team <linux@highpoint-tech.com> Signed-off-by: HighPoint Linux Team <linux@highpoint-tech.com> Signed-off-by: Andrew Morton <akpm@osdl.org> |
ide: fix HPT37x timing tables | Sergei Shtylyov | Tue, 9 May 2006 12:15:43 -0700 | 1 files changed, 29 insertions(+), 120 deletions(-) | 1221 Bytes |
ide: fix HPT3xx hotswap support | Sergei Shtylyov | Tue, 9 May 2006 12:15:48 -0700 | 1 files changed, 36 insertions(+), 79 deletions(-) | 1014 Bytes |
Fix/remove bad/unused timing tables: HPT370/A 66 MHz tables weren't really needed (the chips are not UltraATA/133 capable and shouldn't support 66 MHz PCI) and had many modes over- and underclocked, HPT372 33 MHz table was in fact for 66 MHz and 50 MHz table missed UltraDMA mode 6, HPT374 33 MHz table was really for 50 MHz... (actually, HPT370/A 33 MHz tables also have issues. e.g. HPT370 has PIO modes 0/1 overlocked.) Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Fix the broken hotswap code: on HPT37x it caused RESET- to glitch when tristating the bus (the MISC control 3/6 and soft control 2 need to be written to in the certain order), and for HPT36x the obsolete HDIO_TRISTATE_HWIF ioctl() handler was called instead which treated the state argument wrong. Also, get rid of the soft control reg. 1 wtite to enable IDE interrupt -- this is done in init_hpt37x() already... Hase been tested on HPT370 and 371N. Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: Andrew Morton <akpm@osdl.org> |
input: new force feedback interface | Anssi Hannula | Wed, 17 May 2006 21:46:16 -0700 | 6 files changed, 831 insertions(+), 9 deletions(-) | 875 Bytes |
input: force feedback driver for Zeroplus devices | Anssi Hannula | Fri, 26 May 2006 14:18:43 -0700 | 5 files changed, 139 insertions(+) | 6787 Bytes |
input: adapt iforce driver for the new force feedback interface | Anssi Hannula | Wed, 17 May 2006 21:46:43 -0700 | 4 files changed, 87 insertions(+), 179 deletions(-) | 1315 Bytes |
input: force feedback driver for PID devices | Anssi Hannula | Wed, 17 May 2006 21:46:50 -0700 | 6 files changed, 1121 insertions(+), 31 deletions(-) | 43307 Bytes |
Implement a new force feedback interface, in which all non-driver-specific operations are separated to a common module. This module handles effect type validations, effect timers, locking, etc. As a result, support is added for gain and envelope for memoryless devices, periodic => rumble conversion for memoryless devices and rumble => periodic conversion for devices with periodic support instead of rumble support. Also the effect memory of devices is not emptied if the root user opens and closes the device while another user is using effects. This module also obsoletes some flawed locking and timer code in few ff drivers. The module is named ff-effects. If INPUT_FF_EFFECTS is enabled, the force feedback drivers and interfaces (evdev) will be depending on it. Userspace interface is left unaltered. Signed-off-by: Anssi Hannula <anssi.hannula@gmail.com> Signed-off-by: Andrew Morton <akpm@osdl.org> |
kbuild: export-symbol usage report generator | Ram Pai | Thu, 11 May 2006 11:30:18 -0700 | 3 files changed, 170 insertions(+), 1 deletion(-) | 6503 Bytes |
The following patch provides the ability to generate a report of (1) All the exported symbols and their in-kernel-module usage count (2) For each module, lists the modules and their exported symbols, on which it depends. The report generation is integrated in the build process. 'make exportcheck' prints out the report. 'make exportcheck EXPORTFILE=Documentation/export_report.txt' generates the report in the file Documentation/export_report.txt NOTE: the same report can also be generated by executing 'perl scripts/export_report' Signed-off-by: Ram Pai <linuxram@us.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> |
make kernel warn about incorrectly sized partitions | Mike Miller | Thu, 11 May 2006 07:24:26 -0700 | 1 files changed, 4 insertions(+) | 881 Bytes |
Sometimes partitions claim to be larger than the reported capacity of a disk device. This patch makes the kernel warn about those partitions. We still permit these patitions to be used. Quoting Andries Brouwer <Andries.Brouwer@cwi.nl>: Case 1: The kernel is mistaken about the size of the disk. (There are commands to clip a disk to a certain capacity, there are jumpers to tell a disk that it should report a certain capacity etc. Usually this is because of BIOS bugs. In bad cases the machine will crash in the BIOS and hence fail to boot if the disk reports full capacity.) In such cases actually accessing the blocks of the partition may work fine, or may work fine after running an unclip utility. I wrote "setmax" some years ago precisely for this reason. Case 2: There was a messy partition table (maybe just a rounding error) but the actual filesystem on the partition is contained in the physical disk. Now using the filesystem goes without problem. Case 3: Both partition and filesystem extend beyond the end of the disk. In forensic or debugging situations one often uses a copy of the start of a disk. Now access beyond the end gives an expected I/O error. Signed-off-by: Mike Miller <mike.miller@hp.com> Signed-off-by: Stephen Cameron <steve.cameron@hp.com> Signed-off-by: Andrew Morton <akpm@osdl.org> |
Make RCU API inaccessible to non-GPL Linux kernel modules | "Paul E. McKenney" | Mon, 1 May 2006 15:16:45 -0700 | 4 files changed, 3 insertions(+), 28 deletions(-) | 1153 Bytes |
What: RCU API moves to EXPORT_SYMBOL_GPL When: April 2006 Files: include/linux/rcupdate.h, kernel/rcupdate.c Why: Outside of Linux, the only implementations of anything even vaguely resembling RCU that I am aware of are in DYNIX/ptx, VM/XA, Tornado, and K42.I do not expect anyone to port binary drivers or kernel modules from any of these, since the first two are owned by IBM and the last two are open-source research OSes. So these will move to GPL after a grace period to allow people, who might be using implementations that I am not aware of, to adjust to this upcoming change. Remove synchronize_kernel() (deprecated 2-APR-2005 in http://lkml.org/lkml/2005/4/3/11) and makes the RCU API inaccessible to non-GPL Linux kernel modules (as was announced more than one year ago in http://lkml.org/lkml/2005/4/3/8). Tested on x86 and ppc64. Signed-off-by: "Paul E. McKenney" <paulmck@us.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> |
matroxfb: fix DVI setup to be more compatible | Paul A. Clarke | Sun, 23 Apr 2006 22:29:30 -0700 | 3 files changed, 25 insertions(+), 2 deletions(-) | 3462 Bytes |
There has been a longstanding problem with the Matrox G450 and perhaps other similar cards, with modes "above" 1280x1024-60 on ppc/ppc64 boxes running Linux. Higher resolutions and/or higher refresh rates resulted in a very noticably "jittery" display, and sometimes no display, depending on the physical monitor. This patch fixes that problem on the systems I have easy access to... I've tested with SLES9SP3 (2.6.5+ kernel) and 2.6.16-rc6 custom kernels on an IBM eServer p5 520 w/G450 (a.k.a GXT135P on IBM's ppc64 systems), and a colleague of mine (Ian Romanick) tested it successfully on an Apple ppc32 box (w/GXT135P). I also tested it on IA32 box I have with a GXT135P to verify that it didn't obviously break anything. In my testing, I covered single-card, single and dual-head setups using both HD15 and DVI-D signals, on both the IA32 and ppc64 boxes. While everything appeared fine on both boxes, I did encounter one problem: I can't get any signal on the DVI-D output on the ppc64 box. However, this is also the case without my patch. I just noticed that screen-blanking only occurs on the primary display as well. Signed-off-by: Paul A. Clarke <pc@us.ibm.com> Signed-off-by: Ian Romanick <idr@us.ibm.com> Signed-off-by: Petr Vandrovec <petr@vandrovec.name> Signed-off-by: Andrew Morton <akpm@osdl.org> |
md: allow a linear array to have drives added while active | NeilBrown | Sun, 30 Apr 2006 22:41:28 -0700 | 3 files changed, 76 insertions(+), 15 deletions(-) | 7160 Bytes |
No comment. Signed-off-by: Neil Brown <neilb@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> |
md: merge raid5 and raid6 code | NeilBrown | Sun, 30 Apr 2006 22:41:22 -0700 | 5 files changed, 1056 insertions(+), 2580 deletions(-) | 2323 Bytes |
There is a lot of commonality between raid5.c and raid6main.c. This patches merges both into one module called raid456. This saves a lot of code, and paves the way for online raid5->raid6 migrations. There is still duplication, e.g. between handle_stripe5 and handle_stripe6. This will probably be cleaned up later. Cc: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by: Neil Brown <neilb@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> |
md: support stripe/offset mode in raid10 | NeilBrown | Sun, 30 Apr 2006 22:41:30 -0700 | 2 files changed, 49 insertions(+), 22 deletions(-) | 2343 Bytes |
The "industry standard" DDF format allows for a stripe/offset layout where data is duplicated on different stripes. e.g. A B C D D A B C E F G H H E F G (columns are drives, rows are stripes, LETTERS are chunks of data). This is similar to raid10's 'far' mode, but not quite the same. So enhance 'far' mode with a 'far/offset' option which follows the layout of DDFs stripe/offset. Signed-off-by: Neil Brown <neilb@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> |
namespaces: utsname: implement utsname namespaces | "Serge E. Hallyn" | Fri, 19 May 2006 11:40:13 -0700 | 9 files changed, 133 insertions(+), 12 deletions(-) | 5193 Bytes |
namespaces: utsname: switch to using uts namespaces | "Serge E. Hallyn" | Fri, 19 May 2006 11:40:08 -0700 | 35 files changed, 124 insertions(+), 124 deletions(-) | 39001 Bytes |
namespaces: utsname: use init_utsname when appropriate | "Serge E. Hallyn" | Fri, 19 May 2006 11:40:11 -0700 | 25 files changed, 44 insertions(+), 44 deletions(-) | 19192 Bytes |
Note: The UTS namespace patches aid in the virtualization and isolation of utsname process information (e.g. the hostname). Please have a look at this KernelTrap Article for further explaination. This patch defines the uts namespace and some manipulators. Adds the uts namespace to task_struct, and initializes a system-wide init namespace. Signed-off-by: Serge Hallyn <serue@us.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> |
NFS: Share NFS superblocks per-protocol per-server per-FSID | David Howells | Thu, 11 May 2006 09:56:18 -0700 | 32 files changed, 2737 insertions(+), 1437 deletions(-) | 657 Bytes |
Make NFS share superblocks between mounts from the same server and FSID over the same protocol. The full patchset consists of five patches. Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> |
NFS: Use local caching | David Howells | Thu, 11 May 2006 10:41:41 -0700 | 17 files changed, 820 insertions(+), 5 deletions(-) | 37245 Bytes |
Make it possible for the NFS filesystem to make use of the network filesystem local caching service (FS-Cache). To be able to use this, an updated mount program is required. This can be obtained from: ftp://people.redhat.com/steved/cachefs/util-linux/ To mount an NFS filesystem to use caching, add an "fsc" option to the mount: mount warthog:/ /a -o fsc Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> |
pi-futex: rt mutex core | Ingo Molnar | Thu, 25 May 2006 08:01:32 -0700 | 11 files changed, 1181 insertions(+) | 41864 Bytes |
pi-futex: add plist implementation | Ingo Molnar | Thu, 25 May 2006 08:01:27 -0700 | 4 files changed, 372 insertions(+) | 16087 Bytes |
pi-futex: futex code cleanups | Ingo Molnar | Thu, 25 May 2006 08:01:19 -0700 | 4 files changed, 135 insertions(+), 122 deletions(-) | 14777 Bytes |
pi-futex: futex_lock_pi/futex_unlock_pi support | Ingo Molnar | Thu, 25 May 2006 08:01:42 -0700 | 7 files changed, 825 insertions(+), 41 deletions(-) | 12231 Bytes |
pi-futex: introduce debug_check_no_locks_freed() | Ingo Molnar | Thu, 25 May 2006 08:01:23 -0700 | 4 files changed, 13 insertions(+), 7 deletions(-) | 7195 Bytes |
pi-futex: rt mutex docs | Steven Rostedt | Thu, 25 May 2006 08:01:34 -0700 | 3 files changed, 969 insertions(+) | 44290 Bytes |
pi-futex: scheduler support for pi | Ingo Molnar | Thu, 25 May 2006 08:01:29 -0700 | 3 files changed, 181 insertions(+), 31 deletions(-) | 4370 Bytes |
Note: A Futex is a "Fast User Mutex" and is used to synchronize the access to ressources between multiple Threads. See http://en.wikipedia.org/wiki/Futex for further explainations. We are pleased to announce "lightweight userspace priority inheritance" (PI) support for futexes. The following patchset and glibc patch implements it, ontop of the robust-futexes patchset which is included in 2.6.16-mm1. Priority Inheritance - why, oh why??? ------------------------------------- Many of you heard the horror stories about the evil PI code circling Linux for years, which makes no real sense at all and is only used by buggy applications and which has horrible overhead. Some of you have dreaded this very moment, when someone actually submits working PI code ;-) So why would we like to see PI support for futexes? We'd like to see it done purely for technological reasons. We dont think it's a buggy concept, we think it's useful functionality to offer to applications, which functionality cannot be achieved in other ways. We also think it's the right thing to do, and we think we've got the right arguments and the right numbers to prove that. We also believe that we can address all the counter-arguments as well. For these reasons (and the reasons outlined below) we are submitting this patch-set for upstream kernel inclusion. What are the benefits of PI? The short reply: ---------------- User-space PI helps achieving/improving determinism for user-space applications. In the best-case, it can help achieve determinism and well-bound latencies. Even in the worst-case, PI will improve the statistical distribution of locking related application delays. The longer reply: ----------------- Firstly, sharing locks between multiple tasks is a common programming technique that often cannot be replaced with lockless algorithms. As we can see it in the kernel [which is a quite complex program in itself], lockless structures are rather the exception than the norm - the current ratio of lockless vs. locky code for shared data structures is somewhere between 1:10 and 1:100. Lockless is hard, and the complexity of lockless algorithms often endangers to ability to do robust reviews of said code. I.e. critical RT apps often choose lock structures to protect critical data structures, instead of lockless algorithms. Furthermore, there are cases (like shared hardware, or other resource limits) where lockless access is mathematically impossible. Media players (such as Jack) are an example of reasonable application design with multiple tasks (with multiple priority levels) sharing short-held locks: for example, a highprio audio playback thread is combined with medium-prio construct-audio-data threads and low-prio display-colory-stuff threads. Add video and decoding to the mix and we've got even more priority levels. So once we accept that synchronization objects (locks) are an unavoidable fact of life, and once we accept that multi-task userspace apps have a very fair expectation of being able to use locks, we've got to think about how to offer the option of a deterministic locking implementation to user-space. Most of the technical counter-arguments against doing priority inheritance only apply to kernel-space locks. But user-space locks are different, there we cannot disable interrupts or make the task non-preemptible in a critical section, so the 'use spinlocks' argument does not apply (user-space spinlocks have the same priority inversion problems as other user-space locking constructs). Fact is, pretty much the only technique that currently enables good determinism for userspace locks (such as futex-based pthread mutexes) is priority inheritance: Currently (without PI), if a high-prio and a low-prio task shares a lock [this is a quite common scenario for most non-trivial RT applications], even if all critical sections are coded carefully to be deterministic (i.e. all critical sections are short in duration and only execute a limited number of instructions), the kernel cannot guarantee any deterministic execution of the high-prio task: any medium-priority task could preempt the low-prio task while it holds the shared lock and executes the critical section, and could delay it indefinitely. (...) Many thanks go to the people who helped us create this kernel feature: Steven Rostedt, Esben Nielsen, Benedikt Spranger, Daniel Walker, John Cooper, Arjan van de Ven, Oleg Nesterov and others. Credits for related prior projects goes to Dirk Grambow, Inaky Perez-Gonzalez, Bill Huey and many others. Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> |
readahead: backward prefetching method | Wu Fengguang | Wed, 24 May 2006 16:50:24 -0700 | 1 files changed, 40 insertions(+) | 2809 Bytes |
------------------------------------------------------ Subject: readahead: backward prefetching method From: Wu Fengguang <wfg@mail.ustc.edu.cn> Readahead policy for reading backward. Signed-off-by: Wu Fengguang <wfg@mail.ustc.edu.cn> Signed-off-by: Andrew Morton <akpm@osdl.org> |
readahead: initial method | Wu Fengguang | Wed, 24 May 2006 16:50:20 -0700 | 1 files changed, 37 insertions(+) | 2900 Bytes |
readahead: initial method - expected read size | Wu Fengguang | Wed, 24 May 2006 16:50:12 -0700 | 3 files changed, 63 insertions(+) | 4830 Bytes |
readahead: kconfig options | Wu Fengguang | Wed, 24 May 2006 16:48:38 -0700 | 1 files changed, 57 insertions(+) | 3968 Bytes |
readahead: laptop mode | Wu Fengguang | Wed, 24 May 2006 16:50:41 -0700 | 3 files changed, 37 insertions(+), 1 deletion(-) | 3833 Bytes |
Note: The patchset introduced by Wu Fengguang consists of at more than 70 single patches This patchset introduces a set of adaptive read-ahead methods. They enable the kernel to better support many important I/O applications. MAIN FEATURES ============= - Adaptive read-ahead buffer management - aggressive, thrashing safe read-ahead size - optimal memory utilisation while achieving good I/O throughput - unnecessary to hand tuning VM_MAX_READAHEAD - support slow/fast readers at the same time - support large number of concurrent readers - aggressive read-ahead on start-of-file - configurable recommended read-ahead size - safeguarded by dynamic estimated thrashing threshold - safeguarded by dynamic estimated expected read size - good for lots-of-small-files case - shrinkable look-ahead size - cut down up to 40% memory consumption on overloaded situation - Detecting any form of (semi-)sequencial scan - parallel / interleaved sequential scans on one fd - sequential reads across file open/close lifetime - mixed sequential / random accesses - sparse / skimming sequential read - Support more access patterns - backward prefetching - seeking around reading N pages - Better special case handling - nfs daemon support: the raparams cache is no longer required - laptop mode support: defer look-ahead on drive spinned down - loopback file support: avoid double look-ahead DESIGN STRATEGIES ================= - Dual methods design - stateful method: the fast and default one - stateless method: the robust and failsafe one - if anything abnormal happens, the stateful method bails out, the stateless method queries the page cache and possibly restart the read-ahead process - Robust feedback design - sense and handle important states so that the logic wont run away - detect danger of thrashing and prevent it in advance - extensive accounting and debugging traces This patch: Add kconfig options to enable/disable: - adaptive read-ahead logic - adaptive read-ahead debug traces and events accounting The read-ahead introduction text is cited from the well written LWN article "Adaptive file readahead" <http://lwn.net/Articles/155510/> :) Signed-off-by: Wu Fengguang <wfg@mail.ustc.edu.cn> Signed-off-by: Andrew Morton <akpm@osdl.org> |
readahead: seeking reads method | Wu Fengguang | Wed, 24 May 2006 16:50:28 -0700 | 1 files changed, 43 insertions(+) | 3068 Bytes |
Readahead policy on read after seeking. It tries to detect sequences like: seek(), 5*read(); seek(), 6*read(); seek(), 4*read(); ... Signed-off-by: Wu Fengguang <wfg@mail.ustc.edu.cn> Signed-off-by: Andrew Morton <akpm@osdl.org> |
readahead: turn on by default | Wu Fengguang | Wed, 24 May 2006 16:50:55 -0700 | 1 files changed, 1 insertion(+), 1 deletion(-) | 1884 Bytes |
It helps collect more early testers, and is meant to be a -mm only patch. Signed-off-by: Wu Fengguang <wfg@mail.ustc.edu.cn> Signed-off-by: Andrew Morton <akpm@osdl.org> |
Rewritten backlight infrastructure for portable Apple computers | Michael Hanselmann | Wed, 10 May 2006 22:02:33 -0700 | 26 files changed, 1478 insertions(+), 718 deletions(-) | 3136 Bytes |
This patch contains a total rewrite of the backlight infrastructure for portable Apple computers. Backward compatibility is retained. A sysfs interface allows userland to control the brightness with more steps than before. Userland is allowed to upload a brightness curve for different monitors, similar to Mac OS X. Signed-off-by: Michael Hanselmann <linux-kernel@hansmi.ch> Signed-off-by: Andrew Morton <akpm@osdl.org> |
secmark: Add CONNSECMARK xtables target | James Morris | Thu, 18 May 2006 03:04:57 -0700 | 4 files changed, 180 insertions(+) | 6853 Bytes |
secmark: Add secmark support to core networking. | James Morris | Thu, 18 May 2006 03:04:51 -0700 | 6 files changed, 34 insertions(+), 1 deletion(-) | 1825 Bytes |
Add a new xtables target, CONNSECMARK, which is used to specify rules for copying security marks from packets to connections, and for copyying security marks back from connections to packets. This is similar to the CONNMARK target, but is more limited in scope in that it only allows copying of security marks to and from packets, as this is all it needs to do. A typical scenario would be to apply a security mark to a 'new' packet with SECMARK, then copy that to its conntrack via CONNMARK, and then restore the security mark from the connection to established and related packets on that connection. Add a secmark field to the skbuff structure, to allow security subsystems to place security markings on network packets. This is similar to the nfmark field, except is intended for implementing security policy, rather than than networking policy. This patch was already acked in principle by Dave Miller. Signed-off-by: James Morris <jmorris@namei.org> Signed-off-by: Andrew Morton <akpm@osdl.org> |
secmark: Add new packet controls to SELinux | James Morris | Thu, 18 May 2006 03:04:59 -0700 | 6 files changed, 206 insertions(+), 120 deletions(-) | 2153 Bytes |
Add new per-packet access controls to SELinux, replacing the old packet controls. Packets are labeled with the iptables SECMARK and CONNSECMARK targets, then security policy for the packets is enforced with these controls. To allow for a smooth transition to the new controls, the old code is still present, but not active by default. To restore previous behavior, the old controls may be activated at runtime by writing a '1' to /selinux/compat_net, and also via the kernel boot parameter selinux_compat_net. Switching between the network control models requires the security load_policy permission. The old controls will probably eventually be removed and any continued use is discouraged. Signed-off-by: James Morris <jmorris@namei.org> Signed-off-by: Andrew Morton <akpm@osdl.org> |
smbus unhiding kills thermal management | Pavel Machek | Fri, 12 May 2006 11:27:58 -0700 | 1 files changed, 8 insertions(+), 1 deletion(-) | 1760 Bytes |
Do not enable the SMBus device on Asus boards if suspend is used. We do not reenable the device on resume, leading to all sorts of undesirable effects, the worst being a total fan failure after resume on Samsung P35 laptop. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Signed-off-by: Pavel Machek <pavel@suse.cz> Signed-off-by: Andrew Morton <akpm@osdl.org> |
statistics infrastructure | Martin Peschke | Wed, 24 May 2006 15:58:04 -0700 | 7 files changed, 1833 insertions(+), 5 deletions(-) | 768 Bytes |
statistics infrastructure - documentation | Martin Peschke | Wed, 24 May 2006 15:58:01 -0700 | 2 files changed, 743 insertions(+) | 25540 Bytes |
Add statistics infrastructure as common code. Signed-off-by: Martin Peschke <mp3@de.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> |
statistics infrastructure - exploitation: zfcp | Martin Peschke | Wed, 24 May 2006 15:58:06 -0700 | 5 files changed, 50 insertions(+), 3 deletions(-) | 6895 Bytes |
Instrument the zfcp driver and makes it feed statistics data into the statistics infrastructure. Signed-off-by: Martin Peschke <mp3@de.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> |
swsusp resume must not device_suspend() | David Brownell | Mon, 24 Apr 2006 18:21:27 -0700 | 1 files changed, 10 insertions(+), 3 deletions(-) | 1387 Bytes |
I've noticed a bunch of problem reports that go like this: - boot system with some USB devices attached - echo disk > /sys/power/state - ... later resume ... - now those USB devices don't work right - unplug them/replug them, all is OK I recently observed this myself and tracked down one problem. The solution involves what kexec() does in much the same situation: before starting a new kernel, most hardware needs to be reset. Today, swsusp will suspend it instead, which is the root cause of the problem. This seems like something that might need to sit in the MM tree for a while, as it's a longstanding bug and the fix could shake loose driver goofs. Luckily there's a partial workaround already in wide use: link drivers as modules if they use true suspend states (like all USB HCDs), don't link them statically into the kernel image. That workaround is partial because when BIOS takes over a controller, the resume() method has to handle that nasty case too! Last I checked, all the USB HCDs do handle that case; and few drivers other than those HCDs would ever need to worry about such issues. Currently the swsusp resume path puts devices into a bogus suspend state before switching to the new kernel. It's neither the suspend state that the driver left the device in, nor a "device lost power" reset state. Instead, it's a semi-functional state from the kernel which loaded the snapshot. There's no way that a driver can properly resume from that. Some drivers issue resets in their resume methods, but that's wrong for every driver which uses more power states than just "on" and "reset". This patch shuts down (resets) the devices, just like kexec() does, so that non-modular drivers will know they must fully re-initialize even when they wouldn't ordinarily do so during resume(). Signed-off-by: Andrew Morton <akpm@osdl.org> |
swsusp: support creating bigger images (rev. 2) | "Rafael J. Wysocki" | Tue, 09 May 2006 15:30:29 -0700 | 8 files changed, 306 insertions(+), 78 deletions(-) | 9353 Bytes |
Currently swsusp is only capable of creating suspend images that are not bigger than 1/2 of the normal zone, because it needs to create a copy of every page which should be included in the image. This may hurt the system responsiveness after resume, especially on systems with less that 1 GB of RAM. To allow swsusp to create bigger images we can use the observation that if some pages don't change after the snapshot image of the system has been created and before the image is entirely saved, they can be included in the image without copying. Now if the mapped pages that are not mapped by the current task are considered, it turns out that they would change only if they were reclaimed by try_to_free_pages(). Thus if we take them out of reach of try_to_free_pages(), for example by (temporarily) moving them out of their respective LRU lists after creating the image, we will be able to include them in the image without copying. If these pages are included in the image without copying, the amount of free memory needed by swsusp is usually much less than otherwise, so the size of the image may be bigger. This also makes swsusp use less memory during suspend and saves us quite a lot of memory allocations and copyings. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Andrew Morton <akpm@osdl.org> |
x86_64: Check for too many northbridges in IOMMU code | Andi Kleen | Wed, 10 May 2006 21:18:08 -0700 | 1 files changed, 8 insertions(+) | 1262 Bytes |
The IOMMU code can only deal with 8 northbridges. Error out when more are found. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> |
x86_64: make PC Speaker driver work | Mikael Pettersson | Sun, 30 Apr 2006 00:01:33 -0700 | 1 files changed, 19 insertions(+) | 881 Bytes |
The PC Speaker driver's ->probe() routine doesn't even get called in the 64-bit kernels. The reason for that is that the arch code apparently has to explictly add a "pcspkr" platform device in order for the driver core to call the ->probe() routine. arch/i386/kernel/setup.c unconditionally adds a "pcspkr" device, but the x86_64 kernel has no code at all related to the PC Speaker. The patch below copies the relevant code from i386 to x86_64, which makes the PC Speaker work for me on x86_64. Signed-off-by: Andrew Morton <akpm@osdl.org> |