Re: how to forward port 2222 of pf box to port 22 of internel webserver
On 05/02/14 05:34, Indunil Jayasooriya wrote: Dear ALL, I want to do ssh to a internel webserver from the outside world. ssh port 22 is running in that web server. SSH port 22 is also ruuning my Openbsd 5.4 ( 32 bit ) firewall to which I do ssh from the outside world. So I want to add a rule to access internel webserver So I decided to forward port of pf box to port 22 of internel webserver So, I added a rules like these. I Still can't access. pass in log on $wan_if inet proto tcp from any to $wan_if port \ rdr-to $webserver port 22 pass out log on $int_if inet proto tcp from any to $webserver port 22 modulate state But, I can't access Why? Not sure but what does: sysctl net.inet.ip.forwarding show? and if you are using ipv6: sysctl net.inet6.ip6.forwarding What does pfctl -sr show? Using: match in on $wan_if proto tcp to ($wan_if) port rdr-to \ $webserver port ssh and pass in on $wan_if proto tcp to ($wan_if) port flags S/SA synproxy state work for me on: OpenBSD atom.crowsons.com 5.4 GENERIC.MP#44 i386 If the above does not help run tcpdump on both interfaces and see what is / is not being passed... hth Fred
Re: Firefox tweaking
> Are you using an nvidia gpu by any chance? If so, try an > ATI or Intel if you can. There is an ATI card, as dmesg shows. I was using firefox on the same hardware but other OSes and things went on smoothly and no, I don't want to go back to those OSes. Is it right to say that hardware support for graphic card is not fully developed at this stage? I saw that ATI released some docs for older cards ( RADEON 9600 AGP?) and man talks about some acceleration support for ATI cards. Can one say that on OpenBSD there is only a subset of acceleration and 3D functions supported? Thanks.
Re: Question about Kerberos removal
> Reading current.html, I noticed that KerberosV was removed. I would like > to now why? > > Recentely (a year or two), it was update from 0.7 to 1.5 It is crap. Eventually we recognize the risk is to high. Then situations change.
Re: [patch] www/index.html
> I thought it might be nice to add a link to the Valhalla team's page. > > Index: index.html > === > RCS file: /cvs/www/index.html,v > retrieving revision 1.663 > diff -u -r1.663 index.html > --- index.html1 May 2014 14:44:22 - 1.663 > +++ index.html1 May 2014 23:18:39 - > @@ -97,6 +97,7 @@ > http://www.openntpd.org";>OpenNTPD, > http://www.opensmtpd.org";>OpenSMTPD, > http://www.openiked.org";>OpenIKED, > +http://www.libressl.org";>LibreSSL, > http://mdocml.bsd.lv";>mandoc LibReSSL is not an offering, until it is an offering. Let's chill and wait.
how to forward port 2222 of pf box to port 22 of internel webserver
Dear ALL, I want to do ssh to a internel webserver from the outside world. ssh port 22 is running in that web server. SSH port 22 is also ruuning my Openbsd 5.4 ( 32 bit ) firewall to which I do ssh from the outside world. So I want to add a rule to access internel webserver So I decided to forward port of pf box to port 22 of internel webserver So, I added a rules like these. I Still can't access. pass in log on $wan_if inet proto tcp from any to $wan_if port \ rdr-to $webserver port 22 pass out log on $int_if inet proto tcp from any to $webserver port 22 modulate state But, I can't access Why? -- Thank you Indunil Jayasooriya http://www.theravadanet.net/ http://www.siyabas.lk/sinhala_how_to_install.html - Download Sinhala Fonts
Re: Cubieboard question
On Thu, May 1, 2014 at 5:39 AM, Martin Braun wrote: > Hi > > I am a bit confused about wether Cubiebord A20 or Cubieboard 3 are > supported. > > On the http://www.openbsd.org/armv7.html it mentiones Cubieboard and > Cubieboard 2, but it also says "A20". > > Would either work on OpenBSD 5.5? > As intensive work in progress your best bet is to try with snapshots. OpenBSD 5.5 is couple of months "old". And A20 is Cubieboard 2, A1x is Cubieboard those are supported and then there's new Cubieboard 3 which is not mentioned, but always you can try to boot snapshot. > > Kind regards.
Re: Can't replace /sbin/init
"Ben Dibell" wrote: > === On Apr 30 14:40:29, thinkingrod...@gmail.com wrote: > === > === BSD has an init system. The source is there. > === > === What exactly is your problem? What do you want to do > === > === with your init that you can't do with the default install? > === > > === > Jan: A lot of things can be done in Epoch easier, actually. Especially > === > status related stuff is quite nice in Epoch, I made sure of it since > I use > === > it a lot. > === > === I still have no idea of what you want to do. > === Can you give a concrete example of what you want to do > === once you replace init with this other thing, and why? > === > === > === Not that I know what init=/bin/sh means, > === > === but how does it make anything simpler? > === > > === > It allows me to use not only any binary as init, but Linux permits > === > executable scripts with a hashbang to be run as init as well. > === > === OK, but _why_ ? > > I'll start by saying that thanks to the help of the folks on this list, I > have resolved the issue and Epoch is now building on OpenBSD and (sorta) > running, though I haven't written a config file so Epoch drops to a shell. > It was indeed to do with login_tty(). I had seen that section of code but > I didn't put the pieces together that it might do what it does. Linux > doesn't need that, so, that's where I got lost. > I appreciate all the help I was given, and I'm sorry if I was a nuisance. I didn't mean to sound mean, only to emphasize that you are expected to help yourself around here. Just understand the hostility you might get when you claim to have written a great init system that can't write to the console. In any case if you don't yet know all about process groups and sessions and controlling terminals and the rest of the arcana of the Unix process model I recommend you learn. I suppose writing an init system is a valid way to learn. OpenBSD init is about as minimal as it can get so if you don't understand what every line does you try to find out. > Jan, your question: > I started work on an init system of my own to avoid systemd in Linux back > in July 2013. It was designed to be a single-config-file, > no-deps-but-a-kernel, monolithic design, init system. > Epoch has nice status features and provides options nobody else does, but > it's binary is small and the source is not too long. I'm porting it to BSD > for a couple of reasons. > > 1. I found some folks who seem genuinely interested in Epoch on BSD, and > since I was already working on Epoch 1.1, I decided to port Epoch. > > 2. I might be using OpenBSD on some of my boxes and I'd prefer to use > Epoch even though it's unsupported, because I wrote it to be exactly what > I (not anyone else) wanted in an init system, after all. > > Again, thanks for your help everyone. > -Ben - Martin
OpenBGPD Manual Pages diff
Hasn't www@ been nuked from orbit? - In which case: http://www.openbgpd.org/manual.html --- manual.html.orig2014-05-02 02:30:13.0 +0200 +++ manual.html2014-05-02 02:34:15.0 +0200 @@ -2,7 +2,6 @@ OpenBGPD Manual Pages -mailto:w...@openbsd.org";> @@ -32,7 +31,6 @@ -mailto:w...@openbsd.org";>w...@openbsd.org $OpenBSD: manual.html,v 1.4 2004/12/22 01:40:22 david Exp $ There may be similar ghost of www@ past out there; I didn't search through everything because I'm not even quite sure if www@ really has gone the way of the dodo. regards, ropers
Re: 5.5 CDs arriving
MONTH DAY YEAR o AM HOUR MIN MAY01 2014 * PM 02 : 32 DESTINATION TIME [LOS ANGELES, CA USA] MONTH DAY YEAR o AM HOUR MIN MAY01 2014 * PM 05 : 26 PRESENT TIME MONTH DAY YEAR * AM HOUR MIN APR28 2014 o PM 09 : 22 LAST TIME DEPARTED On 5/1/14, Maurice McCarthy wrote: > 5.5 arrived Swansea, UK.
Re: Question about Kerberos removal
2014-05-01 21:14 GMT-03:00 Philip Guenther : > On Thu, May 1, 2014 at 5:09 PM, Rodrigo Mosconi > wrote: > > Reading current.html, I noticed that KerberosV was removed. I would like > > to now why? > > > > Recentely (a year or two), it was update from 0.7 to 1.5 > > What was unclear about the commit message? > > >> Log message: > >> The complexity and quality of kerberosV and the fact that almost > >> nobody is using it doesn't justify to have it in base - disable and > >> remove it. If the 2 two people who use it still want it, they can > >> make a port or recompile OpenBSD on their own. > >> > >> There is a quote in theo.c from August 2010: "basically, dung beetles > >> fucking. that's what kerberosV + openssl is like". > >> > >> Discussed with many. Tests by henning@ reyk@ and others. > >> ok deraadt@ henning@ > > > Philip Guenther > > Thanks,
Re: Question about Kerberos removal
On Thu, May 1, 2014 at 5:09 PM, Rodrigo Mosconi wrote: > Reading current.html, I noticed that KerberosV was removed. I would like > to now why? > > Recentely (a year or two), it was update from 0.7 to 1.5 What was unclear about the commit message? >> Log message: >> The complexity and quality of kerberosV and the fact that almost >> nobody is using it doesn't justify to have it in base - disable and >> remove it. If the 2 two people who use it still want it, they can >> make a port or recompile OpenBSD on their own. >> >> There is a quote in theo.c from August 2010: "basically, dung beetles >> fucking. that's what kerberosV + openssl is like". >> >> Discussed with many. Tests by henning@ reyk@ and others. >> ok deraadt@ henning@ Philip Guenther
Question about Kerberos removal
Reading current.html, I noticed that KerberosV was removed. I would like to now why? Recentely (a year or two), it was update from 0.7 to 1.5
Re: Weird disklabel problem
On 1 May 2014 14:59, Martijn Rijkeboer wrote: >> Can you provide a hex dump of the MBR Linux produces? The evidence would >> seem to point at the boot code stored in the MBR. To which I made a >> recent minor tweak. So you might also try a 5.4 install to see if it >> works. > > Below are the hexdumps of the MBR. The "before" was created with Linux and > before labeling. The "after" was created with Linux and after labeling. The > "obsd-55" was created with the OpenBSD 5.5 installer with the "whole" disk > option. The "obsd-54" was created with the OpenBSD 5.4 installer with the > "whole" disk option. > > The "before" and "after" differ only on line "1b0". The "obsd-55" and > "obsd-54" are identical. The problem occurs with all except "before". > So marking a partition as 'Active/Bootable', (the 00 -> 80 change) causes your system to hang. Apparently Linux does this when you 'Label' it. The OpenBSD installer does it for you when you select 'Whole disk'. Nothing obviously to do with the disklabel. You could test this by manually setting the 'Active' flag on the working Linux MBR. Or, conversely unsetting the flag with fdisk after the OpenBSD install but before rebooting. In either case does it get further before noticing that it can't boot? Ken > Kind regards, > > > Martijn Rijkeboer > > > > before > == > 000 05ea c000 8c07 8ec8 bcd0 fffc d88e a0b8 > 010 8e07 31c0 31f6 b9ff 0200 f3fc eaa4 0022 > 020 07a0 071e 1f0e 02b4 16cd 03a8 0a74 07b0 > 030 cbe8 8000 b40e 0101 c2f6 7580 be08 0136 > 040 afe8 b200 be80 01be 04b9 8a00 3c04 7480 > 050 830f 10c6 f5e2 6abe e801 0096 f4fb fceb > 060 d088 0f24 3004 27a2 b001 2834 a2c8 0134 > 070 be56 011a 06f6 01b4 7501 4601 73e8 5e00 > 080 c726 fe06 0001 f600 b406 0101 3175 1488 > 090 aabb b455 cd41 8a13 7214 8124 55fb 75aa > 0a0 f61e 01c1 1974 2eb0 53e8 6600 4c8b 6608 > 0b0 0e89 0112 b456 be42 010a 13cd 735e b019 > 0c0 e83b 003a 748a 8b01 024c 01b8 3102 cddb > 0d0 7313 be05 0152 81eb 7dbe e801 0014 8126 > 0e0 fe3e 5501 75aa ea05 7c00 61be e901 > 0f0 ff67 fc50 84ac 74c0 e80f 0002 f6eb 5350 > 100 0eb4 01bb cd00 5b10 c358 0010 0001 > 110 07c0 5521 6973 676e > 120 6420 6972 6576 5820 202c 6170 7472 7469 > 130 6f69 206e 0059 424d 2052 6e6f 6620 6f6c > 140 7070 2079 726f 6f20 646c 4220 4f49 0d53 > 150 000a 0a0d 6552 6461 6520 7272 726f 0a0d > 160 4e00 206f 2f4f 0d53 000a 6f4e 6120 7463 > 170 7669 2065 6170 7472 7469 6f69 0d6e 000a > 180 0090 > 190 > * > 1b0 784f b8e7 0009 2000 > 1c0 0021 fea6 0800 5800 7470 > 1d0 > * > 1f0 aa55 > 200 > > > after > = > 000 05ea c000 8c07 8ec8 bcd0 fffc d88e a0b8 > 010 8e07 31c0 31f6 b9ff 0200 f3fc eaa4 0022 > 020 07a0 071e 1f0e 02b4 16cd 03a8 0a74 07b0 > 030 cbe8 8000 b40e 0101 c2f6 7580 be08 0136 > 040 afe8 b200 be80 01be 04b9 8a00 3c04 7480 > 050 830f 10c6 f5e2 6abe e801 0096 f4fb fceb > 060 d088 0f24 3004 27a2 b001 2834 a2c8 0134 > 070 be56 011a 06f6 01b4 7501 4601 73e8 5e00 > 080 c726 fe06 0001 f600 b406 0101 3175 1488 > 090 aabb b455 cd41 8a13 7214 8124 55fb 75aa > 0a0 f61e 01c1 1974 2eb0 53e8 6600 4c8b 6608 > 0b0 0e89 0112 b456 be42 010a 13cd 735e b019 > 0c0 e83b 003a 748a 8b01 024c 01b8 3102 cddb > 0d0 7313 be05 0152 81eb 7dbe e801 0014 8126 > 0e0 fe3e 5501 75aa ea05 7c00 61be e901 > 0f0 ff67 fc50 84ac 74c0 e80f 0002 f6eb 5350 > 100 0eb4 01bb cd00 5b10 c358 0010 0001 > 110 07c0 5521 6973 676e > 120 6420 6972 6576 5820 202c 6170 7472 7469 > 130 6f69 206e 0059 424d 2052 6e6f 6620 6f6c > 140 7070 2079 726f 6f20 646c 4220 4f49 0d53 > 150 000a 0a0d 6552 6461 6520 7272 726f 0a0d > 160 4e00 206f 2f4f 0d53 000a 6f4e 6120 7463 > 170 7669 2065 6170 7472 7469 6f69 0d6e 000a > 180 0090 > 190 > * > 1b0 784f b8e7 0009 2080 > 1c0 0021 fea6 0800 5800 7470 > 1d0 > * > 1f0 aa55 > 200 > > > obsd-55 > === > 000 05ea c000 8c07 8ec8 bcd0 fffc d88e a0b8 > 010 8e07 31c0 31f6 b9ff 0200 f3fc eaa4 0022 > 020 07a0 071e 1f0e 02b4 16cd 03a8 0a74 07b0 > 030 cbe8 8000 b40e 0101 c2f6 7580 be08 0136 > 040 afe8 b200 be80 01be 04b9 8a00 3c04 7480 > 050 830f 10c6 f5e2 6abe e801 0096 f4fb fceb > 060 d088 0f24 3004 27a2 b001 2834 a2c8 0134 > 070 be56 011a 06f6 01b4 7501 4601 73e8 5e00 > 080 c726 fe06 0001 f600 b406 0101 3175 1488 > 090 aabb b455 cd41 8a13 7214 8124 55fb 75aa > 0a0 f61e 01c1 1974 2eb0 53e8 6600 4c8b 6608 > 0b0 0e89 0112 b456 be42
[patch] www/index.html
I thought it might be nice to add a link to the Valhalla team's page. Index: index.html === RCS file: /cvs/www/index.html,v retrieving revision 1.663 diff -u -r1.663 index.html --- index.html 1 May 2014 14:44:22 - 1.663 +++ index.html 1 May 2014 23:18:39 - @@ -97,6 +97,7 @@ http://www.openntpd.org";>OpenNTPD, http://www.opensmtpd.org";>OpenSMTPD, http://www.openiked.org";>OpenIKED, +http://www.libressl.org";>LibreSSL, http://mdocml.bsd.lv";>mandoc Mirrors, by country:
nitpick on faq/upgrade55.html
Hi! --- upgrade55.html.orig 2014-05-01 22:56:35.504448593 +0200 +++ upgrade55.html 2014-05-01 22:56:40.794448187 +0200 @@ -651,7 +651,7 @@ NSD strips the chroot prefix as needed.< Remove any old cron jobs that run "nsdc patch" as this is no longer needed. If you wish to write slaved zones to the readable data files, you may want -to change this for a 'nsdc-control write' job. +to change this for a 'nsd-control write' job. Check nsd_flags in /etc/rc.conf.local; NSD is now started by nsd-control(8), so nsd(8) flags are no longer available. Daniel -- LÉVAI Dániel PGP key ID = 0x83B63A8F Key fingerprint = DBEC C66B A47A DFA2 792D 650C C69B BE4C 83B6 3A8F
Re: The book of PF
On Thu, 1 May 2014, Peter N. M. Hansteen wrote: > From: Peter N. M. Hansteen > To: Andy > Cc: "misc@openbsd.org" > Date: Thu, 1 May 2014 20:40:13 > Subject: Re: The book of PF > > Andy writes: > > > When is the next edition of 'The book of PF' expected? ... > I'm deeply flattered and a bit horrified that anyone would see > my scribblings as a prerequisite for trying out an exciting new > OpenBSD feature. Well, some of us with the first two editions of the book of PF are hoping to see a pecuniary advantage here. We're hoping that, as they fade into the past, early editions will appreciate massively in value. Much as early CD releases of OpenBSD have. At least according to the prices listed at the Computer Shop of Calgary :-) -- Dennis Davis
Re: SIGBUS but no coredump [SOLVED]
On Thu, May 01, 2014 at 08:47:49PM +, Peter J. Philipp wrote: > Hi list, > > earlier I sent an email to the list complaining about SIGBUS's in a program > of mine. With the generous help from Otto Moerbeek I was able to isolate the > problem to the queue(3) SLIST_FOREACH() macros in my program that caused the > SIGBUS's. > > Basically using SLIST_FOREACH() and removing a node in the linked list causes > a use after free, which OpenBSD-current looks for and handles. The solution > to this was replacing the SLIST_FOREACH with SLIST_FOREACH_SAFE() which takes > an extra variable. Sample code that Otto pointed me to is in > /usr/src/usr.sbin/slowcgi. > > After I fixed my program it ran smoothly again on -current and the SIGBUS is > gone. I'm very grateful and thankful that my hardware indeed was not defect. > Thanks Otto! > > Have a good remaining May 1st! > > -peter I'd like to add that changes to malloc in -current triggered this. More specifically, a "light" version of J is now enabled by default, it really helps spotting bugs, as Peter experienced. -Otto
SIGBUS but no coredump [SOLVED]
Hi list, earlier I sent an email to the list complaining about SIGBUS's in a program of mine. With the generous help from Otto Moerbeek I was able to isolate the problem to the queue(3) SLIST_FOREACH() macros in my program that caused the SIGBUS's. Basically using SLIST_FOREACH() and removing a node in the linked list causes a use after free, which OpenBSD-current looks for and handles. The solution to this was replacing the SLIST_FOREACH with SLIST_FOREACH_SAFE() which takes an extra variable. Sample code that Otto pointed me to is in /usr/src/usr.sbin/slowcgi. After I fixed my program it ran smoothly again on -current and the SIGBUS is gone. I'm very grateful and thankful that my hardware indeed was not defect. Thanks Otto! Have a good remaining May 1st! -peter
Re: Firefox tweaking
previously on this list it was contributed: > It seems that I get some unresponsive behaviour, like > > intermitent scrolling, long delays for content rendering, Are you using an nvidia gpu by any chance? If so, try an ATI or Intel if you can. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___
uvm_fault
Hi, I have a problem with my GPU. When I run command startx: uvm_fault(0xfe823cb0c468, 0x278, 0, 1) -> e kernel: page fault trap, code=0 Stopped at radeon_vm_bo_add+0xaa: movq 0x278(%r15), %rax My dmesg: http://wklej.org/id/1349083/ http://krzy.ch/dmesg OpenBSD 5.5 (GENERIC.MP) #315: Wed Mar 5 09:37:46 MST 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 7959404544 (7590MB) avail mem = 7738912768 (7380MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xebf50 (18 entries) bios0: vendor American Megatrends Inc. version "P1.50" date 11/20/2013 bios0: ASRock FM2A55M-HD+ acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT MCFG HPET AAFT SSDT SSDT CRAT SSDT acpi0: wakeup devices PB2_(S4) PB3_(S4) PB4_(S4) PB5_(S4) PB6_(S4) PB7_(S4) SBAZ(S4) PS2K(S4) PS2M(S4) UAR1(S4) P0PC(S4) OHC1(S4) EHC1(S4) OHC2(S4) EHC2(S4) OHC3(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 16 (boot processor) cpu0: AMD A4-6320 APU with Radeon(tm) HD Graphics , 3793.63 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TBM,TOPEXT,ITSC,BMI1 cpu0: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 1MB 64b/line 16-way L2 cache cpu0: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.0.0.0.0, IBE cpu1 at mainbus0: apid 17 (application processor) cpu1: AMD A4-6320 APU with Radeon(tm) HD Graphics , 3793.11 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TBM,TOPEXT,ITSC,BMI1 cpu1: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 1MB 64b/line 16-way L2 cache cpu1: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 3 pa 0xfec0, version 21, 24 pins acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318180 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PB2_) acpiprt2 at acpi0: bus -1 (PB3_) acpiprt3 at acpi0: bus -1 (PB4_) acpiprt4 at acpi0: bus 1 (PB5_) acpiprt5 at acpi0: bus -1 (PB6_) acpiprt6 at acpi0: bus -1 (PB7_) acpiprt7 at acpi0: bus 2 (P0PC) acpiprt8 at acpi0: bus -1 (PE20) acpiprt9 at acpi0: bus -1 (PE21) acpiprt10 at acpi0: bus -1 (PE22) acpiprt11 at acpi0: bus -1 (PE23) acpicpu0 at acpi0: C2, PSS acpicpu1 at acpi0: C2, PSS acpibtn0 at acpi0: PWRB acpivideo0 at acpi0: VGA_ acpivideo1 at acpi0: VGA_ cpu0: 3793 MHz: speeds: 3800 3400 3000 2600 2200 1800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "AMD AMD64 15/1xh Host" rev 0x00 radeondrm0 at pci0 dev 1 function 0 "ATI Radeon HD 8370D" rev 0x00 drm0 at radeondrm0 radeondrm0: msi azalia0 at pci0 dev 1 function 1 vendor "ATI", unknown product 0x9902 rev 0x00: msi azalia0: no supported codecs ppb0 at pci0 dev 5 function 0 "AMD AMD64 15/1xh PCIE" rev 0x00: msi pci1 at ppb0 bus 1 re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x0b: RTL8168F/8111F (0x4800), msi, address bc:5f:f4:f3:1c:01 rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 5 ahci0 at pci0 dev 17 function 0 "AMD Hudson-2 SATA" rev 0x40: msi, AHCI 1.3 scsibus0 at ahci0: 32 targets sd0 at scsibus0 targ 0 lun 0: SCSI3 0/direct fixed naa.50024e92005724c6 sd0: 305245MB, 512 bytes/sector, 625142448 sectors ohci0 at pci0 dev 18 function 0 "AMD Hudson-2 USB" rev 0x11: apic 3 int 18, version 1.0, legacy support ehci0 at pci0 dev 18 function 2 "AMD Hudson-2 USB2" rev 0x11: apic 3 int 17 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 "AMD EHCI root hub" rev 2.00/1.00 addr 1 ohci1 at pci0 dev 19 function 0 "AMD Hudson-2 USB" rev 0x11: apic 3 int 18, version 1.0, legacy support ehci1 at pci0 dev 19 function 2 "AMD Hudson-2 USB2" rev 0x11: apic 3 int 17 usb1 at ehci1: USB revision 2.0 uhub1 at usb1 "AMD EHCI root hub" rev 2.00/1.00 addr 1 piixpm0 at pci0 dev 20 function 0 "AMD Hudson-2 SMBus" rev 0x14: polling iic0 at piixpm0 spdmem0 at iic0 addr 0x50: 8GB DDR3 SDRAM PC3-12800 pciide0 at pci0 dev 20 function 1 "AMD Hudson-2 IDE" rev 0x00: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility azalia1 at pci0 dev 20 function 2 "AMD Hudson-2 HD Audio" rev 0x01: apic 3 int 16 azalia1: cod
Re: Weird disklabel problem
> Did you guys see my mail yesterday ? (albeit responding to the "Problem > booting OpenBSD-current AMD64" thread) Yes I did. Sorry for the late response. > First of all I'd expect OpenBSD to create its fdisk partition on the > partition with id 3, starting at LBA offset 64. (don't know if this > changed) > Is the partition 0 starting at offset 2048 a Linux left-over ? No I did that on purpose, because when I partition the harddisk with the OpenBSD installer the system won't boot. > Anyway, my Gigabyte board used to work fine with a fdisk partition > starting at either offset 63 or 64, respectively. Not so much after > installing Linux the other day, which put the starting offset at 2048. Unfortunately this board won't start with the offset of either 63 or 64. > This happens using the on-board Intel AHCI controller. Fortunately my > board also has a non-Intel controller which does work, so being able to > use that I didn't put more time into investigating this. Unfortunately this board doesn't have a non-Intel controller. Kind regards, Martijn Rijkeboer
Re: Weird disklabel problem
> Your MBR OpenBSD partition is not flagged as active. Yes I know, but that doesn't matter for this problem.. Kind regards, Martijn Rijkeboer
signing policy
Now that 5.5 is officially released, a few notes about our signing policy. I helped devise the policy, but there are a few operational details regarding the who and the what and where I don't know (because I don't need to know). I'll do my best to answer questions, but if this email doesn't already answer them, you may be out of luck. :) What should be signed and what shouldn't? In short, we will sign "artifacts" but not general communications. Artifacts is my word for anything that we put up on the ftp sites. Releases, packages, installer ISOs, patches, etc. (We're currently transitioning from ftp to http servers, which is likely to blur the lines a bit, but the web site stuff hosted on www.openbsd.org is not an artifact.) If something looks like an artifact, you should expect it to be signed. Note packages (including firmware) carry signatures internally and are automatically verified by pkg_add. Other files are automatically verified by the installer, so the three files you will need to verify by hand are 1) the installer itself, using SHA256.sig 2) any src.tar.gz files you download, using SHA256.sig and 3) any errata patches, which contain signature lines in the header. (One exception at this time: snapshots/ports.tar.gz isn't signed.) Emails will not be signed. As you may have noticed, the recent announcement email to misc@ had some lines stripped out of it (compare with the version that arrived via tech@). Email isn't a good channel for byte precise data transmission, which would lead to spurious signature verification failures. We'd like to avoid that. If, for some reason it is necessary to send out an announcement and prove it's authentic, we'll upload it to the appropriate place and email a link. As a particular example, we're emailing out errata patches. It is still best if you download the patch from the ftp server and verify it. Of course, this applies to 5.5 and forward. 5.4 patches won't be signed.
Re: Weird disklabel problem
> Can you provide a hex dump of the MBR Linux produces? The evidence would > seem to point at the boot code stored in the MBR. To which I made a > recent minor tweak. So you might also try a 5.4 install to see if it > works. Below are the hexdumps of the MBR. The "before" was created with Linux and before labeling. The "after" was created with Linux and after labeling. The "obsd-55" was created with the OpenBSD 5.5 installer with the "whole" disk option. The "obsd-54" was created with the OpenBSD 5.4 installer with the "whole" disk option. The "before" and "after" differ only on line "1b0". The "obsd-55" and "obsd-54" are identical. The problem occurs with all except "before". Kind regards, Martijn Rijkeboer before == 000 05ea c000 8c07 8ec8 bcd0 fffc d88e a0b8 010 8e07 31c0 31f6 b9ff 0200 f3fc eaa4 0022 020 07a0 071e 1f0e 02b4 16cd 03a8 0a74 07b0 030 cbe8 8000 b40e 0101 c2f6 7580 be08 0136 040 afe8 b200 be80 01be 04b9 8a00 3c04 7480 050 830f 10c6 f5e2 6abe e801 0096 f4fb fceb 060 d088 0f24 3004 27a2 b001 2834 a2c8 0134 070 be56 011a 06f6 01b4 7501 4601 73e8 5e00 080 c726 fe06 0001 f600 b406 0101 3175 1488 090 aabb b455 cd41 8a13 7214 8124 55fb 75aa 0a0 f61e 01c1 1974 2eb0 53e8 6600 4c8b 6608 0b0 0e89 0112 b456 be42 010a 13cd 735e b019 0c0 e83b 003a 748a 8b01 024c 01b8 3102 cddb 0d0 7313 be05 0152 81eb 7dbe e801 0014 8126 0e0 fe3e 5501 75aa ea05 7c00 61be e901 0f0 ff67 fc50 84ac 74c0 e80f 0002 f6eb 5350 100 0eb4 01bb cd00 5b10 c358 0010 0001 110 07c0 5521 6973 676e 120 6420 6972 6576 5820 202c 6170 7472 7469 130 6f69 206e 0059 424d 2052 6e6f 6620 6f6c 140 7070 2079 726f 6f20 646c 4220 4f49 0d53 150 000a 0a0d 6552 6461 6520 7272 726f 0a0d 160 4e00 206f 2f4f 0d53 000a 6f4e 6120 7463 170 7669 2065 6170 7472 7469 6f69 0d6e 000a 180 0090 190 * 1b0 784f b8e7 0009 2000 1c0 0021 fea6 0800 5800 7470 1d0 * 1f0 aa55 200 after = 000 05ea c000 8c07 8ec8 bcd0 fffc d88e a0b8 010 8e07 31c0 31f6 b9ff 0200 f3fc eaa4 0022 020 07a0 071e 1f0e 02b4 16cd 03a8 0a74 07b0 030 cbe8 8000 b40e 0101 c2f6 7580 be08 0136 040 afe8 b200 be80 01be 04b9 8a00 3c04 7480 050 830f 10c6 f5e2 6abe e801 0096 f4fb fceb 060 d088 0f24 3004 27a2 b001 2834 a2c8 0134 070 be56 011a 06f6 01b4 7501 4601 73e8 5e00 080 c726 fe06 0001 f600 b406 0101 3175 1488 090 aabb b455 cd41 8a13 7214 8124 55fb 75aa 0a0 f61e 01c1 1974 2eb0 53e8 6600 4c8b 6608 0b0 0e89 0112 b456 be42 010a 13cd 735e b019 0c0 e83b 003a 748a 8b01 024c 01b8 3102 cddb 0d0 7313 be05 0152 81eb 7dbe e801 0014 8126 0e0 fe3e 5501 75aa ea05 7c00 61be e901 0f0 ff67 fc50 84ac 74c0 e80f 0002 f6eb 5350 100 0eb4 01bb cd00 5b10 c358 0010 0001 110 07c0 5521 6973 676e 120 6420 6972 6576 5820 202c 6170 7472 7469 130 6f69 206e 0059 424d 2052 6e6f 6620 6f6c 140 7070 2079 726f 6f20 646c 4220 4f49 0d53 150 000a 0a0d 6552 6461 6520 7272 726f 0a0d 160 4e00 206f 2f4f 0d53 000a 6f4e 6120 7463 170 7669 2065 6170 7472 7469 6f69 0d6e 000a 180 0090 190 * 1b0 784f b8e7 0009 2080 1c0 0021 fea6 0800 5800 7470 1d0 * 1f0 aa55 200 obsd-55 === 000 05ea c000 8c07 8ec8 bcd0 fffc d88e a0b8 010 8e07 31c0 31f6 b9ff 0200 f3fc eaa4 0022 020 07a0 071e 1f0e 02b4 16cd 03a8 0a74 07b0 030 cbe8 8000 b40e 0101 c2f6 7580 be08 0136 040 afe8 b200 be80 01be 04b9 8a00 3c04 7480 050 830f 10c6 f5e2 6abe e801 0096 f4fb fceb 060 d088 0f24 3004 27a2 b001 2834 a2c8 0134 070 be56 011a 06f6 01b4 7501 4601 73e8 5e00 080 c726 fe06 0001 f600 b406 0101 3175 1488 090 aabb b455 cd41 8a13 7214 8124 55fb 75aa 0a0 f61e 01c1 1974 2eb0 53e8 6600 4c8b 6608 0b0 0e89 0112 b456 be42 010a 13cd 735e b019 0c0 e83b 003a 748a 8b01 024c 01b8 3102 cddb 0d0 7313 be05 0152 81eb 7dbe e801 0014 8126 0e0 fe3e 5501 75aa ea05 7c00 61be e901 0f0 ff67 fc50 84ac 74c0 e80f 0002 f6eb 5350 100 0eb4 01bb cd00 5b10 c358 0010 0001 110 07c0 5521 6973 676e 120 6420 6972 6576 5820 202c 6170 7472 7469 130 6f69 206e 0059 424d 2052 6e6f 6620 6f6c 140 7070 2079 726f 6f20 646c 4220 4f49 0d53 150 000a 0a0d 6552 6461 6520 7272 726f 0a0d 160 4e00 206f 2f4f 0d53 000a 6f4e 6120 7463 170 7669 2065 6170 7472 7469 6f69 0d6e 000a 180 0090 190 * 1b0 784f 1c0 000
Re: Can't replace /sbin/init
Ye gods, I just noticed how bad my last message was formatted. My apologies.
Re: Can't replace /sbin/init
=== On Apr 30 14:40:29, thinkingrod...@gmail.com wrote: === > === BSD has an init system. The source is there. === > === What exactly is your problem? What do you want to do === > === with your init that you can't do with the default install? === > === > Jan: A lot of things can be done in Epoch easier, actually. Especially === > status related stuff is quite nice in Epoch, I made sure of it since I use === > it a lot. === === I still have no idea of what you want to do. === Can you give a concrete example of what you want to do === once you replace init with this other thing, and why? === === > === Not that I know what init=/bin/sh means, === > === but how does it make anything simpler? === > === > It allows me to use not only any binary as init, but Linux permits === > executable scripts with a hashbang to be run as init as well. === === OK, but _why_ ? I'll start by saying that thanks to the help of the folks on this list, I have resolved the issue and Epoch is now building on OpenBSD and (sorta) running, though I haven't written a config file so Epoch drops to a shell. It was indeed to do with login_tty(). I had seen that section of code but I didn't put the pieces together that it might do what it does. Linux doesn't need that, so, that's where I got lost. I appreciate all the help I was given, and I'm sorry if I was a nuisance. Jan, your question: I started work on an init system of my own to avoid systemd in Linux back in July 2013. It was designed to be a single-config-file, no-deps-but-a-kernel, monolithic design, init system. Epoch has nice status features and provides options nobody else does, but it's binary is small and the source is not too long. I'm porting it to BSD for a couple of reasons. 1. I found some folks who seem genuinely interested in Epoch on BSD, and since I was already working on Epoch 1.1, I decided to port Epoch. 2. I might be using OpenBSD on some of my boxes and I'd prefer to use Epoch even though it's unsupported, because I wrote it to be exactly what I (not anyone else) wanted in an init system, after all. Again, thanks for your help everyone. -Ben
The book of PF
Hi, When is the next edition of 'The book of PF' expected? Want to read this to fully understand the new queuing subsystem before rewriting our PFs :) Cheers, Andy.
Re: SIGBUS but no coredump?
On Thu, May 01, 2014 at 05:21:26PM +0200, Otto Moerbeek wrote: > On Thu, May 01, 2014 at 09:18:07AM -0600, Theo de Raadt wrote: > > > > On Thu, May 01, 2014 at 05:03:12PM +0200, Peter J. Philipp wrote: > > > > > > > Hi, > > > > > > > > I recently bought a new computer and it runs OpenBSD (latest snapshot, > > > > -current) natively. Everything is fine except a program I develop on > > > > and it crashes according to gdb with a SIGBUS. > > > > > > > > When I run this program on another amd64 computer (vmware fusion on mac, > > > > OpenBSD 5.5-stable), I do not get the SIGBUS's and the program behaves > > > > normally. > > > > > > > > So I'm wondering why no coredumps? SIGBUS is supposed to dump core. > > > > > > > > I have: > > > > > > > > # ls /var/crash > > > > minfree > > > > # sysctl -a|grep suid > > > > kern.nosuidcoredump=2 > > > > # ls -ld /var/crash > > > > drwxrwxrwt 2 root wheel 512 Apr 30 21:05 /var/crash > > > > > > > > is this not enough to make my program which setresuid()'s after fork, > > > > core? > > > > > > your program also has to be running in a dir where it can write. It > > > will not automatically write to /var/crash, that's for kernel dumps. > > > > Not true. He is using nosuidcoredump=2. And it appears it got broken > > a while back. > > > > I am working on something even better, but not willing to share it yet :-) > > Oops, wasn't paying attention. > > -Otto For solving one problem (debugging the program), you could run directly from within gdb or attach gdb while it's running. -Otto
OpenBSD 5.5 Released
May 1, 2014. We are pleased to announce the official release of OpenBSD 5.5. This is our 35th release on CD-ROM (and 36th via FTP). We remain proud of OpenBSD's record of more than ten years with only two remote holes in the default install. As in our previous releases, 5.5 provides significant improvements, including new features, in nearly all areas of the system: - time_t is now 64 bits on all platforms. o From OpenBSD 5.5 onwards, OpenBSD is year 2038 ready and will run well beyond Tue Jan 19 03:14:07 2038 UTC. o The entire source tree (kernel, libraries, and userland programs) has been carefully and comprehensively audited to support 64-bit time_t. o Userland programs that were changed include arp(8), bgpd(8), calendar(1), cron(8), find(1), fsck_ffs(8), ifconfig(8), ksh(1), ld(1), ld.so(1), netstat(1), pfctl(8), ping(8), rtadvd(8), ssh(1), tar(1), tmux(1), top(1), and many others, including games! o Removed time_t from network, on-disk, and database formats. o Removed as many (time_t) casts as possible. o Format strings were converted to use %lld and (long long) casts. o Uses of timeval were converted to timespec where possible. o Parts of the system that could not use 64-bit time_t were converted to use unsigned 32-bit instead, so they are good till the year 2106. o Numerous ports throughout the ports tree received time_t fixes. - Releases and packages are now cryptographically signed with the signify(1) utility. o The installer will verify all sets before installing. o Installing without verification works, but is discouraged. o Users are advised to verify the installer (bsd.rd, install55.iso, etc.) ahead of time using the signify(1) tool if available. o pkg_add(1) now only trusts signed packages by default. - Installer improvements: o The installer now supports a scriptable auto-installation method that enables unattended installation and upgrades using a response file. o Disk images which can be written to a USB flash drive (miniroot55.fs [bsd.rd only] and install55.fs [bsd.rd + unsigned sets]) are now provided for amd64 and i386. o Rewritten installboot(8) utility aiming for a unified implementation across platforms (currently used by amd64 and i386 only). o The installer now parses nwids with embedded blanks correctly. - New/extended platforms: o OpenBSD/alpha: - Multiprocessor support. o OpenBSD/aviion - First self-hosting release for 88100-based AViiON systems. o OpenBSD/armv7 replaces OpenBSD/beagle. - Improved hardware support, including: o New vmx(4) driver for VMware VMXNET3 Virtual Interface Controller devices. o New vmwpvs(4) driver for VMware Paravirtual SCSI. o New vioscsi(4) driver for VirtIO SCSI adapters. o New viornd(4) driver for VirtIO random number devices. o New ubcmtp(4) driver for Broadcom multi-touch trackpads found on newer Apple MacBook, MacBook Pro, and MacBook Air laptops. o New ugold(4) driver for TEMPer gold HID thermometers. o New ugl(4) driver for Genesys Logic based USB host-to-host adapters. o radeondrm(4) has been overhauled, including: - New port of the Radeon code in Linux 3.8.13.19. - Support for Kernel Mode Setting (KMS) including support for additional output types such as DisplayPort. - wsdisplay(4) now attaches to radeondrm(4) and provides a framebuffer console. o inteldrm(4) has been updated to Linux 3.8.13.19 notably bringing Haswell stability fixes. o Support for Intel 8 Series Ethernet with i217/i218 PHYs, and i210/i211/i354 has been added to em(4). o Support for Intel Centrino Wireless-N 2200, 2230 and 105/135 has been added to iwn(4). o Support for Areca ARC-1880, ARC-1882, ARC-1883, ARC-1223, ARC-1214, ARC-1264, and ARC-1284 has been added to arc(4). o Support for Elantech v2 touchpads in pms(4) has been fixed. o Support for 802.11a (5Ghz) has been added to wpi(4). o Workarounds for firmware stability issues have been added to wpi(4), iwi(4), and iwn(4). o Support for RT3572 chips has been added to the ral(4) driver. o Support for RTL8106E chips has been added to the re(4) driver. o Support for RTS5229 card readers has been added to rtsx(4). o Support for Microsoft XBox 360 controllers has been added to the uhid(4) driver. o Support for CoreChip RD9700 USB Ethernet devices has been added to the udav(4) driver. o Further reliability improvements regarding suspend/resume and hibernation. o Enabled IPv6 transmit TCP/UDP checksum offload in jme(4). - Generic network stack improvements: o Added vxlan(4), a virtual extensible local area network tunnel interface. o pflow(4) now sends 64 bit time values for pflowproto 10. The changed templates / flows for pflowproto 10 are
Re: SIGBUS but no coredump?
On Thu, May 01, 2014 at 09:18:07AM -0600, Theo de Raadt wrote: > > On Thu, May 01, 2014 at 05:03:12PM +0200, Peter J. Philipp wrote: > > > > > Hi, > > > > > > I recently bought a new computer and it runs OpenBSD (latest snapshot, > > > -current) natively. Everything is fine except a program I develop on > > > and it crashes according to gdb with a SIGBUS. > > > > > > When I run this program on another amd64 computer (vmware fusion on mac, > > > OpenBSD 5.5-stable), I do not get the SIGBUS's and the program behaves > > > normally. > > > > > > So I'm wondering why no coredumps? SIGBUS is supposed to dump core. > > > > > > I have: > > > > > > # ls /var/crash > > > minfree > > > # sysctl -a|grep suid > > > kern.nosuidcoredump=2 > > > # ls -ld /var/crash > > > drwxrwxrwt 2 root wheel 512 Apr 30 21:05 /var/crash > > > > > > is this not enough to make my program which setresuid()'s after fork, > > > core? > > > > your program also has to be running in a dir where it can write. It > > will not automatically write to /var/crash, that's for kernel dumps. > > Not true. He is using nosuidcoredump=2. And it appears it got broken > a while back. > > I am working on something even better, but not willing to share it yet :-) Oops, wasn't paying attention. -Otto
Re: SIGBUS but no coredump?
> On Thu, May 01, 2014 at 05:03:12PM +0200, Peter J. Philipp wrote: > > > Hi, > > > > I recently bought a new computer and it runs OpenBSD (latest snapshot, > > -current) natively. Everything is fine except a program I develop on > > and it crashes according to gdb with a SIGBUS. > > > > When I run this program on another amd64 computer (vmware fusion on mac, > > OpenBSD 5.5-stable), I do not get the SIGBUS's and the program behaves > > normally. > > > > So I'm wondering why no coredumps? SIGBUS is supposed to dump core. > > > > I have: > > > > # ls /var/crash > > minfree > > # sysctl -a|grep suid > > kern.nosuidcoredump=2 > > # ls -ld /var/crash > > drwxrwxrwt 2 root wheel 512 Apr 30 21:05 /var/crash > > > > is this not enough to make my program which setresuid()'s after fork, core? > > your program also has to be running in a dir where it can write. It > will not automatically write to /var/crash, that's for kernel dumps. Not true. He is using nosuidcoredump=2. And it appears it got broken a while back. I am working on something even better, but not willing to share it yet :-)
Re: SIGBUS but no coredump?
On Thu, May 01, 2014 at 05:03:12PM +0200, Peter J. Philipp wrote: > Hi, > > I recently bought a new computer and it runs OpenBSD (latest snapshot, > -current) natively. Everything is fine except a program I develop on > and it crashes according to gdb with a SIGBUS. > > When I run this program on another amd64 computer (vmware fusion on mac, > OpenBSD 5.5-stable), I do not get the SIGBUS's and the program behaves > normally. > > So I'm wondering why no coredumps? SIGBUS is supposed to dump core. > > I have: > > # ls /var/crash > minfree > # sysctl -a|grep suid > kern.nosuidcoredump=2 > # ls -ld /var/crash > drwxrwxrwt 2 root wheel 512 Apr 30 21:05 /var/crash > > is this not enough to make my program which setresuid()'s after fork, core? your program also has to be running in a dir where it can write. It will not automatically write to /var/crash, that's for kernel dumps. -Otto > > I also have run memtest86 from an old linux CD, it did four passes over > 15 minutes successfully, no errors. > > I'm going to send you a dmesg as well, it's patched with a patch from an > openbsd developer. But I'm upset that my program doesn't dump core. > Could this be an OS fault before I blame the hardware? > > -peter > > > OpenBSD 5.5-current (MERCURY.MP) #0: Thu May 1 15:44:26 CEST 2014 > r...@mercury.centroid.eu:/usr/src/sys/arch/amd64/compile/MERCURY.MP > real mem = 34006806528 (32431MB) > avail mem = 33092833280 (31559MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec1f0 (91 entries) > bios0: vendor American Megatrends Inc. version "1504" date 10/04/2013 > bios0: ASUS All Series > acpi0 at bios0: rev 2 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP APIC FPDT LPIT SSDT SSDT MCFG HPET SSDT SSDT BGRT > acpi0: wakeup devices PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) > RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) > RP07(S4) PXSX(S4) RP08(S4) [...] > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Xeon(R) CPU E3-1275 v3 @ 3.50GHz, 3498.42 MHz > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM > cpu0: 256KB 64b/line 8-way L2 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges > cpu0: apic clock running at 99MHz > cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE > cpu1 at mainbus0: apid 2 (application processor) > cpu1: Intel(R) Xeon(R) CPU E3-1275 v3 @ 3.50GHz, 3497.98 MHz > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM > cpu1: 256KB 64b/line 8-way L2 cache > cpu1: smt 0, core 1, package 0 > cpu2 at mainbus0: apid 4 (application processor) > cpu2: Intel(R) Xeon(R) CPU E3-1275 v3 @ 3.50GHz, 3497.98 MHz > cpu2: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM > cpu2: 256KB 64b/line 8-way L2 cache > cpu2: smt 0, core 2, package 0 > cpu3 at mainbus0: apid 6 (application processor) > cpu3: Intel(R) Xeon(R) CPU E3-1275 v3 @ 3.50GHz, 3497.98 MHz > cpu3: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM > cpu3: 256KB 64b/line 8-way L2 cache > cpu3: smt 0, core 3, package 0 > cpu4 at mainbus0: apid 1 (application processor) > cpu4: Intel(R) Xeon(R) CPU E3-1275 v3 @ 3.50GHz, 3497.98 MHz > cpu4: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM > cpu4: 256KB 64b/line 8-way L2 cache > cpu4: smt 1, core 0, package 0 > cpu5 at mainbus0: apid 3 (application processor)
SIGBUS but no coredump?
Hi, I recently bought a new computer and it runs OpenBSD (latest snapshot, -current) natively. Everything is fine except a program I develop on and it crashes according to gdb with a SIGBUS. When I run this program on another amd64 computer (vmware fusion on mac, OpenBSD 5.5-stable), I do not get the SIGBUS's and the program behaves normally. So I'm wondering why no coredumps? SIGBUS is supposed to dump core. I have: # ls /var/crash minfree # sysctl -a|grep suid kern.nosuidcoredump=2 # ls -ld /var/crash drwxrwxrwt 2 root wheel 512 Apr 30 21:05 /var/crash is this not enough to make my program which setresuid()'s after fork, core? I also have run memtest86 from an old linux CD, it did four passes over 15 minutes successfully, no errors. I'm going to send you a dmesg as well, it's patched with a patch from an openbsd developer. But I'm upset that my program doesn't dump core. Could this be an OS fault before I blame the hardware? -peter OpenBSD 5.5-current (MERCURY.MP) #0: Thu May 1 15:44:26 CEST 2014 r...@mercury.centroid.eu:/usr/src/sys/arch/amd64/compile/MERCURY.MP real mem = 34006806528 (32431MB) avail mem = 33092833280 (31559MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec1f0 (91 entries) bios0: vendor American Megatrends Inc. version "1504" date 10/04/2013 bios0: ASUS All Series acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT LPIT SSDT SSDT MCFG HPET SSDT SSDT BGRT acpi0: wakeup devices PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) PXSX(S4) RP08(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E3-1275 v3 @ 3.50GHz, 3498.42 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU E3-1275 v3 @ 3.50GHz, 3497.98 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Xeon(R) CPU E3-1275 v3 @ 3.50GHz, 3497.98 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Xeon(R) CPU E3-1275 v3 @ 3.50GHz, 3497.98 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 cpu4 at mainbus0: apid 1 (application processor) cpu4: Intel(R) Xeon(R) CPU E3-1275 v3 @ 3.50GHz, 3497.98 MHz cpu4: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM cpu4: 256KB 64b/line 8-way L2 cache cpu4: smt 1, core 0, package 0 cpu5 at mainbus0: apid 3 (application processor) cpu5: Intel(R) Xeon(R) CPU E3-1275 v3 @ 3.50GHz, 3497.98 MHz cpu5: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP
Re: Firefox tweaking
On 04/30/14 08:45, Mihai Popescu wrote:
> Hello,
>
> I am running a very recent snapshot and I want to try Firefox again (now at
> version -28.0p0). It seems that I get some unresponsive behaviour, like
> intermitent scrolling, long delays for content rendering, etc. I must say
> that I had no crash whatsoever. I am using Openbox as a window manager. I
> have no plugins or extension installed in Firefox.
>
> My dmesg is at the bottom, but I want to ask for a few tweaks for Firefox
> tuning if those are available, please. If my hardware is too weak, then I
> will go back to Chromium wich works faster for now.
I think your hw is just too weak. I've got an amd64x3 w/4G RAM, and it
is definitely showing the strain that Mozilla products put on it
I did just fire up Firefox on a little i7 laptop I recently got -- dual
core, hyperthreaded i7 chip, 8G RAM (and a tiny SSD). wow, I don't
recall firefox coming up that fast in quite some time. Guess I need to
replace my desktop now.
Nick.
> Thank you.
>
> OpenBSD 5.5-current (GENERIC) #63: Tue Apr 29 02:37:44 MDT 2014
> t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> cpu0: Intel(R) Pentium(R) 4 CPU 3.20GHz ("GenuineIntel" 686-class) 3.20 GHz
> cpu0:
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,CNXT-ID,xTPR,PERF
> real mem = 1072132096 (1022MB)
> avail mem = 1042214912 (993MB)
...
Re: 5.5 CDs arriving
5.5 arrived Swansea, UK.
Re: Resolving the Lan users hostnames
On Thu, May 1, 2014 at 1:45 AM, John D. Verne wrote: > On Wed, Apr 30, 2014 at 10:28:24AM -0400, sven falempin wrote: > > On Tue, Apr 29, 2014 at 11:43 PM, Stuart Henderson > wrote: > > > On 2014-04-28, sven falempin wrote: > > >> Reading unbound doc i saw i can insert name to be resolved but i have > > >> to each time > > > > > > configure things for unbound-control, then you can do > > > "unbond-control local_data somehost.exaple.com A 192.0.2.1". > > > > > > > would it be interesting to patch dhcpd (like Ted did) but directly > > call the unbound-control work (both are in base) ? > > using a suffix for the hostname given the default domain configured. > > > > Someone hacked together a related solution with DNSMasq, described here: > > http://www.22decembre.eu/2014/04/14/local-dns-setup-with-dnsmasq-nsd-and-unbound/ > > Thank you john , i will follow Stuart method, even if i have to maintain my own patch, the more i look into unbound the more i understand the adoption in base. Dnsmasq has some cool feature especially for windows client, but the dhcp would need a similar patch : https://bitbucket.org/Dohnuts/dnsmasq This is easy to do in unbound with the log-queries. And because dhcpd is able to push ip in table maybe unbound will in the future. -- - () ascii ribbon campaign - against html e-mail /\
Re: Weird disklabel problem
On Thu, May 01, 2014 at 09:06:49AM +0200 or thereabouts, Remco wrote: > >> fdisk before > >> > >> > >> Disk: /dev/rsd0cgeometry: 121601/255/63 [1953523055 Sectors] > >> Offset: 0 Signature: 0xAA55 > >> Starting Ending LBA Info: > >> #: id C H S - C H S [ start:size ] > >> > > - > > -- > >> 0: A6 0 32 33 - 121601 25 24 [2048: 1953519616 ] > > OpenBSD > >> 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] > >> unused > >> 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] > >> unused > >> 3: 00 0 0 0 - 0 0 0 [ 0: 0 ] > >> unused > > Did you guys see my mail yesterday ? (albeit responding to the "Problem > booting OpenBSD-current AMD64" thread) > > First of all I'd expect OpenBSD to create its fdisk partition on the > partition > with id 3, starting at LBA offset 64. (don't know if this changed) > > Is the partition 0 starting at offset 2048 a Linux left-over ? > > Anyway, my Gigabyte board used to work fine with a fdisk partition starting > at > either offset 63 or 64, respectively. Not so much after installing Linux the > other day, which put the starting offset at 2048. > > This happens using the on-board Intel AHCI controller. Fortunately my board > also has a non-Intel controller which does work, so being able to use that I > didn't put more time into investigating this. > So far as I am aware, MS then linux moved the offset due to an accidental discovery of possible performance improvements. For example: from http://www.rodsbooks.com/gdisk/advice.html Partition Alignment Issues MBR disks often use partitions that begin only on sectors that are multiples of 63. This is because modern hard disks almost always appear to have 63 sectors per cylinder in the CHS geometry scheme, and partitioning tools have traditionally begun partitions on cylinder boundaries. (Disks with other than 63 sectors per cylinder will have other sector alignments on MBR disks, of course.) Today, though, CHS geometries are largely fictions, so these partition placement rules serve no real purpose, aside from keeping old OSes and utilities happy. Some recent MBR partitioning tools, including those that ship with Windows Vista and later, therefore abandon these old rules in favor of rules that are designed to satisfy newer issues: Starting in December of 2009, disk manufacturers began introducing models that employ 4096-byte (4 KiB) physical sectors but present 512-byte logical sectors to the OS. When the OS writes eight contiguous logical sectors that make up a physical sector, the drive can simply write the new physical sector; however, whenever the OS writes just one to seven logical sectors of a physical sector, the entire physical sector must be read, modified, and re-written. RAID5 and RAID6 work by creating "stripes" of data. Each disk has many stripes, and each stripe on each disk is associated with matching stripes on the other disks. Another disk or two have stripes that record parity information for the main disks' stripes, or the parity data may be spread across all the disks. In either case, whenever any data in the matched stripes on any of the disks is changed, the parity data must be updated. In both of these cases, performance can be degraded if partitions are not properly aligned. You should first understand that modern filesystems employ data structures that are 4 KiB, or larger multiples of that amount, in size. Thus, when an OS modifies one of these filesystem data structures on a disk with a smaller logical than physical sector size or on a RAID array, performance will be optimized if the partition is aligned to match the underlying disk sector or stripe size. If the partition is not so aligned, the write operation will entail an extra read operation (for disks with 4096-byte physical sectors) or writing to two stripes even for small writes. Such operations take extra time, and so disk write performance can be impacted. Depending on the filesystem in use, performance when writing many small files to disks with 4096-byte physical sectors can be degraded by as much as a factor of 25 in benchmarks I've run-that is, an operation that takes one second on a prope! rly-aligned partition can take up to 25 seconds on a misaligned partition! (My full writeup on the issue appears on the IBM developerWorks site.) Issues surrounding RAID requirements are similar, but not as dramatic. Web sites I've consulted, such as this page on Linux hardware RAID optimization, or a Microsoft page on SQL administration, claim a 10-40% performance difference between properly aligned and misaligned partitions. Regards Moss
Re: Weird disklabel problem
On Wed, 30 Apr 2014, Martijn Rijkeboer wrote: Hello, I've got a weird disklabel related problem (or so it seems). When I partition my harddisk with fdisk and add an OpenBSD (A6) primary partition the system can still boot, but once I place a disklabel on the partition (disklabel -E sd0) I can't boot the system anymore (it freezes during the post). Your MBR OpenBSD partition is not flagged as active. (from your other e-mail:) fdisk after === Disk: /dev/rsd0cgeometry: 121601/255/63 [1953523055 Sectors] Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: id C H S - C H S [ start:size ] -- 0: A6 0 32 33 - 121601 25 24 [2048: 1953519616 ] OpenBSD 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 3: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused Regards, David
Re: Weird disklabel problem
>> fdisk before >> >> >> Disk: /dev/rsd0cgeometry: 121601/255/63 [1953523055 Sectors] >> Offset: 0 Signature: 0xAA55 >> Starting Ending LBA Info: >> #: id C H S - C H S [ start:size ] >> > - > -- >> 0: A6 0 32 33 - 121601 25 24 [2048: 1953519616 ] > OpenBSD >> 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] >> unused >> 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] >> unused >> 3: 00 0 0 0 - 0 0 0 [ 0: 0 ] >> unused Did you guys see my mail yesterday ? (albeit responding to the "Problem booting OpenBSD-current AMD64" thread) First of all I'd expect OpenBSD to create its fdisk partition on the partition with id 3, starting at LBA offset 64. (don't know if this changed) Is the partition 0 starting at offset 2048 a Linux left-over ? Anyway, my Gigabyte board used to work fine with a fdisk partition starting at either offset 63 or 64, respectively. Not so much after installing Linux the other day, which put the starting offset at 2048. This happens using the on-board Intel AHCI controller. Fortunately my board also has a non-Intel controller which does work, so being able to use that I didn't put more time into investigating this.
Re: Firefox tweaking
On Wed 30/04, Mihai Popescu wrote: > Hello, > > I am running a very recent snapshot and I want to try Firefox again (now at > version -28.0p0). It seems that I get some unresponsive behaviour, like > intermitent scrolling, long delays for content rendering, etc. I must say > that I had no crash whatsoever. I am using Openbox as a window manager. I > have no plugins or extension installed in Firefox. > Well, Firefox is undoubtedly the slowest piece of software I'm using with OpenBSD. I tried some tweaks (googling around you'll find plenty of discussion related to this point), but none of them really effective. I partially tackled the slow scrolling disabling the "smooth scrolling" (Preferences -> Advanced) and reducing the keyboard repetition rate: xset r rate 660 10 (the latter can help also with other applications which ofter redraw the whole screen, e.g. Vim when cursorline is set). My few cents -- Alessandro DE LAURENZIS [mailto:just22@gmail.com] LinkedIn: http://it.linkedin.com/in/delaurenzis
