Sunday, December 25, 2011 4:24 AM Jonathan Nieder wrote: >Will Set wrote:
>> Jonathan Nieder wrote
>
>>> but the boot fails in some way unless you
>>> add processor.nocst=1 to the kernel command line.
>>
>> Yes,
>> Adding processor.nocst=1 has always worked for me on all effected kernels I've tested so far.
>[...]
>>> This is
on the machine with a D865GBF motherboard.
>>
>> No,
>> This report is and always will be Intel D865GRH mobo.
>
>Sorry for the typo, and thanks for the corrections.
>
>Excellent --- I suspect that udev is actually a red herring and that
>_any_ code executed during the early boot process is likely to
>misbehave or segfault on this machine unless processor.nocst=1 is
>passed.
>
>In other words, this looks like incorrect execution or memory
>corruption during boot. Which is consistent with a broken _CST table.
>
>Unfortunately the acpidump you sent does not include a _CST table.
>The log you sent does not include any complaints about lack of a _CST
>table, though. Puzzling.
>
>I recommend keeping processor.nocst=1 on the kernel command line for
>now. We should report this upstream to Len Brown and
the
>linux-acpi@vger.kernel.org list, but I would like to delay that until
>after the holidays to avoid overwhelming them.
>
>> There is another Debian user that has an Intel D865GBF mobo
>> with a "very" similar debian bug report filed.
>>
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631597
>
>Does disabling hyperthreading in the BIOS avoid trouble for you, too?
Yes, when I disable hyperthreading in the BIOS the machine boots normally.
Please take my findings today with a grain of salt, because of my testing methods used.
I had to test using 3.1.0-1-686-pae
( which I believe is an old experiemtnal kernel and not a sid or wheezy kernel)
I rebooted 3.1.0-1-686-pae 10 times with hyperthreading enabled,
and got 10 different dmesg problems very
near if not exactly while
udev was populating /dev
So, I than disabled hyperthreading in the BIOS and rebooted 4 or 5 times.
With hyperthreading disabled I still see a 30 second timeout :
[ 7.014167] snd_intel8x0 0000:00:1f.5: PCI INT B -> GSI 17 (level, low) -> IRQ 17
[ 7.016968] snd_intel8x0 0000:00:1f.5: setting latency timer to 64
[ 7.476075] intel8x0_measure_ac97_clock: measured 54401 usecs (2621 samples)
[ 7.478973] intel8x0: clocking to 48000
here while udev finishes populating /dev
But, the boot looks normal to me and I'm using it in this xsession with hyperthreading disabled.
Best Regards,
Will
attachments:
dmesg.hyper
acpidump.hyper
ps: 3.2.0-rc4-686-pae has been remarkably, consistently booting both yesterday and today with any udev
{udev and libudev0 175-1}, {udev and libudev0175-2} and
{udev and libudev0 175-3}
I'm also holding off upgrading the 20 packages waiting in the sid upgrade queue,
until I understand a bit better what I'm looking at in the system today.