Date: Fri, 15 Nov 2002 17:02:14 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Wesley Morgan <morganw@chemikals.org> Cc: freebsd-current@FreeBSD.org Subject: Re: DISABLE_PSE & DISABLE_PG_G still needed? Message-ID: <3DD59916.22CC2AA3@mindspring.com> References: <20021115190426.G33491-100000@volatile.chemikals.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Wesley Morgan wrote: > Based on this, are you recommending that the DISABLE_* still be used? Will > I never see the problem with 512mb of ram? When Matt Dillon made some of the machdep.c allocation sizes dependent on the physical RAM size, it made the problem much less predictable, based on the amount of RAM, so without sitting down and doing some math to find out exactly where each byte of memory was going, I could not tell you for a given amount of RAM and CPU. What I will tell you is that there is a stair function involved in the amount of RAM you can install, and there is a following function that looks similar, for the allocations made by machdep.c now. The problem will occur when there is a gap between the stair and the follower, e.g.: RAM available | ----. | ....+.. | | . <-- bug triggered | `-+----. | .....+.. | | . <-- bug triggered | `-+----. | .....+.. | | . <-- bug triggered V RAM used -------------------> > > Bosko understands the problem (I have explained it to him under > > non-disclosure), and he has a patch which avoids it without really > > disclosing the problem, which I'm OK with. Using the patch cranks > > So basically, there is a DEFECT in something that either Intel or AMD has > some me (you, everyone) and they will not disclose the defect, honor any > warranties, or provide fixes for the problem? No. The non-disclosure was mine. I am not an Intel/AMD employee; I discovered the defect independently. As far as I know, they are aware of the problem from Microsoft, but have no idea as to its root cause. It is likely that AMD licensed Intel designs, in order for AMD to have the same problem. You should be aware that Microsoft recommends a registry setting that disables the use of 4M pages to work around the problem on customer systems that have the problem. They don't have the PG_G problem that FreeBSD 5.x has, for the same reason that FreeBSD 4.3 didn't have it: serendipity. > How... crappy. Reminds me of the Redhat/DMCA suppressed patch. I think > consumers have a right to know about any defects in something they have > bought. Argue with your congressman; it was a U.S. law that suppressed the patch, in that case. > And I also think that the marketer should assume some liability > for selling defective hardware (even though software makers seem to be > able to get away with it). Even defects that haven't been discovered or characterized by them? Argue with the U.S. Supreme Court and the tobacco industry on that one. Degree of product liability is based on the prior knowledge of potential harm. -- Terry 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?3DD59916.22CC2AA3>