In D52166#1273524, @aokblast wrote:

In D52166#1196957, @kenrap_kennethraplee.com wrote:

In D52166#1196949, @aokblast wrote:

Hello, I think I need to at least get a usb 3 hub to test this feature since I haven’t had any super speed device. I will take a look at the candidates hub. However, I am occupied by other stuff recently. Maybe you won’t get any feedback very soon (Maybe a months afterI promise that I will be back ASAP since I would like to finish this feature. Sorry for your inconvenience on helping me test this!

Appreciate the heads up. I'll be on standby.

Hello, I am back and I suspect that https://reviews.freebsd.org/D55289 fixes the problem.
I have rebased the patch to the HEAD.
Could you please check if it actually works?

No objections for cad/fritzing.

The latest version of zig2tuple needs to be merged in the ports tree in order to pick up the missing dependencies that @guest-charlesrocket needed to build ghostty: https://github.com/freebsd/freebsd-ports/pull/469

In D52166#1196949, @aokblast wrote:

Hello, I think I need to at least get a usb 3 hub to test this feature since I haven’t had any super speed device. I will take a look at the candidates hub. However, I am occupied by other stuff recently. Maybe you won’t get any feedback very soon (Maybe a months afterI promise that I will be back ASAP since I would like to finish this feature. Sorry for your inconvenience on helping me test this!

In D52166#1196153, @aokblast wrote:

Hello: Does your device work on FreeBSD host? I saw a transfer is cancelled so the problem maybe on the libusb side or kernel stack.

In D52166#1196089, @aokblast wrote:

In D52166#1196057, @kenrap_kennethraplee.com wrote:

In D52166#1196056, @aokblast wrote:

Sorry, I know that it is a little bit annoying. But since I don't have such device. Could you please try again?

No worries, I want to make sure this gets done right. I'll be your beta tester for this. 👍

I'm rebuilding my src tree now.

Thanks. I really need to get a device with stream in their descriptor. Could you please try again.

No difference. The report: https://gist.github.com/kenrap/9a1c406d097aa12c7a7b7ebe106cb681

In D52166#1196056, @aokblast wrote:

Sorry, I know that it is a little bit annoying. But since I don't have such device. Could you please try again?

In D52166#1195497, @aokblast wrote:

In D52166#1195426, @kenrap_kennethraplee.com wrote:

In D52166#1195408, @aokblast wrote:

In D52166#1195391, @kenrap_kennethraplee.com wrote:

In D52166#1195280, @aokblast wrote:

Hello, could you please set the xhci_debug=1 and usb_passthru_debug=1 in bhyve and send me the report? The report maybe very long I think.

Quick question. How can I go about setting those options and generating the report using vm-bhyve? I already patched it using the diff from your github PR.

Hello, sorry it is from the code directly since it works like the normal DPRINTF. xhci_debug is in pci_xhci.c. usb_passthru_debug is in usb_passthru.c

Gotcha, thanks for clarifying: Here is the report (3911 lines): https://gist.github.com/kenrap/ecfc003562bd8717900a46de4903d7bf

Could you please check if it works now?

In D52166#1195408, @aokblast wrote:

In D52166#1195391, @kenrap_kennethraplee.com wrote:

In D52166#1195280, @aokblast wrote:

Hello, could you please set the xhci_debug=1 and usb_passthru_debug=1 in bhyve and send me the report? The report maybe very long I think.

Quick question. How can I go about setting those options and generating the report using vm-bhyve? I already patched it using the diff from your github PR.

Hello, sorry it is from the code directly since it works like the normal DPRINTF. xhci_debug is in pci_xhci.c. usb_passthru_debug is in usb_passthru.c

In D52166#1195280, @aokblast wrote:

Hello, could you please set the xhci_debug=1 and usb_passthru_debug=1 in bhyve and send me the report? The report maybe very long I think.

In D52166#1194208, @aokblast wrote:

Hello, could you please try again. I forget to adopt multiple configurations.

In D52166#1193982, @aokblast wrote:

Could you please give me the following information?

Sure thing!

For some reason when passing through an SSD with a sata-to-usb3 adapter, it causes bhyve to crash when the Linux kernel is starting to boot.

In D51251#1171079, @olce wrote:

Hi, then please upgrade to a recent -CURRENT. I don't see such errors at all. Incidentally, going to do some minor updates of the revision, with base being an hours-ago main.

Or maybe you've applied local patches of your own?

Hello, thanks for your hard work in solving this.

In D45855#1160605, @hrs wrote:

https://people.allbsd.org/~hrs/FreeBSD/f1692c.diff

In D45855#1160497, @hrs wrote:

Could you explain your configuation and behavior change in more detail?

Sure thing. I use the following in my rc.conf which enlarges the virtual terminal fonts from being small after loading a drm-kmod driver during the booting process:

allscreens_flags="-f spleen-16x32"

After doing a src tree build upgrade today this functionality had stopped. By manually removing both set -o noglob and set +o noglob lines, I restored the original functionality.

This change introduced a regression where my allscreens_flags settings gets ignored at boot.

What are the alternatives to these removed functions? This change essentially broke drm-kmod from building, at least from this line: https://github.com/freebsd/drm-kmod/blob/66e1d0ffbf791759619aa3cfca5ee87da3a5c5c2/drivers/gpu/drm/i915/gem/i915_gem_mman.c#L171

I'm having this same problem with the GOP Blt rendering the framebuffer at my monitor's 4K resolution. It makes rendering to the next part of the loader crawl very slowly against my screen at a row-by-row basis.

• Clean up PORTREVISIONS

Squashed commit to back out plasma5-ports

Squashed commit to back out kf5-ports

A squashed commit for removing an irrelevant file

I just got my account approved. Here, I'll share the same statistics as I did from IRC using the script I wrote.
I also changed the format of the output for better readability.