Dear ReactOS developers,
I follow ReactOS development for some years. I have successfully tested and reported our uLAN driver with PCI cards on ReactOS two years ago.
The latest inclusion of USB VENDOR device requests in ReactOS allowed to finally run driver with our real USB hardware with QEMU KVM USB device pass-through setup.
ReactOS tuned version of the uLAN driver installs and is fully functional when tested from CHROMuLAN application.
But there are more issues still and I would be happy if somebody can help with these or give me hint about possible incompatibility in our driver.
The tests were conducted against ReactOS 57254 build. uLAN driver is from GIT source repository
http://ulan.sourceforge.net/ http://ulan.git.sourceforge.net/git/gitweb.cgi?p=ulan/ulan-drv;a=tree;f=ul_d...
uLAN driver was build by MS WDF VC version 15.00.30729.207
The issues:
1) the first minor one - ReactOS requires minimal transfer size for URB_FUNCTION_GET_DESCRIPTOR_FROM_DEVICE/USB_CONFIGURATION_DESCRIPTOR_TYPE function
(/srv/buildbot_cmake/full_cmake/build/drivers/usb/usbhub/pdo.c:244) URB_FUNCTION_GET_DESCRIPTOR_FROM_DEVICE ulan: _usb_submit_urb : return from IoCallDriver USBD 103 ulan: _usb_submit_urb : URB status = 0 status = 0 irp status 0 uLan: _usb_submit_urb done with status:0x0 uLan: _usb_get_descriptor done with status:0x0 uLan: usb_device_descriptor done with status:0x0 uLan: usb_get_configuration uLan: _usb_get_descriptor (type=0x2,idx=0x0) ulan: _usb_submit_urb : enter (/srv/buildbot_cmake/full_cmake/build/drivers/usb/usbhub/pdo.c:244) URB_FUNCTION_GET_DESCRIPTOR_FROM_DEVICE Assertion 'Urb->UrbControlDescriptorRequest.TransferBufferLength >= sizeof(USB_CONFIGURATION_DESCRIPTOR)' failed at /srv/buildbot_ cmake/full_cmake/build/lib/drivers/libusb/hub_controller.cpp line 1560 Entered debugger on embedded INT3 at 0x0008:0x80924c3a.
Unmodified uLAN driver asks for the first four bytes descriptor bytes firest and after obtaining size of the whole descriptor it prepares full size transfer. ReactOS asserts for this shorted 4 bytes transfer. I have adapted driver to use sizeof(USB_CONFIGURATION_DESCRIPTOR) size for initial probe transfer in USB_CONFIGURATION_DESCRIPTOR_TYPE case. This makes ReactOS happy, but I would like to know which side should be updated in the future.
Is there defined in some spec that initial probe for size has to be at least of sizeof(USB_CONFIGURATION_DESCRIPTOR) or the ReactOS is more strict than necessary and assert should be modified to allow truncated probes or at least 4 bytes ones in addition?
The full log at
http://cmp.felk.cvut.cz/~pisa/ulan/reactos/reactos-ul-win-confdesc.log
2) Driver can be enabled and disabled at runtime but shutdown does not finish, is blocked somehow but system/cursor is responsive
http://cmp.felk.cvut.cz/~pisa/ulan/reactos/reactos-ul-enabled-at-runtime.log
I have no idea what is the problem. Driver works correctly on Windows from 2k to Win7 and latest version supports even suspend and resume on all these platforms.
3) When driver and device are installed/present from boot time, boot hangs
http://cmp.felk.cvut.cz/~pisa/ulan/reactos/reactos-ul-during-boot.log
(/srv/buildbot_cmake/full_cmake/build/lib/drivers/libusb/hub_controller.cpp:313) [USBLIB] SCE Request B027B048 TransferBufferLength 8 Flags 3 MDL 00000000 (/srv/buildbot_cmake/full_cmake/build/lib/drivers/libusb/hub_controller.cpp:324) [USBLIB] Port 0: Status 103, Change 0 (/srv/buildbot_cmake/full_cmake/build/lib/drivers/libusb/hub_controller.cpp:324) [USBLIB] Port 1: Status 100, Change 0 (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/io/pnpmgr/pnpmgr.c:4030) IRP_MN_QUERY_PNP_DEVICE_STATE failed with status 0xc00000bb (/srv/buildbot_cmake/full_cmake/build/drivers/usb/usbhub/pdo.c:541) uLan2usb convertor (/srv/buildbot_cmake/full_cmake/build/drivers/usb/usbhub/pdo.c:541) uLan2usb convertor (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/io/pnpmgr/pnpmgr.c:4030) IRP_MN_QUERY_PNP_DEVICE_STATE failed with status 0xc00000bb (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/io/iomgr/iorsrce.c:725) Failed opening given symbolic link! (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:174) Loading: \SystemRoot\system32\drivers\pciide.sys at FCBF4000 with 7 pages (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:174) Loading: \SystemRoot\system32\drivers\pciidex.sys at FCBEB000 with 9 pages (/srv/buildbot_cmake/full_cmake/build/drivers/bus/pci/pdo.c:1267) Enabling command flags for PCI device 0x21 on bus 0x0: [Bus master] [I/O space enable] (/srv/buildbot_cmake/full_cmake/build/drivers/storage/ide/pciidex/fdo.c:464) IRP_MJ_PNP / Unknown minor function 0x9 (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:174) Loading: \SystemRoot\system32\drivers\ul_wdm.sys at FCBD9000 with 11 pages Assertion 'IsListEmpty(&Irp->ThreadListEntry)' failed at /srv/buildbot_cmake/full_cmake/build/ntoskrnl/io/iomgr/irp.c line 1524 Entered debugger on embedded INT3 at 0x0008:0x80924c3a. kdb:> ====================================================================================
Thanks for any hints in advance.
I would be happy if the problems are resolved in the future. It could be interresting option to have livecd available with ReactOS, uLAN driver and CHROMuLAN for us one day. We can provide even some small funding for such achievement if it could work reliably on real hardware.
Other reason why ReactOS is interresting for us is that it has cached some bugs in our driver (mismatch in memory pools tags which are not reported by Windows release builds). Yet another reasons for ReactOS is to use 64-bit ReactOS build as testbed for uLAN driver Windows 64-bit version debugging. (64-bit Linux x86 version is fully supported now same as MIPS, PPC and ARM). But 64-bit Windows are pain for its signing requirements etc. And after all I do not have any (32/64-bit) Windows installed on our computers at all so ReactOS is great target for our development even if we has to depend on users use and demand for Windows.
As for CHROMuLAN and RectOS compatibility, chromatography system is functional under ReactOS except for some problem in the complex calibration files dialog which can hang the application and some harmless exception during analysis files read. Both seems to cause similar problems under Wine as well.
In each case, thanks for the big pile of the work invested to the ReactOS project,
Pavel Pisa e-mail: pisa@cmp.felk.cvut.cz www: http://cmp.felk.cvut.cz/~pisa university: http://dce.fel.cvut.cz/ company: http://www.pikron.com/