Bug#822112: linux-image-4.5.0-1-686: [i686/GeodeLX] kernel 3.16 to 4.5 breaks X
2016-04-28 16:46 GMT+03:00 Ben Hutchings <ben@decadent.org.uk>:
> Control: tag -1 moreinfo
>
> I should note that userland modesetting is unlikely to be tested by
> many kernel and X developers any more. If you can get someone to work
> on a DRM/KMS driver for Geode, that is likely to keep these systems
> working longer.
Known issue. Sadly, Geode is a more or less abandoned platform.
Someone did start work on such a KMS driver at some point, but it
never got too far AFAIK. See https://gitorious.org/lx/lx
> As for the current regression:
>
>> [ 116.913187] x86/PAT: Xorg:998 map pfn expected mapping type uncached-minus for [mem 0xd0000000-0xd7ffffff], got write-combining
>> [ 116.913723] ------------[ cut here ]------------
>> [ 116.913761] WARNING: CPU: 0 PID: 998 at /build/linux-Efn4pv/linux-4.5.1/arch/x86/mm/pat.c:986 untrack_pfn+0xbf/0xd0()
>> [ 116.913773] Modules linked in: cpufreq_conservative(E) cpufreq_userspace(E) cpufreq_powersave(E) cpufreq_stats(E) scx200_acb(E) ecb(E) snd_cs5535audio(E) snd_ac97_codec(E) geode_aes(E) geode_rng(E) sg(E) rng_core(E) snd_pcm(E) snd_timer(E) snd(E) soundcore(E) ac97_bus(E) cs5535_mfd(E) acpi_cpufreq(E) tpm_tis(E) evdev(E) ac(E) tpm(E) processor(E) ecryptfs(E) cbc(E) hmac(E) encrypted_keys(E) parport_pc(E) ppdev(E) lp(E) parport(E) autofs4(E) msr(E) ext4(E) crc16(E) mbcache(E) jbd2(E) hid_generic(E) usbhid(E) hid(E) sd_mod(E) ata_generic(E) pata_cs5536(E) ohci_pci(E) ehci_pci(E) libata(E) ohci_hcd(E) ehci_hcd(E) usbcore(E) usb_common(E) 8139too(E) scsi_mod(E) 8139cp(E) mii(E) button(E)
>> [ 116.914011] CPU: 0 PID: 998 Comm: Xorg Tainted: G E 4.5.0-1-686 #1 Debian 4.5.1-1
>> [ 116.914026] Hardware name: First International Computer, Inc. ION603/ION603, BIOS 6.00 PG 11/08/2007
>> [ 116.914039] 00203286 6d1e16d9 f41a7d7c c12bdfdc 00000000 c1620568 c105b2bd c16279b0
>> [ 116.914075] 00000000 000003e6 c1620568 000003da c104f16f 00000009 c104f16f f416e630
>> [ 116.914110] aeb10000 00000000 f41a7d8c c105b3c2 00000009 00000000 f41a7db8 c104f16f
>> [ 116.914144] Call Trace:
>> [ 116.914172] [<c12bdfdc>] ? dump_stack+0x55/0x79
>> [ 116.914202] [<c105b2bd>] ? warn_slowpath_common+0x8d/0xc0
>> [ 116.914226] [<c104f16f>] ? untrack_pfn+0xbf/0xd0
>> [ 116.914248] [<c104f16f>] ? untrack_pfn+0xbf/0xd0
>> [ 116.914272] [<c105b3c2>] ? warn_slowpath_null+0x22/0x30
>> [ 116.914294] [<c104f16f>] ? untrack_pfn+0xbf/0xd0
>> [ 116.914327] [<c1174c73>] ? unmap_single_vma+0x673/0x680
>> [ 116.914355] [<c1175d93>] ? unmap_vmas+0x53/0xa0
>> [ 116.914379] [<c117bc8f>] ? exit_mmap+0x7f/0x140
>> [ 116.914406] [<c1058a07>] ? mmput+0x57/0xf0
>> [ 116.914430] [<c1059a36>] ? copy_process.part.34+0xa46/0x1440
>> [ 116.914458] [<c105a5f5>] ? _do_fork+0xe5/0x3d0
>> [ 116.914483] [<c105a9cc>] ? SyS_clone+0x2c/0x30
>> [ 116.914506] [<c1001aa0>] ? do_syscall_32_irqs_on+0x50/0xb0
>> [ 116.914533] [<c1540aed>] ? entry_INT80_32+0x31/0x31
>> [ 116.914551] ---[ end trace 1f55bc51b2556927 ]---
>
> This seems to indicate that the X server attempted to fork() and this
> failed. The warning comes from the failure path.
>
> Possibly it was trying to fork in order to run xkbcomp, as the X log
> shows that as being the fatal error:
>
> [...]
>> [ 246.214] (EE) XKB: Could not invoke xkbcomp
>> [ 246.216] (EE) XKB: Couldn't compile keymap
>> [ 246.217] (EE) XKB: Failed to load keymap. Loading default keymap instead.
> [...]
>
> Have you switched directly from 3.16 to 4.5? If so, could you test
> intermediate kernel versions from snapshot.debian.org, in order to
> narrow down where this regression was introduced?
That host runs testing so it pulls whatever is current. The break
occurred around 4.2 IIRC. As far as I can tell, it's the same
regression that affects some virtual machines such as the hypervisor.
Btw, adding "nopat" to cmdline works in a pinch, but it's obviously
only a workaround.
Martin-Éric
Reply to: