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=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTR 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 the kernel.debug corresponding to the kernel you are booting. Is this a custom kernel on the box or are you doing an install? If you are doing an install, try disabling apic support by entering 'set hint.apic.0.disabled=1' at the loader prompt and install that way. Then, once the box is running, build a debug kernel, reproduce the panic, get the instruction pointer address, and then fire
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: 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.. Doug ___ [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.. Doug ___ [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.. Doug ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
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.. Doug ___ [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: 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
