Date: Thu, 15 Oct 1998 13:17:05 +1000 From: Tony Griffiths <tonyg@OntheNet.com.au> To: freebsd-alpha@FreeBSD.ORG Subject: Re: kernel traps on boot.. Message-ID: <36256931.3E4CD672@OntheNet.com.au> References: Your message of "14 Oct 1998 18:59:18 PDT." <8767dmoaa1.fsf@netbsd1.cygnus.com> <199810150228.TAA28194@kithrup.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Sean Eric Fagan wrote: > > In article <199810150217.TAA06537.kithrup.freebsd.freebsd-arch.alpha@implode.root.com> you write: > > We have lot's of diagnostic code in FreeBSD to panic on various internal > >inconsistencies. An unaligned reference, in my experiance, is usually not > >something to be worried about. Not true! Basically, the compiler that generated the code believes that the object being fetched is aligned when it isn't! This indicates a "potential" serious problem which definitely should not be ignored!!! Either the programmer is confused about what they are doing or something has stomped on a pointer... Either way, a dump should be taken so that the problem can be analysed and hopefully fixed. Perhaps the only caveat I would put on this is to use a sysctl flag to determine whether a panic/dump is taken or a fixup done, thus allowing a knowledgable person to make a hopefully informed decision on the severity of the error and the potential consequences of ignoring it! > An unaligned reference on an Alpha is considerably more severe than an > unaligned reference on the x86. True... Literally 100's of instructions are required to handle an unaligned memory access fault. Even if the compiler "knows" that the object is unaligned, it takes 10-11 instructions to load a 32-bit int compared to a single LDL v0,x instruction for aligned data! > It is, in fact, roughly akin to dereferencing NULL. Not quite _THAT_ bad but almost... Tony To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?36256931.3E4CD672>