From owner-freebsd-bugs Tue Jul 11 14:33:48 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA05649 for bugs-outgoing; Tue, 11 Jul 1995 14:33:48 -0700 Received: from nwpeople.demon.co.uk (nwpeople.demon.co.uk [158.152.27.96]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id OAA05618 for ; Tue, 11 Jul 1995 14:33:15 -0700 Date: Tue, 11 Jul 1995 22:04:55 GMT From: iain@nwpeople.demon.co.uk (Iain Baird) Reply-To: iain@nwpeople.demon.co.uk Message-Id: <739@nwpeople.demon.co.uk> To: bugs@freebsd.org Subject: 950622-SNAP system lockup X-Mailer: PCElm 1.10 Lines: 54 Sender: bugs-owner@freebsd.org Precedence: bulk Hi, I have installed 2.0.5-950622-SNAP on the following hardware: Gateway 4DX66-P Adaptec AHA-2940 Seagate Barracuda ST31250 Diamond Stealth 64 VRAM PCI DTC PCI IDE Controller Western Digital Caviare 540MB (Not used for FreeBSD) SMC Elite Ultra SoundBlaster 16 The installation went fine. I had logged in and was rebuilding the kernel. I logged in on another virtual console and started to un-tar data from a floppy. At this point the system locked solid, with the hard drive activity light on. After a hard reset and reboot fsck reported all filesystem errors fixed, but when I attempted to login I saw a message along the lines of "login: exec format error", so it looks like something is hosed. This is similar to problems I experienced with late 2.0 snapshots, I did not report them as decided to wait for 2.0.5. The problem seems to be triggered by more than one process concurrently performing intensive disk I/O. In the past it has occurred when running a tar pipeline, e.g. tar -cf - . | (cd elsewhere; tar -xf -) With late 2.0 snapshots such a tar pipeline would *always* cause a lockup, provided non-trivial amounts of data were involved. I never saw intensive disk I/O by a single process cause this problem - kernel rebuilds completed OK as long as little else was happening. I have less of a sample size with 950622-SNAP as the lockup seems to have hosed my system, but I had one kernel rebuild complete successfully while nothing else was happening. I vaguely recall reading something about a bug which occurred with fast disks. The ST31250 is pretty fast, could this be a factor? Please let me know if you require further information about my system, or would like me to run any tests - I'm prepared so invest some effort in helping to solve this. Thank you all for your hard work. iain -- Iain Baird Network People International Tel: +44 (0)1732 743591