Re: No xenocara for ATI Radeon HD 2400 XT

2020-08-08 Thread Sebastien Marie
On Sat, Aug 08, 2020 at 10:23:13AM -0600, Andy Bradford wrote:
> Hello,
> 
> The following is found in dmesg:
> 
> initializing kernel modesetting (RV610 0x1002:0x94C1 0x1028:0x0D02 0x00).
> drm:pid0:r600_init *ERROR* Expecting atombios for R600 GPU
> drm:pid0:radeondrm_attachhook *ERROR* Fatal error during GPU init
> [TTM] Memory type 2 has not been initialized
> drm0 detached
> radeondrm0 detached
> vga1 at pci1 dev 0 function 0 "ATI Radeon HD 2400 XT" rev 0x00
> wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation), using wskbd0
> wskbd1: connecting to wsdisplay0
> wsdisplay0: screen 1-5 added (80x25, vt100 emulation)


I have almost the same hardware:

initializing kernel modesetting (RV610 0x1002:0x94C3 0x1028:0x0402 0x00).
drm:pid0:r600_init *ERROR* Expecting atombios for R600 GPU
drm:pid0:radeondrm_attachhook *ERROR* Fatal error during GPU init
[TTM] Memory type 2 has not been initialized
drm0 detached
radeondrm0 detached
vga1 at pci1 dev 0 function 0 "ATI Radeon HD 2400 Pro" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation), using wskbd0
wskbd1: connecting to wsdisplay0
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)


The modesetting failed, but X11 could still work with mesa. It needs
machdep.allowaperture=2 (sysctl) to be set.

You should just add "machdep.allowaperture=2" line in /etc/sysctl.conf and
reboot (this sysctl setting requires to be set at boot-time).

Thanks.
-- 
Sebastien Marie



Re: No xenocara for ATI Radeon HD 2400 XT

2020-08-08 Thread Jonathan Gray
On Sat, Aug 08, 2020 at 10:23:13AM -0600, Andy Bradford wrote:
> Hello,
> 
> I put OpenBSD 6.7 on an older PC that used to run OpenBSD 6.3 and X just
> fine. xenodm refuses to start. Is there  something I can do to make this
> work (edit  sources in xenocara  or kernel  and recompile), or  should I
> just email bugs@?
> 
> The following is found in dmesg:
> 
> initializing kernel modesetting (RV610 0x1002:0x94C1 0x1028:0x0D02 0x00).
> drm:pid0:r600_init *ERROR* Expecting atombios for R600 GPU
> drm:pid0:radeondrm_attachhook *ERROR* Fatal error during GPU init
> [TTM] Memory type 2 has not been initialized

When this came up previously running i386 resulted in being able to read
the atombios.  Can you confirm that is the case here?

The drm code in -current/snapshots has been replaced by a new port of
the linux 5.7 code so behaviour there may change.

> drm0 detached
> radeondrm0 detached
> vga1 at pci1 dev 0 function 0 "ATI Radeon HD 2400 XT" rev 0x00
> wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation), using wskbd0
> wskbd1: connecting to wsdisplay0
> wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
> 
> # fw_update -i
> Installed: radeondrm-firmware-20181218 intel-firmware-20200508v0
> 
> What follows are full dmesg, xenodm.log and Xorg.0.log:
> 
> OpenBSD 6.7 (GENERIC.MP) #5: Tue Jul 21 13:50:07 MDT 2020
> 
> r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 3739795456 (3566MB)
> avail mem = 3613900800 (3446MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.3 @ 0xf0450 (65 entries)
> bios0: vendor Dell Inc. version "A04" date 04/19/2006
> bios0: Dell Inc. Dell DXP051
> acpi0 at bios0: ACPI 3.0
> acpi0: sleep states S0 S1 S3 S4 S5
> acpi0: tables DSDT FACP SSDT APIC BOOT ASF! MCFG HPET
> acpi0: wakeup devices VBTN(S4) PCI0(S5) PCI4(S5) PCI2(S5) PCI3(S5) PCI1(S5) 
> PCI5(S5) PCI6(S5) USB0(S3) USB1(S3) USB2(S3) USB3(S3)
> 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) Pentium(R) D CPU 3.00GHz, 2993.07 MHz, 0f-06-04
> 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,CNXT-ID,CX16,xTPR,PDCM,NXE,LONG,LAHF,MELTDOWN
> cpu0: 2MB 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 199MHz
> cpu0: mwait min=64, max=64
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: Intel(R) Pentium(R) D CPU 3.00GHz, 2992.61 MHz, 0f-06-04
> 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,CNXT-ID,CX16,xTPR,PDCM,NXE,LONG,LAHF,MELTDOWN
> cpu1: 2MB 64b/line 8-way L2 cache
> cpu1: smt 0, core 1, package 0
> ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins, remapped
> acpimcfg0 at acpi0
> acpimcfg0: addr 0xf000, bus 0-63
> acpimcfg0: addr 0x0, bus 0-0
> acpihpet0 at acpi0: 14318179 Hz
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 5 (PCI4)
> acpiprt2 at acpi0: bus 2 (PCI2)
> acpiprt3 at acpi0: bus -1 (PCI3)
> acpiprt4 at acpi0: bus 1 (PCI1)
> acpiprt5 at acpi0: bus 3 (PCI5)
> acpiprt6 at acpi0: bus 4 (PCI6)
> acpicpu0 at acpi0: C1(@1 halt!)
> acpicpu1 at acpi0: C1(@1 halt!)
> acpibtn0 at acpi0: VBTN
> acpipci0 at acpi0 PCI0: _OSC failed
> acpicmos0 at acpi0
> pci0 at mainbus0 bus 0
> pchb0 at pci0 dev 0 function 0 "Intel 82945G Host" rev 0x00
> ppb0 at pci0 dev 1 function 0 "Intel 82945G PCIE" rev 0x00: msi
> pci1 at ppb0 bus 1
> radeondrm0 at pci1 dev 0 function 0 "ATI Radeon HD 2400 XT" rev 0x00
> drm0 at radeondrm0
> radeondrm0: msi
> azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x01: msi
> azalia0: codecs: Sigmatel STAC9220/1
> audio0 at azalia0
> ppb1 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x01: msi
> pci2 at ppb1 bus 2
> ppb2 at pci0 dev 28 function 4 "Intel 82801G PCIE" rev 0x01: msi
> pci3 at ppb2 bus 3
> ppb3 at pci0 dev 28 function 5 "Intel 82801G PCIE" rev 0x01: msi
> pci4 at ppb3 bus 4
> em0 at pci4 dev 0 function 0 "Intel 82573L" rev 0x01: msi, address 
> 00:13:72:1a:ed:5c
> uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x01: apic 8 int 21
> uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x01: apic 8 int 22
> uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x01: apic 8 int 18
> uhci3 at pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x01: apic 8 int 23
> ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x01: apic 8 int 21
> usb0 at ehci0: USB revision 2.0
> uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 
> addr 1
> ppb4 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0xe1
> pci5 at ppb4 bus 5
> "AT&T/Lucent FW322 1394" rev 0x61 at pci5 dev 5 fu

Re: Does OpenBSD support Carrier Grade Nat?

2020-08-08 Thread Stuart Henderson
PF's nat is strict, allowing packets only in response to outgoing packets 
(i.e. from an IP address you already sent packets to), cgn is more likely 
to just pass return packets from any address once the port mapping had been 
established.


You could statically allocate a port range per IP with a long config file, 
but no way to dynamically extend it if you run out of available ports 
beyond what you've configured, and there will be a slowish search through 
the config for each new packet that doesn't match an existing state.


--
 Sent from a phone, apologies for poor formatting.
On 8 August 2020 21:38:10 Brian Brombacher  wrote:


On Aug 8, 2020, at 4:36 AM, Stuart Henderson  wrote:

On 2020-08-07, Edward Carver  wrote:

Hi Misc,

Does OpenBSD support Carrier Grade Nat (cg-nat)?
Thanks for helping..


What do you mean by 'support'?

Running as a client behind one? Yes, that's transparent anyway (unless
you use vmd with its default "local prefix" address range which was
carefully chosen to conflict with the usual CGN address range).

As a router performing nat for others? Sort-of. Some will just say
that CGN is "NAT done by the ISP" and OpenBSD can do that. Others will
say that more is needed - typically CGN installations will dynamically
block off a range of ports for a user and tie in with logging ("user
x was assigned ports 1024-2047 from time y to z") so you can track
activity to a user without recording every single nat mapping (which
is a lot more intrusive information to store), and often allow all
traffic to that range through to the user regardless of whether
the user initiated a connection to that IP (helps for direct machine
to machine access for online gaming etc), OpenBSD doesn't do either
of those.


Hi Stuart,

All coming from a place of curiosity:

I am definitely not knowledgeable on Carrier Grade NAT; however, regarding 
your final two reasons and that OpenBSD may not support this out of the 
box: Could a crafty setup accomplish a CGN using PF and other base 
utilities plus crafty scripting/API integration with PF?


I can surmise PF rules that cover at least the two final reasons you’ve 
mentioned but I’m sure there’s more to it that I’m not understanding.


Thanks,
Brian




Re: Does OpenBSD support Carrier Grade Nat?

2020-08-08 Thread Brian Brombacher


>> On Aug 8, 2020, at 4:36 AM, Stuart Henderson  wrote:
> On 2020-08-07, Edward Carver  wrote:
>> Hi Misc,
>> 
>> Does OpenBSD support Carrier Grade Nat (cg-nat)?
>> Thanks for helping..
> 
> What do you mean by 'support'?
> 
> Running as a client behind one? Yes, that's transparent anyway (unless
> you use vmd with its default "local prefix" address range which was
> carefully chosen to conflict with the usual CGN address range).
> 
> As a router performing nat for others? Sort-of. Some will just say
> that CGN is "NAT done by the ISP" and OpenBSD can do that. Others will
> say that more is needed - typically CGN installations will dynamically
> block off a range of ports for a user and tie in with logging ("user
> x was assigned ports 1024-2047 from time y to z") so you can track
> activity to a user without recording every single nat mapping (which
> is a lot more intrusive information to store), and often allow all
> traffic to that range through to the user regardless of whether
> the user initiated a connection to that IP (helps for direct machine
> to machine access for online gaming etc), OpenBSD doesn't do either
> of those.
> 

Hi Stuart,

All coming from a place of curiosity:

I am definitely not knowledgeable on Carrier Grade NAT; however, regarding your 
final two reasons and that OpenBSD may not support this out of the box: Could a 
crafty setup accomplish a CGN using PF and other base utilities plus crafty 
scripting/API integration with PF?

I can surmise PF rules that cover at least the two final reasons you’ve 
mentioned but I’m sure there’s more to it that I’m not understanding.

Thanks,
Brian



No xenocara for ATI Radeon HD 2400 XT

2020-08-08 Thread Andy Bradford
Hello,

I put OpenBSD 6.7 on an older PC that used to run OpenBSD 6.3 and X just
fine. xenodm refuses to start. Is there  something I can do to make this
work (edit  sources in xenocara  or kernel  and recompile), or  should I
just email bugs@?

The following is found in dmesg:

initializing kernel modesetting (RV610 0x1002:0x94C1 0x1028:0x0D02 0x00).
drm:pid0:r600_init *ERROR* Expecting atombios for R600 GPU
drm:pid0:radeondrm_attachhook *ERROR* Fatal error during GPU init
[TTM] Memory type 2 has not been initialized
drm0 detached
radeondrm0 detached
vga1 at pci1 dev 0 function 0 "ATI Radeon HD 2400 XT" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation), using wskbd0
wskbd1: connecting to wsdisplay0
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)

# fw_update -i
Installed: radeondrm-firmware-20181218 intel-firmware-20200508v0

What follows are full dmesg, xenodm.log and Xorg.0.log:

OpenBSD 6.7 (GENERIC.MP) #5: Tue Jul 21 13:50:07 MDT 2020

r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 3739795456 (3566MB)
avail mem = 3613900800 (3446MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.3 @ 0xf0450 (65 entries)
bios0: vendor Dell Inc. version "A04" date 04/19/2006
bios0: Dell Inc. Dell DXP051
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP SSDT APIC BOOT ASF! MCFG HPET
acpi0: wakeup devices VBTN(S4) PCI0(S5) PCI4(S5) PCI2(S5) PCI3(S5) PCI1(S5) 
PCI5(S5) PCI6(S5) USB0(S3) USB1(S3) USB2(S3) USB3(S3)
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) Pentium(R) D CPU 3.00GHz, 2993.07 MHz, 0f-06-04
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,CNXT-ID,CX16,xTPR,PDCM,NXE,LONG,LAHF,MELTDOWN
cpu0: 2MB 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 199MHz
cpu0: mwait min=64, max=64
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Pentium(R) D CPU 3.00GHz, 2992.61 MHz, 0f-06-04
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,CNXT-ID,CX16,xTPR,PDCM,NXE,LONG,LAHF,MELTDOWN
cpu1: 2MB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins, remapped
acpimcfg0 at acpi0
acpimcfg0: addr 0xf000, bus 0-63
acpimcfg0: addr 0x0, bus 0-0
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 5 (PCI4)
acpiprt2 at acpi0: bus 2 (PCI2)
acpiprt3 at acpi0: bus -1 (PCI3)
acpiprt4 at acpi0: bus 1 (PCI1)
acpiprt5 at acpi0: bus 3 (PCI5)
acpiprt6 at acpi0: bus 4 (PCI6)
acpicpu0 at acpi0: C1(@1 halt!)
acpicpu1 at acpi0: C1(@1 halt!)
acpibtn0 at acpi0: VBTN
acpipci0 at acpi0 PCI0: _OSC failed
acpicmos0 at acpi0
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 82945G Host" rev 0x00
ppb0 at pci0 dev 1 function 0 "Intel 82945G PCIE" rev 0x00: msi
pci1 at ppb0 bus 1
radeondrm0 at pci1 dev 0 function 0 "ATI Radeon HD 2400 XT" rev 0x00
drm0 at radeondrm0
radeondrm0: msi
azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x01: msi
azalia0: codecs: Sigmatel STAC9220/1
audio0 at azalia0
ppb1 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x01: msi
pci2 at ppb1 bus 2
ppb2 at pci0 dev 28 function 4 "Intel 82801G PCIE" rev 0x01: msi
pci3 at ppb2 bus 3
ppb3 at pci0 dev 28 function 5 "Intel 82801G PCIE" rev 0x01: msi
pci4 at ppb3 bus 4
em0 at pci4 dev 0 function 0 "Intel 82573L" rev 0x01: msi, address 
00:13:72:1a:ed:5c
uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x01: apic 8 int 21
uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x01: apic 8 int 22
uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x01: apic 8 int 18
uhci3 at pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x01: apic 8 int 23
ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x01: apic 8 int 21
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 
addr 1
ppb4 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0xe1
pci5 at ppb4 bus 5
"AT&T/Lucent FW322 1394" rev 0x61 at pci5 dev 5 function 0 not configured
pcib0 at pci0 dev 31 function 0 "Intel 82801GH LPC" rev 0x01
pciide0 at pci0 dev 31 function 1 "Intel 82801GB IDE" rev 0x01: DMA, channel 0 
configured to compatibility, channel 1 configured to compatibility
atapiscsi0 at pciide0 channel 0 drive 0
scsibus1 at atapiscsi0: 2 targets
cd0 at scsibus1 targ 0 lun 0:  removable
atapiscsi1 at pciide0 channel 0 drive 1
scsibus2 at atapiscsi1: 2 targets
cd1 at scsibus2 targ 0 lun 0:  removable
cd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
cd1(pc

Re: Julia on OpenBSD?

2020-08-08 Thread Predrag Punosevac
> On July 13 2018 Predrag Punosevac wrote:
> 
> > Hello,
> >
> > has anyone any experience with running Julia (language)
> > on OpenBSD? How difficult was it to set it up? (It isn't
> > in the Ports.)
> >
> >
> 
> As somebody already pointed out bcallah@ was looking more into it but
> last time I looked (1-2 years ago) it would be a major undertaking both
> by upstream and the porter. 
> 
> Even on RHEL which is the most widely used OS for scientific computing
> Julia has to be compiled from the source.
> 
> What are you trying to do with Julia? If you are just trying to do
> science it is probably a bad choice. Jeff Bezanson came here to Carnegie
> Mellon University to give a talk 2 years ago and I was not too
> impressed (arguably I am more interested in science than in computer
> language design). They had immense momentum 5-6 years ago but I think
> the enthusiasm is dissipating at least among scientist.
> 

I am resurrecting this old thread as I evolved from a Julia sceptic to a
Julia user. The language has matured nicely. In my experience, Julia
wins hands down over Python for any scientific computing beyond pure
numerical linear algebra (2d double-precision floating point only data
structure) where MATLAB has an upper edge due to the more mature
debugger and profiler. An example would be

https://diffeq.sciml.ai/latest/index.html

written by Chris Rackauckas which should win Wilkinson prize. In
comparison, Python ODE solvers are a joke. 

In a lieu of the fact that Patrick Wildt just imported LLVM 10.0.0 into
-current, has anybody with a proper skill set looked recently how
difficult would be to port Julia to OpenBSD? Feel free to take the
thread of the mailing list.

Best,
Predrag Punosevac

P.S. If you care primarily for scientific computing like I do then this
is an excellent intro

https://www.sas.upenn.edu/~jesusfv/Chapter_HPC_8_Julia.pdf

also some baby code

https://www.sas.upenn.edu/~jesusfv/Julia_tutorial_script_April_2019.txt

and a mandatory cheat sheet

https://juliadocs.github.io/Julia-Cheat-Sheet/


>
> Cheers,
> Predrag



Re: gdb in uninterruptible wait

2020-08-08 Thread Julian Smith
On Tue, 21 Jul 2020 19:23:44 +0100
Julian Smith  wrote:

> On Mon, 20 Jul 2020 17:18:19 +0100
> Julian Smith  wrote:
> 
> > On Mon, 20 Jul 2020 15:26:11 +
> > Visa Hankala  wrote:
> >   
> > > On Mon, Jul 20, 2020 at 04:35:12AM +, Visa Hankala wrote:
> > > > On Sun, Jul 19, 2020 at 09:47:54PM +0100, Julian Smith wrote:
> > > >
> > > > > I've been finding egdb and gdb rather easily get stuck in an
> > > > > uninterruptible wait, e.g. when running the 'next' command
> > > > > after hitting a breakpoint.
> > 
> > [...]
> >   
> > > > The single-thread check done by wait4() is non-interruptible.
> > > > When the debugger gets stuck, is it blocked in "suspend" state?
> > > >
> > 
> > ps reports it to be in state 'D'.
> >   
> > > > 
> > > > However, I think there is a bug in the single-thread switch
> > > > code. It looks that ps_singlecount can be decremented too much.
> > > > This probably is a regression of making ps_singlecount unsigned
> > > > and letting single_thread_check() run without the kernel lock.
> > > > 
> > > > The bug might go away if single_thread_check() made sure that
> > > > P_SUSPSINGLE is set before the thread suspends.   
> > > 
> > > Below is an updated patch for testing. It extends the scope of
> > > SCHED_LOCK() so that there are fewer chances of interleaving of
> > > single_thread_set() and single_thread_check().
> > 
> > Many thanks for these patches. I'll try to test in the next couple
> > of days. Though the last time i built an OpenBSD kernel was well
> > over a decade ago, so it might take me a little longer.  
> 
> I managed to build a patched kernel, and it seems to fix the problem -
> i haven't been able to get egdb into an uninterruptable wait state.
> 
> Also, i've been running the patched kernel all day now and it doesn't
> seem to be causing any problems elsewhere.

Unfortunately the same problem has just occurred again. I've run egdb
quite a few times since i updated the kernel, so the patch has
definitely reduced the problem, but it doesn't seem to have eliminated
it.

Let me know if there anything i could do to find out more information.

Thanks,

- Jules

-- 
http://op59.net




Re: deep web cookie

2020-08-08 Thread sylvain . saboua
The pre-bigbang would not have "wanted" the universe to happen

> 
> I find the equation in the end :
> c = λ/2 * ( 1 - λ/2 )
> is a good explanation for the origin
> of "light" if λ is taken to mean the
> "first moment."
> 
> Sylvain
> emails by spamgourmet.com
> 
> - Mail original -
> > De: "sylvain saboua" 
> > À: misc@openbsd.org
> > Envoyé: Vendredi 14 Février 2020 07:35:11
> > Objet: deep web cookie
> > 
> > (read attached picture)
> > 
> > Sylvain
> > emails by spamgourmet.com
> > 
> > 
> 



Re: Does OpenBSD support Carrier Grade Nat?

2020-08-08 Thread Stuart Henderson
On 2020-08-07, Edward Carver  wrote:
> Hi Misc,
>
> Does OpenBSD support Carrier Grade Nat (cg-nat)?
> Thanks for helping..

What do you mean by 'support'?

Running as a client behind one? Yes, that's transparent anyway (unless
you use vmd with its default "local prefix" address range which was
carefully chosen to conflict with the usual CGN address range).

As a router performing nat for others? Sort-of. Some will just say
that CGN is "NAT done by the ISP" and OpenBSD can do that. Others will
say that more is needed - typically CGN installations will dynamically
block off a range of ports for a user and tie in with logging ("user
x was assigned ports 1024-2047 from time y to z") so you can track
activity to a user without recording every single nat mapping (which
is a lot more intrusive information to store), and often allow all
traffic to that range through to the user regardless of whether
the user initiated a connection to that IP (helps for direct machine
to machine access for online gaming etc), OpenBSD doesn't do either
of those.