Re: laptop turns itself off

Re: laptop turns itself off

[Bob McElrath]

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

Éric Brunet [ebrunet-l5PIGlIYzrxGWvitb5QawA@public.gmane.org] wrote:
> On Wed, Jul 10, 2002 at 01:20:39PM -0500, Bob McElrath wrote:
> > I have a laptop that spontaneously turns itself off about once or twice
> > a day.  It is an all-ACPI model from Compal model ACL00.  I understand
> > it is equivalent to a Toshiba Satellite 3000 series.  The computer
> > itself is the Emperor Linux model from http://www.aslab.com/.
> 
> I have the same problem with toshiba S3000-X11.

X11?  As in X-Windows?  Is that the model number?  Interesting... ;)

> It happens even when the computer is cool. However, I think it is related to temperature:

Mine seems to bounce between 50 and 60 degrees C.  Seems a bit hot to
me.  I'd like to keep the fan on and keep it below 50...

> I have spent some time looking at the temperature of the computer, as
> reported by Bruno Ducrot's tosh300k module (the DSDT is buggued, so there
> is no thermal zone unless you change it, which I haven't done yet)

Ah, so that's why my thermal doesn't work... :(

> The temperature behaves most of the time nicely: it increases slowly from
> the lower value to the higher, then goes down quickly as the fan gets on.
> However, at some times, the sensor report some aberrant value; like 15 or
> 20 or more degrees (Centigrade) off. It lasts for one or two seconds and
> goes back to normal.
> 
> I believe that at some point, the grossely incorrect reported temperature
> triggers the emergency shutdown.
> 
> I don't know what I should do. Is there a way to disable the emergency
> shutdown (the fan works correctly, thank you) ? Is it possible to make
> the emergency procedure average the temperature for 5 seconds before
> deciding to shut down ? Is there a way to fix the sensors so that they
> don't report wrong values ?
> 
> Of course, the other possibility is that the shutdown has nothing to do
> with temperature, and that the wrong values reported by the sensors are
> just a coincidence.

This is very interesting information.  I just discovered (thanks to a
post on this list) the omnibook tools:
    http://sourceforge.net/projects/omke
Which work with my laptop (after some patching to recognize the ACL00 --
which I will send to the maintainer shortly), and are able to report
temperature.  I also just wrote a script to log the temperature every
second:
    #!/usr/bin/perl -w

    use IO::Handle;

    open(OUT, ">>templog") || die "Unable to open ~/templog";
    OUT->autoflush(1);

    while(1) {
        chomp($date=`date`);
        chomp($temp=`cat /proc/omnibook/cpu`);
        chomp(@performance=`cat /proc/acpi/processor/CPU0/performance`);
        foreach $line (@performance) {
            if($line =~ /^.*\*(P[01]): *(\d+) MHz.*/) { $acpiperf = $1; $acpimhz = $2; }
        }
        chomp(@cpuinfo=`cat /proc/cpuinfo`);
        foreach $line (@cpuinfo) {
            if($line =~ /^cpu MHz.*: ([\d\.]+).*/) { $cpuinfomhz = $1; }
        }
        $outstr = "$date: $temp, CPU speed: $acpiperf($acpimhz) $cpuinfomhz\n";
        print OUT $outstr;
        print $outstr;
        system("/bin/sync");
        sleep 1;
    }

I will let you know if I see the wild temperature variations you mention.

Right now ACPI does not recognize the fan on this laptop.  Looking at my dsdt,
it seems that there is stuff in there about reading/writing the fan status.
Presumably if ACPI took control of the fan and temperature reading, the BIOS
would stop controlling it.  For instance, with the omnibook tools above, as
soon as they take control of the volume buttons, they stop working -- they're
interepreted as keypresses.  I had to write X11 key handlers (WindowMaker menu
items with a keyboard shortcut) to call aumix to change the volume.

I wonder if all tosh3k/ACL00/Omnibook users see this problem, or if we
have a buggy temperature sensor/controller.

Incidentally, the omnibook tools allow all the extra front buttons to work.
They show up as keypresses.  Now I have them hooked up to xmms.  ;)

What processor state have you been using (P0/P1)?  Have you tried both?
I notice more crashes when in state P1 but it also crashes in P0.  I
wonder if this is related.  (There were lots of reported Speedstep
related crashes around 10/2001)

I also just compiled the cpufreq patch.  Hopefully this will fix linux'
timer when the speed changes.  (in state P1 /proc/cpuinfo still reports
the P0 speed)  Dunno if this has anything to do with anything...

Cheers,
-- Bob

Bob McElrath (rsmcelrath-9geRo0GdX4mkVGS65fRQmodd74u8MsAO@public.gmane.org) 
Univ. of Wisconsin at Madison, Department of Physics

"No nation could preserve its freedom in the midst of continual warfare."
    --James Madison, April 20, 1795

[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]

Re: laptop turns itself off

[Bob McElrath]

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

Éric Brunet [ebrunet-l5PIGlIYzrxGWvitb5QawA@public.gmane.org] wrote:
> On Tue, Jul 23, 2002 at 03:17:37PM -0500, Bob McElrath wrote:
> > I will let you know if I see the wild temperature variations you mention.
> 
> Did you see them ?

No.  Many crashes later, I've never seen the odd temperatures you
mention.

> > Right now ACPI does not recognize the fan on this laptop.  Looking at my dsdt,
> > it seems that there is stuff in there about reading/writing the fan status.
> > Presumably if ACPI took control of the fan and temperature reading, the BIOS
> > would stop controlling it.  For instance, with the omnibook tools above, as
> 
> Maybe. I will try Bruno' patched dsdt. Or maybe I will try the bios
> update that toshiba europe proposes without any changelog.

I will probably try the patched dsdt next also.  There is no bios update
for my computer.  (It's bios is newer than the newest one on their web
site!)  Maybe I should put a toshiba BIOS on it.  I'm told my laptop is
equivalent to a Toshiba 3005-S304.

Also I was thinking to find the place in the acpi kernel code where it
is capable of turning the laptop off, and putting in a few debug
statements and a sync() so that it ends up in the logs.  Can anyone
point me to that location in the code?  ;)

Cheers,
-- Bob

Bob McElrath (rsmcelrath-9geRo0GdX4mkVGS65fRQmodd74u8MsAO@public.gmane.org) 
Univ. of Wisconsin at Madison, Department of Physics

"No nation could preserve its freedom in the midst of continual warfare."
    --James Madison, April 20, 1795

[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]

RE: laptop turns itself off

[Huw H]

I seem to have the same trouble, with my laptop turning itself off randomly
without warning. I have a Toshiba Satellite 3000 (model PS302A-00Q5k) and still
use the former (20020517) patch against 2.4.18. In addition I have installed
Bruno's dsdt table for the 3000-601, which as far as I could tell has identical
specs (excepting a 1.13GHz max clock as opposed to 1GHz). I also use the tosh3k
module to set the fan to keep the laptop at between 45-50C.

Time to upgrade kernel and get someone to patch my dsdt propperly I guess.

Huw

<h.hawkins-keaFvQtjc6i7NGdpmJTKYQ@public.gmane.org>



-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31

Re: laptop turns itself off

[Bob McElrath]

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

Huw H [hrhawk-JGs/UdohzUI@public.gmane.org] wrote:
> I seem to have the same trouble, with my laptop turning itself off randomly
> without warning. I have a Toshiba Satellite 3000 (model PS302A-00Q5k) and still
> use the former (20020517) patch against 2.4.18. In addition I have installed
> Bruno's dsdt table for the 3000-601, which as far as I could tell has identical
> specs (excepting a 1.13GHz max clock as opposed to 1GHz). I also use the tosh3k
> module to set the fan to keep the laptop at between 45-50C.
> 
> Time to upgrade kernel and get someone to patch my dsdt propperly I guess.

I just noticed today that it is not actually hung...

It appears to be up but only processing a clock tick once every few
minutes.  If I hit the keyboard, several minutes later the screen will
unblank.  My CPU meter on screen *has* changed on the screen in the last
1/2 hour of watching it.  And the clock is currently 24 minutes slow.
(it should have been accurate at the time of the "hang") There are log
messages on the screen too in my logtail from immediately before the
hang:
    exresnte-0103 [12] Ex_resolve_note_to_val: No object attached to node c16bfd68
    acpi_battery-0195 [07] acpi_battery_get_statu: Error evaluating _BST

I have not seen the turn-off behavior in some time, using kernel
2.4.20-pre5 and acpi from august.  (I will try the latest one soon Andy)

Anyone have any idea what could cause this kind of behavior?

Cheers,
-- Bob

Bob McElrath (rsmcelrath-9geRo0GdX4mkVGS65fRQmodd74u8MsAO@public.gmane.org) 
Univ. of Wisconsin at Madison, Department of Physics

    "The purpose of separation of church and state is to keep forever from
    these shores the ceaseless strife that has soaked the soil of Europe in
    blood for centuries." -- James Madison


[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]

Several problems on a toshiba S3000-X11

[Éric Brunet]

[-- 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 --]

Re: Several problems on a toshiba S3000-X11

[Ducrot Bruno]

On Fri, Sep 27, 2002 at 04:23:20PM +0200, Éric Brunet wrote:
> 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.

This is a trouble with the original AML, and I have not corrected it.

> 
> 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);
>  }

Only the restore should be made.  Actually, the
acpi_set_register(ACPI_BITREG_ARB_DISABLE, 0, ACPI_MTX_DO_NOT_LOCK);
in acpi_leave_sleep_state() didn't work for me too.  Andy, could we
place acpi_set_register(ACPI_BITREG_ARB_DISABLE, 0, ACPI_MTX_DO_NOT_LOCK);
in acpi_enter_sleep_state() instead?

> 
> 		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.
> 

Yes, I have this trouble with some version of ACPI now.  I think that I need
to incorporate now more smoothly with ACPI (that is, I need to use
the function acpi_ec_read() etc. instead of providing them in the module,
and so I avoid some possible races..)

Cheers,

-- 
Ducrot Bruno
http://www.poupinou.org        Page profaissionelle
http://toto.tu-me-saoules.com  Haume page


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Several problems on a toshiba S3000-X11

[Bob McElrath]

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

?ric Brunet [ebrunet-l5PIGlIYzrxGWvitb5QawA@public.gmane.org] wrote:
> 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.

Ah...that's why I switched back to my native dsdt.  Maybe Bruno has a
2-battery machine!  ;)

> 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 ?

I have never seen the interrupts more evenly distributed (my interrupt
distribution is identical to yours).  But I would like them to be!
Having all this stuff share interrupts causes no end of problems.

> (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)

I am not using a patched dsdt...I tried the tosh3k patched dsdt and it
improved nothing but messed up the battery, as you observed above.

> 		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.

So mine has stopped turning itself off (I don't know how or why it
stopped turning off).  Now it hangs and continues to run.  (I sent an
earlier report about this, but nobody seems to be paying attention to us
;)  I left it running for a while and noticed that after I moved the
mouse the screen unblanked after like 1/2 hour.  It's still processing,
just one clock tick per minute or something...  Also the clock was
horribly off after reboot.

> 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.

I have still never seen the temperature swings you mention.

Cheers,
-- Bob

Bob McElrath (rsmcelrath-9geRo0GdX4mkVGS65fRQmodd74u8MsAO@public.gmane.org) 
Univ. of Wisconsin at Madison, Department of Physics

    "The purpose of separation of church and state is to keep forever from
    these shores the ceaseless strife that has soaked the soil of Europe in
    blood for centuries." -- James Madison


[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]

Re: Several problems on a toshiba S3000-X11

[Pavel Machek]

Hi!

> 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.

Emergency shutdown implemented in kernel calls /sbin/halt or similar. This
must be something else.
								Pavel


-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.



-------------------------------------------------------
This sf.net email is sponsored by: DEDICATED SERVERS only $89!
Linux or FreeBSD, FREE setup, FAST network. Get your own server 
today at http://www.ServePath.com/indexfm.htm

Re: Several problems on a toshiba S3000-X11

[Éric Brunet]

On Fri, Sep 27, 2002 at 05:45:42PM +0200, Ducrot Bruno wrote:
> > 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.
> 
> This is a trouble with the original AML, and I have not corrected it.
> 
Are you sure ? Bob McElrath and I never had this problem with the
original DSDT; it appeared when I used your hand-tuned version. It looks
that the problem lies into your correction...
> 
> Only the restore should be made.  Actually, the
It is noted, I will try that. But I hope that it will go mainstream in a
future version.
> 
> > 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.
> > 
> 
> Yes, I have this trouble with some version of ACPI now.  I think that I need
> to incorporate now more smoothly with ACPI (that is, I need to use
> the function acpi_ec_read() etc. instead of providing them in the module,
> and so I avoid some possible races..)

So you confirm that it is ACPI related ? Do you think I can get rid of
that problem by disabling parts of ACPI ? (I guess I could boot with no
acpi at all, but that means no battery readings, no software shutdown and
no S1. That would be a sad world...)

Éric Brunet


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Several problems on a toshiba S3000-X11

[Bob McElrath]

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

?ric Brunet [ebrunet-l5PIGlIYzrxGWvitb5QawA@public.gmane.org] wrote:
> On Fri, Sep 27, 2002 at 05:45:42PM +0200, Ducrot Bruno wrote:
> > > 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.
> > 
> > This is a trouble with the original AML, and I have not corrected it.
> > 
> Are you sure ? Bob McElrath and I never had this problem with the
> original DSDT; it appeared when I used your hand-tuned version. It looks
> that the problem lies into your correction...

Also note that I am using a Compal DSDT.  You guys probably have Toshiba
DSDT's.  My native DSDT correctly reports battery status.  (although
when plugged in with a full battery it says 'charging state: unknown')
But discharge reporting works fine.

> > Only the restore should be made.  Actually, the
> It is noted, I will try that. But I hope that it will go mainstream in a
> future version.
> > 
> > > 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.
> > > 
> > 
> > Yes, I have this trouble with some version of ACPI now.  I think that I need
> > to incorporate now more smoothly with ACPI (that is, I need to use
> > the function acpi_ec_read() etc. instead of providing them in the module,
> > and so I avoid some possible races..)
> 
> So you confirm that it is ACPI related ? Do you think I can get rid of
> that problem by disabling parts of ACPI ? (I guess I could boot with no
> acpi at all, but that means no battery readings, no software shutdown and
> no S1. That would be a sad world...)

Once upon a time I was able to keep my computer up and running for over
a week by using acpi=noacpi on the kernel's command line.  This was
sometime in July (probably with the July ACPI code).  I have tried it
since then and been unable to reproduce this behavior.  (I unwisely
nuked that kernel)

However, as my computer normally stays up for ~1 day on average
(sometimes two), I could believe a statistical fluctuation that stayed
up for a week.  ;)

Cheers,
-- Bob

Bob McElrath (rsmcelrath-9geRo0GdX4mkVGS65fRQmodd74u8MsAO@public.gmane.org) 
Univ. of Wisconsin at Madison, Department of Physics

    "The purpose of separation of church and state is to keep forever from
    these shores the ceaseless strife that has soaked the soil of Europe in
    blood for centuries." -- James Madison


[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]

Re: laptop turns itself off

[Bob McElrath]

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

Ralf-P. Weinmann [ralf-HCprxmsOTPNg9hUCZPvPmw@public.gmane.org] wrote:
> Hi Bob,
> 
> I'm having exactly the same issue that you're having with your Compal, just
> with a Satellite 3000-514 here. The laptop came back from my Toshiba repair
> shop for the second time already. Both times the mainboard was swapped, I was
> told, altogether it was replaced three times, twice at the local Toshiba shop,
> once at Toshiba Europe in Regensburg. What happened before was that the machine
> would crash occasionally afterwards refuse to turn on again. The screen kept
> blank and a short beep-beep was sounded by the BIOS diagnostic routines, which
> according to the Phoenix site can be just about any frigging hardware error.
> 
> So now I get the machine back with system board #4 last Saturday and since then
> it keeps spontaneously turning off on me. Four times thus far, sometimes even
> when the laptop was damn cold. Coming back home this Saturday, the tosh-3k
> module showed incredibly low values (26 Celsius). Few minutes later, the
> machine turns itself off. I have not been able to reproduce this under Windows
> XP, I'd really love to hear from someone who has the same problem under XP,
> because I am not really sure whether it is an ACPI problem or whether it is
> related to something entirely different.
> 
> The new system board seems to have an updated BIOS with a release date of
> 2002/02/19. I'm really wondering what's going on.
> 
> I'm wondering whether it's worth to contact Toshiba on this again now, or
> whether I should wait till the mainboard fries again :)
> 
> On the ACPI mailing list you stated that your laptop doesn't manage to stay
> up for a week even if you have acpi=noacpi passed as an kernel option.
> Does it shut itself down or does it plain crash ?

Ralf-P. Weinmann [ralf-HCprxmsOTPNg9hUCZPvPmw@public.gmane.org] wrote:
> On Mon, Sep 30, 2002 at 11:51:42PM +0200, Ralf-P. Weinmann wrote:
> > Hi Bob,
> > [...]
> > when the laptop was damn cold. Coming back home this Saturday, the tosh-3k
> > module showed incredibly low values (26 Celsius). Few minutes later, the
> > machine turns itself off. I have not been able to reproduce this under Windows
> > XP, I'd really love to hear from someone who has the same problem under XP,
> > because I am not really sure whether it is an ACPI problem or whether it is
> > related to something entirely different.
> > [...]
> 
> Just a quick follow-up. I moved over part of the Java development environment
> for the project I'm working on to Windows XP today. The problem is apparent
> under Windows XP as well (the default install that came shipped with the
> notebook). I'd say it falls into the category "crappy hardware problem", I
> highly doubt it can be fixed by changing the AML code. But we'll see about
> that.
> 
> All I can say is: Toshiba, I want my money back. But that's for tomorrow.

For reference, my Compal ACL00 is equivalent to a Toshiba 3000-514 (I
believe, I could be wrong on the last 3 digits).  Compal manufactures
these laptops for Toshiba.

Based on the available information, I agree with Ralf, this is a
crappy-hardware problem.

We need to figure out which models of these laptops have this problem,
and whether the problem is universal to all of them, or a hardware bug
that can be fixed by swapping out the bad hardware (Ralf's experience
would seem to indicate universality...).  Does anyone know of someone
who has this laptop and does NOT have the turn-off/hang problem?  Bruno
you have probably had the most contact with Toshiba 3k users...

Secondly, we should all pursue remedies though the vendors that sold us
this crap.  I think a class action lawsuit would be appropriate, if they
are not willing to replace the laptops with working models.
Unfortunately, Compal appears to no longer be manufacturing this laptop.

Cheers,
-- Bob

Bob McElrath (rsmcelrath-9geRo0GdX4mkVGS65fRQmodd74u8MsAO@public.gmane.org) 
Univ. of Wisconsin at Madison, Department of Physics

    "The purpose of separation of church and state is to keep forever from
    these shores the ceaseless strife that has soaked the soil of Europe in
    blood for centuries." -- James Madison


[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]

Re: laptop turns itself off

[Ralf-P. Weinmann]

On Mon, Sep 30, 2002 at 10:00:11PM -0500, Bob McElrath wrote:
> [...]

> For reference, my Compal ACL00 is equivalent to a Toshiba 3000-514 (I
> believe, I could be wrong on the last 3 digits).  Compal manufactures
> these laptops for Toshiba.
> 
> Based on the available information, I agree with Ralf, this is a
> crappy-hardware problem.
> 
> We need to figure out which models of these laptops have this problem,
> and whether the problem is universal to all of them, or a hardware bug
> that can be fixed by swapping out the bad hardware (Ralf's experience
> would seem to indicate universality...).  Does anyone know of someone
> who has this laptop and does NOT have the turn-off/hang problem?  Bruno
> you have probably had the most contact with Toshiba 3k users...
> 
> Secondly, we should all pursue remedies though the vendors that sold us
> this crap.  I think a class action lawsuit would be appropriate, if they
> are not willing to replace the laptops with working models.
> Unfortunately, Compal appears to no longer be manufacturing this laptop.

I've got some more things you guys might want to look at. Googling for
'spontaneous shutdown' and similar terms, I found the HP business customer
discussion group, which contains quite an interesting thread about HP
Pavillions (ZT1130/ZT1145), the posting by a a Robert J. Koening being
especially insightful. See the following URL:

http://bizforums.itrc.hp.com/cm/QuestionAnswer/1,,0x3009237a4bc6d611abdb0090277a778c,00.html

To quote from it:

"[...] I summarize the substance of the one of the other threads I read.

 It was concluded by all that it was an overheating problem.

 People aimed small fans at their hp laptops and claimed to have remediated the
 problem.

 Others put tongue depressors under their laptops and removed piles a paper
 around the lap top  and claimed to have stopped the uninvited shutdowns by
 prompting better ventilation.

 But there was no compelling epiphany to explain the problem.

 However, I got the sense that the problem was more a false high-temperature
 reading than a real high-temperature problem.

 There was a lot of talk about whether the automatic fan was working when the
 intrusive shutdown occurred.

 The shut downs did not necessarily seem to take place when the fan was
 working.

 At the end of day, it was suggested by the hp overseer (who watches us writhe
 for a while before finally jumping in) that the new BIOS will cure the
 problem. [...]"

I'm not sure what ODM is supplying Hewlett-Packard for this machine, but as
we have learned before, some Omnibooks seem to be Compals as well so I would
not rule out the possibility that the Pavillion ZT11xx are as well. Maybe the
owner of one on this list can find out? I downloaded a BIOS image for it,
extracted and ran strings over the all.rom file, but it seems to look very
different, except for the Insyde signature on both of them.

Incidentially, Insyde Software seems to be providing ACPI firmware for ODMs
like Compal.  What a coincidence. See the following URL:

http://www.insydesw.com.tw/bios051002%20(%203-1).htm

Cheers,
Ralf

-- 
Ralf-P. Weinmann			HOME: r a l f @ f i m a l u k a . org
Student, Computer Science		 UNI:   r p w @ u n i . d e
Technical University of Darmstadt, Germany


-------------------------------------------------------
This sf.net email is sponsored by: DEDICATED SERVERS only $89!
Linux or FreeBSD, FREE setup, FAST network. Get your own server 
today at http://www.ServePath.com/indexfm.htm