Re: FreeBSD 8.3 and 9.0 freeze with firefox

[Joseph Olatt]

On Fri, Mar 30, 2012 at 10:41:54AM +0700, Erich Dollansky wrote:
> Hi,
> 
> On Friday 30 March 2012 09:28:06 Joseph Olatt wrote:
> > 
> > Starting with 8.3, I've been experiencing FreeBSD freezing up completely
> > after using firefox for a while. Thinking the problem would go away if I
> > upgraded to 9.0, I did that and I am still experiencing the same
> > freezing up. The mouse pointer freezes, the keyboard freezes (caps lock
> > light will not come on; Ctrl-Alt-F[1-10] does not work etc.). The only
> > way to get the system back is by pressing and holding down the power
> > button. 
> > 
> > The problem seems similar to: kern/163145
> > 
> > 
> > There is nothing in /var/log/messages to indicate a problem. Output of 
> > pciconf -lv and uname -a are at:
> > 
> > http://www.eskimo.com/~joji/wisdom/
> > 
> > Anybody else experiencing similar freeze ups with 8.3 or 9.0 while using
> > firefox?
> > 
> I use 8.3 and Firefox without problems. What extension did you install? Are 
> they all properly updated?
> 
> Earlier, it helped deleting firefox' directory in the user directory.
> 
> Erich


Erich,

Thanks for your response.

I've removed the .mozilla directory from my home directory. Let's see if
it will make a difference. It is quite possible it will. I had updated
the firefox port when I updated from 8.2 to 8.3.

Thanks for the suggestion.

joseph

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Text relocations in kernel modules

[Richard Yao]

On 03/30/12 22:15, Peter Wemm wrote:
> On Fri, Mar 30, 2012 at 3:47 PM, Richard Yao  wrote:
>> On 03/30/12 18:46, Konstantin Belousov wrote:
>>> Reread what I wrote to you. Also, it pays off learning how ELF works
>>> before making conclusion from the absence of the output of readelf -d.
>>> Amd64 modules _are not_ shared objects.
>>
>> Whether or not they are shared objects is irrelevant. The fact is that
>> they have text relocations, which interfere with ASLR. Do I need to
>> produce exploit code before you take me seriously?
>>
> 
> I am the person who wrote it and deliberately chose to cause text
> relocations to be generated on i386.  It is by design, not a bug.
> 
> All of your concerns are perfectly valid if they were for userland.
> 
> For the record, our amd64 modules ALSO do this, but your tools simply
> do not detect it.
> 
> Here is what happens, and here is why it is not a problem:
> 
> When you compile with -fpic on an architecture that doesn't support
> PC-relative addressing adequately, the compiler generates code to do
> indirect memory references via the global offset table.  This is so
> that all the relocations can be collected into a single location in
> order to not dirty the MAP_PRIVATE data pages.
> 
> example:
> if there is an function at 0x12345, and another function in a
> different .so file that wants to call it at 0x22345, then the call
> instruction would have to be relocated.  The asm instructions would
> look like:
> 0xE8FFEF  (offset is -0x1)
> 
> If the same .so file was loaded in another user process at 0x32345,
> then the relocation would be different.  An entire page would be
> dirtied by the dynamic linker so that the second instance of the .so
> file had 0xE8FFDF (-0x2).  This is a waste of memory and
> causes a storm of VM faults at startup.
> 
> Instead, the code is compiled with -fPIC, which causes an extra memory
> reference via the global offset table.  Instead of the relocations
> being spread over the text segment, the relocations are in a single
> page.  The dynamic linker has to dirty one page only in order to set
> up a whole host of relocations.
> 
> The cost is i386 doesn't have native pc-relative mode, so it has to
> waste an entire register.  We dedicate one of the 6 general purpose
> registers which costs a hefty performance hit.  This is why crypto
> code tends to be compiled without -fpic, for example.
> 
> For KERNEL modules, all this changes.
> 
> In userland, there is a dynamic linker. In the kernel, there is none.
> In userland, the .so files are mapped with mmap(MAP_PRIVATE), the
> kernel does not use mmap and always uses a private copy.
> In userland, the .so files are shared, the kernel NEVER shares them.
> In userland, doing a relocation causes a copy on write fault, this
> never happens to the kernel because its using private, exclusive
> malloc() pages.
> In userland, we make the performance tradeoff from -fpic in order to
> share memory pages, the kernel never shares pages so -fpic is a waste.
> In userland, ASLR has security benefits.  The kernel already does
> this.. if you load a module on one machine it'll ALWAYS be at
> different address space compared to another.
> 
> In FreeBSD/i386, we use 'ld -shared -o foo.ko *.o', to wrap the non
> pic .o files into a container that was more convenient at the time to
> parse.  There is no global-offset-table.
> In FreeBSD/amd64, we use 'ld -r -o foo.ko *.o' to wrap the same
> non-pic code into a less convenient form that we can feed back into
> the linker if we wish.  There is no global offset table.
> 
> Both i386 and amd64 use raw relocations, regardless of where the came
> from.  Text, data, anywhere.
> 
> This has nothing to do with ASLR, because they are kernel objects, not
> shared libraries.

Most people seem to think that I am unaware of these things, but I
already knew most of it. Note that this mostly applies to remarks people
are sending me privately.

With that said, thank you for the detailed explanation. It filled in a
few blanks that I had, specifically in how FreeBSD does things.

> You posted:
>  * QA Notice: The following files contain runtime text relocations
>  *  Text relocations force the dynamic linker to perform extra
>  *  work at startup, waste system resources, and may pose a security
>  *  risk.  On some architectures, the code may not even function
>  *  properly, if at all.
> The key here is "dynamic linker".  There is no dynamic linker to
> process this stuff.

> This is simply a tools problem on your end.  It's not a bug.

My tools are doing what they were supposed to do. However, people on the
list seem to think that the idea that they are checking for a problem to
be a matter of opinion.

> There are no security implications, no system resources to be wasted.
> 
> And if you think there are security implications, then lets see a
> proof-of-concept.

If I find time to write a proof-of-concept, I promise to publish it
publicly. Your security team w

Re: Text relocations in kernel modules

[Peter Wemm]

On Fri, Mar 30, 2012 at 6:51 PM,   wrote:
> On Fri, Mar 30, 2012 at 06:47:15PM -0400, Richard Yao wrote:
>> On 03/30/12 18:46, Konstantin Belousov wrote:
>> > Reread what I wrote to you. Also, it pays off learning how ELF works
>> > before making conclusion from the absence of the output of readelf -d.
>> > Amd64 modules _are not_ shared objects.
>>
>> Whether or not they are shared objects is irrelevant. The fact is that
>> they have text relocations, which interfere with ASLR. Do I need to
>> produce exploit code before you take me seriously?
>
> Any time you have any reference from a single compilation's object module
> to any code or data in a different compilation you need some way for one
> object to find that code/data.
>
> Think about it: if a function call is going to branch to another function
> it needs to know the address of the target function. How can it get this
> target address? Relocations.
>
> Now, move up a bit to kernel objects which typically consist of multiple
> compilations all linked together. If a function in a kernel object wants
> to call a function in the main part of the kernel it needs the address.
> How can it get this target address? Relocations.
>
> When code is linked together into a single file it is possible to have
> compilations have patched into them the offsets to functions or data from
> other compilations. But this only works when the relative locations are
> fixed.
>
> If you want different kernel objects to get random addresses when loaded
> at run time then you _must_ have some way for the kernel object to call
> back into the main kernel. It is possible to, at the C language level,
> pass around structs holding pointers to functions and pointers to data.
> But this does the same thing as relocations and it does it less efficiently.

When a chunk of code is compiled with -fpic, function calls are
produced with a special relocation type.  When it is linked, all these
calls are gathered into an indirect PLT (procedure linkage table). In
userland, the PLT is dirtied at startup and varies depending on the
random load address.  But all the indirect calls are PC-relative to
the PLT.

eg: if the kernel bzero is at 0xc0201230, and we load a .ko file at
0xc10 which has three "call bzero" references, then:

-fpic case:
all three calls to bzero will pc-relative "call" a slot in the PLT,
which is resolved and created at "ld -shared" time, which will be run
time relocated to "jmp 0xc0201230".
ie:  "call bzero@PLT" -> "jmp bzero" -> bzero()

non-fpic case:
each instance of the three "call bzero" will be relocated without
making an indirect bounce through the PLT, which we don't need.
ie:  "call bzero" -> bzero()
there would be three symbol lookups at .ko load time instead of one.

The big difference (besides the loss of the %ebx register) is those
extra memory hits to do a bzero(), that are paid for every single
time.  Meanwhile the non-pic case has an up-front cost of invoking
some extremely unoptimized code at load time and never has the runtime
overhead.

Linux doesn't use 'ld -shared' format.  They used something vaguely
like what we did with the old LKM system, ie: running ld incrementally
and loading the results.  That was a long time ago, but they sure
don't take the overhead of PLT/GOT/-fpic mode either.  There's just no
need.

We provoke a warning on the gentoo tools on i386 because we simply
used 'ld -shared' output as a container or transport.  We use a
different format by default on amd64, but the code is generated
exactly the same way as on i386 and has exactly the same relocations
in the same places.

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
"All of this is for nothing if we don't go to the stars" - JMS/B5
"If Java had true garbage collection, most programs would delete
themselves upon execution." -- Robert Sewell
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Text relocations in kernel modules

[Peter Wemm]

On Fri, Mar 30, 2012 at 3:47 PM, Richard Yao  wrote:
> On 03/30/12 18:46, Konstantin Belousov wrote:
>> Reread what I wrote to you. Also, it pays off learning how ELF works
>> before making conclusion from the absence of the output of readelf -d.
>> Amd64 modules _are not_ shared objects.
>
> Whether or not they are shared objects is irrelevant. The fact is that
> they have text relocations, which interfere with ASLR. Do I need to
> produce exploit code before you take me seriously?
>

I am the person who wrote it and deliberately chose to cause text
relocations to be generated on i386.  It is by design, not a bug.

All of your concerns are perfectly valid if they were for userland.

For the record, our amd64 modules ALSO do this, but your tools simply
do not detect it.

Here is what happens, and here is why it is not a problem:

When you compile with -fpic on an architecture that doesn't support
PC-relative addressing adequately, the compiler generates code to do
indirect memory references via the global offset table.  This is so
that all the relocations can be collected into a single location in
order to not dirty the MAP_PRIVATE data pages.

example:
if there is an function at 0x12345, and another function in a
different .so file that wants to call it at 0x22345, then the call
instruction would have to be relocated.  The asm instructions would
look like:
0xE8FFEF  (offset is -0x1)

If the same .so file was loaded in another user process at 0x32345,
then the relocation would be different.  An entire page would be
dirtied by the dynamic linker so that the second instance of the .so
file had 0xE8FFDF (-0x2).  This is a waste of memory and
causes a storm of VM faults at startup.

Instead, the code is compiled with -fPIC, which causes an extra memory
reference via the global offset table.  Instead of the relocations
being spread over the text segment, the relocations are in a single
page.  The dynamic linker has to dirty one page only in order to set
up a whole host of relocations.

The cost is i386 doesn't have native pc-relative mode, so it has to
waste an entire register.  We dedicate one of the 6 general purpose
registers which costs a hefty performance hit.  This is why crypto
code tends to be compiled without -fpic, for example.

For KERNEL modules, all this changes.

In userland, there is a dynamic linker. In the kernel, there is none.
In userland, the .so files are mapped with mmap(MAP_PRIVATE), the
kernel does not use mmap and always uses a private copy.
In userland, the .so files are shared, the kernel NEVER shares them.
In userland, doing a relocation causes a copy on write fault, this
never happens to the kernel because its using private, exclusive
malloc() pages.
In userland, we make the performance tradeoff from -fpic in order to
share memory pages, the kernel never shares pages so -fpic is a waste.
In userland, ASLR has security benefits.  The kernel already does
this.. if you load a module on one machine it'll ALWAYS be at
different address space compared to another.

In FreeBSD/i386, we use 'ld -shared -o foo.ko *.o', to wrap the non
pic .o files into a container that was more convenient at the time to
parse.  There is no global-offset-table.
In FreeBSD/amd64, we use 'ld -r -o foo.ko *.o' to wrap the same
non-pic code into a less convenient form that we can feed back into
the linker if we wish.  There is no global offset table.

Both i386 and amd64 use raw relocations, regardless of where the came
from.  Text, data, anywhere.

This has nothing to do with ASLR, because they are kernel objects, not
shared libraries.

You posted:
 * QA Notice: The following files contain runtime text relocations
 *  Text relocations force the dynamic linker to perform extra
 *  work at startup, waste system resources, and may pose a security
 *  risk.  On some architectures, the code may not even function
 *  properly, if at all.
The key here is "dynamic linker".  There is no dynamic linker to
process this stuff.

This is simply a tools problem on your end.  It's not a bug.

There are no security implications, no system resources to be wasted.

And if you think there are security implications, then lets see a
proof-of-concept.

I have given you a detailed explanation of why it's not a problem.  If
you want to continue, then reply with details, not hearsay or
theories.

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
"All of this is for nothing if we don't go to the stars" - JMS/B5
"If Java had true garbage collection, most programs would delete
themselves upon execution." -- Robert Sewell
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: ESCape codes displayed instead of processed in pager

[Matt Thyer]

On Mar 31, 2012 5:02 AM, "Jim Bryant" 
@ gmail.com > wrote:
>
> Matt Thyer wrote:
>
>>
>> On Mar 29, 2012 5:18 AM, "Jim Bryant" 
>> 
@ gmail.com  @ 
gmail.com >> wrote:
>> >
>> > Ever since I have upgraded to 9-stable, I have noticed that the
manpages seem to be munged up with displayed instead of processed ESCape
codes.
>>
>> I believe that this is due to the terminal type of the console changing
from "cons25" to "xterm".  If you fix your /etc/ttys to reflect this things
should be OK.
>>
> 1:27:57pm  argus(19): tty
> /dev/pts/7
> 1:28:03pm  argus(20): setenv TERM xterm
> 1:28:05pm  argus(21): man man
>
> MAN(1)  FreeBSD General Commands Manual
MAN(1)
>
> ESC[1mNAMEESC[0m
>ESC[1mman ESC[22m-- display online manual documentation pages
>
> same thing going on.  that's after switching every vty and the console to
xterm in /etc/ttys as well.
>
> i'm kinda lost on this one.  i have determined that somehow, it's the
pager...  hang on a sec... lemme try vi.
>
> vi seems to be working properly...  it's not the termcap/terminfo...  the
only thing causing this seems to be more and less, both.
>
> when i pipe man into cat, everything gets properly interpreted by the
tty/vty/pty, when i use the pager, i get this crapargh..
>
Some suggestions:

Test with a clean environment (most easily done by creating a new user
account).

If that doesn't fix it then you have a problem with your upgrade that may
be fixed by mergemaster.

You may need to back up your data and do a clean install.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: LSI MegaRAID SAS 9240 with mfi driver?

[Jan Mikkelsen]

On 31/03/2012, at 10:24 AM, Doug Ambrisko wrote:

> Well, then you can do the performance test of the 9240 on the 9261s
> by disabling the battery and the cache!  Feel free to do the test on
> the 9240.  I can't see anything being faster without the NVRAM cache.

The other critical part of the test was making sure the 9240 worked with 
FreeBSD!

On performance and NVRAM, yes, agree on disabling the cache in the 9261 to 
figure out how is will basically perform. Still interested to give the JBOD 
mode a try with ZFS.

Thanks,

Jan.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: LSI MegaRAID SAS 9240 with mfi driver?

[Doug Ambrisko]

Jan Mikkelsen writes:
| On 31/03/2012, at 9:21 AM, Doug Ambrisko wrote:
| 
| > Jan Mikkelsen writes:
| > | I don't know what changes Sean did. Are they in 9.0-release, or do I 
| > | need -stable after a certain point? I'm assuming I should be able to 
| > | take src/sys/dev/mfi/... and src/usr.sbin/mfiutil/... from -current.
| > 
| > It's in the SVN project/head_mfi repro.  You can browse it via the web at:
| > http://svnweb.freebsd.org/base/projects/head_mfi/
| > 
| > It's not in -current yet.  I'm working on the.  I just did all the
| > merges to a look try and eye'd them over.  Now doing a compile test
| > then I can check it into -current.
| 
| OK, will check it out.
| 
| > | The performance is an interesting thing. The write performance I care 
| > | about is ZFS raidz2 with 6 x JBOD disks (or 6 x single disk raid0) on 
| > | this controller. The 9261 with a BBU performs well but obviously costs 
more.
| > 
| > There will need to be clarification in the future.  JBOD is not that
| > same as a single disk RAID.  If I remember correctly, when doing some
| > JBOD testing version single disk RAID is that JBOD is slower.  A 
| > single disk RAID is faster since it can use the RAID.  However, without
| > the battery then you risk losing data on power outage etc.  Without the
| > battery then performance of a JBOD and single disk RAID should be able
| > the same.
| > 
| > A real JBOD as shown by LSI's firmware etc. shows up as a /dev/mfisyspd
| > entries.  JBOD by LSI is a newer thing.
| 
| Ok, interesting. I was told by the distributor that the 9240 supports 
| JBOD mode, but the 9261 doesn't. I'm interested to test it out with ZFS.

Correct, JBOD is not supported on all cards and depending on how the
card comes needs to be enabled.  Again JBOD is not RAID on a single
disk.  Also to clarify mfiutil create jbod does a RAID for each drive
which isn't the same definition of JBOD that LSI talks about.  They
are 2 different animals.  MegaCli can configure LSI JBOD's to enable
the feature and create them.  I'm not really sure what the value of
JBOD support is.  I haven't seen any kind of performance gains.
 
| > | I can see the BBU being important for controller based raid5, but I'm 
| > | hoping that ZFS with JBOD will still perform well. I'm ignorant at this 
| > | point, so that's why I'm trying it out. Do you have any experience or 
| > | expectations with a 9240 being used in a setup like that?
| > 
| > The battery or NVRAM doesn't matter on the RAID type being used since the
| > cache in NVRAM mode, says done whenever it has space in the cache for the
| > write.  Eventually, it will hit the disk.  Without the cache working in
| > this mode the write can't be acknowledged until the disk says done.  So
| > performance suffers.  With a single disk RAID you have been using the
| > cache.
| 
| With RAID-5 it is important because a single update requires two writes 
| and a failure in the window where one write has completed and one write 
| has not could cause data corruption. I don't know whether the controller 
| really handles this case.

That shouldn't be a problem since the acknowledge won't happen until
the writes are all done and if any fail then the I/O should fail back
to the OS.
 
| I guess I'm hopeful that ZFS will perform the function performed by the 
| NVRAM on the controller. I can see how the controller in isolation is 
| clearly slower without a BBU because it has to expose the higher layers 
| to the disk latency.

All the ZFS should really be doing is adding another level of caching.
Without an NVRAM cache, you can't really get the performance gain.
 
| > Now you can force using the cache without NVRAM but you have to acknowledge
| > the risk of that.
| 
| Yes, I understand the risk, and it is one I do not want to take. All
| the 9261s I have deployed have a BBU and go into write through mode if 
| the battery has a problem.
| 
| I think I need to test it in the context of ZFS and see how it works 
| without controller NVRAM.

Well, then you can do the performance test of the 9240 on the 9261s
by disabling the battery and the cache!  Feel free to do the test on
the 9240.  I can't see anything being faster without the NVRAM cache.

Doug A.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: LSI MegaRAID SAS 9240 with mfi driver?

[Jan Mikkelsen]

On 31/03/2012, at 9:21 AM, Doug Ambrisko wrote:

> Jan Mikkelsen writes:
> | I don't know what changes Sean did. Are they in 9.0-release, or do I 
> | need -stable after a certain point? I'm assuming I should be able to 
> | take src/sys/dev/mfi/... and src/usr.sbin/mfiutil/... from -current.
> 
> It's in the SVN project/head_mfi repro.  You can browse it via the web at:
>   http://svnweb.freebsd.org/base/projects/head_mfi/
> 
> It's not in -current yet.  I'm working on the.  I just did all the
> merges to a look try and eye'd them over.  Now doing a compile test
> then I can check it into -current.

OK, will check it out.

> | The performance is an interesting thing. The write performance I care 
> | about is ZFS raidz2 with 6 x JBOD disks (or 6 x single disk raid0) on 
> | this controller. The 9261 with a BBU performs well but obviously costs more.
> 
> There will need to be clarification in the future.  JBOD is not that
> same as a single disk RAID.  If I remember correctly, when doing some
> JBOD testing version single disk RAID is that JBOD is slower.  A 
> single disk RAID is faster since it can use the RAID.  However, without
> the battery then you risk losing data on power outage etc.  Without the
> battery then performance of a JBOD and single disk RAID should be able
> the same.
> 
> A real JBOD as shown by LSI's firmware etc. shows up as a /dev/mfisyspd
> entries.  JBOD by LSI is a newer thing.

Ok, interesting. I was told by the distributor that the 9240 supports JBOD 
mode, but the 9261 doesn't. I'm interested to test it out with ZFS.

> 
> | I can see the BBU being important for controller based raid5, but I'm 
> | hoping that ZFS with JBOD will still perform well. I'm ignorant at this 
> | point, so that's why I'm trying it out. Do you have any experience or 
> | expectations with a 9240 being used in a setup like that?
> 
> The battery or NVRAM doesn't matter on the RAID type being used since the
> cache in NVRAM mode, says done whenever it has space in the cache for the
> write.  Eventually, it will hit the disk.  Without the cache working in
> this mode the write can't be acknowledged until the disk says done.  So
> performance suffers.  With a single disk RAID you have been using the
> cache.

With RAID-5 it is important because a single update requires two writes and a 
failure in the window where one write has completed and one write has not could 
cause data corruption. I don't know whether the controller really handles this 
case.

I guess I'm hopeful that ZFS will perform the function performed by the NVRAM 
on the controller. I can see how the controller in isolation is clearly slower 
without a BBU because it has to expose the higher layers to the disk latency.

> Now you can force using the cache without NVRAM but you have to acknowledge
> the risk of that.

Yes, I understand the risk, and it is one I do not want to take. All the 9261s 
I have deployed have a BBU and go into write through mode if the battery has a 
problem.

I think I need to test it in the context of ZFS and see how it works without 
controller NVRAM.

Regards,

Jan.



___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Text relocations in kernel modules

[Richard Yao]

On 03/30/12 18:46, Konstantin Belousov wrote:
> Reread what I wrote to you. Also, it pays off learning how ELF works
> before making conclusion from the absence of the output of readelf -d.
> Amd64 modules _are not_ shared objects.

Whether or not they are shared objects is irrelevant. The fact is that
they have text relocations, which interfere with ASLR. Do I need to
produce exploit code before you take me seriously?



signature.asc
Description: OpenPGP digital signature

Re: Text relocations in kernel modules

[Konstantin Belousov]

On Fri, Mar 30, 2012 at 06:34:55PM -0400, Richard Yao wrote:
> On 03/30/12 16:36, Konstantin Belousov wrote:
> > First, there _are_ relocations against text in the amd64 modules, but I
> > suspect that your scripts do not detect this. Most likely, scripts look
> > for DT_TEXTREL dynamic tag, and tags are only present in the executables
> > or shared objects, not in the object files. The amd64 modules are object
> > files, so you just mis-interpret the situation.
> 
> readelf is a part of binutils. It is not a script. Here is the version
> that Gentoo/FreeBSD uses:
So you completely missed what I told you.

> 
> # readelf --version
> GNU readelf (GNU Binutils) 2.20.1.20100303
> Copyright 2009 Free Software Foundation, Inc.
> This program is free software; you may redistribute it under the terms of
> the GNU General Public License version 3 or (at your option) any later
> version.
> This program has absolutely no warranty.
> 
> In addition, this is what it says when I ask it to look at virtio_blk.ko:
> 
> # readelf -d /boot/modules/virtio_blk.ko
> 
> Dynamic section at offset 0x2f6c contains 13 entries:
>   TagType Name/Value
>  0x0004 (HASH)   0xd4
>  0x6ef5 (GNU_HASH)   0x480
>  0x0005 (STRTAB) 0x9d0
>  0x0006 (SYMTAB) 0x4e0
>  0x000a (STRSZ)  1295 (bytes)
>  0x000b (SYMENT) 16 (bytes)
>  0x0011 (REL)0xee0
>  0x0012 (RELSZ)  1664 (bytes)
>  0x0013 (RELENT) 8 (bytes)
>  0x0016 (TEXTREL)0x0
>  0x001e (FLAGS)  TEXTREL
>  0x6ffa (RELCOUNT)   87
>  0x (NULL)   0x0
> 
> Running the same command on amd64 FreeBSD's version returns nothing. I
> have attached the result of `readelf -a ...` on both the i386 version
> and the amd64 version.
Reread what I wrote to you. Also, it pays off learning how ELF works
before making conclusion from the absence of the output of readelf -d.
Amd64 modules _are not_ shared objects.

> 
> > Second, from what you wrote, I see the issue in either wrong policy
> > being established in your project, or (another) mis-interpretation of
> > the policy. Indeed, having text relocations in the shared objects is
> > bad, because said relocations hinder text pages sharing. Relocated page
> > is modified, so COW mechanism causes it to become private to process.
> 
> I believe that relocations also cause the linker to work harder when the
> modules themselves are loaded the first time. They can also cause bugs
> when code is ported to another architecture.
I can only answer that this is your fantasy, however ample.
I see that conversation is going nowhere, I will not reply further.

> 
> > On the other hand, there is only one instance of the loaded kernel module,
> > its text segment (or section, for amd64) is not shared, so modifications
> > to the text pages do not cause increased memory use. More, not compiling
> > modules with -fPIC (absence of -fPIC is what makes the text relocations to
> > appear in the final link result) makes the code faster, esp. on i386.
> 
> Compiling with -fPIC breaks the build.
> 
> > So, there is nothing to report, and fix is outside the FreeBSD domain:
> > either fix your policy by not stating that text relocation in kernel
> > module is banned, or just find that policy only applicable to usermode
> > objects.
> 
> Linux has no such text relocations in its modules. I have checked on
> both i386 and amd64. I have difficulty believing that FreeBSD needs text
> relocations when Linux does not.
> 
> I am fairly certain that this is going to interfere with ASLR in the
> kernel, which is a security issue. It is definitely something to report.


pgphVz6PK3bYZ.pgp
Description: PGP signature

Re: LSI MegaRAID SAS 9240 with mfi driver?

[Doug Ambrisko]

Jan Mikkelsen writes:
| Hi,
| 
| On 31/03/2012, at 1:14 AM, Doug Ambrisko wrote:
| 
| > John Baldwin writes:
| > | On Friday, March 30, 2012 12:06:40 am Jan Mikkelsen wrote:
| > | ...
| > | > Is this path likely to work out? Any suggestions on where to go from 
here?
| > | 
| > | You should try the updated mfi(4) driver that Doug (cc'd) is going to soon
| > | merge into HEAD.  It syncs up with the mfi(4) driver on LSI's website 
which
| > | supports several cards that the current mfi(4) driver does not.  (I'm not
| > | fully sure if the 9240 is in that group or not.  Doug might know however.)
| > 
| > Yes, this card is supported with the mfi(4) in projects/head_mfi.  Looks
| > like we fixed a couple of last minute found bugs when trying to create a
| > RAID wth mfiutil.  This should be fixed now.  I'm going to start the
| > merge to -current today.  The version in head_mfi can run on older
| > versions of FreeBSD with the changes that Sean did.
| > 
| > Note that I wouldn't recomend the 9240 since it can't have a battery
| > option.  NVRAM is the key to the speed of mfi(4) cards.  However, that
| > won't stop us from supporting 
| 
| Thanks.
| 
| I don't know what changes Sean did. Are they in 9.0-release, or do I 
| need -stable after a certain point? I'm assuming I should be able to 
| take src/sys/dev/mfi/... and src/usr.sbin/mfiutil/... from -current.

It's in the SVN project/head_mfi repro.  You can browse it via the web at:
http://svnweb.freebsd.org/base/projects/head_mfi/

It's not in -current yet.  I'm working on the.  I just did all the
merges to a look try and eye'd them over.  Now doing a compile test
then I can check it into -current.
 
| The performance is an interesting thing. The write performance I care 
| about is ZFS raidz2 with 6 x JBOD disks (or 6 x single disk raid0) on 
| this controller. The 9261 with a BBU performs well but obviously costs more.

There will need to be clarification in the future.  JBOD is not that
same as a single disk RAID.  If I remember correctly, when doing some
JBOD testing version single disk RAID is that JBOD is slower.  A 
single disk RAID is faster since it can use the RAID.  However, without
the battery then you risk losing data on power outage etc.  Without the
battery then performance of a JBOD and single disk RAID should be able
the same.

A real JBOD as shown by LSI's firmware etc. shows up as a /dev/mfisyspd
entries.  JBOD by LSI is a newer thing.
 
| I can see the BBU being important for controller based raid5, but I'm 
| hoping that ZFS with JBOD will still perform well. I'm ignorant at this 
| point, so that's why I'm trying it out. Do you have any experience or 
| expectations with a 9240 being used in a setup like that?

The battery or NVRAM doesn't matter on the RAID type being used since the
cache in NVRAM mode, says done whenever it has space in the cache for the
write.  Eventually, it will hit the disk.  Without the cache working in
this mode the write can't be acknowledged until the disk says done.  So
performance suffers.  With a single disk RAID you have been using the
cache.

Now you can force using the cache without NVRAM but you have to acknowledge
the risk of that.
 
Doug A.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: LSI MegaRAID SAS 9240 with mfi driver?

[Jan Mikkelsen]

Hi,

On 31/03/2012, at 1:14 AM, Doug Ambrisko wrote:

> John Baldwin writes:
> | On Friday, March 30, 2012 12:06:40 am Jan Mikkelsen wrote:
> | ...
> | > Is this path likely to work out? Any suggestions on where to go from here?
> | 
> | You should try the updated mfi(4) driver that Doug (cc'd) is going to soon
> | merge into HEAD.  It syncs up with the mfi(4) driver on LSI's website which
> | supports several cards that the current mfi(4) driver does not.  (I'm not
> | fully sure if the 9240 is in that group or not.  Doug might know however.)
> 
> Yes, this card is supported with the mfi(4) in projects/head_mfi.  Looks
> like we fixed a couple of last minute found bugs when trying to create a
> RAID wth mfiutil.  This should be fixed now.  I'm going to start the
> merge to -current today.  The version in head_mfi can run on older
> versions of FreeBSD with the changes that Sean did.
> 
> Note that I wouldn't recomend the 9240 since it can't have a battery
> option.  NVRAM is the key to the speed of mfi(4) cards.  However, that
> won't stop us from supporting 

Thanks.

I don't know what changes Sean did. Are they in 9.0-release, or do I need 
-stable after a certain point? I'm assuming I should be able to take 
src/sys/dev/mfi/... and src/usr.sbin/mfiutil/... from -current.

The performance is an interesting thing. The write performance I care about is 
ZFS raidz2 with 6 x JBOD disks (or 6 x single disk raid0) on this controller. 
The 9261 with a BBU performs well but obviously costs more.

I can see the BBU being important for controller based raid5, but I'm hoping 
that ZFS with JBOD will still perform well. I'm ignorant at this point, so 
that's why I'm trying it out. Do you have any experience or expectations with a 
9240 being used in a setup like that?

Regards,

Jan.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: [stable-ish 9] Dell R815 ipmi(4) attach failure

[Sean Bruno]

> This is the relevant bits:
> 
> Handle 0x2600, DMI type 38, 18 bytes
> IPMI Device Information
>   Interface Type: KCS (Keyboard Control Style)
>   Specification Version: 2.0
>   I2C Slave Address: 0x10
>   NV Storage Device: Not Present
>   Base Address: 0x0CA8 (I/O)
>   Register Spacing: 32-bit Boundaries
> 
> Note the '32-bit' boundaries.  I think ACPI doesn't support that for its 
> attachment (well, it does if they specify each port as a separate thing in 
> _CRS).  Can you get acpidump -d output?
> 

Aye, here ya go. 

http://people.freebsd.org/~sbruno/acpidump_r815.txt

sean

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: [stable-ish 9] Dell R815 ipmi(4) attach failure

[John Baldwin]

On Friday, March 30, 2012 4:03:54 pm Sean Bruno wrote:
> On Fri, 2012-03-30 at 09:29 -0700, John Baldwin wrote:
> > On Thursday, March 29, 2012 12:48:39 pm Sean Bruno wrote:
> > > Noting a failure to attach to the onboard IPMI controller with this dell
> > > R815.  Not sure what to start poking at and thought I'd though this over
> > > here for comment.
> > > 
> > > -bash-4.2$ dmesg |grep ipmi
> > > ipmi0: KCS mode found at io 0xca8 on acpi
> > > ipmi1:  on isa0
> > > device_attach: ipmi1 attach returned 16
> > > ipmi1:  on isa0
> > > device_attach: ipmi1 attach returned 16
> > > ipmi0: Timed out waiting for GET_DEVICE_ID
> > > 
> > > 
> > > -bash-4.2$ sysctl -a|grep ipmi
> > > device  ipmi# IPMI
> > > hw.ipmi.on: 1
> > > dev.ipmi.0.%desc: IPMI System Interface
> > > dev.ipmi.0.%driver: ipmi
> > > dev.ipmi.0.%location: handle=\_SB_.PCI0.ISA_.NIPM
> > > dev.ipmi.0.%pnpinfo: _HID=IPI0001 _UID=5
> > > dev.ipmi.0.%parent: acpi0
> > 
> > Can you get dmidecode output?
> > 
> 
> 
> http://people.freebsd.org/~sbruno/dmidecode_r815.txt

This is the relevant bits:

Handle 0x2600, DMI type 38, 18 bytes
IPMI Device Information
Interface Type: KCS (Keyboard Control Style)
Specification Version: 2.0
I2C Slave Address: 0x10
NV Storage Device: Not Present
Base Address: 0x0CA8 (I/O)
Register Spacing: 32-bit Boundaries

Note the '32-bit' boundaries.  I think ACPI doesn't support that for its 
attachment (well, it does if they specify each port as a separate thing in 
_CRS).  Can you get acpidump -d output?

-- 
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 9-STABLE, ZFS, NFS, ggatec - suspected memory leak

[Philip M. Gollucci]

http://lists.freebsd.org/pipermail/freebsd-questions/2012-March/239643.html

Same issue different thread.  Different software.

Its not NFS, its ZFS.

I don't really have a place to try it on 8.2, but my hunch from things
I've done rather similarly which don't cause tell me its a new issue in
9.0, though I won't swear by that.



On 03/30/12 08:38, Oliver Brandmueller wrote:
> Hi all,
> 
> Setup:
> 
> I'm running 2 machines (amd64, 16GB) with FreeBSD 9-STABLE (Mar 14 so 
> far) acting as NFS servers. They each serve 3 zpools (holding a single 
> zfs, hourly snapshots). The zpools each are 3-way mirrors of ggate 
> devices, each 2 TB, so 2 TB per zpool. Compression is "on" (to save 
> bandwith to the backend, compressratio around 1.05 to 1.15), atime is 
> off.
> 
> There is no special tuning in loader.conf (except I tried to limit ZFS 
> ARC to 8GB lately, which doesn't change a lot). sysctl.conf has:
> 
> kern.ipc.maxsockbuf=33554432
> net.inet.tcp.sendspace=8388608
> net.inet.tcp.recvspace=8388608
> kern.maxfiles=64000
> vfs.nfsd.maxthreads=254
> 
> Without the first three zfs+ggate goes bad after a short time (checksum 
> errors, stall), the latter are mainly for NFS and some regular local 
> cleanup stuff.
> 
> The machines have 4 em and 2 igb network interfaces. 3 of the are 
> dedicated links (with no switches) to the ggate servers, one is a 
> dedicated link to a third machine which gets feeded with incremental 
> snapshots by ZFS send (as backup and fallaback of last resort), one 
> interface for management tasks and one to an internal network with the 
> NFS clients.
> 
> The NFS clients are mostly FreeBSD 6, 7 and 9 STABLE machines (migration 
> to 9 is running), no NFSv4 (by now), all tcp NFS links, merely no 
> locking.
> 
> Data consists of a lot of files, this is mainly mailboxes (IMAP: 
> dovecot, incoming mail with exim, some simple web stuff with apache), so 
> lots of small files, only few bigger ones. Directory structures to a 
> reasonable depth.
> 
> System is on a SSD (ufs, trim), additionally there are 3 (4 actually, 1 
> unused by now) 120GB SSDs serving as cache devices for the zpools. I 
> first starting using the whole device, but in my hopes to change 
> something limited cache to partitions of 32GB without change in 
> behaviour.
> 
> 
> Problem:
> 
> After about a week of runtime in normal workload the systems starts to 
> swap (with about 300 to 500 MB of RAM free). Lots of swapping in and 
> out, but only very few swap space used (30 to 50 MB). ZFS ARC at that 
> point reaches it's minimum (while using up to it's configured maximum 
> before). Most of the RAM is wired. L2ARC headers, accourding to 
> zfs-stats eat about 1GB, ARC is at 1.8GB at this time. No userland 
> processes using lots of RAM.
> 
> After some time the system becomes unresponsive, the only way to fix 
> this I had found by now is to reboot the machine (which of course gives 
> a service interruption).
> 
>>From the start of swapping to unresponsiveness I have about 2 to 4 hours 
> to check several things (if I just knew what!).
> 
> Workload distribution is not even over the day, from my munin graphs I 
> can see, that wired grows at time of higher workload. At night with 
> lower workload (but far from nothing, let's say about 1/3 to 1/2 in 
> writes, but probably <1/4 in reads from weekday workload) I can barely 
> see any groth of the wired graph.
> 
> So where is my memory going, any ideas what to change?
> 
> Kernel is stripped down from GENERIC and then everything I need loaded 
> as modules.
> 
> Kernel config: http://sysadm.in/zprob/ZSTOR
> loader.conf  : http://sysadm.in/zprob/loader.conf
> dmesg.boot   : http://sysadm.in/zprob/dmesg.boot
> 
> 


-- 

1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70  3F8C 75B8 8FFB DB9B 8C1C
Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354
Member,   Apache Software Foundation
Committer,FreeBSD Foundation
Consultant,   P6M7G8 Inc.
Director Operations,  Ridecharge Inc.

Work like you don't need the money,
love like you'll never get hurt,
and dance like nobody's watching.



signature.asc
Description: OpenPGP digital signature

Re: Text relocations in kernel modules

[Konstantin Belousov]

On Fri, Mar 30, 2012 at 04:11:29PM -0400, Richard Yao wrote:
> On 03/30/12 15:46, Konstantin Belousov wrote:
> > On Fri, Mar 30, 2012 at 03:42:22PM -0400, Richard Yao wrote:
> >> On 03/30/12 15:07, Konstantin Belousov wrote:
>  Is this a bug?
> >>> No. This is by design.
> >>>
> >>> Why do you consider this a bug ?
> >>
> >> It occurs on i386, but not amd64. It could be that something is wrong
> >> with how things are being compiled i386, or it could be that i386
> >> requires things to be compiled this way. I do not know which.
> >>
> > Again, let me repeat my question. Why do you consider the presence
> > of relocations against text section a problem ?
> 
> The linker emits warnings:
> i686-gentoo-freebsd9.0-ld: warning: creating a DT_TEXTREL in object.
> 
> Furthermore, this triggers a QA check in Gentoo/FreeBSD's package manager.
> 
>  * QA Notice: The following files contain runtime text relocations
>  *  Text relocations force the dynamic linker to perform extra
>  *  work at startup, waste system resources, and may pose a security
>  *  risk.  On some architectures, the code may not even function
>  *  properly, if at all.
>  *  For more information, see http://hardened.gentoo.org/pic-fix-guide.xml
>  *  Please include the following list of files in your report:
>  * TEXTREL boot/modules/if_vtnet.ko
>  * TEXTREL boot/modules/virtio_blk.ko
>  * TEXTREL boot/modules/virtio.ko
>  * TEXTREL boot/modules/virtio_balloon.ko
>  * TEXTREL boot/modules/virtio_pci.ko
> 
> I wrote that ebuild as part of something entirely unrelated. If it is a
> feature, I can disable the QA check, but I should at least know why the
> text relocations are needed.
> 
> Gentoo maintainers are expected to patch text relocations and send
> patches upstream. The only exception is in the case of binary packages,
> which they cannot patch.
> 
> Investigating the text relocations in my port of emulators/virtio-kmod
> revealed that all kernel modules on i386 Gentoo/FreeBSD have text
> relocations, yet none have them on amd64 FreeBSD, so I do not know
> whether this is a bug or a feature.
> 

First, there _are_ relocations against text in the amd64 modules, but I
suspect that your scripts do not detect this. Most likely, scripts look
for DT_TEXTREL dynamic tag, and tags are only present in the executables
or shared objects, not in the object files. The amd64 modules are object
files, so you just mis-interpret the situation.

Second, from what you wrote, I see the issue in either wrong policy
being established in your project, or (another) mis-interpretation of
the policy. Indeed, having text relocations in the shared objects is
bad, because said relocations hinder text pages sharing. Relocated page
is modified, so COW mechanism causes it to become private to process.

On the other hand, there is only one instance of the loaded kernel module,
its text segment (or section, for amd64) is not shared, so modifications
to the text pages do not cause increased memory use. More, not compiling
modules with -fPIC (absence of -fPIC is what makes the text relocations to
appear in the final link result) makes the code faster, esp. on i386.

So, there is nothing to report, and fix is outside the FreeBSD domain:
either fix your policy by not stating that text relocation in kernel
module is banned, or just find that policy only applicable to usermode
objects.


pgpc8leWKmOO5.pgp
Description: PGP signature

Re: Text relocations in kernel modules

[Richard Yao]

On 03/30/12 15:46, Konstantin Belousov wrote:
> On Fri, Mar 30, 2012 at 03:42:22PM -0400, Richard Yao wrote:
>> On 03/30/12 15:07, Konstantin Belousov wrote:
 Is this a bug?
>>> No. This is by design.
>>>
>>> Why do you consider this a bug ?
>>
>> It occurs on i386, but not amd64. It could be that something is wrong
>> with how things are being compiled i386, or it could be that i386
>> requires things to be compiled this way. I do not know which.
>>
> Again, let me repeat my question. Why do you consider the presence
> of relocations against text section a problem ?

The linker emits warnings:
i686-gentoo-freebsd9.0-ld: warning: creating a DT_TEXTREL in object.

Furthermore, this triggers a QA check in Gentoo/FreeBSD's package manager.

 * QA Notice: The following files contain runtime text relocations
 *  Text relocations force the dynamic linker to perform extra
 *  work at startup, waste system resources, and may pose a security
 *  risk.  On some architectures, the code may not even function
 *  properly, if at all.
 *  For more information, see http://hardened.gentoo.org/pic-fix-guide.xml
 *  Please include the following list of files in your report:
 * TEXTREL boot/modules/if_vtnet.ko
 * TEXTREL boot/modules/virtio_blk.ko
 * TEXTREL boot/modules/virtio.ko
 * TEXTREL boot/modules/virtio_balloon.ko
 * TEXTREL boot/modules/virtio_pci.ko

I wrote that ebuild as part of something entirely unrelated. If it is a
feature, I can disable the QA check, but I should at least know why the
text relocations are needed.

Gentoo maintainers are expected to patch text relocations and send
patches upstream. The only exception is in the case of binary packages,
which they cannot patch.

Investigating the text relocations in my port of emulators/virtio-kmod
revealed that all kernel modules on i386 Gentoo/FreeBSD have text
relocations, yet none have them on amd64 FreeBSD, so I do not know
whether this is a bug or a feature.



signature.asc
Description: OpenPGP digital signature

Re: [stable-ish 9] Dell R815 ipmi(4) attach failure

[Sean Bruno]

On Fri, 2012-03-30 at 09:29 -0700, John Baldwin wrote:
> On Thursday, March 29, 2012 12:48:39 pm Sean Bruno wrote:
> > Noting a failure to attach to the onboard IPMI controller with this dell
> > R815.  Not sure what to start poking at and thought I'd though this over
> > here for comment.
> > 
> > -bash-4.2$ dmesg |grep ipmi
> > ipmi0: KCS mode found at io 0xca8 on acpi
> > ipmi1:  on isa0
> > device_attach: ipmi1 attach returned 16
> > ipmi1:  on isa0
> > device_attach: ipmi1 attach returned 16
> > ipmi0: Timed out waiting for GET_DEVICE_ID
> > 
> > 
> > -bash-4.2$ sysctl -a|grep ipmi
> > device  ipmi# IPMI
> > hw.ipmi.on: 1
> > dev.ipmi.0.%desc: IPMI System Interface
> > dev.ipmi.0.%driver: ipmi
> > dev.ipmi.0.%location: handle=\_SB_.PCI0.ISA_.NIPM
> > dev.ipmi.0.%pnpinfo: _HID=IPI0001 _UID=5
> > dev.ipmi.0.%parent: acpi0
> 
> Can you get dmidecode output?
> 


http://people.freebsd.org/~sbruno/dmidecode_r815.txt

http://people.freebsd.org/~sbruno/pciconf_r815.txt

Sean

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Text relocations in kernel modules

[Richard Yao]

On 03/30/12 15:07, Konstantin Belousov wrote:
>> Is this a bug?
> No. This is by design.
> 
> Why do you consider this a bug ?

It occurs on i386, but not amd64. It could be that something is wrong
with how things are being compiled i386, or it could be that i386
requires things to be compiled this way. I do not know which.



signature.asc
Description: OpenPGP digital signature

Re: Text relocations in kernel modules

[Konstantin Belousov]

On Fri, Mar 30, 2012 at 01:38:14PM -0400, Richard Yao wrote:
> As a disclaimer, I would like to clarify that Gentoo/FreeBSD uses a
> FreeBSD userland and that Gentoo/FreeBSD has nothing to do with Debian
> GNU/kFreeBSD. People seem to think Gentoo/FreeBSD is related to Debian
> GNU/kFreeBSD, which has made collaboration difficult.
> 
> With that said, Gentoo Portage is warning about text relocations in
> kernel modules. This is in a Gentoo/FreeBSD port of
> emulators/freebsd-kmod that I wrote. For instance, I see:
> 
> # readelf -d /boot/modules/virtio.ko
> 
> Dynamic section at offset 0x2f6c contains 13 entries:
>   TagType Name/Value
>  0x0004 (HASH)   0xd4
>  0x6ef5 (GNU_HASH)   0x238
>  0x0005 (STRTAB) 0x4a8
>  0x0006 (SYMTAB) 0x298
>  0x000a (STRSZ)  397 (bytes)
>  0x000b (SYMENT) 16 (bytes)
>  0x0011 (REL)0x638
>  0x0012 (RELSZ)  1568 (bytes)
>  0x0013 (RELENT) 8 (bytes)
>  0x0016 (TEXTREL)0x0
>  0x001e (FLAGS)  TEXTREL
>  0x6ffa (RELCOUNT)   108
>  0x (NULL)   0x0
> 
> Checking /boot/kernel, it seems that all modules have text relocations.
> My Gentoo/FreeBSD install is a 32-bit chroot on a ZFS Guru install of
> amd64 FreeBSD. amd64 FreeBSD does not appear to have any text relocations.
> 
> I don't have a reference i386 install, but according to frogs in
> ##freebsd on freenode, his i386 FreeBSD also has text relocations.
> 
> Is this a bug?
No. This is by design.

Why do you consider this a bug ?
> 
> Yours truly,
> Richard Yao
> 
> On 03/30/12 12:49, Richard Yao wrote:
> > Dear Ports Maintainers and kuriyama,
> > 
> > emulators/freebsd-kmod has a typo in pkg-descr, where it says "lodable"
> > instead of "loadable".
> > 
> > In addition, I have done the work necessary to port
> > emulators/freebsd-kmod to Gentoo/FreeBSD.
> > 
> > https://bugs.gentoo.org/show_bug.cgi?id=410199
> > 
> > The ebuild contains a few improvements on the original FreeBSD port
> > where we copy only the parts of SYSDIR that we need to build the module.
> > We also do hardlinks instead of copies when Gentoo Portage builds with
> > user privileges.
> > 
> > The NEEDSUBDIRS part of the ebuild was written by naota AT gentoo.org as
> > part of Gentoo's review process. I have permission from him to upstream
> > the improvements we made on the port. Feel free to adopt any
> > improvements in the attachments in that bug report.
> > 
> > Lastly, I have sent an email to gentoo-dev AT lists.gentoo.org and
> > gentoo-bsd AT lists.gentoo.org requesting that the FreeBSD specific
> > parts of the portage tree be relicensed under terms of the BSD-2
> > license. With a little luck, it will be possible to upstream
> > improvements made in Gentoo/FreeBSD without any hassle in the future.
> > 
> > Yours truly,
> > Richard Yao
> > 
> 
> 




pgpl5RLyaPw25.pgp
Description: PGP signature

Re: ESCape codes displayed instead of processed in pager

[Jim Bryant]

Matt Thyer wrote:


On Mar 29, 2012 5:18 AM, "Jim Bryant" > wrote:

>
> Ever since I have upgraded to 9-stable, I have noticed that the 
manpages seem to be munged up with displayed instead of processed 
ESCape codes.


I believe that this is due to the terminal type of the console 
changing from "cons25" to "xterm".  If you fix your /etc/ttys to 
reflect this things should be OK.



1:27:57pm  argus(19): tty
/dev/pts/7
1:28:03pm  argus(20): setenv TERM xterm
1:28:05pm  argus(21): man man
MAN(1)  FreeBSD General Commands Manual 
MAN(1)


ESC[1mNAMEESC[0m
ESC[1mman ESC[22m-- display online manual documentation pages

same thing going on.  that's after switching every vty and the console 
to xterm in /etc/ttys as well.


i'm kinda lost on this one.  i have determined that somehow, it's the 
pager...  hang on a sec... lemme try vi.


vi seems to be working properly...  it's not the termcap/terminfo...  
the only thing causing this seems to be more and less, both.


when i pipe man into cat, everything gets properly interpreted by the 
tty/vty/pty, when i use the pager, i get this crapargh..


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Text relocations in kernel modules

[Richard Yao]

As a disclaimer, I would like to clarify that Gentoo/FreeBSD uses a
FreeBSD userland and that Gentoo/FreeBSD has nothing to do with Debian
GNU/kFreeBSD. People seem to think Gentoo/FreeBSD is related to Debian
GNU/kFreeBSD, which has made collaboration difficult.

With that said, Gentoo Portage is warning about text relocations in
kernel modules. This is in a Gentoo/FreeBSD port of
emulators/freebsd-kmod that I wrote. For instance, I see:

# readelf -d /boot/modules/virtio.ko

Dynamic section at offset 0x2f6c contains 13 entries:
  TagType Name/Value
 0x0004 (HASH)   0xd4
 0x6ef5 (GNU_HASH)   0x238
 0x0005 (STRTAB) 0x4a8
 0x0006 (SYMTAB) 0x298
 0x000a (STRSZ)  397 (bytes)
 0x000b (SYMENT) 16 (bytes)
 0x0011 (REL)0x638
 0x0012 (RELSZ)  1568 (bytes)
 0x0013 (RELENT) 8 (bytes)
 0x0016 (TEXTREL)0x0
 0x001e (FLAGS)  TEXTREL
 0x6ffa (RELCOUNT)   108
 0x (NULL)   0x0

Checking /boot/kernel, it seems that all modules have text relocations.
My Gentoo/FreeBSD install is a 32-bit chroot on a ZFS Guru install of
amd64 FreeBSD. amd64 FreeBSD does not appear to have any text relocations.

I don't have a reference i386 install, but according to frogs in
##freebsd on freenode, his i386 FreeBSD also has text relocations.

Is this a bug?

Yours truly,
Richard Yao

On 03/30/12 12:49, Richard Yao wrote:
> Dear Ports Maintainers and kuriyama,
> 
> emulators/freebsd-kmod has a typo in pkg-descr, where it says "lodable"
> instead of "loadable".
> 
> In addition, I have done the work necessary to port
> emulators/freebsd-kmod to Gentoo/FreeBSD.
> 
> https://bugs.gentoo.org/show_bug.cgi?id=410199
> 
> The ebuild contains a few improvements on the original FreeBSD port
> where we copy only the parts of SYSDIR that we need to build the module.
> We also do hardlinks instead of copies when Gentoo Portage builds with
> user privileges.
> 
> The NEEDSUBDIRS part of the ebuild was written by naota AT gentoo.org as
> part of Gentoo's review process. I have permission from him to upstream
> the improvements we made on the port. Feel free to adopt any
> improvements in the attachments in that bug report.
> 
> Lastly, I have sent an email to gentoo-dev AT lists.gentoo.org and
> gentoo-bsd AT lists.gentoo.org requesting that the FreeBSD specific
> parts of the portage tree be relicensed under terms of the BSD-2
> license. With a little luck, it will be possible to upstream
> improvements made in Gentoo/FreeBSD without any hassle in the future.
> 
> Yours truly,
> Richard Yao
> 




signature.asc
Description: OpenPGP digital signature

Re: Floppy disks don't work with FreeBSD 9.0

[John Baldwin]

On Wednesday, March 28, 2012 3:57:37 pm Thomas Laus wrote:
> > Hi.
> > 
> > I'm a bit short on free machines, so the closest I can get right now
> > is my everyday machine running from sources cvsupped from
> > RELENG_8 3.rd of March:
> > 
> I 'csuped' to FreeBSD 9.0-STABLE today and still had the same problem.  This 
> computer has normal floppy disk operation when using FreeBSD 8.3-RC1 and 
> doesn't have any fd functionality with FreeBSD 9.0-STABLE.  I entered a 
> Problem Report in the system today.
> 
> Thanks for all of the help, we'll let the development team take if from 
here.

I just fixed a bug in HEAD yesterday where bounce buffers for ISA DMA were 
broken in 9.  Can you try that change out?

Author: jhb
Date: Thu Mar 29 18:58:02 2012
New Revision: 233675
URL: http://svn.freebsd.org/changeset/base/233675

Log:
  Restore proper use of bounce buffers for ISA DMA.  When locking was
  added, the call to pmap_kextract() was moved up, and as a result the
  code never updated the physical address to use for DMA if a bounce
  buffer was used.  Restore the earlier location of pmap_kextract() so
  it takes bounce buffers into account.
  
  Tested by:kargl
  MFC after:1 week

Modified:
  head/sys/x86/isa/isa_dma.c

Modified: head/sys/x86/isa/isa_dma.c
==
--- head/sys/x86/isa/isa_dma.c  Thu Mar 29 17:50:01 2012(r233674)
+++ head/sys/x86/isa/isa_dma.c  Thu Mar 29 18:58:02 2012(r233675)
@@ -237,8 +237,6 @@ isa_dmastart(int flags, caddr_t addr, u_
caddr_t newaddr;
int dma_range_checked;
 
-   /* translate to physical */
-   phys = pmap_extract(kernel_pmap, (vm_offset_t)addr);
dma_range_checked = isa_dmarangecheck(addr, nbytes, chan);
 
 #ifdef DIAGNOSTIC
@@ -281,6 +279,9 @@ isa_dmastart(int flags, caddr_t addr, u_
addr = newaddr;
}
 
+   /* translate to physical */
+   phys = pmap_extract(kernel_pmap, (vm_offset_t)addr);
+
if (flags & ISADMA_RAW) {
dma_auto_mode |= (1 << chan);
} else { 

-- 
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: [stable-ish 9] Dell R815 ipmi(4) attach failure

[John Baldwin]

On Thursday, March 29, 2012 12:48:39 pm Sean Bruno wrote:
> Noting a failure to attach to the onboard IPMI controller with this dell
> R815.  Not sure what to start poking at and thought I'd though this over
> here for comment.
> 
> -bash-4.2$ dmesg |grep ipmi
> ipmi0: KCS mode found at io 0xca8 on acpi
> ipmi1:  on isa0
> device_attach: ipmi1 attach returned 16
> ipmi1:  on isa0
> device_attach: ipmi1 attach returned 16
> ipmi0: Timed out waiting for GET_DEVICE_ID
> 
> 
> -bash-4.2$ sysctl -a|grep ipmi
> device  ipmi# IPMI
> hw.ipmi.on: 1
> dev.ipmi.0.%desc: IPMI System Interface
> dev.ipmi.0.%driver: ipmi
> dev.ipmi.0.%location: handle=\_SB_.PCI0.ISA_.NIPM
> dev.ipmi.0.%pnpinfo: _HID=IPI0001 _UID=5
> dev.ipmi.0.%parent: acpi0

Can you get dmidecode output?

-- 
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: LSI MegaRAID SAS 9240 with mfi driver?

[Doug Ambrisko]

John Baldwin writes:
| On Friday, March 30, 2012 12:06:40 am Jan Mikkelsen wrote:
| > Hi,
| > 
| > I have a loan LSI MegaRAID SAS 9240-4i controller for testing.
| > 
| > According to the LSI documentation, this device provides the MegaRAID 
| > interface and the BIOS message mentions MFI. The LSI driver for this device 
| > also lists support for the 9261 which I know is supported by mfi(4). 
| > Based on all this, I was hopeful that mfi(4) would work with the 9240.
| > 
| > The pciconf -lv output is:
| > 
| > none3@pci0:1:0:0:   class=0x010400 card=0x92411000 chip=0x00731000 rev=0x03 
hdr=0x00
| > vendor = 'LSI Logic / Symbios Logic'
| > device = 'MegaRAID SAS 9240'
| > class  = mass storage
| > subclass   = RAID
| > 
| > I added this line to src/sys/dev/mfi/mfi_pci.c
| > 
| > {0x1000, 0x0073, 0x, 0x, MFI_FLAGS_GEN2, "LSI MegaRAID SAS 
9240"},
| > 
| > It gave this result (tried with hw.mfi.msi set to 0 and to 1):
| > 
| > mfi0:  port 0xdc00-0xdcff mem 
0xfe7bc000-0xfe7b,0xfe7c-0xfe7f irq 16 at device 0.0 on pci1
| > mfi0: Using MSI
| > mfi0: Megaraid SAS driver Ver 3.00 
| > mfi0: Frame 0xff8000285000 timed out command 0x26C8040
| > mfi0: failed to send init command
| > 
| > The firmware is package 20.10.1-0077, which is the latest on the LSI 
website.
| > 
| > Is this path likely to work out? Any suggestions on where to go from here?
| 
| You should try the updated mfi(4) driver that Doug (cc'd) is going to soon
| merge into HEAD.  It syncs up with the mfi(4) driver on LSI's website which
| supports several cards that the current mfi(4) driver does not.  (I'm not
| fully sure if the 9240 is in that group or not.  Doug might know however.)

Yes, this card is supported with the mfi(4) in projects/head_mfi.  Looks
like we fixed a couple of last minute found bugs when trying to create a
RAID wth mfiutil.  This should be fixed now.  I'm going to start the
merge to -current today.  The version in head_mfi can run on older
versions of FreeBSD with the changes that Sean did.

Note that I wouldn't recomend the 9240 since it can't have a battery
option.  NVRAM is the key to the speed of mfi(4) cards.  However, that
won't stop us from supporting it.

Doug A.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: LSI MegaRAID SAS 9240 with mfi driver?

[John Baldwin]

On Friday, March 30, 2012 12:06:40 am Jan Mikkelsen wrote:
> Hi,
> 
> I have a loan LSI MegaRAID SAS 9240-4i controller for testing.
> 
> According to the LSI documentation, this device provides the MegaRAID 
> interface and the BIOS message mentions MFI. The LSI driver for this device 
also lists support for the 9261 which I know is supported by mfi(4). Based on 
all this, I was hopeful that mfi(4) would work with the 9240.
> 
> The pciconf -lv output is:
> 
> none3@pci0:1:0:0: class=0x010400 card=0x92411000 chip=0x00731000 rev=0x03 
> hdr=0x00
> vendor = 'LSI Logic / Symbios Logic'
> device = 'MegaRAID SAS 9240'
> class  = mass storage
> subclass   = RAID
> 
> I added this line to src/sys/dev/mfi/mfi_pci.c
> 
>   {0x1000, 0x0073, 0x, 0x, MFI_FLAGS_GEN2, "LSI MegaRAID SAS 
> 9240"},
> 
> It gave this result (tried with hw.mfi.msi set to 0 and to 1):
> 
> mfi0:  port 0xdc00-0xdcff mem 
> 0xfe7bc000-0xfe7b,0xfe7c-0xfe7f irq 16 at device 0.0 on pci1
> mfi0: Using MSI
> mfi0: Megaraid SAS driver Ver 3.00 
> mfi0: Frame 0xff8000285000 timed out command 0x26C8040
> mfi0: failed to send init command
> 
> The firmware is package 20.10.1-0077, which is the latest on the LSI website.
> 
> Is this path likely to work out? Any suggestions on where to go from here?

You should try the updated mfi(4) driver that Doug (cc'd) is going to soon
merge into HEAD.  It syncs up with the mfi(4) driver on LSI's website which
supports several cards that the current mfi(4) driver does not.  (I'm not
fully sure if the 9240 is in that group or not.  Doug might know however.)

-- 
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: ESCape codes displayed instead of processed in pager

[Matt Thyer]

On Mar 29, 2012 5:18 AM, "Jim Bryant"  wrote:
>
> Ever since I have upgraded to 9-stable, I have noticed that the manpages
seem to be munged up with displayed instead of processed ESCape codes.

I believe that this is due to the terminal type of the console changing
from "cons25" to "xterm".  If you fix your /etc/ttys to reflect this things
should be OK.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: SAS Drive identification LEDs

[Mike Pumford]

Fred Liu wrote:


How would you identify such a drive on any other system?



Normally, there are printed labels as the backup solution.

You can identify SAS drives in an enclosure if the drive and enclosure 
provide the information needed.


If you issue an INQUIRY EVPD read of page 0x83 on the drive it should 
give you the WWN and target SAS addresses of the drive. You should then 
be able to tie this up with the array element in the enclosure by 
matching it up with data in the SES diagnostic page 0xA from the enclosure.


sg3_utils provides command line tools that can perform these queries.

Mike
--
Mike Pumford, Senior Software Engineer
MPC Data Limited
e-mail: mpumf...@mpcdata.comweb: www.mpcdata.com
tel: +44 (0) 1225 710600fax: +44 (0) 1225 710601
ddi: +44 (0) 1225 710635

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: SAS Drive identification LEDs

[Fred Liu]

>
> How would you identify such a drive on any other system?
>

Normally, there are printed labels as the backup solution.

Thanks.

Fred
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

9-STABLE, ZFS, NFS, ggatec - suspected memory leak

[Oliver Brandmueller]

Hi all,

Setup:

I'm running 2 machines (amd64, 16GB) with FreeBSD 9-STABLE (Mar 14 so 
far) acting as NFS servers. They each serve 3 zpools (holding a single 
zfs, hourly snapshots). The zpools each are 3-way mirrors of ggate 
devices, each 2 TB, so 2 TB per zpool. Compression is "on" (to save 
bandwith to the backend, compressratio around 1.05 to 1.15), atime is 
off.

There is no special tuning in loader.conf (except I tried to limit ZFS 
ARC to 8GB lately, which doesn't change a lot). sysctl.conf has:

kern.ipc.maxsockbuf=33554432
net.inet.tcp.sendspace=8388608
net.inet.tcp.recvspace=8388608
kern.maxfiles=64000
vfs.nfsd.maxthreads=254

Without the first three zfs+ggate goes bad after a short time (checksum 
errors, stall), the latter are mainly for NFS and some regular local 
cleanup stuff.

The machines have 4 em and 2 igb network interfaces. 3 of the are 
dedicated links (with no switches) to the ggate servers, one is a 
dedicated link to a third machine which gets feeded with incremental 
snapshots by ZFS send (as backup and fallaback of last resort), one 
interface for management tasks and one to an internal network with the 
NFS clients.

The NFS clients are mostly FreeBSD 6, 7 and 9 STABLE machines (migration 
to 9 is running), no NFSv4 (by now), all tcp NFS links, merely no 
locking.

Data consists of a lot of files, this is mainly mailboxes (IMAP: 
dovecot, incoming mail with exim, some simple web stuff with apache), so 
lots of small files, only few bigger ones. Directory structures to a 
reasonable depth.

System is on a SSD (ufs, trim), additionally there are 3 (4 actually, 1 
unused by now) 120GB SSDs serving as cache devices for the zpools. I 
first starting using the whole device, but in my hopes to change 
something limited cache to partitions of 32GB without change in 
behaviour.


Problem:

After about a week of runtime in normal workload the systems starts to 
swap (with about 300 to 500 MB of RAM free). Lots of swapping in and 
out, but only very few swap space used (30 to 50 MB). ZFS ARC at that 
point reaches it's minimum (while using up to it's configured maximum 
before). Most of the RAM is wired. L2ARC headers, accourding to 
zfs-stats eat about 1GB, ARC is at 1.8GB at this time. No userland 
processes using lots of RAM.

After some time the system becomes unresponsive, the only way to fix 
this I had found by now is to reboot the machine (which of course gives 
a service interruption).

>From the start of swapping to unresponsiveness I have about 2 to 4 hours 
to check several things (if I just knew what!).

Workload distribution is not even over the day, from my munin graphs I 
can see, that wired grows at time of higher workload. At night with 
lower workload (but far from nothing, let's say about 1/3 to 1/2 in 
writes, but probably <1/4 in reads from weekday workload) I can barely 
see any groth of the wired graph.

So where is my memory going, any ideas what to change?

Kernel is stripped down from GENERIC and then everything I need loaded 
as modules.

Kernel config: http://sysadm.in/zprob/ZSTOR
loader.conf  : http://sysadm.in/zprob/loader.conf
dmesg.boot   : http://sysadm.in/zprob/dmesg.boot


-- 
| Oliver Brandmueller  http://sysadm.in/ o...@sysadm.in |
|Ich bin das Internet. Sowahr ich Gott helfe. |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"