When I boot a Jan 13th or Jan 15th kernel, and then run
/usr/local/etc/cvsup/update.sh to update the local CVS repository, I
get the following panic:

panic: System call lstat returning with 1 locks held
cpuid = 0
KDB: enter: panic
[thread ; pid 1240 tid 10031]
stopped at kdb_enter+0x3d: movq $0,0x41b048(%rip)
db> show alllocks
db> show locks
db> bt
tracing pid 1240 tid 10031 td 0xffffff001c1ad360
kdb_enter() at kdb_enter+0x3d
panic() at panic+0x176
syscalls() at syscalls+0x66d
Xfast_syscalls() at Xfast_syscalls+0xab
--- syscall (0, FreeBSD ELF64, nosys), rip = 0x8009e87ec, rsp=
0x72ec50, rbp = 0x72ed28 ---

----
$ strings /boot/kernel_hp_debug/kernel | grep CURRENT
@(#)FreeBSD 8.0-CURRENT #0: Tue Jan 15 01:30:50 CST 2008
FreeBSD 8.0-CURRENT #0: Tue Jan 15 01:30:50 CST 2008
8.0-CURRENT

$ strings /boot/kernel_hp_debug.old/kernel | grep CURRENT
@(#)FreeBSD 8.0-CURRENT #0: Sun Jan 13 13:12:56 CST 2008
FreeBSD 8.0-CURRENT #0: Sun Jan 13 13:12:56 CST 2008
8.0-CURRENT
---

When I try to look at the core file that gets generated, kgdb is
having problems reading it:

hp010# cd /sys/amd64/compile/DV8135NR
hp010# kgdb -n 14 kernel.debug
kgdb: kvm_read: invalid address (0x1050000)
[GDB will not be able to debug user-mode threads:
/usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"]
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 "amd64-marcel-freebsd".
Ready to go.  Enter 'tr' to connect to the remote target
with /dev/cuad0, 'tr /dev/cuad1' 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.
During symbol reading...location expression too complex...
During symbol reading, unsupported tag: 'DW_TAG_const_type'.
Cannot access memory at address 0x0
(kgdb)

---

A Jan 9th kernel doesn't exhibit this problem with lstat when
/usr/local/etc/cvsup/update.sh is run.

Any suggestions to isolate this problem?

Scot