Re: DP2 Fatal Trap
Scott Sipe wrote: I didn't make a backup copy (or mark down the errors) of the bad file or try rebooting which in retrospect would have been a good idea..sorry--I just fixed the file and saved it so I could compile some ports--and that worked. Just FWIW: if it was a transfer error, a backup copy would have been made from cache. As such, it would only be useful in seeing if the data was zeroed. It wouldn't help in the lost word during burst transfer case, or the reboot to test for self-healing case. If it happens again, then: (1) hd the file, and determine if the data was lost, or is merely not displaying because it was zeroed, and (2) reboot to see if it heals. Both of these are very imporant tests. I have an IWILL KK266 motherboard which has a AMI MegaRaid controller and a VIA Apollo KT133A chipset. The FreeBSD drive is primary master ad0 on the via ide line (both Current and Stable are on the same disk). I have a dvd drive and a cdrw on the secondary channel. Then 2 harddisks, one each on the RAID controller (I use the bios to alternate which drives are used for booting--the RAID or the IDE) [ ... other information ... ] OK. None of this resembles hardware for which bugs have been reported to the -current or -hackers mailing lists. This is an affirmation (but not positive confirmation) that the problem is not in the disk controller, disk, or FreeBSD driver. The fact that you'v not had strange probelms with -stable indicates for certain that it's not a disk or controller problem. That leaves other bug (which is what I thought in the first place) or driver bug. I don't think it's a driver bug, but I can't prove it isn't. 1) Yes it happened with a generic kernel straight off the DP2 install CD. OK. No recompiles, fancy driver load directives, etc.. If John Baldwin wants to try and repeat your problem, he *may* need a copy of your rc.conf. DO NOT SEND THIS UNLESS REQUESTED TO DO SO. 2) I had the problems directly off DP2 iso image burned cd install, so can that tell you what you need to know about the cvs date or do you want me to do more? OK; what this means, because there was no tag laid down, and there was not a published checkout datestamp that can be used to duplicate a -current system (according to John, it's a checkout of -CURRENT, hacked to change the name to DP2 for the build), is that I will have to build a known kernel locally, so that I have source tree that duplicated the failure for you. Do you have it booting DP2 enough to replace the kernel, or is it fully reverted to -STABLE at this point? It would be very hard for me to build a full release CDROM ISO image and transfer it, without sending it through the mail. 3) Yes, I'm at college on a fast connection (though with a limited upload) so if you need to I can setup an ftp login for you on my computer. If you can live with just kernel replacements, then if you can set this up, I can give you a kernel which we will then hope *that it fails* as soon as tomorrow, or whenever is convenient, and, after you verify that it does, indeed, fail, then I can do the fix and give you another kernel 2-3 days after that (depending on the porting required, since it involves assmebly language). Let me know. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: DP2 Fatal Trap
On Fri, Nov 22, 2002 at 03:25:15PM -0800, Terry Lambert [EMAIL PROTECTED] wrote: I have now definitive answer for _my_ case and environment. Just finished full package build for my workstation bundle port (92 ports), including XFree-4, KDE3, mozilla-devel and whatnot. It all went very well running kernel which had: DISABLE_PSE enabled DISABLE_PG_Gdisabled Are you interested of the reverse? Can it be that enabling DISABLE_PSE incorporates DISABLE_PG_G somehow? I give up. You guys obviously still think it's a software problem that you can characterize and fix using binary elimination to find the offending code. It's not. You got me wrong. I'm user and do not know and don't want to know about any CPU architecture and bugs. But I've got problems and simply trying to provide any data possible to gather by myself. Either CPU hardware or software bug, fine. You're claiming to know the bug and possible fix, but don't want to publish it, fine. I don't want to think about it because with my knowledge this is going to nowhere and only wasting my time. Things you see above are my results using consistent testing environment, take it or leave it. I'll stick with DISABLE_PSE enabled and DISABLE_PG_G disabled for the time being. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: DP2 Fatal Trap
Vallo Kallaste wrote: You got me wrong. I'm user and do not know and don't want to know about any CPU architecture and bugs. But I've got problems and simply trying to provide any data possible to gather by myself. Either CPU hardware or software bug, fine. You're claiming to know the bug and possible fix, but don't want to publish it, fine. I do not object to publication of code that embodies a workaroun to the poblem, so long as that workaround doesn;t specifically disclose the root cause problem itself. I don't want to think about it because with my knowledge this is going to nowhere and only wasting my time. Things you see above are my results using consistent testing environment, take it or leave it. I'll stick with DISABLE_PSE enabled and DISABLE_PG_G disabled for the time being. I'll make the same offer of a fixed kernel binary, for testing purposes, if you are willing to test two: one to be sure that there is no serendipity involved, and one with the patch. We can skip the first one if you can give me a CVS date or tag to checkout to get code identical to code you have locally, which has the problem. E.g. if you have a local copy of the CVS tree, and you check out with a date tag of, say, last Wednesday, and the kernel you build from that coe ha he problem, then I can check out identical code, patch it, and give you a binary to try. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: DP2 Fatal Trap
On Sat, Nov 23, 2002 at 02:50:36AM -0800, Terry Lambert [EMAIL PROTECTED] wrote: Either CPU hardware or software bug, fine. You're claiming to know the bug and possible fix, but don't want to publish it, fine. I do not object to publication of code that embodies a workaroun to the poblem, so long as that workaround doesn;t specifically disclose the root cause problem itself. Yes I know it from your previous posts. For some reason you don't want that description and analysis of (possible) hardware bug comes public (at this time). Whatever your reasons are, you certainly have your rights for it, no problem from my viewpoint. I don't want to think about it because with my knowledge this is going to nowhere and only wasting my time. Things you see above are my results using consistent testing environment, take it or leave it. I'll stick with DISABLE_PSE enabled and DISABLE_PG_G disabled for the time being. I'll make the same offer of a fixed kernel binary, for testing purposes, if you are willing to test two: one to be sure that there is no serendipity involved, and one with the patch. We can skip the first one if you can give me a CVS date or tag to checkout to get code identical to code you have locally, which has the problem. E.g. if you have a local copy of the CVS tree, and you check out with a date tag of, say, last Wednesday, and the kernel you build from that coe ha he problem, then I can check out identical code, patch it, and give you a binary to try. I'll take this route, at least it can prove something objective (for me). Of course I have to trust you to not send me kernel binary with simply those damned options enabled... or with something interesting in it... The sources the kernel is built are checked out from freebsd.dk.freebsd.org at: *default date=2002.11.21.13.56.00 -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: DP2 Fatal Trap
On 21-Nov-2002 Scott Sipe wrote: On Thursday 21 November 2002 04:26 pm, John Baldwin wrote: Erm, well, PSE and PGE are already disabled in GENERIC on DP2. Hmm. Can you try doing gdb -k kernel.debug in multiuser under DEBUG and see if gdb behaves any better? Another idea might be to use addr2line instead like so: addr2line -e kernel.debug -f 0xc031f044 in gdb the line I get when I do l * is 'No symbol table is loaded. Use the file command.' -- (multiuser too). Am I doing something wrong? addr2line displays: getpeername1 /usr/src/sys/kern/uipc_syscalls.c:1453 Hmm, that would be: if ((error = fgetsock(td, uap-fdes, so, NULL)) != 0) goto done2; (which is in getpeername1()). Hmm. Unless uap was somehow hosed I don't see how else you could be getting a panic (it was a fatal trap 12, right?) -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: DP2 Fatal Trap
On 22-Nov-2002 Terry Lambert wrote: John Baldwin wrote: It's the PSE and PGE, John. Are you sure you won't agree to not disclose, so I can tell you what's happening? Bosko has a patch which he will give you if you ask him for it that (mostly) works around the problem. DP2 shipped with DISABLE_PSE and DISABLE_PG_G in GENERIC. I know because I put them there. And dynamically tuned maxfiles? Or a large static maxfiles? Whatever is the default for GENERIC. The diff between DP2 and the CVS revisions it was branched from is at http://www.FreeBSD.org/~jhb/patches/dp2.patch As you can see, the only changes to GENERIC were to turn off debugging and disable PSE and PG_G for i386. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: DP2 Fatal Trap
On 22-Nov-2002 Terry Lambert wrote: John Baldwin wrote: Is it any help to know that my problems on P4 stopped after enabling DISABLE_PSE? Initially I had both of these enabled, but seems that one is enough. Just FYI. If we can verify that DISABLE_PG_G has no effect then that would be nice. It has an effect: writing CR3 or a TSS resulting in a changed CR3 will not invalidate TLB entries with the G flag set, if PGE is set in CR4. I know what PG_G does, Terry. My question is that if DISABLE_PG_G has no effect on the _problems_ people are having. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: DP2 Fatal Trap
On Fri, Nov 22, 2002 at 10:57:42AM -0500, John Baldwin [EMAIL PROTECTED] wrote: It has an effect: writing CR3 or a TSS resulting in a changed CR3 will not invalidate TLB entries with the G flag set, if PGE is set in CR4. I know what PG_G does, Terry. My question is that if DISABLE_PG_G has no effect on the _problems_ people are having. I have now definitive answer for _my_ case and environment. Just finished full package build for my workstation bundle port (92 ports), including XFree-4, KDE3, mozilla-devel and whatnot. It all went very well running kernel which had: DISABLE_PSE enabled DISABLE_PG_Gdisabled Are you interested of the reverse? Can it be that enabling DISABLE_PSE incorporates DISABLE_PG_G somehow? -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: DP2 Fatal Trap
On Friday 22 November 2002 10:57 am, you wrote: On 21-Nov-2002 Scott Sipe wrote: On Thursday 21 November 2002 04:26 pm, John Baldwin wrote: Erm, well, PSE and PGE are already disabled in GENERIC on DP2. Hmm. Can you try doing gdb -k kernel.debug in multiuser under DEBUG and see if gdb behaves any better? Another idea might be to use addr2line instead like so: addr2line -e kernel.debug -f 0xc031f044 in gdb the line I get when I do l * is 'No symbol table is loaded. Use the file command.' -- (multiuser too). Am I doing something wrong? addr2line displays: getpeername1 /usr/src/sys/kern/uipc_syscalls.c:1453 Hmm, that would be: if ((error = fgetsock(td, uap-fdes, so, NULL)) != 0) goto done2; (which is in getpeername1()). Hmm. Unless uap was somehow hosed I don't see how else you could be getting a panic (it was a fatal trap 12, right?) It was a trap 12, and definitely that address...I think something more overarching must be going on though. I'm able to login with /bin/sh (not csh/tcsh) and so I've been trying various things--I can't compile a kernel because I get bus errors, same with many ports I've been trying to install. pkg_adding seems fine. Any chance this could be acpi related? Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: DP2 Fatal Trap
On 22-Nov-2002 Scott Sipe wrote: On Friday 22 November 2002 10:57 am, you wrote: On 21-Nov-2002 Scott Sipe wrote: On Thursday 21 November 2002 04:26 pm, John Baldwin wrote: Erm, well, PSE and PGE are already disabled in GENERIC on DP2. Hmm. Can you try doing gdb -k kernel.debug in multiuser under DEBUG and see if gdb behaves any better? Another idea might be to use addr2line instead like so: addr2line -e kernel.debug -f 0xc031f044 in gdb the line I get when I do l * is 'No symbol table is loaded. Use the file command.' -- (multiuser too). Am I doing something wrong? addr2line displays: getpeername1 /usr/src/sys/kern/uipc_syscalls.c:1453 Hmm, that would be: if ((error = fgetsock(td, uap-fdes, so, NULL)) != 0) goto done2; (which is in getpeername1()). Hmm. Unless uap was somehow hosed I don't see how else you could be getting a panic (it was a fatal trap 12, right?) It was a trap 12, and definitely that address...I think something more overarching must be going on though. I'm able to login with /bin/sh (not csh/tcsh) and so I've been trying various things--I can't compile a kernel because I get bus errors, same with many ports I've been trying to install. pkg_adding seems fine. Any chance this could be acpi related? I doubt it is acpi related, but you can always disable ACPI by either doing 'unset acpi_load' at the loader prompt or 'set hint.acpi.0.disabled=1' -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: DP2 Fatal Trap
On 22-Nov-2002 Vallo Kallaste wrote: On Fri, Nov 22, 2002 at 10:57:42AM -0500, John Baldwin [EMAIL PROTECTED] wrote: It has an effect: writing CR3 or a TSS resulting in a changed CR3 will not invalidate TLB entries with the G flag set, if PGE is set in CR4. I know what PG_G does, Terry. My question is that if DISABLE_PG_G has no effect on the _problems_ people are having. I have now definitive answer for _my_ case and environment. Just finished full package build for my workstation bundle port (92 ports), including XFree-4, KDE3, mozilla-devel and whatnot. It all went very well running kernel which had: DISABLE_PSE enabled DISABLE_PG_Gdisabled Are you interested of the reverse? Can it be that enabling DISABLE_PSE incorporates DISABLE_PG_G somehow? No, they are completely orthogonal. Thanks for the info though. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: DP2 Fatal Trap
John Baldwin wrote: Is it any help to know that my problems on P4 stopped after enabling DISABLE_PSE? Initially I had both of these enabled, but seems that one is enough. Just FYI. If we can verify that DISABLE_PG_G has no effect then that would be nice. It has an effect: writing CR3 or a TSS resulting in a changed CR3 will not invalidate TLB entries with the G flag set, if PGE is set in CR4. I know what PG_G does, Terry. My question is that if DISABLE_PG_G has no effect on the _problems_ people are having. It can have an effect, if the problem is being exhibited on a P3 or an AMD processor, but not on a P4, unless it has 512M of memory; the jury is out on other memory sizes, after Matt Dillon's dynamic sizing changes (my own suggestion in this area was to conservatively not go overboard in allocating a multiplier of physical memory for page mappings, when doing so would push the space the mappings could cover well over the available physical address space, if you'll remember). I think the processor in the bug report that started this thread was an AMD K6? There really is a CPU bug, John, and the new FreeBSD locore.s code is triggering it. A stock FreeBSD 4.4, for example, will not exhibit this problem, on the same hardware. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: DP2 Fatal Trap
Vallo Kallaste wrote: I have now definitive answer for _my_ case and environment. Just finished full package build for my workstation bundle port (92 ports), including XFree-4, KDE3, mozilla-devel and whatnot. It all went very well running kernel which had: DISABLE_PSE enabled DISABLE_PG_Gdisabled Are you interested of the reverse? Can it be that enabling DISABLE_PSE incorporates DISABLE_PG_G somehow? I give up. You guys obviously still think it's a software problem that you can characterize and fix using binary elimination to find the offending code. It's not. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: DP2 Fatal Trap
Scott Sipe wrote: It was a trap 12, and definitely that address...I think something more overarching must be going on though. I'm able to login with /bin/sh (not csh/tcsh) and so I've been trying various things--I can't compile a kernel because I get bus errors, same with many ports I've been trying to install. pkg_adding seems fine. Any chance this could be acpi related? How about this... o Are you using a GENERIC kernel? o Do you have a timestamp that can be used to check out a /usr/src/sys from CVS that will let me build the same kernel? o Do you have a place I can upload two or more 3/4MB kernel files for you to try? Let's say the answer to all three questions is yes. Assuming I can build you a binary kernel from your sources which then fails on your machine, I believe I can fix the problem, and give you a new binary kernel that fixes it, if it's the problem I think it is. That way, we all win: you get a working kernel, and I get to convince people that the problem is what I said it was in the first place: a CPU bug that has to be specifically worked around. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: DP2 Fatal Trap
Alright, this is pretty frustrating. I've installed DP2 4 or 5 times now (each time reformatting). The first time the installation program acted really weird and didn't do the install correctly. The second time I had weird random core dump problems so that I couldn't even log in. The third time I think was with the trap 12 when I started tcsh...now I reinstalled and it SEEMS to be working fine. At least enough that I was able to compile a custom kernel, and compile most of the gnome suite from ports too (and then to remove it ;). There was ONE problem I had -- one of the g++ include files (limits) had one line that was corrupted and I could fix. the line was like: coint name_more; (somethingl ike that) when it should have been const int name_more10; (line 1710 iirc) so basically it seems like I'm getting random data corruption at random times with random results. fwiw, I'm running stable off the same harddisk as I type this. sorry if this throws a wrench in things again. Scott On Friday 22 November 2002 06:48 pm, Terry Lambert wrote: Scott Sipe wrote: It was a trap 12, and definitely that address...I think something more overarching must be going on though. I'm able to login with /bin/sh (not csh/tcsh) and so I've been trying various things--I can't compile a kernel because I get bus errors, same with many ports I've been trying to install. pkg_adding seems fine. Any chance this could be acpi related? How about this... o Are you using a GENERIC kernel? o Do you have a timestamp that can be used to check out a /usr/src/sys from CVS that will let me build the same kernel? o Do you have a place I can upload two or more 3/4MB kernel files for you to try? Let's say the answer to all three questions is yes. Assuming I can build you a binary kernel from your sources which then fails on your machine, I believe I can fix the problem, and give you a new binary kernel that fixes it, if it's the problem I think it is. That way, we all win: you get a working kernel, and I get to convince people that the problem is what I said it was in the first place: a CPU bug that has to be specifically worked around. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: DP2 Fatal Trap
On 21-Nov-2002 Scott Sipe wrote: First install of DP2 went crazy weird (posted earlier). A minimal install (just the minimal distribution) went fine and I could login but didn't really try anything more than that. Now the install went fine, the boot goes fine (no errors that I can see) but when I log in I get: page fault Fatal Trap 12: Page fault while in kernel mode fault virtual address = 0x89 fault code= supervisor read, page not present IP= 0x8:0xc031f044 SP= 0x10:0xd99a6c98 FP= 0x10:0xd99a6cc0 Code Segment = base 0x0, limit 0xf, type 0x1b = DPL0, pres 1, def32 1, gran 1 (-- not 100% sure of this line) Processor eflags = interrupt enabled, resume, IOPL=0 Current Process = 446 (tcsh) Trap Number = 12 Panic: Page Fault Syncing disks... panic: bwrite: buffer is not busy??? /page fault I have 512MB of ram, AthlonXP cpu, and the swap partition was mounted during boot. I posted my STABLE dmesg, I can do it again if it would help, I can't get my current dmesg (don't have a serial console unless a palm pilot will work somehow) Hmm, is this from a GENERIC kernel? -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: DP2 Fatal Trap
On Thursday 21 November 2002 01:36 pm, John Baldwin wrote: Hmm, is this from a GENERIC kernel? This is from straight from DP2 iso image cd install, X-Developer install, first boot after the install finished, generic kernel etc. Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: DP2 Fatal Trap
On 21-Nov-2002 Scott Sipe wrote: On Thursday 21 November 2002 01:36 pm, John Baldwin wrote: Hmm, is this from a GENERIC kernel? This is from straight from DP2 iso image cd install, X-Developer install, first boot after the install finished, generic kernel etc. Ok, generic kernel is the only really important part. :) Can you do me a favor and see if you have a /boot/kernel.GENERIC/kernel.debug or a /boot/kernel/kernel.debug? If so, can you please do 'gdb -k kernel.debug' and then at the prompt do 'l *instruction pointer' where instruction pointer is the second part of the instruction pointer from the panic message? (I.e., w/o the leading '0x8:' part.) -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: DP2 Fatal Trap
John Baldwin wrote: On 21-Nov-2002 Scott Sipe wrote: On Thursday 21 November 2002 01:36 pm, John Baldwin wrote: Hmm, is this from a GENERIC kernel? This is from straight from DP2 iso image cd install, X-Developer install, first boot after the install finished, generic kernel etc. Ok, generic kernel is the only really important part. :) Can you do me a favor and see if you have a /boot/kernel.GENERIC/kernel.debug or a /boot/kernel/kernel.debug? If so, can you please do 'gdb -k kernel.debug' and then at the prompt do 'l *instruction pointer' where instruction pointer is the second part of the instruction pointer from the panic message? (I.e., w/o the leading '0x8:' part.) It's the PSE and PGE, John. Are you sure you won't agree to not disclose, so I can tell you what's happening? Bosko has a patch which he will give you if you ask him for it that (mostly) works around the problem. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: DP2 Fatal Trap
On 21-Nov-2002 Terry Lambert wrote: John Baldwin wrote: On 21-Nov-2002 Scott Sipe wrote: On Thursday 21 November 2002 01:36 pm, John Baldwin wrote: Hmm, is this from a GENERIC kernel? This is from straight from DP2 iso image cd install, X-Developer install, first boot after the install finished, generic kernel etc. Ok, generic kernel is the only really important part. :) Can you do me a favor and see if you have a /boot/kernel.GENERIC/kernel.debug or a /boot/kernel/kernel.debug? If so, can you please do 'gdb -k kernel.debug' and then at the prompt do 'l *instruction pointer' where instruction pointer is the second part of the instruction pointer from the panic message? (I.e., w/o the leading '0x8:' part.) It's the PSE and PGE, John. Are you sure you won't agree to not disclose, so I can tell you what's happening? Bosko has a patch which he will give you if you ask him for it that (mostly) works around the problem. DP2 shipped with DISABLE_PSE and DISABLE_PG_G in GENERIC. I know because I put them there. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: DP2 Fatal Trap
On Thu, Nov 21, 2002 at 03:03:48PM -0500, John Baldwin [EMAIL PROTECTED] wrote: It's the PSE and PGE, John. Are you sure you won't agree to not disclose, so I can tell you what's happening? Bosko has a patch which he will give you if you ask him for it that (mostly) works around the problem. DP2 shipped with DISABLE_PSE and DISABLE_PG_G in GENERIC. I know because I put them there. Is it any help to know that my problems on P4 stopped after enabling DISABLE_PSE? Initially I had both of these enabled, but seems that one is enough. Just FYI. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: DP2 Fatal Trap
On 21-Nov-2002 Vallo Kallaste wrote: On Thu, Nov 21, 2002 at 03:03:48PM -0500, John Baldwin [EMAIL PROTECTED] wrote: It's the PSE and PGE, John. Are you sure you won't agree to not disclose, so I can tell you what's happening? Bosko has a patch which he will give you if you ask him for it that (mostly) works around the problem. DP2 shipped with DISABLE_PSE and DISABLE_PG_G in GENERIC. I know because I put them there. Is it any help to know that my problems on P4 stopped after enabling DISABLE_PSE? Initially I had both of these enabled, but seems that one is enough. Just FYI. If we can verify that DISABLE_PG_G has no effect then that would be nice. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: DP2 Fatal Trap
On Thursday 21 November 2002 01:58 pm, John Baldwin wrote: On 21-Nov-2002 Scott Sipe wrote: On Thursday 21 November 2002 01:36 pm, John Baldwin wrote: Hmm, is this from a GENERIC kernel? This is from straight from DP2 iso image cd install, X-Developer install, first boot after the install finished, generic kernel etc. Ok, generic kernel is the only really important part. :) Can you do me a favor and see if you have a /boot/kernel.GENERIC/kernel.debug or a /boot/kernel/kernel.debug? If so, can you please do 'gdb -k kernel.debug' and then at the prompt do 'l *instruction pointer' where instruction pointer is the second part of the instruction pointer from the panic message? (I.e., w/o the leading '0x8:' part.) I am able to login as root (sh) in single user mode, but login as root on a normal boot dies (starting tcsh from single user mode traps too). There is a file /boot/kernel/kernel.debug but when I do the gdb command (the l) it gives an error about no symbols, use the file command. I did: cd /boot/kernek gdb -k kernel.debug (in gdb) l *0xc031f044 sorry if this is a stupid mistake on my part. Secondly, I'm able to boot ok from the debug kernel. I did boot DEBUG and I can then login as my user (tcsh) ok and can run X successfully. I imagine I can recompile the kernel, would this be useful? (disabling PSE or the PGE options?) Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: DP2 Fatal Trap
On 21-Nov-2002 Scott Sipe wrote: On Thursday 21 November 2002 01:58 pm, John Baldwin wrote: On 21-Nov-2002 Scott Sipe wrote: On Thursday 21 November 2002 01:36 pm, John Baldwin wrote: Hmm, is this from a GENERIC kernel? This is from straight from DP2 iso image cd install, X-Developer install, first boot after the install finished, generic kernel etc. Ok, generic kernel is the only really important part. :) Can you do me a favor and see if you have a /boot/kernel.GENERIC/kernel.debug or a /boot/kernel/kernel.debug? If so, can you please do 'gdb -k kernel.debug' and then at the prompt do 'l *instruction pointer' where instruction pointer is the second part of the instruction pointer from the panic message? (I.e., w/o the leading '0x8:' part.) I am able to login as root (sh) in single user mode, but login as root on a normal boot dies (starting tcsh from single user mode traps too). There is a file /boot/kernel/kernel.debug but when I do the gdb command (the l) it gives an error about no symbols, use the file command. I did: cd /boot/kernek gdb -k kernel.debug (in gdb) l *0xc031f044 sorry if this is a stupid mistake on my part. Secondly, I'm able to boot ok from the debug kernel. I did boot DEBUG and I can then login as my user (tcsh) ok and can run X successfully. I imagine I can recompile the kernel, would this be useful? (disabling PSE or the PGE options?) Erm, well, PSE and PGE are already disabled in GENERIC on DP2. Hmm. Can you try doing gdb -k kernel.debug in multiuser under DEBUG and see if gdb behaves any better? Another idea might be to use addr2line instead like so: addr2line -e kernel.debug -f 0xc031f044 -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: DP2 Fatal Trap
On Thursday 21 November 2002 04:26 pm, John Baldwin wrote: Erm, well, PSE and PGE are already disabled in GENERIC on DP2. Hmm. Can you try doing gdb -k kernel.debug in multiuser under DEBUG and see if gdb behaves any better? Another idea might be to use addr2line instead like so: addr2line -e kernel.debug -f 0xc031f044 in gdb the line I get when I do l * is 'No symbol table is loaded. Use the file command.' -- (multiuser too). Am I doing something wrong? addr2line displays: getpeername1 /usr/src/sys/kern/uipc_syscalls.c:1453 Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: DP2 Fatal Trap
John Baldwin wrote: Is it any help to know that my problems on P4 stopped after enabling DISABLE_PSE? Initially I had both of these enabled, but seems that one is enough. Just FYI. If we can verify that DISABLE_PG_G has no effect then that would be nice. It has an effect: writing CR3 or a TSS resulting in a changed CR3 will not invalidate TLB entries with the G flag set, if PGE is set in CR4. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
