>> Just to report that i always encountered a panic when building the world >> using an SMP kernel for a CPU with HTT enable (in the BIOS) and the >> sysctl machdep.hlt_logical_cpus set to 0. >> >> Just cvsup'ed (kernel built at Fri Sep 9 18:39:41 CEST 2005). >> See the kernel trace and kernel configuration file attached, please. > Do you have a crash dump for this crash, and a kernel with debugging > symbols? There have been occasional fifo panic reports from SMP boxes > (especially >=4 CPUs doing builds), and I'd like to try to track it down, > but based on prior experience, we'll need some amount of detailed > debugging information to get much further. (I should have say that this box follow the RELENG_6 branch.) Yes, i have a kernel with debugging symbols. Sadly, it seems that the core file is unusable (maybe due to the "write_null" error on notebook disk, see below): /* From a serial console */ db> panic panic: from debugger cpuid = 0 Uptime: 22m7s Dumping 1021 MB (2 chunks) ad0: timeout waiting to issue command ad0: error issueing WRITE_MUL command chunk 0: 1MB (159 pages)ad0: timeout waiting to issue command ad0: error issueing WRITE_MUL command ... ok chunk 1: 1021MB (261360 pages) 1005 989 973 957 941 925 909 893 877 861 845 829 813 797 781 765 749 733 717 701 685 669 653 637 621 605 589 573 557 541 525 509 493 477 461 445 429 413 397 381 365 349 333 317 301 285 269 253 237 221 205 189 173 157 141 125 109 93 77 61 45 29 13 ... ok /* After a reboot */ # cd /var/crash # gzip -d vmcore.18.gz # kgdb /usr/obj/usr/src/sys/BOBOCHE/kernel.debug vmcore.18 kgdb: cannot read IdlePTD I think this timeout is a "side effect" of some energy saving mecanism on the disk. If someone can help me bypassing this timeout problem, i may provide a crash dump ASAP (i will try to reproduce the panic sitting near the machine to get a dump typing `panic' _just_ after the crash). Thanks, -- -jpeg.Received on Fri Sep 09 2005 - 20:17:03 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:43 UTC