Re: pool related crashes, but "kernel did no panic"

On Tue, May 31, 2016 at 7:16 PM, Theo de Raadt wrote: >> is exactly 80 characters long (such a long printf violates "80 chars" >> rule, isn't it?). > > there is no hard and fast rule for that at all; printing extra newlines > has other downsides such as the screen

Re: pool related crashes, but "kernel did no panic"

On Mon, May 30, 2016 at 9:02 PM, Ted Unangst <t...@tedunangst.com> wrote: > Alexey Suslikov wrote: >> On Thu, May 12, 2016 at 4:14 PM, Bob Beck <b...@openbsd.org> wrote: >> > Thank you!now that's a bug report.. >> >> Hi. >> >> Moved

Re: pool related crashes, but "kernel did no panic"

On Thu, May 12, 2016 at 4:14 PM, Bob Beck wrote: > Thank you!now that's a bug report.. Hi. Moved to 6.0-beta some time ago to make crash dumps more up to date. Also, removed some services to minimize their impact. Fresh build against today's cvs don't survived even half

Re: pool related crashes, but "kernel did no panic"

On Fri, May 13, 2016 at 3:59 AM, David Gwynne <da...@gwynne.id.au> wrote: > >> On 12 May 2016, at 20:28, Alexey Suslikov <alexey.susli...@gmail.com> wrote: >> >> On Wed, Apr 27, 2016 at 7:22 PM, Theo de Raadt <dera...@cvs.openbsd.org> >> wrote: >&

Re: pool related crashes, but "kernel did no panic"

On Wed, Apr 27, 2016 at 7:22 PM, Theo de Raadt <dera...@cvs.openbsd.org> wrote: >> On 27/04/16(Wed) 15:45, Alexey Suslikov wrote: >> > Theo de Raadt cvs.openbsd.org> writes: >> > >> > > >> > > Most of these bug reports completely stink. &

Re: pool related crashes, but "kernel did no panic"

Theo de Raadt cvs.openbsd.org> writes: > > Most of these bug reports completely stink. > > ALWAYS include *ALL* information in a report. In an idealistic world, yes. Above are not parts of the "chain", but different statements of the same bug. To have both blue screen and ddb, I need to keep

Re: pool related crashes, but "kernel did no panic"

Stuart Henderson spacehopper.org> writes: > There should be some lines printed before you get dumped into DDB > (probably a uvm_fault), the information in them is important. I either have a screenshot, or ddb. Not both at the same time. Here is one of screenshots from 5.9 transcribed:

Re: pool related crashes, but "kernel did no panic"

Another one from my collection. Apr 16: ddb{0}> show panic the kernel did not panic ddb{0}> trace pool_do_get() at pool_do_get+0x90 pool_get() at pool_get+0xb5 m_get() at m_get+0x28 sbappendaddr() at sbappendaddr+0x9a uipc_usrreq() at uipc_usrreq+0x3b8 sosend() at sosend+0x3d8 dosendsyslog() at

pool related crashes, but "kernel did no panic"

Hi tech@. (Maybe related to http://marc.info/?l=openbsd-bugs=146174654219490=2). Crashing server acts as a carp backup (master has same hardware config but don't crash, in contrast to backup). Will post additional information if necessary. There's a collection of crashes (including pre 5.9) but

Re: Optimize pledge-related notes in 59.html

Theo de Raadt openbsd.org> writes: > so thanks for your suggestion. have you ever noticed how suggestions > are taken less seriously when they are not formatted as a diff? --- 59.html.origThu Feb 18 11:45:24 2016 +++ 59.html Thu Feb 18 12:03:29 2016 @@ -100,21 +100,21 @@

Optimize pledge-related notes in 59.html

Hi tech@. pledge itself is a security feature, so maybe it is better to put pledge under "Security improvements", like "More than 200 daemons and programs was pledged, among them: dhclient, dhcpd, fdisk" etc I found myself happy to understand what a) pledge is a security feature, b) how deep

Re: Make em(4) more mpsafe again

Juuso Lapinlampi partyvan.eu> writes: > > - * These parameters control when the driver calls the routine to reclaim > > - * transmit descriptors. > > + * Thise parameter controls the minimum number of available transmit > > + * descriptors needed before we attempt transmission of a packet. > >

Re: pledge telnet

On Fri, Nov 13, 2015 at 8:40 PM, Theo de Raadt wrote: >> > On 2015/11/13 09:59, Theo de Raadt wrote: >> > > > > I really want to delete telnet entirely, >> > > > >> > > > I often use it for testing unencrypted SMTP and HTTP across the >> > > > Internet. Which tool would

Re: pledge telnet

On Fri, Nov 13, 2015 at 9:00 PM, Theo de Raadt wrote: >> It is similar to (optional) XMODEM/ZMODEM disciplines over serial, IMO. > > No, it is similar to over the INTERNET, because the INTERNET > is nothing at all like a serial line, the later generally being nicely >

Re: pledge telnet

Stuart Henderson wrote: > On 2015/11/13 09:59, Theo de Raadt wrote: > > > > I really want to delete telnet entirely, > > > > > > I often use it for testing unencrypted SMTP and HTTP across the > > > Internet. Which tool would you recommend for that purpose? > > > > nc(1). > I use telnet fairly

Re: mpsafe gem(4)

Martin Pieuchot openbsd.org> writes: > + /* > + * If we have enough room, clear IFF_OACTIVE to tell the stack > + * that it iss OK to send packets. > + */ there's a typo here. "that it iss" should be "that it is".

Re: ifdef DIAGNOSTIC in azalia.c

Alexey Suslikov gmail.com> writes: > > Alexey Suslikov gmail.com> writes: > > > If there is a need to debug something in azalia.c, defining DIAGNOSTIC > > is overkill so replace two instances of DIAGNOSTIC with AZALIA_DEBUG > > (DPRINTF->printf suggested by

Re: ifdef DIAGNOSTIC in azalia.c

Alexey Suslikov gmail.com> writes: > If there is a need to debug something in azalia.c, defining DIAGNOSTIC > is overkill so replace two instances of DIAGNOSTIC with AZALIA_DEBUG > (DPRINTF->printf suggested by ratchov ). > > Also, entirely remove 3rd instance of

Re: Unlocking ix(4) a bit further

Mark Kettenis xs4all.nl> writes: > + * Thise parameter controls the minimum number of available transmit "Thise" should be "This" here.

ifdef DIAGNOSTIC in azalia.c

Hi tech@. If there is a need to debug something in azalia.c, defining DIAGNOSTIC is overkill so replace two instances of DIAGNOSTIC with AZALIA_DEBUG (DPRINTF->printf suggested by ratchov@). Also, entirely remove 3rd instance of DIAGNOSTIC. Normally it is not compiled and, ratchov@ thinks,

Re: Dropping needless globals (ksh)

Michael McConville sccs.swarthmore.edu> writes: > RCS file: /cvs/src/bin/ksh/c_ksh.c,v > - shprintf(newline); > + shprintf("\n"); In terms of portability, are you sure newline is \n on all platforms?

Re: Avoid grabbing the kernel lock in pool backend allocator

Mark Kettenis xs4all.nl> writes: > RCS file: /cvs/src/sys/kern/subr_pool.c,v > kd.kd_waitok = ISSET(flags, PR_WAITOK); > + /* > + * XXX Until we can call msleep(9) without holding the kernel > + * lock. > + */ > + if (ISSET(flags, PR_WAITOK)) It there a

Wrong man links on 58.html

In wscons(4) works with even more odd trackpads. Added pvbus(4) paravirtual device tree root on virtual machines that are running on hypervisors. http://www.openbsd.org/cgi-bin/man.cgi?query=wscons(4)sec=4 http://www.openbsd.org/cgi-bin/man.cgi?query=pvbus(4)sec=4 are wrong. Should be

size: cannot read a.out: No such file or directory

Hi tech@. size(1) DESCRIPTION says: ... If no file is specified size attempts to report on the file a.out. And, indeed, it warns: $ size size: cannot read a.out: No such file or directory Above message looks misleading in a.out-less world. Cheers, Alexey

Re: [Patch] pf refactoring

Martin Pieuchot mpi at openbsd.org writes: On 17/08/15(Mon) 17:39, Richard Procter wrote: Hi, This series of 29 small diffs slims pf.o by 2640 bytes and pf.c by 113 non-comment lines. We generally discuss one diff per mail. It makes it easier for people to comment and as you can

sys/arch/{hppa,hppa64}/dev/apic.c cosmetics, Was:Re: Brainy: User-Triggerable Kernel Memory Leak in execve()

Christian Schulte cs at schulte.it writes: _14/ UNINITIALIZED VARIABLE: sys/arch/hppa64/dev/apic.c rev1.8 At l.176, 'cnt' is not initialized. I came up with the following. --- sys/arch/hppa/dev/apic.c.orig Sun Aug 9 14:16:56 2015 +++ sys/arch/hppa/dev/apic.cSun Aug 9

Re: Brainy: User-Triggerable Kernel Memory Leak in execve()

Theo de Raadt deraadt at cvs.openbsd.org writes: I would like to point out the noise is coming from *users* -- not from actual developers in the project. http://www.imdb.com/title/tt1278449/ you'll get the idea.

Re: Brainy: User-Triggerable Kernel Memory Leak in execve()

On Sat, Aug 8, 2015 at 2:21 PM, Christian Schulte c...@schulte.it wrote: Am 08/07/15 um 23:46 schrieb Alexey Suslikov: Christian Schulte cs at schulte.it writes: Now, I believe that this effort is too much for my spare time. Then why not release that scanner? That effort could be shared

Re: Brainy: User-Triggerable Kernel Memory Leak in execve()

Christian Schulte cs at schulte.it writes: Now, I believe that this effort is too much for my spare time. Then why not release that scanner? That effort could be shared. What's so secret about it? You have been asked several times already. Start sharing right now. Brainy OpenBSD page

Re: Warning on assembly of RdRand instructions

Michael McConville mmcconv1 at sccs.swarthmore.edu writes: https://www.hyperelliptic.org/tanja/vortraege/random.pdf made my day: “The way RDRAND is being used in kernels = 3.12.3 allows it to cancel out the other entropy. See extract buf().” “if I make RDRAND return [EDX] ^ 0x41414141,

Re: audio: recover after missed interrupts

Alexandre Ratchov alex at caoua.org writes: DPRINTFN(1, %s: rec ptr wrapped, moving %d blocs\n, DPRINTFN(1, %s: play ptr wrapped, moving %d blocs\n, blocs in above DPRINTFNs should be blocks, I think.

Re: Update to /etc/services

Denis Fondras openbsd at ledeuns.net writes: krb524 /tcp# Kerberos 5-4 I would tweak krb524 comment to be # Kerberos 5 to 4 because this is how krb524 reads.

Re: Brainy: User-Triggerable Kernel Memory Leak in execve()

Ville Valkonen weezelding at gmail.com writes: On Jul 21, 2015 9:32 AM, Maxime Villard max at m00nbsd.net wrote: It is not the last bug Brainy has found, but it is the last one I report. I don't have time for that. Maxime Why such a dramatic tone? Because that famous thank you small

Re: Brainy: User-Triggerable Kernel Memory Leak in execve()

sam sam at cmpct.info writes: How about you release the Brainy Code Scanner then? I have so many bugs; in fact, there are so many, I don't even have the time to report them! My scanner is so good! Or perhaps you should report 'just' the relatively important ones? Made my day. Searching

Re: Use m_defrag in intel wireless drivers

Mark Kettenis mark.kettenis at xs4all.nl writes: Index: if_ipw.c /* too many fragments, linearize */ Index: if_iwi.c /* too many fragments, linearize */ Index: if_iwn.c /* Too many DMA segments, linearize mbuf. */ Index: if_wpi.c

Tcl/Tk entry in www/57.html

Hi tech@. Tcl/Tk 8.5.16 and 8.6.2 line (Some highlights section) appears twice: ... Tcl/Tk 8.5.16 and 8.6.2 TeX Live 2013 Tcl/Tk 8.5.16 and 8.6.2 ...

Re: ntpd:support adjusting initial time = y2k36 on 32-bit time_t platforms

Brent Cook busterb at gmail.com writes: + T4 += (uint64_t)tv.tv_sec + JAN_1970 + 1.0e-6 * tv.tv_usec; snip + return ((uint64_t)tv.tv_sec + JAN_1970 + 1.0e-6 * tv.tv_usec); snip Can gettime_from_timeval be used over the code instead of repeating same chunk? T4 +=

Re: Questions about 802.11n support

T. Jameson Little beatgammit at gmail.com writes: Well, I'm much more capable of fixing existing drivers to make it work well than building something from scratch, and I imagine the same is true for many developers, because you work on whatever affects you. IMO, fixing existing drivers should

Re: Questions about 802.11n support

On Thu, Mar 5, 2015 at 11:45 PM, Stefan Sperling s...@stsp.name wrote: On Thu, Mar 05, 2015 at 09:22:51PM +, Alexey Suslikov wrote: T. Jameson Little beatgammit at gmail.com writes: Well, I'm much more capable of fixing existing drivers to make it work well than building something from

Re: Questions about 802.11n support

T. Jameson Little beatgammit at gmail.com writes: Since USB 2.0 has a maximum throughput of 480Mbit/s, anything higher than 300Mbit/s is not particularly important, and many consumer devices only support 150Mbit/s anyway. 72Mbit/s is completely fine for an initial implementation. I slightly

Re: Brainy: User-Triggerable Kernel Memory Leak

Maxime Villard max at M00nBSD.net writes: 'lsa' being user-controllable, it is easy for a local (un)privileged user to cause the kernel to run out of memory and become unresponsive. OpenBSD 5.6/i386 is affected, and perhaps previous releases. compat_linux(8) says: The Linux compatibility

Re: elantech-v4 clickpad support

Ulf Brosziewski ulf.brosziewski at t-online.de writes: I have written two patches that provide these options (I'm using them on an Acer V5-131 netbook with OpenBSD 5.6/amd64, the clickpad hardware and firmware is identified as Elantech Clickpad, version 4, firmware 0x461f02). There is,

Re: Kernel does not compile with option LOCKDEBUG

Philip Guenther guenther at gmail.com writes: It's dead, Jim, let's bury LOCKDEBUG. There is an define AZALIA_LOG_MP and accompanying code in sys/dev/pci/azalia.c which looks like a debug left-over. azalia(4) is considered MP-safe for over a year from now.

PATCH: azalia(4) invalid index crash

Hi tech@. See http://marc.info/?l=openbsd-bugsm=141867088702648w=2 Reported by t...@openmailbox.org, John M. Molloy moll...@acm.org and confirmed this diff to fix an issue. --- azalia.c.orig Mon Dec 15 23:23:14 2014 +++ azalia.cWed Dec 17 13:42:41 2014 @@ -2348,14 +2348,23 @@

PATCH: more of airport

Hi tech@. Fixing existing names, plus some new. --- airport.origWed Dec 17 14:16:04 2014 +++ airport Wed Dec 17 14:25:51 2014 @@ -328,6 +328,7 @@ CJB:Peelamedu, Coimbatore, India CJS:International Abraham Gonzalez, Ciudad Juarez, Chihuahua, Mexico CJU:Cheju, Cheju, South Korea

Re: Binary code patching and paravirtualization

CVSROOT: /cvs Module name: src Changes by: s...@cvs.openbsd.org 2014/12/16 14:02:58 Modified files: sys/arch/amd64/amd64: identcpu.c sys/arch/amd64/include: specialreg.h Log message: Define and print HV cpuid flag. This is set by many hypervisors, including kvm, vmware, hyper-v. do they

Re: Binary code patching and paravirtualization

Stefan Fritsch sf at sfritsch.de writes: --- a/sys/arch/amd64/include/specialreg.h +++ b/sys/arch/amd64/include/specialreg.h at at -158,6 +158,7 at at #define CPUIDECX_AVX0x1000 /* Advanced Vector Extensions */ #define CPUIDECX_F16C 0x2000 /* 16bit

amd64 intro(4) refs

Hello tech@. I noticed isapnp(4) and eisa(4) refs in amd64 intro(4) while amd64 kernel config doesn't do neither isapnp, nor eisa. Looks like a remnant after i386 intro(4). Cheers, Alexey

Re: amd64 intro(4) refs

Jason McIntyre jmc at kerhand.co.uk writes: On Tue, Dec 09, 2014 at 10:27:45PM +0200, Alexey Suslikov wrote: I noticed isapnp(4) and eisa(4) refs in amd64 intro(4) while amd64 kernel config doesn't do neither isapnp, nor eisa. those pages are not MD, so they display for all archs. that's

Re: LibreSSL: GOST ciphers implementation

Chris Cappuccio chris at nmedia.net writes: So, you're saying, he's really dmitry at svr.gov.ru, the source of Russian backdoors into technology worldwide!!! I guess the open-source ecosystem has been thoroughly poisoned! Putin is going to take us over. OpenBSD and Linux are ruined!

Re: LibreSSL: GOST ciphers implementation

Bob Beck beck at openbsd.org writes: 1) It can't mess up the code base for everyone. 2) Everyone should not need to eat the dog food 3) I try to convince myself that our grant means a half of a cruise missile doesn't get built (c)

Re: armv7: banana pi, Allwinner A20 board

SASANO Takayoshi uaa at mx5.nisiq.net writes: Try this[1] kernel and have a look if it has the same issue or not. Kernel did not started... U-Boot says checksum is ok, so maybe .umg file is not corrupted. When using OpenBSD 5.6 (RAMDISK-SUNXI) #3: Sun Aug 31 18:46:49 EDT 2014 could you

Re: run(4) firmware update; please test

Stefan Sperling stsp at openbsd.org writes: Are you able to try your run(4) device with FreeBSD-current (10 isn't new enough)? They claim to support your device and use the updated firmware. Please take a look at my (unfinished) attempt to bring MediaTek/Ralink RT5370/RT5372 support to

Re: vlan tagging surgery

Henning Brauer lists-openbsdtech at bsws.de writes: I must admit I am getting tired of all these good proposals/ideas. don't you think we've gone thru this before? Look, I haven't called them good or bad. what you propose would require a custom vlan_output function which does nothing but

Re: vlan tagging surgery

Henning Brauer lists-openbsdtech at bsws.de writes: And lot of (possible) encapsulation subsystems in the middle: vlan, vlan-in-vlan, ipsec, you name it. VLAN IS NOT AN ENCAPSULATION. Well, vlan(4) says: vlan, svlan - IEEE 802.1Q/1AD encapsulation/decapsulation pseudo-device Given a

WIP: MediaTek/Ralink RT5370/RT5372

This is based on http://svnweb.freebsd.org/base?view=revisionrevision=257955 For now, my DWA-140 rev B3 is able to * attach to run(4) and correctly identify MAC address; * load firmware on ifconfig up; * blink LED (so I think something is going thru a radio); * ifconfig down (LED stops

Randomization from the bootblocks

Theo de Raadt deraadt at cvs.openbsd.org writes: This requires an upgrade of the bootblocks and at least /etc/rc (which saves an entropy file for future use). Some bootblocks will be able to use machine-dependent features to improve the entropy even further (for instance using random

pfsync(4) mangles prio in master/slave setup

Hi. This is on 5.4-stable. Trivial master/slave carp(4) setup. vlan(4) is to make picture clear wrt prio. Test 1 (without using match). pf.conf (BOX1 and BOX2). ext_if=vlan101 dmz_if=vlan10 pf_sync=vlan50 block log all pass quick on $pf_sync proto pfsync keep state (no-sync) set prio 7 pass

Re: pfsync(4) mangles prio in master/slave setup

they were right when state was created on master). I will be glad to provide more information/tests/etc - just say what is needed. On 20 November 2013 12:11, Alexey Suslikov alexey.susli...@gmail.com wrote: Hi. This is on 5.4-stable. Trivial master/slave carp(4) setup. vlan(4) is to make picture

Re: pfsync(4) mangles prio in master/slave setup

On Wed, Nov 20, 2013 at 1:38 PM, Alexey Suslikov alexey.susli...@gmail.com wrote: On Wed, Nov 20, 2013 at 1:32 PM, Mike Belopuhov m...@belopuhov.com wrote: could you please add more description to this report since it's very hard to follow and interpret your mail. basically, when setup

Re: pfsync(4) mangles prio in master/slave setup

On Wed, Nov 20, 2013 at 2:15 PM, Florian Obser flor...@openbsd.org wrote: On Wed, Nov 20, 2013 at 01:38:11PM +0200, Alexey Suslikov wrote: On Wed, Nov 20, 2013 at 1:32 PM, Mike Belopuhov m...@belopuhov.com wrote: could you please add more description to this report since it's very hard

Re: Unexpected match set prio behaviour

On Mon, Nov 18, 2013 at 3:03 AM, Alexander Bluhm alexander.bl...@gmx.net wrote: On Thu, Nov 14, 2013 at 12:03:21AM +0200, Alexey Suslikov wrote: This is on 5.4-stable. vlan is only used to see what resulting prio is. #match on { $int_if } inet proto icmp all icmp-type echoreq set prio 5 pass

Unexpected match set prio behaviour

Hi tech@. This is on 5.4-stable. vlan is only used to see what resulting prio is. The ruleset: --- ext_if=em0 int_if=vlan2525 set skip on { lo enc0 em1 } block log all #match on { $int_if } inet proto icmp all icmp-type echoreq set prio 5 pass quick on { $ext_if, $int_if } --- The vlan: ---

Re: 2 x em(4) and 2 x bnx(4) trunk(4)s behave differently

On Mon, Nov 11, 2013 at 11:42 AM, Stuart Henderson s...@spacehopper.org wrote: master on em0/em1/bnx0 is nothing to do with trunk, it is about the gigabit ethernet clocking source. ok, but it is obvious: documentation is unclear (silent) about that. lacp hashing policy is the same as for

Re: 2 x em(4) and 2 x bnx(4) trunk(4)s behave differently

trunkport em0 trunkport em1 up -inet6 on switch itself, both trunks have no visible difference in configuration. 2013/11/11 Alexey Suslikov alexey.susli...@gmail.com On Mon, Nov 11, 2013 at 11:42 AM, Stuart Henderson s...@spacehopper.org wrote: master on em0/em1/bnx0 is nothing to do

Re: 2 x em(4) and 2 x bnx(4) trunk(4)s behave differently

On Mon, Nov 11, 2013 at 12:43 PM, Stuart Henderson st...@openbsd.org wrote: On 2013/11/11 12:15, Alexey Suslikov wrote: On Mon, Nov 11, 2013 at 11:42 AM, Stuart Henderson s...@spacehopper.org wrote: master on em0/em1/bnx0 is nothing to do with trunk, it is about the gigabit ethernet

Re: 2 x em(4) and 2 x bnx(4) trunk(4)s behave differently

On Mon, Nov 11, 2013 at 1:00 PM, Stuart Henderson st...@openbsd.org wrote: On 2013/11/11 12:15, Alexey Suslikov wrote: I see different inbound packet distribution on trunk on-top of em(4)s and on trunk on top of bnx(4)s - that's the real problem. On 2013/11/11 10:43, I wrote: The trunk

2 x em(4) and 2 x bnx(4) trunk(4)s behave differently

Hi tech@. Two machines (A and B) running recent 5.4-stable plugged into same switch. A has: em0 at pci4 dev 0 function 0 Intel 82573E rev 0x03: msi, address 00:30:48:66:a0:ec em1 at pci5 dev 0 function 0 Intel 82573L rev 0x00: msi, address 00:30:48:66:a0:ed B has: bnx0 at pci2 dev 0 function

Re: defer routing table updates on link state changes

Reyk Floeter wrote: Yes, in theory if_index should be fixed and return a consistent number between 1 and the number of interfaces. But this is obviously difficult and I'm not sure if it's worth the effort. So the hack that you're going to remove was a best effort. But putting another

octeon bits on 54.html

Hi tech@. 54.html says: Ubiquiti Networks EdgeRouter LITE (no local storage) How should I read it: an EdgeRouter LITE variant with no local storage or local storage is currently not supported? Cheers, Alexey

Re: drm bits on 54.html

On Sat, Aug 10, 2013 at 12:09 PM, Brad Smith b...@comstyle.com wrote: - Original message - On Sat, Aug 10, 2013 at 11:58 AM, Brad Smith b...@comstyle.com wrote: - Original message - Hi tech@. 54.html says: Now mostly in sync with Linux 3.8.13 But there's

a.out in gcc-local(1)

Hi tech@ Just found no longer relevant block in gcc-local(1): - On a.out platforms (i.e. vax), gcc uses a linker wrapper to write stubs that call global constructors and destructors. Those platforms use gcc 2.95.3, and those calls can be traced using -Wl,-trace-ctors-dtors, using

Re: Stop printing excessive numbers of ACPI wakeup devices

On Sun, Jun 2, 2013 at 12:05 AM, Theo de Raadt dera...@cvs.openbsd.org wrote: Mike Larkin mlarkin at azathoth.net writes: It's sometimes nice to know what devices can wake up a machine, and from what sleep state. But I'm fine suppressing these also. Don't want this to end up being a

Re: Stop printing excessive numbers of ACPI wakeup devices

On Sun, Jun 2, 2013 at 12:14 AM, Mark Kettenis mark.kette...@xs4all.nl wrote: Date: Sun, 2 Jun 2013 00:09:25 +0300 From: Alexey Suslikov alexey.susli...@gmail.com On Sun, Jun 2, 2013 at 12:05 AM, Theo de Raadt dera...@cvs.openbsd.org wrote: Mike Larkin mlarkin at azathoth.net writes

Question about MP safe audio/video

Hi tech@. Are uvideo(4), bktr(4) and similar also MP safe or they somewhat different in terms of a technique used to make audio MP safe? Cheers, Alexey

amd64errata.c,v 1.4

For our crash, v 1.4 of amd64errata.c is no-op unless we de-static functions' prototypes. acpiprt0 at acpi0: bus 0 (PCI0) mpbios0 at bios0: Intel MP Specification 1.4 cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Phenom(tm) 9550 Quad-Core Processor, 3600.54 MHz cpu0:

Re: Possible relayd memory leak analysis

recent snaps don't have above mentioned problem. no sure what was the cause, but leak is gone. On Tue, Apr 9, 2013 at 1:47 AM, Alexey Suslikov alexey.susli...@gmail.com wrote: hi tech@ tools used: * ps auxwww | grep relayd * httperf --hog --server=192.168.5.201 --wsess=25,1000,0.1 --rate=50

cvsweb says 'No viewable change' for i915_drv.c diffs

Hi. Try this http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/drm/i915/i915_drv.c.diff?r1=1.26;r2=1.27;f=h and, for instance, this http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/drm/i915/i915_dma.c.diff?r1=1.6;r2=1.7;f=h Former says No viewable change. I think it isn't normal. Am I

Re: cvsweb says 'No viewable change' for i915_drv.c diffs

googled gnu cvs utf diff and found this http://stackoverflow.com/questions/778291/how-do-i-diff-utf-16-files-with-gnu-diff On Wed, May 15, 2013 at 2:03 PM, Stuart Henderson st...@openbsd.org wrote: On 2013/05/15 11:53, Stuart Henderson wrote: On 2013/05/15 10:43, Alexey E. Suslikov wrote:

Re: external ip/tcp (sysctl) variables

RCS file: /home/ncvs/src/sys/netinet/ip_var.h,v retrieving revision 1.44 diff -u -p -r1.44 ip_var.h --- netinet/ip_var.h 16 Jul 2012 18:05:36 - 1.44 +++ netinet/ip_var.h 8 Apr 2013 13:23:23 - @@ -149,8 +149,20 @@ extern struct ipstat ipstat; extern LIST_HEAD(ipqhead, ipq) ipq; /*

Possible relayd memory leak analysis

hi tech@ tools used: * ps auxwww | grep relayd * httperf --hog --server=192.168.5.201 --wsess=25,1000,0.1 --rate=50 --timeout=5 target machine: OpenBSD 5.3-current (GENERIC.MP) #0: Sun Apr 7 15:14:10 EEST 2013 *@*:/usr/src/sys/arch/amd64/compile/GENERIC.MP /etc/relayd.conf:

SSE4.2 CRC32 question

Hi tech@. Can OpenBSD use SSE4.2 CRC32 (found on Core i7) to speedup TCP/IP checksum calculations? Cheers, Alexey

Re: goodbye to some isa devices

On Wed, Mar 27, 2013 at 10:04 PM, Miod Vallat m...@online.fr wrote: Not sure about ancient 3Com's, but they are Ethernet at least, in contract to Token-Ring device like tr*. Do we support Token-Ring? We used to, on TRopic boards, but since public documentation for TR hardware amounts to

Re: goodbye to some isa devices

On Wed, Mar 27, 2013 at 10:24 PM, Miod Vallat m...@online.fr wrote: Do we support Token-Ring? We used to, on TRopic boards, but since public documentation for TR hardware amounts to zilch, and there is no interest in changing this situation, it was eventually removed from the tree to

5.3 lyrics

hi tech@. despite of 5.3 lyrics being released recently, 53.html says opposite. is it normal? cheers, alexey

Re: Threads related SIGSEGV in random.c (diff, v2)

On Thu, Mar 14, 2013 at 6:48 PM, Ted Unangst t...@tedunangst.com wrote: On Thu, Mar 14, 2013 at 17:24, Antoine Jacoutot wrote: On Thu, Mar 14, 2013 at 11:41:52AM -0400, Ted Unangst wrote: On Thu, Mar 14, 2013 at 14:30, Antoine Jacoutot wrote: FYI I am seeing a somehow similar crash when

Re: savecore on swap-less amd64 box

On Mon, Dec 17, 2012 at 2:44 PM, Mark Kettenis mark.kette...@xs4all.nl wrote: Date: Mon, 17 Dec 2012 14:14:40 +0200 From: Alexey Suslikov alexey.susli...@gmail.com Hello tech@. On swap-less amd64 box using 20121213 amd64 snap, I have noticed a difference in how savecore behaves on SP and MP

Re: MBA remove unneeded quirk

On Tue, Dec 4, 2012 at 2:38 PM, Alexandre Ratchov a...@caoua.org wrote: On Sat, Dec 01, 2012 at 05:14:46PM +0800, Ray Lai wrote: I'm not sure why jakemsr's diff[1] has AZ_QRK_GPIO_UNMUTE_1, my MBA works fine without it. I've tested both left and right channels on both speakers and headphones.

Re: [PATCH, TEST] Make functions in random.c thread safe

Hi. Me and Roman are curious about zero comments on this. We'll try to improve the diff if it is not ok. Just let us know. Anyone? :) On Wed, Oct 3, 2012 at 4:06 PM, Alexey Suslikov alexey.susli...@gmail.com wrote: Hi. Is there any progress/comments on this? On Fri, Sep 28, 2012 at 11:29

Re: [PATCH, TEST] Make functions in random.c thread safe

Hi. Is there any progress/comments on this? On Fri, Sep 28, 2012 at 11:29 PM, Alexey Suslikov alexey.susli...@gmail.com wrote: Hi. With input from tedu@, guenther@ and others, below are: 1) test case; 2) backtrace for test case; 3) locking diff; 4) dmesg (amd64 GENERIC.MP built from 2012

[PATCH, TEST] Make functions in random.c thread safe

Hi. With input from tedu@, guenther@ and others, below are: 1) test case; 2) backtrace for test case; 3) locking diff; 4) dmesg (amd64 GENERIC.MP built from 2012-09-28 CVS). Diff introduces no changes to srandomdev(): correct me if I'm wrong, but no mutex can be used since sysctl can sleep.

Re: Threads related SIGSEGV in random.c (diff, v2)

On Thursday, September 27, 2012, Philip Guenther wrote: On Thu, 27 Sep 2012, Alexey Suslikov wrote: Removing only local variables part reverts us to previous behavior (i.e. crashes). My guess is your program is calling srandom(), srandomdev(), initstate() or setstate() as well. Your diff

Threads related SIGSEGV in random.c (diff, v2)

On Thursday, September 27, 2012, Alexey Suslikov wrote: On Thursday, September 27, 2012, Philip Guenther wrote: On Thu, 27 Sep 2012, Alexey Suslikov wrote: Removing only local variables part reverts us to previous behavior (i.e. crashes). My guess is your program is calling srandom

Re: Threads related SIGSEGV in random.c (diff, v2)

Hi. Any news on that? On Friday, September 21, 2012, Alexey Suslikov wrote: On Fri, Sep 21, 2012 at 10:36 AM, Alexey Suslikov alexey.susli...@gmail.com javascript:; wrote: On Wed, Sep 19, 2012 at 10:24 PM, Ted Unangst t...@tedunangst.comjavascript:; wrote: On Wed, Sep 19, 2012 at 18

Re: Threads related SIGSEGV in random.c (diff, v2)

On Wed, Sep 26, 2012 at 9:51 PM, Ted Unangst t...@tedunangst.com wrote: On Wed, Sep 26, 2012 at 11:18, Alexey Suslikov wrote: Hi. Any news on that? Can we do it without the local variables for speed part? I am not interested in making this function faster. Removing only local variables

Re: Threads related SIGSEGV in random.c

On Wed, Sep 19, 2012 at 10:24 PM, Ted Unangst t...@tedunangst.com wrote: On Wed, Sep 19, 2012 at 18:50, Alexey Suslikov wrote: On Wednesday, September 19, 2012, Theo de Raadt wrote: arc4random() is also thread-safe (it has interal locking) and very desirable for other reasons. But no way

Threads related SIGSEGV in random.c (diff, v2)

On Fri, Sep 21, 2012 at 10:36 AM, Alexey Suslikov alexey.susli...@gmail.com wrote: On Wed, Sep 19, 2012 at 10:24 PM, Ted Unangst t...@tedunangst.com wrote: On Wed, Sep 19, 2012 at 18:50, Alexey Suslikov wrote: On Wednesday, September 19, 2012, Theo de Raadt wrote: arc4random() is also thread

Re: Threads related SIGSEGV in random.c

On Wednesday, September 19, 2012, Theo de Raadt wrote: arc4random() is also thread-safe (it has interal locking) and very desirable for other reasons. But no way to save state. The last part of this is intentional. Saving the state of pseudo random number generators is a stupid concept

Re: Threads related SIGSEGV in random.c

On Wed, Sep 19, 2012 at 10:24 PM, Ted Unangst t...@tedunangst.com wrote: On Wed, Sep 19, 2012 at 18:50, Alexey Suslikov wrote: On Wednesday, September 19, 2012, Theo de Raadt wrote: arc4random() is also thread-safe (it has interal locking) and very desirable for other reasons. But no way

Threads related SIGSEGV in random.c

Hello tech@. This one being discovered by Roman Kravchuk using Kannel port (see https://github.com/jasperla/openbsd-wip/tree/master/net/kannel). While stress testing, Kannel components die with Program received signal SIGSEGV, Segmentation fault. [Switching to thread 1006387] 0x0cb33345cf6e

  1   2   >