Fw: Documento em anexo..
Segue em anexo conforme solicitado o relatorio e as cotagues de pregos e produtos listados a seguir. Tenha um bom dia! Arquivo: anexo-documento.doc (155,1 KB) Agredecemos a sua preferencia.
Re: pf.conf, comments and continuation lines
anyone?
On 05/19/2011 03:31 PM, Florian Obser wrote:
> Hi,
>
> I'm not sure if this is a bug or a feature. Consider the following pf.conf:
>
> # foo
> # bar
>
> #pass out \
> pass out log \
> label "foo#bar"\
> tag "FOO#BAZ"
>
>
> pass out \
> label "foo#bar"\
> tag FOO#BAZ
>
> # /sbin/pfctl -vv -nf /home/florian/pf.conf
> @0 pass out all flags S/SA keep state label "foo#bar" tag FOO
>
> The comment "#pass out \" continues to tag "FOO#BAZ" and the first rule is
> removed.
>
> If this is considered a bug the attached patch fixes this:
>
> # /usr/src/sbin/pfctl/obj/pfctl -vv -nf /home/florian/pf.conf
> @0 pass out log all flags S/SA keep state label "foo#bar" tag FOO#BAZ
> @1 pass out all flags S/SA keep state label "foo#bar" tag FOO
>
> The patch contains fixes for all parse.y mentioned in
>
> http://marc.info/?l=openbsd-cvs&m=128086103506497&w=2
>
> Additionally there is a patch for parse.y for xenocara app/cwm, mentioned
> here: http://marc.info/?l=openbsd-cvs&m=128544524209247&w=2
>
> I currently have no build infrastructure for xenocara and don't use cwm so
> that patch is completly untested.
>
> Base compiles with the patch and we tested pfctl and bgpd, with help
> from Sebastian Benoit who tested bgpd.
>
> Note that this patch might change the behaviour of pf and all the
> other daemons.
>
> If it is a feature, note that pf.conf(5) talks about comments:
> Comments can be put anywhere in the file using a hash mark (`#'), and
> extend to the end of the current line.
>
> but doesn't explain the semantics of continuation lines. I don't feel
> qualified to provide a patch for pf.conf(5).
>
> ~ Florian
>
> Index: sbin/iked/parse.y
> ===
> RCS file: /cvs/src/sbin/iked/parse.y,v
> retrieving revision 1.21
> diff -u -r1.21 parse.y
> --- sbin/iked/parse.y 18 Apr 2011 08:45:43 - 1.21
> +++ sbin/iked/parse.y 18 May 2011 22:33:34 -
> @@ -1132,6 +1132,10 @@
> return (EOF);
> c = getc(file->stream);
> }
> +
> + if (c == '#')
> + while ((c = getc(file->stream)) != '\n' && c != EOF)
> + ; /* nothing */
> return (c);
> }
>
> @@ -1188,9 +1192,6 @@
> ; /* nothing */
>
> yylval.lineno = file->lineno;
> - if (c == '#')
> - while ((c = lgetc(0)) != '\n' && c != EOF)
> - ; /* nothing */
> if (c == '$' && parsebuf == NULL) {
> while (1) {
> if ((c = lgetc(0)) == EOF)
> Index: sbin/ipsecctl/parse.y
> ===
> RCS file: /cvs/src/sbin/ipsecctl/parse.y,v
> retrieving revision 1.150
> diff -u -r1.150 parse.y
> --- sbin/ipsecctl/parse.y 6 Oct 2010 22:19:20 - 1.150
> +++ sbin/ipsecctl/parse.y 18 May 2011 22:33:40 -
> @@ -1036,6 +1036,10 @@
> return (EOF);
> c = getc(file->stream);
> }
> +
> + if (c == '#')
> + while ((c = getc(file->stream)) != '\n' && c != EOF)
> + ; /* nothing */
> return (c);
> }
>
> @@ -1092,9 +1096,6 @@
> ; /* nothing */
>
> yylval.lineno = file->lineno;
> - if (c == '#')
> - while ((c = lgetc(0)) != '\n' && c != EOF)
> - ; /* nothing */
> if (c == '$' && parsebuf == NULL) {
> while (1) {
> if ((c = lgetc(0)) == EOF)
> Index: sbin/pfctl/parse.y
> ===
> RCS file: /cvs/src/sbin/pfctl/parse.y,v
> retrieving revision 1.599
> diff -u -r1.599 parse.y
> --- sbin/pfctl/parse.y6 Apr 2011 13:19:55 - 1.599
> +++ sbin/pfctl/parse.y18 May 2011 22:33:51 -
> @@ -5226,6 +5226,10 @@
> return (EOF);
> c = getc(file->stream);
> }
> +
> + if (c == '#')
> + while ((c = getc(file->stream)) != '\n' && c != EOF)
> + ; /* nothing */
> return (c);
> }
>
> @@ -5282,9 +5286,6 @@
> ; /* nothing */
>
> yylval.lineno = file->lineno;
> - if (c == '#')
> - while ((c = lgetc(0)) != '\n' && c != EOF)
> - ; /* nothing */
> if (c == '$' && parsebuf == NULL) {
> while (1) {
> if ((c = lgetc(0)) == EOF)
> Index: usr.sbin/bgpd/parse.y
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/parse.y,v
> retrieving revision 1.259
> diff -u -r1.259 parse.y
> --- usr.sbin/bgpd/parse.y 1 May 2011 12:56:04 - 1.259
> +++ usr.sbin/bgpd/parse.y 18 May 2011 22:33:58 -
> @@ -2261,6 +2261,10 @@
> return (EOF);
> c = getc(file->stream);
> }
> +
> + if (c == '#')
> + while ((c
Re: pf.conf, comments and continuation lines
On 2011/06/14 09:33, Florian Obser wrote: > anyone? This is just how it works. http://thread.gmane.org/gmane.os.openbsd.misc/144553/focus=144586 > > but doesn't explain the semantics of continuation lines. I don't feel > > qualified to provide a patch for pf.conf(5). How about this? I tried a few wordings to explain it but none were right, so it seems clearest with an example. Lines can be joined using a backslash (`\'), for example: pass log proto tcp \ to port http # this \ is all one \ line. Index: pf.conf.5 === RCS file: /cvs/src/share/man/man5/pf.conf.5,v retrieving revision 1.494 diff -u -p -r1.494 pf.conf.5 --- pf.conf.5 20 May 2011 22:57:20 - 1.494 +++ pf.conf.5 14 Jun 2011 08:54:26 - @@ -72,6 +72,16 @@ keyword, for example: include "/etc/pf/sub.filter.conf" .Ed .Pp +Lines can be joined using a backslash +.Pq Sq \e , +for example: +.Bd -literal -offset indent +pass log proto tcp \e +to port http # this \e +is all one \e +line. +.Ed +.Pp Macros can be defined that will later be expanded in context. Macro names must start with a letter, and may contain letters, digits and underscores.
Toshiba M30 ACPI support
Hello Everybody,
I installed OpenBSD 4.9 current in my old Toshiba M30. Although,
there was not LCD brightness control, so I started to do something
about
it, taking into account the Toshiba acpi support of FreeBSD.
http://fxr.watson.org/fxr/source/dev/acpi_support/acpi_toshiba.c
Successfully, I can manage the LCD brightness level using wsconsctl(8).
wsconsctl display.brightness=100. ;) works nicely by command
line as well by setting the brightness level in /etc/wsconsctl.conf
file.
I attached the required patch files for testing. I hope can be
useful for other guys using toshiba laptops as I added the
Libretto and Dynabook models.
Thanks to Paul for coaching me to provide a decent patch :).
Greatings,
Javier.
/*-
* Copyright (c) 2003 Hiroyuki Aizu
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in the
*documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
/*
* Toshiba HCI interface definitions
*
* HCI is Toshiba's "Hardware Control Interface" which is supposed to
* be uniform across all their models. Ideally we would just call
* dedicated ACPI methods instead of using this primitive interface.
* However, the ACPI methods seem to be incomplete in some areas (for
* example they allow setting, but not reading, the LCD brightness
* value), so this is still useful.
*/
#define METHOD_HCI "GHCI"
#define METHOD_HCI_ENABLE "ENAB"
/* Operations */
#define HCI_SET 0xFF00
#define HCI_GET 0xFE00
/* Functions */
#define HCI_REG_SYSTEM_EVENT0x0016
#define HCI_REG_VIDEO_OUTPUT0x001C
#define HCI_REG_LCD_BRIGHTNESS 0x002A
/* Field definitions */
#define HCI_LCD_BRIGHTNESS_BITS 3
#define HCI_LCD_BRIGHTNESS_SHIFT(16 - HCI_LCD_BRIGHTNESS_BITS)
#define HCI_LCD_BRIGHTNESS_MAX ((1 << HCI_LCD_BRIGHTNESS_BITS) - 1)
#define HCI_LCD_BRIGHTNESS_MIN 0
#define HCI_VIDEO_OUTPUT_FLAG 0x0100
#define HCI_VIDEO_OUTPUT_CYCLE_MIN 0
#define HCI_VIDEO_OUTPUT_CYCLE_MAX 7
/* HCI register definitions */
#define HCI_WORDS 6 /* Number of register */
#define HCI_REG_AX 0 /* Operation, then return value */
#define HCI_REG_BX 1 /* Function */
#define HCI_REG_CX 2 /* Argument (in or out) */
/* Return codes */
#define HCI_FAILURE-1
#define HCI_SUCCESS 0
/* Toshiba fn_keys events */
#define FN_KEY_VIDEO_OUTPUT 0x01BF
#define FN_KEY_BRIGHTNESS_DOWN 0x01C0
#define FN_KEY_BRIGHTNESS_UP0x01C1
struct acpitoshiba_softc {
struct devicesc_dev;
struct acpi_softc *sc_acpi;
struct aml_node *sc_devnode;
};
int toshiba_enable_events(struct acpitoshiba_softc *);
int toshiba_read_events(struct acpitoshiba_softc *);
int toshiba_match(struct device *, void *, void *);
voidtoshiba_attach(struct device *, struct device *, void *);
int toshiba_hotkey(struct aml_node *, int, void *);
int toshiba_get_brightness(struct acpitoshiba_softc *, u_int32_t *);
int toshiba_set_brightness(struct acpitoshiba_softc *, u_int32_t *);
int toshiba_get_video_output(struct acpitoshiba_softc *, u_int32_t *);
int toshiba_set_video_output(struct acpitoshiba_softc *, u_int32_t *);
int toshiba_find_brightness(struct acpitoshiba_softc *, int *);
int toshiba_fn_key_brightness_up(struct acpitoshiba_softc *);
int toshiba_fn_key_brightness_down(struct acpitoshiba_softc *);
int toshi
Mobee ürünleri şimdi tüm Darty mağazalarında kampanyada!
2 boyutlu oyunlar haricinde 3 boyutlu oyunlar} oynatabilme vzellipidir. Bu vzellikle sayesinde oyunlar}n igine girmi~cesine bir hisle oyun oynanabilir Mobee'nin son reklam filmini izlemek igin t}klay}n}z. Yasal Uyar} Mobee, bu internet sitesinin igerdipi bilgilerin dopru ve g|ncellenmi~ olmas}na b|y|k vnem verir. Ancak, baz} hatalar gvzden kagm}~ olabilir ve siz deperli ziyaretgilerimizin, gerekli bilgi hakk}nda(fiyat, teknik vzellikler gibi) kesin emin olmak igin bizimle irtibata gegmenizi tavsiye ederiz. G|ncelleme hatalar} Mobee igin baplay}c} depildir. Mobee, link verdipi sitelerin igeripinin t|m|n| incelememi~tir. Link verilen sitelerin igeripinden Mobee sorumlu depildir. www.mobee.com.tr sitelerine d}~ar}dan gvnderilen her hangi bir dosya veya bilgi gizli depildir, ve bu ~ekilde i~lem gvrecektir. Bu t|r bilgiler Mobee taraf}ndan saklanabilir, sergilenebilir, depi~tirilebilir, aktar}labilir dap}t}labilir ve Mobee grup ~irketleri ile geli~tirme veya pazarlama gibi sebeplerden dolay} payla~}labilir. Bu sitede payla~}lan her t|rl| bilgi ve ya dosyalar}n (ses, gvr|nt|, yaz}) telif haklar} Mobee, ilgili markalar ve belgelerin orijinal yarat}c}s}na aittir. Bu belgeler yaln}zca sahiplerinin izni ile kullan}lmaktad}r. Bu sitede payla~}lan higbir belge ve bilgi izinsiz kopyalanamaz, |zerlerinde depi~iklik yap}lamaz, kiralanamaz, vd|ng verilemez, iletilemez ve yay}nlanamaz. Bu siteden al}nan her t|rl| ses, gvr|nt|, yaz} igeren higbir bilgi ve belge sat}lamaz veya herhangi bir kbr amac}yla dap}t}lamaz. Ticari kullan}m harici, sadece ki~isel kullan}m igin belgelerin, bilgilerin ve gvr|nt|lerin gvr|nt|lenmesi, kopyalanmas}, dap}t}lmas} ve indirilmesine izin verilmi~tir. Higbir ~ekilde modifiye edilemez ve depi~tirilemez. Bu site igerinde kullan}lan logolar ve sloganlar, ayr}ca bulunan b|t|n markalar, |r|n ve model isimleri Mobee'nin m|seccel veya m|seccel olmayan markalar}d}r. ]zin al}nmadan bu logolar ve sloganlar bilgi dap}t}m} veya reklam amagl} kullan}lamaz. Mobee, Mobee logosu, mobee.com.tr T|rkiye'de m|seccel markalard}r. Bu e-b|lteni Mobee veritaban}nda oldupunuz igin ald}n}z. Eper bu e-b|ltenin istepiniz d}~}nda gvnderildipini d|~|n|yorsan}z l|tfen |yelikten g}k}~ igin t}klay}n}z. If you wish to be removed from our list, click unsubscribe
Re: pf.conf, comments and continuation lines
On Tue, Jun 14, 2011 at 09:59:22AM +0100, Stuart Henderson wrote: > On 2011/06/14 09:33, Florian Obser wrote: > > anyone? > > This is just how it works. > > http://thread.gmane.org/gmane.os.openbsd.misc/144553/focus=144586 > > > > but doesn't explain the semantics of continuation lines. I don't feel > > > qualified to provide a patch for pf.conf(5). > > How about this? I tried a few wordings to explain it but none > were right, so it seems clearest with an example. > > Lines can be joined using a backslash (`\'), for example: > >pass log proto tcp \ >to port http # this \ >is all one \ >line. > i'm surprised we don;t actually document that. i guess it's something that you instinctively understand, especially since the whole page uses this notation. if you want to document it, i'd prefer to try and tuck it in nice and neat, without an example. how about rearranging the section to something like this: Comments can be put anywhere in the file using a hash mark (`#'), and extend to the end of the current line. The current line itself can be extended using a backslash (`\'). Additional configuration files can be included with the include keyword, for example: include "/etc/pf/sub.filter.conf" ... that would be just a one line addition. i'd prefer to try and keep this little blurb short, as i think we should expect readers to understand the idea of `#' as comments, and `\' as extending the current line. also note that this specific bit of text tends to get pasted into a lot of pages, so we want to keep it simple (and a diff to this page may not be enough - we might need to update all the stuff that uses the same parser). jmc
Re: Toshiba M30 ACPI support
On Tue, Jun 14, 2011 at 6:38 AM, Javier Vazquez wrote:
> Hello Everybody,
>
>I installed OpenBSD 4.9 current in my old Toshiba M30. Although,
>there was not LCD brightness control, so I started to do something
about
>it, taking into account the Toshiba acpi support of FreeBSD.
>http://fxr.watson.org/fxr/source/dev/acpi_support/acpi_toshiba.c
>
>Successfully, I can manage the LCD brightness level using
wsconsctl(8).
>
>wsconsctl display.brightness=100. ;) works nicely by command
>line as well by setting the brightness level in /etc/wsconsctl.conf
file.
>
>I attached the required patch files for testing. I hope can be
>useful for other guys using toshiba laptops as I added the
>Libretto and Dynabook models.
>
>Thanks to Paul for coaching me to provide a decent patch :).
>
> Greatings,
> Javier.
> /*-
> * Copyright (c) 2003 Hiroyuki Aizu
> * All rights reserved.
> *
> * Redistribution and use in source and binary forms, with or without
> * modification, are permitted provided that the following conditions
> * are met:
> * 1. Redistributions of source code must retain the above copyright
> *notice, this list of conditions and the following disclaimer.
> * 2. Redistributions in binary form must reproduce the above copyright
> *notice, this list of conditions and the following disclaimer in the
> *documentation and/or other materials provided with the distribution.
> *
> * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
> * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE
> * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
> * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL
> * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
> * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
> * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
STRICT
> * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY
WAY
> * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
> * SUCH DAMAGE.
> *
> */
> #include
> #include
> #include
>
> #include
> #include
> #include
> #include
> #include
>
> #include
> #include
>
> /*
> * Toshiba HCI interface definitions
> *
> * HCI is Toshiba's "Hardware Control Interface" which is supposed to
> * be uniform across all their models. Ideally we would just call
> * dedicated ACPI methods instead of using this primitive interface.
> * However, the ACPI methods seem to be incomplete in some areas (for
> * example they allow setting, but not reading, the LCD brightness
> * value), so this is still useful.
> */
> #define METHOD_HCI "GHCI"
> #define METHOD_HCI_ENABLE "ENAB"
>
> /* Operations */
> #define HCI_SET 0xFF00
> #define HCI_GET 0xFE00
>
> /* Functions */
> #define HCI_REG_SYSTEM_EVENT0x0016
> #define HCI_REG_VIDEO_OUTPUT0x001C
> #define HCI_REG_LCD_BRIGHTNESS 0x002A
>
> /* Field definitions */
> #define HCI_LCD_BRIGHTNESS_BITS 3
> #define HCI_LCD_BRIGHTNESS_SHIFT(16 - HCI_LCD_BRIGHTNESS_BITS)
> #define HCI_LCD_BRIGHTNESS_MAX ((1 << HCI_LCD_BRIGHTNESS_BITS) -
1)
> #define HCI_LCD_BRIGHTNESS_MIN 0
> #define HCI_VIDEO_OUTPUT_FLAG 0x0100
> #define HCI_VIDEO_OUTPUT_CYCLE_MIN 0
> #define HCI_VIDEO_OUTPUT_CYCLE_MAX 7
>
> /* HCI register definitions */
> #define HCI_WORDS 6 /* Number of register */
> #define HCI_REG_AX 0 /* Operation, then return value
*/
> #define HCI_REG_BX 1 /* Function */
> #define HCI_REG_CX 2 /* Argument (in or out) */
>
> /* Return codes */
> #define HCI_FAILURE-1
> #define HCI_SUCCESS 0
>
> /* Toshiba fn_keys events */
> #define FN_KEY_VIDEO_OUTPUT 0x01BF
> #define FN_KEY_BRIGHTNESS_DOWN 0x01C0
> #define FN_KEY_BRIGHTNESS_UP0x01C1
>
> struct acpitoshiba_softc {
>struct devicesc_dev;
>struct acpi_softc *sc_acpi;
>struct aml_node *sc_devnode;
> };
>
> int toshiba_enable_events(struct acpitoshiba_softc *);
> int toshiba_read_events(struct acpitoshiba_softc *);
> int toshiba_match(struct device *, void *, void *);
> voidtoshiba_attach(struct device *, struct device *, void *);
> int toshiba_hotkey(struct aml_node *, int, void *);
> int toshiba_get_brightness(struct acpitoshiba_softc *, u_int32_t *);
> int toshiba_set_brightness(struct acpitoshiba_softc *, u_int32_t *);
> int toshiba_get_video_output(struct acpitoshiba_softc *, u_int32_t *);
> int toshiba_set_video_ou
Re: Toshiba M30 ACPI support
On Tue, Jun 14, 2011 at 11:38:45AM +0200, Javier Vazquez wrote: > Hello Everybody, > > I installed OpenBSD 4.9 current in my old Toshiba M30. Although, > there was not LCD brightness control, so I started to do something > about > it, taking into account the Toshiba acpi support of FreeBSD. > http://fxr.watson.org/fxr/source/dev/acpi_support/acpi_toshiba.c > > Successfully, I can manage the LCD brightness level using wsconsctl(8). > > wsconsctl display.brightness=100. ;) works nicely by command > line as well by setting the brightness level in /etc/wsconsctl.conf > file. > > I attached the required patch files for testing. I hope can be > useful for other guys using toshiba laptops as I added the > Libretto and Dynabook models. > > Thanks to Paul for coaching me to provide a decent patch :). You should have done: $ cd /sys/dev/acpi $ cvs add acpitoshiba.c $ cd /sys $ cvs diff -uNp So that you can supply one easy patch for people to test. Also, the comment about the && instead of || is correct. People with Toshiba's should test this and report back if this works for them or not. The 'WARN: not a buffer' AML message is a known issue and jordan@ is looking into it.
Re: pf.conf, comments and continuation lines
On 06/14/2011 12:54 PM, Jason McIntyre wrote: > On Tue, Jun 14, 2011 at 09:59:22AM +0100, Stuart Henderson wrote: >> On 2011/06/14 09:33, Florian Obser wrote: >>> anyone? >> >> This is just how it works. >> >> http://thread.gmane.org/gmane.os.openbsd.misc/144553/focus=144586 >> but doesn't explain the semantics of continuation lines. I don't feel qualified to provide a patch for pf.conf(5). >> >> How about this? I tried a few wordings to explain it but none >> were right, so it seems clearest with an example. >> >> Lines can be joined using a backslash (`\'), for example: >> >>pass log proto tcp \ >>to port http # this \ >>is all one \ >>line. >> > > i'm surprised we don;t actually document that. i guess it's something > that you instinctively understand, especially since the whole page uses > this notation. Right, I instinctively understood that everything after a hash mark is ignored - which is wrong here but which is what ksh does for example. In the misc thread Stuart sent me, Philip Guenther has a nice list of different behaviour ( http://article.gmane.org/gmane.os.openbsd.misc/144586 ) > > if you want to document it, i'd prefer to try and tuck it in nice and > neat, without an example. how about rearranging the section to something > like this: > > Comments can be put anywhere in the file using a hash mark > (`#'), and extend to the end of the current line. The > current line itself can be extended using a backslash (`\'). > > Additional configuration files can be included with the > include keyword, for example: > > include "/etc/pf/sub.filter.conf" > > ... > > that would be just a one line addition. > > i'd prefer to try and keep this little blurb short, as i think we > should expect readers to understand the idea of `#' as comments, > and `\' as extending the current line. > Right. The problem is what happens when you combine `#' and `\' on the same line. pf.conf does one thing, extending the comment. ksh (for example) does something else, ignoring/commenting the `\'. I'm not sure if your addition captures this distinction. [...] > > jmc > Thanks, Florian
Re: Fix ISA autoconfusion
On Mon, Jun 13, 2011 at 11:15:44PM -0700, Matthew Dempsky wrote: > isa(4) is an indirect bus, which means that drivers that attach to it > need to provide an xxxprobe() method instead of an xxxmatch() method. > The critical difference is xxxprobe() is given a device softc for the > second argument, whereas a xxxmatch() is given the cfdata as the > second argument. > > However, a number of our ISA device drivers treat the second argument > as a cfdata instead of a softc. Diff below addresses this. (Only > complication: unlike isa(4), isapnp(4) is a direct bus, and if_we.c > used the same probe/match code for both.) > > Does this look right? (Compile tested on i386, but I don't have any > ISA hardware, and I'm not having any luck with qemu's "isapc" machine > at the moment...) > Appears to make sense to me, but I have no hardware to test with. Ken
find: exit if there is an unknown option
To quote the FreeBSD commit message where this is from: ---> find: Exit if there is an unknown option. Ignoring the parameter with the unknown options is unlikely to be what was intended. Example: find -n . Note that things like find -n already caused an exit, equivalent to "find" by itself. <--- Index: main.c === RCS file: /cvs/src/usr.bin/find/main.c,v retrieving revision 1.27 diff -u -p -r1.27 main.c --- main.c 21 Apr 2011 01:14:21 - 1.27 +++ main.c 13 Jun 2011 22:50:09 - @@ -99,7 +99,7 @@ main(int argc, char *argv[]) break; case '?': default: - break; + usage(); } argc -= optind; -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: pf.conf, comments and continuation lines
On Tue, Jun 14, 2011 at 03:58:46PM +0200, Florian Obser wrote: > > > > > if you want to document it, i'd prefer to try and tuck it in nice and > > neat, without an example. how about rearranging the section to something > > like this: > > > > Comments can be put anywhere in the file using a hash mark > > (`#'), and extend to the end of the current line. The > > current line itself can be extended using a backslash (`\'). > > > > Additional configuration files can be included with the > > include keyword, for example: > > > > include "/etc/pf/sub.filter.conf" > > > > ... > > > > that would be just a one line addition. > > > > i'd prefer to try and keep this little blurb short, as i think we > > should expect readers to understand the idea of `#' as comments, > > and `\' as extending the current line. > > > > Right. > The problem is what happens when you combine `#' and `\' on the same > line. pf.conf does one thing, extending the comment. ksh (for example) > does something else, ignoring/commenting the `\'. I'm not sure if your > addition captures this distinction. > ah, i missed that part. i think the text i proposed still makes it clear that it would work this way but admittedly it does not address it head on. so i'm not fussed. i'll leave it to stuart to decide whether the example is actually needed or not. i suppose if it is different to the shell, it will confuse people. jmc
tcp keepalive diff #1
actually send keepalives at tcp_keepintvl half-seconds.
previously, tcp_timer.c would arm the timer at tcp_keepintvl half-seconds
in tcp_timer_keep(), but then the code touched in the diff below would
reset it to tcp_keepidle half-seconds instead
any comments?
ok?
Index: netinet/tcp_input.c
===
RCS file: /cvs/src/sys/netinet/tcp_input.c,v
retrieving revision 1.250
diff -u -p -r1.250 tcp_input.c
--- netinet/tcp_input.c 13 May 2011 14:31:16 - 1.250
+++ netinet/tcp_input.c 14 Jun 2011 15:17:50 -
@@ -961,8 +961,13 @@ findpcb:
* Reset idle time and keep-alive timer.
*/
tp->t_rcvtime = tcp_now;
- if (TCPS_HAVEESTABLISHED(tp->t_state))
- TCP_TIMER_ARM(tp, TCPT_KEEP, tcp_keepidle);
+ if (TCPS_HAVEESTABLISHED(tp->t_state)) {
+ if (tcp_always_keepalive ||
+ tp->t_inpcb->inp_socket->so_options & SO_KEEPALIVE)
+ TCP_TIMER_ARM(tp, TCPT_KEEP, tcp_keepintvl);
+ else
+ TCP_TIMER_ARM(tp, TCPT_KEEP, tcp_keepidle);
+ }
#ifdef TCP_SACK
if (tp->sack_enable)
tcp keepalive diff #2: always_keepalive
add sysctl net.inet.tcp.always_keepalive, setting this to 1 acts
as if SO_KEEPALIVE were set on all TCP sockets.
based on code added to FreeBSD ~15 years ago, these days it's
enabled by default there and in dfbsd, here I've left the default
as being disabled.
useful for a client machine behind a NAT gateway or similar that
times out on inactivity too quickly, possibly removing the need for
the NOOP hack in ftp(1).
also useful on servers if you accumulate connections from
users whose net has gone away (for services not already setting
SO_KEEPALIVE).
for an easily-visible test, you could set something like this,
make a tcp connection and obverse network traffic with tcpdump.
net.inet.tcp.always_keepalive=1
net.inet.tcp.keepidle=28
net.inet.tcp.keepintvl=7
(N.B. unless my diff #1 is applied, keepintvtl will be ignored and
only keepidle will take effect).
keepidle/keepintvl values are in "net.inet.tcp.slowhz intervals
per second", i.e. usually half-seconds.
typical values for a client using this to keep NAT state alive
would be a bit higher e.g. maybe keepidle=300, keepintvtl=60
typical conservative values for a server would be something more
like the defaults.
comments?
ok?
Index: sys/netinet/tcp_timer.c
===
RCS file: /cvs/src/sys/netinet/tcp_timer.c,v
retrieving revision 1.45
diff -u -p -r1.45 tcp_timer.c
--- sys/netinet/tcp_timer.c 3 Jul 2010 04:44:51 - 1.45
+++ sys/netinet/tcp_timer.c 14 Jun 2011 15:24:24 -
@@ -55,6 +55,7 @@
#include
#include
+inttcp_always_keepalive;
inttcp_keepidle;
inttcp_keepintvl;
inttcp_maxpersistidle; /* max idle time in persist */
@@ -435,7 +436,8 @@ tcp_timer_keep(void *arg)
tcpstat.tcps_keeptimeo++;
if (TCPS_HAVEESTABLISHED(tp->t_state) == 0)
goto dropit;
- if (tp->t_inpcb->inp_socket->so_options & SO_KEEPALIVE &&
+ if ((tcp_always_keepalive ||
+ tp->t_inpcb->inp_socket->so_options & SO_KEEPALIVE) &&
tp->t_state <= TCPS_CLOSING) {
if ((tcp_maxidle > 0) &&
((tcp_now - tp->t_rcvtime) >= tcp_keepidle + tcp_maxidle))
Index: sys/netinet/tcp_timer.h
===
RCS file: /cvs/src/sys/netinet/tcp_timer.h,v
retrieving revision 1.12
diff -u -p -r1.12 tcp_timer.h
--- sys/netinet/tcp_timer.h 8 Nov 2008 12:54:58 - 1.12
+++ sys/netinet/tcp_timer.h 14 Jun 2011 15:24:24 -
@@ -145,6 +145,7 @@ typedef void (*tcp_timer_func_t)(void *)
extern const tcp_timer_func_t tcp_timer_funcs[TCPT_NTIMERS];
extern int tcptv_keep_init;
+extern int tcp_always_keepalive; /* assume SO_KEEPALIVE is always set */
extern int tcp_keepidle; /* time before keepalive probes begin */
extern int tcp_keepintvl; /* time between keepalive probes */
extern int tcp_maxidle;/* time to drop after starting
probes */
Index: sys/netinet/tcp_var.h
===
RCS file: /cvs/src/sys/netinet/tcp_var.h,v
retrieving revision 1.98
diff -u -p -r1.98 tcp_var.h
--- sys/netinet/tcp_var.h 7 Jan 2011 17:50:42 - 1.98
+++ sys/netinet/tcp_var.h 14 Jun 2011 15:24:24 -
@@ -473,7 +473,8 @@ struct tcpstat {
#defineTCPCTL_DROP19 /* drop tcp connection */
#defineTCPCTL_SACKHOLE_LIMIT 20 /* max entries for tcp sack queues */
#defineTCPCTL_STATS 21 /* TCP statistics */
-#defineTCPCTL_MAXID 22
+#define TCPCTL_ALWAYS_KEEPALIVE 22 /* assume SO_KEEPALIVE is always set */
+#defineTCPCTL_MAXID 23
#defineTCPCTL_NAMES { \
{ 0, 0 }, \
@@ -497,7 +498,8 @@ struct tcpstat {
{ "reasslimit", CTLTYPE_INT }, \
{ "drop", CTLTYPE_STRUCT }, \
{ "sackholelimit", CTLTYPE_INT }, \
- { "stats", CTLTYPE_STRUCT } \
+ { "stats", CTLTYPE_STRUCT }, \
+ { "always_keepalive", CTLTYPE_INT } \
}
#defineTCPCTL_VARS { \
Index: sbin/sysctl/sysctl.8
===
RCS file: /cvs/src/sbin/sysctl/sysctl.8,v
retrieving revision 1.158
diff -u -p -r1.158 sysctl.8
--- sbin/sysctl/sysctl.823 May 2011 07:18:45 - 1.158
+++ sbin/sysctl/sysctl.814 Jun 2011 15:24:24 -
@@ -257,6 +257,7 @@ and a few require a kernel compiled with
.It net.inet.tcp.keepinittime integer yes
.It net.inet.tcp.keepidle integer yes
.It net.inet.tcp.keepintvl integer yes
+.It net.inet.tcp.always_keepalive integer yes
.It net.inet.tcp.slowhzinteger no
.It net.inet.tcp.baddynamicarray yes
.It net.inet.tcp.sack integer yes
Re: tcp keepalive diff #2: always_keepalive
I haven't tested this yet, but it would be handy, I had to patch bitlbee to set the SO_KEEPALIVE option otherwise gtalk would keep reconnecting. -Bryan.
Beneficio Exclusivo para Clientes de Cueros Liberty
Estimado Cliente tech@openbsd.org Si recibe este correo es porque no puede visualizar correctamente nuestro newsletter mensual. Por favor, ingrese al siguiente link para visualizarlo: http://www.cuerosliberty.com.ar/newsletter/padre2011.htm Ante cualquier consulta no dude en contactarnos. Un cordial saludo. Cueros Liberty Reconquista 573, CABA Tel. (11) 4314-0766 Horario: 10.30 a 19 hs. Paseo Pinamar Plaza, Pinamar Local 9 y Gondola 10 www.cuerosliberty.com.ar www.facebook.com/cuerosliberty
Re: tcp keepalive diff #1
On 2011/06/14 16:22, Stuart Henderson wrote:
> actually send keepalives at tcp_keepintvl half-seconds.
>
> previously, tcp_timer.c would arm the timer at tcp_keepintvl half-seconds
> in tcp_timer_keep(), but then the code touched in the diff below would
> reset it to tcp_keepidle half-seconds instead
>
> any comments?
> ok?
>
> Index: netinet/tcp_input.c
> ===
> RCS file: /cvs/src/sys/netinet/tcp_input.c,v
> retrieving revision 1.250
> diff -u -p -r1.250 tcp_input.c
> --- netinet/tcp_input.c 13 May 2011 14:31:16 - 1.250
> +++ netinet/tcp_input.c 14 Jun 2011 15:17:50 -
> @@ -961,8 +961,13 @@ findpcb:
>* Reset idle time and keep-alive timer.
>*/
> tp->t_rcvtime = tcp_now;
> - if (TCPS_HAVEESTABLISHED(tp->t_state))
> - TCP_TIMER_ARM(tp, TCPT_KEEP, tcp_keepidle);
> + if (TCPS_HAVEESTABLISHED(tp->t_state)) {
> + if (tcp_always_keepalive ||
> + tp->t_inpcb->inp_socket->so_options & SO_KEEPALIVE)
sorry, brynet pointed out this depends on diff #2; if you'd like to
test it alone, use this line instead:
+ if (tp->t_inpcb->inp_socket->so_options & SO_KEEPALIVE)
> + TCP_TIMER_ARM(tp, TCPT_KEEP, tcp_keepintvl);
> + else
> + TCP_TIMER_ARM(tp, TCPT_KEEP, tcp_keepidle);
> + }
>
> #ifdef TCP_SACK
> if (tp->sack_enable)
Los Nocheros / Duo Coplanacu - Discografía mas Pendrive de Regalo
Los Nocheros 1 Nuestra Salta - 2 Al rojo vivo - 3 Con el alma - 4 Tiempo de amor - 5 Ven por mi - 6 Signos 7 Nocheros - 8 Señal de amor - 9 En vivo teatro colon - 10 Estado natural - 11 Noche amiga mia - 12 Despedida a un amigo 13 Crónica - 14 Encuentro - 15 Gen - 16 Las 2200 noches - 17 La otra luna Duo Coplanacu 1 Corazon sin tiempo - 2 Desde adentro - 3 Duo Coplanacu - 4 El encuentro 5 guitarrero - 6 paisaje - 7 retiro al norte - 8 taquetuyoj
Re: Synaptics touchpad
On Mon, Jun 13, 2011 at 08:23:16PM -0500, joshua stein wrote:
> > I find the mouse emulation code for synaptics touch pads in your patch
> > really weird. I've tried to understand what it does, and why it
> > behaves badly for me on the first tap (move the pointer in the upper
> > right direction every time), but I fail to understand the logic.
>
> your change makes the problem worse on 2 laptops (samsung series 9
> and thinkpad x220), where the cursor now jumps to the lower left
> after every movement. these seem to be due to events that come
> through after removing all the fingers from the touchpad that need
> to be ignored. i checked linux and they also ignore these events:
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4f56ce929cab45a3a6e1a81700da52bb9bdbfc0f
>
> this also adds support for "clickpads" where there is only one
> physical button and it's the entire trackpad that moves down, which
> both of those laptops have. without this change, the click gets
> ignored.
With your patch my synaptics driver is recognized as a clickpad, but I
can't get no click from it. Otherwise the emulation works fine for
me.
Hopefully with the configuration changes I'm working on, most people
will get the synaptics driver and thus won't need this emulation mode.
>
>
> --- pms.c.new Mon Jun 13 16:26:39 2011
> +++ pms.c Mon Jun 13 20:06:59 2011
> @@ -799,7 +799,9 @@
> syn->wsmode = WSMOUSE_COMPAT;
> syn->count = 0;
>
> - printf("%s: Synaptics touchpad, firmware %d.%d\n", DEVNAME(sc),
> + printf("%s: Synaptics %s, firmware %d.%d\n", DEVNAME(sc),
> + (syn->capabilities & SYNAPTICS_EXT_CAP_CLICKPAD ?
> + "clickpad" : "touchpad"),
> SYNAPTICS_ID_MAJOR(syn->identify),
> SYNAPTICS_ID_MINOR(syn->identify));
> }
> @@ -882,8 +884,11 @@
> buttons |= ((sc->packet[0] & 0x02) & (sc->packet[3] & 0x02)) ?
> WSMOUSE_BUTTON(3) : 0;
>
> - if (syn->capabilities & SYNAPTICS_CAP_MIDDLE_BUTTON) {
> + if (syn->ext_capabilities & SYNAPTICS_EXT_CAP_CLICKPAD) {
> buttons |= ((sc->packet[0] & 0x01) ^ (sc->packet[3] & 0x01)) ?
> + WSMOUSE_BUTTON(1) : 0;
> + } else if (syn->capabilities & SYNAPTICS_CAP_MIDDLE_BUTTON) {
> + buttons |= ((sc->packet[0] & 0x01) ^ (sc->packet[3] & 0x01)) ?
> WSMOUSE_BUTTON(2) : 0;
> }
>
> @@ -906,6 +911,14 @@
> y &= ~0x0f;
> }
>
> + /* ignore final events that happen when removing all fingers */
> + if (x <= 1 && !z) {
> + x = syn->old_x;
> + y = syn->old_y;
> + w = 0;
> + buttons = 0;
> + }
> +
> if (syn->wsmode == WSMOUSE_NATIVE) {
> wsmouse_input(sc->sc_wsmousedev, buttons, x, y, z, w,
> WSMOUSE_INPUT_ABSOLUTE_X | WSMOUSE_INPUT_ABSOLUTE_Y |
> @@ -925,10 +938,11 @@
> if (dx || dy || buttons != syn->old_buttons)
> wsmouse_input(sc->sc_wsmousedev, buttons, dx, dy, 0, 0,
> WSMOUSE_INPUT_DELTA);
> - syn->old_x = x;
> - syn->old_y = y;
> syn->old_buttons = buttons;
> }
> +
> + syn->old_x = x;
> + syn->old_y = y;
> }
>
> void
>
--
Matthieu Herrb
Re: Toshiba M30 ACPI support
Hello again,
Sending toshiba acpi patch as Paul has suggested.
Regards,
Javier.
On Tue, Jun 14, 2011 at 04:04:19PM +0300, Paul Irofti wrote:
> On Tue, Jun 14, 2011 at 11:38:45AM +0200, Javier Vazquez wrote:
> > Hello Everybody,
> >
> > I installed OpenBSD 4.9 current in my old Toshiba M30. Although,
> > there was not LCD brightness control, so I started to do something
> > about
> > it, taking into account the Toshiba acpi support of FreeBSD.
> > http://fxr.watson.org/fxr/source/dev/acpi_support/acpi_toshiba.c
> >
> > Successfully, I can manage the LCD brightness level using wsconsctl(8).
> >
> > wsconsctl display.brightness=100. ;) works nicely by command
> > line as well by setting the brightness level in /etc/wsconsctl.conf
> > file.
> >
> > I attached the required patch files for testing. I hope can be
> > useful for other guys using toshiba laptops as I added the
> > Libretto and Dynabook models.
> >
> > Thanks to Paul for coaching me to provide a decent patch :).
>
> You should have done:
>
> $ cd /sys/dev/acpi
> $ cvs add acpitoshiba.c
> $ cd /sys
> $ cvs diff -uNp
>
> So that you can supply one easy patch for people to test.
>
> Also, the comment about the && instead of || is correct.
>
> People with Toshiba's should test this and report back if this works for
> them or not.
>
> The 'WARN: not a buffer' AML message is a known issue and jordan@ is
> looking into it.
? toshiba_acpi.patch
Index: arch/amd64/conf/GENERIC
===
RCS file: /cvs/src/sys/arch/amd64/conf/GENERIC,v
retrieving revision 1.319
diff -u -p -r1.319 GENERIC
--- arch/amd64/conf/GENERIC 30 May 2011 22:03:47 - 1.319
+++ arch/amd64/conf/GENERIC 14 Jun 2011 20:02:40 -
@@ -52,6 +52,7 @@ acpimcfg* at acpi?
acpiasus* at acpi?
acpisony* at acpi?
acpithinkpad* at acpi?
+acpitoshiba* at acpi?
acpivideo* at acpi?
acpivout* at acpivideo?
acpipwrres*at acpi?
Index: arch/i386/conf/GENERIC
===
RCS file: /cvs/src/sys/arch/i386/conf/GENERIC,v
retrieving revision 1.716
diff -u -p -r1.716 GENERIC
--- arch/i386/conf/GENERIC 30 May 2011 22:03:47 - 1.716
+++ arch/i386/conf/GENERIC 14 Jun 2011 20:02:41 -
@@ -62,6 +62,7 @@ acpitz* at acpi?
acpiasus* at acpi?
acpisony* at acpi?
acpithinkpad* at acpi?
+acpitoshiba* at acpi?
acpivideo* at acpi?
acpivout* at acpivideo?
acpipwrres*at acpi?
Index: dev/acpi/acpi.c
===
RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
retrieving revision 1.224
diff -u -p -r1.224 acpi.c
--- dev/acpi/acpi.c 27 Apr 2011 20:55:42 - 1.224
+++ dev/acpi/acpi.c 14 Jun 2011 20:02:44 -
@@ -93,6 +93,7 @@ void acpi_pbtn_task(void *, int);
#ifndef SMALL_KERNEL
intacpi_thinkpad_enabled;
+intacpi_toshiba_enabled;
intacpi_saved_spl;
intacpi_enabled;
@@ -781,8 +782,8 @@ acpi_attach(struct device *parent, struc
/* check if we're running on a sony */
aml_find_node(&aml_root, "GBRT", acpi_foundsony, sc);
- /* attach video only if this is not a stinkpad */
- if (!acpi_thinkpad_enabled)
+ /* attach video only if this is not a stinkpad or toshiba */
+ if (!acpi_thinkpad_enabled || !acpi_toshiba_enabled)
aml_find_node(&aml_root, "_DOS", acpi_foundvideo, sc);
/* create list of devices we want to query when APM come in */
@@ -2334,6 +2335,13 @@ acpi_foundhid(struct aml_node *node, voi
acpi_thinkpad_enabled = 1;
} else if (!strcmp(dev, ACPI_DEV_ASUSAIBOOSTER))
aaa.aaa_name = "aibs";
+ else if (!strcmp(dev, ACPI_DEV_TOSHIBA_LIBRETTO) ||
+ !strcmp(dev, ACPI_DEV_TOSHIBA_DYNABOOK) ||
+ !strcmp(dev, ACPI_DEV_TOSHIBA_SPA40)) {
+ aaa.aaa_name = "acpitoshiba";
+ acpi_toshiba_enabled = 1;
+ }
+
if (aaa.aaa_name)
config_found(self, &aaa, acpi_print);
Index: dev/acpi/acpireg.h
===
RCS file: /cvs/src/sys/dev/acpi/acpireg.h,v
retrieving revision 1.25
diff -u -p -r1.25 acpireg.h
--- dev/acpi/acpireg.h 27 Apr 2011 20:55:42 - 1.25
+++ dev/acpi/acpireg.h 14 Jun 2011 20:02:44 -
@@ -716,5 +716,8 @@ struct acpi_ivrs {
#define ACPI_DEV_IBM "IBM0068" /* IBM ThinkPad support */
#define ACPI_DEV_LENOVO"LEN0068" /* Lenovo ThinkPad support */
#define ACPI_DEV_ASUSAIBOOSTER "ATK0110" /* ASUSTeK AI Booster */
+#define ACPI_DEV_TOSHIBA_LIBRETTO "TOS6200" /* Toshiba Libretto
support */
+#define ACPI_DEV_TOSHIBA_DYNABOOK "TOS6207" /* Toshiba Dynabook
support */
+#define ACPI_DEV_TOSHIBA_SPA40 "TOS6208" /* Toshiba SPA40 support */
#endif /* !_DEV
Re: pf cleanup diff
On Wed, Jun 08, 2011 at 09:53:24AM +0200, Claudio Jeker wrote:
> Next step on my quest to unify pf_test and pf_test6.
> Move the fragment handling and some other protocol specific tests into
> pf_setup_pdesc(). IPv6 already does this mostly but only IPv4 did not. So
> this diff brings that more into sync. It also includes some additional
> cleanups.
>
> Works for me but needs some more testing.
New version with fixes found by bluhm@ (mostly make sure that the right
header and mbufs are used in all cases).
--
:wq Claudio
Index: net/if_pflog.c
===
RCS file: /cvs/src/sys/net/if_pflog.c,v
retrieving revision 1.34
diff -u -p -r1.34 if_pflog.c
--- net/if_pflog.c 22 May 2011 13:21:24 - 1.34
+++ net/if_pflog.c 24 May 2011 15:56:53 -
@@ -334,7 +334,7 @@ pflog_bpfcopy(const void *src_arg, void
/* rewrite addresses if needed */
memset(&pd, 0, sizeof(pd));
pd.hdr.any = &pf_hdrs;
- if (pf_setup_pdesc(pfloghdr->af, pfloghdr->dir, &pd, mfake, &action,
+ if (pf_setup_pdesc(pfloghdr->af, pfloghdr->dir, &pd, &mfake, &action,
&reason, NULL, NULL, NULL, NULL, &off, &hdrlen) == -1)
return;
Index: net/pf.c
===
RCS file: /cvs/src/sys/net/pf.c,v
retrieving revision 1.747
diff -u -p -r1.747 pf.c
--- net/pf.c2 Jun 2011 22:08:40 - 1.747
+++ net/pf.c10 Jun 2011 08:22:36 -
@@ -5466,10 +5466,12 @@ pf_get_divert(struct mbuf *m)
}
int
-pf_setup_pdesc(sa_family_t af, int dir, struct pf_pdesc *pd, struct mbuf *m,
+pf_setup_pdesc(sa_family_t af, int dir, struct pf_pdesc *pd, struct mbuf **m0,
u_short *action, u_short *reason, struct pfi_kif *kif, struct pf_rule **a,
struct pf_rule **r, struct pf_ruleset **ruleset, int *off, int *hdrlen)
{
+ struct mbuf *m = *m0;
+
if (pd->hdr.any == NULL)
panic("pf_setup_pdesc: no storage for headers provided");
@@ -5479,13 +5481,23 @@ pf_setup_pdesc(sa_family_t af, int dir,
case AF_INET: {
struct ip *h;
+ /* Check for illegal packets */
+ if (m->m_pkthdr.len < (int)sizeof(struct ip)) {
+ *action = PF_DROP;
+ REASON_SET(reason, PFRES_SHORT);
+ return (-1);
+ }
+
h = mtod(m, struct ip *);
*off = h->ip_hl << 2;
- if (*off < (int)sizeof(*h)) {
+
+ if (*off < (int)sizeof(struct ip) ||
+ *off > ntohs(h->ip_len)) {
*action = PF_DROP;
REASON_SET(reason, PFRES_SHORT);
return (-1);
}
+
pd->src = (struct pf_addr *)&h->ip_src;
pd->dst = (struct pf_addr *)&h->ip_dst;
pd->sport = pd->dport = NULL;
@@ -5500,9 +5512,41 @@ pf_setup_pdesc(sa_family_t af, int dir,
pd->tot_len = ntohs(h->ip_len);
pd->rdomain = rtable_l2(m->m_pkthdr.rdomain);
- /* fragments not reassembled handled later */
- if (h->ip_off & htons(IP_MF | IP_OFFMASK))
- return (0);
+ if (h->ip_off & htons(IP_MF | IP_OFFMASK)) {
+ if (!pf_status.reass) {
+ /*
+* handle fragments that aren't reassembled by
+* normalization
+*/
+ if (kif == NULL || r == NULL) /* pflog */
+ *action = PF_DROP;
+ else
+ *action = pf_test_fragment(r, dir, kif,
+m, pd, a, ruleset);
+ if (*action == PF_DROP)
+ REASON_SET(reason, PFRES_FRAG);
+ return (-1);
+ }
+ /* packet reassembly */
+ if (pf_normalize_ip(m0, dir, reason, pd) != PF_PASS) {
+ *action = PF_DROP;
+ return (-1);
+ }
+ m = *m0;
+ if (m == NULL) {
+ /* packet has been reassembled, no error */
+ *action = PF_PASS;
+ return (-1);
+ }
+ /* refetch header, recalc offset and update pd */
+ h = mtod(m, struct ip *);
+ *off = h->ip_hl << 2;
+ pd->src = (struct pf_addr *)&h->ip_src;
+ pd->dst = (struct pf_addr *)&h->ip_dst;
+ pd->ip_sum = &h->ip_sum;
+
Re: En/disabling power button shutdown
Christian Weisgerber wrote: > The diff below -snip- > I have only tested this on amd64 and sparc64. Has anybody compiled this on landisk, sgi, zaurus? -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: pf.conf, comments and continuation lines
On 2011/06/14 15:43, Jason McIntyre wrote: > On Tue, Jun 14, 2011 at 03:58:46PM +0200, Florian Obser wrote: > > > > > > > > if you want to document it, i'd prefer to try and tuck it in nice and > > > neat, without an example. how about rearranging the section to something > > > like this: > > > > > > Comments can be put anywhere in the file using a hash mark > > > (`#'), and extend to the end of the current line. The > > > current line itself can be extended using a backslash (`\'). > > > > > > Additional configuration files can be included with the > > > include keyword, for example: > > > > > > include "/etc/pf/sub.filter.conf" > > > > > > ... > > > > > > that would be just a one line addition. > > > > > > i'd prefer to try and keep this little blurb short, as i think we > > > should expect readers to understand the idea of `#' as comments, > > > and `\' as extending the current line. > > > > > > > Right. > > The problem is what happens when you combine `#' and `\' on the same > > line. pf.conf does one thing, extending the comment. ksh (for example) > > does something else, ignoring/commenting the `\'. I'm not sure if your > > addition captures this distinction. > > > > ah, i missed that part. i think the text i proposed still makes it clear > that it would work this way but admittedly it does not address it head > on. > > so i'm not fussed. i'll leave it to stuart to decide whether the example > is actually needed or not. i suppose if it is different to the shell, it > will confuse people. I think it needs to be mentioned explicitly as, although it's something people coming from a programming background might expect, it's completely alien to people who only edit configuration files and common scripting languages. You're right about it getting copied to other places, there are 9 copies in tree and I'd rather not come up with an example for each, so I would be happier to have it in the text rather than as an example if it can be done clearly, but I haven't managed it...
Re: wol for xl(4)
Stefan Sperling openbsd.org> writes:
>
> This is an attempt to add wol support to xl(4).
>
> Unfortunately, while I have an xl(4) card to test with none of the
> motherboards I have will do WOL with it since they all lack an
> on-board WOL connector :(
>
> So test reports are needed.
> Please also check whether WOL is disabled by default.
>
hi
i have an old ASUS A7N8X DELUXE Rev.2 motherboard with an on-board 3Com
3C920B-EMB NIC. i'm running the latest -current.
i tried wol, but it won't work with openbsd (although it works perfectly with
gentoo on the same box).
i had a look into the driver, and tried several approaches, none successful so
far.
1) first, the driver never put the NIC into D3 power state, since the test on
PXL_PME_CAP_D3_HOT was negative.
---
if (command & XL_PME_CAP_D3_HOT) {
sc->wol_power = xl_pci_wol_power;
sc->wol_power_arg = psc;
}
---
so i simply disabled the "if" above.
=> "xl_pci_wol_power" is called now on shutdown.
2) next i had a look into "xl_pci_wol_power". i realized that it does the power
state switch differently from the linux driver. thus, i tried to use
"pci_set_powerstate" (with proper arguments) instead. i took as
an example (there you can see how "pci_set_powerstate" must be called).
=> unfortunately no effect either.
3) i compared the register window write calls to that of the linux driver (set
win 5 / 7, set and enable rx filter with flags to accept broadcast frames,
etc.). i found nothing wrong about that. the only thing that IMO is different,
is that while the openbsd driver does all those things in different functions,
the linux driver does all within "acpi_set_WOL".
4) a note on setting the rx filter (grep on rxfilt): the xl driver does this in
"iff_905x" (?) (sorry, don't have the sources available right now...) in file
. i checked and by default, this routine is never called in my case. thus,
i put the rxfilt-code into "xl_wol" () right into the "if (enable)"
block...
=> again no functional WOL...
i hope this helps, i will investigate further.
if you need any more specific detail, please let me know!
cheers,
thomas
Re: pf.conf, comments and continuation lines
> so I would be happier to have it in the text rather than as an > example if it can be done clearly, but I haven't managed it... For pf and pf like code: Notice: Line continuation processing occurs BEFORE comment removal. For ksh and ksh like code: Notice: Comments are removed BEFORE line continuation processing. Without an example of each, though, I don't know if the repercussions will be understood. /\/\arc
Re: pf.conf, comments and continuation lines
On 06/14/2011 11:58 PM, Stuart Henderson wrote: > On 2011/06/14 15:43, Jason McIntyre wrote: >> On Tue, Jun 14, 2011 at 03:58:46PM +0200, Florian Obser wrote: >>> if you want to document it, i'd prefer to try and tuck it in nice and neat, without an example. how about rearranging the section to something like this: Comments can be put anywhere in the file using a hash mark (`#'), and extend to the end of the current line. The current line itself can be extended using a backslash (`\'). Additional configuration files can be included with the include keyword, for example: include "/etc/pf/sub.filter.conf" ... that would be just a one line addition. i'd prefer to try and keep this little blurb short, as i think we should expect readers to understand the idea of `#' as comments, and `\' as extending the current line. >>> >>> Right. >>> The problem is what happens when you combine `#' and `\' on the same >>> line. pf.conf does one thing, extending the comment. ksh (for example) >>> does something else, ignoring/commenting the `\'. I'm not sure if your >>> addition captures this distinction. >>> >> >> ah, i missed that part. i think the text i proposed still makes it clear >> that it would work this way but admittedly it does not address it head >> on. >> >> so i'm not fussed. i'll leave it to stuart to decide whether the example >> is actually needed or not. i suppose if it is different to the shell, it >> will confuse people. > > I think it needs to be mentioned explicitly as, although it's something > people coming from a programming background might expect, it's completely > alien to people who only edit configuration files and common scripting > languages. As an anti thesis you could change the behaviour of the parser. But that probably needs documentation, too. This might have the benefit of being what users expect. > > You're right about it getting copied to other places, there are 9 > copies in tree and I'd rather not come up with an example for each, > so I would be happier to have it in the text rather than as an > example if it can be done clearly, but I haven't managed it... > After reading jmc's proposal many more times I finally convinced myself that I would probably understand that comments will be extended, too. I think it's nearly there, maybe a tiny bit more explicit? Comments can be put anywhere in the file using a hash mark (`#'), and extend to the end of the current line. The current line itself, including comments, can be extended using a backslash (`\'). Additional configuration files can be included with the include keyword, for example: include "/etc/pf/sub.filter.conf" I don't feel strongly one way or the other (change the parser or extend the documentation). It took us about 15 minutes to debug our original problem so we are not going to forget pf.conf's behaviour any time soon. It would be nice to do one thing or the other... Thanks, Florian
Local Flores Oferta Imperdible Sin Gastos Inmobiliaria
Impecable Local, listo para ser usado o rentado Puede dividirse en dos locales, con entradas independientes. Se ofrece a la mitad de su valor real, sin gastos inmobiliarios !!! Son 125 m2 ( 75m2 en PB, 50m2 en impecable subsuelo ); tiene 7 mts de frente y 14 de fondo. Majestuosa recepcisn ( espejos y madera ), 4 despachos, cocina office y 3 baqos, todo excelente!. Rejas en todo el frente. Aire Acond Central funcionando perfectamente. Ventilacisn forzada subsuelo reglamentaria. Montacargas como nuevo 500 kg. A metros de nuevo subte "A" Flores Nazca y J.B.Alberdi zona sanitarios Ocasisn para no dejar pasar, verlo es quererlo!!! u$s 77.000 ( incluye gastos inmobiliarios ) 4674-3200 [IMAGE][IMAGE][IMAGE] [demime 1.01d removed an attachment of type image/jpeg which had a name of frente.jpg] [demime 1.01d removed an attachment of type image/jpeg which had a name of subsuelo.jpg] [demime 1.01d removed an attachment of type image/jpeg which had a name of recepcion.jpg]
dont let sdmmc devices respond to scsi vpd queries
ie, check if the VPD bit is set when an inquiry is issued and stop
if it is. adds a free check for the cdblen there too.
i cant even ping my x60 atm, so i cant test. anyone else want to
give it a spin?
Index: sdmmc_scsi.c
===
RCS file: /cvs/src/sys/dev/sdmmc/sdmmc_scsi.c,v
retrieving revision 1.26
diff -u -p -r1.26 sdmmc_scsi.c
--- sdmmc_scsi.c25 Oct 2010 10:36:49 - 1.26
+++ sdmmc_scsi.c15 Jun 2011 03:25:28 -
@@ -80,6 +80,7 @@ void *sdmmc_ccb_alloc(void *);
void sdmmc_ccb_free(void *, void *);
void sdmmc_scsi_cmd(struct scsi_xfer *);
+void sdmmc_inquiry(struct scsi_xfer *);
void sdmmc_start_xs(struct sdmmc_softc *, struct sdmmc_ccb *);
void sdmmc_complete_xs(void *);
void sdmmc_done_xs(struct sdmmc_ccb *);
@@ -296,7 +297,6 @@ sdmmc_scsi_cmd(struct scsi_xfer *xs)
struct sdmmc_softc *sc = link->adapter_softc;
struct sdmmc_scsi_softc *scbus = sc->sc_scsibus;
struct sdmmc_scsi_target *tgt = &scbus->sc_tgt[link->target];
- struct scsi_inquiry_data inq;
struct scsi_read_cap_data rcd;
u_int32_t blockno;
u_int32_t blockcnt;
@@ -327,17 +327,7 @@ sdmmc_scsi_cmd(struct scsi_xfer *xs)
break;
case INQUIRY:
- bzero(&inq, sizeof inq);
- inq.device = T_DIRECT;
- inq.version = 2;
- inq.response_format = 2;
- inq.additional_length = 32;
- strlcpy(inq.vendor, "SD/MMC ", sizeof(inq.vendor));
- snprintf(inq.product, sizeof(inq.product),
- "Drive #%02d", link->target);
- strlcpy(inq.revision, " ", sizeof(inq.revision));
- bcopy(&inq, xs->data, MIN(xs->datalen, sizeof inq));
- scsi_done(xs);
+ sdmmc_inquiry(xs);
return;
case TEST_UNIT_READY:
@@ -381,6 +371,39 @@ sdmmc_scsi_cmd(struct scsi_xfer *xs)
ccb->ccb_blockno = blockno;
sdmmc_start_xs(sc, ccb);
+}
+
+void
+sdmmc_inquiry(struct scsi_xfer *xs)
+{
+ struct scsi_link *link = xs->sc_link;
+ struct scsi_inquiry_data inq;
+ struct scsi_inquiry *cdb = (struct scsi_inquiry *)xs->cmd;
+
+if (xs->cmdlen != sizeof(*cdb)) {
+ xs->error = XS_DRIVER_STUFFUP;
+ goto done;
+ }
+
+ if (ISSET(cdb->flags, SI_EVPD)) {
+ xs->error = XS_DRIVER_STUFFUP;
+ goto done;
+ }
+
+ bzero(&inq, sizeof inq);
+ inq.device = T_DIRECT;
+ inq.version = 2;
+ inq.response_format = 2;
+ inq.additional_length = 32;
+ strlcpy(inq.vendor, "SD/MMC ", sizeof(inq.vendor));
+ snprintf(inq.product, sizeof(inq.product),
+ "Drive #%02d", link->target);
+ strlcpy(inq.revision, " ", sizeof(inq.revision));
+
+ bcopy(&inq, xs->data, MIN(xs->datalen, sizeof(inq)));
+
+done:
+ scsi_done(xs);
}
void
try to refill bnx(4) when all the mbufs are gone
this is like the change i did for ix(4)...
Index: if_bnx.c
===
RCS file: /cvs/src/sys/dev/pci/if_bnx.c,v
retrieving revision 1.94
diff -u -p -r1.94 if_bnx.c
--- if_bnx.c18 Apr 2011 04:27:31 - 1.94
+++ if_bnx.c15 Jun 2011 04:05:28 -
@@ -363,7 +363,8 @@ int bnx_get_buf(struct bnx_softc *, u_in
intbnx_init_tx_chain(struct bnx_softc *);
void bnx_init_tx_context(struct bnx_softc *);
-void bnx_fill_rx_chain(struct bnx_softc *);
+void bnx_fill_rx_chain(struct bnx_softc *, int);
+void bnx_refill_rx_chain(void *);
void bnx_init_rx_context(struct bnx_softc *);
intbnx_init_rx_chain(struct bnx_softc *);
void bnx_free_rx_chain(struct bnx_softc *);
@@ -933,6 +934,7 @@ bnx_attachhook(void *xsc)
ether_ifattach(ifp);
timeout_set(&sc->bnx_timeout, bnx_tick, sc);
+ timeout_set(&sc->rx_refill, bnx_refill_rx_chain, sc);
/* Print some important debugging info. */
DBRUN(BNX_INFO, bnx_dump_driver_state(sc));
@@ -3233,6 +3235,7 @@ bnx_stop(struct bnx_softc *sc)
DBPRINT(sc, BNX_VERBOSE_RESET, "Entering %s()\n", __FUNCTION__);
timeout_del(&sc->bnx_timeout);
+ timeout_del(&sc->rx_refill);
ifp->if_flags &= ~(IFF_RUNNING | IFF_OACTIVE);
@@ -3706,6 +3709,7 @@ bnx_get_buf(struct bnx_softc *sc, u_int1
* last rx_bd entry so that rx_mbuf_ptr and rx_mbuf_map matches)
* and update our counter.
*/
+ sc->rx_mbuf_alloc++;
sc->rx_mbuf_ptr[*chain_prod] = m;
sc->rx_mbuf_map[first_chain_prod] = sc->rx_mbuf_map[*chain_prod];
sc->rx_mbuf_map[*chain_prod] = map;
@@ -3981,10 +3985,11 @@ bnx_init_rx_context(struct bnx_softc *sc
/* Nothing*/
//
void
-bnx_fill_rx_chain(struct bnx_softc *sc)
+bnx_fill_rx_chain(struct bnx_softc *sc, int offset)
{
u_int16_t prod, chain_prod;
u_int32_t prod_bseq;
+ int refill = 0;
#ifdef BNX_DEBUG
int rx_mbuf_alloc_before, free_rx_bd_before;
#endif
@@ -4007,6 +4012,7 @@ bnx_fill_rx_chain(struct bnx_softc *sc)
break;
}
prod = NEXT_RX_BD(prod);
+ refill = 1;
}
#if 0
@@ -4016,17 +4022,33 @@ bnx_fill_rx_chain(struct bnx_softc *sc)
(free_rx_bd_before - sc->free_rx_bd)));
#endif
- /* Save the RX chain producer index. */
- sc->rx_prod = prod;
- sc->rx_prod_bseq = prod_bseq;
-
- /* Tell the chip about the waiting rx_bd's. */
- REG_WR16(sc, MB_RX_CID_ADDR + BNX_L2CTX_HOST_BDIDX, sc->rx_prod);
- REG_WR(sc, MB_RX_CID_ADDR + BNX_L2CTX_HOST_BSEQ, sc->rx_prod_bseq);
+ if (refill) {
+ /* Save the RX chain producer index. */
+ sc->rx_prod = prod;
+ sc->rx_prod_bseq = prod_bseq;
+
+ /* Tell the chip about the waiting rx_bd's. */
+ REG_WR16(sc, MB_RX_CID_ADDR + BNX_L2CTX_HOST_BDIDX,
+ sc->rx_prod);
+ REG_WR(sc, MB_RX_CID_ADDR + BNX_L2CTX_HOST_BSEQ,
+ sc->rx_prod_bseq);
+ } else if (sc->rx_mbuf_alloc < 2)
+ timeout_add(&sc->rx_refill, offset);
DBPRINT(sc, BNX_EXCESSIVE_RECV, "Exiting %s()\n", __FUNCTION__);
}
+void
+bnx_refill_rx_chain(void *xsc)
+{
+ struct bnx_softc *sc = xsc;
+ int s;
+
+ s = splnet();
+ bnx_fill_rx_chain(sc, 1);
+ splx(s);
+}
+
//
/* Allocate memory and initialize the RX data structures. */
/* */
@@ -4071,7 +4093,7 @@ bnx_init_rx_chain(struct bnx_softc *sc)
}
/* Fill up the RX chain. */
- bnx_fill_rx_chain(sc);
+ bnx_fill_rx_chain(sc, 1);
for (i = 0; i < RX_PAGES; i++)
bus_dmamap_sync(sc->bnx_dmatag, sc->rx_bd_chain_map[i], 0,
@@ -4120,7 +4142,7 @@ bnx_free_rx_chain(struct bnx_softc *sc)
}
m_freem(sc->rx_mbuf_ptr[i]);
sc->rx_mbuf_ptr[i] = NULL;
- DBRUNIF(1, sc->rx_mbuf_alloc--);
+ sc->rx_mbuf_alloc--;
}
}
@@ -4335,6 +4357,7 @@ bnx_rx_intr(struct bnx_softc *sc)
/* Remove the mbuf from RX chain. */
m = sc->rx_mbuf_ptr[sw_chain_cons];
sc->rx_mbuf_ptr[sw_chain_cons] = NULL;
+ sc->rx_mbuf_alloc--;
/*
* Frames received on the NetXteme II are prepended
@@ -4483,7 +4506,6 @@ bnx_rx_int_next_rx:
DBPRINT(sc, BNX_VERBOSE_REC
