Re: remote debugging question
On Monday, 27 September 2004 at 11:07:21 -0700, Jerry Toung wrote: > Good morning list, > I CAN connect to the target but the 'bt" command return #0 0x in ?? > () at the remote. That suggests that you're not connected. > So this is what I am doing, hopefully somebody can tell me what I am > missing. I have 2 laptops same brand and model, both running > 6.0current and same kernel config. > > laptop A panics because of kld I am writing and I want to debug A with laptop > B. > > I reboot A and login and enter CTRL-ATL-ESC to get db> prompt, then enter > 'gdb', then enter 's'. At this point I don't get the db> prompt anymore and A > seems to be in a loop, is that normal? Yes. It's not in a loop, it's waiting for remote gdb. > on laptop B, the only thing I did is get the copy of kernel.debug.A > in /usr/obj/usr/src/sys/MYKERNEL You'll need the sources as well, but that's the next problem, not the one you're experiencing. > I 'cd' to that location an run > kgdb > file kernel.debug.A > set remotebaud 1 That's obviously wrong. This is the bit rate of the serial connection. I don't know what gdb does with such a speed (0.1 bytes per second), but it looks like it ignores it. > set remotebreak 1 > set debug remote 1 > target remote /dev/cuaa0 > > it connects, on B screen (not using X) I see > > Warning: Unable to find dynamic linker breakpoint function. > GDB will be unable to debug shared library initializers > and track explicitly loaded dynamic code. > warning: shared library handler failed to enable breakpoint > Sending packet: $qSymbol ::#5...Ack > Packet Received: > Packet qSymbol (symbol-lookup) is NOT supported This looks like a communication problem. Typically the connection should run at 9600 bps (well, it should run as fast as it can, but we've had problems above that speed). gdb has been significantly changed in the last few months, and it's possible that I'm out of date with some details. It's also possible that this is a bug that crept in there, but I'd first check the bit rates. My personal favourite for remote debugging is firewire. If you have the hardware, you should use it. I'm working on documentation, but there's a fair amount in gdb(4). The format of the fwcontrol and dconschat EUI64s has changed, and the man page needs changing as a result (doc committers please note). It should be obvious, though. > when I type 'bt', that's where I get > #0 0x in ?? () Yes, that's what I thought. > Please somebody advise since I can't do anything with that. And > laptop A is still hanging/loop, and no prompt. If you can't get the connection to work with the correct bit rate, you'll have to reset and reboot it. Greg -- See complete headers for address and phone numbers. pgpDVsAswY2PA.pgp Description: PGP signature
Re: hacking SCO....
I believe DAT is what you want to tell SCO. -- Matt - Original Message - From: "John Von Essen" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, September 27, 2004 6:33 PM Subject: Re: hacking SCO > Well, > > I was able to get a boot/install floppy made. Then install a fresh SCO. > Then create recovery floppies, then boot with recovery floppy and try > to cpio tape data to /mnt. > > However, in both the recover floppy and the real SCO system I have to > configure the tape drive apparently. As of right now, I can not access > the tape device. > > SCO's tape device builder asks what type of tape, is a DDS-2 considered > DAT or 8mm? > > Anyway, I wish I would of thought of the dd args to skip the bad > sectors and continue on. Now that SCO is installed (which took an hour > and a half) I would hate to start over. The drive is really messed up, > dd would copy a couple thousand records, then the drive would start > making a horrendous noise and through an IO error stopping dd. > > You have no idea how much I hate SCO. I feel like I am cheating on my > girlfriend every time I login to this damn box. > > -john > > > On Sep 27, 2004, at 4:15 PM, Doug Russell wrote: > > > > > On Mon, 27 Sep 2004, John Von Essen wrote: > > > >> I have a new replacement 4Gb disk. With a FreeBSD boot CD I did a dd > >> and was able to get the new disk setup with all of the old disks > >> partition maps, boot data, etc.,. The new disk actually boots into SCO > >> but fails because it only has 100Mb or so of data. > > > > Try addingconv=sync,noerrorto your dd line. If most of the > > data > > after the defect(s) can be read, you'll end up with an almost complete > > partition which will likely run. You can then fsck and restore from > > tape. > > > > for example, > > > > dd if=/dev/daX of=/dev/daY conv=sync,noerror bs=128k > > > > Later.. > > > > > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hacking SCO....
Well, I was able to get a boot/install floppy made. Then install a fresh SCO. Then create recovery floppies, then boot with recovery floppy and try to cpio tape data to /mnt. However, in both the recover floppy and the real SCO system I have to configure the tape drive apparently. As of right now, I can not access the tape device. SCO's tape device builder asks what type of tape, is a DDS-2 considered DAT or 8mm? Anyway, I wish I would of thought of the dd args to skip the bad sectors and continue on. Now that SCO is installed (which took an hour and a half) I would hate to start over. The drive is really messed up, dd would copy a couple thousand records, then the drive would start making a horrendous noise and through an IO error stopping dd. You have no idea how much I hate SCO. I feel like I am cheating on my girlfriend every time I login to this damn box. -john On Sep 27, 2004, at 4:15 PM, Doug Russell wrote: On Mon, 27 Sep 2004, John Von Essen wrote: I have a new replacement 4Gb disk. With a FreeBSD boot CD I did a dd and was able to get the new disk setup with all of the old disks partition maps, boot data, etc.,. The new disk actually boots into SCO but fails because it only has 100Mb or so of data. Try addingconv=sync,noerrorto your dd line. If most of the data after the defect(s) can be read, you'll end up with an almost complete partition which will likely run. You can then fsck and restore from tape. for example, dd if=/dev/daX of=/dev/daY conv=sync,noerror bs=128k Later.. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hacking SCO....
Oh, I love replying to my own posts :) On Mon, 27 Sep 2004, Doug Russell wrote: > Try addingconv=sync,noerrorto your dd line. If most of the data > after the defect(s) can be read, you'll end up with an almost complete > partition which will likely run. You can then fsck and restore from tape. > > for example, > > dd if=/dev/daX of=/dev/daY conv=sync,noerror bs=128k Actually, remove the bs=128k from above (force of habit). When you're trying to recover a disk like this, you want the block size to be single sectors (bs=512, the default) so you get every sector that is readable. It's slower, but it'll get you a more complete copy if it only skips 1 sector on an error instead of 256. :) If you know the defects are only in a certain range, you can get creative with the skip directives to dd and copy most of the disk in larger blocks, and go back and do the bad part one sector at a time (very handy when recovering today's large IDE disks). See the dd(1) manpage for more info. Later.. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hacking SCO....
On Mon, 27 Sep 2004, John Von Essen wrote: > I have a new replacement 4Gb disk. With a FreeBSD boot CD I did a dd > and was able to get the new disk setup with all of the old disks > partition maps, boot data, etc.,. The new disk actually boots into SCO > but fails because it only has 100Mb or so of data. Try addingconv=sync,noerrorto your dd line. If most of the data after the defect(s) can be read, you'll end up with an almost complete partition which will likely run. You can then fsck and restore from tape. for example, dd if=/dev/daX of=/dev/daY conv=sync,noerror bs=128k Later.. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
hacking SCO....
Unfortunately, I have inherited a Intel P200 with SCO OpenServer 5.0.4 with a 4Gb SCSI drive. I have to get the machine back up and running. Here is my dilemma and progress: I have a cpio archive on DDS-2 tape that is valid. I have been able to extract files onto a test disk with FreeBSD. The current 4Gb SCSI disk has a hardware problem. Not sure of where, but roughly 120Mb into the desk it starts making noise of fails. I have a new replacement 4Gb disk. With a FreeBSD boot CD I did a dd and was able to get the new disk setup with all of the old disks partition maps, boot data, etc.,. The new disk actually boots into SCO but fails because it only has 100Mb or so of data. The problem is I do not have any SCI media. According to docs, if I had a boot floppy or emergency repair disk, I could boot with that, then mount the partition and cpio extract the data. I tried doing this with a freebsd boot cd, but could mount the SCO filesystem. In fdisk, it comes up as type 99, and I know the SCO is htfs. Does freebsd support any of this? Any ideas on how I should go about this. All I need to do is get that data from the tape onto the disk and I should good to go. SCO is of no help, they cant provide replacement boot floppy, only sell me complete distribution version 5.0.7 for $100. Thanks john ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Dell gx280 and acpi problems
On Monday 27 September 2004 04:34 am, Danny Braniss wrote: > for the short verions goto the end. > > > On Thursday 23 September 2004 04:29 am, Danny Braniss wrote: > > > > On Wednesday 22 September 2004 04:58 am, Danny Braniss wrote: > > > > > could some acpi expert shed some light? > > > > > > > > > > -current panics on boot with BIOS default settings (Suspend Mode is > > > > > S3) fix: set Power Management/Suspend Mode to S1 in BIOS > > > > > > > > > > disabling ACPI on boot is not good, since this box has no PS/2, and > > > > > the USB keyboard/mouse don't work with ACPI off. > > > > > > > > > > the acpi dumps are available from: > > > > > ftp://ftp.cs.huji.ac.il/users/danny/freebsd/gx280 > > > > > > > > > > this is the panic: > > > > > > > > > > > > > > > KDB: debugger backends: ddb > > > > > KDB: current backend: ddb > > > > > Copyright (c) 1992-2004 The FreeBSD Project. > > > > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, > > > > > 1994 The Regents of the University of California. All rights > > > > > reserved. FreeBSD 5.3-BETA5 #14: Tue Sep 21 13:44:32 IDT 2004 > > > > > [EMAIL PROTECTED]:/r+d/obj/new-dev/r+d/5.3/src/sys/HUJI > > > > > Timecounter "i8254" frequency 1193182 Hz quality 0 > > > > > CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (2992.52-MHz 686-class CPU) > > > > > Origin = "GenuineIntel" Id = 0xf34 Stepping = 4 > > > > > > > > > > Features=0xbfebfbff > > > >R,PG E,MC A, > > > > > CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > > > > > Hyperthreading: 2 logical CPUs > > > > > real memory = 1063813120 (1014 MB) > > > > > avail memory = 1031565312 (983 MB) > > > > > kernel trap 12 with interrupts disabled > > > > > > > > > > > > > > > Fatal trap 12: page fault while in kernel mode > > > > > cpuid = 0; apic id = 00 > > > > > fault virtual address = 0x1c > > > > > fault code = supervisor write, page not present > > > > > instruction pointer = 0x8:0xc075dab5 > > > > > stack pointer = 0x10:0xc0c21be0 > > > > > frame pointer = 0x10:0xc0c21cac > > > > > code segment= base 0x0, limit 0xf, type 0x1b > > > > > = DPL 0, pres 1, def32 1, gran 1 > > > > > processor eflags= interrupt enabled, resume, IOPL = 0 > > > > > current process = 0 () > > > > > [thread 0] > > > > > Stopped at vm_fault+0x1b1: lock cmpxchgl %ecx,0x1c(%edx) > > > > > db> trace > > > > > vm_fault(c103a000,c1004000,1,0,c08e36c0) at vm_fault+0x1b1 > > > > > trap_pfault(c0c21d14,0,c1004c29) at trap_pfault+0x184 > > > > > trap(fffd0018,c110,c0c20010,c1004bfd,7) at trap+0x2f1 > > > > > calltrap() at calltrap+0x5 > > > > > --- trap 0xc, eip = 0xc0a18574, esp = 0xc0c21d54, ebp = 0xc0c21d74 > > > > > --- madt_probe(c22264f0,c08bb1f0,c0c21d98,c05e8302,0) at > > > > > madt_probe+0x174 apic_init(0,c1ec00,c1e000,0,c0441225) at > > > > > apic_init+0x47 > > > > > mi_startup() at mi_startup+0x96 > > > > > begin() at begin+0x2c > > > > > > > > Can you do a 'gdb kernel.debug' and then do 'l madt_probe+0x174' and > > > > e-mail the results? > > > > > > I think i'm doing something wrong :-), tip -38400 com1 works fine, > > > Type '?' for a list of commands, 'help' for more detailed help. > > > OK boot -d > > > /boot/kernel/acpi.ko text=0x3fa30 data=0x1be4+0x110c > > > syms=[0x4+0x72a0+0x4+0x9743] > > > GDB: debug ports: sio > > > GDB: current port: sio > > > KDB: debugger backends: ddb gdb > > > KDB: current backend: ddb > > > KDB: enter: Boot flags requested debugger > > > [thread 0] > > > Stopped at kdb_enter+0x2b: nop > > > db> gdb > > > Step to enter the remote GDB backend. > > > > > > backing out of tip via ~. > > > > > > > > > shuttle-2# gdb -b 38400 kernel.debug > > > GNU gdb 6.1.1 [FreeBSD] > > > Copyright 2004 Free Software Foundation, Inc. > > > GDB is free software, covered by the GNU General Public License, and > > > you are welcome to change it and/or distribute copies of it under > > > certain conditions. Type "show copying" to see the conditions. > > > There is absolutely no warranty for GDB. Type "show warranty" for > > > details. This GDB was configured as "i386-marcel-freebsd"... > > > Ready to go. Enter 'tr' to connect to the remote target > > > with /dev/cuaa0, 'tr /dev/cuaa1' to connect to a different port > > > or 'trf portno' to connect to the remote target with the firewire > > > interface. portno defaults to 5556. > > > > > > Type 'getsyms' after connection to load kld symbols. > > > > > > If you're debugging a local system, you can use 'kldsyms' instead > > > to load the kld symbols. That's a less obnoxious interface. > > > (gdb) tr /dev/cuaa0 > > > Ignoring packet error, continuing... > > > Ignoring packet error, continuing... > > > Ignoring packet error, continuing... > > > Couldn't establish connection to remote target > > > Malformed response to offset query, timeout > > > (gdb) > > > > You don't have to do the gdb during the panic. You just need access to
