Date: Mon, 5 Aug 2002 09:49:50 -0400 (EDT) From: Andrew Gallatin <gallatin@cs.duke.edu> To: Peter Grehan <peterg@ptree32.com.au> Cc: freebsd-ppc@FreeBSD.ORG Subject: Re: Single-user Message-ID: <15694.33407.146642.70257@grasshopper.cs.duke.edu> In-Reply-To: <3D4DAE9C.FA1B05C9@ptree32.com.au> References: <3D4CF994.7478E7D0@ptree32.com.au> <20020804150712.GA81125@electricjellyfish.net> <3D4DAE9C.FA1B05C9@ptree32.com.au>
index | next in thread | previous in thread | raw e-mail
Peter Grehan writes: > Hi Garrett, > > > well, that was the shortest uptime i can recall ;-) > > Yep, that's not good. > > > tried the iso on my ibook, and got the following results: > > The fact that there's different types of failure, and the alignment > exception, point the finger at a timing and/or cache-related problem :-( > Speaking of timing related problems, I'm seeing something really odd. If I attempt to remount root read/write, the kernel complains: udp: Netconfig database has invalid format Thinking that's odd, I cat /etc/netconfig & I see that it has a large number of (what I assume are) nulls at the front of it: %cat /etc/netconfig ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@st of: # # <network_id> <semantics> <flags> <protofamily> <protoname> \ # <device> <nametoaddr_libs> Note that what I see on the console makes it look like the file starts with the string "st of:", I only see the nulls when looking at the conserver log files. This looks really odd to me .. I'm used to seeing races where you get entire pages of nulls, not just 239 of them. Could this be a cache related problem? Do you see this behaviour on your test machine? This is probably unrelated, but the machine will lock solid under heavy io (dd'ing 100MB file over NFS to /dev/null). I can also panic it by doing 'sysctl -a' on the console: <..> hw.pagesize: 4096 hw.machine_arch: powerpc hw.ata.ata_dma: 1 hw.ata.wc: 1 hw.ata.tags: 0 hw.ata.atapi_dma: 0 hw.pci.enable_io_modes: 1 panic: kmem Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ppc" in the body of the messagehelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15694.33407.146642.70257>
