Re: initial 11ac support for iwm(4)
On Wed, Mar 16, 2022 at 04:11:41PM +0100, Stefan Sperling wrote: > This patch adds initial 11ac support to the iwm(4) driver. > It allows use of 80 MHz channels and VHT MCS. > > In net80211 I added a new rate control module to support VHT rates, as > a new file called ieee80211_ra_vht.c, derived from ieee80211_ra.c which > we use in 11n mode. The task of this code is to determine the fastest > VHT rate that is usable. (This was not needed to add 11ac support to > iwx(4) because iwx(4) devices perform this task in firmware.) > Retries at lower rates must be handled by the driver. iwm(4) does this via > the "LQ" command which sends a table of Tx rates the firmware should use. > > So far, I have tested this successfully on iwm(4) 8265. > In my testing performance peaks at around 250Mbit/s. > There is no device-specific code involved so I would expect this to > work on all cards supported by the driver. > > I will test a few more devices I have here soon, but I don't have > access to all iwm(4) hardware variants at the moment. Testing on any > iwm(4) device would be appreciated. Please be precise about which model > of iwm(4) you are testing on when reporting results. > No issues on my iwm(4) 8265 either. Seeing around 250Mbit/s here as well! Thanks for all the work on these devices. James
Re: acpithinkpad: a fix for the x260
e, > - "PBLS", 1, , NULL); > + ret = aml_evalname(sc->sc_acpi, sc->sc_devnode, "PBLS", 1, , NULL); > + > + if (ret) > + return ret; > > thinkpad_get_brightness(sc); > + > + return 0; > } > > int > @@ -765,7 +775,8 @@ thinkpad_set_param(struct wsdisplay_para > dp->curval = maxval; > sc->sc_brightness &= ~0xff; > sc->sc_brightness |= dp->curval; > - acpi_addtask(sc->sc_acpi, thinkpad_set_brightness, sc, 0); > + acpi_addtask(sc->sc_acpi, (void *)thinkpad_set_brightness, sc, > + 0); > acpi_wakeup(sc->sc_acpi); > return 0; > default: > -- James Turner
Re: acpithinkpad: fix brightness keys, keyboard backlight value
quot;MHKA",
> 0, NULL, )) {
> printf("%s: no MHKA\n", DEVNAME(sc));
> return (1);
> }
>
> + /* Enable events we need to know about */
> + mask |= (THINKPAD_MASK_BRIGHTNESS_UP | THINKPAD_MASK_BRIGHTNESS_DOWN |
> + THINKPAD_MASK_KBD_BACKLIGHT);
> +
> + DPRINTF(("%s: setting event mask to 0x%llx\n", DEVNAME(sc), mask));
> +
> /* Update hotkey mask */
> bzero(args, sizeof(args));
> args[0].type = args[1].type = AML_OBJTYPE_INTEGER;
> @@ -380,6 +396,8 @@ thinkpad_hotkey(struct aml_node *node, i
> if (aml_evalinteger(sc->sc_acpi, sc->sc_devnode, "MHKP",
> 0, NULL, ))
> break;
> +
> + DPRINTF(("%s: event 0x%03llx\n", DEVNAME(sc), event));
> if (event == 0)
> break;
>
> @@ -535,13 +553,37 @@ thinkpad_volume_mute(struct acpithinkpad
> int
> thinkpad_brightness_up(struct acpithinkpad_softc *sc)
> {
> - return (thinkpad_cmos(sc, THINKPAD_CMOS_BRIGHTNESS_UP));
> + int b;
> +
> + if (sc->sc_hkey_version == THINKPAD_HKEY_VERSION2) {
> + thinkpad_get_brightness(sc);
> + b = sc->sc_brightness & 0xff;
> + if (b < ((sc->sc_brightness >> 8) & 0xff)) {
> + sc->sc_brightness = b + 1;
> + thinkpad_set_brightness(sc, 0);
> + }
> +
> + return (0);
> + } else
> + return (thinkpad_cmos(sc, THINKPAD_CMOS_BRIGHTNESS_UP));
> }
>
> int
> thinkpad_brightness_down(struct acpithinkpad_softc *sc)
> {
> - return (thinkpad_cmos(sc, THINKPAD_CMOS_BRIGHTNESS_DOWN));
> + int b;
> +
> + if (sc->sc_hkey_version == THINKPAD_HKEY_VERSION2) {
> + thinkpad_get_brightness(sc);
> + b = sc->sc_brightness & 0xff;
> + if (b > 0) {
> + sc->sc_brightness = b - 1;
> + thinkpad_set_brightness(sc, 0);
> + }
> +
> + return (0);
> + } else
> + return (thinkpad_cmos(sc, THINKPAD_CMOS_BRIGHTNESS_DOWN));
> }
>
> int
> @@ -620,7 +662,7 @@ thinkpad_set_thinklight(void *arg0, int
> }
>
> int
> -thinkpad_get_backlight(struct wskbd_backlight *kbl)
> +thinkpad_get_kbd_backlight(struct wskbd_backlight *kbl)
> {
> struct acpithinkpad_softc *sc = acpithinkpad_cd.cd_devs[0];
>
> @@ -637,7 +679,7 @@ thinkpad_get_backlight(struct wskbd_back
> }
>
> int
> -thinkpad_set_backlight(struct wskbd_backlight *kbl)
> +thinkpad_set_kbd_backlight(struct wskbd_backlight *kbl)
> {
> struct acpithinkpad_softc *sc = acpithinkpad_cd.cd_devs[0];
> int maxval;
> @@ -664,6 +706,8 @@ thinkpad_get_brightness(struct acpithink
> {
> aml_evalinteger(sc->sc_acpi, sc->sc_devnode,
> "PBLG", 0, NULL, >sc_brightness);
> +
> + DPRINTF(("%s: %s: 0x%llx\n", DEVNAME(sc), __func__, sc->sc_brightness));
> }
>
> void
> @@ -672,11 +716,15 @@ thinkpad_set_brightness(void *arg0, int
> struct acpithinkpad_softc *sc = arg0;
> struct aml_value arg;
>
> + DPRINTF(("%s: %s: 0x%llx\n", DEVNAME(sc), __func__, sc->sc_brightness));
> +
> memset(, 0, sizeof(arg));
> arg.type = AML_OBJTYPE_INTEGER;
> arg.v_integer = sc->sc_brightness & 0xff;
> aml_evalname(sc->sc_acpi, sc->sc_devnode,
> "PBLS", 1, , NULL);
> +
> + thinkpad_get_brightness(sc);
> }
>
> int
>
--
James Turner
Re: libxshmfence.so.0.0 issues with latest snapshot?
On Tue, Jun 26, 2018 at 10:59:09AM -0700, jungle Boogie wrote: > Hi All, > > Prior to updating to the latest snapshot (#56), I updated my packages, > then updated to #56. Now X won't start and I have a library error: > ls.so: X: can't load library libxshmfence.so.0.0 > > At the time of updating packages, there wasn't a new snapshot > available so I felt it was safe to proceed. > > What are my options at this point? Is this something others are also > experiencing? > > --- > inum: 883510009027723 > sip: jungleboo...@sip2sip.info > I ran into the same issue. You can either wait for a new snapshot, or build X yourself following step 5 in release(8). -- James Turner
Re: ihidev(4) polling
On Thu, Nov 16, 2017 at 12:32:44PM -0600, joshua stein wrote: > Now that the dwiic(4) PCI support is in, this implements polling > mode for ihidev to work around the problem of ioapic interrupts not > arriving for them after setup. I've spent far too much time trying > to debug that problem (including much of my time at t2k17), so I > made this as a workaround until someone else fixes that issue. > > The new PCI attachment of dwiic sets sc_poll_ihidev, which > dwiic_acpi_found_ihidev() checks for and does not set ia_intr, and > this diff implements the other half which sets up a polling mode in > response to that. > > It does slow polling by default to conserve power, and once movement > is detected on a device under ihidev (like imt(4)), it starts > polling quickly for a while. > > It's not perfect but it's enough to make the touchpad work on these > machines and will hopefully be a temporary fix. > > So I have to ask since when I hit you up on icb the above terms where all mentioned. With this diff and what you just committed to src add touchpad support to the Xiaomi Mi Air 12.5"? Even if not, thanks for all your hard work on adding touchpad support to these new devices. -- James Turner
Re: sqlite3 update
On Thu, Jun 23, 2016 at 09:03:43AM +0100, Stuart Henderson wrote: > On 2016/06/23 00:25, Ted Unangst wrote: > > Stuart Henderson wrote: > > > Turns out I forgot about the pthread stubs, without which there > > > are build failures in mandoc and various ports things unless we link > > > them with -lpthread. This broke a few things in my first ports test > > > build, but thanks to guenther's work it should now be valid to pull > > > this in via an inter-library dependency rather than having to > > > sprinkle it over mandoc and lots of the ports tree. > > > > > > > Index: Makefile > > > -# so that it works with NO THREADS > > > -SRCS += pthread_stub.c > > > - > > > -#mem3.c mem5.c > > > +SRCS = sqlite3.c > > > +LDADD = -lpthread > > > > Why are we dropping the stubs in favor of linking with libpthread? > > Trying to avoid too many changes to upstream's source. But I suppose > we can keep that as a separate file - just tested that with 3 things > where I ran into the problem (mandoc, www/kcaldav, www/nsh,static) > and they're happy. And I've tried build usr.bin/sqlite3 both with > and without -pthread and both versions of that also work OK for the > things I've tested. > > So, new diff: https://junkpile.org/sqlite-3.11.0.diff.gz,2 > > pthread_stub.c moves from lib/libsqlite3/tsrc/ to lib/libsqlite3/ > but is otherwise unchanged from the in-tree version. > > The only change to the Makefile from my previous diff is adding > pthread_stub.c to SRCS. > Like I've stated before, I think this is the best way to move forward for the time being, so you have my ok. -- James Turner
Re: sqlite3 update
On Wed, Jun 08, 2016 at 11:33:42PM +0100, Stuart Henderson wrote: > On 2016/06/03 20:17, James Turner wrote: > > On Fri, Jun 03, 2016 at 11:24:15PM +0100, Stuart Henderson wrote: > > > On 2016/06/01 11:22, Stuart Henderson wrote: > > > > On 2016/06/01 09:09, Landry Breuil wrote: > > > > > And most importantly, 47 (released next week) requires 3.11. > > > > > /usr/obj/ports/firefox-47.0beta9/firefox-47.0b9/old-configure:SQLITE_VERSION=3.11.0 > > > > > > > > Ok, I'll update the diff this evening. > > > > > > So this was a bit optimistic... 3.11 and 3.13 start making more > > > changes to the Tcl scripts that replaced the awk scripts and it's > > > beyond my awk to replicate them. (Also I'm not too sure about the > > > XXX in Makefile about lempar.c which has changed upstream since > > > the version where we added it). > > > > > > As I see it there are two options to get us out of the hole. > > > > > > - Pregenerate the files with Tcl and commit them, adapting the > > > Makefile to use them. This is looking possible for 3.11 though > > > still a bit of a pain to handle the build system hacks that > > > will be needed. From a quick look at 3.13 there are more build > > > system changes and further changes to the Tcl. I for one am > > > not going to be able to maintain a forked build system with > > > this many moving pieces. > > > > > > - Switch to the "amalgamation" (4 source files: 3 for the lib, > > > one for the shell), which is what upstream push people towards > > > using (and what everybody else that I've seen including > > > sqlite source uses). > > > Does anyone have thoughts about these two as a "for now" option? > I prefer option 2. Switch to the amalgamation with our changes on top. > > > > With this the main file is unfortunately huge but would be easier > > > by far to update later. Note that we only have a small change to > > > the actual source code (replacing the RNG code) which is easy enough > > > to carry across. Most of our changes are to the build infrastructure. > > > > > > As far as Firefox goes, I think sqlite 3.11 should do us until > > > release, but might be problematic if we want to update in -stable > > > ports. > > > > > > From what I can tell sqlite upstream *are* careful about ABI. > > > But it would seem quite a stretch to expect things to work > > > safely/reliably with two different versions brought into > > > one address space. > > > > > > > So when I talked with Ingo about removing SQLite from base we talked > > about imported the "amalgamation" into mandoc for local use only and > > then removing lib/libsqlite3 and usr.bin/sqlite3. > > > > We would then need to updated sqlite3 in ports and update ports to use > > this instead. > > I think this does make sense. But it's used quite a lot in ports, > handling a move back to ports is too much work to do before release. > -- James Turner
Re: sqlite3 update
On Fri, Jun 03, 2016 at 11:24:15PM +0100, Stuart Henderson wrote: > On 2016/06/01 11:22, Stuart Henderson wrote: > > On 2016/06/01 09:09, Landry Breuil wrote: > > > And most importantly, 47 (released next week) requires 3.11. > > > /usr/obj/ports/firefox-47.0beta9/firefox-47.0b9/old-configure:SQLITE_VERSION=3.11.0 > > > > Ok, I'll update the diff this evening. > > So this was a bit optimistic... 3.11 and 3.13 start making more > changes to the Tcl scripts that replaced the awk scripts and it's > beyond my awk to replicate them. (Also I'm not too sure about the > XXX in Makefile about lempar.c which has changed upstream since > the version where we added it). > > As I see it there are two options to get us out of the hole. > > - Pregenerate the files with Tcl and commit them, adapting the > Makefile to use them. This is looking possible for 3.11 though > still a bit of a pain to handle the build system hacks that > will be needed. From a quick look at 3.13 there are more build > system changes and further changes to the Tcl. I for one am > not going to be able to maintain a forked build system with > this many moving pieces. > > - Switch to the "amalgamation" (4 source files: 3 for the lib, > one for the shell), which is what upstream push people towards > using (and what everybody else that I've seen including > sqlite source uses). > > With this the main file is unfortunately huge but would be easier > by far to update later. Note that we only have a small change to > the actual source code (replacing the RNG code) which is easy enough > to carry across. Most of our changes are to the build infrastructure. > > As far as Firefox goes, I think sqlite 3.11 should do us until > release, but might be problematic if we want to update in -stable > ports. > > From what I can tell sqlite upstream *are* careful about ABI. > But it would seem quite a stretch to expect things to work > safely/reliably with two different versions brought into > one address space. > So when I talked with Ingo about removing SQLite from base we talked about imported the "amalgamation" into mandoc for local use only and then removing lib/libsqlite3 and usr.bin/sqlite3. We would then need to updated sqlite3 in ports and update ports to use this instead. I personally think this is the way to go. Sadly I don't have the time to do this right now (We just welcomed our second child recently). -- James Turner
Re: sqlite3 update
On Tue, May 31, 2016 at 11:36:35PM +0100, Stuart Henderson wrote: > Thanks for the pointer Ingo.. > > I'll be doing tests (including a bulk ports build) with this, > but here's an update to sqlite 3.10.2 (the version which is > in Firefox 46) in the hope it will let us get rid of the > conflicting sqlite3 versions in firefox. > > If this is the wrong version to be targetting (Landry?) please > let me know. > > If anyone has anything in particular they'd like to test, > could you try it please. > > A shlib_version update is included, four symbols were removed so > it's a major bump. > > I modified addopcodes.awk by hand based on the changes in the > upstream version which has now switched to a Tcl script. > > (I don't really understand how things are working in Firefox on > other OS, there are two different versions of sqlite in their Stuart, This looks good. I've tested with mandoc and fossil in ports. ok jturner. -- James Turner
Re: SQLite 3.9.2 update
On Sat, Dec 19, 2015 at 08:43:38AM +0100, Landry Breuil wrote: > On Mon, Dec 14, 2015 at 08:51:47PM +0100, Landry Breuil wrote: > > On Mon, Dec 14, 2015 at 01:09:38PM -0500, James Turner wrote: > > > SQLite 3.9.2 updated. Tested on amd64. I've included the json extension > > > but haven't enabled it yet. I can leave it out if know thinks it will be > > > usful at this time and can always at it later. oks? > > > > I havent tested this yet, but i'll just say that firefox 44 (due in 6 > > weeks) relies/integrates 3.9.1.. just the same story all over :) > > So i'll put it on my buildboxes as soon as i'll start working on 44beta > > next weekend.. > > I'm using it now since some days without issue, and it went through an > amd64 bulk build (thx ajacoutot@) without fallout. Fwiw, okay for me. > > Landry > Unless anyone else objects, I'd like to commit this by Wednesday. Again, I'd be happy yo just leave out the json backend since It's not being enabled now anyways. -- James Turner
[no subject]
espie@openbsd, dera...@cvs.openbsd.org Bcc: Subject: Re: sqlite 3.8.11.1 Reply-To: In-Reply-To: <20150909084510.gh30...@tazenat.gentiane.org> On Wed, Sep 09, 2015 at 08:45:10AM +, Miod Vallat wrote: > > Hi, > > > > thanks to the hard work of jturner@, here's a 650kb gzipped update to > > sqlite 3.8.11.1, bumping shlib to 31.0. This is needed for upcoming > > firefox 41 update, but anyone is welcome to look into the update itself. > > > > Not attaching the diff because of the size, available at > > http://rhaalovely.net/~landry/stuff/sqlite-3.8.11.1.diff.gz > > Do we really need to import lib/libsqlite3/ext/fts5/test/ which amounts > for half of the diff? > To give a little background on why we have all these directories and files based on my understanding... When espie@ imported sqlite he wanted to follow upstream so he imported what was distrubuted with sqlite. Since then we do tagged (based on the sqlite version) imports whenever we do an update. So when a diff is sent out it includes all new files in that sqlite release. In this case there is a new fts5 backend which contains a lot of tests (which we never run). We also haven't enabled the fts5 backend at this time. Now we could change strategies and I could only create a diff of the changes we actually want and then remove all these extra files from our tree and the use commit rather then import going forward. I would be fine with this as it would make each update more manageable but I'm not sure what espie@ original goals where with following upstream. -- James Turner
Re: your mail
On Wed, Sep 09, 2015 at 06:13:11PM +0200, Gilles Chehade wrote: > unrelated to this topic, I suspect your smtpd is fairly old right ? > Running a snapshot from 9/2. > On Wed, Sep 09, 2015 at 11:33:57AM -0400, James Turner wrote: > > espie@openbsd, dera...@cvs.openbsd.org > > Bcc: > > Subject: Re: sqlite 3.8.11.1 > > Reply-To: > > In-Reply-To: <20150909084510.gh30...@tazenat.gentiane.org> > > > > On Wed, Sep 09, 2015 at 08:45:10AM +, Miod Vallat wrote: > > > > Hi, > > > > > > > > thanks to the hard work of jturner@, here's a 650kb gzipped update to > > > > sqlite 3.8.11.1, bumping shlib to 31.0. This is needed for upcoming > > > > firefox 41 update, but anyone is welcome to look into the update itself. > > > > > > > > Not attaching the diff because of the size, available at > > > > http://rhaalovely.net/~landry/stuff/sqlite-3.8.11.1.diff.gz > > > > > > Do we really need to import lib/libsqlite3/ext/fts5/test/ which amounts > > > for half of the diff? > > > > > > > To give a little background on why we have all these directories and > > files based on my understanding... > > > > When espie@ imported sqlite he wanted to follow upstream so he imported > > what was distrubuted with sqlite. Since then we do tagged (based on the > > sqlite version) imports whenever we do an update. So when a diff is sent > > out it includes all new files in that sqlite release. In this case there > > is a new fts5 backend which contains a lot of tests (which we never > > run). We also haven't enabled the fts5 backend at this time. > > > > Now we could change strategies and I could only create a diff of the > > changes we actually want and then remove all these extra files from our > > tree and the use commit rather then import going forward. > > > > I would be fine with this as it would make each update more manageable > > but I'm not sure what espie@ original goals where with following > > upstream. > > > > -- > > James Turner > > > > -- > Gilles Chehade > > https://www.poolp.org @poolpOrg -- James Turner
Re: your mail
On Wed, Sep 09, 2015 at 06:13:11PM +0200, Gilles Chehade wrote: > unrelated to this topic, I suspect your smtpd is fairly old right ? > If this is about my fucked up response I think that was all on me and a failed Mutt reply. > On Wed, Sep 09, 2015 at 11:33:57AM -0400, James Turner wrote: > > espie@openbsd, dera...@cvs.openbsd.org > > Bcc: > > Subject: Re: sqlite 3.8.11.1 > > Reply-To: > > In-Reply-To: <20150909084510.gh30...@tazenat.gentiane.org> > > > > On Wed, Sep 09, 2015 at 08:45:10AM +, Miod Vallat wrote: > > > > Hi, > > > > > > > > thanks to the hard work of jturner@, here's a 650kb gzipped update to > > > > sqlite 3.8.11.1, bumping shlib to 31.0. This is needed for upcoming > > > > firefox 41 update, but anyone is welcome to look into the update itself. > > > > > > > > Not attaching the diff because of the size, available at > > > > http://rhaalovely.net/~landry/stuff/sqlite-3.8.11.1.diff.gz > > > > > > Do we really need to import lib/libsqlite3/ext/fts5/test/ which amounts > > > for half of the diff? > > > > > > > To give a little background on why we have all these directories and > > files based on my understanding... > > > > When espie@ imported sqlite he wanted to follow upstream so he imported > > what was distrubuted with sqlite. Since then we do tagged (based on the > > sqlite version) imports whenever we do an update. So when a diff is sent > > out it includes all new files in that sqlite release. In this case there > > is a new fts5 backend which contains a lot of tests (which we never > > run). We also haven't enabled the fts5 backend at this time. > > > > Now we could change strategies and I could only create a diff of the > > changes we actually want and then remove all these extra files from our > > tree and the use commit rather then import going forward. > > > > I would be fine with this as it would make each update more manageable > > but I'm not sure what espie@ original goals where with following > > upstream. > > > > -- > > James Turner > > > > -- > Gilles Chehade > > https://www.poolp.org @poolpOrg -- James Turner
opensmtpd + acceptable mail
So I'm not quite sure how to explain this but I'm getting similiar emails to the one below and it seems like opensmtpd should be rejecting them as they don't seem like they are a valid format. Have others seen emails like these? Should opensmtpd be rejecting them? -- James Turner From pruitt_albert...@cbetech.com Wed May 6 20:52:33 2015 Return-Path: pruitt_albert...@cbetech.com Delivered-To: ja...@calminferno.net Received: from AY140625164339Z (218.244.157.21 [218.244.157.21]) by soekris.calminferno.net (OpenSMTPD) with SMTP id c1f2ed9d for ja...@calminferno.net; Wed, 6 May 2015 20:52:32 -0400 (EDT)
Re: Macbook Air azalia(4) quirk
On Fri, Apr 24, 2015 at 08:23:01PM -0400, James Turner wrote: The attached diff allows sound to work on my late 2013 Macbook Air (6,1). oks? Ok that diff had lots of typos, please ignore until I can send a new one. Sorry for the noise. -- James Turner
Macbook Air azalia(4) quirk
The attached diff allows sound to work on my late 2013 Macbook Air
(6,1). oks?
--
James Turner
Index: azalia_codec.c
===
RCS file: /cvs/src/sys/dev/pci/azalia_codec.c,v
retrieving revision 1.165
diff -u -p -u -p -r1.165 azalia_codec.c
--- azalia_codec.c 10 Dec 2014 14:18:11 - 1.165
+++ azalia_codec.c 25 Apr 2015 00:06:23 -
@@ -71,6 +71,11 @@ azalia_codec_init_vtbl(codec_t *this)
AZ_QRK_GPIO_UNMUTE_3;
}
break;
+ case 0x10134208:
+ this-name = Cirrus Logic CS4208;
+ if (this-subid == 0x72708086) {/* APPLE_MBA6_1 */
+ this-qrks != AZ_QRK_GPIO_UNMUTE_0;
+ }
case 0x10ec0221:
this-name = Realtek ALC221;
this-qrks |= AZ_QRK_WID_CDIN_1C | AZ_QRK_WID_BEEP_1D;
Re: Macbook Air azalia(4) quirk
On Fri, Apr 24, 2015 at 08:53:44PM -0400, James Turner wrote:
On Fri, Apr 24, 2015 at 08:23:01PM -0400, James Turner wrote:
The attached diff allows sound to work on my late 2013 Macbook Air
(6,1). oks?
Ok that diff had lots of typos, please ignore until I can send a new
one. Sorry for the noise.
Here is the correct typo free version.
--
James Turner
Index: azalia_codec.c
===
RCS file: /cvs/src/sys/dev/pci/azalia_codec.c,v
retrieving revision 1.165
diff -u -p -u -p -r1.165 azalia_codec.c
--- azalia_codec.c 10 Dec 2014 14:18:11 - 1.165
+++ azalia_codec.c 25 Apr 2015 01:17:33 -
@@ -71,6 +71,12 @@ azalia_codec_init_vtbl(codec_t *this)
AZ_QRK_GPIO_UNMUTE_3;
}
break;
+ case 0x10134208:
+ this-name = Cirrus Logic CS4208;
+ if (this-subid == 0x72708086) {/* APPLE_MBA6_1 */
+ this-qrks |= AZ_QRK_GPIO_UNMUTE_0 |
AZ_QRK_GPIO_UNMUTE_1;
+ }
+ break;
case 0x10ec0221:
this-name = Realtek ALC221;
this-qrks |= AZ_QRK_WID_CDIN_1C | AZ_QRK_WID_BEEP_1D;
Re: apmd -C tweak
On Sun, Jul 13, 2014 at 10:06:44AM -0400, Ted Unangst wrote: for reference, i use this. faster query interval and when not idle, slam high immediately. I've been very happy with this change as well. -- James Turner
Re: acpiec(4) clear events on attach and resume
On Fri, Mar 28, 2014 at 11:59:57AM +0200, Paul Irofti wrote:
On Thu, Mar 27, 2014 at 08:33:51PM -0400, James Turner wrote:
I'm running the most recent amd64 snap (3/27) and it sounds like this
diff might be in it?
Also not sure if this diff would affect the reporting of acpi battery
usage but after upgrading my acpibat0 sensors are all over the place.
Initial boot on a plugged in and fully charged battery shows 51%. I let
it drain to 35% and rebooted. With the computer still unplugged it
showed 100%. I then plugged it back in and it jumped back down to 35%.
Does running with this diff manifest the same battery woes?
Things seem to be back to normal with this diff. Battery indicator is
returning the results I would expect.
Index: acpiec.c
===
RCS file: /cvs/src/sys/dev/acpi/acpiec.c,v
retrieving revision 1.48
diff -u -p -r1.48 acpiec.c
--- acpiec.c 2 Jul 2013 18:37:47 - 1.48
+++ acpiec.c 28 Mar 2014 09:57:43 -
@@ -34,6 +34,7 @@
int acpiec_match(struct device *, void *, void *);
void acpiec_attach(struct device *, struct device *, void *);
+int acpiec_activate(struct device *, int);
u_int8_t acpiec_status(struct acpiec_softc *);
u_int8_t acpiec_read_data(struct acpiec_softc *);
@@ -54,6 +55,7 @@ int acpiec_getregister(const u_int8_t *
void acpiec_wait(struct acpiec_softc *, u_int8_t, u_int8_t);
void acpiec_sci_event(struct acpiec_softc *);
+void acpiec_clear_events(struct acpiec_softc *);
void acpiec_get_events(struct acpiec_softc *);
@@ -82,7 +84,8 @@ voidacpiec_unlock(struct acpiec_softc
int acpiec_reg(struct acpiec_softc *);
struct cfattach acpiec_ca = {
- sizeof(struct acpiec_softc), acpiec_match, acpiec_attach
+ sizeof(struct acpiec_softc), acpiec_match, acpiec_attach,
+ NULL, acpiec_activate
};
struct cfdriver acpiec_cd = {
@@ -296,6 +299,8 @@ acpiec_attach(struct device *parent, str
acpi_set_gpehandler(sc-sc_acpi, sc-sc_gpe, acpiec_gpehandler,
sc, 1);
#endif
+
+ /* acpiec_clear_events(sc); */
if (aml_evalname(sc-sc_acpi, sc-sc_devnode, _GLK, 0, NULL, res))
sc-sc_glk = 0;
@@ -307,6 +312,20 @@ acpiec_attach(struct device *parent, str
printf(\n);
}
+int
+acpiec_activate(struct device *self, int act)
+{
+ struct acpiec_softc *sc = (struct acpiec_softc *)self;
+
+
+ switch (act) {
+ case DVACT_RESUME:
+ acpiec_clear_events(sc);
+ break;
+ }
+ return (0);
+}
+
void
acpiec_get_events(struct acpiec_softc *sc)
{
@@ -552,4 +571,18 @@ acpiec_unlock(struct acpiec_softc *sc)
}
sc-sc_ecbusy = 0;
+}
+
+void
+acpiec_clear_events(struct acpiec_softc *sc)
+{
+ int i;
+
+ for (i = 0; i 100; i++) {
+ acpiec_write_cmd(sc, EC_CMD_QR);
+ sc-sc_gotsci = 0;
+ if ((acpiec_status(sc) EC_STAT_SCI_EVT) != EC_STAT_SCI_EVT) {
+ break;
+ }
+ }
}
--
James Turner
Re: acpiec(4) clear events on attach and resume
On Sat, Mar 29, 2014 at 03:51:10AM +0200, Paul Irofti wrote: On Fri, Mar 28, 2014 at 07:14:53PM -0400, James Turner wrote: On Fri, Mar 28, 2014 at 11:59:57AM +0200, Paul Irofti wrote: On Thu, Mar 27, 2014 at 08:33:51PM -0400, James Turner wrote: I'm running the most recent amd64 snap (3/27) and it sounds like this diff might be in it? Also not sure if this diff would affect the reporting of acpi battery usage but after upgrading my acpibat0 sensors are all over the place. Initial boot on a plugged in and fully charged battery shows 51%. I let it drain to 35% and rebooted. With the computer still unplugged it showed 100%. I then plugged it back in and it jumped back down to 35%. Does running with this diff manifest the same battery woes? Things seem to be back to normal with this diff. Battery indicator is returning the results I would expect. Even after a suspend resume cycle? It's important to test resume with this diff. Yes even after suspend/resume things were fine. Before the battery sensors were all over the place even without ever suspending. -- James Turner
Re: acpiec(4) clear events on attach and resume
function 0 Intel Centrino Advanced-N 6030 rev 0x34: msi, MIMO 2T2R, MoW, address 88:53:2e:9a:43:81 ppb2 at pci0 dev 28 function 3 Intel 6 Series PCIE rev 0xb5: msi pci3 at ppb2 bus 3 Fresco Logic FL1009 xHCI rev 0x02 at pci3 dev 0 function 0 not configured ehci1 at pci0 dev 29 function 0 Intel 6 Series USB rev 0x05: apic 14 int 23 usb1 at ehci1: USB revision 2.0 uhub1 at usb1 Intel EHCI root hub rev 2.00/1.00 addr 1 pcib0 at pci0 dev 31 function 0 Intel QS67 LPC rev 0x05 ahci0 at pci0 dev 31 function 2 Intel 6 Series AHCI rev 0x05: msi, AHCI 1.3 scsibus0 at ahci0: 32 targets sd0 at scsibus0 targ 0 lun 0: ATA, SAMSUNG SSD PM83, CXM1 SCSI3 0/direct fixed naa.5002538043584d30 sd0: 122104MB, 512 bytes/sector, 250069680 sectors, thin ichiic0 at pci0 dev 31 function 3 Intel 6 Series SMBus rev 0x05: apic 14 int 18 iic0 at ichiic0 isa0 at pcib0 isadma0 at isa0 pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 pms0 at pckbc0 (aux slot) pckbc0: using irq 12 for aux slot wsmouse0 at pms0 mux 0 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 uhub2 at uhub0 port 1 Intel Rate Matching Hub rev 2.00/0.00 addr 2 uvideo0 at uhub2 port 5 configuration 1 interface 0 CN01RH71724871CHDCTWA00 Laptop_Integrated_Webcam_1.3M rev 2.00/1b.03 addr 3 video0 at uvideo0 uhub3 at uhub1 port 1 Intel Rate Matching Hub rev 2.00/0.00 addr 2 ugen0 at uhub3 port 5 Intel product 0x0189 rev 2.00/69.19 addr 3 vscsi0 at root scsibus1 at vscsi0: 256 targets softraid0 at root scsibus2 at softraid0: 256 targets sd1 at scsibus2 targ 1 lun 0: OPENBSD, SR CRYPTO, 005 SCSI2 0/direct fixed sd1: 122103MB, 512 bytes/sector, 250067198 sectors root on sd1a (91aab9c13da59ddb.a) swap on sd1b dump on sd1b -- James Turner
Re: Use SCRIPT_FILENAME in slowcgi
On Sun, Mar 16, 2014 at 04:01:04PM +, Florian Obser wrote:
On Fri, Mar 07, 2014 at 10:35:37PM -0500, James Turner wrote:
On Fri, Mar 07, 2014 at 11:20:53PM +, Stuart Henderson wrote:
I've been umming and ahhing about this diff, the thing I don't like is
that SCRIPT_FILENAME is an Apache extension rather than part of the
standard CGI variables, which explains why it's not included by
default in nginx (or other servers that people might conceivably
want to use with slowcgi, such as lighttpd).
Still, I don't see a better way to handle this, and replacing Apache
is going to need to support cgis outside of /cgi-bin one way or another.
But I do think it should fallback to using SCRIPT_NAME if the
SCRIPT_FILENAME variable isn't present, so that standard fastcgi
servers can use it to some extent too.
Maybe something like this? Using SCRIPT_FILENAME if present but falling
back on SCRIPT_NAME.
--
James Turner
How about this? I don't see a reason to track SCRIPT_NAME vs.
SCRIPT_FILENAME through the whole daemon. c-script_name is just the
thing that get's execve'ed, it doesn't care where it's comming from.
diff --git slowcgi.c slowcgi.c
index af07bd8..1b467f5 100644
--- slowcgi.c
+++ slowcgi.c
@@ -741,7 +741,11 @@ parse_params(uint8_t *buf, uint16_t n, struct request
*c, uint16_t id)
env_entry-val[name_len] = '\0';
if (val_len MAXPATHLEN strcmp(env_entry-val,
- SCRIPT_NAME) == 0) {
+ SCRIPT_NAME) == 0 c-script_name[0] == '\0') {
+ bcopy(buf, c-script_name, val_len);
+ c-script_name[val_len] = '\0';
+ } else if (val_len MAXPATHLEN strcmp(env_entry-val,
+ SCRIPT_FILENAME) == 0) {
bcopy(buf, c-script_name, val_len);
c-script_name[val_len] = '\0';
}
--
I'm not entirely sure you are real.
I like it. SCRIPT_FILENAME is used when set otherwise it falls back on
SCRIPT_NAME. Works with my test case were I have a cgi script in htdocs
and need to set SCRIPT_FILENAME with something like:
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
and when I use /cgi-bin/ and don't set SCRIPT_FILENAME (current nginx
cgi-bin example).
ok jturner@
--
James Turner
Re: Use SCRIPT_FILENAME in slowcgi
If we want to keep it simple we can just go this route.
On Sat, Mar 01, 2014 at 04:39:49PM -0500, James Turner wrote:
The attached diff uses SCRIPT_FILENAME instead of SCRIPT_NAME to
determine the path of CGI scripts in slowcgi. It also updates the
example in nginx.conf.
According to CGI/1.1:
The SCRIPT_NAME variable MUST be set to a URL path (not URL-encoded)
which could identify the CGI script (rather than the script's
output). The syntax is the same as for PATH_INFO (section 4.1.5)
If you decided to run a CGI script outside of /cgi-bin/ SCRIPT_NAME no
longer matches the path of the CGI script as it is now local to the
document root.
You would need to set something like the following in nginx.conf to make
slowcgi be able to find the CGI script:
fastcgi_param SCRIPT_NAME $document_root$fastcgi_script_name;
However this now violates the CGI/1.1 spec as SCRIPT_NAME is now an
absolute path to the file on disk.
By introducing SCRIPT_FILENAME much like PHP does we can then use:
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
when using CGI scripts outside of cgi-bin and SCRIPT_NAME still
functions as normal.
The /cgi-bin/ example doesn't need $document_root so your pretty much
setting SCRIPT_FILENAME = SCRIPT_NAME which seems redundant but once you
move outside of cgi-bin I believe this is the correct way to go.
--
James Turner
--
James Turner
Index: usr.sbin/slowcgi/slowcgi.c
===
RCS file: /cvs/src/usr.sbin/slowcgi/slowcgi.c,v
retrieving revision 1.27
diff -u -p -u -p -r1.27 slowcgi.c
--- usr.sbin/slowcgi/slowcgi.c 19 Jan 2014 00:01:05 - 1.27
+++ usr.sbin/slowcgi/slowcgi.c 7 Mar 2014 23:02:43 -
@@ -741,7 +741,7 @@ parse_params(uint8_t *buf, uint16_t n, s
env_entry-val[name_len] = '\0';
if (val_len MAXPATHLEN strcmp(env_entry-val,
- SCRIPT_NAME) == 0) {
+ SCRIPT_FILENAME) == 0) {
bcopy(buf, c-script_name, val_len);
c-script_name[val_len] = '\0';
}
Index: usr.sbin/nginx/conf/nginx.conf
===
RCS file: /cvs/src/usr.sbin/nginx/conf/nginx.conf,v
retrieving revision 1.16
diff -u -p -u -p -r1.16 nginx.conf
--- usr.sbin/nginx/conf/nginx.conf 28 Jan 2014 14:48:53 - 1.16
+++ usr.sbin/nginx/conf/nginx.conf 7 Mar 2014 23:02:43 -
@@ -64,6 +64,7 @@ http {
#fastcgi_pass unix:run/slowcgi.sock;
#fastcgi_split_path_info ^(/cgi-bin/[^/]+)(.*);
#fastcgi_param PATH_INFO $fastcgi_path_info;
+#fastcgi_param SCRIPT_FILENAME $fastcgi_script_name;
#includefastcgi_params;
#}
Re: Use SCRIPT_FILENAME in slowcgi
On Fri, Mar 07, 2014 at 11:20:53PM +, Stuart Henderson wrote:
I've been umming and ahhing about this diff, the thing I don't like is
that SCRIPT_FILENAME is an Apache extension rather than part of the
standard CGI variables, which explains why it's not included by
default in nginx (or other servers that people might conceivably
want to use with slowcgi, such as lighttpd).
Still, I don't see a better way to handle this, and replacing Apache
is going to need to support cgis outside of /cgi-bin one way or another.
But I do think it should fallback to using SCRIPT_NAME if the
SCRIPT_FILENAME variable isn't present, so that standard fastcgi
servers can use it to some extent too.
Maybe something like this? Using SCRIPT_FILENAME if present but falling
back on SCRIPT_NAME.
--
James Turner
Index: slowcgi.c
===
RCS file: /cvs/src/usr.sbin/slowcgi/slowcgi.c,v
retrieving revision 1.27
diff -u -p -u -p -r1.27 slowcgi.c
--- slowcgi.c 19 Jan 2014 00:01:05 - 1.27
+++ slowcgi.c 8 Mar 2014 03:33:30 -
@@ -119,6 +119,7 @@ struct request {
struct fcgi_stdin_head stdin_head;
uint16_tid;
charscript_name[MAXPATHLEN];
+ charscript_filename[MAXPATHLEN];
struct env_head env;
int env_count;
pid_t script_pid;
@@ -524,7 +525,7 @@ slowcgi_sig_handler(int sig, short event
create_end_record(c);
c-script_flags |= SCRIPT_DONE;
- ldebug(wait: %s, c-script_name);
+ ldebug(wait: %s, (strlen(c-script_filename) == 0) ?
c-script_name : c-script_filename);
}
if (pid == -1 errno != ECHILD)
lwarn(waitpid);
@@ -745,6 +746,11 @@ parse_params(uint8_t *buf, uint16_t n, s
bcopy(buf, c-script_name, val_len);
c-script_name[val_len] = '\0';
}
+ if (val_len MAXPATHLEN strcmp(env_entry-val,
+ SCRIPT_FILENAME) == 0) {
+ bcopy(buf, c-script_filename, val_len);
+ c-script_filename[val_len] = '\0';
+ }
env_entry-val[name_len] = '=';
bcopy(buf, (env_entry-val) + name_len + 1, val_len);
@@ -848,7 +854,7 @@ exec_cgi(struct request *c)
lerr(1, socketpair);
cgi_inflight--;
c-inflight_fds_accounted = 1;
- ldebug(fork: %s, c-script_name);
+ ldebug(fork: %s, (strlen(c-script_filename) == 0) ? c-script_name :
c-script_filename);
switch (pid = fork()) {
case -1:
@@ -887,15 +893,15 @@ exec_cgi(struct request *c)
close(s_out[1]);
close(s_err[1]);
- argv[0] = c-script_name;
+ argv[0] = (strlen(c-script_filename) == 0) ? c-script_name :
c-script_filename;
argv[1] = NULL;
if ((env = calloc(c-env_count + 1, sizeof(char*))) == NULL)
_exit(1);
SLIST_FOREACH(env_entry, c-env, entry)
env[i++] = env_entry-val;
env[i++] = NULL;
- execve(c-script_name, argv, env);
- lwarn(execve %s, c-script_name);
+ execve((strlen(c-script_filename) == 0) ? c-script_name :
c-script_filename, argv, env);
+ lwarn(execve %s, (strlen(c-script_filename) == 0) ?
c-script_name : c-script_filename);
_exit(1);
}
Re: missing ports.tar.gz in snapshot
On Thu, Mar 06, 2014 at 03:18:38PM +, Devin Ceartas wrote: On Mar 6, 2014, at 3:13 PM, Vijay Sankar vsan...@foretell.ca wrote: Quoting Theo de Raadt dera...@cvs.openbsd.org: is there a reason, why there is no ports.tar.gz in the latest snapshot folder? At present, it is not being built in the ftp area any more. I'd like to ask. Does anyone find it useful? It is not in sync with the packages beside it. Are all the ports in the packages in snapshots? I seem to remember needing to build some of the things I use to test, but maybe that has changed. I use snapshots when I have time to test, so whatever direction you want to give as far as testing goes, just let us know. devin No, not all ports can be distributed as packages due to license restrictions. -- James Turner
Simple static testcgi.c
So I wanted to test out nginx and slowcgi. I started everything up and
hit up localhost/cgi-bin/test-cgi. Whoops forgot to move /bin/sh into
the chroot. Try again, shit forgot to chmod 555 test-cgi.
I was complaining on IRC and tbert suggested I write a simple statically
linked testcgi.c so people can easily verify cgi is up and working.
That is what is attached. It just prints out the environment like
test-cgi and printenv but is statically linked and doesn't require
anything to be copied into the chroot. Also it's 555 by default so it
just works. Is this so bad?
The BINDIR is set since I have no idea where in /usr/src this should
live or if this is even anything we want in source but here it is for
those who don't want to mess around with moving things into the www
chroot and just want to verify cgi (slowcgi in my case) is working.
Tested with both nginx + slowcgi and httpd.
--
James Turner
diff -u -p -N Makefile Makefile
--- MakefileWed Dec 31 19:00:00 1969
+++ MakefileSat Mar 1 14:06:39 2014
@@ -0,0 +1,7 @@
+PROG= testcgi
+SRCS= testcgi.c
+LDSTATIC= -static
+NOMAN= 1
+BINDIR=/var/www/cgi-bin
+
+.include bsd.prog.mk
diff -u -p -N testcgi.c testcgi.c
--- testcgi.c Wed Dec 31 19:00:00 1969
+++ testcgi.c Sat Mar 1 14:15:25 2014
@@ -0,0 +1,42 @@
+/*
+ * This is free and unencumbered software released into the public domain.
+ */
+
+#include stdio.h
+#include stdlib.h
+
+static char *
+cleanenv(char *name)
+{
+ char *env;
+
+ if ((env = getenv(name)) == NULL)
+ return ;
+
+ return env;
+}
+
+int
+main(void)
+{
+ printf(Content-type: text/plain\r\n\r\n);
+ printf(CGI/1.1 test script report:\n\n);
+ printf(GATEWAY_INTERFACE = %s\n, cleanenv(GATEWAY_INTERFACE));
+ printf(SERVER_SOFTWARE = %s\n, cleanenv(SERVER_SOFTWARE));
+ printf(SERVER_PROTOCOL = %s\n, cleanenv(SERVER_PROTOCOL));
+ printf(SERVER_NAME = %s\n, cleanenv(SERVER_NAME));
+ printf(SERVER_ADDR = %s\n, cleanenv(SERVER_ADDR));
+ printf(SERVER_PORT = %s\n, cleanenv(SERVER_PORT));
+ printf(REQUEST_METHOD = %s\n, cleanenv(REQUEST_METHOD));
+ printf(HTTP_ACCEPT = %s\n, cleanenv(HTTP_ACCEPT));
+ printf(SCRIPT_NAME = %s\n, cleanenv(SCRIPT_NAME));
+ printf(REQUEST_URI = %s\n, cleanenv(REQUEST_URI));
+ printf(PATH_INFO = %s\n, cleanenv(PATH_INFO));
+ printf(QUERY_STRING = %s\n, cleanenv(QUERY_STRING));
+ printf(REMOTE_ADDR = %s\n, cleanenv(REMOTE_ADDR));
+ printf(REMOTE_PORT = %s\n, cleanenv(REMOTE_PORT));
+ printf(CONTENT_TYPE = %s\n, cleanenv(CONTENT_TYPE));
+ printf(CONTENT_LENGTH = %s\n, cleanenv(CONTENT_LENGTH));
+
+ return (0);
+}
Re: Simple static testcgi.c
Simplified.
On Sat, Mar 01, 2014 at 02:27:44PM -0500, James Turner wrote:
So I wanted to test out nginx and slowcgi. I started everything up and
hit up localhost/cgi-bin/test-cgi. Whoops forgot to move /bin/sh into
the chroot. Try again, shit forgot to chmod 555 test-cgi.
I was complaining on IRC and tbert suggested I write a simple statically
linked testcgi.c so people can easily verify cgi is up and working.
That is what is attached. It just prints out the environment like
test-cgi and printenv but is statically linked and doesn't require
anything to be copied into the chroot. Also it's 555 by default so it
just works. Is this so bad?
The BINDIR is set since I have no idea where in /usr/src this should
live or if this is even anything we want in source but here it is for
those who don't want to mess around with moving things into the www
chroot and just want to verify cgi (slowcgi in my case) is working.
Tested with both nginx + slowcgi and httpd.
--
James Turner
diff -u -p -N Makefile Makefile
--- MakefileWed Dec 31 19:00:00 1969
+++ MakefileSat Mar 1 14:06:39 2014
@@ -0,0 +1,7 @@
+PROG= testcgi
+SRCS= testcgi.c
+LDSTATIC= -static
+NOMAN= 1
+BINDIR=/var/www/cgi-bin
+
+.include bsd.prog.mk
diff -u -p -N testcgi.c testcgi.c
--- testcgi.c Wed Dec 31 19:00:00 1969
+++ testcgi.c Sat Mar 1 14:41:15 2014
@@ -0,0 +1,43 @@
+/*
+ * This is free and unencumbered software released into the public domain.
+ */
+
+#include stdio.h
+#include stdlib.h
+
+static void
+printenv(char *name)
+{
+ char *env;
+
+ if ((env = getenv(name)) == NULL)
+ env = ;
+
+ printf(%s = %s\n, name, env);
+}
+
+int
+main(void)
+{
+ printf(Content-type: text/plain\r\n\r\n);
+ printf(CGI/1.1 test script report:\n\n);
+
+ printenv(GATEWAY_INTERFACE);
+ printenv(SERVER_SOFTWARE);
+ printenv(SERVER_PROTOCOL);
+ printenv(SERVER_NAME);
+ printenv(SERVER_ADDR);
+ printenv(SERVER_PORT);
+ printenv(REQUEST_METHOD);
+ printenv(HTTP_ACCEPT);
+ printenv(SCRIPT_NAME);
+ printenv(REQUEST_URI);
+ printenv(PATH_INFO);
+ printenv(QUERY_STRING);
+ printenv(REMOTE_ADDR);
+ printenv(REMOTE_PORT);
+ printenv(CONTENT_TYPE);
+ printenv(CONTENT_LENGTH);
+
+ return (0);
+}
Use SCRIPT_FILENAME in slowcgi
The attached diff uses SCRIPT_FILENAME instead of SCRIPT_NAME to
determine the path of CGI scripts in slowcgi. It also updates the
example in nginx.conf.
According to CGI/1.1:
The SCRIPT_NAME variable MUST be set to a URL path (not URL-encoded)
which could identify the CGI script (rather than the script's
output). The syntax is the same as for PATH_INFO (section 4.1.5)
If you decided to run a CGI script outside of /cgi-bin/ SCRIPT_NAME no
longer matches the path of the CGI script as it is now local to the
document root.
You would need to set something like the following in nginx.conf to make
slowcgi be able to find the CGI script:
fastcgi_param SCRIPT_NAME $document_root$fastcgi_script_name;
However this now violates the CGI/1.1 spec as SCRIPT_NAME is now an
absolute path to the file on disk.
By introducing SCRIPT_FILENAME much like PHP does we can then use:
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
when using CGI scripts outside of cgi-bin and SCRIPT_NAME still
functions as normal.
The /cgi-bin/ example doesn't need $document_root so your pretty much
setting SCRIPT_FILENAME = SCRIPT_NAME which seems redundant but once you
move outside of cgi-bin I believe this is the correct way to go.
--
James Turner
Index: usr.sbin/slowcgi/slowcgi.c
===
RCS file: /cvs/src/usr.sbin/slowcgi/slowcgi.c,v
retrieving revision 1.27
diff -u -p -u -p -r1.27 slowcgi.c
--- usr.sbin/slowcgi/slowcgi.c 19 Jan 2014 00:01:05 - 1.27
+++ usr.sbin/slowcgi/slowcgi.c 1 Mar 2014 21:32:03 -
@@ -118,7 +118,7 @@ struct request {
struct fcgi_response_head response_head;
struct fcgi_stdin_head stdin_head;
uint16_tid;
- charscript_name[MAXPATHLEN];
+ charscript_filename[MAXPATHLEN];
struct env_head env;
int env_count;
pid_t script_pid;
@@ -524,7 +524,7 @@ slowcgi_sig_handler(int sig, short event
create_end_record(c);
c-script_flags |= SCRIPT_DONE;
- ldebug(wait: %s, c-script_name);
+ ldebug(wait: %s, c-script_filename);
}
if (pid == -1 errno != ECHILD)
lwarn(waitpid);
@@ -741,9 +741,9 @@ parse_params(uint8_t *buf, uint16_t n, s
env_entry-val[name_len] = '\0';
if (val_len MAXPATHLEN strcmp(env_entry-val,
- SCRIPT_NAME) == 0) {
- bcopy(buf, c-script_name, val_len);
- c-script_name[val_len] = '\0';
+ SCRIPT_FILENAME) == 0) {
+ bcopy(buf, c-script_filename, val_len);
+ c-script_filename[val_len] = '\0';
}
env_entry-val[name_len] = '=';
@@ -848,7 +848,7 @@ exec_cgi(struct request *c)
lerr(1, socketpair);
cgi_inflight--;
c-inflight_fds_accounted = 1;
- ldebug(fork: %s, c-script_name);
+ ldebug(fork: %s, c-script_filename);
switch (pid = fork()) {
case -1:
@@ -887,15 +887,15 @@ exec_cgi(struct request *c)
close(s_out[1]);
close(s_err[1]);
- argv[0] = c-script_name;
+ argv[0] = c-script_filename;
argv[1] = NULL;
if ((env = calloc(c-env_count + 1, sizeof(char*))) == NULL)
_exit(1);
SLIST_FOREACH(env_entry, c-env, entry)
env[i++] = env_entry-val;
env[i++] = NULL;
- execve(c-script_name, argv, env);
- lwarn(execve %s, c-script_name);
+ execve(c-script_filename, argv, env);
+ lwarn(execve %s, c-script_filename);
_exit(1);
}
Index: usr.sbin/nginx/conf/nginx.conf
===
RCS file: /cvs/src/usr.sbin/nginx/conf/nginx.conf,v
retrieving revision 1.16
diff -u -p -u -p -r1.16 nginx.conf
--- usr.sbin/nginx/conf/nginx.conf 28 Jan 2014 14:48:53 - 1.16
+++ usr.sbin/nginx/conf/nginx.conf 1 Mar 2014 21:32:03 -
@@ -64,6 +64,7 @@ http {
#fastcgi_pass unix:run/slowcgi.sock;
#fastcgi_split_path_info ^(/cgi-bin/[^/]+)(.*);
#fastcgi_param PATH_INFO $fastcgi_path_info;
+#fastcgi_param SCRIPT_FILENAME $fastcgi_script_name;
#includefastcgi_params;
#}
Re: upd(4) proposal
On Mon, Feb 17, 2014 at 02:19:42PM +0100, Andre de Oliveira wrote: On Sun, Feb 16, 2014 at 10:28:48PM -0500, James Turner wrote: Forgot to include tech@... Hi Andre, I tested upd(4) with my APC Back-UPS ES 550. It looks like it may only have partial support but figured the report will be helpful nonetheless. I'm currently using NUT for monitoring. Thanks for testing James. Can you send me a few debug info? First you need to enable UPD_DEBUG, be sure upddebug is set to something greater than 9 on upd.c. Let the kernel boots, then plug the device to your usb port, you'll see a few periodic messages, let it run for 10 or 20 seconds 30, save your dmesg output and send it to me. -a Here ya go. upd: vendor=0x51d, product=0x2 upd0 at uhub3 port 2 APC Back-UPS ES 550 FW:843.K2 .D USB FW:K2 rev 1.10/1.06 addr 3 upd: sc_num_sensors=8 upd_attach: complete actlen=02 ptr[0]=0a ptr[1]=03 ptr[2]=00 actlen=02 ptr[0]=0b ptr[1]=02 ptr[2]=00 upd: data read fail actlen=03 ptr[0]=07 ptr[1]=38 ptr[2]=3c upd0: battery nominal volt: hidget data: 0 upd0: battery current volt: hidget data: 0 upd0: battery load: hidget data: 0 upd0: battery charging: hidget data: 0 upd0: battery discharging: hidget data: 0 upd0: battery present: hidget data: -1 upd0: shutdown imminent: hidget data: 0 upd0: acpower present: hidget data: 1 actlen=02 ptr[0]=0a ptr[1]=03 ptr[2]=00 actlen=02 ptr[0]=0b ptr[1]=02 ptr[2]=00 upd: data read fail actlen=03 ptr[0]=07 ptr[1]=38 ptr[2]=3c upd0: battery nominal volt: hidget data: 3000 upd0: battery current volt: hidget data: 2000 upd0: battery load: hidget data: 0 upd0: battery charging: hidget data: 0 upd0: battery discharging: hidget data: 0 upd0: battery present: hidget data: -1 upd0: shutdown imminent: hidget data: 0 upd0: acpower present: hidget data: 1 upd_detach: battery nominal volt upd_detach: battery current volt upd_detach: battery load upd_detach: battery charging upd_detach: battery discharging upd_detach: battery present upd_detach: shutdown imminent upd_detach: acpower present upd_detach: complete upd0 detached -- James Turner
Re: upd(4) proposal
Forgot to include tech@... Hi Andre, I tested upd(4) with my APC Back-UPS ES 550. It looks like it may only have partial support but figured the report will be helpful nonetheless. I'm currently using NUT for monitoring. dmesg: upd0 at uhub3 port 2 APC Back-UPS ES 550 FW:843.K2 .D USB FW:K2 rev 1.10/1.06 addr 3 usbdevs -v: port 1 addr 2: low speed, power 2 mA, config 1, Back-UPS ES 550 FW:843.K2 .D USB FW:K2(0x0002), APC(0x051d), rev 1.06, iSerialNumber 4B1004P9325 sysctl hw.sensors.upd0: hw.sensors.upd0.volt0=0.00 VDC (battery nominal volt) hw.sensors.upd0.volt1=0.00 VDC (battery current volt) hw.sensors.upd0.indicator0=Off (battery charging) hw.sensors.upd0.indicator1=Off (battery discharging) hw.sensors.upd0.indicator2=On (battery present) hw.sensors.upd0.indicator3=Off (shutdown imminent) hw.sensors.upd0.indicator4=On (acpower present) hw.sensors.upd0.percent0=0.00% (battery load) And for comparison here are the numbers from NUT: battery.voltage: 13.5 battery.voltage.nominal: 12.0 battery.charge: 100 ups.status: OL ups.load: 5 -- James Turner
Re: SQLite 3.8.0.2 diff
On Wed, Sep 18, 2013 at 05:56:10PM +0200, Marc Espie wrote: On Thu, Sep 12, 2013 at 02:35:02PM -0400, James Turner wrote: Attached is a diff to update our in tree version of SQLite to the recently released 3.8.0.2. SQLite 3.8.0 is needed for a fossil update I'm working on. I've tested this diff against my fossil update and everything appears to be good, the recent arc4random addition should have been maintained across the diff. This should probably go through a round of bulk builds. I'll express my thanks now for anyone who can assist by running a bulk build on a couple platforms. I'm also okay with this. SQLite 3.8.0.2 has been imported. -- James Turner
Re: SQLite 3.8.0.2 diff
On Sun, Sep 15, 2013 at 11:12:44AM +0200, Landry Breuil wrote: On Thu, Sep 12, 2013 at 02:35:02PM -0400, James Turner wrote: Attached is a diff to update our in tree version of SQLite to the recently released 3.8.0.2. SQLite 3.8.0 is needed for a fossil update I'm working on. I've tested this diff against my fossil update and everything appears to be good, the recent arc4random addition should have been maintained across the diff. This should probably go through a round of bulk builds. I'll express my thanks now for anyone who can assist by running a bulk build on a couple platforms. Doesnt seem to cause any direct fallout in an amd64 bulk build. Thanks for running this against a bulk build. Glad to hear it doesn't seem to have any ill effects. At some poing mozilla will also require 3.8.x, see https://bugzilla.mozilla.org/show_bug.cgi?id=909382. Apparently there are still bugfixes piling on this 3.8.0.x branch.. And note that for mozilla, we might need to turn on the new SQLITE_ALLOW_URI_AUTHORITY define flag at some point for https://bugzilla.mozilla.org/show_bug.cgi?id=879133 . I dont grok all the details here, it seems a windows only issue (profiles on a cifs network drive) but mozilla might require that flag to be set to allow building with systemwide sqlite. Landry -- James Turner
Re: acpi global lock diff that needs testing
); /* XXX - yield/delay? */ } @@ -790,7 +790,7 @@ aml_unlockfield(struct aml_scope *scope, return; /* Release lock */ - st = acpi_release_global_lock(acpi_softc-sc_facs-global_lock); + st = acpi_release_glk(acpi_softc-sc_facs-global_lock); if (!st) return; -- James Turner
Re: pop3 daemon with ssl/tls and STARTTLS, V2
On Thu, Jul 11, 2013 at 12:58:58AM +0530, Sunil Nimmagadda wrote: Second iteration... 1. Fixed CRLF issues in RETR and TOP commands that caused message truncation. 2. Properly byte stuff a line beginning with termination character . . 3. Implemented STLS and CAPA. (STARTTLS RFC 2595) Comments? Source: https://poolp.org/~sunil/pop3d.tar.gz uuencoded gzipped tar file... The new STARTTLS support works like a charm. I would love to see this replace popa3d in base. -- James Turner
Re: pop3 daemon with ssl
On Thu, Jun 27, 2013 at 11:50:48AM +0530, su...@sunilnimmagadda.com wrote: On Wed, Jun 26, 2013 at 09:08:20PM -0400, James Turner wrote: On Wed, Jun 26, 2013 at 08:36:48PM -0400, James Turner wrote: On Thu, Jun 27, 2013 at 12:07:14AM +0530, su...@sunilnimmagadda.com wrote: Hello, This is an implementation of RFC1939 with pop3s(port 995) support out of box. The DESIGN document outlines the processes setup and imsg exchange. It needs a user named _pop3d, a certificate named server.crt in /etc/ssl and its key named server.key in /etc/ssl/private to run. Tested with fdm, fetchmail, getmail, mutt packages and mail clients on Andriod, iPhone and Nokia(symbian). Comments? Source: https://poolp.org/~sunil/pop3d.tar.gz mercurial repository: https://bitbucket.org/nimsun/pop3d/src uuencoded gzipped tar file follows. Just trying things out now. In ssl.c, pop3s.crt and pop3s.key are hard coded in the fatal() calls, those should probably use CERTFILE and KEYFILE respectively. Fixed, thanks. -- James Turner Now that I've had a chance to play with it for a bit a couple things I've ran into. First, if you connect to port 995 with telnet instead of say openssl s_client and issue any command pop3d dies and leaves the following fatal: session lost. Even running ^] from telnet after connecting is enough to cause this behavior. TLS handshake failed with an IO_ERROR, but the daemon shouldn't fatal. Converted it to a log_debug. Second, below is a openssl s_client session. Everything is good up until the point when I issue RETR 1. I then get disconnected with the below message. I'm using a self-signed cert if that matters. openssl s_client -connect localhost:995 CONNECTED(0003) ...lots of cert stuff... +OK pop3d ready USER james +OK PASS notmypassword +OK LIST +OK 1 599 .. Not sure why your message is truncated here while using fdm with pop3d. I could read complete message on Nokia though. Will investigate. Thanks for fixing the first couple of issues, those all look good. The last issue seems to be a problem with openssl and TLSv1 renegotiations. It seems one fix is to use SSL_OP_NO_TLSv1 or we need to apply a similar patch to this one [0] to ssl/s3_pkt.c to ignore the version check during renegotiation. Looks like the [0] fix is in openssl 1.0.1c. [0] http://cvs.openssl.org/chngview?cn=22565 -- James Turner
Re: pop3 daemon with ssl
On Thu, Jun 27, 2013 at 02:14:50PM -0400, James Turner wrote: On Thu, Jun 27, 2013 at 11:50:48AM +0530, su...@sunilnimmagadda.com wrote: On Wed, Jun 26, 2013 at 09:08:20PM -0400, James Turner wrote: On Wed, Jun 26, 2013 at 08:36:48PM -0400, James Turner wrote: On Thu, Jun 27, 2013 at 12:07:14AM +0530, su...@sunilnimmagadda.com wrote: Hello, This is an implementation of RFC1939 with pop3s(port 995) support out of box. The DESIGN document outlines the processes setup and imsg exchange. It needs a user named _pop3d, a certificate named server.crt in /etc/ssl and its key named server.key in /etc/ssl/private to run. Tested with fdm, fetchmail, getmail, mutt packages and mail clients on Andriod, iPhone and Nokia(symbian). Comments? Source: https://poolp.org/~sunil/pop3d.tar.gz mercurial repository: https://bitbucket.org/nimsun/pop3d/src uuencoded gzipped tar file follows. Just trying things out now. In ssl.c, pop3s.crt and pop3s.key are hard coded in the fatal() calls, those should probably use CERTFILE and KEYFILE respectively. Fixed, thanks. -- James Turner Now that I've had a chance to play with it for a bit a couple things I've ran into. First, if you connect to port 995 with telnet instead of say openssl s_client and issue any command pop3d dies and leaves the following fatal: session lost. Even running ^] from telnet after connecting is enough to cause this behavior. TLS handshake failed with an IO_ERROR, but the daemon shouldn't fatal. Converted it to a log_debug. Second, below is a openssl s_client session. Everything is good up until the point when I issue RETR 1. I then get disconnected with the below message. I'm using a self-signed cert if that matters. openssl s_client -connect localhost:995 CONNECTED(0003) ...lots of cert stuff... +OK pop3d ready USER james +OK PASS notmypassword +OK LIST +OK 1 599 .. Not sure why your message is truncated here while using fdm with pop3d. I could read complete message on Nokia though. Will investigate. Thanks for fixing the first couple of issues, those all look good. The last issue seems to be a problem with openssl and TLSv1 renegotiations. It seems one fix is to use SSL_OP_NO_TLSv1 or we need to apply a similar patch to this one [0] to ssl/s3_pkt.c to ignore the version check during renegotiation. Looks like the [0] fix is in openssl 1.0.1c. [0] http://cvs.openssl.org/chngview?cn=22565 -- James Turner OK, I'm sorry the problem is on my end. Because I am testing with openssl s_client and not reading the docs! Because I wasn't using -quiet every time I issued the RETR command it was being interpreted as R which asks the server to renegotiate. After passing -quiet everything works as it should. -- James Turner
Re: Somewhat important ACPI diff
On Mon, May 20, 2013 at 06:57:56PM +0200, Mark Kettenis wrote:
As diagnosed by some other people (armani@, jcs@?) a while ago, our
code to deal with IndexField() operators in our AML interpreter is
quite broken. It works for fields that are less than a byte in size,
but anything else is pretty much completely busted. I wouldn't be
surprised if this is the cause of many ACPI-related problems. One
that comes to mind are the ridiculous temperatures reported by
acpitz(4) that have been plaguing us since basically forever.
I don't have a lot of machines that have AML with IndexField()
operators. I've verified that those return the correct values, but
this defenitely could use further testing on a wide variety of
i386/amd64 hardware please.
No regressions on Dell XPS 13 (L321X). hw.sensors.acpitz0.temp0 and
hw.sensors.acpitz1.temp0 still go from a normal reading (64 degC) to a
somewhat strange reading (27.80 degC) after suspend/resume. A reboot is
needed to get the normal temperature reading back.
hw.sensors.cpu{0-3}.temp0 continue to output correct readings post
suspend/resume.
--
James Turner
Re: Stolen memory
On Thu, Apr 04, 2013 at 11:06:16PM +0200, Mark Kettenis wrote: Machines with Intel integrated graphics have this concept of stolen memory; system memory set aside by the BIOS for use by the graphics chip. On OpenBSD we don't touch that memory since we don't want to step on the BIOS' toes. We also assume that this memory is mapped in the graphics translation table (GTT). So we reserve a block of the size of the stolen memory at the start of the aperture and never use it. On modern machines this strategy doesn't make a lot of sense. The size of the stolen memory can be larger than the graphics aperture, leaving inteldrm(4) no space to map framebuffers and other graphics objects. The diff below gets rid of this policy on Sandy Bridge and Ivy Bridge CPUs, making the full aperture available for use by inteldrm(4). This works fine on my x220, but before I commit this, I'd like to see a little bit more testing. If you have a machine with Intel HD Graphics 2000/3000/2500/4000, please give this diff a try. If possible, test the following: * Check that X still works properly. * Check that suspend/resume still works. (Don't bother if suspend/resume doesn't work without this diff). * Disable the inteldrm driver (boot with the -c option, disable inteldrm at the UKC prompt) and check if the VGA text console still works properly. Thanks, Mark All the above scenerios worked fine on a Dell XPS 13 with Intel HD Graphics 3000. -- James Turner
sys/socket.h __BSD_VISIBLE
I've come across a piece of software that defines __POSIX_C_SOURCE which
causes __BSD_VISIBLE to bet set to 0.
In sys/socket.h if __BSD_VISIBLE is 0 sys/_types.h is included instead
of sys/types.h. This is fine however in three cases we reference
u_int8_t (2) and u_int64_t (1) which requires sys/types.h.
If we change these to __uint8_t and __uint64_t they work with either
types.h or _types.h. Does this make sense? Will there be any side
effects?
--
James Turner
Index: sys/sys/socket.h
===
RCS file: /cvs/src/sys/sys/socket.h,v
retrieving revision 1.82
diff -u -p -r1.82 socket.h
--- sys/sys/socket.h15 Sep 2012 00:47:08 - 1.82
+++ sys/sys/socket.h2 Apr 2013 02:40:46 -
@@ -186,7 +186,7 @@ struct splice {
* addresses.
*/
struct sockaddr {
- u_int8_tsa_len; /* total length */
+ __uint8_tsa_len;/* total length */
sa_family_t sa_family; /* address family */
charsa_data[14];/* actually longer; address value */
};
@@ -204,10 +204,10 @@ struct sockaddr {
* occurrences (including header file) to __ss_len.
*/
struct sockaddr_storage {
- u_int8_tss_len; /* total length */
+ __uint8_t ss_len; /* total length */
sa_family_t ss_family; /* address family */
unsigned char __ss_pad1[6]; /* align to quad */
- u_int64_t __ss_pad2; /* force alignment for stupid compilers
*/
+ __uint64_t __ss_pad2; /* force alignment for stupid compilers
*/
unsigned char __ss_pad3[240]; /* pad to a total of 256 bytes */
};
Re: rthread suspension
On Thu, Mar 21, 2013 at 10:01:42PM -0500, Kurt Miller wrote: On Thursday 21 March 2013 7:47:34 am Brad Smith wrote: On Thu, Mar 21, 2013 at 11:43:15AM +, Stuart Henderson wrote: On 2013/03/21 12:32, Taylan Ulrich B. wrote: Stuart Henderson s...@spacehopper.org writes: As I said, perhaps the uthread workarounds that we used to have in the port got committed upstream and now need to be reverted? i.e. _used_ to have, before the change to rthreads. Oh sorry, I understand now. Indeed, the patches in e.g. 5.0 ports seem equivalent to what is now upstream (although not exactly identical). In your opinion, should upstream Boehm GC try to support pre-rthreads OpenBSD versions as well, or drop that and only support rthreads? (Or do the new patches work for both?) As far as I'm concerned it's not really worth supporting both, but this depends on their usual policies.. Upstream insisted on supporting both. Any way, the new patches will have to be integrated to master. Would anyone like to take that job? If not, I'd like to try, although I don't know how long it would take for me. I don't want that job ;) AFAIK Kurt was talking about this recently and he was working with upstream to have the patches integrated. I stalled on submitting them with upstream. I ran into a snafu. However, I do have an update for boehm-gc that can be tested. There's one i386 machine in my cluster that doesn't behave which is one of the reasons I haven't moved this forward yet. It is on my todo list which I'm chipping away at little by little. -Kurt boehm-gc built and packaged fine on mips64el but all tests failed miserably. -- James Turner
Re: rthread suspension
On Fri, Mar 22, 2013 at 11:19:43PM -0400, James Turner wrote: On Fri, Mar 22, 2013 at 10:05:49PM -0500, Kurt Miller wrote: On Friday 22 March 2013 4:08:47 pm James Turner wrote: On Thu, Mar 21, 2013 at 10:01:42PM -0500, Kurt Miller wrote: [snip] I stalled on submitting them with upstream. I ran into a snafu. However, I do have an update for boehm-gc that can be tested. There's one i386 machine in my cluster that doesn't behave which is one of the reasons I haven't moved this forward yet. It is on my todo list which I'm chipping away at little by little. -Kurt boehm-gc built and packaged fine on mips64el but all tests failed miserably. Thanks for the report. Does the 7.0 one in ports current work or fail too? -Kurt It's currently marked as NOT_FOR_ARCHS. The current version does build, but fails all tests as well. So no change really and probably not worth removing from NOT_FOR_ARCHS. -- James Turner Sent this to ports@ by mistake. Moving back to tech@. -- James Turner
Re: add intel 6235 support to iwn(4)
On Wed, Jan 09, 2013 at 04:12:23PM +, Richard N wrote:
Mark Kettenis mark.kettenis at xs4all.nl writes:
Date: Tue, 13 Nov 2012 21:02:24 -0500
From: James Turner james at calminferno.net
I was actually able to add support myself with the following diff.
Great!
Committed an improved diff that also adds the other 6030 variant.
Index: if_iwn.c
===
RCS file: /cvs/src/sys/dev/pci/if_iwn.c,v
retrieving revision 1.115
diff -u -p if_iwn.c
--- if_iwn.c 11 Nov 2012 20:45:31 - 1.115
+++ if_iwn.c 14 Nov 2012 02:00:52 -
@@ -639,7 +639,8 @@ iwn5000_attach(struct iwn_softc *sc, pci_product_id_t
break;
case IWN_HW_REV_TYPE_6005:
sc-limits = iwn6000_sensitivity_limits;
- if (pid == PCI_PRODUCT_INTEL_WL_6235_1) {
+ if (pid == PCI_PRODUCT_INTEL_WL_6235_1 ||
+ pid == PCI_PRODUCT_INTEL_WL_6030_2) {
sc-fwname = iwn-6030;
/* XXX: The 6235 generates a fatal firmware error when
--
Thankyou for all the above info
I am interested in purchasing a Laptop which will unfortunately have the
Intel
Centrino Advanced-N 6235 + Bluetooth Combo Module
I assume, in an earlier post, that someone disabled bluetooth (in their
BIOS), and then the iwn0 firmware/driver had worked flawlessly. ?
I'm sorry for interrupting here, but I just wanted to confirm, that in
OpenBSD
5.2 Official (Stable) Release , that this in fact is still the case. ?
Either way, I do NOT plan on using Bluetooth on my laptop.
Thanks for all your efforts as well.
Rick.
Rick,
I did not have to disable BT in my bios, the driver it self
disables/skips over it I believe.
This commit was made to cvs after 5.2 was released so you will need to
run a snapshot or follow -current instead.
--
James Turner
www/events.html future events year fix
Future events year should be 2013. -- James Turner | 0x560B0C49 --- events.html.origSat Jan 5 14:53:23 2013 +++ events.html Sat Jan 5 14:52:15 2013 @@ -38,7 +38,7 @@ like-minded people. h2Future events:/h2 -h32012/h3 +h32013/h3 ul listronga name=bsddayeu2013/a
Problems compiling libsqlite3
I'm trying to build the latest libsqlite3 in tree and am running into a number of problems. First I want to make sure I'm following the correct build procedure. In lib/libsqlite3 I'm running make obj make depend make During make I get the following build failure on amd64: /usr/src/lib/libsqlite3/src/btree.c: In function 'sqlite3BtreeOpen': /usr/src/lib/libsqlite3/src/btree.c:1790: error: too many arguments to function 'sqlite3PagerFilename' /usr/src/lib/libsqlite3/src/btree.c: In function 'sqlite3BtreeGetFilename': /usr/src/lib/libsqlite3/src/btree.c:8063: error: too many arguments to function 'sqlite3PagerFilename' *** Error 1 in /usr/src/lib/libsqlite3 (bsd.lib.mk:37 'btree.o': @cc -O2 -pipe -g -I/usr/src/lib/libsqlite3/obj -I/usr/src/lib/libsqlite... The problem is in pager.h, sqlite3PagerFilename's prototype hasn't been updated to accept a second parameter. It should be: -const char *sqlite3PagerFilename(Pager*); +const char *sqlite3PagerFilename(Pager*, int); With that fix the build get's a bit farther but then it fails with this: /usr/src/lib/libsqlite3/src/callback.c:332: error: conflicting types for 'sqlite3FindFunction' /usr/src/lib/libsqlite3/src/sqliteInt.h:2863: error: previous declaration of 'sqlite3FindFunction' was here *** Error 1 in /usr/src/lib/libsqlite3 (bsd.lib.mk:37 'callback.o': @cc -O2 -pipe -g -I/usr/src/lib/libsqlite3/obj -I/usr/src/lib/libsql...) So, I'm just wondering if anyone is able to build libsqlite3 on amd64 or is it just me? Thanks. -- James Turner ja...@calminferno.net
Re: Problems compiling libsqlite3
On Sun, Dec 02, 2012 at 05:07:47PM +, Miod Vallat wrote: I'm trying to build the latest libsqlite3 in tree and am running into a number of problems. First I want to make sure I'm following the correct build procedure. In lib/libsqlite3 I'm running make obj make depend make During make I get the following build failure on amd64: You forgot to make includes before attempting to build the library. Miod So I did: make obj make depend make includes make and am still receiving the same build errors. I'd normally just wait for a new snapshot, but now I want to make sure the build isn't broken. As long as developers aren't seeing a problem, thats good enough for me. -- James Turner ja...@calminferno.net
Re: Problems compiling libsqlite3
On Sun, Dec 02, 2012 at 09:21:02PM +, Nigel Taylor wrote: So I did: make obj make depend make includes make and am still receiving the same build errors. I'd normally just wait for a new snapshot, but now I want to make sure the build isn't broken. As long as developers aren't seeing a problem, thats good enough for me. I built both amd64/i386 releases without problems yesterday, and two days before after libsqlight3 was updated. However I built the whole userland as part of the release not just a small part. Good to know, thanks. I'm probably missing a step by just trying to compile libsqlite3. I'll just wait for a new snapshot. Thanks for confirming that the build is clearly not broken. -- James Turner ja...@calminferno.net
Re: add intel 6235 support to iwn(4)
I was actually able to add support myself with the following diff.
--
James Turner
ja...@calminferno.net
Index: if_iwn.c
===
RCS file: /cvs/src/sys/dev/pci/if_iwn.c,v
retrieving revision 1.115
diff -u -p if_iwn.c
--- if_iwn.c11 Nov 2012 20:45:31 - 1.115
+++ if_iwn.c14 Nov 2012 02:00:52 -
@@ -639,7 +639,8 @@ iwn5000_attach(struct iwn_softc *sc, pci_product_id_t
break;
case IWN_HW_REV_TYPE_6005:
sc-limits = iwn6000_sensitivity_limits;
- if (pid == PCI_PRODUCT_INTEL_WL_6235_1) {
+ if (pid == PCI_PRODUCT_INTEL_WL_6235_1 ||
+ pid == PCI_PRODUCT_INTEL_WL_6030_2) {
sc-fwname = iwn-6030;
/* XXX: The 6235 generates a fatal firmware error when
mg(1) allow no-tab-mode to compile
Attached is a diff to allow no-tab-mode to compile. It's basically the
same as a diff sent to this list around 2 years ago minus enabling this
mode by default.
--
James Turner
ja...@calminferno.net
Index: cmode.c
===
RCS file: /cvs/src/usr.bin/mg/cmode.c,v
retrieving revision 1.7
diff -u -p cmode.c
--- cmode.c 18 Jan 2011 17:35:42 - 1.7
+++ cmode.c 16 May 2012 19:48:03 -
@@ -243,7 +243,7 @@ getindent(const struct line *lp, int *curi)
break;
if (c == '\t'
#ifdef NOTAB
-!(curbp-b_flag BFNOTAB)
+!(curbp-b_flag BFNOTAB)
#endif /* NOTAB */
) {
nicol |= 0x07;
Index: random.c
===
RCS file: /cvs/src/usr.bin/mg/random.c,v
retrieving revision 1.30
diff -u -p random.c
--- random.c21 Jan 2011 19:10:13 - 1.30
+++ random.c16 May 2012 19:48:03 -
@@ -378,7 +378,7 @@ indent(int f, int n)
(void)gotobol(FFRAND, 1);
if (
#ifdef NOTAB
- curbp-b_flag BFNOTAB) ? linsert(n, ' ') == FALSE :
+ (curbp-b_flag BFNOTAB) ? linsert(n, ' ') == FALSE :
#endif /* NOTAB */
(((i = n / 8) != 0 linsert(i, '\t') == FALSE) ||
((i = n % 8) != 0 linsert(i, ' ') == FALSE)))
spamd.8 patch
I was just setting up spamd in blacklist mode on the latest snap and discovered the man page is missing the in between pass on. Diff attached. Index: spamd.8 === RCS file: /cvs/src/libexec/spamd/spamd.8,v retrieving revision 1.117 diff -u -p -r1.117 spamd.8 --- spamd.8 17 Sep 2009 06:37:54 - 1.117 +++ spamd.8 18 Mar 2011 23:09:43 - @@ -477,7 +477,7 @@ Any other addresses are passed to the real MTA. .Bd -literal -offset 4n table \*(Ltspamd\*(Gt persist -pass on egress proto tcp from \*(Ltspamd\*(Gt to any \e +pass in on egress proto tcp from \*(Ltspamd\*(Gt to any \e port smtp rdr-to 127.0.0.1 port spamd .Ed .Pp
