>That check was added recently with 7b2db29fbb4e7, which also explains
how it
>can happen. Question here is if the problem with intel-3165-wifi was seen
>on a kernel which doesn't have that patch.
@Guenter Roeck,
Thanks for your reminding,I didn't see your patch.
I just do test with kernel-4.10,I will fetch this patch.
Thank you very much.
dmesg output:
dmesg output:<1>[ 64.576756] BUG: unable to handle kernel NULL pointer
dereference at 0000000000000008
<1>[ 64.576768] IP: [<ffffffff813ac34c>] hub_port_init+0x8db/0x95a
<4>[ 64.576770] PGD 0
<4>[ 64.576775] Oops: 0000 [#1] PREEMPT SMP
<4>[ 64.576826] Modules linked in: binfmt_misc aesni_intel rtsx_pci_ms
rtsx_pci_sdmmc memstick
mac_hid aes_x86_64 sparse_keymap uvcvideo videobuf2_vmalloc videobuf2_memops
videobuf2_v4l2
videobuf2_core btusb btrtl psmouse pcspkr efivars iwlmvm mac80211 r8169 mii
rtsx_pci iwlwifi
cfg80211 snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic nouveau
mxm_wmi hwmon ttm
i2c_i801 snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer
snd soundcore
shpchp i915 drm_kms_helper drm fb_sys_fops syscopyarea sysfillrect sysimgblt
i2c_algo_bit i2c_hid
dell_smo8800 wmi pinctrl_sunrisepoint pinctrl_intel intel_lpss_acpi intel_lpss
hci_uart btbcm
btqca btintel bluetooth atkbd
<4>[ 64.576832] CPU: 0 PID: 3380 Comm: kworker/u8:38 Not tainted
4.4.10-android-x86_64 #6
<4>[ 64.576833] Hardware name: THTF THTF T Series/NTSN1413, BIOS N.1.22
07/05/2016
<4>[ 64.576841] Workqueue: events_unbound async_run_entry_fn
<4>[ 64.576844] task: ffff8800912da440 ti: ffff8800913f4000 task.ti:
ffff8800913f4000
<4>[ 64.576851] RIP: 0010:[<ffffffff813ac34c>] [<ffffffff813ac34c>]
hub_port_init+0x8db/0x95a
<4>[ 64.576854] RSP: 0018:ffff8800913f7c20 EFLAGS: 00010286
<4>[ 64.576856] RAX: 0000000000000000 RBX: ffff88024af76800 RCX:
000000000000000c
<4>[ 64.576858] RDX: 0000000000000000 RSI: 0000000000000001 RDI:
ffff8800a7771800
<4>[ 64.576871] RBP: ffff8800a7771800 R08: 000000000000000c R09:
0000000000000001
<4>[ 64.576872] R10: 0000000000000000 R11: 0000000000000000 R12:
0000000000000002
<4>[ 64.576874] R13: ffff880252ba9800 R14: 0000000000000012 R15:
0000000000000001
<4>[ 64.576887] FS: 0000000000000000(0000) GS:ffff880253c00000(0000)
knlGS:0000000000000000
<4>[ 64.576890] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4>[ 64.576892] CR2: 0000000000000008 CR3: 0000000001a0b000 CR4:
00000000001406f0
<4>[ 64.576893] Stack:
<4>[ 64.576901] ffff88022f103200 0000000000000040 ffffffff00001388
0000000200000001
<4>[ 64.576905] ffff8800a760c000 0000000200000032 ffff88024af76890
0000000200000000
<4>[ 64.576909] 0000000200000000 ffff88024af76800 0000000000000000
ffff88024af76b58
<4>[ 64.576910] Call Trace:
<4>[ 64.576920] [<ffffffff813ac501>] ?
usb_reset_and_verify_device+0x136/0x618
<4>[ 64.576925] [<ffffffff813aa5b8>] ? hub_port_status+0xee/0xff
<4>[ 64.576931] [<ffffffff813ae757>] ? usb_port_resume+0x478/0x5af
<4>[ 64.576936] [<ffffffff813a9836>] ? usb_dev_thaw+0xb/0xb
<4>[ 64.576941] [<ffffffff813b73ba>] ? usb_resume_both+0x87/0xf4
<4>[ 64.576945] [<ffffffff813b79af>] ? usb_resume+0x11/0x53
<4>[ 64.576949] [<ffffffff813a9840>] ? usb_dev_resume+0xa/0xb
<4>[ 64.576957] [<ffffffff81350327>] ? dpm_run_callback+0x82/0x140
<4>[ 64.576960] [<ffffffff813508a1>] ? device_resume+0x176/0x1b6
<4>[ 64.576963] [<ffffffff813508f5>] ? async_resume+0x14/0x38
<4>[ 64.576967] [<ffffffff8107914f>] ? async_run_entry_fn+0x66/0x128
<4>[ 64.576972] [<ffffffff810731e6>] ? process_one_work+0x1e8/0x37d
<4>[ 64.576976] [<ffffffff81073aec>] ? worker_thread+0x26d/0x35c
<4>[ 64.576980] [<ffffffff8107387f>] ? cancel_delayed_work_sync+0xa/0xa
<4>[ 64.576985] [<ffffffff810776d3>] ? kthread+0xc1/0xc9
<4>[ 64.576991] [<ffffffff81077612>] ? kthread_create_on_node+0x16b/0x16b
<4>[ 64.576998] [<ffffffff815cc46f>] ? ret_from_fork+0x3f/0x70
<4>[ 64.577003] [<ffffffff81077612>] ? kthread_create_on_node+0x16b/0x16b
<4>[ 64.577045] Code: 00 00 48 85 c0 74 1b 0f b6 93 92 04 00 00 48 8b 80 38 02
00 00 48 8b 44 d0 f8 8b 80 e8 02 00 00 eb 02 31 c0 48 8b 93 70 03 00 00 <48> 8b
52 08
f6 42 03 04 75 05 83 f8 02 75 4e 80 8b 95 04 00 00
<1>[ 64.577050] RIP [<ffffffff813ac34c>] hub_port_init+0x8db/0x95a
<4>[ 64.577052] RSP <ffff8800913f7c20>
<4>[ 64.577053] CR2: 0000000000000008
<4>[ 64.602169] ---[ end trace f7bf72111ed03d11 ]---
<0>[ 64.604667] Kernel panic - not syncing: Fatal exception
<0>[ 64.604716] Kernel Offset: disabled
On 2017年05月02日 21:51, Guenter Roeck wrote:
On 05/02/2017 06:19 AM, Greg KH wrote:
On Tue, May 02, 2017 at 02:31:40PM +0800, wangjianxing5...@163.com
wrote:
From: "Jianxing.Wang" <wangjianxing5...@163.com>
When notebook with intel-3165-wifi suspend and resume,crash for
udev->bos is NULL.
I'm sorry, I don't understand, how can udev->bos be NULL here? Why does
the wifi device matter to the USB device?
Signed-off-by: Jianxing.Wang <wangjianxing5...@163.com>
---
drivers/usb/core/hub.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 5286bf6..3b5493a 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -4281,10 +4281,12 @@ static void
hub_set_initial_usb2_lpm_policy(struct usb_device *udev)
if (hub)
connect_type = hub->ports[udev->portnum - 1]->connect_type;
- if ((udev->bos->ext_cap->bmAttributes &
cpu_to_le32(USB_BESL_SUPPORT)) ||
- connect_type == USB_PORT_CONNECT_TYPE_HARD_WIRED) {
- udev->usb2_hw_lpm_allowed = 1;
- usb_set_usb2_hardware_lpm(udev, 1);
+ if (udev->bos != NULL) {
This is already checked a few lines above this, how can it have changed
already?
That check was added recently with 7b2db29fbb4e7, which also explains
how it
can happen. Question here is if the problem with intel-3165-wifi was seen
on a kernel which doesn't have that patch.
This is a good example why it is useful to provide a crash log as well as
some context information.
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
