X configuration changes for synaptics - please test
Hi, here are a set of patches being worked on to add native synaptics touch pad support to OpenBSD and Xenocara. The xf86-input-synaptics driver itself is already committed and built in Xenocara. http://xenocara.org/wscons_config.2.diff is a diff that uses the X hot-plug mechanism to configure you input drivers. It will setup the xf86-input-synaptics driver for you if you have one, together with a regular mouse driver that will handle any external PS/2 or USB mouse attached in addition. Touchscreens will also be auto-configured this way if one is detected. This new code also takes care of the configuration of the keyboard layout from the wscons layout. Thus a second diff: http://xenocara.org/xf86-input-keyboard.diff removes that code from the keyboard driver. To apply those patches: cd /usr/xenocara/xserver patch -p0 -E /path/to/wscons_config.2.diff make -f Makefile.bsd-wrapper obj make -f Makefile.bsd-wrapper build cd /usr/xenocara/driver/xf86-input-keyboard patch -p0 -E /path/to/xf86-input-keyboard.diff make -f Makefile.bsd-wrapper obj make -f Makefile.bsd-wrapper build Once X is ready, apply the kernel patch, and build a new kernel with the synaptics support in pms(4): http://xenocara.org/sys-synaptics.diff cd /sys patch -p0 -E /path/to/sys-synaptics.diff the new kernel will detect your synaptics touch pad if any, and X will be configured with the xf86-input-synaptics. Read the synaptics(4) manual page to discover all its features. You can check how the input drivers were configured by running the command: xinput list If you are configuring input devices manually in xorg,conf you need to add this to the ServerFlags section (but may be you should give a try at auto-configuration and remove your InputDevice sections all together): Section ServerFlags Option AutoAddDevices false EndSection Please test, comment and report failures. Make sure to include /var/log/Xorg.0.log and dmesg outputs in your reports. Thanks to Alexandr Shadchin (shadchin@) for his work on this driver and to all people who already tested these patches and suggested enhancements. -- Matthieu Herrb
Re: tcp keepalive diff #2: always_keepalive
On 2011/06/14 16:33, Stuart Henderson wrote: -#define TCPCTL_MAXID 22 +#define TCPCTL_ALWAYS_KEEPALIVE 22 /* assume SO_KEEPALIVE is always set */ +#define TCPCTL_MAXID 23 I wasn't going to post a followup just for this but seeing as a few people have mentioned it already, I'll post and save others the trouble :) I have changed #define TCPCTL_ALWAYS_KEEPALIVE 22 /* assume SO_KEEPALIVE is always set */ to #define TCPCTL_ALWAYS_KEEPALIVE 22 /* assume SO_KEEPALIVE is always set */ (space/tab).
Re: Toshiba M30 ACPI support
On Tue, Jun 14, 2011 at 10:07:54PM +0200, Javier Vazquez wrote: Hello again, Sending toshiba acpi patch as Paul has suggested. Cool! [--snip--] 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 @@ voidacpi_pbtn_task(void *, int); #ifndef SMALL_KERNEL int acpi_thinkpad_enabled; +int acpi_toshiba_enabled; int acpi_saved_spl; int acpi_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); You forgot to fix this into: + if (!acpi_thinkpad_enabled !acpi_toshiba_enabled)
lru/failover path scheduling in mpath(4)
the subject line says it all, but happy to explain further if
required.
Index: mpath.c
===
RCS file: /cvs/src/sys/scsi/mpath.c,v
retrieving revision 1.21
diff -u -p -r1.21 mpath.c
--- mpath.c 27 Apr 2011 05:22:24 - 1.21
+++ mpath.c 15 Jun 2011 08:03:06 -
@@ -58,6 +58,7 @@ struct mpath_dev {
u_intd_path_count;
+ const struct mpath_ops *d_ops;
struct devid*d_id;
};
@@ -89,7 +90,7 @@ void mpath_cmd(struct scsi_xfer *);
void mpath_minphys(struct buf *, struct scsi_link *);
intmpath_probe(struct scsi_link *);
-struct mpath_path *mpath_next_path(struct mpath_dev *);
+struct mpath_path *mpath_next_path(struct mpath_dev *, int);
void mpath_done(struct scsi_xfer *);
struct scsi_adapter mpath_switch = {
@@ -161,7 +162,7 @@ mpath_probe(struct scsi_link *link)
}
struct mpath_path *
-mpath_next_path(struct mpath_dev *d)
+mpath_next_path(struct mpath_dev *d, int next)
{
struct mpath_path *p;
@@ -169,7 +170,7 @@ mpath_next_path(struct mpath_dev *d)
panic(%s: d is NULL, __func__);
p = d-d_next_path;
- if (p != NULL) {
+ if (p != NULL next == MPATH_NEXT) {
d-d_next_path = TAILQ_NEXT(p, p_entry);
if (d-d_next_path == NULL)
d-d_next_path = TAILQ_FIRST(d-d_paths);
@@ -194,7 +195,7 @@ mpath_cmd(struct scsi_xfer *xs)
if (ISSET(xs-flags, SCSI_POLL)) {
mtx_enter(d-d_mtx);
- p = mpath_next_path(d);
+ p = mpath_next_path(d, d-d_ops-op_schedule);
mtx_leave(d-d_mtx);
if (p == NULL) {
mpath_xs_stuffup(xs);
@@ -232,7 +233,7 @@ mpath_cmd(struct scsi_xfer *xs)
mtx_enter(d-d_mtx);
SIMPLEQ_INSERT_TAIL(d-d_ccbs, ccb, c_entry);
- p = mpath_next_path(d);
+ p = mpath_next_path(d, d-d_ops-op_schedule);
mtx_leave(d-d_mtx);
if (p != NULL)
@@ -294,11 +295,15 @@ mpath_done(struct scsi_xfer *mxs)
struct mpath_ccb *ccb = xs-io;
struct mpath_dev *d = mpath_devs[link-target];
struct mpath_path *p;
+ int next = d-d_ops-op_schedule;
- if (mxs-error == XS_RESET || mxs-error == XS_SELTIMEOUT) {
+ switch (mxs-error) {
+ case XS_SELTIMEOUT: /* physical path is gone, try the next */
+ next = MPATH_NEXT;
+ case XS_RESET:
mtx_enter(d-d_mtx);
SIMPLEQ_INSERT_HEAD(d-d_ccbs, ccb, c_entry);
- p = mpath_next_path(d);
+ p = mpath_next_path(d, next);
mtx_leave(d-d_mtx);
scsi_xs_put(mxs);
@@ -363,7 +368,7 @@ mpath_path_probe(struct scsi_link *link)
}
int
-mpath_path_attach(struct mpath_path *p)
+mpath_path_attach(struct mpath_path *p, const struct mpath_ops *ops)
{
struct scsi_link *link = p-p_link;
struct mpath_dev *d = NULL;
@@ -381,7 +386,7 @@ mpath_path_attach(struct mpath_path *p)
if ((d = mpath_devs[target]) == NULL)
continue;
- if (DEVID_CMP(d-d_id, link-id))
+ if (DEVID_CMP(d-d_id, link-id) d-d_ops == ops)
break;
d = NULL;
@@ -403,6 +408,7 @@ mpath_path_attach(struct mpath_path *p)
TAILQ_INIT(d-d_paths);
SIMPLEQ_INIT(d-d_ccbs);
d-d_id = devid_copy(link-id);
+ d-d_ops = ops;
mpath_devs[target] = d;
newdev = 1;
Index: mpath_emc.c
===
RCS file: /cvs/src/sys/scsi/mpath_emc.c,v
retrieving revision 1.5
diff -u -p -r1.5 mpath_emc.c
--- mpath_emc.c 15 Jun 2011 01:10:50 - 1.5
+++ mpath_emc.c 15 Jun 2011 08:03:06 -
@@ -94,11 +94,12 @@ int emc_mpath_checksense(struct scsi_xf
intemc_mpath_online(struct scsi_link *);
intemc_mpath_offline(struct scsi_link *);
-struct mpath_ops emc_mpath_ops = {
+const struct mpath_ops emc_mpath_ops = {
emc,
emc_mpath_checksense,
emc_mpath_online,
emc_mpath_offline,
+ MPATH_ROUNDROBIN
};
struct emc_device {
@@ -156,7 +157,6 @@ emc_attach(struct device *parent, struct
/* init path */
scsi_xsh_set(sc-sc_path.p_xsh, link, emc_mpath_start);
sc-sc_path.p_link = link;
- sc-sc_path.p_ops = emc_mpath_ops;
if (emc_sp_info(sc)) {
printf(%s: unable to get sp info\n, DEVNAME(sc));
@@ -172,7 +172,7 @@ emc_attach(struct device *parent, struct
sc-sc_sp + 'A', sc-sc_port);
if (sc-sc_lun_state == EMC_SP_INFO_LUN_STATE_OWNED) {
- if (mpath_path_attach(sc-sc_path) != 0)
+ if (mpath_path_attach(sc-sc_path, emc_mpath_ops) != 0)
printf(%s:
Re: pf.conf, comments and continuation lines
On Tue, Jun 14, 2011 at 10:58:31PM +0100, Stuart Henderson wrote: 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... so i suggest you just go with wording similar to that which i proposed, which does cover the case we're talking about. i think florian's tweak (including comments) was definitely an improvement. i don;t think marco's suggestion will help though - i think without any clear context or examples, the sentence is likely to confuse more people than help. i know i wouldn;t have understood it exactly without having had this conversation. remember this issue (such that it is) is only going to effect a very small number of people. we just need to make sure that if they read the man page carefully, they come to the conclusion that we want them to. jmc
Re: pf.conf, comments and continuation lines
On 2011/06/15 09:18, Jason McIntyre wrote:
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...
so i suggest you just go with wording similar to that which i proposed,
which does cover the case we're talking about. i think florian's tweak
(including comments) was definitely an improvement.
i don;t think marco's suggestion will help though - i think without any
clear context or examples, the sentence is likely to confuse more people
than help. i know i wouldn;t have understood it exactly without having
had this conversation.
remember this issue (such that it is) is only going to effect a very
small number of people.
perhaps a small number of people, but it can be a very serious
issue indeed. particularly for pf.conf it needs to be crystal clear.
compare output from these two:
$ cat EOF | pfctl -nvf -
pass out quick on lan \
# inet proto {udp,tcp} from {10.71.38.0/24} \
inet proto {udp,tcp} from {10.71.38.0/24, 10.71.100.0/22} \
to port {http, https}
EOF
$ cat EOF | pfctl -nvf -
pass out quick on lan \
inet proto {udp,tcp} from {10.71.38.0/24, 10.71.100.0/22} \
to port {http, https}
EOF
Re: pf.conf, comments and continuation lines
On Wed, Jun 15, 2011 at 09:37:25AM +0100, Stuart Henderson wrote:
perhaps a small number of people, but it can be a very serious
issue indeed. particularly for pf.conf it needs to be crystal clear.
compare output from these two:
$ cat EOF | pfctl -nvf -
pass out quick on lan \
# inet proto {udp,tcp} from {10.71.38.0/24} \
inet proto {udp,tcp} from {10.71.38.0/24, 10.71.100.0/22} \
to port {http, https}
EOF
$ cat EOF | pfctl -nvf -
pass out quick on lan \
inet proto {udp,tcp} from {10.71.38.0/24, 10.71.100.0/22} \
to port {http, https}
EOF
so i guess we're looking for a text only (i.e. no example) solution.
here is another stab.
jmc
Index: pf.conf.5
===
RCS file: /cvs/src/share/man/man5/pf.conf.5,v
retrieving revision 1.494
diff -u -r1.494 pf.conf.5
--- pf.conf.5 20 May 2011 22:57:20 - 1.494
+++ pf.conf.5 15 Jun 2011 09:02:10 -
@@ -62,9 +62,14 @@
Some example rulesets.
.El
.Pp
+The current line can be extended over multiple lines using a backslash
+.Pq Sq \e .
Comments can be put anywhere in the file using a hash mark
.Pq Sq # ,
and extend to the end of the current line.
+Take care when commenting out text which is part of a multi-line block:
+the comment takes effect until the end of the entire block.
+.Pp
Additional configuration files can be included with the
.Ic include
keyword, for example:
Re: pf.conf, comments and continuation lines
On 2011/06/15 10:03, Jason McIntyre wrote: so i guess we're looking for a text only (i.e. no example) solution. here is another stab. nicely crafted words, this is good. ok sthen@ I'll handle the other copies of this if you like. Index: pf.conf.5 === RCS file: /cvs/src/share/man/man5/pf.conf.5,v retrieving revision 1.494 diff -u -r1.494 pf.conf.5 --- pf.conf.5 20 May 2011 22:57:20 - 1.494 +++ pf.conf.5 15 Jun 2011 09:02:10 - @@ -62,9 +62,14 @@ Some example rulesets. .El .Pp +The current line can be extended over multiple lines using a backslash +.Pq Sq \e . Comments can be put anywhere in the file using a hash mark .Pq Sq # , and extend to the end of the current line. +Take care when commenting out text which is part of a multi-line block: +the comment takes effect until the end of the entire block. +.Pp Additional configuration files can be included with the .Ic include keyword, for example:
Re: pf.conf, comments and continuation lines
On Wed, Jun 15, 2011 at 11:09:35AM +0100, Stuart Henderson wrote: On 2011/06/15 10:03, Jason McIntyre wrote: so i guess we're looking for a text only (i.e. no example) solution. here is another stab. nicely crafted words, this is good. ok sthen@ I'll handle the other copies of this if you like. i think it makes sense to do this in one commit, so i'd appreciate if you could do this one too. one thing for consideration: in the text below, i swithered whether the comment takes effect would read better as the comment will take effect. i'm not sure which would be clearer (or read better) for most people. jmc Index: pf.conf.5 === RCS file: /cvs/src/share/man/man5/pf.conf.5,v retrieving revision 1.494 diff -u -r1.494 pf.conf.5 --- pf.conf.5 20 May 2011 22:57:20 - 1.494 +++ pf.conf.5 15 Jun 2011 09:02:10 - @@ -62,9 +62,14 @@ Some example rulesets. .El .Pp +The current line can be extended over multiple lines using a backslash +.Pq Sq \e . Comments can be put anywhere in the file using a hash mark .Pq Sq # , and extend to the end of the current line. +Take care when commenting out text which is part of a multi-line block: +the comment takes effect until the end of the entire block. +.Pp Additional configuration files can be included with the .Ic include keyword, for example:
Re: lru/failover path scheduling in mpath(4)
On 15/06/2011, at 8:16 PM, Mark Kettenis wrote: Date: Wed, 15 Jun 2011 18:04:24 +1000 From: David Gwynne l...@animata.net the subject line says it all, but happy to explain further if required. Hmm, I'm somewhat confused: +#define MPATH_ROUNDROBIN0 +#define MPATH_NEXT MPATH_ROUNDROBIN +#define MPATH_LRU 1 ah crap, i mean MRU for most recently used. i dont know why LRU keeps coming out of my fingers. What does MPATH_NEXT mean? Is that the strategy you fall back on if the path you're using fails? What if you have more than 4 paths to a disk with a device that only allows a single active path and one of them fails? Are you suddenly going to try roundrobin scheduling of IOs? if you have a group of four paths and you're doing MRU scheduling, only one of those will be used. if that path goes away (ie, you get XS_SELTIMEOUT from the physical adapter), MPATH_NEXT moves us to the next available path in the group. Also, I don't quite understand what MPATH_LRU would mean. Least Recently Used? How is that different from Round Robin? Don't you need a Last Used policy for devices that can only have a single active path or devices where there is a significant overhead for switching to a different path. round robin uses all available paths, L^HMRU uses only one of the available paths until it fails or goes away. dlg
Re: pf.conf, comments and continuation lines
On 15/06/2011, at 10:16 PM, Jason McIntyre wrote: On Wed, Jun 15, 2011 at 11:09:35AM +0100, Stuart Henderson wrote: On 2011/06/15 10:03, Jason McIntyre wrote: so i guess we're looking for a text only (i.e. no example) solution. here is another stab. nicely crafted words, this is good. ok sthen@ I'll handle the other copies of this if you like. i think it makes sense to do this in one commit, so i'd appreciate if you could do this one too. one thing for consideration: in the text below, i swithered whether the comment takes effect would read better as the comment will take effect. i'm not sure which would be clearer (or read better) for most people. jmc How about the comment is effective until the end of the entire block.? Index: pf.conf.5 === RCS file: /cvs/src/share/man/man5/pf.conf.5,v retrieving revision 1.494 diff -u -r1.494 pf.conf.5 --- pf.conf.5 20 May 2011 22:57:20 - 1.494 +++ pf.conf.5 15 Jun 2011 09:02:10 - @@ -62,9 +62,14 @@ Some example rulesets. .El .Pp +The current line can be extended over multiple lines using a backslash +.Pq Sq \e . Comments can be put anywhere in the file using a hash mark .Pq Sq # , and extend to the end of the current line. +Take care when commenting out text which is part of a multi-line block: +the comment takes effect until the end of the entire block. +.Pp Additional configuration files can be included with the .Ic include keyword, for example:
Re: pf.conf, comments and continuation lines
On Wed, Jun 15, 2011 at 11:16:18AM +0100, Jason McIntyre wrote:
On Wed, Jun 15, 2011 at 11:09:35AM +0100, Stuart Henderson wrote:
On 2011/06/15 10:03, Jason McIntyre wrote:
so i guess we're looking for a text only (i.e. no example) solution.
here is another stab.
nicely crafted words, this is good. ok sthen@
I'll handle the other copies of this if you like.
i think it makes sense to do this in one commit, so i'd appreciate if
you could do this one too.
one thing for consideration: in the text below, i swithered whether
the comment takes effect would read better as the comment will take
effect. i'm not sure which would be clearer (or read better) for most
people.
Maybe the comment remains in effect?
But I think switching concepts from an extended line to
block is a bit fuzzy. I would prefer something like:
Take care when commenting out text which is part
of a multi-line block; the comment will in effect
comment out the remainder of the multi-line block,
unless the backslash is removed in the commented
out line as well.
- or -
Take care when commenting out text which is part
of a multi-line block; the comment will in effect
comment out the remainder of the multi-line block,
unless the backslash is also removed from the line
where the comment marker ('#') is introduced.
--patrick
jmc
Index: pf.conf.5
===
RCS file: /cvs/src/share/man/man5/pf.conf.5,v
retrieving revision 1.494
diff -u -r1.494 pf.conf.5
--- pf.conf.5 20 May 2011 22:57:20 - 1.494
+++ pf.conf.5 15 Jun 2011 09:02:10 -
@@ -62,9 +62,14 @@
Some example rulesets.
.El
.Pp
+The current line can be extended over multiple lines using a backslash
+.Pq Sq \e .
Comments can be put anywhere in the file using a hash mark
.Pq Sq # ,
and extend to the end of the current line.
+Take care when commenting out text which is part of a multi-line block:
+the comment takes effect until the end of the entire block.
+.Pp
Additional configuration files can be included with the
.Ic include
keyword, for example:
Re: pf.conf, comments and continuation lines
so something like this... ok mandoc@ Index: sbin/isakmpd/isakmpd.conf.5 === RCS file: /cvs/src/sbin/isakmpd/isakmpd.conf.5,v retrieving revision 1.127 diff -u -p -r1.127 isakmpd.conf.5 --- sbin/isakmpd/isakmpd.conf.5 22 Sep 2010 13:45:16 - 1.127 +++ sbin/isakmpd/isakmpd.conf.5 15 Jun 2011 11:27:51 - @@ -53,14 +53,13 @@ Inside a section many tag/value pairs ca .Bd -unfilled .Ar Tag Ns = Ns Ar Value .Ed -If the value needs more space than fits on a single line, it's possible to -continue it on the next by ending the first with a backslash character -immediately before the newline character. -This method can extend a value for an arbitrary number of lines. -.Pp -Comments can be put anywhere in the file by using a hash mark -.Pq Sq \# . -The comment extends to the end of the current line. +The current line can be extended over multiple lines using a backslash +.Pq Sq \e . +Comments can be put anywhere in the file using a hash mark +.Pq Sq # , +and extend to the end of the current line. +Take care when commenting out text which is part of a multi-line block: +the comment is effective until the end of the entire block. .Pp Often the right-hand side values consist of other section names. This results in a tree structure. Index: share/man/man5/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 --- share/man/man5/pf.conf.520 May 2011 22:57:20 - 1.494 +++ share/man/man5/pf.conf.515 Jun 2011 11:27:51 - @@ -62,9 +62,14 @@ A method for detecting a host's operatin Some example rulesets. .El .Pp +The current line can be extended over multiple lines using a backslash +.Pq Sq \e . Comments can be put anywhere in the file using a hash mark .Pq Sq # , and extend to the end of the current line. +Take care when commenting out text which is part of a multi-line block: +the comment is effective until the end of the entire block. +.Pp Additional configuration files can be included with the .Ic include keyword, for example: Index: usr.sbin/bgpd/bgpd.conf.5 === RCS file: /cvs/src/usr.sbin/bgpd/bgpd.conf.5,v retrieving revision 1.114 diff -u -p -r1.114 bgpd.conf.5 --- usr.sbin/bgpd/bgpd.conf.5 30 Apr 2011 07:52:33 - 1.114 +++ usr.sbin/bgpd/bgpd.conf.5 15 Jun 2011 11:27:51 - @@ -56,9 +56,13 @@ the sections should be grouped and appea .Nm in the order shown above. .Pp +The current line can be extended over multiple lines using a backslash +.Pq Sq \e . Comments can be put anywhere in the file using a hash mark .Pq Sq # , and extend to the end of the current line. +Take care when commenting out text which is part of a multi-line block: +the comment is effective until the end of the entire block. .Pp Additional configuration files can be included with the .Ic include Index: usr.sbin/hostapd/hostapd.conf.5 === RCS file: /cvs/src/usr.sbin/hostapd/hostapd.conf.5,v retrieving revision 1.37 diff -u -p -r1.37 hostapd.conf.5 --- usr.sbin/hostapd/hostapd.conf.5 16 Apr 2009 20:13:13 - 1.37 +++ usr.sbin/hostapd/hostapd.conf.5 15 Jun 2011 11:27:51 - @@ -47,9 +47,13 @@ The concepts and details about the optio .Xr hostapd 8 . .El .Pp +The current line can be extended over multiple lines using a backslash +.Pq Sq \e . Comments can be put anywhere in the file using a hash mark .Pq Sq # , and extend to the end of the current line. +Take care when commenting out text which is part of a multi-line block: +the comment is effective until the end of the entire block. .Pp Additional configuration files can be included with the .Ic include Index: usr.sbin/ldapd/ldapd.conf.5 === RCS file: /cvs/src/usr.sbin/ldapd/ldapd.conf.5,v retrieving revision 1.13 diff -u -p -r1.13 ldapd.conf.5 --- usr.sbin/ldapd/ldapd.conf.5 28 Jan 2011 09:26:22 - 1.13 +++ usr.sbin/ldapd/ldapd.conf.5 15 Jun 2011 11:27:51 - @@ -28,9 +28,14 @@ is the configuration file for the LDAP daemon .Xr ldapd 8 . .Pp +The current line can be extended over multiple lines using a backslash +.Pq Sq \e . Comments can be put anywhere in the file using a hash mark -.Pq # , +.Pq Sq # , and extend to the end of the current line. +Take care when commenting out text which is part of a multi-line block: +the comment is effective until the end of the entire block. +.Pp Arguments containing whitespace should be surrounded by double quotes .Pq \ . .Pp Index: usr.sbin/relayd/relayd.conf.5 === RCS file: /cvs/src/usr.sbin/relayd/relayd.conf.5,v retrieving revision 1.122 diff -u -p -r1.122 relayd.conf.5 --- usr.sbin/relayd/relayd.conf.5 23 May 2011
Re: dont let sdmmc devices respond to scsi vpd queries
On Wed, Jun 15, 2011 at 01:27:03PM +1000, David Gwynne wrote:
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?
I have several sdmmc devices. What would I look for? i.e. what problem
does this fix?
Ken
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.c 25 Oct 2010 10:36:49 - 1.26
+++ sdmmc_scsi.c 15 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
Re: dont let sdmmc devices respond to scsi vpd queries
On 15/06/2011, at 9:52 PM, Kenneth R Westerback wrote:
On Wed, Jun 15, 2011 at 01:27:03PM +1000, David Gwynne wrote:
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?
I have several sdmmc devices. What would I look for? i.e. what problem
does this fix?
the kernel seems to ignore garbage vpd pages just fine, so you wont see
anything visible in dmesg. if you run
https://svn.itee.uq.edu.au/repo/openbsd-scsidump/ against a card before this
diff you'll see it try to parse the inquiry page as vpd pages cos thats what
the device returns. after the diff it should only show the basic inquiry since
thats all the code emulates.
dlg
Ken
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.c 25 Oct 2010 10:36:49 - 1.26
+++ sdmmc_scsi.c 15 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 *);
+voidsdmmc_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
MSI for em(4)
This is a fairly conservative diff that enables MSI on the newer em(4)
parts, essentially everything handled by the Linux e1000e driver.
Please test if you have anything that's vaguely recent.
Index: if_em.c
===
RCS file: /cvs/src/sys/dev/pci/if_em.c,v
retrieving revision 1.257
diff -u -p -r1.257 if_em.c
--- if_em.c 3 Jun 2011 13:06:06 - 1.257
+++ if_em.c 15 Jun 2011 13:02:14 -
@@ -329,6 +329,10 @@ em_attach(struct device *parent, struct
/* Determine hardware revision */
em_identify_hardware(sc);
+ /* Only use MSIe on the newer PCIe parts */
+ if (sc-hw.mac_type em_82571)
+ pa-pa_flags = ~PCI_FLAGS_MSI_ENABLED;
+
/* Parameters (to be read from user) */
if (sc-hw.mac_type = em_82544) {
sc-num_tx_desc = EM_MAX_TXD;
@@ -1615,7 +1619,7 @@ em_allocate_pci_resources(struct em_soft
}
}
- if (pci_intr_map(pa, ih)) {
+ if (pci_intr_map_msi(pa, ih) pci_intr_map(pa, ih)) {
printf(: couldn't map interrupt\n);
return (ENXIO);
}
Re: Synaptics touchpad
On Tue, Jun 14, 2011 at 09:35:04PM +0200, Matthieu Herrb wrote: 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 ? ^ should be syn-ext_capabilities ;-) -- Alexandr Shadchin
Sandro - Discografía mas Pendrive de Regalo
Sandro y los de fuego Presentando a sandro Al calor de sandro y los de fuego Alma y fuego Beat latino Quiero llenarme de ti Una muchacha y una guitarra La magia de sandro Sandro de america Sandro Muchacho Sandro espectacular Te espero... Sandro Despues de diez antilde;os Siempre sandro Tu me enloqueces Sandro Sandro un idolo Querer como dios manda Sandro Sandro Fue sin querer Vengo a ocupar mi lugar Sandro Volviendo a casa Con gusto a mujer Clasico Historia viva Mis 30 mejores canciones Para mama Mi vida mi musica 15 grandes exitos Coleccion definitivaBaladas de amor / Amor gitano / En vivo / Secretamente palabras de amor / Voces de amor / A cortez, sandro, cerato / Simple y otros (no existe caratula) / 20 grandes exitos / Top50 / Tributo a sandro. un disco de rock / Sorprendente mundo de sandro
Re: Moving WSKBDIO_SETLEDS and WSKBDIO_GETLEDS in wskbd
On Sat, Apr 16, 2011 at 03:16:47AM +0600, Alexandr Shadchin wrote:
Hi,
No need to process WSKBDIO_SETLEDS and WSKBDIO_GETLEDS in each drivers,
when same can be done in wskbd.
Tested on i386 and amd64. Please test on other platforms.
* fix build if not defined WSDISPLAY_COMPAT_RAWKBD
* tested on macppc/atkbd (thank Martin Pieuchot)
Comments ? OK ?
--
Alexandr Shadchin
Index: arch/arm/xscale/pxa27x_kpc.c
===
RCS file: /cvs/src/sys/arch/arm/xscale/pxa27x_kpc.c,v
retrieving revision 1.1
diff -u -p -r1.1 pxa27x_kpc.c
--- arch/arm/xscale/pxa27x_kpc.c9 Sep 2009 12:14:39 - 1.1
+++ arch/arm/xscale/pxa27x_kpc.c15 Jun 2011 17:25:53 -
@@ -27,7 +27,6 @@
#include arch/arm/xscale/pxa27x_kpc.h
int pxa27x_kpc_enable(void *, int);
-void pxa27x_kpc_setleds(void *, int);
int pxa27x_kpc_ioctl(void *, u_long, caddr_t, int, struct proc *);
inline void pxa27x_kpc_submit(struct pxa27x_kpc_softc *, int);
@@ -39,7 +38,7 @@ struct cfdriver pxa27x_kpc_cd = {
struct wskbd_accessops pxa27x_kpc_accessops = {
pxa27x_kpc_enable,
- pxa27x_kpc_setleds,
+ NULL,
pxa27x_kpc_ioctl,
};
@@ -178,11 +177,6 @@ pxa27x_kpc_enable(void *v, int power)
return 0;
}
-void
-pxa27x_kpc_setleds(void *v, int power)
-{
-}
-
int
pxa27x_kpc_ioctl(void *v, u_long cmd, caddr_t data, int flag, struct proc *p)
{
@@ -193,11 +187,6 @@ pxa27x_kpc_ioctl(void *v, u_long cmd, ca
switch (cmd) {
case WSKBDIO_GTYPE:
*(int *)data = WSKBD_TYPE_KPC;
- return 0;
- case WSKBDIO_SETLEDS:
- return 0;
- case WSKBDIO_GETLEDS:
- *(int *)data = 0;
return 0;
#ifdef WSDISPLAY_COMPAT_RAWKBD
case WSKBDIO_SETMODE:
Index: arch/hp300/dev/dnkbd.c
===
RCS file: /cvs/src/sys/arch/hp300/dev/dnkbd.c,v
retrieving revision 1.17
diff -u -p -r1.17 dnkbd.c
--- arch/hp300/dev/dnkbd.c 23 Jul 2009 21:05:56 - 1.17
+++ arch/hp300/dev/dnkbd.c 15 Jun 2011 17:25:54 -
@@ -170,12 +170,16 @@ struct cfattach dnkbd_ca = {
};
intdnkbd_enable(void *, int);
-void dnkbd_set_leds(void *, int);
intdnkbd_ioctl(void *, u_long, caddr_t, int, struct proc *);
+/*
+ * LED not supported. There is only one LED on this keyboard, and
+ * is hardware tied to the caps lock key.
+ */
+
const struct wskbd_accessops dnkbd_accessops = {
dnkbd_enable,
- dnkbd_set_leds,
+ NULL,
dnkbd_ioctl
};
@@ -917,15 +921,6 @@ dnkbd_enable(void *v, int on)
return (0);
}
-void
-dnkbd_set_leds(void *v, int leds)
-{
- /*
-* Not supported. There is only one LED on this keyboard, and
-* is hardware tied to the caps lock key.
-*/
-}
-
int
dnkbd_ioctl(void *v, u_long cmd, caddr_t data, int flag, struct proc *p)
{
@@ -936,11 +931,6 @@ dnkbd_ioctl(void *v, u_long cmd, caddr_t
switch (cmd) {
case WSKBDIO_GTYPE:
*(int *)data = WSKBD_TYPE_DOMAIN;
- return (0);
- case WSKBDIO_SETLEDS:
- return (ENXIO);
- case WSKBDIO_GETLEDS:
- *(int *)data = 0;
return (0);
case WSKBDIO_COMPLEXBELL:
#defined ((struct wskbd_bell_data *)data)
Index: arch/luna88k/dev/lunaws.c
===
RCS file: /cvs/src/sys/arch/luna88k/dev/lunaws.c,v
retrieving revision 1.7
diff -u -p -r1.7 lunaws.c
--- arch/luna88k/dev/lunaws.c 11 Sep 2008 11:30:14 - 1.7
+++ arch/luna88k/dev/lunaws.c 15 Jun 2011 17:25:54 -
@@ -70,7 +70,6 @@ struct ws_softc {
void omkbd_input(void *, int);
void omkbd_decode(void *, int, u_int *, int *);
int omkbd_enable(void *, int);
-void omkbd_set_leds(void *, int);
int omkbd_ioctl(void *, u_long, caddr_t, int, struct proc *);
struct wscons_keydesc omkbd_keydesctab[];
@@ -86,7 +85,7 @@ const struct wskbd_mapdata omkbd_keymapd
const struct wskbd_accessops omkbd_accessops = {
omkbd_enable,
- omkbd_set_leds,
+ NULL,
omkbd_ioctl,
};
@@ -456,18 +455,18 @@ omkbd_enable(v, on)
return 0;
}
+#if notyet
void
omkbd_set_leds(v, leds)
void *v;
int leds;
{
-#if 0
syscnputc((dev_t)1, 0x10); /* kana LED on */
syscnputc((dev_t)1, 0x00); /* kana LED off */
syscnputc((dev_t)1, 0x11); /* caps LED on */
syscnputc((dev_t)1, 0x01); /* caps LED off */
-#endif
}
+#endif
int
omkbd_ioctl(v, cmd, data, flag, p)
@@ -485,8 +484,6 @@ omkbd_ioctl(v, cmd, data, flag, p)
case WSKBDIO_GTYPE:
*(int *)data = WSKBD_TYPE_LUNA;
return 0;
- case WSKBDIO_SETLEDS:
- case WSKBDIO_GETLEDS:
case WSKBDIO_COMPLEXBELL: /* XXX capable of complex bell */
return -1;
}
Index:
Re: Toshiba M30 ACPI support
Hello,
Sending toshiba patch file with the new changes.
Thanks,
Javier.
On Wed, Jun 15, 2011 at 11:03:49AM +0300, Paul Irofti wrote:
On Tue, Jun 14, 2011 at 10:07:54PM +0200, Javier Vazquez wrote:
Hello again,
Sending toshiba acpi patch as Paul has suggested.
Cool!
[--snip--]
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);
You forgot to fix this into:
+ if (!acpi_thinkpad_enabled !acpi_toshiba_enabled)
? 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 15 Jun 2011 19:35:23 -
@@ -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 15 Jun 2011 19:35:24 -
@@ -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 15 Jun 2011 19:35:27 -
@@ -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 15 Jun 2011 19:35:27 -
@@ -716,5 +716,8 @@ struct acpi_ivrs {
#define ACPI_DEV_IBM IBM0068 /* IBM ThinkPad support */
#define ACPI_DEV_LENOVOLEN0068 /* 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_ACPI_ACPIREG_H_ */
Index: dev/acpi/acpitoshiba.c
===
Re: try to refill bnx(4) when all the mbufs are gone
On Wed, Jun 15, 2011 at 07:39:12PM +0100, Stuart Henderson wrote:
On 2011/06/15 14:06, David Gwynne wrote:
this is like the change i did for ix(4)...
Index: if_bnx.c
can i have the if_bnxreg.h part too, please? :)
yes...
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 21:36:46 -
@@ -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--;
/*
Re: sed behavior
that's not relevant to the example because $ matches the empty string at eol, not the character at eol (.$), which is openbsd sed's interpretation even in the case of certain regex standards that do not allow $ to be used as part of a | expression, the interpretation is faulty On Wed, Jun 15, 2011 at 5:54 PM, Stuart Henderson s...@spacehopper.org wrote: On 2011-06-15, Alexander Hall ha...@openbsd.org wrote: This dif fixes your problem here. Big question is of course: does it break other cases? It differs from perl like this: $ echo 'l1_1' | perl -pe 's/1|$/X/g' lX_XX $ echo 'l1_1' | sed -E 's/1|$/X/g' lX_X Meaning we don't hit that final '$' if the last match went to eol. perl regular expressions are expected to behave differently to posix REs.
Re: pf cleanup diff
On Tue, Jun 14, 2011 at 10:23:36PM +0200, Claudio Jeker wrote: 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 Blows up REAL good on my 6xamd64 box. Within a minute or two. I put some debug in and pf_scrub() is being passed a NULL 'm' parameter from pf_test(). Hand transcribed trace: pf_scrub()+0x12 pf_test()+0x93b ipv4_input()+0x22a ipintr()+0x51 netintr()+0xda softintr_dispatch()+0x5d Xsoftnet()+0x2d This box is my nfs server and is using the default pf.conf file as far as I know. Also blew up on my firewall as soon as traffic started transitting it. Same trace as far as I can see. Ken
Re: pf cleanup diff
On Wed, Jun 15, 2011 at 09:50:51PM -0400, Kenneth R Westerback wrote: On Tue, Jun 14, 2011 at 10:23:36PM +0200, Claudio Jeker wrote: 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 Blows up REAL good on my 6xamd64 box. Within a minute or two. I put some debug in and pf_scrub() is being passed a NULL 'm' parameter from pf_test(). Hand transcribed trace: pf_scrub()+0x12 pf_test()+0x93b ipv4_input()+0x22a ipintr()+0x51 netintr()+0xda softintr_dispatch()+0x5d Xsoftnet()+0x2d This box is my nfs server and is using the default pf.conf file as far as I know. Also blew up on my firewall as soon as traffic started transitting it. Same trace as far as I can see. Ken panic'ing my way along the stack I find that the problem starts in pf_reassemble(), when the 'if (!pf_isfull_fragment(frag))' test leaves m0 as NULL and returns PF_PASS to pf_normalize_ip(). *m0 is tested and found to be NULL, so pf_normalize_ip() returns PF_PASS to pf_setup_pdesc(). Where *m0 is tested for NULL and causes *action to be set to PF_PASS and pf_setup_pdesc() to return -1 to pf_test. m is set to *m0 (i.e. NULL) and then pf_test goto's done:. action is PF_PASS and 'if (s)' fails so control passes to the first statement of the else, which is a pf_scrub() call with m being NULL. Boom. Ken
