iwn(4) support for Intel WiFi Link 1030/Centrino Wireless-N 1030
Anybody around with the (currently non-working) Intel WiFi Link 1030
wireless hardware that can test the following diff? You'll need an
up-to-date firmware pckage and a bleeding edge -current tree.
Cheers,
Mark
Index: if_iwn.c
===
RCS file: /cvs/src/sys/dev/pci/if_iwn.c,v
retrieving revision 1.116
diff -u -p -r1.116 if_iwn.c
--- if_iwn.c14 Nov 2012 12:30:19 - 1.116
+++ if_iwn.c14 Nov 2012 12:40:37 -
@@ -639,7 +639,9 @@ iwn5000_attach(struct iwn_softc *sc, pci
break;
case IWN_HW_REV_TYPE_6005:
sc-limits = iwn6000_sensitivity_limits;
- if (pid == PCI_PRODUCT_INTEL_WL_6030_1 ||
+ if (pid == PCI_PRODUCT_INTEL_WL_1030_1 ||
+ pid == PCI_PRODUCT_INTEL_WL_1030_2 ||
+ pid == PCI_PRODUCT_INTEL_WL_6030_1 ||
pid == PCI_PRODUCT_INTEL_WL_6030_2 ||
pid == PCI_PRODUCT_INTEL_WL_6235_1) {
sc-fwname = iwn-6030;
Re: add intel 6235 support to iwn(4)
Date: Tue, 13 Nov 2012 21:02:24 -0500
From: James Turner ja...@calminferno.net
I was actually able to add support myself with the following diff.
Great!
Committed an improved diff that also adds the other 6030 variant.
Index: if_iwn.c
===
RCS file: /cvs/src/sys/dev/pci/if_iwn.c,v
retrieving revision 1.115
diff -u -p if_iwn.c
--- if_iwn.c 11 Nov 2012 20:45:31 - 1.115
+++ if_iwn.c 14 Nov 2012 02:00:52 -
@@ -639,7 +639,8 @@ iwn5000_attach(struct iwn_softc *sc, pci_product_id_t
break;
case IWN_HW_REV_TYPE_6005:
sc-limits = iwn6000_sensitivity_limits;
- if (pid == PCI_PRODUCT_INTEL_WL_6235_1) {
+ if (pid == PCI_PRODUCT_INTEL_WL_6235_1 ||
+ pid == PCI_PRODUCT_INTEL_WL_6030_2) {
sc-fwname = iwn-6030;
/* XXX: The 6235 generates a fatal firmware error when
Re: Make cron supply valid RFC822 From: and To: headers
On Tue, 13 Nov 2012 11:02:00 +0100, Alexander Hall wrote: Since I switched to SMTPD I noticed a few cron emails being marked as spam by spamassassin, largely caused by the From: and To: headers not containing a domain part. Sendmail will add the domain if the always_add_domain feature is enabled (as it is in our default config). If I read RFC822 correctly, the domain part is not optional, and thus we should append one, unless MAILTO already specifies one. Historical reasons from the land of pre-smtp why I'm wrong? Historically, cron has been able to work with non-internet mailers that simply write to the local spool file. It seems like smtpd should add the domain for locally-generated messages if one is missing. - todd
patch: pf source-hash/random with dynamic address pools
Hi!
pf currently only supports the round-robin and least-states methods
when using dynamic address pools like tables or interface pools. The
following diff adds support for source-hash and random with dynamic
pools. source-hash can be used in some cases as an alternative to
sticky-address to get mapping stability without the extra memory
cost. In contrast to sticky-address, it can also guarantee the same
mapping after reloading or flushing pf. random is useful for some
security applications, testing and kind of the counterpart to the
prob keyword.
I already got positive feedback for this diff from mcbride@ and jmc@,
but I'd like to get feedback and testing from a few more people here
on tech@. And some OKs from OpenBSD hackers, of course :-)
btw.: This will also fix the first relayd: add new load balancing
scheduling algorithms diff that I sent to tech@ one month ago.
reyk
Index: share/man/man5/pf.conf.5
===
RCS file: /cvs/src/share/man/man5/pf.conf.5,v
retrieving revision 1.523
diff -u -p -r1.523 pf.conf.5
--- share/man/man5/pf.conf.518 Oct 2012 15:18:56 - 1.523
+++ share/man/man5/pf.conf.514 Nov 2012 14:07:30 -
@@ -1040,10 +1040,8 @@ from modifying the source port on TCP an
.El
.Pp
When more than one redirection address or a table is specified,
-.Ar round-robin
-and
-.Ar least-states
-are the only permitted pool types.
+.Ar bitmask
+is not permitted as a pool type.
.Ss Routing
If a packet matches a rule with one of the following route options set,
the packet filter will route the packet according to the type of route option.
@@ -1724,10 +1722,8 @@ They can also be used for the redirect a
.Ar nat-to
and
.Ar rdr-to
-and in the routing options of filter rules, but only for
-.Ar least-states
-and
-.Ar round-robin
+and in the routing options of filter rules, but not for
+.Ar bitmask
pools.
.Pp
Tables can be defined with any of the following
Index: sys/net/pf_lb.c
===
RCS file: /cvs/src/sys/net/pf_lb.c,v
retrieving revision 1.21
diff -u -p -r1.21 pf_lb.c
--- sys/net/pf_lb.c 9 Jul 2012 15:20:57 - 1.21
+++ sys/net/pf_lb.c 14 Nov 2012 14:07:31 -
@@ -99,7 +99,7 @@
* Global variables
*/
-voidpf_hash(struct pf_addr *, struct pf_addr *,
+u_int32_t pf_hash(struct pf_addr *, struct pf_addr *,
struct pf_poolhashkey *, sa_family_t);
int pf_get_sport(struct pf_pdesc *, struct pf_rule *,
struct pf_addr *, u_int16_t *, u_int16_t,
@@ -124,7 +124,7 @@ int pf_islinklocal(sa_family_t, struc
/*
* hash function based on bridge_hash in if_bridge.c
*/
-void
+u_int32_t
pf_hash(struct pf_addr *inaddr, struct pf_addr *hash,
struct pf_poolhashkey *key, sa_family_t af)
{
@@ -137,7 +137,7 @@ pf_hash(struct pf_addr *inaddr, struct p
b += key-key32[1];
mix(a, b, c);
hash-addr32[0] = c + key-key32[2];
- break;
+ return (hash-addr32[0]);
#endif /* INET */
#ifdef INET6
case AF_INET6:
@@ -160,9 +160,10 @@ pf_hash(struct pf_addr *inaddr, struct p
c += key-key32[3];
mix(a, b, c);
hash-addr32[3] = c;
- break;
+ return (c);
#endif /* INET6 */
}
+ return (0);
}
int
@@ -258,8 +259,8 @@ pf_get_sport(struct pf_pdesc *pd, struct
init_addr, sn, r-nat, PF_SN_NAT))
return (1);
break;
- case PF_POOL_NONE:
case PF_POOL_SRCHASH:
+ case PF_POOL_NONE:
case PF_POOL_BITMASK:
default:
return (1);
@@ -290,6 +291,8 @@ pf_map_addr(sa_family_t af, struct pf_ru
u_int16_tweight;
u_int64_tload;
u_int64_tcload;
+ u_int32_thashidx;
+ int cnt;
if (sns[type] == NULL rpool-opts PF_POOL_STICKYADDR
(rpool-opts PF_POOL_TYPEMASK) != PF_POOL_NONE) {
@@ -321,10 +324,7 @@ pf_map_addr(sa_family_t af, struct pf_ru
#ifdef INET
case AF_INET:
if (rpool-addr.p.dyn-pfid_acnt4 1
- ((rpool-opts PF_POOL_TYPEMASK) !=
- PF_POOL_ROUNDROBIN)
- ((rpool-opts PF_POOL_TYPEMASK) !=
- PF_POOL_LEASTSTATES))
+ !PF_POOL_DYNTYPE(rpool-opts))
return (1);
raddr = rpool-addr.p.dyn-pfid_addr4;
rmask = rpool-addr.p.dyn-pfid_mask4;
@@ -333,10 +333,7 @@ pf_map_addr(sa_family_t af, struct pf_ru
#ifdef INET6
Re: Intel azalia(4) and MSI
On Fri, Sep 28, 2012 at 12:07:31AM -0400, Brad Smith wrote:
On Fri, Sep 28, 2012 at 04:06:32AM +0200, Mark Kettenis wrote:
Date: Mon, 24 Sep 2012 03:49:41 -0400
From: Brad Smith b...@comstyle.com
I've always wondered why this workaround was not removed once MSI
support was added. This was added before we had MSI support to
workaround some Intel azalia(4) being setup by the BIOS as far
as I know to use MSI and thus interrupts on system that were
affected by this did not work at all for azalia(4).
Because there still are conditions under which we would not be able to
use MSI.
I had 6 people reply off list indicating their Intel azalia controllers
didn't seem to have any regressions with the previous diff applied.
Can you expand upon this and explain what you mean. What are these
conditions? It would be nice to mention what those conditions are
within the comment.
Perhaps we should change the generic PCI code to explicitly disable
MSIs if they are turned on. But until we do that, this workaround
needs to stay in place.
Since MSI is being disabled for the Intel azalia controller and the
datasheet does confirm that is what this code is doing shouldn't
we be telling the PCI layer MSI is disabled too like so? It doesn't
make sense to have MSI disabled for the controller and then the
PCI layer still thinking MSI should be used.
ping.
Index: azalia.c
===
RCS file: /home/cvs/src/sys/dev/pci/azalia.c,v
retrieving revision 1.201
diff -u -p -r1.201 azalia.c
--- azalia.c 12 Aug 2012 19:32:22 - 1.201
+++ azalia.c 28 Sep 2012 02:17:31 -
@@ -515,6 +515,7 @@ azalia_pci_attach(struct device *parent,
/* disable MSI, use INTx instead */
if (PCI_VENDOR(sc-pciid) == PCI_VENDOR_INTEL) {
+ pa-pa_flags = ~PCI_FLAGS_MSI_ENABLED;
reg = azalia_pci_read(sc-pc, sc-tag, ICH_PCI_MMC);
reg = ~(ICH_PCI_MMC_ME);
azalia_pci_write(sc-pc, sc-tag, ICH_PCI_MMC, reg);
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Re: Intel azalia(4) and MSI
Date: Wed, 14 Nov 2012 22:30:48 -0500 From: Brad Smith b...@comstyle.com On Fri, Sep 28, 2012 at 12:07:31AM -0400, Brad Smith wrote: On Fri, Sep 28, 2012 at 04:06:32AM +0200, Mark Kettenis wrote: Date: Mon, 24 Sep 2012 03:49:41 -0400 From: Brad Smith b...@comstyle.com I've always wondered why this workaround was not removed once MSI support was added. This was added before we had MSI support to workaround some Intel azalia(4) being setup by the BIOS as far as I know to use MSI and thus interrupts on system that were affected by this did not work at all for azalia(4). Because there still are conditions under which we would not be able to use MSI. I had 6 people reply off list indicating their Intel azalia controllers didn't seem to have any regressions with the previous diff applied. Can you expand upon this and explain what you mean. What are these conditions? It would be nice to mention what those conditions are within the comment. Perhaps we should change the generic PCI code to explicitly disable MSIs if they are turned on. But until we do that, this workaround needs to stay in place. Since MSI is being disabled for the Intel azalia controller and the datasheet does confirm that is what this code is doing shouldn't we be telling the PCI layer MSI is disabled too like so? It doesn't make sense to have MSI disabled for the controller and then the PCI layer still thinking MSI should be used. You clearly don't understand how the code works. The flag indicates whether MSIs are supported by the host bridge (and the device). Not whether MSIs are actually enabled on the device. The PCI layer will turn MSIs back on if it decides to use them. We just want to make sure MSIs aren't accidentally enabled when we decide not to use them. Something that apparently happened on some machines with Intel HD Audio.
