From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 98417] TTM broken on 4.9-rc2 Date: Tue, 15 Nov 2016 03:01:40 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1724463096==" Return-path: Received: from culpepper.freedesktop.org (culpepper.freedesktop.org [131.252.210.165]) by gabe.freedesktop.org (Postfix) with ESMTP id 9734A6E0A9 for ; Tue, 15 Nov 2016 03:01:40 +0000 (UTC) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============1724463096== Content-Type: multipart/alternative; boundary="14791789000.c1A6949.6995"; charset="UTF-8" --14791789000.c1A6949.6995 Date: Tue, 15 Nov 2016 03:01:40 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.freedesktop.org/ Auto-Submitted: auto-generated https://bugs.freedesktop.org/show_bug.cgi?id=3D98417 --- Comment #7 from Adam J. Richter --- Agreeing with the previous comments that this is probably not a TTM problem= , I want to pass along that I have observed what is probably the same problem, = but with many kernel modules unrelated to TTM and graphics. I think it might be possible to work around the problem by disabling CONFIG_MODVERSIONS, but just have not had the time to try that yet. I suspect that this has something to do with the changes in symbol exports = that occurred in linux 4.9-rc1, which you can see if you do something like: diff -pruN linux-{4.8,4.9-rc1}/arch/x86/lib The symbols that I have had trouble with, such as memset, are ones that have had export declarations added to assembler sources (.S files). I see that = the entry for memset in the generated file Module.symvers is different. In Linux 4.8, it looks like this: 0xfb578fc5 memset vmlinux EXPORT_SYMBOL In Linux 4.9-rc1, it looks like this: 0x00000000 memset vmlinux EXPORT_SYMBOL As you can see, the first field, which I believe is some sort of checksum of the C function declaration, is all zeroes for memset in Linux 4.9-rc1. I am still looking into this, but I am posting now because I may need to set this task aside for a day or two and didn't want to delay in passing along information that I think might be helpful in resolving your problem. --=20 You are receiving this mail because: You are the assignee for the bug.= --14791789000.c1A6949.6995 Date: Tue, 15 Nov 2016 03:01:40 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.freedesktop.org/ Auto-Submitted: auto-generated

Comment= # 7 on bug 98417<= /a> from Adam J. Richter
Agreeing with the previous comments that this is probably not =
a TTM problem, I
want to pass along that I have observed what is probably the same problem, =
but
with many kernel modules unrelated to TTM and graphics.

I think it might be possible to work around the problem by disabling
CONFIG_MODVERSIONS, but just have not had the time to try that yet.

I suspect that this has something to do with the changes in symbol exports =
that
occurred in linux 4.9-rc1, which you can see if you do something like:

diff -pruN linux-{4.8,4.9-rc1}/arch/x86/lib

The symbols that I have had trouble with, such as memset, are ones that have
had export declarations added to assembler sources (.S files).  I see that =
the
entry for memset in the generated file Module.symvers is different.

In Linux 4.8, it looks like this:
0xfb578fc5      memset  vmlinux EXPORT_SYMBOL

In Linux 4.9-rc1, it looks like this:
0x00000000      memset  vmlinux EXPORT_SYMBOL

As you can see, the first field, which I believe is some sort of checksum of
the C function declaration, is all zeroes for memset in Linux 4.9-rc1.

I am still looking into this, but I am posting now because I may need to set
this task aside for a day or two and didn't want to delay in passing along
information that I think might be helpful in resolving your problem.


You are receiving this mail because:
  • You are the assignee for the bug.
= --14791789000.c1A6949.6995-- --===============1724463096== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============1724463096==--