On 13.04.2013 11:29, Markiyan Kushnir wrote:
The only thing I would like to add -- tree lookup did make a good effect
on CPU consumption.
John,
I'm just curious, did you consider sys/tree.h for tree implementation? I
realize that it wouldn't be well portable to Linux. Any way, did
The only thing I would like to add -- tree lookup did make a good effect
on CPU consumption.
--
Markiyan.
On 13.04.2013 10:38, mrb...@gmail.com wrote:
In the previous version (0.61), the process of checking
file names against the list of known files in the
repository was inefficient and most
here is what I used to use (not 100% match, but quite close):
indent -bad -bap -bbb -d4 -di1 -fc1 -i4 -nip -npsl -nut $*
--
Markiyan.
On 13.04.2013 02:38, John Mehr wrote:
On Thu, 11 Apr 2013 01:39:32 -0700 (PDT)
mrb...@gmail.com wrote:
On Thursday, April 11, 2013 1:14:57 PM UTC+6, mrb..
ok, looks like the mere fix to the strlen() call as you suggested
earlier doesn't resolve the issue of CPU eating up.
On 12.04.2013 08:43, mrb...@gmail.com wrote:
On Friday, April 12, 2013 1:09:53 AM UTC+6, Markiyan Kushnir wrote:
Another thing that might be worth of attention, the pa
On 11.04.2013 20:42, Markiyan Kushnir wrote:
I agree with Ian, there is no need to statically link to base libraries.
While not going into details of the patch, I can confirm no issues,
except of known ones, of course: ports/17, ports/177408.
Another thing that might be worth of attention
24, 2013 9:57:12 AM UTC+6, Markiyan Kushnir wrote:
> > Tested svnup for a while, and I can say it does its job well, and works
> > basically as I would expect, so thanks for your initiative. Although it
> > appears to be quite resource greedy. Most of the time it showed
On 31.03.2013 13:07, Markiyan Kushnir wrote:
Hi John,
I also measured svnup basic process resource usage, attaching a complete
plot (measurements were taken each 2 seconds based on ps(1) and
procstat(1)). Hopefully it will help you as well.
(in case it's not available through the
ups, sorry:
https://docs.google.com/file/d/0B9Q-zpUXxqCnRVVMTkk1blVfZzA/edit?usp=sharing
Please let me know if you have problems with accessing it.
--
Markiyan
On 31.03.2013 13:18, Kurt Jaeger wrote:
Hi!
I also measured svnup basic process resource usage, attaching a complete
plot (measurem
Hi John,
I also measured svnup basic process resource usage, attaching a complete
plot (measurements were taken each 2 seconds based on ps(1) and
procstat(1)). Hopefully it will help you as well.
--
Markiyan.
On 31.03.2013 12:51, Markiyan Kushnir wrote:
On 25.03.2013 02:55, John Mehr wrote
On 25.03.2013 02:55, John Mehr wrote:
On Sun, 24 Mar 2013 05:55:19 +0200
Markiyan Kushnir wrote:
Hello John,
Tested svnup for a while, and I can say it does its job well, and
works basically as I would expect, so thanks for your initiative.
Although it appears to be quite resource greedy
Hello John,
Tested svnup for a while, and I can say it does its job well, and works
basically as I would expect, so thanks for your initiative. Although it
appears to be quite resource greedy. Most of the time it showed
something like:
PID USERNAMETHR PRI NICE SIZERES STATE C
On 13.01.2013 18:48, Juergen Lock wrote:
On Sun, Jan 13, 2013 at 06:11:13PM +0200, Markiyan Kushnir wrote:
Hi,
Any reason why LINUX_VIDIOC_ENUM_FRAMESIZES,
LINUX_VIDIOC_ENUM_FRAMEINTERVALS, LINUX_VIDIOC_ENCODER_CMD, and
LINUX_VIDIOC_TRY_ENCODER_CMD in compat/linux/linux_ioctl.c have been put
Hi,
Any reason why LINUX_VIDIOC_ENUM_FRAMESIZES,
LINUX_VIDIOC_ENUM_FRAMEINTERVALS, LINUX_VIDIOC_ENCODER_CMD, and
LINUX_VIDIOC_TRY_ENCODER_CMD in compat/linux/linux_ioctl.c have been put
under #ifdef VIDIOC_ENUM_FRAMESIZES (looks like it's been there since
rev. 221426, when the v4l2 support wa
A related thread (for the record):
http://lists.freebsd.org/pipermail/freebsd-virtualization/2011-February/000648.html
Markiyan.
On 15.02.2012 12:34, Markiyan Kushnir wrote:
Here it is:
(kgdb) bt
#0 doadump () at /usr/RELENG_8/src/sys/kern/kern_shutdown.c:263
#1 0x8036da50 in boot
shnir kernel: Xfast_syscall() at Xfast_syscall+0xfc
Feb 15 14:10:01 mkushnir kernel: --- syscall (54, FreeBSD ELF64, ioctl),
rip = 0x800b86a6c, rsp = 0x7fffe4a8, rbp = 0x7fffef44 ---
--
Marikyan.
On 15.02.2012 12:40, Markiyan Kushnir wrote:
Any way, I'm still unsure if the urtw's l
Any way, I'm still unsure if the urtw's logic of "ignore device
identification failure, and attach" is correct.
--
Markiyan.
2012/2/15 Markiyan Kushnir :
> looks like that's it ...
>
> --
> Markiyan.
___
freebsd
looks like that's it ...
--
Markiyan.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
s frame inner to this frame (corrupt stack?)
(kgdb)
2012/2/15 Sergey Kandaurov :
> On 15 February 2012 13:01, Markiyan Kushnir
> wrote:
>> Hello,
>>
>> [First seen on RELENG_9,] then (trying to get back to 8) on RELENG_8, both
>> csup'ed around Feb. 10.
>&
Hello,
[First seen on RELENG_9,] then (trying to get back to 8) on RELENG_8,
both csup'ed around Feb. 10.
Now worked around by turning the RTL8187L off in the BIOS.
%uname -a
FreeBSD mkushnir.zapto.org 8.2-STABLE FreeBSD 8.2-STABLE #0: Sat Feb 11
19:39:29 EET 2012
r...@mkushnir.zapto.org:/u
2011/1/7 Jeremy Chadwick :
> On Fri, Jan 07, 2011 at 12:29:17PM +1100, Jean-Yves Avenard wrote:
>> On 6 January 2011 22:26, Chris Forgeron wrote:
>> > You know, these days I'm not as happy with SSD's for ZIL. I may blog about
>> > some of the speed results I've been getting over the last 6mo-1yr
As long as you have to re-install everything from scratch, you can
consider installing 8.0 and having your services jailed. The new jail is
announced to be much improved.
Markiyan.
Paul Procacci wrote:
>> But far as rtld vulnerability, doesn't it require at least a local
user account?
No, i
It's amazing -- I also did my recent 6.3->7.0 exactly this way. Running
it as a desktop, WindowMaker, some of gnu apps. kde is at hand mostly
for a couple of applications, but it works ok either.
My case is much simpler, but I feel that it's worth of considering
alternatives to portupgrade. I
22 matches
Mail list logo
