- 29 Jun, 2005 5 commits
-
-
Oleg Nesterov authored
As Steven Rostedt pointed out, there are 2 problems with ITIMER_REAL timers. 1. do_setitimer() does not call del_timer_sync() in case when the timer is not pending (it_real_value() returns 0). This is wrong, the timer may still be running, and it can rearm itself. 2. It calls del_timer_sync() with tsk->sighand->siglock held. This is deadlockable, because timer's handler needs this lock too. Signed-off-by:
Oleg Nesterov <oleg@tv-sign.ru> Acked-by:
Steven Rostedt <rostedt@goodmis.org> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Lennert Buytenhek authored
Fix the same typo in the ixp4xx and ixp2000 watchdog drivers. Signed-off-by:
Lennert Buytenhek <buytenh+lkml@wantstofly.org> Signed-off-by:
-
Luc Van Oostenryck authored
In the setup function, the delay variable is initialized with ints[2], but ints is declared as: int ints[2]; Since the module parameter should correspond to: tipar=timeout,delay I suppose that the following patch fix the problem. Signed-off-by:
Luc Van Oostenryck <luc.vanoostenryck@looxix.net> Signed-off-by:
-
Luca Falavigna authored
Use msleep() in a few places. Signed-off-by:
Luca Falavigna <dktrkranz@gmail.com> Acked-by:
Ingo Molnar <mingo@elte.hu> Acked-by:
Jeff Garzik <jgarzik@pobox.com> Signed-off-by:
-
Wen-chien Jesse Sung authored
This up() should be down() instead. Signed-off-by:
Wen-chien Jesse Sung <jesse@cola.voip.idv.tw> Signed-off-by:
-
- 28 Jun, 2005 35 commits
-
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Ingo Molnar authored
This patch tweaks idle thread setup semantics a bit: instead of setting NEED_RESCHED in init_idle(), we do an explicit schedule() before calling into cpu_idle(). This patch, while having no negative side-effects, enables wider use of cond_resched()s. (which might happen in the stock kernel too, but it's particulary important for voluntary-preempt) Signed-off-by:
-
Jens Axboe authored
Currently we cap request allocations at q->nr_requests, but we allow a batching io context to allocate up to 32 more (default setting). This can flood the queue with request allocations, with only a few batching processes. The real fix would be to limit the number of batchers, but as that isn't currently tracked, I suggest we just cap the maximum number of allocated requests to eg 50% over the limit. This was observed in real life, users typically see this as vmstat bo numbers going off the wall with seconds of no queueing afterwards. Behaviour this bursty is not beneficial. Signed-off-by:
Jens Axboe <axboe@suse.de> Signed-off-by:
-
Neil Brown authored
insert a missing bio_put when writting the md superblock. Without this we have a steady growth in the "bio" slab. Signed-off-by:
Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by:
-
Alexey Dobriyan authored
Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Cc: Eric Biederman <ebiederm@xmission.com> Signed-off-by:
-
Andrew Morton authored
Signed-off-by:
-
Ben Dooks authored
Patch from Ben Dooks Fix the IRQ_LCD so that it is marked as valid since we no longer de-mux this in the main IRQ handler. Signed-off-by:
Ben Dooks <ben-linux@fluff.org> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk>
-
Tony Lindgren authored
Patch from Tony Lindgren This patch was suggested by RMK, and adds a warning on the accuracy of timekeeping when using dynamic tick on some platforms. Depending on the timer implementation, dynamic tick may affect the accuracy of timekeeping. Currently at least OMAP is known to have accurate timekeeping with dynamic tick. Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Ben Dooks authored
Patch from Ben Dooks This provides the s3c24xx audio platform data which can be supplied from any of the board specific drivers. Signed-off-by:
-
Richard Purdie authored
Patch from Richard Purdie Add functions to generate backtraces of both kernel and user processes which allows oprofile's call graphing functionality to be used on arm. This requires unstripped binaries/libs which use a frame pointer. Signed-off-by: Richard Purdie Signed-off-by:
Zwane Mwaikambo <zwane@arm.linux.org.uk> Signed-off-by:
-
Linus Torvalds authored
Merge head 'upstream-20050628-1' of rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev
-
-
Greg Kroah-Hartman authored
Now that we have access to the whole MCFG table, let's properly use it for all pci device accesses (as that's what it is there for, some boxes don't put all the busses into one entry.) If, for some reason, the table is incorrect, we fallback to the "old style" of mmconfig accesses, namely, we just assume the first entry in the table is the one for us, and blindly use it. Signed-off-by:Greg Kroah-Hartman <gregkh@suse.de>
-
Greg Kroah-Hartman authored
Now that we have access to the whole MCFG table, let's properly use it for all pci device accesses (as that's what it is there for, some boxes don't put all the busses into one entry.) If, for some reason, the table is incorrect, we fallback to the "old style" of mmconfig accesses, namely, we just assume the first entry in the table is the one for us, and blindly use it. Signed-off-by: -
Greg Kroah-Hartman authored
This patch is the first step in properly handling the MCFG PCI table. It defines the structures properly, and saves off the table so that the pci mmconfig code can access it. It moves the parsing of the table a little later in the boot process, but still before the information is needed. Signed-off-by: -
Greg Kroah-Hartman authored
Now we can change the pci core to always set this pointer, as pci drivers should use it, not the driver core callback. Signed-off-by: -
Keith Moore authored
drivers/pci/hotplug/cpqphp_core.c calls cpqphp_event_start_thread() in one_time_init(), which is called whenever the hardware is probed. Unfortunately, cpqphp_event_stop_thread() is *always* called when the module is unloaded. If the hardware is never probed, then cpqphp_event_stop_thread() tries to manipulate a couple of uninitialized mutexes. Signed-off-by:
Keith Moore <keithmo@exmsft.com> Signed-off-by:
-
Greg Kroah-Hartman authored
Mostly just cleans up the irq handling logic to be smaller and a bit more descriptive as to what it really does. Signed-off-by: -
Andrew Morton authored
With CONFIG_PCI=n: In file included from include/linux/pci.h:917, from lib/iomap.c:6: include/asm/pci.h:104: warning: `enum pci_dma_burst_strategy' declared inside parameter list include/asm/pci.h:104: warning: its scope is only this definition or declaration, which is probably not what you want. include/asm/pci.h: In function `pci_dma_burst_advice': include/asm/pci.h:106: dereferencing pointer to incomplete type include/asm/pci.h:106: `PCI_DMA_BURST_INFINITY' undeclared (first use in this function) include/asm/pci.h:106: (Each undeclared identifier is reported only once include/asm/pci.h:106: for each function it appears in.) make[1]: *** [lib/iomap.o] Error 1 Signed-off-by: -
David S. Miller authored
After seeing, at best, "guesses" as to the following kind of information in several drivers, I decided that we really need a way for platforms to specifically give advice in this area for what works best with their PCI controller implementation. Basically, this new interface gives DMA bursting advice on PCI. There are three forms of the advice: 1) Burst as much as possible, it is not necessary to end bursts on some particular boundary for best performance. 2) Burst on some byte count multiple. A DMA burst to some multiple of number of bytes may be done, but it is important to end the burst on an exact multiple for best performance. The best example of this I am aware of are the PPC64 PCI controllers, where if you end a burst mid-cacheline then chip has to refetch the data and the IOMMU translations which hurts performance a lot. 3) Burst on a single byte count multiple. Bursts shall end exactly on the next multiple boundary for best performance. Sparc64 and Alpha's PCI controllers operate this way. They disconnect any device which tries to burst across a cacheline boundary. Actually, newer sparc64 PCI controllers do not have this behavior. That is why the "pdev" is passed into the interface, so I can add code later to check which PCI controller the system is using and give advice accordingly. Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Michael Ellerman authored
This is an updated version of Ben's fix-pci-mmap-on-ppc-and-ppc64.patch which is in 2.6.12-rc4-mm1. It fixes the patch to work on PPC iSeries, removes some debug printks at Ben's request, and incorporates your fix-pci-mmap-on-ppc-and-ppc64-fix.patch also. Originally from Benjamin Herrenschmidt <benh@kernel.crashing.org> This patch was discussed at length on linux-pci and so far, the last iteration of it didn't raise any comment. It's effect is a nop on architecture that don't define the new pci_resource_to_user() callback anyway. It allows architecture like ppc who put weird things inside of PCI resource structures to convert to some different value for user visible ones. It also fixes mmap'ing of IO space on those archs. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
Michael Ellerman <michael@ellerman.id.au> Signed-off-by:
-
Kenji Kaneshige authored
This patch adds PCI based I/O xAPIC hot-add support to ACPIPHP driver. When PCI root bridge is hot-added, all PCI based I/O xAPICs under the root bridge are hot-added by this patch. Hot-remove support is TBD. Signed-off-by:
Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by:
-
Kenji Kaneshige authored
This is an ia64 implementation of acpi_register_ioapic() and acpi_unregister_ioapic() interfaces. Signed-off-by:
-
Kenji Kaneshige authored
This patch adds the following new interfaces for I/O xAPIC hotplug. The implementation of these interfaces depends on each architecture. o int acpi_register_ioapic(acpi_handle handle, u64 phys_addr, u32 gsi_base); This new interface is to add a new I/O xAPIC specified by phys_addr and gsi_base pair. phys_addr is the physical address to which the I/O xAPIC is mapped and gsi_base is global system interrupt base of the I/O xAPIC. acpi_register_ioapic returns 0 on success, or negative value on error. o int acpi_unregister_ioapic(acpi_handle handle, u32 gsi_base); This new interface is to remove a I/O xAPIC specified by gsi_base. acpi_unregister_ioapic returns 0 on success, or negative value on error. Signed-off-by: -
Rajesh Shah authored
Current acpiphp code does not distinguish between the physical presence and power state of a device/slot. That is, if a device has to be disabled, it also tries to physically ejects the device. This patch decouples power state from physical presence. You can now echo to the corresponding sysfs power control file to repeatedly enable and disable a device without having to physically re-insert it. Signed-off-by:
Rajesh Shah <rajesh.shah@intel.com> Signed-off-by:
-
Rajesh Shah authored
acpiphp changes to support acpi based root bridge hot-add. Signed-off-by:
-
Rajesh Shah authored
Earlier I reported that Matthew's acpiphp rewrite had problem in powering down slot on my i386 system. The following patch is needed to get the acpiphp rewrite properly powering down the slot. Signed-off-by:
Dely Sy <dely.l.sy@intel.com> Signed-off-by:
-
Rajesh Shah authored
A root bridge may not have directly attached hotpluggable slots under it. Instead, it may have p2p bridges with slots under it. In this case, we need to clean up the p2p bridges and slots properly too. Patch below applies on top of the original patch, and fixes this problem. Without this, acpiphp leaves behind notify handlers on module unload, and subsequent module load attempts don't work properly too. Patch was tested on an ia64 Tiger4 box. Signed-off-by:
-
Rajesh Shah authored
This patch converts acpiphp to use the generic PCI resource assignment code. It's quite large, but most of it is deleting the acpiphp_pci and acpiphp_res files. It's tested on an hp Integrity rx8620 (which won't work without this patch). Testers with other hardware welcomed. Signed-off-by:
Matthew Wilcox <matthew@wil.cx> Signed-off-by:
-
Rajesh Shah authored
Export an acpi interface to get PCI domain/bus/devfn information from the corresponding namespace handle. Used by acpiphp code to transpate the device handle of the hot-plugged root bridge to the corresponding pci location information. Signed-off-by:
-
Rajesh Shah authored
Create new interfaces to recursively add an acpi namespace object to the acpi device list, and recursively start the namespace object. This is needed for ACPI based hotplug of a root bridge hierarchy where the add operation must be performed first and the start operation must be performed separately after the hot-plugged devices have been properly configured. Signed-off-by:
-
Rajesh Shah authored
Read bridge io/mem/pfmem ranges when fixing up the bus so that bus resources are tracked. This is required to properly support pci end device and bridge hotplug. Signed-off-by:
-
Rajesh Shah authored
When hot-plugging an I/O hierarchy that contains many bridges and leaf devices, it's possible that there are not enough resources to start all the device present. If we fail to assign a resource, clear the corresponding value in the pci_dev structure, so other code can take corrective action. Signed-off-by:
-
Rajesh Shah authored
When a root bridge hierarchy is hot-plugged, resource requirements for the new devices may be greater than what the root bridge is decoding. In this case, we want to remove devices that did not get needed resources. These devices have been scanned into bus specific lists but not yet added to the global device list. Make sure the pci remove functions can handle this case. Signed-off-by:
-
