13 Apr, 2012
32 commits
-
commit 67236c44741e250199ccd77f1115568e68cf8848 upstream.
This patch fixes a bug in target-core where unsupported WRITE_SAME ops
from a target_check_write_same_discard() failure was incorrectly
returning CHECK_CONDITION w/ TCM_INVALID_CDB_FIELD sense data.
This was causing some clients to not properly fall back, so go ahead
and use the correct TCM_UNSUPPORTED_SCSI_OPCODE sense for this case.Reported-by: Martin Svec
Signed-off-by: Nicholas Bellinger
Signed-off-by: Greg Kroah-Hartman -
commit 2a15cd2ff488a9fdb55e5e34060f499853b27c77 upstream.
With runtime PM, if the ethernet cable is disconnected, the device is
transitioned to D3 state to conserve energy. If the system is shutdown
in this state, any register accesses in rtl_shutdown are dropped on
the floor. As the device was programmed by .runtime_suspend() to wake
on link changes, it is thus brought back up as soon as the link recovers.Resuming every suspended device through the driver core would slow things
down and it is not clear how many devices really need it now.Original report and D0 transition patch by Sameer Nanda. Patch has been
changed to comply with advices by Rafael J. Wysocki and the PM folks.Reported-by: Sameer Nanda
Signed-off-by: Francois Romieu
Cc: Rafael J. Wysocki
Cc: Hayes Wang
Cc: Alan Stern
Acked-by: Rafael J. Wysocki
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit 25e341cfc33d94435472983825163e97fe370a6c upstream.
Somehow the BIOS manages to screw things up when copying the VBT
around, because the one we scrap from the VBIOS rom actually works.Tested-by: Markus Heinz
Acked-by: Chris Wilson
Reviewed-by: Rodrigo Vivi
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=28812
Signed-Off-by: Daniel Vetter
Signed-off-by: Greg Kroah-Hartman -
commit 927a2f119e8235238a2fc64871051b16c9bdae75 upstream.
i915_drm_thaw was not locking the mode_config lock when calling
drm_helper_resume_force_mode. When there were multiple wake sources,
this caused FDI training failure on SNB which in turn corrupted the
display.Signed-off-by: Sean Paul
Reviewed-by: Chris Wilson
Signed-Off-by: Daniel Vetter
Signed-off-by: Greg Kroah-Hartman -
commit f47166d2b0001fcb752b40c5a2d4db986dfbea68 upstream.
Quoting the BSpec from time immemorial:
PIPEACONF, bits 28:27: Frame Start Delay (Debug)
Used to delay the frame start signal that is sent to the display planes.
Care must be taken to insure that there are enough lines during VBLANK
to support this setting.An instance of the BIOS leaving these bits set was found in the wild,
where it caused our modesetting to go all squiffy and skewiff.Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47271
Reported-and-tested-by: Eva Wang
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43012
Reported-and-tested-by: Carl Richell
Signed-off-by: Chris Wilson
Signed-off-by: Daniel Vetter
Signed-off-by: Greg Kroah-Hartman -
commit 97effadb65ed08809e1720c8d3ee80b73a93665c upstream.
This hardware doesn't have an LVDS, it's a desktop box. Fix incorrect
LVDS detection.Signed-off-by: Anisse Astier
Acked-by: Chris Wilson
Signed-off-by: Daniel Vetter
Signed-off-by: Greg Kroah-Hartman -
commit 402976fe51b2d1a58a29ba06fa1ca5ace3a4cdcd upstream.
On pre-R600 asics, the SpeedFanControl table is not
executed as part of ASIC_Init as it is on newer asics.Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=29412Signed-off-by: Alex Deucher
Reviewed-by: Michel Dänzer
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman -
commit 62fb376e214d3c1bfdf6fbb77dac162f6da04d7e upstream.
mplayer -vo fbdev tries to create a screen that is twice as tall as the
allocated framebuffer for "doublebuffering". By default, and all in-tree
users, only sufficient memory is allocated and mapped to satisfy the
smallest framebuffer and the virtual size is no larger than the actual.
For these users, we should therefore reject any userspace request to
create a screen that requires a buffer larger than the framebuffer
originally allocated.References: https://bugs.freedesktop.org/show_bug.cgi?id=38138
Signed-off-by: Chris Wilson
Reviewed-by: Daniel Vetter
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman -
commit 643c61e119459e9d750087b7b34be94491efebf9 upstream.
In https://bugzilla.redhat.com/show_bug.cgi?id=770207, slowdowns of driver
rtl8192ce are reported. One fix (commit a9b89e2) has already been applied,
and it helped, but the maximum RX speed would still drop to 1 Mbps. As in
the previous fix, the initial gain was determined to be the problem; however,
the problem arises from a setting of the gain when scans are started.Driver rtl8192de also has the same code structure - this one is fixed as well.
Reported-and-Tested-by: Ivan Pesin
Signed-off-by: Larry Finger
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman -
commit d72308bff5c2fa207949a5925b020bce74495e33 upstream.
Is possible that we will arm the tid_rx->reorder_timer after
del_timer_sync() in ___ieee80211_stop_rx_ba_session(). We need to stop
timer after RCU grace period finish, so move it to
ieee80211_free_tid_rx(). Timer will not be armed again, as
rcu_dereference(sta->ampdu_mlme.tid_rx[tid]) will return NULL.Debug object detected problem with the following warning:
ODEBUG: free active (active state 0) object type: timer_list hint: sta_rx_agg_reorder_timer_expired+0x0/0xf0 [mac80211]Bug report (with all warning messages):
https://bugzilla.redhat.com/show_bug.cgi?id=804007Reported-by: "jan p. springer"
Signed-off-by: Stanislaw Gruszka
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman -
commit 6cfeba53911d6d2f17ebbd1246893557d5ff5aeb upstream.
On multi-platform kernels, the Mac platform devices should be registered
when running on Mac only. Else it may crash later.Signed-off-by: Geert Uytterhoeven
Signed-off-by: Greg Kroah-Hartman -
commit 12b5da349a8b94c9dbc3430a6bc42eabd9eaf50b upstream.
When reading the trace file, the records of each of the per_cpu buffers
are examined to find the next event to print out. At the point of looking
at the event, the size of the event is recorded. But if the first event is
chosen, the other events in the other CPU buffers will reset the event size
that is stored in the iterator descriptor, causing the event size passed to
the output functions to be incorrect.In most cases this is not a problem, but for the case of stack traces, it
is. With the change to the stack tracing to record a dynamic number of
back traces, the output depends on the size of the entry instead of the
fixed 8 back traces. When the entry size is not correct, the back traces
would not be fully printed.Note, reading from the per-cpu trace files were not affected.
Reported-by: Thomas Gleixner
Tested-by: Thomas Gleixner
Signed-off-by: Steven Rostedt
Signed-off-by: Greg Kroah-Hartman -
commit 01de982abf8c9e10fc3089e10585cd2cc914bdab upstream.
8 hex characters tell only half the tale for 64 bit CPUs,
so use the appropriate length.Link: http://lkml.kernel.org/r/1332411501-8059-2-git-send-email-wolfgang.mauerer@siemens.com
Signed-off-by: Wolfgang Mauerer
Signed-off-by: Steven Rostedt
Signed-off-by: Greg Kroah-Hartman -
commit f5cb92ac82d06cb583c1f66666314c5c0a4d7913 upstream.
irq_move_masked_irq() checks the return code of
chip->irq_set_affinity() only for 0, but IRQ_SET_MASK_OK_NOCOPY is
also a valid return code, which is there to avoid a redundant copy of
the cpumask. But in case of IRQ_SET_MASK_OK_NOCOPY we not only avoid
the redundant copy, we also fail to adjust the thread affinity of an
eventually threaded interrupt handler.Handle IRQ_SET_MASK_OK (==0) and IRQ_SET_MASK_OK_NOCOPY(==1) return
values correctly by checking the valid return values seperately.Signed-off-by: Jiang Liu
Cc: Jiang Liu
Cc: Keping Chen
Link: http://lkml.kernel.org/r/1333120296-13563-2-git-send-email-jiang.liu@huawei.com
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman -
commit 9aaf440f8fabcebf9ea79a62ccf4c212e6544b49 upstream.
This was lacking a comma between two supposed to be separate strings.
Signed-off-by: Jan Beulich
Signed-off-by: Michal Marek
Signed-off-by: Greg Kroah-Hartman -
commit 3e80acd1af40fcd91a200b0416a7616b20c5d647 upstream.
commit 64b3db22c04586997ab4be46dd5a5b99f8a2d390 (2.6.39),
"Remove use of unreliable FADT revision field" causes regression
for old P4 systems because now cst_control and other fields are
not reset to 0.The effect is that acpi_processor_power_init will notice
cst_control != 0 and a write to CST_CNT register is performed
that should not happen. As result, the system oopses after the
"No _CST, giving up" message, sometimes in acpi_ns_internalize_name,
sometimes in acpi_ns_get_type, usually at random places. May be
during migration to CPU 1 in acpi_processor_get_throttling.Every one of these settings help to avoid this problem:
- acpi=off
- processor.nocst=1
- maxcpus=1The fix is to update acpi_gbl_FADT.header.length after
the original value is used to check for old revisions.https://bugzilla.kernel.org/show_bug.cgi?id=42700
https://bugzilla.redhat.com/show_bug.cgi?id=727865Signed-off-by: Julian Anastasov
Acked-by: Bob Moore
Signed-off-by: Len Brown
Cc: Jonathan Nieder
Cc: Josh Boyer
Signed-off-by: Greg Kroah-Hartman -
commit 89e96ada572fb216e582dbe3f64e1a6939a37f74 upstream.
During testing pci root bus removal, found some root bus bridge is not freed.
If booting with pnpacpi=off, those hostbridge could be freed without problem.
It turns out that some devices reference are not released during acpi_pnp_match.
that match should not hold one device ref during every calling.
Add pu_device calling before returning.Signed-off-by: Yinghai Lu
Signed-off-by: Len Brown
Signed-off-by: Greg Kroah-Hartman -
commit 2815ab92ba3ab27556212cc306288dc95692824b upstream.
On Intel CPUs the processor typically uses the highest frequency
set by any logical CPU. When the system overheats
Linux first forces the frequency to the lowest available one
to lower the temperature.However this was done only per logical CPU, which means all
logical CPUs in a package would need to go through this before
the frequency is actually lowered.Worse this delay actually prevents real throttling, because
the real throttle code only proceeds when the lowest frequency
is already reached.So when a throttle event happens force the lowest frequency
for all CPUs in the package where it happened. The per CPU
state is now kept per package, not per logical CPU. An alternative
would be to do it per cpufreq unit, but since we want to bring
down the temperature of the complete chip it's better
to do it for all.In principle it may even make sense to do it for all CPUs,
but I kept it on the package for now.With this change the frequency is actually lowered, which
in terms also allows real throttling to proceed.I also removed an unnecessary per cpu variable initialization.
v2: Fix package mapping
Signed-off-by: Andi Kleen
Signed-off-by: Len Brown
Signed-off-by: Greg Kroah-Hartman -
commit b54f47c8bcfc5f766bf13ec31bd7dd1d4726d33b upstream.
Using UBI on m25p80 can give messages like:
UBI error: io_init: bad write buffer size 0 for 1 min. I/O unit
We need to initialize writebufsize; I think "page_size" is the correct
"bufsize", although I'm not sure. Comments?Signed-off-by: Brian Norris
Signed-off-by: Artem Bityutskiy
Signed-off-by: David Woodhouse
Signed-off-by: Greg Kroah-Hartman -
commit fcc44a07dae0af16e84e93425fc8afe642ddc603 upstream.
The writebufsize concept was introduce by commit
"0e4ca7e mtd: add writebufsize field to mtd_info struct" and it represents
the maximum amount of data the device writes to the media at a time. This is
an important parameter for UBIFS which is used during recovery and which
basically defines how big a corruption caused by a power cut can be.Set writebufsize to 4 because this drivers writes at max 4 bytes at a time.
Signed-off-by: Artem Bityutskiy
Signed-off-by: David Woodhouse
Signed-off-by: Greg Kroah-Hartman -
commit b604387411ec6a072e95910099262616edd2bd2f upstream.
The writebufsize concept was introduce by commit
"0e4ca7e mtd: add writebufsize field to mtd_info struct" and it represents
the maximum amount of data the device writes to the media at a time. This is
an important parameter for UBIFS which is used during recovery and which
basically defines how big a corruption caused by a power cut can be.However, we forgot to set this parameter for block2mtd. Set it to PAGE_SIZE
because this is actually the amount of data we write at a time.Signed-off-by: Artem Bityutskiy
Acked-by: Joern Engel
Signed-off-by: David Woodhouse
Signed-off-by: Greg Kroah-Hartman -
commit c4cc625ea5958d065c21cc0fcea29e9ed8f3d2bc upstream.
The writebufsize concept was introduce by commit
"0e4ca7e mtd: add writebufsize field to mtd_info struct" and it represents
the maximum amount of data the device writes to the media at a time. This is
an important parameter for UBIFS which is used during recovery and which
basically defines how big a corruption caused by a power cut can be.Set writebufsize to the flash page size because it is the maximum amount of
data it writes at a time.Signed-off-by: Artem Bityutskiy
Signed-off-by: David Woodhouse
Signed-off-by: Greg Kroah-Hartman -
commit 5289966ea576a062b80319975b31b661c196ff9d upstream.
This has been moved from .options to .bbt_options meanwhile. So, it
currently checks for something totally different (NAND_OWN_BUFFERS) and
decides according to that.Artem Bityutskiy: the options were moved in
a40f734 mtd: nand: consolidate redundant flash-based BBT flagsArtem Bityutskiy: CCing -stable
Signed-off-by: Wolfram Sang
Acked-by: Huang Shijie
Signed-off-by: Artem Bityutskiy
Signed-off-by: David Woodhouse
Signed-off-by: Greg Kroah-Hartman -
commit bf011f2ed53d587fdd8148c173c4f09ed77bdf1a upstream.
Since commit ca97dec2ab5c87e9fbdf7e882e1820004a3966fa the
command line parsing of MTD partitions does not work anymore.Signed-off-by: Daniel Schwierzeck
Signed-off-by: John Crispin
Signed-off-by: Artem Bityutskiy
Acked-by: John Crispin
Signed-off-by: David Woodhouse
Signed-off-by: Greg Kroah-Hartman -
commit a3c1e3b732b3708a80e4035b9d845f3f7c7dd0c9 upstream.
In commit "c797533 mtd: abstract last MTD partition parser argument" the
third argument of "mtd_device_parse_register()" changed from start address
of the MTD device to a pointer to a struct.The "ixp4xx_flash_probe()" function was not converted properly, causing
an oops during boot.This patch fixes the problem by filling the needed information into a
"struct mtd_part_parser_data" and passing it to
"mtd_device_parse_register()".Signed-off-by: Marc Kleine-Budde
Signed-off-by: Artem Bityutskiy
Signed-off-by: David Woodhouse
Signed-off-by: Greg Kroah-Hartman -
commit e16605855d58803fe0608417150c7a618b4f8243 upstream.
Based on latest production information.
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 464b57da56910c8737ede75ad820b9a7afc46b3e ]
The merge done in commit b26e478f undid bug fix in commit c3e072f8
("net: fsl_pq_mdio: fix non tbi phy access"), with the result that non
TBI (e.g. MDIO) PHYs cannot be accessed.Signed-off-by: Kenth Eriksson
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 78fb72f7936c01d5b426c03a691eca082b03f2b9 ]
Make CDC EEM recalculate the hard_mtu after adjusting the
hard_header_len.Without this, usbnet adjusts the MTU down to 1494 bytes, and the host is
unable to receive standard 1500-byte frames from the device.Tested with the Linux USB Ethernet gadget.
Cc: Oliver Neukum
Signed-off-by: Rabin Vincent
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 81213b5e8ae68e204aa7a3f83c4f9100405dbff9 ]
If both addresses equal, nothing needs to be done. If the device is down,
then we simply copy the new address to dev->dev_addr. If the device is up,
then we add another loopback device with the new address, and if that does
not fail, we remove the loopback device with the old address. And only
then, we update the dev->dev_addr.Signed-off-by: Daniel Borkmann
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 2240eb4ae3dc4acff20d1a8947c441c451513e37 ]
This patch corrects a bug in function sky2_open() of the Marvell Yukon 2 driver
in which the settings for PHY quick link are overwritten.Signed-off-by: Lino Sanfilippo
Acked-by: Stephen Hemminger
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 085f1afc56619bda424941412fdeaff1e32c21dc ]
If port 0 of a 5717 serdes device powers down, it hides the phy from
port 1. This patch works around the problem by keeping port 0's phy
powered up.Signed-off-by: Matt Carlson
Signed-off-by: Michael Chan
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 1d24fb3684f347226747c6b11ea426b7b992694e ]
When K >= 0xFFFF0000, AND needs the two least significant bytes of K as
its operand, but EMIT2() gives it the least significant byte of K and
0x2. EMIT() should be used here to replace EMIT2().Signed-off-by: Feiran Zhuang
Acked-by: Eric Dumazet
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
03 Apr, 2012
8 commits
-
commit c9651e70ad0aa499814817cbf3cc1d0b806ed3a1 upstream.
Since 3.2.12 and 3.3, some systems are failing to boot with a BUG_ON.
Some other systems using the pata_jmicron driver fail to boot because no
disks are detected. Passing pcie_aspm=force on the kernel command line
works around it.The cause: commit 4949be16822e ("PCI: ignore pre-1.1 ASPM quirking when
ASPM is disabled") changed the behaviour of pcie_aspm_sanity_check() to
always return 0 if aspm is disabled, in order to avoid cases where we
changed ASPM state on pre-PCIe 1.1 devices.This skipped the secondary function of pcie_aspm_sanity_check which was
to avoid us enabling ASPM on devices that had non-PCIe children, causing
trouble later on. Move the aspm_disabled check so we continue to honour
that scenario.Addresses https://bugzilla.kernel.org/show_bug.cgi?id=42979 and
http://bugs.debian.org/665420Reported-by: Romain Francoise # kernel panic
Reported-by: Chris Holland # disk detection trouble
Signed-off-by: Matthew Garrett
Tested-by: Hatem Masmoudi # Dell Latitude E5520
Tested-by: janek # pata_jmicron with JMB362/JMB363
[jn: with more symptoms in log message]
Signed-off-by: Jonathan Nieder
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 49d4bcaddca977fffdea8b0b71f6e5da96dac78e upstream.
When DMA is enabled, sh-sci transfer begins with
uart_start()
sci_start_tx()
if (cookie_tx < 0) schedule_work()
Then, starts DMA when wq scheduled, -- (A)
process_one_work()
work_fn_rx()
cookie_tx = desc->submit_tx()
And finishes when DMA transfer ends, -- (B)
sci_dma_tx_complete()
async_tx_ack()
cookie_tx = -EINVAL
(possible another schedule_work())This A to B sequence is not reentrant, since controlling variables
(for example, cookie_tx above) are not queues nor lists. So, they
must be invoked as A B A B..., otherwise results in kernel crash.To ensure the sequence, sci_start_tx() seems to test if cookie_tx < 0
(represents "not used") to call schedule_work().
But cookie_tx will not be set (to a cookie, also means "used") until
in the middle of work queue scheduled function work_fn_tx().This gap between the test and set allows the breakage of the sequence
under the very frequently call of uart_start().
Another gap between async_tx_ack() and another schedule_work() results
in the same issue, too.This patch introduces a new condition "cookie_tx == 0" just to mark
it is "busy" and assign it within spin-locked region to fill the gaps.Signed-off-by: Takashi Yoshii
Reviewed-by: Guennadi Liakhovetski
Signed-off-by: Paul Mundt
Signed-off-by: Greg Kroah-Hartman -
commit 6d8d17499810479eabd10731179c04b2ca22152f upstream.
There is no point in passing a zero length string here and quite a
few of that cache_parse() implementations will Oops if count is
zero.Signed-off-by: Dan Carpenter
Signed-off-by: J. Bruce Fields
Signed-off-by: Greg Kroah-Hartman -
commit 4a649903f91232d02284d53724b0a45728111767 upstream.
Richard Weinberger noticed that on some RTC hardware that
doesn't support UIE mode, due to coarse granular alarms
(like 1minute resolution), the current virtualized RTC
support doesn't properly error out when UIE is enabled.Instead the current code queues an alarm for the next second,
but it won't fire until up to a miniute later.This patch provides a generic way to flag this sort of hardware
and fixes the issue on the mpc5121 where Richard noticed the
problem.Reported-by: Richard Weinberger
Tested-by: Richard Weinberger
Signed-off-by: John Stultz
Signed-off-by: Greg Kroah-Hartman -
commit 1631fcea8399da5e80a80084b3b8c5bfd99d21e7 upstream.
was set up to use sys_sendfile() for the 32-bit
compat API instead of sys_sendfile64(), but in fact the right thing to
do is to use sys_sendfile64() in all cases. The 32-bit sendfile64() API
in glibc uses the sendfile64 syscall, so it has to be capable of doing
full 64-bit operations. But the sys_sendfile() kernel implementation
has a MAX_NON_LFS test in it which explicitly limits the offset to 2^32.
So, we need to use the sys_sendfile64() implementation in the kernel
for this case.Acked-by: Arnd Bergmann
Signed-off-by: Chris Metcalf
Signed-off-by: Greg Kroah-Hartman -
commit 8f0750f19789cf352d7e24a6cc50f2ab1b4f1372 upstream.
These are used as offsets into an array of GDT_ENTRY_TLS_ENTRIES members
so GDT_ENTRY_TLS_ENTRIES is one past the end of the array.Signed-off-by: Dan Carpenter
Link: http://lkml.kernel.org/r/20120324075250.GA28258@elgon.mountain
Signed-off-by: H. Peter Anvin
Signed-off-by: Greg Kroah-Hartman -
commit 57779dc2b3b75bee05ef5d1ada47f615f7a13932 upstream.
While running the latest Linux as guest under VMware in highly
over-committed situations, we have seen cases when the refined TSC
algorithm fails to get a valid tsc_start value in
tsc_refine_calibration_work from multiple attempts. As a result the
kernel keeps on scheduling the tsc_irqwork task for later. Subsequently
after several attempts when it gets a valid start value it goes through
the refined calibration and either bails out or uses the new results.
Given that the kernel originally read the TSC frequency from the
platform, which is the best it can get, I don't think there is much
value in refining it.So for systems which get the TSC frequency from the platform we
should skip the refined tsc algorithm.We can use the TSC_RELIABLE cpu cap flag to detect this, right now it is
set only on VMware and for Moorestown Penwell both of which have there
own TSC calibration methods.Signed-off-by: Alok N Kataria
Cc: John Stultz
Cc: Dirk Brandewie
Cc: Alan Cox
[jstultz: Reworked to simply not schedule the refining work,
rather then scheduling the work and bombing out later]
Signed-off-by: John Stultz
Signed-off-by: Greg Kroah-Hartman
