|
Hi! Now it's back again. After a number of unichrome user complaints I just compiled the via driver in today's linux-2.6 drm and get a kernel Oops after doing modprobe via rmmod via The last VIA-specific change was done sep 7th. If I check out a sep 8th drm and compile the via module, at least I can do 4 modprobs and rmmods before a kernel Oops. The big problem is that users are starting to report problems also when the X server initializes and they are not always reproducable. IMHO there is a need for a reasonably stable branch, and, again IMHO, it should be the trunk. Two points from the CVS policy page: I know I'm not a big contributor to dri / drm and may not have a big say, but with user complaints about kernel oopses piling up on the unichrome lists, the situation is becoming troublesome. Regards Thomas Stack trace of the latest one. Unable to handle kernel NULL pointer dereference at virtual address 00000000 printing eip: df86d1aa *pde = 00000000 Oops: 0000 [#1] CPU: 0 EIP: 0060:[<df86d1aa>] Tainted: GF VLI EFLAGS: 00010202 EIP is at __crc_via_fb_free+0x131f4b1b/0x131f4bb2 [via] eax: 00000000 ebx: dd835180 ecx: 00000062 edx: 00000001 esi: dd148800 edi: 0000000c ebp: d3b03f64 esp: d3b03f54 ds: 007b es: 007b ss: 0068 Process rmmod (pid: 3188, threadinfo=d3b02000 task=d466e760) Stack: 00000001 df8735a0 c0327818 00000000 d3b03fbc c0134d03 00000000 00616976 d3dc5de0 40019000 d3dc5de0 d3b03fa0 c0149e34 d3e825a0 d3dc5de0 d4937260 d3e825a0 d3e825c0 00000000 d3b03fbc c0149eb4 00e825a0 40018000 bffff7c8 Call Trace: [<c0134d03>] sys_delete_module+0x133/0x1c0 [<c0149e34>] do_munmap+0xf4/0x140 [<c0149eb4>] sys_munmap+0x34/0x60 [<c010b017>] syscall_call+0x7/0xb Code: 45 f0 00 00 00 00 31 d2 3b 10 0f 83 81 00 00 00 31 ff eb 1b 83 3b 01 74 48 8b 45 f0 83 c7 0c 40 89 45 f0 a1 3c 37 87 df 8b 55 f0 <3b> 10 73 62 8b 58 04 01 fb f6 05 34 37 87 df 01 8b 73 04 74 d4 |
- Re: Kernel Oopses in recent DRMs Thomas Hellstrom
- Re: Kernel Oopses in recent DRMs Jon Smirl
- Re: Kernel Oopses in recent DRMs Thomas Hellstrom
- Re: Kernel Oopses in recent DRMs Jon Smirl
- Re: Kernel Oopses in recent DRMs Jon Smirl
- Re: Kernel Oopses in recent DRMs Dieter N�tzel
- Re: Kernel Oopses in recent DRMs Thomas Hellstrom
- Re: Kernel Oopses in recent DRMs David Bronaugh
- Re: Kernel Oopses in recent DRM... Thomas Hellstrom
- Re: Kernel Oopses in recent DRMs Jon Smirl
- Re: Kernel Oopses in recent DRMs Ian Romanick
