Re: DISABLE_PSE DISABLE_PG_G still needed?

2002-11-16 Thread Vallo Kallaste
On Fri, Nov 15, 2002 at 03:50:47PM -0800, Terry Lambert
[EMAIL PROTECTED] wrote:

  Sorry, this can be CPU specific, but I'm not sure. I'll try to
  reproduce it on my home P2 system and P3-SMP lying under my desk at
  work.
 
 How much memory do these systems have?

The P4 system has 128MB, P3-SMP has 512MB and P2 has 380MB. As you
can guess, the P4 system has been given by my employer, hehe ;-)
-- 

Vallo Kallaste
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: DISABLE_PSE DISABLE_PG_G still needed?

2002-11-16 Thread Vallo Kallaste
On Fri, Nov 15, 2002 at 11:45:16AM -0500, Robert Watson
[EMAIL PROTECTED] wrote:

 Does this apply generally to all P4's, or just a subset?  If all, it may
 be we want to add a P4-workaround to GENERIC so that P4's work better ouf
 of the box.  If it's a select few, I wonder if there's some way to test
 for the problem early in the boot...
 
 One of the recurring themes here has (a) been P4 processors, and (b) been
 a fear that because of timing changes introduced by the DISABLE_FOO flags,
 the real bug is still there, but less visible in the tests people are
 running.

Certainly doesn't happen on my P3-500 SMP system. I've finished two
buildworlds without any problems. As everyone seems to think that it
happens only on P4's, I'm not going to try it on old P2-400.
That's all I can provide, happens reliably (for months now) on my P4
and doesn't happen with P3. 5.0-RELEASE definitely needs a fix.
-- 

Vallo Kallaste
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: DISABLE_PSE DISABLE_PG_G still needed?

2002-11-15 Thread Terry Lambert
Vallo Kallaste wrote:
 
 Hi
 
 The kernel compiled from yesterday sources and with the
 abovementioned options disabled will not finish make -j2 buildworld
 on P4. Dies with bus error:
 
 /usr/src/lib/libc/gen/termios.c: In function `tcgetpgrp':
 /usr/src/lib/libc/gen/termios.c:104: internal error: Bus error
 Please submit a full bug report,
 with preprocessed source if appropriate.
 See URL:http://www.gnu.org/software/gcc/bugs.html for instructions.
 
 Are those options still needed? They are commented out in NOTES and
 shouldn't be necessary, right?

What happens if you add those options?  Does it still crash?

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: DISABLE_PSE DISABLE_PG_G still needed?

2002-11-15 Thread Vallo Kallaste
On Fri, Nov 15, 2002 at 02:59:32AM -0800, Terry Lambert
[EMAIL PROTECTED] wrote:

  The kernel compiled from yesterday sources and with the
  abovementioned options disabled will not finish make -j2 buildworld
  on P4. Dies with bus error:
  
  /usr/src/lib/libc/gen/termios.c: In function `tcgetpgrp':
  /usr/src/lib/libc/gen/termios.c:104: internal error: Bus error
  Please submit a full bug report,
  with preprocessed source if appropriate.
  See URL:http://www.gnu.org/software/gcc/bugs.html for instructions.
  
  Are those options still needed? They are commented out in NOTES and
  shouldn't be necessary, right?
 
 What happens if you add those options?  Does it still crash?

Just finished '-j2 buildworld' and it did well with kernel which had
the options enabled. Therefore I suppose that those options are
still absolutely necessary to make use of -current system. These
options should be uncommented in NOTES and added to GENERIC
otherwise new users will be trapped. All old -current users have
those options probably enabled for a while, that's because there are
no complaints. Actually, I'm not complaining, just testing out the
bad things I have encountered in the near past. This darn
5.0-RELEASE is nearing way too fast considering the state of
-current today.
-- 

Vallo Kallaste
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: DISABLE_PSE DISABLE_PG_G still needed?

2002-11-15 Thread Wesley Morgan
On Fri, 15 Nov 2002, Vallo Kallaste wrote:

 Just finished '-j2 buildworld' and it did well with kernel which had
 the options enabled. Therefore I suppose that those options are
 still absolutely necessary to make use of -current system. These

This may be a bit overstated. I removed those options from my kernel a few
weeks ago and have no problems at all. Are you certain the problem is not
specific to a particular CPU?

 options should be uncommented in NOTES and added to GENERIC
 otherwise new users will be trapped. All old -current users have
 those options probably enabled for a while, that's because there are
 no complaints. Actually, I'm not complaining, just testing out the
 bad things I have encountered in the near past. This darn
 5.0-RELEASE is nearing way too fast considering the state of
 -current today.

While I am just a small, small voice among many... I must agree :/... The
few things that remain broken for me would be enough to sour testing 5.0
if I wasnt used to working around it.


-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: DISABLE_PSE DISABLE_PG_G still needed?

2002-11-15 Thread Vallo Kallaste
On Fri, Nov 15, 2002 at 09:55:52AM -0500, Wesley Morgan
[EMAIL PROTECTED] wrote:

 On Fri, 15 Nov 2002, Vallo Kallaste wrote:
 
  Just finished '-j2 buildworld' and it did well with kernel which had
  the options enabled. Therefore I suppose that those options are
  still absolutely necessary to make use of -current system. These
 
 This may be a bit overstated. I removed those options from my kernel a few
 weeks ago and have no problems at all. Are you certain the problem is not
 specific to a particular CPU?

Sorry, this can be CPU specific, but I'm not sure. I'll try to
reproduce it on my home P2 system and P3-SMP lying under my desk at
work.
-- 

Vallo Kallaste
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: DISABLE_PSE DISABLE_PG_G still needed?

2002-11-15 Thread John Baldwin

On 15-Nov-2002 Wesley Morgan wrote:
 On Fri, 15 Nov 2002, Vallo Kallaste wrote:
 
 Just finished '-j2 buildworld' and it did well with kernel which had
 the options enabled. Therefore I suppose that those options are
 still absolutely necessary to make use of -current system. These
 
 This may be a bit overstated. I removed those options from my kernel a few
 weeks ago and have no problems at all. Are you certain the problem is not
 specific to a particular CPU?

It only happens with P4's.  I haven't seen it locally on a p4 test machine
at work that I have built test releases on.  Also, it would be nice to see
if just adding one of the options fixed the problems.  As for NOTES, those
options should not be enabled in NOTES as they would defeat the purpose of
LINT since they disable code.

-- 

John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve!  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: DISABLE_PSE DISABLE_PG_G still needed?

2002-11-15 Thread Robert Watson

On Fri, 15 Nov 2002, John Baldwin wrote:

 On 15-Nov-2002 Wesley Morgan wrote:
  On Fri, 15 Nov 2002, Vallo Kallaste wrote:
  
  Just finished '-j2 buildworld' and it did well with kernel which had
  the options enabled. Therefore I suppose that those options are
  still absolutely necessary to make use of -current system. These
  
  This may be a bit overstated. I removed those options from my kernel a few
  weeks ago and have no problems at all. Are you certain the problem is not
  specific to a particular CPU?
 
 It only happens with P4's.  I haven't seen it locally on a p4 test
 machine at work that I have built test releases on.  Also, it would be
 nice to see if just adding one of the options fixed the problems.  As
 for NOTES, those options should not be enabled in NOTES as they would
 defeat the purpose of LINT since they disable code. 

Does this apply generally to all P4's, or just a subset?  If all, it may
be we want to add a P4-workaround to GENERIC so that P4's work better ouf
of the box.  If it's a select few, I wonder if there's some way to test
for the problem early in the boot...

One of the recurring themes here has (a) been P4 processors, and (b) been
a fear that because of timing changes introduced by the DISABLE_FOO flags,
the real bug is still there, but less visible in the tests people are
running.

Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED]  Network Associates Laboratories



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: DISABLE_PSE DISABLE_PG_G still needed?

2002-11-15 Thread Vallo Kallaste
On Fri, Nov 15, 2002 at 11:45:16AM -0500, Robert Watson
[EMAIL PROTECTED] wrote:

  It only happens with P4's.  I haven't seen it locally on a p4 test
  machine at work that I have built test releases on.  Also, it would be
  nice to see if just adding one of the options fixed the problems.  As
  for NOTES, those options should not be enabled in NOTES as they would
  defeat the purpose of LINT since they disable code. 
 
 Does this apply generally to all P4's, or just a subset?  If all, it may
 be we want to add a P4-workaround to GENERIC so that P4's work better ouf
 of the box.  If it's a select few, I wonder if there's some way to test
 for the problem early in the boot...
 
 One of the recurring themes here has (a) been P4 processors, and (b) been
 a fear that because of timing changes introduced by the DISABLE_FOO flags,
 the real bug is still there, but less visible in the tests people are
 running.

To add even more variables into the mix, this particular machine
seems to be running Celeron processor based on P4 core. The case has
Celeron Inside sticker and althought I haven't opened the case I
tend to believe what the sticker tells, because port/misc/cpuid
agrees. The local PC assembly company is well known and trusted
also. Kernel identifies the CPU as P4, no surprise because CPU core
is P4 based.

dmesg:

Copyright (c) 1992-2002 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-CURRENT #0: Fri Nov 15 18:14:03 EET 2002
[EMAIL PROTECTED]:/usr/home/vallo/Vallo
Preloaded elf kernel /boot/kernel/kernel at 0xc04f.
Preloaded elf module /boot/kernel/acpi.ko at 0xc04f00a8.
Timecounter i8254  frequency 1193182 Hz
Timecounter TSC  frequency 1699953860 Hz
CPU: Pentium 4 (1699.95-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0xf13  Stepping = 3
  
Features=0x3febfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM
real memory  = 132382720 (126 MB)
avail memory = 123219968 (117 MB)
Initializing GEOMetry subsystem
Pentium Pro MTRR support enabled
VESA: v3.0, 832k memory, flags:0x1, mode table:0xc0421d20 (140)
VESA: Brookdale-G Graphics Chip Accelerated VGA BIOS
npx0: math processor on motherboard
npx0: INT 16 interface
acpi0: INTEL  D845GLLY on motherboard
Using $PIR table, 9 entries at 0xc00f3d20
acpi0: power button is handled as a fixed feature programming model.
Timecounter ACPI-fast  frequency 3579545 Hz
acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0
acpi_cpu0: CPU on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
 initial configuration 
 before setting priority for links 
 before fixup boot-disabled links -
 after fixup boot-disabled links --
 arbitrated configuration -
pci0: ACPI PCI bus on pcib0
agp0: Intel 82845 (i845 GMCH) SVGA controller mem 
0xffa8-0xffaf,0xf000-0xf7ff irq 11 at device 2.0 on pci0
agp0: detected 892k stolen memory
agp0: aperture size is 128M
pci0: serial bus, USB at device 29.0 (no driver attached)
pci0: serial bus, USB at device 29.1 (no driver attached)
pci0: serial bus, USB at device 29.2 (no driver attached)
pcib1: ACPI PCI-PCI bridge at device 30.0 on pci0
 initial configuration 
 before setting priority for links 
 before fixup boot-disabled links -
 after fixup boot-disabled links --
 arbitrated configuration -
pci1: ACPI PCI bus on pcib1
fxp0: Intel Pro/100 Ethernet port 0xdc00-0xdc3f mem 0xff8ff000-0xff8f irq 11 at 
device 8.0 on pci1
fxp0: Ethernet address 00:03:47:29:85:a5
inphy0: i82562ET 10/100 media interface on miibus0
inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
isab0: PCI-ISA bridge at device 31.0 on pci0
isa0: ISA bus on isab0
atapci0: Intel ICH4 ATA100 controller port 0xffa0-0xffaf,0-0x3,0-0x7,0-0x3,0-0x7 at 
device 31.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
pci0: serial bus, SMBus at device 31.3 (no driver attached)
pcm0: Intel 82801DB (ICH4) port 0xe080-0xe0bf,0xe400-0xe4ff mem 
0xffa7f800-0xffa7f8ff,0xffa7fc00-0xffa7fdff irq 5 at device 31.5 on pci0
acpi_button0: Sleep Button on acpi0
sio0 port 0x3f8-0x3ff irq 4 on acpi0
sio0: type 16550A
sio1 port 0x2f8-0x2ff irq 3 on acpi0
sio1: type 16550A
fdc0: Enhanced floppy controller (i82077, NE72065 or clone) port 
0x3f7,0x3f4-0x3f5,0x3f2-0x3f3,0x3f0-0x3f1 irq 6 drq 2 on acpi0
fdc0: FIFO enabled, 8 bytes threshold
fd0: 1440-KB 3.5 drive on fdc0 drive 0
ppc0 port 0x378-0x37f irq 7 on acpi0
ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode
ppi0: Parallel I/O on ppbus0
atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0
atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0
kbd0 at atkbd0
sc0: System 

Re: DISABLE_PSE DISABLE_PG_G still needed?

2002-11-15 Thread Terry Lambert
Vallo Kallaste wrote:
  This may be a bit overstated. I removed those options from my kernel a few
  weeks ago and have no problems at all. Are you certain the problem is not
  specific to a particular CPU?
 
 Sorry, this can be CPU specific, but I'm not sure. I'll try to
 reproduce it on my home P2 system and P3-SMP lying under my desk at
 work.

How much memory do these systems have?

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: DISABLE_PSE DISABLE_PG_G still needed?

2002-11-15 Thread Terry Lambert
Robert Watson wrote:
 On Fri, 15 Nov 2002, John Baldwin wrote:
  It only happens with P4's.  I haven't seen it locally on a p4 test
  machine at work that I have built test releases on.  Also, it would be
  nice to see if just adding one of the options fixed the problems.  As
  for NOTES, those options should not be enabled in NOTES as they would
  defeat the purpose of LINT since they disable code.
 
 Does this apply generally to all P4's, or just a subset?  If all, it may
 be we want to add a P4-workaround to GENERIC so that P4's work better ouf
 of the box.  If it's a select few, I wonder if there's some way to test
 for the problem early in the boot...
 
 One of the recurring themes here has (a) been P4 processors, and (b) been
 a fear that because of timing changes introduced by the DISABLE_FOO flags,
 the real bug is still there, but less visible in the tests people are
 running.

The amount of RAM will also affect it.  It can also happen on P3's
and AMD K6's.  It is a CPU bug related to the use of 4M pages.

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
the amount of base memory required for a minimal FreeBSD up to 16M,
and loads the kernel at 4M, instead of 1M.  This avoids the problem
on purpose that the older FreeBSD locore.s used to avoid by accident.

The alternative is to take up to a 15% performance hit by not using
4M and global pages, or to revert the locore.s code so that it does
not tickle the hardware bug.

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: DISABLE_PSE DISABLE_PG_G still needed?

2002-11-15 Thread Wesley Morgan
Based on this, are you recommending that the DISABLE_* still be used? Will
I never see the problem with 512mb of ram?

On Fri, 15 Nov 2002, Terry Lambert wrote:

 The amount of RAM will also affect it.  It can also happen on P3's
 and AMD K6's.  It is a CPU bug related to the use of 4M pages.

Let's not dance around the issue. Software has bugs. Hardware has defects.

 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?

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. 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).

But this is getting way off topic :P

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: DISABLE_PSE DISABLE_PG_G still needed?

2002-11-15 Thread Terry Lambert
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 [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message