Make sure we cleanup all MAC related resources (entries in the port MAC
table and steering rules) when stopping a port or when the driver is unloaded.
The leak was introduced by commit 07cb4b0a "net/mlx4_en: Manage hash of MAC
addresses per port".
Signed-off-by: Yan Burman <yanb@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Remove unnecessary use of workqueue for the device MAC address setting
flow, and fix a race when setting MAC address which was introduced by
commit c07cb4b0a "net/mlx4_en: Manage hash of MAC addresses per port"
The race happened when mlx4_en_replace_mac was being executed in parallel
with a successive call to ndo_set_mac_address, e.g witn an A/B/A MAC
setting configuration test, the third set fails.
With this change we also properly report an error if set MAC fails.
Signed-off-by: Yan Burman <yanb@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The set_param_l function assumes casting a u64 pointer to a u32 pointer
allows to access the lower 32bits, but it results in writing the upper
32 bits on big endian systems.
The fixed function reads the upper 32 bits of the 64 argument, and or's
them with the 32 bits of the 32-bit value passed to the function.
Since this is now a "read-modify-write" operation, we got many
"unintialized variable" warnings which needed to be fixed as well.
Reported-by: Alexander Schmidt <alexschm@de.ibm.com>.
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Older kernels detect DMFS (device-managed flow steering) from the HCA
device capability directly, regardless of whether the capability was
enabled in INIT_HCA, this is fixed by commit 7b8157bed "mlx4_core: Adjustments
to Flow Steering activation logic for SR-IOV"
To protect against guests running kernels without this fix, the host driver
should turn off the DMFS capability bit in mlx4_QUERY_DEV_CAP_wrapper.
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Guests kernels may not correctly detect if DMFS (device-enabled flow steering) is
activated by the host. If DMFS is activated, the master should return error to guests
which try to use the B0-steering flow calls (mlx4_QP_ATTACH).
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The MIP_ADDRESS state has 2 meanings. If the texture has one sample
per pixel, it's a pointer to the mipmap chain. If the texture has
multiple samples per pixel, it's a pointer to FMASK, a metadata buffer
needed for reading compressed MSAA textures. The mipmap
alignment rules do not apply to FMASK.
Signed-off-by: Marek Olšák <maraeo@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The MC is mostly likely busy (e.g., display requests), not hung
so no need to reset it. Doing an MC reset is tricky and not
particularly reliable. Fixes hangs in certain cases.
Reported-by: Josh Boyer <jwboyer@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
vbios values are wrong leading to colors that are
too bright. Use the default values instead.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Avoids splatter if the interrupt handler is not registered due
to acceleration being disabled.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Cc: stable@vger.kernel.org
hid_output_raw_report() makes a direct call to usb_control_msg(). However,
some USB3 boards have shown that the usb device is not ready during the
.probe(). This blocks the entire usb device, and the paired mice, keyboards
are not functional. The dmesg output is the following:
[ 11.912287] logitech-djreceiver 0003:046D:C52B.0003: hiddev0,hidraw0: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:14.0-2/input2
[ 11.912537] logitech-djreceiver 0003:046D:C52B.0003: logi_dj_probe:logi_dj_recv_query_paired_devices error:-32
[ 11.912636] logitech-djreceiver: probe of 0003:046D:C52B.0003 failed with error -32
Relying on the scheduled call to usbhid_submit_report() fixes the problem.
related bugs:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1072082https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1039143https://bugzilla.redhat.com/show_bug.cgi?id=840391https://bugzilla.kernel.org/show_bug.cgi?id=49781
Reported-and-tested-by: Bob Bowles <bobjohnbowles@gmail.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This patch fixes some annoying messages like 'Error reading PHY register' and
'Hardware Erorr' and saves several seconds on reboot.
Cc: Bruce Allan <bruce.w.allan@intel.com>
Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Borislav Petkov <bp@suse.de>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
This patch removes redundant actions from driver and fixes its interaction
with actions in pci-bus runtime power management code.
It removes pci_save_state() from __e1000_shutdown() for normal adapters,
PCI bus callbacks pci_pm_*() will do all this for us. Now __e1000_shutdown()
switches to D3-state only quad-port adapters, because they needs quirk for
clearing false-positive error from downsteam pci-e port.
pci_save_state() now called after clearing bus-master bit, thus __e1000_resume()
and e1000_io_slot_reset() must set it back after restoring configuration space.
This patch set get_link_status before calling pm_runtime_put() in e1000_open()
to allow e1000_idle() get real link status and schedule first runtime suspend.
This patch also enables wakeup for device if management mode is enabled
(like for WoL) as result pci_prepare_to_sleep() would setup wakeup without
special actions like custom 'enable_wakeup' sign.
Cc: Bruce Allan <bruce.w.allan@intel.com>
Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Borislav Petkov <bp@suse.de>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
This patch removes redundant and unbalanced pci_disable_device() from
__e1000_shutdown(). pci_clear_master() is enough, device can go into
suspended state with elevated enable_cnt.
Bug was introduced in commit 23606cf5d1192c2b17912cb2ef6e62f9b11de133
("e1000e / PCI / PM: Add basic runtime PM support (rev. 4)") in v2.6.35
Cc: Bruce Allan <bruce.w.allan@intel.com>
CC: Stable <stable@kernel.org>
Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Borislav Petkov <bp@suse.de>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
A bunch of fixes, nothing truely horrible:
- Fix PCH irq handling race which resulted in missed gmbus/dp aux irqs
and subsequent fallout (Paulo)
- Fixup off-by-one in our hsw id table (Kenneth)
- Fixup ilk rc6 support (disabled by default), regression introduced in
3.8
- g4x plane w/a from Egbert Eich
- gen2/3/4 dpms suspend/standy fixes for VGA outputs from Patrik Jakobsson
- Workaround dying ivb machines with less aggressive rc6 values (Stéphane
Marchesin)
* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel:
drm/i915: Turn off hsync and vsync on ADPA when disabling crt
drm/i915: Fix incorrect definition of ADPA HSYNC and VSYNC bits
drm/i915: also disable south interrupts when handling them
drm/i915: enable irqs earlier when resuming
drm/i915: Increase the RC6p threshold.
DRM/i915: On G45 enable cursor plane briefly after enabling the display plane.
drm/i915: Fix Haswell/CRW PCI IDs.
drm/i915: Don't clobber crtc->fb when queue_flip fails
drm/i915: wait_event_timeout's timeout is in jiffies
drm/i915: Fix missing variable initilization
* pm-fixes:
cpufreq / intel_pstate: Do not load on VM that does not report max P state.
cpufreq / intel_pstate: Fix intel_pstate_init() error path
PM / QoS: Remove device PM QoS sysfs attributes at the right place
PM / QoS: Fix concurrency issues and memory leaks in device PM QoS
cpufreq: highbank: do not initialize array with a loop
PM / OPP: improve introductory documentation
cpufreq: Fix a typo in comment
mailbox, pl320-ipc: remove __init from probe function
It seems some VMs support the P state MSRs but return zeros. Fail
gracefully if we are running in this environment.
References: https://bugzilla.redhat.com/show_bug.cgi?id=916833
Reported-by: Josh Boyer <jwboyer@redhat.com>
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
If cpufreq_register_driver() fails just free memory that has been
allocated and return. intel_pstate_exit() function is removed since we
are built-in only now there is no reason for a module exit procedure.
Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
John W. Linville says:
====================
This time just passing along a big batch of fixes from Johannes...
For the mac80211 bits:
"Here I have fixes from Ben Greear for stray work items when deleting
interfaces, another idle handling fix from Felix, a fix from Marco ro a
mesh PS buffering crash and I have a fix for the VHT MCS calculation in
association request frames and more nl80211 feature advertising removal
as well as a workaround to increase the dump size if the SKB overhead is
too large. For 3.10 I already have a complete fix queued, but that also
requires (simple) userspace changes."
And for the iwlwifi bits:
"The patches from Dor fix a bunch of calibration issues in the new MVM
driver, and Emmanuel has a number of fixes there as well. Also, we
decided to disable 8k A-MSDU by default, so that's in there. My own
patches are addressing an issue we found with the new devices but that
seems to also exist on older ones, the DMA writeback the devices do can
be delayed and cause issues. The fix is unfortunately relatively large
and depends on two other changes (to not be hugely conflicting), but I
think it's still worth it at this point."
As Johannes says, it is a bit large. But I hope it is still early
enough in the cycle to make that worthwhile.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
The SLIPORT_SEMAPHORE register shadowed in the
config-space may not reflect the correct POST stage after
an EEH reset in BE2/3; it may return FW_READY state even though
FW is not ready. This causes the driver to prematurely
poll the FW mailbox and fail.
For BE2/3 use the CSR-BAR/0xac instead.
Reported-by: Gavin Shan <shangw@linux.vnet.ibm.com>
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Ben Hutchings says:
====================
Fix regressions introduced by the last set of fixes (sorry):
1. Potential deadlock when disabling TX queues.
2. RX was broken on architectures other than x86 and powerpc.
I still expect to send one more bug fix for 3.9, but as it sometimes
takes days to reproduce the bug it's going to take a couple of weeks of
testing to be confident that it's really fixed.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
RX DMA buffers start at an offset of EFX_PAGE_IP_ALIGN bytes from the
start of a cache line. This offset obviously needs to be included in
the virtual address, but this was missed in commit b590ace09d51
('sfc: Fix efx_rx_buf_offset() in the presence of swiotlb') since
EFX_PAGE_IP_ALIGN is equal to 0 on both x86 and powerpc.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
efx_device_detach_sync() locks all TX queues before marking the device
detached and thus disabling further TX scheduling. But it can still
be interrupted by TX completions which then result in TX scheduling in
soft interrupt context. This will deadlock when it tries to acquire
a TX queue lock that efx_device_detach_sync() already acquired.
To avoid deadlock, we must use netif_tx_{,un}lock_bh().
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
According to PRM we need to disable hsync and vsync even though ADPA is
disabled. The previous code did infact do the opposite so we fix it.
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56359
Tested-by: max <manikulin@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The git commit d5aaffa9dd531c978c6f3fea06a2972653bd7fc8
(cpufreq: handle cpufreq being disabled for all exported function)
tightens the cpufreq API by returning errors when disable_cpufreq()
had been called.
The problem we are hitting is that the module xen-acpi-processor which
uses the ACPI's functions: acpi_processor_register_performance,
acpi_processor_preregister_performance, and acpi_processor_notify_smm
fails at acpi_processor_register_performance with -22.
Note that earlier during bootup in arch/x86/xen/setup.c there is also
an call to cpufreq's API: disable_cpufreq().
This is b/c we want the Linux kernel to parse the ACPI data, but leave
the cpufreq decisions to the hypervisor.
In v3.9 all the checks that d5aaffa9dd531c978c6f3fea06a2972653bd7fc8
added are now hit and the calls to cpufreq_register_notifier will now
fail. This means that acpi_processor_ppc_init ends up printing:
"Warning: Processor Platform Limit not supported"
and the acpi_processor_ppc_status is not set.
The repercussions of that is that the call to
acpi_processor_register_performance fails right away at:
if (!(acpi_processor_ppc_status & PPC_REGISTERED))
and we don't progress any further on parsing and extracting the _P*
objects.
The only reason the Xen code called that function was b/c it was
exported and the only way to gather the P-states. But we can also
just make acpi_processor_get_performance_info be exported and not
use acpi_processor_register_performance. This patch does so.
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Joseph was hitting a failure case when mounting efivarfs which
resulted in an incorrect error message,
$ sudo mount -v /sys/firmware/efi/efivars mount: Cannot allocate memory
triggered when efivarfs_valid_name() returned -EINVAL.
Make sure we pass accurate return values up the stack if
efivarfs_fill_super() fails to build inodes for EFI variables.
Reported-by: Joseph Yasi <joe.yasi@gmail.com>
Reported-by: Lingzhu Xiang <lxiang@redhat.com>
Cc: Josh Boyer <jwboyer@redhat.com>
Cc: Jeremy Kerr <jk@ozlabs.org>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: <stable@vger.kernel.org> # v3.8
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Stricter validation was introduced with commit da27a24383b2b
("efivarfs: guid part of filenames are case-insensitive") and commit
47f531e8ba3b ("efivarfs: Validate filenames much more aggressively"),
which is necessary for the guid portion of efivarfs filenames, but we
don't need to be so strict with the first part, the variable name. The
UEFI specification doesn't impose any constraints on variable names
other than they be a NULL-terminated string.
The above commits caused a regression that resulted in users seeing
the following message,
$ sudo mount -v /sys/firmware/efi/efivars mount: Cannot allocate memory
whenever pstore EFI variables were present in the variable store,
since their variable names failed to pass the following check,
/* GUID should be right after the first '-' */
if (s - 1 != strchr(str, '-'))
as a typical pstore filename is of the form, dump-type0-10-1-<guid>.
The fix is trivial since the guid portion of the filename is GUID_LEN
bytes, we can use (len - GUID_LEN) to ensure the '-' character is
where we expect it to be.
(The bogus ENOMEM error value will be fixed in a separate patch.)
Reported-by: Joseph Yasi <joe.yasi@gmail.com>
Tested-by: Joseph Yasi <joe.yasi@gmail.com>
Reported-by: Lingzhu Xiang <lxiang@redhat.com>
Cc: Josh Boyer <jwboyer@redhat.com>
Cc: Jeremy Kerr <jk@ozlabs.org>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: <stable@vger.kernel.org> # v3.8
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
UEFI variables are typically stored in flash. For various reasons, avaiable
space is typically not reclaimed immediately upon the deletion of a
variable - instead, the system will garbage collect during initialisation
after a reboot.
Some systems appear to handle this garbage collection extremely poorly,
failing if more than 50% of the system flash is in use. This can result in
the machine refusing to boot. The safest thing to do for the moment is to
forbid writes if they'd end up using more than half of the storage space.
We can make this more finegrained later if we come up with a method for
identifying the broken machines.
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Cc: Josh Boyer <jwboyer@redhat.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Disable bits for ADPA HSYNC and VSYNC where mixed up resulting in suspend
becoming standby and vice versa. Fixed by swapping their bit position.
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The number of DMA fault reasons in intel's document are from 1
to 0xD, but in dmar.c fault reason 0xD is not printed out.
In this document:
"Intel Virtualization Technology for Directed I/O Architecture Specification"
http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Direct_IO.pdf
Chapter 4. Support For Device-IOTLBs
Table 6. Unsuccessful Translated Requests
There is fault reason for 0xD not listed in kernel:
Present context-entry used to process translation request
specifies blocking of Translation Requests (Translation Type (T)
field value not equal to 01b).
This patch adds reason 0xD as well.
Signed-off-by: Li, Zhen-Hua <zhen-hual@hp.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Donald Dutile <ddutile@redhat.com>
Cc: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: Hannes Reinecke <hare@suse.de>
Link: http://lkml.kernel.org/r/1362537797-6034-1-git-send-email-zhen-hual@hp.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
While PCI card faces EEH errors, reset (usually hot reset) is
expected to recover from the EEH errors. After EEH core finishes
the reset, the driver callback (be_eeh_reset) is called and wait
the firmware to complete POST successfully. The original code would
return with error once detecting failure during POST stage. That
seems not enough.
The patch forces the driver (be_eeh_reset) to wait the firmware
completes POST until timeout, instead of returning error upon
detection POST failure immediately. Also, it would improve the
reliability of the EEH funtionality of the driver.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
Acked-by: Sathya Perla <sathya.perla@emulex.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
We should reset nf settings bond to the skb as ipip/ipgre do.
If not, the conntrack/nat info bond to the origin packet may continually
redirect the packet to vxlan interface causing a routing loop.
this is the scenario:
VETP VXLAN Gateway
/----\ /---------------\
| | | |
| vx+--+vx --NAT-> eth0+--> Internet
| | | |
\----/ \---------------/
when there are any packet coming from internet to the vetp, there will be lots
of garbage packets coming out the gateway's vxlan interface, but none actually
sent to the physical interface, because they are redirected back to the vxlan
interface in the postrouting chain of NAT rule, and dmesg complains:
Mar 1 21:52:53 debian kernel: [ 8802.997699] Dead loop on virtual device vxlan0, fix it urgently!
Mar 1 21:52:54 debian kernel: [ 8804.004907] Dead loop on virtual device vxlan0, fix it urgently!
Mar 1 21:52:55 debian kernel: [ 8805.012189] Dead loop on virtual device vxlan0, fix it urgently!
Mar 1 21:52:56 debian kernel: [ 8806.020593] Dead loop on virtual device vxlan0, fix it urgently!
the patch should fix the problem
Signed-off-by: Zang MingJie <zealot0630@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Jeff Kirsher says:
===================
This series contains fixes to e1000e and igb.
The e1000e fix resolves an issue at 1000Mbps link speed, where one of the
MAC's internal clocks can be stopped for up to 4us when entering K1 (a
power mode of the MAC-PHY interconnect). If the MAC is waiting for
completion indications for 2 DMA write requests into Host memory
(e.g. descriptor writeback or Rx packet writing) and the
indications occur while the clock is stopped, both indications will be
missed by the MAC causing the MAC to wait for the completion indications
and be unable to generate further DMA write requests. This results in an
apparent hardware hang. The patch works-around the issue by disabling
the de-assertion of the clock request when 1000Mbps link is acquired (K1
must be disabled while doing this).
The igb fix to drop BUILD_BUG_ON check from igb_build_rx_buffer resolves
a build error on s390 devices. The igb driver was throwing a build error
due to the fact that a frame built using build_skb would be larger than 2K.
Since this is not likely to change at any point in the future we are better
off just dropping the check since we already had a check in
igb_set_rx_buffer_len that will just disable the usage of build_skb anyway.
The igb fix for i210 link setup changes the setup copper link function
to use a switch statement, so that the appropriate setup link function
is called for the given PHY types.
Lastly, the igb fix for a lockdep issue in igb_get_i2c_client resolves
the issue by re-factoring the initialization and usage of the i2c_client.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Pull powerpc fixes from Ben Herrenschmidt:
"Here are a few powerpc bits & fixes for rc1. A couple of str*cpy
fixes, some fixes in handling the FSCR register on Power8 (controls
the enabling of processor features), a 32-bit build fix and a couple
more nits."
* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
powerpc: Set DSCR bit in FSCR setup
powerpc: Add DSCR FSCR register bit definition
powerpc: Fix setting FSCR for HV=0 and on secondary CPUs
powerpc: Wireup the kcmp syscall to sys_ni
powerpc: Remove unused BITOP_LE_SWIZZLE macro
powerpc: Avoid link stack corruption in MMU on syscall entry path
drivers/tty/hvc: Use strlcpy instead of strncpy
powerpc/pseries/hvcserver: Fix strncpy buffer limit in location code
powerpc: Fix compile of sha1-powerpc-asm.S on 32-bit
into scatterlists. Jens has a check queued for this, so it shouldn't happen
again.
Thanks,
Rusty.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJRNTJTAAoJENkgDmzRrbjxW9gQAIWBlCZre5eWYAny6/rnCoix
Hj/5mH6PI1VZZw9S8vLyKdZ/DJDdsLQSFsofDBvQyEzJ1rTwNx0bnxXnlCgzX3WE
9/s2/oa49a4ceep8PCyz72N+eNIdRdhwhuRjRTBsT4o9Qle187WlZFPjMQdS+u96
U+sIhh7uWmRsob7QofjXW43K2DM9lKCKN3u3fTB7q4cZ1BDTnlOCwTXRBCZjInoc
XgVXIf9my8/WXsWQZEYmnwUDg/smPXQCa+kxKewW00zXQ7A5K+Q6TXpKBj3o1C84
Y7mGozW5jcRw4bGxUj18Rq2e5VsgJ5ZZj25EuiBGGSvF+7DAUWIbZUkrf9HyUMc3
Z7MnEfNuwIOZ/YPyzcsRl+45sv6NI2bA429uiGVWlcnWh4uVbSMzFAvCjmc3BpAM
zC+zazion8HG3Yr3veAqIT6N1KJu7qKfvmPxh4KaFCK/0DzQa7ENwttudwk+5zPs
nSYPsfy6HlTkcGpglVWDELwPO85jBEmB8EMwPWCbw5dGfem/WjrbmvwNPxWjzvrw
BqJOfm8pWqdW4c3Bu60u2py6tp4L44trVn8jfl0drspvT97lAwDLWD3Qtbh+Trlz
fVqhVGpDttB+cYDQktXPOdKtp9Z4boQ4RnOv0GJIsogLulA/BY/hEZqYOKRGgwJC
Zh5RYphDYiWP41FMSLLv
=OHfs
-----END PGP SIGNATURE-----
Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux
Pull virtio hwrng fix from Rusty Russell:
"Nasty side-effect of vmalloc'ing modules: their static vars cannot be
put into scatterlists. Jens has a check queued for this, so it
shouldn't happen again.
We could fix this in virtio_rng, but it's actually far easier to just
do it in the core"
* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux:
hw_random: make buffer usable in scatterlist.
Pull networking fixes from David Miller:
"A moderately sized pile of fixes, some specifically for merge window
introduced regressions although others are for longer standing items
and have been queued up for -stable.
I'm kind of tired of all the RDS protocol bugs over the years, to be
honest, it's way out of proportion to the number of people who
actually use it.
1) Fix missing range initialization in netfilter IPSET, from Jozsef
Kadlecsik.
2) ieee80211_local->tim_lock needs to use BH disabling, from Johannes
Berg.
3) Fix DMA syncing in SFC driver, from Ben Hutchings.
4) Fix regression in BOND device MAC address setting, from Jiri
Pirko.
5) Missing usb_free_urb in ISDN Hisax driver, from Marina Makienko.
6) Fix UDP checksumming in bnx2x driver for 57710 and 57711 chips,
fix from Dmitry Kravkov.
7) Missing cfgspace_lock initialization in BCMA driver.
8) Validate parameter size for SCTP assoc stats getsockopt(), from
Guenter Roeck.
9) Fix SCTP association hangs, from Lee A Roberts.
10) Fix jumbo frame handling in r8169, from Francois Romieu.
11) Fix phy_device memory leak, from Petr Malat.
12) Omit trailing FCS from frames received in BGMAC driver, from Hauke
Mehrtens.
13) Missing socket refcount release in L2TP, from Guillaume Nault.
14) sctp_endpoint_init should respect passed in gfp_t, rather than use
GFP_KERNEL unconditionally. From Dan Carpenter.
15) Add AISX AX88179 USB driver, from Freddy Xin.
16) Remove MAINTAINERS entries for drivers deleted during the merge
window, from Cesar Eduardo Barros.
17) RDS protocol can try to allocate huge amounts of memory, check
that the user's request length makes sense, from Cong Wang.
18) SCTP should use the provided KMALLOC_MAX_SIZE instead of it's own,
bogus, definition. From Cong Wang.
19) Fix deadlocks in FEC driver by moving TX reclaim into NAPI poll,
from Frank Li. Also, fix a build error introduced in the merge
window.
20) Fix bogus purging of default routes in ipv6, from Lorenzo Colitti.
21) Don't double count RTT measurements when we leave the TCP receive
fast path, from Neal Cardwell."
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (61 commits)
tcp: fix double-counted receiver RTT when leaving receiver fast path
CAIF: fix sparse warning for caif_usb
rds: simplify a warning message
net: fec: fix build error in no MXC platform
net: ipv6: Don't purge default router if accept_ra=2
net: fec: put tx to napi poll function to fix dead lock
sctp: use KMALLOC_MAX_SIZE instead of its own MAX_KMALLOC_SIZE
rds: limit the size allocated by rds_message_alloc()
MAINTAINERS: remove eexpress
MAINTAINERS: remove drivers/net/wan/cycx*
MAINTAINERS: remove 3c505
caif_dev: fix sparse warnings for caif_flow_cb
ax88179_178a: ASIX AX88179_178A USB 3.0/2.0 to gigabit ethernet adapter driver
sctp: use the passed in gfp flags instead GFP_KERNEL
ipv[4|6]: correct dropwatch false positive in local_deliver_finish
l2tp: Restore socket refcount when sendmsg succeeds
net/phy: micrel: Disable asymmetric pause for KSZ9021
bgmac: omit the fcs
phy: Fix phy_device_free memory leak
bnx2x: Fix KR2 work-around condition
...
This branch contains a few bug fixes that I missed the first time around
and updates to the gpio_desc series included in the first pull request.
This tag has been retagged to drop the 2 head commits because the one of
them caused a build failure.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJRM/rxAAoJEEFnBt12D9kBQrIQAITeMNChzMcfjC77vlGsquf4
YXstt6buUAc1Nz3cB+N/ut8etgmVzTtkjqMnQgec2jpmwScp6GS/9yXDIbhBE5+F
uSX0tg7VVkwHTdKvyG7J/NeqnobrrdTHw0oxFieg79gycy6Lvyk0mfDJ0NOfRXpn
QRWv5ItDecAcH/fPqjpMEk3pJj98diTnsH12vHmJyQJczKr9NNrC0Kcb6btYjr2Z
tymVcwy8Os7V4RZSon/f0CqBlhGF9/bRUhwoMKhRrI/ZVU2pzy7SYi2AsN7sAzU2
JCwvSQ4N9Zs3lh8aaQ1maS2IyxWkKUNPF6RqRLBzYAuSzvOMdo/LRIbdnE4pC5Ui
OObqTA4X4DscxYCZDfg/KdMFp14VW3tb6y7Zw61NCmbDFtaWTuFvssHN0DUFy1x8
997Oi22x9Vpetz4Q+TmrzkaR7uqo7xkAHkfrAy62ZPYJh3BenKK6gSAu3Wfr8jJV
yYkmGb2S86O4LH06rN9EVZS8XHCNT8QliPTvn/fSc3X2rggnZhX6gIoVa1V5/cNe
c9zJzr3k+UB5vGEPaFcpD5ImU+eQtoZ+5f0Q7TCqt47MhPB2ZJe5lKtIJzokp1se
b+d/znNVeTNMuYDvaRxI1g8CUBtAHIFw9EcLWWvSl/Zr77TqvT/8mbaG2CG4bZk7
SfXl209voktpFFwtg3Rg
=rX0+
-----END PGP SIGNATURE-----
Merge tag 'gpio-for-linus' of git://git.secretlab.ca/git/linux
Pull second round of GPIO changes from Grant Likely:
"This branch contains a few bug fixes that I missed the first time
around and updates to the gpio_desc series included in the first pull
request. This tag has been retagged to drop the 2 head commits
because the one of them caused a build failure."
* tag 'gpio-for-linus' of git://git.secretlab.ca/git/linux:
gpio/gpio-ich: fix ichx_gpio_check_available() return what callers expect
gpiolib: move comment to right function
gpiolib: use const parameters when possible
gpiolib: check descriptors validity before use
mostly little bugfixes.
Only "feature" is a new RAID10 layout which slightly
improves the number of sets of devices that can concurrently
fail, without data loss.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQIVAwUAUTPm+znsnt1WYoG5AQLLsw/+PMqr8roC4twgxTWV1NRbU8NtOcRi9Rj9
uvBS63uYAaLdi/D3UBKFYczmNCu9knuXbcp9SgFDxH7LlthQsWN/GYnif06pPo3w
9Agu5M8c062TJEG1vrnX6FhPO6pNgrWFr3h+CKkTiD3179i9DoQpP8LXQToeyMtI
YRMQf/zCkxYtDvWAP0iwsEWtw8cf+q9I/uGPhQ1L+DnZapXYdbtnqWBRz9q6mrDt
orcGrP41aZHvnOHUaTbwmaorCKkf/Ys4SMaGenrSFpnpQMypt7VgNuwHC59LxvJT
5eiFG/26zIsv7Wk0jv/TvFP5qzUPo0/PFkd5ug0ArvbVRiXS2cMJDwQvMdO1toxD
i5Bb+P9DptadvoWhOTgIpxnG77yRH45wJvyJOk+ZfS1/IO87nCRa3d0yiNOU5e2/
o0VdXPZRr72sdKKTK6kQuYfwCPb+Z2Pz6Q8BJdk6GxlmTXyP6sKhIgwUX86534fE
LrOxfK8qV+GetVu3X02RoX2CyJJRQHXyXmbHuSzXuo/JiOYtDigAydwNZChvf+tf
OoMY9K8vgNbhnGsUG6la7XPvZ+6dZMjdnxp2HB99Ml5A3PWZd75i5T6IHHxIQFbD
C3z9PWTWP+hK4k15DEyjlELtsE9WduGTXG4kUcf328xJ/7lj4VIImVugdCz+1B6z
+HlI6BiLwzY=
=YdVD
-----END PGP SIGNATURE-----
Merge tag 'md-3.9' of git://neil.brown.name/md
Pull md updates from NeilBrown:
"Mostly little bugfixes.
Only "feature" is a new RAID10 layout which slightly improves the
number of sets of devices that can concurrently fail, without data
loss."
* tag 'md-3.9' of git://neil.brown.name/md:
md: expedite metadata update when switching read-auto -> active
md: remove CONFIG_MULTICORE_RAID456
md/raid1,raid10: fix deadlock with freeze_array()
md/raid0: improve error message when converting RAID4-with-spares to RAID0
md: raid0: fix error return from create_stripe_zones.
md: fix two bugs when attempting to resize RAID0 array.
DM RAID: Add support for MD's RAID10 "far" and "offset" algorithms
MD RAID10: Improve redundancy for 'far' and 'offset' algorithms (part 2)
MD RAID10: Improve redundancy for 'far' and 'offset' algorithms (part 1)
MD RAID10: Minor non-functional code changes
md: raid1,10: Handle REQ_WRITE_SAME flag in write bios
md: protect against crash upon fsync on ro array
From the docs:
"IIR can queue up to two interrupt events. When the IIR is cleared,
it will set itself again after one clock if a second event was
stored."
"Only the rising edge of the PCH Display interrupt will cause the
North Display IIR (DEIIR) PCH Display Interrupt even bit to be set,
so all PCH Display Interrupts, including back to back interrupts,
must be cleared before a new PCH Display interrupt can cause DEIIR
to be set".
The current code works fine because we don't get many interrupts, but
if we enable the PCH FIFO underrun interrupts we'll start getting so
many interrupts that at some point new PCH interrupts won't cause
DEIIR to be set.
The initial implementation I tried was to turn the code that checks
SDEIIR into a loop, but we can still get interrupts even after the
loop is done (and before the irq handler finishes), so we have to
either disable the interrupts or mask them. In the end I concluded
that just disabling the PCH interrupts is enough, you don't even need
the loop, so this is what this patch implements. I've tested it and it
passes the 2 "PCH FIFO underrun interrupt storms" I can reproduce:
the "ironlake_crtc_disable" case and the "wrong watermarks" case.
In other words, here's how to reproduce the problem fixed by this
patch:
1 - Enable PCH FIFO underrun interrupts (SERR_INT on SNB+)
2 - Boot the machine
3 - While booting we'll get tons of PCH FIFO underrun interrupts
4 - Plug a new monitor
5 - Run xrandr, notice it won't detect the new monitor
6 - Read SDEIIR and notice it's not 0 while DEIIR is 0
Q: Can't we just clear DEIIR before SDEIIR?
A: It doesn't work. SDEIIR has to be completely cleared (including the
interrupts stored on its back queue) before it can flip DEIIR's bit to
1 again, and even while you're clearing it you'll be getting more and
more interrupts.
Q: Why does it work by just disabling+enabling the south interrupts?
A: Because when we re-enable them, if there's something on the SDEIIR
register (maybe an interrupt stored on the queue), the re-enabling
will make DEIIR's bit flip to 1, and since we'll already have
interrupts enabled we'll get another interrupt, then run our irq
handler again to process the "back" interrupts.
v2: Even bigger commit message, added code comments.
Note that this fixes missed dp aux irqs which have been reported for
3.9-rc1. This regression has been introduced by switching to
irq-driven dp aux transactions with
commit 9ee32fea5fe810ec06af3a15e4c65478de56d4f5
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Sat Dec 1 13:53:48 2012 +0100
drm/i915: irq-drive the dp aux communication
References: http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg18588.html
References: https://lkml.org/lkml/2013/2/26/769
Tested-by: Imre Deak <imre.deak@intel.com>
Reported-by: Sedat Dilek <sedat.dilek@gmail.com>
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Pimp commit message with references for the dp aux irq
timeout regression this fixes.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch fixes a lockdep warning in igb_get_i2c_client by
refactoring the initialization and usage of the i2c_client
completely. There is no on the fly allocation of the single
client needed today.
Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
We need it to restore the ilk rc6 context, since the gpu wait no
requires interrupts. But in general having interrupts around should
help in code sanity, since more and more stuff is interrupt driven.
This regression has been introduced in
commit 3e9605018ab3e333d51cc90fccfde2031886763b
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Tue Nov 27 16:22:54 2012 +0000
drm/i915: Rearrange code to only have a single method for waiting upon the ring
Like in the driver load code we need to make sure that hotplug
interrupts don't cause havoc with our modeset state, hence block them
with the existing infrastructure. Again we ignore races where we might
loose hotplug interrupts ...
Note that the driver load part of the regression has already been
fixed in
commit 52d7ecedac3f96fb562cb482c139015372728638
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Sat Dec 1 21:03:22 2012 +0100
drm/i915: reorder setup sequence to have irqs for output setup
v2: Add a note to the commit message about which patch fixed the
driver load part of the regression. Stable kernels need to backport
both patches.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=54691
Cc: stable@vger.kernel.org (for 3.8 only, plese backport
52d7ecedac3f96fb5 first)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reported-and-Tested-by: Ilya Tumaykin <itumaykin@gmail.com>
Reviewed-by: Chris wilson <chris@chris-wilson.co.uk> (v1)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch changes the setup copper link function to use a switch
statement for the PHY id's available for the given PHY types. It
also adds a case for the I210 PHY id, so the appropriate setup link
function is called for it.
Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
On s390 the igb driver was throwing a build error due to the fact that a frame
built using build_skb would be larger than 2K. Since this is not likely to
change at any point in the future we are better off just dropping the check
since we already had a check in igb_set_rx_buffer_len that will just disable
the usage of build_skb anyway.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
This increases GEN6_RC6p_THRESHOLD from 100000 to 150000. For some
reason this avoids the gen6_gt_check_fifodbg.isra warnings and
associated GPU lockups, which makes my ivy bridge machine stable.
Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
At 1000Mbps link speed, one of the MAC's internal clocks can be stopped for
up to 4us when entering K1 (a power mode of the MAC-PHY interconnect). If
the MAC is waiting for completion indications for 2 DMA write requests into
Host memory (e.g. descriptor writeback or Rx packet writing) and the
indications occur while the clock is stopped, both indications will be
missed by the MAC causing the MAC to wait for the completion indications
and be unable to generate further DMA write requests. This results in an
apparent hardware hang.
Work-around the issue by disabling the de-assertion of the clock request
when 1000Mbps link is acquired (K1 must be disabled while doing this).
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
when strlen pi->location_code is larger than HVCS_CLC_LENGTH + 1,
original implementation can not let hvcsd->p_location_code NUL terminated.
so need fix it (also can simplify the code)
Signed-off-by: Chen Gang <gang.chen@asianux.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
