no background scan while waiting for mgt frame
Don't start a background scan while we're waiting for a response from
the AP to a management frame we have sent.
In particular, the logic which tries to detect dead APs might be waiting
for a probe response from the AP. Starting a background scan in this state
won't do any good. In case of iwn(4) it seems to result in an endless
scan command dance with the firwmare.
Associated:
Jun 6 10:37:03 jim /bsd: iwn0: missed beacon threshold set to 7 beacons,
beacon interval is 100 TU
Got "beacon miss" interrupt from firmware; sending probe req to AP to check
if AP is still alive:
Jun 6 10:37:04 jim /bsd: iwn0: sending probe_req to 00:25:56:73:b7:a2 on
channel 1 mode 11n
Meanwhile, low signal of received frames kicks off a background scan:
Jun 6 10:37:05 jim /bsd: iwn0: begin background scan
Response from AP never arrived; interface watchdog moves to SCAN state
while background scan isn't done yet:
Jun 6 10:37:09 jim /bsd: iwn0: RUN -> SCAN
Driver issues SCAN_ABORT and SCAN commands here.
Jun 6 10:37:09 jim /bsd: iwn0: end active scan
Jun 6 10:37:09 jim /bsd: iwn0: SCAN -> SCAN
Jun 6 10:37:09 jim /bsd: iwn0: end active scan
Driver issues SCAN command here.
Jun 6 10:37:09 jim /bsd: iwn0: SCAN -> SCAN
Jun 6 10:37:09 jim /bsd: iwn0: end passive scan
Driver issues SCAN command here.
Jun 6 10:37:09 jim /bsd: iwn0: SCAN -> SCAN
Jun 6 10:37:09 jim /bsd: iwn0: end passive scan
Driver issues SCAN command here.
Jun 6 10:37:09 jim /bsd: iwn0: SCAN -> SCAN
Jun 6 10:37:09 jim /bsd: iwn0: end passive scan
Driver issues SCAN command here.
These SCAN -> SCAN transitions go on forever until the interface is put down.
For some reason we never get scan results from firmware.
So this diff is merely masking an actual driver bug; but such bugs are
hard to fix without really understanding how firmware's SCAN, SCAN_ABORT
commands and "scan done" interrupts interact.
I suppose asking Intel for docs would be an exercise in futility...
Fortunately, it is easy to avoid this situation in the first place.
Note that the inverse case (ignore "missed beacon" events while a background
scan is in progress) must be fixed separately in the driver, not the stack.
OK?
diff c3669ebdb8dc5ae83ec861abde2c7a1cf357a580 /usr/src
blob - f0e9b2ba482a96a5d7deb442d094f6ecc63afec0
file + sys/net80211/ieee80211.c
--- sys/net80211/ieee80211.c
+++ sys/net80211/ieee80211.c
@@ -75,7 +75,7 @@ ieee80211_begin_bgscan(struct ifnet *ifp)
struct ieee80211com *ic = (void *)ifp;
if ((ic->ic_flags & IEEE80211_F_BGSCAN) ||
- ic->ic_state != IEEE80211_S_RUN)
+ ic->ic_state != IEEE80211_S_RUN || ic->ic_mgt_timer != 0)
return;
if (ic->ic_bgscan_start != NULL && ic->ic_bgscan_start(ic) == 0) {
Re: Waiting for 'high priority' events with kqueue
Date: Mon, 15 Jun 2015 12:59:50 +1000
From: Daurnimator q...@daurnimator.com
On 14 June 2015 at 14:51, Philip Guenther guent...@gmail.com wrote:
On Wed, Jun 10, 2015 at 10:21 PM, Daurnimator q...@daurnimator.com wrote:
I'm working on adding support for high priority events to a user space
event library.
Conceptually, I need the equivalent of poll() with POLLPRI, but via kqueue.
POLLPRI only works for STREAMS. What sort of fd are you using this
on? What does it *mean*?
On OpenBSD POLLPRI and POLLRDBAND effectively are the same thing.
Pretty much means that there is OOB data to be read from a socket.
Other than hat, only some obscure pty code will generate them.
Whatever it would mean to use POLLPRI with poll().
Or a slightly looser criteria: whatever the equivalent to the 3rd set
to select() means.
== On OpenBSD, this is equivalent to POLLPRI:
http://fxr.watson.org/fxr/source/kern/sys_generic.c?v=OPENBSD#L744
FreeBSD and Apple OSX provide this via the 'EV_OOBAND' flag to EV_SET.
Uh, I just checked against FreeBSD subversion I don't see an EV_OOBAND
in their kqueue(2) manpage or sys/event.h. What version did you see
this in?
Sorry, I was confused on this point; I actually only saw it in the OSX
sources:
On OSX, poll() with POLLPRI is actually implemented **using** kqueue
with EV_OOBAND.
See:
http://fxr.watson.org/fxr/source/bsd/kern/sys_generic.c?v=xnu-1699.24.8#L149
Is there a way to wait for high priority events with kqueue on OpenBSD?
Lacking a definition for high priority, no.
I had a read through various kernel sources, but didn't manage to find
anything.
Could OpenBSD add support for the EV_OOBAND flag?
What Problem Are You Trying To Solve?
I'm using this inside an event handling library/framework.
It uses a kqueue rather than poll() or select() under the hood.
The users of our API expect that they'd get the same behaviour as if
they used poll directly themselves.
Most users don't actually expect OOB data. It's generally a bad idea
to use it, since there are subtle difference between OSes, it is
probably unwise for people to use this feature.
Who is responsible for these sorts of things?
Whomever is convinced it's worthwhile. Lacking a definition, it
certainly can't be.
Philip Guenther
The issue is one of feature parity. On posix-y systems, there are
multiple ways to wait for an event on a file descriptor.
- select(), which takes a 'readable' set (equivalent to POLLIN), a
'writable' set (equivalent to POLLOUT), and a 'error' set (POLLPRI +
some others depending on OS)
- poll(), which takes POLL{IN,RDNORM, RDBAND, PRI, OUT, WRNORM, WRBAND}
- Linux only: epoll(), which takes the same flags as poll()
- Solaris only: port with PORT_SOURCE_FD, which takes the same flags as
poll()
- BSDs: kqueue: which has EVFILT_READ (with default flags is
equivalent to POLLIN) and EVFILT_WRITE (equivalent to POLLOUT)
Any given single threaded program generally has to pick one of the
above, and use it throughout.
The platform specific options (epoll, ports, kqueue) are generally
more performant.
The issue I'm trying to solve is: if a program needs to poll for
priority events (i.e. POLLPRI) on OpenBSD, they have to use select()
or poll(); it takes the kqueue option off the table.
I'd like to fix this.
My suggested fix was to add the same API as OSX; i.e. EV_OOBAND flag,
which causes kqueue's EVFILT_READ to act like it was given POLLPRI
instead of just POLLIN.
But anything else that adds the ability would be fine too :)
Well, given
https://blog.sandstorm.io/news/2015-04-08-osx-security-bug.html
I'd say, no. In fact, that article suggests this interface is no
longer supported in OS X either.
The article indicates that DagonFlyBSD has EVFILT_EXCEPT to signal OOB
data. That would probably be a better choice. But as I said, the OOB
data mechanism is an obscure feature and I'm not convinced that this
is worth spending time on.
Re: Waiting for 'high priority' events with kqueue
On 15 June 2015 at 22:40, Mark Kettenis mark.kette...@xs4all.nl wrote:
I'm using this inside an event handling library/framework.
It uses a kqueue rather than poll() or select() under the hood.
The users of our API expect that they'd get the same behaviour as if
they used poll directly themselves.
Most users don't actually expect OOB data. It's generally a bad idea
to use it, since there are subtle difference between OSes, it is
probably unwise for people to use this feature.
Sometimes you need it; invariably, if the OS offers it, someone will
come to need it.
e.g. this was recently fast tracked, as someone needed to poll the
sysfs on linux (which requires POLLPRI)
However (as a good cross platform library should), we're trying to add
baseline support for POLLPRI across all our targets.
The issue is one of feature parity. On posix-y systems, there are
multiple ways to wait for an event on a file descriptor.
- select(), which takes a 'readable' set (equivalent to POLLIN), a
'writable' set (equivalent to POLLOUT), and a 'error' set (POLLPRI +
some others depending on OS)
- poll(), which takes POLL{IN,RDNORM, RDBAND, PRI, OUT, WRNORM, WRBAND}
- Linux only: epoll(), which takes the same flags as poll()
- Solaris only: port with PORT_SOURCE_FD, which takes the same flags as
poll()
- BSDs: kqueue: which has EVFILT_READ (with default flags is
equivalent to POLLIN) and EVFILT_WRITE (equivalent to POLLOUT)
Any given single threaded program generally has to pick one of the
above, and use it throughout.
The platform specific options (epoll, ports, kqueue) are generally
more performant.
The issue I'm trying to solve is: if a program needs to poll for
priority events (i.e. POLLPRI) on OpenBSD, they have to use select()
or poll(); it takes the kqueue option off the table.
I'd like to fix this.
My suggested fix was to add the same API as OSX; i.e. EV_OOBAND flag,
which causes kqueue's EVFILT_READ to act like it was given POLLPRI
instead of just POLLIN.
But anything else that adds the ability would be fine too :)
Well, given
https://blog.sandstorm.io/news/2015-04-08-osx-security-bug.html
I'd say, no. In fact, that article suggests this interface is no
longer supported in OS X either.
I do recall that bug, I'm not sure what the fix the distributed ended up being.
The article indicates that DagonFlyBSD has EVFILT_EXCEPT to signal OOB
data. That would probably be a better choice. But as I said, the OOB
data mechanism is an obscure feature and I'm not convinced that this
is worth spending time on.
Ah ha! EVFILT_EXCEPT seems a much nicer solution to the problem.
Would OpenBSD consider adding support for it?
(as I mentioned above, I don't care *how* it's done, just that the
general facility is available via kqueue)
Daurn.
Re: Waiting for 'high priority' events with kqueue
On Wed, Jun 10, 2015 at 10:21 PM, Daurnimator q...@daurnimator.com wrote: I'm working on adding support for high priority events to a user space event library. Conceptually, I need the equivalent of poll() with POLLPRI, but via kqueue. POLLPRI only works for STREAMS. What sort of fd are you using this on? What does it *mean*? FreeBSD and Apple OSX provide this via the 'EV_OOBAND' flag to EV_SET. Uh, I just checked against FreeBSD subversion I don't see an EV_OOBAND in their kqueue(2) manpage or sys/event.h. What version did you see this in? Is there a way to wait for high priority events with kqueue on OpenBSD? Lacking a definition for high priority, no. I had a read through various kernel sources, but didn't manage to find anything. Could OpenBSD add support for the EV_OOBAND flag? What Problem Are You Trying To Solve? Who is responsible for these sorts of things? Whomever is convinced it's worthwhile. Lacking a definition, it certainly can't be. Philip Guenther
Waiting for 'high priority' events with kqueue
Hi, I'm working on adding support for high priority events to a user space event library. Conceptually, I need the equivalent of poll() with POLLPRI, but via kqueue. FreeBSD and Apple OSX provide this via the 'EV_OOBAND' flag to EV_SET. However, OpenBSD (and NetBSD) do not. Is there a way to wait for high priority events with kqueue on OpenBSD? I had a read through various kernel sources, but didn't manage to find anything. Could OpenBSD add support for the EV_OOBAND flag? Who is responsible for these sorts of things? -- Daurnimator PS, I'm not an OpenBSD user myself, I'm just trying to keep a cross-platform library cross-platform. PPS, I'm not subscribed to the list, please ensure you Cc me on replies.
Re: hi, hope you are fine, my Name is Paulina, I will want us to be friends, for something important which I would like to share with u, we will get to know each other better i am waiting for your r
Re: hi, hope you are fine, my Name is Paulina, I will want us to be friends, for something important which I would like to share with u, we will get to know each other better i am waiting for your responds, ( distance or colour does not matter ) urs Paul thought you would be interested in the following article:Italian merchants funded England's discovery of North America Evidence that a Florentine merchant house financed the earliest English voyages to North America, has been published on-line in the academic journal Historical Research. Click here to read more on e! Science News
Waiting!
Got a proposition for you,reply for futher details.
diff: fix waiting problem on AMD Hudson's AHCI (Re: AMD APU report)
Hello,
I have a system with an asrock a75m-itx motherboard and an amd a6-3500
processor. I notice there is a 40 second delay after the 'ahci0 at pci0
dev 17
...' line.
I have IBM's ThinkPad Edge E525, AMD A8-3500M based machine.
And I checked this diff fix that problem.
ok or comment?
Index: ahci.c
===
RCS file: /cvs/src/sys/dev/pci/ahci.c,v
retrieving revision 1.186
diff -u -p -r1.186 ahci.c
--- ahci.c 4 Feb 2012 21:44:54 - 1.186
+++ ahci.c 12 Apr 2012 13:30:27 -
@@ -462,6 +462,8 @@ int ahci_intel_attach(struct ahci_soft
static const struct ahci_device ahci_devices[] = {
{ PCI_VENDOR_AMD, PCI_PRODUCT_AMD_HUDSON2_SATA,
NULL, ahci_amd_hudson2_attach },
+ { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_HUDSON_AHCI_1,
+ NULL, ahci_ati_sb700_attach },
{ PCI_VENDOR_ATI, PCI_PRODUCT_ATI_SB600_SATA,
NULL, ahci_ati_sb600_attach },
SASANO Takayoshi u...@mx5.nisiq.net, sas...@cvs.openbsd.org
Re: diff: fix waiting problem on AMD Hudson's AHCI (Re: AMD APU report)
On Thu, Apr 12, 2012 at 22:40 +0900, SASANO Takayoshi wrote:
Hello,
I have a system with an asrock a75m-itx motherboard and an amd a6-3500
processor. I notice there is a 40 second delay after the 'ahci0 at pci0
dev 17
...' line.
I have IBM's ThinkPad Edge E525, AMD A8-3500M based machine.
And I checked this diff fix that problem.
ok or comment?
makes sense to me, ok mikeb
Index: ahci.c
===
RCS file: /cvs/src/sys/dev/pci/ahci.c,v
retrieving revision 1.186
diff -u -p -r1.186 ahci.c
--- ahci.c4 Feb 2012 21:44:54 - 1.186
+++ ahci.c12 Apr 2012 13:30:27 -
@@ -462,6 +462,8 @@ int ahci_intel_attach(struct
ahci_soft
static const struct ahci_device ahci_devices[] = {
{ PCI_VENDOR_AMD, PCI_PRODUCT_AMD_HUDSON2_SATA,
NULL, ahci_amd_hudson2_attach },
+ { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_HUDSON_AHCI_1,
+ NULL, ahci_ati_sb700_attach },
{ PCI_VENDOR_ATI, PCI_PRODUCT_ATI_SB600_SATA,
NULL, ahci_ati_sb600_attach },
SASANO Takayoshi u...@mx5.nisiq.net, sas...@cvs.openbsd.org
Re: diff: fix waiting problem on AMD Hudson's AHCI (Re: AMD APU report)
On 04/12/12 09:40, SASANO Takayoshi wrote: Hello, I have a system with an asrock a75m-itx motherboard and an amd a6-3500 processor. I notice there is a 40 second delay after the 'ahci0 at pci0 dev 17 ...' line. I have IBM's ThinkPad Edge E525, AMD A8-3500M based machine. And I checked this diff fix that problem. ok or comment? Thanks, your patch eliminates the 40 second delay.
[PATCH] please test if dmesg has ehci0: timed out waiting for BIOS
Hi, I'm just touching this again because I'd like to see this
fix committed to CVS.
The problem that is fixed by this change is a complete deadlock
while booting with USB2 HiSpeed enabled in BIOS.
On Mon, 8 Mar 2010 15:39:55 +0100 Christopher Zimmermann wrote:
Heres my theory of what went wrong:
My (broken) BIOS does not know how to hand over the ehci host
controller. Therefore the timeout.
That's the ehci0: timed out waiting for BIOS message
Additionally when 'HiSpeed' is selected it turns on several System
Management Interupts in the ehci host controller and won't turn them
off when the kernel requests the handover.
Later, when the kernel sets the CF bit the host controller issues a
SMI to notify the BIOS of the ownership change of mouse and keyboard
from ohci to the ehci host controller. The BIOS does not seem to like
this and the kernel/BIOS freezes.
- complete deadlock
My fix simply clears all SMI_ENABLE bits in the USBLEGCTLSTS register
when the BIOS does not acknowledge the handover. This violates the
spec, because the USBLEGCTLSTS register is supposed to be used by the
BIOS, not the OS.
Still this will only be done in case we timeout while waiting for
the bios to acknowledge the handover.
Therefore this should be tested by people seeing the
ehci0: timed out waiting for BIOS
in their dmesg.
Christopher
Index: dev/pci/ehci_pci.c
===
RCS file: /cvs/src/sys/dev/pci/ehci_pci.c,v
retrieving revision 1.18
diff -u -p -r1.18 ehci_pci.c
--- dev/pci/ehci_pci.c 24 Jul 2009 03:18:58 - 1.18
+++ dev/pci/ehci_pci.c 8 Mar 2010 14:17:48 -
@@ -294,9 +294,26 @@ ehci_pci_takecontroller(struct ehci_pci_
break;
DELAY(1000);
}
- if (legsup EHCI_LEGSUP_BIOSOWNED)
- printf(%s: timed out waiting for BIOS\n,
+ if (legsup EHCI_LEGSUP_BIOSOWNED) {
+ /*
+* The BIOS on the Asus K8S-MV/P does not
+* release the semaphore in time and won't
+* turn of System management interrupts.
+* It will get confused by the SMIs caused
+* by port changes when the CF bit goes up.
+* Therefore we do the job of the BIOS and
+* turn off SMIs. The SMI control bits
+* are bits 0-15 at register eecp+0x04.
+* See the intel EHCI spec.
+*/
+ printf(%s: timed out waiting for BIOS
+- at least disable all SMIs.\n,
sc-sc.sc_bus.bdev.dv_xname);
+ legsup = pci_conf_read(sc-sc_pc, sc-sc_tag,
+ eecp + 0x04);
+ pci_conf_write(sc-sc_pc, sc-sc_tag,
+ eecp + 0x04, legsup 0x);
+ }
}
}
}
My dmesg after applying the change:
OpenBSD 4.7-current (sys) #55: Mon Mar 29 18:29:56 CEST 2010
madro...@pundit:/var/obj/sys
[...]
ohci0 at pci0 dev 3 function 0 SiS 5597/5598 USB rev 0x0f: apic
1 int 20 (irq 5), version 1.0, legacy support
ohci1 at pci0 dev 3 function 1 SiS 5597/5598 USB rev 0x0f: apic 1 int 21 (irq
10), version 1.0, legacy support
ohci2 at pci0 dev 3 function 2 SiS 5597/5598 USB rev 0x0f: apic 1 int 22 (irq
5), version 1.0, legacy support
ehci0 at pci0 dev 3 function 3 SiS 7002 USB rev 0x00: apic 1 int 23 (irq 10)
ehci0: timed out waiting for BIOS - at least disable all SMIs.
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 SiS EHCI root hub rev 2.00/1.00 addr 1
[...]
usb1 at ohci0: USB revision 1.0
uhub1 at usb1 SiS OHCI root hub rev 1.00/1.00 addr 1
usb2 at ohci1: USB revision 1.0
uhub2 at usb2 SiS OHCI root hub rev 1.00/1.00 addr 1
usb3 at ohci2: USB revision 1.0
uhub3 at usb3 SiS OHCI root hub rev 1.00/1.00 addr 1
mtrr: Pentium Pro MTRR support
uhidev0 at uhub1 port 2 configuration 1 interface 0 Sun Microsystems Type 6
Keyboard rev 1.10/2.00 addr 2
uhidev0: iclass 3/1
ukbd0 at uhidev0: 8 modifier keys, 6 key codes, country code 33
wskbd0 at ukbd0: console keyboard, using wsdisplay0
uhidev1 at uhub3 port 1 configuration 1 interface 0 Logitech USB Optical
Mouse rev 2.00/43.01 addr 2
uhidev1: iclass 3/1
ums0 at uhidev1: 3 buttons, Z dir
wsmouse0 at ums0 mux 0
[...]
