Re: pledge(2) problems on 18/x/ octeon snapshot
> > Might be a stupid question, but I haven't found an answer to it yet > > - how does one update to a new snapshot/kernel on an octeon system? > > boot bsd.rd and select upgrade in the installer. (i hope.) > I'm afraid this is not as simple as this, yet. You will also need to copy your kernel to the fat16 partition created during the install, since this is the only filesystem #$%^@# u-boot can read.
Re: cannot input _ (keyboard layout is jp)
> chose 'keyboad layout' jp(japanese), > then i cannot input _(under bar) . Are you using a PS/2 or USB keyboard? The underscore should be obtained with shift-backslash (using the key left of the right shift key).
Re: Include "wsconsctl" on installer CD so keyboard repeat can be disabled = make VNC KVM install smooth on laggy connection?
> VNC KVM install means some keypresses will be interpreted as seconds-long, > ordinarily leading to multiple unintended "enter" or character key presses > which easily seriously breaks things, when the connection is not perfect, > which it many times is not. > > I believe there is no way to disable keyboard repeat on the installer CD - > > What do you say about including "wsconsctl" on it? No, thanks. If you are attempting to install OpenBSD remotely over a flakey connection, I'd suggest using the `autoinstall' feature so that you do not need to enter anything.
Re: Include "wsconsctl" on installer CD so keyboard repeat can be disabled = make VNC KVM install smooth on laggy connection?
> do people need autorepeat in the installer? (for what?) i think it'd be > simpler to just disable it in all ramdisks. Not all keyboards support disabling autorepeat, and for those which can, this would add more badly tested code path to their drivers.
Re: console color
> For local console I've googled and TERM=wsvt25 brings colors to emacs > and vim for me on amd64. wsvt25 (and wsvt43 and wsvt50) only are 8-color terminals, and that's the best the kernels's console emulation code will provide; and this is not going to change anytime soon. If you want 16 or 256 colors, run X.
Re: console color
> Can someone give be a brief rundown on how OpenBSD handles color on console? It depends upon the terminal emulation being used. OpenBSD provides both a `sun' terminal emulation, which is the default on sparc and sparc64 (use either TERM=sun for faithful behavioul or TERM=rcons-color for the colour extensions), and a `vt220' terminal emulation, which is a subset of the VT220 command set, with some xterm control sequences recognized (use either TERM=vt220 or one of the wsvtXX matching your number of rows). The SGR (ESC [ * m) sequences recognized by the vt220 emulation are 0 (reset), 1 (bold), 4 (underline), 5 (blink), 7 (reverse video), 30-37 (select fg color), and 40-47 (select bg color) [in fact, a few VT300 sequences are also recognized but they don't matter here]. There is no support for more than 8 color code using 90-97 and 100-107. Also, keep in mind that, depending upon the actual video hardware being used, the hardware may not be able to output what the escape sequences are requesting. Not all hardware supports blinking or underline, for example.
Re: Question - test lab
> General hints for picking up an alpha: [...] > If you intend to be in the same room as the machine, pick a workstation > model and not a server. DS25 are supposed to be deskside workstations, but their noise level fits in the `server' category.
Re: System clock hours behind, network hangs (amd64, -current)
> Could you also include the output of "ifconfig", "netstat -nf inet" and > "netsat -rn"? "vmstat -i" might be useful as well.
Re: Kernel Driver Question
> is 'bus_dma' > http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man9/bus_dma.9 > the <> of 'ioremap/ioread32' > http://www.makelinux.net/ldd3/chp-9-sect-4-- > ? I don't think so. It looks like you are attempting to port a PCI driver, and attempting to access the device's register. PCI device regions in memory and I/O space are made available to the kernel with pci_mapreg_map(), which gives you a bus_space_handle_t suitable for use with thi bus_space(9) API. This would be a sugar-coated equivalent of ioremap(). >From then on, bus_space_read_(N/8) will match ioreadN() calls.
Re: SPARC minimum hardware specification
> Indeed. If you're a "my neighbour listens to heavy metal all day, whether > he wants to or not" kind of person, then these machines are for your home. Well, ny neighbours listen to heavy metal every day whether they want it or not, but I'd hate for a loud computer to impair that heavy metal experience.
Re: SPARC minimum hardware specification
> What are the minimum requirements for a "decent" SPARC machine? I mean > by that a machine who is able to run OpenBSD as a desktop. I am > currently use a Pentium 4 3.2GHz with 2 GB DDR and it barely meets my > needs. Tell me please the CPU or the machine name, I will search the > prices :-). I doubt any sparc hardware would fit. Not even a Sun Blade 2500.
Re: LibreSSL enable-ec_nistp_64_gcc_128 vs. compiler bugs
> Hi Miod, > > is your statement from > http://article.gmane.org/gmane.os.openbsd.misc/218944 : > > Until someone spends enough time checking the various compiler > > versions around to check which are safe to use, and which are not, > > this code will remain disabled in LibreSSL. > > still valid, or was there any change related to this? That statement still stands.
Re: # sign
> >hash > > > Wikipedia says that he use of "hash" for this sign may have come > from Baudot, which predated both ASCII and EBCDIC. > I thought everyone here knew that this sign is actually historically called `sliced unicorn hearts' after the specific pattern their heart display when thinly sliced. Oh, I'd kill for a unicorn heart carpaccio, right now. It's been too long since I last had some.
Re: sshd segfaults after applying OpenBSD 5.7 errata 9
> I am now trying to revert errata 9 and recompile libcrypto to see if I get > a usable system back. (This is a fun breakage, curl is no longer working > for instance.) If think I will move o to bsd.rd. You can use ftp(1) instead of curl. > In the hubbub around OpenSSL 1.0.1n I read there was a problem with ABI > breakage, leading to an 1.0.1o release. I wonder if 5.7 errata 9 incurred > the ABI breakage of the snarfed OpenSSL 1.0.1n release. There are no ABI changes in the libcrypto errata in OpenBSD 5.7. Are you sure however, your source tree is really 5.7-STABLE and not a mix of HEAD and 5.7-STABLE?
Re: Random PID implementation and security
It is not the responsibility of the operating system to protect its users against software which assumes using the pid as a random source is a bright and wise idea.
Re: "long pad" argument in SYS_mmap syscall
> #define SYS_MMAP(addr, len, prot, flags, fd, off) \ > __syscall(SYS_mmap, (void *)(addr), (size_t)(len), \ > (int)(prot), (int)(flags), (int)(fd), (__off_t)(off)) > #elif defined(__FreeBSD_kernel__) > #define SYS_MMAP(addr, len, prot, flags, fd, off) \ > syscall(SYS_mmap, (void *)(addr), (size_t)(len), \ > (int)(prot), (int)(flags), (int)(fd), (__off_t)(off)) > > sys/sys/syscallargs.h tells me that in OpenBSD there is a further > argument "long pad" at sixth position. Just setting it to "(long) 0" > gives a segmentation fault. Actually, it's an int. But it only matters if you are wrapping the system call. If you are wrapping the mmap() symbol, it's already doing the right thing and does not need any extra parameter. See src/lib/libc/sys/mmap.c for yourself.
Re: Can't install latest snapshot over http
> Hi there, I wonder if others had the same problem with the latest > snapshot. I can't install over http, for every file it fails with > "Ilegal instruction". Does anyone else has the same problem? It's the > snapshot from the 26th, the latest. Do you realize you are not giving ANY information which might help us help you? We don't know what hardware you are installing on, which mirror you obtained the installation media from, the result of the sha256 check, if the installation media you had been booting was the snapshots' or an old bsd.rd lying around, etc.
Re: running multiple simultaneous X sessions as different users
> Now I finally (cough) notice those error messages in dmesg.boot. Not > sure how critical they are, if it's referring to missing binary blobs, > and if openbsd has fallen back to acceptable/stable defaults or > something. But where it says "screen 1-5 added", that seems to connect > with 'man wsdisplay' saying that screens can be > configured with either the wsconscfg utility or a (kernel?) > compile-time parameter. I tried running things like "wsconscfg 6" (& > 7, 8), which return 0, but it didn't seem to change the behavior. The kernel will attach WSDISPLAY_DEFAULTSCREENS virtual consoles by default, which is 6 on i386 and amd64 platforms. More virtual consoles (up to WSDISPLAY_MAXSCREEN, which is 12) can be created by using wsconscfg as you did. Your dmesg output will report something like: wsdisplay0: screen 6 added (std, vt100 emulation) Now, for X to find a proper virtual console to run on, it has to find an unused one, i.e. one where no getty(8) runs. This is controlled by /etc/ttys, and in the default congfiguration of six virtual consoles, only the fifth (ctrl-alt-F5) is left unused and available for X. If you run another X server instance, it will use the seventh virtual console (ctrl-alt-F7). But I am not sure drm-enabled X servers can run multiple instances. Miod
Re: HP900/803/D220 working just as needed.
> This is very good news! How does it work? How did you install? CD?
> I used to run Linux on HPPA, before the disks died, but I had a lot of
> trouble with software being buggy on HPPA. No Stack made a lot of stuff
> crazy (ffcall, ffi, interpreters, brwosers) in any case a very fine memory
> bug finding machine :) And very safe for servers, no stack-protection
> needed! I mourn HPPA.
I think you are deluded. The stack orientation on hppa makes any kind of
stack protection pointless, not because it is safe, but because it is
trivial to bypass.
Consider this:
#include
voidbogus_routine(char *);
int
main()
{
char buf[128];
bogus_routine(buf);
return 0;
}
void
bogus_routine(char *buf)
{
memset(buf, 0xff, 128 + 40);
}
bogus_routine() will happily overwrite the return address - which is on
the stack *beyond* buf. In this simple case, it will simply cause a
segmentation fault and a core dump because the address is not valid.
Now imagine bogus_routine() is not in your program, but in a shared
library from a huge third-party software known for frequent
vulnerabilities (for example, lib). A
malicious input passed to a function in such a library could overwrite
the return stack with a carefully crafted return address and make your
innocent image viewer misbehave in many ways.
Re: Does LibreSSL support RSA export-grade keys? - FREAK Attack
> "interoperable" - you mean there are still softwares that really count and > still cannot use/support HIGH ciphers? wow. What a world we live in.. :\ There are still idiots top-posting, why wouldn't there be idiots misconfiguring TLS servers or not giving a damn? Miod
Re: Does LibreSSL support RSA export-grade keys? - FREAK Attack
> "Sometimes you have to break things to make it better" Yes, and getting people to stop using LibreSSL because it suddenly is not interoperable with anything would surely help a lot. Instead, we are trying to get developers to try and use LibreSSL provided libtsl, which defaults to sane, strong crypto choices. Miod
Re: Does LibreSSL support RSA export-grade keys? - FREAK Attack
I think that's a win. What about PFS-only + HIGH ciphers? What about interoperability? It is too early to restrict LibreSSL to PFS ciphersuites, alas. Miod
Re: athn at usb fixes
You can borrow a tip from USB hardware hackers here: use an external hub to help protect your ports. But I really need my hub, too! Look for people holding ``free hubs!'' signs in the streets...
Re: Legacy Laptop stops working with OpenBSD GENERIC >= 5.5
> >Both works with OpenBSD 5.4. > > Ok, I've remembered ACPI and given it a try to disable in UKC. > Now, the stuff works. :-) But now you're depriving us of the means to help you. Please send a 5.4 dmesg if you still have it, and 5.6 dmesgs with and without acpi disabled, as well as `acpidump' and `pcidump -vxx' output, to b...@openbsd.org .
Re: man shutdown 8 diff in BSDs
> > Make -h, -p and -r distinct, incompatible, options. (removes support for > > -hp) > > Like FreeBSD, it seems reasonable to also mark -k as incompatible with the > > other three options. > > I hate this. I type shutdown -hp all the time. Ditto. I'm fine with -p implying -h, but don't break existing -hp muscle memory.
Re: Variable Length Arrays
> So I've been wondering about variable length arrays from c99 for a while > now. They seem to me like a good way to avoid lots of trivial calls to > malloc/free at least for smaller arrays that aren't going to blow up the > stack. That said I don't see them being used. > > The promise of them seems to be 'easy', dynamic, stack allocated memory and ^ Most uses of variable length array in the kernel (and a significant part in userland) needs allocated data to outlive the routine they are allocated by. This rules out stack allocation.
Re: [Tor-BSD] Recognizing Randomness Exhaustion
> > I should have also specified that I didn't just go ahead and enable them > > because I wasn't sure if they're considered safe. I like abiding by > > OpenBSD's crypto best practices when possible. > > > > Is there any reason why they're disabled by default? > > Compiler bugs generate incorrect code for 128 bit integers. In slightly more words, we have tried enabling this code, and found out the hard way that, when compiled by the system compiler under OpenBSD, it would generate slightly wrong code, and cause computations to be subtly wrong. Until someone spends enough time checking the various compiler versions around to check which are safe to use, and which are not, this code will remain disabled in LibreSSL. Miod
Re: OpenBSD projects
> Was Tim Miller (guy that created sudo, right?) an openbsd developer > before/during/after/never when sudo was put in base in 2009? He's Todd Miller, he did not create sudo, and sudo was imported in 1999, not 2009.
Re: OpenBSD projects
> Here's a list of projects that I'm aware of that openBSD created. Is > that correct? (p) is for portable. What else am I missing? > mandoc (p) Mandoc was not initiated by OpenBSD, although it got engulfed very quickly thanks to Ingo's hard work.
Re: Strange default values in /usr/src/distrib/amd64/iso/Makefile
> > This change is not going to happen. > > Okay, thanks, I can see how that would be a problem. > Note that these variables are ?=, so environment takes precedence. Just build with RELDIR and RELXDIR set in addition of RELEASEDIR and you're all set.
Re: null checks before free()
> Not that long ago we saw a lot of commits related to null checks being > not needed before free() calls. [...] > So how should I interpret this in relation to the above commit messages? > > 1) double free is safe, no need for null checks > 2) double free is detected by OpenBSD, no need for null checks we will > kill your program > 3) double free is unsafe, avoid double free > > I would like to think that (2) is true. Though reading the man page > makes an initial impression (at least for me) that (3) is true and could > lead to people following the rule of null checking before a free call? > > Should the man page be altered to discouraged the use of null checks > before calls to free? I am not sure I can understand the state of confusion you are in to ask such a question. The act of freeing a pointer, whichever value it has, will not change the value of the pointer variable. It will not magically become NULL after your first call to free(). Double free() are never safe, and some of them are caught by OpenBSD's malloc, but not all of them. But free(NULL) is actually a no-op because nothing has been allocated, so you can call free(NULL) as many times as you want. Miod
Re: segmentation fault during package build
I can confirm the spurious segmentation faults or `double free' issues with an SM40 module, and I am currently investigating the issue. Miod
Re: Disk /dev/X is user root, group wheel, permissions brw-r-----.
> > chgrp operator /dev/X > > Thanks. I tried it but I now get > > Disk /dev/X is user root, group operator, permissions brw---. Permissions are supposed to be 640. Either your original install was not made from a verified OpenBSD source, or you've run some scripts on your system since then, which are highly suspicious. Miod
Re: OT:Password strength
> Examples: > > treetykaveprethicooputhedu > soonataviceenoopatecoge > gootrozapiceelytrithunula > preezypeendothanundipeesooka These stand no chance against a finnish attacker! Miod
Re: Ancient source-changes archive
> Use ftp://ftp.openbsd.org/pub/OpenBSD/Changelogs/ or any mirror. > > For developers, the same is available in /cvs/CVSROOT/ChangeLog*. Ah, but these files lack about one month of changes in 1996.
Re: Sun/Cassini Quad Gigabit Card Not Detected
> Hi, > > I've installed OpenBSD 5.6 (i386) on a dual processor XEON box which > has a 4 port Sun (Sun# 501-6738-10) Gigabit NIC card. dmesg doesn't > have any indication that the card is installed. Booting Linux shows > the card as Sun/Cassini which I believe should be handled by the "cas" > driver. The cas(4) driver for this hardware is not enabled in the i386 and amd64 kernels, and is probably untested on these platforms. You might want to add cas*at pci? to the kernel configuration file and rebuild it, and see if it works. Miod
Re: sudo bad practice or inconsistency?
> just22@poseidon:[xfe]> sudo su -c ls > su: no such login class: ls > > so basically sudo is parsing the "-c" option instead of passing it to > su. No, it is not. If it were, the error message would come from sudo, not from su. > And, in any case, why the same command works in Linux? do they use a > modified/patched version? They use a different su(1). You might want to check the third example in the OpenBSD manual page for su.
Re: [LibreSSL] unable to encrypt file
> I'm trying to encrypt a file using openssl and a prompted password on OpenBSD. > Unfortunately there is no prompt and all I get is a 'bad password read': I'll guess you're using a snapshot from one or two weeks old. This has been fixed since.
Re: running cvs update as root (was: Re: New install)
> http://www.openbsd.org/anoncvs.html shows the 'cvs update' command being
> run by root ("#" shell prompt), and I wouldn't expect any non-root user
> to have write permission to /usr/src anyway. So... why is doing the
> cvs-update as root a bad idea?
Is this a kind of bad joke? Running anything as root unless it
absolutely requires root privileges is a bad idea. Put yourself in the
wsrc group, and you'll be able to write into /usr/src.
Miod
Re: New install
> cd /usr/ > export CVSROOT=anon...@anoncvs.openbsd.org:/cvs > cvs -d$CVSROOT up -rOPENBSD_5_5 -Pd You should run this in /usr/src, not /usr. And you should not run this command as root either.
Re: standard FAQ procedure ... in chroot
> >> Is this some kind of security protection ? > > > > of course... see mknod(2). > > i read it and still does not understand. Check the description of EINVAL.
Re: new OpenSSL flaws
> Now you have and example of how they are unwilling to work with you next > time someone asks why not work with OpenSSL on fixing it. Pretty direct > proof. The culture gap between OpenSSL and OpenBSD/LibreSSL is UNFIXABLE. We believe in peer review; they don't give a sh*t about it (as shown less than a month ago by the way their #3317 bug was fixed, commiting a different fix from the proposed one and introducing a stupid *and obvious* bug in the process - which got fixed the next day after otto@ mentioned it to the OpenSSL developers). If you can't trust people to apply one-liner fixes correctly, can you trust them for anything serious? Miod
Re: building a release "sh checkflist"
> When I run "sh checkflist" from /usr/src/distrib/sets I get the > following output: > # cd /usr/src/distrib/sets > # sh checkflist > 1,51d0 [snip 28721 lines] > > In the past I usually get no output when I run it. > > Any thoughts? You forgot to set DESTDIR.
Re: Lenovo Y510P status on OpenBSD amd64 -current
> 6) Wired LAN not supported > "Attansic Technology AR8171" rev 0x10 at pci1 dev 0 function 0 not configured There is currently no support for this chip in OpenBSD. If you're willing to tinker, you could try and port the FreeBSD driver available here: https://github.com/markjdb/alx-freebsd which is supposed to work (it has been done by a FreeBSD developer, but for some reason I'm not aware of, it does not seem to have been commited to their main repository). Miod
Re: Intel driver doesn't get automatically selected by Xorg
> When I run X, I get the following result (from Xorg.0.log): [...] > [ 42880.713] (II) intel: Driver for Intel(R) HD Graphics: 2000-5000 > [ 42880.713] (II) intel: Driver for Intel(R) Iris(TM) Graphics: 5100 > [ 42880.713] (II) intel: Driver for Intel(R) Iris(TM) Pro Graphics: 5200 > [ 42880.713] (II) VESA: driver for VESA chipsets: vesa > [ 42880.714] (WW) Falling back to old probe method for vesa > As we can see, it correctly selected candidate i915 then reported that > it supports chips from 2000 to 5000 and still it falls back to vesa. No, it doesn't. It tries to load different drivers in order to pick the best one for the job, and the Vesa driver logs some information, just as the Intel one did before it. And then your log continues with: > [ 42880.716] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD > Graphics 3000 Which shows the intel driver has been selected. Miod
Re: Big endian options
> If one is to consider only hardware that is still being manufactured > (ie: bought new), what are our options now? The only big-endian systems you can buy new nowadays, would be Octeon-based systems. Some of them can run OpenBSD.
Re: My Cyrix CPU is a filthy rotten liar!
> On 2014-04-26, Miod Vallat wrote:
> >> The question I have is can I disable the random number generator?s use of
> >> that instruction? I?d rather be on -current than years old.
> >
> > Apart from the following hammer, I see no easy way to achieve this.
> >
> > Index: i386/machdep.c
> >===
> > RCS file: /cvs/src/sys/arch/i386/i386/machdep.c,v
> > retrieving revision 1.536
> > diff -u -p -r1.536 machdep.c
> > --- i386/machdep.c 29 Mar 2014 18:09:29 - 1.536
> > +++ i386/machdep.c 26 Apr 2014 19:13:14 -
> > @@ -1964,7 +1964,8 @@ identifycpu(struct cpu_info *ci)
> > }
> >
> > if (ci->ci_flags & CPUF_PRIMARY) {
> > - if (cpu_ecxfeature & CPUIDECX_RDRAND)
> > + if (cpu_ecxfeature & CPUIDECX_RDRAND &&
> > + vendor != CPUVENDOR_CYRIX)
> > has_rdrand = 1;
> > #ifndef SMALL_KERNEL
> > if (ci->ci_feature_sefflags & SEFF0EBX_SMAP)
> >
> >
>
> Funnily enough it's handled here:
Then this ought to work as well:
Index: i386/locore.s
===
RCS file: /cvs/src/sys/arch/i386/i386/locore.s,v
retrieving revision 1.147
diff -u -p -r1.147 locore.s
--- i386/locore.s 13 Jun 2013 02:26:53 - 1.147
+++ i386/locore.s 26 Apr 2014 21:21:01 -
@@ -401,6 +401,7 @@ try586: /* Use the `cpuid' instruction.
movl$0, RELOC(_C_LABEL(cpu_vendor))+12
movl$1,%eax
+ xorl%ecx,%ecx
cpuid
movl%eax,RELOC(_C_LABEL(cpu_id))# store cpu_id and features
movl%ebx,RELOC(_C_LABEL(cpu_miscinfo))
Re: My Cyrix CPU is a filthy rotten liar!
> The question I have is can I disable the random number generator?s use of
> that instruction? I?d rather be on -current than years old.
Apart from the following hammer, I see no easy way to achieve this.
Index: i386/machdep.c
===
RCS file: /cvs/src/sys/arch/i386/i386/machdep.c,v
retrieving revision 1.536
diff -u -p -r1.536 machdep.c
--- i386/machdep.c 29 Mar 2014 18:09:29 - 1.536
+++ i386/machdep.c 26 Apr 2014 19:13:14 -
@@ -1964,7 +1964,8 @@ identifycpu(struct cpu_info *ci)
}
if (ci->ci_flags & CPUF_PRIMARY) {
- if (cpu_ecxfeature & CPUIDECX_RDRAND)
+ if (cpu_ecxfeature & CPUIDECX_RDRAND &&
+ vendor != CPUVENDOR_CYRIX)
has_rdrand = 1;
#ifndef SMALL_KERNEL
if (ci->ci_feature_sefflags & SEFF0EBX_SMAP)
Re: OpenBSD - Linux compatibility
> to understand the purpose of the binary compats, you really have to go > way back in history. there was a time when the only way to run a > grapical browser on openbsd was to use the netscape binary under BSDi > emulation (I think it was BSDi, not 100% certain) on i386 or the solaris > binary under emulation on a sparc. there was no open source graphical > browser back then. Actually it was the SunOS 4.x binary which would be used on sparc; fgsch@ and me tried independently to run the Solaris (SunOS 5.x) binary, but it was heavily relying upon Solaris threads, and our kernel was in no way ready for that. It could probably be done nowadays, as an exercize in futility. Miod
Re: is -current broken?
> I've upgraded -current (i386, dated april 6th, 2014), and a few things > (e.g. pkg_mgr and libreoffice4.1) won't start. > > Is it intentionally broken, or the packages are just out of sync? You did not say what state you were upgrading from. Your question can't be answered without this information. Miod
Re: OpenBSD Website, multilanguage faq
I would volunteer to translate the FAQ into Bazgelootz, a language my wife and daughter and I made up over 25 years around the dinner table, but they don't use OpenBSD. Would your translation have been in Traditional Bazgelootz, or in Simplified Bazgelootz? The former could be useful to get, if only for cultural and language preservation reasons. Miod
Re: No audio
> I noticed error message on boot a while ago, but wasn't paying much > attention until right now. [...] > Using snap from today, but saw problem a good time ago, wish I had paid > attention sooner. Do you have an old dmesg from a kernel with working sound? Did you change anything in your BIOS settings? Miod
Re: OpenBSD rootkits
> and of course PAM: > > http://blackhatlibrary.net/Hooking_PAM Well, there's a reason why OpenBSD does not embed PAM. It has to do with software giving people enough rope to hang themselves.
Re: OpenBSD rootkits
> It actually should reduce the risk for set*id(), but this in the past > related to CVE-2006-6164 (_dl_unsetenv())? Yes, and this has been fixed since.
Re: OpenBSD rootkits
> Attacks with LD_PRELOAD are very old and can > be performed on any OS where you have dynamic linking (Linux, *BSD > etc.), so yes, OpenBSD is "vulnerable" to this type of stuff. You forgot to mention that the value of LD_PRELOAD is ignored for set*id executables, in order to prevent these kind of games. Miod
Re: The "unknown" in i386-unknown-openbsd5.4
> i386-donatetoopenbsdfoundationtoday-openbsd5.4? or i386-bikeshed-openbsd.
Re: restoring keyboard layout after suspend or hibernate
> Something is inconsistent here. Do you mean the uk is not the > default? Or there is a difference between mux default and new attach > default? How does one know whether plugging a keyboard in is > reattaching it or attachning a new one? There is a difference between a keyboard which can provide accurate layout information, and one which can not. The Sun USB keyboard provides accurate layout information, and will always attach with the layout computed from this information, because this matches the writings on the key caps. (and power-users know enough to override that after the keyboard has been connected) The other keyboard do not know their actual layout, and thus the keyboard driver attaches with `I'd like the default layout, please, and if there isn't, please give me the us layout'. If there has been a default layout set on the mux (with kbd or wsconsctl, or with a ``strong knowledge'' keyboard being plugged before) before this cheap keyboard attaches, then it will get that layout. Otherwise it will get the us default. There is no way to please all users here. Some people will prefer keyboards to always attach as `us' layout, and only change the international keyboard they might connect for a while, and some people, on the other hand, will expect further keyboards to reuse the last-used layout. (And that's only in console. X is another nightma^Wstory)
Re: restoring keyboard layout after suspend or hibernate
[cc: tech@, reply-to set to tech@]
> After suspend or hibernate, I lose my designated console keyboard layout
> (sv) and it reverts to the default (us?) wsconsctl shows that the
> encoding to still be sv,
>
> keyboard.encoding=sv
>
> What setting(s) am I missing to preserve the designated layout across
> suspend/hibernate?
Well, the mux is supposed to be a bit smart and remember a forced
keyboard layout (set with kbd(8) or wsconsctl keyboard.encoding), and
force it on new keyboard attachments.
Except that this only works when the `set encoding' ioctl is issued on
/dev/wskbd, not /dev/wskbd[0-9], which is what kbd(8) and wsconsctl(8)
prefer.
Fear not, for I have a diff for you (which I have been sitting on for
about two years, and only completed and debugged thanks to this
discussion)!
This diff attempts to achieve the following:
- keyboard drivers will now tell wskbd if the keyboard layout they ask
for is a default value, or a value they are 100% sure of (either
because your kernel has a XXXKBD_LAYOUT option, or because the
driver can tell the keyboard layout, e.g. by the country code on USB
keyboards which provide it, such as Sun's)
- when attaching a keyboard with a non-default layout, the layout will
become the default layout of the mux for new keyboard attachments if
the mux doesn't have a layout set already.
- when changing the keyboard layout of a particular keyboard with an
ioctl (i.e. using kbd(8) or wsconsctl(8)), the layout will become the
default layout of the mux for new keyboard attachments.
This actually allows special-casing of the WSKBDIO_SETENCODING ioctl in
the mux code to be removed.
If the above is a bit too complicated, let me provide an example.
I am booting a GENERIC kernel with a PS/2 us keyboard. The keyboard
is wskbd0, its layout is the default, ``us''.
$ wsconsctl 2>/dev/null |grep encoding
keyboard.encoding=us
Now I am plugging an icelandic USB keyboard with no country information.
It becomes wskbd1, and uses the default layout, ``us''.
$ wsconsctl 2>/dev/null |grep encoding
keyboard.encoding=us
keyboard1.encoding=us
Now I run:
$ wsconsctl keyboard1.encoding=is
keyboard1.encoding -> is
Now the PS/2 keyboard is still using the us layout, the USB keyboard is
using the icelandic layout (and I can enter thorns and eths), and the
default setting for new keyboards become icelandic:
$ wsconsctl 2>/dev/null |grep encoding
keyboard.encoding=us
keyboard1.encoding=is
I unplug the USB keyboard.
$ wsconsctl 2>/dev/null |grep encoding
keyboard.encoding=us
I plug the USB keyboard again. It will reattach with an icelandic
keyboard layout, whereas it would use the us layout without that diff:
$ wsconsctl 2>/dev/null |grep encoding
keyboard.encoding=us
keyboard1.encoding=is
Now I plug a Sun USB keyboard with the uk layout (pound sign as shift-3,
etc). Sun keyboards provide country information to the ukbd driver,
which uses it to select the matching layout.
$ wsconsctl 2>/dev/null |grep encoding
keyboard.encoding=us
keyboard1.encoding=is
keyboard2.encoding=uk
And the uk layout has become the default for new attachments. If I
unplug, then replug, the icelandic keyboard, it will reattach as wskbd1,
and it will pick the default mux layout, which is still icelandic.
$ wsconsctl 2>/dev/null |grep encoding
keyboard.encoding=us
keyboard1.encoding=is
keyboard2.encoding=uk
Now I unplug both USB keyboards...
$ wsconsctl 2>/dev/null |grep encoding
keyboard.encoding=us
... and put the machine to sleep.
$ zzz
I wake up the system, and connect back the icelandic keyboard:
$ wsconsctl 2>/dev/null |grep encoding
keyboard.encoding=us
keyboard1.encoding=is
Is this the behaviour you would like to get?
Miod
Index: arch/arm/xscale/pxa27x_kpc.c
===
RCS file: /cvs/src/sys/arch/arm/xscale/pxa27x_kpc.c,v
retrieving revision 1.2
diff -u -p -r1.2 pxa27x_kpc.c
--- arch/arm/xscale/pxa27x_kpc.c9 Feb 2013 20:36:14 - 1.2
+++ arch/arm/xscale/pxa27x_kpc.c23 Jan 2014 20:32:22 -
@@ -50,7 +50,7 @@ struct wscons_keydesc pxa27x_kpc_keydesc
};
struct wskbd_mapdata pxa27x_kpc_mapdata = {
- pxa27x_kpc_keydesctab, KB_US,
+ pxa27x_kpc_keydesctab, KB_US | KB_DEFAULT,
};
void pxa27x_kpc_cngetc(void *, u_int *, int *);
Index: arch/hp300/dev/dnkbd.c
===
RCS file: /cvs/src/sys/arch/hp300/dev/dnkbd.c,v
retrieving revision 1.18
diff -u -p -r1.18 dnkbd.c
--- arch/hp300/dev/dnkbd.c 9 Nov 2011 14:22:37 - 1.18
+++ arch/hp300/dev/dnkbd.c 23 Jan 2014 20:32:22 -
@@ -201,7 +201,7 @@ struct wskbd_mapdata dnkbd_keymapdata =
#ifdef DNKBD_LAYOUT
DNKBD_LAYOUT
#else
- KB_US
+ KB_US | KB_DEFAULT
#endif
};
Index: arch/luna88k/dev/lunaws.c
===
RCS file: /cvs/s
Re: Power consumption of various architectures
> Having used most of the architectures out there, > can you please say which of them consume most/least power > in regular operation of OpenBSD, if you have such statistics? I can't tell for the exact machines Theo is using, but here are a few values from my bunker: - VAX 4000/106 (fast vax, 100MHz processor), quite similar to the one Theo is using, two SCSI disks: about 95W. - Alpha LX164 (2nd generation alpha, 533MHz processor), with a modern (2 years old) ATX power supply, only one disk: about 85W. - SGI Fuel (700MHz R16000), original power supply: about 200W. - 1.4GHz G4 Mac mini: 40W. - SPARCstation 20, 150MHz RT625 processor, one disk: about 115W. - Sun Blade 100 (500MHz UltraSPARC-IIe): about 65W. - HP Visualize B2000 (400MHz PA-RISC): about 130W. - Lemote Fuloong 2F (800MHz): about 20W. - Plextor PX-EH160L (landisk): about 15W. Miod
Re: Request for Funding our Electricity
>And it's not full emulator if it doesn't emulate the > bugs. It's almost bedtime in Europe. Do you mind if I tell you a bedtime story? Years ago, a (back then) successful company selling high-end Unix-based workstations, having been designing its own systems and core components for years, started designing a new generation of workstations. As part of their design, they created a dedicated memory controller, which turned out to fit their hardware so well that it was reused on four other workstation motherboard designs. That memory controller had, among many registers, an arbitration register, used to configure the relative priority of onboard devices, as well as expansion slots, to acquire the data bus. Proper setting of this register is necessary to allow on-board devices and expansion slots to correctly perform DMA, while still allowing cache writeback to run and whatnot. The proper value for that register had to be decided at runtime. The recommended logic was to rely upon the minimal initialization done by the firmware, and then clear some bits and set some others depending upon what on-board devices would be present on the particular motherboard artwork, and what would be found in the various expansion slots. However, it turned out that, on the first few revisions of the memory controller, reading from this particular register was not reliable at all. Sometimes, one would read the correct value, and sometimes, one would read a completely wrong value, depending upon the recent activity occuring on the data bus. The hardware engineers could not figure out what exactly caused this. Most importantly, they could not figure out a reliable workaround to get the correct value out of this register. So they asked the software guys for help. And the company's homemade SVR4-based Unix grew a complex logic to decide, once and for all, which value to write to the register, without having to rely upon the previous value. And they told the hardware guys that it was ok not to worry about this issue anymore. OpenBSD runs on these systems, but we are not lucky enough to have all the necessary hardware documentation, and, for some of the bits in this register, we simply don't know when to set them, and when not to set them. Instead, the OpenBSD kernel still reads that register, several times, and has an ugly heuristic to decide when the value read is likely to be correct. And then we only flip the bits we know for certain we can tinker with. It's the best we can do. Assuming someone would write an emulator for that particular system: - if the ``unreliable read'' behaviour is not emulated, according to your logic, it's a bug in the emulator, which has to be fixed. - if the behaviour is emulated, how can we know it is correctly emulated, since even the designers of the chip did not spend enough time tracking down the exact conditions leading to the misbehaviour (and which bogus value would be put on the data bus). You may argue that, since the kernel has a workaround for this issue, this is a moot point. But if some developer has a better idea for the kernel heuristic, how can the new code be tested, if not on the real hardware? Miod
Re: Request for Funding our Electricity
> Yes, we remove about 10 of the architectures. We'd slowly lose the > developers who like to work on those areas. They also work in other > areas, but ... I suspect they would another BSD that supports them. Darn' tootin'! > Anyone want to suggest we hold a bake sale? Make that a lo-carb bake sale.
Re: kernel config, unremmovable driver
> however removing
>
> et*at pci?# Agere/LSI ET1310
>
>
> causes this at link stage:
>
> ld -Ttext 0xD0200120 -e start -N --warn-common -nopie -S -x -o bsd
> ${SYSTEM_HEAD} vers.o ${OBJS}
> fxp.o(.text+0x495): In function `fxp_mediachange':
> : undefined reference to `mii_phy_reset'
[...]
> Does this mean that the fxp, aue (...) ethernet drivers use
> something defined only inside the et driver?
No, this means these driver should have the `mii_phy' attribute in the
various sys/*/files* they are defined it, but don't; and as soon as all
drivers with the `mii_phy' attribute are removed from the kernel
configuration, mii_physubr.c (which contains the aforementioned
routines) is not compiled.
Re: 5.4 on a ThinkPad 760EL
> OpenBSD is getting so bloated these days, it requires > so much RAM :) Only on x86! Miod
Re: 5.4 on a ThinkPad 760EL
> I'm trying to install 5.4 on an old ThinkPad 760EL and running into some > trouble, probably due to how little RAM it has - 16 MB. [...] > I have read INSTALL.i386 and > it says that I need at least 32 MB of RAM for 5.4. [...] > Apologies if there is something obvious I should be doing. The obvious thing you should do is to add more memory to this system. The 5.4 i386 GENERIC kernel is huge and eats more than half the physical memory, and then the data structures it creates aren't free. There is basically no free memory for userland to run, and your system is swap-bound, hence horribly slow, as you have noticed. Your available options are: - run an old release, which fits in 16MB. I doubt anything >= 4.5 will fit in 16MB, so you'd use a 5+ years old, unsupported, release. - build a stripped-down kernel on another 5.4 system and run it on your ThinkPad. This ought to work, but your kernel will not be supported, so if it breaks, you get to keep both pieces. - add more memory to your system. Really. It will help. Can't you see your laptop looking at you with puppy dog eyes? - get a beefier laptop. Anything with more memory will do. Miod
Re: loongson:automatic loading of OpenBSD:YES to 8G ssd No for 500Gdisk
> PMON> vers > PMON: PMON2000 2.1 (Bonito) #14: Tue May 18 10:33:47 CST 2010 The yeeloong here runs the same version, and autoboots correctly, but its disk is only 160GB. I am not aware of anyone using >= 500GB disks in a Yeeloong, this could very well trigger a bug in Lemote's bastardisation of PMON, and prevent autoboot. Miod
Re: loongson:automatic loading of OpenBSD:YES to 8G ssd No for 500G disk
> 2. change the disk to Seagate 500g disk, install 5.4 release with same > settings. > 1)when power up the notebook, system will hung in the splash screen (Press > Tab to recover | Press Del to setup) > now hit Del, can not enter PMON prompt(nothing happend) > > 2)if power up the notebook and Press Del immediately, > monitor will show > BEV in SR set to zero. > PMON> > > now "boot /dev/fs/ext2@wd0/boot/boot" ok What is the PMON version reported by ``vers'' at the PMON> prompt? Does the system boot if you press `enter' when the system is apparently hung with the splash screen still displayed? Miod
Re: FAQ 7.3
> What should i do to have scrollback again? Scrollback is currently not supported when running frame buffer display drivers. I am not aware of plans to work on restoring this feature (although it is probably somewhere on my todolist). > Btw, to mitigate this fact, is there maybe a mode to determine the geometry > of cli framebuffer, like 80x50 or 100x40 etc? Not yet. However, there is work in progress to allow for the console font metrics to be changed at runtime, which would in turn allow different resolutions for the textmode emulation. Soon to hit a source tree near you. Miod
Re: text-mode console, wscons ignoring keyboard repeat
> On the i386 snapshots dated Oct 9 and Oct 23, I am unable to make the > text-mode console (no fancy inteldrm here) repeat keyboard input any faster > than the default. [...] > $ wsconsctl keyboard.repeat.del1=1 > keyboard.repeat.del1 -> 1 > $ wsconsctl keyboard.repeat.deln=1 > keyboard.repeat.deln -> 1 > $ echo I can still type just fine. > I can still type just fine. > > Changing the del1 and deln fields to 1 or 1000 makes no difference. I > would expect typingto be impossible when set to 1ms. Any clues as to how > I troubleshoot this one? You are probably using your USB keyboard, wskbd1, not the PS/2 keyboard, wskbd0, which might actually be the PS/2 keyboard emulation performed by the USB controller during boot. Try to use `keyboard1' instead of `keyboard'. Miod
Re: Apple keyboard backlight
> Hello again, > Is it possible to utilise the keyboard backlight found on Apple > laptops with OpenBSD? If it attaches as a set of usb devices and exposes the backlight as one of its report descriptors, then it could be controllable from OpenBSD. You might want to tinker with usbhidctl(1). Miod
Re: m88k architecture has no snapshot packages
> Relating to my post on September 12 about the SHA256 file missing for > several architectures's snapshots ( > http://marc.info/?l=openbsd-misc&m=137900173516173&w=2), I've noticed that > several other architectures' INSTALL.$arch file lists a non-existent m88k > package architecture. > I'm not sure what the correct course of rectifying this is; whether the > INSTALL.$arch file should say m68k (I'm not familiar with these > architectures) or whether there is simply no snapshot packages for m88k > (there are release packages). However I felt it best to bring it to the > attention of the group at the very least. m68k and m88k packages are still building at the moment. Miod
Re: sudo configuration !ttytickets?
> I can't say whether this is the thinking of the OpenBSD developers, > but I have seen some concerns over the years that tty_tickets gives > a false sense of security. Not to mention the annoyance. Miod
Re: Bootparamd
> Who uses bootparam? Only the Kernel? bootparam is used by network boot blocks on several machines, as well as by the kernel when booting with root on nfs. > Is Bootparamd a standard? FreeBSD has it with the same author, > there is also a Bootparamd in SunOS. I think this is important > to know for booting from other operating systems, but I dont > find this info in the man pages. It is a Sun (now Oracle) standard. Its is a very simple protocol, described in /usr/include/rpcsvc/bootparam_prot.x . > After it boots, I have the root file I gave in /etc/bootparam, > I dont need to mount it with /etc/fstab. Should I give the > root file in /etc/bootparam and leave the kernel mount the > root again? It's preferrable, especially if you want to use different mount options than the default NFS options. Also, I'd suggest, whenever possible, to add the `alldirs' option to the NFS server, and put, in the diskless client, explicit entries for /tmp, /usr and /var, so that these can get mounted as NFSv3. Otherwise, the whole / hierarchy is mounted as NFSv2 by the kernel. > The above does not happen with the swap file. To have a swap > file I have to give it in /etc/fstab. Is this due to an error > in my configuration? I think the bootparams swap file information will be used correctly (I remember seeing a fix in this area some time ago). It doesn't hurt anyway to mention it in /etc/fstab with the nfsmntpt option. Miod
Re: 11" mid-2102 i7 MacBook Air 5,1 dmesg
> > Geez, not much changed in the 89 years between now and 2102. :-) > > > > Ken > > Im the idiot from the future, 2 days ago, I thought I was running 5.4-RELEASE > on there 5.4-RELEASE will have time issues in 2102. However, 5.4-CURRENT as of now ought to run without any particular problems (assuming the hardware is still in working condition and you can still get electricity in year 2102).
Re: diff: INSTALL: etcXX: (addition of opening quotes)
> Here's an addition of opening quotes in this INSTALL file: Fixed. Thanks! Miod
Re: .shrc vs ~/.shrc
> $ . .shrc > /bin/ksh: .: .shrc: not found > $ . ~/.shrc > $ echo $SHELL > /bin/ksh > > Why is it that ksh can find ~/.shrc and '.' it, > but cannot find .shrc, which is the very same file? Because '.' is not in your $PATH. Miod
Compilers in OpenBSD
A recent discussion (``Default software in the base'') suggests using Clang/LLVM as the system compiler in OpenBSD in the short-term future. This discussion hasn't really gone anywhere, yet I thought I could waste bandwidth with my thoughts as the current de-facto compiler maintainer in OpenBSD. Mind you, I did not ask to end up maintaining the system compiler in OpenBSD. I have earned this position because I have had to fix or workaround too many bugs in gcc, as a port maintainer. And I wish I hadn't need to do this. A long time ago, in the first few years of the *BSD projects, the only free software compiler spanning the various platforms BSD systems were targeting was gcc. pcc was orphaned, TenDRA still used a cumbersome build system and did not support enough platforms, and that was about everything in the free software land. Also, gcc 2.5 (at the time) had a few bugs, but not many. You could trust it to produce working code at any optimization level, and forget about it. In other words: there was no need to put any effort in maintaining the compiler, because it was (almost) bug-free. This state of mind was valid up to the 2.7 days. The accepted wisdom was that -O2 was supposed to be followed by -fno-strength-reduce, because 2.7 had bugs in the strength reduction code, which mostly affected i386 code. And then you could trust the compiler. And then C++98 came out, as well as C99, and it was time for serious work in gcc, if only to attempt to support the new features of these standards. One may remember the schism between gcc 2.8, conservative but trying to catch up on C++98, and the ``Pentium gcc'' group, attempting to produce faster code by stretching the optimizer code beyond its limits. These projects eventually merged as gcc 2.95. From then on, a few things changed forever: - many more people were working on specific optimizations - these optimizations, unlike the 2.5/2.7 optimizer, were no longer ``almost platform-independent'', but would benefit from particularities of the target platform, leading to more code attempting to decide whether a given optimization recipe was worth applying or not. As an unavoidable consequence of this, something very important in the world order changed: gcc had bugs, and you were expected to accept that and cope with them. When I write `gcc', you can read `the compiler'. As Arthur C. Clarke would have said, ``any sufficiently optimizing compiler is indistinguishable from magic.'' So what does this tale teaches us ? First, compilers are fragile. While one would like to expect a minimum level of correctness and trustworthiness from a modern compiler, we can't, regardless of the compiler we use. Second, compilers are a moving target. Architectures without enough testers and developers start misbehaving (because they are the only ones to subtly break assumptions of the newly added optimization passes, yet 95% of the time end up producing working code, after all), and eventually get dropped. The prime example of this had been m88k, which got broken in gcc 2.95 because of a target-specific macro suddenly needed its arguments to be brace-protected, and noone had fixed the m88k backend because noone had tested/cared. This is the reason why OpenBSD ships with different compilers, depending upon the platform you are running OpenBSD on: a given release of gcc might not be suitable on a given, less popular, platform (which is not surprising for gcc since, due to benchmark^Wcompetition with other compilers, from gcc 3 onwards, the gcc developers have been eager to release ``bug free'' new versions by enforcing a policy that only ``regressions'' would get fixed, and spending more time changing their definition of ``regression'' or trying to explain why regressions weren't, so as not need to fix them in any stable release). And it is very unfortunate that gcc 2.95 does not completely implement C99, for we would have happily kept it for the older platforms, those which are not supported, or fubar (does it make any difference) with later versions. Switching from gcc to clang is worth considering, and truth is that some developers have been tinkering with that idea. This is something that may (and probably will) happen on some platforms (since llvm does not support as many platforms as OpenBSD does); but switching a subset of OpenBSD's supported platforms is not a trivial task, and a lot of work needs to happen first (such as replacing libgcc with compiler-rt, and port it to the missing platforms). And if/when such a switch happens, bugs will trigger and problems will need fixing; and we can not risk being naive enough to expect llvm developers to handle bug reports and bugfix releases any better than the gcc developers do (although we hope they will). Assuming the upstream developers fail to deliver, it's up to us to fix or workaround compiler problems as we encounter them; sometimes it's as easy as finding out which patch has been commited upstrea
Re: Java on OpenBSD 5.3
> Pretty sure it takes more than 1.7G to build Java. But then how can java people pretend it has any usefulness, besides filing disks? Miod
Re: OpenBSD Doesn't Support 64-Bit Intel
> an unlikely combination, but a 486sx with a Weitek 4167 would qualify. And OpenBSD would not run on it, because it only expects an x87-compatible FPU on such a system. > Plus... I would not be surprised if some day, someone (probably > Chinese/Taiwanese/Indian) did an embedded x86 compatible-ish chip > optimized for low price and power consumption without any FPU. Such systems already exist. You can buy newly produced 80386 clones (running way faster than 25 or 33MHz). Of course these are not intended to be used in PC-style hardware.
Re: Can't boot Loongson after upgrade from 5.2 -> 5.3 update
> An update...the bsd.rd kernel boots from / but not bsd. bsd from snapshots > also boots. Looks like there is some problem with bsd in loongson 5.3 > release. Where did you get your 5.3 release from? Did you check its md5? Miod
Re: Can't boot Loongson after upgrade from 5.2 -> 5.3
> A fresh install also doesn't boot and using PMON to boot into it fails the > same way as on the old install. Well crap. That was unexpected. If a new install fails, now that's something unexpected. Will installing 5.2 (which used to work) boot again? Miod
Re: Can't boot Loongson after upgrade from 5.2 -> 5.3
> Has anyone done a successful upgrade from Loongson 5.2 to 5.3? I've done > upgrades on numerous platforms and this is the only one I've ever had > problems with. The upgrade seemed to go fine and finish normally. After the > reboot it goes from the Lemote Dragon screen to a black screen and stops > there. I have performed many upgrades without a hitch. However, the PMON ext2fs access code is fragile, and may not load the bootblocks correctly if the boot block image gets put in a too-trick-for-retarded-code location. Of course, when this happens, PMON will happily tell you it has loaded the binary, but actually loaded garbage from different sectors than those the binary is installed in. Did I mention how high quality that PMON code is? My best advice would be to backup your system and reinstall. If this is not an option, you *might* (as in, ought to) be lucky if you ``newfs_ext2fs wd0i'' and copy /usr/mdec/boot to the root of the ext2fs filesystem (boot bsd.rd from the network; newfs_ext2fs is on the installation media filesystem, but /usr/mdec/boot isn't, you'll need to copy it from either the network or your BSD filesystem, which you can mount from bsd.rd) Miod
Re: Suspend/Resume on Lemote Yeeloong netbook
> Thank you for the reply, I have now tried suspending with 'zzz', which puts > the netbook to sleep within a second, but it will not turn back on by > pressing keys or the touchpad/touchpad buttons. > > So now the machine will not go back on, unless I assume, if I use the power > button, in which case it will come up from cold boot rather than resume. I have just checked, and this feature is indeed currently broken. This is a regression, which I need to investigate... Miod
Re: Suspend/Resume on Lemote Yeeloong netbook
> I have installed OpenBSD onto my Lemote netbook, and have apmd running on > startup. If I run the command 'zzz' the computer suspends perfectly. > However, on turning the machine back on, it boots as normal, with complains > about being uncleanly shutdown. How did you `turn the machine back on'? > On closing the lid of the netbook, the computer remains on. OpenBSD is not able to detect lid close on the Yeeloong at the moment. > So, simply put, how can I make suspend/resume work? I'm happy to run the > 'zzz' command instead of closing the lid, I'd just like to know how to make > it work at all. Suspend: zzz Resume: press any key or the touchpad. Do not touch the power button. Miod
Re: current/macppc on Mac Mini
> Were you thinking of something like that? It works for me (c) tm, with
> my PowerBooks (disk@0/wd0), I haven't tried NFS boot yet.
Not exactly, but your version is probably better than what I was
thinking of. However, it will not allow for root on the second wd disk
of a controller, or on any secondary pciide controller.
Borrowing the sparc64 logic is a larger work but less error-prone.
Miod
> Index: autoconf.c
> ===
> RCS file: /cvs/src/sys/arch/macppc/macppc/autoconf.c,v
> retrieving revision 1.39
> diff -u -p -r1.39 autoconf.c
> --- autoconf.c11 Nov 2010 17:58:21 - 1.39
> +++ autoconf.c22 May 2013 19:00:45 -
> @@ -68,7 +68,7 @@
>
> void dumpconf(void);
> static struct devmap *findtype(char **);
> -void makebootdev(char *cp);
> +void parseofwbp(char *);
> int getpno(char **);
>
> /*
> @@ -79,6 +79,9 @@ int getpno(char **);
> int cold = 1; /* if 1, still working on cold-start */
> char bootdev[16];/* to hold boot dev name */
> struct device *bootdv = NULL;
> +enum devclass bootdev_class = DV_DULL;
> +int bootdev_type = 0;
> +int bootdev_unit = 0;
>
> struct dumpmem dumpmem[VM_PHYSSEG_MAX];
> u_int ndumpmem;
> @@ -165,9 +168,9 @@ findtype(char **s)
> *'/ht@0,f200/pci@2/bcom5704@4/bsd'
> */
> void
> -makebootdev(char *bp)
> +parseofwbp(char *bp)
> {
> - int unit, ptype;
> + int ptype;
> char *dev, *cp;
> struct devmap *dp;
>
> @@ -184,6 +187,8 @@ makebootdev(char *bp)
> } while((dp->type & T_IFACE) == 0);
>
> if (dp->att && dp->type == T_IFACE) {
> + bootdev_class = DV_IFNET;
> + bootdev_type = dp->type;
> strlcpy(bootdev, dp->dev, sizeof bootdev);
> return;
> }
> @@ -193,24 +198,9 @@ makebootdev(char *bp)
> ptype = dp->type;
> dp = findtype(&cp);
> if (dp->att && dp->type == T_DISK) {
> - unit = getpno(&cp);
> - if (ptype == T_SCSI) {
> - struct device *dv;
> - struct sd_softc *sd;
> -
> - TAILQ_FOREACH(dv, &alldevs, dv_list) {
> - if (dv->dv_class != DV_DISK ||
> - strcmp(dv->dv_cfdata->cf_driver->cd_name,
> "sd"))
> - continue;
> - sd = (struct sd_softc *)dv;
> - if (sd->sc_link->target != unit)
> - continue;
> - snprintf(bootdev, sizeof bootdev,
> - "%s%c", dv->dv_xname, 'a');
> - return;
> - }
> - }
> - snprintf(bootdev, sizeof bootdev, "%s%d%c", dev, unit, 'a');
> + bootdev_class = DV_DISK;
> + bootdev_type = ptype;
> + bootdev_unit = getpno(&cp);
> return;
> }
> printf("Warning: boot device unrecognized: %s\n", bp);
> @@ -239,25 +229,44 @@ getpno(char **cp)
> void
> device_register(struct device *dev, void *aux)
> {
> + const char *drvrname = dev->dv_cfdata->cf_driver->cd_name;
> + const char *name = dev->dv_xname;
> +
> + if (bootdv != NULL || dev->dv_class != bootdev_class)
> + return;
> +
> + switch (bootdev_type) {
> + case T_SCSI:
> + if (strcmp(drvrname, "sd") == 0) {
> + struct sd_softc *sd = (struct sd_softc *)dev;
> +
> + if (sd->sc_link->target == bootdev_unit)
> + bootdv = dev;
> + }
> + case T_IDE:
> + /*
> + * Do not require the bootpath unit number to match
> + * against the driver's one, a slave disk on the ATA
> + * channel `disk@1' can attach as `wd0'.
> + */
> + if (strcmp(drvrname, "wd") == 0)
> + bootdv = dev;
> + break;
> + case T_IFACE:
> + if (strcmp(name, bootdev) == 0)
> + bootdv = dev;
> + break;
> + default:
> + break;
> + }
> }
>
> -/*
> - * Now that we are fully operational, we can checksum the
> - * disks, and using some heuristics, hopefully are able to
> - * always determine the correct root disk.
> - */
> void
> diskconf(void)
> {
> - dev_t temp;
> - int part = 0;
> -
> printf("bootpath: %s\n", bootpath);
> - makebootdev(bootpath);
>
> - /* Lookup boot device from boot if not set by configuration */
> - bootdv = parsedisk(bootdev, strlen(bootdev), 0, &temp);
> - setroot(bootdv, part, RB_USERREQ);
> + setroot(bootdv, 0, RB_USERREQ);
> dumpconf();
> }
>
> Index: machdep.c
> ===
> RCS file: /cvs/src/sys/arch/macppc/mac
Re: panic: got error 5 while accessing filesystem
> I wasn't able to find out what "error 5" is. EIO. There are probably horrible I/O error messages in your dmesg prior to this panic. > I will try disabling softdeps on that filesystem. This will indeed avoid the panic (which occurs because at this point there is no way to propagate the I/O error up to the filesystem operation which has triggered it), but that won't fix the I/O error. I'd suggest doing backups and gettting ready to replace the disk. Miod
Re: Ethernet card not working
> Hi,
>
> I inserted the card into a debian laptop which recongizes it. Here
> some output.
>
> dmesg:
> [ 149.244112] pcmcia_socket pcmcia_socket1: pccard: PCMCIA card
> inserted into slot 1
> [ 149.244234] pcmcia_socket pcmcia_socket1: cs: memory probe
> 0xa000-0xa0ff: excluding 0xa000-0xa00f
> [ 149.254856] pcmcia 1.0: pcmcia: registering new device pcmcia1.0 (IRQ: 4)
> [ 149.351576] pcnet_cs 1.0: eth0: NE2000 (DL10022 rev 30): io
> 0x320, irq 4, hw_addr 00:13:46:34:0d:62
>
> ifconfig:
> eth2 Link encap:Ethernet HWaddr 00:13:46:34:0d:62
> BROADCAST MULTICAST MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
> Interrupt:4 Base address:0x320
>
> pccardctl ident:
> Socket 1:
> product info: "D-Link
> ", "DFE-670TXD
> ", "PC Card
> ", ""
> manfid: 0x0149, 0x4530
> function: 6 (network)
>
> Is this enough? what can I provide more?
Does the following diff help?
Index: if_ne_pcmcia.c
===
RCS file: /cvs/src/sys/dev/pcmcia/if_ne_pcmcia.c,v
retrieving revision 1.95
diff -u -p -r1.95 if_ne_pcmcia.c
--- if_ne_pcmcia.c 3 Jul 2011 15:47:17 - 1.95
+++ if_ne_pcmcia.c 16 Apr 2013 20:26:47 -
@@ -296,19 +296,23 @@ const struct ne2000dev {
PCMCIA_CIS_IODATA_PCETTXR,
0, -1, { 0x00, 0xa0, 0xb0 } },
-{ PCMCIA_VENDOR_LINKSYS, PCMCIA_PRODUCT_NETGEAR_FA410TXC,
+{ PCMCIA_VENDOR_NETGEAR, PCMCIA_PRODUCT_NETGEAR_FA410TXC,
PCMCIA_CIS_DLINK_DFE670TXD,
0, -1, { 0x00, 0x05, 0x5d } },
-{ PCMCIA_VENDOR_LINKSYS, PCMCIA_PRODUCT_NETGEAR_FA410TXC,
+{ PCMCIA_VENDOR_NETGEAR, PCMCIA_PRODUCT_NETGEAR_FA410TXC,
PCMCIA_CIS_DLINK_DFE670TXD,
0, -1, { 0x00, 0x50, 0xba } },
- { PCMCIA_VENDOR_LINKSYS, PCMCIA_PRODUCT_NETGEAR_FA410TXC,
+ { PCMCIA_VENDOR_NETGEAR, PCMCIA_PRODUCT_NETGEAR_FA410TXC,
PCMCIA_CIS_DLINK_DFE670TXD,
0, -1, { 0x00, 0x0d, 0x88 } },
-{ PCMCIA_VENDOR_LINKSYS, PCMCIA_PRODUCT_NETGEAR_FA410TXC,
+{ PCMCIA_VENDOR_NETGEAR, PCMCIA_PRODUCT_NETGEAR_FA410TXC,
+ PCMCIA_CIS_DLINK_DFE670TXD,
+ 0, -1, { 0x00, 0x13, 0x46 } },
+
+{ PCMCIA_VENDOR_NETGEAR, PCMCIA_PRODUCT_NETGEAR_FA410TXC,
PCMCIA_CIS_DLINK_DFE670TXD,
0, -1, { 0x00, 0x40, 0x05 } },
Re: Disk layout: OpenBSD OT
> just wonder in a typical hard drive nowadays (SATA/SAS), the sector 0 > is in the inner or outter track ? > Which tracks are faster: the inner ones or the outter ? Only the manufacturer knows. Disks have been reporting fake geometries since more than 20 years. The electronic on the disk will do the necessary work to use the disk physical characteristic (with a varying number of sector per track) as cleverly as it can. Nowadays, you can't even be sure a given `software' is even contiguous on the disk. Just trust the disk and don't try to outsmart it, for it knows more about the actual hardware than you do. Miod
Re: Precisions on ZFS (was: Millions of files in /var/www & inode / out of space issue.)
> Please, please, please, can someone port ZFS, just to end this endless > thread...? Please someone port HAMMER instead. We are only interested in free software, with no strings attached.
Re: OpenSMTPD - thank you!
> Don't be a tease!! What's in -current? Ponies. Lots of'em.
Re: vi vs ed in bsd.rd - proposal
> The only editing available tool in bsd.rd, the infamous ed, made me sweat > cold with fear not to correctly spell its syntax or do some logic mistake. > I would have been way more lighthearted if I had vi available. Actually, vi used to be in the installation media, 15 years ago. Lack of space caused it to be removed, although for unconstrained installation media (i.e. bsd.rd or anything which does not need to fit on a floppy) it might be worth bring it back. > Btw, how many are really using ed everyday, now in 2013? I am using ed, maybe not every day, but several times a week. And I use it a lot when in the OpenBSD installer, to do some post-install setup everytime I have completed an installation (this is because I am too lazy to setup a siteXX.tgz tarball). > I believe I'm not > the only one who thinks this. My guess is that vi could be more appreciated > by most of the user base more than ed. But ed is the standard text editor. This is the only editor noone will complain about. If we start putting vi back on the installation media, it won't be long until people complain about the lack of an emacs-compatible editor. > This is the raw situation: > > /usr/bin/vi = 343320 bytes > /bin/ed = 238864 bytes > delta = 104456 bytes > > 100K of executable, when compressed, wouldn't be "that" much in terms of > difference, Except your figures are wrong. What you need to check is the output of size(1) on both binaries, and after relinking vi as a static binary, since ed is statically linked while vi is not. Now on a random system here (admittedly not an x86 one), I get: textdatabss dec hex 177074 743696252 280762 448ba /bin/ed 740510 755630772 778838 be256 /usr/bin/vi.static which is closer to 500KB of delta. A third of floppy52.fs. Miod
Re: current/macppc on Mac Mini
> Just upgraded to a current again, with the same problem, > and the same solution: [...] > wdc1 at kauaiata0 irq 39: DMA > atapiscsi0 at wdc1 channel 0 drive 0 > scsibus0 at atapiscsi0: 2 targets > cd0 at scsibus0 targ 0 lun 0: ATAPI 5/cdrom > removable > wd0 at wdc1 channel 0 drive 1: > wd0: 16-sector PIO, LBA, 76319MB, 156301488 sectors [...] > bootpath: /pci@f400/ata-6@d/disk@1:/bsd I think I understand what goes wrong. The code responsible for matching the boot device to the actual kernel device on macppc is quite crude, especially for non-SCSI disks. Your bootpath specifies `disk@1' because the disk drive is the second device (slave) on the ATA channel, the cdrom drive being master. However, the kernel wants to match this information against a `wd1' device (as if there were two hard disks on the ATA channel). The kernel code needs to be fixed to use device_register() to match the boot path against actual attachment information, instead of walking the device tree at the end of autoconf. If nobody beats me to do this, I'll try to cook a diff in a few days. Miod
Re: 5.2 bsd.rd -- panic: cannot open disk, error EINVAL
> I seem to be unable to boot from locally-compiled bsd.rd (i386). I > have triple-checked everything I'm doing against release(8) > instructions and tried both 5.2 -stable and release CVS tags; the > result is the same: "panic: cannot open disk, 0x1100/0x2f02, error 22" Let me guess. You have compiled RAMDISK, copied that to bsd.rd, and tried to boot it, didn't you? Compiling RAMDISK is not enough for it to work. You need to put a filesystem in it afterwards - this is what the machinery within src/distrib/ does. Miod
Re: *** Error 1 in /usr/src/sys/arch/amd64/compile/GENERIC.MP (Makefile:816 'copy.o')
You need to rebuild binutils first - this ought to be added to the `following -current' faq, but hasn't been added yet. Miod
Re: duplicate code
> Question: Why is there duplicate code in "bus.h" that says its not > implemented? This was added by mistake in 1.44 by accident, and noone had noticed so far. Thanks for reporting this. Miod
Re: Ubiquiti EdgeMax
> there was already some work to get Cavium based systems > supported. However, 1) Cavium is anal^Wreticent about providing documentation without strings attached, and 2) Cavium hardawre does not really fit in the $100 price range. Also, the Cavium cnMIPS cores lack a FPU, which is probably not that important if you're using them purely to route and filter packets, but can be a major PITA if you start using them as general purpose systems. Miod
Re: Ubiquiti EdgeMax
> Dual-core MIPS64 processor with hardware acceleration for packet > processing and encryption/decryption. And conveniently not giving any more details. Also, there might be no easy way to load anything but the manufacturer-provided software. > Only 99 USD, wonder if OpenBSD can run on it and take advantage of the > hardware acceleration. Without decent hardware documentation, it can't. Miod
Re: Dilemma: between OpenBSD and NetBSD
> You will find idiots on @misc. It's one of the few things not in the > FAQ. We'd rather not have idiots in the FAQ (-: Miod
Re: getty
> I would like to change /etc/ttys to get, for instance: > > ttyC3 "/usr/libexec/getty std.192600" vt220 on secure > > instead of : > > ttyC3 "/usr/libexec/getty std.9600" vt220 on secure > > Do you think i could run into problems ? As long as you are using a baud rate recognized by getty, things will still work and you won't notice a change, because wsdisplay(4) ttys ignore the terminal speed you try to configure them at.
Re: Fuloong: how to boot single user mode from pmon?
> > 2G: fixed 2F without the branch prediction bug. I am told the recent > > Yeeloong and Fuloong are fit with 2G processors. I am not even sure > > these can be told apart in software, as 2G supposedly reports itself as > > a 2F level. > > Does anybody have a piece of assembly code that triggers the branch > prediction bug reliably? I'd like to see if it breaks my machine. This errata is only lethal to kernel code. When it triggers in userland, it causes memory access faults (TLB misses) which cause the branch prediction logic to abort the bogus prediction. Therefore, only the kernel needs to be modified to not risk triggering the bug. This is done by two counter-measures: 1/ The kernel is built with the -Wa,-mfix-loongson2f-btb option, which tells the assembler to insert explicit instructions to invalidate the branch prediction cache before every `jr' instruction. 2/ The kernel exception handlers perform explicit branch prediction cache invalidation on kernel<->userland execution boundaries. If you really have some time to lose on this, you can build yourself a workaround-free kernel by following these steps: 1/ edit sys/arch/loongson/conf/Makefile.loongson to remove -Wa,-mfix-loongson2f-btb from CMACHFLAGS 2/ edit sys/arch/mips64/include/loongson2.h and change the value of COP_0_DIAG_BTB_CLEAR from 0x02 to 0 3/ config(8) a new kernel, make clean, make 4/ boot new kernel 5/ run "openssl speed -elapsed" 6/ go on a coffe break 7/ notice the machine is frozen when coming back. 8/ cycle power, restore backup kernel Miod
Re: Fuloong: how to boot single user mode from pmon?
> where are Loongson 3 based computers available? In dreamland only. > how can loongson 3 be (roughly) compared to x86 CPUs in performance? It's slower. A hell lot slower. 3A systems are running at around 1GHz. The x86 code translation stuff was benchmark-only and, to the best of my knowledge, has never been made public (with full source code and acceptable licence terms). I don't see any point in this kind of benchmark. Either you are able to recompile the x86 code on the Loongson system, and you need to compare the speed of native Loongson code versus native X86 code. Or you can only run the X86 code through the Loongson JIT-like code, and this is the least of your problems because you have no idea what the original code does and what the JIT does. Here are a few meaningless numbers: - a 1.8GHz amd64 processor is about 6 times faster than a 900MHz Loongson 2F doing md5 crypto. - the same processor is only 3 times faster doing Blowfish crypto. > Would be nice if finally some non-x86 hardware would actually be > available. It has been available for ages, and well-supported by free software as well; and I am not only speaking about loongson-based systems.
