James Bottomley [Wed, 6 Sep 2006 14:00:29 +0000 (09:00 -0500)]
[SCSI] fix up non-modular SCSI
The recent change to the way scsi_device_get()/put() work broke the
non modular build (we do a module_refcount on a NULL). Fix this by
checking for non-null before checking module_refcount().
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
James Bottomley [Tue, 5 Sep 2006 21:26:41 +0000 (16:26 -0500)]
[SCSI] Fix refcount breakage with 'echo "1" > scan' when target already present
Spotted by: Dan Aloni <da-xx@monatomic.org>
The problem is there's inconsistent locking semantic usage of
scsi_alloc_target(). Two callers assume the target comes back with
reference unincremented and the third assumes its incremented. Fix by
always making the reference incremented on return. Also fix path in
target alloc that could consistently increment the parent lock.
Finally document scsi_alloc_target() so its callers know what the
expectations are.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
James Smart [Fri, 18 Aug 2006 21:47:08 +0000 (17:47 -0400)]
[SCSI] lpfc 8.1.10 : Add support for dev_loss_tmo_callbk and fast_io_fail_tmo_callbk
Add support for new dev_loss_tmo callback
Goodness is that it removes code for a parallel nodev timer that
existed in the driver
Add support for the new fast_io_fail callback
Signed-off-by: James Smart <James.Smart@emulex.com> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
James Smart [Fri, 18 Aug 2006 21:33:29 +0000 (17:33 -0400)]
[SCSI] FC transport: Add dev_loss_tmo callbacks, and new fast_io_fail_tmo w/ callback
This patch adds the following functionality to the FC transport:
- dev_loss_tmo LLDD callback :
Called to essentially confirm the deletion of an rport. Thus, it is
called whenever the dev_loss_tmo fires, or when the rport is deleted
due to other circumstances (module unload, etc). It is expected that
the callback will initiate the termination of any outstanding i/o on
the rport.
- fast_io_fail_tmo and LLD callback:
There are some cases where it may take a long while to truly determine
device loss, but the system is in a multipathing configuration that if
the i/o was failed quickly (faster than dev_loss_tmo), it could be
redirected to a different path and completed sooner.
Many thanks to Mike Reed who cleaned up the initial RFC in support
of this post.
The original RFC is at:
http://marc.theaimsgroup.com/?l=linux-scsi&m=115505981027246&w=2
Signed-off-by: James Smart <James.Smart@emulex.com> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
James Smart [Fri, 18 Aug 2006 21:30:09 +0000 (17:30 -0400)]
[SCSI] SCSI and FC Transport: add netlink support for posting of transport events
This patch formally adds support for the posting of FC events via netlink.
It is a followup to the original RFC at:
http://marc.theaimsgroup.com/?l=linux-scsi&m=114530667923464&w=2
and the initial posting at:
http://marc.theaimsgroup.com/?l=linux-scsi&m=115507374832500&w=2
The patch has been updated to optimize the send path, per the discussions
in the initial posting.
Per discussions at the Storage Summit and at OLS, we are to use netlink for
async events from transports. Also per discussions, to avoid a netlink
protocol per transport, I've create a single NETLINK_SCSITRANSPORT protocol,
which can then be used by all transports.
This patch:
- Creates new files scsi_netlink.c and scsi_netlink.h, which contains the
single and shared definitions for the SCSI Transport. It is tied into the
base SCSI subsystem intialization.
Contains a single interface routine, scsi_send_transport_event(), for a
transport to send an event (via multicast to a protocol specific group).
- Creates a new scsi_netlink_fc.h file, which contains the FC netlink event
messages
- Adds 3 new routines to the fc transport:
fc_get_event_number() - to get a FC event #
fc_host_post_event() - to send a simple FC event (32 bits of data)
fc_host_post_vendor_event() - to send a Vendor unique event, with
arbitrary amounts of data.
Note: the separation of event number allows for a LLD to send a standard
event, followed by vendor-specific data for the event.
Note: This patch assumes 2 prior fc transport patches have been installed:
http://marc.theaimsgroup.com/?l=linux-scsi&m=115555807316329&w=2
http://marc.theaimsgroup.com/?l=linux-scsi&m=115581614930261&w=2
Sorry - next time I'll do something like making these individual
patches of the same posting when I know they'll be posted closely
together.
Signed-off-by: James Smart <James.Smart@emulex.com>
Tidy up configuration not to make SCSI always select NET
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Jeff Garzik [Fri, 1 Sep 2006 07:12:19 +0000 (03:12 -0400)]
[SCSI] Add Promise SuperTrak driver
Add Promise SuperTrak 'stex' driver, supporting SuperTrak
EX8350/8300/16350/16300 controllers. The controller's firmware accepts
SCSI commands, handing them to the underlying RAID or JBOD disks.
The driver consisted of the following cleanups and fixes, beyond its
initial submission:
Ed Lin:
stex: cleanup and minor fixes
stex: add new device ids
stex: update internal copy code path
stex: add hard reset function
stex: adjust command timeout in slave_config routine
stex: use more efficient method for unload/shutdown flush
Jeff Garzik:
[SCSI] Add Promise SuperTrak 'shasta' driver.
Rename drivers/scsi/shasta.c to stex.c ("SuperTrak EX").
[SCSI] stex: update with community comments from 'Promise SuperTrak' thread
[SCSI] stex: Fix warning, trim trailing whitespace.
[SCSI] stex: remove last remnants of "shasta" project code name
[SCSI] stex: removed 6-byte command emulation
[SCSI] stex: minor cleanups
[SCSI] stex: minor fixes: irq flag, error return value
[SCSI] stex: use dma_alloc_coherent()
Signed-off-by: Jeff Garzik <jeff@garzik.org> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Hannes Reinecke [Fri, 1 Sep 2006 13:50:23 +0000 (15:50 +0200)]
[SCSI] Wrong size information for devices with disabled read access
When accessing a device with disabled read access the capacity is set
randomly to 1GB. This makes it impossible to userspace tools to detect
invalid device capacities.
Signed-off-by: Mike Anderson <andmike@us.ibm.com> Acked-by: Chris Mason <mason@suse.com> Signed-off-by: Hannes Reinecke <hare@suse.de> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Mike Christie [Thu, 31 Aug 2006 22:09:33 +0000 (18:09 -0400)]
[SCSI] libiscsi: check that command ptr is set before accessing it
If the scsi eh sends a TUR and the session is down we could
return SCSI_ML_HOST_BUSY. scsi eh will ignore this and send
ask us to abort the command and we blindly accesst the
command ptr.
Signed-off-by: Mike Christie <michaelc@cs.wisc.edu> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Mike Christie [Thu, 31 Aug 2006 22:09:32 +0000 (18:09 -0400)]
[SCSI] iscsi_tcp: fix partial digest recv
When a digest is spread across two network buffers, we currently
ignore this and try to check the digest with the partial buffer.
Or course this fails. This patch has use iscsi_tcp_copy to
copy the whole digest before testing it.
Signed-off-by: Mike Christie <michaelc@cs.wisc.edu> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Mike Christie [Thu, 31 Aug 2006 22:09:29 +0000 (18:09 -0400)]
[SCSI] iscsi_tcp: fix header resend
This patch built over the last ones fixes a bug in the partial header
resend code, where we add on another 4 bytes to the send length on the resend.
We want just the header plus digest.
Signed-off-by: Mike Christie <michaelc@cs.wisc.edu> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Mike Christie [Thu, 31 Aug 2006 22:09:28 +0000 (18:09 -0400)]
[SCSI] scsi_tcp: rm data rx and tx tfms
We currently allocated seperate tfms for data and header digests. There
is no reason for this since we can never calculate a rx header and
digest at the same time. Same for sends. So this patch removes the data
tfms and has the send and recv sides use the rx_tfm or tx_tfm.
I also made the connection creation code preallocate the tfms because I
thought I hit a bug where I changed the digests settings during a
relogin but could not allocate the tfm and then we just failed.
Signed-off-by: Mike Christie <michaelc@cs.wisc.edu> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Mike Christie [Thu, 31 Aug 2006 22:09:27 +0000 (18:09 -0400)]
[SCSI] iscsi_tcp: fix padding, data digests, and IO at weird offsets
iscsi_tcp calculates padding by using the expected transfer length. This
has the problem where if we have immediate data = no and initial R2T =
yes, and the transfer length ended up needing padding then we send:
1. header
2. padding which should have gone after data
3. data
Besides this bug, we also assume the target will always ask for nice
transfer lengths and the first burst length will always be a nice value.
As far as I can tell form the RFC this is not a requirement. It would be
silly to do this, but if someone did it we will end doing bad things.
Finally the last bug in that bit of code is in our handling of the
recalculation of data digests when we do not send a whole iscsi_buf in
one try. The bug here is that we call crypto_digest_final on a
iscsi_sendpage error, then when we send the rest of the iscsi_buf, we
doiscsi_data_digest_init and this causes the previous data digest to be
lost.
And to make matters worse, some of these bugs are replicated over and
over and over again for immediate data, solicited data and unsolicited
data. So the attached patch made over the iscsi git tree (see
kernel.org/git for details) which I updated today to include the patches
I said I merged, consolidates the sending of data, padding and digests
and calculation of data digests and fixes the above bugs.
Signed-off-by: Mike Christie <michaelc@cs.wisc.edu> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Mike Christie [Thu, 31 Aug 2006 22:09:26 +0000 (18:09 -0400)]
[SCSI] attempt to complete r2t with data len greater than max burst
A couple targets like string bean and MDS, send r2ts with
a data len greater than the max burst we agreed to. We
were being strict in our enforcing of the iscsi rfc in that
code path, but there is no driver limitation that prevents
us from fullfilling the request. To allow those targets
to work we will ignore the max_burst length and send as
much data as the target asks for assuming it has consciously
decided to override its max burst length.
Signed-off-by: Mike Christie <michaelc@cs.wisc.edu> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Mike Christie [Thu, 31 Aug 2006 22:09:25 +0000 (18:09 -0400)]
[SCSI] add refcouting around ctask usage in main IO patch
It is possible that a ctask could be completing and getting
cleaned up at the same time, we are finishing up the last
data transfer. This could then result in the data transfer
code using stale or invalid values. This patch adds a refcount
to the ctask. When the count goes to zero then we know the
transmit thread and recv thread or softirq are not touching
it and we can safely release it.
The eh should not need to grab a reference because it only cleans
up a task if it has both the xmit mutex and recv lock (or recv
side suspended).
Signed-off-by: Mike Christie <michaelc@cs.wisc.edu> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Mike Christie [Thu, 31 Aug 2006 22:09:24 +0000 (18:09 -0400)]
[SCSI] libiscsi, iscsi_tcp, iscsi_iser: check that burst lengths are valid.
iSCSI RFC states that the first burst length must be smaller than the
max burst length. We currently assume targets will be good, but that may
not be the case, so this patch adds a check.
This patch also moves the unsol data out offset to the lib so the LLDs
do not have to track it.
Signed-off-by: Mike Christie <michaelc@cs.wisc.edu> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Alan Stern [Mon, 21 Aug 2006 19:53:25 +0000 (15:53 -0400)]
[SCSI] SCSI: sanitize INQUIRY strings
Sanitize the Vendor, Product, and Revision strings contained in an
INQUIRY result by setting all non-graphic or non-ASCII characters to ' '.
Since the standard disallows such characters, this will affect
only non-compliant devices.
To help maintain backward compatibility, NUL characters are treated
specially. They are taken as string terminators; they and all the
following characters are set to ' '. If some valid characters get
erased as a result... well, we weren't seeing them before so we haven't
lost anything.
The primary purpose of this change is to allow blacklist entries to
match devices with illegal Vendor or Product strings.
In addition, the patch updates a couple of function prototypes, giving
inq_result its correct type (unsigned char *).
Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
The fix isn't actually in sd: it's in scsi_device_get(). I modified it
to allow devices to be returned in SDEV_CANCEL, but not SDEV_DEL. This
means that the device_remove_driver, which occurs in device_del() in
scsi_remove_device() after the device has gone into SDEV_CANCEL is now
effective at flushing the cache.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
James Bottomley [Wed, 30 Aug 2006 13:45:51 +0000 (09:45 -0400)]
[SCSI] add shared tag map helpers
This patch adds support for sharing tag maps at the host level
(i.e. either every queue [LUN] has its own tag map or there's a single
one for the entire host). This formulation is primarily intended to
help single issue queue hardware, like the aic7xxx
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
James Bottomley [Wed, 30 Aug 2006 19:48:45 +0000 (15:48 -0400)]
[SCSI] block: add support for shared tag maps
The current block queue implementation already contains most of the
machinery for shared tag maps. The only remaining pieces are a way to
allocate and destroy a tag map independently of the queues (so that
the maps can be managed on the life cycle of the overseeing entity)
Acked-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Darrick J. Wong [Wed, 30 Aug 2006 21:18:33 +0000 (14:18 -0700)]
[SCSI] aic94xx: Increase can_queue for better performance
This patch sets can_queue in the aic94xx driver's scsi_host to better
performing values than what's there currently. It seems that
asd_ha->seq.can_queue reflects the number of requests that can be
queued per controller; so long as there's one scsi_host per
controller, it seems logical that the scsi_host ought to have the same
can_queue value. To the best of my (still limited) knowledge, this
method provides the correct value.
The effect of leaving this value set to 1 is terrible performance in
the case of either (a) certain Maxtor SAS drives flying solo or (b)
flooding several disks with I/O simultaneously (md-raid). There may be
more scenarios where we see similar problems that I haven't uncovered.
Signed-off-by: Darrick J. Wong <djwong@us.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Jon Masters [Mon, 28 Aug 2006 22:08:21 +0000 (17:08 -0500)]
[SCSI] MODULE_FIRMWARE for binary firmware(s)
Right now, various kernel modules are being migrated over to use
request_firmware in order to pull in binary firmware blobs from userland
when the module is loaded. This makes sense.
However, there is right now little mechanism in place to automatically
determine which binary firmware blobs must be included with a kernel in
order to satisfy the prerequisites of these drivers. This affects
vendors, but also regular users to a certain extent too.
The attached patch introduces MODULE_FIRMWARE as a mechanism for
advertising that a particular firmware file is to be loaded - it will
then show up via modinfo and could be used e.g. when packaging a kernel.
Signed-off-by: Jon Masters <jcm@redhat.com>
Comments added in line with all the other MODULE_ tag
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
James Bottomley [Tue, 29 Aug 2006 14:22:51 +0000 (09:22 -0500)]
[SCSI] aic94xx: new driver
This is the end point of the separate aic94xx driver based on the
original driver and transport class from Luben Tuikov
<ltuikov@yahoo.com>
The log of the separate development is:
Alexis Bruemmer:
o aic94xx: fix hotplug/unplug for expanderless systems
o aic94xx: disable split completion timer/setting by default
o aic94xx: wide port off expander support
o aic94xx: remove various inline functions
o aic94xx: use bitops
o aic94xx: remove queue comment
o aic94xx: remove sas_common.c
o aic94xx: sas remove depot's
o aic94xx: use available list_for_each_entry_safe_reverse()
o aic94xx: sas header file merge
James Bottomley:
o aic94xx: fix TF_TMF_NO_CTX processing
o aic94xx: convert to request_firmware interface
o aic94xx: fix hotplug/unplug
o aic94xx: add link error counts to the expander phys
o aic94xx: add transport class phy reset capability
o aic94xx: remove local_attached flag
o Remove README
o Fixup Makefile variable for libsas rename
o Rename sas->libsas
o aic94xx: correct return code for sas_discover_event
o aic94xx: use parent backlink port
o aic94xx: remove channel abstraction
o aic94xx: fix routing algorithms
o aic94xx: add backlink port
o aic94xx: fix cascaded expander properties
o aic94xx: fix sleep under lock
o aic94xx: fix panic on module removal in complex topology
o aic94xx: make use of the new sas_port
o rename sas_port to asd_sas_port
o Fix for eh_strategy_handler move
o aic94xx: move entirely over to correct transport class formulation
o remove last vestages of sas_rphy_alloc()
o update for eh_timed_out move
o Preliminary expander support for aic94xx
o sas: remove event thread
o minor warning cleanups
o remove last vestiges of id mapping arrays
o Further updates
o Convert aic94xx over entirely to the transport class end device and
o update aic94xx/sas to use the new sas transport class end device
o [PATCH] aic94xx: attaching to the sas transport class
o Add missing completion removal from prior patch
o [PATCH] aic94xx: attaching to the sas transport class
o Build fixes from akpm
Jeff Garzik:
o [scsi aic94xx] Remove ->owner from PCI info table
Luben Tuikov:
o initial aic94xx driver
Mike Anderson:
o aic94xx: fix panic on module insertion
o aic94xx: stub out SATA_DEV case
o aic94xx: compile warning cleanups
o aic94xx: sas_alloc_task
o aic94xx: ref count update
o aic94xx nexus loss time value
o [PATCH] aic94xx: driver assertion in non-x86 BIOS env
Randy Dunlap:
o libsas: externs not needed
Robert Tarte:
o aic94xx: sequence patch - fixes SATA support
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
James Bottomley [Fri, 25 Aug 2006 18:48:18 +0000 (13:48 -0500)]
[SCSI] scsi_transport_sas: remove local_attached flag
This flag denotes local attachment of the phy. There are two problems
with it:
1) It's actually redundant ... you can get the same information simply
by seeing whether a host is the phys parent
2) we condition a lot of phy parameters on it on the false assumption
that we can only control local phys. I'm wiring up phy resets in the
aic94xx now, and it will be able to reset non-local phys as well.
I fixed 2) by moving the local check into the reset and stats function
of the mptsas, since that seems to be the only HBA that can't
(currently) control non-local phys.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Alan Cox [Sun, 27 Aug 2006 08:24:02 +0000 (01:24 -0700)]
[PATCH] Fix tty layer DoS and comment relevant code
Unlike the other tty comment patch this one has code changes. Specifically
it limits the queue size for a tty to 64K characters (128Kbytes) worst case
even if the tty is ignoring tty->throttle. This is because certain drivers
don't honour the throttle value correctly, although it is a useful
safeguard anyway.
Signed-off-by: Alan Cox <alan@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Randy Dunlap [Sun, 27 Aug 2006 08:24:00 +0000 (01:24 -0700)]
[PATCH] cdrom/gdsc: fix printk format warning
Fix printk format warning:
drivers/cdrom/gscd.c:269: warning: format â\80\98%luâ\80\99 expects type â\80\98long unsigned intâ\80\99, but argument 2 has type â\80\98unsigned intâ\80\99
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net> Cc: Jens Axboe <axboe@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Andrew Morton [Sun, 27 Aug 2006 08:23:58 +0000 (01:23 -0700)]
[PATCH] /proc/meminfo: don't put spaces in names
None of the other /proc/meminfo lines have a space in the identifier. This
post-2.6.17 addition has the potential to break existing parsers, so use an
underscore instead (like Committed_AS).
Cc: Christoph Lameter <clameter@engr.sgi.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Dave Jones [Sun, 27 Aug 2006 08:23:57 +0000 (01:23 -0700)]
[PATCH] fix up lockdep trace in fs/exec.c
This fixes the locking error noticed by lockdep:
=============================================
[ INFO: possible recursive locking detected ]
---------------------------------------------
init/1 is trying to acquire lock:
(&sighand->siglock){....}, at: [<c047a78a>] flush_old_exec+0x3ae/0x859
but task is already holding lock:
(&sighand->siglock){....}, at: [<c047a77a>] flush_old_exec+0x39e/0x859
other info that might help us debug this:
2 locks held by init/1:
#0: (tasklist_lock){..--}, at: [<c047a76a>] flush_old_exec+0x38e/0x859
#1: (&sighand->siglock){....}, at: [<c047a77a>] flush_old_exec+0x39e/0x859
Signed-off-by: Arjan van de Ven <arjan@infradead.org> Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Ingo Molnar [Sun, 27 Aug 2006 08:23:56 +0000 (01:23 -0700)]
[PATCH] lockdep: annotate idescsi_pc_intr()
idescsi_pc_intr() uses local_irq_enable() in IRQ context: annotate it.
(this has no effect on kernels with lockdep disabled. On kernels with lockdep
enabled this means that we wont actually disable interrupts, and the warning
message will go away as well.)
In file included from include/asm/mmzone.h:18,
from include/linux/mmzone.h:439,
<snip>
include/asm/srat.h:31:2: error: #error CONFIG_ACPI_SRAT not defined, and srat.h header has been included
make[1]: *** [arch/i386/kernel/asm-offsets.s] Error 1
This can happen with CONFIG_NUMA && !CONFIG_ACPI && !CONFIG_X86_NUMAQ
Nick Piggin [Sun, 27 Aug 2006 08:23:54 +0000 (01:23 -0700)]
[PATCH] cpuset: oom panic fix
cpuset_excl_nodes_overlap always returns 0 if current is exiting. This caused
customer's systems to panic in the OOM killer when processes were having
trouble getting memory for the final put_user in mm_release. Even though
there were lots of processes to kill.
Change to returning 1 in this case. This achieves parity with !CONFIG_CPUSETS
case, and was observed to fix the problem.
Signed-off-by: Nick Piggin <npiggin@suse.de> Acked-by: Paul Jackson <pj@sgi.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Badari Pulavarty [Sun, 27 Aug 2006 08:23:52 +0000 (01:23 -0700)]
[PATCH] Manage jbd allocations from its own slabs
JBD currently allocates commit and frozen buffers from slabs. With
CONFIG_SLAB_DEBUG, its possible for an allocation to cross the page
boundary causing IO problems.
Paul Jackson [Sun, 27 Aug 2006 08:23:51 +0000 (01:23 -0700)]
[PATCH] cpuset: top_cpuset tracks hotplug changes to cpu_online_map
Change the list of cpus allowed to tasks in the top (root) cpuset to
dynamically track what cpus are online, using a CPU hotplug notifier. Make
this top cpus file read-only.
On systems that have cpusets configured in their kernel, but that aren't
actively using cpusets (for some distros, this covers the majority of
systems) all tasks end up in the top cpuset.
If that system does support CPU hotplug, then these tasks cannot make use
of CPUs that are added after system boot, because the CPUs are not allowed
in the top cpuset. This is a surprising regression over earlier kernels
that didn't have cpusets enabled.
In order to keep the behaviour of cpusets consistent between systems
actively making use of them and systems not using them, this patch changes
the behaviour of the 'cpus' file in the top (root) cpuset, making it read
only, and making it automatically track the value of cpu_online_map. Thus
tasks in the top cpuset will have automatic use of hot plugged CPUs allowed
by their cpuset.
Thanks to Anton Blanchard and Nathan Lynch for reporting this problem,
driving the fix, and earlier versions of this patch.
Signed-off-by: Paul Jackson <pj@sgi.com> Cc: Nathan Lynch <ntl@pobox.com> Cc: Anton Blanchard <anton@samba.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
NeilBrown [Sun, 27 Aug 2006 08:23:50 +0000 (01:23 -0700)]
[PATCH] md: fix recent breakage of md/raid1 array checking
A recent patch broke the ability to do a user-request check of a raid1.
This patch fixes the breakage and also moves a comment that was dislocated
by the same patch.
Signed-off-by: Neil Brown <neilb@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
NeilBrown [Sun, 27 Aug 2006 08:23:49 +0000 (01:23 -0700)]
[PATCH] md: avoid backward event updates in md superblock when degraded.
If we
- shut down a clean array,
- restart with one (or more) drive(s) missing
- make some changes
- pause, so that they array gets marked 'clean',
the event count on the superblock of included drives
will be the same as that of the removed drives.
So adding the removed drive back in will cause it
to be included with no resync.
To avoid this, we only update the eventcount backwards when the array
is not degraded. In this case there can (should) be no non-connected
drives that we can get confused with, and this is the particular case
where updating-backwards is valuable.
Signed-off-by: Neil Brown <neilb@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Tom Zanussi [Sun, 27 Aug 2006 08:23:47 +0000 (01:23 -0700)]
[PATCH] Documentation update for relay interface
Here's updated documentation for the relay interface, rewritten to match
the relayfs->relay changes. It also moves relayfs.txt to relay.txt in the
process.
It includes the changes to relayfs.txt previously posted by Randy Dunlap,
thanks for those.
The relay-apps examples have also been updated to match, and can be found
on the sourceforge relayfs website.
Signed-off-by: Tom Zanussi <zanussi@us.ibm.com> Cc: "Randy.Dunlap" <rdunlap@xenotime.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
1) When we allocated last fragment in ufs_truncate, we read page, check
if block mapped to address, and if not trying to allocate it. This is
wrong behaviour, fragment may be NOT allocated, but mapped, this
happened because of "block map" function not checked allocated fragment
or not, it just take address of the first fragment in the block, add
offset of fragment and return result, this is correct behaviour in
almost all situation except call from ufs_truncate.
2) Almost all implementation of UFS, which I can investigate have such
"defect": if you have full disk, and try truncate file, for example 3GB
to 2MB, and have hole in this region, truncate return -ENOSPC. I tried
evade from this problem, but "block allocation" algorithm is tied to
right value of i_lastfrag, and fix of this corner case may slow down of
ordinaries scenarios, so this patch makes behavior of "truncate"
operations similar to what other UFS implementations do.
On UFS, this scenario:
open(O_TRUNC)
lseek(1024 * 1024 * 80)
write("A")
lseek(1024 * 2)
write("A")
may cause access to invalid address.
This happened because of "goal" is calculated in wrong way in block
allocation path, as I see this problem exists also in 2.4.
We use construction like this i_data[lastfrag], i_data array of pointers to
direct blocks, indirect and so on, it has ceratain size ~20 elements, and
lastfrag may have value for example 40000.
Also this patch fixes related to handling such scenario issues, wrong
zeroing metadata, in case of block(not fragment) allocation, and wrong goal
calculation, when we allocate block
Mingming Cao [Sun, 27 Aug 2006 08:23:44 +0000 (01:23 -0700)]
[PATCH] ext3 filesystem bogus ENOSPC with reservation fix
To handle the earlier bogus ENOSPC error caused by filesystem full of block
reservation, current code falls back to non block reservation, starts to
allocate block(s) from the goal allocation block group as if there is no
block reservation.
Current code needs to re-load the corresponding block group descriptor for
the initial goal block group in this case. The patch fixes this.
Signed-off-by: Mingming Cao <cmm@us.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Andries Brouwer [Sun, 27 Aug 2006 08:23:42 +0000 (01:23 -0700)]
[PATCH] Fix for minix crash
Mounting a (corrupt) minix filesystem with zero s_zmap_blocks
gives a spectacular crash on my 2.6.17.8 system, no doubt
because minix/inode.c does an unconditional
minix_set_bit(0,sbi->s_zmap[0]->b_data);
[akpm@osdl.org: make labels conistent while we're there]
Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] MTD NAND: Fix ams-delta after core conversion
The recent hwctrl core conversion for MTD NAND devices broke the Amstrad
Delta driver. This fixes it up and uses the existing control line defines
rather than unclear magic numbers.
Signed-off-by: Jonathan McDowell <noodles@earth.li> Acked-by: David Woodhouse <dwmw2@infradead.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Oleg Nesterov [Sun, 27 Aug 2006 08:23:40 +0000 (01:23 -0700)]
[PATCH] futex_find_get_task(): remove an obscure EXIT_ZOMBIE check
futex_find_get_task:
if (p->state == EXIT_ZOMBIE || p->exit_state == EXIT_ZOMBIE)
return NULL;
I can't understand this. First, p->state can't be EXIT_ZOMBIE. The
->exit_state check looks strange too. Sub-threads or tasks whose ->parent
ignores SIGCHLD go directly to EXIT_DEAD state (I am ignoring a ptrace
case). Why EXIT_DEAD tasks should be ok? Yes, EXIT_ZOMBIE is more
important (a task may stay zombie for a long time), but this doesn't mean
we should explicitely ignore other EXIT_XXX states.
Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru> Acked-by: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
When reading /dev/vcsa while a font with more than 256 characters is
loaded, one of the attribute bits records the 9th bit of the character.
But depending on the console driver (vgacon or fbcon for instance), that's
bit 3 or bit 0. And there is no way for userland to know that, thus no way
for userland to safely grab the screen content. So here is a (tested)
patch:
Add a VT_GETHIFONTMASK ioctl for knowing which bit is the 9th bit for VC
text (vc_hi_font_mask field of the vc_data structure).
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Paul A. Clarke [Sun, 27 Aug 2006 08:23:37 +0000 (01:23 -0700)]
[PATCH] matroxfb: fix jittery display on non-ppc systems
I wish I was happier about this patch. It'll serve as a placeholder for
the moment. I'm still trying to get a G550 working in order to even
reproduce the problem this patch introduces. I find that the G450 has
jitter even without this patch, so it won't show me what the patch changed.
At this point, I'll continue trying to get the G550 to work, and in
parallel work with the G450 to work out the kinks.
The patch is below.
Set XDVICLKCTRL only on PPC, as doing this apparently introduces jitter on
the G550, at least on x86 architectures.
Signed-off-by: Paul A. Clarke <pc@us.ibm.com> Signed-off-by: Petr Vandrovec <petr@vandrovec.name> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Dirk Eibach [Sun, 27 Aug 2006 08:23:36 +0000 (01:23 -0700)]
[PATCH] char/moxa.c: fix endianess and multiple-card issues
While testing Moxa C218T/PCI on PowerPC 405EP I found that loading firmware
using the linux kernel driver fails because calculation of the checksum is
not endianess independent in the original code.
After I fixed this I found that uploading firmware in a system with
multiple cards causes a kernel oops. I had a look in the recent moxa
sources and found that they do some kind of locking there. Applying this
lock fixed the problem.
Alan sayeth:
Checksum changes are clearly correct. Other changes is an improvement but
not I think enough to handle malicious firmware attacks. That said such an
attacker has CAP_SYS_RAWIO anyway so that part is irrelevant except for
neatness.
[akpm@osdl.org: cleanups] Signed-off-by: Dirk Eibach <eibach@gdsys.de> Acked-by: Alan Cox <alan@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Dave Jones [Sun, 27 Aug 2006 08:23:35 +0000 (01:23 -0700)]
[PATCH] cpufreq: acpi-cpufreq: Ignore failure from acpi_cpufreq_early_init_acpi
Ignore the return value of early_init_acpi(), as it can give false error
messages. If there is something really wrong, then register_driver will
fail cleanly with EINVAL later.
[ background: modprobe acpi-cpufreq on systems not capable of speed-scaling
started failing with 'invalid argument', where previously it would only
ever -ENODEV
I'm not 100% happy with the solution. It'd be better to handle
failure properly, but this is a low-impact change for 2.6.18
We can always revisit doing this better in .19 --davej.]
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Dave Jones <davej@redhat.com> Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Oleg Nesterov [Sun, 27 Aug 2006 08:23:34 +0000 (01:23 -0700)]
[PATCH] revert "Drop tasklist lock in do_sched_setscheduler"
sched_setscheduler() looks at ->signal->rlim[]. It is unsafe do
dereference ->signal unless tasklist_lock or ->siglock is held (or p ==
current). We pin the task structure, but this can't prevent from
release_task()->__exit_signal() which sets ->signal = NULL.
Restore tasklist_lock across the setscheduler call.
Richard Purdie [Sun, 27 Aug 2006 08:23:33 +0000 (01:23 -0700)]
[PATCH] mtd corruption fix
Read the return value before we release the nand device otherwise the
value can become corrupted by another user of chip->ops, ultimately
resulting in filesystem corruption.
Signed-off-by: Richard Purdie <rpurdie@rpsys.net> Cc: David Woodhouse <dwmw2@infradead.org> Acked-by: Josh Boyer <jwboyer@gmail.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Peter Zijlstra [Sun, 27 Aug 2006 08:23:31 +0000 (01:23 -0700)]
[PATCH] lockdep: fix blkdev_open() warning
On Wed, 2006-08-09 at 07:57 +0200, Rolf Eike Beer wrote:
> =============================================
> [ INFO: possible recursive locking detected ]
> ---------------------------------------------
> parted/7929 is trying to acquire lock:
> (&bdev->bd_mutex){--..}, at: [<c105eb8d>] __blkdev_put+0x1e/0x13c
>
> but task is already holding lock:
> (&bdev->bd_mutex){--..}, at: [<c105eec6>] do_open+0x72/0x3a8
>
> other info that might help us debug this:
> 1 lock held by parted/7929:
> #0: (&bdev->bd_mutex){--..}, at: [<c105eec6>] do_open+0x72/0x3a8
> stack backtrace:
> [<c1003aad>] show_trace_log_lvl+0x58/0x15b
> [<c100495f>] show_trace+0xd/0x10
> [<c1004979>] dump_stack+0x17/0x1a
> [<c102dee5>] __lock_acquire+0x753/0x99c
> [<c102e3b0>] lock_acquire+0x4a/0x6a
> [<c1204501>] mutex_lock_nested+0xc8/0x20c
> [<c105eb8d>] __blkdev_put+0x1e/0x13c
> [<c105ecc4>] blkdev_put+0xa/0xc
> [<c105f18a>] do_open+0x336/0x3a8
> [<c105f21b>] blkdev_open+0x1f/0x4c
> [<c1057b40>] __dentry_open+0xc7/0x1aa
> [<c1057c91>] nameidata_to_filp+0x1c/0x2e
> [<c1057cd1>] do_filp_open+0x2e/0x35
> [<c1057dd7>] do_sys_open+0x38/0x68
> [<c1057e33>] sys_open+0x16/0x18
> [<c1002845>] sysenter_past_esp+0x56/0x8d
OK, I'm having a look here; its all new to me so bear with me.
blkdev_open() calls
do_open(bdev, ...,BD_MUTEX_NORMAL) and takes
mutex_lock_nested(&bdev->bd_mutex, BD_MUTEX_NORMAL)
then something fails, and we're thrown to:
out_first: where
if (bdev != bdev->bd_contains)
blkdev_put(bdev->bd_contains) which is
__blkdev_put(bdev->bd_contains, BD_MUTEX_NORMAL) which does
mutex_lock_nested(&bdev->bd_contains->bd_mutex, BD_MUTEX_NORMAL) <--- lockdep trigger
When going to out_first, dbev->bd_contains is either bdev or whole, and
since we take the branch it must be whole. So it seems to me the
following patch would be the right one:
[akpm@osdl.org: compile fix] Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Arjan van de Ven <arjan@linux.intel.com> Acked-by: NeilBrown <neilb@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Danny Tholen [Sun, 27 Aug 2006 08:23:29 +0000 (01:23 -0700)]
[PATCH] 1394: fix for recently added firewire patch that breaks things on ppc
Recently a patch was added for preliminary suspend/resume handling on
!PPC_PMAC. However, this broke both suspend and firewire on powerpc
because it saves the pci state after the device has already been disabled.
This moves the save state to before the pmac specific code.
Signed-off-by: Danny Tholen <obiwan@mailmij.org> Cc: Stefan Richter <stefanr@s5r6.in-berlin.de> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Ben Collins <bcollins@ubuntu.com> Cc: Jody McIntyre <scjody@modernduck.com> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Daniel Kobras [Sun, 27 Aug 2006 08:23:24 +0000 (01:23 -0700)]
[PATCH] dm: Fix deadlock under high i/o load in raid1 setup.
On an nForce4-equipped machine with two SATA disk in raid1 setup using dmraid,
we experienced frequent deadlock of the system under high i/o load. 'cat
/dev/zero > ~/zero' was the most reliable way to reproduce them: Randomly
after a few GB, 'cp' would be left in 'D' state along with kjournald and
kmirrord. The functions cp and kjournald were blocked in did vary, but
kmirrord's wchan always pointed to 'mempool_alloc()'. We've seen this pattern
on 2.6.15 and 2.6.17 kernels. http://lkml.org/lkml/2005/4/20/142 indicates
that this problem has been around even before.
So much for the facts, here's my interpretation: mempool_alloc() first tries
to atomically allocate the requested memory, or falls back to hand out
preallocated chunks from the mempool. If both fail, it puts the calling
process (kmirrord in this case) on a private waitqueue until somebody refills
the pool. Where the only 'somebody' is kmirrord itself, so we have a
deadlock.
I worked around this problem by falling back to a (blocking) kmalloc when
before kmirrord would have ended up on the waitqueue. This defeats part of
the benefits of using the mempool, but at least keeps the system running. And
it could be done with a two-line change. Note that mempool_alloc() clears the
GFP_NOIO flag internally, and only uses it to decide whether to wait or return
an error if immediate allocation fails, so the attached patch doesn't change
behaviour in the non-deadlocking case. Path is against current git
(2.6.18-rc4), but should apply to earlier versions as well. I've tested on
2.6.15, where this patch makes the difference between random lockup and a
stable system.
Signed-off-by: Daniel Kobras <kobras@linux.de> Acked-by: Alasdair G Kergon <agk@redhat.com> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Ben Dooks [Sun, 27 Aug 2006 08:23:22 +0000 (01:23 -0700)]
[PATCH] drivers/rtc: fix rtc-s3c.c
In the cleanups of drivers/rtc/s3c-rtc.c, the base address for the
registers got broken. This patch fixes that by ensuring the readb/writeb
are all prefixed with the base returned from ioremap()ing the registers.
Also fix check for valid year range, which was the wrong way around.
Signed-off-by: Ben Dooks <ben-linux@fluff.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Ian McDonald [Sun, 27 Aug 2006 06:40:50 +0000 (23:40 -0700)]
[DCCP]: Fix CCID3
This fixes CCID3 to give much closer performance to RFC4342.
CCID3 is meant to alter sending rate based on RTT and loss.
The performance was verified against:
http://wand.net.nz/~perry/max_download.php
For example I tested with netem and had the following parameters:
Delayed Acks 1, MSS 256 bytes, RTT 105 ms, packet loss 5%.
This gives a theoretical speed of 71.9 Kbits/s. I measured across three
runs with this patch set and got 70.1 Kbits/s. Without this patchset the
average was 232 Kbits/s which means Linux can't be used for CCID3 research
properly.
I also tested with netem turned off so box just acting as router with 1.2
msec RTT. The performance with this is the same with or without the patch
at around 30 Mbit/s.
Signed off by: Ian McDonald <ian.mcdonald@jandi.co.nz> Signed-off-by: David S. Miller <davem@davemloft.net>
The bridge-netfilter code will overwrite memory if there is not
headroom in the skb to save the header. This first showed up when
using Xen with sky2 driver that doesn't allocate the extra space.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6:
[DCCP]: Introduce dccp_rx_hist_find_entry
[DCCP]: Introduces follows48 function
[DCCP]: Update contact details and copyright
[DCCP]: Fix typo
[IPV6]: Segmentation offload not set correctly on TCP children
[CONNECTOR]: Add userspace example code into Documentation/connector/
[IPV6]: Segmentation offload not set correctly on TCP children
TCP over IPV6 would incorrectly inherit the GSO settings.
This would cause kernel to send Tcp Segmentation Offload packets for
IPV6 data to devices that can't handle it. It caused the sky2 driver
to lock http://bugzilla.kernel.org/show_bug.cgi?id=7050
and the e1000 would generate bogus packets. I can't blame the
hardware for gagging if the upper layers feed it garbage.
This was a new bug in 2.6.18 introduced with GSO support.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Evgeniy Polyakov [Fri, 25 Aug 2006 07:52:06 +0000 (00:52 -0700)]
[CONNECTOR]: Add userspace example code into Documentation/connector/
I was asked several times to include userspace example code into
Documentation, so if there is no policy against it, consider attached patch
for 2.6.18. This program works with included Documentation/connector/cn_test.c
connector module.
Signed-off-by: Evgeniy Polyakov <johnpol@2ka.mipt.ru> Signed-off-by: David S. Miller <davem@davemloft.net>
Jeff Mahoney [Fri, 25 Aug 2006 22:58:57 +0000 (15:58 -0700)]
[DISKLABEL] SUN: Fix signed int usage for sector count
The current sun disklabel code uses a signed int for the sector count.
When partitions larger than 1 TB are used, the cast to a sector_t causes
the partition sizes to be invalid:
Alan Stern [Mon, 14 Aug 2006 15:40:46 +0000 (11:40 -0400)]
[PATCH] unusual_devs update for UCR-61S2B
The existing unusual_devs entry for the UCR-61S2B appears to have too
wide a revision range. It matches at least one device that doesn't
respond to the initialization sequence. Perhaps the sequence needs to
be updated, or perhaps something else can be done. For now, this patch
(as764) restricts the range to include only the revision mentioned in
the original comment.
This resolves (for now!) Bugzilla entry #6950.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[PATCH] USB: pl2303: removed support for OTi's DKU-5 clone cable
This patch removes support for a clone of Nokia DKU-5 cable made by Ours
Technology Inc, as it turned out that the cable does not use the pl2303
chip, but OTI-6858 chip which is not compatible with the pl2303.
Signed-off-by: Tomasz Kazmierczak <tomek.fizyk@op.pl> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Scott Murray [Tue, 22 Aug 2006 23:55:57 +0000 (19:55 -0400)]
[PATCH] CPCI hotplug: fix resource assignment
Here is a patch against the CPCI hotplug core to fix up PCI resource
assignment such that things will actually work when a hot inserted
device is enabled. I mentioned this patch to you way back in April at
ELC, but am only now out from under things enough to clean it up and
submit it. I've basically cribbed the corresponding code from
shpchp_pci.c, so there are no big surprises. If it's still possible, I
wouldn't mind this going into 2.6.18, but it wouldn't be the end of the
world if it went into 2.6.19.
Signed-off-by: Scott Murray <scottm@somanetworks.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Daniel Ritz [Tue, 22 Aug 2006 14:29:10 +0000 (07:29 -0700)]
[PATCH] PCI: fix ICH6 quirks
- add the ICH6(R) LPC to the ICH6 ACPI quirks. currently only the ICH6-M
is handled. [ PCI_DEVICE_ID_INTEL_ICH6_1 is the ICH6-M LPC, ICH6_0 is
the ICH6(R) ]
- remove the wrong quirk calling asus_hides_smbus_lpc() for ICH6. the
register modified in asus_hides_smbus_lpc() has a different meaning in
ICH6.
Signed-off-by: Daniel Ritz <daniel.ritz@gmx.ch> Acked-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Daniel Ritz [Tue, 22 Aug 2006 14:29:08 +0000 (07:29 -0700)]
[PATCH] PCI: use PCBIOS as last fallback
there was a change in 2.6.17 which affected the order in which the PCI
access methods are probed. this gives regressions on some machines with
broken BIOS. the problem is that PCBIOS sometimes reports last bus wrong,
leaving cardbus non-funcational. previously those system worked fine with
direct access.
The patch changes the PCI init code to have PCBIOS as last fallback, yet
the PCBIOS code still has to run first to set pcibios_last_bus to the value
reported by the BIOS. this is needed in case legacy PCI probing
(arch/i386/pci/legacy.c) is used to detect peer busses. using direct
access if available fixes the cardbus problems.
Signed-off-by: Daniel Ritz <daniel.ritz@gmx.ch> Cc: Dave Hansen <haveblue@us.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Hans de Goede [Fri, 25 Aug 2006 08:24:20 +0000 (10:24 +0200)]
[PATCH] hwmon: abituguru timeout fixes
This patch contains 2 sets of fixes for the abituguru:
1) Much improved timeout handling, drasticly reducing the amount of
timeout errors on some motherboards
2) Fix the exit paths in the bank1 sensor type detect code to always
restore the original settings even on an error. Without this our
special test settings could remain seriously confusing the system
BIOS's setup menu.
Both are very much related and are must haves, to avoid messing up the
uguru CMOS settings.
Detailed changes:
- Much improved timeout / wait for status handling. Many thanks to Sunil
Kumar, for all his testing, ideas and patches! The code now first busy
waits, polling the uguru for the expected status as this usually
succeeds pretty quickly (within 90 reads). To avoid unnecessary CPU burn
in timeout conditions, the amount of busy waiting has been halved from
previous versions (120 tries instead of 250). This is not a problem,
because this version goes to sleep after 120 attemps for 1 jiffy and
then tries again, it does this sleep and try again 5 times before
finally giving up. This (almost?) completly removes the timeout errors
some people have seen regulary. Apparently some older uguru versions
sometimes are distracted for a (relatively) long time. This solves this.
- These timeout errors not only occur in the sending address part of
reading the uguru but also in the wait for read state, so errors in
this state are now handled as retryable just like send address state
errors and are only logged and reported to userspace if 3 executive
tries fail.
- Fix a very nasty bug in the bank1 sensor type detection code, where it
would not restore the original settings in any of the error paths!
- Since not successfully restoring the original settings can seriously
confuse the system BIOS (hang when entering the relevant setup menu),
we now try restoring them 3 times before giving up.
Signed-off-by: Hans de Goede <j.w.r.degoede@hhs.nl> Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David Brownell [Fri, 11 Aug 2006 20:53:08 +0000 (22:53 +0200)]
[PATCH] i2c: tps65010 build fixes
The tps65010.c driver in the main tree never got updated with
build fixes since the last batch of I2C driver changes; and the
genirq trigger flags were updated wierdly too.
This also includes a minor tweak to reduce the frequency used to
poll for unplug-the-AC-power on the TPS chips that don't provide
relevant IRQs. It _would_ be nice to sense whether there's even
a battery, but that'd normally be an HDQ/1-wire interface to a
smart battery, and such APIs aren't standardized.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Mike Christie [Sat, 26 Aug 2006 07:00:22 +0000 (03:00 -0400)]
[SCSI] fix scsi_send_eh_cmnd regression
The callers of scsi_send_eh_cmnd are setting the cmnd buffer,
and then scsi_send_eh_cmnd is copying that updated buffer to
the old_cmnd variable. Then after the command runs, we end up
copying that old_cmnd var which has the new cmnd to the scsi
command buffer. When this command gets recent, all types of fun
things happen like getting TUR or START_STOP commands with
data and scatterlists.
This patch made against scsi-rc-fixes, has the callers of
scsi_send_eh_cmnd pass in the command so scsi_send_eh_cmnd
can do the right thing. This should go into 2.6.18 since this
fixes a regression added when we removed some of the scsi_cmnd
fields and replaced them with local variables.
Signed-off-by: Mike Christie <michaelc@cs.wisc.edu> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
projects / linux-2.6 / log