Re: USB M-Audio as default audio output
On Sat, Jan 25, 2020 at 08:43:29AM +0100, Alexandre Ratchov wrote: > On Fri, Jan 24, 2020 at 04:04:40PM +0100, Thomas de Grivel wrote: > > I have a USB M-Audio card which is very well supported by OpenBSD 6.6 amd64 > > > > My question is : how do I setup an USB audio card as the default audio > > device whenever it is plugged in ? > > > > Also I did not manage to get audio output with environment variables > > only, I had to swap /dev/audio0 and /dev/audio1 and then it worked. > > Could it have something to do with sndiod not running for /dev/audio1 > > ? > > > > In all cases I really like sndio, it is really easy to work with. > > There's no way to detect when the usb device is connected > again. sndiod will start using it the next time it needs to open a > device. As programs tend to keep the device open, you could force > sndiod to reopen the devices (and thus switch to the usb one) by > sending it a HUP signal. To do certain things after a usb device appears you can use hotplugd(8). > On 6.6 you have to "pkill -1 -x sndiod", on -current the rcctl script > does it for you: > > rcctl reload sndiod
FYI: logitech mouse LED color tool
Hi, I implemented a utility to set the LED color of Logitech mouse devices on OpenBSD. Some people might also use this mouse and would like to change the LED color. If you are interested just try it: https://github.com/younix/g403led I just tested it with the "G403 Prodigy Gaming Mouse" model. If it also work for other models, let me know. Any feedback is welcome. bye, Jan
Re: FYI: logitech mouse LED color tool
On Sat, Jan 13, 2018 at 04:48:10AM +0100, Juan Francisco Cantero Hurtado wrote: > On Fri, Jan 12, 2018 at 02:42:06AM +0100, Jan Klemkow wrote: > > I implemented a utility to set the LED color of Logitech mouse devices > > on OpenBSD. Some people might also use this mouse and would like to > > change the LED color. > > > > If you are interested just try it: https://github.com/younix/g403led > > > > I just tested it with the "G403 Prodigy Gaming Mouse" model. If it also > > work for other models, let me know. > > > > Any feedback is welcome. > > Make a port! :) I think it isn't worth is now. Maybe if some other logitech mouse models are also working with the same tool?! But, one port for one device seams to be to noisy for the ports tree. When someone here has a similar logitech mouse, please send me a dmesg and a message if it's working or not. Thanks! signature.asc Description: PGP signature
Re: TSO and LRO while forwarding traffic
On Tue, Jan 09, 2024 at 05:14:47AM +, Valdrin MUJA wrote: > I've got a question about TSO and LRO: > > How does enabling TSO and/or LRO on the Ethernet cards of a network > device that will serve as a router and firewall affect the forward > traffic of users accessing the internet behind this device? LRO will merge several receiving packets together by hardware. Later on the outgoing path, TSO will be used to split them intro peaces of max. mss size. Thus, TCP segments will be reformed be these features. TSO alone does not affect routing. Without LRO, TSO is just used for traffic initiated by your router. > In short, should I keep these features on or turn them off in my OpenBSD > firewall? > What is the OpenBSD recommendation? I recommend to keep it turned on. Just turn it off, if you case of errors. When you have issues which you can fix by turning it off, just send us a bug report. bye, Jan
shutdown and syncing discs fail
Hello, I think I have this problem since OpenBSD 4.2 release till now 4.4 current. I have a problem with the shutdown process. When I do run several programs firefox and/or gimp for example and make a shutdown than the system hangs on "syncing discs..." The computer do nothing. There is no disc-activity. I only could press the power switch to power down the machine. In the follow boot process OpenBSD starts checking the disks with fsck. I have the problem even when I restart X with the [ctl]+[Alt]+[backspace] key combination. When I close all running programs before typing "halt -p" to the xterm, then everything is fine and before the machine turn off, its printing "syncing discs...done". I have the problem on all my three OpenBSD machines. All machines do run Current. thanks for any help. Jan
Re: shutdown and syncing discs fail
Maybe my English is so bad, that you did not understand me. My problem is not that the machine does not turn off automatically. The Problem is that the system hangs/freeze during "syncing disks...". Jean-FranC'ois wrote: Hello, This is default setting. Change powerdown=YES in /etc.rc.shutdown BR JF Le samedi 14 fC)vrier 2009 C 11:47 +0100, Jan Klemkow a C)crit : Hello, I think I have this problem since OpenBSD 4.2 release till now 4.4 current. I have a problem with the shutdown process. When I do run several programs firefox and/or gimp for example and make a shutdown than the system hangs on "syncing discs..." The computer do nothing. There is no disc-activity. I only could press the power switch to power down the machine. In the follow boot process OpenBSD starts checking the disks with fsck. I have the problem even when I restart X with the [ctl]+[Alt]+[backspace] key combination. When I close all running programs before typing "halt -p" to the xterm, then everything is fine and before the machine turn off, its printing "syncing discs...done". I have the problem on all my three OpenBSD machines. All machines do run Current. thanks for any help. Jan
graphic card support
Hi, I have a problem to select right graphic cards for my OpenBSD systems. At the first machine I want to use 2 screens in dualhead mode. At the second machine I need a graphic card with 3D-acceleration. I have no idea where i could find information which card or chipset support this features. Are there a list of graphic-chips where i could see which chipsets support the DRI/DRM-feature under OpenBSD? Did the support depends in the xorg-driver or at the OpenBSD kernel implementation of DRI? thanks a lot, Jan
HowTo gpio with com-port?
Hello,
I want to get some signals from a electronic circuit at my serial-port
com0. I don't know how to attach the pin's from the serial port with the
gpioctl tool. I think it my hardware is not supported, but I don't know
exactly. In my dmesg there is nothing like this:
"gpio0 at gscpcib0: 64 pins"
What could I do to get the signals from my circuit or to get support
with gpio?
thx
ciao, Jan
my dmesg:
OpenBSD 4.5-current (GENERIC.MP) #10: Tue Mar 24 06:45:46 CET 2009
r...@eva.hope:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: AMD Athlon(tm) 64 X2 Dual Core Processor 6000+ ("AuthenticAMD"
686-class, 1024KB L2 cache) 3.05 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16
real mem = 1072984064 (1023MB)
avail mem = 1029214208 (981MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 07/16/07, SMBIOS rev. 2.4 @
0xfbc00 (30 entries)
bios0: vendor American Megatrends Inc. version "P2.10" date 07/16/2007
acpi0 at bios0: rev 0
acpi0: tables DSDT FACP APIC OEMB HPET
acpi0: wakeup devices PS2K(S4) PS2M(S4) UAR1(S4) USB0(S4) MAC_(S5)
AC97(S4) USB1(S4) USB2(S4) P0P1(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 202MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD Athlon(tm) 64 X2 Dual Core Processor 6000+ ("AuthenticAMD"
686-class, 1024KB L2 cache) 3.05 GHz
cpu1:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 11, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 2
acpihpet0 at acpi0: 2500 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 2 (P0P1)
acpicpu0 at acpi0
acpicpu1 at acpi0
acpibtn0 at acpi0: PWRB
bios0: ROM list: 0xc/0xd000 0xcd000/0x1800
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "NVIDIA nForce3 250 PCI Host" rev 0xa1
agp at pchb0 not configured
pcib0 at pci0 dev 1 function 0 "NVIDIA nForce3 250 ISA" rev 0xa2
nviic0 at pci0 dev 1 function 1 "NVIDIA nForce3 250 SMBus" rev 0xa1
iic0 at nviic0
spdmem0 at iic0 addr 0x50: 1GB DDR2 SDRAM non-parity PC2-5300CL5
iic1 at nviic0
ohci0 at pci0 dev 2 function 0 "NVIDIA nForce3 250 USB" rev 0xa1: apic 2
int 9 (irq 9), version 1.0, legacy support
ohci1 at pci0 dev 2 function 1 "NVIDIA nForce3 250 USB" rev 0xa1: apic 2
int 3 (irq 3), version 1.0, legacy support
ehci0 at pci0 dev 2 function 2 "NVIDIA nForce3 250 USB" rev 0xa2: apic 2
int 9 (irq 9)
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "NVIDIA EHCI root hub" rev 2.00/1.00 addr 1
nfe0 at pci0 dev 5 function 0 "NVIDIA nForce3 LAN" rev 0xa2: apic 2 int
9 (irq 9), address 00:19:66:47:22:e8
rlphy0 at nfe0 phy 1: RTL8201L 10/100 PHY, rev. 1
pciide0 at pci0 dev 8 function 0 "NVIDIA nForce3 250 IDE" rev 0xa2: DMA,
channel 0 configured to compatibility, channel 1 configured to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 16-sector PIO, LBA, 38172MB, 78177792 sectors
wd1 at pciide0 channel 0 drive 1:
wd1: 16-sector PIO, LBA48, 190782MB, 390721968 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 6
wd1(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 6
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: ATAPI
5/cdrom removable
wd2 at pciide0 channel 1 drive 1:
wd2: 16-sector PIO, LBA, 19544MB, 40026672 sectors
cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
wd2(pciide0:1:1): using PIO mode 4, Ultra-DMA mode 4
pciide1 at pci0 dev 10 function 0 "NVIDIA nForce3 250 SATA" rev 0xa2: DMA
pciide1: using apic 2 int 10 (irq 10) for native-PCI interrupt
wd3 at pciide1 channel 0 drive 0:
wd3: 16-sector PIO, LBA48, 476940MB, 976773168 sectors
wd3(pciide1:0:0): using PIO mode 4, Ultra-DMA mode 5
ppb0 at pci0 dev 11 function 0 "NVIDIA nForce3 250 AGP" rev 0xa2
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "ATI Radeon 9800 Pro" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
radeondrm0 at vga1: apic 2 int 11 (irq 11)
drm0 at radeondrm0
"ATI Radeon 9800 Pro Sec" rev 0x00 at pci1 dev 0 function 1 not configured
ppb1 at pci0 dev 14 function 0 "NVIDIA nForce3 250 PCI-PCI" rev 0xa2
pci2 at ppb1 bus 2
rl0 at pci2 dev 9 function 0 "Realtek 8139" rev 0x10: apic 2 int 9 (irq
9), address 00:e0:7d:d3:74:23
rlphy1 at rl0 phy 0: RTL internal PHY
pchb1 at pci0 dev 24 function 0 "AMD AMD64 0Fh HyperTransport" rev 0x00
pchb2 at pci0 dev 24 function 1 "AMD AMD64 0Fh Address Map" rev 0x00
pchb3 at pci0 dev 24 function 2 "AMD AMD64 0Fh DRAM Cfg" rev 0x00
kate0 at pci0 dev 24 function 3 "AMD AMD64 0Fh Misc Cfg" rev 0x00: core
rev JH-F3
isa0 at pcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using i
Re: umb is cool
+1 from me, too. The umb(4) drive was great work from gerhard@! On Tue, Oct 04, 2016 at 09:36:26PM -0700, Scott Bonds wrote: > I've got a WWAN card that required a bunch of fiddling with pppd under > 5.9 to get online. I upgraded to 6.0 and my pppd dialup script stopped > working. I soon discovered I had a new NIC: umb0. A man page read and > an ifconfig command later, I've got a working WWAN-based connection to > the internet. Piece of cake. > > I really like being able to connect with a simple ifconfig command > instead of all that pppd config I had before. If you're in the market > for a WWAN card for your OpenBSD box and you have a BIOS that doesn't > get in the way of using the hardware of your choice, you might want to > consider the list of devices on the umb man page.
Re: Hannover BSD meetup
On Thu, Jan 22, 2015 at 08:05:13PM +0100, Jan Lambertz wrote: > Hey Reyk, > > that sounds great. Unfortunately the Way to Hannover is 600km from > here. I hope something simliar is happening soon near Munich. I was > not able to find any Meeting for OpenBSD here. > > Jan Hi Jan, I'm living in Munich and interested to meet OpenBSD folks, too. And I know some other OpenBSD people around Munich. If you organise a place with food and coke I will join! bye, Jan
Re: Munich BSD meetup
On Fri, Jan 23, 2015 at 07:58:37PM +0100, Jan Lambertz wrote: > I fine with everywhere reachable in 1,5 hours. Me, too. Fix a date and place! I will join. If you have no idea. I would suggest "Pasta e Basta". It is next to an entrance of the U2 at station "Fraunhoferstrasse". Fraunhoferstrasse 19, 80469 Muenchen http://www.pastaebastaweb.de/ bye, Jan
Re: Munich BSD meetup
Ok. This is also fine for me. At which date/time we want to meet? At Friday evening? How is that for you "Jan Lambertz"? On Mon, Jan 26, 2015 at 02:41:33PM +0100, Philipp Westphal wrote: > The "PASTA W BASTA" idea is not that good... Maybe we can greater at > "Augustiner Braustuben" and make up a table It's close to the main > station.. > > Philipp > Am 26.01.2015 10:01 schrieb "Jan Klemkow" : > > > On Fri, Jan 23, 2015 at 07:58:37PM +0100, Jan Lambertz wrote: > > > I fine with everywhere reachable in 1,5 hours. > > > > Me, too. Fix a date and place! I will join. If you have no idea. I > > would suggest "Pasta e Basta". It is next to an entrance of the U2 at > > station "Fraunhoferstrasse". > > > > Fraunhoferstrasse 19, > > 80469 Muenchen > > > > http://www.pastaebastaweb.de/
slow network thread
hi, I've a problem with the network speed. If I download the a file with openbsd, it has only a speed round about 250 kBit/s I could start several downloads with the same speed. So that a program like aget has a speed from 600 till 900. I've this effect with all programs like Firefox, wget and curl. On the same machine with Windows or Linux the speed goes up from 600 till 900kBit/s. Does somebody know why this happen? Driver problem? or a simple configuration? thanks, Jan
Re: ixl(4) troubles
Hi Matthew,
On Thu, Oct 03, 2024 at 01:52:11PM -0500, matthew j weaver wrote:
> Howdy, all. I'm having basic trouble with some ixl(4) interfaces and
> cannot figure out what I am overlooking.
>
> The hardware is an Intel X710 SFP+ card with two interfaces. I cannot
> seem to get the interfaces to achieve carrier link. The interfaces are
> always status: no carrier. I've tried a few transceivers, cables, different
> equipment on the far end, to no avail.
>
> The transceivers and cables currently set up have worked fine in
> other hardware.
>
> Install is OpenBSD 7.5, dmesg is below.
>
> For ease of experiment, I've put matching transceivers into the two
> interfaces, connected by an appropriate cable. Even in this
> configuration I can't get link, as can be seen here in output from
> ifconfig ixl{0,1} transceiver:
>
> -
> ixl0: flags=8843 mtu 1500
> lladdr 40:a6:b7:b3:4b:28
> index 1 priority 0 llprio 3
> media: Ethernet autoselect
> status: no carrier
> transceiver: SFP LC, 850 nm, 300m OM1, 300m OM2, 600m OM3
> model: Ubiquiti Inc. OM-MM-10G-D rev A1
This kind of transceiver may incompatible with Intel NICs.
Do you have Intel-Transceivers to verify that?
bye,
jan
Re: NIC offloading features (TSO, LRO, TSO, etc)
On Wed, May 07, 2025 at 10:39:25PM +, H. Hartzer wrote: > I figure this may not be worthy of tech@. Just wanted to mention > some thoughts. > > I see a lot of work done around the various NIC offloading features. > Personally, I've had a lot of problems with these. Typically involving > virtualization at the guest level or the host level. If you still see problems in your setup running current/stable OpenBSD. Please write a report about it to b...@openbsd.org. Your are also welcome give some feedback of your offloading Linux problems re-tested with OpenBSD. > Now a lot of my experience here comes from Linux many moons ago. > But I found a lot of hardware that wouldn't play nicely unless > offloading was disabled, with the most aggravating bugs. There's > also minor nuisances, like checksums not matching in tcpdump under > some circumstances. And some NICs would seem to "go bad" at some > point at not play nicely with those settings enabled. > > I'm not 100% sure what the CPU savings are, but for my cases I've > never found a situation that was impacted an obvious amount by > having offloading features disabled. I also think that there can > be some security issues where a packet might get by that the NIC > splits up (I think segmentation offloading can do this) and it gets > broken into another packet that would normally not be permitted. > > I certainly don't have all the answers here, and my experience on > the matter is rather old. I just had enough of a persistently poor > experience with offloading features to where I assume that I would > rather not have any offloading code at all. > > That said, maybe some chipsets work great. And maybe some of the > features, especially say outbound, are quite reliable. I'm just a > skeptic after being bitten by it. Maybe some of it was Linux related? > > I'm sure someone here has had a more positive experience with it, > or can attest that the performance gains are worthwhile, or that > it can be utilized only on hardware known to be reliable with it. > > Most of my experience involves gigabit hardware and performance > requirements, so I can see how at say 40gbit/sec, offloading is 40x > more valuable.
