Bug 224064
| Summary: | [nvme][hang][resume] nvme_ctrlr_wait_for_ready called with desired_val = 0 but cc.en =1 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | Dave Cottlehuber <dch> | ||||||
| Component: | kern | Assignee: | freebsd-scsi (Nobody) <scsi> | ||||||
| Status: | Closed FIXED | ||||||||
| Severity: | Affects Only Me | CC: | cem, chuck, gonzo, imp | ||||||
| Priority: | --- | ||||||||
| Version: | CURRENT | ||||||||
| Hardware: | amd64 | ||||||||
| OS: | Any | ||||||||
| Attachments: |
|
||||||||
|
Description
Dave Cottlehuber
2017-12-03 22:03:27 UTC
Created attachment 188502 [details]
dmesg
# uname FreeBSD akai.skunkwerks.at 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r325987+5aee85eae833(master): Sun Nov 19 04:34:13 UTC 2017 root@wintermute:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 While most like not a fix, it would be worth testing the change proposed in D13389 [1]. The message you are seeing will definitely go away, but it isn't clear if the change would either a) let the driver proceed with the reset and life is good or b) fall down somewhere else. [1] https://reviews.freebsd.org/D13389 If you do, you'll have to add this device to the quirk list... I suspect some other issue is going on since the device is likely transitioning from power state D3 to D0. I haven't checked, but sometimes that takes a while and it's quite possible there's an other spot in the driver that needs either a fixed delay (yuck) or to poll something to become active before proceeding. thanks Chuck & Warner for the info. I'll build with the patch later this week & report back. wrt adding a quirk, I'm not familiar with this. I see nothing in /sys/dev/nv* regarding these, so I assume they are specified in sys/cam/. I'll read up README.quirks and my FreeBSD Design & Implementation book, but if you have any pointers or similar commits that would be a big help. I've found: - https://reviews.freebsd.org/D13093 - https://forums.freebsd.org/threads/55210/ to start with. actually it looks like https://reviews.freebsd.org/D13389#inline-80238 is all I need - sorry for the noise It would be interesting to see what, if any, failure occurs without adding a specific quirk for your device. So if you have the time and inclination, I'd vote for experiment #1 to be the D13389 patch without changes and experiment #2 to be the D13389 patch plus an entry in pci_ids for your device with .quirks set to QUIRK_DELAY_B4_CHK_RDY. experiment#1 underway.. early days but I've not had a repeat hang with this patch (yay). I'll close this later in the week if I don't have a recurrence. thanks! LGTM, no issues reported at all, no quirk hacks needed. My perception is that resume time is super fast now as well. |