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