linux-kernel - Re: [Intel-gift] Linux 3.10-rc7

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-id: <B8EFE96D1287C24090BAD9D858E15E617382FC@sisaex02sj>
Date:	Wed, 10 Jul 2013 17:42:12 +0000
From:	Shuah Khan <shuah.kh@...sung.com>
To:	"Winkler, Tomas" <tomas.winkler@...el.com>
Cc:	Daniel Vetter <daniel.vetter@...ll.ch>,
	intel-gfx <intel-gfx@...ts.freedesktop.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"shuahkhan@...il.com" <shuahkhan@...il.com>,
	Dave Airlie <airlied@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"rjw@...k.pl" <rjw@...k.pl>, Shuah Khan <shuah.kh@...sung.com>,
	"shuahkhan@...il.com" <shuahkhan@...il.com>
Subject: Re: [Intel-gift] Linux 3.10-rc7

On 07/10/2013 09:18 AM, Winkler, Tomas wrote:
>>> suspend complete.
>>>
>>> I can start bi-sect of this problem on intel-display scope if you
>>> would like me to. Please let me know if the bisect scope should be larger.
>>>
>>> -- Shuah
>>
>> I got finally an older system where this reproduces consistently, I'm trying to
>> root cause that now.
>> As soon I have something to test I will send it out.
>>
>
> I'm not sure why but I'm not able to get the interrupt from the device until all the devices has resumed after that the mei reset is successful and device work as expected.
> I need to fix the state machine so the reset won't go crazy on resetting  actually I did that and it reduces resets into two but I'm still trying to figure out what's going on.
> The regression coming from the fact that I've linearize the reset flow, it waits for interrupt to arrive, before that the flow gave up and  has restarted directly from the interrupt thread.
>
>
> Thanks
> Tomas
>
>

Tomas,

This might be a shot in the dark. Commit  mei: me: clear interrupts on 
the resume path (42f132febff3b7b42c6c9dbfc151f29233be3132), clears 
pending interrupts in mei_me_pci_resume(). Your comment about not seeing 
interrupt until mei reset is successful got me wondering, if clearing 
pending interrupts is causing this?

I don't see mei_me_pci_suspend() calling mei_disable_interrupts() and 
pci_disable_msi(). I don't see a call to mei_enable_interrupts() from 
mei_me_pci_resume(). I don't think mei_enable_interrupts() is used 
anywhere. pci_dev_msi_enabled() enables the interrupts in
mei_me_pci_resume() looks like.

However, I did notice one thing, if pci_dev_msi_enabled() returns false, 
request_threaded_irq() is called  with IRQF_SHARED. Again might just be 
fine, it leads me to the next question.

mei_me_pci_suspend() has code that runs after disabling interrupts. Does 
this need to be split into suspend() and suspend_noirq() ops, since the 
IRQ could be shared?

It is a possibility if pci_enable_msi() takes longer in resume path and 
pci_dev_msi_enabled() returns false, then IRQF_SHARED is requested.

Don't know if this helpful, but I thought I would ask just in case, it 
helps you think of something you didn't before. Please let me know if 
you need help gathering data from my system.

-- Shuah

Shuah Khan, Linux Kernel Developer - Open Source Group Samsung Research 
America (Silicon Valley) shuah.kh@...sung.com | (970) 672-0658
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/