Attempting to build a kernel with the soundcard driver
will fail due to an unresolved reference to contigmalloc()
I'm not sure. I'm not familiar enough with the VM system to produce
a fix. kern_malloc.c in 184.108.40.206 contained a contigmalloc(), but I'm
not sure if a) it will work and b) if it's legal.
Configure a kernel with the soundcard driver.
Sound driver fixed (some months ago).
>Originator: A. David McNab
>Synopsis: PS/2 mouse cause kernel trap and hang
>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 email@example.com:/usr/src/sys/compile/MCNAB i386
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
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
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 :^).
Buy a better trained rodent.
>Originator: John Ioannidis
>Organization: AT&T Labs - Research
>Synopsis: 1/2/98 cvsup followed by make/make install builds bad libc.so
>Environment: FreeBSD elf.tla.org 2.2.5-STABLE FreeBSD 2.2.5-STABLE #1: Mon Dec 22 23:05:50 EST 1997 firstname.lastname@example.org:/usr/cvsrc/src/sys/compile/ELF i386
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).
cvsup, followed by "make" and "make install"
>Originator: Nic Cheneweth
>Organization: AmiCare, Inc.
>Synopsis: PS/2 mouse crashed XFree86
>Release: 2.2.6 - 4 CD set
>Environment: FreeBSD 2.2.6-RELEASE #0: Wed Mar 25 02:28:49 GMT 1998 email@example.com:/usr/src/sys/compile/GENERIC i386
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.
Reboot, run startx, touch mouse or wait.
have seen some references to it in reports, but no fix.
>Originator: Craig Huckabee (firstname.lastname@example.org)
>Synopsis: psm0 is marked as disabled after kernel rebuild
>Release: FreeBSD 3.0-CURRENT i386
3.0-CURRENT as of Nov. 13, 6:35 am EST
ASUS SP3G w/ PS/2 mouse option
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.
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.
Boot into the configuration editor and re-enable the psm0