On Mon, 11 May 2020, Maciej W. Rozycki wrote: > And if timing is indeed the culprit, then I think it will be best fixed > in the 82378IB southbridge, i.e.[1]: > > "The I/O recovery mechanism in the SIO is used to add additional recovery > delay between PCI originated 8-bit and 16-bit I/O cycles to the ISA Bus. > The SIO automatically forces a minimum delay of four SYSCLKs between > back-to-back 8 and 16 bit I/O cycles to the ISA Bus. The delay is > measured from the rising edge of the I/O command (IOR# or IOW#) to the > falling edge of the next BALE. If a delay of greater than four SYSCLKs is > required, the ISA I/O Recovery Time Register can be programmed to increase > the delay in increments of SYSCLKs. Note that no additional delay is > inserted for back-to-back I/O "sub cycles" generated as a result of byte > assembly or disassembly. This register defaults to 8 and 16-bit recovery > enabled with two clocks added to the standard I/O recovery." > > where it won't be causing unnecessary overhead for native PCI devices or > indeed excessive one for ISA devices. It might be interesting to note > that later SIO versions like the 82378ZB increased the minimum to five > SYSCLKs, so maybe a missing SYSCLK (that can still be inserted by suitably > programming the ICRT) is the source of the problem? > > References: > > [1] "82378IB System I/O (SIO)", April 1993, Intel Corporation, Order > Number: 290473-002, Section 4.1.17 "ICRT -- ISA Controller Recovery > Timer Register" > > Maciej I tried to modify this register (I wrote 0x44 to it - it should correspond to the maximum delay) and it had no effect on the serial port and rtc lock-ups. Mikulas
