<feed xmlns='http://www.w3.org/2005/Atom'>
<title>wireguard-linux/include/asm-alpha/percpu.h, branch stable</title>
<subtitle>WireGuard for the Linux kernel</subtitle>
<id>https://git.zx2c4.com/wireguard-linux/atom/include/asm-alpha/percpu.h?h=stable</id>
<link rel='self' href='https://git.zx2c4.com/wireguard-linux/atom/include/asm-alpha/percpu.h?h=stable'/>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/'/>
<updated>2008-08-15T16:19:40Z</updated>
<entry>
<title>alpha: move include/asm-alpha to arch/alpha/include/asm</title>
<updated>2008-08-15T16:19:40Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2008-08-15T16:19:40Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=024b246ed24492d6c2ee14c34d742b137fce1b94'/>
<id>urn:sha1:024b246ed24492d6c2ee14c34d742b137fce1b94</id>
<content type='text'>
Sam Ravnborg did the build-test that the direct header file move works,
I'm just committing it.

This is a pure move:

	mkdir arch/alpha/include
	git mv include/asm-alpha arch/alpha/include/asm

with no other changes.

Requested-and-tested-by: Sam Ravnborg &lt;sam@ravnborg.org&gt;
Cc: Richard Henderson &lt;rth@twiddle.net&gt;
Cc: Ivan Kokshaysky &lt;ink@jurassic.park.msu.ru&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>alpha: fix compile error in arch/alpha/mm/init.c</title>
<updated>2008-06-24T01:26:04Z</updated>
<author>
<name>Thorsten Kranzkowski</name>
<email>dl8bcu@dl8bcu.de</email>
</author>
<published>2008-06-23T20:57:22Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=72c6e251ed84b3a9cdfde6711191155c47bb2b9c'/>
<id>urn:sha1:72c6e251ed84b3a9cdfde6711191155c47bb2b9c</id>
<content type='text'>
Commit 9267b4b3880d00dc2dab90f1d817c856939114f7 ("alpha: fix module load
failures on smp (bug #10926)") causes a regression for my ev4
uniprocessor build:

  CC      arch/alpha/mm/init.o
/export/data/repositories/linux-2.6/arch/alpha/mm/init.c:34: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘typeof’
make[2]: *** [arch/alpha/mm/init.o] Error 1
make[1]: *** [arch/alpha/mm] Error 2
make: *** [sub-make] Error 2

This fixes it for me (compile and boot tested):

Signed-off-by: Thorsten Kranzkowski &lt;dl8bcu@dl8bcu.de&gt;
Acked-by: Ivan Kokshaysky &lt;ink@jurassic.park.msu.ru&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>alpha: fix module load failures on smp (bug #10926)</title>
<updated>2008-06-20T23:46:10Z</updated>
<author>
<name>Ivan Kokshaysky</name>
<email>ink@jurassic.park.msu.ru</email>
</author>
<published>2008-06-20T23:25:39Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=9267b4b3880d00dc2dab90f1d817c856939114f7'/>
<id>urn:sha1:9267b4b3880d00dc2dab90f1d817c856939114f7</id>
<content type='text'>
To calculate addresses of locally defined variables, GCC uses 32-bit
displacement from the GP. Which doesn't work for per cpu variables in
modules, as an offset to the kernel per cpu area is way above 4G.

The workaround is to force allocation of a GOT entry for per cpu variable
using ldq instruction with a 'literal' relocation.
I had to use custom asm/percpu.h, as a required argument magic doesn't
work with asm-generic/percpu.h macros.

Signed-off-by: Ivan Kokshaysky &lt;ink@jurassic.park.msu.ru&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>[PATCH] x86-64: Account for module percpu space separately from kernel percpu</title>
<updated>2007-05-02T17:27:11Z</updated>
<author>
<name>Jeremy Fitzhardinge</name>
<email>jeremy@goop.org</email>
</author>
<published>2007-05-02T17:27:11Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=b00742d399513a4100c24cc2accefdc1bb1e0b15'/>
<id>urn:sha1:b00742d399513a4100c24cc2accefdc1bb1e0b15</id>
<content type='text'>
Rather than using a single constant PERCPU_ENOUGH_ROOM, compute it as
the sum of kernel_percpu + PERCPU_MODULE_RESERVE.  This is now common
to all architectures; if an architecture wants to set
PERCPU_ENOUGH_ROOM to something special, then it may do so (ia64 is
the only one which does).

Signed-off-by: Jeremy Fitzhardinge &lt;jeremy@xensource.com&gt;
Signed-off-by: Andi Kleen &lt;ak@suse.de&gt;
Cc: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
Cc: Eric W. Biederman &lt;ebiederm@xmission.com&gt;
Cc: Andi Kleen &lt;ak@suse.de&gt;
</content>
</entry>
<entry>
<title>[PATCH] Alpha: increase PERCPU_ENOUGH_ROOM</title>
<updated>2007-02-11T18:51:19Z</updated>
<author>
<name>Aneesh Kumar K.V</name>
<email>aneesh.kumar@gmail.com</email>
</author>
<published>2007-02-10T09:43:22Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=65fdc8544f7d27df95256cbcfc2a53fa0fa38134'/>
<id>urn:sha1:65fdc8544f7d27df95256cbcfc2a53fa0fa38134</id>
<content type='text'>
Module loading on Alpha was failing with error "Could not allocate 8 bytes
percpu data".

Looking at dmesg we have the below error "No per-cpu room for modules."

Increase the PERCPU_ENOUGH_ROOM in a similar way as x86_64

Signed-off-by: Aneesh Kumar K.V &lt;aneesh.kumar@gmail.com&gt;
Cc: &lt;Jay.Estabrook@hp.com&gt;
Cc: Richard Henderson &lt;rth@twiddle.net&gt;
Cc: Ivan Kokshaysky &lt;ink@jurassic.park.msu.ru&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>Linux-2.6.12-rc2</title>
<updated>2005-04-16T22:20:36Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@ppc970.osdl.org</email>
</author>
<published>2005-04-16T22:20:36Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2'/>
<id>urn:sha1:1da177e4c3f41524e886b7f1b8a0c1fc7321cac2</id>
<content type='text'>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
</content>
</entry>
</feed>
