Hi Luis,
On Wed, Oct 4, 2017 at 8:20 AM, Luis R. Rodriguez wrote:
> So please retest now that the revert happened: commit
> f007cad159e99fa2acd3b2e9364fbb32ad28b971 ("Revert "firmware: add sanity check
> on shutdown/suspend").
I can confirm the issue is gone after the commit.
Also, thanks for yo
On Tue, Oct 3, 2017 at 5:20 PM, Luis R. Rodriguez wrote:
> the ordering devised currently there is:
>
> o device driver pm ops called
> o notifier for suspend issued - *going to suspend*
> o userspace frozen
> o filesystem freeze
>
> On the way back up this order is inverted:
>
> o files
On Mon, Oct 02, 2017 at 04:34:11PM +0800, Kai-Heng Feng wrote:
> Hi Luis,
>
> On Thu, Sep 14, 2017 at 1:39 AM, Luis R. Rodriguez wrote:
> [snipped]
> > Would a fw_cache_hint(device, name_list) be reasonable then sometime
> > *before*
> > suspend? All this would do is ask the firmware API to exte
Hi Luis,
On Thu, Sep 14, 2017 at 1:39 AM, Luis R. Rodriguez wrote:
[snipped]
> Would a fw_cache_hint(device, name_list) be reasonable then sometime *before*
> suspend? All this would do is ask the firmware API to extend the fw cache
> list with the entries. It would not load firmware immediately,
On Wed, Sep 13, 2017 at 08:52:15AM +0200, Marcel Holtmann wrote:
> > I checked and prior to commit 81f95076281f ("firmware: add sanity check on
> > shutdown/suspend") and commit 06a45a93e7d34aa ("firmware: move umh try locks
> > into the umh code") I believe we could end up also failing at a firmwa
Hi Luis,
If something needs to be fixed, can you make a patch showing that? Or
do we also need to revert anything else as well to get back to a "better
working" state?
>>>
>>> I took a look at the driver and it seems that btusb_setup_intel_new() is
>>> not called after the driver
On Mon, Sep 11, 2017 at 05:48:52PM -0700, Greg Kroah-Hartman wrote:
> On Mon, Sep 11, 2017 at 10:06:51PM +0200, Luis R. Rodriguez wrote:
> > On Mon, Sep 11, 2017 at 12:29:55PM -0700, Greg Kroah-Hartman wrote:
> > > On Mon, Sep 11, 2017 at 07:11:38PM +0200, Luis R. Rodriguez wrote:
> > > > On Mon, S
On Tue, Sep 12, 2017 at 07:13:42AM +0200, Marcel Holtmann wrote:
> >> If something needs to be fixed, can you make a patch showing that? Or
> >> do we also need to revert anything else as well to get back to a "better
> >> working" state?
> >
> > I took a look at the driver and it seems that btus
Hi Luis,
To confirm, reverting this fixes the problem I was seeing in 4.13. I've
queued it up for the next 4.13-stable release as well.
>>>
>>> Commit 81f95076281f ("firmware: add sanity check on shutdown/suspend") may
>>> seem kludgy but the reason for it was to cleanup the horrible f
On Mon, Sep 11, 2017 at 10:06:51PM +0200, Luis R. Rodriguez wrote:
> On Mon, Sep 11, 2017 at 12:29:55PM -0700, Greg Kroah-Hartman wrote:
> > On Mon, Sep 11, 2017 at 07:11:38PM +0200, Luis R. Rodriguez wrote:
> > > On Mon, Sep 11, 2017 at 06:46:47AM -0700, Greg Kroah-Hartman wrote:
> > > > To confir
On Mon, Sep 11, 2017 at 5:13 PM, Gabriel C wrote:
> On 11.09.2017 22:06, Luis R. Rodriguez wrote:
>>
>> On Mon, Sep 11, 2017 at 12:29:55PM -0700, Greg Kroah-Hartman wrote:
>>>
>>> On Mon, Sep 11, 2017 at 07:11:38PM +0200, Luis R. Rodriguez wrote:
On Mon, Sep 11, 2017 at 06:46:47AM -0700,
On 11.09.2017 22:06, Luis R. Rodriguez wrote:
On Mon, Sep 11, 2017 at 12:29:55PM -0700, Greg Kroah-Hartman wrote:
On Mon, Sep 11, 2017 at 07:11:38PM +0200, Luis R. Rodriguez wrote:
On Mon, Sep 11, 2017 at 06:46:47AM -0700, Greg Kroah-Hartman wrote:
To confirm, reverting this fixes the problem
On Mon, Sep 11, 2017 at 12:29:55PM -0700, Greg Kroah-Hartman wrote:
> On Mon, Sep 11, 2017 at 07:11:38PM +0200, Luis R. Rodriguez wrote:
> > On Mon, Sep 11, 2017 at 06:46:47AM -0700, Greg Kroah-Hartman wrote:
> > > To confirm, reverting this fixes the problem I was seeing in 4.13. I've
> > > queue
On Mon, Sep 11, 2017 at 07:11:38PM +0200, Luis R. Rodriguez wrote:
> On Mon, Sep 11, 2017 at 06:46:47AM -0700, Greg Kroah-Hartman wrote:
> > To confirm, reverting this fixes the problem I was seeing in 4.13. I've
> > queued it up for the next 4.13-stable release as well.
>
> Commit 81f95076281f (
On Mon, Sep 11, 2017 at 06:46:47AM -0700, Greg Kroah-Hartman wrote:
> On Mon, Sep 11, 2017 at 07:12:44AM +0200, Marcel Holtmann wrote:
> > Hi Linus,
> >
> > >> Yes 81f95076281f is to blame.. After reverting it all is fine again.
> > >>
> > >> 15 resume cycles on the one laptop , 10 on the other w
On Mon, Sep 11, 2017 at 07:12:44AM +0200, Marcel Holtmann wrote:
> Hi Linus,
>
> >> Yes 81f95076281f is to blame.. After reverting it all is fine again.
> >>
> >> 15 resume cycles on the one laptop , 10 on the other without to hit the
> >> trace.
> >
> > Yeah, I think that disable/enable_firmwar
Hi Linus,
>> Yes 81f95076281f is to blame.. After reverting it all is fine again.
>>
>> 15 resume cycles on the one laptop , 10 on the other without to hit the
>> trace.
>
> Yeah, I think that disable/enable_firmware in the suspend/resume path
> is basically just completely random code. There i
On Sun, Sep 10, 2017 at 8:49 PM, Gabriel C wrote:
>
> Yes 81f95076281f is to blame.. After reverting it all is fine again.
>
> 15 resume cycles on the one laptop , 10 on the other without to hit the
> trace.
Yeah, I think that disable/enable_firmware in the suspend/resume path
is basically just c
On 11.09.2017 05:15, Gabriel C wrote:
On 11.09.2017 03:25, Greg Kroah-Hartman wrote:
On Sun, Sep 10, 2017 at 12:26:02PM -0700, Linus Torvalds wrote:
This seems to be a new problem at resume for the Intel btusb driver,
but I'm not seeing anything in that driver itself that looks like a
likely tr
On 11.09.2017 03:25, Greg Kroah-Hartman wrote:
On Sun, Sep 10, 2017 at 12:26:02PM -0700, Linus Torvalds wrote:
This seems to be a new problem at resume for the Intel btusb driver,
but I'm not seeing anything in that driver itself that looks like a
likely trigger, so I wonder if it's some driver
On Sun, Sep 10, 2017 at 12:26:02PM -0700, Linus Torvalds wrote:
> This seems to be a new problem at resume for the Intel btusb driver,
> but I'm not seeing anything in that driver itself that looks like a
> likely trigger, so I wonder if it's some driver core change, a generic
> resume path issue,
This seems to be a new problem at resume for the Intel btusb driver,
but I'm not seeing anything in that driver itself that looks like a
likely trigger, so I wonder if it's some driver core change, a generic
resume path issue, or a workqueue change that has made it trigger for
me.
It might also ju
22 matches
Mail list logo
