search for: unregistration

On Sat, Nov 09, 2019 at 03:54:17PM +0800, Chuhong Yuan wrote: > drm_put_dev also calls drm_dev_unregister, so dev will be unregistered > twice. > Replace it with drm_dev_put to fix it. > > Signed-off-by: Chuhong Yuan <hslester96 at gmail.com> Nice catch, I'll apply. Since this is so confusing, we actually have a todo to remove drm_put_dev completely from the codebase

Can asterisk log the registration date/time in a database? Is there a standard option to do this? I know it being logged in the asterisks 'full' (debug) log and we are probably able to script something with the API interface but there might be somewhat easier if there is a option to make asterisk log this information directly into a database. Thanks in advance, Bram

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> Fix panic in virtio.c when CONFIG_DEBUG_SLAB is set. Use device_del() and put_device() instead of device_unregister(), and access device data before calling put_device(). Signed-off-by: Sjur Br?ndeland <sjur.brandeland at stericsson.com> cc: Guzman Lugo, Fernadndo <fernando.lugo at ti.com> cc: Michael S. Tsirkin <mst

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> Fix panic in virtio.c when CONFIG_DEBUG_SLAB is set. Use device_del() and put_device() instead of device_unregister(), and access device data before calling put_device(). Signed-off-by: Sjur Br?ndeland <sjur.brandeland at stericsson.com> cc: Guzman Lugo, Fernadndo <fernando.lugo at ti.com> cc: Michael S. Tsirkin <mst

drm_put_dev also calls drm_dev_unregister, so dev will be unregistered twice. Replace it with drm_dev_put to fix it. Signed-off-by: Chuhong Yuan <hslester96 at gmail.com> --- drivers/gpu/drm/virtio/virtgpu_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c b/drivers/gpu/drm/virtio/virtgpu_drv.c index 0fc32fa0b3c0..fccc24e21af8

drm_put_dev also calls drm_dev_unregister, so dev will be unregistered twice. Replace it with drm_dev_put to fix it. Signed-off-by: Chuhong Yuan <hslester96 at gmail.com> --- drivers/gpu/drm/virtio/virtgpu_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c b/drivers/gpu/drm/virtio/virtgpu_drv.c index 0fc32fa0b3c0..fccc24e21af8

Hi, we had an attack on a server and we don't understand how it was possible, Asterisk 1.4.28/Debian Lenny 5.1 Attacker came from PALTEL, network 188.161.128.0/18 Hacked account had following setup: [111] type=friend username=111 context=from-111 host=11.22.33.44 dtmfmode=auto qualify=yes nat=yes canreinvite=no defaultip=11.22.33.44 port=35060 disallow=all allow=ulaw,alaw call-limit=2

...isk restart the old registration is not unregistered and new one is registered with different line value. Then incoming invites and qualify requests are sent to all the registrations and there the problem lies. I am thinking of how could asterisk prevent such situations. 1. I think it should send unregistration requests on shutdown. 2. I think it should keep the database of active registrations and unregister and reregister all of them during startup in case some of them remain active after unclean shutdown. Also probably provider side should be fixed? Thanks for your insight. Marek 2020-06-05 19:29...

Hello, I am trying to force a registration and unregistration with my SIP trunks, but I see pjsip send unregister, but no register. I.e., I am looking for pjsip send register. Is there any such command? If so, why do I not see it in my CLI? Should I upgrade to 13.2.0? Any insight appreciated. -------------- next part -------------- An HTML attachment was...

Rusty, this patch exploits the new function virtio_break_device() as of your patch set dated January 15th on linux-kernel at vger.kernel.org. The patch avoids hang situations during device unregister, when a (block) device with active IO is hot-unplugged. Heinz Graalfs (1): virtio_ccw: introduce device_lost in virtio_ccw_device drivers/s390/kvm/virtio_ccw.c | 49

Rusty, this patch exploits the new function virtio_break_device() as of your patch set dated January 15th on linux-kernel at vger.kernel.org. The patch avoids hang situations during device unregister, when a (block) device with active IO is hot-unplugged. Heinz Graalfs (1): virtio_ccw: introduce device_lost in virtio_ccw_device drivers/s390/kvm/virtio_ccw.c | 49

...it is registered. Drivers expect, for example, that none of their methods will be called after driver_unregister() returns. It doesn''t matter if some other thread still holds a reference to the driver structure; that reference mustn''t be used for accessing the driver code after unregistration. get_driver() does not do any checking for this. People may have been misled by the kerneldoc into thinking that the references obtained by get_driver() do somehow pin the driver structure in memory. This simply isn''t true; all it pins is the associated private structure. Code that ne...

...F_DGRAM 0x00000004 Documentation comments, please. > +void vsock_core_unregister(const struct vsock_transport *t) > +{ > + mutex_lock(&vsock_register_mutex); > + > + /* RFC-TODO: maybe we should check if there are open sockets > + * assigned to that transport and avoid the unregistration > + */ If unregister() is only called from module_exit() functions then holding a reference to the transport module would be enough to prevent this case. The transport could only be removed once all sockets have been destroyed (and dropped their transport module reference). -------------- nex...

On Fri, 2018-08-17 at 16:11 +0200, Hans Verkuil wrote: > From: Hans Verkuil <hans.verkuil at cisco.com> > > If aux->transfer == NULL, then just return without doing > anything. In that case the function is likely called for > a non-(e)DP connector. > > This never happened for the i915 driver, but the nouveau and amdgpu > drivers need this check. Could you give a

Hello, after migration from chan_sip to res_pjsip I get strange behavior when receiving call from the outside world. When call is received, it is replicated multiple times. Two of that calls get to the phone. So the phone is ringing on both lines. When having only Dial function in dialplan I am able to place call. But when creating some dialplan procedures containing VoiceMail I get phone ringing

Hi everyone, I'm having an odd problem with one of my sipura boxes. The box registers the first time with asterisk properly after being plugged in. After which, some of the subsequent registration tries fail and the box becomes unregistered. However, after a few hours, it finally successfully re-registers and the cycle continues. I have not been able to figure out the problem but

Hi All, Currently i'm facing with a cdr issue, When i originate a call (outbound call) to uncorrect/unregistration user, asterisk inform me that call was failed but in mysl-cdr (cdr-csv also) records. Here are 2 samples +---------------------+------+-----+-----+----------+---------------------+------------+----------+-------------+-----------+ | calldate | clid | src | dst | dcontext | channel...

...otification handler with CIO_GONE: In that event, flag device_lost as true. In case the device had been flagged as lost when the remove/offline callbacks are called, call the new virtio_break_device() function prior to invoking device_unregister(). This avoids hangs of I/O triggered via the device unregistration callbacks. Signed-off-by: Heinz Graalfs <graalfs at linux.vnet.ibm.com> Reviewed-by: Cornelia Huck <cornelia.huck at de.ibm.com> --- drivers/s390/kvm/virtio_ccw.c | 49 ++++++++++++++++++++++++++++++++----------- 1 file changed, 37 insertions(+), 12 deletions(-) diff --git a/drivers/...

Hello, I installed 1.6.2.17 version of asterisk. Set the user database to realtime. I have no problems with sip users. They can register talk etc.. With iax clients, they can register also.. And when they call iax to sip, it works. When they make an echo test..no voice received on iax clients. When they make call from sip to iax ..no sound received on iax clients. I didnt see any clue on debug.

...ec_* function, it is better to just test for aux->transfer in the drm_dp_cec_* functions themselves. It's more robust. So there isn't a bug or anything like that, it's just so that these drm_dp_cec functions can handle a slightly different driver design safely. The registration and unregistration of the cec devices is always DP specific, and an attempt to register a cec device for a non-DP connector will now fail with a WARN_ON. Regards, Hans > >> >> The alternative would be to add this check in those drivers before >> every drm_dp_cec call, but it makes sense to c...