- User Since
- Jan 24 2015, 12:39 AM (155 w, 4 d)
Tue, Dec 19
This seems to fix dumps from panics caused by in-kernel page faults.
Nov 12 2017
Oct 31 2017
Sep 11 2017
Sep 6 2017
@rgrimes what is the state of this review?
Sep 4 2017
Aug 30 2017
Aug 29 2017
@sbruno I've created an iflib/adaptive_entropy branch with this change. It's dependent on the master-bogofix branch.
Only launch as many threads as we actually need
@sbruno dedicated branch vs iflib/ithread_dispatch called iflib/pollution reduction
avoid gratuitous ithread dispatch
Aug 28 2017
Aug 27 2017
It occurred to me that we can both have our way by enabling the driver to disable entropy collection on packets.
Aug 26 2017
move more blocking work to deferred context
Aug 25 2017
Aug 24 2017
Folded in to D12101
- Eliminate remaining mutex use in os independent e1000 code.
- Fold in iflib updates.
@jtl any comments?
Aug 23 2017
@erj I updated the summary - is there anything more I should add?
Also, can we stop massively refactoring the drivers until after the iflib version goes in to HEAD? And in general, there's a lot of non-productive function shuffling that goes on in Intel drivers that makes it a lot more work for downstream users maintaining their own branches.
In the future when you find yourselves implementing synchronization primitives like swfw_sync or your hand rolled locks in if_bypass.c please make sure you get the attention and sign off from @markj, @jhb, or myself.
Aug 22 2017
update to reflect potential for brokenness
Aug 12 2017
Aug 11 2017
I'm also unsure about the benefit of deferring some of the work to run asynchronously in a different thread. Again, I may be missing something, but it looks to me like the same code runs, but it is deferred. In some cases, this has user-visible side effects. For example, there could be a period of time after an ioctl call has "successfully" completed when the behavior will be different than expected. This might be OK if the behavior was well-documented and there was a good reason for it. But, I'm not sure the change description explains why this is necessary. (Again, I might be missing something.)
I talked to Kevin. I may need to clarify my thinking a bit more.
Aug 10 2017
Jul 7 2017
Jul 5 2017
Thanks for your review.
May 26 2017
@rstone have you committed an equivalent fix already?
May 25 2017
May 24 2017
May 23 2017
I updated my primary e-mail. I didn't see your update. Thanks.
Update for comments
May 1 2017
Jan 5 2017
Jan 2 2017
FYI - this is a backtrace of where X hangs when running the patched driver:
#0 0x000000080250115a in ioctl () from /lib/libc.so.7
#1 0x00000008012763d5 in drmIoctl (fd=7, request=3223348297, arg=0x7fffffffd830) at xf86drm.c:183
#2 0x0000000807a5a1b4 in amdgpu_ioctl_wait_cs (context=0x80409c000, ip=0, ip_instance=0, ring=0, handle=1,
timeout_ns=18446744073709551615, flags=1, busy=0x7fffffffd8d7) at amdgpu_cs.c:403
#3 0x0000000807a5a0bf in amdgpu_cs_query_fence_status (fence=0x804170010, timeout_ns=18446744073709551615, flags=1,
expired=0x7fffffffd944) at amdgpu_cs.c:436
#4 0x0000000808d213bb in amdgpu_fence_wait (fence=0x804170000, timeout=18446744073709551615, absolute=true)
#5 0x0000000808d1ea3a in amdgpu_bo_wait (_buf=0x8041e2880, timeout=18446744073709551615, usage=RADEON_USAGE_WRITE)
#6 0x0000000808d1fa95 in amdgpu_bo_map (buf=0x8041e2880, rcs=0x0, usage=PIPE_TRANSFER_READ) at amdgpu_bo.c:264
#7 0x0000000808d4406d in r600_buffer_map_sync_with_rings (ctx=0x804171000, resource=0x804038b40, usage=1)
#8 0x0000000808d4c3c2 in r600_query_init_backend_mask (ctx=0x804171000) at r600_query.c:1611
#9 0x0000000808c1353c in si_create_context (screen=0x80409b800, priv=0x0, flags=0) at si_pipe.c:253
#10 0x0000000808c13042 in radeonsi_screen_create (ws=0x8040e5600) at si_pipe.c:848
#11 0x0000000808d26c23 in amdgpu_winsys_create (fd=8, screen_create=0x808c12c70 <radeonsi_screen_create>)
#12 0x00000008084671ca in pipe_radeonsi_create_screen (fd=8)
#13 0x0000000808aa04f3 in pipe_loader_drm_create_screen (dev=0x80415f7c0) at pipe_loader_drm.c:347
#14 0x0000000808a9f618 in pipe_loader_create_screen (dev=0x80415f7c0) at pipe_loader.c:79
#15 0x00000008088ccb15 in dri2_init_screen (sPriv=0x8040385a0) at dri2.c:1885
#16 0x00000008088c7c79 in driCreateNewScreen2 (scrn=0, fd=6, extensions=0x80463aaa0 <gbm_dri_screen_extensions>,
driver_extensions=0x8091b8910 <galliumdrm_driver_extensions>, driver_configs=0x804042570, data=0x804042400) at dri_util.c:145
#17 0x0000000804435b0f in dri_screen_create_dri2 (dri=0x804042400, driver_name=0x804029120 "radeonsi")
#18 0x0000000804435480 in dri_screen_create (dri=0x804042400) at backends/dri/gbm_dri.c:523
#19 0x00000008044342b2 in dri_device_create (fd=6) at backends/dri/gbm_dri.c:1069
#20 0x000000080443396e in _gbm_create_device (fd=6) at main/backend.c:100
#21 0x0000000804433baf in gbm_create_device (fd=6) at main/gbm.c:123
#22 0x0000000807840dbe in ?? () from /usr/local/lib/xorg/modules/drivers/amdgpu_drv.so
#23 0x000000000047ce3f in InitOutput ()
#24 0x000000000043a4d4 in ?? ()
#25 0x0000000000424e0f in _start ()
Dec 23 2016
Why are you abandoning this?
Dec 11 2016
Fixed by PQ_LAUNDER
Replaced by populate, which although it still insists on doing a great deal of accounting not needed for device mappings (COW cargo culting AFAICT) that complicates mapping the same device memory at different VAs - it is quite close to what is expected by graphics drivers. Thanks go to Kostik and Alan.
Nov 23 2016
add missed check
Nov 18 2016
Add comment to tcp_timer.c as requested by hiren@
simplify badrxtwin assignment
This is now dependent on D8558
Nov 17 2016
The following 1 line change fixes this issue:
Oct 27 2016
@sbruno what is this gated on now?
With regards to:
The one exception is that - if it is possible to reach a state where min_rtt_ticks is zero but we are *not* in slowstart the ack will be processed whereas before it would have been ignored.
Oct 19 2016
That makes sense, as the device id is the same as a standard X520-DA2 adapter.
@jeffrey.e.pieper_intel.com are all your test systems multi-socket or just this one?
@jeffrey.e.pieper_intel.com The panic you've hit means that the admin task was not assigned a taskqueue. In all likelihood we're hitting an initialization edge case on the system itself, not that particular adapter.
@jeffrey.e.pieper_intel.com and please post dmesg for the system it crashes on.
@jeffrey.e.pieper_intel.com Please run with INVARIANTS. No one else has the offending hardware.
Please try running worth INVARIANTS on the offending hardware.
Is this with the driver in kernel or as a module? And with INVARIANTS or
What svn rev are you using?