More 1394 and Re: my 1394 driver BSODs someone else's

Mike_Kemp · September 8, 2006, 4:34am

Hi All

Thanks for the tips last week. Been doing a week of experimenting and it has
thrown up a query on the MS 1394 support in general - maybe someone here
wrote it and can comment:

My problem is that when I run the target OS (XP prof unchecked) under debug,
I can’t make isochronous transfers work, so my debugging stalls. At most it
seems a few isoch transmissions take place then nothing. I just wait for a
callback forever. All the asynch stuff works fine.

I’ve tried debugging both with a serial connection and a (separate) 1394
connection on an intel dual core 2.66GHz target, and with 1394 on a 1.7GHz
laptop. Same results.

Debug also stops all the 3rd party 1394 drivers I’ve tried (for various pro
sound interfaces) working in a similar way as far as I can tell.

So I wonder if there is a known issue with 1394 isoch when running under the
debugger?

I haven’t tried any checked OS stuff yet. Is it easy to install just the
checked 1394bus.sys (and where could I find it) and is this just going to
make things slower, i.e. is this likely to tell me anything?

BTW almost everything works fine when target OS is not in debug.

Regarding my driver crashing a 3rd party driver, I’ve decided to throw it
back to their customer support and also requested symbol files but I think
their support is on holiday as no answer so far. So if whoever wrote the RME
Fireface800 driver is reading this, let me know and I can send you more
details of the problem, we may need to work together to fix it.

Thanks, Mike

----- Original Message -----
From: Gary G. Little
To: Windows System Software Devs Interest List
Sent: Saturday, September 02, 2006 5:12 PM
Subject: RE: [ntdev] my 1394 driver BSODs someone else’s

Look for buffer overruns. I’d bet donut you are overrunning an allocated
buffer or stack space. Stepping thru ain’t abad idea and many times the best
way to this type of critter.

Gary

-----Original Message-----
>From: “Mike Kemp”
>Sent: 02-Sep-06 08:00:37
>To: “Windows System Software Devs Interest List”
>Subject: [ntdev] my 1394 driver BSODs someone else’s
>
>Hi Folks
>
>I’ve been doing pretty well with my 1394 driver until I start sharing
the
>bus. As soon as I start pumping asynch data through mine it BSODs in
another
>party’s 1394 driver (fireface.sys). My next step is to single step my
code
>to see if I can identify the point it upsets the other one. In the
meantime
>I’d really appreciate any tips on any more info I can get out of the
>crashdump (below). Incidentally my hardware also forces a bus reset
after
>it’s received its code update so this is another point I’ll be watching
for.
>Any tips / strategies appreciated…
>
>Thank, Mike.
>
>Microsoft (R) Windows Debugger Version 6.6.0007.5
>Copyright (c) Microsoft Corporation. All rights reserved.
>
>
>Loading Dump File [C:\crashdumps\bootlm-ff-2.DMP]
>Kernel Complete Dump File: Full address space is available
>
>Symbol search path is:
>srvc:\localsymbolshttp://msdl.microsoft.com/download/symbols
>Executable search path is:
>C:\Development\lm1394\driver\lm1394\objchk_wxp_x86\i386
>Windows XP Kernel Version 2600 (Service Pack 2) MP (2 procs) Free x86
>

[Message truncated. Tap Edit->Mark for Download to get remaining portion.]

—
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

Mike_Kemp · September 9, 2006, 7:36am

Hi Folks

Sorry to repeat the query but I just need to know if I’m doing something
stupid or if this is a problem known to others.

The key question is:

Does anyone else have problems debugging 1394 drivers when the test machine
is running in debug mode?

As described below my isochronous transmits just won’t run under debug, but
run okay when target is not started in debug mode. This is without any
breakpoints or the like, and seems the same whether I run my checked or free
driver.

Shouldn’t the timing be the same on the target whether or not under debug if
there are no breakpoints? And since my free build does not issue any
debugtraces they should not be affecting the timing either I’d assume?

I’ve seen isoch transmits fail on slow machines before so does the system
1394 hardware driver just give up if any interrupt callback is too slow for
some reason?

Thanks

Mike

----- Original Message -----
From: Mike Kemp
To: Windows System Software Devs Interest List
Sent: Friday, September 08, 2006 9:34 AM
Subject: More 1394 and Re: [ntdev] my 1394 driver BSODs someone else’s