2016-04-28 16:46 GMT+03:00 Ben Hutchings <[email protected]>: > 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
