Difference between revisions of "Download/kernel/rhel5/028stab053.10/changes"

From OpenVZ Virtuozzo Containers Wiki
Jump to: navigation, search
(use div class="change")
m (Protected "Download/kernel/rhel5/028stab053.10/changes": Robot: Protecting a list of files. [edit=autoconfirmed:move=autoconfirmed])
(2 intermediate revisions by the same user not shown)
Line 42: Line 42:
Bug #98868.
Bug #98868.
==== diff-ms-splice-access-20080211 ====
<div class="change">
Patch prepared by Denis Lunev <den@sw.ru>
Proper access checks in sys_splice.
Bug #98867.
==== linux-2.6.18-3w-xxxx- ====
==== linux-2.6.18-3w-xxxx- ====
<div class="change">
<div class="change">
Line 62: Line 54:
Bug #99172.
Bug #99172.

Latest revision as of 18:30, 22 October 2009


  • Fixed not working NAT in container in case ip_conntrack_disable_ve0 module option is set
  • Fixed data corruption with 3ware 7000 and 8000 controllers
  • Improved performance on AMD NUMA boxes



Patch from Dmitry Mishin <dim@parallels.com>

If ip_conntrack_disable_ve0 option is set, than it is impossible to use nat targets (DNAT, SNAT) inside Containers even if nat table is permitted for them and respective modules are loaded. This patch fixes above issue.

Fixed and tested by Konstantin Khlebnikov <khlebnikov@openvz.org>.

Issue reported by Alec.


Patch from Alexandr Andreev <aandreev@openvz.org>

[SCHEDULER] fix load_balance() behavior, when it's invoked on a busy PCPU.

Note: looks like it works, but not sure about any kind of performance any more. Now we can trust performance results for VE's with --cpus 1

Bugs #93544, #98868.


Patch from Konstantin Khlebnikov <khlebnikov@openvz.org>

CPU frequency switch may be incorrect on some hardware.

Ondemand use queue_delayed_work_on call and suppose that it works correctly. Farsched schedule kernel threads on random cpu and timer event may called not on supposed cpu.

This leads to CPU frequency is set almost randomly.

Bug #98868.


Patch prepared by Kirill Shileev <kshileev@parallels.com>

>From http://www.3ware.com/KB/article.aspx?id=15243&cNode=6I1C6S

Solves the problem with data corruption with 3ware 7000 or 8000 on x86_64 with more then 4G.

Bug #99172.