Bug#559578: [Debian-eeepc-devel] Bug#559578: eeepc-acpi-scripts: EeePC 701 freezes with garbled screen while booting
Damyan Ivanov
> Package: eeepc-acpi-scripts
> Version: 1.1.3
> Severity: critical
> Justification: Breaks whole system
Ouch!
> After the upgrade to 1.1.3 my EeePC 701 4G freezes on shortly after
> setting the console fonts with a garbled screen (no more readable,
> looks like lines being out of sync or so). I have to power it off by
> pressing the power button 4 seconds. No more ping, nothing. Due to the
> garbled screen, I do not know if there was any kernel panic or so.
>
> It does not happen if I:
>
> * unplug the power supply (not very usable).
> * boot with acpi=off (neither very helpful)
> * downgrade to version 1.1.2 (did that :-)
> * boot with init=/bin/bash (of course)
>
> It does happen:
>
> * independent of the kernel (tried 2.6.30, 2.6.31, 2.6.31 from grml,
> 2.6.32)
> * independent of the udev or console-setup versions (downgraded both
> to the versions in testing since I first suspected them)
> * even when I boot into single user mode (and power supply is plugged
> in)
> * as soon as I plug in the power supply (in case I had it unplugged on
> startup) the system freezes and garbles the screen, also if running
> under X.
The last point lights a bulb. May be this is related to the
SuperHybrid thingie? Perhaps setting it to 'normal/overload' breaks on
701s?
There are a couple of settings in /etc/default/eeepc-acpi-scripts aout
it. (See the commented file in
/usr/share/doc/eeepc-acpi-scripts/examples)
--
dam
Ben Armstrong
Axel Beckert <a...@deuxchevaux.org> wrote:
> AFAIK there is (officially) _no_ high-speed mode on the 701.
Right. However, they did build into the first model the ability to use
it. They just didn't give any access to that feature when they shipped
it. The similar 701SD model (same 900 MHz CPU) lists S.H.E. support
here:
http://eeepc.asus.com/global/product701sd.html
The model 701 des not:
http://eeepc.asus.com/global/product700.html
> It's a 900 MHz Celeron _permanently_ underclocked to 630 MHz. I
> remember there were some kernel module hacks to run it at 900 MHz
We don't support it via a hack. The eeepc_laptop module which is a
standard part of the kernel now supports access to S.H.E.
via /sys/devices/platform/eeepc/cpufv for all models, whether or not
Asus lists support.
> nevertheless, but this was IIRC quite unreliable so I stopped using it
> after some tests. Can't remember the details what was bad about them,
> but I still know it caused far less problems (especially not reliably
> reproducable problems) than this one.
Given that Asus lists no support for this, perhaps we should patch
eeepc-acpi-scripts to detect model 701 and disable the setting by
default, only enabling it for all other models.
I have a model 4G and have been using S.H.E. performance mode while on
AC for some time. I occasionally suffer lockups, but that could just
as well be due to the still immature support for KMS as anything else.
I'll try for a week to do without S.H.E. and see if the lockups cease.
Ben
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Axel Beckert
On Sun, Dec 06, 2009 at 12:13:04PM -0400, Ben Armstrong wrote:
> We don't support it via a hack
Yeah, that hack dates back to the time where there was no other
support for this feature available anywhere else. IIRC I started with
Kernel 2.6.24 or so on the EeePC. :-)
> The eeepc_laptop module which is a standard part of the kernel now
> supports access to S.H.E. via /sys/devices/platform/eeepc/cpufv for
> all models, whether or not Asus lists support.
Ok, I'll check later if changing that value causes the same problems.
Thanks for that pointer.
P.S.: I'm on the debian-ee...@l.a.d.o list. :-)
Regards, Axel
--
Axel Beckert - a...@deuxchevaux.org, a...@noone.org - http://noone.org/abe/
Ben Armstrong
Axel Beckert <a...@deuxchevaux.org> wrote:
> The following settings work fine and make the problem disappear:
>
> PWR_CLOCK_AC=1
> PWR_CLOCK_BATTERY=2
>
> PWR_CLOCK_AC=2
> PWR_CLOCK_BATTERY=2
>
> So to be on the save side, I suggest for the EeePC 4G (aka 701) to
> either disable SHE or use the 1+2 setting as default.
Given that the 4G only has two modes, setting either of these = 2
doesn't really make sense. Set them to 1 and you'll observe the same
results. If you cat /sys/devices/platform/eeepc/cpufv you should see
that the value 0x201 is reported, indicating that 2 modes are available
and mode 1 is in use. If you try to set any value higher than 1, an
error is returned:
dove:~# echo 2 >/sys/devices/platform/eeepc/cpufv
-bash: echo: write error: Invalid argument
dove:~# echo 1 >/sys/devices/platform/eeepc/cpufv
dove:~# cat /sys/devices/platform/eeepc/cpufv
0x201
Ben
--
To UNSUBSCRIBE, email to debian-bugs...@lists.debian.org
Alexey Morozov
I can confirm this bug. However it 's not a problem with acpi scripts, but
rather a bug in the kernel [module]. I experience exactly the same problem
when I manually switch performance settings from 'normal' (default), to
'performance':
echo 0 >/sys/devices/platform/eeepc/cpufv
My Eee PC is also 701 4G (originally shipped with MS Windows XP) and currently
has Karmic Koala with 2.6.31-15-generic kernel installed. Maybe I should try a
different kernel, or try to load a specific module or whatever else...
Actually I would prefer to have a 'powersave' mode rather than performance.
However only 0 and 1 are reported in available_cpufv. BTW Windows was able to
downgrade performance when battery was close to discharge. But maybe it was a
hardware feature activated specially for an operating system which is known to
be a speed hog :)
Sincerely, Alexey Morozov
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org