Re: btusb "firmware request while host is not available" at resume

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.

Re: btusb "firmware request while host is not available" at resume

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

Re: btusb "firmware request while host is not available" at resume

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

Re: btusb "firmware request while host is not available" at resume

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

Re: btusb "firmware request while host is not available" at resume

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

Re: btusb "firmware request while host is not available" at resume

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

Re: btusb "firmware request while host is not available" at resume

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

Re: btusb "firmware request while host is not available" at resume

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

Re: btusb "firmware request while host is not available" at resume

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

Re: btusb "firmware request while host is not available" at resume

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

Re: btusb "firmware request while host is not available" at resume

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

Re: btusb "firmware request while host is not available" at resume

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

Re: btusb "firmware request while host is not available" at resume

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,

Re: btusb "firmware request while host is not available" at resume

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,

Re: btusb "firmware request while host is not available" at resume

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

Re: btusb "firmware request while host is not available" at resume

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

Re: btusb "firmware request while host is not available" at resume

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

Re: btusb "firmware request while host is not available" at resume

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

Re: btusb "firmware request while host is not available" at resume

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

Re: btusb "firmware request while host is not available" at resume

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

Re: btusb "firmware request while host is not available" at resume

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,

Re: btusb "firmware request while host is not available" at resume

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

Re: btusb "firmware request while host is not available" at resume

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

Re: btusb "firmware request while host is not available" at resume

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

Re: btusb "firmware request while host is not available" at resume

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 > > >

Re: btusb "firmware request while host is not available" at resume

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 > > >

Re: btusb "firmware request while host is not available" at resume

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

Re: btusb "firmware request while host is not available" at resume

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

Re: btusb "firmware request while host is not available" at resume

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

Re: btusb "firmware request while host is not available" at resume

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

Re: btusb "firmware request while host is not available" at resume

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

Re: btusb "firmware request while host is not available" at resume

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

Re: btusb "firmware request while host is not available" at resume

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

Re: btusb "firmware request while host is not available" at resume

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

Re: btusb "firmware request while host is not available" at resume

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

Re: btusb "firmware request while host is not available" at resume

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

Re: btusb "firmware request while host is not available" at resume

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

Re: btusb "firmware request while host is not available" at resume

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

Re: btusb "firmware request while host is not available" at resume

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

Re: btusb "firmware request while host is not available" at resume

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

Re: btusb "firmware request while host is not available" at resume

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,

Re: btusb "firmware request while host is not available" at resume

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,

btusb "firmware request while host is not available" at resume

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

btusb "firmware request while host is not available" at resume

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