Bug#835160: linux-image-4.6.0-1-amd64: touchpad support on Fujitsu LIFEBOOK E556 does not work with crc_enabled == 0
Package: src:linux
Version: 4.6.4-1
Severity: normal
Tags: upstream
The driver input/mouse/elantech.c provides already support for some Fujitsu
LIFEBOOK types. Same support is needed for "LIFEBOOK E556" too. After adding a
new section related to "LIFEBOOK E556" touchpad works fine.
root@black:~/myfixes/elantech# cat patch_elantech.c.diff
--- input/mouse/elantech.c 2016-07-11 18:30:07.0 +0200
+++ input.modified/mouse/elantech.c 2016-07-24 10:23:49.617447543 +0200
@@ -1123,6 +1123,7 @@
* Avatar AVIU-145A2 0x361f00? clickpad
* Fujitsu LIFEBOOK E544 0x470f00d0, 12, 09 2 hw buttons
* Fujitsu LIFEBOOK E554 0x570f0140, 14, 0c 2 hw buttons
+ * Fujitsu LIFEBOOK E556 0x570f01c0, 14, 0c 2 hw buttons
* Fujitsu T7250x470f0105, 12, 09 2 hw buttons
* Fujitsu H7300x570f00c0, 14, 0c 3 hw buttons (**)
* Gigabyte U2442 0x450f0158, 17, 0c 2 hw buttons
@@ -1514,6 +1515,13 @@
},
},
{
+ /* Fujitsu LIFEBOOK E556 does not work with crc_enabled == 0
*/
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "LIFEBOOK E556"),
+ },
+ },
+ {
/* Fujitsu LIFEBOOK E544 does not work with crc_enabled == 0
*/
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU"),
Please add this support to the kernel.
Regards
Edgar
-- Package-specific info:
** Version:
Linux version 4.6.0-1-amd64 (debian-kernel@lists.debian.org) (gcc version 5.4.0
20160609 (Debian 5.4.0-6) ) #1 SMP Debian 4.6.4-1 (2016-07-18)
** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.6.0-1-amd64
root=UUID=97878278-b8a7-458e-aa9b-4c94504d3638 ro quiet
** Tainted: OE (12288)
* Out-of-tree module has been loaded.
* Unsigned module has been loaded (currently expected).
** Kernel log:
[3.213476] intel_rapl: Found RAPL domain package
[3.213479] intel_rapl: Found RAPL domain core
[3.213481] intel_rapl: Found RAPL domain uncore
[3.213483] intel_rapl: Found RAPL domain dram
[3.213487] intel_rapl: RAPL package 0 domain package locked by BIOS
[3.213490] intel_rapl: RAPL package 0 domain dram locked by BIOS
[3.245410] FAT-fs (sda5): utf8 is not a recommended IO charset for FAT
filesystems, filesystem will be case sensitive!
[3.248696] random: nonblocking pool is initialized
[3.303908] ieee80211 phy0: Selected rate control algorithm 'iwl-mvm-rs'
[3.322843] Adding 19562492k swap on /dev/mapper/swap. Priority:-1
extents:1 across:19562492k SSFS
[3.348189] media: Linux media interface: v0.10
[3.352467] Linux video capture interface: v2.00
[3.355820] snd_hda_intel :00:1f.3: bound :00:02.0 (ops
i915_audio_component_bind_ops [i915])
[3.355854] fbcon: inteldrmfb (fb0) is primary device
[3.359547] uvcvideo: Found UVC 1.00 device FJ Camera (04f2:b413)
[3.368504] usb 1-6: USB disconnect, device number 3
[3.371267] cdc_mbim 1-6:2.12 wwan0: unregister 'cdc_mbim'
usb-:00:14.0-6, CDC MBIM
[3.380073] snd_hda_codec_realtek hdaudioC0D0: ALC255: SKU not ready
0x909701f0
[3.380495] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC255:
line_outs=1 (0x21/0x0/0x0/0x0/0x0) type:line
[3.380496] snd_hda_codec_realtek hdaudioC0D0:speaker_outs=1
(0x14/0x0/0x0/0x0/0x0)
[3.380498] snd_hda_codec_realtek hdaudioC0D0:hp_outs=1
(0x1b/0x0/0x0/0x0/0x0)
[3.380499] snd_hda_codec_realtek hdaudioC0D0:mono: mono_out=0x0
[3.380500] snd_hda_codec_realtek hdaudioC0D0:inputs:
[3.380501] snd_hda_codec_realtek hdaudioC0D0: Dock Mic=0x19
[3.380502] snd_hda_codec_realtek hdaudioC0D0: Mic=0x1a
[3.380503] snd_hda_codec_realtek hdaudioC0D0: Internal Mic=0x12
[3.392646] input: HDA Digital PCBeep as
/devices/pci:00/:00:1f.3/sound/card0/input19
[3.393478] input: HDA Intel PCH Dock Mic as
/devices/pci:00/:00:1f.3/sound/card0/input20
[3.393530] input: HDA Intel PCH Mic as
/devices/pci:00/:00:1f.3/sound/card0/input21
[3.393575] input: HDA Intel PCH Headphone as
/devices/pci:00/:00:1f.3/sound/card0/input22
[3.393611] input: HDA Intel PCH Dock Headphone as
/devices/pci:00/:00:1f.3/sound/card0/input23
[3.393652] input: HDA Intel PCH HDMI/DP,pcm=3 as
/devices/pci:00/:00:1f.3/sound/card0/input24
[3.393689] input: HDA Intel PCH HDMI/DP,pcm=7 as
/devices/pci:00/:00:1f.3/sound/card0/input25
[3.393733] input: HDA Intel PCH HDMI/DP,pcm=8 as
/devices/pci:00/:00:1f.3/sound/card0/input26
[3.400629] uvcvideo 1-8:1.0: Entity type for entity Extension 3 was not
initialized!
[3.400631] uvcvideo 1-8:1.0: Entity type for entity Processing 2 was not
initialized!
[3.400632] uvcvideo 1-8:1.0: Entity type for en
Bug#834505: arm64 boot failure with large physical memory range
On Mon, 2016-08-22 at 11:03 +0100, Leif Lindholm wrote: > > > I thought there was a control bit on ARMv8 too which made it cause a > > fault if the code loaded through, stored via, branched to etc an > > address with bits set between the maximum physical address bit and the > > bits architecturally reserved for tagging at the top end of the word, > > but perhaps my memory has simply fabricated that out of thing air? > > I don't remember if there's a dedicated bit for that, but certainly > > judicious use of TTBCR/TTBRn should be able to achieve the same. If it's possible then that seems like a good thing to do to me, to avoid surprises and to be consistent with other arches. OTOH as I now understand from Ard's response the problem here is not lack of masking, but rather too much masking. Ian.
Bug#834505: arm64 boot failure with large physical memory range
X-Debbugs-CC: ard.biesheu...@linaro.org On Sun, Aug 21, 2016 at 02:46:06PM +0100, Ben Hutchings wrote: > > > I seem to remember that AArch64 has the ill-advised rule that VA bits > > > outside the range of the current page table format are ignored, so > > > presumably you're concerned that the code relies on this. But since > > > other 64-bit architectures (at least x86, PowerPC and SPARC) behave > > > otherwise, I would expect semi-portable code to mask out the tag bits. OK, as per my reply to Ian's comment, I now understand your point here. If this is true, then that does reduce the scope of the problem. > > You're not wrong, but unfortunately the ability to write semi-portable > > code left the planet over a decade ago. For clarification - the > > problem is not with regards to code written specifically for arm64 and > > not verified with different MMU-configurations, but with code written > > for x86 and never tested on anything else. See my post to cross-distro > > last week (and the subsequent thread): > > https://lists.linaro.org/pipermail/cross-distro/2016-August/000838.html > > I already read that. I don't see the contradiction. > > > So simply adjusting the mmap range on Debian would result in us using > > less verified code paths without it helping with the problem at hand. > > What new code path would be used? Looking at the code, apparently none other than the one that sets /proc/sys/vm/mmap_rnd_bits, so fair enough. But this still scares me, as it still relies on software that has been proven to not be sane being sane. I would be much less nervous with an approach like the one suggested by Ard at: https://patchwork.kernel.org/patch/9292139/ But then maybe I'm just being too nervous. / Leif
Bug#834505: arm64 boot failure with large physical memory range
X-Debbugs-CC: ard.biesheu...@linaro.org On Sun, Aug 21, 2016 at 03:04:02PM +0100, Ian Campbell wrote: > On Sun, 2016-08-21 at 11:42 +0100, Leif Lindholm wrote: > > > > You're not wrong, but unfortunately the ability to write semi-portable > > code left the planet over a decade ago. For clarification - the > > problem is not with regards to code written specifically for arm64 and > > not verified with different MMU-configurations, but with code written > > for x86 and never tested on anything else. > > Wouldn't the equivalent scenario on x86 result in taking faults (#GP > IIRC) due to them being non-canonical addresses? (Which are basically > Intel's way of forbidding the use of bits above the physical address > size when registers are used in pointer-like ways, i.e. for > loads/stores or jump targets etc). Right so most of my confusion here was related to my belief that the address masking was in fact not correct in the first place. Speaking to Ard, that appears to not be the case here. > I thought there was a control bit on ARMv8 too which made it cause a > fault if the code loaded through, stored via, branched to etc an > address with bits set between the maximum physical address bit and the > bits architecturally reserved for tagging at the top end of the word, > but perhaps my memory has simply fabricated that out of thing air? I don't remember if there's a dedicated bit for that, but certainly judicious use of TTBCR/TTBRn should be able to achieve the same. / Leif
Bug#834505: arm64 boot failure with large physical memory range
On Sun, 21 Aug 2016 01:11:15 +0100 Ben Hutchings wrote: > On Fri, 2016-08-19 at 13:42 +0100, Leif Lindholm wrote: > > On Fri, Aug 19, 2016 at 12:50:49PM +0100, Ben Hutchings wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > everything using mozilla-js). > > > > > [...] > > > > > > > > > > Could we possibly work around that by reducing > > > > > CONFIG_ARCH_MMAP_RND_BITS_MAX? Â (That's not directly configurable; it > > > > > requires patching arch/arm64/Kconfig.) > > > > > > > > I think this would be opening up a real can of worms. Not all sizes > > > > are supported by the architecture, and only certain VA_BITS/pagesize > > > > combinations work in the kernel. > > > > > > > > We could switch to 42-bit VA, but that would require switching to 64K > > > > pagesize, which would be an even huger can. > > > > > > I'm not suggesting using any unusual page table configuration. Just > > > reducing the ASLR range that is currently implied by a 48-bit VA. > > > > But would that help anything? > > Even if you don't allocate to the top bits, if they're used for > > tagging, you'll still segfault. > > I seem to remember that AArch64 has the ill-advised rule that VA bits > outside the range of the current page table format are ignored, so > presumably you're concerned that the code relies on this. Â But since > other 64-bit architectures (at least x86, PowerPC and SPARC) behave > otherwise, I would expect semi-portable code to mask out the tag bits. > Indeed. The most likely failure mode (but we'd need to check to be sure) is that the JITs 'clean up' the addresses before dereferencing them by masking bits that have a special meaning to them, and inadvertently clear upper address bits in the process. My concern with changing CONFIG_ARCH_MMAP_RND_BITS_MAX is that it is not a guarantee that mmap() will not be called with explicit addr values in the problematic range. (In some cases, munmap() is used to detect the VA range, given that munmap() turns out to succeed for non-existent mappings unless the address value exceeds the VA size). It's unlikely that an affected JIT would do both things at the same time, i.e., steal upper address bits and perform mmap() allocations in the problematic range, but we'd need to confirm it nonetheless. -- Ard.
