- 12 Jun, 2006 11 commits
-
-
Ben Collins authored
Add support for the following types of hardware: + nodes that have a link speed < PHY speed + 1394b PHYs that are less than S800 capable + 1394b/1394a adapter cable between two 1394b PHYs Also, S1600 and S3200 are now supported if IEEE1394_SPEED_MAX is raised. A probing function is added to nodemgr's config ROM fetching routine which adjusts the allowable speed if an access problem was encountered. Pros and Cons of the approach: + minimum code footprint to support this less widely used hardware + nearly no overhead for unaffected hardware - ineffective before nodemgr began to read the ROM of affected nodes - ineffective if ieee1394 is loaded with disable_nodemgr=1 The speed map CSRs which are published to the bus are not touched by the patch. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Cc: Hakan Ardo <hakan@debian.org> Cc: Calculex <linux@calculex.com> Cc: Robert J. Kosinski <robk@cmcherald.com> Signed-off-by: Ben Collins <bcollins@ubuntu.com>
-
Ben Collins authored
This patch modifies the ohci1394.c file to enable and manage the "cycle too long" interrupt. If this interrupt occurs, the "LinkControl.CycleMaster" bit of the host controller is reseted. This implies, that the host controller does not send "cycle start" packet anymore freezing then the isochronous communication. The management of the interrupt added by the patch is that when the interrupt occurs, the OHCI irq handler prints a kernel log warning and then sets the "LinkControl.CycleMaster" bit again resuming the isochronous communication. Signed-off-by: Jean-Baptiste Mur <jeanbaptiste@maunakeatech.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Ben Collins <bcollins@ubuntu.com>
-
Ben Collins authored
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Ben Collins <bcollins@ubuntu.com>
-
Ben Collins authored
Semaphore to mutex conversion. The conversion was generated via scripts, and the result was validated automatically via a script as well. Signed-off-by: Arjan van de Ven <arjan@infradead.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> Cc: Ben Collins <bcollins@debian.org> Cc: Jody McIntyre <scjody@modernduck.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Ben Collins <bcollins@ubuntu.com>
-
Ben Collins authored
The workarounds are not required for DViCO Momobay FX-3A and AFAIR not for Momobay CX-2. These contain an TSB42AA9A but feature the same firmware_revision value as the older DViCO Momobay CX-1. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Ben Collins <bcollins@ubuntu.com>
-
Ben Collins authored
spotted by Adrian Bunk. Also remove some superfluous comments. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Ben Collins <bcollins@ubuntu.com>
-
Ben Collins authored
when attempting to find the 'last' part of the dma region continue the search from where we left off, instead of starting the search over. Signed-off-by: Jim Westfall <jwestfall@surrealistic.net> Signed-off-by: Ben Collins <bcollins@ubuntu.com>
-
Ben Collins authored
When working with multiple cameras and intensive applications, our logs get flooded with video1394 information which isn't of much interest. Any objections to demoting these messages to debug messages? Signed-off-by: Daniel Drake <dsd@gentoo.org> Signed-off-by: Ben Collins <bcollins@ubuntu.com>
-
Linus Torvalds authored
* 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev: [PATCH] sata_mv: grab host lock inside eng_timeout
-
Paul Mackerras authored
People have been reporting that PPP connections over ptys, such as used with PPTP, will hang randomly when transferring large amounts of data, for instance in http://bugzilla.kernel.org/show_bug.cgi?id=6530. I have managed to reproduce the problem, and the patch below fixes the actual cause. The problem is not in fact in ppp_async.c but in n_tty.c. What happens is that when pptp reads from the pty, we call read_chan() in drivers/char/n_tty.c on the master side of the pty. That copies all the characters out of its buffer to userspace and then calls check_unthrottle(), which calls the pty unthrottle routine, which calls tty_wakeup on the slave side, which calls ppp_asynctty_wakeup, which calls tasklet_schedule. So far so good. Since we are in process context, the tasklet runs immediately and calls ppp_async_process(), which calls ppp_async_push, which calls the tty->driver->write function to send some more output. However, tty->driver->write() returns zero, because the master tty->receive_room is still zero. We haven't returned from check_unthrottle() yet, and read_chan() only updates tty->receive_room _after_ calling check_unthrottle. That means that the driver->write call in ppp_async_process() returns 0. That would be fine if we were going to get a subsequent wakeup call, but we aren't (we just had it, and the buffer is now empty). The solution is for n_tty.c to update tty->receive_room _before_ calling the driver unthrottle routine. The patch below does this. With this patch I was able to transfer a 900MB file over a PPTP connection (taking about 25 minutes), whereas without the patch the connection would always stall in under a minute. Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Mark Lord authored
Bug fix: mv_eng_timeout() calls mv_err_intr() without first grabbing the host lock, which can lead to all sorts of interesting scenarios. This whole error-handling portion of sata_mv is nasty (and will get fixed for the new EH stuff), but for now this patch will help keep it on life-support. Signed-off-by: Mark Lord <liml@rtr.ca> Signed-off-by: Jeff Garzik <jeff@garzik.org>
-
- 11 Jun, 2006 8 commits
-
-
Linus Torvalds authored
* master.kernel.org:/pub/scm/linux/kernel/git/gregkh/pci-2.6: [PATCH] PCI: reverse pci config space restore order [PATCH] PCI: Improve PCI config space writeback [PATCH] PCI: Error handling on PCI device resume [PATCH] PCI: fix pciehp compile issue when CONFIG_ACPI is not enabled
-
Christoph Lameter authored
From: Christoph Lameter <clameter@sgi.com> Looks like a comma was left from the conversion from a struct to an assignment. Signed-off-by: Christoph Lameter <clameter@sgi.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Yu, Luming authored
According to Intel ICH spec, there are several rules that Base Address should be programmed before IOSE (PCICMD register ) enabled. For example ICH7: 12.1.3 SATA : the base address register for the bus master register should be programmed before this bit is set. 11.1.3: PCICMD (USB): The base address register for USB should be programmed before this bit is set. .... To make sure kernel code follow this rule , and prevent unnecessary confusion. I proposal this patch. Signed-off-by: Luming Yu <luming.yu@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Dave Jones authored
At least one laptop blew up on resume from suspend with a black screen due to a lack of this patch. By only writing back config space that is different, we minimise the possibility of accidents like this. Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Jean Delvare authored
We currently don't handle errors properly when resuming a PCI device: * In pci_default_resume() we capture the error code returned by pci_enable_device() but don't pass it up to the caller. Introduced by commit 95a62965 * In pci_resume_device(), the errors possibly returned by the driver's .resume method or by the generic pci_default_resume() function are ignored. This patch fixes both issues. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
akpm@osdl.org authored
Fix build error when CONFIG_ACPI not defined Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Krzysztof Helt authored
This patch sets the max_cache_size value required to tune up scheduler in SMP systems. Otherwise, the calculated migration_cost is too high and task scheduling may lock up. Signed-off-by: Krzysztof Helt <krzysztof.h1@wp.pl> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 10 Jun, 2006 8 commits
-
-
Linus Torvalds authored
* master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6: [SPARC64]: Avoid JBUS errors on some Niagara systems. [FUSION]: Fix mptspi.c build with CONFIG_PM not set. [TG3]: Handle Sun onboard tg3 chips more correctly. [SPARC64]: Dump local cpu registers in sun4v_log_error()
-
Milton Miller authored
From: Milton Miller <miltonm@bga.com> The add_preferred_console call in rtas_console.c was not causing the console to be selected. It turns out that the add_preferred_console was being called after the hvc_console driver was registered. It only works when it is called before the console driver is registered. Reorder hvc_console.o after the hvc_console drivers to allow the selection during console_initcall processing. Signed-off-by: Milton Miller <miltonm@bga.com> Signed-off-by: Anton Blanchard <anton@samba.org> Cc: Paul Mackerras <paulus@samba.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Markus Lidel authored
From: Markus Lidel <Markus.Lidel@shadowconnect.com> - Fixed locking of struct i2o_exec_wait in Executive-OSM - Removed LCT Notify in i2o_exec_probe() which caused freeing memory and accessing freed memory during first enumeration of I2O devices - Added missing locking in i2o_exec_lct_notify() - removed put_device() of I2O controller in i2o_iop_remove() which caused the controller structure get freed to early - Fixed size of mempool in i2o_iop_alloc() - Fixed access to freed memory in i2o_msg_get() See http://bugzilla.kernel.org/show_bug.cgi?id=6561Signed-off-by: Markus Lidel <Markus.Lidel@shadowconnect.com> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Andrew Morton authored
From: Andrew Morton <akpm@osdl.org> Work around the oops reported in http://bugzilla.kernel.org/show_bug.cgi?id=6478. Thanks to Ralf Hildebrandt <ralf.hildebrandt@charite.de> for testing and reporting. Acked-by: Dave Jones <davej@codemonkey.org.uk> Cc: "Brown, Len" <len.brown@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
David Howells authored
From: David Howells <dhowells@redhat.com> Apply some alterations to the memory barrier document that I worked out with Paul McKenney of IBM, plus some of the alterations suggested by Alan Stern. The following changes were made: (*) One of the examples given for what can happen with overlapping memory barriers was wrong. (*) The description of general memory barriers said that a general barrier is a combination of a read barrier and a write barrier. This isn't entirely true: it implies both, but is more than a combination of both. (*) The first example in the "SMP Barrier Pairing" section was wrong: the loads around the read barrier need to touch the memory locations in the opposite order to the stores around the write barrier. (*) Added a note to make explicit that the loads should be in reverse order to the stores. (*) Adjusted the diagrams in the "Examples Of Memory Barrier Sequences" section to make them clearer. Added a couple of diagrams to make it more clear as to how it could go wrong without the barrier. (*) Added a section on memory speculation. (*) Dropped any references to memory allocation routines doing memory barriers. They may do sometimes, but it can't be relied on. This may be worthy of further documentation later. (*) Made the fact that a LOCK followed by an UNLOCK should not be considered a full memory barrier more explicit and gave an example. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Paul E. McKenney <paulmck@us.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpcLinus Torvalds authored
* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc: [PATCH] powerpc: Fix cell blade detection [PATCH] powerpc: Fix call to ibm,client-architecture-support powerpc: Fix machine check problem on 32-bit kernels
-
David S. Miller authored
Doing PCI config space accesses to non-present PCI slots can result in fatal JBUS errors if the PCI config access hypervisor call is performed on cpus other than the boot cpu. PCI config space accesses to present PCI slots works just fine. Recursively traverse the OBP device tree under the PCI controller node and record all present device IDs into a small hash table. Avoid the hypervisor call for any PCI config space access attempt for a device not recorded in the hash table. Signed-off-by: David S. Miller <davem@davemloft.net>
-
Tom "spot" Callaway authored
Signed-off-by: Tom "spot" Callaway <tcallawa@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 09 Jun, 2006 5 commits
-
-
David S. Miller authored
Get rid of all the SUN_570X logic and instead: 1) Make sure MEMARB_ENABLE is set when we probe the SRAM for config information. If that is off we will get timeouts. 2) Always try to sync with the firmware, if there is no firmware running do not treat it as an error and instead just report it the first time we notice this condition. 3) If there is no valid SRAM signature, assume the device is onboard by setting TG3_FLAG_EEPROM_WRITE_PROT. Update driver version and release date. With help from Michael Chan and Fabio Massimo Di Nitto. Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
This makes the debugging information more usable. Signed-off-by: David S. Miller <davem@davemloft.net>
-
Arnd Bergmann authored
The IBM Cell blade firmware might confuse the kernel to think it's a pSeries machine. This fixes it for now. With a bit of luck, the firmware will be updated to avoid that in the future but currently that patch is needed. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Benjamin Herrenschmidt authored
The code in prom_init.c calling the firmware ibm,client-architecture-support method on pSeries has a bug where it fails to properly pass the instance handle of the firmware object when trying to call a method. Result ranges from the call doing nothing to the firmware crashing. (Found by Segher, thanks !) Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Paul Mackerras authored
This fixes a bug found by Dave Jones that means that it is possible for userspace to provoke a machine check on 32-bit kernels. This also fixes a couple of other places where I found similar problems by inspection. Signed-off-by: Paul Mackerras <paulus@samba.org>
-
- 08 Jun, 2006 8 commits
-
-
Linus Torvalds authored
* 'upstream-fixes' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6: e1000: remove risky prefetch on next_skb->data e1000: fix ethtool test irq alloc as "probe" [PATCH] bcm43xx: add DMA rx poll workaround to DMA4
-
Martin Schwidefsky authored
From: Martin Schwidefsky <schwidefsky@de.ibm.com> __futex_atomic_op needs to do an atomic operation in the user address space, not the kernel address space. Add the missing sacf 256/sacf 0 to switch to the secondary mode before doing the compare-and-swap. In addition add another fixup for catch specification exceptions if the compare-and-swap address is not aligned. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Jens Axboe authored
Looking at the reiser4 crash, I found a leak in debugfs. In debugfs_mknod(), we create the inode before checking if the dentry already has one attached. We don't free it if that is the case. These bugs happen quite often, I'm starting to think we should disallow such coding in CodingStyle. Signed-off-by: Jens Axboe <axboe@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Jens Axboe authored
There's a race between shutting down one io scheduler and firing up the next, in which a new io could enter and cause the io scheduler to be invoked with bad or NULL data. To fix this, we need to maintain the queue lock for a bit longer. Unfortunately we cannot do that, since the elevator init requires to be run without the lock held. This isn't easily fixable, without also changing the mempool API. So split the initialization into two parts, and alloc-init operation and an attach operation. Then we can preallocate the io scheduler and related structures, and run the attach inside the lock after we detach the old one. This patch has survived 30 minutes of 1 second io scheduler switching with a very busy io load. Signed-off-by: Jens Axboe <axboe@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Malcom Parsons authored
From: Malcom Parsons <malcolm.parsons@gmail.com> When scrolling up in SCROLL_PAN_REDRAW mode with a large limited scroll region, the bottom few lines have to be redrawn. Without this patch, the wrong text is drawn into these lines, corrupting the display. Observed in 2.6.14 when running an IRC client in the Nintendo DS linux port. I haven't tested if scrolling down has the same problem. Signed-off-by: Antonino Daplas <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Ralf Baechle authored
From: Ralf Baechle <ralf@linux-mips.org> <linux/mempolicy.h> uses struct mm_struct and relies on a definition or declaration somehow magically being dragged in which may result in a build: [...] CC mm/mempolicy.o In file included from mm/mempolicy.c:69: include/linux/mempolicy.h:150: warning: âstruct mm_structâ declared inside parameter list include/linux/mempolicy.h:150: warning: its scope is only this definition or declaration, which is probably not what you want include/linux/mempolicy.h:175: warning: âstruct mm_structâ declared inside parameter list mm/mempolicy.c:622: error: conflicting types for âdo_migrate_pagesâ include/linux/mempolicy.h:175: error: previous declaration of âdo_migrate_pagesâ was here mm/mempolicy.c:1661: error: conflicting types for âmpol_rebind_mmâ include/linux/mempolicy.h:150: error: previous declaration of âmpol_rebind_mmâ was here make[1]: *** [mm/mempolicy.o] Error 1 make: *** [mm] Error 2 [ralf@denk linux-ip35]$ Including <linux/sched.h> is a step into direction of include hell so fixed by adding a forward declaration of struct mm_struct instead. Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Lennert Buytenhek authored
From: Lennert Buytenhek <buytenh@wantstofly.org> The recent renaming of m48t86's ->readb() and ->writeb() platform driver methods (2d7b20c1) to ->readbyte() and ->writebyte() to fix the ia64 build broke the build of the cirrus ep93xx ARM platform. This patch fixes it up. Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Andy Currid authored
From: "Andy Currid" <ACurrid@nvidia.com> This patch fixes a kernel panic during boot that occurs on NVIDIA platforms that have HPET enabled. When HPET is enabled, the standard timer IRQ is routed to IOAPIC pin 2 and is advertised as such in the ACPI APIC table - but an earlier workaround in the kernel was ignoring this override. The fix is to honor timer IRQ overrides from ACPI when HPET is detected on an NVIDIA platform. Signed-off-by: Andy Currid <acurrid@nvidia.com> Cc: "Brown, Len" <len.brown@intel.com> Cc: "Yu, Luming" <luming.yu@intel.com> Cc: Andi Kleen <ak@muc.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-