Re: The unknown in i386-unknown-openbsd5.4
On Mon, 03 Feb 2014 05:15:39 -0500 Brad Smith b...@comstyle.com wrote: Enough is enough. Just drop it. Of course people are going to start making fun of this non issue. How bizarre. I'm sorry the discussion has offended you but I don't think your commands have any authority. If it's a delicate topic, perhaps you could ignore the thread?
Re: The unknown in i386-unknown-openbsd5.4
On Mon, 03 Feb 2014 16:57:28 + Andy a...@brandwatch.com wrote: Please realise who you are talking to and learn to treat this community with respect whether they're a first time user, or a lead dev.. Despite the contextual irony, that seems like a good point. Thanks!
Re: The unknown in i386-unknown-openbsd5.4
On Sun, 2 Feb 2014 16:17:08 + (UTC) na...@mips.inka.de (Christian Weisgerber) wrote: At least it's consistent. FreeBSD's collection of -undermydesk- (gcc) -marcel- (gdb) -unknown- (clang, binutils, occasionally in ports) -portbld- (most ports) would never confuse anybody, would it? It would certainly be disappointing to see something like that in OpenBSD. A new naming convention wouldn't necessarily need to be whimsical and inconsistent, would it? (That's a rhetorical question, but you get my point, right?)
Re: The unknown in i386-unknown-openbsd5.4
On Sun, 02 Feb 2014 18:19:50 +0100 j...@wxcvbn.org (Jérémie Courrèges-Anglas) wrote: Maybe we can just leave it. Indeed. Well, at least you didn't call it a bikeshed issue (though, that probably would have been a more compelling statement).
Re: The unknown in i386-unknown-openbsd5.4
On Sun, 02 Feb 2014 18:43:15 +0100 j...@wxcvbn.org (Jérémie Courrèges-Anglas) wrote: Maybe we can just leave it. Indeed. Well, at least you didn't call it a bikeshed issue (though, that probably would have been a more compelling statement). Fine: I call this a bikeshed issue. All that's needed now is a comparison involving Nazis or Hitler and the cycle will be complete.
Re: The unknown in i386-unknown-openbsd5.4
On Sun, 2 Feb 2014 18:18:06 + (UTC) na...@mips.inka.de (Christian Weisgerber) wrote: Miod Vallat m...@online.fr wrote: i386-donatetoopenbsdfoundationtoday-openbsd5.4? or i386-bikeshed-openbsd. What is the string equivalent of goatse or tubgirl? Maybe something simple that distinguishes compilers: i386-gcc-openbsd5.4 i386-clang-openbsd5.4 Or something more elaborate signifies the origin: Locally compiled: i386-srcbld-openbsd5.4 i386-portbld-openbsd5.4 Upstream binary releases: i386-dist-openbsd5.4 i386-package-openbsd5.4
Re: The unknown in i386-unknown-openbsd5.4
On Sat, 1 Feb 2014 00:52:31 + (UTC)
na...@mips.inka.de (Christian Weisgerber) wrote:
FreeBSD is more playful: It has ${ARCH}-portbld-freebsd
${OSREL} in its ports tree and ...
I wonder how the FreeBSD guys changed it without breaking every
gnu-configure script in existence.
It shows up in so many places, even my email headers:
X-Mailer:Sylpheed 3.2.0 (GTK+ 2.24.20; i386-unknown-openbsd5.4)
To the uninitiated masses, it might seem like the system was
sloppily configured or in some other way the admin was confused.
Re: The unknown in i386-unknown-openbsd5.4
On Sat, 01 Feb 2014 22:06:47 -0500 Ted Unangst t...@tedunangst.com wrote: Well, that's true. If the admin cares about the value in X-Mailer, the admin should configure a better value. Patching the various occurrences of this string might be more cumbersome than changing the way it's generated and used throughout the system, but I get your gist.
Re: The unknown in i386-unknown-openbsd5.4
On Sun, 02 Feb 2014 00:23:18 -0500 Brad Smith b...@comstyle.com wrote: The way it is generated can be changed very easily and contrary to the previous comment it doesn't break all autoconf scripts Will you share your technique? that use the triplet. But there is no purpose for doing so. OMG something I don't understand, must... fiddle... with. There's an aesthetic nicety that comes from having everything well organized and thoughtfully labeled. But I agree with you that there is no immediate functional gain.
Re: Remove default X rootweave
On Fri, 31 Jan 2014 17:47:59 +0100 Alessandro Gallo llgx...@gmail.com wrote: I'm trying to remove the default checkerboard background that is shipped with the OpenBSD version of X. During my research I stumbled across this: http://openbsd.7691.n7.nabble.com/X-Window-System-settings-for-better-user-ex perience-and-security-td187453.html Here a post from Matthieu Herrb suggests to add -br to /etc/X11/xdm/Xservers to get rid of it. I changed the file and now it looks like this: :0 local /usr/X11R6/bin/X -br :0 vt05 however after a reboot nothing changed. I can successfully set the background under the xdm login form by modifying /etc/X11/xdm/Xsetup_0, but the rootweave is still shown for a couple of seconds before whatever is present in Xsetup_0 is run. Have I done something wrong? I would also like to see a convenient, maintainable method to make this little tweak. It's weird that this topic seems to provoke the bully-boy brigade. [demime 1.01d removed an attachment of type application/pgp-signature]
The unknown in i386-unknown-openbsd5.4
I see the string i386-unknown-openbsd5.4 in various places throughout my system. What does the unknown part of this string refer to and is there a canonical way to set it to something more meaningful? Thanks!
Re: (5.4) System hangs during shutdown
On 12/20/2013 09:05 AM, Giancarlo Razzolini wrote: Em 19-12-2013 17:56, Adam Jensen escreveu: I've been using a KVM switch (USB keyboard and mouse) on a couple of machines recently and I noticed that when the Keyboard, Video, and Mouse connections are switched away from the OpenBSD machine, a USB disconnect is reported (as expected). When switched back, the keyboard and mouse are not reconnected (video is displayed, of course). Once the machine is in this state, I can continue to work with it through ssh but if the machine is shutdown -hp or halt -p it hangs during the Syncing disks... stage and stays there indefinitely (or until the power cable is pulled). The file-systems are not cleanly unmounted. This behavior occurs with an i386 machine and with an amd64 machine. It seems like it might be a serious issue if the USB software stack is preventing a disk sync. Do you have all patches on http://www.openbsd.org/errata54.html applied? Specifically, I had random issues until I've applied this one: http://ftp.openbsd.org/pub/OpenBSD/patches/5.4/common/003_vnode.patch Also, try enabling the ddb.panic sysctl flag, it might help debugging the issue. A dmesg would help too. I rebuilt the machines recently and I have not been able to reproduce the system hang during shutdown. The USB devices still don't reconnect after being disconnected but both machines have been powering down without any problems. So on the one hand, huzzah! It works. On the other hand, wtf?
Re: (5.4-stable i386) framebuffer console with tmux - poor performance
On 12/17/2013 07:46 AM, Christian Weisgerber wrote: Adam Jensen han...@riseup.net wrote: I recently installed 5.4-stable on a machine with an intel graphics device so I can tinker with the framebuffer console. I notice that when running tmux on the console, output to the screen is very sluggish and text seems to scroll with a wave-like effect. The hardware acceleration for the framebuffer console on Intel graphics went through several stages; from your report I guess that 5.4-release/stable is at one where only scrolling of the whole screen is accelerated, but not that of a scrolling region. In -current I don't see a slowdown in scrolling regions any longer. This appears to have been silently (?) fixed. Are you sure? We might be talking about different issues. I haven't tinkered with 5.4-current so I can't verify whether or not the framebuffer console behavior I've experienced has changed. A simple experiment: At the framebuffer console, login; change to a directory with many files; measure the time of the directory listing. # cd /usr/src/sys/arch/i386/compile/GENERIC.MP # time ls [...lots of output...] 0m0.29s real 0m0.00s user 0m0.22s system Then start tmux in the simplest mode (one session, one window, no panes) and do it again. # tmux # cd /usr/src/sys/arch/i386/compile/GENERIC.MP # time ls [...lots of output...] 0m33.19s real 0m0.01s user 0m0.01s system If you do something like this on -current, what are your results?
Re: (5.4-stable i386) framebuffer console with tmux - poor performance
The poor tmux + framebuffer console behavior I have experienced occurs on an intel graphics (inteldrm) equipped machine that is *not* running X11 (or XDM). Josh, your IP is in a blacklist[1]. riseup.net blocked my direct response to you. [1]: http://www.spamcop.net/bl.shtml?198.252.153.129
Re: (5.4-stable i386) framebuffer console with tmux - poor performance
On 12/19/2013 02:18 PM, Adam Jensen wrote: Josh, your IP is in a blacklist[1]. riseup.net blocked my direct response to you. [1]: http://www.spamcop.net/bl.shtml?198.252.153.129 Correction, *my* email provider (riseup.net) is in the spamcop blacklist. Sorry for the noise.
(5.4) System hangs during shutdown
I've been using a KVM switch (USB keyboard and mouse) on a couple of machines recently and I noticed that when the Keyboard, Video, and Mouse connections are switched away from the OpenBSD machine, a USB disconnect is reported (as expected). When switched back, the keyboard and mouse are not reconnected (video is displayed, of course). Once the machine is in this state, I can continue to work with it through ssh but if the machine is shutdown -hp or halt -p it hangs during the Syncing disks... stage and stays there indefinitely (or until the power cable is pulled). The file-systems are not cleanly unmounted. This behavior occurs with an i386 machine and with an amd64 machine. It seems like it might be a serious issue if the USB software stack is preventing a disk sync.
Re: 5.4 amd64 - Poor disk performance with Smart Array 6404
On 12/17/2013 05:05 PM, Adam Jensen wrote: If this performance difference is simply due to OpenBSD's architecture and implementation methods - if it's a well engineered file-system - and maximum performance was a lower priority goal than robustness and reliability, then the lower performance isn't a big deal. However, if my system is poorly tuned and if there is a mismatch between the software and the hardware, that is something that needs serious consideration. Please don't hesitate with any advice, recommendations, quandaries or queries. In an attempt to understand the problem, I ran a similar set of tests on an i386 machine. While the file-system characteristics of OpenBSD and FreeBSD are different, I can comfortably assume that, in this case (i386), they are both utilizing the underlying hardware effectively. dd file-system characterization ### OpenBSD-5.4 i386 dd if=/dev/zero of=test bs=1k count=524288 536870912 bytes transferred in 4.412 secs (121674708 bytes/sec) ### FreeBSD-9.2 i386 dd if=/dev/zero of=test bs=1k count=524288 536870912 bytes transferred in 5.128465 secs (104684524 bytes/sec) bonnie++ file-system characterization ### OpenBSD-5.4 i386 --Sequential Output-- --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP 4G 291 100 122454 36 44439 14 461 99 126183 28 119.2 10 Latency 30223us 62654us 49224us 25027us 18430us3439ms --Sequential Create-- Random Create -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 1659 10 + +++ 3639 12 1741 11 + +++ 2569 12 Latency 23736us 51us 20350us 27543us 159us8780us ### FreeBSD-9.2 i386 --Sequential Output-- --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP 4G 197 99 124706 37 55326 19 416 99 130154 22 206.6 4 Latency 43718us 209ms 190ms 71722us 66112us 442ms --Sequential Create-- Random Create -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 28559 83 + +++ + +++ 15712 65 + +++ + +++ Latency 92535us 65us 220us 97489us 519us 38us However, whether or not OpenBSD is effectively functioning and utilizing the hardware on my Proliant with Smart Array machine is considerably less clear. Does anyone have an amd64 capable machine that does not use the ciss disk driver? (I do not). It might help in isolating the area of the problem to perform similar file-system characterizations with both OpenBSD and FreeBSD on such a machine. The performance problem that I noticed might be an OpenBSD-amd64 issue, or it might be an OpenBSD-ciss issue, or it might be an issue with my particular hardware. It would be interesting to know which is the case.
Re: 5.4 amd64 - Poor disk performance with Smart Array 6404
On 12/18/2013 07:38 PM, Chris Cappuccio wrote:
What if you try larger block sizes? like bs=1m ?
Do you mean bs=1m for the dd tests rather than anything concerning the
file-system (newfs) or RAID configuration?
{if dd} It would take some time to get precise data along those lines (I
haven't been dual-booting my machines) but, in the beginning of this
project I did tinker with various values for the dd tests. I don't think
it sheds any new light on the issue - On the Proliant machine, FreeBSD
file-system performance is around 150% of the OpenBSD file-system
performance. However, on my i386 machine, they are *much* more closely
matched.
If you [or anyone] have[/has] an idea, I will happily perform particular
experiments and collect the data for your analysis.
Re: 5.4 amd64 - Poor disk performance with Smart Array 6404
On 12/11/2013 10:27 AM, Jan Lambertz wrote: I found dd to be a very bad/misleading tool for this case. Problems are caches in different layers of the system, filesystem behaviour, sector sizing of drives and arrays, kernel configurations, input data loading, real world scenarios and driver implementation. I had same issues on centos. Not perfect but a lot better for my purpose is bonnie++. Even with bonnie++ i would not dare to say that same tests on same hardware with centos and openbsd will show the real differences in performance. Maybe that might help to get more comparable results I installed new batteries for the RAM cache on my hardware RAID controller (HP Smart Array 6404) yesterday and, following Jan's recommendation, I ran some file-system performance tests with bonnie++. Before getting to the bonnie++ test results, for comparison to earlier emails in this thread, this is how dd performs with the RAID controller's write-cache enabled: ## OpenBSD 5.4 GENERIC.MP amd64 (two-disk RAID0) hanzer:/tmp:34$ dd if=/dev/zero of=test bs=1k count=524288 536870912 bytes transferred in 5.922 secs (90647246 bytes/sec) ## FreeBSD 9.2-RELEASE amd64 (two-disk RAID0) hanzer@colossus:/tmp % dd if=/dev/zero of=test bs=1k count=524288 536870912 bytes transferred in 3.765968 secs (142558549 bytes/sec) The OpenBSD performance actually decreased, significantly. I ran the default bonnie++ test suite on a single disk (no RAID) then again on a two-disk RAID0 for each, OpenBSD and FreeBSD. I ran these test for various partition sizes. 32G is presented here for simplicity. It's a bit cluttered; hopefully, it doesn't get mangled in transport. --- ### No RAID (single disk, 32GB partition) ## OpenBSD 5.4 GENERIC.MP amd64 --Sequential Output-- --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP 16G 281 100 50412 24 8966 5 331 99 9020 3 162.1 26 Latency 30337us1384ms 179ms 38470us 34736us 222ms --Sequential Create-- Random Create -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 2349 17 + +++ 5068 17 2640 15 + +++ 5044 19 Latency 15962us 169us 360us8410us 190us 396us ## FreeBSD 9.2-RELEASE amd64 --Sequential Output-- --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP 16G 326 99 70558 18 11927 10 627 99 45458 5 339.3 10 Latency 32462us 894ms3812ms 18257us 238ms 293ms --Sequential Create-- Random Create -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 28296 69 + +++ + +++ 28454 82 + +++ + +++ Latency 105ms 149us 177us 71759us 167us 190us --- ### Two-disk RAID0 (32GB partition) ## OpenBSD 5.4 GENERIC.MP amd64 --Sequential Output-- --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP 16G 285 99 88245 40 9013 4 360 99 11377 4 185.9 29 Latency 37473us 460ms 157ms 34602us 29774us 214ms --Sequential Create-- Random Create -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 2465 15 + +++ 5106 19 2663 15 + +++ 4957 20 Latency 18823us 190us 360us8056us 190us 386us ## FreeBSD 9.2-RELEASE amd64 --Sequential Output-- --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP 16G 320 99 121412 31 13937 11 625 99 61133 7 486.9 15 Latency 32956us 341ms2104ms 18049us 399ms 266ms --Sequential Create-- Random Create -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 32225 85 + +++ + +++ 24767 87 + +++ + +++ Latency 71852us 193us 195us 72355us 187us 232us --- I am *very* concerned that something might be malformed in OpenBSD or that there is a configuration mismatch between my hardware and the default OpenBSD file-system. If the later is the case, hopefully all
Re: (5.4-i386) framebuffer console
On 12/15/2013 08:16 PM, Adam Jensen wrote: For the sake of others who might also be confused by this, the framebuffer console is probably configured and *on by default* when 5.4-release (or -stable or -current) is installed on machine with an appropriate *intel* graphics device. I say probably because I haven't verified this on an intel graphics equipped machine. Machines without an appropriate graphics device won't/can't have a framebuffer console (yet). If anyone has knowledge of how the framebuffer console is configured and controlled, a short tutorial would be grand! I now have 5.4-stable running on a machine with an intel graphics device and the framebuffer console is indeed on by default. [dmesg]: http://pastebin.com/raw.php?i=eKgZzNa8 When the monitor is connected directly to the machine - rather than the KVM switch - the machine boots with 1600x1200 resolution and there is plenty of text on the screen. At this resolution the text size is almost perfect for me but the default font is a bit thick, jagged, and overly stylized for my taste. Has anyone figured out how to configure the framebuffer console?
(5.4-stable i386) framebuffer console with tmux - poor performance
I recently installed 5.4-stable on a machine with an intel graphics device so I can tinker with the framebuffer console. [dmesg]: http://pastebin.com/raw.php?i=eKgZzNa8 I notice that when running tmux on the console, output to the screen is very sluggish and text seems to scroll with a wave-like effect. I built the kernel from source a few times to collect some rough data that might demonstrate the extent of the performance problem. From /usr/src/sys/arch/i386/compile/GENERIC.MP # framebuffer console time make -j 4 4m43.97s real 8m20.15s user 0m53.01s system # framebuffer console with tmux time make -j 4 22m53.03s real 8m22.85s user11m3.58s system # ssh from remote time make -j 4 4m37.65s real 8m16.88s user 0m45.16s system # ssh from remote with tmux on local time make -j 4 4m40.15s real 8m16.46s user 0m45.28s system
Re: (5.4-i386) framebuffer console
On 12/14/2013 04:46 PM, Gabriel Guzman wrote: On 12/14, Adam Jensen wrote: Did you get a framebuffer (no X11) console working with a decent resolution font and [much] more than 25 lines of 80 characters? If so, how did you do it - what's your recipe? just boot the machine (: no tweaking required. I guess if it's not working for you, then something is wrong, since I didn't have to do anything to get it working on my end. I haven't tried to adjust the framebuffer settings, or change the font as the default is fine for me. For the sake of others who might also be confused by this, the framebuffer console is probably configured and *on by default* when 5.4-release (or -stable or -current) is installed on machine with an appropriate *intel* graphics device. I say probably because I haven't verified this on an intel graphics equipped machine. Machines without an appropriate graphics device won't/can't have a framebuffer console (yet). Apparently, a framebuffer console is configured and *on by default* when 5.4-current is installed on machine with an appropriate *radeon* graphics device. I upgraded a radeon equipped machine to 5.4-current this evening and got to see the framebuffer console in action, briefly (the kernel panicked during boot). The console text is still quite a bit larger than I would like. If anyone has knowledge of how the framebuffer console is configured and controlled, a short tutorial would be grand!
Re: PgUp and PgDown on a Serial Console?
On 12/15/2013 07:43 AM, Evan Root wrote: Hi list, Does anybody know how to scroll back in a serial line console? I have a serial line connected to my box and I'm on the ftp site at the ftp client's command prompt wondering if anybody else has solved the problem of 1) not having a pager 2) trying to look at too many files that scroll off the screen and 3)using a VT100 or whatever with it's measly 80x24 Could you use tmux? http://www.openbsd.org/faq/faq7.html#tmux
Re: PgUp and PgDown on a Serial Console?
On 12/15/2013 09:14 PM, Adam Jensen wrote: On 12/15/2013 07:43 AM, Evan Root wrote: Hi list, Does anybody know how to scroll back in a serial line console? I have a serial line connected to my box and I'm on the ftp site at the ftp client's command prompt wondering if anybody else has solved the problem of 1) not having a pager 2) trying to look at too many files that scroll off the screen and 3)using a VT100 or whatever with it's measly 80x24 Could you use tmux? http://www.openbsd.org/faq/faq7.html#tmux If you want to try tmux, you might want a .tmux.conf file in your home directory with a line that sets the scrollback buffer size. For example, if you want 6000 lines of scrollback rather than the default 2000 lines, put this line in your .tmux.conf file: set-option -g history-limit 6000 After starting tmux and accessing the ftp sight, you can scroll with Ctrl-b followed by Page-Up, Page-Down.
Re: (5.4-i386) framebuffer console
On 12/15/2013 08:16 PM, Adam Jensen wrote: On 12/14/2013 04:46 PM, Gabriel Guzman wrote: On 12/14, Adam Jensen wrote: Did you get a framebuffer (no X11) console working with a decent resolution font and [much] more than 25 lines of 80 characters? If so, how did you do it - what's your recipe? just boot the machine (: no tweaking required. I guess if it's not working for you, then something is wrong, since I didn't have to do anything to get it working on my end. I haven't tried to adjust the framebuffer settings, or change the font as the default is fine for me. For the sake of others who might also be confused by this, the framebuffer console is probably configured and *on by default* when 5.4-release (or -stable or -current) is installed on machine with an appropriate *intel* graphics device. I say probably because I haven't verified this on an intel graphics equipped machine. Machines without an appropriate graphics device won't/can't have a framebuffer console (yet). Apparently, a framebuffer console is configured and *on by default* when 5.4-current is installed on machine with an appropriate *radeon* graphics device. I upgraded a radeon equipped machine to 5.4-current this evening and got to see the framebuffer console in action, briefly (the kernel panicked during boot). The console text is still quite a bit larger than I would like. If anyone has knowledge of how the framebuffer console is configured and controlled, a short tutorial would be grand! Here is a dmesg for the machine that panicked with today's pull build of 5.4-current. 5.4-release was reinstalled to get the dmesg. [dmesg]: http://pastebin.com/raw.php?i=PtQdaE5R
Re: (5.4-i386) framebuffer console
On 12/14/2013 01:36 AM, Philip Guenther wrote: On Fri, Dec 13, 2013 at 9:09 PM, Adam Jensen han...@riseup.net wrote: I noticed on [The OpenBSD 5.4 Release](http://www.openbsd.org/54.html) wsdisplay(4) now attaches to inteldrm(4) and provides a framebuffer console. drm supports the radeon driver and I have an old Thinkpad T60 with: vga1 at pci1 dev 0 function 0 ATI Radeon Mobility X1300 M52-64 rev 0x00 radeondrm0 at vga1: apic 1 int 16 Cool. So I guess setting up a framebuffer console at 1024x768 What does this *mean*? For example, how do you plan to draw in this 1024x768 framebuffer? A framebuffer console, as its name implies, is a text console running on top of the framebuffer device. It has the functionality of any standard text console driver, such as the VGA console, with added features that can be attributed to the graphical nature of the framebuffer device. It probably allows high resolution text, varying font types, multi-colored fonts, blending, aliasing, and any other feature made available by the underlying graphics card. It looks like it's a very new feature in OpenBSD and I really have little idea (at the moment) of what's possible/available. If anyone is familiar the framebuffer console and how to configure it and manipulate it, a little tutorial will be much appreciated!
Re: (5.4-i386) framebuffer console
On 12/14/2013 12:09 AM, Adam Jensen wrote: I noticed on [The OpenBSD 5.4 Release](http://www.openbsd.org/54.html) wsdisplay(4) now attaches to inteldrm(4) and provides a framebuffer console. drm supports the radeon driver and I have an old Thinkpad T60 with: vga1 at pci1 dev 0 function 0 ATI Radeon Mobility X1300 M52-64 rev 0x00 radeondrm0 at vga1: apic 1 int 16 After closer inspection, wsdisplay attaches to inteldrm specifically, not just generic drm. So I guess radeondrm isn't suitable for a framebuffer console. Luckily, I have a machine with the Intel 945G Chipset that I can re-task and dedicate to OpenBSD tinkering. Game on.
Re: (5.4-i386) framebuffer console
On 12/14/2013 02:57 PM, Gabriel Guzman wrote: wsdisplay0 at radeondrm0 mux 1: console (std, vt100 emulation), using wskbd0 Did you get a framebuffer (no X11) console working with a decent resolution font and [much] more than 25 lines of 80 characters? If so, how did you do it - what's your recipe?
(5.4-i386) framebuffer console
I noticed on [The OpenBSD 5.4 Release](http://www.openbsd.org/54.html) wsdisplay(4) now attaches to inteldrm(4) and provides a framebuffer console. drm supports the radeon driver and I have an old Thinkpad T60 with: vga1 at pci1 dev 0 function 0 ATI Radeon Mobility X1300 M52-64 rev 0x00 radeondrm0 at vga1: apic 1 int 16 Cool. So I guess setting up a framebuffer console at 1024x768 might go something like this: wsfontload clueless wsconscfg -dF 5 wsconscfg -f /dev/drm0 -e vt100 -t hmm 5 Yeah, this needs a little work. Has anyone managed to pull this off?
Re: 5.4 amd64 - Poor disk performance with Smart Array 6404
On 12/11/2013 10:27 AM, Jan Lambertz wrote: I found dd to be a very bad/misleading tool for this case. Problems are caches in different layers of the system, filesystem behaviour, sector sizing of drives and arrays, kernel configurations, input data loading, real world scenarios and driver implementation. I had same issues on centos. Not perfect but a lot better for my purpose is bonnie++. Even with bonnie++ i would not dare to say that same tests on same hardware with centos and openbsd will show the real differences in performance. Maybe that might help to get more comparable results Agreed. dd was a quick and dirty way to get some numbers after noticing very unusual system performance with OpenBSD. I might have gotten a little carried away with it. However, in this case I do think the numbers generally correlate to my impression of overall disk performance for this machine when running OpenBSD and FreeBSD. For example, when unpacking the ports tree or compiling a kernel, FreeBSD seems to drive the disks harder than OpenBSD (indicated by the drive activity lights, drive noise, and the output scrolling across the screen). Of course, this is hardly an objective metric and [for me] a ~15% disk I/O performance difference is not terribly important. It is far more important [to me] to have an elegant coherent reliable system with clean source code and good documentation. If the underlying system is cobbled together with zip-ties, duct-tape, and hot-rod hacks, it's not something I could trust and I wouldn't invest too much in it. If the zombie-apocalypse overruns the remnants of human society, it's the OpenBSD source and documentation I want on my machines. ;)
(5.4-amd64) Broadcom BCM95821 Crypto Accelerator
I'm thinking of getting a Broadcom PCI-X crypto accelerator card for my Proliant ML370-G4. (I found one for $20). The number on the chip is BCM5821A1KTB. The ubsec driver man page seems to suggest that this chip will accelerate DES, Triple-DES, MD5-HMAC, and SHA1-HMAC operations for ipsec(4) and crypto(4). Unfortunately, I don't think this particular chip will accelerate AES-CBC. Will anyone suggest any before and after performance tests that I might do to evaluate this card? Also, which encryption algorithms does the softraid CRYPTO discipline support? I didn't find that information in the man pages. It might be interesting to see if the Broadcom card will enhance encrypted volume disk performance.
Re: (5.4-amd64) Broadcom BCM95821 Crypto Accelerator
On 12/11/2013 10:09 PM, Ted Unangst wrote: On Wed, Dec 11, 2013 at 21:21, Adam Jensen wrote: Will anyone suggest any before and after performance tests that I might do to evaluate this card? Also, which encryption algorithms does the softraid CRYPTO discipline support? I didn't find that information in the man pages. It might be interesting to see if the Broadcom card will enhance encrypted volume disk performance. Honestly, I'd save your money. You might be right. I can't find any technical specifications for the card but the BCM5821 processor product brief says it has a 64-bit 33/66 MHz PCI 2.2 interface. The card structurally appears to be PCI-X. I guess it's probably a 64-bit 66-MHz PCI-X card. I think this would cause the entire PCI-X bus to drop to 66MHz. That's something I cannot abide. Bummer.
Re: 5.4 amd64 - Poor disk performance with Smart Array 6404
On 12/09/2013 08:51 PM, Steve Shockley wrote: On 12/9/2013 7:24 PM, Adam Jensen wrote: Disk performance is *very* bad. For example: Shot in the dark, but maybe try upgrading the 6404 firmware from 2.34 to 2.84, there are a variety of fixes that possibly could have been worked around by the other OS' drivers. Nice call, Steve! I upgraded the Smart Array 6404 firmware to version 2.84 and all seems well now. I do see a curious difference in performance when writing to the /home partition verses writing to the /tmp partition: OpenBSD5.4-amd64 FW-v2.84 Filesystem SizeUsed Avail Capacity Mounted on /dev/sd0o 59.0G 30.0K 56.1G 0%/home dd if=/dev/zero of=test bs=1k count=524288 536870912 bytes transferred in 4.929 secs (108916550 bytes/sec) Filesystem SizeUsed Avail Capacity Mounted on /dev/sd0e 7.9G297M7.2G 4%/tmp dd if=/dev/zero of=test bs=1k count=524288 536870912 bytes transferred in 4.098 secs (130989620 bytes/sec) It might be interesting to explore this and maybe think about file system tuning. The FreeBSD performance is somehow still a little better. FreeBSD9.2-amd64 FW-v2.84 dd if=/dev/zero of=test bs=1k count=524288 536870912 bytes transferred in 3.733867 secs (143784149 bytes/sec) This is with the default partitioning scheme (boot and swap partitions, and everything else in one big partition). Another important point that I forgot to mention in the original post of this thread is that the write cache is currently disable on the RAID controller card. The machine gives this POST Message during startup: 1794 - Slot 2 Drive Array - Array Accelerator Battery Charge Low Array Accelerator Posted-Write Cache is temporarily disabled. Array Accelerator batteries have failed to charge and should be replaced. I've mail-ordered two replacement battery packs; they should be here next week. It will be interesting to see how an enabled 192MB write cache will affect performance.
Re: 5.4 amd64 - Poor disk performance with Smart Array 6404
This might not be terribly relevant but just in case, for posterity, the ML370 G4 system messages (dmesg) with both versions of the Smart Array 6404 firmware are here: OpenBSD5.4-amd64 [v2.34]: http://pastebin.com/Sxs801ef [v2.84]: http://pastebin.com/RGUJ5pcS FreeBSD9.2-amd64 [v2.34]: http://pastebin.com/xxphWLr2 [v2.84]: http://pastebin.com/zcxRPz4Y diff v2.34 v2.84 OpenBSD5.4-amd64 sd0 at scsibus0 targ 0 lun 0: HP, LOGICAL VOLUME, 2.34 SCSI0 0/direct fixed --- sd0 at scsibus0 targ 0 lun 0: HP, LOGICAL VOLUME, 2.84 SCSI2 0/direct fixed FreeBSD9.2-amd64 da0: COMPAQ RAID 0 OK Fixed Direct Access SCSI-0 device --- da0: COMPAQ RAID 0 OK Fixed Direct Access SCSI-4 device
5.4 amd64 - Poor disk performance with Smart Array 6404
I recently (last night) installed OpenBSD-5.4-amd64 on an HP-Proliant ML370-G4 that has a Smart Array 6404 controller card in a 64-bit, 133-MHz PCI-X slot. It has two Ultra320 SCSI channels and 192MB of RAM cache. One SCSI channel is connected to two 146GB U320 10kRPM drives which are configured as a RAID0 array. The Smart Array card presents the RAID0 as one SCSI device: /dev/sd0. [dmesg]: http://pastebin.com/Sxs801ef [pcidump]: http://pastebin.com/P5Zn1xM4 [sysctl]: http://pastebin.com/kmXeMZ02 [acpidump]: http://pastebin.com/xufZXdha acpi.headers only Disk performance is *very* bad. For example: dd if=/dev/zero of=test bs=1k count=32768 32768+0 records in 32768+0 records out 33554432 bytes transferred in 6.325 secs (5304659 bytes/sec) I tinkered with FreeBSD9.2 and CentOS6.4 on this hardware and they both transfer about 300M to 400M bytes/sec with that command. Large transfers (GB) write about 80M to 100M bytes/sec (if I remember correctly). I am preparing to recompile the system to 5.4-stable so there is an opportunity to make some tweaks to the default kernel configuration (maybe the SCSIDEBUG option) but I am very open to suggestions on how to proceed. I plan to add four more 146GB U320 10kRPM drives, place them on the second Ultra320 SCSI channel, and configure them as a RAID5 array. I intend to run OpenBSD on this machine for the foreseeable future so getting the RAID hardware configured for maximum utilization, performance, and reliability is of utmost importance. Any RAID hardware gurus willing to point me in the right direction will be much appreciated. Actually, *any* suggestions could potentially be useful. I'm rather stuck at the moment.
