SMI causing BSOD in USBHUB

hi all,

We have a driver that does custom SMI to a custom BIOS through IOCTL calls.
We *do not* use the ACPI driver interface to generate SMIs, we instead read
the BIOS ACPI tables and find out the SMI port and we know the function
number (since it is out own) and use the out instruction directly instead of
the HAL interfaces.

This driver of ours is WHQLed and works almost on every system.

However, we have a problem with some stress tests run by our partner OEM for
Windows System WHQL, the partner is using PMS in this case.

The scenario is this:

Install out software (which has the driver and the user mode service
running) and all other software they bundle with the system and runs PMS
tests on them. This particular test will do power cycles s3/s4 thousands of
times.

We find that the machine BSODs after a random number of cycles.

The crash is 9F, and points to usbhub or BTusb hub or something similar.

However when I do a stacks 2 I find that at the point of the crash our ser
mode service made an IOCTL call and an SMI was generated.

Given this scenario, and the newest Win7 power IRP rules, I think this is
what is going on:

Windows sends a power down IRP but by that time the IOCTL was already
generated. So our thread goes into SMI. SMI might take some time and when it
comes out of SMI, the Windows Timer for power event has expired and also due
to thread scheduling the thread that would wake up (after we exit smi
ofocurse) is the USB driver. Now since windows has no knowledge that SM
Ihappned it simply assumes that USB driver took too much time to shut down
and panics and throws the BSOD 9F.

My questions o you all are:

  1. Can this be a valid explanation of what is causing the os to panic?
  2. what other possible explanations can be? (if we remove our software the
    platofrm passes the logo tests)
  3. How can I fix this? Win7 is very strict n it’s power IRP rules, and I
    need to figure out a solution (it could be an app level or a driver level
    fix)
  4. it is possible for the app to help us fix this, re-whqling the driver
    will take a longertime than an appleel solution (if possible)

thanks in advance

ap

  1. Could you post the !analyze -v?

  2. Does this crash always involve the same device/driver? That is, is it always the usb device you mentioned?

mm

it is usually usb or blue tooth, i have three dumps two from usbhub one from
blue tooth…below is analyze -v on on of these…

0: kd> !analyze -v
*******************************************************************************
*
*
* Bugcheck
Analysis *
*
*
*******************************************************************************
DRIVER_POWER_STATE_FAILURE (9f)
A driver is causing an inconsistent power state.
Arguments:
Arg1: 00000003, A device object has been blocking an Irp for too long a time
Arg2: 941a2030, Physical Device Object of the stack
Arg3: 83337ae0, Functional Device Object of the stack
Arg4: 9521ee00, The blocked IRP
Debugging Details:

*** ERROR: Module load completed but symbols could not be loaded for
btusbflt.sys
DRVPOWERSTATE_SUBCODE: 3
IRP_ADDRESS: 9521ee00
DEVICE_OBJECT: 8a08e018
DRIVER_OBJECT: 8a089ef0
IMAGE_NAME: btusbflt.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 4a2ed826
MODULE_NAME: btusbflt
FAULTING_MODULE: 96f46000 btusbflt
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
BUGCHECK_STR: 0x9F
PROCESS_NAME: System
CURRENT_IRQL: 2
LAST_CONTROL_TRANSFER: from 8324d054 to 832edd10
STACK_TEXT:
83337a94 8324d054 0000009f 00000003 941a2030 nt!KeBugCheckEx+0x1e
83337b00 8324c8e8 83337bac 00000000 83344280 nt!PopCheckIrpWatchdog+0x1f5
83337b38 8327b04d 83352a20 00000000 e0cd92cf nt!PopCheckForIdleness+0x73
83337b7c 8327aff1 8333ad20 83337ca8 00000001 nt!KiProcessTimerDpcTable+0x50
83337c68 8327aeae 8333ad20 83337ca8 00000000
nt!KiProcessExpiredTimerList+0x101
83337cdc 8327920e 0000b28e a0b616f0 83344280 nt!KiTimerExpiration+0x25c
83337d20 83279038 00000000 0000000e 00000000 nt!KiRetireDpcList+0xcb
83337d24 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x38

STACK_COMMAND: kb
FOLLOWUP_NAME: MachineOwner
FAILURE_BUCKET_ID: 0x9F_IMAGE_btusbflt.sys
BUCKET_ID: 0x9F_IMAGE_btusbflt.sys
Followup: MachineOwner

On Tue, Dec 1, 2009 at 7:24 PM, wrote:

> 1. Could you post the !analyze -v?
>
> 2. Does this crash always involve the same device/driver? That is, is it
> always the usb device you mentioned?
>
>
> mm
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

What does ‘!irp 0x9521ee00 1’ say?

mm

it is he set power IRP…

0: kd> !irp 9521ee00 1
Irp is active with 11 stacks 10 is current (= 0x9521efb4)
No Mdl: No System Buffer: Thread 00000000: Irp stack trace.
Flags = 00000000
ThreadListEntry.Flink = 9521ee10
ThreadListEntry.Blink = 9521ee10
IoStatus.Status = 00000000
IoStatus.Information = 00000000
RequestorMode = 00000000
Cancel = 00
CancelIrql = 0
ApcEnvironment = 00
UserIosb = 00000000
UserEvent = 00000000
Overlay.AsynchronousParameters.UserApcRoutine = 00000000
Overlay.AsynchronousParameters.UserApcContext = 00000000
Overlay.AllocationSize = 00000000 - 00000000
CancelRoutine = 00000000
UserBuffer = 00000000
&Tail.Overlay.DeviceQueueEntry = 9521ee40
Tail.Overlay.Thread = 00000000
Tail.Overlay.AuxiliaryBuffer = 00000000
Tail.Overlay.ListEntry.Flink = 83352478
Tail.Overlay.ListEntry.Blink = 83352478
Tail.Overlay.CurrentStackLocation = 9521efb4
Tail.Overlay.OriginalFileObject = 00000000
Tail.Apc = 00000000
Tail.CompletionKey = 00000000
cmd flg cl Device File Completion-Context
[0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000

[16, 2] 0 e1 8a08e018 00000000 8329a851-952130d8 Success Error Cancel
pending
\Driver\btusbflt nt!IopUnloadSafeCompletion
Args: 00000000 00000001 00000003 00000000
[0, 0] 0 0 00000000 00000000 00000000-a0a05180
Args: 00000000 00000000 00000000 00000000

On Tue, Dec 1, 2009 at 7:48 PM, wrote:

> What does ‘!irp 0x9521ee00 1’ say?
>
> mm
>
>
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

Going back to basics for a moment:

  1. What’s the target system?

  2. Is this system different than the others in any obvious way?

  3. Have you tried (if you can) uninstalling that ‘btusbflt’ module, or even just deselecting the ‘allow this device to power the system’ (or whatever) checkbox on the properties page for that device? A lot of devices have been known to have problems in the area of power management.

Presumably, even if this were to ‘work,’ it wouldn’t be a solution for you, but it might help define the problem/interaction a little better.

mm

For your own info, btusbflt is not a microsoft written driver. Also, it takes minutes for the 9f timer to fire, so unless your smi takes that long too, i think your smi has other effects on the system that manifest in hung drivers and perhaps messing up the usb hc state

d


From: A P
Sent: Tuesday, December 01, 2009 6:22 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] SMI causing BSOD in USBHUB

it is he set power IRP…

0: kd> !irp 9521ee00 1
Irp is active with 11 stacks 10 is current (= 0x9521efb4)
No Mdl: No System Buffer: Thread 00000000: Irp stack trace.
Flags = 00000000
ThreadListEntry.Flink = 9521ee10
ThreadListEntry.Blink = 9521ee10
IoStatus.Status = 00000000
IoStatus.Information = 00000000
RequestorMode = 00000000
Cancel = 00
CancelIrql = 0
ApcEnvironment = 00
UserIosb = 00000000
UserEvent = 00000000
Overlay.AsynchronousParameters.UserApcRoutine = 00000000
Overlay.AsynchronousParameters.UserApcContext = 00000000
Overlay.AllocationSize = 00000000 - 00000000
CancelRoutine = 00000000
UserBuffer = 00000000
&Tail.Overlay.DeviceQueueEntry = 9521ee40
Tail.Overlay.Thread = 00000000
Tail.Overlay.AuxiliaryBuffer = 00000000
Tail.Overlay.ListEntry.Flink = 83352478
Tail.Overlay.ListEntry.Blink = 83352478
Tail.Overlay.CurrentStackLocation = 9521efb4
Tail.Overlay.OriginalFileObject = 00000000
Tail.Apc = 00000000
Tail.CompletionKey = 00000000
cmd flg cl Device File Completion-Context
[0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
>[16, 2] 0 e1 8a08e018 00000000 8329a851-952130d8 Success Error Cancel pending
\Driver\btusbflt nt!IopUnloadSafeCompletion
Args: 00000000 00000001 00000003 00000000
[0, 0] 0 0 00000000 00000000 00000000-a0a05180
Args: 00000000 00000000 00000000 00000000

On Tue, Dec 1, 2009 at 7:48 PM, > wrote:
What does ‘!irp 0x9521ee00 1’ say?

mm


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

doron, mm,

here are your answers:

  1. it is win7 32 build 7600
  2. well it is a new platform based on intel calpella, since this is a new
    platform bringup we expect some hardware/BIOS hiccups, but this one is a
    real complex one. more difficult as it doesnt reproduce on our CRBs, and
    only does on the OEM site in their finished boards integrated with other 3rd
    party hardware with no debug ports what so ever (ITP/ or windbg).
  3. We cannot remove the hardware, this is typically what happens when you
    are a small fish i a large pond owned by other biggies. The OEM always
    blames you for your code, and unless you prove them wrong you are at fault.
    And without debug capabilities we just cannot proceed.

Doron,

i have considered the possibility of memory usage conflictb/w our BIOS based
device and the USB based BT adapter, where we accidentally over write their
memory in pci config space and this causes this device to malfunction.

can you tell us how much time it takes for 9f timer ot fire off? a ball park
would help. but since 9f is firing, i assume we are over writing some apci
code and the power irp cannot be completed for this device, if we had over
written any other memory then probably the BSOD would have been
different…

On Tue, Dec 1, 2009 at 8:35 PM, Doron Holan wrote:

> For your own info, btusbflt is not a microsoft written driver. Also, it
> takes minutes for the 9f timer to fire, so unless your smi takes that long
> too, i think your smi has other effects on the system that manifest in hung
> drivers and perhaps messing up the usb hc state
>
> d
>
>
>
> ------------------------------
> From: A P
> Sent: Tuesday, December 01, 2009 6:22 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] SMI causing BSOD in USBHUB
>
> it is he set power IRP…
>
> 0: kd> !irp 9521ee00 1
> Irp is active with 11 stacks 10 is current (= 0x9521efb4)
> No Mdl: No System Buffer: Thread 00000000: Irp stack trace.
> Flags = 00000000
> ThreadListEntry.Flink = 9521ee10
> ThreadListEntry.Blink = 9521ee10
> IoStatus.Status = 00000000
> IoStatus.Information = 00000000
> RequestorMode = 00000000
> Cancel = 00
> CancelIrql = 0
> ApcEnvironment = 00
> UserIosb = 00000000
> UserEvent = 00000000
> Overlay.AsynchronousParameters.UserApcRoutine = 00000000
> Overlay.AsynchronousParameters.UserApcContext = 00000000
> Overlay.AllocationSize = 00000000 - 00000000
> CancelRoutine = 00000000
> UserBuffer = 00000000
> &Tail.Overlay.DeviceQueueEntry = 9521ee40
> Tail.Overlay.Thread = 00000000
> Tail.Overlay.AuxiliaryBuffer = 00000000
> Tail.Overlay.ListEntry.Flink = 83352478
> Tail.Overlay.ListEntry.Blink = 83352478
> Tail.Overlay.CurrentStackLocation = 9521efb4
> Tail.Overlay.OriginalFileObject = 00000000
> Tail.Apc = 00000000
> Tail.CompletionKey = 00000000
> cmd flg cl Device File Completion-Context
> [0, 0] 0 0 00000000 00000000 00000000-00000000
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
> Args: 00000000 00000000 00000000 00000000
> >[16, 2] 0 e1 8a08e018 00000000 8329a851-952130d8 Success Error Cancel
> pending
> \Driver\btusbflt nt!IopUnloadSafeCompletion
> Args: 00000000 00000001 00000003 00000000
> [0, 0] 0 0 00000000 00000000 00000000-a0a05180
> Args: 00000000 00000000 00000000 00000000
>
>
> On Tue, Dec 1, 2009 at 7:48 PM, wrote:
>
>> What does ‘!irp 0x9521ee00 1’ say?
>>
>> mm
>>
>>
>>
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
> the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

Hmm. I don’t mean to be a downer, but, all things considered - no JTAG emulator or even windbg, different hardware, new hardware, new BIOS, et. c., plus all the sketchy stuff that you’re doing with SMM - this sounds likely to be pretty intractable.

Given what you’re doing in the way of SMM, as Doron mentioned, it’s certainly quite possible that your trashing the system’s/device’s state, or the system requires SMM for some functionality and you’re not emulating it correctly, or there’s weird timing problems, or the new BIOS has problems, et. c., and without the ability to debug, there’s no way that I see to make any general statements about the problem that are useful, other than to say that you need to find a way to debug the actual system in question.

As I mentioned earlier, there are devices that cause this problem that don’t enter SMM, so it perhaps might not be what you’re doing in that regard that’s causing the problem, though I would certainly bet against that myself, but either way, I just don’t see any way to sort it out, given your situation, all the things that you don’t really have control over, and what you’re doing in the first place. If you could at least get a kd session to the actualy OEM board, you could install the CHK build of ACPI, and perhaps get lucky a useful trace/assertion, as well as use windbg’s amli debugger, which might help.

Sorry I don’t have anything better to offer.

Good luck,

mm

mm

i know it is a difficult case (no i refuse to give up and say lost case :slight_smile: )
but thanks for trying to help!

we do have the same calpella CRBs here and everythings works fine on that,
but ofcourse the CRB comes from Intel where was OEMs almost always
add/remove stuff from it…

i guess we gotta do it the real hard way…comment out stuff from BIOS one
chunk at at time, and see if we can narow down…

BTW, is there a way in win7 where the app can actually stop the system from
going to s3, MSDN says no! if we could, then we could try finishing our
IOCTL before releasing the lock which prevents the system from doing power
transitions…

On Tue, Dec 1, 2009 at 9:29 PM, wrote:

> Hmm. I don’t mean to be a downer, but, all things considered - no JTAG
> emulator or even windbg, different hardware, new hardware, new BIOS, et. c.,
> plus all the sketchy stuff that you’re doing with SMM - this sounds likely
> to be pretty intractable.
>
> Given what you’re doing in the way of SMM, as Doron mentioned, it’s
> certainly quite possible that your trashing the system’s/device’s state, or
> the system requires SMM for some functionality and you’re not emulating it
> correctly, or there’s weird timing problems, or the new BIOS has problems,
> et. c., and without the ability to debug, there’s no way that I see to make
> any general statements about the problem that are useful, other than to say
> that you need to find a way to debug the actual system in question.
>
> As I mentioned earlier, there are devices that cause this problem that
> don’t enter SMM, so it perhaps might not be what you’re doing in that regard
> that’s causing the problem, though I would certainly bet against that
> myself, but either way, I just don’t see any way to sort it out, given your
> situation, all the things that you don’t really have control over, and what
> you’re doing in the first place. If you could at least get a kd session to
> the actualy OEM board, you could install the CHK build of ACPI, and perhaps
> get lucky a useful trace/assertion, as well as use windbg’s amli debugger,
> which might help.
>
>
> Sorry I don’t have anything better to offer.
>
> Good luck,
>
> mm
>
>
>
>
>
>
> mm
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

The 9f timeout is in minutes, I think vista had it at 10. Not sure if we made it lower for W7 or not

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of A P
Sent: Tuesday, December 01, 2009 7:20 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] SMI causing BSOD in USBHUB

doron, mm,

here are your answers:

  1. it is win7 32 build 7600
  2. well it is a new platform based on intel calpella, since this is a new platform bringup we expect some hardware/BIOS hiccups, but this one is a real complex one. more difficult as it doesnt reproduce on our CRBs, and only does on the OEM site in their finished boards integrated with other 3rd party hardware with no debug ports what so ever (ITP/ or windbg).
  3. We cannot remove the hardware, this is typically what happens when you are a small fish i a large pond owned by other biggies. The OEM always blames you for your code, and unless you prove them wrong you are at fault. And without debug capabilities we just cannot proceed.

Doron,

i have considered the possibility of memory usage conflictb/w our BIOS based device and the USB based BT adapter, where we accidentally over write their memory in pci config space and this causes this device to malfunction.

can you tell us how much time it takes for 9f timer ot fire off? a ball park would help. but since 9f is firing, i assume we are over writing some apci code and the power irp cannot be completed for this device, if we had over written any other memory then probably the BSOD would have been different…

On Tue, Dec 1, 2009 at 8:35 PM, Doron Holan > wrote:
For your own info, btusbflt is not a microsoft written driver. Also, it takes minutes for the 9f timer to fire, so unless your smi takes that long too, i think your smi has other effects on the system that manifest in hung drivers and perhaps messing up the usb hc state

d

________________________________
From: A P >
Sent: Tuesday, December 01, 2009 6:22 AM
To: Windows System Software Devs Interest List >
Subject: Re: [ntdev] SMI causing BSOD in USBHUB
it is he set power IRP…

0: kd> !irp 9521ee00 1
Irp is active with 11 stacks 10 is current (= 0x9521efb4)
No Mdl: No System Buffer: Thread 00000000: Irp stack trace.
Flags = 00000000
ThreadListEntry.Flink = 9521ee10
ThreadListEntry.Blink = 9521ee10
IoStatus.Status = 00000000
IoStatus.Information = 00000000
RequestorMode = 00000000
Cancel = 00
CancelIrql = 0
ApcEnvironment = 00
UserIosb = 00000000
UserEvent = 00000000
Overlay.AsynchronousParameters.UserApcRoutine = 00000000
Overlay.AsynchronousParameters.UserApcContext = 00000000
Overlay.AllocationSize = 00000000 - 00000000
CancelRoutine = 00000000
UserBuffer = 00000000
&Tail.Overlay.DeviceQueueEntry = 9521ee40
Tail.Overlay.Thread = 00000000
Tail.Overlay.AuxiliaryBuffer = 00000000
Tail.Overlay.ListEntry.Flink = 83352478
Tail.Overlay.ListEntry.Blink = 83352478
Tail.Overlay.CurrentStackLocation = 9521efb4
Tail.Overlay.OriginalFileObject = 00000000
Tail.Apc = 00000000
Tail.CompletionKey = 00000000
cmd flg cl Device File Completion-Context
[0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
>[16, 2] 0 e1 8a08e018 00000000 8329a851-952130d8 Success Error Cancel pending
\Driver\btusbflt nt!IopUnloadSafeCompletion
Args: 00000000 00000001 00000003 00000000
[0, 0] 0 0 00000000 00000000 00000000-a0a05180
Args: 00000000 00000000 00000000 00000000

On Tue, Dec 1, 2009 at 7:48 PM, > wrote:
What does ‘!irp 0x9521ee00 1’ say?

mm


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

It was still 10 minutes in Win7 RC and I’m almost sure it remained in
RTM (don’t exactly remember when saw it last time :slight_smile:

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com http:</http:>]


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Tuesday, December 01, 2009 9:04 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] SMI causing BSOD in USBHUB

The 9f timeout is in minutes, I think vista had it at 10. Not
sure if we made it lower for W7 or not

d

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of A P
Sent: Tuesday, December 01, 2009 7:20 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] SMI causing BSOD in USBHUB

doron, mm,

here are your answers:

  1. it is win7 32 build 7600

  2. well it is a new platform based on intel calpella, since this
    is a new platform bringup we expect some hardware/BIOS hiccups, but this
    one is a real complex one. more difficult as it doesnt reproduce on our
    CRBs, and only does on the OEM site in their finished boards integrated
    with other 3rd party hardware with no debug ports what so ever (ITP/ or
    windbg).

  3. We cannot remove the hardware, this is typically what happens
    when you are a small fish i a large pond owned by other biggies. The OEM
    always blames you for your code, and unless you prove them wrong you are
    at fault. And without debug capabilities we just cannot proceed.

Doron,

i have considered the possibility of memory usage conflictb/w
our BIOS based device and the USB based BT adapter, where we
accidentally over write their memory in pci config space and this causes
this device to malfunction.

can you tell us how much time it takes for 9f timer ot fire off?
a ball park would help. but since 9f is firing, i assume we are over
writing some apci code and the power irp cannot be completed for this
device, if we had over written any other memory then probably the BSOD
would have been different…

On Tue, Dec 1, 2009 at 8:35 PM, Doron Holan
wrote:

For your own info, btusbflt is not a microsoft written driver.
Also, it takes minutes for the 9f timer to fire, so unless your smi
takes that long too, i think your smi has other effects on the system
that manifest in hung drivers and perhaps messing up the usb hc state

d

________________________________

From: A P
Sent: Tuesday, December 01, 2009 6:22 AM
To: Windows System Software Devs Interest List

Subject: Re: [ntdev] SMI causing BSOD in USBHUB

it is he set power IRP…

0: kd> !irp 9521ee00 1
Irp is active with 11 stacks 10 is current (= 0x9521efb4)
No Mdl: No System Buffer: Thread 00000000: Irp stack trace.
Flags = 00000000
ThreadListEntry.Flink = 9521ee10
ThreadListEntry.Blink = 9521ee10
IoStatus.Status = 00000000
IoStatus.Information = 00000000
RequestorMode = 00000000
Cancel = 00
CancelIrql = 0
ApcEnvironment = 00
UserIosb = 00000000
UserEvent = 00000000
Overlay.AsynchronousParameters.UserApcRoutine = 00000000
Overlay.AsynchronousParameters.UserApcContext = 00000000
Overlay.AllocationSize = 00000000 - 00000000
CancelRoutine = 00000000
UserBuffer = 00000000
&Tail.Overlay.DeviceQueueEntry = 9521ee40
Tail.Overlay.Thread = 00000000
Tail.Overlay.AuxiliaryBuffer = 00000000
Tail.Overlay.ListEntry.Flink = 83352478
Tail.Overlay.ListEntry.Blink = 83352478
Tail.Overlay.CurrentStackLocation = 9521efb4
Tail.Overlay.OriginalFileObject = 00000000
Tail.Apc = 00000000
Tail.CompletionKey = 00000000
cmd flg cl Device File Completion-Context
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
>[16, 2] 0 e1 8a08e018 00000000 8329a851-952130d8 Success
Error Cancel pending
\Driver\btusbflt nt!IopUnloadSafeCompletion
Args: 00000000 00000001 00000003 00000000
[0, 0] 0 0 00000000 00000000 00000000-a0a05180

Args: 00000000 00000000 00000000 00000000

On Tue, Dec 1, 2009 at 7:48 PM,
wrote:

What does ‘!irp 0x9521ee00 1’ say?

mm


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other
seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR
Online at http://www.osronline.com/page.cfm?name=ListServer

— NTDEV is sponsored by OSR For our schedule of WDF, WDM,
debugging and other seminars visit: http://www.osr.com/seminars To
unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer



NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars
visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

— NTDEV is sponsored by OSR For our schedule of WDF, WDM,
debugging and other seminars visit: http://www.osr.com/seminars To
unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars
visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer