Bug 2 - Kernel cannot be built with soundcard driver
Summary: Kernel cannot be built with soundcard driver
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: FreeBSD Core Team
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 1994-09-15 18:00 UTC by cmf
Modified: 1998-09-15 01:00 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description cmf 1994-09-15 18:00:01 UTC
	Attempting to build a kernel with the soundcard driver
	will fail due to an unresolved reference to contigmalloc()
	from soundcard.o.

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.
How-To-Repeat: 
	Configure a kernel with the soundcard driver.
Comment 1 Garrett Wollman freebsd_committer freebsd_triage 1994-11-23 20:19:42 UTC
State Changed
From-To: open->closed

Sound driver fixed (some months ago). 

Comment 2 mcnab 1997-05-01 01:18:35 UTC
>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 rx0, 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.
Comment 3 ji 1998-01-03 15:29:35 UTC
>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:
Comment 4 nic 1998-09-15 00:53:47 UTC
>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.
Comment 5 huck 2008-03-26 00:58:16 UTC
>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.