>From: "Yu, Luming" <[email protected]>
>> I suggest you to retest, and post dmesg with UN-modified BIOS.
>
>I'm now running/testing an unmodified DSDT with 2.6.16-rc5.
>For a while
>I had no S3 hangs, but I just noticed them again. The error
>is the same
>as with the modified DSDT (with slightly different offsets):
I assume you have tested ec_intr=0 and ec_intr=1.
>
>exregion-0185 [36] ex_system_memory_space: system_memory 0 (32
>width) Address=0000000023FDFFC0
>exregion-0185 [36] ex_system_memory_space: system_memory 1 (32
>width) Address=0000000023FDFFC0
>exregion-0290 [36] ex_system_io_space_han: system_iO 1 (8
>width) Address=00000000000000B2
>
>repeated endlessly.
I need calltrace for this
>
>I think the problem resurfaced once I decided to let my sleep.sh script
>leave the thermal driver loaded before going into S3 (suspecting that
>the bug might come back if I did that).
Clealy, it's thermal related. We need to narrow down here.
>
>So I susect that my modified DSDT didn't cause the S3 problems, it
>merely exposed one even in the minimal configuration discussed in the
>#5989 report.
The ground rule is Don't use modified DSDT.
If you do that, the results won't be trusted.
>
>Which makes me wonder about another bug that disappeared when
>I switched
>to the vanilla DSDT: While printing (via gs+hpijs to an HP photosmart
>2710 via the wireless card), the system makes double-beeps as
>if it were
>having the AC adapter plugged and unplugged. These noises happen when
>printing via the wireless card or via USB (to a different HP inkjet),
Interesting, open bug for this.
>but not when printing via the parallel port to a Lexmark laserprinter
>(using just gs). Since I didn't do anything to the battery code in the
>DSDT, I now wonder whether changing the DSDT merely exposed the issue
>but didn't create it.
>
>[From an earlier msg:]
>> I think the truth is, for 5989, we need to fix thermal and processor
>> driver issue.
>
>I agree, although I think the processor driver is not the culprit. My
>earlier testing with the (with the modified DSDT) worked fine with the
>processor module loaded, but hung with processor + thermal loaded.
>
ok, we need to start from thermal.
BTW, do you still think this is a regression?
Thanks,
Luming
> I assume you have tested ec_intr=0 and ec_intr=1.
Right: I forgot to mention it, but I did test it both ways, and
ec_intr=0 is fine.
>> These noises happen when printing via the wireless card or via USB
>> (to a different HP inkjet),
> Interesting, open bug for this.
I cannot reproduce it with the vanilla DSDT, only with the modified
one. But:
> The ground rule is Don't use modified DSDT.
> If you do that, the results won't be trusted.
>> exregion-0290 [36] ex_system_io_space_han: system_iO 1 (8
>> width) Address=00000000000000B2
>>
>> repeated endlessly.
> I need calltrace for this
Looking at /proc/acpi/debug_level, I see several debugging choices
that might give the calltrace you want. Let me know which ones are
essential (I'd turn all of them on; however, I found when trying to
track this down earlier that the bug would slither away if I had too
much debugging turned on):
ACPI_LV_DISPATCH 0x00000100 [ ]
ACPI_LV_EXEC 0x00000200 [ ]
ACPI_LV_NAMES 0x00000400 [ ]
ACPI_LV_FUNCTIONS 0x00200000 [ ]
By the way, a long standing buglet for me is that 'cat
/proc/acpi/debug_level' truncates the output to 1024 bytes. So I have
to do 'cat /proc/acpi/debug_level | cat' so that the first cat doesn't
find that its stdout is a tty and try to reduce its buffer size from
4096 (big enough) to 1024. A patch is available at
<http://bugzilla.kernel.org/show_bug.cgi?id=5076>
> BTW, do you still think this is a regression?
I'm 95% sure, because booting with ec_intr=0 avoids the problem, so
the commit that made ec_intr=1 the default almost certainly also makes
this bug appear.
-Sanjoy
`Never underestimate the evil of which men of power are capable.'
--Bertrand Russell, _War Crimes in Vietnam_, chapter 1.