Re: ehci_idone: ex=0xd90fd934 is done!
i confirm that with the latest snapshot that includes the latest ehci fix these messages went away. thank you. -f -- doubt is the beginning of wisdom
Slow (Num/Caps/Scroll)Lock response under X.
Hi, When I am in X, the system takes a lot of time to respond the press of (Num/Caps/Scroll)Lock. Out of X it works instantly. I already used Xenocara from -release, -stable, and I am now using -current. I takes time also to change the light in the keyboard. In the time between a (Num/Caps/Scroll)Lock, if I type the words don't appear in the screen, only after the light change. The dmesg and the Xorg.0.log are attached -- Regards Henrique Lengler OpenBSD 5.7-beta (GENERIC) #0: Sat Feb 28 13:15:26 BRT 2015 he...@henrique-pc.my.domain:/usr/src/sys/arch/amd64/compile/GENERIC real mem = 8439386112 (8048MB) avail mem = 8210849792 (7830MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec1f0 (82 entries) bios0: vendor American Megatrends Inc. version 1401 date 07/29/2014 bios0: ASUS All Series acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT LPIT SSDT SSDT MCFG HPET SSDT SSDT BGRT acpi0: wakeup devices UAR1(S4) PS2K(S4) PS2M(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) PXSX(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz, 3498.50 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 2 (RP01) acpiprt2 at acpi0: bus 3 (RP03) acpiprt3 at acpi0: bus 4 (RP04) acpiprt4 at acpi0: bus 5 (PXSX) acpiprt5 at acpi0: bus 1 (PEG0) acpiprt6 at acpi0: bus -1 (PEG1) acpiprt7 at acpi0: bus -1 (PEG2) acpiec0 at acpi0: not present acpicpu0 at acpi0: C1, PSS acpipwrres0 at acpi0: FN00, resource for FAN0 acpipwrres1 at acpi0: FN01, resource for FAN1 acpipwrres2 at acpi0: FN02, resource for FAN2 acpipwrres3 at acpi0: FN03, resource for FAN3 acpipwrres4 at acpi0: FN04, resource for FAN4 acpitz0 at acpi0: critical temperature is 105 degC acpitz1 at acpi0: critical temperature is 105 degC acpibat0 at acpi0: BAT0 not present acpibat1 at acpi0: BAT1 not present acpibat2 at acpi0: BAT2 not present acpibtn0 at acpi0: PWRB acpibtn1 at acpi0: LID0 acpivideo0 at acpi0: GFX0 acpivout0 at acpivideo0: DD1F cpu0: Enhanced SpeedStep 3498 MHz: speeds: 3501, 3500, 3300, 3100, 2900, 2700, 2500, 2300, 2100, 2000, 1800, 1600, 1400, 1200, 1000, 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 Intel Core 4G Host rev 0x06 ppb0 at pci0 dev 1 function 0 Intel Core 4G PCIE rev 0x06: msi pci1 at ppb0 bus 1 vga1 at pci0 dev 2 function 0 Intel HD Graphics 4600 rev 0x06 intagp at vga1 not configured inteldrm0 at vga1 drm0 at inteldrm0 error: [drm:pid0:i915_write32] *ERROR* Unknown unclaimed register before writing to 10 inteldrm0: 1920x1080 wsdisplay0 at vga1 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) azalia0 at pci0 dev 3 function 0 Intel Core 4G HD Audio rev 0x06: msi azalia0: No codecs found xhci0 at pci0 dev 20 function 0 Intel 8 Series xHCI rev 0x05: msi usb0 at xhci0: USB revision 3.0 uhub0 at usb0 Intel xHCI root hub rev 3.00/1.00 addr 1 Intel 8 Series MEI rev 0x04 at pci0 dev 22 function 0 not configured ehci0 at pci0 dev 26 function 0 Intel 8 Series USB rev 0x05: apic 8 int 20 usb1 at ehci0: USB revision 2.0 uhub1 at usb1 Intel EHCI root hub rev 2.00/1.00 addr 1 azalia1 at pci0 dev 27 function 0 Intel 8 Series HD Audio rev 0x05: msi azalia1: codecs: Realtek/0x0887 audio0 at azalia1 ppb1 at pci0 dev 28 function 0 Intel 8 Series PCIE rev 0xd5: msi pci2 at ppb1 bus 2 ppb2 at pci0 dev 28 function 2 Intel 8 Series PCIE rev 0xd5: msi pci3 at ppb2 bus 3 re0 at pci3 dev 0 function 0 Realtek 8168 rev 0x11: RTL8168G/8111G (0x4c00), msi, address bc:ee:7b:e0:59:17 rgephy0 at re0 phy 7: RTL8251 PHY, rev. 0 ppb3 at pci0 dev 28 function 3 Intel 82801BA Hub-to-PCI rev 0xd5: msi pci4 at ppb3 bus 4 ppb4 at pci4 dev 0 function 0 ASMedia ASM1083/1085 PCIE-PCI rev 0x03 pci5 at ppb4 bus 5 ehci1 at pci0 dev 29 function 0 Intel 8 Series USB rev 0x05: apic 8 int 23 usb2 at ehci1: USB revision 2.0 uhub2 at usb2 Intel EHCI root hub rev 2.00/1.00
Re: athn at usb fixes
Stefan Sperling s...@stsp.name writes:
On Sun, Mar 01, 2015 at 11:52:42PM -0300, Henrique Lengler wrote:
On Sun, Mar 01, 2015 at 11:34:54AM -0430, Naim, Halim. wrote:
Thanks, I have applied and recompiled. I can attach/detach. ifconfig
down up, and sh /etc/netstart athn0, without any problems now. I will
use it through the day to see if It goes down by itself as it use to.
I will test this.
Please test this updated diff instead (after more discussion with mpi@).
I'm going to start committing bits of this soon but it's still worth
testing this entire diff ASAP.
Everything continues to work with the new diff. Yesterday (with the
previous diff), I used the dongle for some 12 hours, without any
problems.
Index: if_athn_usb.c
===
RCS file: /cvs/src/sys/dev/usb/if_athn_usb.c,v
retrieving revision 1.26
diff -u -p -r1.26 if_athn_usb.c
--- if_athn_usb.c 10 Feb 2015 23:25:46 - 1.26
+++ if_athn_usb.c 2 Mar 2015 10:46:13 -
@@ -117,8 +117,6 @@ int athn_usb_htc_msg(struct athn_usb_so
int athn_usb_htc_setup(struct athn_usb_softc *);
int athn_usb_htc_connect_svc(struct athn_usb_softc *, uint16_t,
uint8_t, uint8_t, uint8_t *);
-void athn_usb_wmieof(struct usbd_xfer *, void *,
- usbd_status);
int athn_usb_wmi_xcmd(struct athn_usb_softc *, uint16_t, void *,
int, void *);
int athn_usb_read_rom(struct athn_softc *);
@@ -126,6 +124,7 @@ uint32_t athn_usb_read(struct athn_softc
void athn_usb_write(struct athn_softc *, uint32_t, uint32_t);
void athn_usb_write_barrier(struct athn_softc *);
int athn_usb_media_change(struct ifnet *);
+void athn_usb_next_scan(void *);
int athn_usb_newstate(struct ieee80211com *, enum ieee80211_state,
int);
void athn_usb_newstate_cb(struct athn_usb_softc *, void *);
@@ -291,6 +290,8 @@ athn_usb_detach(struct device *self, int
/* Wait for all async commands to complete. */
athn_usb_wait_async(usc);
+ usbd_ref_wait(usc-sc_udev);
+
/* Abort and close Tx/Rx pipes. */
athn_usb_close_pipes(usc);
@@ -348,10 +349,7 @@ athn_usb_attachhook(void *xsc)
#endif
ic-ic_newstate = athn_usb_newstate;
ic-ic_media.ifm_change = athn_usb_media_change;
-
- /* Firmware cannot handle more than 8 STAs. */
- if (ic-ic_max_nnodes AR_USB_MAX_STA)
- ic-ic_max_nnodes = AR_USB_MAX_STA;
+ timeout_set(sc-scan_to, athn_usb_next_scan, usc);
ops-rx_enable = athn_usb_rx_enable;
splx(s);
@@ -436,18 +434,26 @@ athn_usb_open_pipes(struct athn_usb_soft
void
athn_usb_close_pipes(struct athn_usb_softc *usc)
{
- if (usc-tx_data_pipe != NULL)
+ if (usc-tx_data_pipe != NULL) {
usbd_close_pipe(usc-tx_data_pipe);
- if (usc-rx_data_pipe != NULL)
+ usc-tx_data_pipe = NULL;
+ }
+ if (usc-rx_data_pipe != NULL) {
usbd_close_pipe(usc-rx_data_pipe);
- if (usc-tx_intr_pipe != NULL)
+ usc-rx_data_pipe = NULL;
+ }
+ if (usc-tx_intr_pipe != NULL) {
usbd_close_pipe(usc-tx_intr_pipe);
+ usc-tx_intr_pipe = NULL;
+ }
if (usc-rx_intr_pipe != NULL) {
- usbd_abort_pipe(usc-rx_intr_pipe);
usbd_close_pipe(usc-rx_intr_pipe);
+ usc-rx_intr_pipe = NULL;
}
- if (usc-ibuf != NULL)
+ if (usc-ibuf != NULL) {
free(usc-ibuf, M_USBDEV, 0);
+ usc-ibuf = NULL;
+ }
}
int
@@ -590,7 +596,6 @@ athn_usb_task(void *arg)
ring-queued--;
ring-next = (ring-next + 1) % ATHN_USB_HOST_CMD_RING_COUNT;
}
- wakeup(ring);
splx(s);
}
@@ -602,8 +607,11 @@ athn_usb_do_async(struct athn_usb_softc
struct athn_usb_host_cmd *cmd;
int s;
- if (ring-queued)
+ if (ring-queued == ATHN_USB_HOST_CMD_RING_COUNT) {
+ printf(%s: host cmd queue overrun\n, usc-usb_dev.dv_xname);
return; /* XXX */
+ }
+
s = splusb();
cmd = ring-cmd[ring-cur];
cmd-cb = cb;
@@ -621,8 +629,7 @@ void
athn_usb_wait_async(struct athn_usb_softc *usc)
{
/* Wait for all queued asynchronous commands to complete. */
- while (usc-cmdq.queued 0)
- tsleep(usc-cmdq, 0, cmdq, 0);
+ usb_wait_task(usc-sc_udev, usc-sc_task);
}
int
@@ -830,19 +837,6 @@ athn_usb_htc_connect_svc(struct athn_usb
return (0);
}
-void
-athn_usb_wmieof(struct usbd_xfer *xfer, void *priv,
-usbd_status status)
-{
- struct athn_usb_softc *usc = priv;
-
- if (__predict_false(status == USBD_STALLED))
- usbd_clear_endpoint_stall_async(usc-tx_intr_pipe);
-
- usc-wmi_done = 1;
-
Re: athn at usb fixes
On Mon, Mar 02, 2015 at 09:21:02AM -0430, Naim, Halim. wrote: Everything continues to work with the new diff. Yesterday (with the previous diff), I used the dongle for some 12 hours, without any problems. Great, thanks for checking. This new diff mainly fixes an issue where the machine effectively locks up (storm of xfer not free errors on the console) if the device is unplugged at a particular moment while a scan is in progress, which won't ever happen most of the time even with the previous diff. Otherwise it's the same. I'm not 100% sure we've fixed all the race conditions in there but only time can tell. I'm tired of replugging this device, and I don't want to wear out my laptop's USB ports even more ;)
Re: relayd memory usage when loading large URL lists
On Sun, Mar 1, 2015 at 4:45 PM, Felipe Scarel fbsca...@gmail.com wrote:
Hello all,
I'm implementing a simple SSL forward proxy using relayd.
Configuration has been fine, as was testing. There seems to be one
issue with memory consumption, however.
To better illustrate my issue, here follows an excerpt of /etc/relayd.conf :
http protocol httpsfilter {
tcp { nodelay, sack, socket buffer 65536, backlog 1024 }
return error
match header set Keep-Alive value $TIMEOUT
match header set Connecton value close
pass quick url file /etc/relayd.d/custom_whitelist
block url file /etc/relayd.d/custom_blacklist
include /etc/relayd.d/auto_blacklist
ssl ca key /etc/ssl/private/ca.key password password
ssl ca cert /etc/ssl/ca.crt
}
So basically it checks against a custom whitelist, then a custom
blacklist, and finally an auto blacklist (which is the main source
of the problem). Using a few URLs with both custom black/white lists
poses no issue, but when attempting to load a somewhat bigger URL list
downloaded from the internet (I'm using
ftp://ftp.ut-capitole.fr/pub/reseau/cache/squidguard_contrib/blacklists.tar.gz)
I run into memory problems.
For example, here is relayd's memory usage when only the custom
white/black lists are loaded (2 URLs total, no big deal):
# ps aux | grep relayd
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
_relayd 17238 0.0 0.1 1528 3208 ?? I 3:27PM0:00.01
relayd: relay (relayd)
_relayd 14280 0.0 0.1 1524 3176 ?? I 3:27PM0:00.02
relayd: relay (relayd)
_relayd 30448 0.0 0.1 1396 2812 ?? I 3:27PM0:00.01
relayd: ca (relayd)
_relayd 10020 0.0 0.1 1376 2768 ?? I 3:27PM0:00.01
relayd: ca (relayd)
_relayd 25775 0.0 0.1 1400 2852 ?? I 3:27PM0:00.01
relayd: ca (relayd)
root 346 0.0 0.1 1912 3672 ?? Is 3:27PM0:00.02
relayd: parent (relayd)
_relayd 15883 0.0 0.1 1440 2828 ?? I 3:27PM0:00.01
relayd: pfe (relayd)
_relayd 32000 0.0 0.1 1220 2560 ?? I 3:27PM0:00.01
relayd: hce (relayd)
_relayd 2677 0.0 0.1 1516 3188 ?? I 3:27PM0:00.01
relayd: relay (relayd)
Now loading the phishing/domains URL list, which has about ~63k
entries. relayd's parent process ballons to over 2GB memory usage
(I'm assuming it's reading the URL lists and building a data structure
for the relays), and after that the relays stabilize with the
following memory usage:
# ps aux | grep relayd
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
_relayd 12982 0.0 12.9 516728 526288 ?? S 3:31PM0:03.44
relayd: relay (relayd)
_relayd 1206 0.0 0.1 1368 2836 ?? I 3:31PM0:00.01
relayd: ca (relayd)
root 25673 0.0 2.7 155616 111228 ?? Is 3:31PM0:16.35
relayd: parent (relayd)
_relayd 15513 0.0 0.1 1416 2832 ?? S 3:31PM0:00.01
relayd: pfe (relayd)
_relayd 15643 0.0 0.1 1200 2560 ?? I 3:31PM0:00.01
relayd: hce (relayd)
_relayd 25822 0.0 12.9 516716 526296 ?? S 3:31PM0:03.37
relayd: relay (relayd)
_relayd 17950 0.0 0.1 1380 2824 ?? I 3:31PM0:00.01
relayd: ca (relayd)
_relayd 9068 0.0 0.1 1360 2784 ?? I 3:31PM0:00.01
relayd: ca (relayd)
_relayd 19666 0.0 12.9 516712 526292 ?? S 3:31PM0:03.46
relayd: relay (relayd)
So that's about ~520 MB of memory per relay process, out of 3 total.
Next I load another URL list alongside the previous one, the
adult/urls list, which contains roughtly ~55k entries. Adding up
with the previous list, we have more or less ~118k URLs for relayd to
process. The parent process takes a couple minutes to process
everything, going over 4GB VSZ and 2.2GB RSS. After all's said and
done, here's what's shown by ps:
# ps aux | grep relayd
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
_relayd 6332 0.0 0.1 1428 2228 ?? I 3:35PM0:00.01
relayd: ca (relayd)
_relayd 8736 0.0 23.9 967808 976768 ?? I 3:35PM0:06.81
relayd: relay (relayd)
_relayd 22890 0.0 23.9 967812 976768 ?? I 3:35PM0:06.77
relayd: relay (relayd)
_relayd 5871 0.0 23.9 967804 976760 ?? I 3:35PM0:06.33
relayd: relay (relayd)
_relayd 8199 0.0 0.1 1440 2256 ?? I 3:35PM0:00.01
relayd: ca (relayd)
root 5571 0.0 5.3 315032 214796 ?? Is 3:35PM1:28.45
relayd: parent (relayd)
_relayd 30781 0.0 0.1 1488 2136 ?? S 3:35PM0:00.01
relayd: pfe (relayd)
_relayd 1502 0.0 0.0 1272 2040 ?? I 3:35PM0:00.01
relayd: hce (relayd)
_relayd 29135 0.0 0.1 1432 2236 ?? I 3:35PM0:00.01
relayd: ca (relayd)
Nearly 1GB of RAM per relay process, and ~214 MB to the parent
process. This server I'm working with has 4GB of RAM, so it can't go
much further. If I attempt to load the biggest URL list from the set,
Re: questions to the security of softraid_crypto
On Monday 02 March 2015, Peter J. Philipp wrote:
On 03/01/15 23:17, Ted Unangst wrote:
Peter J. Philipp wrote:
Hi,
I am not the best C reader and programmer out there so I try to make
myself tools that may seem useless in order to better understand. I see
this in /sys/dev/softraid_crypto.c
int
sr_crypto_encrypt(u_char *p, u_char *c, u_char *key, size_t size, int
alg) {
rijndael_ctxctx;
int i, rv = 1;
switch (alg) {
case SR_CRYPTOM_AES_ECB_256:
This function is only used to encrypt the master key, which is a small
chunk of random data.
Thanks for taking a look Tedu, I really appreciate it. I'm wondering
does this master key use salt to protect against rainbow tables? At a
glance at the code I see not mention of salt.
I would strongly suggest that you follow the entire path through, rather than
reading small pieces of code and guessing as to how the rest of the code may
be implemented. In other words, you might want to undertake some research and
see if you can answer the following questions (the questions that you are
asking will likely be answered in the process):
- What encryption algorithm/mode is used for disk block encryption?
- Where do the keys come from that are used for the disk block
encryption/decryption?
- How are the keys that are used to encrypt the disk blocks stored?
- When creating a new softraid crypto volume, where does the key come from?
- What happens if you use a keydisk instead of a passphrase?
dd if=/dev/zero of=EFS2 bs=1g count=1
vnconfig vnd0 EFS2
bioctl -c C -l /dev/vnd0a softraid0
And I created a filesystem on it and populated it. In fact I use this
EFS2 file for storing work related things in it (so I can never share
it). I ran this program over the EFS2 file:
so it says that there is 652063 occurences where AES blocks were
duplicated, to me that's near 10 MB of material someone can use like the
above [1] where it says it could describe the data pattern.
It seems more likely you found the 652063 zero blocks that haven't been
written to yet.
Note that if you are concerned about people doing stat analysis on your
encrypted disk, you should be sure to overwrite the entirety of it.
Either with /dev/random on the outside, or /dev/zero on the inside, to
ensure the used and unused portions look the same.
That's good advice I'll try to fill up the space inside with a file and
see if the number of those blocks goes down. It isn't all zero blocks
but the majority of it could be.
By design softraid does not scrub or overwrite what is on the underlying disk
chunks until such time as you actually write data to the softraid volume. As
Ted noted, you will need to fill the disk chunks (or softraid volume)
yourself if you want to guarantee such a state.
--
Action without study is fatal. Study without action is futile.
-- Mary Ritter Beard
Re: athn at usb fixes
On Sun, Mar 01, 2015 at 11:52:42PM -0300, Henrique Lengler wrote:
On Sun, Mar 01, 2015 at 11:34:54AM -0430, Naim, Halim. wrote:
Thanks, I have applied and recompiled. I can attach/detach. ifconfig
down up, and sh /etc/netstart athn0, without any problems now. I will
use it through the day to see if It goes down by itself as it use to.
I will test this.
Please test this updated diff instead (after more discussion with mpi@).
I'm going to start committing bits of this soon but it's still worth
testing this entire diff ASAP.
Index: if_athn_usb.c
===
RCS file: /cvs/src/sys/dev/usb/if_athn_usb.c,v
retrieving revision 1.26
diff -u -p -r1.26 if_athn_usb.c
--- if_athn_usb.c 10 Feb 2015 23:25:46 - 1.26
+++ if_athn_usb.c 2 Mar 2015 10:46:13 -
@@ -117,8 +117,6 @@ int athn_usb_htc_msg(struct athn_usb_so
intathn_usb_htc_setup(struct athn_usb_softc *);
intathn_usb_htc_connect_svc(struct athn_usb_softc *, uint16_t,
uint8_t, uint8_t, uint8_t *);
-void athn_usb_wmieof(struct usbd_xfer *, void *,
- usbd_status);
intathn_usb_wmi_xcmd(struct athn_usb_softc *, uint16_t, void *,
int, void *);
intathn_usb_read_rom(struct athn_softc *);
@@ -126,6 +124,7 @@ uint32_tathn_usb_read(struct athn_softc
void athn_usb_write(struct athn_softc *, uint32_t, uint32_t);
void athn_usb_write_barrier(struct athn_softc *);
intathn_usb_media_change(struct ifnet *);
+void athn_usb_next_scan(void *);
intathn_usb_newstate(struct ieee80211com *, enum ieee80211_state,
int);
void athn_usb_newstate_cb(struct athn_usb_softc *, void *);
@@ -291,6 +290,8 @@ athn_usb_detach(struct device *self, int
/* Wait for all async commands to complete. */
athn_usb_wait_async(usc);
+ usbd_ref_wait(usc-sc_udev);
+
/* Abort and close Tx/Rx pipes. */
athn_usb_close_pipes(usc);
@@ -348,10 +349,7 @@ athn_usb_attachhook(void *xsc)
#endif
ic-ic_newstate = athn_usb_newstate;
ic-ic_media.ifm_change = athn_usb_media_change;
-
- /* Firmware cannot handle more than 8 STAs. */
- if (ic-ic_max_nnodes AR_USB_MAX_STA)
- ic-ic_max_nnodes = AR_USB_MAX_STA;
+ timeout_set(sc-scan_to, athn_usb_next_scan, usc);
ops-rx_enable = athn_usb_rx_enable;
splx(s);
@@ -436,18 +434,26 @@ athn_usb_open_pipes(struct athn_usb_soft
void
athn_usb_close_pipes(struct athn_usb_softc *usc)
{
- if (usc-tx_data_pipe != NULL)
+ if (usc-tx_data_pipe != NULL) {
usbd_close_pipe(usc-tx_data_pipe);
- if (usc-rx_data_pipe != NULL)
+ usc-tx_data_pipe = NULL;
+ }
+ if (usc-rx_data_pipe != NULL) {
usbd_close_pipe(usc-rx_data_pipe);
- if (usc-tx_intr_pipe != NULL)
+ usc-rx_data_pipe = NULL;
+ }
+ if (usc-tx_intr_pipe != NULL) {
usbd_close_pipe(usc-tx_intr_pipe);
+ usc-tx_intr_pipe = NULL;
+ }
if (usc-rx_intr_pipe != NULL) {
- usbd_abort_pipe(usc-rx_intr_pipe);
usbd_close_pipe(usc-rx_intr_pipe);
+ usc-rx_intr_pipe = NULL;
}
- if (usc-ibuf != NULL)
+ if (usc-ibuf != NULL) {
free(usc-ibuf, M_USBDEV, 0);
+ usc-ibuf = NULL;
+ }
}
int
@@ -590,7 +596,6 @@ athn_usb_task(void *arg)
ring-queued--;
ring-next = (ring-next + 1) % ATHN_USB_HOST_CMD_RING_COUNT;
}
- wakeup(ring);
splx(s);
}
@@ -602,8 +607,11 @@ athn_usb_do_async(struct athn_usb_softc
struct athn_usb_host_cmd *cmd;
int s;
- if (ring-queued)
+ if (ring-queued == ATHN_USB_HOST_CMD_RING_COUNT) {
+ printf(%s: host cmd queue overrun\n, usc-usb_dev.dv_xname);
return; /* XXX */
+ }
+
s = splusb();
cmd = ring-cmd[ring-cur];
cmd-cb = cb;
@@ -621,8 +629,7 @@ void
athn_usb_wait_async(struct athn_usb_softc *usc)
{
/* Wait for all queued asynchronous commands to complete. */
- while (usc-cmdq.queued 0)
- tsleep(usc-cmdq, 0, cmdq, 0);
+ usb_wait_task(usc-sc_udev, usc-sc_task);
}
int
@@ -830,19 +837,6 @@ athn_usb_htc_connect_svc(struct athn_usb
return (0);
}
-void
-athn_usb_wmieof(struct usbd_xfer *xfer, void *priv,
-usbd_status status)
-{
- struct athn_usb_softc *usc = priv;
-
- if (__predict_false(status == USBD_STALLED))
- usbd_clear_endpoint_stall_async(usc-tx_intr_pipe);
-
- usc-wmi_done = 1;
- wakeup(usc-wmi_done);
-}
-
int
athn_usb_wmi_xcmd(struct athn_usb_softc *usc, uint16_t cmd_id, void *ibuf,
int ilen, void *obuf)
@@ -852,6 +846,24 @@
Re: [Bulk] Re: vnconfig crypto alternative
On Sun, 1 Mar 2015 13:52:37 -0500 Jonathan Thornburg wrote: That deprecation is not going to happen. Keep using what you are using now. I grok that (the current implementation of) vnd crypto is weak. What's the current migration/fixing/transition plan for this? (I can't find any mention of vnd or vnconfig in http://www.openbsd.org/plus.html .) Where do you grok that from? I believe the words were not state of the art, which is fair and encouraging to use softraid is correct. vnd crypto uses CBC which has some papers pondering the possibility of breakage but in no way are they useful to a legitimate attacker. It doesn't change the keys like softraid which also uses the more modern xts and is far more suitable to larger volumes. Blowfish certainly isn't weak I believe theo said something along the lines of there is still a place for a simpler crypto implementation. I think that says it all and the warning will certainly send those in doubt to bioctl (softraid)
Re: athn at usb fixes
Thanks for the work with this patch. On Mar 2, 2015 11:17 AM, Stefan Sperling s...@stsp.name wrote: On Mon, Mar 02, 2015 at 03:05:41PM +0100, Stefan Sperling wrote: On Mon, Mar 02, 2015 at 09:21:02AM -0430, Naim, Halim. wrote: Everything continues to work with the new diff. Yesterday (with the previous diff), I used the dongle for some 12 hours, without any problems. Great, thanks for checking. All important changes from the diff have now been committed.
typo in strip(1) man page
Hi, there is a typo in the manpage for strip. In section --only-keep-debug, In the first point, It says: 1.Link the executable... Assuming that is is called... That should be: that it is called
Re: athn at usb fixes
On Mon, Mar 02, 2015 at 03:05:41PM +0100, Stefan Sperling wrote: On Mon, Mar 02, 2015 at 09:21:02AM -0430, Naim, Halim. wrote: Everything continues to work with the new diff. Yesterday (with the previous diff), I used the dongle for some 12 hours, without any problems. Great, thanks for checking. All important changes from the diff have now been committed.
Re: typo in strip(1) man page
I just noticed that all the points after that are numbered 1 (also below in the next enumeration). maybe that's also not right. On Mar 2, 2015 11:41 AM, Naim, Halim. halimsr...@gmail.com wrote: Hi, there is a typo in the manpage for strip. In section --only-keep-debug, In the first point, It says: 1.Link the executable... Assuming that is is called... That should be: that it is called
Re: typo in strip(1) man page
On Tue, 3 Mar 2015, at 05:11 AM, Naim, Halim. wrote: Hi, there is a typo in the manpage for strip. In section --only-keep-debug, In the first point, It says: 1.Link the executable... Assuming that is is called... That should be: that it is called grep -sr ' is is ' /usr/src/gnu A common typo in the GNU-verse. -- Carlin
Re: improving browser security
On 03/01/2015 10:36 AM, Ted Unangst wrote: A few words about a project I've started working on today with support from the OpenBSD Foundation. This is a good idea. I just threw some more coin in the donations bin. At the risk of feature creep: There was a thread on this list about browser installation such that it would, for each user be sandboxed in a clean room, denying any scripts access to the users files. I don't know if this is at all appropriate for this project, and I just throw it out there for consideration. http://marc.info/?l=openbsd-miscm=141710381310891w=2 -- Those who do not understand Unix are condemned to reinvent it, poorly.
Re: improving browser security
At the risk of feature creep: There was a thread on this list about browser installation such that it would, for each user be sandboxed in a clean room, denying any scripts access to the users files. I don't know if this is at all appropriate for this project, and I just throw it out there for consideration. http://marc.info/?l=openbsd-miscm=141710381310891w=2 I think Ted is going to fix the so called we do 64 bit random and we are 64 bit lies that browser JITs say they do. I remember when Ariane applied the commits, browsers failed spectacularly. Please correct me if i am wrong. espie@ original email http://marc.info/?l=openbsd-miscm=130683944229077w=2 naddy@ detailed explanation http://marc.info/?l=openbsd-miscm=130687174807002w=2 otto@ http://marc.info/?l=openbsd-miscm=130687174807002w=2 deraadt@ http://marc.info/?l=openbsd-miscm=130687281908151w=2
