* refs/heads/tmp-d8cb916:
Linux 4.14.161
perf probe: Fix to show function entry line as probe-able
nbd: fix shutdown and recv work deadlock v2
mmc: sdhci-of-esdhc: fix P2020 errata handling
mmc: sdhci: Update the tuning failed messages to pr_debug level
mmc: sdhci-of-esdhc: Revert "mmc: sdhci-of-esdhc: add erratum A-009204 support"
powerpc/irq: fix stack overflow verification
x86/MCE/AMD: Allow Reserved types to be overwritten in smca_banks[]
x86/MCE/AMD: Do not use rdmsr_safe_on_cpu() in smca_configure()
KVM: arm64: Ensure 'params' is initialised when looking up sys register
ext4: unlock on error in ext4_expand_extra_isize()
ext4: check for directory entries too close to block end
ext4: fix ext4_empty_dir() for directories with holes
staging: comedi: gsc_hpdi: check dma_alloc_coherent() return value
platform/x86: hp-wmi: Make buffer for HPWMI_FEATURE2_QUERY 128 bytes
intel_th: pci: Add Elkhart Lake SOC support
intel_th: pci: Add Comet Lake PCH-V support
USB: EHCI: Do not return -EPIPE when hub is disconnected
usbip: Fix error path of vhci_recv_ret_submit()
usbip: Fix receive error in vhci-hcd when using scatter-gather
btrfs: abort transaction after failed inode updates in create_subvol
btrfs: return error pointer from alloc_test_extent_buffer
s390/ftrace: fix endless recursion in function_graph tracer
usb: xhci: Fix build warning seen with CONFIG_PM=n
mmc: mediatek: fix CMD_TA to 2 for MT8173 HS200/HS400 mode
Revert "mmc: sdhci: Fix incorrect switch to HS mode"
btrfs: don't prematurely free work in scrub_missing_raid56_worker()
btrfs: don't prematurely free work in reada_start_machine_worker()
net: phy: initialise phydev speed and duplex sanely
mips: fix build when "48 bits virtual memory" is enabled
libtraceevent: Fix memory leakage in copy_filter_type
crypto: vmx - Avoid weird build failures
mac80211: consider QoS Null frames for STA_NULLFUNC_ACKED
crypto: sun4i-ss - Fix 64-bit size_t warnings on sun4i-ss-hash.c
crypto: sun4i-ss - Fix 64-bit size_t warnings
fbtft: Make sure string is NULL terminated
iwlwifi: check kasprintf() return value
x86/insn: Add some Intel instructions to the opcode map
spi: st-ssc4: add missed pm_runtime_disable
btrfs: don't prematurely free work in run_ordered_work()
btrfs: don't prematurely free work in end_workqueue_fn()
mmc: tmio: Add MMC_CAP_ERASE to allow erase/discard/trim requests
crypto: virtio - deal with unsupported input sizes
spi: tegra20-slink: add missed clk_unprepare
iwlwifi: mvm: fix unaligned read of rx_pkt_status
x86/crash: Add a forward declaration of struct kimage
cpufreq: Register drivers only after CPU devices have been registered
parport: load lowlevel driver if ports not found
s390/disassembler: don't hide instruction addresses
ASoC: Intel: kbl_rt5663_rt5514_max98927: Add dmic format constraint
ASoC: rt5677: Mark reg RT5677_PWR_ANLG2 as volatile
spi: pxa2xx: Add missed security checks
EDAC/ghes: Fix grain calculation
media: si470x-i2c: add missed operations in remove
media: pvrusb2: Fix oops on tear-down when radio support is not present
fsi: core: Fix small accesses and unaligned offsets via sysfs
ath10k: fix get invalid tx rate for Mesh metric
perf probe: Filter out instances except for inlined subroutine and subprogram
perf probe: Skip end-of-sequence and non statement lines
perf probe: Fix to show calling lines of inlined functions
perf probe: Return a better scope DIE if there is no best scope
perf probe: Skip overlapped location on searching variables
perf parse: If pmu configuration fails free terms
drm/amdgpu: fix potential double drop fence reference
perf probe: Fix to probe a function which has no entry pc
libsubcmd: Use -O0 with DEBUG=1
perf probe: Fix to show inlined function callsite without entry_pc
perf probe: Fix to show ranges of variables in functions without entry_pc
perf probe: Fix to probe an inline function which has no entry pc
perf probe: Walk function lines in lexical blocks
perf probe: Fix to list probe event with correct line number
perf probe: Fix to find range-only function instance
rtlwifi: fix memory leak in rtl92c_set_fw_rsvdpagepkt()
ALSA: timer: Limit max amount of slave instances
spi: img-spfi: fix potential double release
bnx2x: Fix PF-VF communication over multi-cos queues.
rfkill: allocate static minor
media: v4l2-core: fix touch support in v4l_g_fmt
media: rcar_drif: fix a memory disclosure
ixgbe: protect TX timestamping from API misuse
pinctrl: amd: fix __iomem annotation in amd_gpio_irq_handler()
Bluetooth: Fix advertising duplicated flags
iio: dln2-adc: fix iio_triggered_buffer_postenable() position
pinctrl: sh-pfc: sh7734: Fix duplicate TCLK1_B
loop: fix no-unmap write-zeroes request behavior
libata: Ensure ata_port probe has completed before detach
s390/mm: add mm_pxd_folded() checks to pxd_free()
s390/time: ensure get_clock_monotonic() returns monotonic values
phy: qcom-usb-hs: Fix extcon double register after power cycle
net: dsa: LAN9303: select REGMAP when LAN9303 enable
gpu: host1x: Allocate gather copy for host1x
RDMA/qedr: Fix memory leak in user qp and mr
net: phy: dp83867: enable robust auto-mdix
arm64: psci: Reduce the waiting time for cpu_psci_cpu_kill()
x86/ioapic: Prevent inconsistent state when moving an interrupt
rtl8xxxu: fix RTL8723BU connection failure issue after warm reboot
drm/gma500: fix memory disclosures due to uninitialized bytes
x86/mce: Lower throttling MCE messages' priority to warning
Bluetooth: hci_core: fix init for HCI_USER_CHANNEL
Bluetooth: missed cpu_to_le16 conversion in hci_init4_req
iio: adc: max1027: Reset the device at probe time
usb: usbfs: Suppress problematic bind and unbind uevents.
perf report: Add warning when libunwind not compiled in
perf test: Report failure for mmap events
drm/bridge: dw-hdmi: Restore audio when setting a mode
x86/mm: Use the correct function type for native_set_fixmap()
extcon: sm5502: Reset registers during initialization
media: ti-vpe: vpe: fix a v4l2-compliance failure about invalid sizeimage
media: ti-vpe: vpe: ensure buffers are cleaned up properly in abort cases
media: ti-vpe: vpe: fix a v4l2-compliance failure causing a kernel panic
media: ti-vpe: vpe: Make sure YUYV is set as default format
media: ti-vpe: vpe: fix a v4l2-compliance failure about frame sequence number
media: ti-vpe: vpe: fix a v4l2-compliance warning about invalid pixel format
media: ti-vpe: vpe: Fix Motion Vector vpdma stride
media: cx88: Fix some error handling path in 'cx8800_initdev()'
mwifiex: pcie: Fix memory leak in mwifiex_pcie_init_evt_ring
block: Fix writeback throttling W=1 compiler warnings
samples: pktgen: fix proc_cmd command result check logic
drm/bridge: dw-hdmi: Refuse DDC/CI transfers on the internal I2C controller
media: cec-funcs.h: add status_req checks
media: flexcop-usb: fix NULL-ptr deref in flexcop_usb_transfer_init()
regulator: max8907: Fix the usage of uninitialized variable in max8907_regulator_probe()
hwrng: omap3-rom - Call clk_disable_unprepare() on exit only if not idled
usb: renesas_usbhs: add suspend event support in gadget mode
selftests/bpf: Correct path to include msg + path
pinctrl: devicetree: Avoid taking direct reference to device name string
ath10k: fix offchannel tx failure when no ath10k_mac_tx_frm_has_freq
media: venus: core: Fix msm8996 frequency table
tools/power/cpupower: Fix initializer override in hsw_ext_cstates
media: ov6650: Fix stored crop rectangle not in sync with hardware
media: ov6650: Fix stored frame format not in sync with hardware
media: i2c: ov2659: Fix missing 720p register config
media: ov6650: Fix crop rectangle alignment not passed back
media: i2c: ov2659: fix s_stream return value
media: am437x-vpfe: Setting STD to current value is not an error
IB/iser: bound protection_sg size by data_sg size
libertas: fix a potential NULL pointer dereference
rtlwifi: prevent memory leak in rtl_usb_probe
staging: rtl8188eu: fix possible null dereference
staging: rtl8192u: fix multiple memory leaks on error path
spi: Add call to spi_slave_abort() function when spidev driver is released
iio: light: bh1750: Resolve compiler warning and make code more readable
drm/bridge: analogix-anx78xx: silence -EPROBE_DEFER warnings
drm: mst: Fix query_payload ack reply struct
ALSA: hda/ca0132 - Avoid endless loop
ALSA: hda/ca0132 - Keep power on during processing DSP response
ALSA: pcm: Avoid possible info leaks from PCM stream buffers
Btrfs: fix removal logic of the tree mod log that leads to use-after-free issues
btrfs: handle ENOENT in btrfs_uuid_tree_iterate
btrfs: do not leak reloc root if we fail to read the fs root
btrfs: skip log replay on orphaned roots
btrfs: do not call synchronize_srcu() in inode_tree_del
btrfs: don't double lock the subvol_sem for rename exchange
sctp: fully initialize v4 addr in some functions
qede: Fix multicast mac configuration
net: usb: lan78xx: Fix suspend/resume PHY register access error
net: qlogic: Fix error paths in ql_alloc_large_buffers()
net: nfc: nci: fix a possible sleep-in-atomic-context bug in nci_uart_tty_receive()
net: hisilicon: Fix a BUG trigered by wrong bytes_compl
net: dst: Force 4-byte alignment of dst_metrics
mod_devicetable: fix PHY module format
fjes: fix missed check in fjes_acpi_add
af_packet: set defaule value for tmo
ANDROID: cuttlefish_defconfig: Disable TRANSPARENT_HUGEPAGE
Conflicts:
arch/arm64/kernel/psci.c
Change-Id: I989024129dbc7ce44af19108621958bfdd2fe6ef
Signed-off-by: Srinivasarao P <spathi@codeaurora.org>
Signed-off-by: Blagovest Kolenichev <bkolenichev@codeaurora.org>
commit 64cc3f12d1c7dd054a215bc1ff9cc2abcfe35832 upstream.
When disconnecting a USB hub that has some child device(s) connected to it
(such as a USB mouse), then the stack tries to clear halt and
reset device(s) which are _already_ physically disconnected.
The issue has been reproduced with:
CPU: IMX6D5EYM10AD or MCIMX6D5EYM10AE.
SW: U-Boot 2019.07 and kernel 4.19.40.
CPU: HP Proliant Microserver Gen8.
SW: Linux version 4.2.3-300.fc23.x86_64
In this situation there will be error bit for MMF active yet the
CERR equals EHCI_TUNE_CERR + halt. Existing implementation
interprets this as a stall [1] (chapter 8.4.5).
The possible conditions when the MMF will be active + halt
can be found from [2] (Table 4-13).
Fix for the issue is to check whether MMF is active and PID Code is
IN before checking for the stall. If these conditions are true then
it is not a stall.
What happens after the fix is that when disconnecting a hub with
attached device(s) the situation is not interpret as a stall.
[1] [https://www.usb.org/document-library/usb-20-specification, usb_20.pdf]
[2] [https://www.intel.com/content/dam/www/public/us/en/documents/
technical-specifications/ehci-specification-for-usb.pdf]
Signed-off-by: Erkka Talvitie <erkka.talvitie@vincit.fi>
Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/ef70941d5f349767f19c0ed26b0dd9eed8ad81bb.1576050523.git.erkka.talvitie@vincit.fi
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Format specifier %p can leak kernel addresses while not valuing the
kptr_restrict system settings. When kptr_restrict is set to (1), kernel
pointers printed using the %pK format specifier will be replaced with 0's.
Debugging Note : &pK prints only Zeros as address. If you need actual
address information, write zero to kptr_restrict.
echo 0 > /proc/sys/kernel/kptr_restrict
Change-Id: Ib2b999693224b33241141e290b70724f9e27183f
Signed-off-by: Vamsi Krishna Samavedam <vskrishn@codeaurora.org>
Now that usb_endpoint_maxp() only returns the lowest
11 bits from wMaxPacketSize, we can remove this macro
from the driver.
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: <linux-usb@vger.kernel.org>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
We have introduced a helper to calculate multiplier
value from wMaxPacketSize. Start using it.
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: <linux-usb@vger.kernel.org>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
unlink_empty_async_suspended() is marked __maybe_unused. This is
because its caller, ehci_bus_suspend(), is protected by "#ifdef
CONFIG_PM". We should use the same protection here instead of
__maybe_unused.
unlink_empty_async_suspended() gets called only when the root hub is
suspended. It's silly for it to call start_iaa_cycle() at such a
time; the IAA mechanism doesn't work when the root hub isn't running.
It should call end_unlink_async() instead. But even this isn't
necessary, since there already is a call to end_iaa_cycle() right
before the call to unlink_empty_async_suspended(). All we have to do
is interchange the two subroutine calls.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael Reutman reports that an AMD/ATI EHCI host controller on one of
his computers does not stop transferring data when an active bulk QH
is unlinked from the async schedule. Apparently that host controller
fails to implement the IAA mechanism correctly when an active QH is
unlinked. This leads to data corruption, because the controller
continues to update the QH in memory when the driver doesn't expect
it. As a result, the next URB submitted for that QH can hang, because
the link pointers for the TD queue have been messed up. This
misbehavior is observed quite regularly.
To be fair, the EHCI spec (section 4.8.2) says that active QHs should
not be unlinked. It goes on to recommend a procedure that involves
waiting for the QH to go inactive before unlinking it. In the real
world this is impractical, not least because the QH may _never_ go
inactive. (What were they thinking?) Sometimes we have no choice but
to unlink an active QH.
In an attempt to avoid the problems that can ensue, this patch changes
how the driver decides when the unlink is complete. In addition to
waiting through two IAA cycles, in cases where the QH was not known to
be inactive beforehand we now wait until a 2-ms period has elapsed
with the host controller making no change to the QH data structure
(the hw_current and hw_token fields in particular). The intuition
here is that after such a long period, the endpoint must be NAKing and
hopefully the QH has been dropped from the host controller's internal
cache. There's no way to know if this reasoning is really valid --
the spec is no help in this regard -- but at least this approach fixes
Michael's problem.
The test for whether the QH is already known to be inactive involves
the reason for unlinking the QH originally. If it was unlinked
because it had halted, or it stopped in response to a short read, or
it overlaid a dummy TD (a silicon bug), then it certainly is inactive.
If it was unlinked because the TD queue was empty and no TDs have been
added to the queue in the meantime, then it must be inactive. Or if
the hardware status indicates that the QH is currently halted (even if
that wasn't the reason for unlinking it), then it is inactive.
Otherwise, if none of those checks apply, we go through the 2-ms
delay.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Michael Reutman <mreutman@epiqsolutions.com>
Tested-by: Michael Reutman <mreutman@epiqsolutions.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch improves the way ehci-hcd handles the iaa_in_progress flag.
The current code is somewhat careless in this regard:
The flag is meaningless when the root hub isn't running, most
particularly after the root hub has been suspended. But in
start_iaa_cycle(), the driver checks the flag before checking
the root hub's state. They should be checked in the opposite
order.
That routine also sets the flag too early, before it has
definitely committed to starting an IAA cycle.
The flag is turned off in end_unlink_async(). Upcoming
changes will call that routine at other times, not just at the
end of an IAA cycle. The two actions are logically separate
(although related), so we separate out a new routine to be
called in place of end_unlink_async() whenever an IAA cycle
ends: end_iaa_cycle().
iaa_in_progress should be turned off when the root hub is
suspended -- we certainly don't want it still to be set when
the root hub resumes. Therefore the call to
end_unlink_async() in ehci_bus_suspend() should also be
replaced with a call to end_iaa_cycle().
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch replaces the "exception" bitflag in the ehci_qh structure
with a more explicit "unlink_reason" bitmask. This is for use in the
following patch, where we will need to have a good idea of the
reason for unlinking a QH, not just "something exceptional happened".
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Michael Reutman <mreutman@epiqsolutions.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch adds a new warning message to ehci-hcd. The warning is
triggered whenever the driver finds that the hardware has set the
Active bit in a QH at a time when the driver expects the QH to be
completely idle. Such bugs have been observed by users in the past,
and since they can lead to serious problems (such as inability to
unlink an URB that never completes), it would be good to know about
them when they occur.
This won't fix these bugs; that's a bigger job for a later patch. But
success isn't guaranteed, since this depends on aspects of the
hardware which are not documented in the EHCI spec or for which the
spec's recommendations are clearly unworkable. It therefore seems
worthwhile to check for these bugs proactively.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Michael Reutman <mreutman@epiqsolutions.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In the drivers that no longer need it, it is removed.
It is removed from the Makefile. Drivers not fully converted
to dynamic debug have it shifted down into the individual
drivers.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch significantly changes the scheduling code in ehci-hcd.
Instead of calculating the current bandwidth utilization by trudging
through the schedule and adding up the times used by the existing
transfers, we will now maintain a table holding the time used for each
of 64 microframes. This will drastically speed up the bandwidth
computations.
In addition, it eliminates a theoretical bug. An isochronous endpoint
may have bandwidth reserved even at times when it has no transfers
listed in the schedule. The table will keep track of the reserved
bandwidth, whereas adding up entries in the schedule would miss it.
As a corollary, we can keep bandwidth reserved for endpoints even
when they aren't in active use. Eventually the bandwidth will be
reserved when a new alternate setting is installed; for now the
endpoint's reservation takes place when its first URB is submitted.
A drawback of this approach is that transfers with an interval larger
than 64 microframes will have to be charged for bandwidth as though
the interval was 64. In practice this shouldn't matter much;
transfers with longer intervals tend to be rather short anyway (things
like hubs or HID devices).
Another minor drawback is that we will keep track of two different
period and phase values: the actual ones and the ones used for
bandwidth allocation (which are limited to 64). This adds only a
small amount of overhead: 3 bytes for each endpoint.
The patch also adds a new debugfs file named "bandwidth" to display
the information stored in the new table.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch begins the process of unifying the scheduling parameters
that ehci-hcd uses for interrupt and isochronous transfers. It
creates an ehci_per_sched structure, which will be stored in both
ehci_qh and ehci_iso_stream structures, and will contain the common
scheduling information needed for both.
Initially we merely create the new structure and move some existing
fields into it. Later patches will add more fields and utilize these
structures in improved scheduling algorithms.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This reverts commit 3b8d7321ed4b8511e17048303b806ffcc2806077, which
brings back commit 428aac8a81058e2303677a8fbf26670229e51d3a as it should
be working for the 3.13-rc1 merge window now that Alan's other fixes are
here in the tree already.
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This reverts commit 428aac8a81058e2303677a8fbf26670229e51d3a.
This isn't quite ready for 3.12, we need some more EHCI driver changes
that are just now showing up. So revert this for now, and queue it up
later for 3.13.
Reported-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The debugging code for ehci is enabled to run if the DEBUG flag is defined.
This patch enables the debugging code also when the kernel is configured
with dynamic debugging on.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch removes ehci_vdbg debugging statements from EHCI host controller
driver because they produce too much information, lowering the signal to noise
ratio when debugging, and because they are not used anymore.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9841f37a1c ("usb: ehci: Add support for SINGLE_STEP_SET_FEATURE
test of EHSET") added additional code to the EHCI hub driver but it is
anticipated to only have a limited audience (e.g. embedded silicon
vendors and integrators). Avoid subjecting all EHCI (and in the future
maybe xHCI/OHCI, etc.) HCD users to code bloat by conditionally
compiling the EHSET-specific additions with a new Kconfig option,
CONFIG_USB_HCD_TEST_MODE.
Signed-off-by: Jack Pham <jackp@codeaurora.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The USB Embedded High-speed Host Electrical Test (EHSET) defines the
SINGLE_STEP_SET_FEATURE test as follows:
1) The host enumerates the test device with VID:0x1A0A, PID:0x0108
2) The host sends the SETUP stage of a GetDescriptor(Device)
3) The device ACKs the request
4) The host issues SOFs for 15 seconds allowing the test operator to
raise the scope trigger just above the SOF voltage level
5) The host sends the IN packet
6) The device sends data in response, triggering the scope
7) The host sends an ACK in response to the data
This patch adds additional handling to the EHCI hub driver and allows
the EHSET driver to initiate this test mode by issuing a a SetFeature
request to the root hub with a Test Selector value of 0x06. From there
it mimics ehci_urb_enqueue() but separately submits QTDs for the
SETUP and DATA/STATUS stages in order to insert a delay in between.
Signed-off-by: Manu Gautam <mgautam@codeaurora.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
[jackp@codeaurora.org: imported from commit c2084930 on codeaurora.org;
minor cleanup and updated author email]
Signed-off-by: Jack Pham <jackp@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
All 4 transfer types can work well on EHCI HCD after switching to run
URB giveback in tasklet context, so mark all HCD drivers to support
it.
Also we don't need to release ehci->lock during URB giveback any more.
>From below test results on 3 machines(2 ARM and one x86), time
consumed by EHCI interrupt handler droped much without performance
loss.
1 test description
1.1 mass storage performance test:
- run below command 10 times and compute the average performance
dd if=/dev/sdN iflag=direct of=/dev/null bs=200M count=1
- two usb mass storage device:
A: sandisk extreme USB 3.0 16G(used in test case 1 & case 2)
B: kingston DataTraveler G2 4GB(only used in test case 2)
1.2 uvc function test:
- run one simple capture program in the below link
http://kernel.ubuntu.com/~ming/up/capture.c
- capture format 640*480 and results in High Bandwidth mode on the
uvc device: Z-Star 0x0ac8/0x3450
- on T410(x86) laptop, also use guvcview to watch video capture/playback
1.3 about test2 and test4
- both two devices involved are tested concurrently by above test items
1.4 how to compute irq time(the time consumed by ehci_irq)
- use trace points of irq:irq_handler_entry and irq:irq_handler_exit
1.5 kernel
3.10.0-rc3-next-20130528
1.6 test machines
Pandaboard A1: ARM CortexA9 dural core
Arndale board: ARM CortexA15 dural core
T410: i5 CPU 2.67GHz quad core
2 test result
2.1 test case1: single mass storage device performance test
--------------------------------------------------------------------
upstream | patched
perf(MB/s)+irq time(us) | perf(MB/s)+irq time(us)
--------------------------------------------------------------------
Pandaboard A1: 25.280(avg:145,max:772) | 25.540(avg:14, max:75)
Arndale board: 29.700(avg:33, max:129) | 29.700(avg:10, max:50)
T410: 34.430(avg:17, max:154*)| 34.660(avg:12, max:155)
---------------------------------------------------------------------
2.2 test case2: two mass storage devices' performance test
--------------------------------------------------------------------
upstream | patched
perf(MB/s)+irq time(us) | perf(MB/s)+irq time(us)
--------------------------------------------------------------------
Pandaboard A1: 15.840/15.580(avg:158,max:1216) | 16.500/16.160(avg:15,max:139)
Arndale board: 17.370/16.220(avg:33 max:234) | 17.480/16.200(avg:11, max:91)
T410: 21.180/19.820(avg:18 max:160) | 21.220/19.880(avg:11, max:149)
---------------------------------------------------------------------
2.3 test case3: one uvc streaming test
- uvc device works well(on x86, luvcview can be used too and has
same result with uvc capture)
--------------------------------------------------------------------
upstream | patched
irq time(us) | irq time(us)
--------------------------------------------------------------------
Pandaboard A1: (avg:445, max:873) | (avg:33, max:44)
Arndale board: (avg:316, max:630) | (avg:20, max:27)
T410: (avg:39, max:107) | (avg:10, max:65)
---------------------------------------------------------------------
2.4 test case4: one uvc streaming plus one mass storage device test
--------------------------------------------------------------------
upstream | patched
perf(MB/s)+irq time(us) | perf(MB/s)+irq time(us)
--------------------------------------------------------------------
Pandaboard A1: 20.340(avg:259,max:1704)| 20.390(avg:24, max:101)
Arndale board: 23.460(avg:124,max:726) | 23.370(avg:15, max:52)
T410: 28.520(avg:27, max:169) | 28.630(avg:13, max:160)
---------------------------------------------------------------------
2.5 test case5: read single mass storage device with small transfer
- run below command 10 times and compute the average speed
dd if=/dev/sdN iflag=direct of=/dev/null bs=4K count=4000
1), test device A:
--------------------------------------------------------------------
upstream | patched
perf(MB/s)+irq time(us) | perf(MB/s)+irq time(us)
--------------------------------------------------------------------
Pandaboard A1: 6.5(avg:21, max:64) | 6.5(avg:10, max:24)
Arndale board: 8.13(avg:12, max:23) | 8.06(avg:7, max:17)
T410: 6.66(avg:13, max:131) | 6.84(avg:11, max:149)
---------------------------------------------------------------------
2), test device B:
--------------------------------------------------------------------
upstream | patched
perf(MB/s)+irq time(us) | perf(MB/s)+irq time(us)
--------------------------------------------------------------------
Pandaboard A1: 5.5(avg:21,max:43) | 5.49(avg:10, max:24)
Arndale board: 5.9(avg:12, max:22) | 5.9(avg:7, max:17)
T410: 5.48(avg:13, max:155) | 5.48(avg:7, max:140)
---------------------------------------------------------------------
* On T410, sometimes read ehci status register in ehci_irq takes more
than 100us, and the problem has been reported on the link:
http://marc.info/?t=137065867300001&r=1&w=2
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Patch 4d053fdac3 "usb: ehci: unlink_empty_async_suspended() only used
with CONFIG_PM" tried to hide the unlink_empty_async_suspended function
inside of an #ifdef to work around an unused function warning.
Unfortunately that had the effect of introducing a new warning:
drivers/usb/host/ehci-q.c:1297:13: warning: 'unlink_empty_async_suspended'
declared 'static' but never defined [-Wunused-function]
While we could add another #ifdef around the function declaration to avoid
this, a nicer solution is to mark it as __maybe_unused, which will let
gcc silently drop the function definition when it is not needed.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Compiling with !CONFIG_PM generates an unused function warning on
unlink_empty_async_suspended().
Enclose the function in a #ifdef CONFIG_PM
Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1669) removes the check_unlinks_later flag in ehci-hcd's
unlink_empty_async(). It wasn't being used for anything and should
have been removed in an earlier patch, but I forgot about it.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1665) changes the way ehci-hcd's end_unlink_async()
routine works in order to avoid recursive execution and to be more
efficient:
Now when an IAA cycle ends, a new one gets started up right
away (if it is needed) instead of waiting until the
just-unlinked QH has been processed.
The async_iaa list is renamed to async_idle, which better
expresses its new purpose: It is now the list of QHs which are
now completely idle and are waiting to be processed by
end_unlink_async().
A new flag is added to track whether an IAA cycle is in
progress, because the list formerly known as async_iaa no
longer stores the QHs waiting for the IAA to finish.
The decision about how many QHs to process when an IAA cycle
ends is now made at the end of the cycle, when we know the
current state of the hardware, rather than at the beginning.
This means a bunch of logic got moved from start_iaa_cycle()
to end_unlink_async().
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1664) converts ehci-hcd's async_unlink, async_iaa, and
intr_unlink from singly-linked lists to standard doubly-linked
list_heads. Originally it didn't seem necessary to use list_heads,
because items are always added to and removed from these lists in FIFO
order. But now with more list processing going on, it's easier to use
the standard routines than continue with a roll-your-own approach.
I don't know if the code ends up being notably shorter, but the
patterns will be more familiar to any kernel hacker.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1662) does some more QH-related cleanup in ehci-hcd.
The qh->needs_rescan flag is currently used for two different
purposes; the patch replaces it with two separate flags for greater
clarity: qh->dequeue_during_giveback indicates that a completion
handler dequeued an URB (implying that a rescan is needed), and
qh->exception indicates that the QH is in an exceptional state
requiring an unlink (either it encountered an I/O error or an unlink
was requested).
The new flags get set where the dequeue, exception, or unlink request
occurred, rather than where the unlink is started. This is so that in
the future, if we need to, we will be able to tell apart unlinks that
truly were required from those that were carried out merely because
the QH wasn't being used.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1658) cleans up the usage of qh_completions() in
ehci-hcd. Currently the function's return value indicates whether any
URBs were given back; the idea was that the caller can scan the QH
over again to handle any URBs that were dequeued by a completion
handler. This is not necessary; when qh_completions() is ready to
give back dequeued URBs, it does its own rescanning.
Therefore the new return value will be a flag indicating whether the
caller needs to unlink the QH. This is more convenient than forcing
the caller to check qh->needs_rescan, and it makes a lot more sense --
why should "needs_rescan" imply that an unlink is needed? The callers
are also changed to remove the unneeded rescans.
Lastly, the check for whether qh->qtd_list is non-empty is removed
from the start of qh_completions(). Two of the callers have to make
this test anyway, so the same test can simply be added to the other
two callers.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1638) makes several changes to the ehci-hcd driver, all
related to the qh_refresh() function. This function must be called
whenever an idle QH gets linked back into either the async or the
periodic schedule.
Change a BUG_ON() in the qh_update routine to a WARN_ON().
Since this code runs in atomic context, a BUG_ON() would
immediately freeze the whole system.
Remove two unneeded calls to qh_refresh(), one when a QH is
initialized and one when a QH becomes idle. Adjust the
adjacent comments accordingly.
Move the qh_refresh() and qh_link_periodic() calls for new
interrupt URBs to after the new TDs have been added.
As a result of the previous two changes, qh_refresh() is never
called when the qtd_list is empty. The corresponding check in
qh_refresh() can be removed, along with an indentation level.
These changes should not cause any alteration of behavior.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1663) fixes a regression caused by commit
6e0c3339a6f19d748f16091d0a05adeb1e1f822b (USB: EHCI: unlink one async
QH at a time). In order to avoid keeping multiple QHs in an unusable
intermediate state, that commit changed unlink_empty_async() so that
it unlinks only one empty QH at a time.
However, when the EHCI root hub is suspended, _all_ async QHs need to
be unlinked. ehci_bus_suspend() used to do this by calling
unlink_empty_async(), but now this only unlinks one of the QHs, not
all of them.
The symptom is that when the root hub is resumed, USB communications
don't work for some period of time. This is because ehci-hcd doesn't
realize it needs to restart the async schedule; it assumes that
because some QHs are already on the schedule, the schedule must be
running.
The easiest way to fix the problem is add a new function that unlinks
all the async QHs when the root hub is suspended.
This patch should be applied to all kernels that have the 6e0c3339a6f1
commit.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-and-tested-by: Adrian Bassett <adrian.bassett@hotmail.co.uk>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1661) fixes a rather obscure bug in ehci-hcd. In a
couple of places, the driver compares the DMA address stored in a QH's
overlay region with the address of a particular qTD, in order to see
whether that qTD is the one currently being processed by the hardware.
(If it is then the status in the QH's overlay region is more
up-to-date than the status in the qTD, and if it isn't then the
overlay's value needs to be adjusted when the QH is added back to the
active schedule.)
However, DMA address in the overlay region isn't always valid. It
sometimes will contain a stale value, which may happen by coincidence
to be equal to a qTD's DMA address. Instead of checking the DMA
address, we should check whether the overlay region is active and
valid. The patch tests the ACTIVE bit in the overlay, and clears this
bit when the overlay becomes invalid (which happens when the
currently-executing URB is unlinked).
This is the second part of a fix for the regression reported at:
https://bugs.launchpad.net/bugs/1088733
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Joseph Salisbury <joseph.salisbury@canonical.com>
Reported-and-tested-by: Stephen Thirlwall <sdt@dr.com>
CC: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1660) works around a hardware problem present in some
(if not all) Intel EHCI controllers. After a QH has been unlinked
from the async schedule and the corresponding IAA interrupt has
occurred, the controller is not supposed access the QH and its qTDs.
There certainly shouldn't be any more DMA writes to those structures.
Nevertheless, Intel's controllers have been observed to perform a
final writeback to the QH's overlay region and to the most recent qTD.
For more information and a test program to determine whether this
problem is present in a particular controller, see
http://marc.info/?l=linux-usb&m=135492071812265&w=2http://marc.info/?l=linux-usb&m=136182570800963&w=2
This patch works around the problem by always waiting for two IAA
cycles when unlinking an async QH. The extra IAA delay gives the
controller time to perform its final writeback.
Surprisingly enough, the effects of this silicon bug have gone
undetected until quite recently. More through luck than anything
else, it hasn't caused any apparent problems. However, it does
interact badly with the path that follows this one, so it needs to be
addressed.
This is the first part of a fix for the regression reported at:
https://bugs.launchpad.net/bugs/1088733
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Stephen Thirlwall <sdt@dr.com>
CC: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1648) fixes a regression affecting nVidia EHCI
controllers. Evidently they don't like to have more than one async QH
unlinked at a time. I can't imagine how they manage to mess it up,
but at least one of them does.
The patch changes the async unlink logic in two ways:
Each time an IAA cycle is started, only the first QH on the
async unlink list is handled (rather than all of them).
Async QHs do not all get unlinked as soon as they have been
empty for long enough. Instead, only the last one (i.e., the
one that has been on the schedule the longest) is unlinked,
and then only if no other unlinks are in progress at the time.
This means that when multiple QHs are empty, they won't be unlinked as
quickly as before. That's okay; it won't affect correct operation of
the driver or add an excessive load. Multiple unlinks tend to be
relatively rare in any case.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-and-tested-by: Piergiorgio Sartor <piergiorgio.sartor@nexgo.de>
Cc: stable <stable@vger.kernel.org> # 3.6
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1632b) fixes a bug in ehci-hcd. The USB core uses
urb->hcpriv to determine whether or not an URB is active; host
controller drivers are supposed to set this pointer to a non-NULL
value when an URB is queued. However ehci-hcd sets it to NULL for
isochronous URBs, which defeats the check in usbcore.
In itself this isn't a big deal. But people have recently found that
certain sequences of actions will cause the snd-usb-audio driver to
reuse URBs without waiting for them to complete. In the absence of
proper checking by usbcore, the URBs get added to their endpoint list
twice. This leads to list corruption and a system freeze.
The patch makes ehci-hcd assign a meaningful value to urb->hcpriv for
isochronous URBs. Improving robustness always helps.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Artem S. Tashkinov <t.artem@lycos.com>
Reported-by: Christof Meerwald <cmeerw@cmeerw.org>
CC: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There is a possibility of QH overlay region having reference to a stale
qTD pointer during unlink.
Consider an endpoint having two pending qTD before unlink process begins.
The endpoint's QH queue looks like this.
qTD1 --> qTD2 --> Dummy
To unlink qTD2, QH is removed from asynchronous list and Asynchronous
Advance Doorbell is programmed. The qTD1's next qTD pointer is set to
qTD2'2 next qTD pointer and qTD2 is retired upon controller's doorbell
interrupt. If QH's current qTD pointer points to qTD1, transfer overlay
region still have reference to qTD2. But qtD2 is just unlinked and freed.
This may cause EHCI system error. Fix this by updating qTD next pointer
in QH overlay region with the qTD next pointer of the current qTD.
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1586) replaces the kernel timer used by ehci-hcd as an
I/O watchdog with an hrtimer event.
Unlike in the current code, the watchdog event is now always enabled
whenever any isochronous URBs are active. This will prevent bugs
caused by the periodic schedule wrapping around with no completion
interrupts; the watchdog handler is guaranteed to scan the isochronous
transfers at least once during each iteration of the schedule. The
extra overhead will be negligible: one timer interrupt every 100 ms.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1585) fixes a bug in ehci-hcd's scheme for scanning
interrupt QHs.
Currently a single routine takes care of scanning everything on the
periodic schedule. Whenever an interrupt occurs, it scans all
isochronous and interrupt URBs scheduled for frames that have elapsed
since the last scan.
This has two disadvantages. The first is relatively minor: An
interrupt QH is likely to end up getting scanned multiple times,
particularly if the last scan was not fairly recent. (The current
code avoids this by maintaining a periodic_stamp in each interrupt
QH.)
The second is more serious. The periodic schedule wraps around. If
the last scan occurred during frame N, and the next scan occurs when
the schedule has gone through an entire cycle and is back at frame N,
the scanning code won't look at any frames other than N. Consequently
it won't see any QHs that completed during frame N-1 or earlier.
The patch replaces the entire frame-based approach for scanning
interrupt QHs with a new routine using a list-based approach, the same
as for async QHs. This has a slight disadvantage, because it means
that all interrupt QHs have to be scanned every time. But it is more
robust than the current approach.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1583) changes ehci-hcd to use an hrtimer event for
unlinking empty (unused) async QHs instead of using a kernel timer.
The check for empty QHs is moved to a new routine, where it doesn't
require going through an entire scan of both the async and periodic
schedules. And it can unlink multiple QHs at once, unlike the current
code.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1582) changes ehci-hcd's strategy for unlinking async
QHs. Currently the driver never unlinks more than one QH at a time.
This can be inefficient and cause unnecessary delays, since a QH
cannot be reused while it is waiting to be unlinked.
The new strategy unlinks all the waiting QHs at once. In practice the
improvement won't be very big, because it's somewhat uncommon to have
two or more QHs waiting to be unlinked at any time. But it does
happen, and in any case, doing things this way makes more sense IMO.
The change requires the async unlinking code to be refactored
slightly. Now in addition to the routines for starting and ending an
unlink, there are new routines for unlinking a single QH and starting
an IAA cycle. This approach is needed because there are two separate
paths for unlinking async QHs:
When a transfer error occurs or an URB is cancelled, the QH
must be unlinked right away;
When a QH has been idle sufficiently long, it is unlinked
to avoid consuming DMA bandwidth uselessly.
In the first case we want the unlink to proceed as quickly as
possible, whereas in the second case we can afford to batch several
QHs together and unlink them all at once. Hence the division of
labor.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1581) replaces the iaa_watchdog kernel timer used by
ehci-hcd with an hrtimer event, in keeping with the general conversion
to high-res timers.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1576) adds hrtimer support for managing ehci-hcd's
async schedule. Just as with the earlier change to the periodic
schedule management, two new hrtimer events take care of everything.
One event polls at 1-ms intervals to see when the Asynchronous
Schedule Status (ASS) flag matches the Asynchronous Schedule Enable
(ASE) value; the schedule's state must not be changed until it does.
The other event delays for 15 ms after the async schedule becomes
empty before turning it off.
The new events replace a busy-wait poll and a kernel timer usage.
They also replace the rather illogical method currently used for
indicating the async schedule should be turned off: attempting to
unlink the dedicated QH at the head of the async list.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1571) adds a new state for ehci-hcd's root hubs:
EHCI_RH_STOPPING. This value is used at times when the root hub is
being stopped and we don't know whether or not the hardware has
finished all its DMA yet.
Although the purpose may not be apparent, this distinction will come
in useful later on. Future patches will avoid actions that depend on
the root hub being operational (like turning on the async or periodic
schedules) when they see the state is EHCI_RH_STOPPING.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1570) adds a pointer for the end of ehci-hcd's
async-unlink list. The list (which is actually a queue) is singly
linked, so having a pointer to its end makes adding new entries easier
-- there's no longer any need to scan through the whole list.
In principle it could be changed to a standard doubly-linked list. It
turns out that doing so actually makes the code less clear, so I'm
leaving it as is.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1569) renames the ehci->reclaim list in ehci-hcd. The
word "reclaim" is used in the EHCI specification to mean something
quite different, and "unlink_next" is more descriptive of the list's
purpose anyway.
Similarly, the "reclaim" field in the ehci_stats structure is renamed
"iaa", which is more meaningful (to experts, anyway) and is a better
match for the "lost_iaa" field.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1568) introduces symbolic constants for some of the
less-frequently used bitfields in the QH structure. This makes the
code a little easier to read and understand.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1567) removes ehci-hcd's reference counting of QH
structures. It's not necessary to refcount these things because they
always get deallocated at exactly one spot in ehci_endpoint_disable()
(except for two special QHs, ehci->async and ehci->dummy) and are
never used again.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
dbg() was a very old USB-specific macro that should no longer
be used. This patch removes it from being used in the driver
and uses dev_dbg() instead.
CC: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The ehci-hcd driver is a little haphazard about keeping track of the
state of the USBCMD register. The ehci->command field is supposed to
hold the register's value (apart from a few special bits) at all
times, but it isn't maintained properly.
This patch (as1543) cleans up the situation. It keeps ehci->command
up-to-date, and uses that value rather than reading the register from
the hardware whenever possible.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add a new field num_mapped_sgs to struct urb so that we have a place to
store the number of mapped entries and can also retain the original
value of entries in num_sgs. Previously, usb_hcd_map_urb_for_dma()
would overwrite this with the number of mapped entries, which would
break dma_unmap_sg() because it requires the original number of entries.
This fixes warnings like the following when using USB storage devices:
------------[ cut here ]------------
WARNING: at lib/dma-debug.c:902 check_unmap+0x4e4/0x695()
ehci_hcd 0000:00:12.2: DMA-API: device driver frees DMA sg list with different entry count [map count=4] [unmap count=1]
Modules linked in: ohci_hcd ehci_hcd
Pid: 0, comm: kworker/0:1 Not tainted 3.2.0-rc2+ #319
Call Trace:
<IRQ> [<ffffffff81036d3b>] warn_slowpath_common+0x80/0x98
[<ffffffff81036de7>] warn_slowpath_fmt+0x41/0x43
[<ffffffff811fa5ae>] check_unmap+0x4e4/0x695
[<ffffffff8105e92c>] ? trace_hardirqs_off+0xd/0xf
[<ffffffff8147208b>] ? _raw_spin_unlock_irqrestore+0x33/0x50
[<ffffffff811fa84a>] debug_dma_unmap_sg+0xeb/0x117
[<ffffffff8137b02f>] usb_hcd_unmap_urb_for_dma+0x71/0x188
[<ffffffff8137b166>] unmap_urb_for_dma+0x20/0x22
[<ffffffff8137b1c5>] usb_hcd_giveback_urb+0x5d/0xc0
[<ffffffffa0000d02>] ehci_urb_done+0xf7/0x10c [ehci_hcd]
[<ffffffffa0001140>] qh_completions+0x429/0x4bd [ehci_hcd]
[<ffffffffa000340a>] ehci_work+0x95/0x9c0 [ehci_hcd]
...
---[ end trace f29ac88a5a48c580 ]---
Mapped at:
[<ffffffff811faac4>] debug_dma_map_sg+0x45/0x139
[<ffffffff8137bc0b>] usb_hcd_map_urb_for_dma+0x22e/0x478
[<ffffffff8137c494>] usb_hcd_submit_urb+0x63f/0x6fa
[<ffffffff8137d01c>] usb_submit_urb+0x2c7/0x2de
[<ffffffff8137dcd4>] usb_sg_wait+0x55/0x161
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Data Buffer Error as per spec section 4.15.1.1.2
results when there is Underrun or Overrun condition.
This error is considered non-fatal and never gets reported.
Its a very good indication on things going wrong at system level,
like running memory at much slower speed.
This is a good error to flag allowing system level corrections.
An issue was found with OMAP4460 board where DDR had to be run
at full speed and this logging helped.
Signed-off-by: Vikram Pandita <vikram.pandita@ti.com>
Reviewed-by: Marek Vasut <marek.vasut@gmail.com>
Signed-off-by: Vikram Pandita <vikram.pandita@ti.com>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
According to ehci spec 4.10.2, Advance Queue
If the fetched qTD has its Active bit set to a zero, the
host controller aborts the queue advance and follows the
queue head's horizontal pointer to the next schedule data
structure.
the 'qtd' will be linked into qh hardware queue after the line
below
*dummy = *qtd;
is executed and observed by EHCI HC, but EHCI HC won't have chance to
fetch the qtd descriptor pointed by 'qtd' in qh_append_tds until the
line below
dummy->hw_token = token; #set Active bit here
is executed by CPU and observed by EHCI HC.
There is already one 'wmb' to order writing to 'dummy'/'qtd' descriptors
and writing 'token' to 'dummy' descriptor(set Active bit), so the 1st
wmb is not needed and can be removed.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
