[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: