search for: portting

On Tue, Sep 03, 2019 at 04:45:54PM -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

I have about 20+ phones on a server, all set for registry expiry 1 min. But only 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

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

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

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

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

On Wed, 2019-09-25 at 15:27 -0400, Sean Paul wrote: > On Tue, Sep 03, 2019 at 04:45:54PM -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

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 sense once we redesign how the current refcounting scheme here works.

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 safe to perform

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 safe to perform

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 while, and I ensure there are no regressions

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 while, and I ensure there are no regressions

The current way of handling refcounting 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

On Thu, Dec 13, 2018 at 08:25:32PM -0500, Lyude Paul wrote: > The current way of handling refcounting 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

Hi, Are you sure? What happens if you manually telnet/socket 10.130.39.180 nsasia at web3:~$ telnet 10.130.39.180 655 Trying 10.130.39.180... Connected to 10.130.39.180. Escape character is '^]'. 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

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 <robert

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

On Tue, Dec 18, 2018 at 04:27:58PM -0500, Lyude Paul wrote: > On Fri, 2018-12-14 at 10:29 +0100, Daniel Vetter wrote: > > On Thu, Dec 13, 2018 at 08:25:32PM -0500, Lyude Paul wrote: > > > The current way of handling refcounting in the DP MST helpers is really > > > confusing and probably just plain wrong because it's been hacked up many > > > times over the

On Fri, 2018-12-14 at 10:29 +0100, Daniel Vetter wrote: > On Thu, Dec 13, 2018 at 08:25:32PM -0500, Lyude Paul wrote: > > The current way of handling refcounting 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

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 any badness. I've marked these patches