Re: Issue with pxebooting on HP DL360 G7

[Edgar Pettijohn]

On 06/09/17 11:18, Tommy Nevtelen wrote:

On 2017-06-09 17:46, Tommy Nevtelen wrote:


Hello misc!

I'm chain-loading pxeboot symlinked to auto_install from ipxe.

So I tried to remove ipxe and specify pxeboot directly in the dhcp
filename, that worked.
But with that said I still don't understand why it works on a VM but not
on my hardware.

Could somebody clarify what that error means?

It is an issue with the reply packet from the DHCP server. It delves 
into assembly from there and I'd rather not purposefully give myself a 
headache, so thats the best I can do for you.

Re: Can I use OpenBSD as a desktop system?

[Nick Holland]

On 06/09/17 15:39, SOUL_OF_ROOT 55 wrote:
> Can I use OpenBSD as a desktop system?

You?  No, I doubt it.

Me, it's pretty much all I use as a home desktop system.

But you didn't seem to want to give it a try to find out for yourself,
or define what you mean by a "desktop system", or do some basic
research, like maybe googling for "openbsd desktop".  So it might be
quite an uphill battle for you.   You must be so --->  <--- smart to
ride this ride.

But, you are welcome, and invited, to give it a try.  Prove me wrong! :)

Nick.

Re: ASLR for golang on OpenBSD

[Juan Francisco Cantero Hurtado]

On Fri, Jun 09, 2017 at 06:37:51PM +, ra...@openmailbox.org wrote:
> Hello!
> 
> Here is a patch that lets you use `go build -buildmode=pie file.go` to
> compile golang binaries on OpenBSD and get ASLR.
> 
> By default all the golang binaries compiled on openbsd are not randomized,
> only linux and android have that feature.
> 
> This patch is against go1.8.3.src.tar.gz

You should send the patch to the golang project. If we only patch the
port, then the users from other platforms generating OpenBSD binaries
will not be able to use the pie mode.

> 
> 
> 
> diff -Naur go/src/cmd/go/build.go go-aslr/src/cmd/go/build.go
> --- go/src/cmd/go/build.go  2017-05-24 18:15:12.0 +
> +++ go-aslr/src/cmd/go/build.go 2017-06-09 18:26:12.740449349 +
> @@ -383,8 +383,11 @@
> } else {
> switch platform {
> case "linux/386", "linux/amd64", "linux/arm",
> "linux/arm64", "linux/ppc64le", "linux/s390x",
> -   "android/amd64", "android/arm",
> "android/arm64", "android/386":
> +   "android/amd64", "android/arm",
> "android/arm64", "android/386", "openbsd/amd64":
> codegenArg = "-shared"
> +   if platform == "openbsd/amd64" {
> +   ldBuildmode = "pie"
> +   }
> default:
> fatalf("-buildmode=pie not supported on
> %s\n", platform)
> }
> diff -Naur go/src/cmd/link/internal/ld/config.go
> go-aslr/src/cmd/link/internal/ld/config.go
> --- go/src/cmd/link/internal/ld/config.go   2017-05-24
> 18:15:12.0 +
> +++ go-aslr/src/cmd/link/internal/ld/config.go  2017-06-09
> 18:26:37.820448527 +
> @@ -43,7 +43,7 @@
> *mode = BuildmodeExe
> case "pie":
> switch obj.GOOS {
> -   case "android", "linux":
> +   case "android", "linux", "openbsd":
> default:
> return badmode()
> }
> diff -Naur go/src/cmd/link/internal/ld/lib.go
> go-aslr/src/cmd/link/internal/ld/lib.go
> --- go/src/cmd/link/internal/ld/lib.go  2017-05-24 18:15:12.0 +
> +++ go-aslr/src/cmd/link/internal/ld/lib.go 2017-06-09
> 18:26:56.903781235 +
> @@ -1019,7 +1019,9 @@
> argv = append(argv, "-Wl,-no_pie")
> }
> case obj.Hopenbsd:
> -   argv = append(argv, "-Wl,-nopie")
> +   if Buildmode != BuildmodePIE {
> +   argv = append(argv, "-Wl,-nopie")
> +   }
> case obj.Hwindows:
> argv = append(argv, "-mconsole")
> case obj.Hwindowsgui:
> 

-- 
Juan Francisco Cantero Hurtado http://juanfra.info

Re: Can I use OpenBSD as a desktop system?

[Ingo Schwarze]

Johan Mellberg wrote on Fri, Jun 09, 2017 at 10:06:18PM +0200:
> 2017-06-09 21:39 GMT+02:00 SOUL_OF_ROOT 55 :

>> Can I use OpenBSD as a desktop system?

> Yes.

To provide an example:

On my private desktops and laptops, i never ran anything else since 2001.

And even at work, i only made two exceptions:

>From 2003 to 2006, i had one Windows desktop at work because i had to run
a specific commercial binary-only accounting software.

And for a few months in 2007, i ran Debian GNU/Linux on one desktop
at a new job in a software company before i defied the official
company policy of "you can run whatever you want on your desktop,
but it must be Linux" and installed OpenBSD instead.  If anybody
had ever asked, my answer would have been "I consider OpenBSD a
Linux distribution: for all practical purposes, i can run the same
software on it, and i can work much more efficiently with it."
But nobody ever asked.

For the last ten years, nothing else on the desktop, neither privately
nor at work...

Yours,
  Ingo

Re: Can I use OpenBSD as a desktop system?

[Davor Balder]

Installing is not hard. It can be done in 15 min if you are comfortable
with UNIX.

Peruse this and enjoy: http://sohcahtoa.org.uk/openbsd.html#0

Cheers

D


On 10/06/17 06:06, Johan Mellberg wrote:
> Yes.
>
> 2017-06-09 21:39 GMT+02:00 SOUL_OF_ROOT 55 :
>
>> Can I use OpenBSD as a desktop system?
>>

Re: Can I use OpenBSD as a desktop system?

[Edgar Pettijohn]

As long as you can type startx at the command prompt, then yes.

⁣Sent from BlueMail ​

On Jun 9, 2017, 3:07 PM, at 3:07 PM, Johan Mellberg  
wrote:
>Yes.
>
>2017-06-09 21:39 GMT+02:00 SOUL_OF_ROOT 55 :
>
>> Can I use OpenBSD as a desktop system?
>>

Re: Can I use OpenBSD as a desktop system?

[Johan Mellberg]

Yes.

2017-06-09 21:39 GMT+02:00 SOUL_OF_ROOT 55 :

> Can I use OpenBSD as a desktop system?
>

Can I use OpenBSD as a desktop system?

[SOUL_OF_ROOT 55]

Can I use OpenBSD as a desktop system?

ASLR for golang on OpenBSD

[rain1]

Hello!

Here is a patch that lets you use `go build -buildmode=pie file.go` to 
compile golang binaries on OpenBSD and get ASLR.


By default all the golang binaries compiled on openbsd are not 
randomized, only linux and android have that feature.


This patch is against go1.8.3.src.tar.gz



diff -Naur go/src/cmd/go/build.go go-aslr/src/cmd/go/build.go
--- go/src/cmd/go/build.go  2017-05-24 18:15:12.0 +
+++ go-aslr/src/cmd/go/build.go 2017-06-09 18:26:12.740449349 +
@@ -383,8 +383,11 @@
} else {
switch platform {
case "linux/386", "linux/amd64", "linux/arm", 
"linux/arm64", "linux/ppc64le", "linux/s390x",
-   "android/amd64", "android/arm", 
"android/arm64", "android/386":
+   "android/amd64", "android/arm", 
"android/arm64", "android/386", "openbsd/amd64":

codegenArg = "-shared"
+   if platform == "openbsd/amd64" {
+   ldBuildmode = "pie"
+   }
default:
fatalf("-buildmode=pie not supported on 
%s\n", platform)

}
diff -Naur go/src/cmd/link/internal/ld/config.go 
go-aslr/src/cmd/link/internal/ld/config.go
--- go/src/cmd/link/internal/ld/config.go   2017-05-24 
18:15:12.0 +
+++ go-aslr/src/cmd/link/internal/ld/config.go  2017-06-09 
18:26:37.820448527 +

@@ -43,7 +43,7 @@
*mode = BuildmodeExe
case "pie":
switch obj.GOOS {
-   case "android", "linux":
+   case "android", "linux", "openbsd":
default:
return badmode()
}
diff -Naur go/src/cmd/link/internal/ld/lib.go 
go-aslr/src/cmd/link/internal/ld/lib.go
--- go/src/cmd/link/internal/ld/lib.go  2017-05-24 18:15:12.0 
+
+++ go-aslr/src/cmd/link/internal/ld/lib.go 2017-06-09 
18:26:56.903781235 +

@@ -1019,7 +1019,9 @@
argv = append(argv, "-Wl,-no_pie")
}
case obj.Hopenbsd:
-   argv = append(argv, "-Wl,-nopie")
+   if Buildmode != BuildmodePIE {
+   argv = append(argv, "-Wl,-nopie")
+   }
case obj.Hwindows:
argv = append(argv, "-mconsole")
case obj.Hwindowsgui:

Re: re0 and re1 watchdog timeouts, and system freeze

[Björn Ketelaars]

On Fri 09/06/2017 12:07, Martin Pieuchot wrote:
> On 08/06/17(Thu) 20:38, Björn Ketelaars wrote:
> > On Thu 08/06/2017 16:55, Martin Pieuchot wrote:
> > > On 07/06/17(Wed) 09:43, Björn Ketelaars wrote:
> > > > On Sat 03/06/2017 08:44, Björn Ketelaars wrote:
> > > > > 
> > > > > Reverting back to the previous kernel fixed the issue above. 
> > > > > Question: can
> > > > > someone give a hint on how to track this issue?
> > > > 
> > > > After a bit of experimenting I'm able to reproduce the problem. Summary 
> > > > is
> > > > that queueing in pf and use of a current (after May 30), multi processor
> > > > kernel (bsd.mp from snapshots) causes these specific watchdog timeouts
> > > > followed by a system freeze.
> > > > 
> > > > Issue is 'gone' when:
> > > > 1.) using an older kernel (before May 30);
> > > > 2.) removal of queueing statements from pf.conf. Included below the 
> > > > specific
> > > > snippet;
> > > > 3.) switch from MP kernel to SP kernel.
> > > > 
> > > > New observation is that while queueing, using a MP kernel, the download
> > > > bandwidth is only a fraction of what is expected. Exchanging the MP 
> > > > kernel
> > > > with a SP kernel restores the download bandwidth to expected level.
> > > > 
> > > > I'm guessing that this issue is related to recent work on PF?
> > > 
> > > It's certainly a problem in, or exposed by, re(4) with the recent MP work
> > > in the network stack.
> > > 
> > > It would help if you could build a kernel with MP_LOCKDEBUG defined and
> > > see if the resulting kernel enters ddb(4) instead of freezing.
> > > 
> > > Thanks,
> > > Martin
> > 
> > Thanks for the hint! It helped in entering ddb. I collected a bit of output,
> > which you can find below. If I read the trace correctly the crash is related
> > to line 1750 of sys/dev/ic/re.c:
> > 
> > d->rl_cmdstat |= htole32(RL_TDESC_CMD_EOF);
> 
> Could you test the diff below, always with a MP_LOCKDEBUG kernel and
> tell us if you can reproduce the freeze or if the kernel enters ddb(4)?
> 
> Another question, how often do you see "watchdog timeout" messages?
> 
> Index: re.c
> ===
> RCS file: /cvs/src/sys/dev/ic/re.c,v
> retrieving revision 1.201
> diff -u -p -r1.201 re.c
> --- re.c  24 Jan 2017 03:57:34 -  1.201
> +++ re.c  9 Jun 2017 10:04:43 -
> @@ -2074,9 +2074,6 @@ re_watchdog(struct ifnet *ifp)
>   s = splnet();
>   printf("%s: watchdog timeout\n", sc->sc_dev.dv_xname);
>  
> - re_txeof(sc);
> - re_rxeof(sc);
> -
>   re_init(ifp);
>  
>   splx(s);

The diff (with a MP_LOCKDEBUG kernel) resulted in similar traces as before.
ddb Output is included below.

With your diff the number of timeout messages decreased from 9 to 2 before
entering ddb.


ddb{1}> show panic
the kernel did not panic

ddb{1}> machine ddbcpu 0
Stopped at  db_enter+0x9:   leave

ddb{0}> trace
db_enter(8196b640,200,804d1600,10,8000220e9938,282) at db_e
nter+0x9
x86_ipi_handler(80074010,819e7160,102860,c,4,1813a9522) at x86_
ipi_handler+0x85
Xresume_lapic_ipi() at Xresume_lapic_ipi+0x1c
--- interrupt ---
___mp_lock(819e7160,8187acf0,1,1,8000220a38c0,8000220a7
ab0) at ___mp_lock+0x4a
___mp_acquire_count(819e7160,1,8000220a38c0,8000220a7ab0,ff
011da1e1c8,81019942) at ___mp_acquire_count+0x33
mi_switch(ff011b4a93c0,818bf7e7,9cd,8000220e9bb0,8000220a7a
b0,8000220e9ba0) at mi_switch+0x22b
sleep_finish(8000220e9bb0,1,118,8000220e9bb0,ff011b4a93c0,8
18bf7e7) at sleep_finish+0xc2
tsleep(ff011b4a93c0,118,818bf7e7,9cd,0,40) at tsleep+0x164
kqueue_scan(ff011b4a93c0,40,143d48714800,8000220e9dd0,8000220a7ab0,
8000220e9de4) at kqueue_scan+0x15b
sys_kevent(8000220a7ab0,8000220e9e60,8000220e9eb0,8000220a7ab0,
48,1) at sys_kevent+0x2f6
syscall() at syscall+0x29f
--- syscall (number 72) ---
end of kernel
end trace frame: 0x143d48714800, count: -11
0x143c524f280a:

ddb{0}> machine ddbcpu 1
Stopped at  re_encap+0x24d: movl0(%r15),%eax

ddb{1}> trace
re_encap(80084000,dd,ff00d6e03f00,800842c0,400,8008
4000) at re_encap+0x24d
re_start(800842c0,7,ff00d6dd7200,80084338,800842c0,
81091d70) at re_start+0x8c
ifq_serialize(800842c0,80084360,80084090,ff00d6a515
00,800842c0,0) at ifq_serialize+0xf8
if_enqueue(80084090,ff00d6a51500,8001dc80,ff00d6a51500,
37,2) at if_enqueue+0x90
ether_output(80084090,ff00d6dd7200,8001dc80,ff011b3f49a
0,80933400,8001dc80) at ether_output+0x1d6
ip_output(ff00d6dd7200,0,800022032cc0,1,0,0) at ip_output+0x8a1
ip_forward(ff00d6dd7200,802a4090,0,0,8244c78a,8244c78a) at ip_forwa
rd+0x1e7
ipv4_input(802a4090,ff00d6dd7200,800,800,ff0009d00200,8

Re: Use of upwexpire to configure user password expiry policy

[Ted Unangst]

Darren Marshall wrote:
> Hi guys,
> 
> I'm trying to create a policy whereby a user added to an OpenBSD 6.0 system
> automatically gets their password expiry set to 60 days.
> 
> I did think that this could be accomplished by adding upwexpire="60d" to
> /etc/adduser.conf but subsequent adding of a test user using adduser
> doesn't inherit this setting , field 6 of their passwd entry is set to 0.
> 
> Anyone got any idea how to achieve this?

>From adduser:

# obscure perl bug
$new_entry = "$name\:" . "$cryptpwd" .
"\:$u_id\:$g_id\:$log_cl:0:0:$fullname:$home/$name:$sh";

I will leave it to the ancient wizards to tell us more about the obscure perl
bug, but it's easy to see the hardcoded 0:0 for change and expiry.

Re: Use of upwexpire to configure user password expiry policy

[Edgar Pettijohn]

I think you are looking for usermgmt.conf, or useradd -D -e `date`

⁣Sent from BlueMail ​

On Jun 9, 2017, 11:22 AM, at 11:22 AM, Darren Marshall  
wrote:
>Hi guys,
>
>I'm trying to create a policy whereby a user added to an OpenBSD 6.0
>system
>automatically gets their password expiry set to 60 days.
>
>I did think that this could be accomplished by adding upwexpire="60d"
>to
>/etc/adduser.conf but subsequent adding of a test user using adduser
>doesn't inherit this setting , field 6 of their passwd entry is set to
>0.
>
>Anyone got any idea how to achieve this?
>
>Many thanks daz

Use of upwexpire to configure user password expiry policy

[Darren Marshall]

Hi guys,

I'm trying to create a policy whereby a user added to an OpenBSD 6.0 system
automatically gets their password expiry set to 60 days.

I did think that this could be accomplished by adding upwexpire="60d" to
/etc/adduser.conf but subsequent adding of a test user using adduser
doesn't inherit this setting , field 6 of their passwd entry is set to 0.

Anyone got any idea how to achieve this?

Many thanks daz

Re: Issue with pxebooting on HP DL360 G7

[Tommy Nevtelen]

On 2017-06-09 17:46, Tommy Nevtelen wrote:

> Hello misc!
>
> I'm chain-loading pxeboot symlinked to auto_install from ipxe.

So I tried to remove ipxe and specify pxeboot directly in the dhcp
filename, that worked.
But with that said I still don't understand why it works on a VM but not
on my hardware.

Could somebody clarify what that error means?

-- 
Tommy Nevtelen

Issue with pxebooting on HP DL360 G7

[Tommy Nevtelen]

Hello misc!

I'm chain-loading pxeboot symlinked to auto_install from ipxe.
This works all fine and dandy in a kvm virtual machine.

But when i run a HP DL360 G7 against the same dhcp/tftp-server I get the
following:

Starting OpenBSD 6.1
tftp://boot1.example.com/openbsd/auto_install... ok
probing: px0 com0 pxe![2.1]
pxeinfo: PXENV_GET_CACHED_INFO failed: 0x60
 mem[578K 3444M 639M a20=on]
disk: fd0 fd1 hd0+

Then it hangs there until I reboot the machine.

HALP! );

-- 
Tommy Nevtelen

Re: With Multiple PPPoE interfaces on one will work

[Stefan Sperling]

On Thu, May 18, 2017 at 11:15:53AM +, Steve wrote:
> Thanks,I was mostly checking if this was a known issue.If I rename 
> hostname.pppoe0 to hostname.pppoe1 and then rename hostname.pppoe2 to 
> hostname.pppoe0The original pppoe2 (now pppoe0) works fine but the other 
> interface stops working. If I swap them back the original behaviour is seen.
>  ifconfig pppoe2 debug shows no ouput.As shown below pppoe2 just stays in 
> state: initial.
> 
> vr2: flags=8843 mtu 1500
>     lladdr 00:00:24:d1:9d:6a
>     priority: 0
>     media: Ethernet autoselect (100baseTX full-duplex)
>     status: active
> 
> pppoe2: flags=8810 mtu 1492
>     priority: 0
>     dev: vr2 state: initial
>     sid: 0x0 PADI retries: 0 PADR retries: 0
>     groups: pppoe
>     status: no carrier
> 
> I have now "upgraded" to 6.1. The same is noted
> Any thoughts would be appreciated.

I believe this stopped working due to legitimate changes in how the
routing table works.

To reproduce the problem, start with a fresh routing table.
Before any interfaces (except loopback) are configured it looks like:

DestinationGatewayFlags   Refs  Use   Mtu  Prio Iface   
127.0.0.1  127.0.0.1  UHl00 32768 1 lo1

Prepare configuration of two pppoe interfaces as per the pppoe(4) man page:

$ cat /etc/hostname.pppoe0
inet 0.0.0.0 255.255.255.255 NONE \
   pppoedev em0 authproto pap \
   authname 'testcaller' authkey 'donttell' up
dest 0.0.0.1
$ cat /etc/hostname.pppoe1
inet 0.0.0.0 255.255.255.255 NONE \
   pppoedev em1 authproto pap \
   authname 'testcaller2' authkey 'donttell2' up
dest 0.0.0.1

After 'sh /etc/netstart pppoe0' the routing table looks like:

DestinationGatewayFlags   Refs  Use   Mtu  Prio Iface
0.0.0.1defaultH  00 - 8 pppoe0
127.0.0.1  127.0.0.1  UHl00 32768 1 lo1  

And the pppoe interface is ready to get its addresses from the peer:

pppoe0: flags=8851 rdomain 1 mtu 1492
index 15 priority 0 llprio 3
dev: em0 state: PADI sent
sid: 0x0 PADI retries: 18 PADR retries: 0
sppp: phase establish authproto pap 
groups: pppoe
status: no carrier
inet 0.0.0.0 --> 0.0.0.1 netmask 0x


But the second interface fails to set its dest address since the same
route already exists in the table:

# sh /etc/netstart pppoe1
ifconfig: SIOCAIFADDR: File exists 

So there's no address on pppoe1:

pppoe1: flags=8851 rdomain 1 mtu 1492
index 16 priority 0 llprio 3
dev: cdce0 state: PADI sent
sid: 0x0 PADI retries: 5 PADR retries: 0
sppp: phase establish authproto pap 
groups: pppoe
status: no carrier

And as a result, this code in sys/net/if_spppsubr.c cannot work:

if (myaddr == 0) {
/*
 * I don't have an assigned address, so i need to
 * negotiate my address.
 */
sp->ipcp.flags |= IPCP_MYADDR_DYN;
sp->ipcp.opts |= (1 << IPCP_OPT_ADDRESS);
}
if (hisaddr == 1) {
/*
 * XXX - remove this hack!
 * remote has no valid address, we need to get one assigned.
 */
sp->ipcp.flags |= IPCP_HISADDR_DYN;
}

It seems a correct fix would involve replacing the above code with a better
way of setting the IPCP_MYADDR_DYN and IPCP_HISADDR_DYN flags. And this
new way should not require any 'wildcard' addresses on pppoe interfaces.

One workaround is to run each pppoe interface in a separate routing domain
so that each interface gets its own routing table.
Offhand I'm not quite sure to combine this workaround with a failover setup.

screen black after attaching to inteldrm, June snapshots

[Ed Ahlsen-Girard]

Since the June 7 snapshot and the one before that, once inteldrm is
attached:

inteldrm0 at pci0 dev 2 function 0 "Intel G41 Video" rev 0x03 

the screen goes black. Seems similar to the issue noted here:

http://marc.info/?l=openbsd-tech=144317809403958=2

dmesg below.

-- 

Edward Ahlsen-Girard
Ft Walton Beach, FL

OpenBSD 6.1-current (GENERIC.MP) #91: Fri Jun  2 05:22:31 MDT 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4242014208 (4045MB)
avail mem = 4107661312 (3917MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xf06d0 (43 entries)
bios0: vendor American Megatrends Inc. version "0504" date 10/05/2009
bios0: ASUSTeK Computer INC. P-P5G41
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG OEMB HPET GSCI SSDT
acpi0: wakeup devices P0P2(S4) P0P3(S4) P0P1(S4) UAR1(S4) PS2K(S4)
USB0(S4) USB1(S4) USB2(S4) USB3(S4) EUSB(S4) MC97(S4) P0P4(S4) P0P5(S4)
P0P6(S4) P0P7(S4) P0P8(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24
bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0:
apid 0 (boot processor) cpu0: Intel(R) Core(TM)2 Duo CPU E7500 @
2.93GHz, 2933.64 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,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF
cpu0: 3MB 64b/line 8-way L2 cache mtrr: Pentium Pro MTRR support, 8 var
ranges, 88 fixed ranges cpu0: apic clock running at 266MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz, 2933.31 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,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF
cpu1: 3MB 64b/line 8-way L2 cache ioapic0 at mainbus0: apid 2 pa
0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xf000, bus
0-63 acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (P0P2)
acpiprt2 at acpi0: bus -1 (P0P3)
acpiprt3 at acpi0: bus 3 (P0P4)
acpiprt4 at acpi0: bus -1 (P0P5)
acpiprt5 at acpi0: bus 2 (P0P6)
acpiprt6 at acpi0: bus 1 (P0P7)
acpicpu0 at acpi0: C1(@1 halt!), PSS
acpicpu1 at acpi0: C1(@1 halt!), PSS
aibs0 at acpi0 RTMP RVLT RFAN GGRP GITM SITM
aibs0: FSIF: invalid package
"PNP0501" at acpi0 not configured
"PNP0303" at acpi0 not configured
acpibtn0 at acpi0: PWRB
cpu0: Enhanced SpeedStep 2933 MHz: speeds: 2936, 2670, 2403, 2136,
1870, 1603 MHz pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel G41 Host" rev 0x03
inteldrm0 at pci0 dev 2 function 0 "Intel G41 Video" rev 0x03
drm0 at inteldrm0
intagp0 at inteldrm0
agp0 at intagp0: aperture at 0xe000, size 0x1000
inteldrm0: msi
inteldrm0: 1920x1080, 32bpp
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
"Intel G41 Video" rev 0x03 at pci0 dev 2 function 1 not configured
azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x01: msi
azalia0: codecs: Realtek ALC888
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x01: msi
pci1 at ppb0 bus 3
xhci0 at pci1 dev 0 function 0 vendor "Fresco Logic", unknown product
0x1100 rev 0x01: msi usb0 at xhci0: USB revision 3.0
uhub0 at usb0 configuration 1 interface 0 "Fresco Logic xHCI root hub"
rev 3.00/1.00 addr 1 ppb1 at pci0 dev 28 function 2 "Intel 82801GB
PCIE" rev 0x01: msi pci2 at ppb1 bus 2
re0 at pci2 dev 0 function 0 "Realtek 8168" rev 0x02: RTL8168C/8111C
(0x3c00), msi, address 48:5b:39:c5:63:95 rgephy0 at re0 phy 7:
RTL8169S/8110S/8211 PHY, rev. 2 ppb2 at pci0 dev 28 function 3 "Intel
82801GB PCIE" rev 0x01: msi pci3 at ppb2 bus 1
vendor "VIA", unknown product 0x3401 (class serial bus subclass
Firewire, rev 0x00) at pci3 dev 0 function 0 not configured vendor
"VIA", unknown product 0x401a (class mass storage subclass
miscellaneous, rev 0x00) at pci3 dev 0 function 1 not configured sdhc0
at pci3 dev 0 function 2 vendor "VIA", unknown product 0x401b rev 0x00:
apic 2 int 19 sdhc0: SDHC 1.0, 50 MHz base clock sdmmc0 at sdhc0:
4-bit, sd high-speed, mmc high-speed uhci0 at pci0 dev 29 function 0
"Intel 82801GB USB" rev 0x01: apic 2 int 23 uhci1 at pci0 dev 29
function 1 "Intel 82801GB USB" rev 0x01: apic 2 int 19 uhci2 at pci0
dev 29 function 2 "Intel 82801GB USB" rev 0x01: apic 2 int 18 uhci3 at
pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x01: apic 2 int 16
ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x01: apic 2
int 23 usb1 at ehci0: USB revision 2.0 uhub1 at usb1 configuration 1
interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 ppb3 at pci0 dev
30 function 0 "Intel 82801BA Hub-to-PCI" rev 0xe1 pci4 at ppb3 bus 4
pcib0 at pci0 dev 31 function 0 "Intel 82801GB LPC" rev 0x01 pciide0 at
pci0 dev 31 function 1 "Intel 82801GB IDE" rev 0x01: DMA, channel 

Re: re0 and re1 watchdog timeouts, and system freeze

[Martin Pieuchot]

On 08/06/17(Thu) 20:38, Björn Ketelaars wrote:
> On Thu 08/06/2017 16:55, Martin Pieuchot wrote:
> > On 07/06/17(Wed) 09:43, Björn Ketelaars wrote:
> > > On Sat 03/06/2017 08:44, Björn Ketelaars wrote:
> > > > 
> > > > Reverting back to the previous kernel fixed the issue above. Question: 
> > > > can
> > > > someone give a hint on how to track this issue?
> > > 
> > > After a bit of experimenting I'm able to reproduce the problem. Summary is
> > > that queueing in pf and use of a current (after May 30), multi processor
> > > kernel (bsd.mp from snapshots) causes these specific watchdog timeouts
> > > followed by a system freeze.
> > > 
> > > Issue is 'gone' when:
> > > 1.) using an older kernel (before May 30);
> > > 2.) removal of queueing statements from pf.conf. Included below the 
> > > specific
> > > snippet;
> > > 3.) switch from MP kernel to SP kernel.
> > > 
> > > New observation is that while queueing, using a MP kernel, the download
> > > bandwidth is only a fraction of what is expected. Exchanging the MP kernel
> > > with a SP kernel restores the download bandwidth to expected level.
> > > 
> > > I'm guessing that this issue is related to recent work on PF?
> > 
> > It's certainly a problem in, or exposed by, re(4) with the recent MP work
> > in the network stack.
> > 
> > It would help if you could build a kernel with MP_LOCKDEBUG defined and
> > see if the resulting kernel enters ddb(4) instead of freezing.
> > 
> > Thanks,
> > Martin
> 
> Thanks for the hint! It helped in entering ddb. I collected a bit of output,
> which you can find below. If I read the trace correctly the crash is related
> to line 1750 of sys/dev/ic/re.c:
> 
>   d->rl_cmdstat |= htole32(RL_TDESC_CMD_EOF);

Could you test the diff below, always with a MP_LOCKDEBUG kernel and
tell us if you can reproduce the freeze or if the kernel enters ddb(4)?

Another question, how often do you see "watchdog timeout" messages?

Index: re.c
===
RCS file: /cvs/src/sys/dev/ic/re.c,v
retrieving revision 1.201
diff -u -p -r1.201 re.c
--- re.c24 Jan 2017 03:57:34 -  1.201
+++ re.c9 Jun 2017 10:04:43 -
@@ -2074,9 +2074,6 @@ re_watchdog(struct ifnet *ifp)
s = splnet();
printf("%s: watchdog timeout\n", sc->sc_dev.dv_xname);
 
-   re_txeof(sc);
-   re_rxeof(sc);
-
re_init(ifp);
 
splx(s);

OpenBSD and Zope2

[Markus Rosjat]

Hi there,

does someone has a Zope2 4.0a5 or 4.0a6 running out there. The last time 
I came in contact with zope was around 2012 and version 2.10.x  and this 
seems to be a bit outdated or not supported at all anymore.


Im aware that lot has changed in Zope2 since then but befor I skip it 
totally I wanted to check it out but even I get the instance up and 
running I dont cant connect to it. I know its not really a OpenBSD 
Question but since we are on misc I might get lucky :)


regards

--
Markus Rosjatfon: +49 351 8107223mail: ros...@ghweb.de

G+H Webservice GbR Gorzolla, Herrmann
Königsbrücker Str. 70, 01099 Dresden

http://www.ghweb.de
fon: +49 351 8107220   fax: +49 351 8107227

Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss! Before 
you print it, think about your responsibility and commitment to the 
ENVIRONMENT