On Fri, 18.02.2005 at 23:18:50 -0500, Stephan Uphoff wrote:
> Strange - are you sure that you have not accidentally have
> options DCONS_FORCE_CONSOLE=1
> in your config file?
> ( Or forgot to config or make depend after removing it?)
I made a new kernel (make kernel) and since I never set
On Fri, 2005-02-18 at 18:39, Ulrich Spoerlein wrote:
> On Fri, 18.02.2005 at 14:32:36 -0500, Stephan Uphoff wrote:
> > Changing a line in the function dcons_modevent() (File
> > sys/dev/dcons/dcons.c or dcons_os.c depending on your sources) should
> > help you.
> >
> > #if __FreeBSD_version >= 50
On Fri, 18.02.2005 at 14:32:36 -0500, Stephan Uphoff wrote:
> Changing a line in the function dcons_modevent() (File
> sys/dev/dcons/dcons.c or dcons_os.c depending on your sources) should
> help you.
>
> #if __FreeBSD_version >= 50
> - if (ret == 0) {
> + if (ret
On Wed, 2005-02-16 at 06:02, Ulrich Spoerlein wrote:
> On Sun, 13.02.2005 at 22:46:29 -0500, Stephan Uphoff wrote:
> > +device dcons
> > +device dcons_crom
> >
> > Then configured/compiled/installed the GENERIC.debug kernel.
> > Copied the kernel.debug file in the GENERIC.debug compile directory to
Stephan Uphoff wrote:
On Wed, 2005-02-16 at 07:19, Gerald Heinig wrote:
Gerald Heinig wrote:
Ulrich Spoerlein wrote:
[stuff snipped]
Other than that, remote gdb is working. Poking inside the fwmem itself
is however not working, I get this after setting eui64_{hi,lo}
% kgdb -c /dev/fwmem0.0 kernel.d
On Wed, 2005-02-16 at 07:19, Gerald Heinig wrote:
> Gerald Heinig wrote:
> > Ulrich Spoerlein wrote:
> [stuff snipped]
> >>
> >> Other than that, remote gdb is working. Poking inside the fwmem itself
> >> is however not working, I get this after setting eui64_{hi,lo}
> >> % kgdb -c /dev/fwmem0.0 ke
On Wed, 16.02.2005 at 13:10:22 +0100, Gerald Heinig wrote:
> >When dcons_crom is loaded (module or not) and I boot my system (laptop),
> >I only get the "kernel output" on screen. All the other output (starting
> >from Mounting root from ufs) goes to the firewire console.
>
> I don't know whether t
Gerald Heinig wrote:
Ulrich Spoerlein wrote:
[stuff snipped]
Other than that, remote gdb is working. Poking inside the fwmem itself
is however not working, I get this after setting eui64_{hi,lo}
% kgdb -c /dev/fwmem0.0 kernel.debug
...
0x in ?? ()
I got this as well. In my case I assumed i
Ulrich Spoerlein wrote:
On Sun, 13.02.2005 at 22:46:29 -0500, Stephan Uphoff wrote:
+device dcons
+device dcons_crom
Then configured/compiled/installed the GENERIC.debug kernel.
Copied the kernel.debug file in the GENERIC.debug compile directory to
the debug station and rebooted the target machine.
On Sun, 13.02.2005 at 22:46:29 -0500, Stephan Uphoff wrote:
> +device dcons
> +device dcons_crom
>
> Then configured/compiled/installed the GENERIC.debug kernel.
> Copied the kernel.debug file in the GENERIC.debug compile directory to
> the debug station and rebooted the target machine.
I tried th
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 a
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
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 vari
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 a
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 conn
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 understa
On Thu, 2005-02-10 at 12:02, Gerald Heinig wrote:
> Stephan Uphoff wrote:
> > Once I linked in dcons, dcons_crom and firewire into the kernel
> > everything worked. (I think only dcons is really needed - maybe a link
> > set issue?)
> > I only used the gdb stub method.
> >
> > Can you send me your
Stephan Uphoff wrote:
Once I linked in dcons, dcons_crom and firewire into the kernel
everything worked. (I think only dcons is really needed - maybe a link
set issue?)
I only used the gdb stub method.
Can you send me your dmesg? (After you linked the dcons stuff into the
kernel)
Another thing: wha
Stephan Uphoff wrote:
On Wed, 2005-02-09 at 03:13, Gerald Heinig wrote:
Stephan Uphoff wrote:
There are two ways using kgdb to debug a target with firewire.
The first way basically replaces the slow serial cable for
communication to the remote target gdb stub. The second way uses
the remote DMA
On Wed, 2005-02-09 at 03:13, Gerald Heinig wrote:
> Stephan Uphoff wrote:
> > There are two ways using kgdb to debug a target with firewire.
> > The first way basically replaces the slow serial cable for communication
> > to the remote target gdb stub.
> > The second way uses the remote DMA capabil
Stephan Uphoff wrote:
There are two ways using kgdb to debug a target with firewire.
The first way basically replaces the slow serial cable for communication
to the remote target gdb stub.
The second way uses the remote DMA capabilities of firewire to directly
read memory of the target WITHOUT usin
On Tue, 2005-02-08 at 08:08, Gerald Heinig wrote:
> Gerald Heinig wrote:
> >>
> >>
> >> I recall some issues with gdb and firewire as a module that may or may
> >> not be fixed.
> >> I recommend to put the dcons into the kernel to avoid any problems.
> >
> >
> > I tried that too. There are a few
Gerald Heinig wrote:
I recall some issues with gdb and firewire as a module that may or may
not be fixed.
I recommend to put the dcons into the kernel to avoid any problems.
I tried that too. There are a few additional flags that can be set. Of
particular interest are DCONS_FORCE_CONSOLE and DCO
Stephan Uphoff wrote:
On Mon, 2005-02-07 at 04:16, Gerald Heinig wrote:
Hi all,
I'm having problems getting two 5.3-RELEASE boxes to communicate over
firewire.
I'm using two VIA Vt-6306 -based cards which are correctly recognised at
boot-time.
I've loaded the dcons and dconschat modules and obta
On Mon, 07.02.2005 at 10:16:13 +0100, Gerald Heinig wrote:
> [dcons disconnected (get crom failed)]
> [...]
> BTW, I'm trying to set up remote debugging with gdb to debug a kernel hang.
As Stephan already suggested, try fwcontrol -r (probably on both hosts).
This worked for me. And good luck in ge
On Mon, 2005-02-07 at 04:16, Gerald Heinig wrote:
> Hi all,
>
> I'm having problems getting two 5.3-RELEASE boxes to communicate over
> firewire.
> I'm using two VIA Vt-6306 -based cards which are correctly recognised at
> boot-time.
>
> I've loaded the dcons and dconschat modules and obtained
Hi all,
I'm having problems getting two 5.3-RELEASE boxes to communicate over
firewire.
I'm using two VIA Vt-6306 -based cards which are correctly recognised at
boot-time.
I've loaded the dcons and dconschat modules and obtained both firewire
addresses via fwcontrol.
When I try to set up a conn
27 matches
Mail list logo
