Prev: usbsamp WdfRequestRetrieveOutputWdmMdl failure question
Next: Installation of WinUSB on XP Pro SP2
From: Asaf Shelly on 20 Dec 2009 03:32
OK... so we can take the USB version out of the list..
Below is another one.
It is harder to reproduce with smaller endpoint buffers (32,64) and easier
with 256.

Asaf

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: 00000000, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, value 0 = read operation, 1 = write operation
Arg4: ba3eafd3, address which referenced memory

Debugging Details:
------------------
*********************************************************************

ADDITIONAL_DEBUG_TEXT:
Use '!findthebuild' command to search for the target build information.
If the build information is available, run '!findthebuild -s ; .reload' to
set symbol path and load symbols.

MODULE_NAME: usbuhci

FAULTING_MODULE: 804d7000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 480254ce

WRITE_ADDRESS: unable to get nt!MmSpecialPoolStart
unable to get nt!MmSpecialPoolEnd
unable to get nt!MmPoolCodeStart
unable to get nt!MmPoolCodeEnd
00000000

CURRENT_IRQL: 2

FAULTING_IP:
usbuhci!UhciProcessDoneAsyncTd+dd
ba3eafd3 f3a5 rep movs dword ptr es:[edi],dword ptr [esi]

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD1

LAST_CONTROL_TRANSFER: from ba3eafd3 to 805446f0

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be
wrong.
ba4d3b98 ba3eafd3 badb0d00 620b45ff 50726261 nt!Kei386EoiHelper+0x2834
ba4d3c28 ba3eb520 899ca9dc 88fe31a0 88ff8df0
usbuhci!UhciProcessDoneAsyncTd+0xdd
ba4d3c48 ba3e8ded 899ca9dc 88fe3000 ba4d3c78
usbuhci!UhciPollAsyncEndpoint+0x450
ba4d3c58 b8af74aa 899ca9dc 88ff8df0 80546acc usbuhci!UhciPollEndpoint+0x1f
ba4d3c78 b8af8768 026c6f50 899ca0e0 88ff8c78 USBPORT!USBPORT_PollEndpoint+0xe8
ba4d3ca0 b8afc0a0 899ca028 50457270 80546acc
USBPORT!USBPORT_CoreEndpointWorker+0x2be
ba4d3cd0 b8b0a24b 899ca028 80546acc 899ca028 USBPORT!USBPORT_DpcWorker+0x18a
ba4d3d0c b8b0a3c2 899ca028 00000001 8055c0c0
USBPORT!USBPORT_IsrDpcWorker+0x38f
ba4d3d28 80545e7f 899ca64c 6b755044 00000000 USBPORT!USBPORT_IsrDpc+0x166
ba4d3d50 80545d64 00000000 0000000e 00000000 nt!KiDispatchInterrupt+0x4bf
ba4d3d54 00000000 0000000e 00000000 00000000 nt!KiDispatchInterrupt+0x3a4


STACK_COMMAND: kb

FOLLOWUP_IP:
usbuhci!UhciProcessDoneAsyncTd+dd
ba3eafd3 f3a5 rep movs dword ptr es:[edi],dword ptr [esi]

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: usbuhci!UhciProcessDoneAsyncTd+dd

FOLLOWUP_NAME: MachineOwner

IMAGE_NAME: usbuhci.sys

BUCKET_ID: WRONG_SYMBOLS

Followup: MachineOwner
---------


From: Tim Roberts on 20 Dec 2009 19:51
Asaf Shelly <MSMediaForum(a)Shelly.co.il> wrote:
>
>OK... so we can take the USB version out of the list..
>Below is another one.
>It is harder to reproduce with smaller endpoint buffers (32,64) and easier
>with 256.

Well, hold on. What kind of pipes are you using? In a full-speed device,
bulk pipes can have 8, 16, 32, or 64-byte packets. In a high-speed device,
bulk pipes can only use 512-byte packets. Those are the ONLY choices. A
bulk pipe can NEVER have 256-byte packets.
--
Tim Roberts, timr(a)probo.com
Providenza & Boekelheide, Inc.
From: Asaf Shelly on 21 Dec 2009 05:12
How about that....
It has been 10 years since I last read chapter 9. Didn't even remember there
was a limit.
Thanks for the answer it was really helpful.
Now can someone please tell me why my USB1.1 hardware enjoys 2X time
improvement when I am using 128 bytes per buffer.

* Also this is no reason for a blue-screen. The host can detect that the
device is doing something wrong and ignore it. I know that devices are not
expected to make such mistakes but this is load-time tests so there is no
impact on performance. Having a device that can make the kernel read invalid
buffers is also a potential security risk.

Thanks again for the help.
Asaf
From: Asaf Shelly on 21 Dec 2009 06:47
Never mind about the 128 buffers. Probably a device internal problem.

TIA,
Asaf
From: Tim Roberts on 22 Dec 2009 22:53
Asaf Shelly <MSMediaForum(a)Shelly.co.il> wrote:
>
>How about that....
>It has been 10 years since I last read chapter 9. Didn't even remember there
>was a limit.
>Thanks for the answer it was really helpful.
>Now can someone please tell me why my USB1.1 hardware enjoys 2X time
>improvement when I am using 128 bytes per buffer.

Absolutely. Remember USB is a scheduled bus; the entire frame is scheduled
in advance; the hardware then executes the transfers on its own while the
HCD driver schedules the next frame. Let's say you send 64 bytes and wait,
then send 64 bytes and wait. In that case, you are going to send exactly
one packet per frame, so no more than 64 bytes per millisecond.

But when you send 128 bytes and wait, the HCD driver can schedule that as 2
64-bit packets in a single frame. That doubles your throughput. If you
send 1024-byte buffers, you'll do even better.

Howver, the device's endpoint packet size is limited to 64 bytes (for full
speed).

>* Also this is no reason for a blue-screen. The host can detect that the
>device is doing something wrong and ignore it. I know that devices are not
>expected to make such mistakes but this is load-time tests so there is no
>impact on performance. Having a device that can make the kernel read invalid
>buffers is also a potential security risk.

Well, USB is a protocol bus, and devices are expected to obey the
protocols. There are tests for protocol compliance that must be passed
before your driver can be WHQL-approved, but the system cannot be expected
to protect against every protocol violation.

Yes, you are right, and I am just making lame excuses.
--
Tim Roberts, timr(a)probo.com
Providenza & Boekelheide, Inc.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: usbsamp WdfRequestRetrieveOutputWdmMdl failure question
Next: Installation of WinUSB on XP Pro SP2