From: Oliver Neukum <oneukum@suse.com>
To: Hayes Wang <hayeswang@realtek.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: Hangs in r8152 connected to power management in kernels at least up v4.17-rc4
Date: Wed, 16 May 2018 10:26:43 +0200 [thread overview]
Message-ID: <1526459203.25281.2.camel@suse.com> (raw)
In-Reply-To: <0835B3720019904CB8F7AA43166CEEB2D2E47ABE@RTITMBSV06.realtek.com.tw>
Am Mittwoch, den 16.05.2018, 03:37 +0000 schrieb Hayes Wang:
> Oliver Neukum [mailto:oneukum@suse.com]
> >
> > Hi,
> >
> > I got reports about hangs with this trace:
> >
> > May 13 01:36:55 neroon kernel: INFO: task kworker/0:0:4 blocked for more
> > than 60 seconds.
> > May 13 01:36:55 neroon kernel: Tainted: G U
> > 4.17.0-rc4-1.g8257a00-vanilla #1
> > May 13 01:36:55 neroon kernel: "echo 0 >
> > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> > May 13 01:36:55 neroon kernel: kworker/0:0 D 0 4 2
> > 0x80000000
> > May 13 01:36:55 neroon kernel: Workqueue: events rtl_work_func_t [r8152]
> > May 13 01:36:55 neroon kernel: Call Trace:
> > May 13 01:36:55 neroon kernel: ? __schedule+0x289/0x880
> > May 13 01:36:55 neroon kernel: schedule+0x2f/0x90
> > May 13 01:36:55 neroon kernel: rpm_resume+0xf9/0x7a0
> > May 13 01:36:55 neroon kernel: ? wait_woken+0x80/0x80
> > May 13 01:36:55 neroon kernel: rpm_resume+0x547/0x7a0
> > May 13 01:36:55 neroon kernel: ? __switch_to_asm+0x40/0x70
> > May 13 01:36:55 neroon kernel: ? __switch_to_asm+0x34/0x70
> > May 13 01:36:55 neroon kernel: ? __switch_to_asm+0x40/0x70
> > May 13 01:36:55 neroon kernel: ? __switch_to_asm+0x34/0x70
> > May 13 01:36:55 neroon kernel: ? __switch_to_asm+0x40/0x70
> > May 13 01:36:55 neroon kernel: __pm_runtime_resume+0x3a/0x50
> > May 13 01:36:55 neroon kernel: usb_autopm_get_interface+0x1d/0x50 [usbcore]
>
> Would usb_autopm_get_interface() take a long time?
> The driver would wake the device if it has suspended.
> I have no idea about how usb_autopm_get_interface() works, so I don't know how to help.
Hi,
it basically calls r8152_resume() and makes a control request to the
hub. I think we are spinning in rtl8152_runtime_resume(), but where?
It has a lot of NAPI stuff. Any suggestions on how to instrument or
trace this?
Regards
Oliver
next prev parent reply other threads:[~2018-05-16 8:26 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-15 12:43 Hangs in r8152 connected to power management in kernels at least up v4.17-rc4 Oliver Neukum
2018-05-16 3:37 ` Hayes Wang
2018-05-16 8:26 ` Oliver Neukum [this message]
2018-05-16 10:00 ` Hayes Wang
2018-05-16 10:09 ` Oliver Neukum
2018-05-16 12:07 ` Hayes Wang
2018-05-16 13:29 ` Jiri Slaby
2018-05-16 13:36 ` Jiri Slaby
2018-05-25 8:41 ` Jiri Slaby
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1526459203.25281.2.camel@suse.com \
--to=oneukum@suse.com \
--cc=hayeswang@realtek.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.