Skip to content

cloud-kernel
cloud-kernel

bug2833 / cloud-kernel
与 Fork 源项目一致

Fork自 openanolis / cloud-kernel

通知 1
Star 0
Fork 0
cloud-kernel
cloud-kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 15 1月, 2011 2 次提交
    • Z
      xhci: Do not run xhci_cleanup_msix with irq disabled · 40a9fb17
      由 Zhang Rui 提交于 
      when unloading xhci_hcd, I got:
[  134.856813] xhci_hcd 0000:02:00.0: remove, state 4
[  134.858140] usb usb3: USB disconnect, address 1
[  134.874956] xhci_hcd 0000:02:00.0: Host controller not halted, aborting reset.
[  134.876351] BUG: sleeping function called from invalid context at kernel/mutex.c:85
[  134.877657] in_atomic(): 0, irqs_disabled(): 1, pid: 1451, name: modprobe
[  134.878975] Pid: 1451, comm: modprobe Not tainted 2.6.37-rc5+ #162
[  134.880298] Call Trace:
[  134.881602]  [<ffffffff8104156a>] __might_sleep+0xeb/0xf0
[  134.882921]  [<ffffffff814763dc>] mutex_lock+0x24/0x50
[  134.884229]  [<ffffffff810a745c>] free_desc+0x2e/0x5f
[  134.885538]  [<ffffffff810a74c8>] irq_free_descs+0x3b/0x71
[  134.886853]  [<ffffffff8102584d>] free_irq_at+0x31/0x36
[  134.888167]  [<ffffffff8102723f>] destroy_irq+0x69/0x71
[  134.889486]  [<ffffffff8102747a>] native_teardown_msi_irq+0xe/0x10
[  134.890820]  [<ffffffff8124c382>] default_teardown_msi_irqs+0x57/0x80
[  134.892158]  [<ffffffff8124be46>] free_msi_irqs+0x8b/0xe9
[  134.893504]  [<ffffffff8124cd46>] pci_disable_msix+0x35/0x39
[  134.894844]  [<ffffffffa01b444a>] xhci_cleanup_msix+0x31/0x51 [xhci_hcd]
[  134.896186]  [<ffffffffa01b4b3a>] xhci_stop+0x3a/0x80 [xhci_hcd]
[  134.897521]  [<ffffffff81341dd4>] usb_remove_hcd+0xfd/0x14a
[  134.898859]  [<ffffffff813500ae>] usb_hcd_pci_remove+0x5c/0xc6
[  134.900193]  [<ffffffff8123c606>] pci_device_remove+0x3f/0x91
[  134.901535]  [<ffffffff812e7ea4>] __device_release_driver+0x83/0xd9
[  134.902899]  [<ffffffff812e8571>] driver_detach+0x86/0xad
[  134.904222]  [<ffffffff812e7d56>] bus_remove_driver+0xb2/0xd8
[  134.905540]  [<ffffffff812e8633>] driver_unregister+0x6c/0x74
[  134.906839]  [<ffffffff8123c8e4>] pci_unregister_driver+0x44/0x89
[  134.908121]  [<ffffffffa01b940e>] xhci_unregister_pci+0x15/0x17 [xhci_hcd]
[  134.909396]  [<ffffffffa01bd7d2>] xhci_hcd_cleanup+0xe/0x10 [xhci_hcd]
[  134.910652]  [<ffffffff8107fcd1>] sys_delete_module+0x1ca/0x23b
[  134.911882]  [<ffffffff81123932>] ? path_put+0x22/0x26
[  134.913104]  [<ffffffff8109a800>] ? audit_syscall_entry+0x2c/0x148
[  134.914333]  [<ffffffff8100ac82>] system_call_fastpath+0x16/0x1b
[  134.915658] xhci_hcd 0000:02:00.0: USB bus 3 deregistered
[  134.916465] xhci_hcd 0000:02:00.0: PCI INT A disabled

and the same issue when xhci_suspend is invoked.  (Note from Sarah: That's
fixed by Andiry's patch before this, by synchronizing the irqs rather than
freeing them on suspend.)

Do not run xhci_cleanup_msix with irq disabled.

This patch should be queued for the 2.6.37 stable tree.
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
      40a9fb17
    • A
      xHCI: synchronize irq in xhci_suspend() · 0029227f
      由 Andiry Xu 提交于 
      Synchronize the interrupts instead of free them in xhci_suspend(). This will
prevent a double free when the host is suspended and then the card removed.

Set the flag hcd->msix_enabled when using MSI-X, and check the flag in
suspend_common(). MSI-X synchronization will be handled by xhci_suspend(),
and MSI/INTx will be synchronized in suspend_common().

This patch should be queued for the 2.6.37 stable tree.
Reported-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
      0029227f
  3. 20 11月, 2010 1 次提交
    • P
      xhci: Fix reset-device and configure-endpoint commands · 7a3783ef
      由 Paul Zimmerman 提交于 
      We have been having problems with the USB-IF Gold Tree tests when plugging
and unplugging devices from the tree. I have seen that the reset-device
and configure-endpoint commands, which are invoked from
xhci_discover_or_reset_device() and xhci_configure_endpoint(), will sometimes
time out.

After much debugging, I determined that the commands themselves do not actually
time out, but rather their completion events do not get delivered to the right
place.

This happens when the command ring has just wrapped around, and it's enqueue
pointer is left pointing to the link TRB. xhci_discover_or_reset_device() and
xhci_configure_endpoint() use the enqueue pointer directly as their command
TRB pointer, without checking whether it's pointing to the link TRB.

When the completion event arrives, if the command TRB is pointing to the link
TRB, the check against the command ring dequeue pointer in
handle_cmd_in_cmd_wait_list() fails, so the completion inside the command does
not get signaled.

The patch below fixes the timeout problem for me.

This should be queued for the 2.6.35 and 2.6.36 stable trees.
Signed-off-by: NPaul Zimmerman <paulz@synopsys.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
      7a3783ef
  5. 16 11月, 2010 1 次提交
    • S
      xhci: Fix command ring replay after resume. · 89821320
      由 Sarah Sharp 提交于 
      Andiry's xHCI bus suspend patch introduced the possibly of a host
controller replaying old commands on the command ring, if the host
successfully restores the registers after a resume.

After a resume from suspend, the xHCI driver must restore the registers,
including the command ring pointer.  I had suggested that Andiry set the
command ring pointer to the current command ring dequeue pointer, so that
the driver wouldn't have to zero the command ring.

Unfortunately, setting the command ring pointer to the current dequeue
pointer won't work because the register assumes the pointer is 64-byte
aligned, and TRBs on the command ring are 16-byte aligned.  The lower
seven bits will always be masked off, leading to the written pointer being
up to 3 TRBs behind the intended pointer.

Here's a log excerpt.  On init, the xHCI driver places a vendor-specific
command on the command ring:

[  215.750958] xhci_hcd 0000:01:00.0: Vendor specific event TRB type = 48
[  215.750960] xhci_hcd 0000:01:00.0: NEC firmware version 30.25
[  215.750962] xhci_hcd 0000:01:00.0: Command ring deq = 0x3781e010 (DMA)

When we resume, the command ring dequeue pointer to be written should have
been 0x3781e010.  Instead, it's 0x3781e000:

[  235.557846] xhci_hcd 0000:01:00.0: // Setting command ring address to 0x3781e001
[  235.557848] xhci_hcd 0000:01:00.0: `MEM_WRITE_DWORD(3'b000, 64'hffffc900100bc038, 64'h3781e001, 4'hf);
[  235.557850] xhci_hcd 0000:01:00.0: `MEM_WRITE_DWORD(3'b000, 32'hffffc900100bc020, 32'h204, 4'hf);
[  235.557866] usb usb9: root hub lost power or was reset

(I can't see the results of this bug because the xHCI restore always fails
on this box, and the xHCI driver re-allocates everything.)

The fix is to zero the command ring and put the software and hardware
enqueue and dequeue pointer back to the beginning of the ring.  We do this
before the system suspends, to be paranoid and prevent the BIOS from
starting the host without clearing the command ring pointer, which might
cause the host to muck with stale memory.  (The pointer isn't required to
be in the suspend power well, but it could be.)  The command ring pointer
is set again after the host resumes.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: NAndiry Xu <andiry.xu@amd.com>
      89821320
  7. 12 11月, 2010 2 次提交
  9. 11 11月, 2010 1 次提交
  11. 23 10月, 2010 7 次提交
  13. 11 8月, 2010 7 次提交
  15. 27 7月, 2010 1 次提交
    • S
      USB: xhci: Set EP0 dequeue ptr after reset of configured device. · 2d1ee590
      由 Sarah Sharp 提交于 
      When a configured device is reset, the control endpoint's ring is reused.
If control transfers to the device were issued before the device is reset,
the dequeue pointer will be somewhere in the middle of the ring.  If the
device is then issued an address with the set address command, the xHCI
driver must provide a valid input context for control endpoint zero.

The original code would give the hardware the original input context,
which had a dequeue pointer set to the top of the ring.  This would cause
the host to re-execute any control transfers until it reached the ring's
enqueue pointer.  When issuing a set address command for a device that has
just been configured and then reset, use the control endpoint's enqueue
pointer as the hardware's dequeue pointer.

Assumption:  All control transfers will be completed or cancelled before
the set address command is issued to the device.  If there are any
outstanding control transfers, this code will not work.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      2d1ee590
  17. 05 6月, 2010 3 次提交
  19. 21 5月, 2010 6 次提交
    • S
      USB: xhci: Set stream ID to 0 after cleaning up stalls. · 5e5cf6fc
      由 Sarah Sharp 提交于 
      After using state stored in xhci_virt_ep to clean up a stalled endpoint,
be sure to set the stalled stream ID back to 0.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      5e5cf6fc
    • S
      USB: xhci: Avoid double free after streams are disabled. · 8a007748
      由 Sarah Sharp 提交于 
      When a device is disconnected, xhci_free_virt_device() is called.  Ramya
found that if the device had streams enabled, and then the driver freed
the streams with a call to usb_free_streams(), then about a minute after
he had called this, his machine crashed with a Bad DMA error.  It turns
out that xhci_free_virt_device() would attempt to free the endpoint's
stream_info data structure if it wasn't NULL, and the free streams
function was not setting it to NULL after freeing it.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: NRamya Desai <ramya.desai@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      8a007748
    • A
      USB: remove the usb_host_ss_ep_comp structure · 842f1690
      由 Alan Stern 提交于 
      This patch (as1375) eliminates the usb_host_ss_ep_comp structure used
for storing a dynamically-allocated copy of the SuperSpeed endpoint
companion descriptor.  The SuperSpeed descriptor is placed directly in
the usb_host_endpoint structure, alongside the standard endpoint
descriptor.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      842f1690
    • S
      USB: xhci: Correct assumptions about number of rings per endpoint. · e9df17eb
      由 Sarah Sharp 提交于 
      Much of the xHCI driver code assumes that endpoints only have one ring.
Now an endpoint can have one ring per enabled stream ID, so correct that
assumption.  Use functions that translate the stream_id field in the URB
or the DMA address of a TRB into the correct stream ring.

Correct the polling loop to print out all enabled stream rings.  Make the
URB cancellation routine find the correct stream ring if the URB has
stream_id set.  Make sure the URB enqueueing routine does the same.  Also
correct the code that handles stalled/halted endpoints.

Check that commands and registers that can take stream IDs handle them
properly.  That includes ringing an endpoint doorbell, resetting a
stalled/halted endpoint, and setting a transfer ring dequeue pointer
(since that command can set the dequeue pointer in a stream context or an
endpoint context).

Correct the transfer event handler to translate a TRB DMA address into the
stream ring it was enqueued to.  Make the code to allocate and prepare TD
structures adds the TD to the right td_list for the stream ring.  Make
sure the code to give the first TRB in a TD to the hardware manipulates
the correct stream ring.

When an endpoint stalls, store the stream ID of the stream ring that
stalled in the xhci_virt_ep structure.  Use that instead of the stream ID
in the URB, since an URB may be re-used after it is given back after a
non-control endpoint stall.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      e9df17eb
    • S
      USB: xhci: Add memory allocation for USB3 bulk streams. · 8df75f42
      由 Sarah Sharp 提交于 
      Add support for allocating streams for USB 3.0 bulk endpoints.  See
Documentation/usb/bulk-streams.txt for more information about how and why
you would use streams.

When an endpoint has streams enabled, instead of having one ring where all
transfers are enqueued to the hardware, it has several rings.  The ring
dequeue pointer in the endpoint context is changed to point to a "Stream
Context Array".  This is basically an array of pointers to transfer rings,
one for each stream ID that the driver wants to use.

The Stream Context Array size must be a power of two, and host controllers
can place a limit on the size of the array (4 to 2^16 entries).  These
two facts make calculating the size of the Stream Context Array and the
number of entries actually used by the driver a bit tricky.

Besides the Stream Context Array and rings for all the stream IDs, we need
one more data structure.  The xHCI hardware will not tell us which stream
ID a transfer event was for, but it will give us the slot ID, endpoint
index, and physical address for the TRB that caused the event.  For every
endpoint on a device, add a radix tree to map physical TRB addresses to
virtual segments within a stream ring.

Keep track of whether an endpoint is transitioning to using streams, and
don't enqueue any URBs while that's taking place.  Refuse to transition an
endpoint to streams if there are already URBs enqueued for that endpoint.

We need to make sure that freeing streams does not fail, since a driver's
disconnect() function may attempt to do this, and it cannot fail.
Pre-allocate the command structure used to issue the Configure Endpoint
command, and reserve space on the command ring for each stream endpoint.
This may be a bit overkill, but it is permissible for the driver to
allocate all streams in one call and free them in multiple calls.  (It is
not advised, however, since it is a waste of resources and time.)

Even with the memory and ring room pre-allocated, freeing streams can
still fail because the xHC rejects the configure endpoint command.  It is
valid (by the xHCI 0.96 spec) to return a "Bandwidth Error" or a "Resource
Error" for a configure endpoint command.  We should never see a Bandwidth
Error, since bulk endpoints do not effect the reserved bandwidth.  The
host controller can still return a Resource Error, but it's improbable
since the xHC would be going from a more resource-intensive configuration
(streams) to a less resource-intensive configuration (no streams).

If the xHC returns a Resource Error, the endpoint will be stuck with
streams and will be unusable for drivers.  It's an unavoidable consequence
of broken host controller hardware.

Includes bug fixes from the original patch, contributed by
John Youn <John.Youn@synopsys.com> and Andy Green <AGreen@PLXTech.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      8df75f42
    • S
      USB: xhci: Fix issue with set interface after stall. · 1624ae1c
      由 Sarah Sharp 提交于 
      When the USB core installs a new interface, it unconditionally clears the
halts on all the endpoints on the new interface.  Usually the xHCI host
needs to know when an endpoint is reset, so it can change its internal
endpoint state.  In this case, it doesn't care, because the endpoints were
never halted in the first place.

To avoid issuing a redundant Reset Endpoint command, the xHCI driver looks
at xhci_virt_ep->stopped_td to determine if the endpoint was actually
halted.  However, the functions that handle the stall never set that
variable to NULL after it dealt with the stall.  So if an endpoint stalled
and a Reset Endpoint command completed, and then the class driver tried to
install a new alternate setting, the xHCI driver would access the old
xhci_virt_ep->stopped_td pointer.  A similar problem occurs if the
endpoint has been stopped to cancel a transfer.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      1624ae1c
  21. 30 3月, 2010 1 次提交
    • T
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      由 Tejun Heo 提交于 
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h

percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files.  percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.

percpu.h -> slab.h dependency is about to be removed.  Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability.  As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.

  http://userweb.kernel.org/~tj/misc/slabh-sweep.py

The script does the followings.

* Scan files for gfp and slab usages and update includes such that
  only the necessary includes are there.  ie. if only gfp is used,
  gfp.h, if slab is used, slab.h.

* When the script inserts a new include, it looks at the include
  blocks and try to put the new include such that its order conforms
  to its surrounding.  It's put in the include block which contains
  core kernel includes, in the same order that the rest are ordered -
  alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
  doesn't seem to be any matching order.

* If the script can't find a place to put a new include (mostly
  because the file doesn't have fitting include block), it prints out
  an error message indicating which .h file needs to be added to the
  file.

The conversion was done in the following steps.

1. The initial automatic conversion of all .c files updated slightly
   over 4000 files, deleting around 700 includes and adding ~480 gfp.h
   and ~3000 slab.h inclusions.  The script emitted errors for ~400
   files.

2. Each error was manually checked.  Some didn't need the inclusion,
   some needed manual addition while adding it to implementation .h or
   embedding .c file was more appropriate for others.  This step added
   inclusions to around 150 files.

3. The script was run again and the output was compared to the edits
   from #2 to make sure no file was left behind.

4. Several build tests were done and a couple of problems were fixed.
   e.g. lib/decompress_*.c used malloc/free() wrappers around slab
   APIs requiring slab.h to be added manually.

5. The script was run on all .h files but without automatically
   editing them as sprinkling gfp.h and slab.h inclusions around .h
   files could easily lead to inclusion dependency hell.  Most gfp.h
   inclusion directives were ignored as stuff from gfp.h was usually
   wildly available and often used in preprocessor macros.  Each
   slab.h inclusion directive was examined and added manually as
   necessary.

6. percpu.h was updated not to include slab.h.

7. Build test were done on the following configurations and failures
   were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
   distributed build env didn't work with gcov compiles) and a few
   more options had to be turned off depending on archs to make things
   build (like ipr on powerpc/64 which failed due to missing writeq).

   * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
   * powerpc and powerpc64 SMP allmodconfig
   * sparc and sparc64 SMP allmodconfig
   * ia64 SMP allmodconfig
   * s390 SMP allmodconfig
   * alpha SMP allmodconfig
   * um on x86_64 SMP allmodconfig

8. percpu.h modifications were reverted so that it could be applied as
   a separate patch and serve as bisection point.

Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: NTejun Heo <tj@kernel.org>
Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  23. 19 3月, 2010 2 次提交
  25. 03 3月, 2010 5 次提交
  27. 12 12月, 2009 1 次提交
    • S
      USB: xhci: Make reverting an alt setting "unfailable". · 74f9fe21
      由 Sarah Sharp 提交于 
      When a driver wants to switch to a different alternate setting for an
interface, the USB core will (soon) check whether there is enough
bandwidth.  Once the new alternate setting is installed in the xHCI
hardware, the USB core will send a USB_REQ_SET_INTERFACE control
message.  That can fail in various ways, and the USB core needs to be
able to reinstate the old alternate setting.

With the old code, reinstating the old alt setting could fail if the
there's not enough memory to allocate new endpoint rings.  Keep
around a cache of (at most 31) endpoint rings for this case.  When we
successfully switch the xHCI hardware to the new alt setting, the old
alt setting's rings will be stored in the cache.  Therefore we'll
always have enough rings to satisfy a conversion back to a previous
device setting.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      74f9fe21