Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
大约 1 年 前同步成功

通知 158
Star 36
Fork 7
cloud-kernel
cloud-kernel

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

切换分支/标签
  1. 17 2月, 2010 1 次提交
  3. 15 2月, 2010 4 次提交
  5. 14 2月, 2010 1 次提交
    • C
      firewire: ohci: retransmit isochronous transmit packets on cycle loss · 7f51a100
      由 Clemens Ladisch 提交于 
      In isochronous transmit DMA descriptors, link the skip address pointer
back to the descriptor itself.  When a cycle is lost, the controller
will send the packet in the next cycle, instead of terminating the
entire DMA program.

There are two reasons for this:

* This behaviour is compatible with the old IEEE1394 stack.  Old
  applications would not expect the DMA program to stop in this case.

* Since the OHCI driver does not report any uncompleted packets, the
  context would stop silently; clients would not have any chance to
  detect and handle this error without a watchdog timer.
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>

Pieter Palmers notes:

"The reason I added this retry behavior to the old stack is because some
cards now and then fail to send a packet (e.g. the o2micro card in my
dell laptop).  I couldn't figure out why exactly this happens, my best
guess is that the card cannot fetch the payload data on time.  This
happens much more frequently when sending large packets, which leads me
to suspect that there are some contention issues with the DMA that fills
the transmit FIFO.

In the old stack it was a pretty critical issue as it resulted in a
freeze of the userspace application.

The omission of a packet doesn't necessarily have to be an issue.  E.g.
in IEC61883 streams the DBC field can be used to detect discontinuities
in the stream.  So as long as the other side doesn't bail when no
[packet] is present in a cycle, there is not really a problem.

I'm not convinced though that retrying is the proper solution, but it is
simple and effective for what it had to do.  And I think there are no
reasons not to do it this way.  Userspace can still detect this by
checking the cycle the descriptor was sent in."

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (changelog, comment)
      7f51a100
  7. 12 2月, 2010 7 次提交
  9. 11 2月, 2010 23 次提交
  11. 10 2月, 2010 4 次提交
    • N
      md: fix some lockdep issues between md and sysfs. · ef286f6f
      由 NeilBrown 提交于 
      ======
This fix is related to
    http://bugzilla.kernel.org/show_bug.cgi?id=15142
but does not address that exact issue.
======

sysfs does like attributes being removed while they are being accessed
(i.e. read or written) and waits for the access to complete.

As accessing some md attributes takes the same lock that is held while
removing those attributes a deadlock can occur.

This patch addresses 3 issues in md that could lead to this deadlock.

Two relate to calling flush_scheduled_work while the lock is held.
This is probably a bad idea in general and as we use schedule_work to
delete various sysfs objects it is particularly bad.

In one case flush_scheduled_work is called from md_alloc (called by
md_probe) called from do_md_run which holds the lock.  This call is
only present to ensure that ->gendisk is set.  However we can be sure
that gendisk is always set (though possibly we couldn't when that code
was originally written.  This is because do_md_run is called in three
different contexts:
  1/ from md_ioctl.  This requires that md_open has succeeded, and it
     fails if ->gendisk is not set.
  2/ from writing a sysfs attribute.  This can only happen if the
     mddev has been registered in sysfs which happens in md_alloc
     after ->gendisk has been set.
  3/ from autorun_array which is only called by autorun_devices, which
     checks for ->gendisk to be set before calling autorun_array.
So the call to md_probe in do_md_run can be removed, and the check on
->gendisk can also go.


In the other case flush_scheduled_work is being called in do_md_stop,
purportedly to wait for all md_delayed_delete calls (which delete the
component rdevs) to complete.  However there really isn't any need to
wait for them - they have already been disconnected in all important
ways.

The third issue is that raid5->stop() removes some attribute names
while the lock is held.  There is already some infrastructure in place
to delay attribute removal until after the lock is released (using
schedule_work).  So extend that infrastructure to remove the
raid5_attrs_group.

This does not address all lockdep issues related to the sysfs
"s_active" lock.  The rest can be address by splitting that lockdep
context between symlinks and non-symlinks which hopefully will happen.
Signed-off-by: NNeilBrown <neilb@suse.de>
      ef286f6f
    • M
      drm/nv50: make the pgraph irq handler loop like the pre-nv50 version · b1d37aa0
      由 Maarten Maathuis 提交于 
      Unset the bit that indicates that a ctxprog can continue at the end.
Signed-off-by: NMaarten Maathuis <madman2003@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      b1d37aa0
    • M
      drm/nv50: delete ramfc object after disabling fifo, not before · a87ff62a
      由 Maarten Maathuis 提交于 
      ramfc is zero'ed upon destruction, so it's safer to do things in the right
order.
Signed-off-by: NMaarten Maathuis <madman2003@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      a87ff62a
    • M
      drm/nv50: avoid unloading pgraph context when ctxprog is running · a51a3bf5
      由 Maarten Maathuis 提交于 
      - We need to disable pgraph fifo access before checking the current channel,
  otherwise we could still hit a running ctxprog.
- The writes to 0x400500 are already handled by pgraph->fifo_access and are
  therefore redundant, moreover pgraph fifo access should not be reenabled
  before current context is set as invalid. So remove them altogether.
Signed-off-by: NMaarten Maathuis <madman2003@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      a51a3bf5