linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* lockdep warning in urb.c:363 usb_submit_urb
@ 2020-03-23 14:38 Qais Yousef
  2020-03-23 15:36 ` Oliver Neukum
  0 siblings, 1 reply; 50+ messages in thread
From: Qais Yousef @ 2020-03-23 14:38 UTC (permalink / raw)
  To: Greg Kroah-Hartman, linux-usb; +Cc: linux-kernel

Hi

I've hit the following lockdep warning when I trigger hibernate on arm64
platform (Juno-r2)


	echo suspend > /sys/power/disk
	echo disk > /sys/power/state

I only had a usb flash drive attached to it. Let me know if you need more info.



# echo suspend > disk
# echo disk > state
[  325.775152] PM: hibernation: hibernation entry
[  325.780708] Filesystems sync: 0.000 seconds
[  325.784976] Freezing user space processes ... (elapsed 0.001 seconds) done.
[  325.793322] OOM killer disabled.
[  325.797934] PM: hibernation: Preallocating image memory
[  326.852851] PM: hibernation: Allocated 96124 pages for snapshot
[  326.858826] PM: hibernation: Allocated 384496 kbytes in 1.04 seconds (369.70 MB/s)
[  326.866447] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[  326.876429] printk: Suspending console(s) (use no_console_suspend to debug)
[  326.947751] Disabling non-boot CPUs ...
[  326.948909] CPU1: shutdown
[  326.948918] psci: CPU1 killed (polled 0 ms)
[  326.951082] CPU2: shutdown
[  326.952130] psci: CPU2 killed (polled 0 ms)
[  326.954600] CPU3: shutdown
[  326.954613] psci: CPU3 killed (polled 0 ms)
[  326.957217] CPU4: shutdown
[  326.957229] psci: CPU4 killed (polled 0 ms)
[  326.958924] CPU5: shutdown
[  326.958936] psci: CPU5 killed (polled 0 ms)
[  326.959878] PM: hibernation: Creating image:
[  326.959878] PM: hibernation: Need to copy 94789 pages
[  326.959878] PM: hibernation: Image created (94789 pages copied)
[  326.959994] Enabling non-boot CPUs ...
[  326.973678] Detected PIPT I-cache on CPU1
[  326.973728] CPU1: Booted secondary processor 0x0000000000 [0x410fd080]
[  326.975172] CPU1 is up
[  326.993051] Detected PIPT I-cache on CPU2
[  326.993081] CPU2: Booted secondary processor 0x0000000001 [0x410fd080]
[  326.993839] CPU2 is up
[  327.007492] Detected VIPT I-cache on CPU3
[  327.007557] CPU3: Booted secondary processor 0x0000000101 [0x410fd033]
[  327.009075] CPU3 is up
[  327.022636] Detected VIPT I-cache on CPU4
[  327.022682] CPU4: Booted secondary processor 0x0000000102 [0x410fd033]
[  327.024296] CPU4 is up
[  327.038227] Detected VIPT I-cache on CPU5
[  327.038272] CPU5: Booted secondary processor 0x0000000103 [0x410fd033]
[  327.039921] CPU5 is up
[  327.154849] usb usb2: runtime PM trying to activate child device usb2 but parent (7ffb0000.ohci) is not active
[  327.290355] PM: Cannot find swap device, try swapon -a
[  327.295533] PM: Cannot get swap writer
[  327.480758] OOM killer enabled.
[  327.483939] Restarting tasks ...
[  327.484229] ------------[ cut here ]------------
[  327.484664] done.
[  327.487743] URB 000000000c121c1c submitted while active
[  327.499622] WARNING: CPU: 1 PID: 296 at drivers/usb/core/urb.c:363 usb_submit_urb+0x3f0/0x520
[  327.508191] Modules linked in:
[  327.511262] CPU: 1 PID: 296 Comm: kworker/1:2 Not tainted 5.6.0-rc6 #533
[  327.517993] Hardware name: ARM Juno development board (r2) (DT)
[  327.523944] Workqueue: usb_hub_wq hub_event
[  327.528148] pstate: 40000005 (nZcv daif -PAN -UAO)
[  327.532959] pc : usb_submit_urb+0x3f0/0x520
[  327.537160] lr : usb_submit_urb+0x3f0/0x520
[  327.541360] sp : ffff80001891b8c0
[  327.544687] x29: ffff80001891b8c0 x28: ffff000973f7a000
[  327.550024] x27: ffff00097049f320 x26: 0000000000000003
[  327.555361] x25: ffff8000101704e8 x24: ffff80001891bb48
[  327.560697] x23: ffff80001323d000 x22: 0000000000000c00
[  327.566033] x21: 0000000000000004 x20: 00000000fffffff0
[  327.571369] x19: ffff0009703f0300 x18: 0000000000000000
[  327.576705] x17: 0000000000000000 x16: 0000000000000000
[  327.582041] x15: 0000000000000000 x14: 0000000000000000
[  327.587376] x13: 0000000000000000 x12: 0000000000000000
[  327.592712] x11: 0000000000000000 x10: 0000000000000000
[  327.598048] x9 : ffff80001323da88 x8 : ffff00097ef0a798
[  327.603384] x7 : ffff800010148c08 x6 : ffff00097eef7450
[  327.608720] x5 : ffff00097eef7450 x4 : 0000000000000000
[  327.614055] x3 : ffff00097ef06df0 x2 : 0000000000000001
[  327.619391] x1 : 1798c844b4d7c300 x0 : 0000000000000000
[  327.624727] Call trace:
[  327.627183]  usb_submit_urb+0x3f0/0x520
[  327.631035]  hub_activate+0x108/0x788
[  327.634713]  hub_resume+0x40/0x108
[  327.638129]  usb_resume_interface.isra.9+0x60/0x108
[  327.643028]  usb_resume_both+0xe4/0x140
[  327.646881]  usb_runtime_resume+0x24/0x30
[  327.650910]  __rpm_callback+0xdc/0x138
[  327.654675]  rpm_callback+0x34/0x98
[  327.658178]  rpm_resume+0x4a8/0x720
[  327.661681]  rpm_resume+0x50c/0x720
[  327.665183]  __pm_runtime_resume+0x4c/0xb8
[  327.669297]  usb_autopm_get_interface+0x28/0x60
[  327.673848]  hub_event+0x80/0x1368
[  327.677266]  process_one_work+0x2a4/0x748
[  327.681292]  worker_thread+0x48/0x498
[  327.684970]  kthread+0x13c/0x140
[  327.688211]  ret_from_fork+0x10/0x18
[  327.691801] irq event stamp: 17114
[  327.695219] hardirqs last  enabled at (17113): [<ffff80001191b29c>] _raw_spin_unlock_irq+0x34/0x68
[  327.704224] hardirqs last disabled at (17114): [<ffff8000119132d8>] __schedule+0xd0/0x7e8
[  327.712442] softirqs last  enabled at (16742): [<ffff8000100818a4>] __do_softirq+0x4bc/0x568
[  327.720922] softirqs last disabled at (16731): [<ffff800010114064>] irq_exit+0x144/0x150
[  327.729051] ---[ end trace 7d41436f96488c51 ]---
[  327.733762] PM: hibernation: hibernation exit
sh: write error: No such device
# [  327.739972] hub 2-0:1.0: activate --> -16



Thanks

--
Qais Yousef

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: lockdep warning in urb.c:363 usb_submit_urb
  2020-03-23 14:38 lockdep warning in urb.c:363 usb_submit_urb Qais Yousef
@ 2020-03-23 15:36 ` Oliver Neukum
  2020-03-23 15:54   ` Alan Stern
                     ` (2 more replies)
  0 siblings, 3 replies; 50+ messages in thread
From: Oliver Neukum @ 2020-03-23 15:36 UTC (permalink / raw)
  To: Qais Yousef, Greg Kroah-Hartman, linux-usb; +Cc: linux-kernel

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

Am Montag, den 23.03.2020, 14:38 +0000 schrieb Qais Yousef:
> Hi
> 
> I've hit the following lockdep warning when I trigger hibernate on arm64
> platform (Juno-r2)
> 
> 
> 	echo suspend > /sys/power/disk
> 	echo disk > /sys/power/state
> 
> I only had a usb flash drive attached to it. Let me know if you need more info.

Hi,

that is not a lockdep issue, but the hub driver is not properly killing
its URB presumably. Yet, the driver looks correct to me. Please use
the additional patch and activate dynamic debugging for usbcore.

	Regards
		Oliver

[-- Attachment #2: 0001-usb-hub-additional-debugging.patch --]
[-- Type: text/x-patch, Size: 683 bytes --]

From 8357d9d7abe35d5e3684f5127fea6d2430011526 Mon Sep 17 00:00:00 2001
From: Oliver Neukum <oneukum@suse.com>
Date: Mon, 23 Mar 2020 16:34:35 +0100
Subject: [PATCH] usb: hub additional debugging

---
 drivers/usb/core/hub.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 54cd8ef795ec..25530cf30381 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1629,6 +1629,7 @@ static int hub_configure(struct usb_hub *hub,
 		ret = -ENOMEM;
 		goto fail;
 	}
+	dev_dbg(hub_dev, "%p URB allocated \n");
 
 	usb_fill_int_urb(hub->urb, hdev, pipe, *hub->buffer, maxp, hub_irq,
 		hub, endpoint->bInterval);
-- 
2.16.4


^ permalink raw reply related	[flat|nested] 50+ messages in thread

* Re: lockdep warning in urb.c:363 usb_submit_urb
  2020-03-23 15:36 ` Oliver Neukum
@ 2020-03-23 15:54   ` Alan Stern
  2020-03-23 16:02     ` Qais Yousef
  2020-03-23 16:18     ` Oliver Neukum
  2020-03-23 15:57   ` Qais Yousef
  2020-03-23 17:29   ` Qais Yousef
  2 siblings, 2 replies; 50+ messages in thread
From: Alan Stern @ 2020-03-23 15:54 UTC (permalink / raw)
  To: Oliver Neukum; +Cc: Qais Yousef, Greg Kroah-Hartman, linux-usb, linux-kernel

On Mon, 23 Mar 2020, Oliver Neukum wrote:

> Am Montag, den 23.03.2020, 14:38 +0000 schrieb Qais Yousef:
> > Hi
> > 
> > I've hit the following lockdep warning when I trigger hibernate on arm64
> > platform (Juno-r2)
> > 
> > 
> > 	echo suspend > /sys/power/disk
> > 	echo disk > /sys/power/state
> > 
> > I only had a usb flash drive attached to it. Let me know if you need more info.
> 
> Hi,
> 
> that is not a lockdep issue, but the hub driver is not properly killing
> its URB presumably. Yet, the driver looks correct to me. Please use
> the additional patch and activate dynamic debugging for usbcore.

Was the USB flash drive being used as a swap device for holding the 
hibernation image?  That's not likely to work very well.  At least, I 
doubt that it has been tested very much.

This diagnostic was suggested by the runtime PM error that occurred 
when the system was trying to store the hibernation image.  That's 
probably when the hub driver's URB got restarted.

Alan Stern


^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: lockdep warning in urb.c:363 usb_submit_urb
  2020-03-23 15:36 ` Oliver Neukum
  2020-03-23 15:54   ` Alan Stern
@ 2020-03-23 15:57   ` Qais Yousef
  2020-03-23 16:20     ` Oliver Neukum
  2020-03-23 17:29   ` Qais Yousef
  2 siblings, 1 reply; 50+ messages in thread
From: Qais Yousef @ 2020-03-23 15:57 UTC (permalink / raw)
  To: Oliver Neukum; +Cc: Greg Kroah-Hartman, linux-usb, linux-kernel

On 03/23/20 16:36, Oliver Neukum wrote:
> Am Montag, den 23.03.2020, 14:38 +0000 schrieb Qais Yousef:
> > Hi
> > 
> > I've hit the following lockdep warning when I trigger hibernate on arm64
> > platform (Juno-r2)
> > 
> > 
> > 	echo suspend > /sys/power/disk
> > 	echo disk > /sys/power/state
> > 
> > I only had a usb flash drive attached to it. Let me know if you need more info.
> 
> Hi,
> 
> that is not a lockdep issue, but the hub driver is not properly killing
> its URB presumably. Yet, the driver looks correct to me. Please use
> the additional patch and activate dynamic debugging for usbcore.

Yes sorry my bad, it's a WARN_ONCE().

I applied your patch and will reproduce, but meanwhile not sure if you noticed
this line in my previous email

[  327.154849] usb usb2: runtime PM trying to activate child device usb2 but parent (7ffb0000.ohci) is not active

Thanks

--
Qais Yousef

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: lockdep warning in urb.c:363 usb_submit_urb
  2020-03-23 15:54   ` Alan Stern
@ 2020-03-23 16:02     ` Qais Yousef
  2020-03-23 16:18     ` Oliver Neukum
  1 sibling, 0 replies; 50+ messages in thread
From: Qais Yousef @ 2020-03-23 16:02 UTC (permalink / raw)
  To: Alan Stern; +Cc: Oliver Neukum, Greg Kroah-Hartman, linux-usb, linux-kernel

On 03/23/20 11:54, Alan Stern wrote:
> On Mon, 23 Mar 2020, Oliver Neukum wrote:
> 
> > Am Montag, den 23.03.2020, 14:38 +0000 schrieb Qais Yousef:
> > > Hi
> > > 
> > > I've hit the following lockdep warning when I trigger hibernate on arm64
> > > platform (Juno-r2)
> > > 
> > > 
> > > 	echo suspend > /sys/power/disk
> > > 	echo disk > /sys/power/state
> > > 
> > > I only had a usb flash drive attached to it. Let me know if you need more info.
> > 
> > Hi,
> > 
> > that is not a lockdep issue, but the hub driver is not properly killing
> > its URB presumably. Yet, the driver looks correct to me. Please use
> > the additional patch and activate dynamic debugging for usbcore.
> 
> Was the USB flash drive being used as a swap device for holding the 
> hibernation image?  That's not likely to work very well.  At least, I 
> doubt that it has been tested very much.
> 
> This diagnostic was suggested by the runtime PM error that occurred 
> when the system was trying to store the hibernation image.  That's 
> probably when the hub driver's URB got restarted.

Yes, sadly it's the only source of storage I have on that device.

When I ran the test I had swapoff, as you can see in the snippet below. When
swap is on I do hibernate and wakeup successfully. At least that's what appears
to be happening to me.

I get a similar splat regardless of swap is on or off.


[  327.154849] usb usb2: runtime PM trying to activate child device usb2 but parent (7ffb0000.ohci) is not active
[  327.290355] PM: Cannot find swap device, try swapon -a
[  327.295533] PM: Cannot get swap writer
[  327.480758] OOM killer enabled.
[  327.483939] Restarting tasks ...
[  327.484229] ------------[ cut here ]------------
[  327.484664] done.
[  327.487743] URB 000000000c121c1c submitted while active
[  327.499622] WARNING: CPU: 1 PID: 296 at drivers/usb/core/urb.c:363 usb_submit_urb+0x3f0/0x520

Thanks

--
Qais Yousef

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: lockdep warning in urb.c:363 usb_submit_urb
  2020-03-23 15:54   ` Alan Stern
  2020-03-23 16:02     ` Qais Yousef
@ 2020-03-23 16:18     ` Oliver Neukum
  1 sibling, 0 replies; 50+ messages in thread
From: Oliver Neukum @ 2020-03-23 16:18 UTC (permalink / raw)
  To: Alan Stern; +Cc: Qais Yousef, Greg Kroah-Hartman, linux-usb, linux-kernel

Am Montag, den 23.03.2020, 11:54 -0400 schrieb Alan Stern:
> On Mon, 23 Mar 2020, Oliver Neukum wrote:
> 
> > Am Montag, den 23.03.2020, 14:38 +0000 schrieb Qais Yousef:
> > > Hi
> > > 
> > > I've hit the following lockdep warning when I trigger hibernate on arm64
> > > platform (Juno-r2)
> > > 
> > > 
> > > 	echo suspend > /sys/power/disk
> > > 	echo disk > /sys/power/state
> > > 
> > > I only had a usb flash drive attached to it. Let me know if you need more info.
> > 
> > Hi,
> > 
> > that is not a lockdep issue, but the hub driver is not properly killing
> > its URB presumably. Yet, the driver looks correct to me. Please use
> > the additional patch and activate dynamic debugging for usbcore.
> 
> Was the USB flash drive being used as a swap device for holding the 
> hibernation image?  That's not likely to work very well.  At least, I 
> doubt that it has been tested very much.

Right, but this is good. We are getting a test for something that needs
work. It does not really matetr why STD fails.

> This diagnostic was suggested by the runtime PM error that occurred 
> when the system was trying to store the hibernation image.  That's 
> probably when the hub driver's URB got restarted.

AFAICT hub_quiesce() unconditionally calls usb_kill_urb(). So I'd like
to verify that case is really triggered.

	Regards
		Oliver


^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: lockdep warning in urb.c:363 usb_submit_urb
  2020-03-23 15:57   ` Qais Yousef
@ 2020-03-23 16:20     ` Oliver Neukum
  0 siblings, 0 replies; 50+ messages in thread
From: Oliver Neukum @ 2020-03-23 16:20 UTC (permalink / raw)
  To: Qais Yousef; +Cc: Greg Kroah-Hartman, linux-usb, linux-kernel

Am Montag, den 23.03.2020, 15:57 +0000 schrieb Qais Yousef:
> On 03/23/20 16:36, Oliver Neukum wrote:
> > Am Montag, den 23.03.2020, 14:38 +0000 schrieb Qais Yousef:
> > > Hi
> > > 
> > > I've hit the following lockdep warning when I trigger hibernate on arm64
> > > platform (Juno-r2)
> > > 
> > > 
> > > 	echo suspend > /sys/power/disk
> > > 	echo disk > /sys/power/state
> > > 
> > > I only had a usb flash drive attached to it. Let me know if you need more info.
> > 
> > Hi,
> > 
> > that is not a lockdep issue, but the hub driver is not properly killing
> > its URB presumably. Yet, the driver looks correct to me. Please use
> > the additional patch and activate dynamic debugging for usbcore.
> 
> Yes sorry my bad, it's a WARN_ONCE().
> 
> I applied your patch and will reproduce, but meanwhile not sure if you noticed
> this line in my previous email
> 
> [  327.154849] usb usb2: runtime PM trying to activate child device usb2 but parent (7ffb0000.ohci) is not active

Hi,

yes I noticed, but that did not trigger the WARN(). One thing at a time
please.

	Regards
		Oliver


^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: lockdep warning in urb.c:363 usb_submit_urb
  2020-03-23 15:36 ` Oliver Neukum
  2020-03-23 15:54   ` Alan Stern
  2020-03-23 15:57   ` Qais Yousef
@ 2020-03-23 17:29   ` Qais Yousef
  2020-03-24  9:08     ` Oliver Neukum
  2 siblings, 1 reply; 50+ messages in thread
From: Qais Yousef @ 2020-03-23 17:29 UTC (permalink / raw)
  To: Oliver Neukum; +Cc: Greg Kroah-Hartman, linux-usb, linux-kernel

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

Hi Oliver

On 03/23/20 16:36, Oliver Neukum wrote:
> Am Montag, den 23.03.2020, 14:38 +0000 schrieb Qais Yousef:
> > Hi
> > 
> > I've hit the following lockdep warning when I trigger hibernate on arm64
> > platform (Juno-r2)
> > 
> > 
> > 	echo suspend > /sys/power/disk
> > 	echo disk > /sys/power/state
> > 
> > I only had a usb flash drive attached to it. Let me know if you need more info.
> 
> Hi,
> 
> that is not a lockdep issue, but the hub driver is not properly killing
> its URB presumably. Yet, the driver looks correct to me. Please use
> the additional patch and activate dynamic debugging for usbcore.

First time I use dynamic debugging, hopefully I've done correctly.


	echo "file drivers/usb/* +p" > /sys/kernel/debug/dynamic_debug/control

	$REPRODUCE

	cat /sys/kernel/debug/dynamic_debug/control | grep usb > usb.debug

usb.debug is attached.

Thanks

--
Qais Yousef

[-- Attachment #2: usb.debug --]
[-- Type: text/plain, Size: 146871 bytes --]

drivers/phy/allwinner/phy-sun4i-usb.c:857 [phy_sun4i_usb]sun4i_usb_phy_probe =_ "successfully loaded\012"
drivers/phy/rockchip/phy-rockchip-inno-usb2.c:487 [phy_rockchip_inno_usb2]rockchip_usb2phy_power_off =_ "port power off\012"
drivers/phy/rockchip/phy-rockchip-inno-usb2.c:460 [phy_rockchip_inno_usb2]rockchip_usb2phy_power_on =_ "port power on\012"
drivers/phy/rockchip/phy-rockchip-inno-usb2.c:542 [phy_rockchip_inno_usb2]rockchip_usb2phy_otg_sm_work =_ "%s otg sm work\012"
drivers/phy/rockchip/phy-rockchip-inno-usb2.c:552 [phy_rockchip_inno_usb2]rockchip_usb2phy_otg_sm_work =_ "usb otg host connect\012"
drivers/phy/rockchip/phy-rockchip-inno-usb2.c:557 [phy_rockchip_inno_usb2]rockchip_usb2phy_otg_sm_work =_ "vbus_attach\012"
drivers/phy/rockchip/phy-rockchip-inno-usb2.c:565 [phy_rockchip_inno_usb2]rockchip_usb2phy_otg_sm_work =_ "sdp cable is connected\012"
drivers/phy/rockchip/phy-rockchip-inno-usb2.c:573 [phy_rockchip_inno_usb2]rockchip_usb2phy_otg_sm_work =_ "dcp cable is connected\012"
drivers/phy/rockchip/phy-rockchip-inno-usb2.c:580 [phy_rockchip_inno_usb2]rockchip_usb2phy_otg_sm_work =_ "cdp cable is connected\012"
drivers/phy/rockchip/phy-rockchip-inno-usb2.c:615 [phy_rockchip_inno_usb2]rockchip_usb2phy_otg_sm_work =_ "usb disconnect\012"
drivers/phy/rockchip/phy-rockchip-inno-usb2.c:626 [phy_rockchip_inno_usb2]rockchip_usb2phy_otg_sm_work =_ "usb otg host disconnect\012"
drivers/phy/rockchip/phy-rockchip-inno-usb2.c:694 [phy_rockchip_inno_usb2]rockchip_chg_detect_work =_ "chg detection work state = %d\012"
drivers/phy/rockchip/phy-rockchip-inno-usb2.c:431 [phy_rockchip_inno_usb2]rockchip_usb2phy_init =_ "mode %d\012"
drivers/phy/rockchip/phy-rockchip-inno-usb2.c:821 [phy_rockchip_inno_usb2]rockchip_usb2phy_sm_work =_ "HS online\012"
drivers/phy/rockchip/phy-rockchip-inno-usb2.c:835 [phy_rockchip_inno_usb2]rockchip_usb2phy_sm_work =_ "FS/LS online\012"
drivers/phy/rockchip/phy-rockchip-inno-usb2.c:841 [phy_rockchip_inno_usb2]rockchip_usb2phy_sm_work =_ "Connected\012"
drivers/phy/rockchip/phy-rockchip-inno-usb2.c:846 [phy_rockchip_inno_usb2]rockchip_usb2phy_sm_work =_ "FS/LS online\012"
drivers/phy/rockchip/phy-rockchip-inno-usb2.c:851 [phy_rockchip_inno_usb2]rockchip_usb2phy_sm_work =_ "Disconnected\012"
drivers/phy/rockchip/phy-rockchip-inno-usb2.c:870 [phy_rockchip_inno_usb2]rockchip_usb2phy_sm_work =_ "unknown phy state\012"
drivers/phy/tegra/xusb.h:434 [phy_tegra_xusb]padctl_readl =_ "%08lx > %08x\012"
drivers/phy/tegra/xusb.h:426 [phy_tegra_xusb]padctl_writel =_ "%08lx < %08x\012"
drivers/phy/tegra/xusb.c:848 [phy_tegra_xusb]tegra_xusb_update_usb3_fake_port =_ "Found unused usb3 port: %d\012"
drivers/phy/tegra/xusb.h:434 [phy_tegra_xusb]padctl_readl =_ "%08lx > %08x\012"
drivers/phy/tegra/xusb.h:426 [phy_tegra_xusb]padctl_writel =_ "%08lx < %08x\012"
drivers/phy/tegra/xusb.h:434 [phy_tegra_xusb]padctl_readl =_ "%08lx > %08x\012"
drivers/phy/tegra/xusb.h:426 [phy_tegra_xusb]padctl_writel =_ "%08lx < %08x\012"
drivers/phy/tegra/xusb-tegra210.c:2031 [phy_tegra_xusb]tegra210_xusb_padctl_vbus_override =_ "%s vbus override\012"
drivers/phy/tegra/xusb-tegra186.c:809 [phy_tegra_xusb]tegra186_xusb_read_fuse_calibration =_ "FUSE_USB_CALIB_0 %#x\012"
drivers/phy/tegra/xusb-tegra186.c:828 [phy_tegra_xusb]tegra186_xusb_read_fuse_calibration =_ "FUSE_USB_CALIB_EXT_0 %#x\012"
drivers/phy/tegra/xusb-tegra186.c:472 [phy_tegra_xusb]tegra186_usb2_pad_probe =_ "failed to get usb2 trk clock: %d\012"
drivers/phy/tegra/xusb-tegra186.c:865 [phy_tegra_xusb]tegra186_xusb_padctl_vbus_override =_ "%s vbus override\012"
drivers/phy/tegra/xusb.h:434 [phy_tegra_xusb]padctl_readl =_ "%08lx > %08x\012"
drivers/phy/tegra/xusb.h:426 [phy_tegra_xusb]padctl_writel =_ "%08lx < %08x\012"
drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c:257 [phy_bcm_ns2_usbdrd]extcon_work =_ "Host cable connected\012"
drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c:263 [phy_bcm_ns2_usbdrd]extcon_work =_ "Cable disconnected\012"
drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c:266 [phy_bcm_ns2_usbdrd]extcon_work =_ "Device cable connected\012"
drivers/phy/broadcom/phy-brcm-usb.c:122 [phy_brcm_usb_dvr]brcm_usb_phy_exit =_ "EXIT\012"
drivers/phy/broadcom/phy-brcm-usb.c:326 [phy_brcm_usb_dvr]brcm_usb_get_regs =_ "Optional reg %s not found\012"
drivers/phy/broadcom/phy-brcm-usb.c:450 [phy_brcm_usb_dvr]brcm_usb_phy_probe =_ "Best mapping table is for %s\012"
drivers/phy/broadcom/phy-brcm-usb.c:111 [phy_brcm_usb_dvr]brcm_usb_phy_init =_ "INIT, id: %d, total: %d\012"
drivers/phy/broadcom/phy-brcm-usb-init.c:970 [phy_brcm_usb_dvr]usb_get_dual_select =_ "%s\012"
drivers/phy/broadcom/phy-brcm-usb-init.c:984 [phy_brcm_usb_dvr]usb_set_dual_select =_ "%s\012"
drivers/phy/broadcom/phy-brcm-usb-init.c:1011 [phy_brcm_usb_dvr]brcm_usb_dvr_init_7445 =_ "%s\012"
drivers/phy/broadcom/phy-brcm-usb-init-synopsys.c:357 [phy_brcm_usb_dvr]usb_get_dual_select =_ "%s\012"
drivers/phy/broadcom/phy-brcm-usb-init-synopsys.c:305 [phy_brcm_usb_dvr]usb_init_xhci =_ "%s\012"
drivers/phy/broadcom/phy-brcm-usb-init-synopsys.c:314 [phy_brcm_usb_dvr]usb_uninit_common =_ "%s\012"
drivers/phy/broadcom/phy-brcm-usb-init-synopsys.c:369 [phy_brcm_usb_dvr]usb_set_dual_select =_ "%s\012"
drivers/phy/broadcom/phy-brcm-usb-init-synopsys.c:155 [phy_brcm_usb_dvr]usb_init_ipp =_ "%s\012"
drivers/phy/broadcom/phy-brcm-usb-init-synopsys.c:346 [phy_brcm_usb_dvr]usb_uninit_xhci =_ "%s\012"
drivers/phy/broadcom/phy-brcm-usb-init-synopsys.c:326 [phy_brcm_usb_dvr]usb_uninit_common_7211b0 =_ "%s\012"
drivers/phy/broadcom/phy-brcm-usb-init-synopsys.c:191 [phy_brcm_usb_dvr]usb_init_common =_ "%s\012"
drivers/phy/broadcom/phy-brcm-usb-init-synopsys.c:400 [phy_brcm_usb_dvr]brcm_usb_dvr_init_7216 =_ "%s\012"
drivers/phy/broadcom/phy-brcm-usb-init-synopsys.c:409 [phy_brcm_usb_dvr]brcm_usb_dvr_init_7211b0 =_ "%s\012"
drivers/phy/qualcomm/phy-qcom-qusb2.c:853 [phy_qcom_qusb2]qusb2_phy_probe =_ "failed to lookup TCSR regmap\012"
drivers/phy/qualcomm/phy-qcom-qusb2.c:862 [phy_qcom_qusb2]qusb2_phy_probe =_ "failed to lookup tune2 hstx trim value\012"
drivers/phy/qualcomm/phy-qcom-qusb2.c:450 [phy_qcom_qusb2]qusb2_phy_set_tune2_param =_ "failed to read a valid hs-tx trim value\012"
drivers/phy/samsung/phy-samsung-usb2.c:69 [phy_exynos_usb2]samsung_usb2_phy_power_off =_ "Request to power_off \042%s\042 usb phy\012"
drivers/phy/samsung/phy-samsung-usb2.c:224 [phy_exynos_usb2]samsung_usb2_phy_probe =_ "Creating phy \042%s\042\012"
drivers/phy/samsung/phy-samsung-usb2.c:27 [phy_exynos_usb2]samsung_usb2_phy_power_on =_ "Request to power_on \042%s\042 usb phy\012"
drivers/phy/samsung/phy-exynos5-usbdrd.c:311 [phy_exynos5_usbdrd]exynos5_usbdrd_pipe3_set_refclk =_ "unsupported ref clk\012"
drivers/phy/samsung/phy-exynos5-usbdrd.c:535 [phy_exynos5_usbdrd]exynos5_usbdrd_phy_power_off =_ "Request to power_off usbdrd_phy phy\012"
drivers/phy/samsung/phy-exynos5-usbdrd.c:890 [phy_exynos5_usbdrd]exynos5_usbdrd_phy_probe =_ "Not a multi-controller usbdrd phy\012"
drivers/phy/samsung/phy-exynos5-usbdrd.c:483 [phy_exynos5_usbdrd]exynos5_usbdrd_phy_power_on =_ "Request to power_on usbdrd_phy phy\012"
drivers/dma/sh/usb-dmac.c:209 [usb_dmac]usb_dmac_chan_start_sg =_ "chan%u: queue sg %p: %u@%pad -> %pad\012"
drivers/net/usb/pegasus.c:661 [pegasus]intr_callback =_ "intr status %d\012"
drivers/net/usb/pegasus.c:160 [pegasus]set_registers =_ "%s returned %d\012"
drivers/net/usb/pegasus.c:179 [pegasus]set_register =_ "%s returned %d\012"
drivers/net/usb/pegasus.c:119 [pegasus]async_ctrl_callback =_ "%s failed with %d"
drivers/net/usb/pegasus.c:1038 [pegasus]pegasus_set_multicast =_ "set allmulti\012"
drivers/net/usb/pegasus.c:138 [pegasus]get_registers =_ "%s returned %d\012"
drivers/net/usb/pegasus.c:249 [pegasus]__mii_op =_ "%s failed\012"
drivers/net/usb/pegasus.c:627 [pegasus]write_bulk_callback =_ "tx unlink, %d\012"
drivers/net/usb/pegasus.c:1235 [pegasus]pegasus_disconnect =_ "unregistering non-bound device?\012"
drivers/net/usb/pegasus.c:477 [pegasus]read_bulk_callback =_ "reset MAC\012"
drivers/net/usb/pegasus.c:487 [pegasus]read_bulk_callback =_ "rx unlink, %d\012"
drivers/net/usb/pegasus.c:490 [pegasus]read_bulk_callback =_ "RX status %d\012"
drivers/net/usb/pegasus.c:500 [pegasus]read_bulk_callback =_ "RX packet error %x\012"
drivers/net/usb/pegasus.c:844 [pegasus]pegasus_open =_ "failed rx_urb, %d\012"
drivers/net/usb/pegasus.c:855 [pegasus]pegasus_open =_ "failed intr_urb, %d\012"
drivers/net/usb/pegasus.c:862 [pegasus]pegasus_open =_ "can't enable_net_traffic() - %d\012"
drivers/net/usb/pegasus.c:870 [pegasus]pegasus_open =_ "open\012"
drivers/net/usb/rtl8150.c:512 [rtl8150]intr_callback =_ "%s: LINK LOST\012"
drivers/net/usb/rtl8150.c:517 [rtl8150]intr_callback =_ "%s: LINK CAME BACK\012"
drivers/net/usb/rtl8150.c:193 [rtl8150]async_set_reg_cb =_ "%s failed with %d"
drivers/net/usb/rtl8150.c:294 [rtl8150]rtl8150_set_mac_address =_ "Setting MAC address to %pM\012"
drivers/net/usb/rtl8150.c:679 [rtl8150]rtl8150_set_multicast =_ "%s: allmulti set\012"
drivers/net/usb/r8152.c:1447 [r8152]vendor_mac_passthru_addr_read =_ "No efuse for RTL8153-AD MAC pass through\012"
drivers/net/usb/r8152.c:1455 [r8152]vendor_mac_passthru_addr_read =_ "Invalid variant for MAC pass through\012"
drivers/net/usb/r8152.c:6689 [r8152]rtl_get_version =_ "Detected version 0x%04x\012"
drivers/net/usb/r8152.c:4042 [r8152]rtl8152_fw_mac_apply =_ "successfully applied %s\012"
drivers/net/usb/r8152.c:3981 [r8152]rtl8152_fw_phy_nc_apply =_ "successfully applied %s\012"
drivers/net/usb/lan78xx.c:1087 [lan78xx]lan78xx_set_multicast =_ "promiscuous mode enabled"
drivers/net/usb/lan78xx.c:1092 [lan78xx]lan78xx_set_multicast =_ "receive all multicast enabled"
drivers/net/usb/lan78xx.c:1101 [lan78xx]lan78xx_set_multicast =_ "receive multicast hash filter"
drivers/net/usb/lan78xx.c:1687 [lan78xx]lan78xx_init_mac_address =_ "MAC address read from Device Tree"
drivers/net/usb/lan78xx.c:1695 [lan78xx]lan78xx_init_mac_address =_ "MAC address read from EEPROM"
drivers/net/usb/lan78xx.c:1700 [lan78xx]lan78xx_init_mac_address =_ "MAC address set to random addr"
drivers/net/usb/lan78xx.c:2258 [lan78xx]unlink_urbs =_ "unlink urb err, %d\012"
drivers/net/usb/lan78xx.c:2676 [lan78xx]lan78xx_terminate_urbs =_ "waited for %d urb completions\012"
drivers/net/usb/lan78xx.c:3075 [lan78xx]lan78xx_skb_return =_ "< rx, len %zu, type 0x%x\012"
drivers/net/usb/lan78xx.c:3084 [lan78xx]lan78xx_skb_return =_ "netif_rx status %d\012"
drivers/net/usb/lan78xx.c:1048 [lan78xx]lan78xx_deferred_multicast_write =_ "deferred multicast write 0x%08x\012"
drivers/net/usb/lan78xx.c:3025 [lan78xx]lan78xx_unbind =_ "free pdata"
drivers/net/usb/lan78xx.c:1829 [lan78xx]lan78xx_mdio_init =_ "registered mdiobus bus %s\012"
drivers/net/usb/lan78xx.c:2049 [lan78xx]lan7801_phy_init =_ "PHY Not Found!! Registering Fixed PHY\012"
drivers/net/usb/lan78xx.c:2055 [lan78xx]lan7801_phy_init =_ "Registered FIXED PHY\012"
drivers/net/usb/lan78xx.c:2128 [lan78xx]lan78xx_phy_init =_ "phydev->irq = %d\012"
drivers/net/usb/lan78xx.c:1265 [lan78xx]lan78xx_status =_ "PHY INTR: 0x%08x\012"
drivers/net/usb/lan78xx.c:3596 [lan78xx]intr_complete =_ "intr shutdown, code %d\012"
drivers/net/usb/lan78xx.c:3603 [lan78xx]intr_complete =_ "intr status %d\012"
drivers/net/usb/lan78xx.c:2629 [lan78xx]lan78xx_open =_ "phy initialised successfully"
drivers/net/usb/lan78xx.c:2814 [lan78xx]tx_complete =_ "tx err %d\012"
drivers/net/usb/lan78xx.c:2853 [lan78xx]lan78xx_start_xmit =_ "lan78xx_tx_prep return NULL\012"
drivers/net/usb/lan78xx.c:1223 [lan78xx]lan78xx_link_reset =_ "speed: %u duplex: %d anadv: 0x%04x anlpa: 0x%04x"
drivers/net/usb/lan78xx.c:1152 [lan78xx]lan78xx_update_flowcontrol =_ "rx pause %s, tx pause %s"
drivers/net/usb/lan78xx.c:3216 [lan78xx]rx_submit =_ "device gone\012"
drivers/net/usb/lan78xx.c:3224 [lan78xx]rx_submit =_ "rx submit, %d\012"
drivers/net/usb/lan78xx.c:3228 [lan78xx]rx_submit =_ "rx: stopped\012"
drivers/net/usb/lan78xx.c:3258 [lan78xx]rx_complete =_ "rx length %d\012"
drivers/net/usb/lan78xx.c:3269 [lan78xx]rx_complete =_ "rx shutdown, code %d\012"
drivers/net/usb/lan78xx.c:3291 [lan78xx]rx_complete =_ "rx status %d\012"
drivers/net/usb/lan78xx.c:3306 [lan78xx]rx_complete =_ "no read resubmitted\012"
drivers/net/usb/lan78xx.c:3115 [lan78xx]lan78xx_rx =_ "Error rx_cmd_a=0x%08x"
drivers/net/usb/lan78xx.c:3171 [lan78xx]rx_process =_ "drop\012"
drivers/net/usb/lan78xx.c:3481 [lan78xx]lan78xx_bh =_ "skb state %d\012"
drivers/net/usb/lan78xx.c:3398 [lan78xx]lan78xx_tx_bh =_ "Delaying transmission for resumption\012"
drivers/net/usb/lan78xx.c:3419 [lan78xx]lan78xx_tx_bh =_ "tx: submit urb err %d\012"
drivers/net/usb/lan78xx.c:3426 [lan78xx]lan78xx_tx_bh =_ "drop, code %d\012"
drivers/net/usb/lan78xx.c:3434 [lan78xx]lan78xx_tx_bh =_ "> tx, len %d, type 0x%x\012"
drivers/net/usb/asix_devices.c:314 [asix]ax88772_link_reset =_ "ax88772_link_reset() speed: %u duplex: %d setting mode to 0x%04x\012"
drivers/net/usb/asix_devices.c:184 [asix]ax88172_link_reset =_ "ax88172_link_reset() speed: %u duplex: %d setting mode to 0x%04x\012"
drivers/net/usb/asix_devices.c:601 [asix]ax88772_suspend =_ "ax88772_suspend: medium=0x%04x\012"
drivers/net/usb/asix_devices.c:459 [asix]ax88772a_hw_reset =_ "Select PHY #1 failed: %d\012"
drivers/net/usb/asix_devices.c:502 [asix]ax88772a_hw_reset =_ "Write BQ setting failed: %d\012"
drivers/net/usb/asix_devices.c:516 [asix]ax88772a_hw_reset =_ "772a_hw_reset: MR20=0x%x MR21=0x%x MR22=0x%x\012"
drivers/net/usb/asix_devices.c:537 [asix]ax88772a_hw_reset =_ "Write IPG,IPG1,IPG2 failed: %d\012"
drivers/net/usb/asix_devices.c:564 [asix]ax88772a_hw_reset =_ "RX_CTL is 0x%04x after all initializations\012"
drivers/net/usb/asix_devices.c:569 [asix]ax88772a_hw_reset =_ "Medium Status is 0x%04x after all initializations\012"
drivers/net/usb/asix_devices.c:1033 [asix]ax88178_change_mtu =_ "ax88178_change_mtu() new_mtu=%d\012"
drivers/net/usb/asix_devices.c:55 [asix]asix_status =_ "Link Status is: %d\012"
drivers/net/usb/asix_devices.c:961 [asix]ax88178_link_reset =_ "ax88178_link_reset()\012"
drivers/net/usb/asix_devices.c:983 [asix]ax88178_link_reset =_ "ax88178_link_reset() speed: %u duplex: %d setting mode to 0x%04x\012"
drivers/net/usb/asix_devices.c:846 [asix]marvell_led_status =_ "marvell_led_status() read 0x%04x\012"
drivers/net/usb/asix_devices.c:862 [asix]marvell_led_status =_ "marvell_led_status() writing 0x%04x\012"
drivers/net/usb/asix_devices.c:1071 [asix]ax88178_bind =_ "Failed to read MAC address: %d\012"
drivers/net/usb/asix_devices.c:364 [asix]ax88772_hw_reset =_ "Select PHY #1 failed: %d\012"
drivers/net/usb/asix_devices.c:412 [asix]ax88772_hw_reset =_ "Write IPG,IPG1,IPG2 failed: %d\012"
drivers/net/usb/asix_devices.c:430 [asix]ax88772_hw_reset =_ "RX_CTL is 0x%04x after all initializations\012"
drivers/net/usb/asix_devices.c:435 [asix]ax88772_hw_reset =_ "Medium Status is 0x%04x after all initializations\012"
drivers/net/usb/asix_devices.c:689 [asix]ax88772_bind =_ "MAC address read from device tree"
drivers/net/usb/asix_devices.c:707 [asix]ax88772_bind =_ "Failed to read MAC address: %d\012"
drivers/net/usb/asix_devices.c:734 [asix]ax88772_bind =_ "Failed to reset AX88772: %d\012"
drivers/net/usb/asix_devices.c:740 [asix]ax88772_bind =_ "PHYID=0x%08x\012"
drivers/net/usb/asix_devices.c:878 [asix]ax88178_reset =_ "GPIO Status: 0x%04x\012"
drivers/net/usb/asix_devices.c:884 [asix]ax88178_reset =_ "EEPROM index 0x17 is 0x%04x\012"
drivers/net/usb/asix_devices.c:895 [asix]ax88178_reset =_ "GPIO0: %d, PhyMode: %d\012"
drivers/net/usb/asix_devices.c:905 [asix]ax88178_reset =_ "gpio phymode == 1 path\012"
drivers/net/usb/asix_devices.c:912 [asix]ax88178_reset =_ "PHYID=0x%08x\012"
drivers/net/usb/asix_devices.c:794 [asix]marvell_phy_init =_ "marvell_phy_init()\012"
drivers/net/usb/asix_devices.c:797 [asix]marvell_phy_init =_ "MII_MARVELL_STATUS = 0x%04x\012"
drivers/net/usb/asix_devices.c:805 [asix]marvell_phy_init =_ "MII_MARVELL_LED_CTRL (1) = 0x%04x\012"
drivers/net/usb/asix_devices.c:814 [asix]marvell_phy_init =_ "MII_MARVELL_LED_CTRL (2) = 0x%04x\012"
drivers/net/usb/asix_devices.c:825 [asix]rtl8211cl_phy_init =_ "rtl8211cl_phy_init()\012"
drivers/net/usb/asix_devices.c:253 [asix]ax88172_bind =_ "read AX_CMD_READ_NODE_ID failed: %d\012"
drivers/net/usb/asix_common.c:148 [asix]asix_rx_fixup_internal =_ "asix_rx_fixup() Bad RX Length %d\012"
drivers/net/usb/asix_common.c:297 [asix]asix_read_phy_addr =_ "asix_get_phy_addr()\012"
drivers/net/usb/asix_common.c:304 [asix]asix_read_phy_addr =_ "asix_get_phy_addr() returning 0x%04x\012"
drivers/net/usb/asix_common.c:347 [asix]asix_write_rx_ctl =_ "asix_write_rx_ctl() - mode = 0x%04x\012"
drivers/net/usb/asix_common.c:376 [asix]asix_write_medium_mode =_ "asix_write_medium_mode() - mode = 0x%04x\012"
drivers/net/usb/asix_common.c:390 [asix]asix_write_gpio =_ "asix_write_gpio() - value = 0x%04x\012"
drivers/net/usb/asix_common.c:472 [asix]asix_mdio_read =_ "asix_mdio_read() phy_id=0x%02x, loc=0x%02x, returns=0x%04x\012"
drivers/net/usb/asix_common.c:486 [asix]asix_mdio_write =_ "asix_mdio_write() phy_id=0x%02x, loc=0x%02x, val=0x%04x\012"
drivers/net/usb/asix_common.c:536 [asix]asix_mdio_read_nopm =_ "asix_mdio_read_nopm() phy_id=0x%02x, loc=0x%02x, returns=0x%04x\012"
drivers/net/usb/asix_common.c:551 [asix]asix_mdio_write_nopm =_ "asix_mdio_write() phy_id=0x%02x, loc=0x%02x, val=0x%04x\012"
drivers/net/usb/asix_common.c:662 [asix]asix_set_eeprom =_ "write EEPROM len %d, offset %d, magic 0x%x\012"
drivers/net/usb/asix_common.c:710 [asix]asix_set_eeprom =_ "write to EEPROM at offset 0x%02x, data 0x%04x\012"
drivers/net/usb/ax88172a.c:247 [asix]ax88172a_stop =_ "Stopping interface\012"
drivers/net/usb/ax88172a.c:64 [asix]ax88172a_adjust_link =_ "speed %u duplex %d, setting mode to 0x%04x\012"
drivers/net/usb/ax88172a.c:278 [asix]ax88172a_reset =_ "RX_CTL is 0x%04x after software reset\012"
drivers/net/usb/ax88172a.c:284 [asix]ax88172a_reset =_ "RX_CTL is 0x%04x setting to 0x0000\012"
drivers/net/usb/ax88172a.c:310 [asix]ax88172a_reset =_ "RX_CTL is 0x%04x after all initializations\012"
drivers/net/usb/ax88172a.c:314 [asix]ax88172a_reset =_ "Medium Status is 0x%04x after all initializations\012"
drivers/net/usb/ax88172a.c:205 [asix]ax88172a_bind =_ "AX_CMD_SW_PHY_STATUS = 0x%02x\012"
drivers/net/usb/ax88172a.c:208 [asix]ax88172a_bind =_ "use internal phy\012"
drivers/net/usb/ax88172a.c:212 [asix]ax88172a_bind =_ "use external phy\012"
drivers/net/usb/ax88179_178a.c:1225 [ax88179_178a]ax88179_get_mac_addr =_ "MAC address read from device tree"
drivers/net/usb/ax88179_178a.c:1230 [ax88179_178a]ax88179_get_mac_addr =_ "MAC address read from ASIX chip"
drivers/net/usb/cdc_ether.c:125 [cdc_ether]usbnet_generic_cdc_bind =_ "CDC descriptors on config\012"
drivers/net/usb/cdc_ether.c:141 [cdc_ether]usbnet_generic_cdc_bind =_ "CDC descriptors on endpoint\012"
drivers/net/usb/cdc_ether.c:178 [cdc_ether]usbnet_generic_cdc_bind =_ "master #%u/%p slave #%u/%p\012"
drivers/net/usb/cdc_ether.c:187 [cdc_ether]usbnet_generic_cdc_bind =_ "bogus CDC Union\012"
drivers/net/usb/cdc_ether.c:205 [cdc_ether]usbnet_generic_cdc_bind =_ "slave class %u\012"
drivers/net/usb/cdc_ether.c:234 [cdc_ether]usbnet_generic_cdc_bind =_ "GUID doesn't match\012"
drivers/net/usb/cdc_ether.c:241 [cdc_ether]usbnet_generic_cdc_bind =_ "Descriptor too short\012"
drivers/net/usb/cdc_ether.c:270 [cdc_ether]usbnet_generic_cdc_bind =_ "missing cdc %s%s%sdescriptor\012"
drivers/net/usb/cdc_ether.c:303 [cdc_ether]usbnet_generic_cdc_bind =_ "bad notification endpoint\012"
drivers/net/usb/cdc_ether.c:408 [cdc_ether]usbnet_cdc_status =_ "CDC: carrier %s\012"
drivers/net/usb/cdc_ether.c:413 [cdc_ether]usbnet_cdc_status =_ "CDC: speed change (len %d)\012"
drivers/net/usb/cdc_ether.c:502 [cdc_ether]usbnet_cdc_zte_status =_ "CDC: carrier %s\012"
drivers/net/usb/dm9601.c:555 [dm9601]dm9601_link_reset =_ "link_reset() speed: %u duplex: %d\012"
drivers/net/usb/dm9601.c:142 [dm9601]dm_read_shared_word =_ "read shared %d 0x%02x returned 0x%04x, %d\012"
drivers/net/usb/dm9601.c:543 [dm9601]dm9601_status =_ "Link Status is: %d\012"
drivers/net/usb/dm9601.c:226 [dm9601]dm9601_mdio_read =_ "Only internal phy supported\012"
drivers/net/usb/dm9601.c:234 [dm9601]dm9601_mdio_read =_ "dm9601_mdio_read() phy_id=0x%02x, loc=0x%02x, returns=0x%04x\012"
drivers/net/usb/dm9601.c:246 [dm9601]dm9601_mdio_write =_ "Only internal phy supported\012"
drivers/net/usb/dm9601.c:251 [dm9601]dm9601_mdio_write =_ "dm9601_mdio_write() phy_id=0x%02x, loc=0x%02x, val=0x%04x\012"
drivers/net/usb/sr9800.c:270 [sr9800]sr_write_medium_mode =_ "%s : mode = 0x%04x\012"
drivers/net/usb/sr9800.c:550 [sr9800]sr9800_link_reset =_ "%s : speed: %u duplex: %d mode: 0x%04x\012"
drivers/net/usb/sr9800.c:241 [sr9800]sr_write_rx_ctl =_ "%s : mode = 0x%04x\012"
drivers/net/usb/sr9800.c:348 [sr9800]sr_mdio_read =_ "%s : phy_id=0x%02x, loc=0x%02x, returns=0x%04x\012"
drivers/net/usb/sr9800.c:162 [sr9800]sr_status =_ "Link Status is: %d\012"
drivers/net/usb/sr9800.c:361 [sr9800]sr_mdio_write =_ "%s : phy_id=0x%02x, loc=0x%02x, val=0x%04x\012"
drivers/net/usb/sr9800.c:576 [sr9800]sr9800_set_default_mode =_ "Write IPG,IPG1,IPG2 failed: %d\012"
drivers/net/usb/sr9800.c:587 [sr9800]sr9800_set_default_mode =_ "RX_CTL is 0x%04x after all initializations\012"
drivers/net/usb/sr9800.c:591 [sr9800]sr9800_set_default_mode =_ "Medium Status:0x%04x after all initializations\012"
drivers/net/usb/sr9800.c:760 [sr9800]sr9800_bind =_ "Failed to read MAC address: %d\012"
drivers/net/usb/sr9800.c:763 [sr9800]sr9800_bind =_ "mac addr : %pM\012"
drivers/net/usb/sr9800.c:200 [sr9800]sr_get_phy_addr =_ "%s : returning 0x%04x\012"
drivers/net/usb/sr9800.c:780 [sr9800]sr9800_bind =_ "Select PHY #1 failed: %d\012"
drivers/net/usb/sr9800.c:790 [sr9800]sr9800_bind =_ "RX_CTL is 0x%04x after software reset\012"
drivers/net/usb/sr9800.c:796 [sr9800]sr9800_bind =_ "RX_CTL is 0x%04x setting to 0x0000\012"
drivers/net/usb/sr9800.c:800 [sr9800]sr9800_bind =_ "PHYID=0x%08x\012"
drivers/net/usb/sr9800.c:831 [sr9800]sr9800_bind =_ "%s : setting rx_urb_size with : %zu\012"
drivers/net/usb/sr9800.c:283 [sr9800]sr_write_gpio =_ "%s : value = 0x%04x\012"
drivers/net/usb/sr9800.c:613 [sr9800]sr9800_reset =_ "Select PHY #1 failed: %d\012"
drivers/net/usb/sr9800.c:641 [sr9800]sr9800_reset =_ "RX_CTL is 0x%04x after software reset\012"
drivers/net/usb/sr9800.c:647 [sr9800]sr9800_reset =_ "RX_CTL is 0x%04x setting to 0x0000\012"
drivers/net/usb/smsc75xx.c:666 [smsc75xx]smsc75xx_status =_ "intdata: 0x%08X\012"
drivers/net/usb/smsc75xx.c:558 [smsc75xx]smsc75xx_set_multicast =_ "promiscuous mode enabled\012"
drivers/net/usb/smsc75xx.c:561 [smsc75xx]smsc75xx_set_multicast =_ "receive all multicast enabled\012"
drivers/net/usb/smsc75xx.c:566 [smsc75xx]smsc75xx_set_multicast =_ "receive multicast hash filter\012"
drivers/net/usb/smsc75xx.c:576 [smsc75xx]smsc75xx_set_multicast =_ "receive own packets only\012"
drivers/net/usb/smsc75xx.c:1511 [smsc75xx]smsc75xx_unbind =_ "free pdata\012"
drivers/net/usb/smsc75xx.c:649 [smsc75xx]smsc75xx_link_reset =_ "speed: %u duplex: %d lcladv: %04x rmtadv: %04x\012"
drivers/net/usb/smsc75xx.c:606 [smsc75xx]smsc75xx_update_flowcontrol =_ "rx pause %s, tx pause %s\012"
drivers/net/usb/smsc75xx.c:608 [smsc75xx]smsc75xx_update_flowcontrol =_ "half duplex\012"
drivers/net/usb/smsc75xx.c:1703 [smsc75xx]smsc75xx_enable_phy_wakeup_interrupts =_ "enabling PHY wakeup interrupts\012"
drivers/net/usb/smsc75xx.c:1753 [smsc75xx]smsc75xx_autosuspend =_ "autosuspend entering SUSPEND2\012"
drivers/net/usb/smsc75xx.c:1759 [smsc75xx]smsc75xx_autosuspend =_ "autosuspend entering SUSPEND1\012"
drivers/net/usb/smsc75xx.c:1781 [smsc75xx]smsc75xx_autosuspend =_ "autosuspend entering SUSPEND3\012"
drivers/net/usb/smsc75xx.c:1664 [smsc75xx]smsc75xx_enter_suspend3 =_ "rx fifo not empty in autosuspend\012"
drivers/net/usb/smsc75xx.c:1048 [smsc75xx]smsc75xx_reset =_ "entering smsc75xx_reset\012"
drivers/net/usb/smsc75xx.c:1086 [smsc75xx]smsc75xx_reset =_ "Lite reset complete, resetting PHY\012"
drivers/net/usb/smsc75xx.c:1118 [smsc75xx]smsc75xx_reset =_ "PHY reset complete\012"
drivers/net/usb/smsc75xx.c:1127 [smsc75xx]smsc75xx_reset =_ "MAC Address: %pM\012"
drivers/net/usb/smsc75xx.c:1136 [smsc75xx]smsc75xx_reset =_ "Read Value from HW_CFG : 0x%08x\012"
drivers/net/usb/smsc75xx.c:1153 [smsc75xx]smsc75xx_reset =_ "Read Value from HW_CFG after writing HW_CFG_BIR: 0x%08x\012"
drivers/net/usb/smsc75xx.c:1167 [smsc75xx]smsc75xx_reset =_ "rx_urb_size=%ld\012"
drivers/net/usb/smsc75xx.c:1182 [smsc75xx]smsc75xx_reset =_ "Read Value from BURST_CAP after writing: 0x%08x\012"
drivers/net/usb/smsc75xx.c:1197 [smsc75xx]smsc75xx_reset =_ "Read Value from BULK_IN_DLY after writing: 0x%08x\012"
drivers/net/usb/smsc75xx.c:1206 [smsc75xx]smsc75xx_reset =_ "HW_CFG: 0x%08x\012"
drivers/net/usb/smsc75xx.c:1222 [smsc75xx]smsc75xx_reset =_ "HW_CFG: 0x%08x\012"
drivers/net/usb/smsc75xx.c:1233 [smsc75xx]smsc75xx_reset =_ "FCT_RX_FIFO_END set to 0x%08x\012"
drivers/net/usb/smsc75xx.c:1242 [smsc75xx]smsc75xx_reset =_ "FCT_TX_FIFO_END set to 0x%08x\012"
drivers/net/usb/smsc75xx.c:1256 [smsc75xx]smsc75xx_reset =_ "ID_REV = 0x%08x\012"
drivers/net/usb/smsc75xx.c:1316 [smsc75xx]smsc75xx_reset =_ "RFE_CTL set to 0x%08x\012"
drivers/net/usb/smsc75xx.c:870 [smsc75xx]smsc75xx_phy_initialize =_ "phy initialised successfully\012"
drivers/net/usb/smsc75xx.c:1372 [smsc75xx]smsc75xx_reset =_ "MAC_TX set to 0x%08x\012"
drivers/net/usb/smsc75xx.c:1388 [smsc75xx]smsc75xx_reset =_ "FCT_TX_CTL set to 0x%08x\012"
drivers/net/usb/smsc75xx.c:1410 [smsc75xx]smsc75xx_reset =_ "MAC_RX set to 0x%08x\012"
drivers/net/usb/smsc75xx.c:1426 [smsc75xx]smsc75xx_reset =_ "FCT_RX_CTL set to 0x%08x\012"
drivers/net/usb/smsc75xx.c:1428 [smsc75xx]smsc75xx_reset =_ "smsc75xx_reset, return 0\012"
drivers/net/usb/smsc75xx.c:2094 [smsc75xx]smsc75xx_resume =_ "resume suspend_flags=0x%02x\012"
drivers/net/usb/smsc75xx.c:775 [smsc75xx]smsc75xx_init_mac_address =_ "MAC address read from EEPROM\012"
drivers/net/usb/smsc75xx.c:782 [smsc75xx]smsc75xx_init_mac_address =_ "MAC address set to eth_random_addr\012"
drivers/net/usb/smsc75xx.c:531 [smsc75xx]smsc75xx_deferred_multicast_write =_ "deferred multicast write 0x%08x\012"
drivers/net/usb/smsc75xx.c:2197 [smsc75xx]smsc75xx_rx_fixup =_ "Error rx_cmd_a=0x%08x\012"
drivers/net/usb/smsc75xx.c:2210 [smsc75xx]smsc75xx_rx_fixup =_ "size err rx_cmd_a=0x%08x\012"
drivers/net/usb/smsc95xx.c:610 [smsc95xx]smsc95xx_status =_ "intdata: 0x%08X\012"
drivers/net/usb/smsc95xx.c:468 [smsc95xx]smsc95xx_set_multicast =_ "promiscuous mode enabled\012"
drivers/net/usb/smsc95xx.c:472 [smsc95xx]smsc95xx_set_multicast =_ "receive all multicast enabled\012"
drivers/net/usb/smsc95xx.c:491 [smsc95xx]smsc95xx_set_multicast =_ "HASHH=0x%08X, HASHL=0x%08X\012"
drivers/net/usb/smsc95xx.c:493 [smsc95xx]smsc95xx_set_multicast =_ "receive own packets only\012"
drivers/net/usb/smsc95xx.c:1328 [smsc95xx]smsc95xx_unbind =_ "free pdata\012"
drivers/net/usb/smsc95xx.c:683 [smsc95xx]smsc95xx_set_features =_ "COE_CR = 0x%08x\012"
drivers/net/usb/smsc95xx.c:576 [smsc95xx]smsc95xx_link_reset =_ "speed: %u duplex: %d lcladv: %04x rmtadv: %04x\012"
drivers/net/usb/smsc95xx.c:538 [smsc95xx]smsc95xx_phy_update_flowcontrol =_ "rx pause %s, tx pause %s\012"
drivers/net/usb/smsc95xx.c:540 [smsc95xx]smsc95xx_phy_update_flowcontrol =_ "half duplex\012"
drivers/net/usb/smsc95xx.c:1026 [smsc95xx]smsc95xx_reset =_ "entering smsc95xx_reset\012"
drivers/net/usb/smsc95xx.c:1069 [smsc95xx]smsc95xx_reset =_ "MAC Address: %pM\012"
drivers/net/usb/smsc95xx.c:1076 [smsc95xx]smsc95xx_reset =_ "Read Value from HW_CFG : 0x%08x\012"
drivers/net/usb/smsc95xx.c:1090 [smsc95xx]smsc95xx_reset =_ "Read Value from HW_CFG after writing HW_CFG_BIR_: 0x%08x\012"
drivers/net/usb/smsc95xx.c:1104 [smsc95xx]smsc95xx_reset =_ "rx_urb_size=%ld\012"
drivers/net/usb/smsc95xx.c:1116 [smsc95xx]smsc95xx_reset =_ "Read Value from BURST_CAP after writing: 0x%08x\012"
drivers/net/usb/smsc95xx.c:1128 [smsc95xx]smsc95xx_reset =_ "Read Value from BULK_IN_DLY after writing: 0x%08x\012"
drivers/net/usb/smsc95xx.c:1135 [smsc95xx]smsc95xx_reset =_ "Read Value from HW_CFG: 0x%08x\012"
drivers/net/usb/smsc95xx.c:1154 [smsc95xx]smsc95xx_reset =_ "Read Value from HW_CFG after writing: 0x%08x\012"
drivers/net/usb/smsc95xx.c:1163 [smsc95xx]smsc95xx_reset =_ "ID_REV = 0x%08x\012"
drivers/net/usb/smsc95xx.c:1016 [smsc95xx]smsc95xx_phy_initialize =_ "phy initialised successfully\012"
drivers/net/usb/smsc95xx.c:1230 [smsc95xx]smsc95xx_reset =_ "smsc95xx_reset, return 0\012"
drivers/net/usb/smsc95xx.c:1854 [smsc95xx]smsc95xx_resume =_ "resume suspend_flags=0x%02x\012"
drivers/net/usb/smsc95xx.c:1933 [smsc95xx]smsc95xx_rx_fixup =_ "Error header=0x%08x\012"
drivers/net/usb/smsc95xx.c:1951 [smsc95xx]smsc95xx_rx_fixup =_ "size err header=0x%08x\012"
drivers/net/usb/smsc95xx.c:1346 [smsc95xx]smsc95xx_enable_phy_wakeup_interrupts =_ "enabling PHY wakeup interrupts\012"
drivers/net/usb/smsc95xx.c:1537 [smsc95xx]smsc95xx_autosuspend =_ "autosuspend entering SUSPEND2\012"
drivers/net/usb/smsc95xx.c:1551 [smsc95xx]smsc95xx_autosuspend =_ "autosuspend entering SUSPEND1\012"
drivers/net/usb/smsc95xx.c:1573 [smsc95xx]smsc95xx_autosuspend =_ "autosuspend entering SUSPEND3\012"
drivers/net/usb/smsc95xx.c:918 [smsc95xx]smsc95xx_init_mac_address =_ "MAC address read from EEPROM\012"
drivers/net/usb/smsc95xx.c:925 [smsc95xx]smsc95xx_init_mac_address =_ "MAC address set to eth_random_addr\012"
drivers/net/usb/net1080.c:314 [net1080]net1080_check_connect =_ "net1080_check_conn read - %d\012"
drivers/net/usb/net1080.c:270 [net1080]net1080_reset =_ "can't read %s-%s status: %d\012"
drivers/net/usb/net1080.c:246 [net1080]nc_dump_status =_ "net1080 %s-%s status 0x%x: this (%c) PKT=%d%s%s%s; other PKT=%d%s%s%s; unspec 0x%x\012"
drivers/net/usb/net1080.c:277 [net1080]net1080_reset =_ "can't read USBCTL, %d\012"
drivers/net/usb/net1080.c:200 [net1080]nc_dump_usbctl =_ "net1080 %s-%s usbctl 0x%x:%s%s%s%s%s; this%s%s; other%s%s; r/o 0x%x\012"
drivers/net/usb/net1080.c:287 [net1080]net1080_reset =_ "can't read TTL, %d\012"
drivers/net/usb/net1080.c:294 [net1080]net1080_reset =_ "assigned TTL, %d ms\012"
drivers/net/usb/net1080.c:336 [net1080]nc_ensure_sync =_ "flush net1080; too many framing errors\012"
drivers/net/usb/net1080.c:353 [net1080]net1080_rx_fixup =_ "rx framesize %d range %d..%d mtu %d\012"
drivers/net/usb/net1080.c:364 [net1080]net1080_rx_fixup =_ "packet too big, %d\012"
drivers/net/usb/net1080.c:369 [net1080]net1080_rx_fixup =_ "header too short, %d\012"
drivers/net/usb/net1080.c:374 [net1080]net1080_rx_fixup =_ "header OOB, %d bytes\012"
drivers/net/usb/net1080.c:387 [net1080]net1080_rx_fixup =_ "bad pad\012"
drivers/net/usb/net1080.c:395 [net1080]net1080_rx_fixup =_ "bad packet len %d (expected %d)\012"
drivers/net/usb/net1080.c:403 [net1080]net1080_rx_fixup =_ "(2+ dropped) rx packet_id mismatch 0x%x 0x%x\012"
drivers/net/usb/plusb.c:88 [plusb]pl_reset =_ "pl_reset --> %d\012"
drivers/net/usb/zaurus.c:153 [zaurus]blan_mdlm_bind =_ "extra MDLM\012"
drivers/net/usb/zaurus.c:159 [zaurus]blan_mdlm_bind =_ "MDLM len %u\012"
drivers/net/usb/zaurus.c:166 [zaurus]blan_mdlm_bind =_ "MDLM guid\012"
drivers/net/usb/zaurus.c:172 [zaurus]blan_mdlm_bind =_ "extra MDLM detail\012"
drivers/net/usb/zaurus.c:211 [zaurus]blan_mdlm_bind =_ "bad MDLM detail, %d %d %d\012"
drivers/net/usb/zaurus.c:229 [zaurus]blan_mdlm_bind =_ "missing cdc mdlm %s%sdescriptor\012"
drivers/net/usb/mcs7830.c:526 [mcs7830]mcs7830_rx_fixup =_ "rx fixup status %x\012"
drivers/net/usb/mcs7830.c:557 [mcs7830]mcs7830_status =_ "Link Status is: %d\012"
drivers/net/usb/mcs7830.c:244 [mcs7830]mcs7830_write_phy =_ "write PHY reg %02x: %04x (%d tries)\012"
drivers/net/usb/mcs7830.c:201 [mcs7830]mcs7830_read_phy =_ "read PHY reg %02x: %04x (%d tries)\012"
drivers/net/usb/usbnet.c:162 [usbnet]usbnet_get_ethernet_addr =_ "bad MAC string %d fetch, %d\012"
drivers/net/usb/usbnet.c:186 [usbnet]intr_complete =_ "intr shutdown, code %d\012"
drivers/net/usb/usbnet.c:193 [usbnet]intr_complete =_ "intr status %d\012"
drivers/net/usb/usbnet.c:2112 [usbnet]usbnet_async_cmd_cb =_ "%s failed with %d"
drivers/net/usb/usbnet.c:2132 [usbnet]usbnet_write_cmd_async =_ "usbnet_write_cmd cmd=0x%02x reqtype=%02x value=0x%04x index=0x%04x size=%d\012"
drivers/net/usb/usbnet.c:253 [usbnet]usbnet_status_start =_ "incremented interrupt URB count to %d\012"
drivers/net/usb/usbnet.c:287 [usbnet]usbnet_status_stop =_ "decremented interrupt URB count to %d\012"
drivers/net/usb/usbnet.c:739 [usbnet]unlink_urbs =_ "unlink urb err, %d\012"
drivers/net/usb/usbnet.c:794 [usbnet]usbnet_terminate_urbs =_ "waited for %d urb completions\012"
drivers/net/usb/usbnet.c:2021 [usbnet]__usbnet_write_cmd =_ "usbnet_write_cmd cmd=0x%02x reqtype=%02x value=0x%04x index=0x%04x size=%d\012"
drivers/net/usb/usbnet.c:329 [usbnet]usbnet_skb_return =_ "< rx, len %zu, type 0x%x\012"
drivers/net/usb/usbnet.c:338 [usbnet]usbnet_skb_return =_ "netif_rx status %d\012"
drivers/net/usb/usbnet.c:671 [usbnet]usbnet_pause_rx =_ "paused rx queue enabled\012"
drivers/net/usb/usbnet.c:458 [usbnet]usbnet_defer_kevent =_ "kevent %d may have been dropped\012"
drivers/net/usb/usbnet.c:460 [usbnet]usbnet_defer_kevent =_ "kevent %d scheduled\012"
drivers/net/usb/usbnet.c:299 [usbnet]__usbnet_status_stop_force =_ "killed interrupt URB for suspend\012"
drivers/net/usb/usbnet.c:690 [usbnet]usbnet_resume_rx =_ "paused rx queue disabled, %d skbs requeued\012"
drivers/net/usb/usbnet.c:1279 [usbnet]tx_complete =_ "tx throttle %d\012"
drivers/net/usb/usbnet.c:1285 [usbnet]tx_complete =_ "tx err %d\012"
drivers/net/usb/usbnet.c:893 [usbnet]usbnet_open =_ "can't open; %d\012"
drivers/net/usb/usbnet.c:1368 [usbnet]usbnet_start_xmit =_ "can't tx_fixup skb\012"
drivers/net/usb/usbnet.c:1374 [usbnet]usbnet_start_xmit =_ "no urb\012"
drivers/net/usb/usbnet.c:1446 [usbnet]usbnet_start_xmit =_ "Delaying transmission for resumption\012"
drivers/net/usb/usbnet.c:1460 [usbnet]usbnet_start_xmit =_ "tx: submit urb err %d\012"
drivers/net/usb/usbnet.c:1471 [usbnet]usbnet_start_xmit =_ "drop, code %d\012"
drivers/net/usb/usbnet.c:1483 [usbnet]usbnet_start_xmit =_ "> tx, len %u, type 0x%x\012"
drivers/net/usb/usbnet.c:487 [usbnet]rx_submit =_ "no rx skb\012"
drivers/net/usb/usbnet.c:516 [usbnet]rx_submit =_ "device gone\012"
drivers/net/usb/usbnet.c:524 [usbnet]rx_submit =_ "rx submit, %d\012"
drivers/net/usb/usbnet.c:531 [usbnet]rx_submit =_ "rx: stopped\012"
drivers/net/usb/usbnet.c:563 [usbnet]rx_process =_ "rx length %d\012"
drivers/net/usb/usbnet.c:1538 [usbnet]usbnet_bh =_ "bogus skb state %d\012"
drivers/net/usb/usbnet.c:1567 [usbnet]usbnet_bh =_ "rxqlen %d --> %d\012"
drivers/net/usb/usbnet.c:269 [usbnet]__usbnet_status_start_force =_ "submitted interrupt URB for resume\012"
drivers/net/usb/usbnet.c:606 [usbnet]rx_complete =_ "rx shutdown, code %d\012"
drivers/net/usb/usbnet.c:620 [usbnet]rx_complete =_ "rx throttle %d\012"
drivers/net/usb/usbnet.c:636 [usbnet]rx_complete =_ "rx status %d\012"
drivers/net/usb/usbnet.c:663 [usbnet]rx_complete =_ "no read resubmitted\012"
drivers/net/usb/usbnet.c:1236 [usbnet]usbnet_deferred_kevent =_ "kevent done, flags = 0x%lx\012"
drivers/net/usb/usbnet.c:1989 [usbnet]__usbnet_read_cmd =_ "usbnet_read_cmd cmd=0x%02x reqtype=%02x value=0x%04x index=0x%04x size=%d\012"
drivers/net/usb/usbnet.c:2005 [usbnet]__usbnet_read_cmd =_ "Huh? Data requested but thrown away.\012"
drivers/net/usb/usbnet.c:1677 [usbnet]usbnet_probe =_ "blacklisted by %s\012"
drivers/net/usb/usbnet.c:234 [usbnet]init_status =_ "status ep%din, %d bytes period %d\012"
drivers/net/usb/cdc_ncm.c:583 [cdc_ncm]cdc_ncm_set_dgram_size =_ "GET_MAX_DATAGRAM_SIZE failed\012"
drivers/net/usb/cdc_ncm.c:595 [cdc_ncm]cdc_ncm_set_dgram_size =_ "SET_MAX_DATAGRAM_SIZE failed\012"
drivers/net/usb/cdc_ncm.c:1426 [cdc_ncm]cdc_ncm_rx_verify_nth16 =_ "frame too short\012"
drivers/net/usb/cdc_ncm.c:1435 [cdc_ncm]cdc_ncm_rx_verify_nth16 =_ "invalid NTH16 signature <%#010x>\012"
drivers/net/usb/cdc_ncm.c:1443 [cdc_ncm]cdc_ncm_rx_verify_nth16 =_ "unsupported NTB block length %u/%u\012"
drivers/net/usb/cdc_ncm.c:1452 [cdc_ncm]cdc_ncm_rx_verify_nth16 =_ "sequence number glitch prev=%d curr=%d\012"
drivers/net/usb/cdc_ncm.c:1471 [cdc_ncm]cdc_ncm_rx_verify_ndp16 =_ "invalid NDP offset  <%u>\012"
drivers/net/usb/cdc_ncm.c:1478 [cdc_ncm]cdc_ncm_rx_verify_ndp16 =_ "invalid DPT16 length <%u>\012"
drivers/net/usb/cdc_ncm.c:1489 [cdc_ncm]cdc_ncm_rx_verify_ndp16 =_ "Invalid nframes = %d\012"
drivers/net/usb/cdc_ncm.c:1526 [cdc_ncm]cdc_ncm_rx_fixup =_ "invalid DPT16 signature <%#010x>\012"
drivers/net/usb/cdc_ncm.c:1550 [cdc_ncm]cdc_ncm_rx_fixup =_ "invalid frame detected (ignored) offset[%u]=%u, length=%u, skb=%p\012"
drivers/net/usb/cdc_ncm.c:186 [cdc_ncm]cdc_ncm_check_tx_max =_ "tx_max must be in the [%u, %u] range\012"
drivers/net/usb/cdc_ncm.c:167 [cdc_ncm]cdc_ncm_check_rx_max =_ "rx_max must be in the [%u, %u] range\012"
drivers/net/usb/cdc_ncm.c:395 [cdc_ncm]cdc_ncm_update_rxtx_max =_ "Setting NTB Input Size failed\012"
drivers/net/usb/cdc_ncm.c:1646 [cdc_ncm]cdc_ncm_status =_ "NCM: unexpected notification 0x%02x!\012"
drivers/net/usb/cdc_ncm.c:815 [cdc_ncm]cdc_ncm_bind_common =_ "CDC Union missing - got slave from IAD\012"
drivers/net/usb/cdc_ncm.c:820 [cdc_ncm]cdc_ncm_bind_common =_ "CDC Union missing and no IAD found\012"
drivers/net/usb/cdc_ncm.c:825 [cdc_ncm]cdc_ncm_bind_common =_ "MBIM functional descriptor missing\012"
drivers/net/usb/cdc_ncm.c:830 [cdc_ncm]cdc_ncm_bind_common =_ "NCM or ECM functional descriptors missing\012"
drivers/net/usb/cdc_ncm.c:839 [cdc_ncm]cdc_ncm_bind_common =_ "failed to claim data intf\012"
drivers/net/usb/cdc_ncm.c:860 [cdc_ncm]cdc_ncm_bind_common =_ "set interface failed\012"
drivers/net/usb/cdc_ncm.c:505 [cdc_ncm]cdc_ncm_init =_ "Setting CRC mode off\012"
drivers/net/usb/cdc_ncm.c:522 [cdc_ncm]cdc_ncm_init =_ "Setting NTB format to 16-bit\012"
drivers/net/usb/cdc_ncm.c:544 [cdc_ncm]cdc_ncm_init =_ "dwNtbInMaxSize=%u dwNtbOutMaxSize=%u wNdpOutPayloadRemainder=%u wNdpOutDivisor=%u wNdpOutAlignment=%u wNtbOutMaxDatagrams=%u flags=0x%x\012"
drivers/net/usb/cdc_ncm.c:878 [cdc_ncm]cdc_ncm_bind_common =_ "set interface failed\012"
drivers/net/usb/cdc_ncm.c:911 [cdc_ncm]cdc_ncm_bind_common =_ "failed to collect endpoints\012"
drivers/net/usb/cdc_ncm.c:921 [cdc_ncm]cdc_ncm_bind_common =_ "failed to get mac address\012"
drivers/net/usb/cdc_ncm.c:624 [cdc_ncm]cdc_ncm_fix_modulus =_ "Using default alignment: 4 bytes\012"
drivers/net/usb/cdc_ncm.c:638 [cdc_ncm]cdc_ncm_fix_modulus =_ "Using default transmit modulus: 4 bytes\012"
drivers/net/usb/cdc_ncm.c:644 [cdc_ncm]cdc_ncm_fix_modulus =_ "Using default transmit remainder: 0 bytes\012"
drivers/usb/common/ulpi.c:256 [ulpi]ulpi_register =p "registered ULPI PHY: vendor %04x, product %04x\012"
drivers/usb/core/hub.c:3937 [usbcore]usb_set_device_initiated_lpm =p "%s: Can't %s %s state for unconfigured device.\012"
drivers/usb/core/hub.c:464 [usbcore]set_port_led =p "indicator %s status %d\012"
drivers/usb/core/hub.c:3866 [usbcore]usb_req_set_sel =p "Device-initiated %s disabled due to long SEL %llu us or PEL %llu us\012"
drivers/usb/core/hub.c:725 [usbcore]hub_irq =p "transfer --> %d\012"
drivers/usb/core/hub.c:4999 [usbcore]descriptors_changed =p "config index %d, error %d\012"
drivers/usb/core/hub.c:5008 [usbcore]descriptors_changed =p "config index %d changed (#%d)\012"
drivers/usb/core/hub.c:5019 [usbcore]descriptors_changed =p "serial string error %d\012"
drivers/usb/core/hub.c:5022 [usbcore]descriptors_changed =p "serial string changed\012"
drivers/usb/core/hub.c:959 [usbcore]hub_port_logical_disconnect =p "logical disconnect\012"
drivers/usb/core/hub.c:2798 [usbcore]hub_port_wait_reset =p "not %sreset yet, waiting %dms\012"
drivers/usb/core/hub.c:2901 [usbcore]hub_port_reset =p "port_wait_reset: err = %d\012"
drivers/usb/core/hub.c:2939 [usbcore]hub_port_reset =p "hot reset failed, warm reset\012"
drivers/usb/core/hub.c:2946 [usbcore]hub_port_reset =p "not enabled, trying %sreset again...\012"
drivers/usb/core/hub.c:4565 [usbcore]hub_port_init =p "device reset changed speed!\012"
drivers/usb/core/hub.c:4715 [usbcore]hub_port_init =p "device reset changed speed!\012"
drivers/usb/core/hub.c:4792 [usbcore]hub_port_init =p "Failed set isoch delay, error %d\012"
drivers/usb/core/hub.c:4830 [usbcore]hub_port_init =p "ep0 maxpacket = %d\012"
drivers/usb/core/hub.c:5731 [usbcore]usb_reset_and_verify_device =p "device reset not allowed in state %d\012"
drivers/usb/core/hub.c:5894 [usbcore]usb_reset_device =p "device reset not allowed in state %d\012"
drivers/usb/core/hub.c:5900 [usbcore]usb_reset_device =p "%s for root hub!\012"
drivers/usb/core/hub.c:910 [usbcore]hub_power_on =p "enabling power on all ports\012"
drivers/usb/core/hub.c:913 [usbcore]hub_power_on =p "trying to enable port power on non-switchable hub\012"
drivers/usb/core/hub.c:1124 [usbcore]hub_activate =p "status %04x change %04x\012"
drivers/usb/core/hub.c:3794 [usbcore]hub_reset_resume =p "%s\012"
drivers/usb/core/hub.c:3777 [usbcore]hub_resume =p "%s\012"
drivers/usb/core/hub.c:2211 [usbcore]usb_disconnect =p "unregistering device\012"
drivers/usb/core/hub.c:3732 [usbcore]hub_suspend =p "%s\012"
drivers/usb/core/hub.c:2523 [usbcore]usb_new_device =p "udev %d, busnum %d, minor = %d\012"
drivers/usb/core/hub.c:3269 [usbcore]usb_port_suspend =p "won't remote wakeup, status %d\012"
drivers/usb/core/hub.c:3309 [usbcore]usb_port_suspend =p "can't suspend, status %d\012"
drivers/usb/core/hub.c:3327 [usbcore]usb_port_suspend =p "usb %ssuspend, wakeup %d\012"
drivers/usb/core/hub.c:3532 [usbcore]usb_port_resume =p "can't resume usb port, status %d\012"
drivers/usb/core/hub.c:3554 [usbcore]usb_port_resume =p "can't resume, status %d\012"
drivers/usb/core/hub.c:3558 [usbcore]usb_port_resume =p "usb %sresume\012"
drivers/usb/core/hub.c:3482 [usbcore]wait_for_connected =p "Waited %dms for CONNECT\012"
drivers/usb/core/hub.c:3082 [usbcore]check_port_resume_type =p "status %04x.%04x after resume, %d\012"
drivers/usb/core/hub.c:3365 [usbcore]finish_port_resume =p "%s\012"
drivers/usb/core/hub.c:3405 [usbcore]finish_port_resume =p "retry with reset-resume\012"
drivers/usb/core/hub.c:3413 [usbcore]finish_port_resume =p "gone after usb resume? status %d\012"
drivers/usb/core/hub.c:3435 [usbcore]finish_port_resume =p "disable remote wakeup, status %d\012"
drivers/usb/core/hub.c:3594 [usbcore]usb_port_resume =p "can't resume, status %d\012"
drivers/usb/core/hub.c:3615 [usbcore]usb_remote_wakeup =p "usb %sresume\012"
drivers/usb/core/hub.c:4424 [usbcore]hub_port_debounce =p "debounce total %dms stable %dms status 0x%x\012"
drivers/usb/core/hub.c:5506 [usbcore]hub_event =p "state %d ports %d chg %04x evt %04x\012"
drivers/usb/core/hub.c:5524 [usbcore]hub_event =p "Can't autoresume: %d\012"
drivers/usb/core/hub.c:5533 [usbcore]hub_event =p "resetting for error %d\012"
drivers/usb/core/hub.c:5537 [usbcore]hub_event =p "error resetting hub: %d\012"
drivers/usb/core/hub.c:5401 [usbcore]port_event =p "enable change, status %08x\012"
drivers/usb/core/hub.c:5422 [usbcore]port_event =p "over-current change #%u\012"
drivers/usb/core/hub.c:5433 [usbcore]port_event =p "reset change\012"
drivers/usb/core/hub.c:5438 [usbcore]port_event =p "warm reset change\012"
drivers/usb/core/hub.c:5443 [usbcore]port_event =p "link state change\012"
drivers/usb/core/hub.c:3666 [usbcore]hub_handle_remote_wakeup =p "resume, status %d\012"
drivers/usb/core/hub.c:5465 [usbcore]port_event =p "do warm reset\012"
drivers/usb/core/hub.c:5273 [usbcore]hub_port_connect_change =p "status %04x, change %04x, %s\012"
drivers/usb/core/hub.c:5303 [usbcore]hub_port_connect_change =p "can't read device descriptor %d\012"
drivers/usb/core/hub.c:5308 [usbcore]hub_port_connect_change =p "device descriptor has changed\012"
drivers/usb/core/hub.c:5149 [usbcore]hub_port_connect =p "get status %d ?\012"
drivers/usb/core/hub.c:5215 [usbcore]hub_port_connect =p "%dmA power budget left\012"
drivers/usb/core/hub.c:5577 [usbcore]hub_event =p "power change\012"
drivers/usb/core/hub.c:5589 [usbcore]hub_event =p "over-current change\012"
drivers/usb/core/hub.c:6051 [usbcore]usb_hub_adjust_deviceremovable =p "DeviceRemovable is changed to 1 according to platform information.\012"
drivers/usb/core/hub.c:6067 [usbcore]usb_hub_adjust_deviceremovable =p "DeviceRemovable is changed to 1 according to platform information.\012"
drivers/usb/core/hub.c:1458 [usbcore]hub_configure =p "compound device; port removable status: %s\012"
drivers/usb/core/hub.c:1460 [usbcore]hub_configure =p "standalone hub\012"
drivers/usb/core/hub.c:1464 [usbcore]hub_configure =p "ganged power switching\012"
drivers/usb/core/hub.c:1467 [usbcore]hub_configure =p "individual port power switching\012"
drivers/usb/core/hub.c:1471 [usbcore]hub_configure =p "no power switching (usb 1.0)\012"
drivers/usb/core/hub.c:1477 [usbcore]hub_configure =p "global over-current protection\012"
drivers/usb/core/hub.c:1480 [usbcore]hub_configure =p "individual port over-current protection\012"
drivers/usb/core/hub.c:1484 [usbcore]hub_configure =p "no over-current protection\012"
drivers/usb/core/hub.c:1495 [usbcore]hub_configure =p "Single TT\012"
drivers/usb/core/hub.c:1501 [usbcore]hub_configure =p "TT per port\012"
drivers/usb/core/hub.c:1513 [usbcore]hub_configure =p "Unrecognized hub protocol %d\012"
drivers/usb/core/hub.c:1524 [usbcore]hub_configure =p "TT requires at most %d FS bit times (%d ns)\012"
drivers/usb/core/hub.c:1531 [usbcore]hub_configure =p "TT requires at most %d FS bit times (%d ns)\012"
drivers/usb/core/hub.c:1537 [usbcore]hub_configure =p "TT requires at most %d FS bit times (%d ns)\012"
drivers/usb/core/hub.c:1543 [usbcore]hub_configure =p "TT requires at most %d FS bit times (%d ns)\012"
drivers/usb/core/hub.c:1550 [usbcore]hub_configure =p "Port indicators are supported\012"
drivers/usb/core/hub.c:1554 [usbcore]hub_configure =p "power on to power good time: %dms\012"
drivers/usb/core/hub.c:1581 [usbcore]hub_configure =p "hub controller current requirement: %dmA\012"
drivers/usb/core/hub.c:1597 [usbcore]hub_configure =p "%umA bus power budget for each child\012"
drivers/usb/core/hub.c:1609 [usbcore]hub_configure =p "local power source is %s\012"
drivers/usb/core/hub.c:1613 [usbcore]hub_configure =p "%sover-current condition exists\012"
drivers/usb/core/hub.c:1632 [usbcore]hub_configure =p "%p URB allocated \012"
drivers/usb/core/hcd.c:1114 [usbcore]usb_calc_bus_time =p "%s: bogus device speed!\012"
drivers/usb/core/hcd.c:2420 [usbcore]__usb_create_hcd =p "hcd address0 mutex alloc failed\012"
drivers/usb/core/hcd.c:2429 [usbcore]__usb_create_hcd =p "hcd bandwidth mutex alloc failed\012"
drivers/usb/core/hcd.c:2846 [usbcore]usb_remove_hcd =p "roothub graceful disconnect\012"
drivers/usb/core/hcd.c:2689 [usbcore]usb_add_hcd =p "pool alloc failed\012"
drivers/usb/core/hcd.c:2767 [usbcore]usb_add_hcd =p "supports USB remote wakeup\012"
drivers/usb/core/hcd.c:992 [usbcore]register_root_hub =p "can't read %s device descriptor %d\012"
drivers/usb/core/hcd.c:1003 [usbcore]register_root_hub =p "can't read %s bos descriptor %d\012"
drivers/usb/core/hcd.c:813 [usbcore]rh_queue_status =p "not queuing rh status urb\012"
drivers/usb/core/hcd.c:641 [usbcore]rh_call_control =p "root hub device address %d\012"
drivers/usb/core/hcd.c:656 [usbcore]rh_call_control =p "no endpoint features yet\012"
drivers/usb/core/hcd.c:702 [usbcore]rh_call_control =p "CTRL: TypeReq=0x%x val=0x%x idx=0x%x len=%d ==> %d\012"
drivers/usb/core/hcd.c:1619 [usbcore]usb_hcd_unlink_urb =p "hcd_unlink_urb %pK fail %d\012"
drivers/usb/core/hcd.c:1774 [usbcore]usb_hcd_flush_endpoint =p "shutdown urb %pK ep%d%s-%s\012"
drivers/usb/core/hcd.c:2164 [usbcore]hcd_bus_resume =p "usb %sresume\012"
drivers/usb/core/hcd.c:2166 [usbcore]hcd_bus_resume =p "skipped %s of dead bus\012"
drivers/usb/core/hcd.c:2219 [usbcore]hcd_bus_resume =p "bus %s fail, err %d\012"
drivers/usb/core/hcd.c:2112 [usbcore]hcd_bus_suspend =p "bus %ssuspend, wakeup %d\012"
drivers/usb/core/hcd.c:2114 [usbcore]hcd_bus_suspend =p "skipped %s of dead bus\012"
drivers/usb/core/hcd.c:2139 [usbcore]hcd_bus_suspend =p "suspend raced with wakeup event\012"
drivers/usb/core/hcd.c:2152 [usbcore]hcd_bus_suspend =p "bus %s fail, err %d\012"
drivers/usb/core/urb.c:415 [usbcore]usb_submit_urb =p "bogus endpoint ep%d%s in %s (bad maxpacket %d)\012"
drivers/usb/core/message.c:72 [usbcore]usb_start_wait_urb =p "%s timed out on ep%d%s len=%u/%u\012"
drivers/usb/core/message.c:555 [usbcore]usb_sg_wait =p "%s, submit --> %d\012"
drivers/usb/core/message.c:2260 [usbcore]cdc_parse_cdc_header =p "Ignoring descriptor: type %02x, length %ud\012"
drivers/usb/core/message.c:795 [usbcore]usb_get_langid =p "default language 0x%04x\012"
drivers/usb/core/message.c:848 [usbcore]usb_string =p "wrong descriptor type %02x for string %d (\042%s\042)\012"
drivers/usb/core/message.c:1235 [usbcore]usb_disable_device =p "unregistering interface %s\012"
drivers/usb/core/message.c:1258 [usbcore]usb_disable_device =p "%s nuking %s URBs\012"
drivers/usb/core/message.c:1373 [usbcore]usb_set_interface =p "selecting invalid interface %d\012"
drivers/usb/core/message.c:1430 [usbcore]usb_set_interface =p "manual set_interface for iface %d, alt %d\012"
drivers/usb/core/message.c:2021 [usbcore]usb_set_configuration =p "adding %s (config #%d, interface %d)\012"
drivers/usb/core/driver.c:1815 [usbcore]autosuspend_check =p "remote wakeup needed for autosuspend\012"
drivers/usb/core/driver.c:1826 [usbcore]autosuspend_check =p "HCD doesn't handle wakeup requests\012"
drivers/usb/core/driver.c:845 [usbcore]usb_uevent =p "usb %s: already deleted?\012"
drivers/usb/core/driver.c:849 [usbcore]usb_uevent =p "usb %s: bus removed?\012"
drivers/usb/core/driver.c:1251 [usbcore]usb_resume_interface =p "no reset_resume for driver %s?\012"
drivers/usb/core/driver.c:1018 [usbcore]usb_forced_unbind_intf =p "forced unbind\012"
drivers/usb/core/driver.c:255 [usbcore]usb_probe_device =p "%s\012"
drivers/usb/core/driver.c:292 [usbcore]usb_probe_interface =p "%s\012"
drivers/usb/core/driver.c:314 [usbcore]usb_probe_interface =p "%s - got id\012"
drivers/usb/core/config.c:789 [usbcore]usb_parse_configuration =p "skipped %d descriptor%s after %s\012"
drivers/usb/core/config.c:554 [usbcore]usb_parse_interface =p "skipped %d descriptor%s after %s\012"
drivers/usb/core/config.c:475 [usbcore]usb_parse_endpoint =p "skipped %d descriptor%s after %s\012"
drivers/usb/core/file.c:185 [usbcore]usb_register_dev =p "looking for a minor, starting at %d\012"
drivers/usb/core/file.c:236 [usbcore]usb_deregister_dev =p "removing %d minor\012"
drivers/usb/core/devio.c:2368 [usbcore]proc_disconnect_claim =p "disconnect by usbfs\012"
drivers/usb/core/devio.c:2236 [usbcore]proc_ioctl =p "disconnect by usbfs\012"
drivers/usb/core/generic.c:187 [usbcore]usb_choose_configuration =p "configuration #%d chosen from %d choice%s\012"
drivers/usb/core/quirks.c:614 [usbcore]usb_detect_quirks =p "USB quirks for this device: %x\012"
drivers/usb/core/quirks.c:635 [usbcore]usb_detect_interface_quirks =p "USB interface quirks for this device: %x\012"
drivers/usb/core/port.c:344 [usbcore]link_peers =p "usb: failed to peer %s and %s by %s (%s:%s) (%s:%s)\012"
drivers/usb/core/port.c:396 [usbcore]link_peers_report =p "peered to %s\012"
drivers/usb/core/port.c:399 [usbcore]link_peers_report =p "failed to peer to %s (%d)\012"
drivers/usb/core/port.c:233 [usbcore]usb_port_runtime_resume =p "reconnect timeout\012"
drivers/usb/core/hcd-pci.c:476 [usbcore]resume_common =p "can't resume, not suspended!\012"
drivers/usb/core/hcd-pci.c:598 [usbcore]hcd_pci_runtime_resume =p "hcd_pci_runtime_resume: %d\012"
drivers/usb/core/hcd-pci.c:588 [usbcore]hcd_pci_runtime_suspend =p "hcd_pci_runtime_suspend: %d\012"
drivers/usb/core/hcd-pci.c:534 [usbcore]hcd_pci_suspend_noirq =p "wakeup: %d\012"
drivers/usb/core/hcd-pci.c:541 [usbcore]hcd_pci_suspend_noirq =p "--> PCI D0 legacy\012"
drivers/usb/core/hcd-pci.c:545 [usbcore]hcd_pci_suspend_noirq =p "--> PCI %s\012"
drivers/usb/core/hcd-pci.c:128 [usbcore]non_ehci_add =p "FS/LS companion for %s\012"
drivers/usb/core/hcd-pci.c:110 [usbcore]ehci_post_add =p "HS companion for %s\012"
drivers/usb/core/hcd-pci.c:221 [usbcore]usb_hcd_pci_probe =p "controller already in use\012"
drivers/usb/core/hcd-pci.c:228 [usbcore]usb_hcd_pci_probe =p "error mapping memory\012"
drivers/usb/core/hcd-pci.c:249 [usbcore]usb_hcd_pci_probe =p "no i/o regions available\012"
drivers/usb/core/usb-acpi.c:76 [usbcore]usb_acpi_set_power_state =p "acpi: power was set to %d\012"
drivers/usb/core/usb-acpi.c:78 [usbcore]usb_acpi_set_power_state =p "acpi: power failed to be set\012"
drivers/usb/phy/phy.c:465 [phy]usb_get_phy =p "PHY: unable to find transceiver of type %s\012"
drivers/usb/phy/phy.c:507 [phy]devm_usb_get_phy_by_node =p "failed to allocate memory for devres\012"
drivers/usb/phy/phy.c:563 [phy]devm_usb_get_phy_by_phandle =p "device does not have a device node entry\012"
drivers/usb/phy/phy.c:570 [phy]devm_usb_get_phy_by_phandle =p "failed to get %s phandle in %pOF node\012"
drivers/usb/phy/phy-generic.c:250 [phy_generic]usb_phy_gen_create_phy =p "Can't get phy clock: %ld\012"
drivers/usb/phy/phy-generic.c:266 [phy_generic]usb_phy_gen_create_phy =p "Error getting vcc regulator: %ld\012"
drivers/usb/dwc3/gadget.c:785 [dwc3]dwc3_gadget_ep_enable =p "dwc3: invalid parameters\012"
drivers/usb/dwc3/gadget.c:790 [dwc3]dwc3_gadget_ep_enable =p "dwc3: missing wMaxPacketSize\012"
drivers/usb/dwc3/gadget.c:817 [dwc3]dwc3_gadget_ep_disable =p "dwc3: invalid parameters\012"
drivers/usb/dwc3/dwc3-pci.c:164 [dwc3_pci]dwc3_pci_quirks =p "failed to add mapping table\012"
drivers/usb/dwc2/core.c:71 [dwc2]dwc2_backup_global_registers =p "%s\012"
drivers/usb/dwc2/core.c:103 [dwc2]dwc2_restore_global_registers =p "%s\012"
drivers/usb/dwc2/core.c:579 [dwc2]dwc2_force_mode =p "Forcing mode to %s\012"
drivers/usb/dwc2/core.c:628 [dwc2]dwc2_clear_force_mode =p "Clearing force mode bits\012"
drivers/usb/dwc2/core.c:675 [dwc2]dwc2_enable_acg =p "Enabling Active Clock Gating\012"
drivers/usb/dwc2/core.c:263 [dwc2]dwc2_restore_essential_regs =p "%s: restoring essential regs\012"
drivers/usb/dwc2/core.c:374 [dwc2]dwc2_hib_restore_common =p "%s: Restore Done wan't generated here\012"
drivers/usb/dwc2/core.c:376 [dwc2]dwc2_hib_restore_common =p "restore done  generated here\012"
drivers/usb/dwc2/core.c:1042 [dwc2]dwc2_init_fs_ls_pclk_sel =p "Initializing HCFG.FSLSPClkSel to %08x\012"
drivers/usb/dwc2/core.c:1059 [dwc2]dwc2_fs_phy_init =p "FS PHY selected\012"
drivers/usb/dwc2/core.c:1079 [dwc2]dwc2_fs_phy_init =p "Activating transceiver\012"
drivers/usb/dwc2/core.c:1099 [dwc2]dwc2_fs_phy_init =p "FS PHY enabling I2C\012"
drivers/usb/dwc2/core.c:1138 [dwc2]dwc2_hs_phy_init =p "HS ULPI PHY selected\012"
drivers/usb/dwc2/core.c:1151 [dwc2]dwc2_hs_phy_init =p "HS UTMI+ PHY selected\012"
drivers/usb/dwc2/core.c:1207 [dwc2]dwc2_phy_init =p "Setting ULPI FSLS\012"
drivers/usb/dwc2/core_intr.c:644 [dwc2]dwc2_read_common_intr =p "gintsts=%08x  gintmsk=%08x\012"
drivers/usb/dwc2/core_intr.c:669 [dwc2]dwc2_handle_gpwrdn_intr =p "%s: dwc2_handle_gpwrdwn_intr called gpwrdn= %08x\012"
drivers/usb/dwc2/core_intr.c:675 [dwc2]dwc2_handle_gpwrdn_intr =p "%s: GPWRDN_DISCONN_DET\012"
drivers/usb/dwc2/core_intr.c:731 [dwc2]dwc2_handle_gpwrdn_intr =p "%s: GPWRDN_LNSTSCHG\012"
drivers/usb/dwc2/core_intr.c:743 [dwc2]dwc2_handle_gpwrdn_intr =p "%s: GPWRDN_RST_DET\012"
drivers/usb/dwc2/core_intr.c:749 [dwc2]dwc2_handle_gpwrdn_intr =p "%s: GPWRDN_STS_CHGINT\012"
drivers/usb/dwc2/core_intr.c:121 [dwc2]dwc2_handle_otg_intr =p "++OTG Interrupt gotgint=%0x [%s]\012"
drivers/usb/dwc2/core_intr.c:126 [dwc2]dwc2_handle_otg_intr =p " ++OTG Interrupt: Session End Detected++ (%s)\012"
drivers/usb/dwc2/core_intr.c:140 [dwc2]dwc2_handle_otg_intr =p "Session End Detected\012"
drivers/usb/dwc2/core_intr.c:160 [dwc2]dwc2_handle_otg_intr =p " ++OTG Interrupt: Session Request Success Status Change++\012"
drivers/usb/dwc2/core_intr.c:219 [dwc2]dwc2_handle_otg_intr =p "HNP Failed\012"
drivers/usb/dwc2/core_intr.c:234 [dwc2]dwc2_handle_otg_intr =p " ++OTG Interrupt: Host Negotiation Detected++ (%s)\012"
drivers/usb/dwc2/core_intr.c:237 [dwc2]dwc2_handle_otg_intr =p "a_suspend->a_peripheral (%d)\012"
drivers/usb/dwc2/core_intr.c:256 [dwc2]dwc2_handle_otg_intr =p " ++OTG Interrupt: A-Device Timeout Change++\012"
drivers/usb/dwc2/core_intr.c:258 [dwc2]dwc2_handle_otg_intr =p " ++OTG Interrupt: Debounce Done++\012"
drivers/usb/dwc2/core_intr.c:287 [dwc2]dwc2_handle_conn_id_status_change_intr =p " ++Connector ID Status Change Interrupt++  (%s)\012"
drivers/usb/dwc2/core_intr.c:464 [dwc2]dwc2_handle_disconnect_intr =p "++Disconnect Detected Interrupt++ (%s) %s\012"
drivers/usb/dwc2/core_intr.c:315 [dwc2]dwc2_handle_session_req_intr =p "Session request interrupt - lx_state=%d\012"
drivers/usb/dwc2/core_intr.c:398 [dwc2]dwc2_handle_wakeup_detected_intr =p "++Resume or Remote Wakeup Detected Interrupt++\012"
drivers/usb/dwc2/core_intr.c:399 [dwc2]dwc2_handle_wakeup_detected_intr =p "%s lxstate = %d\012"
drivers/usb/dwc2/core_intr.c:351 [dwc2]dwc2_wakeup_from_lpm_l1 =p "Exit from L1 state\012"
drivers/usb/dwc2/core_intr.c:408 [dwc2]dwc2_handle_wakeup_detected_intr =p "DSTS=0x%0x\012"
drivers/usb/dwc2/core_intr.c:486 [dwc2]dwc2_handle_usb_suspend_intr =p "USB SUSPEND\012"
drivers/usb/dwc2/core_intr.c:494 [dwc2]dwc2_handle_usb_suspend_intr =p "%s: DSTS=0x%0x\012"
drivers/usb/dwc2/core_intr.c:499 [dwc2]dwc2_handle_usb_suspend_intr =p "DSTS.Suspend Status=%d HWCFG4.Power Optimize=%d HWCFG4.Hibernation=%d\012"
drivers/usb/dwc2/core_intr.c:504 [dwc2]dwc2_handle_usb_suspend_intr =p "ignore suspend request before enumeration\012"
drivers/usb/dwc2/core_intr.c:544 [dwc2]dwc2_handle_usb_suspend_intr =p "a_peripheral->a_host\012"
drivers/usb/dwc2/core_intr.c:589 [dwc2]dwc2_handle_lpm_intr =p "HIRD_THRES_EN = %d\012"
drivers/usb/dwc2/core_intr.c:592 [dwc2]dwc2_handle_lpm_intr =p "L1 with utmi_l1_suspend_n\012"
drivers/usb/dwc2/core_intr.c:594 [dwc2]dwc2_handle_lpm_intr =p "L1 with utmi_sleep_n\012"
drivers/usb/dwc2/core_intr.c:596 [dwc2]dwc2_handle_lpm_intr =p "Entering Sleep with L1 Gating\012"
drivers/usb/dwc2/core_intr.c:613 [dwc2]dwc2_handle_lpm_intr =p "Core is in L1 sleep glpmcfg=%08x\012"
drivers/usb/dwc2/core_intr.c:831 [dwc2]dwc2_handle_common_intr =p " --Port interrupt received in Device mode--\012"
drivers/usb/dwc2/platform.c:401 [dwc2]dwc2_driver_probe =p "mapped PA %08lx to VA %p\012"
drivers/usb/dwc2/platform.c:414 [dwc2]dwc2_driver_probe =p "registering common handler for irq%d\012"
drivers/usb/dwc2/params.c:769 [dwc2]dwc2_get_hwparams =p "Core Release: %1x.%1x%1x%1x (snpsid=%x)\012"
drivers/usb/dwc2/params.c:545 [dwc2]dwc2_check_param_power_down =p "Partial power down isn't supported by HW\012"
drivers/usb/dwc2/params.c:552 [dwc2]dwc2_check_param_power_down =p "Hibernation isn't supported by HW\012"
drivers/usb/dwc2/hcd.c:4779 [dwc2]_dwc2_hcd_endpoint_reset =p "DWC OTG HCD EP RESET: bEndpointAddress=0x%02x\012"
drivers/usb/dwc2/hcd.c:3738 [dwc2]dwc2_hcd_is_status_changed =p "DWC OTG HCD HUB STATUS DATA: Root port status changed\012"
drivers/usb/dwc2/hcd.c:3740 [dwc2]dwc2_hcd_is_status_changed =p "  port_connect_status_change: %d\012"
drivers/usb/dwc2/hcd.c:3742 [dwc2]dwc2_hcd_is_status_changed =p "  port_reset_change: %d\012"
drivers/usb/dwc2/hcd.c:3744 [dwc2]dwc2_hcd_is_status_changed =p "  port_enable_change: %d\012"
drivers/usb/dwc2/hcd.c:3746 [dwc2]dwc2_hcd_is_status_changed =p "  port_suspend_change: %d\012"
drivers/usb/dwc2/hcd.c:3748 [dwc2]dwc2_hcd_is_status_changed =p "  port_over_current_change: %d\012"
drivers/usb/dwc2/hcd.c:4762 [dwc2]_dwc2_hcd_endpoint_disable =p "DWC OTG HCD EP DISABLE: bEndpointAddress=0x%02x, ep->hcpriv=%p\012"
drivers/usb/dwc2/hcd.c:4190 [dwc2]dwc2_hcd_reset_func =p "USB RESET function called\012"
drivers/usb/dwc2/hcd.c:3252 [dwc2]dwc2_wakeup_detected =p "%s()\012"
drivers/usb/dwc2/hcd.c:3259 [dwc2]dwc2_wakeup_detected =p "Resume: HPRT0=%0x\012"
drivers/usb/dwc2/hcd.c:3263 [dwc2]dwc2_wakeup_detected =p "Clear Resume: HPRT0=%0x\012"
drivers/usb/dwc2/hcd.c:3382 [dwc2]dwc2_hcd_hub_control =p "ClearHubFeature %1xh\012"
drivers/usb/dwc2/hcd.c:3405 [dwc2]dwc2_hcd_hub_control =p "ClearPortFeature USB_PORT_FEAT_ENABLE\012"
drivers/usb/dwc2/hcd.c:3413 [dwc2]dwc2_hcd_hub_control =p "ClearPortFeature USB_PORT_FEAT_SUSPEND\012"
drivers/usb/dwc2/hcd.c:3425 [dwc2]dwc2_hcd_hub_control =p "ClearPortFeature USB_PORT_FEAT_POWER\012"
drivers/usb/dwc2/hcd.c:3436 [dwc2]dwc2_hcd_hub_control =p "ClearPortFeature USB_PORT_FEAT_INDICATOR\012"
drivers/usb/dwc2/hcd.c:3445 [dwc2]dwc2_hcd_hub_control =p "ClearPortFeature USB_PORT_FEAT_C_CONNECTION\012"
drivers/usb/dwc2/hcd.c:3452 [dwc2]dwc2_hcd_hub_control =p "ClearPortFeature USB_PORT_FEAT_C_RESET\012"
drivers/usb/dwc2/hcd.c:3462 [dwc2]dwc2_hcd_hub_control =p "ClearPortFeature USB_PORT_FEAT_C_ENABLE\012"
drivers/usb/dwc2/hcd.c:3473 [dwc2]dwc2_hcd_hub_control =p "ClearPortFeature USB_PORT_FEAT_C_SUSPEND\012"
drivers/usb/dwc2/hcd.c:3479 [dwc2]dwc2_hcd_hub_control =p "ClearPortFeature USB_PORT_FEAT_C_PORT_L1\012"
drivers/usb/dwc2/hcd.c:3485 [dwc2]dwc2_hcd_hub_control =p "ClearPortFeature USB_PORT_FEAT_C_OVER_CURRENT\012"
drivers/usb/dwc2/hcd.c:3498 [dwc2]dwc2_hcd_hub_control =p "GetHubDescriptor\012"
drivers/usb/dwc2/hcd.c:3513 [dwc2]dwc2_hcd_hub_control =p "GetHubStatus\012"
drivers/usb/dwc2/hcd.c:3605 [dwc2]dwc2_hcd_hub_control =p "SetHubFeature\012"
drivers/usb/dwc2/hcd.c:3610 [dwc2]dwc2_hcd_hub_control =p "SetPortFeature\012"
drivers/usb/dwc2/hcd.c:3628 [dwc2]dwc2_hcd_hub_control =p "SetPortFeature - USB_PORT_FEAT_SUSPEND\012"
drivers/usb/dwc2/hcd.c:3287 [dwc2]dwc2_port_suspend =p "%s()\012"
drivers/usb/dwc2/hcd.c:3639 [dwc2]dwc2_hcd_hub_control =p "SetPortFeature - USB_PORT_FEAT_POWER\012"
drivers/usb/dwc2/hcd.c:3654 [dwc2]dwc2_hcd_hub_control =p "SetPortFeature - USB_PORT_FEAT_RESET\012"
drivers/usb/dwc2/hcd.c:3674 [dwc2]dwc2_hcd_hub_control =p "In host mode, hprt0=%08x\012"
drivers/usb/dwc2/hcd.c:3689 [dwc2]dwc2_hcd_hub_control =p "SetPortFeature - USB_PORT_FEAT_INDICATOR\012"
drivers/usb/dwc2/hcd.c:3696 [dwc2]dwc2_hcd_hub_control =p "SetPortFeature - USB_PORT_FEAT_TEST\012"
drivers/usb/dwc2/hcd.c:3716 [dwc2]dwc2_hcd_hub_control =p "Unknown hub control request: %1xh wIndex: %1xh wValue: %1xh\012"
drivers/usb/dwc2/hcd.c:2588 [dwc2]dwc2_assign_and_init_hc =p "No QTDs in QH list\012"
drivers/usb/dwc2/hcd.c:2593 [dwc2]dwc2_assign_and_init_hc =p "No free channel to assign\012"
drivers/usb/dwc2/hcd.c:894 [dwc2]dwc2_hc_halt =p "desc DMA enabled\012"
drivers/usb/dwc2/hcd.c:4716 [dwc2]_dwc2_hcd_urb_dequeue =p "DWC OTG HCD URB Dequeue\012"
drivers/usb/dwc2/hcd.c:4726 [dwc2]_dwc2_hcd_urb_dequeue =p "## urb->hcpriv is NULL ##\012"
drivers/usb/dwc2/hcd.c:1946 [dwc2]dwc2_hcd_urb_dequeue =p "## Urb QTD is NULL ##\012"
drivers/usb/dwc2/hcd.c:1952 [dwc2]dwc2_hcd_urb_dequeue =p "## Urb QTD QH is NULL ##\012"
drivers/usb/dwc2/hcd.c:4742 [dwc2]_dwc2_hcd_urb_dequeue =p "Called usb_hcd_giveback_urb()\012"
drivers/usb/dwc2/hcd.c:4743 [dwc2]_dwc2_hcd_urb_dequeue =p "  urb->status = %d\012"
drivers/usb/dwc2/hcd.c:4232 [dwc2]_dwc2_hcd_start =p "DWC OTG HCD START\012"
drivers/usb/dwc2/hcd.c:2167 [dwc2]dwc2_core_host_init =p "%s(%p)\012"
drivers/usb/dwc2/hcd.c:302 [dwc2]dwc2_config_fifos =p "initial grxfsiz=%08x\012"
drivers/usb/dwc2/hcd.c:308 [dwc2]dwc2_config_fifos =p "new grxfsiz=%08x\012"
drivers/usb/dwc2/hcd.c:312 [dwc2]dwc2_config_fifos =p "initial gnptxfsiz=%08x\012"
drivers/usb/dwc2/hcd.c:319 [dwc2]dwc2_config_fifos =p "new gnptxfsiz=%08x\012"
drivers/usb/dwc2/hcd.c:323 [dwc2]dwc2_config_fifos =p "initial hptxfsiz=%08x\012"
drivers/usb/dwc2/hcd.c:331 [dwc2]dwc2_config_fifos =p "new hptxfsiz=%08x\012"
drivers/usb/dwc2/hcd.c:2266 [dwc2]dwc2_core_host_init =p "%s: Halt channel %d\012"
drivers/usb/dwc2/hcd.c:2283 [dwc2]dwc2_core_host_init =p "Init: Port Power? op_state=%d\012"
drivers/usb/dwc2/hcd.c:2288 [dwc2]dwc2_core_host_init =p "Init: Power Port (%d)\012"
drivers/usb/dwc2/hcd.c:194 [dwc2]dwc2_enable_host_interrupts =p "%s()\012"
drivers/usb/dwc2/hcd.c:4259 [dwc2]_dwc2_hcd_start =p "DWC OTG HCD Has Root Hub\012"
drivers/usb/dwc2/hcd.c:4176 [dwc2]dwc2_hcd_start_func =p "%s() %p\012"
drivers/usb/dwc2/hcd.c:1861 [dwc2]dwc2_hcd_stop =p "DWC OTG HCD STOP\012"
drivers/usb/dwc2/hcd.c:1873 [dwc2]dwc2_hcd_stop =p "PortPower off\012"
drivers/usb/dwc2/hcd.c:2080 [dwc2]dwc2_core_init =p "%s(%p)\012"
drivers/usb/dwc2/hcd.c:110 [dwc2]dwc2_gahbcfg_init =p "Internal DMA Mode\012"
drivers/usb/dwc2/hcd.c:120 [dwc2]dwc2_gahbcfg_init =p "Slave Only Mode\012"
drivers/usb/dwc2/hcd.c:2143 [dwc2]dwc2_core_init =p "Host Mode\012"
drivers/usb/dwc2/hcd.c:2146 [dwc2]dwc2_core_init =p "Device Mode\012"
drivers/usb/dwc2/hcd.c:3173 [dwc2]dwc2_conn_id_status_change =p "%s()\012"
drivers/usb/dwc2/hcd.c:3176 [dwc2]dwc2_conn_id_status_change =p "gotgctl=%0x\012"
drivers/usb/dwc2/hcd.c:3178 [dwc2]dwc2_conn_id_status_change =p "gotgctl.b.conidsts=%d\012"
drivers/usb/dwc2/hcd.c:3184 [dwc2]dwc2_conn_id_status_change =p "connId B\012"
drivers/usb/dwc2/hcd.c:3222 [dwc2]dwc2_conn_id_status_change =p "connId A\012"
drivers/usb/dwc2/hcd.c:4101 [dwc2]dwc2_host_complete =p "## %s: qtd is NULL ##\012"
drivers/usb/dwc2/hcd.c:4106 [dwc2]dwc2_host_complete =p "## %s: qtd->urb is NULL ##\012"
drivers/usb/dwc2/hcd.c:4112 [dwc2]dwc2_host_complete =p "## %s: urb->priv is NULL ##\012"
drivers/usb/dwc2/hcd.c:1801 [dwc2]dwc2_hcd_disconnect =p "Disconnect: PortPower off\012"
drivers/usb/dwc2/hcd.c:4936 [dwc2]dwc2_hcd_free =p "DWC OTG HCD FREE\012"
drivers/usb/dwc2/hcd.c:4953 [dwc2]dwc2_hcd_free =p "HCD Free channel #%i, chan=%p\012"
drivers/usb/dwc2/hcd.c:5022 [dwc2]dwc2_hcd_init =p "DWC OTG HCD INIT\012"
drivers/usb/dwc2/hcd.c:5027 [dwc2]dwc2_hcd_init =p "hcfg=%08x\012"
drivers/usb/dwc2/hcd.c:5269 [dwc2]dwc2_hcd_remove =p "DWC OTG HCD REMOVE\012"
drivers/usb/dwc2/hcd.c:5272 [dwc2]dwc2_hcd_remove =p "hsotg->hcd = %p\012"
drivers/usb/dwc2/hcd.c:5276 [dwc2]dwc2_hcd_remove =p "%s: dwc2_hsotg_to_hcd(hsotg) NULL!\012"
drivers/usb/dwc2/hcd.c:5311 [dwc2]dwc2_backup_host_registers =p "%s\012"
drivers/usb/dwc2/hcd.c:5340 [dwc2]dwc2_restore_host_registers =p "%s\012"
drivers/usb/dwc2/hcd.c:5379 [dwc2]dwc2_host_enter_hibernation =p "Preparing host for hibernation\012"
drivers/usb/dwc2/hcd.c:5463 [dwc2]dwc2_host_enter_hibernation =p "Host hibernation completed\012"
drivers/usb/dwc2/hcd.c:5494 [dwc2]dwc2_host_exit_hibernation =p "%s: called with rem_wakeup = %d reset = %d\012"
drivers/usb/dwc2/hcd.c:5586 [dwc2]dwc2_host_exit_hibernation =p "Host hibernation restore complete\012"
drivers/usb/dwc2/hcd_intr.c:669 [dwc2]dwc2_deactivate_qh =p "## QTD list empty ##\012"
drivers/usb/dwc2/hcd_intr.c:1129 [dwc2]dwc2_hc_stall_intr =p "--Host Channel %d Interrupt: STALL Received--\012"
drivers/usb/dwc2/hcd_intr.c:1521 [dwc2]dwc2_hc_babble_intr =p "--Host Channel %d Interrupt: Babble Error--\012"
drivers/usb/dwc2/hcd_intr.c:1720 [dwc2]dwc2_hc_frmovrun_intr =p "--Host Channel %d Interrupt: Frame Overrun--\012"
drivers/usb/dwc2/hcd_intr.c:1562 [dwc2]dwc2_hc_ahberr_intr =p "--Host Channel %d Interrupt: AHB Error--\012"
drivers/usb/dwc2/hcd_intr.c:1213 [dwc2]dwc2_hc_nak_intr =p "%s: qtd is NULL\012"
drivers/usb/dwc2/hcd_intr.c:1218 [dwc2]dwc2_hc_nak_intr =p "%s: qtd->urb is NULL\012"
drivers/usb/dwc2/hcd_intr.c:1659 [dwc2]dwc2_hc_xacterr_intr =p "--Host Channel %d Interrupt: Transaction Error--\012"
drivers/usb/dwc2/hcd_intr.c:2096 [dwc2]dwc2_hc_n_intr =p "## no QTD queued for channel %d ##\012"
drivers/usb/dwc2/hcd_intr.c:2099 [dwc2]dwc2_hc_n_intr =p "  hcint 0x%08x, hcintmsk 0x%08x, hcint&hcintmsk 0x%08x\012"
drivers/usb/dwc2/hcd_intr.c:1957 [dwc2]dwc2_hc_chhltd_intr_dma =p "%s: Halt channel %d (assume incomplete periodic transfer)\012"
drivers/usb/dwc2/hcd_intr.c:1750 [dwc2]dwc2_hc_datatglerr_intr =p "--Host Channel %d Interrupt: Data Toggle Error--\012"
drivers/usb/dwc2/hcd_queue.c:1366 [dwc2]dwc2_schedule_periodic =p "%s: Channel max transfer size too small for periodic transfer\012"
drivers/usb/dwc2/hcd_queue.c:90 [dwc2]dwc2_periodic_channel_available =p "%s: Total channels: %d, Periodic: %d, Non-periodic: %d\012"
drivers/usb/dwc2/hcd_queue.c:1222 [dwc2]dwc2_do_reserve =p "%s: Insufficient periodic bandwidth for periodic transfer\012"
drivers/usb/dwc2/gadget.c:897 [dwc2]dwc2_gadget_fill_isoc_desc =p "%s: desc chain full\012"
drivers/usb/dwc2/gadget.c:906 [dwc2]dwc2_gadget_fill_isoc_desc =p "%s: Filling ep %d, dir %s isoc desc # %d\012"
drivers/usb/dwc2/gadget.c:1518 [dwc2]dwc2_hsotg_complete_oursetup =p "%s: ep %p, req %p\012"
drivers/usb/dwc2/gadget.c:2241 [dwc2]dwc2_hsotg_rx_data =p "%s: FIFO %d bytes on ep%d but no req (DXEPCTl=0x%08x)\012"
drivers/usb/dwc2/gadget.c:2255 [dwc2]dwc2_hsotg_rx_data =p "%s: read %d/%d, done %d/%d\012"
drivers/usb/dwc2/gadget.c:158 [dwc2]dwc2_hsotg_en_gsint =p "gsintmsk now 0x%08x\012"
drivers/usb/dwc2/gadget.c:2044 [dwc2]dwc2_hsotg_program_zlp =p "Sending zero-length packet on ep%d\012"
drivers/usb/dwc2/gadget.c:2047 [dwc2]dwc2_hsotg_program_zlp =p "Receiving zero-length packet on ep%d\012"
drivers/usb/dwc2/gadget.c:533 [dwc2]dwc2_hsotg_write_fifo =p "%s: left=%d, load=%d, fifo=%d, size %d\012"
drivers/usb/dwc2/gadget.c:541 [dwc2]dwc2_hsotg_write_fifo =p "%s: => can_write1=%d\012"
drivers/usb/dwc2/gadget.c:545 [dwc2]dwc2_hsotg_write_fifo =p "%s: => can_write2=%d\012"
drivers/usb/dwc2/gadget.c:561 [dwc2]dwc2_hsotg_write_fifo =p "%s: no queue slots available (0x%08x)\012"
drivers/usb/dwc2/gadget.c:574 [dwc2]dwc2_hsotg_write_fifo =p "%s: GNPTXSTS=%08x, can=%d, to=%d, max_transfer %d\012"
drivers/usb/dwc2/gadget.c:629 [dwc2]dwc2_hsotg_write_fifo =p "write %d/%d, can_write %d, done %d\012"
drivers/usb/dwc2/gadget.c:2642 [dwc2]dwc2_hsotg_trytx =p "trying to write more for ep%d\012"
drivers/usb/dwc2/gadget.c:373 [dwc2]dwc2_hsotg_init_fifo =p "FIFOs reset, timeout at %d\012"
drivers/usb/dwc2/gadget.c:965 [dwc2]dwc2_gadget_start_isoc_ddma =p "%s: No requests in queue\012"
drivers/usb/dwc2/gadget.c:5119 [dwc2]dwc2_gadget_init_lpm =p "GLPMCFG=0x%08x\012"
drivers/usb/dwc2/gadget.c:3953 [dwc2]dwc2_hsotg_ep_enable =p "%s: ep %s: a 0x%02x, attr 0x%02x, mps 0x%04x, intr %d\012"
drivers/usb/dwc2/gadget.c:3993 [dwc2]dwc2_hsotg_ep_enable =p "%s: read DxEPCTL=0x%08x from 0x%08x\012"
drivers/usb/dwc2/gadget.c:4133 [dwc2]dwc2_hsotg_ep_enable =p "%s: write DxEPCTL=0x%08x\012"
drivers/usb/dwc2/gadget.c:4137 [dwc2]dwc2_hsotg_ep_enable =p "%s: read DxEPCTL=0x%08x\012"
drivers/usb/dwc2/gadget.c:1049 [dwc2]dwc2_hsotg_start_req =p "%s: DxEPCTL=0x%08x, ep %d, dir %s\012"
drivers/usb/dwc2/gadget.c:1061 [dwc2]dwc2_hsotg_start_req =p "ureq->length:%d ureq->actual:%d\012"
drivers/usb/dwc2/gadget.c:1072 [dwc2]dwc2_hsotg_start_req =p "%s: length %d, max-req %d, r %d\012"
drivers/usb/dwc2/gadget.c:1109 [dwc2]dwc2_hsotg_start_req =p "%s: %d@%d/%d, 0x%08x => 0x%08x\012"
drivers/usb/dwc2/gadget.c:1143 [dwc2]dwc2_hsotg_start_req =p "%s: %08x pad => 0x%08x\012"
drivers/usb/dwc2/gadget.c:1157 [dwc2]dwc2_hsotg_start_req =p "%s: %pad => 0x%08x\012"
drivers/usb/dwc2/gadget.c:1173 [dwc2]dwc2_hsotg_start_req =p "ep0 state:%d\012"
drivers/usb/dwc2/gadget.c:1179 [dwc2]dwc2_hsotg_start_req =p "%s: DxEPCTL=0x%08x\012"
drivers/usb/dwc2/gadget.c:1206 [dwc2]dwc2_hsotg_start_req =p "ep%d: failed to become enabled (DXEPCTL=0x%08x)?\012"
drivers/usb/dwc2/gadget.c:1209 [dwc2]dwc2_hsotg_start_req =p "%s: DXEPCTL=0x%08x\012"
drivers/usb/dwc2/gadget.c:1724 [dwc2]dwc2_gadget_start_next_request =p "%s: No more ISOC-IN requests\012"
drivers/usb/dwc2/gadget.c:1727 [dwc2]dwc2_gadget_start_next_request =p "%s: No more ISOC-OUT requests\012"
drivers/usb/dwc2/gadget.c:2088 [dwc2]dwc2_hsotg_complete_request =p "%s: nothing to complete?\012"
drivers/usb/dwc2/gadget.c:2093 [dwc2]dwc2_hsotg_complete_request =p "complete: ep %p %s, req %p, %d => %p\012"
drivers/usb/dwc2/gadget.c:1288 [dwc2]dwc2_hsotg_handle_unaligned_buf_complete =p "%s: %s: status=%d actual-length=%d\012"
drivers/usb/dwc2/gadget.c:1375 [dwc2]dwc2_hsotg_ep_queue =p "%s: req %p: %d@%p, noi=%d, zero=%d, snok=%d\012"
drivers/usb/dwc2/gadget.c:1380 [dwc2]dwc2_hsotg_ep_queue =p "%s: submit request only in active state\012"
drivers/usb/dwc2/gadget.c:1259 [dwc2]dwc2_hsotg_handle_unaligned_buf_start =p "%s: %s: buf=%p length=%d\012"
drivers/usb/dwc2/gadget.c:2008 [dwc2]dwc2_hsotg_enqueue_setup =p "%s: queueing setup request\012"
drivers/usb/dwc2/gadget.c:2016 [dwc2]dwc2_hsotg_enqueue_setup =p "%s already queued???\012"
drivers/usb/dwc2/gadget.c:1863 [dwc2]dwc2_hsotg_stall_ep0 =p "ep0 stall (dir=%d)\012"
drivers/usb/dwc2/gadget.c:1878 [dwc2]dwc2_hsotg_stall_ep0 =p "written DXEPCTL=0x%08x to %08x (DXEPCTL=0x%08x)\012"
drivers/usb/dwc2/gadget.c:4306 [dwc2]dwc2_hsotg_ep_sethalt =p "%s request is pending, cannot halt\012"
drivers/usb/dwc2/gadget.c:1596 [dwc2]dwc2_hsotg_send_reply =p "%s: buff %p, len %d\012"
drivers/usb/dwc2/gadget.c:1983 [dwc2]dwc2_hsotg_complete_setup =p "%s: failed %d\012"
drivers/usb/dwc2/gadget.c:1906 [dwc2]dwc2_hsotg_process_control =p "ctrl Type=%02x, Req=%02x, V=%04x, I=%04x, L=%04x\012"
drivers/usb/dwc2/gadget.c:1640 [dwc2]dwc2_hsotg_process_req_status =p "%s: USB_REQ_GET_STATUS\012"
drivers/usb/dwc2/gadget.c:1753 [dwc2]dwc2_hsotg_process_req_feature =p "%s: %s_FEATURE\012"
drivers/usb/dwc2/gadget.c:1793 [dwc2]dwc2_hsotg_process_req_feature =p "%s: no endpoint for 0x%04x\012"
drivers/usb/dwc2/gadget.c:1952 [dwc2]dwc2_hsotg_process_control =p "driver->setup() ret %d\012"
drivers/usb/dwc2/gadget.c:2363 [dwc2]dwc2_hsotg_handle_outdone =p "%s: no request active\012"
drivers/usb/dwc2/gadget.c:2368 [dwc2]dwc2_hsotg_handle_outdone =p "zlp packet received\012"
drivers/usb/dwc2/gadget.c:2403 [dwc2]dwc2_hsotg_handle_outdone =p "%s: got %d/%d (short not ok) => error\012"
drivers/usb/dwc2/gadget.c:3862 [dwc2]dwc2_hsotg_ep_stop_xfr =p "%s: stopping transfer on %s\012"
drivers/usb/dwc2/gadget.c:4169 [dwc2]dwc2_hsotg_ep_disable =p "%s(ep %p)\012"
drivers/usb/dwc2/gadget.c:4192 [dwc2]dwc2_hsotg_ep_disable =p "%s: DxEPCTL=0x%08x\012"
drivers/usb/dwc2/gadget.c:4250 [dwc2]dwc2_hsotg_ep_dequeue =p "ep_dequeue(%p,%p)\012"
drivers/usb/dwc2/gadget.c:2665 [dwc2]dwc2_hsotg_complete_in =p "XferCompl but no req\012"
drivers/usb/dwc2/gadget.c:2671 [dwc2]dwc2_hsotg_complete_in =p "zlp packet sent\012"
drivers/usb/dwc2/gadget.c:2686 [dwc2]dwc2_hsotg_complete_in =p "Invalid Test #%d\012"
drivers/usb/dwc2/gadget.c:2718 [dwc2]dwc2_hsotg_complete_in =p "%s: adjusting size done %d => %d\012"
drivers/usb/dwc2/gadget.c:2722 [dwc2]dwc2_hsotg_complete_in =p "req->length:%d req->actual:%d req->zero:%d\012"
drivers/usb/dwc2/gadget.c:2725 [dwc2]dwc2_hsotg_complete_in =p "%s trying more for req...\012"
drivers/usb/dwc2/gadget.c:2995 [dwc2]dwc2_hsotg_epint =p "%s: ep%d(%s) DxEPINT=0x%08x\012"
drivers/usb/dwc2/gadget.c:3015 [dwc2]dwc2_hsotg_epint =p "%s: XferCompl: DxEPCTL=0x%08x, DXEPTSIZ=%08x\012"
drivers/usb/dwc2/gadget.c:2797 [dwc2]dwc2_gadget_handle_ep_disabled =p "%s: EPDisbld\012"
drivers/usb/dwc2/gadget.c:2828 [dwc2]dwc2_gadget_handle_ep_disabled =p "%s: complete_ep 0x%p, ep->queue empty!\012"
drivers/usb/dwc2/gadget.c:3059 [dwc2]dwc2_hsotg_epint =p "%s: AHBErr\012"
drivers/usb/dwc2/gadget.c:3062 [dwc2]dwc2_hsotg_epint =p "%s: Setup/Timeout\012"
drivers/usb/dwc2/gadget.c:3080 [dwc2]dwc2_hsotg_epint =p "%s: StsPhseRcvd\012"
drivers/usb/dwc2/gadget.c:3104 [dwc2]dwc2_hsotg_epint =p "%s: B2BSetup/INEPNakEff\012"
drivers/usb/dwc2/gadget.c:3107 [dwc2]dwc2_hsotg_epint =p "%s: BNA interrupt\012"
drivers/usb/dwc2/gadget.c:3116 [dwc2]dwc2_hsotg_epint =p "%s: ep%d: INTknTXFEmpMsk\012"
drivers/usb/dwc2/gadget.c:3129 [dwc2]dwc2_hsotg_epint =p "%s: ep%d: TxFIFOEmpty\012"
drivers/usb/dwc2/gadget.c:4825 [dwc2]dwc2_gadget_init =p "NonPeriodic TXFIFO size: %d\012"
drivers/usb/dwc2/gadget.c:4826 [dwc2]dwc2_gadget_init =p "RXFIFO size: %d\012"
drivers/usb/dwc2/gadget.c:4992 [dwc2]dwc2_backup_device_registers =p "%s\012"
drivers/usb/dwc2/gadget.c:5048 [dwc2]dwc2_restore_device_registers =p "%s\012"
drivers/usb/dwc2/gadget.c:5142 [dwc2]dwc2_gadget_program_ref_clk =p "GREFCLK=0x%08x\012"
drivers/usb/dwc2/gadget.c:3466 [dwc2]dwc2_hsotg_core_init_disconnected =p "EP0: DIEPCTL0=0x%08x, DOEPCTL0=0x%08x\012"
drivers/usb/dwc2/gadget.c:3489 [dwc2]dwc2_hsotg_core_init_disconnected =p "DCTL=0x%08x\012"
drivers/usb/dwc2/gadget.c:3531 [dwc2]dwc2_hsotg_core_init_disconnected =p "EP0: DIEPCTL0=0x%08x, DOEPCTL0=0x%08x\012"
drivers/usb/dwc2/gadget.c:3663 [dwc2]dwc2_hsotg_irq =p "%s: %08x %08x (%08x) retry %d\012"
drivers/usb/dwc2/gadget.c:3668 [dwc2]dwc2_hsotg_irq =p "%s: USBRstDet\012"
drivers/usb/dwc2/gadget.c:3683 [dwc2]dwc2_hsotg_irq =p "%s: USBRst\012"
drivers/usb/dwc2/gadget.c:3685 [dwc2]dwc2_hsotg_irq =p "GNPTXSTS=%08x\012"
drivers/usb/dwc2/gadget.c:3154 [dwc2]dwc2_hsotg_irq_enumdone =p "EnumDone (DSTS=0x%08x)\012"
drivers/usb/dwc2/gadget.c:3217 [dwc2]dwc2_hsotg_irq_enumdone =p "EP0: DIEPCTL0=0x%08x, DOEPCTL0=0x%08x\012"
drivers/usb/dwc2/gadget.c:3715 [dwc2]dwc2_hsotg_irq =p "%s: daint=%08x\012"
drivers/usb/dwc2/gadget.c:3733 [dwc2]dwc2_hsotg_irq =p "NPTxFEmp\012"
drivers/usb/dwc2/gadget.c:3746 [dwc2]dwc2_hsotg_irq =p "PTxFEmp\012"
drivers/usb/dwc2/gadget.c:2467 [dwc2]dwc2_hsotg_handle_rx =p "%s: GRXSTSP=0x%08x (%d@%d)\012"
drivers/usb/dwc2/gadget.c:2471 [dwc2]dwc2_hsotg_handle_rx =p "GLOBALOUTNAK\012"
drivers/usb/dwc2/gadget.c:2476 [dwc2]dwc2_hsotg_handle_rx =p "OutDone (Frame=0x%08x)\012"
drivers/usb/dwc2/gadget.c:2486 [dwc2]dwc2_hsotg_handle_rx =p "SetupDone (Frame=0x%08x, DOPEPCTL=0x%08x)\012"
drivers/usb/dwc2/gadget.c:2504 [dwc2]dwc2_hsotg_handle_rx =p "SetupRX (Frame=0x%08x, DOPEPCTL=0x%08x)\012"
drivers/usb/dwc2/gadget.c:3765 [dwc2]dwc2_hsotg_irq =p "GINTSTS_ErlySusp\012"
drivers/usb/dwc2/gadget.c:3789 [dwc2]dwc2_hsotg_irq =p "GOUTNakEff triggered\012"
drivers/usb/dwc2/gadget.c:3566 [dwc2]dwc2_gadget_handle_incomplete_isoc_in =p "Incomplete isoc in interrupt received:\012"
drivers/usb/dwc2/gadget.c:3611 [dwc2]dwc2_gadget_handle_incomplete_isoc_out =p "%s: GINTSTS_INCOMPL_SOOUT\012"
drivers/usb/dwc2/gadget.c:265 [dwc2]dwc2_gadget_wkup_alert_handler =p "%s: Wkup_Alert_Int\012"
drivers/usb/dwc2/gadget.c:4403 [dwc2]dwc2_hsotg_init =p "GRXFSIZ=0x%08x, GNPTXFSIZ=0x%08x\012"
drivers/usb/dwc2/gadget.c:4543 [dwc2]dwc2_hsotg_pullup =p "%s: is_on: %d op_state: %d\012"
drivers/usb/dwc2/gadget.c:4575 [dwc2]dwc2_hsotg_vbus_session =p "%s: is_active: %d\012"
drivers/usb/dwc2/gadget.c:5159 [dwc2]dwc2_gadget_enter_hibernation =p "Start of hibernation completed\012"
drivers/usb/dwc2/gadget.c:5209 [dwc2]dwc2_gadget_enter_hibernation =p "Hibernation completed\012"
drivers/usb/dwc2/gadget.c:5239 [dwc2]dwc2_gadget_exit_hibernation =p "Already exited from Hibernation\012"
drivers/usb/dwc2/gadget.c:5244 [dwc2]dwc2_gadget_exit_hibernation =p "%s: called with rem_wakeup = %d reset = %d\012"
drivers/usb/dwc2/gadget.c:5316 [dwc2]dwc2_gadget_exit_hibernation =p "Hibernation recovery completes here\012"
drivers/usb/isp1760/isp1760-hcd.c:1000 [isp1760]check_int_transfer =p "%s: underrun during uFrame %d\012"
drivers/usb/isp1760/isp1760-hcd.c:1006 [isp1760]check_int_transfer =p "%s: transaction error during uFrame %d\012"
drivers/usb/isp1760/isp1760-hcd.c:1013 [isp1760]check_int_transfer =p "%s: babble error during uFrame %d\012"
drivers/usb/isp1760/isp1760-hcd.c:1050 [isp1760]check_atl_transfer =p "PID error; reloading ptd\012"
drivers/usb/isp1760/isp1760-udc.c:254 [isp1760]isp1760_udc_transmit =p "%s: transferring %u bytes (%u/%u done)\012"
drivers/usb/isp1760/isp1760-udc.c:131 [isp1760]isp1760_udc_request_complete =p "completing request %p with status %d\012"
drivers/usb/isp1760/isp1760-udc.c:403 [isp1760]__isp1760_udc_set_halt =p "%s: %s halt on ep%02x\012"
drivers/usb/isp1760/isp1760-udc.c:407 [isp1760]__isp1760_udc_set_halt =p "%s: ep%02x is isochronous\012"
drivers/usb/isp1760/isp1760-udc.c:155 [isp1760]isp1760_udc_ctrl_send_stall =p "%s(ep%02x)\012"
drivers/usb/isp1760/isp1760-udc.c:953 [isp1760]__isp1760_ep_set_halt =p "%s: ep%02x is disabled\012"
drivers/usb/isp1760/isp1760-udc.c:962 [isp1760]__isp1760_ep_set_halt =p "%s: ep%02x has request pending\012"
drivers/usb/isp1760/isp1760-udc.c:1011 [isp1760]isp1760_ep_set_wedge =p "%s: set wedge on ep%02x)\012"
drivers/usb/isp1760/isp1760-udc.c:995 [isp1760]isp1760_ep_set_halt =p "%s: %s halt on ep%02x\012"
drivers/usb/isp1760/isp1760-udc.c:915 [isp1760]isp1760_ep_dequeue =p "%s(ep%02x)\012"
drivers/usb/isp1760/isp1760-udc.c:776 [isp1760]isp1760_ep_disable =p "%s\012"
drivers/usb/isp1760/isp1760-udc.c:781 [isp1760]isp1760_ep_disable =p "%s: endpoint not enabled\012"
drivers/usb/isp1760/isp1760-udc.c:715 [isp1760]isp1760_ep_enable =p "%s\012"
drivers/usb/isp1760/isp1760-udc.c:729 [isp1760]isp1760_ep_enable =p "%s: invalid descriptor type %u addr %02x ep addr %02x max packet size %u/%u\012"
drivers/usb/isp1760/isp1760-udc.c:746 [isp1760]isp1760_ep_enable =p "%s: control endpoints unsupported\012"
drivers/usb/isp1760/isp1760-udc.c:1237 [isp1760]isp1760_udc_stop =p "%s\012"
drivers/usb/isp1760/isp1760-udc.c:1214 [isp1760]isp1760_udc_start =p "starting UDC with driver %s\012"
drivers/usb/isp1760/isp1760-udc.c:1227 [isp1760]isp1760_udc_start =p "UDC started with driver %s\012"
drivers/usb/isp1760/isp1760-udc.c:1162 [isp1760]isp1760_udc_wakeup =p "%s\012"
drivers/usb/isp1760/isp1760-udc.c:1070 [isp1760]isp1760_udc_disconnect =p "Device disconnected in state %u\012"
drivers/usb/isp1760/isp1760-udc.c:188 [isp1760]isp1760_udc_receive =p "%s: received %u bytes (%u/%u done)\012"
drivers/usb/isp1760/isp1760-udc.c:226 [isp1760]isp1760_udc_receive =p "%s: req %p actual/length %u/%u maxpacket %u packet size %u\012"
drivers/usb/isp1760/isp1760-udc.c:842 [isp1760]isp1760_ep_queue =p "%s: req %p (%u bytes%s) ep %p(0x%02x)\012"
drivers/usb/isp1760/isp1760-udc.c:851 [isp1760]isp1760_ep_queue =p "%s: invalid length %u for req %p\012"
drivers/usb/isp1760/isp1760-udc.c:859 [isp1760]isp1760_ep_queue =p "%s: transmitting req %p\012"
drivers/usb/isp1760/isp1760-udc.c:877 [isp1760]isp1760_ep_queue =p "%s: invalid ep0 state\012"
drivers/usb/isp1760/isp1760-udc.c:892 [isp1760]isp1760_ep_queue =p "%s: can't queue request to disabled ep%02x\012"
drivers/usb/isp1760/isp1760-udc.c:1274 [isp1760]isp1760_udc_irq =p "%s(VBUS)\012"
drivers/usb/isp1760/isp1760-udc.c:1282 [isp1760]isp1760_udc_irq =p "%s(BRST)\012"
drivers/usb/isp1760/isp1760-udc.c:1291 [isp1760]isp1760_udc_irq =p "%s(EPTX%u)\012"
drivers/usb/isp1760/isp1760-udc.c:330 [isp1760]isp1760_ep_tx_complete =p "TX IRQ: invalid endpoint state %u\012"
drivers/usb/isp1760/isp1760-udc.c:348 [isp1760]isp1760_ep_tx_complete =p "%s: ep%02x has no request queued\012"
drivers/usb/isp1760/isp1760-udc.c:363 [isp1760]isp1760_ep_tx_complete =p "TX IRQ: req %p actual/length %u/%u maxpacket %u packet size %u zero %u need zlp %u\012"
drivers/usb/isp1760/isp1760-udc.c:1296 [isp1760]isp1760_udc_irq =p "%s(EPRX%u)\012"
drivers/usb/isp1760/isp1760-udc.c:289 [isp1760]isp1760_ep_rx_ready =p "%s: invalid ep0 state %u\012"
drivers/usb/isp1760/isp1760-udc.c:296 [isp1760]isp1760_ep_rx_ready =p "%s: ep%02x is disabled\012"
drivers/usb/isp1760/isp1760-udc.c:304 [isp1760]isp1760_ep_rx_ready =p "%s: ep%02x (%p) has no request queued\012"
drivers/usb/isp1760/isp1760-udc.c:1302 [isp1760]isp1760_udc_irq =p "%s(EP0SETUP)\012"
drivers/usb/isp1760/isp1760-udc.c:671 [isp1760]isp1760_ep0_setup =p "unexpected SETUP packet\012"
drivers/usb/isp1760/isp1760-udc.c:692 [isp1760]isp1760_ep0_setup =p "%s: bRequestType 0x%02x bRequest 0x%02x wValue 0x%04x wIndex 0x%04x wLength 0x%04x\012"
drivers/usb/isp1760/isp1760-udc.c:489 [isp1760]isp1760_udc_get_status =p "%s: status 0x%04x\012"
drivers/usb/isp1760/isp1760-udc.c:497 [isp1760]isp1760_udc_set_address =p "invalid device address %u\012"
drivers/usb/isp1760/isp1760-udc.c:504 [isp1760]isp1760_udc_set_address =p "can't set address in state %u\012"
drivers/usb/isp1760/isp1760-udc.c:1308 [isp1760]isp1760_udc_irq =p "%s(RESM)\012"
drivers/usb/isp1760/isp1760-udc.c:1313 [isp1760]isp1760_udc_irq =p "%s(SUSP)\012"
drivers/usb/isp1760/isp1760-udc.c:1324 [isp1760]isp1760_udc_irq =p "%s(HS_STA)\012"
drivers/usb/host/pci-quirks.c:687 [pci_quirks]uhci_check_and_reset_hc =p "%s: legsup = 0x%04x\012"
drivers/usb/host/pci-quirks.c:695 [pci_quirks]uhci_check_and_reset_hc =p "%s: cmd = 0x%04x\012"
drivers/usb/host/pci-quirks.c:702 [pci_quirks]uhci_check_and_reset_hc =p "%s: intr = 0x%04x\012"
drivers/usb/host/pci-quirks.c:708 [pci_quirks]uhci_check_and_reset_hc =p "Performing full reset\012"
drivers/usb/host/pci-quirks.c:292 [pci_quirks]usb_hcd_amd_remote_wakeup_quirk =p "QUIRK: Enable AMD remote wakeup fix\012"
drivers/usb/host/pci-quirks.c:1086 [pci_quirks]usb_enable_intel_xhci_ports =p "Configurable ports to enable SuperSpeed: 0x%x\012"
drivers/usb/host/pci-quirks.c:1099 [pci_quirks]usb_enable_intel_xhci_ports =p "USB 3.0 ports that are now enabled under xHCI: 0x%x\012"
drivers/usb/host/pci-quirks.c:1109 [pci_quirks]usb_enable_intel_xhci_ports =p "Configurable USB 2.0 ports to hand over to xCHI: 0x%x\012"
drivers/usb/host/pci-quirks.c:1122 [pci_quirks]usb_enable_intel_xhci_ports =p "USB 2.0 ports that are now switched over to xHCI: 0x%x\012"
drivers/usb/host/pci-quirks.c:871 [pci_quirks]ehci_bios_handoff =p "EHCI: BIOS handoff\012"
drivers/usb/host/ehci-q.c:171 [ehci_hcd]ehci_clear_tt_buffer =p "clear tt buffer port %d, a%d ep%d t%08x\012"
drivers/usb/host/ehci-q.c:361 [ehci_hcd]qh_completions =p "detected DataBufferErr for urb %p ep%d%s len %d, qtd %p [qh %p]\012"
drivers/usb/host/ehci-q.c:377 [ehci_hcd]qh_completions =p "detected XactErr len %zu/%zu retry %d\012"
drivers/usb/host/ehci-q.c:240 [ehci_hcd]qtd_copy_status =p "devpath %s ep%d%s 3strikes\012"
drivers/usb/host/ehci-sched.c:203 [ehci_hcd]bandwidth_dbg =p "ep %02x: %s %s @ %u+%u (%u.%u+%u) [%u/%u us] mask %04x\012"
drivers/usb/host/ehci-mem.c:58 [ehci_hcd]qh_destroy =p "unused qh not empty!\012"
drivers/usb/host/ehci-mem.c:88 [ehci_hcd]ehci_qh_alloc =p "no dummy td\012"
drivers/usb/host/ehci-q.c:793 [ehci_hcd]qh_make =p "bogus qh maxpacket %d\012"
drivers/usb/host/ehci-q.c:933 [ehci_hcd]qh_make =p "bogus dev %p speed %d\012"
drivers/usb/host/ehci-sched.c:861 [ehci_hcd]qh_schedule =p "reused qh %p schedule\012"
drivers/usb/host/ehci-hcd.c:1306 [ehci_hcd]ehci_hcd_init =p "%s: block sizes: qh %zd qtd %zd itd %zd sitd %zd\012"
drivers/usb/host/ehci-sched.c:1166 [ehci_hcd]iso_stream_find =p "dev %s ep%d%s, not iso??\012"
drivers/usb/host/ehci-dbg.c:275 [ehci_hcd]dbg_cmd =p "%s\012"
drivers/usb/host/ehci-timer.c:114 [ehci_hcd]ehci_poll_ASS =p "Waited too long for the async schedule status (%x/%x), giving up\012"
drivers/usb/host/ehci-timer.c:354 [ehci_hcd]ehci_iaa_watchdog =p "IAA watchdog: status %x cmd %x\012"
drivers/usb/host/ehci-timer.c:160 [ehci_hcd]ehci_poll_PSS =p "Waited too long for the periodic schedule status (%x/%x), giving up\012"
drivers/usb/host/ehci-sched.c:543 [ehci_hcd]qh_link_periodic =p "link qh%d-%04x/%p start %d [%d/%d us]\012"
drivers/usb/host/ehci-sched.c:636 [ehci_hcd]qh_unlink_periodic =p "unlink qh%d-%04x/%p start %d [%d/%d us]\012"
drivers/usb/host/ehci-dbg.c:28 [ehci_hcd]dbg_hcs_params =p "%s hcs_params 0x%x dbg=%d%s cc=%d pcc=%d%s%s ports=%d\012"
drivers/usb/host/ehci-dbg.c:42 [ehci_hcd]dbg_hcs_params =p "%s portroute %s\012"
drivers/usb/host/ehci-dbg.c:61 [ehci_hcd]dbg_hcc_params =p "%s hcc_params %04x caching frame %s%s%s\012"
drivers/usb/host/ehci-dbg.c:75 [ehci_hcd]dbg_hcc_params =p "%s hcc_params %04x thresh %d uframes %s%s%s%s%s%s%s\012"
drivers/usb/host/ehci-mem.c:222 [ehci_hcd]ehci_mem_init =p "couldn't init memory\012"
drivers/usb/host/ehci-hcd.c:536 [ehci_hcd]ehci_init =p "enable per-port change event\012"
drivers/usb/host/ehci-hcd.c:552 [ehci_hcd]ehci_init =p "park %d\012"
drivers/usb/host/ehci-hcd.c:422 [ehci_hcd]ehci_stop =p "stop\012"
drivers/usb/host/ehci-dbg.c:266 [ehci_hcd]dbg_status =p "%s\012"
drivers/usb/host/ehci-sched.c:2476 [ehci_hcd]scan_isoc =p "corrupt type %d frame %d shadow %p\012"
drivers/usb/host/ehci-hub.c:222 [ehci_hcd]ehci_bus_suspend =p "suspend root hub\012"
drivers/usb/host/ehci-hub.c:242 [ehci_hcd]ehci_bus_suspend =p "suspend failed because a port is resuming\012"
drivers/usb/host/ehci-hub.c:328 [ehci_hcd]ehci_bus_suspend =p "Port %d phy low-power mode %s\012"
drivers/usb/host/ehci-hcd.c:709 [ehci_hcd]ehci_irq =p "device removed\012"
drivers/usb/host/ehci-hcd.c:757 [ehci_hcd]ehci_irq =p "IAA with IAAD still set?\012"
drivers/usb/host/ehci-hcd.c:804 [ehci_hcd]ehci_irq =p "port %d remote wakeup\012"
drivers/usb/host/ehci-sched.c:1540 [ehci_hcd]iso_stream_schedule =p "iso sched full %p"
drivers/usb/host/ehci-sched.c:1595 [ehci_hcd]iso_stream_schedule =p "request %p would overflow (%u-%u < %u mod %u)\012"
drivers/usb/host/ehci-sched.c:1625 [ehci_hcd]iso_stream_schedule =p "iso underrun %p (%u+%u < %u) [%u]\012"
drivers/usb/host/ehci-sched.c:1651 [ehci_hcd]iso_stream_schedule =p "request %p would overflow (%u+%u >= %u)\012"
drivers/usb/host/ehci-sched.c:1933 [ehci_hcd]itd_submit =p "can't get iso stream\012"
drivers/usb/host/ehci-sched.c:1938 [ehci_hcd]itd_submit =p "can't change iso interval %d --> %d\012"
drivers/usb/host/ehci-sched.c:1956 [ehci_hcd]itd_submit =p "can't init itds\012"
drivers/usb/host/ehci-sched.c:2312 [ehci_hcd]sitd_submit =p "can't get iso stream\012"
drivers/usb/host/ehci-sched.c:2317 [ehci_hcd]sitd_submit =p "can't change iso interval %d --> %d\012"
drivers/usb/host/ehci-sched.c:2333 [ehci_hcd]sitd_submit =p "can't init sitds\012"
drivers/usb/host/ehci-hub.c:584 [ehci_hcd]check_reset_complete =p "Failed to enable port %d on root hub TT\012"
drivers/usb/host/ehci-hub.c:589 [ehci_hcd]check_reset_complete =p "port %d full speed --> companion\012"
drivers/usb/host/ehci-hub.c:601 [ehci_hcd]check_reset_complete =p "port %d reset complete, port enabled\012"
drivers/usb/host/ehci-hub.c:1102 [ehci_hcd]ehci_hub_control =p "port %d --> companion\012"
drivers/usb/host/ehci-dbg.c:284 [ehci_hcd]dbg_port =p "%s\012"
drivers/usb/host/ehci-hub.c:1204 [ehci_hcd]ehci_hub_control =p "Port%d phy low pwr mode %s\012"
drivers/usb/host/ehci-hub.c:1233 [ehci_hcd]ehci_hub_control =p "port %d low speed --> companion\012"
drivers/usb/host/ehci-hub.c:403 [ehci_hcd]ehci_bus_resume =p "resume root hub%s\012"
drivers/usb/host/ehci-hub.c:430 [ehci_hcd]ehci_bus_resume =p "Port status(0x%x) is wrong\012"
drivers/usb/host/ehci-hub.c:116 [ehci_hcd]ehci_handover_companion_ports =p "failed handover port %d: %x\012"
drivers/usb/host/ehci-pci.c:71 [ehci_pci]ehci_pci_reinit =p "MWI active\012"
drivers/usb/host/ehci-pci.c:276 [ehci_pci]ehci_pci_setup =p "bogus port configuration: cc=%d x pcc=%d < ports=%d\012"
drivers/usb/host/ehci-orion.c:222 [ehci_orion]ehci_orion_drv_probe =p "Initializing Orion-SoC USB Host Controller\012"
drivers/usb/host/ohci-q.c:792 [ohci_hcd]td_done =p "urb %p iso td %p (%d) len %d cc %d\012"
drivers/usb/host/ohci-q.c:826 [ohci_hcd]td_done =p "urb %p td %p (%d) cc %d, len=%d/%d\012"
drivers/usb/host/ohci-q.c:293 [ohci_hcd]periodic_unlink =p "unlink %sed %p branch %d [%dus.], interval %d\012"
drivers/usb/host/ohci-q.c:251 [ohci_hcd]ed_schedule =p "ERR %d, interval %d msecs, load %d\012"
drivers/usb/host/ohci-q.c:149 [ohci_hcd]periodic_link =p "link %sed %p branch %d [%dus.], interval %d\012"
drivers/usb/host/ohci-mem.c:121 [ohci_hcd]td_free =p "no hash for td %p\012"
drivers/usb/host/ohci-dbg.c:61 [ohci_hcd]ohci_dump_intr_mask =p "%s 0x%08x%s%s%s%s%s%s%s%s%s\012"
drivers/usb/host/ohci-q.c:894 [ohci_hcd]ed_halted =p "urb %p path %s ep%d%s %08x cc %d --> status %d\012"
drivers/usb/host/ohci-dbg.c:72 [ohci_hcd]maybe_print_eds =p "%s %08x\012"
drivers/usb/host/ohci-hcd.c:1279 [ohci_hcd]ohci_hcd_mod_init =p "%s: block sizes: ed %zd td %zd\012"
drivers/usb/host/ohci-dbg.c:111 [ohci_hcd]ohci_dump_status =p "OHCI %d.%d, %s legacy support registers, rh state %s\012"
drivers/usb/host/ohci-dbg.c:126 [ohci_hcd]ohci_dump_status =p "control 0x%03x%s%s%s HCFS=%s%s%s%s%s CBSR=%d\012"
drivers/usb/host/ohci-dbg.c:136 [ohci_hcd]ohci_dump_status =p "cmdstatus 0x%05x SOC=%d%s%s%s%s\012"
drivers/usb/host/ohci-dbg.c:213 [ohci_hcd]ohci_dump_roothub =p "roothub.a %08x POTPGT=%d%s%s%s%s%s NDP=%d(%d)\012"
drivers/usb/host/ohci-dbg.c:220 [ohci_hcd]ohci_dump_roothub =p "roothub.b %08x PPCM=%04x DR=%04x\012"
drivers/usb/host/ohci-dbg.c:231 [ohci_hcd]ohci_dump_roothub =p "roothub.status %08x%s%s%s%s%s%s\012"
drivers/usb/host/ohci-dbg.c:236 [ohci_hcd]ohci_dump_roothub =p "roothub.portstatus [%d] 0x%08x%s%s%s%s%s%s%s%s%s%s%s%s\012"
drivers/usb/host/ohci-dbg.c:242 [ohci_hcd]ohci_dump =p "OHCI controller state\012"
drivers/usb/host/ohci-dbg.c:248 [ohci_hcd]ohci_dump =p "hcca frame #%04x\012"
drivers/usb/host/ohci-hcd.c:790 [ohci_hcd]io_watchdog_func =p "takeback pending TD for dev %d ep 0x%x\012"
drivers/usb/host/ohci-hcd.c:479 [ohci_hcd]ohci_init =p "USB HC TakeOver from BIOS/SMM\012"
drivers/usb/host/ohci-dbg.c:776 [ohci_hcd]create_debug_files =p "created debug files\012"
drivers/usb/host/ohci-hub.c:56 [ohci_hcd]ohci_rh_suspend =p "resume/suspend?\012"
drivers/usb/host/ohci-hub.c:64 [ohci_hcd]ohci_rh_suspend =p "needs reinit!\012"
drivers/usb/host/ohci-hub.c:68 [ohci_hcd]ohci_rh_suspend =p "already suspended\012"
drivers/usb/host/ohci-hub.c:73 [ohci_hcd]ohci_rh_suspend =p "%s root hub\012"
drivers/usb/host/ohci-hub.c:85 [ohci_hcd]ohci_rh_suspend =p "stopping schedules ...\012"
drivers/usb/host/ohci-hub.c:753 [ohci_hcd]ohci_hub_control =p "%s roothub.portstatus [%d] = 0x%08x%s%s%s%s%s%s%s%s%s%s%s%s\012"
drivers/usb/host/ohci-hub.c:651 [ohci_hcd]root_port_reset =p "port[%d] reset timeout, stat %08x\012"
drivers/usb/host/ohci-hcd.c:560 [ohci_hcd]ohci_run =p "fminterval delta %d\012"
drivers/usb/host/ohci-hcd.c:646 [ohci_hcd]ohci_run =p "enabling initreset quirk\012"
drivers/usb/host/ohci-hcd.c:1040 [ohci_hcd]ohci_restart =p "abort schedule...\012"
drivers/usb/host/ohci-hcd.c:1059 [ohci_hcd]ohci_restart =p "bogus ed %p state %d\012"
drivers/usb/host/ohci-hcd.c:1085 [ohci_hcd]ohci_restart =p "restart complete\012"
drivers/usb/host/ohci-hub.c:165 [ohci_hcd]ohci_rh_resume =p "BIOS/SMM active, control %03x\012"
drivers/usb/host/ohci-hub.c:169 [ohci_hcd]ohci_rh_resume =p "duplicate resume\012"
drivers/usb/host/ohci-hub.c:179 [ohci_hcd]ohci_rh_resume =p "%s root hub\012"
drivers/usb/host/ohci-hub.c:184 [ohci_hcd]ohci_rh_resume =p "%swakeup root hub\012"
drivers/usb/host/ohci-hub.c:188 [ohci_hcd]ohci_rh_resume =p "snapshot resume? reinit\012"
drivers/usb/host/ohci-hub.c:192 [ohci_hcd]ohci_rh_resume =p "lost power\012"
drivers/usb/host/ohci-hub.c:289 [ohci_hcd]ohci_rh_resume =p "restarting schedules ... %08x\012"
drivers/usb/host/ohci-hcd.c:1156 [ohci_hcd]ohci_resume =p "powerup ports\012"
drivers/usb/host/ohci-hcd.c:891 [ohci_hcd]ohci_irq =p "device removed!\012"
drivers/usb/host/ohci-hcd.c:925 [ohci_hcd]ohci_irq =p "rhsc\012"
drivers/usb/host/ohci-hcd.c:947 [ohci_hcd]ohci_irq =p "resume detect\012"
drivers/usb/host/ohci-hcd.c:287 [ohci_hcd]ohci_urb_enqueue =p "iso underrun %p (%u+%u < %u)\012"
drivers/usb/host/ohci-pci.c:161 [ohci_pci]ohci_quirk_amd700 =p "enabled AMD prefetch quirk\012"
drivers/usb/host/ohci-pci.c:49 [ohci_pci]ohci_quirk_amd756 =p "AMD756 erratum 4 workaround\012"
drivers/usb/host/ohci-pci.c:83 [ohci_pci]ohci_quirk_ns =p "Using NSC SuperIO setup\012"
drivers/usb/host/ohci-pci.c:173 [ohci_pci]ohci_quirk_qemu =p "enabled qemu quirk\012"
drivers/usb/host/ohci-pci.c:99 [ohci_pci]ohci_quirk_zfmicro =p "enabled Compaq ZFMicro chipset quirks\012"
drivers/usb/host/ohci-pci.c:63 [ohci_pci]ohci_quirk_opti =p "WARNING: OPTi workarounds unavailable\012"
drivers/usb/host/ohci-pci.c:146 [ohci_pci]ohci_quirk_nec =p "enabled NEC chipset lost interrupt quirk\012"
drivers/usb/host/xhci.c:4573 [xhci_hcd]xhci_get_timeout_no_hub_lpm =p "Device-initiated %s disabled due to long SEL %llu ms\012"
drivers/usb/host/xhci.c:4577 [xhci_hcd]xhci_get_timeout_no_hub_lpm =p "Device-initiated %s disabled due to long PEL %llu ms\012"
drivers/usb/host/xhci.c:4636 [xhci_hcd]xhci_calculate_u1_timeout =p "Disable U1, ESIT shorter than exit latency\012"
drivers/usb/host/xhci.c:4660 [xhci_hcd]xhci_calculate_u1_timeout =p "Hub-initiated U1 disabled due to long timeout %llu ms\012"
drivers/usb/host/xhci.c:4700 [xhci_hcd]xhci_calculate_u2_timeout =p "Disable U2, ESIT shorter than exit latency\012"
drivers/usb/host/xhci.c:4718 [xhci_hcd]xhci_calculate_u2_timeout =p "Hub-initiated U2 disabled due to long timeout %llu ms\012"
drivers/usb/host/xhci.c:1342 [xhci_hcd]xhci_check_args =p "xHCI %s called with invalid args\012"
drivers/usb/host/xhci.c:1346 [xhci_hcd]xhci_check_args =p "xHCI %s called for root hub\012"
drivers/usb/host/xhci.c:1354 [xhci_hcd]xhci_check_args =p "xHCI %s called with unaddressed device\012"
drivers/usb/host/xhci.c:1361 [xhci_hcd]xhci_check_args =p "xHCI %s called with udev and virt_dev does not match\012"
drivers/usb/host/xhci.c:2968 [xhci_hcd]xhci_reset_bandwidth =p "%s called for udev %p\012"
drivers/usb/host/xhci.c:3204 [xhci_hcd]xhci_endpoint_reset =p "%s: Failed to queue stop ep command, %d "
drivers/usb/host/xhci.c:3227 [xhci_hcd]xhci_endpoint_reset =p "%s: Failed to queue config ep command, %d "
drivers/usb/host/xhci.c:3107 [xhci_hcd]xhci_endpoint_disable =p "endpoint disable with ep_state 0x%x\012"
drivers/usb/host/xhci.c:1748 [xhci_hcd]xhci_drop_endpoint =p "%s called for udev %p\012"
drivers/usb/host/xhci.c:1752 [xhci_hcd]xhci_drop_endpoint =p "xHCI %s - can't drop slot or ep 0 %#x\012"
drivers/usb/host/xhci.c:1797 [xhci_hcd]xhci_drop_endpoint =p "drop ep 0x%x, slot id %d, new drop flags = %#x, new add flags = %#x\012"
drivers/usb/host/xhci.c:1844 [xhci_hcd]xhci_add_endpoint =p "xHCI %s - can't add slot or ep 0 %#x\012"
drivers/usb/host/xhci.c:1885 [xhci_hcd]xhci_add_endpoint =p "%s - could not initialize ep %#x\012"
drivers/usb/host/xhci.c:1921 [xhci_hcd]xhci_add_endpoint =p "add ep 0x%x, slot id %d, new drop flags = %#x, new add flags = %#x\012"
drivers/usb/host/xhci.c:907 [xhci_hcd]xhci_disable_port_wake_on_bits =p "disable wake bits port %d-%d, portsc: 0x%x, write: 0x%x\012"
drivers/usb/host/xhci.c:923 [xhci_hcd]xhci_disable_port_wake_on_bits =p "disable wake bits port %d-%d, portsc: 0x%x, write: 0x%x\012"
drivers/usb/host/xhci.c:992 [xhci_hcd]xhci_suspend =p "%s: stopping port polling.\012"
drivers/usb/host/xhci.c:1157 [xhci_hcd]xhci_resume =p "Stop HCD\012"
drivers/usb/host/xhci.c:1164 [xhci_hcd]xhci_resume =p "// Disabling event ring interrupts\012"
drivers/usb/host/xhci.c:1170 [xhci_hcd]xhci_resume =p "cleaning up memory\012"
drivers/usb/host/xhci.c:1174 [xhci_hcd]xhci_resume =p "xhci_stop completed - status = %x\012"
drivers/usb/host/xhci.c:1185 [xhci_hcd]xhci_resume =p "Initialize the xhci_hcd\012"
drivers/usb/host/xhci.c:1191 [xhci_hcd]xhci_resume =p "Start the primary HCD\012"
drivers/usb/host/xhci.c:1194 [xhci_hcd]xhci_resume =p "Start the secondary HCD\012"
drivers/usb/host/xhci.c:1244 [xhci_hcd]xhci_resume =p "%s: starting port polling.\012"
drivers/usb/host/xhci.c:5222 [xhci_hcd]xhci_gen_setup =p "Resetting HCD\012"
drivers/usb/host/xhci.c:5227 [xhci_hcd]xhci_gen_setup =p "Reset complete\012"
drivers/usb/host/xhci.c:5243 [xhci_hcd]xhci_gen_setup =p "Enabling 64-bit DMA addresses.\012"
drivers/usb/host/xhci.c:5253 [xhci_hcd]xhci_gen_setup =p "Enabling 32-bit DMA addresses.\012"
drivers/usb/host/xhci.c:5257 [xhci_hcd]xhci_gen_setup =p "Calling HCD init\012"
drivers/usb/host/xhci.c:5262 [xhci_hcd]xhci_gen_setup =p "Called HCD init\012"
drivers/usb/host/xhci.c:4796 [xhci_hcd]xhci_check_intel_tier_policy =p "Disabling U1 link state for device below second-tier hub.\012"
drivers/usb/host/xhci.c:4798 [xhci_hcd]xhci_check_intel_tier_policy =p "Plug device into first-tier hub to decrease power consumption.\012"
drivers/usb/host/xhci.c:4864 [xhci_hcd]xhci_calculate_lpm_timeout =p "Hub-initiated %s disabled at request of driver %s\012"
drivers/usb/host/xhci.c:4411 [xhci_hcd]xhci_set_usb2_hardware_lpm =p "%s port %d USB2 hardware LPM\012"
drivers/usb/host/xhci.c:5043 [xhci_hcd]xhci_update_hub_device =p "Could not allocate xHCI TT structure.\012"
drivers/usb/host/xhci.c:5066 [xhci_hcd]xhci_update_hub_device =p "xHCI version %x needs hub TT think time and number of ports\012"
drivers/usb/host/xhci.c:5084 [xhci_hcd]xhci_update_hub_device =p "xHCI version %x doesn't need hub TT think time or number of ports\012"
drivers/usb/host/xhci.c:5091 [xhci_hcd]xhci_update_hub_device =p "Set up %s for hub device.\012"
drivers/usb/host/xhci.c:2878 [xhci_hcd]xhci_check_bandwidth =p "%s called for udev %p\012"
drivers/usb/host/xhci.c:3421 [xhci_hcd]xhci_alloc_streams =p "Driver wants %u stream IDs (including stream 0).\012"
drivers/usb/host/xhci.c:3426 [xhci_hcd]xhci_alloc_streams =p "xHCI controller does not support streams.\012"
drivers/usb/host/xhci.c:3328 [xhci_hcd]xhci_calculate_streams_and_bitmask =p "Ep 0x%x only supports %u stream IDs.\012"
drivers/usb/host/xhci.c:3298 [xhci_hcd]xhci_calculate_streams_entries =p "xHCI HW only supports %u stream ctx entries.\012"
drivers/usb/host/xhci.c:3477 [xhci_hcd]xhci_alloc_streams =p "Need %u stream ctx entries for %u stream IDs.\012"
drivers/usb/host/xhci.c:3528 [xhci_hcd]xhci_alloc_streams =p "Slot %u ep ctx %u now has streams.\012"
drivers/usb/host/xhci.c:1475 [xhci_hcd]xhci_urb_enqueue =p "urb submitted during PCI suspend\012"
drivers/usb/host/xhci.c:1479 [xhci_hcd]xhci_urb_enqueue =p "Can't queue urb, port error, link inactive\012"
drivers/usb/host/xhci.c:1522 [xhci_hcd]xhci_urb_enqueue =p "Ep 0x%x: URB %p submitted for non-responsive xHCI host.\012"
drivers/usb/host/xhci.c:3972 [xhci_hcd]xhci_alloc_dev =p "FIXME: allocate a command ring segment\012"
drivers/usb/host/xhci.c:3712 [xhci_hcd]xhci_discover_or_reset_device =p "The device to be reset with slot ID %u does not exist. Re-allocate the device\012"
drivers/usb/host/xhci.c:3730 [xhci_hcd]xhci_discover_or_reset_device =p "The device to be reset with slot ID %u does not match the udev. Re-allocate the device\012"
drivers/usb/host/xhci.c:3746 [xhci_hcd]xhci_discover_or_reset_device =p "Resetting device with slot ID %u\012"
drivers/usb/host/xhci.c:3755 [xhci_hcd]xhci_discover_or_reset_device =p "Couldn't allocate command structure.\012"
drivers/usb/host/xhci.c:3764 [xhci_hcd]xhci_discover_or_reset_device =p "FIXME: allocate a command ring segment\012"
drivers/usb/host/xhci.c:3789 [xhci_hcd]xhci_discover_or_reset_device =p "Can't reset device (slot ID %u) in %s state\012"
drivers/usb/host/xhci.c:3790 [xhci_hcd]xhci_discover_or_reset_device =p "Not freeing device rings.\012"
drivers/usb/host/xhci.c:3795 [xhci_hcd]xhci_discover_or_reset_device =p "Successful reset device command.\012"
drivers/usb/host/xhci.c:4092 [xhci_hcd]xhci_setup_device =p "Slot already in default state\012"
drivers/usb/host/xhci-mem.c:2093 [xhci_hcd]xhci_check_trb_in_td_math =p "TRB math tests passed.\012"
drivers/usb/host/xhci-mem.c:815 [xhci_hcd]xhci_free_tt_info =p "Bad real port.\012"
drivers/usb/host/xhci-mem.c:1262 [xhci_hcd]xhci_microframes_to_exponent =p "ep %#x - rounding interval to %d microframes, ep desc says %d microframes\012"
drivers/usb/host/xhci-mem.c:994 [xhci_hcd]xhci_alloc_virt_device =p "Slot %d output ctx = 0x%llx (dma)\012"
drivers/usb/host/xhci-mem.c:1002 [xhci_hcd]xhci_alloc_virt_device =p "Slot %d input ctx = 0x%llx (dma)\012"
drivers/usb/host/xhci-mem.c:1023 [xhci_hcd]xhci_alloc_virt_device =p "Set slot id %d dcbaa entry %p to 0x%llx\012"
drivers/usb/host/xhci-mem.c:1136 [xhci_hcd]xhci_setup_addressable_virt_dev =p "FIXME xHCI doesn't support wireless speeds\012"
drivers/usb/host/xhci-mem.c:1154 [xhci_hcd]xhci_setup_addressable_virt_dev =p "Set root hub portnum to %d\012"
drivers/usb/host/xhci-mem.c:1155 [xhci_hcd]xhci_setup_addressable_virt_dev =p "Set fake root hub portnum to %d\012"
drivers/usb/host/xhci-mem.c:1194 [xhci_hcd]xhci_setup_addressable_virt_dev =p "udev->tt = %p\012"
drivers/usb/host/xhci-mem.c:1195 [xhci_hcd]xhci_setup_addressable_virt_dev =p "udev->ttport = 0x%x\012"
drivers/usb/host/xhci-mem.c:626 [xhci_hcd]xhci_alloc_stream_info =p "Allocating %u streams and %u stream context array entries.\012"
drivers/usb/host/xhci-mem.c:628 [xhci_hcd]xhci_alloc_stream_info =p "Command ring has no reserved TRBs available\012"
drivers/usb/host/xhci-mem.c:686 [xhci_hcd]xhci_alloc_stream_info =p "Setting stream %d ring ptr to 0x%08llx\012"
drivers/usb/host/xhci-mem.c:949 [xhci_hcd]xhci_free_virt_devices_depth_first =p "Bad vdev->real_port.\012"
drivers/usb/host/xhci-mem.c:2196 [xhci_hcd]xhci_add_in_port =p "PSIV:%d PSIE:%d PLT:%d PFD:%d LP:%d PSIM:%d\012"
drivers/usb/host/xhci-ring.c:2921 [xhci_hcd]prepare_ring =p "WARN halted endpoint, queueing URB anyway.\012"
drivers/usb/host/xhci-ring.c:2997 [xhci_hcd]prepare_transfer =p "Can't prepare ring for bad stream ID %u\012"
drivers/usb/host/xhci-ring.c:3122 [xhci_hcd]check_interval =p "Driver uses different interval (%d microframe%s) than xHCI (%d microframe%s)\012"
drivers/usb/host/xhci-ring.c:1935 [xhci_hcd]xhci_td_cleanup =p "Giveback URB %p, len = %d, expected = %d, status = %d\012"
drivers/usb/host/xhci-ring.c:282 [xhci_hcd]xhci_ring_cmd_db =p "// Ding dong!\012"
drivers/usb/host/xhci-ring.c:321 [xhci_hcd]xhci_handle_stopped_cmd_ring =p "Turn aborted command %p to no-op\012"
drivers/usb/host/xhci-ring.c:3986 [xhci_hcd]queue_command =p "xHCI dying or halted, can't queue_command\012"
drivers/usb/host/xhci-ring.c:965 [xhci_hcd]xhci_stop_endpoint_command_watchdog =p "Stop EP timer raced with cmd completion, exit"
drivers/usb/host/xhci-ring.c:1354 [xhci_hcd]xhci_handle_command_timeout =p "Command timeout\012"
drivers/usb/host/xhci-ring.c:348 [xhci_hcd]xhci_abort_cmd_ring =p "Abort command ring\012"
drivers/usb/host/xhci-ring.c:381 [xhci_hcd]xhci_abort_cmd_ring =p "No stop event for abort, ring start fail?\012"
drivers/usb/host/xhci-ring.c:1361 [xhci_hcd]xhci_handle_command_timeout =p "host removed, ring start fail?\012"
drivers/usb/host/xhci-ring.c:1368 [xhci_hcd]xhci_handle_command_timeout =p "Command timeout on stopped ring\012"
drivers/usb/host/xhci-ring.c:1893 [xhci_hcd]xhci_is_vendor_info_code =p "Vendor defined info completion code %u\012"
drivers/usb/host/xhci-ring.c:1894 [xhci_hcd]xhci_is_vendor_info_code =p "Treating code as success.\012"
drivers/usb/host/xhci-ring.c:3212 [xhci_hcd]xhci_align_td =p "Unaligned %d bytes, buff len %d\012"
drivers/usb/host/xhci-ring.c:3217 [xhci_hcd]xhci_align_td =p "split align, new buff len %d\012"
drivers/usb/host/xhci-ring.c:3255 [xhci_hcd]xhci_align_td =p "Bounce align, new buff len %d\012"
drivers/usb/host/xhci-ring.c:3720 [xhci_hcd]xhci_queue_isoc_tx =p "Isoc URB with zero packets?\012"
drivers/usb/host/xhci-ring.c:3659 [xhci_hcd]xhci_get_isoc_frame_id =p "%s: index %d, reg 0x%x start_frame_id 0x%x, end_frame_id 0x%x, start_frame 0x%x\012"
drivers/usb/host/xhci-ring.c:1027 [xhci_hcd]update_ring_for_set_deq_completion =p "Unable to find new dequeue pointer\012"
drivers/usb/host/xhci-ring.c:1283 [xhci_hcd]xhci_handle_cmd_reset_dev =p "Completed reset device command.\012"
drivers/usb/host/xhci-ring.c:2835 [xhci_hcd]xhci_irq =p "xHCI dying, ignoring interrupt. Shouldn't IRQs be disabled?\012"
drivers/usb/host/xhci-ring.c:1606 [xhci_hcd]handle_port_status =p "ignore port event for removed USB3 hcd\012"
drivers/usb/host/xhci-ring.c:1617 [xhci_hcd]handle_port_status =p "Port change event, %d-%d, id %d, portsc: 0x%x\012"
drivers/usb/host/xhci-ring.c:1622 [xhci_hcd]handle_port_status =p "resume root hub\012"
drivers/usb/host/xhci-ring.c:1634 [xhci_hcd]handle_port_status =p "port resume event for port %d\012"
drivers/usb/host/xhci-ring.c:1643 [xhci_hcd]handle_port_status =p "remote wake SS port %d\012"
drivers/usb/host/xhci-ring.c:1658 [xhci_hcd]handle_port_status =p "resume HS port %d\012"
drivers/usb/host/xhci-ring.c:1679 [xhci_hcd]handle_port_status =p "resume SS port %d finished\012"
drivers/usb/host/xhci-ring.c:1737 [xhci_hcd]handle_port_status =p "%s: starting port polling.\012"
drivers/usb/host/xhci-ring.c:2396 [xhci_hcd]handle_tx_event =p "Stopped on Transfer TRB for slot %u ep %u\012"
drivers/usb/host/xhci-ring.c:2401 [xhci_hcd]handle_tx_event =p "Stopped on No-op or Link TRB for slot %u ep %u\012"
drivers/usb/host/xhci-ring.c:2406 [xhci_hcd]handle_tx_event =p "Stopped with short packet transfer detected for slot %u ep %u\012"
drivers/usb/host/xhci-ring.c:2411 [xhci_hcd]handle_tx_event =p "Stalled endpoint for slot %u ep %u\012"
drivers/usb/host/xhci-ring.c:2418 [xhci_hcd]handle_tx_event =p "Transfer error for slot %u ep %u on endpoint\012"
drivers/usb/host/xhci-ring.c:2423 [xhci_hcd]handle_tx_event =p "Babble error for slot %u ep %u on endpoint\012"
drivers/usb/host/xhci-ring.c:2456 [xhci_hcd]handle_tx_event =p "underrun event on endpoint\012"
drivers/usb/host/xhci-ring.c:2461 [xhci_hcd]handle_tx_event =p "Underrun Event for slot %d ep %d still with TDs queued?\012"
drivers/usb/host/xhci-ring.c:2464 [xhci_hcd]handle_tx_event =p "overrun event on endpoint\012"
drivers/usb/host/xhci-ring.c:2469 [xhci_hcd]handle_tx_event =p "Overrun Event for slot %d ep %d still with TDs queued?\012"
drivers/usb/host/xhci-ring.c:2481 [xhci_hcd]handle_tx_event =p "Miss service interval error for slot %u ep %u, set skip flag\012"
drivers/usb/host/xhci-ring.c:2487 [xhci_hcd]handle_tx_event =p "No Ping response error for slot %u ep %u, Skip one Isoc TD\012"
drivers/usb/host/xhci-ring.c:2531 [xhci_hcd]handle_tx_event =p "td_list is empty while skip flag set. Clear skip flag for slot %u ep %u.\012"
drivers/usb/host/xhci-ring.c:2540 [xhci_hcd]handle_tx_event =p "All tds on the ep_ring skipped. Clear skip flag for slot %u ep %u.\012"
drivers/usb/host/xhci-ring.c:2601 [xhci_hcd]handle_tx_event =p "Found td. Clear skip flag for slot %u ep %u.\012"
drivers/usb/host/xhci-ring.c:2075 [xhci_hcd]process_ctrl_td =p "TRB error %u, halted endpoint index = %u\012"
drivers/usb/host/xhci-ring.c:2098 [xhci_hcd]process_ctrl_td =p "Waiting for status stage event\012"
drivers/usb/host/xhci-ring.c:2256 [xhci_hcd]process_bulk_intr_td =p "ep %#x - asked for %d bytes, %d bytes untransferred\012"
drivers/usb/host/xhci-ring.c:2263 [xhci_hcd]process_bulk_intr_td =p "ep %#x - asked for %d bytes, %d bytes untransferred\012"
drivers/usb/host/xhci-ring.c:1533 [xhci_hcd]handle_device_notification =p "Device Wake Notification event for slot ID %u\012"
drivers/usb/host/xhci-ring.c:1514 [xhci_hcd]handle_vendor_event =p "Vendor specific event TRB type = %u\012"
drivers/usb/host/xhci-ring.c:2733 [xhci_hcd]xhci_handle_event =p "xHCI host dying, returning from event handler.\012"
drivers/usb/host/xhci-hub.c:580 [xhci_hcd]xhci_set_port_power =p "set port power %d-%d %s, portsc: 0x%x\012"
drivers/usb/host/xhci-hub.c:692 [xhci_hcd]xhci_set_link_state =p "Set port %d-%d link state, portsc: 0x%x, write 0x%x"
drivers/usb/host/xhci-hub.c:1124 [xhci_hcd]xhci_hub_control =p "Wrong hub descriptor type for USB 3.0 roothub.\012"
drivers/usb/host/xhci-hub.c:862 [xhci_hcd]xhci_handle_usb2_port_link_resume =p "resume USB2 port %d-%d\012"
drivers/usb/host/xhci-hub.c:882 [xhci_hcd]xhci_handle_usb2_port_link_resume =p "slot_id is zero\012"
drivers/usb/host/xhci-hub.c:1157 [xhci_hcd]xhci_hub_control =p "Get port status %d-%d read: 0x%x, return 0x%x"
drivers/usb/host/xhci-hub.c:1242 [xhci_hcd]xhci_hub_control =p "Disable port %d\012"
drivers/usb/host/xhci-hub.c:1258 [xhci_hcd]xhci_hub_control =p "Enable port %d\012"
drivers/usb/host/xhci-hub.c:1281 [xhci_hcd]xhci_hub_control =p "CTC flag is 0, port already supports entering compliance mode\012"
drivers/usb/host/xhci-hub.c:1291 [xhci_hcd]xhci_hub_control =p "Enable compliance mode transition for port %d\012"
drivers/usb/host/xhci-hub.c:1346 [xhci_hcd]xhci_hub_control =p "set port reset, actual port %d status  = 0x%x\012"
drivers/usb/host/xhci-hub.c:1354 [xhci_hcd]xhci_hub_control =p "set port remote wake mask, actual port %d status  = 0x%x\012"
drivers/usb/host/xhci-hub.c:624 [xhci_hcd]xhci_enter_test_mode =p "Disable all slots\012"
drivers/usb/host/xhci-hub.c:637 [xhci_hcd]xhci_enter_test_mode =p "Disable all port (PP = 0)\012"
drivers/usb/host/xhci-hub.c:645 [xhci_hcd]xhci_enter_test_mode =p "Stop controller\012"
drivers/usb/host/xhci-hub.c:654 [xhci_hcd]xhci_enter_test_mode =p "Enter Test Mode: %d, Port_id=%d\012"
drivers/usb/host/xhci-hub.c:1407 [xhci_hcd]xhci_hub_control =p "clear USB_PORT_FEAT_SUSPEND\012"
drivers/usb/host/xhci-hub.c:1408 [xhci_hcd]xhci_hub_control =p "PORTSC %04x\012"
drivers/usb/host/xhci-hub.c:1432 [xhci_hcd]xhci_hub_control =p "slot_id is zero\012"
drivers/usb/host/xhci-hub.c:551 [xhci_hcd]xhci_clear_port_change_bit =p "clear port%d %s change, portsc: 0x%x\012"
drivers/usb/host/xhci-hub.c:486 [xhci_hcd]xhci_disable_port =p "Ignoring request to disable SuperSpeed port.\012"
drivers/usb/host/xhci-hub.c:492 [xhci_hcd]xhci_disable_port =p "Broken Port Enabled/Disabled, ignoring port disable request.\012"
drivers/usb/host/xhci-hub.c:500 [xhci_hcd]xhci_disable_port =p "disable port %d-%d, portsc: 0x%x\012"
drivers/usb/host/xhci-hub.c:1533 [xhci_hcd]xhci_hub_status_data =p "%s: stopping port polling.\012"
drivers/usb/host/xhci-hub.c:1565 [xhci_hcd]xhci_bus_suspend =p "suspend failed because a port is resuming\012"
drivers/usb/host/xhci-hub.c:1593 [xhci_hcd]xhci_bus_suspend =p "port %d polling in bus suspend, waiting\012"
drivers/usb/host/xhci-hub.c:1601 [xhci_hcd]xhci_bus_suspend =p "Bus suspend bailout, port connect change\012"
drivers/usb/host/xhci-hub.c:1604 [xhci_hcd]xhci_bus_suspend =p "port %d not suspended\012"
drivers/usb/host/xhci-hub.c:1734 [xhci_hcd]xhci_bus_resume =p "reset stuck port %d\012"
drivers/usb/host/xhci-dbg.c:31 [xhci_hcd]xhci_dbg_trace =p "%pV\012"
drivers/usb/host/xhci-pci.c:310 [xhci_pci]xhci_pci_setup =p "Got SBRN %u\012"
drivers/usb/host/xhci-pci.c:81 [xhci_pci]xhci_pci_reinit =p "MWI active\012"
drivers/usb/host/xhci-pci.c:83 [xhci_pci]xhci_pci_reinit =p "Finished xhci_pci_reinit\012"
drivers/usb/storage/usb.c:896 [usb_storage]usb_stor_scan_dwork =p "starting scan\012"
drivers/usb/storage/usb.c:914 [usb_storage]usb_stor_scan_dwork =p "scan complete\012"
drivers/usb/storage/usb.c:1064 [usb_storage]usb_stor_probe2 =p "waiting for device to settle before scanning\012"
drivers/usb/storage/usb.c:1128 [usb_storage]storage_probe =p "Use Bulk-Only transport with the Transparent SCSI protocol for dynamic id: 0x%04x 0x%04x\012"
drivers/usb/storage/sierra_ms.c:87 [usb_storage]debug_swoc =p "SWIMS: SWoC Rev: %02d\012"
drivers/usb/storage/sierra_ms.c:88 [usb_storage]debug_swoc =p "SWIMS: Linux SKU: %04X\012"
drivers/usb/storage/sierra_ms.c:89 [usb_storage]debug_swoc =p "SWIMS: Linux Version: %04X\012"
drivers/usb/storage/sierra_ms.c:69 [usb_storage]sierra_get_swoc_info =p "SWIMS: Attempting to get TRU-Install info\012"
drivers/usb/storage/sierra_ms.c:110 [usb_storage]truinst_show =p "SWIMS: failed SWoC query\012"
drivers/usb/storage/sierra_ms.c:51 [usb_storage]sierra_set_ms_mode =p "SWIMS: %s"
drivers/usb/musb/musb_core.c:1583 [musb_hdrc]ep_config_from_hw =p "%s: missing bulk\012"
drivers/usb/musb/musb_core.c:1501 [musb_hdrc]ep_config_from_table =p "%s: setup fifo_mode %d\012"
drivers/usb/musb/musb_core.c:1517 [musb_hdrc]ep_config_from_table =p "%s: invalid ep %d\012"
drivers/usb/musb/musb_core.c:1523 [musb_hdrc]ep_config_from_table =p "%s: mem overrun, ep %d\012"
drivers/usb/musb/musb_core.c:1533 [musb_hdrc]ep_config_from_table =p "%s: %d/%d max ep, %d/%d memory\012"
drivers/usb/musb/musb_core.c:1536 [musb_hdrc]ep_config_from_table =p "%s: missing bulk\012"
drivers/usb/musb/musb_core.c:325 [musb_hdrc]musb_default_write_fifo =p "%cX ep%d fifo %p count %d buf %p\012"
drivers/usb/musb/musb_core.c:1631 [musb_hdrc]musb_core_init =p "%s: ConfigData=0x%02x (%s)\012"
drivers/usb/musb/musb_core.c:1651 [musb_hdrc]musb_core_init =p "%s: %sHDRC RTL version %d.%d%s\012"
drivers/usb/musb/musb_core.c:367 [musb_hdrc]musb_default_read_fifo =p "%cX ep%d fifo %p count %d buf %p\012"
drivers/usb/musb/musb_virthub.c:389 [musb_hdrc]musb_hub_control =p "TEST_J\012"
drivers/usb/musb/musb_virthub.c:393 [musb_hdrc]musb_hub_control =p "TEST_K\012"
drivers/usb/musb/musb_virthub.c:397 [musb_hdrc]musb_hub_control =p "TEST_SE0_NAK\012"
drivers/usb/musb/musb_virthub.c:401 [musb_hdrc]musb_hub_control =p "TEST_PACKET\012"
drivers/usb/musb/musb_virthub.c:406 [musb_hdrc]musb_hub_control =p "TEST_FORCE_ENABLE\012"
drivers/usb/musb/musb_virthub.c:414 [musb_hdrc]musb_hub_control =p "TEST_FIFO_ACCESS\012"
drivers/usb/musb/musb_gadget_ep0.c:315 [musb_hdrc]service_zero_data_request =p "TEST_J\012"
drivers/usb/musb/musb_gadget_ep0.c:322 [musb_hdrc]service_zero_data_request =p "TEST_K\012"
drivers/usb/musb/musb_gadget_ep0.c:328 [musb_hdrc]service_zero_data_request =p "TEST_SE0_NAK\012"
drivers/usb/musb/musb_gadget_ep0.c:334 [musb_hdrc]service_zero_data_request =p "TEST_PACKET\012"
drivers/usb/musb/musb_gadget_ep0.c:341 [musb_hdrc]service_zero_data_request =p "TEST_FORCE_HS\012"
drivers/usb/musb/musb_gadget_ep0.c:347 [musb_hdrc]service_zero_data_request =p "TEST_FORCE_FS\012"
drivers/usb/musb/musb_gadget_ep0.c:353 [musb_hdrc]service_zero_data_request =p "TEST_FIFO_ACCESS\012"
drivers/usb/musb/musb_gadget_ep0.c:359 [musb_hdrc]service_zero_data_request =p "TEST_FORCE_HOST\012"
drivers/usb/musb/musb_gadget.c:1069 [musb_hdrc]musb_gadget_enable =p "%s periph: enabled %s for %s %s, %smaxpacket %d\012"
drivers/usb/chipidea/core.c:1271 [ci_hdrc]ci_controller_resume =p "at %s\012"
drivers/usb/chipidea/core.c:1363 [ci_hdrc]ci_runtime_suspend =p "at %s\012"
drivers/usb/chipidea/core.c:276 [ci_hdrc]hw_device_init =p "ChipIdea HDRC found, revision: %d, lpm: %d; cap: %p op: %p\012"
drivers/usb/chipidea/core.c:921 [ci_hdrc]ci_get_otg_capable =p "It is OTG capable controller\012"
drivers/usb/chipidea/otg.c:171 [ci_hdrc]ci_handle_id_switch =p "switching from %s to %s\012"
drivers/usb/chipidea/ci_hdrc_msm.c:181 [ci_hdrc_msm]ci_hdrc_msm_probe =p "ci_hdrc_msm_probe\012"
drivers/usb/chipidea/ci_hdrc_msm.c:87 [ci_hdrc_msm]ci_hdrc_msm_notify_event =p "CI_HDRC_CONTROLLER_RESET_EVENT received\012"
drivers/usb/chipidea/ci_hdrc_msm.c:127 [ci_hdrc_msm]ci_hdrc_msm_notify_event =p "CI_HDRC_CONTROLLER_STOPPED_EVENT received\012"
drivers/usb/chipidea/ci_hdrc_msm.c:132 [ci_hdrc_msm]ci_hdrc_msm_notify_event =p "unknown ci_hdrc event\012"
drivers/usb/chipidea/ci_hdrc_zevio.c:25 [ci_hdrc_zevio]ci_hdrc_zevio_probe =p "ci_hdrc_zevio_probe\012"
drivers/usb/chipidea/usbmisc_imx.c:574 [usbmisc_imx]usbmisc_imx7d_set_wakeup =p "wakeup int\012"
drivers/usb/chipidea/usbmisc_imx.c:367 [usbmisc_imx]usbmisc_imx6q_set_wakeup =p "wakeup int at ci_hdrc.%d\012"
drivers/usb/chipidea/ci_hdrc_imx.c:520 [ci_hdrc_imx]imx_controller_suspend =p "at %s\012"
drivers/usb/chipidea/ci_hdrc_imx.c:542 [ci_hdrc_imx]imx_controller_resume =p "at %s\012"
drivers/usb/renesas_usbhs/common.c:773 [renesas_usbhs]usbhs_remove =p "usb remove\012"
drivers/usb/renesas_usbhs/common.c:473 [renesas_usbhs]usbhsc_hotplug =p "%s enable\012"
drivers/usb/renesas_usbhs/common.c:487 [renesas_usbhs]usbhsc_hotplug =p "%s disable\012"
drivers/usb/renesas_usbhs/pipe.c:496 [renesas_usbhs]usbhsp_setup_pipebuff =p "pipe : %d : buff_size 0x%x: bufnmb 0x%x\012"
drivers/usb/renesas_usbhs/pipe.c:737 [renesas_usbhs]usbhs_pipe_malloc =p "enable pipe %d : %s (%s)\012"
drivers/usb/renesas_usbhs/pipe.c:838 [renesas_usbhs]usbhs_pipe_probe =p "pipe %x\011: %s\012"
drivers/usb/renesas_usbhs/fifo.c:1348 [renesas_usbhs]usbhsf_irq_ready =p "irq ready [0x%04x]\012"
drivers/usb/renesas_usbhs/fifo.c:1318 [renesas_usbhs]usbhsf_irq_empty =p "irq empty [0x%04x]\012"
drivers/usb/renesas_usbhs/fifo.c:575 [renesas_usbhs]usbhsf_pio_try_push =p "  send %d (%d/ %d/ %d/ %d)\012"
drivers/usb/renesas_usbhs/fifo.c:724 [renesas_usbhs]usbhsf_pio_try_pop =p "  recv %d (%d/ %d/ %d/ %d)\012"
drivers/usb/renesas_usbhs/fifo.c:840 [renesas_usbhs]usbhsf_dma_xfer_preparing =p "  %s %d (%d/ %d)\012"
drivers/usb/renesas_usbhs/fifo.c:1300 [renesas_usbhs]usbhsf_dma_init =p "enable DMAEngine (%s%s%s)\012"
drivers/usb/renesas_usbhs/mod_gadget.c:734 [renesas_usbhs]__usbhsg_ep_set_halt_wedge =p "set halt %d (pipe %d)\012"
drivers/usb/renesas_usbhs/mod_gadget.c:128 [renesas_usbhs]__usbhsg_queue_pop =p "pipe %d : queue pop\012"
drivers/usb/renesas_usbhs/mod_gadget.c:916 [renesas_usbhs]usbhsg_try_stop =p "stop gadget\012"
drivers/usb/renesas_usbhs/mod_gadget.c:488 [renesas_usbhs]usbhsg_irq_ctrl_stage =p "stage = %d\012"
drivers/usb/renesas_usbhs/mod_gadget.c:443 [renesas_usbhs]usbhsg_recip_run_handle =p "%s (pipe %d :%s)\012"
drivers/usb/renesas_usbhs/mod_gadget.c:464 [renesas_usbhs]usbhsg_irq_dev_state =p "state = %x : speed : %d\012"
drivers/usb/renesas_usbhs/mod_gadget.c:840 [renesas_usbhs]usbhsg_try_start =p "start gadget\012"
drivers/usb/renesas_usbhs/mod_gadget.c:181 [renesas_usbhs]usbhsg_queue_push =p "pipe %d : queue push (%d)\012"
drivers/usb/gadget/udc/core.c:1135 [udc_core]usb_udc_release =p "releasing '%s'\012"
drivers/usb/gadget/udc/core.c:1350 [udc_core]udc_bind_to_driver =p "registering UDC driver [%s]\012"
drivers/usb/gadget/udc/core.c:1295 [udc_core]usb_gadget_remove_driver =p "unregistering UDC driver [%s]\012"
drivers/usb/gadget/udc/snps_udc_core.c:267 [snps_udc_core]udc_enable_dev_setup_interrupts =p "enable device interrupts for setup data\012"
drivers/usb/gadget/udc/snps_udc_core.c:1401 [snps_udc_core]udc_remote_wakeup =p "UDC initiates remote wakeup\012"
drivers/usb/gadget/udc/snps_udc_core.c:1465 [snps_udc_core]udc_basic_init =p "udc_basic_init()\012"
drivers/usb/gadget/udc/snps_udc_core.c:1533 [snps_udc_core]udc_setup_endpoints =p "udc_setup_endpoints()\012"
drivers/usb/gadget/udc/snps_udc_core.c:740 [snps_udc_core]udc_rxfifo_read =p "%s: rx %d bytes, rx-buf space = %d bytesn\012"
drivers/usb/gadget/udc/snps_udc_core.c:315 [snps_udc_core]UDC_QUEUE_CNAK =p "NAK could not be cleared for ep%d\012"
drivers/usb/gadget/udc/snps_udc_core.c:2030 [snps_udc_core]udc_process_cnak_queue =p "CNAK pending queue processing\012"
drivers/usb/gadget/udc/snps_udc_core.c:2033 [snps_udc_core]udc_process_cnak_queue =p "CNAK pending for ep%d\012"
drivers/usb/gadget/udc/snps_udc_core.c:2044 [snps_udc_core]udc_process_cnak_queue =p "CNAK pending for ep%d\012"
drivers/usb/gadget/udc/snps_udc_core.c:1849 [snps_udc_core]activate_control_endpoints =p "activate_control_endpoints\012"
drivers/usb/gadget/udc/snps_udc_core.c:1321 [snps_udc_core]udc_set_halt =p "set_halt %s: halt=%d\012"
drivers/usb/gadget/udc/snps_udc_core.c:1350 [snps_udc_core]udc_set_halt =p "start polltimer\012"
drivers/usb/gadget/udc/snps_udc_core.c:1709 [snps_udc_core]udc_soft_reset =p "Soft reset\012"
drivers/usb/gadget/udc/snps_udc_core.c:1667 [snps_udc_core]udc_tasklet_disconnect =p "Tasklet disconnect\012"
drivers/usb/gadget/udc/snps_udc_core.c:250 [snps_udc_core]udc_enable_ep0_interrupts =p "udc_enable_ep0_interrupts()\012"
drivers/usb/gadget/udc/snps_udc_core.c:574 [snps_udc_core]udc_free_dma_chain =p "free chain req = %p\012"
drivers/usb/gadget/udc/snps_udc_core.c:192 [snps_udc_core]print_regs =p "------- Device registers -------\012"
drivers/usb/gadget/udc/snps_udc_core.c:193 [snps_udc_core]print_regs =p "dev config     = %08x\012"
drivers/usb/gadget/udc/snps_udc_core.c:194 [snps_udc_core]print_regs =p "dev control    = %08x\012"
drivers/usb/gadget/udc/snps_udc_core.c:195 [snps_udc_core]print_regs =p "dev status     = %08x\012"
drivers/usb/gadget/udc/snps_udc_core.c:196 [snps_udc_core]print_regs =p "\012"
drivers/usb/gadget/udc/snps_udc_core.c:197 [snps_udc_core]print_regs =p "dev int's      = %08x\012"
drivers/usb/gadget/udc/snps_udc_core.c:198 [snps_udc_core]print_regs =p "dev intmask    = %08x\012"
drivers/usb/gadget/udc/snps_udc_core.c:199 [snps_udc_core]print_regs =p "\012"
drivers/usb/gadget/udc/snps_udc_core.c:200 [snps_udc_core]print_regs =p "dev ep int's   = %08x\012"
drivers/usb/gadget/udc/snps_udc_core.c:201 [snps_udc_core]print_regs =p "dev ep intmask = %08x\012"
drivers/usb/gadget/udc/snps_udc_core.c:202 [snps_udc_core]print_regs =p "\012"
drivers/usb/gadget/udc/snps_udc_core.c:203 [snps_udc_core]print_regs =p "USE DMA        = %d\012"
drivers/usb/gadget/udc/snps_udc_core.c:206 [snps_udc_core]print_regs =p "DMA mode       = PPBNDU (packet per buffer WITHOUT desc. update)\012"
drivers/usb/gadget/udc/snps_udc_core.c:210 [snps_udc_core]print_regs =p "DMA mode       = PPBDU (packet per buffer WITH desc. update)\012"
drivers/usb/gadget/udc/snps_udc_core.c:214 [snps_udc_core]print_regs =p "DMA mode       = BF (buffer fill mode)\012"
drivers/usb/gadget/udc/snps_udc_core.c:219 [snps_udc_core]print_regs =p "-------------------------------------------------------\012"
drivers/usb/gadget/udc/snps_udc_core.c:507 [snps_udc_core]udc_ep_disable =p "Disable ep-%d\012"
drivers/usb/gadget/udc/snps_udc_core.c:3106 [snps_udc_core]init_dma_pools =p "can't get request data pool\012"
drivers/usb/gadget/udc/snps_udc_core.c:3117 [snps_udc_core]init_dma_pools =p "can't get stp request pool\012"
drivers/usb/gadget/udc/snps_udc_core.c:898 [snps_udc_core]prep_dma =p "Out of DMA memory\012"
drivers/usb/gadget/udc/snps_udc_core.c:1220 [snps_udc_core]udc_queue =p "udc_queue(): pending bytes in rxfifo after nyet\012"
drivers/usb/gadget/udc/snps_udc_core.c:2101 [snps_udc_core]udc_data_out_isr =p "BNA ep%dout occurred - DESPTR = %x\012"
drivers/usb/gadget/udc/snps_udc_core.c:2208 [snps_udc_core]udc_data_out_isr =p "%s: rx %db, space=%db\012"
drivers/usb/gadget/udc/snps_udc_core.c:343 [snps_udc_core]udc_ep_enable =p "udc_ep_enable() ep %d\012"
drivers/usb/gadget/udc/snps_udc_core.c:446 [snps_udc_core]udc_ep_enable =p "%s enabled\012"
drivers/usb/gadget/udc/snps_udc_core.c:2555 [snps_udc_core]udc_control_out_isr =p "MSC Reset\012"
drivers/usb/gadget/udc/snps_udc_core.c:2699 [snps_udc_core]udc_control_in_isr =p "stall ep0in\012"
drivers/usb/gadget/udc/snps_udc_core.c:2784 [snps_udc_core]udc_dev_isr =p "SET_CONFIG interrupt: config=%d\012"
drivers/usb/gadget/udc/snps_udc_core.c:2844 [snps_udc_core]udc_dev_isr =p "SET_INTERFACE interrupt: alt=%d intf=%d\012"
drivers/usb/gadget/udc/snps_udc_core.c:2888 [snps_udc_core]udc_dev_isr =p "USB Reset interrupt\012"
drivers/usb/gadget/udc/snps_udc_core.c:2926 [snps_udc_core]udc_dev_isr =p "DMA machine reset\012"
drivers/usb/gadget/udc/snps_udc_core.c:2944 [snps_udc_core]udc_dev_isr =p "USB Suspend interrupt\012"
drivers/usb/gadget/udc/snps_udc_core.c:2954 [snps_udc_core]udc_dev_isr =p "ENUM interrupt\012"
drivers/usb/gadget/udc/snps_udc_core.c:2975 [snps_udc_core]udc_dev_isr =p "USB SVC interrupt\012"
drivers/usb/gadget/udc/snps_udc_core.c:2985 [snps_udc_core]udc_dev_isr =p "USB Disconnect (session valid low)\012"
drivers/usb/gadget/udc/renesas_usb3.c:914 [renesas_usb3]__usb3_request_done =p "giveback: ep%2d, %u, %u, %d\012"
drivers/usb/gadget/udc/renesas_usb3.c:2598 [renesas_usb3]renesas_usb3_init_ep =p "%s: num_usb3_eps = %d\012"
drivers/usb/gadget/udc/renesas_usb3.c:2675 [renesas_usb3]renesas_usb3_init_ram =p "ep%2d: val = %08x, ramif = %d, base = %x\012"
drivers/usb/gadget/udc/renesas_usb3.c:434 [renesas_usb3]usb3_wait =p "%s: timed out (%8x, %08x, %08x)\012"
drivers/usb/gadget/udc/renesas_usb3.c:1270 [renesas_usb3]usb3_dma_get_setting_area =p "%s: the length is too big (%d)\012"
drivers/usb/gadget/udc/renesas_usb3.c:2233 [renesas_usb3]renesas_usb3_ep_dequeue =p "ep_dequeue: ep%2d, %u\012"
drivers/usb/gadget/udc/renesas_usb3.c:1537 [renesas_usb3]renesas_usb3_ep_queue =p "ep_queue: ep%2d, %u\012"
drivers/usb/gadget/udc/renesas_usb3.c:1625 [renesas_usb3]usb3_std_req_get_status =p "get_status: req = %p\012"
drivers/usb/gadget/udc/renesas_usb3.c:1782 [renesas_usb3]usb3_std_req_set_sel =p "set_sel: req = %p\012"
drivers/usb/gadget/udc/renesas_usb3.c:1933 [renesas_usb3]usb3_irq_epc_pipen_lsttr =p "%s: len = %u, actual = %u\012"
drivers/usb/gadget/udc/snps_udc_plat.c:48 [snps_udc_plat]stop_udc =p "ep rx queue flushed\012"
drivers/usb/gadget/udc/snps_udc_plat.c:269 [snps_udc_plat]udc_plat_suspend =p "device -> idle\012"
drivers/usb/gadget/udc/snps_udc_plat.c:92 [snps_udc_plat]usbd_connect_notify =p "%s: event: %lu\012"
drivers/usb/gadget/udc/snps_udc_plat.c:79 [snps_udc_plat]udc_drd_work =p "idle -> device\012"
drivers/usb/gadget/udc/snps_udc_plat.c:82 [snps_udc_plat]udc_drd_work =p "device -> idle\012"
drivers/usb/gadget/udc/snps_udc_plat.c:299 [snps_udc_plat]udc_plat_resume =p "idle -> device\012"
drivers/usb/gadget/udc/bdc/bdc_core.c:310 [bdc]bdc_mem_free =p "%s\012"
drivers/usb/gadget/udc/bdc/bdc_core.c:416 [bdc]bdc_hw_exit =p "%s ()\012"
drivers/usb/gadget/udc/bdc/bdc_core.c:590 [bdc]bdc_remove =p "%s ()\012"
drivers/usb/gadget/udc/bdc/bdc_core.c:41 [bdc]poll_oip =p "poll_oip complete status=%d"
drivers/usb/gadget/udc/bdc/bdc_core.c:224 [bdc]bdc_mem_init =p "%s ()\012"
drivers/usb/gadget/udc/bdc/bdc_core.c:237 [bdc]bdc_mem_init =p "bdc->srr.sr_bds =%p\012"
drivers/usb/gadget/udc/bdc/bdc_core.c:242 [bdc]bdc_mem_init =p "SRRBAL[0]=%08x NUM_SR_ENTRIES:%d size:%d\012"
drivers/usb/gadget/udc/bdc/bdc_core.c:265 [bdc]bdc_mem_init =p "usb2_pm=%08x"
drivers/usb/gadget/udc/bdc/bdc_core.c:272 [bdc]bdc_mem_init =p "usb2_pm=%08x\012"
drivers/usb/gadget/udc/bdc/bdc_core.c:58 [bdc]bdc_stop =p "%s ()\012\012"
drivers/usb/gadget/udc/bdc/bdc_core.c:82 [bdc]bdc_reset =p "%s ()\012"
drivers/usb/gadget/udc/bdc/bdc_core.c:490 [bdc]bdc_probe =p "%s()\012"
drivers/usb/gadget/udc/bdc/bdc_core.c:522 [bdc]bdc_probe =p "bdc->regs: %p irq=%d\012"
drivers/usb/gadget/udc/bdc/bdc_core.c:556 [bdc]bdc_probe =p "Using 64-bit address\012"
drivers/usb/gadget/udc/bdc/bdc_core.c:564 [bdc]bdc_probe =p "Using 32-bit address\012"
drivers/usb/gadget/udc/bdc/bdc_core.c:425 [bdc]bdc_hw_init =p "%s ()\012"
drivers/usb/gadget/udc/bdc/bdc_core.c:368 [bdc]bdc_mem_alloc =p "%s() NUM_BDS_PER_TABLE:%d\012"
drivers/usb/gadget/udc/bdc/bdc_core.c:374 [bdc]bdc_mem_alloc =p "page_size=%d\012"
drivers/usb/gadget/udc/bdc/bdc_core.c:167 [bdc]scratchpad_setup =p "%s() sp_buff_size=%d\012"
drivers/usb/gadget/udc/bdc/bdc_core.c:169 [bdc]scratchpad_setup =p "Scratchpad buffer not needed\012"
drivers/usb/gadget/udc/bdc/bdc_core.c:174 [bdc]scratchpad_setup =p "Allocating %d bytes for scratchpad\012"
drivers/usb/gadget/udc/bdc/bdc_core.c:394 [bdc]bdc_mem_alloc =p "ieps:%d eops:%d num_eps:%d\012"
drivers/usb/gadget/udc/bdc/bdc_core.c:401 [bdc]bdc_mem_alloc =p "Allocating sr report0\012"
drivers/usb/gadget/udc/bdc/bdc_core.c:201 [bdc]setup_srr =p "%s() NUM_SR_ENTRIES:%d\012"
drivers/usb/gadget/udc/bdc/bdc_core.c:438 [bdc]bdc_hw_init =p "HW Init done\012"
drivers/usb/gadget/udc/bdc/bdc_core.c:105 [bdc]bdc_run =p "%s ()\012"
drivers/usb/gadget/udc/bdc/bdc_core.c:143 [bdc]bdc_softconn =p "%s () uspc=%08x\012"
drivers/usb/gadget/udc/bdc/bdc_core.c:155 [bdc]bdc_softdisconn =p "%s () uspc=%x\012"
drivers/usb/gadget/udc/bdc/bdc_core.c:342 [bdc]bdc_reinit =p "%s\012"
drivers/usb/gadget/udc/bdc/bdc_cmd.c:60 [bdc]bdc_submit_cmd =p "%s:CMDSC:%08x cmdsc:%08x param0=%08x param1=%08x param2=%08x\012"
drivers/usb/gadget/udc/bdc/bdc_cmd.c:34 [bdc]bdc_issue_cmd =p "cmdsc=%x"
drivers/usb/gadget/udc/bdc/bdc_cmd.c:38 [bdc]bdc_issue_cmd =p "command completed cmd_sts:%x\012"
drivers/usb/gadget/udc/bdc/bdc_cmd.c:70 [bdc]bdc_submit_cmd =p "command completed successfully\012"
drivers/usb/gadget/udc/bdc/bdc_cmd.c:101 [bdc]bdc_submit_cmd =p "Unknown command completion code:%x\012"
drivers/usb/gadget/udc/bdc/bdc_cmd.c:114 [bdc]bdc_dconfig_ep =p "%s ep->ep_num =%d cmd_sc=%x\012"
drivers/usb/gadget/udc/bdc/bdc_cmd.c:151 [bdc]bdc_config_ep =p "%s: param0=%08x param1=%08x"
drivers/usb/gadget/udc/bdc/bdc_cmd.c:208 [bdc]bdc_config_ep =p "cmd_sc=%x param2=%08x\012"
drivers/usb/gadget/udc/bdc/bdc_cmd.c:128 [bdc]ep_bd_list_reinit =p "%s ep:%p bd:%p\012"
drivers/usb/gadget/udc/bdc/bdc_cmd.c:229 [bdc]bdc_ep_bla =p "%s: add=%08llx\012"
drivers/usb/gadget/udc/bdc/bdc_cmd.c:236 [bdc]bdc_ep_bla =p "cmd_sc=%x\012"
drivers/usb/gadget/udc/bdc/bdc_cmd.c:247 [bdc]bdc_address_device =p "%s: add=%d\012"
drivers/usb/gadget/udc/bdc/bdc_cmd.c:261 [bdc]bdc_function_wake_fh =p "%s intf=%d\012"
drivers/usb/gadget/udc/bdc/bdc_cmd.c:267 [bdc]bdc_function_wake_fh =p "param0=%08x param1=%08x\012"
drivers/usb/gadget/udc/bdc/bdc_cmd.c:278 [bdc]bdc_function_wake =p "%s intf=%d"
drivers/usb/gadget/udc/bdc/bdc_cmd.c:290 [bdc]bdc_ep_set_stall =p "%s epnum=%d\012"
drivers/usb/gadget/udc/bdc/bdc_cmd.c:304 [bdc]bdc_ep_clear_stall =p "%s: epnum=%d\012"
drivers/usb/gadget/udc/bdc/bdc_cmd.c:344 [bdc]bdc_stop_ep =p "%s: ep:%s ep->flags:%08x\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:546 [bdc]bdc_req_complete =p "%s ep:%s status:%d\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:60 [bdc]ep_bd_list_free =p "%s ep:%s num_tabs:%d\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:63 [bdc]ep_bd_list_free =p "%s already freed\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:73 [bdc]ep_bd_list_free =p "bd_table:%p index:%d\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:75 [bdc]ep_bd_list_free =p "bd_table not allocated\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:79 [bdc]ep_bd_list_free =p "bd dma pool not allocated\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:86 [bdc]ep_bd_list_free =p "Free dma pool start_bd:%p dma:%llx\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:226 [bdc]bd_add_to_bdi =p "%s  %llx\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:240 [bdc]bd_add_to_bdi =p "dma_first_bd:%llx dma_last_bd:%llx\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:870 [bdc]ep_set_halt =p "%s ep:%s value=%d\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:873 [bdc]ep_set_halt =p "Halt\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:885 [bdc]ep_set_halt =p "Before Clear\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:892 [bdc]ep_set_halt =p "After  Clear\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1091 [bdc]ep0_stall =p "%s\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1805 [bdc]bdc_gadget_ep_set_halt =p "%s ep:%s value=%d\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1939 [bdc]init_ep =p "%s epnum=%d dir=%d\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1983 [bdc]init_ep =p "ep=%p ep->usb_ep.name=%s epnum=%d ep->epnum=%d\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:516 [bdc]bdc_queue_xfr =p "%s req:%p\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:518 [bdc]bdc_queue_xfr =p "eqp_bdi:%d hwd_bdi:%d\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:403 [bdc]setup_first_bd_ep0 =p "ZLP needed wVal:%d len:%d MaxP:%d\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:663 [bdc]ep0_queue =p "%s()\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:701 [bdc]ep0_queue_data_stage =p "%s\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1726 [bdc]bdc_gadget_ep_queue =p "%s ep:%p req:%p\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1728 [bdc]bdc_gadget_ep_queue =p "queuing request %p to %s length %d zero:%d\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1833 [bdc]bdc_gadget_alloc_request =p "%s ep:%s req:%p\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1769 [bdc]bdc_gadget_ep_dequeue =p "%s ep:%s req:%p\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:759 [bdc]ep_dequeue =p "%s ep:%s start:%d end:%d\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:761 [bdc]ep_dequeue =p "ep_dequeue ep=%p ep->desc=%p\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:808 [bdc]ep_dequeue =p "start_pending:%d end_pending:%d speed:%d\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1242 [bdc]ep0_handle_feature =p "%s wValue=%d wIndex=%d\011devstate=%08x speed=%d set=%d"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1151 [bdc]ep0_handle_feature_dev =p "%s set:%d dev state:%d\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1154 [bdc]ep0_handle_feature_dev =p "USB_DEVICE_REMOTE_WAKEUP\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1162 [bdc]ep0_handle_feature_dev =p "USB_DEVICE_TEST_MODE\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1171 [bdc]ep0_handle_feature_dev =p "USB_DEVICE_U1_ENABLE\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1193 [bdc]ep0_handle_feature_dev =p "USB_DEVICE_U2_ENABLE\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1213 [bdc]ep0_handle_feature_dev =p "USB_DEVICE_LTM_ENABLE?\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1248 [bdc]ep0_handle_feature =p "USB_RECIP_INTERFACE\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1255 [bdc]ep0_handle_feature =p "SET REMOTE_WAKEUP\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1258 [bdc]ep0_handle_feature =p "CLEAR REMOTE_WAKEUP\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1265 [bdc]ep0_handle_feature =p "USB_RECIP_ENDPOINT\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1284 [bdc]ep0_handle_feature =p "ep0 stall already cleared\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1287 [bdc]ep0_handle_feature =p "epnum=%d\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1438 [bdc]handle_control_request =p "%s\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1442 [bdc]handle_control_request =p "USB_REQ_SET_ADDRESS\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1113 [bdc]ep0_set_address =p "%s addr:%d dev state:%d\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1448 [bdc]handle_control_request =p "USB_REQ_SET_CONFIGURATION\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1467 [bdc]handle_control_request =p "USB_REQ_SET_FEATURE\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1472 [bdc]handle_control_request =p "USB_REQ_CLEAR_FEATURE\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1477 [bdc]handle_control_request =p "USB_REQ_GET_STATUS\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1315 [bdc]ep0_handle_status =p "%s\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1321 [bdc]ep0_handle_status =p "USB_RECIP_DEVICE devstatus:%08x\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1328 [bdc]ep0_handle_status =p "USB_RECIP_INTERFACE\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1343 [bdc]ep0_handle_status =p "USB_RECIP_ENDPOINT\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1368 [bdc]ep0_handle_status =p "usb_status=%08x\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1482 [bdc]handle_control_request =p "USB_REQ_SET_SEL\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1389 [bdc]ep0_set_sel =p "%s\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:566 [bdc]bdc_ep_disable =p "%s() ep->ep_num=%d\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1898 [bdc]bdc_gadget_ep_disable =p "bdc: invalid parameters\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1911 [bdc]bdc_gadget_ep_disable =p "%s() ep:%s ep->flags:%08x\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:609 [bdc]bdc_ep_enable =p "%s NUM_TABLES:%d %d\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:138 [bdc]ep_bd_list_alloc =p "%s ep:%p num_tabs:%d\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:167 [bdc]ep_bd_list_alloc =p "index:%d start_bd:%p dma=%08llx prev_table:%p\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1859 [bdc]bdc_gadget_ep_enable =p "bdc_gadget_ep_enable invalid parameters\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1864 [bdc]bdc_gadget_ep_enable =p "bdc_gadget_ep_enable missing wMaxPacketSize\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1880 [bdc]bdc_gadget_ep_enable =p "%s Enabling %s\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:904 [bdc]bdc_free_ep =p "%s\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1069 [bdc]bdc_xsf_ep0_setup_recv =p "%s ep0_state:%s\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1082 [bdc]bdc_xsf_ep0_setup_recv =p "%s exit ep0_state:%s\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1513 [bdc]bdc_xsf_ep0_data_start =p "%s\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1538 [bdc]bdc_xsf_ep0_data_start =p "ep0_state:%s"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1554 [bdc]bdc_xsf_ep0_status_start =p "%s ep0_state:%s"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1578 [bdc]bdc_xsf_ep0_status_start =p "status started but data  not transmitted yet\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1600 [bdc]bdc_xsf_ep0_status_start =p "ep0_state:%s"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1661 [bdc]bdc_sr_xsf =p "%s clearing FUNC_WAKE_ISSUED flag\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1665 [bdc]bdc_sr_xsf =p "%s sr_status=%d ep:%s\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:964 [bdc]handle_xsr_succ_status =p "%s  ep:%p\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1043 [bdc]handle_xsr_succ_status =p "len=%d actual=%d bd_xfr->next_hwd_bdi:%d\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1049 [bdc]handle_xsr_succ_status =p "short xfr on %d\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1610 [bdc]ep0_xsf_complete =p "%s\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1620 [bdc]ep0_xsf_complete =p "test_mode:%d\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:928 [bdc]bdc_set_test_mode =p "%s\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:940 [bdc]bdc_set_test_mode =p "usb2_pm=%08x"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1689 [bdc]bdc_sr_xsf =p "Babble on ep0 zlp_need:%d\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1413 [bdc]ep0_queue_zlp =p "%s\012"
drivers/usb/gadget/udc/bdc/bdc_ep.c:1996 [bdc]bdc_init_ep =p "%s()\012"
drivers/usb/gadget/udc/bdc/bdc_udc.c:452 [bdc]bdc_udc_set_selfpowered =p "%s()\012"
drivers/usb/gadget/udc/bdc/bdc_udc.c:162 [bdc]bdc_func_wake_timer =p "%s\012"
drivers/usb/gadget/udc/bdc/bdc_udc.c:169 [bdc]bdc_func_wake_timer =p "FUNC_WAKE_ISSUED FLAG IS STILL SET\012"
drivers/usb/gadget/udc/bdc/bdc_udc.c:401 [bdc]bdc_udc_stop =p "%s()\012"
drivers/usb/gadget/udc/bdc/bdc_udc.c:369 [bdc]bdc_udc_start =p "%s()\012"
drivers/usb/gadget/udc/bdc/bdc_udc.c:475 [bdc]bdc_udc_wakeup =p "%s() bdc->devstatus=%08x\012"
drivers/usb/gadget/udc/bdc/bdc_udc.c:483 [bdc]bdc_udc_wakeup =p "link_state =%d portsc=%x"
drivers/usb/gadget/udc/bdc/bdc_udc.c:501 [bdc]bdc_udc_wakeup =p "link_state =%d portsc=%x"
drivers/usb/gadget/udc/bdc/bdc_udc.c:417 [bdc]bdc_udc_pullup =p "%s() is_on:%d\012"
drivers/usb/gadget/udc/bdc/bdc_udc.c:313 [bdc]bdc_udc_interrupt =p "%s eqp_index=%d dqp_index=%d  srr.dqp_index=%d\012\012"
drivers/usb/gadget/udc/bdc/bdc_udc.c:317 [bdc]bdc_udc_interrupt =p "SRR empty?\012"
drivers/usb/gadget/udc/bdc/bdc_udc.c:327 [bdc]bdc_udc_interrupt =p "sr_type=%d\012"
drivers/usb/gadget/udc/bdc/bdc_udc.c:65 [bdc]srr_dqp_index_advc =p "srr->dqp_index:%d\012"
drivers/usb/gadget/udc/bdc/bdc_udc.c:238 [bdc]bdc_sr_uspc =p "%s uspc=0x%08x\012"
drivers/usb/gadget/udc/bdc/bdc_udc.c:253 [bdc]bdc_sr_uspc =p "Do a softconnect\012"
drivers/usb/gadget/udc/bdc/bdc_udc.c:261 [bdc]bdc_sr_uspc =p "Port reset or disconn\012"
drivers/usb/gadget/udc/bdc/bdc_udc.c:133 [bdc]bdc_uspc_disconnected =p "%s\012"
drivers/usb/gadget/udc/bdc/bdc_udc.c:183 [bdc]handle_link_state_change =p "Link state change"
drivers/usb/gadget/udc/bdc/bdc_udc.c:189 [bdc]handle_link_state_change =p "Entered Suspend mode\012"
drivers/usb/gadget/udc/bdc/bdc_udc.c:212 [bdc]handle_link_state_change =p "sched func_wake_notify\012"
drivers/usb/gadget/udc/bdc/bdc_udc.c:218 [bdc]handle_link_state_change =p "Resumed from Suspend\012"
drivers/usb/gadget/udc/bdc/bdc_udc.c:225 [bdc]handle_link_state_change =p "link state:%d\012"
drivers/usb/gadget/udc/bdc/bdc_udc.c:277 [bdc]bdc_sr_uspc =p "Connected\012"
drivers/usb/gadget/udc/bdc/bdc_udc.c:81 [bdc]bdc_uspc_connected =p "%s speed=%x\012"
drivers/usb/gadget/udc/bdc/bdc_udc.c:117 [bdc]bdc_uspc_connected =p "connected at %s\012"
drivers/usb/gadget/udc/bdc/bdc_udc.c:283 [bdc]bdc_sr_uspc =p "uspc=%x\012"
drivers/usb/gadget/udc/bdc/bdc_udc.c:522 [bdc]bdc_udc_init =p "%s()\012"
drivers/usb/gadget/udc/bdc/bdc_udc.c:582 [bdc]bdc_udc_exit =p "%s()\012"
drivers/usb/typec/class.c:1222 [typec]vconn_source_store =p "VCONN swap depends on USB Power Delivery\012"
drivers/usb/typec/class.c:1227 [typec]vconn_source_store =p "VCONN swapping not supported\012"
drivers/usb/typec/class.c:1154 [typec]port_type_store =p "changing port type not supported\012"
drivers/usb/typec/class.c:1095 [typec]power_role_store =p "USB Power Delivery not supported\012"
drivers/usb/typec/class.c:1100 [typec]power_role_store =p "power role swapping not supported\012"
drivers/usb/typec/class.c:1105 [typec]power_role_store =p "partner unable to swap power role\012"
drivers/usb/typec/class.c:1116 [typec]power_role_store =p "port type fixed at \042%s\042"
drivers/usb/typec/class.c:1001 [typec]preferred_role_store =p "Preferred role only supported with DRP ports\012"
drivers/usb/typec/class.c:1006 [typec]preferred_role_store =p "Setting preferred role not supported\012"
drivers/usb/typec/class.c:1050 [typec]data_role_store =p "data role swapping not supported\012"
drivers/bluetooth/btusb.c:846 [btusb]btusb_bulk_complete =_ "%s urb %p status %d count %d\012"
drivers/bluetooth/btusb.c:890 [btusb]btusb_submit_bulk_urb =_ "%s\012"
drivers/bluetooth/btusb.c:1145 [btusb]btusb_tx_complete =_ "%s urb %p status %d count %d\012"
drivers/bluetooth/btusb.c:1171 [btusb]btusb_isoc_tx_complete =_ "%s urb %p status %d count %d\012"
drivers/bluetooth/btusb.c:1475 [btusb]btusb_notify =_ "%s evt %d\012"
drivers/bluetooth/btusb.c:3939 [btusb]btusb_disconnect =_ "intf %p\012"
drivers/bluetooth/btusb.c:1610 [btusb]btusb_setup_bcm92035 =_ "%s\012"
drivers/bluetooth/btusb.c:1826 [btusb]btusb_setup_intel =_ "%s\012"
drivers/bluetooth/btusb.c:982 [btusb]__fill_isoc_descriptor =_ "len %d mtu %d\012"
drivers/bluetooth/btusb.c:1437 [btusb]btusb_send_frame =_ "%s\012"
drivers/bluetooth/btusb.c:1296 [btusb]btusb_flush =_ "%s\012"
drivers/bluetooth/btusb.c:756 [btusb]btusb_intr_complete =_ "%s urb %p status %d count %d\012"
drivers/bluetooth/btusb.c:1007 [btusb]btusb_submit_isoc_urb =_ "%s\012"
drivers/bluetooth/btusb.c:935 [btusb]btusb_isoc_complete =_ "%s urb %p status %d count %d\012"
drivers/bluetooth/btusb.c:1057 [btusb]btusb_diag_complete =_ "%s urb %p status %d count %d\012"
drivers/bluetooth/btusb.c:2075 [btusb]btusb_send_frame_intel =_ "%s\012"
drivers/bluetooth/btusb.c:1262 [btusb]btusb_close =_ "%s\012"
drivers/bluetooth/btusb.c:1626 [btusb]btusb_setup_csr =_ "%s\012"
drivers/bluetooth/btusb.c:3984 [btusb]btusb_suspend =_ "intf %p\012"
drivers/bluetooth/btusb.c:2172 [btusb]btusb_setup_intel_new =_ "%s\012"
drivers/bluetooth/btusb.c:800 [btusb]btusb_submit_intr_urb =_ "%s\012"
drivers/bluetooth/btusb.c:4062 [btusb]btusb_resume =_ "intf %p\012"
drivers/bluetooth/btusb.c:1192 [btusb]btusb_open =_ "%s\012"
drivers/bluetooth/btusb.c:1099 [btusb]btusb_submit_diag_urb =_ "%s\012"
drivers/bluetooth/btusb.c:3598 [btusb]btusb_probe =_ "intf %p id %p\012"
drivers/bluetooth/btusb.c:3558 [btusb]btusb_config_oob_wake =_ "%s: %s: no OOB Wakeup IRQ in DT\012"
drivers/hid/usbhid/hid-core.c:110 [usbhid]hid_retry_timeout =_ "retrying intr urb\012"
drivers/hid/usbhid/hid-core.c:124 [usbhid]hid_reset =_ "clear halt\012"
drivers/hid/usbhid/hid-core.c:131 [usbhid]hid_reset =_ "clear-halt failed: %d\012"
drivers/hid/usbhid/hid-core.c:137 [usbhid]hid_reset =_ "resetting device\012"
drivers/hid/usbhid/hid-core.c:201 [usbhid]usbhid_restart_out_queue =_ "Kicking head %d tail %d"
drivers/hid/usbhid/hid-core.c:240 [usbhid]usbhid_restart_ctrl_queue =_ "Kicking head %d tail %d"
drivers/hid/usbhid/hid-core.c:1599 [usbhid]hid_resume =_ "resume status %d\012"
drivers/hid/usbhid/hid-core.c:1585 [usbhid]hid_suspend =_ "suspend\012"
drivers/extcon/extcon-usbc-cros-ec.c:272 [extcon_usbc_cros_ec]extcon_cros_ec_detect_cable =_ "disconnected\012"
drivers/extcon/extcon-usbc-cros-ec.c:288 [extcon_usbc_cros_ec]extcon_cros_ec_detect_cable =_ "connected role 0x%x pwr type %d dr %d pr %d pol %d mux %d dp %d hpd %d\012"
drivers/extcon/extcon-usbc-cros-ec.c:305 [extcon_usbc_cros_ec]extcon_cros_ec_detect_cable =_ "Type/Role switch! type = %s role = %s\012"

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: lockdep warning in urb.c:363 usb_submit_urb
  2020-03-23 17:29   ` Qais Yousef
@ 2020-03-24  9:08     ` Oliver Neukum
  2020-03-24 10:46       ` Qais Yousef
  0 siblings, 1 reply; 50+ messages in thread
From: Oliver Neukum @ 2020-03-24  9:08 UTC (permalink / raw)
  To: Qais Yousef; +Cc: Greg Kroah-Hartman, linux-usb, linux-kernel

Am Montag, den 23.03.2020, 17:29 +0000 schrieb Qais Yousef:
> Hi Oliver

Hi,

> First time I use dynamic debugging, hopefully I've done correctly.

I am afraid not.

> 	echo "file drivers/usb/* +p" > /sys/kernel/debug/dynamic_debug/control

Overkill but correct. +mpf would be even better

> 	$REPRODUCE

Good

> 	cat /sys/kernel/debug/dynamic_debug/control | grep usb > usb.debug

No.

/sys/kernel/debug/dynamic_debug/control holds the collection of the
messages that may be triggered, but it does not tell you which messages
are triggered and in which order. The triggered messages end up
in syslog. So you would use 'dmesg'
I am afraid you redid the test correctly and then threw away the
result.
Could you redo it and just attach the output of dmesg?

	Sorry
		Oliver


^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: lockdep warning in urb.c:363 usb_submit_urb
  2020-03-24  9:08     ` Oliver Neukum
@ 2020-03-24 10:46       ` Qais Yousef
  2020-03-24 13:20         ` Oliver Neukum
  2020-03-24 13:47         ` Alan Stern
  0 siblings, 2 replies; 50+ messages in thread
From: Qais Yousef @ 2020-03-24 10:46 UTC (permalink / raw)
  To: Oliver Neukum; +Cc: Greg Kroah-Hartman, linux-usb, linux-kernel

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

On 03/24/20 10:08, Oliver Neukum wrote:
> Am Montag, den 23.03.2020, 17:29 +0000 schrieb Qais Yousef:
> > Hi Oliver
> 
> Hi,
> 
> > First time I use dynamic debugging, hopefully I've done correctly.
> 
> I am afraid not.
> 
> > 	echo "file drivers/usb/* +p" > /sys/kernel/debug/dynamic_debug/control
> 
> Overkill but correct. +mpf would be even better
> 
> > 	$REPRODUCE
> 
> Good
> 
> > 	cat /sys/kernel/debug/dynamic_debug/control | grep usb > usb.debug
> 
> No.
> 
> /sys/kernel/debug/dynamic_debug/control holds the collection of the
> messages that may be triggered, but it does not tell you which messages
> are triggered and in which order. The triggered messages end up
> in syslog. So you would use 'dmesg'
> I am afraid you redid the test correctly and then threw away the
> result.
> Could you redo it and just attach the output of dmesg?
> 
> 	Sorry

I should have stuck to what I know then. I misread the documentation. Hopefully
the attached looks better. I don't see the new debug you added emitted.

Thanks

--
Qais Yousef

[-- Attachment #2: usb.dmesg --]
[-- Type: text/plain, Size: 56459 bytes --]

[    0.000000] Booting Linux on physical CPU 0x0000000100 [0x410fd033]
[    0.000000] Linux version 5.6.0-rc6-00002-g533440e608d2 (qyousef@e107158-lin) (gcc version 7.5.0 (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04)) #537 SMP PREEMPT Tue Mar 24 10:16:57 GMT 2020
[    0.000000] Machine model: ARM Juno development board (r2)
[    0.000000] earlycon: pl11 at MMIO 0x000000007ff80000 (options '')
[    0.000000] printk: bootconsole [pl11] enabled
[    0.000000] efi: Getting EFI parameters from FDT:
[    0.000000] efi: UEFI not found.
[    0.000000] cma: Reserved 32 MiB at 0x00000000fd000000
[    0.000000] NUMA: No NUMA configuration found
[    0.000000] NUMA: Faking a node at [mem 0x0000000080000000-0x00000009ffffffff]
[    0.000000] NUMA: NODE_DATA [mem 0x9fefdb000-0x9fefdcfff]
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x0000000080000000-0x00000000bfffffff]
[    0.000000]   DMA32    [mem 0x00000000c0000000-0x00000000ffffffff]
[    0.000000]   Normal   [mem 0x0000000100000000-0x00000009ffffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000080000000-0x00000000feffffff]
[    0.000000]   node   0: [mem 0x0000000880000000-0x00000009ffffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000080000000-0x00000009ffffffff]
[    0.000000] On node 0 totalpages: 2093056
[    0.000000]   DMA zone: 4096 pages used for memmap
[    0.000000]   DMA zone: 0 pages reserved
[    0.000000]   DMA zone: 262144 pages, LIFO batch:63
[    0.000000]   DMA32 zone: 4096 pages used for memmap
[    0.000000]   DMA32 zone: 258048 pages, LIFO batch:63
[    0.000000]   Normal zone: 24576 pages used for memmap
[    0.000000]   Normal zone: 1572864 pages, LIFO batch:63
[    0.000000] psci: probing for conduit method from DT.
[    0.000000] psci: PSCIv1.0 detected in firmware.
[    0.000000] psci: Using standard PSCI v0.2 function IDs
[    0.000000] psci: Trusted OS migration not required
[    0.000000] psci: SMC Calling Convention v1.0
[    0.000000] percpu: Embedded 48 pages/cpu s159176 r8192 d29240 u196608
[    0.000000] pcpu-alloc: s159176 r8192 d29240 u196608 alloc=48*4096
[    0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0] 4 [0] 5 
[    0.000000] Detected VIPT I-cache on CPU0
[    0.000000] CPU features: detected: ARM erratum 845719
[    0.000000] CPU features: detected: ARM erratum 843419
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 2060288
[    0.000000] Policy zone: Normal
[    0.000000] Kernel command line: ttyAMA0,115200n8 root=/dev/nfs rw verbose debug ip=dhcp nfsroot=xx.xx.xx.xx:/mnt/data/exports/juno,vers=4,tcp nfsrootdebug rootwait earlycon=pl011,0x7ff80000 systemd.log_target=null user_debug=31 androidboot.hardware=juno loglevel=9 bootargs_sky2=sky2.mac_address=0x00,0x02,0xf7,0x00,0x67,0xbe
[    0.000000] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes, linear)
[    0.000000] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes, linear)
[    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[    0.000000] software IO TLB: mapped [mem 0xbbfff000-0xbffff000] (64MB)
[    0.000000] Memory: 8044448K/8372224K available (25724K kernel code, 4126K rwdata, 12236K rodata, 14656K init, 11192K bss, 295008K reserved, 32768K cma-reserved)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=6, Nodes=1
[    0.000000] ftrace: allocating 77609 entries in 304 pages
[    0.000000] ftrace: allocated 304 pages with 3 groups
[    0.000000] Running RCU self tests
[    0.000000] rcu: Preemptible hierarchical RCU implementation.
[    0.000000] rcu: 	RCU lockdep checking is enabled.
[    0.000000] rcu: 	RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=6.
[    0.000000] 	Tasks RCU enabled.
[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
[    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=6
[    0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
[    0.000000] GIC: Using split EOI/Deactivate mode
[    0.000000] GICv2m: range[mem 0x2c1c0000-0x2c1cffff], SPI[224:255]
[    0.000000] GICv2m: range[mem 0x2c1d0000-0x2c1dffff], SPI[256:287]
[    0.000000] GICv2m: range[mem 0x2c1e0000-0x2c1effff], SPI[288:319]
[    0.000000] GICv2m: range[mem 0x2c1f0000-0x2c1fffff], SPI[320:351]
[    0.000000] random: get_random_bytes called from start_kernel+0x5d8/0x784 with crng_init=0
[    0.000000] clocksource: arm,sp804: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275 ns
[    0.000007] sched_clock: 32 bits at 1000kHz, resolution 1000ns, wraps every 2147483647500ns
[    0.008555] Failed to initialize '/smb@8000000/motherboard/iofpga@3,00000000/timer@120000': -22
[    0.018098] arch_timer: cp15 and mmio timer(s) running at 50.00MHz (phys/phys).
[    0.025443] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0xb8812736b, max_idle_ns: 440795202655 ns
[    0.036273] sched_clock: 56 bits at 50MHz, resolution 20ns, wraps every 4398046511100ns
[    0.045515] Console: colour dummy device 80x25
[    0.050047] printk: console [tty0] enabled
[    0.054293] printk: bootconsole [pl11] disabled
[    0.058985] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
[    0.059152] ... MAX_LOCKDEP_SUBCLASSES:  8
[    0.059252] ... MAX_LOCK_DEPTH:          48
[    0.059353] ... MAX_LOCKDEP_KEYS:        8192
[    0.059457] ... CLASSHASH_SIZE:          4096
[    0.059561] ... MAX_LOCKDEP_ENTRIES:     32768
[    0.059667] ... MAX_LOCKDEP_CHAINS:      65536
[    0.059772] ... CHAINHASH_SIZE:          32768
[    0.059878]  memory used by lock dependency info: 6237 kB
[    0.060000]  memory used for stack traces: 4224 kB
[    0.060111]  per task-struct memory footprint: 1920 bytes
[    0.060233] ------------------------
[    0.060322] | Locking API testsuite:
[    0.060412] ----------------------------------------------------------------------------
[    0.060583]                                  | spin |wlock |rlock |mutex | wsem | rsem |
[    0.060754]   --------------------------------------------------------------------------
[    0.060934]                      A-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[    0.079458]                  A-B-B-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[    0.099597]              A-B-B-C-C-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[    0.121450]              A-B-C-A-B-C deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[    0.143252]          A-B-B-C-C-D-D-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[    0.166754]          A-B-C-D-B-D-D-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[    0.190217]          A-B-C-D-B-C-D-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[    0.213728]                     double unlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[    0.232179]                   initialize held:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[    0.250005]   --------------------------------------------------------------------------
[    0.250174]               recursive read-lock:             |  ok  |             |  ok  |
[    0.255815]            recursive read-lock #2:             |  ok  |             |  ok  |
[    0.261226]             mixed read-write-lock:             |  ok  |             |  ok  |
[    0.266651]             mixed write-read-lock:             |  ok  |             |  ok  |
[    0.272074]   mixed read-lock/lock-write ABBA:             |FAILED|             |  ok  |
[    0.277794]    mixed read-lock/lock-read ABBA:             |  ok  |             |  ok  |
[    0.283677]  mixed write-lock/lock-write ABBA:             |  ok  |             |  ok  |
[    0.289568]   --------------------------------------------------------------------------
[    0.289899]      hard-irqs-on + irq-safe-A/12:  ok  |  ok  |  ok  |
[    0.297861]      soft-irqs-on + irq-safe-A/12:  ok  |  ok  |  ok  |
[    0.305876]      hard-irqs-on + irq-safe-A/21:  ok  |  ok  |  ok  |
[    0.313850]      soft-irqs-on + irq-safe-A/21:  ok  |  ok  |  ok  |
[    0.321869]        sirq-safe-A => hirqs-on/12:  ok  |  ok  |  ok  |
[    0.329856]        sirq-safe-A => hirqs-on/21:  ok  |  ok  |  ok  |
[    0.337879]          hard-safe-A + irqs-on/12:  ok  |  ok  |  ok  |
[    0.345855]          soft-safe-A + irqs-on/12:  ok  |  ok  |  ok  |
[    0.353875]          hard-safe-A + irqs-on/21:  ok  |  ok  |  ok  |
[    0.361849]          soft-safe-A + irqs-on/21:  ok  |  ok  |  ok  |
[    0.369867]     hard-safe-A + unsafe-B #1/123:  ok  |  ok  |  ok  |
[    0.378541]     soft-safe-A + unsafe-B #1/123:  ok  |  ok  |  ok  |
[    0.387259]     hard-safe-A + unsafe-B #1/132:  ok  |  ok  |  ok  |
[    0.395932]     soft-safe-A + unsafe-B #1/132:  ok  |  ok  |  ok  |
[    0.404647]     hard-safe-A + unsafe-B #1/213:  ok  |  ok  |  ok  |
[    0.413331]     soft-safe-A + unsafe-B #1/213:  ok  |  ok  |  ok  |
[    0.422056]     hard-safe-A + unsafe-B #1/231:  ok  |  ok  |  ok  |
[    0.430717]     soft-safe-A + unsafe-B #1/231:  ok  |  ok  |  ok  |
[    0.439420]     hard-safe-A + unsafe-B #1/312:  ok  |  ok  |  ok  |
[    0.447627]     soft-safe-A + unsafe-B #1/312:  ok  |  ok  |  ok  |
[    0.455885]     hard-safe-A + unsafe-B #1/321:  ok  |  ok  |  ok  |
[    0.464544]     soft-safe-A + unsafe-B #1/321:  ok  |  ok  |  ok  |
[    0.473249]     hard-safe-A + unsafe-B #2/123:  ok  |  ok  |  ok  |
[    0.481912]     soft-safe-A + unsafe-B #2/123:  ok  |  ok  |  ok  |
[    0.490637]     hard-safe-A + unsafe-B #2/132:  ok  |  ok  |  ok  |
[    0.499308]     soft-safe-A + unsafe-B #2/132:  ok  |  ok  |  ok  |
[    0.508034]     hard-safe-A + unsafe-B #2/213:  ok  |  ok  |  ok  |
[    0.516698]     soft-safe-A + unsafe-B #2/213:  ok  |  ok  |  ok  |
[    0.525421]     hard-safe-A + unsafe-B #2/231:  ok  |  ok  |  ok  |
[    0.534078]     soft-safe-A + unsafe-B #2/231:  ok  |  ok  |  ok  |
[    0.542801]     hard-safe-A + unsafe-B #2/312:  ok  |  ok  |  ok  |
[    0.551463]     soft-safe-A + unsafe-B #2/312:  ok  |  ok  |  ok  |
[    0.560185]     hard-safe-A + unsafe-B #2/321:  ok  |  ok  |  ok  |
[    0.568838]     soft-safe-A + unsafe-B #2/321:  ok  |  ok  |  ok  |
[    0.577560]       hard-irq lock-inversion/123:  ok  |  ok  |  ok  |
[    0.586226]       soft-irq lock-inversion/123:  ok  |  ok  |  ok  |
[    0.594948]       hard-irq lock-inversion/132:  ok  |  ok  |  ok  |
[    0.603609]       soft-irq lock-inversion/132:  ok  |  ok  |  ok  |
[    0.612335]       hard-irq lock-inversion/213:  ok  |  ok  |  ok  |
[    0.620999]       soft-irq lock-inversion/213:  ok  |  ok  |  ok  |
[    0.629714]       hard-irq lock-inversion/231:  ok  |  ok  |  ok  |
[    0.638387]       soft-irq lock-inversion/231:  ok  |  ok  |  ok  |
[    0.647101]       hard-irq lock-inversion/312:  ok  |  ok  |  ok  |
[    0.655767]       soft-irq lock-inversion/312:  ok  |  ok  |  ok  |
[    0.664501]       hard-irq lock-inversion/321:  ok  |  ok  |  ok  |
[    0.673168]       soft-irq lock-inversion/321:  ok  |  ok  |  ok  |
[    0.681885]       hard-irq read-recursion/123:  ok  |
[    0.684842]       soft-irq read-recursion/123:  ok  |
[    0.687847]       hard-irq read-recursion/132:  ok  |
[    0.690799]       soft-irq read-recursion/132:  ok  |
[    0.693801]       hard-irq read-recursion/213:  ok  |
[    0.696755]       soft-irq read-recursion/213:  ok  |
[    0.699754]       hard-irq read-recursion/231:  ok  |
[    0.702712]       soft-irq read-recursion/231:  ok  |
[    0.705716]       hard-irq read-recursion/312:  ok  |
[    0.708669]       soft-irq read-recursion/312:  ok  |
[    0.711670]       hard-irq read-recursion/321:  ok  |
[    0.714628]       soft-irq read-recursion/321:  ok  |
[    0.717628]   --------------------------------------------------------------------------
[    0.717796]   | Wound/wait tests |
[    0.717883]   ---------------------
[    0.717970]                   ww api failures:  ok  |  ok  |  ok  |
[    0.726471]                ww contexts mixing:  ok  |  ok  |
[    0.732069]              finishing ww context:  ok  |  ok  |  ok  |  ok  |
[    0.743150]                locking mismatches:  ok  |  ok  |  ok  |
[    0.751625]                  EDEADLK handling:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[    0.780554]            spinlock nest unlocked:  ok  |
[    0.783275]   -----------------------------------------------------
[    0.783410]                                  |block | try  |context|
[    0.783545]   -----------------------------------------------------
[    0.783679]                           context:  ok  |  ok  |  ok  |
[    0.792405]                               try:  ok  |  ok  |  ok  |
[    0.800609]                             block:  ok  |  ok  |  ok  |
[    0.808865]                          spinlock:  ok  |  ok  |  ok  |
[    0.817805] -------------------------------------------------------
[    0.817940] Good, all 261 testcases passed! |
[    0.818042] ---------------------------------
[    0.818374] Calibrating delay loop (skipped), value calculated using timer frequency.. 100.00 BogoMIPS (lpj=200000)
[    0.818650] pid_max: default: 32768 minimum: 301
[    0.819127] LSM: Security Framework initializing
[    0.819431] Mount-cache hash table entries: 16384 (order: 5, 131072 bytes, linear)
[    0.819637] Mountpoint-cache hash table entries: 16384 (order: 5, 131072 bytes, linear)
[    0.855086] rcu: Hierarchical SRCU implementation.
[    0.872279] EFI services will not be available.
[    0.879406] smp: Bringing up secondary CPUs ...
[    0.925493] CPU features: detected: EL2 vector hardening
[    0.925506] ARM_SMCCC_ARCH_WORKAROUND_1 missing from firmware
[    0.925513] CPU features: detected: ARM erratum 1319367
[    0.925520] Detected PIPT I-cache on CPU1
[    0.925581] CPU1: Booted secondary processor 0x0000000000 [0x410fd080]
[    0.969796] Detected PIPT I-cache on CPU2
[    0.969832] CPU2: Booted secondary processor 0x0000000001 [0x410fd080]
[    1.014237] Detected VIPT I-cache on CPU3
[    1.014311] CPU3: Booted secondary processor 0x0000000101 [0x410fd033]
[    1.058634] Detected VIPT I-cache on CPU4
[    1.058692] CPU4: Booted secondary processor 0x0000000102 [0x410fd033]
[    1.103056] Detected VIPT I-cache on CPU5
[    1.103113] CPU5: Booted secondary processor 0x0000000103 [0x410fd033]
[    1.103736] smp: Brought up 1 node, 6 CPUs
[    1.105371] SMP: Total of 6 processors activated.
[    1.105592] CPU features: detected: 32-bit EL0 Support
[    1.105727] CPU features: detected: CRC32 instructions
[    1.168474] CPU: All CPU(s) started at EL2
[    1.168736] alternatives: patching kernel code
[    1.173894] devtmpfs: initialized
[    1.193840] KASLR disabled due to lack of seed
[    1.195999] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[    1.196122] futex hash table entries: 2048 (order: 6, 262144 bytes, linear)
[    1.197685] xor: measuring software checksum speed
[    1.234635]    8regs     :  4238.000 MB/sec
[    1.274844]    32regs    :  4762.000 MB/sec
[    1.315096]    arm64_neon:  4290.000 MB/sec
[    1.315150] xor: using function: 32regs (4762.000 MB/sec)
[    1.315220] pinctrl core: initialized pinctrl subsystem
[    1.317981] thermal_sys: Registered thermal governor 'step_wise'
[    1.317988] thermal_sys: Registered thermal governor 'power_allocator'
[    1.319705] DMI not present or invalid.
[    1.320967] NET: Registered protocol family 16
[    1.325075] DMA: preallocated 256 KiB pool for atomic allocations
[    1.325159] audit: initializing netlink subsys (disabled)
[    1.325695] audit: type=2000 audit(1.044:1): state=initialized audit_enabled=0 res=1
[    1.327803] cpuidle: using governor menu
[    1.328072] NET: Registered protocol family 42
[    1.328670] hw-breakpoint: found 6 breakpoint and 4 watchpoint registers.
[    1.329170] ASID allocator initialised with 65536 entries
[    1.331184] Serial: AMBA PL011 UART driver
[    1.361153] 7ff80000.uart: ttyAMA0 at MMIO 0x7ff80000 (irq = 31, base_baud = 0) is a PL011 rev3
[    2.798369] printk: console [ttyAMA0] enabled
[    2.870617] HugeTLB registered 1.00 GiB page size, pre-allocated 0 pages
[    2.877509] HugeTLB registered 32.0 MiB page size, pre-allocated 0 pages
[    2.884316] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages
[    2.891122] HugeTLB registered 64.0 KiB page size, pre-allocated 0 pages
[    2.924275] cryptd: max_cpu_qlen set to 1000
[    3.021921] raid6: neonx8   gen()  3076 MB/s
[    3.094380] raid6: neonx8   xor()  2156 MB/s
[    3.166878] raid6: neonx4   gen()  3066 MB/s
[    3.239290] raid6: neonx4   xor()  2275 MB/s
[    3.311749] raid6: neonx2   gen()  2655 MB/s
[    3.384196] raid6: neonx2   xor()  2059 MB/s
[    3.456660] raid6: neonx1   gen()  1970 MB/s
[    3.529097] raid6: neonx1   xor()  1619 MB/s
[    3.601566] raid6: int64x8  gen()  1555 MB/s
[    3.674001] raid6: int64x8  xor()   899 MB/s
[    3.746469] raid6: int64x4  gen()  1788 MB/s
[    3.818905] raid6: int64x4  xor()   971 MB/s
[    3.891361] raid6: int64x2  gen()  1592 MB/s
[    3.963807] raid6: int64x2  xor()   846 MB/s
[    4.036254] raid6: int64x1  gen()  1225 MB/s
[    4.108747] raid6: int64x1  xor()   639 MB/s
[    4.113096] raid6: using algorithm neonx8 gen() 3076 MB/s
[    4.118582] raid6: .... xor() 2156 MB/s, rmw enabled
[    4.123628] raid6: using neon recovery algorithm
[    4.129207] ACPI: Interpreter disabled.
[    4.135997] iommu: Default domain type: Translated 
[    4.141562] vgaarb: loaded
[    4.145325] SCSI subsystem initialized
[    4.149678] libata version 3.00 loaded.
[    4.154233] usbcore: registered new interface driver usbfs
[    4.159929] usbcore: registered new interface driver hub
[    4.165531] usbcore: registered new device driver usb
[    4.173548] mc: Linux media interface: v0.10
[    4.177978] videodev: Linux video capture interface: v2.00
[    4.183822] pps_core: LinuxPPS API ver. 1 registered
[    4.188875] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    4.198170] PTP clock support registered
[    4.202965] EDAC MC: Ver: 3.0.0
[    4.208840] FPGA manager framework
[    4.212815] Advanced Linux Sound Architecture Driver Initialized.
[    4.220404] Bluetooth: Core ver 2.22
[    4.224123] NET: Registered protocol family 31
[    4.228653] Bluetooth: HCI device and connection manager initialized
[    4.235146] Bluetooth: HCI socket layer initialized
[    4.240120] Bluetooth: L2CAP socket layer initialized
[    4.245316] Bluetooth: SCO socket layer initialized
[    4.251866] clocksource: Switched to clocksource arch_sys_counter
[    5.094257] VFS: Disk quotas dquot_6.6.0
[    5.098389] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    5.106111] pnp: PnP ACPI: disabled
[    5.128825] NET: Registered protocol family 2
[    5.134147] tcp_listen_portaddr_hash hash table entries: 4096 (order: 6, 294912 bytes, linear)
[    5.143582] TCP established hash table entries: 65536 (order: 7, 524288 bytes, linear)
[    5.151961] TCP bind hash table entries: 65536 (order: 10, 4194304 bytes, linear)
[    5.170386] TCP: Hash tables configured (established 65536 bind 65536)
[    5.177605] UDP hash table entries: 4096 (order: 7, 655360 bytes, linear)
[    5.186030] UDP-Lite hash table entries: 4096 (order: 7, 655360 bytes, linear)
[    5.195062] NET: Registered protocol family 1
[    5.201498] RPC: Registered named UNIX socket transport module.
[    5.207580] RPC: Registered udp transport module.
[    5.212385] RPC: Registered tcp transport module.
[    5.217186] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    5.224830] PCI: CLS 0 bytes, default 64
[    6.572338] hw perfevents: enabled with armv8_cortex_a72 PMU driver, 7 counters available
[    6.581996] hw perfevents: enabled with armv8_cortex_a53 PMU driver, 7 counters available
[    6.590456] kvm [1]: IPA Size Limit: 40bits
[    6.603487] kvm [1]: vgic interrupt IRQ1
[    6.608115] kvm [1]: Hyp mode initialized successfully
[    7.077003] rcu-torture:--- Start of test: nreaders=5 nfakewriters=4 stat_interval=60 verbose=1 test_no_idle_hz=1 shuffle_interval=3 stutter=5 irqreader=1 fqs_duration=0 fqs_holdoff=0 fqs_stutter=3 test_boost=1/0 test_boost_interval=7 test_boost_duration=4 shutdown_secs=0 stall_cpu=0 stall_cpu_holdoff=10 stall_cpu_irqsoff=0 n_barrier_cbs=0 onoff_interval=0 onoff_holdoff=0
[    7.110912] rcu-torture: Creating rcu_torture_writer task
[    7.116921] rcu-torture: rcu_torture_writer task started
[    7.116978] rcu-torture: Creating rcu_torture_fakewriter task
[    7.122474] rcu-torture: GP expediting controlled from boot/sysfs for rcu.
[    7.128706] rcu-torture: Creating rcu_torture_fakewriter task
[    7.128721] rcu-torture: rcu_torture_fakewriter task started
[    7.135516] rcu_torture_writer: Testing conditional GPs.
[    7.135529] rcu_torture_writer: Testing expedited GPs.
[    7.135541] rcu_torture_writer: Testing asynchronous GPs.
[    7.135553] rcu_torture_writer: Testing normal GPs.
[    7.169278] rcu-torture: Creating rcu_torture_fakewriter task
[    7.169332] rcu-torture: rcu_torture_fakewriter task started
[    7.175479] rcu-torture: Creating rcu_torture_fakewriter task
[    7.175508] rcu-torture: rcu_torture_fakewriter task started
[    7.192882] rcu-torture: rcu_torture_fakewriter task started
[    7.192892] rcu-torture: Creating rcu_torture_reader task
[    7.204420] rcu-torture: Creating rcu_torture_reader task
[    7.204461] rcu-torture: rcu_torture_reader task started
[    7.210172] rcu-torture: Creating rcu_torture_reader task
[    7.210201] rcu-torture: rcu_torture_reader task started
[    7.226585] rcu-torture: Creating rcu_torture_reader task
[    7.228494] rcu-torture: rcu_torture_reader task started
[    7.232344] rcu-torture: Creating rcu_torture_reader task
[    7.237625] rcu-torture: rcu_torture_reader task started
[    7.243256] rcu-torture: Creating rcu_torture_stats task
[    7.244853] rcu-torture: rcu_torture_reader task started
[    7.259962] rcu-torture: Creating torture_shuffle task
[    7.259968] rcu-torture: rcu_torture_stats task started
[    7.265475] rcu-torture: Creating torture_stutter task
[    7.275822] rcu-torture: torture_shuffle task started
[    7.281238] rcu-torture: Creating rcu_torture_fwd_prog task
[    7.287088] rcu-torture: torture_stutter task started
[    7.290982] Initialise system trusted keyrings
[    7.292318] rcu-torture: rcu_torture_fwd_progress task started
[    7.297206] workingset: timestamp_bits=44 max_order=21 bucket_order=0
[    7.338244] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    7.346622] NFS: Registering the id_resolver key type
[    7.351878] Key type id_resolver registered
[    7.356176] Key type id_legacy registered
[    7.360288] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[    7.367522] fuse: init (API version 7.31)
[    7.373094] 9p: Installing v9fs 9p2000 file system support
[    7.402140] Key type asymmetric registered
[    7.406393] Asymmetric key parser 'x509' registered
[    7.411440] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 243)
[    7.418983] io scheduler mq-deadline registered
[    7.423603] io scheduler kyber registered
[    7.443299] pl061_gpio 1c1d0000.gpio: PL061 GPIO chip registered
[    7.453154] pci-host-generic 40000000.pcie: host bridge /pcie@40000000 ranges:
[    7.460555] pci-host-generic 40000000.pcie:       IO 0x005f800000..0x005fffffff -> 0x0000000000
[    7.469469] pci-host-generic 40000000.pcie:      MEM 0x0050000000..0x0057ffffff -> 0x0050000000
[    7.478332] pci-host-generic 40000000.pcie:      MEM 0x4000000000..0x40ffffffff -> 0x4000000000
[    7.487282] pci-host-generic 40000000.pcie: ECAM at [mem 0x40000000-0x4fffffff] for [bus 00-ff]
[    7.496483] pci-host-generic 40000000.pcie: PCI host bridge to bus 0000:00
[    7.503487] pci_bus 0000:00: root bus resource [bus 00-ff]
[    7.509081] pci_bus 0000:00: root bus resource [io  0x0000-0x7fffff]
[    7.515554] pci_bus 0000:00: root bus resource [mem 0x50000000-0x57ffffff]
[    7.522555] pci_bus 0000:00: root bus resource [mem 0x4000000000-0x40ffffffff pref]
[    7.530434] pci 0000:00:00.0: [1556:1100] type 01 class 0x060400
[    7.536607] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x00003fff 64bit pref]
[    7.544142] pci 0000:00:00.0: supports D1 D2
[    7.548504] pci 0000:00:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[    7.557347] pci 0000:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[    7.565770] pci 0000:01:00.0: [111d:8090] type 01 class 0x060400
[    7.572049] pci 0000:01:00.0: enabling Extended Tags
[    7.577301] pci 0000:01:00.0: PME# supported from D0 D3hot D3cold
[    7.597290] pci 0000:01:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[    7.605812] pci 0000:02:01.0: [111d:8090] type 01 class 0x060400
[    7.612083] pci 0000:02:01.0: enabling Extended Tags
[    7.617356] pci 0000:02:01.0: PME# supported from D0 D3hot D3cold
[    7.624225] pci 0000:02:02.0: [111d:8090] type 01 class 0x060400
[    7.630498] pci 0000:02:02.0: enabling Extended Tags
[    7.635769] pci 0000:02:02.0: PME# supported from D0 D3hot D3cold
[    7.642594] pci 0000:02:03.0: [111d:8090] type 01 class 0x060400
[    7.648862] pci 0000:02:03.0: enabling Extended Tags
[    7.654133] pci 0000:02:03.0: PME# supported from D0 D3hot D3cold
[    7.661312] pci 0000:02:0c.0: [111d:8090] type 01 class 0x060400
[    7.667579] pci 0000:02:0c.0: enabling Extended Tags
[    7.672850] pci 0000:02:0c.0: PME# supported from D0 D3hot D3cold
[    7.679805] pci 0000:02:10.0: [111d:8090] type 01 class 0x060400
[    7.686059] pci 0000:02:10.0: enabling Extended Tags
[    7.691313] pci 0000:02:10.0: PME# supported from D0 D3hot D3cold
[    7.698750] pci 0000:02:1f.0: [111d:8090] type 01 class 0x060400
[    7.705018] pci 0000:02:1f.0: enabling Extended Tags
[    7.710287] pci 0000:02:1f.0: PME# supported from D0 D3hot D3cold
[    7.717099] pci 0000:02:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[    7.725258] pci 0000:02:02.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[    7.733423] pci 0000:02:03.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[    7.741596] pci 0000:02:0c.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[    7.749754] pci 0000:02:10.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[    7.757908] pci 0000:02:1f.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[    7.766376] pci 0000:03:00.0: [1095:3132] type 00 class 0x018000
[    7.772564] pci 0000:03:00.0: reg 0x10: [mem 0x00000000-0x0000007f 64bit]
[    7.779501] pci 0000:03:00.0: reg 0x18: [mem 0x00000000-0x00003fff 64bit]
[    7.786422] pci 0000:03:00.0: reg 0x20: [io  0x0000-0x007f]
[    7.792133] pci 0000:03:00.0: reg 0x30: [mem 0x00000000-0x0007ffff pref]
[    7.799115] pci 0000:03:00.0: supports D1 D2
[    7.803979] pci 0000:03:00.0: disabling ASPM on pre-1.1 PCIe device.  You can enable it with 'pcie_aspm=force'
[    7.815435] pci_bus 0000:03: busn_res: [bus 03-ff] end is updated to 03
[    7.823681] pci_bus 0000:04: busn_res: [bus 04-ff] end is updated to 04
[    7.831969] pci_bus 0000:05: busn_res: [bus 05-ff] end is updated to 05
[    7.840257] pci_bus 0000:06: busn_res: [bus 06-ff] end is updated to 06
[    7.848558] pci_bus 0000:07: busn_res: [bus 07-ff] end is updated to 07
[    7.855611] pci 0000:08:00.0: [11ab:4380] type 00 class 0x020000
[    7.861796] pci 0000:08:00.0: reg 0x10: [mem 0x00000000-0x00003fff 64bit]
[    7.868717] pci 0000:08:00.0: reg 0x18: [io  0x0000-0x00ff]
[    7.874629] pci 0000:08:00.0: supports D1 D2
[    7.878987] pci 0000:08:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[    7.887674] pci_bus 0000:08: busn_res: [bus 08-ff] end is updated to 08
[    7.894415] pci_bus 0000:02: busn_res: [bus 02-ff] end is updated to 08
[    7.901151] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 08
[    7.907908] pci 0000:00:00.0: BAR 14: assigned [mem 0x50000000-0x501fffff]
[    7.914903] pci 0000:00:00.0: BAR 0: assigned [mem 0x4000000000-0x4000003fff 64bit pref]
[    7.923140] pci 0000:00:00.0: BAR 13: assigned [io  0x1000-0x2fff]
[    7.929441] pci 0000:01:00.0: BAR 14: assigned [mem 0x50000000-0x501fffff]
[    7.936433] pci 0000:01:00.0: BAR 13: assigned [io  0x1000-0x2fff]
[    7.942734] pci 0000:02:01.0: BAR 14: assigned [mem 0x50000000-0x500fffff]
[    7.949726] pci 0000:02:1f.0: BAR 14: assigned [mem 0x50100000-0x501fffff]
[    7.956722] pci 0000:02:01.0: BAR 13: assigned [io  0x1000-0x1fff]
[    7.963027] pci 0000:02:1f.0: BAR 13: assigned [io  0x2000-0x2fff]
[    7.969336] pci 0000:03:00.0: BAR 6: assigned [mem 0x50000000-0x5007ffff pref]
[    7.976696] pci 0000:03:00.0: BAR 2: assigned [mem 0x50080000-0x50083fff 64bit]
[    7.984155] pci 0000:03:00.0: BAR 0: assigned [mem 0x50084000-0x5008407f 64bit]
[    7.991613] pci 0000:03:00.0: BAR 4: assigned [io  0x1000-0x107f]
[    7.997826] pci 0000:02:01.0: PCI bridge to [bus 03]
[    8.002888] pci 0000:02:01.0:   bridge window [io  0x1000-0x1fff]
[    8.009099] pci 0000:02:01.0:   bridge window [mem 0x50000000-0x500fffff]
[    8.016023] pci 0000:02:02.0: PCI bridge to [bus 04]
[    8.021115] pci 0000:02:03.0: PCI bridge to [bus 05]
[    8.026206] pci 0000:02:0c.0: PCI bridge to [bus 06]
[    8.031297] pci 0000:02:10.0: PCI bridge to [bus 07]
[    8.036397] pci 0000:08:00.0: BAR 0: assigned [mem 0x50100000-0x50103fff 64bit]
[    8.043882] pci 0000:08:00.0: BAR 2: assigned [io  0x2000-0x20ff]
[    8.050092] pci 0000:02:1f.0: PCI bridge to [bus 08]
[    8.055153] pci 0000:02:1f.0:   bridge window [io  0x2000-0x2fff]
[    8.061363] pci 0000:02:1f.0:   bridge window [mem 0x50100000-0x501fffff]
[    8.068290] pci 0000:01:00.0: PCI bridge to [bus 02-08]
[    8.073633] pci 0000:01:00.0:   bridge window [io  0x1000-0x2fff]
[    8.079883] pci 0000:01:00.0:   bridge window [mem 0x50000000-0x501fffff]
[    8.086808] pci 0000:00:00.0: PCI bridge to [bus 01-08]
[    8.092132] pci 0000:00:00.0:   bridge window [io  0x1000-0x2fff]
[    8.098343] pci 0000:00:00.0:   bridge window [mem 0x50000000-0x501fffff]
[    8.105696] pcieport 0000:00:00.0: enabling device (0000 -> 0003)
[    8.119956] pcieport 0000:00:00.0: PME: Signaling with IRQ 44
[    8.126905] pcieport 0000:00:00.0: AER: enabled with IRQ 44
[    8.133174] pcieport 0000:01:00.0: enabling device (0000 -> 0003)
[    8.139619] pcieport 0000:02:01.0: enabling device (0000 -> 0003)
[    8.150481] pcieport 0000:02:1f.0: enabling device (0000 -> 0003)
[    8.160437] IPMI message handler: version 39.2
[    8.165148] ipmi device interface
[    8.168672] ipmi_si: IPMI System Interface driver
[    8.174113] ipmi_si: Unable to find any System Interface(s)
[    8.181063] EINJ: ACPI disabled.
[    8.193709] dma-pl330 7ff00000.dma: WARN: Device release is not defined so it is not safe to unbind this driver while in use
[    8.206485] dma-pl330 7ff00000.dma: Loaded driver for PL330 DMAC-341330
[    8.213223] dma-pl330 7ff00000.dma: 	DBUFF-1024x16bytes Num_Chans-8 Num_Peri-8 Num_Events-8
[    8.238224] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    8.250126] SuperH (H)SCI(F) driver initialized
[    8.255426] msm_serial: driver initialized
[    8.263297] arm-smmu 7fb10000.iommu: probing hardware configuration...
[    8.269962] arm-smmu 7fb10000.iommu: SMMUv1 with:
[    8.274768] arm-smmu 7fb10000.iommu: 	stage 2 translation
[    8.280274] arm-smmu 7fb10000.iommu: 	non-coherent table walk
[    8.286124] arm-smmu 7fb10000.iommu: 	(IDR0.CTTW overridden by FW configuration)
[    8.293648] arm-smmu 7fb10000.iommu: 	stream matching with 2 register groups
[    8.300820] arm-smmu 7fb10000.iommu: 	1 context banks (1 stage-2 only)
[    8.307472] arm-smmu 7fb10000.iommu: 	Supported page sizes: 0x60211000
[    8.314117] arm-smmu 7fb10000.iommu: 	Stage-2: 40-bit IPA -> 40-bit PA
[    8.321680] arm-smmu 7fb20000.iommu: probing hardware configuration...
[    8.328333] arm-smmu 7fb20000.iommu: SMMUv1 with:
[    8.333131] arm-smmu 7fb20000.iommu: 	stage 2 translation
[    8.338635] arm-smmu 7fb20000.iommu: 	non-coherent table walk
[    8.344489] arm-smmu 7fb20000.iommu: 	(IDR0.CTTW overridden by FW configuration)
[    8.352026] arm-smmu 7fb20000.iommu: 	stream matching with 2 register groups
[    8.359206] arm-smmu 7fb20000.iommu: 	1 context banks (1 stage-2 only)
[    8.365869] arm-smmu 7fb20000.iommu: 	Supported page sizes: 0x60211000
[    8.372530] arm-smmu 7fb20000.iommu: 	Stage-2: 40-bit IPA -> 40-bit PA
[    8.379670] arm-smmu 7fb30000.iommu: probing hardware configuration...
[    8.386320] arm-smmu 7fb30000.iommu: SMMUv1 with:
[    8.391116] arm-smmu 7fb30000.iommu: 	stage 2 translation
[    8.396615] arm-smmu 7fb30000.iommu: 	coherent table walk
[    8.402122] arm-smmu 7fb30000.iommu: 	stream matching with 2 register groups
[    8.409299] arm-smmu 7fb30000.iommu: 	1 context banks (1 stage-2 only)
[    8.415948] arm-smmu 7fb30000.iommu: 	Supported page sizes: 0x60211000
[    8.422588] arm-smmu 7fb30000.iommu: 	Stage-2: 40-bit IPA -> 40-bit PA
[    8.567995] tda998x 0-0070: found TDA19988
[    8.700032] tda998x 0-0071: found TDA19988
[    8.770858] loop: module loaded
[    8.909277] mpt3sas version 33.100.00.00 loaded
[    8.918139] sata_sil24 0000:03:00.0: version 1.1
[    8.922891] sata_sil24 0000:03:00.0: enabling device (0000 -> 0003)
[    8.932880] scsi host0: sata_sil24
[    8.937935] scsi host1: sata_sil24
[    8.941931] ata1: SATA max UDMA/100 host m128@0x50084000 port 0x50080000 irq 51
[    8.949371] ata2: SATA max UDMA/100 host m128@0x50084000 port 0x50082000 irq 51
[    8.964337] libphy: Fixed MDIO Bus: probed
[    8.970767] tun: Universal TUN/TAP device driver, 1.6
[    8.977464] bnx2x: QLogic 5771x/578xx 10/20-Gigabit Ethernet Driver bnx2x 1.713.36-0 (2014/02/10)
[    8.987430] thunder_xcv, ver 1.0
[    8.990880] thunder_bgx, ver 1.0
[    8.994307] nicpf, ver 1.0
[    8.997957] hclge is initializing
[    9.001745] hns3: Hisilicon Ethernet Network Driver for Hip08 Family - version
[    9.009110] hns3: Copyright (c) 2017 Huawei Corporation.
[    9.014690] e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k
[    9.020626] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
[    9.026786] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.6.0-k
[    9.033865] igb: Copyright (c) 2007-2014 Intel Corporation.
[    9.039659] igbvf: Intel(R) Gigabit Virtual Function Network Driver - version 2.4.0-k
[    9.047614] igbvf: Copyright (c) 2009 - 2012 Intel Corporation.
[    9.054325] sky2: driver version 1.30
[    9.058390] sky2 0000:08:00.0: enabling device (0000 -> 0003)
[    9.064334] sky2 0000:08:00.0: Yukon-2 UL 2 chip revision 0
[    9.070122] sky2 0000:08:00.0 (unnamed net_device) (uninitialized): Invalid MAC address, defaulting to random
[    9.122388] libphy: smsc911x-mdio: probed
[    9.137784] pegasus: v0.9.3 (2013/04/25), Pegasus/Pegasus II USB Ethernet driver
[    9.145400] usbcore: registered new interface driver pegasus
[    9.151233] usbcore: registered new interface driver rtl8150
[    9.157096] usbcore: registered new interface driver r8152
[    9.162746] usbcore: registered new interface driver lan78xx
[    9.168604] usbcore: registered new interface driver asix
[    9.174168] usbcore: registered new interface driver ax88179_178a
[    9.180438] usbcore: registered new interface driver cdc_ether
[    9.186437] usbcore: registered new interface driver dm9601
[    9.192200] usbcore: registered new interface driver CoreChips
[    9.198235] usbcore: registered new interface driver smsc75xx
[    9.204176] usbcore: registered new interface driver smsc95xx
[    9.210087] usbcore: registered new interface driver net1080
[    9.215963] usbcore: registered new interface driver plusb
[    9.221634] usbcore: registered new interface driver cdc_subset
[    9.227726] usbcore: registered new interface driver zaurus
[    9.233461] usbcore: registered new interface driver MOSCHIP usb-ethernet driver
[    9.241085] usbcore: registered new interface driver cdc_ncm
[    9.247396] VFIO - User Level meta-driver version: 0.3
[    9.256195] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    9.262889] ehci-pci: EHCI PCI platform driver
[    9.267528] ehci-platform: EHCI generic platform driver
[    9.273435] ehci-platform 7ffc0000.ehci: Adding to iommu group 0
[    9.280068] ehci-platform 7ffc0000.ehci: EHCI Host Controller
[    9.286078] ehci-platform 7ffc0000.ehci: new USB bus registered, assigned bus number 1
[    9.294554] ehci-platform 7ffc0000.ehci: irq 34, io mem 0x7ffc0000
[    9.315965] ehci-platform 7ffc0000.ehci: USB 2.0 started, EHCI 1.00
[    9.325070] hub 1-0:1.0: USB hub found
[    9.329074] hub 1-0:1.0: 1 port detected
[    9.334431] ehci-orion: EHCI orion driver
[    9.338751] ehci-exynos: EHCI Exynos driver
[    9.343214] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    9.349530] ohci-pci: OHCI PCI platform driver
[    9.354170] ohci-platform: OHCI generic platform driver
[    9.359769] ohci-platform 7ffb0000.ohci: Adding to iommu group 0
[    9.366095] ohci-platform 7ffb0000.ohci: Generic Platform OHCI controller
[    9.373043] ohci-platform 7ffb0000.ohci: new USB bus registered, assigned bus number 2
[    9.381357] ohci-platform 7ffb0000.ohci: irq 33, io mem 0x7ffb0000
[    9.465980] hub 2-0:1.0: USB hub found
[    9.469922] hub 2-0:1.0: 1 port detected
[    9.474925] ohci-exynos: OHCI Exynos driver
[    9.480138] usbcore: registered new interface driver usb-storage
[    9.495052] rtc-pl031 1c170000.rtc: registered as rtc0
[    9.501816] i2c /dev entries driver
[    9.510750] usbcore: registered new interface driver uvcvideo
[    9.516601] USB Video Class driver (1.1.1)
[    9.520780] gspca_main: v2.14.0 registered
[    9.531569] sp805-wdt 1c0f0000.wdt: registration successful
[    9.540146] device-mapper: ioctl: 4.42.0-ioctl (2020-02-27) initialised: dm-devel@redhat.com
[    9.548791] Bluetooth: HCI UART driver ver 2.3
[    9.553326] Bluetooth: HCI UART protocol H4 registered
[    9.558609] Bluetooth: HCI UART protocol LL registered
[    9.564081] Bluetooth: HCI UART protocol Broadcom registered
[    9.569971] usbcore: registered new interface driver btusb
[    9.578149] mmci-pl18x 1c050000.mmci: mmc0: PL180 manf 41 rev0 at 0x1c050000 irq 9,0 (pio)
[    9.612337] sdhci: Secure Digital Host Controller Interface driver
[    9.618760] sdhci: Copyright(c) Pierre Ossman
[    9.623910] Synopsys Designware Multimedia Card Interface Driver
[    9.631804] sdhci-pltfm: SDHCI platform and OF driver helper
[    9.641121] leds-syscon 1c010000.apbregs:led0: registered LED vexpress:0
[    9.648501] leds-syscon 1c010000.apbregs:led1: registered LED vexpress:1
[    9.655722] leds-syscon 1c010000.apbregs:led2: registered LED vexpress:2
[    9.663004] leds-syscon 1c010000.apbregs:led3: registered LED vexpress:3
[    9.670217] leds-syscon 1c010000.apbregs:led4: registered LED vexpress:4
[    9.675925] usb 1-1: new high-speed USB device number 2 using ehci-platform
[    9.677555] leds-syscon 1c010000.apbregs:led5: registered LED vexpress:5
[    9.691379] leds-syscon 1c010000.apbregs:led6: registered LED vexpress:6
[    9.698697] leds-syscon 1c010000.apbregs:led7: registered LED vexpress:7
[    9.706674] ledtrig-cpu: registered to indicate activity on CPUs
[    9.716940] usbcore: registered new interface driver usbhid
[    9.718536] hub 1-1:1.0: USB hub found
[    9.722710] usbhid: USB HID core driver
[    9.726796] hub 1-1:1.0: 4 ports detected
[    9.731660] mhu 2b1f0000.mhu: ARM MHU Mailbox registered
[    9.753570] drop_monitor: Initializing network drop monitor service
[    9.764502] NET: Registered protocol family 10
[    9.771387] Segment Routing with IPv6
[    9.775683] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
[    9.783056] NET: Registered protocol family 17
[    9.787822] Bridge firewalling registered
[    9.791925] Bluetooth: HIDP (Human Interface Emulation) ver 1.2
[    9.797958] Bluetooth: HIDP socket layer initialized
[    9.803093] 8021q: 802.1Q VLAN Support v1.8
[    9.807737] 9pnet: Installing 9P2000 support
[    9.812269] Key type dns_resolver registered
[    9.818002] registered taskstats version 1
[    9.818711] random: fast init done
[    9.822216] Loading compiled-in X.509 certificates
[    9.833679] Btrfs loaded, crc32c=crc32c-generic
[    9.849847] scpi_protocol scpi: SCP Protocol 1.2 Firmware 1.21.0 version
[    9.902826] arm-smmu 2b600000.iommu: probing hardware configuration...
[    9.909730] arm-smmu 2b600000.iommu: SMMUv1 with:
[    9.914561] arm-smmu 2b600000.iommu: 	stage 2 translation
[    9.920057] arm-smmu 2b600000.iommu: 	coherent table walk
[    9.925554] arm-smmu 2b600000.iommu: 	stream matching with 2 register groups
[    9.932718] arm-smmu 2b600000.iommu: 	1 context banks (1 stage-2 only)
[    9.939356] arm-smmu 2b600000.iommu: 	Supported page sizes: 0x60211000
[    9.945999] arm-smmu 2b600000.iommu: 	Stage-2: 40-bit IPA -> 40-bit PA
[    9.955816] input: smb@8000000:motherboard:gpio-keys as /devices/platform/smb@8000000/smb@8000000:motherboard/smb@8000000:motherboard:gpio-keys/input/input1
[    9.972285] rtc-pl031 1c170000.rtc: setting system clock to 2020-03-24T10:26:12 UTC (1585045572)
[   10.300127] usb 1-1.1: new high-speed USB device number 3 using ehci-platform
[   10.349460] usb-storage 1-1.1:1.0: USB Mass Storage device detected
[   10.363200] scsi host2: usb-storage 1-1.1:1.0
[   10.503999] atkbd serio0: keyboard reset failed on 1c060000.kmi
[   10.960092] ata1: SATA link down (SStatus 0 SControl 0)
[   11.410625] scsi 2:0:0:0: Direct-Access     TOSHIBA  TransMemory      PMAP PQ: 0 ANSI: 6
[   11.427539] sd 2:0:0:0: [sda] 30253056 512-byte logical blocks: (15.5 GB/14.4 GiB)
[   11.437183] sd 2:0:0:0: [sda] Write Protect is off
[   11.442275] sd 2:0:0:0: [sda] Mode Sense: 45 00 00 00
[   11.449859] sd 2:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[   11.532644]  sda: sda1 sda2
[   11.554491] sd 2:0:0:0: [sda] Attached SCSI removable disk
[   11.751890] atkbd serio1: keyboard reset failed on 1c070000.kmi
[   13.016042] ata2: SATA link down (SStatus 0 SControl 0)
[   13.027503] sky2 0000:08:00.0 eth0: enabling interface
[   13.034374] Generic PHY 18000000.ethernet-ffffffff:01: attached PHY driver [Generic PHY] (mii_bus:phy_addr=18000000.ethernet-ffffffff:01, irq=POLL)
[   13.049029] smsc911x 18000000.ethernet eth1: SMSC911x/921x identified at 0xffff800018ca0000, IRQ: 8
[   15.120048] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[   15.271436] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
[   15.280364] ALSA device list:
[   15.283426]   No soundcards found.
[   15.287501] uart-pl011 7ff80000.uart: no DMA platform data
[   15.293135] platform regulatory.0: Falling back to sysfs fallback for: regulatory.db
[   15.331598] Freeing unused kernel memory: 14656K
[   15.368044] Run /init as init process
[   15.371814]   with arguments:
[   15.376160]     /init
[   15.378500]     ttyAMA0,115200n8
[   15.381866]     verbose
[   15.384435]     nfsrootdebug
[   15.387392]   with environment:
[   15.390678]     HOME=/
[   15.393159]     TERM=linux
[   15.396026]     user_debug=31
[   15.399071]     bootargs_sky2=sky2.mac_address=0x00,0x02,0xf7,0x00,0x67,0xbe
[   15.520448] Adding 2543608k swap on /dev/sda2.  Priority:-2 extents:1 across:2543608k 
[   18.653510] input: PS/2 Generic Mouse as /devices/platform/smb@8000000/smb@8000000:motherboard/smb@8000000:motherboard:iofpga@3,00000000/1c060000.kmi/serio0/input/input3
[   18.797800] psmouse serio0: Failed to enable mouse on 1c060000.kmi
[   19.752741] random: dd: uninitialized urandom read (512 bytes read)
[   19.871823] random: ssh-keygen: uninitialized urandom read (32 bytes read)
[   19.903479] random: sshd: uninitialized urandom read (32 bytes read)
[   19.978048] sky2 0000:08:00.0 eth0: enabling interface
[   25.360833] input: PS/2 Generic Mouse as /devices/platform/smb@8000000/smb@8000000:motherboard/smb@8000000:motherboard:iofpga@3,00000000/1c070000.kmi/serio1/input/input4
[   25.496980] psmouse serio1: Failed to enable mouse on 1c070000.kmi
[   51.795983] Adding 2543608k swap on /dev/sda2.  Priority:-2 extents:1 across:2543608k 
[   58.003911] Adding 2543608k swap on /dev/sda2.  Priority:-2 extents:1 across:2543608k 
[   68.871904] rcu-torture: rtc: (____ptrval____) ver: 1352 tfle: 0 rta: 1353 rtaf: 0 rtf: 1341 rtmbe: 0 rtbe: 0 rtbke: 0 rtbre: 0 rtbf: 0 rtb: 0 nt: 24895 onoff: 0/0:0/0 -1,0:-1,0 0:0 (HZ=250) barrier: 0/0:0
[   68.891877] rcu-torture: Reader Pipe:  15093251 3894 0 0 0 0 0 0 0 0 0
[   68.898586] rcu-torture: Reader Batch:  15088478 8668 0 0 0 0 0 0 0 0 0
[   68.905361] rcu-torture: Free-Block Circulation:  1352 1351 1350 1349 1348 1347 1345 1344 1342 1341 0
[   77.064682] cfg80211: failed to load regulatory.db
[   82.483925] rcu_torture_fwd_prog_nr: Duration 3313 cver 132 gps 323
[   83.050946] rcu_torture_fwd_prog_cr Duration 29 barrier: 52 pending 11716 n_launders: 13871 n_launders_sa: 4213 n_max_gps: 100 n_max_cbs: 11831 cver 2 gps 7
[   83.135905] rcu_torture_fwd_cb_hist: Callback-invocation histogram (duration 103 jiffies): 1s/10: 7996:6 2s/10: 17706:4
[  130.311938] rcu-torture: rtc: (____ptrval____) ver: 2845 tfle: 0 rta: 2845 rtaf: 0 rtf: 2833 rtmbe: 0 rtbe: 0 rtbke: 0 rtbre: 0 rtbf: 0 rtb: 0 nt: 49544 onoff: 0/0:0/0 -1,0:-1,0 0:0 (HZ=250) barrier: 0/0:0
[  130.331472] rcu-torture: Reader Pipe:  30267437 8086 0 0 0 0 0 0 0 0 0
[  130.338371] rcu-torture: Reader Batch:  30258284 17244 0 0 0 0 0 0 0 0 0
[  130.345317] rcu-torture: Free-Block Circulation:  2847 2844 2842 2841 2839 2838 2837 2836 2834 2833 0
[  155.448590] PM: hibernation: hibernation entry
[  155.460881] Filesystems sync: 0.001 seconds
[  155.465293] Freezing user space processes ... (elapsed 0.002 seconds) done.
[  155.475391] OOM killer disabled.
[  155.483313] PM: hibernation: Preallocating image memory
[  157.508143] ------------[ cut here ]------------
[  157.512899] WARNING: CPU: 0 PID: 261 at kernel/rcu/rcutorture.c:1055 rcu_torture_writer+0x664/0xa90
[  157.522134] Modules linked in:
[  157.525267] CPU: 0 PID: 261 Comm: rcu_torture_wri Not tainted 5.6.0-rc6-00002-g533440e608d2 #537
[  157.534233] Hardware name: ARM Juno development board (r2) (DT)
[  157.540278] pstate: 00000005 (nzcv daif -PAN -UAO)
[  157.545175] pc : rcu_torture_writer+0x664/0xa90
[  157.549805] lr : rcu_torture_writer+0x65c/0xa90
[  157.554432] sp : ffff800018b63de0
[  157.557821] x29: ffff800018b63de0 x28: ffff80001426e320 
[  157.563253] x27: ffff80001426cf08 x26: ffff80001426cf08 
[  157.568683] x25: ffff8000121b5000 x24: 0000000000000001 
[  157.574111] x23: ffff80001426d648 x22: ffff80001426b000 
[  157.579540] x21: ffff800013439000 x20: ffff80001426e938 
[  157.584968] x19: ffff80001426c000 x18: 0000000000000000 
[  157.590397] x17: 0000000000000000 x16: 0000000000000000 
[  157.595825] x15: 0000000000000000 x14: 0000000000000000 
[  157.601254] x13: 0000000000000000 x12: 0000000000000003 
[  157.606682] x11: 000000000000050f x10: 0000000000000000 
[  157.612116] x9 : ffff800013a130a0 x8 : ffff000975051fd0 
[  157.617547] x7 : 0000000000000000 x6 : ffff800018b63cc0 
[  157.622977] x5 : 0000000000000001 x4 : 0000000000000000 
[  157.628406] x3 : 0000000000000080 x2 : 0000000002611501 
[  157.633835] x1 : 0000000000000000 x0 : 0000000000000001 
[  157.639265] Call trace:
[  157.641775]  rcu_torture_writer+0x664/0xa90
[  157.646054]  kthread+0x13c/0x140
[  157.649359]  ret_from_fork+0x10/0x18
[  157.653016] irq event stamp: 113198
[  157.656590] hardirqs last  enabled at (113197): [<ffff800010114300>] __local_bh_enable_ip+0x98/0x148
[  157.665917] hardirqs last disabled at (113198): [<ffff8000100a95d0>] do_debug_exception+0x1a8/0x258
[  157.675154] softirqs last  enabled at (113196): [<ffff8000101b92a4>] rcu_torture_free+0x84/0x98
[  157.684038] softirqs last disabled at (113194): [<ffff8000101b9280>] rcu_torture_free+0x60/0x98
[  157.692916] ---[ end trace dc3eeb58f7182c07 ]---
[  157.787490] PM: hibernation: Allocated 97253 pages for snapshot
[  157.793533] PM: hibernation: Allocated 389012 kbytes in 2.29 seconds (169.87 MB/s)
[  157.801242] Freezing remaining freezable tasks ... (elapsed 0.002 seconds) done.
[  157.813411] printk: Suspending console(s) (use no_console_suspend to debug)
[  157.872686] usbcore:hub_suspend: hub 1-1:1.0: hub_suspend
[  157.872801] ehci_hcd:qh_unlink_periodic: usb 1-1: unlink qh256-0001/(____ptrval____) start 1 [1/0 us]
[  157.875261] usbcore:hub_suspend: hub 1-0:1.0: hub_suspend
[  157.875422] usbcore:hcd_bus_suspend: usb usb1: bus suspend, wakeup 0
[  157.875435] ehci_hcd:ehci_bus_suspend: ehci-platform 7ffc0000.ehci: suspend root hub
[  157.918359] Disabling non-boot CPUs ...
[  157.922121] CPU1: shutdown
[  157.922214] psci: CPU1 killed (polled 0 ms)
[  157.931368] CPU2: shutdown
[  157.931919] psci: CPU2 killed (polled 4 ms)
[  157.958718] CPU3: shutdown
[  157.958742] psci: CPU3 killed (polled 0 ms)
[  157.978433] CPU4: shutdown
[  157.978457] psci: CPU4 killed (polled 0 ms)
[  157.987192] CPU5: shutdown
[  157.987216] psci: CPU5 killed (polled 0 ms)
[  157.989182] PM: hibernation: Creating image:
[  157.989182] PM: hibernation: Need to copy 95313 pages
[  157.989182] PM: hibernation: Image created (95313 pages copied)
[  157.989984] Enabling non-boot CPUs ...
[  158.003937] Detected PIPT I-cache on CPU1
[  158.004001] CPU1: Booted secondary processor 0x0000000000 [0x410fd080]
[  158.007405] CPU1 is up
[  158.029491] Detected PIPT I-cache on CPU2
[  158.029529] CPU2: Booted secondary processor 0x0000000001 [0x410fd080]
[  158.030995] CPU2 is up
[  158.044660] Detected VIPT I-cache on CPU3
[  158.044745] CPU3: Booted secondary processor 0x0000000101 [0x410fd033]
[  158.047796] CPU3 is up
[  158.061584] Detected VIPT I-cache on CPU4
[  158.061649] CPU4: Booted secondary processor 0x0000000102 [0x410fd033]
[  158.064910] CPU4 is up
[  158.078695] Detected VIPT I-cache on CPU5
[  158.078758] CPU5: Booted secondary processor 0x0000000103 [0x410fd033]
[  158.083170] CPU5 is up
[  158.103957] usbcore:hcd_bus_resume: usb usb1: usb resume
[  158.103986] ehci_hcd:ehci_bus_resume: ehci-platform 7ffc0000.ehci: resume root hub
[  158.113836] ohci_hcd:ohci_resume: ohci-platform 7ffb0000.ohci: powerup ports
[  158.139682] usbcore:hcd_bus_resume: usb usb2: usb resume
[  158.139715] ohci_hcd:ohci_rh_resume: ohci-platform 7ffb0000.ohci: resume root hub
[  158.162826] usbcore:hub_resume: hub 1-0:1.0: hub_resume
[  158.163176] usbcore:hub_activate: usb usb1-port1: status 0503 change 0000
[  158.163369] usbcore:hub_resume: hub 1-1:1.0: hub_resume
[  158.163735] usbcore:hub_activate: usb 1-1-port1: status 0503 change 0000
[  158.164492] ehci_hcd:qh_schedule: ehci-platform 7ffc0000.ehci: reused qh (____ptrval____) schedule
[  158.164506] ehci_hcd:qh_link_periodic: usb 1-1: link qh256-0001/(____ptrval____) start 1 [1/0 us]
[  158.219604] usbcore:hub_resume: hub 2-0:1.0: hub_resume
[  158.220482] usb usb2: runtime PM trying to activate child device usb2 but parent (7ffb0000.ohci) is not active
[  158.482995] PM: Cannot find swap device, try swapon -a
[  158.488379] PM: Cannot get swap writer
[  159.064094] OOM killer enabled.
[  159.067351] Restarting tasks ... 
[  159.068831] usbcore:hub_event: hub 2-0:1.0: state 7 ports 1 chg 0000 evt 0000
[  159.079921] usbcore:hub_event: hub 1-1:1.0: state 7 ports 4 chg 0000 evt 0000
[  159.079959] usbcore:hub_event: hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0000
[  159.090776] done.
[  159.097076] usbcore:hub_resume: hub 2-0:1.0: hub_resume
[  159.102961] ------------[ cut here ]------------
[  159.107805] URB (____ptrval____) submitted while active
[  159.113322] WARNING: CPU: 5 PID: 388 at drivers/usb/core/urb.c:363 usb_submit_urb+0x3d8/0x590
[  159.122054] Modules linked in:
[  159.125350] CPU: 5 PID: 388 Comm: kworker/5:2 Tainted: G        W         5.6.0-rc6-00002-g533440e608d2 #537
[  159.125365] Hardware name: ARM Juno development board (r2) (DT)
[  159.125379] Workqueue: usb_hub_wq hub_event
[  159.125396] pstate: 40000005 (nZcv daif -PAN -UAO)
[  159.150713] pc : usb_submit_urb+0x3d8/0x590
[  159.150724] lr : usb_submit_urb+0x3d8/0x590
[  159.150732] sp : ffff8000190938b0
[  159.150740] x29: ffff8000190938b0 x28: 0000000000000003 
[  159.150755] x27: ffff000970512b20 x26: ffff80001340d000 
[  159.150769] x25: ffff80001340d000 x24: ffff800019093b38 
[  159.150783] x23: 0000000000000004 x22: 0000000000000c00 
[  159.150797] x21: 0000000000000000 x20: 00000000fffffff0 
[  159.150811] x19: ffff0009704ef700 x18: ffffffffffffffff 
[  159.150825] x17: 0000000000000000 x16: 0000000000000000 
[  159.150839] x15: ffff80001340da88 x14: 0720072007200720 
[  159.150853] x13: 0720072007200720 x12: 0720072007200720 
[  159.150867] x11: 0000000000000000 x10: 00000000b9d5c580 
[  159.150881] x9 : 0000000000000002 x8 : ffff00097504a020 
[  159.150895] x7 : 0000000000000000 x6 : ffff00097efb6450 
[  159.150911] x5 : ffff00097efb6450 x4 : 0000000000000000 
[  159.150942] PM: hibernation: hibernation exit
[  159.240807] x3 : ffff00097efc6070 x2 : 0000000000000001 
[  159.246257] x1 : 9f98e61376502200 x0 : 0000000000000000 
[  159.251708] Call trace:
[  159.254228]  usb_submit_urb+0x3d8/0x590
[  159.258167]  hub_activate+0x108/0x7f0
[  159.261929]  hub_resume+0xac/0x148
[  159.265426]  usb_resume_interface.isra.10+0x60/0x138
[  159.270519]  usb_resume_both+0xe4/0x140
[  159.274460]  usb_runtime_resume+0x24/0x30
[  159.278579]  __rpm_callback+0xdc/0x138
[  159.282430]  rpm_callback+0x34/0x98
[  159.286015]  rpm_resume+0x4a8/0x720
[  159.289601]  rpm_resume+0x50c/0x720
[  159.293186]  __pm_runtime_resume+0x4c/0xb8
[  159.297393]  usb_autopm_get_interface+0x28/0x60
[  159.302041]  hub_event+0x80/0x16d8
[  159.305540]  process_one_work+0x2a4/0x748
[  159.309659]  worker_thread+0x48/0x498
[  159.313422]  kthread+0x13c/0x140
[  159.316742]  ret_from_fork+0x10/0x18
[  159.320413] irq event stamp: 1628
[  159.323825] hardirqs last  enabled at (1627): [<ffff80001019ea1c>] console_unlock+0x504/0x5b8
[  159.332561] hardirqs last disabled at (1628): [<ffff8000100a95d0>] do_debug_exception+0x1a8/0x258
[  159.341650] softirqs last  enabled at (1624): [<ffff8000100818a4>] __do_softirq+0x4bc/0x568
[  159.350207] softirqs last disabled at (1613): [<ffff8000101145a4>] irq_exit+0x144/0x150
[  159.358406] ---[ end trace dc3eeb58f7182c08 ]---
[  159.363503] hub 2-0:1.0: activate --> -16
[  159.367776] usbcore:hub_event: hub 2-0:1.0: state 7 ports 1 chg 0000 evt 0000
[  159.375217] usbcore:hub_suspend: hub 2-0:1.0: hub_suspend
[  159.380981] usbcore:hcd_bus_suspend: usb usb2: bus auto-suspend, wakeup 1
[  159.388048] ohci_hcd:ohci_rh_suspend: ohci-platform 7ffb0000.ohci: suspend root hub
[  159.767477] rcu_torture_fwd_prog_nr: Duration 3762 cver 287 gps 446
[  160.127595] ata1: SATA link down (SStatus 0 SControl 0)
[  160.199587] ata2: SATA link down (SStatus 0 SControl 0)
[  160.364599] rcu_torture_fwd_prog_cr Duration 60 barrier: 31 pending 14166 n_launders: 41977 n_launders_sa: 32650 n_max_gps: 100 n_max_cbs: 25188 cver 0 gps 13
[  160.378993] rcu_torture_fwd_cb_hist: Callback-invocation histogram (duration 94 jiffies): 1s/10: 9328:3 2s/10: 34895:6 3s/10: 22942:7
[  161.166729] usbcore:usb_remote_wakeup: usb usb2: usb wakeup-resume
[  161.173564] usbcore:hcd_bus_resume: usb usb2: usb auto-resume
[  161.179575] ohci_hcd:ohci_rh_resume: ohci-platform 7ffb0000.ohci: resume root hub
[  161.259656] usbcore:hub_resume: hub 2-0:1.0: hub_resume
[  161.265457] usbcore:hub_event: hub 2-0:1.0: state 7 ports 1 chg 0000 evt 0000
[  161.272917] usbcore:hub_suspend: hub 2-0:1.0: hub_suspend
[  161.279238] usbcore:hcd_bus_suspend: usb usb2: bus auto-suspend, wakeup 1
[  161.286336] ohci_hcd:ohci_rh_suspend: ohci-platform 7ffb0000.ohci: suspend root hub
[  164.787580] psmouse serio0: Failed to enable mouse on 1c060000.kmi
[  171.429093] psmouse serio1: Failed to enable mouse on 1c070000.kmi
[  171.510004] random: crng init done
[  187.479501] cpufreq: __target_index: Failed to change cpu frequency: -5
[  187.555502] cpufreq: __target_index: Failed to change cpu frequency: -5
[  187.623502] cpufreq: __target_index: Failed to change cpu frequency: -5

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: lockdep warning in urb.c:363 usb_submit_urb
  2020-03-24 10:46       ` Qais Yousef
@ 2020-03-24 13:20         ` Oliver Neukum
  2020-03-24 13:43           ` Qais Yousef
  2020-03-24 13:47         ` Alan Stern
  1 sibling, 1 reply; 50+ messages in thread
From: Oliver Neukum @ 2020-03-24 13:20 UTC (permalink / raw)
  To: Qais Yousef; +Cc: Greg Kroah-Hartman, linux-usb, linux-kernel

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

Am Dienstag, den 24.03.2020, 10:46 +0000 schrieb Qais Yousef:
> 
> I should have stuck to what I know then. I misread the documentation. Hopefully
> the attached looks better. I don't see the new debug you added emitted.

That is odd. Please try

echo "module usbcore +mfp" > /sys/kernel/debug/dynamic_debug/control

with the attached improved patch.

	Regards
		Oliver

[-- Attachment #2: 0001-usb-hub-additional-debugging.patch --]
[-- Type: text/x-patch, Size: 697 bytes --]

From 89b420f4b6fd41e8901267ee698ac9e5d498f8db Mon Sep 17 00:00:00 2001
From: Oliver Neukum <oneukum@suse.com>
Date: Mon, 23 Mar 2020 16:34:35 +0100
Subject: [PATCH 1/2] usb: hub additional debugging

---
 drivers/usb/core/hub.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 54cd8ef795ec..12ce2fdc4c2a 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1629,6 +1629,7 @@ static int hub_configure(struct usb_hub *hub,
 		ret = -ENOMEM;
 		goto fail;
 	}
+	dev_dbg(hub_dev, "%p URB allocated \n", hub->urb);
 
 	usb_fill_int_urb(hub->urb, hdev, pipe, *hub->buffer, maxp, hub_irq,
 		hub, endpoint->bInterval);
-- 
2.16.4


^ permalink raw reply related	[flat|nested] 50+ messages in thread

* Re: lockdep warning in urb.c:363 usb_submit_urb
  2020-03-24 13:20         ` Oliver Neukum
@ 2020-03-24 13:43           ` Qais Yousef
  2020-03-24 13:52             ` Alan Stern
  0 siblings, 1 reply; 50+ messages in thread
From: Qais Yousef @ 2020-03-24 13:43 UTC (permalink / raw)
  To: Oliver Neukum; +Cc: Greg Kroah-Hartman, linux-usb, linux-kernel

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

On 03/24/20 14:20, Oliver Neukum wrote:
> Am Dienstag, den 24.03.2020, 10:46 +0000 schrieb Qais Yousef:
> > 
> > I should have stuck to what I know then. I misread the documentation. Hopefully
> > the attached looks better. I don't see the new debug you added emitted.
> 
> That is odd. Please try
> 
> echo "module usbcore +mfp" > /sys/kernel/debug/dynamic_debug/control
> 
> with the attached improved patch.

Hmm still no luck


# history
   0 echo "module usbcore +mfp" > /sys/kernel/debug/dynamic_debug/control
   1 swapoff -a
   2 echo suspend > /sys/power/disk
   3 echo disk > /sys/power/state
   4 dmesg > usb.dmesg





# grep "URB allocated" /sys/kernel/debug/dynamic_debug/control
drivers/usb/core/hub.c:1632 [usbcore]hub_configure =pmf "%p URB allocated \012"





$ git log -p
commit dfd1731f9a3e7592135d2a6b2a5c5e1640a7eea4 (HEAD)
Author: Oliver Neukum <oneukum@suse.com>
Date:   Mon Mar 23 16:34:35 2020 +0100

    usb: hub additional debugging

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 54cd8ef795ec..12ce2fdc4c2a 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1629,6 +1629,7 @@ static int hub_configure(struct usb_hub *hub,
                ret = -ENOMEM;
                goto fail;
        }
+       dev_dbg(hub_dev, "%p URB allocated \n", hub->urb);

        usb_fill_int_urb(hub->urb, hdev, pipe, *hub->buffer, maxp, hub_irq,
                hub, endpoint->bInterval);


Thanks

--
Qais Yousef

[-- Attachment #2: usb.dmesg --]
[-- Type: text/plain, Size: 51854 bytes --]

[    0.000000] Booting Linux on physical CPU 0x0000000100 [0x410fd033]
[    0.000000] Linux version 5.6.0-rc6-00002-gdfd1731f9a3e (qyousef@e107158-lin) (gcc version 7.5.0 (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04)) #541 SMP PREEMPT Tue Mar 24 13:29:19 GMT 2020
[    0.000000] Machine model: ARM Juno development board (r2)
[    0.000000] earlycon: pl11 at MMIO 0x000000007ff80000 (options '')
[    0.000000] printk: bootconsole [pl11] enabled
[    0.000000] efi: Getting EFI parameters from FDT:
[    0.000000] efi: UEFI not found.
[    0.000000] cma: Reserved 32 MiB at 0x00000000fd000000
[    0.000000] NUMA: No NUMA configuration found
[    0.000000] NUMA: Faking a node at [mem 0x0000000080000000-0x00000009ffffffff]
[    0.000000] NUMA: NODE_DATA [mem 0x9fefdb000-0x9fefdcfff]
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x0000000080000000-0x00000000bfffffff]
[    0.000000]   DMA32    [mem 0x00000000c0000000-0x00000000ffffffff]
[    0.000000]   Normal   [mem 0x0000000100000000-0x00000009ffffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000080000000-0x00000000feffffff]
[    0.000000]   node   0: [mem 0x0000000880000000-0x00000009ffffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000080000000-0x00000009ffffffff]
[    0.000000] On node 0 totalpages: 2093056
[    0.000000]   DMA zone: 4096 pages used for memmap
[    0.000000]   DMA zone: 0 pages reserved
[    0.000000]   DMA zone: 262144 pages, LIFO batch:63
[    0.000000]   DMA32 zone: 4096 pages used for memmap
[    0.000000]   DMA32 zone: 258048 pages, LIFO batch:63
[    0.000000]   Normal zone: 24576 pages used for memmap
[    0.000000]   Normal zone: 1572864 pages, LIFO batch:63
[    0.000000] psci: probing for conduit method from DT.
[    0.000000] psci: PSCIv1.0 detected in firmware.
[    0.000000] psci: Using standard PSCI v0.2 function IDs
[    0.000000] psci: Trusted OS migration not required
[    0.000000] psci: SMC Calling Convention v1.0
[    0.000000] percpu: Embedded 48 pages/cpu s159176 r8192 d29240 u196608
[    0.000000] pcpu-alloc: s159176 r8192 d29240 u196608 alloc=48*4096
[    0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0] 4 [0] 5 
[    0.000000] Detected VIPT I-cache on CPU0
[    0.000000] CPU features: detected: ARM erratum 845719
[    0.000000] CPU features: detected: ARM erratum 843419
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 2060288
[    0.000000] Policy zone: Normal
[    0.000000] Kernel command line: ttyAMA0,115200n8 root=/dev/nfs rw verbose debug ip=dhcp nfsroot=xx.xx.xx.xx:/mnt/data/exports/juno,vers=4,tcp nfsrootdebug rootwait earlycon=pl011,0x7ff80000 systemd.log_target=null user_debug=31 androidboot.hardware=juno loglevel=9 bootargs_sky2=sky2.mac_address=0x00,0x02,0xf7,0x00,0x67,0xbe
[    0.000000] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes, linear)
[    0.000000] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes, linear)
[    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[    0.000000] software IO TLB: mapped [mem 0xbbfff000-0xbffff000] (64MB)
[    0.000000] Memory: 8044448K/8372224K available (25724K kernel code, 4126K rwdata, 12236K rodata, 14656K init, 11192K bss, 295008K reserved, 32768K cma-reserved)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=6, Nodes=1
[    0.000000] ftrace: allocating 77609 entries in 304 pages
[    0.000000] ftrace: allocated 304 pages with 3 groups
[    0.000000] Running RCU self tests
[    0.000000] rcu: Preemptible hierarchical RCU implementation.
[    0.000000] rcu: 	RCU lockdep checking is enabled.
[    0.000000] rcu: 	RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=6.
[    0.000000] 	Tasks RCU enabled.
[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
[    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=6
[    0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
[    0.000000] GIC: Using split EOI/Deactivate mode
[    0.000000] GICv2m: range[mem 0x2c1c0000-0x2c1cffff], SPI[224:255]
[    0.000000] GICv2m: range[mem 0x2c1d0000-0x2c1dffff], SPI[256:287]
[    0.000000] GICv2m: range[mem 0x2c1e0000-0x2c1effff], SPI[288:319]
[    0.000000] GICv2m: range[mem 0x2c1f0000-0x2c1fffff], SPI[320:351]
[    0.000000] random: get_random_bytes called from start_kernel+0x5d8/0x784 with crng_init=0
[    0.000000] clocksource: arm,sp804: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275 ns
[    0.000007] sched_clock: 32 bits at 1000kHz, resolution 1000ns, wraps every 2147483647500ns
[    0.008559] Failed to initialize '/smb@8000000/motherboard/iofpga@3,00000000/timer@120000': -22
[    0.018104] arch_timer: cp15 and mmio timer(s) running at 50.00MHz (phys/phys).
[    0.025447] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0xb8812736b, max_idle_ns: 440795202655 ns
[    0.036277] sched_clock: 56 bits at 50MHz, resolution 20ns, wraps every 4398046511100ns
[    0.045514] Console: colour dummy device 80x25
[    0.050047] printk: console [tty0] enabled
[    0.054294] printk: bootconsole [pl11] disabled
[    0.058987] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
[    0.059154] ... MAX_LOCKDEP_SUBCLASSES:  8
[    0.059254] ... MAX_LOCK_DEPTH:          48
[    0.059355] ... MAX_LOCKDEP_KEYS:        8192
[    0.059460] ... CLASSHASH_SIZE:          4096
[    0.059565] ... MAX_LOCKDEP_ENTRIES:     32768
[    0.059672] ... MAX_LOCKDEP_CHAINS:      65536
[    0.059777] ... CHAINHASH_SIZE:          32768
[    0.059883]  memory used by lock dependency info: 6237 kB
[    0.060005]  memory used for stack traces: 4224 kB
[    0.060117]  per task-struct memory footprint: 1920 bytes
[    0.060239] ------------------------
[    0.060330] | Locking API testsuite:
[    0.060421] ----------------------------------------------------------------------------
[    0.060593]                                  | spin |wlock |rlock |mutex | wsem | rsem |
[    0.060764]   --------------------------------------------------------------------------
[    0.060943]                      A-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[    0.079471]                  A-B-B-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[    0.099610]              A-B-B-C-C-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[    0.121456]              A-B-C-A-B-C deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[    0.143259]          A-B-B-C-C-D-D-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[    0.166767]          A-B-C-D-B-D-D-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[    0.190249]          A-B-C-D-B-C-D-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[    0.213763]                     double unlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[    0.232219]                   initialize held:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[    0.250044]   --------------------------------------------------------------------------
[    0.250214]               recursive read-lock:             |  ok  |             |  ok  |
[    0.255845]            recursive read-lock #2:             |  ok  |             |  ok  |
[    0.261257]             mixed read-write-lock:             |  ok  |             |  ok  |
[    0.266678]             mixed write-read-lock:             |  ok  |             |  ok  |
[    0.272102]   mixed read-lock/lock-write ABBA:             |FAILED|             |  ok  |
[    0.277826]    mixed read-lock/lock-read ABBA:             |  ok  |             |  ok  |
[    0.283714]  mixed write-lock/lock-write ABBA:             |  ok  |             |  ok  |
[    0.289603]   --------------------------------------------------------------------------
[    0.289934]      hard-irqs-on + irq-safe-A/12:  ok  |  ok  |  ok  |
[    0.297909]      soft-irqs-on + irq-safe-A/12:  ok  |  ok  |  ok  |
[    0.305930]      hard-irqs-on + irq-safe-A/21:  ok  |  ok  |  ok  |
[    0.313903]      soft-irqs-on + irq-safe-A/21:  ok  |  ok  |  ok  |
[    0.321911]        sirq-safe-A => hirqs-on/12:  ok  |  ok  |  ok  |
[    0.329897]        sirq-safe-A => hirqs-on/21:  ok  |  ok  |  ok  |
[    0.337919]          hard-safe-A + irqs-on/12:  ok  |  ok  |  ok  |
[    0.345890]          soft-safe-A + irqs-on/12:  ok  |  ok  |  ok  |
[    0.353910]          hard-safe-A + irqs-on/21:  ok  |  ok  |  ok  |
[    0.361883]          soft-safe-A + irqs-on/21:  ok  |  ok  |  ok  |
[    0.369892]     hard-safe-A + unsafe-B #1/123:  ok  |  ok  |  ok  |
[    0.378560]     soft-safe-A + unsafe-B #1/123:  ok  |  ok  |  ok  |
[    0.387282]     hard-safe-A + unsafe-B #1/132:  ok  |  ok  |  ok  |
[    0.395952]     soft-safe-A + unsafe-B #1/132:  ok  |  ok  |  ok  |
[    0.404671]     hard-safe-A + unsafe-B #1/213:  ok  |  ok  |  ok  |
[    0.413340]     soft-safe-A + unsafe-B #1/213:  ok  |  ok  |  ok  |
[    0.422052]     hard-safe-A + unsafe-B #1/231:  ok  |  ok  |  ok  |
[    0.430701]     soft-safe-A + unsafe-B #1/231:  ok  |  ok  |  ok  |
[    0.439410]     hard-safe-A + unsafe-B #1/312:  ok  |  ok  |  ok  |
[    0.447609]     soft-safe-A + unsafe-B #1/312:  ok  |  ok  |  ok  |
[    0.455852]     hard-safe-A + unsafe-B #1/321:  ok  |  ok  |  ok  |
[    0.464512]     soft-safe-A + unsafe-B #1/321:  ok  |  ok  |  ok  |
[    0.473223]     hard-safe-A + unsafe-B #2/123:  ok  |  ok  |  ok  |
[    0.481908]     soft-safe-A + unsafe-B #2/123:  ok  |  ok  |  ok  |
[    0.490625]     hard-safe-A + unsafe-B #2/132:  ok  |  ok  |  ok  |
[    0.499298]     soft-safe-A + unsafe-B #2/132:  ok  |  ok  |  ok  |
[    0.508019]     hard-safe-A + unsafe-B #2/213:  ok  |  ok  |  ok  |
[    0.516684]     soft-safe-A + unsafe-B #2/213:  ok  |  ok  |  ok  |
[    0.525407]     hard-safe-A + unsafe-B #2/231:  ok  |  ok  |  ok  |
[    0.534083]     soft-safe-A + unsafe-B #2/231:  ok  |  ok  |  ok  |
[    0.542794]     hard-safe-A + unsafe-B #2/312:  ok  |  ok  |  ok  |
[    0.551452]     soft-safe-A + unsafe-B #2/312:  ok  |  ok  |  ok  |
[    0.560171]     hard-safe-A + unsafe-B #2/321:  ok  |  ok  |  ok  |
[    0.568833]     soft-safe-A + unsafe-B #2/321:  ok  |  ok  |  ok  |
[    0.577549]       hard-irq lock-inversion/123:  ok  |  ok  |  ok  |
[    0.586217]       soft-irq lock-inversion/123:  ok  |  ok  |  ok  |
[    0.594934]       hard-irq lock-inversion/132:  ok  |  ok  |  ok  |
[    0.603596]       soft-irq lock-inversion/132:  ok  |  ok  |  ok  |
[    0.612318]       hard-irq lock-inversion/213:  ok  |  ok  |  ok  |
[    0.620989]       soft-irq lock-inversion/213:  ok  |  ok  |  ok  |
[    0.629708]       hard-irq lock-inversion/231:  ok  |  ok  |  ok  |
[    0.638374]       soft-irq lock-inversion/231:  ok  |  ok  |  ok  |
[    0.647089]       hard-irq lock-inversion/312:  ok  |  ok  |  ok  |
[    0.655746]       soft-irq lock-inversion/312:  ok  |  ok  |  ok  |
[    0.664467]       hard-irq lock-inversion/321:  ok  |  ok  |  ok  |
[    0.673130]       soft-irq lock-inversion/321:  ok  |  ok  |  ok  |
[    0.681851]       hard-irq read-recursion/123:  ok  |
[    0.684808]       soft-irq read-recursion/123:  ok  |
[    0.687809]       hard-irq read-recursion/132:  ok  |
[    0.690765]       soft-irq read-recursion/132:  ok  |
[    0.693770]       hard-irq read-recursion/213:  ok  |
[    0.696726]       soft-irq read-recursion/213:  ok  |
[    0.699730]       hard-irq read-recursion/231:  ok  |
[    0.702687]       soft-irq read-recursion/231:  ok  |
[    0.705688]       hard-irq read-recursion/312:  ok  |
[    0.708645]       soft-irq read-recursion/312:  ok  |
[    0.711647]       hard-irq read-recursion/321:  ok  |
[    0.714602]       soft-irq read-recursion/321:  ok  |
[    0.717604]   --------------------------------------------------------------------------
[    0.717772]   | Wound/wait tests |
[    0.717859]   ---------------------
[    0.717947]                   ww api failures:  ok  |  ok  |  ok  |
[    0.726453]                ww contexts mixing:  ok  |  ok  |
[    0.732068]              finishing ww context:  ok  |  ok  |  ok  |  ok  |
[    0.743151]                locking mismatches:  ok  |  ok  |  ok  |
[    0.751623]                  EDEADLK handling:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[    0.780528]            spinlock nest unlocked:  ok  |
[    0.783253]   -----------------------------------------------------
[    0.783387]                                  |block | try  |context|
[    0.783524]   -----------------------------------------------------
[    0.783658]                           context:  ok  |  ok  |  ok  |
[    0.792394]                               try:  ok  |  ok  |  ok  |
[    0.800608]                             block:  ok  |  ok  |  ok  |
[    0.808862]                          spinlock:  ok  |  ok  |  ok  |
[    0.817795] -------------------------------------------------------
[    0.817931] Good, all 261 testcases passed! |
[    0.818034] ---------------------------------
[    0.818373] Calibrating delay loop (skipped), value calculated using timer frequency.. 100.00 BogoMIPS (lpj=200000)
[    0.818650] pid_max: default: 32768 minimum: 301
[    0.819122] LSM: Security Framework initializing
[    0.819426] Mount-cache hash table entries: 16384 (order: 5, 131072 bytes, linear)
[    0.819632] Mountpoint-cache hash table entries: 16384 (order: 5, 131072 bytes, linear)
[    0.855086] rcu: Hierarchical SRCU implementation.
[    0.872249] EFI services will not be available.
[    0.879375] smp: Bringing up secondary CPUs ...
[    0.925462] CPU features: detected: EL2 vector hardening
[    0.925475] ARM_SMCCC_ARCH_WORKAROUND_1 missing from firmware
[    0.925482] CPU features: detected: ARM erratum 1319367
[    0.925489] Detected PIPT I-cache on CPU1
[    0.925551] CPU1: Booted secondary processor 0x0000000000 [0x410fd080]
[    0.969765] Detected PIPT I-cache on CPU2
[    0.969800] CPU2: Booted secondary processor 0x0000000001 [0x410fd080]
[    1.014206] Detected VIPT I-cache on CPU3
[    1.014278] CPU3: Booted secondary processor 0x0000000101 [0x410fd033]
[    1.058602] Detected VIPT I-cache on CPU4
[    1.058660] CPU4: Booted secondary processor 0x0000000102 [0x410fd033]
[    1.103026] Detected VIPT I-cache on CPU5
[    1.103083] CPU5: Booted secondary processor 0x0000000103 [0x410fd033]
[    1.103707] smp: Brought up 1 node, 6 CPUs
[    1.105347] SMP: Total of 6 processors activated.
[    1.105567] CPU features: detected: 32-bit EL0 Support
[    1.105703] CPU features: detected: CRC32 instructions
[    1.168589] CPU: All CPU(s) started at EL2
[    1.168851] alternatives: patching kernel code
[    1.173882] devtmpfs: initialized
[    1.193809] KASLR disabled due to lack of seed
[    1.195961] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[    1.196083] futex hash table entries: 2048 (order: 6, 262144 bytes, linear)
[    1.197646] xor: measuring software checksum speed
[    1.234611]    8regs     :  4238.000 MB/sec
[    1.274820]    32regs    :  4763.000 MB/sec
[    1.315072]    arm64_neon:  4290.000 MB/sec
[    1.315126] xor: using function: 32regs (4763.000 MB/sec)
[    1.315194] pinctrl core: initialized pinctrl subsystem
[    1.317944] thermal_sys: Registered thermal governor 'step_wise'
[    1.317950] thermal_sys: Registered thermal governor 'power_allocator'
[    1.319665] DMI not present or invalid.
[    1.320924] NET: Registered protocol family 16
[    1.325042] DMA: preallocated 256 KiB pool for atomic allocations
[    1.325127] audit: initializing netlink subsys (disabled)
[    1.325663] audit: type=2000 audit(1.044:1): state=initialized audit_enabled=0 res=1
[    1.327747] cpuidle: using governor menu
[    1.328011] NET: Registered protocol family 42
[    1.328608] hw-breakpoint: found 6 breakpoint and 4 watchpoint registers.
[    1.329105] ASID allocator initialised with 65536 entries
[    1.331101] Serial: AMBA PL011 UART driver
[    1.360865] 7ff80000.uart: ttyAMA0 at MMIO 0x7ff80000 (irq = 31, base_baud = 0) is a PL011 rev3
[    2.798063] printk: console [ttyAMA0] enabled
[    2.869683] HugeTLB registered 1.00 GiB page size, pre-allocated 0 pages
[    2.876629] HugeTLB registered 32.0 MiB page size, pre-allocated 0 pages
[    2.883447] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages
[    2.890254] HugeTLB registered 64.0 KiB page size, pre-allocated 0 pages
[    2.923328] cryptd: max_cpu_qlen set to 1000
[    3.021904] raid6: neonx8   gen()  3081 MB/s
[    3.094355] raid6: neonx8   xor()  2156 MB/s
[    3.166859] raid6: neonx4   gen()  3067 MB/s
[    3.239275] raid6: neonx4   xor()  2275 MB/s
[    3.311745] raid6: neonx2   gen()  2656 MB/s
[    3.384186] raid6: neonx2   xor()  2059 MB/s
[    3.456655] raid6: neonx1   gen()  1971 MB/s
[    3.529101] raid6: neonx1   xor()  1619 MB/s
[    3.601566] raid6: int64x8  gen()  1555 MB/s
[    3.674013] raid6: int64x8  xor()   899 MB/s
[    3.746476] raid6: int64x4  gen()  1790 MB/s
[    3.818913] raid6: int64x4  xor()   971 MB/s
[    3.891357] raid6: int64x2  gen()  1592 MB/s
[    3.963815] raid6: int64x2  xor()   846 MB/s
[    4.036263] raid6: int64x1  gen()  1224 MB/s
[    4.108748] raid6: int64x1  xor()   639 MB/s
[    4.113097] raid6: using algorithm neonx8 gen() 3081 MB/s
[    4.118582] raid6: .... xor() 2156 MB/s, rmw enabled
[    4.123628] raid6: using neon recovery algorithm
[    4.129187] ACPI: Interpreter disabled.
[    4.135980] iommu: Default domain type: Translated 
[    4.141597] vgaarb: loaded
[    4.145349] SCSI subsystem initialized
[    4.149692] libata version 3.00 loaded.
[    4.154219] usbcore: registered new interface driver usbfs
[    4.159916] usbcore: registered new interface driver hub
[    4.165517] usbcore: registered new device driver usb
[    4.173528] mc: Linux media interface: v0.10
[    4.177949] videodev: Linux video capture interface: v2.00
[    4.183789] pps_core: LinuxPPS API ver. 1 registered
[    4.188842] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    4.198139] PTP clock support registered
[    4.202924] EDAC MC: Ver: 3.0.0
[    4.208900] FPGA manager framework
[    4.212863] Advanced Linux Sound Architecture Driver Initialized.
[    4.220442] Bluetooth: Core ver 2.22
[    4.224164] NET: Registered protocol family 31
[    4.228690] Bluetooth: HCI device and connection manager initialized
[    4.235176] Bluetooth: HCI socket layer initialized
[    4.240150] Bluetooth: L2CAP socket layer initialized
[    4.245346] Bluetooth: SCO socket layer initialized
[    4.251847] clocksource: Switched to clocksource arch_sys_counter
[    5.094664] VFS: Disk quotas dquot_6.6.0
[    5.098862] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    5.106585] pnp: PnP ACPI: disabled
[    5.129217] NET: Registered protocol family 2
[    5.134547] tcp_listen_portaddr_hash hash table entries: 4096 (order: 6, 294912 bytes, linear)
[    5.144017] TCP established hash table entries: 65536 (order: 7, 524288 bytes, linear)
[    5.152363] TCP bind hash table entries: 65536 (order: 10, 4194304 bytes, linear)
[    5.170770] TCP: Hash tables configured (established 65536 bind 65536)
[    5.177861] UDP hash table entries: 4096 (order: 7, 655360 bytes, linear)
[    5.186272] UDP-Lite hash table entries: 4096 (order: 7, 655360 bytes, linear)
[    5.195315] NET: Registered protocol family 1
[    5.201490] RPC: Registered named UNIX socket transport module.
[    5.207660] RPC: Registered udp transport module.
[    5.212485] RPC: Registered tcp transport module.
[    5.217296] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    5.224881] PCI: CLS 0 bytes, default 64
[    6.578984] hw perfevents: enabled with armv8_cortex_a72 PMU driver, 7 counters available
[    6.589062] hw perfevents: enabled with armv8_cortex_a53 PMU driver, 7 counters available
[    6.597532] kvm [1]: IPA Size Limit: 40bits
[    6.610626] kvm [1]: vgic interrupt IRQ1
[    6.615204] kvm [1]: Hyp mode initialized successfully
[    7.077112] rcu-torture:--- Start of test: nreaders=5 nfakewriters=4 stat_interval=60 verbose=1 test_no_idle_hz=1 shuffle_interval=3 stutter=5 irqreader=1 fqs_duration=0 fqs_holdoff=0 fqs_stutter=3 test_boost=1/0 test_boost_interval=7 test_boost_duration=4 shutdown_secs=0 stall_cpu=0 stall_cpu_holdoff=10 stall_cpu_irqsoff=0 n_barrier_cbs=0 onoff_interval=0 onoff_holdoff=0
[    7.110494] rcu-torture: Creating rcu_torture_writer task
[    7.116379] rcu-torture: Creating rcu_torture_fakewriter task
[    7.116385] rcu-torture: rcu_torture_writer task started
[    7.122491] rcu-torture: Creating rcu_torture_fakewriter task
[    7.122522] rcu-torture: rcu_torture_fakewriter task started
[    7.128171] rcu-torture: GP expediting controlled from boot/sysfs for rcu.
[    7.133916] rcu-torture: Creating rcu_torture_fakewriter task
[    7.133945] rcu-torture: rcu_torture_fakewriter task started
[    7.139582] rcu_torture_writer: Testing conditional GPs.
[    7.146788] rcu-torture: Creating rcu_torture_fakewriter task
[    7.146817] rcu-torture: rcu_torture_fakewriter task started
[    7.155874] rcu_torture_writer: Testing expedited GPs.
[    7.158579] rcu-torture: Creating rcu_torture_reader task
[    7.158607] rcu-torture: rcu_torture_fakewriter task started
[    7.163675] rcu_torture_writer: Testing asynchronous GPs.
[    7.169749] rcu-torture: Creating rcu_torture_reader task
[    7.169782] rcu-torture: rcu_torture_reader task started
[    7.175265] rcu_torture_writer: Testing normal GPs.
[    7.213385] rcu-torture: Creating rcu_torture_reader task
[    7.213443] rcu-torture: rcu_torture_reader task started
[    7.219139] rcu-torture: Creating rcu_torture_reader task
[    7.219168] rcu-torture: rcu_torture_reader task started
[    7.235646] rcu-torture: Creating rcu_torture_reader task
[    7.235684] rcu-torture: rcu_torture_reader task started
[    7.241392] rcu-torture: Creating rcu_torture_stats task
[    7.241397] rcu-torture: rcu_torture_reader task started
[    7.257785] rcu-torture: Creating torture_shuffle task
[    7.263087] rcu-torture: rcu_torture_stats task started
[    7.268826] rcu-torture: Creating torture_stutter task
[    7.268858] rcu-torture: torture_shuffle task started
[    7.274329] rcu-torture: Creating rcu_torture_fwd_prog task
[    7.274355] rcu-torture: torture_stutter task started
[    7.290466] rcu-torture: rcu_torture_fwd_progress task started
[    7.293479] Initialise system trusted keyrings
[    7.301423] workingset: timestamp_bits=44 max_order=21 bucket_order=0
[    7.336884] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    7.349427] NFS: Registering the id_resolver key type
[    7.354642] Key type id_resolver registered
[    7.358937] Key type id_legacy registered
[    7.363047] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[    7.370267] fuse: init (API version 7.31)
[    7.375772] 9p: Installing v9fs 9p2000 file system support
[    7.404730] Key type asymmetric registered
[    7.408986] Asymmetric key parser 'x509' registered
[    7.414040] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 243)
[    7.421582] io scheduler mq-deadline registered
[    7.426202] io scheduler kyber registered
[    7.445797] pl061_gpio 1c1d0000.gpio: PL061 GPIO chip registered
[    7.455590] pci-host-generic 40000000.pcie: host bridge /pcie@40000000 ranges:
[    7.462988] pci-host-generic 40000000.pcie:       IO 0x005f800000..0x005fffffff -> 0x0000000000
[    7.471956] pci-host-generic 40000000.pcie:      MEM 0x0050000000..0x0057ffffff -> 0x0050000000
[    7.480842] pci-host-generic 40000000.pcie:      MEM 0x4000000000..0x40ffffffff -> 0x4000000000
[    7.489788] pci-host-generic 40000000.pcie: ECAM at [mem 0x40000000-0x4fffffff] for [bus 00-ff]
[    7.498975] pci-host-generic 40000000.pcie: PCI host bridge to bus 0000:00
[    7.505978] pci_bus 0000:00: root bus resource [bus 00-ff]
[    7.511570] pci_bus 0000:00: root bus resource [io  0x0000-0x7fffff]
[    7.518038] pci_bus 0000:00: root bus resource [mem 0x50000000-0x57ffffff]
[    7.525038] pci_bus 0000:00: root bus resource [mem 0x4000000000-0x40ffffffff pref]
[    7.532922] pci 0000:00:00.0: [1556:1100] type 01 class 0x060400
[    7.539090] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x00003fff 64bit pref]
[    7.546617] pci 0000:00:00.0: supports D1 D2
[    7.550978] pci 0000:00:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[    7.559711] pci 0000:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[    7.568127] pci 0000:01:00.0: [111d:8090] type 01 class 0x060400
[    7.574387] pci 0000:01:00.0: enabling Extended Tags
[    7.579627] pci 0000:01:00.0: PME# supported from D0 D3hot D3cold
[    7.597244] pci 0000:01:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[    7.605766] pci 0000:02:01.0: [111d:8090] type 01 class 0x060400
[    7.612042] pci 0000:02:01.0: enabling Extended Tags
[    7.617316] pci 0000:02:01.0: PME# supported from D0 D3hot D3cold
[    7.624195] pci 0000:02:02.0: [111d:8090] type 01 class 0x060400
[    7.630469] pci 0000:02:02.0: enabling Extended Tags
[    7.635741] pci 0000:02:02.0: PME# supported from D0 D3hot D3cold
[    7.642575] pci 0000:02:03.0: [111d:8090] type 01 class 0x060400
[    7.648842] pci 0000:02:03.0: enabling Extended Tags
[    7.654113] pci 0000:02:03.0: PME# supported from D0 D3hot D3cold
[    7.661293] pci 0000:02:0c.0: [111d:8090] type 01 class 0x060400
[    7.667561] pci 0000:02:0c.0: enabling Extended Tags
[    7.672832] pci 0000:02:0c.0: PME# supported from D0 D3hot D3cold
[    7.679795] pci 0000:02:10.0: [111d:8090] type 01 class 0x060400
[    7.686056] pci 0000:02:10.0: enabling Extended Tags
[    7.691318] pci 0000:02:10.0: PME# supported from D0 D3hot D3cold
[    7.698753] pci 0000:02:1f.0: [111d:8090] type 01 class 0x060400
[    7.705021] pci 0000:02:1f.0: enabling Extended Tags
[    7.710291] pci 0000:02:1f.0: PME# supported from D0 D3hot D3cold
[    7.717084] pci 0000:02:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[    7.725252] pci 0000:02:02.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[    7.733413] pci 0000:02:03.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[    7.741593] pci 0000:02:0c.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[    7.749753] pci 0000:02:10.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[    7.757907] pci 0000:02:1f.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[    7.766363] pci 0000:03:00.0: [1095:3132] type 00 class 0x018000
[    7.772551] pci 0000:03:00.0: reg 0x10: [mem 0x00000000-0x0000007f 64bit]
[    7.779489] pci 0000:03:00.0: reg 0x18: [mem 0x00000000-0x00003fff 64bit]
[    7.786411] pci 0000:03:00.0: reg 0x20: [io  0x0000-0x007f]
[    7.792122] pci 0000:03:00.0: reg 0x30: [mem 0x00000000-0x0007ffff pref]
[    7.799106] pci 0000:03:00.0: supports D1 D2
[    7.803984] pci 0000:03:00.0: disabling ASPM on pre-1.1 PCIe device.  You can enable it with 'pcie_aspm=force'
[    7.815450] pci_bus 0000:03: busn_res: [bus 03-ff] end is updated to 03
[    7.823713] pci_bus 0000:04: busn_res: [bus 04-ff] end is updated to 04
[    7.832011] pci_bus 0000:05: busn_res: [bus 05-ff] end is updated to 05
[    7.840311] pci_bus 0000:06: busn_res: [bus 06-ff] end is updated to 06
[    7.848601] pci_bus 0000:07: busn_res: [bus 07-ff] end is updated to 07
[    7.855662] pci 0000:08:00.0: [11ab:4380] type 00 class 0x020000
[    7.861847] pci 0000:08:00.0: reg 0x10: [mem 0x00000000-0x00003fff 64bit]
[    7.868769] pci 0000:08:00.0: reg 0x18: [io  0x0000-0x00ff]
[    7.874684] pci 0000:08:00.0: supports D1 D2
[    7.879043] pci 0000:08:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[    7.887739] pci_bus 0000:08: busn_res: [bus 08-ff] end is updated to 08
[    7.894481] pci_bus 0000:02: busn_res: [bus 02-ff] end is updated to 08
[    7.901219] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 08
[    7.907976] pci 0000:00:00.0: BAR 14: assigned [mem 0x50000000-0x501fffff]
[    7.914978] pci 0000:00:00.0: BAR 0: assigned [mem 0x4000000000-0x4000003fff 64bit pref]
[    7.923243] pci 0000:00:00.0: BAR 13: assigned [io  0x1000-0x2fff]
[    7.929548] pci 0000:01:00.0: BAR 14: assigned [mem 0x50000000-0x501fffff]
[    7.936542] pci 0000:01:00.0: BAR 13: assigned [io  0x1000-0x2fff]
[    7.942844] pci 0000:02:01.0: BAR 14: assigned [mem 0x50000000-0x500fffff]
[    7.949838] pci 0000:02:1f.0: BAR 14: assigned [mem 0x50100000-0x501fffff]
[    7.956830] pci 0000:02:01.0: BAR 13: assigned [io  0x1000-0x1fff]
[    7.963120] pci 0000:02:1f.0: BAR 13: assigned [io  0x2000-0x2fff]
[    7.969424] pci 0000:03:00.0: BAR 6: assigned [mem 0x50000000-0x5007ffff pref]
[    7.976773] pci 0000:03:00.0: BAR 2: assigned [mem 0x50080000-0x50083fff 64bit]
[    7.984244] pci 0000:03:00.0: BAR 0: assigned [mem 0x50084000-0x5008407f 64bit]
[    7.991702] pci 0000:03:00.0: BAR 4: assigned [io  0x1000-0x107f]
[    7.997917] pci 0000:02:01.0: PCI bridge to [bus 03]
[    8.002980] pci 0000:02:01.0:   bridge window [io  0x1000-0x1fff]
[    8.009191] pci 0000:02:01.0:   bridge window [mem 0x50000000-0x500fffff]
[    8.016115] pci 0000:02:02.0: PCI bridge to [bus 04]
[    8.021208] pci 0000:02:03.0: PCI bridge to [bus 05]
[    8.026305] pci 0000:02:0c.0: PCI bridge to [bus 06]
[    8.031418] pci 0000:02:10.0: PCI bridge to [bus 07]
[    8.036523] pci 0000:08:00.0: BAR 0: assigned [mem 0x50100000-0x50103fff 64bit]
[    8.043981] pci 0000:08:00.0: BAR 2: assigned [io  0x2000-0x20ff]
[    8.050190] pci 0000:02:1f.0: PCI bridge to [bus 08]
[    8.055258] pci 0000:02:1f.0:   bridge window [io  0x2000-0x2fff]
[    8.061477] pci 0000:02:1f.0:   bridge window [mem 0x50100000-0x501fffff]
[    8.068407] pci 0000:01:00.0: PCI bridge to [bus 02-08]
[    8.073732] pci 0000:01:00.0:   bridge window [io  0x1000-0x2fff]
[    8.079944] pci 0000:01:00.0:   bridge window [mem 0x50000000-0x501fffff]
[    8.086873] pci 0000:00:00.0: PCI bridge to [bus 01-08]
[    8.092201] pci 0000:00:00.0:   bridge window [io  0x1000-0x2fff]
[    8.098407] pci 0000:00:00.0:   bridge window [mem 0x50000000-0x501fffff]
[    8.105743] pcieport 0000:00:00.0: enabling device (0000 -> 0003)
[    8.120032] pcieport 0000:00:00.0: PME: Signaling with IRQ 44
[    8.126997] pcieport 0000:00:00.0: AER: enabled with IRQ 44
[    8.133261] pcieport 0000:01:00.0: enabling device (0000 -> 0003)
[    8.139707] pcieport 0000:02:01.0: enabling device (0000 -> 0003)
[    8.150518] pcieport 0000:02:1f.0: enabling device (0000 -> 0003)
[    8.160458] IPMI message handler: version 39.2
[    8.165174] ipmi device interface
[    8.168698] ipmi_si: IPMI System Interface driver
[    8.174132] ipmi_si: Unable to find any System Interface(s)
[    8.181111] EINJ: ACPI disabled.
[    8.193706] dma-pl330 7ff00000.dma: WARN: Device release is not defined so it is not safe to unbind this driver while in use
[    8.206494] dma-pl330 7ff00000.dma: Loaded driver for PL330 DMAC-341330
[    8.213230] dma-pl330 7ff00000.dma: 	DBUFF-1024x16bytes Num_Chans-8 Num_Peri-8 Num_Events-8
[    8.237794] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    8.249476] SuperH (H)SCI(F) driver initialized
[    8.254765] msm_serial: driver initialized
[    8.262532] arm-smmu 7fb10000.iommu: probing hardware configuration...
[    8.269207] arm-smmu 7fb10000.iommu: SMMUv1 with:
[    8.274005] arm-smmu 7fb10000.iommu: 	stage 2 translation
[    8.279509] arm-smmu 7fb10000.iommu: 	non-coherent table walk
[    8.285365] arm-smmu 7fb10000.iommu: 	(IDR0.CTTW overridden by FW configuration)
[    8.292894] arm-smmu 7fb10000.iommu: 	stream matching with 2 register groups
[    8.300072] arm-smmu 7fb10000.iommu: 	1 context banks (1 stage-2 only)
[    8.306717] arm-smmu 7fb10000.iommu: 	Supported page sizes: 0x60211000
[    8.313357] arm-smmu 7fb10000.iommu: 	Stage-2: 40-bit IPA -> 40-bit PA
[    8.320927] arm-smmu 7fb20000.iommu: probing hardware configuration...
[    8.327578] arm-smmu 7fb20000.iommu: SMMUv1 with:
[    8.332379] arm-smmu 7fb20000.iommu: 	stage 2 translation
[    8.337882] arm-smmu 7fb20000.iommu: 	non-coherent table walk
[    8.343734] arm-smmu 7fb20000.iommu: 	(IDR0.CTTW overridden by FW configuration)
[    8.351262] arm-smmu 7fb20000.iommu: 	stream matching with 2 register groups
[    8.358439] arm-smmu 7fb20000.iommu: 	1 context banks (1 stage-2 only)
[    8.365088] arm-smmu 7fb20000.iommu: 	Supported page sizes: 0x60211000
[    8.371733] arm-smmu 7fb20000.iommu: 	Stage-2: 40-bit IPA -> 40-bit PA
[    8.378889] arm-smmu 7fb30000.iommu: probing hardware configuration...
[    8.385544] arm-smmu 7fb30000.iommu: SMMUv1 with:
[    8.390347] arm-smmu 7fb30000.iommu: 	stage 2 translation
[    8.395849] arm-smmu 7fb30000.iommu: 	coherent table walk
[    8.401352] arm-smmu 7fb30000.iommu: 	stream matching with 2 register groups
[    8.408523] arm-smmu 7fb30000.iommu: 	1 context banks (1 stage-2 only)
[    8.415173] arm-smmu 7fb30000.iommu: 	Supported page sizes: 0x60211000
[    8.421817] arm-smmu 7fb30000.iommu: 	Stage-2: 40-bit IPA -> 40-bit PA
[    8.563772] tda998x 0-0070: found TDA19988
[    8.696060] tda998x 0-0071: found TDA19988
[    8.766216] loop: module loaded
[    8.893170] mpt3sas version 33.100.00.00 loaded
[    8.903315] sata_sil24 0000:03:00.0: version 1.1
[    8.908345] sata_sil24 0000:03:00.0: enabling device (0000 -> 0003)
[    8.918391] scsi host0: sata_sil24
[    8.923496] scsi host1: sata_sil24
[    8.927499] ata1: SATA max UDMA/100 host m128@0x50084000 port 0x50080000 irq 51
[    8.934940] ata2: SATA max UDMA/100 host m128@0x50084000 port 0x50082000 irq 51
[    8.950044] libphy: Fixed MDIO Bus: probed
[    8.956437] tun: Universal TUN/TAP device driver, 1.6
[    8.962964] bnx2x: QLogic 5771x/578xx 10/20-Gigabit Ethernet Driver bnx2x 1.713.36-0 (2014/02/10)
[    8.972980] thunder_xcv, ver 1.0
[    8.976426] thunder_bgx, ver 1.0
[    8.979813] nicpf, ver 1.0
[    8.983449] hclge is initializing
[    8.987220] hns3: Hisilicon Ethernet Network Driver for Hip08 Family - version
[    8.994608] hns3: Copyright (c) 2017 Huawei Corporation.
[    9.000181] e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k
[    9.006119] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
[    9.012273] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.6.0-k
[    9.019349] igb: Copyright (c) 2007-2014 Intel Corporation.
[    9.025142] igbvf: Intel(R) Gigabit Virtual Function Network Driver - version 2.4.0-k
[    9.033096] igbvf: Copyright (c) 2009 - 2012 Intel Corporation.
[    9.039878] sky2: driver version 1.30
[    9.043915] sky2 0000:08:00.0: enabling device (0000 -> 0003)
[    9.049850] sky2 0000:08:00.0: Yukon-2 UL 2 chip revision 0
[    9.055639] sky2 0000:08:00.0 (unnamed net_device) (uninitialized): Invalid MAC address, defaulting to random
[    9.067331] sky2 0000:08:00.0 eth0: addr ae:19:c6:f0:10:e2
[    9.110208] libphy: smsc911x-mdio: probed
[    9.115328] smsc911x 18000000.ethernet eth1: MAC Address: 00:02:f7:00:67:bd
[    9.125648] pegasus: v0.9.3 (2013/04/25), Pegasus/Pegasus II USB Ethernet driver
[    9.133322] usbcore: registered new interface driver pegasus
[    9.139170] usbcore: registered new interface driver rtl8150
[    9.145034] usbcore: registered new interface driver r8152
[    9.150697] usbcore: registered new interface driver lan78xx
[    9.156568] usbcore: registered new interface driver asix
[    9.162135] usbcore: registered new interface driver ax88179_178a
[    9.168409] usbcore: registered new interface driver cdc_ether
[    9.174408] usbcore: registered new interface driver dm9601
[    9.180169] usbcore: registered new interface driver CoreChips
[    9.186202] usbcore: registered new interface driver smsc75xx
[    9.192194] usbcore: registered new interface driver smsc95xx
[    9.198107] usbcore: registered new interface driver net1080
[    9.203931] usbcore: registered new interface driver plusb
[    9.209590] usbcore: registered new interface driver cdc_subset
[    9.215686] usbcore: registered new interface driver zaurus
[    9.221421] usbcore: registered new interface driver MOSCHIP usb-ethernet driver
[    9.229036] usbcore: registered new interface driver cdc_ncm
[    9.235198] VFIO - User Level meta-driver version: 0.3
[    9.244049] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    9.250734] ehci-pci: EHCI PCI platform driver
[    9.255373] ehci-platform: EHCI generic platform driver
[    9.261265] ehci-platform 7ffc0000.ehci: Adding to iommu group 0
[    9.267943] ehci-platform 7ffc0000.ehci: EHCI Host Controller
[    9.273960] ehci-platform 7ffc0000.ehci: new USB bus registered, assigned bus number 1
[    9.282413] ehci-platform 7ffc0000.ehci: irq 34, io mem 0x7ffc0000
[    9.303894] ehci-platform 7ffc0000.ehci: USB 2.0 started, EHCI 1.00
[    9.312750] hub 1-0:1.0: USB hub found
[    9.316756] hub 1-0:1.0: 1 port detected
[    9.322098] ehci-orion: EHCI orion driver
[    9.326429] ehci-exynos: EHCI Exynos driver
[    9.330880] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    9.337203] ohci-pci: OHCI PCI platform driver
[    9.341844] ohci-platform: OHCI generic platform driver
[    9.347445] ohci-platform 7ffb0000.ohci: Adding to iommu group 0
[    9.353789] ohci-platform 7ffb0000.ohci: Generic Platform OHCI controller
[    9.360733] ohci-platform 7ffb0000.ohci: new USB bus registered, assigned bus number 2
[    9.369041] ohci-platform 7ffb0000.ohci: irq 33, io mem 0x7ffb0000
[    9.454060] hub 2-0:1.0: USB hub found
[    9.458002] hub 2-0:1.0: 1 port detected
[    9.462996] ohci-exynos: OHCI Exynos driver
[    9.468199] usbcore: registered new interface driver usb-storage
[    9.483090] rtc-pl031 1c170000.rtc: registered as rtc0
[    9.489863] i2c /dev entries driver
[    9.498761] usbcore: registered new interface driver uvcvideo
[    9.504616] USB Video Class driver (1.1.1)
[    9.508794] gspca_main: v2.14.0 registered
[    9.519678] sp805-wdt 1c0f0000.wdt: registration successful
[    9.528211] device-mapper: ioctl: 4.42.0-ioctl (2020-02-27) initialised: dm-devel@redhat.com
[    9.536840] Bluetooth: HCI UART driver ver 2.3
[    9.541374] Bluetooth: HCI UART protocol H4 registered
[    9.546654] Bluetooth: HCI UART protocol LL registered
[    9.552062] Bluetooth: HCI UART protocol Broadcom registered
[    9.557942] usbcore: registered new interface driver btusb
[    9.566162] mmci-pl18x 1c050000.mmci: mmc0: PL180 manf 41 rev0 at 0x1c050000 irq 9,0 (pio)
[    9.600728] sdhci: Secure Digital Host Controller Interface driver
[    9.607167] sdhci: Copyright(c) Pierre Ossman
[    9.612329] Synopsys Designware Multimedia Card Interface Driver
[    9.620229] sdhci-pltfm: SDHCI platform and OF driver helper
[    9.629527] leds-syscon 1c010000.apbregs:led0: registered LED vexpress:0
[    9.636858] leds-syscon 1c010000.apbregs:led1: registered LED vexpress:1
[    9.644123] leds-syscon 1c010000.apbregs:led2: registered LED vexpress:2
[    9.651333] leds-syscon 1c010000.apbregs:led3: registered LED vexpress:3
[    9.658549] leds-syscon 1c010000.apbregs:led4: registered LED vexpress:4
[    9.660037] usb 1-1: new high-speed USB device number 2 using ehci-platform
[    9.665756] leds-syscon 1c010000.apbregs:led5: registered LED vexpress:5
[    9.679910] leds-syscon 1c010000.apbregs:led6: registered LED vexpress:6
[    9.687122] leds-syscon 1c010000.apbregs:led7: registered LED vexpress:7
[    9.695039] ledtrig-cpu: registered to indicate activity on CPUs
[    9.704066] hub 1-1:1.0: USB hub found
[    9.704866] usbcore: registered new interface driver usbhid
[    9.708570] hub 1-1:1.0: 4 ports detected
[    9.713711] usbhid: USB HID core driver
[    9.714861] mhu 2b1f0000.mhu: ARM MHU Mailbox registered
[    9.740849] drop_monitor: Initializing network drop monitor service
[    9.751356] NET: Registered protocol family 10
[    9.752975] random: fast init done
[    9.761199] Segment Routing with IPv6
[    9.765574] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
[    9.772882] NET: Registered protocol family 17
[    9.777629] Bridge firewalling registered
[    9.781804] Bluetooth: HIDP (Human Interface Emulation) ver 1.2
[    9.787875] Bluetooth: HIDP socket layer initialized
[    9.793029] 8021q: 802.1Q VLAN Support v1.8
[    9.797718] 9pnet: Installing 9P2000 support
[    9.802205] Key type dns_resolver registered
[    9.807996] registered taskstats version 1
[    9.812243] Loading compiled-in X.509 certificates
[    9.820380] Btrfs loaded, crc32c=crc32c-generic
[    9.836554] scpi_protocol scpi: SCP Protocol 1.2 Firmware 1.21.0 version
[    9.900309] arm-smmu 2b600000.iommu: probing hardware configuration...
[    9.906999] arm-smmu 2b600000.iommu: SMMUv1 with:
[    9.911929] arm-smmu 2b600000.iommu: 	stage 2 translation
[    9.917444] arm-smmu 2b600000.iommu: 	coherent table walk
[    9.922977] arm-smmu 2b600000.iommu: 	stream matching with 2 register groups
[    9.930180] arm-smmu 2b600000.iommu: 	1 context banks (1 stage-2 only)
[    9.936853] arm-smmu 2b600000.iommu: 	Supported page sizes: 0x60211000
[    9.943495] arm-smmu 2b600000.iommu: 	Stage-2: 40-bit IPA -> 40-bit PA
[    9.953325] input: smb@8000000:motherboard:gpio-keys as /devices/platform/smb@8000000/smb@8000000:motherboard/smb@8000000:motherboard:gpio-keys/input/input1
[    9.969875] rtc-pl031 1c170000.rtc: setting system clock to 2020-03-24T13:26:36 UTC (1585056396)
[   10.280067] usb 1-1.1: new high-speed USB device number 3 using ehci-platform
[   10.325610] usb-storage 1-1.1:1.0: USB Mass Storage device detected
[   10.340148] scsi host2: usb-storage 1-1.1:1.0
[   10.503982] atkbd serio0: keyboard reset failed on 1c060000.kmi
[   10.992124] ata1: SATA link down (SStatus 0 SControl 0)
[   11.372862] scsi 2:0:0:0: Direct-Access     TOSHIBA  TransMemory      PMAP PQ: 0 ANSI: 6
[   11.385025] sd 2:0:0:0: [sda] 30253056 512-byte logical blocks: (15.5 GB/14.4 GiB)
[   11.395886] sd 2:0:0:0: [sda] Write Protect is off
[   11.400946] sd 2:0:0:0: [sda] Mode Sense: 45 00 00 00
[   11.407205] sd 2:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[   11.476739]  sda: sda1 sda2
[   11.495313] sd 2:0:0:0: [sda] Attached SCSI removable disk
[   11.751875] atkbd serio1: keyboard reset failed on 1c070000.kmi
[   13.048101] ata2: SATA link down (SStatus 0 SControl 0)
[   13.059761] sky2 0000:08:00.0 eth0: enabling interface
[   13.068686] Generic PHY 18000000.ethernet-ffffffff:01: attached PHY driver [Generic PHY] (mii_bus:phy_addr=18000000.ethernet-ffffffff:01, irq=POLL)
[   13.083104] smsc911x 18000000.ethernet eth1: SMSC911x/921x identified at 0xffff800018d90000, IRQ: 8
[   15.144751] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[   15.163932] Sending DHCP requests ., OK
[   15.300992] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
[   15.304182] ALSA device list:
[   15.309940] platform regulatory.0: Falling back to sysfs fallback for: regulatory.db
[   15.313166]   No soundcards found.
[   15.325677] uart-pl011 7ff80000.uart: no DMA platform data
[   15.381459] Freeing unused kernel memory: 14656K
[   15.576075] Run /init as init process
[   15.579784]   with arguments:
[   15.582818]     /init
[   15.585143]     ttyAMA0,115200n8
[   15.588438]     verbose
[   15.590911]     nfsrootdebug
[   15.593846]   with environment:
[   15.597044]     HOME=/
[   15.599429]     TERM=linux
[   15.602189]     user_debug=31
[   16.000277] Adding 2543608k swap on /dev/sda2.  Priority:-2 extents:1 across:2543608k 
[   18.690278] input: PS/2 Generic Mouse as /devices/platform/smb@8000000/smb@8000000:motherboard/smb@8000000:motherboard:iofpga@3,00000000/1c060000.kmi/serio0/input/input3
[   18.815258] psmouse serio0: Failed to enable mouse on 1c060000.kmi
[   20.581550] random: dd: uninitialized urandom read (512 bytes read)
[   20.695317] random: ssh-keygen: uninitialized urandom read (32 bytes read)
[   20.725071] random: sshd: uninitialized urandom read (32 bytes read)
[   20.805838] sky2 0000:08:00.0 eth0: enabling interface
[   25.641788] input: PS/2 Generic Mouse as /devices/platform/smb@8000000/smb@8000000:motherboard/smb@8000000:motherboard:iofpga@3,00000000/1c070000.kmi/serio1/input/input4
[   25.770081] psmouse serio1: Failed to enable mouse on 1c070000.kmi
[   68.871949] rcu-torture: rtc: (____ptrval____) ver: 1430 tfle: 0 rta: 1431 rtaf: 0 rtf: 1419 rtmbe: 0 rtbe: 0 rtbke: 0 rtbre: 0 rtbf: 0 rtb: 0 nt: 24137 onoff: 0/0:0/0 -1,0:-1,0 0:0 (HZ=250) barrier: 0/0:0
[   68.891859] rcu-torture: Reader Pipe:  14518041 3920 0 0 0 0 0 0 0 0 0
[   68.898567] rcu-torture: Reader Batch:  14513170 8794 0 0 0 0 0 0 0 0 0
[   68.905308] rcu-torture: Free-Block Circulation:  1430 1430 1429 1428 1426 1425 1424 1423 1421 1420 0
[   77.075919] cfg80211: failed to load regulatory.db
[   85.395510] PM: hibernation: hibernation entry
[   85.407291] Filesystems sync: 0.001 seconds
[   85.411706] Freezing user space processes ... (elapsed 0.003 seconds) done.
[   85.422153] OOM killer disabled.
[   85.432722] PM: hibernation: Preallocating image memory
[   86.962730] PM: hibernation: Allocated 97206 pages for snapshot
[   86.968783] PM: hibernation: Allocated 388824 kbytes in 1.52 seconds (255.80 MB/s)
[   86.976488] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[   86.988496] printk: Suspending console(s) (use no_console_suspend to debug)
[   87.052353] usbcore:hub_suspend: hub 1-1:1.0: hub_suspend
[   87.054920] usbcore:hub_suspend: hub 1-0:1.0: hub_suspend
[   87.055211] usbcore:hcd_bus_suspend: usb usb1: bus suspend, wakeup 0
[   87.106030] Disabling non-boot CPUs ...
[   87.115339] CPU1: shutdown
[   87.115396] psci: CPU1 killed (polled 0 ms)
[   87.124698] CPU2: shutdown
[   87.125786] psci: CPU2 killed (polled 0 ms)
[   87.142474] CPU3: shutdown
[   87.142499] psci: CPU3 killed (polled 0 ms)
[   87.158793] CPU4: shutdown
[   87.158818] psci: CPU4 killed (polled 0 ms)
[   87.170296] CPU5: shutdown
[   87.170322] psci: CPU5 killed (polled 0 ms)
[   87.181175] PM: hibernation: Creating image:
[   87.181175] PM: hibernation: Need to copy 95355 pages
[   87.181175] PM: hibernation: Image created (95355 pages copied)
[   87.181755] Enabling non-boot CPUs ...
[   87.195741] Detected PIPT I-cache on CPU1
[   87.195807] CPU1: Booted secondary processor 0x0000000000 [0x410fd080]
[   87.199267] CPU1 is up
[   87.218474] Detected PIPT I-cache on CPU2
[   87.218514] CPU2: Booted secondary processor 0x0000000001 [0x410fd080]
[   87.220090] CPU2 is up
[   87.233753] Detected VIPT I-cache on CPU3
[   87.233836] CPU3: Booted secondary processor 0x0000000101 [0x410fd033]
[   87.236870] CPU3 is up
[   87.251072] Detected VIPT I-cache on CPU4
[   87.251139] CPU4: Booted secondary processor 0x0000000102 [0x410fd033]
[   87.254256] CPU4 is up
[   87.268055] Detected VIPT I-cache on CPU5
[   87.268119] CPU5: Booted secondary processor 0x0000000103 [0x410fd033]
[   87.272310] CPU5 is up
[   87.308368] usbcore:hcd_bus_resume: usb usb1: usb resume
[   87.339802] usbcore:hcd_bus_resume: usb usb2: usb resume
[   87.370809] usbcore:hub_resume: hub 1-0:1.0: hub_resume
[   87.371148] usbcore:hub_activate: usb usb1-port1: status 0503 change 0000
[   87.371358] usbcore:hub_resume: hub 1-1:1.0: hub_resume
[   87.371785] usbcore:hub_activate: usb 1-1-port1: status 0503 change 0000
[   87.418064] usbcore:hub_resume: hub 2-0:1.0: hub_resume
[   87.418308] usb usb2: runtime PM trying to activate child device usb2 but parent (7ffb0000.ohci) is not active
[   87.622694] PM: Cannot find swap device, try swapon -a
[   87.628057] PM: Cannot get swap writer
[   88.214621] OOM killer enabled.
[   88.217943] Restarting tasks ... 
[   88.220049] usbcore:hub_event: hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0000
[   88.225181] done.
[   88.231030] usbcore:hub_event: hub 1-1:1.0: state 7 ports 4 chg 0000 evt 0000
[   88.240461] usbcore:hub_event: hub 2-0:1.0: state 7 ports 1 chg 0000 evt 0000
[   88.248053] usbcore:hub_resume: hub 2-0:1.0: hub_resume
[   88.253967] ------------[ cut here ]------------
[   88.258945] URB (____ptrval____) submitted while active
[   88.264629] WARNING: CPU: 4 PID: 379 at drivers/usb/core/urb.c:363 usb_submit_urb+0x3d8/0x590
[   88.273808] Modules linked in:
[   88.273830] CPU: 4 PID: 379 Comm: kworker/4:2 Not tainted 5.6.0-rc6-00002-gdfd1731f9a3e #541
[   88.273839] Hardware name: ARM Juno development board (r2) (DT)
[   88.273852] Workqueue: usb_hub_wq hub_event
[   88.273865] pstate: 40000005 (nZcv daif -PAN -UAO)
[   88.273876] pc : usb_submit_urb+0x3d8/0x590
[   88.273886] lr : usb_submit_urb+0x3d8/0x590
[   88.273894] sp : ffff8000190038b0
[   88.273902] x29: ffff8000190038b0 x28: 0000000000000003 
[   88.273916] x27: ffff00097050fb20 x26: ffff80001340d000 
[   88.273930] x25: ffff80001340d000 x24: ffff800019003b38 
[   88.273944] x23: 0000000000000004 x22: 0000000000000c00 
[   88.273958] x21: 0000000000000000 x20: 00000000fffffff0 
[   88.273971] x19: ffff00097046fe00 x18: ffffffffffffffff 
[   88.273986] x17: 00000000934eeaf4 x16: 00000000ad4e46a7 
[   88.273999] x15: ffff80001340da88 x14: 0720072007200720 
[   88.274013] x13: 0720072007200720 x12: 0720072007200720 
[   88.274027] x11: 0000000000000000 x10: 000000008f00fc00 
[   88.274041] x9 : 0000000000000002 x8 : ffff000970fa08a0 
[   88.274055] x7 : 0000000000000000 x6 : ffff00097ef86450 
[   88.274069] x5 : ffff00097ef86450 x4 : 0000000000000000 
[   88.274082] x3 : ffff00097ef96070 x2 : 0000000000000001 
[   88.274096] x1 : bf0dcc4e01afe000 x0 : 0000000000000000 
[   88.274110] Call trace:
[   88.274121]  usb_submit_urb+0x3d8/0x590
[   88.274131]  hub_activate+0x108/0x7f0
[   88.274140]  hub_resume+0xac/0x148
[   88.274152]  usb_resume_interface.isra.10+0x60/0x138
[   88.274163]  usb_resume_both+0xe4/0x140
[   88.274173]  usb_runtime_resume+0x24/0x30
[   88.274187]  __rpm_callback+0xdc/0x138
[   88.274197]  rpm_callback+0x34/0x98
[   88.274208]  rpm_resume+0x4a8/0x720
[   88.274218]  rpm_resume+0x50c/0x720
[   88.274229]  __pm_runtime_resume+0x4c/0xb8
[   88.274240]  usb_autopm_get_interface+0x28/0x60
[   88.274249]  hub_event+0x80/0x16d8
[   88.274262]  process_one_work+0x2a4/0x748
[   88.274273]  worker_thread+0x48/0x498
[   88.274284]  kthread+0x13c/0x140
[   88.274295]  ret_from_fork+0x10/0x18
[   88.274303] irq event stamp: 392
[   88.274318] hardirqs last  enabled at (391): [<ffff800011982754>] _raw_spin_unlock_irq+0x34/0x68
[   88.274332] hardirqs last disabled at (392): [<ffff8000100a95d0>] do_debug_exception+0x1a8/0x258
[   88.274344] softirqs last  enabled at (386): [<ffff8000100818a4>] __do_softirq+0x4bc/0x568
[   88.274355] softirqs last disabled at (375): [<ffff8000101145a4>] irq_exit+0x144/0x150
[   88.274363] ---[ end trace f4c0292c296f056a ]---
[   88.286435] hub 2-0:1.0: activate --> -16
[   88.286692] usbcore:hub_event: hub 2-0:1.0: state 7 ports 1 chg 0000 evt 0000
[   88.286765] usbcore:hub_suspend: hub 2-0:1.0: hub_suspend
[   88.287042] usbcore:hcd_bus_suspend: usb usb2: bus auto-suspend, wakeup 1
[   88.537224] PM: hibernation: hibernation exit
[   89.075447] rcu_torture_fwd_prog_nr: Duration 5043 cver 276 gps 501
[   89.311502] ata1: SATA link down (SStatus 0 SControl 0)
[   89.367552] ata2: SATA link down (SStatus 0 SControl 0)
[   89.530995] rcu_torture_fwd_prog_cr Duration 36 barrier: 29 pending 11061 n_launders: 18738 n_launders_sa: 9612 n_max_gps: 100 n_max_cbs: 14380 cver 0 gps 8
[   89.545347] rcu_torture_fwd_cb_hist: Callback-invocation histogram (duration 69 jiffies): 1s/10: 8737:5 2s/10: 24381:7
[   93.948034] psmouse serio0: Failed to enable mouse on 1c060000.kmi
[  100.793867] psmouse serio1: Failed to enable mouse on 1c070000.kmi

^ permalink raw reply related	[flat|nested] 50+ messages in thread

* Re: lockdep warning in urb.c:363 usb_submit_urb
  2020-03-24 10:46       ` Qais Yousef
  2020-03-24 13:20         ` Oliver Neukum
@ 2020-03-24 13:47         ` Alan Stern
  1 sibling, 0 replies; 50+ messages in thread
From: Alan Stern @ 2020-03-24 13:47 UTC (permalink / raw)
  To: Qais Yousef; +Cc: Oliver Neukum, Greg Kroah-Hartman, linux-usb, linux-kernel

On Tue, 24 Mar 2020, Qais Yousef wrote:

> I should have stuck to what I know then. I misread the documentation. Hopefully
> the attached looks better. I don't see the new debug you added emitted.

These lines:

[  158.113836] ohci_hcd:ohci_resume: ohci-platform 7ffb0000.ohci: powerup ports
[  158.139682] usbcore:hcd_bus_resume: usb usb2: usb resume
[  158.139715] ohci_hcd:ohci_rh_resume: ohci-platform 7ffb0000.ohci: resume root hub
...
[  158.219604] usbcore:hub_resume: hub 2-0:1.0: hub_resume
[  158.220482] usb usb2: runtime PM trying to activate child device usb2 but parent (7ffb0000.ohci) is not active

suggest there is a bug in the platform code.  The 7ffb0000.ohci 
platform device should already be resumed and active at this point.

Following that, this is suspicious:

[  158.482995] PM: Cannot find swap device, try swapon -a
[  158.488379] PM: Cannot get swap writer

Since there was never any device attached to the OHCI controller, this
error is not connected to the previous one.  In fact, the swap device
was plugged into the EHCI controller; it was 1-1.1.  But the log
doesn't contain anything about that device being suspended, resumed, or
disconnected.  What happened to it?

[  159.064094] OOM killer enabled.
[  159.067351] Restarting tasks ... 
[  159.068831] usbcore:hub_event: hub 2-0:1.0: state 7 ports 1 chg 0000 evt 0000
[  159.079921] usbcore:hub_event: hub 1-1:1.0: state 7 ports 4 chg 0000 evt 0000
[  159.079959] usbcore:hub_event: hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0000
[  159.090776] done.
[  159.097076] usbcore:hub_resume: hub 2-0:1.0: hub_resume
[  159.102961] ------------[ cut here ]------------
[  159.107805] URB (____ptrval____) submitted while active

And why was usb2 resumed twice in a row with intervening suspend?

Alan Stern


^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: lockdep warning in urb.c:363 usb_submit_urb
  2020-03-24 13:43           ` Qais Yousef
@ 2020-03-24 13:52             ` Alan Stern
  2020-03-24 14:06               ` Qais Yousef
  0 siblings, 1 reply; 50+ messages in thread
From: Alan Stern @ 2020-03-24 13:52 UTC (permalink / raw)
  To: Qais Yousef; +Cc: Oliver Neukum, Greg Kroah-Hartman, linux-usb, linux-kernel

On Tue, 24 Mar 2020, Qais Yousef wrote:

> On 03/24/20 14:20, Oliver Neukum wrote:
> > Am Dienstag, den 24.03.2020, 10:46 +0000 schrieb Qais Yousef:
> > > 
> > > I should have stuck to what I know then. I misread the documentation. Hopefully
> > > the attached looks better. I don't see the new debug you added emitted.
> > 
> > That is odd. Please try
> > 
> > echo "module usbcore +mfp" > /sys/kernel/debug/dynamic_debug/control
> > 
> > with the attached improved patch.
> 
> Hmm still no luck
> 
> 
> # history
>    0 echo "module usbcore +mfp" > /sys/kernel/debug/dynamic_debug/control
>    1 swapoff -a
>    2 echo suspend > /sys/power/disk
>    3 echo disk > /sys/power/state
>    4 dmesg > usb.dmesg

What happens if you omit step 1 (the swapoff)?

> $ git log -p
> commit dfd1731f9a3e7592135d2a6b2a5c5e1640a7eea4 (HEAD)
> Author: Oliver Neukum <oneukum@suse.com>
> Date:   Mon Mar 23 16:34:35 2020 +0100
> 
>     usb: hub additional debugging
> 
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index 54cd8ef795ec..12ce2fdc4c2a 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -1629,6 +1629,7 @@ static int hub_configure(struct usb_hub *hub,
>                 ret = -ENOMEM;
>                 goto fail;
>         }
> +       dev_dbg(hub_dev, "%p URB allocated \n", hub->urb);
> 
>         usb_fill_int_urb(hub->urb, hdev, pipe, *hub->buffer, maxp, hub_irq,
>                 hub, endpoint->bInterval);

Oliver, by the way, %p isn't a good way to get pointer values for 
debugging.  Its output depends on how the system is configured.  Use 
%px instead (see Documentation/core-api/printk-formats.rst).

Alan Stern


^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: lockdep warning in urb.c:363 usb_submit_urb
  2020-03-24 13:52             ` Alan Stern
@ 2020-03-24 14:06               ` Qais Yousef
  2020-03-24 15:56                 ` Alan Stern
  0 siblings, 1 reply; 50+ messages in thread
From: Qais Yousef @ 2020-03-24 14:06 UTC (permalink / raw)
  To: Alan Stern; +Cc: Oliver Neukum, Greg Kroah-Hartman, linux-usb, linux-kernel

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

On 03/24/20 09:52, Alan Stern wrote:
> On Tue, 24 Mar 2020, Qais Yousef wrote:
> 
> > On 03/24/20 14:20, Oliver Neukum wrote:
> > > Am Dienstag, den 24.03.2020, 10:46 +0000 schrieb Qais Yousef:
> > > > 
> > > > I should have stuck to what I know then. I misread the documentation. Hopefully
> > > > the attached looks better. I don't see the new debug you added emitted.
> > > 
> > > That is odd. Please try
> > > 
> > > echo "module usbcore +mfp" > /sys/kernel/debug/dynamic_debug/control
> > > 
> > > with the attached improved patch.
> > 
> > Hmm still no luck
> > 
> > 
> > # history
> >    0 echo "module usbcore +mfp" > /sys/kernel/debug/dynamic_debug/control
> >    1 swapoff -a
> >    2 echo suspend > /sys/power/disk
> >    3 echo disk > /sys/power/state
> >    4 dmesg > usb.dmesg
> 
> What happens if you omit step 1 (the swapoff)?

It seems to hibernate (suspend) successfully. If I omit that step I must setup
a wakealarm to trigger the wakeup, but that's it.

I attached the dmesg; I didn't reboot the system in between.


# history
   0 echo "module usbcore +mfp" > /sys/kernel/debug/dynamic_debug/control
   1 swapoff -a
   2 echo suspend > /sys/power/disk
   3 echo disk > /sys/power/state
   4 dmesg > usb.dmesg
   5 history
   6 grep URB /sys/kernel/debug/dynamic_debug/control
   7 grep "URB allocated" /sys/kernel/debug/dynamic_debug/control
   8 swapon -a
   9 echo +60 > /sys/class/rtc/rtc0/wakealarm
  10 echo disk > /sys/power/state
  11 dmesg > usb.dmesg


Thanks

--
Qais Yousef

> 
> > $ git log -p
> > commit dfd1731f9a3e7592135d2a6b2a5c5e1640a7eea4 (HEAD)
> > Author: Oliver Neukum <oneukum@suse.com>
> > Date:   Mon Mar 23 16:34:35 2020 +0100
> > 
> >     usb: hub additional debugging
> > 
> > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> > index 54cd8ef795ec..12ce2fdc4c2a 100644
> > --- a/drivers/usb/core/hub.c
> > +++ b/drivers/usb/core/hub.c
> > @@ -1629,6 +1629,7 @@ static int hub_configure(struct usb_hub *hub,
> >                 ret = -ENOMEM;
> >                 goto fail;
> >         }
> > +       dev_dbg(hub_dev, "%p URB allocated \n", hub->urb);
> > 
> >         usb_fill_int_urb(hub->urb, hdev, pipe, *hub->buffer, maxp, hub_irq,
> >                 hub, endpoint->bInterval);
> 
> Oliver, by the way, %p isn't a good way to get pointer values for 
> debugging.  Its output depends on how the system is configured.  Use 
> %px instead (see Documentation/core-api/printk-formats.rst).
> 
> Alan Stern
> 

[-- Attachment #2: usb.dmesg --]
[-- Type: text/plain, Size: 80841 bytes --]

[    0.000000] Booting Linux on physical CPU 0x0000000100 [0x410fd033]
[    0.000000] Linux version 5.6.0-rc6-00002-gdfd1731f9a3e (qyousef@e107158-lin) (gcc version 7.5.0 (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04)) #541 SMP PREEMPT Tue Mar 24 13:29:19 GMT 2020
[    0.000000] Machine model: ARM Juno development board (r2)
[    0.000000] earlycon: pl11 at MMIO 0x000000007ff80000 (options '')
[    0.000000] printk: bootconsole [pl11] enabled
[    0.000000] efi: Getting EFI parameters from FDT:
[    0.000000] efi: UEFI not found.
[    0.000000] cma: Reserved 32 MiB at 0x00000000fd000000
[    0.000000] NUMA: No NUMA configuration found
[    0.000000] NUMA: Faking a node at [mem 0x0000000080000000-0x00000009ffffffff]
[    0.000000] NUMA: NODE_DATA [mem 0x9fefdb000-0x9fefdcfff]
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x0000000080000000-0x00000000bfffffff]
[    0.000000]   DMA32    [mem 0x00000000c0000000-0x00000000ffffffff]
[    0.000000]   Normal   [mem 0x0000000100000000-0x00000009ffffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000080000000-0x00000000feffffff]
[    0.000000]   node   0: [mem 0x0000000880000000-0x00000009ffffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000080000000-0x00000009ffffffff]
[    0.000000] On node 0 totalpages: 2093056
[    0.000000]   DMA zone: 4096 pages used for memmap
[    0.000000]   DMA zone: 0 pages reserved
[    0.000000]   DMA zone: 262144 pages, LIFO batch:63
[    0.000000]   DMA32 zone: 4096 pages used for memmap
[    0.000000]   DMA32 zone: 258048 pages, LIFO batch:63
[    0.000000]   Normal zone: 24576 pages used for memmap
[    0.000000]   Normal zone: 1572864 pages, LIFO batch:63
[    0.000000] psci: probing for conduit method from DT.
[    0.000000] psci: PSCIv1.0 detected in firmware.
[    0.000000] psci: Using standard PSCI v0.2 function IDs
[    0.000000] psci: Trusted OS migration not required
[    0.000000] psci: SMC Calling Convention v1.0
[    0.000000] percpu: Embedded 48 pages/cpu s159176 r8192 d29240 u196608
[    0.000000] pcpu-alloc: s159176 r8192 d29240 u196608 alloc=48*4096
[    0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0] 4 [0] 5 
[    0.000000] Detected VIPT I-cache on CPU0
[    0.000000] CPU features: detected: ARM erratum 845719
[    0.000000] CPU features: detected: ARM erratum 843419
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 2060288
[    0.000000] Policy zone: Normal
[    0.000000] Kernel command line: ttyAMA0,115200n8 root=/dev/nfs rw verbose debug ip=dhcp nfsroot=xx.xx.xx.xx:/mnt/data/exports/juno,vers=4,tcp nfsrootdebug rootwait earlycon=pl011,0x7ff80000 systemd.log_target=null user_debug=31 androidboot.hardware=juno loglevel=9 bootargs_sky2=sky2.mac_address=0x00,0x02,0xf7,0x00,0x67,0xbe
[    0.000000] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes, linear)
[    0.000000] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes, linear)
[    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[    0.000000] software IO TLB: mapped [mem 0xbbfff000-0xbffff000] (64MB)
[    0.000000] Memory: 8044448K/8372224K available (25724K kernel code, 4126K rwdata, 12236K rodata, 14656K init, 11192K bss, 295008K reserved, 32768K cma-reserved)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=6, Nodes=1
[    0.000000] ftrace: allocating 77609 entries in 304 pages
[    0.000000] ftrace: allocated 304 pages with 3 groups
[    0.000000] Running RCU self tests
[    0.000000] rcu: Preemptible hierarchical RCU implementation.
[    0.000000] rcu: 	RCU lockdep checking is enabled.
[    0.000000] rcu: 	RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=6.
[    0.000000] 	Tasks RCU enabled.
[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
[    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=6
[    0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
[    0.000000] GIC: Using split EOI/Deactivate mode
[    0.000000] GICv2m: range[mem 0x2c1c0000-0x2c1cffff], SPI[224:255]
[    0.000000] GICv2m: range[mem 0x2c1d0000-0x2c1dffff], SPI[256:287]
[    0.000000] GICv2m: range[mem 0x2c1e0000-0x2c1effff], SPI[288:319]
[    0.000000] GICv2m: range[mem 0x2c1f0000-0x2c1fffff], SPI[320:351]
[    0.000000] random: get_random_bytes called from start_kernel+0x5d8/0x784 with crng_init=0
[    0.000000] clocksource: arm,sp804: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275 ns
[    0.000007] sched_clock: 32 bits at 1000kHz, resolution 1000ns, wraps every 2147483647500ns
[    0.008559] Failed to initialize '/smb@8000000/motherboard/iofpga@3,00000000/timer@120000': -22
[    0.018104] arch_timer: cp15 and mmio timer(s) running at 50.00MHz (phys/phys).
[    0.025447] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0xb8812736b, max_idle_ns: 440795202655 ns
[    0.036277] sched_clock: 56 bits at 50MHz, resolution 20ns, wraps every 4398046511100ns
[    0.045514] Console: colour dummy device 80x25
[    0.050047] printk: console [tty0] enabled
[    0.054294] printk: bootconsole [pl11] disabled
[    0.058987] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
[    0.059154] ... MAX_LOCKDEP_SUBCLASSES:  8
[    0.059254] ... MAX_LOCK_DEPTH:          48
[    0.059355] ... MAX_LOCKDEP_KEYS:        8192
[    0.059460] ... CLASSHASH_SIZE:          4096
[    0.059565] ... MAX_LOCKDEP_ENTRIES:     32768
[    0.059672] ... MAX_LOCKDEP_CHAINS:      65536
[    0.059777] ... CHAINHASH_SIZE:          32768
[    0.059883]  memory used by lock dependency info: 6237 kB
[    0.060005]  memory used for stack traces: 4224 kB
[    0.060117]  per task-struct memory footprint: 1920 bytes
[    0.060239] ------------------------
[    0.060330] | Locking API testsuite:
[    0.060421] ----------------------------------------------------------------------------
[    0.060593]                                  | spin |wlock |rlock |mutex | wsem | rsem |
[    0.060764]   --------------------------------------------------------------------------
[    0.060943]                      A-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[    0.079471]                  A-B-B-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[    0.099610]              A-B-B-C-C-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[    0.121456]              A-B-C-A-B-C deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[    0.143259]          A-B-B-C-C-D-D-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[    0.166767]          A-B-C-D-B-D-D-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[    0.190249]          A-B-C-D-B-C-D-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[    0.213763]                     double unlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[    0.232219]                   initialize held:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[    0.250044]   --------------------------------------------------------------------------
[    0.250214]               recursive read-lock:             |  ok  |             |  ok  |
[    0.255845]            recursive read-lock #2:             |  ok  |             |  ok  |
[    0.261257]             mixed read-write-lock:             |  ok  |             |  ok  |
[    0.266678]             mixed write-read-lock:             |  ok  |             |  ok  |
[    0.272102]   mixed read-lock/lock-write ABBA:             |FAILED|             |  ok  |
[    0.277826]    mixed read-lock/lock-read ABBA:             |  ok  |             |  ok  |
[    0.283714]  mixed write-lock/lock-write ABBA:             |  ok  |             |  ok  |
[    0.289603]   --------------------------------------------------------------------------
[    0.289934]      hard-irqs-on + irq-safe-A/12:  ok  |  ok  |  ok  |
[    0.297909]      soft-irqs-on + irq-safe-A/12:  ok  |  ok  |  ok  |
[    0.305930]      hard-irqs-on + irq-safe-A/21:  ok  |  ok  |  ok  |
[    0.313903]      soft-irqs-on + irq-safe-A/21:  ok  |  ok  |  ok  |
[    0.321911]        sirq-safe-A => hirqs-on/12:  ok  |  ok  |  ok  |
[    0.329897]        sirq-safe-A => hirqs-on/21:  ok  |  ok  |  ok  |
[    0.337919]          hard-safe-A + irqs-on/12:  ok  |  ok  |  ok  |
[    0.345890]          soft-safe-A + irqs-on/12:  ok  |  ok  |  ok  |
[    0.353910]          hard-safe-A + irqs-on/21:  ok  |  ok  |  ok  |
[    0.361883]          soft-safe-A + irqs-on/21:  ok  |  ok  |  ok  |
[    0.369892]     hard-safe-A + unsafe-B #1/123:  ok  |  ok  |  ok  |
[    0.378560]     soft-safe-A + unsafe-B #1/123:  ok  |  ok  |  ok  |
[    0.387282]     hard-safe-A + unsafe-B #1/132:  ok  |  ok  |  ok  |
[    0.395952]     soft-safe-A + unsafe-B #1/132:  ok  |  ok  |  ok  |
[    0.404671]     hard-safe-A + unsafe-B #1/213:  ok  |  ok  |  ok  |
[    0.413340]     soft-safe-A + unsafe-B #1/213:  ok  |  ok  |  ok  |
[    0.422052]     hard-safe-A + unsafe-B #1/231:  ok  |  ok  |  ok  |
[    0.430701]     soft-safe-A + unsafe-B #1/231:  ok  |  ok  |  ok  |
[    0.439410]     hard-safe-A + unsafe-B #1/312:  ok  |  ok  |  ok  |
[    0.447609]     soft-safe-A + unsafe-B #1/312:  ok  |  ok  |  ok  |
[    0.455852]     hard-safe-A + unsafe-B #1/321:  ok  |  ok  |  ok  |
[    0.464512]     soft-safe-A + unsafe-B #1/321:  ok  |  ok  |  ok  |
[    0.473223]     hard-safe-A + unsafe-B #2/123:  ok  |  ok  |  ok  |
[    0.481908]     soft-safe-A + unsafe-B #2/123:  ok  |  ok  |  ok  |
[    0.490625]     hard-safe-A + unsafe-B #2/132:  ok  |  ok  |  ok  |
[    0.499298]     soft-safe-A + unsafe-B #2/132:  ok  |  ok  |  ok  |
[    0.508019]     hard-safe-A + unsafe-B #2/213:  ok  |  ok  |  ok  |
[    0.516684]     soft-safe-A + unsafe-B #2/213:  ok  |  ok  |  ok  |
[    0.525407]     hard-safe-A + unsafe-B #2/231:  ok  |  ok  |  ok  |
[    0.534083]     soft-safe-A + unsafe-B #2/231:  ok  |  ok  |  ok  |
[    0.542794]     hard-safe-A + unsafe-B #2/312:  ok  |  ok  |  ok  |
[    0.551452]     soft-safe-A + unsafe-B #2/312:  ok  |  ok  |  ok  |
[    0.560171]     hard-safe-A + unsafe-B #2/321:  ok  |  ok  |  ok  |
[    0.568833]     soft-safe-A + unsafe-B #2/321:  ok  |  ok  |  ok  |
[    0.577549]       hard-irq lock-inversion/123:  ok  |  ok  |  ok  |
[    0.586217]       soft-irq lock-inversion/123:  ok  |  ok  |  ok  |
[    0.594934]       hard-irq lock-inversion/132:  ok  |  ok  |  ok  |
[    0.603596]       soft-irq lock-inversion/132:  ok  |  ok  |  ok  |
[    0.612318]       hard-irq lock-inversion/213:  ok  |  ok  |  ok  |
[    0.620989]       soft-irq lock-inversion/213:  ok  |  ok  |  ok  |
[    0.629708]       hard-irq lock-inversion/231:  ok  |  ok  |  ok  |
[    0.638374]       soft-irq lock-inversion/231:  ok  |  ok  |  ok  |
[    0.647089]       hard-irq lock-inversion/312:  ok  |  ok  |  ok  |
[    0.655746]       soft-irq lock-inversion/312:  ok  |  ok  |  ok  |
[    0.664467]       hard-irq lock-inversion/321:  ok  |  ok  |  ok  |
[    0.673130]       soft-irq lock-inversion/321:  ok  |  ok  |  ok  |
[    0.681851]       hard-irq read-recursion/123:  ok  |
[    0.684808]       soft-irq read-recursion/123:  ok  |
[    0.687809]       hard-irq read-recursion/132:  ok  |
[    0.690765]       soft-irq read-recursion/132:  ok  |
[    0.693770]       hard-irq read-recursion/213:  ok  |
[    0.696726]       soft-irq read-recursion/213:  ok  |
[    0.699730]       hard-irq read-recursion/231:  ok  |
[    0.702687]       soft-irq read-recursion/231:  ok  |
[    0.705688]       hard-irq read-recursion/312:  ok  |
[    0.708645]       soft-irq read-recursion/312:  ok  |
[    0.711647]       hard-irq read-recursion/321:  ok  |
[    0.714602]       soft-irq read-recursion/321:  ok  |
[    0.717604]   --------------------------------------------------------------------------
[    0.717772]   | Wound/wait tests |
[    0.717859]   ---------------------
[    0.717947]                   ww api failures:  ok  |  ok  |  ok  |
[    0.726453]                ww contexts mixing:  ok  |  ok  |
[    0.732068]              finishing ww context:  ok  |  ok  |  ok  |  ok  |
[    0.743151]                locking mismatches:  ok  |  ok  |  ok  |
[    0.751623]                  EDEADLK handling:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[    0.780528]            spinlock nest unlocked:  ok  |
[    0.783253]   -----------------------------------------------------
[    0.783387]                                  |block | try  |context|
[    0.783524]   -----------------------------------------------------
[    0.783658]                           context:  ok  |  ok  |  ok  |
[    0.792394]                               try:  ok  |  ok  |  ok  |
[    0.800608]                             block:  ok  |  ok  |  ok  |
[    0.808862]                          spinlock:  ok  |  ok  |  ok  |
[    0.817795] -------------------------------------------------------
[    0.817931] Good, all 261 testcases passed! |
[    0.818034] ---------------------------------
[    0.818373] Calibrating delay loop (skipped), value calculated using timer frequency.. 100.00 BogoMIPS (lpj=200000)
[    0.818650] pid_max: default: 32768 minimum: 301
[    0.819122] LSM: Security Framework initializing
[    0.819426] Mount-cache hash table entries: 16384 (order: 5, 131072 bytes, linear)
[    0.819632] Mountpoint-cache hash table entries: 16384 (order: 5, 131072 bytes, linear)
[    0.855086] rcu: Hierarchical SRCU implementation.
[    0.872249] EFI services will not be available.
[    0.879375] smp: Bringing up secondary CPUs ...
[    0.925462] CPU features: detected: EL2 vector hardening
[    0.925475] ARM_SMCCC_ARCH_WORKAROUND_1 missing from firmware
[    0.925482] CPU features: detected: ARM erratum 1319367
[    0.925489] Detected PIPT I-cache on CPU1
[    0.925551] CPU1: Booted secondary processor 0x0000000000 [0x410fd080]
[    0.969765] Detected PIPT I-cache on CPU2
[    0.969800] CPU2: Booted secondary processor 0x0000000001 [0x410fd080]
[    1.014206] Detected VIPT I-cache on CPU3
[    1.014278] CPU3: Booted secondary processor 0x0000000101 [0x410fd033]
[    1.058602] Detected VIPT I-cache on CPU4
[    1.058660] CPU4: Booted secondary processor 0x0000000102 [0x410fd033]
[    1.103026] Detected VIPT I-cache on CPU5
[    1.103083] CPU5: Booted secondary processor 0x0000000103 [0x410fd033]
[    1.103707] smp: Brought up 1 node, 6 CPUs
[    1.105347] SMP: Total of 6 processors activated.
[    1.105567] CPU features: detected: 32-bit EL0 Support
[    1.105703] CPU features: detected: CRC32 instructions
[    1.168589] CPU: All CPU(s) started at EL2
[    1.168851] alternatives: patching kernel code
[    1.173882] devtmpfs: initialized
[    1.193809] KASLR disabled due to lack of seed
[    1.195961] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[    1.196083] futex hash table entries: 2048 (order: 6, 262144 bytes, linear)
[    1.197646] xor: measuring software checksum speed
[    1.234611]    8regs     :  4238.000 MB/sec
[    1.274820]    32regs    :  4763.000 MB/sec
[    1.315072]    arm64_neon:  4290.000 MB/sec
[    1.315126] xor: using function: 32regs (4763.000 MB/sec)
[    1.315194] pinctrl core: initialized pinctrl subsystem
[    1.317944] thermal_sys: Registered thermal governor 'step_wise'
[    1.317950] thermal_sys: Registered thermal governor 'power_allocator'
[    1.319665] DMI not present or invalid.
[    1.320924] NET: Registered protocol family 16
[    1.325042] DMA: preallocated 256 KiB pool for atomic allocations
[    1.325127] audit: initializing netlink subsys (disabled)
[    1.325663] audit: type=2000 audit(1.044:1): state=initialized audit_enabled=0 res=1
[    1.327747] cpuidle: using governor menu
[    1.328011] NET: Registered protocol family 42
[    1.328608] hw-breakpoint: found 6 breakpoint and 4 watchpoint registers.
[    1.329105] ASID allocator initialised with 65536 entries
[    1.331101] Serial: AMBA PL011 UART driver
[    1.360865] 7ff80000.uart: ttyAMA0 at MMIO 0x7ff80000 (irq = 31, base_baud = 0) is a PL011 rev3
[    2.798063] printk: console [ttyAMA0] enabled
[    2.869683] HugeTLB registered 1.00 GiB page size, pre-allocated 0 pages
[    2.876629] HugeTLB registered 32.0 MiB page size, pre-allocated 0 pages
[    2.883447] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages
[    2.890254] HugeTLB registered 64.0 KiB page size, pre-allocated 0 pages
[    2.923328] cryptd: max_cpu_qlen set to 1000
[    3.021904] raid6: neonx8   gen()  3081 MB/s
[    3.094355] raid6: neonx8   xor()  2156 MB/s
[    3.166859] raid6: neonx4   gen()  3067 MB/s
[    3.239275] raid6: neonx4   xor()  2275 MB/s
[    3.311745] raid6: neonx2   gen()  2656 MB/s
[    3.384186] raid6: neonx2   xor()  2059 MB/s
[    3.456655] raid6: neonx1   gen()  1971 MB/s
[    3.529101] raid6: neonx1   xor()  1619 MB/s
[    3.601566] raid6: int64x8  gen()  1555 MB/s
[    3.674013] raid6: int64x8  xor()   899 MB/s
[    3.746476] raid6: int64x4  gen()  1790 MB/s
[    3.818913] raid6: int64x4  xor()   971 MB/s
[    3.891357] raid6: int64x2  gen()  1592 MB/s
[    3.963815] raid6: int64x2  xor()   846 MB/s
[    4.036263] raid6: int64x1  gen()  1224 MB/s
[    4.108748] raid6: int64x1  xor()   639 MB/s
[    4.113097] raid6: using algorithm neonx8 gen() 3081 MB/s
[    4.118582] raid6: .... xor() 2156 MB/s, rmw enabled
[    4.123628] raid6: using neon recovery algorithm
[    4.129187] ACPI: Interpreter disabled.
[    4.135980] iommu: Default domain type: Translated 
[    4.141597] vgaarb: loaded
[    4.145349] SCSI subsystem initialized
[    4.149692] libata version 3.00 loaded.
[    4.154219] usbcore: registered new interface driver usbfs
[    4.159916] usbcore: registered new interface driver hub
[    4.165517] usbcore: registered new device driver usb
[    4.173528] mc: Linux media interface: v0.10
[    4.177949] videodev: Linux video capture interface: v2.00
[    4.183789] pps_core: LinuxPPS API ver. 1 registered
[    4.188842] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    4.198139] PTP clock support registered
[    4.202924] EDAC MC: Ver: 3.0.0
[    4.208900] FPGA manager framework
[    4.212863] Advanced Linux Sound Architecture Driver Initialized.
[    4.220442] Bluetooth: Core ver 2.22
[    4.224164] NET: Registered protocol family 31
[    4.228690] Bluetooth: HCI device and connection manager initialized
[    4.235176] Bluetooth: HCI socket layer initialized
[    4.240150] Bluetooth: L2CAP socket layer initialized
[    4.245346] Bluetooth: SCO socket layer initialized
[    4.251847] clocksource: Switched to clocksource arch_sys_counter
[    5.094664] VFS: Disk quotas dquot_6.6.0
[    5.098862] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    5.106585] pnp: PnP ACPI: disabled
[    5.129217] NET: Registered protocol family 2
[    5.134547] tcp_listen_portaddr_hash hash table entries: 4096 (order: 6, 294912 bytes, linear)
[    5.144017] TCP established hash table entries: 65536 (order: 7, 524288 bytes, linear)
[    5.152363] TCP bind hash table entries: 65536 (order: 10, 4194304 bytes, linear)
[    5.170770] TCP: Hash tables configured (established 65536 bind 65536)
[    5.177861] UDP hash table entries: 4096 (order: 7, 655360 bytes, linear)
[    5.186272] UDP-Lite hash table entries: 4096 (order: 7, 655360 bytes, linear)
[    5.195315] NET: Registered protocol family 1
[    5.201490] RPC: Registered named UNIX socket transport module.
[    5.207660] RPC: Registered udp transport module.
[    5.212485] RPC: Registered tcp transport module.
[    5.217296] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    5.224881] PCI: CLS 0 bytes, default 64
[    6.578984] hw perfevents: enabled with armv8_cortex_a72 PMU driver, 7 counters available
[    6.589062] hw perfevents: enabled with armv8_cortex_a53 PMU driver, 7 counters available
[    6.597532] kvm [1]: IPA Size Limit: 40bits
[    6.610626] kvm [1]: vgic interrupt IRQ1
[    6.615204] kvm [1]: Hyp mode initialized successfully
[    7.077112] rcu-torture:--- Start of test: nreaders=5 nfakewriters=4 stat_interval=60 verbose=1 test_no_idle_hz=1 shuffle_interval=3 stutter=5 irqreader=1 fqs_duration=0 fqs_holdoff=0 fqs_stutter=3 test_boost=1/0 test_boost_interval=7 test_boost_duration=4 shutdown_secs=0 stall_cpu=0 stall_cpu_holdoff=10 stall_cpu_irqsoff=0 n_barrier_cbs=0 onoff_interval=0 onoff_holdoff=0
[    7.110494] rcu-torture: Creating rcu_torture_writer task
[    7.116379] rcu-torture: Creating rcu_torture_fakewriter task
[    7.116385] rcu-torture: rcu_torture_writer task started
[    7.122491] rcu-torture: Creating rcu_torture_fakewriter task
[    7.122522] rcu-torture: rcu_torture_fakewriter task started
[    7.128171] rcu-torture: GP expediting controlled from boot/sysfs for rcu.
[    7.133916] rcu-torture: Creating rcu_torture_fakewriter task
[    7.133945] rcu-torture: rcu_torture_fakewriter task started
[    7.139582] rcu_torture_writer: Testing conditional GPs.
[    7.146788] rcu-torture: Creating rcu_torture_fakewriter task
[    7.146817] rcu-torture: rcu_torture_fakewriter task started
[    7.155874] rcu_torture_writer: Testing expedited GPs.
[    7.158579] rcu-torture: Creating rcu_torture_reader task
[    7.158607] rcu-torture: rcu_torture_fakewriter task started
[    7.163675] rcu_torture_writer: Testing asynchronous GPs.
[    7.169749] rcu-torture: Creating rcu_torture_reader task
[    7.169782] rcu-torture: rcu_torture_reader task started
[    7.175265] rcu_torture_writer: Testing normal GPs.
[    7.213385] rcu-torture: Creating rcu_torture_reader task
[    7.213443] rcu-torture: rcu_torture_reader task started
[    7.219139] rcu-torture: Creating rcu_torture_reader task
[    7.219168] rcu-torture: rcu_torture_reader task started
[    7.235646] rcu-torture: Creating rcu_torture_reader task
[    7.235684] rcu-torture: rcu_torture_reader task started
[    7.241392] rcu-torture: Creating rcu_torture_stats task
[    7.241397] rcu-torture: rcu_torture_reader task started
[    7.257785] rcu-torture: Creating torture_shuffle task
[    7.263087] rcu-torture: rcu_torture_stats task started
[    7.268826] rcu-torture: Creating torture_stutter task
[    7.268858] rcu-torture: torture_shuffle task started
[    7.274329] rcu-torture: Creating rcu_torture_fwd_prog task
[    7.274355] rcu-torture: torture_stutter task started
[    7.290466] rcu-torture: rcu_torture_fwd_progress task started
[    7.293479] Initialise system trusted keyrings
[    7.301423] workingset: timestamp_bits=44 max_order=21 bucket_order=0
[    7.336884] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    7.349427] NFS: Registering the id_resolver key type
[    7.354642] Key type id_resolver registered
[    7.358937] Key type id_legacy registered
[    7.363047] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[    7.370267] fuse: init (API version 7.31)
[    7.375772] 9p: Installing v9fs 9p2000 file system support
[    7.404730] Key type asymmetric registered
[    7.408986] Asymmetric key parser 'x509' registered
[    7.414040] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 243)
[    7.421582] io scheduler mq-deadline registered
[    7.426202] io scheduler kyber registered
[    7.445797] pl061_gpio 1c1d0000.gpio: PL061 GPIO chip registered
[    7.455590] pci-host-generic 40000000.pcie: host bridge /pcie@40000000 ranges:
[    7.462988] pci-host-generic 40000000.pcie:       IO 0x005f800000..0x005fffffff -> 0x0000000000
[    7.471956] pci-host-generic 40000000.pcie:      MEM 0x0050000000..0x0057ffffff -> 0x0050000000
[    7.480842] pci-host-generic 40000000.pcie:      MEM 0x4000000000..0x40ffffffff -> 0x4000000000
[    7.489788] pci-host-generic 40000000.pcie: ECAM at [mem 0x40000000-0x4fffffff] for [bus 00-ff]
[    7.498975] pci-host-generic 40000000.pcie: PCI host bridge to bus 0000:00
[    7.505978] pci_bus 0000:00: root bus resource [bus 00-ff]
[    7.511570] pci_bus 0000:00: root bus resource [io  0x0000-0x7fffff]
[    7.518038] pci_bus 0000:00: root bus resource [mem 0x50000000-0x57ffffff]
[    7.525038] pci_bus 0000:00: root bus resource [mem 0x4000000000-0x40ffffffff pref]
[    7.532922] pci 0000:00:00.0: [1556:1100] type 01 class 0x060400
[    7.539090] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x00003fff 64bit pref]
[    7.546617] pci 0000:00:00.0: supports D1 D2
[    7.550978] pci 0000:00:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[    7.559711] pci 0000:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[    7.568127] pci 0000:01:00.0: [111d:8090] type 01 class 0x060400
[    7.574387] pci 0000:01:00.0: enabling Extended Tags
[    7.579627] pci 0000:01:00.0: PME# supported from D0 D3hot D3cold
[    7.597244] pci 0000:01:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[    7.605766] pci 0000:02:01.0: [111d:8090] type 01 class 0x060400
[    7.612042] pci 0000:02:01.0: enabling Extended Tags
[    7.617316] pci 0000:02:01.0: PME# supported from D0 D3hot D3cold
[    7.624195] pci 0000:02:02.0: [111d:8090] type 01 class 0x060400
[    7.630469] pci 0000:02:02.0: enabling Extended Tags
[    7.635741] pci 0000:02:02.0: PME# supported from D0 D3hot D3cold
[    7.642575] pci 0000:02:03.0: [111d:8090] type 01 class 0x060400
[    7.648842] pci 0000:02:03.0: enabling Extended Tags
[    7.654113] pci 0000:02:03.0: PME# supported from D0 D3hot D3cold
[    7.661293] pci 0000:02:0c.0: [111d:8090] type 01 class 0x060400
[    7.667561] pci 0000:02:0c.0: enabling Extended Tags
[    7.672832] pci 0000:02:0c.0: PME# supported from D0 D3hot D3cold
[    7.679795] pci 0000:02:10.0: [111d:8090] type 01 class 0x060400
[    7.686056] pci 0000:02:10.0: enabling Extended Tags
[    7.691318] pci 0000:02:10.0: PME# supported from D0 D3hot D3cold
[    7.698753] pci 0000:02:1f.0: [111d:8090] type 01 class 0x060400
[    7.705021] pci 0000:02:1f.0: enabling Extended Tags
[    7.710291] pci 0000:02:1f.0: PME# supported from D0 D3hot D3cold
[    7.717084] pci 0000:02:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[    7.725252] pci 0000:02:02.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[    7.733413] pci 0000:02:03.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[    7.741593] pci 0000:02:0c.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[    7.749753] pci 0000:02:10.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[    7.757907] pci 0000:02:1f.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[    7.766363] pci 0000:03:00.0: [1095:3132] type 00 class 0x018000
[    7.772551] pci 0000:03:00.0: reg 0x10: [mem 0x00000000-0x0000007f 64bit]
[    7.779489] pci 0000:03:00.0: reg 0x18: [mem 0x00000000-0x00003fff 64bit]
[    7.786411] pci 0000:03:00.0: reg 0x20: [io  0x0000-0x007f]
[    7.792122] pci 0000:03:00.0: reg 0x30: [mem 0x00000000-0x0007ffff pref]
[    7.799106] pci 0000:03:00.0: supports D1 D2
[    7.803984] pci 0000:03:00.0: disabling ASPM on pre-1.1 PCIe device.  You can enable it with 'pcie_aspm=force'
[    7.815450] pci_bus 0000:03: busn_res: [bus 03-ff] end is updated to 03
[    7.823713] pci_bus 0000:04: busn_res: [bus 04-ff] end is updated to 04
[    7.832011] pci_bus 0000:05: busn_res: [bus 05-ff] end is updated to 05
[    7.840311] pci_bus 0000:06: busn_res: [bus 06-ff] end is updated to 06
[    7.848601] pci_bus 0000:07: busn_res: [bus 07-ff] end is updated to 07
[    7.855662] pci 0000:08:00.0: [11ab:4380] type 00 class 0x020000
[    7.861847] pci 0000:08:00.0: reg 0x10: [mem 0x00000000-0x00003fff 64bit]
[    7.868769] pci 0000:08:00.0: reg 0x18: [io  0x0000-0x00ff]
[    7.874684] pci 0000:08:00.0: supports D1 D2
[    7.879043] pci 0000:08:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[    7.887739] pci_bus 0000:08: busn_res: [bus 08-ff] end is updated to 08
[    7.894481] pci_bus 0000:02: busn_res: [bus 02-ff] end is updated to 08
[    7.901219] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 08
[    7.907976] pci 0000:00:00.0: BAR 14: assigned [mem 0x50000000-0x501fffff]
[    7.914978] pci 0000:00:00.0: BAR 0: assigned [mem 0x4000000000-0x4000003fff 64bit pref]
[    7.923243] pci 0000:00:00.0: BAR 13: assigned [io  0x1000-0x2fff]
[    7.929548] pci 0000:01:00.0: BAR 14: assigned [mem 0x50000000-0x501fffff]
[    7.936542] pci 0000:01:00.0: BAR 13: assigned [io  0x1000-0x2fff]
[    7.942844] pci 0000:02:01.0: BAR 14: assigned [mem 0x50000000-0x500fffff]
[    7.949838] pci 0000:02:1f.0: BAR 14: assigned [mem 0x50100000-0x501fffff]
[    7.956830] pci 0000:02:01.0: BAR 13: assigned [io  0x1000-0x1fff]
[    7.963120] pci 0000:02:1f.0: BAR 13: assigned [io  0x2000-0x2fff]
[    7.969424] pci 0000:03:00.0: BAR 6: assigned [mem 0x50000000-0x5007ffff pref]
[    7.976773] pci 0000:03:00.0: BAR 2: assigned [mem 0x50080000-0x50083fff 64bit]
[    7.984244] pci 0000:03:00.0: BAR 0: assigned [mem 0x50084000-0x5008407f 64bit]
[    7.991702] pci 0000:03:00.0: BAR 4: assigned [io  0x1000-0x107f]
[    7.997917] pci 0000:02:01.0: PCI bridge to [bus 03]
[    8.002980] pci 0000:02:01.0:   bridge window [io  0x1000-0x1fff]
[    8.009191] pci 0000:02:01.0:   bridge window [mem 0x50000000-0x500fffff]
[    8.016115] pci 0000:02:02.0: PCI bridge to [bus 04]
[    8.021208] pci 0000:02:03.0: PCI bridge to [bus 05]
[    8.026305] pci 0000:02:0c.0: PCI bridge to [bus 06]
[    8.031418] pci 0000:02:10.0: PCI bridge to [bus 07]
[    8.036523] pci 0000:08:00.0: BAR 0: assigned [mem 0x50100000-0x50103fff 64bit]
[    8.043981] pci 0000:08:00.0: BAR 2: assigned [io  0x2000-0x20ff]
[    8.050190] pci 0000:02:1f.0: PCI bridge to [bus 08]
[    8.055258] pci 0000:02:1f.0:   bridge window [io  0x2000-0x2fff]
[    8.061477] pci 0000:02:1f.0:   bridge window [mem 0x50100000-0x501fffff]
[    8.068407] pci 0000:01:00.0: PCI bridge to [bus 02-08]
[    8.073732] pci 0000:01:00.0:   bridge window [io  0x1000-0x2fff]
[    8.079944] pci 0000:01:00.0:   bridge window [mem 0x50000000-0x501fffff]
[    8.086873] pci 0000:00:00.0: PCI bridge to [bus 01-08]
[    8.092201] pci 0000:00:00.0:   bridge window [io  0x1000-0x2fff]
[    8.098407] pci 0000:00:00.0:   bridge window [mem 0x50000000-0x501fffff]
[    8.105743] pcieport 0000:00:00.0: enabling device (0000 -> 0003)
[    8.120032] pcieport 0000:00:00.0: PME: Signaling with IRQ 44
[    8.126997] pcieport 0000:00:00.0: AER: enabled with IRQ 44
[    8.133261] pcieport 0000:01:00.0: enabling device (0000 -> 0003)
[    8.139707] pcieport 0000:02:01.0: enabling device (0000 -> 0003)
[    8.150518] pcieport 0000:02:1f.0: enabling device (0000 -> 0003)
[    8.160458] IPMI message handler: version 39.2
[    8.165174] ipmi device interface
[    8.168698] ipmi_si: IPMI System Interface driver
[    8.174132] ipmi_si: Unable to find any System Interface(s)
[    8.181111] EINJ: ACPI disabled.
[    8.193706] dma-pl330 7ff00000.dma: WARN: Device release is not defined so it is not safe to unbind this driver while in use
[    8.206494] dma-pl330 7ff00000.dma: Loaded driver for PL330 DMAC-341330
[    8.213230] dma-pl330 7ff00000.dma: 	DBUFF-1024x16bytes Num_Chans-8 Num_Peri-8 Num_Events-8
[    8.237794] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    8.249476] SuperH (H)SCI(F) driver initialized
[    8.254765] msm_serial: driver initialized
[    8.262532] arm-smmu 7fb10000.iommu: probing hardware configuration...
[    8.269207] arm-smmu 7fb10000.iommu: SMMUv1 with:
[    8.274005] arm-smmu 7fb10000.iommu: 	stage 2 translation
[    8.279509] arm-smmu 7fb10000.iommu: 	non-coherent table walk
[    8.285365] arm-smmu 7fb10000.iommu: 	(IDR0.CTTW overridden by FW configuration)
[    8.292894] arm-smmu 7fb10000.iommu: 	stream matching with 2 register groups
[    8.300072] arm-smmu 7fb10000.iommu: 	1 context banks (1 stage-2 only)
[    8.306717] arm-smmu 7fb10000.iommu: 	Supported page sizes: 0x60211000
[    8.313357] arm-smmu 7fb10000.iommu: 	Stage-2: 40-bit IPA -> 40-bit PA
[    8.320927] arm-smmu 7fb20000.iommu: probing hardware configuration...
[    8.327578] arm-smmu 7fb20000.iommu: SMMUv1 with:
[    8.332379] arm-smmu 7fb20000.iommu: 	stage 2 translation
[    8.337882] arm-smmu 7fb20000.iommu: 	non-coherent table walk
[    8.343734] arm-smmu 7fb20000.iommu: 	(IDR0.CTTW overridden by FW configuration)
[    8.351262] arm-smmu 7fb20000.iommu: 	stream matching with 2 register groups
[    8.358439] arm-smmu 7fb20000.iommu: 	1 context banks (1 stage-2 only)
[    8.365088] arm-smmu 7fb20000.iommu: 	Supported page sizes: 0x60211000
[    8.371733] arm-smmu 7fb20000.iommu: 	Stage-2: 40-bit IPA -> 40-bit PA
[    8.378889] arm-smmu 7fb30000.iommu: probing hardware configuration...
[    8.385544] arm-smmu 7fb30000.iommu: SMMUv1 with:
[    8.390347] arm-smmu 7fb30000.iommu: 	stage 2 translation
[    8.395849] arm-smmu 7fb30000.iommu: 	coherent table walk
[    8.401352] arm-smmu 7fb30000.iommu: 	stream matching with 2 register groups
[    8.408523] arm-smmu 7fb30000.iommu: 	1 context banks (1 stage-2 only)
[    8.415173] arm-smmu 7fb30000.iommu: 	Supported page sizes: 0x60211000
[    8.421817] arm-smmu 7fb30000.iommu: 	Stage-2: 40-bit IPA -> 40-bit PA
[    8.563772] tda998x 0-0070: found TDA19988
[    8.696060] tda998x 0-0071: found TDA19988
[    8.766216] loop: module loaded
[    8.893170] mpt3sas version 33.100.00.00 loaded
[    8.903315] sata_sil24 0000:03:00.0: version 1.1
[    8.908345] sata_sil24 0000:03:00.0: enabling device (0000 -> 0003)
[    8.918391] scsi host0: sata_sil24
[    8.923496] scsi host1: sata_sil24
[    8.927499] ata1: SATA max UDMA/100 host m128@0x50084000 port 0x50080000 irq 51
[    8.934940] ata2: SATA max UDMA/100 host m128@0x50084000 port 0x50082000 irq 51
[    8.950044] libphy: Fixed MDIO Bus: probed
[    8.956437] tun: Universal TUN/TAP device driver, 1.6
[    8.962964] bnx2x: QLogic 5771x/578xx 10/20-Gigabit Ethernet Driver bnx2x 1.713.36-0 (2014/02/10)
[    8.972980] thunder_xcv, ver 1.0
[    8.976426] thunder_bgx, ver 1.0
[    8.979813] nicpf, ver 1.0
[    8.983449] hclge is initializing
[    8.987220] hns3: Hisilicon Ethernet Network Driver for Hip08 Family - version
[    8.994608] hns3: Copyright (c) 2017 Huawei Corporation.
[    9.000181] e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k
[    9.006119] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
[    9.012273] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.6.0-k
[    9.019349] igb: Copyright (c) 2007-2014 Intel Corporation.
[    9.025142] igbvf: Intel(R) Gigabit Virtual Function Network Driver - version 2.4.0-k
[    9.033096] igbvf: Copyright (c) 2009 - 2012 Intel Corporation.
[    9.039878] sky2: driver version 1.30
[    9.043915] sky2 0000:08:00.0: enabling device (0000 -> 0003)
[    9.049850] sky2 0000:08:00.0: Yukon-2 UL 2 chip revision 0
[    9.055639] sky2 0000:08:00.0 (unnamed net_device) (uninitialized): Invalid MAC address, defaulting to random
[    9.067331] sky2 0000:08:00.0 eth0: addr ae:19:c6:f0:10:e2
[    9.110208] libphy: smsc911x-mdio: probed
[    9.115328] smsc911x 18000000.ethernet eth1: MAC Address: 00:02:f7:00:67:bd
[    9.125648] pegasus: v0.9.3 (2013/04/25), Pegasus/Pegasus II USB Ethernet driver
[    9.133322] usbcore: registered new interface driver pegasus
[    9.139170] usbcore: registered new interface driver rtl8150
[    9.145034] usbcore: registered new interface driver r8152
[    9.150697] usbcore: registered new interface driver lan78xx
[    9.156568] usbcore: registered new interface driver asix
[    9.162135] usbcore: registered new interface driver ax88179_178a
[    9.168409] usbcore: registered new interface driver cdc_ether
[    9.174408] usbcore: registered new interface driver dm9601
[    9.180169] usbcore: registered new interface driver CoreChips
[    9.186202] usbcore: registered new interface driver smsc75xx
[    9.192194] usbcore: registered new interface driver smsc95xx
[    9.198107] usbcore: registered new interface driver net1080
[    9.203931] usbcore: registered new interface driver plusb
[    9.209590] usbcore: registered new interface driver cdc_subset
[    9.215686] usbcore: registered new interface driver zaurus
[    9.221421] usbcore: registered new interface driver MOSCHIP usb-ethernet driver
[    9.229036] usbcore: registered new interface driver cdc_ncm
[    9.235198] VFIO - User Level meta-driver version: 0.3
[    9.244049] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    9.250734] ehci-pci: EHCI PCI platform driver
[    9.255373] ehci-platform: EHCI generic platform driver
[    9.261265] ehci-platform 7ffc0000.ehci: Adding to iommu group 0
[    9.267943] ehci-platform 7ffc0000.ehci: EHCI Host Controller
[    9.273960] ehci-platform 7ffc0000.ehci: new USB bus registered, assigned bus number 1
[    9.282413] ehci-platform 7ffc0000.ehci: irq 34, io mem 0x7ffc0000
[    9.303894] ehci-platform 7ffc0000.ehci: USB 2.0 started, EHCI 1.00
[    9.312750] hub 1-0:1.0: USB hub found
[    9.316756] hub 1-0:1.0: 1 port detected
[    9.322098] ehci-orion: EHCI orion driver
[    9.326429] ehci-exynos: EHCI Exynos driver
[    9.330880] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    9.337203] ohci-pci: OHCI PCI platform driver
[    9.341844] ohci-platform: OHCI generic platform driver
[    9.347445] ohci-platform 7ffb0000.ohci: Adding to iommu group 0
[    9.353789] ohci-platform 7ffb0000.ohci: Generic Platform OHCI controller
[    9.360733] ohci-platform 7ffb0000.ohci: new USB bus registered, assigned bus number 2
[    9.369041] ohci-platform 7ffb0000.ohci: irq 33, io mem 0x7ffb0000
[    9.454060] hub 2-0:1.0: USB hub found
[    9.458002] hub 2-0:1.0: 1 port detected
[    9.462996] ohci-exynos: OHCI Exynos driver
[    9.468199] usbcore: registered new interface driver usb-storage
[    9.483090] rtc-pl031 1c170000.rtc: registered as rtc0
[    9.489863] i2c /dev entries driver
[    9.498761] usbcore: registered new interface driver uvcvideo
[    9.504616] USB Video Class driver (1.1.1)
[    9.508794] gspca_main: v2.14.0 registered
[    9.519678] sp805-wdt 1c0f0000.wdt: registration successful
[    9.528211] device-mapper: ioctl: 4.42.0-ioctl (2020-02-27) initialised: dm-devel@redhat.com
[    9.536840] Bluetooth: HCI UART driver ver 2.3
[    9.541374] Bluetooth: HCI UART protocol H4 registered
[    9.546654] Bluetooth: HCI UART protocol LL registered
[    9.552062] Bluetooth: HCI UART protocol Broadcom registered
[    9.557942] usbcore: registered new interface driver btusb
[    9.566162] mmci-pl18x 1c050000.mmci: mmc0: PL180 manf 41 rev0 at 0x1c050000 irq 9,0 (pio)
[    9.600728] sdhci: Secure Digital Host Controller Interface driver
[    9.607167] sdhci: Copyright(c) Pierre Ossman
[    9.612329] Synopsys Designware Multimedia Card Interface Driver
[    9.620229] sdhci-pltfm: SDHCI platform and OF driver helper
[    9.629527] leds-syscon 1c010000.apbregs:led0: registered LED vexpress:0
[    9.636858] leds-syscon 1c010000.apbregs:led1: registered LED vexpress:1
[    9.644123] leds-syscon 1c010000.apbregs:led2: registered LED vexpress:2
[    9.651333] leds-syscon 1c010000.apbregs:led3: registered LED vexpress:3
[    9.658549] leds-syscon 1c010000.apbregs:led4: registered LED vexpress:4
[    9.660037] usb 1-1: new high-speed USB device number 2 using ehci-platform
[    9.665756] leds-syscon 1c010000.apbregs:led5: registered LED vexpress:5
[    9.679910] leds-syscon 1c010000.apbregs:led6: registered LED vexpress:6
[    9.687122] leds-syscon 1c010000.apbregs:led7: registered LED vexpress:7
[    9.695039] ledtrig-cpu: registered to indicate activity on CPUs
[    9.704066] hub 1-1:1.0: USB hub found
[    9.704866] usbcore: registered new interface driver usbhid
[    9.708570] hub 1-1:1.0: 4 ports detected
[    9.713711] usbhid: USB HID core driver
[    9.714861] mhu 2b1f0000.mhu: ARM MHU Mailbox registered
[    9.740849] drop_monitor: Initializing network drop monitor service
[    9.751356] NET: Registered protocol family 10
[    9.752975] random: fast init done
[    9.761199] Segment Routing with IPv6
[    9.765574] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
[    9.772882] NET: Registered protocol family 17
[    9.777629] Bridge firewalling registered
[    9.781804] Bluetooth: HIDP (Human Interface Emulation) ver 1.2
[    9.787875] Bluetooth: HIDP socket layer initialized
[    9.793029] 8021q: 802.1Q VLAN Support v1.8
[    9.797718] 9pnet: Installing 9P2000 support
[    9.802205] Key type dns_resolver registered
[    9.807996] registered taskstats version 1
[    9.812243] Loading compiled-in X.509 certificates
[    9.820380] Btrfs loaded, crc32c=crc32c-generic
[    9.836554] scpi_protocol scpi: SCP Protocol 1.2 Firmware 1.21.0 version
[    9.900309] arm-smmu 2b600000.iommu: probing hardware configuration...
[    9.906999] arm-smmu 2b600000.iommu: SMMUv1 with:
[    9.911929] arm-smmu 2b600000.iommu: 	stage 2 translation
[    9.917444] arm-smmu 2b600000.iommu: 	coherent table walk
[    9.922977] arm-smmu 2b600000.iommu: 	stream matching with 2 register groups
[    9.930180] arm-smmu 2b600000.iommu: 	1 context banks (1 stage-2 only)
[    9.936853] arm-smmu 2b600000.iommu: 	Supported page sizes: 0x60211000
[    9.943495] arm-smmu 2b600000.iommu: 	Stage-2: 40-bit IPA -> 40-bit PA
[    9.953325] input: smb@8000000:motherboard:gpio-keys as /devices/platform/smb@8000000/smb@8000000:motherboard/smb@8000000:motherboard:gpio-keys/input/input1
[    9.969875] rtc-pl031 1c170000.rtc: setting system clock to 2020-03-24T13:26:36 UTC (1585056396)
[   10.280067] usb 1-1.1: new high-speed USB device number 3 using ehci-platform
[   10.325610] usb-storage 1-1.1:1.0: USB Mass Storage device detected
[   10.340148] scsi host2: usb-storage 1-1.1:1.0
[   10.503982] atkbd serio0: keyboard reset failed on 1c060000.kmi
[   10.992124] ata1: SATA link down (SStatus 0 SControl 0)
[   11.372862] scsi 2:0:0:0: Direct-Access     TOSHIBA  TransMemory      PMAP PQ: 0 ANSI: 6
[   11.385025] sd 2:0:0:0: [sda] 30253056 512-byte logical blocks: (15.5 GB/14.4 GiB)
[   11.395886] sd 2:0:0:0: [sda] Write Protect is off
[   11.400946] sd 2:0:0:0: [sda] Mode Sense: 45 00 00 00
[   11.407205] sd 2:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[   11.476739]  sda: sda1 sda2
[   11.495313] sd 2:0:0:0: [sda] Attached SCSI removable disk
[   11.751875] atkbd serio1: keyboard reset failed on 1c070000.kmi
[   13.048101] ata2: SATA link down (SStatus 0 SControl 0)
[   13.059761] sky2 0000:08:00.0 eth0: enabling interface
[   13.068686] Generic PHY 18000000.ethernet-ffffffff:01: attached PHY driver [Generic PHY] (mii_bus:phy_addr=18000000.ethernet-ffffffff:01, irq=POLL)
[   13.083104] smsc911x 18000000.ethernet eth1: SMSC911x/921x identified at 0xffff800018d90000, IRQ: 8
[   15.144751] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[   15.163932] Sending DHCP requests ., OK
[   15.300992] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
[   15.304182] ALSA device list:
[   15.309940] platform regulatory.0: Falling back to sysfs fallback for: regulatory.db
[   15.313166]   No soundcards found.
[   15.325677] uart-pl011 7ff80000.uart: no DMA platform data
[   15.381459] Freeing unused kernel memory: 14656K
[   15.576075] Run /init as init process
[   15.579784]   with arguments:
[   15.582818]     /init
[   15.585143]     ttyAMA0,115200n8
[   15.588438]     verbose
[   15.590911]     nfsrootdebug
[   15.593846]   with environment:
[   15.597044]     HOME=/
[   15.599429]     TERM=linux
[   15.602189]     user_debug=31
[   16.000277] Adding 2543608k swap on /dev/sda2.  Priority:-2 extents:1 across:2543608k 
[   18.690278] input: PS/2 Generic Mouse as /devices/platform/smb@8000000/smb@8000000:motherboard/smb@8000000:motherboard:iofpga@3,00000000/1c060000.kmi/serio0/input/input3
[   18.815258] psmouse serio0: Failed to enable mouse on 1c060000.kmi
[   20.581550] random: dd: uninitialized urandom read (512 bytes read)
[   20.695317] random: ssh-keygen: uninitialized urandom read (32 bytes read)
[   20.725071] random: sshd: uninitialized urandom read (32 bytes read)
[   20.805838] sky2 0000:08:00.0 eth0: enabling interface
[   25.641788] input: PS/2 Generic Mouse as /devices/platform/smb@8000000/smb@8000000:motherboard/smb@8000000:motherboard:iofpga@3,00000000/1c070000.kmi/serio1/input/input4
[   25.770081] psmouse serio1: Failed to enable mouse on 1c070000.kmi
[   68.871949] rcu-torture: rtc: (____ptrval____) ver: 1430 tfle: 0 rta: 1431 rtaf: 0 rtf: 1419 rtmbe: 0 rtbe: 0 rtbke: 0 rtbre: 0 rtbf: 0 rtb: 0 nt: 24137 onoff: 0/0:0/0 -1,0:-1,0 0:0 (HZ=250) barrier: 0/0:0
[   68.891859] rcu-torture: Reader Pipe:  14518041 3920 0 0 0 0 0 0 0 0 0
[   68.898567] rcu-torture: Reader Batch:  14513170 8794 0 0 0 0 0 0 0 0 0
[   68.905308] rcu-torture: Free-Block Circulation:  1430 1430 1429 1428 1426 1425 1424 1423 1421 1420 0
[   77.075919] cfg80211: failed to load regulatory.db
[   85.395510] PM: hibernation: hibernation entry
[   85.407291] Filesystems sync: 0.001 seconds
[   85.411706] Freezing user space processes ... (elapsed 0.003 seconds) done.
[   85.422153] OOM killer disabled.
[   85.432722] PM: hibernation: Preallocating image memory
[   86.962730] PM: hibernation: Allocated 97206 pages for snapshot
[   86.968783] PM: hibernation: Allocated 388824 kbytes in 1.52 seconds (255.80 MB/s)
[   86.976488] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[   86.988496] printk: Suspending console(s) (use no_console_suspend to debug)
[   87.052353] usbcore:hub_suspend: hub 1-1:1.0: hub_suspend
[   87.054920] usbcore:hub_suspend: hub 1-0:1.0: hub_suspend
[   87.055211] usbcore:hcd_bus_suspend: usb usb1: bus suspend, wakeup 0
[   87.106030] Disabling non-boot CPUs ...
[   87.115339] CPU1: shutdown
[   87.115396] psci: CPU1 killed (polled 0 ms)
[   87.124698] CPU2: shutdown
[   87.125786] psci: CPU2 killed (polled 0 ms)
[   87.142474] CPU3: shutdown
[   87.142499] psci: CPU3 killed (polled 0 ms)
[   87.158793] CPU4: shutdown
[   87.158818] psci: CPU4 killed (polled 0 ms)
[   87.170296] CPU5: shutdown
[   87.170322] psci: CPU5 killed (polled 0 ms)
[   87.181175] PM: hibernation: Creating image:
[   87.181175] PM: hibernation: Need to copy 95355 pages
[   87.181175] PM: hibernation: Image created (95355 pages copied)
[   87.181755] Enabling non-boot CPUs ...
[   87.195741] Detected PIPT I-cache on CPU1
[   87.195807] CPU1: Booted secondary processor 0x0000000000 [0x410fd080]
[   87.199267] CPU1 is up
[   87.218474] Detected PIPT I-cache on CPU2
[   87.218514] CPU2: Booted secondary processor 0x0000000001 [0x410fd080]
[   87.220090] CPU2 is up
[   87.233753] Detected VIPT I-cache on CPU3
[   87.233836] CPU3: Booted secondary processor 0x0000000101 [0x410fd033]
[   87.236870] CPU3 is up
[   87.251072] Detected VIPT I-cache on CPU4
[   87.251139] CPU4: Booted secondary processor 0x0000000102 [0x410fd033]
[   87.254256] CPU4 is up
[   87.268055] Detected VIPT I-cache on CPU5
[   87.268119] CPU5: Booted secondary processor 0x0000000103 [0x410fd033]
[   87.272310] CPU5 is up
[   87.308368] usbcore:hcd_bus_resume: usb usb1: usb resume
[   87.339802] usbcore:hcd_bus_resume: usb usb2: usb resume
[   87.370809] usbcore:hub_resume: hub 1-0:1.0: hub_resume
[   87.371148] usbcore:hub_activate: usb usb1-port1: status 0503 change 0000
[   87.371358] usbcore:hub_resume: hub 1-1:1.0: hub_resume
[   87.371785] usbcore:hub_activate: usb 1-1-port1: status 0503 change 0000
[   87.418064] usbcore:hub_resume: hub 2-0:1.0: hub_resume
[   87.418308] usb usb2: runtime PM trying to activate child device usb2 but parent (7ffb0000.ohci) is not active
[   87.622694] PM: Cannot find swap device, try swapon -a
[   87.628057] PM: Cannot get swap writer
[   88.214621] OOM killer enabled.
[   88.217943] Restarting tasks ... 
[   88.220049] usbcore:hub_event: hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0000
[   88.225181] done.
[   88.231030] usbcore:hub_event: hub 1-1:1.0: state 7 ports 4 chg 0000 evt 0000
[   88.240461] usbcore:hub_event: hub 2-0:1.0: state 7 ports 1 chg 0000 evt 0000
[   88.248053] usbcore:hub_resume: hub 2-0:1.0: hub_resume
[   88.253967] ------------[ cut here ]------------
[   88.258945] URB (____ptrval____) submitted while active
[   88.264629] WARNING: CPU: 4 PID: 379 at drivers/usb/core/urb.c:363 usb_submit_urb+0x3d8/0x590
[   88.273808] Modules linked in:
[   88.273830] CPU: 4 PID: 379 Comm: kworker/4:2 Not tainted 5.6.0-rc6-00002-gdfd1731f9a3e #541
[   88.273839] Hardware name: ARM Juno development board (r2) (DT)
[   88.273852] Workqueue: usb_hub_wq hub_event
[   88.273865] pstate: 40000005 (nZcv daif -PAN -UAO)
[   88.273876] pc : usb_submit_urb+0x3d8/0x590
[   88.273886] lr : usb_submit_urb+0x3d8/0x590
[   88.273894] sp : ffff8000190038b0
[   88.273902] x29: ffff8000190038b0 x28: 0000000000000003 
[   88.273916] x27: ffff00097050fb20 x26: ffff80001340d000 
[   88.273930] x25: ffff80001340d000 x24: ffff800019003b38 
[   88.273944] x23: 0000000000000004 x22: 0000000000000c00 
[   88.273958] x21: 0000000000000000 x20: 00000000fffffff0 
[   88.273971] x19: ffff00097046fe00 x18: ffffffffffffffff 
[   88.273986] x17: 00000000934eeaf4 x16: 00000000ad4e46a7 
[   88.273999] x15: ffff80001340da88 x14: 0720072007200720 
[   88.274013] x13: 0720072007200720 x12: 0720072007200720 
[   88.274027] x11: 0000000000000000 x10: 000000008f00fc00 
[   88.274041] x9 : 0000000000000002 x8 : ffff000970fa08a0 
[   88.274055] x7 : 0000000000000000 x6 : ffff00097ef86450 
[   88.274069] x5 : ffff00097ef86450 x4 : 0000000000000000 
[   88.274082] x3 : ffff00097ef96070 x2 : 0000000000000001 
[   88.274096] x1 : bf0dcc4e01afe000 x0 : 0000000000000000 
[   88.274110] Call trace:
[   88.274121]  usb_submit_urb+0x3d8/0x590
[   88.274131]  hub_activate+0x108/0x7f0
[   88.274140]  hub_resume+0xac/0x148
[   88.274152]  usb_resume_interface.isra.10+0x60/0x138
[   88.274163]  usb_resume_both+0xe4/0x140
[   88.274173]  usb_runtime_resume+0x24/0x30
[   88.274187]  __rpm_callback+0xdc/0x138
[   88.274197]  rpm_callback+0x34/0x98
[   88.274208]  rpm_resume+0x4a8/0x720
[   88.274218]  rpm_resume+0x50c/0x720
[   88.274229]  __pm_runtime_resume+0x4c/0xb8
[   88.274240]  usb_autopm_get_interface+0x28/0x60
[   88.274249]  hub_event+0x80/0x16d8
[   88.274262]  process_one_work+0x2a4/0x748
[   88.274273]  worker_thread+0x48/0x498
[   88.274284]  kthread+0x13c/0x140
[   88.274295]  ret_from_fork+0x10/0x18
[   88.274303] irq event stamp: 392
[   88.274318] hardirqs last  enabled at (391): [<ffff800011982754>] _raw_spin_unlock_irq+0x34/0x68
[   88.274332] hardirqs last disabled at (392): [<ffff8000100a95d0>] do_debug_exception+0x1a8/0x258
[   88.274344] softirqs last  enabled at (386): [<ffff8000100818a4>] __do_softirq+0x4bc/0x568
[   88.274355] softirqs last disabled at (375): [<ffff8000101145a4>] irq_exit+0x144/0x150
[   88.274363] ---[ end trace f4c0292c296f056a ]---
[   88.286435] hub 2-0:1.0: activate --> -16
[   88.286692] usbcore:hub_event: hub 2-0:1.0: state 7 ports 1 chg 0000 evt 0000
[   88.286765] usbcore:hub_suspend: hub 2-0:1.0: hub_suspend
[   88.287042] usbcore:hcd_bus_suspend: usb usb2: bus auto-suspend, wakeup 1
[   88.537224] PM: hibernation: hibernation exit
[   89.075447] rcu_torture_fwd_prog_nr: Duration 5043 cver 276 gps 501
[   89.311502] ata1: SATA link down (SStatus 0 SControl 0)
[   89.367552] ata2: SATA link down (SStatus 0 SControl 0)
[   89.530995] rcu_torture_fwd_prog_cr Duration 36 barrier: 29 pending 11061 n_launders: 18738 n_launders_sa: 9612 n_max_gps: 100 n_max_cbs: 14380 cver 0 gps 8
[   89.545347] rcu_torture_fwd_cb_hist: Callback-invocation histogram (duration 69 jiffies): 1s/10: 8737:5 2s/10: 24381:7
[   93.948034] psmouse serio0: Failed to enable mouse on 1c060000.kmi
[  100.793867] psmouse serio1: Failed to enable mouse on 1c070000.kmi
[  106.293706] random: sshd: uninitialized urandom read (32 bytes read)
[  106.322993] random: sshd: uninitialized urandom read (32 bytes read)
[  130.312035] rcu-torture: rtc: (____ptrval____) ver: 2453 tfle: 0 rta: 2454 rtaf: 0 rtf: 2444 rtmbe: 0 rtbe: 0 rtbke: 0 rtbre: 0 rtbf: 0 rtb: 0 nt: 48147 onoff: 0/0:0/0 -1,0:-1,0 0:0 (HZ=250) barrier: 0/0:0
[  130.331466] rcu-torture: Reader Pipe:  29178800 6720 0 0 0 0 0 0 0 0 0
[  130.338507] rcu-torture: Reader Batch:  29169686 15840 0 0 0 0 0 0 0 0 0
[  130.347485] rcu-torture: Free-Block Circulation:  2455 2454 2453 2452 2451 2450 2449 2448 2447 2446 0
[  168.979443] rcu_torture_fwd_prog_nr: Duration 4535 cver 329 gps 542
[  169.462873] rcu_torture_fwd_prog_cr Duration 42 barrier: 27 pending 5715 n_launders: 12294 n_launders_sa: 9046 n_max_gps: 100 n_max_cbs: 8946 cver 5 gps 9
[  169.477147] rcu_torture_fwd_cb_hist: Callback-invocation histogram (duration 73 jiffies): 1s/10: 3249:3 2s/10: 16026:7 3s/10: 1965:1
[  191.751468] rcu-torture: rtc: (____ptrval____) ver: 3728 tfle: 0 rta: 3729 rtaf: 0 rtf: 3717 rtmbe: 0 rtbe: 0 rtbke: 0 rtbre: 0 rtbf: 0 rtb: 0 nt: 71415 onoff: 0/0:0/0 -1,0:-1,0 0:0 (HZ=250) barrier: 0/0:0
[  191.771463] rcu-torture: Reader Pipe:  43149852 10217 0 0 0 0 0 0 0 0 0
[  191.778225] rcu-torture: Reader Batch:  43136800 23279 0 0 0 0 0 0 0 0 0
[  191.785086] rcu-torture: Free-Block Circulation:  3728 3727 3725 3723 3722 3721 3720 3719 3718 3717 0
[  215.694144] random: crng init done
[  251.559438] rcu_torture_fwd_prog_nr: Duration 5215 cver 332 gps 598
[  252.162079] rcu_torture_fwd_prog_cr Duration 56 barrier: 35 pending 5879 n_launders: 12528 n_launders_sa: 103 n_max_gps: 100 n_max_cbs: 9511 cver 6 gps 9
[  252.187444] rcu_torture_fwd_cb_hist: Callback-invocation histogram (duration 98 jiffies): 1s/10: 4198:4 2s/10: 8228:4 3s/10: 9613:4
[  253.191437] rcu-torture: rtc: 00000000cf292551 ver: 5140 tfle: 0 rta: 5141 rtaf: 0 rtf: 5127 rtmbe: 0 rtbe: 0 rtbke: 0 rtbre: 0 rtbf: 0 rtb: 0 nt: 96642 onoff: 0/0:0/0 -1,0:-1,0 0:0 (HZ=250) barrier: 0/0:0
[  253.209993] rcu-torture: Reader Pipe:  58692259 14278 0 0 0 0 0 0 0 0 0
[  253.217640] rcu-torture: Reader Batch:  58675125 31423 0 0 0 0 0 0 0 0 0
[  253.224491] rcu-torture: Free-Block Circulation:  5140 5139 5138 5136 5135 5134 5132 5131 5130 5127 0
[  314.631456] rcu-torture: rtc: 000000009d05af10 ver: 6725 tfle: 0 rta: 6726 rtaf: 0 rtf: 6715 rtmbe: 0 rtbe: 0 rtbke: 0 rtbre: 0 rtbf: 0 rtb: 0 nt: 121951 onoff: 0/0:0/0 -1,0:-1,0 0:0 (HZ=250) barrier: 0/0:0
[  314.651893] rcu-torture: Reader Pipe:  74645463 18849 0 0 0 0 0 0 0 0 0
[  314.658834] rcu-torture: Reader Batch:  74623829 40496 0 0 0 0 0 0 0 0 0
[  314.665811] rcu-torture: Free-Block Circulation:  6725 6723 6722 6721 6720 6719 6718 6717 6716 6715 0
[  333.051407] rcu_torture_fwd_prog_nr: Duration 4594 cver 321 gps 512
[  333.713547] rcu_torture_fwd_prog_cr Duration 50 barrier: 53 pending 11353 n_launders: 29003 n_launders_sa: 317 n_max_gps: 100 n_max_cbs: 28989 cver 7 gps 9
[  333.727825] rcu_torture_fwd_cb_hist: Callback-invocation histogram (duration 107 jiffies): 1s/10: 10585:5 2s/10: 34728:4 3s/10: 12679:3
[  376.071467] rcu-torture: rtc: 00000000d7f79419 ver: 7994 tfle: 0 rta: 7995 rtaf: 0 rtf: 7983 rtmbe: 0 rtbe: 0 rtbke: 0 rtbre: 0 rtbf: 0 rtb: 0 nt: 147180 onoff: 0/0:0/0 -1,0:-1,0 0:0 (HZ=250) barrier: 0/0:0
[  376.091417] rcu-torture: Reader Pipe:  90164393 22480 0 0 0 0 0 0 0 0 0
[  376.098188] rcu-torture: Reader Batch:  90139122 47764 0 0 0 0 0 0 0 0 0
[  376.105006] rcu-torture: Free-Block Circulation:  7994 7993 7992 7991 7990 7989 7988 7986 7985 7983 0
[  419.103457] rcu_torture_fwd_prog_nr: Duration 5609 cver 364 gps 827
[  419.623718] rcu_torture_fwd_prog_cr Duration 50 barrier: 33 pending 6786 n_launders: 29745 n_launders_sa: 102 n_max_gps: 100 n_max_cbs: 22162 cver 8 gps 12
[  419.637804] rcu_torture_fwd_cb_hist: Callback-invocation histogram (duration 86 jiffies): 1s/10: 13487:5 2s/10: 30939:7 3s/10: 7481:2
[  437.511566] rcu-torture: rtc: 00000000acae9a3a ver: 9408 tfle: 0 rta: 9408 rtaf: 0 rtf: 9399 rtmbe: 0 rtbe: 0 rtbke: 0 rtbre: 0 rtbf: 0 rtb: 0 nt: 171889 onoff: 0/0:0/0 -1,0:-1,0 0:0 (HZ=250) barrier: 0/0:0
[  437.530207] rcu-torture: Reader Pipe:  105326024 26408 0 0 0 0 0 0 0 0 0
[  437.537399] rcu-torture: Reader Batch:  105296742 55707 0 0 0 0 0 0 0 0 0
[  437.544516] rcu-torture: Free-Block Circulation:  9407 9407 9406 9405 9404 9403 9402 9401 9400 9399 0
[  448.227482] cpufreq: __target_index: Failed to change cpu frequency: -5
[  448.283466] cpufreq: __target_index: Failed to change cpu frequency: -5
[  448.343464] cpufreq: __target_index: Failed to change cpu frequency: -5
[  498.767427] rcu_torture_fwd_prog_nr: Duration 4043 cver 314 gps 482
[  498.955449] rcu-torture: rtc: 000000006f4ac24b ver: 10838 tfle: 0 rta: 10839 rtaf: 0 rtf: 10824 rtmbe: 0 rtbe: 0 rtbke: 0 rtbre: 0 rtbf: 0 rtb: 0 nt: 199047 onoff: 0/0:0/0 -1,0:-1,0 0:0 (HZ=250) barrier: 0/0:0
[  498.974351] rcu-torture: Reader Pipe:  122211400 30464 0 0 0 0 0 0 0 0 0
[  498.981281] rcu-torture: Reader Batch:  122177972 63909 0 0 0 0 0 0 0 0 0
[  498.988223] rcu-torture: Free-Block Circulation:  10838 10837 10836 10835 10834 10833 10831 10828 10825 10824 0
[  499.193895] rcu_torture_fwd_prog_cr Duration 34 barrier: 24 pending 15388 n_launders: 32067 n_launders_sa: 7102 n_max_gps: 100 n_max_cbs: 20880 cver 1 gps 10
[  499.208156] rcu_torture_fwd_cb_hist: Callback-invocation histogram (duration 62 jiffies): 1s/10: 21050:6 2s/10: 31897:8
[  560.391467] rcu-torture: rtc: 000000006fac79f9 ver: 12420 tfle: 0 rta: 12420 rtaf: 0 rtf: 12407 rtmbe: 0 rtbe: 0 rtbke: 0 rtbre: 0 rtbf: 0 rtb: 0 nt: 224178 onoff: 0/0:0/0 -1,0:-1,0 0:0 (HZ=250) barrier: 0/0:0
[  560.410615] rcu-torture: Reader Pipe:  137980786 35026 0 0 0 0 0 0 0 0 0
[  560.417610] rcu-torture: Reader Batch:  137942800 73030 0 0 0 0 0 0 0 0 0
[  560.424675] rcu-torture: Free-Block Circulation:  12422 12419 12417 12416 12414 12412 12411 12410 12409 12408 0
[  585.963407] rcu_torture_fwd_prog_nr: Duration 5362 cver 311 gps 604
[  586.427747] rcu_torture_fwd_prog_cr Duration 30 barrier: 36 pending 12966 n_launders: 15864 n_launders_sa: 6592 n_max_gps: 100 n_max_cbs: 14363 cver 6 gps 7
[  586.442133] rcu_torture_fwd_cb_hist: Callback-invocation histogram (duration 69 jiffies): 1s/10: 9273:6 2s/10: 20954:4
[  621.831497] rcu-torture: rtc: 0000000088efe1d5 ver: 13771 tfle: 0 rta: 13772 rtaf: 0 rtf: 13760 rtmbe: 0 rtbe: 0 rtbke: 0 rtbre: 0 rtbf: 0 rtb: 0 nt: 249276 onoff: 0/0:0/0 -1,0:-1,0 0:0 (HZ=250) barrier: 0/0:0
[  621.851423] rcu-torture: Reader Pipe:  153460629 38916 0 0 0 0 0 0 0 0 0
[  621.858293] rcu-torture: Reader Batch:  153418888 80677 0 0 0 0 0 0 0 0 0
[  621.865261] rcu-torture: Free-Block Circulation:  13771 13770 13768 13767 13765 13764 13763 13762 13761 13760 0
[  657.427423] rcu_torture_fwd_prog_nr: Duration 2236 cver 166 gps 264
[  657.979270] rcu_torture_fwd_prog_cr Duration 36 barrier: 42 pending 14533 n_launders: 24368 n_launders_sa: 1 n_max_gps: 100 n_max_cbs: 14535 cver 6 gps 9
[  657.993374] rcu_torture_fwd_cb_hist: Callback-invocation histogram (duration 82 jiffies): 1s/10: 15341:6 2s/10: 23562:6
[  683.275456] rcu-torture: rtc: 000000006c6fda6a ver: 15243 tfle: 0 rta: 15243 rtaf: 0 rtf: 15231 rtmbe: 0 rtbe: 0 rtbke: 0 rtbre: 0 rtbf: 0 rtb: 0 nt: 274134 onoff: 0/0:0/0 -1,0:-1,0 0:0 (HZ=250) barrier: 0/0:0
[  683.294353] rcu-torture: Reader Pipe:  168823340 43102 0 0 0 0 0 0 0 0 0
[  683.303434] rcu-torture: Reader Batch:  168777355 89107 0 0 0 0 0 0 0 0 0
[  683.310384] rcu-torture: Free-Block Circulation:  15243 15242 15241 15240 15239 15238 15237 15236 15235 15234 0
[  744.711488] rcu-torture: rtc: 000000009d05af10 ver: 16532 tfle: 0 rta: 16533 rtaf: 0 rtf: 16522 rtmbe: 0 rtbe: 0 rtbke: 0 rtbre: 0 rtbf: 0 rtb: 0 nt: 298520 onoff: 0/0:0/0 -1,0:-1,0 0:0 (HZ=250) barrier: 0/0:0
[  744.730630] rcu-torture: Reader Pipe:  183621702 46641 0 0 0 0 0 0 0 0 0
[  744.737674] rcu-torture: Reader Batch:  183571809 96556 0 0 0 0 0 0 0 0 0
[  744.744775] rcu-torture: Free-Block Circulation:  16532 16531 16530 16529 16528 16527 16526 16525 16524 16523 0
[  745.895408] rcu_torture_fwd_prog_nr: Duration 6429 cver 360 gps 742
[  746.343098] rcu_torture_fwd_prog_cr Duration 36 barrier: 29 pending 11544 n_launders: 21556 n_launders_sa: 12255 n_max_gps: 100 n_max_cbs: 15596 cver 5 gps 9
[  746.358669] rcu_torture_fwd_cb_hist: Callback-invocation histogram (duration 69 jiffies): 1s/10: 11069:6 2s/10: 26083:6
[  806.151563] rcu-torture: rtc: 00000000a00e51a8 ver: 17936 tfle: 0 rta: 17937 rtaf: 0 rtf: 17925 rtmbe: 0 rtbe: 0 rtbke: 0 rtbre: 0 rtbf: 0 rtb: 0 nt: 323365 onoff: 0/0:0/0 -1,0:-1,0 0:0 (HZ=250) barrier: 0/0:0
[  806.170711] rcu-torture: Reader Pipe:  199004925 50650 0 0 0 0 0 0 0 0 0
[  806.177745] rcu-torture: Reader Batch:  198950674 104922 0 0 0 0 0 0 0 0 0
[  806.184879] rcu-torture: Free-Block Circulation:  17937 17936 17935 17932 17931 17930 17929 17928 17927 17926 0
[  820.059424] rcu_torture_fwd_prog_nr: Duration 2953 cver 193 gps 314
[  820.587381] rcu_torture_fwd_prog_cr Duration 34 barrier: 30 pending 7052 n_launders: 17731 n_launders_sa: 103 n_max_gps: 100 n_max_cbs: 18574 cver 6 gps 11
[  820.601711] rcu_torture_fwd_cb_hist: Callback-invocation histogram (duration 68 jiffies): 1s/10: 17629:7 2s/10: 18676:6
[  867.591480] rcu-torture: rtc: 000000007015fe2e ver: 19268 tfle: 0 rta: 19269 rtaf: 0 rtf: 19255 rtmbe: 0 rtbe: 0 rtbke: 0 rtbre: 0 rtbf: 0 rtb: 0 nt: 347779 onoff: 0/0:0/0 -1,0:-1,0 0:0 (HZ=250) barrier: 0/0:0
[  867.611453] rcu-torture: Reader Pipe:  213932998 54453 0 0 0 0 0 0 0 0 0
[  867.618330] rcu-torture: Reader Batch:  213874751 112723 0 0 0 0 0 0 0 0 0
[  867.625335] rcu-torture: Free-Block Circulation:  19269 19268 19267 19265 19264 19263 19262 19261 19259 19256 0
[  891.535435] rcu_torture_fwd_prog_nr: Duration 2397 cver 192 gps 316
[  891.997923] rcu_torture_fwd_prog_cr Duration 38 barrier: 29 pending 10717 n_launders: 19422 n_launders_sa: 185 n_max_gps: 100 n_max_cbs: 14935 cver 8 gps 10
[  892.012309] rcu_torture_fwd_cb_hist: Callback-invocation histogram (duration 71 jiffies): 1s/10: 13052:7 2s/10: 21305:6
[  929.031526] rcu-torture: rtc: 00000000950ec0d1 ver: 20738 tfle: 0 rta: 20738 rtaf: 0 rtf: 20729 rtmbe: 0 rtbe: 0 rtbke: 0 rtbre: 0 rtbf: 0 rtb: 0 nt: 373451 onoff: 0/0:0/0 -1,0:-1,0 0:0 (HZ=250) barrier: 0/0:0
[  929.050430] rcu-torture: Reader Pipe:  229637192 58557 0 0 0 0 0 0 0 0 0
[  929.057299] rcu-torture: Reader Batch:  229574549 121227 0 0 0 0 0 0 0 0 0
[  929.064321] rcu-torture: Free-Block Circulation:  20737 20737 20736 20735 20734 20733 20732 20731 20730 20729 0
[  983.239440] rcu_torture_fwd_prog_nr: Duration 6374 cver 392 gps 771
[  983.699796] rcu_torture_fwd_prog_cr Duration 20 barrier: 32 pending 7084 n_launders: 10068 n_launders_sa: 101 n_max_gps: 100 n_max_cbs: 10233 cver 4 gps 7
[  983.713981] rcu_torture_fwd_cb_hist: Callback-invocation histogram (duration 55 jiffies): 1s/10: 16621:8 2s/10: 3680:2
[  990.471456] rcu-torture: rtc: 00000000a00e51a8 ver: 22144 tfle: 0 rta: 22145 rtaf: 0 rtf: 22132 rtmbe: 0 rtbe: 0 rtbke: 0 rtbre: 0 rtbf: 0 rtb: 0 nt: 398547 onoff: 0/0:0/0 -1,0:-1,0 0:0 (HZ=250) barrier: 0/0:0
[  990.490361] rcu-torture: Reader Pipe:  245038234 62427 0 0 0 0 0 0 0 0 0
[  990.497269] rcu-torture: Reader Batch:  244971458 129230 0 0 0 0 0 0 0 0 0
[  990.504295] rcu-torture: Free-Block Circulation:  22144 22144 22143 22142 22141 22140 22139 22137 22136 22134 0
[ 1051.911438] rcu-torture: rtc: 00000000a2033ded ver: 23556 tfle: 0 rta: 23557 rtaf: 0 rtf: 23543 rtmbe: 0 rtbe: 0 rtbke: 0 rtbre: 0 rtbf: 0 rtb: 0 nt: 422979 onoff: 0/0:0/0 -1,0:-1,0 0:0 (HZ=250) barrier: 0/0:0
[ 1051.930353] rcu-torture: Reader Pipe:  260300077 66370 0 0 0 0 0 0 0 0 0
[ 1051.937224] rcu-torture: Reader Batch:  260229042 137435 0 0 0 0 0 0 0 0 0
[ 1051.944304] rcu-torture: Free-Block Circulation:  23556 23556 23555 23554 23552 23551 23550 23548 23547 23546 0
[ 1057.235408] rcu_torture_fwd_prog_nr: Duration 2860 cver 183 gps 316
[ 1057.620007] rcu_torture_fwd_prog_cr Duration 33 barrier: 25 pending 16028 n_launders: 28240 n_launders_sa: 4401 n_max_gps: 100 n_max_cbs: 21616 cver 0 gps 8
[ 1057.634176] rcu_torture_fwd_cb_hist: Callback-invocation histogram (duration 61 jiffies): 1s/10: 20966:6 2s/10: 28890:5
[ 1113.351453] rcu-torture: rtc: 00000000e7866be4 ver: 25042 tfle: 0 rta: 25043 rtaf: 0 rtf: 25031 rtmbe: 0 rtbe: 0 rtbke: 0 rtbre: 0 rtbf: 0 rtb: 0 nt: 447783 onoff: 0/0:0/0 -1,0:-1,0 0:0 (HZ=250) barrier: 0/0:0
[ 1113.371458] rcu-torture: Reader Pipe:  275866686 70632 0 0 0 0 0 0 0 0 0
[ 1113.378316] rcu-torture: Reader Batch:  275791374 145975 0 0 0 0 0 0 0 0 0
[ 1113.385344] rcu-torture: Free-Block Circulation:  25042 25041 25040 25039 25038 25037 25036 25033 25032 25031 0
[ 1141.035410] rcu_torture_fwd_prog_nr: Duration 4864 cver 241 gps 482
[ 1141.438910] rcu_torture_fwd_prog_cr Duration 25 barrier: 27 pending 11862 n_launders: 12518 n_launders_sa: 0 n_max_gps: 100 n_max_cbs: 11864 cver 3 gps 8
[ 1141.453265] rcu_torture_fwd_cb_hist: Callback-invocation histogram (duration 56 jiffies): 1s/10: 12316:8 2s/10: 12066:2
[ 1174.791496] rcu-torture: rtc: 00000000b3cbeac9 ver: 26410 tfle: 0 rta: 26411 rtaf: 0 rtf: 26401 rtmbe: 0 rtbe: 0 rtbke: 0 rtbre: 0 rtbf: 0 rtb: 0 nt: 473097 onoff: 0/0:0/0 -1,0:-1,0 0:0 (HZ=250) barrier: 0/0:0
[ 1174.810663] rcu-torture: Reader Pipe:  291515904 74558 0 0 0 0 0 0 0 0 0
[ 1174.817647] rcu-torture: Reader Batch:  291436558 153934 0 0 0 0 0 0 0 0 0
[ 1174.824783] rcu-torture: Free-Block Circulation:  26411 26410 26409 26408 26407 26406 26405 26404 26403 26402 0
[ 1199.467463] cpufreq: __target_index: Failed to change cpu frequency: -5
[ 1199.523431] cpufreq: __target_index: Failed to change cpu frequency: -5
[ 1199.579444] cpufreq: __target_index: Failed to change cpu frequency: -5
[ 1199.631442] cpufreq: __target_index: Failed to change cpu frequency: -5
[ 1199.683444] cpufreq: __target_index: Failed to change cpu frequency: -5
[ 1213.751408] rcu_torture_fwd_prog_nr: Duration 2561 cver 156 gps 272
[ 1214.493676] rcu_torture_fwd_prog_cr Duration 64 barrier: 75 pending 6309 n_launders: 28428 n_launders_sa: 9192 n_max_gps: 100 n_max_cbs: 44878 cver 12 gps 14
[ 1214.511007] rcu_torture_fwd_cb_hist: Callback-invocation histogram (duration 143 jiffies): 1s/10: 4946:4 2s/10: 34203:4 3s/10: 34157:8
[ 1236.231477] rcu-torture: rtc: 00000000291363a7 ver: 27745 tfle: 0 rta: 27746 rtaf: 0 rtf: 27732 rtmbe: 0 rtbe: 0 rtbke: 0 rtbre: 0 rtbf: 0 rtb: 0 nt: 498035 onoff: 0/0:0/0 -1,0:-1,0 0:0 (HZ=250) barrier: 0/0:0
[ 1236.251425] rcu-torture: Reader Pipe:  306958447 78330 0 0 0 0 0 0 0 0 0
[ 1236.258568] rcu-torture: Reader Batch:  306874956 161854 0 0 0 0 0 0 0 0 0
[ 1236.265608] rcu-torture: Free-Block Circulation:  27745 27742 27741 27740 27739 27737 27736 27735 27734 27732 0
[ 1288.855420] rcu_torture_fwd_prog_nr: Duration 2910 cver 150 gps 450
[ 1289.193347] rcu_torture_fwd_prog_cr Duration 27 barrier: 18 pending 9130 n_launders: 19196 n_launders_sa: 13850 n_max_gps: 100 n_max_cbs: 13749 cver 0 gps 9
[ 1289.207581] rcu_torture_fwd_cb_hist: Callback-invocation histogram (duration 49 jiffies): 1s/10: 19096:8 2s/10: 13849:3
[ 1297.671545] rcu-torture: rtc: 0000000089bba9ca ver: 29158 tfle: 0 rta: 29158 rtaf: 0 rtf: 29148 rtmbe: 0 rtbe: 0 rtbke: 0 rtbre: 0 rtbf: 0 rtb: 0 nt: 522215 onoff: 0/0:0/0 -1,0:-1,0 0:0 (HZ=250) barrier: 0/0:0
[ 1297.690658] rcu-torture: Reader Pipe:  321974523 82313 0 0 0 0 0 0 0 0 0
[ 1297.697706] rcu-torture: Reader Batch:  321886741 170129 0 0 0 0 0 0 0 0 0
[ 1297.704924] rcu-torture: Free-Block Circulation:  29160 29159 29158 29157 29156 29155 29154 29153 29152 29150 0
[ 1359.111511] rcu-torture: rtc: 000000001bdbf93f ver: 30625 tfle: 0 rta: 30626 rtaf: 0 rtf: 30614 rtmbe: 0 rtbe: 0 rtbke: 0 rtbre: 0 rtbf: 0 rtb: 0 nt: 547332 onoff: 0/0:0/0 -1,0:-1,0 0:0 (HZ=250) barrier: 0/0:0
[ 1359.130654] rcu-torture: Reader Pipe:  337720601 86544 0 0 0 0 0 0 0 0 0
[ 1359.137675] rcu-torture: Reader Batch:  337628286 178893 0 0 0 0 0 0 0 0 0
[ 1359.144854] rcu-torture: Free-Block Circulation:  30627 30625 30624 30623 30622 30621 30620 30619 30618 30616 0
[ 1370.903433] rcu_torture_fwd_prog_nr: Duration 4991 cver 259 gps 574
[ 1371.417591] rcu_torture_fwd_prog_cr Duration 41 barrier: 32 pending 8114 n_launders: 13569 n_launders_sa: 427 n_max_gps: 100 n_max_cbs: 14569 cver 6 gps 8
[ 1371.431856] rcu_torture_fwd_cb_hist: Callback-invocation histogram (duration 77 jiffies): 1s/10: 4875:4 2s/10: 22835:6 3s/10: 428:1
[ 1420.551661] rcu-torture: rtc: 00000000a439da5b ver: 31971 tfle: 0 rta: 31971 rtaf: 0 rtf: 31962 rtmbe: 0 rtbe: 0 rtbke: 0 rtbre: 0 rtbf: 0 rtb: 0 nt: 572674 onoff: 0/0:0/0 -1,0:-1,0 0:0 (HZ=250) barrier: 0/0:0
[ 1420.570631] rcu-torture: Reader Pipe:  353218469 90358 0 0 0 0 0 0 0 0 0
[ 1420.577546] rcu-torture: Reader Batch:  353122253 186608 0 0 0 0 0 0 0 0 0
[ 1420.584565] rcu-torture: Free-Block Circulation:  31970 31970 31969 31968 31967 31966 31965 31964 31963 31962 0
[ 1443.575634] rcu_torture_fwd_prog_nr: Duration 2677 cver 197 gps 307
[ 1444.229871] rcu_torture_fwd_prog_cr Duration 69 barrier: 41 pending 8749 n_launders: 47293 n_launders_sa: 40732 n_max_gps: 100 n_max_cbs: 28517 cver 4 gps 13
[ 1444.263240] rcu_torture_fwd_cb_hist: Callback-invocation histogram (duration 118 jiffies): 1s/10: 6562:3 2s/10: 36657:5 3s/10: 30190:6 4s/10: 2401:2
[ 1481.991457] rcu-torture: rtc: 00000000babfc60e ver: 33433 tfle: 0 rta: 33433 rtaf: 0 rtf: 33423 rtmbe: 0 rtbe: 0 rtbke: 0 rtbre: 0 rtbf: 0 rtb: 0 nt: 598519 onoff: 0/0:0/0 -1,0:-1,0 0:0 (HZ=250) barrier: 0/0:0
[ 1482.010374] rcu-torture: Reader Pipe:  369283515 94426 0 0 0 0 0 0 0 0 0
[ 1482.017538] rcu-torture: Reader Batch:  369182893 195081 0 0 0 0 0 0 0 0 0
[ 1482.024735] rcu-torture: Free-Block Circulation:  33433 33432 33431 33430 33429 33428 33427 33426 33425 33424 0
[ 1487.891535] Adding 2543608k swap on /dev/sda2.  Priority:-2 extents:1 across:2543608k 
[ 1506.901112] PM: hibernation: hibernation entry
[ 1506.908948] Filesystems sync: 0.000 seconds
[ 1506.913461] Freezing user space processes ... (elapsed 0.004 seconds) done.
[ 1506.925595] OOM killer disabled.
[ 1506.933280] PM: hibernation: Preallocating image memory
[ 1508.326491] PM: hibernation: Allocated 97058 pages for snapshot
[ 1508.332547] PM: hibernation: Allocated 388232 kbytes in 1.38 seconds (281.32 MB/s)
[ 1508.340256] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[ 1508.351931] printk: Suspending console(s) (use no_console_suspend to debug)
[ 1508.396262] usbcore:hub_suspend: hub 1-1:1.0: hub_suspend
[ 1508.398618] usbcore:hub_suspend: hub 1-0:1.0: hub_suspend
[ 1508.398702] usbcore:hcd_bus_suspend: usb usb1: bus suspend, wakeup 0
[ 1508.454532] Disabling non-boot CPUs ...
[ 1508.457758] CPU1: shutdown
[ 1508.457772] psci: CPU1 killed (polled 0 ms)
[ 1508.466944] CPU2: shutdown
[ 1508.468030] psci: CPU2 killed (polled 4 ms)
[ 1508.473377] CPU3: shutdown
[ 1508.473401] psci: CPU3 killed (polled 0 ms)
[ 1508.497978] CPU4: shutdown
[ 1508.498002] psci: CPU4 killed (polled 0 ms)
[ 1508.515008] CPU5: shutdown
[ 1508.515032] psci: CPU5 killed (polled 0 ms)
[ 1508.516800] PM: hibernation: Creating image:
[ 1508.516800] PM: hibernation: Need to copy 95831 pages
[ 1508.516800] PM: hibernation: Image created (95831 pages copied)
[ 1508.516989] Enabling non-boot CPUs ...
[ 1508.530874] Detected PIPT I-cache on CPU1
[ 1508.530938] CPU1: Booted secondary processor 0x0000000000 [0x410fd080]
[ 1508.533432] CPU1 is up
[ 1508.547085] Detected PIPT I-cache on CPU2
[ 1508.547124] CPU2: Booted secondary processor 0x0000000001 [0x410fd080]
[ 1508.548734] CPU2 is up
[ 1508.562597] Detected VIPT I-cache on CPU3
[ 1508.562680] CPU3: Booted secondary processor 0x0000000101 [0x410fd033]
[ 1508.565722] CPU3 is up
[ 1508.579511] Detected VIPT I-cache on CPU4
[ 1508.579577] CPU4: Booted secondary processor 0x0000000102 [0x410fd033]
[ 1508.582624] CPU4 is up
[ 1508.596422] Detected VIPT I-cache on CPU5
[ 1508.596484] CPU5: Booted secondary processor 0x0000000103 [0x410fd033]
[ 1508.599819] CPU5 is up
[ 1508.635427] usbcore:hcd_bus_resume: usb usb1: usb resume
[ 1508.663949] usbcore:hcd_bus_resume: usb usb2: usb resume
[ 1508.698488] usbcore:hub_resume: hub 1-0:1.0: hub_resume
[ 1508.698684] usbcore:hub_activate: usb usb1-port1: status 0503 change 0000
[ 1508.698960] usbcore:hub_resume: hub 1-1:1.0: hub_resume
[ 1508.699424] usbcore:hub_activate: usb 1-1-port1: status 0503 change 0000
[ 1508.744319] usbcore:hub_resume: hub 2-0:1.0: hub_resume
[ 1508.744535] usb usb2: runtime PM trying to activate child device usb2 but parent (7ffb0000.ohci) is not active
[ 1508.952296] hibernate: Hibernating on CPU 0 [mpidr:0x100]
[ 1509.029654] PM: Using 3 thread(s) for compression
[ 1509.034501] PM: Compressing and saving image data (96019 pages)...
[ 1509.040930] PM: Image saving progress:   0%
[ 1510.695439] ata1: SATA link down (SStatus 0 SControl 0)
[ 1510.700971] ata2: SATA link down (SStatus 0 SControl 0)
[ 1514.118386] PM: Image saving progress:  10%
[ 1514.281248] PM: Image saving progress:  20%
[ 1514.352696] PM: Image saving progress:  30%
[ 1515.313655] psmouse serio0: Failed to enable mouse on 1c060000.kmi
[ 1517.074193] PM: Image saving progress:  40%
[ 1521.275281] PM: Image saving progress:  50%
[ 1521.985264] psmouse serio1: Failed to enable mouse on 1c070000.kmi
[ 1523.463876] ------------[ cut here ]------------
[ 1523.468620] WARNING: CPU: 3 PID: 261 at kernel/rcu/rcutorture.c:1055 rcu_torture_writer+0x664/0xa90
[ 1523.477854] Modules linked in:
[ 1523.480989] CPU: 3 PID: 261 Comm: rcu_torture_wri Tainted: G        W         5.6.0-rc6-00002-gdfd1731f9a3e #541
[ 1523.491374] Hardware name: ARM Juno development board (r2) (DT)
[ 1523.497421] pstate: 00000005 (nzcv daif -PAN -UAO)
[ 1523.502318] pc : rcu_torture_writer+0x664/0xa90
[ 1523.506950] lr : rcu_torture_writer+0x65c/0xa90
[ 1523.511579] sp : ffff800018c4bde0
[ 1523.514970] x29: ffff800018c4bde0 x28: ffff80001426e200 
[ 1523.520401] x27: ffff80001426cf08 x26: ffff80001426cf08 
[ 1523.525832] x25: ffff8000121b5000 x24: 0000000000000001 
[ 1523.531264] x23: ffff80001426d648 x22: ffff80001426b000 
[ 1523.536694] x21: ffff800013439000 x20: ffff80001426e938 
[ 1523.542125] x19: ffff80001426c000 x18: 00000000fffffffd 
[ 1523.547555] x17: dc1a0015bd1a0108 x16: 102d7c245e000f18 
[ 1523.552986] x15: 8003952700001b91 x14: 80003abf2549fc26 
[ 1523.558418] x13: 1a00a41000240120 x12: 0000000000000003 
[ 1523.563848] x11: 0000000000003b06 x10: 0000000000000000 
[ 1523.569279] x9 : ffff800013a130a0 x8 : ffff0009750d3750 
[ 1523.574710] x7 : 0000000000000000 x6 : ffff800018c4bd20 
[ 1523.580140] x5 : 0000000000000001 x4 : 0000000000000000 
[ 1523.585571] x3 : 0000000000000080 x2 : 0000000002611501 
[ 1523.591001] x1 : 0000000000000000 x0 : 0000000000000001 
[ 1523.596431] Call trace:
[ 1523.598940]  rcu_torture_writer+0x664/0xa90
[ 1523.603220]  kthread+0x13c/0x140
[ 1523.606527]  ret_from_fork+0x10/0x18
[ 1523.610184] irq event stamp: 1104256
[ 1523.613846] hardirqs last  enabled at (1104255): [<ffff8000101beb4c>] call_rcu+0xec/0x1e0
[ 1523.622201] hardirqs last disabled at (1104256): [<ffff8000100a95d0>] do_debug_exception+0x1a8/0x258
[ 1523.631528] softirqs last  enabled at (1104250): [<ffff8000101ba304>] rcu_torture_writer+0x28c/0xa90
[ 1523.640854] softirqs last disabled at (1104248): [<ffff8000101ba2b8>] rcu_torture_writer+0x240/0xa90
[ 1523.650174] ---[ end trace f4c0292c296f056b ]---
[ 1525.952260] rcu_torture_fwd_prog_nr: Duration 4836 cver 442 gps 555
[ 1526.364916] rcu_torture_fwd_prog_cr Duration 35 barrier: 30 pending 14089 n_launders: 20949 n_launders_sa: 7854 n_max_gps: 100 n_max_cbs: 14938 cver 3 gps 11
[ 1526.379365] rcu_torture_fwd_cb_hist: Callback-invocation histogram (duration 69 jiffies): 1s/10: 13096:7 2s/10: 22791:7
[ 1529.173844] PM: Image saving progress:  60%
[ 1529.641286] PM: Image saving progress:  70%
[ 1533.819717] PM: Image saving progress:  80%
[ 1539.807208] PM: Image saving progress:  90%
[ 1540.289830] PM: Image saving progress: 100%
[ 1540.299999] PM: Image saving done
[ 1540.303543] PM: hibernation: Wrote 384076 kbytes in 31.25 seconds (12.29 MB/s)
[ 1540.316607] PM: S|
[ 1540.623981] printk: Suspending console(s) (use no_console_suspend to debug)
[ 1540.660035] usbcore:usb_port_suspend: usb 1-1.1: usb suspend, wakeup 0
[ 1540.660198] usbcore:hub_suspend: hub 1-1:1.0: hub_suspend
[ 1540.662500] usbcore:usb_port_suspend: usb 1-1: usb suspend, wakeup 0
[ 1540.744669] psmouse serio1: Failed to disable mouse on 1c070000.kmi
[ 1541.071650] psmouse serio0: Failed to disable mouse on 1c060000.kmi
[ 1541.293276] usbcore:hub_suspend: hub 2-0:1.0: hub_suspend
[ 1541.293428] usbcore:hcd_bus_suspend: usb usb2: bus suspend, wakeup 0
[ 1541.294019] usbcore:hub_suspend: hub 1-0:1.0: hub_suspend
[ 1541.294626] usbcore:hcd_bus_suspend: usb usb1: bus suspend, wakeup 0
[ 1541.672882] Disabling non-boot CPUs ...
[ 1541.677863] CPU1: shutdown
[ 1541.677892] psci: CPU1 killed (polled 0 ms)
[ 1541.683584] CPU2: shutdown
[ 1541.684659] psci: CPU2 killed (polled 0 ms)
[ 1541.698413] CPU3: shutdown
[ 1541.698437] psci: CPU3 killed (polled 0 ms)
[ 1541.703558] CPU4: shutdown
[ 1541.703581] psci: CPU4 killed (polled 0 ms)
[ 1541.709947] CPU5: shutdown
[ 1541.709971] psci: CPU5 killed (polled 0 ms)
[ 1541.712919] Enabling non-boot CPUs ...
[ 1541.728562] Detected PIPT I-cache on CPU1
[ 1541.728623] CPU1: Booted secondary processor 0x0000000000 [0x410fd080]
[ 1541.731362] CPU1 is up
[ 1541.745968] Detected PIPT I-cache on CPU2
[ 1541.746007] CPU2: Booted secondary processor 0x0000000001 [0x410fd080]
[ 1541.747593] CPU2 is up
[ 1541.761801] Detected VIPT I-cache on CPU3
[ 1541.761881] CPU3: Booted secondary processor 0x0000000101 [0x410fd033]
[ 1541.765426] CPU3 is up
[ 1541.779111] Detected VIPT I-cache on CPU4
[ 1541.779176] CPU4: Booted secondary processor 0x0000000102 [0x410fd033]
[ 1541.782619] CPU4 is up
[ 1541.796272] Detected VIPT I-cache on CPU5
[ 1541.796337] CPU5: Booted secondary processor 0x0000000103 [0x410fd033]
[ 1541.800310] CPU5 is up
[ 1542.140492] usbcore:hcd_bus_resume: usb usb1: usb resume
[ 1542.175352] usbcore:hcd_bus_resume: usb usb2: usb resume
[ 1542.202449] usbcore:hub_resume: hub 1-0:1.0: hub_resume
[ 1542.202641] usbcore:hub_activate: usb usb1-port1: status 0503 change 0000
[ 1542.203370] usbcore:wait_for_connected: usb 1-1: Waited 0ms for CONNECT
[ 1542.203396] usbcore:finish_port_resume: usb 1-1: finish resume
[ 1542.203766] usbcore:hub_resume: hub 1-1:1.0: hub_resume
[ 1542.203980] usbcore:hub_activate: usb 1-1-port1: status 0503 change 0000
[ 1542.205097] usbcore:wait_for_connected: usb 1-1.1: Waited 0ms for CONNECT
[ 1542.205110] usbcore:finish_port_resume: usb 1-1.1: finish resume
[ 1542.259265] usbcore:hub_resume: hub 2-0:1.0: hub_resume
[ 1542.259393] usb usb2: runtime PM trying to activate child device usb2 but parent (7ffb0000.ohci) is not active
[ 1543.431275] rcu-torture: rtc: 0000000005e1898f ver: 35307 tfle: 0 rta: 35308 rtaf: 0 rtf: 35298 rtmbe: 0 rtbe: 0 rtbke: 0 rtbre: 0 rtbf: 0 rtb: 0 nt: 623130 onoff: 0/0:0/0 -1,0:-1,0 0:0 (HZ=250) barrier: 0/0:0
[ 1543.431302] rcu-torture: Reader Pipe:  384476031 99661 0 0 0 0 0 0 0 0 0
[ 1543.431333] rcu-torture: Reader Batch:  384372023 203703 0 0 0 0 0 0 0 0 0
[ 1543.431363] rcu-torture: Free-Block Circulation:  35307 35306 35305 35304 35303 35302 35301 35300 35299 35298 0
[ 1544.195320] ata2: SATA link down (SStatus 0 SControl 0)
[ 1544.195401] ata1: SATA link down (SStatus 0 SControl 0)
[ 1548.761974] psmouse serio0: Failed to enable mouse on 1c060000.kmi
[ 1555.407092] psmouse serio1: Failed to enable mouse on 1c070000.kmi
[ 1557.844726] OOM killer enabled.
[ 1557.847957] Restarting tasks ... 
[ 1557.848416] usbcore:hub_event: hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0000
[ 1557.848578] usbcore:hub_event: hub 2-0:1.0: state 7 ports 1 chg 0000 evt 0000
[ 1557.849774] done.
[ 1557.871361] usbcore:hub_resume: hub 2-0:1.0: hub_resume
[ 1557.871498] hub 2-0:1.0: activate --> -16
[ 1557.871560] usbcore:hub_event: hub 2-0:1.0: state 7 ports 1 chg 0000 evt 0000
[ 1557.871624] usbcore:hub_suspend: hub 2-0:1.0: hub_suspend
[ 1557.871633] PM: hibernation: hibernation exit
[ 1557.898882] usbcore:hcd_bus_suspend: usb usb2: bus auto-suspend, wakeup 1
[ 1562.118339] psmouse serio0: Failed to enable mouse on 1c060000.kmi
[ 1565.237499] usbcore:usb_remote_wakeup: usb usb2: usb wakeup-resume
[ 1565.244115] usbcore:hcd_bus_resume: usb usb2: usb auto-resume
[ 1565.254962] usbcore:hub_event: hub 1-1:1.0: state 7 ports 4 chg 0000 evt 0000
[ 1565.327389] usbcore:hub_resume: hub 2-0:1.0: hub_resume
[ 1565.333227] usbcore:hub_event: hub 2-0:1.0: state 7 ports 1 chg 0000 evt 0000
[ 1565.340689] usbcore:hub_suspend: hub 2-0:1.0: hub_suspend
[ 1565.346490] usbcore:hcd_bus_suspend: usb usb2: bus auto-suspend, wakeup 1
[ 1568.819545] psmouse serio1: Failed to enable mouse on 1c070000.kmi

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: lockdep warning in urb.c:363 usb_submit_urb
  2020-03-24 14:06               ` Qais Yousef
@ 2020-03-24 15:56                 ` Alan Stern
  2020-03-24 17:22                   ` Qais Yousef
  0 siblings, 1 reply; 50+ messages in thread
From: Alan Stern @ 2020-03-24 15:56 UTC (permalink / raw)
  To: Qais Yousef; +Cc: Oliver Neukum, Greg Kroah-Hartman, linux-usb, linux-kernel

On Tue, 24 Mar 2020, Qais Yousef wrote:

> On 03/24/20 09:52, Alan Stern wrote:
> > On Tue, 24 Mar 2020, Qais Yousef wrote:
> > 
> > > On 03/24/20 14:20, Oliver Neukum wrote:
> > > > Am Dienstag, den 24.03.2020, 10:46 +0000 schrieb Qais Yousef:
> > > > > 
> > > > > I should have stuck to what I know then. I misread the documentation. Hopefully
> > > > > the attached looks better. I don't see the new debug you added emitted.
> > > > 
> > > > That is odd. Please try
> > > > 
> > > > echo "module usbcore +mfp" > /sys/kernel/debug/dynamic_debug/control
> > > > 
> > > > with the attached improved patch.
> > > 
> > > Hmm still no luck
> > > 
> > > 
> > > # history
> > >    0 echo "module usbcore +mfp" > /sys/kernel/debug/dynamic_debug/control
> > >    1 swapoff -a
> > >    2 echo suspend > /sys/power/disk
> > >    3 echo disk > /sys/power/state
> > >    4 dmesg > usb.dmesg
> > 
> > What happens if you omit step 1 (the swapoff)?
> 
> It seems to hibernate (suspend) successfully. If I omit that step I must setup
> a wakealarm to trigger the wakeup, but that's it.

You don't have any other wakeup sources?  Like a power button?

> I attached the dmesg; I didn't reboot the system in between.
> 
> 
> # history
>    0 echo "module usbcore +mfp" > /sys/kernel/debug/dynamic_debug/control
>    1 swapoff -a
>    2 echo suspend > /sys/power/disk
>    3 echo disk > /sys/power/state
>    4 dmesg > usb.dmesg
>    5 history
>    6 grep URB /sys/kernel/debug/dynamic_debug/control
>    7 grep "URB allocated" /sys/kernel/debug/dynamic_debug/control
>    8 swapon -a
>    9 echo +60 > /sys/class/rtc/rtc0/wakealarm
>   10 echo disk > /sys/power/state
>   11 dmesg > usb.dmesg

This certainly reinforces the initial impression that the cause of the
warnings is a bug in the platform code.  You should ask the appropriate
maintainer.

However, an equally troubling question is why the usb2 bus never got 
suspended in the first place.  To solve that, you may need to enable 
dynamic debugging in the Power Management core (i.e., "file
drivers/base/power/* +p").

Alan Stern


^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: lockdep warning in urb.c:363 usb_submit_urb
  2020-03-24 15:56                 ` Alan Stern
@ 2020-03-24 17:22                   ` Qais Yousef
  2020-03-24 19:22                     ` Alan Stern
  0 siblings, 1 reply; 50+ messages in thread
From: Qais Yousef @ 2020-03-24 17:22 UTC (permalink / raw)
  To: Alan Stern; +Cc: Oliver Neukum, Greg Kroah-Hartman, linux-usb, linux-kernel

On 03/24/20 11:56, Alan Stern wrote:
> On Tue, 24 Mar 2020, Qais Yousef wrote:
> 
> > On 03/24/20 09:52, Alan Stern wrote:
> > > On Tue, 24 Mar 2020, Qais Yousef wrote:
> > > 
> > > > On 03/24/20 14:20, Oliver Neukum wrote:
> > > > > Am Dienstag, den 24.03.2020, 10:46 +0000 schrieb Qais Yousef:
> > > > > > 
> > > > > > I should have stuck to what I know then. I misread the documentation. Hopefully
> > > > > > the attached looks better. I don't see the new debug you added emitted.
> > > > > 
> > > > > That is odd. Please try
> > > > > 
> > > > > echo "module usbcore +mfp" > /sys/kernel/debug/dynamic_debug/control
> > > > > 
> > > > > with the attached improved patch.
> > > > 
> > > > Hmm still no luck
> > > > 
> > > > 
> > > > # history
> > > >    0 echo "module usbcore +mfp" > /sys/kernel/debug/dynamic_debug/control
> > > >    1 swapoff -a
> > > >    2 echo suspend > /sys/power/disk
> > > >    3 echo disk > /sys/power/state
> > > >    4 dmesg > usb.dmesg
> > > 
> > > What happens if you omit step 1 (the swapoff)?
> > 
> > It seems to hibernate (suspend) successfully. If I omit that step I must setup
> > a wakealarm to trigger the wakeup, but that's it.
> 
> You don't have any other wakeup sources?  Like a power button?

Not sure if it's hooked correctly as a wakeup source. But as UK is now getting
lockedown, I don't think I'll be seeing the board for a while and serial
console is my only friend :-)

I can hard reboot remotely reliably though.

> 
> > I attached the dmesg; I didn't reboot the system in between.
> > 
> > 
> > # history
> >    0 echo "module usbcore +mfp" > /sys/kernel/debug/dynamic_debug/control
> >    1 swapoff -a
> >    2 echo suspend > /sys/power/disk
> >    3 echo disk > /sys/power/state
> >    4 dmesg > usb.dmesg
> >    5 history
> >    6 grep URB /sys/kernel/debug/dynamic_debug/control
> >    7 grep "URB allocated" /sys/kernel/debug/dynamic_debug/control
> >    8 swapon -a
> >    9 echo +60 > /sys/class/rtc/rtc0/wakealarm
> >   10 echo disk > /sys/power/state
> >   11 dmesg > usb.dmesg
> 
> This certainly reinforces the initial impression that the cause of the
> warnings is a bug in the platform code.  You should ask the appropriate
> maintainer.

The device-tree compatible node returns "generic-ohci".
drivers/usb/host/ohci-platform.c returns you as the maintainer :-)

> 
> However, an equally troubling question is why the usb2 bus never got 
> suspended in the first place.  To solve that, you may need to enable 
> dynamic debugging in the Power Management core (i.e., "file
> drivers/base/power/* +p").

Thanks Alan. I'll run with extra debug and send back.

Cheers

--
Qais Yousef

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: lockdep warning in urb.c:363 usb_submit_urb
  2020-03-24 17:22                   ` Qais Yousef
@ 2020-03-24 19:22                     ` Alan Stern
  2020-03-25 15:00                       ` Qais Yousef
  0 siblings, 1 reply; 50+ messages in thread
From: Alan Stern @ 2020-03-24 19:22 UTC (permalink / raw)
  To: Qais Yousef; +Cc: Oliver Neukum, Greg Kroah-Hartman, linux-usb, linux-kernel

On Tue, 24 Mar 2020, Qais Yousef wrote:

> On 03/24/20 11:56, Alan Stern wrote:

> > This certainly reinforces the initial impression that the cause of the
> > warnings is a bug in the platform code.  You should ask the appropriate
> > maintainer.
> 
> The device-tree compatible node returns "generic-ohci".
> drivers/usb/host/ohci-platform.c returns you as the maintainer :-)

I'm the maintainer of the driver for the device.  But the device
structure itself (the one named 7ffb0000.ohci) gets created by 
device-tree -- that's what I was referring to.

Here's the first error message:

usb usb2: runtime PM trying to activate child device usb2 but parent (7ffb0000.ohci) is not active

The runtime PM status of 7ffb0000.ohci is set in ohci_platform_probe(),
which does:

        pm_runtime_set_active(&dev->dev);

The runtime PM status can change, and there aren't any debugging 
statements in ohci_platform_suspend() or ohci_platform_resume() (or 
ohci_suspend()/ohci_resume() in ohci-hcd.c, for that matter).  Maybe 
you can add some so we can see if anything strange is going on.

Any maybe you can find out exactly where that error message is coming 
from by calling dump_stack() immediately after the dev_err() line 
(approximately line 1198 in drivers/base/power/runtime.c).

(Also, you might want to turn off rcutorture.  It adds a lot of 
messages to the system log that are irrelevant for our purposes.)

Alan Stern


^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: lockdep warning in urb.c:363 usb_submit_urb
  2020-03-24 19:22                     ` Alan Stern
@ 2020-03-25 15:00                       ` Qais Yousef
  2020-03-25 20:49                         ` Alan Stern
  0 siblings, 1 reply; 50+ messages in thread
From: Qais Yousef @ 2020-03-25 15:00 UTC (permalink / raw)
  To: Alan Stern; +Cc: Oliver Neukum, Greg Kroah-Hartman, linux-usb, linux-kernel

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

On 03/24/20 15:22, Alan Stern wrote:
> On Tue, 24 Mar 2020, Qais Yousef wrote:
> 
> > On 03/24/20 11:56, Alan Stern wrote:
> 
> > > This certainly reinforces the initial impression that the cause of the
> > > warnings is a bug in the platform code.  You should ask the appropriate
> > > maintainer.
> > 
> > The device-tree compatible node returns "generic-ohci".
> > drivers/usb/host/ohci-platform.c returns you as the maintainer :-)
> 
> I'm the maintainer of the driver for the device.  But the device
> structure itself (the one named 7ffb0000.ohci) gets created by 
> device-tree -- that's what I was referring to.
> 
> Here's the first error message:
> 
> usb usb2: runtime PM trying to activate child device usb2 but parent (7ffb0000.ohci) is not active
> 
> The runtime PM status of 7ffb0000.ohci is set in ohci_platform_probe(),
> which does:
> 
>         pm_runtime_set_active(&dev->dev);
> 
> The runtime PM status can change, and there aren't any debugging 
> statements in ohci_platform_suspend() or ohci_platform_resume() (or 
> ohci_suspend()/ohci_resume() in ohci-hcd.c, for that matter).  Maybe 
> you can add some so we can see if anything strange is going on.
> 
> Any maybe you can find out exactly where that error message is coming 
> from by calling dump_stack() immediately after the dev_err() line 
> (approximately line 1198 in drivers/base/power/runtime.c).
> 
> (Also, you might want to turn off rcutorture.  It adds a lot of 
> messages to the system log that are irrelevant for our purposes.)

Thanks for all the hints Alan.

I think I figured it out, the below patch seems to fix it for me. Looking
at other drivers resume functions it seems we're missing the
pm_runtime_disable()->set_active()->enable() dance. Doing that fixes the
warning and the dev_err() in driver/base/power.

I don't see xhci-plat.c doing that, I wonder if it needs it too.

I'm not well versed about the details and the rules here. So my fix could be
a hack, though it does seem the right thing to do.

I wonder why the power core doesn't handle this transparently..

Requested dmesg is attached too.


diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
index 7addfc2cbadc..eb92c8092fae 100644
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -299,6 +299,10 @@ static int ohci_platform_resume(struct device *dev)
        }

        ohci_resume(hcd, false);
+
+       pm_runtime_disable(dev);
+       pm_runtime_set_active(dev);
+       pm_runtime_enable(dev);
        return 0;
 }
 #endif /* CONFIG_PM_SLEEP */


Thanks

--
Qais Yousef

[-- Attachment #2: usb.dmesg --]
[-- Type: text/plain, Size: 49530 bytes --]

[    0.000000] Booting Linux on physical CPU 0x0000000100 [0x410fd033]
[    0.000000] Linux version 5.6.0-rc6-00002-gdfd1731f9a3e-dirty (qyousef@e107158-lin) (gcc version 7.5.0 (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04)) #545 SMP PREEMPT Wed Mar 25 14:16:10 GMT 2020
[    0.000000] Machine model: ARM Juno development board (r2)
[    0.000000] earlycon: pl11 at MMIO 0x000000007ff80000 (options '')
[    0.000000] printk: bootconsole [pl11] enabled
[    0.000000] efi: Getting EFI parameters from FDT:
[    0.000000] efi: UEFI not found.
[    0.000000] cma: Reserved 32 MiB at 0x00000000fd000000
[    0.000000] NUMA: No NUMA configuration found
[    0.000000] NUMA: Faking a node at [mem 0x0000000080000000-0x00000009ffffffff]
[    0.000000] NUMA: NODE_DATA [mem 0x9fefdb000-0x9fefdcfff]
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x0000000080000000-0x00000000bfffffff]
[    0.000000]   DMA32    [mem 0x00000000c0000000-0x00000000ffffffff]
[    0.000000]   Normal   [mem 0x0000000100000000-0x00000009ffffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000080000000-0x00000000feffffff]
[    0.000000]   node   0: [mem 0x0000000880000000-0x00000009ffffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000080000000-0x00000009ffffffff]
[    0.000000] On node 0 totalpages: 2093056
[    0.000000]   DMA zone: 4096 pages used for memmap
[    0.000000]   DMA zone: 0 pages reserved
[    0.000000]   DMA zone: 262144 pages, LIFO batch:63
[    0.000000]   DMA32 zone: 4096 pages used for memmap
[    0.000000]   DMA32 zone: 258048 pages, LIFO batch:63
[    0.000000]   Normal zone: 24576 pages used for memmap
[    0.000000]   Normal zone: 1572864 pages, LIFO batch:63
[    0.000000] psci: probing for conduit method from DT.
[    0.000000] psci: PSCIv1.0 detected in firmware.
[    0.000000] psci: Using standard PSCI v0.2 function IDs
[    0.000000] psci: Trusted OS migration not required
[    0.000000] psci: SMC Calling Convention v1.0
[    0.000000] percpu: Embedded 48 pages/cpu s158536 r8192 d29880 u196608
[    0.000000] pcpu-alloc: s158536 r8192 d29880 u196608 alloc=48*4096
[    0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0] 4 [0] 5 
[    0.000000] Detected VIPT I-cache on CPU0
[    0.000000] CPU features: detected: ARM erratum 845719
[    0.000000] CPU features: detected: ARM erratum 843419
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 2060288
[    0.000000] Policy zone: Normal
[    0.000000] Kernel command line: ttyAMA0,115200n8 root=/dev/nfs rw verbose debug ip=dhcp nfsroot=xx.xx.xx.xx:/mnt/data/exports/juno,vers=4,tcp nfsrootdebug rootwait earlycon=pl011,0x7ff80000 systemd.log_target=null user_debug=31 androidboot.hardware=juno loglevel=9 bootargs_sky2=sky2.mac_address=0x00,0x02,0xf7,0x00,0x67,0xbe
[    0.000000] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes, linear)
[    0.000000] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes, linear)
[    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[    0.000000] software IO TLB: mapped [mem 0xbbfff000-0xbffff000] (64MB)
[    0.000000] Memory: 8044524K/8372224K available (25660K kernel code, 4120K rwdata, 12216K rodata, 14656K init, 11183K bss, 294932K reserved, 32768K cma-reserved)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=6, Nodes=1
[    0.000000] ftrace: allocating 77520 entries in 303 pages
[    0.000000] ftrace: allocated 303 pages with 6 groups
[    0.000000] Running RCU self tests
[    0.000000] rcu: Preemptible hierarchical RCU implementation.
[    0.000000] rcu: 	RCU lockdep checking is enabled.
[    0.000000] rcu: 	RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=6.
[    0.000000] 	Tasks RCU enabled.
[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
[    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=6
[    0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
[    0.000000] GIC: Using split EOI/Deactivate mode
[    0.000000] GICv2m: range[mem 0x2c1c0000-0x2c1cffff], SPI[224:255]
[    0.000000] GICv2m: range[mem 0x2c1d0000-0x2c1dffff], SPI[256:287]
[    0.000000] GICv2m: range[mem 0x2c1e0000-0x2c1effff], SPI[288:319]
[    0.000000] GICv2m: range[mem 0x2c1f0000-0x2c1fffff], SPI[320:351]
[    0.000000] random: get_random_bytes called from start_kernel+0x5d8/0x784 with crng_init=0
[    0.000000] clocksource: arm,sp804: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275 ns
[    0.000008] sched_clock: 32 bits at 1000kHz, resolution 1000ns, wraps every 2147483647500ns
[    0.008557] Failed to initialize '/smb@8000000/motherboard/iofpga@3,00000000/timer@120000': -22
[    0.018103] arch_timer: cp15 and mmio timer(s) running at 50.00MHz (phys/phys).
[    0.025447] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0xb8812736b, max_idle_ns: 440795202655 ns
[    0.036276] sched_clock: 56 bits at 50MHz, resolution 20ns, wraps every 4398046511100ns
[    0.045517] Console: colour dummy device 80x25
[    0.050050] printk: console [tty0] enabled
[    0.054295] printk: bootconsole [pl11] disabled
[    0.058992] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
[    0.059159] ... MAX_LOCKDEP_SUBCLASSES:  8
[    0.059260] ... MAX_LOCK_DEPTH:          48
[    0.059361] ... MAX_LOCKDEP_KEYS:        8192
[    0.059465] ... CLASSHASH_SIZE:          4096
[    0.059570] ... MAX_LOCKDEP_ENTRIES:     32768
[    0.059676] ... MAX_LOCKDEP_CHAINS:      65536
[    0.059782] ... CHAINHASH_SIZE:          32768
[    0.059887]  memory used by lock dependency info: 6237 kB
[    0.060010]  memory used for stack traces: 4224 kB
[    0.060122]  per task-struct memory footprint: 1920 bytes
[    0.060244] ------------------------
[    0.060334] | Locking API testsuite:
[    0.060424] ----------------------------------------------------------------------------
[    0.060596]                                  | spin |wlock |rlock |mutex | wsem | rsem |
[    0.060767]   --------------------------------------------------------------------------
[    0.060946]                      A-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[    0.079440]                  A-B-B-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[    0.099547]              A-B-B-C-C-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[    0.121354]              A-B-C-A-B-C deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[    0.143126]          A-B-B-C-C-D-D-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[    0.166625]          A-B-C-D-B-D-D-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[    0.190062]          A-B-C-D-B-C-D-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[    0.213553]                     double unlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[    0.231966]                   initialize held:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[    0.249767]   --------------------------------------------------------------------------
[    0.249937]               recursive read-lock:             |  ok  |             |  ok  |
[    0.255564]            recursive read-lock #2:             |  ok  |             |  ok  |
[    0.260970]             mixed read-write-lock:             |  ok  |             |  ok  |
[    0.266382]             mixed write-read-lock:             |  ok  |             |  ok  |
[    0.271793]   mixed read-lock/lock-write ABBA:             |FAILED|             |  ok  |
[    0.277515]    mixed read-lock/lock-read ABBA:             |  ok  |             |  ok  |
[    0.283397]  mixed write-lock/lock-write ABBA:             |  ok  |             |  ok  |
[    0.289274]   --------------------------------------------------------------------------
[    0.289605]      hard-irqs-on + irq-safe-A/12:  ok  |  ok  |  ok  |
[    0.297567]      soft-irqs-on + irq-safe-A/12:  ok  |  ok  |  ok  |
[    0.305563]      hard-irqs-on + irq-safe-A/21:  ok  |  ok  |  ok  |
[    0.313516]      soft-irqs-on + irq-safe-A/21:  ok  |  ok  |  ok  |
[    0.321520]        sirq-safe-A => hirqs-on/12:  ok  |  ok  |  ok  |
[    0.329488]        sirq-safe-A => hirqs-on/21:  ok  |  ok  |  ok  |
[    0.337502]          hard-safe-A + irqs-on/12:  ok  |  ok  |  ok  |
[    0.345458]          soft-safe-A + irqs-on/12:  ok  |  ok  |  ok  |
[    0.353477]          hard-safe-A + irqs-on/21:  ok  |  ok  |  ok  |
[    0.361441]          soft-safe-A + irqs-on/21:  ok  |  ok  |  ok  |
[    0.369453]     hard-safe-A + unsafe-B #1/123:  ok  |  ok  |  ok  |
[    0.378116]     soft-safe-A + unsafe-B #1/123:  ok  |  ok  |  ok  |
[    0.386824]     hard-safe-A + unsafe-B #1/132:  ok  |  ok  |  ok  |
[    0.395480]     soft-safe-A + unsafe-B #1/132:  ok  |  ok  |  ok  |
[    0.404183]     hard-safe-A + unsafe-B #1/213:  ok  |  ok  |  ok  |
[    0.412842]     soft-safe-A + unsafe-B #1/213:  ok  |  ok  |  ok  |
[    0.421545]     hard-safe-A + unsafe-B #1/231:  ok  |  ok  |  ok  |
[    0.430196]     soft-safe-A + unsafe-B #1/231:  ok  |  ok  |  ok  |
[    0.438895]     hard-safe-A + unsafe-B #1/312:  ok  |  ok  |  ok  |
[    0.447085]     soft-safe-A + unsafe-B #1/312:  ok  |  ok  |  ok  |
[    0.455316]     hard-safe-A + unsafe-B #1/321:  ok  |  ok  |  ok  |
[    0.463973]     soft-safe-A + unsafe-B #1/321:  ok  |  ok  |  ok  |
[    0.472673]     hard-safe-A + unsafe-B #2/123:  ok  |  ok  |  ok  |
[    0.481336]     soft-safe-A + unsafe-B #2/123:  ok  |  ok  |  ok  |
[    0.490034]     hard-safe-A + unsafe-B #2/132:  ok  |  ok  |  ok  |
[    0.498693]     soft-safe-A + unsafe-B #2/132:  ok  |  ok  |  ok  |
[    0.507410]     hard-safe-A + unsafe-B #2/213:  ok  |  ok  |  ok  |
[    0.516066]     soft-safe-A + unsafe-B #2/213:  ok  |  ok  |  ok  |
[    0.524770]     hard-safe-A + unsafe-B #2/231:  ok  |  ok  |  ok  |
[    0.533425]     soft-safe-A + unsafe-B #2/231:  ok  |  ok  |  ok  |
[    0.542130]     hard-safe-A + unsafe-B #2/312:  ok  |  ok  |  ok  |
[    0.550787]     soft-safe-A + unsafe-B #2/312:  ok  |  ok  |  ok  |
[    0.559501]     hard-safe-A + unsafe-B #2/321:  ok  |  ok  |  ok  |
[    0.568163]     soft-safe-A + unsafe-B #2/321:  ok  |  ok  |  ok  |
[    0.576870]       hard-irq lock-inversion/123:  ok  |  ok  |  ok  |
[    0.585537]       soft-irq lock-inversion/123:  ok  |  ok  |  ok  |
[    0.594252]       hard-irq lock-inversion/132:  ok  |  ok  |  ok  |
[    0.602905]       soft-irq lock-inversion/132:  ok  |  ok  |  ok  |
[    0.611620]       hard-irq lock-inversion/213:  ok  |  ok  |  ok  |
[    0.620272]       soft-irq lock-inversion/213:  ok  |  ok  |  ok  |
[    0.628982]       hard-irq lock-inversion/231:  ok  |  ok  |  ok  |
[    0.637635]       soft-irq lock-inversion/231:  ok  |  ok  |  ok  |
[    0.646346]       hard-irq lock-inversion/312:  ok  |  ok  |  ok  |
[    0.655006]       soft-irq lock-inversion/312:  ok  |  ok  |  ok  |
[    0.663718]       hard-irq lock-inversion/321:  ok  |  ok  |  ok  |
[    0.672361]       soft-irq lock-inversion/321:  ok  |  ok  |  ok  |
[    0.681063]       hard-irq read-recursion/123:  ok  |
[    0.684017]       soft-irq read-recursion/123:  ok  |
[    0.687014]       hard-irq read-recursion/132:  ok  |
[    0.689967]       soft-irq read-recursion/132:  ok  |
[    0.692963]       hard-irq read-recursion/213:  ok  |
[    0.695917]       soft-irq read-recursion/213:  ok  |
[    0.698910]       hard-irq read-recursion/231:  ok  |
[    0.701862]       soft-irq read-recursion/231:  ok  |
[    0.704861]       hard-irq read-recursion/312:  ok  |
[    0.707814]       soft-irq read-recursion/312:  ok  |
[    0.710809]       hard-irq read-recursion/321:  ok  |
[    0.713763]       soft-irq read-recursion/321:  ok  |
[    0.716757]   --------------------------------------------------------------------------
[    0.716927]   | Wound/wait tests |
[    0.717014]   ---------------------
[    0.717102]                   ww api failures:  ok  |  ok  |  ok  |
[    0.725588]                ww contexts mixing:  ok  |  ok  |
[    0.731180]              finishing ww context:  ok  |  ok  |  ok  |  ok  |
[    0.742246]                locking mismatches:  ok  |  ok  |  ok  |
[    0.750716]                  EDEADLK handling:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[    0.779593]            spinlock nest unlocked:  ok  |
[    0.782307]   -----------------------------------------------------
[    0.782442]                                  |block | try  |context|
[    0.782577]   -----------------------------------------------------
[    0.782711]                           context:  ok  |  ok  |  ok  |
[    0.791429]                               try:  ok  |  ok  |  ok  |
[    0.799631]                             block:  ok  |  ok  |  ok  |
[    0.807872]                          spinlock:  ok  |  ok  |  ok  |
[    0.816791] -------------------------------------------------------
[    0.816927] Good, all 261 testcases passed! |
[    0.817029] ---------------------------------
[    0.817366] Calibrating delay loop (skipped), value calculated using timer frequency.. 100.00 BogoMIPS (lpj=200000)
[    0.817640] pid_max: default: 32768 minimum: 301
[    0.818117] LSM: Security Framework initializing
[    0.818411] Mount-cache hash table entries: 16384 (order: 5, 131072 bytes, linear)
[    0.818617] Mountpoint-cache hash table entries: 16384 (order: 5, 131072 bytes, linear)
[    0.854086] rcu: Hierarchical SRCU implementation.
[    0.871249] EFI services will not be available.
[    0.878379] smp: Bringing up secondary CPUs ...
[    0.924476] CPU features: detected: EL2 vector hardening
[    0.924488] ARM_SMCCC_ARCH_WORKAROUND_1 missing from firmware
[    0.924496] CPU features: detected: ARM erratum 1319367
[    0.924502] Detected PIPT I-cache on CPU1
[    0.924565] CPU1: Booted secondary processor 0x0000000000 [0x410fd080]
[    0.968768] Detected PIPT I-cache on CPU2
[    0.968804] CPU2: Booted secondary processor 0x0000000001 [0x410fd080]
[    1.013229] Detected VIPT I-cache on CPU3
[    1.013300] CPU3: Booted secondary processor 0x0000000101 [0x410fd033]
[    1.057633] Detected VIPT I-cache on CPU4
[    1.057692] CPU4: Booted secondary processor 0x0000000102 [0x410fd033]
[    1.102062] Detected VIPT I-cache on CPU5
[    1.102119] CPU5: Booted secondary processor 0x0000000103 [0x410fd033]
[    1.102748] smp: Brought up 1 node, 6 CPUs
[    1.104412] SMP: Total of 6 processors activated.
[    1.104635] CPU features: detected: 32-bit EL0 Support
[    1.104773] CPU features: detected: CRC32 instructions
[    1.168392] CPU: All CPU(s) started at EL2
[    1.168658] alternatives: patching kernel code
[    1.173720] devtmpfs: initialized
[    1.193388] KASLR disabled due to lack of seed
[    1.195550] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[    1.195672] futex hash table entries: 2048 (order: 6, 262144 bytes, linear)
[    1.197239] xor: measuring software checksum speed
[    1.234111]    8regs     :  4239.000 MB/sec
[    1.274329]    32regs    :  4763.000 MB/sec
[    1.314588]    arm64_neon:  4422.000 MB/sec
[    1.314642] xor: using function: 32regs (4763.000 MB/sec)
[    1.314711] pinctrl core: initialized pinctrl subsystem
[    1.317493] thermal_sys: Registered thermal governor 'step_wise'
[    1.317499] thermal_sys: Registered thermal governor 'power_allocator'
[    1.319214] DMI not present or invalid.
[    1.320478] NET: Registered protocol family 16
[    1.324609] DMA: preallocated 256 KiB pool for atomic allocations
[    1.324694] audit: initializing netlink subsys (disabled)
[    1.325236] audit: type=2000 audit(1.044:1): state=initialized audit_enabled=0 res=1
[    1.327342] cpuidle: using governor menu
[    1.327610] NET: Registered protocol family 42
[    1.328197] hw-breakpoint: found 6 breakpoint and 4 watchpoint registers.
[    1.328700] ASID allocator initialised with 65536 entries
[    1.330723] Serial: AMBA PL011 UART driver
[    1.360582] 7ff80000.uart: ttyAMA0 at MMIO 0x7ff80000 (irq = 31, base_baud = 0) is a PL011 rev3
[    2.798170] printk: console [ttyAMA0] enabled
[    2.862142] HugeTLB registered 1.00 GiB page size, pre-allocated 0 pages
[    2.869034] HugeTLB registered 32.0 MiB page size, pre-allocated 0 pages
[    2.875841] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages
[    2.882657] HugeTLB registered 64.0 KiB page size, pre-allocated 0 pages
[    2.916023] cryptd: max_cpu_qlen set to 1000
[    3.017580] raid6: neonx8   gen()  3109 MB/s
[    3.090046] raid6: neonx8   xor()  2105 MB/s
[    3.162564] raid6: neonx4   gen()  3115 MB/s
[    3.234985] raid6: neonx4   xor()  2169 MB/s
[    3.307454] raid6: neonx2   gen()  2693 MB/s
[    3.379910] raid6: neonx2   xor()  2010 MB/s
[    3.452380] raid6: neonx1   gen()  1993 MB/s
[    3.524838] raid6: neonx1   xor()  1589 MB/s
[    3.597305] raid6: int64x8  gen()  1567 MB/s
[    3.669756] raid6: int64x8  xor()   889 MB/s
[    3.742226] raid6: int64x4  gen()  1815 MB/s
[    3.814687] raid6: int64x4  xor()   958 MB/s
[    3.887140] raid6: int64x2  gen()  1601 MB/s
[    3.959610] raid6: int64x2  xor()   839 MB/s
[    4.032067] raid6: int64x1  gen()  1222 MB/s
[    4.104533] raid6: int64x1  xor()   631 MB/s
[    4.108935] raid6: using algorithm neonx4 gen() 3115 MB/s
[    4.114420] raid6: .... xor() 2169 MB/s, rmw enabled
[    4.119466] raid6: using neon recovery algorithm
[    4.125047] ACPI: Interpreter disabled.
[    4.131906] iommu: Default domain type: Translated 
[    4.137540] vgaarb: loaded
[    4.141299] SCSI subsystem initialized
[    4.145645] libata version 3.00 loaded.
[    4.150204] usbcore: registered new interface driver usbfs
[    4.155912] usbcore: registered new interface driver hub
[    4.161514] usbcore: registered new device driver usb
[    4.169580] mc: Linux media interface: v0.10
[    4.174009] videodev: Linux video capture interface: v2.00
[    4.179858] pps_core: LinuxPPS API ver. 1 registered
[    4.184911] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    4.194206] PTP clock support registered
[    4.199016] EDAC MC: Ver: 3.0.0
[    4.204950] FPGA manager framework
[    4.208929] Advanced Linux Sound Architecture Driver Initialized.
[    4.216504] Bluetooth: Core ver 2.22
[    4.220219] NET: Registered protocol family 31
[    4.224747] Bluetooth: HCI device and connection manager initialized
[    4.231233] Bluetooth: HCI socket layer initialized
[    4.236207] Bluetooth: L2CAP socket layer initialized
[    4.241403] Bluetooth: SCO socket layer initialized
[    4.247908] clocksource: Switched to clocksource arch_sys_counter
[    5.092304] VFS: Disk quotas dquot_6.6.0
[    5.096486] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    5.104257] pnp: PnP ACPI: disabled
[    5.126899] NET: Registered protocol family 2
[    5.132268] tcp_listen_portaddr_hash hash table entries: 4096 (order: 6, 294912 bytes, linear)
[    5.141703] TCP established hash table entries: 65536 (order: 7, 524288 bytes, linear)
[    5.150017] TCP bind hash table entries: 65536 (order: 10, 4194304 bytes, linear)
[    5.168454] TCP: Hash tables configured (established 65536 bind 65536)
[    5.175673] UDP hash table entries: 4096 (order: 7, 655360 bytes, linear)
[    5.184143] UDP-Lite hash table entries: 4096 (order: 7, 655360 bytes, linear)
[    5.193203] NET: Registered protocol family 1
[    5.199434] RPC: Registered named UNIX socket transport module.
[    5.205500] RPC: Registered udp transport module.
[    5.210304] RPC: Registered tcp transport module.
[    5.215105] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    5.222684] PCI: CLS 0 bytes, default 64
[    6.577624] hw perfevents: enabled with armv8_cortex_a72 PMU driver, 7 counters available
[    6.587298] hw perfevents: enabled with armv8_cortex_a53 PMU driver, 7 counters available
[    6.595760] kvm [1]: IPA Size Limit: 40bits
[    6.608906] kvm [1]: vgic interrupt IRQ1
[    6.613502] kvm [1]: Hyp mode initialized successfully
[    7.080099] Initialise system trusted keyrings
[    7.085057] workingset: timestamp_bits=44 max_order=21 bucket_order=0
[    7.120549] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    7.129076] NFS: Registering the id_resolver key type
[    7.134304] Key type id_resolver registered
[    7.138597] Key type id_legacy registered
[    7.142713] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[    7.149953] fuse: init (API version 7.31)
[    7.155477] 9p: Installing v9fs 9p2000 file system support
[    7.183946] Key type asymmetric registered
[    7.188171] Asymmetric key parser 'x509' registered
[    7.193229] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 243)
[    7.200782] io scheduler mq-deadline registered
[    7.205432] io scheduler kyber registered
[    7.225296] pl061_gpio 1c1d0000.gpio: PL061 GPIO chip registered
[    7.235193] pci-host-generic 40000000.pcie: host bridge /pcie@40000000 ranges:
[    7.242600] pci-host-generic 40000000.pcie:       IO 0x005f800000..0x005fffffff -> 0x0000000000
[    7.251513] pci-host-generic 40000000.pcie:      MEM 0x0050000000..0x0057ffffff -> 0x0050000000
[    7.260389] pci-host-generic 40000000.pcie:      MEM 0x4000000000..0x40ffffffff -> 0x4000000000
[    7.269326] pci-host-generic 40000000.pcie: ECAM at [mem 0x40000000-0x4fffffff] for [bus 00-ff]
[    7.278527] pci-host-generic 40000000.pcie: PCI host bridge to bus 0000:00
[    7.285533] pci_bus 0000:00: root bus resource [bus 00-ff]
[    7.291123] pci_bus 0000:00: root bus resource [io  0x0000-0x7fffff]
[    7.297590] pci_bus 0000:00: root bus resource [mem 0x50000000-0x57ffffff]
[    7.304582] pci_bus 0000:00: root bus resource [mem 0x4000000000-0x40ffffffff pref]
[    7.312464] pci 0000:00:00.0: [1556:1100] type 01 class 0x060400
[    7.318635] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x00003fff 64bit pref]
[    7.326164] pci 0000:00:00.0: supports D1 D2
[    7.330525] pci 0000:00:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[    7.339261] pci 0000:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[    7.347697] pci 0000:01:00.0: [111d:8090] type 01 class 0x060400
[    7.353962] pci 0000:01:00.0: enabling Extended Tags
[    7.359209] pci 0000:01:00.0: PME# supported from D0 D3hot D3cold
[    7.377317] pci 0000:01:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[    7.385860] pci 0000:02:01.0: [111d:8090] type 01 class 0x060400
[    7.392141] pci 0000:02:01.0: enabling Extended Tags
[    7.397415] pci 0000:02:01.0: PME# supported from D0 D3hot D3cold
[    7.404279] pci 0000:02:02.0: [111d:8090] type 01 class 0x060400
[    7.410549] pci 0000:02:02.0: enabling Extended Tags
[    7.415822] pci 0000:02:02.0: PME# supported from D0 D3hot D3cold
[    7.422643] pci 0000:02:03.0: [111d:8090] type 01 class 0x060400
[    7.428912] pci 0000:02:03.0: enabling Extended Tags
[    7.434185] pci 0000:02:03.0: PME# supported from D0 D3hot D3cold
[    7.441395] pci 0000:02:0c.0: [111d:8090] type 01 class 0x060400
[    7.447666] pci 0000:02:0c.0: enabling Extended Tags
[    7.452938] pci 0000:02:0c.0: PME# supported from D0 D3hot D3cold
[    7.459931] pci 0000:02:10.0: [111d:8090] type 01 class 0x060400
[    7.466186] pci 0000:02:10.0: enabling Extended Tags
[    7.471444] pci 0000:02:10.0: PME# supported from D0 D3hot D3cold
[    7.478879] pci 0000:02:1f.0: [111d:8090] type 01 class 0x060400
[    7.485150] pci 0000:02:1f.0: enabling Extended Tags
[    7.490430] pci 0000:02:1f.0: PME# supported from D0 D3hot D3cold
[    7.497230] pci 0000:02:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[    7.505402] pci 0000:02:02.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[    7.513562] pci 0000:02:03.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[    7.521720] pci 0000:02:0c.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[    7.529877] pci 0000:02:10.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[    7.538035] pci 0000:02:1f.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[    7.546502] pci 0000:03:00.0: [1095:3132] type 00 class 0x018000
[    7.552696] pci 0000:03:00.0: reg 0x10: [mem 0x00000000-0x0000007f 64bit]
[    7.559637] pci 0000:03:00.0: reg 0x18: [mem 0x00000000-0x00003fff 64bit]
[    7.566562] pci 0000:03:00.0: reg 0x20: [io  0x0000-0x007f]
[    7.572276] pci 0000:03:00.0: reg 0x30: [mem 0x00000000-0x0007ffff pref]
[    7.579263] pci 0000:03:00.0: supports D1 D2
[    7.584131] pci 0000:03:00.0: disabling ASPM on pre-1.1 PCIe device.  You can enable it with 'pcie_aspm=force'
[    7.595613] pci_bus 0000:03: busn_res: [bus 03-ff] end is updated to 03
[    7.603920] pci_bus 0000:04: busn_res: [bus 04-ff] end is updated to 04
[    7.612230] pci_bus 0000:05: busn_res: [bus 05-ff] end is updated to 05
[    7.620534] pci_bus 0000:06: busn_res: [bus 06-ff] end is updated to 06
[    7.628842] pci_bus 0000:07: busn_res: [bus 07-ff] end is updated to 07
[    7.635950] pci 0000:08:00.0: [11ab:4380] type 00 class 0x020000
[    7.642138] pci 0000:08:00.0: reg 0x10: [mem 0x00000000-0x00003fff 64bit]
[    7.649063] pci 0000:08:00.0: reg 0x18: [io  0x0000-0x00ff]
[    7.654979] pci 0000:08:00.0: supports D1 D2
[    7.659341] pci 0000:08:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[    7.668084] pci_bus 0000:08: busn_res: [bus 08-ff] end is updated to 08
[    7.674828] pci_bus 0000:02: busn_res: [bus 02-ff] end is updated to 08
[    7.681569] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 08
[    7.688330] pci 0000:00:00.0: BAR 14: assigned [mem 0x50000000-0x501fffff]
[    7.695330] pci 0000:00:00.0: BAR 0: assigned [mem 0x4000000000-0x4000003fff 64bit pref]
[    7.703581] pci 0000:00:00.0: BAR 13: assigned [io  0x1000-0x2fff]
[    7.709886] pci 0000:01:00.0: BAR 14: assigned [mem 0x50000000-0x501fffff]
[    7.716883] pci 0000:01:00.0: BAR 13: assigned [io  0x1000-0x2fff]
[    7.723190] pci 0000:02:01.0: BAR 14: assigned [mem 0x50000000-0x500fffff]
[    7.730187] pci 0000:02:1f.0: BAR 14: assigned [mem 0x50100000-0x501fffff]
[    7.737183] pci 0000:02:01.0: BAR 13: assigned [io  0x1000-0x1fff]
[    7.743477] pci 0000:02:1f.0: BAR 13: assigned [io  0x2000-0x2fff]
[    7.749786] pci 0000:03:00.0: BAR 6: assigned [mem 0x50000000-0x5007ffff pref]
[    7.757139] pci 0000:03:00.0: BAR 2: assigned [mem 0x50080000-0x50083fff 64bit]
[    7.764614] pci 0000:03:00.0: BAR 0: assigned [mem 0x50084000-0x5008407f 64bit]
[    7.772078] pci 0000:03:00.0: BAR 4: assigned [io  0x1000-0x107f]
[    7.778296] pci 0000:02:01.0: PCI bridge to [bus 03]
[    7.783364] pci 0000:02:01.0:   bridge window [io  0x1000-0x1fff]
[    7.789580] pci 0000:02:01.0:   bridge window [mem 0x50000000-0x500fffff]
[    7.796509] pci 0000:02:02.0: PCI bridge to [bus 04]
[    7.801605] pci 0000:02:03.0: PCI bridge to [bus 05]
[    7.806701] pci 0000:02:0c.0: PCI bridge to [bus 06]
[    7.811797] pci 0000:02:10.0: PCI bridge to [bus 07]
[    7.816902] pci 0000:08:00.0: BAR 0: assigned [mem 0x50100000-0x50103fff 64bit]
[    7.824363] pci 0000:08:00.0: BAR 2: assigned [io  0x2000-0x20ff]
[    7.830578] pci 0000:02:1f.0: PCI bridge to [bus 08]
[    7.835644] pci 0000:02:1f.0:   bridge window [io  0x2000-0x2fff]
[    7.841859] pci 0000:02:1f.0:   bridge window [mem 0x50100000-0x501fffff]
[    7.848787] pci 0000:01:00.0: PCI bridge to [bus 02-08]
[    7.854116] pci 0000:01:00.0:   bridge window [io  0x1000-0x2fff]
[    7.860331] pci 0000:01:00.0:   bridge window [mem 0x50000000-0x501fffff]
[    7.867259] pci 0000:00:00.0: PCI bridge to [bus 01-08]
[    7.872593] pci 0000:00:00.0:   bridge window [io  0x1000-0x2fff]
[    7.878802] pci 0000:00:00.0:   bridge window [mem 0x50000000-0x501fffff]
[    7.886081] pcieport 0000:00:00.0: enabling device (0000 -> 0003)
[    7.900350] pcieport 0000:00:00.0: PME: Signaling with IRQ 44
[    7.907274] pcieport 0000:00:00.0: AER: enabled with IRQ 44
[    7.913552] pcieport 0000:01:00.0: enabling device (0000 -> 0003)
[    7.920030] pcieport 0000:02:01.0: enabling device (0000 -> 0003)
[    7.930863] pcieport 0000:02:1f.0: enabling device (0000 -> 0003)
[    7.940840] IPMI message handler: version 39.2
[    7.945556] ipmi device interface
[    7.949078] ipmi_si: IPMI System Interface driver
[    7.954515] ipmi_si: Unable to find any System Interface(s)
[    7.961434] EINJ: ACPI disabled.
[    7.974192] dma-pl330 7ff00000.dma: WARN: Device release is not defined so it is not safe to unbind this driver while in use
[    7.986948] dma-pl330 7ff00000.dma: Loaded driver for PL330 DMAC-341330
[    7.993684] dma-pl330 7ff00000.dma: 	DBUFF-1024x16bytes Num_Chans-8 Num_Peri-8 Num_Events-8
[    8.018275] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    8.029986] SuperH (H)SCI(F) driver initialized
[    8.035328] msm_serial: driver initialized
[    8.043194] arm-smmu 7fb10000.iommu: probing hardware configuration...
[    8.049858] arm-smmu 7fb10000.iommu: SMMUv1 with:
[    8.054660] arm-smmu 7fb10000.iommu: 	stage 2 translation
[    8.060164] arm-smmu 7fb10000.iommu: 	non-coherent table walk
[    8.066016] arm-smmu 7fb10000.iommu: 	(IDR0.CTTW overridden by FW configuration)
[    8.073545] arm-smmu 7fb10000.iommu: 	stream matching with 2 register groups
[    8.080722] arm-smmu 7fb10000.iommu: 	1 context banks (1 stage-2 only)
[    8.087371] arm-smmu 7fb10000.iommu: 	Supported page sizes: 0x60211000
[    8.094016] arm-smmu 7fb10000.iommu: 	Stage-2: 40-bit IPA -> 40-bit PA
[    8.101582] arm-smmu 7fb20000.iommu: probing hardware configuration...
[    8.108298] arm-smmu 7fb20000.iommu: SMMUv1 with:
[    8.113100] arm-smmu 7fb20000.iommu: 	stage 2 translation
[    8.118604] arm-smmu 7fb20000.iommu: 	non-coherent table walk
[    8.124456] arm-smmu 7fb20000.iommu: 	(IDR0.CTTW overridden by FW configuration)
[    8.131985] arm-smmu 7fb20000.iommu: 	stream matching with 2 register groups
[    8.139162] arm-smmu 7fb20000.iommu: 	1 context banks (1 stage-2 only)
[    8.145821] arm-smmu 7fb20000.iommu: 	Supported page sizes: 0x60211000
[    8.152466] arm-smmu 7fb20000.iommu: 	Stage-2: 40-bit IPA -> 40-bit PA
[    8.159610] arm-smmu 7fb30000.iommu: probing hardware configuration...
[    8.166260] arm-smmu 7fb30000.iommu: SMMUv1 with:
[    8.171060] arm-smmu 7fb30000.iommu: 	stage 2 translation
[    8.176562] arm-smmu 7fb30000.iommu: 	coherent table walk
[    8.182068] arm-smmu 7fb30000.iommu: 	stream matching with 2 register groups
[    8.189242] arm-smmu 7fb30000.iommu: 	1 context banks (1 stage-2 only)
[    8.195967] arm-smmu 7fb30000.iommu: 	Supported page sizes: 0x60211000
[    8.202613] arm-smmu 7fb30000.iommu: 	Stage-2: 40-bit IPA -> 40-bit PA
[    8.347541] tda998x 0-0070: found TDA19988
[    8.476376] tda998x 0-0071: found TDA19988
[    8.547034] loop: module loaded
[    8.673238] mpt3sas version 33.100.00.00 loaded
[    8.682167] sata_sil24 0000:03:00.0: version 1.1
[    8.686921] sata_sil24 0000:03:00.0: enabling device (0000 -> 0003)
[    8.696899] scsi host0: sata_sil24
[    8.701952] scsi host1: sata_sil24
[    8.705964] ata1: SATA max UDMA/100 host m128@0x50084000 port 0x50080000 irq 51
[    8.713412] ata2: SATA max UDMA/100 host m128@0x50084000 port 0x50082000 irq 51
[    8.728534] libphy: Fixed MDIO Bus: probed
[    8.734961] tun: Universal TUN/TAP device driver, 1.6
[    8.741517] bnx2x: QLogic 5771x/578xx 10/20-Gigabit Ethernet Driver bnx2x 1.713.36-0 (2014/02/10)
[    8.751549] thunder_xcv, ver 1.0
[    8.755013] thunder_bgx, ver 1.0
[    8.758439] nicpf, ver 1.0
[    8.762092] hclge is initializing
[    8.765875] hns3: Hisilicon Ethernet Network Driver for Hip08 Family - version
[    8.773260] hns3: Copyright (c) 2017 Huawei Corporation.
[    8.778842] e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k
[    8.784782] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
[    8.790947] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.6.0-k
[    8.798024] igb: Copyright (c) 2007-2014 Intel Corporation.
[    8.803824] igbvf: Intel(R) Gigabit Virtual Function Network Driver - version 2.4.0-k
[    8.811780] igbvf: Copyright (c) 2009 - 2012 Intel Corporation.
[    8.818521] sky2: driver version 1.30
[    8.822596] sky2 0000:08:00.0: enabling device (0000 -> 0003)
[    8.828564] sky2 0000:08:00.0: Yukon-2 UL 2 chip revision 0
[    8.834357] sky2 0000:08:00.0 (unnamed net_device) (uninitialized): Invalid MAC address, defaulting to random
[    8.846043] sky2 0000:08:00.0 eth0: addr fe:9a:bd:e5:a7:ff
[    8.886584] libphy: smsc911x-mdio: probed
[    8.901994] pegasus: v0.9.3 (2013/04/25), Pegasus/Pegasus II USB Ethernet driver
[    8.909637] usbcore: registered new interface driver pegasus
[    8.915469] usbcore: registered new interface driver rtl8150
[    8.921330] usbcore: registered new interface driver r8152
[    8.926986] usbcore: registered new interface driver lan78xx
[    8.932837] usbcore: registered new interface driver asix
[    8.938418] usbcore: registered new interface driver ax88179_178a
[    8.944688] usbcore: registered new interface driver cdc_ether
[    8.950686] usbcore: registered new interface driver dm9601
[    8.956448] usbcore: registered new interface driver CoreChips
[    8.962492] usbcore: registered new interface driver smsc75xx
[    8.968474] usbcore: registered new interface driver smsc95xx
[    8.974386] usbcore: registered new interface driver net1080
[    8.980208] usbcore: registered new interface driver plusb
[    8.985862] usbcore: registered new interface driver cdc_subset
[    8.991964] usbcore: registered new interface driver zaurus
[    8.997710] usbcore: registered new interface driver MOSCHIP usb-ethernet driver
[    9.005326] usbcore: registered new interface driver cdc_ncm
[    9.011485] VFIO - User Level meta-driver version: 0.3
[    9.020377] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    9.027057] ehci-pci: EHCI PCI platform driver
[    9.031695] ehci-platform: EHCI generic platform driver
[    9.037597] ehci-platform 7ffc0000.ehci: Adding to iommu group 0
[    9.044283] ehci-platform 7ffc0000.ehci: EHCI Host Controller
[    9.050291] ehci-platform 7ffc0000.ehci: new USB bus registered, assigned bus number 1
[    9.058744] ehci-platform 7ffc0000.ehci: irq 34, io mem 0x7ffc0000
[    9.079967] ehci-platform 7ffc0000.ehci: USB 2.0 started, EHCI 1.00
[    9.088797] hub 1-0:1.0: USB hub found
[    9.092798] hub 1-0:1.0: 1 port detected
[    9.098135] ehci-orion: EHCI orion driver
[    9.102462] ehci-exynos: EHCI Exynos driver
[    9.106916] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    9.113238] ohci-pci: OHCI PCI platform driver
[    9.117881] ohci-platform: OHCI generic platform driver
[    9.123495] ohci-platform 7ffb0000.ohci: Adding to iommu group 0
[    9.129894] ohci-platform 7ffb0000.ohci: Generic Platform OHCI controller
[    9.136861] ohci-platform 7ffb0000.ohci: new USB bus registered, assigned bus number 2
[    9.145189] ohci-platform 7ffb0000.ohci: irq 33, io mem 0x7ffb0000
[    9.230048] hub 2-0:1.0: USB hub found
[    9.233993] hub 2-0:1.0: 1 port detected
[    9.239005] ohci-exynos: OHCI Exynos driver
[    9.244235] usbcore: registered new interface driver usb-storage
[    9.259192] rtc-pl031 1c170000.rtc: registered as rtc0
[    9.266003] i2c /dev entries driver
[    9.275028] usbcore: registered new interface driver uvcvideo
[    9.280884] USB Video Class driver (1.1.1)
[    9.285065] gspca_main: v2.14.0 registered
[    9.296038] sp805-wdt 1c0f0000.wdt: registration successful
[    9.304583] device-mapper: ioctl: 4.42.0-ioctl (2020-02-27) initialised: dm-devel@redhat.com
[    9.313212] Bluetooth: HCI UART driver ver 2.3
[    9.317746] Bluetooth: HCI UART protocol H4 registered
[    9.323026] Bluetooth: HCI UART protocol LL registered
[    9.328441] Bluetooth: HCI UART protocol Broadcom registered
[    9.334327] usbcore: registered new interface driver btusb
[    9.342601] mmci-pl18x 1c050000.mmci: mmc0: PL180 manf 41 rev0 at 0x1c050000 irq 9,0 (pio)
[    9.377097] sdhci: Secure Digital Host Controller Interface driver
[    9.383545] sdhci: Copyright(c) Pierre Ossman
[    9.388697] Synopsys Designware Multimedia Card Interface Driver
[    9.396519] sdhci-pltfm: SDHCI platform and OF driver helper
[    9.405237] leds-syscon 1c010000.apbregs:led0: registered LED vexpress:0
[    9.412494] leds-syscon 1c010000.apbregs:led1: registered LED vexpress:1
[    9.419731] leds-syscon 1c010000.apbregs:led2: registered LED vexpress:2
[    9.426949] leds-syscon 1c010000.apbregs:led3: registered LED vexpress:3
[    9.432038] usb 1-1: new high-speed USB device number 2 using ehci-platform
[    9.434150] leds-syscon 1c010000.apbregs:led4: registered LED vexpress:4
[    9.448228] leds-syscon 1c010000.apbregs:led5: registered LED vexpress:5
[    9.455450] leds-syscon 1c010000.apbregs:led6: registered LED vexpress:6
[    9.462677] leds-syscon 1c010000.apbregs:led7: registered LED vexpress:7
[    9.470608] ledtrig-cpu: registered to indicate activity on CPUs
[    9.471854] hub 1-1:1.0: USB hub found
[    9.480403] usbcore: registered new interface driver usbhid
[    9.481137] hub 1-1:1.0: 4 ports detected
[    9.486375] usbhid: USB HID core driver
[    9.487558] mhu 2b1f0000.mhu: ARM MHU Mailbox registered
[    9.513690] drop_monitor: Initializing network drop monitor service
[    9.520317] random: fast init done
[    9.524235] NET: Registered protocol family 10
[    9.531342] Segment Routing with IPv6
[    9.535733] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
[    9.542881] NET: Registered protocol family 17
[    9.547631] Bridge firewalling registered
[    9.551728] Bluetooth: HIDP (Human Interface Emulation) ver 1.2
[    9.557760] Bluetooth: HIDP socket layer initialized
[    9.562911] 8021q: 802.1Q VLAN Support v1.8
[    9.567556] 9pnet: Installing 9P2000 support
[    9.572093] Key type dns_resolver registered
[    9.577890] registered taskstats version 1
[    9.582110] Loading compiled-in X.509 certificates
[    9.590285] Btrfs loaded, crc32c=crc32c-generic
[    9.606480] scpi_protocol scpi: SCP Protocol 1.2 Firmware 1.21.0 version
[    9.667669] arm-smmu 2b600000.iommu: probing hardware configuration...
[    9.674460] arm-smmu 2b600000.iommu: SMMUv1 with:
[    9.679337] arm-smmu 2b600000.iommu: 	stage 2 translation
[    9.684895] arm-smmu 2b600000.iommu: 	coherent table walk
[    9.690397] arm-smmu 2b600000.iommu: 	stream matching with 2 register groups
[    9.697574] arm-smmu 2b600000.iommu: 	1 context banks (1 stage-2 only)
[    9.704214] arm-smmu 2b600000.iommu: 	Supported page sizes: 0x60211000
[    9.710849] arm-smmu 2b600000.iommu: 	Stage-2: 40-bit IPA -> 40-bit PA
[    9.720694] input: smb@8000000:motherboard:gpio-keys as /devices/platform/smb@8000000/smb@8000000:motherboard/smb@8000000:motherboard:gpio-keys/input/input1
[    9.737183] rtc-pl031 1c170000.rtc: setting system clock to 2020-03-25T14:11:59 UTC (1585145519)
[   10.060137] usb 1-1.1: new high-speed USB device number 3 using ehci-platform
[   10.105383] usb-storage 1-1.1:1.0: USB Mass Storage device detected
[   10.119740] scsi host2: usb-storage 1-1.1:1.0
[   10.280188] atkbd serio0: keyboard reset failed on 1c060000.kmi
[   10.780087] ata1: SATA link down (SStatus 0 SControl 0)
[   11.150232] scsi 2:0:0:0: Direct-Access     TOSHIBA  TransMemory      PMAP PQ: 0 ANSI: 6
[   11.163134] sd 2:0:0:0: [sda] 30253056 512-byte logical blocks: (15.5 GB/14.4 GiB)
[   11.172288] sd 2:0:0:0: [sda] Write Protect is off
[   11.177604] sd 2:0:0:0: [sda] Mode Sense: 45 00 00 00
[   11.184331] sd 2:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[   11.264921]  sda: sda1 sda2
[   11.293352] sd 2:0:0:0: [sda] Attached SCSI removable disk
[   11.528536] atkbd serio1: keyboard reset failed on 1c070000.kmi
[   12.836137] ata2: SATA link down (SStatus 0 SControl 0)
[   12.849154] sky2 0000:08:00.0 eth0: enabling interface
[   12.855704] Generic PHY 18000000.ethernet-ffffffff:01: attached PHY driver [Generic PHY] (mii_bus:phy_addr=18000000.ethernet-ffffffff:01, irq=POLL)
[   12.880247] smsc911x 18000000.ethernet eth1: SMSC911x/921x identified at 0xffff800018cb0000, IRQ: 8
[   14.928231] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[   14.948102] Sending DHCP requests ., OK
[   15.068128] ALSA device list:
[   15.071357]   No soundcards found.
[   15.076585] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
[   15.085596] uart-pl011 7ff80000.uart: no DMA platform data
[   15.091359] platform regulatory.0: Falling back to sysfs fallback for: regulatory.db
[   15.120243] Freeing unused kernel memory: 14656K
[   15.128168] Run /init as init process
[   15.131870]   with arguments:
[   15.134909]     /init
[   15.137239]     ttyAMA0,115200n8
[   15.140526]     verbose
[   15.142998]     nfsrootdebug
[   15.145933]   with environment:
[   15.149131]     HOME=/
[   15.151515]     TERM=linux
[   15.154273]     user_debug=31
[   15.280504] Adding 2543608k swap on /dev/sda2.  Priority:-2 extents:1 across:2543608k 
[   18.132184] input: PS/2 Generic Mouse as /devices/platform/smb@8000000/smb@8000000:motherboard/smb@8000000:motherboard:iofpga@3,00000000/1c060000.kmi/serio0/input/input3
[   18.256896] psmouse serio0: Failed to enable mouse on 1c060000.kmi
[   19.369253] random: dd: uninitialized urandom read (512 bytes read)
[   19.503090] random: ssh-keygen: uninitialized urandom read (32 bytes read)
[   19.533868] random: sshd: uninitialized urandom read (32 bytes read)
[   19.614518] sky2 0000:08:00.0 eth0: enabling interface
[   24.632590] input: PS/2 Generic Mouse as /devices/platform/smb@8000000/smb@8000000:motherboard/smb@8000000:motherboard:iofpga@3,00000000/1c070000.kmi/serio1/input/input4
[   24.756753] psmouse serio1: Failed to enable mouse on 1c070000.kmi
[   77.066210] cfg80211: failed to load regulatory.db
[  109.484923] PM: hibernation: hibernation entry
[  109.505798] Filesystems sync: 0.003 seconds
[  109.510720] Freezing user space processes ... (elapsed 0.004 seconds) done.
[  109.522347] OOM killer disabled.
[  109.535034] PM: hibernation: Preallocating image memory
[  110.858314] PM: hibernation: Allocated 96587 pages for snapshot
[  110.864358] PM: hibernation: Allocated 386348 kbytes in 1.31 seconds (294.92 MB/s)
[  110.872058] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[  110.883798] printk: Suspending console(s) (use no_console_suspend to debug)
[  110.894359] ohci-platform 7ffb0000.ohci: ohci_platform_suspend : ret=0
[  110.908778] usbcore:hub_suspend: hub 1-1:1.0: hub_suspend
[  110.911448] usbcore:hub_suspend: hub 1-0:1.0: hub_suspend
[  110.911588] usbcore:hcd_bus_suspend: usb usb1: bus suspend, wakeup 0
[  110.942466] Disabling non-boot CPUs ...
[  110.945799] CPU1: shutdown
[  110.945826] psci: CPU1 killed (polled 0 ms)
[  110.951729] CPU2: shutdown
[  110.952840] psci: CPU2 killed (polled 4 ms)
[  110.959068] CPU3: shutdown
[  110.959097] psci: CPU3 killed (polled 0 ms)
[  110.964518] CPU4: shutdown
[  110.964547] psci: CPU4 killed (polled 0 ms)
[  110.969407] CPU5: shutdown
[  110.969434] psci: CPU5 killed (polled 0 ms)
[  110.971466] PM: hibernation: Creating image:
[  110.971466] PM: hibernation: Need to copy 95098 pages
[  110.971466] PM: hibernation: Image created (95098 pages copied)
[  110.972416] Enabling non-boot CPUs ...
[  110.986470] Detected PIPT I-cache on CPU1
[  110.986534] CPU1: Booted secondary processor 0x0000000000 [0x410fd080]
[  110.989804] CPU1 is up
[  111.003759] Detected PIPT I-cache on CPU2
[  111.003798] CPU2: Booted secondary processor 0x0000000001 [0x410fd080]
[  111.005181] CPU2 is up
[  111.018850] Detected VIPT I-cache on CPU3
[  111.018945] CPU3: Booted secondary processor 0x0000000101 [0x410fd033]
[  111.022529] CPU3 is up
[  111.036187] Detected VIPT I-cache on CPU4
[  111.036263] CPU4: Booted secondary processor 0x0000000102 [0x410fd033]
[  111.040050] CPU4 is up
[  111.053709] Detected VIPT I-cache on CPU5
[  111.053784] CPU5: Booted secondary processor 0x0000000103 [0x410fd033]
[  111.058844] CPU5 is up
[  111.080887] usbcore:hcd_bus_resume: usb usb1: usb resume
[  111.084174] ohci-platform 7ffb0000.ohci: ohci_platform_resume
[  111.111950] usbcore:hcd_bus_resume: usb usb2: usb resume
[  111.138939] usbcore:hub_resume: hub 1-0:1.0: hub_resume
[  111.139333] usbcore:hub_activate: usb usb1-port1: status 0503 change 0000
[  111.139718] usbcore:hub_resume: hub 1-1:1.0: hub_resume
[  111.140090] usbcore:hub_activate: usb 1-1-port1: status 0503 change 0000
[  111.187608] usbcore:hub_resume: hub 2-0:1.0: hub_resume
[  111.187893] usb usb2: runtime PM trying to activate child device usb2 but parent (7ffb0000.ohci) is not active
[  111.187979] CPU: 3 PID: 369 Comm: kworker/u12:6 Not tainted 5.6.0-rc6-00002-gdfd1731f9a3e-dirty #545
[  111.187994] Hardware name: ARM Juno development board (r2) (DT)
[  111.188022] Workqueue: events_unbound async_run_entry_fn
[  111.188041] Call trace:
[  111.188060]  dump_backtrace+0x0/0x1d8
[  111.188077]  show_stack+0x24/0x30
[  111.188096]  dump_stack+0xe8/0x150
[  111.188116]  __pm_runtime_set_status+0x1b8/0x2e8
[  111.188135]  usb_resume+0x64/0x88
[  111.188152]  usb_dev_thaw+0x24/0x30
[  111.188170]  dpm_run_callback+0x90/0x348
[  111.188188]  device_resume+0xe0/0x1c8
[  111.188205]  async_resume+0x30/0x60
[  111.188223]  async_run_entry_fn+0x48/0x1a8
[  111.188242]  process_one_work+0x2a4/0x748
[  111.188259]  worker_thread+0x48/0x498
[  111.188276]  kthread+0x13c/0x140
[  111.188294]  ret_from_fork+0x10/0x18
[  111.473320] PM: Cannot find swap device, try swapon -a
[  111.478559] PM: Cannot get swap writer
[  111.740186] OOM killer enabled.
[  111.743377] Restarting tasks ... 
[  111.744458] usbcore:hub_event: hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0000
[  111.744660] usbcore:hub_event: hub 1-1:1.0: state 7 ports 4 chg 0000 evt 0000
[  111.744971] done.
[  111.748289] usbcore:hub_event: hub 2-0:1.0: state 7 ports 1 chg 0000 evt 0000
[  111.773192] usbcore:hub_resume: hub 2-0:1.0: hub_resume
[  111.773249] PM: hibernation: hibernation exit
[  111.779649] ------------[ cut here ]------------
[  111.788382] URB (____ptrval____) submitted while active
[  111.796646] WARNING: CPU: 3 PID: 365 at drivers/usb/core/urb.c:363 usb_submit_urb+0x3d8/0x590
[  111.805417] Modules linked in:
[  111.808584] CPU: 3 PID: 365 Comm: kworker/3:2 Not tainted 5.6.0-rc6-00002-gdfd1731f9a3e-dirty #545
[  111.817796] Hardware name: ARM Juno development board (r2) (DT)
[  111.823896] Workqueue: usb_hub_wq hub_event
[  111.828217] pstate: 60000005 (nZCv daif -PAN -UAO)
[  111.833156] pc : usb_submit_urb+0x3d8/0x590
[  111.837471] lr : usb_submit_urb+0x3d8/0x590
[  111.841783] sp : ffff800018de38b0
[  111.845205] x29: ffff800018de38b0 x28: 0000000000000003 
[  111.850682] x27: ffff000970530b20 x26: ffff8000133fd000 
[  111.856159] x25: ffff8000133fd000 x24: ffff800018de3b38 
[  111.861635] x23: 0000000000000004 x22: 0000000000000c00 
[  111.867112] x21: 0000000000000000 x20: 00000000fffffff0 
[  111.872589] x19: ffff0009704e7a00 x18: ffffffffffffffff 
[  111.878065] x17: 00000000a7c8f4bc x16: 000000002af33de8 
[  111.883542] x15: ffff8000133fda88 x14: 0720072007200720 
[  111.889019] x13: 0720072007200720 x12: 0720072007200720 
[  111.894496] x11: 0000000000000000 x10: 00000000a5286134 
[  111.899973] x9 : 0000000000000002 x8 : ffff000970c837a0 
[  111.905449] x7 : 0000000000000000 x6 : ffff800018de3570 
[  111.910926] x5 : 0000000000000001 x4 : 0000000000000003 
[  111.916401] x3 : 0000000000000000 x2 : ffff800013427118 
[  111.921879] x1 : 9d4e965b4b7d7c00 x0 : 0000000000000000 
[  111.927356] Call trace:
[  111.929892]  usb_submit_urb+0x3d8/0x590
[  111.933852]  hub_activate+0x108/0x7f0
[  111.937633]  hub_resume+0xac/0x148
[  111.941149]  usb_resume_interface.isra.10+0x60/0x138
[  111.946265]  usb_resume_both+0xe4/0x140
[  111.950225]  usb_runtime_resume+0x24/0x30
[  111.954365]  __rpm_callback+0xdc/0x138
[  111.958236]  rpm_callback+0x34/0x98
[  111.961841]  rpm_resume+0x4a8/0x720
[  111.965445]  rpm_resume+0x50c/0x720
[  111.969049]  __pm_runtime_resume+0x4c/0xb8
[  111.973276]  usb_autopm_get_interface+0x28/0x60
[  111.977948]  hub_event+0x80/0x16d8
[  111.981466]  process_one_work+0x2a4/0x748
[  111.985604]  worker_thread+0x48/0x498
[  111.989387]  kthread+0x13c/0x140
[  111.992725]  ret_from_fork+0x10/0x18
[  111.996415] irq event stamp: 354
[  111.999756] hardirqs last  enabled at (353): [<ffff80001019ea1c>] console_unlock+0x504/0x5b8
[  112.008441] hardirqs last disabled at (354): [<ffff8000100a95d0>] do_debug_exception+0x1a8/0x258
[  112.017479] softirqs last  enabled at (350): [<ffff8000100818a4>] __do_softirq+0x4bc/0x568
[  112.025984] softirqs last disabled at (343): [<ffff8000101145a4>] irq_exit+0x144/0x150
[  112.034129] ---[ end trace dc96030b9cf6c8a3 ]---
[  112.039119] hub 2-0:1.0: activate --> -16
[  112.043367] usbcore:hub_event: hub 2-0:1.0: state 7 ports 1 chg 0000 evt 0000
[  112.050825] usbcore:hub_suspend: hub 2-0:1.0: hub_suspend
[  112.056596] usbcore:hcd_bus_suspend: usb usb2: bus auto-suspend, wakeup 1
[  113.131730] ata1: SATA link down (SStatus 0 SControl 0)
[  113.138068] ata2: SATA link down (SStatus 0 SControl 0)
[  117.651706] psmouse serio0: Failed to enable mouse on 1c060000.kmi
[  124.239499] psmouse serio1: Failed to enable mouse on 1c070000.kmi

^ permalink raw reply related	[flat|nested] 50+ messages in thread

* Re: lockdep warning in urb.c:363 usb_submit_urb
  2020-03-25 15:00                       ` Qais Yousef
@ 2020-03-25 20:49                         ` Alan Stern
  2020-03-25 21:28                           ` Rafael J. Wysocki
  2020-04-20 20:26                           ` Alan Stern
  0 siblings, 2 replies; 50+ messages in thread
From: Alan Stern @ 2020-03-25 20:49 UTC (permalink / raw)
  To: Qais Yousef, Rafael J. Wysocki
  Cc: Oliver Neukum, Greg Kroah-Hartman, USB list,
	Linux-pm mailing list, Kernel development list

On Wed, 25 Mar 2020, Qais Yousef wrote:

> Thanks for all the hints Alan.
> 
> I think I figured it out, the below patch seems to fix it for me. Looking
> at other drivers resume functions it seems we're missing the
> pm_runtime_disable()->set_active()->enable() dance. Doing that fixes the
> warning and the dev_err() in driver/base/power.

Ah, yes.  This should have been added years ago; guess I forgot.  :-(

> I don't see xhci-plat.c doing that, I wonder if it needs it too.
> 
> I'm not well versed about the details and the rules here. So my fix could be
> a hack, though it does seem the right thing to do.
> 
> I wonder why the power core doesn't handle this transparently..

Initially, we didn't want the PM core to do this automatically because
we thought some devices might want to remain runtime-suspended
following a system resume, and only the device driver would know what 
to do.

Raphael, now that we have the direct_complete mechanism, can we revisit 
this?  Should the PM core automatically call pm_runtime_set_active() if 
dev->power.direct_complete isn't set?  Perhaps in device_resume_early() 
prior to the pm_runtime_enable() call?

It's possible we discussed this and decided against it at the time when 
direct_complete was added, but if so I don't remember what was said.

Alan Stern

> diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
> index 7addfc2cbadc..eb92c8092fae 100644
> --- a/drivers/usb/host/ohci-platform.c
> +++ b/drivers/usb/host/ohci-platform.c
> @@ -299,6 +299,10 @@ static int ohci_platform_resume(struct device *dev)
>         }
> 
>         ohci_resume(hcd, false);
> +
> +       pm_runtime_disable(dev);
> +       pm_runtime_set_active(dev);
> +       pm_runtime_enable(dev);
>         return 0;
>  }
>  #endif /* CONFIG_PM_SLEEP */
> 
> 
> Thanks
> 
> --
> Qais Yousef



^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: lockdep warning in urb.c:363 usb_submit_urb
  2020-03-25 20:49                         ` Alan Stern
@ 2020-03-25 21:28                           ` Rafael J. Wysocki
  2020-03-26 12:27                             ` Qais Yousef
  2020-04-20 20:26                           ` Alan Stern
  1 sibling, 1 reply; 50+ messages in thread
From: Rafael J. Wysocki @ 2020-03-25 21:28 UTC (permalink / raw)
  To: Alan Stern
  Cc: Qais Yousef, Rafael J. Wysocki, Oliver Neukum,
	Greg Kroah-Hartman, USB list, Linux-pm mailing list,
	Kernel development list

On Wed, Mar 25, 2020 at 9:49 PM Alan Stern <stern@rowland.harvard.edu> wrote:
>
> On Wed, 25 Mar 2020, Qais Yousef wrote:
>
> > Thanks for all the hints Alan.
> >
> > I think I figured it out, the below patch seems to fix it for me. Looking
> > at other drivers resume functions it seems we're missing the
> > pm_runtime_disable()->set_active()->enable() dance. Doing that fixes the
> > warning and the dev_err() in driver/base/power.
>
> Ah, yes.  This should have been added years ago; guess I forgot.  :-(
>
> > I don't see xhci-plat.c doing that, I wonder if it needs it too.
> >
> > I'm not well versed about the details and the rules here. So my fix could be
> > a hack, though it does seem the right thing to do.
> >
> > I wonder why the power core doesn't handle this transparently..
>
> Initially, we didn't want the PM core to do this automatically because
> we thought some devices might want to remain runtime-suspended
> following a system resume, and only the device driver would know what
> to do.
>
> Raphael, now that we have the direct_complete mechanism, can we revisit
> this?  Should the PM core automatically call pm_runtime_set_active() if
> dev->power.direct_complete isn't set?  Perhaps in device_resume_early()
> prior to the pm_runtime_enable() call?
>
> It's possible we discussed this and decided against it at the time when
> direct_complete was added, but if so I don't remember what was said.

Me neither. :-)

That said complexity has grown since then and there are the
DPM_FLAG_SMART_SUSPEND and DPM_FLAG_LEAVE_SUSPENDED flags that can be
used to control that behavior to some extent.

Setting DPM_FLAG_SMART_SUSPEND alone, in particular, causes
pm_runtime_set_active() to be called at the noirq stage of device
resume either by the core or by bus types (e.g. PCI) etc.

It looks like ohci-platform might use DPM_FLAG_SMART_SUSPEND, but I
need to take a closer look at that (possibly later this week).

Cheers!


>
> > diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
> > index 7addfc2cbadc..eb92c8092fae 100644
> > --- a/drivers/usb/host/ohci-platform.c
> > +++ b/drivers/usb/host/ohci-platform.c
> > @@ -299,6 +299,10 @@ static int ohci_platform_resume(struct device *dev)
> >         }
> >
> >         ohci_resume(hcd, false);
> > +
> > +       pm_runtime_disable(dev);
> > +       pm_runtime_set_active(dev);
> > +       pm_runtime_enable(dev);
> >         return 0;
> >  }
> >  #endif /* CONFIG_PM_SLEEP */
> >
> >
> > Thanks
> >
> > --
> > Qais Yousef
>
>

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: lockdep warning in urb.c:363 usb_submit_urb
  2020-03-25 21:28                           ` Rafael J. Wysocki
@ 2020-03-26 12:27                             ` Qais Yousef
  2020-03-27 20:45                               ` Alan Stern
  0 siblings, 1 reply; 50+ messages in thread
From: Qais Yousef @ 2020-03-26 12:27 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Alan Stern, Rafael J. Wysocki, Oliver Neukum, Greg Kroah-Hartman,
	USB list, Linux-pm mailing list, Kernel development list

On 03/25/20 22:28, Rafael J. Wysocki wrote:
> On Wed, Mar 25, 2020 at 9:49 PM Alan Stern <stern@rowland.harvard.edu> wrote:
> >
> > On Wed, 25 Mar 2020, Qais Yousef wrote:
> >
> > > Thanks for all the hints Alan.
> > >
> > > I think I figured it out, the below patch seems to fix it for me. Looking
> > > at other drivers resume functions it seems we're missing the
> > > pm_runtime_disable()->set_active()->enable() dance. Doing that fixes the
> > > warning and the dev_err() in driver/base/power.
> >
> > Ah, yes.  This should have been added years ago; guess I forgot.  :-(
> >
> > > I don't see xhci-plat.c doing that, I wonder if it needs it too.
> > >
> > > I'm not well versed about the details and the rules here. So my fix could be
> > > a hack, though it does seem the right thing to do.
> > >
> > > I wonder why the power core doesn't handle this transparently..
> >
> > Initially, we didn't want the PM core to do this automatically because
> > we thought some devices might want to remain runtime-suspended
> > following a system resume, and only the device driver would know what
> > to do.
> >
> > Raphael, now that we have the direct_complete mechanism, can we revisit
> > this?  Should the PM core automatically call pm_runtime_set_active() if
> > dev->power.direct_complete isn't set?  Perhaps in device_resume_early()
> > prior to the pm_runtime_enable() call?
> >
> > It's possible we discussed this and decided against it at the time when
> > direct_complete was added, but if so I don't remember what was said.
> 
> Me neither. :-)
> 
> That said complexity has grown since then and there are the
> DPM_FLAG_SMART_SUSPEND and DPM_FLAG_LEAVE_SUSPENDED flags that can be
> used to control that behavior to some extent.
> 
> Setting DPM_FLAG_SMART_SUSPEND alone, in particular, causes
> pm_runtime_set_active() to be called at the noirq stage of device
> resume either by the core or by bus types (e.g. PCI) etc.
> 
> It looks like ohci-platform might use DPM_FLAG_SMART_SUSPEND, but I
> need to take a closer look at that (possibly later this week).

Okay I take it this was root caused correctly and now it's a question of which
is a better fix.

Thanks!

--
Qais Yousef

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: lockdep warning in urb.c:363 usb_submit_urb
  2020-03-26 12:27                             ` Qais Yousef
@ 2020-03-27 20:45                               ` Alan Stern
  2020-03-28 14:15                                 ` Rafael J. Wysocki
  0 siblings, 1 reply; 50+ messages in thread
From: Alan Stern @ 2020-03-27 20:45 UTC (permalink / raw)
  To: Rafael J. Wysocki, Qais Yousef
  Cc: USB list, Linux-pm mailing list, Kernel development list

On Thu, 26 Mar 2020, Qais Yousef wrote:

> On 03/25/20 22:28, Rafael J. Wysocki wrote:
> > On Wed, Mar 25, 2020 at 9:49 PM Alan Stern <stern@rowland.harvard.edu> wrote:

> > > Raphael, now that we have the direct_complete mechanism, can we revisit
> > > this?  Should the PM core automatically call pm_runtime_set_active() if
> > > dev->power.direct_complete isn't set?  Perhaps in device_resume_early()
> > > prior to the pm_runtime_enable() call?
> > >
> > > It's possible we discussed this and decided against it at the time when
> > > direct_complete was added, but if so I don't remember what was said.
> > 
> > Me neither. :-)
> > 
> > That said complexity has grown since then and there are the
> > DPM_FLAG_SMART_SUSPEND and DPM_FLAG_LEAVE_SUSPENDED flags that can be
> > used to control that behavior to some extent.
> > 
> > Setting DPM_FLAG_SMART_SUSPEND alone, in particular, causes
> > pm_runtime_set_active() to be called at the noirq stage of device
> > resume either by the core or by bus types (e.g. PCI) etc.
> > 
> > It looks like ohci-platform might use DPM_FLAG_SMART_SUSPEND, but I
> > need to take a closer look at that (possibly later this week).
> 
> Okay I take it this was root caused correctly and now it's a question of which
> is a better fix.

Indeed.

Raphael, I've been going over the PM core code, trying to figure out
what it's really doing.  It's kind of a mess.

A large part of the problem is related to an inconsistency between the
documentation and the code.  include/linux/pm.h says that
DPM_FLAG_SMART_SUSPEND tells bus types and PM domains about what the
driver wants.  This strongly implies that the PM core will ignore
SMART_SUSPEND.  But in fact the core does check that flag and takes its
own actions if the device has no subsystem-level callbacks!

Furthermore, the PM core's actions don't seem to make sense.  If the
flag is set and the device is runtime-suspended when the system sleep
begins, the core will skip issuing the suspend_late and suspend_noirq
callbacks to the driver.  But it doesn't skip issuing the suspend
callback!  I can't figure that out.  Furthermore, the decisions about
whether to skip the resume_noirq, resume_early, and resume callbacks
are based on different criteria from the decisions on the suspend side.

That's not all: The SMART_SUSPEND decisions completely ignore the value
of DPM_FLAG_NEVER_SKIP!  NEVER_SKIP affects only the direct_completion
pathway.

SMART_SUSPEND seems to have two different meanings.  (1) If the device 
is already in runtime suspend when a system sleep starts, skip the 
suspend_late and suspend_noirq callbacks.  (2) Under certain (similar) 
circumstances, skip the resume callbacks.  The documentation only 
mentions (1) but the code also handles (2).

Other things in there also seem strange.  device_prepare() does a
WARN_ON if either SMART_SUSPEND or LEAVE_SUSPENDED is set and the
device is not runtime-PM-enabled.  That's understandable, but it's also
racy.  A system sleep can begin at any time; how can a driver know when
it is safe to disable a device's runtime PM briefly?

When device_prepare() calculates the power.direct_complete flag, it
checks to see whether the device is currently in runtime suspend in
some cases but not in others, as in the code added by your commit
c62ec4610c40 ("PM / core:  Fix direct_complete handling for devices
with no callbacks").  Since the runtime-PM state is going to checked in
__device_suspend() anyway, we shouldn't need to check it here at all.

At a couple of points in the code, THAW and RESTORE events are each
treatedly specially, with no explanation.

The power.may_skip_resume flag is used in only one place, when 
LEAVE_SUSPENDED is set and there are subsystem-level callbacks.  In 
particular, it is _not_ used by dev_pm_may_skip_resume().  That seems 
highly suspicious at best.

I think it would be worthwhile to expend some serious effort
straightening all this stuff out.  Perhaps we could start with a more
explicit description of what is supposed to happen at each step.  
(Things to be careful about include phrases like "leave suspended",
which is not the same as "don't call the resume callbacks", even though
the two are easily conflated.)

What do you think?

Alan Stern


^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: lockdep warning in urb.c:363 usb_submit_urb
  2020-03-27 20:45                               ` Alan Stern
@ 2020-03-28 14:15                                 ` Rafael J. Wysocki
  2020-03-28 19:58                                   ` Alan Stern
  0 siblings, 1 reply; 50+ messages in thread
From: Rafael J. Wysocki @ 2020-03-28 14:15 UTC (permalink / raw)
  To: Alan Stern
  Cc: Rafael J. Wysocki, Qais Yousef, USB list, Linux-pm mailing list,
	Kernel development list

On Friday, March 27, 2020 9:45:09 PM CET Alan Stern wrote:
> On Thu, 26 Mar 2020, Qais Yousef wrote:
> 
> > On 03/25/20 22:28, Rafael J. Wysocki wrote:
> > > On Wed, Mar 25, 2020 at 9:49 PM Alan Stern <stern@rowland.harvard.edu> wrote:
> 
> > > > Raphael, now that we have the direct_complete mechanism, can we revisit
> > > > this?  Should the PM core automatically call pm_runtime_set_active() if
> > > > dev->power.direct_complete isn't set?  Perhaps in device_resume_early()
> > > > prior to the pm_runtime_enable() call?
> > > >
> > > > It's possible we discussed this and decided against it at the time when
> > > > direct_complete was added, but if so I don't remember what was said.
> > > 
> > > Me neither. :-)
> > > 
> > > That said complexity has grown since then and there are the
> > > DPM_FLAG_SMART_SUSPEND and DPM_FLAG_LEAVE_SUSPENDED flags that can be
> > > used to control that behavior to some extent.
> > > 
> > > Setting DPM_FLAG_SMART_SUSPEND alone, in particular, causes
> > > pm_runtime_set_active() to be called at the noirq stage of device
> > > resume either by the core or by bus types (e.g. PCI) etc.
> > > 
> > > It looks like ohci-platform might use DPM_FLAG_SMART_SUSPEND, but I
> > > need to take a closer look at that (possibly later this week).
> > 
> > Okay I take it this was root caused correctly and now it's a question of which
> > is a better fix.
> 
> Indeed.
> 
> Raphael, I've been going over the PM core code, trying to figure out
> what it's really doing.  It's kind of a mess.

Well, sorry about that. 

> A large part of the problem is related to an inconsistency between the
> documentation and the code.  include/linux/pm.h says that
> DPM_FLAG_SMART_SUSPEND tells bus types and PM domains about what the
> driver wants.  This strongly implies that the PM core will ignore
> SMART_SUSPEND.  But in fact the core does check that flag and takes its
> own actions if the device has no subsystem-level callbacks!

Right, which is because in those cases there is no "middle layer" between
the driver and the core and if you want the driver to work both with
something like genpd or the ACPI PM domain and without anything like that,
the core needs to take those actions for consistency.

> Furthermore, the PM core's actions don't seem to make sense.  If the
> flag is set and the device is runtime-suspended when the system sleep
> begins, the core will skip issuing the suspend_late and suspend_noirq
> callbacks to the driver.  But it doesn't skip issuing the suspend
> callback!  I can't figure that out.

That's because if the core gets to executing ->suspend_late, PM-runtime has
been disabled for the device and if the device is runtime-suspended at that
point, so (at least if SMART_SUSPEND is set for the device) there is no reason
to do anything more to it.

> Furthermore, the decisions about
> whether to skip the resume_noirq, resume_early, and resume callbacks
> are based on different criteria from the decisions on the suspend side.

Right, because there are drivers that don't want devices to stay in suspend
after system resume even though they have been left in suspend by it.

Arguably, they could be left in suspend and then resumed after the completion
of system suspend, but that would add quite a bit of latency if the device
needs to be accessed right after the system suspend is complete.

> That's not all: The SMART_SUSPEND decisions completely ignore the value
> of DPM_FLAG_NEVER_SKIP!  NEVER_SKIP affects only the direct_completion
> pathway.

As documented AFAICS.

> SMART_SUSPEND seems to have two different meanings.  (1) If the device 
> is already in runtime suspend when a system sleep starts, skip the 
> suspend_late and suspend_noirq callbacks.  (2) Under certain (similar) 
> circumstances, skip the resume callbacks.  The documentation only 
> mentions (1) but the code also handles (2).

That's because (2) is the THAW case and I was distracted before I got
to documenting it properly.  Sorry.

The problem is that if you leave the device in runtime suspend, calling
->freeze_late() or ->freeze_noirq() on it is not useful and if you have
skipped those, running the corresponding "thaw" callbacks is not useful
either (what would they do, specifically?).

There is a whole problem of whether or not devices should be left in
runtime suspend during hibernation and I have not had a chance to get
to the bottom of that yet.

> Other things in there also seem strange.  device_prepare() does a
> WARN_ON if either SMART_SUSPEND or LEAVE_SUSPENDED is set and the
> device is not runtime-PM-enabled.  That's understandable, but it's also
> racy.

I guess you mean the check in device_prepare().

> A system sleep can begin at any time; how can a driver know when
> it is safe to disable a device's runtime PM briefly?

Well, fair enough, but then I'm not sure if there is a good place for this
check at all, because drivers can briefly disable PM-runtime at any time in
theory.

> When device_prepare() calculates the power.direct_complete flag, it
> checks to see whether the device is currently in runtime suspend in
> some cases but not in others, as in the code added by your commit
> c62ec4610c40 ("PM / core:  Fix direct_complete handling for devices
> with no callbacks").  Since the runtime-PM state is going to checked in
> __device_suspend() anyway, we shouldn't need to check it here at all.

I guess the point is that in theory the device can be runtime-suspended
between device_prepare() and _device_suspend(), is by checking the status
in the former, we lose the opportunity to leave it in suspend if that
happens.

OK, fair enough.

> At a couple of points in the code, THAW and RESTORE events are each
> treatedly specially, with no explanation.

Right, which is related to the kind of work in progress situation regarding
the flags and hibernation mentioned above.  Again, sorry about that.

> The power.may_skip_resume flag is used in only one place, when 
> LEAVE_SUSPENDED is set and there are subsystem-level callbacks.  In 
> particular, it is _not_ used by dev_pm_may_skip_resume().  That seems 
> highly suspicious at best.

That's because it's for the middle-layer (subsystem-level) code to let the
core know that skipping the resume would be OK.

The core doesn't need that flag when it decides by itself.

> I think it would be worthwhile to expend some serious effort
> straightening all this stuff out.  Perhaps we could start with a more
> explicit description of what is supposed to happen at each step.  
> (Things to be careful about include phrases like "leave suspended",
> which is not the same as "don't call the resume callbacks", even though
> the two are easily conflated.)
> 
> What do you think?

I am certainly not going to reject any help. :-)

Also, I'm not against clarifying anything that is not clear enough.

Cheers!




^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: lockdep warning in urb.c:363 usb_submit_urb
  2020-03-28 14:15                                 ` Rafael J. Wysocki
@ 2020-03-28 19:58                                   ` Alan Stern
  2020-03-29  9:16                                     ` Rafael J. Wysocki
  0 siblings, 1 reply; 50+ messages in thread
From: Alan Stern @ 2020-03-28 19:58 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Rafael J. Wysocki, Qais Yousef, USB list, Linux-pm mailing list,
	Kernel development list

On Sat, 28 Mar 2020, Rafael J. Wysocki wrote:

> On Friday, March 27, 2020 9:45:09 PM CET Alan Stern wrote:

> > Raphael, I've been going over the PM core code, trying to figure out
> > what it's really doing.  It's kind of a mess.
> 
> Well, sorry about that. 
> 
> > A large part of the problem is related to an inconsistency between the
> > documentation and the code.  include/linux/pm.h says that
> > DPM_FLAG_SMART_SUSPEND tells bus types and PM domains about what the
> > driver wants.  This strongly implies that the PM core will ignore
> > SMART_SUSPEND.  But in fact the core does check that flag and takes its
> > own actions if the device has no subsystem-level callbacks!
> 
> Right, which is because in those cases there is no "middle layer" between
> the driver and the core and if you want the driver to work both with
> something like genpd or the ACPI PM domain and without anything like that,
> the core needs to take those actions for consistency.

Sure, the core is acting as a proxy for the missing subsystem
callbacks.  Still, it should be documented properly.

Also, couldn't we simplify the behavior?  Right now the core checks
that there are no subsystem-level callbacks for any of _early, _late,
and _noirq variants before skipping a callback.  Couldn't we forget
about all that checking and simply skip the device-level callbacks?  
(Yes, I realize this could lead to inconsistent behavior if the
subsystem has some callbacks defined but not others -- but subsystems
should never do that, at least, not if it would lead to trouble.)

Another issue is that the documentation exists in two separate places:
include/linux/pm.h and Documentation/driver-api/devices.rst (plus a
brief mention in Documentation/power/runtime_pm.rst).  This leads to
incompleteness and inconsistencies.  Ideally there would be a complete
explanation in one place (probably the devices.rst file) and the others
would refer to it.

> > Furthermore, the PM core's actions don't seem to make sense.  If the
> > flag is set and the device is runtime-suspended when the system sleep
> > begins, the core will skip issuing the suspend_late and suspend_noirq
> > callbacks to the driver.  But it doesn't skip issuing the suspend
> > callback!  I can't figure that out.
> 
> That's because if the core gets to executing ->suspend_late, PM-runtime has
> been disabled for the device and if the device is runtime-suspended at that
> point, so (at least if SMART_SUSPEND is set for the device) there is no reason
> to do anything more to it.

But if SMART_SUSPEND is set and the device is runtime-suspended, why 
issue the ->suspend callback?  Why not just do pm_runtime_disable() 
then (to prevent the device from resuming) and skip the callback?

> > Furthermore, the decisions about
> > whether to skip the resume_noirq, resume_early, and resume callbacks
> > are based on different criteria from the decisions on the suspend side.
> 
> Right, because there are drivers that don't want devices to stay in suspend
> after system resume even though they have been left in suspend by it.

This suggests that sometimes we may want to issue non-matching 
callbacks.  For example, ->resume_noirq, ->resume_early, and ->resume
but not ->suspend, ->suspend_late, or ->suspend_noirq.  Is that what 
you are saying?

> Arguably, they could be left in suspend and then resumed after the completion
> of system suspend, but that would add quite a bit of latency if the device
> needs to be accessed right after the system suspend is complete.
> 
> > That's not all: The SMART_SUSPEND decisions completely ignore the value
> > of DPM_FLAG_NEVER_SKIP!  NEVER_SKIP affects only the direct_completion
> > pathway.
> 
> As documented AFAICS.

But highly confusing.  Maybe we can change the name to, say, 
DPM_FLAG_NO_DIRECT_COMPLETE.

> > SMART_SUSPEND seems to have two different meanings.  (1) If the device 
> > is already in runtime suspend when a system sleep starts, skip the 
> > suspend_late and suspend_noirq callbacks.  (2) Under certain (similar) 
> > circumstances, skip the resume callbacks.  The documentation only 
> > mentions (1) but the code also handles (2).
> 
> That's because (2) is the THAW case and I was distracted before I got
> to documenting it properly.  Sorry.
> 
> The problem is that if you leave the device in runtime suspend, calling
> ->freeze_late() or ->freeze_noirq() on it is not useful and if you have
> skipped those, running the corresponding "thaw" callbacks is not useful
> either (what would they do, specifically?).
> 
> There is a whole problem of whether or not devices should be left in
> runtime suspend during hibernation and I have not had a chance to get
> to the bottom of that yet.

Not only that.  The distinction between SMART_SUSPEND and
direct_complete is rather subtle, and it doesn't seem to be carefully
explained anywhere.  In fact, I'm not sure I understand it myself.  :-)
For example, the direct_complete mechanism is very careful about not
leaving a device in runtime suspend if a descendant (or other dependent
device) will remain active.  Does SMART_SUSPEND behave similarly?  If
so, it isn't documented.

Besides, it seems like a mistake to try controlling (1) and (2)  
together (i.e., with one flag).  Can we do a better job of
separating the functions of SMART_SUSPEND and LEAVE_SUSPENDED?

> > Other things in there also seem strange.  device_prepare() does a
> > WARN_ON if either SMART_SUSPEND or LEAVE_SUSPENDED is set and the
> > device is not runtime-PM-enabled.  That's understandable, but it's also
> > racy.
> 
> I guess you mean the check in device_prepare().
> 
> > A system sleep can begin at any time; how can a driver know when
> > it is safe to disable a device's runtime PM briefly?
> 
> Well, fair enough, but then I'm not sure if there is a good place for this
> check at all, because drivers can briefly disable PM-runtime at any time in
> theory.

There probably isn't a good place for it.  We could just get rid of the 
WARN.  I've never heard of it triggering.

> > When device_prepare() calculates the power.direct_complete flag, it
> > checks to see whether the device is currently in runtime suspend in
> > some cases but not in others, as in the code added by your commit
> > c62ec4610c40 ("PM / core:  Fix direct_complete handling for devices
> > with no callbacks").  Since the runtime-PM state is going to checked in
> > __device_suspend() anyway, we shouldn't need to check it here at all.
> 
> I guess the point is that in theory the device can be runtime-suspended
> between device_prepare() and _device_suspend(), is by checking the status
> in the former, we lose the opportunity to leave it in suspend if that
> happens.
> 
> OK, fair enough.
> 
> > At a couple of points in the code, THAW and RESTORE events are each
> > treatedly specially, with no explanation.
> 
> Right, which is related to the kind of work in progress situation regarding
> the flags and hibernation mentioned above.  Again, sorry about that.

I haven't thought about those issues as much as you have.  Still, it 
seems obvious that the FREEZE/THAW phases should be very happy to leave 
devices in runtime suspend throughout (without even worrying about 
wakeup settings), and the RESTORE phase should always bring everything 
back out of runtime suspend.

What to do during the POWEROFF phase isn't so clear, because it depends
on how the platform handles the poweroff transition.

> > The power.may_skip_resume flag is used in only one place, when 
> > LEAVE_SUSPENDED is set and there are subsystem-level callbacks.  In 
> > particular, it is _not_ used by dev_pm_may_skip_resume().  That seems 
> > highly suspicious at best.
> 
> That's because it's for the middle-layer (subsystem-level) code to let the
> core know that skipping the resume would be OK.
> 
> The core doesn't need that flag when it decides by itself.

This may be another situation where changing a name would make things
clearer.  One doesn't immediately recognize that
dev_pm_may_skip_resume() applies only in cases where there is no
subsystem-level callback.

> > I think it would be worthwhile to expend some serious effort
> > straightening all this stuff out.  Perhaps we could start with a more
> > explicit description of what is supposed to happen at each step.  
> > (Things to be careful about include phrases like "leave suspended",
> > which is not the same as "don't call the resume callbacks", even though
> > the two are easily conflated.)
> > 
> > What do you think?
> 
> I am certainly not going to reject any help. :-)
> 
> Also, I'm not against clarifying anything that is not clear enough.

Okay, let's start with direct_complete.  The direct_complete mechanism
is applied to the SUSPEND and RESUME phases under the following
conditions:

	DPM_FLAG_NEVER_SKIP (or better, DPM_FLAG_NO_DIRECT_COMPLETE)
	is clear;  [Incidentally, since a driver can set this flag 
	whenever its ->prepare routine returns 0, why do we need
	DPM_FLAG_SMART_PREPARE?]

	Either the device has no system-PM callbacks at all or else the
	->prepare callback returns a positive value;

	All of the device's descendants and dependents also want to use
	direct_complete;

	Neither the device nor any of its descendants/dependents is
	enabled for wakeup;

	The device is runtime suspended just before the ->suspend
	callback would normally be issued.

When the mechanism applies, none of the suspend or resume callbacks (in
any of their normal, _early, _late, or _noirq variants) are issued,
only ->complete.  Consequently the device remains in runtime suspend
throughout the system sleep.

Currently, direct_complete is never applied during any of the system
hibernation phases (FREEZE, THAW, POWEROFF, RESTORE).  This may change
in the future.

Is this description correct and complete?  Can you give a similarly
succinct outline for how SMART_SUSPEND and LEAVE_SUSPENDED should work?  
And also describe how they differ from direct_complete and how they
interact with it?  (For example, how does setting both flags differ 
from returning a positive value from ->prepare?)

Alan Stern


^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: lockdep warning in urb.c:363 usb_submit_urb
  2020-03-28 19:58                                   ` Alan Stern
@ 2020-03-29  9:16                                     ` Rafael J. Wysocki
  2020-03-29 13:56                                       ` Rafael J. Wysocki
  2020-03-29 16:27                                       ` Alan Stern
  0 siblings, 2 replies; 50+ messages in thread
From: Rafael J. Wysocki @ 2020-03-29  9:16 UTC (permalink / raw)
  To: Alan Stern
  Cc: Rafael J. Wysocki, Rafael J. Wysocki, Qais Yousef, USB list,
	Linux-pm mailing list, Kernel development list

On Sat, Mar 28, 2020 at 8:58 PM Alan Stern <stern@rowland.harvard.edu> wrote:
>
> On Sat, 28 Mar 2020, Rafael J. Wysocki wrote:
>
> > On Friday, March 27, 2020 9:45:09 PM CET Alan Stern wrote:
>
> > > Raphael, I've been going over the PM core code, trying to figure out
> > > what it's really doing.  It's kind of a mess.
> >
> > Well, sorry about that.
> >
> > > A large part of the problem is related to an inconsistency between the
> > > documentation and the code.  include/linux/pm.h says that
> > > DPM_FLAG_SMART_SUSPEND tells bus types and PM domains about what the
> > > driver wants.  This strongly implies that the PM core will ignore
> > > SMART_SUSPEND.  But in fact the core does check that flag and takes its
> > > own actions if the device has no subsystem-level callbacks!
> >
> > Right, which is because in those cases there is no "middle layer" between
> > the driver and the core and if you want the driver to work both with
> > something like genpd or the ACPI PM domain and without anything like that,
> > the core needs to take those actions for consistency.
>
> Sure, the core is acting as a proxy for the missing subsystem
> callbacks.  Still, it should be documented properly.
>
> Also, couldn't we simplify the behavior?  Right now the core checks
> that there are no subsystem-level callbacks for any of _early, _late,
> and _noirq variants before skipping a callback.  Couldn't we forget
> about all that checking and simply skip the device-level callbacks?
> (Yes, I realize this could lead to inconsistent behavior if the
> subsystem has some callbacks defined but not others -- but subsystems
> should never do that, at least, not if it would lead to trouble.)

In quite a few cases the middle layer has nothing specific to do in a
given phase of suspend/resume, but the driver may.

Subsystems haven't been required to provide callbacks for all phases
so far, so this change would require some modifications in there.

I actually prefer the core to do more, even if that means more
complexity in it, to avoid possible subtle differences in behavior
between subsystems.

> Another issue is that the documentation exists in two separate places:
> include/linux/pm.h and Documentation/driver-api/devices.rst (plus a
> brief mention in Documentation/power/runtime_pm.rst).  This leads to
> incompleteness and inconsistencies.  Ideally there would be a complete
> explanation in one place (probably the devices.rst file) and the others
> would refer to it.

OK

> > > Furthermore, the PM core's actions don't seem to make sense.  If the
> > > flag is set and the device is runtime-suspended when the system sleep
> > > begins, the core will skip issuing the suspend_late and suspend_noirq
> > > callbacks to the driver.  But it doesn't skip issuing the suspend
> > > callback!  I can't figure that out.
> >
> > That's because if the core gets to executing ->suspend_late, PM-runtime has
> > been disabled for the device and if the device is runtime-suspended at that
> > point, so (at least if SMART_SUSPEND is set for the device) there is no reason
> > to do anything more to it.
>
> But if SMART_SUSPEND is set and the device is runtime-suspended, why
> issue the ->suspend callback?

The driver itself or the middle-layer may want to resume the device.

Arguably, it may do that in ->prepare() too, but see below.

> Why not just do pm_runtime_disable()
> then (to prevent the device from resuming) and skip the callback?

Because another driver may want to runtime-resume that device in order
to use it for something before ->suspend_late().  Of course, you may
argue that this means a missing device link or similar, so it is not
clear-cut.

The general rule is that "synchronous" PM-runtime can be expected to
work before ->suspend_late(), so ->suspend() callbacks should be able
to use it safely in all cases in principle.

That expectation goes against direct_complete in some cases, so
drivers need to set NEVER_SKIP (or whatever it will be called in the
future) to avoid that problem.

> > > Furthermore, the decisions about
> > > whether to skip the resume_noirq, resume_early, and resume callbacks
> > > are based on different criteria from the decisions on the suspend side.
> >
> > Right, because there are drivers that don't want devices to stay in suspend
> > after system resume even though they have been left in suspend by it.
>
> This suggests that sometimes we may want to issue non-matching
> callbacks.  For example, ->resume_noirq, ->resume_early, and ->resume
> but not ->suspend, ->suspend_late, or ->suspend_noirq.  Is that what
> you are saying?

Yes.

As per devices.rst:

"the driver must be prepared to
cope with the invocation of its system-wide resume callbacks back-to-back with
its ``->runtime_suspend`` one (without the intervening ``->runtime_resume`` and
so on) and the final state of the device must reflect the "active" runtime PM
status in that case."

> > Arguably, they could be left in suspend and then resumed after the completion
> > of system suspend, but that would add quite a bit of latency if the device
> > needs to be accessed right after the system suspend is complete.
> >
> > > That's not all: The SMART_SUSPEND decisions completely ignore the value
> > > of DPM_FLAG_NEVER_SKIP!  NEVER_SKIP affects only the direct_completion
> > > pathway.
> >
> > As documented AFAICS.
>
> But highly confusing.  Maybe we can change the name to, say,
> DPM_FLAG_NO_DIRECT_COMPLETE.

Sure, if that helps. :-)

> > > SMART_SUSPEND seems to have two different meanings.  (1) If the device
> > > is already in runtime suspend when a system sleep starts, skip the
> > > suspend_late and suspend_noirq callbacks.  (2) Under certain (similar)
> > > circumstances, skip the resume callbacks.  The documentation only
> > > mentions (1) but the code also handles (2).
> >
> > That's because (2) is the THAW case and I was distracted before I got
> > to documenting it properly.  Sorry.
> >
> > The problem is that if you leave the device in runtime suspend, calling
> > ->freeze_late() or ->freeze_noirq() on it is not useful and if you have
> > skipped those, running the corresponding "thaw" callbacks is not useful
> > either (what would they do, specifically?).
> >
> > There is a whole problem of whether or not devices should be left in
> > runtime suspend during hibernation and I have not had a chance to get
> > to the bottom of that yet.
>
> Not only that.  The distinction between SMART_SUSPEND and
> direct_complete is rather subtle, and it doesn't seem to be carefully
> explained anywhere.  In fact, I'm not sure I understand it myself.  :-)
> For example, the direct_complete mechanism is very careful about not
> leaving a device in runtime suspend if a descendant (or other dependent
> device) will remain active.  Does SMART_SUSPEND behave similarly?  If
> so, it isn't documented.

The difference is that SMART_SUSPEND allows the ->suspend callback to
be invoked which may decide to resume the device (or reconfigure it
for system wakeup if that doesn't require resuming it).  IOW, this
means "I can cope with a runtime-suspended device going forward".
[But if the device is still runtime-suspended during ->suspend_late(),
its configuration is regarded as "final".]

In turn, direct_complete means something like "if this device is
runtime-suspended, leave it as is and don't touch it during the whole
suspend-resume cycle".

> Besides, it seems like a mistake to try controlling (1) and (2)
> together (i.e., with one flag).  Can we do a better job of
> separating the functions of SMART_SUSPEND and LEAVE_SUSPENDED?
>
> > > Other things in there also seem strange.  device_prepare() does a
> > > WARN_ON if either SMART_SUSPEND or LEAVE_SUSPENDED is set and the
> > > device is not runtime-PM-enabled.  That's understandable, but it's also
> > > racy.
> >
> > I guess you mean the check in device_prepare().
> >
> > > A system sleep can begin at any time; how can a driver know when
> > > it is safe to disable a device's runtime PM briefly?
> >
> > Well, fair enough, but then I'm not sure if there is a good place for this
> > check at all, because drivers can briefly disable PM-runtime at any time in
> > theory.
>
> There probably isn't a good place for it.  We could just get rid of the
> WARN.  I've never heard of it triggering.

OK

> > > When device_prepare() calculates the power.direct_complete flag, it
> > > checks to see whether the device is currently in runtime suspend in
> > > some cases but not in others, as in the code added by your commit
> > > c62ec4610c40 ("PM / core:  Fix direct_complete handling for devices
> > > with no callbacks").  Since the runtime-PM state is going to checked in
> > > __device_suspend() anyway, we shouldn't need to check it here at all.
> >
> > I guess the point is that in theory the device can be runtime-suspended
> > between device_prepare() and _device_suspend(), is by checking the status
> > in the former, we lose the opportunity to leave it in suspend if that
> > happens.
> >
> > OK, fair enough.
> >
> > > At a couple of points in the code, THAW and RESTORE events are each
> > > treatedly specially, with no explanation.
> >
> > Right, which is related to the kind of work in progress situation regarding
> > the flags and hibernation mentioned above.  Again, sorry about that.
>
> I haven't thought about those issues as much as you have.  Still, it
> seems obvious that the FREEZE/THAW phases should be very happy to leave
> devices in runtime suspend throughout (without even worrying about
> wakeup settings), and the RESTORE phase should always bring everything
> back out of runtime suspend.

These were exactly my original thoughts, but then when I started to
consider possible interactions the restore kernel (which also carries
out the "freeze" transition before jumping into the image kernel), it
became less clear.

The concerns is basically whether or not attempting to power on
devices that are already powered on can always be guaranteed to work.

> What to do during the POWEROFF phase isn't so clear, because it depends
> on how the platform handles the poweroff transition.

POWEROFF is exactly analogous to SUSPEND AFAICS.

> > > The power.may_skip_resume flag is used in only one place, when
> > > LEAVE_SUSPENDED is set and there are subsystem-level callbacks.  In
> > > particular, it is _not_ used by dev_pm_may_skip_resume().  That seems
> > > highly suspicious at best.
> >
> > That's because it's for the middle-layer (subsystem-level) code to let the
> > core know that skipping the resume would be OK.
> >
> > The core doesn't need that flag when it decides by itself.
>
> This may be another situation where changing a name would make things
> clearer.  One doesn't immediately recognize that
> dev_pm_may_skip_resume() applies only in cases where there is no
> subsystem-level callback.

Fair enough.

> > > I think it would be worthwhile to expend some serious effort
> > > straightening all this stuff out.  Perhaps we could start with a more
> > > explicit description of what is supposed to happen at each step.
> > > (Things to be careful about include phrases like "leave suspended",
> > > which is not the same as "don't call the resume callbacks", even though
> > > the two are easily conflated.)
> > >
> > > What do you think?
> >
> > I am certainly not going to reject any help. :-)
> >
> > Also, I'm not against clarifying anything that is not clear enough.
>
> Okay, let's start with direct_complete.  The direct_complete mechanism
> is applied to the SUSPEND and RESUME phases under the following
> conditions:
>
>         DPM_FLAG_NEVER_SKIP (or better, DPM_FLAG_NO_DIRECT_COMPLETE)
>         is clear;  [Incidentally, since a driver can set this flag
>         whenever its ->prepare routine returns 0, why do we need
>         DPM_FLAG_SMART_PREPARE?]

Because the former allows the driver to avoid providing a ->prepare
callback always returning 1.

>         Either the device has no system-PM callbacks at all or else the
>         ->prepare callback returns a positive value;

Why so?

>         All of the device's descendants and dependents also want to use
>         direct_complete;

Yes.

>         Neither the device nor any of its descendants/dependents is
>         enabled for wakeup;

Yes.

>         The device is runtime suspended just before the ->suspend
>         callback would normally be issued.

Yes.

> When the mechanism applies, none of the suspend or resume callbacks (in
> any of their normal, _early, _late, or _noirq variants) are issued,
> only ->complete.  Consequently the device remains in runtime suspend
> throughout the system sleep.
>
> Currently, direct_complete is never applied during any of the system
> hibernation phases (FREEZE, THAW, POWEROFF, RESTORE).  This may change
> in the future.
>
> Is this description correct and complete?

It is mostly. :-)

> Can you give a similarly
> succinct outline for how SMART_SUSPEND and LEAVE_SUSPENDED should work?
> And also describe how they differ from direct_complete and how they
> interact with it?  (For example, how does setting both flags differ
> from returning a positive value from ->prepare?)

I will, but I need some time to do that.  Stay tuned.

Cheers!

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: lockdep warning in urb.c:363 usb_submit_urb
  2020-03-29  9:16                                     ` Rafael J. Wysocki
@ 2020-03-29 13:56                                       ` Rafael J. Wysocki
  2020-03-29 16:27                                       ` Alan Stern
  1 sibling, 0 replies; 50+ messages in thread
From: Rafael J. Wysocki @ 2020-03-29 13:56 UTC (permalink / raw)
  To: Alan Stern
  Cc: Rafael J. Wysocki, Rafael J. Wysocki, Qais Yousef, USB list,
	Linux-pm mailing list, Kernel development list

On Sun, Mar 29, 2020 at 11:16 AM Rafael J. Wysocki <rafael@kernel.org> wrote:
>

[cut]

> >
> > But if SMART_SUSPEND is set and the device is runtime-suspended, why
> > issue the ->suspend callback?
>
> The driver itself or the middle-layer may want to resume the device.
>
> Arguably, it may do that in ->prepare() too,

Not really.

The problem is that that device_prepare() is executed synchronously
for all devices, so if multiple devices needed to be resumed, the
latency would accumulate if that happened in device_prepare().

Cheers!

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: lockdep warning in urb.c:363 usb_submit_urb
  2020-03-29  9:16                                     ` Rafael J. Wysocki
  2020-03-29 13:56                                       ` Rafael J. Wysocki
@ 2020-03-29 16:27                                       ` Alan Stern
  2020-04-03 15:04                                         ` Rafael J. Wysocki
  2020-04-03 17:08                                         ` Rafael J. Wysocki
  1 sibling, 2 replies; 50+ messages in thread
From: Alan Stern @ 2020-03-29 16:27 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Rafael J. Wysocki, Qais Yousef, USB list, Linux-pm mailing list,
	Kernel development list

On Sun, 29 Mar 2020, Rafael J. Wysocki wrote:

> On Sat, Mar 28, 2020 at 8:58 PM Alan Stern <stern@rowland.harvard.edu> wrote:

> > > > A large part of the problem is related to an inconsistency between the
> > > > documentation and the code.  include/linux/pm.h says that
> > > > DPM_FLAG_SMART_SUSPEND tells bus types and PM domains about what the
> > > > driver wants.  This strongly implies that the PM core will ignore
> > > > SMART_SUSPEND.  But in fact the core does check that flag and takes its
> > > > own actions if the device has no subsystem-level callbacks!
> > >
> > > Right, which is because in those cases there is no "middle layer" between
> > > the driver and the core and if you want the driver to work both with
> > > something like genpd or the ACPI PM domain and without anything like that,
> > > the core needs to take those actions for consistency.
> >
> > Sure, the core is acting as a proxy for the missing subsystem
> > callbacks.  Still, it should be documented properly.
> >
> > Also, couldn't we simplify the behavior?  Right now the core checks
> > that there are no subsystem-level callbacks for any of _early, _late,
> > and _noirq variants before skipping a callback.  Couldn't we forget
> > about all that checking and simply skip the device-level callbacks?
> > (Yes, I realize this could lead to inconsistent behavior if the
> > subsystem has some callbacks defined but not others -- but subsystems
> > should never do that, at least, not if it would lead to trouble.)
> 
> In quite a few cases the middle layer has nothing specific to do in a
> given phase of suspend/resume, but the driver may.
> 
> Subsystems haven't been required to provide callbacks for all phases
> so far, so this change would require some modifications in there.
> 
> I actually prefer the core to do more, even if that means more
> complexity in it, to avoid possible subtle differences in behavior
> between subsystems.

What I meant was that it might be reasonable to get rid of the
no_subsys_cb checks.  For example, change __device_suspend_noirq() as
follows:

-	no_subsys_cb = !dpm_subsys_suspend_late_cb(dev, state, NULL);
-
-	if (dev_pm_smart_suspend_and_suspended(dev) && no_subsys_cb)
+	if (dev_pm_smart_suspend_and_suspended(dev))
		goto Skip;

with similar changes to the _suspend_late, _resume_noirq, and
_resume_early.  In each stage, we would bypass the driver's callback
if SMART_SUSPEND was set and there was no subsystem-level callback for
_that_ stage -- rather than there being no subsystem-level callbacks
for _any_ of the stages.

> > > > Furthermore, the PM core's actions don't seem to make sense.  If the
> > > > flag is set and the device is runtime-suspended when the system sleep
> > > > begins, the core will skip issuing the suspend_late and suspend_noirq
> > > > callbacks to the driver.  But it doesn't skip issuing the suspend
> > > > callback!  I can't figure that out.
> > >
> > > That's because if the core gets to executing ->suspend_late, PM-runtime has
> > > been disabled for the device and if the device is runtime-suspended at that
> > > point, so (at least if SMART_SUSPEND is set for the device) there is no reason
> > > to do anything more to it.
> >
> > But if SMART_SUSPEND is set and the device is runtime-suspended, why
> > issue the ->suspend callback?
> 
> The driver itself or the middle-layer may want to resume the device.
> 
> Arguably, it may do that in ->prepare() too, but see below.
> 
> > Why not just do pm_runtime_disable()
> > then (to prevent the device from resuming) and skip the callback?
> 
> Because another driver may want to runtime-resume that device in order
> to use it for something before ->suspend_late().  Of course, you may
> argue that this means a missing device link or similar, so it is not
> clear-cut.
> 
> The general rule is that "synchronous" PM-runtime can be expected to
> work before ->suspend_late(), so ->suspend() callbacks should be able
> to use it safely in all cases in principle.

(With one exception: Since the PM core does pm_runtime_get_noresume()  
during the prepare stage, going _into_ runtime suspend is impossible
during ->prepare and ->suspend.  Of course, drivers can always call 
their runtime_suspend routines directly, but that wouldn't affect the 
power.runtime_status value.)

> That expectation goes against direct_complete in some cases, so
> drivers need to set NEVER_SKIP (or whatever it will be called in the
> future) to avoid that problem.

Ah, okay.  Very well, let's spell this out explicitly in the
documentation; it's an important difference.

> > > > Furthermore, the decisions about
> > > > whether to skip the resume_noirq, resume_early, and resume callbacks
> > > > are based on different criteria from the decisions on the suspend side.
> > >
> > > Right, because there are drivers that don't want devices to stay in suspend
> > > after system resume even though they have been left in suspend by it.
> >
> > This suggests that sometimes we may want to issue non-matching
> > callbacks.  For example, ->resume_noirq, ->resume_early, and ->resume
> > but not ->suspend, ->suspend_late, or ->suspend_noirq.  Is that what
> > you are saying?
> 
> Yes.
> 
> As per devices.rst:
> 
> "the driver must be prepared to
> cope with the invocation of its system-wide resume callbacks back-to-back with
> its ``->runtime_suspend`` one (without the intervening ``->runtime_resume`` and
> so on) and the final state of the device must reflect the "active" runtime PM
> status in that case."

Here would also be a good place to mention the difference between "keep
the device in runtime suspend" and "not issue the various resume
callbacks".  In theory, a subsystem and a driver could collaborate to
make their resume-side callbacks keep the device runtime-suspended, so
these two concepts are not identical.

Alternatively, we could specify that this sort of thing is never 
allowed: When the ->resume callback returns, the device _must_ be 
powered-up and runtime-active.  If we do this, then the _only_ way to 
avoid powering up the device (and to let it remain in runtime suspend) 
is for the core to skip issuing the resume-side callbacks.  Or at 
least, skip issuing the ->resume callback.

> > > > SMART_SUSPEND seems to have two different meanings.  (1) If the device
> > > > is already in runtime suspend when a system sleep starts, skip the
> > > > suspend_late and suspend_noirq callbacks.  (2) Under certain (similar)
> > > > circumstances, skip the resume callbacks.  The documentation only
> > > > mentions (1) but the code also handles (2).
> > >
> > > That's because (2) is the THAW case and I was distracted before I got
> > > to documenting it properly.  Sorry.
> > >
> > > The problem is that if you leave the device in runtime suspend, calling
> > > ->freeze_late() or ->freeze_noirq() on it is not useful and if you have
> > > skipped those, running the corresponding "thaw" callbacks is not useful
> > > either (what would they do, specifically?).
> > >
> > > There is a whole problem of whether or not devices should be left in
> > > runtime suspend during hibernation and I have not had a chance to get
> > > to the bottom of that yet.
> >
> > Not only that.  The distinction between SMART_SUSPEND and
> > direct_complete is rather subtle, and it doesn't seem to be carefully
> > explained anywhere.  In fact, I'm not sure I understand it myself.  :-)
> > For example, the direct_complete mechanism is very careful about not
> > leaving a device in runtime suspend if a descendant (or other dependent
> > device) will remain active.  Does SMART_SUSPEND behave similarly?  If
> > so, it isn't documented.
> 
> The difference is that SMART_SUSPEND allows the ->suspend callback to
> be invoked which may decide to resume the device (or reconfigure it
> for system wakeup if that doesn't require resuming it).  IOW, this
> means "I can cope with a runtime-suspended device going forward".
> [But if the device is still runtime-suspended during ->suspend_late(),
> its configuration is regarded as "final".]
> 
> In turn, direct_complete means something like "if this device is
> runtime-suspended, leave it as is and don't touch it during the whole
> suspend-resume cycle".

Right; let's spell this out in the documentation too.

> > > > At a couple of points in the code, THAW and RESTORE events are each
> > > > treatedly specially, with no explanation.
> > >
> > > Right, which is related to the kind of work in progress situation regarding
> > > the flags and hibernation mentioned above.  Again, sorry about that.
> >
> > I haven't thought about those issues as much as you have.  Still, it
> > seems obvious that the FREEZE/THAW phases should be very happy to leave
> > devices in runtime suspend throughout (without even worrying about
> > wakeup settings), and the RESTORE phase should always bring everything
> > back out of runtime suspend.
> 
> These were exactly my original thoughts, but then when I started to
> consider possible interactions the restore kernel (which also carries
> out the "freeze" transition before jumping into the image kernel), it
> became less clear.
> 
> The concerns is basically whether or not attempting to power on
> devices that are already powered on can always be guaranteed to work.

This doesn't affect THAW, because during THAW the driver knows what
state the device is in.  It only affects RESTORE.  But during RESTORE
the driver really doesn't know anything about the device state, even
with the current code.  The restore kernel doesn't even know whether
the boot kernel put the device through a FREEZE transition, because
it's possible that the driver was in a module that hadn't been loaded
yet when the resume-from-hibernation started.

Thus, drivers face this problem already.  I don't think we need to
worry about it.

> > What to do during the POWEROFF phase isn't so clear, because it depends
> > on how the platform handles the poweroff transition.
> 
> POWEROFF is exactly analogous to SUSPEND AFAICS.

The difference is that on many platforms (such as desktop PCs) the
POWEROFF callbacks don't have to power-down the device, because the
firmware will power _everything_ off (except the devices needed for
wakeup, of course).  But on other platforms this isn't true, so on them
POWEROFF does need to behave like SUSPEND.

> > Okay, let's start with direct_complete.  The direct_complete mechanism
> > is applied to the SUSPEND and RESUME phases under the following
> > conditions:
> >
> >         DPM_FLAG_NEVER_SKIP (or better, DPM_FLAG_NO_DIRECT_COMPLETE)
> >         is clear;  [Incidentally, since a driver can set this flag
> >         whenever its ->prepare routine returns 0, why do we need
> >         DPM_FLAG_SMART_PREPARE?]
> 
> Because the former allows the driver to avoid providing a ->prepare
> callback always returning 1.

Do you mean NEVER_SKIP allows the driver to avoid providing a ->prepare 
callback which always returns _0_?  If that's not what you meant, I 
don't understand.

> >         Either the device has no system-PM callbacks at all or else the
> >         ->prepare callback returns a positive value;
> 
> Why so?

Isn't that exactly what __device_prepare() does?  After your latest 
patch, we have:

	dev->power.direct_complete = state.event == PM_EVENT_SUSPEND &&
		(ret > 0 || dev->power.no_pm_callbacks) &&
		!dev_pm_test_driver_flags(dev, DPM_FLAG_NEVER_SKIP);

which is exactly what I said, isn't it?

> >         All of the device's descendants and dependents also want to use
> >         direct_complete;
> 
> Yes.
> 
> >         Neither the device nor any of its descendants/dependents is
> >         enabled for wakeup;
> 
> Yes.
> 
> >         The device is runtime suspended just before the ->suspend
> >         callback would normally be issued.
> 
> Yes.
> 
> > When the mechanism applies, none of the suspend or resume callbacks (in
> > any of their normal, _early, _late, or _noirq variants) are issued,
> > only ->complete.  Consequently the device remains in runtime suspend
> > throughout the system sleep.
> >
> > Currently, direct_complete is never applied during any of the system
> > hibernation phases (FREEZE, THAW, POWEROFF, RESTORE).  This may change
> > in the future.
> >
> > Is this description correct and complete?
> 
> It is mostly. :-)

I forgot to mention that if power.syscore is set then none of these
mechanisms apply because none of the callbacks are issued.  Does
anything else need to be changed?

> > Can you give a similarly
> > succinct outline for how SMART_SUSPEND and LEAVE_SUSPENDED should work?
> > And also describe how they differ from direct_complete and how they
> > interact with it?  (For example, how does setting both flags differ
> > from returning a positive value from ->prepare?)
> 
> I will, but I need some time to do that.  Stay tuned.

You bet!

Alan Stern


^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: lockdep warning in urb.c:363 usb_submit_urb
  2020-03-29 16:27                                       ` Alan Stern
@ 2020-04-03 15:04                                         ` Rafael J. Wysocki
  2020-04-03 16:13                                           ` Rafael J. Wysocki
  2020-04-03 16:41                                           ` Alan Stern
  2020-04-03 17:08                                         ` Rafael J. Wysocki
  1 sibling, 2 replies; 50+ messages in thread
From: Rafael J. Wysocki @ 2020-04-03 15:04 UTC (permalink / raw)
  To: Alan Stern
  Cc: Rafael J. Wysocki, Qais Yousef, USB list, Linux-pm mailing list,
	Kernel development list

On Sunday, March 29, 2020 6:27:38 PM CEST Alan Stern wrote:
> On Sun, 29 Mar 2020, Rafael J. Wysocki wrote:
> 
> > On Sat, Mar 28, 2020 at 8:58 PM Alan Stern <stern@rowland.harvard.edu> wrote:

[cut]

> > > Can you give a similarly
> > > succinct outline for how SMART_SUSPEND and LEAVE_SUSPENDED should work?
> > > And also describe how they differ from direct_complete and how they
> > > interact with it?  (For example, how does setting both flags differ
> > > from returning a positive value from ->prepare?)
> > 
> > I will, but I need some time to do that.  Stay tuned.
> 
> You bet!

Sorry for the delay, too much distraction nowadays.

I'll address the other points in your message separately.

The rules for SMART_SUSPEND are as follows:

(a) If SMART_SUSPEND is set and the device is runtime-suspended during system
    suspend, it is not expected to be resumed by the core or the middle layer
    (subsystem) code unless the latter has a specific reason to do that (e.g.
    it knows that the device needs to be reconfigured which cannot be done
    without resuming it).

    The device can still be resumed when it is needed to suspend a dependent
    device, but that cannot happen before the "late suspend" phase.

(b) Drivers that set SMART_SUSPEND are allowed to reuse their PM-runtime
    callbacks for system-wide suspend and resume.

    That is, they can point either the ->suspend_late or the ->suspend_noirq
    callback pointer to the same function as ->runtime_suspend and they can
    point either the ->resume_noirq or ->the resume_early callback to the'
    same function as ->runtime_resume.

(c) Drivers that set SMART_SUSPEND are alwo allowed to provide special
    simplified callbacks for the "freeze" and "thaw" transitions during
    hibernation (and restore) and (if they do so) special callbacks for the
    "restore" phase.

[OK, I realize that (b) and (c) are not documented, see the notes below.]

Because of (a), if the device with SMART_SUSPEND set is still runtime-suspended
during the "late" phase of suspend, the core will not invoke the driver's
"late" and "noirq" suspend callbacks directly (*).  Middle layer (subsystem)
code is expected to behave accordingly.

Because of (b), if the "late" and "noirq" driver callbacks were skipped during
the "freeze" transition, the core will also avoid invoking the "noirq" and
"early" callbacks provided by the driver during the "thaw" transition and
the callbacks during the "restore" transition will be executed unconditionally
(**).  Middle layer code is expected to behave accordingly.

Notes:

1. I have considered splitting SMART_SUSPEND into two or even three flags
   so that (a), (b) and (c) are each associated with a separate flag, but
   then I would expect the majority of users to use all of them anyway.

2. LEAVE_SUSPENDED (which may be better renamed to SKIP_RESUME) is kind of
   expected to be used along with SMART_SUSPEND unless there is a good enough
   reason to avoid using it.  I admit that this isn't really straightforward,
   maybe the default behavior should be to skip the resume and there should be
   FORCE_RESUME instead of LEAVE_SUSPENDED.

3. (*) Under the assumption that either ->suspend_late or ->suspend_noirq
   points to the same routine as ->runtime_suspend (and the other is NULL),
   invokig that callback for a runtime-suspended device is technically invalid.
   In turn, under the assumption that either ->resume_early or ->resume_noirq
   points to the same routine as ->runtime_resume (and the other is NULL), it is
   valid to invoke that callback if the late/noirq suspend was skipped.

4. (**) If the "freeze" and "thaw" callbacks are simplified, they cannot be
   run back-to-back with ->runtime_resume and ->runtime_suspend, respectively.
   Thus if "freeze" is skippend, "thaw" must be skipped too.  However,
   "restore" needs to be prepared to be invoked after "freeze" or
   ->runtime_suspend (and the state of the device may not match the
   callback that ran previously), so it must be special.

5. I agree that skipping the driver level of callbacks depending on what is
   provided by the middle layer is inconsistent, but I wanted to take the
   users of pm_runtime_force_suspend/resume() into account by letting those
   things run.

   It would be more consistent to expect middle layer code (bus types, PM
   domains) to provide either all of the noirq/early/late callbacks, or none
   of them and make SMART_SUSPEND and pm_runtime_force_suspend/resume()
   mutually exclusive.

Cheers!




^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: lockdep warning in urb.c:363 usb_submit_urb
  2020-04-03 15:04                                         ` Rafael J. Wysocki
@ 2020-04-03 16:13                                           ` Rafael J. Wysocki
  2020-04-03 16:41                                           ` Alan Stern
  1 sibling, 0 replies; 50+ messages in thread
From: Rafael J. Wysocki @ 2020-04-03 16:13 UTC (permalink / raw)
  To: Alan Stern
  Cc: Rafael J. Wysocki, Qais Yousef, USB list, Linux-pm mailing list,
	Kernel development list

On Friday, April 3, 2020 5:04:16 PM CEST Rafael J. Wysocki wrote:
> On Sunday, March 29, 2020 6:27:38 PM CEST Alan Stern wrote:
> > On Sun, 29 Mar 2020, Rafael J. Wysocki wrote:
> > 
> > > On Sat, Mar 28, 2020 at 8:58 PM Alan Stern <stern@rowland.harvard.edu> wrote:
> 
> [cut]
> 
> > > > Can you give a similarly
> > > > succinct outline for how SMART_SUSPEND and LEAVE_SUSPENDED should work?
> > > > And also describe how they differ from direct_complete and how they
> > > > interact with it?  (For example, how does setting both flags differ
> > > > from returning a positive value from ->prepare?)
> > > 
> > > I will, but I need some time to do that.  Stay tuned.
> > 
> > You bet!
> 
> Sorry for the delay, too much distraction nowadays.
> 
> I'll address the other points in your message separately.
> 
> The rules for SMART_SUSPEND are as follows:
> 
> (a) If SMART_SUSPEND is set and the device is runtime-suspended during system
>     suspend, it is not expected to be resumed by the core or the middle layer
>     (subsystem) code unless the latter has a specific reason to do that (e.g.
>     it knows that the device needs to be reconfigured which cannot be done
>     without resuming it).
> 
>     The device can still be resumed when it is needed to suspend a dependent
>     device, but that cannot happen before the "late suspend" phase.

s/cannot/must/

> (b) Drivers that set SMART_SUSPEND are allowed to reuse their PM-runtime
>     callbacks for system-wide suspend and resume.
> 
>     That is, they can point either the ->suspend_late or the ->suspend_noirq
>     callback pointer to the same function as ->runtime_suspend and they can
>     point either the ->resume_noirq or ->the resume_early callback to the'
>     same function as ->runtime_resume.
> 
> (c) Drivers that set SMART_SUSPEND are alwo allowed to provide special

s/alwo/also/

>     simplified callbacks for the "freeze" and "thaw" transitions during
>     hibernation (and restore) and (if they do so) special callbacks for the
>     "restore" phase.
> 
> [OK, I realize that (b) and (c) are not documented, see the notes below.]
> 
> Because of (a), if the device with SMART_SUSPEND set is still runtime-suspended
> during the "late" phase of suspend, the core will not invoke the driver's
> "late" and "noirq" suspend callbacks directly (*).  Middle layer (subsystem)
> code is expected to behave accordingly.
> 
> Because of (b), if the "late" and "noirq" driver callbacks were skipped during
> the "freeze" transition, the core will also avoid invoking the "noirq" and
> "early" callbacks provided by the driver during the "thaw" transition and
> the callbacks during the "restore" transition will be executed unconditionally
> (**).  Middle layer code is expected to behave accordingly.
> 
> Notes:
> 
> 1. I have considered splitting SMART_SUSPEND into two or even three flags
>    so that (a), (b) and (c) are each associated with a separate flag, but
>    then I would expect the majority of users to use all of them anyway.
> 
> 2. LEAVE_SUSPENDED (which may be better renamed to SKIP_RESUME) is kind of
>    expected to be used along with SMART_SUSPEND unless there is a good enough
>    reason to avoid using it.  I admit that this isn't really straightforward,
>    maybe the default behavior should be to skip the resume and there should be
>    FORCE_RESUME instead of LEAVE_SUSPENDED.
> 
> 3. (*) Under the assumption that either ->suspend_late or ->suspend_noirq
>    points to the same routine as ->runtime_suspend (and the other is NULL),
>    invokig that callback for a runtime-suspended device is technically invalid.
>    In turn, under the assumption that either ->resume_early or ->resume_noirq
>    points to the same routine as ->runtime_resume (and the other is NULL), it is
>    valid to invoke that callback if the late/noirq suspend was skipped.
> 
> 4. (**) If the "freeze" and "thaw" callbacks are simplified, they cannot be
>    run back-to-back with ->runtime_resume and ->runtime_suspend, respectively.

That is, ->freeze -> ->runtime_resume would be invalid and
->runtime_suspend -> ->thaw would be invalid.

>    Thus if "freeze" is skippend, "thaw" must be skipped too.  However,
>    "restore" needs to be prepared to be invoked after "freeze" or
>    ->runtime_suspend (and the state of the device may not match the
>    callback that ran previously), so it must be special.
> 
> 5. I agree that skipping the driver level of callbacks depending on what is
>    provided by the middle layer is inconsistent, but I wanted to take the
>    users of pm_runtime_force_suspend/resume() into account by letting those
>    things run.
> 
>    It would be more consistent to expect middle layer code (bus types, PM
>    domains) to provide either all of the noirq/early/late callbacks, or none
>    of them and make SMART_SUSPEND and pm_runtime_force_suspend/resume()
>    mutually exclusive.
> 
> Cheers!




^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: lockdep warning in urb.c:363 usb_submit_urb
  2020-04-03 15:04                                         ` Rafael J. Wysocki
  2020-04-03 16:13                                           ` Rafael J. Wysocki
@ 2020-04-03 16:41                                           ` Alan Stern
  2020-04-03 18:32                                             ` Rafael J. Wysocki
  1 sibling, 1 reply; 50+ messages in thread
From: Alan Stern @ 2020-04-03 16:41 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Rafael J. Wysocki, Qais Yousef, USB list, Linux-pm mailing list,
	Kernel development list

On Fri, 3 Apr 2020, Rafael J. Wysocki wrote:

> I'll address the other points in your message separately.
> 
> The rules for SMART_SUSPEND are as follows:

These rules are a sort of high-level overview.  They don't (for the
most part) say exactly what will happen, in terms of which callbacks
will be issued and under what circumstances.  I have tried to provide 
such a description inline below.

> (a) If SMART_SUSPEND is set and the device is runtime-suspended during system
>     suspend, it is not expected to be resumed by the core or the middle layer
>     (subsystem) code unless the latter has a specific reason to do that (e.g.
>     it knows that the device needs to be reconfigured which cannot be done
>     without resuming it).
> 
>     The device can still be resumed when it is needed to suspend a dependent
>     device, but that cannot happen before the "late suspend" phase.

Don't you mean it cannot happen during or after the "late suspend"  
phase?  (More precisely, it cannot happen after the time when the core
would issue the device's ->suspend_late callback, but it can happen
between that time and the time when the "late suspend" phase began --
for example, from within the dependent device's ->suspend_late
callback.)  After all, __device_suspend_late() calls
__pm_runtime_disable(), following which the device _cannot_ be runtime
resumed.

Putting this in operational terms, it seems to say that if
SMART_SUSPEND is set and the device is runtime-suspended at the times
when the core would normally issue the driver's ->suspend_late or
->suspend_noirq callback, then the core will skip the callback (with a
similar requirement for subsystems).  Correct?

> (b) Drivers that set SMART_SUSPEND are allowed to reuse their PM-runtime
>     callbacks for system-wide suspend and resume.
> 
>     That is, they can point either the ->suspend_late or the ->suspend_noirq
>     callback pointer to the same function as ->runtime_suspend and they can
>     point either the ->resume_noirq or ->the resume_early callback to the'
>     same function as ->runtime_resume.

Well, in theory any driver or subsystem can do this whenever it wants
to, regardless of any flag settings.  It's then up to the driver or
subsystem to make sure the callback "does the right thing".

What I'm concerned about now is: What guarantees can the core give to 
the driver and subsystem, so that they will know what is necessary in 
order to "do the right thing"?

> (c) Drivers that set SMART_SUSPEND are alwo allowed to provide special
>     simplified callbacks for the "freeze" and "thaw" transitions during
>     hibernation (and restore) and (if they do so) special callbacks for the
>     "restore" phase.

What do you mean by "simplified"?

As I see it, the suspend-side callbacks are generally responsible for 
four things:

	1. Quiesce the device (finish ongoing I/O and do not allow any
	   more to start).

	2. Save the current device state.

	3. Install the appropriate wakeup settings.

	4. Put the device into low-power mode.

(Not explicitly listed: Perform a runtime-resume if needed in order to
carry out these four items.)

During a SUSPEND transition, we usually expect all four to happen.  
During a FREEZE transition, we only require 1.  During a POWEROFF
transition we require 1 and 3, and possibly 4 (depending on how the
platform handles poweroff).

Similar requirements apply to the resume-side callbacks.  (But note 
that RESTORE is not the inverse of POWEROFF; it is more like an inverse 
of FREEZE with the added complication that the device's initial state 
is unknown.)

What changes to this analysis would SMART_SUSPEND allow?  None if the 
device is runtime-active.  But if the device is runtime-suspended and 
the wakeup settings don't need to be changed, then presumably none of 
the four items are necessary.

Is this what you mean?

> [OK, I realize that (b) and (c) are not documented, see the notes below.]
> 
> Because of (a), if the device with SMART_SUSPEND set is still runtime-suspended
> during the "late" phase of suspend, the core will not invoke the driver's
> "late" and "noirq" suspend callbacks directly (*).  Middle layer (subsystem)
> code is expected to behave accordingly.

Okay, this agrees with what I wrote above.

> Because of (b), if the "late" and "noirq" driver callbacks were skipped during
> the "freeze" transition, the core will also avoid invoking the "noirq" and
> "early" callbacks provided by the driver during the "thaw" transition and
> the callbacks during the "restore" transition will be executed unconditionally
> (**).  Middle layer code is expected to behave accordingly.

All right.  To summarize: If the driver's ->freeze_late callback is
skipped then the driver's ->thaw-early will be skipped, and similarly
for ->freeze_noirq and ->thaw_noirq.  But RESTORE callbacks are never
skipped.  Correct?

However, the most difficult transitions are SUSPEND and RESUME.  Is it
accurate to say that if the driver's ->suspend_late callback is skipped
then the driver's ->resume_early will be skipped, and similarly for
->suspend_noirq and ->resume_noirq?

> Notes:
> 
> 1. I have considered splitting SMART_SUSPEND into two or even three flags
>    so that (a), (b) and (c) are each associated with a separate flag, but
>    then I would expect the majority of users to use all of them anyway.
> 
> 2. LEAVE_SUSPENDED (which may be better renamed to SKIP_RESUME) is kind of
>    expected to be used along with SMART_SUSPEND unless there is a good enough
>    reason to avoid using it.  I admit that this isn't really straightforward,
>    maybe the default behavior should be to skip the resume and there should be
>    FORCE_RESUME instead of LEAVE_SUSPENDED.

One question not addressed above (in fact, the original reason for 
getting you involved in this discussion): What about the device's 
power.runtime_status?  Shall we say that that core will call 
pm_runtime_set_active() at some point before issuing the ->complete 
callback unless some combination of flags is set?  And what should that 
combination be?

After all, we expect that most drivers will want their devices to be in 
the runtime-active state at the end of a system sleep or hibernation.  
It makes sense for the core to do the necessary housekeeping.

> 3. (*) Under the assumption that either ->suspend_late or ->suspend_noirq
>    points to the same routine as ->runtime_suspend (and the other is NULL),
>    invokig that callback for a runtime-suspended device is technically invalid.

Does this invalidate anything I wrote above?

>    In turn, under the assumption that either ->resume_early or ->resume_noirq
>    points to the same routine as ->runtime_resume (and the other is NULL), it is
>    valid to invoke that callback if the late/noirq suspend was skipped.

In other words, it's okay for the core either to issue or skip those 
callbacks.  Presumably the decision will be made based on some flag 
setting?

> 4. (**) If the "freeze" and "thaw" callbacks are simplified, they cannot be
>    run back-to-back with ->runtime_resume and ->runtime_suspend, respectively.
>    Thus if "freeze" is skippend, "thaw" must be skipped too.  However,
>    "restore" needs to be prepared to be invoked after "freeze" or
>    ->runtime_suspend (and the state of the device may not match the
>    callback that ran previously), so it must be special.
> 
> 5. I agree that skipping the driver level of callbacks depending on what is
>    provided by the middle layer is inconsistent, but I wanted to take the
>    users of pm_runtime_force_suspend/resume() into account by letting those
>    things run.
> 
>    It would be more consistent to expect middle layer code (bus types, PM
>    domains) to provide either all of the noirq/early/late callbacks, or none
>    of them and make SMART_SUSPEND and pm_runtime_force_suspend/resume()
>    mutually exclusive.

I don't have a clear idea of how pm_runtime_force_suspend/resume() gets 
used.  Are we better off ignoring it for the time being?

Alan Stern


^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: lockdep warning in urb.c:363 usb_submit_urb
  2020-03-29 16:27                                       ` Alan Stern
  2020-04-03 15:04                                         ` Rafael J. Wysocki
@ 2020-04-03 17:08                                         ` Rafael J. Wysocki
  1 sibling, 0 replies; 50+ messages in thread
From: Rafael J. Wysocki @ 2020-04-03 17:08 UTC (permalink / raw)
  To: Alan Stern
  Cc: Rafael J. Wysocki, Qais Yousef, USB list, Linux-pm mailing list,
	Kernel development list

On Sunday, March 29, 2020 6:27:38 PM CEST Alan Stern wrote:
> On Sun, 29 Mar 2020, Rafael J. Wysocki wrote:
> 
> > On Sat, Mar 28, 2020 at 8:58 PM Alan Stern <stern@rowland.harvard.edu> wrote:
> 
> > > > > A large part of the problem is related to an inconsistency between the
> > > > > documentation and the code.  include/linux/pm.h says that
> > > > > DPM_FLAG_SMART_SUSPEND tells bus types and PM domains about what the
> > > > > driver wants.  This strongly implies that the PM core will ignore
> > > > > SMART_SUSPEND.  But in fact the core does check that flag and takes its
> > > > > own actions if the device has no subsystem-level callbacks!
> > > >
> > > > Right, which is because in those cases there is no "middle layer" between
> > > > the driver and the core and if you want the driver to work both with
> > > > something like genpd or the ACPI PM domain and without anything like that,
> > > > the core needs to take those actions for consistency.
> > >
> > > Sure, the core is acting as a proxy for the missing subsystem
> > > callbacks.  Still, it should be documented properly.
> > >
> > > Also, couldn't we simplify the behavior?  Right now the core checks
> > > that there are no subsystem-level callbacks for any of _early, _late,
> > > and _noirq variants before skipping a callback.  Couldn't we forget
> > > about all that checking and simply skip the device-level callbacks?
> > > (Yes, I realize this could lead to inconsistent behavior if the
> > > subsystem has some callbacks defined but not others -- but subsystems
> > > should never do that, at least, not if it would lead to trouble.)
> > 
> > In quite a few cases the middle layer has nothing specific to do in a
> > given phase of suspend/resume, but the driver may.
> > 
> > Subsystems haven't been required to provide callbacks for all phases
> > so far, so this change would require some modifications in there.
> > 
> > I actually prefer the core to do more, even if that means more
> > complexity in it, to avoid possible subtle differences in behavior
> > between subsystems.
> 
> What I meant was that it might be reasonable to get rid of the
> no_subsys_cb checks.  For example, change __device_suspend_noirq() as
> follows:
> 
> -	no_subsys_cb = !dpm_subsys_suspend_late_cb(dev, state, NULL);
> -
> -	if (dev_pm_smart_suspend_and_suspended(dev) && no_subsys_cb)
> +	if (dev_pm_smart_suspend_and_suspended(dev))
> 		goto Skip;
> 
> with similar changes to the _suspend_late, _resume_noirq, and
> _resume_early.  In each stage, we would bypass the driver's callback
> if SMART_SUSPEND was set and there was no subsystem-level callback for
> _that_ stage -- rather than there being no subsystem-level callbacks
> for _any_ of the stages.

I understand that.

As mentioned in the other message, I attempted to allow
pm_runtime_force_suspend/resume() to be used along with setting SMART_SUSPEND,
but that looks like a mistake now.

I agree that skipping the driver-level callbacks regardless of what is provided
by the subsystem would be more consistent.

> > > > > Furthermore, the PM core's actions don't seem to make sense.  If the
> > > > > flag is set and the device is runtime-suspended when the system sleep
> > > > > begins, the core will skip issuing the suspend_late and suspend_noirq
> > > > > callbacks to the driver.  But it doesn't skip issuing the suspend
> > > > > callback!  I can't figure that out.
> > > >
> > > > That's because if the core gets to executing ->suspend_late, PM-runtime has
> > > > been disabled for the device and if the device is runtime-suspended at that
> > > > point, so (at least if SMART_SUSPEND is set for the device) there is no reason
> > > > to do anything more to it.
> > >
> > > But if SMART_SUSPEND is set and the device is runtime-suspended, why
> > > issue the ->suspend callback?
> > 
> > The driver itself or the middle-layer may want to resume the device.
> > 
> > Arguably, it may do that in ->prepare() too, but see below.
> > 
> > > Why not just do pm_runtime_disable()
> > > then (to prevent the device from resuming) and skip the callback?
> > 
> > Because another driver may want to runtime-resume that device in order
> > to use it for something before ->suspend_late().  Of course, you may
> > argue that this means a missing device link or similar, so it is not
> > clear-cut.
> > 
> > The general rule is that "synchronous" PM-runtime can be expected to
> > work before ->suspend_late(), so ->suspend() callbacks should be able
> > to use it safely in all cases in principle.
> 
> (With one exception: Since the PM core does pm_runtime_get_noresume()  
> during the prepare stage, going _into_ runtime suspend is impossible
> during ->prepare and ->suspend.  Of course, drivers can always call 
> their runtime_suspend routines directly, but that wouldn't affect the 
> power.runtime_status value.)
> 
> > That expectation goes against direct_complete in some cases, so
> > drivers need to set NEVER_SKIP (or whatever it will be called in the
> > future) to avoid that problem.
> 
> Ah, okay.  Very well, let's spell this out explicitly in the
> documentation; it's an important difference.
> 
> > > > > Furthermore, the decisions about
> > > > > whether to skip the resume_noirq, resume_early, and resume callbacks
> > > > > are based on different criteria from the decisions on the suspend side.
> > > >
> > > > Right, because there are drivers that don't want devices to stay in suspend
> > > > after system resume even though they have been left in suspend by it.
> > >
> > > This suggests that sometimes we may want to issue non-matching
> > > callbacks.  For example, ->resume_noirq, ->resume_early, and ->resume
> > > but not ->suspend, ->suspend_late, or ->suspend_noirq.  Is that what
> > > you are saying?
> > 
> > Yes.
> > 
> > As per devices.rst:
> > 
> > "the driver must be prepared to
> > cope with the invocation of its system-wide resume callbacks back-to-back with
> > its ``->runtime_suspend`` one (without the intervening ``->runtime_resume`` and
> > so on) and the final state of the device must reflect the "active" runtime PM
> > status in that case."
> 
> Here would also be a good place to mention the difference between "keep
> the device in runtime suspend" and "not issue the various resume
> callbacks".  In theory, a subsystem and a driver could collaborate to
> make their resume-side callbacks keep the device runtime-suspended, so
> these two concepts are not identical.
> 
> Alternatively, we could specify that this sort of thing is never 
> allowed: When the ->resume callback returns, the device _must_ be 
> powered-up and runtime-active.  If we do this, then the _only_ way to 
> avoid powering up the device (and to let it remain in runtime suspend) 
> is for the core to skip issuing the resume-side callbacks.  Or at 
> least, skip issuing the ->resume callback.

Basically, all devices with SMART_SUSPEND set whose late/noirq suspend callbacks
were skipped can be left in suspend during system-wide resume by skipping their
callbacks, so that they can be resumed by PM-runtime (that becomes kind of like
direct-complete at that point), but some drivers may not want that for earlier
device response after system-wide resume (if it is resumed by the system-wide
code, it will be immediately ready when user space is unfrozen).

It is expected that LEAVE_SUSPENDED will be used along with SMART_SUSPEND unless
the above is the case.

> > > > > SMART_SUSPEND seems to have two different meanings.  (1) If the device
> > > > > is already in runtime suspend when a system sleep starts, skip the
> > > > > suspend_late and suspend_noirq callbacks.  (2) Under certain (similar)
> > > > > circumstances, skip the resume callbacks.  The documentation only
> > > > > mentions (1) but the code also handles (2).
> > > >
> > > > That's because (2) is the THAW case and I was distracted before I got
> > > > to documenting it properly.  Sorry.
> > > >
> > > > The problem is that if you leave the device in runtime suspend, calling
> > > > ->freeze_late() or ->freeze_noirq() on it is not useful and if you have
> > > > skipped those, running the corresponding "thaw" callbacks is not useful
> > > > either (what would they do, specifically?).
> > > >
> > > > There is a whole problem of whether or not devices should be left in
> > > > runtime suspend during hibernation and I have not had a chance to get
> > > > to the bottom of that yet.
> > >
> > > Not only that.  The distinction between SMART_SUSPEND and
> > > direct_complete is rather subtle, and it doesn't seem to be carefully
> > > explained anywhere.  In fact, I'm not sure I understand it myself.  :-)
> > > For example, the direct_complete mechanism is very careful about not
> > > leaving a device in runtime suspend if a descendant (or other dependent
> > > device) will remain active.  Does SMART_SUSPEND behave similarly?  If
> > > so, it isn't documented.
> > 
> > The difference is that SMART_SUSPEND allows the ->suspend callback to
> > be invoked which may decide to resume the device (or reconfigure it
> > for system wakeup if that doesn't require resuming it).  IOW, this
> > means "I can cope with a runtime-suspended device going forward".
> > [But if the device is still runtime-suspended during ->suspend_late(),
> > its configuration is regarded as "final".]
> > 
> > In turn, direct_complete means something like "if this device is
> > runtime-suspended, leave it as is and don't touch it during the whole
> > suspend-resume cycle".
> 
> Right; let's spell this out in the documentation too.
> 
> > > > > At a couple of points in the code, THAW and RESTORE events are each
> > > > > treatedly specially, with no explanation.
> > > >
> > > > Right, which is related to the kind of work in progress situation regarding
> > > > the flags and hibernation mentioned above.  Again, sorry about that.
> > >
> > > I haven't thought about those issues as much as you have.  Still, it
> > > seems obvious that the FREEZE/THAW phases should be very happy to leave
> > > devices in runtime suspend throughout (without even worrying about
> > > wakeup settings), and the RESTORE phase should always bring everything
> > > back out of runtime suspend.
> > 
> > These were exactly my original thoughts, but then when I started to
> > consider possible interactions the restore kernel (which also carries
> > out the "freeze" transition before jumping into the image kernel), it
> > became less clear.
> > 
> > The concerns is basically whether or not attempting to power on
> > devices that are already powered on can always be guaranteed to work.
> 
> This doesn't affect THAW, because during THAW the driver knows what
> state the device is in.  It only affects RESTORE.  But during RESTORE
> the driver really doesn't know anything about the device state, even
> with the current code.  The restore kernel doesn't even know whether
> the boot kernel put the device through a FREEZE transition, because
> it's possible that the driver was in a module that hadn't been loaded
> yet when the resume-from-hibernation started.
> 
> Thus, drivers face this problem already.  I don't think we need to
> worry about it.

OK

> > > What to do during the POWEROFF phase isn't so clear, because it depends
> > > on how the platform handles the poweroff transition.
> > 
> > POWEROFF is exactly analogous to SUSPEND AFAICS.
> 
> The difference is that on many platforms (such as desktop PCs) the
> POWEROFF callbacks don't have to power-down the device, because the
> firmware will power _everything_ off (except the devices needed for
> wakeup, of course).  But on other platforms this isn't true, so on them
> POWEROFF does need to behave like SUSPEND.

And there are platforms where the firmware turns off everything (except for
wakeup devices) at the end of system-wide suspend too.

There really isn't that much of a difference in general.

> > > Okay, let's start with direct_complete.  The direct_complete mechanism
> > > is applied to the SUSPEND and RESUME phases under the following
> > > conditions:
> > >
> > >         DPM_FLAG_NEVER_SKIP (or better, DPM_FLAG_NO_DIRECT_COMPLETE)
> > >         is clear;  [Incidentally, since a driver can set this flag
> > >         whenever its ->prepare routine returns 0, why do we need
> > >         DPM_FLAG_SMART_PREPARE?]
> > 
> > Because the former allows the driver to avoid providing a ->prepare
> > callback always returning 1.
> 
> Do you mean NEVER_SKIP allows the driver to avoid providing a ->prepare 
> callback which always returns _0_?  If that's not what you meant, I 
> don't understand.

Yes, I thought 0 and wrote 1, sorry.

> > >         Either the device has no system-PM callbacks at all or else the
> > >         ->prepare callback returns a positive value;
> > 
> > Why so?
> 
> Isn't that exactly what __device_prepare() does?  After your latest 
> patch, we have:
> 
> 	dev->power.direct_complete = state.event == PM_EVENT_SUSPEND &&
> 		(ret > 0 || dev->power.no_pm_callbacks) &&
> 		!dev_pm_test_driver_flags(dev, DPM_FLAG_NEVER_SKIP);
> 
> which is exactly what I said, isn't it?

I misread what you wrote, so agreed.

> > >         All of the device's descendants and dependents also want to use
> > >         direct_complete;
> > 
> > Yes.
> > 
> > >         Neither the device nor any of its descendants/dependents is
> > >         enabled for wakeup;
> > 
> > Yes.
> > 
> > >         The device is runtime suspended just before the ->suspend
> > >         callback would normally be issued.
> > 
> > Yes.
> > 
> > > When the mechanism applies, none of the suspend or resume callbacks (in
> > > any of their normal, _early, _late, or _noirq variants) are issued,
> > > only ->complete.  Consequently the device remains in runtime suspend
> > > throughout the system sleep.
> > >
> > > Currently, direct_complete is never applied during any of the system
> > > hibernation phases (FREEZE, THAW, POWEROFF, RESTORE).  This may change
> > > in the future.
> > >
> > > Is this description correct and complete?
> > 
> > It is mostly. :-)
> 
> I forgot to mention that if power.syscore is set then none of these
> mechanisms apply because none of the callbacks are issued.  Does
> anything else need to be changed?

No, I don't think so.




^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: lockdep warning in urb.c:363 usb_submit_urb
  2020-04-03 16:41                                           ` Alan Stern
@ 2020-04-03 18:32                                             ` Rafael J. Wysocki
  2020-04-03 20:15                                               ` Alan Stern
  0 siblings, 1 reply; 50+ messages in thread
From: Rafael J. Wysocki @ 2020-04-03 18:32 UTC (permalink / raw)
  To: Alan Stern
  Cc: Rafael J. Wysocki, Qais Yousef, USB list, Linux-pm mailing list,
	Kernel development list

On Friday, April 3, 2020 6:41:05 PM CEST Alan Stern wrote:
> On Fri, 3 Apr 2020, Rafael J. Wysocki wrote:
> 
> > I'll address the other points in your message separately.
> > 
> > The rules for SMART_SUSPEND are as follows:
> 
> These rules are a sort of high-level overview.  They don't (for the
> most part) say exactly what will happen, in terms of which callbacks
> will be issued and under what circumstances.  I have tried to provide 
> such a description inline below.
> 
> > (a) If SMART_SUSPEND is set and the device is runtime-suspended during system
> >     suspend, it is not expected to be resumed by the core or the middle layer
> >     (subsystem) code unless the latter has a specific reason to do that (e.g.
> >     it knows that the device needs to be reconfigured which cannot be done
> >     without resuming it).
> > 
> >     The device can still be resumed when it is needed to suspend a dependent
> >     device, but that cannot happen before the "late suspend" phase.
> 
> Don't you mean it cannot happen during or after the "late suspend"  
> phase?

Yes, I do.

> (More precisely, it cannot happen after the time when the core
> would issue the device's ->suspend_late callback, but it can happen
> between that time and the time when the "late suspend" phase began --
> for example, from within the dependent device's ->suspend_late
> callback.)  After all, __device_suspend_late() calls
> __pm_runtime_disable(), following which the device _cannot_ be runtime
> resumed.

Right.

> Putting this in operational terms, it seems to say that if
> SMART_SUSPEND is set and the device is runtime-suspended at the times
> when the core would normally issue the driver's ->suspend_late or
> ->suspend_noirq callback, then the core will skip the callback (with a
> similar requirement for subsystems).  Correct?

Yes.

> > (b) Drivers that set SMART_SUSPEND are allowed to reuse their PM-runtime
> >     callbacks for system-wide suspend and resume.
> > 
> >     That is, they can point either the ->suspend_late or the ->suspend_noirq
> >     callback pointer to the same function as ->runtime_suspend and they can
> >     point either the ->resume_noirq or ->the resume_early callback to the'
> >     same function as ->runtime_resume.
> 
> Well, in theory any driver or subsystem can do this whenever it wants
> to, regardless of any flag settings.

Not exactly.

Say the driver wants to point both ->runtime_suspend and ->suspend_late to
the same function.

If the bus type doesn't provide system-wide PM callbacks at all (which is
the case for some bus types), that only works if the device is never
runtime-suspended when ->suspend_late is about to run, because otherwise
the function in question needs to check the context in which it is running
(PM-runtime vs system-wide and runtime-suspended vs runtime-active in the
latter case) which at least is awkward and hard to get right.

> It's then up to the driver or
> subsystem to make sure the callback "does the right thing".

In theory.

> What I'm concerned about now is: What guarantees can the core give to 
> the driver and subsystem, so that they will know what is necessary in 
> order to "do the right thing"?

I'm not sure what you mean.

If the subsystem provides callbacks, the core will run them regardless.

If it does not provide callbacks, the core will skip ->suspend_late and
->suspend_noirq for the driver and the device will remain suspended.

If SMART_SUSPEND is not set, the core will execute all of the callbacks
that are present.

> > (c) Drivers that set SMART_SUSPEND are alwo allowed to provide special
> >     simplified callbacks for the "freeze" and "thaw" transitions during
> >     hibernation (and restore) and (if they do so) special callbacks for the
> >     "restore" phase.
> 
> What do you mean by "simplified"?

Avoiding actual PM.

> As I see it, the suspend-side callbacks are generally responsible for 
> four things:
> 
> 	1. Quiesce the device (finish ongoing I/O and do not allow any
> 	   more to start).
> 
> 	2. Save the current device state.
> 
> 	3. Install the appropriate wakeup settings.
> 
> 	4. Put the device into low-power mode.
> 
> (Not explicitly listed: Perform a runtime-resume if needed in order to
> carry out these four items.)
> 
> During a SUSPEND transition, we usually expect all four to happen.  
> During a FREEZE transition, we only require 1.

That's what I mean by "simplified".

> During a POWEROFF
> transition we require 1 and 3, and possibly 4 (depending on how the
> platform handles poweroff).

But doing 2 is not a bug AFAICS.

> Similar requirements apply to the resume-side callbacks.  (But note 
> that RESTORE is not the inverse of POWEROFF; it is more like an inverse 
> of FREEZE with the added complication that the device's initial state 
> is unknown.)

It actually isn't even an inverse of FREEZE.  It is like RESUME with the
additional requirements that (a) it can never be skipped and (b) the
device need not be in a low-power state when it runs (the initial state
of it is unknown if you will).

> What changes to this analysis would SMART_SUSPEND allow?  None if the 
> device is runtime-active.  But if the device is runtime-suspended and 
> the wakeup settings don't need to be changed, then presumably none of 
> the four items are necessary.
> 
> Is this what you mean?

No.

What I meant was that even if the driver pointed ->runtime_suspend and
->suspend_late (say) to the same function and it pointed ->resume_early
and ->runtime_resume to the same function, it didn't have to point
->freeze_late and ->thaw_early to the same pair of functions, respectively.

It can point ->freeze_late and ->thaw_early to a pair of different functions
that only quiesce the device and reverse that, respectively.

> > [OK, I realize that (b) and (c) are not documented, see the notes below.]
> > 
> > Because of (a), if the device with SMART_SUSPEND set is still runtime-suspended
> > during the "late" phase of suspend, the core will not invoke the driver's
> > "late" and "noirq" suspend callbacks directly (*).  Middle layer (subsystem)
> > code is expected to behave accordingly.
> 
> Okay, this agrees with what I wrote above.
> 
> > Because of (b), if the "late" and "noirq" driver callbacks were skipped during
> > the "freeze" transition, the core will also avoid invoking the "noirq" and
> > "early" callbacks provided by the driver during the "thaw" transition and
> > the callbacks during the "restore" transition will be executed unconditionally
> > (**).  Middle layer code is expected to behave accordingly.
> 
> All right.  To summarize: If the driver's ->freeze_late callback is
> skipped then the driver's ->thaw-early will be skipped, and similarly
> for ->freeze_noirq and ->thaw_noirq.  But RESTORE callbacks are never
> skipped.  Correct?

Yes.

> However, the most difficult transitions are SUSPEND and RESUME.  Is it
> accurate to say that if the driver's ->suspend_late callback is skipped
> then the driver's ->resume_early will be skipped, and similarly for
> ->suspend_noirq and ->resume_noirq?

If LEAVE_SUSPENDED is set in addition to SMART_SUSPEND, then yes.

> > Notes:
> > 
> > 1. I have considered splitting SMART_SUSPEND into two or even three flags
> >    so that (a), (b) and (c) are each associated with a separate flag, but
> >    then I would expect the majority of users to use all of them anyway.
> > 
> > 2. LEAVE_SUSPENDED (which may be better renamed to SKIP_RESUME) is kind of
> >    expected to be used along with SMART_SUSPEND unless there is a good enough
> >    reason to avoid using it.  I admit that this isn't really straightforward,
> >    maybe the default behavior should be to skip the resume and there should be
> >    FORCE_RESUME instead of LEAVE_SUSPENDED.
> 
> One question not addressed above (in fact, the original reason for 
> getting you involved in this discussion): What about the device's 
> power.runtime_status?  Shall we say that that core will call 
> pm_runtime_set_active() at some point before issuing the ->complete 
> callback unless some combination of flags is set?  And what should that 
> combination be?
> 
> After all, we expect that most drivers will want their devices to be in 
> the runtime-active state at the end of a system sleep or hibernation.  
> It makes sense for the core to do the necessary housekeeping.

The core will set the PM-runtime status to "active" in device_resume_noirq()
if (a) the subsystem callbacks are not invoked (otherwise the subsystem is
responsible for doing that) and (b) if the driver's callback not skipped
(in which case its ->resume_early callback will not be skipped too).

> > 3. (*) Under the assumption that either ->suspend_late or ->suspend_noirq
> >    points to the same routine as ->runtime_suspend (and the other is NULL),
> >    invokig that callback for a runtime-suspended device is technically invalid.
> 
> Does this invalidate anything I wrote above?

I don't think so.  It is the reason why driver callbacks are skipped for
runtime-suspended devices.

> >    In turn, under the assumption that either ->resume_early or ->resume_noirq
> >    points to the same routine as ->runtime_resume (and the other is NULL), it is
> >    valid to invoke that callback if the late/noirq suspend was skipped.
> 
> In other words, it's okay for the core either to issue or skip those 
> callbacks.  Presumably the decision will be made based on some flag 
> setting?

Yes.  A flag combined with the PM-runtime status of the device in
device_suspend_noirq().

> > 4. (**) If the "freeze" and "thaw" callbacks are simplified, they cannot be
> >    run back-to-back with ->runtime_resume and ->runtime_suspend, respectively.
> >    Thus if "freeze" is skippend, "thaw" must be skipped too.  However,
> >    "restore" needs to be prepared to be invoked after "freeze" or
> >    ->runtime_suspend (and the state of the device may not match the
> >    callback that ran previously), so it must be special.
> > 
> > 5. I agree that skipping the driver level of callbacks depending on what is
> >    provided by the middle layer is inconsistent, but I wanted to take the
> >    users of pm_runtime_force_suspend/resume() into account by letting those
> >    things run.
> > 
> >    It would be more consistent to expect middle layer code (bus types, PM
> >    domains) to provide either all of the noirq/early/late callbacks, or none
> >    of them and make SMART_SUSPEND and pm_runtime_force_suspend/resume()
> >    mutually exclusive.
> 
> I don't have a clear idea of how pm_runtime_force_suspend/resume() gets 
> used.  Are we better off ignoring it for the time being?

Yes, we are.




^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: lockdep warning in urb.c:363 usb_submit_urb
  2020-04-03 18:32                                             ` Rafael J. Wysocki
@ 2020-04-03 20:15                                               ` Alan Stern
  2020-04-06 16:45                                                 ` Rafael J. Wysocki
  0 siblings, 1 reply; 50+ messages in thread
From: Alan Stern @ 2020-04-03 20:15 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Rafael J. Wysocki, Qais Yousef, USB list, Linux-pm mailing list,
	Kernel development list

For the most part we seem to be in agreement.

On Fri, 3 Apr 2020, Rafael J. Wysocki wrote:

> On Friday, April 3, 2020 6:41:05 PM CEST Alan Stern wrote:
> > On Fri, 3 Apr 2020, Rafael J. Wysocki wrote:

> > > (b) Drivers that set SMART_SUSPEND are allowed to reuse their PM-runtime
> > >     callbacks for system-wide suspend and resume.
> > > 
> > >     That is, they can point either the ->suspend_late or the ->suspend_noirq
> > >     callback pointer to the same function as ->runtime_suspend and they can
> > >     point either the ->resume_noirq or ->the resume_early callback to the'
> > >     same function as ->runtime_resume.
> > 
> > Well, in theory any driver or subsystem can do this whenever it wants
> > to, regardless of any flag settings.
> 
> Not exactly.
> 
> Say the driver wants to point both ->runtime_suspend and ->suspend_late to
> the same function.
> 
> If the bus type doesn't provide system-wide PM callbacks at all (which is
> the case for some bus types), that only works if the device is never
> runtime-suspended when ->suspend_late is about to run, because otherwise
> the function in question needs to check the context in which it is running
> (PM-runtime vs system-wide and runtime-suspended vs runtime-active in the
> latter case) which at least is awkward and hard to get right.
> 
> > It's then up to the driver or
> > subsystem to make sure the callback "does the right thing".
> 
> In theory.

Okay.  In any case, this is about what drivers should do, not about 
what the core should do.

> > What I'm concerned about now is: What guarantees can the core give to 
> > the driver and subsystem, so that they will know what is necessary in 
> > order to "do the right thing"?
> 
> I'm not sure what you mean.
> 
> If the subsystem provides callbacks, the core will run them regardless.
> 
> If it does not provide callbacks, the core will skip ->suspend_late and
> ->suspend_noirq for the driver and the device will remain suspended.
> 
> If SMART_SUSPEND is not set, the core will execute all of the callbacks
> that are present.

All right, then those are the guarantees I was thinking of.

> > > (c) Drivers that set SMART_SUSPEND are alwo allowed to provide special
> > >     simplified callbacks for the "freeze" and "thaw" transitions during
> > >     hibernation (and restore) and (if they do so) special callbacks for the
> > >     "restore" phase.
> > 
> > What do you mean by "simplified"?
> 
> Avoiding actual PM.
> 
> > As I see it, the suspend-side callbacks are generally responsible for 
> > four things:
> > 
> > 	1. Quiesce the device (finish ongoing I/O and do not allow any
> > 	   more to start).
> > 
> > 	2. Save the current device state.
> > 
> > 	3. Install the appropriate wakeup settings.
> > 
> > 	4. Put the device into low-power mode.
> > 
> > (Not explicitly listed: Perform a runtime-resume if needed in order to
> > carry out these four items.)
> > 
> > During a SUSPEND transition, we usually expect all four to happen.  

Based on what you said elsewhere, 4 may not be needed for SUSPEND 
(depending on the platform).

> > During a FREEZE transition, we only require 1.

Actually, FREEZE should do 2 as well.  Doing all four is acceptable,
though not optimal.

> That's what I mean by "simplified".
> 
> > During a POWEROFF
> > transition we require 1 and 3, and possibly 4 (depending on how the
> > platform handles poweroff).
> 
> But doing 2 is not a bug AFAICS.

Agreed.

> > Similar requirements apply to the resume-side callbacks.  (But note 
> > that RESTORE is not the inverse of POWEROFF; it is more like an inverse 
> > of FREEZE with the added complication that the device's initial state 
> > is unknown.)
> 
> It actually isn't even an inverse of FREEZE.  It is like RESUME with the
> additional requirements that (a) it can never be skipped and (b) the
> device need not be in a low-power state when it runs (the initial state
> of it is unknown if you will).

Let's put it like this: The resume-side callbacks should have the
overall effect of bringing the device back to its initial state, with
the following exceptions and complications:

	Unless SMART_SUSPEND and LEAVE_SUSPEND are both set, a device
	that was in runtime suspend before the suspend_late phase 
	must end up being runtime-active after the matching RESUME.

	Unless SMART_SUSPEND is set, a device that was in runtime 
	suspend before the freeze_late phase must end up being 
	runtime-active after the matching THAW.

[I'm not so sure about this.  Wouldn't it make more sense to treat
_every_ device as though SMART_SUSPEND was set for FREEZE/THAW
transitions, and require subsystems to do the same?]

	After RESTORE, _every_ device must end up being runtime 
	active.

	In general, each resume-side callback should undo the effect
	of the matching suspend-side callback.  However, because of
	the requirements mentioned in the preceding sentences,
	sometimes a resume-side callback will be issued even though
	the matching suspend-side callback was skipped -- i.e., when
	a device that starts out runtime-suspended ends up being
	runtime-active.

How does that sound?

> > What changes to this analysis would SMART_SUSPEND allow?  None if the 
> > device is runtime-active.  But if the device is runtime-suspended and 
> > the wakeup settings don't need to be changed, then presumably none of 
> > the four items are necessary.
> > 
> > Is this what you mean?
> 
> No.
> 
> What I meant was that even if the driver pointed ->runtime_suspend and
> ->suspend_late (say) to the same function and it pointed ->resume_early
> and ->runtime_resume to the same function, it didn't have to point
> ->freeze_late and ->thaw_early to the same pair of functions, respectively.
> 
> It can point ->freeze_late and ->thaw_early to a pair of different functions
> that only quiesce the device and reverse that, respectively.

Again, that describes what drivers or subsystems should do, not what 
the core will do.

> > > [OK, I realize that (b) and (c) are not documented, see the notes below.]
> > > 
> > > Because of (a), if the device with SMART_SUSPEND set is still runtime-suspended
> > > during the "late" phase of suspend, the core will not invoke the driver's
> > > "late" and "noirq" suspend callbacks directly (*).  Middle layer (subsystem)
> > > code is expected to behave accordingly.
> > 
> > Okay, this agrees with what I wrote above.
> > 
> > > Because of (b), if the "late" and "noirq" driver callbacks were skipped during
> > > the "freeze" transition, the core will also avoid invoking the "noirq" and
> > > "early" callbacks provided by the driver during the "thaw" transition and
> > > the callbacks during the "restore" transition will be executed unconditionally
> > > (**).  Middle layer code is expected to behave accordingly.
> > 
> > All right.  To summarize: If the driver's ->freeze_late callback is
> > skipped then the driver's ->thaw-early will be skipped, and similarly
> > for ->freeze_noirq and ->thaw_noirq.  But RESTORE callbacks are never
> > skipped.  Correct?
> 
> Yes.

And this will be true whether or not LEAVE_SUSPENDED is set, right?

> > However, the most difficult transitions are SUSPEND and RESUME.  Is it
> > accurate to say that if the driver's ->suspend_late callback is skipped
> > then the driver's ->resume_early will be skipped, and similarly for
> > ->suspend_noirq and ->resume_noirq?
> 
> If LEAVE_SUSPENDED is set in addition to SMART_SUSPEND, then yes.
> 
> > > Notes:
> > > 
> > > 1. I have considered splitting SMART_SUSPEND into two or even three flags
> > >    so that (a), (b) and (c) are each associated with a separate flag, but
> > >    then I would expect the majority of users to use all of them anyway.
> > > 
> > > 2. LEAVE_SUSPENDED (which may be better renamed to SKIP_RESUME) is kind of
> > >    expected to be used along with SMART_SUSPEND unless there is a good enough
> > >    reason to avoid using it.  I admit that this isn't really straightforward,
> > >    maybe the default behavior should be to skip the resume and there should be
> > >    FORCE_RESUME instead of LEAVE_SUSPENDED.
> > 
> > One question not addressed above (in fact, the original reason for 
> > getting you involved in this discussion): What about the device's 
> > power.runtime_status?  Shall we say that that core will call 
> > pm_runtime_set_active() at some point before issuing the ->complete 
> > callback unless some combination of flags is set?  And what should that 
> > combination be?
> > 
> > After all, we expect that most drivers will want their devices to be in 
> > the runtime-active state at the end of a system sleep or hibernation.  
> > It makes sense for the core to do the necessary housekeeping.
> 
> The core will set the PM-runtime status to "active" in device_resume_noirq()
> if (a) the subsystem callbacks are not invoked (otherwise the subsystem is
> responsible for doing that) and (b) if the driver's callback not skipped
> (in which case its ->resume_early callback will not be skipped too).

Are you certain you want the subsystem callback to be responsible for
setting the runtime status to "active"?  Isn't this an example of
something the core could do in order to help simplify subsystems?

> > > 3. (*) Under the assumption that either ->suspend_late or ->suspend_noirq
> > >    points to the same routine as ->runtime_suspend (and the other is NULL),
> > >    invokig that callback for a runtime-suspended device is technically invalid.
> > 
> > Does this invalidate anything I wrote above?
> 
> I don't think so.  It is the reason why driver callbacks are skipped for
> runtime-suspended devices.

And this brings up another thing the core might do to help simplify
drivers and subsystems: If SMART_SUSPEND isn't set and the device is in
runtime suspend, couldn't the core do a pm_runtime_resume before
issuing the ->suspend or ->suspend_late callback?

> > >    In turn, under the assumption that either ->resume_early or ->resume_noirq
> > >    points to the same routine as ->runtime_resume (and the other is NULL), it is
> > >    valid to invoke that callback if the late/noirq suspend was skipped.
> > 
> > In other words, it's okay for the core either to issue or skip those 
> > callbacks.  Presumably the decision will be made based on some flag 
> > setting?
> 
> Yes.  A flag combined with the PM-runtime status of the device in
> device_suspend_noirq().
> 
> > > 4. (**) If the "freeze" and "thaw" callbacks are simplified, they cannot be
> > >    run back-to-back with ->runtime_resume and ->runtime_suspend, respectively.
> > >    Thus if "freeze" is skippend, "thaw" must be skipped too.  However,
> > >    "restore" needs to be prepared to be invoked after "freeze" or
> > >    ->runtime_suspend (and the state of the device may not match the
> > >    callback that ran previously), so it must be special.
> > > 
> > > 5. I agree that skipping the driver level of callbacks depending on what is
> > >    provided by the middle layer is inconsistent, but I wanted to take the
> > >    users of pm_runtime_force_suspend/resume() into account by letting those
> > >    things run.
> > > 
> > >    It would be more consistent to expect middle layer code (bus types, PM
> > >    domains) to provide either all of the noirq/early/late callbacks, or none
> > >    of them and make SMART_SUSPEND and pm_runtime_force_suspend/resume()
> > >    mutually exclusive.
> > 
> > I don't have a clear idea of how pm_runtime_force_suspend/resume() gets 
> > used.  Are we better off ignoring it for the time being?
> 
> Yes, we are.

We're converging on a final answer!

Alan Stern


^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: lockdep warning in urb.c:363 usb_submit_urb
  2020-04-03 20:15                                               ` Alan Stern
@ 2020-04-06 16:45                                                 ` Rafael J. Wysocki
  2020-04-06 20:25                                                   ` Alan Stern
  0 siblings, 1 reply; 50+ messages in thread
From: Rafael J. Wysocki @ 2020-04-06 16:45 UTC (permalink / raw)
  To: Alan Stern
  Cc: Rafael J. Wysocki, Qais Yousef, USB list, Linux-pm mailing list,
	Kernel development list

On Friday, April 3, 2020 10:15:09 PM CEST Alan Stern wrote:
> For the most part we seem to be in agreement.

Indeed.

> On Fri, 3 Apr 2020, Rafael J. Wysocki wrote:
> 
> > On Friday, April 3, 2020 6:41:05 PM CEST Alan Stern wrote:
> > > On Fri, 3 Apr 2020, Rafael J. Wysocki wrote:
> 
> > > > (b) Drivers that set SMART_SUSPEND are allowed to reuse their PM-runtime
> > > >     callbacks for system-wide suspend and resume.
> > > > 
> > > >     That is, they can point either the ->suspend_late or the ->suspend_noirq
> > > >     callback pointer to the same function as ->runtime_suspend and they can
> > > >     point either the ->resume_noirq or ->the resume_early callback to the'
> > > >     same function as ->runtime_resume.
> > > 
> > > Well, in theory any driver or subsystem can do this whenever it wants
> > > to, regardless of any flag settings.
> > 
> > Not exactly.
> > 
> > Say the driver wants to point both ->runtime_suspend and ->suspend_late to
> > the same function.
> > 
> > If the bus type doesn't provide system-wide PM callbacks at all (which is
> > the case for some bus types), that only works if the device is never
> > runtime-suspended when ->suspend_late is about to run, because otherwise
> > the function in question needs to check the context in which it is running
> > (PM-runtime vs system-wide and runtime-suspended vs runtime-active in the
> > latter case) which at least is awkward and hard to get right.
> > 
> > > It's then up to the driver or
> > > subsystem to make sure the callback "does the right thing".
> > 
> > In theory.
> 
> Okay.  In any case, this is about what drivers should do, not about 
> what the core should do.

These two things are related to each other though.

> > > What I'm concerned about now is: What guarantees can the core give to 
> > > the driver and subsystem, so that they will know what is necessary in 
> > > order to "do the right thing"?
> > 
> > I'm not sure what you mean.
> > 
> > If the subsystem provides callbacks, the core will run them regardless.
> > 
> > If it does not provide callbacks, the core will skip ->suspend_late and
> > ->suspend_noirq for the driver and the device will remain suspended.
> > 
> > If SMART_SUSPEND is not set, the core will execute all of the callbacks
> > that are present.
> 
> All right, then those are the guarantees I was thinking of.

OK

> > > > (c) Drivers that set SMART_SUSPEND are alwo allowed to provide special
> > > >     simplified callbacks for the "freeze" and "thaw" transitions during
> > > >     hibernation (and restore) and (if they do so) special callbacks for the
> > > >     "restore" phase.
> > > 
> > > What do you mean by "simplified"?
> > 
> > Avoiding actual PM.
> > 
> > > As I see it, the suspend-side callbacks are generally responsible for 
> > > four things:
> > > 
> > > 	1. Quiesce the device (finish ongoing I/O and do not allow any
> > > 	   more to start).
> > > 
> > > 	2. Save the current device state.
> > > 
> > > 	3. Install the appropriate wakeup settings.
> > > 
> > > 	4. Put the device into low-power mode.
> > > 
> > > (Not explicitly listed: Perform a runtime-resume if needed in order to
> > > carry out these four items.)
> > > 
> > > During a SUSPEND transition, we usually expect all four to happen.  
> 
> Based on what you said elsewhere, 4 may not be needed for SUSPEND 
> (depending on the platform).

Right.

> > > During a FREEZE transition, we only require 1.
> 
> Actually, FREEZE should do 2 as well.  Doing all four is acceptable,
> though not optimal.

Right.

> > That's what I mean by "simplified".
> > 
> > > During a POWEROFF
> > > transition we require 1 and 3, and possibly 4 (depending on how the
> > > platform handles poweroff).
> > 
> > But doing 2 is not a bug AFAICS.
> 
> Agreed.
> 
> > > Similar requirements apply to the resume-side callbacks.  (But note 
> > > that RESTORE is not the inverse of POWEROFF; it is more like an inverse 
> > > of FREEZE with the added complication that the device's initial state 
> > > is unknown.)
> > 
> > It actually isn't even an inverse of FREEZE.  It is like RESUME with the
> > additional requirements that (a) it can never be skipped and (b) the
> > device need not be in a low-power state when it runs (the initial state
> > of it is unknown if you will).
> 
> Let's put it like this: The resume-side callbacks should have the
> overall effect of bringing the device back to its initial state, with
> the following exceptions and complications:
> 
> 	Unless SMART_SUSPEND and LEAVE_SUSPEND are both set, a device
> 	that was in runtime suspend before the suspend_late phase 
> 	must end up being runtime-active after the matching RESUME.
>
> 	Unless SMART_SUSPEND is set, a device that was in runtime 
> 	suspend before the freeze_late phase must end up being 
> 	runtime-active after the matching THAW.

Correct.
 
> [I'm not so sure about this.  Wouldn't it make more sense to treat
> _every_ device as though SMART_SUSPEND was set for FREEZE/THAW
> transitions, and require subsystems to do the same?]

Drivers may expect devices to be runtime-active when their suspend
callbacks are invoked unless they set SMART_SUSPEND.  IOW, without
SMART_SUSPEND set the device should not be left in runtime suspend
during system-wide suspend at all unless direct-complete is applied
to it.

> 	After RESTORE, _every_ device must end up being runtime 
> 	active.

Correct.

> 	In general, each resume-side callback should undo the effect
> 	of the matching suspend-side callback.  However, because of
> 	the requirements mentioned in the preceding sentences,
> 	sometimes a resume-side callback will be issued even though
> 	the matching suspend-side callback was skipped -- i.e., when
> 	a device that starts out runtime-suspended ends up being
> 	runtime-active.
> 
> How does that sound?

It is correct, but in general the other way around is possible too.
That is, a suspend-side callback may be issued without the matching
resume-side one and the device's PM runtime status may be changed
if LEAVE_SUSPENDED is set and SMART_SUSPEND is unset.

> > > What changes to this analysis would SMART_SUSPEND allow?  None if the 
> > > device is runtime-active.  But if the device is runtime-suspended and 
> > > the wakeup settings don't need to be changed, then presumably none of 
> > > the four items are necessary.
> > > 
> > > Is this what you mean?
> > 
> > No.
> > 
> > What I meant was that even if the driver pointed ->runtime_suspend and
> > ->suspend_late (say) to the same function and it pointed ->resume_early
> > and ->runtime_resume to the same function, it didn't have to point
> > ->freeze_late and ->thaw_early to the same pair of functions, respectively.
> > 
> > It can point ->freeze_late and ->thaw_early to a pair of different functions
> > that only quiesce the device and reverse that, respectively.
> 
> Again, that describes what drivers or subsystems should do, not what 
> the core will do.
> 
> > > > [OK, I realize that (b) and (c) are not documented, see the notes below.]
> > > > 
> > > > Because of (a), if the device with SMART_SUSPEND set is still runtime-suspended
> > > > during the "late" phase of suspend, the core will not invoke the driver's
> > > > "late" and "noirq" suspend callbacks directly (*).  Middle layer (subsystem)
> > > > code is expected to behave accordingly.
> > > 
> > > Okay, this agrees with what I wrote above.
> > > 
> > > > Because of (b), if the "late" and "noirq" driver callbacks were skipped during
> > > > the "freeze" transition, the core will also avoid invoking the "noirq" and
> > > > "early" callbacks provided by the driver during the "thaw" transition and
> > > > the callbacks during the "restore" transition will be executed unconditionally
> > > > (**).  Middle layer code is expected to behave accordingly.
> > > 
> > > All right.  To summarize: If the driver's ->freeze_late callback is
> > > skipped then the driver's ->thaw-early will be skipped, and similarly
> > > for ->freeze_noirq and ->thaw_noirq.  But RESTORE callbacks are never
> > > skipped.  Correct?
> > 
> > Yes.
> 
> And this will be true whether or not LEAVE_SUSPENDED is set, right?

Right.

> > > However, the most difficult transitions are SUSPEND and RESUME.  Is it
> > > accurate to say that if the driver's ->suspend_late callback is skipped
> > > then the driver's ->resume_early will be skipped, and similarly for
> > > ->suspend_noirq and ->resume_noirq?
> > 
> > If LEAVE_SUSPENDED is set in addition to SMART_SUSPEND, then yes.
> > 
> > > > Notes:
> > > > 
> > > > 1. I have considered splitting SMART_SUSPEND into two or even three flags
> > > >    so that (a), (b) and (c) are each associated with a separate flag, but
> > > >    then I would expect the majority of users to use all of them anyway.
> > > > 
> > > > 2. LEAVE_SUSPENDED (which may be better renamed to SKIP_RESUME) is kind of
> > > >    expected to be used along with SMART_SUSPEND unless there is a good enough
> > > >    reason to avoid using it.  I admit that this isn't really straightforward,
> > > >    maybe the default behavior should be to skip the resume and there should be
> > > >    FORCE_RESUME instead of LEAVE_SUSPENDED.
> > > 
> > > One question not addressed above (in fact, the original reason for 
> > > getting you involved in this discussion): What about the device's 
> > > power.runtime_status?  Shall we say that that core will call 
> > > pm_runtime_set_active() at some point before issuing the ->complete 
> > > callback unless some combination of flags is set?  And what should that 
> > > combination be?
> > > 
> > > After all, we expect that most drivers will want their devices to be in 
> > > the runtime-active state at the end of a system sleep or hibernation.  
> > > It makes sense for the core to do the necessary housekeeping.
> > 
> > The core will set the PM-runtime status to "active" in device_resume_noirq()
> > if (a) the subsystem callbacks are not invoked (otherwise the subsystem is
> > responsible for doing that) and (b) if the driver's callback not skipped
> > (in which case its ->resume_early callback will not be skipped too).
> 
> Are you certain you want the subsystem callback to be responsible for
> setting the runtime status to "active"?  Isn't this an example of
> something the core could do in order to help simplify subsystems?

The rationale here is that whoever decides whether or not to skip the
driver-level callbacks, should also set the PM-runtime status of the
device to match that decision.

> > > > 3. (*) Under the assumption that either ->suspend_late or ->suspend_noirq
> > > >    points to the same routine as ->runtime_suspend (and the other is NULL),
> > > >    invokig that callback for a runtime-suspended device is technically invalid.
> > > 
> > > Does this invalidate anything I wrote above?
> > 
> > I don't think so.  It is the reason why driver callbacks are skipped for
> > runtime-suspended devices.
> 
> And this brings up another thing the core might do to help simplify
> drivers and subsystems: If SMART_SUSPEND isn't set and the device is in
> runtime suspend, couldn't the core do a pm_runtime_resume before
> issuing the ->suspend or ->suspend_late callback?

It could, but sometimes that is not desirable.  Like when the drivver points its
suspend callback to pm_runtime_force_suspend().

> > > >    In turn, under the assumption that either ->resume_early or ->resume_noirq
> > > >    points to the same routine as ->runtime_resume (and the other is NULL), it is
> > > >    valid to invoke that callback if the late/noirq suspend was skipped.
> > > 
> > > In other words, it's okay for the core either to issue or skip those 
> > > callbacks.  Presumably the decision will be made based on some flag 
> > > setting?
> > 
> > Yes.  A flag combined with the PM-runtime status of the device in
> > device_suspend_noirq().
> > 
> > > > 4. (**) If the "freeze" and "thaw" callbacks are simplified, they cannot be
> > > >    run back-to-back with ->runtime_resume and ->runtime_suspend, respectively.
> > > >    Thus if "freeze" is skippend, "thaw" must be skipped too.  However,
> > > >    "restore" needs to be prepared to be invoked after "freeze" or
> > > >    ->runtime_suspend (and the state of the device may not match the
> > > >    callback that ran previously), so it must be special.
> > > > 
> > > > 5. I agree that skipping the driver level of callbacks depending on what is
> > > >    provided by the middle layer is inconsistent, but I wanted to take the
> > > >    users of pm_runtime_force_suspend/resume() into account by letting those
> > > >    things run.
> > > > 
> > > >    It would be more consistent to expect middle layer code (bus types, PM
> > > >    domains) to provide either all of the noirq/early/late callbacks, or none
> > > >    of them and make SMART_SUSPEND and pm_runtime_force_suspend/resume()
> > > >    mutually exclusive.
> > > 
> > > I don't have a clear idea of how pm_runtime_force_suspend/resume() gets 
> > > used.  Are we better off ignoring it for the time being?
> > 
> > Yes, we are.
> 
> We're converging on a final answer!

I think so.

In the meantime I have created a git branch with changes to simplify the code,
rename some things and clarify the documentation a bit:

 git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
 pm-sleep-core

(https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/log/?h=pm-sleep-core
for web access).

I'm going to post these changes as patches soon.

Cheers!




^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: lockdep warning in urb.c:363 usb_submit_urb
  2020-04-06 16:45                                                 ` Rafael J. Wysocki
@ 2020-04-06 20:25                                                   ` Alan Stern
  2020-04-09 18:45                                                     ` Rafael J. Wysocki
  0 siblings, 1 reply; 50+ messages in thread
From: Alan Stern @ 2020-04-06 20:25 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Rafael J. Wysocki, Qais Yousef, USB list, Linux-pm mailing list,
	Kernel development list

On Mon, 6 Apr 2020, Rafael J. Wysocki wrote:

> In the meantime I have created a git branch with changes to simplify the code,
> rename some things and clarify the documentation a bit:
> 
>  git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
>  pm-sleep-core
> 
> (https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/log/?h=pm-sleep-core
> for web access).
> 
> I'm going to post these changes as patches soon.

All right, those are some significant changes.  It'll take me a little 
while to absorb them.

> On Friday, April 3, 2020 10:15:09 PM CEST Alan Stern wrote:

> > Let's put it like this: The resume-side callbacks should have the
> > overall effect of bringing the device back to its initial state, with
> > the following exceptions and complications:
> > 
> > 	Unless SMART_SUSPEND and LEAVE_SUSPEND are both set, a device
> > 	that was in runtime suspend before the suspend_late phase 
> > 	must end up being runtime-active after the matching RESUME.
> >
> > 	Unless SMART_SUSPEND is set, a device that was in runtime 
> > 	suspend before the freeze_late phase must end up being 
> > 	runtime-active after the matching THAW.
> 
> Correct.
>  
> > [I'm not so sure about this.  Wouldn't it make more sense to treat
> > _every_ device as though SMART_SUSPEND was set for FREEZE/THAW
> > transitions, and require subsystems to do the same?]
> 
> Drivers may expect devices to be runtime-active when their suspend
> callbacks are invoked unless they set SMART_SUSPEND.  IOW, without
> SMART_SUSPEND set the device should not be left in runtime suspend
> during system-wide suspend at all unless direct-complete is applied
> to it.

[Let's confine this discussion to the not-direct-complete case.]

Okay, say that SMART_SUSPEND isn't set and the device is initially
runtime-suspended.  Since the core knows all this, shouldn't the core 
then call pm_runtime_resume() immediately before ->suspend?  Why leave 
this up to subsystems or drivers (which can easily get it wrong -- 
not to mention all the code duplication it would require)?

Also, doesn't it make sense for some subsystems or drivers to want 
their devices to remain in runtime suspend throughout a FREEZE/THAW 
transition but not throughout a SUSPEND/RESUME transition?  With only a 
single SMART_SUSPEND flag, how can we accomodate this desire?

Finally, my description above says that LEAVE_SUSPENDED matters for 
SUSPEND/RESUME but not for FREEZE/THAW.  Is that really what you have 
in mind?

> > 	After RESTORE, _every_ device must end up being runtime 
> > 	active.
> 
> Correct.
> 
> > 	In general, each resume-side callback should undo the effect
> > 	of the matching suspend-side callback.  However, because of
> > 	the requirements mentioned in the preceding sentences,
> > 	sometimes a resume-side callback will be issued even though
> > 	the matching suspend-side callback was skipped -- i.e., when
> > 	a device that starts out runtime-suspended ends up being
> > 	runtime-active.
> > 
> > How does that sound?
> 
> It is correct, but in general the other way around is possible too.
> That is, a suspend-side callback may be issued without the matching
> resume-side one and the device's PM runtime status may be changed
> if LEAVE_SUSPENDED is set and SMART_SUSPEND is unset.

This is inconsistent with what I wrote above (the "Unless SMART_SUSPEND
and LEAVE_SUSPENDED are both set" part).  Are you saying that text
should be changed?

> > Are you certain you want the subsystem callback to be responsible for
> > setting the runtime status to "active"?  Isn't this an example of
> > something the core could do in order to help simplify subsystems?
> 
> The rationale here is that whoever decides whether or not to skip the
> driver-level callbacks, should also set the PM-runtime status of the
> device to match that decision.

Well, that's not really a fair description.  The decision about
skipping driver-level callbacks is being made right here, by us, now.  
(Or if you prefer, by the developers who originally added the
SMART_SUSPEND flag.)  We require subsystems to obey the decisions being
outlined in this discussion.

Given that fact, this is again a case of having the core do something 
rather than forcing subsystems/drivers to do it (possibly getting it 
wrong and certainly creating a lot of code duplication).

If a subsystem really wants to override our decision, it can always
call pm_runtime_set_{active|suspended} to override the core's setting.

> > And this brings up another thing the core might do to help simplify
> > drivers and subsystems: If SMART_SUSPEND isn't set and the device is in
> > runtime suspend, couldn't the core do a pm_runtime_resume before
> > issuing the ->suspend or ->suspend_late callback?
> 
> It could, but sometimes that is not desirable.  Like when the drivver points its
> suspend callback to pm_runtime_force_suspend().

This seems to contradict what you wrote above: "Drivers may expect
devices to be runtime-active when their suspend callbacks are invoked
unless they set SMART_SUSPEND.  IOW, without SMART_SUSPEND set the
device should not be left in runtime suspend during system-wide suspend
at all unless direct-complete is applied to it."

If you stand by that statement then drivers should never point their
suspend callback to pm_runtime_force_suspend() unless they also set
SMART_SUSPEND.

Alan Stern


^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: lockdep warning in urb.c:363 usb_submit_urb
  2020-04-06 20:25                                                   ` Alan Stern
@ 2020-04-09 18:45                                                     ` Rafael J. Wysocki
  2020-04-11  2:41                                                       ` Alan Stern
  0 siblings, 1 reply; 50+ messages in thread
From: Rafael J. Wysocki @ 2020-04-09 18:45 UTC (permalink / raw)
  To: Alan Stern
  Cc: Rafael J. Wysocki, Qais Yousef, USB list, Linux-pm mailing list,
	Kernel development list

On Monday, April 6, 2020 10:25:08 PM CEST Alan Stern wrote:
> On Mon, 6 Apr 2020, Rafael J. Wysocki wrote:
> 
> > In the meantime I have created a git branch with changes to simplify the code,
> > rename some things and clarify the documentation a bit:
> > 
> >  git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
> >  pm-sleep-core
> > 
> > (https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/log/?h=pm-sleep-core
> > for web access).
> > 
> > I'm going to post these changes as patches soon.
> 
> All right, those are some significant changes.  It'll take me a little 
> while to absorb them.
> 
> > On Friday, April 3, 2020 10:15:09 PM CEST Alan Stern wrote:
> 
> > > Let's put it like this: The resume-side callbacks should have the
> > > overall effect of bringing the device back to its initial state, with
> > > the following exceptions and complications:
> > > 
> > > 	Unless SMART_SUSPEND and LEAVE_SUSPEND are both set, a device
> > > 	that was in runtime suspend before the suspend_late phase 
> > > 	must end up being runtime-active after the matching RESUME.
> > >
> > > 	Unless SMART_SUSPEND is set, a device that was in runtime 
> > > 	suspend before the freeze_late phase must end up being 
> > > 	runtime-active after the matching THAW.
> > 
> > Correct.
> >  
> > > [I'm not so sure about this.  Wouldn't it make more sense to treat
> > > _every_ device as though SMART_SUSPEND was set for FREEZE/THAW
> > > transitions, and require subsystems to do the same?]
> > 
> > Drivers may expect devices to be runtime-active when their suspend
> > callbacks are invoked unless they set SMART_SUSPEND.  IOW, without
> > SMART_SUSPEND set the device should not be left in runtime suspend
> > during system-wide suspend at all unless direct-complete is applied
> > to it.
> 
> [Let's confine this discussion to the not-direct-complete case.]
> 
> Okay, say that SMART_SUSPEND isn't set and the device is initially
> runtime-suspended.  Since the core knows all this, shouldn't the core 
> then call pm_runtime_resume() immediately before ->suspend?  Why leave 
> this up to subsystems or drivers (which can easily get it wrong -- 
> not to mention all the code duplication it would require)?

I would agree in principle, but that has been done by subsystems forever and
(at least in some cases) drivers on bus types like platform on i2c (where
subsystem-level PM callbacks are not provided in general unless there is a PM
domain doing that) don't expect the devices to be resumed and they
decide whether or not to do that themselves.

Making the core resume the runtime-suspended devices during system-wide
suspend, would require those drivers to adapt and it is rather hard to
even estimate how many of them there are.

> Also, doesn't it make sense for some subsystems or drivers to want 
> their devices to remain in runtime suspend throughout a FREEZE/THAW 
> transition but not throughout a SUSPEND/RESUME transition?  With only a 
> single SMART_SUSPEND flag, how can we accomodate this desire?

That's a fair statement, but in general it is more desirable to optimize
suspend/resume than to optimize hibernation, so the latter is not a priority.

I'm not ruling out adding one more flag specific to hibernation or similar
in the future.

> Finally, my description above says that LEAVE_SUSPENDED matters for 
> SUSPEND/RESUME but not for FREEZE/THAW.  Is that really what you have 
> in mind?

Yes, it is.  LEAVE_SUSPENDED really does not apply to hibernation at all.

> > > 	After RESTORE, _every_ device must end up being runtime 
> > > 	active.
> > 
> > Correct.
> > 
> > > 	In general, each resume-side callback should undo the effect
> > > 	of the matching suspend-side callback.  However, because of
> > > 	the requirements mentioned in the preceding sentences,
> > > 	sometimes a resume-side callback will be issued even though
> > > 	the matching suspend-side callback was skipped -- i.e., when
> > > 	a device that starts out runtime-suspended ends up being
> > > 	runtime-active.
> > > 
> > > How does that sound?
> > 
> > It is correct, but in general the other way around is possible too.
> > That is, a suspend-side callback may be issued without the matching
> > resume-side one and the device's PM runtime status may be changed
> > if LEAVE_SUSPENDED is set and SMART_SUSPEND is unset.
> 
> This is inconsistent with what I wrote above (the "Unless SMART_SUSPEND
> and LEAVE_SUSPENDED are both set" part).  Are you saying that text
> should be changed?

Yes, in fact SMART_SUSPEND need not be set for resume callbacks to be skipped.

LEAVE_SUSPENDED must be set for that to happen (except for hibernation) and it
may be sufficient if the subsystem sets power.may_skip_resume in addition.

> > > Are you certain you want the subsystem callback to be responsible for
> > > setting the runtime status to "active"?  Isn't this an example of
> > > something the core could do in order to help simplify subsystems?
> > 
> > The rationale here is that whoever decides whether or not to skip the
> > driver-level callbacks, should also set the PM-runtime status of the
> > device to match that decision.
> 
> Well, that's not really a fair description.  The decision about
> skipping driver-level callbacks is being made right here, by us, now.  
> (Or if you prefer, by the developers who originally added the
> SMART_SUSPEND flag.)  We require subsystems to obey the decisions being
> outlined in this discussion.
> 
> Given that fact, this is again a case of having the core do something 
> rather than forcing subsystems/drivers to do it (possibly getting it 
> wrong and certainly creating a lot of code duplication).
> 
> If a subsystem really wants to override our decision, it can always
> call pm_runtime_set_{active|suspended} to override the core's setting.

OK, fair enough.

I've incorporated this into the changes on the pm-sleep-core branch
mentioned before.

> > > And this brings up another thing the core might do to help simplify
> > > drivers and subsystems: If SMART_SUSPEND isn't set and the device is in
> > > runtime suspend, couldn't the core do a pm_runtime_resume before
> > > issuing the ->suspend or ->suspend_late callback?
> > 
> > It could, but sometimes that is not desirable.  Like when the drivver points its
> > suspend callback to pm_runtime_force_suspend().
> 
> This seems to contradict what you wrote above: "Drivers may expect
> devices to be runtime-active when their suspend callbacks are invoked
> unless they set SMART_SUSPEND.  IOW, without SMART_SUSPEND set the
> device should not be left in runtime suspend during system-wide suspend
> at all unless direct-complete is applied to it."
> 
> If you stand by that statement then drivers should never point their
> suspend callback to pm_runtime_force_suspend() unless they also set
> SMART_SUSPEND.

OK, let me rephrase.

Some drivers that don't use SMART_SUSPEND expect the devices to be runtime-active
when their system-wide PM callbacks run, but the other drivers do not have such
expectations, because the subsystems they work with have never resumed devices
during system-wide suspend.

SMART_SUSPEND is not needed for the latter category of drivers, but it is for
the former and I want the behavior when SMART_SUSPEND *is* set to be consistent
across the core and subsystems, while the other case have never been so.

Cheers!




^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: lockdep warning in urb.c:363 usb_submit_urb
  2020-04-09 18:45                                                     ` Rafael J. Wysocki
@ 2020-04-11  2:41                                                       ` Alan Stern
  2020-04-13 21:32                                                         ` Rafael J. Wysocki
  0 siblings, 1 reply; 50+ messages in thread
From: Alan Stern @ 2020-04-11  2:41 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Rafael J. Wysocki, Qais Yousef, USB list, Linux-pm mailing list,
	Kernel development list

Okay, this is my attempt to summarize what we have been discussing.  
But first: There is a dev_pm_skip_resume() helper routine which
subsystems can call to see whether resume-side _early and _noirq driver
callbacks should be skipped.  But there is no corresponding
dev_pm_skip_suspend() helper routine.  Let's add one, or rename
dev_pm_smart_suspend_and_suspended() to dev_pm_skip_suspend().

Given that, here's my understanding of what should happen.  (I'm
assuming the direct_complete mechanism is not being used.)  This tries
to describe what we _want_ to happen, which is not always the same as
what the current code actually _does_.

	During the suspend side, for each of the
	{suspend,freeze,poweroff}_{late,noirq} phases: If
	dev_pm_skip_suspend() returns true then the subsystem should
	not invoke the driver's callback, and if there is no subsystem
	callback then the core will not invoke the driver's callback.

	During the resume side, for each of the
	{resume,thaw,restore}_{early,noirq} phases: If
	dev_pm_skip_resume() returns true then the subsystem should
	not invoke the driver's callback, and if there is no subsystem
	callback then the core will not invoke the driver's callback.

	dev_pm_skip_suspend() will return "true" if SMART_SUSPEND is
	set and the device's runtime status is "suspended".

	power.must_resume gets set following the suspend-side _noirq
	phase if power.usage_count > 1 (indicating the device was
	in active use before the start of the sleep transition) or
	power.must_resume is set for any of the device's dependents.

	dev_pm_skip_resume() will return "false" if the current
	transition is RESTORE or power.must_resume is set.  Otherwise:
	It will return true if the current transition is THAW,
	SMART_SUSPEND is set, and the device's runtime status is
	"suspended".  It will return "true" if the current transition is
	RESUME, SMART_SUSPEND and MAY_SKIP_RESUME are both set, and
	the device's runtime status is "suspended".  For a RESUME
	transition, it will also return "true" if MAY_SKIP_RESUME and
	power.may_skip_resume are both set, regardless of
	SMART_SUSPEND or the current runtime status.

	At the start of the {resume,thaw,restore}_noirq phase, if
	dev_pm_skip_resume() returns true then the core will set the
	runtime status to "suspended".  Otherwise it will set the
	runtime status to "active".  If this is not what the subsystem
	or driver wants, it must update the runtime status itself.

Comments and differences with respect to the code in your pm-sleep-core
branch:

	I'm not sure whether we should specify other conditions for
	setting power.must_resume.

	dev_pm_skip_resume() doesn't compute the value described
	above.  I'm pretty sure the existing code is wrong.

	device_resume_noirq() checks
	dev_pm_smart_suspend_and_suspended() before setting the
	runtime PM status to "active", contrary to the text above.
	The difference shows up in the case where SMART_SUSPEND is
	clear but the runtime PM status is "suspended".  Don't we want
	to set the status to "active" in this case?  Or is there some 
	need to accomodate legacy drivers here?  In any case, wouldn't
	it be good enough to check just the SMART_SUSPEND flag?

	__device_suspend_late() sets power.may_skip_resume, contrary
	to the comment in include/linux/pm.h: That flag is supposed to
	be set by subsystems, not the core.

	I'm not at all sure that this algorithm won't run into trouble
	at some point when it tries to set a device's runtime status
	to "active" but the parent's status is set to "suspended".
	And I'm not sure this problem can be fixed by adjusting
	power.must_resume.

Alan Stern


^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: lockdep warning in urb.c:363 usb_submit_urb
  2020-04-11  2:41                                                       ` Alan Stern
@ 2020-04-13 21:32                                                         ` Rafael J. Wysocki
  2020-04-14 13:43                                                           ` Rafael J. Wysocki
  0 siblings, 1 reply; 50+ messages in thread
From: Rafael J. Wysocki @ 2020-04-13 21:32 UTC (permalink / raw)
  To: Alan Stern
  Cc: Rafael J. Wysocki, Qais Yousef, USB list, Linux-pm mailing list,
	Kernel development list

On Saturday, April 11, 2020 4:41:14 AM CEST Alan Stern wrote:
> Okay, this is my attempt to summarize what we have been discussing.  
> But first: There is a dev_pm_skip_resume() helper routine which
> subsystems can call to see whether resume-side _early and _noirq driver
> callbacks should be skipped.  But there is no corresponding
> dev_pm_skip_suspend() helper routine.  Let's add one, or rename
> dev_pm_smart_suspend_and_suspended() to dev_pm_skip_suspend().

OK

> Given that, here's my understanding of what should happen.  (I'm
> assuming the direct_complete mechanism is not being used.)  This tries
> to describe what we _want_ to happen, which is not always the same as
> what the current code actually _does_.

OK

> 	During the suspend side, for each of the
> 	{suspend,freeze,poweroff}_{late,noirq} phases: If
> 	dev_pm_skip_suspend() returns true then the subsystem should
> 	not invoke the driver's callback, and if there is no subsystem
> 	callback then the core will not invoke the driver's callback.
> 
> 	During the resume side, for each of the
> 	{resume,thaw,restore}_{early,noirq} phases: If
> 	dev_pm_skip_resume() returns true then the subsystem should
> 	not invoke the driver's callback, and if there is no subsystem
> 	callback then the core will not invoke the driver's callback.
> 
> 	dev_pm_skip_suspend() will return "true" if SMART_SUSPEND is
> 	set and the device's runtime status is "suspended".

Agreed with the above.

> 	power.must_resume gets set following the suspend-side _noirq
> 	phase if power.usage_count > 1 (indicating the device was
> 	in active use before the start of the sleep transition) or
> 	power.must_resume is set for any of the device's dependents.

Or MAY_SKIP_RESUME is unset (which means that the driver does not
allow its resume callbacks to be skipped), or power.may_skip_resume
is unset (which means that the subsystem does not allow the
driver callbacks to be skipped).

> 	dev_pm_skip_resume() will return "false" if the current
> 	transition is RESTORE or power.must_resume is set.  Otherwise:
> 	It will return true if the current transition is THAW,
> 	SMART_SUSPEND is set, and the device's runtime status is
> 	"suspended".

The other way around.  That is:

dev_pm_skip_resume() will return "true" if the current transition is
THAW and dev_pm_skip_suspend() returns "true" for that device (so
SMART_SUSPEND is set, and the device's runtime status is "suspended",
as per the definition of that function above).

Otherwise, it will return "true" if the current transition is RESTORE
(which means that all devices are resumed) or power.must_resume is not
set (so this particular device need not be resumed).

>  It will return "true" if the current transition is
> 	RESUME, SMART_SUSPEND and MAY_SKIP_RESUME are both set, and
> 	the device's runtime status is "suspended".

Unless MAY_SKIP_RESUME is unset for at least one of its descendants (or
dependent devices).

> 	For a RESUME
> 	transition, it will also return "true" if MAY_SKIP_RESUME and
> 	power.may_skip_resume are both set, regardless of
> 	SMART_SUSPEND or the current runtime status.

And if the device was not in active use before suspend (as per its usage
counter) or MAY_SKIP_RESUME is unset for at least one of its descendants (or
dependent devices in general).

> 	At the start of the {resume,thaw,restore}_noirq phase, if
> 	dev_pm_skip_resume() returns true then the core will set the
> 	runtime status to "suspended".  Otherwise it will set the
> 	runtime status to "active".  If this is not what the subsystem
> 	or driver wants, it must update the runtime status itself.

Right.

> Comments and differences with respect to the code in your pm-sleep-core
> branch:
> 
> 	I'm not sure whether we should specify other conditions for
> 	setting power.must_resume.

IMO we should.

Otherwise it is rather hard to catch the case in which one of the
device's descendants has MAY_SKIP_RESUME unset (and so the device
needs to be resumed).

> 	dev_pm_skip_resume() doesn't compute the value described
> 	above.  I'm pretty sure the existing code is wrong.

Well, we don't seem to have reached an agreement on some details
above ...

Cheers!




^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: lockdep warning in urb.c:363 usb_submit_urb
  2020-04-13 21:32                                                         ` Rafael J. Wysocki
@ 2020-04-14 13:43                                                           ` Rafael J. Wysocki
  2020-04-14 17:47                                                             ` Alan Stern
  0 siblings, 1 reply; 50+ messages in thread
From: Rafael J. Wysocki @ 2020-04-14 13:43 UTC (permalink / raw)
  To: Alan Stern
  Cc: Rafael J. Wysocki, Qais Yousef, USB list, Linux-pm mailing list,
	Kernel development list

Note to self: avoid replying to technical messages late in the night ...

On Mon, Apr 13, 2020 at 11:32 PM Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>
> On Saturday, April 11, 2020 4:41:14 AM CEST Alan Stern wrote:
> > Okay, this is my attempt to summarize what we have been discussing.
> > But first: There is a dev_pm_skip_resume() helper routine which
> > subsystems can call to see whether resume-side _early and _noirq driver
> > callbacks should be skipped.  But there is no corresponding
> > dev_pm_skip_suspend() helper routine.  Let's add one, or rename
> > dev_pm_smart_suspend_and_suspended() to dev_pm_skip_suspend().
>
> OK
>
> > Given that, here's my understanding of what should happen.  (I'm
> > assuming the direct_complete mechanism is not being used.)  This tries
> > to describe what we _want_ to happen, which is not always the same as
> > what the current code actually _does_.
>
> OK
>
> >       During the suspend side, for each of the
> >       {suspend,freeze,poweroff}_{late,noirq} phases: If
> >       dev_pm_skip_suspend() returns true then the subsystem should
> >       not invoke the driver's callback, and if there is no subsystem
> >       callback then the core will not invoke the driver's callback.
> >
> >       During the resume side, for each of the
> >       {resume,thaw,restore}_{early,noirq} phases: If
> >       dev_pm_skip_resume() returns true then the subsystem should
> >       not invoke the driver's callback, and if there is no subsystem
> >       callback then the core will not invoke the driver's callback.
> >
> >       dev_pm_skip_suspend() will return "true" if SMART_SUSPEND is
> >       set and the device's runtime status is "suspended".
>
> Agreed with the above.
>
> >       power.must_resume gets set following the suspend-side _noirq
> >       phase if power.usage_count > 1 (indicating the device was
> >       in active use before the start of the sleep transition) or
> >       power.must_resume is set for any of the device's dependents.
>
> Or MAY_SKIP_RESUME is unset (which means that the driver does not
> allow its resume callbacks to be skipped), or power.may_skip_resume
> is unset (which means that the subsystem does not allow the
> driver callbacks to be skipped).
>
> >       dev_pm_skip_resume() will return "false" if the current
> >       transition is RESTORE or power.must_resume is set.  Otherwise:
> >       It will return true if the current transition is THAW,
> >       SMART_SUSPEND is set, and the device's runtime status is
> >       "suspended".
>
> The other way around.  That is:
>
> dev_pm_skip_resume() will return "true" if the current transition is
> THAW and dev_pm_skip_suspend() returns "true" for that device (so
> SMART_SUSPEND is set, and the device's runtime status is "suspended",
> as per the definition of that function above).

The above is what I wanted to say ->

> Otherwise, it will return "true" if the current transition is RESTORE
> (which means that all devices are resumed) or power.must_resume is not
> set (so this particular device need not be resumed).

-> but this isn't.  In particular, I messed up the RESTORE part, so it
should read:

Otherwise, it will return "true" if the current transition is *not*
RESTORE (in which case all devices would be resumed) *and*
power.must_resume is not set (so this particular device need not be
resumed).

Sorry about that.

> >  It will return "true" if the current transition is
> >       RESUME, SMART_SUSPEND and MAY_SKIP_RESUME are both set, and
> >       the device's runtime status is "suspended".
>
> Unless MAY_SKIP_RESUME is unset for at least one of its descendants (or
> dependent devices).

That should include the power.may_skip_resume flag, so as to read as follows:

Unless MAY_SKIP_RESUME is unset or power.may_skip_resume is unset for
at least one of its descendants (or dependent devices).

> >       For a RESUME
> >       transition, it will also return "true" if MAY_SKIP_RESUME and
> >       power.may_skip_resume are both set, regardless of
> >       SMART_SUSPEND or the current runtime status.
>
> And if the device was not in active use before suspend (as per its usage
> counter) or MAY_SKIP_RESUME is unset for at least one of its descendants (or
> dependent devices in general).

And analogously here, so what I really should have written is:

And if the device was not in active use before suspend (as per its
usage counter) or MAY_SKIP_RESUME or power.may_skip_resume is unset
for at least one of its descendants (or dependent devices in general).

> >       At the start of the {resume,thaw,restore}_noirq phase, if
> >       dev_pm_skip_resume() returns true then the core will set the
> >       runtime status to "suspended".  Otherwise it will set the
> >       runtime status to "active".  If this is not what the subsystem
> >       or driver wants, it must update the runtime status itself.
>
> Right.
>
> > Comments and differences with respect to the code in your pm-sleep-core
> > branch:
> >
> >       I'm not sure whether we should specify other conditions for
> >       setting power.must_resume.
>
> IMO we should.

In fact, this is part of the implementation and it helps to
"propagate" the "must resume" condition to the parent and the
first-order suppliers of the device (which is sufficient, because
their power.must_resume "propagates" in the same way and so on).

IOW, the important piece is what the return value of
dev_pm_skip_resume() should be in particular conditions and that
return value is computed with the help of power.must_resume (and it
might have been computed in a different, possibly less efficient,
way).

> Otherwise it is rather hard to catch the case in which one of the
> device's descendants has MAY_SKIP_RESUME unset (and so the device
> needs to be resumed).
>
> >       dev_pm_skip_resume() doesn't compute the value described
> >       above.  I'm pretty sure the existing code is wrong.
>
> Well, we don't seem to have reached an agreement on some details
> above ...

Sorry for failing to be careful enough ...

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: lockdep warning in urb.c:363 usb_submit_urb
  2020-04-14 13:43                                                           ` Rafael J. Wysocki
@ 2020-04-14 17:47                                                             ` Alan Stern
  2020-04-15 22:20                                                               ` Rafael J. Wysocki
  0 siblings, 1 reply; 50+ messages in thread
From: Alan Stern @ 2020-04-14 17:47 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Qais Yousef, USB list, Linux-pm mailing list, Kernel development list

On Tue, 14 Apr 2020, Rafael J. Wysocki wrote:

> Note to self: avoid replying to technical messages late in the night ...
> 
> On Mon, Apr 13, 2020 at 11:32 PM Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> >
> > On Saturday, April 11, 2020 4:41:14 AM CEST Alan Stern wrote:
> > > Okay, this is my attempt to summarize what we have been discussing.
> > > But first: There is a dev_pm_skip_resume() helper routine which
> > > subsystems can call to see whether resume-side _early and _noirq driver
> > > callbacks should be skipped.  But there is no corresponding
> > > dev_pm_skip_suspend() helper routine.  Let's add one, or rename
> > > dev_pm_smart_suspend_and_suspended() to dev_pm_skip_suspend().
> >
> > OK
> >
> > > Given that, here's my understanding of what should happen.  (I'm
> > > assuming the direct_complete mechanism is not being used.)  This tries
> > > to describe what we _want_ to happen, which is not always the same as
> > > what the current code actually _does_.
> >
> > OK
> >
> > >       During the suspend side, for each of the
> > >       {suspend,freeze,poweroff}_{late,noirq} phases: If
> > >       dev_pm_skip_suspend() returns true then the subsystem should
> > >       not invoke the driver's callback, and if there is no subsystem
> > >       callback then the core will not invoke the driver's callback.
> > >
> > >       During the resume side, for each of the
> > >       {resume,thaw,restore}_{early,noirq} phases: If
> > >       dev_pm_skip_resume() returns true then the subsystem should
> > >       not invoke the driver's callback, and if there is no subsystem
> > >       callback then the core will not invoke the driver's callback.
> > >
> > >       dev_pm_skip_suspend() will return "true" if SMART_SUSPEND is
> > >       set and the device's runtime status is "suspended".
> >
> > Agreed with the above.
> >
> > >       power.must_resume gets set following the suspend-side _noirq
> > >       phase if power.usage_count > 1 (indicating the device was
> > >       in active use before the start of the sleep transition) or
> > >       power.must_resume is set for any of the device's dependents.
> >
> > Or MAY_SKIP_RESUME is unset (which means that the driver does not
> > allow its resume callbacks to be skipped), or power.may_skip_resume
> > is unset (which means that the subsystem does not allow the
> > driver callbacks to be skipped).

Are you certain about that?  It contradicts what you said earlier, that
MAY_SKIP_RESUME doesn't affect THAW transitions.  Also, it would mean 
that a device whose subsystem doesn't know about power.may_skip_resume 
would never be allowed to stay in runtime suspend.

> > >       dev_pm_skip_resume() will return "false" if the current
> > >       transition is RESTORE or power.must_resume is set.  Otherwise:
> > >       It will return true if the current transition is THAW,
> > >       SMART_SUSPEND is set, and the device's runtime status is
> > >       "suspended".
> >
> > The other way around.  That is:
> >
> > dev_pm_skip_resume() will return "true" if the current transition is
> > THAW and dev_pm_skip_suspend() returns "true" for that device (so
> > SMART_SUSPEND is set, and the device's runtime status is "suspended",
> > as per the definition of that function above).
> 
> The above is what I wanted to say ->

So for THAW, dev_pm_skip_resume() can return "true" even if 
power.must_resume is set?  That doesn't seem right.

> > Otherwise, it will return "true" if the current transition is RESTORE
> > (which means that all devices are resumed) or power.must_resume is not
> > set (so this particular device need not be resumed).
> 
> -> but this isn't.  In particular, I messed up the RESTORE part, so it
> should read:
> 
> Otherwise, it will return "true" if the current transition is *not*
> RESTORE (in which case all devices would be resumed) *and*
> power.must_resume is not set (so this particular device need not be
> resumed).
> 
> Sorry about that.

For the RESTORE and THAW cases that is exactly the same as what I 
wrote, apart from the THAW issue noted above.

> > >  It will return "true" if the current transition is
> > >       RESUME, SMART_SUSPEND and MAY_SKIP_RESUME are both set, and
> > >       the device's runtime status is "suspended".
> >
> > Unless MAY_SKIP_RESUME is unset for at least one of its descendants (or
> > dependent devices).
> 
> That should include the power.may_skip_resume flag, so as to read as follows:
> 
> Unless MAY_SKIP_RESUME is unset or power.may_skip_resume is unset for
> at least one of its descendants (or dependent devices).

What about the runtime PM usage counter?

> > >       For a RESUME
> > >       transition, it will also return "true" if MAY_SKIP_RESUME and
> > >       power.may_skip_resume are both set, regardless of
> > >       SMART_SUSPEND or the current runtime status.
> >
> > And if the device was not in active use before suspend (as per its usage
> > counter) or MAY_SKIP_RESUME is unset for at least one of its descendants (or
> > dependent devices in general).
> 
> And analogously here, so what I really should have written is:
> 
> And if the device was not in active use before suspend (as per its
> usage counter) or MAY_SKIP_RESUME or power.may_skip_resume is unset
> for at least one of its descendants (or dependent devices in general).

In other words, for RESUME transitions you want the MAY_SKIP_RESUME and
power.may_skip_resume restrictions to propagate up from dependent
devices.  And of course, the way to do that is by adding them into the
power.must_resume flag.

How do you want to handle the usage counter restriction.  
Should that also propagate upward?

And how should the result of dev_pm_skip_resume() be affected by 
SMART_SUSPEND for RESUME transitions?

Maybe this is getting confusing because of the way I organized it.  
Let's try like this:

Transition   Conditions for dev_pm_skip_resume() to return "true"
----------   ----------------------------------------------------

RESTORE      Never

THAW         power.must_resume is clear (which requires
               MAY_SKIP_RESUME and power.may_skip_resume to be set and 
               the runtime usage counter to be = 1, and which 
               propagates up from dependent devices)
             SMART_SUSPEND is set,
             runtime status is "suspended"

RESUME       Same as THAW?  Or maybe don't require SMART_SUSPEND?
               (But if SMART_SUSPEND is clear, how could the runtime 
               status be "suspended"?)

I can't really tell what you want, because your comments at various 
times have been inconsistent.

Alan Stern

> > >       At the start of the {resume,thaw,restore}_noirq phase, if
> > >       dev_pm_skip_resume() returns true then the core will set the
> > >       runtime status to "suspended".  Otherwise it will set the
> > >       runtime status to "active".  If this is not what the subsystem
> > >       or driver wants, it must update the runtime status itself.
> >
> > Right.
> >
> > > Comments and differences with respect to the code in your pm-sleep-core
> > > branch:
> > >
> > >       I'm not sure whether we should specify other conditions for
> > >       setting power.must_resume.
> >
> > IMO we should.
> 
> In fact, this is part of the implementation and it helps to
> "propagate" the "must resume" condition to the parent and the
> first-order suppliers of the device (which is sufficient, because
> their power.must_resume "propagates" in the same way and so on).
> 
> IOW, the important piece is what the return value of
> dev_pm_skip_resume() should be in particular conditions and that
> return value is computed with the help of power.must_resume (and it
> might have been computed in a different, possibly less efficient,
> way).
> 
> > Otherwise it is rather hard to catch the case in which one of the
> > device's descendants has MAY_SKIP_RESUME unset (and so the device
> > needs to be resumed).
> >
> > >       dev_pm_skip_resume() doesn't compute the value described
> > >       above.  I'm pretty sure the existing code is wrong.
> >
> > Well, we don't seem to have reached an agreement on some details
> > above ...
> 
> Sorry for failing to be careful enough ...



^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: lockdep warning in urb.c:363 usb_submit_urb
  2020-04-14 17:47                                                             ` Alan Stern
@ 2020-04-15 22:20                                                               ` Rafael J. Wysocki
  2020-04-16 15:18                                                                 ` Alan Stern
  0 siblings, 1 reply; 50+ messages in thread
From: Rafael J. Wysocki @ 2020-04-15 22:20 UTC (permalink / raw)
  To: Alan Stern
  Cc: Rafael J. Wysocki, Qais Yousef, USB list, Linux-pm mailing list,
	Kernel development list

On Tuesday, April 14, 2020 7:47:35 PM CEST Alan Stern wrote:
> On Tue, 14 Apr 2020, Rafael J. Wysocki wrote:
> 
> > Note to self: avoid replying to technical messages late in the night ...
> > 
> > On Mon, Apr 13, 2020 at 11:32 PM Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > >
> > > On Saturday, April 11, 2020 4:41:14 AM CEST Alan Stern wrote:
> > > > Okay, this is my attempt to summarize what we have been discussing.
> > > > But first: There is a dev_pm_skip_resume() helper routine which
> > > > subsystems can call to see whether resume-side _early and _noirq driver
> > > > callbacks should be skipped.  But there is no corresponding
> > > > dev_pm_skip_suspend() helper routine.  Let's add one, or rename
> > > > dev_pm_smart_suspend_and_suspended() to dev_pm_skip_suspend().
> > >
> > > OK
> > >
> > > > Given that, here's my understanding of what should happen.  (I'm
> > > > assuming the direct_complete mechanism is not being used.)  This tries
> > > > to describe what we _want_ to happen, which is not always the same as
> > > > what the current code actually _does_.
> > >
> > > OK
> > >
> > > >       During the suspend side, for each of the
> > > >       {suspend,freeze,poweroff}_{late,noirq} phases: If
> > > >       dev_pm_skip_suspend() returns true then the subsystem should
> > > >       not invoke the driver's callback, and if there is no subsystem
> > > >       callback then the core will not invoke the driver's callback.
> > > >
> > > >       During the resume side, for each of the
> > > >       {resume,thaw,restore}_{early,noirq} phases: If
> > > >       dev_pm_skip_resume() returns true then the subsystem should
> > > >       not invoke the driver's callback, and if there is no subsystem
> > > >       callback then the core will not invoke the driver's callback.
> > > >
> > > >       dev_pm_skip_suspend() will return "true" if SMART_SUSPEND is
> > > >       set and the device's runtime status is "suspended".
> > >
> > > Agreed with the above.
> > >
> > > >       power.must_resume gets set following the suspend-side _noirq
> > > >       phase if power.usage_count > 1 (indicating the device was
> > > >       in active use before the start of the sleep transition) or
> > > >       power.must_resume is set for any of the device's dependents.
> > >
> > > Or MAY_SKIP_RESUME is unset (which means that the driver does not
> > > allow its resume callbacks to be skipped), or power.may_skip_resume
> > > is unset (which means that the subsystem does not allow the
> > > driver callbacks to be skipped).
> 
> Are you certain about that?  It contradicts what you said earlier, that
> MAY_SKIP_RESUME doesn't affect THAW transitions.

Yes, MAY_SKIP_RESUME, as well as power.may_skip_resume for that matter, really
should not affect the THAW transition at all.  I overlooked that when I was
writing the above (and earlier).

This means that the dev_pm_skip_resume() logic really is relatively
straightforward:
 - If the current transition is RESTORE, return "false".
 - Otherwise, if the current transition is THAW, return the return value
   of dev_pm_skip_suspend().
 - Otherwise (so the current transition is RESUME which is the only remaining
   case), return the logical negation of power.must_resume.

> Also, it would mean 
> that a device whose subsystem doesn't know about power.may_skip_resume 
> would never be allowed to stay in runtime suspend.

Not really, because I want the core to set power.may_skip_resume for the
devices for which dev_pm_skip_suspend() returns "true" if the "suspend_late"
subsystem-level callback is not present.  [It might be more consistent
to simply set it for all devices for which dev_pm_skip_suspend() returns
"true" and let the subsystems update it should they want to?  IOW, the
default value of power.may_skip_resume could be the return value of
dev_pm_skip_suspend()?]

> > > >       dev_pm_skip_resume() will return "false" if the current
> > > >       transition is RESTORE or power.must_resume is set.  Otherwise:
> > > >       It will return true if the current transition is THAW,
> > > >       SMART_SUSPEND is set, and the device's runtime status is
> > > >       "suspended".
> > >
> > > The other way around.  That is:
> > >
> > > dev_pm_skip_resume() will return "true" if the current transition is
> > > THAW and dev_pm_skip_suspend() returns "true" for that device (so
> > > SMART_SUSPEND is set, and the device's runtime status is "suspended",
> > > as per the definition of that function above).
> > 
> > The above is what I wanted to say ->
> 
> So for THAW, dev_pm_skip_resume() can return "true" even if 
> power.must_resume is set?  That doesn't seem right.

But it cannot be the other way around.

For example, invoking ->thaw_early() from the driver without the corresponding
->freeze_late() would be a bug in general, unless they point to the same
routines as ->runtime_resume() and ->runtime_suspend() (or equivalent),
respectively, but that need not be the case.

> > > Otherwise, it will return "true" if the current transition is RESTORE
> > > (which means that all devices are resumed) or power.must_resume is not
> > > set (so this particular device need not be resumed).
> > 
> > -> but this isn't.  In particular, I messed up the RESTORE part, so it
> > should read:
> > 
> > Otherwise, it will return "true" if the current transition is *not*
> > RESTORE (in which case all devices would be resumed) *and*
> > power.must_resume is not set (so this particular device need not be
> > resumed).
> > 
> > Sorry about that.
> 
> For the RESTORE and THAW cases that is exactly the same as what I 
> wrote, apart from the THAW issue noted above.

OK then.

> > > >  It will return "true" if the current transition is
> > > >       RESUME, SMART_SUSPEND and MAY_SKIP_RESUME are both set, and
> > > >       the device's runtime status is "suspended".
> > >
> > > Unless MAY_SKIP_RESUME is unset for at least one of its descendants (or
> > > dependent devices).
> > 
> > That should include the power.may_skip_resume flag, so as to read as follows:
> > 
> > Unless MAY_SKIP_RESUME is unset or power.may_skip_resume is unset for
> > at least one of its descendants (or dependent devices).
> 
> What about the runtime PM usage counter?

Yes, it applies to that too.

Of course, if dev_pm_skip_suspend() returns "true", the usage counter cannot
be greater than 1 (for the given device as well as for any dependent devices).

> > > >       For a RESUME
> > > >       transition, it will also return "true" if MAY_SKIP_RESUME and
> > > >       power.may_skip_resume are both set, regardless of
> > > >       SMART_SUSPEND or the current runtime status.
> > >
> > > And if the device was not in active use before suspend (as per its usage
> > > counter) or MAY_SKIP_RESUME is unset for at least one of its descendants (or
> > > dependent devices in general).
> > 
> > And analogously here, so what I really should have written is:
> > 
> > And if the device was not in active use before suspend (as per its
> > usage counter) or MAY_SKIP_RESUME or power.may_skip_resume is unset
> > for at least one of its descendants (or dependent devices in general).
> 
> In other words, for RESUME transitions you want the MAY_SKIP_RESUME and
> power.may_skip_resume restrictions to propagate up from dependent
> devices.

Yes, I do.

> And of course, the way to do that is by adding them into the
> power.must_resume flag.

Right.

> How do you want to handle the usage counter restriction.  
> Should that also propagate upward?

Yes, it should.

> And how should the result of dev_pm_skip_resume() be affected by 
> SMART_SUSPEND for RESUME transitions?

Not directly, just through power.must_resume.

> Maybe this is getting confusing because of the way I organized it.  
> Let's try like this:
> 
> Transition   Conditions for dev_pm_skip_resume() to return "true"
> ----------   ----------------------------------------------------
> 
> RESTORE      Never

Right.

> THAW         power.must_resume is clear (which requires
>                MAY_SKIP_RESUME and power.may_skip_resume to be set and 
>                the runtime usage counter to be = 1, and which 
>                propagates up from dependent devices)
>              SMART_SUSPEND is set,
>              runtime status is "suspended"

Like I said above:

 THAW			dev_pm_skip_suspend() returns "true".

> 
> RESUME       Same as THAW?  Or maybe don't require SMART_SUSPEND?
>                (But if SMART_SUSPEND is clear, how could the runtime 
>                status be "suspended"?)

 RESUME		power.must_resume is clear (which requires
				  MAY_SKIP_RESUME and power.may_skip_resume to be set and
				  the runtime usage counter to be = 1, and which 
				  propagates up from dependent devices)

Nothing else is really strictly required IMO.

> 
> I can't really tell what you want, because your comments at various 
> times have been inconsistent.

Sorry for the inconsistencies, I hope that it's more clear now.

Cheers!




^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: lockdep warning in urb.c:363 usb_submit_urb
  2020-04-15 22:20                                                               ` Rafael J. Wysocki
@ 2020-04-16 15:18                                                                 ` Alan Stern
  2020-04-17  9:57                                                                   ` Rafael J. Wysocki
  0 siblings, 1 reply; 50+ messages in thread
From: Alan Stern @ 2020-04-16 15:18 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Rafael J. Wysocki, Qais Yousef, USB list, Linux-pm mailing list,
	Kernel development list

Thanks for all your help straightening this out.  I think the end 
result will be a distinct improvement over the old code.

On Thu, 16 Apr 2020, Rafael J. Wysocki wrote:

> This means that the dev_pm_skip_resume() logic really is relatively
> straightforward:
>  - If the current transition is RESTORE, return "false".
>  - Otherwise, if the current transition is THAW, return the return value
>    of dev_pm_skip_suspend().
>  - Otherwise (so the current transition is RESUME which is the only remaining
>    case), return the logical negation of power.must_resume.
> 
> > Also, it would mean 
> > that a device whose subsystem doesn't know about power.may_skip_resume 
> > would never be allowed to stay in runtime suspend.
> 
> Not really, because I want the core to set power.may_skip_resume for the
> devices for which dev_pm_skip_suspend() returns "true" if the "suspend_late"
> subsystem-level callback is not present.  [It might be more consistent
> to simply set it for all devices for which dev_pm_skip_suspend() returns
> "true" and let the subsystems update it should they want to?  IOW, the
> default value of power.may_skip_resume could be the return value of
> dev_pm_skip_suspend()?]

How about this?  Let's set power.may_skip_resume to "true" for each
device before issuing ->prepare.  The subsystem can set it to "false"
if it wants to during any of the suspend-side callbacks.  Following the
->suspend_noirq callback, the core will do the equivalent of:

	dev->power.may_skip_resume &= dev_pm_skip_suspend(dev);

before propagating the flag.  Any subsystem changes to support this
should be minimal, since only ACPI and PCI currently use
may_skip_resume.

> > What about the runtime PM usage counter?
> 
> Yes, it applies to that too.
> 
> Of course, if dev_pm_skip_suspend() returns "true", the usage counter cannot
> be greater than 1 (for the given device as well as for any dependent devices).

Well, in theory the subsystem could call pm_runtime_get_noresume().  I 
can't imagine why it would want to, though.

So here's what we've got:

> > Transition   Conditions for dev_pm_skip_resume() to return "true"
> > ----------   ----------------------------------------------------
> > 
> > RESTORE      Never
> 
> Right.

>  THAW	         dev_pm_skip_suspend() returns "true".

>  RESUME        power.must_resume is clear (which requires
>                  MAY_SKIP_RESUME and power.may_skip_resume to be set and
>                  the runtime usage counter to be = 1, and which 
>                  propagates up from dependent devices)
> 
> Nothing else is really strictly required IMO.

This seems very clear and simple.  And I will repeat here some of the 
things posted earlier, to make the description more complete:

	During the suspend side, for each of the
	{suspend,freeze,poweroff}_{late,noirq} phases: If
	dev_pm_skip_suspend() returns true then the subsystem should
	not invoke the driver's callback, and if there is no subsystem
	callback then the core will not invoke the driver's callback.

	During the resume side, for each of the
	{resume,thaw,restore}_{early,noirq} phases: If
	dev_pm_skip_resume() returns true then the subsystem should
	not invoke the driver's callback, and if there is no subsystem
	callback then the core will not invoke the driver's callback.

	dev_pm_skip_suspend() will return "true" if SMART_SUSPEND is
	set and the device's runtime status is "suspended".

	For dev_pm_skip_resume() and power.must_resume, see above.

	At the start of the {resume,thaw,restore}_noirq phase, if
	dev_pm_skip_resume() returns true then the core will set the
	runtime status to "suspended".  Otherwise it will set the
	runtime status to "active".  If this is not what the subsystem
	or driver wants, it must update the runtime status itself.

For this to work properly, we will have to rely on subsystems/drivers
to call pm_runtime_resume() during the suspend/freeze transition if
SMART_SUSPEND is clear.  Otherwise we could have the following
scenario:

Device A has a child B, and both are runtime suspended when hibernation
starts.  Suppose that the SMART_SUSPEND flag is set for A but not for
B, and suppose that B's subsystem/driver neglects to call
pm_runtime_resume() during the FREEZE transition.  Then during the THAW
transition, dev_pm_skip_resume() will return "true" for A and "false"  
for B.  This will lead to an error when the core tries to set B's
runtime status to "active" while A's status is "suspended".

One way to avoid this is to have the core make the pm_runtime_resume()  
call, but you have said that you don't like that approach.  Any 
suggestions?

Should the core take some special action following ->freeze_noirq if
the runtime status is "suspended" and SMART_SUSPEND is clear?

Alan Stern


^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: lockdep warning in urb.c:363 usb_submit_urb
  2020-04-16 15:18                                                                 ` Alan Stern
@ 2020-04-17  9:57                                                                   ` Rafael J. Wysocki
  2020-04-17 16:10                                                                     ` Alan Stern
  0 siblings, 1 reply; 50+ messages in thread
From: Rafael J. Wysocki @ 2020-04-17  9:57 UTC (permalink / raw)
  To: Alan Stern
  Cc: Rafael J. Wysocki, Qais Yousef, USB list, Linux-pm mailing list,
	Kernel development list

On Thursday, April 16, 2020 5:18:15 PM CEST Alan Stern wrote:
> Thanks for all your help straightening this out.  I think the end 
> result will be a distinct improvement over the old code.

Yes, I believe so.

> On Thu, 16 Apr 2020, Rafael J. Wysocki wrote:
> 
> > This means that the dev_pm_skip_resume() logic really is relatively
> > straightforward:
> >  - If the current transition is RESTORE, return "false".
> >  - Otherwise, if the current transition is THAW, return the return value
> >    of dev_pm_skip_suspend().
> >  - Otherwise (so the current transition is RESUME which is the only remaining
> >    case), return the logical negation of power.must_resume.
> > 
> > > Also, it would mean 
> > > that a device whose subsystem doesn't know about power.may_skip_resume 
> > > would never be allowed to stay in runtime suspend.
> > 
> > Not really, because I want the core to set power.may_skip_resume for the
> > devices for which dev_pm_skip_suspend() returns "true" if the "suspend_late"
> > subsystem-level callback is not present.  [It might be more consistent
> > to simply set it for all devices for which dev_pm_skip_suspend() returns
> > "true" and let the subsystems update it should they want to?  IOW, the
> > default value of power.may_skip_resume could be the return value of
> > dev_pm_skip_suspend()?]
> 
> How about this?  Let's set power.may_skip_resume to "true" for each
> device before issuing ->prepare.

Yes, it can be set to 'true' by default for all devices.

It doesn't need to be before ->prepare, it can be before ->suspend (as it
is now).

> The subsystem can set it to "false"
> if it wants to during any of the suspend-side callbacks.  Following the
> ->suspend_noirq callback, the core will do the equivalent of:
> 
> 	dev->power.may_skip_resume &= dev_pm_skip_suspend(dev);
> 
> before propagating the flag.  Any subsystem changes to support this
> should be minimal, since only ACPI and PCI currently use
> may_skip_resume.

IMO it can be simpler even.

Because power.may_skip_resume is taken into account along with
MAY_SKIP_RESUME and the driver setting the latter must be prepared
for skipping its resume callbacks regardless of the suspend side of
things, they may always be skipped (and the device may be left in
suspend accordingly) if there is a reason to avoid doing that.

The core doesn't know about those reasons, so it has no reason to
touch power.may_skip_resume after setting it at the outset and then
whoever sees a reason why these callbacks should run (the subsystem
or the driver) needs to clear power.may_skip_resume (and clearing it
more than once obviously makes no difference).

> > > What about the runtime PM usage counter?
> > 
> > Yes, it applies to that too.
> > 
> > Of course, if dev_pm_skip_suspend() returns "true", the usage counter cannot
> > be greater than 1 (for the given device as well as for any dependent devices).
> 
> Well, in theory the subsystem could call pm_runtime_get_noresume().  I 
> can't imagine why it would want to, though.

Indeed.

> So here's what we've got:
> 
> > > Transition   Conditions for dev_pm_skip_resume() to return "true"
> > > ----------   ----------------------------------------------------
> > > 
> > > RESTORE      Never
> > 
> > Right.
> 
> >  THAW	         dev_pm_skip_suspend() returns "true".
> 
> >  RESUME        power.must_resume is clear (which requires
> >                  MAY_SKIP_RESUME and power.may_skip_resume to be set and
> >                  the runtime usage counter to be = 1, and which 
> >                  propagates up from dependent devices)
> > 
> > Nothing else is really strictly required IMO.
> 
> This seems very clear and simple.  And I will repeat here some of the 
> things posted earlier, to make the description more complete:
> 
> 	During the suspend side, for each of the
> 	{suspend,freeze,poweroff}_{late,noirq} phases: If
> 	dev_pm_skip_suspend() returns true then the subsystem should
> 	not invoke the driver's callback, and if there is no subsystem
> 	callback then the core will not invoke the driver's callback.
> 
> 	During the resume side, for each of the
> 	{resume,thaw,restore}_{early,noirq} phases: If
> 	dev_pm_skip_resume() returns true then the subsystem should
> 	not invoke the driver's callback, and if there is no subsystem
> 	callback then the core will not invoke the driver's callback.
> 
> 	dev_pm_skip_suspend() will return "true" if SMART_SUSPEND is
> 	set and the device's runtime status is "suspended".
> 
> 	For dev_pm_skip_resume() and power.must_resume, see above.
> 
> 	At the start of the {resume,thaw,restore}_noirq phase, if
> 	dev_pm_skip_resume() returns true then the core will set the
> 	runtime status to "suspended".  Otherwise it will set the
> 	runtime status to "active".  If this is not what the subsystem
> 	or driver wants, it must update the runtime status itself.
> 
> For this to work properly, we will have to rely on subsystems/drivers
> to call pm_runtime_resume() during the suspend/freeze transition if
> SMART_SUSPEND is clear.

That has been the case forever, though.

> Otherwise we could have the following scenario:
> 
> Device A has a child B, and both are runtime suspended when hibernation
> starts.  Suppose that the SMART_SUSPEND flag is set for A but not for
> B, and suppose that B's subsystem/driver neglects to call
> pm_runtime_resume() during the FREEZE transition.  Then during the THAW
> transition, dev_pm_skip_resume() will return "true" for A and "false"  
> for B.  This will lead to an error when the core tries to set B's
> runtime status to "active" while A's status is "suspended".
> 
> One way to avoid this is to have the core make the pm_runtime_resume()  
> call, but you have said that you don't like that approach.  Any 
> suggestions?

Because the core has not been calling pm_runtime_resume() during system-wide
suspend for devices with SMART_SUSPEND clear, that should not be changed or
we'll see regressions.

I know for a fact that some drivers expect the core to be doing nothing
with respect to that.

> Should the core take some special action following ->freeze_noirq if
> the runtime status is "suspended" and SMART_SUSPEND is clear?

Again, anything like that would change the current behavior which may
not be expected by at least some drivers, so I wouldn't change that.

IOW, SMART_SUSPEND clear means to the core that *it* need not care about
the suspend side at all (because somebody else will do that).




^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: lockdep warning in urb.c:363 usb_submit_urb
  2020-04-17  9:57                                                                   ` Rafael J. Wysocki
@ 2020-04-17 16:10                                                                     ` Alan Stern
  2020-04-17 21:54                                                                       ` Rafael J. Wysocki
  0 siblings, 1 reply; 50+ messages in thread
From: Alan Stern @ 2020-04-17 16:10 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Rafael J. Wysocki, Qais Yousef, USB list, Linux-pm mailing list,
	Kernel development list

On Fri, 17 Apr 2020, Rafael J. Wysocki wrote:

> On Thursday, April 16, 2020 5:18:15 PM CEST Alan Stern wrote:

> > >   IOW, the
> > > default value of power.may_skip_resume could be the return value of
> > > dev_pm_skip_suspend()?]
> > 
> > How about this?  Let's set power.may_skip_resume to "true" for each
> > device before issuing ->prepare.
> 
> Yes, it can be set to 'true' by default for all devices.
> 
> It doesn't need to be before ->prepare, it can be before ->suspend (as it
> is now).

I suggested doing it before ->prepare so that subsystems can clear
power.may_skip_resume in their ->prepare callbacks.  If you think the
ability to do that isn't important then fine, initialize the flag
before ->suspend.

> > The subsystem can set it to "false"
> > if it wants to during any of the suspend-side callbacks.  Following the
> > ->suspend_noirq callback, the core will do the equivalent of:
> > 
> > 	dev->power.may_skip_resume &= dev_pm_skip_suspend(dev);
> > 
> > before propagating the flag.  Any subsystem changes to support this
> > should be minimal, since only ACPI and PCI currently use
> > may_skip_resume.
> 
> IMO it can be simpler even.
> 
> Because power.may_skip_resume is taken into account along with
> MAY_SKIP_RESUME and the driver setting the latter must be prepared
> for skipping its resume callbacks regardless of the suspend side of
> things, they may always be skipped (and the device may be left in
> suspend accordingly) if there is a reason to avoid doing that.
> 
> The core doesn't know about those reasons, so it has no reason to
> touch power.may_skip_resume after setting it at the outset and then
> whoever sees a reason why these callbacks should run (the subsystem
> or the driver) needs to clear power.may_skip_resume (and clearing it
> more than once obviously makes no difference).

I was trying to implement your suggestion of making the default for
power.may_skip_resume be the return value of dev_pm_skip_suspend().  
However, making the default value be "true" is indeed simpler, and I
think it would work okay.

> > So here's what we've got:
> > 
> > > > Transition   Conditions for dev_pm_skip_resume() to return "true"
> > > > ----------   ----------------------------------------------------
> > > > 
> > > > RESTORE      Never
> > > 
> > > Right.
> > 
> > >  THAW	         dev_pm_skip_suspend() returns "true".
> > 
> > >  RESUME        power.must_resume is clear (which requires
> > >                  MAY_SKIP_RESUME and power.may_skip_resume to be set and
> > >                  the runtime usage counter to be = 1, and which 
> > >                  propagates up from dependent devices)
> > > 
> > > Nothing else is really strictly required IMO.
> > 
> > This seems very clear and simple.  And I will repeat here some of the 
> > things posted earlier, to make the description more complete:
> > 
> > 	During the suspend side, for each of the
> > 	{suspend,freeze,poweroff}_{late,noirq} phases: If
> > 	dev_pm_skip_suspend() returns true then the subsystem should
> > 	not invoke the driver's callback, and if there is no subsystem
> > 	callback then the core will not invoke the driver's callback.
> > 
> > 	During the resume side, for each of the
> > 	{resume,thaw,restore}_{early,noirq} phases: If
> > 	dev_pm_skip_resume() returns true then the subsystem should
> > 	not invoke the driver's callback, and if there is no subsystem
> > 	callback then the core will not invoke the driver's callback.
> > 
> > 	dev_pm_skip_suspend() will return "true" if SMART_SUSPEND is
> > 	set and the device's runtime status is "suspended".
> > 
> > 	For dev_pm_skip_resume() and power.must_resume, see above.
> > 
> > 	At the start of the {resume,thaw,restore}_noirq phase, if
> > 	dev_pm_skip_resume() returns true then the core will set the
> > 	runtime status to "suspended".  Otherwise it will set the
> > 	runtime status to "active".  If this is not what the subsystem
> > 	or driver wants, it must update the runtime status itself.
> > 
> > For this to work properly, we will have to rely on subsystems/drivers
> > to call pm_runtime_resume() during the suspend/freeze transition if
> > SMART_SUSPEND is clear.
> 
> That has been the case forever, though.

I'm not so sure about that.  The existing PM core code doesn't ever get
into a situation where it tries to set a device's runtime status to
"active" while the parent's status is "suspended".

> > Otherwise we could have the following scenario:
> > 
> > Device A has a child B, and both are runtime suspended when hibernation
> > starts.  Suppose that the SMART_SUSPEND flag is set for A but not for
> > B, and suppose that B's subsystem/driver neglects to call
> > pm_runtime_resume() during the FREEZE transition.  Then during the THAW
> > transition, dev_pm_skip_resume() will return "true" for A and "false"  
> > for B.  This will lead to an error when the core tries to set B's
> > runtime status to "active" while A's status is "suspended".
> > 
> > One way to avoid this is to have the core make the pm_runtime_resume()  
> > call, but you have said that you don't like that approach.  Any 
> > suggestions?
> 
> Because the core has not been calling pm_runtime_resume() during system-wide
> suspend for devices with SMART_SUSPEND clear, that should not be changed or
> we'll see regressions.
> 
> I know for a fact that some drivers expect the core to be doing nothing
> with respect to that.
> 
> > Should the core take some special action following ->freeze_noirq if
> > the runtime status is "suspended" and SMART_SUSPEND is clear?
> 
> Again, anything like that would change the current behavior which may
> not be expected by at least some drivers, so I wouldn't change that.
> 
> IOW, SMART_SUSPEND clear means to the core that *it* need not care about
> the suspend side at all (because somebody else will do that).

But the core _does_ need to care, because if somebody else fails to
take care of the suspend side then the core would trigger the WARN() in
pm_runtime_enable() for the parent device.  I guess we could consider
such a WARN() to be a symptom of a bug in the driver or subsystem,
rather than in the core; is that how you want to handle the scenario
above?

This approach doesn't seem robust.  I can easily imagine cases where
the parent's driver is aware of SMART_SUSPEND but the child's driver
isn't.  Currently we don't require the child's driver to call 
pm_runtime_resume().  Do you really want to consider all such cases to 
be bugs?

Basically, I'm saying that if the core allows things to arrive at a
situation where we can come out of THAW with a runtime-suspended parent
and a runtime-active child, it really should be considered to be the
core's fault.

Alan Stern


^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: lockdep warning in urb.c:363 usb_submit_urb
  2020-04-17 16:10                                                                     ` Alan Stern
@ 2020-04-17 21:54                                                                       ` Rafael J. Wysocki
  2020-04-17 23:37                                                                         ` Alan Stern
  0 siblings, 1 reply; 50+ messages in thread
From: Rafael J. Wysocki @ 2020-04-17 21:54 UTC (permalink / raw)
  To: Alan Stern
  Cc: Rafael J. Wysocki, Qais Yousef, USB list, Linux-pm mailing list,
	Kernel development list

On Friday, April 17, 2020 6:10:19 PM CEST Alan Stern wrote:
> On Fri, 17 Apr 2020, Rafael J. Wysocki wrote:
> 
> > On Thursday, April 16, 2020 5:18:15 PM CEST Alan Stern wrote:
> 

[cut]

> > > So here's what we've got:
> > > 
> > > > > Transition   Conditions for dev_pm_skip_resume() to return "true"
> > > > > ----------   ----------------------------------------------------
> > > > > 
> > > > > RESTORE      Never
> > > > 
> > > > Right.
> > > 
> > > >  THAW	         dev_pm_skip_suspend() returns "true".
> > > 
> > > >  RESUME        power.must_resume is clear (which requires
> > > >                  MAY_SKIP_RESUME and power.may_skip_resume to be set and
> > > >                  the runtime usage counter to be = 1, and which 
> > > >                  propagates up from dependent devices)
> > > > 
> > > > Nothing else is really strictly required IMO.
> > > 
> > > This seems very clear and simple.  And I will repeat here some of the 
> > > things posted earlier, to make the description more complete:
> > > 
> > > 	During the suspend side, for each of the
> > > 	{suspend,freeze,poweroff}_{late,noirq} phases: If
> > > 	dev_pm_skip_suspend() returns true then the subsystem should
> > > 	not invoke the driver's callback, and if there is no subsystem
> > > 	callback then the core will not invoke the driver's callback.
> > > 
> > > 	During the resume side, for each of the
> > > 	{resume,thaw,restore}_{early,noirq} phases: If
> > > 	dev_pm_skip_resume() returns true then the subsystem should
> > > 	not invoke the driver's callback, and if there is no subsystem
> > > 	callback then the core will not invoke the driver's callback.
> > > 
> > > 	dev_pm_skip_suspend() will return "true" if SMART_SUSPEND is
> > > 	set and the device's runtime status is "suspended".
> > > 
> > > 	For dev_pm_skip_resume() and power.must_resume, see above.
> > > 
> > > 	At the start of the {resume,thaw,restore}_noirq phase, if
> > > 	dev_pm_skip_resume() returns true then the core will set the
> > > 	runtime status to "suspended".  Otherwise it will set the
> > > 	runtime status to "active".  If this is not what the subsystem
> > > 	or driver wants, it must update the runtime status itself.

There is one detail here that I missed, sorry about that.

Actually, the core can only set the runtime status to "active" for
devices where dev_pm_skip_suspend() returns 'true'.

First, if the device is not "suspended", its status is "active" already
anyway.

Second, if the device has SMART_SUSPEND clear, the driver may not expect
its runtime status to change from "suspended" to "active" during system-wide
resume-type transitions (the driver's system-wide PM callbacks may use
the runtime status to determine what to do and changing the status this
way may confuse that).

[Actually, the drivers that set neither SMART_SUSPEND nor MAY_SKIP_RESUME
 may not expect the runtime status to change during system-wide resume-type
 transitions at all, but there is the corner case when the driver can set
 MAY_SKIP_RESUME without setting SMART_SUSPEND.  In that case its "noirq"
 and "early" resume callbacks may be skipped and then it should expect
 the runtime status to sometimes change from "active" to "suspended" during
 RESUME transitions, but it may still not expect to see changes the other way
 around, as in that case all of its callbacks are going to be invoked and
 apply the internal runtime status handling mentioned above.]

So overall:

  At the start of the {resume,thaw,restore}_noirq phase, if
  dev_pm_skip_resume() returns true ,then the core will set the
  runtime status to "suspended".  Otherwise, if dev_pm_skip_suspend()
  also returns true, then the core will set the runtime status to "active".
  If this is not what the subsystem or driver wants, it must update the
  runtime status itself.

> > > For this to work properly, we will have to rely on subsystems/drivers
> > > to call pm_runtime_resume() during the suspend/freeze transition if
> > > SMART_SUSPEND is clear.
> > 
> > That has been the case forever, though.
> 
> I'm not so sure about that.  The existing PM core code doesn't ever get
> into a situation where it tries to set a device's runtime status to
> "active" while the parent's status is "suspended".

I'm assuming that you refer to the scenario below.

> > > Otherwise we could have the following scenario:
> > > 
> > > Device A has a child B, and both are runtime suspended when hibernation
> > > starts.  Suppose that the SMART_SUSPEND flag is set for A but not for
> > > B, and suppose that B's subsystem/driver neglects to call
> > > pm_runtime_resume() during the FREEZE transition.  Then during the THAW
> > > transition, dev_pm_skip_resume() will return "true" for A and "false"  
> > > for B.  This will lead to an error when the core tries to set B's
> > > runtime status to "active" while A's status is "suspended".

That cannot happen, because dev_pm_smart_suspend() also returns 'false' for B
and so its runtime status will not be changed to "active".

> > > One way to avoid this is to have the core make the pm_runtime_resume()  
> > > call, but you have said that you don't like that approach.  Any 
> > > suggestions?
> > 
> > Because the core has not been calling pm_runtime_resume() during system-wide
> > suspend for devices with SMART_SUSPEND clear, that should not be changed or
> > we'll see regressions.
> > 
> > I know for a fact that some drivers expect the core to be doing nothing
> > with respect to that.
> > 
> > > Should the core take some special action following ->freeze_noirq if
> > > the runtime status is "suspended" and SMART_SUSPEND is clear?
> > 
> > Again, anything like that would change the current behavior which may
> > not be expected by at least some drivers, so I wouldn't change that.
> > 
> > IOW, SMART_SUSPEND clear means to the core that *it* need not care about
> > the suspend side at all (because somebody else will do that).
> 
> But the core _does_ need to care, because if somebody else fails to
> take care of the suspend side then the core would trigger the WARN() in
> pm_runtime_enable() for the parent device.  I guess we could consider
> such a WARN() to be a symptom of a bug in the driver or subsystem,
> rather than in the core; is that how you want to handle the scenario
> above?
> 
> This approach doesn't seem robust.  I can easily imagine cases where
> the parent's driver is aware of SMART_SUSPEND but the child's driver
> isn't.  Currently we don't require the child's driver to call 
> pm_runtime_resume().  Do you really want to consider all such cases to 
> be bugs?
> 
> Basically, I'm saying that if the core allows things to arrive at a
> situation where we can come out of THAW with a runtime-suspended parent
> and a runtime-active child, it really should be considered to be the
> core's fault.

AFAICS, this particular one is not an issue.

BTW, I have updated my pm-sleep-core branch to reflect what appears to be
the current state-of-the-art to me.

I'm going to post a v2 of this patch series over the weekend for reference.

Cheers!




^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: lockdep warning in urb.c:363 usb_submit_urb
  2020-04-17 21:54                                                                       ` Rafael J. Wysocki
@ 2020-04-17 23:37                                                                         ` Alan Stern
  2020-04-18  9:40                                                                           ` Rafael J. Wysocki
  0 siblings, 1 reply; 50+ messages in thread
From: Alan Stern @ 2020-04-17 23:37 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Rafael J. Wysocki, Qais Yousef, USB list, Linux-pm mailing list,
	Kernel development list

On Fri, 17 Apr 2020, Rafael J. Wysocki wrote:

> There is one detail here that I missed, sorry about that.
> 
> Actually, the core can only set the runtime status to "active" for
> devices where dev_pm_skip_suspend() returns 'true'.
> 
> First, if the device is not "suspended", its status is "active" already
> anyway.
> 
> Second, if the device has SMART_SUSPEND clear, the driver may not expect
> its runtime status to change from "suspended" to "active" during system-wide
> resume-type transitions (the driver's system-wide PM callbacks may use
> the runtime status to determine what to do and changing the status this
> way may confuse that).
> 
> [Actually, the drivers that set neither SMART_SUSPEND nor MAY_SKIP_RESUME
>  may not expect the runtime status to change during system-wide resume-type
>  transitions at all, but there is the corner case when the driver can set
>  MAY_SKIP_RESUME without setting SMART_SUSPEND.  In that case its "noirq"
>  and "early" resume callbacks may be skipped and then it should expect
>  the runtime status to sometimes change from "active" to "suspended" during
>  RESUME transitions, but it may still not expect to see changes the other way
>  around, as in that case all of its callbacks are going to be invoked and
>  apply the internal runtime status handling mentioned above.]
> 
> So overall:
> 
>   At the start of the {resume,thaw,restore}_noirq phase, if
>   dev_pm_skip_resume() returns true ,then the core will set the
>   runtime status to "suspended".  Otherwise, if dev_pm_skip_suspend()
>   also returns true, then the core will set the runtime status to "active".
>   If this is not what the subsystem or driver wants, it must update the
>   runtime status itself.

Sigh.  The bug which prompted this whole thread was when I forgot to 
set the runtime PM status back to "active" in one of my drivers.  I was 
hoping the core could handle it for me automatically.

I guess the answer is always to set the SMART_SUSPEND flag.


> > > > For this to work properly, we will have to rely on subsystems/drivers
> > > > to call pm_runtime_resume() during the suspend/freeze transition if
> > > > SMART_SUSPEND is clear.
> > > 
> > > That has been the case forever, though.
> > 
> > I'm not so sure about that.  The existing PM core code doesn't ever get
> > into a situation where it tries to set a device's runtime status to
> > "active" while the parent's status is "suspended".
> 
> I'm assuming that you refer to the scenario below.
> 
> > > > Otherwise we could have the following scenario:
> > > > 
> > > > Device A has a child B, and both are runtime suspended when hibernation
> > > > starts.  Suppose that the SMART_SUSPEND flag is set for A but not for
> > > > B, and suppose that B's subsystem/driver neglects to call
> > > > pm_runtime_resume() during the FREEZE transition.  Then during the THAW
> > > > transition, dev_pm_skip_resume() will return "true" for A and "false"  
> > > > for B.  This will lead to an error when the core tries to set B's
> > > > runtime status to "active" while A's status is "suspended".
> 
> That cannot happen, because dev_pm_smart_suspend() also returns 'false' for B
> and so its runtime status will not be changed to "active".

Yes, your change to dev_pm_skip_resume() will prevent the problem from 
arising.


> BTW, I have updated my pm-sleep-core branch to reflect what appears to be
> the current state-of-the-art to me.
> 
> I'm going to post a v2 of this patch series over the weekend for reference.

Okay, I'll check it out.

By the way, if you don't mind I may want to do some editing of 
devices.rst.

Alan Stern



^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: lockdep warning in urb.c:363 usb_submit_urb
  2020-04-17 23:37                                                                         ` Alan Stern
@ 2020-04-18  9:40                                                                           ` Rafael J. Wysocki
  0 siblings, 0 replies; 50+ messages in thread
From: Rafael J. Wysocki @ 2020-04-18  9:40 UTC (permalink / raw)
  To: Alan Stern
  Cc: Rafael J. Wysocki, Rafael J. Wysocki, Qais Yousef, USB list,
	Linux-pm mailing list, Kernel development list

On Sat, Apr 18, 2020 at 1:37 AM Alan Stern <stern@rowland.harvard.edu> wrote:
>
> On Fri, 17 Apr 2020, Rafael J. Wysocki wrote:
>
> > There is one detail here that I missed, sorry about that.
> >
> > Actually, the core can only set the runtime status to "active" for
> > devices where dev_pm_skip_suspend() returns 'true'.
> >
> > First, if the device is not "suspended", its status is "active" already
> > anyway.
> >
> > Second, if the device has SMART_SUSPEND clear, the driver may not expect
> > its runtime status to change from "suspended" to "active" during system-wide
> > resume-type transitions (the driver's system-wide PM callbacks may use
> > the runtime status to determine what to do and changing the status this
> > way may confuse that).
> >
> > [Actually, the drivers that set neither SMART_SUSPEND nor MAY_SKIP_RESUME
> >  may not expect the runtime status to change during system-wide resume-type
> >  transitions at all, but there is the corner case when the driver can set
> >  MAY_SKIP_RESUME without setting SMART_SUSPEND.  In that case its "noirq"
> >  and "early" resume callbacks may be skipped and then it should expect
> >  the runtime status to sometimes change from "active" to "suspended" during
> >  RESUME transitions, but it may still not expect to see changes the other way
> >  around, as in that case all of its callbacks are going to be invoked and
> >  apply the internal runtime status handling mentioned above.]
> >
> > So overall:
> >
> >   At the start of the {resume,thaw,restore}_noirq phase, if
> >   dev_pm_skip_resume() returns true ,then the core will set the
> >   runtime status to "suspended".  Otherwise, if dev_pm_skip_suspend()
> >   also returns true, then the core will set the runtime status to "active".
> >   If this is not what the subsystem or driver wants, it must update the
> >   runtime status itself.
>
> Sigh.  The bug which prompted this whole thread was when I forgot to
> set the runtime PM status back to "active" in one of my drivers.  I was
> hoping the core could handle it for me automatically.
>
> I guess the answer is always to set the SMART_SUSPEND flag.

I would say so. :-)

> > > > > For this to work properly, we will have to rely on subsystems/drivers
> > > > > to call pm_runtime_resume() during the suspend/freeze transition if
> > > > > SMART_SUSPEND is clear.
> > > >
> > > > That has been the case forever, though.
> > >
> > > I'm not so sure about that.  The existing PM core code doesn't ever get
> > > into a situation where it tries to set a device's runtime status to
> > > "active" while the parent's status is "suspended".
> >
> > I'm assuming that you refer to the scenario below.
> >
> > > > > Otherwise we could have the following scenario:
> > > > >
> > > > > Device A has a child B, and both are runtime suspended when hibernation
> > > > > starts.  Suppose that the SMART_SUSPEND flag is set for A but not for
> > > > > B, and suppose that B's subsystem/driver neglects to call
> > > > > pm_runtime_resume() during the FREEZE transition.  Then during the THAW
> > > > > transition, dev_pm_skip_resume() will return "true" for A and "false"
> > > > > for B.  This will lead to an error when the core tries to set B's
> > > > > runtime status to "active" while A's status is "suspended".
> >
> > That cannot happen, because dev_pm_smart_suspend() also returns 'false' for B
> > and so its runtime status will not be changed to "active".
>
> Yes, your change to dev_pm_skip_resume() will prevent the problem from
> arising.
>
>
> > BTW, I have updated my pm-sleep-core branch to reflect what appears to be
> > the current state-of-the-art to me.
> >
> > I'm going to post a v2 of this patch series over the weekend for reference.
>
> Okay, I'll check it out.
>
> By the way, if you don't mind I may want to do some editing of
> devices.rst.

Sure, please feel free to do that.

Cheers!

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: lockdep warning in urb.c:363 usb_submit_urb
  2020-03-25 20:49                         ` Alan Stern
  2020-03-25 21:28                           ` Rafael J. Wysocki
@ 2020-04-20 20:26                           ` Alan Stern
  2020-04-21 11:15                             ` Qais Yousef
  1 sibling, 1 reply; 50+ messages in thread
From: Alan Stern @ 2020-04-20 20:26 UTC (permalink / raw)
  To: Qais Yousef, Rafael J. Wysocki
  Cc: Oliver Neukum, Greg Kroah-Hartman, USB list,
	Linux-pm mailing list, Kernel development list

On Wed, 25 Mar 2020, Alan Stern wrote:

> On Wed, 25 Mar 2020, Qais Yousef wrote:
> 
> > Thanks for all the hints Alan.
> > 
> > I think I figured it out, the below patch seems to fix it for me. Looking
> > at other drivers resume functions it seems we're missing the
> > pm_runtime_disable()->set_active()->enable() dance. Doing that fixes the
> > warning and the dev_err() in driver/base/power.
> 
> Ah, yes.  This should have been added years ago; guess I forgot.  :-(
> 
> > I don't see xhci-plat.c doing that, I wonder if it needs it too.
> > 
> > I'm not well versed about the details and the rules here. So my fix could be
> > a hack, though it does seem the right thing to do.
> > 
> > I wonder why the power core doesn't handle this transparently..
> 
> Initially, we didn't want the PM core to do this automatically because
> we thought some devices might want to remain runtime-suspended
> following a system resume, and only the device driver would know what 
> to do.

Qais:

So it looks like the discussion with Rafael will lead to changes in the
PM core, but they won't go into the -stable kernels, and they won't
directly fix the problem here.

In the meantime, why don't you write up your patch below and submit it
properly?  Even better, create similar patches for ehci-platform.c and
xhci-plat.c and submit them too.

Alan Stern

> > diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
> > index 7addfc2cbadc..eb92c8092fae 100644
> > --- a/drivers/usb/host/ohci-platform.c
> > +++ b/drivers/usb/host/ohci-platform.c
> > @@ -299,6 +299,10 @@ static int ohci_platform_resume(struct device *dev)
> >         }
> > 
> >         ohci_resume(hcd, false);
> > +
> > +       pm_runtime_disable(dev);
> > +       pm_runtime_set_active(dev);
> > +       pm_runtime_enable(dev);
> >         return 0;
> >  }
> >  #endif /* CONFIG_PM_SLEEP */
> > 
> > 
> > Thanks
> > 
> > --
> > Qais Yousef
> 
> 
> 


^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: lockdep warning in urb.c:363 usb_submit_urb
  2020-04-20 20:26                           ` Alan Stern
@ 2020-04-21 11:15                             ` Qais Yousef
  0 siblings, 0 replies; 50+ messages in thread
From: Qais Yousef @ 2020-04-21 11:15 UTC (permalink / raw)
  To: Alan Stern
  Cc: Rafael J. Wysocki, Oliver Neukum, Greg Kroah-Hartman, USB list,
	Linux-pm mailing list, Kernel development list

On 04/20/20 16:26, Alan Stern wrote:
> On Wed, 25 Mar 2020, Alan Stern wrote:
> 
> > On Wed, 25 Mar 2020, Qais Yousef wrote:
> > 
> > > Thanks for all the hints Alan.
> > > 
> > > I think I figured it out, the below patch seems to fix it for me. Looking
> > > at other drivers resume functions it seems we're missing the
> > > pm_runtime_disable()->set_active()->enable() dance. Doing that fixes the
> > > warning and the dev_err() in driver/base/power.
> > 
> > Ah, yes.  This should have been added years ago; guess I forgot.  :-(
> > 
> > > I don't see xhci-plat.c doing that, I wonder if it needs it too.
> > > 
> > > I'm not well versed about the details and the rules here. So my fix could be
> > > a hack, though it does seem the right thing to do.
> > > 
> > > I wonder why the power core doesn't handle this transparently..
> > 
> > Initially, we didn't want the PM core to do this automatically because
> > we thought some devices might want to remain runtime-suspended
> > following a system resume, and only the device driver would know what 
> > to do.
> 
> Qais:
> 
> So it looks like the discussion with Rafael will lead to changes in the
> PM core, but they won't go into the -stable kernels, and they won't
> directly fix the problem here.
> 
> In the meantime, why don't you write up your patch below and submit it
> properly?  Even better, create similar patches for ehci-platform.c and
> xhci-plat.c and submit them too.

Sure.

Thanks

--
Qais Yousef

> 
> Alan Stern
> 
> > > diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
> > > index 7addfc2cbadc..eb92c8092fae 100644
> > > --- a/drivers/usb/host/ohci-platform.c
> > > +++ b/drivers/usb/host/ohci-platform.c
> > > @@ -299,6 +299,10 @@ static int ohci_platform_resume(struct device *dev)
> > >         }
> > > 
> > >         ohci_resume(hcd, false);
> > > +
> > > +       pm_runtime_disable(dev);
> > > +       pm_runtime_set_active(dev);
> > > +       pm_runtime_enable(dev);
> > >         return 0;
> > >  }
> > >  #endif /* CONFIG_PM_SLEEP */
> > > 
> > > 
> > > Thanks
> > > 
> > > --
> > > Qais Yousef
> > 
> > 
> > 
> 

^ permalink raw reply	[flat|nested] 50+ messages in thread

end of thread, other threads:[~2020-04-21 11:15 UTC | newest]

Thread overview: 50+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-23 14:38 lockdep warning in urb.c:363 usb_submit_urb Qais Yousef
2020-03-23 15:36 ` Oliver Neukum
2020-03-23 15:54   ` Alan Stern
2020-03-23 16:02     ` Qais Yousef
2020-03-23 16:18     ` Oliver Neukum
2020-03-23 15:57   ` Qais Yousef
2020-03-23 16:20     ` Oliver Neukum
2020-03-23 17:29   ` Qais Yousef
2020-03-24  9:08     ` Oliver Neukum
2020-03-24 10:46       ` Qais Yousef
2020-03-24 13:20         ` Oliver Neukum
2020-03-24 13:43           ` Qais Yousef
2020-03-24 13:52             ` Alan Stern
2020-03-24 14:06               ` Qais Yousef
2020-03-24 15:56                 ` Alan Stern
2020-03-24 17:22                   ` Qais Yousef
2020-03-24 19:22                     ` Alan Stern
2020-03-25 15:00                       ` Qais Yousef
2020-03-25 20:49                         ` Alan Stern
2020-03-25 21:28                           ` Rafael J. Wysocki
2020-03-26 12:27                             ` Qais Yousef
2020-03-27 20:45                               ` Alan Stern
2020-03-28 14:15                                 ` Rafael J. Wysocki
2020-03-28 19:58                                   ` Alan Stern
2020-03-29  9:16                                     ` Rafael J. Wysocki
2020-03-29 13:56                                       ` Rafael J. Wysocki
2020-03-29 16:27                                       ` Alan Stern
2020-04-03 15:04                                         ` Rafael J. Wysocki
2020-04-03 16:13                                           ` Rafael J. Wysocki
2020-04-03 16:41                                           ` Alan Stern
2020-04-03 18:32                                             ` Rafael J. Wysocki
2020-04-03 20:15                                               ` Alan Stern
2020-04-06 16:45                                                 ` Rafael J. Wysocki
2020-04-06 20:25                                                   ` Alan Stern
2020-04-09 18:45                                                     ` Rafael J. Wysocki
2020-04-11  2:41                                                       ` Alan Stern
2020-04-13 21:32                                                         ` Rafael J. Wysocki
2020-04-14 13:43                                                           ` Rafael J. Wysocki
2020-04-14 17:47                                                             ` Alan Stern
2020-04-15 22:20                                                               ` Rafael J. Wysocki
2020-04-16 15:18                                                                 ` Alan Stern
2020-04-17  9:57                                                                   ` Rafael J. Wysocki
2020-04-17 16:10                                                                     ` Alan Stern
2020-04-17 21:54                                                                       ` Rafael J. Wysocki
2020-04-17 23:37                                                                         ` Alan Stern
2020-04-18  9:40                                                                           ` Rafael J. Wysocki
2020-04-03 17:08                                         ` Rafael J. Wysocki
2020-04-20 20:26                           ` Alan Stern
2020-04-21 11:15                             ` Qais Yousef
2020-03-24 13:47         ` Alan Stern

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).