Re: XFCE screensaver strangeness ...
On 5.2.23. 18:38, Why 42? The lists account. wrote: Hi All, Recently I have noticed some XFCE screensaving weirdness e.g. The XFCE desktop seems to ignore my preference for xscreensaver, but rather always starts the xfce4-screensaver instead. Currently I think I have disabled both in my settings and yet the xfce saver is still getting started e.g. ... Has anyone else noticed anything like this? I can kill it and start the desired xscreensaver, but that seems to have some problems of its own e.g. ... I see the same behaviour on Linux too, so it is not OpenBSD specific. I am trying to find out what update to what XFCE component caused it, in order to report the problem upstream. Z.
Re: Weirdness with du/df/my brain (latter more likely)
On 22.1.23. 22:06, Steve Fairhead wrote: Hi folks, I was cloning a server with rsync in preparation for a major upgrade (elderly OpenBSD to 7.2). I noticed that the home partition usage was a good deal greater on the new machine than the old (as seen by df). After a lot of analysis, I found that all user folders (and all other folders/partitions) were near-enough identical on both machines, except for one - my boss's ;) . After more analysis, I found that it was his Maildir (using dovecot) that was weird: - Old machine: 49 GB - New machine: 188 GB Figures as measured with du -sk, which I realise is sector-oriented, but still... And yes, my boss does a *lot* of email. After yet more testing, I did a recursive copy of the old 49 GB Maildir to a spare folder on the same home partition on the old machine. This came up, again, as 188 GB. (FWIW, Windows via Samba reported "140 GB; size on disk 204 GB" for both the original "49 GB" Maildir and the 188 GB copy.) I'm just puzzled, and clearly missing something. Can anyone enlighten me as to the large (nearly 4*) discrepancy? Thanks, Steve Since you have the same result after copying the files on the same machine, I would say that some of them are sparse, and you didn't preserve that. For openrsync, I searched the man page, and didn't find any mention of "sparse", so I don't know how it handles them. If you are using "original" rsync, try with -S flag. Best regards, Zeljko
Re: RISC-V and OpenBSD
On 12/15/20 10:10 PM, Stuart Longland wrote: On 10/12/20 4:33 am, Mihai Popescu wrote: Just wanted to see if RISC-V architecture is attractive for OpenBSD development. It's open and it is from Berkeley. I hear it's only truly open if you're part of their exclusive "club". Otherwise it's as much "you take what you're given" as any other architecture. RISC-V architecture, and a few implementations are released under BSD licence. In contrast, ARM Holdings or MIPS Technologies don't allow others to use their architectures without paying royalty fees. For example, the Chinese Academy of Sciences designed Loongson processor from the scratch, but had to pay to MIPS Technologies in order to base it on the MIPS IV instruction set. Zeljko Jovanovic
Re: Can I boot without GPU ("headless")?
On 31.8.20. 10:52, Henry W. Peterson wrote: If I simply type "boot" with my keyboard, it does not boot because I removed the graphics card and the CPU does not include a GPU. If I configure boot.conf to use com0 as its default console, I will not be able to type the password to decrypt the disk at boot, because I have COM pins at my motherboard but not the port itself nor the cables. It seems clear to me now that the only thing I can do is to buy the serial communications ports and cables for all the computers (it is a subtantial expense I was trying to avoid because I can hardly afford it). But wasn't the conclusion of this discussion that you can just buy one, connect it to computer only for booting, and then disconnect it and use on another one? Somebody mentioned serial ports not being "hot-plugable". This is not a concern here, as the serial port is built into chipset and remains there - you are just moving the connector. The connector/adapter you need is something like this: http://www.kelco.rs/katalog/detalji.php?ID=19753 , but as somebody else wrote, the pinout is only informally "standardized", so it is best to check it in advance. Alternatively, instead of buying it, you can find such bracket (usually with one DB-9 and one DB-25 port) on old (very old!) PCs. I found mine many years ago in some old 486 waiting to be recycled. Best regards, Z.
Re: Cannot start conversation using talk
On 19.02.2020. 22:08, b...@0x1bi.net wrote: I've set my hostname to point to 127.0.0.1 and I still receive the same error. I tried with and without the domain information. Is there a log for talkd or inetd? I've attempted to use the -d flag for inetd however I receive no error messages or warnings. Ben Raskin. I haven't used talk in decades (literally), but here is an interesting comment from /etc/hosts on the system I am currently logged in (a Slackware Linux): # # hosts This file describes a number of hostname-to-address # mappings for the TCP/IP subsystem. It is mostly # used at boot time, when no name servers are running. # On small systems, this file can be used instead of a # "named" name server. Just add the names, addresses # and any aliases to this file... # # By the way, Arnt Gulbrandsen says that 127.0.0.1 # should NEVER be named with the name of the machine. It causes problems # for some (stupid) programs, irc and reputedly talk. :^) # # For loopbacking. 127.0.0.1localhost 172.30.1.10 myhost.mydomain.lan myhost So it seems that talk had always been picky about host name resolution. Appart from setting your address and host and domain names in /etc/hosts, do you have a "lookup file bind" line in /etc/resolv.conf ? If you don't, it defaults to "lookup bind file", so it will query DNS first, and then look into /etc/hosts. There is a possibility this too can confuse talk. Best regards, Zeljko Jovanovic
Re: The right way to view the current input layout in X
On 28.05.2019. 14:45, Максим wrote: I saw this option Not exactly what I want: "~ $ setxkbmap -query rules: base model: pc105 layout: us,ru options:grp:alt_space_toggle" I would like to know whether it is "en" or "ru" right now -- Best Regards Maksim Rodin Hi Maksim, I use the following command to enable switching with Alt-Shift between English US, Serbian Latin and Serbian Cyrillic layouts: setxkbmap -option grp:switch,grp:alt_shift_toggle,grp_led:scroll us,rs,rs ,latin, When keyboard layout is the first one specified (English US), Scroll Lock LED on keyboard is turned on, otherwise it is off. That's allow me to switch layouts fast, without looking at the screen. Hope this helps. Zeljko
Re: xfce4 and gtk+3 applications
On 13.11.2017. 00:47, Dutch Ingraham wrote: Hi all - I've just installed xfce and xfce-extras on my x86_64 box, running the snapshot from 11/11. I'm having trouble with gtk+3 applications such as firefox and geany. It *seems* gtk+3 is not being recognized, i.e., the scrollbar is an inoperative, wide gtk+2-type scrollbar, applications appear as though they are missing theming, e.g., there are no icons in the toolbars, all menu entries are scrunched together, etc. Also, in some xfce utilities, like the Notifications and Power Manager settings windows, are missing things like sliders and drop-down boxes; they are just text, and are therefore virtually unusable. I believe I have all the appropriate gtk+3 packages installed, as all gtk+3 apps work well when I'm using Awesome WM. Is this a gtk+3 issue, or am I missing some essential setting or package? Any suggestions? I encountered this long ago, but it is actually not an OpenBSD or gtk+3 issue. The problem is lack of gtk+3 themes in Xfce 4.12. Until Xfce 4.14 is released, you can try adding some theme from an another source. For example, https://www.gnome-look.org/p/1191436/ looks promising. Personally, I currently avoid "gtk3 only" applications, and stick with gtk2. Some (such as LibreOffice) switched to gtk3 default, but can still be compiled with gtk2. Another, such as Firefox, dropped gtk2 support some time ago. I currently use Firefox 52.4.1 ESR, since the ESR branch will support gtk2 for another year or so. Cheers
Re: 82599ES support
On 02.05.2017. 19:57, Lyndon Nerenberg wrote: We're looking to buy some 10-gig SFP+ boards, and are eyeing up Supermicro's 2-port boards (listed as the 'Intel 82599ES - AOC-STGN-i2S'). ix(4) doesn't list the ES variant of the chip, and a quick grep through the driver source doesn't mention it explicitly, either. Are any of you running this board under >= 6.0 ? (We need to buy these boards as part of a single lease, so I'm constrained on what's available. Otherwise I'd just buy some X520s.) 82599ES is the the "standard" two-interface chip, which is used in Intel X520 and many other boards. 82599EB is also a two-interface chip, but with XAUI interface only (no 10 Gb/s serial capability for directly connecting to SFP+). I didn't see any boards which use it, but it would be suitable for XENPAK or X2 transceivers. So 82599ES is essentialy 82599EB + serdes. There is also 82599EN, which is a single port 82599ES. These data can be found in the 82599 datasheet. I am familiar with them, because five years ago I worked on a 82599ES board design, but sadly my company didn't mananage to finish it on time. There was suddenly more and more boards on the market, the prices dropped, and we abandoned the almost-completed project.
Re: codepage and iocharset in fat32 aka msdos filesystem
On 17.01.2016. 16:12, Lampshade wrote: I am using Windows 8.1 64-bit and OpenBSD-current amd64. When I used Gnu/Linux I mounted fat32 partitions with these options: iocharset=iso8859-2,codepage=852 However OpenBSD's mount tells me: mount -t msdos -o codepage=852 /dev/sd0f /mnt/partycjaFat/ mount_msdos: -o codepage: option not supported and mount -t msdos -o iocharset=iso8859-2 /dev/sd0f /mnt/partycjaFat/ mount_msdos: -o iocharset: option not supported 1. What codepage is used by default in FAT32 filesystem created and mounted in OpenBSD? I mount FAT32 filesystems in Linux with: mount -t vfat -o iocharset=utf8 and then read/write them normally in Linux as well as Windows. Most filenames are in Serbian Latin (contain letters šŠ čČ ćĆ žŽ đĐ in addition to ASCII), others are in Serbian Cyrillic, and everything work well. Just use UTF8, and I bet you will have no problem in OpenBSD too.
Re: SPARC minimum hardware specification
On 19.07.2015. 19:51, Raul Miller wrote: http://www.andovercg.com/datasheets/sun-fire-v210-server.pdf Suggests that we're talking 320 watts, and 7.3 db acoustic noise. http://www.gcaudio.com/resources/howtos/loudness.html suggests that whispers are about 30 db. And, 320 watts is not too far from what you would expect from a 3 bulb light fixture. Gamer rig PCs can run hotter than that. So perhaps I'm looking at the wrong information? Info is all right, but is says 7.3 B = 73 dB = very loud.
Re: File transfer from NetBSD to OpenBSD
On 01.03.2015. 17:55, Josh Grosse wrote: You might experiment with ext2fs. IIRC, FAT has two strikes against it: owner/mode, and 4GB individual filesize limit. NTFS (built-in, or FUSE) has its own owner/mode translation issues, such that you would liely want to archive files as intermediate step. Or use FAT, but put all files in one or serveral tar archives. In that way, file type, ownership and permissions would be saved.
Re: Former Yugoslavia in countrycodes
On 12.01.2015. 01:00, Dmitrij D. Czarkoff wrote: Zeljko Jovanovic said: I thought at least OpenBSD people had some understanding of how world politics work. This is wrong forum for "world politics" discussions. Let's not digress. Agreed.
Re: PRG airport in misc
On 07.01.2015. 18:16, Ted Unangst wrote: ZZE:Ponikve, Uzice, Serbia KVO:Morava, Kraljevo, Serbia Wikipedia has Uzice-Ponikve as UZC. Neither airport has regular flights, so I'm not sure we want to list them. I think the original guideline "add it if you've flown through it" was a good one. Seems reasonable. Both were military airports which are now being converted to military/civilian use. This is relatively common pratice in small cities all around the world.
Re: Former Yugoslavia in countrycodes
On 05.01.2015. 10:14, Peter Hessler wrote: On 2015 Jan 04 (Sun) at 21:39:08 -0500 (-0500), Predrag Punosevac wrote: :For many of us who were born in that country and whose lives have been :altered forever by actual events on the ground your remark doesn't sound :clever I'm sorry, but this is simply a fact. To get a country code assigned, you will need to contact the ISO. We are unable to assign one for them. Peter, I believe you had good intentions, but your comment made me (and I am sure Predrag as well), even more miserable. We do not want any iso codes assigned to a part of our country occupied by islamic militants! I thought at least OpenBSD people had some understanding of how world politics work. The same people who decide whether you may or may not "exercise your freedom of speach", can also decide whether some group are "terrorists" or "freedom fighters", depending on part of the world in which that group operate.
Re: PRG airport in misc
On 04.01.2015. 14:22, Reyk Floeter wrote: Thanks, done. Index: airport Speaking of changed airport names, I expected to see: BEG:Surcin, Belgrade, Yugoslavia but it was apparently never entered at all. The current name is: BEG:Nikola Tesla, Belgrade, Serbia and there are another few missing: INI:Constantine the Great, Nis, Serbia ZZE:Ponikve, Uzice, Serbia KVO:Morava, Kraljevo, Serbia These two: TIV:Tivat, Yugoslavia TGD:Golubovci, Podgorica, Yugoslavia should be changed to: TIV:Tivat, Montenegro TGD:Golubovci, Podgorica, Montenegro
Re: The rant about browsers
On 23.08.2014. 18:16, Nick Holland wrote: real mem = 1568260096 (1495MB) avail mem = 1517772800 (1447MB) ... cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Celeron(R) CPU G530 @ 2.40GHz, 2394.94 MHz ok, how do I put this nicely... To run a modern browser, you need a modern computer. 1.5GB RAM and a celeron processor doesn't cut it. NOW, that doesn't cause CRASHES, but when you fix the crashes by cranking up your login.conf specs, you will be so far into swap you will wish your browser crashed. Well, nowadays one can get a very fast CPU and lot of RAM cheaply, but that does not mean all of this is necessary in order to just browse the web. From time to time, I must use a 12-year old Pentium 4 Northwood, 1.8 GHz, 512 kB cache with 512 MB RAM, it has Windows XP installed and is quite usable with modern web browsers. Until recently, I also regularly used an Athlon64 Venice, 2.0 GHz, 1 MB cache and 1 GB RAM under Linux, and it was usable even with many tabs/sites open. The only problem was Adobe flash Linux plugin, which was for some reason slower than its Windows counterpart. Current Pentiums and Celerons (such as this G530) are based on Core i architecture, have more than one core, and are much faster than the two mentioned processors. 1.5 GB RAM is also _a lot of memory_, regardless how easy is to get more today. The point is: It should work just fine. Just raise the OS memory limits.
Re: openssh
On 03.07.2014. 10:41, Peter N. M. Hansteen wrote: And if the hard disks are small enough, you can attach them to pigeons, or swallows, even! (African or European) - P What is the air-speed velocity of an unladen swallow (African or European)? :D
Re: OpenBSD 5.5 on mSATA SSD unit in PC Engines APU.1C - "bad dir ino 2 at offset 0: mangled entry"
On 27.06.2014. 08:59, Mihai Popescu wrote: It think the designer wanted to keep the board compatible with the old case, or the other way around. To cool the CPU more one needs better pads ( i doubt there are much better, since the industry has standards) or adds a fan. Current situation is like this: \__/ - CPU - PAD == - Aluminium heatsink - PAD - CASE A better approach is a cast aluminium case, but this is too expensive. So one can do pressed steel sheet like this: \__/ - CPU - PAD . ../ \... - CASE ^^^ bend area This way, one pad and the extra aluminium heat spreader can be out of equation. Of course, and extra bending of the bottom sheet is needed. Maybe the price will go higher, maybe the CPU is too far and the bending distance I would try to replace the aluminium sheet with a copper one. It would be also good to make it thicker, in order to avoid thermal pads and use thermal paste instead (to additionally lower thermal resistance). Finally, increasing the area of this sheet would also help, preferably to cover the entire bottom of the box.
Re: OpenBSD on IBM Power
On 14.04.2014. 04:53, Nick Holland wrote: um. Linux kernel 2.4? Are you kidding me? dead dead dead. I said the port was old and had not been maintained for a long time. :) In any case, if one wants the current Slackware on System Z, I am sure this old version could be used as a starting point for compiling it. I would very much like to play with IBM mainframes, but as I know, the last one here at Belgrade University was dismantled some 16 or 17 years ago. It was a System 370, given by IBM for free back in the times of old Yugoslavia. The room it occupied has been since turned into classroom, and only its air condition system remained. They also kept a fancy black cube-shaped IBM vacuum cleaner. :)
Re: OpenBSD on IBM Power
On 09.04.2014. 18:24, Fil Di Noto wrote: Is there any hope of OpenBSD running on IBM Power hardware (System P, LPAR) in the future? ... OS on that hardware without cooperation from IBM? I don't see any Linux distros that do not have a relationship with IBM that run on Power. Slackware Linux has an IBM port, although it has not been updated for several years now: http://www.slack390.org I am not sure what are the differences between largest IBM machines (System Z, formerly known as System/390), and smaller systems such as System P. But I am sure that Slackware project certainly does not have a relationship with any company. By the way, as you probably know, Slackware is the oldest surviving Linux distribution, and adversises as the most "UNIX-like" among Linuxes. Also, its /etc layout is of BSD type, not System V like in other Linux distribution. The overall "look and feel" after instalation is similar to OpenBSD. Even the BSD games packages, with fortune program enabled by default is there. :)
Re: In some man pages Mb means MB, in others it means Mb/s
On 24.08.2013. 15:36, Jason McIntyre wrote: at first i feared a can of worms, but actually it's not looking so bad. of the two pages in base you point out, i think sort(1) definitely needs changed. ld(1) is 3rd party, however, so i'm not touching that. of the "pf-related pages"...i think hostapd.conf(5) could be clearer, ... as far as packages, i doubt the man pages would be changed. i guess you could talk to the individual port maintainer if you wanted. Thank you! As for GNU binutils and ports, I will contact their maintainers directly. Zeljko Jovanovic
In some man pages Mb means MB, in others it means Mb/s
I was just reading some random man pages, and noticed a few places where "Mb" should probably be changed to "MB", since the intended meaning is Megabytes, not Megabits. In the base system, these are sort(1) and ld(1). I have only a few additional packages installed, but found it also in /usr/local/man/cat3/pcrestack.0 The "Mb" abbreviation is also used in pf-related pages: hostapd.conf(5), iked.conf(5), ipsec.conf(5), pf.conf(5), in the meaning Megabits per second. So it could be more correctly written as Mb/s (or at least Mbps). However, since the Mb word, in the meaning Mb/s, is already part of pf syntax, I suppose it is going to stay that way. :) Cheers, Zeljko Jovanovic
Re: OpenBSD Doesn't Support 64-Bit Intel
On 03.07.2013. 19:15, Chris Cappuccio wrote: Is there floating-point hardware for 486 or higher that isn't "Intel-compatible"? This text seems superfluous. I remember some Weitek floating-point coprocessors from those times - I suppose they were not x87 compatible?
Re: Re : Tux cups
On 10.05.2013. 20:51, Erling Westenvik wrote: The intention with my original email was actually to be kind of funny but the smiley got lost somehow.. Well, all right then. :)
Re: Re : Tux cups
On 10.05.2013. 19:55, Evan Root wrote: Hey Erling, Maybe we should figure out where the default file is and replace it with this: ... Wish this list accepted attachements because I could show you a scan of the Mac os x default test page that is the same as above. It has no logos except the Cups C with 'unix printing system' inside it, even though Apple employs Micheal Sweet. Out of curiosity, I've just tried printing CUPS test page on Slackware Linux, and it is exactly like the picture from your link. Just C - Unix Printing System logo, and no penguins of any kind. The used pictures are cups.png and color-wheel.png from /usr/doc/cups-1.5.4/images directory. The question remains... if the tux logo is not CUPS' default, and it is not ubiquitous even on Linux, how did it find its way to OpenBSD?
Re: altq on a variable bandwidth interface
You cannot do any kind of bandwidth shaping, priorization or fair queueing on any link but the bottleneck. that is plain bullshit. I think you are talking about two different things here: Henning Brauer is explaining how queuing and prioritization work in OpenBSD, while the others have in mind those network switches and routers which perform packet switching in hardware. In such devices, input frame or packet is forwarded without any queuing if the output port is not congested. Otherwise, the queues would quickly grow and overrun (and the latency would be higher). This is the only possible thing to do when there are tens or hundreds of interfaces, especially high speed ones. So, it is probably not a good idea to automatically apply knowledge about network hardware to packet switching in general-purpose operating systems.
Re: Loongson -- is it actually encumbered now?
On 09.09.2011. 00:32, ropers wrote: http://en.wikipedia.org/wiki/Loongson#MIPS_patent_issues So does this mean that this platform is now to be regarded as patent-encumbered and no longer completely free (libre)? (That would kind of ruin the big appeal for me.) The platform is free in software sense, i.e. there is no proprietary firmware or other software. The hardware specification is also available to general public, in the form of manuals (some in Chinese only, but they are being translated). The Chinese didn't make a clone of a specific MIPS processor (although they could have done that if they wanted, as there are no patents or laws or royalty fees associated with that), but made a completely new processor. It executes the MIPS instruction set, which is (IMO) a very wise choice (for many reasons). They payed a fee to MIPS Technologies only as a sign of good will (and they didn't want press to write (lie) about some patent nonsense associated with their product). Officialy, the explanation is that that gives them right to use the MIPS-compatible labeling. I was very happy when I learned about Loongson processor, because this way the MIPS continues to live. It is a great architecture and it unjustly disappeared from market (together with other RISCs), because of Intel and its Itanium (which turned-out to be a failure). So, buy a Loongson system, and enjoy it! :) Not only it is a more elegant architecture, but it gives you a much more performance per Watt than any x86/x86_64. And if your primary motiff is "freedom", than it is also an excellent choice.
Re: OpenBSD on QEMU-emulated Loongson-2E system
On 13.05.2011. 06:28, Miod Vallat wrote: Why are you trying to emulate a 2E system? OpenBSD/loongson has never been tested on a Fuloong 2E system and I wouldn't be surprised if it did not work at all on such a machine (and I've been unable to find one on the second hand market). You are likely yo get better results trying to emulate a 2F system. QEMU does support 2F processor, but can currently emulate only the Fulong-2E system. Of course, it is possible to start it with: qemu-system-mips64el -M fulong2e -cpu loongson-2f, but it is still a Fulong-2E system, albeit with a 2F processor. In that case, the OpenBSD kernel reports "Unable to figure out model". The reason I am doing all this is that I really want to try OpenBSD for Loongson, but I do not have a real Loongson machine. Hopefully this will change soon. :) Zeljko
OpenBSD on QEMU-emulated Loongson-2E system
I tried to run an OpenBSD kernel image (for Loongson) under QEMU-emulated Fulong2E system (on AMD64 host). When I load the kernel from PMON, it starts, but then the following exception occurs (0x1fe00138 is the address of Bonito INTEN register): PMON> boot -k /dev/fs/ext2@wd0/bsd Loading file: /dev/fs/ext2@wd0/bsd (elf) (elf) 0x8020/4656352 + 0x80670ce0/578912(z) + 12144 syms Kernel debugger symbols ELF hdr @ 0x806fe248 Found Generic Loongson2E, setting up. Exception Cause=address error on load or ifetch, SR=0x2402, PC=0x8059d284 CONTEXT=0x000ff000, XCONTEXT=0x000ff000 BADVADDR=0x90001fe00138, ENTHI=0x80001fe0 ENTLO0=0x, ENTLO1=0x zero at v0 v1 a0 a1 a2 a3 fffe 2400 1fe00138 1fe00134 fff9 801ffec4 t0 t1 t2 t3 t4 t5 t6 t7 801ffec8 1fe0 0008 0002 0001ffe0 8067 8070 s0 s1 s2 s3 s4 s5 s6 s7 0019 806678c0 806f 8070 8070 0063 t8 t9 k0 k1 gp sp s8 ra 8070 8070 806600e0 801fff00 1fff 8059d268 8059d284 8c67 lw a3,0(v1)# addr=0x1fe00138 By inserting a few debug pmon_printf calls in the machdep.c file and recompiling the kernel with a cross-compiler, I found that everything is executing fine until consinit(), and the exception happens in that function. After commenting out consinit() and the subsequent printf calls, the kernel execution continues for a few more lines, and than stops at initmsgbuf (msgbufbase, MSGBUFSIZE) line with the following execption: PMON> boot /dev/fs/ext2@wd0/bsd Loading file: /dev/fs/ext2@wd0/bsd (elf) (elf) 0x8020/4656336 + 0x80670cd0/578912(z) + 12136 syms/ Found Generic Loongson2E, setting up. Exception Cause=address error on load or ifetch, SR=0x2402, PC=0x802fc090 CONTEXT=0x3800, XCONTEXT=0x3800 BADVADDR=0x9870, ENTHI=0x8070 ENTLO0=0x, ENTLO1=0x zero at v0 v1 a0 a1 a2 a3 8067 8067 0070 4000 8067 0016 t0 t1 t2 t3 t4 t5 t6 t7 bfd003f8 0040 0008 8009fbc4 0001ffe0 806f 806f6560 s0 s1 s2 s3 s4 s5 s6 s7 0070 8067 8067 8070 8070 0063 t8 t9 k0 k1 gp sp s8 ra 8070 8070 806600d0 801fff60 1fff 804c099c initmsgbuf+0x30 dc83 ld v1,0(a0) # addr=0x70 There is probably nothing wrong with the OpenBSD kernel, but I just wanted to ask if somebody had a clue about what was happening. I tried QEMU 0.14.0 and 0.14.1, and OpenBSD kernels from 4.8, 4.9 and current CVS version. Interestingly, the Linux kernel from Lemote BBS runs fine in QEMU, even without PMON present (with qemu -kernel option). Thank you in advance, Zeljko
