libjail issues.
Hi, all. I have found something very strange to me... It is a problem with static allocating size of buffer where jail param is going to be coppied, using jail_getv function from the libjails. Well for example: buff[size]; jail_getv(0, "name", "1", "host.hostname", buff, NULL); the result for size = 64; is bsnmp.test, size = 257; is bsnmp.test, size = 256; is bs1 ? #sysctl -a | grep "security.jail.param.host.hostname:" 256 #jls JID Hostname 1 bsnmp.test #jls -n | grep "bs1" returns no match. This is really confusing me. Also i will take suggestions, what is the best way, to get and set all value/params using the jailparam struct. I am trying first to set the name or jid, and after that getting the values for the rest parameters with jail_getv, but i face some problems setting jp_value since it is type (void *). ___ 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"
how to do page level mem alloc in freebsd kernel?
Hi, I want to allocate one (or more) pages in kernel space. I'm not sure what is the api in freebsd (something which is similar to __get_free_pages() of linux). Would malloc(4096, ...) guarantee that the returned address is aligned on page boundary? Thanks and regards, -Kalash ___ 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"
how to do page level mem alloc in freebsd kernel?
Hi, I want to allocate one (or more) pages in kernel space. I'm not sure what is the api in freebsd (something which is similar to __get_free_pages() of linux). Would malloc(4096, ...) guarantee that the returned address is aligned on page boundary? Thanks and regards, -Kalash ___ 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"
avoid producing empty set_pcpu section [Was: elf obj load: skip zero-sized sections early]
on 11/07/2010 15:23 Andriy Gapon said the following:
> on 11/07/2010 14:54 Andriy Gapon said the following:
>> For completeness, here is a patch that simply drops the inline assembly and
>> the
>> comment about it, and GCC-generated assembly and its diff:
>> http://people.freebsd.org/~avg/dpcpu/pcpu.new.patch
>> http://people.freebsd.org/~avg/dpcpu/dpcpu.new.s
>> http://people.freebsd.org/~avg/dpcpu/dpcpu.new.diff
>>
>> As was speculated above, the only thing really changed is section alignment
>> (from 128 to 4).
>
> After making the above analysis I wondered why we require set_pcpu section
> alignment at all. After all, it's not used as loaded, data from the section
> gets copied into special per-cpu memory areas. So, logically, it's those
> areas
> that need to be aligned, not the section.
>
> svn log and google quickly pointed me to this excellent analysis and
> explanation
> by bz (thanks again!):
> http://people.freebsd.org/~bz/20090809-02-pcpu-start-align-fix.diff
>
> Summary: this alignment is needed to work around a bug in GNU binutils ld for
> __start_SECNAME placement.
>
> As explained by bz, ld internally generates an equivalent of the following
> linker script:
> ...
> __start_pcpu_set = ALIGN(NN);
> pcpu_set : {
> ...
> }
> __stop_pcpu_set = .;
>
> Where NN is an alignment of the first _input_ pcpu_set section found in
> whichever .o file happens to be first. Not the resulting alignment of
> pcpu_set
> _output_ section.
> Alignment requirement of input sections is based on largest alignment
> requirement of section's members. So if section is empty then the required
> alignment is 1. Alignment of output section, if not explicitly overridden
> e.g.
> via linker script, is the largest alignment of the corresponding input
> sections.
>
> I think that the problem can be fixed by making ld define __start_SECNAME like
> follows:
> ...
> pcpu_set : {
> __start_pcpu_set = ABSOLUTE(.);
> ...
> }
> __stop_pcpu_set = .;
>
> This way __start_SECNAME would always point to the actual start of the output
> section.
>
> Here's a patch that implements the idea:
> http://people.freebsd.org/~avg/dpcpu/ld.start_sec-alignment.patch
>
> This is similar to what was done upstream:
> http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/ldlang.c.diff?r1=1.306&r2=1.307&cvsroot=src&f=h
> The code is quite different there, and approach is somewhat different, but the
> idea is the same - place __start_SECNAME inside the section, not outside it.
Does anybody see any obvious or non-obvious flaw in the above analysis and the
proposed patches?
Does anyone object against me committing the ld patch and some time later the
pcpu.h patch?
My plan is to commit the ld patch tomorrow and the pcpu.h patch early next week.
P.S.
Pro-active testing is welcome! Especially if you have an "unusual" architecture
or use epair or both.
--
Andriy Gapon
___
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: avoid producing empty set_pcpu section [Was: elf obj load: skip zero-sized sections early]
On Thu, Jul 15, 2010 at 02:25:26PM +0300, Andriy Gapon wrote:
> on 11/07/2010 15:23 Andriy Gapon said the following:
> > on 11/07/2010 14:54 Andriy Gapon said the following:
> >> For completeness, here is a patch that simply drops the inline assembly
> >> and the
> >> comment about it, and GCC-generated assembly and its diff:
> >> http://people.freebsd.org/~avg/dpcpu/pcpu.new.patch
> >> http://people.freebsd.org/~avg/dpcpu/dpcpu.new.s
> >> http://people.freebsd.org/~avg/dpcpu/dpcpu.new.diff
> >>
> >> As was speculated above, the only thing really changed is section alignment
> >> (from 128 to 4).
> >
> > After making the above analysis I wondered why we require set_pcpu section
> > alignment at all. After all, it's not used as loaded, data from the section
> > gets copied into special per-cpu memory areas. So, logically, it's those
> > areas
> > that need to be aligned, not the section.
> >
> > svn log and google quickly pointed me to this excellent analysis and
> > explanation
> > by bz (thanks again!):
> > http://people.freebsd.org/~bz/20090809-02-pcpu-start-align-fix.diff
> >
> > Summary: this alignment is needed to work around a bug in GNU binutils ld
> > for
> > __start_SECNAME placement.
> >
> > As explained by bz, ld internally generates an equivalent of the following
> > linker script:
> > ...
> > __start_pcpu_set = ALIGN(NN);
> > pcpu_set : {
> > ...
> > }
> > __stop_pcpu_set = .;
> >
> > Where NN is an alignment of the first _input_ pcpu_set section found in
> > whichever .o file happens to be first. Not the resulting alignment of
> > pcpu_set
> > _output_ section.
> > Alignment requirement of input sections is based on largest alignment
> > requirement of section's members. So if section is empty then the required
> > alignment is 1. Alignment of output section, if not explicitly overridden
> > e.g.
> > via linker script, is the largest alignment of the corresponding input
> > sections.
> >
> > I think that the problem can be fixed by making ld define __start_SECNAME
> > like
> > follows:
> > ...
> > pcpu_set : {
> > __start_pcpu_set = ABSOLUTE(.);
> > ...
> > }
> > __stop_pcpu_set = .;
> >
> > This way __start_SECNAME would always point to the actual start of the
> > output
> > section.
> >
> > Here's a patch that implements the idea:
> > http://people.freebsd.org/~avg/dpcpu/ld.start_sec-alignment.patch
> >
> > This is similar to what was done upstream:
> > http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/ldlang.c.diff?r1=1.306&r2=1.307&cvsroot=src&f=h
> > The code is quite different there, and approach is somewhat different, but
> > the
> > idea is the same - place __start_SECNAME inside the section, not outside it.
>
> Does anybody see any obvious or non-obvious flaw in the above analysis and the
> proposed patches?
> Does anyone object against me committing the ld patch and some time later the
> pcpu.h patch?
>
> My plan is to commit the ld patch tomorrow and the pcpu.h patch early next
> week.
>
> P.S.
> Pro-active testing is welcome! Especially if you have an "unusual"
> architecture
> or use epair or both.
>
Is new behaviour completely identical to the behaviour of the newer
ld ? Even if yes, I think that such changes make potential import of
newer binutils harder.
pgp92RgCaFSWb.pgp
Description: PGP signature
re: how to do page level mem alloc in freebsd kernel?
Hello, what about using contigmalloc(9), there you can specify alignment and boundary. HTH, Marc >Hi, > >I want to allocate one (or more) pages in kernel space. >I'm not sure what is the api in freebsd (something which >is similar to __get_free_pages() of linux). > >Would malloc(4096, ...) guarantee that the returned >address is aligned on page boundary? > >Thanks and regards, >-Kalash -- GMX DSL: Internet-, Telefon- und Handy-Flat ab 19,99 EUR/mtl. Bis zu 150 EUR Startguthaben inklusive! http://portal.gmx.net/de/go/dsl ___ 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: avoid producing empty set_pcpu section [Was: elf obj load: skip zero-sized sections early]
on 15/07/2010 14:39 Kostik Belousov said the following: > > Is new behaviour completely identical to the behaviour of the newer > ld ? No, it's not completely identical. __start_SECNAME placement would be identical, but our ld would still assign the symbol while latest upstream binutils PROVIDES it. > Even if yes, I think that such changes make potential import of > newer binutils harder. How? -- Andriy Gapon ___ 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: 8.1RC2 amd64 machine check question
On Wednesday, July 14, 2010 11:25:29 am Andrew Heybey wrote: > Got the following in /var/log/messages on my one-week-old amd64 box running > 8.1RC2: > > Jul 13 20:30:17 spaten kernel: MCA: Global Cap 0x0106, Status > 0x > Jul 13 20:30:17 spaten kernel: MCA: Vendor "AuthenticAMD", ID 0x100f43, APIC > ID 0 > Jul 13 20:30:17 spaten kernel: MCA: CPU 0 COR GCACHE LG EVICT error > Jul 13 20:30:17 spaten kernel: MCA: Address 0x2a49464c I tend to use mcelog to get more detailed results. Unfortunately this is missing the first line which contains the bank number and status register, so I can't provide any extra details. I really should make a port of mcelog, but the patches I have to it aren't a complete port. > My questions are: > > 1. Did I interpret the message correctly (correctable error on my L3 cache)? Probably, though mcelog output would be better. > 2. Is it anything to worry about? Or is this just one of those things that > happens but now it gets logged whereas before I was blissfully ignorant? Given that it is correctable it probably isn't an issue. It was not reported in earlier releases, so there is a chance that this could have been happening previously. -- John Baldwin ___ 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 do page level mem alloc in freebsd kernel?
On Thursday, July 15, 2010 6:28:53 am kalash nainwal wrote: > Hi, > > I want to allocate one (or more) pages in kernel space. > I'm not sure what is the api in freebsd (something which > is similar to __get_free_pages() of linux). > > Would malloc(4096, ...) guarantee that the returned > address is aligned on page boundary? Well, malloc(PAGE_SIZE) will align it on a page boundary. :) malloc(4096) will be aligned on a 4096-byte boundary if PAGE_SIZE is >= 4096. My understanding is that objects returned from malloc() are aligned to the smallest power-of-2 value >= the requested size up to a page. Allocations larger than a page are page aligned. So a malloc of 24 bytes or 32 bytes is 32-byte aligned for example. -- John Baldwin ___ 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: 8.1RC2 amd64 machine check question
On Jul 15, 2010, at 8:07 AM, John Baldwin wrote: > On Wednesday, July 14, 2010 11:25:29 am Andrew Heybey wrote: >> Got the following in /var/log/messages on my one-week-old amd64 box running >> 8.1RC2: >> >> Jul 13 20:30:17 spaten kernel: MCA: Global Cap 0x0106, Status >> 0x >> Jul 13 20:30:17 spaten kernel: MCA: Vendor "AuthenticAMD", ID 0x100f43, APIC >> ID 0 >> Jul 13 20:30:17 spaten kernel: MCA: CPU 0 COR GCACHE LG EVICT error >> Jul 13 20:30:17 spaten kernel: MCA: Address 0x2a49464c > > I tend to use mcelog to get more detailed results. Unfortunately this is > missing the first line which contains the bank number and status register, so > I can't provide any extra details. Doh. Sorry, thought that I had cut-and-paste everything. Jul 13 20:30:17 spaten kernel: MCA: Bank 4, Status 0x942c4880001c017b andrew ___ 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: disk I/O, VFS hirunningspace
On 07/14/10 18:27, Jerry Toung wrote: > On Wed, Jul 14, 2010 at 12:04 AM, Gary Jennejohn > wrote: > >> >> >> Rather than commenting out the code try setting the sysctl >> vfs.hirunningspace to various powers-of-two. Default seems to be >> 1MB. I just changed it on the command line as a test to 2MB. >> >> You can do this in /etc/sysctl.conf. >> >> > thank you all, that did it. The settings that Matt recommended are giving > the same numbers Any objections to raising the defaults to 8 MB / 1 MB in HEAD? ___ 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: 8.1RC2 amd64 machine check question
On Thursday, July 15, 2010 8:42:09 am Andrew Heybey wrote: > On Jul 15, 2010, at 8:07 AM, John Baldwin wrote: > > > On Wednesday, July 14, 2010 11:25:29 am Andrew Heybey wrote: > >> Got the following in /var/log/messages on my one-week-old amd64 box > >> running 8.1RC2: > >> > >> Jul 13 20:30:17 spaten kernel: MCA: Global Cap 0x0106, Status > >> 0x > >> Jul 13 20:30:17 spaten kernel: MCA: Vendor "AuthenticAMD", ID 0x100f43, > >> APIC ID 0 > >> Jul 13 20:30:17 spaten kernel: MCA: CPU 0 COR GCACHE LG EVICT error > >> Jul 13 20:30:17 spaten kernel: MCA: Address 0x2a49464c > > > > I tend to use mcelog to get more detailed results. Unfortunately this is > > missing the first line which contains the bank number and status register, > > so > > I can't provide any extra details. > > Doh. Sorry, thought that I had cut-and-paste everything. > > Jul 13 20:30:17 spaten kernel: MCA: Bank 4, Status 0x942c4880001c017b This is what mcelog claims: HARDWARE ERROR. This is *NOT* a software problem! Please contact your hardware vendor CPU 0 4 northbridge ADDR 2a49464c Northbridge NB Array Error bit43 = L3 subcache in error bit 1 bit46 = corrected ecc error memory/cache error 'evict mem transaction, generic transaction, level generic' STATUS 942c4880001c017b MCGSTATUS 0 MCGCAP 106 APICID 0 SOCKETID 0 CPUID Vendor AMD Family 16 Model 4 > andrew > > ___ > 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" > -- John Baldwin ___ 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"
Kernel linker and undefined references in KLD
Hello Hackers,
I have a question about kernel linker.
Please take a look at an example of simple module:
#include
#include
#include
#include
#include
#include
#include
/* DECLARING A FUNCTION JUST TO AVOID WARNING WHICH IS TREAT AS ERROR
BY DEFAULT */
void seltdinit(struct thread* t);
static int event_handler(struct module *module, int event, void *arg)
{
int e = 0;
switch (event)
{
case MOD_LOAD:
/* CALLING A FUNCTION DECLARED AS STATIC IN kern/sys_generic.c */
seltdinit(curthread);
break;
case MOD_QUIESCE:
break;
case MOD_UNLOAD:
break;
case MOD_SHUTDOWN:
break;
default:
e = EOPNOTSUPP;
break;
}
return(e);
};
As you can see, this module calls seltdinit function declared as
_static_ in kern/sys_generic.c file.
I added a declaration of seltdinit function w/o static just to avoid
compilation error since -Werror is used
by default in FreeBSD.
Then I successfully built the module:
$ make
Warning: Object directory not changed from original
/usr/home/krived/work/freebsd/trouble
cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE
-nostdinc -I. -I@ -I@/contrib/altq -finline-limit=8000 --param
inline-unit-growth=100 --param large-function-growth=1000 -fno-common
-fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387
-mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float
-fno-asynchronous-unwind-tables -ffreestanding -fstack-protector
-std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls
-Wnested-externs -Wstrict-prototypes -Wmissing-prototypes
-Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign
-fformat-extensions -c trouble.c
ld -d -warn-common -r -d -o trouble.ko trouble.o
:> export_syms
awk -f /sys/conf/kmod_syms.awk trouble.ko export_syms | xargs -J%
objcopy % trouble.ko
objcopy --strip-debug trouble.ko
$
As expected, seltdinit symbol is undefined in trouble.ko file:
$ nm trouble.ko | grep seltdinit
U seltdinit
$
and is local in kernel binary file:
$ nm /boot/kernel/kernel | grep seltdinit
805fda50 t seltdinit
$
I expected to get something like "undefined reference to seltdinit"
error, but the module was loaded w/o any errors:
$ sudo make load
/sbin/kldload -v /usr/home/krived/work/freebsd/trouble/trouble.ko
Loaded /usr/home/krived/work/freebsd/trouble/trouble.ko, id=2
$ kldstat | grep trouble
21 0x81212000 126 trouble.ko
$ sudo make unload
/sbin/kldunload -v trouble.ko
Unloading trouble.ko, id=2
$
Could you please explain why the linker (or whatever is loading
modules in FreeBSD) doesn't complain?
For example, ld tool complains for the similar user-space example:
$ cat seltdinit.c
static void seltdinit(void* td)
{
return;
}
$ cat main.c
void seltdinit(void* td);
int main()
{
seltdinit(0);
return 0;
}
$ gcc -Wall -c seltdinit.c
seltdinit.c:2: warning: 'seltdinit' defined but not used
$ gcc -Wall -c main.c
$ gcc seltdinit.o main.o -o sel
main.o: In function `main':
main.c:(.text+0xa): undefined reference to `seltdinit'
collect2: ld returned 1 exit status
$
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: Kernel linker and undefined references in KLD
On Thu, Jul 15, 2010 at 06:07:36PM +0400, Dmitry Krivenok wrote:
> Hello Hackers,
>
> I have a question about kernel linker.
> Please take a look at an example of simple module:
>
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> /* DECLARING A FUNCTION JUST TO AVOID WARNING WHICH IS TREAT AS ERROR
> BY DEFAULT */
> void seltdinit(struct thread* t);
>
> static int event_handler(struct module *module, int event, void *arg)
> {
> int e = 0;
> switch (event)
> {
> case MOD_LOAD:
> /* CALLING A FUNCTION DECLARED AS STATIC IN kern/sys_generic.c */
> seltdinit(curthread);
> break;
> case MOD_QUIESCE:
> break;
> case MOD_UNLOAD:
> break;
> case MOD_SHUTDOWN:
> break;
> default:
> e = EOPNOTSUPP;
> break;
> }
>
> return(e);
> };
>
>
> As you can see, this module calls seltdinit function declared as
> _static_ in kern/sys_generic.c file.
> I added a declaration of seltdinit function w/o static just to avoid
> compilation error since -Werror is used
> by default in FreeBSD.
>
> Then I successfully built the module:
>
> $ make
> Warning: Object directory not changed from original
> /usr/home/krived/work/freebsd/trouble
> cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE
> -nostdinc -I. -I@ -I@/contrib/altq -finline-limit=8000 --param
> inline-unit-growth=100 --param large-function-growth=1000 -fno-common
> -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387
> -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float
> -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector
> -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls
> -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes
> -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign
> -fformat-extensions -c trouble.c
> ld -d -warn-common -r -d -o trouble.ko trouble.o
> :> export_syms
> awk -f /sys/conf/kmod_syms.awk trouble.ko export_syms | xargs -J%
> objcopy % trouble.ko
> objcopy --strip-debug trouble.ko
> $
>
> As expected, seltdinit symbol is undefined in trouble.ko file:
> $ nm trouble.ko | grep seltdinit
> U seltdinit
> $
> and is local in kernel binary file:
> $ nm /boot/kernel/kernel | grep seltdinit
> 805fda50 t seltdinit
> $
>
> I expected to get something like "undefined reference to seltdinit"
> error, but the module was loaded w/o any errors:
>
> $ sudo make load
> /sbin/kldload -v /usr/home/krived/work/freebsd/trouble/trouble.ko
> Loaded /usr/home/krived/work/freebsd/trouble/trouble.ko, id=2
> $ kldstat | grep trouble
> 21 0x81212000 126 trouble.ko
> $ sudo make unload
> /sbin/kldunload -v trouble.ko
> Unloading trouble.ko, id=2
> $
>
> Could you please explain why the linker (or whatever is loading
> modules in FreeBSD) doesn't complain?
>
> For example, ld tool complains for the similar user-space example:
>
>
> $ cat seltdinit.c
> static void seltdinit(void* td)
> {
> return;
> }
> $ cat main.c
> void seltdinit(void* td);
>
> int main()
> {
> seltdinit(0);
> return 0;
> }
> $ gcc -Wall -c seltdinit.c
> seltdinit.c:2: warning: 'seltdinit' defined but not used
> $ gcc -Wall -c main.c
> $ gcc seltdinit.o main.o -o sel
> main.o: In function `main':
> main.c:(.text+0xa): undefined reference to `seltdinit'
> collect2: ld returned 1 exit status
> $
>
>
> Thanks in advance!
The kernel linker ignores weak attribute of the symbol, as you see.
There is more bugs in this department, in regard of the list of
exported symbols from the modules.
I have a patch that fixes the issues, but I am leery to commit it, since
the fix effectively breaks significant set of the modules.
pgpWX4UsqM2fE.pgp
Description: PGP signature
Re: how to do page level mem alloc in freebsd kernel?
On Thu, Jul 15, 2010 at 4:46 PM, "Marc Lörner" wrote: > Hello, > what about using contigmalloc(9), there you can specify > alignment and boundary. > > HTH, > Marc > Thanks Marc. I had thought of using contigmalloc, but was not sure what would be the other args (boundary, low, high etc.) in my case. So was looking for a simpler interface. Regards, -Kalash ___ 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 do page level mem alloc in freebsd kernel?
On Thu, Jul 15, 2010 at 5:41 PM, John Baldwin wrote: > On Thursday, July 15, 2010 6:28:53 am kalash nainwal wrote: >> Hi, >> >> I want to allocate one (or more) pages in kernel space. >> I'm not sure what is the api in freebsd (something which >> is similar to __get_free_pages() of linux). >> >> Would malloc(4096, ...) guarantee that the returned >> address is aligned on page boundary? > > Well, malloc(PAGE_SIZE) will align it on a page boundary. :) malloc(4096) > will be aligned on a 4096-byte boundary if PAGE_SIZE is >= 4096. My > understanding is that objects returned from malloc() are aligned to the > smallest power-of-2 value >= the requested size up to a page. Allocations > larger than a page are page aligned. So a malloc of 24 bytes or 32 bytes is > 32-byte aligned for example. > Thanks John for explaining. After going through the kernel src I was not sure about malloc, as the code is little hard to follow. However I figured kmem_alloc(kernel_pmap, PAGE_SIZE) would serve my purpose fine. Regards, -Kalash ___ 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 do page level mem alloc in freebsd kernel?
On Thu, Jul 15, 2010 at 08:24:53PM +0530, kalash nainwal wrote: > On Thu, Jul 15, 2010 at 5:41 PM, John Baldwin wrote: > > On Thursday, July 15, 2010 6:28:53 am kalash nainwal wrote: > >> Hi, > >> > >> I want to allocate one (or more) pages in kernel space. > >> I'm not sure what is the api in freebsd (something which > >> is similar to __get_free_pages() of linux). > >> > >> Would malloc(4096, ...) guarantee that the returned > >> address is aligned on page boundary? > > > > Well, malloc(PAGE_SIZE) will align it on a page boundary. :) malloc(4096) > > will be aligned on a 4096-byte boundary if PAGE_SIZE is >= 4096. My > > understanding is that objects returned from malloc() are aligned to the > > smallest power-of-2 value >= the requested size up to a page. Allocations > > larger than a page are page aligned. So a malloc of 24 bytes or 32 bytes is > > 32-byte aligned for example. > > > > Thanks John for explaining. > > After going through the kernel src I was not sure about > malloc, as the code is little hard to follow. However I figured > kmem_alloc(kernel_pmap, PAGE_SIZE) would serve my ^^kernel_map. > purpose fine. > > Regards, > -Kalash > ___ > 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" pgp6vaSyuYG0N.pgp Description: PGP signature
Re: Kernel linker and undefined references in KLD
On Thu, Jul 15, 2010 at 05:32:35PM +0300, Kostik Belousov wrote:
> On Thu, Jul 15, 2010 at 06:07:36PM +0400, Dmitry Krivenok wrote:
> > Hello Hackers,
> >
> > I have a question about kernel linker.
> > Please take a look at an example of simple module:
> >
> >
> > #include
> > #include
> > #include
> > #include
> > #include
> > #include
> > #include
> >
> > /* DECLARING A FUNCTION JUST TO AVOID WARNING WHICH IS TREAT AS ERROR
> > BY DEFAULT */
> > void seltdinit(struct thread* t);
> >
> > static int event_handler(struct module *module, int event, void *arg)
> > {
> > int e = 0;
> > switch (event)
> > {
> > case MOD_LOAD:
> > /* CALLING A FUNCTION DECLARED AS STATIC IN kern/sys_generic.c */
> > seltdinit(curthread);
> > break;
> > case MOD_QUIESCE:
> > break;
> > case MOD_UNLOAD:
> > break;
> > case MOD_SHUTDOWN:
> > break;
> > default:
> > e = EOPNOTSUPP;
> > break;
> > }
> >
> > return(e);
> > };
> >
> >
> > As you can see, this module calls seltdinit function declared as
> > _static_ in kern/sys_generic.c file.
> > I added a declaration of seltdinit function w/o static just to avoid
> > compilation error since -Werror is used
> > by default in FreeBSD.
> >
> > Then I successfully built the module:
> >
> > $ make
> > Warning: Object directory not changed from original
> > /usr/home/krived/work/freebsd/trouble
> > cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE
> > -nostdinc -I. -I@ -I@/contrib/altq -finline-limit=8000 --param
> > inline-unit-growth=100 --param large-function-growth=1000 -fno-common
> > -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387
> > -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float
> > -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector
> > -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls
> > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes
> > -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign
> > -fformat-extensions -c trouble.c
> > ld -d -warn-common -r -d -o trouble.ko trouble.o
> > :> export_syms
> > awk -f /sys/conf/kmod_syms.awk trouble.ko export_syms | xargs -J%
> > objcopy % trouble.ko
> > objcopy --strip-debug trouble.ko
> > $
> >
> > As expected, seltdinit symbol is undefined in trouble.ko file:
> > $ nm trouble.ko | grep seltdinit
> > U seltdinit
> > $
> > and is local in kernel binary file:
> > $ nm /boot/kernel/kernel | grep seltdinit
> > 805fda50 t seltdinit
> > $
> >
> > I expected to get something like "undefined reference to seltdinit"
> > error, but the module was loaded w/o any errors:
> >
> > $ sudo make load
> > /sbin/kldload -v /usr/home/krived/work/freebsd/trouble/trouble.ko
> > Loaded /usr/home/krived/work/freebsd/trouble/trouble.ko, id=2
> > $ kldstat | grep trouble
> > 21 0x81212000 126 trouble.ko
> > $ sudo make unload
> > /sbin/kldunload -v trouble.ko
> > Unloading trouble.ko, id=2
> > $
> >
> > Could you please explain why the linker (or whatever is loading
> > modules in FreeBSD) doesn't complain?
> >
> > For example, ld tool complains for the similar user-space example:
> >
> >
> > $ cat seltdinit.c
> > static void seltdinit(void* td)
> > {
> > return;
> > }
> > $ cat main.c
> > void seltdinit(void* td);
> >
> > int main()
> > {
> > seltdinit(0);
> > return 0;
> > }
> > $ gcc -Wall -c seltdinit.c
> > seltdinit.c:2: warning: 'seltdinit' defined but not used
> > $ gcc -Wall -c main.c
> > $ gcc seltdinit.o main.o -o sel
> > main.o: In function `main':
> > main.c:(.text+0xa): undefined reference to `seltdinit'
> > collect2: ld returned 1 exit status
> > $
> >
> >
> > Thanks in advance!
> The kernel linker ignores weak attribute of the symbol, as you see.
> There is more bugs in this department, in regard of the list of
> exported symbols from the modules.
>
> I have a patch that fixes the issues, but I am leery to commit it, since
> the fix effectively breaks significant set of the modules.
Ok, below is the patch. I updated it to the latest HEAD, but did not
verified even the build.
diff --git a/sys/conf/kmod_syms.awk b/sys/conf/kmod_syms.awk
index 677d813..98940c6 100644
--- a/sys/conf/kmod_syms.awk
+++ b/sys/conf/kmod_syms.awk
@@ -12,7 +12,10 @@ BEGIN {
# De-list symbols from the export list.
{
-delete syms[$0]
+ split($0, exports)
+ for (member in exports) {
+ delete syms[$member]
+ }
}
# Strip commons, make everything else local.
diff --git a/sys/kern/kern_linker.c b/sys/kern/kern_linker.c
index dd29302..f3da962 100644
--- a
Re: how to do page level mem alloc in freebsd kernel?
2010/7/15 Kostik Belousov : > On Thu, Jul 15, 2010 at 08:24:53PM +0530, kalash nainwal wrote: >> On Thu, Jul 15, 2010 at 5:41 PM, John Baldwin wrote: >> > On Thursday, July 15, 2010 6:28:53 am kalash nainwal wrote: >> >> Hi, >> >> >> >> I want to allocate one (or more) pages in kernel space. >> >> I'm not sure what is the api in freebsd (something which >> >> is similar to __get_free_pages() of linux). >> >> >> >> Would malloc(4096, ...) guarantee that the returned >> >> address is aligned on page boundary? >> > >> > Well, malloc(PAGE_SIZE) will align it on a page boundary. :) malloc(4096) >> > will be aligned on a 4096-byte boundary if PAGE_SIZE is >= 4096. My >> > understanding is that objects returned from malloc() are aligned to the >> > smallest power-of-2 value >= the requested size up to a page. Allocations >> > larger than a page are page aligned. So a malloc of 24 bytes or 32 bytes >> > is >> > 32-byte aligned for example. >> > >> >> Thanks John for explaining. >> >> After going through the kernel src I was not sure about >> malloc, as the code is little hard to follow. However I figured >> kmem_alloc(kernel_pmap, PAGE_SIZE) would serve my > ^^kernel_map. oops. my bad. thanks for correcting. ___ 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: Kernel linker and undefined references in KLD
Unfortunately, one can easily miss such problems during build of the module.
I'm working on a system which consists of lots of user-space programs
and kernel modules and
uses it's own complicated build system.
gcc option -Werror is not used by the build system (I believe it
should), that's why we just missed
a compiler warning when called undeclared function (actually declared
as static deep in kernel source).
Then we got kernel panic and started investigating it.
I disassembled seltdinit function and found that it takes pointer to
thread from %eax register and global kernel
functions (e.g. kern_select) calling seltdinit copy the pointer to
%eax just before "call" instruction.
Then I disassembled my own function calling seltdinit and found that
it passes the pointer via stack and
doesn't do anything with %eax register.
I'm not OS/compilers/ASM expert, but I guess that gcc is free to
optimize passing of parameters to static functions
because it has all the information about callers of these static
functions (all stuff is inside one translation unit).
So kernel functions call static functions in a right way, but modules
compiled separately may use wrong calling
convention.
On Thu, Jul 15, 2010 at 6:32 PM, Kostik Belousov wrote:
> On Thu, Jul 15, 2010 at 06:07:36PM +0400, Dmitry Krivenok wrote:
>> Hello Hackers,
>>
>> I have a question about kernel linker.
>> Please take a look at an example of simple module:
>>
>>
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
>>
>> /* DECLARING A FUNCTION JUST TO AVOID WARNING WHICH IS TREAT AS ERROR
>> BY DEFAULT */
>> void seltdinit(struct thread* t);
>>
>> static int event_handler(struct module *module, int event, void *arg)
>> {
>> int e = 0;
>> switch (event)
>> {
>> case MOD_LOAD:
>> /* CALLING A FUNCTION DECLARED AS STATIC IN kern/sys_generic.c */
>> seltdinit(curthread);
>> break;
>> case MOD_QUIESCE:
>> break;
>> case MOD_UNLOAD:
>> break;
>> case MOD_SHUTDOWN:
>> break;
>> default:
>> e = EOPNOTSUPP;
>> break;
>> }
>>
>> return(e);
>> };
>>
>>
>> As you can see, this module calls seltdinit function declared as
>> _static_ in kern/sys_generic.c file.
>> I added a declaration of seltdinit function w/o static just to avoid
>> compilation error since -Werror is used
>> by default in FreeBSD.
>>
>> Then I successfully built the module:
>>
>> $ make
>> Warning: Object directory not changed from original
>> /usr/home/krived/work/freebsd/trouble
>> cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE
>> -nostdinc -I. -I@ -I@/contrib/altq -finline-limit=8000 --param
>> inline-unit-growth=100 --param large-function-growth=1000 -fno-common
>> -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387
>> -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float
>> -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector
>> -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls
>> -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes
>> -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign
>> -fformat-extensions -c trouble.c
>> ld -d -warn-common -r -d -o trouble.ko trouble.o
>> :> export_syms
>> awk -f /sys/conf/kmod_syms.awk trouble.ko export_syms | xargs -J%
>> objcopy % trouble.ko
>> objcopy --strip-debug trouble.ko
>> $
>>
>> As expected, seltdinit symbol is undefined in trouble.ko file:
>> $ nm trouble.ko | grep seltdinit
>> U seltdinit
>> $
>> and is local in kernel binary file:
>> $ nm /boot/kernel/kernel | grep seltdinit
>> 805fda50 t seltdinit
>> $
>>
>> I expected to get something like "undefined reference to seltdinit"
>> error, but the module was loaded w/o any errors:
>>
>> $ sudo make load
>> /sbin/kldload -v /usr/home/krived/work/freebsd/trouble/trouble.ko
>> Loaded /usr/home/krived/work/freebsd/trouble/trouble.ko, id=2
>> $ kldstat | grep trouble
>> 2 1 0x81212000 126 trouble.ko
>> $ sudo make unload
>> /sbin/kldunload -v trouble.ko
>> Unloading trouble.ko, id=2
>> $
>>
>> Could you please explain why the linker (or whatever is loading
>> modules in FreeBSD) doesn't complain?
>>
>> For example, ld tool complains for the similar user-space example:
>>
>>
>> $ cat seltdinit.c
>> static void seltdinit(void* td)
>> {
>> return;
>> }
>> $ cat main.c
>> void seltdinit(void* td);
>>
>> int main()
>> {
>> seltdinit(0);
>> return 0;
>> }
>> $ gcc -Wall -c seltdinit.c
>> seltdinit.c:2: warning: 'seltdinit' defined but not used
>> $ gcc -Wall -c main.c
>> $ gcc seltdinit.o main.o -o sel
>> main.o: In function `main':
>> main.c:(.text+0xa): undefined reference to `seltdinit'
>> collect2
Re: Kernel linker and undefined references in KLD
On Thu, Jul 15, 2010 at 10:13:54PM +0400, Dmitry Krivenok wrote: > Unfortunately, one can easily miss such problems during build of the module. > I'm working on a system which consists of lots of user-space programs > and kernel modules and > uses it's own complicated build system. > gcc option -Werror is not used by the build system (I believe it > should), that's why we just missed > a compiler warning when called undeclared function (actually declared > as static deep in kernel source). > > Then we got kernel panic and started investigating it. > I disassembled seltdinit function and found that it takes pointer to > thread from %eax register and global kernel > functions (e.g. kern_select) calling seltdinit copy the pointer to > %eax just before "call" instruction. > > Then I disassembled my own function calling seltdinit and found that > it passes the pointer via stack and > doesn't do anything with %eax register. > > I'm not OS/compilers/ASM expert, but I guess that gcc is free to > optimize passing of parameters to static functions > because it has all the information about callers of these static > functions (all stuff is inside one translation unit). > So kernel functions call static functions in a right way, but modules > compiled separately may use wrong calling > convention. Your message does not contain the question, but right answer is that you should not call static functions. pgph7MXonIOXB.pgp Description: PGP signature
Re: Kernel linker and undefined references in KLD
On 15.07.2010 18:32, Kostik Belousov wrote:
> The kernel linker ignores weak attribute of the symbol, as you see.
> There is more bugs in this department, in regard of the list of
> exported symbols from the modules.
>
> I have a patch that fixes the issues, but I am leery to commit it, since
> the fix effectively breaks significant set of the modules.
Hi, Kostik
i want to remind that some time ago there was a report about another
bug.
#include
#include
#include
#include
static int
tst_modevent(module_t mod, int type, void *unused)
{
switch (type) {
case MOD_LOAD:
return (EINVAL);
case MOD_UNLOAD:
break;
};
return (0);
}
static moduledata_t tstmod = {
"tst",
tst_modevent,
0
};
DECLARE_MODULE(tst, tstmod, SI_SUB_ROOT_CONF, SI_ORDER_ANY);
# kldload -v ./tst.ko
Loaded ./tst.ko, id=16
I think loading of this module should be rejected on MOD_LOAD,
but it doesn't.
--
WBR, Andrey V. Elsukov
signature.asc
Description: OpenPGP digital signature
Re: disk I/O, VFS hirunningspace
On Thu, Jul 15, 2010 at 8:01 AM, Ivan Voras wrote: > On 07/14/10 18:27, Jerry Toung wrote: > > On Wed, Jul 14, 2010 at 12:04 AM, Gary Jennejohn > > wrote: > > > >> > >> > >> Rather than commenting out the code try setting the sysctl > >> vfs.hirunningspace to various powers-of-two. Default seems to be > >> 1MB. I just changed it on the command line as a test to 2MB. > >> > >> You can do this in /etc/sysctl.conf. > >> > >> > > thank you all, that did it. The settings that Matt recommended are giving > > the same numbers > > Any objections to raising the defaults to 8 MB / 1 MB in HEAD? > > > Keep in mind that we still run on some fairly small systems with limited I/O capabilities, e.g., a typical arm platform. More generally, with the range of systems that FreeBSD runs on today, any particular choice of constants is going to perform poorly for someone. If nothing else, making these sysctls a function of the buffer cache size is probably better than any particular constants. Alan ___ 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: Kernel linker and undefined references in KLD
On Thu, Jul 15, 2010 at 10:36:04PM +0400, Andrey V. Elsukov wrote:
> On 15.07.2010 18:32, Kostik Belousov wrote:
> > The kernel linker ignores weak attribute of the symbol, as you see.
> > There is more bugs in this department, in regard of the list of
> > exported symbols from the modules.
> >
> > I have a patch that fixes the issues, but I am leery to commit it, since
> > the fix effectively breaks significant set of the modules.
>
> Hi, Kostik
>
> i want to remind that some time ago there was a report about another
> bug.
>
> #include
> #include
> #include
> #include
>
> static int
> tst_modevent(module_t mod, int type, void *unused)
> {
> switch (type) {
> case MOD_LOAD:
> return (EINVAL);
> case MOD_UNLOAD:
> break;
> };
> return (0);
> }
> static moduledata_t tstmod = {
> "tst",
> tst_modevent,
> 0
> };
>
> DECLARE_MODULE(tst, tstmod, SI_SUB_ROOT_CONF, SI_ORDER_ANY);
>
> # kldload -v ./tst.ko
> Loaded ./tst.ko, id=16
>
> I think loading of this module should be rejected on MOD_LOAD,
> but it doesn't.
Did you tried this ? It works for me.
There was a thread about the issue where apparently submitter used
binutils 2.20.1. The solution of reverting r103230 was
mentioned by peter.
pgpBxOqSAy3sw.pgp
Description: PGP signature
Re: libjail issues.
On 07/15/10 04:12, Stanislav Uzunchev wrote: I have found something very strange to me... It is a problem with static allocating size of buffer where jail param is going to be coppied, using jail_getv function from the libjails. Well for example: buff[size]; jail_getv(0, "name", "1", "host.hostname", buff, NULL); the result for size = 64; is bsnmp.test, size = 257; is bsnmp.test, size = 256; is bs1 ? #sysctl -a | grep "security.jail.param.host.hostname:" 256 #jls JID Hostname 1 bsnmp.test #jls -n | grep "bs1" returns no match. This is really confusing me. That's a bug in jail_getv, which I'm committing the fix for now. Unfortunately, it's too late to get it in the 8.1 release, but it will at least be in future releases. The issue is that jail_getv wrongly allocated temporary space based on the length of the parameters passed in, which don't even have values yet. The different array sizes in your sample code would coincidentally locate the "buff" array with different garbage contents, leading to different behavior with the bug. Also i will take suggestions, what is the best way, to get and set all value/params using the jailparam struct. I am trying first to set the name or jid, and after that getting the values for the rest parameters with jail_getv, but i face some problems setting jp_value since it is type (void *). You don't value to set jp_value directly, but use the jailparam_import function. That will set jp_value correctly based on the parameter's type. - Jamie ___ 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: strange problem with int64_t variables
Em 2010.07.13. 16:05, pluknet escreveu:
#ifndef _SYS_SYSPROTO_H_
struct setjlimit_args {
jid_t jid;
int resource;
struct rlimit *rlp;
};
#endif
int
setjlimit(td, uap)
struct thread *td;
struct setjlimit_args /* {
jid_t jid;
int resource;
struct rlimit *rlp;
} */ *uap;
{
printf("%s called\n", __FUNCTION__);
printf("resource: %d\n", uap->resource);
if (uap->resource>= JLIM_NLIMITS) {
td->td_retval[0] = -1;
return (EINVAL);
}
return (0);
}
Thanks for trying this out. I still couldn't find the problem. Is this
generate code? I mean the prototype of the function. I'm using C99
syntax and I manually added the implementation, the generated code what
I'm using is just what make sysent generated. Besides, the generated
code in sysproto.h is different from this struct that you have here,
there are padding members, as well:
+struct setjlimit_args {
+ char jid_l_[PADL_(__jid_t)]; __jid_t jid; char jid_r_[PADR_(__jid_t)];
+ char resource_l_[PADL_(int)]; int resource; char
resource_r_[PADR_(int)];
+ char rlp_l_[PADL_(struct rlimit *)]; struct rlimit * rlp; char
rlp_r_[PADR_(struct rlimit *)];
+};
And what do you have in syscalls.master? Is it the same as I have?
+527AUE_NULLSTD { int setjlimit(__jid_t jid, int resource, \
+ struct rlimit *rlp); }
Gabor
___
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"
Use of printf's inside a kernel thread
Just wondering if there is some constraints to using printf() calls inside a kernel thread (created by kthread_create()). I'm currently trying to debug a worker thread but the printf's are coming out garbled. Not entirely sure why this could be occurring. OS: FreeBSD 7.3 on an Intel Xeon with 8 Gbytes of memory. Any ideas? Thanks, Patrick ___ 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"
[DTRACE] ctfconvert ".bss data: Invalid section descriptor" +
Through 3 recent ``buildkernel'' runs I have logged the following. The
build logs are available to those with interest.
I have tested this with three variations to the environment i.e.
make.conf, src.conf, make -j{N}, & a vanilla build. The errors come up
the same way but with a variation of the lines in the log file where the
errors appear.
I still have the tar'd object directory for the last vanilla build that
was performed.
Though these errors are prominent in the log I don't believe it has a
negative impact other than not being traceable by dtrace. I have not
observed any other impact that this could have so I decided to report
what I have here for someone else to decide on the outcome.
Summary of errors in the logs:
ctfconvert -L VERSION -g kern_ktr.o
kern_ktr.c: kern_ktr.o: Cannot get sect .bss data: Invalid section
descriptor
ctfconvert -L VERSION -g tcp_debug.o
tcp_debug.c: tcp_debug.o: Cannot get sect .bss data: Invalid section
descriptor
ctfconvert -L VERSION -g clnt_rc.o
ctfconvert -L VERSION -g ffs_tables.o
ctfconvert -L VERSION -g ufs_gjournal.o
ctfconvert: rc = 2 No entry found [dwarf_next_cu_header(57)]
ctfconvert -L VERSION -g local_apic.o
local_apic.c: local_apic.o: Cannot get sect .bss data: Invalid section
descriptor
ctfconvert -L VERSION msp34xx.o
ctfconvert: rc = 2 No entry found [dwarf_next_cu_header(57)]
dtrace.c: dtrace.o: Cannot get sect .bss data: Invalid section descriptor
ctfconvert -L VERSION if_ed_3c503.o
ctfconvert: rc = 2 No entry found [dwarf_next_cu_header(57)]
ctfconvert -L VERSION if_ed_hpp.o
ctfconvert: rc = 2 No entry found [dwarf_next_cu_header(57)]
ctfconvert -L VERSION if_ed_sic.o
ctfconvert: rc = 2 No entry found [dwarf_next_cu_header(57)]
ctfconvert -L VERSION mfi_debug.o
ctfconvert: rc = 2 No entry found [dwarf_next_cu_header(57)]
ctfconvert -L VERSION ufs_gjournal.o
ctfconvert: rc = 2 No entry found [dwarf_next_cu_header(57)]
Regards,
--
jhell,v
___
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: [DTRACE] ctfconvert ".bss data: Invalid section descriptor" +
I should probably note that this is on stable/8 i386 r210115. And that this was before the 210145:210147 commits. Regards, -- jhell,v ___ 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: disk I/O, VFS hirunningspace
2010/7/15 Alan Cox : > On Thu, Jul 15, 2010 at 8:01 AM, Ivan Voras wrote: > >> On 07/14/10 18:27, Jerry Toung wrote: >> > On Wed, Jul 14, 2010 at 12:04 AM, Gary Jennejohn >> > wrote: >> > >> >> >> >> >> >> Rather than commenting out the code try setting the sysctl >> >> vfs.hirunningspace to various powers-of-two. Default seems to be >> >> 1MB. I just changed it on the command line as a test to 2MB. >> >> >> >> You can do this in /etc/sysctl.conf. >> >> >> >> >> > thank you all, that did it. The settings that Matt recommended are giving >> > the same numbers >> >> Any objections to raising the defaults to 8 MB / 1 MB in HEAD? >> >> >> > Keep in mind that we still run on some fairly small systems with limited I/O > capabilities, e.g., a typical arm platform. More generally, with the range > of systems that FreeBSD runs on today, any particular choice of constants is > going to perform poorly for someone. If nothing else, making these sysctls > a function of the buffer cache size is probably better than any particular > constants. What about making a MD sysctl? Attilio -- Peace can only be achieved by understanding - A. Einstein ___ 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: Use of printf's inside a kernel thread
Patrick Mahan wrote: Just wondering if there is some constraints to using printf() calls inside a kernel thread (created by kthread_create()). I'm currently trying to debug a worker thread but the printf's are coming out garbled. Not entirely sure why this could be occurring. OS: FreeBSD 7.3 on an Intel Xeon with 8 Gbytes of memory. Any ideas? Thanks, Patrick I don't think printf() output from the kernel is serialized. The PRINTF_BUFR_SIZE=128 GENERIC kernel option in 8.x alleviates this to a good extent, and there is a reference to it in /usr/src/sys/conf/options in 7.3, so it might be available there as well. Try it out. -Boris ___ 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: [DTRACE] ctfconvert ".bss data: Invalid section descriptor" +
On Thu, 15 Jul 2010 20:02:01 -0400 jhell wrote: > > I should probably note that this is on stable/8 i386 r210115. And that > this was before the 210145:210147 commits. > This is a message from ctfconvert bogusly trying to read non-existent data from .bss. I have fix for this which I forwarded to our libelf author. The bug if harmless otherwise. -- Alexander Kabaev PS. I usually avoid responding to messages from strangely named entities, but there's always a place for exception... signature.asc Description: PGP signature
Re: [DTRACE] ctfconvert ".bss data: Invalid section descriptor" +
On 07/16/2010 00:31, Alexander Kabaev wrote: > On Thu, 15 Jul 2010 20:02:01 -0400 > jhell wrote: > >> >> I should probably note that this is on stable/8 i386 r210115. And that >> this was before the 210145:210147 commits. >> > This is a message from ctfconvert bogusly trying to read non-existent > data from .bss. I have fix for this which I forwarded to our libelf > author. The bug if harmless otherwise. > Alright, thank you for confirming this. I thought this was the case but did not want to make any assumptions as to exactly what it was caused by even though the error that was popping up looked like ctfconvert's fault. Thanks again, -- jhell,v ___ 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"
