search for: payload

...ions(-) > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c > index 9b1b5c9b1fa0..2ab16c9e6243 100644 > --- a/drivers/gpu/drm/drm_dp_mst_topology.c > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c > @@ -1879,39 +1879,48 @@ int drm_dp_update_payload_part1(struct drm_dp_mst_topology_mgr *mgr) > > mutex_lock(&mgr->payload_lock); > for (i = 0; i < mgr->max_payloads; i++) { > + struct drm_dp_vcpi *vcpi = mgr->proposed_vcpis[i]; > + struct drm_dp_payload *payload = &mgr->payloads[i]; > + > /* s...

...ed, 42 insertions(+), 29 deletions(-) diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c index 9b1b5c9b1fa0..2ab16c9e6243 100644 --- a/drivers/gpu/drm/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/drm_dp_mst_topology.c @@ -1879,39 +1879,48 @@ int drm_dp_update_payload_part1(struct drm_dp_mst_topology_mgr *mgr) mutex_lock(&mgr->payload_lock); for (i = 0; i < mgr->max_payloads; i++) { + struct drm_dp_vcpi *vcpi = mgr->proposed_vcpis[i]; + struct drm_dp_payload *payload = &mgr->payloads[i]; + /* solve the current payloads - compare...

After applying the patches in my previous message... I'm getting the following when building dovecot for CentOS 6 (but not for CentOS 7): lmtp payload - normal: parallel pipelining ssl ....................... : ok CLIENT: Panic: file smtp-client-connection.c: line 1309 (smtp_client_connection_established): assertion failed: (!conn->connect_succeeded) CLIENT: Error: Raw backtrace: /builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-tes...

On 6/9/23 04:17, Eric Blake wrote: > In order to more easily add a third reply type with an even larger > header, but where the payload will look the same for both structured > and extended replies, it is nicer if simple and structured replies are > nested inside the same layer of sbuf.reply.hdr. Doing this also lets > us add an alias for accessing the cookie directly without picking > which header type we have on hand...

Currently, nouveau tries to go through the drm_dp_mst_port structures itself in order to retrieve the relevant payload and VCPI information that it needs to report to the GPU. This is wrong: mstc->port could be destroyed at any point, and additionally the payload could be changed at any point because it doesn't bother trying to grab the payload lock. So; remove nv50_msto_payload entirely and use the new drm_...

Hi, I was womdering, if anyone has experienced the same issues. When I run the tests after compiling 2.3.5, the following 4 tests fail: http payload echo (ssl): sequential .................................. : ok http payload echo (ssl): pipeline .................................... : ok http payload echo (ssl): parallel .................................... : FAILED: Test is hanging http payload echo (ssl) ..........................................

On Fri, Nov 16, 2018 at 07:21:15PM -0500, Lyude Paul wrote: > Some hardware (nvidia hardware in particular) needs to be notified of > the exact VCPI and payload settings that the topology manager decided on > for each mstb port. Since there isn't currently any way to get this > information without going through port (which drivers are very much not > supposed to do by themselves, ever), let's add one. > > Signed-off-by: Lyude Paul &...

FYI, the Opus RTP payload format is now RFC7587: https://tools.ietf.org/html/rfc7587 Cheers, Jean-Marc -------- Forwarded Message -------- Subject: [payload] RFC 7587 on RTP Payload Format for the Opus Speech and Audio Codec Date: Tue, 30 Jun 2015 16:33:17 -0700 (PDT) From: rfc-editor at rfc-editor.org To: ietf-announc...

On 02/05/2019 06:52, Peter via dovecot wrote: > After applying the patches in my previous message... > > I'm getting the following when building dovecot for CentOS 6 (but not > for CentOS 7): > > > lmtp payload - normal: parallel pipelining ssl ....................... > : ok > CLIENT: Panic: file smtp-client-connection.c: line 1309 > (smtp_client_connection_established): assertion failed: > (!conn->connect_succeeded) > CLIENT: Error: Raw backtrace: > /builddir/build/BUILD/dovecot-...

This was v3 patch 2/22, reworked to address the confusion about how a structured reply header is read in two pieces before getting to the payload portion. I'm still working on rebasing the rest of my v3 series (patches 1, 3-22) from other comments given, but this seemed independent enough that it's worth posting now rather than holding it up for the rest of the series. Eric Blake (4): states: Document our reliance on type overlap...

...libnbd, nbd_handle is an opaque type always referenced as a pointer). Eric Blake (7): states: Log structured error messages, if any states: Refactor SET_META_CONTEXT reply parsing states: Allow large SET_CONTEXT_NAME replies states: Rewrite NBD_REP_INFO parsing states: Factor out NBD_REP payload prep states: Give up on oversized reply length states: Capture NBD_REP_ERR message generator/generator | 19 ++-- generator/states-newstyle-opt-go.c | 71 ++++++------- .../states-newstyle-opt-set-meta-context.c | 99 +++++++------------ generator/state...

So we don't ever have to worry about drivers touching drm_dp_mst_port structs without verifying them and crashing again. Lyude Paul (6): drm/dp_mst: Add drm_dp_get_payload_info() drm/nouveau: Use drm_dp_get_payload_info() for getting payload/vcpi drm/nouveau: Stop reading port->mgr in nv50_mstc_get_modes() drm/nouveau: Stop reading port->mgr in nv50_mstc_detect() drm/dp_mst: Hide drm_dp_mst_port contents from drivers drm/i915: Start using struct drm_d...

Hi everyone, The WebAssembly backend recently had Bug 39448 <https://bugs.llvm.org/show_bug.cgi?id=39448> filed against it because NaN payloads in floating-point immediates are not preserved through compilation on 32-bit builds. I took a look and the corruption takes place when the immediates are converted from APFloats to be stored as native doubles in MCOperand. I assume this bug only appears in 32-bit builds because they are using x87...

...Sec tunnel drops out. I do notice a lot of these errors in the secure log though, would this be any indication of a problem? (I'm grepping for this specific error, they're not the only messages in there). Feb 11 14:18:10 site-a pluto[10450]: "site-b/1x1" #803: ignoring Delete SA payload: PROTO_IPSEC_ESP SA(0x01f90e1d) not found (maybe expired) Feb 11 14:18:14 site-a pluto[10450]: "site-b/1x1" #803: ignoring Delete SA payload: PROTO_IPSEC_ESP SA(0xb3681486) not found (maybe expired) Feb 11 14:18:14 site-a pluto[10450]: "site-b/1x1" #803: ignoring Delete SA paylo...

Instead of repeating a check for valid reply headers in each sub-state machine, let's have a common helper function do all the work. Additionally, a central location will make it easier to uniformly capture any NBD_REP_ERR message payloads. --- generator/generator | 8 +-- generator/states-newstyle-opt-go.c | 40 +++---------- .../states-newstyle-opt-set-meta-context.c | 39 ++----------- generator/states-newstyle-opt-starttls.c | 31 ++-------- .../states-newstyle-opt-structured-reply....

...SSL::disable } else { set secure 1 } set realm "mydomain.com" set debug 0 set loggedin 0 } when SERVER_CONNECTED { TCP::collect } when CLIENTSSL_HANDSHAKE { SSL::collect set secure 1 } when CLIENTSSL_DATA { if { $debug } { log local0. "CLIENT DATA: [SSL::payload]" } set lcpayload [string tolower [SSL::payload]] if { $lcpayload starts_with "user" } { scan [SSL::payload] {%s%s} command user set pos [string first $user [SSL::payload] 0] SSL::payload replace $pos [string length $user] "$user@$realm" if { $debug }...

On 7/05/19 11:08 AM, Stephan Bosch wrote: >> CLIENT: Error: Raw backtrace: >> /builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload() >> [0x4547ea] -> >> /builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload() >> [0x454891] -> >> /builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload(_start+0) >> [0x4193f8] -> >> /builddir/build/BUILD/...

Hi, (moving back to the list as some bits can be useful to everyone) > I am sure that 75 is the length of payload only. Confirmed > I also don't have idea for the package containing data of a length 46. > > To make everything more clear, Payload type in rtp packages is 97. > SDP defines the stream as > a=rtpmap: 97 SPEEX/8000 That's a dynamic payload number, so it doesn't really...

https://bugzilla.netfilter.org/show_bug.cgi?id=915 Summary: segfault in error case : expr_evaluate_payload not checking payload->payload.desc being null Product: nftables Version: unspecified Platform: x86_64 OS/Version: All Status: NEW Severity: normal Priority: P5 Component: nft AssignedTo:...

Well. Centos 5 is really near of it's end of life. There is not much updates to kernel or openswan. You should at least try latest openswan version. Your issue looks like a bit network problem. -- Eero 2016-02-10 8:34 GMT+02:00 John Cenile <jcenile1983 at gmail.com>: > So lowering the keylife / ikelifetime didn't solve the problem. I've > enabled debugging and I'll