An error occurred fetching the project authors.
- 08 Jan, 2005 1 commit
-
-
James Nelson authored
Document kernel parameters for tipar driver. Signed-off-by: James Nelson <james4765@gmail.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
- 07 Jan, 2005 1 commit
-
-
David Mosberger authored
I was in need of a 3.3V/dual-voltage-capable PCI sound-card and, as luck would have it, the only card of that sort in the local computer store was one that _still_ has a DMA engine that cannot even DMA to all 32 bits (it's limited to 28 bits). Hard to believe, but true (the card in question is a "SoundBlaster Live! 24-bit" with a CA0106 chip; stay away from that one if you can...). Anyhow, since I don't like it when PCI cards don't work in my machine, I created the attached patch which adds a new machine-vector to enable support of such broken cards. With the patch applied, you can either configure the kernel for "HP-zx1/sx1000+swiotlb" or configure for "generic" and boot with option "machvec=hpzx1_swiotlb" to enable support for broken PCI devices. The patch works as follows: the new machvec implements a I/O MMU which will use the hardware I/O MMU whenever possible but fall back on the software I/O TLB when encountering a device that can't be supported by the hardware I/O MMU. Fortunately, we don't have to mess with MAX_DMA_ADDRESS or create a new zone: the software I/O TLB allocates its memory as low as possible and early in the boot-process, so on any machine with low memory, we're pretty much guaranteed that we'll get a reasonable amount of low memory, which is all we need to properly support broken PCI cards. Note that I made a small change to swiotlb.c: I added a swiotlb_init_with_default_size() function to let the new I/O MMU initialize the software I/O TLB with less than 64MB (which is way too much for the limited uses we'll see for the broken PCI devices; for example, the CA0106 chip allocates only coherent buffers of about 128KB). The patch has been tested on a zx1 machine in the generic, hpzx1, and hpzx1_swiotlb configuration. Thanks to Alex Williamson for the suggestion of doing this via a completely separate machvec. Signed-off-by: David Mosberger-Tang <davidm@hpl.hp.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
-
- 04 Jan, 2005 2 commits
-
-
Randy Dunlap authored
When setting the 'cpu_isolated_map' mask, check that the user input value is valid (in range 0 .. NR_CPUS - 1). Also fix up kernel-parameters.txt for this parameter. Signed-off-by: Randy Dunlap <rddunlap@osdl.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Matt Domsch authored
EDD: add edd=off and edd=skipmbr command line options New command line options edd=off (or edd=of) edd=skipmbr (or edd=sk) runtime options for disabling all EDD int13 calls completely, or for skipping the int13 READ SECTOR calls, respectively. These are provided to allow Linux distributions to include CONFIG_EDD=m, yet allow end-users to disable parts of EDD which may not work well with their system's BIOS. I incorporated comments from Randy Dunlap, and got an ack from Andi Kleen. Signed-off-by: Matt Domsch <Matt_Domsch@dell.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
- 03 Jan, 2005 1 commit
-
-
Brent Casavant authored
NUMA systems running current Linux kernels suffer from substantial inequities in the amount of memory allocated from each NUMA node during boot. In particular, several large hashes are allocated using alloc_bootmem, and as such are allocated contiguously from a single node each. This becomes a problem for certain workloads that are relatively common on big-iron HPC NUMA systems. In particular, a number of MPI and OpenMP applications which require nearly all available processors in the system and nearly all the memory on each node run into difficulties. Due to the uneven memory distribution onto a few nodes, any thread on those nodes will require a portion of its memory be allocated from remote nodes. Any access to those memory locations will be slower than local accesses, and thereby slows down the effective computation rate for the affected CPUs/threads. This problem is further amplified if the application is tightly synchronized between threads (as is often the case), as they entire job can run only at the speed of the slowest thread. Additionally since these hashes are usually accessed by all CPUS in the system, the NUMA network link on the node which hosts the hash experiences disproportionate traffic levels, thereby reducing the memory bandwidth available to that node's CPUs, and further penalizing performance of the threads executed thereupon. As such, it is desired to find a way to distribute these large hash allocations more evenly across NUMA nodes. Fortunately current kernels do perform allocation interleaving for vmalloc() during boot, which provides a stepping stone to a solution. This series of patches enables (but does not require) the kernel to allocate several boot time hashes using vmalloc rather than alloc_bootmem, thereby causing the hashes to be interleaved amongst NUMA nodes. In particular the dentry cache, inode cache, TCP ehash, and TCP bhash have been changed to be allocated in this manner. Due to the limited vmalloc space on architectures such as i386, this behavior is turned on by default only for IA64 NUMA systems (though there is no reason other interested architectures could not enable it if desired). Non-IA64 and non-NUMA systems continue to use the existing alloc_bootmem() allocation mechanism. A boot line parameter "hashdist" can be set to override the default behavior. The following two sets of example output show the uneven distribution just after boot, using init=/bin/sh to eliminate as much non-kernel allocation as possible. Without the boot hash distribution patches: Nid MemTotal MemFree MemUsed (in kB) 0 3870656 3697696 172960 1 3882992 3866656 16336 2 3883008 3866784 16224 3 3882992 3866464 16528 4 3883008 3866592 16416 5 3883008 3866720 16288 6 3882992 3342176 540816 7 3883008 3865440 17568 8 3882992 3866560 16432 9 3883008 3866400 16608 10 3882992 3866592 16400 11 3883008 3866400 16608 12 3882992 3866400 16592 13 3883008 3866432 16576 14 3883008 3866528 16480 15 3864768 3848256 16512 ToT 62097440 61152096 945344 Notice that nodes 0 and 6 have a substantially larger memory utilization than all other nodes. With the boot hash distribution patch: Nid MemTotal MemFree MemUsed (in kB) 0 3870656 3789792 80864 1 3882992 3843776 39216 2 3883008 3843808 39200 3 3882992 3843904 39088 4 3883008 3827488 55520 5 3883008 3843712 39296 6 3882992 3843936 39056 7 3883008 3844096 38912 8 3882992 3843712 39280 9 3883008 3844000 39008 10 3882992 3843872 39120 11 3883008 3843872 39136 12 3882992 3843808 39184 13 3883008 3843936 39072 14 3883008 3843712 39296 15 3864768 3825760 39008 ToT 62097440 61413184 684256 While not perfectly even, we can see that there is a substantial improvement in the spread of memory allocated by the kernel during boot. The remaining uneveness may be due in part to further boot time allocations that could be addressed in a similar manner, but some difference is due to the somewhat special nature of node 0 during boot. However the uneveness has fallen to a much more acceptable level (at least to a level that SGI isn't concerned about). The astute reader will also notice that in this example, with this patch approximately 256 MB less memory was allocated during boot. This is due to the size limits of a single vmalloc. More specifically, this is because the automatically computed size of the TCP ehash exceeds the maximum size which a single vmalloc can accomodate. However this is of little practical concern as the vmalloc size limit simply reduces one ridiculously large allocation (512MB) to a slightly less ridiculously large allocation (256MB). In practice machines with large memory configurations are using the thash_entries setting to limit the size of the TCP ehash _much_ lower than either of the automatically computed values. Illustrative of the exceedingly large nature of the automatically computed size, SGI currently recommends that customers boot with thash_entries=2097152, which works out to a 32MB allocation. In any case, setting hashdist=0 will allow for allocations in excess of vmalloc limits, if so desired. Other than the vmalloc limit, great care was taken to ensure that the size of TCP hash allocations was not altered by this patch. Due to slightly different computation techniques between the existing TCP code and alloc_large_system_hash (which is now utilized), some of the magic constants in the TCP hash allocation code were changed. On all sizes of system (128MB through 64GB) that I had access to, the patched code preserves the previous hash size, as long as the vmalloc limit (256MB on IA64) is not encountered. There was concern that changing the TCP-related hashes to use vmalloc space may adversely impact network performance. To this end the netperf set of benchmarks was run. Some individual tests seemed to benefit slightly, some seemed to be harmed slightly, but in all cases the average difference with and without these patches was well within the variabilty I would see from run to run. The following is the overall netperf averages (30 10 second runs each) against an older kernel with these same patches. These tests were run over loopback as GigE results were so inconsistent run to run both with and without these patches that they provided no meaningful comparison that I could discern. I used the same kernel (IA64 generic) for each run, simply varying the new "hashdist" boot parameter to turn on or off the new allocation behavior. In all cases the thash_entries value was manually specified as discussed previously to eliminate any variability that might result from that size difference. HP ZX1, hashdist=0 ================== TCP_RR = 19389 TCP_MAERTS = 6561 TCP_STREAM = 6590 TCP_CC = 9483 TCP_CRR = 8633 HP ZX1, hashdist=1 ================== TCP_RR = 19411 TCP_MAERTS = 6559 TCP_STREAM = 6584 TCP_CC = 9454 TCP_CRR = 8626 SGI Altix, hashdist=0 ===================== TCP_RR = 16871 TCP_MAERTS = 3925 TCP_STREAM = 4055 TCP_CC = 8438 TCP_CRR = 7750 SGI Altix, hashdist=1 ===================== TCP_RR = 17040 TCP_MAERTS = 3913 TCP_STREAM = 4044 TCP_CC = 8367 TCP_CRR = 7538 I believe the TCP_CC and TCP_CRR are the tests most sensitive to this particular change. But again, I want to emphasize that even the differences you see above are _well_ within the variability I saw from run to run of any given test. In addition, Jose Santos at IBM has run specSFS, which has been particularly sensitive to TLB issues, against these patches and saw no performance degredation (differences down in the noise). This patch: Modifies alloc_large_system_hash to enable the use of vmalloc to alleviate boottime allocation imbalances on NUMA systems. Due to limited vmalloc space on some architectures (i.e. x86), the use of vmalloc is enabled by default only on NUMA IA64 kernels. There should be no problem enabling this change for any other interested NUMA architecture. Signed-off-by: Brent Casavant <bcasavan@sgi.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
- 13 Dec, 2004 2 commits
-
-
Andrew Morton authored
Avoid documenting something which isn't there. Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Magnus Damm authored
I recently learnt that limiting RAM with by using only "mem=xxxM" is no good on machines equipped with PCI. In my case (vanilla 2.6.9) the cardbus bridge on my laptop got mapped to the unused RAM area which resulted in wierd errors due to the collision. The right solution is to use "mem=" together with "memmap=" to mark the unused RAM area reserved. Henceforth I force the kernel to use 2016MiB by passing "mem=2016M memmap=32M#2016M" instead of just "mem=2016M". Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
- 05 Dec, 2004 1 commit
-
-
Len Brown authored
ex_access_region Region EmbeddedControl(3) has no handler http://bugzilla.kernel.org/show_bug.cgi?id=1690Signed-off-by: David Shaohua Li <shaohua.li@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
-
- 01 Dec, 2004 1 commit
-
-
Len Brown authored
Now "max_cstate=" instead of "acpi_cstate_limit=" Delete redundant static cstate flags .c2 and .c3 http://bugme.osdl.org/show_bug.cgi?id=3549 For static processor driver, boot cmdline: processor.max_cstate=2 For processor module, /etc/modprobe.conf: options processor max_cstate=2 or # modprobe processor max_cstate=2 From kernel or kernel module: #include <linux/acpi.h> acpi_set_cstate_limit(2); Suggested-by: Pavel Machek Signed-off-by: Len Brown <len.brown@intel.com>
-
- 19 Nov, 2004 2 commits
-
-
Magnus Damm authored
The kernel parameter "nohighio" seems to be gone in the code, but the parameter is still left in the documentation. Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Bjorn Helgaas authored
This adds an early polled-mode "uart" console driver, based on Andi Kleen's early_printk work. The difference is that this locates the UART device directly by its MMIO or I/O port address, so we don't have to make assumptions about how ttyS devices will be named. After the normal serial driver starts, we try to locate the matching ttyS device and start a console there. Sample usage: console=uart,io,0x3f8 console=uart,mmio,0xff5e0000,115200n8 If the baud rate isn't specified, we peek at the UART to figure it out. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
- 18 Nov, 2004 1 commit
-
-
Bartlomiej Zolnierkiewicz authored
From: Magnus Damm <magnus.damm@gmail.com> This patch removes ide parameters marked as obsolete in the source and adds documentation for "ide=". I think I got it right, the important part for me is "ide=nodma". Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
-
- 16 Nov, 2004 1 commit
-
-
Cal Peake authored
This patch updates Documentation/kernel-parameters.txt with the proper SCSI LUNs params and adds a description for 'max_luns'. Signed-off-by: Cal Peake <cp@absolutedigital.net> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
-
- 14 Nov, 2004 1 commit
-
-
Jens Axboe authored
Correct wrong paths and add link to deadline documentation. Patch from Christian Kujau <evil@g-house.de> Signed-off-by: Jens Axboe <axboe@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
- 07 Nov, 2004 3 commits
-
-
James Nelson authored
Remove deleted module option in Documentation/kernel-parameters.txt Signed-off-by: James Nelson <james4765@gmail.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Pavel Fedin authored
This patch allows the kernel to configure port's mode without help of BIOS. It is needed on my machine because its firmware simply ignores the parallel port leaving in unidirectional SPP mode. Notes on usage: To configure the port you need to: - if parport_pc driver is compiled as a module: specify parport_pc init_mode=[spp|ps2|epp|ecp|ecpepp] in /etc/modules file (for Debian Linux). - if the driver is linked statically with the kernel: specify parport_init_mode=[spp|ps2|epp|ecp|ecpepp] in kernel's arguments. This patch is intended for use primarily on Pegasos machines but it will work on any computer with VIA8231 south bridge. In this case it will override BIOS setting if you tell the driver to configure the port. BIOS setting will be honored if you omit init_mode parameter. Technical details: 1. On Pegasos standard port settings (set by OpenFirmware) are: IRQ=7, DMA=3, base address=0x3BC, mode is unidirectional SPP. 2. The patch changes only port mode, all other settings are preserved. So if you have a PC with VIA8231 and use driver to configure the port you'll still be able to change IRQ, DMA and base address in BIOS and these settings will be kept. 3. One exclusion: if you tell the driver to turn on EPP mode (specify epp or ecpepp value) and if default base address is 0x3BC (this is the case on Pegasos) the port will be moved to 0x378. EPP port can't have 0x3BC as the base. Known problems: 1. ECP+EPP mode is strange, it doesn't work even on several PC's i tested with Linux. ECP mode is detected and EPP is not. So if you get the same thing, it's not my fault. I just have no time to deal with it, current result is enough for me. 2. Not all devices work on Pegasos, i tried my Genuis-HR6 parallel port scanner and parallel ZIP drive and both of them don't work. ZIP drive is detected properly but then suddenly gets offline. Scanner does not answer any command at all. Without the patch the same thing happens. Obviously Pegasos has some more problems which are not discovered and not fixed yet. Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Stelian Pop authored
Signed-off-by: Stelian Pop <stelian@popies.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
- 30 Oct, 2004 1 commit
-
-
Matthew Wilcox authored
- Add the PARISC tag (Thibaut Varene) - Mark some existing PA-RISC specific entries with it (Thibaut Varene) - Document pdcchassis (Thibaut Varene)
-
- 29 Oct, 2004 1 commit
-
-
Dmitry Torokhov authored
I8K: Switch to using module_param, allow switching 'power_status' through sysfs. Signed-off-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
- 28 Oct, 2004 2 commits
-
-
Andrew Morton authored
From: Bjorn Helgaas <bjorn.helgaas@hp.com> Now that PCI interrupts are routed in pci_enable_device(), remove the unconditional routing previously done in pci_acpi_init(). This has the potential to break drivers that don't use pci_enable_device() correctly, so I also added a "pci=routeirq" kernel option that restores the previous behavior. I intend to remove that option, along with all the code below, in a month or so. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Stelian Pop authored
* use module_param() instead of MODULE_PARM() and __setup() * use MODULE_VERSION() Signed-off-by: Stelian Pop <stelian@popies.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
- 26 Oct, 2004 1 commit
-
-
Dmitry Torokhov authored
parkbd.port and parkbd.mode Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
-
- 20 Oct, 2004 2 commits
-
-
Phil Oester authored
The scsihosts boot parameter was removed in 2.5.73, but references to it still exist in docs. Cleanup below. Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Zwane Mwaikambo authored
The 'noapic' kernel parameter only disables IOAPIC use and not all the APICs (which would include local APICs) in the system. Signed-off-by: Zwane Mwaikambo <zwane@fsmlabs.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
- 19 Oct, 2004 1 commit
-
-
Suresh B. Siddha authored
Sync x86_64 noexec behaviour with i386. And remove all the confusing noexec related boot parameters. Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
- 18 Oct, 2004 1 commit
-
-
Len Brown authored
to disable/enable C2 or C3 blacklist entries for R40e and Medion 41700 http://bugme.osdl.org/show_bug.cgi?id=3549 from Andi Kleen
-
- 03 Oct, 2004 2 commits
-
-
Randy Dunlap authored
Remove lingering PC-9800 doc. Signed-off-by: Randy Dunlap <rddunlap@osdl.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Nick Piggin authored
Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
- 24 Sep, 2004 1 commit
-
-
Bjorn Helgaas authored
disabled by passing i8042.noacpi as a boot parameter. Original code by Bjorn Helgaas <bjorn.helgaas@hp.com>, reworked by Dmitry Torokhov <dtor@mail.ru>, FixedIO support from Hans-Frieder Vogt <hfvogt@gmx.net> Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Vojtech Pavlik <vojtech@suse.cz>
-
- 17 Sep, 2004 2 commits
-
-
Ingo Molnar authored
There are a few devices that use lots of ioremap space. vmalloc space is a showstopper problem for them. this patch adds the vmalloc=<size> boot parameter to override __VMALLOC_RESERVE. The default is 128mb right now - e.g. vmalloc=256m doubles the size. Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Arjan van de Ven <arjanv@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Deepak Saxena authored
Added a new pci= command line option specific to ARM systems in -rc2 and it should be added to kernel-parameters.txt. Signed-off-by: Deepak Saxena <dsaxena@plexity.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
- 10 Sep, 2004 1 commit
-
-
John Stultz authored
Apparently there is an issue w/ the IBM x440/x445's BIOS's USB Legacy support. Due to the delay in issuing SMI's across the IOAPICs, its possible for I/O to ports 60/64 to cause register corruption. The solution is to disable the BIOS's USB Legacy support early in boot(via PCI quirks) for x440/x445 systems. Originally written by Vojtech against SuSE's tree, this patch was then updated to disable EHCI by Aleksey Gorelov, cleaned up by Pete Zaitcev for 2.4 and finally tweaked and updated against 2.6 by me. I've lightly tested this version of the patch, but it differs little from what Aleksey, Pete and I have been testing for 2.4. Signed-off-by: John Stultz <jstultz@us.ibm.com> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
- 01 Sep, 2004 1 commit
-
-
Len Brown authored
new cmdline options: "acpi_dbg_layer=", "acpi_dbg_level=" and /proc/acpi/debug_layer, debug_level now describe levels http://bugzilla.kernel.org/show_bug.cgi?id=2398
-
- 27 Aug, 2004 1 commit
-
-
Arjan van de Ven authored
From: William Lee Irwin III <wli@holomorphy.com> The patch (from Ingo) below is quite interesting, it allows the use of readprofile not for statistical tine sampling, but for seeing where calls to schedule() come from, so it can give some insight to the "where do my context switches come from" question. Boot with `profile=schedul2' to activate this feature. Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
- 24 Aug, 2004 1 commit
-
-
Adam Kropelin authored
Adds a kernel boot parameter "lpj=NNN" which allows the operator to specify the loops-per-jiffy value. This shaves up to a quarter of a second off boot times, which are critical for embedded appliances. It's a bit thin, but the code is in __init. Signed-off-by: Adam Kropelin <akropel1@rochester.rr.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
- 23 Aug, 2004 2 commits
-
-
Mark Broadbent authored
The APIC and IO-APIC code is very verbose on startup especially on SMP machines. This patch allows the verbosity of the APIC code to be controlled through the boot-time option apic= using three levels: quiet, verbose and debug. The default level is quiet. Signed-off-by: Mark Broadbent <markb@wetlettuce.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Matt Porter authored
Adds documentation of the PPC noltlbs and nobats kernel cmdline parameters. noltlbs is a new option and nobats never had an entry. Signed-off-by: Matt Porter <mporter@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
- 17 Aug, 2004 1 commit
-
-
Tom Rini authored
Signed-off-by: Leigh Brown <leigh@solinno.co.uk> Signed-off-by: Tom Rini <trini@kernel.crashing.org>
-
- 11 Jul, 2004 1 commit
-
-
Andrew Morton authored
Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
- 05 Jul, 2004 1 commit
-
-
Adrian Bunk authored
allowdma0 is gone in 2.6, the patch below removes the mentionings of this option in the documentation. Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-