From owner-freebsd-hackers Mon Jan 23 21:39:50 1995 Return-Path: hackers-owner Received: (from root@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id VAA12815 for hackers-outgoing; Mon, 23 Jan 1995 21:39:50 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id VAA12793; Mon, 23 Jan 1995 21:39:14 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id QAA10618; Tue, 24 Jan 1995 16:36:02 +1100 Date: Tue, 24 Jan 1995 16:36:02 +1100 From: Bruce Evans Message-Id: <199501240536.QAA10618@godzilla.zeta.org.au> To: wpaul@skynet.ctr.columbia.edu, wraith@csd.uwm.edu Subject: Re: Is this a bug?!? Cc: hackers@FreeBSD.org, questions@FreeBSD.org Sender: hackers-owner@FreeBSD.org Precedence: bulk >> I just finished upgrading one of my 'bsd boxes from a dx2-50 ISA to a dx2-66 >> VLB motherboard. Problems: >> >> I now seem to be unable to issue a Ctrl-Alt-Del (system >> just beeps at me each time I hit the combo). >> >> 'shutdown' results in a kernel panic: >> >> panic: b_to_q to a clist with no reserved cblocks This should be fixed in -current. There is another bug instead :-[. >I've been able to reliably reproduce this panic message on my system now >that I've started looking into actually using /dev/console for something. It is easier to reproduce on your serial console. syscons used to avoid the problem. >that writing to /dev/ttyv0 actually causes the kernel to go from >write(), to vn_write(), to ffsspec_write(), to spec_write(), to cn_write(), >to scwrite(), to ttwrite() and then to b_to_q() and a panic. The This layering seems excessive. One of the benchmarks in Larry Mcvoy's benchmark suite tests "syscall" overhead by writing a byte to stdout. FreeBSD is about 4 times slower than Linux for this benchmark, perhaps because of all the layers. The benchmark doesn't really test syscalls or i/o, but it's good for testing cdev overheads. >vn->v_un->vu_specinfo->si_rdev in spec_write() was 0x00000000 where >it probably should have been 0x0c000000 (or something like that -- >basically, 0x00000000 is major 0/minor 0 where it should have been >major 12/minor 0 (for syscons) instead). 0/0 is correct for the console. It gets translated to 12/0 in cons.c. The current version of syscons, and all versions of sio, cannot tell if they are working with the 0/0 device, and this causes problems when the 12/0 device is closed while the 0/0 device is open or vice versa. I fixed this, but now the process group info for the 12/0 device doesn't go away when the 12/0 device is closed, and TIOCSTTY fails in login_tty(). Bruce