12 Sep
2012
12 Sep
'12
12:46 p.m.
Hey Pavel,
it's great to hear that you find ReactOS useful for developing you
driver!
It's also excellent to have another driver confirmed working. ;)
On 2012-09-10 00:11, Pavel Pisa wrote:
The issues:
1) the first minor one - ReactOS requires minimal transfer size for
URB_FUNCTION_GET_DESCRIPTOR_FROM_DEVICE/USB_CONFIGURATION_DESCRIPTOR_TYPE function
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 spec for us in most (if not all) cases is "what does Windows do",
which means that this is by definition a bug in ROS's USB stack.
The ASSERT simply indicates that the code is not prepared for this case,
either because the developer didn't expect it to be possible, or deemed
it unnecessary to implement right away (because he hadn't seen a driver
use it yet).
I've created a Jira issue for this:
http://jira.reactos.org/browse/CORE-6634
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.
Not sure where this might come from either, but I'd generally rather
assume a bug in ROS rather than your driver.
I suppose whatever component calls the ShutdownRoutine should be
verified to do that correctly.
Perhaps you'd like to create an issue for this too. Some debugging of
the relevant USB components or a method to reproduce this (though I
suppose one would need a compatible piece of hardware :p) might of
course be useful.
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
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:>
You might want to generate a backtrace here (bt command).
This assert is likely to be present in a checked build of Windows as
well, and indicates that the IRP that is being freed is still queued to
a thread. I.e. it might be freed by someone who doesn't own it.
The backtrace (and your driver's debug info) should help you determine
where/how this happens, and possibly show a bug in the driver. It might
of course still be a bug in ROS, though ;)
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.
Alas, our AMD64 port still needs a lot of work in order to actually
install and boot properly.
A stable version, especially on real hardware, is also something that
may take quite a long time.
But of course it's (again :p) great that you've found the project
useful so far, and hopefully it'll continue to be ;)
Finally - because we aim for compatibility with Windows, drivers
shouldn't ultimately need to be modified to work on ROS, so most of the
differences you spot are probably bugs in ReactOS by definition.
We'll of course gladly take further reports of such bugs ;)
Best Regards,
Thomas