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

Thanks @obiwac!

Fixes from comment

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.

In D52166#1194385, @kenrap_kennethraplee.com wrote:

In D52166#1194208, @aokblast wrote:

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

With your latest changes, it does prevent bhyve from crashing. Appreciate it!

So, now it seems to create an additional 22 second stall at boot compared to without passing through the ssd with usb adapter.

When fully booted, it seems like it doesn't recognize it as if it weren't passthru'd.

Follow xHCI document

Set PCD to report port status change

Set PCD for FreeBSD

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

Minor updates

Honor different configuration.

In D52166#1193959, @kenrap_kennethraplee.com wrote:

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.

However, regular usb3 mass storage works fine and is recognized.

I have tested on Windows and works fine. An interesting thing is that when I plug in a Linux Live CD. The UEFI shell recognize it and want me to install Linux:).

Fix windows related bug.

This implemented is problematic since the correct way is to append a zero size TRB in TD instead of creating new TD. However, I think I am unable to make it work before 15.0 release. Therefore, I will modify it to at least we won't break any ABI for 15 if we want to merge later.

No clear in reset

Add total number of xfer to xhci

Fix various locking problem

Destroy mutex

Rename upassthru -> usb_passthru

Use (void)

Formatting

Use int

Minor fixes

Add missing ue_cancel

Minor fixes

Minor fixes

In D47930#1191301, @phil wrote:

Why do you need this on xo_buf.h, an internal file?

In the FWIW department: It always seems odd that C++ needs decoration in non-C++ files, rather that have this knowledge in compiler command line arguments (e.g. "--c-include /usr/include").

Thanks,
Phil

Also, thanks for helping me test it!

In D52166#1191842, @bz wrote:

I have to second the *wow* given I have started this myself not knowing you are working on it.

I'll be happy to contribute the code for ugen selector as I have multiple v/d duplicates on laptops. doesn't need libusb changes, just a bit more parsing and looping (assuming my code fits in yours).
ugen matching isn't ideal either as you unplug/plug things and the bus.addr change and you have to update the config file... If you meant adding ugen checks on top of v/d then...

I think some of the fixes should be factored out upfront and commit separately.

I'll definitively test this by the end of the week with smart cards, some licensing dongle (very weird thing), and some wifi dongles.

In D52166#1191818, @ziaee wrote:

Wow this is exciting! How do we use this? Can we put it in the manual?

Reorder include

FOrmatting

Format fixes

Remove useless constant

In D52049#1191173, @markj wrote:

In D52049#1191172, @aokblast wrote:

In D52049#1191168, @markj wrote:

I think it's ok, thank you.

One thing I am not sure about: should we just compile the new driver into ichwd.ko rather than create a new kernel module? I do not think it is a major issue, but personally I would probably just fold this into ichwd.ko to keep the diff smaller. I leave it up to you.

I never do that before. Can I define two modules inside a ko? I know that the kernel module is done through special ELF section and will be handled by kernel loader. I don't know if the linker works on combining these two into a single section.

Yes! It is a bit confusing, but there are two distinct concepts, linker files (i.e., ELF files which the kernel can load, so a .ko file) and modules (typically drivers). A linker file can contain multiple modules. kldstat -v will list the modules in each linker file, e.g.,:

4    1 0xffffffff8227d000   380300 vmm.ko (/boot/kernel.GENERIC-NODEBUG/vmm.ko)
       Contains modules:                                                                                                                                      
                Id Name                                                                                                                                       
                 6 acpi/ivhd                                                                                                                                  
                 5 pci/amdviiommu   
                 4 pci/ppt                                                                                                                                    
                 3 vmm                                                                                                                                        
5    1 0xffffffff825fe000   61fa88 zfs.ko (/boot/kernel.GENERIC-NODEBUG/zfs.ko)                                                                               
       Contains modules:                                                                                                                                      
                Id Name                                                                                                                                       
                 7 zfsctrl                                                                                                                                    
                 9 zfs                                                                                                                                        
                10 zfs_zvol
                 8 zfs_vdev

Confusingly, to most people "kernel module" means "linker file." Usually the distinction is not important, and usually a linker file contains only one module.

Merge driver to ichwd

In D52049#1191168, @markj wrote:

I think it's ok, thank you.

One thing I am not sure about: should we just compile the new driver into ichwd.ko rather than create a new kernel module? I do not think it is a major issue, but personally I would probably just fold this into ichwd.ko to keep the diff smaller. I leave it up to you.

Add manual

Add missing x86 file

rename i6300esb -> i6300esbwd

LGTM. Thanks!

Minor fixes

Minor fixes and add usbcnfig document

Fix style nit

Elaborate comments

Remove useless sysctl

Other looks good. Thanks!

In D52101#1189939, @lwhsu wrote:

In D52101#1189908, @aokblast wrote:

In D52101#1189896, @lwhsu wrote:

In D52101#1189895, @aokblast wrote:

In D52101#1189879, @lwhsu wrote:

I mentioned perhaps making hkbd_no_leds a normal sysctl is that it can be used as a workaround for people in ticket 288968.

I locate the problem inside qemu and do some modification then it works. I will submit a patch to qemu later.

That's great. I feel then we have one more reason to have that sysctl to let people to workaround it before qemu having a new release and being deployed to the production environments.

Wouldn't it means I need to create another patch for that? Why not just use the fix in here?

In most of case we want to avoid ignoring the return error entirely, as this implicitly hides the error in other places, which might cause other issues in the future.

Hmm, I am on the fence now, indeed it's also not good to ask people to manually set a workaround, even it's just a simple sysctl.

I guess I should accept this, as we can fix qemu but probably harder for Parallel.

After all, can we add some DPRINTF() in KDSKBSTATE or hkbd_set_leds() or KDSETLED to indicate that an error occurs?

Minor fixes

In D52101#1189896, @lwhsu wrote:

In D52101#1189895, @aokblast wrote:

In D52101#1189879, @lwhsu wrote:

I mentioned perhaps making hkbd_no_leds a normal sysctl is that it can be used as a workaround for people in ticket 288968.

I locate the problem inside qemu and do some modification then it works. I will submit a patch to qemu later.

That's great. I feel then we have one more reason to have that sysctl to let people to workaround it before qemu having a new release and being deployed to the production environments.

In D52101#1189879, @lwhsu wrote:

In D52101#1189875, @aokblast wrote:

The previous comment is incorrect. I check the HID document. HID has a usage page to locate the LED stuff. And FreeBSD kernel does check if such usage page exists. The problem maybe comes from qemu.

Ok, yes, I was wondering why the /* figure out leds on keyboard */ part in`hkbd_parse_hid() doesn't work. If it works then hkbd_set_leds()` should work as our expectation.

I mentioned perhaps making hkbd_no_leds a normal sysctl is that it can be used as a workaround for people in ticket 288968.

The previous comment is incorrect. I check the HID document. HID has a usage page to locate the LED stuff. And FreeBSD kernel does check if such usage page exists. The problem maybe comes from qemu.

Fix in caller instead of fixing in callee