search for: port

...PM -0400, Lyude Paul wrote: > Since we're going to be implementing suspend/resume reprobing very soon, > we need to make sure we are extra careful to ensure that our locking > actually protects the topology state where we expect it to. Turns out > this isn't the case with drm_dp_port_setup_pdt() and > drm_dp_port_teardown_pdt(), both of which change port->mstb without > grabbing &mgr->lock. > > Additionally, since most callers of these functions are just using it to > teardown the port's previous PDT and setup a new one we can simplify > things...

...nly this one, with 2 accounts, keeps re-registerting itself. All the time this is what I see on asterisk CLI and it is kind of annoying. What only this phone does this and no other. Its on a remote location. All phones are Grandstream GXP-2000. -- Registered SIP '502' at 64.101.221.250 port 18639 expires 60 -- Registered SIP '7052823582' at 64.101.221.250 port 18641 expires 60 -- Registered SIP '502' at 64.101.221.250 port 18643 expires 60 -- Registered SIP '502' at 64.101.221.250 port 18647 expires 60 -- Registered SIP '7052823582' at 6...

Hai, If you use that or the AD, then its incomplete, imo. Your missing ldaps (636) and the GC (ssl) 3268/3269) ports and maybe NTP (123/tcp) if installed. Maybe you dont need them, just an observation. Greetz, Louis > -----Oorspronkelijk bericht----- > Van: samba [mailto:samba-bounces at lists.samba.org] Namens Jeff > Sadowski via samba > Verzonden: dinsdag 13 februari 2018 16:05 > Aan: M...

Since we're going to be implementing suspend/resume reprobing very soon, we need to make sure we are extra careful to ensure that our locking actually protects the topology state where we expect it to. Turns out this isn't the case with drm_dp_port_setup_pdt() and drm_dp_port_teardown_pdt(), both of which change port->mstb without grabbing &mgr->lock. Additionally, since most callers of these functions are just using it to teardown the port's previous PDT and setup a new one we can simplify things a bit and combine drm_dp_port_...

Since we're going to be implementing suspend/resume reprobing very soon, we need to make sure we are extra careful to ensure that our locking actually protects the topology state where we expect it to. Turns out this isn't the case with drm_dp_port_setup_pdt() and drm_dp_port_teardown_pdt(), both of which change port->mstb without grabbing &mgr->lock. Additionally, since most callers of these functions are just using it to teardown the port's previous PDT and setup a new one we can simplify things a bit and combine drm_dp_port_...

On Tue, Sep 03, 2019 at 04:45:58PM -0400, Lyude Paul wrote: > Yes-you read that right. Currently there is literally no locking in > place for any of the drm_dp_mst_port struct members that can be modified > in response to a link address response, or a connection status response. > Which literally means if we're unlucky enough to have any sort of > hotplugging event happen before we're finished with reprobing link > addresses, we'll race and...

...wrote: > > Since we're going to be implementing suspend/resume reprobing very soon, > > we need to make sure we are extra careful to ensure that our locking > > actually protects the topology state where we expect it to. Turns out > > this isn't the case with drm_dp_port_setup_pdt() and > > drm_dp_port_teardown_pdt(), both of which change port->mstb without > > grabbing &mgr->lock. > > > > Additionally, since most callers of these functions are just using it to > > teardown the port's previous PDT and setup a new one we...

s/drm_dp_get_validated_port_ref/drm_dp_mst_topology_get_port_validated/ s/drm_dp_put_port/drm_dp_mst_topology_put_port/ s/drm_dp_get_validated_mstb_ref/drm_dp_mst_topology_get_mstb_validated/ s/drm_dp_put_mst_branch_device/drm_dp_mst_topology_put_mstb/ This is a much more consistent naming scheme, and will make even more sen...

Hey Rusty, These are the patches that rework a few bits to make hot-unplug while ports are open not crash apps (or kernels). The problem is when hot-unplug is performed when a port is open, the cdev struct is kept around by the file pointers and when the app later does a 'close', things go boom-boom. This patch series makes sure port as well as device hot-unplug is now saf...

Hey Rusty, These are the patches that rework a few bits to make hot-unplug while ports are open not crash apps (or kernels). The problem is when hot-unplug is performed when a port is open, the cdev struct is kept around by the file pointers and when the app later does a 'close', things go boom-boom. This patch series makes sure port as well as device hot-unplug is now saf...

Hello, This series fixes a few bugs and races with port unplug and the various file operations: read(), write() and close(). I started coding up an alternative locking mechanism based on the discussion earlier in this series, but some of what we already have has to remain, and the new code is sufficiently different, so I'd rather it bakes for a whi...

Hello, This series fixes a few bugs and races with port unplug and the various file operations: read(), write() and close(). I started coding up an alternative locking mechanism based on the discussion earlier in this series, but some of what we already have has to remain, and the new code is sufficiently different, so I'd rather it bakes for a whi...

...ng in the DP MST helpers is really confusing and probably just plain wrong because it's been hacked up many times over the years without anyone actually going over the code and seeing if things could be simplified. To the best of my understanding, the current scheme works like this: drm_dp_mst_port and drm_dp_mst_branch both have a single refcount. When this refcount hits 0 for either of the two, they're removed from the topology state, but not immediately freed. Both ports and branch devices will reinitialize their kref once it's hit 0 before actually destroying themselves. The inten...

...ally > confusing and probably just plain wrong because it's been hacked up many > times over the years without anyone actually going over the code and > seeing if things could be simplified. > > To the best of my understanding, the current scheme works like this: > drm_dp_mst_port and drm_dp_mst_branch both have a single refcount. When > this refcount hits 0 for either of the two, they're removed from the > topology state, but not immediately freed. Both ports and branch devices > will reinitialize their kref once it's hit 0 before actually destroying > t...

...'^]'. 0 db1 17 Connection closed by foreign host. Stopping the service and running debug I get: nsasia at web3:~$ sudo tincd -n gainplus -d5 -D tincd 1.0.33 starting, debug level 5 /dev/net/tun is a Linux tun/tap device (tun mode) Executing script tinc-up Listening on 10.130.69.123 port 655 Ready Trying to connect to db1 (10.130.39.180 port 655) Connected to db1 (10.130.39.180 port 655) Sending ID to db1 (10.130.39.180 port 655): 0 web3 17 Sending 10 bytes of metadata to db1 (10.130.39.180 port 655) Flushing 10 bytes to db1 (10.130.39.180 port 655) Got ID from db1 (10.130.39.180 p...

Yes, I am sure but added another broader rule: nsasia at db1:~$ sudo ufw allow from any port 655 proto udp same result for debug example. regards Robert >>> Rafael Wolf <rfwolf at gmail.com> 13-Jun-18 5:32 PM >>> Telnet will only do tcp not udp which tinc works on. Are you sure udp 655 is open? On Wed, Jun 13, 2018, 3:51 AM Robert Horgan &lt...

Yes-you read that right. Currently there is literally no locking in place for any of the drm_dp_mst_port struct members that can be modified in response to a link address response, or a connection status response. Which literally means if we're unlucky enough to have any sort of hotplugging event happen before we're finished with reprobing link addresses, we'll race and the contents of sai...

...because it's been hacked up many > > > times over the years without anyone actually going over the code and > > > seeing if things could be simplified. > > > > > > To the best of my understanding, the current scheme works like this: > > > drm_dp_mst_port and drm_dp_mst_branch both have a single refcount. When > > > this refcount hits 0 for either of the two, they're removed from the > > > topology state, but not immediately freed. Both ports and branch devices > > > will reinitialize their kref once it's hit 0 bef...

...robably just plain wrong because it's been hacked up many > > times over the years without anyone actually going over the code and > > seeing if things could be simplified. > > > > To the best of my understanding, the current scheme works like this: > > drm_dp_mst_port and drm_dp_mst_branch both have a single refcount. When > > this refcount hits 0 for either of the two, they're removed from the > > topology state, but not immediately freed. Both ports and branch devices > > will reinitialize their kref once it's hit 0 before actually de...

Hello, This series fixes a few bugs and races with port unplug and the various file operations: read(), write(), close() and poll(). There still might be more races lurking, but testing this series looks good to at least solve the easily-triggerable ones. I've run the virtio-serial testsuite and a few open/close/unplug tests, and haven't seen...