<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/arch/ia64/kernel, branch v2.6.13.1</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>[IA64] Initialize some spinlocks</title>
<updated>2005-08-16T22:33:26+00:00</updated>
<author>
<name>Keith Owens</name>
<email>kaos@sgi.com</email>
</author>
<published>2005-07-31T00:52:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=71841b8fe7dd8caffd07482cbed4a99874bfbb70'/>
<id>71841b8fe7dd8caffd07482cbed4a99874bfbb70</id>
<content type='text'>
Some IA64 spinlocks are not being initialized, make it so.

Signed-off-by: Keith Owens &lt;kaos@sgi.com&gt;
Signed-off-by: Tony Luck &lt;tony.luck@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Some IA64 spinlocks are not being initialized, make it so.

Signed-off-by: Keith Owens &lt;kaos@sgi.com&gt;
Signed-off-by: Tony Luck &lt;tony.luck@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Auto-update from upstream</title>
<updated>2005-08-16T18:29:57+00:00</updated>
<author>
<name>Tony Luck</name>
<email>tony.luck@intel.com</email>
</author>
<published>2005-08-16T18:29:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=f7001e8f1fa5369ee24f58255726a04a2019e4bd'/>
<id>f7001e8f1fa5369ee24f58255726a04a2019e4bd</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>[PATCH] fix for ia64 sched-domains code</title>
<updated>2005-08-16T15:54:00+00:00</updated>
<author>
<name>John Hawkes</name>
<email>hawkes@jackhammer.engr.sgi.com</email>
</author>
<published>2005-08-16T07:59:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=367ae3cd74bdc2ad32d71293427fec570b14ddcd'/>
<id>367ae3cd74bdc2ad32d71293427fec570b14ddcd</id>
<content type='text'>
Fix for ia64 sched domain building triggered by cpuset code.

Acked-by: Nick Piggin &lt;npiggin@suse.de&gt;
Acked-by: Dinakar Guniguntala &lt;dino@in.ibm.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fix for ia64 sched domain building triggered by cpuset code.

Acked-by: Nick Piggin &lt;npiggin@suse.de&gt;
Acked-by: Dinakar Guniguntala &lt;dino@in.ibm.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[IA64] fix perfmon context load</title>
<updated>2005-08-10T23:21:58+00:00</updated>
<author>
<name>stephane.eranian@hp.com</name>
<email>stephane.eranian@hp.com</email>
</author>
<published>2005-07-28T12:18:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=6bf11e8c708f0e512ed733fc65a50770c5bc7b54'/>
<id>6bf11e8c708f0e512ed733fc65a50770c5bc7b54</id>
<content type='text'>
The PFM_LOAD_CONTEXT may fail silently and cause a session
to remain reserved even though it should not. This can happen
when the commands succeeds in reserving the session but fails
when it actually tries to attach to the load_pid. In that case,
the command has failed but will return 0. More importantly,
the session will remain reserved. This patch fixes the problem.

Signed-off-by: &lt;stephane.eranian@hp.com&gt;
Signed-off-by: Tony Luck &lt;tony.luck@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The PFM_LOAD_CONTEXT may fail silently and cause a session
to remain reserved even though it should not. This can happen
when the commands succeeds in reserving the session but fails
when it actually tries to attach to the load_pid. In that case,
the command has failed but will return 0. More importantly,
the session will remain reserved. This patch fixes the problem.

Signed-off-by: &lt;stephane.eranian@hp.com&gt;
Signed-off-by: Tony Luck &lt;tony.luck@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[IA64] fix nohalt boot option</title>
<updated>2005-08-08T22:39:47+00:00</updated>
<author>
<name>Ken Chen</name>
<email>kenneth.w.chen@intel.com</email>
</author>
<published>2005-08-08T22:25:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=fb573856b2d82926b36ed059899d883474a3b9eb'/>
<id>fb573856b2d82926b36ed059899d883474a3b9eb</id>
<content type='text'>
this changeset broke the "nohalt" kernel boot option.
  8df5a500a3e97f7811cdce0f553ca1917ccd4220

default_idle() is looking at new variable can_do_pal_halt.  However,
that variable did not get cleared upon "nohalt" boot option.  Result
is that "nohalt" option is ignored until perfmon is exercised.

Signed-off-by: Ken Chen &lt;kenneth.w.chen@intel.com&gt;
Signed-off-by: Tony Luck &lt;tony.luck@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
this changeset broke the "nohalt" kernel boot option.
  8df5a500a3e97f7811cdce0f553ca1917ccd4220

default_idle() is looking at new variable can_do_pal_halt.  However,
that variable did not get cleared upon "nohalt" boot option.  Result
is that "nohalt" option is ignored until perfmon is exercised.

Signed-off-by: Ken Chen &lt;kenneth.w.chen@intel.com&gt;
Signed-off-by: Tony Luck &lt;tony.luck@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[PATCH] remove sys_set_zone_reclaim()</title>
<updated>2005-08-01T17:03:56+00:00</updated>
<author>
<name>Ingo Molnar</name>
<email>mingo@elte.hu</email>
</author>
<published>2005-08-01T11:39:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=6cb54819d7b1867053e2dfd8c0ca3a8dc65a7eff'/>
<id>6cb54819d7b1867053e2dfd8c0ca3a8dc65a7eff</id>
<content type='text'>
This removes sys_set_zone_reclaim() for now.  While i'm sure Martin is
trying to solve a real problem, we must not hard-code an incomplete and
insufficient approach into a syscall, because syscalls are pretty much
for eternity.  I am quite strongly convinced that this syscall must not
hit v2.6.13 in its current form.

Firstly, the syscall lacks basic syscall design: e.g. it allows the
global setting of VM policy for unprivileged users. (!) [ Imagine an
Oracle installation and a SAP installation on the same NUMA box fighting
over the 'optimal' setting for this flag. What will they do? Will they
try to set the flag to their own preferred value every second or so? ]

Secondly, it was added based on a single datapoint from Martin:

 http://marc.theaimsgroup.com/?l=linux-mm&amp;m=111763597218177&amp;w=2

where Martin characterizes the numbers the following way:

 ' Run-to-run variability for "make -j" is huge, so these numbers aren't
   terribly useful except to see that with reclaim the benchmark still
   finishes in a reasonable amount of time. '

in other words: the fundamental problem has likely not been solved, only
a tendential move into the right direction has been observed, and a
handful of numbers were picked out of a set of hugely variable results,
without showing the variability data. How much variance is there
run-to-run?

I'd really suggest to first walk the walk and see what's needed to get
stable &amp; predictable kernel compilation numbers on that NUMA box, before
adding random syscalls to tune a particular aspect of the VM ... which
approach might not even matter once the whole picture has been analyzed
and understood!

The third, most important point is that the syscall exposes VM tuning
internals in a completely unstructured way. What sense does it make to
have a _GLOBAL_ per-node setting for 'should we go to another node for
reclaim'? If then it might make sense to do this per-app, via numalib or
so.

The change is minimalistic in that it doesnt remove the syscall and the
underlying infrastructure changes, only the user-visible changes.  We
could perhaps add a CAP_SYS_ADMIN-only sysctl for this hack, a'ka
/proc/sys/vm/swappiness, but even that looks quite counterproductive
when the generic approach is that we are trying to reduce the number of
external factors in the VM balance picture.

Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This removes sys_set_zone_reclaim() for now.  While i'm sure Martin is
trying to solve a real problem, we must not hard-code an incomplete and
insufficient approach into a syscall, because syscalls are pretty much
for eternity.  I am quite strongly convinced that this syscall must not
hit v2.6.13 in its current form.

Firstly, the syscall lacks basic syscall design: e.g. it allows the
global setting of VM policy for unprivileged users. (!) [ Imagine an
Oracle installation and a SAP installation on the same NUMA box fighting
over the 'optimal' setting for this flag. What will they do? Will they
try to set the flag to their own preferred value every second or so? ]

Secondly, it was added based on a single datapoint from Martin:

 http://marc.theaimsgroup.com/?l=linux-mm&amp;m=111763597218177&amp;w=2

where Martin characterizes the numbers the following way:

 ' Run-to-run variability for "make -j" is huge, so these numbers aren't
   terribly useful except to see that with reclaim the benchmark still
   finishes in a reasonable amount of time. '

in other words: the fundamental problem has likely not been solved, only
a tendential move into the right direction has been observed, and a
handful of numbers were picked out of a set of hugely variable results,
without showing the variability data. How much variance is there
run-to-run?

I'd really suggest to first walk the walk and see what's needed to get
stable &amp; predictable kernel compilation numbers on that NUMA box, before
adding random syscalls to tune a particular aspect of the VM ... which
approach might not even matter once the whole picture has been analyzed
and understood!

The third, most important point is that the syscall exposes VM tuning
internals in a completely unstructured way. What sense does it make to
have a _GLOBAL_ per-node setting for 'should we go to another node for
reclaim'? If then it might make sense to do this per-app, via numalib or
so.

The change is minimalistic in that it doesnt remove the syscall and the
underlying infrastructure changes, only the user-visible changes.  We
could perhaps add a CAP_SYS_ADMIN-only sysctl for this hack, a'ka
/proc/sys/vm/swappiness, but even that looks quite counterproductive
when the generic approach is that we are trying to reduce the number of
external factors in the VM balance picture.

Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[IA64] unwind.c uses wrong unat from switch_stack</title>
<updated>2005-07-27T21:18:08+00:00</updated>
<author>
<name>Keith Owens</name>
<email>kaos@sgi.com</email>
</author>
<published>2005-07-22T06:41:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=b833961bd30eec201b9a94eec36aa7ac96f9c9c0'/>
<id>b833961bd30eec201b9a94eec36aa7ac96f9c9c0</id>
<content type='text'>
unwind.c can read the wrong unat bits from switch_stack.
sw-&gt;caller_unat is the value of ar.unat when the task was blocked.
sw-&gt;ar_unat is the value of ar.unat after doing st8.spill for r4-7.
IOW, ar_unat is caller_unat with 4 bits changed.

unw_access_gr() uses sw-&gt;ar_unat for r4-7 (correct), but it also uses
sw-&gt;ar_unat for other scratch registers (incorrect).  sw-&gt;ar_unat
should only be used for r4-7, everything else should use
sw-&gt;caller_unat, unless modified by unwind info.  Using sw-&gt;ar_unat
risks picking up the 4 bits that were overwritten when r4-7 were saved.

Also this line is wrong
	unw.sw_off[unw.preg_index[UNW_REG_PFS]] = SW(AR_UNAT);
and should be
	unw.sw_off[unw.preg_index[UNW_REG_PFS]] = SW(AR_PFS);

Signed-off-by: Keith Owens &lt;kaos@sgi.com&gt;
Signed-off-by: Tony Luck &lt;tony.luck@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
unwind.c can read the wrong unat bits from switch_stack.
sw-&gt;caller_unat is the value of ar.unat when the task was blocked.
sw-&gt;ar_unat is the value of ar.unat after doing st8.spill for r4-7.
IOW, ar_unat is caller_unat with 4 bits changed.

unw_access_gr() uses sw-&gt;ar_unat for r4-7 (correct), but it also uses
sw-&gt;ar_unat for other scratch registers (incorrect).  sw-&gt;ar_unat
should only be used for r4-7, everything else should use
sw-&gt;caller_unat, unless modified by unwind info.  Using sw-&gt;ar_unat
risks picking up the 4 bits that were overwritten when r4-7 were saved.

Also this line is wrong
	unw.sw_off[unw.preg_index[UNW_REG_PFS]] = SW(AR_UNAT);
and should be
	unw.sw_off[unw.preg_index[UNW_REG_PFS]] = SW(AR_PFS);

Signed-off-by: Keith Owens &lt;kaos@sgi.com&gt;
Signed-off-by: Tony Luck &lt;tony.luck@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[IA64] inotify: ia64 syscalls.</title>
<updated>2005-07-27T17:46:12+00:00</updated>
<author>
<name>Robert Love</name>
<email>rml@novell.com</email>
</author>
<published>2005-07-27T15:58:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=d108919b2b5c064946c9bd30cbd4761d491cddb0'/>
<id>d108919b2b5c064946c9bd30cbd4761d491cddb0</id>
<content type='text'>
Attached patch adds the inotify syscalls to ia64.

Signed-off-by: Robert Love &lt;rml@novell.com&gt;
Signed-off-by: Tony Luck &lt;tony.luck@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Attached patch adds the inotify syscalls to ia64.

Signed-off-by: Robert Love &lt;rml@novell.com&gt;
Signed-off-by: Tony Luck &lt;tony.luck@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[PATCH] Don't export machine_restart, machine_halt, or machine_power_off.</title>
<updated>2005-07-26T21:35:42+00:00</updated>
<author>
<name>Eric W. Biederman</name>
<email>ebiederm@xmission.com</email>
</author>
<published>2005-07-26T17:36:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=59586e5a262a29361c45c929ea3253d4aec830b0'/>
<id>59586e5a262a29361c45c929ea3253d4aec830b0</id>
<content type='text'>
machine_restart, machine_halt and machine_power_off are machine
specific hooks deep into the reboot logic, that modules
have no business messing with.  Usually code should be calling
kernel_restart, kernel_halt, kernel_power_off, or
emergency_restart. So don't export machine_restart,
machine_halt, and machine_power_off so we can catch buggy users.

Signed-off-by: Eric W. Biederman &lt;ebiederm@xmission.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
machine_restart, machine_halt and machine_power_off are machine
specific hooks deep into the reboot logic, that modules
have no business messing with.  Usually code should be calling
kernel_restart, kernel_halt, kernel_power_off, or
emergency_restart. So don't export machine_restart,
machine_halt, and machine_power_off so we can catch buggy users.

Signed-off-by: Eric W. Biederman &lt;ebiederm@xmission.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[IA64] Fix undefined reference to can_cpei_retarget for simulator</title>
<updated>2005-07-14T16:21:47+00:00</updated>
<author>
<name>Ian Wienand</name>
<email>ianw@gelato.unsw.edu.au</email>
</author>
<published>2005-07-14T04:09:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=46906c4415f88cebfad530917bada0835d651824'/>
<id>46906c4415f88cebfad530917bada0835d651824</id>
<content type='text'>
The simulator build doesn't turn on ACPI, so doesn't have a definition
of can_cpei_retarget.

Signed-off-by: Tony Luck &lt;tony.luck@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The simulator build doesn't turn on ACPI, so doesn't have a definition
of can_cpei_retarget.

Signed-off-by: Tony Luck &lt;tony.luck@intel.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
