.. i've detected a strange behaviour of 2.0.20 last sunday.
First the machine: ASUS-PCI/I-486 SP3G (Rev. 1.8) with onbaord ncr53c810,
mb-BIOS awsg0304 with NCRPCI-3.07.00, AMD5x86-P75, SCSI 1G hardisk IBM-Pegasus,
SCSI Toshiba-CDROM ... onboard controller and CDROM are terminated
(passive on controller, active on CDROM) and TERMPWR are set on all devices.
It works rock stable under 1.2.13, some 1.3.xx, most 1.9.xx, and 2.0.0 to
2.0.18 (2.0.xx with CONFIG_SCSI_NCR53C7xx=y, CONFIG_SCSI_NCR53C7xx_sync=y,
CONFIG_SCSI_NCR53C7xx_FAST=y, and CONFIG_SCSI_NCR53C7xx_DISCONNECT=y)
Now the 2.0.20 kernel says during disk access:
... at vrituall address c0000001
current->txx.cr3=00101000, %cr3=00101000
*pde=00102067
*pte=00000027
Oops: 0000
CPU: 0
EIP: 0010[<0018d912>]
EFLAGS: 00010202
eax: 00000001 ebx: 00000000 ecx: 00092f60 edx: 00092f64
esi: 00000000 edi: 00095808 ebp: 00000000 esp: 00092f24
ds: 0018 es: 0018 fs: 002b gs: 0018 ss:0018
Process swapper (pid: 1, process nr: 1 stackpage=00092000)
Stack: 00000000 00000000 00000000 00009000 00092f69 00000000 00092f6e 00000008
0000017d 00092f6c 00000000 0008e000 00001000 00000246 00000000 00000002
00000000 00092f64 00000000 00000000 00090000 0018e2ca 00000000 001bea80
Call Trace: [<0018e2ca>][<001899b3>][<00168e81>][<0012dd68>][<0010a5b2>][<0011e4d0>][<001093aa>]
[<001091b4>][<001091bb>][<00109360>]
Code ff 08 88 d6 e5 00 00 8b b7 f0 00 00 00 43 85 f6 0f 84 54
or something like that ... i've write it down by hand. Sorry, i've forgotten
to take the System.map on floppy at home to compare against this result at.
It looke like a dieing kswapd ...
After booting 2.0.18 the system is rock stabel again ... strange
Werner