On Mon, Jun 28, 2010 at 10:25:15AM -0400, Nathaniel W Filardo wrote:
Well, I'm back in the same town as my sparc64 and so csup'd, built, and
rebooted, trying to get more information about the vm object not owned
panic I reported a while ago. To my dismay, I now get this panic, also late
enough in the boot process to be starting up jails:
panic: cheetah_ipi_selected: CPU can't IPI itself
cpuid = 0
KDB: stack backtrace:
panic() at panic+0x1c8
cheetah_ipi_selected() at cheetah_ipi_selected+0x48
tlb_page_demap() at tlb_page_demap+0xdc
pmap_copy_page() at pmap_copy_page+0x4c4
vm_fault() at vm_fault+0x13ec
trap_pfault() at trap_pfault+0x190
trap() at trap+0xd0
-- data access protection tar=0x224b93 sfar=0x224550 sfsr=0x85
%o7=0x4063398c --
userland() at 0x40633830
user trace: trap %o7=0x4063398c
...
And the system hangs; I had to use the ALOM to reboot it.
Sorry to not have more useful news.
Could please give the following patch a try?
http://people.freebsd.org/~marius/sparc64_pin_ipis.diff
If that doesn't fix the above panic I have no clue how this can
happen apart from the per-CPU pages getting corrupted.
Marius
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
