* 'for-linus' of git://neil.brown.name/md:
md: allow upper limit for resync/reshape to be set when array is read-only
md/raid5: Properly remove excess drives after shrinking a raid5/6
md/raid5: make sure a reshape restarts at the correct address.
md/raid5: allow new reshape modes to be restarted in the middle.
md: never advance 'events' counter by more than 1.
Remove deadlock potential in md_open
Normally we only allow the upper limit for a reshape to be decreased
when the array not performing a sync/recovery/reshape, otherwise there
could be races. But if an array is part-way through a reshape when it
is assembled the reshape is started immediately leaving no window
to set an upper bound.
If the array is started read-only, the reshape will be suspended until
the array becomes writable, so that provides a window during which it
is perfectly safe to reduce the upper limit of a reshape.
So: allow the upper limit (sync_max) to be reduced even if the reshape
thread is running, as long as the array is still read-only.
Signed-off-by: NeilBrown <neilb@suse.de>
We were removing the drives, from the array, but not
removing symlinks from /sys/.... and not marking the device
as having been removed.
Signed-off-by: NeilBrown <neilb@suse.de>
This "if" don't allow for the possibility that the number of devices
doesn't change, and so sector_nr isn't set correctly in that case.
So change '>' to '>='.
Signed-off-by: NeilBrown <neilb@suse.de>
md/raid5 doesn't allow a reshape to restart if it involves writing
over the same part of disk that it would be reading from.
This happens at the beginning of a reshape that increases the number
of devices, at the end of a reshape that decreases the number of
devices, and continuously for a reshape that does not change the
number of devices.
The current code is correct for the "increase number of devices"
case as the critical section at the start is handled by userspace
performing a backup.
It does not work for reducing the number of devices, or the
no-change case.
For 'reducing', we need to invert the test. For no-change we cannot
really be sure things will be safe, so simply require the array
to be read-only, which is how the user-space code which carefully
starts such arrays works.
Signed-off-by: NeilBrown <neilb@suse.de>
When assembling arrays, md allows two devices to have different event
counts as long as the difference is only '1'. This is to cope with
a system failure between updating the metadata on two difference
devices.
However there are currently times when we update the event count by
2. This was done to keep the event count even when the array is clean
and odd when it is dirty, which allows us to avoid writing common
update to spare devices and so allow those spares to go to sleep.
This is bad for the above reason. So change it to never increase by
two. This means that the alignment between 'odd/even' and
'clean/dirty' might take a little longer to attain, but that is only a
small cost. The spares will get a few more updates but that will
still be spared (;-) most updates and can still go to sleep.
Prior to this patch there was a small chance that after a crash an
array would fail to assemble due to the overly large event count
mismatch.
Signed-off-by: NeilBrown <neilb@suse.de>
Some gigabytes have on-board SIMG5723s connected to JMB ahcis. These
are used to implement hardware raid. Unfortunately some firmware
revisions on these 5723s don't bring the link down when all the
downstream ports are unoccupied while not responding to reset protocol
which makes libata think that there's device attached to the port but
is not responding and retry. This results in painfully wrong boot
detection time for these ports when they're empty.
This patch quirks those boards such that ahci gives up after the
initial timeout. Combined with parallel probing, this gives quick
enough probing and also is safe because SIMG5723 will respond to the
first try if any of the downstream ports is occupied.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Marc Bowes <marcbowes@gmail.com>
Reported-by: Nicolas Mailhot <Nicolas.Mailhot@LaPoste.net>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Too strong words led to spurious bug reports: Novell bugzilla #527748,
RedHat bugzilla #468800. This patch is used to soften up the dmesg on
SB600 PMP softreset failure recovery, so as to remove the scariness and
concern from community.
Reported-by: pgnet Dev <pgnet.dev@gmail.com>
Signed-off-by: Shane Huang <shane.huang@amd.com>
Cc: Tejun Heo <tj@kernel.org>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
At least the nVidia MCP55 controller quite happily supports MSI.
This adds an option to use it. It is disabled by default.
As per feedback by Robert Hancock, it will honour the user
request as the kernel will not enable MSI where the controller
or the specific system configuration do not support it.
Signed-off-by: Tony Vroon <tony@linx.net>
Cc: Robert Hancock <hancockrwd@gmail.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
OCZ Vertex SSD can't do HPA and not in a usual way. It reports HPA,
allows unlocking but then fails all IOs which fall in the unlocked
area. Quirk it so that HPA unlocking is not used for the device.
Reported by Daniel Perup in bnc#522414.
https://bugzilla.novell.com/show_bug.cgi?id=522414
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Daniel Perup <probe@spray.se>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
PIO and MWDMA timings are never programmed for the second channel
because timing registers are treated as 16-bit long ones.
The bug is an attixp -> pata_atiixp regression and goes back to:
commit 669a5db411
Author: Jeff Garzik <jeff@garzik.org>
Date: Tue Aug 29 18:12:40 2006 -0400
[libata] Add a bunch of PATA drivers.
Cc: Krystian Juskowiak <jusko@tlen.pl>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Borislav Petkov <bbpetkov@yahoo.de>
Cc: Robert Hancock <hancockrwd@gmail.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Julias Lawall discovered that pata_at91 wasn't freeing a memory region
allocated with kzalloc() on init failure paths. Upon review,
pata_at91 also seems to be doing unnecessary explicit resource
releases for managed resources too. Convert memory allocation to
managed one and drop unnecessary explicit resource releases.
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Julia Lawall <julia@diku.dk>
Cc: Sergey Matyukevich <geomatsi@gmail.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Commit 783ea7d4ee
(Driver Core: Rework platform suspend/resume, print warning)
added a warning message printed for platform drivers that use the
legacy PM callbacks rather than struct dev_pm_ops. Unfortunately,
this resulted in some confusion and made some people try to convert
drivers by replacing the old callbacks with struct dev_pm_ops in
automatic way, which generally is not a good idea.
Remove the platform device runtime dev_pm_ops warning for now,
because it's annoying to users and it's not really necessary right
now.
[rjw: Modified the changelog to be more informative.]
Signed-off-by: Magnus Damm <damm@igel.co.jp>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Commit d945cb9cc ("pty: Rework the pty layer to use the normal buffering
logic") dropped the test for 'tty->stopped' in pty_write_room(), which
then causes the n_tty line discipline thing to not throttle the data
properly when the tty is stopped.
So instead of pausing the write due to the tty being stopped, the ldisc
layer would go ahead and push it down to the pty. The pty write()
routine would then refuse to take the data (because it _did_ check
'stopped'), and the data wouldn't actually be written.
This whole stopped test should eventually be moved into the tty ldisc
layer rather than have low-level tty drivers care about these things,
but right now the fix is to just re-instate the missing pty 'stopped'
handling.
Reported-and-tested-by: Artur Skawina <art.08.09@gmail.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6:
PCI hotplug: SGI hotplug: do not use hotplug_slot_attr
PCI hotplug: SGI hotplug: fix build failure
A recent commit:
commit 449aad3e25
introduced the possibility of an A-B/B-A deadlock between
bd_mutex and reconfig_mutex.
__blkdev_get holds bd_mutex while calling md_open which takes
reconfig_mutex,
do_md_run is always called with reconfig_mutex held, and it now
takes bd_mutex in the call the revalidate_disk.
This potential deadlock was not caught by lockdep due to the
use of mutex_lock_interruptible_nexted which was introduced
by
commit d63a5a74de
do avoid a warning of an impossible deadlock.
It is quite possible to split reconfig_mutex in to two locks.
One protects the array data structures while it is being
reconfigured, the other ensures that an array is never even partially
open while it is being deactivated.
In particular, the second lock prevents an open from completing
between the time when do_md_stop checks if there are any active opens,
and the time when the array is either set read-only, or when ->pers is
set to NULL. So we can be certain that no IO is in flight as the
array is being destroyed.
So create a new lock, open_mutex, just to ensure exclusion between
'open' and 'stop'.
This avoids the deadlock and also avoids the lockdep warning mentioned
in commit d63a5a74d
Reported-by: "Mike Snitzer" <snitzer@gmail.com>
Reported-by: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Some applications/hardware combinations are triggering the message "failed to
acquire vblank counter" to be issued up to 20 times a second, which makes it
both useless and dangerous, as this may hide other important messages.
This changes makes it only appear when people are debugging.
Signed-off-by: Paul Rolland <rol@as2917.net>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Lost-twice-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The code which takes probed modes and adds them to a connector eliminates
duplicate modes by comparing them using drm_mode_equal. That function
doesn't consider the type bits, which means that any modes which differ only
in the type field will be lost.
One of the bits in the mode->type field is the DRM_MODE_TYPE_PREFERRED bit.
If the mode with that bit is lost, then higher level code will not know
which mode to select, causing a random mode to be used instead.
This patch simply merges the two mode type bits together; that seems
reasonable to me, but perhaps only a subset of the bits should be used? None
of these can be user defined as they all come from looking at just the
hardware.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6:
USB: fix oops on disconnect in cdc-acm
USB: storage: include Prolific Technology USB drive in unusual_devs list
USB: ftdi_sio: add product_id for Marvell OpenRD Base, Client
USB: ftdi_sio: add vendor and product id for Bayer glucose meter serial converter cable
USB: EHCI: fix counting of transaction error retries
USB: EHCI: fix two new bugs related to Clear-TT-Buffer
USB: usbfs: fix -ENOENT error code to be -ENODEV
USB: musb: fix the nop registration for OMAP3EVM
USB: devio: Properly do access_ok() checks
USB: pl2303: New vendor and product id
* git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-2.6:
Staging: rspiusb: Fix buffer overflow
staging: add dependencies on PCI for drivers that require it
Staging: rtl8192su: fix build error
Staging: rt2870: Revert d44ca7 Removal of kernel_thread() API
Staging: rt2870: Add USB ID for Linksys, Planex Communications, Belkin
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel: (22 commits)
drm/i915: Fix read outside array bounds in restoring the SWF10 range.
drm/i915: Use our own workqueue to avoid wedging the system along with the GPU.
drm/i915: Add support for dual-channel LVDS on 8xx.
drm/i915: Return disconnected for SDVO DVI when there's no digital EDID.
drm/i915: Choose real sdvo output according to result from detection
drm/i915: Set preferred mode for integrated TV according to TV format
drm/i915: fix 845G FIFO size & burst length
drm/i915: fix VGA detect on IGDNG
drm/i915: Add eDP support on IGDNG mobile chip
drm/i915: enable DisplayPort support on IGDNG
drm/i915: Fix channel ending action for DP aux transaction
drm/i915: fix issue in display pipe setup on IGDNG
drm/i915: disable VGA plane reliably
drm/I915: Fix offset to DVO timings in LVDS data
drm/i915: hdmi detection according by reading edid
drm/i915: correct self-refresh calculation in "everything off" case
drm/i915: handle FIFO oversubsription correctly
drm/i915: FIFO watermark calculation fixes
drm/i915: ignore lvds on AOpen Mini PC MP-915
drm/i915: Allow frame buffers up to 4096x4096 on 915/945 class hardware
...
Linus Torvalds
NeilBrown
Jeff Garzik
Tejun Heo
Shane Huang
Tony Vroon
Bartlomiej Zolnierkiewicz
Magnus Damm
Frans Pop
Paul Rolland
Keith Packard