Tuesday, November 15, 2011 3:10AM Jonathan Nieder wrote:
>
>Hi,
>
>Will Set
wrote:
>
>- you have tested some 3.1.0-1-686-pae kernel (I assume
> 3.1.0-1~experimental.1 from experimental).
Yes, 3.1.0-1~experimental.1 from experimental
>- unless you add "processor.nocst=1", it reliably hangs at boot time.
>- adding "processor.nocst=1" makes it boot without hanging.
>- in addition to this machine, you have another machine that has an
> i865 chipset. It produces the same symptoms.
>- in addition, you have a machine with an i915 chipset, which works
> fine, with no need for special boot parameters.
Yes.
>
>In the bug log, I see:
>
>- this is an Acer Aspire One AO521, board JV01-NL, BIOS v1.08
>- the chipset is indeed an 82865G
>- oopses are all over the place. Feels like corruption somewhere.
>- with debug=3, we see that the DMI
says this is board D865GRH, BIOS
> BF86510A.86A.0077.P25.0508040031 --- wait, are these even the same
> machine?
>- the other i865 is D865PERLK.
What I have gathered so far from reading docs and reports
it looks like a C state problem.
I think there isn't a CST in this processor...
If CST adjusts processor voltage and stepping for energy saving when idle?
I;m thinking legacy FADT is all this chip can use..
It's not a big deal for me to use the workaround Len Brown suggested
https://bugzilla.redhat.com/show_bug.cgi?id=727865#c16
for 2.6.38-rc and newer kernels. --->
Debian stable / 2.6.32-5-686 kernel still works fine.
And I'm still OK if it's an upstream ( will not fix issue).
But I would like a fix as well, if one is possible.
>
>Ok. The processor.nocst=1 workaround indicates that the ACPI
tables
>might be incorrect or being incorrectly parsed. For the D865GBF, such
>a problem is being tracked as bug#630031 and upstream bug 38262.
>Compare v2.6.22-rc1~1112^2^2 (ACPICA: clear fields reserved before
>FADT r3, 2007-04-28). To move forward on that, the right thing to do
>would be to get in touch with Len Brown, for example by answering his
>questions from the Fedora bugtracker at
><
https://bugzilla.redhat.com/show_bug.cgi?id=727865>.
All my answers to Len Browns questions are identical to
Adam 's https://bugzilla.redhat.com/show_bug.cgi?id=727865#c17
answers to Len Browns questions.
$ grep . /sys/devices/system/cpu/cpu0/cpuidle/*/* --> doesn't exis
t.
$ /sys/firmware/acpi/tables/dynamic/* --> doesn't exist in the filesystem.
>
>For the D865PERLK, a quick web search does not show anyone but you
>having this problem.
>
>You've said you have three boards you're checking with and only two
>exhibit the problem. I'm not sure where the JV01-NL fits into the
>picture.
I'm not sure how the JV01-NL got into the picture either.
>
>Anyway, for the future, it would be way less confusing to have one bug
>per machine,
Yes, I agree
100%
>unless they are identically configured or we can
be
>reasonably certain for some other reason that the
same fix will apply
>to all of them.
Yes, at this preliminary stage, I think the issue is exactly the same,
or at least close enough, on my two Intel 865 chipset machines.
Even though the two mobos are not identical,
the processors, memory and disks are identical in both machines.
>Please provide a summary of which machines that you
>use are affected and not affected, and I can clone this bug and let
>you know the bug number assigned to each.
I will file a separate bug report from the other machine.
>
>Thanks for your help and patience.
>
>Regards,
>Jonathan
Best Regards,
Will