Re: Chip cheaper than chips
Not yet thanks. Not if it has that flawed Intel ME in it, I don't want it running on my routers. I have enough trouble coming to grips with AMD's Platform Security Processor rubbish, but at least that hasn't got any known exploits, and the firmware blob for it appears much smaller. On Fri, 01 Dec 2017 14:48:59 -0500 Rupert Gallagher wrote: > I am drooling for an Intel Atom C3308. Two cores, but who cares? Higher > context switch: so what? It is faster than quad-core pcengines! It supports > m.2, to finally replace mPCI and mSATA with a single universal connector. It > has both aes-ng and qat, to make vpn faster than fast! It costs 32$!!! Give > it to me! GIVE IT TO MEEE!!! > > Can we setup an *hail mary* to pcengines and ask them to upgrade? > > http://ark.intel.com/products/97935?ui=BIG
Problem booting OpenBSD/amd64 with LSI MegaRAID card
Hello, I'm running into a problem when I try to boot the OpenBSD install disc with an LSI Logic MegaRAID SAS 9240-8i (mfi driver) card installed in the machine. I take the card out and it boots just fine from the disc, but I get the following panic with the RAID card in: --- boot> cannot open cd0a:/etc/random.see: No such file or directory booting cd0a:/6.2/amd64/bsd.rd: 3371132+1459200+3873512+0+598016 [373741+82+427200+282103]=0x9e99c0 entry point at 0x1000158 panic: init_x86_64: can't find end of memory The operating system has halted. Please press any key to reboot. --- The card is in an Intel Core 2 Quad system with 8GB of RAM. It has two logical drives, one in RAID5 and another in RAID1. Any help getting past this would be much appreciated. If more information is needed, please let me know. Thanks, Shane
Having a problem with ldomctl
Hello, I'm trying to breath some life into some Sun T5120's that no longer have oracle support for by switching them to OpenBSD6.2. The issue I'm having is when I go to dump the contents of the NVRAM config into the current working directory to copy for my new config, the ldomctl dump command never completes. I don't know what the expected behavior is as I've never run OpenBSD as the primary domain before. However after letting ldomctl dump run for over an hour all I have is one file and the process is still running: -rw-r--r-- 1 root wheel 23168 Dec 1 18:37 hv.md I've tried running ldomd in the foreground to see if there is any sort of error but it seems to all be running okay. Before I cleared the system of all my old LDOMs ldomctl was seeing them fine and was able to access them. Can anyone who has run this before tell me if ldomctl dump just takes a really long time or possibly shed some light on where I have gone wrong? As a side note OpenBSD runs beautifully on these hosts in an ldom. I have had zero issues. Just trying to stop using Solaris all together now. Thanks for any help you can give. Massive amount of system info follows: from the service processor: hypervisor_version = Hypervisor 1.10.7.g 2014/07/10 11:46 obp_version = OpenBoot 4.33.6.f 2014/07/10 10:23 post_version = POST 4.33.6.f 2014/07/10 10:32 sysfw_version = Sun System Firmware 7.4.8.a 2014/10/12 09:186.2 Dmesg: console is /virtual-devices@100/console@1 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2017 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 6.2 (GENERIC.MP) #303: Tue Oct 3 22:46:49 MDT 2017 dera...@sparc64.openbsd.org:/usr/src/sys/arch/sparc64/compile/GENERIC.MP real mem = 68585259008 (65408MB) avail mem = 67371524096 (64250MB) warning: no entropy supplied by boot loader mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root: SPARC Enterprise T5120 cpu0 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz cpu1 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz cpu2 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz cpu3 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz cpu4 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz cpu5 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz cpu6 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz cpu7 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz cpu8 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz cpu9 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz cpu10 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz cpu11 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz cpu12 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz cpu13 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz cpu14 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz cpu15 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz cpu16 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz cpu17 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz cpu18 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz cpu19 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz cpu20 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz cpu21 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz cpu22 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz cpu23 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz cpu24 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz cpu25 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz cpu26 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz cpu27 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz cpu28 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz cpu29 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz cpu30 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz cpu31 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz cpu32 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz cpu33 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz cpu34 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz cpu35 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz cpu36 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz cpu37 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz cpu38 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz cpu39 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz cpu40 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz cpu41 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz cpu42 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz cpu43 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz cpu44 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz cpu45 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz cpu46 at mainbus0: SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz cpu47 at ma
Re: broken EHCI USB on AMD chipset?
> From: Stefan Sperling > Sent: Friday, December 1, 2017 10:35 AM > > Problems with ehci(4) on AMD SB700 are known. > For instance, athn(4) USB devices don't work on such ports. Interesting; that's a similar device to the LTE network modem I'm working with. > Could you try adding missing workarounds to our EHCI driver to fix > your problem? That would probably help with other known issues, too. Hmm, sadly low level device drivers aren't my area of expertise :(. I was trying to compare the Linux driver, but it is structured quite differently than the openbsd one. Now that I see that the FreeBSD one works, at least as far as hot plug/remove, it is more similar to the openbsd driver, I'll see if I can pick anything out of it that I can make sense out of to add to openbsd. I did find a section of code in OpenBSD's echi_pci.c with a comment of "Enable workaround for dropped interrupts as required" which was being applied to ATI chipsets; I was excited for a moment as that seems to be exactly the problem being experienced and AMD bought ATI, so I hoped perhaps enabling that for my AMD chipset would do something, but unfortunately all it did was result in interrupt timed out messages . There's another function called ehci_sb700_match that's looking for an ATI chipset, which controls whether or not to "apply the ATI SB600/SB700 workaround", those are also the names of the AMD controllers, I'm going to look to see if perhaps those should be applied or not and if they do anything. If my shooting in the dark comes up with anything promising I'll bring it back to show somebody who knows what they're doing :). Thanks.
Re: sftp-server
On Fri, Dec 01, 2017 at 02:59:38AM -0500, Jiri B wrote: > On Thu, Nov 30, 2017 at 05:36:57PM -0600, Edgar Pettijohn wrote: > > I was looking into how best to secure a sftp-server. The manual > > mentions a -Q option to query protocol features supported. I added the > > following line to sshd_config. > > > > Subsystem sftp/usr/libexec/sftp-server sftp -Q requests > > > > So far I'm not sure how to get at the information provided by this > > command line option. Or am I doing it wrong? For future reference: $ /usr/libexec/sftp-server -Q requests gives the following output: open close read write lstat fstat setstat fsetstat opendir readdir remove mkdir rmdir realpath stat rename readlink symlink posix-rename statvfs fstatvfs hardlink fsync > > > > Any insight is greatly appreciated. > > > > Edgar > > IMO you got confused, it is "query", it does not set anything. I didn't suggest it did set anything. The other command line options require they be set in sshd_config, so thats what I tried. Didn't click to try on the command line. :( > > Output of "-Q requests" as "requests"/actions which sftp client > can do on remote server. > > An example: you want to mimic anon ftp upload server, then you > would - IIRC - open, write, lstat,... but not readdir, remote, > symlink etc... My end goal is similar. I want users to log in trapped in their $HOME but be able to make directories, remove directories, upload, download, possibly symlink. I'll just play around with it till I feel comfortable. > > j. >
Chip cheaper than chips
I am drooling for an Intel Atom C3308. Two cores, but who cares? Higher context switch: so what? It is faster than quad-core pcengines! It supports m.2, to finally replace mPCI and mSATA with a single universal connector. It has both aes-ng and qat, to make vpn faster than fast! It costs 32$!!! Give it to me! GIVE IT TO MEEE!!! Can we setup an *hail mary* to pcengines and ask them to upgrade? http://ark.intel.com/products/97935?ui=BIG
Re: [cwm] list all available items
On 30/11/17 12:25, Charlie Eddy wrote: > Just a note that cwm is an old welsh word for a mountain pass, one of the > few OED words with no vowel The Welsh-English Dictionary gives cwm 1. valley n.m. http://www.geiriadur.net/ My Geography teacher taught us many years ago that it especially referred to a valley created by glaciation scooping out a mountain side. It is related to the English place names ending in coombe or combe, such as Ilfracombe.
Re: xterm(1) changing UTF-8 characters when copy-pasting?
On Fri, Dec 1, 2017 at 11:38 AM, Stefan Sperling wrote: > On Fri, Dec 01, 2017 at 12:14:48PM +0100, Ingo Schwarze wrote: > > Anthony J. Bentley wrote on Thu, Nov 30, 2017 at 11:28:54PM -0700: > > > > > You'll need extra fonts once I finish my patch to add situationally > > > appropriate emoji to all our manpages. > > > > I'm looking forward to that. Don't forget to make them animated, > > make the colours fully configurable, and maybe add some nice > > background music, a pleasant scent, and touchscreen support. > > And make them soft and plushy to the touch! > Or spiney and plushy, for when we switch the manpage footer from saying "OpenBSD 6.2" to " 6.2"!
Re: xterm(1) changing UTF-8 characters when copy-pasting?
On Fri, Dec 01, 2017 at 12:14:48PM +0100, Ingo Schwarze wrote: > Hi Anthony, > > Anthony J. Bentley wrote on Thu, Nov 30, 2017 at 11:28:54PM -0700: > > > You'll need extra fonts once I finish my patch to add situationally > > appropriate emoji to all our manpages. > > I'm looking forward to that. Don't forget to make them animated, > make the colours fully configurable, and maybe add some nice > background music, a pleasant scent, and touchscreen support. And make them soft and plushy to the touch!
Re: broken EHCI USB on AMD chipset?
On Tue, Nov 28, 2017 at 08:03:05PM -0800, Paul B. Henson wrote: > The EHCI ports seem to work fine under Linux, including the LTE modem > when attached to them, so this seems to be an issue with openbsd, not > faulty hardware per se. The Linux driver does have a couple of > workarounds in their EHCI driver for AMD chipsets, I'm not sure if > either of them are relevant for this; one involves disabling low power > mode during transfers and the other says: > > "EHCI controller on AMD SB700/SB800/Hudson-2/3 platforms may > read/write memory space which does not belong to it when > there is NULL pointer with T-bit set to 1 in the frame list > table. To avoid the issue, the frame list link pointer > should always contain a valid pointer to a inactive qh" > > I don't see anything specifically discussing flaky interrupts. Any > thoughts on what might be going on here with USB and how it fix it? > Problems with ehci(4) on AMD SB700 are known. For instance, athn(4) USB devices don't work on such ports. Could you try adding missing workarounds to our EHCI driver to fix your problem? That would probably help with other known issues, too.
Re: xterm(1) changing UTF-8 characters when copy-pasting?
Anthony J. Bentley wrote: >I was internally debating this earlier. The bug is already exposed by >any combining characters that don't have precomposed forms. It also >doesn't show up with the default (i.e. non TrueType) fonts. Given that >and how unfriendly the precomposition behavior is, I think disabling it >is still reasonable. I'd agree with that. TrueType fonts are not the default. I think it's more important to get copy-paste to work the way one would expect it to work (even if it displays the characters the wrong way). Philippe
Re: xterm(1) changing UTF-8 characters when copy-pasting?
Anthony J. Bentley wrote: >Philippe Meunier writes: >> - When the precompose resource is set to false, copy-pasting the result of >> printf "e\xcc\x81\n" never works correctly in xterm, regardless of >> whether I use TrueType fonts or not. xterm copy-pastes the correct >> sequence of bytes but that sequence is not displayed correctly. That's a >> bug in xterm. > >I get slightly different results: with TrueType fonts enabled, LC_CTYPE >set to en_US.UTF-8, and precompose disabled, accents are not displayed, >but they do copy and paste correctly. I tested this on a fresh install as >well as my desktop. I haven't been able to trigger the results you're >getting (best guess: your LC_CTYPE is unset or set funny? But I don't get >the same results even then). Strange. I have: $ set | egrep -i 'utf|xterm' LC_CTYPE=en_US.UTF-8 TERM=xterm XTERM_LOCALE=en_US.UTF-8 XTERM_SHELL=/bin/ksh XTERM_VERSION='XTerm/OpenBSD(327)' and even with just this: $ xrdb -query xterm*precompose: false and TrueType enabled, then accents are not displayed and copy-paste does not work: I get an 'e' character followed by another character which is a question mark inside a circle. Philippe
Re: snmpd high memory page fault / cpu usage and high latency / it seems a memory problem
On 2017-12-01, Thomas Boernert wrote: > Hi, > > an update: > > it seems thats a memory pool problem. > > on the same machine its running bgpd with 2 uplinks. How much memory does snmpd use? (You could run it with e.g. "/usr/bin/time -l /usr/sbin/snmpd -vd") "filter-routes yes" is likely to help.
Re: xterm(1) changing UTF-8 characters when copy-pasting?
Allan Streib writes: > $ printf "e\xcc\x81\n" | od -a > 000e cc 81 nl > > $ printf "e\xcc\x81\n" > é > > ^ copy/pasting: $ echo "é" | od -a > 000 c3 a9 nl Also in case it's interesting: $ printf "e\xcc\x81" | xclip -i $ xclip -o | od -a 000e cc 81 $ echo "é" | od -a 000e cc 81 nl In the above, the "é" was obtained with middle-click (paste). $ echo "é" | od -a 000 c3 a9 nl In the above, the entire command 'echo "é" | od -a' was copied from the prior line and pasted with the mouse. Allan
Re: xterm(1) changing UTF-8 characters when copy-pasting?
Ingo Schwarze writes: > Hi, > > Anthony J. Bentley wrote on Fri, Dec 01, 2017 at 08:18:59AM -0700: > > Philippe Meunier writes: > > >> - In addition, when the precompose resource is set to false and TrueType > >> fonts are used, the result of printf "e\xcc\x81\n" itself is wrong (even > >> before trying to copy-paste it): od(1) shows that the correct sequence o > f > >> bytes is printed but it is displayed without accent. That's another bug > >> in xterm. The result is displayed correctly when the precompose resourc > e > >> is set to true. > > > Yes, this matches what I'm seeing. > > To me, that seems to imply that xterm(1), with the bugs it has now, > works significantly better with Precompose enabled: at least it > displays the correct glyphs, while there seem to be cases where it > displays wrong glyphs without Precompose. Right? > > Doesn't that imply that it would be better to fix this bug first, > before disabling Precompose? I certainly hate that xterm(1) is > doing normalization by default now, but if removing that exposes a > bug that causes display of incorrect glyphs, that would seem like > a serious regression to me. > > What do you think? I was internally debating this earlier. The bug is already exposed by any combining characters that don't have precomposed forms. It also doesn't show up with the default (i.e. non TrueType) fonts. Given that and how unfriendly the precomposition behavior is, I think disabling it is still reasonable.
Re: xterm(1) changing UTF-8 characters when copy-pasting?
Hi, Anthony J. Bentley wrote on Fri, Dec 01, 2017 at 08:18:59AM -0700: > Philippe Meunier writes: >> - In addition, when the precompose resource is set to false and TrueType >> fonts are used, the result of printf "e\xcc\x81\n" itself is wrong (even >> before trying to copy-paste it): od(1) shows that the correct sequence of >> bytes is printed but it is displayed without accent. That's another bug >> in xterm. The result is displayed correctly when the precompose resource >> is set to true. > Yes, this matches what I'm seeing. To me, that seems to imply that xterm(1), with the bugs it has now, works significantly better with Precompose enabled: at least it displays the correct glyphs, while there seem to be cases where it displays wrong glyphs without Precompose. Right? Doesn't that imply that it would be better to fix this bug first, before disabling Precompose? I certainly hate that xterm(1) is doing normalization by default now, but if removing that exposes a bug that causes display of incorrect glyphs, that would seem like a serious regression to me. What do you think? Ingo
Re: xterm(1) changing UTF-8 characters when copy-pasting?
Philippe Meunier writes: > - When the precompose resource is set to false, copy-pasting the result of > printf "e\xcc\x81\n" never works correctly in xterm, regardless of > whether I use TrueType fonts or not. xterm copy-pastes the correct > sequence of bytes but that sequence is not displayed correctly. That's a > bug in xterm. I get slightly different results: with TrueType fonts enabled, LC_CTYPE set to en_US.UTF-8, and precompose disabled, accents are not displayed, but they do copy and paste correctly. I tested this on a fresh install as well as my desktop. I haven't been able to trigger the results you're getting (best guess: your LC_CTYPE is unset or set funny? But I don't get the same results even then). > - In addition, when the precompose resource is set to false and TrueType > fonts are used, the result of printf "e\xcc\x81\n" itself is wrong (even > before trying to copy-paste it): od(1) shows that the correct sequence of > bytes is printed but it is displayed without accent. That's another bug > in xterm. The result is displayed correctly when the precompose resource > is set to true. Yes, this matches what I'm seeing.
Re: xterm(1) changing UTF-8 characters when copy-pasting?
Philippe Meunier writes: > - Allan probably did his tests with the precompose resource set to its > default true value. I assume this is correct because I have never deliberately changed it. And you're right after all. $ printf "e\xcc\x81\n" | od -a 000e cc 81 nl $ printf "e\xcc\x81\n" é ^ copy/pasting: $ echo "é" | od -a 000 c3 a9 nl Allan
Re: xterm(1) changing UTF-8 characters when copy-pasting?
Ingo Schwarze writes: > >> +*precompose: false > > > Sure. > > On a more serious note, i'll commit that tomorrow then > based on OK bentley@ unless somebody can point out a downside. Please update the OPENBSD SPECIFICS section of the manual as well. > Hum, i don't doubt your analysis. But now i don't understand why > uxterm(1) works for Allan and plain xterm(1) doesn't... Yeah, my guess is he never disabled precomposition for uxterm, meaning what he's seeing are not actually combining characters, meaning xterm doesn't bug out.
Re: xterm(1) changing UTF-8 characters when copy-pasting?
Ingo Schwarze wrote: >Hum, i don't doubt your analysis. But now i don't understand why >uxterm(1) works for Allan and plain xterm(1) doesn't... Re-reading Allan's email, it's not clear to me whether he did his tests with the precompose resource set to true or false. If using the default value of true then: - Copy-pasting the result of printf "e\xcc\x81\n" works correctly in xterm, regardless of whether I use TrueType fonts or not. That's because, as pointed out by Ingo, xterm rewrites e\xcc\x81 into \xc3\xa9. That's the reason why this whole discussion started (and preventing the rewrite is then the reason why setting the precompose resource to false makes sense). - When using TrueType fonts, printf "e\xcc\x81\n" shows the accent. This is with the precompose resource set to its default true value. Interestingly, when the precompose resource is set to false and TrueType fonts are used, the same printf "e\xcc\x81\n" does not show the accent (as indicated in one of the my previous emails). So it looks like this is not just a font problem after all but another bug (which Anthony actually already pointed out in his second email). So my conclusions so far are: - Allan probably did his tests with the precompose resource set to its default true value. It's either that or there is some as yet unknown extra factor that makes a difference in the results between him and me. - When the precompose resource is set to false, copy-pasting the result of printf "e\xcc\x81\n" never works correctly in xterm, regardless of whether I use TrueType fonts or not. xterm copy-pastes the correct sequence of bytes but that sequence is not displayed correctly. That's a bug in xterm. - In addition, when the precompose resource is set to false and TrueType fonts are used, the result of printf "e\xcc\x81\n" itself is wrong (even before trying to copy-paste it): od(1) shows that the correct sequence of bytes is printed but it is displayed without accent. That's another bug in xterm. The result is displayed correctly when the precompose resource is set to true. Philippe
Re: OpenBSD Puffy Stickers
On Fri, 1 Dec 2017, x9p wrote: ego is a bitch. lets have a beer and live in peace. its friday. بالصحة و العافية
Re: OpenBSD Puffy Stickers
ego is a bitch. lets have a beer and live in peace. its friday. cheers. x9p > On Fri, Dec 1, 2017, at 02:50 AM, Rudy Baker wrote: >> Alright guys, he gets it. I wouldn't want to have to read two obligatory >> leaving letters in one week :) >> >> >> On Dec 1, 2017 1:31 AM, "Eric Furman" wrote: >> >> On Thu, Nov 30, 2017, at 11:07 PM, Theo de Raadt wrote: >> > > Currently the OpenBSD store has mugs, t-shirts, posters, and CDs. >> All of >> > > those require more expense than stickers. Stickers are rather >> inexpensive >> > > to produce, can be sold for high markup, and cost very little to >> ship, >> not >> > > to mention are very popular, especially in the tech industry. >> > > >> > > It wouldn't require any new artwork or commissions. If you were to >> sell >> > > Puffy stickers or OpenBSD Logo stickers I'm sure they'd be >> top-sellers. >> > > >> > > Case in point, UnixStickers.com charges $2.69 per sticker and that >> doesn't >> > > include shipping. >> > >> > Why should I do that? You only thought of yourself. >> > >> > What is in it for me? >> > >> > NOTHING. >> > >> > So why should I do this for you? >> > >> > If you think I should, and you repeatedly send mails saying so I can >> > only conclude one thing: >> > >> > You have a self-entitlement issue. >> > >> >> This *MIGHT* be a great idea, but... >> WHO IS GOING TO DO IT? >> I don't want Theo or any of the Devs wasting their time doing crap like >> this >> that might just turn out to be a wast of time. They should be coding. >> People are always asking "What can I do to help the Project"? >> What people can do is to DO something and not talk about it. >> So, make a batch of stickers yourself and sell them on ebay. >> Then you can see for yourself just how Big A Seller they can be. >> I'm going to bet that it will turn out to take a lot more time and >> effort than you think and that it will turn very little if any profit. >> But hey, don't let me stop you. >> Good luck. > > You misunderstand. > I am genuinely trying to give good advice. > I wish him real Good Luck. > > > I will freely admit, I am all talk and no action. > My contributions to Obsd over the last 20 years > are nothing more than monetary and hardware > donations. But I will wager that is more than > most of you F** have done. > >
Re: OpenBSD Puffy Stickers
On Fri, Dec 1, 2017, at 02:50 AM, Rudy Baker wrote: > Alright guys, he gets it. I wouldn't want to have to read two obligatory > leaving letters in one week :) > > > On Dec 1, 2017 1:31 AM, "Eric Furman" wrote: > > On Thu, Nov 30, 2017, at 11:07 PM, Theo de Raadt wrote: > > > Currently the OpenBSD store has mugs, t-shirts, posters, and CDs. All of > > > those require more expense than stickers. Stickers are rather > inexpensive > > > to produce, can be sold for high markup, and cost very little to ship, > not > > > to mention are very popular, especially in the tech industry. > > > > > > It wouldn't require any new artwork or commissions. If you were to sell > > > Puffy stickers or OpenBSD Logo stickers I'm sure they'd be top-sellers. > > > > > > Case in point, UnixStickers.com charges $2.69 per sticker and that > doesn't > > > include shipping. > > > > Why should I do that? You only thought of yourself. > > > > What is in it for me? > > > > NOTHING. > > > > So why should I do this for you? > > > > If you think I should, and you repeatedly send mails saying so I can > > only conclude one thing: > > > > You have a self-entitlement issue. > > > > This *MIGHT* be a great idea, but... > WHO IS GOING TO DO IT? > I don't want Theo or any of the Devs wasting their time doing crap like > this > that might just turn out to be a wast of time. They should be coding. > People are always asking "What can I do to help the Project"? > What people can do is to DO something and not talk about it. > So, make a batch of stickers yourself and sell them on ebay. > Then you can see for yourself just how Big A Seller they can be. > I'm going to bet that it will turn out to take a lot more time and > effort than you think and that it will turn very little if any profit. > But hey, don't let me stop you. > Good luck. You misunderstand. I am genuinely trying to give good advice. I wish him real Good Luck. I will freely admit, I am all talk and no action. My contributions to Obsd over the last 20 years are nothing more than monetary and hardware donations. But I will wager that is more than most of you F** have done.
Re: snmpd high memory page fault / cpu usage and high latency / it seems a memory problem
Hi, an update: it seems thats a memory pool problem. on the same machine its running bgpd with 2 uplinks. if i stop on the backup machine the bgpd and then start the snmpd, than i have only ~ 4000 page faults. i have 8 GB memory, my ulimit: time(cpu-seconds)unlimited file(blocks) unlimited coredump(blocks) unlimited data(kbytes) 33554432 stack(kbytes)8192 lockedmem(kbytes)2645478 memory(kbytes) 7932772 nofiles(descriptors) 128 processes1310 vmstat -m: Memory statistics by bucket size Size In Use Free Requests HighWater Couldfree 16 1329220 198017870311280 2 3290373507 499199 640 0 64 2314 542737010 320 716371 12815233 31 15111238 160510 256 599345 14283987 80 317745 512 570 62 567922 40 51572 1024 237 11 273160 20 16 2048 609 15 56235 10 19907 4096 1077 3 388144 5 0 8192 206 1 47349 5 0 163848 0 476547 5 0 32768 10 0 74 5 0 655363 0 64044 5 0 1310721 0 1 5 0 2621441 0 1 5 0 Memory usage type by bucket size Size Type(s) 16 devbuf, pcb, rtable, ifaddr, UFS mount, dirhash, ACPI, ip_moptions, exec, pfkey data, xform_data, VM swap, UVM amap, UVM aobj, USB, USB device, temp 32 devbuf, pcb, rtable, ifaddr, UFS mount, sem, dirhash, ACPI, in_multi, ether_multi, exec, pfkey data, UVM amap, USB, USB device, temp 64 devbuf, pcb, rtable, ifaddr, sysctl, vnodes, dirhash, ACPI, proc, in_multi, VM swap, UVM amap, USB, USB device, NDP, temp 128 devbuf, pcb, rtable, ifaddr, vnodes, sem, dirhash, ACPI, NFS srvsock, ip_moptions, in_multi, pfkey data, UVM amap, USB, USB device, IPsec creds, NDP, temp 256 devbuf, rtable, ifaddr, sysctl, ioctlops, iov, vnodes, shm, VM map, dirhash, ACPI, exec, pfkey data, tdb, UVM amap, USB, USB device, temp 512 devbuf, ifaddr, ioctlops, iov, UFS mount, dirhash, ACPI, file desc, ttys, newblk, temp 1024 devbuf, pcb, ifaddr, sysctl, ioctlops, iov, mount, UFS mount, shm, ACPI, file desc, proc, ttys, exec, pfkey data, tdb, USB device, crypto data, temp 2048 devbuf, pcb, ifaddr, ioctlops, iov, UFS mount, ACPI, VM swap, UVM aobj, temp 4096 devbuf, ifaddr, ioctlops, iov, proc, ttys, USB, memdesc, temp 8192 devbuf, iov, ttys, pagedep, temp, SYN cache 16384 devbuf, iov, UFS mount, NFS daemon, MSDOSFS mount, VM swap, temp 32768 devbuf, UFS quota, UFS mount, ISOFS mount, inodedep, VM swap 65536 devbuf, temp 131072 devbuf 262144 devbuf Memory statistics by type Type Kern Type InUse MemUse HighUse Limit Requests Limit Limit Size(s) devbuf 4346 6453K 6518K 78644K641560 0 16,32,64,128,256,512,1024,2048,4096,8192,16384,32768,65536,131072,262144 pcb7819K 20K 78644K235300 0 16,32,64,128,1024,2048 rtable1416838 23588K 23682K 78644K 135781670 0 16,32,64,128,256 ifaddr 38358K 58K 78644K 4060 0 16,32,64,128,256,512,1024,2048,4096 sysctl 3 2K 2K 78644K90 0 64,256,1024 ioctlops 0 0K 4K 78644K452040 0 256,512,1024,2048,4096 iov 0 0K 16K 78644K 8500510 0 256,512,1024,2048,4096,8192,16384 mount 5 5K 10K 78644K 400 0 1024 vnodes 123278K 79K 78644K184140 0 64,128,256 UFS quota 132K 32K 78644K10 0 32768 UFS mount2166K100K 78644K 1610 0 16,32,512,1024,2048,16384,32768 shm 2 2K 2K 78644K20 0 256,1024 VM map 2 1K 1K 78644K20 0 256 sem 2 1K 1K 78644K20 0 32,128 dirhash 12624K 48K 78644K 12150 0 16,32,64,128,256,512 ACPI 14997 1754K 1778K 78644K 28561030 0 16,32,64,128,256,512,1024,2048 file desc 3 2K 3K 78644K40 0 512,1024 proc2011K 11K 78644K 200 0 64,1024,4096 NFS srvsock 1 1K 1K 78644K10 0 128 NFS daemon 116K 16K 78644K10 0 16384 ip_moptions30
Re: xterm(1) changing UTF-8 characters when copy-pasting?
Hi Anthony, Anthony J. Bentley wrote on Thu, Nov 30, 2017 at 11:28:54PM -0700: > You'll need extra fonts once I finish my patch to add situationally > appropriate emoji to all our manpages. I'm looking forward to that. Don't forget to make them animated, make the colours fully configurable, and maybe add some nice background music, a pleasant scent, and touchscreen support. >> +*precompose: false > Sure. On a more serious note, i'll commit that tomorrow then based on OK bentley@ unless somebody can point out a downside. >> +*VT100.utf8: 1 > xterm(1): > This option and the utf8 resource are overridden by the -lc and > -en options and locale resource. > > We set the locale resource, so this appears redundant. Sounds convincing, so we don't need that, even though it used to be in UXTerm.ad. >> +*VT100.font2: -misc-fixed-medium-r-normal--8-80-75-75-c-50-iso10646-1 >> +*VT100.font: -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646 >> -1 >> +*VT100.font3: -misc-fixed-medium-r-normal--14-130-75-75-c-70-iso10646-1 >> +*VT100.font4: -misc-fixed-medium-r-normal--13-120-75-75-c-80-iso10646-1 >> +*VT100.font5: -misc-fixed-medium-r-normal--18-120-100-100-c-90-iso10646-1 >> +*VT100.font6: -misc-fixed-medium-r-normal--20-200-75-75-c-100-iso10646-1 > These are already the default according to appres(1). Hum, i don't doubt your analysis. But now i don't understand why uxterm(1) works for Allan and plain xterm(1) doesn't... I mean, what else is there in the old uxterm script that could possibly make a difference? Yours, Ingo
Re: em0: Hardware Initialization Failed
Hi Jan,
On Sat, 11 Nov 2017, Jan Stary wrote:
> This is current/amd64 on a Dell Latitude E5570 (dmesg below).
> When booting without the ethernet cable plugged in,
> the boot sequence finishes with the following message:
>
> em0: Hardware Initialization Failed
> em0: Unable to initialize the hardware
We had similar problems with some HP laptops.
> When I boot with the cable plugged in, everything works as expected,
> like it always has. But now it seems that the ethernet cable _must_
> be plugged in at boot, otherwise em0 will just not work.
>
> Can somebody with em(4) reproduce?
> How can I debug this?
Can you please try if the patch below helps?
If yes, can you please also try without the msec_delay line after the
"Magic delay ..." comment? Note that in our case, it without that
delay, it would work most of the time but not always. So you will have
to try it several times (10 ... 20) to be sure that it's reliable.
I have only tested the patch with older openbsd releases, but I expect
it works on current, too.
Cheers,
Stefan
commit aa7c279debd5c66e1d2a0b3c18ceb20ef32ce7b7
Author: Stefan Fritsch
Date: Fri Dec 1 09:56:58 2017 +0100
34236: em: Fixes/workarounds for em on HP laptops
Some em chips have a semaphore ("software flag") to synchronize access
to certain registers between OS and firmware (ME/AMT).
Make the logic to get the flag match the logic in freebsd. This includes
higher timeouts and waiting for a previous unlock to complete before
trying a lock again.
Another problem was that openbsd em driver calls em_get_software_flag
recursively, which causes the semaphore to be unlocked too early. Make
em_get_software_flag/em_release_software_flag handle this correctly.
Freebsd does not do this, but they have a mutex that probably allows
them to detect recursive calls to e1000_acquire_swflag_ich8lan().
Reworking the openbsd driver to not recursively get the semaphore would
be very invasive.
Also port the logic from freebsd to em_check_phy_reset_block(). A single
read does not seem to be reliable.
Also, increase delay after reset to 20ms, which is the value in freebsd
for ich8lan.
The changes so far make things more reliable, but not 100%. Add another
1ms delay that seems to help with the remaining #34195 problems on HP
elitebook. A printf() at the same place helps, too.
While there, print mac+phy type in em_attach(), and em_init_hw() error
code if something goes wrong.
diff --git a/sys/dev/pci/if_em.c b/sys/dev/pci/if_em.c
index 985a464aaf9..5b6f3479bf5 100644
--- a/sys/dev/pci/if_em.c
+++ b/sys/dev/pci/if_em.c
@@ -545,6 +545,8 @@ em_attach(struct device *parent, struct device *self, void
*aux)
if (!defer)
em_update_link_status(sc);
+ printf(", mac_type %#x phy_type %#x ", sc->hw.mac_type,
+ sc->hw.phy_type);
printf(", address %s\n", ether_sprintf(sc->sc_ac.ac_enaddr));
/* Indicate SOL/IDER usage */
@@ -1847,8 +1849,8 @@ em_hardware_init(struct em_softc *sc)
INIT_DEBUGOUT("\nHardware Initialization Deferred ");
return (EAGAIN);
}
- printf("\n%s: Hardware Initialization Failed\n",
- DEVNAME(sc));
+ printf("\n%s: Hardware Initialization Failed: %d\n",
+ DEVNAME(sc), ret_val);
return (EIO);
}
diff --git a/sys/dev/pci/if_em_hw.c b/sys/dev/pci/if_em_hw.c
index bd94aca904b..c2aa43ed342 100644
--- a/sys/dev/pci/if_em_hw.c
+++ b/sys/dev/pci/if_em_hw.c
@@ -929,7 +929,9 @@ em_reset_hw(struct em_hw *hw)
}
em_get_software_flag(hw);
E1000_WRITE_REG(hw, CTRL, (ctrl | E1000_CTRL_RST));
- msec_delay(5);
+ /* HW reset releases software_flag */
+ hw->sw_flag = 0;
+ msec_delay(20);
/* Ungate automatic PHY configuration on non-managed 82579 */
if (hw->mac_type == em_pch2lan && !hw->phy_reset_disable &&
@@ -1473,6 +1475,8 @@ em_init_hw(struct em_hw *hw)
/* Set the media type and TBI compatibility */
em_set_media_type(hw);
+ /* Magic delay that improves problems with i219LM on HP Elitebook */
+ msec_delay(1);
/* Must be called after em_set_media_type because media_type is used */
em_initialize_hardware_bits(hw);
@@ -9504,9 +9508,18 @@ em_check_phy_reset_block(struct em_hw *hw)
DEBUGFUNC("em_check_phy_reset_block\n");
if (IS_ICH8(hw->mac_type)) {
- fwsm = E1000_READ_REG(hw, FWSM);
- return (fwsm & E1000_FWSM_RSPCIPHY) ? E1000_SUCCESS :
- E1000_BLK_PHY_RESET;
+ int i = 0;
+ int blocked = 0;
+ do {
+ fwsm = E1000_READ_REG(hw, FWSM);
+ i
Re: sftp-server
On Thu, Nov 30, 2017 at 05:36:57PM -0600, Edgar Pettijohn wrote: > I was looking into how best to secure a sftp-server. The manual > mentions a -Q option to query protocol features supported. I added the > following line to sshd_config. > > Subsystem sftp/usr/libexec/sftp-server sftp -Q requests > > So far I'm not sure how to get at the information provided by this > command line option. Or am I doing it wrong? > > Any insight is greatly appreciated. > > Edgar IMO you got confused, it is "query", it does not set anything. Output of "-Q requests" as "requests"/actions which sftp client can do on remote server. An example: you want to mimic anon ftp upload server, then you would - IIRC - open, write, lstat,... but not readdir, remote, symlink etc... j.
