Re: Intel AX200 Stopped Working on Latest Snapshot
On Sat, Aug 01, 2020 at 09:16:55PM -0700, Bobby Reynolds wrote: > Hi Misc! > > Just purchased an Intel AX200 so I could try out the new support in 6.7. > First and foremost, many thanks to those working on the wifi stack :) > > I ran into some firmware issues with the 6.7 release, but I saw some > relevant entries in the -current changelog, and the snapshot from > Monday worked quite well! Unfortunately, after running sysupgrade this > afternoon my iwx0 device is no longer working. It shows up in dmesg but > not in ifconfig output, and I don't have network connectivity. > > Any tips on how I might further debug the issue? I'm rather new to > OpenBSD but quite comfortable with debugging and digging into source > code. > "Intel Wi-Fi 6 AX200" rev 0x1a at pci1 dev 0 function 0 not configured I needed to tweak the iwx device matching code for AX201 because Intel is playing silly games with PCI product IDs. Please send me the output of pcidump -vvv so I can make sure that your device is properly detected again.
Re: Droping UDP traffic
On 1.8.2020 г. 14:43 ч., Stuart Henderson wrote: On 2020-07-31, Ivo Chutkin wrote: Hello guys, Thanks for suggestions. Tweacking sysctl net.inet.udp.recvspace=131072 net.inet.udp.sendspace=131072 solved the problem. Test between routers that started to drop packets over 10Mbit, now run test at 100Mbit with less than 1% drops (over 50% before). net.inet.udp.recvspace and net.inet.udp.sendspace only affect traffic generated on a machine itself, they do not affect forwarded traffic. Generating packets on the router itself isn't a good test for how well they can forward packets. Hi Stuart, I have read it many times that increasing the values do not affect forwarding performance. That is is why I was skeptical about calomel.org solution. Can you point some directions for increasing forwarding performance? I upgraded all routers to 6.7 with patches and I think problem disappears, using the same hardware. Thanks for your help, Ivo
Re: Intel AX200 Stopped Working on Latest Snapshot
On Sun, Aug 02, 2020 at 11:58:26AM +0200, Stefan Sperling wrote: > On Sat, Aug 01, 2020 at 09:16:55PM -0700, Bobby Reynolds wrote: > > Hi Misc! > > > > Just purchased an Intel AX200 so I could try out the new support in 6.7. > > First and foremost, many thanks to those working on the wifi stack :) > > > > I ran into some firmware issues with the 6.7 release, but I saw some > > relevant entries in the -current changelog, and the snapshot from > > Monday worked quite well! Unfortunately, after running sysupgrade this > > afternoon my iwx0 device is no longer working. It shows up in dmesg but > > not in ifconfig output, and I don't have network connectivity. > > > > Any tips on how I might further debug the issue? I'm rather new to > > OpenBSD but quite comfortable with debugging and digging into source > > code. > > > "Intel Wi-Fi 6 AX200" rev 0x1a at pci1 dev 0 function 0 not configured > > I needed to tweak the iwx device matching code for AX201 because Intel > is playing silly games with PCI product IDs. > > Please send me the output of pcidump -vvv so I can make sure that > your device is properly detected again. Nevermind, after taking another close look at the Linux code I could already commit a fix. So please compile a kernel from -current or wait for a future snapshot. Your device should then work again. In case of AX201 we need to be careful about which devices are matched by the driver because there are technical differences such as which firmware image is required. In addition to matching the PCI product ID, the driver must also match the PCI subsystem product ID against a table of known values. For consistency I wrote similar matching code for AX200 devices, and it correctly matches my AX200 device. But in the AX200 case, the Linux driver uses subsystem product IDs only for marketing purposes: It makes the operating system advertise some AX200 devices with distinct trademarked names. There are no technical differences so we can just go back to matching any AX200 device as we did before. Sorry about the breakage. Going forward, I'll try to keep in mind that some things drivers written by vendors will do are not done for technical reasons...
Re: OpenBSD 6.7-current VM on vmd collectd timesync problem
Does anyone hit this on 6.7-current? Martin ‐‐‐ Original Message ‐‐‐ On Thursday, July 30, 2020 11:18 PM, Martin wrote: > I tried kern.timecounter.hardware=tsc, no effect. > > ‐‐‐ Original Message ‐‐‐ > On Thursday, July 30, 2020 10:46 PM, Brian Brombacher br...@planetunix.net > wrote: > > > Are you using: kern.timercounter.hardware=tsc ? > > I’m on 6.7 release and no issue with collectd. > > > > > On Jul 30, 2020, at 4:53 PM, Martin martin...@protonmail.com wrote: > > > I can test it on 6.7-current only, and I haven't tested collectd on 6.6 - > > > 6.7 -stable. TSC looks synchronized, ntpd corrects small amount of time > > > skew ~1s or less. > > > VM time looks stable, but not enougth for time-series measurements. > > > Do you know any command to check TSC is "synchronized"? > > > Martin > > > ‐‐‐ Original Message ‐‐‐ > > > > > > > On Thursday, July 30, 2020 8:40 PM, Chris Cappuccio ch...@nmedia.net > > > > wrote: > > > > Martin [martin...@protonmail.com] wrote: > > > > > > > > > VM using NTP protocol to fine tune clock from the OpenBSD 6.7-current > > > > > host, but collectd complain about clock skew in the past. > > > > > Any ideas? > > > > > > > > Does this happen with 6.6 or 6.7 as well? 6.7-current uses the TSC > > > > directly > > > > to gather timestamps, but it should only do this if the TSC are > > > > "synchronized".
Re: Logging in/out on console while logged in in X removes hardware acceleration
Fri, 31 Jul 2020 17:36:53 +0200 Nils Reuße > Hi Theo, > > thank you for your reply. Well then, I guess I just stop switching > around between different login sessions ;) > > Nils > > > Am 31.07.2020 um 16:08 schrieb Theo de Raadt: > > I'm not sure what can be done about it. > > > > /etc/fbtab's first role is to give access to subsystems, but it's > > second more important role is to *take them away* later. > > > > Unfortunately there is nothing "keeping state" about previous access > > conditions, as well it is quite unclear if reverting to previous access > > conditions would be a safe choice. > > Hi Nils, Or use own tooling to reset desired permissions when you're in X again, try to see if your window manager accepts bindings and use it instead.. -- Kind regards, Anton Lazarov MScEng EECSIT
Re: Logging in/out on console while logged in in X removes hardware acceleration
Explanation: It is how it works. Strahil Nikolov wrote: > Hi All, > > can somwone explain me why all login sessions use /dev/drm0 and not /dev/drm1 > or something like that ? > > Best Regards, > Strahil Nikolov > > Ðа 2 авгÑÑÑ 2020 г. 18:22:23 GMT+03:00, li...@wrant.com напиÑа: > >Fri, 31 Jul 2020 17:36:53 +0200 Nils ReuÃe > >> Hi Theo, > >> > >> thank you for your reply. Well then, I guess I just stop switching > >> around between different login sessions ;) > >> > >> Nils > >> > >> > >> Am 31.07.2020 um 16:08 schrieb Theo de Raadt: > >> > I'm not sure what can be done about it. > >> > > >> > /etc/fbtab's first role is to give access to subsystems, but it's > >> > second more important role is to *take them away* later. > >> > > >> > Unfortunately there is nothing "keeping state" about previous > >access > >> > conditions, as well it is quite unclear if reverting to previous > >access > >> > conditions would be a safe choice. > >> > > > > >Hi Nils, > > > >Or use own tooling to reset desired permissions when you're in X again, > >try to see if your window manager accepts bindings and use it instead.. >
Re: Intel AX200 Stopped Working on Latest Snapshot
Compiled a new kernel and iwx0 is back where it belongs. Thanks Stefan!
Re: Logging in/out on console while logged in in X removes hardware acceleration
Hi All, can somwone explain me why all login sessions use /dev/drm0 and not /dev/drm1 or something like that ? Best Regards, Strahil Nikolov На 2 август 2020 г. 18:22:23 GMT+03:00, li...@wrant.com написа: >Fri, 31 Jul 2020 17:36:53 +0200 Nils Reuße >> Hi Theo, >> >> thank you for your reply. Well then, I guess I just stop switching >> around between different login sessions ;) >> >> Nils >> >> >> Am 31.07.2020 um 16:08 schrieb Theo de Raadt: >> > I'm not sure what can be done about it. >> > >> > /etc/fbtab's first role is to give access to subsystems, but it's >> > second more important role is to *take them away* later. >> > >> > Unfortunately there is nothing "keeping state" about previous >access >> > conditions, as well it is quite unclear if reverting to previous >access >> > conditions would be a safe choice. >> > > >Hi Nils, > >Or use own tooling to reset desired permissions when you're in X again, >try to see if your window manager accepts bindings and use it instead..
Re: scp host:file* /tmp/nonexistent
On Sat, 1 Aug 2020, Christian Weisgerber wrote: Public service announcement: The original BSD repository can be browsed here (converted from SCCS): https://svnweb.freebsd.org/csrg/ Wanna know what those hippies at Berkeley really did? You can look it up. Thanks for the nice repo with the commentaries! Here is the code for cp: https://svnweb.freebsd.org/csrg/bin/cp/cp.c?revision=69112&view=markup https://svnweb.freebsd.org/csrg/bin/cp/utils.c?revision=66606&view=markup A challenge: where does the code distinguish src from src/ ? Indeed it behaves like rsync, but we read in the source something that seems to contradict it: /* * Cp has two distinct cases: * * cp [-R] source target * cp [-R] source1 ... sourceN directory * * In both cases, source can be either a file or a directory. * * In (1), the target becomes a copy of the source. That is, if the * source is a file, the target will be a file, and likewise for * directories. * * In (2), the real target is not directory, but "directory/source". */ Was it a bug? BTW, I do not remember this behaviour in SunOS, but also not in FreeBSD when I used it many years ago, although it was there. Rodrigo
Re: Logging in/out on console while logged in in X removes hardware acceleration
> can somwone explain me ... I guess one can, but it must be from old unix days. Things got changed and mixed, but they are considered ordinary now, so ordinary that even a basic newbie unix book skips them entirely. I am curious even now what is the link among shell, terminal, console, tty. Even the newbies list is closed. All this will not hinder OpenBSD development, so use it as it is and try to grab some answers from internet, good or bad ones it is to you to check.
Re: Logging in/out on console while logged in in X removes hardware acceleration
Thanks for the reply. In the first place, I was wondering if creation of /dev/drm1 (same major and minor) is even possible. In Linux I can create as many devices I need pointing to the same major & minor numbers (for example creating a /dev/null for a chroot jail). If the logic is the same, then each login can create a separate device and later just remove it on logout. Yet, from security perspective it could be a bad solution ... Best Regards, Strahil Nikolov На 2 август 2020 г. 23:42:08 GMT+03:00, Mihai Popescu написа: >> can somwone explain me ... > >I guess one can, but it must be from old unix days. Things got changed >and >mixed, but they are considered ordinary now, so ordinary that even a >basic >newbie unix book skips them entirely. >I am curious even now what is the link among shell, terminal, console, >tty. >Even the newbies list is closed. > >All this will not hinder OpenBSD development, so use it as it is and >try to >grab some answers from internet, good or bad ones it is to you to >check.
