Summary: | [drm-gem] kernel modules fail to build against 2.6.26-rc7 | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | DRI | Reporter: | Johannes Engel <jcnengel> | ||||||||
Component: | DRM/other | Assignee: | Default DRI bug account <dri-devel> | ||||||||
Status: | RESOLVED WORKSFORME | QA Contact: | |||||||||
Severity: | blocker | ||||||||||
Priority: | medium | CC: | camaradetux, s_j_newbury | ||||||||
Version: | DRI git | Keywords: | NEEDINFO | ||||||||
Hardware: | x86 (IA32) | ||||||||||
OS: | Linux (All) | ||||||||||
Whiteboard: | |||||||||||
i915 platform: | i915 features: | ||||||||||
Attachments: |
|
Description
Johannes Engel
2008-06-23 04:00:02 UTC
Created attachment 17328 [details] [review] Add shmem_getpage declaration to make i915-gem part build This is a very rough sketch of what we need to make the i915 driver build again. Yup, that's correct. We're working to finish off the kernel changes needed to support GEM, right now we need shmem_file_setup and shmem_getpage. Created attachment 17329 [details] [review] Patch against drm-gem This one is to apply on top of the patch above and makes drm kernel module for i915 compile against kernel >= 2.6.26. Since 2.6.26-rc8 we will also have to replace init_mm which is no more exported. Is there a public kernel repository or a set of patches against a specific kernel that can be used for building a working drm-gem stack? Take the patches shown here against the kernel or have a look at Eric's kernel branch drm-gem at http://cgit.freedesktop.org/~anholt/linux-2.6/. For kernels from 2.6.27 you need additional patches for drm which can be found on the dri-devel mailinglist (<488F8946.8000605@googlemail.com> and <48905C63.3020606@googlemail.com>). (In reply to comment #6) > Take the patches shown here against the kernel or have a look at Eric's kernel > branch drm-gem at http://cgit.freedesktop.org/~anholt/linux-2.6/. > For kernels from 2.6.27 you need additional patches for drm which can be found > on the dri-devel mailinglist (<488F8946.8000605@googlemail.com> and > <48905C63.3020606@googlemail.com>). > When building drm-gem Mesa for 32bit on amd64 I get the following failure (DRM built sucessfully with mostly the above patches): intel_ioctl.c:189: error: two or more data types in declaration specifiers intel_ioctl.c:193: error: expected identifier or '(' before '{' token gmake[5]: *** [intel_ioctl.o] Error 1 gmake[5]: *** Waiting for unfinished jobs.... gmake[5]: Leaving directory `/var/tmp/portage/media-libs/mesa-9999/work/builddir.x86/src/mesa/drivers/dri/i965' Created attachment 18005 [details] [review] patch to remove double data type in declaration Try with this patch please. (In reply to comment #7) > (In reply to comment #6) > > Take the patches shown here against the kernel or have a look at Eric's kernel > > branch drm-gem at http://cgit.freedesktop.org/~anholt/linux-2.6/. > > For kernels from 2.6.27 you need additional patches for drm which can be found > > on the dri-devel mailinglist (<488F8946.8000605@googlemail.com> and > > <48905C63.3020606@googlemail.com>). > > > When building drm-gem Mesa for 32bit on amd64 I get the following failure (DRM > built sucessfully with mostly the above patches): > > intel_ioctl.c:189: error: two or more data types in declaration specifiers > intel_ioctl.c:193: error: expected identifier or '(' before '{' token > gmake[5]: *** [intel_ioctl.o] Error 1 > gmake[5]: *** Waiting for unfinished jobs.... > gmake[5]: Leaving directory > `/var/tmp/portage/media-libs/mesa-9999/work/builddir.x86/src/mesa/drivers/dri/i965' > Looking at the code I realise I should have ttm-api enabled.. (I assumed that was only for TTM). It builds now. (In reply to comment #8) > Created an attachment (id=18005) [details] > patch to remove double data type in declaration > > Try with this patch please. > Should I not have enabled ttm-api? (In reply to comment #10) > (In reply to comment #8) > > Created an attachment (id=18005) [details] [details] > > patch to remove double data type in declaration > > > > Try with this patch please. > > > > Should I not have enabled ttm-api? > Without ttm-api, it still fails with: intel_ioctl.c:193: error: expected identifier or '(' before '{' token gmake[5]: *** [intel_ioctl.o] Error 1 This is against 2.6.26, but I hit the same problem last time I tried testing drm-gem Server startup fails and the kernel produces the following backtrace: Jul 30 18:00:18 infinity [drm:i915_gem_init_ringbuffer] *ERROR* Failed to map ringbuffer. Jul 30 18:00:18 infinity ------------[ cut here ]------------ Jul 30 18:00:18 infinity kernel BUG at /var/tmp/portage/x11-base/x11-drm-99999999/work/drm/linux-core/drm_gem.c:378! Jul 30 18:00:18 infinity invalid opcode: 0000 [1] PREEMPT SMP Jul 30 18:00:18 infinity CPU 0 Jul 30 18:00:18 infinity Modules linked in: snd_pcm_oss snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device fuse bridge llc bnep rfcomm l2cap cpufreq_ondemand acpi_cpufreq coretemp smsc47m192 hwmon_vid i915 drm tpm_tis tpm tpm_bios rfkill arc4 ecb hci_usb iwl3945 bluetooth snd_hda_intel mac80211 led_class snd_pcm firewire_ohci snd_timer firewire_core cfg80211 snd_page_alloc snd_hwdep crc_itu_t snd yenta_socket pcspkr rsrc_nonstatic tg3 pcmcia_core soundcore joydev [last unloaded: microcode] Jul 30 18:00:18 infinity Pid: 4193, comm: X Not tainted 2.6.26-gentoo-gem #3 Jul 30 18:00:18 infinity RIP: 0010:[<ffffffffa01620ba>] [<ffffffffa01620ba>] :drm:drm_gem_object_free+0x13/0x52 Jul 30 18:00:18 infinity RSP: 0018:ffff810078d5fbe8 EFLAGS: 00010246 Jul 30 18:00:18 infinity RAX: 0000000000000001 RBX: ffff81007cca5000 RCX: 0000000000000000 Jul 30 18:00:18 infinity RDX: 0000000000000000 RSI: 0000000000000040 RDI: ffff81007aa00c80 Jul 30 18:00:18 infinity RBP: ffff81007aa00c80 R08: ffffffff806fffc0 R09: ffff81000101ff98 Jul 30 18:00:18 infinity R10: 0000000707194074 R11: 0000000000000046 R12: ffff81007c023d20 Jul 30 18:00:18 infinity R13: 0000000000000000 R14: ffff81007cca5000 R15: ffff81007cca3000 Jul 30 18:00:18 infinity FS: 00007f2107972760(0000) GS:ffffffff80748000(0000) knlGS:0000000000000000 Jul 30 18:00:18 infinity CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jul 30 18:00:18 infinity CR2: 00000000004c65d0 CR3: 0000000078d8f000 CR4: 00000000000006e0 Jul 30 18:00:18 infinity DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Jul 30 18:00:18 infinity DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Jul 30 18:00:18 infinity Process X (pid: 4193, threadinfo ffff810078d5e000, task ffff810078d4c100) Jul 30 18:00:18 infinity Stack: 0000000000020000 ffff81007aa00c80 ffffffffa01620a7 ffffffff803d5129 Jul 30 18:00:18 infinity 0000000000000000 ffff81007cca3000 ffff81007aa00c80 ffffffffa0180a31 Jul 30 18:00:18 infinity ffff810078d5fde8 ffff81007c849b40 ffff8100799f6350 ffffffffa018a648 Jul 30 18:00:18 infinity Call Trace: Jul 30 18:00:18 infinity [<ffffffffa01620a7>] ? :drm:drm_gem_object_free+0x0/0x52 Jul 30 18:00:18 infinity [<ffffffff803d5129>] ? kref_put+0x41/0x4c Jul 30 18:00:18 infinity [<ffffffffa0180a31>] ? :i915:i915_gem_entervt_ioctl+0x2a5/0x3bf Jul 30 18:00:18 infinity [<ffffffffa018078c>] ? :i915:i915_gem_entervt_ioctl+0x0/0x3bf Jul 30 18:00:18 infinity [<ffffffffa0153990>] ? :drm:drm_unlocked_ioctl+0x19b/0x216 Jul 30 18:00:18 infinity [<ffffffff8038accc>] ? xfs_iunlock+0x1d/0x7c Jul 30 18:00:18 infinity [<ffffffff803aec7f>] ? xfs_write+0x6cd/0x6e8 Jul 30 18:00:18 infinity [<ffffffff80273532>] ? handle_mm_fault+0x39c/0x759 Jul 30 18:00:18 infinity [<ffffffff8028bd7b>] ? do_sync_write+0xce/0x113 Jul 30 18:00:18 infinity [<ffffffff80246a04>] ? getnstimeofday+0x38/0x92 Jul 30 18:00:18 infinity [<ffffffff8021fe24>] ? do_page_fault+0x47e/0x832 Jul 30 18:00:18 infinity [<ffffffff80244bfc>] ? ktime_get_ts+0x21/0x4a Jul 30 18:00:18 infinity [<ffffffff80244c31>] ? ktime_get+0xc/0x41 Jul 30 18:00:18 infinity [<ffffffff80228e6d>] ? hrtick_start_fair+0x11a/0x164 Jul 30 18:00:18 infinity [<ffffffff8020a9bb>] ? __switch_to+0x30c/0x31a Jul 30 18:00:18 infinity [<ffffffff80229b6e>] ? hrtick_set+0x8b/0x10a Jul 30 18:00:18 infinity [<ffffffffa0153a1c>] ? :drm:drm_ioctl+0x11/0x13 Jul 30 18:00:18 infinity [<ffffffff802979b6>] ? vfs_ioctl+0x56/0x6c Jul 30 18:00:18 infinity [<ffffffff80297bed>] ? do_vfs_ioctl+0x221/0x237 Jul 30 18:00:18 infinity [<ffffffff8028c6a7>] ? vfs_write+0x121/0x156 Jul 30 18:00:18 infinity [<ffffffff80297c40>] ? sys_ioctl+0x3d/0x5d Jul 30 18:00:18 infinity [<ffffffff8020bf0b>] ? system_call_after_swapgs+0x7b/0x80 Jul 30 18:00:18 infinity Jul 30 18:00:18 infinity Jul 30 18:00:18 infinity Code: e8 54 30 27 e0 48 c7 c6 a7 20 16 a0 48 89 df e8 45 30 27 e0 31 c0 5b c3 55 48 89 fd 53 48 83 ec 08 48 8b 5f 08 83 7b 28 01 75 04 <0f> 0b eb fe 48 8b 83 20 04 00 00 48 8b 80 10 01 00 00 48 85 c0 Jul 30 18:00:18 infinity RIP [<ffffffffa01620ba>] :drm:drm_gem_object_free+0x13/0x52 Jul 30 18:00:18 infinity RSP <ffff810078d5fbe8> Jul 30 18:00:18 infinity ---[ end trace d16fb1b1e78fea46 ]--- Jul 30 18:00:18 infinity [drm:drm_release] *ERROR* Device busy: 1 0 (In reply to comment #12) > This is against 2.6.26, but I hit the same problem last time I tried testing > drm-gem > i965GM (Dell Lattidude D830) (In reply to comment #13) > (In reply to comment #12) > > This is against 2.6.26, but I hit the same problem last time I tried testing > > drm-gem > > > i965GM (Dell Lattidude D830) > That would be "Latitude"! I don't know happened there! :) The GEM stuff's all disabled in drm.git and replaced with my linux-2.6 tree. Is there anything left in this bug that needs to be handled? From my point of view, everything works now. I just compiled the latest linux kernel, 2.6.27. Of course I've run into problems with init_mm being not exported. The comment near EXPORT_UNUSED_SYMBOL(init_mm) in the kernel still says it was to be absent of 2.6.26. So now the question, should I fill another bug for init_mm export or is this one sufficient ? You want to be using my drm-intel-next tree from kernel.org or airlied's drm-next, not drm.git. Currently I don't have problems, plus I don't need anything special beside a working randr so it's alright the way I'm currently running it. I'm rather worrying about future kernel releases which seem unlikely to make init_mm exportable. If you need testers, I'll be happy to help though. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.