Good thing
Good thing OpenBSD didn't go down the multiple versions path. $ au aucat autoheader-2.59 automake-1.11 autoscan-2.63 audioctlautoheader-2.61 automake-1.14 autoscan-2.65 aumix autoheader-2.63 automake-1.9 autoscan-2.67 authpf autoheader-2.65 autopoint autoscan-2.68 authpf-noip autoheader-2.67 autoreconf autoscan-2.69 autoconfautoheader-2.68 autoreconf-2.13 autoupdate autoconf-2.13 autoheader-2.69 autoreconf-2.52 autoupdate-2.13 autoconf-2.52 autoloadautoreconf-2.59 autoupdate-2.52 autoconf-2.59 autom4teautoreconf-2.61 autoupdate-2.59 autoconf-2.61 autom4te-2.59 autoreconf-2.63 autoupdate-2.61 autoconf-2.63 autom4te-2.61 autoreconf-2.65 autoupdate-2.63 autoconf-2.65 autom4te-2.63 autoreconf-2.67 autoupdate-2.65 autoconf-2.67 autom4te-2.65 autoreconf-2.68 autoupdate-2.67 autoconf-2.68 autom4te-2.67 autoreconf-2.69 autoupdate-2.68 autoconf-2.69 autom4te-2.68 autoscan-2.13 autoupdate-2.69 autoheader autom4te-2.69 autoscan-2.52 autoheader-2.13 automakeautoscan-2.59 autoheader-2.52 automake-1.10 autoscan-2.61 -- This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender.
Re: Good thing
On 08/11/14 09:04, Brad Smith wrote: On 11/08/14 3:02 AM, Gustav Fransson Nyvell wrote: Good thing OpenBSD didn't go down the multiple versions path. The point of your sarcastic post is? If I explain, will you ask what the point of my explanation is? You're stuck in an eternal loop. -- This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender.
Re: Good thing
On 08/11/14 09:10, Brad Smith wrote: On 11/08/14 3:10 AM, Gustav Fransson Nyvell wrote: On 08/11/14 09:04, Brad Smith wrote: On 11/08/14 3:02 AM, Gustav Fransson Nyvell wrote: Good thing OpenBSD didn't go down the multiple versions path. The point of your sarcastic post is? If I explain, will you ask what the point of my explanation is? You're stuck in an eternal loop. So I'll take it you're just trying to make yourself look like a fool. Okay. Well, what I mean is, you are hypocrites. -- This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender.
Re: Good thing
On 08/11/14 09:13, Brad Smith wrote: On 11/08/14 3:16 AM, Gustav Fransson Nyvell wrote: On 08/11/14 09:10, Brad Smith wrote: On 11/08/14 3:10 AM, Gustav Fransson Nyvell wrote: On 08/11/14 09:04, Brad Smith wrote: On 11/08/14 3:02 AM, Gustav Fransson Nyvell wrote: Good thing OpenBSD didn't go down the multiple versions path. The point of your sarcastic post is? If I explain, will you ask what the point of my explanation is? You're stuck in an eternal loop. So I'll take it you're just trying to make yourself look like a fool. Okay. Well, what I mean is, you are hypocrites. This isn't a venting list for your retarded bullshit. What is bullshit? -- This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender.
Re: Good thing
On 08/11/14 09:22, Peter N. M. Hansteen wrote: On Mon, Aug 11, 2014 at 09:02:29AM +0200, Gustav Fransson Nyvell wrote: Good thing OpenBSD didn't go down the multiple versions path. does the word 'dependencies' ring a bell? - P Oh, I thought you had to keep all programs up to date on OpenBSD because that's the OpenBSD way? -- This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender.
Re: Good thing
On 08/11/14 11:49, Alexandre Ratchov wrote: On Mon, Aug 11, 2014 at 09:02:29AM +0200, Gustav Fransson Nyvell wrote: Good thing OpenBSD didn't go down the multiple versions path. $ au aucat autoheader-2.59 automake-1.11 autoscan-2.63 audioctlautoheader-2.61 automake-1.14 autoscan-2.65 [...] since you seem to dislike this, awaiting your diff to fix it. Talk is cheap and wastes other people's time. There's no guarantee a patch would be accepted. -- This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender.
Pre-fetching and ksh
Hi, Does ksh pre-load the programs that are being piped? Like pre-fetch in a CPU pipeline. //Gustav -- This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender.
Re: Pre-fetching and ksh
On 08/10/14 13:45, Alexander Hall wrote: On August 10, 2014 12:20:24 PM CEST, Gustav Fransson Nyvell gus...@nyvell.se wrote: Hi, Does ksh pre-load the programs that are being piped? Like pre-fetch in a CPU pipeline. Well, it doesn't wait for one process to compete before it starts the next one. They are executed simultaneously and their stdin/stdout's are connected. This is not really an openbsd specific question. /Alexander //Gustav That, my friends, is what they call a Freudian slip. -- This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender.
Package installation
Hi, there, I wanted to run something by you, mkay. About package management. I wonder if this has been shouted at already. I remember from SunOS that packages are installed in a different manner than let's say Red Hat and of course OpenBSD. They install it in the form /pkgs/PROGRAM/VERSION, example /pkgs/gimp/1.0. GoboLinux does this. I think this has some advantages over installing /usr/local/bin/gimp1.1 and /usr/local/bin/gimp2.0. What do you think? What have you said? Ready to be shouted at; //Gustav -- This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender.
Re: Package installation
On 08/02/14 12:54, Marc Espie wrote: On Sat, Aug 02, 2014 at 12:26:06PM +0200, Gustav Fransson Nyvell wrote: Hi, there, I wanted to run something by you, mkay. About package management. I wonder if this has been shouted at already. I remember from SunOS that packages are installed in a different manner than let's say Red Hat and of course OpenBSD. They install it in the form /pkgs/PROGRAM/VERSION, example /pkgs/gimp/1.0. GoboLinux does this. I think this has some advantages over installing /usr/local/bin/gimp1.1 and /usr/local/bin/gimp2.0. What do you think? What have you said? Ready to be shouted at; This puts more strain on the file system actually, which is probably the main reason we don't do it. Also, there is generally a lot of churning to do to make the package self-contained. As far as policy goes, having stuff set up like that looks more flexible, but it is a fallacy. Instead of having the distribution solve issues concerning incompatible versions and updates, the toll falls instead on the individual sysadmin, to make sure things they have work together. It can lead to security nightmares, because it's so simple to have the newer version alongside the old version that sticky points of updating take much longer to resolve. It's a bit like having mitigation measures that you can turn on and off... if it's possible to turn these off, there's not enough incentive to actually fix issues. Likewise for packages. By making it somewhat LESS convenient to install several versions of the same piece of software, we make it more important to do timely updates. Also, we don't have the manpower to properly manage lots of distinct versions of the same software. So this kind of setup would be detrimental to actually testing stuff. I guess there could be both. But I think that if there's a security issue with one version of a software then there quite possibly are multiple ways of limiting the impact of that issue. Disallowing multiple versions to force people to upgrade is not really a good reason, from how I see it. Old software will always have more holes, because they're older and more well observed, but they have qualities, too, like speed. GIMP-1.0 is amazing on Lenovo X41 from 2005, but probably has bugs. Of course none of these systems will stop someone who wants to run version x of a software. Maybe something entirely different is needed? Okay, maybe I should complain about the status quo... thing is when packages install in /var, /usr, /etc and /opt they're so spread out it's hard to know what is what. This might be because I'm new but/and scripts can find orphan files in this structures, but you need the scripts for that. Having everything in /pkgs/PKG/VER would not cause this splatter. Programs without dependees (i.e. non-libs, non-utilprograms) could fit in this structure without any extra filesystem magic. Well, the grass is always greener. -- This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender.
Re: Package installation
On 08/02/14 13:13, Gustav Fransson Nyvell wrote: On 08/02/14 12:54, Marc Espie wrote: On Sat, Aug 02, 2014 at 12:26:06PM +0200, Gustav Fransson Nyvell wrote: Hi, there, I wanted to run something by you, mkay. About package management. I wonder if this has been shouted at already. I remember from SunOS that packages are installed in a different manner than let's say Red Hat and of course OpenBSD. They install it in the form /pkgs/PROGRAM/VERSION, example /pkgs/gimp/1.0. GoboLinux does this. I think this has some advantages over installing /usr/local/bin/gimp1.1 and /usr/local/bin/gimp2.0. What do you think? What have you said? Ready to be shouted at; This puts more strain on the file system actually, which is probably the main reason we don't do it. Also, there is generally a lot of churning to do to make the package self-contained. As far as policy goes, having stuff set up like that looks more flexible, but it is a fallacy. Instead of having the distribution solve issues concerning incompatible versions and updates, the toll falls instead on the individual sysadmin, to make sure things they have work together. It can lead to security nightmares, because it's so simple to have the newer version alongside the old version that sticky points of updating take much longer to resolve. It's a bit like having mitigation measures that you can turn on and off... if it's possible to turn these off, there's not enough incentive to actually fix issues. Likewise for packages. By making it somewhat LESS convenient to install several versions of the same piece of software, we make it more important to do timely updates. Also, we don't have the manpower to properly manage lots of distinct versions of the same software. So this kind of setup would be detrimental to actually testing stuff. I guess there could be both. But I think that if there's a security issue with one version of a software then there quite possibly are multiple ways of limiting the impact of that issue. Disallowing multiple versions to force people to upgrade is not really a good reason, from how I see it. Old software will always have more holes, because they're older and more well observed, but they have qualities, too, like speed. GIMP-1.0 is amazing on Lenovo X41 from 2005, but probably has bugs. Of course none of these systems will stop someone who wants to run version x of a software. Maybe something entirely different is needed? Okay, maybe I should complain about the status quo... thing is when packages install in /var, /usr, /etc and /opt they're so spread out it's hard to know what is what. This might be because I'm new but/and scripts can find orphan files in this structures, but you need the scripts for that. Having everything in /pkgs/PKG/VER would not cause this splatter. Programs without dependees (i.e. non-libs, non-utilprograms) could fit in this structure without any extra filesystem magic. Well, the grass is always greener. BTW, you create multiple versions by your mere existence. There are lots of old versions laying around, but they can't be installed together right now. -- This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender.
Re: openbsd and badusb
On 08/01/14 23:01, Ted Unangst wrote: You may have heard about the badusb talk coming at blackhat. In theory, we should wait to watch the talk and see what it's actually about, but since some people can't wait that long, here's a few thoughts. (I'm a little surprised nobody has asked here already. I have some time free, thought I'd beat the rush. :)) The claims on the main page, https://srlabs.de/badusb/, are fairly reasonable if a little vague. Other claims I'm reading elsewhere appear a little overhyped. In order of increasing danger... 0. The final claim is that once infected, you'll always be infected because disinfection is nigh impossible. Meh. The same could be said of the firefox exploit of the week. It too can reprogram your bios or persist itself in any number of ways. 1. They're exploiting all manner of Windows specific autorun functionality to install or configure drivers. By default, OpenBSD will do just about nothing when a USB device is plugged in, so this is not a serious concern. 2. They have created a rogue keyboard device which will type naughty commands. In theory, the same keyboard could type rm -rf ~ into an xterm. This is a tiny bit more challenging since it probably depends on your desktop environment and window manager, but presumably your attacker will know all that. So yeah, vulnerable. But at the same time, I could also train a monkey to type that command and strap it to your normal not backdoored keyboard. Beware the badmonkey attack, too. 3. A storage device may lie about the contents of a file. Sometimes it will say one thing (so it looks safe on this computer), sometimes it will say another (so it installs a backdoor on that computer). Don't install OpenBSD from media you don't control. Technically, signing the sets won't help since the backdoor installer might have a bogus key on it (or a bogus installer that doesn't check). You can always pxeboot and hope that the firmware in your ethernet card is more trustworthy. They don't appear to mention two other avenues of exploitation, which may be more practical. I refer specifically to OpenBSD, though there's no such limitation. First, the USB stack has a number of known races and other bugs, especially around attach/detach and error handling. If a rogue device attached and detached itself several times, it could likely corrupt the kernel heap. Game over. Second, any USB disk, even one with a normal firmware, can have an evil filesystem image on it. By this, I mean the metadata that the kernel reads is corrupt, not that it has naughty files. There have been crash reports when mounting corrupted (and even not corrupted) (e.g.) MSDOSFS disks. The kernel is a little too trusting that a filesystem is what it claims to be. There are probably exploitable vulns here, too. All that to basically say don't panic (that's the kernel's job). Fixing filesystem bugs is something we'll do, of course, but it's not a priority for me to sit down and start fuzzing Right Now. Same for miscellaneous bugs in the USB stack. This wouldn't be such a big problem if hardware manufacturers weren't so mysterious about their firmware and ways to install such firmware. I mean from the owner/operator/maintenance perspective. Maybe the EU should force them to help us... -- This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender.
Re: [Perl] Sys::Syslog add useless space with perror
On 07/14/14 22:42, Bertrand PROVOST wrote:
Hi,
I'm using syslog with perror flag in some perl script, and I recently
notice that there is an additional newline at the end of each message
on stderr output.
Would anyone know why someone added \n in the first place ?
#
# cat /tmp/syslog.pl
use Sys::Syslog;
openlog($0, 'cons,pid,perror', 'user');
syslog('info', 'first line');
syslog('info', 'second line');
closelog();
#
The bug:
# perl /tmp/syslog.pl
/tmp/syslog.pl[14219]: first line
/tmp/syslog.pl[14219]: second line
# tail -n 2 /var/log/all
Jul 14 16:28:49 bsd /tmp/syslog.pl[27039]: first line
Jul 14 16:28:49 bsd /tmp/syslog.pl[27039]: second line
#
With the fix
# perl /tmp/syslog.pl
/tmp/syslog.pl[5146]: first line
/tmp/syslog.pl[5146]: second line
# tail -n 2 /var/log/all
Jul 14 16:37:18 bsd /tmp/syslog.pl[5146]: first line
Jul 14 16:37:18 bsd /tmp/syslog.pl[5146]: second line
#
Fix:
--- /usr/src/gnu/usr.bin/perl/cpan/Sys-Syslog/Syslog.pm.origMon
Jul 14 13:33:49 2014
+++ /usr/libdata/perl5/amd64-openbsd/5.16.3/Sys/Syslog.pm Mon
Jul 14 13:50:05 2014
@@ -396,7 +396,7 @@
$mask =~ s/(?!%)((?:%%)*)%m/$1$error/g;
}
-$mask .= \n unless $mask =~ /\n$/;
+$mask .= \n if ( $mask !~ /\n$/ and $current_proto ne 'native');
$message = @_ ? sprintf($mask, @_) : $mask;
if ($current_proto eq 'native') {
Look at cvs log?
--
This e-mail is confidential and may not be shared with anyone other than
recipient(s) without written permission from sender.
About libmessage
msgrcv(2), msgsnd(2) does exactly this. They're even syscalls. Maybe not as toyable as a sqlite database backend but surely faster better etc. Does anyone use them? -- This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender.
Re: About libmessage
On 07/10/14 12:39, Otto Moerbeek wrote: On Thu, Jul 10, 2014 at 12:20:24PM +0200, Gustav Fransson Nyvell wrote: msgrcv(2), msgsnd(2) does exactly this. They're even syscalls. Maybe not as toyable as a sqlite database backend but surely faster better etc. Does anyone use them? -- This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender. the msg* api is cursed by it's SysV descend. But as the OP never mentioned what his requiremenst are (guaranteed delivery?, in-order?, duplicate avoidance?, hardware failure resistance?, multi-platform?, authenticated src and dst?), any comment is futile. -Otto Hi, Oh, let me begin by saying I have some connections in ATT, which seem to be behind msg*. Even though they might hate me at the moment. I think that libmessage as it works now is pretty much msg* 2.0 because it can handle any length queueid and length message. My requirements or target is one message sent, one message read. Order no guaranteed. Basically like your mailbox at home or whereever you live. You get an envelope, you can only open it once. Haha, okay, it doesn't evaporate, these messages do. You'll have to keep a copy. Guaranteed delivery is #1 priority, nothing can be lost... There's no authentication in libmessage but a lot in msg*. I'm kind of torn about this. Having open messaging is quite good and if you need secrecy - encrypt. Like the internet. Because it's a fail-safe. I'm sort of aiming for the business transaction market where you have something like Joe wants 2 beers and that message is sent to a queue and someone finds it and goes to get beers for Joe. You know the deal. It's what MQs do, except MQs usually suck, hard. Anyway, I'm not expecting wide adoption of libmessage, but I wanted to ask you, how do you handle something like /tmp which has 777 permissions. Isn't that extremely unsafe? Someone could just rm it and all hell would break loose. (I haven't run a shell service so this has never happened to me.) Why is it 777? Shouldn't someone look at this...? :) Off-topic: I might be dead soon, it's 32°C in my kitchen. Damn this Swedenland suddenly a hot summer appears. //Gustav -- This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender.
Re: libmessage (New crazy sh*t)
On 07/08/14 11:08, Henning Brauer wrote: * Gustav Fransson Nyvell gus...@nyvell.se [2014-07-06 03:22]: I made this thing because I wanted or need a way to message between processes that know nothing about each other, using a central name. that's usually called a named pipe. or an mmap'ed file. Without requiring any network. So, some basic message passing, across the OS. It's implemented using sqlite3 which in my case is not good, ok, I stop reading here. Using a fickle rocket launcher to light a candle. That might be the main reason why software today is so miserable. mmap seems very low-level and dangerous for brain dead use. I'm aiming for syslog-like use and accompanying slowness. I think using sqlite3 as a backend is overkill and it was the first thing I picked. Maybe tokyocabinet would be a better fit, it might be worse to setup and I'm guessing it's not in the kernel ATM. See what I want to add to the kernel is this easy to use style of messaging so that common programs can use it, immediately. Like syslog is easy. I think libmessage would be a good fit it just needs a better backend. I think this is sorely needed, as well. A lot of bug tracking becomes much easier - I have seen ktrace. It is much like ktrace, yet can be used for applications too. It's like an internal network for the kernel. I know that message queues are frowned upon yet they are very UNIX, remember JMS is from Java which is from Sun, which you know... created Solaris, SunOS? UNIX is supposed to be big and slow. I'm going to stop typing now due to high environment temperatures... AKA Summer... //Gustav -- This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender.
Re: issues with firefox
On 07/08/14 18:36, misc nick wrote: Firefox becomes non-responsive for a small amount of time when viewing large (wallpaper sized) jpg images. In OpenBSD 5.4 firefox would block for several seconds. In OpenBSD 5.5 the situation improved considerably but it's still not perfect. The lag persists for a very short but visible amount of time. This bug is specific to OpenBSD and not to the machine, as i have tested it across different machines. This issue does not appear with other BSDs or linux (without flash). Secondly, viewing html video (eg in youtube) continuously lags. The sound is perfect but every other video frame seems to stop for a second or two and then the video jumps to the correct frame. This makes streaming video playback virtually unwatchable. This bug is specific to OpenBSD again. I have tested this at different machines and the result are the same. Once again, this issue does not appear with other BSDs or linux (without flash). Those two problems are much less obvious in OpenBSD-current's firefox, but, especially the second, still exist. I just wanted to report these issues and not complain. It is obvious that there is improvement at every new release of OpenBSD. This is my experience too. //Gustav -- This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender.
Re: libmessage (New crazy sh*t)
On 07/08/14 23:36, Jean-Philippe Ouellet wrote: What you are trying is not new, but crazy and sh*t seem pretty spot on. Your description, not mine. There's even a wikipedia article dedicated to how dumb this is! From http://en.wikipedia.org/wiki/Database-as-IPC: In computer programming, Database-as-IPC is an anti-pattern where a database is used as the message queue for routine interprocess communication in a situation where a lightweight IPC mechanism such as sockets would be more suitable. Using a database for this kind of message passing is extremely inefficient compared to other IPC methods and often introduces serious long-term maintenance issues, but this method enjoys a measure of popularity because the database operations are more widely understood than 'proper' IPC mechanisms.[1] On Tue, Jul 08, 2014 at 06:59:57PM +0200, Gustav Fransson Nyvell wrote: mmap seems very low-level and dangerous ... I want to add to the kernel is this easy to use style of messaging so that common programs can use it, immediately. Right... mmap is low-level and dangerous, so lets add large arbitrary shit to the kernel instead! So like kdbus, except implemented in the worst way possible? Please stop. think libmessage would be a good fit it just needs a better backend. No, it needs to disappear, and this conversation needs to end. The system you are proposing is not at all the system you need, nor the system you'd want if you understood the problem better. I think this is sorely needed, as well. Some other people have agreed with you, which is why this problem has already been tackled (in ways MUCH better than you are proposing) by people who put actual thought into the design phase before writing the dozens of different messaging queue/bus systems out there. A lot of bug tracking becomes much easier - I have seen ktrace. It is much like ktrace, yet can be used for applications too. It's quite obvious that you have no idea what you're talking about. It's like an internal network for the kernel. First of all, this has nothing to do with networks. Second of all, this has nothing to do with the kernel. I know that message queues are frowned upon yet they are very UNIX, remember JMS is from Java which is from Sun, which you know... created Solaris, SunOS? UNIX is supposed to be big and slow. Good bye, troll. Did you write that WP article? Anyway, I don't know enough of how the kernel works to use it properly for this situation, though it's nice to see the list is working as expected. -- This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender.
Re: libmessage (New crazy sh*t)
On 07/06/14 14:39, Thomas Adam wrote: On 6 July 2014 02:20, Gustav Fransson Nyvell gus...@nyvell.se wrote: I made this thing because I wanted or need a way to message between processes that know nothing about each other, using a central name. Without requiring any network. So, some basic message passing, across the OS. It's implemented using sqlite3 which in my case is not good, because I originally wanted to track fopen/open, and I think there will be infinite recursion if any of my new functions are used in that context. So, I'm thinking about another backend for it. You didn't attach any code, thankfully. Have you ever read about imsg? This sounds exactly like what you want, rather than using this sqlite-based thing. -- Thomas Adam I heard about the iPhone? Thanks, I'll look it up. //Gustav -- This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender. Open to misc@openbsd.org.
Re: libmessage (New crazy sh*t)
On 07/06/14 14:58, Thomas Adam wrote: On 6 July 2014 13:54, Gustav Fransson Nyvell gus...@nyvell.se wrote: I heard about the iPhone? Thanks, I'll look it up. //Gustav No, not Apple, for goodness sake, man! See this: http://www.openbsd.org/cgi-bin/man.cgi?query=msgbuf_drain -- Thomas Adam Hi, Someone took a bit of the apple. But, hm. This imsg looks pretty much like what I've done, however, libmessage does not require any bounds checking whatsoever. It's way easier to use. I'm currently tracking accept(2) through it. All it needs is one line where accept is defined. However, not sure libmessage is very unixy, not in syntax at least. imsg wins there. :P I've made some updates so that the sending function forks inside so that there is practically no delay when it's used. Though, it does not fork in threads as that seems to disturb some programs (urxvtc specifically.) Of course, I guess libmessage maybe could use imsg as it's backend. :D Do you know where/how imsg stores it's data/messages? Before I have a look... I put the tarball up on my HTTP now. http://nyvell.se/db/libmessage.tar SHA256 (libmessage.tar) = 5e1073a258cd3f0970ecd7999215b2afe7cf4b253205b96b2a77a0c168814a9e If you're interested... //Gustav -- This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender.
Re: libmessage (New crazy sh*t)
On 07/06/14 14:58, Thomas Adam wrote: On 6 July 2014 13:54, Gustav Fransson Nyvell gus...@nyvell.se wrote: I heard about the iPhone? Thanks, I'll look it up. //Gustav No, not Apple, for goodness sake, man! See this: http://www.openbsd.org/cgi-bin/man.cgi?query=msgbuf_drain -- Thomas Adam Hm, seems like imsg only has one channel... that might be a problem because you might read other programs' messages and you'd have to shoot them back on the channel if you accidentally read them... might get inefficient... though probably not as inefficient as using sqlite of course. But if there's whole lot of messages flying around eh, well, it's pretty funny picture but it seems riddled with risk. I don't see a way of filtering or rejecting to get a message that you're looking at, in imsg. Of course, I'm looking for problems in imsg, now... sorry. -- This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender. misc@openbsd.org Exempt
Re: libmessage (New crazy sh*t)
On 07/06/14 15:20, Thomas Adam wrote: On 6 July 2014 14:09, Gustav Fransson Nyvell gus...@nyvell.se wrote: This imsg looks pretty much like what I've done, however, libmessage does not require any bounds checking whatsoever. It's way easier to use. I'm I think you meant to say does not require any error checking. ;) Don't get me wrong, I don't wish to sound discouraging, but this sort of thing is just an academic exercise at this point. Just use imsg. I see absolutely no benefit to what you're doing, and this whole backend thing with sqlite seem proposterous. Good luck, just don't let others use this. Ever. -- Thomas Adam Other way around, libmessage is very dangerous, but it will take any buffer. If they use it, it's their own d*mn fault. :D -- This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender. misc@openbsd.org Exempt
Re: libmessage (New crazy sh*t)
On 07/06/14 15:44, Eugene Yunak wrote: Can you even read? Can you please stay away from public mailing lists for sane people? On 6 July 2014 16:25, Gustav Fransson Nyvell gus...@nyvell.se mailto:gus...@nyvell.se wrote: On 07/06/14 15:20, Thomas Adam wrote: On 6 July 2014 14:09, Gustav Fransson Nyvell gus...@nyvell.se mailto:gus...@nyvell.se wrote: This imsg looks pretty much like what I've done, however, libmessage does not require any bounds checking whatsoever. It's way easier to use. I'm I think you meant to say does not require any error checking. ;) Don't get me wrong, I don't wish to sound discouraging, but this sort of thing is just an academic exercise at this point. Just use imsg. I see absolutely no benefit to what you're doing, and this whole backend thing with sqlite seem proposterous. Good luck, just don't let others use this. Ever. -- Thomas Adam Other way around, libmessage is very dangerous, but it will take any buffer. If they use it, it's their own d*mn fault. :D -- This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender. misc@openbsd.org mailto:misc@openbsd.org Exempt -- The best the little guy can do is what the little guy does right Please give me your home address. -- This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender.
libmessage (New crazy sh*t)
Hi there, I made this thing because I wanted or need a way to message between processes that know nothing about each other, using a central name. Without requiring any network. So, some basic message passing, across the OS. It's implemented using sqlite3 which in my case is not good, because I originally wanted to track fopen/open, and I think there will be infinite recursion if any of my new functions are used in that context. So, I'm thinking about another backend for it. Tell me what you think if you dare untar. (Did it attach properly?) I've made some nifty applications for/with it already. Such as a message reader that runs programs it finds in a list. It's handy... because... etc. I'm thinking maybe in the future the database could be located on a shared network device, or fs, like nfs. If sqlite3 continues on, that is. Could make for some funny applications, especially if optimized. Or connected with pf, for instance. Or added as a layer between ALL c-functions. Imagine getting to look at all activity going on in the system, by simple commands. Okay, maybe it isn't simple... well, try it... So. Please look at it. Good night... PS: When you're going to install this, put it in /usr/src/lib and tar xvf the filename and cd into libmessage and do make make install. So it's a lib from the kernel. (Well.) That should be it. Let me know if it breaks something or does not work. Typical compilation is gcc msg_app.c -lmessage -lsqlite3 -o msg_app. //Gustav -- This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender. Permission granted to share among misc@openbsd.org readers. [demime 1.01d removed an attachment of type application/octet-stream which had a name of libmessage.tar]
Re: does OpenMP work on 5.5/amd64?
On 07/04/14 21:37, Jonathan Thornburg wrote:
In message http://marc.info/?l=openbsd-miscm=140423832428907w=1,
I wrote:
| Has anyone gotten OpenMP to work on 5.5-{release,stable}/amd64?
|
| 'man gcc' and /usr/local/info/gcc.info both describe gcc support for
| OpenMP (the -fopenmp compiler flag), but I'm getting fatal errors
| (either missing compiler spec file or missing omp.h header file)
| trying to compile even the simplest hello, world OpenMP programs
| with gcc (either base /usr/bin/gcc or ports /usr/local/bin/gcc).
[[...]]
In messagehttp://marc.info/?l=openbsd-miscm=140423912429329w=1,
you replied, quoting my message and adding the single word
No.
Could you clarify which of the two different(-but-related) questions
I asked you were answering? Have you gotten OpenMP to work on OpenBSD?
If so, how?
thanks, ciao,
Hello there.
Well, I read from your e-mail that you did not compile it. However, I'm
sure it can be done if you just work at it. Though you're on the right
path, I would just continue if you can keep the focus and have the
resources, which I see that you have.
Good luck!
//Gustav
--
This e-mail is confidential and may not be shared with anyone other than
recipient(s) without written permission from sender. Open to misc@openbsd.org,
of course.
Re: What is the difference between these two SSHD configs?
On 07/01/14 18:18, Ez Egy wrote: #1 Match Group GROUPNAME, User *,!root #2 Match Group GROUPNAME User !root What is the difference between #1 and #2 in the SSHD_CONFIG? If someone could help me.. thanks in advance.. Two bytes. -- This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender.
Re: What is the difference between these two SSHD configs?
On 07/01/14 18:25, Ez Egy wrote: I wanted to mean regarding functionality, are they doing the exact 100% same? :O On Tue, Jul 1, 2014 at 6:21 PM, Gustav Fransson Nyvell gus...@nyvell.se mailto:gus...@nyvell.se wrote: On 07/01/14 18:18, Ez Egy wrote: #1 Match Group GROUPNAME, User *,!root #2 Match Group GROUPNAME User !root What is the difference between #1 and #2 in the SSHD_CONFIG? If someone could help me.. thanks in advance.. Two bytes. -- This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender. The source is open for a reason. -- This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender.
Re: does OpenMP work on 5.5/amd64?
On 07/01/14 19:40, Jonathan Thornburg wrote:
Has anyone gotten OpenMP to work on 5.5-{release,stable}/amd64?
'man gcc' and /usr/local/info/gcc.info both describe gcc support for
OpenMP (the -fopenmp compiler flag), but I'm getting fatal errors
(either missing compiler spec file or missing omp.h header file)
trying to compile even the simplest hello, world OpenMP programs
with gcc (either base /usr/bin/gcc or ports /usr/local/bin/gcc).
'locate omp.h' fails to find the header file anywhere, and
'man clang' doesn't mention OpenMP support at all.
I want to develop OpenMP programs on OpenBSD. Do I need to build my
own gcc to do so?
Script started on Tue Jul 1 10:21:34 2014
% uname -a
OpenBSD copper.astro.indiana.edu 5.5 GENERIC.MP#0 amd64
% cat hello.c
#include stdio.h
int main(void)
{
#pragma omp parallel
printf(Hello, world.\n);
return 0;
}
% cat mt-hello.c
#include stdio.h
#include omp.h
int main(void)
{
#pragma omp parallel
{
int id = omp_get_thread_num();
printf(hello(%d)\n, id);
printf(world(%d)\n, id);
}
return 0;
}
%
%
% /usr/bin/gcc --version
gcc (GCC) 4.2.1 20070719
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
% /usr/bin/gcc -fopenmp -o hello hello.c
gcc: libgomp.spec: No such file or directory
% /usr/bin/gcc -fopenmp -o mt-hello mt-hello.c
mt-hello.c:2:17: error: omp.h: No such file or directory
%
%
% /usr/local/bin/gcc --version
gcc (GCC) 4.8.2
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
% /usr/local/bin/gcc -fopenmp -o hello hello.c
gcc: error: libgomp.spec: No such file or directory
% /usr/local/bin/gcc -fopenmp -o mt-hello mt-hello.c
mt-hello.c:2:17: fatal error: omp.h: No such file or directory
#include omp.h
^
compilation terminated.
%
%
% /usr/local/bin/clang --version
clang version 3.3 (tags/RELEASE_33/final)
Target: amd64-unknown-openbsd5.5
Thread model: posix
% /usr/local/bin/clang -fopenmp -o hello hello.c
clang-3.3: warning: argument unused during compilation: '-fopenmp'
% ./hello
Hello, world.
% /usr/local/bin/clang -fopenmp -o mt-hello mt-hello.c
clang-3.3: warning: argument unused during compilation: '-fopenmp'
mt-hello.c:2:10: fatal error: 'omp.h' file not found
#include omp.h
^
1 error generated.
% exit
Script done on Tue Jul 1 10:23:46 2014
ciao,
No.
--
This e-mail is confidential and may not be shared with anyone other than
recipient(s) without written permission from sender.
Re: crowding out bsd using systemd?
On 06/29/14 13:09, bodie wrote: On 29.06.2014 12:40, Eric Furman wrote: My real helpful comments are that it violates every real concept of UNIX Do ONE thing and do it WELL It's because RedHat (and Oracle) doesn't care about Unix principles (or initial ideas of Linux). They are stating it quite clearly and yet people and communities can't see that. Especially RedHat does not care about Linux or Unix as such. It's company, they want to make profit and create form of vendor lock in. That's how sharks operate in that territory. Thinking that they will listen to any one be it some community leader or some big distribution is at least naive. Look at ArchLinux, Ubuntu, Fedora, OpenSuSe, Debian, Gentoo and others. It's either shut up and play with us or leave Linux game nowadays. And because most of the development is done anyway in RedHat and/or Oracle they either need to follow or dissapear. So here's that true freedom hidden in GPL. Following orders of one/two big corporations and that's it. BSD world had crash with corporate world in 90's in USL vs BSDi and BSD won, but seems like corporations found another way how to cripple Unix roots to its knees. Think about why Linus is so much in rage mood this year against various devs from RedHat and yet can do shit about them because he's no longer in control and he knows it. No wonder he choose to focus more on on-line Linux courses under Linuxfoundation (he will not have so much time for kernel during those for sure). Systemd does none of these things. On Sun, Jun 29, 2014, at 04:51 AM, Antoine Jacoutot wrote: https://uglyman.kremlin.cc/gitweb/gitweb.cgi?p=systemd-utl.git;a=blob;f=scripts/gen-gdbus-interfaces.sh;h=f827434d0211ea8765c075fdb2916386ffc16ecb;hb=HEAD btw. it's bashism in a posix shell suit? If that is all you were able to spot then move along :-) It's very pre-alpha WIP and many things will be modified. If you have real helpful comments to make, feel free to contact Ian, landry@ and myself. -- Antoine UNIX is very old. Some hang on to one or two principles like they're the word of god. For example, in this discussion, that one tool should do one thing and do it well. It kind of makes you blind. Look at the bigger picture. Isn't systemd doing one thing and doing it well? Sure, it's opaque, I guess. Do you miss configuring by file? I do, I think it's reliable. Maybe systemd needs a bit of KISS criticism, because it sure isn't looking simple. At the end of the day, all we need is a running system, we don't need... dbus. However, like I started this, the word of god gets in the way, there are a lot of convenient things going on in Linux (or Ubuntu, I used Ubuntu.) This is where you hate me but I like the kernel or system to use the entire computer for the task I am doing, but I am mainly a desktop user or non-server user, at least on the home laptop. When I compile, I want ALL resources working towards it. If I watch a movie, ALL resources towards it. The machine's focus should be on what I want to do. And... well, this is where UNIX gets in the way. I think we could develop UNIX, just look at Plan 9. There are some great ideas in there. Which have been implemented too. Everything as a file, is a very good idea. It's very simple. UNIX does not have this idea in it. But I think like Theo de Raadt wrote, I don't know what they are chasing about the corporations, Red Hat et al. It's not the finer points of computer discoveries they're after. Plan 9 isn't a huge commercial success, but it's fine. Well, just my two cents! -- This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender. Public domain through misc@
Re: crowding out bsd using systemd?
On 06/29/14 13:43, Antoine Jacoutot wrote: Why are people poluting our lists with systemd rants??? There is nothing to discuss since we do not want and will never have systemd. If you don't understand what the systemd-utl GSoC is about then move along. Gustav Fransson Nyvell gus...@nyvell.se wrote: On 06/29/14 13:09, bodie wrote: On 29.06.2014 12:40, Eric Furman wrote: My real helpful comments are that it violates every real concept of UNIX Do ONE thing and do it WELL It's because RedHat (and Oracle) doesn't care about Unix principles (or initial ideas of Linux). They are stating it quite clearly and yet people and communities can't see that. Especially RedHat does not care about Linux or Unix as such. It's company, they want to make profit and create form of vendor lock in. That's how sharks operate in that territory. Thinking that they will listen to any one be it some community leader or some big distribution is at least naive. Look at ArchLinux, Ubuntu, Fedora, OpenSuSe, Debian, Gentoo and others. It's either shut up and play with us or leave Linux game nowadays. And because most of the development is done anyway in RedHat and/or Oracle they either need to follow or dissapear. So here's that true freedom hidden in GPL. Following orders of one/two big corporations and that's it. BSD world had crash with corporate world in 90's in USL vs BSDi and BSD won, but seems like corporations found another way how to cripple Unix roots to its knees. Think about why Linus is so much in rage mood this year against various devs from RedHat and yet can do shit about them because he's no longer in control and he knows it. No wonder he choose to focus more on on-line Linux courses under Linuxfoundation (he will not have so much time for kernel during those for sure). Systemd does none of these things. On Sun, Jun 29, 2014, at 04:51 AM, Antoine Jacoutot wrote: https://uglyman.kremlin.cc/gitweb/gitweb.cgi?p=systemd-utl.git;a=blob;f=scripts/gen-gdbus-interfaces.sh;h=f827434d0211ea8765c075fdb2916386ffc16ecb;hb=HEAD btw. it's bashism in a posix shell suit? If that is all you were able to spot then move along :-) It's very pre-alpha WIP and many things will be modified. If you have real helpful comments to make, feel free to contact Ian, landry@ and myself. -- Antoine UNIX is very old. Some hang on to one or two principles like they're the word of god. For example, in this discussion, that one tool should do one thing and do it well. It kind of makes you blind. Look at the bigger picture. Isn't systemd doing one thing and doing it well? Sure, it's opaque, I guess. Do you miss configuring by file? I do, I think it's reliable. Maybe systemd needs a bit of KISS criticism, because it sure isn't looking simple. At the end of the day, all we need is a running system, we don't need... dbus. However, like I started this, the word of god gets in the way, there are a lot of convenient things going on in Linux (or Ubuntu, I used Ubuntu.) This is where you hate me but I like the kernel or system to use the entire computer for the task I am doing, but I am mainly a desktop user or non-server user, at least on the home laptop. When I compile, I want ALL resources working towards it. If I watch a movie, ALL resources towards it. The machine's focus should be on what I want to do. And... well, this is where UNIX gets in the way. I think we could develop UNIX, just look at Plan 9. There are some great ideas in there. Which have been implemented too. Everything as a file, is a very good idea. It's very simple. UNIX does not have this idea in it. But I think like Theo de Raadt wrote, I don't know what they are chasing about the corporations, Red Hat et al. It's not the finer points of computer discoveries they're after. Plan 9 isn't a huge commercial success, but it's fine. Well, just my two cents! -- This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender. Public domain through misc@ I'm not saying GET systemd. I thought this was a broad discussion. And I'm NOT ranting. -- This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender. Public domain thru misc@
Re: Thanks for ACPI
On 06/25/14 03:14, Theo de Raadt wrote: It's funny to me that NO power saving features work in Windows 8, nor 2 finger scrolling on the trackpad. It's a funny world, here's how, let me explain the road map for you: In 1 year, Windows will work worse on that particular laptop. In 2 years, it will be expired. In 4 years, it will barely work. That is a result of chasing new sales. In 1 year, OpenBSD will work better on that laptop. In 2 years, it will be work even better. In about 4 years, it will work as well, but the decline will start because our developers will move on. That is an aspect of minimal refinement, not chasing the curve. In 1 year, Linux might work better. In 2 years, it will not work well. But hey, don't take my word for me. Ask the net. They'll set me straight, and they'll set you straight. I don't know what they are chasing. Maybe it is the same as the first. Really, honestly, I don't have a clue what they are chasing. Wow, this is the kind of e-mail I want to read in the (well, sort of) morning. 3
System Hangs with Intel i7 3920XM
Hi, I found something about this before, something old, would like to hear if there's some update. Well, I've had 3 total freezes since I installed OpenBSD recently. This is on a laptop and I can't suspend by closing the screen even, that it will just black the screen. Everything is frozen, sound is stuck at repeat, fans are whizzing. And I'm running X11 and it's happened with just X11+Firefox and X11+Firefox+mplayer. It's not temperature; last time I'm sure it was around 65-68°C and it can handle 95°C for sustained time without hanging (hours of compiling firefox.) System was pretty idle, actually, this last time. I want to ask 1) Is there something I can do? 2) Is there some logging I can enable that will dump stuff useful for reading after a hang? 3) Is this a kernel driver/module/something problem or caused by an application? (Applications should be able to do this, right?) Thanks! Well, I'll go on to list specifics here. Intel 3920XM 2.9GHz Ivy Bridge with Intel HD Graphics 4000 GPU in the same chip. System has Optimus hardware GPU switching with an extra nVidia GeForce GTX 680M (unsupported, I know.) 32 GB RAM 120GB Intel SSD dmesg -- OpenBSD 5.5-current (GENERIC.MP) #4: Thu Jun 19 19:17:56 CEST 2014 gus...@uncouth.nyvell.se:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 34226692096 (32641MB) avail mem = 33306812416 (31763MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb420 (33 entries) bios0: vendor American Megatrends Inc. version 4.6.5 date 08/22/2012 bios0: CLEVO P15xEMx acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT ASF! MCFG HPET SSDT SSDT SSDT DMAR SSDT SSDT acpi0: wakeup devices P0P1(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) USB6(S3) USB7(S3) PXSX(S4) RP01(S3) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-3920XM CPU @ 2.90GHz, 2794.01 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-3920XM CPU @ 2.90GHz, 2793.66 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i7-3920XM CPU @ 2.90GHz, 2793.66 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i7-3920XM CPU @ 2.90GHz, 2793.66 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 cpu4 at mainbus0: apid 1 (application processor) cpu4: Intel(R) Core(TM) i7-3920XM CPU @ 2.90GHz, 2793.66 MHz cpu4: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu4: 256KB 64b/line 8-way L2 cache cpu4: smt 1, core 0, package 0 cpu5 at mainbus0: apid 3 (application processor) cpu5: Intel(R) Core(TM) i7-3920XM CPU @ 2.90GHz, 2793.66 MHz cpu5: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu5: 256KB
Re: System Hangs with Intel i7 3920XM
On 06/21/14 19:55, Dimitris Papastamos wrote: On Sat, Jun 21, 2014 at 07:35:22PM +0200, Gustav Fransson Nyvell wrote: I want to ask 1) Is there something I can do? 2) Is there some logging I can enable that will dump stuff useful for reading after a hang? 3) Is this a kernel driver/module/something problem or caused by an application? (Applications should be able to do this, right?) I am no expert but have you tried disabling nvidia from the bios and booting only with your intel graphics card? No, AFAIK, this can't be done sadly. I could possibly remove it physically but I rather not. does this happen without X? Unknown, not in my experience, I'm always in X. have you tried the bsd.sp kernel? No. -- This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender.
Re: System Hangs with Intel i7 3920XM
On 06/21/14 20:02, Dimitris Papastamos wrote: If you have any means of hooking up a serial cable (docking station?) you might be able to see the ddb prompt and go from there. Does the freeze happen instantly or does it slowly become unresponsive? For the latter you might have time to switch to a VT and wait for ddb. You can force a crash dump via 'boot dump' or 'boot crash'. Sorry, no docking station or serial port. I could get one but it does freeze instantly so. And I've never seen a ddb prompt on screen. -- This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender.
Re: Ethernet configuration problem
On 06/20/14 07:45, Thuban wrote: * Stuart Henderson s...@spacehopper.org le [20-06-2014 00:19:17 +]: On 2014-06-18, Thuban thu...@yeuxdelibad.net wrote: * Peter N. M. Hansteen pe...@bsdly.net le [18-06-2014 18:37:52 +0200]: On Wed, Jun 18, 2014 at 06:21:24PM +0200, Thuban wrote: jme0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 00:90:f5:bc:7b:5E groups egress media: Ethernet autoselect (none) status: no carrier inet6 fe80::290:f5ff:febc:7b56%jme0 prefixlen 64 scopeid 0x1 inet 192.168.1.70 netmask 0xff0 broadcast 192.168.1.255 Haha. Cable is plugged. I tried today to modify media to 10baseT, but the router's LED is still off and I can't connect. Try a different cable. If you get status: no carrier with a cable plugged in, the most likely culprit is the cable. I am currently using this cable on my debian and connexion works Are you saying here that the exact same hardware works with linux, but gets a 'no carrier' with OpenBSD and FreeBSD? Is it possible to try booting with Linux again (a live cd will do) and check link status? Exactly. On linux, I can use the ethernet correctly. The linux's ifconfig gives this : eth0 Link encap:Ethernet HWaddr 00:90:f5:bc:7b:56 inet adr:192.168.1.68 Bcast:192.168.1.255 Masque:255.255.255.0 adr inet6: 2001:41d0:fe34:de00:290:f5ff:febc:7b56/64 Scope:Global adr inet6: fe80::290:f5ff:febc:7b56/64 Scope:Lien UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:266 errors:0 dropped:0 overruns:0 frame:0 TX packets:263 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:1000 RX bytes:61935 (60.4 KiB) TX bytes:31036 (30.3 KiB) Interruption:44 Regards Given what vigdis said, I wonder:- - what speed is the switch port you're using - what speed does linux negotiate - what speed is your NIC supposed to support? 10/100 or also gigabit? I'm not sure how to give you the correct answers to theses questions. The speed is 100Mb/s. Following, the output of ethtool on the linux box : Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Supported pause frame use: No Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Advertised pause frame use: No Advertised auto-negotiation: Yes Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Link partner advertised pause frame use: Symmetric Link partner advertised auto-negotiation: Yes Speed: 100Mb/s Duplex: Full Port: MII PHYAD: 1 Transceiver: internal Auto-negotiation: on Supports Wake-on: pg Wake-on: g Current message level: 0x20c6 (8390) probe link rx_err tx_err hw Link detected: yes Do not hesitate to give me some advice to find more interesting informations. Regards, Hi, What speed is your switch? Can you give us the switch make and model and the NIC make and model? //Gustav -- This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender.
libssl 25?
Hi, Question 1) Yes, yes, I know I messed up. Any idea how I can fix this? $ sudo pkg_add -va f1spirit Update candidates: quirks-1.146 - quirks-1.146 (ok) |No change in quirks-1.146No pkgname in packing-list for py-gobject3-common-3.10.2 Can't install f1spirit-0.1615p0 because of libraries |library curl.24.3 not found | /usr/local/lib/libcurl.so.24.2 (curl-7.34.0p0): minor is too small |library ssl.25.0 not found | /usr/lib/libssl.so.20.0 (system): bad major | /usr/lib/libssl.so.24.1 (system): bad major ... $ uname -a OpenBSD uncouth.nyvell.se 5.5 GENERIC.MP#3 amd64 $ ls /usr/lib/libssl* /usr/lib/libssl.a /usr/lib/libssl.so.24.1 /usr/lib/libssl.so.20.0/usr/lib/libssl_p.a How do I install ssl.25.0? Running -current. Question 2) apm(8) only seems to get one stab at changing settings. Once is okay, I do apm -H or apm -C, but then I have to do /etc/rc.d/apmd restart to change it again. Not sure where to get debug data, it only logs speedstep activity... //Gustav -- This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender.
Re: libssl 25?
On 06/19/14 16:12, Nigel Taylor wrote: On 06/19/14 13:17, Gustav Fransson Nyvell wrote: Hi, Question 1) Yes, yes, I know I messed up. Any idea how I can fix this? $ sudo pkg_add -va f1spirit Update candidates: quirks-1.146 - quirks-1.146 (ok) |No change in quirks-1.146No pkgname in packing-list for py-gobject3-common-3.10.2 Can't install f1spirit-0.1615p0 because of libraries |library curl.24.3 not found | /usr/local/lib/libcurl.so.24.2 (curl-7.34.0p0): minor is too small |library ssl.25.0 not found | /usr/lib/libssl.so.20.0 (system): bad major | /usr/lib/libssl.so.24.1 (system): bad major ... $ uname -a OpenBSD uncouth.nyvell.se 5.5 GENERIC.MP#3 amd64 $ ls /usr/lib/libssl* /usr/lib/libssl.a /usr/lib/libssl.so.24.1 /usr/lib/libssl.so.20.0/usr/lib/libssl_p.a How do I install ssl.25.0? Running -current. /usr/lib/libssl is in the base so you go to an OpenBSD version that matches the packages. As running current that's an upgrade to a more recent snapshot. Question 2) apm(8) only seems to get one stab at changing settings. Once is okay, I do apm -H or apm -C, but then I have to do /etc/rc.d/apmd restart to change it again. Not sure where to get debug data, it only logs speedstep activity... //Gustav But I'm running -current. From CVS. Last update was 24h ago. It should be more recent than snapshots. Or very close. I've had this problem for a few days. -- This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender.
Re: libssl 25?
On 06/19/14 16:21, Henning Brauer wrote: This e-mail is confidential oh damn, I retract my answer then Haha. Sorry. misc@ is excluded! -- This e-mail is confidential and may not be shared with anyone other than recipient(s) without written permission from sender.
Re: Ethernet configuration problem
On 06/18/14 11:53, Thuban wrote: * Alexey Kurinnij alexey.kurin...@gmail.com le [18-06-2014 11:37:31 +0300]: Can you try to configure jme0 from installer in manual mode? And paste ifconfig output. I tried to configure jme0 from installer in manual mode too, but I still can't access to an internet connexion. Then, back to the shell, I copied ifconfig output : lo0 : flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 33144 groups:lo inet6::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet 127.0.0.1 netmask 0xff00 jme0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 00:90:f5:bc:7b:5E groups egress media: Ethernet autoselect (none) status: no carrier inet6 fe80::290:f5ff:febc:7b56%jme0 prefixlen 64 scopeid 0x1 inet 192.168.1.70 netmask 0xff0 broadcast 192.168.1.255 Any suggestion? Regards, Hello, Plug in the cable. //Gustav
Re: Very slow I/O under OpenBSD i386 on qemu-kvm from RHEL7rc
On 06/17/14 10:56, Mikolaj Kucharski wrote: On Mon, Jun 16, 2014 at 11:07:39PM +0100, Kevin Chadwick wrote: previously on this list Mikolaj Kucharski contributed: by disabling mpbios on OpenBSD and falling back to the old pic controller, in this case you I cannot find how to enable 'the old pic controller' in libvirt with qemu-kvm. Do you know by any chance how to enable it? I believe he means disabling mpbios at OpenBSD's boot or in boot.conf means KVM will automatically fall back. Virtual hosting companies like arpnetworks generally ask you to do this for OpenBSD. boot -c disable mpbios Ah, I got confused. Yes, I'm aware of this, as I've seen this on the list archives mentioned few times. I actually tested this, and I don't see any difference. See at my below tests: OpenBSD i386/virtio (default) [test12] # time dd if=/dev/zero of=/tmp/TEST bs=4096 count=1024x1024 1048576+0 records in 1048576+0 records out 4294967296 bytes transferred in 3635.270 secs (1181471 bytes/sec) 60m35.50s real 0m1.24s user54m15.15s system OpenBSD i386/virtio (disable mpbios) [test13] # time dd if=/dev/zero of=/tmp/TEST bs=4096 count=1024x1024 1048576+0 records in 1048576+0 records out 4294967296 bytes transferred in 3628.306 secs (1183739 bytes/sec) 60m28.49s real 0m1.33s user54m8.30s system On the archives I have seen recommendation to disable mpbios while machine is slow in general, however I am experiencing only slow disk I/O. I thought my problem is unrelated to mpbios. With qemu-kvm from RHEL7 on bsd.sp there is no mpbios mentioned in dmesg(8) (I didn't test bsd.mp). See dmesg output at the bottom of this email. Also starting OpenBSD with mpbios disabled via boot_config(8) ends up with: --- dmesg.txt Sat Jun 14 15:49:02 2014 +++ disable-mpbios.txt Tue Jun 17 08:15:34 2014 @@ -4,6 +4,11 @@ cpu0: FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,NXE,LONG,SSE3,CX16,LAHF,ABM,SSE4A,PERF real mem = 536367104 (511MB) avail mem = 515158016 (491MB) +User Kernel Config +UKC disable mpbios +368 mpbios0 disabled +UKC quit +Continuing... mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root @@ -22,7 +27,7 @@ ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins acpiprt0 at acpi0: bus 0 (PCI0) acpicpu0 at acpi0 -bios0: ROM list: 0xc/0x1000! 0xc1000/0xa00 0xc2000/0x2400 0xed800/0x2800! +bios0: ROM list: 0xc/0x1000! 0xc1000/0xa00 0xc2000/0x2400 0xed800/0x2800 pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 Intel 82441FX rev 0x02 pcib0 at pci0 dev 1 function 0 Intel 82371SB ISA rev 0x00 @@ -32,11 +37,11 @@ uhci0 at pci0 dev 1 function 2 Intel 82371SB USB rev 0x01: apic 0 int 11 piixpm0 at pci0 dev 1 function 3 Intel 82371AB Power rev 0x03: apic 0 int 9 iic0 at piixpm0 -iic0: addr 0x1c 0f=00 words 00=9d87 01=9d87 02=9d87 03=9d87 04=9d87 05=9d87 06=9d87 07=9d87 -iic0: addr 0x1d 0f=00 words 00=9d87 01=9d87 02=9d87 03=9d87 04=9d87 05=9d87 06=9d87 07=9d87 -iic0: addr 0x4c 00=00 01=00 02=00 03=00 04=00 05=00 06=00 07=00 08=00 words 00=9d87 01=9d87 02=9d87 03=9d87 04=9d87 05=9d87 06=9d87 07=9d87 -iic0: addr 0x4d 3e=d1 48=d1 4a=d1 4e=d1 fc=d1 fe=d1 words 00=9d87 01=9d87 02=9d87 03=9d87 04=9d87 05=9d87 06=9d87 07=9d87 -iic0: addr 0x4e 00=00 01=00 02=00 03=00 04=00 05=00 06=00 07=00 08=00 3e=d1 48=d1 4a=d1 4e=d1 fc=d1 fe=d1 words 00=9d87 01=9d87 02=9d87 03=9d87 04=9d87 05=9d87 06=9d87 07=9d87 +iic0: addr 0x1c 0f=00 words 00=8fc5 01=8fc5 02=8fc5 03=8fc5 04=8fc5 05=8fc5 06=8fc5 07=8fc5 +iic0: addr 0x1d 0f=00 words 00=8fc5 01=8fc5 02=8fc5 03=8fc5 04=8fc5 05=8fc5 06=8fc5 07=8fc5 +iic0: addr 0x4c 00=00 01=00 02=00 03=00 04=00 05=00 06=00 07=00 08=00 words 00=8fc5 01=8fc5 02=8fc5 03=8fc5 04=8fc5 05=8fc5 06=8fc5 07=8fc5 +iic0: addr 0x4d 3e=d1 48=d1 4a=d1 4e=d1 fc=d1 fe=d1 words 00=8fc5 01=8fc5 02=8fc5 03=8fc5 04=8fc5 05=8fc5 06=8fc5 07=8fc5 +iic0: addr 0x4e 00=00 01=00 02=00 03=00 04=00 05=00 06=00 07=00 08=00 3e=d1 48=d1 4a=d1 4e=d1 fc=d1 fe=d1 words 00=8fc5 01=8fc5 02=8fc5 03=8fc5 04=8fc5 05=8fc5 06=8fc5 07=8fc5 virtio0 at pci0 dev 3 function 0 Qumranet Virtio Network rev 0x00: Virtio Network Device vio0 at virtio0: address 52:54:00:12:34:70 virtio0: apic 0 int 11 Full, default dmesg: OpenBSD 5.5-current (GENERIC) #162: Tue Jun 10 21:17:31 MDT 2014 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: QEMU Virtual CPU version 1.5.3 (AuthenticAMD 686-class, 512KB L2 cache) 2.61 GHz cpu0: FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,NXE,LONG,SSE3,CX16,LAHF,ABM,SSE4A,PERF real mem = 536367104 (511MB) avail mem = 515158016 (491MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 06/23/99, BIOS32 rev. 0 @ 0xfc672, SMBIOS rev. 2.4 @ 0xfdde0 (10 entries) bios0: vendor Bochs version Bochs date 01/01/2011 bios0:
Re: openbsd live-cd?
On 06/17/14 15:27, Jean-Philippe Ouellet wrote: On Mon, Jun 16, 2014 at 03:47:14PM -0400, Brian McCafferty wrote: Install it to a usb stick. And then try to not get banned from the store you're trying the new hardware in for uploading malware (apparently that's what the dmesg scolling by looks like to the untrained eye :P), even if you got the managers permission first. Malware? Sue.
Re: openbsd live-cd?
On 06/16/14 21:35, Thuban wrote: Hi, I would like to try openBSD before installing it on my laptop to check if things works correctly (X server as example). Do you know any liveCD or any methode to try openBSD on some hardware before installing? Regards, -- Thuban PubKey : http://yeuxdelibad.net/Divers/thuban.pub KeyID : 0x54CD2F2F [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc] You'll be testing OpenBSD if you boot install55.iso.
Re: openbsd live-cd?
On 06/16/14 21:49, Thuban wrote: * Gustav Fransson Nyvell gus...@nyvell.se le [16-06-2014 21:38:02 +0200]: On 06/16/14 21:35, Thuban wrote: Hi, I would like to try openBSD before installing it on my laptop to check if things works correctly (X server as example). Do you know any liveCD or any methode to try openBSD on some hardware before installing? Regards, -- Thuban PubKey : http://yeuxdelibad.net/Divers/thuban.pub KeyID : 0x54CD2F2F [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc] You'll be testing OpenBSD if you boot install55.iso. Of course. Let me re-write my question : how to test openbsd before installing, especially the X server (because network and so cas be tested with install55.iso). -- Thuban PubKey : http://yeuxdelibad.net/Divers/thuban.pub KeyID : 0x54CD2F2F [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc] Hi, Well, if you give your specification we can probably answer any questions you have. You won't be playing highly advanced 3D games any time soon, I can give you that. //Gustav
Re: openbsd live-cd?
On 06/16/14 22:41, Thuban wrote: * Gustav Fransson Nyvell gus...@nyvell.se le [16-06-2014 22:21:44 +0200]: On 06/16/14 21:49, Thuban wrote: * Gustav Fransson Nyvell gus...@nyvell.se le [16-06-2014 21:38:02 +0200]: On 06/16/14 21:35, Thuban wrote: Hi, I would like to try openBSD before installing it on my laptop to check if things works correctly (X server as example). Do you know any liveCD or any methode to try openBSD on some hardware before installing? Regards, -- Thuban PubKey : http://yeuxdelibad.net/Divers/thuban.pub KeyID : 0x54CD2F2F [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc] You'll be testing OpenBSD if you boot install55.iso. Of course. Let me re-write my question : how to test openbsd before installing, especially the X server (because network and so cas be tested with install55.iso). -- Thuban PubKey : http://yeuxdelibad.net/Divers/thuban.pub KeyID : 0x54CD2F2F [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc] Hi, Well, if you give your specification we can probably answer any questions you have. You won't be playing highly advanced 3D games any time soon, I can give you that. //Gustav That's not my goal :). I need a system for work, so I have to open pictures, videos and so... Regards -- Thuban PubKey : http://yeuxdelibad.net/Divers/thuban.pub KeyID : 0x54CD2F2F [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc] Hi, Oh, you'll be fine, if it's stable, that I can't guarantee. But, better make sure you have an Intel chipset... they're common. //Gustav
X11 bug/slow mousepointer
Hi, I'm having problems with my mouse cursor (visually) stuttering across the screen when under high load, for example compiling many ports or /usr/srcmake build. PC is 32GB RAM, Intel i7 3920XM (quad core,) Intel HD Graphics 4000, nVidia GPU GTX 580M, 120GB SSD. OpenBSD 5.5. Kernel is -current, as of nearly this e-mail is sent. Userland is also -current. Installed from install55.iso. If you have any tips, I'll be happy to hear, thanks, If you need more information, tell me! //Gustav
