Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 15 Feb 2005 17:55:59 +0100
From:      Gerald Heinig <gheinig@syskonnect.de>
To:        Stephan Uphoff <ups@tree.com>
Cc:        hackers@freebsd.org
Subject:   Re: Firewire blues
Message-ID:  <4212299F.5020005@syskonnect.de>
In-Reply-To: <1108401031.6309.12318.camel@palm.tree.com>
References:  <420731DD.3050206@syskonnect.de> <1107798981.6309.9.camel@palm.tree.com> <42088232.1030001@syskonnect.de> <4208B9C2.6020007@syskonnect.de> <1107888844.6309.221.camel@palm.tree.com> <4209C640.3070502@syskonnect.de> <1107964038.6309.1137.camel@palm.tree.com> <420B938D.2040708@syskonnect.de> <1108352789.6309.9948.camel@palm.tree.com> <4210CF85.6050902@syskonnect.de>  <4210D4BA.9060109@syskonnect.de> <1108401031.6309.12318.camel@palm.tree.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

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.

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
> 
> 
> 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4212299F.5020005>