During install, I picked up the following panic shortly after formatting and during chunk 4 of the base dist. :-/ -sc kernel: type 12 trap, code=0 Stopped at _mtx_assert=0x4e: movl 0x1c(%ebx0,%eax db> trace _mtx_asssert(0,1,c0877786,63e,1000) at _mtx_assert+0x4e vm_page_set_invalid(c17f0c30,0,1000,554,0) at vm_page_set_invalid+0x35 brelse(c8010b88,0,ce893b90,c336f480,c3075c80,ce893bc4,346,c0865d8b0 at softdep_dissk_io_initiation+0xc4 spec_xtrategy(c3372924,c8010818,d5b,c0865d8b,c8010818) at spec_xstrategy+0x117 spec_specstrategy(ce893bf8,f4,c179f6d8,4,c8010818) at spec_specstrategy+0x72 ufs_strategy() ufs_vnoperate() bwrite() vfs_bio_awrite() fluusshbufqueues() buf_daemon() fork_exit() fork_trampoline() --- trap 0x1, eip = 0, esp = 0xce893d7c, ebp = 0 --- db> where 0xce893d7c Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xc06a692e stack pointer = 0x10:0xce8937f0 frame pointer = 0x10:0xce8937f4 code segment = bases 0x0, limit 0xfffff, type 0x1b = DBL 0, pres 1 def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 53 (bufdaemon) I didn't copy the args, but it's easy enough for me to reproduce if they're valuable. Bah, If I disable ACPI then I can complete the install. About halfway through the install, however, I get a LOR and the screen quickly trounces most of it. It looked like it was in the VM. Is there any chance we could redirect this kind of stuff to the debugging scree? The LOR looked like it was in the VM. In the release, are we going to disable ACPI by default? I know witness gets disabled, but it may be prudent. -sc -- Sean ChittendenReceived on Wed Dec 10 2003 - 13:16:46 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:33 UTC