> Date: Tue, 9 Sep 2014 19:27:42 +0200
> From: Ingo Schwarze <schwa...@usta.de>
> 
> Hi Mark,
> 
> Mark Kettenis wrote on Mon, Sep 08, 2014 at 11:35:36PM +0200:
> 
> > The more code & documentation I read, the more I'm convinced that
> > coordinating state changes between logical processors isn't necessary
> > and actually is responsible for the hangs people have been seeing.
> > 
> > So here is a diff that does away with it all.  I've tested it on a few
> > laptops here, but it could use testing on a somewhat wider range of
> > machines.  I'm especially interested in seeing this tested on a dual
> > socket machine with apmd -A.
> 
> i'm sorry to say it makes no difference for me (i'm not opposed to the
> diff, though).
> 
> On my laptop, building ports works fine, running firefox works fine,
> but whenever i surf the web with firefox while building ports,
> the machine locks up hard.  Sometimes, the lockup already happens
> when merely starting firefox while building ports.  Often, it
> happens not when requesting a new URI, but when merely scrolling
> within the page in firefox.
> 
> After the lockup, CapsLk and NmLk still toggle the respective LEDs,
> Fn-PgUp still switches on and off the torch, but nothing else has
> any effect, not even Ctrl-Alt-Esc, Ctrl-Alt-Delete, Ctrl-Alt-Backspace
> or Ctrl-Alt-F1.
> 
> Unfortunately, i cannot break into ddb because i don't have a
> docking station, hence no serial console, and when going to the
> PC virtual console (Ctrl-Alt-F1), setting export DISPLAY=:0,
> and starting firefox from the console, i was unable to get any
> lockup.  Apparently, it only happens when X (or whatever) is
> actually painting something onto the screen.
> 
> Whether i run with the defaults or with apm -A doesn't appear to
> make a difference.

Not sure what you mean with "defaults", but if the crashes happen even
in "manual performance adjustment mode", this diff certainly won't
magically fix things.

Reply via email to