Re: solo6010 modprobe lockup since e1ceb25a (v4.3 regression)

[Krzysztof Hałasa]

Andrey Utkin  writes:

> On Thu, Sep 22, 2016 at 10:51:37AM +0200, Krzysztof Hałasa wrote:
>> I wonder if the following fixes the problem (completely untested).
>
> I have given this a run, and it still hangs.

Does (only) adding the

pci_read_config_word(solo_dev->pdev, PCI_STATUS, );

in solo_reg_write() help?
-- 
Krzysztof Halasa

Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

cron job: media_tree daily build: ERRORS

[Hans Verkuil]

This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:   Mon Sep 26 04:00:17 CEST 2016
git branch: test
git hash:   e3ea5e94489bc8c711d422dfa311cfa310553a1b
gcc version:i686-linux-gcc (GCC) 5.4.0
sparse version: v0.5.0-56-g7647c77
smatch version: v0.5.0-3428-gdfe27cf
host hardware:  x86_64
host os:4.6.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: WARNINGS
linux-2.6.37.6-i686: WARNINGS
linux-2.6.38.8-i686: WARNINGS
linux-2.6.39.4-i686: WARNINGS
linux-3.0.60-i686: WARNINGS
linux-3.1.10-i686: ERRORS
linux-3.2.37-i686: ERRORS
linux-3.3.8-i686: ERRORS
linux-3.4.27-i686: WARNINGS
linux-3.5.7-i686: WARNINGS
linux-3.6.11-i686: WARNINGS
linux-3.7.4-i686: WARNINGS
linux-3.8-i686: WARNINGS
linux-3.9.2-i686: WARNINGS
linux-3.10.1-i686: WARNINGS
linux-3.11.1-i686: OK
linux-3.12.23-i686: OK
linux-3.13.11-i686: OK
linux-3.14.9-i686: OK
linux-3.15.2-i686: OK
linux-3.16.7-i686: OK
linux-3.17.8-i686: OK
linux-3.18.7-i686: OK
linux-3.19-i686: OK
linux-4.0-i686: OK
linux-4.1.1-i686: OK
linux-4.2-i686: OK
linux-4.3-i686: OK
linux-4.4-i686: OK
linux-4.5-i686: OK
linux-4.6-i686: OK
linux-4.7-i686: WARNINGS
linux-4.8-rc1-i686: OK
linux-2.6.36.4-x86_64: WARNINGS
linux-2.6.37.6-x86_64: WARNINGS
linux-2.6.38.8-x86_64: WARNINGS
linux-2.6.39.4-x86_64: WARNINGS
linux-3.0.60-x86_64: WARNINGS
linux-3.1.10-x86_64: ERRORS
linux-3.2.37-x86_64: ERRORS
linux-3.3.8-x86_64: ERRORS
linux-3.4.27-x86_64: WARNINGS
linux-3.5.7-x86_64: WARNINGS
linux-3.6.11-x86_64: WARNINGS
linux-3.7.4-x86_64: WARNINGS
linux-3.8-x86_64: WARNINGS
linux-3.9.2-x86_64: WARNINGS
linux-3.10.1-x86_64: WARNINGS
linux-3.11.1-x86_64: OK
linux-3.12.23-x86_64: OK
linux-3.13.11-x86_64: OK
linux-3.14.9-x86_64: OK
linux-3.15.2-x86_64: OK
linux-3.16.7-x86_64: OK
linux-3.17.8-x86_64: OK
linux-3.18.7-x86_64: OK
linux-3.19-x86_64: OK
linux-4.0-x86_64: OK
linux-4.1.1-x86_64: OK
linux-4.2-x86_64: OK
linux-4.3-x86_64: OK
linux-4.4-x86_64: OK
linux-4.5-x86_64: OK
linux-4.6-x86_64: OK
linux-4.7-x86_64: WARNINGS
linux-4.8-rc1-x86_64: OK
apps: WARNINGS
spec-git: OK
sparse: WARNINGS
smatch: WARNINGS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Monday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Intel-gfx] [PATCH 11/11] dma-buf: Do a fast lockless check for poll with timeout=0

[Daniel Vetter]

On Fri, Sep 23, 2016 at 07:59:44PM +0200, Christian König wrote:
> Am 23.09.2016 um 17:20 schrieb Chris Wilson:
> > On Fri, Sep 23, 2016 at 03:50:44PM +0200, Daniel Vetter wrote:
> > > On Mon, Aug 29, 2016 at 08:08:34AM +0100, Chris Wilson wrote:
> > > > Currently we install a callback for performing poll on a dma-buf,
> > > > irrespective of the timeout. This involves taking a spinlock, as well as
> > > > unnecessary work, and greatly reduces scaling of poll(.timeout=0) across
> > > > multiple threads.
> > > > 
> > > > We can query whether the poll will block prior to installing the
> > > > callback to make the busy-query fast.
> > > > 
> > > > Single thread: 60% faster
> > > > 8 threads on 4 (+4 HT) cores: 600% faster
> > > > 
> > > > Still not quite the perfect scaling we get with a native busy ioctl, but
> > > > poll(dmabuf) is faster due to the quicker lookup of the object and
> > > > avoiding drm_ioctl().
> > > > 
> > > > Signed-off-by: Chris Wilson 
> > > > Cc: Sumit Semwal 
> > > > Cc: linux-media@vger.kernel.org
> > > > Cc: dri-de...@lists.freedesktop.org
> > > > Cc: linaro-mm-...@lists.linaro.org
> > > > Reviewed-by: Daniel Vetter 
> > > Need to strike the r-b here, since Christian König pointed out that
> > > objects won't magically switch signalling on.
> > Oh, it also means that
> > 
> > commit fb8b7d2b9d80e1e71f379e57355936bd2b024be9
> > Author: Jammy Zhou 
> > Date:   Wed Jan 21 18:35:47 2015 +0800
> > 
> >  reservation: wait only with non-zero timeout specified (v3)
> >  When the timeout value passed to reservation_object_wait_timeout_rcu
> >  is zero, no wait should be done if the fences are not signaled.
> >  Return '1' for idle and '0' for busy if the specified timeout is '0'
> >  to keep consistent with the case of non-zero timeout.
> >  v2: call fence_put if not signaled in the case of timeout==0
> >  v3: switch to reservation_object_test_signaled_rcu
> >  Signed-off-by: Jammy Zhou 
> >  Reviewed-by: Christian König 
> >  Reviewed-by: Alex Deucher 
> >  Reviewed-By: Maarten Lankhorst 
> >  Signed-off-by: Sumit Semwal 
> > 
> > is wrong. And reservation_object_test_signaled_rcu() is unreliable.
> 
> Ups indeed, that patch is wrong as well.
> 
> I suggest that we just enable the signaling in this case as well.

Will you/Zhou take care of this corner case? Just so I can't forget about
it ;-)

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Linaro-mm-sig] [PATCH 10/11] dma-buf: Use seqlock to close RCU race in test_signaled_single

[Daniel Vetter]

On Fri, Sep 23, 2016 at 03:02:32PM +0100, Chris Wilson wrote:
> On Fri, Sep 23, 2016 at 03:49:26PM +0200, Daniel Vetter wrote:
> > On Mon, Aug 29, 2016 at 08:08:33AM +0100, Chris Wilson wrote:
> > > With the seqlock now extended to cover the lookup of the fence and its
> > > testing, we can perform that testing solely under the seqlock guard and
> > > avoid the effective locking and serialisation of acquiring a reference to
> > > the request.  As the fence is RCU protected we know it cannot disappear
> > > as we test it, the same guarantee that made it safe to acquire the
> > > reference previously.  The seqlock tests whether the fence was replaced
> > > as we are testing it telling us whether or not we can trust the result
> > > (if not, we just repeat the test until stable).
> > > 
> > > Signed-off-by: Chris Wilson 
> > > Cc: Sumit Semwal 
> > > Cc: linux-media@vger.kernel.org
> > > Cc: dri-de...@lists.freedesktop.org
> > > Cc: linaro-mm-...@lists.linaro.org
> > 
> > Not entirely sure this is safe for non-i915 drivers. We might now call
> > ->signalled on a zombie fence (i.e. refcount == 0, but not yet kfreed).
> > i915 can do that, but other drivers might go boom.
> 
> All fences must be under RCU guard, or is that the sticking point? Given
> that, the problem is fence reallocation within the RCU grace period. If
> we can mandate that fence reallocation must be safe for concurrent
> fence->ops->*(), we can use this technique to avoid the serialisation
> barrier otherwise required. In the simple stress test, the difference is
> an order of magnitude, and test_signaled_rcu is often on a path where
> every memory barrier quickly adds up (at least for us).
> 
> So is it just that you worry that others using SLAB_DESTROY_BY_RCU won't
> ensure their fence is safe during the reallocation?

Before your patch the rcu-protected part was just the
kref_get_unless_zero. This was done before calling down into and
fenc->ops->* functions. Which means the code of these functions was
guaranteed to run on a real fence object, and not a zombie fence in the
process of getting destructed.

Afaiui with your patch we might call into fence->ops->* on these zombie
fences. That would be a behaviour change with rather big implications
(since we'd need to audit all existing implementations, and also make sure
all future ones will be ok too). Or I missed something again.

I think we could still to this trick, at least partially, by making sure
we only inspect generic fence state and never call into fence->ops before
we're guaranteed to have a real fence.

But atm (at least per Christian König) a fence won't eventually get
signalled without calling into ->ops functions, so there's a catch 22.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] dma-buf/sw_sync: mark sync_timeline_create() static

[Gustavo Padovan]

Hi Baoyou,

2016-09-22 Greg Kroah-Hartman :

> On Tue, Sep 20, 2016 at 06:23:33PM +0530, Sumit Semwal wrote:
> > Hi Baoyou,
> > 
> > On 20 September 2016 at 16:43, Gustavo Padovan  wrote:
> > > 2016-09-18 Baoyou Xie :
> > >
> > >> We get 1 warning when building kernel with W=1:
> > >> drivers/dma-buf/sw_sync.c:87:23: warning: no previous prototype for 
> > >> 'sync_timeline_create' [-Wmissing-prototypes]
> > >>
> > >> In fact, this function is only used in the file in which it is
> > >> declared and don't need a declaration, but can be made static.
> > >> So this patch marks it 'static'.
> > >>
> > >> Signed-off-by: Baoyou Xie 
> > >> ---
> > >>  drivers/dma-buf/sw_sync.c | 2 +-
> > >>  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > Thanks for finding this.
> > 
> > Thanks for the patch; this doesn't apply to mainline yet, since the
> > de-staging of sw_sync code is queued for 4.9 via Greg-KH's tree.
> > CC'ing him.
> > 
> > Greg, would it be possible to please take this via your tree?
> 
> If someone resends it to me with the needed acks and reviewed-by, I
> will.

Could please resend this to Greg with all the acks and reviewed-by in
the commit message? Thanks.

Gustavo

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [media/input] rc: report rc protocol type to userspace through input

[Sean Young]

Hi Dmitry,

On Fri, Sep 23, 2016 at 03:08:31PM -0700, Dmitry Torokhov wrote:
> On Thu, Sep 22, 2016 at 11:57:13AM -0300, Mauro Carvalho Chehab wrote:
> > Em Wed, 21 Sep 2016 10:54:21 +0100
> > Sean Young  escreveu:
> > 
> > > We might want to know what protocol a remote uses when we do not know. 
> > > With
> > > this patch and another patch for v4l-utils (follows), you can do that 
> > > with:
> > > 
> > > ./ir-keytable  -p rc-5,nec,rc-6,jvc,sony,sanyo,sharp,xmp -t
> > > Testing events. Please, press CTRL-C to abort.
> > > 1474415431.689685: event type EV_MSC(0x04): protocol = RC_TYPE_RC6_MCE
> > > 1474415431.689685: event type EV_MSC(0x04): scancode = 0x800f040e
> > > 1474415431.689685: event type EV_SYN(0x00).
> > > 
> > > This makes RC_TYPE_* part of the ABI. We also remove the enum rc_type,
> > > since in input-event-codes.h we cannot not use enums.
> > > 
> > > In addition, now that the input layer knows the rc protocol and scancode,
> > > at a later point we could add a feature where keymaps could be created
> > > based on both protocol and scancode, not just scancode.
> > 
> > We need Dmitry's ack in order to apply this one.
> 
> I'd rather not: I am trying to keep input API hardware-independent and
> the kind of device emitting keycodes (a remote control in the sense of
> drivers/media/rc or USB device or BT device) should not really matter to
> consumers. Similarly how we do not export whether device is USB1.1 or
> USB2 or USB3 (although we do have input->id.bustype, but it is more for
> identification purposes rather than for adjusting properties).

Keyboards produce device dependant scancodes; the only output RC devices 
have is protocol and scancode. The scancode is already being sent to
the input layer, and if we can't send the rc protocol to the input layer
we would need a new char device just for that, which is complete overkill.

Alternatively we can put the rc protocol type in MSC_RAW, MSC_SERIAL or
ABS_MISC or one of the other existing device dependant input codes. 

> For configuration (like loading keymaps) we can examine
> parent hardware device and decide.

Unfortunately there is nothing to examine there. The usb device of an 
infrared receiver will tell you nothing about the remote the user is
using.

It would be really helpful if this could be merged; I don't know what
other solution there is to this problem.


Sean
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html