USB regression in next-20171108 with hub spamming

USB regression in next-20171108 with hub spamming

[Tony Lindgren]

Hi Felipe & Greg,

Looks like in next-20171108 USB hub is spamming console about once a
second after commit 7dfd74fd128 ("Merge remote-tracking branch
'usb/usb-next'").

Any ideas? See the log below.

Regards,

Tony

8< ------------------------------
ohci-platform 4a064800.ohci: Generic Platform OHCI controller
ohci-platform 4a064800.ohci: new USB bus registered, assigned bus number 1
ohci-platform 4a064800.ohci: irq 146, io mem 0x4a064800
usb usb1: New USB device found, idVendor=1d6b, idProduct=0001
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: Generic Platform OHCI controller
usb usb1: Manufacturer: Linux 4.14.0-rc8-next-20171108+ ohci_hcd
usb usb1: SerialNumber: 4a064800.ohci
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 3 ports detected
hub 1-0:1.0: config failed, can't get hub status (err 2)
hub 1-0:1.0: activate --> -22
hub 1-0:1.0: activate --> -22
hub 1-0:1.0: activate --> -22
hub 1-0:1.0: activate --> -22
hub 1-0:1.0: activate --> -22
hub 1-0:1.0: activate --> -22
hub 1-0:1.0: activate --> -22
...
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB regression in next-20171108 with hub spamming

[Greg Kroah-Hartman]

On Wed, Nov 08, 2017 at 03:05:11PM -0800, Tony Lindgren wrote:
> Hi Felipe & Greg,
> 
> Looks like in next-20171108 USB hub is spamming console about once a
> second after commit 7dfd74fd128 ("Merge remote-tracking branch
> 'usb/usb-next'").
> 
> Any ideas? See the log below.

Any chance you can run 'git bisect'?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB regression in next-20171108 with hub spamming

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 751 bytes --]


Hi,

Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org> writes:
> On Wed, Nov 08, 2017 at 03:05:11PM -0800, Tony Lindgren wrote:
>> Hi Felipe & Greg,
>> 
>> Looks like in next-20171108 USB hub is spamming console about once a
>> second after commit 7dfd74fd128 ("Merge remote-tracking branch
>> 'usb/usb-next'").
>> 
>> Any ideas? See the log below.
>
> Any chance you can run 'git bisect'?

I wonder if it was caused by the usb_get_std_status() changes. We didn't
catch this in our testing, though. I left the patches in intel's
validation for a few days before sending out.

Let me compile that very tag and try it with one of our machines.

Tony, a bisection would be useful, indeed.

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: USB regression in next-20171108 with hub spamming

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 910 bytes --]

Felipe Balbi <felipe.balbi-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> writes:

> Hi,
>
> Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org> writes:
>> On Wed, Nov 08, 2017 at 03:05:11PM -0800, Tony Lindgren wrote:
>>> Hi Felipe & Greg,
>>> 
>>> Looks like in next-20171108 USB hub is spamming console about once a
>>> second after commit 7dfd74fd128 ("Merge remote-tracking branch
>>> 'usb/usb-next'").
>>> 
>>> Any ideas? See the log below.
>>
>> Any chance you can run 'git bisect'?
>
> I wonder if it was caused by the usb_get_std_status() changes. We didn't
> catch this in our testing, though. I left the patches in intel's
> validation for a few days before sending out.
>
> Let me compile that very tag and try it with one of our machines.
>
> Tony, a bisection would be useful, indeed.

reproduced. Digging to figure out what's going on.

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: USB regression in next-20171108 with hub spamming

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1052 bytes --]

Felipe Balbi <felipe.balbi-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> writes:

> Felipe Balbi <felipe.balbi-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> writes:
>
>> Hi,
>>
>> Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org> writes:
>>> On Wed, Nov 08, 2017 at 03:05:11PM -0800, Tony Lindgren wrote:
>>>> Hi Felipe & Greg,
>>>> 
>>>> Looks like in next-20171108 USB hub is spamming console about once a
>>>> second after commit 7dfd74fd128 ("Merge remote-tracking branch
>>>> 'usb/usb-next'").
>>>> 
>>>> Any ideas? See the log below.
>>>
>>> Any chance you can run 'git bisect'?
>>
>> I wonder if it was caused by the usb_get_std_status() changes. We didn't
>> catch this in our testing, though. I left the patches in intel's
>> validation for a few days before sending out.
>>
>> Let me compile that very tag and try it with one of our machines.
>>
>> Tony, a bisection would be useful, indeed.
>
> reproduced. Digging to figure out what's going on.

Okay, found it. Testing a patch.

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: USB regression in next-20171108 with hub spamming

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1882 bytes --]


Hi,

Felipe Balbi <felipe.balbi-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> writes:
> Felipe Balbi <felipe.balbi-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> writes:
>
>> Felipe Balbi <felipe.balbi-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> writes:
>>
>>> Hi,
>>>
>>> Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org> writes:
>>>> On Wed, Nov 08, 2017 at 03:05:11PM -0800, Tony Lindgren wrote:
>>>>> Hi Felipe & Greg,
>>>>> 
>>>>> Looks like in next-20171108 USB hub is spamming console about once a
>>>>> second after commit 7dfd74fd128 ("Merge remote-tracking branch
>>>>> 'usb/usb-next'").
>>>>> 
>>>>> Any ideas? See the log below.
>>>>
>>>> Any chance you can run 'git bisect'?
>>>
>>> I wonder if it was caused by the usb_get_std_status() changes. We didn't
>>> catch this in our testing, though. I left the patches in intel's
>>> validation for a few days before sending out.
>>>
>>> Let me compile that very tag and try it with one of our machines.
>>>
>>> Tony, a bisection would be useful, indeed.
>>
>> reproduced. Digging to figure out what's going on.
>
> Okay, found it. Testing a patch.

Here's the patch, I'll send it formally shortly.

diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
index 0cdc463c9509..c15fbf76f8f7 100644
--- a/drivers/usb/core/message.c
+++ b/drivers/usb/core/message.c
@@ -975,6 +975,7 @@ int usb_get_status(struct usb_device *dev, int recip, int type, int target,
 		}
 
 		*(u32 *) data = le32_to_cpu(*(__le32 *) status);
+		ret = 0;
 		break;
 	case 2:
 		if (type != USB_STATUS_TYPE_STANDARD) {
@@ -983,6 +984,7 @@ int usb_get_status(struct usb_device *dev, int recip, int type, int target,
 		}
 
 		*(u16 *) data = le16_to_cpu(*(__le16 *) status);
+		ret = 0;
 		break;
 	default:
 		ret = -EIO;
-- 
2.14.2.642.g20fed7cad4


-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: USB regression in next-20171108 with hub spamming

[Tony Lindgren]

* Felipe Balbi <felipe.balbi-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> [171109 11:01]:
> Felipe Balbi <felipe.balbi-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> writes:
> > Okay, found it. Testing a patch.
> 
> Here's the patch, I'll send it formally shortly.

Thanks yeah that fixes the issue for me, replied to your formal
patch with a tested by.

Regards,

Tony

> diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
> index 0cdc463c9509..c15fbf76f8f7 100644
> --- a/drivers/usb/core/message.c
> +++ b/drivers/usb/core/message.c
> @@ -975,6 +975,7 @@ int usb_get_status(struct usb_device *dev, int recip, int type, int target,
>  		}
>  
>  		*(u32 *) data = le32_to_cpu(*(__le32 *) status);
> +		ret = 0;
>  		break;
>  	case 2:
>  		if (type != USB_STATUS_TYPE_STANDARD) {
> @@ -983,6 +984,7 @@ int usb_get_status(struct usb_device *dev, int recip, int type, int target,
>  		}
>  
>  		*(u16 *) data = le16_to_cpu(*(__le16 *) status);
> +		ret = 0;
>  		break;
>  	default:
>  		ret = -EIO;
> -- 
> 2.14.2.642.g20fed7cad4
> 
> 
> -- 
> balbi


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html