Hi,
We have a dual Xeon machine with 4GB of RAM; when running with an SMP
kernel (either the SMP one with RH7 or a freshly compiled 2.4.0-test10) it
is INCREDIBLY slow. e.g. X takes a minute to start the server - I haven't
bothered waiting for anything more. Just from a command line it feels
very unresponsive (e.g. just something like date takes a second or
so). With a UP kernel it is very responsive and fast.
Any ideas what is going on? It has a single SCSI disc hung off a Symbios
SCSI controller.
I've included /proc/pci, /proc/interrupt /proc/cpuinfo and the kernel
config (2.4.0-test10).
Any help appreciated.
Dave
PCI devices found:
Bus 0, device 8, function 0:
SCSI storage controller: Symbios Logic Inc. (formerly NCR) 53c810 (rev 35).
IRQ 58.
Master Capable. Latency=128. Min Gnt=8.Max Lat=64.
I/O at 0x2000 [0x20ff].
Non-prefetchable 32 bit memory at 0xfa001000 [0xfa0010ff].
Bus 0, device 10, function 0:
VGA compatible controller: Cirrus Logic GD 5480 (rev 35).
Master Capable. Latency=64. Min Gnt=2.Max Lat=10.
Prefetchable 32 bit memory at 0xfc000000 [0xfdffffff].
Non-prefetchable 32 bit memory at 0xfa000000 [0xfa000fff].
Bus 0, device 11, function 0:
PIC: Intel Corporation 683053 Programmable Interrupt Device (rev 0).
Master Capable. No bursts. Min Gnt=8.Max Lat=8.
Bus 0, device 12, function 0:
ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 2).
Bus 0, device 12, function 1:
IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 1).
Master Capable. Latency=64.
I/O at 0x2420 [0x242f].
Bus 0, device 12, function 2:
USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 1).
IRQ 54.
Master Capable. Latency=64.
I/O at 0x2400 [0x241f].
Bus 0, device 12, function 3:
Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 2).
Bus 0, device 16, function 0:
Host bridge: Intel Corporation 450NX - 82451NX Memory & I/O Controller (rev 3).
Bus 1, device 2, function 0:
Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 8).
IRQ 20.
Master Capable. Latency=128. Min Gnt=8.Max Lat=56.
Non-prefetchable 32 bit memory at 0xfe004000 [0xfe004fff].
I/O at 0x3800 [0x383f].
Non-prefetchable 32 bit memory at 0xfe100000 [0xfe1fffff].
Bus 1, device 3, function 0:
SCSI storage controller: Symbios Logic Inc. (formerly NCR) 53c896 (rev 1).
IRQ 57.
Master Capable. Latency=128. Min Gnt=17.Max Lat=64.
I/O at 0x3000 [0x30ff].
Non-prefetchable 64 bit memory at 0xfe005000 [0xfe0053ff].
Non-prefetchable 64 bit memory at 0xfe000000 [0xfe001fff].
Bus 1, device 3, function 1:
SCSI storage controller: Symbios Logic Inc. (formerly NCR) 53c896 (#2) (rev 1).
IRQ 56.
Master Capable. Latency=128. Min Gnt=17.Max Lat=64.
I/O at 0x3400 [0x34ff].
Non-prefetchable 64 bit memory at 0xfe005400 [0xfe0057ff].
Non-prefetchable 64 bit memory at 0xfe002000 [0xfe003fff].
Bus 0, device 18, function 0:
Host bridge: Intel Corporation 450NX - 82454NX/84460GX PCI Expander Bridge (rev 4).
Master Capable. Latency=128.
Bus 0, device 19, function 0:
Host bridge: Intel Corporation 450NX - 82454NX/84460GX PCI Expander Bridge (#2) (rev 4).
Master Capable. Latency=128.
CPU0 CPU1
0: 62363 82485 IO-APIC-edge timer
1: 328 305 IO-APIC-edge keyboard
2: 0 0 XT-PIC cascade
9: 0 0 IO-APIC-edge acpi
12: 46 19 IO-APIC-edge PS/2 Mouse
13: 0 0 XT-PIC fpu
20: 1419 1550 IO-APIC-level eth0
56: 14 16 IO-APIC-level sym53c8xx
57: 1944 1943 IO-APIC-level sym53c8xx
58: 15 12 IO-APIC-level sym53c8xx
NMI: 144672 144672
LOC: 144659 144658
ERR: 0
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 7
model name : Pentium III (Katmai)
stepping : 3
cpu MHz : 550.000155
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
sep_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 3
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 pn mmx fxsr xmm
bogomips : 1097.73
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 7
model name : Pentium III (Katmai)
stepping : 3
cpu MHz : 550.000155
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
sep_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 3
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 pn mmx fxsr xmm
bogomips : 1097.73
#
# Automatically generated make config: don't edit
#
CONFIG_X86=y
CONFIG_ISA=y
# CONFIG_SBUS is not set
CONFIG_UID16=y
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODVERSIONS=y
CONFIG_KMOD=y
#
# Processor type and features
#
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
CONFIG_M686FXSR=y
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_X86_TSC=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_PGE=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_FXSR=y
CONFIG_X86_XMM=y
# CONFIG_TOSHIBA is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set
# CONFIG_NOHIGHMEM is not set
CONFIG_HIGHMEM4G=y
# CONFIG_HIGHMEM64G is not set
CONFIG_HIGHMEM=y
CONFIG_MTRR=y
CONFIG_SMP=y
CONFIG_HAVE_DEC_LOCK=y
#
# General setup
#
CONFIG_NET=y
# CONFIG_VISWS is not set
CONFIG_X86_IO_APIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_NAMES=y
# CONFIG_MCA is not set
CONFIG_HOTPLUG=y
#
# PCMCIA/CardBus support
#
CONFIG_PCMCIA=y
CONFIG_CARDBUS=y
CONFIG_SYSVIPC=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
CONFIG_KCORE_ELF=y
# CONFIG_KCORE_AOUT is not set
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=y
CONFIG_PM=y
CONFIG_ACPI=y
# CONFIG_ACPI_INTERPRETER is not set
# CONFIG_ACPI_S1_SLEEP is not set
# CONFIG_APM is not set
#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set
#
# Parallel port support
#
# CONFIG_PARPORT is not set
#
# Plug and Play configuration
#
CONFIG_PNP=y
CONFIG_ISAPNP=y
#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_DEV_XD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_LOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_RAM is not set
#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set
#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
# CONFIG_NETLINK is not set
# CONFIG_NETFILTER is not set
# CONFIG_FILTER is not set
CONFIG_UNIX=y
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_INET_ECN is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_IPV6 is not set
# CONFIG_KHTTPD is not set
# CONFIG_ATM is not set
#
#
#
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_DECNET is not set
# CONFIG_BRIDGE is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_LLC is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_FASTROUTE is not set
# CONFIG_NET_HW_FLOWCONTROL is not set
#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set
#
# Telephony Support
#
# CONFIG_PHONE is not set
#
# ATA/IDE/MFM/RLL support
#
# CONFIG_IDE is not set
# CONFIG_BLK_DEV_IDE_MODES is not set
# CONFIG_BLK_DEV_HD is not set
#
# SCSI support
#
CONFIG_SCSI=y
#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
CONFIG_SD_EXTRA_DEVS=40
# CONFIG_CHR_DEV_ST is not set
CONFIG_BLK_DEV_SR=y
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_SR_EXTRA_DEVS=2
CONFIG_CHR_DEV_SG=y
#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
CONFIG_SCSI_DEBUG_QUEUES=y
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
# CONFIG_SCSI_LOGGING is not set
#
# SCSI low-level drivers
#
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_7000FASST is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AHA152X is not set
# CONFIG_SCSI_AHA1542 is not set
# CONFIG_SCSI_AHA1740 is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_IN2000 is not set
# CONFIG_SCSI_AM53C974 is not set
# CONFIG_SCSI_MEGARAID is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_CPQFCTS is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_DTC3280 is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_EATA_DMA is not set
# CONFIG_SCSI_EATA_PIO is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_GENERIC_NCR5380 is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_NCR53C406A is not set
# CONFIG_SCSI_NCR53C7xx is not set
# CONFIG_SCSI_NCR53C8XX is not set
CONFIG_SCSI_SYM53C8XX=y
CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS=4
CONFIG_SCSI_NCR53C8XX_MAX_TAGS=32
CONFIG_SCSI_NCR53C8XX_SYNC=20
# CONFIG_SCSI_NCR53C8XX_PROFILE is not set
# CONFIG_SCSI_NCR53C8XX_IOMAPPED is not set
CONFIG_SCSI_NCR53C8XX_PQS_PDS=y
# CONFIG_SCSI_NCR53C8XX_SYMBIOS_COMPAT is not set
# CONFIG_SCSI_PAS16 is not set
# CONFIG_SCSI_PCI2000 is not set
# CONFIG_SCSI_PCI2220I is not set
# CONFIG_SCSI_PSI240I is not set
# CONFIG_SCSI_QLOGIC_FAS is not set
# CONFIG_SCSI_QLOGIC_ISP is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_SEAGATE is not set
# CONFIG_SCSI_SIM710 is not set
# CONFIG_SCSI_SYM53C416 is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_T128 is not set
# CONFIG_SCSI_U14_34F is not set
# CONFIG_SCSI_ULTRASTOR is not set
# CONFIG_SCSI_DEBUG is not set
#
# PCMCIA SCSI adapter support
#
# CONFIG_SCSI_PCMCIA is not set
#
# IEEE 1394 (FireWire) support
#
# CONFIG_IEEE1394 is not set
#
# I2O device support
#
# CONFIG_I2O is not set
#
# Network device support
#
CONFIG_NETDEVICES=y
#
# ARCnet devices
#
# CONFIG_ARCNET is not set
CONFIG_DUMMY=y
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_NET_SB1000 is not set
#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_LANCE is not set
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_NET_VENDOR_RACAL is not set
# CONFIG_AT1700 is not set
# CONFIG_DEPCA is not set
# CONFIG_HP100 is not set
# CONFIG_NET_ISA is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_AC3200 is not set
# CONFIG_APRICOT is not set
# CONFIG_CS89x0 is not set
# CONFIG_DE4X5 is not set
# CONFIG_TULIP is not set
# CONFIG_DGRS is not set
# CONFIG_DM9102 is not set
CONFIG_EEPRO100=y
# CONFIG_EEPRO100_PM is not set
# CONFIG_LNE390 is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_NE3210 is not set
# CONFIG_ES3210 is not set
# CONFIG_RTL8129 is not set
# CONFIG_8139TOO is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_WINBOND_840 is not set
# CONFIG_NET_POCKET is not set
#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_SK98LIN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set
#
# Token Ring devices
#
# CONFIG_TR is not set
# CONFIG_NET_FC is not set
# CONFIG_RCPCI is not set
# CONFIG_SHAPER is not set
#
# Wan interfaces
#
# CONFIG_WAN is not set
#
# PCMCIA network device support
#
# CONFIG_NET_PCMCIA is not set
#
# Amateur Radio support
#
# CONFIG_HAMRADIO is not set
#
# IrDA (infrared) support
#
# CONFIG_IRDA is not set
#
# ISDN subsystem
#
# CONFIG_ISDN is not set
#
# Old CD-ROM drivers (not SCSI, not IDE)
#
# CONFIG_CD_NO_IDESCSI is not set
#
# Input core support
#
# CONFIG_INPUT is not set
#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_SERIAL=y
# CONFIG_SERIAL_CONSOLE is not set
# CONFIG_SERIAL_EXTENDED is not set
# CONFIG_SERIAL_NONSTANDARD is not set
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256
#
# I2C support
#
# CONFIG_I2C is not set
#
# Mice
#
# CONFIG_BUSMOUSE is not set
CONFIG_MOUSE=y
CONFIG_PSMOUSE=y
# CONFIG_82C710_MOUSE is not set
# CONFIG_PC110_PAD is not set
#
# Joysticks
#
#
# Game port support
#
#
# Gameport joysticks
#
#
# Serial port support
#
#
# Serial port joysticks
#
#
# Parallel port joysticks
#
#
# Parport support is needed for parallel port joysticks
#
# CONFIG_QIC02_TAPE is not set
#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_INTEL_RNG is not set
# CONFIG_NVRAM is not set
# CONFIG_RTC is not set
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
# CONFIG_AGP is not set
# CONFIG_DRM is not set
CONFIG_PCMCIA_SERIAL=y
#
# PCMCIA character device support
#
# CONFIG_PCMCIA_SERIAL_CS is not set
# CONFIG_PCMCIA_SERIAL_CB is not set
#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set
#
# File systems
#
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=y
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_BFS_FS is not set
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
# CONFIG_UMSDOS_FS is not set
CONFIG_VFAT_FS=y
# CONFIG_EFS_FS is not set
CONFIG_JFFS_FS_VERBOSE=0
# CONFIG_CRAMFS is not set
# CONFIG_RAMFS is not set
CONFIG_ISO9660_FS=y
# CONFIG_JOLIET is not set
# CONFIG_MINIX_FS is not set
# CONFIG_NTFS_FS is not set
# CONFIG_HPFS_FS is not set
CONFIG_PROC_FS=y
# CONFIG_DEVFS_FS is not set
CONFIG_DEVPTS_FS=y
# CONFIG_QNX4FS_FS is not set
# CONFIG_ROMFS_FS is not set
CONFIG_EXT2_FS=y
# CONFIG_SYSV_FS is not set
# CONFIG_UDF_FS is not set
# CONFIG_UFS_FS is not set
#
# Network File Systems
#
# CONFIG_CODA_FS is not set
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
CONFIG_NFSD=y
CONFIG_NFSD_V3=y
CONFIG_SUNRPC=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_SMB_FS=y
# CONFIG_SMB_NLS_DEFAULT is not set
# CONFIG_NCP_FS is not set
#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
CONFIG_NLS=y
#
# Native Language Support
#
CONFIG_NLS_DEFAULT="iso8859-1"
# CONFIG_NLS_CODEPAGE_437 is not set
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_ISO8859_1 is not set
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_UTF8 is not set
#
# Console drivers
#
CONFIG_VGA_CONSOLE=y
# CONFIG_VIDEO_SELECT is not set
# CONFIG_MDA_CONSOLE is not set
#
# Frame-buffer support
#
# CONFIG_FB is not set
#
# Sound
#
# CONFIG_SOUND is not set
#
# USB support
#
# CONFIG_USB is not set
#
# Kernel hacking
#
CONFIG_MAGIC_SYSRQ=y
--
/------------------------------------------------------------------\
| Dr. David Alan Gilbert | Work:[email protected] +44-161-286-2000 Ex258|
| -------- G7FHJ --------|---------------------------------------- |
| Home: [email protected] http://www.treblig.org |
\------------------------------------------------------------------/
On Thu, 2 Nov 2000, Dr. David Gilbert wrote:
> I've included /proc/pci, /proc/interrupt /proc/cpuinfo and the kernel
> config (2.4.0-test10).
> CONFIG_MTRR=y
I bet it's the mtrr bugs. Take a look in /proc/mtrr. Someone suggested
that if you disable the cachable settings in the BIOS for the BIOS/VGA/ROM
regions, the bug can be avoided.
-ben
On Thu, 2 Nov 2000 [email protected] wrote:
> On Thu, 2 Nov 2000, Dr. David Gilbert wrote:
>
> > I've included /proc/pci, /proc/interrupt /proc/cpuinfo and the kernel
> > config (2.4.0-test10).
>
> > CONFIG_MTRR=y
>
> I bet it's the mtrr bugs. Take a look in /proc/mtrr. Someone suggested
> that if you disable the cachable settings in the BIOS for the BIOS/VGA/ROM
> regions, the bug can be avoided.
>
> -ben
Yes. Look at the NMI count. Looks like every access produces a
NMI.
Cheers,
Dick Johnson
Penguin : Linux version 2.2.17 on an i686 machine (801.18 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
On Thu, 2 Nov 2000 [email protected] wrote:
> On Thu, 2 Nov 2000, Dr. David Gilbert wrote:
>
> > I've included /proc/pci, /proc/interrupt /proc/cpuinfo and the kernel
> > config (2.4.0-test10).
>
> > CONFIG_MTRR=y
>
> I bet it's the mtrr bugs. Take a look in /proc/mtrr. Someone suggested
> that if you disable the cachable settings in the BIOS for the BIOS/VGA/ROM
> regions, the bug can be avoided.
>
yes, that someone was me :) It did indeed help to my 4way 6G RAM Xeon --
the performance improved 40x!. Also, using David's mtrr.patch helped with
the problem of eepro100 interfaces sometimes not coming up properly (and
generally, it is nice to see all your 6G appear in /proc/mtrr).
So, here is David's mtrr patch. Although in his case ("only" 4G) it
shouldn't be needed.... it is for 36bit MTRRs I assume.
Regards,
Tigran
diff -rua linux-2.4.0test9/arch/i386/kernel/mtrr.c linux-2.4.0test9.mod/arch/i386/kernel/mtrr.c
--- linux-2.4.0test9/arch/i386/kernel/mtrr.c Wed Oct 11 19:54:56 2000
+++ linux-2.4.0test9.mod/arch/i386/kernel/mtrr.c Wed Oct 11 20:48:26 2000
@@ -503,9 +503,9 @@
static void intel_get_mtrr (unsigned int reg, unsigned long *base,
unsigned long *size, mtrr_type *type)
{
- unsigned long dummy, mask_lo, base_lo;
+ unsigned long mask_lo, mask_hi, base_lo, base_hi;
- rdmsr (MTRRphysMask_MSR(reg), mask_lo, dummy);
+ rdmsr (MTRRphysMask_MSR(reg), mask_lo, mask_hi);
if ( (mask_lo & 0x800) == 0 )
{
/* Invalid (i.e. free) range */
@@ -515,20 +515,17 @@
return;
}
- rdmsr(MTRRphysBase_MSR(reg), base_lo, dummy);
+ rdmsr(MTRRphysBase_MSR(reg), base_lo, base_hi);
- /* We ignore the extra address bits (32-35). If someone wants to
- run x86 Linux on a machine with >4GB memory, this will be the
- least of their problems. */
+ /* Work out the shifted address mask. */
+ mask_lo = 0xff000000 | mask_hi << (32 - PAGE_SHIFT)
+ | mask_lo >> PAGE_SHIFT;
- /* Clean up mask_lo so it gives the real address mask. */
- mask_lo = (mask_lo & 0xfffff000UL);
/* This works correctly if size is a power of two, i.e. a
contiguous range. */
- *size = ~(mask_lo - 1);
-
- *base = (base_lo & 0xfffff000UL);
- *type = (base_lo & 0xff);
+ *size = -mask_lo;
+ *base = base_hi << (32 - PAGE_SHIFT) | base_lo >> PAGE_SHIFT;
+ *type = base_lo & 0xff;
} /* End Function intel_get_mtrr */
static void cyrix_get_arr (unsigned int reg, unsigned long *base,
@@ -553,13 +550,13 @@
/* Enable interrupts if it was enabled previously */
__restore_flags (flags);
shift = ((unsigned char *) base)[1] & 0x0f;
- *base &= 0xfffff000UL;
+ *base >>= PAGE_SHIFT;
/* Power of two, at least 4K on ARR0-ARR6, 256K on ARR7
* Note: shift==0xf means 4G, this is unsupported.
*/
if (shift)
- *size = (reg < 7 ? 0x800UL : 0x20000UL) << shift;
+ *size = (reg < 7 ? 0x1UL : 0x40UL) << (shift - 1);
else
*size = 0;
@@ -596,7 +593,7 @@
/* Upper dword is region 1, lower is region 0 */
if (reg == 1) low = high;
/* The base masks off on the right alignment */
- *base = low & 0xFFFE0000;
+ *base = (low & 0xFFFE0000) >> PAGE_SHIFT;
*type = 0;
if (low & 1) *type = MTRR_TYPE_UNCACHABLE;
if (low & 2) *type = MTRR_TYPE_WRCOMB;
@@ -621,7 +618,7 @@
* *128K ...
*/
low = (~low) & 0x1FFFC;
- *size = (low + 4) << 15;
+ *size = (low + 4) << (15 - PAGE_SHIFT);
return;
} /* End Function amd_get_mtrr */
@@ -634,8 +631,8 @@
static void centaur_get_mcr (unsigned int reg, unsigned long *base,
unsigned long *size, mtrr_type *type)
{
- *base = centaur_mcr[reg].high & 0xfffff000;
- *size = (~(centaur_mcr[reg].low & 0xfffff000))+1;
+ *base = centaur_mcr[reg].high >> PAGE_SHIFT;
+ *size = -(centaur_mcr[reg].low & 0xfffff000) >> PAGE_SHIFT;
*type = MTRR_TYPE_WRCOMB; /* If it is there, it is write-combining */
} /* End Function centaur_get_mcr */
@@ -665,8 +662,10 @@
}
else
{
- wrmsr (MTRRphysBase_MSR (reg), base | type, 0);
- wrmsr (MTRRphysMask_MSR (reg), ~(size - 1) | 0x800, 0);
+ wrmsr (MTRRphysBase_MSR (reg), base << PAGE_SHIFT | type,
+ (base & 0xf00000) >> (32 - PAGE_SHIFT));
+ wrmsr (MTRRphysMask_MSR (reg), -size << PAGE_SHIFT | 0x800,
+ (-size & 0xf00000) >> (32 - PAGE_SHIFT));
}
if (do_safe) set_mtrr_done (&ctxt);
} /* End Function intel_set_mtrr_up */
@@ -680,7 +679,9 @@
arr = CX86_ARR_BASE + (reg << 1) + reg; /* avoid multiplication by 3 */
/* count down from 32M (ARR0-ARR6) or from 2G (ARR7) */
- size >>= (reg < 7 ? 12 : 18);
+ if (reg >= 7)
+ size >>= 6;
+
size &= 0x7fff; /* make sure arr_size <= 14 */
for(arr_size = 0; size; arr_size++, size >>= 1);
@@ -705,6 +706,7 @@
}
if (do_safe) set_mtrr_prepare (&ctxt);
+ base <<= PAGE_SHIFT;
setCx86(arr, ((unsigned char *) &base)[3]);
setCx86(arr+1, ((unsigned char *) &base)[2]);
setCx86(arr+2, (((unsigned char *) &base)[1]) | arr_size);
@@ -724,34 +726,36 @@
[RETURNS] Nothing.
*/
{
- u32 low, high;
+ u32 regs[2];
struct set_mtrr_context ctxt;
if (do_safe) set_mtrr_prepare (&ctxt);
/*
* Low is MTRR0 , High MTRR 1
*/
- rdmsr (0xC0000085, low, high);
+ rdmsr (0xC0000085, regs[0], regs[1]);
/*
* Blank to disable
*/
if (size == 0)
- *(reg ? &high : &low) = 0;
+ regs[reg] = 0;
else
- /* Set the register to the base (already shifted for us), the
- type (off by one) and an inverted bitmask of the size
- The size is the only odd bit. We are fed say 512K
- We invert this and we get 111 1111 1111 1011 but
- if you subtract one and invert you get the desired
- 111 1111 1111 1100 mask
- */
- *(reg ? &high : &low)=(((~(size-1))>>15)&0x0001FFFC)|base|(type+1);
+ /* Set the register to the base, the type (off by one) and an
+ inverted bitmask of the size The size is the only odd
+ bit. We are fed say 512K We invert this and we get 111 1111
+ 1111 1011 but if you subtract one and invert you get the
+ desired 111 1111 1111 1100 mask
+
+ But ~(x - 1) == ~x + 1 == -x. Two's complement rocks! */
+ regs[reg] = (-size>>(15-PAGE_SHIFT) & 0x0001FFFC)
+ | (base<<PAGE_SHIFT) | (type+1);
+
/*
* The writeback rule is quite specific. See the manual. Its
* disable local interrupts, write back the cache, set the mtrr
*/
__asm__ __volatile__ ("wbinvd" : : : "memory");
- wrmsr (0xC0000085, low, high);
+ wrmsr (0xC0000085, regs[0], regs[1]);
if (do_safe) set_mtrr_done (&ctxt);
} /* End Function amd_set_mtrr_up */
@@ -771,9 +775,9 @@
}
else
{
- high = base & 0xfffff000; /* base works on 4K pages... */
- low = ((~(size-1))&0xfffff000);
- low |= 0x1f; /* only support write-combining... */
+ high = base << PAGE_SHIFT;
+ low = -size << PAGE_SHIFT | 0x1f; /* only support write-combining... */
+
}
centaur_mcr[reg].high = high;
centaur_mcr[reg].low = low;
@@ -1078,7 +1082,7 @@
for (i = 0; i < max; ++i)
{
(*get_mtrr) (i, &lbase, &lsize, <ype);
- if (lsize < 1) return i;
+ if (lsize == 0) return i;
}
return -ENOSPC;
} /* End Function generic_get_free_region */
@@ -1095,7 +1099,7 @@
unsigned long lbase, lsize;
/* If we are to set up a region >32M then look at ARR7 immediately */
- if (size > 0x2000000UL)
+ if (size > 0x2000)
{
cyrix_get_arr (7, &lbase, &lsize, <ype);
if (lsize < 1) return 7;
@@ -1107,11 +1111,11 @@
{
cyrix_get_arr (i, &lbase, &lsize, <ype);
if ((i == 3) && arr3_protected) continue;
- if (lsize < 1) return i;
+ if (lsize == 0) return i;
}
/* ARR0-ARR6 isn't free, try ARR7 but its size must be at least 256K */
cyrix_get_arr (i, &lbase, &lsize, <ype);
- if ((lsize < 1) && (size >= 0x40000)) return i;
+ if ((lsize == 0) && (size >= 0x40)) return i;
}
return -ENOSPC;
} /* End Function cyrix_get_free_region */
@@ -1205,7 +1209,7 @@
/* Fall through */
case X86_VENDOR_CYRIX:
case X86_VENDOR_CENTAUR:
- if ( (base & 0xfff) || (size & 0xfff) )
+ if ( (base & (PAGE_SIZE - 1)) || (size & (PAGE_SIZE - 1)) )
{
printk ("mtrr: size and base must be multiples of 4 kiB\n");
printk ("mtrr: size: %lx base: %lx\n", size, base);
@@ -1246,6 +1250,12 @@
printk ("mtrr: type: %u illegal\n", type);
return -EINVAL;
}
+
+ /* For all CPU types, the checks above should have ensured that
+ base and size are page aligned */
+ base >>= PAGE_SHIFT;
+ size >>= PAGE_SHIFT;
+
/* If the type is WC, check that this processor supports it */
if ( (type == MTRR_TYPE_WRCOMB) && !have_wrcomb () )
{
@@ -1265,7 +1275,8 @@
if ( (base < lbase) || (base + size > lbase + lsize) )
{
up(&main_lock);
- printk (KERN_WARNING "mtrr: 0x%lx,0x%lx overlaps existing 0x%lx,0x%lx\n",
+ printk (KERN_WARNING "mtrr: 0x%lx000,0x%lx000 overlaps existing"
+ " 0x%lx000,0x%lx000\n",
base, size, lbase, lsize);
return -EINVAL;
}
@@ -1274,7 +1285,7 @@
{
if (type == MTRR_TYPE_UNCACHABLE) continue;
up(&main_lock);
- printk ( "mtrr: type mismatch for %lx,%lx old: %s new: %s\n",
+ printk ( "mtrr: type mismatch for %lx000,%lx000 old: %s new: %s\n",
base, size, attrib_to_str (ltype), attrib_to_str (type) );
return -EINVAL;
}
@@ -1329,6 +1340,7 @@
unsigned long lbase, lsize;
if ( !(boot_cpu_data.x86_capability & X86_FEATURE_MTRR) ) return -ENODEV;
+
max = get_num_var_ranges ();
down (&main_lock);
if (reg < 0)
@@ -1337,7 +1349,8 @@
for (i = 0; i < max; ++i)
{
(*get_mtrr) (i, &lbase, &lsize, <ype);
- if ( (lbase == base) && (lsize == size) )
+ if (lbase < 0x100000 && lbase << PAGE_SHIFT == base
+ && lsize < 0x100000 && lsize << PAGE_SHIFT == size)
{
reg = i;
break;
@@ -1346,7 +1359,7 @@
if (reg < 0)
{
up(&main_lock);
- printk ("mtrr: no MTRR for %lx,%lx found\n", base, size);
+ printk ("mtrr: no MTRR for %lx000,%lx000 found\n", base, size);
return -EINVAL;
}
}
@@ -1536,7 +1549,16 @@
return -EFAULT;
if ( gentry.regnum >= get_num_var_ranges () ) return -EINVAL;
(*get_mtrr) (gentry.regnum, &gentry.base, &gentry.size, &type);
- gentry.type = type;
+
+ /* Hide entries that go above 4GB */
+ if (gentry.base + gentry.size > 0x100000 || gentry.size == 0x100000)
+ gentry.base = gentry.size = gentry.type = 0;
+ else {
+ gentry.base <<= PAGE_SHIFT;
+ gentry.size <<= PAGE_SHIFT;
+ gentry.type = type;
+ }
+
if ( copy_to_user ( (void *) arg, &gentry, sizeof gentry) )
return -EFAULT;
break;
@@ -1595,24 +1617,24 @@
for (i = 0; i < max; i++)
{
(*get_mtrr) (i, &base, &size, &type);
- if (size < 1) usage_table[i] = 0;
+ if (size == 0) usage_table[i] = 0;
else
{
- if (size < 0x100000)
+ if (size < 0x100000 >> PAGE_SHIFT)
{
- /* 1MB */
- factor = 'k';
- size >>= 10;
+ /* less than 1MB */
+ factor = 'K';
+ size <<= PAGE_SHIFT - 10;
}
else
{
factor = 'M';
- size >>= 20;
+ size >>= 20 - PAGE_SHIFT;
}
sprintf
(ascii_buffer + ascii_buf_bytes,
- "reg%02i: base=0x%08lx (%4liMB), size=%4li%cB: %s, count=%d\n",
- i, base, base>>20, size, factor,
+ "reg%02i: base=0x%05lx000 (%4liMB), size=%4li%cB: %s, count=%d\n",
+ i, base, base >> (20 - PAGE_SHIFT), size, factor,
attrib_to_str (type), usage_table[i]);
ascii_buf_bytes += strlen (ascii_buffer + ascii_buf_bytes);
}
On Thu, 2 Nov 2000, Tigran Aivazian wrote:
> yes, that someone was me :) It did indeed help to my 4way 6G RAM Xeon --
> the performance improved 40x!. Also, using David's mtrr.patch helped with
> the problem of eepro100 interfaces sometimes not coming up properly (and
> generally, it is nice to see all your 6G appear in /proc/mtrr).
>
> So, here is David's mtrr patch. Although in his case ("only" 4G) it
> shouldn't be needed.... it is for 36bit MTRRs I assume.
Thanks! That patch did the trick - our machine is now running lovely.
Thanks again,
Dave
--
/------------------------------------------------------------------\
| Dr. David Alan Gilbert | Work:[email protected] +44-161-286-2000 Ex258|
| -------- G7FHJ --------|---------------------------------------- |
| Home: [email protected] http://www.treblig.org |
\------------------------------------------------------------------/
"Richard B. Johnson" <[email protected]> writes:
> Yes. Look at the NMI count. Looks like every access produces a
> NMI.
I'm seeing this as well, but only with PIII Xeon systems, not PII
Xeon. Every single timer interrupt on any CPU is accompanied by a NMI
and LOC increment on every CPU.
CPU0 CPU1
0: 146727 153389 IO-APIC-edge timer
[...]
NMI: 300035 300035
LOC: 300028 300028
--
---------------. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `------------------------
On Thu, Nov 02, 2000 at 10:09:36AM -0800, Ulrich Drepper wrote:
> "Richard B. Johnson" <[email protected]> writes:
> > Yes. Look at the NMI count. Looks like every access produces a
> > NMI.
>
> I'm seeing this as well, but only with PIII Xeon systems, not PII
> Xeon. Every single timer interrupt on any CPU is accompanied by a NMI
> and LOC increment on every CPU.
Same happens with PIII CopperMine too.
I have Asus P2B-DS board and 1 GB RAM.
> CPU0 CPU1
> 0: 146727 153389 IO-APIC-edge timer
> [...]
> NMI: 300035 300035
> LOC: 300028 300028
/Matti Aarnio
On 2 Nov 2000, Ulrich Drepper wrote:
> I'm seeing this as well, but only with PIII Xeon systems, not PII
> Xeon. Every single timer interrupt on any CPU is accompanied by a NMI
> and LOC increment on every CPU.
>
> CPU0 CPU1
> 0: 146727 153389 IO-APIC-edge timer
> [...]
> NMI: 300035 300035
> LOC: 300028 300028
You mean that isn't supposed to happen?
CPU0 CPU1
0: 8480192 7786028 IO-APIC-edge timer
1: 3 1 IO-APIC-edge keyboard
2: 0 0 XT-PIC cascade
8: 0 0 IO-APIC-edge rtc
13: 0 0 XT-PIC fpu
23: 188915 191259 IO-APIC-level eth0
28: 16 14 IO-APIC-level sym53c8xx
29: 33655 33665 IO-APIC-level sym53c8xx
30: 0 0 IO-APIC-level es1371
NMI: 16266140 16266140
LOC: 16266123 16266122
ERR: 0
This machine isn't even a Xeon, just a PIII CuMine on a ServerWorks HeIII
chipset.
I reported this on -test6 but got no replies. I'm now running -test10 and
still seeing it.
-Chris
--
Two penguins were walking on an iceburg. The first one said to the
second, "you look like you are wearing a tuxedo." The second one said,
"I might be..."
--David Lynch, Twin Peaks
On 2 Nov 2000, Ulrich Drepper wrote:
> I'm seeing this as well, but only with PIII Xeon systems, not PII
> Xeon. Every single timer interrupt on any CPU is accompanied by a NMI
> and LOC increment on every CPU.
>
> CPU0 CPU1
> 0: 146727 153389 IO-APIC-edge timer
This is the legacy 8254 timer source, used for the system time, i.e.
gettimeofday() and friends.
> NMI: 300035 300035
This is the NMI watchdog at work. Every tick of the legacy timer all
CPUs receive an NMI unless overridden by the "nmi_watchdog" command line
argument.
> LOC: 300028 300028
This is the internal local APIC timer used for scheduling. Every CPU is
equipped with such a private timer.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: [email protected], PGP key available +
On Thu, 2 Nov 2000, Chris Meadors wrote:
> On 2 Nov 2000, Ulrich Drepper wrote:
>
> > I'm seeing this as well, but only with PIII Xeon systems, not PII
> > Xeon. Every single timer interrupt on any CPU is accompanied by a NMI
> > and LOC increment on every CPU.
> >
> > CPU0 CPU1
> > 0: 146727 153389 IO-APIC-edge timer
> > [...]
> > NMI: 300035 300035
> > LOC: 300028 300028
>
> You mean that isn't supposed to happen?
>
> CPU0 CPU1
> 0: 8480192 7786028 IO-APIC-edge timer
> 1: 3 1 IO-APIC-edge keyboard
> 2: 0 0 XT-PIC cascade
> 8: 0 0 IO-APIC-edge rtc
> 13: 0 0 XT-PIC fpu
> 23: 188915 191259 IO-APIC-level eth0
> 28: 16 14 IO-APIC-level sym53c8xx
> 29: 33655 33665 IO-APIC-level sym53c8xx
> 30: 0 0 IO-APIC-level es1371
> NMI: 16266140 16266140
> LOC: 16266123 16266122
> ERR: 0
>
> This machine isn't even a Xeon, just a PIII CuMine on a ServerWorks HeIII
> chipset.
>
> I reported this on -test6 but got no replies. I'm now running -test10 and
> still seeing it.
>
I sure home these ISRs are __tiny__. There is a large amount of
overhead to an interrupt!
CPU0 CPU1
0: 3772079 3803111 IO-APIC-edge timer
1: 32410 33467 IO-APIC-edge keyboard
2: 0 0 XT-PIC cascade
4: 4 2 IO-APIC-edge Analogic(tm) VXI Driver
8: 0 0 IO-APIC-edge rtc
10: 1089719 1091693 IO-APIC-level eth0
11: 98093 96730 IO-APIC-level BusLogic BT-958
13: 1 0 XT-PIC fpu
NMI: 0
ERR: 0
My machine doesn't do any of that stuff but I'm not running the
latest kernel (yet).
Cheers,
Dick Johnson
Penguin : Linux version 2.2.17 on an i686 machine (801.18 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
On Thu, Nov 02, 2000 at 05:39:03PM +0000, Dr. David Gilbert wrote:
> > So, here is David's mtrr patch. Although in his case ("only" 4G) it
> > shouldn't be needed.... it is for 36bit MTRRs I assume.
>
> Thanks! That patch did the trick - our machine is now running lovely.
Your very rare problem was solved in 3 hours and 50 minutes. Most commercial
support shops try and fail to deliver 4 hour response times - this makes me
feel warm inside :-)
Regards,
bert hubert
--
PowerDNS Versatile DNS Services
Trilab The Technology People
'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet
> > I'm seeing this as well, but only with PIII Xeon systems, not PII
> > Xeon. Every single timer interrupt on any CPU is accompanied by a NMI
> > and LOC increment on every CPU.
> >
> > CPU0 CPU1
> > 0: 146727 153389 IO-APIC-edge timer
> > [...]
> > NMI: 300035 300035
> > LOC: 300028 300028
>
> You mean that isn't supposed to happen?
>
> CPU0 CPU1
> 0: 8480192 7786028 IO-APIC-edge timer
> 1: 3 1 IO-APIC-edge keyboard
> 2: 0 0 XT-PIC cascade
> 8: 0 0 IO-APIC-edge rtc
> 13: 0 0 XT-PIC fpu
> 23: 188915 191259 IO-APIC-level eth0
> 28: 16 14 IO-APIC-level sym53c8xx
> 29: 33655 33665 IO-APIC-level sym53c8xx
> 30: 0 0 IO-APIC-level es1371
> NMI: 16266140 16266140
> LOC: 16266123 16266122
> ERR: 0
>
> This machine isn't even a Xeon, just a PIII CuMine on a ServerWorks HeIII
> chipset.
[wakko@gohan:/home/wakko] cat /proc/interrupts
CPU0 CPU1
0: 15276613 18358687 IO-APIC-edge timer
1: 391 455 IO-APIC-edge keyboard
2: 0 0 XT-PIC cascade
4: 1 0 IO-APIC-edge serial
13: 1 0 XT-PIC fpu
14: 3013 2422 IO-APIC-edge ide0
16: 179450 191589 IO-APIC-level eth0
17: 22 23 IO-APIC-level aic7xxx
18: 17254 15655 IO-APIC-level es1371
19: 11 10 IO-APIC-level aic7xxx
NMI: 33635184 33635184
LOC: 33636726 33636725
ERR: 0
[wakko@gohan:/home/wakko] cat /proc/mtrr
I noticed it was a tad slow, but I figured it was the fact it was a netboot
machine. It's a dual ppro 200 192mb ram.
--
Lab tests show that use of micro$oft causes cancer in lab animals
On Fri, 3 Nov 2000, bert hubert wrote:
>> Thanks! That patch did the trick - our machine is now running lovely.
>
>Your very rare problem was solved in 3 hours and 50 minutes. Most commercial
>support shops try and fail to deliver 4 hour response times - this makes me
>feel warm inside :-)
To be fair, the _problem_ wasn't solved in under 4 hours. He was given an
answer to a known problem in less than 4 hours.
However, you are correct in implying linux support is, in many respects,
far better than that of any commercial OS. Anyone tried explaining to
Microsoft or Sun that something is broken? They both immidiately assume
you are an idiot (I;m sure that's true more offen than not) and proceed
with an attitude of "how dare you suggest our OS is broken."
<Insert stories about USR here. I was just dealing with RADIUS. God help
us if their modem code looks like that crap.>
--Ricky
> This machine isn't even a Xeon, just a PIII CuMine on a ServerWorks HeIII
> chipset.
Strange, I've got a dual Katmai (non-Xeon) and notice the same...
CPU0 CPU1
0: 95135438 95720832 IO-APIC-edge timer
1: 579101 572402 IO-APIC-edge keyboard
2: 0 0 XT-PIC cascade
3: 1414912 1423496 IO-APIC-edge serial
5: 5563231 5551230 IO-APIC-edge soundblaster
9: 0 0 IO-APIC-edge acpi
10: 10945738 10944261 IO-APIC-level eth0
11: 696382 700477 IO-APIC-level ide0, ide1
12: 7251164 7251575 IO-APIC-edge PS/2 Mouse
13: 0 0 XT-PIC fpu
14: 3079238 3079438 IO-APIC-level eth1
15: 111 130 IO-APIC-level bttv
NMI: 190856196 190856196
LOC: 190858464 190858463
ERR: 0
This cannot be good...
Kelsey Hudson [email protected]
Software Engineer
Compendium Technologies, Inc (619) 725-0771
---------------------------------------------------------------------------
On Tue, Nov 07, 2000 at 02:02:23PM -0800, Dr. Kelsey Hudson wrote:
> > This machine isn't even a Xeon, just a PIII CuMine on a ServerWorks HeIII
> > chipset.
>
> Strange, I've got a dual Katmai (non-Xeon) and notice the same...
I've just gotten a dual PIII (Coppermine) to my hands. I *think* that
this machine is quite slower as it should be... However, I've got
no old speed values of that box, but...
> CPU0 CPU1
[...]
> NMI: 190856196 190856196
> LOC: 190858464 190858463
...are these two lines okay? I've noticed that as well, but I've not
seen that on UP machines as well...
.oO( Where did I see those MTRR settings? )
MfG, JBG
--
Fehler eingestehen, Gr??e zeigen: Nehmt die Rechtschreibreform zur?ck!!!
/* Jan-Benedict Glaw <[email protected]> -- +49-177-5601720 */
keyID=0x8399E1BB fingerprint=250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB
"insmod vi.o and there we go..." (Alexander Viro on linux-kernel)
On Tue, 7 Nov 2000, Jan-Benedict Glaw wrote:
> [...]
> > NMI: 190856196 190856196
> > LOC: 190858464 190858463
>
> ...are these two lines okay? I've noticed that as well, but I've not
> seen that on UP machines as well...
Yes, please don't worry, it's just the NMI watchdog doing its work.
-ben
On Tue, 7 Nov 2000, Dr. Kelsey Hudson wrote:
> > This machine isn't even a Xeon, just a PIII CuMine on a ServerWorks HeIII
> > chipset.
>
> Strange, I've got a dual Katmai (non-Xeon) and notice the same...
>
> CPU0 CPU1
> 0: 95135438 95720832 IO-APIC-edge timer
> 1: 579101 572402 IO-APIC-edge keyboard
> 2: 0 0 XT-PIC cascade
> 3: 1414912 1423496 IO-APIC-edge serial
> 5: 5563231 5551230 IO-APIC-edge soundblaster
> 9: 0 0 IO-APIC-edge acpi
> 10: 10945738 10944261 IO-APIC-level eth0
> 11: 696382 700477 IO-APIC-level ide0, ide1
> 12: 7251164 7251575 IO-APIC-edge PS/2 Mouse
> 13: 0 0 XT-PIC fpu
> 14: 3079238 3079438 IO-APIC-level eth1
> 15: 111 130 IO-APIC-level bttv
> NMI: 190856196 190856196
> LOC: 190858464 190858463
> ERR: 0
>
> This cannot be good...
>
> Kelsey Hudson [email protected]
> Software Engineer
> Compendium Technologies, Inc (619) 725-0771
> ---------------------------------------------------------------------------
The build time (of version 2.2.17) was 300 seconds +/- 20 seconds
with Linux version 2.2.17.
The build time (of version 2.2.17) is now 1240 seconds +/- 20 seconds
with Linux version 2.4.0.
So the system is about 4 times slower.
Also, I get some CPU watchdog timeout that I didn't ask for Grrr...
Nov 7 17:17:54 chaos nmbd[115]: Samba server CHAOS is now a domain master browser for workgroup LINUX on subnet 204.178.40.224
Nov 7 17:17:54 chaos nmbd[115]:
Nov 7 17:17:54 chaos nmbd[115]: *****
Nov 7 17:18:54 chaos kernel: NMI Watchdog detected LOCKUP on CPU0, registers:
Nov 7 17:18:54 chaos kernel: CPU: 0
Nov 7 17:19:01 chaos login: ROOT LOGIN ON tty2
CPU0 CPU1
0: 10945 11869 IO-APIC-edge timer
1: 419 393 IO-APIC-edge keyboard
2: 0 0 XT-PIC cascade
8: 0 0 IO-APIC-edge rtc
10: 2990 2904 IO-APIC-level eth0
11: 1066 1124 IO-APIC-level BusLogic BT-958
13: 0 0 XT-PIC fpu
NMI: 22748 22748
LOC: 21731 22229
ERR: 0
The NMI and LOC (timers) run faster than timer channel 0. This
cannot be correct. Anybody know what this is and how to get
rid of these CPU time stealers?
This is just a dual 400MHz Pentiumi II:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 5
model name : Pentium II (Deschutes)
stepping : 1
cpu MHz : 400.000915
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
sep_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr
bogomips : 799.54
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 5
model name : Pentium II (Deschutes)
stepping : 1
cpu MHz : 400.000915
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
sep_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr
bogomips : 801.18
Cheers,
Dick Johnson
Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
On Tue, 7 Nov 2000 17:31:19 -0500 (EST),
"Richard B. Johnson" <[email protected]> wrote:
>Also, I get some CPU watchdog timeout that I didn't ask for Grrr...
>
>Nov 7 17:17:54 chaos nmbd[115]: Samba server CHAOS is now a domain master browser for workgroup LINUX on subnet 204.178.40.224
>Nov 7 17:17:54 chaos nmbd[115]:
>Nov 7 17:17:54 chaos nmbd[115]: *****
>Nov 7 17:18:54 chaos kernel: NMI Watchdog detected LOCKUP on CPU0, registers:
>Nov 7 17:18:54 chaos kernel: CPU: 0
>Nov 7 17:19:01 chaos login: ROOT LOGIN ON tty2
Which means that one of the cpus is spinning for 5 seconds with
interrupts disabled. CPU watchdogs are *good*.
>
> CPU0 CPU1
> 0: 10945 11869 IO-APIC-edge timer
> 1: 419 393 IO-APIC-edge keyboard
> 2: 0 0 XT-PIC cascade
> 8: 0 0 IO-APIC-edge rtc
> 10: 2990 2904 IO-APIC-level eth0
> 11: 1066 1124 IO-APIC-level BusLogic BT-958
> 13: 0 0 XT-PIC fpu
>NMI: 22748 22748
>LOC: 21731 22229
>ERR: 0
>
>
>The NMI and LOC (timers) run faster than timer channel 0. This
>cannot be correct. Anybody know what this is and how to get
>rid of these CPU time stealers?
The timer is directed both as a normal interrupt 0 and as a broadcast
non maskable interrupt. The NMI count on each cpu should be roughly
the sum of the interrupt 0 count across all cpus.
The NMI path is fairly fast so the overhead is small. When it does
trip you have a problem, a cpu is spinning for far too long. Extract
the NMI report from the log, run it through ksymoops and mail the
decoded result.
On Tue, 07 Nov 2000 23:31:19 Richard B. Johnson wrote:
> On Tue, 7 Nov 2000, Dr. Kelsey Hudson wrote:
..
> > 15: 111 130 IO-APIC-level bttv
> > NMI: 190856196 190856196
> > LOC: 190858464 190858463
> > ERR: 0
> >
..
>
> CPU0 CPU1
> 0: 10945 11869 IO-APIC-edge timer
> 1: 419 393 IO-APIC-edge keyboard
> 2: 0 0 XT-PIC cascade
> 8: 0 0 IO-APIC-edge rtc
> 10: 2990 2904 IO-APIC-level eth0
> 11: 1066 1124 IO-APIC-level BusLogic BT-958
> 13: 0 0 XT-PIC fpu
> NMI: 22748 22748
> LOC: 21731 22229
> ERR: 0
>
I have also 2xPII@400, on a SuperMicro mobo. I just get:
werewolf:~/soft/in# uptime
11:46pm up 8:38, 0 users, load average: 0.00, 0.00, 0.00
werewolf:~/soft/in# cat /proc/interrupts
CPU0 CPU1
0: 1553608 1555092 IO-APIC-edge timer
1: 1784 1800 IO-APIC-edge keyboard
2: 0 0 XT-PIC cascade
8: 0 1 IO-APIC-edge rtc
9: 12053 11483 IO-APIC-edge aha152x
10: 31594 31168 IO-APIC-level aic7xxx, EMU10K1
11: 42836648 42865890 IO-APIC-level eth0, nvidia
12: 134421 134916 IO-APIC-edge PS/2 Mouse
13: 1 0 XT-PIC fpu
14: 16 4 IO-APIC-edge ide0
15: 10 0 IO-APIC-edge ide1
NMI: 0
ERR: 0
The only diff I see is:
> model name : Pentium II (Deschutes)
> stepping : 1
> cpu MHz : 400.000915
model name : Pentium II (Deschutes)
stepping : 2 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
cpu MHz : 400.912
Something related to version-detection of processors in kernel init ?
--
Juan Antonio Magallon Lacarta #> cd /pub
mailto:[email protected] #> more beer
On Wed, 8 Nov 2000, Keith Owens wrote:
> On Tue, 7 Nov 2000 17:31:19 -0500 (EST),
> "Richard B. Johnson" <[email protected]> wrote:
> >Also, I get some CPU watchdog timeout that I didn't ask for Grrr...
> >
> >Nov 7 17:17:54 chaos nmbd[115]: Samba server CHAOS is now a domain master browser for workgroup LINUX on subnet 204.178.40.224
> >Nov 7 17:17:54 chaos nmbd[115]:
> >Nov 7 17:17:54 chaos nmbd[115]: *****
> >Nov 7 17:18:54 chaos kernel: NMI Watchdog detected LOCKUP on CPU0,
registers:
> >Nov 7 17:18:54 chaos kernel: CPU: 0
> >Nov 7 17:19:01 chaos login: ROOT LOGIN ON tty2
>
> Which means that one of the cpus is spinning for 5 seconds with
> interrupts disabled. CPU watchdogs are *good*.
>
Well no. I won't buy that. What it means is that some so-called
watchdog timer code is broken.
The following, tight loop user-mode code will trip it off and the
interrupts are not disabled from user-mode code:
#include <stdio.h>
int main(void);
int main()
{
for(;;)
{
__asm__ __volatile__(
"\tpushl %ecx\n"
"\txorl %ecx,%ecx\n"
"1:\tloop 1b\n"
"\tpopl %ecx\n"
);
}
return 0;
}
When it trips off, this code is seg-faulted without any core-dump.
This code must never seg-fault. It doesn't access memory that was
not allocated upon startup and, if the kernel wants the CPU, it
will take it away. It is, after all , supposed to be premptive.
Somebody has severly broken Linux.
> >
> > CPU0 CPU1
> > 0: 10945 11869 IO-APIC-edge timer
> > 1: 419 393 IO-APIC-edge keyboard
> > 2: 0 0 XT-PIC cascade
> > 8: 0 0 IO-APIC-edge rtc
> > 10: 2990 2904 IO-APIC-level eth0
> > 11: 1066 1124 IO-APIC-level BusLogic BT-958
> > 13: 0 0 XT-PIC fpu
> >NMI: 22748 22748
> >LOC: 21731 22229
> >ERR: 0
> >
> >
> >The NMI and LOC (timers) run faster than timer channel 0. This
> >cannot be correct. Anybody know what this is and how to get
> >rid of these CPU time stealers?
>
> The timer is directed both as a normal interrupt 0 and as a broadcast
> non maskable interrupt. The NMI count on each cpu should be roughly
> the sum of the interrupt 0 count across all cpus.
>
How do I get these things turned OFF? These CPUs and this machine
worked fine for two years. It now runs at 1/4 the speed.
> The NMI path is fairly fast so the overhead is small. When it does
> trip you have a problem, a cpu is spinning for far too long. Extract
> the NMI report from the log, run it through ksymoops and mail the
> decoded result.
>
I sincerely doubt that the overhead is small. The overhead is
enormous. It can be felt!
All I got from the log was what was reported. There is a colon
after 'registers' and that's that. The system continued to run.
It did not panic.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
Marc Lehman verified that PII systems will generate tons of AGIs with
gcc. Perhaps this is the cause of this problem. You could run EMON and
see if there is something obvious in the numbers ...
Jeff
"Richard B. Johnson" wrote:
>
> On Wed, 8 Nov 2000, Keith Owens wrote:
>
> > On Tue, 7 Nov 2000 17:31:19 -0500 (EST),
> > "Richard B. Johnson" <[email protected]> wrote:
> > >Also, I get some CPU watchdog timeout that I didn't ask for Grrr...
> > >
> > >Nov 7 17:17:54 chaos nmbd[115]: Samba server CHAOS is now a domain master browser for workgroup LINUX on subnet 204.178.40.224
> > >Nov 7 17:17:54 chaos nmbd[115]:
> > >Nov 7 17:17:54 chaos nmbd[115]: *****
> > >Nov 7 17:18:54 chaos kernel: NMI Watchdog detected LOCKUP on CPU0,
> registers:
> > >Nov 7 17:18:54 chaos kernel: CPU: 0
> > >Nov 7 17:19:01 chaos login: ROOT LOGIN ON tty2
> >
> > Which means that one of the cpus is spinning for 5 seconds with
> > interrupts disabled. CPU watchdogs are *good*.
> >
>
> Well no. I won't buy that. What it means is that some so-called
> watchdog timer code is broken.
>
> The following, tight loop user-mode code will trip it off and the
> interrupts are not disabled from user-mode code:
>
> #include <stdio.h>
>
> int main(void);
> int main()
> {
> for(;;)
> {
> __asm__ __volatile__(
> "\tpushl %ecx\n"
> "\txorl %ecx,%ecx\n"
> "1:\tloop 1b\n"
> "\tpopl %ecx\n"
> );
> }
> return 0;
> }
>
> When it trips off, this code is seg-faulted without any core-dump.
> This code must never seg-fault. It doesn't access memory that was
> not allocated upon startup and, if the kernel wants the CPU, it
> will take it away. It is, after all , supposed to be premptive.
>
> Somebody has severly broken Linux.
>
> > >
> > > CPU0 CPU1
> > > 0: 10945 11869 IO-APIC-edge timer
> > > 1: 419 393 IO-APIC-edge keyboard
> > > 2: 0 0 XT-PIC cascade
> > > 8: 0 0 IO-APIC-edge rtc
> > > 10: 2990 2904 IO-APIC-level eth0
> > > 11: 1066 1124 IO-APIC-level BusLogic BT-958
> > > 13: 0 0 XT-PIC fpu
> > >NMI: 22748 22748
> > >LOC: 21731 22229
> > >ERR: 0
> > >
> > >
> > >The NMI and LOC (timers) run faster than timer channel 0. This
> > >cannot be correct. Anybody know what this is and how to get
> > >rid of these CPU time stealers?
> >
> > The timer is directed both as a normal interrupt 0 and as a broadcast
> > non maskable interrupt. The NMI count on each cpu should be roughly
> > the sum of the interrupt 0 count across all cpus.
> >
>
> How do I get these things turned OFF? These CPUs and this machine
> worked fine for two years. It now runs at 1/4 the speed.
>
> > The NMI path is fairly fast so the overhead is small. When it does
> > trip you have a problem, a cpu is spinning for far too long. Extract
> > the NMI report from the log, run it through ksymoops and mail the
> > decoded result.
> >
>
> I sincerely doubt that the overhead is small. The overhead is
> enormous. It can be felt!
>
> All I got from the log was what was reported. There is a colon
> after 'registers' and that's that. The system continued to run.
> It did not panic.
>
> Cheers,
> Dick Johnson
>
> Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).
>
> "Memory is like gasoline. You use it up when you are running. Of
> course you get it all back when you reboot..."; Actual explanation
> obtained from the Micro$oft help desk.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> Please read the FAQ at http://www.tux.org/lkml/
On Tue, 7 Nov 2000, Jeff V. Merkey wrote:
>
> Marc Lehman verified that PII systems will generate tons of AGIs with
> gcc. Perhaps this is the cause of this problem. You could run EMON and
> see if there is something obvious in the numbers ...
>
> Jeff
>
Here are some tests:
Before the tests, I do:
`ifconfig eth0 down`
`kill -TERM -1`
Then I disconnect my ethernet cable to get rid of those interrupts.
This is the test-script:
make clean
time make -j 10 bzImage
It is executed as `sh test.sh &>World.Log &` .
This is Linux 2.4.0-test9
This is a kernel build with NMI watchdog turned OFF:
349.04user 19.83system 3:21.96elapsed 182%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+0minor)pagefaults 0swaps
This is a kernel build with NMI watchdog turned ON:
348.23user 18.84system 3:57.14elapsed 154%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+0minor)pagefaults 0swaps
The elapsed time went from 3:21 to 3:57.
This is Linux 2.2.17
This is the kernel build (the exact same build as above).
214.91user 12.93system 2:37.00elapsed 145%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+0minor)pagefaults 0swaps
The original elapsed time when booting 2.2.17 was 2:37. It is now 3:57.
This is, in every case, rebuilding the exact same kernel.
It doth appearith asthough ithsucks.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
On Wed, Nov 08, 2000 at 09:28:54AM -0500, Richard B. Johnson wrote:
> On Tue, 7 Nov 2000, Jeff V. Merkey wrote:
>
> >
> > Marc Lehman verified that PII systems will generate tons of AGIs with
> > gcc. Perhaps this is the cause of this problem. You could run EMON and
> > see if there is something obvious in the numbers ...
> >
> > Jeff
> >
>
> Here are some tests:
>
> Before the tests, I do:
> `ifconfig eth0 down`
> `kill -TERM -1`
>
> Then I disconnect my ethernet cable to get rid of those interrupts.
>
>
> This is the test-script:
> make clean
> time make -j 10 bzImage
>
> It is executed as `sh test.sh &>World.Log &` .
>
>
> This is Linux 2.4.0-test9
>
> This is a kernel build with NMI watchdog turned OFF:
> 349.04user 19.83system 3:21.96elapsed 182%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (0major+0minor)pagefaults 0swaps
>
>
> This is a kernel build with NMI watchdog turned ON:
> 348.23user 18.84system 3:57.14elapsed 154%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (0major+0minor)pagefaults 0swaps
>
> The elapsed time went from 3:21 to 3:57.
>
>
> This is Linux 2.2.17
>
> This is the kernel build (the exact same build as above).
> 214.91user 12.93system 2:37.00elapsed 145%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (0major+0minor)pagefaults 0swaps
>
> The original elapsed time when booting 2.2.17 was 2:37. It is now 3:57.
>
> This is, in every case, rebuilding the exact same kernel.
>
> It doth appearith asthough ithsucks.
>
I'll attempt to reproduce. I've got live internet servers running on 2.2.18-19
and am not seeing this.
Jeff
>
> Cheers,
> Dick Johnson
>
> Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).
>
> "Memory is like gasoline. You use it up when you are running. Of
> course you get it all back when you reboot..."; Actual explanation
> obtained from the Micro$oft help desk.
>
On Tue, Nov 07, 2000 at 04:03:25PM -0700, "Jeff V. Merkey" <[email protected]> wrote:
>
> Marc Lehman verified that PII systems will generate tons of AGIs with
> gcc.
It is a bit late (just came back from the systems'00 fair), but Jeff
Merkey just acknowledged that indeed he meant me with "Marc Lehman". I
have no idea why he wrote such a thing, since I never mentioned something
like that, nor did I verify anything like this (given that the sentence
doesn't make much sense, either).
Jeff, I never said such a thing and I would appreciate if you didn't put
your words into my mouth.
*puzzled*
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [email protected] |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
On Sat, Nov 11, 2000 at 08:26:55PM +0100, Marc Lehmann wrote:
> On Tue, Nov 07, 2000 at 04:03:25PM -0700, "Jeff V. Merkey" <[email protected]> wrote:
> >
> > Marc Lehman verified that PII systems will generate tons of AGIs with
> > gcc.
>
> It is a bit late (just came back from the systems'00 fair), but Jeff
> Merkey just acknowledged that indeed he meant me with "Marc Lehman". I
> have no idea why he wrote such a thing, since I never mentioned something
> like that, nor did I verify anything like this (given that the sentence
> doesn't make much sense, either).
>
> Jeff, I never said such a thing and I would appreciate if you didn't put
> your words into my mouth.
I can go and get the text from our discussion, and I distinctly remember
your answer to this question on PII and you said "lots". This was also a
private email correspondence between us based on my review. I also
verified what you told me, and you were right . On PII, it generated
lots....
Jeff
>
> *puzzled*
>
> --
> -----==- |
> ----==-- _ |
> ---==---(_)__ __ ____ __ Marc Lehmann +--
> --==---/ / _ \/ // /\ \/ / [email protected] |e|
> -=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
> The choice of a GNU generation |
> |
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> Please read the FAQ at http://www.tux.org/lkml/
On Mon, 13 Nov 2000, Jeff V. Merkey wrote:
> On Sat, Nov 11, 2000 at 08:26:55PM +0100, Marc Lehmann wrote:
> > On Tue, Nov 07, 2000 at 04:03:25PM -0700, "Jeff V. Merkey" <[email protected]> wrote:
> > >
> > > Marc Lehman verified that PII systems will generate tons of AGIs with
> > > gcc.
> >
> > It is a bit late (just came back from the systems'00 fair), but Jeff
> > Merkey just acknowledged that indeed he meant me with "Marc Lehman". I
> > have no idea why he wrote such a thing, since I never mentioned something
> > like that, nor did I verify anything like this (given that the sentence
> > doesn't make much sense, either).
> >
> > Jeff, I never said such a thing and I would appreciate if you didn't put
> > your words into my mouth.
>
> I can go and get the text from our discussion, and I distinctly remember
> your answer to this question on PII and you said "lots". This was also a
> private email correspondence between us based on my review. I also
> verified what you told me, and you were right . On PII, it generated
> lots....
I wouldn't swear it was Marc, but I do remember seeing a thread in which
someone did confirm this. Jeff posted an example code segment which would
generate an AGI, and gcc generated a lot of code like this (i.e. it doesn't
avoid generating AGIs). Someone (Marc??) supported this.
He didn't state directly "gcc code produces lots of AGIs", but did say that gcc
generated a lot of code which, according to Jeff, produces AGIs.
James.
On Sun, Nov 12, 2000 at 11:22:02PM -0700, "Jeff V. Merkey" <[email protected]> wrote:
> I can go and get the text from our discussion, and I distinctly remember
> your answer to this question on PII and you said "lots". This was also a
Well, my mail certainly contained the words "lot" (not "lots") and "PII",
but certainly not in the same sentence and certainly not refering to each
other and certainly not in refering to syscalls, and I am totally puzzled
of why you are keep claiming this in public (you can't even quote my name
correctly).
Could you please stop lying and hopefully apologize for abusing my name in
public for claiming wrong things I never said and abstain from doing so in
the future?
And please keep this off-list from now on.
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [email protected] |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|