From scsprong@wit381007.student.utwente.nl  Fri Jul 10 09:12:30 1998
Received: from wit381007.student.utwente.nl (wit381007.student.utwente.nl [130.89.232.187])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA00890
          for <FreeBSD-gnats-submit@freebsd.org>; Fri, 10 Jul 1998 09:12:28 -0700 (PDT)
          (envelope-from scsprong@wit381007.student.utwente.nl)
Received: (from scsprong@localhost)
	by wit381007.student.utwente.nl (8.8.8/8.8.7) id SAA21205;
	Fri, 10 Jul 1998 18:11:06 +0200 (CEST)
	(envelope-from scsprong)
Message-Id: <199807101611.SAA21205@wit381007.student.utwente.nl>
Date: Fri, 10 Jul 1998 18:11:06 +0200 (CEST)
From: "S.C. Sprong" <scsprong@wit381007.student.utwente.nl>
Reply-To: s.c.sprong@student.utwente.nl
To: FreeBSD-gnats-submit@freebsd.org
Subject: keyboard problems during login immediately after boot
X-Send-Pr-Version: 3.2

>Number:         7234
>Category:       kern
>Synopsis:       [kbd] keyboard problems during login immediately after boot
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Jul 10 09:20:00 PDT 1998
>Closed-Date:    Sat Jul 30 01:09:27 GMT 2005
>Last-Modified:  Sat Jul 30 01:09:27 GMT 2005
>Originator:     S.C. Sprong
>Release:        FreeBSD 2.2.6-RELEASE i386
>Organization:
>Environment:

The machine is a good quality Pentium with proven hardware (for the IBM
PC clone world anyway). There are no silly overclockings or such.
The relevant reatures for this problem are:

- a rather old keyboard connected with a ~2 m elongation(?) cable and a
  db/ps2 convertor, which may or may not push this set-up out of spec. 

- rc.conf settings:

keymap="us.iso"         # keymap in /usr/share/syscons/keymaps/* (or NO).
keyrate="fast"          # keyboard rate to: slow, normal, fast (or NO).
keybell="NO"            # bell to duration.pitch or normal or visual (or NO).
keychange="NO"          # function keys default values (or NO).
cursor="destructive"    # cursor type {normal|blink|destructive} (or NO).
scrnmap="NO"            # screen map in /usr/share/syscons/scrnmaps/* (or NO).
font8x16="iso-8x16"     # font 8x16 from /usr/share/syscons/fonts/* (or NO).
font8x14="iso-8x14"     # font 8x14 from /usr/share/syscons/fonts/* (or NO).
font8x8="iso-8x8"	#

- a custom rc.local with the following syscons twiddling:
  set terminals to 30 rows, iso latin characters

	if [ -f /usr/sbin/vidcontrol ]; then
	    for tty in /dev/ttyv?
        	do
        	vidcontrol -f 8x14 iso-8x14.fnt <$tty
        	vidcontrol VGA_80x30 <$tty
    	done
	fi

as suggested in the freebsd.misc newsgroup some time ago.


>Description:

Sometimes right after booting, the keyboard produces garbage non ASCII
characters which make it impossible to login. There is no discernible
pattern to this character mess. Ctl-D, Ctl-C, etc. don't work. 

Remote login reveals that the boot sequence has always completed
successfully. Actions that update or display messages on the console,
such as (remote) su root and (remote) kill -HUP 1, display correctly on
the console (ttyv0), which suggests that the video part of syscons works. 

Unplugging or swapping the keyboard doesn't work. I have several brands
of (elderly) keyboards, and this problem happened with all of them.
 
At one time, login exited on signal 3, but this could be the result of
my clumsy fiddling. The core dump is available on request.

My suspicion is that some hardware timing (reset of the keyboard processor?)
is sometimes off, which triggers a bug in the syscons device driver.

As I started a private problem log with the installation of release 2.2.6,
I do not know whether this problem occurred in earlier versions I used.


>How-To-Repeat:

This problem occurs infrequently, and is not repeatable.


>Fix:

The ability to completely reset the syscons driver would not be a luxury.
	
A suggested workaround that I haven't tried yet is from problem report
i386/3082:
	kbdcontrol -r fast >/dev/ttyv?
which I shall try as soon as the opportunity arises.
As a sidenote: kbd_mode, the suggested panacaea for all keyboard ills, has
not had any effect whatsoever, for good or for bad.
>Release-Note:
>Audit-Trail:

From: Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp>
To: s.c.sprong@student.utwente.nl
Cc: FreeBSD-gnats-submit@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp
Subject: Re: kern/7234: keyboard problems during login immediately after boot 
Date: Thu, 23 Jul 1998 00:01:32 +0900

 >>Number:         7234
 >>Category:       kern
 >>Synopsis:       keyboard problems during login immediately after boot
 [snip]
 >>Release:        FreeBSD 2.2.6-RELEASE i386
 >>Environment:
 >
 >The machine is a good quality Pentium with proven hardware (for the IBM
 >PC clone world anyway). There are no silly overclockings or such.
 >The relevant reatures for this problem are:
 >
 >- a rather old keyboard connected with a ~2 m elongation(?) cable and a
 >  db/ps2 convertor, which may or may not push this set-up out of spec. 
 >
 >- rc.conf settings:
 >
 >keymap="us.iso"         # keymap in /usr/share/syscons/keymaps/* (or NO).
 >keyrate="fast"          # keyboard rate to: slow, normal, fast (or NO).
 >keybell="NO"            # bell to duration.pitch or normal or visual (or NO).
 >keychange="NO"          # function keys default values (or NO).
 >cursor="destructive"    # cursor type {normal|blink|destructive} (or NO).
 >scrnmap="NO"            # screen map in /usr/share/syscons/scrnmaps/* (or NO).
 >font8x16="iso-8x16"     # font 8x16 from /usr/share/syscons/fonts/* (or NO).
 >font8x14="iso-8x14"     # font 8x14 from /usr/share/syscons/fonts/* (or NO).
 >font8x8="iso-8x8"	#
 >
 >- a custom rc.local with the following syscons twiddling:
 >  set terminals to 30 rows, iso latin characters
 >
 >	if [ -f /usr/sbin/vidcontrol ]; then
 >	    for tty in /dev/ttyv?
 >        	do
 >        	vidcontrol -f 8x14 iso-8x14.fnt <$tty
 >        	vidcontrol VGA_80x30 <$tty
 >    	done
 >	fi
 >
 >as suggested in the freebsd.misc newsgroup some time ago.
 
 I would ask you to try the following steps to help us to diagnose
 your problem.
 
 1. Set the cursor type to "normal", rather than destructive, and
    see if it makes any difference.
 2. Leave the cursor type to "normal", remove the above shell script
    lines from rc.local and see if things are improved.
 3. If you still have difficulty, set font8x16, font8x14, font8x8 to "NO".
    I would expect the console work as it should at this step, because
    no fancy settings are done any more.
 4. Then add the following lines to rc.local. (Notice that there is not
    "vidcontrol -f 8x14..." line here. It is OK, because the VGA_80x30 
    mode will use the built-in 8x16 font.)
 
 	if [ -f /usr/sbin/vidcontrol ]; then
 	    for tty in /dev/ttyv?
         	do
         	vidcontrol VGA_80x30 <$tty
     	    done
 	fi
 
 Tell me the brand of your video card when you report the results.
 Thank you for your cooperation.
 
 Kazu
 yokota@freebsd.org
Responsible-Changed-From-To: freebsd-bugs->yokota 
Responsible-Changed-By: yokota 
Responsible-Changed-When: Mon Aug 3 02:34:07 PDT 1998 
Responsible-Changed-Why:  
I will be tracking this one. 

From: Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp>
To: s.c.sprong@student.utwente.nl
Cc: FreeBSD-gnats-submit@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp
Subject: Re: kern/7234: keyboard problems during login immediately after boot 
Date: Sat, 26 Sep 1998 13:42:20 +0900

 I have not heard from you since you reported the problem below.  Did
 you try any tests I suggested earlier?
 
 Another thing I can think of trying is to set the driver flags of
 syscons to 0x20.  This flag will skip keyboard reset when syscons
 probes the keyboard and the video card.
 
 Hope I will hear from you soon.
 
 Kazu
 yokota@FreeBSD.ORG
 
 >>>Number:         7234
 >>>Category:       kern
 >>>Synopsis:       keyboard problems during login immediately after boot
 >[snip]
 >>>Release:        FreeBSD 2.2.6-RELEASE i386
 >>>Environment:
 [...]

From: "S.C.Sprong" <scsprong@wit381007.student.utwente.nl>
To: Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp>
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: kern/7234: keyboard problems during login immediately after
 boot 
Date: Sat, 26 Sep 1998 14:33:36 +0200 (CEST)

 On Sat, 26 Sep 1998, Kazutaka YOKOTA wrote:
 
 >I have not heard from you since you reported the problem below.  Did
 >you try any tests I suggested earlier?
 
 Actually yes. It was a gradual process but I think I narrowed it down.
 The main reason I didn't keep you steadily informed is that I rather
 give a sound story without too vague assertions.
 
 I automatically assume that you and the other GNATTERS are constantly
 deluged in e-mail. Therefore sending several incomplete status reports
 showing little or no progress will waste your time.
 
 Anyway, here are some of the points:
 
 - This error is very rare. It only happens with a soft reboot. Since
   I generally have long uptimes, the error becomes more rare for me.
   I keep a system log with important events, This error happened
   three times in 6 months.
 
 - This error does not happen while booting into DOS. As I wrote
   earlier, I cannot remember if it ocurred with FreeBSD < 2.2.5.
 
 - Your own post arrived about 4 weeks later, just after I upgraded
   to 2.2.7. In fact yours was the first mail shortly after reboot!
   I thought, scratch that bug report, since with a new OS version
   the system has changed too much. In the following week, while
   composing an apologising reply, the error happened.
 
 - In fact, in the last months I changed some of the components
   (I dare not say 'upgraded', you know how it is with PC junk)
   therefore my system is not the same as it was at the time of
   the first report.
 
 - However, I pinpointed the on-board keyboard controller as the
   culprit.
 
 - The kernel config BROKEN_KEYBOARD_RESET solved it as far as I
   can see.
 
 
 My theory, which is mine, for now:
 
 - The motherboard in question is an Asus P/I-XP55T2P4.
 
 - Some of my friends who run FreeBSD and also have a T2P4, but not
   the ATX version, do not have the problem I reported.
 
 - It turns out that Asus used several brands of keyboard controller
   for its T2P4 series. Mine is a Holtek, and I still must open my
   case to verify the exact type, for they made a least three
   versions: 6542B, 6547A, and 6547C. Holtek has a website that also
   contains their datasheets. They also have an e-mail contact which
   I plan to write to if time permits.
 
 - Either the Holtek controller has race conditions which are
   sometimes met, or mine is damaged. I plan to use this one as
   long as it works. I'm not going to replace it in the following
   months.
 
 From reading the source I know that syscons probes and resets the
 keyboard. It may or may not be that it does it wrongly or too fast.
 
 The most interesting side effect is of course that I can make login
 crash, which makes for a nice denial of service. I learned that
 I can crash login at will by bashing in semi-random 8bit characters.
 I can do this with a working syscons too. If it can be done from
 a remote terminal login, FreeBSD is in trouble.
 
 If login realy accepts 8-bit characters, a sanity check on them
 could a valuable addition to the code.
 
 >Another thing I can think of trying is to set the driver flags of
 >syscons to 0x20.  This flag will skip keyboard reset when syscons
 >probes the keyboard and the video card.
 
 Is this the same as BROKEN_KEYBOARD_RESET?
 
 Although this story is far from over, I hope that this rambling
 will have some value for the bughunters.
  
 well met,
 scsprong
 

From: Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp>
To: "S.C.Sprong" <scsprong@wit381007.student.utwente.nl>
Cc: FreeBSD-gnats-submit@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp
Subject: Re: kern/7234: keyboard problems during login immediately after boot 
Date: Sat, 26 Sep 1998 22:33:43 +0900

 Thank you for your detailed report.  You gave me a lot of material
 to think about.
 
 >On Sat, 26 Sep 1998, Kazutaka YOKOTA wrote:
 >
 >>I have not heard from you since you reported the problem below.  Did
 >>you try any tests I suggested earlier?
 >
 >Actually yes. It was a gradual process but I think I narrowed it down.
 >The main reason I didn't keep you steadily informed is that I rather
 >give a sound story without too vague assertions.
 [...]
  
 >- However, I pinpointed the on-board keyboard controller as the
 >  culprit.
 >
 >- The kernel config BROKEN_KEYBOARD_RESET solved it as far as I
 >  can see.
 
 Um, the config option BROKEN_KEYBOARD_RESET has nothing to do with
 keyboard probe.  The name has confused so many people :-) 
 This option select an alternative way of resetting CPU.  In AT
 architecture, the keyboard controller can genetate a pulse to reset
 the CPU.  However, some keyboard controllers have compatibility 
 problem.  This option for such keyboard controllers. It does not
 affect how the keyboard is reset when the keyboard is probed by
 the console driver.
 
 >My theory, which is mine, for now:
 >
 >- The motherboard in question is an Asus P/I-XP55T2P4.
 >
 >- Some of my friends who run FreeBSD and also have a T2P4, but not
 >  the ATX version, do not have the problem I reported.
 >
 >- It turns out that Asus used several brands of keyboard controller
 >  for its T2P4 series. Mine is a Holtek, and I still must open my
 >  case to verify the exact type, for they made a least three
 >  versions: 6542B, 6547A, and 6547C. Holtek has a website that also
 >  contains their datasheets. They also have an e-mail contact which
 >  I plan to write to if time permits.
 >
 >- Either the Holtek controller has race conditions which are
 >  sometimes met, or mine is damaged. I plan to use this one as
 >  long as it works. I'm not going to replace it in the following
 >  months.
 >
 >>From reading the source I know that syscons probes and resets the
 >keyboard. It may or may not be that it does it wrongly or too fast.
 
 The keyboard probe routine caused troubles in the past. Although
 it rarely has problems recently, it is quite possible it still has
 compatibility problems with some keyboard controllers.
 
 >The most interesting side effect is of course that I can make login
 >crash, which makes for a nice denial of service. I learned that
 >I can crash login at will by bashing in semi-random 8bit characters.
 >I can do this with a working syscons too. If it can be done from
 >a remote terminal login, FreeBSD is in trouble.
 
 You are right. We had better check 'login'.
 
 >If login realy accepts 8-bit characters, a sanity check on them
 >could a valuable addition to the code.
 >
 >>Another thing I can think of trying is to set the driver flags of
 >>syscons to 0x20.  This flag will skip keyboard reset when syscons
 >>probes the keyboard and the video card.
 >
 >Is this the same as BROKEN_KEYBOARD_RESET?
 
 No, the flag will avoid resetting keyboard but employs a simple 
 check routine to see if a keyboard is present. This is considered
 bit safer.
 
 >Although this story is far from over, I hope that this rambling
 >will have some value for the bughunters.
 
 It certainly will. Thank you.
 
 Kazu

From: David Pick <D.M.Pick@qmw.ac.uk>
To: freebsd-gnats-submit@FreeBSD.org, s.c.sprong@student.utwente.nl
Cc:  
Subject: Re: kern/7234: keyboard problems during login immediately after boot
Date: Thu, 02 Mar 2000 17:59:31 +0000

 This is a multipart MIME message.
 
 --==_Exmh_-21454021340
 Content-Type: text/plain; charset=us-ascii
 
 
 I have been having the same problems on my Toshiba Libretto 110.
 
 Again, it's unpredictable when it occours, but I'm not using any
 external keyboard, and it happens with a similar frequency regardless
 of the presence or absence on my external PS/2 trackerball.
 
 As in the original report: the screen appears to work normally as does
 the network. The keyboard problem seems to affect both the basic syscons
 driver and the X display equally (together or not at all).
 
 My kernel has no unusual flags or options selected: just as one might
 expect for a build for a laptop with PCCard support. The configuration
 file is attached to this message.
 
 One thing that *does* seem to make a difference is that the problem
 *seems* to happen less frequently if my PCCard ethernet adaptor is
 not inserted as the machine starts up, but I put it in later. I also
 have a suspicion (but can't demonstrate it) that if I succeed in
 getting a character typed on the keyboard at the first "login" prompt
 before whatever happens, happens, it prevents the problem: not doing
 so *seems* to make the problem happen more often.
 
 Compared to the original report, since my machine is a laptop and
 usually rebooted a couple of times a day, the problem is rather
 more annoying ;-(
 
 -- 
 	David Pick
 
 
 --==_Exmh_-21454021340
 Content-Type: text/plain ; name="OPTIO"; charset=us-ascii
 Content-Description: OPTIO
 Content-Disposition: attachment; filename="OPTIO"
 
 #
 # OPTIO for Libretto 110: based on GENERIC -- Generic machine with WD/AHx/NCR/BTx family disks
 #
 # For more information on this file, please read the handbook section on
 # Kernel Configuration Files:
 #
 #    http://www.freebsd.org/handbook/kernelconfig-config.html
 #
 # The handbook is also available locally in /usr/share/doc/handbook
 # if you've installed the doc distribution, otherwise always see the
 # FreeBSD World Wide Web server (http://www.FreeBSD.ORG/) for the
 # latest information.
 #
 # An exhaustive list of options and more detailed explanations of the
 # device lines is also present in the ./LINT configuration file. If you are
 # in doubt as to the purpose or necessity of a line, check first in LINT.
 #
 # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.143.2.24 1999/12/05 01:56:42 luoqi Exp $
 
 machine		"i386"
 cpu		"I586_CPU"
 #cpu		"I686_CPU"
 ident		OPTIO
 maxusers	32
 
 options		"EXT2FS"		#Linux "ext2fs" Filesystem
 
 options 	MATH_EMULATE		#Support for x87 emulation
 options 	INET			#InterNETworking
 options 	FFS			#Berkeley Fast Filesystem
 options 	FFS_ROOT		#FFS usable as root device [keep this!]
 options 	MFS			#Memory Filesystem
 options 	MFS_ROOT		#MFS usable as root device, "MFS" req'ed
 options 	NFS			#Network Filesystem
 options 	NFS_ROOT		#NFS usable as root device, "NFS" req'ed
 options 	MSDOSFS			#MSDOS Filesystem
 options 	"CD9660"		#ISO 9660 Filesystem
 options 	"CD9660_ROOT"		#CD-ROM usable as root. "CD9660" req'ed
 options 	PROCFS			#Process filesystem
 options 	"COMPAT_43"		#Compatible with BSD 4.3 [KEEP THIS!]
 options 	SCSI_DELAY=15000	#Be pessimistic about Joe SCSI device
 options 	UCONSOLE		#Allow users to grab the console
 options 	FAILSAFE		#Be conservative
 options 	USERCONFIG		#boot -c editor
 options 	VISUAL_USERCONFIG	#visual boot -c editor
 options 	KTRACE			#ktrace(1) syscall trace support
 options 	SYSVSHM			#SYSV-style shared memory
 options 	SYSVMSG			#SYSV-style message queues
 options 	SYSVSEM			#SYSV-style semaphores
 
 config		kernel	root on wd0
 
 # To make an SMP kernel, the next two are needed
 #options 	SMP			# Symmetric MultiProcessor Kernel
 #options 	APIC_IO			# Symmetric (APIC) I/O
 # Optionally these may need tweaked, (defaults shown):
 #options 	NCPU=2			# number of CPUs
 #options 	NBUS=4			# number of busses
 #options 	NAPIC=1			# number of IO APICs
 #options 	NINTR=24		# number of INTs
 
 controller	isa0
 controller	pnp0			# PnP support for ISA
 controller	pci0
 
 # Floppy drives
 controller	fdc0	at isa? disable port "IO_FD1" bio irq 6 drq 2
 disk		fd0	at fdc0 drive 0
 
 # IDE controller and disks
 #options		"CMD640"	# work around CMD640 chip deficiency
 controller	wdc0	at isa? port "IO_WD1" bio irq 14
 disk		wd0	at wdc0 drive 0
 
 controller	wdc1	at isa? disable port "IO_WD2" bio irq 15
 disk		wd2	at wdc1 drive 0
 
 # ATAPI devices
 #options		ATAPI		#Enable ATAPI support for IDE bus
 #options		ATAPI_STATIC	#Don't do it as an LKM
 device		acd0		#IDE CD-ROM
 #device		wfd0		#IDE Floppy (e.g. LS-120)
 
 # SCSI Controllers
 # A single entry for any of these controllers (ncr, ahb, ahc) is
 # sufficient for any number of installed devices.
 #controller	ncr0		# NCR/Symbios Logic
 #controller	ahb0		# EISA AHA1742 family
 #controller	ahc0		# AHA2940 and onboard AIC7xxx devices
 #controller	amd0		# AMD 53C974 (Teckram DC-390(T))
 #controller	isp0		# Qlogic family
 #controller	dpt0		# DPT Smartcache - See LINT for options!
 
 #controller	adv0	at isa? port ? cam irq ?
 #controller	adw0
 #controller	bt0	at isa? port ? cam irq ?
 #controller	aha0	at isa? port ? cam irq ?
 controller	aic0	at isa? disable port ? cam irq ?
 
 # SCSI peripherals
 # Only one of each of these is needed, they are dynamically allocated.
 controller	scbus0		# SCSI bus (required)
 device		da0		# Direct Access (disks)
 device		sa0		# Sequential Access (tape etc)
 device		cd0		# CD
 device		pass0		# Passthrough device (direct SCSI)
 
 # atkbdc0 controls both the keyboard and the PS/2 mouse
 controller	atkbdc0	at isa? port IO_KBD tty
 device		atkbd0	at isa? tty irq 1
 device		psm0	at isa? tty irq 12
 
 device		vga0	at isa? port ? conflicts
 
 # splash screen/screen saver
 pseudo-device	splash
 
 # syscons is the default console driver, resembling an SCO console
 device		sc0	at isa? tty
 
 # Enable this and PCVT_FREEBSD for pcvt vt220 compatible console driver
 #device		vt0	at isa? tty
 #options 	XSERVER			# support for X server
 #options 	FAT_CURSOR		# start with block cursor
 # If you have a ThinkPAD, uncomment this along with the rest of the PCVT lines
 #options 	PCVT_SCANSET=2		# IBM keyboards are non-std
 
 # Floating point support - do not disable.
 device		npx0	at isa? port IO_NPX irq 13
 
 # Power management support (see LINT for more options)
 device		apm0    at isa?	flags 0x31 # Advanced Power Management
 
 # PCCARD (PCMCIA) support
 controller	card0
 device		pcic0	at card?
 device		pcic1	at card?
 
 # Serial (COM) ports
 device		sio0	at isa? port "IO_COM1" flags 0x10 tty irq 4
 device		sio1	at isa? disable port "IO_COM2" tty irq 3
 device		sio2	at isa? disable port "IO_COM3" tty irq 5
 device		sio3	at isa? disable port "IO_COM4" tty irq 9
 
 # Parallel port
 device		ppc0	at isa? port? flags 0x40 net irq 7
 controller	ppbus0			# Parallel port bus (required)
 device		lpt0	at ppbus?	# Printer
 device		plip0	at ppbus?	# TCP/IP over parallel
 device		ppi0	at ppbus?	# Parallel port interface device
 controller	vpo0	at ppbus?	# Requires scbus and da0
 
 # PCI Ethernet NICs.
 #device		al0		# ADMtek AL981 (``Comet'')
 #device		ax0		# ASIX AX88140A
 #device		de0		# DEC/Intel DC21x4x (``Tulip'')
 #device		fxp0		# Intel EtherExpress PRO/100B (82557, 82558)
 #device		mx0		# Macronix 98713/98715/98725 (``PMAC'')
 #device		pn0		# Lite-On 82c168/82c169 (``PNIC'')
 #device		rl0		# RealTek 8129/8139
 #device		sf0		# Adaptec AIC-6915 DuraLAN (``Starfire'')
 #device		tl0		# Texas Instruments ThunderLAN
 #device		tx0		# SMC 9432TX (83c170 ``EPIC'')
 #device		vr0		# VIA Rhine, Rhine II
 #device		vx0		# 3Com 3c590, 3c595 (``Vortex'')
 #device		wb0		# Winbond W89C840F
 #device		xl0		# 3Com 3c90x (``Boomerang'', ``Cyclone'')
 
 # ISA Ethernet NICs.
 # Order is important here due to intrusive probes, do *not* alphabetize
 # this list of network interfaces until the probes have been fixed.
 # Right now it appears that the ie0 must be probed before ep0. See
 # revision 1.20 of this file.
 #device		ed0	at isa? port 0x280 net irq 10 iomem 0xd8000
 #device		ie0	at isa? port 0x300 net irq 10 iomem 0xd0000
 #device		ep0	at isa? port 0x300 net irq 10
 device		ep0	at isa? disable port 0x300 net irq 10
 #device		ex0	at isa? port? net irq?
 #device		fe0	at isa? port 0x300 net irq ?
 #device		le0	at isa? port 0x300 net irq 5 iomem 0xd0000
 #device		lnc0	at isa? port 0x280 net irq 10 drq 0
 #device		cs0	at isa? port 0x300 net irq ?
 # requires PCCARD (PCMCIA) support to be activated
 device		xe0	at isa? disable port? net irq ?
 
 # PCCARD NIC drivers.
 # ze and zp take over the pcic and cannot coexist with generic pccard
 # support, nor the ed and ep drivers they replace.
 #device		ze0	at isa? port 0x300 net irq 10 iomem 0xd8000
 #device		zp0	at isa? port 0x300 net irq 10 iomem 0xd8000
 
 # Pseudo devices - the number indicates how many units to allocated.
 pseudo-device	loop		# Network loopback
 pseudo-device	ether		# Ethernet support
 pseudo-device	sl	2	# Kernel SLIP
 pseudo-device	ppp	2	# Kernel PPP
 pseudo-device	tun	2	# Packet tunnel
 pseudo-device	pty	16	# Pseudo-ttys (telnet etc)
 pseudo-device	gzip		# Exec gzipped a.out's
 
 # The `bpfilter' pseudo-device enables the Berkeley Packet Filter.
 # Be aware of the administrative consequences of enabling this!
 # The number of devices determines the maximum number of
 # simultaneous BPF clients programs runnable.
 pseudo-device	bpfilter 8	#Berkeley packet filter
 
 # Other additions:
 
 pseudo-device	vn	2	# VNode driver (turns a file into a device)
 pseudo-device	snp	4	# Snoop device - to look at pty/vty/etc...
 
 # The PPP_BSDCOMP option enables support for compress(1) style entire
 # packet compression, the PPP_DEFLATE is for zlib/gzip style compression.
 # PPP_FILTER enables code for filtering the PPP data stream and selecting
 # events for resetting the demand dial activity times - requires bpfilter.
 # See pppd(8) for more details.
 
 options		PPP_BSDCOMP	# PPP BSD-compress support
 options		PPP_DEFLATE	# PPP zlib/deflate/gzip support
 options		PPP_FILTER	# enable bpf filtering
 
 # Allow user-mode programs to manipulate their local descriptor tables.
 # This option is required for the WINE Windows(tm) emulator, and is
 # not used for anything else (that we know of).
 
 options		USER_LDT
 
 # This option includes a MD5 routine in the kernel, this is used for
 # various authentication and privacy uses.
 
 options		"MD5"
 
 options		IPX		# Novell IPX/SPX protocols
 
 options		NETATALK	# AppleTalk protocols
 
 options		MROUTING	# Multicast routing
 
 options		IPFIREWALL	# Firewall
 options		IPFIREWALL_FORWARD	# Enable transparent forwarding
 options		IPFIREWALL_VERBOSE	# Say something about dropped packets
 options		"IPFIREWALL_VERBOSE_LIMIT=100"	# Say it only so many times
 #options		IPFIREWALL_DEFAULT_TO_ACCEPT	# Allow everything by default
 options		IPDIVERT	# Include divert sockets
 
 options		IPFILTER	# Include Darren Reed's ipfilter
 options		IPFILTER_LOG	# Include ipfilter logging
 
 device		pcm0	at isa? disable port ? tty irq 5 drq 1 flags 0x0
 
 
 --==_Exmh_-21454021340--
 
 
State-Changed-From-To: open->feedback 
State-Changed-By: linimon 
State-Changed-When: Thu Aug 26 03:28:05 GMT 2004 
State-Changed-Why:  
Is this still a problem with modern versions of FreeBSD? 


Responsible-Changed-From-To: yokota->freebsd-bugs 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Thu Aug 26 03:28:05 GMT 2004 
Responsible-Changed-Why:  
With bugmeister hat on, reassign from inactive committer. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=7234 

From: Brooks Davis <brooks@one-eyed-alien.net>
To: freebsd-gnats-submit@FreeBSD.org, s.c.sprong@student.utwente.nl
Cc:  
Subject: Re: kern/7234: [kbd] keyboard problems during login immediately after boot
Date: Mon, 1 Nov 2004 13:41:27 -0800

 FWIW, I used to see this problem now and then on a variety of hardware,
 but I haven't seen it in a couple years (IIRC.)  Probably I've gotten
 non-broken hardware since then or the problem has been fixed.
 
 -- Brooks
State-Changed-From-To: feedback->closed 
State-Changed-By: kris 
State-Changed-When: Sat Jul 30 01:09:09 GMT 2005 
State-Changed-Why:  
Feedback timeout, with evidence the problem is resolved. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=7234 
>Unformatted:
