search for: repc

On Thu, Oct 31, 2024 at 01:52:37AM -0700, Zhi Wang wrote: > The name "repc" has different meanings in different contexts. > > To improve the readability, it's better to refine it to a name that > reflects what it actually represents. > > Rename "repc" to "gsp_rpc_len" in the GSP message recv path. Add an > section in the do...

...----------------------------------- [2012-03-20 19:29:10.118295] I [monitor(monitor):60:monitor] Monitor: starting gsyncd worker [2012-03-20 19:29:10.168212] I [gsyncd:289:main_i] <top>: syncing: gluster://localhost:myvol -> ssh://root at remoteip:/data/path [2012-03-20 19:29:10.222372] D [repce:130:push] RepceClient: call 23154:47903647023584:1332271750.22 __repce_version__() ... [2012-03-20 19:29:10.504734] E [syncdutils:133:exception] <top>: FAIL: Traceback (most recent call last): File "/opt/glusterfs/3.2.5/local/libexec//glusterfs/python/syncdaemon/syncdutils.py", l...

...e.kernel.org/all/ZxD1BBUUeLQdvXVX at pollux/ [3] https://benchmark.unigine.com/heaven [4] https://github.com/KhronosGroup/VK-GL-CTS [5] https://lore.kernel.org/kvm/20240922124951.1946072-1-zhiw at nvidia.com/T/#t Zhi Wang (15): nvkm: add a kernel doc to introduce the GSP RPC nvkm: rename "repc" to "gsp_rpc_len" on the GSP message recv path nvkm: rename "argv" to what it represnts on the GSP message send path nvkm: remove unused param repc in *rm_alloc_push() nvkm: rename "argv" to what it represents in *rm_{alloc, ctrl}_*() nvkm: rename "ar...

This is a collection of nouveau debug prints, memory leak, a very annoying race condition causing system hangs with prime scenarios, and a fix from Lyude to get the panel on my laptop working. I'd like to get these into 6.7, Dave.

...) switch (rpc_status) { case 0x55: /* NV_ERR_NOT_READY */ case 0x66: /* NV_ERR_TIMEOUT_RETRY */ - return -EAGAIN; + return -EBUSY; case 0x51: /* NV_ERR_NO_MEMORY */ return -ENOMEM; default: @@ -601,7 +601,7 @@ r535_gsp_rpc_rm_alloc_push(struct nvkm_gsp_object *object, void *argv, u32 repc) if (rpc->status) { ret = ERR_PTR(r535_rpc_status_to_errno(rpc->status)); - if (PTR_ERR(ret) != -EAGAIN) + if (PTR_ERR(ret) != -EAGAIN && PTR_ERR(ret) != -EBUSY) nvkm_error(&gsp->subdev, "RM_ALLOC: 0x%x\n", rpc->status); } else { ret = repc ? rpc-...

...dev/gsp/r535.c b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c index f6725a5f5bfb..8b368df2e798 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c @@ -1505,6 +1505,26 @@ r535_gsp_msg_run_cpu_sequencer(void *priv, u32 fn, void *repv, u32 repc) return 0; } +static int +r535_gsp_msg_perf_bridgeless_info_update(void *priv, u32 fn, void *repv, u32 repc) +{ + return 0; +} + +static int +r535_gsp_msg_ucode_libos_print(void *priv, u32 fn, void *repv, u32 repc) +{ + /* work out what we should do here. */ + return 0; +} + +static int +r535_...

.../* NV_ERR_NOT_READY */ + case 0x66: /* NV_ERR_TIMEOUT_RETRY */ + return -EAGAIN; + case 0x51: /* NV_ERR_NO_MEMORY */ + return -ENOMEM; + default: + return -EINVAL; + } +} + static void * r535_gsp_msgq_wait(struct nvkm_gsp *gsp, u32 repc, u32 *prepc, int *ptime) { @@ -584,8 +598,9 @@ r535_gsp_rpc_rm_alloc_push(struct nvkm_gsp_object *object, void *argv, u32 repc) return rpc; if (rpc->status) { - nvkm_error(&gsp->subdev, "RM_ALLOC: 0x%x\n", rpc->status); - ret = ERR_PTR(-EINVAL); + ret = ERR_PTR(r53...

...10635] E [fuse-bridge.c:3484:fuse_xattr_cbk] 0-glusterfs-fuse: extended attribute not supported by the backend storage Then it starts syncing the data but it stops at the exact same point every time I try. In the master, I'm getting the following error messages: [2017-08-16 12:57:45.205311] E [repce(/mnt/storage/lapbacks):207:__call__] RepceClient: call 17769:140586894673664:1502888257.97 (entry_ops) failed on peer with OSError [2017-08-16 12:57:45.205593] E [syncdutils(/mnt/storage/lapbacks):312:log_raise_exception] <top>: FAIL: Traceback (most recent call last): File "/usr/lib/...

...635] E [fuse-bridge.c:3484:fuse_xattr_cbk] 0-glusterfs-fuse: extended attribute not supported by the backend storage Then it starts syncing the data but it stops at the exact same point every time I try. In the master, I'm getting the following error messages: [2017-08-16 12:57:45.205311] E [repce(/mnt/storage/lapbacks):207:__call__] RepceClient: call 17769:140586894673664:1502888257.97 (entry_ops) failed on peer with OSError [2017-08-16 12:57:45.205593] E [syncdutils(/mnt/storage/lapbacks):312:log_raise_exception] <top>: FAIL: Traceback (most recent call last): File "/usr/lib/...

...uster volume geo-replication vmstorage slave:/backup/vmstorage start After that geo-replication status was "starting?" for a while and after that it switched to "N/A". I set log-level to DEBUG and saw lines like these appearing every 10 seconds: [2013-03-20 18:48:19.417107] D [repce:175:push] RepceClient: call 27756:140178941277952:1363798099.42 keep_alive(None,) ... [2013-03-20 18:48:19.418431] D [repce:190:__call__] RepceClient: call 27756:140178941277952:1363798099.42 keep_alive -> 34 [2013-03-20 18:48:29.427959] D [repce:175:push] RepceClient: call 27756:14017894127795...

An HTML attachment was scrubbed... URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20110628/64de4f5c/attachment.html>

...tatus: 2011-05-03 09:57:40.315774] E [syncdutils:131:log_raise_exception] <top>: FAIL: Traceback (most recent call last): File "/usr/lib/glusterfs/glusterfs/python/syncdaemon/syncdutils.py", line 152, in twrap tf(*aa) File "/usr/lib/glusterfs/glusterfs/python/syncdaemon/repce.py", line 118, in listen rid, exc, res = recv(self.inf) File "/usr/lib/glusterfs/glusterfs/python/syncdaemon/repce.py", line 42, in recv return pickle.load(inf) EOFError Command line : gluster volume geo-replication test slave.mydomain.com:/data/test/ start On /etc/glus...

...nce_context_kill(fctx, 0); nvif_event_dtor(&fctx->event); fctx->dead = 1; @@ -145,12 +146,13 @@ nouveau_fence_update(struct nouveau_channel *chan, struct nouveau_fence_chan *fc return drop; } -static int -nouveau_fence_wait_uevent_handler(struct nvif_event *event, void *repv, u32 repc) +static void +nouveau_fence_uevent_work(struct work_struct *work) { - struct nouveau_fence_chan *fctx = container_of(event, typeof(*fctx), event); + struct nouveau_fence_chan *fctx = container_of(work, struct nouveau_fence_chan, + uevent_work); unsigned long flags; - int ret = NVIF_...

...ime time=1520325171 [2018-03-06 08:32:51.926801] E [syncdutils(/gfs/testtomcat/mount):299:log_raise_exception] <top>: master volinfo unavailable [2018-03-06 08:32:51.936203] I [syncdutils(/gfs/testtomcat/mount):271:finalize] <top>: exiting. [2018-03-06 08:32:51.938469] I [repce(/gfs/testtomcat/mount):92:service_loop] RepceServer: terminating on reaching EOF. [2018-03-06 08:32:51.938776] I [syncdutils(/gfs/testtomcat/mount):271:finalize] <top>: exiting. [2018-03-06 08:32:52.743696] I [monitor(monitor):363:monitor] Monitor: worker died in startup phase...

...hanks, Kotresh HR On Fri, Jul 13, 2018 at 1:26 AM, Marcus Peders?n <marcus.pedersen at slu.se<mailto:marcus.pedersen at slu.se>> wrote: Hi Kotresh, i have replaced both files (gsyncdconfig.py<https://review.gluster.org/#/c/20207/1/geo-replication/syncdaemon/gsyncdconfig.py> and repce.py<https://review.gluster.org/#/c/20207/1/geo-replication/syncdaemon/repce.py>) in all nodes both master and slave. I rebooted all servers but geo-replication status is still Stopped. I tried to start geo-replication with response Successful but status still show Stopped on all nodes. Not...

...lication/secret.pem -p 22 -oControlMaster=auto -S /tmp/gsyncd-aux-ssh-fdyDHm/78cf8b204207154de59d7ac32eee737f.sock --compress geo-rep-user at gfs6:/proc/17554/cwd error=12 [2017-09-29 15:53:29.797259] I [syncdutils(/gfs/brick2/gv0):271:finalize] <top>: exiting. [2017-09-29 15:53:29.799386] I [repce(/gfs/brick2/gv0):92:service_loop] RepceServer: terminating on reaching EOF. [2017-09-29 15:53:29.799570] I [syncdutils(/gfs/brick2/gv0):271:finalize] <top>: exiting. [2017-09-29 15:53:30.105407] I [monitor(monitor):280:monitor] Monitor: starting gsyncd worker brick=/gfs/brick1/gv0 slave_node...

...olMaster=auto -S > /tmp/gsyncd-aux-ssh-fdyDHm/78cf8b204207154de59d7ac32eee737f.sock > --compress geo-rep-user at gfs6:/proc/17554/cwderror=12 > [2017-09-29 15:53:29.797259] I > [syncdutils(/gfs/brick2/gv0):271:finalize] <top>: exiting. > [2017-09-29 15:53:29.799386] I > [repce(/gfs/brick2/gv0):92:service_loop] RepceServer: terminating on > reaching EOF. > [2017-09-29 15:53:29.799570] I > [syncdutils(/gfs/brick2/gv0):271:finalize] <top>: exiting. > [2017-09-29 15:53:30.105407] I [monitor(monitor):280:monitor] Monitor: > starting gsyncd > worke...

On Tue, 2023-12-05 at 08:55 +1000, Dave Airlie wrote: > +static int > +r535_gsp_msg_ucode_libos_print(void *priv, u32 fn, void *repv, u32 repc) > +{ > +???????/* work out what we should do here. */ > +???????return 0; > +} This is part of my logrm debugfs patch. ?It contains the printf log from a PMU exception. Do you want me to research the other two RPCs and tell you exactly what they do? But if you're not planning on...

...vkm/subdev/gsp/r535.c b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c index 58502102926b..93a7528a1193 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c @@ -2162,7 +2162,7 @@ r535_gsp_msg_libos_print(void *priv, u32 fn, void *repv, u32 repc) } /** - * create_debufgs - create a blob debugfs entry + * create_debugfs - create a blob debugfs entry * @gsp: gsp pointer * @name: name of this dentry * @blob: blob wrapper -- 2.32.0.3.g01195cf9f