Travis Willard schrieb:

On Sat, Apr 19, 2008 at 7:40 PM, Simo Leone wrote:

...

On Sat, Apr 19, 2008 at 06:09:08PM +0200, =?ISO-8859-1?Q?Thomas_B=E4chler_ wrote:

...

- aufs (Simo, could you have a look, you must probably update it) I'll fix this very soon. It just needs a hug. I'm going to update this to a later snapshot (aufs doesn't really do releases). That alright?

...

- catalyst Got this one, had to patch 2 or 3 lines due to some api changes in 2.6.25, no big deal (tm). Also updated it to 8.4 while I was at it.

Holy crap you rule Simo. I have guests over this weekend and haven't really been able to look at it yet.

Apparently, our fix does not work on x86_64, see the thread in the Desktop section of our forum.

Am Sonntag, 20. April 2008 schrieb Andreas Radke:

Am Sun, 20 Apr 2008 10:27:02 +0200

schrieb Pierre Schmitz :

...

Am Samstag, 19. April 2008 18:09:08 schrieb Thomas Bächler:

...

If there are any problems due to the configuration changes or new kernel bugs, please let me know.

I got the following error when using the nvidia driver:

NVRM: bad caching on address 0xffff81007c91a000: actual 0x173 != expected 0x17b NVRM: please see the README section on Cache Aliasing for more information NVRM: bad caching on address 0xffff81007c91b000: actual 0x173 != expected 0x17b NVRM: bad caching on address 0xffff81007cbad000: actual 0x173 != expected 0x17b NVRM: bad caching on address 0xffff81007cbb4000: actual 0x173 != expected 0x17b NVRM: bad caching on address 0xffff81007cbb5000: actual 0x173 != expected 0x17b NVRM: bad caching on address 0xffff81007cbb6000: actual 0x173 != expected 0x17b NVRM: bad caching on address 0xffff81007cbb7000: actual 0x173 != expected 0x17b NVRM: bad caching on address 0xffff81007cbb8000: actual 0x173 != expected 0x17b NVRM: bad caching on address 0xffff81007cbb9000: actual 0x173 != expected 0x17b NVRM: bad caching on address 0xffff81007cbba000: actual 0x173 != expected 0x17b

Even when using the 173.08 beta driver which is meant for kernel 2.6.25 I got the same errors. Any ideas?

Same here:

NVRM: bad caching on address 0xffff81022ce78000: actual 0x173 != expected 0x17b NVRM: please see the README section on Cache Aliasing for more information NVRM: bad caching on address 0xffff81022ce79000: actual 0x173 != expected 0x17b NVRM: bad caching on address 0xffff81022ce7a000: actual 0x173 != expected 0x17b NVRM: bad caching on address 0xffff81022ce7b000: actual 0x173 != expected 0x17b NVRM: bad caching on address 0xffff81022ce7c000: actual 0x173 != expected 0x17b NVRM: bad caching on address 0xffff81022ce7d000: actual 0x173 != expected 0x17b NVRM: bad caching on address 0xffff81022ce7e000: actual 0x173 != expected 0x17b NVRM: bad caching on address 0xffff81022ce7f000: actual 0x173 != expected 0x17b NVRM: bad caching on address 0xffff81022c47a000: actual 0x173 != expected 0x17b NVRM: bad caching on address 0xffff81022cac1000: actual 0x173 != expected 0x17b

but seems to work fine so far.

-Andy

same here also got the warnings, but seems to work greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org

On Sun, Apr 20, 2008 at 12:21 PM, Thomas Bächler wrote:

Have a look at: http://bbs.archlinux.org/viewtopic.php?id=47390

According to the kernel configuration help, increasing the maximum number of CPUs from 4 to 8 will make the kernel 32KB bigger with no performance decrease.

Opinions?

I'd always rather these things go through the ML or a feature request, rather than a forum post. That way someone can actually trace the process. Sounds fine to me, although I don't think there is any point on i686 (who would run >4 cores there?). x86_64 makes sense though. -Dan

eliott schrieb:

Well.. if it isn't harmful in any way, and if we would do it on x86_64, then we should also do it on i686. Having as consistent a baseline as possible is good.

Agreed.

As to actually doing it, are there any ramifications due to the potential for tracking additional cpus (timeslice allocation algorithmic changes?) that would be a noticeable performance inpact for people running 2 or 4 cpus?

"This allows you to specify the maximum number of CPUs which this kernel will support. The maximum supported value is 255 and the minimum value which makes sense is 2. This is purely to save memory - each supported CPU adds approximately eight kilobytes to the kernel image." That's all they say about it.

On Sun, 2008-04-20 at 12:31 -0500, Dan McGee wrote:

On Sun, Apr 20, 2008 at 12:21 PM, Thomas Bächler wrote:

...

Have a look at: http://bbs.archlinux.org/viewtopic.php?id=47390

According to the kernel configuration help, increasing the maximum number of CPUs from 4 to 8 will make the kernel 32KB bigger with no performance decrease.

Opinions?

I'd always rather these things go through the ML or a feature request, rather than a forum post. That way someone can actually trace the process.

Sounds fine to me, although I don't think there is any point on i686 (who would run >4 cores there?). x86_64 makes sense though.

I've got some machines at work that have 4 dual core CPU's (cpuinfo shows 8 cpu's) running 32 bit Linux so it's not that wierd.

-Dan -- K. Piche