Re: how to , apache's ' AuthType Basic '
On Mon, Dec 15, 2014 at 08:14:08PM EST, Ingo Schwarze wrote: OpenBSD base also contains nginx. That is no longer true, but nginx is available from ports. From what I can tell, Martin was talking about 5.6, where 'nginx' is still in base. Not everyone's running -current, Ingo ;^) Regards, Raf
Re: Dovecot happy on 5.6?
On 12/16/14 05:48, Rod Whitworth wrote: I have been trying out dovecot for some years and it has always had some irritating bug or limitation and I have seen a few gripes from others. It seems to have been very quiet lately so I thought I'd have another attempt to get it running whilst choosing options that look like ones to suit me. Any happy users? Absolute haters who have really tried hard? (Description of problem?) Thanx, Happy since June '12 (started with a -current and stayed with -stable since) Marc
Re: Dovecot happy on 5.6?
On 16.12.2014 05:48, Rod Whitworth wrote: Any happy users? Absolute haters who have really tried hard? (Description of problem?) Yep, running a basic setup (fdm, dovecot, roundcube, opensmtpd) on 5.6 -STABLE (and 5.5 -STABLE before that) without hassle. have a nice day Lars
Re: What happened when 5.5 met my old reliable box
On 12/16/14 06:09, Rod Whitworth wrote: On Tue, 16 Dec 2014 00:16:52 -0500, Ted Unangst wrote: On Tue, Dec 16, 2014 at 16:05, Rod Whitworth wrote: I tried 5.5 - crashes there too. 5.4 and earlier work well. Clues? I love these low power skinny boxes in my rack and I'm betting that the problem exists in all the ones I have, but I cannot take the others down until I have one to swap in. 1. connect a serial cable or something to record output. I like the idea of getting chars ready to print but how do I get the data going to the rs232 port that is on all of these boxes (luckily!) ? I missed the class that taught that trick. 8-) at the boot prompt: boot stty com0 9600 boot set tty com0 Then use cu(1) to do the rest hth Fred
Re: What happened when 5.5 met my old reliable box
Thanks much. A different approach to some others. I'll file them all because I suspect that one method will suit one problem better than others. On Tue, 16 Dec 2014 07:48:05 +0100, Adriaan wrote: From the OpenBSD FAQ: At the boot loader prompt, enter boot *set tty com0* This will tell OpenBSD to use the first serial port (often called COM1 or COMA in PC documentation) as a serial console. The default baud rate is 9600. You set the speed higher by first typing stty com0 19200 This is documented in the boot.conf man page. On your workstation you can use tip(1) as terminal emulator. You can easily record the session to file by creating a .tiprc file: beautify record='LOGS/serial-log.txt' script verbose Create the LOGS directory, add yourself to the dialer group. With something liketip -v -19200 tty00 you can then start tip. If you have an USB-Serial converter you need to use ttyU0 as mentioned in ucom(4) On Tue, Dec 16, 2014 at 7:09 AM, Rod Whitworth glis...@witworx.com wrote: On Tue, 16 Dec 2014 00:16:52 -0500, Ted Unangst wrote: On Tue, Dec 16, 2014 at 16:05, Rod Whitworth wrote: I tried 5.5 - crashes there too. 5.4 and earlier work well. Clues? I love these low power skinny boxes in my rack and I'm betting that the problem exists in all the ones I have, but I cannot take the others down until I have one to swap in. 1. connect a serial cable or something to record output. I like the idea of getting chars ready to print but how do I get the data going to the rs232 port that is on all of these boxes (luckily!) ? I missed the class that taught that trick. 8-) 2. get a video camera. smartphone should be good enough. 3. brute force. build kernels from source from 5.4 onwards. the good news is this will only take about seven kernels to find the offending commit; the bad news is building old snapshot ramdisk kernels is quite a pain. *** NOTE *** Please DO NOT CC me. I am subscribed to the list. Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. Rod/ --- This life is not the real thing. It is not even in Beta. If it was, then OpenBSD would already have a man page for it. *** NOTE *** Please DO NOT CC me. I am subscribed to the list. Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. Rod/ --- This life is not the real thing. It is not even in Beta. If it was, then OpenBSD would already have a man page for it.
Re: Dell R630 high interrupts on acpi0
On 16.12.2014. 6:16, Jonathan Matthew wrote:
On Sun, Dec 14, 2014 at 06:22:37PM +0100, Hrvoje Popovski wrote:
Hi all,
I have got two new Dell R630 and have current on them from Sun Dec
14 15:07:17. Installation went great and very fast.
The problem is that I see around 11k interrupts on acpi0. First I
thought that problem is similar to this thread
http://marc.info/?l=openbsd-miscm=140551906923931w=2
But if in dell bios system profile settings is set to performance or
to DAPC there are always interrupts on acpi0.
In links bellow you can find acpidump and dmesg from performance and
DAPC settings in dell bios.
We just got some r630s too, so I spent some time last week figuring out what's
going on here. Something in the AML wants to talk to the intel MEI device.
Normally this works, but on the new generation of dell machines (we've seen it
on r630s and r730s), it's been moved outside the pci memory range we currently
allow on amd64. You can see this in your dmesgs:
0:22:0: mem address conflict 0x3303000/0x10
0:22:1: mem address conflict 0x3302000/0x10
The interrupt will keep triggering until it manages to talk to the device,
which will never happen.
kettenis@ says we can get the pci memory range information we need to deal with
this from acpi. Until that happens, expanding the allowed pci memory range
makes things work properly.
ok?
Index: pci_machdep.c
===
RCS file: /cvs/src/sys/arch/amd64/pci/pci_machdep.c,v
retrieving revision 1.59
diff -u -p -u -p -r1.59 pci_machdep.c
--- pci_machdep.c 19 Apr 2014 11:53:42 - 1.59
+++ pci_machdep.c 16 Dec 2014 04:21:53 -
@@ -622,13 +622,17 @@ pci_init_extents(void)
* here. As long as vendors continue to support
* 32-bit operating systems, we should never see BARs
* outside that region.
+*
+* Dell 13G servers have important devices outside the
+* 36-bit address space. Until we can extract the address
+* ranges from acpi, expand the allowed range to suit.
*/
pcimem_ex = extent_create(pcimem, 0, 0xUL,
M_DEVBUF, NULL, 0, EX_NOWAIT);
if (pcimem_ex == NULL)
return;
- extent_alloc_region(pcimem_ex, 0x10UL,
- 0xfff0UL, EX_NOWAIT);
+ extent_alloc_region(pcimem_ex, 0x400UL,
+ 0xfc00UL, EX_NOWAIT);
for (bmp = bios_memmap; bmp-type != BIOS_MAP_END; bmp++) {
/*
Hi,
you patch makes acpi0 calm as overeaten grandad :)
Thank you.
vmstat without your patch
# vmstat -i
interrupt total rate
irq0/clock 103588029 799
irq0/ipi 1025960
irq144/acpi0 157993005512201
irq96/mfii0 69380
irq114/em0 2702502
irq99/ehci0 1310
irq99/ehci1280
Total 168389802713004
vmstat with your patch
# vmstat -i
interrupt total rate
irq0/clock 848873 800
irq0/ipi14085 13
irq144/acpi030
irq96/mfii0 22352
irq114/em0 36853
irq99/ehci0560
irq99/ehci1280
Total 868965 819
Re: What happened when 5.5 met my old reliable box
On Tue, 16 Dec 2014 21:22:35 +1100, Rod Whitworth wrote: Thanks much. A different approach to some others. I'll file them all because I suspect that one method will suit one problem better than others. On Tue, 16 Dec 2014 07:48:05 +0100, Adriaan wrote: From the OpenBSD FAQ: At the boot loader prompt, enter boot *set tty com0* This will tell OpenBSD to use the first serial port (often called COM1 or COMA in PC documentation) as a serial console. The default baud rate is 9600. You set the speed higher by first typing stty com0 19200 This is documented in the boot.conf man page. On your workstation you can use tip(1) as terminal emulator. You can easily record the session to file by creating a .tiprc file: beautify record='LOGS/serial-log.txt' script verbose Create the LOGS directory, add yourself to the dialer group. With something liketip -v -19200 tty00 you can then start tip. If you have an USB-Serial converter you need to use ttyU0 as mentioned in ucom(4) On Tue, Dec 16, 2014 at 7:09 AM, Rod Whitworth glis...@witworx.com wrote: On Tue, 16 Dec 2014 00:16:52 -0500, Ted Unangst wrote: On Tue, Dec 16, 2014 at 16:05, Rod Whitworth wrote: I tried 5.5 - crashes there too. 5.4 and earlier work well. Clues? I love these low power skinny boxes in my rack and I'm betting that the problem exists in all the ones I have, but I cannot take the others down until I have one to swap in. 1. connect a serial cable or something to record output. I like the idea of getting chars ready to print but how do I get the data going to the rs232 port that is on all of these boxes (luckily!) ? I missed the class that taught that trick. 8-) 2. get a video camera. smartphone should be good enough. 3. brute force. build kernels from source from 5.4 onwards. the good news is this will only take about seven kernels to find the offending commit; the bad news is building old snapshot ramdisk kernels is quite a pain. *** NOTE *** Please DO NOT CC me. I am subscribed to the list. Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. Rod/ --- This life is not the real thing. It is not even in Beta. If it was, then OpenBSD would already have a man page for it. *** NOTE *** Please DO NOT CC me. I am subscribed to the list. Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. Rod/ --- This life is not the real thing. It is not even in Beta. If it was, then OpenBSD would already have a man page for it. *** NOTE *** Please DO NOT CC me. I am subscribed to the list. Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. Rod/ --- This life is not the real thing. It is not even in Beta. If it was, then OpenBSD would already have a man page for it.
Re: Dovecot happy on 5.6?
On Tue, 16 Dec 2014 01:11:34 -0500, Brad Smith wrote: On 12/15/14 23:48, Rod Whitworth wrote: I have been trying out dovecot for some years and it has always had some irritating bug or limitation and I have seen a few gripes from others. It seems to have been very quiet lately so I thought I'd have another attempt to get it running whilst choosing options that look like ones to suit me. It's been quiet because the bugs in OpenBSD were fixed and it just works. It works fine for tons of people. That looks like a unanimous vote. Thank you all! *** NOTE *** Please DO NOT CC me. I am subscribed to the list. Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. Rod/ --- This life is not the real thing. It is not even in Beta. If it was, then OpenBSD would already have a man page for it.
Re: Dell R630 high interrupts on acpi0
Date: Tue, 16 Dec 2014 15:16:58 +1000
From: Jonathan Matthew jonat...@d14n.org
On Sun, Dec 14, 2014 at 06:22:37PM +0100, Hrvoje Popovski wrote:
Hi all,
I have got two new Dell R630 and have current on them from Sun Dec
14 15:07:17. Installation went great and very fast.
The problem is that I see around 11k interrupts on acpi0. First I
thought that problem is similar to this thread
http://marc.info/?l=openbsd-miscm=140551906923931w=2
But if in dell bios system profile settings is set to performance or
to DAPC there are always interrupts on acpi0.
In links bellow you can find acpidump and dmesg from performance and
DAPC settings in dell bios.
We just got some r630s too, so I spent some time last week figuring out what's
going on here. Something in the AML wants to talk to the intel MEI device.
Normally this works, but on the new generation of dell machines (we've seen it
on r630s and r730s), it's been moved outside the pci memory range we currently
allow on amd64. You can see this in your dmesgs:
0:22:0: mem address conflict 0x3303000/0x10
0:22:1: mem address conflict 0x3302000/0x10
The interrupt will keep triggering until it manages to talk to the device,
which will never happen.
kettenis@ says we can get the pci memory range information we need to deal
with
this from acpi. Until that happens, expanding the allowed pci memory range
makes things work properly.
ok?
ok kettenis@ (although I'd prefer if you did a s/acpi/ACPI/ in the comment).
Index: pci_machdep.c
===
RCS file: /cvs/src/sys/arch/amd64/pci/pci_machdep.c,v
retrieving revision 1.59
diff -u -p -u -p -r1.59 pci_machdep.c
--- pci_machdep.c 19 Apr 2014 11:53:42 - 1.59
+++ pci_machdep.c 16 Dec 2014 04:21:53 -
@@ -622,13 +622,17 @@ pci_init_extents(void)
* here. As long as vendors continue to support
* 32-bit operating systems, we should never see BARs
* outside that region.
+ *
+ * Dell 13G servers have important devices outside the
+ * 36-bit address space. Until we can extract the address
+ * ranges from acpi, expand the allowed range to suit.
*/
pcimem_ex = extent_create(pcimem, 0, 0xUL,
M_DEVBUF, NULL, 0, EX_NOWAIT);
if (pcimem_ex == NULL)
return;
- extent_alloc_region(pcimem_ex, 0x10UL,
- 0xfff0UL, EX_NOWAIT);
+ extent_alloc_region(pcimem_ex, 0x400UL,
+ 0xfc00UL, EX_NOWAIT);
for (bmp = bios_memmap; bmp-type != BIOS_MAP_END; bmp++) {
/*
Re: Dovecot happy on 5.6?
Quoting Rod Whitworth glis...@witworx.com: I have been trying out dovecot for some years and it has always had some irritating bug or limitation and I have seen a few gripes from others. It seems to have been very quiet lately so I thought I'd have another attempt to get it running whilst choosing options that look like ones to suit me. Any happy users? Absolute haters who have really tried hard? (Description of problem?) Thanx, *** NOTE *** Please DO NOT CC me. I am subscribed to the list. Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. Rod/ --- This life is not the real thing. It is not even in Beta. If it was, then OpenBSD would already have a man page for it. I am a very very happy dovecot user -- works great with ypldap, webmail, etc. Vijay Sankar, M.Eng., P.Eng. ForeTell Technologies Limited vsan...@foretell.ca - This message was sent using ForeTell-POST 4.9
DigitalOcean's BSD debut is FreeBSD only
Hi, It seems that DigitalOcean's BSD debut is going to be FreeBSD only. We, in the OpenBSD community, are being asked to open up a separate UserVoice vote for OpenBSD -- despite the fact that we've worked so hard to promote the existing one. So, please drop by and share your frustrations: https://digitalocean.uservoice.com/forums/136585-digitalocean/suggestions/3232571-support-bsd-os -- I reckon around half the votes are from OpenBSD users. Many thanks! O.D.
Re: DigitalOcean's BSD debut is FreeBSD only
On Tue, Dec 16, 2014 at 03:10:00PM +, openda...@hushmail.com wrote: Plonk.
Re: DigitalOcean's BSD debut is FreeBSD only
What is digital ocean? On Tue, 16 Dec 2014, openda...@hushmail.com wrote: Hi, It seems that DigitalOcean's BSD debut is going to be FreeBSD only. We, in the OpenBSD community, are being asked to open up a separate UserVoice vote for OpenBSD -- despite the fact that we've worked so hard to promote the existing one. So, please drop by and share your frustrations: https://digitalocean.uservoice.com/forums/136585-digitalocean/suggestions/3232571-support-bsd-os -- I reckon around half the votes are from OpenBSD users. Many thanks! O.D.
Re: DigitalOcean's BSD debut is FreeBSD only
What is digital ocean? They're touted as the new rock stars of the hosting industry. Cheap SSD-enabled cloud hosting for your apps. You do have apps don't you? O.D. On 16. desember 2014 at 3:43 PM, Richard E. Thornton thornton.rich...@gmail.com wrote: What is digital ocean? On Tue, 16 Dec 2014, openda...@hushmail.com wrote: Hi, It seems that DigitalOcean's BSD debut is going to be FreeBSD only. We, in the OpenBSD community, are being asked to open up a separate UserVoice vote for OpenBSD -- despite the fact that we've worked so hard to promote the existing one. So, please drop by and share your frustrations: https://digitalocean.uservoice.com/forums/136585- digitalocean/suggestions/3232571-support-bsd-os -- I reckon around half the votes are from OpenBSD users. Many thanks! O.D.
Re: DigitalOcean's BSD debut is FreeBSD only
On 16.12.2014 16:52, openda...@hushmail.com wrote: What is digital ocean? They're touted as the new rock stars of the hosting industry. Says who? Now it's digital ocean - next month it will be somebody else. Cheap SSD-enabled cloud hosting for your apps. You do have apps don't you? I seem to fall out of the target group for this. As I don't share your obvious enthusiasm and just don't care - so many rock stars rise and fall. Lars
Re: DigitalOcean's BSD debut is FreeBSD only
Hi OD, On 16 December 2014 at 07:10, openda...@hushmail.com wrote: Hi, It seems that DigitalOcean's BSD debut is going to be FreeBSD only. We, in the OpenBSD community, are being asked to open up a separate UserVoice vote for OpenBSD -- despite the fact that we've worked so hard to promote the existing one. So, please drop by and share your frustrations: I have not personally tested openBSD on https://www.vultr.com/ but I have read (tweets, probably) that it will work. https://digitalocean.uservoice.com/forums/136585-digitalocean/suggestions/3232571-support-bsd-os -- I reckon around half the votes are from OpenBSD users. Many thanks! O.D. Best, Jungle -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si
support update
# This version of the template is a bib-like file with one # line per field except notes, which can be any number of lines. # All I want to get back from you is lines like these (minus the # # character and the tab indent): # 0 This line is a delimiter and must be first (digit zero at the start) # C USA # P Arizona # T Cactus Grove # Z Postal Code # A General Delivery # O Acme Widgets # I Wile E. Coyote # M w.coy...@acme.com # U http://www.acme.com/openbsd # B 555-555-1212 # X 555-555-1213 # N Home of the best Acme # widgets around. # # Do not bother sending this in unless your web site's main page clearly shows # that you are engaged in providing support services for OpenBSD. # We reserve the right to delete listings that no longer do so. # # DELETE ALL # COMMENT LINES BEFORE SUBMITTING # # SEND AS PLAIN TEXT IN THE BODY OF YOUR MAIL: NO MIME OR ATTACHMENTS! # Use html character entities (like egrave;) for accented characters. # We reserve the right to edit any and all submissions as we please. 0 C Canada P Alberta T Edmonton Z T6A-2P7 O Neotext I Duncan Patton a Campbell A 10908-65a st. M campb...@neotext.ca U http://www.neotext.com/ # with trailing slash unless a specific resource B 780 466 0109 X 780 469 0930 N Open Systems Integration and Reverse-Engineering, Legacy Sytems, RealTime AI, Air Traffic Control, Remote Sensing, TestBed/Laboratory Development, Remote/Onsite Support, Wireless, RFID, Tracking/Mapping Systems, Barcoding, Inventory/supply-line, SAP integration, C3I, Web Catalogs, Competitive Intelligence Search Engines, Risk AssessmentReduction, Motorola, Intermec, Symbol devices. UNIX -- OpenBSD, FreeBSD, HPUX, Solaris/SunOS in Industrial Environments. And PCs: (Minix, Desqview, QNX) 30+ years experience, competence and integrity. secure(ish) contact point -- https://neotext.ca/cgi-bin/getxt -- Ne obliviscaris, vix ea nostra voco.
Re: DigitalOcean's BSD debut is FreeBSD only
On 16.12.2014 17:25, jungle Boogie wrote: I have not personally tested openBSD on https://www.vultr.com/ but I have read (tweets, probably) that it will work. There are quite a few of them. https://www.transip.eu/vps/ officially support OpenBSD and FreeBSD. Also completely SSD enabled. It seems to be just hype Lars
Re: Problem With Default Route Over IPSEC Site-To-Site Tunnel VPN
I was able to resolve my own problem.
The solution I found was to create a gre tunnel between the two routers
using the gre(4) pseudo-device. Once I had that working, I used IPSEC
transport mode to protect the GRE tunnel. This method eliminates all default
encap routes from both routers; which was the root cause of the problem.
-Joe
-Original Message-
From: Joe Crivello [mailto:josephcrive...@gmail.com]
Sent: Monday, December 15, 2014 2:24 PM
Subject: Problem With Default Route Over IPSEC Site-To-Site Tunnel VPN
Hello,
I am having a problem with a particular aspect of my attempt to establish an
IPSEC site-to-site tunnel between two gateways using ISAKMPD/IKEv1. I seem
to be doing something wrong, but I have exhausted all of the resources that
I know of in my quest to fix the problem (MAN pages, OpenBSD.org FAQ,
Google, etc). I am hoping that someone with more OpenBSD experience than
myself will be able to help me... either way, thanks so much for your time!
The routers in question both run OpenBSD 5.6, situated at either end of long
range wifi bridge link. Router 1 also has a interface connecting to an ISP
router, which provides a route to the Internet:
Internet == Router 1
172.16.5.1
||
Wifi
||
172.16.5.2
Router 2 == Local Networks
(172.16.6.1/24, 172.16.7.1/24)
The intention is to establish an IPSEC tunnel between Router 1 and Router 2,
over which Router 2 should send all traffic not destined for one of it's
local networks. Accordingly, I set the default route of Router 2 to
172.16.5.1, and I configured the tunnel like so:
## Router 1
ike passive esp \
from any to { 172.16.5.2/32, 172.16.6.0/24, 172.16.7.0/24 } \
local 172.16.5.1 peer 172.16.5.2 \
main auth hmac-sha2-512 enc aes-256 group modp2048 \
quick auth hmac-sha2-512 enc aes-256-ctr group modp2048 \
srcid SNIP: Router 1 \
dstid SNIP: Router 2
## Router 2
ike active esp \
from { 172.16.5.2/32, 172.16.6.0/24, 172.16.7.0/24 } to any \
local 172.16.5.2 peer 172.16.5.1 \
main auth hmac-sha2-512 enc aes-256 group modp2048 \
quick auth hmac-sha2-512 enc aes-256-ctr group modp2048 \
srcid SNIP: Router 2 \
dstid SNIP: Router 1
This configuration (correctly) causes six SAs to be established:
## Router 1
# ipsecctl -sa
FLOWS:
flow esp in from 172.16.5.2 to 0.0.0.0/0 peer 172.16.5.2 srcid SNIP:
Router 1 dstid SNIP: Router 2 type use flow esp out from 0.0.0.0/0 to
172.16.5.2 peer 172.16.5.2 srcid SNIP:
Router 1 dstid SNIP: Router 2 type require flow esp in from 172.16.7.0/24
to 0.0.0.0/0 peer 172.16.5.2 srcid SNIP:
Router 1 dstid SNIP: Router 2 type use flow esp out from 0.0.0.0/0 to
172.16.7.0/24 peer 172.16.5.2 srcid SNIP:
Router 1 dstid SNIP: Router 2 type require flow esp in from 172.16.6.0/24
to 0.0.0.0/0 peer 172.16.5.2 srcid SNIP:
Router 1 dstid SNIP: Router 2 type use flow esp out from 0.0.0.0/0 to
172.16.6.0/24 peer 172.16.5.2 srcid SNIP:
Router 1 dstid SNIP: Router 2 type require
SAD:
esp tunnel from 172.16.5.2 to 172.16.5.1 spi 0x0eec4a02 auth hmac-sha2-512
enc aes-256-ctr esp tunnel from 172.16.5.1 to 172.16.5.2 spi 0x1cde0906 auth
hmac-sha2-512 enc aes-256-ctr esp tunnel from 172.16.5.2 to 172.16.5.1 spi
0x6769c99e auth hmac-sha2-512 enc aes-256-ctr esp tunnel from 172.16.5.2 to
172.16.5.1 spi 0xad29e69c auth hmac-sha2-512 enc aes-256-ctr esp tunnel from
172.16.5.1 to 172.16.5.2 spi 0xaf8c3502 auth hmac-sha2-512 enc aes-256-ctr
esp tunnel from 172.16.5.1 to 172.16.5.2 spi 0xcdad877e auth hmac-sha2-512
enc aes-256-ctr
## Router 2
# ipsecctl -sa
FLOWS:
flow esp in from 0.0.0.0/0 to 172.16.5.2 peer 172.16.5.1 srcid SNIP:
Router 2 dstid SNIP: Router 1 type use flow esp out from 172.16.5.2 to
0.0.0.0/0 peer 172.16.5.1 srcid SNIP:
Router 2 dstid SNIP: Router 1 type require flow esp in from 0.0.0.0/0 to
172.16.7.0/24 peer 172.16.5.1 srcid SNIP:
Router 2 dstid SNIP: Router 1 type use flow esp out from 172.16.7.0/24 to
0.0.0.0/0 peer 172.16.5.1 srcid SNIP:
Router 2 dstid SNIP: Router 1 type require flow esp in from 0.0.0.0/0 to
172.16.6.0/24 peer 172.16.5.1 srcid SNIP:
Router 2 dstid SNIP: Router 1 type use flow esp out from 172.16.6.0/24 to
0.0.0.0/0 peer 172.16.5.1 srcid SNIP:
Router 2 dstid SNIP: Router 1 type require
SAD:
esp tunnel from 172.16.5.2 to 172.16.5.1 spi 0x0eec4a02 auth hmac-sha2-512
enc aes-256-ctr esp tunnel from 172.16.5.1 to 172.16.5.2 spi 0x1cde0906 auth
hmac-sha2-512 enc aes-256-ctr esp tunnel from 172.16.5.2 to 172.16.5.1 spi
0x6769c99e auth hmac-sha2-512 enc aes-256-ctr esp tunnel from 172.16.5.2 to
172.16.5.1 spi 0xad29e69c auth hmac-sha2-512 enc aes-256-ctr esp tunnel from
172.16.5.1 to 172.16.5.2 spi 0xaf8c3502 auth hmac-sha2-512 enc aes-256-ctr
esp tunnel from 172.16.5.1 to 172.16.5.2 spi 0xcdad877e auth hmac-sha2-512
enc aes-256-ctr
The problem is that as soon as these flows are
Re: DigitalOcean's BSD debut is FreeBSD only
Hi, On 16. desember 2014 at 4:17 PM, Lars li...@srdn.de wrote: Says who? Now it's digital ocean - next month it will be somebody else. I seem to fall out of the target group for this. As I don't share your obvious enthusiasm and just don't care - so many rock stars rise and fall. There's never been anyone as cheap, as well-designed and as quickly growing as DigitalOcean. Call them The Beatles, The Bob Marley and the Wailers or what have you. I wrote this thread for the people who do care, and I know a lot of you are lurking out there. O.D.
Re: DigitalOcean's BSD debut is FreeBSD only
Hi, On 16. desember 2014 at 4:20 PM, jungle Boogie jungleboog...@gmail.com wrote: I have not personally tested openBSD on https://www.vultr.com/ but I have read (tweets, probably) that it will work. I'm not so sure about Vultr. Icelandic Greenqloud (https://www.greenqloud.com/) are nice though. O.D.
Re: DigitalOcean's BSD debut is FreeBSD only
Thanks for sharing this. This is awesome, best news in all day. I was using Debian but when this is ready, I will use FreeBSD. If you're a student I invite you to join ( https://education.github.com/pack ), you get $100 in DO credit. On Tue, Dec 16, 2014 at 8:10 AM, openda...@hushmail.com wrote: Hi, It seems that DigitalOcean's BSD debut is going to be FreeBSD only. We, in the OpenBSD community, are being asked to open up a separate UserVoice vote for OpenBSD -- despite the fact that we've worked so hard to promote the existing one. So, please drop by and share your frustrations: https://digitalocean.uservoice.com/forums/136585-digitalocean/suggestions/3232571-support-bsd-os -- I reckon around half the votes are from OpenBSD users. Many thanks! O.D.
Re: DigitalOcean's BSD debut is FreeBSD only
On Tue, Dec 16, 2014 at 05:21:16PM +, openda...@hushmail.com wrote: Hi, On 16. desember 2014 at 4:44 PM, Lars li...@srdn.de wrote: There are quite a few of them. https://www.transip.eu/vps/ officially support OpenBSD and FreeBSD. Also completely SSD enabled. It seems to be just hype I quit using them after they refused to enable virtio for OpenBSD, despite having enabled it for FreeBSD. O.D. That has changed, they now do support virtio. -Otto
Re: DigitalOcean's BSD debut is FreeBSD only
On Tue, Dec 16, 2014 at 05:20:27PM +, openda...@hushmail.com wrote: Hi, On 16. desember 2014 at 4:20 PM, jungle Boogie jungleboog...@gmail.com wrote: I have not personally tested openBSD on https://www.vultr.com/ but I have read (tweets, probably) that it will work. I'm not so sure about Vultr. Icelandic Greenqloud (https://www.greenqloud.com/) are nice though. I personally use vultr for my OpenBSD vps. Their prices are reasonable, you can install from any ISO, and I have never had a problem. Currently hosting, my website, email, jabber server, and code repositories. O.D. -- Benjamin Scher Purcell PGP: CCB787BA [demime 1.01d removed an attachment of type application/pgp-signature]
Re: DigitalOcean's BSD debut is FreeBSD only
So, its a cloud based server farm? What's the point for the typical user? On Tue, 16 Dec 2014, openda...@hushmail.com wrote: Hi, On 16. desember 2014 at 4:17 PM, Lars li...@srdn.de wrote: Says who? Now it's digital ocean - next month it will be somebody else. I seem to fall out of the target group for this. As I don't share your obvious enthusiasm and just don't care - so many rock stars rise and fall. There's never been anyone as cheap, as well-designed and as quickly growing as DigitalOcean. Call them The Beatles, The Bob Marley and the Wailers or what have you. I wrote this thread for the people who do care, and I know a lot of you are lurking out there. O.D.
Re: DigitalOcean's BSD debut is FreeBSD only
On 16. desember 2014 at 5:46 PM, Richard E. Thornton thornton.rich...@gmail.com wrote: So, its a cloud based server farm? What's the point for the typical user? I think the typical user will eventually realize that OpenBSD is one of the most valuable assets he or she can use in the pursuit of happiness and livelihood for ones family. Once that time comes, he or she will most definitely be looking for something like DigitalOcean. Thanks. O.D. On Tue, 16 Dec 2014, openda...@hushmail.com wrote: Hi, On 16. desember 2014 at 4:17 PM, Lars li...@srdn.de wrote: Says who? Now it's digital ocean - next month it will be somebody else. I seem to fall out of the target group for this. As I don't share your obvious enthusiasm and just don't care - so many rock stars rise and fall. There's never been anyone as cheap, as well-designed and as quickly growing as DigitalOcean. Call them The Beatles, The Bob Marley and the Wailers or what have you. I wrote this thread for the people who do care, and I know a lot of you are lurking out there. O.D.
Re: DigitalOcean's BSD debut is FreeBSD only
On Mon, Dec 15, 2014 at 11:25 PM, Richard E. Thornton thornton.rich...@gmail.com wrote: So, its a cloud based server farm? What's the point for the typical user? Inexpensive VPS hosting with fast storage. I have one of their small instances (1 vCPU, 512 MB RAM, 20 GB storage) I'm paying $5/mo for. I'm pretty happy with it. $ sudo dd if=/dev/vda of=/dev/null bs=1024k count=2048 2048+0 records in 2048+0 records out 2147483648 bytes (2.1 GB) copied, 7.31609 s, 294 MB/s On Tue, 16 Dec 2014, openda...@hushmail.com wrote: Hi, On 16. desember 2014 at 4:17 PM, Lars li...@srdn.de wrote: Says who? Now it's digital ocean - next month it will be somebody else. I seem to fall out of the target group for this. As I don't share your obvious enthusiasm and just don't care - so many rock stars rise and fall. There's never been anyone as cheap, as well-designed and as quickly growing as DigitalOcean. Call them The Beatles, The Bob Marley and the Wailers or what have you. I wrote this thread for the people who do care, and I know a lot of you are lurking out there. O.D.
kvm_mkdb: can't open /dev/ksyms
I just upgraded to the latest amd64 snapshot (Dec 16) on a Soekris 6501 and noticed the following line on the console during startup: kvm_mkdb: can't open /dev/ksyms The kvm_mkdb(8) man page doesn't mention anything about /dev that I can see. Permissions issue of some kind, perhaps? $ ls -al /dev/ksyms crw-r- 1 root kmem 50, 0 Dec 16 08:43 /dev/ksyms Not sure whether this is anything to be concerned, so thought I would ask here. Thanks in advance. dmesg follows. OpenBSD 5.6-current (GENERIC.MP) #696: Tue Dec 16 00:26:02 MST 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 1056833536 (1007MB) avail mem = 1024901120 (977MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0 acpi at bios0 not configured mpbios0 at bios0: Intel MP Specification 1.4 cpu0 at mainbus0: apid 0 (boot processor) cpu0: Genuine Intel(R) CPU @ 1.00GHz, 1000.13 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF cpu0: 512KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 100MHz cpu0: mwait min=64, max=64, C-substates=0.2.2.0.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Genuine Intel(R) CPU @ 1.00GHz, 1000.00 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF cpu1: 512KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 mpbios0: bus 0 is type PCI mpbios0: bus 64 is type ISA ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins cpu0: unknown Enhanced SpeedStep CPU, msr 0x060e0a1102000a11 cpu0: using only highest and lowest power states cpu0: Enhanced SpeedStep 1000 MHz: speeds: 1000, 600 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 Intel E600 Host rev 0x03 pchb1 at pci0 dev 1 function 0 Intel E600 Config rev 0x00 ppb0 at pci0 dev 23 function 0 Intel E600 PCIE rev 0x00 pci1 at ppb0 bus 1 ppb1 at pci1 dev 0 function 0 Intel EG20T PCIE rev 0x01 pci2 at ppb1 bus 2 Intel EG20T Packet Hub rev 0x01 at pci2 dev 0 function 0 not configured Intel EG20T Ethernet rev 0x01 at pci2 dev 0 function 1 not configured Intel EG20T GPIO rev 0x00 at pci2 dev 0 function 2 not configured ohci0 at pci2 dev 2 function 0 Intel EG20T USB rev 0x01: apic 0 int 19, version 1.0, legacy support ohci1 at pci2 dev 2 function 1 Intel EG20T USB rev 0x01: apic 0 int 19, version 1.0, legacy support ohci2 at pci2 dev 2 function 2 Intel EG20T USB rev 0x01: apic 0 int 19, version 1.0, legacy support ehci0 at pci2 dev 2 function 3 Intel EG20T USB rev 0x01: apic 0 int 19 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 Intel EG20T USB Client rev 0x01 at pci2 dev 2 function 4 not configured sdhc0 at pci2 dev 4 function 0 Intel EG20T SDIO rev 0x01: apic 0 int 18 sdmmc0 at sdhc0 sdhc1 at pci2 dev 4 function 1 Intel EG20T SDIO rev 0x01: apic 0 int 18 sdmmc1 at sdhc1 ahci0 at pci2 dev 6 function 0 Intel EG20T AHCI rev 0x01: msi, AHCI 1.1 scsibus1 at ahci0: 32 targets sd0 at scsibus1 targ 1 lun 0: ATA, INTEL SSDMAEXC02, 9CV1 SCSI3 0/direct fixed naa.5001517bb297bc22 sd0: 19087MB, 512 bytes/sector, 39091248 sectors, thin ohci3 at pci2 dev 8 function 0 Intel EG20T USB rev 0x01: apic 0 int 16, version 1.0, legacy support ohci4 at pci2 dev 8 function 1 Intel EG20T USB rev 0x01: apic 0 int 16, version 1.0, legacy support ohci5 at pci2 dev 8 function 2 Intel EG20T USB rev 0x01: apic 0 int 16, version 1.0, legacy support ehci1 at pci2 dev 8 function 3 Intel EG20T USB rev 0x01: apic 0 int 16 usb1 at ehci1: USB revision 2.0 uhub1 at usb1 Intel EHCI root hub rev 2.00/1.00 addr 1 Intel EG20T DMA rev 0x00 at pci2 dev 10 function 0 not configured puc0 at pci2 dev 10 function 1 Intel EG20T Serial rev 0x00: ports: 1 com com4 at puc0 port 0 apic 0 int 19: ti16750, 64 byte fifo puc1 at pci2 dev 10 function 2 Intel EG20T Serial rev 0x00: ports: 1 com com5 at puc1 port 0 apic 0 int 19: ti16750, 64 byte fifo puc2 at pci2 dev 10 function 3 Intel EG20T Serial rev 0x00: ports: 1 com com6 at puc2 port 0 apic 0 int 19: ti16750, 64 byte fifo puc3 at pci2 dev 10 function 4 Intel EG20T Serial rev 0x00: ports: 1 com com7 at puc3 port 0 apic 0 int 19: ti16750, 64 byte fifo Intel EG20T DMA rev 0x00 at pci2 dev 12 function 0 not configured Intel EG20T SPI rev 0x00 at pci2 dev 12 function 1 not configured Intel EG20T I2C rev 0x00 at pci2 dev 12 function 2 not configured Intel EG20T CAN rev 0x00 at pci2 dev 12 function 3 not configured Intel EG20T 1588 rev 0x01 at pci2 dev 12 function 4 not configured usb2 at ohci0: USB revision 1.0 uhub2 at
Re: DigitalOcean's BSD debut is FreeBSD only
On 12/16/2014 06:18 PM, openda...@hushmail.com wrote: There's never been anyone as cheap, as well-designed and as quickly growing as DigitalOcean. Wanna bet? http://xkcd.com/1102
Re: Problem With Default Route Over IPSEC Site-To-Site Tunnel VPN
I received a request to share my updated configuration, so I thought I would send it to the list in case others might also find it useful. ## Router 1 # cat /etc/hostname.gre0 169.254.0.1 169.254.0.2 netmask 0x link0 up tunnel 172.16.5.1 172.16.5.2 !route add -net 172.16.6.0/24 169.254.0.2 !route add -net 172.16.7.0/24 169.254.0.2 # cat /etc/ipsec.conf ike passive esp transport \ from 172.16.5.1 to 172.16.5.2 \ main auth hmac-sha2-512 enc aes-256 group modp2048 \ quick auth hmac-sha2-512 enc aes-256-ctr group modp2048 \ srcid SNIP: Router 1 \ dstid SNIP: Router 2 # cat /etc/sysctl.conf net.inet.ip.forwarding=1 net.inet.gre.allow=1 kern.bufcachepercent=50 net.inet.ip.ifq.maxlen=2048 # cat /etc/rc.conf.local ipsec=YES SNIP isakmpd_flags=-K -T # ifconfig SNIP gre0: flags=29011UP,POINTOPOINT,LINK0,MULTICAST,NOINET6 mtu 1476 priority: 0 groups: gre tunnel: inet 172.16.5.1 - 172.16.5.2 inet 169.254.0.1 -- 169.254.0.2 netmask 0x # ipsecctl -sa FLOWS: flow esp in from 172.16.5.2 to 172.16.5.1 peer 172.16.5.2 srcid SNIP: Router 1 dstid SNIP: Router 2 type use flow esp out from 172.16.5.1 to 172.16.5.2 peer 172.16.5.2 srcid SNIP: Router 1 dstid SNIP: Router 2 type require SAD: esp transport from 172.16.5.1 to 172.16.5.2 spi 0x6b898652 auth hmac-sha2-512 enc aes-256-ctr esp transport from 172.16.5.2 to 172.16.5.1 spi 0xf4bff52e auth hmac-sha2-512 enc aes-256-ctr # route -n show Routing tables Internet: DestinationGatewayFlags Refs Use Mtu Prio Iface defaultSNIP: ISP Router UGS 1125 6077357 - 8 vlan0 SNIP 169.254.0.1127.0.0.1 UHl00 - 1 lo0 169.254.0.2169.254.0.1UH 2 100720 - 4 gre0 SNIP 172.16.5/24link#11UC 10 - 4 vlan7 172.16.5.1 SNIP UHLl 00 - 1 lo0 172.16.5.2 SNIP UHLc 2 113643 - L 4 vlan7 172.16.6/24169.254.0.2UGS02 - 8 gre0 172.16.7/24169.254.0.2UGS0 5928 - 8 gre0 SNIP Encap: Source Port DestinationPort Proto SA(Address/Proto/Type/Direction) 172.16.5.2/32 0 172.16.5.1/32 0 0 172.16.5.2/esp/use/in 172.16.5.1/32 0 172.16.5.2/32 0 0 172.16.5.2/esp/require/out ## Router 2 # cat /etc/hostname.gre0 169.254.0.2 169.254.0.1 netmask 0x link0 up tunnel 172.16.5.2 172.16.5.1 !route add -net default 169.254.0.1 # cat /etc/ipsec.conf ike esp transport \ from 172.16.5.2 to 172.16.5.1 \ main auth hmac-sha2-512 enc aes-256 group modp2048 \ quick auth hmac-sha2-512 enc aes-256-ctr group modp2048 \ srcid SNIP: Router 2 \ dstid SNIP: Router 1 # cat /etc/sysctl.conf net.inet.ip.forwarding=1 net.inet.gre.allow=1 kern.bufcachepercent=50 net.inet.ip.ifq.maxlen=1024 # cat /etc/rc.conf.local ipsec=YES SNIP isakmpd_flags=-K -T # ifconfig SNIP gre0: flags=29011UP,POINTOPOINT,LINK0,MULTICAST,NOINET6 mtu 1476 priority: 0 groups: gre egress tunnel: inet 172.16.5.2 - 172.16.5.1 inet 169.254.0.2 -- 169.254.0.1 netmask 0x # ipsecctl -sa FLOWS: flow esp in from 172.16.5.1 to 172.16.5.2 peer 172.16.5.1 srcid SNIP: Router 2 dstid SNIP: Router 1 type use flow esp out from 172.16.5.2 to 172.16.5.1 peer 172.16.5.1 srcid SNIP: Router 2 dstid SNIP: Router 1 type require SAD: esp transport from 172.16.5.1 to 172.16.5.2 spi 0x6b898652 auth hmac-sha2-512 enc aes-256-ctr esp transport from 172.16.5.2 to 172.16.5.1 spi 0xf4bff52e auth hmac-sha2-512 enc aes-256-ctr # route -n show Routing tables Internet: DestinationGatewayFlags Refs Use Mtu Prio Iface default169.254.0.1UGS485718 - 8 gre0 SNIP 169.254.0.1169.254.0.2UH 10 - 4 gre0 169.254.0.2127.0.0.1 UHl00 - 1 lo0 172.16.5/24link#4 UC 20 - 4 vlan0 172.16.5.1 SNIP UHLc 285781 - 4 vlan0 172.16.5.2 SNIP HLl00 - 1 lo0 172.16.5.3 SNIP HLl00 - 1 lo0 172.16.5.21SNIP UHLc 02 - 4 vlan0 172.16.6/24link#5 UC 00 - 4 vlan1 172.16.6.1 SNIP HLl00 - 1 lo0 172.16.7/24link#6 UC 00 - 4 vlan2 172.16.7.1 SNIP HLl00 - 1 lo0 SNIP Encap: Source Port DestinationPort Proto SA(Address/Proto/Type/Direction) 172.16.5.1/32 0 172.16.5.2/32 0 0 172.16.5.1/esp/use/in 172.16.5.2/32 0
Re: DigitalOcean's BSD debut is FreeBSD only
online.net is also a great cloud based server hosting service... -Message d'origine- De : owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] De la part de Gene Envoyé : mardi 16 décembre 2014 19:19 À : Richard E. Thornton Cc : misc Objet : Re: DigitalOcean's BSD debut is FreeBSD only On Mon, Dec 15, 2014 at 11:25 PM, Richard E. Thornton thornton.rich...@gmail.com wrote: So, its a cloud based server farm? What's the point for the typical user? Inexpensive VPS hosting with fast storage. I have one of their small instances (1 vCPU, 512 MB RAM, 20 GB storage) I'm paying $5/mo for. I'm pretty happy with it. $ sudo dd if=/dev/vda of=/dev/null bs=1024k count=2048 2048+0 records in 2048+0 records out 2147483648 bytes (2.1 GB) copied, 7.31609 s, 294 MB/s On Tue, 16 Dec 2014, openda...@hushmail.com wrote: Hi, On 16. desember 2014 at 4:17 PM, Lars li...@srdn.de wrote: Says who? Now it's digital ocean - next month it will be somebody else. I seem to fall out of the target group for this. As I don't share your obvious enthusiasm and just don't care - so many rock stars rise and fall. There's never been anyone as cheap, as well-designed and as quickly growing as DigitalOcean. Call them The Beatles, The Bob Marley and the Wailers or what have you. I wrote this thread for the people who do care, and I know a lot of you are lurking out there. O.D.
Re: DigitalOcean's BSD debut is FreeBSD only
On 17/12/14 05:25, jungle Boogie wrote: I have not personally tested openBSD on https://www.vultr.com/ but I have read (tweets, probably) that it will work. I am doing so, twice. Working well. You can use a custom ISO, they do not specifically enable OpenBSD. I have a digital Ocean instance too, but they do not (last time I checked) allow custom ISOs. Worik -- Why is the legal status of chardonnay different to that of cannabis? worik.stan...@gmail.com 021-1680650, (03) 4821804 Aotearoa (New Zealand) I voted for love
Re: DigitalOcean's BSD debut is FreeBSD only
FWIW I have an OpenBSD 'box' with rootbsd.net. Never a single issue ever. On Tue, Dec 16, 2014 at 7:10 AM, openda...@hushmail.com wrote: Hi, It seems that DigitalOcean's BSD debut is going to be FreeBSD only. We, in the OpenBSD community, are being asked to open up a separate UserVoice vote for OpenBSD -- despite the fact that we've worked so hard to promote the existing one. So, please drop by and share your frustrations: https://digitalocean.uservoice.com/forums/136585-digitalocean/suggestions/3232571-support-bsd-os -- I reckon around half the votes are from OpenBSD users. Many thanks! O.D.
Re: SUN SPARCstation IPX to give away
All, The machine has been claimed by the project. Kind regards, Mark -Original Message- From: Mark Hesselink [mailto:mhess...@alumni.caltech.edu] Sent: 14 December 2014 11:37 To: 'misc@openbsd.org' Subject: SUN SPARCstation IPX to give away All, Due to lack of free time I would like to give away my SUN SPARCstation IPX to a good, new home. The machine has the following specifications: * 64 MB of internal memory * COMPAQ BB009222B5 9.1 GB 7200 RPM Wide Ultra 2 68-pin SCSI hard disk drive including necessary accessories. * AUI to 10BASE-T converter * PROM version 2.3 * Fresh NVRAM, i.e. NVRAM battery is very much alive. The machine has been running until very recently in the above configuration. It is currently offline due to a faulty power supply unit. Word of warning: Replacement PSUs are available on the Internet but terribly expensive. If the project has a need for this machine, I am happy to cover the shipping costs as well. Please contact me off-list if you are interested. Kind regards, Mark P.S. I am UK based.
xfce4-power-manager not updating battery status
Hi, not being satisfied with various Linux flavours on my ThinkPad T440, I have reverted back to OpenBSD. With the exception of non-supported internal wifi card (realtek usb dongle works more or less fine with urtwn), and not having sound over HDMI (I have dedicated another older laptop for HTPC use), I use it without significant problems so far. As a long time xfce user, I got used to monitor my battery status with xfce4-power-manager. Unfortunately, I don't have much use of it, as it does not update battery status in real time. Upon start it shows the correct status, but it does not update afterwards. I need to restart the application in order to update. Any chance for fixing this? Thank you in advance. -- Marko Cupać https://www.mimar.rs/
Re: Dell R630 high interrupts on acpi0
On 16.12.2014. 6:16, Jonathan Matthew wrote: We just got some r630s too, so I spent some time last week figuring out what's going on here. Something in the AML wants to talk to the intel MEI device. Normally this works, but on the new generation of dell machines (we've seen it on r630s and r730s), it's been moved outside the pci memory range we currently allow on amd64. You can see this in your dmesgs: 0:22:0: mem address conflict 0x3303000/0x10 0:22:1: mem address conflict 0x3302000/0x10 The interrupt will keep triggering until it manages to talk to the device, which will never happen. kettenis@ says we can get the pci memory range information we need to deal with this from acpi. Until that happens, expanding the allowed pci memory range makes things work properly. Hi, on R630 i have custom bios settings and noticed that even if C states are disabled in bios i can see them in dmesg acpicpu0 at acpi0: C1 acpicpu1 at acpi0: C1 acpicpu2 at acpi0: C1 acpicpu3 at acpi0: C1 acpicpu4 at acpi0: C1 acpicpu5 at acpi0: C1 acpicpu6 at acpi0: C1 acpicpu7 at acpi0: C1 X2Apic is disabled too but in dmesg i see cpu0: FPU,CPI,...SSE4.1,SSE4.2,x2APIC This is not good, right? R630 bios settings Processor Settings: Logical Processor - Disabled QPI Speed - Maximum data rate Alternate RTID Settings - Disabled Virtualization Technology - Disabled Address Translation Service (ATS) - Disabled (gray) Adjacent Cache Line Prefetch - Enabled Hardware Prefetcher - Enabled DCU Streamer Prefetcher - Enabled DCU IP Prefetcher - Enabled Execute Disabled - Enabled Logical Processor Idling - Disabled Configurable TDP - Nominal X2Apic Mode - Disabled (gray) Dell Controlled Turbo - Enabled System Profile Settings: System Profile - Custom CPU Power Management - Maximum Performance Memory Frequency - Maximum Performance Turbo Boost - Enabled Energy Efficient Turbo - Disabled C1E - Disabled C states - Disabled Collaborative CPU Performance Control - Disabled Memory Patrol Scrub - Standard Memory Refresh Rate - 1x Uncore Frequency - Maximum Energy Efficient Policy - Performance Full dmesg and acpidump from R630 http://kosjenka.srce.hr/~hrvoje/R630_custom_dmesg.txt http://kosjenka.srce.hr/~hrvoje/R630_custom.tgz R620 have similar settings and can't see C states in dmesg acpicpu0 at acpi0 acpicpu1 at acpi0 acpicpu2 at acpi0 acpicpu3 at acpi0 acpicpu4 at acpi0 acpicpu5 at acpi0 R620 bios settings Processor Settings: Logical Processor - Disabled Alternate RTID Settings - Disabled Virtualization Technology - Disabled Adjacent Cache Line Prefetch - Enabled Hardware Prefetcher - Enabled DCU Streamer Prefetcher - Enabled DCU IP Prefetcher - Enabled Logical Processor Idling - Disabled Dell Controlled Turbo - Enabled System Profile Settings: System Profile - Custom CPU Power Management - Maximum Performance Memory Frequency - Maximum Performance Turbo Boost - Enabled C1E - Disabled C states - Disabled Monitor/Mwait - Disabled Memory Patrol Scrub - Standard Memory Refresh Rate - 1x Memory Operating Voltage - Auto Collaborative CPU Performance Control - Disabled Full dmesg and acpidump from R620 http://kosjenka.srce.hr/~hrvoje/R620_custom_dmesg.txt http://kosjenka.srce.hr/~hrvoje/R620_custom.tgz
Follow up from What happened....
Here is a rough dump of the attempted install:
cannot open cd0a:/etc/random.seed: No such file or directory
booting cd0a:/5.5/i386/bsd.rd: 6038804+425032 [72+234464+223327]=0x699f80
entry point at 0x200120
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
Copyright (c) 1995-2014 OpenBSD. All rights reserved. http://www.OpenBSD.org
OpenBSD 5.5 (RAMDISK_CD) #229: Wed Mar 5 10:13:54 MST 2014
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD
cpu0: Intel(R) Celeron(TM) CPU 1300MHz (GenuineIntel 686-class) 1.31 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PSE36,MMX,FXSR,SSE,PERF
real mem = 527953920 (503MB)
avail mem = 512069632 (488MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 02/27/02, BIOS32 rev. 0 @ 0xfb4b0, SMBIOS
rev. 2.3 @ 0xf0800 (35 entries)
bios0: vendor Phoenix Technologies, LTD version 6.00 PG date 02/27/2002
bios0: VIA Technologies, Inc. VT8601
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP
acpiprt0 at acpi0: bus 0 (PCI0)
bios0: ROM list: 0xc/0xc000
cpu0 at mainbus0: (uniprocessor)
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 VIA VT8601 PCI rev 0x05
ppb0 at pci0 dev 1 function 0 VIA VT82C601 AGP rev 0x00
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 Trident CyberBlade i1 rev 0x6a
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
pcib0 at pci0 dev 7 function 0 VIA VT82C686 ISA rev 0x40
pciide0 at pci0 dev 7 function 1 VIA VT82C571 IDE rev 0x06: ATA100, channel 0
configured to compatibility, channel 1 configured to compatibility
wd0 at pciide0 channel 0 drive 0: Maxtor 6Y080L0
wd0: 16-sector PIO, LBA, 78167MB, 160086528 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: ATAPI-CD, ROM-DRIVE-52MAX, 52AW ATAPI 5/cdrom
removable
cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 4
uhci0 at pci0 dev 7 function 2 VIA VT83C572 USB rev 0x1a: irq 5
uhci1 at pci0 dev 7 function 3 VIA VT83C572 USB rev 0x1a: irq 5
VIA VT82C686 SMBus rev 0x40 at pci0 dev 7 function 4 not configured
rl0 at pci0 dev 17 function 0 Realtek 8139 rev 0x10: irq 11, address
00:01:80:0f:2b:94
rlphy0 at rl0 phy 0: RTL internal PHY
isa0 at pcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
usb0 at uhci0: USB revision 1.0
uhub0 at usb0 VIA UHCI root hub rev 1.00/1.00 addr 1
usb1 at uhci1: USB revision 1.0
uhub1 at usb1 VIA UHCI root hub rev 1.00/1.00 addr 1
softraid0 at root
scsibus1 at softraid0: 256 targets
root on rd0a swap on rd0b dump on rd0b
erase ^?, werase ^W, kill ^U, intr ^C, status ^T
Welcome to the OpenBSD/i386 5.5 installation program.
(I)nstall, (U)pgrade, (A)utoinstall or (S)hell? i
At any prompt except password prompts you can escape to a shell by
typing '!'. Default answers are shown in []'s and are selected by
pressing RETURN. You can exit this program at any time by pressing
Control-C, but this can leave your system in an inconsistent state.
Terminal type? [vt220]
System hostname? (short form, e.g. 'foo') foo
Available network interfaces are: rl0 vlan0.
Which network interface do you wish to configure? (or 'done') [rl0]
IPv4 address for rl0? (or 'dhcp' or 'none') [dhcp]
Issuing hostname-associated DHCP request for rl0.
DHCPDISCOVER on rl0 to 255.255.255.255 port 67 interval 1
DHCPOFFER from 192.168.80.254 (80:1f:02:c9:d7:2e)
DHCPREQUEST on rl0 to 255.255.255.255 port 67
DHCPACK from 192.168.80.254 (80:1f:02:c9:d7:2e)
bound to 192.168.80.251 -- renewal in 43200 seconds.
IPv6 address for rl0? (or 'rtsol' or 'none') [none]
Available network interfaces are: rl0 vlan0.
Which network interface do you wish to configure? (or 'done') [done]
Using DNS domainname witworx.com.com
Using DNS nameservers at 192.168.80.1
Password for root account? (will not echo)
Password for root account? (again)
Start sshd(8) by default? [yes]
Start ntpd(8) by default? [no]
Do you expect to run the X Window System? [yes] no
Change the default console to com0? [no]
Setup a user? (enter a lower-case loginname, or 'no') [no]
What timezone are you in? ('?' for list) [Australia/Sydney]
Available disks are: wd0.
Which disk is the root disk? ('?' for details) [wd0]
Use DUIDs rather than device names in fstab? [yes]
Disk: wd0 geometry: 9964/255/63 [160086528 Sectors]
Offset: 0 Signature: 0xAA55
Starting Ending LBA Info:
#: id C H S - C H S [ start:size ]
---
0: 00 0 0 0 - 0 0 0 [
Re: Cannot determine prefetch area error with OpenBSD current autoinstall
On 12/16/14 22:06, Adriaan wrote: On Tue, Dec 16, 2014 at 8:26 AM, Raf r...@devio.us wrote: On Tue, Dec 16, 2014 at 01:01:51AM EST, Adriaan wrote: An initial interactive install was succesful. A next autonstall using bsd,rd gave a Cannot determine prefetch area after selecting the sets. [...] Cannot determine prefetch area. Continue without verification? [no] no I see that tedu@ already mentioned the fact about your local storage is probably too small. I'll only add a link to the FAQ[0] in case you have missed it. With the following custom partition scheme of the same 3GB disk the verification succeeds: p m OpenBSD area: 63-6322176; size: 3087.0M; free: 0.0M #size offset fstype [fsize bsize cpg] a: 2901.9M 64 4.2BSD 2048 163841 # / b: 185.1M 5943168swap # none c: 3093.4M0 unused ... So the verification procedure simply needed a larger partition. Look at the install scripts -- it doesn't prefetch just anywhere, it has a few specific places. /tmp, /home I think are two of the choices, may be more (NOTE: I am too tired to bother looking this up myself now, and it would be good experience for you to do so). I don't think /usr is. Thus, your original config, which had nowhere near enough space in /tmp or /home for the prefetch caused it not to. Nick.
Re: Dell R630 high interrupts on acpi0
On Tue, Dec 16, 2014 at 2:45 PM, Hrvoje Popovski hrv...@srce.hr wrote: on R630 i have custom bios settings and noticed that even if C states are disabled in bios i can see them in dmesg acpicpu0 at acpi0: C1 Uh, ACPI *requires* that C1 exist. The halt instruction is defined as entering C1, so not having C1 would mean your CPU lacks a basic manadatory ia32 instruction. Hopefully the BIOS docs explain that you're just disabling deep C-states or something like that. If not, yell at the company that made it. With the exception of C1E, I wouldn't tell a BIOS to disable C-states unless it was causing the OS to have a problem or you're actively trying to use the computer to heat your house. C1E is a cross between C1 and C3; the issue is that bugs in multiple early hardware implementations mean it'll behave poorly depending on exactly how the OS handles it. This is something to test...and then test again with each release you install... X2Apic is disabled too but in dmesg i see cpu0: FPU,CPI,...SSE4.1,SSE4.2,x2APIC That just means the CPU has the feature bit set in the CPUID sets. The BIOS is presumably configuring ACPI (which is what OpenBSD pays attention to) to use the original LAPIC tables instead of the x2APIC tables for locating CPUs and interrupts. R620 have similar settings and can't see C states in dmesg acpicpu0 at acpi0 That's either insane, or a bug in our acpicpu code, IMO. R620 bios settings ... Monitor/Mwait - Disabled I would suggest leaving that on. We ain't using it *right now*, but, well, the source tree on my laptop is, and more than ever. :-) Philip Guenther
Re: Dell R630 high interrupts on acpi0
Hi!
The below diff extracts the memory range information from ACPI. It looks
up all the memory ranges in _CRS and calculates minimal and maximal
values for pci_machdep.c.
I tested this on two amd64 machines and see no difference in pcidump.
Do you think we need to keep the old method in case the ACPI on some
machines does not report correct memory ranges? A simple check would be
to test if pcimem_range[0] pcimem_range[1]...
Index: sys/arch/amd64/include/pci_machdep.h
===
RCS file: /cvs/src/sys/arch/amd64/include/pci_machdep.h,v
retrieving revision 1.22
diff -u -p -b -r1.22 pci_machdep.h
--- sys/arch/amd64/include/pci_machdep.h6 Nov 2013 10:40:36 -
1.22
+++ sys/arch/amd64/include/pci_machdep.h17 Dec 2014 06:00:01 -
@@ -64,6 +64,7 @@ extern int pci_mcfg_min_bus, pci_mcfg_ma
struct pci_attach_args;
+extern uint64_t pcimem_range[2];
extern struct extent *pciio_ex;
extern struct extent *pcimem_ex;
extern struct extent *pcibus_ex;
Index: sys/arch/amd64/pci/pci_machdep.c
===
RCS file: /cvs/src/sys/arch/amd64/pci/pci_machdep.c,v
retrieving revision 1.60
diff -u -p -b -r1.60 pci_machdep.c
--- sys/arch/amd64/pci/pci_machdep.c16 Dec 2014 23:13:20 - 1.60
+++ sys/arch/amd64/pci/pci_machdep.c17 Dec 2014 07:16:47 -
@@ -66,6 +66,7 @@
*/
#include sys/types.h
+#include sys/stdint.h
#include sys/param.h
#include sys/time.h
#include sys/systm.h
@@ -592,6 +593,7 @@ pci_intr_disestablish(pci_chipset_tag_t
intr_disestablish(cookie);
}
+uint64_t pcimem_range[2] = {UINT64_MAX, 0};
struct extent *pciio_ex;
struct extent *pcimem_ex;
struct extent *pcibus_ex;
@@ -618,31 +620,25 @@ pci_init_extents(void)
if (pcimem_ex == NULL) {
/*
-* Cover the 36-bit address space addressable by PAE
-* here. As long as vendors continue to support
-* 32-bit operating systems, we should never see BARs
-* outside that region.
-*
-* Dell 13G servers have important devices outside the
-* 36-bit address space. Until we can extract the address
-* ranges from ACPI, expand the allowed range to suit.
+* Cover the address space extracted from ACPI.
*/
pcimem_ex = extent_create(pcimem, 0, 0xUL,
M_DEVBUF, NULL, 0, EX_NOWAIT);
if (pcimem_ex == NULL)
return;
- extent_alloc_region(pcimem_ex, 0x400UL,
- 0xfc00UL, EX_NOWAIT);
+ extent_alloc_region(pcimem_ex, pcimem_range[1] + 1,
+ (0xUL - pcimem_range[1]), EX_NOWAIT);
for (bmp = bios_memmap; bmp-type != BIOS_MAP_END; bmp++) {
/*
-* Ignore address space beyond 4G.
+* Ignore address space beyond address range
+* extracted from ACPI.
*/
- if (bmp-addr = 0x1ULL)
+ if (bmp-addr pcimem_range[1])
continue;
size = bmp-size;
- if (bmp-addr + size = 0x1ULL)
- size = 0x1ULL - bmp-addr;
+ if (bmp-addr + size pcimem_range[1])
+ size = pcimem_range[1] - bmp-addr + 1;
/* Ignore zero-sized regions. */
if (size == 0)
Index: sys/dev/acpi/acpi.c
===
RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
retrieving revision 1.277
diff -u -p -b -r1.277 acpi.c
--- sys/dev/acpi/acpi.c 9 Dec 2014 06:58:29 - 1.277
+++ sys/dev/acpi/acpi.c 17 Dec 2014 05:59:36 -
@@ -385,0 +385,0 @@ TAILQ_HEAD(, acpi_pci) acpi_pcirootdevs
int acpi_getpci(struct aml_node *node, void *arg);
int acpi_getminbus(union acpi_resource *crs, void *arg);
+int acpi_getmemrange(union acpi_resource *crs, void *arg);
+
+int
+acpi_getmemrange(union acpi_resource *crs, void *arg)
+{
+ int typ = AML_CRSTYPE(crs);
+ uint64_t *range = arg; /* size 2 */
+ uint64_t min, max;
+
+ switch(typ) {
+ case LR_24BIT:
+ min = crs-lr_m24._min;
+ max = crs-lr_m24._max;
+ break;
+ case LR_32BIT:
+ case LR_32BITFIXED:
+ min = crs-lr_m32._min;
+ max = crs-lr_m32._max;
+ break;
+ case LR_WORD:
+ min = crs-lr_word._min;
+ max = crs-lr_word._max;
+ break;
+ case LR_DWORD:
+ min = crs-lr_dword._min;
+ max =
