Re: Core Systems in products.html
On Thu, Jul 09, 2015 at 11:51:23PM -0400, Michael McConville wrote: > Core Systems' website has been down for a while, and it seems that > they no may longer exist. Can anyone confirm or deny? Also, MIPS-Informatics seems to be serving World Cup updates these days. Index: products.html === RCS file: /cvs/www/products.html,v retrieving revision 1.97 diff -u -p -r1.97 products.html --- products.html 2 Jul 2015 05:49:04 - 1.97 +++ products.html 10 Jul 2015 04:04:15 - @@ -105,16 +105,6 @@ href="http://www.opensound.com/openbsd.h for OpenBSD/i386 3.x -Core Systems -http://www.core.dk";>Core Systems sells http://www.core.dk/products/insite/index_en.html";>InSite, an -easy to use, server-side web statistics utility, for OpenBSD/i386. -InSite is similar to products such as WebTrends, but can also be -configured through a web interface to generate reports on the fly, using -very little CPU time. (Upon request, Core may be able to provide InSite -for platforms other then i386.) - - Software2Go Motif (i386 and SPARC only) http://www.apps2go.com";>Software2Go, LLC has Motif 2.1.20 Development and Runtime toolkits for OpenBSD. @@ -152,13 +142,6 @@ Ordering, 817-431-8775 (phone/fax) http://www.interact.se";>Interact Lulea, Sweden. - -Spain - -http://www.mips-informatics.com";>MIPS-Informatics -Sabadell, Spain. - -
Core Systems in products.html
Core Systems' website has been down for a while, and it seems that they no may longer exist. Can anyone confirm or deny? Index: products.html === RCS file: /cvs/www/products.html,v retrieving revision 1.97 diff -u -p -r1.97 products.html --- products.html 2 Jul 2015 05:49:04 - 1.97 +++ products.html 10 Jul 2015 03:47:29 - @@ -105,16 +105,6 @@ href="http://www.opensound.com/openbsd.h for OpenBSD/i386 3.x -Core Systems -http://www.core.dk";>Core Systems sells http://www.core.dk/products/insite/index_en.html";>InSite, an -easy to use, server-side web statistics utility, for OpenBSD/i386. -InSite is similar to products such as WebTrends, but can also be -configured through a web interface to generate reports on the fly, using -very little CPU time. (Upon request, Core may be able to provide InSite -for platforms other then i386.) - - Software2Go Motif (i386 and SPARC only) http://www.apps2go.com";>Software2Go, LLC has Motif 2.1.20 Development and Runtime toolkits for OpenBSD.
Re: Microsoft Now OpenBSD Foundation Gold Contributor
> Kenneth R Westerback, 08 Jul 2015 10:13: > > The OpenBSD Foundation is happy to announce that Microsoft has made > > a significant financial donation to the Foundation. This donation > > is in recognition of the role of the Foundation in supporting the > > OpenSSH project. This donation makes Microsoft the first Gold level > > contributor in the OpenBSD Foundation's 2015 fundraising campaign. > > this is very impressive news, although for me for all > the wrong reasons. > > sad world when even ms realises openssh's importance, > (even while not supporting it out of box natively) > while the other big "open source" players are just > feeding off of it. speechless. Frantisek, With respect, and at the same none at all due to what you say; I know very little about you except what I see historically. This mailing list contains hundreds of people. You have been around for a long time. You know the general agenda which is 20+ years old. Yet here you broadcast just your own, acting like it has any acceptance at all; furthermore you seem to expect validation of your own agenda without consideration of the fact that it is not at all like our general agenda; in fact, you do not put any limiters to indicate so. Therefore: You are welcome to provide the same revenue, and I will personally argue that the OpenBSD Foundation should return what Microsoft gave them; my understanding being that it was without any strings. So pony up all the cash, to match the efforts by hundreds over two decades, and I will gladly validate your opinions as having some value greater than negative to the greater community. Luckily, saying that to you is just a prank. My historical analysis indicates you are just a tiny/tinny loudmouth, who "accidentally" hurts the people who have spent over two decades building good software. You have some hateful agenda entirely unlike our own (by own, I consider the rough consensus of 500+ openbsd developers over two decades). Your comments are entirely disassociated with the general project guidelines of writing software which anyone can use, to advance the state of the art, without restriction. To keep it simple: Where are you coming from, Mr. Do-Nothing? As a group (with me and others as the proxy) we do ask for companies to help fund us from time to time, and this benefits everyone as a result of the common advancements. As for output, there is no discrimination as to their cause, because that is not our oversight/job. The general guidelines for access to software is CLEAR in the licence. Yet you clearly state that we should have some restrictive agenda, Mr. Do-Nothing-Except-State-Position. In essence, you are a loudmouth and a leech. I've been working on this community for two decades. It is my right to call you out for your destructive words. Few are in the position where they can say your words cause harm. Few have as much insight. You have zero insight. You only harbour a general hate and want to change our direction. You have no skin in the game. When the BBQ gets lit up, you are the just a sparrow flitting away down the alley in search of a place to hide. I'm looking at your record of postings in various forums. You add ZERO value. You have spent almost a decade demanding we do more, more, MORE, DO FUCKING FOR ME MORE DEVELOPERS, yet I've never seen your name show up elsewhere of consequence to actually solve the costs behind advancing the state of the art of free options. Yet you feel qualified to tell us this pattern is wrong. Unfortunately, it is a sad world filled with Holops who have done VERY LITTLE, and then deride funding opportunities, very late in the game; for what many of have simply done sans funding for decades. The problem here is simple. Holop has an specific agenda that is not generally held! For everyone following allong, please find the original IPF removal commit message for guidance. The standard is to advance the industry. In general, we don't care about people who whine and try to apply their agenda towards us, but in your case I must make an exception. I think it is high time people like you FIND A MIRROR. You are the specific cause of the situation you so deride. Frantisek, you have absolutely no right to speak like you do. You are a pure-form leech, and leeches should not preach. Please leave our userbase instantly; I am afraid someone in this community might accidentally make a mistake of fixing a bug you care about (and you made it clear you care about nothing else except your own leechy agenda). Frantisek, it would be easier if you just went away. I hate writing these mails, editing them, and creating a disaster. Perhaps you should stop pissing off people who try hard by stabbing yourself with a knife, repeatedly. I don't know if that would work. Maybe you will return as a zombie and say the same things again.
Re: Microsoft Now OpenBSD Foundation Gold Contributor
> On Jul 9, 2015, at 17:06, frantisek holop wrote: > > Kenneth R Westerback, 08 Jul 2015 10:13: >> The OpenBSD Foundation is happy to announce that Microsoft has made >> a significant financial donation to the Foundation. This donation >> is in recognition of the role of the Foundation in supporting the >> OpenSSH project. This donation makes Microsoft the first Gold level >> contributor in the OpenBSD Foundation's 2015 fundraising campaign. > > this is very impressive news, although for me for all > the wrong reasons. > > sad world when even ms realises openssh's importance, > (even while not supporting it out of box natively) This is in connection with them integrating it into powershell. The Windows people I work with are very excited about this. It dramatically improves their toolset for administration. Which just serves to make your point, yes. While other vendors have given none as much. > while the other big "open source" players are just > feeding off of it. speechless. > > -f > -- > the current death rate? one per person, of course. >
Re: Microsoft Now OpenBSD Foundation Gold Contributor
Kenneth R Westerback, 08 Jul 2015 10:13: > The OpenBSD Foundation is happy to announce that Microsoft has made > a significant financial donation to the Foundation. This donation > is in recognition of the role of the Foundation in supporting the > OpenSSH project. This donation makes Microsoft the first Gold level > contributor in the OpenBSD Foundation's 2015 fundraising campaign. this is very impressive news, although for me for all the wrong reasons. sad world when even ms realises openssh's importance, (even while not supporting it out of box natively) while the other big "open source" players are just feeding off of it. speechless. -f -- the current death rate? one per person, of course.
Re: increase athn firmware load timeout
On Thu, Jul 09, 2015 at 03:53:26PM +0200, Mark Kettenis wrote:
> > Date: Thu, 9 Jul 2015 15:40:37 +0200
> > From: Stefan Sperling
> >
> > Allow more time for USB athn(4) firmware boot. It seems people on
> > daemonforums
> > are running into the previous 1 second timeout on some machines, which the
> > driver will treat as fatal. I'm not sure if this will really fix the issue
> > but it won't hurt. Also reported in NetBSD land which inherited our driver:
> > http://mail-index.netbsd.org/current-users/2014/05/06/msg024793.html
>
> Sure. ok kettenis@
I found one laptop of mine can reproduce this issue.
It's a thinkpad x130e with an AMD APU chipset, dmesg below.
This should be similar hardware as the daemonforums reporter is using
("AMD E350") http://daemonforums.org/showpost.php?p=55318&postcount=38
If I plug a USB hub into this laptop, no devices behind the hub do attach.
Not even mice, USB storage sticks, etc. I never noticed this issue before,
but it's probably not new. I never used a USB hub with this machine before.
My current guess is the Atheros device doesn't get sufficient juice to
power up properly for some reason.
OpenBSD 5.8-beta (GENERIC.MP) #584: Thu Jul 9 12:02:49 CEST 2015
s...@ted.stsp.name:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 1701904384 (1623MB)
avail mem = 1646514176 (1570MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xf9d00 (58 entries)
bios0: vendor LENOVO version "8RET52WW (1.15 )" date 11/15/2011
bios0: LENOVO 305162G
acpi0 at bios0: rev 4
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC HPET APIC MCFG UEFI UEFI SSDT SSDT UEFI
acpi0: wakeup devices PB4_(S4) PB5_(S4) PB6_(S4) PB7_(S4) OHC1(S3) EHC1(S3)
OHC2(S3) SBAZ(S4) GEC_(S4) P2P_(S5) SPB0(S4) SPB1(S4) SPB2(S4) SPB3(S4) LID_(S4)
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpihpet0 at acpi0: 14318180 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD E-300 APU with Radeon(tm) HD Graphics, 1297.59 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line
16-way L2 cache
cpu0: 8 4MB entries fully associative
cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 199MHz
cpu0: mwait min=64, max=64, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD E-300 APU with Radeon(tm) HD Graphics, 1297.24 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line
16-way L2 cache
cpu1: 8 4MB entries fully associative
cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 21, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 2
acpimcfg0 at acpi0 addr 0xf800, bus 0-31
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PB4_)
acpiprt2 at acpi0: bus 1 (PB5_)
acpiprt3 at acpi0: bus 2 (PB6_)
acpiprt4 at acpi0: bus 3 (PB7_)
acpiprt5 at acpi0: bus 4 (P2P_)
acpiprt6 at acpi0: bus -1 (SPB0)
acpiprt7 at acpi0: bus -1 (SPB1)
acpiprt8 at acpi0: bus -1 (SPB2)
acpiprt9 at acpi0: bus -1 (SPB3)
acpiec0 at acpi0
acpicpu0 at acpi0: C2(0@100 io@0x841), PSS
acpicpu1 at acpi0: C2(0@100 io@0x841), PSS
acpitz0 at acpi0: critical temperature is 100 degC
acpibtn0 at acpi0: PWRB
acpibtn1 at acpi0: SLPB
acpithinkpad0 at acpi0
acpiac0 at acpi0: AC unit online
acpibat0 at acpi0: BAT1 model "45N1176" serial 875 type LION oem "SANYO"
acpibtn2 at acpi0: LID_
cpu0: 1297 MHz: speeds: 1300 1114 780 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "AMD AMD64 14h Host" rev 0x00
radeondrm0 at pci0 dev 1 function 0 "ATI Radeon HD 6310" rev 0x00
drm0 at radeondrm0
radeondrm0: msi
azalia0 at pci0 dev 1 function 1 "ATI Radeon HD 6310 HD Audio" rev 0x00: msi
azalia0: no supported codecs
ppb0 at pci0 dev 5 function 0 "AMD AMD64 14h PCIE" rev 0x00: msi
pci1 at ppb0 bus 1
rtwn0 at pci1 dev 0 function 0 "Realtek 8188CE" rev 0x01: msi
rtwn0: MAC/BB RTL8188CE, RF 6052 1T1R, address 9c:b7:0d:e1:11:6d
ppb1 at pci0 dev 6 function 0 "AMD AMD64 14h PCIE" rev 0x00: msi
pci2 at ppb1 bus 2
alc0 at pci2 dev 0 function 0 "Attansic Technology L1D" rev 0xc0: msi, address
04:7d:7b:31:00:6e
atphy0 at alc0 phy 0: F1 10/100/1000 PHY, rev. 0
ppb2 at pci0 dev 7 function 0 "AMD AMD64 14h PCIE" rev 0x00: msi
pci3 at ppb2 bus 3
rtsx0 at pci3 dev 0 function 0 "Realtek RTS520
Not vulnerable to CVE-2015-1793
We have received several emails asking if we are impacted by the latest CVE-2015-1793. We are not impacted. The code related to that CVE was added after we forked 1.0.1g and we did not merge these changes from upstream. This CVE only concerns newer OpenSSL releases.
BitCoin donations to the OpenBSD Foundation.
We've recently noticed a few attempts at larger Bitcoin donations to the OpenBSD Foundation. Due to the nature of these, we don't actually know who is attempting to donate, so I'm posting here. Due to changing laws, our provider (BitPay) had to limit transactions to $1000/day causing these donations to fail (according to what we received from BitPay the potential donor would have been told this). As of a few hours ago, we have managed to get the limit raised to $1/day - and a note of this is now reflected at http://www.openbsdfoundation.org/donations.html If you are attempting to donate a sizable amount of BitCoin, please bear the limit in mind when donating.. Donations of more than $1 in value would need to be made over multiple days. Sorry for any inconvenience, this is just how these things work. -Bob
Re: jail_bin_add: script to add binary and libs to chroot
On Tue, Jun 9, 2015 at 10:06 AM, Marc Espie wrote: > On Mon, Jun 08, 2015 at 03:37:27PM +0200, Landry Breuil wrote: >> On Mon, Jun 08, 2015 at 02:59:28PM +0200, Marc Espie wrote: >> > On Mon, Jun 08, 2015 at 01:46:17AM -0400, dan mclaughlin wrote: >> > > i figure this should be useful to some. >> > > any nits welcome. >> > >> > Unfortunately, this will become increasingly useless in >> > gtk-land. >> > >> > Compare ldd firefox vs a ktrace of the running binary... :( >> >> Totally pointless example - firefox is a very specific case, in that >> case you want ldd /usr/local/lib/firefox-*/libxul.so.* i dont know >> of many gtk applications doing this (bundling everything in a dlopen'ed >> library with tons of linking hacks to improve startup times...) > > I took firefox because it is the most blatant example, but Antoine told > me about it in general before I took a look at firefox. > Chrooting firefox is perfectly doable. I'm now using a chrooted firefox-esr as my primary browser. I've used dan's recipe as a starting point. Just be sure to copy all of the nss' shared libraries into the chroot: it took me a while to understand why firefox refused to work yelling at me about mysterious connectivity errors ;) Ciao! David
Re: increase athn firmware load timeout
> Date: Thu, 9 Jul 2015 15:40:37 +0200
> From: Stefan Sperling
>
> Allow more time for USB athn(4) firmware boot. It seems people on daemonforums
> are running into the previous 1 second timeout on some machines, which the
> driver will treat as fatal. I'm not sure if this will really fix the issue
> but it won't hurt. Also reported in NetBSD land which inherited our driver:
> http://mail-index.netbsd.org/current-users/2014/05/06/msg024793.html
Sure. ok kettenis@
> Index: if_athn_usb.c
> ===
> RCS file: /cvs/src/sys/dev/usb/if_athn_usb.c,v
> retrieving revision 1.34
> diff -u -p -r1.34 if_athn_usb.c
> --- if_athn_usb.c 12 Jun 2015 15:47:31 - 1.34
> +++ if_athn_usb.c 9 Jul 2015 13:28:01 -
> @@ -302,7 +302,8 @@ athn_usb_attachhook(void *xsc)
> /* Load firmware. */
> error = athn_usb_load_firmware(usc);
> if (error != 0) {
> - printf("%s: could not load firmware\n", sc->sc_dev.dv_xname);
> + printf("%s: could not load firmware (error %d)\n",
> + sc->sc_dev.dv_xname, error);
> return;
> }
>
> @@ -679,9 +680,9 @@ athn_usb_load_firmware(struct athn_usb_s
> s = splusb();
> usc->wait_msg_id = AR_HTC_MSG_READY;
> error = usbd_do_request(usc->sc_udev, &req, NULL);
> - /* Wait at most 1 second for firmware to boot. */
> + /* Wait at most 2 seconds for firmware to boot. */
> if (error == 0 && usc->wait_msg_id != 0)
> - error = tsleep(&usc->wait_msg_id, 0, "athnfw", hz);
> + error = tsleep(&usc->wait_msg_id, 0, "athnfw", 2 * hz);
> usc->wait_msg_id = 0;
> splx(s);
> return (error);
>
>
increase athn firmware load timeout
Allow more time for USB athn(4) firmware boot. It seems people on daemonforums
are running into the previous 1 second timeout on some machines, which the
driver will treat as fatal. I'm not sure if this will really fix the issue
but it won't hurt. Also reported in NetBSD land which inherited our driver:
http://mail-index.netbsd.org/current-users/2014/05/06/msg024793.html
Index: if_athn_usb.c
===
RCS file: /cvs/src/sys/dev/usb/if_athn_usb.c,v
retrieving revision 1.34
diff -u -p -r1.34 if_athn_usb.c
--- if_athn_usb.c 12 Jun 2015 15:47:31 - 1.34
+++ if_athn_usb.c 9 Jul 2015 13:28:01 -
@@ -302,7 +302,8 @@ athn_usb_attachhook(void *xsc)
/* Load firmware. */
error = athn_usb_load_firmware(usc);
if (error != 0) {
- printf("%s: could not load firmware\n", sc->sc_dev.dv_xname);
+ printf("%s: could not load firmware (error %d)\n",
+ sc->sc_dev.dv_xname, error);
return;
}
@@ -679,9 +680,9 @@ athn_usb_load_firmware(struct athn_usb_s
s = splusb();
usc->wait_msg_id = AR_HTC_MSG_READY;
error = usbd_do_request(usc->sc_udev, &req, NULL);
- /* Wait at most 1 second for firmware to boot. */
+ /* Wait at most 2 seconds for firmware to boot. */
if (error == 0 && usc->wait_msg_id != 0)
- error = tsleep(&usc->wait_msg_id, 0, "athnfw", hz);
+ error = tsleep(&usc->wait_msg_id, 0, "athnfw", 2 * hz);
usc->wait_msg_id = 0;
splx(s);
return (error);
Re: Unlock the reaper
On 9/07/2015 7:20 AM, Stuart Henderson wrote: On 2015/07/08 20:00, Max Fillinger wrote: On Wed, Jul 08, 2015 at 03:53:46PM +0200, Mark Kettenis wrote: I'm looking for testers for this diff. This should be safe to run on amd64, i386 and sparc64. But has been reported to lock up i386 machines. I can't reproduce this on any of my own systems. So I'm looking for help. I'm looking for people that are able to build a kernel with this diff and the MP_LOCKDEBUG option enabled (uncommented) in their GENERIC.MP kernel, run it on an MP machine and put some load on it to see if it locks up and/or panics. Being able to move forward with this would make OpenBSD run significantly better on MP systems. Thanks, Mark I just finished compiling the kernel for amd64; I might test i386 later. What kind of load would be required to give useful feedback? Would building the userland or some of the bigger ports be a useful test? Building base with the reaper unlock diff on i386 doesn't seem to trigger problems, or at least I haven't run into them in a few attempts. I do see problems when building ports on a dpb cluster, quite quickly in some cases - I just did a run and one node locked after 261s, another after 756s (dpb master stayed up FWIW). If you're trying to reproduce, make sure you set ddb.console=1 and check that you can break into ddb under normal conditions. If you manage to trigger a hang, see if you can break into ddb and get the usual things (backtrace, ps, sh reg, etc). I've been unable to get into ddb after a hang, including on this most recent run with MP_LOCKDEBUG. Nothing particular special was being built during the last hang; from dpb term-report, the last entry before "i386-2-" appeared (indicating that the host is no longer contactable) showed these archivers/libzip audio/libogg archivers/lzo2 Looking at build logs (which are streamed over ssh and logged on the dpb master) lzo2 and libzip were compiling (cc from base) and libogg was doing pkg_create/gzip when contact was lost. So I don't think it's going to be triggered by any particular ports, there is nothing out of the ordinary about these, and no funny autoconf checks were occurring at the time. The main other build-related active process would be sshd, and since pkg_create was running it would also most likely have been writing to nfs at the time. My money is on -> nfs. Ian McWilliam
Radeon & OpenGL on big-endian
Diff below is a fix for the regression [0] preventing the gallium r300
driver to work on big endian architectures. It has been written by
Michel Dänzer [1] but never made it into Mesa.
This diff allows me to use OpenGL acceleration on macppc. ajacoutot@
also confirmed he can use GNOME3 on his PowerBook with it.
So I'd like to hear from people using the gallium r300 driver on x86.
If this diff does not introduce regression, I'd really appreciate to
put it in instead of recompiling my Frankenstein xenocara.
The diff also makes r600 build on macppc/sparc64, in the hope that it
will allow other people to analyse/report/fix possible remaining issues.
[0] https://bugs.freedesktop.org/show_bug.cgi?id=71789
[1] http://lists.freedesktop.org/archives/mesa-dev/2013-December/050218.html
Index: dist/Mesa/src/gallium/drivers/r300/r300_blit.c
===
RCS file: /cvs/xenocara/dist/Mesa/src/gallium/drivers/r300/r300_blit.c,v
retrieving revision 1.7
diff -u -p -r1.7 r300_blit.c
--- dist/Mesa/src/gallium/drivers/r300/r300_blit.c 20 Feb 2015 23:09:52
- 1.7
+++ dist/Mesa/src/gallium/drivers/r300/r300_blit.c 25 Jun 2015 13:01:25
-
@@ -185,7 +185,9 @@ static void r300_set_clear_color(struct
union util_color uc;
memset(&uc, 0, sizeof(uc));
-util_pack_color(color->f, fb->cbufs[0]->format, &uc);
+util_pack_color(color->f,
+r300_get_hw_format(fb->cbufs[0]->format,
PIPE_BIND_RENDER_TARGET),
+&uc);
if (fb->cbufs[0]->format == PIPE_FORMAT_R16G16B16A16_FLOAT ||
fb->cbufs[0]->format == PIPE_FORMAT_R16G16B16X16_FLOAT) {
Index: dist/Mesa/src/gallium/drivers/r300/r300_context.h
===
RCS file: /cvs/xenocara/dist/Mesa/src/gallium/drivers/r300/r300_context.h,v
retrieving revision 1.7
diff -u -p -r1.7 r300_context.h
--- dist/Mesa/src/gallium/drivers/r300/r300_context.h 20 Feb 2015 23:09:52
- 1.7
+++ dist/Mesa/src/gallium/drivers/r300/r300_context.h 25 Jun 2015 13:01:25
-
@@ -45,6 +45,8 @@ struct r300_vertex_shader;
struct r300_stencilref_context;
enum colormask_swizzle {
+COLORMASK_ARGB,
+COLORMASK_XRGB,
COLORMASK_BGRA,
COLORMASK_RGBA,
COLORMASK_,
Index: dist/Mesa/src/gallium/drivers/r300/r300_state.c
===
RCS file: /cvs/xenocara/dist/Mesa/src/gallium/drivers/r300/r300_state.c,v
retrieving revision 1.7
diff -u -p -r1.7 r300_state.c
--- dist/Mesa/src/gallium/drivers/r300/r300_state.c 20 Feb 2015 23:09:52
- 1.7
+++ dist/Mesa/src/gallium/drivers/r300/r300_state.c 25 Jun 2015 13:01:25
-
@@ -225,6 +225,12 @@ static unsigned blend_discard_conditiona
/* The hardware colormask is clunky a must be swizzled depending on the format.
* This was figured out by trial-and-error. */
+static unsigned argb_cmask(unsigned mask)
+{
+ return ((mask & (PIPE_MASK_R | PIPE_MASK_G | PIPE_MASK_B)) << 1) |
+ ((mask & PIPE_MASK_A) >> 3);
+}
+
static unsigned bgra_cmask(unsigned mask)
{
return ((mask & PIPE_MASK_R) << 2) |
@@ -471,6 +477,8 @@ static void* r300_create_blend_state(str
/* Build a command buffer. */
{
unsigned (*func[COLORMASK_NUM_SWIZZLES])(unsigned) = {
+argb_cmask,
+argb_cmask,
bgra_cmask,
rgba_cmask,
_cmask,
@@ -482,7 +490,8 @@ static void* r300_create_blend_state(str
};
for (i = 0; i < COLORMASK_NUM_SWIZZLES; i++) {
-boolean has_alpha = i != COLORMASK_RGBX && i != COLORMASK_BGRX;
+boolean has_alpha = i != COLORMASK_RGBX && i != COLORMASK_BGRX &&
+i != COLORMASK_XRGB;
BEGIN_CB(blend->cb_clamp[i], 8);
OUT_CB_REG(R300_RB3D_ROPCNTL, rop);
@@ -1667,6 +1676,7 @@ r300_create_sampler_view_custom(struct p
boolean dxtc_swizzle = r300_screen(pipe->screen)->caps.dxtc_swizzle;
if (view) {
+enum pipe_format format = r300_get_hw_format(templ->format,
texture->bind);
unsigned hwformat;
view->base = *templ;
@@ -1682,24 +1692,24 @@ r300_create_sampler_view_custom(struct p
view->swizzle[2] = templ->swizzle_b;
view->swizzle[3] = templ->swizzle_a;
-hwformat = r300_translate_texformat(templ->format,
+hwformat = r300_translate_texformat(format,
view->swizzle,
is_r500,
dxtc_swizzle);
if (hwformat == ~0) {
fprintf(stderr, "r300: Ooops. Got unsupported format %s in %s.\n",
-util_format_short_name(templ->format), __func__);
+util_format_short_name(format), __func__);
}
assert(hwformat != ~0);
r300_texture_setup_format_state(r300_
Re: LibreSSL 2.2.1 released - Windows version clarification
On Wed, Jul 8, 2015 at 7:49 AM, Brent Cook wrote: > We have released LibreSSL 2.2.1, which will be arriving in the > LibreSSL directory of your local OpenBSD mirror soon. > > This release continues from the OpenBSD 5.8 development tree, featuring > expanded OS support, code improvements, and feature removal. Also note > that SSLv3 support has not been removed yet, but it should happen soon. > > Notable changes in this release are: > > * Assorted build fixes for musl, HP-UX, Mingw, and Solaris. > > * Initial support for Windows 2009, 2003, and XP. Update: As I continue to receive emails stating that I must have made a typo about Windows 2009 and 2003, I would like to point out that these are, in fact, real! I have amended the Changelog to be more clear: * Initial support for Windows Embeded 2009, Server 2003, XP While these are not all consumer desktop editions, they share a common core API level, and thus were supported by the same additions to the LibreSSL portability layer. I thought it was worth mentioning simply because these were the versions for which people have kindly sent me test reports. Thanks, and enjoy using LibreSSL. - Brent
[patch] add "X-Forwarded-For" to httpd(8)'s combined logs
Hi guys. This is my first ever post to an openbsd mailing list. I apologize in advance if i'm doing something wrong. So basically, I had just setup a relayd box in front of a few httpd boxes behind a ipsec tunnel for fun. btw, reyk and others, thank you so much for this fine software. I noticed httpd(8) didn't have a way to log "true ips" I went ahead and synced my source tree and wrote this: disclaimer: I'm not a programmer. nor an expert. idk if this is even an acceptable log format... also, should something like this ( if it even belongs in the tree) be tied to the "X-Forwarded-For" variable? is "HTTP_VIA" a better choice? AFIAK it's arbitrary. Also, was anyone planning on adding a 'customlog' feature? Perhaps such a thing is going to be left out on purpose? Sorry for bugging y'all. Just wanted to share my first practical diff. -gwurr3 Index: usr.sbin/httpd/server_http.c === RCS file: /cvs/src/usr.sbin/httpd/server_http.c,v retrieving revision 1.84 diff -u -p -r1.84 server_http.c --- usr.sbin/httpd/server_http.c23 Jun 2015 17:25:01 - 1.84 +++ usr.sbin/httpd/server_http.c9 Jul 2015 08:40:43 - @@ -1422,7 +1422,7 @@ server_log_http(struct client *clt, u_in static char tstamp[64]; static char ip[INET6_ADDRSTRLEN]; time_t t; - struct kvkey, *agent, *referrer; + struct kvkey, *agent, *referrer, *forwarded; struct tm *tm; struct server_config*srv_conf; struct http_descriptor *desc; @@ -1479,9 +1479,15 @@ server_log_http(struct client *clt, u_in agent->kv_value == NULL) agent = NULL; + key.kv_key = "X-Forwarded-For"; + if ((forwarded = kv_find(&desc->http_headers, &key)) != NULL && + forwarded->kv_value == NULL) + forwarded = NULL; + + if (evbuffer_add_printf(clt->clt_log, "%s %s - %s [%s] \"%s %s%s%s%s%s\"" - " %03d %zu \"%s\" \"%s\"\n", + " %03d %zu \"%s\" \"%s\" \"%s\"\n", srv_conf->name, ip, clt->clt_remote_user == NULL ? "-" : clt->clt_remote_user, tstamp, server_httpmethod_byid(desc->http_method), @@ -1492,7 +1498,8 @@ server_log_http(struct client *clt, u_in desc->http_version == NULL ? "" : desc->http_version, code, len, referrer == NULL ? "" : referrer->kv_value, - agent == NULL ? "" : agent->kv_value) == -1) + agent == NULL ? "" : agent->kv_value, + forwarded == NULL ? "" : forwarded->kv_value) == -1) return (-1); break;
Re: Unlock the reaper
> Date: Wed, 8 Jul 2015 16:35:09 +0200 (CEST)
> From: Mark Kettenis
>
> > Date: Wed, 8 Jul 2015 15:17:46 +0100
> > From: Stuart Henderson
> >
> > On 2015/07/08 15:53, Mark Kettenis wrote:
> > > Index: uvm_map.c
> > ..
> > > @@ -2466,8 +2470,7 @@ uvm_map_teardown(struct vm_map *map)
> > > if ((entry = RB_ROOT(&map->addr)) != NULL)
> > > DEAD_ENTRY_PUSH(&dead_entries, entry);
> > > while (entry != NULL) {
> > > - if (waitok)
> > > - uvm_pause();
> > > + sched_pause();
> >
> > ah, slightly different than the one I've tried before which
> > had uvm_pause instead of sched_pause here plus an extra change
> > in uvm_glue.c.
>
> Just a bit of a cleanup though. Not going to make a difference.
>
> > I'll give this a spin on i386 after my current build finishes.
> > FWIW I've been running the previous version on amd64 for ages with
> > very positive results.
>
> I won't stop you ;). But my goal was to trick others into testing
> this diff such that this doesn't hamper the i386 ports builds.
And thanks to Stuart, we have found a (fairly straightforward) lock
order reversal. I'm working on a fix.
Thanks for everybody who tested so far. Feel free to continue
testing, although you might want to be a bit careful on i386 systems
as they are somewhat likely to lock up with this diff.
[patch] xlocale part 4: make localetable_head thread-safe
localetable_head is used in libc/locale/setrunelocale.c for caching
previously loaded ctype locale (we keep a copy of every loaded
runelocale).
- it is a static variable that hold a list.
- _findrunelocale() is used for search in this list.
- _newrunelocale() will add a new item in the list (add in front of
list), if it isn't already in the list.
In order to prevent race that would result adding multiple times the
same runelocale in the list (by multiple threads) I use a mutex in
_newrunelocale() to protect all the adding code path.
--
Sebastien Marie
Index: b/lib/libc/locale/setrunelocale.c
===
--- a/lib/libc/locale/setrunelocale.c 2015-07-09 08:12:38.659210133 +0200
+++ b/lib/libc/locale/setrunelocale.c 2015-07-09 09:48:35.757157373 +0200
@@ -102,6 +102,7 @@
#include "citrus_ctype.h"
#include "rune.h"
#include "rune_local.h"
+#include "thread_private.h"
#include "xlocale_private.h"
struct localetable {
@@ -110,6 +111,7 @@
struct localetable *next;
};
static struct localetable *localetable_head;
+_THREAD_PRIVATE_MUTEX(localetable_head);
_RuneLocale *
_findrunelocale(const char *path)
@@ -130,22 +132,27 @@
struct localetable *lt;
FILE *fp;
_RuneLocale *rl;
+ int ret = 0;
if (strlen(path) + 1 > sizeof(lt->path))
return EINVAL;
+ _THREAD_PRIVATE_MUTEX_LOCK(localetable_head);
rl = _findrunelocale(path);
if (rl)
- return 0;
+ goto out; /* ret = 0 */
- if ((fp = fopen(path, "re")) == NULL)
- return ENOENT;
+ if ((fp = fopen(path, "re")) == NULL) {
+ ret = ENOENT;
+ goto out;
+ }
if ((rl = _Read_RuneMagi(fp)) != NULL)
goto found;
fclose(fp);
- return EFTYPE;
+ ret = EFTYPE;
+ goto out;
found:
fclose(fp);
@@ -154,21 +161,25 @@
if (_citrus_ctype_open(&rl->rl_citrus_ctype, rl->rl_encoding)) {
_NukeRune(rl);
- return EINVAL;
+ ret = EINVAL;
+ goto out;
}
/* register it */
lt = malloc(sizeof(struct localetable));
if (lt == NULL) {
_NukeRune(rl);
- return ENOMEM;
+ ret = ENOMEM;
+ goto out;
}
strlcpy(lt->path, path, sizeof(lt->path));
lt->runelocale = rl;
lt->next = localetable_head;
localetable_head = lt;
- return 0;
+out:
+ _THREAD_PRIVATE_MUTEX_UNLOCK(localetable_head);
+ return ret;
}
int
Re: Unlock the reaper
A further success story on an amd64 Core2 laptop. I built an entire release with no complications. Suspend/Hibernate/Resume work fine as well. OpenBSD 5.8-beta (GENERIC.MP) #451: Wed Jul 8 16:33:38 CEST 2015 t...@miraculix.home:/sys/arch/amd64/compile/GENERIC.MP real mem = 2634596352 (2512MB) avail mem = 2550943744 (2432MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe (37 entries) bios0: vendor Apple Inc. version "MB21.88Z.00A5.B07.0706270922" date 06/27/07 bios0: Apple Inc. MacBook2,1 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP HPET APIC MCFG ASF! SBST ECDT SSDT SSDT SSDT acpi0: wakeup devices ADP1(S3) LID0(S3) PXS1(S4) PXS2(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB7(S3) EC__(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz, 1995.35 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF,SENSOR cpu0: 4MB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 166MHz cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz, 1995.21 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF,SENSOR cpu1: 4MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 1 acpimcfg0 at acpi0 addr 0xf000, bus 0-255 acpiec0 at acpi0 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (RP01) acpiprt2 at acpi0: bus 2 (RP02) acpiprt3 at acpi0: bus 3 (PCIB) acpicpu0 at acpi0: !C3(100@55 mwait@0x31), !C2(500@1 mwait@0x10), C1(1000@1 mwait), PSS acpicpu1 at acpi0: !C3(100@55 mwait@0x31), !C2(500@1 mwait@0x10), C1(1000@1 mwait), PSS acpiac0 at acpi0: AC unit online acpibtn0 at acpi0: LID0 acpibtn1 at acpi0: PWRB acpibtn2 at acpi0: SLPB acpibat0 at acpi0: BAT0 model "15253732082930497" type 15253732284385612 oem "15253732284387396" acpivideo0 at acpi0: GFX0 cpu0: Enhanced SpeedStep 1995 MHz: speeds: 2000, 1833, 1667, 1500, 1333, 1000 MHz memory map conflict 0x9ef0/0x10 memory map conflict 0x9f00/0x100 memory map conflict 0xf00f8000/0x1000 memory map conflict 0xfed1c000/0x4000 memory map conflict 0xfffb/0x3 pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 82945GM Host" rev 0x03 vga1 at pci0 dev 2 function 0 "Intel 82945GM Video" rev 0x03 intagp0 at vga1 agp0 at intagp0: aperture at 0xa000, size 0x1000 inteldrm0 at vga1 drm0 at inteldrm0 inteldrm0: 1280x800 wsdisplay0 at vga1 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) "Intel 82945GM Video" rev 0x03 at pci0 dev 2 function 1 not configured vendor "Intel", unknown product 0x27a3 (class DASP subclass Time and Frequency, rev 0x03) at pci0 dev 7 function 0 not configured azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x02: msi azalia0: codecs: Sigmatel STAC9220/1 audio0 at azalia0 ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x02: msi pci1 at ppb0 bus 1 mskc0 at pci1 dev 0 function 0 "Marvell Yukon 88E8053" rev 0x22, Yukon-2 EC rev. A3 (0x2): apic 1 int 16 msk0 at mskc0 port A: address 00:19:e3:38:6c:56 eephy0 at msk0 phy 0: 88E Gigabit PHY, rev. 2 ppb1 at pci0 dev 28 function 1 "Intel 82801GB PCIE" rev 0x02: msi pci2 at ppb1 bus 2 athn0 at pci2 dev 0 function 0 "Atheros AR5418" rev 0x01: apic 1 int 17 athn0: MAC AR5418 rev 2, RF AR5133 (2T3R), ROM rev 4, address 00:1b:63:02:1c:22 uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x02: apic 1 int 21 uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x02: apic 1 int 19 uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x02: apic 1 int 18 uhci3 at pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x02: apic 1 int 16 ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x02: apic 1 int 21 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 ppb2 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0xe2 pci3 at ppb2 bus 3 "AT&T/Lucent FW322 1394" rev 0x61 at pci3 dev 3 function 0 not configured pcib0 at pci0 dev 31 function 0 "Intel 82801GBM LPC" rev 0x02 pciide0 at pci0 dev 31 function 1 "Intel 82801GB IDE" rev 0x02: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility atapiscsi0 at pciide0 channel 0 drive 0 scsibus1 at atapiscsi0: 2 targets cd0 at scsibus1 targ
ipip interrupt path and list iteration
Most of the network interrupt paths are now free from global list
iterations. The rule I tried to follow is simple. If you already
have an ifp pointer and need a per-ifp resource use it, otherwise
do a route lookup.
Diff below converts one of the few remaining iteration on the global
list of interfaces (&ifnet).
Tests and oks are welcome.
Index: netinet/ip_ipip.c
===
RCS file: /cvs/src/sys/netinet/ip_ipip.c,v
retrieving revision 1.60
diff -u -p -r1.60 ip_ipip.c
--- netinet/ip_ipip.c 16 Jun 2015 11:09:40 - 1.60
+++ netinet/ip_ipip.c 9 Jul 2015 06:52:35 -
@@ -145,11 +145,8 @@ void
ipip_input(struct mbuf *m, int iphlen, struct ifnet *gifp, int proto)
{
struct sockaddr_in *sin;
- struct ifnet *ifp;
- struct ifaddr *ifa;
struct niqueue *ifq = NULL;
struct ip *ipo;
- u_int rdomain;
#ifdef INET6
struct sockaddr_in6 *sin6;
struct ip6_hdr *ip6;
@@ -295,45 +292,33 @@ ipip_input(struct mbuf *m, int iphlen, s
}
/* Check for local address spoofing. */
- if (((ifp = if_get(m->m_pkthdr.ph_ifidx)) == NULL ||
- !(ifp->if_flags & IFF_LOOPBACK)) && ipip_allow != 2) {
- rdomain = rtable_l2(m->m_pkthdr.ph_rtableid);
- TAILQ_FOREACH(ifp, &ifnet, if_list) {
- if (ifp->if_rdomain != rdomain)
- continue;
- TAILQ_FOREACH(ifa, &ifp->if_addrlist, ifa_list) {
- if (ipo) {
- if (ifa->ifa_addr->sa_family !=
- AF_INET)
- continue;
-
- sin = (struct sockaddr_in *)
- ifa->ifa_addr;
- if (sin->sin_addr.s_addr ==
- ipo->ip_src.s_addr) {
- ipipstat.ipips_spoof++;
- m_freem(m);
- return;
- }
- }
-#ifdef INET6
- if (ip6) {
- if (ifa->ifa_addr->sa_family !=
- AF_INET6)
- continue;
-
- sin6 = (struct sockaddr_in6 *)
- ifa->ifa_addr;
- if (IN6_ARE_ADDR_EQUAL(&sin6->sin6_addr,
- &ip6->ip6_src)) {
- ipipstat.ipips_spoof++;
- m_freem(m);
- return;
- }
-
- }
+ if (ipip_allow != 2) {
+ struct sockaddr_storage ss;
+ struct rtentry *rt;
+
+ if (ipo) {
+ sin = (struct sockaddr_in *)&ss;
+ sin->sin_family = AF_INET;
+ sin->sin_len = sizeof(*sin);
+ sin->sin_addr = ipo->ip_src;
+#ifdef INET6
+ } else if (ip6) {
+ sin6 = (struct sockaddr_in6 *)&ss;
+ sin6->sin6_family = AF_INET6;
+ sin6->sin6_len = sizeof(*sin6);
+ sin6->sin6_addr = ip6->ip6_src;
#endif /* INET6 */
+ }
+ rt = rtalloc((struct sockaddr *)&ss, 0,
+ m->m_pkthdr.ph_rtableid);
+ if (rt != NULL) {
+ if (rt->rt_flags & RTF_LOCAL) {
+ ipipstat.ipips_spoof++;
+ m_freem(m);
+ rtfree(rt);
+ return;
}
+ rtfree(rt);
}
}
