Losing ssh session when doing intensive disk I/O & background fsck with RELENG_6

Listas listas at informatica.info
Fri Sep 30 11:59:43 PDT 2005

I'm testing BETA5/RELENG_6 with an Intel P4 system. Here are the 
essential dmesg fragments with system information:

Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (3010.67-MHz 686-class CPU)
   Origin = "GenuineIntel"  Id = 0xf34  Stepping = 4
real memory  = 1073414144 (1023 MB)
avail memory = 1041526784 (993 MB)
ioapic0 <Version 2.0> irqs 0-23 on motherboard
xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xb800-0xb87f mem 
0xcddffc00-0xcddffc7f irq 17 at device 9.0 on pci1
miibus0: <MII bus> on xl0
xlphy0: <3Com internal media interface> on miibus0
xlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
xl0: Ethernet address: 00:01:02:a6:96:37
acd0: DMA limited to UDMA33, controller found non-ATA66 cable
acd0: DVDR <HL-DT-ST DVDRAM GSA-4160B/A300> at ata0-master UDMA33
ad8: 194481MB <Maxtor 6B200M0 BANC1980> at ata4-master SATA150
ad8: Intel calc=55e037a4 meta=2af01bd2
ad10: 194481MB <Maxtor 6B200M0 BANC1980> at ata5-master SATA150
ad10: Intel calc=55e037a4 meta=2af01bd2
ar0: 194480MB <Intel MatrixRAID RAID1> status: READY
ar0: disk0 READY (master) using ad8 at ata4-master
ar0: disk1 READY (mirror) using ad10 at ata5-master
Trying to mount root from ufs:/dev/ar0s1a
Loading configuration files.
No suitable dump device was found.
Entropy harvesting:
swapon: adding /dev/ar0s1b as swap device

The boot process is trying to configure the dump device before swapon 
and it fails, but that's not the real problem I report here.

The problem is that when I do some intensive disk I/O (make install, du 
-ckx /usr, etc.) just after booting, I lose my ssh connection to the 
machine, and may spend a lot to reconnect. It seems that this only 
happens while a background fsck is running.

I find nothing in /var/log/messages, nor elsewhere.

For example, If I do a /usr/bin/du -ckx, it starts really fast, but then 
becomes slower and slower until the ssh connection is closed. Meanwhile, 
the console runs just fine.

Found the same problem running 'make install', and after the connection 
was closed the 'make' processes were all in wait state and had to issue 
a kill -9 to kill them.

Tested with BETA5 and RELENG_6 as of today.


More information about the freebsd-current mailing list