Re: Firefox Crashes; slow xfce

[Guillaume Simon]

Unless your current user is in the daemon login class (which is
unlikely), it shouldn't.
Have a look to the manual page of login.conf(5) to understand how it works.
When you edit your login.conf, you have to login again for your
modifications to take effect.
It may explain a difference between the theorical value of your
login.conf file, and the real current value.


Le 04/20/16 18:29, Daniel Boyd a écrit :
> openfiles-cur is set to 128 under daemon in my login.conf.  Could that be
> affecting it?
>
> On Wed, Apr 20, 2016 at 10:51 AM, Guillaume Simon <
> guillaume.si...@mailoo.org> wrote:
>
>> Your nofiles(descriptors) may be too low.
>> You should consider increasing it to 512 or more
>> The weird thing is it doesn't match the "openfiles-cur" of your default
>> login class (2048, according to your first email).
>>
>> Le 04/20/16 16:41, Daniel Boyd a écrit :
>>> $ ulimit -a
>>> time(cpu-seconds)unlimited
>>> file(blocks) unlimited
>>> coredump(blocks) unlimited
>>> data(kbytes) 3584000
>>> stack(kbytes)4096
>>> lockedmem(kbytes)2701637
>>> memory(kbytes)   8101908
>>> nofiles(descriptors) 128
>>> processes256

Re: Firefox Crashes; slow xfce

[Daniel Boyd]

Radeon HD 7770

Sent from Outlook Mobile. Yes, it works with gmail.




On Wed, Apr 20, 2016 at 12:21 PM -0700, "ilyes aiouaz"
 wrote:










Hi,
What's the model of your graphics card ?


Le 20/04/2016 18:46, Daniel Boyd a écrit :
> Breakthrough in xfce -- Settings -> Window Manager Tweaks -> Compositor.
> Disabled it.
>
> Runs *so* much better
>
> On Wed, Apr 20, 2016 at 11:35 AM, Daniel Boyd  wrote:
>
>> I just switched to fvwm this morning and it's night-and-day faster than
>> xfce.  Hard to believe it's the same computer.  I'm going to have to spend
>> some quality time with the fvwm manpage because I've never used it much
>> beyond launching xterm to install another window manager :)
>>
>> On Mon, Apr 18, 2016 at 3:40 PM, Edgar Pettijohn
>> wrote:
>>
>>> I don't have any problems with Firefox  on -current with Fvwm2. I
>>> switched to Fvwm because Xfce was getting unmanageable. After about a
week
>>> when I got my config just right it is much easier and faster than Xfce
just
>>> not as pretty.
>>>
>>> Sent from my iPhone
>>>
 On Apr 18, 2016, at 3:13 PM, Daniel Boyd  wrote:

 Thanks -- I will give xombrero a shot.  Definitely need javascript
>>> support
 as I am currently composing this in Gmail  and do quite a bit of
 javscript-based web development :)

> On Mon, Apr 18, 2016 at 1:31 PM,  wrote:
>
> I think the problem is with firefox itself.
> tedu@ wrote a post about this:
> http://www.tedunangst.com/flak/post/firefox-vs-rthreads
>
> Since the code is so bloated, no one will ever waste time trying to fix
> all the issues. Just switch to some other browser, there's plenty of
> options.
> I'm using Links 2.12 on -stable and it works fine for my needs. But
> there's also Xombrero if you need javascript support.

Re: Firefox Crashes; slow xfce

[ilyes aiouaz]

Hi,
What's the model of your graphics card ?


Le 20/04/2016 18:46, Daniel Boyd a écrit :

Breakthrough in xfce -- Settings -> Window Manager Tweaks -> Compositor.
Disabled it.

Runs *so* much better

On Wed, Apr 20, 2016 at 11:35 AM, Daniel Boyd  wrote:


I just switched to fvwm this morning and it's night-and-day faster than
xfce.  Hard to believe it's the same computer.  I'm going to have to spend
some quality time with the fvwm manpage because I've never used it much
beyond launching xterm to install another window manager :)

On Mon, Apr 18, 2016 at 3:40 PM, Edgar Pettijohn 
wrote:


I don't have any problems with Firefox  on -current with Fvwm2. I
switched to Fvwm because Xfce was getting unmanageable. After about a week
when I got my config just right it is much easier and faster than Xfce just
not as pretty.

Sent from my iPhone


On Apr 18, 2016, at 3:13 PM, Daniel Boyd  wrote:

Thanks -- I will give xombrero a shot.  Definitely need javascript

support

as I am currently composing this in Gmail  and do quite a bit of
javscript-based web development :)


On Mon, Apr 18, 2016 at 1:31 PM,  wrote:

I think the problem is with firefox itself.
tedu@ wrote a post about this:
http://www.tedunangst.com/flak/post/firefox-vs-rthreads

Since the code is so bloated, no one will ever waste time trying to fix
all the issues. Just switch to some other browser, there's plenty of
options.
I'm using Links 2.12 on -stable and it works fine for my needs. But
there's also Xombrero if you need javascript support.

Re: Firefox Crashes; slow xfce

[Daniel Boyd]

Breakthrough in xfce -- Settings -> Window Manager Tweaks -> Compositor.
Disabled it.

Runs *so* much better

On Wed, Apr 20, 2016 at 11:35 AM, Daniel Boyd  wrote:

> I just switched to fvwm this morning and it's night-and-day faster than
> xfce.  Hard to believe it's the same computer.  I'm going to have to spend
> some quality time with the fvwm manpage because I've never used it much
> beyond launching xterm to install another window manager :)
>
> On Mon, Apr 18, 2016 at 3:40 PM, Edgar Pettijohn 
> wrote:
>
>> I don't have any problems with Firefox  on -current with Fvwm2. I
>> switched to Fvwm because Xfce was getting unmanageable. After about a week
>> when I got my config just right it is much easier and faster than Xfce just
>> not as pretty.
>>
>> Sent from my iPhone
>>
>> > On Apr 18, 2016, at 3:13 PM, Daniel Boyd  wrote:
>> >
>> > Thanks -- I will give xombrero a shot.  Definitely need javascript
>> support
>> > as I am currently composing this in Gmail  and do quite a bit of
>> > javscript-based web development :)
>> >
>> >> On Mon, Apr 18, 2016 at 1:31 PM,  wrote:
>> >>
>> >> I think the problem is with firefox itself.
>> >> tedu@ wrote a post about this:
>> >> http://www.tedunangst.com/flak/post/firefox-vs-rthreads
>> >>
>> >> Since the code is so bloated, no one will ever waste time trying to fix
>> >> all the issues. Just switch to some other browser, there's plenty of
>> >> options.
>> >> I'm using Links 2.12 on -stable and it works fine for my needs. But
>> >> there's also Xombrero if you need javascript support.

Re: Firefox Crashes; slow xfce

[Daniel Boyd]

openfiles-cur is set to 128 under daemon in my login.conf.  Could that be
affecting it?

On Wed, Apr 20, 2016 at 10:51 AM, Guillaume Simon <
guillaume.si...@mailoo.org> wrote:

> Your nofiles(descriptors) may be too low.
> You should consider increasing it to 512 or more
> The weird thing is it doesn't match the "openfiles-cur" of your default
> login class (2048, according to your first email).
>
> Le 04/20/16 16:41, Daniel Boyd a écrit :
> > $ ulimit -a
> > time(cpu-seconds)unlimited
> > file(blocks) unlimited
> > coredump(blocks) unlimited
> > data(kbytes) 3584000
> > stack(kbytes)4096
> > lockedmem(kbytes)2701637
> > memory(kbytes)   8101908
> > nofiles(descriptors) 128
> > processes256

Re: Firefox Crashes; slow xfce

[Daniel Boyd]

I just switched to fvwm this morning and it's night-and-day faster than
xfce.  Hard to believe it's the same computer.  I'm going to have to spend
some quality time with the fvwm manpage because I've never used it much
beyond launching xterm to install another window manager :)

On Mon, Apr 18, 2016 at 3:40 PM, Edgar Pettijohn 
wrote:

> I don't have any problems with Firefox  on -current with Fvwm2. I switched
> to Fvwm because Xfce was getting unmanageable. After about a week when I
> got my config just right it is much easier and faster than Xfce just not as
> pretty.
>
> Sent from my iPhone
>
> > On Apr 18, 2016, at 3:13 PM, Daniel Boyd  wrote:
> >
> > Thanks -- I will give xombrero a shot.  Definitely need javascript
> support
> > as I am currently composing this in Gmail  and do quite a bit of
> > javscript-based web development :)
> >
> >> On Mon, Apr 18, 2016 at 1:31 PM,  wrote:
> >>
> >> I think the problem is with firefox itself.
> >> tedu@ wrote a post about this:
> >> http://www.tedunangst.com/flak/post/firefox-vs-rthreads
> >>
> >> Since the code is so bloated, no one will ever waste time trying to fix
> >> all the issues. Just switch to some other browser, there's plenty of
> >> options.
> >> I'm using Links 2.12 on -stable and it works fine for my needs. But
> >> there's also Xombrero if you need javascript support.

Re: Firefox Crashes; slow xfce

[Guillaume Simon]

Your nofiles(descriptors) may be too low.
You should consider increasing it to 512 or more
The weird thing is it doesn't match the "openfiles-cur" of your default
login class (2048, according to your first email).

Le 04/20/16 16:41, Daniel Boyd a écrit :
> $ ulimit -a
> time(cpu-seconds)unlimited
> file(blocks) unlimited
> coredump(blocks) unlimited
> data(kbytes) 3584000
> stack(kbytes)4096
> lockedmem(kbytes)2701637
> memory(kbytes)   8101908
> nofiles(descriptors) 128
> processes256

Re: Firefox Crashes; slow xfce

[Daniel Boyd]

$ ulimit -a
time(cpu-seconds)unlimited
file(blocks) unlimited
coredump(blocks) unlimited
data(kbytes) 3584000
stack(kbytes)4096
lockedmem(kbytes)2701637
memory(kbytes)   8101908
nofiles(descriptors) 128
processes256


On Tue, Apr 19, 2016 at 3:52 PM, ilyes aiouaz 
wrote:

> Le 19/04/2016 19:11, Daniel Boyd a écrit :
>
>> Firefox has been quite stable, with or without the 'noscript' plug-in,
>>>
>> since I increased my data allocation. The crashes that I saw
>>
>>> previously were all due to running out of memory (I don't run a
>>> desktop, just a wm, nor do I use xdm, so it's easy to see Firefox
>>> errors on the vt where I ran the 'startx' command).
>>>
>>> I'm running xdm and xfce4, so I suppose the culprit must lie in there
>> somewhere...   The crashes seem to happen when certain other programs
>> launch.  Like evince and libreoffice...  It really doesn't seem to like
>> anything gtk3-based.  Once it starts crashing, I can see 5 or 6 crashes
>> within a span of 5-10 minutes.  And then it won't crash for a day or two.
>>
>> Hi Everybody,
> Did you change the following parameters in the /etc/login.conf :
>
> default:\
> ...
> :datasize-max= :\
> :datasize-cur= :\
> :maxproc-max= :\
> :maxproc-cur= :\
> :openfiles-cur= :\
> :stacksize-cur= :\
>
> staff:\
> :datasize-cur= :\
> ...

Re: Firefox Crashes; slow xfce

[Kevin Chadwick]

> I've been using OpenBSD (first 5.8 and now 5.9) on my primary work machine
> for a couple months now.  

I still find xombrero far faster than firefox, however I am on 5.9 and
often use older machines. However I have switched my browser even on my
windows machine to xombrero for local browsing as it saves me no
joke atleast 300M of memory with xombrero going down to 16M when pages
are idle. Some sites break in whitelist mode though, which is annoying
and primarily aside from overlaps in known security issues why I
keep both around, with w^x though I *may*?? switch back if the
performance has improved.

Were the threading changes that sped up firefox committed after 5.9 and
so in current? Perhaps some are seeing differences in performance
because of that?

p.s. I noticed the last security webkit update in mtier stable a while
back for amd64, did those issues not apply to i386 as well?

-- 

KISSIS - Keep It Simple So It's Securable

Re: Firefox Crashes; slow xfce

[ilyes aiouaz]

Le 19/04/2016 19:11, Daniel Boyd a écrit :

Firefox has been quite stable, with or without the 'noscript' plug-in,

since I increased my data allocation. The crashes that I saw

previously were all due to running out of memory (I don't run a
desktop, just a wm, nor do I use xdm, so it's easy to see Firefox
errors on the vt where I ran the 'startx' command).


I'm running xdm and xfce4, so I suppose the culprit must lie in there
somewhere...   The crashes seem to happen when certain other programs
launch.  Like evince and libreoffice...  It really doesn't seem to like
anything gtk3-based.  Once it starts crashing, I can see 5 or 6 crashes
within a span of 5-10 minutes.  And then it won't crash for a day or two.


Hi Everybody,
Did you change the following parameters in the /etc/login.conf :

default:\
...
:datasize-max= :\
:datasize-cur= :\
:maxproc-max= :\
:maxproc-cur= :\
:openfiles-cur= :\
:stacksize-cur= :\

staff:\
:datasize-cur= :\
...

Re: Firefox Crashes; slow xfce

[Daniel Boyd]

> Firefox has been quite stable, with or without the 'noscript' plug-in,

since I increased my data allocation. The crashes that I saw
> previously were all due to running out of memory (I don't run a
> desktop, just a wm, nor do I use xdm, so it's easy to see Firefox
> errors on the vt where I ran the 'startx' command).
>

I'm running xdm and xfce4, so I suppose the culprit must lie in there
somewhere...   The crashes seem to happen when certain other programs
launch.  Like evince and libreoffice...  It really doesn't seem to like
anything gtk3-based.  Once it starts crashing, I can see 5 or 6 crashes
within a span of 5-10 minutes.  And then it won't crash for a day or two.

Re: Firefox Crashes; slow xfce

[Donald Allen]

On Tue, Apr 19, 2016 at 1:54 PM, Daniel Boyd  wrote:
> I was OK with the performance in Firefox (though it was pretty slow).  What
> was *really* bothering me was the crashing.  Does 'noscript' solve that as
> well?

Firefox has been quite stable, with or without the 'noscript' plug-in,
since I increased my data allocation. The crashes that I saw
previously were all due to running out of memory (I don't run a
desktop, just a wm, nor do I use xdm, so it's easy to see Firefox
errors on the vt where I ran the 'startx' command).

>
> I'm currently trying out xombrero and vimb.  I feel like vimb might be a bit
> faster, but it doesn't recognize the Gmail composing text area as an input.

I tried vimb, but I *am* seeing crashes with it, plus a whole slew of
complaints from glib that it had been passed a NULL pointer. It's nice
while it lasts, but the MTBF is far too small.

> Anyone know how to force vimb into insert mode?

If you still want to use it after what I said above, see the man page.
It's all there.

Re: Firefox Crashes; slow xfce

[Daniel Boyd]

I was OK with the performance in Firefox (though it was pretty slow).  What
was *really* bothering me was the crashing.  Does 'noscript' solve that as
well?

I'm currently trying out xombrero and vimb.  I feel like vimb might be a
bit faster, but it doesn't recognize the Gmail composing text area as an
input.  Anyone know how to force vimb into insert mode?

On Tue, Apr 19, 2016 at 12:51 PM, Donald Allen 
wrote:

> On Tue, Apr 19, 2016 at 12:58 PM, Federico Carrone
>  wrote:
> > After migrating from Linux to OpenBSD on my desktop performance was
> really
> > bad inside Firefox and Chromium in 5.9 specially on big websites like
> gmail.
> > It was not usable, on an 4 core machine and with 16GB of RAM. After
> > migrating to -current, they have become usable. If it is possible try to
> use
> > firefox/chrome in current and check if it works fine.
>
> Thanks for the tip, but getting rid of much of the incredibly annoying
> javascript-generated junk ("Don't read that! Click me instead!") has
> resulted in perfectly good Firefox performance even without the recent
> improvements in -current.

Re: Firefox Crashes; slow xfce

[Donald Allen]

On Tue, Apr 19, 2016 at 12:58 PM, Federico Carrone
 wrote:
> After migrating from Linux to OpenBSD on my desktop performance was really
> bad inside Firefox and Chromium in 5.9 specially on big websites like gmail.
> It was not usable, on an 4 core machine and with 16GB of RAM. After
> migrating to -current, they have become usable. If it is possible try to use
> firefox/chrome in current and check if it works fine.

Thanks for the tip, but getting rid of much of the incredibly annoying
javascript-generated junk ("Don't read that! Click me instead!") has
resulted in perfectly good Firefox performance even without the recent
improvements in -current.

Re: Firefox Crashes; slow xfce

[Federico Carrone]

After migrating from Linux to OpenBSD on my desktop performance was really
bad inside Firefox and Chromium in 5.9 specially on big websites like
gmail. It was not usable, on an 4 core machine and with 16GB of RAM. After
migrating to -current, they have become usable. If it is possible try to
use firefox/chrome in current and check if it works fine.

On Tue, Apr 19, 2016 at 8:00 AM Donald Allen  wrote:

> I have also had problems with Firefox performance with OpenBSD (it's
> not a speed demon with Linux or FreeBSD, but it is faster on those
> systems). And I haven't found Chromium to be a good alternative -- too
> many crashes and "Oh, snap"s.
>
> But my experience with Firefox is that the problem is easily solved:
> install the Noscript plugin (RequestPolicy isn't a bad idea either).
> Noscript gives you finer-grained control over when to allow javascript
> than about:config does. And I think it is clear that javascript is the
> problem, compounded by Firefox' scheduling tabs itself, rather than
> creating a process for each and letting the system scheduler do its
> job.
>
> I can well believe that there is a performance/security tradeoff, as
> Ted Unangst mentioned, and I much prefer the OpenBSD approach of not
> giving in to the temptation to compromise security to quiet the
> performance complaints, especially given that there is another way to
> manage this problem (which has at its core, in my opinion, the overuse
> of javascript; there seems to be a pattern in the human condition of
> coming up with good inventions and then misusing them, e.g., the
> cell-phone, which has become a bodily appendage for too many; I'll
> spare you the rest of my rant on this topic).
>
> On Mon, Apr 18, 2016 at 4:40 PM, Edgar Pettijohn
>  wrote:
> > I don't have any problems with Firefox  on -current with Fvwm2. I
> switched to
> > Fvwm because Xfce was getting unmanageable. After about a week when I
> got my
> > config just right it is much easier and faster than Xfce just not as
> pretty.
> >
> > Sent from my iPhone
> >
> >> On Apr 18, 2016, at 3:13 PM, Daniel Boyd  wrote:
> >>
> >> Thanks -- I will give xombrero a shot.  Definitely need javascript
> support
> >> as I am currently composing this in Gmail  and do quite a bit of
> >> javscript-based web development :)
> >>
> >>> On Mon, Apr 18, 2016 at 1:31 PM,  wrote:
> >>>
> >>> I think the problem is with firefox itself.
> >>> tedu@ wrote a post about this:
> >>> http://www.tedunangst.com/flak/post/firefox-vs-rthreads
> >>>
> >>> Since the code is so bloated, no one will ever waste time trying to fix
> >>> all the issues. Just switch to some other browser, there's plenty of
> >>> options.
> >>> I'm using Links 2.12 on -stable and it works fine for my needs. But
> >>> there's also Xombrero if you need javascript support.

Re: Firefox Crashes; slow xfce

[Donald Allen]

I have also had problems with Firefox performance with OpenBSD (it's
not a speed demon with Linux or FreeBSD, but it is faster on those
systems). And I haven't found Chromium to be a good alternative -- too
many crashes and "Oh, snap"s.

But my experience with Firefox is that the problem is easily solved:
install the Noscript plugin (RequestPolicy isn't a bad idea either).
Noscript gives you finer-grained control over when to allow javascript
than about:config does. And I think it is clear that javascript is the
problem, compounded by Firefox' scheduling tabs itself, rather than
creating a process for each and letting the system scheduler do its
job.

I can well believe that there is a performance/security tradeoff, as
Ted Unangst mentioned, and I much prefer the OpenBSD approach of not
giving in to the temptation to compromise security to quiet the
performance complaints, especially given that there is another way to
manage this problem (which has at its core, in my opinion, the overuse
of javascript; there seems to be a pattern in the human condition of
coming up with good inventions and then misusing them, e.g., the
cell-phone, which has become a bodily appendage for too many; I'll
spare you the rest of my rant on this topic).

On Mon, Apr 18, 2016 at 4:40 PM, Edgar Pettijohn
 wrote:
> I don't have any problems with Firefox  on -current with Fvwm2. I switched to
> Fvwm because Xfce was getting unmanageable. After about a week when I got my
> config just right it is much easier and faster than Xfce just not as pretty.
>
> Sent from my iPhone
>
>> On Apr 18, 2016, at 3:13 PM, Daniel Boyd  wrote:
>>
>> Thanks -- I will give xombrero a shot.  Definitely need javascript support
>> as I am currently composing this in Gmail  and do quite a bit of
>> javscript-based web development :)
>>
>>> On Mon, Apr 18, 2016 at 1:31 PM,  wrote:
>>>
>>> I think the problem is with firefox itself.
>>> tedu@ wrote a post about this:
>>> http://www.tedunangst.com/flak/post/firefox-vs-rthreads
>>>
>>> Since the code is so bloated, no one will ever waste time trying to fix
>>> all the issues. Just switch to some other browser, there's plenty of
>>> options.
>>> I'm using Links 2.12 on -stable and it works fine for my needs. But
>>> there's also Xombrero if you need javascript support.

Re: Firefox Crashes; slow xfce

[Guillaume Simon - Mailoo]

For what it's worth, Firefox may be quite usable even on an old config
when you add plugins limiting javascript usage such as :
- RequestPolicy
- Noscript

I use it daily on an 11 years old computer and prefere it over xombrero
because of the following issues :
- https://github.com/conformal/xombrero/issues/128
- https://github.com/conformal/xombrero/issues/90

It may not be enough for your javscript-based web development or on the
contrary it may give you an insight of the bloat-level of the framework
you use. ;)

Le 04/18/16 22:13, Daniel Boyd a écrit :
> Thanks -- I will give xombrero a shot.  Definitely need javascript support
> as I am currently composing this in Gmail  and do quite a bit of
> javscript-based web development :)
>
> On Mon, Apr 18, 2016 at 1:31 PM,  wrote:
>
>> I think the problem is with firefox itself.
>> tedu@ wrote a post about this:
>> http://www.tedunangst.com/flak/post/firefox-vs-rthreads
>>
>> Since the code is so bloated, no one will ever waste time trying to fix
>> all the issues. Just switch to some other browser, there's plenty of
>> options.
>> I'm using Links 2.12 on -stable and it works fine for my needs. But
>> there's also Xombrero if you need javascript support.

Re: Firefox Crashes; slow xfce

[frederick w. soucy]

On 2016.04.18, Daniel Boyd wrote:
> Thanks -- I will give xombrero a shot.  Definitely need javascript support
> as I am currently composing this in Gmail  and do quite a bit of
> javscript-based web development :)
> 
> On Mon, Apr 18, 2016 at 1:31 PM,  wrote:
> 
> > I think the problem is with firefox itself.
> > tedu@ wrote a post about this:
> > http://www.tedunangst.com/flak/post/firefox-vs-rthreads
> >
> > Since the code is so bloated, no one will ever waste time trying to fix
> > all the issues. Just switch to some other browser, there's plenty of
> > options.
> > I'm using Links 2.12 on -stable and it works fine for my needs. But
> > there's also Xombrero if you need javascript support.
> 
there is also vimb which is lightweight and has javascript support.
i find it to be quite faster than xombrero and much easier to setup.
as the name suggests it is made to operate with vim like keybindings
much like the firefox plugin vimperator. this might be a deal breaker
or sealer for some. it also has no tab support but is xembed aware so
you can combine it with the `tabbed` package and run as:

$tabbed -c vimb -e

each tab being its own process is very nice as one page crashing won`t
kill your entire session and closing a tab will free up resources. 

i do like xombrero but it crashes quite often for me and doesn`t seem
to have much development going on. 

Re: Firefox Crashes; slow xfce

[Edgar Pettijohn]

I don't have any problems with Firefox  on -current with Fvwm2. I switched to
Fvwm because Xfce was getting unmanageable. After about a week when I got my
config just right it is much easier and faster than Xfce just not as pretty.

Sent from my iPhone

> On Apr 18, 2016, at 3:13 PM, Daniel Boyd  wrote:
>
> Thanks -- I will give xombrero a shot.  Definitely need javascript support
> as I am currently composing this in Gmail  and do quite a bit of
> javscript-based web development :)
>
>> On Mon, Apr 18, 2016 at 1:31 PM,  wrote:
>>
>> I think the problem is with firefox itself.
>> tedu@ wrote a post about this:
>> http://www.tedunangst.com/flak/post/firefox-vs-rthreads
>>
>> Since the code is so bloated, no one will ever waste time trying to fix
>> all the issues. Just switch to some other browser, there's plenty of
>> options.
>> I'm using Links 2.12 on -stable and it works fine for my needs. But
>> there's also Xombrero if you need javascript support.

Re: Firefox Crashes; slow xfce

[Daniel Boyd]

Thanks -- I will give xombrero a shot.  Definitely need javascript support
as I am currently composing this in Gmail  and do quite a bit of
javscript-based web development :)

On Mon, Apr 18, 2016 at 1:31 PM,  wrote:

> I think the problem is with firefox itself.
> tedu@ wrote a post about this:
> http://www.tedunangst.com/flak/post/firefox-vs-rthreads
>
> Since the code is so bloated, no one will ever waste time trying to fix
> all the issues. Just switch to some other browser, there's plenty of
> options.
> I'm using Links 2.12 on -stable and it works fine for my needs. But
> there's also Xombrero if you need javascript support.

Re: Firefox Crashes; slow xfce

[Daniel Boyd]

> Yes, I did. awesome, and clutter(that comes with gnome. I actually
> installed the gnome DE to just to try this out). To no avail.
>

> Speculating, I'd say that the problem is in X. Where I don't know. But it
> might also be that xfce is involved somehow; both 5.8 and 5.9 uses xfce
> 4.12. IIRC, I installed both awesome and gnome without de-installing xfce.
> It is not completely unthinkable (although unlikely) that they share some
> common parts.
>
> Best regards
> /Birger
>
>
Not familiar with Awesome, but gnome and xfce both use GTK...

Re: Firefox Crashes; slow xfce

[arrowscript]

I think the problem is with firefox itself.
tedu@ wrote a post about this:
http://www.tedunangst.com/flak/post/firefox-vs-rthreads

Since the code is so bloated, no one will ever waste time trying to fix all the 
issues. Just switch to some other browser, there's plenty of options.
I'm using Links 2.12 on -stable and it works fine for my needs. But there's 
also Xombrero if you need javascript support.

Re: Firefox Crashes; slow xfce

[Birger Andersson]

Hi Daniel,

On 2016-04-18 18:30, Daniel Boyd wrote:


I was unable to solve either of the two problems you describe and
obviously did noone else. The proposed solutions later in this thread 
did
nothing to improve the situation in my case. Your first item (the 
crash
fest in 5.8 and 5.9) made me move back to 5.7 which I'm using right 
now. It

comes with xfce 4.10 and firefox-esr 31.4. The desktop is reasonably
stable. Enough to remain productive.

Best regards
/Birger


Are you saying that this is a problem with Xfce and Firefox?  If so, 
might

be worth looking into other window managers...


Yes, I did. awesome, and clutter(that comes with gnome. I actually 
installed the gnome DE to just to try this out). To no avail.


Speculating, I'd say that the problem is in X. Where I don't know. But 
it might also be that xfce is involved somehow; both 5.8 and 5.9 uses 
xfce 4.12. IIRC, I installed both awesome and gnome without 
de-installing xfce. It is not completely unthinkable (although unlikely) 
that they share some common parts.


Best regards
/Birger

Re: Firefox Crashes; slow xfce

[Daniel Boyd]

> I was unable to solve either of the two problems you describe and
> obviously did noone else. The proposed solutions later in this thread did
> nothing to improve the situation in my case. Your first item (the crash
> fest in 5.8 and 5.9) made me move back to 5.7 which I'm using right now. It
> comes with xfce 4.10 and firefox-esr 31.4. The desktop is reasonably
> stable. Enough to remain productive.
>
> Best regards
> /Birger
>
>
Are you saying that this is a problem with Xfce and Firefox?  If so, might
be worth looking into other window managers...

Re: Firefox Crashes; slow xfce

[Daniel Boyd]

I tried this and it didn't seem to have much of an effect, unfortunately.

On Fri, Apr 15, 2016 at 8:48 PM,  wrote:

> Try to raise your aperture driver level to give your gpu more privileges:
>
> # sysctl machdep.allowaperture=2
>
> You can read more about the other levels on man pages (type "man xf86").

Re: Firefox Crashes; slow xfce

[Birger Andersson]

Hi Daniel,

On 2016-04-15 20:11, Daniel Boyd wrote:

I have noticed a pattern lately.  When I open LibreOffice or Evince,
Firefox crashes -- like pretty regularly.  I switched from using Calc 
to
Gnumeric and that has helped some, but having my browser crash 10-15 
times

a day is not good for productivity.

I've been using OpenBSD (first 5.8 and now 5.9) on my primary work 
machine

for a couple months now.  I am largely very happy with things, but I'm
hopeful I can figure out a solution to this.

In addition, the LibreOffice 5 build in 5.9 crashed so much on me last 
week

as to not be usable.  I don't use LibreOffice super often, but I don't
recall having any issues like that with the 4.x build that ran on 5.8.


You are not alone...

http://marc.info/?l=openbsd-bugs=14547010926=2

Switching to Chromium will not help. Quite the contrary.



And, lastly dragging windows in xfce is *slow*.  This isn't a new 
computer,
but it's got a Radeon HD 7770.  I am running dual 2560x1440 monitors 
which

is a lot of pixels, but I think that card should be capable of handling
it.


You are not alone... I guess sound gets muted when you drag those slow 
windows too, right.


http://marc.info/?t=14528853021=1=2

I was unable to solve either of the two problems you describe and 
obviously did noone else. The proposed solutions later in this thread 
did nothing to improve the situation in my case. Your first item (the 
crash fest in 5.8 and 5.9) made me move back to 5.7 which I'm using 
right now. It comes with xfce 4.10 and firefox-esr 31.4. The desktop is 
reasonably stable. Enough to remain productive.


Best regards
/Birger




I'm not sure what all log/configuration files etc to post, so I'll just 
do

dmesg, Xorg.0.log, and login.conf

dmesg:
OpenBSD 5.9 (GENERIC.MP) #1: Thu Mar 31 12:53:41 CEST 2016
jas...@stable-59-amd64.mtier.org:
/binpatchng/work-binpatch59-amd64/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8564244480 (8167MB)
avail mem = 8300490752 (7915MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xf0720 (77 entries)
bios0: vendor American Megatrends Inc. version "0711" date 05/18/2009
bios0: ASUSTeK Computer INC. P6T WS PRO
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG OEMB HPET OSFR SSDT
acpi0: wakeup devices NPE2(S4) NPE4(S4) NPE5(S4) NPE6(S4) NPE8(S4) 
NPE9(S4)

NPEA(S4) P0P1(S4) PS2K(S4) PS2M(S4) USB0(S4) USB1(S4) USB2(S4) USB5(S4)
EUSB(S4) USB3(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU E5506 @ 2.13GHz, 2138.51 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF,PERF,ITSC,SENSOR
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 136MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU E5506 @ 2.13GHz, 2180.95 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF,PERF,ITSC,SENSOR
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Xeon(R) CPU E5506 @ 2.13GHz, 2180.95 MHz
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF,PERF,ITSC,SENSOR
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Xeon(R) CPU E5506 @ 2.13GHz, 2180.95 MHz
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF,PERF,ITSC,SENSOR
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 8, remapped to apid 1
ioapic1 at mainbus0: apid 3 pa 0xfec8a000, version 20, 24 pins
ioapic1: misconfigured as apic 9, remapped to apid 3
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (NPE2)
acpiprt2 at acpi0: bus -1 (NPE4)
acpiprt3 at acpi0: bus -1 (NPE5)
acpiprt4 at acpi0: bus -1 (NPE6)
acpiprt5 at acpi0: bus -1 (NPE8)
acpiprt6 at acpi0: bus -1 (NPE9)
acpiprt7 at acpi0: bus -1 (NPEA)
acpiprt8 at acpi0: bus 10 

Re: Firefox Crashes; slow xfce

[arrowscript]

Try to raise your aperture driver level to give your gpu more privileges:

# sysctl machdep.allowaperture=2

You can read more about the other levels on man pages (type "man xf86").

Re: Firefox Crashes; slow xfce

[Daniel Boyd]

hm.. What about the slow xfce?  Does anyone else have issues dragging
windows around with high-res monitors?  Anyone else using a Radeon HD 7770?

On Fri, Apr 15, 2016 at 5:15 PM, Daniel Jakots  wrote:

> On Fri, 15 Apr 2016 13:11:39 -0500, Daniel Boyd 
> wrote:
>
> > I have noticed a pattern lately.  When I open LibreOffice or Evince,
> > Firefox crashes -- like pretty regularly.
>
> FWIW, more than 90% of times I launch smplayer to play a movie, firefox
> dies and it really looks it's 'disk-usage' related.
>
> *shrug*

Re: Firefox Crashes; slow xfce

[Daniel Boyd]

yeah -- my effective data limit is (and has been ) 3500M

this this might be indicative of bad memory (like physically?)

On Fri, Apr 15, 2016 at 3:28 PM, Donald Allen 
wrote:

> On Fri, Apr 15, 2016 at 4:24 PM, Daniel Boyd  wrote:
> > I had my datasize up under 'staff' which I believe should cover my user
> > account.  How do I find out what my effective datasize limit is?  Is it
> > possible that some processes would be bound by 'default' and others by
> > 'staff?'
>
> ulimit -a
>
> >
> > On Fri, Apr 15, 2016 at 1:34 PM, Donald Allen 
> > wrote:
> >>
> >> On Fri, Apr 15, 2016 at 2:11 PM, Daniel Boyd 
> wrote:
> >> > I have noticed a pattern lately.  When I open LibreOffice or Evince,
> >> > Firefox crashes -- like pretty regularly.  I switched from using Calc
> to
> >> > Gnumeric and that has helped some, but having my browser crash 10-15
> >> > times
> >> > a day is not good for productivity.
> >>
> >> My guess is that Firefox is running out of memory. I had similar
> >> problems and this change to /etc/login.conf made firefox reliable:
> >>
> >> # Sample login.conf file.  See login.conf(5) for details.
> >> @@ -41,14 +41,13 @@ auth-ftp-defaults:auth-ftp=passwd:
> >>  default:\
> >> :path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin
> >> /usr/local/bin /usr/local/sbin:\
> >> :umask=022:\
> >> -   :datasize-max=512M:\
> >> -   :datasize-cur=512M:\
> >> +   :datasize-max=2048M:\
> >> +   :datasize-cur=2048M:\
> >>
> >> >
> >> > I've been using OpenBSD (first 5.8 and now 5.9) on my primary work
> >> > machine
> >> > for a couple months now.  I am largely very happy with things, but I'm
> >> > hopeful I can figure out a solution to this.
> >> >
> >> > In addition, the LibreOffice 5 build in 5.9 crashed so much on me last
> >> > week
> >> > as to not be usable.  I don't use LibreOffice super often, but I don't
> >> > recall having any issues like that with the 4.x build that ran on 5.8.
> >> >
> >> > And, lastly dragging windows in xfce is *slow*.  This isn't a new
> >> > computer,
> >> > but it's got a Radeon HD 7770.  I am running dual 2560x1440 monitors
> >> > which
> >> > is a lot of pixels, but I think that card should be capable of
> handling
> >> > it.
> >> >
> >> > I'm not sure what all log/configuration files etc to post, so I'll
> just
> >> > do
> >> > dmesg, Xorg.0.log, and login.conf
> >> >
> >> > dmesg:
> >> > OpenBSD 5.9 (GENERIC.MP) #1: Thu Mar 31 12:53:41 CEST 2016
> >> > jas...@stable-59-amd64.mtier.org:
> >> > /binpatchng/work-binpatch59-amd64/src/sys/arch/amd64/compile/
> GENERIC.MP
> >> > real mem = 8564244480 (8167MB)
> >> > avail mem = 8300490752 (7915MB)
> >> > mpath0 at root
> >> > scsibus0 at mpath0: 256 targets
> >> > mainbus0 at root
> >> > bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xf0720 (77 entries)
> >> > bios0: vendor American Megatrends Inc. version "0711" date 05/18/2009
> >> > bios0: ASUSTeK Computer INC. P6T WS PRO
> >> > acpi0 at bios0: rev 0
> >> > acpi0: sleep states S0 S1 S3 S4 S5
> >> > acpi0: tables DSDT FACP APIC MCFG OEMB HPET OSFR SSDT
> >> > acpi0: wakeup devices NPE2(S4) NPE4(S4) NPE5(S4) NPE6(S4) NPE8(S4)
> >> > NPE9(S4)
> >> > NPEA(S4) P0P1(S4) PS2K(S4) PS2M(S4) USB0(S4) USB1(S4) USB2(S4)
> USB5(S4)
> >> > EUSB(S4) USB3(S4) [...]
> >> > acpitimer0 at acpi0: 3579545 Hz, 24 bits
> >> > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> >> > cpu0 at mainbus0: apid 0 (boot processor)
> >> > cpu0: Intel(R) Xeon(R) CPU E5506 @ 2.13GHz, 2138.51 MHz
> >> > cpu0:
> >> >
> >> >
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF,PERF,ITSC,SENSOR
> >> > cpu0: 256KB 64b/line 8-way L2 cache
> >> > cpu0: smt 0, core 0, package 0
> >> > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> >> > cpu0: apic clock running at 136MHz
> >> > cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
> >> > cpu1 at mainbus0: apid 2 (application processor)
> >> > cpu1: Intel(R) Xeon(R) CPU E5506 @ 2.13GHz, 2180.95 MHz
> >> > cpu1:
> >> >
> >> >
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF,PERF,ITSC,SENSOR
> >> > cpu1: 256KB 64b/line 8-way L2 cache
> >> > cpu1: smt 0, core 1, package 0
> >> > cpu2 at mainbus0: apid 4 (application processor)
> >> > cpu2: Intel(R) Xeon(R) CPU E5506 @ 2.13GHz, 2180.95 MHz
> >> > cpu2:
> >> >
> >> >
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF,PERF,ITSC,SENSOR
> >> > cpu2: 256KB 64b/line 8-way L2 cache
> >> > cpu2: smt 0, core 

Re: Firefox Crashes; slow xfce

[Daniel Jakots]

On Fri, 15 Apr 2016 13:11:39 -0500, Daniel Boyd 
wrote:

> I have noticed a pattern lately.  When I open LibreOffice or Evince,
> Firefox crashes -- like pretty regularly.

FWIW, more than 90% of times I launch smplayer to play a movie, firefox
dies and it really looks it's 'disk-usage' related.

*shrug*

Re: Firefox Crashes; slow xfce

[Daniel Boyd]

I had my datasize up under 'staff' which I believe should cover my user
account.  How do I find out what my effective datasize limit is?  Is it
possible that some processes would be bound by 'default' and others by
'staff?'

On Fri, Apr 15, 2016 at 1:34 PM, Donald Allen 
wrote:

> On Fri, Apr 15, 2016 at 2:11 PM, Daniel Boyd  wrote:
> > I have noticed a pattern lately.  When I open LibreOffice or Evince,
> > Firefox crashes -- like pretty regularly.  I switched from using Calc to
> > Gnumeric and that has helped some, but having my browser crash 10-15
> times
> > a day is not good for productivity.
>
> My guess is that Firefox is running out of memory. I had similar
> problems and this change to /etc/login.conf made firefox reliable:
>
> # Sample login.conf file.  See login.conf(5) for details.
> @@ -41,14 +41,13 @@ auth-ftp-defaults:auth-ftp=passwd:
>  default:\
> :path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin
> /usr/local/bin /usr/local/sbin:\
> :umask=022:\
> -   :datasize-max=512M:\
> -   :datasize-cur=512M:\
> +   :datasize-max=2048M:\
> +   :datasize-cur=2048M:\
>
> >
> > I've been using OpenBSD (first 5.8 and now 5.9) on my primary work
> machine
> > for a couple months now.  I am largely very happy with things, but I'm
> > hopeful I can figure out a solution to this.
> >
> > In addition, the LibreOffice 5 build in 5.9 crashed so much on me last
> week
> > as to not be usable.  I don't use LibreOffice super often, but I don't
> > recall having any issues like that with the 4.x build that ran on 5.8.
> >
> > And, lastly dragging windows in xfce is *slow*.  This isn't a new
> computer,
> > but it's got a Radeon HD 7770.  I am running dual 2560x1440 monitors
> which
> > is a lot of pixels, but I think that card should be capable of handling
> > it.
> >
> > I'm not sure what all log/configuration files etc to post, so I'll just
> do
> > dmesg, Xorg.0.log, and login.conf
> >
> > dmesg:
> > OpenBSD 5.9 (GENERIC.MP) #1: Thu Mar 31 12:53:41 CEST 2016
> > jas...@stable-59-amd64.mtier.org:
> > /binpatchng/work-binpatch59-amd64/src/sys/arch/amd64/compile/GENERIC.MP
> > real mem = 8564244480 (8167MB)
> > avail mem = 8300490752 (7915MB)
> > mpath0 at root
> > scsibus0 at mpath0: 256 targets
> > mainbus0 at root
> > bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xf0720 (77 entries)
> > bios0: vendor American Megatrends Inc. version "0711" date 05/18/2009
> > bios0: ASUSTeK Computer INC. P6T WS PRO
> > acpi0 at bios0: rev 0
> > acpi0: sleep states S0 S1 S3 S4 S5
> > acpi0: tables DSDT FACP APIC MCFG OEMB HPET OSFR SSDT
> > acpi0: wakeup devices NPE2(S4) NPE4(S4) NPE5(S4) NPE6(S4) NPE8(S4)
> NPE9(S4)
> > NPEA(S4) P0P1(S4) PS2K(S4) PS2M(S4) USB0(S4) USB1(S4) USB2(S4) USB5(S4)
> > EUSB(S4) USB3(S4) [...]
> > acpitimer0 at acpi0: 3579545 Hz, 24 bits
> > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> > cpu0 at mainbus0: apid 0 (boot processor)
> > cpu0: Intel(R) Xeon(R) CPU E5506 @ 2.13GHz, 2138.51 MHz
> > cpu0:
> >
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF,PERF,ITSC,SENSOR
> > cpu0: 256KB 64b/line 8-way L2 cache
> > cpu0: smt 0, core 0, package 0
> > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> > cpu0: apic clock running at 136MHz
> > cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
> > cpu1 at mainbus0: apid 2 (application processor)
> > cpu1: Intel(R) Xeon(R) CPU E5506 @ 2.13GHz, 2180.95 MHz
> > cpu1:
> >
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF,PERF,ITSC,SENSOR
> > cpu1: 256KB 64b/line 8-way L2 cache
> > cpu1: smt 0, core 1, package 0
> > cpu2 at mainbus0: apid 4 (application processor)
> > cpu2: Intel(R) Xeon(R) CPU E5506 @ 2.13GHz, 2180.95 MHz
> > cpu2:
> >
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF,PERF,ITSC,SENSOR
> > cpu2: 256KB 64b/line 8-way L2 cache
> > cpu2: smt 0, core 2, package 0
> > cpu3 at mainbus0: apid 6 (application processor)
> > cpu3: Intel(R) Xeon(R) CPU E5506 @ 2.13GHz, 2180.95 MHz
> > cpu3:
> >
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF,PERF,ITSC,SENSOR
> > cpu3: 256KB 64b/line 8-way L2 cache
> > cpu3: smt 0, core 3, package 0
> > ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
> > ioapic0: misconfigured as apic 8, remapped to apid 1
> > ioapic1 at mainbus0: apid 3 pa 0xfec8a000, 

Re: Firefox Crashes; slow xfce

[Donald Allen]

On Fri, Apr 15, 2016 at 4:24 PM, Daniel Boyd  wrote:
> I had my datasize up under 'staff' which I believe should cover my user
> account.  How do I find out what my effective datasize limit is?  Is it
> possible that some processes would be bound by 'default' and others by
> 'staff?'

ulimit -a

>
> On Fri, Apr 15, 2016 at 1:34 PM, Donald Allen 
> wrote:
>>
>> On Fri, Apr 15, 2016 at 2:11 PM, Daniel Boyd  wrote:
>> > I have noticed a pattern lately.  When I open LibreOffice or Evince,
>> > Firefox crashes -- like pretty regularly.  I switched from using Calc to
>> > Gnumeric and that has helped some, but having my browser crash 10-15
>> > times
>> > a day is not good for productivity.
>>
>> My guess is that Firefox is running out of memory. I had similar
>> problems and this change to /etc/login.conf made firefox reliable:
>>
>> # Sample login.conf file.  See login.conf(5) for details.
>> @@ -41,14 +41,13 @@ auth-ftp-defaults:auth-ftp=passwd:
>>  default:\
>> :path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin
>> /usr/local/bin /usr/local/sbin:\
>> :umask=022:\
>> -   :datasize-max=512M:\
>> -   :datasize-cur=512M:\
>> +   :datasize-max=2048M:\
>> +   :datasize-cur=2048M:\
>>
>> >
>> > I've been using OpenBSD (first 5.8 and now 5.9) on my primary work
>> > machine
>> > for a couple months now.  I am largely very happy with things, but I'm
>> > hopeful I can figure out a solution to this.
>> >
>> > In addition, the LibreOffice 5 build in 5.9 crashed so much on me last
>> > week
>> > as to not be usable.  I don't use LibreOffice super often, but I don't
>> > recall having any issues like that with the 4.x build that ran on 5.8.
>> >
>> > And, lastly dragging windows in xfce is *slow*.  This isn't a new
>> > computer,
>> > but it's got a Radeon HD 7770.  I am running dual 2560x1440 monitors
>> > which
>> > is a lot of pixels, but I think that card should be capable of handling
>> > it.
>> >
>> > I'm not sure what all log/configuration files etc to post, so I'll just
>> > do
>> > dmesg, Xorg.0.log, and login.conf
>> >
>> > dmesg:
>> > OpenBSD 5.9 (GENERIC.MP) #1: Thu Mar 31 12:53:41 CEST 2016
>> > jas...@stable-59-amd64.mtier.org:
>> > /binpatchng/work-binpatch59-amd64/src/sys/arch/amd64/compile/GENERIC.MP
>> > real mem = 8564244480 (8167MB)
>> > avail mem = 8300490752 (7915MB)
>> > mpath0 at root
>> > scsibus0 at mpath0: 256 targets
>> > mainbus0 at root
>> > bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xf0720 (77 entries)
>> > bios0: vendor American Megatrends Inc. version "0711" date 05/18/2009
>> > bios0: ASUSTeK Computer INC. P6T WS PRO
>> > acpi0 at bios0: rev 0
>> > acpi0: sleep states S0 S1 S3 S4 S5
>> > acpi0: tables DSDT FACP APIC MCFG OEMB HPET OSFR SSDT
>> > acpi0: wakeup devices NPE2(S4) NPE4(S4) NPE5(S4) NPE6(S4) NPE8(S4)
>> > NPE9(S4)
>> > NPEA(S4) P0P1(S4) PS2K(S4) PS2M(S4) USB0(S4) USB1(S4) USB2(S4) USB5(S4)
>> > EUSB(S4) USB3(S4) [...]
>> > acpitimer0 at acpi0: 3579545 Hz, 24 bits
>> > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
>> > cpu0 at mainbus0: apid 0 (boot processor)
>> > cpu0: Intel(R) Xeon(R) CPU E5506 @ 2.13GHz, 2138.51 MHz
>> > cpu0:
>> >
>> > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF,PERF,ITSC,SENSOR
>> > cpu0: 256KB 64b/line 8-way L2 cache
>> > cpu0: smt 0, core 0, package 0
>> > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
>> > cpu0: apic clock running at 136MHz
>> > cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
>> > cpu1 at mainbus0: apid 2 (application processor)
>> > cpu1: Intel(R) Xeon(R) CPU E5506 @ 2.13GHz, 2180.95 MHz
>> > cpu1:
>> >
>> > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF,PERF,ITSC,SENSOR
>> > cpu1: 256KB 64b/line 8-way L2 cache
>> > cpu1: smt 0, core 1, package 0
>> > cpu2 at mainbus0: apid 4 (application processor)
>> > cpu2: Intel(R) Xeon(R) CPU E5506 @ 2.13GHz, 2180.95 MHz
>> > cpu2:
>> >
>> > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF,PERF,ITSC,SENSOR
>> > cpu2: 256KB 64b/line 8-way L2 cache
>> > cpu2: smt 0, core 2, package 0
>> > cpu3 at mainbus0: apid 6 (application processor)
>> > cpu3: Intel(R) Xeon(R) CPU E5506 @ 2.13GHz, 2180.95 MHz
>> > cpu3:
>> >
>> > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF,PERF,ITSC,SENSOR
>> > cpu3: 256KB 64b/line 8-way L2 

Re: Firefox Crashes; slow xfce

[Donald Allen]

On Fri, Apr 15, 2016 at 2:11 PM, Daniel Boyd  wrote:
> I have noticed a pattern lately.  When I open LibreOffice or Evince,
> Firefox crashes -- like pretty regularly.  I switched from using Calc to
> Gnumeric and that has helped some, but having my browser crash 10-15 times
> a day is not good for productivity.

My guess is that Firefox is running out of memory. I had similar
problems and this change to /etc/login.conf made firefox reliable:

# Sample login.conf file.  See login.conf(5) for details.
@@ -41,14 +41,13 @@ auth-ftp-defaults:auth-ftp=passwd:
 default:\
:path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin
/usr/local/bin /usr/local/sbin:\
:umask=022:\
-   :datasize-max=512M:\
-   :datasize-cur=512M:\
+   :datasize-max=2048M:\
+   :datasize-cur=2048M:\

>
> I've been using OpenBSD (first 5.8 and now 5.9) on my primary work machine
> for a couple months now.  I am largely very happy with things, but I'm
> hopeful I can figure out a solution to this.
>
> In addition, the LibreOffice 5 build in 5.9 crashed so much on me last week
> as to not be usable.  I don't use LibreOffice super often, but I don't
> recall having any issues like that with the 4.x build that ran on 5.8.
>
> And, lastly dragging windows in xfce is *slow*.  This isn't a new computer,
> but it's got a Radeon HD 7770.  I am running dual 2560x1440 monitors which
> is a lot of pixels, but I think that card should be capable of handling
> it.
>
> I'm not sure what all log/configuration files etc to post, so I'll just do
> dmesg, Xorg.0.log, and login.conf
>
> dmesg:
> OpenBSD 5.9 (GENERIC.MP) #1: Thu Mar 31 12:53:41 CEST 2016
> jas...@stable-59-amd64.mtier.org:
> /binpatchng/work-binpatch59-amd64/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 8564244480 (8167MB)
> avail mem = 8300490752 (7915MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xf0720 (77 entries)
> bios0: vendor American Megatrends Inc. version "0711" date 05/18/2009
> bios0: ASUSTeK Computer INC. P6T WS PRO
> acpi0 at bios0: rev 0
> acpi0: sleep states S0 S1 S3 S4 S5
> acpi0: tables DSDT FACP APIC MCFG OEMB HPET OSFR SSDT
> acpi0: wakeup devices NPE2(S4) NPE4(S4) NPE5(S4) NPE6(S4) NPE8(S4) NPE9(S4)
> NPEA(S4) P0P1(S4) PS2K(S4) PS2M(S4) USB0(S4) USB1(S4) USB2(S4) USB5(S4)
> EUSB(S4) USB3(S4) [...]
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Xeon(R) CPU E5506 @ 2.13GHz, 2138.51 MHz
> cpu0:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF,PERF,ITSC,SENSOR
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 136MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Xeon(R) CPU E5506 @ 2.13GHz, 2180.95 MHz
> cpu1:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF,PERF,ITSC,SENSOR
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0: apid 4 (application processor)
> cpu2: Intel(R) Xeon(R) CPU E5506 @ 2.13GHz, 2180.95 MHz
> cpu2:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF,PERF,ITSC,SENSOR
> cpu2: 256KB 64b/line 8-way L2 cache
> cpu2: smt 0, core 2, package 0
> cpu3 at mainbus0: apid 6 (application processor)
> cpu3: Intel(R) Xeon(R) CPU E5506 @ 2.13GHz, 2180.95 MHz
> cpu3:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF,PERF,ITSC,SENSOR
> cpu3: 256KB 64b/line 8-way L2 cache
> cpu3: smt 0, core 3, package 0
> ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
> ioapic0: misconfigured as apic 8, remapped to apid 1
> ioapic1 at mainbus0: apid 3 pa 0xfec8a000, version 20, 24 pins
> ioapic1: misconfigured as apic 9, remapped to apid 3
> acpimcfg0 at acpi0 addr 0xe000, bus 0-255
> acpihpet0 at acpi0: 14318179 Hz
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus -1 (NPE2)
> acpiprt2 at acpi0: bus -1 (NPE4)
> acpiprt3 at acpi0: bus -1 (NPE5)
> acpiprt4 at acpi0: bus -1 (NPE6)
> acpiprt5 at acpi0: bus -1 (NPE8)
> acpiprt6 at acpi0: bus -1 (NPE9)
> acpiprt7 at acpi0: bus -1 (NPEA)
> acpiprt8 at acpi0: bus 10 (P0P1)
> acpiprt9 at acpi0: bus 9 

Firefox Crashes; slow xfce

[Daniel Boyd]

I have noticed a pattern lately.  When I open LibreOffice or Evince,
Firefox crashes -- like pretty regularly.  I switched from using Calc to
Gnumeric and that has helped some, but having my browser crash 10-15 times
a day is not good for productivity.

I've been using OpenBSD (first 5.8 and now 5.9) on my primary work machine
for a couple months now.  I am largely very happy with things, but I'm
hopeful I can figure out a solution to this.

In addition, the LibreOffice 5 build in 5.9 crashed so much on me last week
as to not be usable.  I don't use LibreOffice super often, but I don't
recall having any issues like that with the 4.x build that ran on 5.8.

And, lastly dragging windows in xfce is *slow*.  This isn't a new computer,
but it's got a Radeon HD 7770.  I am running dual 2560x1440 monitors which
is a lot of pixels, but I think that card should be capable of handling
it.

I'm not sure what all log/configuration files etc to post, so I'll just do
dmesg, Xorg.0.log, and login.conf

dmesg:
OpenBSD 5.9 (GENERIC.MP) #1: Thu Mar 31 12:53:41 CEST 2016
jas...@stable-59-amd64.mtier.org:
/binpatchng/work-binpatch59-amd64/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8564244480 (8167MB)
avail mem = 8300490752 (7915MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xf0720 (77 entries)
bios0: vendor American Megatrends Inc. version "0711" date 05/18/2009
bios0: ASUSTeK Computer INC. P6T WS PRO
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG OEMB HPET OSFR SSDT
acpi0: wakeup devices NPE2(S4) NPE4(S4) NPE5(S4) NPE6(S4) NPE8(S4) NPE9(S4)
NPEA(S4) P0P1(S4) PS2K(S4) PS2M(S4) USB0(S4) USB1(S4) USB2(S4) USB5(S4)
EUSB(S4) USB3(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU E5506 @ 2.13GHz, 2138.51 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF,PERF,ITSC,SENSOR
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 136MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU E5506 @ 2.13GHz, 2180.95 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF,PERF,ITSC,SENSOR
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Xeon(R) CPU E5506 @ 2.13GHz, 2180.95 MHz
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF,PERF,ITSC,SENSOR
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Xeon(R) CPU E5506 @ 2.13GHz, 2180.95 MHz
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF,PERF,ITSC,SENSOR
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 8, remapped to apid 1
ioapic1 at mainbus0: apid 3 pa 0xfec8a000, version 20, 24 pins
ioapic1: misconfigured as apic 9, remapped to apid 3
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (NPE2)
acpiprt2 at acpi0: bus -1 (NPE4)
acpiprt3 at acpi0: bus -1 (NPE5)
acpiprt4 at acpi0: bus -1 (NPE6)
acpiprt5 at acpi0: bus -1 (NPE8)
acpiprt6 at acpi0: bus -1 (NPE9)
acpiprt7 at acpi0: bus -1 (NPEA)
acpiprt8 at acpi0: bus 10 (P0P1)
acpiprt9 at acpi0: bus 9 (P0P4)
acpiprt10 at acpi0: bus 8 (P0P5)
acpiprt11 at acpi0: bus 7 (P0P6)
acpiprt12 at acpi0: bus 6 (P0P7)
acpiprt13 at acpi0: bus -1 (P0P8)
acpiprt14 at acpi0: bus -1 (P0P9)
acpiprt15 at acpi0: bus 1 (NPE1)
acpiprt16 at acpi0: bus 3 (PXHA)
acpiprt17 at acpi0: bus 4 (NPE3)
acpiprt18 at acpi0: bus 5 (NPE7)
acpicpu0 at acpi0: C1(@1 halt!), PSS
acpicpu1 at acpi0: C1(@1 halt!), PSS
acpicpu2 at acpi0: C1(@1 halt!), PSS
acpicpu3 at acpi0: C1(@1 halt!), PSS
aibs0 at acpi0 RTMP RVLT RFAN GGRP GITM SITM
acpibtn0 at acpi0: PWRB
cpu0: Enhanced SpeedStep 2138 MHz: speeds: 2133, 2000, 1867, 1733, 1600 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel X58 Host" rev 0x13
ppb0 at pci0 dev 1 function 0 "Intel X58 PCIE" rev