- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I am working on a multi-threaded NDIS WDM driver. It runs fine on a Dual Xeon based system (with both processors enabled) and has passed an entire suite of tests.
But when Hyperthreading is enabled (even with the second processor disabled), the system hangs.
The problem is - I can't even break in with the debugger (SoftICE - DriverStudio 3.0) at this point - have to cold boot the system.
Are there any special considerations for supporting Hyperthreading in device drivers?
I am working on a multi-threaded NDIS WDM driver. It runs fine on a Dual Xeon based system (with both processors enabled) and has passed an entire suite of tests.
But when Hyperthreading is enabled (even with the second processor disabled), the system hangs.
The problem is - I can't even break in with the debugger (SoftICE - DriverStudio 3.0) at this point - have to cold boot the system.
Are there any special considerations for supporting Hyperthreading in device drivers?
Link Copied
1 Reply
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
gharil -
There should be no special considerations for supporting device drivers on HT-enabled systems. If the code is serial, the extra resources should have no effect. For threaded codes, the rule of thumb is that codes running (correctly) on SMP systems should run on HT.
I've consulted one of our resident Hyper-Threading experts and he is wondering if you have access to and can run your driver on a 4 processor system. Are there any problems with that?
While logically equivalent, a dual processor system and a single processor with HT are quite different. On the latter, many of the resources are shared between the two running threads. Also, the timing characteristics and thread execution interaction can be vastly different between the two systems. This leads us to believe that there may be some problem with the threads in the driver or between the application and the driver that all works together correctly when two physical processors are used, but rears its ugly head when HT is enabled.
What threading model are you programming with, Win32 threads or OpenMP? Have you tried using the MS remote kernel debugger? Even if you are able to use this tool, you still run the risk of throwing the timing off such that the code doesn't hang as expected.
Have you tried running your application and driver through the Intel Thread Checker? If there is some thread contention that is present within the driver, even if it only shows up under certain conditions, Thread Checker will probably find it. Thread Checker still relies on some timing "luck," but it has advanced analysis methods designed specifically for threaded applications that can identify many potential errors that may not have been executed when the program ran. Check out the Intel Thread Checker product page for more details. If you're interested, you might want to be part of the version 2.0 Beta test.
Please post more info or results when you get them.
--clay
There should be no special considerations for supporting device drivers on HT-enabled systems. If the code is serial, the extra resources should have no effect. For threaded codes, the rule of thumb is that codes running (correctly) on SMP systems should run on HT.
I've consulted one of our resident Hyper-Threading experts and he is wondering if you have access to and can run your driver on a 4 processor system. Are there any problems with that?
While logically equivalent, a dual processor system and a single processor with HT are quite different. On the latter, many of the resources are shared between the two running threads. Also, the timing characteristics and thread execution interaction can be vastly different between the two systems. This leads us to believe that there may be some problem with the threads in the driver or between the application and the driver that all works together correctly when two physical processors are used, but rears its ugly head when HT is enabled.
What threading model are you programming with, Win32 threads or OpenMP? Have you tried using the MS remote kernel debugger? Even if you are able to use this tool, you still run the risk of throwing the timing off such that the code doesn't hang as expected.
Have you tried running your application and driver through the Intel Thread Checker? If there is some thread contention that is present within the driver, even if it only shows up under certain conditions, Thread Checker will probably find it. Thread Checker still relies on some timing "luck," but it has advanced analysis methods designed specifically for threaded applications that can identify many potential errors that may not have been executed when the program ran. Check out the Intel Thread Checker product page for more details. If you're interested, you might want to be part of the version 2.0 Beta test.
Please post more info or results when you get them.
--clay
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page