first time module dev question: undefined reference to 'memset'

[M. Warner Losh]

In message: <d3dd0e360709250410x678fcbbdn6863f7c13c558fe6 at mail.gmail.com>
            "Michael Iedema" <michael at askozia.com> writes:
: Hello again,
: 
: > >  what about s/patchmenset/.BEGIN/ and s/unpatchememset/.END/ ?
: >
: > Thanks! Everything's building nicely and it's now cleaning up after itself.
: 
: It's clear to me now that building cleanly is still not the end of the
: road here. My module "OSLEC" is loading and being recognized by a
: module depending on it "Zaptel." This dependent module is also being
: recognized and correctly utilized by the Asterisk process in my
: project. However, as soon as the echo canceller (OSLEC) is activated
: by Asterisk it page faults.

OK.

: I'm thinking that the symbols that zaptel needs from oslec are not
: being recognized, or additional libkern functions need to be patched
: in.

Unlikely.  More likely you've not initialized a pointer.  You would
get a symbol undefined error if there were problems with symbols.

: I've provided below as much information as I can. Can anyone help me
: take the next step in debugging this?

Look at the section on kernel debugging in the FreeBSD handbook.
You'll want to look at things like adding options DDB and options KDB
to your kernel so you can do rudimentary debugging.  Or setting up a
serial port to do debugging over serial...

: Fatal trap 12: page fault while in kernel mode
: fault virtual address = 0x0

Null pointer

: fault code = supervisor read, page not present

You tried to read through it.

: instruction pointer = 0x20:0xc04f3867
: stack pointer = 0x28:0xcd4f19d8
: frame pointer = 0x28:0xcd4f19e8
: code segment = base 0x0, limit 0xfffff, type 0x1b
: 			= DPL 0, pres 1, def32 1, gran 1
: processor eflags = interrupt enabled, resume, IPOL = 0
: current process	= 198 (asterisk)
: trap number = 12
: panic: page fault
: 
: 
: Following this page[1] I see that the IP is closest to:
: 
: c04f3808 T __mac_set_file
: c04f3814 T __mac_set_link
: c04f3820 T mac_syscall
: c04f382c T malloc_last_fail
: c04f383c t malloc_type_zone_allocated

It would be in here somewhere.  This changes my view to be biased
towards 'you may be dancing in memory, corrupting things' or 'The
symbols you have don't match up to the kernel you booted'.  DDB will
take care of that.

: c04f38a8 T malloc_type_allocated
: c04f38c8 T malloc_type_freed
: 
: 
: --------------------------------------------------
: Symbols missing from my oslec and zaptel kernel modules are as follows:
: 
: oslec
: U M_DEVBUF
: U free
: U malloc
: U malloc_init
: U malloc_uninit
: U memcpy
: U module_register_init
: U printf
: 
: zaptel
: U _mtx_lock_flags
: U _mtx_lock_spin_flags
: U _mtx_unlock_flags
: U _mtx_unlock_spin_flags
: U bcmp
: U bcopy
: U bzero
: U copyin
: U destroy_dev
: U dev_ref
: U devclass_find
: U eventhandler_deregister
: U eventhandler_find_list
: U eventhandler_register
: U free
: U kthread_create
: U kthread_exit
: U make_dev
: U malloc
: U malloc_init
: U malloc_uninit
: U memcpy
: U module_register_init
: U msleep
: U mtx_destroy
: U mtx_init
: U oslec_echo_can_create
: U oslec_echo_can_free
: U oslec_echo_can_traintap
: U oslec_echo_can_update
: U printf
: U selrecord
: U selwakeup
: U snprintf
: U strcmp
: U strlen
: U strncpy
: U sysctl__children
: U sysctl_add_oid
: U sysctl_ctx_free
: U sysctl_ctx_init
: U sysctl_handle_int
: U uiomove
: U unit2minor
: U wakeup
: 
: 
: 
: [1] http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/advanced.html#KERNEL-PANIC-TROUBLESHOOTING
: _______________________________________________
: freebsd-drivers at freebsd.org mailing list
: http://lists.freebsd.org/mailman/listinfo/freebsd-drivers
: To unsubscribe, send any mail to "freebsd-drivers-unsubscribe at freebsd.org"
: 
: