Firewire blues

[Gerald Heinig]

Stephan Uphoff wrote:
> On Tue, 2005-02-15 at 11:55, Gerald Heinig wrote:
> 
>>Hi Stephan,
>>
>>I'm happy to say that it's working now :)
>>I grabbed a 5.3-STABLE snapshot to get the updated kgdb and completely 
>>reinstalled my 5.3-RELEASE system. I compiled the kernel using your 
>>options and it worked straight away.
>>I have no idea why it didn't work before. It must be some boot variable 
>>I set way back whenever.
>>Thanks very much indeed for helping me out with this! I really 
>>appreciate your patience.
>>
> 
> 
> Great.
> 
> 
>>By the way, did you ever get the non-cooperative debugging working? I 
>>tried that, but it doesn't work, complaining about invalid hex digits.
>>That's the debug method I'm _really_ interested in, because it enables 
>>you to debug hangs and freezes.
> 
> 
> Never used it before - but is works for me.
> 
> debug# fwcontrol
> 2 devices (info_len=2)
> node           EUI64          status
>    0  00-11-06-66-40-00-82-34      0
>    1  00-11-06-66-40-00-18-dd      1
> 
> debug# sysctl -w hw.firewire.fwmem.eui64_hi=0x00110666
> hw.firewire.fwmem.eui64_hi: 1073775156 -> 1115750
> 
> debug# sysctl -w hw.firewire.fwmem.eui64_lo=0x400018dd
> hw.firewire.fwmem.eui64_lo: 0 -> 1073748189
> 
> debug# kgdb -c /dev/fwmem0.0 kernel.debug

Damn. I was using the -r option. Of course it should be -c. D'oh.. :(
Anyway, it works fine for me too now.

Stephan, you da man!! :)

Cheers,
Gerald

> 
> 
> 
>>Anyway, enough for now. Thanks again.
>>
>>Cheers,
>>Gerald
>>
>>Stephan Uphoff wrote:
>>
>>>On Mon, 2005-02-14 at 11:41, Gerald Heinig wrote:
>>>
>>>
>>>>Gerald Heinig wrote:
>>>>
>>>>
>>>>>Hi Stephan,
>>>>>
>>>>>first off, thanks very much for your continuing help on this. It's very 
>>>>>much appreciated.
>>>>>
>>>>>I compiled a kernel with exactly the same options that you cited below. 
>>>>>I tried booting it and it stops before the kernel probe routines and 
>>>>>waits for the FireWire GDB connect.
>>>>>I can't understand how you managed to reboot the target machine without 
>>>>>it entering the debugger and waiting for the remote gdb attach. My 
>>>>>machine refuses to do anything else.
>>>>>I tried unsetting boot_ddb and boot_gdb in the loader, as well as 
>>>>>clearing the -d and -g flags in the boot_flags variable. No deal, it 
>>>>>still stops and waits for the remote gdb attach.
>>>
>>>
>>>I did change anything at the bootstrap loader.
>>>
>>>The tests were done 15 minutes after a complete new install (wiped the
>>>disk) from a 5.3 CD.
>>>
>>>You may want to take another look at you boot flags / variables.
>>>
>>>
>>>
>>>
>>>>>When I try to attach from the debug machine, gdb complains about 
>>>>>operation not supported.
>>>>>
>>>>>Also, I don't understand how your command line
>>>>>
>>>>>kgdb -r :5555 -t 11-22-33-44-55...
>>>>
>>>>D'oh...
>>>>What I meant was:
>>>>
>>>>kgdb -r :5555 kernel.debug
>>>>
>>>><sigh>. Time to go home I suppose...
>>>>
>>>>
>>>>
>>>>>can work. I just get
>>>>>
>>>>>':5555: no such file or directory'
>>>>>
>>>>>when I try that. The kgdb manpage also states that it needs a device 
>>>
>>>
>>>
>>>Just looked at the CVS repository.
>>>Seems like you need to update to a newer kgdb on the debug station.
>>>The old version does not understand tcp ports and needs devices.
>>>
>>>If this is not an option then you can probably use some pty to tcp
>>>forwarding program.
>>>The debugger would connect to the pty and the forwarding program opens a
>>>connection to dconschat and forwards data in both directions.
>>>( Sorry -  used such a program a long, long time ago but can't remember
>>>the name )
>>>
>>>
>>>Stephan