prevent
> other possible race conditions.
>
> Fixes: 9488585b21bef0df12 ("tpm: add support for partial reads")
> Reported-by: Mantas Mikulėnas
> Signed-off-by: Tadeusz Struk
> ---
> drivers/char/tpm/tpm-dev-common.c |4 +++-
> 1 file changed, 3 insertions(+),
et a report to device.
[ 38.085221] hid-rmi 0018:06CB:2934.0003: failed to write hid report
(-110)
[ 38.085224] hid-rmi 0018:06CB:2934.0003: failed to write request
output report (-110)
[ 38.085229] rmi4_f54 rmi4-00.fn54: rmi_f54_work: read [722 bytes]
returned -110
---
--
Mantas Mikulėnas
ficant in newer versions of libinput and I
>>>> attached some evemu-record logs.
>>>>
>>>> https://bugs.freedesktop.org/show_bug.cgi?id=100436
>>>>
>>>> I also spent time looking into the kernel drivers to see if they were
>>>> causing or contributing to the jumps. One of the things that I tried was
>>>> calling rmi_irq_fn() from a workqueue instead of calling
>>>> generic_handle_irq(). Originally, we were using a workqueue before
>>>> interrupt
>>>> handling was added to the rmi core. I also tried moving the call to
>>>> generic_handle_irq() to a workqueue. In both cases the jumps seemed to
>>>> disappear or at least be reduced. I looked through the irq handling code
>>>> and
>>>> I did not see anything which should cause an issue. The only difference
>>>> between irq thread and the workqueue that I could think of is that the irq
>>>> thread runs at a higher priority. But, I didn't really see much of a
>>>> difference between the timing of the events in the evemu-record logs.
>>> Despite libinput having issues has reported by Peter, I wonder if the
>>> priority of the IRQ thread isn't the one interfering with the data here.
>>> In the workqueue version, the processing of the events didn't interfere
>>> with the retrieval of the I2C values. But with the IRQ thread, we might
>>> be delaying the retrieval of the values, and we might not be reading the
>>> correct value at the right time (oversimplifying it, but I think you get
>>> the gist of it). The 2 IRQ threads from I2C to read the data and the
>>> other one from RMI4 might simply be interfering.
>>>
>>> I am sure you have something equivalent in your tree, but could you
>>> confirm that the following patch removes the jumps?
>>
>> Yes, this patch does remove the jumps. My version just restored the old
>> functionality which was to call rmi_process_interrupts from a workqueue
>> inside hid-rmi. Your patch seems more complete.
>>
>> I did look to see if I could find something in the threaded IRQ code which
>> would confirm that there was some interference going on. But, I didn't find
>> anything. I also see jumps with USB devices and since USB devices do not use
>> threaded IRQs that did not seem to be the source. Looking at the call stack
>> in which rmi_input_event() gets called they seem quite different between USB
>> and I2C.
>>
>> I also tried calling generic_handle_irq() from a workqueue and that also
>> seemed to remove the jumps. That led me to look into if there were any side
>> affects from calling local_irq_save / restore or generic_handle_irq() from
>> inside the IRQ thread or IRQ handler. But, I could not find anything which
>> would indicate that doing this was unsafe.
>>
>> This is what I tried:
>> https://github.com/aduggan/linux/commit/d484e423e7375f1a6564f735f44a1246f6c0ee84
>
> Thanks. Your patch looks smaller than mine :)
>
> Jiri, Dmitry, which patch would you prefer having upstream?
>
> Andrew's patch is smaller but requires a workqueue in hid-rmi, which
> then reinject the IRQ in RMI4. Mine has the workqueue in RMI4 and
> ditches the IRQ in hid-rmi all together (so no need to call
> local_irq_save() anymore).
>
>>
>>> ---
>>>
>>> From b60c0b4f145e171e55ffd861a852a49f5104d59f Mon Sep 17 00:00:00 2001
>>> From: Benjamin Tissoires
>>> Date: Wed, 29 Mar 2017 10:41:34 +0200
>>> Subject: [PATCH] Input: rmi4 - remove the need for artificial IRQ in case of
>>> HID
>>>
>>> The IRQ from rmi4 may interfere with the one we currently use on i2c-hid.
>>> Given that there is already a need for an external API from rmi4 to
>>> forward the attention data, we can, in this particular case rely on a
>>> separate workqueue to prevent cursor jumps.
>>>
>>> Signed-off-by: Benjamin Tissoires
>>
>> Tested-by: Andrew Duggan
>
> Great :)
Hi,
Just checking – have any of these fixes been merged so far? I'm trying
out 4.14.0 right now, and while the jumps aren't as severe as before,
they still happen frequently enough that I'll be returning to 4.9-LTS
once again...
(Or is this something that libinput is supposed to deal with?)
--
Mantas Mikulėnas
The protocol field is checked when deleting IPv4 routes, but ignored for
IPv6, which causes problems with routing daemons accidentally deleting
externally set routes (observed by multiple bird6 users).
This can be verified using `ip -6 route del proto something`.
Signed-off-by: Mantas Mikulėnas
On Sat, Sep 6, 2014 at 11:09 PM, Mantas Mikulėnas wrote:
> On Sat, Sep 6, 2014 at 1:16 AM, Matt Fleming wrote:
>> On Thu, 04 Sep, at 01:59:05PM, H. Peter Anvin wrote:
>>>
>>> I am fine with this patch, but at the same time I do want to note that
>>> there is
in the upstream EDK2 DiskIO code in Aug 2013 which
> may possibly be related, commit 4e39b75e ("MdeModulePkg/DiskIoDxe: fix
> source/destination pointer of overrun transfer"). Whatever the cause,
> it's unlikely that a fix will be forthcoming from the vendor, hence the
> wor
This makes absolutely zero sense. Please explain what the actual
>> problem is here.
>
> The firmware has bug and can use buffer above 4G to read files.
> and if the file size is 512 bytes alignment, then reading could go through.
>
> From Mantas:
> --
> On Wed, Aug
On Fri, Aug 22, 2014 at 5:43 PM, Mantas Mikulėnas wrote:
>
> On Fri, Aug 22, 2014 at 5:24 PM, Harald Hoyer wrote:
> > On 09.08.2014 16:23, Mantas Mikulėnas wrote:
> >> As of commit 4bf7111f5016 ("x86/efi: Support initrd loaded above 4G"),
> >> the kernel
On Fri, Aug 22, 2014 at 5:24 PM, Harald Hoyer wrote:
> On 09.08.2014 16:23, Mantas Mikulėnas wrote:
>> As of commit 4bf7111f5016 ("x86/efi: Support initrd loaded above 4G"),
>> the kernel freezes at the earliest possible moment when trying to boot
>> via UEFI on
freeze, 5684736
bytes will not.
...In other words, seems like it cannot read chunks that aren't
multiples of 512 into a location above 4 GB. Or something like that...
--
Mantas Mikulėnas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On Wed, Aug 13, 2014 at 5:02 PM, Matt Fleming wrote:
>
> On Sun, 10 Aug, at 09:43:32PM, Mantas Mikulėnas wrote:
> > On Sun, Aug 10, 2014 at 8:55 AM, Yinghai Lu wrote:
> > > On Sat, Aug 9, 2014 at 3:45 PM, Mantas Mikulėnas
> > > wrote:
> > >> On
On Sun, Aug 10, 2014 at 8:55 AM, Yinghai Lu wrote:
> On Sat, Aug 9, 2014 at 3:45 PM, Mantas Mikulėnas wrote:
>> On Sat, Aug 9, 2014 at 10:23 PM, Matt Fleming wrote:
>> [However... Whether it's five chunks, four (after making the initrd
>> smaller), or just one (with yo
On Sat, Aug 9, 2014 at 10:23 PM, Matt Fleming wrote:
>
> On Sat, 09 Aug, at 09:44:55AM, Yinghai Lu wrote:
> > On Sat, Aug 9, 2014 at 7:23 AM, Mantas Mikulėnas wrote:
> > > As of commit 4bf7111f5016 ("x86/efi: Support initrd loaded above 4G"),
> > > the
ough I see "setup_efi_pci() failed" being printed].
(Seems like it freezes when handle_cmdline_files() attempts to read
the last chunk of the initramfs -- the last call to efi_file_read()
never returns. Figuring out why that happens is beyond me, though.)
--
Mantas Mikulėnas
--
To unsubs
On Thu, Apr 24, 2014 at 1:51 PM, Rafael J. Wysocki wrote:
> On Thursday, April 24, 2014 06:21:52 AM Sitsofe Wheeler wrote:
>> On Thu, Apr 17, 2014 at 02:11:15PM +0300, Mantas Mikulėnas wrote:
>> > After commit 1a699476e258 [two months ago], Linux has stopped
>> > recog
as 3.14-rc1 if they're after 3.14?)
The kernel config is close to that of stock Arch Linux, except with
entirely irrelevant devices disabled (PATA, SCSI, tuner, etc.)
--
Mantas Mikulėnas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
th
, I added that URL and queued up these patches. I'll wait to
> push them until we have confirmation from Mantas [1] and Chris [2]
> that this fixes it for both.
Tested the three patches on top of v3.9-rc4-134-gb175293, works fine.
[the first patch refers to reverting commit f4eb5ff05, w
ons probably makes sense, though. Something like this (entirely
>> untested)?
>
> This looks reasonable. Mantas?
It compiles, boots, and even makes the graphics card work again.
So it looks good to me.
--
Mantas Mikulėnas
--
To unsubscribe from this list: send the line "unsubscribe
s: 5
(dbg) rom->device: 0, rom->function: 5
(dbg) rom->vendor: 197b, rom->devid: 250
(dbg) -
pci :05:00.5: System wakeup disabled by ACPI
--
Mantas Mikulėnas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
On 2013-02-22 03:03, Mantas Mikulėnas wrote:
> On 2013-02-22 01:54, Dave Airlie wrote:
>>>
>>> | radeon :01:00.0: No connectors reported connected with modes
>>> | [drm] Cannot find any crtc or sizes - going 1024x768
>>>
>>> The connector is def
20 matches
Mail list logo
