lkml.org 
[lkml]   [1998]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subject2.0.33/SMP lockups

Dual P200, 128MB RAM, AIC-7880 Ultra SCSI builtin into GA-586DX board, two
WDE4360 disks, CR-506 CD (not in use), 3C509B EtherLink III,
SMP=1

I have been using patch-2.0.34-pre2 since late January. I have had 7 lockups
since then. Before first 5 I had been running xntp3-5.90_export-1.rpm and in
fact I have seen in 2(out 5) cases xntpd messages directly before the
lockup. But then I have removed/killed xntpd, and I have got 2 new lockups
in 6 days.

In most (6/7) cases what it happens I see messages:

"CPU ... :previous IPI still not cleared after 10mS" scrolling fast through
the screen. I can still switch VTs, Caps/Num lock does not work, the machine
pings but with great delays:

64 bytes from 131.152.105.107: icmp_seq=74 ttl=64 time=19.3 ms
64 bytes from 131.152.105.107: icmp_seq=75 ttl=64 time=2.6 ms
64 bytes from 131.152.105.107: icmp_seq=76 ttl=64 time=18.8 ms

--- crds.chemie.unibas.ch ping statistics ---
77 packets transmitted, 77 packets received, 0% packet loss
round-trip min/avg/max = 1.0/13.8/21.1 ms
Connections get accepted, but no deamons are spawned. All processes stop
responding.
The only way out is hard reset.

Once I have seen only one message "unknown interrupt" instead of
stream of "previous IPI"

crash 21 min at 19.2-1:5:1 19.2-1:26:27
unknown interrupt

Feb 19 00:11:32 crds identd[12807]: Connection from hegel.ittc.ukans.edu
Feb 19 00:11:32 crds identd[12807]: Successful lookup: 13655 , 80 : root
Feb 19 00:16:12 crds xntpd[348]: time reset (step) -0.326229 s
Feb 19 00:16:12 crds xntpd[348]: synchronisation lost
Feb 19 00:20:33 crds xntpd[348]: synchronized to LOCAL(0), stratum=10
Feb 19 00:21:23 crds xntpd[348]: synchronized to 129.132.1.11, stratum=2
Feb 19 00:21:23 crds xntpd[348]: kernel pll status change 89
Feb 19 00:21:32 crds xntpd[348]: synchronized to 131.188.2.45, stratum=1
Feb 19 00:59:51 crds xntpd[348]: time reset (step) -0.282968 s
Feb 19 00:59:51 crds xntpd[348]: synchronisation lost
Feb 19 01:04:16 crds xntpd[348]: synchronized to LOCAL(0), stratum=10
Feb 19 01:05:02 crds xntpd[348]: synchronized to 130.159.144.62, stratum=3
Feb 19 01:05:02 crds kernel: Unknown interrupt
Feb 19 01:05:02 crds xntpd[348]: kernel pll status change 89
Feb 19 01:05:03 crds xntpd[348]: synchronized to 129.132.1.11, stratum=2
Feb 19 01:05:11 crds xntpd[348]: synchronized to 131.188.2.45, stratum=1
Feb 19 01:26:21 crds syslogd 1.3-3: restart.

A few hours before this event I have seen my video memory beeing "scratched"
- suddenly aprox. 2 lines filled with strange, colourful symbols appeared.


This machine is in principle a workstation, it serves 2 remote and one local
X-server, there is also GPIB (specialised serial communication card) module
loaded, but not used frequently.

The following patches were applied:

Feb 25 14:03:40 crds kernel: Linux version 2.0.33
(root@crds.chemie.unibas.ch) (gcc version 2.7.2.1.f.1) #1 Sun Jan 25 03:31:34
MET 1998
Feb 25 14:03:40 crds kernel: *** Installed patches:
Feb 25 14:03:40 crds kernel: aic7xxx-5.0.3 (Doug Ledford)
Feb 25 14:03:40 crds kernel: linux-2.0.33-stack-symlink (Solar Designer)
Feb 25 14:03:40 crds kernel: patch-2.0.34-pre2 (Alan Cox)
Feb 25 14:03:40 crds kernel: Linux Unofficial Patch Printout V1.1 (Henning
Schmiedehausen <henning@twins.iconsult.com>/Kurt Huwig <kurt@huwig.de>)
Feb 25 14:03:40 crds kernel: *** End of Patches

[root@crds /root]# lsmod
Module Pages Used by
ip_masq_raudio 1 0
ip_masq_ftp 1 0
gpib0 11 0
3c509 2 1

I use the following rule:
/sbin/ipfwadm -F -a accept -m -S 10.10.0.0/24 -D 0.0.0.0/0 -b
(can -b here be the cause of the problem?)
together with:
eth0:0 Link encap:10Mbps Ethernet HWaddr 00:60:97:5C:D6:71
inet addr:10.10.0.1 Bcast:10.10.0.255 Mask:255.255.255.0
- those addresses are not used frequently.

Appletalk is heavily used here (atalkd, afpd, papd running).
Most of the time (40s/minute) tcpdump redirected to a file is running (files
are being deleted if no network errors occured).

I had similar problems with 2.0.33, this is not specific to
patch-2.0.34-pre2. If someone expresses such need I can go through the list
of 122 reboots I had since July 1997, and try to determine the kernel running
and their causes. In have never had FS corruption nor "signal 11" problems.
This machine was used for heavy testing of pre-2.0.31 series.

At the moment I am going to compile the kernel with removed
linux-2.0.33-stack-symlink , aic7xxx-5.0.7 (corrected version) and run it for
another week. May be I should also switch off some of the following options:
? Which ones ? Since that crashes are sort of reproducible I am open to test
any suggested configuration.

CONFIG_EXPERIMENTAL=y

CONFIG_MODULES=y
CONFIG_MODVERSIONS=y
CONFIG_KERNELD=y

CONFIG_NET=y
CONFIG_PCI=y
CONFIG_PCI_OPTIMIZE=y
CONFIG_SYSVIPC=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_JAVA=y
CONFIG_STACKEXEC=y
CONFIG_STACKEXEC_LOG=y
CONFIG_KERNEL_ELF=y
CONFIG_M586=y

CONFIG_BLK_DEV_FD=y
CONFIG_BLK_DEV_IDE=y

CONFIG_BLK_DEV_IDECD=y
CONFIG_BLK_DEV_CMD640=y
CONFIG_BLK_DEV_RZ1000=y
CONFIG_BLK_DEV_TRITON=y

CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_XD=m

CONFIG_FIREWALL=y
CONFIG_NET_ALIAS=y
CONFIG_INET=y
CONFIG_IP_FORWARD=y
CONFIG_IP_MULTICAST=y
CONFIG_SYN_COOKIES=y
CONFIG_IP_FIREWALL=y
CONFIG_IP_MASQUERADE=y

CONFIG_IP_MASQUERADE_ICMP=y
CONFIG_IP_TRANSPARENT_PROXY=y
CONFIG_IP_ALWAYS_DEFRAG=y
CONFIG_IP_ACCT=y
CONFIG_IP_ROUTER=y
CONFIG_NET_IPIP=y
CONFIG_IP_MROUTE=y
CONFIG_IP_ALIAS=y

CONFIG_IP_NOSR=y
CONFIG_SKB_LARGE=y

CONFIG_IPX=m
CONFIG_ATALK=y

CONFIG_SCSI=y

CONFIG_BLK_DEV_SD=y
CONFIG_CHR_DEV_ST=m
CONFIG_BLK_DEV_SR=y
CONFIG_CHR_DEV_SG=m

CONFIG_SCSI_CONSTANTS=y

CONFIG_SCSI_7000FASST=m
CONFIG_SCSI_AHA152X=m
CONFIG_SCSI_AHA1542=m
CONFIG_SCSI_AHA1740=m
CONFIG_SCSI_AIC7XXX=y
CONFIG_AIC7XXX_PROC_STATS=y
CONFIG_AIC7XXX_RESET_DELAY=5
CONFIG_SCSI_ADVANSYS=m
CONFIG_SCSI_IN2000=m
CONFIG_SCSI_AM53C974=m
CONFIG_SCSI_BUSLOGIC=m
CONFIG_SCSI_DTC3280=m
CONFIG_SCSI_EATA_DMA=m
CONFIG_SCSI_EATA_PIO=m
CONFIG_SCSI_EATA=m
CONFIG_SCSI_EATA_MAX_TAGS=16
CONFIG_SCSI_FUTURE_DOMAIN=m
CONFIG_SCSI_NCR53C406A=m
CONFIG_SCSI_NCR53C7xx=m
CONFIG_SCSI_NCR53C8XX=m
CONFIG_SCSI_NCR53C8XX_MAX_TAGS=4
CONFIG_SCSI_NCR53C8XX_SYNC=5
CONFIG_SCSI_PPA=m
CONFIG_SCSI_PAS16=m
CONFIG_SCSI_QLOGIC_FAS=m
CONFIG_SCSI_QLOGIC_ISP=m
CONFIG_SCSI_SEAGATE=m
CONFIG_SCSI_T128=m
CONFIG_SCSI_U14_34F=m
CONFIG_SCSI_U14_34F_MAX_TAGS=8
CONFIG_SCSI_ULTRASTOR=m
CONFIG_SCSI_GDTH=m

CONFIG_NETDEVICES=y
CONFIG_DUMMY=y
CONFIG_EQUALIZER=m
CONFIG_DLCI=m
CONFIG_DLCI_COUNT=24
CONFIG_DLCI_MAX=8
CONFIG_SDLA=m
CONFIG_PLIP=m
CONFIG_PPP=y

CONFIG_SLIP=y
CONFIG_SLIP_COMPRESSED=y
CONFIG_SLIP_SMART=y
CONFIG_SLIP_MODE_SLIP6=y
CONFIG_NET_ETHERNET=y
CONFIG_NET_VENDOR_3COM=y
CONFIG_EL1=m
CONFIG_EL2=m
CONFIG_ELPLUS=m
CONFIG_EL16=m
CONFIG_EL3=m
CONFIG_VORTEX=m
CONFIG_NET_VENDOR_SMC=y
CONFIG_WD80x3=m
CONFIG_ULTRA=m
CONFIG_ULTRA32=m
CONFIG_SMC9194=m
CONFIG_NET_ISA=y
CONFIG_AT1700=m
CONFIG_E2100=m
CONFIG_DEPCA=m
CONFIG_EWRK3=m
CONFIG_EEXPRESS=m
CONFIG_EEXPRESS_PRO=m
CONFIG_FMV18X=m
CONFIG_HPLAN_PLUS=m
CONFIG_HPLAN=m
CONFIG_HP100=m
CONFIG_ETH16I=m
CONFIG_NI52=m
CONFIG_NI65=m
CONFIG_ARCNET=m
CONFIG_ARCNET_ETH=y
CONFIG_ARCNET_1051=y

CONFIG_QUOTA=y
CONFIG_SYMLINK_FIX=y
CONFIG_SYMLINK_LOG=y
CONFIG_MINIX_FS=y
CONFIG_EXT_FS=m
CONFIG_EXT2_FS=y
CONFIG_XIA_FS=m
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=m
CONFIG_UMSDOS_FS=m
CONFIG_PROC_FS=y
CONFIG_NFS_FS=y
CONFIG_SMB_FS=m
CONFIG_SMB_WIN95=y
CONFIG_NCP_FS=m
CONFIG_ISO9660_FS=m
CONFIG_HPFS_FS=m
CONFIG_SYSV_FS=m
CONFIG_AFFS_FS=m
CONFIG_AMIGA_PARTITION=y
CONFIG_UFS_FS=m
CONFIG_BSD_DISKLABEL=y
CONFIG_SMD_DISKLABEL=y

CONFIG_SERIAL=y
CONFIG_CYCLADES=m
CONFIG_RISCOM8=m
CONFIG_PRINTER=m
CONFIG_SPECIALIX=m
CONFIG_MOUSE=y
CONFIG_ATIXL_BUSMOUSE=m
CONFIG_BUSMOUSE=m
CONFIG_MS_BUSMOUSE=m
CONFIG_PSMOUSE=y
CONFIG_FTAPE=m

CONFIG_WATCHDOG=y
CONFIG_WATCHDOG_NOWAYOUT=y
CONFIG_WDT=m
CONFIG_WDT_501=y
CONFIG_WDT_501_FAN=y
CONFIG_SOFT_WATCHDOG=m
CONFIG_PCWATCHDOG=m
CONFIG_RTC=y

CONFIG_SOUND=m
CONFIG_LOWLEVEL_SOUND=y




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:41    [W:0.073 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site