Re: Can you specify which interface DHCP should serve on, in /etc/dhcpd.conf , or only via arg?

[Marcus MERIGHI]

t1...@protonmail.ch (Tinker), 2018.02.27 (Tue) 07:12 (CET):
> Just so I not missed anything in reading the man pages [1]:
> 
> If you have a machine with an external and an internal NIC e.g. em0 and
> em1 , and you want to serve DHCP only on em1 , then the only way to do
> that is as a dhcpd argument, e.g. add a line 'dhcpd="em1"' to
> /etc/rc.conf.local or alternatively add a line "dhcpd em1" to
> /etc/rc.local - there is _no way_ to specify in /etc/dhcpd.conf which
> network interfaces dhcpd will bind/serve on, right?
> 
> Has this been for a particular reason (i.e. it's a feature) or just
> noone bothered?
> 
> The usecase I describe above should be typical.

dhcpd(8) reads the subnet declarations from dhcpd.conf(5) and get's to
the interface from there. It does not listen like other network daemons
but uses bpf(4). Try to block it with pf(4)... ;-)

Marcus

Can you specify which interface DHCP should serve on, in /etc/dhcpd.conf , or only via arg?

[Tinker]

Hi misc@,

Just so I not missed anything in reading the man pages [1]:

If you have a machine with an external and an internal NIC e.g. em0 and
em1 , and you want to serve DHCP only on em1 , then the only way to do
that is as a dhcpd argument, e.g. add a line 'dhcpd="em1"' to
/etc/rc.conf.local or alternatively add a line "dhcpd em1" to
/etc/rc.local - there is _no way_ to specify in /etc/dhcpd.conf which
network interfaces dhcpd will bind/serve on, right?

Has this been for a particular reason (i.e. it's a feature) or just
noone bothered?

The usecase I describe above should be typical.

Thanks,
Tinker

[1]
http://man.openbsd.org/dhcpd
http://man.openbsd.org/dhcpd.conf.5

httpd howto redirect port 80 to 443 in vm

[niya]

hi
using vmd in openbsd 6.2
and following 
http://thecyberrecce.net/2017/01/15/secure-webservers-with-openbsd-6-0-setting-up-httpd-mariadb-and-php/

i have setup openbsd running a webserver
everything installed and the webserver works via port 80 and 443.
i can access the webserver from a remote client by browsing to the ip of 
the host machine and redirecting to the vm address and port using pf.
i tried to setup port 80 redirection to port 443 so that all all access 
is over HTTPS, when i use http://host ip, i am redirected to 
https://default/
how do i get the webserver to redirect to the ip address of the host 
machine?


my httpd.conf

server "default" {
    listen on $ext_addr port 80 block return 301 
"https://$SERVER_NAME$REQUEST_URI;

#   listen on $ext_addr port 80
    listen on $ext_addr tls port 443
    tls {
    key "/etc/ssl/private/server.key"
    certificate "/etc/ssl/server.crt"
    }
    directory {
    index "index.php"
    }
    location "*.php" {
    fastcgi socket "/run/php-fpm.sock"
    }


shadrock

Re: Supermicro SuperServer E200-9A

[Stuart Henderson]

On 2018-02-26, OpenBSD user  wrote:
> Hello
>
> I want to build a OpenBSD firewall. And I have bought a Supermicro
> SuperServer E200-9A. There is installed a A2SDi-4C-HLN4F motherboard in it.
>
> I'm trying to installed OpenBSD 6.2 on it, but I have some problems.
>
> First I tried to boot it from an usb stick and thought I could use the
> installed keyboard to control the installation. But under the boot
> process and before I could type "i" for install, it had turned the
> keyboard off.
>
> Then I tried to control the installation from the IPMI port. I can
> control the installation through it, but when I'm went to configure the
> NIC's there is only a VLAN installed. Beside the IPMI port there is also
> 4 other NIC's installed on the motherboard. And I can't see them. I type
> "done" but when the installation come to the installed hdd, there is
> none to choose between.
>
> I have visit the manufacturer site, but there isn't any drivers to any *BSD.
>
> I have googled for other who have problems, but I can't find any solutions.
>
> How do I installed OpenBSD 6.2 on the E200-9A ?
>
> Please help.
>
> Thanks in advance
>
>

This machine has a lot of rather new hardware in (C3000 Denverton) and
is really not at all supported yet.

I found a dmesg from RAMDISK_CD on one of these and it's full of failure
starting with being unable to enable acpi (so interrupt routing and
other things aren't working), plus we haven't even got skeleton pcidevs
entries for most of the devices (ahci, nic, etc).

Realistically, at the moment, I'd say the best chances of getting this
machine supported are if you can get similar hardware in the hands of a
developer if there is anyone with interest, skills and time to look into
it, remote debugging of a system in this state is going to be slow and
painful..


OpenBSD 6.2-current (RAMDISK_CD) #379: Wed Jan 24 12:58:41 MST 2018
dera...@amd64.openbsd.org:/usr/src/sys/al mem = 4250882048 (4053MB)
avail mem = 4118294528 (3927MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x7f0c7000 (31 entries)
bios0: vendor American Megatrends Inc. version "1.0" date 08/02/2017
bios0: Supermicro Super Server
acpi0 at bios0: rev 2, can't enable ACPI
cpu0 at mainbus0: (uniprocessor)
cpu0: Intel(R) Atom(TM) CPU C3338 @ 1.50:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,SENSOR,ARAT
cpu0: 2MB 64b/line 16-way L2 cache
cpu0: cannot disable silicon debug
cpu0: mwait min=64, max=64, C-substates=0.2.0.2, IBE
pci0 at mainbus0 bus 0
0:31:5: mem address conflict 0xfe01/0x1000
pchb0 at pci0 dev 0 function 0 vendor "Intel", unknown product 0x1980
rev 0x11
pchb1 at pci0 dev 4 function 0 vendor "Intel", unknown product 0x19a1
rev 0x11
vendor "Intel", unknown product 0x19a2 (class system subclass root
complex event, rev 0x11) at pci0 dev 5 function 0 not configured
ppb0 at pci0 dev 10 function 0 vendor "Intel", unknown product 0x19a5
rev 0x11
pci1 at ppb0 bus 1
ppb1 at pci0 dev 17 function 0 vendor "Intel", unknown product 0x19ab
rev 0x11
pci2 at ppb1 bus 2
ppb2 at pci2 dev 0 function 0 "ASPEED Technology AST1150 PCI" rev 0x03
pci3 at ppb2 bus 3
"ASPEED Technology AST2000" rev 0x30 at pci3 dev 0 function 0 not configured
vendor "Intel", unknown product 0x19ac (class system subclass
miscellaneous, rev 0x11) at pci0 dev 18 function 0 not configured
ahci0 at pci0 dev 19 function 0 vendor "Intel", unknown product 0x19b2
rev 0x11: unable to map interrupt
ahci1 at pci0 dev 20 function 0 vendor "Intel", unknown product 0x19c2
rev 0x11: unable to map interrupt
xhci0 at pci0 dev 21 function 0 vendor "Intel", unknown product 0x19d0
rev 0x11: couldn't map interrupt
ppb3 at pci0 dev 22 function 0 vendor "Intel", unknown product 0x19d1
rev 0x11
pci4 at ppb3 bus 4
vendor "Intel", unknown product 0x15e5 (class network subclass ethernet,
rev 0x11) at pci4 dev 0 function 0 not configured
vendor "Intel", unknown product 0x15e5 (class network subclass ethernet,
rev 0x11) at pci4 dev 0 function 1 not configured
ppb4 at pci0 dev 23 function 0 vendor "Intel", unknown product 0x19d2
rev 0x11
pci5 at ppb4 bus 5
vendor "Intel", unknown product 0x15e5 (class network subclass ethernet,
rev 0x11) at pci5 dev 0 function 0 not configured
vendor "Intel", unknown product 0x15e5 (class network subclass ethernet,
rev 0x11) at pci5 dev 0 function 1 not configured
vendor "Intel", unknown product 0x19d3 (class communications subclass
miscellaneous, rev 0x11) at pci0 dev 24 function 0 not configured
vendor "Intel", unknown product 0x19dc (class bridge subclass ISA, rev
0x11) at pci0 dev 31 function 0 not configured
vendor "Intel", unknown product 0x19de (class memory subclass
miscellaneous, rev 0x11) at pci0 dev 31 function 

Re: Black screen when starting Xorg with new laptop.

[George Ramirez]

Sadly this didn't work. I tried the keys for the screen brightness but
nothing changed.

On Thu, Feb 22, 2018 at 3:29 PM, Andrew  wrote:

> On 02/22/18 09:27, George Ramirez wrote:
>
>> with intel 620 UHD graphics. At first, the console shows with underscan,
>> then the resolution changes to the native one, and finally it goes black.
>>
>
> It's a frustrating problem because there are no errors and it seemingly
> doesn't work. I bet X is actually running properly but xbacklight
> somehow ended up = 0. Tap the "brightness" key on your keyboard a couple
> times and see if it illuminates the display properly. On my ThinkPad
> it's [Fn]+[Home]. Also check out man xbacklight(1). Good luck !!!
>

Re: Queuing faster than 4 Gbps

[Stuart Henderson]

On 2018-02-26, Peter N. M. Hansteen  wrote:
> On 02/26/18 17:50, BARDOU Pierre wrote:
>> Hello,
>> 
>> I'm trying to use queuing on a 10 Gbps interface.
>> I remind of a conversation on tech@ or misc@ which was about queuing values 
>> being stored in a UINT which prevented configuring values > 4 Gbps.
>> I can't find it in the mailing list archive logs though. Wasn't the 
>> discussion about using long integers and so remove this limitation ?
>
> If I remember correctly, the bandwidth values were 32-bit in ALTQ,
> effectively limiting the upper bandwidth value to something like what
> you suggest.  The current queueing code is quite different in most respects.
>
>> As of today current, it seem to be still present. Any plans to upgrade this 
>> in the (near) future ?
>
> I'm a bit curious as to how you reached this conclusion. You're hitting
> one or more limits in your environment, but how do you identify which one?
>

$ echo 'queue foo on em0 default bandwidth 4294967295'|pfctl -nvf - 
queue foo on em0 bandwidth 4294967295  default

$ echo 'queue foo on em0 default bandwidth 4294967296'|pfctl -nvf -
stdin:1: bandwidth number too big

... Though if specified in other units, it wraps around:

$ echo 'queue foo on em0 default bandwidth 4.3G'|pfctl -nvf - 
queue foo on em0 bandwidth 5032704  default

meltdown supported

[Jan Stary]

I just upgraded to current/amd64. Nothing special here, it's a PC.
Only wanted to note that the new MELTDOWN feature of the CPU
is correctly recognized.

Jan


OpenBSD 6.2-current (GENERIC.MP) #0: Mon Feb 26 15:04:31 CET 2018
h...@biblio.stare.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8486649856 (8093MB)
avail mem = 8222433280 (7841MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf0100 (36 entries)
bios0: vendor Award Software International, Inc. version "F2" date 04/20/2011
bios0: Gigabyte Technology Co., Ltd. Z68MX-UD2H-B3
acpi0 at bios0: rev 0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP HPET MCFG ASPT SSPT EUDS MATS TAMG APIC SSDT MATS
acpi0: wakeup devices PEX0(S5) PEX1(S5) PEX2(S5) PEX3(S5) PEX4(S5) PEX5(S5) 
PEX6(S5) PEX7(S5) HUB0(S5) UAR1(S3) USBE(S3) USE2(S3) AZAL(S5) PCI0(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimcfg0 at acpi0 addr 0xf400, bus 0-63
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz, 3193.17 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
acpihpet0: recalibrated TSC frequency 3092989561 Hz
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz, 3192.75 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz, 3192.75 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz, 3192.75 MHz
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT,MELTDOWN
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
, remapped to apid 2
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (PEG0)
acpiprt2 at acpi0: bus -1 (PEG1)
acpiprt3 at acpi0: bus 2 (PEX0)
acpiprt4 at acpi0: bus -1 (PEX1)
acpiprt5 at acpi0: bus -1 (PEX2)
acpiprt6 at acpi0: bus -1 (PEX3)
acpiprt7 at acpi0: bus 3 (PEX4)
acpiprt8 at acpi0: bus 4 (PEX5)
acpiprt9 at acpi0: bus 5 (PEX6)
acpiprt10 at acpi0: bus 6 (PEX7)
acpicpu0 at acpi0: C3(350@96 mwait.1@0x20), C2(500@64 mwait.1@0x10), C1(1000@1 
mwait.1), PSS
acpicpu1 at acpi0: C3(350@96 mwait.1@0x20), C2(500@64 mwait.1@0x10), C1(1000@1 
mwait.1), PSS
acpicpu2 at acpi0: C3(350@96 mwait.1@0x20), C2(500@64 mwait.1@0x10), C1(1000@1 
mwait.1), PSS
acpicpu3 at acpi0: C3(350@96 mwait.1@0x20), C2(500@64 mwait.1@0x10), C1(1000@1 
mwait.1), PSS
acpibtn0 at acpi0: PWRB
"ICD0001" at acpi0 not configured
"pnp0c14" at acpi0 not configured
"INT3F0D" at acpi0 not configured
cpu0: Enhanced SpeedStep 3193 MHz: speeds: 3301, 3300, 3200, 3100, 3000, 2900, 
2800, 2700, 2600, 2500, 2400, 2300, 2200, 2100, 2000, 1900, 1800, 1700, 1600 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Core 2G Host" rev 0x09
ppb0 at pci0 dev 1 function 0 "Intel Core 2G PCIE" rev 0x09: msi
pci1 at ppb0 bus 1
em0 at pci1 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address 
68:05:ca:33:6a:61
inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 2000" rev 0x09
drm0 at inteldrm0
inteldrm0: msi
inteldrm0: 1920x1080, 32bpp
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
"Intel 6 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured
ehci0 at pci0 dev 26 function 0 "Intel 6 Series USB" rev 0x05: apic 2 int 18
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Intel 

Supermicro SuperServer E200-9A

[OpenBSD user]

Hello

I want to build a OpenBSD firewall. And I have bought a Supermicro
SuperServer E200-9A. There is installed a A2SDi-4C-HLN4F motherboard in it.

I'm trying to installed OpenBSD 6.2 on it, but I have some problems.

First I tried to boot it from an usb stick and thought I could use the
installed keyboard to control the installation. But under the boot
process and before I could type "i" for install, it had turned the
keyboard off.

Then I tried to control the installation from the IPMI port. I can
control the installation through it, but when I'm went to configure the
NIC's there is only a VLAN installed. Beside the IPMI port there is also
4 other NIC's installed on the motherboard. And I can't see them. I type
"done" but when the installation come to the installed hdd, there is
none to choose between.

I have visit the manufacturer site, but there isn't any drivers to any *BSD.

I have googled for other who have problems, but I can't find any solutions.

How do I installed OpenBSD 6.2 on the E200-9A ?

Please help.

Thanks in advance

gif(4) changes vs tunnelbroker

[Pavel Korovin]

Dear all,

After upgrading several hosts to -current I noticed that all my IPv6 tunnels
via tunnelbroker stopped working. Recently introduced changes to gif(4) (since 
late December 2017) are too complex for me to grasp, maybe anybody on the list
can advise.

-- 
With best regards,
Pavel Korovin

Re: Booting OpenBSD on a HP Compaq Desktop

[Israel Brewster]

On Feb 26, 2018, at 8:10 AM, Stuart Henderson  wrote:
> 
> On 2018/02/26 07:50, Israel Brewster wrote:
>>On Feb 24, 2018, at 3:06 AM, Stuart Henderson  
>> wrote:
>> 
>>On 2018-02-24, Israel Brewster  wrote:
>> 
>>I have an HP Compaq Pro 6300 machine on which I am trying to run
>>OpenBSD. The installer boots and runs fine, but after rebooting into 
>> the
>>newly installed OS, I start getting the boot sequence (the white text 
>> on
>>blue background stuff - don't know what that is officially called), 
>> but
>>after a second or so the screen goes blank and that's all she wrote.
>> 
>>My first thought was that it was just a display issue, and that I
>>should be able to ssh in and tweak stuff, but as it turns out, the
>>machine never shows up on the network, either, so apparently it never
>>gets far enough in the boot process to enable the network (networking
>>*does* work while I am running through the installer, so I don't think
>>it's just a missing network driver there).
>> 
>> 
>>It sounds like it's crashing after the video mode is changed. The
>>machine probably has inteldrm so at the boot loader prompt, try
>>"boot -c", then at UKC "disable inteldrm" and "quit".
>> 
>> 
>> Bingo! that did the trick - got a good clean boot after running that 
>> command. The only issue
>> appears to be that I'm going to have to do that every time I boot. Given 
>> that, how do I make it
>> stick? Or, now that we know that is the issue, is there some other, more 
>> permanent "fix" I can
>> try? Do I need that inteldrm for any reason?
> 
> You'll want it if the machine will be running X.

It won't be. It's role in life is to be a FTP/SFTP server, so no need for X.

> 
> It's possible to modify an on-disk kernel with config(8)'s -e flag, but
> that has other problems (not least, syspatch won't be able to update the
> kernel).

Gotcha. It did work to allow ongoing booting, but I'll keep trying other 
solutions.

> 
>>That may let it boot, if not then you're at least more likely to see
>>a hidden error message of some sort.
>> 
>>If this is 6.2, try -current instead. If it's OpenBSD/i386, try amd64
>>instead.
>> 
>> 
>> Since disabling inteldrm seemed to bypass the issue, if only temporarily, 
>> would these still be
>> worth trying, or were they just additional suggestions if the inteldrm thing 
>> didn't work?
> 
> Definitely worth trying, it would be better to have a fix than a workaround,
> and without trying -current you won't know if it's already been fixed. With
> the information you've given so far we have very little idea about what you're
> running or what hardware.

My apologies, I mean't to mention that, but it slipped my mind (kind of like 
remembering to remove the stupid image signature my boss insists upon). This is 
a brand-new install of OpenBSD 6.2, running on a HP Compaq Pro 6300, stock 
hardware (no add-in cards or the like). 

> 
> Please send a bug report with the files generated from sendbug (run as root).
> It's often easiest to do "sendbug -P > /tmp/template.txt" then copy that to
> another machine, edit to add a description etc, and send the whole thing
> to b...@openbsd.org .

Will do. Thanks!

---
Israel Brewster
Systems Analyst II
Ravn Alaska
5245 Airport Industrial Rd
Fairbanks, AK 99709
(907) 450-7293
---

Re: Queuing faster than 4 Gbps

[Peter N. M. Hansteen]

On 02/26/18 17:50, BARDOU Pierre wrote:
> Hello,
> 
> I'm trying to use queuing on a 10 Gbps interface.
> I remind of a conversation on tech@ or misc@ which was about queuing values 
> being stored in a UINT which prevented configuring values > 4 Gbps.
> I can't find it in the mailing list archive logs though. Wasn't the 
> discussion about using long integers and so remove this limitation ?

If I remember correctly, the bandwidth values were 32-bit in ALTQ,
effectively limiting the upper bandwidth value to something like what
you suggest.  The current queueing code is quite different in most respects.

> As of today current, it seem to be still present. Any plans to upgrade this 
> in the (near) future ?

I'm a bit curious as to how you reached this conclusion. You're hitting
one or more limits in your environment, but how do you identify which one?

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Re: Booting OpenBSD on a HP Compaq Desktop

[Stuart Henderson]

On 2018/02/26 07:50, Israel Brewster wrote:
> On Feb 24, 2018, at 3:06 AM, Stuart Henderson  
> wrote:
> 
> On 2018-02-24, Israel Brewster  wrote:
> 
> I have an HP Compaq Pro 6300 machine on which I am trying to run
> OpenBSD. The installer boots and runs fine, but after rebooting into 
> the
> newly installed OS, I start getting the boot sequence (the white text 
> on
> blue background stuff - don't know what that is officially called), 
> but
> after a second or so the screen goes blank and that's all she wrote.
> 
> My first thought was that it was just a display issue, and that I
> should be able to ssh in and tweak stuff, but as it turns out, the
> machine never shows up on the network, either, so apparently it never
> gets far enough in the boot process to enable the network (networking
> *does* work while I am running through the installer, so I don't think
> it's just a missing network driver there).
> 
> 
> It sounds like it's crashing after the video mode is changed. The
> machine probably has inteldrm so at the boot loader prompt, try
> "boot -c", then at UKC "disable inteldrm" and "quit".
> 
> 
> Bingo! that did the trick - got a good clean boot after running that command. 
> The only issue
> appears to be that I'm going to have to do that every time I boot. Given 
> that, how do I make it
> stick? Or, now that we know that is the issue, is there some other, more 
> permanent "fix" I can
> try? Do I need that inteldrm for any reason?

You'll want it if the machine will be running X.

It's possible to modify an on-disk kernel with config(8)'s -e flag, but
that has other problems (not least, syspatch won't be able to update the
kernel).

> That may let it boot, if not then you're at least more likely to see
> a hidden error message of some sort.
> 
> If this is 6.2, try -current instead. If it's OpenBSD/i386, try amd64
> instead.
> 
> 
> Since disabling inteldrm seemed to bypass the issue, if only temporarily, 
> would these still be
> worth trying, or were they just additional suggestions if the inteldrm thing 
> didn't work?

Definitely worth trying, it would be better to have a fix than a workaround,
and without trying -current you won't know if it's already been fixed. With
the information you've given so far we have very little idea about what you're
running or what hardware.

Please send a bug report with the files generated from sendbug (run as root).
It's often easiest to do "sendbug -P > /tmp/template.txt" then copy that to
another machine, edit to add a description etc, and send the whole thing
to b...@openbsd.org.

Queuing faster than 4 Gbps

[BARDOU Pierre]

Hello,

I'm trying to use queuing on a 10 Gbps interface.
I remind of a conversation on tech@ or misc@ which was about queuing values 
being stored in a UINT which prevented configuring values > 4 Gbps.
I can't find it in the mailing list archive logs though. Wasn't the discussion 
about using long integers and so remove this limitation ?

As of today current, it seem to be still present. Any plans to upgrade this in 
the (near) future ?

Thank you

--
Cordialement,
Pierre Bardou

Re: Booting OpenBSD on a HP Compaq Desktop

[Israel Brewster]

> On Feb 24, 2018, at 3:06 AM, Stuart Henderson  wrote:
> 
> On 2018-02-24, Israel Brewster  wrote:
>> I have an HP Compaq Pro 6300 machine on which I am trying to run
>> OpenBSD. The installer boots and runs fine, but after rebooting into the
>> newly installed OS, I start getting the boot sequence (the white text on
>> blue background stuff - don't know what that is officially called), but
>> after a second or so the screen goes blank and that's all she wrote.
>> 
>> My first thought was that it was just a display issue, and that I
>> should be able to ssh in and tweak stuff, but as it turns out, the
>> machine never shows up on the network, either, so apparently it never
>> gets far enough in the boot process to enable the network (networking
>> *does* work while I am running through the installer, so I don't think
>> it's just a missing network driver there).
> 
> It sounds like it's crashing after the video mode is changed. The
> machine probably has inteldrm so at the boot loader prompt, try
> "boot -c", then at UKC "disable inteldrm" and "quit".

Bingo! that did the trick - got a good clean boot after running that command. 
The only issue appears to be that I'm going to have to do that every time I 
boot. Given that, how do I make it stick? Or, now that we know that is the 
issue, is there some other, more permanent "fix" I can try? Do I need that 
inteldrm for any reason?

> 
> That may let it boot, if not then you're at least more likely to see
> a hidden error message of some sort.
> 
> If this is 6.2, try -current instead. If it's OpenBSD/i386, try amd64
> instead.

Since disabling inteldrm seemed to bypass the issue, if only temporarily, would 
these still be worth trying, or were they just additional suggestions if the 
inteldrm thing didn't work?

---
Israel Brewster
Systems Analyst II
Ravn Alaska
5245 Airport Industrial Rd
Fairbanks, AK 99709
(907) 450-7293
---
> 
> 

Re: kernel panic with cmp

[Krzysztof Strzeszewski]

Hardware was bad, now it's ok.


W dniu 17.02.2018 o 08:23, Krzysztof Strzeszewski pisze:
> Hi,
>
> I have kernel panic in OpenBSD 6.1 end 6.2 on the same machine. Command
> "cmp" is in my script , it starts every minute. When I don't use "cmp"
> command with my script, is ok. This kernel panic is after the last path
> of February 2, 2018. Kernel is default from upgrade.
>
>
> Links:
>
> #--
>
> https://nroot.pl/kernel/kernel_panic_openbsd_6.1.JPG
>
> https://nroot.pl/kernel/kernel_panic_openbsd_6.2.JPG
>
> https://nroot.pl/kernel/mem_test.JPG
>
> #--
>
>
> 
> Regards,
> Krzych
>
>
>