Date: Wed, 16 Feb 2005 09:38:22 +0100 From: Gerald Heinig <gheinig@syskonnect.de> To: Stephan Uphoff <ups@tree.com> Cc: hackers@freebsd.org Subject: Re: Firewire blues Message-ID: <4213067E.8090204@syskonnect.de> In-Reply-To: <1108496350.7621.1465.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> <4212299F.5020005@syskonnect.de> <1108496350.7621.1465.camel@palm.tree.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4213067E.8090204>