[arch-dev-public] kernel26 2.6.25-1 enters [testing]
The new 2.6.25 kernel and most of the external modules are in [testing]. Changes: - Complete configuration overhaul - Removed phc patch - Removed mactel patch The removal of these patches was because a) there are no new patches available for 2.6.25 and b) I am trying to reduce the amount of patching, especially if it only benefits a few people or can be potentially dangerous. If there are any problems due to the configuration changes or new kernel bugs, please let me know. If you want to know more about the real changes, read here: http://kernelnewbies.org/Linux_2_6_25 I didn't update any modules, so if there are new versions available for any, please inform their maintainers. The following modules are currently broken. I didn't do any research on those yet, so if anyone knows something, please let me know. - atl2 (Simo, could you have a look, you must probably update it) - catalyst - martian - openswan-klips - slmodem (USB symbols are now GPL only, this driver will never work again unless it's rewritten in userspace - is this only a USB driver or also a PCI driver?) I wish you all happy testing.
Thomas Bächler schrieb:
I didn't update any modules, so if there are new versions available for any, please inform their maintainers. The following modules are currently broken. I didn't do any research on those yet, so if anyone knows something, please let me know.
- atl2 (Simo, could you have a look, you must probably update it)
Stupid me: I was talking about aufs, not atl2. atl2 is fine.
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.
I wish you all happy testing.
It still runs. Happy enough ;) -S
On Sat, Apr 19, 2008 at 7:40 PM, Simo Leone <simo@archlinux.org> 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.
Travis Willard schrieb:
On Sat, Apr 19, 2008 at 7:40 PM, Simo Leone <simo@archlinux.org> 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.
On Sun, Apr 20, 2008 at 07:15:22PM +0200, =?ISO-8859-1?Q?Thomas_B=E4chler_ wrote:
Travis Willard schrieb:
On Sat, Apr 19, 2008 at 7:40 PM, Simo Leone <simo@archlinux.org> 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?
Upstream aufs came out today, I've uploaded the new version to testing for both architectures. It appears to work.
- 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.
OK, so I've looked into this one quite a bit, and I replied with an explanation in the bbs thread, which I'll repeat here, except more verbosely. The changes I already applied to the catalyst driver are fine and dandy, and work on all architectures. However, the catalyst driver also relies on a couple exported symbols that changed with this kernel release. The symbols in question are: - init_mm (from arch/x86/kernel/init_task.c) This symbol has been marked "unused" (which is kernel-speak for deprecated) and will disappear altogether in 2.6.26. As a result, this triggers a warning to dmesg when the module is loaded, but does not affect functionality. This is something for ATI to deal with, and not our concern. - flush_tlb_page (from arch/x86/kernel/smp_{32,64}.c) This symbol was unexported with no warning watsoever, and what's more, it was only unexported from smp_64.c . The patch that caused this was [1], which is just a "random cleanups" type of patch. Now, I looked into this issue quite a bit, and it turns out there's a lot of debate among kernel devs as to whether exports should just be removed without warning, or whether they should give one development cycle's worth of warning. I'm going to contact upstream about this particular issue (and probably start a firestorm, it appears to be a touchy subject), but in the meantime, our best course of action is to patch our -ARCH kernel and re-export the symbol until either a) the kernel changes (not gonna happen for a while), or b) the ATI guys that got screwed by this sudden change find a way not to use this function. To summarize: The changes I already applied to the catalyst module works on all architectures. The other change, unfortunately, needs to be made in kernel space (patch attached). -S [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=... diff --git a/arch/x86/kernel/smp_64.c b/arch/x86/kernel/smp_64.c index 2fd74b0..b3e6312 100644 --- a/arch/x86/kernel/smp_64.c +++ b/arch/x86/kernel/smp_64.c @@ -269,6 +269,7 @@ void flush_tlb_page(struct vm_area_struct * vma, unsigned long va) preempt_enable(); } +EXPORT_SYMBOL(flush_tlb_page); static void do_flush_tlb_all(void* info) {
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? And here is the mentioned part of the README: Cache Aliasing Cache aliasing occurs when multiple mappings to a physical page of memory have conflicting caching states, such as cached and uncached. Due to these conflicting states, data in that physical page may become corrupted when the processor's cache is flushed. If that page is being used for DMA by a driver such as NVIDIA's graphics driver, this can lead to hardware stability problems and system lockups. NVIDIA has encountered bugs with some Linux kernel versions that lead to cache aliasing. Although some systems will run perfectly fine when cache aliasing occurs, other systems will experience severe stability problems, including random lockups. Users experiencing stability problems due to cache aliasing will benefit from updating to a kernel that does not cause cache aliasing to occur. NVIDIA has added driver logic to detect cache aliasing and to print a warning with a message similar to the following: NVRM: bad caching on address 0x1cdf000: actual 0x46 != expected 0x73 If you see this message in your log files and are experiencing stability problems, you should update your kernel to the latest version. If the message persists after updating your kernel, send a bug report to NVIDIA. -- archlinux.de
Am Sun, 20 Apr 2008 10:27:02 +0200 schrieb Pierre Schmitz <pierre@archlinux.de>:
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
Am Sonntag, 20. April 2008 schrieb Andreas Radke:
Am Sun, 20 Apr 2008 10:27:02 +0200
schrieb Pierre Schmitz <pierre@archlinux.de>:
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
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?
On Sun, Apr 20, 2008 at 12:21 PM, Thomas Bächler <thomas@archlinux.org> 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
On 4/20/08, Dan McGee <dpmcgee@gmail.com> wrote:
On Sun, Apr 20, 2008 at 12:21 PM, Thomas Bächler <thomas@archlinux.org> 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.
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. 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?
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, 20 Apr 2008, Thomas Bächler wrote:
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.
+1 from me. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
On Sun, 2008-04-20 at 12:31 -0500, Dan McGee wrote:
On Sun, Apr 20, 2008 at 12:21 PM, Thomas Bächler <thomas@archlinux.org> 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 <kpiche@rogers.com>
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.
We have quite a few dual quad-core cpu boxes at work too.
participants (10)
-
Andreas Radke
-
Dan McGee
-
eliott
-
Eric Belanger
-
K. Piche
-
Pierre Schmitz
-
Simo Leone
-
Thomas Bächler
-
Tobias Powalowski
-
Travis Willard