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_…
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(a)cmp.felk.cvut.cz
www: http://cmp.felk.cvut.cz/~pisa
university: http://dce.fel.cvut.cz/
company: http://www.pikron.com/
Can we rename the "Affects Version" field to "Affected Revision"? Noone
cares for 0.3.11 bugs and TRUNK ins meaningless.
Also: is it possible to automaticcally translate to the current head
revision number, when TRUNK or rather HEAD is selected? Maybe when we
have FishEye?
Regards,
Timo
Hiya
We had a little discussion tonight, regarding changes in component list.
It is obvious that current list is illogical, unplanned and requires
urgent changes, with Jira update this is the best oportunity. Initial
plan was to base upon Timo's Layout rewrite. We had just a small
trimming done - below is the result:
audio
applications
directx (or rather 3d graphics which would allow also mesa/gallium in)
host-tools
networking
ntcore
sdk
shell
usb
winedlls
win32core
+
rosdlls(
| | advapi32
| | kernel32
| | crtdll
| | lsasrv
| | msvcrt
| | msvcrt20
| | msvcrt40
| | samlib
| | samsrv
| | secur32
| | security
| | fmifs
| | vdmdbg
| | userenv
| | uext2
| | ufat
| | ufatx
| | untfs)
The problem is what to do with some ill-fitting to the current scheme,
like:
| nls
| services
| eventlog
| rpcss
| services.exe
| svchost
| umpnpmgr
| spoolsv
and more. Do you see need for more components?
--
With best regards
Caemyr
Hi,
Does anyone know how to search for issues older than 1 year or something
like that?
According to https://jira.atlassian.com/browse/JRA-1983 it should be
possible, but Icouldn't figure out how to.
Timo
Why the removal of the do/while loop?
This breaks the macro when used without braces :
+#define SepReleaseTokenLock(Token) \
+ ExReleaseResource(((PTOKEN)Token)->TokenLock); \
+ KeLeaveCriticalRegion(); \
+
<snip>
-#define SepReleaseTokenLock(Token) \
- do { \
- ExReleaseResource(((PTOKEN)Token)->TokenLock); \
- KeLeaveCriticalRegion(); \
- while(0)
<snip>
/* Release the lock if we had acquired it */
+ if (!TokenLocked) SepReleaseTokenLock(Token);
Hi,
I'd like to invite every developer to make use of the Jira planning
feature. For those, who are not yet familiar with it here's a an explantion.
In the blue Jira menu bar you'll find an item called "Agile". Click on
that to get to the planning boards.
First time users will be asked to either choose between Scrum or Kanban.
Select Scrum.
Then you will be asked to select a dashboard or create one. You can
simply choose "Scrum Board" from the dropdown list, this one should be
fine. You can later create your own board, if you like.
Now you will see 3 buttons on the right-hand side below the menu bar:
"plan", "work" and "report"
First select "plan"
On the top you can see the current "sprint", which is the next planned
period. We currently have one sprint for September. We can create
multiple sprints and periods are as we want them. I think one month is
reasonable.
Under the sprint you can see the issues that are selected for this
sprint, i.e. supposed to be tackled in that period. Currently only
project administrators can create sprints, but every developer can move
items there. To remove an item from the sprint, you need to click on it,
so it gets highlited, then open the menu with the gear wheel icon in the
issue description on the right and select "Remove from sprint".
Below you see the backlog (all open issues). Since the list is quite
huge, you can limit it to your own issues, by pressing the "Only my
issues" filter button. (Note this one works like a pushbutton, click it
once to enable, again to disable. Maybe Amine can make them look more
like that by adding a highlite color)
On the righ-hand side, you see a box that shows the currently selected
issue.
Now you can drag and drop issues from the backlog into one of the
sprints. So if you plan to work on a specific issue in September, just
drag it into sprint 1.
Now select "work"
Here you can see the so called "swim lanes". In the default Scrum Board
they are configured per Developer. So you see every developer that has
active issues in the current sprint(s). You can open and close the swim
lanes to see the issues. And you can again select "Only my issues".
The board has 3 columns: "To do", "In Progress", "Done". All issues that
you selected for the current sprint will initially be in the "To do"
column. When you work on an issue, simply drag it over to the "In
Progress" column. When you fixed it, drag it to "Done". When dragging
them the target column will be highlited in green. The "Done" column
will show you 2 fields when dragging an item there: one for resolve, one
for close. When you dragged them to close, you'll see a confirmation
dialog, where you can enter additional stuff and then confirm it.
Have fun
Timo