On 1 September 2013 14:35, Andriy Gapon <a...@freebsd.org> wrote:

> Do you have any evidence that there is anybody else besides Mike who has
> this
> problem?
>


Nope! but we can't assume that users are reporting all the system slowdowns.

And honestly, I've heard enough strange stories on mailing lists and IRC of
things like "during disk IO, blah would be really slow, when I change
timekeeping or halt from ACPI to something else, things get better." So I
can't discount that this is affecting people and they either don't know, or
just chalk it up as "shitty hardware."

Also, I usually try to "sort out" things after there is a clear
> understanding of
> what the problem is and how it should be fixed.
>
>
Well, the big change is that it's now going into a sleep state on a HT
core, right?

Are you able to go into an ACPI sleep state on a HT logical CPU, rather
than the physical core? Or am I mis-understanding what's going on?



> > Reverting and fixing it later seems like the safest option to me. Is
> there a
> > bigger problem that you tried to fix in that patch that wasn't as
> obvious?
>
> I do not see any problem with the code*.*  I do not see any explanation of
> the
> root cause of the problem that Mike has.  I do not see why anything has to
> be
> reverted.  Especially because "since we're so close to 9.2-REL".
> Just in case, I'll remind that the commit in question is in stable/9 since
> Dec
> 23 2012.
>
>
Right, but I also know a lot of people who just have stayed with 8.x or
9.0-RELEASE and haven't bothered upgrading. Again, I can't assume that
everyone has been keeping up to date with stable/9 and providing feedback.

Thanks,


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

Reply via email to