From owner-freebsd-current Tue Feb 21 07:09:22 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id HAA04386 for current-outgoing; Tue, 21 Feb 1995 07:09:22 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id HAA03501 for ; Tue, 21 Feb 1995 07:06:54 -0800 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA12418; Tue, 21 Feb 1995 15:51:15 +0100 Received: by sax.sax.de (8.6.9/8.6.9-s1) with UUCP id PAA05239; Tue, 21 Feb 1995 15:51:14 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.9/8.6.9) id PAA10150; Tue, 21 Feb 1995 15:38:07 +0100 From: J Wunsch Message-Id: <199502211438.PAA10150@uriah.heep.sax.de> Subject: pcvt in -current To: freebsd-current@FreeBSD.org (FreeBSD-current users), hm@hcs.de (Hellmuth Michaelis), lim@gate.sinica.edu.tw (Carmay Lim) Date: Tue, 21 Feb 1995 15:38:06 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1163 Sender: current-owner@FreeBSD.org Precedence: bulk Wow, i've finally tracked down why pcvt panics a -current kernel. Thanks to the guy who used to be called Carny Lim here (i know it's not your real name, but forgive me: i've forgot it), who provided me with an account on a machine in Taiwan to analyze a kernel core dump for this. The problem is that pcvt used to be a replacement driver for syscons and pccons. Hence it always used the same calling interface as its replacees, so all external entry points are named pc*. Recently, Søren decided to rename the syscons entry points to their new names though, and since we don't have pccons any longer, pcvt dissapeared from the cdevsw[] table. :-( Hellmuth, we need to test for this condition in pccnprobe() instead of falling off the end of cdevsw[] and filling the console structure with bogus values. (panic() is all we can do there, but much better pointing to the source of the evil.) Now i dunno how to handle this at best. IMHO, creating an own cdevsw[] entry is the best solution. Any other opinions? -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-)