Cannot connect WinDbg to target using 1394 cardbus/pcmcia

Hello,

Config:
_ Host : WinXP SP2, WinDbg 6.12, onboard 1394 4 pin
_ Driver config on host : 1394 interface enabled, 1394 Network disabled.
_ Target: Win7/32 SP1, damaged onboad 1394 4 pin, to replace it : st-lab cardbus combo (1394 4pin and 6pin and 2 USB ports)
_ Driver config on target : damaged onboard 1394 interface disabled, cardbus 1394 interface enabled
_ Cable : FireWire 4-4 (I’ve tried 4-6 as well)

_ boot config on target : debug on, busparams set to parameters indicated on cardbus 1394 interface.

Problem : host won’t connect to target whatever fiddling I do : “Waiting to reconnect…”

I found a possible symptom of the cause of the problem : on the target the cardbus 1394 interface does NOT get banged up with code 31. But if I set busparams to damaged onboard 1394 interface and enabled that interface, the onboad interface DOES get banged up with code 31.

Questions :

  1. Do you think the fact that the cardbus 1394 interface does NOT get banged up with code 31 is a symptom of the cause of the problem ?

  2. If answer to the above (Q1) is yes : do you have an idea why the cardbus 1394 interface does NOT get banged up with code 31 ?
    If answer to the above (Q1) is no : any idea what the root cause could be ?

If you need me to provide you with further info or do more experiment obviously just ask me.

Many thanks in advance for your help,
Michael

Do you disable the on-board (damaged) 1394 *in BIOS setup* ?

–pa

On 12-Jul-2011 14:08, xxxxx@netcourrier.com wrote:

Hello,

Config:
_ Host : WinXP SP2, WinDbg 6.12, onboard 1394 4 pin
_ Driver config on host : 1394 interface enabled, 1394 Network disabled.
_ Target: Win7/32 SP1, damaged onboad 1394 4 pin, to replace it : st-lab cardbus combo (1394 4pin and 6pin and 2 USB ports)
_ Driver config on target : damaged onboard 1394 interface disabled, cardbus 1394 interface enabled
_ Cable : FireWire 4-4 (I’ve tried 4-6 as well)

_ boot config on target : debug on, busparams set to parameters indicated on cardbus 1394 interface.

Problem : host won’t connect to target whatever fiddling I do : “Waiting to reconnect…”

I found a possible symptom of the cause of the problem : on the target the cardbus 1394 interface does NOT get banged up with code 31. But if I set busparams to damaged onboard 1394 interface and enabled that interface, the onboad interface DOES get banged up with code 31.

Questions :

  1. Do you think the fact that the cardbus 1394 interface does NOT get banged up with code 31 is a symptom of the cause of the problem ?

  2. If answer to the above (Q1) is yes : do you have an idea why the cardbus 1394 interface does NOT get banged up with code 31 ?
    If answer to the above (Q1) is no : any idea what the root cause could be ?

If you need me to provide you with further info or do more experiment obviously just ask me.

Many thanks in advance for your help,
Michael

Also XP as the host is in my experience less successful than later OS releases.

Mark Roddy

On Tue, Jul 12, 2011 at 7:08 AM, wrote:
> Hello,
>
> Config:
> _ Host : WinXP SP2, WinDbg 6.12, onboard 1394 4 pin
> _ Driver config on host : 1394 interface enabled, 1394 Network disabled.
> _ Target: Win7/32 SP1, damaged onboad 1394 4 pin, to replace it : st-lab cardbus combo (1394 4pin and 6pin and 2 USB ports)
> _ Driver config on target : damaged onboard 1394 interface disabled, cardbus 1394 interface enabled
> _ Cable : FireWire 4-4 (I’ve tried 4-6 as well)
>
> _ boot config on target : debug on, busparams set to parameters indicated on cardbus 1394 interface.
>
> Problem : host won’t connect to target whatever fiddling I do : “Waiting to reconnect…”
>
> I found a possible symptom of the cause of the problem : on the target the cardbus 1394 interface does NOT get banged up with code 31. But if I set busparams to damaged onboard 1394 interface and enabled that interface, the onboad interface DOES get banged up with code 31.
>
> Questions :
> 1) Do you think the fact that the cardbus 1394 interface does NOT get banged up with code 31 is a symptom of the cause of the problem ?
>
> 2) If answer to the above (Q1) is yes : do you have an idea why the cardbus 1394 interface does NOT get banged up with code 31 ?
> If answer to the above (Q1) is no : any idea what the root cause could be ?
>
> If you need me to provide you with further info or do more experiment obviously just ask me.
>
> Many thanks in advance for your help,
> Michael
>
>
> —
> WINDBG 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
>

Hi Pavel,

Thank you for your answer.

I disabled the on-board (damaged) 1394 controller through the device manager : I right click on it in the device manager, a menu appears and then I click on “Disable” in this menu.
Is it the wrong way of disabling it ?
If yes how do you disable it “in BIOS setup” ?

Cheers

>Also XP as the host is in my experience less successful than later OS releases.

Mark: I will try using Windows 7 / 64 as the host instead of WinXP SP2 but I think the result will be the same. I have some suspicion the problem is on the target side.

Also one thing I must emphasize : debugging the other way round works i.e. with exactly the same hardware config if I debug the Win XP machine with the Windows 7 machine (i.e. target becomes host and host becomes target) it works without problems so I think the hardware is OK.

On 12-Jul-2011 16:52, xxxxx@netcourrier.com wrote:

Hi Pavel,

Thank you for your answer.

I disabled the on-board (damaged) 1394 controller through the device manager : I right click on it in the device manager, a menu appears and then I click on “Disable” in this menu.
Is it the wrong way of disabling it ?
If yes how do you disable it “in BIOS setup” ?

Somewhere in BIOS setup there should be a screen with settings
for on-board devices, like serial & LPT ports, LAN and so on.
If you don’t disable the on-board 1394 in BIOS, the debugger
may use it, rather than the add-on card.

–pa

> Also one thing I must emphasize : debugging the other way round works i.e. with exactly the same hardware config if I debug the Win XP machine with the Windows 7 machine (i.e. target becomes host and host becomes target) it works without problems so I think the hardware is OK.

That is generally faulty logic, as the target and host use completely
different software and drivers.

>Somewhere in BIOS setup there should be a screen with settings for on-board

devices, like serial & LPT ports, LAN and so on. If you don’t disable the
on-board 1394 in BIOS, the debugger may use it, rather than the add-on card.

Unfortunately there is no 1394 related setup option in the BIOS…

> Also one thing I must emphasize : debugging the other way round works >>i.e. with exactly the same hardware config if I debug the Win XP machine
>with the Windows 7 machine (i.e. target becomes host and host becomes
>target) it works without problems so I think the hardware is OK.
That is generally faulty logic, as the target and host use completely different software and drivers.
Yes I’m sure it’s a problem with regard to driver or software but it shows that the cable and all the 1394 related hardware being used seems fine.

On Tue, Jul 12, 2011 at 4:26 PM, wrote:
>>on-board 1394 in BIOS, the debugger may use it, rather than the add-on card.
>
> Unfortunately there is no 1394 related setup option in the BIOS…

You can try to force KD to use given 1394 device with
/BUSPARAMS=.. switch where bus, device and
function can be obtained from device manager (location field for 1394
controller that you want to use).

Kris

>You can try to force KD to use given 1394 device with /BUSPARAMS=.
>. switch where bus, device and function can be obtained
>from device manager (location field for 1394 controller that you want to use).

Hi Kris,

Many thanks for your suggestions but I tried that as well (as mentioned in my OP) but it didn’t make any differences.

I am currently installing a WinDbg instance on a Windows 7 so that I can try Windows 7 as a host instead of WinXP SP2 but I don’t think it will make any differences as I think the problem is on the target.
I’m a bit at lost at what’s going on.
I can see that on the target the cardbus 1394 controller is not banged out so no error code 31 which is a bad sign.
As I have enabled boot logs so I can see the loading sequence:
ntkrnlpa.exe
halmacpi.dll
kd1394.dll
mcupdate_GenuineIntel.dll
pshed.dll
bootvid.dll
etc…

I haven’t seen anything of more interest in the Event Viewer.

Would there be anyway to poke a bit more in depth on the target side to understand why the cardbus 1394 controller is not banged out with code 31 as it should ? Would it be possible to enable some sort of logs for ntkrnlpa.exe halmacpi.dll and kd1394.dll ?

Just to let you know that I made a few tests with a Windows 7 as a host instead of Windows XP SP2 but as expected it does not make any differences : the host won’t connect to the target.

If any of you has any hints to allow me to go further in the investigation please let me know, many thanks.

> If any of you has any hints to allow me to go further in the investigation

please let me know, many thanks.

Try a different brand of 1394? It used to be that WindBg was quite choosy
about precisely which chipset was involved. I learnt to always look for a
TI chipset or better still to just buy the OSR supplied kit.

Your card appears to use a VIA chipset so that might (emphasis on might) be
your issue…

On 13-Jul-2011 19:13, Rod Widdowson wrote:

I learnt to always
look for a TI chipset or better still to just buy the OSR supplied kit.

Your card appears to use a VIA chipset so that might (emphasis on might)
be your issue

Have you seen the post by Joe Ballantyne / June 20, 2011
Subject: remote kernel debugging on windows vista home premium?

Now it appears that TI is not the best model…

–pa

On 12-Jul-2011 19:32, Krzysztof Uchronski wrote:

On Tue, Jul 12, 2011 at 4:26 PM, wrote:
>>> on-board 1394 in BIOS, the debugger may use it, rather than the add-on card.
>>
>> Unfortunately there is no 1394 related setup option in the BIOS…
>
> You can try to force KD to use given 1394 device with
> /BUSPARAMS=.. switch where bus, device and
> function can be obtained from device manager (location field for 1394
> controller that you want to use).
>
> Kris
>

Kris, can you tell, please, how to specify this parameter for win7’s
bcdedit ?

Thanks,
–pa

bcdedit /set debugtype 1394
bcdedit /set channel 43
bcdedit /set testsigning on
bcdedit /debug on

Is this what you’re looking for?

Larry C

>>Try a different brand of 1394? It used to be that WindBg was quite choosy

>about precisely which chipset was involved. I learnt to always look for a TI
>chipset or better still to just buy the OSR supplied kit. Your card appears to
>use a VIA chipset so that might (emphasis on might) be your issue…

Have you seen the post by Joe Ballantyne / June 20, 2011 Subject: remote
kernel debugging on windows vista home premium? Now it appears that TI is
not the best model…

I will try to to get hold of a TI cardbus card and give it a go with my fingers crossed, it might not happen for several weeks though but I will let you know the result.

Kris, can you tell, please, how to specify this parameter for win7’s bcdedit
?

bcdedit /set loadoptions busparams=..