When appending the 'cio_ignore' kernel parameter to the command line, a blank
has to be inserted in order to separate 'cio_ignore' from the preceding kernel
parameters.
Signed-off-by: Michael Holzheu <holzheu@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Return the number of bytes buffered in rxrpc_send_data().
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
ip_vs currently fails to reset its ip_vs_sync_state variable if the
sync thread fails to start properly. The result is that the kernel
will report a running daemon when their actuall is none.
If you issue the following commands:
1. ipvsadm --start-daemon master --mcast-interface bla
2. ipvsadm -L --daemon
3. ipvsadm --stop-daemon master
Assuming that bla is not an actual interface, step 2 should return no
data, but instead returns:
$ ipvsadm -L --daemon
master sync daemon (mcast=bla, syncid=0)
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
My IPsec MTU optimization patch introduced a regression in MTU calculation
for non-ESP SAs, the SA's header_len needs to be subtracted from the MTU if
the transform doesn't provide a ->get_mtu() function.
Reported-and-tested-by: Marco Berizzi <pupilla@hotmail.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
The old snd-powermac driver has some serious refcounting issues when
initialisation fails, which is the case on all new machines with
a layout-id since those are handled by the new snd-aoa driver.
Some of those bugs seem to have been under the radar for some time
(like double pci_dev_put), but one was actually added in 2.6.22 with
Stephen attempt at teaching refcounting to the driver which didn't
do it at all.
This patch fixes both, thus removing all sort of kref errors that
would happen if that driver gets loaded on a G5 machine or a recent
PowerBook due to OF nodes left around with a 0 refcount.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
The current implementation only handles -ERESTARTNOHAND, whereas we
also need to handle -ERESTART_RESTARTBLOCK in the handle_signal()
case for restartable system calls. Follows the sh change.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
The current implementation only handles -ERESTARTNOHAND, whereas we
also need to handle -ERESTART_RESTARTBLOCK in the handle_signal()
case for restartable system calls.
As noted by Carl:
This fixes the LTP test nanosleep03 - the current kernel causes
-ERESTART_RESTARTBLOCK to reach user space rather than the correct
-EINTR.
Reported-by: Carl Shaw <shaw.carl@gmail.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
iscsi_iser: convert to use the data buffer accessors
- remove the unnecessary map_single path.
- convert to use the new accessors for the sg lists and the
parameters.
TODO: use scsi_for_each_sg().
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Acked-by: Erez Zilber <erezz@voltaire.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Miklos Szeredi reported very long pauses (several seconds, sometimes
more) on his T60 (with a Core2Duo) which he managed to track down to
wait_task_inactive()'s open-coded busy-loop.
He observed that an interrupt on one core tries to acquire the
runqueue-lock but does not succeed in doing so for a very long time -
while wait_task_inactive() on the other core loops waiting for the first
core to deschedule a task (which it wont do while spinning in an
interrupt handler).
This rewrites wait_task_inactive() to do all its waiting optimistically
without any locks taken at all, and then just double-check the end
result with the proper runqueue lock held over just a very short
section. If there were races in the optimistic wait, of a preemption
event scheduled the process away, we simply re-synchronize, and start
over.
So the code now looks like this:
repeat:
/* Unlocked, optimistic looping! */
rq = task_rq(p);
while (task_running(rq, p))
cpu_relax();
/* Get the *real* values */
rq = task_rq_lock(p, &flags);
running = task_running(rq, p);
array = p->array;
task_rq_unlock(rq, &flags);
/* Check them.. */
if (unlikely(running)) {
cpu_relax();
goto repeat;
}
/* Preempted away? Yield if so.. */
if (unlikely(array)) {
yield();
goto repeat;
}
Basically, that first "while()" loop is done entirely without any
locking at all (and doesn't check for the case where the target process
might have been preempted away), and so it's possibly "incorrect", but
we don't really care. Both the runqueue used, and the "task_running()"
check might be the wrong tests, but they won't oops - they just mean
that we could possibly get the wrong results due to lack of locking and
exit the loop early in the case of a race condition.
So once we've exited the loop, we then get the proper (and careful) rq
lock, and check the running/runnable state _safely_. And if it turns
out that our quick-and-dirty and unsafe loop was wrong after all, we
just go back and try it all again.
(The patch also adds a lot of comments, which is the actual bulk of it
all, to make it more obvious why we can do these things without holding
the locks).
Thanks to Miklos for all the testing and tracking it down.
Tested-by: Miklos Szeredi <miklos@szeredi.hu>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Gene Heskett reported the following problem while testing CFS: SysRq-N
is not always effective in normalizing tasks back to SCHED_OTHER.
The reason for that turns out to be the following bug:
- normalize_rt_tasks() uses for_each_process() to iterate through all
tasks in the system. The problem is, this method does not iterate
through all tasks, it iterates through all thread groups.
The proper mechanism to enumerate over all threads is to use a
do_each_thread() + while_each_thread() loop.
Reported-by: Gene Heskett <gene.heskett@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Don't let signalfd dequeue private signals off other threads (in the
case of things like SIGILL or SIGSEGV, trying to do so would result
in undefined behaviour on who actually gets the signal, since they
are force unblocked).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Davide Libenzi <davidel@xmailserver.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This reverts commit d0aa7a70bf.
It not only introduced user space visible changes to the futex syscall,
it is also non-functional and there is no way to fix it proper before
the 2.6.22 release.
The breakage report ( http://lkml.org/lkml/2007/5/12/17 ) went
unanswered, and unfortunately it turned out that the concept is not
feasible at all. It violates the rtmutex semantics badly by introducing
a virtual owner, which hacks around the coupling of the user-space
pi_futex and the kernel internal rt_mutex representation.
At the moment the only safe option is to remove it fully as it contains
user-space visible changes to broken kernel code, which we do not want
to expose in the 2.6.22 release.
The patch reverts the original patch mostly 1:1, but contains a couple
of trivial manual cleanups which were necessary due to patches, which
touched the same area of code later.
Verified against the glibc tests and my own PI futex tests.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@elte.hu>
Acked-by: Ulrich Drepper <drepper@redhat.com>
Cc: Pierre Peiffer <pierre.peiffer@bull.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Inline data segments in send WQEs are not allowed to cross a 64 byte
boundary. We use inline data segments to hold the UD headers for MLX
QPs (QP0 and QP1). A send with GRH on QP1 will have a UD header that
is too big to fit in a single inline data segment without crossing a
64 byte boundary, so split the header into two inline data segments.
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Upcoming firmware introduces command interface revision 3, which
changes the way port capabilities are queried and set. Update the
driver to handle both the new and old command interfaces by adding a
new MLX4_FLAG_OLD_PORT_CMDS that it is set after querying the firmware
interface revision and then using the correct interface based on the
setting of the flag.
Signed-off-by: Roland Dreier <rolandd@cisco.com>
When compacting CQ entries, we need to set the correct value of the
ownership bit in case the value is different between the index we copy
the CQE from and the index we copy it to.
Found by Ronni Zimmerman of Mellanox.
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
The calculation of max_inline_data in set_kernel_sq_size() is bogus,
since it doesn't take into account the fact that inline segments may
not cross a 64-byte boundary, and hence multiple inline segments will
probably need to be used to post large inline sends.
We don't support inline sends for kernel QPs anyway, so there's no
point in doing this calculation anyway, since the field is just zeroed
out a little later. So just delete the bogus calculation.
Signed-off-by: Roland Dreier <rolandd@cisco.com>
New ConnectX firmware introduces FW command interface revision 2,
which requires that for each QP, a chunk of send queue entries (the
"headroom") is kept marked as invalid, so that the HCA doesn't get
confused if it prefetches entries that haven't been posted yet. Add
code to the driver to do this, and also update the user ABI so that
userspace can request that the prefetcher be turned off for userspace
QPs (we just leave the prefetcher on for all kernel QPs).
Unfortunately, marking send queue entries this way is confuses older
firmware, so we change the driver to allow only FW command interface
revisions 2. This means that users will have to update their firmware
to work with the new driver, but the firmware is changing quickly and
the old firmware has lots of other bugs anyway, so this shouldn't be too
big a deal.
Based on a patch from Jack Morgenstein <jackm@dev.mellanox.co.il>.
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Add the kernel release and version information to the output of
show_regs/oops. Add the CPU PSR register. Avoid using printk
to output partial lines; always output a complete line.
Re-combine the "Control" and "Table + DAC" lines after nommu
separated them; we don't want to waste vertical screen space
needlessly.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
As Russell helpfully pointed out on linux-arch:
http://marc.info/?l=linux-arch&m=118208089204630&w=2
We were missing the oops_enter/exit() in the sh die() implementation.
As we do support lockdep, it's beneficial to add these calls so lockdep
properly disables itself in the die() case.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
In the routine acpi_ut_create_package_object(), if the
ACPI_ALLOCATE_ZEROED() fails then ACPI_FREE(package_desc) is called as
part of the cleanup. This should instead be
acpi_ut_remove_reference(package_desc) in order to remove the reference
acquired from acpi_ut_create_internal_object() [see the routine
acpi_ut_create_buffer_object() as an example of proper functionality].
Signed-off-by: Myron Stowe <myron.stowe@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
if acpi_bus_get_device() returns NULL, print nothing
instead of "<NUL" in /proc/acpi/thermal_zone/*/trip_points
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
This patch updates the driver version to 8.2.1
Signed-off-by: James Smart <James.Smart@emulex.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
This patch is a reworked version of the data buffer accessors patch
so that it applies on the NPIV sources.
The original patch was developed and submitted by Fujita Tomonori:
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
http://marc.info/?l=linux-scsi&m=117896446832171&w=2
- remove the unnecessary map_single path.
- convert to use the new accessors for the sg lists and the
parameters.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Signed-off-by: James Smart <James.Smart@emulex.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Following the NPIV support, the following changes have been accumulated
in the testing and qualification of the driver:
- Fix affinity of ELS ring to slow/deferred event processing
- Fix Ring attention masks
- Defer dev_loss_tmo timeout handling to worker thread
- Consolidate link down error classification for better error checking
- Remove unused/deprecated nlp_initiator_tmr timer
- Fix for async scan - move adapter init code back into pci_probe_one
context. Fix async scan interfaces.
- Expand validation of ability to create vports
- Extract VPI resource cnt from firmware
- Tuning of Login/Reject policies to better deal with overwhelmned targets
- Misc ELS and discovery fixes
- Export the npiv_enable attribute to sysfs
- Mailbox handling fix
- Add debugfs support
- A few other small misc fixes:
- wrong return values, double-frees, bad locking
- Added adapter failure heartbeat
Signed-off-by: James Smart <James.Smart@emulex.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
NPIV support is added to the driver. It utilizes the interfaces of
the fc transport for the creation and deletion of vports. Within the
driver, a new Scsi_Host is created for each NPIV instance, and is
paired with a new instance of a FC port. This allows N FC Port
elements to share a single Adapter.
Signed-off-by: James Smart <James.Smart@emulex.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
NPIV support is only available via new adapter interface extensions,
termed SLI-3. This interface changes some of the basic behaviors such
as command and response ring element sizes and data structures, as
well as a change in buffer posting. Note: the new firmware extensions
are found only on our mid-range and enterprise 4Gig adapters - so NPIV
support is available only on these newer adapters. The latest firmware
can be downloaded from the Emulex support page.
Signed-off-by: James Smart <James.Smart@emulex.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
The driver is reorganized to separate the handling of the adapter from
the handling of the FC port. Adapter handling includes submissions of
command requests, receiving responses, and managing adapter resources.
The FC port includes the discovery engine, login handling, and the
mapping of a Scsi_Host on the "port". Although not a large functional
change, as it touches core structures and functions, resulting in a
large text delta.
Signed-off-by: James Smart <James.Smart@emulex.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
We use R0 as the 5th argument of syscall. When the syscall restarts
after signal handling, we should restore the old value of R0.
The attached patch does it. Without this patch, I've experienced random
failures in the situation which signals are issued frequently.
Signed-off-by: Kaz Kojima <kkojima@rr.iij4u.or.jp>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
- convert to use the new accessors for the sg lists and the
parameters.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: David Miller <davem@davemloft.net>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
- remove the unnecessary map_single path.
- convert to use the new accessors for the sg lists and the
parameters.
Jens Axboe <jens.axboe@oracle.com> did the for_each_sg cleanup.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Acked-by: HighPoint Linux Team <linux@highpoint-tech.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
New driver for Amiga Zorro bus NCR53c710 SCSI controllers, using the 53c700
SCSI core.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
New driver for the Amiga 4000T built-in NCR53c710 SCSI controller, using the
53c700 SCSI core.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
New driver for the MVME16x NCR53C710 SCSI controller, using the 53c700 SCSI
core.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
New driver for the BVME6000 NCR53C710 SCSI controller, using the 53c700 SCSI
core.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Add m68k support to the 53c700 SCSI driver
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
If there is IO going to the volume while a hidden disk is being torn down,
there is a case where we would return a DID_NO_CONNECT for IO sent to the
volume. The end result is the volume goes read-only. This problem is due to the
fact the firmware mapped target ids saved in per device object is phys_disk_num
for hidden raid components, and target_id for the volume. There is a single
case when both phys_disk_num and target_id are equal, so enters this issue. We
fix this issue by checking the tflags when the device is torned down,
insuring the IO being completed is meant for hidden raid component, not the
volume. In addition to this fix, there are a couple other cases to address
hidden raid components. For instance task_abort and device reset are not
supported by mpt fw for hidden raid components, a bus reset would be required
or target reset to volume.
Signed-off-by: Eric Moore <Eric.Moore@lsi.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
nice cosmetic cleaning of eh thread callback funtions
Signed-off-by: Eric Moore <Eric.Moore@lsi.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
I was investigating strange driver behaviour and thought that readable
code and proper visible types might help explain why it didn't work right
the moment a second SCB was outstanding to the controller. I was right
- Cleanup, linuxise, demacro
- Remove the BSD dual licence on the new work
- Switch the if ALPHA to if __LP64__. (struct size is then right
elsewhere) and then to CONFIG_64BIT as per Christoph's request
- Fix the recursive locking on a reset. This is the only actual real code
change (I hope ;)).
I'm not clear what the right way to handle the BIOS param stuff is on n
on x86-32/64. Using phys_to_virt and stuff is ugly and probably doesn't
make sense elsewhere
Still has a couple of odd things - and there seems to be a commonly shared
EEPROM handling error several drivers have. Roughly speaking several SCSI
drivers go
try and read EEPROM
It failed..
Write any changes between the default and the data we read
Which is great as for some paths we've no idea what was in
before, so each boot won't write it all back, won't checksum but will
repeat the bug
Also it can still sleep for a second with IRQ off, and there is some
dubious looking error path locking marked FIXME in case anyone feels
inspired to work on it. Not a newly introduced bug, and at least its now
marked.
Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
When a target scan is initiated from sysfs, we should check the
portstate prior to invoke scsi_scan_target().
Otherwise scsi_scan_target() might oops as the rport might already
been removed from the scsi host and the traversal from the rport to
the scsi_host in scsi_scan_target() will fail.
Also the portstate already told us that communication with the target
has failed, so it's quite pointless to try.
Signed-off-by: Hannes Reinecke <hare@suse.de>
Cc: James Smart <James.Smart@Emulex.Com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
- remove the unnecessary map_single path.
- convert to use the new accessors for the sg lists and the
parameters.
TODO: use scsi_for_each_sg().
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Acked-by: Mike Christie <michaelc@cs.wisc.edu>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
rewrite of mpt_fc_log_info to use the enum/defines from mpi_log_fc.h
Signed-off-by: Eric Moore <Eric.Moore@lsi.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Update assocated fusion sources with new support email address.
Signed-off-by: Eric Moore <Eric.Moore@lsi.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
