From cmf@ins.infonet.net  Thu Sep 15 17:52:33 1994
Received: from localhost (s087.infonet.net [167.142.100.87]) by freefall.cdrom.com (8.6.8/8.6.6) with ESMTP id RAA29229 for <FreeBSD-gnats-submit@freefall.cdrom.com>; Thu, 15 Sep 1994 17:52:28 -0700
Received: (cmf@localhost) by localhost (8.6.8/8.6.5) id TAA13649; Thu, 15 Sep 1994 19:52:19 -0500
Message-Id: <199409160052.TAA13649@localhost>
Date: Thu, 15 Sep 1994 19:52:19 -0500
From: cmf@ins.infonet.net
Reply-To: cmf@ins.infonet.net
To: FreeBSD-gnats-submit@freefall.cdrom.com
Subject: Kernel cannot be built with soundcard driver
X-Send-Pr-Version: 3.2

>Number:         2
>Category:       kern
>Synopsis:       Kernel cannot be built with soundcard driver
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    core (FreeBSD core team)
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Sep 15 18:00:01 1994
>Closed-Date:    Wed Nov 23 12:19:42 PST 1994
>Last-Modified:  Mon Sep 14 17:00:00 PDT 1998
>Originator:     Carl M. Fongheiser
>Release:        FreeBSD 2.0.0 (Development) i386
>Organization:
Just me at home
>Environment:

	-current as of yesterday morning

>Description:

	Attempting to build a kernel with the soundcard driver
	will fail due to an unresolved reference to contigmalloc()
	from soundcard.o.

>How-To-Repeat:

	Configure a kernel with the soundcard driver.

>Fix:
	
	I'm not sure.  I'm not familiar enough with the VM system to produce
	a fix.  kern_malloc.c in 1.1.5.1 contained a contigmalloc(), but I'm
	not sure if a) it will work and b) if it's legal.

>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed 
State-Changed-By: wollman 
State-Changed-When: Wed Nov 23 12:19:42 PST 1994 
State-Changed-Why:  
Sound driver fixed (some months ago). 

From: huck@nosc.mil
To: FreeBSD-gnats-submit@freebsd.org
Cc:  Subject: PS/2 mouse disabled after kernel rebuild 
Date: Tue, 25 Mar 2008 19:58:16 -0500 (EST)

 >Submitter-Id:   current-users
 >Originator:     Craig Huckabee (huck@nosc.mil)
 >Organization:   none
 >Confidential:   no
 >Synopsis:       psm0 is marked as disabled after kernel rebuild
 >Severity:       non-critical
 >Priority:       medium
 >Category:       misc
 >Release:        FreeBSD 3.0-CURRENT i386
 >Class:          sw-bug 
 >Environment: 
 
 	3.0-CURRENT as of Nov. 13, 6:35 am EST
         Hardware :
                 ASUS SP3G w/ PS/2 mouse option
 
                 
 >Description: 
 
 	After rebuilding a kernel and installing it, the kernel is 
         installed with the psm0 driver disabled by default.  It can
         be re-enabled by using the boot time kernel configuration
         editor, but it's annoying that you have to do this each time
         you rebuild the kernel.
 
 >How-To-Repeat: 
 
 	Build a new kernel with the psm0 driver and install it.  
         Each time this process is repeated the psm0 driver will
         show up as "disabled, not probed" on initial reboot.
 
 
 >Fix: 
 	
 	Boot into the configuration editor and re-enable the psm0
 
         driver.

From: mcnab@nas.nasa.gov
To: freebsd-gnats-submit@freebsd.org
Cc:  Subject: PS/2 mouse cause kernel trap and hang
Date: Wed, 30 Apr 1997 17:18:35 -0700 (PDT)

 >Submitter-Id:	net
 >Originator:	A. David McNab
 >Organization:	MRJ
 >Confidential:	no
 >Synopsis:	PS/2 mouse cause kernel trap and hang
 >Severity:	critical
 >Priority:	medium
 >Category:	i386
 >Class:		sw-bug
 >Release:	2.2.1-RELEASE #0
 >Environment:	FreeBSD aargh.nas.nasa.gov 2.2.1-RELEASE FreeBSD 2.2.1-RELEASE #0: Wed Apr 30 15:32:13 PDT 1997     root@aargh.nas.nasa.gov:/usr/src/sys/compile/MCNAB  i386
 >Description:
 I have a Logitech MouseMan mouse with PS/2 connector,
 plus std. 101-key kbd with small 6-pin style connector.
 Machine is a P6 200MHz with ASUS P/I-P65UP5 M/B.
 Kernel is custom but nothing unusual.  psm0 is enabled
 (standard args) with PSM_CHECKSYNC option turned on.
 
 Original manifestation of problem was a "hang" during
 X activity--no response from keyboard or mouse--followed
 in a few seconds by a reboot.  Turned on DDB option and
 same would happen, except no reboot--sc waiting for input.
 Turned on moused and sat on sc vt0 futzing around, eventually
 got:
 
 instruction pointer     = 0x8:0xf01887cb
 stack pointer           = 0x10:0xf01a1f3c
 frame pointer           = 0x10:0xf01a1f40
 code segment            = base 0x0, limit 0xfffff, type 0x1b
                         = DPL 0, pres 1, def32 1, gran 1
 processor eflags        = interrupt enabled, IOPL = 0
 current process         = Idle
 interrupt mask          = tty
 kernel: type 29 trap, code=0
 Stopped at      _read_kbd_data_no_wait+0x37:    andl    $0xff,%eax
 
 Actually I could 'cont' from here with no noticeable
 lossage, but that's not much help since I can't recover
 once X is up.  2.2.1 is useless with this h/w config,
 and since I need the new de0 driver 2.1.7 won't do
 either.
 >How-To-Repeat:
 Hook up a PS/2 mouse, start moused, and turn on the
 mouse pointer..  The problem will happen as soon as
 you stop trying to replicate it and start doing something
 more interesting :^).
 >Fix:
 Buy a better trained rodent.

From: ji@research.att.com
To: freebsd-gnats-submit@freebsd.org
Cc:  Subject: 1/2/98 cvsup followed by make/make install builds bad libc.so
Date: Sat, 3 Jan 1998 07:29:35 -0800 (PST)

 >Submitter-Id:	net
 >Originator:	John Ioannidis
 >Organization:	AT&T Labs - Research
 >Confidential:	no
 >Synopsis:	1/2/98 cvsup followed by make/make install builds bad libc.so
 >Severity:	critical
 >Priority:	high
 >Category:	conf
 >Class:		sw-bug
 >Release:	2.2.5-STABLE
 >Environment:	FreeBSD elf.tla.org 2.2.5-STABLE FreeBSD 2.2.5-STABLE #1: Mon Dec 22 23:05:50 EST 1997     root@elf.tla.org:/usr/cvsrc/src/sys/compile/ELF  i386
 
 >Description:
 my previous complete cvsup and build was  around December 22nd. The system
 worked fine. I ran cvsup on January 2nd, and when it completed, did
 a make in /usr/src followed by make install. Right after libc.so.3.0
 was installed, all dynamically linked executables (including the install
 executable!) were failing, complaining that "___generic_syscall" could
 not be loaded. Needless to say, I had to do a full restore from
 backups (I didn't lose anything, but it was annoying).
 >How-To-Repeat:
 cvsup, followed by "make" and "make install"
 >Fix:
 

From: nic@amicare.com
To: freebsd-gnats-submit@freebsd.org
Cc:  Subject: PS/2 mouse crashed XFree86
Date: Mon, 14 Sep 1998 16:53:47 -0700 (PDT)

 >Submitter-Id:	net
 >Originator:	Nic Cheneweth
 >Organization:	AmiCare, Inc.
 >Confidential:	no
 >Synopsis:	PS/2 mouse crashed XFree86
 >Severity:	critical
 >Priority:	high
 >Category:	i386
 >Class:		sw-bug
 >Release:	2.2.6 - 4 CD set
 >Environment:	FreeBSD 2.2.6-RELEASE #0: Wed Mar 25 02:28:49 GMT 1998  jkh@time.cdrom.com:/usr/src/sys/compile/GENERIC  i386
 >Description:
 New clean installation of 2.2.6. Within moments of activating "startx" and using mouse, machine locks up, doesn't respond to ping, etc, etc.. total reboot.  If you don't touch the mouse, it will take longer to crash, but still.
 >How-To-Repeat:
 Reboot, run startx, touch mouse or wait.
 >Fix:
 have seen some references to it in reports, but no fix.
>Unformatted:



