On Sun, Jan 15, 2012 at 1:31 AM, Roman Yeryomin wrote:
> On 12 January 2012 11:31, Helmut Schaa wrote:
>> The most interesting one is for sure this one, at least in my tests
>> it reduced CPU load considerable:
>>
>> http://permalink.gmane.org/gmane.linux.drivers.rt2x00.user/53
>>
>
> I got 8.5 -
On 1/14/12 11:37 AM, Olipro wrote:
> On Saturday 14 Jan 2012 02:45:59 Philip Prindeville wrote:
>> Don't we already have a 'disabled' option? Now we're adding an
>> 'enable_server' option?
>>
>> That seems confusing for no useful reason.
>>
>
> have you bothered to read what I originally wrote? y
On Sun, Jan 15, 2012 at 1:42 PM, devendra.aaru wrote:
>>
>> valgrind lua cairo test4oo.lua?? :)
>>>
>>> Segmentation fault
>>
>> atleast you will get some inputs by running valgrind .
No Valgrind on ARM. And running same test with Valgrind on x86 doesn't
find anything.
I have dmalloc linked in an
This patch updates shorewall-lite to current stable release 4.4.27.2
Signed-off-by: Edy Corak i...@loenshotel.de
Index: patches/110-MODULESDIR.patch
===
--- patches/110-MODULESDIR.patch (Revision 29755)
+++ patches/110-MODULESDIR.patc
This patch updates shorewall6-lite to current stable release 4.4.27.2
Signed-off-by: Edy Corak i...@loenshotel.de
Index: patches/120-LOGFILE.patch
===
--- patches/120-LOGFILE.patch (Revision 29755)
+++ patches/120-LOGFILE.patch (Arbei
On Mon, Jan 16, 2012 at 12:11 AM, devendra.aaru wrote:
>
>
> On Sun, Jan 15, 2012 at 11:39 PM, jonsm...@gmail.com
> wrote:
>
>> First run builds the fontconfig cache.
>> Second run uses the cache and seg faults.
>> I delete it, and program runs again.
>>
>> The gdb data from the segfault is usele
On Sun, Jan 15, 2012 at 11:39 PM, jonsm...@gmail.com wrote:
> First run builds the fontconfig cache.
> Second run uses the cache and seg faults.
> I delete it, and program runs again.
>
> The gdb data from the segfault is useless since the seg fault is
> caused by application data getting corrupte
First run builds the fontconfig cache.
Second run uses the cache and seg faults.
I delete it, and program runs again.
The gdb data from the segfault is useless since the seg fault is
caused by application data getting corrupted by some other source I
have not been able to track down.
I have tried
After more testing updating the font file didn't fix the corruption,
it just moved it to a different spot which makes a different test
program fail. Now I really don't know what is messing up memory but it
is definitely related to fonts.
--
Jon Smirl
jonsm...@gmail.com
___
Index: font/liberation-fonts-ttf/Makefile
===
--- font/liberation-fonts-ttf/Makefile (revision 29747)
+++ font/liberation-fonts-ttf/Makefile (working copy)
@@ -6,14 +6,14 @@
#
include $(TOPDIR)/rules.mk
-PKG_NAME:=liberation-fonts
On 2012-01-15 4:40 PM, jonsm...@gmail.com wrote:
> I finally found the bug. One of the glyphs in the 1.04 liberation font
> package has a bad index. That index causes the higher layers to
> corrupt a few bytes of memory when they cache it. Of course corrupting
> a few bytes of memory may, but not a
I finally found the bug. One of the glyphs in the 1.04 liberation font
package has a bad index. That index causes the higher layers to
corrupt a few bytes of memory when they cache it. Of course corrupting
a few bytes of memory may, but not always, lead to a bunch of
unrelated failures later. In t
This patch add sysupgrade for Engenius ESR-9753
Signed-off-by: Artur Wronowski
Index: target/linux/ramips/base-files/lib/upgrade/platform.sh
===
--- target/linux/ramips/base-files/lib/upgrade/platform.sh (wersja 29753)
+++ tar
13 matches
Mail list logo
