lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4D7FE3BE.4000100@xmsnet.nl>
Date:	Tue, 15 Mar 2011 23:10:06 +0100
From:	Hans de Bruin <jmdebruin@...net.nl>
To:	Johannes Weiner <hannes@...xchg.org>
CC:	linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: 2.6.38-rc echo 3 > /proc/sys/vm/drop_caches repairs mplayer distortions

On 03/15/2011 07:59 PM, Johannes Weiner wrote:
> linux-mm cc'd
>
> On Mon, Mar 14, 2011 at 10:34:31PM +0100, Hans de Bruin wrote:
>> Since the start of the start of 2.6.38-rc I sporadic have problems
>> with mplayer. A mpeg stream sometimes gets distorted when mplayer
>> starts. An example is at http://www.xs4all.nl/~bruinjm/mplayer.png .
>> I do not know how to trigger the behaviour, so bissecting is not
>> possible. Since yesterday however I found a way to 'repair' mplayer:
>>
>> echo 3>  /proc/sys/vm/drop_caches
>>
>> This repairs mplayer while it is running.
>
> While echo is running?  Or does one cache drop fix the problem until
> mplayer exits?  Could you describe exactly the steps you are going
> through and the effects they have?
>

mplayer either starts with a corrupt screen or not. Without interference 
  there are no switches from good to bad or the other way around. When I 
run echo 3> ... its completes in a blink of an eye and at the same time 
the mplayer screen switches from bad to good.

In an earlier snapshot I made 
(http://www.xs4all.nl/~bruinjm/earlier.png) you can see (if you ignore 
the starship) two mplayers playing the same file. The colors look the 
same. The contens on the bad window is moving horizontaly.

sometimes restarting mplayer helps, some times not. When its not the 
corrupt screens are persistent. clearing the cache between running seems 
mplayer seems to help in these cases (although I only tested this ones).

The 8mbit/s videocapture streams to have a much higher change of going 
wrong than 1mbit/s streams from other sources.

The first incident was at 26-jan the second at 7-feb. I use mplayer to 
watch the news 4 times a week. so its not failing often. At 26-jan my 
tree was at commit 6663050 (I pull and rebuild every day)

only mplayer is misbehaving. My other two favorite programs firefox and 
thunderbird work fine and I have not seen corrupt files.

-- 
Hans



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ