Re: Fix for errant semicolon in Mesa library
On Thu, Apr 23, 2015 at 04:55:17PM +1000, Jonathan Gray wrote:
> On Thu, Apr 23, 2015 at 08:42:24AM +0200, Alex Greif wrote:
> > Hi,
> >
> > It seems to be fixed upstream
> > (http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/omx/vid_dec_h264.c)
> >
> > find /usr/xenocara -name '*.c' -exec grep -rE '^[^a-zA-Z0-9]*if \([^)]*\);$'
> > {} \;
> >
> > Alex.
>
> Thanks for looking for these problems. We don't currently build the
> OpenMAX state tracker in Mesa though so I'd be inclined to not add
> another local diff and pick up the fix in a future Mesa update.
I agree.
>
> >
> >
> > Index: vid_dec_h264.c
> > ===
> > RCS file:
> > /cvs/xenocara/dist/Mesa/src/gallium/state_trackers/omx/vid_dec_h264.c,v
> > retrieving revision 1.1.1.3
> > diff -u -p -r1.1.1.3 vid_dec_h264.c
> > --- vid_dec_h264.c 20 Feb 2015 22:46:31 - 1.1.1.3
> > +++ vid_dec_h264.c 23 Apr 2015 06:24:59 -
> > @@ -681,7 +681,7 @@ static void slice_header(vid_dec_Private
> >if (priv->picture.h264.field_pic_flag) {
> > unsigned bottom_field_flag = vl_rbsp_u(rbsp, 1);
> >
> > - if (bottom_field_flag != priv->picture.h264.bottom_field_flag);
> > + if (bottom_field_flag != priv->picture.h264.bottom_field_flag)
> > vid_dec_h264_EndFrame(priv);
> >
> > priv->picture.h264.bottom_field_flag = bottom_field_flag;
> >
>
--
Matthieu Herrb
Re: Change the way we handle interface/connected networks
On 15/04/15(Wed) 23:00, Claudio Jeker wrote:
> On Wed, Mar 18, 2015 at 05:46:34AM +0100, Claudio Jeker wrote:
> > On Tue, Mar 17, 2015 at 05:35:21PM +0100, Martin Pieuchot wrote:
> > > On 12/02/15(Thu) 12:35, Martin Pieuchot wrote:
> > > > On 10/02/15(Tue) 03:04, Claudio Jeker wrote:
> > > > > There is no need to not allow the same network to be configured more
> > > > > then
> > > > > once. Instead just rely on the multipath and priority handling of the
> > > > > routing table to select the right route.
> > > > > Additionally this removes cloned routes (arp/npd cache) when the
> > > > > interface
> > > > > goes down or when the any of the multipath cloning route is changed.
> > > > >
> > > > > With this it is possible to run 2 dhclients on wired and wireless
> > > > > with a
> > > > > bridged network. Active TCP sessions still fail when the cable is
> > > > > unplugged. To fix this more is needed.
> > > > >
> > > > > This changes a fundamental part of the network stack and therefor
> > > > > broad
> > > > > testing is needed to find all the hidden dragons.
> > > >
> > It is broken for IPv6 and I could not find the proper fix yet. I think I
> > now why it goes wrong but the nd6 code is a nightmare.
> >
> > I will send out a new diff once I have IPv6 fixed.
> >
>
> Unsurprisingly IPv6 needs to be special and is not using rt_ifa_add or
> rt_ifa_del in all cases.
Not yet! That would be nice to convert them :)
> There are three special cases that do the same
> dance but use ifa->ifa_addr as the gateway and because of this the
> resulting interface routes are not catched by the nd6 code (RTF_LLINFO is
> missing). When the routes are then cloned nd6 is not invoced and
> everything points back to the host. Oups.
It still think we need to use ifa->ifa_addr as gateway in some cases,
see below.
> The following updated diff seems to fix this but I only minimally tested
> the IPv6 part. People using IPv6 may want to give this a spin.
Same here. I mostly played with dhclient with 3 interfaces and apart
the fact that only interfaces with different priorities will get a
cloning route it works fine. But that can be improve later.
> IMO the net/if_var.h and netinet/ip_carp.c changes could be commited
> before the rest since there should be no noticeable change in how carp
> works.
I agree.
I have some comments inline:
> @@ -1106,16 +1117,20 @@ rt_ifa_add(struct ifaddr *ifa, int flags
> {
> struct rtentry *rt, *nrt = NULL;
> struct sockaddr_rtlabel sa_rl;
> + struct sockaddr_dl sa_dl = { sizeof(sa_dl), AF_LINK };
> struct rt_addrinfo info;
> u_short rtableid = ifa->ifa_ifp->if_rdomain;
> - u_int8_t prio = RTP_CONNECTED;
> + u_int8_t prio = ifa->ifa_ifp->if_priority + RTP_STATIC;
> int error;
>
> + sa_dl.sdl_type = ifa->ifa_ifp->if_type;
> + sa_dl.sdl_index = ifa->ifa_ifp->if_index;
I do not like having more sdl stuff here but I don't see a simpler way
to do that right now since cloning routes need a sockaddr_dl with the
right ifp index but an empty address.
I considered using ifp->if_sadl instead but that means we need to clear
the link-layer address somewhere and this wouldn't help if we change it
after adding a local or cloning route.
IMHO we cannot fix this without improving the RTM_RESOLVE logic. See my
comment below. I think we should be able to call ifa_rtrequest() before
adding the rtentry to the routing table, this would prevent another layer
violation and properly bail if the ARP or ND informations are incorrects.
> memset(&info, 0, sizeof(info));
> info.rti_ifa = ifa;
> - info.rti_flags = flags;
> + info.rti_flags = flags | RTF_MPATH;
> info.rti_info[RTAX_DST] = dst;
> - info.rti_info[RTAX_GATEWAY] = ifa->ifa_addr;
> + info.rti_info[RTAX_GATEWAY] = (struct sockaddr *)&sa_dl;
Here I strongly believe that we should only use a sockaddr_dl as gateway
if we are creating a RTF_CLONING or RTF_LLINFO route.
The first reason is that p2p interfaces generally add a route like:
dstaddr localaddr UH 0 0 - pppoe0
And I'm afraid using a sockaddr_dl might break things.
The second reason is that having sockaddr_dl in the gateway is tied to
the RTM_RESOLVE mechanism related to ifa_rtrequest, which does not apply
to IFF_LOOPBACK or IFF_POINTOPOINT interfaces.
> Index: netinet/if_ether.c
> ===
> RCS file: /cvs/src/sys/netinet/if_ether.c,v
> retrieving revision 1.150
> diff -u -p -r1.150 if_ether.c
> --- netinet/if_ether.c10 Apr 2015 13:58:20 - 1.150
> +++ netinet/if_ether.c12 Apr 2015 11:47:03 -
> @@ -121,8 +121,6 @@ void db_print_llinfo(caddr_t);
> int db_show_radix_node(struct radix_node *, void *, u_int);
> #endif
>
> -static const struct sockaddr_dl null_sd
Re: report thread scheduling setting properly
On Tue, Apr 21, 2015 at 08:03:43PM -0700, Philip Guenther wrote:
>
> While we don't actually make use of thread scheduling attributes, we do
> support setting and retrieving them. However, it doesn't make any sense
> to let you set them in a pthread_attr_t...but then ignore that in
> pthread_create().
>
> Diff below deletes the duplicated sched_{policy,param} members from the
> internal struct pthread and instead use the values from the embedded
> struct pthread_attr. For bonus points, pay attention to the sched_inherit
> attribute and possibly set the values from the parent thread.
>
> Problem noted by natano of bitrig.
>
> ok?
The diff works fine here on amd64 and macppc. It allows the zeromq unit
tests (from github; they draw my attention to that problem) to pass
successfully.
natano
Re: Byte range implementation for httpd(8)
Any interest/comments/suggestions for this diff...
On Fri, Apr 17, 2015 at 05:04:01AM +0200, Sunil Nimmagadda wrote:
> Range requests as defined in RFC7233 is required for resuming
> interrupted http(s) downloads for example:
> ftp -C http://foo.bar/install57.iso
>
> With this diff, httpd parses "Range" header in the requests and
> provide either 206(Partial Content) or 416(Range not Satisfiable)
> responses with "Content-Range" header set appropriately. Further,
> it understands multi range request and generate satisfiable payloads
> with "multipart/byteranges" media type.
>
> Suggestions/comments to improve the diff are welcome.
>
> Note, "If-Range" isn't implemented yet.
>
> Index: server_file.c
> ===
> RCS file: /cvs/src/usr.sbin/httpd/server_file.c,v
> retrieving revision 1.51
> diff -u -p -r1.51 server_file.c
> --- server_file.c 12 Feb 2015 10:05:29 - 1.51
> +++ server_file.c 17 Apr 2015 02:22:12 -
> @@ -36,12 +36,23 @@
>
> #define MINIMUM(a, b)(((a) < (b)) ? (a) : (b))
> #define MAXIMUM(a, b)(((a) > (b)) ? (a) : (b))
> +#define MAX_RANGES 4
> +
> +struct range {
> + off_t start;
> + off_t end;
> +};
>
> int server_file_access(struct httpd *, struct client *, char *, size_t);
> int server_file_request(struct httpd *, struct client *, char *,
> struct stat *);
> +int server_partial_file_request(struct httpd *, struct client *, char *,
> + struct stat *, char *);
> int server_file_index(struct httpd *, struct client *, struct stat *);
> int server_file_method(struct client *);
> +int parse_range_spec(char *, size_t, struct range *);
> +struct range *parse_range(char *, size_t, int *);
> +int buffer_add_range(int, struct evbuffer *, struct range *);
>
> int
> server_file_access(struct httpd *env, struct client *clt,
> @@ -50,6 +61,7 @@ server_file_access(struct httpd *env, st
> struct http_descriptor *desc = clt->clt_descreq;
> struct server_config*srv_conf = clt->clt_srv_conf;
> struct stat st;
> + struct kv *r, key;
> char*newpath;
> int ret;
>
> @@ -123,7 +135,13 @@ server_file_access(struct httpd *env, st
> goto fail;
> }
>
> - return (server_file_request(env, clt, path, &st));
> + key.kv_key = "Range";
> + r = kv_find(&desc->http_headers, &key);
> + if (r != NULL)
> + return (server_partial_file_request(env, clt, path, &st,
> + r->kv_value));
> + else
> + return (server_file_request(env, clt, path, &st));
>
> fail:
> switch (errno) {
> @@ -262,6 +280,138 @@ server_file_request(struct httpd *env, s
> }
>
> int
> +server_partial_file_request(struct httpd *env, struct client *clt, char
> *path,
> +struct stat *st, char *range_str)
> +{
> + struct http_descriptor *resp = clt->clt_descresp;
> + struct media_type *media, multipart_media;
> + struct range*range;
> + struct evbuffer *evb = NULL;
> + size_t content_length;
> + int code = 500, fd = -1, i, nranges, ret;
> + char content_range[64];
> + const char *errstr = NULL;
> + uint32_t boundary;
> +
> + if ((range = parse_range(range_str, st->st_size, &nranges)) == NULL) {
> + code = 416;
> + (void)snprintf(content_range, sizeof(content_range),
> + "bytes */%lld", st->st_size);
> + errstr = content_range;
> + goto abort;
> + }
> +
> + /* Now open the file, should be readable or we have another problem */
> + if ((fd = open(path, O_RDONLY)) == -1)
> + goto abort;
> +
> + media = media_find(env->sc_mediatypes, path);
> + if ((evb = evbuffer_new()) == NULL) {
> + errstr = "failed to allocate file buffer";
> + goto abort;
> + }
> +
> + if (nranges == 1) {
> + (void)snprintf(content_range, sizeof(content_range),
> + "bytes %lld-%lld/%lld", range->start, range->end,
> + st->st_size);
> + if (kv_add(&resp->http_headers, "Content-Range",
> + content_range) == NULL)
> + goto abort;
> +
> + content_length = range->end - range->start + 1;
> + if (buffer_add_range(fd, evb, range) == 0)
> + goto abort;
> +
> + } else {
> + content_length = 0;
> + boundary = arc4random();
> + /* Generate a multipart payload of byteranges */
> + while (nranges--) {
> + if ((i = evbuffer_add_printf(evb, "\r\n--%ud\r\n",
> + boundary)) == -1)
> + goto abort;
> +
> +
r1.21 of sys/net/hfsc.c cripples networking speed
Hello, After updating one of my machines to a more recent snapshot I noticed that networking speed was reduced and that the machine was 'less' responsive. Quick look in systat revealed that softnet was hammering the processor (>90% interrupt on CPU0). After reverting to a backup (older kernel) the issue with softnet claiming the processor was gone. I once more attempted the more recent kernel disabling queuing in pf (wild guess). This resolved my issue with networking speed. After some digging in the CVS log I noticed that revision 1.21 of sys/net/hfsc.c [0] altered code related to pf queueing. A test, using a kernel without the above changeset, results in a machine that is behaving as expected. As I do not understand the changed code I was wondering if there is a reason why the commit has such an impact on the system resulting in a decreased networking speed? [0] http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/net/hfsc.c.diff?r1=1.20&r2=1.21&f=h -- Björn Ketelaars GPG key: 0x4F0E5F21
Re: r1.21 of sys/net/hfsc.c cripples networking speed
> After updating one of my machines to a more recent snapshot I noticed that > networking speed was reduced and that the machine was 'less' responsive. Be aware there is a fairly expensive debugging diff in the snapshots (it is not actually commited).
Re: r1.21 of sys/net/hfsc.c cripples networking speed
> On 24 Apr 2015, at 3:39 pm, Theo de Raadt wrote: > >> After updating one of my machines to a more recent snapshot I noticed that >> networking speed was reduced and that the machine was 'less' responsive. > > Be aware there is a fairly expensive debugging diff in the snapshots > (it is not actually commited). yeah. have you tried the speed of a current kernel you've built yourself? dlg
