<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/include, branch v2.6.27.26</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>IB/mlx4: Add strong ordering to local inval and fast reg work requests</title>
<updated>2009-07-02T23:31:47+00:00</updated>
<author>
<name>Jack Morgenstein</name>
<email>jackm@dev.mellanox.co.il</email>
</author>
<published>2009-06-05T17:36:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=ef01dc931edee0aff13604a74c9debb518bcc88c'/>
<id>ef01dc931edee0aff13604a74c9debb518bcc88c</id>
<content type='text'>
commit 2ac6bf4ddc87c3b6b609f8fa82f6ebbffeac12f4 upstream.

The ConnectX Programmer's Reference Manual states that the "SO" bit
must be set when posting Fast Register and Local Invalidate send work
requests.  When this bit is set, the work request will be executed
only after all previous work requests on the send queue have been
executed.  (If the bit is not set, Fast Register and Local Invalidate
WQEs may begin execution too early, which violates the defined
semantics for these operations)

This fixes the issue with NFS/RDMA reported in
&lt;http://lists.openfabrics.org/pipermail/general/2009-April/059253.html&gt;

Signed-off-by: Jack Morgenstein &lt;jackm@dev.mellanox.co.il&gt;
Signed-off-by: Roland Dreier &lt;rolandd@cisco.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 2ac6bf4ddc87c3b6b609f8fa82f6ebbffeac12f4 upstream.

The ConnectX Programmer's Reference Manual states that the "SO" bit
must be set when posting Fast Register and Local Invalidate send work
requests.  When this bit is set, the work request will be executed
only after all previous work requests on the send queue have been
executed.  (If the bit is not set, Fast Register and Local Invalidate
WQEs may begin execution too early, which violates the defined
semantics for these operations)

This fixes the issue with NFS/RDMA reported in
&lt;http://lists.openfabrics.org/pipermail/general/2009-April/059253.html&gt;

Signed-off-by: Jack Morgenstein &lt;jackm@dev.mellanox.co.il&gt;
Signed-off-by: Roland Dreier &lt;rolandd@cisco.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>firmware_map: fix hang with x86/32bit</title>
<updated>2009-07-02T23:31:31+00:00</updated>
<author>
<name>Yinghai Lu</name>
<email>yinghai@kernel.org</email>
</author>
<published>2009-06-16T22:31:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=18223acf5db925a001db7f6087eaacf0007235d0'/>
<id>18223acf5db925a001db7f6087eaacf0007235d0</id>
<content type='text'>
commit 3b0fde0fac19c180317eb0601b3504083f4b9bf5 upstream.

Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13484

Peer reported:
| The bug is introduced from kernel 2.6.27, if E820 table reserve the memory
| above 4G in 32bit OS(BIOS-e820: 00000000fff80000 - 0000000120000000
| (reserved)), system will report Int 6 error and hang up. The bug is caused by
| the following code in drivers/firmware/memmap.c, the resource_size_t is 32bit
| variable in 32bit OS, the BUG_ON() will be invoked to result in the Int 6
| error. I try the latest 32bit Ubuntu and Fedora distributions, all hit this
| bug.
|======
|static int firmware_map_add_entry(resource_size_t start, resource_size_t end,
|                  const char *type,
|                  struct firmware_map_entry *entry)

and it only happen with CONFIG_PHYS_ADDR_T_64BIT is not set.

it turns out we need to pass u64 instead of resource_size_t for that.

[akpm@linux-foundation.org: add comment]
Reported-and-tested-by: Peer Chen &lt;pchen@nvidia.com&gt;
Signed-off-by: Yinghai Lu &lt;yinghai@kernel.org&gt;
Cc: Ingo Molnar &lt;mingo@elte.hu&gt;
Acked-by: H. Peter Anvin &lt;hpa@zytor.com&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 3b0fde0fac19c180317eb0601b3504083f4b9bf5 upstream.

Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13484

Peer reported:
| The bug is introduced from kernel 2.6.27, if E820 table reserve the memory
| above 4G in 32bit OS(BIOS-e820: 00000000fff80000 - 0000000120000000
| (reserved)), system will report Int 6 error and hang up. The bug is caused by
| the following code in drivers/firmware/memmap.c, the resource_size_t is 32bit
| variable in 32bit OS, the BUG_ON() will be invoked to result in the Int 6
| error. I try the latest 32bit Ubuntu and Fedora distributions, all hit this
| bug.
|======
|static int firmware_map_add_entry(resource_size_t start, resource_size_t end,
|                  const char *type,
|                  struct firmware_map_entry *entry)

and it only happen with CONFIG_PHYS_ADDR_T_64BIT is not set.

it turns out we need to pass u64 instead of resource_size_t for that.

[akpm@linux-foundation.org: add comment]
Reported-and-tested-by: Peer Chen &lt;pchen@nvidia.com&gt;
Signed-off-by: Yinghai Lu &lt;yinghai@kernel.org&gt;
Cc: Ingo Molnar &lt;mingo@elte.hu&gt;
Acked-by: H. Peter Anvin &lt;hpa@zytor.com&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ocfs2: fix i_mutex locking in ocfs2_splice_to_file()</title>
<updated>2009-05-20T05:20:15+00:00</updated>
<author>
<name>Miklos Szeredi</name>
<email>miklos@szeredi.hu</email>
</author>
<published>2009-04-14T17:48:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=770908db2adb9dcfa2dabf739ac4d59be7f91ddc'/>
<id>770908db2adb9dcfa2dabf739ac4d59be7f91ddc</id>
<content type='text'>
commit 328eaaba4e41a04c1dc4679d65bea3fee4349d86 upstream.

Rearrange locking of i_mutex on destination and call to
ocfs2_rw_lock() so locks are only held while buffers are copied with
the pipe_to_file() actor, and not while waiting for more data on the
pipe.

Signed-off-by: Miklos Szeredi &lt;mszeredi@suse.cz&gt;
Signed-off-by: Jens Axboe &lt;jens.axboe@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 328eaaba4e41a04c1dc4679d65bea3fee4349d86 upstream.

Rearrange locking of i_mutex on destination and call to
ocfs2_rw_lock() so locks are only held while buffers are copied with
the pipe_to_file() actor, and not while waiting for more data on the
pipe.

Signed-off-by: Miklos Szeredi &lt;mszeredi@suse.cz&gt;
Signed-off-by: Jens Axboe &lt;jens.axboe@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>splice: split up __splice_from_pipe()</title>
<updated>2009-05-20T05:20:14+00:00</updated>
<author>
<name>Miklos Szeredi</name>
<email>miklos@szeredi.hu</email>
</author>
<published>2009-04-14T17:48:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=89fd89c80b4b78862f5e5fa5c73855aade0907c7'/>
<id>89fd89c80b4b78862f5e5fa5c73855aade0907c7</id>
<content type='text'>
commit b3c2d2ddd63944ef2a1e4a43077b602288107e01 upstream.

Split up __splice_from_pipe() into four helper functions:

  splice_from_pipe_begin()
  splice_from_pipe_next()
  splice_from_pipe_feed()
  splice_from_pipe_end()

splice_from_pipe_next() will wait (if necessary) for more buffers to
be added to the pipe.  splice_from_pipe_feed() will feed the buffers
to the supplied actor and return when there's no more data available
(or if all of the requested data has been copied).

This is necessary so that implementations can do locking around the
non-waiting splice_from_pipe_feed().

This patch should not cause any change in behavior.

Signed-off-by: Miklos Szeredi &lt;mszeredi@suse.cz&gt;
Signed-off-by: Jens Axboe &lt;jens.axboe@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit b3c2d2ddd63944ef2a1e4a43077b602288107e01 upstream.

Split up __splice_from_pipe() into four helper functions:

  splice_from_pipe_begin()
  splice_from_pipe_next()
  splice_from_pipe_feed()
  splice_from_pipe_end()

splice_from_pipe_next() will wait (if necessary) for more buffers to
be added to the pipe.  splice_from_pipe_feed() will feed the buffers
to the supplied actor and return when there's no more data available
(or if all of the requested data has been copied).

This is necessary so that implementations can do locking around the
non-waiting splice_from_pipe_feed().

This patch should not cause any change in behavior.

Signed-off-by: Miklos Szeredi &lt;mszeredi@suse.cz&gt;
Signed-off-by: Jens Axboe &lt;jens.axboe@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mm: page_mkwrite change prototype to match fault</title>
<updated>2009-05-20T05:20:09+00:00</updated>
<author>
<name>Nick Piggin</name>
<email>npiggin@suse.de</email>
</author>
<published>2009-05-12T06:23:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=be05b43969cfca5b15df6b558b65a24aec25e61a'/>
<id>be05b43969cfca5b15df6b558b65a24aec25e61a</id>
<content type='text'>
commit c2ec175c39f62949438354f603f4aa170846aabb upstream


mm: page_mkwrite change prototype to match fault

Change the page_mkwrite prototype to take a struct vm_fault, and return
VM_FAULT_xxx flags.  There should be no functional change.

This makes it possible to return much more detailed error information to
the VM (and also can provide more information eg.  virtual_address to the
driver, which might be important in some special cases).

This is required for a subsequent fix.  And will also make it easier to
merge page_mkwrite() with fault() in future.

Signed-off-by: Nick Piggin &lt;npiggin@suse.de&gt;
Cc: Chris Mason &lt;chris.mason@oracle.com&gt;
Cc: Trond Myklebust &lt;trond.myklebust@fys.uio.no&gt;
Cc: Miklos Szeredi &lt;miklos@szeredi.hu&gt;
Cc: Steven Whitehouse &lt;swhiteho@redhat.com&gt;
Cc: Mark Fasheh &lt;mfasheh@suse.com&gt;
Cc: Joel Becker &lt;joel.becker@oracle.com&gt;
Cc: Artem Bityutskiy &lt;dedekind@infradead.org&gt;
Cc: Felix Blyakher &lt;felixb@sgi.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit c2ec175c39f62949438354f603f4aa170846aabb upstream


mm: page_mkwrite change prototype to match fault

Change the page_mkwrite prototype to take a struct vm_fault, and return
VM_FAULT_xxx flags.  There should be no functional change.

This makes it possible to return much more detailed error information to
the VM (and also can provide more information eg.  virtual_address to the
driver, which might be important in some special cases).

This is required for a subsequent fix.  And will also make it easier to
merge page_mkwrite() with fault() in future.

Signed-off-by: Nick Piggin &lt;npiggin@suse.de&gt;
Cc: Chris Mason &lt;chris.mason@oracle.com&gt;
Cc: Trond Myklebust &lt;trond.myklebust@fys.uio.no&gt;
Cc: Miklos Szeredi &lt;miklos@szeredi.hu&gt;
Cc: Steven Whitehouse &lt;swhiteho@redhat.com&gt;
Cc: Mark Fasheh &lt;mfasheh@suse.com&gt;
Cc: Joel Becker &lt;joel.becker@oracle.com&gt;
Cc: Artem Bityutskiy &lt;dedekind@infradead.org&gt;
Cc: Felix Blyakher &lt;felixb@sgi.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/i915: add support for G41 chipset</title>
<updated>2009-05-08T21:54:33+00:00</updated>
<author>
<name>Zhenyu Wang</name>
<email>zhenyu.z.wang@intel.com</email>
</author>
<published>2008-11-17T05:58:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=1beaf51ea30d9bc4c8b40391b230da59500835c2'/>
<id>1beaf51ea30d9bc4c8b40391b230da59500835c2</id>
<content type='text'>
commit 72021788678523047161e97b3dfed695e802a5fd upstream.

This had been delayed for some time due to failure to work on the one piece
of G41 hardware we had, and lack of success reports from anybody else.
Current hardware appears to be OK.

Signed-off-by: Zhenyu Wang &lt;zhenyu.z.wang@intel.com&gt;
[anholt: hand-applied due to conflicts with IGD patches]
Signed-off-by: Eric Anholt &lt;eric@anholt.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 72021788678523047161e97b3dfed695e802a5fd upstream.

This had been delayed for some time due to failure to work on the one piece
of G41 hardware we had, and lack of success reports from anybody else.
Current hardware appears to be OK.

Signed-off-by: Zhenyu Wang &lt;zhenyu.z.wang@intel.com&gt;
[anholt: hand-applied due to conflicts with IGD patches]
Signed-off-by: Eric Anholt &lt;eric@anholt.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: fix incorrect mask of PM No_Soft_Reset bit</title>
<updated>2009-05-02T17:25:03+00:00</updated>
<author>
<name>Yu Zhao</name>
<email>yu.zhao@intel.com</email>
</author>
<published>2009-02-25T05:15:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=7b91b355a659bba2075a6ce44e7cc79a45d31132'/>
<id>7b91b355a659bba2075a6ce44e7cc79a45d31132</id>
<content type='text'>
commit 998dd7c719f62dcfa91d7bf7f4eb9c160e03d817 upstream.

Reviewed-by: Matthew Wilcox &lt;matthew@wil.cx&gt;
Signed-off-by: Yu Zhao &lt;yu.zhao@intel.com&gt;
Signed-off-by: Jesse Barnes &lt;jbarnes@virtuousgeek.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 998dd7c719f62dcfa91d7bf7f4eb9c160e03d817 upstream.

Reviewed-by: Matthew Wilcox &lt;matthew@wil.cx&gt;
Signed-off-by: Yu Zhao &lt;yu.zhao@intel.com&gt;
Signed-off-by: Jesse Barnes &lt;jbarnes@virtuousgeek.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>add some long-missing capabilities to fs_mask</title>
<updated>2009-05-02T17:24:21+00:00</updated>
<author>
<name>Serge E. Hallyn</name>
<email>serue@us.ibm.com</email>
</author>
<published>2009-04-13T17:25:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=0b4f4f3a442e731c3916bde12a77db8e90667107'/>
<id>0b4f4f3a442e731c3916bde12a77db8e90667107</id>
<content type='text'>
upstream commit: 0ad30b8fd5fe798aae80df6344b415d8309342cc

When POSIX capabilities were introduced during the 2.1 Linux
cycle, the fs mask, which represents the capabilities which having
fsuid==0 is supposed to grant, did not include CAP_MKNOD and
CAP_LINUX_IMMUTABLE.  However, before capabilities the privilege
to call these did in fact depend upon fsuid==0.

This patch introduces those capabilities into the fsmask,
restoring the old behavior.

See the thread starting at http://lkml.org/lkml/2009/3/11/157 for
reference.

Note that if this fix is deemed valid, then earlier kernel versions (2.4
and 2.2) ought to be fixed too.

Changelog:
	[Mar 23] Actually delete old CAP_FS_SET definition...
	[Mar 20] Updated against J. Bruce Fields's patch

Reported-by: Igor Zhbanov &lt;izh1979@gmail.com&gt;
Signed-off-by: Serge E. Hallyn &lt;serue@us.ibm.com&gt;
Cc: stable@kernel.org
Cc: J. Bruce Fields &lt;bfields@citi.umich.edu&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Chris Wright &lt;chrisw@sous-sol.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
upstream commit: 0ad30b8fd5fe798aae80df6344b415d8309342cc

When POSIX capabilities were introduced during the 2.1 Linux
cycle, the fs mask, which represents the capabilities which having
fsuid==0 is supposed to grant, did not include CAP_MKNOD and
CAP_LINUX_IMMUTABLE.  However, before capabilities the privilege
to call these did in fact depend upon fsuid==0.

This patch introduces those capabilities into the fsmask,
restoring the old behavior.

See the thread starting at http://lkml.org/lkml/2009/3/11/157 for
reference.

Note that if this fix is deemed valid, then earlier kernel versions (2.4
and 2.2) ought to be fixed too.

Changelog:
	[Mar 23] Actually delete old CAP_FS_SET definition...
	[Mar 20] Updated against J. Bruce Fields's patch

Reported-by: Igor Zhbanov &lt;izh1979@gmail.com&gt;
Signed-off-by: Serge E. Hallyn &lt;serue@us.ibm.com&gt;
Cc: stable@kernel.org
Cc: J. Bruce Fields &lt;bfields@citi.umich.edu&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Chris Wright &lt;chrisw@sous-sol.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>sched: do not count frozen tasks toward load</title>
<updated>2009-05-02T17:24:19+00:00</updated>
<author>
<name>Nathan Lynch</name>
<email>ntl@pobox.com</email>
</author>
<published>2009-04-09T18:20:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=6219030cf41f307e3115fa689b0dee6e436130e7'/>
<id>6219030cf41f307e3115fa689b0dee6e436130e7</id>
<content type='text'>
upstream commit: e3c8ca8336707062f3f7cb1cd7e6b3c753baccdd

Freezing tasks via the cgroup freezer causes the load average to climb
because the freezer's current implementation puts frozen tasks in
uninterruptible sleep (D state).

Some applications which perform job-scheduling functions consult the
load average when making decisions.  If a cgroup is frozen, the load
average does not provide a useful measure of the system's utilization
to such applications.  This is especially inconvenient if the job
scheduler employs the cgroup freezer as a mechanism for preempting low
priority jobs.  Contrast this with using SIGSTOP for the same purpose:
the stopped tasks do not count toward system load.

Change task_contributes_to_load() to return false if the task is
frozen.  This results in /proc/loadavg behavior that better meets
users' expectations.

Signed-off-by: Nathan Lynch &lt;ntl@pobox.com&gt;
Acked-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Acked-by: Nigel Cunningham &lt;nigel@tuxonice.net&gt;
Tested-by: Nigel Cunningham &lt;nigel@tuxonice.net&gt;
Cc: containers@lists.linux-foundation.org
Cc: linux-pm@lists.linux-foundation.org
Cc: Matt Helsley &lt;matthltc@us.ibm.com&gt;
LKML-Reference: &lt;20090408194512.47a99b95@manatee.lan&gt;
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
Signed-off-by: Chris Wright &lt;chrisw@sous-sol.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
upstream commit: e3c8ca8336707062f3f7cb1cd7e6b3c753baccdd

Freezing tasks via the cgroup freezer causes the load average to climb
because the freezer's current implementation puts frozen tasks in
uninterruptible sleep (D state).

Some applications which perform job-scheduling functions consult the
load average when making decisions.  If a cgroup is frozen, the load
average does not provide a useful measure of the system's utilization
to such applications.  This is especially inconvenient if the job
scheduler employs the cgroup freezer as a mechanism for preempting low
priority jobs.  Contrast this with using SIGSTOP for the same purpose:
the stopped tasks do not count toward system load.

Change task_contributes_to_load() to return false if the task is
frozen.  This results in /proc/loadavg behavior that better meets
users' expectations.

Signed-off-by: Nathan Lynch &lt;ntl@pobox.com&gt;
Acked-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Acked-by: Nigel Cunningham &lt;nigel@tuxonice.net&gt;
Tested-by: Nigel Cunningham &lt;nigel@tuxonice.net&gt;
Cc: containers@lists.linux-foundation.org
Cc: linux-pm@lists.linux-foundation.org
Cc: Matt Helsley &lt;matthltc@us.ibm.com&gt;
LKML-Reference: &lt;20090408194512.47a99b95@manatee.lan&gt;
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
Signed-off-by: Chris Wright &lt;chrisw@sous-sol.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Fix misreporting of #cores as #hyperthreads for Q9550</title>
<updated>2009-03-23T22:00:04+00:00</updated>
<author>
<name>Joe Korty</name>
<email>joe.korty@ccur.com</email>
</author>
<published>2009-03-19T17:27:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=55ec5cadc315fee6950e5a04d54694da3baf2f69'/>
<id>55ec5cadc315fee6950e5a04d54694da3baf2f69</id>
<content type='text'>
Fix misreporting of #cores for the Intel Quad Core Q9550.

For the Q9550, in x86_64 mode, /proc/cpuinfo mistakenly
reports the #cores present as the #hyperthreads present.
i386 mode was not examined but is assumed to have the
same problem.

A backport of the following three 2.6.29-rc1 patches
fixes the problem:
  066941bd4eeb159307a5d7d795100d0887c00442:
    [PATCH] x86: unmask CPUID levels on Intel CPUs
  99fb4d349db7e7dacb2099c5cc320a9e2d31c1ef:
    [PATCH] x86: unmask CPUID levels on Intel CPUs, fix
  bdf21a49bab28f0d9613e8d8724ef9c9168b61b9:
    [PATCH] x86: add MSR_IA32_MISC_ENABLE bits to &lt;asm/msr-index.h&gt;

From the first patch: "If the CPUID limit bit in
MSR_IA32_MISC_ENABLE is set, clear it to make all CPUID
information available.  This is required for some features
to work, in particular XSAVE."

Originally-Developed-by: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
Backported-by: Joe Korty &lt;joe.korty@ccur.com&gt;
Cc: Ingo Molnar &lt;mingo@elte.hu&gt;
Signed-off-by: Joe Korty &lt;joe.korty@ccur.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fix misreporting of #cores for the Intel Quad Core Q9550.

For the Q9550, in x86_64 mode, /proc/cpuinfo mistakenly
reports the #cores present as the #hyperthreads present.
i386 mode was not examined but is assumed to have the
same problem.

A backport of the following three 2.6.29-rc1 patches
fixes the problem:
  066941bd4eeb159307a5d7d795100d0887c00442:
    [PATCH] x86: unmask CPUID levels on Intel CPUs
  99fb4d349db7e7dacb2099c5cc320a9e2d31c1ef:
    [PATCH] x86: unmask CPUID levels on Intel CPUs, fix
  bdf21a49bab28f0d9613e8d8724ef9c9168b61b9:
    [PATCH] x86: add MSR_IA32_MISC_ENABLE bits to &lt;asm/msr-index.h&gt;

From the first patch: "If the CPUID limit bit in
MSR_IA32_MISC_ENABLE is set, clear it to make all CPUID
information available.  This is required for some features
to work, in particular XSAVE."

Originally-Developed-by: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
Backported-by: Joe Korty &lt;joe.korty@ccur.com&gt;
Cc: Ingo Molnar &lt;mingo@elte.hu&gt;
Signed-off-by: Joe Korty &lt;joe.korty@ccur.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
</feed>
