Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots

[Mehmet Erol Sanliturk]

On Mon, Mar 18, 2013 at 3:01 AM, Tom Evans  wrote:

> On Sun, Mar 17, 2013 at 8:26 PM, Mehmet Erol Sanliturk
>  wrote:
> > Dear All ,
> >
> > Previously , in the following message , I have mentioned effect of memory
> > chip placement on execution speed :
> >
> >
> http://lists.freebsd.org/pipermail/freebsd-current/2012-February/031836.html
> > Effect of Processor and Memory on KDE4 execution
> > speed<
> http://lists.freebsd.org/pipermail/freebsd-current/2012-February/031836.html
> >
>
> These seems to be more than different memory slot allocation between
> those two boxes.
>
> Can you reproduce this on the one labelled 'FAST' by assigning memory
> in the same manner as it is assigned in the one labelled 'SLOW'?
>
> >
> >
> > The above thread did not produce any usable result .
> >
> > The problem is persisting over 9.1 and 10.0 current .
> >
> > My opinion is that , it is NOT related to KDE only .
> >
> > After X is started , any desktop is behaving very slowly .
> > This is also visible in PC-BSD and GhostBSD .
>
> This is very nebulous. What is 'very slowly'? Is there a test you can
> run that is independent of X, KDE, etc that demonstrates this?
>
> One thing that KDE does require (iirc - from about 5 years ago,
> probably wrong now) is that since KDE is C++, it spends a lot of time
> loading executables/libraries into memory and prelinking them. If you
> have dramatically lowered your RAM bandwidth, then this stage could
> take a lot longer.
>
> One thing that could cause memory bandwidth to lower is by installing
> mismatched modules. The BIOS will set all RAM up at the same speed,
> the lowest that all of the installed RAM supports. If you fill the RAM
> slots with mismatched modules of different sizes, it may also not
> enable dual channel memory, further reducing the RAM bandwidth.
>
> Because of this, I think it is a jump to go from "My computer runs
> slow when I put these bits of RAM in" to "FreeBSD always runs slow
> when there is mismatched RAM".
>
> If you find out what is slow on FreeBSD - eg RAM bandwidth -  you can
> then test the same thing in Linux. If Linux shows the same slowdown
> from fast to slow, then I'm sorry, that's a hardware defect. If, on
> the other hand, Linux is just as fast in both configurations, then I'm
> sure a lot of people would be interested as to why.
>
> Cheers
>
> Tom
>

I think , all of the answers to your questions may be found in the above
referenced thread messages :

 Every possible combination has been tried , and identified that the
problem is different memory chip sizes for FreeBSD ( v9.0 , v9.1 , v10.0 )
( GhostBSD , PC-BSD , v9.0 , v9.1 ) :

Channel A : Slot 1 : 2 GB
  Slot 2 : 1 GB


Channel B : Slot 1 : 2 GB
  Slot 2 : 1 GB


All of the memory chips : Kingston HyperX , same  clock frequency .
Memory placement kind is correct .

There is NO any hardware defect .

Linux is insensitive to such different memory chip sizes ( I am using
Fedora , CentOS , Mandriva , Mageia , OpenSUSE , Arch Linux , Puppy Linux ,
and some others ... )

Thank you very much .

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

Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots

[Tom Evans]

On Sun, Mar 17, 2013 at 8:26 PM, Mehmet Erol Sanliturk
 wrote:
> Dear All ,
>
> Previously , in the following message , I have mentioned effect of memory
> chip placement on execution speed :
>
> http://lists.freebsd.org/pipermail/freebsd-current/2012-February/031836.html
> Effect of Processor and Memory on KDE4 execution
> speed

These seems to be more than different memory slot allocation between
those two boxes.

Can you reproduce this on the one labelled 'FAST' by assigning memory
in the same manner as it is assigned in the one labelled 'SLOW'?

>
>
> The above thread did not produce any usable result .
>
> The problem is persisting over 9.1 and 10.0 current .
>
> My opinion is that , it is NOT related to KDE only .
>
> After X is started , any desktop is behaving very slowly .
> This is also visible in PC-BSD and GhostBSD .

This is very nebulous. What is 'very slowly'? Is there a test you can
run that is independent of X, KDE, etc that demonstrates this?

One thing that KDE does require (iirc - from about 5 years ago,
probably wrong now) is that since KDE is C++, it spends a lot of time
loading executables/libraries into memory and prelinking them. If you
have dramatically lowered your RAM bandwidth, then this stage could
take a lot longer.

One thing that could cause memory bandwidth to lower is by installing
mismatched modules. The BIOS will set all RAM up at the same speed,
the lowest that all of the installed RAM supports. If you fill the RAM
slots with mismatched modules of different sizes, it may also not
enable dual channel memory, further reducing the RAM bandwidth.

Because of this, I think it is a jump to go from "My computer runs
slow when I put these bits of RAM in" to "FreeBSD always runs slow
when there is mismatched RAM".

If you find out what is slow on FreeBSD - eg RAM bandwidth -  you can
then test the same thing in Linux. If Linux shows the same slowdown
from fast to slow, then I'm sorry, that's a hardware defect. If, on
the other hand, Linux is just as fast in both configurations, then I'm
sure a lot of people would be interested as to why.

Cheers

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

Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots

[Tom Evans]

On Mon, Mar 18, 2013 at 10:30 AM, Mehmet Erol Sanliturk
 wrote:
>
>
> On Mon, Mar 18, 2013 at 3:01 AM, Tom Evans  wrote:
>>
>> On Sun, Mar 17, 2013 at 8:26 PM, Mehmet Erol Sanliturk
>>  wrote:
>> > Dear All ,
>> >
>> > Previously , in the following message , I have mentioned effect of
>> > memory
>> > chip placement on execution speed :
>> >
>> >
>> > http://lists.freebsd.org/pipermail/freebsd-current/2012-February/031836.html
>> > Effect of Processor and Memory on KDE4 execution
>> >
>> > speed
>>
>> These seems to be more than different memory slot allocation between
>> those two boxes.
>>
>> Can you reproduce this on the one labelled 'FAST' by assigning memory
>> in the same manner as it is assigned in the one labelled 'SLOW'?
>>
>> >
>> >
>> > The above thread did not produce any usable result .
>> >
>> > The problem is persisting over 9.1 and 10.0 current .
>> >
>> > My opinion is that , it is NOT related to KDE only .
>> >
>> > After X is started , any desktop is behaving very slowly .
>> > This is also visible in PC-BSD and GhostBSD .
>>
>> This is very nebulous. What is 'very slowly'? Is there a test you can
>> run that is independent of X, KDE, etc that demonstrates this?
>>
>> One thing that KDE does require (iirc - from about 5 years ago,
>> probably wrong now) is that since KDE is C++, it spends a lot of time
>> loading executables/libraries into memory and prelinking them. If you
>> have dramatically lowered your RAM bandwidth, then this stage could
>> take a lot longer.
>>
>> One thing that could cause memory bandwidth to lower is by installing
>> mismatched modules. The BIOS will set all RAM up at the same speed,
>> the lowest that all of the installed RAM supports. If you fill the RAM
>> slots with mismatched modules of different sizes, it may also not
>> enable dual channel memory, further reducing the RAM bandwidth.
>>
>> Because of this, I think it is a jump to go from "My computer runs
>> slow when I put these bits of RAM in" to "FreeBSD always runs slow
>> when there is mismatched RAM".
>>
>> If you find out what is slow on FreeBSD - eg RAM bandwidth -  you can
>> then test the same thing in Linux. If Linux shows the same slowdown
>> from fast to slow, then I'm sorry, that's a hardware defect. If, on
>> the other hand, Linux is just as fast in both configurations, then I'm
>> sure a lot of people would be interested as to why.
>>
>> Cheers
>>
>> Tom
>
>
> I think , all of the answers to your questions may be found in the above
> referenced thread messages :

Nope, you tested 'running KDE' and on different computers found out
that one runs at a different speed than another. You've not done
anything else to determine why or because of what.

You're the one seeing this problem. If you want it fixed, you will
need to do some work to determine what is causing it. All you are
saying now is "When I build this complex combination of hardware and
software, it's slow. Fix my special case".

>
>  Every possible combination has been tried , and identified that the problem
> is different memory chip sizes for FreeBSD ( v9.0 , v9.1 , v10.0 )  (
> GhostBSD , PC-BSD , v9.0 , v9.1 ) :
>
> Channel A : Slot 1 : 2 GB
>   Slot 2 : 1 GB
>
>
> Channel B : Slot 1 : 2 GB
>   Slot 2 : 1 GB
>
>
> All of the memory chips : Kingston HyperX , same  clock frequency .
> Memory placement kind is correct .

You say this, have you actually measured/checked. sysutils/dmidecode
will interrogate your BIOS and tell us what it thinks is installed in
each RAM socket. It is not uncommon for RAM to say one thing on the
outside, and report something completely different to the BIOS.

>
> There is NO any hardware defect .
>
> Linux is insensitive to such different memory chip sizes ( I am using Fedora
> , CentOS , Mandriva , Mageia , OpenSUSE , Arch Linux , Puppy Linux , and
> some others ... )

And you've run the tests which clearly demonstrate this? Or you've
installed KDE, and it's not been 'too slow'?

I'm trying to get you to approach a more scientific approach to this.
Hopefully, this would lead to some actual conclusions and things that
can be improved, rather than "FreeBSD is slow".

You've got a problem when you have mismatched memory, your computer runs slower.
Is the memory running slower?
Test memory bandwidth in both 'fast' and 'slow' configurations. Is
there a difference?
Apparently linux is unaffected.
Test memory bandwidth in both fast and slow configurations on linux.
Is there a difference?

Doing those 4 steps should tell us more about your actual problem, and
might spur an idea in someone. You can use ramspeed to test ram speed
in both linux and freebsd:

http://alasir.com/software/ramspeed/

Problems with your memory modules should produce testable scenarios
that don't involve X and KDE.

Cheers

Tom
___
freebsd-current@freebsd.org mailing list
http://lists.f

Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots

[Poul-Henning Kamp]

In message 
, Tom Evans 
writes:

>You say this, have you actually measured/checked. sysutils/dmidecode
>will interrogate your BIOS and tell us what it thinks is installed in
>each RAM socket. It is not uncommon for RAM to say one thing on the
>outside, and report something completely different to the BIOS.

I can only second Tom's call for a proper scientific approach to 
debugging this issue, rather than just assume that it is the
operating systems fault.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots

[Mehmet Erol Sanliturk]

On Mon, Mar 18, 2013 at 4:54 AM, Poul-Henning Kamp wrote:

> In message  djjmoe5t...@mail.gmail.com>, Tom Evans writes:
>
> >You say this, have you actually measured/checked. sysutils/dmidecode
> >will interrogate your BIOS and tell us what it thinks is installed in
> >each RAM socket. It is not uncommon for RAM to say one thing on the
> >outside, and report something completely different to the BIOS.
>
> I can only second Tom's call for a proper scientific approach to
> debugging this issue, rather than just assume that it is the
> operating systems fault.
>
> --
> Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
> p...@freebsd.org | TCP/IP since RFC 956
> FreeBSD committer   | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>


I am a graduate of Operations Research and Statistics option of a
Mathematics department .
All of your considerations are considered . It is so much apparent that ,
the cause is FreeBSD .

In my previous year message and in its subsequent messages , there are
sufficiently detailed information .


This message is caused from the following fact :

In previous year case , KDE used was a cause , but FluxBox was working fast
.
Now , I have installed 10.0 current . It does not have KDE in packages . I
have installed FluxBox .
It is not a few second slow : Many minutes to start Firefox , and activate
a menu of it  !

What is the point of measuring milliseconds when the difference is around
many minutes ?

PC-BSD installation ( it is a graphical installation after starting X ) is
taking many hours to reach 20 percent completion .
The same is for GhostBSD : Start it at night , at the next morning , it is
likely that it is not finished yet .


Then : WQhat will be measured ?

Linux installations are around 30 minutes .
Starting/Opening menus are instantenous : I do no have chronometer , but
everything is within a second .


Thank you very much .

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

Re: NewNFS vs. oldNFS for 10.0?

[Andre Oppermann]

On 16.03.2013 01:44, Peter Wemm wrote:

On Fri, Mar 15, 2013 at 2:03 PM, John Baldwin  wrote:

On Friday, March 15, 2013 11:24:32 am Andre Oppermann wrote:

On 15.03.2013 14:46, John Baldwin wrote:

On Friday, March 15, 2013 9:40:56 am Andre Oppermann wrote:

Hi Rick, all,

is there a plan to decide for one NFS implementation for FreeBSD 10.0,
or to keep both around indefinately?

I'm talking about:
oldNFS in sys/{nfs, nfsclient, nfsserver} NFSv2+NFSv3
newNFS in sys/fs/{nfs, nfsclient, nfsserver}  NFSv2+NFSv3+NFSv4

NewNFS supports newer NFS standards and seems to have proven itself in
some quite heavy traffic environments.

Is there any reason to keep oldNFS around other than nostalgic?


It can probably be removed.  It's kind of handy to keep around as long as 8.x
is around since it uses oldNFS by default as it makes merging bugfixes to the
NFS client a bit easier (you fix both clients in HEAD and can then just svn
merge both of those to 8 and 9).  Having several fixes to the NFS client
recently and being in a position of still using 8.x with oldNFS in production,
I would prefer to not remove it quite yet.


Do you have a timeframe on the sunset of oldNFS in HEAD so we can communicate
a) that oldNFS won't be in 10.0; and b) it will go on date X?


I thought I implied one above: when 8.x is EOL'd.  However, that has more to do
with developer convience.  It's actually a PITA to use the old NFS client even
on 9.0.


Yes to both.  As somebody who uses oldNFS in production in 9.x, I can
vouch for that.


Sounds like we have a plan.


Personally I'd like to see oldnfs go away from head after a
comfortable dust-settling period 8.4-R and then call it a day.


Since 8.4-R is scheduled for this year(-ish), actually for mid-April,
that would put OldNFS going away around mid to later summer 2013.

Current users of OldNFS on 10-CURRENT should start to test NewNFS and
report any issues they find.  The maintainer of NewNFS is very responsive
and tries hard to fix problems given a sufficient precise problem report.

Users of OldNFS on 9-STABLE should also start to test NewNFS and report
any issues, especially divergent behavior to OldNFS.


Although, please, as part of this please hunt down and s/newnfs/nfs/g
in the process.  This should be done well before 10.x so loose ends
can be tracked down and fixed.


Later summer 2013 fits very well with this and gives about 4 month's of
leading time for a theoretical start of the 10.0 release process.

This seems to be the majority consensus unless someone forcefully objects
on technical grounds and is willing to provide quality input to help
fixing NewNFS regressions.

--
Andre

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

Re: NewNFS vs. oldNFS for 10.0?

[Andre Oppermann]

On 15.03.2013 15:08, Rick Macklem wrote:

Lars Eggert wrote:

Hi,

this reminds me that I ran into an issue lately with the new NFS and
locking for NFSv3 mounts on a client that ran -CURRENT and a server
that ran -STABLE.

When I ran "portmaster -a" on the client, which mounted /usr/ports and
/usr/local, as well as the location of the respective sqlite databases
over NFSv3, the client network stack became unresponsive on all
interfaces for 30 or so seconds and e.g. SSH connections broke. The
serial console remained active throughout, and the system didn't
crash. About a minute after the wedgie I could SSH into the box again,
too.

The issue went away when I killed lockd on the client, but that caused
the sqlite database to become corrupted over time. The workaround for
me was to move to NFSv4, which has been working fine. (One more reason
to make it the default...)


I've mentioned limitations w.r.t. the design of the NLM protocol (rpc.lockd)
before. Any time there is any kind of network topology issue, it will run
into difficulties. There may also be other issues.

However, since both the old and new client use the same rpc.lockd in the
same way (the new one just cribbed the code from the old one), I think
the same problem would exist for the old one. As such, I don't believe
this is a regression.


Maybe we can talk Peter Holm into periodically running his file system
stress test suite against NFS too?  :-)  Peter?

--
Andre

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

Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots

[Nathan Whitehorn]

On 03/18/13 07:18, Mehmet Erol Sanliturk wrote:
> On Mon, Mar 18, 2013 at 4:54 AM, Poul-Henning Kamp wrote:
> 
>> In message > djjmoe5t...@mail.gmail.com>, Tom Evans writes:
>>
>>> You say this, have you actually measured/checked. sysutils/dmidecode
>>> will interrogate your BIOS and tell us what it thinks is installed in
>>> each RAM socket. It is not uncommon for RAM to say one thing on the
>>> outside, and report something completely different to the BIOS.
>>
>> I can only second Tom's call for a proper scientific approach to
>> debugging this issue, rather than just assume that it is the
>> operating systems fault.
>>
>> --
>> Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
>> p...@freebsd.org | TCP/IP since RFC 956
>> FreeBSD committer   | BSD since 4.3-tahoe
>> Never attribute to malice what can adequately be explained by incompetence.
>>
> 
> 
> I am a graduate of Operations Research and Statistics option of a
> Mathematics department .
> All of your considerations are considered . It is so much apparent that ,
> the cause is FreeBSD .
> 
> In my previous year message and in its subsequent messages , there are
> sufficiently detailed information .
> 
> 
> This message is caused from the following fact :
> 
> In previous year case , KDE used was a cause , but FluxBox was working fast
> .
> Now , I have installed 10.0 current . It does not have KDE in packages . I
> have installed FluxBox .
> It is not a few second slow : Many minutes to start Firefox , and activate
> a menu of it  !
> 
> What is the point of measuring milliseconds when the difference is around
> many minutes ?
> 
> PC-BSD installation ( it is a graphical installation after starting X ) is
> taking many hours to reach 20 percent completion .
> The same is for GhostBSD : Start it at night , at the next morning , it is
> likely that it is not finished yet .
> 
> 
> Then : WQhat will be measured ?
> 
> Linux installations are around 30 minutes .
> Starting/Opening menus are instantenous : I do no have chronometer , but
> everything is within a second .
> 
> 
> Thank you very much .

The problem is that "slow" doesn't mean anything. An incomplete list of
things it might be related to:
1. Something to do with the way KDE is built (options, system compiler)
2. A disk I/O issue
3. A memory speed issue
4. Some other process using CPU that isn't running on Linux
5. A scheduler issue triggered by some property of the machine

Doing some of these smaller tests will help pin down which of these are
causing the problem. Without that, there's no possibility to even start
debugging. Even just running top and seeing whether you are spinning in
a user thread, in the kernel, or waiting while the slow things are
happening would be extremely helpful.
-Nathan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots

[Mehmet Erol Sanliturk]

On Mon, Mar 18, 2013 at 6:26 AM, Nathan Whitehorn wrote:

> On 03/18/13 07:18, Mehmet Erol Sanliturk wrote:
> > On Mon, Mar 18, 2013 at 4:54 AM, Poul-Henning Kamp  >wrote:
> >
> >> In message  >> djjmoe5t...@mail.gmail.com>, Tom Evans writes:
> >>
> >>> You say this, have you actually measured/checked. sysutils/dmidecode
> >>> will interrogate your BIOS and tell us what it thinks is installed in
> >>> each RAM socket. It is not uncommon for RAM to say one thing on the
> >>> outside, and report something completely different to the BIOS.
> >>
> >> I can only second Tom's call for a proper scientific approach to
> >> debugging this issue, rather than just assume that it is the
> >> operating systems fault.
> >>
> >> --
> >> Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
> >> p...@freebsd.org | TCP/IP since RFC 956
> >> FreeBSD committer   | BSD since 4.3-tahoe
> >> Never attribute to malice what can adequately be explained by
> incompetence.
> >>
> >
> >
> > I am a graduate of Operations Research and Statistics option of a
> > Mathematics department .
> > All of your considerations are considered . It is so much apparent that ,
> > the cause is FreeBSD .
> >
> > In my previous year message and in its subsequent messages , there are
> > sufficiently detailed information .
> >
> >
> > This message is caused from the following fact :
> >
> > In previous year case , KDE used was a cause , but FluxBox was working
> fast
> > .
> > Now , I have installed 10.0 current . It does not have KDE in packages .
> I
> > have installed FluxBox .
> > It is not a few second slow : Many minutes to start Firefox , and
> activate
> > a menu of it  !
> >
> > What is the point of measuring milliseconds when the difference is around
> > many minutes ?
> >
> > PC-BSD installation ( it is a graphical installation after starting X )
> is
> > taking many hours to reach 20 percent completion .
> > The same is for GhostBSD : Start it at night , at the next morning , it
> is
> > likely that it is not finished yet .
> >
> >
> > Then : WQhat will be measured ?
> >
> > Linux installations are around 30 minutes .
> > Starting/Opening menus are instantenous : I do no have chronometer , but
> > everything is within a second .
> >
> >
> > Thank you very much .
>
> The problem is that "slow" doesn't mean anything. An incomplete list of
> things it might be related to:
> 1. Something to do with the way KDE is built (options, system compiler)
> 2. A disk I/O issue
> 3. A memory speed issue
> 4. Some other process using CPU that isn't running on Linux
> 5. A scheduler issue triggered by some property of the machine
>
> Doing some of these smaller tests will help pin down which of these are
> causing the problem. Without that, there's no possibility to even start
> debugging. Even just running top and seeing whether you are spinning in
> a user thread, in the kernel, or waiting while the slow things are
> happening would be extremely helpful.
> -Nathan
> ___
>
>
In the following messages , there are some values for possible combinations
on two identical main boards with 2 and 4 core processors :

http://lists.freebsd.org/pipermail/freebsd-current/2012-February/031836.html
http://lists.freebsd.org/pipermail/freebsd-current/2012-February/031912.html
http://lists.freebsd.org/pipermail/freebsd-current/2012-February/031928.html
http://lists.freebsd.org/pipermail/freebsd-current/2012-February/032012.html

FreeBSD 9.1 Stable ( 2013-03-09 )


top in console mode :

Load averages : 0.22 0.53 0.28
33 processes , 1 running , 32 sleeping

CPU  : 1.5 ... 3.5 % user
 0.0 % nice
   0.6 .. 1.5 % system
   0.0 ... 0.4 interrupt
   ~ 0.95 % idle


top in X + FluxBox :


Load averages : 0.22 0.53 0.28

xterm ( top )
xterm ( Firefox )


44 processes , 1 running , 43 sleeping

CPU  : 1.5 ... 3.5 % user
 0.0 % nice
   0.0 .. 1.5 % system
   0.0 ... 0.4 interrupt
   ~ 0.96 % idle

When there is no user activity : Sometimes  % user is increasing , % idle
decreasing .
When anything clicked in Firefox % user increasing , % idle decreasing .

Response is slow ( to open a menu sometimes reaching to minute ) .
Closing a menu is taking many seconds .

Thank you very much .


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

Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots

[Mehmet Erol Sanliturk]

On Mon, Mar 18, 2013 at 6:26 AM, Nathan Whitehorn wrote:

> On 03/18/13 07:18, Mehmet Erol Sanliturk wrote:
> > On Mon, Mar 18, 2013 at 4:54 AM, Poul-Henning Kamp  >wrote:
> >
> >> In message  >> djjmoe5t...@mail.gmail.com>, Tom Evans writes:
> >>
> >>> You say this, have you actually measured/checked. sysutils/dmidecode
> >>> will interrogate your BIOS and tell us what it thinks is installed in
> >>> each RAM socket. It is not uncommon for RAM to say one thing on the
> >>> outside, and report something completely different to the BIOS.
> >>
> >> I can only second Tom's call for a proper scientific approach to
> >> debugging this issue, rather than just assume that it is the
> >> operating systems fault.
> >>
> >> --
> >> Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
> >> p...@freebsd.org | TCP/IP since RFC 956
> >> FreeBSD committer   | BSD since 4.3-tahoe
> >> Never attribute to malice what can adequately be explained by
> incompetence.
> >>
> >
> >
> > I am a graduate of Operations Research and Statistics option of a
> > Mathematics department .
> > All of your considerations are considered . It is so much apparent that ,
> > the cause is FreeBSD .
> >
> > In my previous year message and in its subsequent messages , there are
> > sufficiently detailed information .
> >
> >
> > This message is caused from the following fact :
> >
> > In previous year case , KDE used was a cause , but FluxBox was working
> fast
> > .
> > Now , I have installed 10.0 current . It does not have KDE in packages .
> I
> > have installed FluxBox .
> > It is not a few second slow : Many minutes to start Firefox , and
> activate
> > a menu of it  !
> >
> > What is the point of measuring milliseconds when the difference is around
> > many minutes ?
> >
> > PC-BSD installation ( it is a graphical installation after starting X )
> is
> > taking many hours to reach 20 percent completion .
> > The same is for GhostBSD : Start it at night , at the next morning , it
> is
> > likely that it is not finished yet .
> >
> >
> > Then : WQhat will be measured ?
> >
> > Linux installations are around 30 minutes .
> > Starting/Opening menus are instantenous : I do no have chronometer , but
> > everything is within a second .
> >
> >
> > Thank you very much .
>
> The problem is that "slow" doesn't mean anything. An incomplete list of
> things it might be related to:
> 1. Something to do with the way KDE is built (options, system compiler)
> 2. A disk I/O issue
> 3. A memory speed issue
> 4. Some other process using CPU that isn't running on Linux
> 5. A scheduler issue triggered by some property of the machine
>
> Doing some of these smaller tests will help pin down which of these are
> causing the problem. Without that, there's no possibility to even start
> debugging. Even just running top and seeing whether you are spinning in
> a user thread, in the kernel, or waiting while the slow things are
> happening would be extremely helpful.
> -Nathan
> ___
>  
>


The dmidecode output is attached .

Thank you very much .

Mehmet Erol Sanliturk
# dmidecode 2.11
SMBIOS 2.4 present.
39 structures occupying 1794 bytes.
Table at 0x000E32F0.

Handle 0x, DMI type 4, 35 bytes
Processor Information
Socket Designation: LGA 775
Type: Central Processor
Family: Pentium D
Manufacturer: Intel(R) Corporation
ID: FD 06 00 00 FF FB EB BF
Signature: Type 0, Family 6, Model 15, Stepping 13
Flags:
FPU (Floating-point unit on-chip)
VME (Virtual mode extension)
DE (Debugging extension)
PSE (Page size extension)
TSC (Time stamp counter)
MSR (Model specific registers)
PAE (Physical address extension)
MCE (Machine check exception)
CX8 (CMPXCHG8 instruction supported)
APIC (On-chip APIC hardware supported)
SEP (Fast system call)
MTRR (Memory type range registers)
PGE (Page global enable)
MCA (Machine check architecture)
CMOV (Conditional move instruction supported)
PAT (Page attribute table)
PSE-36 (36-bit page size extension)
CLFSH (CLFLUSH instruction supported)
DS (Debug store)
ACPI (ACPI supported)
MMX (MMX technology supported)
FXSR (FXSAVE and FXSTOR instructions supported)
SSE (Streaming SIMD extensions)
SSE2 (Streaming SIMD extensions 2)
SS (Self-snoop)
HTT (Multi-threading)
TM (Thermal monitor supported)
PBE (Pending break enabled)
Version: Intel(R) Pentium(R) Dual  CPU  E2220  @ 2.40GHz
Voltage: 1.6 V
External Clock: 200 MHz
Max Speed: 4000 MHz
Current Speed: 2400 MHz

Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots

[Steven Hartland]

- Original Message - 
From: "Nathan Whitehorn" 

To: 
Sent: Monday, March 18, 2013 1:26 PM
Subject: Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots



On 03/18/13 07:18, Mehmet Erol Sanliturk wrote:

On Mon, Mar 18, 2013 at 4:54 AM, Poul-Henning Kamp wrote:


In message , Tom Evans writes:


You say this, have you actually measured/checked. sysutils/dmidecode
will interrogate your BIOS and tell us what it thinks is installed in
each RAM socket. It is not uncommon for RAM to say one thing on the
outside, and report something completely different to the BIOS.


I can only second Tom's call for a proper scientific approach to
debugging this issue, rather than just assume that it is the
operating systems fault.

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.




I am a graduate of Operations Research and Statistics option of a
Mathematics department .
All of your considerations are considered . It is so much apparent that ,
the cause is FreeBSD .

In my previous year message and in its subsequent messages , there are
sufficiently detailed information .


This message is caused from the following fact :

In previous year case , KDE used was a cause , but FluxBox was working fast
.
Now , I have installed 10.0 current . It does not have KDE in packages . I
have installed FluxBox .
It is not a few second slow : Many minutes to start Firefox , and activate
a menu of it  !

What is the point of measuring milliseconds when the difference is around
many minutes ?

PC-BSD installation ( it is a graphical installation after starting X ) is
taking many hours to reach 20 percent completion .
The same is for GhostBSD : Start it at night , at the next morning , it is
likely that it is not finished yet .


Then : WQhat will be measured ?

Linux installations are around 30 minutes .
Starting/Opening menus are instantenous : I do no have chronometer , but
everything is within a second .


Thank you very much .


The problem is that "slow" doesn't mean anything. An incomplete list of
things it might be related to:
1. Something to do with the way KDE is built (options, system compiler)
2. A disk I/O issue
3. A memory speed issue
4. Some other process using CPU that isn't running on Linux
5. A scheduler issue triggered by some property of the machine

Doing some of these smaller tests will help pin down which of these are
causing the problem. Without that, there's no possibility to even start
debugging. Even just running top and seeing whether you are spinning in
a user thread, in the kernel, or waiting while the slow things are
happening would be extremely helpful.


Surely you can eliminate all of those and confirm / deny the original
diagnosis by simply installing balanced memory in the machine and checking
to see if the problem goes away?

Could this be an NUMA related issue?

   Regards
   Steve


This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 


In the event of misdirection, illegible or incomplete transmission please 
telephone +44 845 868 1337
or return the E.mail to postmas...@multiplay.co.uk.

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

[head tinderbox] failure on arm/arm

[FreeBSD Tinderbox]

TB --- 2013-03-18 13:20:17 - tinderbox 2.10 running on freebsd-current.sentex.ca
TB --- 2013-03-18 13:20:17 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE 
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2013-03-18 13:20:17 - starting HEAD tinderbox run for arm/arm
TB --- 2013-03-18 13:20:17 - cleaning the object tree
TB --- 2013-03-18 13:20:17 - /usr/local/bin/svn stat /src
TB --- 2013-03-18 13:20:21 - At svn revision 248465
TB --- 2013-03-18 13:20:22 - building world
TB --- 2013-03-18 13:20:22 - CROSS_BUILD_TESTING=YES
TB --- 2013-03-18 13:20:22 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-03-18 13:20:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-03-18 13:20:22 - SRCCONF=/dev/null
TB --- 2013-03-18 13:20:22 - TARGET=arm
TB --- 2013-03-18 13:20:22 - TARGET_ARCH=arm
TB --- 2013-03-18 13:20:22 - TZ=UTC
TB --- 2013-03-18 13:20:22 - __MAKE_CONF=/dev/null
TB --- 2013-03-18 13:20:22 - cd /src
TB --- 2013-03-18 13:20:22 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Mon Mar 18 13:20:27 UTC 2013
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
[...]
cc -O -pipe  -DBFD_DEFAULT_TARGET_SIZE=32 -I. -I/src/gnu/usr.bin/binutils/as 
-I/src/gnu/usr.bin/binutils/as/../libbfd 
-I/obj/arm.arm/src/gnu/usr.bin/binutils/as/../libbfd 
-I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/include 
-DDEFAULT_ARCH=\"arm\" -DTARGET_CPU=\"arm\" -DTARGET_OS=\"freebsd\" 
-DTARGET_CANONICAL=\"arm-unknown-freebsd\" 
-DTARGET_ALIAS=\"arm-unknown-freebsd\" -DVERSION=\""2.17.50 [FreeBSD] 
2007-07-03"\" -D_GNU_SOURCE 
-I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas 
-I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/bfd 
-I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/config 
-I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils 
-I/src/gnu/usr.bin/binutils/as -I/src/gnu/usr.bin/binutils/as/arm-freebsd 
-std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W 
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith 
-Wno-uninitialized -Wno-pointer-sign -c /src/gnu/usr.bin/binutils/as!
 /../../../../contrib/binutils/gas/symbols.c
cc -O -pipe  -DBFD_DEFAULT_TARGET_SIZE=32 -I. -I/src/gnu/usr.bin/binutils/as 
-I/src/gnu/usr.bin/binutils/as/../libbfd 
-I/obj/arm.arm/src/gnu/usr.bin/binutils/as/../libbfd 
-I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/include 
-DDEFAULT_ARCH=\"arm\" -DTARGET_CPU=\"arm\" -DTARGET_OS=\"freebsd\" 
-DTARGET_CANONICAL=\"arm-unknown-freebsd\" 
-DTARGET_ALIAS=\"arm-unknown-freebsd\" -DVERSION=\""2.17.50 [FreeBSD] 
2007-07-03"\" -D_GNU_SOURCE 
-I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas 
-I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/bfd 
-I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/config 
-I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils 
-I/src/gnu/usr.bin/binutils/as -I/src/gnu/usr.bin/binutils/as/arm-freebsd 
-std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W 
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith 
-Wno-uninitialized -Wno-pointer-sign -c /src/gnu/usr.bin/binutils/as!
 /../../../../contrib/binutils/gas/write.c
cc -O -pipe  -DBFD_DEFAULT_TARGET_SIZE=32 -I. -I/src/gnu/usr.bin/binutils/as 
-I/src/gnu/usr.bin/binutils/as/../libbfd 
-I/obj/arm.arm/src/gnu/usr.bin/binutils/as/../libbfd 
-I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/include 
-DDEFAULT_ARCH=\"arm\" -DTARGET_CPU=\"arm\" -DTARGET_OS=\"freebsd\" 
-DTARGET_CANONICAL=\"arm-unknown-freebsd\" 
-DTARGET_ALIAS=\"arm-unknown-freebsd\" -DVERSION=\""2.17.50 [FreeBSD] 
2007-07-03"\" -D_GNU_SOURCE 
-I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas 
-I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/bfd 
-I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/config 
-I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils 
-I/src/gnu/usr.bin/binutils/as -I/src/gnu/usr.bin/binutils/as/arm-freebsd 
-std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W 
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith 
-Wno-uninitialized -Wno-pointer-sign -c /src/gnu/usr.bin/binutils/as!
 /../../../../contrib/binutils/gas/config/tc-arm.c
cc1: warnings being treated as errors
/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/config/tc-arm.c:15793:
 warning: initialization from incompatible pointer type
/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/config/tc-arm.c:15793:
 warning: initialization from incompatible

[head tinderbox] failure on armv6/arm

[FreeBSD Tinderbox]

TB --- 2013-03-18 13:20:17 - tinderbox 2.10 running on freebsd-current.sentex.ca
TB --- 2013-03-18 13:20:17 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE 
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2013-03-18 13:20:17 - starting HEAD tinderbox run for armv6/arm
TB --- 2013-03-18 13:20:17 - cleaning the object tree
TB --- 2013-03-18 13:20:17 - /usr/local/bin/svn stat /src
TB --- 2013-03-18 13:20:21 - At svn revision 248465
TB --- 2013-03-18 13:20:22 - building world
TB --- 2013-03-18 13:20:22 - CROSS_BUILD_TESTING=YES
TB --- 2013-03-18 13:20:22 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-03-18 13:20:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-03-18 13:20:22 - SRCCONF=/dev/null
TB --- 2013-03-18 13:20:22 - TARGET=arm
TB --- 2013-03-18 13:20:22 - TARGET_ARCH=armv6
TB --- 2013-03-18 13:20:22 - TZ=UTC
TB --- 2013-03-18 13:20:22 - __MAKE_CONF=/dev/null
TB --- 2013-03-18 13:20:22 - cd /src
TB --- 2013-03-18 13:20:22 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Mon Mar 18 13:20:27 UTC 2013
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
[...]
cc -O -pipe  -DBFD_DEFAULT_TARGET_SIZE=32 -I. -I/src/gnu/usr.bin/binutils/as 
-I/src/gnu/usr.bin/binutils/as/../libbfd 
-I/obj/arm.armv6/src/gnu/usr.bin/binutils/as/../libbfd 
-I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/include 
-DCPU_DEFAULT=ARM_ARCH_V6K -DDEFAULT_ARCH=\"armv6\" -DTARGET_CPU=\"armv6\" 
-DTARGET_OS=\"freebsd\" -DTARGET_CANONICAL=\"armv6-unknown-freebsd\" 
-DTARGET_ALIAS=\"armv6-unknown-freebsd\" -DVERSION=\""2.17.50 [FreeBSD] 
2007-07-03"\" -D_GNU_SOURCE 
-I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas 
-I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/bfd 
-I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/config 
-I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils 
-I/src/gnu/usr.bin/binutils/as -I/src/gnu/usr.bin/binutils/as/arm-freebsd 
-std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W 
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith 
-Wno-uninitialized -Wno-pointer!
 -sign -c 
/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/symbols.c
cc -O -pipe  -DBFD_DEFAULT_TARGET_SIZE=32 -I. -I/src/gnu/usr.bin/binutils/as 
-I/src/gnu/usr.bin/binutils/as/../libbfd 
-I/obj/arm.armv6/src/gnu/usr.bin/binutils/as/../libbfd 
-I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/include 
-DCPU_DEFAULT=ARM_ARCH_V6K -DDEFAULT_ARCH=\"armv6\" -DTARGET_CPU=\"armv6\" 
-DTARGET_OS=\"freebsd\" -DTARGET_CANONICAL=\"armv6-unknown-freebsd\" 
-DTARGET_ALIAS=\"armv6-unknown-freebsd\" -DVERSION=\""2.17.50 [FreeBSD] 
2007-07-03"\" -D_GNU_SOURCE 
-I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas 
-I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/bfd 
-I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/config 
-I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils 
-I/src/gnu/usr.bin/binutils/as -I/src/gnu/usr.bin/binutils/as/arm-freebsd 
-std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W 
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith 
-Wno-uninitialized -Wno-pointer!
 -sign -c /src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/write.c
cc -O -pipe  -DBFD_DEFAULT_TARGET_SIZE=32 -I. -I/src/gnu/usr.bin/binutils/as 
-I/src/gnu/usr.bin/binutils/as/../libbfd 
-I/obj/arm.armv6/src/gnu/usr.bin/binutils/as/../libbfd 
-I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/include 
-DCPU_DEFAULT=ARM_ARCH_V6K -DDEFAULT_ARCH=\"armv6\" -DTARGET_CPU=\"armv6\" 
-DTARGET_OS=\"freebsd\" -DTARGET_CANONICAL=\"armv6-unknown-freebsd\" 
-DTARGET_ALIAS=\"armv6-unknown-freebsd\" -DVERSION=\""2.17.50 [FreeBSD] 
2007-07-03"\" -D_GNU_SOURCE 
-I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas 
-I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/bfd 
-I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/config 
-I/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils 
-I/src/gnu/usr.bin/binutils/as -I/src/gnu/usr.bin/binutils/as/arm-freebsd 
-std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W 
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith 
-Wno-uninitialized -Wno-pointer!
 -sign -c 
/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/config/tc-arm.c
cc1: warnings being treated as errors
/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/config/tc-arm.c:15793:
 warning: initialization from incompatible pointer type
/src/gnu/u

Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots

[Mehmet Erol Sanliturk]

On Mon, Mar 18, 2013 at 7:47 AM, Steven Hartland wrote:

>
> - Original Message - From: "Nathan Whitehorn" <
> nwhiteh...@freebsd.org>
> To: 
> Sent: Monday, March 18, 2013 1:26 PM
> Subject: Re: FreeBSD is very slow when Memory chip sizes are imbalanced in
> slots
>
>
>  On 03/18/13 07:18, Mehmet Erol Sanliturk wrote:
>>
>>> On Mon, Mar 18, 2013 at 4:54 AM, Poul-Henning Kamp >> >wrote:
>>>
>>>  In message >>> djjmoe5t...@mail.gmail.com>, Tom Evans writes:

  You say this, have you actually measured/checked. sysutils/dmidecode
> will interrogate your BIOS and tell us what it thinks is installed in
> each RAM socket. It is not uncommon for RAM to say one thing on the
> outside, and report something completely different to the BIOS.
>

 I can only second Tom's call for a proper scientific approach to
 debugging this issue, rather than just assume that it is the
 operating systems fault.

 --
 Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
 p...@freebsd.org | TCP/IP since RFC 956
 FreeBSD committer   | BSD since 4.3-tahoe
 Never attribute to malice what can adequately be explained by
 incompetence.


>>>
>>> I am a graduate of Operations Research and Statistics option of a
>>> Mathematics department .
>>> All of your considerations are considered . It is so much apparent that ,
>>> the cause is FreeBSD .
>>>
>>> In my previous year message and in its subsequent messages , there are
>>> sufficiently detailed information .
>>>
>>>
>>> This message is caused from the following fact :
>>>
>>> In previous year case , KDE used was a cause , but FluxBox was working
>>> fast
>>> .
>>> Now , I have installed 10.0 current . It does not have KDE in packages .
>>> I
>>> have installed FluxBox .
>>> It is not a few second slow : Many minutes to start Firefox , and
>>> activate
>>> a menu of it  !
>>>
>>> What is the point of measuring milliseconds when the difference is around
>>> many minutes ?
>>>
>>> PC-BSD installation ( it is a graphical installation after starting X )
>>> is
>>> taking many hours to reach 20 percent completion .
>>> The same is for GhostBSD : Start it at night , at the next morning , it
>>> is
>>> likely that it is not finished yet .
>>>
>>>
>>> Then : WQhat will be measured ?
>>>
>>> Linux installations are around 30 minutes .
>>> Starting/Opening menus are instantenous : I do no have chronometer , but
>>> everything is within a second .
>>>
>>>
>>> Thank you very much .
>>>
>>
>> The problem is that "slow" doesn't mean anything. An incomplete list of
>> things it might be related to:
>> 1. Something to do with the way KDE is built (options, system compiler)
>> 2. A disk I/O issue
>> 3. A memory speed issue
>> 4. Some other process using CPU that isn't running on Linux
>> 5. A scheduler issue triggered by some property of the machine
>>
>> Doing some of these smaller tests will help pin down which of these are
>> causing the problem. Without that, there's no possibility to even start
>> debugging. Even just running top and seeing whether you are spinning in
>> a user thread, in the kernel, or waiting while the slow things are
>> happening would be extremely helpful.
>>
>
> Surely you can eliminate all of those and confirm / deny the original
> diagnosis by simply installing balanced memory in the machine and checking
> to see if the problem goes away?
>
> Could this be an NUMA related issue?
>
>Regards
>Steve
>
>
Please see links in my previous mails .
All of these are worked in detail .

This is Intel DG965WH main board and I do not know much about NUMA , but
with respect to Wikipedia Non-Uniform_Memory_Access  page , it seems that
there is no NUMA structure in this main board .

Thank you very much .

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

Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots

[Steven Hartland]

- Original Message - 
From: Mehmet Erol Sanliturk 

Surely you can eliminate all of those and confirm / deny the original
diagnosis by simply installing balanced memory in the machine and checking
to see if the problem goes away?


Please see links in my previous mails .
All of these are worked in detail .

This is Intel DG965WH main board and I do not know much about NUMA , but
with respect to Wikipedia Non-Uniform_Memory_Access  page , it seems that
there is no NUMA structure in this main board .


But have you installed balanced memory and confirmed the problem goes away?

   Regards
   Steve


This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 


In the event of misdirection, illegible or incomplete transmission please 
telephone +44 845 868 1337
or return the E.mail to postmas...@multiplay.co.uk.

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

Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots

[Mehmet Erol Sanliturk]

On Mon, Mar 18, 2013 at 8:09 AM, Steven Hartland wrote:

>
> - Original Message - From: Mehmet Erol Sanliturk
>
>> Surely you can eliminate all of those and confirm / deny the original
>>> diagnosis by simply installing balanced memory in the machine and
>>> checking
>>> to see if the problem goes away?
>>>
>>
>> Please see links in my previous mails .
>> All of these are worked in detail .
>>
>> This is Intel DG965WH main board and I do not know much about NUMA , but
>> with respect to Wikipedia Non-Uniform_Memory_Access  page , it seems that
>> there is no NUMA structure in this main board .
>>
>
> But have you installed balanced memory and confirmed the problem goes away?
>
>Regards
>Steve
>



Yes .


http://lists.freebsd.org/pipermail/freebsd-current/2012-February/031836.html
http://lists.freebsd.org/pipermail/freebsd-current/2012-February/031912.html
http://lists.freebsd.org/pipermail/freebsd-current/2012-February/031928.html
http://lists.freebsd.org/pipermail/freebsd-current/2012-February/032012.html


Thank you very much .

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

Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots

[Steven Hartland]

>> - Original Message - From: Mehmet Erol Sanliturk
>>>
>>> Surely you can eliminate all of those and confirm / deny the original
 diagnosis by simply installing balanced memory in the machine and
 checking
 to see if the problem goes away?

>>>
>>> Please see links in my previous mails .
>>> All of these are worked in detail .
>>>
>>> This is Intel DG965WH main board and I do not know much about NUMA , but
>>> with respect to Wikipedia Non-Uniform_Memory_Access  page , it seems that
>>> there is no NUMA structure in this main board .
>>>
>>
>> But have you installed balanced memory and confirmed the problem goes away?
>
> Yes .
>
>
> http://lists.freebsd.org/pipermail/freebsd-current/2012-February/031836.html
> http://lists.freebsd.org/pipermail/freebsd-current/2012-February/031912.html
> http://lists.freebsd.org/pipermail/freebsd-current/2012-February/031928.html
> http://lists.freebsd.org/pipermail/freebsd-current/2012-February/032012.html
>

You state there that "The main boards are the same" which indicates to me
the machines aren't the same machine which could result in some other subtle
difference causing the problem.

To confirm you'll need to use the "exact same machine" for tests with the only
difference being the ram modules installed.

Regards
Steve


This e.mail is private and confidential between Multiplay (UK) Ltd. and the 
person or entity to whom it is addressed. In the event of misdirection, the 
recipient is prohibited from using, copying, printing or otherwise 
disseminating it or any information contained in it. 

In the event of misdirection, illegible or incomplete transmission please 
telephone +44 845 868 1337
or return the E.mail to postmas...@multiplay.co.uk.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots

[Poul-Henning Kamp]

In message , "Steven 
Hartland" writes:

>You state there that "The main boards are the same" which indicates to me
>the machines aren't the same machine which could result in some other subtle
>difference causing the problem.
>
>To confirm you'll need to use the "exact same machine" for tests with the only
>difference being the ram modules installed.

Or, at the very least, switch _all_ the RAM between the two machines, and 
confirm
that the problem follows the RAM.


-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots

[Mehmet Erol Sanliturk]

On Mon, Mar 18, 2013 at 8:26 AM, Poul-Henning Kamp wrote:

> In message , "Steven
> Hartland" writes:
>
> >You state there that "The main boards are the same" which indicates to me
> >the machines aren't the same machine which could result in some other
> subtle
> >difference causing the problem.
> >
> >To confirm you'll need to use the "exact same machine" for tests with the
> only
> >difference being the ram modules installed.
>
> Or, at the very least, switch _all_ the RAM between the two machines, and
> confirm
> that the problem follows the RAM.
>
>
> --
> Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
> p...@freebsd.org | TCP/IP since RFC 956
> FreeBSD committer   | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>


Yes .



http://lists.freebsd.org/pipermail/freebsd-current/2012-February/031836.html
http://lists.freebsd.org/pipermail/freebsd-current/2012-February/031912.html
http://lists.freebsd.org/pipermail/freebsd-current/2012-February/031928.html
http://lists.freebsd.org/pipermail/freebsd-current/2012-February/032012.html


Thank you very much .

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

Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots

[Mehmet Erol Sanliturk]

On Mon, Mar 18, 2013 at 8:21 AM, Steven Hartland wrote:

> **
> >> - Original Message - From: Mehmet Erol Sanliturk
> >>>
> >>> Surely you can eliminate all of those and confirm / deny the original
>  diagnosis by simply installing balanced memory in the machine and
>  checking
>  to see if the problem goes away?
> 
> >>>
> >>> Please see links in my previous mails .
> >>> All of these are worked in detail .
> >>>
> >>> This is Intel DG965WH main board and I do not know much about NUMA ,
> but
> >>> with respect to Wikipedia Non-Uniform_Memory_Access  page , it seems
> that
> >>> there is no NUMA structure in this main board .
> >>>
> >>
> >> But have you installed balanced memory and confirmed the problem goes
> away?
> >
> > Yes .
> >
> >
> >
> http://lists.freebsd.org/pipermail/freebsd-current/2012-February/031836.html
> >
> http://lists.freebsd.org/pipermail/freebsd-current/2012-February/031912.html
> >
> http://lists.freebsd.org/pipermail/freebsd-current/2012-February/031928.html
> >
> http://lists.freebsd.org/pipermail/freebsd-current/2012-February/032012.html
> >
>
> You state there that "The main boards are the same" which indicates to me
> the machines aren't the same machine which could result in some other
> subtle
> difference causing the problem.
>
> To confirm you'll need to use the "exact same machine" for tests with the
> only
> difference being the ram modules installed.
> Regards
> Steve
>
>

The main boards are the same model , two of them in two different cases ,
not one main board .

Thank you very much .

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

Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots

[Steven Hartland]

- Original Message - 
From: "Mehmet Erol Sanliturk" 



You state there that "The main boards are the same" which indicates to me
the machines aren't the same machine which could result in some other
subtle
difference causing the problem.

To confirm you'll need to use the "exact same machine" for tests with the
only difference being the ram modules installed.


The main boards are the same model , two of them in two different cases ,
not one main board .


That doesn't mean that both machines are configured / installed identically
you need to rule out other differences before continuing.

   Regards
   Steve


This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 


In the event of misdirection, illegible or incomplete transmission please 
telephone +44 845 868 1337
or return the E.mail to postmas...@multiplay.co.uk.

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

Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots

[Mehmet Erol Sanliturk]

On Mon, Mar 18, 2013 at 8:41 AM, Steven Hartland wrote:

>
> - Original Message - From: "Mehmet Erol Sanliturk" <
> m.e.sanlit...@gmail.com>
>
>  You state there that "The main boards are the same" which indicates to me
>>> the machines aren't the same machine which could result in some other
>>> subtle
>>> difference causing the problem.
>>>
>>> To confirm you'll need to use the "exact same machine" for tests with the
>>> only difference being the ram modules installed.
>>>
>>
>> The main boards are the same model , two of them in two different cases ,
>> not one main board .
>>
>
> That doesn't mean that both machines are configured / installed identically
> you need to rule out other differences before continuing.
>
>Regards
>Steve
>
>

Important ( determiner ) parameters are ( FreeBSD ( 9.0 , 9.1 , 10.0 : any
of them with X + Desktop ( FluxBox , KDE , Gnome , I never used any other
one , except one time I have tried Enlightenment , but not for this case  )
, Memory Chip Sizes ) .

Assume :

Computer A : Memory Chip Sizes : ( 2 GB , 1 GB , 2 GB , 1 GB ) : Working
SLOW . FreeBSD A
Computer B  : Memory Chip Sizes : ( 2 GB , 2 GB , 2 GB , 2 GB ) : Working
FAST . FreeBSD B

Interchange memory chips :

Computer A : Memory Chip Sizes : ( 2 GB , 2 GB , 2 GB , 2 GB ) : Working
FAST . FreeBSD A
Computer B  : Memory Chip Sizes : ( 2 GB , 1 GB , 2 GB , 1 GB ) : Working
SLOW . FreeBSD B


Then : Interchanging only memory chips is interchanging also the SPEED .
Means : FreeBSD installation is NOT important ( or effective ) .

Thank you very much .

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

Re: troubles with buildworld/sendmail/sasl/clang

[Kimmo Paasiala]

On Mon, Mar 18, 2013 at 1:03 PM, Beat Siegenthaler
 wrote:
> Hi all,
>
> since some days i try to "make buildworld", but have some errors in
> sendmail.
> The make conf is not changed since years (in this case) . Adding
> NO_WERROR= in src.conf helps, but i think it is not the optimal solution?
>
> # SASL (cyrus-sasl v2) sendmail build flags...
> SENDMAIL_CFLAGS+=-I/usr/local/include -DSASL=2
> SENDMAIL_LDFLAGS+=-L/usr/local/lib
> SENDMAIL_LDADD+=-lsasl2
> SENDMAIL_CFLAGS+= -D_FFR_SMTP_SSL
>
> SENDMAIL_MC = /etc/mail/xyz.mc
> WITH_SSL_AND_PLAINTEXT=yes # for imaps and cclient
>
> ==src.conf===
>
> CC=clang
> CXX=clang++
> CPP=clang-cpp
> # This setting to build world without -Werror:
> # NO_WERROR=
> # This setting to build kernel without -Werror:
> # WERROR=
>
> =buildworld===
>
> /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/usersmtp.c:1864:8:
> error: incompatible pointer types passing 'void ()' to parameter of type
> 'void (*)(char *, bool, MAILER *, struct mailer_con_info *, ENVELOPE *)'
> [-Werror,-Wincompatible-pointer-types]
>getsasldata, NULL, XS_AUTH);
>^~~
> /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/sendmail.h:2519:67: 
> note:
> passing argument to parameter here
> extern int  reply __P((MAILER *, MCI *, ENVELOPE *, time_t, void
> (*)__P((char *, bool, MAILER *, MCI *, ENVELOPE *)), char **, int));
>^
> /usr/obj/usr/src/tmp/usr/include/sys/cdefs.h:129:21: note: expanded from
> macro '__P'
> #define __P(protos) protos  /* full-blown ANSI C */
> ^
> 3 errors generated.
> *** [usersmtp.o] Error code 1
> 1 error
> *** [all] Error code 2
> 1 error
> *** [usr.sbin.all__D] Error code 2
> 1 error
> *** [everything] Error code 2
> 1 error
> *** [buildworld] Error code 2
> 1 error
>
> regards
> beat


I can not help with the error but I really have to make this question:
Does FreeBSD really have to support pre-ANSI C compilers in 2013?

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

Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots

[Scot Hetzel]

On Mon, Mar 18, 2013 at 11:06 AM, Mehmet Erol Sanliturk
 wrote:
> Computer A : Memory Chip Sizes : ( 2 GB , 1 GB , 2 GB , 1 GB ) : Working
> SLOW . FreeBSD A
> Computer B  : Memory Chip Sizes : ( 2 GB , 2 GB , 2 GB , 2 GB ) : Working
> FAST . FreeBSD B
>
> Interchange memory chips :
>
> Computer A : Memory Chip Sizes : ( 2 GB , 2 GB , 2 GB , 2 GB ) : Working
> FAST . FreeBSD A
> Computer B  : Memory Chip Sizes : ( 2 GB , 1 GB , 2 GB , 1 GB ) : Working
> SLOW . FreeBSD B
>
>

What happens if you configure the memory as ( 2 GB , 2 GB , 1 GB , 1 GB )?

-- 
DISCLAIMER:

No electrons were maimed while sending this message. Only slightly bruised.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Handbook Jail Chapter rewrite available for critique

[Fbsd8]

To all interested parties;

I have completed the final draft of the total rewrite of FreeBSD's 
handbook Chapter 16 on Jails.


Before submitting my work for submission to the documentation group for 
insertion in the handbook I am looking for critique of the work to find 
errors in concept, wrong use of words, or anything to make it better.


All feedback welcomed.

Use this URL to access it  http://www.jails.a1poweruser.com/


Thank You.

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

Re: Handbook Jail Chapter rewrite available for critique

[Isaac (.ike) Levy]

Pretty heavy cross-posting here, could you perhaps reign this in to the 
freebsd-jail@ list, where it can be discussed in-context?  This will help keep 
the noise down.

On Mar 18, 2013, at 12:57 PM, Fbsd8 wrote:

> To all interested parties;
> 
> I have completed the final draft of the total rewrite of FreeBSD's handbook 
> Chapter 16 on Jails.
> 
> Before submitting my work for submission to the documentation group for 
> insertion in the handbook I am looking for critique of the work to find 
> errors in concept, wrong use of words, or anything to make it better.
> 
> All feedback welcomed.
> 
> Use this URL to access it  http://www.jails.a1poweruser.com/
> 
> 
> Thank You.

Wow, overall that's really quite cool.

- Do you have a rough timeframe for when you want feedback?  (I would like to 
give this the time it deserves).

--
Feedback right off the bat, (please tell me if I'm off track here):

- After a short skim- I do not believe the qjail utilities referenced are 
appropriate for the FreeBSD handbook.  There are many 3rd party approaches to 
handling/managing jails, some of them with quite long histories and loyal user 
bases- it is impractical and not appropriate to try to cover any/all of them 
here.

- The "Jail Cell" vocabulary is a serious departure- and may create some 
confusion- I'll read thoroughly to get your context right.  In what I 
understand to be the majority of uses, it's confusing to think of the hardware 
host as the 'jail' and the jailed instance as the 'cell'.

- The references and history cite some works, but do not cite the original (and 
possibly most important) document on jailing, 
http://docs.freebsd.org/44doc/papers/jail/jail.ps.gz

- There are a number of common lexical errors right off the bat, (There instead 
of Their), etc…

--
I look foreword to reading this on my subway commute this week-

Best,
.ike


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

Re: Handbook Jail Chapter rewrite available for critique

[Robert Huff]

Isaac (.ike) Levy writes:

>  Pretty heavy cross-posting here, could you perhaps reign this in
>  to the freebsd-jail@ list, where it can be discussed in-context?
>  This will help keep the noise down.

It will also keep down the signal from people who use or are
interested in jails, but do not (and do not plan to) subscribe to
that list.

Respectfully,


Robert Huff

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

Handbook Jail Chapter rewrite available for critique

[Fbsd8]

To all interested parties;

I have completed the final draft of the total rewrite of FreeBSD's
handbook Chapter 16 on Jails.

Before submitting my work for submission to the documentation group for
insertion in the handbook I am looking for critique of the work to find
errors in concept, wrong use of words, or anything to make it better.

All feedback welcomed. Please email me directly so we keep the noise 
down on the mailing list.


Use this URL to access it  http://www.jails.a1poweruser.com/


Thank You.

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


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

Re: NewNFS vs. oldNFS for 10.0?

[Peter Holm]

On Mon, Mar 18, 2013 at 01:43:24PM +0100, Andre Oppermann wrote:
> On 15.03.2013 15:08, Rick Macklem wrote:
> > Lars Eggert wrote:
> >> Hi,
> >>
> >> this reminds me that I ran into an issue lately with the new NFS and
> >> locking for NFSv3 mounts on a client that ran -CURRENT and a server
> >> that ran -STABLE.
> >>
> >> When I ran "portmaster -a" on the client, which mounted /usr/ports and
> >> /usr/local, as well as the location of the respective sqlite databases
> >> over NFSv3, the client network stack became unresponsive on all
> >> interfaces for 30 or so seconds and e.g. SSH connections broke. The
> >> serial console remained active throughout, and the system didn't
> >> crash. About a minute after the wedgie I could SSH into the box again,
> >> too.
> >>
> >> The issue went away when I killed lockd on the client, but that caused
> >> the sqlite database to become corrupted over time. The workaround for
> >> me was to move to NFSv4, which has been working fine. (One more reason
> >> to make it the default...)
> >>
> > I've mentioned limitations w.r.t. the design of the NLM protocol (rpc.lockd)
> > before. Any time there is any kind of network topology issue, it will run
> > into difficulties. There may also be other issues.
> >
> > However, since both the old and new client use the same rpc.lockd in the
> > same way (the new one just cribbed the code from the old one), I think
> > the same problem would exist for the old one. As such, I don't believe
> > this is a regression.
> 
> Maybe we can talk Peter Holm into periodically running his file system
> stress test suite against NFS too?  :-)  Peter?
> 

I'll add this to my work queue :)

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

Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots

[Mehmet Erol Sanliturk]

On Mon, Mar 18, 2013 at 9:48 AM, Scot Hetzel  wrote:

> On Mon, Mar 18, 2013 at 11:06 AM, Mehmet Erol Sanliturk
>  wrote:
> > Computer A : Memory Chip Sizes : ( 2 GB , 1 GB , 2 GB , 1 GB ) : Working
> > SLOW . FreeBSD A
> > Computer B  : Memory Chip Sizes : ( 2 GB , 2 GB , 2 GB , 2 GB ) : Working
> > FAST . FreeBSD B
> >
> > Interchange memory chips :
> >
> > Computer A : Memory Chip Sizes : ( 2 GB , 2 GB , 2 GB , 2 GB ) : Working
> > FAST . FreeBSD A
> > Computer B  : Memory Chip Sizes : ( 2 GB , 1 GB , 2 GB , 1 GB ) : Working
> > SLOW . FreeBSD B
> >
> >
>
> What happens if you configure the memory as ( 2 GB , 2 GB , 1 GB , 1 GB )?
>
> --
> DISCLAIMER:
>
> No electrons were maimed while sending this message. Only slightly bruised.
>


This can NOT be done  , because

Channel A : Slot 1 :
   Slot 2 :

Channel B : Slot 1 :
   Slot 2 :

( Slot 1 , Slot 1 ) should be equivalent when chips inserted to both .
( Slot 2 , Slot 2 ) should be equivalent when chips inserted to both .

Thank you ver much .

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

Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots

[Mehmet Erol Sanliturk]

Dear All ,

I tried the following on Nathan Whitehorn's  suggestions :


I have disabled ~/.xinitrc , leaving X with its default window manager .

I have started Firefox . The same slow behavior !

The problem starts after STARTING X . The rest ( FluxBox , KDE , Gnome )
seems to be innocent .


If I can apply other tests , please tell me .


Thank you very much .

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

Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots

[olli hauer]

On 2013-03-18 21:43, Mehmet Erol Sanliturk wrote:
> On Mon, Mar 18, 2013 at 9:48 AM, Scot Hetzel  wrote:
> 
>> On Mon, Mar 18, 2013 at 11:06 AM, Mehmet Erol Sanliturk
>>  wrote:
>>> Computer A : Memory Chip Sizes : ( 2 GB , 1 GB , 2 GB , 1 GB ) : Working
>>> SLOW . FreeBSD A
>>> Computer B  : Memory Chip Sizes : ( 2 GB , 2 GB , 2 GB , 2 GB ) : Working
>>> FAST . FreeBSD B
>>>
>>> Interchange memory chips :
>>>
>>> Computer A : Memory Chip Sizes : ( 2 GB , 2 GB , 2 GB , 2 GB ) : Working
>>> FAST . FreeBSD A
>>> Computer B  : Memory Chip Sizes : ( 2 GB , 1 GB , 2 GB , 1 GB ) : Working
>>> SLOW . FreeBSD B
>>>
>>>
>>
>> What happens if you configure the memory as ( 2 GB , 2 GB , 1 GB , 1 GB )?
>>
>> --
>> DISCLAIMER:
>>
>> No electrons were maimed while sending this message. Only slightly bruised.
>>
> 
> 
> This can NOT be done  , because
> 
> Channel A : Slot 1 :
>Slot 2 :
> 
> Channel B : Slot 1 :
>Slot 2 :
> 
> ( Slot 1 , Slot 1 ) should be equivalent when chips inserted to both .
> ( Slot 2 , Slot 2 ) should be equivalent when chips inserted to both .
> 
> Thank you ver much .
> 

I suspect the BIOS does not detect the optimal timing for the "SLOW" RAM or
a RAM Module is running on a slower timing.

What happen if you test with only the 2GB or the 1GB modules (to identify 
possible CHIP issues).
How is the memory detected in the BIOS (timings ...) some newer BIOS can run 
manual tests to detect timing issues.



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

Re: Handbook Jail Chapter rewrite available for critique

[Andreas Nilsson]

On Mon, Mar 18, 2013 at 6:45 PM, Robert Huff  wrote:

>
> Isaac (.ike) Levy writes:
>
> >  Pretty heavy cross-posting here, could you perhaps reign this in
> >  to the freebsd-jail@ list, where it can be discussed in-context?
> >  This will help keep the noise down.
>
> It will also keep down the signal from people who use or are
> interested in jails, but do not (and do not plan to) subscribe to
> that list.
>
Respectfully,
>
>
> Robert Huff
>
>
Great! There really was a need to modernize the handbook with regards to
jails. Since I'm not a native English speaker I'll leave grammar and
spelling for those who are ;)

My first impressions are along the lines:
To much scripts, to few examples/scenarios. Our users are smart, show them
what can be accomplished with "high-level" config, leave minutiae to some
part of the appendix.

Also the exclusion of zfs and vnet is surprising, as those really make
jails shine, imo ( although jails really need to be thought about the
"gray" area visa-vi networking in rc-scripts that vnet provides ). How
about the resource control, which further makes jails really spiffy.

I would have preferred top-level separation of the different methods, ie
after the introduction there was one "track" manual, one for old-school
rc-, one for new-school rc- and one for jail.conf-style jails.


More specifically I agree with Isaac Levy's, especially in regards to the
"jail cell" terminology:

"16.1 Synopsis": the term jail cell is used, long before being defined.

"16.2 Introduction": Mentioning jail cells in a historic contest is imho a
"blatant" lie ( they were never known as such ). As far as I know, no
official documentation has called them cells, either. That does not mean
that it's not an appropriate term, though. As a contrast there is Solaris
vocabulary of zones ( "cells" ) and global zone ( "jail system" ). In this
regard I prefer the solaris one.
Most importantly, a large chunk of 16.2 would imo fit much better as a
"history"-appendix. Current and new users don't need to know and consider
the limitations of earlier implementations. The "generations" talked about
could perhaps be quantified with a release version :)

There are, as stated by Isaac Levy, many (good) utils for managing jails.
Why the focus on qjail? I also think that most of the strong points of
jails are rendered moot without, in order, zfs and vimage. Linux jails
might also interest quite a few people.

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

Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots

[Mehmet Erol Sanliturk]

On Mon, Mar 18, 2013 at 2:28 PM, olli hauer  wrote:

> On 2013-03-18 21:43, Mehmet Erol Sanliturk wrote:
> > On Mon, Mar 18, 2013 at 9:48 AM, Scot Hetzel  wrote:
> >
> >> On Mon, Mar 18, 2013 at 11:06 AM, Mehmet Erol Sanliturk
> >>  wrote:
> >>> Computer A : Memory Chip Sizes : ( 2 GB , 1 GB , 2 GB , 1 GB ) :
> Working
> >>> SLOW . FreeBSD A
> >>> Computer B  : Memory Chip Sizes : ( 2 GB , 2 GB , 2 GB , 2 GB ) :
> Working
> >>> FAST . FreeBSD B
> >>>
> >>> Interchange memory chips :
> >>>
> >>> Computer A : Memory Chip Sizes : ( 2 GB , 2 GB , 2 GB , 2 GB ) :
> Working
> >>> FAST . FreeBSD A
> >>> Computer B  : Memory Chip Sizes : ( 2 GB , 1 GB , 2 GB , 1 GB ) :
> Working
> >>> SLOW . FreeBSD B
> >>>
> >>>
> >>
> >> What happens if you configure the memory as ( 2 GB , 2 GB , 1 GB , 1 GB
> )?
> >>
> >> --
> >> DISCLAIMER:
> >>
> >> No electrons were maimed while sending this message. Only slightly
> bruised.
> >>
> >
> >
> > This can NOT be done  , because
> >
> > Channel A : Slot 1 :
> >Slot 2 :
> >
> > Channel B : Slot 1 :
> >Slot 2 :
> >
> > ( Slot 1 , Slot 1 ) should be equivalent when chips inserted to both .
> > ( Slot 2 , Slot 2 ) should be equivalent when chips inserted to both .
> >
> > Thank you ver much .
> >
>
> I suspect the BIOS does not detect the optimal timing for the "SLOW" RAM or
> a RAM Module is running on a slower timing.
>
> What happen if you test with only the 2GB or the 1GB modules (to identify
> possible CHIP issues).
> How is the memory detected in the BIOS (timings ...) some newer BIOS can
> run manual tests to detect timing issues.
>
>
>
>
These are worked :

http://lists.freebsd.org/pipermail/freebsd-current/2012-February/031836.html
http://lists.freebsd.org/pipermail/freebsd-current/2012-February/031912.html
http://lists.freebsd.org/pipermail/freebsd-current/2012-February/031928.html
http://lists.freebsd.org/pipermail/freebsd-current/2012-February/032012.html


It seems that memory chip sizes are not checked one by one or used per chip
in slots , but a COMMON value is used :

Size of chip in first slot . When size of chip in second slot is smaller
than size of chip in first slot , problem appears .

Thank you very much .

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

[head tinderbox] failure on powerpc64/powerpc

[FreeBSD Tinderbox]

TB --- 2013-03-18 19:54:43 - tinderbox 2.10 running on freebsd-current.sentex.ca
TB --- 2013-03-18 19:54:43 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE 
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2013-03-18 19:54:43 - starting HEAD tinderbox run for powerpc64/powerpc
TB --- 2013-03-18 19:54:43 - cleaning the object tree
TB --- 2013-03-18 19:54:43 - /usr/local/bin/svn stat /src
TB --- 2013-03-18 19:54:46 - At svn revision 248465
TB --- 2013-03-18 19:54:47 - building world
TB --- 2013-03-18 19:54:47 - CROSS_BUILD_TESTING=YES
TB --- 2013-03-18 19:54:47 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-03-18 19:54:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-03-18 19:54:47 - SRCCONF=/dev/null
TB --- 2013-03-18 19:54:47 - TARGET=powerpc
TB --- 2013-03-18 19:54:47 - TARGET_ARCH=powerpc64
TB --- 2013-03-18 19:54:47 - TZ=UTC
TB --- 2013-03-18 19:54:47 - __MAKE_CONF=/dev/null
TB --- 2013-03-18 19:54:47 - cd /src
TB --- 2013-03-18 19:54:47 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Mon Mar 18 19:54:52 UTC 2013
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> stage 5.1: building 32 bit shim libraries
>>> World build completed on Mon Mar 18 22:38:03 UTC 2013
TB --- 2013-03-18 22:38:03 - generating LINT kernel config
TB --- 2013-03-18 22:38:03 - cd /src/sys/powerpc/conf
TB --- 2013-03-18 22:38:03 - /usr/bin/make -B LINT
TB --- 2013-03-18 22:38:03 - cd /src/sys/powerpc/conf
TB --- 2013-03-18 22:38:03 - /usr/sbin/config -m LINT
TB --- 2013-03-18 22:38:03 - skipping LINT kernel
TB --- 2013-03-18 22:38:03 - cd /src/sys/powerpc/conf
TB --- 2013-03-18 22:38:03 - /usr/sbin/config -m GENERIC
TB --- 2013-03-18 22:38:03 - skipping GENERIC kernel
TB --- 2013-03-18 22:38:03 - cd /src/sys/powerpc/conf
TB --- 2013-03-18 22:38:03 - /usr/sbin/config -m GENERIC64
TB --- 2013-03-18 22:38:03 - building GENERIC64 kernel
TB --- 2013-03-18 22:38:03 - CROSS_BUILD_TESTING=YES
TB --- 2013-03-18 22:38:03 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-03-18 22:38:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-03-18 22:38:03 - SRCCONF=/dev/null
TB --- 2013-03-18 22:38:03 - TARGET=powerpc
TB --- 2013-03-18 22:38:03 - TARGET_ARCH=powerpc64
TB --- 2013-03-18 22:38:03 - TZ=UTC
TB --- 2013-03-18 22:38:03 - __MAKE_CONF=/dev/null
TB --- 2013-03-18 22:38:03 - cd /src
TB --- 2013-03-18 22:38:03 - /usr/bin/make -B buildkernel KERNCONF=GENERIC64
>>> Kernel build for GENERIC64 started on Mon Mar 18 22:38:03 UTC 2013
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
[...]
/src/sys/modules/dtrace/fbt/../../../cddl/dev/fbt/fbt.c:291: error: 
'DTRACE_INVOP_PUSHL_EBP' undeclared (first use in this function)
/src/sys/modules/dtrace/fbt/../../../cddl/dev/fbt/fbt.c:291: error: (Each 
undeclared identifier is reported only once
/src/sys/modules/dtrace/fbt/../../../cddl/dev/fbt/fbt.c:291: error: for each 
function it appears in.)
cc1: warnings being treated as errors
/src/sys/modules/dtrace/fbt/../../../cddl/dev/fbt/fbt.c:311: warning: implicit 
declaration of function 'dtrace_instr_size'
/src/sys/modules/dtrace/fbt/../../../cddl/dev/fbt/fbt.c:311: warning: nested 
extern declaration of 'dtrace_instr_size' [-Wnested-externs]
/src/sys/modules/dtrace/fbt/../../../cddl/dev/fbt/fbt.c:385: error: 
'DTRACE_INVOP_POPL_EBP' undeclared (first use in this function)
/src/sys/modules/dtrace/fbt/../../../cddl/dev/fbt/fbt.c:388: error: 
'DTRACE_INVOP_LEAVE' undeclared (first use in this function)
*** [fbt.o] Error code 1

Stop in /src/sys/modules/dtrace/fbt.
*** [all] Error code 1

Stop in /src/sys/modules/dtrace.
*** [all] Error code 1

Stop in /src/sys/modules.
*** [modules-all] Error code 1

Stop in /obj/powerpc.powerpc64/src/sys/GENERIC64.
*** [buildkernel] Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2013-03-18 22:46:56 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2013-03-18 22:46:56 - ERROR: failed to build GENERIC64 kernel
TB --- 2013-03-18 22:46:56 - 9218.26 user 1190.64 system 10333.29 real


http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-powerpc64-powerpc.full
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: gptzfsboot problem on HP P410i Smart Array

[Sergey Dyatko]

2012/8/20 Bjorn Larsson 

> Hi Andrey,
>
> We are installing freeBSD using ZFS as root filesystem using the GPT
> method as described on the freeBSD ZFS wiki. We are creating a GPT
> boot partition with the gptzfsboot program embedded and then a zroot
> partition with the freeBSD binaries. This works well and boots on
> every system we tested except HP P410i smart array systems. The
> problem is that no disks are identified in gptzfsboot and the
> following error code is displayed:
>
> gptzfsboot: error 1 lba 32
> gptzfsboot: error 1 lba 1
>
> It appears that gptzfsboot is not identifying the drives properly.
> However, when we insert a printf() command in main() in zfsboot.c to
> troubleshoot the identification problem, the system boots perfectly
> fine.
>
> This is a problem that I believe was fixed last year in 9-CURRENT by
> implementing a proper struct for edd rather than using a char array
> for BIOS communication. However, it doesn't seems to have fixed the on
> the p410i smart arrays.
>
>
I was faced with same problem on my laptop. Adding printf() into main()
before dsk = malloc(sizeof(struct dsk)); fix boot. Yesterday, avg@ proposed
patch:
Index: /usr/src/sys/boot/i386/zfsboot/zfsboot.c
===
--- /usr/src/sys/boot/i386/zfsboot/zfsboot.c(revision 248421)
+++ /usr/src/sys/boot/i386/zfsboot/zfsboot.c(working copy)
@@ -302,6 +302,7 @@
  * region in the SMAP, use the last 3MB of 'extended' memory as a
  * high heap candidate.
  */
+   high_heap_size = 0;
 if (bios_extmem >= HEAP_MIN && high_heap_size < HEAP_MIN) {
high_heap_size = HEAP_MIN;
high_heap_base = bios_extmem + 0x10 - HEAP_MIN;

it works for me, without printf() :) Can you test it ?

> Best regards,
>
> Björn Larsson
>
>
> On Sun, Aug 19, 2012 at 6:41 PM, Andrey V. Elsukov 
> wrote:
> >
> > On 19.08.2012 11:22, Bjorn Larsson wrote:
> > > We are having problems with gptzfsboot on a HP DL360 G7 using the P410i
> > > Smart Array Controller.
> > > I’ve some information on this in the archive on this mailing list that
> this
> > > has supposedly been fixed with revision 227400, by implementing the edd
> > > data structure.
> > > However we still see the same problem and by adding a printf() in
> zfsboot.c
> > > fixes the problem.
> > > Please, let me know if anyone have seen this problem and if there is a
> fix
> > > for it?
> >
> > Hi,
> >
> > what exactly do you have?
> >
> > --
> > WBR, Andrey V. Elsukov
> >
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"