Re: Support for more than 256 CPU cores
On 5/5/23 17:23, Tomek CEDRO wrote: On Fri, May 5, 2023 at 3:38 PM Ed Maste wrote: FreeBSD supports up to 256 CPU cores in the default kernel configuration (on Tier-1 architectures). Systems with more than 256 cores are available now, and will become increasingly common over FreeBSD 14’s lifetime. (..) Congratulations! :-) I am looking after AMD Threadripper with 64 cores 2 threads each that will give 128 CPU to the system.. maybe this year I could afford that beast then I will report back after testing :-) In upcoming years variations of RISC-V will provide unheard before number of CPU in a single SoC (i.e. 1000 CPU) at amazing power efficiency and I saw reports of prototype with 3 x SoC of this kind on a single board :-) https://spectrum.ieee.org/risc-v-ai Hi, Maybe it makes sense to cluster CPU's in logical groups somehow. Some synchronization mechanism like EPOCH() are O(N²) where N is the number of CPUs. Not in the read-case, but in the synchronize case. It depends a bit though. Currently EPOCH() is executed every kern.hz . --HPS
Re: Link modules to DYN type
On 4/26/23 13:12, Konstantin Belousov wrote:
No, in-kernel linker does not behave this way.
Modules need to contain explicit reference to all modules they depend upon,
using the MODULE_DEPEND() macro. Only symbols from the dependencies are
resolved.
All modules get an implicit reference to kernel.
Hi Konstantin,
Maybe I wasn't so clear. Trying again:
diff --git a/sys/tests/ktest.c b/sys/tests/ktest.c
index 495fedf95dde..eb42cf062487 100644
--- a/sys/tests/ktest.c
+++ b/sys/tests/ktest.c
@@ -409,6 +409,12 @@ static moduledata_t ktestmod = {
0
};
+int
+printf(const char *fmt, ...)
+{
+ return (0);
+}
+
DECLARE_MODULE(ktestmod, ktestmod, SI_SUB_PSEUDO, SI_ORDER_ANY);
MODULE_VERSION(ktestmod, 1);
MODULE_DEPEND(ktestmod, netlink, 1, 1, 1);
Then kldload ktest.ko . Which printf() function will be used if ktest.c
calls printf() ?
I would expect a warning from the kernel at least ...
--HPS
Re: Link modules to DYN type
On 4/26/23 12:36, Zhenlei Huang wrote:
Hi,
I'm recently working on https://reviews.freebsd.org/D39638 (sysctl(9): Enable
vnet sysctl variables be loader tunable),
the changes to `sys/kern/link_elf_obj.c` are runtime tested, but not those to
`sys/kern/link_elf.c` .
After some hacking I realized that `link_elf.c` is for EXEC (Executable file)
or DYN (Shared object file), and `link_elf_obj.c` is
for REL (Relocatable file).
```
/* link_elf.c */
static int
link_elf_load_file(linker_class_t cls, const char* filename,
linker_file_t* result)
{
...
if (hdr->e_type != ET_EXEC && hdr->e_type != ET_DYN) {
error = ENOSYS;
goto out;
}
...
}
/* link_elf_obj.c */
static int
link_elf_load_file(linker_class_t cls, const char *filename,
linker_file_t *result)
{
...
if (hdr->e_type != ET_REL) {
error = ENOSYS;
goto out;
}
...
}
```
Run the following snip:
```
# find /boot/kernel -type f -name "*.ko" -exec readelf -h {} \; | grep Type
```
shows that all the kernel modules' types are `REL (Relocatable file)`.
I guess if some module such as if_bridge is linked to DYN type, then I can do
runtime for the changes to `sys/kern/link_elf.c`.
I'm not familiar with elf and linkers, is that ( compile module and link it to
DYN type ) possible ?
Hi,
I don't have an answer for you either, but I have seen in the past,
loading kernel modules behaves a bit like libraries, in the following
regard:
If two kernel modules define the same global symbol, then no warning is
given and the first loaded symbol definition (I think) is used to
resolve that symbol for all kernel modules, regardless of the prototype.
Probably we should not allow this. That's why building LINT is a good
thing, to avoid this issue.
Even if we don't have C++ support in the FreeBSD kernel, defining symbol
names the way C++ does for C could be nice for the kernel too, also with
regards to debugging systems.
Many times when I don't know what is going on, I do like this:
#include
if (not too fast or my sysctl debug) {
printf("My tracer\n");
kdb_backtrace();
}
Dtrace can also do this, but not during boot. Just track who is calling
those functions, and you'll probably find the answer to your question!
--HPS
Best regards,
Zhenlei
Re: Is it valid to combine CTLFLAG_TUN with CTLFLAG_VNET ?
On 4/5/23 21:44, Hans Petter Selasky wrote: On 4/5/23 20:23, Gleb Smirnoff wrote: What if we remove the CTLFLAG_VNET check from the code you posted above? I don't see anything going wrong, rather going right 😄 CTLFLAG_VNET will not mask away CTLFLAG_TUN. Hi Gleb, It's possible to bypass that check, but some work needs to be done first. Then all jails created, will also start from those sysctl tunable values. The problem is, where does the VNET base pointer come from? Especially those static sysctl's. You would need to make some design there I guess and look at the SYSINIT() order. When are SYSINIT's filled with tunable data's. And when is the default VNET created. Because the data pointer passed to the register sysctl function is simply an offset pointer into a malloc'ed structure. --HPS Hi Zhenlei, Feel free to work on this, and add me as a reviewer and complete phase two of: commit 3da1cf1e88f8448bb10c5f778ab56ff65c7a6938 Author: Hans Petter Selasky Date: Fri Jun 27 16:33:43 2014 + Extend the meaning of the CTLFLAG_TUN flag to automatically check if there is an environment variable which shall initialize the SYSCTL during early boot. This works for all SYSCTL types both statically and dynamically created ones, except for the SYSCTL NODE type and SYSCTLs which belong to VNETs. A new flag, CTLFLAG_NOFETCH, has been added to --HPS
Re: Is it valid to combine CTLFLAG_TUN with CTLFLAG_VNET ?
On 4/5/23 20:23, Gleb Smirnoff wrote: What if we remove the CTLFLAG_VNET check from the code you posted above? I don't see anything going wrong, rather going right 😄 CTLFLAG_VNET will not mask away CTLFLAG_TUN. Hi Gleb, It's possible to bypass that check, but some work needs to be done first. Then all jails created, will also start from those sysctl tunable values. The problem is, where does the VNET base pointer come from? Especially those static sysctl's. You would need to make some design there I guess and look at the SYSINIT() order. When are SYSINIT's filled with tunable data's. And when is the default VNET created. Because the data pointer passed to the register sysctl function is simply an offset pointer into a malloc'ed structure. --HPS
Re: vt and keyboard accents
On 1/29/23 09:48, Yuri wrote:
Hans Petter Selasky wrote:
On 1/29/23 01:54, Yuri wrote:
Looking into an issue with accents input for vt and cz (so
/usr/share/vt/keymaps/cz.kbd) keyboard where some of the accents are
working and other result weird unrelated characters output.
Checking kbdcontrol -d output, there is an obvious difference with
keymap contents -- all mappings are trimmed down to 1 byte after reading:
kbdcontrol:
dacu 180 ( 180 180 ) ( 'S' 'Z' ) ( 'Z' 'y' ) ( 's' '[' )
( 'z' 'z' ) ( 'R' 'T' ) ( 'A' 193 ) ( 'L' '9' )
( 'C' 006 ) ( 'E' 201 ) ( 'I' 205 ) ( 'N' 'C' )
( 'O' 211 ) ( 'U' 218 ) ( 'Y' 221 ) ( 'r' 'U' )
( 'a' 225 ) ( 'l' ':' ) ( 'c' 007 ) ( 'e' 233 )
( 'i' 237 ) ( 'n' 'D' ) ( 'o' 243 ) ( 'u' 250 )
( 'y' 253 )
keymap:
dacu 0xb4 ( 0xb4 0xb4 ) ( 'S' 0x015a ) ( 'Z' 0x0179 )
( 's' 0x015b )
( 'z' 0x017a ) ( 'R' 0x0154 ) ( 'A' 0xc1 )
( 'L' 0x0139 )
( 'C' 0x0106 ) ( 'E' 0xc9 ) ( 'I' 0xcd )
( 'N' 0x0143 )
( 'O' 0xd3 ) ( 'U' 0xda ) ( 'Y' 0xdd )
( 'r' 0x0155 )
( 'a' 0xe1 ) ( 'l' 0x013a ) ( 'c' 0x0107 )
( 'e' 0xe9 )
( 'i' 0xed ) ( 'n' 0x0144 ) ( 'o' 0xf3 )
( 'u' 0xfa )
( 'y' 0xfd )
Source of the problem is the following definition in sys/sys/kbio.h:
struct acc_t {
u_char accchar;
u_char map[NUM_ACCENTCHARS][2];
};
While the keymaps were converted to have the unicode characters for vt
in the commit below, the array to store them (map) was missed, or was
there a reason for this?
---
commit 7ba08f814546ece02e0193edc12cf6eb4d5cb8d4
Author: Stefan Eßer
Date: Sun Aug 17 19:54:21 2014 +
Attempt at converting the SYSCONS keymaps to Unicode for use with
NEWCONS.
I have spent many hours comparing source and destination formats,
and hope
to have caught the most severe conversion errors.
---
I have tried the following patch and it allows me to enter all accents
documented in the keymap, though I must admit I'm not sure it does not
have hidden issues:
diff --git a/sys/sys/kbio.h b/sys/sys/kbio.h
index 7f17bda76c5..fffeb63e226 100644
--- a/sys/sys/kbio.h
+++ b/sys/sys/kbio.h
@@ -200,7 +200,7 @@ typedef struct okeymap okeymap_t;
struct acc_t {
u_char accchar;
- u_char map[NUM_ACCENTCHARS][2];
+ int map[NUM_ACCENTCHARS][2];
};
Hi,
Using "int" for unicode characters is probably good for now. Your patch
looks good, but please also consider the "umlaut" case while at it
(multiple characters that become one)!
I think umlauts are already part of "accents" (duml keyword), e.g. in
cz.kbd:
duml 0xa8( 0xa8 0xa8) ( 'A'0xc4) ( 'E'0xcb)
( 'O'0xd6)
( 'U'0xdc) ( 'a'0xe4) ( 'e'0xeb)
( 'o'0xf6)
( 'u'0xfc)
So pressing Alt+Shift and "=/+" key, and then pressing one of AEOUaeou
keys would produce ÄËÖÜäëöü, respectively, and it currently works as all
of the ÄËÖÜäëöü characters can be written as single-byte unicode.
And the following dcar (that is, "caron") characters are all broken as
they need at least 2 bytes, pressing Shift and "=/+" key, and any of the
LSTZlstzCEDNRcednrUu would print nothing at all, produce garbage, or
print some control character (last byte only):
dcar 0x02c7 ( 0x02c7 0x02c7 ) ( 'L'0x013d ) ( 'S'0x0160 )
( 'T'0x0164 )
( 'Z'0x017d ) ( 'l'0x013e ) ( 's'0x0161 )
( 't'0x0165 )
( 'z'0x017e ) ( 'C'0x010c ) ( 'E'0x011a )
( 'D'0x010e )
( 'N'0x0147 ) ( 'R'0x0158 ) ( 'c'0x010d )
( 'e'0x011b )
( 'd'0x010f ) ( 'n'0x0148 ) ( 'r'0x0159 )
( 'U'0x016e )
( 'u'0x016f )
Hi Yuri,
Do you happen to know if we currently support these Norwegian-only umlauts?
For example written as "umlauts":
å b̊ c̊
Only the single-characters å and Å are of interest in the Norwegian
language.
--HPS
Re: vt and keyboard accents
On 1/29/23 01:54, Yuri wrote:
Looking into an issue with accents input for vt and cz (so
/usr/share/vt/keymaps/cz.kbd) keyboard where some of the accents are
working and other result weird unrelated characters output.
Checking kbdcontrol -d output, there is an obvious difference with
keymap contents -- all mappings are trimmed down to 1 byte after reading:
kbdcontrol:
dacu 180 ( 180 180 ) ( 'S' 'Z' ) ( 'Z' 'y' ) ( 's' '[' )
( 'z' 'z' ) ( 'R' 'T' ) ( 'A' 193 ) ( 'L' '9' )
( 'C' 006 ) ( 'E' 201 ) ( 'I' 205 ) ( 'N' 'C' )
( 'O' 211 ) ( 'U' 218 ) ( 'Y' 221 ) ( 'r' 'U' )
( 'a' 225 ) ( 'l' ':' ) ( 'c' 007 ) ( 'e' 233 )
( 'i' 237 ) ( 'n' 'D' ) ( 'o' 243 ) ( 'u' 250 )
( 'y' 253 )
keymap:
dacu 0xb4( 0xb4 0xb4) ( 'S'0x015a ) ( 'Z'0x0179 )
( 's'0x015b )
( 'z'0x017a ) ( 'R'0x0154 ) ( 'A'0xc1)
( 'L'0x0139 )
( 'C'0x0106 ) ( 'E'0xc9) ( 'I'0xcd)
( 'N'0x0143 )
( 'O'0xd3) ( 'U'0xda) ( 'Y'0xdd)
( 'r'0x0155 )
( 'a'0xe1) ( 'l'0x013a ) ( 'c'0x0107 )
( 'e'0xe9)
( 'i'0xed) ( 'n'0x0144 ) ( 'o'0xf3)
( 'u'0xfa)
( 'y'0xfd)
Source of the problem is the following definition in sys/sys/kbio.h:
struct acc_t {
u_char accchar;
u_char map[NUM_ACCENTCHARS][2];
};
While the keymaps were converted to have the unicode characters for vt
in the commit below, the array to store them (map) was missed, or was
there a reason for this?
---
commit 7ba08f814546ece02e0193edc12cf6eb4d5cb8d4
Author: Stefan Eßer
Date: Sun Aug 17 19:54:21 2014 +
Attempt at converting the SYSCONS keymaps to Unicode for use with
NEWCONS.
I have spent many hours comparing source and destination formats,
and hope
to have caught the most severe conversion errors.
---
I have tried the following patch and it allows me to enter all accents
documented in the keymap, though I must admit I'm not sure it does not
have hidden issues:
diff --git a/sys/sys/kbio.h b/sys/sys/kbio.h
index 7f17bda76c5..fffeb63e226 100644
--- a/sys/sys/kbio.h
+++ b/sys/sys/kbio.h
@@ -200,7 +200,7 @@ typedef struct okeymap okeymap_t;
struct acc_t {
u_char accchar;
- u_char map[NUM_ACCENTCHARS][2];
+ int map[NUM_ACCENTCHARS][2];
};
Hi,
Using "int" for unicode characters is probably good for now. Your patch
looks good, but please also consider the "umlaut" case while at it
(multiple characters that become one)!
--HPS
Re: TP-LINK USB no carrier after speed test
On 1/18/23 12:45, Gary Jennejohn wrote: It's not clear from the content of README.md whether Hans has added thunderbolt to the files under /sys/conf. Currently not so much has changed there, except from regularly rebasing the repository on top of FreeBSD-main. I currently have my hands full! --HPS
Re: RES: TP-LINK USB no carrier after speed test
On 1/17/23 14:13, Ivan Quitschal wrote: not THAT fine of course, since its limited to around 300mbps. when in USB 3 it reaches 600mbps just fine. but besides that limitation from the version 2.0, it really works. ive tried a whole day of heavy traffic here and nothing happened at all. rings any bells ? Yes, I see that too: ugen0.3: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (248mA) Works like a charm spd=HIGH, but probably not super-speed. Maybe the vendor does something different when the speed is super speed so that the BULK transport can move more data at a time ... Vendor documentation is wanted! Maybe you simply need to USB trace the protocol when super-speed is used and vendor drivers are in place. Right now there is no option to disable super speed only, but maybe try to run this command on all USB 3.x root HUBS: usbconfig -d X.Y set_config 255 Maybe the device will show up as high-speed on the other computer aswell. It's worth a try. --HPS
Re: ULE realtime scheduler advice needed
On 11/22/22 20:28, mike tancsa wrote: On 11/17/2022 11:47 PM, Hans Petter Selasky wrote: Hi, I'm doing some work with audio and have noticed some problems with the ULE scheduler. I have a program that generate audio based on key-presses. When no keys are pressed, the load is near 0%, but as soon as you start pressing keys, the load goes maybe to 80% of a CPU core. This program I run with rtprio 8 xxx. The issue I observe or hear actually, is that it takes too long until the scheduler grasps that this program needs it's own CPU core and stops time-sharing the program. When I however use cpuset -l xxx rtprio 8 yyy everything is good, and the program outputs realtime audio in-time. Or is this perhaps a CPU frequency stepping issue? Any advice on where to look? A long shot, but I am curious if by chance you have hwpstate_intel for your cpu frequency driver. If so, does setting dev.hwpstate_intel.0.epp=0 make any difference ? Yes, I have four of those, set to 50 by default. Let me try. --HPS
Re: ULE realtime scheduler advice needed
On 11/21/22 20:12, Mark Johnston wrote: There were some bug fixes earlier this year to address problems where high-priority threads were not getting scheduled quickly enough. If you're using an old kernel, they might improve things: Are any of these fixes merged to stable/13 ? --HPS
Re: ULE realtime scheduler advice needed
Hi Alexander, Thank you for the pointers. I will try it out. --HPS On 11/18/22 09:18, Alexander Leidinger wrote: Quoting Hans Petter Selasky (from Fri, 18 Nov 2022 05:47:58 +0100): Hi, I'm doing some work with audio and have noticed some problems with the ULE scheduler. I have a program that generate audio based on key-presses. When no keys are pressed, the load is near 0%, but as soon as you start pressing keys, the load goes maybe to 80% of a CPU core. This program I run with rtprio 8 xxx. The issue I observe or hear actually, is that it takes too long until the scheduler grasps that this program needs it's own CPU core and stops time-sharing the program. When I however use cpuset -l xxx rtprio 8 yyy everything is good, and the program outputs realtime audio in-time. I have something in my mind about ULE not handling idleprio and/or rtprio correctly, but I have no pointer to a validation of this. Or is this perhaps a CPU frequency stepping issue? You could play with rc.conf (/etc/rc.d/power_profile): performance_cpu_freq="HIGH" performance_cx_lowest="C3" # see sysctl hw.cpu.0 | grep cx economy_cx_lowest="C3" # see sysctl hw.cpu.0 | grep cx Your system may provide other Cx possibilities, and ging to a lower number (e.g. C1) means less power-saving but faster response from the CPU (I do not expect that this is causing the issue you have). Any advice on where to look? Potential sysctl to play with to change "interactivity detection" in ULE: https://www.mail-archive.com/freebsd-stable@freebsd.org/msg112118.html Bye, Alexander.
ULE realtime scheduler advice needed
Hi, I'm doing some work with audio and have noticed some problems with the ULE scheduler. I have a program that generate audio based on key-presses. When no keys are pressed, the load is near 0%, but as soon as you start pressing keys, the load goes maybe to 80% of a CPU core. This program I run with rtprio 8 xxx. The issue I observe or hear actually, is that it takes too long until the scheduler grasps that this program needs it's own CPU core and stops time-sharing the program. When I however use cpuset -l xxx rtprio 8 yyy everything is good, and the program outputs realtime audio in-time. Or is this perhaps a CPU frequency stepping issue? Any advice on where to look? --HPS
Re: DESPARATE: How to stop FreeBSD form sleeping / disable ACPI? (on FreeBSD14 CURRENT)
Hi, I don't know what you mean by "sleep", but some CPUs have bug and setting: sysctl machdep.idle=spin Helps! --HPS
Re: morse(6) sound
On 10/30/22 00:05, Nuno Teixeira wrote: Considering that morse could use same beep dsp code, instead of repeating dsp code inside morse, why not use a dsp library or something so that morse could use it without duplicating code? If you figure out a good name for it. Not sure if it is worth a library ... --HPS
Re: morse(6) sound
On 10/29/22 20:18, Nuno Teixeira wrote: Technically you could symlink the two - yes. Can't understand how, what do I missing? In the main() routine, the name of the program name is passed. Then you just check if argv[0] == "morse" and invoke main_morse() instead, if you see. Of course you need to write main_morse() first, but you can re-use all the dsp code in there. --HPS
Re: morse(6) sound
On 10/29/22 17:44, Nuno Teixeira wrote: Hello Hans, A few days ago I tried beep and it remembered me about morse sound only available to speaker and not to dsp. So, are you saying that morse could be changed to have dsp sound like beep? Thanks, Technically you could symlink the two - yes. --HPS Hans Petter Selasky escreveu no dia sábado, 29/10/2022 à(s) 16:33: On 10/29/22 15:36, Nuno Teixeira wrote: Hello, unixcw is what I was looking for. I think I will include it in some scripts just for fun :) I've started with base morse because it was nice if it can be updated to play on dsp too. And yes, `cw -w 60 < /etc/passwd` it's really cool. You may want to look at beep(1). Maybe the two could be integrated. --HPS
Re: morse(6) sound
On 10/29/22 15:36, Nuno Teixeira wrote: Hello, unixcw is what I was looking for. I think I will include it in some scripts just for fun :) I've started with base morse because it was nice if it can be updated to play on dsp too. And yes, `cw -w 60 < /etc/passwd` it's really cool. You may want to look at beep(1). Maybe the two could be integrated. --HPS
Re: Accessibility in the FreeBSD installer and console
On 7/18/22 14:46, Hans Petter Selasky wrote: Hi, There are three work in progress patches pending: 1) Updates for kernel https://reviews.freebsd.org/D35754 2) Updates for beep https://reviews.freebsd.org/D35772 3) New vtspeakd daemon https://reviews.freebsd.org/D35776 Please test if you can! Feedback is welcome. --HPS All patches are now updated containing new and interesting features! Please test! --HPS
Re: build world fails on raw_ip.c
On 10/4/22 15:49, Hans Petter Selasky wrote: On 10/4/22 15:35, Gary Jennejohn wrote: On Tue, 4 Oct 2022 15:20:05 +0200 Hans Petter Selasky wrote: On 10/4/22 15:14, Johan Hendriks wrote: I just updated the source today but now i get an error building world. The old build was from yesterday which was fine! Building /usr/obj/usr/src/amd64.amd64/sys/KRNL/raw_ip.o cc -target x86_64-unknown-freebsd14.0 > --sysroot=/usr/obj/usr/src/amd64.amd64/tmp > -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -c -O2 -pipe > -fno-strict-aliasing -march=broadwell -g -nostdinc -I. -I/usr/src/sys > -I/usr/src/sys/contrib/ck/include -I/usr/src/sys/contrib/libfdt > -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common > -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer > -fdebug-prefix-map=./machine=/usr/src/sys/amd64/include > -fdebug-prefix-map=./x86=/usr/src/sys/x86/include > -fdebug-prefix-map=./i386=/usr/src/sys/i386/include -mcmodel=kernel > -mno-red-zone -mno-mmx -mno-sse -msoft-float > -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector > -Wall -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign > -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs > -fdiagnostics-show-option -Wno-unknown-pragmas > -Wno-error=tautological-compare -Wno-error=empty-body > -Wno-error=parentheses-equality -Wno-error=unused-function > -Wno-error=pointer-sign -Wno-error=shift-negative-value > -Wno-address-of-packed-member -Wno-format-zero-length -mno-aes > -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/netinet/raw_ip.c /usr/src/sys/netinet/raw_ip.c:811:3: error: too few arguments to > function call, expected 4, have 2 IPSEC_CTLINPUT(ipv4, icmp); ^~ /usr/src/sys/netipsec/ipsec_support.h:222:61: note: expanded from macro > 'IPSEC_CTLINPUT' ipsec_kmod_ctlinput(proto ## _ipsec_support, __VA_ARGS__) ~~~ ^ /usr/src/sys/netipsec/ipsec_support.h:196:5: note: 'ipsec_kmod_ctlinput' > declared here int ipsec_kmod_ctlinput(struct ipsec_support * const, int, ^ 1 error generated. *** Error code 1 I've mailed the responsible committer. Just do: diff --git a/sys/amd64/conf/GENERIC b/sys/amd64/conf/GENERIC index 9178abba36cc..ed8045e48257 100644 --- a/sys/amd64/conf/GENERIC +++ b/sys/amd64/conf/GENERIC @@ -30,7 +30,7 @@ options PREEMPTION # Enable kernel thread preemption options VIMAGE # Subsystem virtualization, e.g. VNET options INET # InterNETworking options INET6 # IPv6 communications protocols -options IPSEC_SUPPORT # Allow kldload of ipsec and tcpmd5 +# options IPSEC_SUPPORT # Allow kldload of ipsec and tcpmd5 options ROUTE_MPATH # Multipath routing support options FIB_ALGO # Modular fib lookups options TCP_OFFLOAD # TCP offload For now. There are the usual other problems, like always assuming the every user has INET6 defined in their kernel config file. Here's an error I just saw: /usr/src/sys/netinet/tcp_subr.c:136:8: error: unknown type name 'ip6proto_ctlinput_t'; did you mean 'ipproto_ctlinput_t'? static ip6proto_ctlinput_t tcp6_ctlinput; ^~~ ipproto_ctlinput_t /usr/src/sys/netinet/ip_var.h:242:14: note: 'ipproto_ctlinput_t' declared here typedef void ipproto_ctlinput_t(struct icmp *); ^ 1 error generated. --- tcp_subr.o --- *** [tcp_subr.o] Error code 1 -- Gary Jennejohn I'll leave fixing the LINT-NOINET6 for Gleb. Seems like it needs a bit more changes. At least LINT and GENERIC is fine. --HPS Fixed too: https://cgit.freebsd.org/src/commit/?id=c2a808b977dd61c0d69d878cd1bef6b016114d14 Was trivial. --HPS
Re: build world fails on raw_ip.c
On 10/4/22 15:35, Gary Jennejohn wrote: On Tue, 4 Oct 2022 15:20:05 +0200 Hans Petter Selasky wrote: On 10/4/22 15:14, Johan Hendriks wrote: I just updated the source today but now i get an error building world. The old build was from yesterday which was fine! Building /usr/obj/usr/src/amd64.amd64/sys/KRNL/raw_ip.o cc -target x86_64-unknown-freebsd14.0 > --sysroot=/usr/obj/usr/src/amd64.amd64/tmp > -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -c -O2 -pipe > -fno-strict-aliasing -march=broadwell -g -nostdinc -I. -I/usr/src/sys > -I/usr/src/sys/contrib/ck/include -I/usr/src/sys/contrib/libfdt > -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common > -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer > -fdebug-prefix-map=./machine=/usr/src/sys/amd64/include > -fdebug-prefix-map=./x86=/usr/src/sys/x86/include > -fdebug-prefix-map=./i386=/usr/src/sys/i386/include -mcmodel=kernel > -mno-red-zone -mno-mmx -mno-sse -msoft-float > -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector > -Wall -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign > -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs > -fdiagnostics-show-option -Wno-unknown-pragmas > -Wno-error=tautological-compare -Wno-error=empty-body > -Wno-error=parentheses-equality -Wno-error=unused-function > -Wno-error=pointer-sign -Wno-error=shift-negative-value > -Wno-address-of-packed-member -Wno-format-zero-length -mno-aes > -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/netinet/raw_ip.c /usr/src/sys/netinet/raw_ip.c:811:3: error: too few arguments to > function call, expected 4, have 2 IPSEC_CTLINPUT(ipv4, icmp); ^~ /usr/src/sys/netipsec/ipsec_support.h:222:61: note: expanded from macro > 'IPSEC_CTLINPUT' ipsec_kmod_ctlinput(proto ## _ipsec_support, __VA_ARGS__) ~~~ ^ /usr/src/sys/netipsec/ipsec_support.h:196:5: note: 'ipsec_kmod_ctlinput' > declared here int ipsec_kmod_ctlinput(struct ipsec_support * const, int, ^ 1 error generated. *** Error code 1 I've mailed the responsible committer. Just do: diff --git a/sys/amd64/conf/GENERIC b/sys/amd64/conf/GENERIC index 9178abba36cc..ed8045e48257 100644 --- a/sys/amd64/conf/GENERIC +++ b/sys/amd64/conf/GENERIC @@ -30,7 +30,7 @@ options PREEMPTION # Enable kernel thread preemption optionsVIMAGE # Subsystem virtualization, e.g. VNET optionsINET# InterNETworking optionsINET6 # IPv6 communications protocols -optionsIPSEC_SUPPORT # Allow kldload of ipsec and tcpmd5 +# options IPSEC_SUPPORT # Allow kldload of ipsec and tcpmd5 optionsROUTE_MPATH # Multipath routing support optionsFIB_ALGO# Modular fib lookups optionsTCP_OFFLOAD # TCP offload For now. There are the usual other problems, like always assuming the every user has INET6 defined in their kernel config file. Here's an error I just saw: /usr/src/sys/netinet/tcp_subr.c:136:8: error: unknown type name 'ip6proto_ctlinput_t'; did you mean 'ipproto_ctlinput_t'? static ip6proto_ctlinput_t tcp6_ctlinput; ^~~ ipproto_ctlinput_t /usr/src/sys/netinet/ip_var.h:242:14: note: 'ipproto_ctlinput_t' declared here typedef voidipproto_ctlinput_t(struct icmp *); ^ 1 error generated. --- tcp_subr.o --- *** [tcp_subr.o] Error code 1 -- Gary Jennejohn I'll leave fixing the LINT-NOINET6 for Gleb. Seems like it needs a bit more changes. At least LINT and GENERIC is fine. --HPS
Re: build world fails on raw_ip.c
On 10/4/22 15:35, Gary Jennejohn wrote: On Tue, 4 Oct 2022 15:20:05 +0200 Hans Petter Selasky wrote: On 10/4/22 15:14, Johan Hendriks wrote: I just updated the source today but now i get an error building world. The old build was from yesterday which was fine! Building /usr/obj/usr/src/amd64.amd64/sys/KRNL/raw_ip.o cc -target x86_64-unknown-freebsd14.0 > --sysroot=/usr/obj/usr/src/amd64.amd64/tmp > -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -c -O2 -pipe > -fno-strict-aliasing -march=broadwell -g -nostdinc -I. -I/usr/src/sys > -I/usr/src/sys/contrib/ck/include -I/usr/src/sys/contrib/libfdt > -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common > -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer > -fdebug-prefix-map=./machine=/usr/src/sys/amd64/include > -fdebug-prefix-map=./x86=/usr/src/sys/x86/include > -fdebug-prefix-map=./i386=/usr/src/sys/i386/include -mcmodel=kernel > -mno-red-zone -mno-mmx -mno-sse -msoft-float > -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector > -Wall -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign > -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs > -fdiagnostics-show-option -Wno-unknown-pragmas > -Wno-error=tautological-compare -Wno-error=empty-body > -Wno-error=parentheses-equality -Wno-error=unused-function > -Wno-error=pointer-sign -Wno-error=shift-negative-value > -Wno-address-of-packed-member -Wno-format-zero-length -mno-aes > -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/netinet/raw_ip.c /usr/src/sys/netinet/raw_ip.c:811:3: error: too few arguments to > function call, expected 4, have 2 IPSEC_CTLINPUT(ipv4, icmp); ^~ /usr/src/sys/netipsec/ipsec_support.h:222:61: note: expanded from macro > 'IPSEC_CTLINPUT' ipsec_kmod_ctlinput(proto ## _ipsec_support, __VA_ARGS__) ~~~ ^ /usr/src/sys/netipsec/ipsec_support.h:196:5: note: 'ipsec_kmod_ctlinput' > declared here int ipsec_kmod_ctlinput(struct ipsec_support * const, int, ^ 1 error generated. *** Error code 1 I've mailed the responsible committer. Just do: diff --git a/sys/amd64/conf/GENERIC b/sys/amd64/conf/GENERIC index 9178abba36cc..ed8045e48257 100644 --- a/sys/amd64/conf/GENERIC +++ b/sys/amd64/conf/GENERIC @@ -30,7 +30,7 @@ options PREEMPTION # Enable kernel thread preemption optionsVIMAGE # Subsystem virtualization, e.g. VNET optionsINET# InterNETworking optionsINET6 # IPv6 communications protocols -optionsIPSEC_SUPPORT # Allow kldload of ipsec and tcpmd5 +# options IPSEC_SUPPORT # Allow kldload of ipsec and tcpmd5 optionsROUTE_MPATH # Multipath routing support optionsFIB_ALGO# Modular fib lookups optionsTCP_OFFLOAD # TCP offload For now. There are the usual other problems, like always assuming the every user has INET6 defined in their kernel config file. Here's an error I just saw: /usr/src/sys/netinet/tcp_subr.c:136:8: error: unknown type name 'ip6proto_ctlinput_t'; did you mean 'ipproto_ctlinput_t'? static ip6proto_ctlinput_t tcp6_ctlinput; ^~~ ipproto_ctlinput_t /usr/src/sys/netinet/ip_var.h:242:14: note: 'ipproto_ctlinput_t' declared here typedef voidipproto_ctlinput_t(struct icmp *); ^ 1 error generated. --- tcp_subr.o --- *** [tcp_subr.o] Error code 1 -- Gary Jennejohn I think this should fix it for now. Will let Gleb review when he's back in the office again. https://cgit.freebsd.org/src/commit/?id=9f69c0b87da3faa02abcedb69689b1ab1edf571a --HPS
Re: build world fails on raw_ip.c
On 10/4/22 15:14, Johan Hendriks wrote: I just updated the source today but now i get an error building world. The old build was from yesterday which was fine! Building /usr/obj/usr/src/amd64.amd64/sys/KRNL/raw_ip.o cc -target x86_64-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -c -O2 -pipe -fno-strict-aliasing -march=broadwell -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/ck/include -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fdebug-prefix-map=./machine=/usr/src/sys/amd64/include -fdebug-prefix-map=./x86=/usr/src/sys/x86/include -fdebug-prefix-map=./i386=/usr/src/sys/i386/include -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -Wall -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error=tautological-compare -Wno-error=empty-body -Wno-error=parentheses-equality -Wno-error=unused-function -Wno-error=pointer-sign -Wno-error=shift-negative-value -Wno-address-of-packed-member -Wno-format-zero-length -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/netinet/raw_ip.c /usr/src/sys/netinet/raw_ip.c:811:3: error: too few arguments to function call, expected 4, have 2 IPSEC_CTLINPUT(ipv4, icmp); ^~ /usr/src/sys/netipsec/ipsec_support.h:222:61: note: expanded from macro 'IPSEC_CTLINPUT' ipsec_kmod_ctlinput(proto ## _ipsec_support, __VA_ARGS__) ~~~ ^ /usr/src/sys/netipsec/ipsec_support.h:196:5: note: 'ipsec_kmod_ctlinput' declared here int ipsec_kmod_ctlinput(struct ipsec_support * const, int, ^ 1 error generated. *** Error code 1 I've mailed the responsible committer. Just do: diff --git a/sys/amd64/conf/GENERIC b/sys/amd64/conf/GENERIC index 9178abba36cc..ed8045e48257 100644 --- a/sys/amd64/conf/GENERIC +++ b/sys/amd64/conf/GENERIC @@ -30,7 +30,7 @@ options PREEMPTION # Enable kernel thread preemption optionsVIMAGE # Subsystem virtualization, e.g. VNET optionsINET# InterNETworking optionsINET6 # IPv6 communications protocols -optionsIPSEC_SUPPORT # Allow kldload of ipsec and tcpmd5 +# options IPSEC_SUPPORT # Allow kldload of ipsec and tcpmd5 optionsROUTE_MPATH # Multipath routing support optionsFIB_ALGO# Modular fib lookups optionsTCP_OFFLOAD # TCP offload For now. --HPS
Re: [RFC] Three patches for time infrastructure in FreeBSD!
On 10/3/22 15:26, Renato Botelho wrote: On 03/10/22 10:20, Hans Petter Selasky wrote: Hi, I've made three patches to improve conversion between timing units, like sbintime, and usecs and so on. I've been testing these for some days and can see a notiable difference when using realtime audio applications, in the form of less jitter, audio/hpsjam and video-chat using www/firefox . https://reviews.freebsd.org/D36857 https://reviews.freebsd.org/D36858 https://reviews.freebsd.org/D36858 You added D36858 twice. Off-by one: https://reviews.freebsd.org/D36859 --HPS
[RFC] Three patches for time infrastructure in FreeBSD!
Hi, I've made three patches to improve conversion between timing units, like sbintime, and usecs and so on. I've been testing these for some days and can see a notiable difference when using realtime audio applications, in the form of less jitter, audio/hpsjam and video-chat using www/firefox . https://reviews.freebsd.org/D36857 https://reviews.freebsd.org/D36858 https://reviews.freebsd.org/D36858 --HPS
Re: usbhid panic when switching vt-s (invariants+witness enabled)
On 9/30/22 12:31, Andriy Gapon wrote: On 26/09/2022 18:13, Hans Petter Selasky wrote: On 9/23/22 23:43, Hans Petter Selasky wrote: vpanic() at 0x808f4c84 = vpanic+0x184/frame 0xfe003590e900 panic() at 0x808f4a33 = panic+0x43/frame 0xfe003590e960 sleepq_add() at 0x809521ab = sleepq_add+0x37b/frame 0xfe003590e9b0 _sleep() at 0x80902118 = _sleep+0x238/frame 0xfe003590ea40 usbhid_sync_xfer() at 0x8532e071 = usbhid_sync_xfer+0x171/frame 0xfe003590eaa0 usbhid_set_report() at 0x8532db26 = usbhid_set_report+0x96/frame 0xfe003590eae0 hid_set_report() at 0x80686caa = hid_set_report+0x6a/frame 0xfe003590eb20 hidbus_write() at 0x85335a7c = hidbus_write+0x5c/frame 0xfe003590eb50 hid_write() at 0x80686b98 = hid_write+0x58/frame 0xfe003590eb80 hkbd_set_leds() at 0x85c1cfe6 = hkbd_set_leds+0x206/frame 0xfe003590ebc0 hkbd_ioctl_locked() at 0x85c1cd6b = hkbd_ioctl_locked+0x33b/frame 0xfe003590ec20 hkbd_ioctl_locked() at 0x85c1caff = hkbd_ioctl_locked+0xcf/frame 0xfe003590ec80 hkbd_ioctl() at 0x85c1ba5a = hkbd_ioctl+0xba/frame 0xfe003590ecc0 kbdmux_ioctl() at 0x80695d3b = kbdmux_ioctl+0x12b/frame 0xfe003590ed00 vt_window_switch() at 0x8079d969 = vt_window_switch+0x229/frame 0xfe003590ed40 vt_switch_timer() at 0x807a15a1 = vt_switch_timer+0x21/frame 0xfe003590ed60 Can you test this patch: https://reviews.freebsd.org/D36715 Sorry that it took a while. I cannot reproduce the problem after applying the patch. I see that you already committed the change, but I thought that I'd let you know. Thank you very much! You are welcome! --HPS
Re: RES: TP-LINK USB no carrier after speed test
On 9/28/22 11:47, Tomoaki AOKI wrote: As I stated on Bug 237666 [1], I have Titan Ridge TB3 bridge on my ThinkPad P52. The relevant part of HW probe is at comment 206 [2]. Are there any other info I can provide for Titan Ridge support? (Not yet tried the codes.) [1]https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237666 [2]https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237666#c206 I cannot promise anything and I don't have an overview which TB3 controllers are compatible with eachother. Maybe grepping for the PCI ID's in Linux will give some clues, hence I don't have access to any thunderbolt documentation myself! --HPS
Re: RES: TP-LINK USB no carrier after speed test
On 9/28/22 11:07, Ivan Quitschal wrote: On Tue, 27 Sep 2022, Hans Petter Selasky wrote: On 9/27/22 15:22, Hans Petter Selasky wrote: On 9/27/22 14:17, Ivan Quitschal wrote: On Tue, 27 Sep 2022, Hans Petter Selasky wrote: On 9/27/22 02:24, Alexander Motin wrote: On 26.09.2022 17:29, Hans Petter Selasky wrote: I've got a supposedly "broken" if_ure dongle from Alexander, but I'm unable to reproduce the if_ure hang on two different pieces of XHCI hardware, Intel based and AMD based, which I've got. This leads me to believe there is a bug in the XHCI driver or hardware on your system. Can you share the pciconfig -lv output for your XHCI controllers? I have two laptops of different generations reproducing this problem, but both are having Thunderbolt on the USB-C ports: This is one (7th Gen Core i7): xhci1@pci0:56:0:0: class=0x0c0330 rev=0x02 hdr=0x00 vendor=0x8086 device=0x15d4 subvendor=0x subdevice=0x vendor = 'Intel Corporation' device = 'JHL6540 Thunderbolt 3 USB Controller (C step) [Alpine Ridge 4C 2016]' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0xc3f0, size 65536, enabled cap 01[80] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 05[88] = MSI supports 8 messages, 64 bit enabled with 1 message cap 10[c0] = PCI-Express 2 endpoint max data 128(128) RO NS max read 512 link x4(x4) speed 2.5(2.5) ASPM disabled(L0s/L1) ClockPM disabled ecap 0003[100] = Serial 1 20ff910876f10c00 ecap 0001[200] = AER 1 0 fatal 0 non-fatal 1 corrected ecap 0002[300] = VC 1 max VC0 ecap 0004[400] = Power Budgeting 1 ecap 000b[500] = Vendor [1] ID 1234 Rev 1 Length 216 ecap 0018[600] = LTR 1 ecap 0019[700] = PCIe Sec 1 lane errors 0 This is another (11th Gen Core i7); xhci0@pci0:0:13:0: class=0x0c0330 rev=0x01 hdr=0x00 vendor=0x8086 device=0x9a13 subvendor=0x1028 subdevice=0x0991 vendor = 'Intel Corporation' device = 'Tiger Lake-LP Thunderbolt 4 USB Controller' class = serial bus subclass = USB bar [10] = type Memory, range 64, base 0x60552c, size 65536, enabled cap 01[70] = powerspec 2 supports D0 D3 current D0 cap 05[80] = MSI supports 8 messages, 64 bit enabled with 1 message cap 09[90] = vendor (length 20) Intel cap 15 version 0 cap 09[b0] = vendor (length 0) Intel cap 0 version 1 Does the system you also has Thunderbolt chip, or you use native Intel chipet's XHCI? Also, when running the stress test and you see the traffic stops, what happens if you run this command as root on the ugen which the if_ure belongs to: usbconfig -d ugenX.Y dump_string 0 Does the traffic resume? Nope. Out of 4 times when traffic stopped 2 times it reported and 2 times it completed successfully, but it neither case it recovered traffic. Only reset recovered it. Hi Alexander, Could you run "usbdump -d X.Y" at the same time to capture all the errors? Looking especially for USB_ERR_TIMEOUT . I have this: xhci0@pci0:3:0:3: class=0x0c0330 rev=0x00 hdr=0x00 vendor=0x1022 device=0x15e0 subvendor=0x1849 subdevice=0x vendor = 'Advanced Micro Devices, Inc. [AMD]' device = 'Raven USB 3.1' class = serial bus subclass = USB xhci0@pci0:0:20:0: class=0x0c0330 rev=0x21 hdr=0x00 vendor=0x8086 device=0x9d2f subvendor=0x8086 subdevice=0x9d2f vendor = 'Intel Corporation' device = 'Sunrise Point-LP USB 3.0 xHCI Controller' class = serial bus subclass = USB --HPS hi Hans i think i got some good logs for you before the problem i ran this: ugen0.10: at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (72mA) # usbconfig -d ugen0.10 >> before # usbconfig -d ugen0.10 dump_all_desc >> before # usbconfig -d ugen0.10 dump_stats >> before_status the after the problem happened i ran # usbconfig -d ugen0.10 >> after # usbconfig -d ugen0.10 dump_all_desc >> after # usbconfig -d ugen0.10 dump_stats >> after_status just by looking i already see some problems comparing both for example before the problem we have: -- ugen0.10: at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (72mA) ugen0.10: at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (72mA) bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0300 bDeviceClass = 0x bDeviceSubClass = 0x bDeviceProtocol = 0x bMaxPacketSize0 = 0x0009 idVendor = 0x2357 idProduct = 0x0601 bcdDevice = 0x3000 iManufacturer = 0x0001 iProduct = 0x0002 iSerialNumber = 0x0006 <01> bNumConfigurations = 0x0002 after the problem -- u
Re: RES: TP-LINK USB no carrier after speed test
On 9/27/22 15:22, Hans Petter Selasky wrote: On 9/27/22 14:17, Ivan Quitschal wrote: On Tue, 27 Sep 2022, Hans Petter Selasky wrote: On 9/27/22 02:24, Alexander Motin wrote: On 26.09.2022 17:29, Hans Petter Selasky wrote: I've got a supposedly "broken" if_ure dongle from Alexander, but I'm unable to reproduce the if_ure hang on two different pieces of XHCI hardware, Intel based and AMD based, which I've got. This leads me to believe there is a bug in the XHCI driver or hardware on your system. Can you share the pciconfig -lv output for your XHCI controllers? I have two laptops of different generations reproducing this problem, but both are having Thunderbolt on the USB-C ports: This is one (7th Gen Core i7): xhci1@pci0:56:0:0: class=0x0c0330 rev=0x02 hdr=0x00 vendor=0x8086 device=0x15d4 subvendor=0x subdevice=0x vendor = 'Intel Corporation' device = 'JHL6540 Thunderbolt 3 USB Controller (C step) [Alpine Ridge 4C 2016]' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0xc3f0, size 65536, enabled cap 01[80] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 05[88] = MSI supports 8 messages, 64 bit enabled with 1 message cap 10[c0] = PCI-Express 2 endpoint max data 128(128) RO NS max read 512 link x4(x4) speed 2.5(2.5) ASPM disabled(L0s/L1) ClockPM disabled ecap 0003[100] = Serial 1 20ff910876f10c00 ecap 0001[200] = AER 1 0 fatal 0 non-fatal 1 corrected ecap 0002[300] = VC 1 max VC0 ecap 0004[400] = Power Budgeting 1 ecap 000b[500] = Vendor [1] ID 1234 Rev 1 Length 216 ecap 0018[600] = LTR 1 ecap 0019[700] = PCIe Sec 1 lane errors 0 This is another (11th Gen Core i7); xhci0@pci0:0:13:0: class=0x0c0330 rev=0x01 hdr=0x00 vendor=0x8086 device=0x9a13 subvendor=0x1028 subdevice=0x0991 vendor = 'Intel Corporation' device = 'Tiger Lake-LP Thunderbolt 4 USB Controller' class = serial bus subclass = USB bar [10] = type Memory, range 64, base 0x60552c, size 65536, enabled cap 01[70] = powerspec 2 supports D0 D3 current D0 cap 05[80] = MSI supports 8 messages, 64 bit enabled with 1 message cap 09[90] = vendor (length 20) Intel cap 15 version 0 cap 09[b0] = vendor (length 0) Intel cap 0 version 1 Does the system you also has Thunderbolt chip, or you use native Intel chipet's XHCI? Also, when running the stress test and you see the traffic stops, what happens if you run this command as root on the ugen which the if_ure belongs to: usbconfig -d ugenX.Y dump_string 0 Does the traffic resume? Nope. Out of 4 times when traffic stopped 2 times it reported error> and 2 times it completed successfully, but it neither case it recovered traffic. Only reset recovered it. Hi Alexander, Could you run "usbdump -d X.Y" at the same time to capture all the errors? Looking especially for USB_ERR_TIMEOUT . I have this: xhci0@pci0:3:0:3: class=0x0c0330 rev=0x00 hdr=0x00 vendor=0x1022 device=0x15e0 subvendor=0x1849 subdevice=0x vendor = 'Advanced Micro Devices, Inc. [AMD]' device = 'Raven USB 3.1' class = serial bus subclass = USB xhci0@pci0:0:20:0: class=0x0c0330 rev=0x21 hdr=0x00 vendor=0x8086 device=0x9d2f subvendor=0x8086 subdevice=0x9d2f vendor = 'Intel Corporation' device = 'Sunrise Point-LP USB 3.0 xHCI Controller' class = serial bus subclass = USB --HPS hi Hans i think i got some good logs for you before the problem i ran this: ugen0.10: at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (72mA) # usbconfig -d ugen0.10 >> before # usbconfig -d ugen0.10 dump_all_desc >> before # usbconfig -d ugen0.10 dump_stats >> before_status the after the problem happened i ran # usbconfig -d ugen0.10 >> after # usbconfig -d ugen0.10 dump_all_desc >> after # usbconfig -d ugen0.10 dump_stats >> after_status just by looking i already see some problems comparing both for example before the problem we have: -- ugen0.10: at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (72mA) ugen0.10: at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (72mA) bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0300 bDeviceClass = 0x bDeviceSubClass = 0x bDeviceProtocol = 0x bMaxPacketSize0 = 0x0009 idVendor = 0x2357 idProduct = 0x0601 bcdDevice = 0x3000 iManufacturer = 0x0001 iProduct = 0x0002 iSerialNumber = 0x0006 <01> bNumConfigurations = 0x0002 after the problem -- ugen0.10: at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (72mA) ugen0.10: at usbus0, cfg=0 m
Re: RES: TP-LINK USB no carrier after speed test
On 9/27/22 14:17, Ivan Quitschal wrote: On Tue, 27 Sep 2022, Hans Petter Selasky wrote: On 9/27/22 02:24, Alexander Motin wrote: On 26.09.2022 17:29, Hans Petter Selasky wrote: I've got a supposedly "broken" if_ure dongle from Alexander, but I'm unable to reproduce the if_ure hang on two different pieces of XHCI hardware, Intel based and AMD based, which I've got. This leads me to believe there is a bug in the XHCI driver or hardware on your system. Can you share the pciconfig -lv output for your XHCI controllers? I have two laptops of different generations reproducing this problem, but both are having Thunderbolt on the USB-C ports: This is one (7th Gen Core i7): xhci1@pci0:56:0:0: class=0x0c0330 rev=0x02 hdr=0x00 vendor=0x8086 device=0x15d4 subvendor=0x subdevice=0x vendor = 'Intel Corporation' device = 'JHL6540 Thunderbolt 3 USB Controller (C step) [Alpine Ridge 4C 2016]' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0xc3f0, size 65536, enabled cap 01[80] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 05[88] = MSI supports 8 messages, 64 bit enabled with 1 message cap 10[c0] = PCI-Express 2 endpoint max data 128(128) RO NS max read 512 link x4(x4) speed 2.5(2.5) ASPM disabled(L0s/L1) ClockPM disabled ecap 0003[100] = Serial 1 20ff910876f10c00 ecap 0001[200] = AER 1 0 fatal 0 non-fatal 1 corrected ecap 0002[300] = VC 1 max VC0 ecap 0004[400] = Power Budgeting 1 ecap 000b[500] = Vendor [1] ID 1234 Rev 1 Length 216 ecap 0018[600] = LTR 1 ecap 0019[700] = PCIe Sec 1 lane errors 0 This is another (11th Gen Core i7); xhci0@pci0:0:13:0: class=0x0c0330 rev=0x01 hdr=0x00 vendor=0x8086 device=0x9a13 subvendor=0x1028 subdevice=0x0991 vendor = 'Intel Corporation' device = 'Tiger Lake-LP Thunderbolt 4 USB Controller' class = serial bus subclass = USB bar [10] = type Memory, range 64, base 0x60552c, size 65536, enabled cap 01[70] = powerspec 2 supports D0 D3 current D0 cap 05[80] = MSI supports 8 messages, 64 bit enabled with 1 message cap 09[90] = vendor (length 20) Intel cap 15 version 0 cap 09[b0] = vendor (length 0) Intel cap 0 version 1 Does the system you also has Thunderbolt chip, or you use native Intel chipet's XHCI? Also, when running the stress test and you see the traffic stops, what happens if you run this command as root on the ugen which the if_ure belongs to: usbconfig -d ugenX.Y dump_string 0 Does the traffic resume? Nope. Out of 4 times when traffic stopped 2 times it reported error> and 2 times it completed successfully, but it neither case it recovered traffic. Only reset recovered it. Hi Alexander, Could you run "usbdump -d X.Y" at the same time to capture all the errors? Looking especially for USB_ERR_TIMEOUT . I have this: xhci0@pci0:3:0:3: class=0x0c0330 rev=0x00 hdr=0x00 vendor=0x1022 device=0x15e0 subvendor=0x1849 subdevice=0x vendor = 'Advanced Micro Devices, Inc. [AMD]' device = 'Raven USB 3.1' class = serial bus subclass = USB xhci0@pci0:0:20:0: class=0x0c0330 rev=0x21 hdr=0x00 vendor=0x8086 device=0x9d2f subvendor=0x8086 subdevice=0x9d2f vendor = 'Intel Corporation' device = 'Sunrise Point-LP USB 3.0 xHCI Controller' class = serial bus subclass = USB --HPS hi Hans i think i got some good logs for you before the problem i ran this: ugen0.10: at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (72mA) # usbconfig -d ugen0.10 >> before # usbconfig -d ugen0.10 dump_all_desc >> before # usbconfig -d ugen0.10 dump_stats >> before_status the after the problem happened i ran # usbconfig -d ugen0.10 >> after # usbconfig -d ugen0.10 dump_all_desc >> after # usbconfig -d ugen0.10 dump_stats >> after_status just by looking i already see some problems comparing both for example before the problem we have: -- ugen0.10: at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (72mA) ugen0.10: at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (72mA) bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0300 bDeviceClass = 0x bDeviceSubClass = 0x bDeviceProtocol = 0x bMaxPacketSize0 = 0x0009 idVendor = 0x2357 idProduct = 0x0601 bcdDevice = 0x3000 iManufacturer = 0x0001 iProduct = 0x0002 iSerialNumber = 0x0006 <01> bNumConfigurations = 0x0002 after the problem -- ugen0.10: at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (72mA) ugen0.10: at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (72mA)
Re: RES: TP-LINK USB no carrier after speed test
On 9/27/22 02:24, Alexander Motin wrote: On 26.09.2022 17:29, Hans Petter Selasky wrote: I've got a supposedly "broken" if_ure dongle from Alexander, but I'm unable to reproduce the if_ure hang on two different pieces of XHCI hardware, Intel based and AMD based, which I've got. This leads me to believe there is a bug in the XHCI driver or hardware on your system. Can you share the pciconfig -lv output for your XHCI controllers? I have two laptops of different generations reproducing this problem, but both are having Thunderbolt on the USB-C ports: This is one (7th Gen Core i7): xhci1@pci0:56:0:0: class=0x0c0330 rev=0x02 hdr=0x00 vendor=0x8086 device=0x15d4 subvendor=0x subdevice=0x vendor = 'Intel Corporation' device = 'JHL6540 Thunderbolt 3 USB Controller (C step) [Alpine Ridge 4C 2016]' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0xc3f0, size 65536, enabled cap 01[80] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 05[88] = MSI supports 8 messages, 64 bit enabled with 1 message cap 10[c0] = PCI-Express 2 endpoint max data 128(128) RO NS max read 512 link x4(x4) speed 2.5(2.5) ASPM disabled(L0s/L1) ClockPM disabled ecap 0003[100] = Serial 1 20ff910876f10c00 ecap 0001[200] = AER 1 0 fatal 0 non-fatal 1 corrected ecap 0002[300] = VC 1 max VC0 ecap 0004[400] = Power Budgeting 1 ecap 000b[500] = Vendor [1] ID 1234 Rev 1 Length 216 ecap 0018[600] = LTR 1 ecap 0019[700] = PCIe Sec 1 lane errors 0 This is another (11th Gen Core i7); xhci0@pci0:0:13:0: class=0x0c0330 rev=0x01 hdr=0x00 vendor=0x8086 device=0x9a13 subvendor=0x1028 subdevice=0x0991 vendor = 'Intel Corporation' device = 'Tiger Lake-LP Thunderbolt 4 USB Controller' class = serial bus subclass = USB bar [10] = type Memory, range 64, base 0x60552c, size 65536, enabled cap 01[70] = powerspec 2 supports D0 D3 current D0 cap 05[80] = MSI supports 8 messages, 64 bit enabled with 1 message cap 09[90] = vendor (length 20) Intel cap 15 version 0 cap 09[b0] = vendor (length 0) Intel cap 0 version 1 Does the system you also has Thunderbolt chip, or you use native Intel chipet's XHCI? Also, when running the stress test and you see the traffic stops, what happens if you run this command as root on the ugen which the if_ure belongs to: usbconfig -d ugenX.Y dump_string 0 Does the traffic resume? Nope. Out of 4 times when traffic stopped 2 times it reported error> and 2 times it completed successfully, but it neither case it recovered traffic. Only reset recovered it. Hi Alexander, Could you run "usbdump -d X.Y" at the same time to capture all the errors? Looking especially for USB_ERR_TIMEOUT . I have this: xhci0@pci0:3:0:3: class=0x0c0330 rev=0x00 hdr=0x00 vendor=0x1022 device=0x15e0 subvendor=0x1849 subdevice=0x vendor = 'Advanced Micro Devices, Inc. [AMD]' device = 'Raven USB 3.1' class = serial bus subclass = USB xhci0@pci0:0:20:0: class=0x0c0330 rev=0x21 hdr=0x00 vendor=0x8086 device=0x9d2f subvendor=0x8086 subdevice=0x9d2f vendor = 'Intel Corporation' device = 'Sunrise Point-LP USB 3.0 xHCI Controller' class = serial bus subclass = USB --HPS
Re: RES: RES: TP-LINK USB no carrier after speed test
On 9/27/22 00:25, Ivan Quitschal wrote: Hi Hans, how do you want me to do those tests for you ? with or without any of your patches? With the actual code on git ? Without any patches. --HPS
Re: RES: TP-LINK USB no carrier after speed test
On 9/26/22 21:28, Alexander Motin wrote: Ivan, On 26.09.2022 13:11, Ivan Quitschal wrote: bad news im afraid, problem occurred at the first attempt on speedtest.net. and I'm really trying to help you analizying this code here myself, but problem is: im far from expert on network protocol business. if it is a network problem at all. seems to me more like a USB protocol limit issue or something .. just FYI , limiting that first constant to 2048 still limits my upload to 90mbps , and also still solves the issue .. there has to be something about it obviously On my tests I found that reduction of URE_MAX_TX from 4 to 1 actually help a lot more without so dramatic performance decrease. Though it is likely only a workaround and does not explain the cause, so I hope Hans more ideas for us to test. ;) Hi, I've got a supposedly "broken" if_ure dongle from Alexander, but I'm unable to reproduce the if_ure hang on two different pieces of XHCI hardware, Intel based and AMD based, which I've got. This leads me to believe there is a bug in the XHCI driver or hardware on your system. Can you share the pciconfig -lv output for your XHCI controllers? Also, when running the stress test and you see the traffic stops, what happens if you run this command as root on the ugen which the if_ure belongs to: usbconfig -d ugenX.Y dump_string 0 Does the traffic resume? --HPS
Re: usbhid panic when switching vt-s (invariants+witness enabled)
On 9/23/22 23:43, Hans Petter Selasky wrote: vpanic() at 0x808f4c84 = vpanic+0x184/frame 0xfe003590e900 panic() at 0x808f4a33 = panic+0x43/frame 0xfe003590e960 sleepq_add() at 0x809521ab = sleepq_add+0x37b/frame 0xfe003590e9b0 _sleep() at 0x80902118 = _sleep+0x238/frame 0xfe003590ea40 usbhid_sync_xfer() at 0x8532e071 = usbhid_sync_xfer+0x171/frame 0xfe003590eaa0 usbhid_set_report() at 0x8532db26 = usbhid_set_report+0x96/frame 0xfe003590eae0 hid_set_report() at 0x80686caa = hid_set_report+0x6a/frame 0xfe003590eb20 hidbus_write() at 0x85335a7c = hidbus_write+0x5c/frame 0xfe003590eb50 hid_write() at 0x80686b98 = hid_write+0x58/frame 0xfe003590eb80 hkbd_set_leds() at 0x85c1cfe6 = hkbd_set_leds+0x206/frame 0xfe003590ebc0 hkbd_ioctl_locked() at 0x85c1cd6b = hkbd_ioctl_locked+0x33b/frame 0xfe003590ec20 hkbd_ioctl_locked() at 0x85c1caff = hkbd_ioctl_locked+0xcf/frame 0xfe003590ec80 hkbd_ioctl() at 0x85c1ba5a = hkbd_ioctl+0xba/frame 0xfe003590ecc0 kbdmux_ioctl() at 0x80695d3b = kbdmux_ioctl+0x12b/frame 0xfe003590ed00 vt_window_switch() at 0x8079d969 = vt_window_switch+0x229/frame 0xfe003590ed40 vt_switch_timer() at 0x807a15a1 = vt_switch_timer+0x21/frame 0xfe003590ed60 Can you test this patch: https://reviews.freebsd.org/D36715 --HPS
Re: RES: TP-LINK USB no carrier after speed test
Hi Ivan,
Can you revert all if_ure patches, and try this one instead.
--HPSdiff --git a/sys/dev/usb/controller/xhci.c b/sys/dev/usb/controller/xhci.c
index 045be9a40b99..09aefb02687d 100644
--- a/sys/dev/usb/controller/xhci.c
+++ b/sys/dev/usb/controller/xhci.c
@@ -2848,8 +2848,16 @@ xhci_transfer_insert(struct usb_xfer *xfer)
/* check if already inserted */
if (xfer->flags_int.bandwidth_reclaimed) {
- DPRINTFN(8, "Already in schedule\n");
- return (0);
+ DPRINTFN(8, "Already in schedule (ringin doorbell only)\n");
+
+ /*
+ * Apparently there may be a race with multi
+ * buffering, that the hardware doesn't see the new
+ * chain bit value and stops the endpoint
+ * execution. Fix this by ringing the doorbell after
+ * each and every job that has been completed.
+ */
+ goto ring_doorbell;
}
pepext = xhci_get_endpoint_ext(xfer->xroot->udev,
@@ -2966,6 +2974,7 @@ xhci_transfer_insert(struct usb_xfer *xfer)
xfer->flags_int.bandwidth_reclaimed = 1;
+ring_doorbell:
xhci_endpoint_doorbell(xfer);
return (0);
Re: usbhid panic when switching vt-s (invariants+witness enabled)
On 9/23/22 23:33, Andriy Gapon wrote: It seems that the problem may be related to different keyboard LED states between the VTs. The system is a fresh stable/13. The panic looks like an attempt to sleep while in an interrupt thread (a callout?). Hi, I suspect vt_switch_timer must have a task to handle those requests, which allows sleeping. Vladimir, will you handle this? It is a minor regression issue when using the new usbhid feature. --HPS panic: sleepq_add: td 0xf80006af to sleep on wchan 0xf802ea752e08 with sleeping prohibited cpuid = 5 time = 1663940484 KDB: stack backtrace: db_trace_self_wrapper() at 0x8061555b = db_trace_self_wrapper+0x2b/frame 0xfe003590e7f0 kdb_backtrace() at 0x80942637 = kdb_backtrace+0x37/frame 0xfe003590e8a0 vpanic() at 0x808f4c84 = vpanic+0x184/frame 0xfe003590e900 panic() at 0x808f4a33 = panic+0x43/frame 0xfe003590e960 sleepq_add() at 0x809521ab = sleepq_add+0x37b/frame 0xfe003590e9b0 _sleep() at 0x80902118 = _sleep+0x238/frame 0xfe003590ea40 usbhid_sync_xfer() at 0x8532e071 = usbhid_sync_xfer+0x171/frame 0xfe003590eaa0 usbhid_set_report() at 0x8532db26 = usbhid_set_report+0x96/frame 0xfe003590eae0 hid_set_report() at 0x80686caa = hid_set_report+0x6a/frame 0xfe003590eb20 hidbus_write() at 0x85335a7c = hidbus_write+0x5c/frame 0xfe003590eb50 hid_write() at 0x80686b98 = hid_write+0x58/frame 0xfe003590eb80 hkbd_set_leds() at 0x85c1cfe6 = hkbd_set_leds+0x206/frame 0xfe003590ebc0 hkbd_ioctl_locked() at 0x85c1cd6b = hkbd_ioctl_locked+0x33b/frame 0xfe003590ec20 hkbd_ioctl_locked() at 0x85c1caff = hkbd_ioctl_locked+0xcf/frame 0xfe003590ec80 hkbd_ioctl() at 0x85c1ba5a = hkbd_ioctl+0xba/frame 0xfe003590ecc0 kbdmux_ioctl() at 0x80695d3b = kbdmux_ioctl+0x12b/frame 0xfe003590ed00 vt_window_switch() at 0x8079d969 = vt_window_switch+0x229/frame 0xfe003590ed40 vt_switch_timer() at 0x807a15a1 = vt_switch_timer+0x21/frame 0xfe003590ed60 softclock_call_cc() at 0x809127c4 = softclock_call_cc+0x244/frame 0xfe003590ee20 softclock() at 0x80912c1c = softclock+0x7c/frame 0xfe003590ee50 ithread_loop() at 0x808b662a = ithread_loop+0x2da/frame 0xfe003590eef0 fork_exit() at 0x808b2f85 = fork_exit+0xc5/frame 0xfe003590ef30 fork_trampoline() at 0x80c084fe = fork_trampoline+0xe/frame 0xfe003590ef30
Re: RES: TP-LINK USB no carrier after speed test
Hi Ivan,
Can you also test this USB kernel patch? And revert your if_ure.c patch?
--HPSdiff --git a/sys/dev/usb/usb_transfer.c b/sys/dev/usb/usb_transfer.c
index 20ed2c897aac..757697926106 100644
--- a/sys/dev/usb/usb_transfer.c
+++ b/sys/dev/usb/usb_transfer.c
@@ -419,6 +419,7 @@ usbd_get_max_frame_length(const struct usb_endpoint_descriptor *edesc,
switch (type) {
case UE_CONTROL:
+ case UE_BULK:
max_packet_count = 1;
break;
case UE_ISOCHRONOUS:
@@ -529,6 +530,7 @@ usbd_transfer_setup_sub(struct usb_setup_params *parm)
switch (type) {
case UE_CONTROL:
+ case UE_BULK:
xfer->max_packet_count = 1;
break;
case UE_ISOCHRONOUS:
Re: RES: TP-LINK USB no carrier after speed test
On 9/18/22 13:50, Ivan Quitschal wrote: Hi Hans just a heads up, it worked, tested a thousand times and the problem does not occur anylonger after i changed the constant to 2048 but upload speed was affcted a little i believe. insted of 600/300 of internet speed , im having 600/90 but thats fine, way better now. should this bug be in bugzilla for this ure driver as well wehave for axge? thanks --tzk Hi Ivan, I got one of those if_ure adapters at my hand, and will test it a bit before concluding. Stay tuned and thanks for your testing efforts! --HPS
Re: RES: TP-LINK USB no carrier after speed test
On 9/16/22 16:31, Ivan Quitschal wrote: -Mensagem original- De: Hans Petter Selasky Enviada em: sexta-feira, 16 de setembro de 2022 10:40 Para: Ivan Quitschal Cc: freebsd-current@freebsd.org Assunto: Re: TP-LINK USB no carrier after speed test On 9/16/22 14:18, Ivan Quitschal wrote: On Fri, 16 Sep 2022, Hans Petter Selasky wrote: On 9/16/22 08:34, Hans Petter Selasky wrote: On 9/16/22 08:20, Hans Petter Selasky wrote: On 9/15/22 17:36, Ivan Quitschal wrote: On Thu, 15 Sep 2022, Ivan Quitschal wrote: On Thu, 15 Sep 2022, Hans Petter Selasky wrote: On 9/15/22 17:18, Hans Petter Selasky wrote: On 9/15/22 17:16, Ivan Quitschal wrote: Hi All Does anybody have any idea what could be happening here?. I have a laptop DELL INSPIRON 3511 and everything works just fine, literally everything. even the iwlwifi0. But in order to use my full 600mbps, i dont use the wireless but a TP-LINK USB ethernet connected on "ue0" ugen0.6: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (200mA) but something really strange is happening .. everytime i open the chromium e do a speedtest (could be speedtest.net or any other) , at the end of the test the eth interface dies .. it changes from full-duplex to half-duplex/no carrier and the only way to get the internet back thru ue0 is by rebooting the whole thing. not even a "service netif restart" does anything if anyone has any ideas why is that , would be appreciated Hi, I think it some new features they use in the USB data protocol which we don't support. Check the Linux code. Between does: usbconfig -d 0.6 reset recover the device? --HPS Hi, Search for axge on bugzilla: I suspect you are using this chipset: Try: usbconfig show_ifdrv To know for sure. Also see: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F% 2Fbugs.freebsd.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D210488&d ata=05%7C01%7C%7C7d0b875611fa4c22aa6808da97e8f75a%7C84df9e7fe9f6 40afb435%7C1%7C0%7C637989324107373931%7CUnknown%7C TW FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC JXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=o%2B12TNKJ4bcBBj1b4r4TT 1f xyEalCMDMjOepy3MZm5c%3D&reserved=0 --HPS Hi Hans, actually the driver i use is not agxe (i thought it would be by the time i bought the usbcard) this is the module im using if_ure.ko and thank you , yes, reseting the usb entry with your command worked just fine. i got the internet back after doing this usbconfig -d 0.6 reset do we have a bug here then? thank you --tzk oh, i forgot to mention that the ure driver freezes not during the download test but in the middle of the upload, always dont know if that helps thanks --tzk Hi Ivan, Yes, there seems to be problem there. I need to look at the driver. Maybe it is simply sending too much data, than the device can handle! --HPS Hi, Try lowering this constant to 8192: sys/dev/usb/net/if_urereg.h:#define URE_TX_BUFSZ 16384 Then recompile and install if_ure: make -C sys/modules/usb/ure KMODDIR=/boot/kernel all install --HPS You can also try other values, like subtracting one. --HPS hi Hans, it worked but with a cost. i tried 8192 and it works 5 tests (5 speed tests in a row). freezes on the 6th. then i tried 4096 no success then i tried bufsize 2048 and its working now, i did several tests in a row and the internet keeps working just fine. but i noticed that the speed also dropped. with the same server , testing on windows, it goes like: 600 download / 300 upload and on freebsd with 2048 bufsiz it goes like: 300 download / 150 upload so it worked with a cost like i said, i had to give up half of my bandwitch what do you think ? and thank you again --tzk Hi, Can you try this instead: usbconfig -d X.Y set_config 1 X.Y are the numbers after ugenX.Y Then it will use a different driver. --HPS Hi Hans, After the usbconfig -d X.Y set_config 1, the interface doesn't work anymore, how can I undo this? Thanks Ivan usbconfig -d X.Y set_config 0 or usbconfig -d X.Y reset Did you check dmesg? --HPS
Re: TP-LINK USB no carrier after speed test
Hi, I compared the Linux code and the FreeBSD code, and the Linux code has firmware upload support for this device. Maybe implementing that will fix some issues. Will come back to this after EuroBSDcon :-) --HPS
Re: TP-LINK USB no carrier after speed test
On 9/16/22 14:18, Ivan Quitschal wrote: On Fri, 16 Sep 2022, Hans Petter Selasky wrote: On 9/16/22 08:34, Hans Petter Selasky wrote: On 9/16/22 08:20, Hans Petter Selasky wrote: On 9/15/22 17:36, Ivan Quitschal wrote: On Thu, 15 Sep 2022, Ivan Quitschal wrote: On Thu, 15 Sep 2022, Hans Petter Selasky wrote: On 9/15/22 17:18, Hans Petter Selasky wrote: On 9/15/22 17:16, Ivan Quitschal wrote: Hi All Does anybody have any idea what could be happening here?. I have a laptop DELL INSPIRON 3511 and everything works just fine, literally everything. even the iwlwifi0. But in order to use my full 600mbps, i dont use the wireless but a TP-LINK USB ethernet connected on "ue0" ugen0.6: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (200mA) but something really strange is happening .. everytime i open the chromium e do a speedtest (could be speedtest.net or any other) , at the end of the test the eth interface dies .. it changes from full-duplex to half-duplex/no carrier and the only way to get the internet back thru ue0 is by rebooting the whole thing. not even a "service netif restart" does anything if anyone has any ideas why is that , would be appreciated Hi, I think it some new features they use in the USB data protocol which we don't support. Check the Linux code. Between does: usbconfig -d 0.6 reset recover the device? --HPS Hi, Search for axge on bugzilla: I suspect you are using this chipset: Try: usbconfig show_ifdrv To know for sure. Also see: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.freebsd.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D210488&data=05%7C01%7C%7C266a987745fc4f2d0b9008da97ae1d13%7C84df9e7fe9f640afb435%7C1%7C0%7C637989071335334015%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zKuhXtYc%2FG3qpRtU%2FZNr5uEeQARsGudcWIlC1bVOsLE%3D&reserved=0 --HPS Hi Hans, actually the driver i use is not agxe (i thought it would be by the time i bought the usbcard) this is the module im using if_ure.ko and thank you , yes, reseting the usb entry with your command worked just fine. i got the internet back after doing this usbconfig -d 0.6 reset do we have a bug here then? thank you --tzk oh, i forgot to mention that the ure driver freezes not during the download test but in the middle of the upload, always dont know if that helps thanks --tzk Hi Ivan, Yes, there seems to be problem there. I need to look at the driver. Maybe it is simply sending too much data, than the device can handle! --HPS Hi, Try lowering this constant to 8192: sys/dev/usb/net/if_urereg.h:#define URE_TX_BUFSZ 16384 Then recompile and install if_ure: make -C sys/modules/usb/ure KMODDIR=/boot/kernel all install --HPS You can also try other values, like subtracting one. --HPS hi Hans, it worked but with a cost. i tried 8192 and it works 5 tests (5 speed tests in a row). freezes on the 6th. then i tried 4096 no success then i tried bufsize 2048 and its working now, i did several tests in a row and the internet keeps working just fine. but i noticed that the speed also dropped. with the same server , testing on windows, it goes like: 600 download / 300 upload and on freebsd with 2048 bufsiz it goes like: 300 download / 150 upload so it worked with a cost like i said, i had to give up half of my bandwitch what do you think ? and thank you again --tzk Hi, Can you try this instead: usbconfig -d X.Y set_config 1 X.Y are the numbers after ugenX.Y Then it will use a different driver. --HPS
Re: TP-LINK USB no carrier after speed test
On 9/16/22 08:34, Hans Petter Selasky wrote: On 9/16/22 08:20, Hans Petter Selasky wrote: On 9/15/22 17:36, Ivan Quitschal wrote: On Thu, 15 Sep 2022, Ivan Quitschal wrote: On Thu, 15 Sep 2022, Hans Petter Selasky wrote: On 9/15/22 17:18, Hans Petter Selasky wrote: On 9/15/22 17:16, Ivan Quitschal wrote: Hi All Does anybody have any idea what could be happening here?. I have a laptop DELL INSPIRON 3511 and everything works just fine, literally everything. even the iwlwifi0. But in order to use my full 600mbps, i dont use the wireless but a TP-LINK USB ethernet connected on "ue0" ugen0.6: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (200mA) but something really strange is happening .. everytime i open the chromium e do a speedtest (could be speedtest.net or any other) , at the end of the test the eth interface dies .. it changes from full-duplex to half-duplex/no carrier and the only way to get the internet back thru ue0 is by rebooting the whole thing. not even a "service netif restart" does anything if anyone has any ideas why is that , would be appreciated Hi, I think it some new features they use in the USB data protocol which we don't support. Check the Linux code. Between does: usbconfig -d 0.6 reset recover the device? --HPS Hi, Search for axge on bugzilla: I suspect you are using this chipset: Try: usbconfig show_ifdrv To know for sure. Also see: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.freebsd.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D210488&data=05%7C01%7C%7Ce7f888b3635f4e898ca308da972fa69b%7C84df9e7fe9f640afb435%7C1%7C0%7C637988528164303655%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zvw7m8lJ%2FHocK%2FXJIDfdPv%2FArCpE5pk9lYz%2BY8WzMCc%3D&reserved=0 --HPS Hi Hans, actually the driver i use is not agxe (i thought it would be by the time i bought the usbcard) this is the module im using if_ure.ko and thank you , yes, reseting the usb entry with your command worked just fine. i got the internet back after doing this usbconfig -d 0.6 reset do we have a bug here then? thank you --tzk oh, i forgot to mention that the ure driver freezes not during the download test but in the middle of the upload, always dont know if that helps thanks --tzk Hi Ivan, Yes, there seems to be problem there. I need to look at the driver. Maybe it is simply sending too much data, than the device can handle! --HPS Hi, Try lowering this constant to 8192: sys/dev/usb/net/if_urereg.h:#define URE_TX_BUFSZ 16384 Then recompile and install if_ure: make -C sys/modules/usb/ure KMODDIR=/boot/kernel all install --HPS You can also try other values, like subtracting one. --HPS
Re: TP-LINK USB no carrier after speed test
On 9/16/22 08:20, Hans Petter Selasky wrote: On 9/15/22 17:36, Ivan Quitschal wrote: On Thu, 15 Sep 2022, Ivan Quitschal wrote: On Thu, 15 Sep 2022, Hans Petter Selasky wrote: On 9/15/22 17:18, Hans Petter Selasky wrote: On 9/15/22 17:16, Ivan Quitschal wrote: Hi All Does anybody have any idea what could be happening here?. I have a laptop DELL INSPIRON 3511 and everything works just fine, literally everything. even the iwlwifi0. But in order to use my full 600mbps, i dont use the wireless but a TP-LINK USB ethernet connected on "ue0" ugen0.6: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (200mA) but something really strange is happening .. everytime i open the chromium e do a speedtest (could be speedtest.net or any other) , at the end of the test the eth interface dies .. it changes from full-duplex to half-duplex/no carrier and the only way to get the internet back thru ue0 is by rebooting the whole thing. not even a "service netif restart" does anything if anyone has any ideas why is that , would be appreciated Hi, I think it some new features they use in the USB data protocol which we don't support. Check the Linux code. Between does: usbconfig -d 0.6 reset recover the device? --HPS Hi, Search for axge on bugzilla: I suspect you are using this chipset: Try: usbconfig show_ifdrv To know for sure. Also see: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.freebsd.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D210488&data=05%7C01%7C%7Ce7f888b3635f4e898ca308da972fa69b%7C84df9e7fe9f640afb435%7C1%7C0%7C637988528164303655%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zvw7m8lJ%2FHocK%2FXJIDfdPv%2FArCpE5pk9lYz%2BY8WzMCc%3D&reserved=0 --HPS Hi Hans, actually the driver i use is not agxe (i thought it would be by the time i bought the usbcard) this is the module im using if_ure.ko and thank you , yes, reseting the usb entry with your command worked just fine. i got the internet back after doing this usbconfig -d 0.6 reset do we have a bug here then? thank you --tzk oh, i forgot to mention that the ure driver freezes not during the download test but in the middle of the upload, always dont know if that helps thanks --tzk Hi Ivan, Yes, there seems to be problem there. I need to look at the driver. Maybe it is simply sending too much data, than the device can handle! --HPS Hi, Try lowering this constant to 8192: sys/dev/usb/net/if_urereg.h:#define URE_TX_BUFSZ16384 Then recompile and install if_ure: make -C sys/modules/usb/ure KMODDIR=/boot/kernel all install --HPS
Re: TP-LINK USB no carrier after speed test
On 9/15/22 17:36, Ivan Quitschal wrote: On Thu, 15 Sep 2022, Ivan Quitschal wrote: On Thu, 15 Sep 2022, Hans Petter Selasky wrote: On 9/15/22 17:18, Hans Petter Selasky wrote: On 9/15/22 17:16, Ivan Quitschal wrote: Hi All Does anybody have any idea what could be happening here?. I have a laptop DELL INSPIRON 3511 and everything works just fine, literally everything. even the iwlwifi0. But in order to use my full 600mbps, i dont use the wireless but a TP-LINK USB ethernet connected on "ue0" ugen0.6: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (200mA) but something really strange is happening .. everytime i open the chromium e do a speedtest (could be speedtest.net or any other) , at the end of the test the eth interface dies .. it changes from full-duplex to half-duplex/no carrier and the only way to get the internet back thru ue0 is by rebooting the whole thing. not even a "service netif restart" does anything if anyone has any ideas why is that , would be appreciated Hi, I think it some new features they use in the USB data protocol which we don't support. Check the Linux code. Between does: usbconfig -d 0.6 reset recover the device? --HPS Hi, Search for axge on bugzilla: I suspect you are using this chipset: Try: usbconfig show_ifdrv To know for sure. Also see: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.freebsd.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D210488&data=05%7C01%7C%7Ce7f888b3635f4e898ca308da972fa69b%7C84df9e7fe9f640afb435%7C1%7C0%7C637988528164303655%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zvw7m8lJ%2FHocK%2FXJIDfdPv%2FArCpE5pk9lYz%2BY8WzMCc%3D&reserved=0 --HPS Hi Hans, actually the driver i use is not agxe (i thought it would be by the time i bought the usbcard) this is the module im using if_ure.ko and thank you , yes, reseting the usb entry with your command worked just fine. i got the internet back after doing this usbconfig -d 0.6 reset do we have a bug here then? thank you --tzk oh, i forgot to mention that the ure driver freezes not during the download test but in the middle of the upload, always dont know if that helps thanks --tzk Hi Ivan, Yes, there seems to be problem there. I need to look at the driver. Maybe it is simply sending too much data, than the device can handle! --HPS
Re: TP-LINK USB no carrier after speed test
On 9/15/22 17:18, Hans Petter Selasky wrote: On 9/15/22 17:16, Ivan Quitschal wrote: Hi All Does anybody have any idea what could be happening here?. I have a laptop DELL INSPIRON 3511 and everything works just fine, literally everything. even the iwlwifi0. But in order to use my full 600mbps, i dont use the wireless but a TP-LINK USB ethernet connected on "ue0" ugen0.6: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (200mA) but something really strange is happening .. everytime i open the chromium e do a speedtest (could be speedtest.net or any other) , at the end of the test the eth interface dies .. it changes from full-duplex to half-duplex/no carrier and the only way to get the internet back thru ue0 is by rebooting the whole thing. not even a "service netif restart" does anything if anyone has any ideas why is that , would be appreciated Hi, I think it some new features they use in the USB data protocol which we don't support. Check the Linux code. Between does: usbconfig -d 0.6 reset recover the device? --HPS Hi, Search for axge on bugzilla: I suspect you are using this chipset: Try: usbconfig show_ifdrv To know for sure. Also see: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210488 --HPS
Re: TP-LINK USB no carrier after speed test
On 9/15/22 17:16, Ivan Quitschal wrote: Hi All Does anybody have any idea what could be happening here?. I have a laptop DELL INSPIRON 3511 and everything works just fine, literally everything. even the iwlwifi0. But in order to use my full 600mbps, i dont use the wireless but a TP-LINK USB ethernet connected on "ue0" ugen0.6: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (200mA) but something really strange is happening .. everytime i open the chromium e do a speedtest (could be speedtest.net or any other) , at the end of the test the eth interface dies .. it changes from full-duplex to half-duplex/no carrier and the only way to get the internet back thru ue0 is by rebooting the whole thing. not even a "service netif restart" does anything if anyone has any ideas why is that , would be appreciated Hi, I think it some new features they use in the USB data protocol which we don't support. Check the Linux code. Between does: usbconfig -d 0.6 reset recover the device? --HPS
Re: [RFC] Proposal adding new sorting algorithm, bsort() to libc
On 9/8/22 12:50, Hans Petter Selasky wrote: See: https://reviews.freebsd.org/D36493 Looking through base I see qsort() being used in places it shouldn't be used. For example in fts_open(). If for example you fill a directory with 64k simply numerical file names in the wrong order and ask fts_open() to sort these ascending for example, qsort() will end stuck for a long-long time. So either switch to mergesort, or if malloc() is unacceptable, use something like bsort() which I've implemented in the above review as a drop-in replacement for qsort(). The advantage with bsort() is that in can be CPU accelerated, due to fixed comparison patterns. Quick sort is not always a quick sorting algorithm. Quick means simple, and not clever this time. For the qsort's bad pattern, sorting 4096 entries 1024 times in a row took: qsort: 15 seconds bsort: 230 milliseconds (non-CPU accelerated) mergesort: 30 milliseconds The problem with qsort() is that as the array size grows, the time consumption just gets worse and worse for the bad-patterns. Sorry there is no nice and fancy paper yet about this. --HPS Hi, Also see the "kill_ls.c" test program I attached to D36493, which shows the direct affect of qsort() on the regular "ls" command! --HPS
[RFC] Proposal adding new sorting algorithm, bsort() to libc
See: https://reviews.freebsd.org/D36493 Looking through base I see qsort() being used in places it shouldn't be used. For example in fts_open(). If for example you fill a directory with 64k simply numerical file names in the wrong order and ask fts_open() to sort these ascending for example, qsort() will end stuck for a long-long time. So either switch to mergesort, or if malloc() is unacceptable, use something like bsort() which I've implemented in the above review as a drop-in replacement for qsort(). The advantage with bsort() is that in can be CPU accelerated, due to fixed comparison patterns. Quick sort is not always a quick sorting algorithm. Quick means simple, and not clever this time. For the qsort's bad pattern, sorting 4096 entries 1024 times in a row took: qsort: 15 seconds bsort: 230 milliseconds (non-CPU accelerated) mergesort: 30 milliseconds The problem with qsort() is that as the array size grows, the time consumption just gets worse and worse for the bad-patterns. Sorry there is no nice and fancy paper yet about this. --HPS
Re: vt newcons 3 clicks mouse paste issue FIXED
Hi Ivan, Can you upload your patch to differential revision at freebsd.org ? https://reviews.freebsd.org/differential/ Then maybe someone else or me can approve and commit it! --HPS
Re: Accessibility in the FreeBSD installer and console
Hi, There are three work in progress patches pending: 1) Updates for kernel https://reviews.freebsd.org/D35754 2) Updates for beep https://reviews.freebsd.org/D35772 3) New vtspeakd daemon https://reviews.freebsd.org/D35776 Please test if you can! Feedback is welcome. --HPS
Re: Accessibility in the FreeBSD installer and console
Hi Klaus and Michael, I've tried to make some graphical QT v6.x cross platform so-called accessible applications. It is really hard to get it right. If you use one QT widget, everything is read perfectly in MacOS and if you use another QT widget, or a custom one, it is just not working. Or if you have a text editor you need to make sure you can tab out of it. Then a friend of mine said he started to use mac-ports and asked if I can port my applications from AppStore to there, because it is so much easier for him to use --- sigh, why could he not just re-install his Mac M1 with FreeBSD. pkg has just about everything he needs! Only that he needs to learn a few things the FreeBSD way. FreeBSD could beep all sound cards from 0 to 9 during single user mode for example, to indicate something is wrong. Some kind of espeak daemon could also be started from single user-mode. FreeBSD could technically support USB audio from the USB loader. We do have a USB stack which can be built as a single-threaded blob into the loader, but probably using the bell character via the BIOS is simpler. Many times when I see people use FreeBSD it is through Windows or MacOS. There is nothing wrong about that. I personally however prefer Windows through FreeBSD. Now if you would listen to me for a bit you will get why FreeBSD may be your only bet. Both Apple and Microsoft are totally tied up companies. I claim they can't do anything about computer programs that violates copyright law. You will be completely banned from their stores. But who would need to break "the law" to do something which most other people can do by not breaking the law? I've personally had a dream about being able to play the piano, but my brain simply won't do it. So I made a computer program to fill the gaps. The problem is that many so-called TAB sites are full of "stupid" copyright protections, obfuscating all the simple plain-text everyone else can see with their plain eyes, I just need it for my program, with tons JavaScript parsing, to make the text non-machine readable: Go here first and look at the CPU-usage and HTML source: https://www.ultimate-guitar.com/ Then go here and compare: https://nortabs.net And nobody wants to use a program that can only play a 100 Norwegian songs, when UG has 1.4 million multi-national songs available, in exactly right format I need. You will find people tried to talk to UG, but with no success. Is it legal to download movies using the Pirate bay if you are blind? Say you want all sub-titles on a braille device and need machine-readable subtitles? What if you have some kind of other disability and really need machine-readable formats to do your job? It's like being allowed to remove the copyright protection from that PDF, because you are not blind or deaf, but something else, which in the future will be mitigated by a machine. The only option for Apple, Google and Microsoft products, is so-called jail-breaking and cracks, which often gets your device infected by viruses. Apple says that all browsers on iOS must use the WebKit layout engine. That is so clever and I see another reason why. They don't want anyone to have access to machine readable formats, because then someone could remove all the ADs or someone could clone all the TABs on UG or blah blah blah. What prevents you from feeding audio of an e-book back into Google translate and selling the resulting text? What prevents you from OCR-ing ultimate-guitar? It's getting late here now and I think I've shared enough thoughts for today. Hope you find something meaningful in what I've written. --HPS
Re: Accessibility in the FreeBSD installer and console
On 7/8/22 14:34, David Chisnall wrote: On 08/07/2022 13:18, Stefan Esser wrote: Am 08.07.22 um 12:53 schrieb Hans Petter Selasky: Hi, Here is the complete patch for Voice-Over in the FreeBSD console: https://reviews.freebsd.org/D35754 You need to install espeak from pkg and then install the /etc/devd/accessibility.conf file and then run sysctl kern.vt.accessibility.enable=1 after booting the new kernel. It is freaking awesome! There might be some bugs, but it worked fine for me! The espeak port is marked for deletion on 2022-06-30 (but has not been deleted, yet): DEPRECATED= Last release in 2014 and deprecated upstream EXPIRATION_DATE=2022-06-30 There is espeak-ng, which took over the sources, and I have prepared a port update. Many years ago, I added the speech synthesis APIs from OS X to GNUstep using flite: https://www.freshports.org/audio/flite/ flite it small (the port contains separate .so and .a files for each voice, a minimal version needs only one), has no dependencies outside of the base system, and is permissively licensed. I haven't used it for a while (apparently it's had a new major release since I last did), but I was happily using it for text-to-speech on FreeBSD 10-15 years ago and it is still in ports. David Hi, I've updated my patch a little bit, so please re-fetch it. I tried: action "echo -- $text | rtprio 8 /usr/local/bin/flite_cmu_us_slt" And it doesn't sound as good as espeak :-( Do we have more of these in ports which are know to be good? --HPS
Re: FreeBSD is a great operating system!
On 7/8/22 05:40, Turritopsis Dohrnii Teo En Ming wrote: Dear Hans Petter Selasky, Why do you say FreeBSD license is a killer? Because you can do anything you want with the operating system :-) --HPS
Re: Accessibility in the FreeBSD installer and console
Hi, Here is the complete patch for Voice-Over in the FreeBSD console: https://reviews.freebsd.org/D35754 You need to install espeak from pkg and then install the /etc/devd/accessibility.conf file and then run sysctl kern.vt.accessibility.enable=1 after booting the new kernel. It is freaking awesome! There might be some bugs, but it worked fine for me! --HPS
Re: Accessibility in the FreeBSD installer and console
On 7/7/22 23:26, John Kennedy wrote: On Thu, Jul 07, 2022 at 10:11:52PM +0200, Klaus Küchemann wrote: Am 07.07.2022 um 19:32 schrieb Hans Petter Selasky : The only argument I've heard from some non-sighted friends about not using FreeBSD natively is that ooh, MacOSX is so cool. It starts speaking from the start if I press this and this key. Is anyone here working on or wanting such a feature? Possibly they didn’t want to be rude and your friends didn't tell you the other argument :-) : according to the corresponding wiki page FreeBSD doesn't natively support any audio output at all on your friends current M1 Mac hardware. since quite nothing is currently supported you probably will first take over working on the Audio driver …..and of course USB :-) I think a huge benefit that Apple would have is that they might be able to guarantee some sort of audio speaker, period, since they control the hardware that the software runs on. That might be a big ask on FreeBSD, but maybe if there was some relatively ubiqitous Hi, Does Apple support voice-over in its bootloaders too? I think not, so at some point of technical breakage you will be stuck anyway - right? --HPS
Accessibility in the FreeBSD installer and console
Hi, The only argument I've heard from some non-sighted friends about not using FreeBSD natively is that ooh, MacOSX is so cool. It starts speaking from the start if I press this and this key. Is anyone here working on or wanting such a feature? I mean it should be so much easier to text to speech our text based unicode console, than what MacOSX is doing, by tracking screen changes intelligently inside newcons in the kernel, and feeding that into a character device, that to espeak or whatever can read it. --HPS
Re: FreeBSD is a great operating system!
On 7/6/22 10:07, Turritopsis Dohrnii Teo En Ming wrote: Subject: FreeBSD is a great operating system! Good day from Singapore, I think FreeBSD is a great operating system! I support FreeBSD because the most popular pfSense firewall, the extremely popular OPNsense firewall and the BSD Router Project are all powered by FreeBSD! macOS is also based on FreeBSD! I use pfSense community edition firewall in my home. I am planning to try out OPNsense firewall next. I will continue to support FreeBSD! It is a great operating system! FreeBSD is a very good network operating system. Regards, Mr. Turritopsis Dohrnii Teo En Ming Targeted Individual in Singapore 6 July 2022 Wed Blogs: https://tdtemcerts.blogspot.com https://tdtemcerts.wordpress.com ... And its license is a killer! --HPS
Re: iichid/hms keyboard/mouse wrongly reattached to uhid/ums
On 6/27/22 17:19, Ivan Quitschal wrote: Hi all Not sure if I found a problem here but here we go. Since I have a KVM usb switch here for keyboard/mouse sometimes I toggle it between my windows and freebsd. I am using iichid here to have my multimedia keys working on keyboard and all hw.usb.usbhid.enable="1" Im also using Wulf's moused https://github.com/wulf7/moused so far so good. Problem is: when I switch to windows , everything is detached correctly (hms, hkbd etc), but when I switch back, sometimes the keyboard and mouse are wrongly attached to "ums" device , not hms. (sometimes it goes to the correct one). Shouldn't ums/uhid modules be deactivated once hw.usb.usbhid.enable is set to 1 ? The workaround I did here was to manually kldunload both uhid.ko and ums.ko within rc.local during boot. This way I can detache attach the kbd/mouse back as much as I want and it always end up in hms/hkbd devices Is this how its supposed to function? Randomly choosing between ums or hms? Hi, Can you dump "kldstat" at the different times? I guess it may be just be that the wrong module is loaded first, so it grabs the device, because there are no other drivers loaded, even though ums is a generic driver. Try loading all relevant drivers in /boot/loader.conf . Then the attach order shouldn't matter. --HPS
Re: vt newcons mouse paste issue FIXED
On 6/24/22 18:51, Tomoaki AOKI wrote: On Fri, 24 Jun 2022 17:29:26 +0200 Hans Petter Selasky wrote: Hi Tomoaki, Please retest: https://reviews.freebsd.org/D35552 Pushing this after some local tests. --HPS
Re: vt newcons mouse paste issue FIXED
Hi Tomoaki, On 6/24/22 16:48, Hans Petter Selasky wrote: IDEOGRAPHIC (Full-width) SPACE According to this page: https://jkorpela.fi/chars/spaces.html There are multiple uni-code characters which are spaces. Should we support them all? --HPS
Re: vt newcons mouse paste issue FIXED
On 6/24/22 16:02, Tomoaki AOKI wrote: On Thu, 23 Jun 2022 21:41:38 +0200 Hans Petter Selasky wrote: Hi, https://reviews.freebsd.org/D35552 Updated! Please test! --HPS As I've commented on Phabricator, works perfect except one CJK-related mis-behaviour. IDEOGRAPHIC (Full-width) SPACE (E38080, U+3000) seems to be treated as regular character, not as space. Possibly, any other space characters in code points other than CJK could have problem, but not at all tested. Sorry. Anyway, thanks in great advance! Hi Tomoaki, Should IDEOGRAPHIC (Full-width) SPACE (E38080, U+3000) also be checked when selection single words? --HPS
Re: vt newcons mouse paste issue FIXED
Hi, https://reviews.freebsd.org/D35552 Updated! Please test! --HPS
Re: RES: RES: RES: RES: vt newcons mouse paste issue FIXED
On 6/23/22 21:32, Ivan Quitschal wrote:
Hi,
Please test this latest version:
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Freviews.freebsd.org%2FD35552&data=05%7C01%7C%7C8a105d5de0164d4b2eac08da554bfeb2%7C84df9e7fe9f640afb435%7C1%7C0%7C637916082154929613%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=0qxyXDZSJ3lElK7HGgK200mwrV3%2Bn%2Ftj5%2B5VbxFLxOA%3D&reserved=0
--HPS
Hi Hans
The version before worked just fine. I will test this one and let you know
But I have a suggestion to make:
Today the trim is being done on every line , even on the last one . for
example, if you mark the mouse:
|from here|to here
| |
"Blablabla"(you can see there are 10 spaces )
_
It will only copy the Blablabla (im talking about the *last* line only, or when
it's just one line)
What if you do something like this?
Moving this part of code into the "non last line block"
/* Add new line for all rows, but not for last one. */
if (r != e.tp_row)
{
/* Trim trailing whitespace from each line, if any. */
for (; i != j; i--) {
if (TCHAR_CHARACTER(buf[i - 1]) == ' ')
buf[i - 1] = '\0';
else
break;
}
buf[i++] = '\r';
}
This way you would trim all the lines but the last one.
Just an idea , what do you think?
Sounds reasonable. Let me update the patch.
--HPS
Re: RES: RES: RES: vt newcons mouse paste issue FIXED
Hi, Please test this latest version: https://reviews.freebsd.org/D35552 --HPS
Re: RES: RES: vt newcons mouse paste issue FIXED
On 6/22/22 18:48, Tomoaki AOKI wrote: Hi. Not actually tested, but this can cause breakage on non-ascii cases. Maybe also (or instead) iswspace() test would be needed. Possibly additional mbrtowc() in the argument of iswspace(). Please see `man 3 multibyte` and `man 3 iswspace`. (Possibly more to see.) Characters in buf can be multibyte or wide char depending on locale, as vt can show at least UTF-8 characters. Sorry, not looked into enough how UTF-8 characters outside ascii are handled internally on vt. Thanks for your feedback. Now using the TCHAR_CHARACTER() macro, which is already used for space separation. See: https://reviews.freebsd.org/D35552 --HPS
Re: RES: RES: vt newcons mouse paste issue FIXED
On 6/22/22 18:41, Hans Petter Selasky wrote: Hi, I needed to update the patch a bit. Can you test this: https://reviews.freebsd.org/D35552 Use the download raw patch link in there to get the patch. Thank you! --HPS One more update. --HPS
Re: RES: RES: vt newcons mouse paste issue FIXED
Hi, I needed to update the patch a bit. Can you test this: https://reviews.freebsd.org/D35552 Use the download raw patch link in there to get the patch. Thank you! --HPS
Re: RES: vt newcons mouse paste issue FIXED
On 6/22/22 15:36, Ivan Quitschal wrote:
Hi Hans
Hi Ivan,
I think you should upload the diff at:
https://reviews.freebsd.org/differential/
Make the diff like this:
diff -u -C 99 sys/dev/vt/vt_buf.c.orig sys/dev/vt/vt_buf.c > a.diff
I see two issues:
1) Pointer arithmetics is not so good!
}
+ end = buf + i - 1;
+ while (end > buf && isspace((unsigned char)*end))
+ {
+ *end = '\0';
+ end--;
+ }
+
I think this would be better and avoid the ">" with pointers!
for (end = buf + i; end-- != buf; ) {
if (isspace((unsigned char)*end) == false)
break;
*end = '\0';
}
Can you explain this:
- buf[i++] = '\r';
+ buf[i] = '\r';
buf[i++] = '\n';
'\r' character is now overwritten by '\n' character.
--HPS
Re: vt newcons mouse paste issue FIXED
On 6/22/22 14:53, Ivan Quitschal wrote: Hi All About this anoying paste error we still have in vt console, I looked it up and couldnt find any fix regarding this, so i did it. Please find attached the fixed version of /usr/src/sys/dev/vt/vt_buf.c with trim spaces and aligned to the console size. I've tested with other fonts and looks fine in here. I hope this can help other ppl which finds this terminal mouse paste issue a pain in the neck. thanks --tzk Can you provide the diff against the old, unmodified file? --HPS
Re: A kernel crash after compiling a fresh kernel
Hi,
Does this patch fix your issue?
--HPScommit cc7a224fa956372cc5c5b4d29aa6906d79bd9f26
Author: Hans Petter Selasky
Date: Wed Jun 8 08:49:55 2022 +0200
tcp: Skip sackhole KASSERTS() on NULL
Inadvertedly introduced NULL pointer dereference during
sackhole sanity check in D35387.
No functional change intended.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D35423
Sponsored by: NVIDIA Networking
diff --git a/sys/netinet/tcp_sack.c b/sys/netinet/tcp_sack.c
index 273d56c510e2..4ecc0e045118 100644
--- a/sys/netinet/tcp_sack.c
+++ b/sys/netinet/tcp_sack.c
@@ -963,9 +963,10 @@ tcp_sack_output(struct tcpcb *tp, int *sack_bytes_rexmt)
while ((hole = TAILQ_NEXT(hole, scblink)) != NULL) {
if (SEQ_LT(hole->rxmit, hole->end)) {
tp->sackhint.nexthole = hole;
- break;
+ goto out;
}
}
+ return (hole);
out:
KASSERT(SEQ_LT(hole->start, hole->end), ("%s: hole.start >= hole.end", __func__));
KASSERT(SEQ_LT(hole->start, tp->snd_fack), ("%s: hole.start >= snd.fack", __func__));
Re: commit 99902b1 causes kernel panics
On 6/4/22 23:21, Michael Butler wrote: On a Dell E6430 laptop with an i5-3340M CPU on-board but no additional video adapter, this commit causes a panic when i915kms is loaded :-( This adapter does not use any additional firmware. Reverting only this change allows me to run way past it - up to commit 00b0158d2ca, so far. https://reviews.freebsd.org/D35403 --HPS
Re: Testing 14-CURRENT-f44280bf5fb on aarch64
On 5/10/22 09:37, Daniel Morante wrote: Updated to the latest (14.0-CURRENT #2 main-n255521-10f44229dcd: Tue May 10 02:52:27 EDT 2022) and removed the sysctl option (hw.usb.disable_enumeration=1). Still seeing the problem. The below just endlessly prints out on the console: ``` FreeBSD/arm64 (mars.morante.com) (ttyu0) login: ugen0.2: at usbus0 (disconnected) uhub4: at uhub0, port 1, addr 1 (disconnected) uhub4: detached ugen0.2: at usbus0 uhub4 numa-domain 0 on uhub0 uhub4: on usbus0 uhub4: 4 ports with 4 removable, self powered ugen0.2: at usbus0 (disconnected) uhub4: at uhub0, port 1, addr 1 (disconnected) uhub4: detached ugen0.2: at usbus0 uhub4 numa-domain 0 on uhub0 uhub4: on usbus0 uhub4: 4 ports with 4 removable, self powered ugen0.2: at usbus0 (disconnected) uhub4: at uhub0, port 1, addr 1 (disconnected) uhub4: detached ugen0.2: at usbus0 uhub4 numa-domain 0 on uhub0 uhub4: on usbus0 uhub_attach: port 1 power on or off failed, USB_ERR_IOERROR uhub_attach: port 2 power on or off failed, USB_ERR_IOERROR uhub_attach: port 3 power on or off failed, USB_ERR_IOERROR uhub_attach: port 4 power on or off failed, USB_ERR_IOERROR uhub4: 4 ports with 4 removable, self powered uhub_reattach_port: device problem (USB_ERR_IOERROR), disabling port 1 uhub_reattach_port: device problem (USB_ERR_IOERROR), disabling port 2 uhub_reattach_port: device problem (USB_ERR_IOERROR), disabling port 3 uhub_reattach_port: device problem (USB_ERR_IOERROR), disabling port 4 ugen0.2: at usbus0 (disconnected) uhub4: at uhub0, port 1, addr 1 (disconnected) uhub4: detached ugen0.2: at usbus0 uhub4 numa-domain 0 on uhub0 uhub4: on usbus0 uhub4: 4 ports with 4 removable, self powered ugen0.2: at usbus0 (disconnected) uhub4: at uhub0, port 1, addr 1 (disconnected) uhub4: detached ugen0.2: at usbus0 uhub4 numa-domain 0 on uhub0 uhub4: on usbus0 uhub4: 4 ports with 4 removable, self powered ugen0.2: at usbus0 (disconnected) uhub4: at uhub0, port 1, addr 1 (disconnected) uhub4: detached ugen0.2: at usbus0 uhub4 numa-domain 0 on uhub0 uhub4: on usbus0 uhub4: 4 ports with 4 removable, self powered ugen0.2: at usbus0 (disconnected) uhub4: at uhub0, port 1, addr 1 (disconnected) uhub4: detached ugen0.2: at usbus0 uhub4 numa-domain 0 on uhub0 uhub4: on usbus0 uhub4: 4 ports with 4 removable, self powered ugen0.2: at usbus0 (disconnected) uhub4: at uhub0, port 1, addr 1 (disconnected) uhub4: detached ugen0.2: at usbus0 uhub4 numa-domain 0 on uhub0 uhub4: on usbus0 uhub4: 4 ports with 4 removable, self powered ugen0.2: at usbus0 (disconnected) uhub4: at uhub0, port 1, addr 1 (disconnected) uhub4: detached ugen0.2: at usbus0 uhub4 numa-domain 0 on uhub0 uhub4: on usbus0 uhub4: 4 ports with 4 removable, self powered ugen0.2: at usbus0 (disconnected) uhub4: at uhub0, port 1, addr 1 (disconnected) uhub4: detached ugen0.2: at usbus0 uhub4 numa-domain 0 on uhub0 uhub4: on usbus0 uhub4: 4 ports with 4 removable, self powered ugen0.2: at usbus0 (disconnected) uhub4: at uhub0, port 1, addr 1 (disconnected) uhub4: detached ugen0.2: at usbus0 uhub4 numa-domain 0 on uhub0 uhub4: on usbus0 uhub4: 4 ports with 4 removable, self powered ``` Hi, Does it help to do a "usbconfig -d X.Y reset" of the parent USB HUB of the failing one, I guess this is ugen0.1 . --HPS
Re: Testing 14-CURRENT-f44280bf5fb on aarch64
On 5/4/22 09:49, Daniel Morante wrote: I'm still using the sysctl option "hw.usb.disable_enumeration=1" to prevent the USB devices from disconnecting/reconnecting every few seconds. Other than that the improvement in stability with 14-CURRENT on aarach64 on this hardware is much better since the last time I tried, back in late February 2022. Hi Daniel, Could you try the very latest 14-current as of now? I've made a couple of USB fixes which may fix the issue you are seeing. --HPS
Re: What are the in-kernel functions to format time?
On 3/11/22 12:20, Gary Jennejohn wrote: Do you mean the %zd? kvprintf() checks for a zflag and handles the argument as size_t or ssize_t, depending on whether the sign is positive or negative. Hi, Given that time is a 64-bit value, then probably "%llu", and (unsigned long long)bintime would do it, but then you need that cast. ./_types.h:typedef __int64_t __sbintime_t; I was tinking of a %XXX that divides the value somehow into something more readable, maybe suffixing "ns" or "ms" or "us" or something. --HPS
Re: What are the in-kernel functions to format time?
On 3/11/22 10:49, Alexander Leidinger wrote: Hi, I'm looking for a function to convert bintime to a human readable format in the kernel... and what is the usual format we use? The use case for this is: if something throws a log from the kernel about a signal, I want to know when it happened, or in terms of code see below (tabs are most probably messed up). Do we have some kind of policy in terms of kernel messages and timestamps? Like "do not commit logging with timestamps"? I have the code below because I needed it at least once and think something like this (in a human readably shape) would be beneficial to have in the tree. Hi, I think our kernel printer doesn't support this: sys/kern/subr_prf.c If you need to extend the format, please check other OS'es too, like OpenBSD, NetBSD and Linux, what they support, so there won't be any obvious conflicts when moving code cross platforms! --HPS
Re: New panic in main-n253273-a52d8d4a6c6:
On 2/22/22 00:42, Michael Jung wrote:
Hi:
I was trying to remember what I did that was odd when this crash occurred then
it
hit me. You can repeat this panic by doing:
# watch -I -W pts/0
Here is another panic that happened write after issuing "watch" for comparison.
http://mail.mikej.com/core.txt.1
http://mail.mikej.com/info.1
http://mail.mikej.com/vmcore.1
I also need your kernel and debug kernel to fully debug this.
1) Do ssh to machine.
2) watch -i -W pts/0 (does not panic over here)
Can you explain what step 1 is? An scp ?
Refcount is -1.
f_count = 0x
f_data = 0xf800158b0400
In your KGDB, can you enter:
info 0x81b052d0
Does the attached patch make any difference?
--HPSdiff --git a/sys/dev/snp/snp.c b/sys/dev/snp/snp.c
index 64e2d0f6453..6eec4a5a632 100644
--- a/sys/dev/snp/snp.c
+++ b/sys/dev/snp/snp.c
@@ -86,6 +86,7 @@ static d_poll_t snp_poll;
static struct cdevsw snp_cdevsw = {
.d_version = D_VERSION,
+ .d_flags = D_TRACKCLOSE,
.d_open = snp_open,
.d_read = snp_read,
.d_write = snp_write,
Re: New panic in main-n253273-a52d8d4a6c6:
On 2/21/22 14:07, Michael Jung wrote:
(kgdb) fram 16
#16 0x80bad587 in closefp_impl (fdp=0xfe012b7c0430, fd=4,
fp=0xf801cc119280, td=0xfe00df8d0560, audit=true) at
/usr/src/sys/kern/kern_descrip.c:1300
1300error = closef(fp, td);
(kgdb) print /x *fdp
$1 = {fd_files = 0xfe00df6d9000, fd_map = 0xf80001bb1800, fd_freefile =
0x4, fd_refcnt = 0x1, fd_holdcnt = 0x1, fd_sx = {lock_object = {lo_name =
0x8124f6a9, lo_flags = 0x233, lo_data = 0x0,
lo_witness = 0xf8041eb94000}, sx_lock = 0x1}, fd_kqlist = {tqh_first
= 0x0, tqh_last = 0x0}, fd_holdleaderscount = 0x0, fd_holdleaderswakeup = 0x0}
(kgdb)
Can you also:
print /x *fp
in the same frame?
--HPS
Re: New panic in main-n253273-a52d8d4a6c6:
On 2/20/22 21:53, Michael Jung wrote: Hi! The box was quite busy at the time. The only odd thing I am aware of and which I do not think is related is I have not been able to expand one of my zpool's. ZFS sees my added draid2:2d:10c:0s vdev but I can't seem to force zpool's expansion - my bet this is somehow related to the mirrored special device in the pool even though autoexpand is set to 'on' for the pool. Not asking anyone to solve this, I plan on putting together a "how to reproduce" and post to freebsd-fs@ but wanted to note this oddity. --mikej This is a unmodified GENERIC kernel. Unread portion of the kernel message buffer: panic: refcount 0xf801cc119284 wraparound cpuid = 7 time = 1645382575 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0119a83c80 vpanic() at vpanic+0x17f/frame 0xfe0119a83cd0 panic() at panic+0x43/frame 0xfe0119a83d30 fdclose() at fdclose/frame 0xfe0119a83dc0 closefp_impl() at closefp_impl+0x77/frame 0xfe0119a83e00 amd64_syscall() at amd64_syscall+0x12e/frame 0xfe0119a83f30 fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe0119a83f30 --- syscall (6, FreeBSD ELF64, sys_close), rip = 0x3309a531b62a, rsp = 0x3309a2802bc8, rbp = 0x3309a2803000 --- KDB: enter: panic This may be a refcount leak. Are you able to dump "fdp" at: #16 0x80bad587 in closefp_impl (fdp=0xfe012b7c0430, fd=4, fp=0xf801cc119280, td=0xfe00df8d0560, audit=true) at /usr/src/sys/kern/kern_descrip.c:1300 frame 16 print /x *fdp --HPS
pxeboot binary is too big on FreeBSD (>640KBytes)
FYI: After a lot of digging trying everything, I found that the pxeboot and loader.efi was too big simply due to ZFS support. So I did this after buildworld: cd /usr/src/stand make WITHOUT_LOADER_ZFS=YES clean make WITHOUT_LOADER_ZFS=YES all make WITHOUT_LOADER_ZFS=YES install And now it works, with my old GigaByte mainboard! Why should pxeboot have ZFS support? https://forums.freebsd.org/threads/problem-with-isc-dhcpd-and-diskless-booting.82199/ --HPS
Re: Patch for patch, but not foreach :-)
On 5/10/21 15:57, Hans Petter Selasky wrote: On 5/7/21 11:58 PM, Chris wrote: On 2021-05-07 14:10, Michael Gmelin wrote: What about using "."? Or "/" (which would match the muscle memory of "search" in less/more/vi/some browsers)? +1 I really like that idea. Hi, Thank you for all the good feedback! Based on the input I've got, the differential revision has now been updated: https://reviews.freebsd.org/D30160 Still looking for feedback on this? Anyone tried it? --HPS
Re: USB CD Eject Failures
On 2/17/22 03:31, Sean Bruno wrote: Been playing around with sysutils/eject to automate some media backup stuff. I note that "after a number of ejects" the USB 2 CD drive will cease responding. I don't think its a race to failure, it acts like resource starvation/leak. Seems fairly reproducible, if someone gets to it before I do, let me know. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261961 I suspect that something has changed in the 12 years since sysutils/eject was last looked at and the CDIOCEJECT case in sys/cam/scsi_cd.c probably needs an eyeball. The close tray command also seems nonfunctional, which probably means that a data structure has changed or something else that I haven't started at in quite some time. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261936 Hi, You can trace all USB SCSI commands with "usbdump". --HPS
Re: observations on Ryzen 5xxx (Zen 3) processors
On 12/22/21 13:42, Andriy Gapon wrote: There have been some reports on strange / unexpected things with Ryzen 5xxx processors. I think I have seen 5950X, 5900X and 5800X mentioned, not sure about others. Since I have 5800X myself I looked into a couple of issues that have straightforward demonstrators. I would like to share my findings and observations on those issues. Issue 1. High wake-up latency for CPU idle states. This seems to be related to the so called CC6 idle state. The official information on it is very sparse. The state is not explicitly exposed to the OS, at least, though ACPI interfaces that FreeBSD currently supports. In my tests I see that if all logical processors enter an idle state then an external interrupt can be delayed by 500+ us. Specifically, I observed this with an MSI-X interrupt from a discrete network chip. Interrupts from internal components seem to be affected as well, but to a lesser degree. The deep state in question can be entered regardless of whether C2 (via I/O) is enabled, C1 (via hlt) is sufficient. In fact, with machdep.idle=hlt it works the same. The state is not entered if at least one logical CPU is not idle. The state is not entered if machdep.idle=mwait is used. Apparently, the processors do not attempt to automatically enter as deep idle modes with mwait as they do with hlt. Finally, the state is not entered if zenstates.py utility is used to disable C6 / CC6 state via an undocumented (publicly) MSR. For me personally that state does not cause any annoyances but anyone who experiences problems related to "stuttering", "jitter", latency might want to look into this. Issue 2. Uneven performance of CPU intensive tasks, especially with SCHED_ULE, when SMT is enabled. I found out that at least on my hardware all even numbered logical CPUs can perform much better than odd numbered logical CPUs. It seems that hardware threads within a core are not equal. Maybe this is related to ability to use boosted frequencies, but maybe something else, I am not sure. From a brief look at the ULE code it looks that the selection of a hw thread within a core is intentionally random when all other things are equal. I suspect that the hardware + firmware may actually describe that performance disparity via ACPI CPPC (_CPC object, etc), but right now we do not support querying that or making use of it. It would interesting to see if other owners of similar processors can confirm or provide counter-examples to my observations. Simple tests for issue 1: - ping a host attached to the same switch (so, with very low expected latency) - ping 127.0.0.1 For issue 2: take some CPU intensive single-threaded task and bind it (with cpuset -l) to different logical CPUs. Multiple such tasks can be run concurrently on different logical CPUs. References: - https://forums.freebsd.org/threads/variable-ping-latency-on-ryzen-setup.82791/ - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256594 - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254040 - https://github.com/r4m0n/ZenStates-Linux - https://github.com/meowthink/ZenStates-FreeBSD -- has a bug - https://github.com/avg-I/ZenStates-FreeBSD -- has a fix - https://www.kernel.org/doc/html/latest/admin-guide/acpi/cppc_sysfs.html - https://static.linaro.org/connect/lvc21/presentations/lvc21-219.pdf - https://uefi.org/specs/ACPI/6.4/14_Platform_Communications_Channel/Platform_Comm_Channel.html Hi, I've seen exactly the same thing. See older FreeBSD-current thread: "AMD Ryzen 5 3400G with Radeon Vega Graphics" I just put: machdep.idle=spin In /boot/loader.conf for now. --HPS
Re: On amd64 main-n251456-22c4ab6cb015-dirty (Dec.-7): /boot/kernel/ng_ubt.ko is getting "symbol sysctl___net_bluetooth undefined"
On 12/15/21 23:58, Mark Millard via freebsd-current wrote: Back when I upgraded the ThreadRipper 1950X amd64 system to (line split for readability): # uname -apKU FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #25 main-n251456-22c4ab6cb015-dirty: Tue Dec 7 19:38:53 PST 2021 root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400043 1400043 I started getting notices like: Dec 7 18:38:57 amd64_ZFS kernel: link_elf_obj: symbol sysctl___net_bluetooth undefined Dec 7 18:38:57 amd64_ZFS kernel: linker_load_file: /boot/kernel/ng_ubt.ko - unsupported file type (Not that I use the bluetooth on the system.) Is this expected for a kernel of that vintage? For reference: # more /usr/main-src/sys/amd64/conf/GENERIC-NODBG # # GENERIC -- Custom configuration for the amd64/amd64 # include "GENERIC" ident GENERIC-NODBG makeoptions DEBUG=-g# Build kernel with gdb(1) debug symbols makeoptions WITH_CTF=1 # Run ctfconvert(1) for DTrace support options NUMA options MAXMEMDOM=2 #optionsALT_BREAK_TO_DEBUGGER options KDB # Enable kernel debugger support # For minimum debugger support (stable branch) use: options KDB_TRACE # Print a stack trace for a panic options DDB # Enable the kernel debugger # Extra stuff: #optionsVERBOSE_SYSINIT=0 # Enable verbose sysinit messages #optionsBOOTVERBOSE=1 #optionsBOOTHOWTO=RB_VERBOSE #optionsKTR #optionsKTR_MASK=KTR_TRAP ##options KTR_CPUMASK=0xF #optionsKTR_VERBOSE #optionsACPI_DEBUG # Disable any extra checking for. . . nooptions DEADLKRES # Would enable the deadlock resolver nooptions INVARIANTS # Would enable calls of extra sanity checking nooptions INVARIANT_SUPPORT # Would enable extra sanity checks of internal structures, required by INVARIANTS nooptions WITNESS # Would enable checks to detect deadlocks and cycles nooptions WITNESS_SKIPSPIN# Would enable running witness on spinlocks for speed nooptions DIAGNOSTIC nooptions MALLOC_DEBUG_MAXZONES # Kernel Sanitizers nooptions COVERAGE# Would enable generic kernel coverage. Used by KCOV nooptions KCOV# Would enable Kernel Coverage Sanitizer # Warning: KUBSAN can result in a kernel too large for loader to load nooptions KUBSAN # Would enable Kernel Undefined Behavior Sanitizer device iwm device iwmfw sysctl___net_bluetooth seems to be from one or more of: # grep -r "net_bluetooth[^_]" /usr/main-src/sys/ | more /usr/main-src/sys/netgraph/bluetooth/common/ng_bluetooth.c:SYSCTL_INT(_net_bluetooth, OID_AUTO, version, /usr/main-src/sys/netgraph/bluetooth/common/ng_bluetooth.c:SYSCTL_NODE(_net_bluetooth, OID_AUTO, hci, CTLFLAG_RW | CTLFLAG_MPSAFE, 0, /usr/main-src/sys/netgraph/bluetooth/common/ng_bluetooth.c:SYSCTL_NODE(_net_bluetooth, OID_AUTO, l2cap, CTLFLAG_RW | CTLFLAG_MPSAFE, 0, /usr/main-src/sys/netgraph/bluetooth/common/ng_bluetooth.c:SYSCTL_NODE(_net_bluetooth, OID_AUTO, rfcomm, CTLFLAG_RW | CTLFLAG_MPSAFE, 0, /usr/main-src/sys/netgraph/bluetooth/common/ng_bluetooth.c:SYSCTL_NODE(_net_bluetooth, OID_AUTO, sco, CTLFLAG_RW | CTLFLAG_MPSAFE, 0, /usr/main-src/sys/netgraph/bluetooth/drivers/ubt/ng_ubt.c:SYSCTL_INT(_net_bluetooth, OID_AUTO, usb_isoc_enable, CTLFLAG_RWTUN | CTLFLAG_MPSAFE, /usr/main-src/sys/netgraph/bluetooth/include/ng_bluetooth.h:SYSCTL_DECL(_net_bluetooth); This issue was fixed: https://cgit.freebsd.org/src/commit/?id=8fa952937bbe44a0fdd17348adfbbfd44aef6004 --HPS
Re: What to do about tgammal?
On 12/4/21 19:53, Steve Kargl wrote: What to do about tgammal? A long time ago (2013-09-06), theraven@ committed a kludge that mapped several missing long double math functions to double math functions (e.g., tanhl(x) was mapped to tanh(x)). Over the next few years, I (along with bde and das reviews) provided Intel 80-bit (ld80) and IEEE 128-bit (ld128) implementations for some of these functions; namely, coshl(x), sinhl(x), tanhl(x), erfl(x), erfcl(x), and lgamma(x). The last remaining function is tgammal(x). If one links a program that uses tgammal(x) with libm, one sees /usr/local/bin/ld: fcn_list.o: in function `build_fcn_list': fcn_list.c:(.text+0x7c4): warning: tgammal has lower than advertised precision The warning is actually misleading. Not only does tgammal(x) have a *MUCH* lower precision, it has a reduced domain. That is, tgammal(x) produces +inf for x > 172 whereas tgammal(x) should produce a finite result for values of x up to 1755 (or so). On amd64-*-freebsd, testing 100 in the below intervals demonstrates pathetic accuracy. Current implmentation via imprecise.c Interval | Max ULP ---+ [6,171] | 1340542.2 [1.0662,6]|14293.3 [1.01e-17,1.0661] | 3116.1 [-1.,-1.0001] | 15330369.3 ---+ Well, I finally have gotten around to removing theraven@'s last kludge for FreeBSD on systems that support ld80. This is done with a straight forward modification of the msun/bsdsrc code. The limitation on domain is removed and the accuracy substantially improved. Interval | Max ULP ---+-- [6,1755] |8.457 [1.0662,6]| 11.710 [1.01e-17,1.0661] | 11.689 [-1.,-1.0001] | 11.871 ---+-- My modifications leverage the fact that tgamma(x) (ie., double function) uses extend arithmetic to do the computations (approximately 85 bits of precision). To get the Max ULP below 1 (the desired upper limit), a few minimax polynomials need to be determined and the mystery around a few magic numbers need to be unraveled. Extending what I have done to an ld128 implementation requires much more effort than I have time and energy to pursue. Someone with interest in floating point math on ld128 system can provide an implementation. So, is anyone interested in seeing a massive patch? Hi, Do you need a implementation of tgamma() which is 100% correct, or a so-called speed-hack version of tgamma() which is almost correct? I've looked a bit into libm in FreeBSD and I see some functions are implemented so that they execute quickly, instead of producing exact results. Is this true? --HPS
sys/conf: Simplify configuration files
Hi fellow kernel developers, I have two patches for config(8) which will allow us to group filenames in sys/conf/files* among others. Any strong opinions about the following change? https://reviews.freebsd.org/D33224 --HPS
Re: sound on FreeBSD 14.0-CURRENT
On 11/17/21 13:36, Ludovit Koren wrote: firefox plays via speakers In firefox go to "about:config", then add this string: media.cubeb.backend oss Then restart firefox. --HPS
Re: sound on FreeBSD 14.0-CURRENT
Hi Ludovit, It does not work automatically on the new notebook. I suppose pcm1, is the output for the jack headphones. I just tried without virtual_oss, with virtual_oss, starting with -f /dev/dsp0; /dev/dsp1; /dev/dsp2; /dev/dsp1.0; /dev/dsp2.0; then using virtual_oss_cmd using different devices and using virtual_oss_cmd as you mentioned in the email. Still no success... (and next I would like to run bluetooth headphones) Again, please show all the commands you try and the output from them. Else I cannot help you figure this out! Your setup should be like this: mixer -f /dev/mixer0 -s vol 100 mixer -f /dev/mixer0 -s pcm 100 mixer -f /dev/mixer1 -s vol 100 mixer -f /dev/mixer1 -s pcm 100 killall virtual_oss virtual_oss \ -B -S -Q 1 -C 2 -c 2 \ -T /dev/sndstat \ -r 48000 \ -b 24 \ -s 8.0ms \ -R /dev/dsp0 \ -P /dev/dsp0 \ -c 2 \ -d dsp \ -t vdsp.ctl # if you play something now, do you have sound in your regular speakers? virtual_oss_cmd /dev/vdsp.ctl -P /dev/dsp1 # if you play something now, do you have sound in your headphone jack? If the answer is "no" to the last question and "yes" to the first question, there may be some quirks needed for the sound card: Please read through: man snd_hda First and then try to search the FreeBSD forums for similar issues. --HPS
Re: sound on FreeBSD 14.0-CURRENT
Hi, Still the same result... Please show all commands you try! Can you explain, which if these devices you want to receive audio from, and which you want to transmit audio to: pcm0: (play/rec) default pcm1: (play) pcm2: (play) It might also be the mixer has the volume or recording level set to zero. --HPS
Re: sound on FreeBSD 14.0-CURRENT
On 11/16/21 20:59, Ludovit Koren wrote: Hans Petter Selasky writes: > Hi, >> It is not working... >> Just a thought... Could not be the problem how are the apps built >> (chromium, firefox), i.e. which options are set on? > No, the default should work out of the box. > What does "which virtual_oss_cmd" output? which virtual_oss_cmd /usr/local/sbin/virtual_oss_cmd > Maybe /usr/local/bin is not in your PATH? env SHELL=/usr/local/bin/bash WORDLIST=/usr/home/koren/ispell.words crt=24 EDITOR=vi ENV=/usr/home/koren/.shrc PWD=/usr/home/koren LOGNAME=koren TEXINPUTS=.:/usr/local/lib/texmf/tex//:/usr/local/share/texmf/tex//:/usr/local/share/texmf-dist/tex//:/usr/home/koren/others:/usr/home/koren/mytex:/usr/home/koren/projects/interpre/manual/english MANPATH=/usr/share/man:/usr/X11R6/man:/usr/local/man:/usr/local/pgsql/man HOME=/usr/home/koren LANG=C.UTF-8 EXINIT=set redraw wm=8 TEXEDIT=/usr/local/bin/emacs +%d %s SSH_CONNECTION=192.168.2.16 15340 192.168.2.19 22 PGLIB=/usr/local/pgsql/lib TERM=xterm USER=koren MORE=-cei mail=/usr/spool/mail/koren DISPLAY=localhost:11.0 SHLVL=1 PAGER=more MM_CHARSET=UTF-8 PS1=\! \h|\w> SSH_CLIENT=192.168.2.16 15340 22 PGDATA=/usr/local/pgsql/data host=jedi PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin:/usr/X11R6/bin:/usr/home/koren/bin BLOCKSIZE=K MAIL=/usr/spool/mail/koren SSH_TTY=/dev/pts/11 _=/usr/bin/env >> regards, >> > Can you show the commands you are running and the result printed in > the terminal. virtual_oss_cmd /dev/dsp.ctl -f /dev/dsp1.0 virtual_oss_cmd /dev/dsp.ctl -f /dev/dsp2.0 virtual_oss_cmd /dev/dsp.ctl -f /dev/dsp1 virtual_oss_cmd /dev/dsp.ctl -f /dev/dsp2 no output Hi, Maybe the output and input are two different DSP devices. Try using the -P /dev/dsp1 and -R /dev/dsp0 options instead to sepecify each device separately. --HPS
Re: sound on FreeBSD 14.0-CURRENT
Hi, It is not working... Just a thought... Could not be the problem how are the apps built (chromium, firefox), i.e. which options are set on? No, the default should work out of the box. What does "which virtual_oss_cmd" output? Maybe /usr/local/bin is not in your PATH? regards, Can you show the commands you are running and the result printed in the terminal. --HPS
Re: sound on FreeBSD 14.0-CURRENT
On 11/16/21 11:26, Ludovit Koren wrote: Hans Petter Selasky writes: > On 11/16/21 10:40, Ludovit Koren wrote: >> Hi, >> I am running FreeBSD 14.0-CURRENT #0 main-n250646-c0525ab1d1c-dirty: >> Sat Nov 13 16:42:44 CET 2021 >> Here is the output from: >> cat /dev/sndstat >> Installed devices: >> pcm0: (play/rec) default >> pcm1: (play) >> pcm2: (play) >> Installed devices from userspace: >> dsp: (play/rec) >> vdsp: (play/rec) >> I am running: >> /usr/local/sbin/virtual_oss -B -D /var/run/virtual_oss/dsp.pid -T >> /dev/sndstat -S -i 8 -C 18 -c 18 -r 48000 -b 32 -s 512 -f /dev/dsp0 >> -c 2 -d dsp -c 18 -d vdsp -t vdsp.ctl >> I am not able to redirect to different output even if I try for >> example: >> sysctl hw.snd.default_unit=1 >> Please see the attached output from: sysctl dev.pcm, sysctl hw.snd >> and >> dmesg. >> I did not find any hint how to redirect the sound output to the >> different >> device except hw.snd.default_unit. The output remains in the default >> output. Am I missing something or doing something wrong? >> > Hi, > When you are using virtual_oss , hw.snd.default_unit is not used. > man virtual_oss_cmd > Try this instead: > virtual_oss_cmd /dev/vdsp.ctl -f /dev/dsp1 Unfortunately, even the command is not working. Maybe your virtual_oss installation needs to be upgraded then? It should be supported. --HPS
Re: sound on FreeBSD 14.0-CURRENT
On 11/16/21 10:40, Ludovit Koren wrote: Hi, I am running FreeBSD 14.0-CURRENT #0 main-n250646-c0525ab1d1c-dirty: Sat Nov 13 16:42:44 CET 2021 Here is the output from: cat /dev/sndstat Installed devices: pcm0: (play/rec) default pcm1: (play) pcm2: (play) Installed devices from userspace: dsp: (play/rec) vdsp: (play/rec) I am running: /usr/local/sbin/virtual_oss -B -D /var/run/virtual_oss/dsp.pid -T /dev/sndstat -S -i 8 -C 18 -c 18 -r 48000 -b 32 -s 512 -f /dev/dsp0 -c 2 -d dsp -c 18 -d vdsp -t vdsp.ctl I am not able to redirect to different output even if I try for example: sysctl hw.snd.default_unit=1 Please see the attached output from: sysctl dev.pcm, sysctl hw.snd and dmesg. I did not find any hint how to redirect the sound output to the different device except hw.snd.default_unit. The output remains in the default output. Am I missing something or doing something wrong? Hi, When you are using virtual_oss , hw.snd.default_unit is not used. man virtual_oss_cmd Try this instead: virtual_oss_cmd /dev/vdsp.ctl -f /dev/dsp1 --HPS
Re: current now panics when starting VBox VM
On 11/2/21 16:37, Greg V via freebsd-current wrote: On November 2, 2021 5:16:35 PM GMT+03:00, Michael Butler via freebsd-current wrote: On current as of this morning (I haven't tried to bisect yet) .. .. with either graphics/drm-devel-kmod or graphics/drm-current-kmod, trying to start a VirtualBox VM triggers this panic .. #16 0x80c81fc8 at calltrap+0x8 #17 0x808b4d69 at sysctl_kern_proc_pathname+0xc9 something something https://reviews.freebsd.org/D32738 ? sysctl_kern_proc_pathname was touched recently there. (Also can someone commit https://reviews.freebsd.org/D30174 ? These warning-filled reports are unreadable >_<) Done: https://cgit.freebsd.org/src/commit/?id=2390a1441effaba0e3d0f2f447f448aaf20428f1 --HPS
Re: LAN ure interface problem
On 10/22/21 16:00, Ludovit Koren wrote: Hi, I have installed FreeBSD 14.0-CURRENT #1 main-n250134-225639e7db6-dirty on my notebook HP EliteBook 830 G7 and I am using RealTek usb LAN interface: ure0 on uhub0 ure0: on usbus1 miibus0: on ure0 rgephy0: PHY 0 on miibus0 rgephy0: OUI 0x00e04c, model 0x, rev. 0 rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto ue0: on ure0 ue0: bpf attached ue0: Ethernet address: 00:e0:4c:68:04:20 When there is bigger load on the interface, for example rsync of the big directory, the carrier is lost. The only solution I found is to remove and insert the usb interface; ifconfig ue0 down, ifconfig ue0 up did not help. The output of the ifconfig: ue0: flags=8843 metric 0 mtu 1500 options=68009b ether 00:e0:4c:68:04:20 inet 192.168.1.18 netmask 0xff00 broadcast 192.168.1.255 media: Ethernet autoselect (100baseTX ) status: active nd6 options=29 I do not know and did not find anything relevant, if the driver is buggy or the hardware has some problems. Please, advice. Regards, Not the same device, but similar issue: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258057 --HPS
Re: After updating main (so: 14) Orange Pi+ 2E panicked: ucom_cons_softc "'Translation Fault (L2)' on read" while typing first command after login
On 10/12/21 3:11 AM, Mark Millard via freebsd-arm wrote: There is this "mixer" oddity for each boot: Feeding entropy: . mixer: 75:75: no such device mixer: 75:75: no such device mixer: 75:75: no such device mixer: 25:25: no such device mixer: 75:75: no such device mixer: 75:75: no such device mixer: =rec: no such device lo0: link state changed to UP (in case that matters for some reason). Hi, Add this script to /etc/rc.d/ and you'll be fine from now on. https://cgit.freebsd.org/src/tree/libexec/rc/rc.d/mixer Then run: service mixer stop && service mixer start And the problem should go away. See "git: 903873ce1560 - main - Implement and use new mixer(3) library for FreeBSD" --HPS
Re: [HEADSUP] making /bin/sh the default shell for root
Hi, I've always used "tcsh" for root. The little help you get on the command line to search and repeat commands is very useful compared to plain "sh". Sorry for top-posting. --HPS
AMD Ryzen 5 3400G with Radeon Vega Graphics
Hi, I was lucky to get the hands on a mini-ITX containing a "AMD Ryzen 5 3400G with Radeon Vega Graphics". FreeBSD-13 installed just fine and 4K HDMI output works too with AMDGPU. However I noticed some problems with a webcamd DVB-T receiver, that it had lots of dropouts I couldn't understand. When I looked closer at this it turns out that something was blocking the threads for longer amounts of time, up to 100 ms at random. After some debugging I eventually found: sysctl machdep.idle machdep.idle: acpi machdep.idle_available: spin, mwait, hlt, acpi And when I set it to: sysctl machdep.idle=spin The problems I saw vanished. Anyone else having such experiences with Ryzen? --HPS
Re: Kernel/driver hacking: panic: Assertion vm_object_busied((m->object)) failed at /usr/src/sys/vm/vm_page.c:5455
On 6/20/21 7:32 AM, Neel Chauhan wrote: On 2021-06-18 20:03, Neel Chauhan wrote: Apparently, the vm_start values is for some reason coming as 0 when it is passed into vm_fault_cpu(). That's why it's giving these errors: of course the address at 0 is mapped, it is (probably) used by the kernel. An update: The vm_start 0 seems to be expected. I checked the values with printf()s. I have posted this on Twitter, and am considering hiring a kernel consultant to help if I am unable to do this on my own. So I am guessing this line (Line 231) is incorrect: pa = sg_dma_address(sgl); Source: https://github.com/neelchauhan/drm-kmod/blob/d0eee96973ee0772e977b813678f92c5becf0507/drivers/gpu/drm/i915/intel_freebsd.c#L231 Hi Neel, sg_dma_address() is zero, because the memory hasn't been loaded. You need to handle two cases there: When r->iobase is -1 and when it is not. I suspect you should add r->iobase to the sg_dma_address() only and only when it is non -1. Also, there is a superfluous "pa = " in the beginning of the function. --HPS
Re: Kernel/driver hacking: panic: Assertion vm_object_busied((m->object)) failed at /usr/src/sys/vm/vm_page.c:5455
Hi Neel,
On 6/16/21 5:28 PM, Neel Chauhan wrote:
Hi,
On 2021-06-16 00:35, Hans Petter Selasky wrote:
Do you have the full backtrace?
Yes.
I have attached a stack trace in the previous email, but if you didn't
get it, I have uploaded it to GitHub:
https://gist.github.com/neelchauhan/437bd10239f84c563aafb37ab440029a
Doesn't this code work in the current DRM - kmod? What changed? Did
you perhaps miss a patch?
I think there is new code with Linux 5.6 which changes how this is done.
I have been attempting to make a FreeBSD equivalent, but it panics. It
is **not** from missing Linux commits since I believe I added them all.
The code in my GH repo:
https://github.com/neelchauhan/drm-kmod/blob/5.7-wip/drivers/gpu/drm/i915/gem/i915_gem_mman.c#L346
I think the following changes are needed. CC'ing Jeff.
for_each_sg_page(pages->sgl, &sg_iter, pages->nents, 0) {
pmap_t pmap = vm_map_pmap(map);
struct vm_page *pa = sg_page_iter_page(&sg_iter);
VM_OBJECT_RLOCK(pa->object);
Try adding this:
vm_object_busy(pa->object);
if (pmap_enter(pmap, va, pa, 0, flags, 0)) {
Try adding this:
vm_object_unbusy(pa->object);
VM_OBJECT_RUNLOCK(pa->object);
err = -ENOMEM;
break;
}
Try adding this:
vm_object_unbusy(pa->object);
VM_OBJECT_RUNLOCK(pa->object);
va += PAGE_SIZE;
--HPS
Re: Kernel/driver hacking: panic: Assertion vm_object_busied((m->object)) failed at /usr/src/sys/vm/vm_page.c:5455
On 6/16/21 5:36 AM, Neel Chauhan wrote: Hi current@, First off, sorry if I spammed developers@ and other mailing lists with my previous message, and to bz@/hselasky@/manu@ sent so many duplicate emails. Right now, I am attempting to update the drm-kmod driver to the Linux 5.7 code, and am having an issue with the pmap lock. I am new-ish to the kernel, meaning not a whole lot of "experience", but do have patches in src. But like it not we need kernel newbies, they're the next generation of experts. If we don't, we'd be the next Minix with **zero** development since Tanenbaum retired. Going back, the code in question is here: https://github.com/neelchauhan/drm-kmod/blob/5.7-wip/drivers/gpu/drm/i915/gem/i915_gem_mman.c#L346 The lines important are 346-356, but lines of interest are also the non-"#ifdef __linux__" sections of vm_fault_cpu(). The code gives this error: panic: Assertion vm_object_busied((m->object)) failed at /usr/src/sys/vm/vm_page.c:5455 I have attached the core dump log. To those who aren't graphics driver experts, it happens when I load Xorg when Xorg attempts to map the I/O to userspace. But I feel this is more of me not using page locks correctly (which is needed for the pmap), or maybe a linuxkpi issue, rather than a graphics-specific issue. I spent days on this (all my non-$DAYJOB hours at one point + all my weekends) and haven't figured out the locks completely. Does anyone have suggestions to what I'm doing wrong in my code and locks? If it is important, OpenBSD's version of this code is here: https://github.com/openbsd/src/blob/2207c4325726fdc5c4bcd0011af0fdf7d3dab137/sys/dev/pci/drm/i915/gem/i915_gem_mman.c#L459 (lines 459-523, but some calls are unsurprisingly different). Hope you all can help. Hi, Do you have the full backtrace? Doesn't this code work in the current DRM - kmod? What changed? Did you perhaps miss a patch? --HPS
