Re: Failure to start vmd

2023-10-03 Thread vitmau...@gmail.com
Dear Atticus,

thank you for this information. That missing "EPT" seems to be essential,
then.

Cheers,
Vitor


Em ter., 3 de out. de 2023 13:30, B. Atticus Grobe 
escreveu:

> The E8400 processor doesn't support extended page tables, which vmm
> requires. AFAIK, all modern hypervisors require this.
>


Failure to start vmd

2023-10-03 Thread vitmau...@gmail.com
Hi,

I'm trying to fiddle with OpenBSD's virtualization capabilities, but I
couldn't manage to start vmd. The console gives me the error "vmd(failed)"
and my /var/log/message says "vmd[31605]: vmd: /dev/vmm: Operation not
supported by device". I enabled the "Virtualization Technology" and "VT-d"
options on my bios and fw_update indicates that vmm is already installed. I
did a grep on my dmesg to look for "VMX/EPT" (as suggested by OpenBSD's
FAQ), but only occurrences of "VMX".

Anybody has any idea about what might be wrong?

Here's my dmesg.

OpenBSD 7.2 (GENERIC.MP) #5: Tue Jul 25 16:20:58 CEST 2023
r...@syspatch-72-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/
GENERIC.MP
real mem = 6254428160 (5964MB)
avail mem = 6047473664 (5767MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf0100 (40 entries)
bios0: vendor Itautec ST 4262, LTD 6.00 PG version "FC" date 08/21/2009
bios0: Itautec S.A. Infoway
acpi0 at bios0: ACPI 1.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP ASF! HPET MCFG APIC SSDT
acpi0: wakeup devices PCI0(S5) PEX0(S5) PEX1(S5) PEX2(S5) PEX3(S5) PEX4(S5)
PEX5(S5) HUB0(S5) UAR1(S3) UAR2(S3) IGBE(S4) USB0(S3) USB1(S3) USB2(S3)
USB3(S3) USB4(S3) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimcfg0 at acpi0
acpimcfg0: addr 0xd000, bus 0-255
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz, 2826.29 MHz, 06-17-0a
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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 6MB
64b/line 24-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 332MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz, 2826.26 MHz, 06-17-0a
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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 6MB
64b/line 24-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins, remapped
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (PEX0)
acpiprt2 at acpi0: bus -1 (PEX1)
acpiprt3 at acpi0: bus -1 (PEX2)
acpiprt4 at acpi0: bus -1 (PEX3)
acpiprt5 at acpi0: bus -1 (PEX4)
acpiprt6 at acpi0: bus -1 (PEX5)
acpiprt7 at acpi0: bus 2 (HUB0)
acpibtn0 at acpi0: PWRB
acpipci0 at acpi0 PCI0
acpicmos0 at acpi0
com0 at acpi0 UAR1 addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo
com1 at acpi0 UAR2 addr 0x2f8/0x8 irq 3: ns16550a, 16 byte fifo
acpicpu0 at acpi0: C1(@1 halt!), FVS, 2667, 2000 MHz
acpicpu1 at acpi0: C1(@1 halt!), FVS, 2667, 2000 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Q45 Host" rev 0x03
inteldrm0 at pci0 dev 2 function 0 "Intel Q45 Video" rev 0x03
drm0 at inteldrm0
intagp0 at inteldrm0
agp0 at intagp0: aperture at 0xe000, size 0x1000
inteldrm0: apic 2 int 16, G45, gen 4
"Intel Q45 Video" rev 0x03 at pci0 dev 2 function 1 not configured
"Intel Q45 HECI" rev 0x03 at pci0 dev 3 function 0 not configured
pciide0 at pci0 dev 3 function 2 "Intel Q45 PT IDER" rev 0x03: DMA
(unsupported), channel 0 wired to native-PCI, channel 1 wired to native-PCI
pciide0: using apic 2 int 18 for native-PCI interrupt
pciide0: channel 0 ignored (not responding; disabled or no drives?)
pciide0: channel 1 ignored (not responding; disabled or no drives?)
puc0 at pci0 dev 3 function 3 "Intel Q45 KT" rev 0x03: ports: 16 com
com4 at puc0 port 0 apic 2 int 17: ns16550a, 16 byte fifo
com4: probed fifo depth: 15 bytes
em0 at pci0 dev 25 function 0 "Intel ICH10 D BM LM" rev 0x02: apic 2 int
20, address 6c:f0:49:fa:26:2e
uhci0 at pci0 dev 26 function 0 "Intel 82801JD USB" rev 0x02: apic 2 int 16
uhci1 at pci0 dev 26 function 1 "Intel 82801JD USB" rev 0x02: apic 2 int 21
uhci2 at pci0 dev 26 function 2 "Intel 82801JD USB" rev 0x02: apic 2 int 18
ehci0 at pci0 dev 26 function 7 "Intel 82801JD USB" rev 0x02: apic 2 int 18
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
azalia0 at pci0 dev 27 function 0 "Intel 82801JD HD Audio" rev 0x02: apic 2
int 22
azalia0: codecs: Realtek ALC888
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 "Intel 82801JD PCIE" rev 0x02: apic 2 int 16
pci1 at ppb0 bus 1
uhci3 at pci0 dev 29 function 0 "Intel 82801JD USB" rev 0x02: apic 2 int 23
uhci4 at pci0 dev 29 function 1 "Intel 82801JD USB" rev 0x02: 

Re: Speed: dump/restore vs rsync

2023-09-23 Thread vitmau...@gmail.com
Dear Janne,

thanks for the tip. I'll try it.

Cheers,
Vitor

Em sáb., 23 de set. de 2023 02:36, Janne Johansson 
escreveu:

> Den fre 22 sep. 2023 kl 20:17 skrev vitmau...@gmail.com <
> vitmau...@gmail.com>:
>
>> Hi,
>>
>> I used the command "cd /SRC && dump 0f - . | (cd /DST && restore -rf - )"
>> as suggested by the "Disk Setup" section of the FAQ to transfer everything
>> from one of my old hard disks to the one that should replace it. However,
>> I'm stuck with something around 35 megabytes/s of speed transfer (measured
>> using "systat -h io") following this path. If I use rsync, I get something
>> around 70 megabytes/s (measured by both the "--progress" option and
>> systat). Am I missing something? Is this to be expected?
>>
>
> While I can't comment on the actual numbers, one thing one could consider
> when restoring (from any medium/type) into a new empty file system is that
> you can mount the destination fs async during the restore in order to speed
> it up a bit.
>
> While running with async all the time is not a good idea, the reasoning
> here is that if you get a half-restore (from some error you can fix) you
> would want to restart the restore fully anyhow, so in that case async isn't
> a problem while restoring. Then you need to remount or unmount the async so
> that you are really sure it flushes all writes before you start running on
> it, or rebooting.
>
> --
> May the most significant bit of your life be positive.
>


Re: Speed: dump/restore vs rsync

2023-09-22 Thread vitmau...@gmail.com
Dear Philip,

thank you for pulling my ears. The complete error message is:

DUMP: Warning: undefined file type 013

Best,
Vitor

Em sex., 22 de set. de 2023 às 16:17, Philip Guenther 
escreveu:

> On Fri, Sep 22, 2023 at 11:18 AM vitmau...@gmail.com 
> wrote:
>
>> I'm also getting an "undefined file type" error from dump. I found one guy
>> from the FreeBSD mail list that got the same error, but he solved his
>> problem using fsck on the partition. I forced fsck on my side, since the
>> filesystem was marked as clean, but to no avail.
>>
>
> In OpenBSD's dump, that warning includes the actual file type which
> provoked the error:
>
>  : bleys; pwd
> /usr/src/sbin/dump
> : bleys; grep  'undefined file type' *.c
> traverse.c: msg("Warning: undefined file type 0%o\n",
> : bleys;
>
> Since yours didn't include that, you would appear to be running some other
> version of dump, which would make this the wrong place to get help.
>
> ...unless you truncated an error message before asking about it, which is
> kinda self-defeating.
>
>
> Philip Guenther
>
>


Speed: dump/restore vs rsync

2023-09-22 Thread vitmau...@gmail.com
Hi,

I used the command "cd /SRC && dump 0f - . | (cd /DST && restore -rf - )"
as suggested by the "Disk Setup" section of the FAQ to transfer everything
from one of my old hard disks to the one that should replace it. However,
I'm stuck with something around 35 megabytes/s of speed transfer (measured
using "systat -h io") following this path. If I use rsync, I get something
around 70 megabytes/s (measured by both the "--progress" option and
systat). Am I missing something? Is this to be expected?

I'm also getting an "undefined file type" error from dump. I found one guy
from the FreeBSD mail list that got the same error, but he solved his
problem using fsck on the partition. I forced fsck on my side, since the
filesystem was marked as clean, but to no avail.

I don't know if this information is relevant, but the partition I'm copying
the files from is mounted "ro,nodev,nosuid". The partition I'm copying the
files to is mounted "rw,nodev,nosuid".

Here is my dmesg:

OpenBSD 7.2 (GENERIC.MP) #5: Tue Jul 25 16:20:58 CEST 2023
r...@syspatch-72-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/
GENERIC.MP
real mem = 6254428160 (5964MB)
avail mem = 6047461376 (5767MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf0100 (40 entries)
bios0: vendor Itautec ST 4262, LTD 6.00 PG version "FC" date 08/21/2009
bios0: Itautec S.A. Infoway
acpi0 at bios0: ACPI 1.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP ASF! HPET MCFG APIC SSDT
acpi0: wakeup devices PCI0(S5) PEX0(S5) PEX1(S5) PEX2(S5) PEX3(S5) PEX4(S5)
PEX5(S5) HUB0(S5) UAR1(S3) UAR2(S3) IGBE(S4) USB0(S3) USB1(S3) USB2(S3)
USB3(S3) USB4(S3) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimcfg0 at acpi0
acpimcfg0: addr 0xd000, bus 0-255
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz, 2826.27 MHz, 06-17-0a
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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 6MB
64b/line 24-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 332MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz, 2826.26 MHz, 06-17-0a
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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 6MB
64b/line 24-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins, remapped
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (PEX0)
acpiprt2 at acpi0: bus -1 (PEX1)
acpiprt3 at acpi0: bus -1 (PEX2)
acpiprt4 at acpi0: bus -1 (PEX3)
acpiprt5 at acpi0: bus -1 (PEX4)
acpiprt6 at acpi0: bus -1 (PEX5)
acpiprt7 at acpi0: bus 2 (HUB0)
acpibtn0 at acpi0: PWRB
acpipci0 at acpi0 PCI0
acpicmos0 at acpi0
com0 at acpi0 UAR1 addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo
com1 at acpi0 UAR2 addr 0x2f8/0x8 irq 3: ns16550a, 16 byte fifo
acpicpu0 at acpi0: C1(@1 halt!), FVS, 2667, 2000 MHz
acpicpu1 at acpi0: C1(@1 halt!), FVS, 2667, 2000 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Q45 Host" rev 0x03
inteldrm0 at pci0 dev 2 function 0 "Intel Q45 Video" rev 0x03
drm0 at inteldrm0
intagp0 at inteldrm0
agp0 at intagp0: aperture at 0xe000, size 0x1000
inteldrm0: apic 2 int 16, G45, gen 4
"Intel Q45 Video" rev 0x03 at pci0 dev 2 function 1 not configured
"Intel Q45 HECI" rev 0x03 at pci0 dev 3 function 0 not configured
pciide0 at pci0 dev 3 function 2 "Intel Q45 PT IDER" rev 0x03: DMA
(unsupported), channel 0 wired to native-PCI, channel 1 wired to native-PCI
pciide0: using apic 2 int 18 for native-PCI interrupt
pciide0: channel 0 ignored (not responding; disabled or no drives?)
pciide0: channel 1 ignored (not responding; disabled or no drives?)
puc0 at pci0 dev 3 function 3 "Intel Q45 KT" rev 0x03: ports: 16 com
com4 at puc0 port 0 apic 2 int 17: ns16550a, 16 byte fifo
com4: probed fifo depth: 15 bytes
em0 at pci0 dev 25 function 0 "Intel ICH10 D BM LM" rev 0x02: apic 2 int
20, address 6c:f0:49:fa:26:2e
uhci0 at pci0 dev 26 function 0 "Intel 82801JD USB" rev 0x02: apic 2 int 16
uhci1 at pci0 dev 26 function 1 "Intel 82801JD USB" rev 0x02: apic 2 int 21
uhci2 at pci0 dev 26 function 2 "Intel 82801JD USB" rev 0x02: apic 2 int 18
ehci0 at pci0 dev 26 function 7 "Intel 82801JD USB" rev 0x02: apic 2 int 18
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 

Re: Safely remove USB drive

2023-02-08 Thread vitmau...@gmail.com
Hi,

thank you Crystal for the explanation.

Best,
Vito

Em qua., 8 de fev. de 2023 às 10:44, Crystal Kolipe
 escreveu:
>
> On Wed, Feb 08, 2023 at 10:34:07AM -0300, vitmau...@gmail.com wrote:
> > I'm not using my drives for anything more than copying files, dd etc.
> > I just got curious because you mentioned the act of detaching a device
> > after umounting it and I don't know how to do that on OpenBSD.
>
> If and only if you are using it with softraid, (usually as an encrypted
> volume), then you would need to detach the softraid device using bioctl -d.
>
> But you are almost certainly not doing that.
>
> If you are just copying files, and/or using dd to, for example, overwrite
> a device with zeros or random data, then you don't need to do anything
> special to use usb storage devices on OpenBSD.



Re: Safely remove USB drive

2023-02-08 Thread vitmau...@gmail.com
Hi,

I'm not using my drives for anything more than copying files, dd etc.
I just got curious because you mentioned the act of detaching a device
after umounting it and I don't know how to do that on OpenBSD. On
Fedora I would issue "udisks --detach /dev/sdX" (older versions) or
"udisksctl poweroff -b /dev/sdX" (newer versions).

Best,
Vitor

Em qua., 8 de fev. de 2023 às 10:24, Crystal Kolipe
 escreveu:
>
> Hi,
>
> On Wed, Feb 08, 2023 at 10:13:59AM -0300, vitmau...@gmail.com wrote:
> > thank you all for the replies. Crystal, what command would I use to
> > detach a USB drive? I tried eject, but it doesn't seem to work with
> > the kind of devices I have.
>
> Can you explain exactly what you are trying to do, and what devices
> you are using?
>
> If you are just writing files to a usb flash drive from the command line,
> then you mount it, copy the files, and umount, nothing more.
>
> (Actually, umount automatically does a sync as soon as you invoke it.)
>
> If you are doing something more complicated or using a usb device
> other than a flash drive or external HD, then let us know so that we
> can give you accurate advice.



Re: Safely remove USB drive

2023-02-08 Thread vitmau...@gmail.com
Hi,

thank you all for the replies. Crystal, what command would I use to
detach a USB drive? I tried eject, but it doesn't seem to work with
the kind of devices I have.

Best,
Vitor

Em qua., 8 de fev. de 2023 às 09:55, Crystal Kolipe
 escreveu:
>
> On Wed, Feb 08, 2023 at 09:27:08AM -0300, vitmau...@gmail.com wrote:
> > quick and very basic question: is syncing and umounting a USB drive
> > enough to safely remove it or should I execute other commands before
> > unplugging these devices?
>
> Unless you are doing something 'unusual' (*), then just unmounting
> it is fine, you don't even need to run sync.
>
> (*) Such as having it encrypted as a softraid device, in which case
> you'd need to detach that after unmounting it.  Or writing to
> the raw device directly with tar, for example.



Safely remove USB drive

2023-02-08 Thread vitmau...@gmail.com
Hi,

quick and very basic question: is syncing and umounting a USB drive
enough to safely remove it or should I execute other commands before
unplugging these devices?

Best,
Vitor



Re: LAN slow speed transfer

2023-02-05 Thread vitmau...@gmail.com
Hi,

I don't think my pf.conf will reveal the root of the problem because I
never changed it, but maybe I'm wrong. Anyway, here it is:
# $OpenBSD: pf.conf,v 1.55 2017/12/03 20:40:04 sthen Exp $
#
# See pf.conf(5) and /etc/examples/pf.conf

set skip on lo

block return # block stateless traffic
pass # establish keep-state

# By default, do not permit remote connections to X11
block return in on ! lo0 proto tcp to port 6000:6010

# Port build user does not need network
block return out log proto {tcp udp} user _pbuild

Best,
Vitor

Em sáb., 4 de fev. de 2023 às 10:57, vitmau...@gmail.com
 escreveu:
>
> Hi,
>
> there are two things that still bother me. First, how the Windows
> machine was able to reach something around 30 MBytes/s of download
> rate with the faulty cable. It reached this speed through Ookla's
> Speedtest, though; maybe that is relevant information (don't really
> know how those tests work). Second, I cannot get more than 35 MBytes/s
> even on LAN transfer if the machines are linked through my ISP's
> router, even though it's advertised as a full gigabit router. I get
> something around 95 MBytes/s using my switch, though, so I think it's
> safe to say the router is somehow capped.
>
> Here are those outputs you guys requested. Those state mismatches on
> pfctl caught my attention, but I'm not sure about what they mean
> exactly. Thank you for the help.
>
> dmesg:
> OpenBSD 7.2 (GENERIC.MP) #6: Sat Jan 21 01:03:04 MST 2023
> 
> r...@syspatch-72-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 6254428160 (5964MB)
> avail mem = 6047465472 (5767MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf0100 (40 entries)
> bios0: vendor Itautec ST 4262, LTD 6.00 PG version "FC" date 08/21/2009
> bios0: Itautec S.A. Infoway
> acpi0 at bios0: ACPI 1.0
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP ASF! HPET MCFG APIC SSDT
> acpi0: wakeup devices PCI0(S5) PEX0(S5) PEX1(S5) PEX2(S5) PEX3(S5)
> PEX4(S5) PEX5(S5) HUB0(S5) UAR1(S3) UAR2(S3) IGBE(S4) USB0(S3)
> USB1(S3) USB2(S3) USB3(S3) USB4(S3) [...]
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpihpet0 at acpi0: 14318179 Hz
> acpimcfg0 at acpi0
> acpimcfg0: addr 0xd000, bus 0-255
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz, 2826.29 MHz, 06-17-0a
> 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
> cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 6MB
> 64b/line 24-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 332MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz, 2826.26 MHz, 06-17-0a
> 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
> cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 6MB
> 64b/line 24-way L2 cache
> cpu1: smt 0, core 1, package 0
> ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins, remapped
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 1 (PEX0)
> acpiprt2 at acpi0: bus -1 (PEX1)
> acpiprt3 at acpi0: bus -1 (PEX2)
> acpiprt4 at acpi0: bus -1 (PEX3)
> acpiprt5 at acpi0: bus -1 (PEX4)
> acpiprt6 at acpi0: bus -1 (PEX5)
> acpiprt7 at acpi0: bus 2 (HUB0)
> acpibtn0 at acpi0: PWRB
> acpipci0 at acpi0 PCI0
> acpicmos0 at acpi0
> com0 at acpi0 UAR1 addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo
> com1 at acpi0 UAR2 addr 0x2f8/0x8 irq 3: ns16550a, 16 byte fifo
> acpicpu0 at acpi0: C1(@1 halt!), FVS, 2667, 2000 MHz
> acpicpu1 at acpi0: C1(@1 halt!), FVS, 2667, 2000 MHz
> pci0 at mainbus0 bus 0
> pchb0 at pci0 dev 0 function 0 "Intel Q45 Host" rev 0x03
> inteldrm0 at pci0 dev 2 function 0 "Intel Q45 Video" rev 0x03
> drm0 at inteldrm0
> intagp0 at inteldrm0
> agp0 at intagp0: aperture at 0xe000, size 0x1000
> inteldrm0: apic 2 int 16, G45, gen 4
> "Intel Q45 Video" rev 0x03 at pci0 dev 2 function 1 not configured
> "Intel Q45 HECI" rev 0x03 at pci0 dev 3 function 0 not configured
> pciide0 at pci0 dev 3 function 2 "Intel Q45 PT IDER" rev 0x03: DMA
> (unsupported),

Re: LAN slow speed transfer

2023-02-04 Thread vitmau...@gmail.com
Hi,

there are two things that still bother me. First, how the Windows
machine was able to reach something around 30 MBytes/s of download
rate with the faulty cable. It reached this speed through Ookla's
Speedtest, though; maybe that is relevant information (don't really
know how those tests work). Second, I cannot get more than 35 MBytes/s
even on LAN transfer if the machines are linked through my ISP's
router, even though it's advertised as a full gigabit router. I get
something around 95 MBytes/s using my switch, though, so I think it's
safe to say the router is somehow capped.

Here are those outputs you guys requested. Those state mismatches on
pfctl caught my attention, but I'm not sure about what they mean
exactly. Thank you for the help.

dmesg:
OpenBSD 7.2 (GENERIC.MP) #6: Sat Jan 21 01:03:04 MST 2023

r...@syspatch-72-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 6254428160 (5964MB)
avail mem = 6047465472 (5767MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf0100 (40 entries)
bios0: vendor Itautec ST 4262, LTD 6.00 PG version "FC" date 08/21/2009
bios0: Itautec S.A. Infoway
acpi0 at bios0: ACPI 1.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP ASF! HPET MCFG APIC SSDT
acpi0: wakeup devices PCI0(S5) PEX0(S5) PEX1(S5) PEX2(S5) PEX3(S5)
PEX4(S5) PEX5(S5) HUB0(S5) UAR1(S3) UAR2(S3) IGBE(S4) USB0(S3)
USB1(S3) USB2(S3) USB3(S3) USB4(S3) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimcfg0 at acpi0
acpimcfg0: addr 0xd000, bus 0-255
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz, 2826.29 MHz, 06-17-0a
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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 6MB
64b/line 24-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 332MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz, 2826.26 MHz, 06-17-0a
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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 6MB
64b/line 24-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins, remapped
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (PEX0)
acpiprt2 at acpi0: bus -1 (PEX1)
acpiprt3 at acpi0: bus -1 (PEX2)
acpiprt4 at acpi0: bus -1 (PEX3)
acpiprt5 at acpi0: bus -1 (PEX4)
acpiprt6 at acpi0: bus -1 (PEX5)
acpiprt7 at acpi0: bus 2 (HUB0)
acpibtn0 at acpi0: PWRB
acpipci0 at acpi0 PCI0
acpicmos0 at acpi0
com0 at acpi0 UAR1 addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo
com1 at acpi0 UAR2 addr 0x2f8/0x8 irq 3: ns16550a, 16 byte fifo
acpicpu0 at acpi0: C1(@1 halt!), FVS, 2667, 2000 MHz
acpicpu1 at acpi0: C1(@1 halt!), FVS, 2667, 2000 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Q45 Host" rev 0x03
inteldrm0 at pci0 dev 2 function 0 "Intel Q45 Video" rev 0x03
drm0 at inteldrm0
intagp0 at inteldrm0
agp0 at intagp0: aperture at 0xe000, size 0x1000
inteldrm0: apic 2 int 16, G45, gen 4
"Intel Q45 Video" rev 0x03 at pci0 dev 2 function 1 not configured
"Intel Q45 HECI" rev 0x03 at pci0 dev 3 function 0 not configured
pciide0 at pci0 dev 3 function 2 "Intel Q45 PT IDER" rev 0x03: DMA
(unsupported), channel 0 wired to native-PCI, channel 1 wired to
native-PCI
pciide0: using apic 2 int 18 for native-PCI interrupt
pciide0: channel 0 ignored (not responding; disabled or no drives?)
pciide0: channel 1 ignored (not responding; disabled or no drives?)
puc0 at pci0 dev 3 function 3 "Intel Q45 KT" rev 0x03: ports: 16 com
com4 at puc0 port 0 apic 2 int 17: ns16550a, 16 byte fifo
com4: probed fifo depth: 15 bytes
em0 at pci0 dev 25 function 0 "Intel ICH10 D BM LM" rev 0x02: apic 2
int 20, address 6c:f0:49:fa:26:2e
uhci0 at pci0 dev 26 function 0 "Intel 82801JD USB" rev 0x02: apic 2 int 16
uhci1 at pci0 dev 26 function 1 "Intel 82801JD USB" rev 0x02: apic 2 int 21
uhci2 at pci0 dev 26 function 2 "Intel 82801JD USB" rev 0x02: apic 2 int 18
ehci0 at pci0 dev 26 function 7 "Intel 82801JD USB" rev 0x02: apic 2 int 18
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
ppb0 at pci0 dev 28 function 0 "Intel 82801JD PCIE" rev 0x02: apic 2 int 16
pci1 at ppb0 bus 1
uhci3 at pci0 dev 29 function 0 "Intel 82801JD USB" rev 

Re: LAN slow speed transfer

2023-02-02 Thread vitmau...@gmail.com
Hi,

thank you Stu for the feedback. Turns out the problem was one of the
cables. It is advertised as 5E, but maybe there is something fishy
with it. Fact is, I bought another, changed it, and now I got
something around 95 MBytes/s of LAN transfer rate.

Best,
Vitor

Em qui., 2 de fev. de 2023 às 13:21, vitmau...@gmail.com
 escreveu:
>
> Hello guys,
>
> I'm having problems trying to improve my transfer speed over LAN. I
> can't consistently reach speeds over 10 MBytes/s using iPerf (real
> disk writing transfers with scp render basically the same results).
> Since both server (OpenBSD) and client (Windows) are able to reach
> speeds over 30 MBytes/s downloading files from the internet, I reckon
> there's something to be tweaked on my machines. Any thoughts regarding
> what can be done on the server?
>
> I already tried to no avail what is suggested here:
> http://dant.net.ru/calomel/network_performance.html
>
> Here is there relevant part of my dmesg:
> OpenBSD 7.2 (GENERIC.MP) #5: Wed Jan 11 01:03:12 MST 2023
> em0 at pci0 dev 25 function 0 "Intel ICH10 D BM LM" rev 0x02: apic 2 int 20
>
> Here's my ifconfig output:
> lo0: flags=8049 mtu 32768
> index 3 priority 0 llprio 3
> groups: lo
> inet6 ::1 prefixlen 128
> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
> inet 127.0.0.1 netmask 0xff00
> em0: flags=808843 mtu 1500
> lladdr
> index 1 priority 0 llprio 3
> groups: egress
> media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause)
> status: active
> inet 192.168.1.2 netmask 0xff00 broadcast 192.168.1.255
> enc0: flags=0<>
> index 2 priority 0 llprio 3
> groups: enc
> status: active
> pflog0: flags=141 mtu 33136
> index 4 priority 0 llprio 3
> groups: pflog
>
> Best,
> Vitor



LAN slow speed transfer

2023-02-02 Thread vitmau...@gmail.com
Hello guys,

I'm having problems trying to improve my transfer speed over LAN. I
can't consistently reach speeds over 10 MBytes/s using iPerf (real
disk writing transfers with scp render basically the same results).
Since both server (OpenBSD) and client (Windows) are able to reach
speeds over 30 MBytes/s downloading files from the internet, I reckon
there's something to be tweaked on my machines. Any thoughts regarding
what can be done on the server?

I already tried to no avail what is suggested here:
http://dant.net.ru/calomel/network_performance.html

Here is there relevant part of my dmesg:
OpenBSD 7.2 (GENERIC.MP) #5: Wed Jan 11 01:03:12 MST 2023
em0 at pci0 dev 25 function 0 "Intel ICH10 D BM LM" rev 0x02: apic 2 int 20

Here's my ifconfig output:
lo0: flags=8049 mtu 32768
index 3 priority 0 llprio 3
groups: lo
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
inet 127.0.0.1 netmask 0xff00
em0: flags=808843 mtu 1500
lladdr
index 1 priority 0 llprio 3
groups: egress
media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause)
status: active
inet 192.168.1.2 netmask 0xff00 broadcast 192.168.1.255
enc0: flags=0<>
index 2 priority 0 llprio 3
groups: enc
status: active
pflog0: flags=141 mtu 33136
index 4 priority 0 llprio 3
groups: pflog

Best,
Vitor



Re: Some NFS clients won't mount

2023-01-01 Thread vitmau...@gmail.com
Theo helped solve my main concern. In my mind, I was kinda comparing
NFS and HTTP: no one requires a browser (which is essentially a
HTTPclient) to be run as root, so why require a NFS client to be run
this way? But the point is that we have securely written HTTP servers,
so we don't need to be so strict when it comes to who talks to these
servers. Unfortunately, the same cannot be said of NFS servers.

Thank you guys for the help and for making things clearer for me.

Best,
Vitor

Em dom., 1 de jan. de 2023 às 06:39, Theo de Raadt
 escreveu:
>
> vitmau...@gmail.com  wrote:
>
> > I did some tests and I'm now pretty sure the problem revolves around
> > the point naddy made: Kodi and VLC try to mount my NFS share through a
> > non-privileged port. As both Kodi and VLC use the same NFS client
> > library (libnfs), I tried to find out a bit more about how it works.
> > According to its readme, libnfs uses standard NFS ports when run as
> > root and non-privileged ports when run non-root. Here is the relevant
> > part of the readme file: "When running as root, libnfs tries to
> > allocate a system port for its connection to the NFS server. When
> > running as non-root it will use a normal ephemeral port". I find it
> > strange that a client library should be run as root in order to use a
> > privileged port. My (very poor, I confess) understanding was that only
> > server processes should be run as root in order to use privileged
> > ports. Anyway, as things stand I can only mount my OpenBSD NFS shares
> > if the client is run as root, since the usual way to circumvent this
> > problem on the server side (set the insecure flag on exports) is not
> > available on OpenBSD and, I hope, won't ever be. As I don't have root
> > access to my Fire Stick TV, there is no way to mount my OpenBSD NFS
> > shares on it. As I'm no expert on security though, I'd like an opinion
> > from you guys regarding this: is it reasonable to require an NFS
> > client to be run as root?
>
> Yes, it is very reasonable, because after five decades noone has written
> a bug-free NFS server, so this mechanism limiting who can talk to it
> makes sense.
>
> More general comment on this matter: The use of reserved ports for
> numerous protocols will continue to make sense FOREVER, no matter what
> the naysayers say, because there are protocols with insufficient
> alternative authentication methods or services you don't want generic
> users to startup on a shared system and behave as the cannonical
> offering of that service from such a shared system machine.  If anyone
> things we are wrong, go to IETF and convince then to move http and https
> to non-reserved well-known ports *by default*.  Anyone who tries this
> will get nowhere there, and will get nowhere here either... practical
> matters force this.
>
> Sorry.



Re: Some NFS clients won't mount

2022-12-31 Thread vitmau...@gmail.com
I did some tests and I'm now pretty sure the problem revolves around
the point naddy made: Kodi and VLC try to mount my NFS share through a
non-privileged port. As both Kodi and VLC use the same NFS client
library (libnfs), I tried to find out a bit more about how it works.
According to its readme, libnfs uses standard NFS ports when run as
root and non-privileged ports when run non-root. Here is the relevant
part of the readme file: "When running as root, libnfs tries to
allocate a system port for its connection to the NFS server. When
running as non-root it will use a normal ephemeral port". I find it
strange that a client library should be run as root in order to use a
privileged port. My (very poor, I confess) understanding was that only
server processes should be run as root in order to use privileged
ports. Anyway, as things stand I can only mount my OpenBSD NFS shares
if the client is run as root, since the usual way to circumvent this
problem on the server side (set the insecure flag on exports) is not
available on OpenBSD and, I hope, won't ever be. As I don't have root
access to my Fire Stick TV, there is no way to mount my OpenBSD NFS
shares on it. As I'm no expert on security though, I'd like an opinion
from you guys regarding this: is it reasonable to require an NFS
client to be run as root?

Best,
Vitor



Em sex., 30 de dez. de 2022 às 15:20, Bodie  escreveu:
>
> On Fri Dec 30, 2022 at 3:59 PM CET, vitmau...@gmail.com wrote:
> > Thank you guys for the tips. I think naddy is right, which means I was
> > wrong in thinking that I finally had a doubt that couldn't be solved
> > by OpenBSD's manuals. I'll do some tests and report back on this
> > thread soon.
>
> Don't forget to check firewall as NFSv4 from your Fedora 34 has
> way less requirements then NFSv3 served by OpenBSD
>
> You can compare 'rpcinfo -p localhost' on your OpenBSD server
> vs same command remotely from client (with proper hostname/IP)
>
> And NFSv3 is by default UDP while NFSv4 is TCP
>
> >
> > Best,
> > Vitor
> >
> > Em qui., 29 de dez. de 2022 às 16:55, Christian Weisgerber
> >  escreveu:
> > >
> > > "vitmau...@gmail.com":
> > >
> > > > My /var/log/daemon regarding the issue:
> > > > mountd[91001]: Refused mount RPC from host 192.168.1.4 port 57264
> > >
> > > The client's mount request didn't come from a reserved port, i.e. <1024.
> > > OpenBSD's mountd(8) does not accept this.
> > >
> > > --
> > > Christian "naddy" Weisgerber  na...@mips.inka.de
>



Re: Some NFS clients won't mount

2022-12-30 Thread vitmau...@gmail.com
Thank you guys for the tips. I think naddy is right, which means I was
wrong in thinking that I finally had a doubt that couldn't be solved
by OpenBSD's manuals. I'll do some tests and report back on this
thread soon.

Best,
Vitor

Em qui., 29 de dez. de 2022 às 16:55, Christian Weisgerber
 escreveu:
>
> "vitmau...@gmail.com":
>
> > My /var/log/daemon regarding the issue:
> > mountd[91001]: Refused mount RPC from host 192.168.1.4 port 57264
>
> The client's mount request didn't come from a reserved port, i.e. <1024.
> OpenBSD's mountd(8) does not accept this.
>
> --
> Christian "naddy" Weisgerber  na...@mips.inka.de



Some NFS clients won't mount

2022-12-29 Thread vitmau...@gmail.com
I have a NFS share on OpenBSD with a Windows 10 and a FireOS clients
(through VLC and Kodi). Windows 10 mounts the NFS share without issue,
but the Fire OS can't mount it either through VLC or Kodi. Before
moving to OpenBSD I had a NFS share on Fedora 34 and all my systems
could mount it.

I've found a similar problem on the lists, but it came down to NAT
issues and I don't think that is my case, since the Windows client
mounts the share successfully. Here's the entry:
https://www.mail-archive.com/bugs@openbsd.org/msg15280.html

I considered a version problem (NFSv3 vs NFSv4 or something of the
sort), but the version of libnfs used by both Kodi and VLC implements
NFSv3.

My exports file (tried mapall to my user, to root, and to nobody; none worked):
/home/vitor/server -alldirs -ro -network=192.168.1.0 -mask=255.255.255.0

My /var/log/daemon regarding the issue:
mountd[91001]: Refused mount RPC from host 192.168.1.4 port 57264

VLC for Android (version 3.5.3) log:
[8fdb48f0/39db] libvlc stream: nfs_mount_cb failed: -14, 'RPC Packet
not accepted by the server'

Kodi (version 19.5) log:
NFS: Failed to mount nfs share: /home/vitor/server (mount_cb: )
GetDirectory - Error getting nfs://192.168.1.14/home/vitor/server/
CGUIDialogFileBrowser::GetDirectory(nfs://192.168.1.14/home/vitor/server/)
failed

Server version:
OpenBSD 7.2 GENERIC.MP#758 amd64

Any help will be much appreciated.

Best,
Vitor