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

Simo Leone simo at archlinux.org
Tue Apr 22 00:47:42 EDT 2008

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 at 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

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).


-------------- next part --------------
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)
 static void do_flush_tlb_all(void* info)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://archlinux.org/pipermail/arch-dev-public/attachments/20080421/2c04ea51/attachment.pgp>

More information about the arch-dev-public mailing list