Looks good!
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Feb 27 2020
Mar 7 2019
Dec 11 2018
Oct 25 2018
Looks good!
I think you mean "completion timeout", not "command timeout" - in both the commit message and some of the comments.
Aug 3 2018
This looks good so far. Definitely a big improvement over what was there previously. I'll think about this some more, if there are any other syncs that we're missing.
Sorry - I was looking at a much older version of the nvme(4) driver. You are correct - PRPs are getting synced as part of the queuemem_map.
I'm sure you already know this, but you only need to sync before we ring the doorbell for I/O submission. The device never writes to the PRP list - it only reads it.
In nvme_payload_map, can you also sync the tr->prp_dma_map? Using the same qpair->dma_tag.
I think we have to sync the PRP lists too. Give me a minute and I'll send you some pointers.
Aug 2 2018
Looks good to me. Would be great if @git_bdragon.rtk0.net could retest with this latest patch.
Apr 23 2018
Warner - can you commit this to HEAD?
Mar 15 2018
Changes look fine, but you should probably remove the commented out code.
Feb 23 2018
Hi Ed,
Jan 27 2018
Dec 7 2017
Aug 4 2017
Code all looks good. Just a couple of typos.
Apr 4 2017
Mar 9 2017
Nov 7 2016
Looks good!
Nov 6 2016
Jul 24 2016
In D7295#151938, @jhibbits wrote:In D7295#151926, @imp wrote:I'm pretty sure it won't work with big endian machine. Have you tested this?
Nope, haven't tested it, don't have a NVME card to test with. There have between people expressing a desire to use it on PowerPC. Regardless, it should be usable on any little endian platform, and any bugs for big endian can be squashed as they are tested.
Jul 6 2016
May 13 2016
Looks good. Thanks!
Feb 29 2016
Feb 24 2016
Feb 17 2016
Feb 11 2016
Jan 28 2016
Jan 11 2016
Jan 7 2016
Dec 10 2015
Dec 9 2015
Dec 4 2015
Nov 23 2015
Nov 6 2015
Oct 30 2015
Sep 11 2015
Sep 8 2015
Sep 2 2015
Technically the BWD (stands for Briarwood - an Atom-based SOC) dev IDs should be treated the same as BDX (Broadwell) DE (aka Xeon D). I have no Briarwood hardware to test on though. But should not hurt to just add those device IDs anyways.
I would rather see the full patch here instead of just this workaround to get BDX-DE initialized. Otherwise recovering from channel hangs after initialization will not be possible.
Aug 25 2015
Aug 24 2015
This revision looks good to me.
Aug 22 2015
sys/modules/Makefile needs to be updated too, such that _ioat is only defined when MACHINE_CPUARCH == amd64. I forgot to mention this when I commented on files.amd64 and NOTES.
One more note - sys/conf/files.amd64 and sys/amd64/conf/NOTES should also be updated for ioat, so that it gets integrated into normal kernel builds.