Date: Tue, 9 Aug 2005 01:31:42 +0200 From: Chris Gilbert <Chris@LainOS.org> To: freebsd-current@freebsd.org Subject: Re: Panic during install on Sparc64 - Only with large HDD Message-ID: <200508090131.43056.Chris@LainOS.org> In-Reply-To: <200508071916.50197.Chris@LainOS.org> References: <1123369733.852.12.camel@shumai.marcuscom.com> <42F6388A.9000208@savvis.net> <200508071916.50197.Chris@LainOS.org>
next in thread | previous in thread | raw e-mail | index | archive | help
As a follow up to my previous mail, I've got a bit more info on the crash. It seems to not be specific to the large disklabel after all, but it still only happens with the very large disk. (200GB) Here are the messages I receive: ad0: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=77596976 ad0: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=77597072 It spews these during the newfs stage. Then, during file copying I get the following panic: /mnt/usr: bad dir ino 756855 at offset 0: mangled entry panic: ufs_dirbad: bad dir cpuid = 0 KDB: enter: panic [thread pid 79 tid 100038 ] Stopped at kdb_enter+0x3c: ta %xcc, 1 db> Any takers? On Sunday 07 August 2005 19:16, Chris Gilbert wrote: > Hi there, > > Since FreeBSD 5.2 I've been seeing these strange intermittent "DMA WRITE > TIMEOUT" messages. They seemed to go away for a time, but now they have > returned again on my sparc64 machine. > > I do not get them with my 40GB disk, but I do get them with my new 200GB > IDE disk. I have tested said disk with my x86 6-CURRENT machine and it > seems to be okay. > > Also, it starts spewing these timeout messages when it tries to > disklabel/newfs a large disk slice in the installer. It successfully > creates a few 2, 5, and 15 GB slices, then fails on my ~135GB slice. > > The installer continued past these timeout messages, then while copying > files during the install (post slice/label) it broke into the debugger. > > I have the machine hooked up via a serial cable, and waiting in the > debugger. > > It is accessible via a shell if someone would like to look into it. > > I've seen other reports of the same, or a similar error, and I would really > like to see it fixed. So, if there is anything I can do to help please ask. > > Here is the stack trace from the debugger: > > db> trace > Tracing pid 77 tid 100035 td 0xfffff8006ed3fc80 > panic() at panic+0x16c > ufs_dirbad() at ufs_dirbad+0x38 > ufs_lookup() at ufs_lookup+0x2fc > VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0xb4 > vfs_cache_lookup() at vfs_cache_lookup+0xd8 > VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xc0 > lookup() at lookup+0x55c > namei() at namei+0x41c > kern_lstat() at kern_lstat+0x24 > lstat() at lstat+0x14 > syscall() at syscall+0x2dc > -- syscall (190, FreeBSD ELF64, lstat) %o7=0x11980c -- > userland() at 0x20d308 > user trace: trap %o7=0x11980c > pc 0x20d308, sp 0x7fdffffdab1 > pc 0x11dd2c, sp 0x7fdffffdcb1 > pc 0x100470, sp 0x7fdffffdd71 > pc 0x100194, sp 0x7fdffffde31 > pc 0, sp 0x7fdffffdef1 > done > db> -- Thanks, Chris (Lance) Gilbert Ph: +16239791302 (UTC -0700)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200508090131.43056.Chris>