Re: Converting pointer to vm_offset_t
2010/5/6 Fernando Apesteguía : > 2010/5/7 Garrett Cooper : >> 2010/5/5 Fernando Apesteguía : >>> Hi all, >>> >>> Is there a way to convert a (char *) pointer (or in general any >>> pointer) to a vm_offset_t type? >> >> Be wary that char * is not compat layer friendly though :(... > > Ummm... I'm asking this because I want to access an array of strings > that resides in user space. If I'm not wrong, I need to copy in with > proc_rwmem the array itself and then, every one of the strings, > right?. I can easily locate the array through the > proc->p_sysent->sv_psstrings (that is actually a vm_offset_t), but how > can I specify the offset for the strings? void* is the preferred method I'm told for direct address translation (32-bit to 32-bit or 64-bit to 64-bit). Not sure about the compatibility types (kind of why I was waiting for a reply from someone more knowledgeable). I know the equivalent for Linux, not FreeBSD [yet]. Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: How to get data from kernel module ?
On Thu, 6 May 2010, Ivan Voras wrote: > Date: Thu, 06 May 2010 20:12:07 +0200 > From: Ivan Voras > To: freebsd-hackers@freebsd.org > Subject: Re: How to get data from kernel module ? > > On 05/06/10 15:38, Lukáš Czerner wrote: > > Hi, > > > > I am creating a kernel module and I need to get some information from > > that module. I can do this with ioctl and pass the data to the > > user space but it seems a bit unpractical to me, because I do not know > > the amount of the data - it can differ. I do not know of any way to > > pass a list of structures to the userspace through ioctl - is there > > any? > > > > So my question is, is there any standard way in FreeBSD to do this ? > > In linux I would probably use the sysfs, but in FreeBSD I can not find > > anything similar, except just creating some virtual filesystem on my > > own and obviously this is not what I want to do. > > As others said, sysctl is one way to go, but might not be very convenient if > the amount of data is large. I'd rather setup a device and a simple protocol > to read/write to/from it. > > http://www.freebsd.org/doc/en/books/arch-handbook/driverbasics-char.html > > (you want the 5+ version) > That seems even better. Thank you very much! -Lukas.___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Moving from FreeBSD7 to FreeBSD8 (cdev, minor, dev2unit)
Hello Hackers,
I'm working on porting some kernel modules written for FreeBSD7 to FreeBSD8.
Some of these modules contain the following code:
struct cdev *dev;
...
int dev_num = minor(dev);
This code doesn't compile on FreeBSD8.
I found that in FreeBSD7 minor() was defined as follows:
515 int
516 minor(struct cdev *x)
517 {
518 if (x == NULL)
519 return NODEV;
520 return(x->si_drv0 & MAXMINOR);
521 }
where MAXMINOR was defined as
236 #define MAXMINOR0x00ffU
But in FreeBSD8 minor() is defined as macro that takes integer as a parameter:
323 #define minor(x)((int)((x)&0x00ff)) /* minor number */
I also found that FreeBSD8 provides dev2unit macro:
276 #define dev2unit(d) ((d)->si_drv0)
It looks like dev2unit is exactly what I need to fix compilation issue.
I changed the code of all modules as follows:
- int dev_num = minor(dev);
+ int dev_num = minor(dev2unit(dev));
and now it compiles and works well.
Is this the proper way of solving the problem?
Thanks in advance!
--
Sincerely yours, Dmitry V. Krivenok
e-mail: krivenok.dmi...@gmail.com
skype: krivenok_dmitry
jabber: krivenok_dmi...@jabber.ru
icq: 242-526-443
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: nginx + passenger = segv in _rtld_error on restart on FreeBSD 8.0?
On Tue, Dec 8, 2009 at 6:48 PM, Steven Hartland wrote: > I'm currently testing nginx + passenger on FreeBSD 8.0 and I'm seeing a > strange > segv which seems to indicate a core library error in _rtld_error. Could this > be the case or is the stack just badly corrupted? > > (gdb) bt > #0 0x0008005577dc in _rtld_error () from /libexec/ld-elf.so.1 > #1 0x000800557c3f in _rtld_error () from /libexec/ld-elf.so.1 > #2 0x000800557d5e in _rtld_error () from /libexec/ld-elf.so.1 > #3 0x00080055851b in dladdr () from /libexec/ld-elf.so.1 > #4 0x0008005585f3 in dladdr () from /libexec/ld-elf.so.1 > #5 0x00080055576d in ?? () from /libexec/ld-elf.so.1 > #6 0x0001 in ?? () > #7 0x004117f8 in > boost::detail::sp_counted_impl_p::dispose > (this=0x800768980) at sp_counted_impl.hpp:78 > Previous frame inner to this frame (corrupt stack?) > > Regards > Steve Steve, Did you figure this out? We're seeing something very similar with nginx + passenger + FreeBSD 8.0. Matt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Moving from FreeBSD7 to FreeBSD8 (cdev, minor, dev2unit)
On Fri, 7 May 2010, Dmitry Krivenok wrote: It looks like dev2unit is exactly what I need to fix compilation issue. I changed the code of all modules as follows: - int dev_num = minor(dev); + int dev_num = minor(dev2unit(dev)); and now it compiles and works well. Is this the proper way of solving the problem? It should be -- see the commit message for svn revision 187830 on 2009-01-28 17:57:16Z by ed -Ben Kaduk ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
hifn(4) DMA fix for review
Proposed patch addresses hifn(4) problems on FreeBSD/mips. Current implementation keeps some of the state information (indexes in buffers, etc) in DMA-mapped memory and bus_dma code invalidates them during sync operations. This fix moves data that doesn't belong to DMA ring to softc structure. Patch: http://people.freebsd.org/~gonzo/hifn.diff Stats for original driver: http://people.freebsd.org/~gonzo/hifn.stats.orig.txt Stats for patched version: http://people.freebsd.org/~gonzo/hifn.stats.patched.txt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: nginx + passenger = segv in _rtld_error on restart on FreeBSD8.0?
On Wed, Dec 9, 2009 at 4:20 AM, Steven Hartland wrote:
>
> - Original Message - From: "Kostik Belousov"
> To: "Steven Hartland"
> Cc: ;
> Sent: Wednesday, December 09, 2009 10:21 AM
> Subject: Re: nginx + passenger = segv in _rtld_error on restart on
> FreeBSD8.0?
>
> This is the trace once world had been recompiled with:-
> CFLAGS=-pipe
> WITH_CTF=1
> DEBUG_FLAGS=-g
>
>
> #0 0x000800c95eec in thr_kill () at thr_kill.S:3
> #1 0x000800b22e9e in _thr_send_sig (thread=0x800f06600, sig=6) at
> /usr/src/lib/libthr/thread/thr_kern.c:92
> #2 0x000800b1f878 in _raise (sig=6) at
> /usr/src/lib/libthr/thread/thr_sig.c:187
> #3 0x000800d74003 in abort () at /usr/src/lib/libc/stdlib/abort.c:65
> #4 0x0043b8a7 in Client::threadMain (this=0x800f9cf40) at
> ext/nginx/HelperServer.cpp:516
> #5 0x00411302 in boost::_mfi::mf0::operator()
> (this=0x7fa45ea8, p=0x800f9cf40) at mem_fn_template.hpp:49
> #6 0x00411651 in boost::_bi::list1
>>::operator(), boost::_bi::list0>
> (this=0x7fa45eb8, f...@0x7fa45ea8, a...@0x7fa45d7f) at
> bind.hpp:232
> #7 0x00411696 in boost::_bi::bind_t Client>, boost::_bi::list1 > >::operator()
> (this=0x7fa45ea8) at bind_template.hpp:20
> #8 0x004116bd in
> boost::detail::function::void_function_obj_invoker0 boost::_mfi::mf0, boost::_bi::list1
>> >, void>::invoke (
> function_obj_p...@0x7fa45ea8) at function_template.hpp:158
> #9 0x0042e73a in boost::function0
>>::operator() (this=0x7fa45ea0) at function_template.hpp:825
> #10 0x00435760 in oxt::thread::thread_main (fu...@0x7fa45ea0,
> da...@0x7fa45e90) at thread.hpp:107
> #11 0x0041310e in
> boost::_bi::list2 std::allocator > >,
> boost::_bi::value >
>>::operator() >,
> boost::shared_ptr), boost::_bi::list0>
> (this=0x800f3ee80, f...@0x800f3ee78, a...@0x7fa45f0f) at bind.hpp:289
> #12 0x00413196 in boost::_bi::bind_t (*)(boost::function >,
> boost::shared_ptr),
> boost::_bi::list2 std::allocator > >,
> boost::_bi::value > >
>>::operator() (this=0x800f3ee78) at bind_template.hpp:20
> #13 0x004131b9 in
> boost::thread::thread_data (*)(boost::function >,
> boost::shared_ptr),
> boost::_bi::list2 std::allocator > >,
> boost::_bi::value > > > >::run
> (this=0x800f3ee00) at thread.hpp:130
> #14 0x00443259 in thread_proxy (param=0x800f3ee00) at
> ext/boost/src/pthread/thread.cpp:127
> #15 0x000800b1badd in thread_start (curthread=0x800f06600) at
> /usr/src/lib/libthr/thread/thr_create.c:288
> #16 0x in ?? ()
> Cannot access memory at address 0x7fa46000
> Current language: auto; currently asm
>
> It seems that in the passenger client threads it calls closeStream which
> errors when
> the socket close errors with ENOTCONN
> virtual void closeStream() {
> TRACE_POINT();
> if (fd != -1) {
> int ret = syscalls::close(fd);
> fd = -1;
> if (ret == -1) {
> if (errno == EIO) {
> throw SystemException("A write operation on the
> session stream failed",
> errno);
> } else {
> throw SystemException("Cannot close the session
> stream",
> errno);
> }
> }
> }
> }
>
> This causes it to call abort on the the thread which then crashes the app
> with
> the above stack trace, which seems really weird. Anyone got any ideas?
>
> Regards
> steve
Steve,
The patch for PR 144061 works for us.
http://lists.freebsd.org/pipermail/freebsd-hackers/2010-February/030741.html
http://www.freebsd.org/cgi/query-pr.cgi?pr=144061
Matt
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
