Re: PC Engines APU platform EOL
On Wed, Apr 19, 2023 at 11:30 AM Martin Schröder wrote: > https://www.pcengines.ch/eol.htm > The end is near for APUs :-( :( Happy apu2 & apu4 user here. Are there other OpenBSD friendly options? Regards, -f
SATA disk identify taking 10 seconds to give me output
Hi, I am running OpenBSD_7.1 on VMWare workstation16. It has two hard disks(wd0 & sd0) I am trying to get hard disk information using the following command. *$atactl identify* If I use the disk wd0, I am getting output immediately. If I use the disk sd0, I am getting the output after 10 seconds. I need to trigger the above command multiple times, it is causing delay in my scenario. What's the problem and fix for this issue. *Thanks* Rajasekhar
Re: any way to "redo" a botched upgrade?
On Wed, Apr 19, 2023 at 07:25:17PM -0700, Jonathan Thornburg wrote: > I've just upgraded an amd64 machine from 7.1 to 7.3 (first a 7.1-->7.2 > upgrade, immediately followed by a 7.2-->7.3 upgrade, both following the > FAQ instructions). After a full 'pkg_add -uvv', at least one package > (p5-Term-ReadPassword) is out-of-sync with the new perl binary: > # cat /tmp/foo > #!/usr/bin/perl > use warnings; > use strict; > use Term::ReadPassword; > > print "hello, world\n"; > # /tmp/foo > Gnu.c: loadable library and perl binaries are mismatched (got first > handshake key 0xec0, needed 0xeb8) This usually happens when an XS module is installed outside of the package ecosystem, often with a CPAN client. I would guess this error is Term::ReadLine::Gnu https://metacpan.org/pod/Term::ReadLine::Gnu You might be able to pkg_add p5-Term-ReadLine-Gnu to overwrite that file, but not sure that will work. I recommend looking at sysutils/sysclean as the easiest way to clean up those files. l8rZ, -- andrew Adding manpower to a late software project makes it later.
Re: 7.2: backup adventures against last alternate
UPDATE: Fixed that disk I decided to rebooted to test it one more time before starting the backup again from that. It seems not my day: BAD SUPER BLOCK: VALUES IN SUPER BLOCK DISAGREE WITH THOSE IN LAST ALTERNATE RUN fsck_ffs MANUALLY like before to fix it.. -- Daniele Bonini > > Hello, > > (7.2 patched till 72-024) > > I just came across the moment to do my backups and testing > the resulting two backup disks the result was the same for both: > > BAD SUPER BLOCK: VALUES IN SUPER BLOCK DISAGREE WITH THOSE IN LAST > ALTERNATE > RUN fsck_ffs MANUALLY > > After the third time I redid the full stack of backup I start to be > suspicious about the source disk, you know... tar of my important > files, etc. and running an fsck_ffs on the source disk the result was > negative, it was all fine. > > So, I convinced myself that was the time to fix one of the disks > and see the result... > > BAD SUPERBLOCK ... DO YOU WANT to FIND A NEW ALTERNATE? (or something > alike) Fyn? y > > CLEAN? Fyn? F > > (after 5 min) > > etc. > > *** Phase 5 - Check Cyl groups > FREE BLK COUNT(S) WRONG IN SUPERBLK > SALVAGE? yes > > SUMMARY INFORMATION BAD > SALVAGE? yes > > BLK(S) MISSING IN BIT MAPS > SALVAGE? yes > > CG 288: BAD MAGIC NUMBER > CG 289: BAD MAGIC NUMBER > CG 290: BAD MAGIC NUMBER > CG 291: BAD MAGIC NUMBER > CG 292: BAD MAGIC NUMBER > CG 293: BAD MAGIC NUMBER > etc. > > UPDATE STANDARD SUPERBLOCK? yes > > Can you help me to understand what happened to my disks? > > Thx, appreciated. > > > -- Daniele Bonini -- Daniele Bonini Project Owner and Author http://5mode.com via Massimo Gorki 23 40128 splash.ooo/g/Bologna Italy +390514086280 +393314029415 -- This message is confidential, including all materials contained inside or attached to this email, and intended only for the addressee. If you have received this message in error, please delete it from your systems. You are hereby notified that distribution or copying of its content is strictly prohibited. For information about 5 Mode visit http://5mode.com
any way to "redo" a botched upgrade?
I've just upgraded an amd64 machine from 7.1 to 7.3 (first a 7.1-->7.2
upgrade, immediately followed by a 7.2-->7.3 upgrade, both following the
FAQ instructions). After a full 'pkg_add -uvv', at least one package
(p5-Term-ReadPassword) is out-of-sync with the new perl binary:
# cat /tmp/foo
#!/usr/bin/perl
use warnings;
use strict;
use Term::ReadPassword;
print "hello, world\n";
# /tmp/foo
Gnu.c: loadable library and perl binaries are mismatched (got first handshake
key 0xec0, needed 0xeb8)
# pkg_add -uvv p5-Term-ReadPassword
Update candidates: quirks-6.121 -> quirks-6.121
quirks-6.121 signed on 2023-04-19T08:30:26Z
No change in quirks-6.121
Update candidates: p5-Term-ReadPassword-0.11p2 -> p5-Term-ReadPassword-0.11p2
No change in p5-Term-ReadPassword-0.11p2
#
I've tried deleting and re-adding the p5-Term-ReadPassword package
('pkg_delete -vv p5-Term-ReadPassword', 'pkg_add -vv p5-Term-ReadPassword')
and rebooting, but this didn't change the above behavior. My /etc/installurl
points to
https://cdn.openbsd.org/pub/OpenBSD
The output of 'perl -V' on this system is identical to that on another
amd64 machine (which I just upgraded from 7.2-->7.3) which does *not*
have this problem. In both cases:
# perl -V
Summary of my perl5 (revision 5 version 36 subversion 0) configuration:
Platform:
osname=openbsd
osvers=7.3
archname=amd64-openbsd
uname='openbsd'
config_args='-dse -Dopenbsd_distribution=defined -Dmksymlinks'
hint=recommended
useposix=true
d_sigaction=define
useithreads=undef
usemultiplicity=undef
use64bitint=define
use64bitall=define
uselongdouble=undef
usemymalloc=n
default_inc_excludes_dot=define
Compiler:
cc='cc'
ccflags ='-DNO_LOCALE_NUMERIC -DNO_LOCALE_COLLATE -fno-strict-aliasing
-fno-delete-null-pointer-checks -pipe -fstack-protector-strong
-I/usr/local/include'
optimize='-O2'
cppflags='-DBIG_TIME -DNO_LOCALE_NUMERIC -DNO_LOCALE_COLLATE
-fno-strict-aliasing -fno-delete-null-pointer-checks -pipe
-fstack-protector-strong -I/usr/local/include'
ccversion=''
gccversion='OpenBSD Clang 13.0.0'
gccosandvers=''
intsize=4
longsize=8
ptrsize=8
doublesize=8
byteorder=12345678
doublekind=3
d_longlong=define
longlongsize=8
d_longdbl=define
longdblsize=16
longdblkind=3
ivtype='long'
ivsize=8
nvtype='double'
nvsize=8
Off_t='off_t'
lseeksize=8
alignbytes=8
prototype=define
Linker and Libraries:
ld='cc'
ldflags ='-Wl,-E -fstack-protector-strong -L/usr/local/lib'
libpth=/usr/lib /usr/lib/clang/13.0.0/lib
libs=-lm -lc
perllibs=-lm -lc
libc=/usr/lib/libc.so.97.0
so=so
useshrplib=true
libperl=libperl.so.23.0
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_dlopen.xs
dlext=so
d_dlsymun=undef
ccdlflags='-Wl,-R/usr/libdata/perl5/amd64-openbsd/CORE'
cccdlflags='-DPIC -fpic '
lddlflags='-shared -fpic -fstack-protector-strong -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options:
HAS_TIMES
PERLIO_LAYERS
PERL_COPY_ON_WRITE
PERL_DONT_CREATE_GVSV
PERL_MALLOC_WRAP
PERL_OP_PARENT
PERL_PRESERVE_IVUV
USE_64_BIT_ALL
USE_64_BIT_INT
USE_LARGE_FILES
USE_LOCALE
USE_LOCALE_CTYPE
USE_LOCALE_TIME
USE_PERLIO
USE_PERL_ATOF
Built under openbsd
@INC:
/usr/local/libdata/perl5/site_perl/amd64-openbsd
/usr/local/libdata/perl5/site_perl
/usr/libdata/perl5/amd64-openbsd
/usr/libdata/perl5
#
I presume that I somehow botched one of the upgrades.
Is there any easy way to "redo the upgrade", or should I just give
up and do a clean 7.3 (re)install (followed by manual re-creation of
all of my system configuration)?
Thanks,
--
-- "Jonathan Thornburg [remove -color to reply]"
on the west coast of Canada, eh?
"Now back when I worked in banking, if someone went to Barclays,
pretended to be me, borrowed UKP10,000 and legged it, that was
`impersonation', and it was the bank's money that had been stolen,
not my identity. How did things change?" -- Ross Anderson
7.2: backup adventures against last alternate
Hello, (7.2 patched till 72-024) I just came across the moment to do my backups and testing the resulting two backup disks the result was the same for both: BAD SUPER BLOCK: VALUES IN SUPER BLOCK DISAGREE WITH THOSE IN LAST ALTERNATE RUN fsck_ffs MANUALLY After the third time I redid the full stack of backup I start to be suspicious about the source disk, you know... tar of my important files, etc. and running an fsck_ffs on the source disk the result was negative, it was all fine. So, I convinced myself that was the time to fix one of the disks and see the result... BAD SUPERBLOCK ... DO YOU WANT to FIND A NEW ALTERNATE? (or something alike) Fyn? y CLEAN? Fyn? F (after 5 min) etc. *** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? yes SUMMARY INFORMATION BAD SALVAGE? yes BLK(S) MISSING IN BIT MAPS SALVAGE? yes CG 288: BAD MAGIC NUMBER CG 289: BAD MAGIC NUMBER CG 290: BAD MAGIC NUMBER CG 291: BAD MAGIC NUMBER CG 292: BAD MAGIC NUMBER CG 293: BAD MAGIC NUMBER etc. UPDATE STANDARD SUPERBLOCK? yes Can you help me to understand what happened to my disks? Thx, appreciated. -- Daniele Bonini
Re: hw RNG on APUs
Maybe the driver is broken.
Maybe it fails to initialize it. Maybe in other cases, the BIOS initializes it.
So maybe on this machine, it is broken, but on other machines it is not broken.
Pushing 0's to the random subsystem doesn't make the random state worse.
It just fails to make it better.
But on another machine, it might not be pushing 0's, and it might be making the
random state better.
Christian Weisgerber wrote:
> Christian Weisgerber:
>
> > ccp(4) attaches, so presumably it is used as a source of entropy.
> > Whether the hardware actually provides random output, I don't know.
>
> I built a kernel with an instrumented driver. Unfortunately, no
> entropy is provided:
>
> ccp: rng
> ccp: rng
> ccp: rng
> ccp: rng
> ccp: rng
>
> This is with the lastest firmware:
> bios0: vendor coreboot version "v4.19.0.1" date 01/31/2023
>
>
> Index: dev/ic/ccp.c
> ===
> RCS file: /cvs/src/sys/dev/ic/ccp.c,v
> retrieving revision 1.3
> diff -u -p -r1.3 ccp.c
> --- dev/ic/ccp.c 29 May 2020 04:42:25 - 1.3
> +++ dev/ic/ccp.c 19 Apr 2023 15:12:17 -
> @@ -56,6 +56,7 @@ ccp_rng(void *arg)
> trng = bus_space_read_4(sc->sc_iot, sc->sc_ioh, CCP_REG_TRNG);
> if (trng != 0)
> enqueue_randomness(trng);
> + printf("ccp: rng %08x\n", trng);
>
> - timeout_add_msec(>sc_tick, 100);
> + timeout_add_msec(>sc_tick, 5000);
> }
> --
> Christian "naddy" Weisgerber na...@mips.inka.de
>
Re: hw RNG on APUs
Christian Weisgerber:
> ccp(4) attaches, so presumably it is used as a source of entropy.
> Whether the hardware actually provides random output, I don't know.
I built a kernel with an instrumented driver. Unfortunately, no
entropy is provided:
ccp: rng
ccp: rng
ccp: rng
ccp: rng
ccp: rng
This is with the lastest firmware:
bios0: vendor coreboot version "v4.19.0.1" date 01/31/2023
Index: dev/ic/ccp.c
===
RCS file: /cvs/src/sys/dev/ic/ccp.c,v
retrieving revision 1.3
diff -u -p -r1.3 ccp.c
--- dev/ic/ccp.c29 May 2020 04:42:25 - 1.3
+++ dev/ic/ccp.c19 Apr 2023 15:12:17 -
@@ -56,6 +56,7 @@ ccp_rng(void *arg)
trng = bus_space_read_4(sc->sc_iot, sc->sc_ioh, CCP_REG_TRNG);
if (trng != 0)
enqueue_randomness(trng);
+ printf("ccp: rng %08x\n", trng);
- timeout_add_msec(>sc_tick, 100);
+ timeout_add_msec(>sc_tick, 5000);
}
--
Christian "naddy" Weisgerber na...@mips.inka.de
Re: [arm64] [sound] simpleaudio, but no audio to attach
On Wed, Apr 19, 2023 at 06:09:06AM -, Stuart Henderson wrote:
> On 2023-04-18, S V wrote:
> > Hello, misc@!
> >
> > I'm using ARM64/current and see that my audio chip got detected by
> > simpleaudio
> > but OpenBSD can't attach audio to it
> >
> > Any suggestions on there to start reading? I'm not developer,
> > but I tried to read different match/attach functions
> > in simpleaudio.c/audio.c with no result for now.
>
> Fortunately you don't need to be a programmer to add some code that
> will help you figure out more about what's going on.
>
> Try adding printf()s to simpleaudio_attach_deferred() to check if that
> function is called and, if so, see how far it gets.
>
> I guess it might hit one of the "return"s before actually attaching, so
> for example you could add printf before+after the various return
> statements to see if they were triggered.
>
> While you can just printf some text that you write to identify them,
> you can save a bit of time by sprinkling some of these which use the
> C features to include the function name/line number:
>
> printf("... %s line %d\n", __func__, __LINE__);
Yup. Also we don't appear to have support for nuvoton,nau8822, so that
might be a hindrance. simpleaudio is merely a meta-node that combines
all the necessary HW pieces for a audio path. This usually needs some-
thing that does I2S (transfers audio), speakers and... probably some-
thing else I forgot. Your simpleaudio node shows two pieces, referenced
through the phandles 0031 and 0032. You should look these up
to see what drivers you need to implement.
Re: veb Interface Max Cache Size Restrict
OpenBSD tries to limit the amount of knob tuning, people tend to shoot
themselves in the foot when they start playing with knobs.
However you can always compile your own kernel with the information provided.
On April 19, 2023 2:12:00 AM MDT, Samuel Jayden
wrote:
>Sincerely thank you David for your answer,
>I hope you may consider committing it to src and I kindly say that it would
>be perfect if this max cache size limit value was tied to a sysctl
>parameter.
>
>David Gwynne , 19 Nis 2023 Çar, 02:30 tarihinde şunu
>yazdı:
>
>> On Tue, Apr 18, 2023 at 07:51:08PM +, Samuel Jayden wrote:
>> > Hello,
>> > I have one veb interface in OpenBSD 7.2 and 5 ethernet ports are paired
>> > with this veb. As I understand from the ifconfig output, 4096 mac address
>> > cache values can be kept in this veb interface .
>> >
>> > ifconfig veb10
>> > veb10: flags=8843
>> > index 12 llprio 3
>> > groups: veb
>> > em3 flags=3
>> > port 4 ifpriority 0 ifcost 0
>> > em0 flags=3
>> > port 1 ifpriority 0 ifcost 0
>> > em1 flags=3
>> > port 2 ifpriority 0 ifcost 0
>> > ix3 flags=3
>> > port 8 ifpriority 0 ifcost 0
>> > ix2 flags=3
>> > port 7 ifpriority 0 ifcost 0
>> > Addresses (max cache: 4096, timeout: 240):
>> > 2c:f0:5d:73:f8:c4 em1 0 flags=0<>
>> >
>> >
>> > When I tried to extend this limit value with the command "ifconfig veb10
>> > maxaddr 4097", I got the following error message:
>> > "ifconfig: veb10: Invalid argument"
>> > The maximum value I can give without this error message is 4096. Isn't
>> this
>> > value a bit narrow?
>>
>> maybe. it seemed pretty high when i made it up.
>>
>> > I have tested that the mac addresses of the connected devices are not
>> > recorded in the veb interface after exceeding the limit.
>> >
>> > I want to switch from Cisco device to OpenBSD in a place where there are
>> > more than 8 thousand MAC addresses, but I need to exceed this max cache
>> > size value.
>> > How can I increase this max cache size value 8192 or higher value?
>>
>> you change 4096 to a bigger number in the code.
>>
>> Index: if_etherbridge.c
>> ===
>> RCS file: /cvs/src/sys/net/if_etherbridge.c,v
>> retrieving revision 1.7
>> diff -u -p -r1.7 if_etherbridge.c
>> --- if_etherbridge.c5 Jul 2021 04:17:41 - 1.7
>> +++ if_etherbridge.c19 Apr 2023 02:25:54 -
>> @@ -675,7 +676,7 @@ int
>> etherbridge_set_max(struct etherbridge *eb, struct ifbrparam *bparam)
>> {
>> if (bparam->ifbrp_csize < 1 ||
>> - bparam->ifbrp_csize > 4096) /* XXX */
>> + bparam->ifbrp_csize > 16384) /* XXX */
>> return (EINVAL);
>>
>> /* commit */
>>
Re: hardware
and lest we forget, all the gray/grey ones On April 19, 2023 2:19:48 AM MDT, Jan Stary wrote: >Once we leveraged the synergy of the red and purple solution frameworks. > >On Apr 18 07:47:56, deich...@placebonol.com wrote: >> I was always partial to the blue or purple ones. >> >> On April 18, 2023 3:42:58 AM MDT, Joel Carnat wrote: >> > >> >> Le 18 avr. 2023 à 11:30, Stuart Henderson a >> >> écrit : >> >> >> >> On 2023-04-18, Mischa wrote: >> On 2023-04-17 23:37, Mike Larkin wrote: >> On Mon, Apr 17, 2023 at 02:21:14PM -0600, Theo de Raadt wrote: >> > Gustavo Rios wrote: >> > >> >> What is the best supported servers by OpenBSD ? >> > >> > The silver ones work a little bit better than the black ones. >> > >> >> disagree. All my long running servers are the black ones. >> >>> >> >>> I concur. The black ones are the best! >> >>> They also need to have blue blinkenlights. >> >> >> >> No love for the blue ones? >> > >> >If SunFire v100 count as blue, I do. >> > >> > >> >
Re: dmesg and sensors for ODROID H3
I don't have any other 2.5G capable hardware so I tested by connecting the interfaces to eachother and placed them in different routing domains. With pf disabled I reach about 925 Mbit/sec sustained average with iperf3 in either direction, and a bit more with OpenBSD's own tcpbench(1) which averages at 940-ish Mbit/sec: the maximum of plain gigabit Ethernet. It's a bit puzzling that it lands exactly at the limit of 1 gigabit, since ifconfig confirms that the link has negotiated 2500T full duplex. During the test the machine is running at boost frequency of 2900 MHz (aka "2001 MHz" in Intel Speedstep lingo), and nothing from top(1) suggests that it's even close to being stressed out. Though I notice that all 30-35% of "intr" load happens on a single core. No signs of rge(4) timing out or dropping link or similar. I don't have the 4-port expansion, only the two on-board RTL8125B NICs. On Tue, Apr 18, 2023 at 11:51 PM Nick Owens wrote: > On Tue, Apr 18, 2023 at 7:28 AM stolen data > wrote: > > > > Everything seems to work. Only caveat noticed is that the firmware is > > UEFI-only with no CSM/legacy mode, and it will only boot an OpenBSD > > installation from GPT which must contain an EFI system partition holding > > the bootloader. > > great choice. my ODROID H2+ is still holding strong with the add-in > card for 4 extra NICs. it is a fine home firewall. > > my only complaint is sometimes having > > rge5: watchdog timeout > rge2: watchdog timeout > > in dmesg and occasional link state issues, but i didn't dig into > whether its from the rge driver or stuff i attached. > > if you can, provide an iperf3 result in both forward and reverse mode. > here, i only have about 1.60 Gbit/s in both directions, but that's > fine for my wan link. > > > > > dmesg: > > > > ppb0 at pci0 dev 28 function 0 "Intel Jasper Lake PCIE" rev 0x01: msi > > pci1 at ppb0 bus 1 > > rge0 at pci1 dev 0 function 0 "Realtek RTL8125" rev 0x05: msi, address > > 00:xx:xx:xx:xx:x1 > > ppb1 at pci0 dev 28 function 1 "Intel Jasper Lake PCIE" rev 0x01: msi > > pci2 at ppb1 bus 2 > > rge1 at pci2 dev 0 function 0 "Realtek RTL8125" rev 0x05: msi, address > > 00:xx:xx:xx:xx:x2 > > >
SATA disk identify taking 10 seconds to give me output
Hi, I am running OpenBSD_7.1 on VMWare workstation16. It has two hard disks(wd0 & sd0) I am trying to get hard disk information using the following command. *$atactl identify* If I use the disk wd0, I am getting output immediately. If I use the disk sd0, I am getting the output after 10 seconds. I need to trigger the above command multiple times, it is causing delay in my scenario. What's the problem and fix for this issue. *Thanks* Rajasekhar
Re: hw RNG on APUs
Jan Stary: > Does OpenBSD use any hardware RNG on the PC Engines APUs? ccp0 at pci0 dev 8 function 0 "AMD 16h Crypto" rev 0x00 ccp(4) attaches, so presumably it is used as a source of entropy. Whether the hardware actually provides random output, I don't know. -- Christian "naddy" Weisgerber na...@mips.inka.de
PC Engines APU platform EOL
https://www.pcengines.ch/eol.htm The end is near for APUs :-( Best Martin
Re: hardware
Once we leveraged the synergy of the red and purple solution frameworks. On Apr 18 07:47:56, deich...@placebonol.com wrote: > I was always partial to the blue or purple ones. > > On April 18, 2023 3:42:58 AM MDT, Joel Carnat wrote: > > > >> Le 18 avr. 2023 à 11:30, Stuart Henderson a > >> écrit : > >> > >> On 2023-04-18, Mischa wrote: > On 2023-04-17 23:37, Mike Larkin wrote: > On Mon, Apr 17, 2023 at 02:21:14PM -0600, Theo de Raadt wrote: > > Gustavo Rios wrote: > > > >> What is the best supported servers by OpenBSD ? > > > > The silver ones work a little bit better than the black ones. > > > > disagree. All my long running servers are the black ones. > >>> > >>> I concur. The black ones are the best! > >>> They also need to have blue blinkenlights. > >> > >> No love for the blue ones? > > > >If SunFire v100 count as blue, I do. > > > > >
hw RNG on APUs
Reading random(4), System activity (such as disk, network, and clock device interrupts), and hardware random generator output is collected, ... Does OpenBSD use any hardware RNG on the PC Engines APUs? https://github.com/pcengines/apu2-documentation/issues/112 discusses the firmware support for it. Jan
Re: hardware
On Mi, 19 Apr 2023 12:51:02 +1000 David Diggles wrote: On 2023-04-19 01:40, folly bololey wrote: It doesn't matter whether the cat is black or white, as long as it catches mice. Black cat is more stealthy just a different hunting strategy and depends on the lighting. white cats would be stealthier in snow, or ambushing from above in the day time. To be honest I didn't know it was possible to install OpenBSD on a cat.
Re: veb Interface Max Cache Size Restrict
Sincerely thank you David for your answer,
I hope you may consider committing it to src and I kindly say that it would
be perfect if this max cache size limit value was tied to a sysctl
parameter.
David Gwynne , 19 Nis 2023 Çar, 02:30 tarihinde şunu
yazdı:
> On Tue, Apr 18, 2023 at 07:51:08PM +, Samuel Jayden wrote:
> > Hello,
> > I have one veb interface in OpenBSD 7.2 and 5 ethernet ports are paired
> > with this veb. As I understand from the ifconfig output, 4096 mac address
> > cache values can be kept in this veb interface .
> >
> > ifconfig veb10
> > veb10: flags=8843
> > index 12 llprio 3
> > groups: veb
> > em3 flags=3
> > port 4 ifpriority 0 ifcost 0
> > em0 flags=3
> > port 1 ifpriority 0 ifcost 0
> > em1 flags=3
> > port 2 ifpriority 0 ifcost 0
> > ix3 flags=3
> > port 8 ifpriority 0 ifcost 0
> > ix2 flags=3
> > port 7 ifpriority 0 ifcost 0
> > Addresses (max cache: 4096, timeout: 240):
> > 2c:f0:5d:73:f8:c4 em1 0 flags=0<>
> >
> >
> > When I tried to extend this limit value with the command "ifconfig veb10
> > maxaddr 4097", I got the following error message:
> > "ifconfig: veb10: Invalid argument"
> > The maximum value I can give without this error message is 4096. Isn't
> this
> > value a bit narrow?
>
> maybe. it seemed pretty high when i made it up.
>
> > I have tested that the mac addresses of the connected devices are not
> > recorded in the veb interface after exceeding the limit.
> >
> > I want to switch from Cisco device to OpenBSD in a place where there are
> > more than 8 thousand MAC addresses, but I need to exceed this max cache
> > size value.
> > How can I increase this max cache size value 8192 or higher value?
>
> you change 4096 to a bigger number in the code.
>
> Index: if_etherbridge.c
> ===
> RCS file: /cvs/src/sys/net/if_etherbridge.c,v
> retrieving revision 1.7
> diff -u -p -r1.7 if_etherbridge.c
> --- if_etherbridge.c5 Jul 2021 04:17:41 - 1.7
> +++ if_etherbridge.c19 Apr 2023 02:25:54 -
> @@ -675,7 +676,7 @@ int
> etherbridge_set_max(struct etherbridge *eb, struct ifbrparam *bparam)
> {
> if (bparam->ifbrp_csize < 1 ||
> - bparam->ifbrp_csize > 4096) /* XXX */
> + bparam->ifbrp_csize > 16384) /* XXX */
> return (EINVAL);
>
> /* commit */
>
Re: veb Interface Max Cache Size Restrict
On 2023-04-18, Samuel Jayden wrote: > > I want to switch from Cisco device to OpenBSD in a place where there are > more than 8 thousand MAC addresses, but I need to exceed this max cache > size value. I guess it depends on what exactly the traffic is, but software-bridging traffic from a network segment with >4k devices on OpenBSD seems a tad optimistic. Try with dlg's suggestion if you like, but maybe at a time when users of more than 8 thousand devices won't be too upset. Normally one would want to reduce the number of devices in the segment - realistically the broadcast or multicast traffic for address resolution will get a bit much (especially if wifi is involved) - and even ignoring that, it implies the amount of traffic is such that you'd usually want an actual switch (and a reasonably decent one at that).
Re: [arm64] [sound] simpleaudio, but no audio to attach
On 2023-04-18, S V wrote:
> Hello, misc@!
>
> I'm using ARM64/current and see that my audio chip got detected by simpleaudio
> but OpenBSD can't attach audio to it
>
> Any suggestions on there to start reading? I'm not developer,
> but I tried to read different match/attach functions
> in simpleaudio.c/audio.c with no result for now.
Fortunately you don't need to be a programmer to add some code that
will help you figure out more about what's going on.
Try adding printf()s to simpleaudio_attach_deferred() to check if that
function is called and, if so, see how far it gets.
I guess it might hit one of the "return"s before actually attaching, so
for example you could add printf before+after the various return
statements to see if they were triggered.
While you can just printf some text that you write to identify them,
you can save a bit of time by sprinkling some of these which use the
C features to include the function name/line number:
printf("... %s line %d\n", __func__, __LINE__);
