The drivers are in-the-box. While I’m not the 1394 expert here, my experience has been that using these is a plug-and-play activity generally. Unfortunately, like many things with the PC this can depend upon configuration (like in the BIOS) and situations like this ARE frustrating (been there, done that.)
The Windows translations of the real errors is also of marginal value (sort of like translating the original error message from Redmond-English into Tolkein-F?anoran to EU-French and then into London-English it seems to lose SOMETHING in the translation.) From a quick check these two errors seem to mean:
A device attached to the system is not functioning.
And
The environment is incorrect.
The former I’ve seen before as an issue when filter drivers don’t work properly (one I recently debugged on one of my own systems turns out that the upper filter driver was listed but the service key was just gone - that was a nasty situation, like some other driver had mostly uninstalled it.) The latter is a mystery (REG_EXPAND_SZ type key?) that I’ve not personally seen before. Unfortunately, neither one sounds like a hardware issue, both sound like software/configuration issues. Is there anything more informative in the event log? I find that often the real original error is embedded within the event log message (gee, back to the original Redmond-English error!) That doesn’t mean it just solves the problem.
Or another take - imagine you are trying to use these boards NOT for debugging but rather for talking to a 1394 peripheral (e.g., a hard drive.) Once you can do that, the debugging really SHOULD “just work”. Well, that applies to the debugger machine at least.
In fact, if the kernel debugger is taking over the 1394 port on the test machine, I wouldn’t expect the in-box driver to attach to it (since the kernel debugger piece is built into the OS and seizes the 1394 port long before the 1394 driver gets a chance to seize it.) So perhaps it is working “as expected” on the test box (I’ll have to look and see what happens on my own test box with this setup).
Maybe one of the team here (who are more familiar with the 1394 device) can provide further insight.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
Looking forward to seeing you at the next OSR File Systems class in Boston, MA April 18-21, 2006 (note new date - MS scheduled plugfest the same week again.)
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Bruno van Dooren
Sent: Sunday, March 19, 2006 8:51 AM
To: ntdev redirect
Subject: [ntdev] problem with OSR 1394 boards
Hi,
I am trying to set up a debugger connection to debug my USB driver.
I have bought 2 of the 1394 boards available from OSR.
On my test machine (HP VECTRA P3 with XP checked SP2) the driver fails to
load. the error code is 31.
On my other machine (dual P3 with XP SP2 latest patches) the driver cannot
start. the error code is 10.
Is there anything I need to install or configure before I can use those
boards? There was no CD in the box when I got them, so I assumed the drivers
shipped with XP.
One thing to mention is that my 2nd machine also has an onboard TI host
controller. that seems to wok fine. I disabled it because I thought it
interfered with the PCI board, but that was not the case.
Any idea what might be the problem?
–
Kind regards,
Bruno van Dooren
xxxxx@hotmail.com
Remove only “_nos_pam”
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer