40 0 3 1 -12 -12 0 0 kswapd SW< ? 71224881:53 (kswapd)
Now I know my old 8Mb 486 swaps a lot, but that CPU time is ridiculous:
4:05pm up 9 days, 15:15, 4 users, load average: 1.94, 2.42, 2.64
I don't think there are that many minutes in nine days.
This system is running 2.0.34pre2.
Notably, nine days into its last uptime, it had a hard lock - nothing
logged - when I was doing nothing but reading something from xdvi, so there
was perhaps activity over X's AF_UNIX socket, but little else going on.
I fear this is one of the Sporadic Lockups from Hell; but if it's caused by
something jumping on kernel data space, could it not jump in a slightly
different place, and hit kswapd's task structure?
I know little - yet - about the kernel's internals, so this is uneducated
guesswork. :)
It says something about Linux, I feel, that this is the only hard lockup
this system has ever had from a `stable' kernel, in eight months of
nearly continuous running. Try doing *that* with NT! :)
My .config is as follows:
CONFIG_EXPERIMENTAL=y
CONFIG_MODULES=y
CONFIG_KERNELD=y
CONFIG_NET=y
CONFIG_SYSVIPC=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_JAVA=m
CONFIG_KERNEL_ELF=y
CONFIG_M486=y
CONFIG_BLK_DEV_FD=y
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_LOOP=m
CONFIG_INET=y
CONFIG_SYN_COOKIES=y
CONFIG_IP_NOSR=y
CONFIG_NETDEVICES=y
CONFIG_DUMMY=y
CONFIG_SLIP=y
CONFIG_SLIP_COMPRESSED=y
CONFIG_SLIP_SMART=y
CONFIG_CD_NO_IDESCSI=y
CONFIG_CDU31A=y
CONFIG_QUOTA=y
CONFIG_MINIX_FS=m
CONFIG_EXT2_FS=y
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_UMSDOS_FS=m
CONFIG_PROC_FS=y
CONFIG_ISO9660_FS=m
CONFIG_HPFS_FS=m
CONFIG_SERIAL=y
CONFIG_RTC=y
CONFIG_SOUND=y
CONFIG_SB=y
CONFIG_ADLIB=y
CONFIG_AUDIO=y
CONFIG_MIDI=y
CONFIG_YM3812=y
SBC_BASE=220
SBC_IRQ=5
SBC_DMA=1
SB_DMA2=1
SB_MPU_BASE=0
SB_MPU_IRQ=-1
DSP_BUFFSIZE=65536
(Note that I *don't* have RST cookies on, so if I did suffer one of Those
Lockups, it can't be RST cookies' fault alone, as some have speculated.)
-- `Oooo! Saint Malcolm preserve us! This is heresy.'- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu