Date: Mon, 22 Mar 1999 01:51:09 +0000 (GMT) From: Brian Feldman <green@unixhelp.org> To: Greg Lehey <grog@lemis.com> Cc: current@FreeBSD.ORG Subject: Re: Reporting AMD processors (was: CPUT_WT_ALLOC_DISABLE) Message-ID: <Pine.BSF.4.05.9903220147140.6080-100000@zone.syracuse.net> In-Reply-To: <19990322114444.B429@lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 22 Mar 1999, Greg Lehey wrote: > On Monday, 22 March 1999 at 0:54:12 +0000, Brian Feldman wrote: > > Does anyone want a CPU_WT_ALLOC_DISABLE and CPU_WT_ALLOC_ENABLE as separate > > options? I see a couple changes that should be made to the kernel now: > > > > CPU: AMD-K6(tm) 3D processor (300.69-MHz 586-class CPU) > > Origin = "AuthenticAMD" Id = 0x58c Stepping=12 > > Features=0x8021bf<FPU,VME,DE,PSE,TSC,MSR,MCE,CX8,PGE,MMX> > > > > There should be another line, formatted the same, that ALWAYS reports > > CPU_WT_ALLOC info. This will help in debugging problems with certain hardware, > > because on K6-2's I get unreliability with write allocation on. For instance, > > I updated my BIOS lately and observed a crash. On boot -v, I noted that > > the BIOS was kind enough to turn on write allocation, but on a CPU that it > > doesn't seem to work well on. > > What's wrong with leaving the message in the -v output? After all, > it's debugging info. What's wrong is that this is info that should really be printed with the rest of the info. When people send PRs with the dmesg it will show what could possibly be wrong, and with this kind of change would show MORE of what could be wrong. > > > I propose an option to turn OFF write allocation instead of just one to turn > > it on. I also propose the change in CPU info printouts to (more correct spacing > > and extra line): > > > > CPU: AMD-K6(tm) 3D processor (300.69-MHz 586-like CPU) > > Origin = "AuthenticAMD" Id = 0x58c Stepping = 12 > > Features = 0x8021bf <FPU,VME,DE,PSE,TSC,MSR,MCE,CX8,PGE,MMX> > > Write Allocation: Disabled 15-16M Caching Enable: No > > > > The changes would be better spacing, a write allocation line (for whatever > > CPUs are supported, notably the K5, K6, K6-[23]), and changing "class" to > > the more sensible "like" (i.e. a K6 really is 686-class, but being socket 7 > > is 586-like). > > You'd better pass the spacing issue past bde. Certainly it mathes the > other messages. On the whole, I suppose this is reasonable info, but > I wonder if we're not tending towards too much information anyway. I > needed to increase the MSGBUF_SIZE on some machines just to get the > total content of a non-verbose boot. Yeah, I remember System 7's boot having about 1-3 lines, I don't recall exactly. But, having enough output is GOOD! Maybe MSGBUF_SIZE should be increased by default nowadays. > > Greg > -- > See complete headers for address, home page and phone numbers > finger grog@lemis.com for PGP public key > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > Brian Feldman _ __ ___ ___ ___ green@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ ____ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ ____ _____ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9903220147140.6080-100000>