Eric Sandeen [Sat, 28 Oct 2006 17:38:27 +0000 (10:38 -0700)]
[PATCH] jbd: journal_dirty_data re-check for unmapped buffers
When running several fsx's and other filesystem stress tests, we found
cases where an unmapped buffer was still being sent to submit_bh by the
ext3 dirty data journaling code.
I saw this happen in two ways, both related to another thread doing a
truncate which would unmap the buffer in question.
Either we would get into journal_dirty_data with a bh which was already
unmapped (although journal_dirty_data_fn had checked for this earlier, the
state was not locked at that point), or it would get unmapped in the middle
of journal_dirty_data when we dropped locks to call sync_dirty_buffer.
By re-checking for mapped state after we've acquired the bh state lock, we
should avoid these races. If we find a buffer which is no longer mapped,
we essentially ignore it, because journal_unmap_buffer has already decided
that this buffer can go away.
I've also added tracepoints in these two cases, and made a couple other
tracepoint changes that I found useful in debugging this.
Signed-off-by: Eric Sandeen <esandeen@redhat.com> Cc: <linux-ext4@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Randy Dunlap [Sat, 28 Oct 2006 17:38:26 +0000 (10:38 -0700)]
[PATCH] ext4: fix printk format warnings
fs/ext4/resize.c:72: warning: long long unsigned int format, __u64 arg (arg 4)
fs/ext4/resize.c:76: warning: long long unsigned int format, __u64 arg (arg 4)
fs/ext4/resize.c:81: warning: long long unsigned int format, __u64 arg (arg 4)
fs/ext4/resize.c:85: warning: long long unsigned int format, __u64 arg (arg 4)
fs/ext4/resize.c:89: warning: long long unsigned int format, __u64 arg (arg 4)
fs/ext4/resize.c:89: warning: long long unsigned int format, __u64 arg (arg 5)
fs/ext4/resize.c:93: warning: long long unsigned int format, __u64 arg (arg 4)
fs/ext4/resize.c:93: warning: long long unsigned int format, __u64 arg (arg 5)
fs/ext4/resize.c:98: warning: long long unsigned int format, __u64 arg (arg 4)
fs/ext4/resize.c:103: warning: long long unsigned int format, __u64 arg (arg 4)
fs/ext4/resize.c:109: warning: long long unsigned int format, __u64 arg (arg 4)
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Martin Bligh [Sat, 28 Oct 2006 17:38:25 +0000 (10:38 -0700)]
[PATCH] Use min of two prio settings in calculating distress for reclaim
If try_to_free_pages / balance_pgdat are called with a gfp_mask specifying
GFP_IO and/or GFP_FS, they will reclaim the requisite number of pages, and the
reset prev_priority to DEF_PRIORITY (or to some other high (ie: unurgent)
value).
However, another reclaimer without those gfp_mask flags set (say, GFP_NOIO)
may still be struggling to reclaim pages. The concurrent overwrite of
zone->prev_priority will cause this GFP_NOIO thread to unexpectedly cease
deactivating mapped pages, thus causing reclaim difficulties.
Fix this is to key the distress calculation not off zone->prev_priority, but
also take into account the local caller's priority by using
min(zone->prev_priority, sc->priority)
Signed-off-by: Martin J. Bligh <mbligh@google.com> Cc: Nick Piggin <nickpiggin@yahoo.com.au> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Martin Bligh [Sat, 28 Oct 2006 17:38:24 +0000 (10:38 -0700)]
[PATCH] vmscan: Fix temp_priority race
The temp_priority field in zone is racy, as we can walk through a reclaim
path, and just before we copy it into prev_priority, it can be overwritten
(say with DEF_PRIORITY) by another reclaimer.
The same bug is contained in both try_to_free_pages and balance_pgdat, but
it is fixed slightly differently. In balance_pgdat, we keep a separate
priority record per zone in a local array. In try_to_free_pages there is
no need to do this, as the priority level is the same for all zones that we
reclaim from.
Impact of this bug is that temp_priority is copied into prev_priority, and
setting this artificially high causes reclaimers to set distress
artificially low. They then fail to reclaim mapped pages, when they are,
in fact, under severe memory pressure (their priority may be as low as 0).
This causes the OOM killer to fire incorrectly.
From: Andrew Morton <akpm@osdl.org>
__zone_reclaim() isn't modifying zone->prev_priority. But zone->prev_priority
is used in the decision whether or not to bring mapped pages onto the inactive
list. Hence there's a risk here that __zone_reclaim() will fail because
zone->prev_priority ir large (ie: low urgency) and lots of mapped pages end up
stuck on the active list.
Fix that up by decreasing (ie making more urgent) zone->prev_priority as
__zone_reclaim() scans the zone's pages.
This bug perhaps explains why ZONE_RECLAIM_PRIORITY was created. It should be
possible to remove that now, and to just start out at DEF_PRIORITY?
Cc: Nick Piggin <nickpiggin@yahoo.com.au> Cc: Christoph Lameter <clameter@engr.sgi.com> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* master.kernel.org:/pub/scm/linux/kernel/git/gregkh/pci-2.6:
PCI: Remove quirk_via_abnormal_poweroff
PCI: reset pci device state to unknown state for resume
PCI: x86-64: mmconfig missing printk levels
PCI: fix pci_fixup_video as it blows up on sparc64
acpiphp: fix latch status
Andrew Morton [Fri, 27 Oct 2006 18:42:37 +0000 (11:42 -0700)]
[PATCH] drivers: wait for threaded probes between initcall levels
The multithreaded-probing code has a problem: after one initcall level (eg,
core_initcall) has been processed, we will then start processing the next
level (postcore_initcall) while the kernel threads which are handling
core_initcall are still executing. This breaks the guarantees which the
layered initcalls previously gave us.
IOW, we want to be multithreaded _within_ an initcall level, but not between
different levels.
Fix that up by causing the probing code to wait for all outstanding probes at
one level to complete before we start processing the next level.
Karsten Wiese [Fri, 20 Oct 2006 21:45:36 +0000 (14:45 -0700)]
PCI: Remove quirk_via_abnormal_poweroff
My K8T800 mobo resumes fine from suspend to ram with and without patch
applied against 2.6.18.
quirk_via_abnormal_poweroff makes some boards not boot 2.6.18, so IMO patch
should go to head, 2.6.18.2 and everywhere "ACPI: ACPICA 20060623" has been
applied.
Remove quirk_via_abnormal_poweroff
Obsoleted by "ACPI: ACPICA 20060623":
<snip>
Implemented support for "ignored" bits in the ACPI
registers. According to the ACPI specification, these
bits should be preserved when writing the registers via
a read/modify/write cycle. There are 3 bits preserved
in this manner: PM1_CONTROL[0] (SCI_EN), PM1_CONTROL[9],
and PM1_STATUS[11].
http://bugzilla.kernel.org/show_bug.cgi?id=3691
</snip>
Signed-off-by: Karsten Wiese <fzu@wemgehoertderstaat.de> Cc: Bob Moore <robert.moore@intel.com> Cc: "Brown, Len" <len.brown@intel.com> Acked-by: Dave Jones <davej@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Shaohua Li [Fri, 20 Oct 2006 21:45:32 +0000 (14:45 -0700)]
PCI: reset pci device state to unknown state for resume
Considering below scenario:
1.Unload a PCI device's driver, the device ->current remains in PCI_D0.
2.Do suspend/resume circle. After that, BIOS puts the device to D3.
3.Reload the device driver. The calling pci_set_power_state in the
driver can't change the state to D0, as set_power_state thinks the
device is already in D0.
A bug is reported at http://bugzilla.kernel.org/show_bug.cgi?id=6024
Pat attached a patch at
http://marc.theaimsgroup.com/?l=linux-pci&m=114049761428561&w=2 for this
issue, but it's lost. As pci_set_power_state can handle D3 -> D0
correctly (restore config space), I simplified Patrick's patch.
Signed-off-by: Shaohua Li <shaohua.li@intel.com> Cc: Patrick Mochel <mochel@digitalimplant.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Gavin McCullagh [Thu, 26 Oct 2006 06:05:52 +0000 (23:05 -0700)]
[TCP] H-TCP: fix integer overflow
When using H-TCP with a single flow on a 500Mbit connection (or less
actually), alpha can exceed 65000, so alpha needs to be a u32.
Signed-off-by: Gavin McCullagh <gavin.mccullagh@nuim.ie> Signed-off-by: Doug Leith <doug.leith@nuim.ie> Signed-off-by: David S. Miller <davem@davemloft.net>
Doug Leith observed a discrepancy between the version of CUBIC described
in the papers and the version in 2.6.18. A math error related to scaling
causes Cubic to grow too slowly.
Patch is from "Sangtae Ha" <sha2@ncsu.edu>. I validated that
it does fix the problems.
See the following to show behavior over 500ms 100 Mbit link.
Sync atstk1002_defconfig with latest git, turn off non-existent
drivers and enable a few more userspace-visible options like
SysV IPC and inotify support.
[PATCH] AVR32: Use __raw MMIO access for internal peripherals
The read[bwl] and write[bwl] functions are meant for accessing PCI
devices. How this is achieved on AVR32 is unknown, as there are no
systems with a PCI bridge available yet.
On-chip peripheral access, however, should not depend on how we end
up implementing PCI access, so using __raw_read[bwl]/__raw_write[bwl]
is the right thing to do for on-chip peripherals. This patch converts
the drivers for the static memory controller, interrupt controller,
PIO controller and system manager to use __raw MMIO access.
Ben Nizette [Tue, 24 Oct 2006 08:12:43 +0000 (10:12 +0200)]
[PATCH] AVR32: add io{read,write}{8,16,32}{be,} support
A number of new drivers require io{read,write}{8,16,32}{be,} family of io
operations. These are provided for the AVR32 by this patch in the form of
a series of macros.
Access to the (memory mapped) io space through these macros is defined to
be little endian only as little endian devices (such as PCI) are the main
consumer of IO access. If high speed access is required,
io{read,write}{16,32}be macros are supplied to perform native big endian
access to this io space.
[PATCH] AVR32: Fix oversize immediates in atomic.h
When calling e.g. atomic_sub_return with a large constant, the
compiler may output an immediate that is too large for the sub
instruction in the middle of the loop.
Fix this by explicitly specifying the number of bits allowed in the
constraint. Also stop atomic_add_return() and friends from falling
back to their respective "sub" variants if the constant is too large
to fit in an immediate.
[PATCH] AVR32: Don't try to iounmap P2 segment addresses
While ioremap() will happily map a physical address through the
P2 (uncached) segment when appropriate, iounmap() doesn't know how
to handle those mappings.
This patch makes iounmap() do the right thing, i.e. nothing, for
such mappings.
Linus Torvalds [Thu, 26 Oct 2006 03:22:04 +0000 (20:22 -0700)]
Merge branch 'intelfb-patches' of master.kernel.org:/pub/scm/linux/kernel/git/airlied/intelfb-2.6
* 'intelfb-patches' of master.kernel.org:/pub/scm/linux/kernel/git/airlied/intelfb-2.6:
Remove unnecessary check in drivers/video/intelfb/intelfbhw.c
intel fb: switch to pci_get API
Linus Torvalds [Thu, 26 Oct 2006 03:21:43 +0000 (20:21 -0700)]
Merge branch 'drm-patches' of master.kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6
* 'drm-patches' of master.kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6:
drm: ioremap balanced with iounmap for drivers/char/drm
drm: fix error returns, sysfs error handling
fix return code in error case.
drm: mga: set dev_priv_size
drm: savage: dev->agp_buffer_map is not initialized for AGP DMA on savages
drm: radeon: only allow specific type-3 packetss through verifier
Linus Torvalds [Thu, 26 Oct 2006 03:21:16 +0000 (20:21 -0700)]
Merge branch 'for-linus' of git://one.firstfloor.org/home/andi/git/linux-2.6
* 'for-linus' of git://one.firstfloor.org/home/andi/git/linux-2.6:
[PATCH] x86-64: Only look at per_cpu data for online cpus.
[PATCH] x86-64: Simplify the vector allocator.
Linus Torvalds [Thu, 26 Oct 2006 03:20:03 +0000 (20:20 -0700)]
Merge branch 'merge' of master.kernel.org:/pub/scm/linux/kernel/git/paulus/powerpc
* 'merge' of master.kernel.org:/pub/scm/linux/kernel/git/paulus/powerpc:
[POWERPC] Make sure __cpu_preinit_ppc970 gets called on 970GX processors
[POWERPC] Fix CHRP platforms with only 8259
[POWERPC] IPIC: Fix spinlock recursion in set_irq_handler
[POWERPC] Fix the UCC rx/tx clock of QE
[POWERPC] cell: update defconfig
[POWERPC] spufs: fix another off-by-one bug in spufs_mbox_read
[POWERPC] spufs: fix signal2 file to report signal2
[POWERPC] Fix device_is_compatible() const warning
[POWERPC] Cell timebase bug workaround
[POWERPC] Support feature fixups in modules
[POWERPC] Support feature fixups in vdso's
[POWERPC] Support nested cpu feature sections
[POWERPC] Consolidate feature fixup code
[POWERPC] Fix hang in start_ldr if _end or _edata is unaligned
[POWERPC] Fix spelling errors in ucc_fast.c and ucc_slow.c
[POWERPC] Don't require execute perms on wrapper when building zImage.initrd
[POWERPC] Add 970GX cputable entry
[POWERPC] Fix build breakage with CONFIG_PPC32
[POWERPC] Fix compiler warning message on get_property call
[POWERPC] Simplify stolen time calculation
Hannes Reinecke [Mon, 23 Oct 2006 13:26:37 +0000 (15:26 +0200)]
[SCSI] aic79xx: Print out signalling
This is a cross-port of a similar patch for aic7xxx;
only it's a bit simpler here as we don't support HVD
and all controller actually implement this register.
I hope.
Signed-off-by: Hannes Reinecke <hare@suse.de> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Hannes Reinecke [Mon, 23 Oct 2006 13:25:36 +0000 (15:25 +0200)]
[SCSI] aic7xxx: Remove slave_destroy
This is a cross-port from aic79xx; we still hit the occasional
BUG_ON in slave_destroy. And again we don't really need the
slave_destroy callback nor the ahc_linux_target structure
at all.
Signed-off-by: Hannes Reinecke <hare@suse.de> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Hannes Reinecke [Mon, 23 Oct 2006 13:22:37 +0000 (15:22 +0200)]
[SCSI] aic79xx: Fixup external device reset
Whenever an external device is resetted we really have to take
care to keep the channel in sync. Just notifying SCSI-ML and retry
is not enough as we have to make sure the SCSI bus is not getting
confused, either.
So whenever we detect an external reset we rewrite the command to
TUR, disable packetized command and notify the internal engine
that an abort has happened. This way we trigger a proper bus
reset sequence and all devices will be renegotiated properly.
Kudos to Justin Gibbs and Luben Tuikov for this idea.
Signed-off-by: Hannes Reinecke <hare@suse.de> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Randy Dunlap [Tue, 24 Oct 2006 04:47:13 +0000 (21:47 -0700)]
[SCSI] lpfc: fix printk format warning
Fix printk format warning:
drivers/scsi/lpfc/lpfc_attr.c:597: warning: long long unsigned int format, uint64_t arg (arg 4)
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: James Smart <James.Smart@Emulex.Com> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Adrian Bunk [Fri, 20 Oct 2006 21:48:07 +0000 (14:48 -0700)]
[SCSI] aic79xx: make ahd_set_tags() static
Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Acked-by: Hannes Reinecke <hare@suse.de> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Adrian Bunk [Fri, 20 Oct 2006 21:47:57 +0000 (14:47 -0700)]
[SCSI] aic7xxx: cleanups
- make needlessly global code static
- #if 0 the following unused global functions:
- aic79xx_core.c: ahd_print_scb
- aic79xx_core.c: ahd_suspend
- aic79xx_core.c: ahd_resume
- aic79xx_core.c: ahd_dump_scbs
- aic79xx_osm.c: ahd_softc_comp
Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Acked-by: Hannes Reinecke <hare@suse.de> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Hannes Reinecke [Fri, 20 Oct 2006 07:58:47 +0000 (09:58 +0200)]
[SCSI] scsi_debug: support REPORT TARGET PORT GROUPS
This patch adds support for REPORT TARGET PORT GROUPS. This is used
eg for the multipathing priority callout to determine the path
priority.
With this patch multipath-tools can use the existing mpath_prio_alua
callout to exercise the path priority grouping.
Signed-off-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Douglas Gilbert <dougg@torque.net> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Mike Christie [Mon, 16 Oct 2006 22:09:42 +0000 (18:09 -0400)]
[SCSI] libiscsi: fix logout pdu processing
According to the iscsi RFC, we cannot send other requests if
we have sent a logout pdu. This patch enforces this requirement
by blocking the session and suspending the send thread. Userspace
decides if we restart the connection or if we just free everything.
Signed-off-by: Mike Christie <michaelc@cs.wisc.edu> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Mike Christie [Mon, 16 Oct 2006 22:09:40 +0000 (18:09 -0400)]
[SCSI] libiscsi: fix missed iscsi_task_put in xmit error path
from bhalevy@gmail.com:
It looks like change 652 to libiscsi.c added some dead code around line
670
if (rc) {
spin_unlock_bh(&conn->session->lock);
goto again;
}
since 5 lines above we goto again if (rc).
It looks like the previous if (rc) should go away if we want to put the
ctask before
breaking out of the while loop with "goto again" (see following patch).
Signed-off-by: Mike Christie <michaelc@cs.wisc.edu> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Mike Christie [Mon, 16 Oct 2006 22:09:39 +0000 (18:09 -0400)]
[SCSI] libiscsi: fix oops in connection create failure path
If connection creation fails we end up calling list_del
on a invalid struct. This then causes an oops. We are not
acutally using the lists (old MCS code we thought might
be useful elsewhere) so this patch just removes that
code.
Signed-off-by: Mike Christie <michaelc@cs.wisc.edu> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Mike Christie [Mon, 16 Oct 2006 22:09:38 +0000 (18:09 -0400)]
[SCSI] iscsi class: fix slab corruption during restart
The transport class recv mempools are causing slab corruption.
We could hack around netlink's lack of mempool support like dm,
but it is just too ulgy (dm's hack is ugly enough :) when you need
to support broadcast.
This patch removes the recv pools. We have not used them even when
we were allocting 20 MB per session and the system only had 64 MBs.
And we have no pools on the send side and have been ok there. When
Peter's work gets merged we can use that since the network guys
are in favor of that approach and are not going to add mempools
everywhere.
Signed-off-by: Mike Christie <michaelc@cs.wisc.edu> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Alan Cox [Mon, 16 Oct 2006 15:55:46 +0000 (16:55 +0100)]
[SCSI] Switch fdomain to the pci_get API
Doesn't make the hardware hot pluggable but does ensure the driver won't
crash when another device is hot-unplugged at the wrong moment. Soon I
propose to deprecate pci_find_device() and some of its friends.
Signed-off-by: Alan Cox <alan@redhat.com> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
It is known that 2 LSI Logic MegaRAID SATA RAID Controllers (150-4 and
150-6) don't support 64-bit DMA. Unfortunately currently this check is
wrong and driver sets 64-bit DMA mode for these devices.
Santiago Leon [Fri, 13 Oct 2006 15:22:50 +0000 (10:22 -0500)]
[SCSI] ibmvscsi: correctly reenable CRQ
The "ibmvscsi: treat busy and error conditions separately" patch
submitted by Dave Boutcher back in June incorrectly reenables the CRQ.
The broken logic causes the adapter to get disabled if the CRQ
connection happens to close temporarily. This patch "fixes that
obviously wrong logic check" (Dave's words).
Signed-off-by: Santiago Leon <santil@us.ibm.com> Signed-off-by: David Boutcher <sleddog@us.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Andrew Vasquez [Fri, 13 Oct 2006 16:33:39 +0000 (09:33 -0700)]
[SCSI] qla2xxx: Correct QUEUE_FULL handling.
- Drop queue-depths across all luns for a given fcport
during TASK_SET_FULL statuses.
- Ramp-up I/Os after throttling.
- Consolidate completion-status handling of CS_QUEUE_FULL with
CS_COMPLETE as ISP24xx firmware no longer reports
CS_QUEUE_FULL.
Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Early ISP2432 parts have a known hardware issue when coming
out of a D3 hot state. This issue can result in a hung PCIe
link. Recent firmwares contain a workaround whereby the
stop-firmware mailbox command prevents the ISP from entering
the D3 hot state.
In order to ensure that the workaround succeeded the driver
must verify that the stop-firmware mailbox command completes
successfully. In the event of a failure, the driver
attempts a shutdown-retry after resetting the ISP and
re-executing firmware.
Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Changes the obsolete Scsi_Cmnd to struct scsi_cmnd in the Fibre Channel
driver (fc4).
Signed-off-by: Henrik Kretzschmar <henne@nachtwindheim.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Changes the obsolete typedefd Scsi_Cmnd to struct scsi_cmnd in
the ninja scsi pcmcia driver.
Signed-off-by: Henrik Kretzschmar <henne@nachtwindheim.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Changes the obsolete Scsi_Cmnd to struct scsi_cmnd in psi240i-driver.
Signed-off-by: Henrik Kretzschmar <henne@nachtwindheim.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Eric Sesterhenn [Tue, 10 Oct 2006 21:41:43 +0000 (14:41 -0700)]
[SCSI] lpfc: check before dereference in lpfc_ct.c
If we fail to allocate mp->virt during the first while loop iteration,
mlist is still uninitialized, therefore we should check if before
dereferencing.
Signed-off-by: Eric Sesterhenn <snakebyte@gmx.de> Acked-by: James Smart <James.Smart@Emulex.Com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Henne [Mon, 9 Oct 2006 13:38:34 +0000 (15:38 +0200)]
[SCSI] fix typo in previous Scsi_Cmnd convertion in aic7xxx_old.c
Fixes a typo in the aic7xxx_old.c.
Signed-off-by: Olaf Hering <olaf@aepfle.de> Signed-off-by: Henrik Kretzschmar <henne@nachtwindheim.de> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Michael Reed [Fri, 6 Oct 2006 20:39:25 +0000 (15:39 -0500)]
[SCSI] mptfc: stall eh handlers if resetting while rport blocked
Thanks to James Smart for the inspiration.
Stall error handler if attempting recovery while an rport is blocked.
This avoids device offline scenarios due to errors in the error handler.
Also verify that VirtDevice is available before issuing scsi command.
VirtDevice is removed when fc transport removes a target.
See James Smart's patch of 08/17/2006 for greater detail.
AM53C974A's Start Transfer Counter register has 24 bits, thus
maximum transfer length is 16MiB. But the maximum I can test
is 8MiB, so use that until somebody tests 16MiB.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Jeff Garzik [Tue, 10 Oct 2006 21:23:37 +0000 (14:23 -0700)]
drm: fix error returns, sysfs error handling
- callers of drm_sysfs_create() and drm_sysfs_device_add() looked for
errors using IS_ERR(), but the functions themselves only ever returned
NULL on error. Fixed.
- unwind from, and propagate sysfs errors
Signed-off-by: Jeff Garzik <jeff@garzik.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Dave Airlie <airlied@linux.ie>
Al Viro [Tue, 24 Oct 2006 10:15:29 +0000 (11:15 +0100)]
[PATCH] uml: mconsole fixes
* when we have stop/sysrq/go, we get pt_regs of whatever executes
mc_work_proc(). Would be better to see what we had at the time of
interrupt that got us stop.
* stop/stop/stop..... will give stack overflow. Shouldn't allow stop
from mconsole_stop().
* stop/stop/go leaves us inside mconsole_stop() with
os_set_fd_block(req->originating_fd, 0);
reactivate_fd(req->originating_fd, MCONSOLE_IRQ);
just done by nested mconsole_stop(). Ditto.
* once we'd seen stop, there's a period when INTR commands are executed
out of order (as they should; we might have the things stuck badly
enough to never reach mconsole_stop(), but still not badly enough to
block mconsole_interrupt(); in that situation we _want_ things like
"cad" to be executed immediately). Once we enter monsole_stop(), all
INTR commands will be executed in order, mixed with PROC ones. We'd
better let user see that such change of behaviour has happened.
(Suggested by lennert).
* stack footprint of monsole_interrupt() is an atrocity; AFAICS we can
safely make struct mc_request req; static in function there.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Acked-by: Jeff Dike <jdike@addtoit.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
On CHRP platforms with only a 8259 controller, we should set the
default IRQ host to the 8259 driver's one for the IRQ probing
fallbacks to work in case the IRQ tree is incorrect (like on
Pegasos for example). Without this fix, we get a bunch of WARN_ON's
during boot.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
Scott Wood [Mon, 23 Oct 2006 16:35:22 +0000 (11:35 -0500)]
[POWERPC] IPIC: Fix spinlock recursion in set_irq_handler
This causes ipic_set_irq_type to set the handler directly rather
than call set_irq_handler, which causes spinlock recursion because
the lock is already held when ipic_set_irq_type is called.
I'm also not convinced that ipic_set_irq_type should be changing the
handler at all. There seem to be several controllers that don't and
several that do. Those that do would break what appears to be a common
usage of calling set_irq_chip_and_handler followed by set_irq_type, if a
non-standard handler were to be used. OTOH, irq_create_of_mapping()
doesn't set the handler, but only calls set_irq_type().
This patch gets things working in the spinlock-debugging-enabled case,
but I'm curious as to where the handler setting is ideally supposed to be
done. I don't see any documentation on set_irq_type() that clarifies
what the semantics are supposed to be.
Signed-off-by: Scott Wood <scottwood@freescale.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
Liu Dave-r63238 [Wed, 18 Oct 2006 08:36:56 +0000 (16:36 +0800)]
[POWERPC] Fix the UCC rx/tx clock of QE
MPC8323EMDS board ethernet interface with RMII uses the CLK16 divisor
for the rx and tx clock, but the ucc_set_qe_mux_rxtx() function doesn't
handle the CLK16 setting of the CMXUCR3 and CMXUCR4 registers. This
fixes it.
Signed-off-by: Dave Liu <daveliu@freescale.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
Arnd Bergmann [Tue, 24 Oct 2006 16:01:42 +0000 (18:01 +0200)]
[POWERPC] spufs: fix another off-by-one bug in spufs_mbox_read
Currently, spufs_mbox_read transfers more bytes than requested on a
read. If you ask for four bytes, you get eight. This fixes it to
transfer the largest multiple of four bytes that is less than or equal
to the number you asked for.
Note: one nasty property of this file in spufs is that you can only
read multiples of four bytes in the first place, since there is no way
to atomically put back a few bytes into the hardware register. Thus,
reading less than four bytes returns -EINVAL. Asking for more than
four returns the largest possible multiple of four.
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
Fix a const'ification related warning with device_is_compatible()
and friends related to get_property() not properly having const
on it's input device node argument.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
The Cell CPU timebase has an erratum. When reading the entire 64 bits
of the timebase with one mftb instruction, there is a handful of cycles
window during which one might read a value with the low order 32 bits
already reset to 0x00000000 but the high order bits not yet incremeted
by one. This fixes it by reading the timebase again until the low order
32 bits is no longer 0. That might introduce occasional latencies if
hitting mftb just at the wrong time, but no more than 70ns on a cell
blade, and that was considered acceptable.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by: Olof Johansson <olof@lixom.net> Signed-off-by: Paul Mackerras <paulus@samba.org>