Re: [arch-dev-public] kernel26 2.6.25-1 enters [testing]

2008-04-28 Thread Tobias Powalowski
Am Sonntag, 20. April 2008 schrieb Andreas Radke:
 Am Sun, 20 Apr 2008 10:27:02 +0200

 schrieb Pierre Schmitz [EMAIL PROTECTED]:
  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 0x81007c91a000: actual 0x173 !=
  expected 0x17b
  NVRM: please see the README section on Cache Aliasing for more
  information NVRM: bad caching on address 0x81007c91b000: actual
  0x173 != expected 0x17b
  NVRM: bad caching on address 0x81007cbad000: actual 0x173 !=
  expected 0x17b
  NVRM: bad caching on address 0x81007cbb4000: actual 0x173 !=
  expected 0x17b
  NVRM: bad caching on address 0x81007cbb5000: actual 0x173 !=
  expected 0x17b
  NVRM: bad caching on address 0x81007cbb6000: actual 0x173 !=
  expected 0x17b
  NVRM: bad caching on address 0x81007cbb7000: actual 0x173 !=
  expected 0x17b
  NVRM: bad caching on address 0x81007cbb8000: actual 0x173 !=
  expected 0x17b
  NVRM: bad caching on address 0x81007cbb9000: actual 0x173 !=
  expected 0x17b
  NVRM: bad caching on address 0x81007cbba000: 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 0x81022ce78000: actual 0x173 != expected
 0x17b NVRM: please see the README section on Cache Aliasing for more
 information NVRM: bad caching on address 0x81022ce79000: actual 0x173
 != expected 0x17b NVRM: bad caching on address 0x81022ce7a000: actual
 0x173 != expected 0x17b NVRM: bad caching on address 0x81022ce7b000:
 actual 0x173 != expected 0x17b NVRM: bad caching on address
 0x81022ce7c000: actual 0x173 != expected 0x17b NVRM: bad caching on
 address 0x81022ce7d000: actual 0x173 != expected 0x17b NVRM: bad
 caching on address 0x81022ce7e000: actual 0x173 != expected 0x17b NVRM:
 bad caching on address 0x81022ce7f000: actual 0x173 != expected 0x17b
 NVRM: bad caching on address 0x81022c47a000: actual 0x173 != expected
 0x17b NVRM: bad caching on address 0x81022cac1000: 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
[EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part.


Re: [arch-dev-public] kernel26 2.6.25-1 enters [testing]

2008-04-21 Thread Simo Leone
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 [EMAIL PROTECTED] 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=16da2f93054fc379522b93afc71d49751bd8be2b
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)
 {


pgpzIqrGtKXcC.pgp
Description: PGP signature


Re: [arch-dev-public] kernel26 2.6.25-1 enters [testing]

2008-04-20 Thread 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 0x81007c91a000: actual 0x173 != expected 
0x17b
NVRM: please see the README section on Cache Aliasing for more information
NVRM: bad caching on address 0x81007c91b000: actual 0x173 != expected 
0x17b
NVRM: bad caching on address 0x81007cbad000: actual 0x173 != expected 
0x17b
NVRM: bad caching on address 0x81007cbb4000: actual 0x173 != expected 
0x17b
NVRM: bad caching on address 0x81007cbb5000: actual 0x173 != expected 
0x17b
NVRM: bad caching on address 0x81007cbb6000: actual 0x173 != expected 
0x17b
NVRM: bad caching on address 0x81007cbb7000: actual 0x173 != expected 
0x17b
NVRM: bad caching on address 0x81007cbb8000: actual 0x173 != expected 
0x17b
NVRM: bad caching on address 0x81007cbb9000: actual 0x173 != expected 
0x17b
NVRM: bad caching on address 0x81007cbba000: 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



Re: [arch-dev-public] kernel26 2.6.25-1 enters [testing]

2008-04-20 Thread Thomas Bächler

Travis Willard schrieb:

On Sat, Apr 19, 2008 at 7:40 PM, Simo Leone [EMAIL PROTECTED] 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.




signature.asc
Description: OpenPGP digital signature


Re: [arch-dev-public] kernel26 2.6.25-1 enters [testing]

2008-04-20 Thread Andreas Radke
Am Sun, 20 Apr 2008 10:27:02 +0200
schrieb Pierre Schmitz [EMAIL PROTECTED]:

 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 0x81007c91a000: actual 0x173 !=
 expected 0x17b
 NVRM: please see the README section on Cache Aliasing for more
 information NVRM: bad caching on address 0x81007c91b000: actual
 0x173 != expected 0x17b
 NVRM: bad caching on address 0x81007cbad000: actual 0x173 !=
 expected 0x17b
 NVRM: bad caching on address 0x81007cbb4000: actual 0x173 !=
 expected 0x17b
 NVRM: bad caching on address 0x81007cbb5000: actual 0x173 !=
 expected 0x17b
 NVRM: bad caching on address 0x81007cbb6000: actual 0x173 !=
 expected 0x17b
 NVRM: bad caching on address 0x81007cbb7000: actual 0x173 !=
 expected 0x17b
 NVRM: bad caching on address 0x81007cbb8000: actual 0x173 !=
 expected 0x17b
 NVRM: bad caching on address 0x81007cbb9000: actual 0x173 !=
 expected 0x17b
 NVRM: bad caching on address 0x81007cbba000: 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 0x81022ce78000: actual 0x173 != expected 0x17b
NVRM: please see the README section on Cache Aliasing for more information
NVRM: bad caching on address 0x81022ce79000: actual 0x173 != expected 0x17b
NVRM: bad caching on address 0x81022ce7a000: actual 0x173 != expected 0x17b
NVRM: bad caching on address 0x81022ce7b000: actual 0x173 != expected 0x17b
NVRM: bad caching on address 0x81022ce7c000: actual 0x173 != expected 0x17b
NVRM: bad caching on address 0x81022ce7d000: actual 0x173 != expected 0x17b
NVRM: bad caching on address 0x81022ce7e000: actual 0x173 != expected 0x17b
NVRM: bad caching on address 0x81022ce7f000: actual 0x173 != expected 0x17b
NVRM: bad caching on address 0x81022c47a000: actual 0x173 != expected 0x17b
NVRM: bad caching on address 0x81022cac1000: actual 0x173 !=
expected 0x17b

but seems to work fine so far.

-Andy



Re: [arch-dev-public] kernel26 2.6.25-1 enters [testing]

2008-04-19 Thread Thomas Bächler

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.



signature.asc
Description: OpenPGP digital signature


Re: [arch-dev-public] kernel26 2.6.25-1 enters [testing]

2008-04-19 Thread Simo Leone
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


pgps5Dbz7uAoq.pgp
Description: PGP signature


Re: [arch-dev-public] kernel26 2.6.25-1 enters [testing]

2008-04-19 Thread Travis Willard
On Sat, Apr 19, 2008 at 7:40 PM, Simo Leone [EMAIL PROTECTED] 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.