On Tue, 3 Feb 2015, Athlion wrote:
> On Mon, Feb 2, 2015 at 7:27 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
>
> > Had you made any changes to the runtime suspend settings?
> > blk_post_runtime_resume wouldn't be called unless the drive had gone
> > into runtime suspend. And even then, it's not likely to be called
> > after you unplug the USB cable.
> >
> > Alan Stern
>
> I have enabled SCSI ATA Bus power management with this udev rule:
> ACTION=="add", SUBSYSTEM=="scsi_host", KERNEL=="host*",
> ATTR{link_power_management_policy}="min_power"
That won't have any effect on SCSI over USB, as far as I know.
> ( And generally almost all of actions herein:
> https://wiki.archlinux.org/index.php/Power_saving#Laptop_Mode )
>
> Here's another with dynamic debugging on (and some of the stack trace):
>
> [ 1565.610481] usb usb2: usb wakeup-resume
> [ 1565.613019] usb usb2: usb auto-resume
> [ 1565.615599] hub 2-0:1.0: hub_resume
> [ 1565.617876] usb usb2-port1: status 0507 change 0000
> [ 1565.620125] hub 2-0:1.0: state 7 ports 3 chg 0000 evt 0000
> [ 1565.623471] hub 2-0:1.0: state 7 ports 3 chg 0000 evt 0000
> [ 1565.650219] hub 2-0:1.0: state 7 ports 3 chg 0000 evt 0002
> [ 1565.663520] usb 2-1: usb wakeup-resume
> [ 1565.665518] usb 2-1: finish resume
> [ 1565.667684] hub 2-1:1.0: hub_resume
> [ 1565.669812] usb 2-1-port2: status 0101 change 0001
> [ 1565.773645] usb usb2-port1: resume, status 0
> [ 1565.776031] hub 2-1:1.0: state 7 ports 8 chg 0004 evt 0000
> [ 1565.778664] usb 2-1-port2: status 0101, change 0000, 12 Mb/s
> [ 1565.847291] usb 2-1.2: new high-speed USB device number 3 using ehci-pci
> [ 1565.860480] usb 2-1-port2: not reset yet, waiting 10ms
> [ 1565.945202] usb 2-1.2: default language 0x0409
> [ 1565.947882] usb 2-1.2: udev 3, busnum 2, minor = 130
> [ 1565.950384] usb 2-1.2: usb_probe_device
> [ 1565.952704] usb 2-1.2: configuration #1 chosen from 1 choice
> [ 1565.955145] usb 2-1.2: adding 2-1.2:1.0 (config #1, interface 0)
> [ 1565.957630] hub 2-1:1.0: state 7 ports 8 chg 0000 evt 0004
> [ 1566.005124] usb-storage 2-1.2:1.0: usb_probe_interface
> [ 1566.006655] usb-storage 2-1.2:1.0: usb_probe_interface - got id
> [ 1566.008169] usb-storage 2-1.2:1.0: USB Mass Storage device detected
> [ 1566.010155] scsi host6: usb-storage 2-1.2:1.0
> [ 1566.012149] usbcore: registered new interface driver usb-storage
> [ 1566.016061] usbcore: registered new interface driver uas
> [ 1567.015852] scsi 6:0:0:0: Direct-Access WD My Passport
> 0748 1016 PQ: 0 ANSI: 6
> [ 1567.018966] scsi 6:0:0:1: Enclosure WD SES Device
> 1016 PQ: 0 ANSI: 6
Your device contains two Logical Units. One of them is the My Passport
disk drive, and the other is the SES Device enclosure.
> [ 1567.027072] scsi 6:0:0:1: scsi_runtime_idle
> [ 1567.029695] sd 6:0:0:0: [sdb] Spinning up disk...
> [ 1567.032764] scsi 6:0:0:1: scsi_runtime_suspend
> [ 1568.031907] .ready
> [ 1569.060225] sd 6:0:0:0: [sdb] 1953458176 512-byte logical blocks:
> (1.00 TB/931 GiB)
> [ 1569.063857] sd 6:0:0:0: [sdb] Write Protect is off
> [ 1569.065613] ses 6:0:0:1: Attached Enclosure device
> [ 1569.068492] sd 6:0:0:0: [sdb] Mode Sense: 47 00 10 08
> [ 1569.071598] sd 6:0:0:0: [sdb] No Caching mode page found
> [ 1569.073628] sd 6:0:0:0: [sdb] Assuming drive cache: write through
> [ 1569.087891] sdb: sdb1
> [ 1569.093382] sd 6:0:0:0: [sdb] Attached SCSI disk
> [ 1615.830142] hub 2-1:1.0: state 7 ports 8 chg 0000 evt 0004
> [ 1615.833066] usb 2-1-port2: status 0100, change 0001, 12 Mb/s
> [ 1615.835764] usb 2-1.2: USB disconnect, device number 3
> [ 1615.838471] usb 2-1.2: unregistering device
> [ 1615.841199] usb 2-1.2: unregistering interface 2-1.2:1.0
> [ 1615.844996] scsi target6:0:0: scsi_runtime_idle
> [ 1615.848746] scsi target6:0:0: scsi_runtime_suspend
> [ 1615.868925] scsi target6:0:0: scsi_runtime_resume
> [ 1615.870975] ses 6:0:0:1: scsi_runtime_resume
> [ 1615.872913] BUG: unable to handle kernel NULL pointer dereference
> at 00000000000001a0
> [ 1615.874896] IP: [<ffffffff812850d5>] blk_post_runtime_resume+0x65/0x80
> [ 1615.876843] PGD 0
> [ 1615.878765] Oops: 0002 [#1] PREEMPT SMP
> [ 1615.880734] Modules linked in: ses enclosure uas usb_storage
> netconsole joydev mousedev snd_hda_codec_hdmi snd_hda_codec_conexant
> snd_hda_codec_generic coretemp intel_rapl x86_pkg_temp_thermal
> intel_powerclamp kvm_intel kvm arc4 crct10dif_pclmul iwldvm
> crc32_pclmul iTCO_wdt iTCO_vendor_support crc32c_intel mac80211
> ghash_clmulni_intel ip6t_REJECT nf_reject_ipv6 aesni_intel xt_hl
> aes_x86_64 lrw gf128mul ip6t_rt psmouse iwlwifi glue_helper
> ablk_helper cryptd i2c_i801 serio_raw cfg80211 nf_conntrack_ipv6
> nf_defrag_ipv6 snd_hda_intel wmi thinkpad_acpi nvram thermal rfkill
> ipt_REJECT nf_reject_ipv4 hwmon tpm_tis ac tpm battery
> snd_hda_controller snd_hda_codec snd_hwdep evdev snd_pcm mac_hid
> xt_limit e1000e snd_timer xt_tcpudp mei_me snd mei ptp soundcore
> shpchp pps_core lpc_ich processor xt_addrtype nf_conntrack_ipv4
> nf_defrag_ipv4 xt_conntrack at ffffffffffffffd8
> [ 1616.064883] IP: [<ffffffff81091500>] kthread_data+0x10/0x20
Once again, there is no stack trace. In fact, if you look at the
second-to-last line above, it appears that another oops occurred about
0.2 seconds after the first one, and part of the kernel log got lost:
> nf_defrag_ipv4 xt_conntrack at ffffffffffffffd8
-----------------------------^
Right there, the "at ffffffffffffffd8" part appears to be the end of
another BUG: line. Everything in between is missing -- presumably
including the stack trace. Maybe the stack got messed up, so that
tracing it caused the second oops to occur.
Anyway, this shows that the problem was associated with the SES Device,
not the My Passport disk. It occurred during the runtime resume of the
SES, as indicated by the reference to blk_post_runtime_resume. (Note
that the ses driver doesn't support runtime power management in any
case.)
Clearly this problem has nothing to do with USB; it is a SCSI matter.
Somehow the ses driver interacts badly with runtime PM.
James, do you have any idea what might be going wrong here? The
blk_post_runtime_resume routine in block/blk-core.c does very little
other than call __blk_run_queue. I don't know how the ses driver
works, but it looks like it hardly uses its request queue at all.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
