Several problems on a toshiba S3000-X11

Éric Brunet
2002-09-27T14:23:20Z

[-- Attachment #1: Type: text/plain, Size: 4223 bytes --]

Hi !

I am using acpi-20020829 with a 2.4.20pre5 kernel on a toshiba satellite
3000-X11, with the custom DSDT made by Bruno Ducrot. The previous acpi
patch I used was acpi-20020503 (I think) with the native DSDT.
I also use the toshiba_3000 module by Bruno.

I have one big problem: my computer shuts down without warning. I have
also some minor problems, and I will begin with those.

MINOR PROBLEMS
==============

When I read the battery state for the first couple of times, the
/proc/acpi files claim that I have two batteries present, and that both
batteries have a charge of 2040 mAh (capacity is 4000 mAh). After a
couple of readings, I have the truth (only one battery and whatever
capacity I have left.) That's annoying, and it didn't happen with my
previous kernel. I don't now if it comes from the patched DSDT or from
the new version of the acpi patch.

When ACPI assigns interrupts at boot, I get
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 7 9 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 7 9 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 7 *9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 7 *9 10 11 12 14 15)
Now I am __nearly__ sure that there was a version of the ACPI patch where
the interrupts were more evenly distributed. Did I dream that or was a
patch reverted ?

In order to have S1 working, I have to apply this patch (originally by
Bruno Ducrot)
----------------------------------------------------------------------------
--- drivers/acpi/hardware/hwsleep.c.orig Sun Sep 1 16:54:05 2002
+++ drivers/acpi/hardware/hwsleep.c Sun Sep 1 18:24:33 2002
@@ -269,6 +269,9 @@

ACPI_FLUSH_CPU_CACHE ();

+ /* Disable BM arbitration */
+ acpi_set_register(ACPI_BITREG_ARB_DISABLE, 1, ACPI_MTX_DO_NOT_LOCK);
+
status = acpi_hw_register_write (ACPI_MTX_LOCK, ACPI_REGISTER_PM1A_CONTROL, PM1Acontrol);
if (ACPI_FAILURE (status)) {
return_ACPI_STATUS (status);
@@ -309,6 +312,9 @@

} while (!in_value);

+ /* Restore BM arbitration */
+ acpi_set_register(ACPI_BITREG_ARB_DISABLE, 0, ACPI_MTX_DO_NOT_LOCK);
+
return_ACPI_STATUS (AE_OK);
}
--------------------------------------------------------------------------------
(note that I have only tried vanilla acpi patch; acpi patch + this two
liners; and acpi patch + this two liners + patched DSDT. Maybe S1 works
fine with acpi patch + patched DSDT __without__ this two liners. I will
check)

With this patch, when I come back from S1, the computer hangs if I try to
use DMA on the DVD player. Whereas, of course, DMA on the hard drive
works fine. (Maybe I should play with hdparm on the DVD after wake-up...)

MAJOR PROBLEM
=============
So the computer shuts down, without warning, while it is not particulary
hot, with nothing written in the logs, while the user was just using vim
in a xterm, at irregular times, and it can happen two or three times in
an afternoon.

That's a major nuisance. By the way, I can confirm that ext3 works very
nicely at recovering a filesystem.

I have an hypothesis; somehow I think there is something wrong in the
reading of the temperature. When I read the temperature, there are some
very unnatural pics; the computer was at 53 degree, then jumps 3 seconds
at 60 and comes back at 53. I believe that, some time to time, this
unnatural jump goes over the critical trippoint and the computer shuts
down in emergency.

The reading of temperatures was made with
while true; do cat /proc/toshiba3k/temperature | awk '{print $1}' >> t; sleep 1;done

I have attached a postscript file showing the result. Note the pics at
around 500 seconds, 800 seconds, etc. (My trip points are 48 and 53
degrees)

Now, what can cause this ? And, more important for me, is there a way to
desactivate emergency shutdown at critical temperature ? Or, better, make
the emergency shutdown occurs only if the __average__ temperature over,
say, the last 5 seconds is over some thresold ?

If you have any idea, I would love to hear it... Meanwhile, I will try
the latest patch.

Regards,

Éric Brunet

[-- Attachment #2: temp.ps --]
[-- Type: application/postscript, Size: 23486 bytes --]