From owner-freebsd-current Wed Apr 5 09:51:57 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA23753 for current-outgoing; Wed, 5 Apr 1995 09:51:57 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id JAA23746 for ; Wed, 5 Apr 1995 09:51:41 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id CAA25258; Thu, 6 Apr 1995 02:45:42 +1000 Date: Thu, 6 Apr 1995 02:45:42 +1000 From: Bruce Evans Message-Id: <199504051645.CAA25258@godzilla.zeta.org.au> To: ache@astral.msk.su, rgrimes@gndrsh.aac.dev.com Subject: Re: Strange kernel printf... Cc: freebsd-current@freefall.cdrom.com Sender: current-owner@FreeBSD.org Precedence: bulk >> I got strange printf on each kernel reboot, it comes to console >> and log both. >> Here piece of dmesg output: >> ... >> pca0 >> ^^^^^^^^^^^^^!!!!!! Watch this !!!!!!! >> pca0: PC speaker audio driver >> >> I examine pcaudio.c and don't find any additional printf there >> except "pca0: PC speaker audio driver". >> Wrom where this magic "pca0" can come? >> Any ideas? >> Does anybody see it too? >I beleive this is coming from some bad logic in isa.c that has gone >through several changes in attempts to get it to print ``on isa'' >for certain devices that use funny I/O addresses. >It now under certain conditins prints nothing :-(., but atleast the >newline is there :-) :-). >I've been meaning to get in there and fix it, but if you would, please >do. This used to work as follows: isa.c printed "pca0". pcaudio.c printed " PC speaker audio driver\n". isa.c has nothing to print after "pca0" because the driver says that it doesn't use any i/o ports: pcaprobe() returns (-1) (which is a special code meaning `no ports') and the config line for pca0 doesn't specify a port so the iobase is 0 (iobase 0 is thus another special code meaning `no ports'. Apparently there was a convention that the device driver for devices with base port 0 should complete the description of the device and print a new line. pcaattach() did this. This behaviour was broken in two stages: First, isa.c was changed to always print a newline. Apparently some devices didn't follow the convention. The change fixed these devices and broke the pcaudio message to "pca0\n PC speaker audio driver\n". Second, pcaudio was changed to match the changed isa.c. There is no way to undo the newline and the driver wants to be verbose so the end result is a useless line printed by isa.c. This is particularly annoying because the driver lies about the ports that it uses. It actually uses IO_TIMER1 and IO_PPI. The config struct has no way to represent multiple ports per driver, and the config line doesn't use either because IO_TIMER1 should conflict with the clock "driver" and IO_PPI would conflict with keyboard drivers. The config struct also has no way to represent ranges of ports. This is kludged around by having drivers return the number of ports, or (-1) for no ports (0 would be a better value but it means `no device'). The config struct also has no way to represent individual bits within ports. Both IO_TIMER1 and IO_PPI have some bits shared by the pcaudio driver and the clock/syscons driver, and some bits not shared. This is kludged around by doing sloppy conflict checking. Bruce