RE: [Intel-gift] Linux 3.10-rc7
> I don't see mei_me_pci_suspend() calling mei_disable_interrupts() and > pci_disable_msi(). Suspend calls mei_reset with request for disabling interrupts I'm pretty sure I do free_irq and I do disable_msi in the suspend (Hope we are looking at the same code) 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. Again here we call mei_reset with request of enabling the interrupts > > 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. > Is the MSI disabled on your platform? > 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? If you don't have msi I think usually it is shared with some USB device, but I haven't seen that in my code I will check again. Would other resume block the interrupt line? > 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. Thanks for ideas I will check that points. Thanks Tomas > -- Shuah > > Shuah Khan, Linux Kernel Developer - Open Source Group Samsung Research > America (Silicon Valley) shuah...@samsung.com | (970) 672-0658 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [Intel-gift] Linux 3.10-rc7
I don't see mei_me_pci_suspend() calling mei_disable_interrupts() and pci_disable_msi(). Suspend calls mei_reset with request for disabling interrupts I'm pretty sure I do free_irq and I do disable_msi in the suspend (Hope we are looking at the same code) 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. Again here we call mei_reset with request of enabling the interrupts 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. Is the MSI disabled on your platform? 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? If you don't have msi I think usually it is shared with some USB device, but I haven't seen that in my code I will check again. Would other resume block the interrupt line? 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. Thanks for ideas I will check that points. Thanks Tomas -- Shuah Shuah Khan, Linux Kernel Developer - Open Source Group Samsung Research America (Silicon Valley) shuah...@samsung.com | (970) 672-0658 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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...@samsung.com | (970) 672-0658 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [Intel-gift] Linux 3.10-rc7
> > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [Intel-gift] Linux 3.10-rc7
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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...@samsung.com | (970) 672-0658 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
