Re: calendar in Debian
On Thu, Jan 19, 2012 at 05:46:48PM +0100, Otto Moerbeek wrote: Introducing a race is never the right solution, imo. That I totally agree with. By the way, your fix does not catch an included file being a fifo either. So while introducing a race, it actually does not fix the problem. Good point. It seems noone noticed so far. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at googlemail dot com VfL Borussia! ForC'a BarC'a! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: calendar in Debian
On Fri, Jan 20, 2012 at 10:30:01AM +0100, Michael Meskes wrote: On Thu, Jan 19, 2012 at 09:38:06PM +0100, Otto Moerbeek wrote: With a hint from Paul Jantzen I did test this a bit further. There's code to avoid having a child runing too long. If you have 20s patience, you'll see this: calendar: uid 1000 did not finish in time Now that's interesting. I certainly don't see this message. Here's what I did: $ mkfifo c $ ./calendar -f c I killed the program after 40 minutes without any action from it, strace verifies it still waits in open(). Could it be that this works differently on OpenBSD? Yes indeed. Likely we diverged here from net and freebsd. In particular, rev 1.15 op calendar.c and rev 1.13 of io.c are relevant. BTW, there's a slight problem with the current code that kills the child after a timeout. Paul Janzen sent me a diff I'm currently testing. -Otto
Re: calendar in Debian
On Thu, Jan 19, 2012 at 09:41:08PM +0100, Otto Moerbeek wrote: With a hint from Paul Jantzen I did test this a bit further. There's That is, Paul Janzen, sorry about that. code to avoid having a child runing too long. If you have 20s patience, you'll see this: calendar: uid 1000 did not finish in time After reading Paul's explanation I found my mistake. The fix works great for calendar -a but not if you call calendar directly on the named pipe. Of course the latter is not really a problem, so I'm going to remove that patch from our sources. Thanks for the explanations. Any ideas about the other patches? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at googlemail dot com VfL Borussia! ForC'a BarC'a! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: calendar in Debian
On Fri, Jan 20, 2012 at 10:38:35AM +0100, Michael Meskes wrote: On Thu, Jan 19, 2012 at 09:41:08PM +0100, Otto Moerbeek wrote: With a hint from Paul Jantzen I did test this a bit further. There's That is, Paul Janzen, sorry about that. code to avoid having a child runing too long. If you have 20s patience, you'll see this: calendar: uid 1000 did not finish in time After reading Paul's explanation I found my mistake. The fix works great for calendar -a but not if you call calendar directly on the named pipe. Of course the latter is not really a problem, so I'm going to remove that patch from our sources. Thanks for the explanations. Any ideas about the other patches? I don't think I have a chance to look at them the coming time. Any other volunteer here? -Otto
Re: fix ral (and maybe other cards) hostap mode
I will be willing to test any diffs relating to this. I have some soekris with Ral cards which i intended to use in hostap mode. Cheers On Jan 16, 2012 12:13 PM, Steven Chamberlain ste...@pyro.eu.org wrote: On 16/01/12 09:47, Sebastian Reitenbach wrote: this is a followup on the misc@ problem with ral in hopstap mode on -current thread. Thank you! I wasn't subscribed to that list but I mentioned this on bugs@ on 2011-12-10, rum: multiple issues. tcpdump -n -i ral0 -y IEEE802_11_RADIO -vvv ... 17:24:49.225241 802.11: probe request, radiotap v0, tsf 366153760136, 1Mbit/s, chan 1, 11g, antenna 1, signal 65dB 17:24:49.225311 802.11: deauthentication, authentication expired, radiotap v0, 1Mbit/s, chan 1, 11g, antenna 1 17:24:49.225347 802.11: deauthentication, authentication expired, radiotap v0, 1Mbit/s, chan 1, 11g, antenna 1 Same thing I was seeing! I think the flood of deauths from your AP implies the node cache is full, and for some reason it tries but fails to flush anything. At that point no station can (re)associate. So adding this rc=1 on Friday evening, now over the whole weekend, up to this morning, my wireless is working stable now, as it was before with the 4.2. I don't understand how setting 'rc = 1' for beacons/proberesps helped (non-zero means yes, needs an rxnode); I would have expected that to fill the node cache more quickly, and so trigger the bug more often. Figuring this out might be key to understanding some underlying problem... This should prevent entries of the form: nwid chan 3 bssid 00:01:02:03:04:05 0dB 54M in ifconfig if0 scan output, like reported by Rivo Nurges. Have you seen anything like that yourself yet? I found that raising IEEE80211_CACHE_SIZE from its default of 100 in ieee80211_node.h reduces how often the problem occurs, but is not in any way a sensible fix. When debugging the issue it would probably help to lower that value drastically so it is easier to trigger it. Regards, -- Steven Chamberlain ste...@pyro.eu.org
FIX: filedescriptor leak in vi
Hello, this diff fixes a filedescriptor leak in vi. I compiled the code but I could not test the code path. bye, Jan Index: recover.c === RCS file: /mount/cvsdev/cvs/openbsd/src/usr.bin/vi/common/recover.c,v retrieving revision 1.15 diff -u -w -p -r1.15 recover.c --- recover.c 27 Oct 2009 23:59:47 - 1.15 +++ recover.c 20 Jan 2012 10:44:38 - @@ -790,10 +790,13 @@ rcv_copy(sp, wfd, fname) for (off = 0; nr; nr -= nw, off += nw) if ((nw = write(wfd, buf + off, nr)) 0) goto err; + close(rfd); if (nr == 0) return (0); err: msgq_str(sp, M_SYSERR, fname, %s); + if (rfd != -1) + close(rfd); return (1); }
Re: diff: ignore mandatory rx-connect-speed avp
On 01/20/12 11:11, Sebastian Reitenbach wrote: On Friday, January 20, 2012 08:09 CET, YASUOKA Masahiko yasu...@yasuoka.net wrote: add handling of `rx connect speed' avp to ignore the bug of xl2tpd. reported by sebastia@ on misc@. The diff seems correct, ok giovanni@ Cheers Giovanni
Re: small change to the scandir(3) manual page
On Thu, Jan 19, 2012 at 10:17:02AM -0800, Philip Guenther wrote: On Thu, Jan 19, 2012 at 4:18 AM, Edd Barrett vex...@gmail.com wrote: I recently got caught out by scandir's quirky memory allocation. Should we add a note so that others don't have to go through this pain too? Could you elaborate on how this affected your code? I'm trying to think of some way for code to depend on this that isn't undefined behavior by the POSIX standard and (sorry) just a bad idea in practice... Well, if I want to make a copy of a directory entry, I can either memcpy() it or copy attribute by attribute, using strlcpy on the d_name. Memcpy() will segfault sporadically since I'm not told that dirent isn't fully allocated. The problem as I see it is that the man page states builds an array of pointers to directory entries using malloc(3). But the implementation behaves according to IEEE Std 1003.1-2008: Entries for which the function referenced by sel returns non-zero shall be stored in strings allocated as if by a call to malloc() I find strings a bit obscure, but at least it makes it somewhat clearer that one can not just memcpy() based on sizeof(dirent). While helping Edd debug his program, strings gave me enough of a hint to suspect how the implementation works. I would prefer something like: - builds an array of pointers to nul terminated directory entries using malloc(3) - builds an array of pointers to variable-size directory entries using malloc(3) - builds an array of pointers to partially allocated directory entries using malloc(3) however I'm not really happy with these...
Re: small change to the scandir(3) manual page
On Fri, Jan 20, 2012 at 02:34:51PM +0100, Tobias Ulmer wrote: - builds an array of pointers to variable-size directory entries using malloc(3) ^ Something like this could work. Perhaps also a note that we do this because POSIX says so. -- Best Regards Edd Barrett http://www.theunixzoo.co.uk
ix(4) driver Bugfix
Hi!
the ix(4)-Driver stores a pointer to the pci_attach_args structure (as
passed to ixgbe_attach) in its softc. However, the pci_attach_args
structure lives on the stack somewhere in autoconf, i.e. its contents are
undefined after ixgbe_attach returns.
However, the pointer to that data remains in ix_softc and is used at least
in ixgbe_detach. The diff below changes this by storing a copy of the
pci_attach_args in ix_softc.
Tested (with a slightly modified source tree) on x86.
regardsChristian
Index: if_ix.c
===
RCS file: /cvs/src/sys/dev/pci/if_ix.c,v
retrieving revision 1.59
diff -u -p -r1.59 if_ix.c
--- if_ix.c 13 Jan 2012 09:38:23 - 1.59
+++ if_ix.c 20 Jan 2012 14:02:04 -
@@ -209,7 +209,7 @@ ixgbe_attach(struct device *parent, stru
INIT_DEBUGOUT(ixgbe_attach: begin);
sc-osdep.os_sc = sc;
- sc-osdep.os_pa = pa;
+ sc-osdep.os_pa = *pa;
/* Core Lock Init*/
mtx_init(sc-core_mtx, IPL_NET);
@@ -1400,7 +1400,7 @@ void
ixgbe_identify_hardware(struct ix_softc *sc)
{
struct ixgbe_osdep *os = sc-osdep;
- struct pci_attach_args *pa = os-os_pa;
+ struct pci_attach_args *pa = os-os_pa;
uint32_t reg;
/* Save off the information about this board */
@@ -1534,7 +1534,7 @@ ixgbe_allocate_legacy(struct ix_softc *s
{
struct ifnet*ifp = sc-arpcom.ac_if;
struct ixgbe_osdep *os = sc-osdep;
- struct pci_attach_args *pa = os-os_pa;
+ struct pci_attach_args *pa = os-os_pa;
const char *intrstr = NULL;
pci_chipset_tag_t pc = pa-pa_pc;
pci_intr_handle_t ih;
@@ -1576,7 +1576,7 @@ int
ixgbe_allocate_pci_resources(struct ix_softc *sc)
{
struct ixgbe_osdep *os = sc-osdep;
- struct pci_attach_args *pa = os-os_pa;
+ struct pci_attach_args *pa = os-os_pa;
int val;
val = pci_conf_read(pa-pa_pc, pa-pa_tag, PCIR_BAR(0));
@@ -1609,7 +1609,7 @@ void
ixgbe_free_pci_resources(struct ix_softc * sc)
{
struct ixgbe_osdep *os = sc-osdep;
- struct pci_attach_args *pa = os-os_pa;
+ struct pci_attach_args *pa = os-os_pa;
struct ix_queue *que = sc-queues;
int i;
@@ -1749,7 +1749,7 @@ ixgbe_dma_malloc(struct ix_softc *sc, bu
struct ixgbe_osdep *os = sc-osdep;
int r;
- dma-dma_tag = os-os_pa-pa_dmat;
+ dma-dma_tag = os-os_pa.pa_dmat;
r = bus_dmamap_create(dma-dma_tag, size, 1,
size, 0, BUS_DMA_NOWAIT, dma-dma_map);
if (r != 0) {
@@ -3330,7 +3330,7 @@ ixgbe_read_pci_cfg(struct ixgbe_hw *hw,
high = 1;
reg = ~0x2;
}
- pa = ((struct ixgbe_osdep *)hw-back)-os_pa;
+ pa = ((struct ixgbe_osdep *)hw-back)-os_pa;
value = pci_conf_read(pa-pa_pc, pa-pa_tag, reg);
if (high)
@@ -3351,7 +3351,7 @@ ixgbe_write_pci_cfg(struct ixgbe_hw *hw,
high = 1;
reg = ~0x2;
}
- pa = ((struct ixgbe_osdep *)hw-back)-os_pa;
+ pa = ((struct ixgbe_osdep *)hw-back)-os_pa;
rv = pci_conf_read(pa-pa_pc, pa-pa_tag, reg);
if (!high)
rv = (rv 0x) | value;
Index: ixgbe.h
===
RCS file: /cvs/src/sys/dev/pci/ixgbe.h,v
retrieving revision 1.7
diff -u -p -r1.7 ixgbe.h
--- ixgbe.h 10 Jun 2011 12:46:35 - 1.7
+++ ixgbe.h 20 Jan 2012 14:02:04 -
@@ -127,7 +127,7 @@ struct ixgbe_osdep {
bus_addr_t os_membase;
void*os_sc;
- struct pci_attach_args *os_pa;
+ struct pci_attach_args os_pa;
};
extern uint16_t ixgbe_read_pci_cfg(struct ixgbe_hw *, uint32_t);
İngilizceyi öğrenmeyi ihmal etmeyin .
Kanada Kultur Merkezi Zorla ingilizce C6DYreneceksiniz. Ozel Ders Ortamindan Sizde Yararlanin. Yeni Donem Kayitlarimiz Basladi ( Ozel Ders Ortamimiz sizi bekliyor) Indirimli kayit donemi basladi hemen kayit yaptirin erken kayit avantajlarindan faydalanarak ozel ders ortaminda ingilizce ogrenin. KANADA KULTUR MERKEZI 0212 252 90 35 - 36 Adresimiz : Istiklal Caddesi No:104/3 Beyoglu-Istanbul ( Yapi Kredi Kultur Karsisi) 0212 2529035-36
Re: ix(4) driver Bugfix
On Fri, Jan 20, 2012 at 3:08 PM, Christian Ehrhardt christian_ehrha...@genua.de wrote: Hi! the ix(4)-Driver stores a pointer to the pci_attach_args structure (as passed to ixgbe_attach) in its softc. However, the pci_attach_args structure lives on the stack somewhere in autoconf, i.e. its contents are undefined after ixgbe_attach returns. However, the pointer to that data remains in ix_softc and is used at least in ixgbe_detach. The diff below changes this by storing a copy of the pci_attach_args in ix_softc. Tested (with a slightly modified source tree) on x86. regardsChristian yes, i've noticed it today when was working on igb. thankfully it wasn't really used in runtime. thanks a lot for the diff!
Re: small change to the scandir(3) manual page
On Fri, Jan 20, 2012 at 02:33:29PM +, Edd Barrett wrote: On Fri, Jan 20, 2012 at 02:34:51PM +0100, Tobias Ulmer wrote: - builds an array of pointers to variable-size directory entries using malloc(3) ^ Something like this could work. Perhaps also a note that we do this because POSIX says so. Nope, no note. Everybody does that. The way directories work was already set 20 years ago. The only real change POSIX did was standardize the function and struct names, instead of reading directly from the fd into a struct direct.
Re: Scheduler improvements
On Wed, Jan 18, 2012 at 04:41:35PM +0100, Gregor Best wrote:
after a long time of silence here's a second iteration of the patch.
I've addressed a few concerns voiced here:
* Process lookup and friends now have O(log n) runtime. I achieved that
by abusing RB-trees as priority queues since they have runtime
O(log n) in all relevant algorithms.
I'm wondering if a heap tree isn't more suitable. But since they're
currently not in the kernel, I guess the RB tree is the best solution.
* The algorithm for calculating a new deadline for a given process has
been simplified and is now documented a bit better. It also derives
the deadline offset from the value of hz (via rrticks_init) as
suggested by Miod (?).
* CPU rlimits are now honored again. The relevant code did not change, the
new patch just doesn't remove rlimit enforcement anymore.
* Timeslices are 20ms long instead of 10ms. This solves the issue of 0ms
long timeslices on machines with hz 100.
I'm not really happy having timeslices get larger. They're considerably
large already. Can you think of a way to derive a sane value based on
the hz?
With recent improvements in the mainline scheduler and especially
rthreads, the performance of the patched scheduler and mainline is now
roughly similar, at least if throughput is concerned. I have the feeling
that the system behaves snappier with my patch, but that might be some
sort of placebo effect. I haven't yet come up with a reliable method to
benchmark interactivity except for actually using the machine and doing
stuff on it. It's interesting to note however that the patched scheduler
achieves a performance similar to the default one without all the fancy
methods for calculating how expensive it is to move a process from one
CPU to another or related methods for preserving cache locality.
You'll want to test this on a multi-socket machine as well (preferably a
numa machine). You're currently migrating processes using your on-die L3
cache, which is considerably faster than memory.
I use the patched scheduler exclusively on my Core2Duo machine with an
MP build.
The amount of lines removed versus added lines by this patch shifted
towards more added lines but is still at 173 lines less than the
default.
Once again, comments, rants, insults, everything is welcome :)
Comments on the code inline. This is just me glancing over it, I'll try
and get more in-depth over the weekend.
Index: sys/proc.h
===
RCS file: /cvs/src/sys/sys/proc.h,v
retrieving revision 1.149
diff -u -r1.149 proc.h
--- sys/proc.h7 Jan 2012 05:38:12 - 1.149
+++ sys/proc.h17 Jan 2012 16:10:09 -
@@ -43,6 +43,7 @@
#include machine/proc.h/* Machine-dependent proc substruct. */
#include sys/selinfo.h /* For struct selinfo */
#include sys/queue.h
+#include sys/tree.h
#include sys/timeout.h /* For struct timeout */
#include sys/event.h /* For struct klist */
#include sys/mutex.h /* For struct mutex */
@@ -210,7 +211,9 @@
#define PS_SINGLEUNWIND _P_SINGLEUNWIND
struct proc {
- TAILQ_ENTRY(proc) p_runq;
+ RB_ENTRY(proc) p_runq;
+ RB_ENTRY(proc) p_expq;
+ TAILQ_ENTRY(proc) p_slpq;
LIST_ENTRY(proc) p_list;/* List of all processes. */
struct process *p_p; /* The process of this thread. */
@@ -251,6 +254,9 @@
#endif
/* scheduling */
+ struct timeval p_deadline; /* virtual deadline used for scheduling */
+ struct timeval p_deadline_set; /* time at which the deadline was set */
+ int p_rrticks; /* number of ticks this process is allowed to stay on a
processor */
u_int p_estcpu;/* Time averaged value of p_cpticks. */
int p_cpticks; /* Ticks of cpu time. */
fixpt_t p_pctcpu;/* %cpu for this process during p_swtime */
Index: sys/sched.h
===
RCS file: /cvs/src/sys/sys/sched.h,v
retrieving revision 1.30
diff -u -r1.30 sched.h
--- sys/sched.h 16 Nov 2011 20:50:19 - 1.30
+++ sys/sched.h 17 Jan 2012 16:10:09 -
@@ -87,8 +87,6 @@
#define CP_IDLE 4
#define CPUSTATES5
-#define SCHED_NQS 32 /* 32 run queues. */
-
/*
* Per-CPU scheduler state.
* XXX - expose to userland for now.
@@ -99,7 +97,6 @@
u_int spc_schedticks; /* ticks for schedclock() */
u_int64_t spc_cp_time[CPUSTATES]; /* CPU state statistics */
u_char spc_curpriority; /* usrpri of curproc */
- int spc_rrticks;/* ticks until roundrobin() */
int spc_pscnt; /* prof/stat counter */
int spc_psdiv; /* prof/stat divisor */
struct proc *spc_idleproc; /*
Re: Scheduler improvements
On Fri, Jan 20, 2012 at 06:06:08PM +0100, Ariane van der Steldt wrote: * Timeslices are 20ms long instead of 10ms. This solves the issue of 0ms long timeslices on machines with hz 100. I'm not really happy having timeslices get larger. They're considerably large already. Can you think of a way to derive a sane value based on the hz? 20ms slices are a big problem. You only get 50 per second. This will yield all kinds of stroboscopic effects in video applications... (granted, that's probably not an issue on machines with hz100...)
Re: fix ral (and maybe other cards) hostap mode
On 10:23, Edd Barrett wrote:
I will be willing to test any diffs relating to this. I have some soekris
with Ral cards which i intended to use in hostap mode.
Hi,
I think finally we have a solution for this :)
First you'll need to apply the two recent CVS commits by Stefan Sperling,
ieee80211_node.c,v 1.64 and ieee80211_proto.c,v 1.46.
You may then try his 'inactivity' patch included below, otherwise active
stations could be deauthed when the node cache becomes full. There used to be
an LRU list that would caused inactive entries to be removed first, but
unfortunately that is gone so this seems to be necessary instead.
And I suggest applying my small diff which follows it, to fix the behaviour of
the clean_nodes function, otherwise it would have tried to clear more nodes out
of the cache than was intended.
I'm currently trialling these diffs in production, so far with success.
Further testing would be very helpful right now. Thanks!
Index: ieee80211_node.c
===
RCS file: /cvs/src/sys/net80211/ieee80211_node.c,v
retrieving revision 1.64
diff -u -p -r1.64 ieee80211_node.c
--- ieee80211_node.c18 Jan 2012 14:35:34 - 1.64
+++ ieee80211_node.c18 Jan 2012 23:21:30 -
@@ -95,10 +95,35 @@ void ieee80211_node_leave_ht(struct ieee
void ieee80211_node_leave_rsn(struct ieee80211com *, struct ieee80211_node *);
void ieee80211_node_leave_11g(struct ieee80211com *, struct ieee80211_node *);
void ieee80211_set_tim(struct ieee80211com *, int, int);
+void ieee80211_inact_timeout(void *);
#endif
#define M_80211_NODE M_DEVBUF
+#ifndef IEEE80211_STA_ONLY
+void ieee80211_inact_timeout(void *arg)
+{
+ struct ieee80211com *ic = arg;
+ struct ieee80211_node *ni, *next_ni;
+ int s;
+
+ s = splnet();
+ for (ni = RB_MIN(ieee80211_tree, ic-ic_tree);
+ ni != NULL; ni = next_ni) {
+ next_ni = RB_NEXT(ieee80211_tree, ic-ic_tree, ni);
+ if (ni == ic-ic_bss)
+ continue;
+ if (ni-ni_refcnt 0)
+ continue;
+ if (ni-ni_inact IEEE80211_INACT_MAX)
+ ni-ni_inact++;
+ }
+ splx(s);
+
+ timeout_add_sec(ic-ic_inact_timeout, IEEE80211_INACT_WAIT);
+}
+#endif
+
void
ieee80211_node_attach(struct ifnet *ifp)
{
@@ -138,6 +163,8 @@ ieee80211_node_attach(struct ifnet *ifp)
ic-ic_set_tim = ieee80211_set_tim;
timeout_set(ic-ic_rsn_timeout,
ieee80211_gtk_rekey_timeout, ic);
+ timeout_set(ic-ic_inact_timeout,
+ ieee80211_inact_timeout, ic);
}
#endif
}
@@ -185,6 +212,7 @@ ieee80211_node_detach(struct ifnet *ifp)
free(ic-ic_aid_bitmap, M_DEVBUF);
if (ic-ic_tim_bitmap != NULL)
free(ic-ic_tim_bitmap, M_DEVBUF);
+ timeout_del(ic-ic_inact_timeout);
#endif
timeout_del(ic-ic_rsn_timeout);
}
@@ -378,6 +406,7 @@ ieee80211_create_ibss(struct ieee80211co
/* schedule a GTK/IGTK rekeying after 3600s */
timeout_add_sec(ic-ic_rsn_timeout, 3600);
}
+ timeout_add_sec(ic-ic_inact_timeout, IEEE80211_INACT_WAIT);
ieee80211_new_state(ic, IEEE80211_S_RUN, -1);
}
#endif /* IEEE80211_STA_ONLY */
@@ -771,20 +800,7 @@ ieee80211_setup_node(struct ieee80211com
timeout_set(ni-ni_eapol_to, ieee80211_eapol_timeout, ni);
timeout_set(ni-ni_sa_query_to, ieee80211_sa_query_timeout, ni);
#endif
-
- /*
-* Note we don't enable the inactive timer when acting
-* as a station. Nodes created in this mode represent
-* AP's identified while scanning. If we time them out
-* then several things happen: we can't return the data
-* to users to show the list of AP's we encountered, and
-* more importantly, we'll incorrectly deauthenticate
-* ourself because the inactivity timer will kick us off.
-*/
s = splnet();
- if (ic-ic_opmode != IEEE80211_M_STA
- RB_EMPTY(ic-ic_tree))
- ic-ic_inact_timer = IEEE80211_INACT_WAIT;
RB_INSERT(ieee80211_tree, ic-ic_tree, ni);
splx(s);
}
@@ -1067,8 +1083,6 @@ ieee80211_free_node(struct ieee80211com
(*ic-ic_set_tim)(ic, ni-ni_associd, 0);
}
#endif
- if (RB_EMPTY(ic-ic_tree))
- ic-ic_inact_timer = 0;
(*ic-ic_node_free)(ic, ni);
/* TBD indicate to drivers that a new node can be allocated */
}
@@ -1125,6 +1139,13 @@ ieee80211_clean_nodes(struct ieee80211co
ni-ni_scangen = gen;
if (ni-ni_refcnt 0)
continue;
+#ifndef IEEE80211_STA_ONLY
+ if ((ic-ic_opmode == IEEE80211_M_HOSTAP ||
+ ic-ic_opmode == IEEE80211_M_IBSS)
+ ic-ic_state == IEEE80211_S_RUN
+
Re: fix ral (and maybe other cards) hostap mode
On Fri, Jan 20, 2012 at 06:57:54PM +, Steven Chamberlain wrote:
On 10:23, Edd Barrett wrote:
I will be willing to test any diffs relating to this. I have some soekris
with Ral cards which i intended to use in hostap mode.
Hi,
I think finally we have a solution for this :)
First you'll need to apply the two recent CVS commits by Stefan Sperling,
ieee80211_node.c,v 1.64 and ieee80211_proto.c,v 1.46.
You may then try his 'inactivity' patch included below, otherwise active
stations could be deauthed when the node cache becomes full. There used to
be an LRU list that would caused inactive entries to be removed first, but
unfortunately that is gone so this seems to be necessary instead.
And I suggest applying my small diff which follows it, to fix the behaviour
of the clean_nodes function, otherwise it would have tried to clear more
nodes out of the cache than was intended.
I'm currently trialling these diffs in production, so far with success.
Further testing would be very helpful right now. Thanks!
Please try this diff instead with whatever hostap-capable card you've got.
It includes Steven's change (which is very good) and some more of my own.
Index: ieee80211_node.c
===
RCS file: /cvs/src/sys/net80211/ieee80211_node.c,v
retrieving revision 1.64
diff -u -p -r1.64 ieee80211_node.c
--- ieee80211_node.c18 Jan 2012 14:35:34 - 1.64
+++ ieee80211_node.c20 Jan 2012 17:44:02 -
@@ -95,10 +95,46 @@ void ieee80211_node_leave_ht(struct ieee
void ieee80211_node_leave_rsn(struct ieee80211com *, struct ieee80211_node *);
void ieee80211_node_leave_11g(struct ieee80211com *, struct ieee80211_node *);
void ieee80211_set_tim(struct ieee80211com *, int, int);
+void ieee80211_inact_timeout(void *);
+void ieee80211_node_cache_timeout(void *);
#endif
#define M_80211_NODE M_DEVBUF
+#ifndef IEEE80211_STA_ONLY
+void
+ieee80211_inact_timeout(void *arg)
+{
+ struct ieee80211com *ic = arg;
+ struct ieee80211_node *ni, *next_ni;
+ int s;
+
+ s = splnet();
+ for (ni = RB_MIN(ieee80211_tree, ic-ic_tree);
+ ni != NULL; ni = next_ni) {
+ next_ni = RB_NEXT(ieee80211_tree, ic-ic_tree, ni);
+ if (ni == ic-ic_bss)
+ continue;
+ if (ni-ni_refcnt 0)
+ continue;
+ if (ni-ni_inact IEEE80211_INACT_MAX)
+ ni-ni_inact++;
+ }
+ splx(s);
+
+ timeout_add_sec(ic-ic_inact_timeout, IEEE80211_INACT_WAIT);
+}
+
+void
+ieee80211_node_cache_timeout(void *arg)
+{
+ struct ieee80211com *ic = arg;
+
+ ieee80211_clean_nodes(ic, 1);
+ timeout_add_sec(ic-ic_node_cache_timeout, IEEE80211_CACHE_WAIT);
+}
+#endif
+
void
ieee80211_node_attach(struct ifnet *ifp)
{
@@ -138,6 +174,10 @@ ieee80211_node_attach(struct ifnet *ifp)
ic-ic_set_tim = ieee80211_set_tim;
timeout_set(ic-ic_rsn_timeout,
ieee80211_gtk_rekey_timeout, ic);
+ timeout_set(ic-ic_inact_timeout,
+ ieee80211_inact_timeout, ic);
+ timeout_set(ic-ic_node_cache_timeout,
+ ieee80211_node_cache_timeout, ic);
}
#endif
}
@@ -147,7 +187,7 @@ ieee80211_alloc_node_helper(struct ieee8
{
struct ieee80211_node *ni;
if (ic-ic_nnodes = ic-ic_max_nnodes)
- ieee80211_clean_nodes(ic);
+ ieee80211_clean_nodes(ic, 0);
if (ic-ic_nnodes = ic-ic_max_nnodes)
return NULL;
ni = (*ic-ic_node_alloc)(ic);
@@ -185,6 +225,8 @@ ieee80211_node_detach(struct ifnet *ifp)
free(ic-ic_aid_bitmap, M_DEVBUF);
if (ic-ic_tim_bitmap != NULL)
free(ic-ic_tim_bitmap, M_DEVBUF);
+ timeout_del(ic-ic_inact_timeout);
+ timeout_del(ic-ic_node_cache_timeout);
#endif
timeout_del(ic-ic_rsn_timeout);
}
@@ -378,6 +420,8 @@ ieee80211_create_ibss(struct ieee80211co
/* schedule a GTK/IGTK rekeying after 3600s */
timeout_add_sec(ic-ic_rsn_timeout, 3600);
}
+ timeout_add_sec(ic-ic_inact_timeout, IEEE80211_INACT_WAIT);
+ timeout_add_sec(ic-ic_node_cache_timeout, IEEE80211_CACHE_WAIT);
ieee80211_new_state(ic, IEEE80211_S_RUN, -1);
}
#endif /* IEEE80211_STA_ONLY */
@@ -771,20 +815,7 @@ ieee80211_setup_node(struct ieee80211com
timeout_set(ni-ni_eapol_to, ieee80211_eapol_timeout, ni);
timeout_set(ni-ni_sa_query_to, ieee80211_sa_query_timeout, ni);
#endif
-
- /*
-* Note we don't enable the inactive timer when acting
-* as a station. Nodes created in this mode represent
-* AP's identified while scanning. If we time them out
-* then several things happen: we can't return the data
-* to users to show the list of AP's we encountered, and
-*
Re: Only noise from azalia
On Wed, Jan 18, 2012 at 09:41:03AM -0200, Daniel Bolgheroni wrote:
On Tue, Jan 17, 2012 at 02:24:19PM -0200, Jairo Souto wrote:
I have been tried all bsd.mp from
ftp.openbsd.org:/pub/OpenBSD/snapshots/amd64/bsd.mp
Are you running 4.9 or -current?
4.9
misc@ did not answer...
Usually, people in tech@ are in misc@ too. They probably won't because
you're running a custom built kernel. Please see:
http://www.openbsd.org/faq/faq5.html#WhySrc
I run the kernel customized to get an
HUAWEI cellular modem to run. Only the files
sys/dev/usb/{umsm.c,usbdevs.h,usbdevs,usbdevs_data.h} were
changed.
Thank you.
--Jairo Souto (38)8816-1254
