I've put Debian-testing (from about september 2005) on my Maxdata Eco 4000A notebook, with kernel, 184.108.40.206 (before I used 2.6.14-rc5 and 220.127.116.11, they work too). All important things works OK.
Main things that don't work for me are: S-video out and the SD cardreader.
From 2.6.17 or thereabout I start to experience infrequent lockups, usually about 5 min after boot.
Below I describe in more detail my experiences with my Maxdata Eco 4000A Laptop & Linux (Debian)
Oh, using wget, the max speed I get is about 2.51MByte/s (20.1Mbit/s), rather slow for a 54Mbit connection, but maybe my el-cheapo SWEEX access point is guilty for that. This is with the signal-strength indicator at 97%. The transmission speed rarely drops below 1.5MByte/s, so it feels relatively stable.
GPU type: SiS 760/760GX rev 0; SiS 302LV video bridge Video RAM: 64MB (shared) Bus type, location: AGP, PCI:1:0.0 BIOS version: 2.06J.01, new SiS data layout Driver version: 2005/09/18-1 SiSCtrl extension version: 0.1 SiSCtrl version: 0.0.20050916
# lsmod|grep ^snd snd_intel8x0m 17092 0 snd_intel8x0 30912 0 snd_ac97_codec 83580 2 snd_intel8x0m,snd_intel8x0 snd_ac97_bus 2560 1 snd_ac97_codec snd_pcm 81800 3 snd_intel8x0m,snd_intel8x0,snd_ac97_codec snd_timer 23428 1 snd_pcm snd 49508 5 snd_intel8x0m,snd_intel8x0,snd_ac97_codec,snd_pcm,snd_timer snd_page_alloc 10120 3 snd_intel8x0m,snd_intel8x0,snd_pcm
# grep 1394 /var/log/kern.log Oct 10 12:52:37 localhost kernel: ieee1394: Initialized config rom entry `ip1394' Oct 10 12:52:37 localhost kernel: ohci1394: $Rev: 1299 $ Ben Collins <firstname.lastname@example.org> Oct 10 12:52:38 localhost kernel: ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ= MMIO=[dfffb800-dfffbfff] Max Packet= Oct 10 12:52:38 localhost kernel: eth1394: $Rev: 1264 $ Ben Collins <email@example.com> Oct 10 12:52:38 localhost kernel: eth1394: eth1: IEEE-1394 IPv4 over 1394 Ethernet (fw-host0) Oct 10 12:52:39 localhost kernel: ieee1394: Host added: ID:BUS[0-00:1023] GUID[00030d532553232a]
When ec_burst=1 isn't handled,
in /proc/acpi/battery/BAT0/state the remaining capacity is usually shown correctly, but not always. cat-ing from the file often breaks halfway with an error.
Thus, gnome battery charge monitor 2.8.2 cannot read it consistantly, and
often complains about "no battery present", or "battery low", even though
there is a fully charged battery present.
Furthermore, in /proc/acpi/battery/BAT0/state the 'present rate' always seems 0:
# cat /proc/acpi/battery/BAT0/state present: yes capacity state: critical charging state: charged present rate: 0 mA remaining capacity: 1289 mAh present voltage: 11492 mVAlso, when the ec_burst=1 isn't given, the kernel spits out the following:
Oct 14 23:01:20 localhost kernel: ACPI-0412: *** Error: Handler for [EmbeddedControl] returned AE_TIME Oct 14 23:01:20 localhost kernel: ACPI-0508: *** Error: Method execution failed [\_SB_.PCI0.BAT0._BST] (Node cbf84fe0), AE_TIMEFirst discharge lasted 2:08; charging again took about 4h (while the laptop is switched on).
abelo:/proc/acpi/thermal_zone/THRM# echo 85:80:35:75:60 > trip_points abelo:/proc/acpi/thermal_zone/THRM# cat trip_points critical (S5): 85 C(to change the one-and-only trip-point, you do have to give 5 values, as explained in the acpi_howto.txt).
# echo "ondemand" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
CPU Idle Power States: /proc/acpi/processor/CPU0/info reports power management: yes, and /proc/acpi/processor/CPU0/power reports max_cstate: C8. Unfortunately, whatever I do, the active state always is C2, so it looks like it doesn't really do anything useful.
# cat /proc/acpi/processor/CPU1/power active state: C2 max_cstate: C8 bus master activity: 815c2103 states: C1: type[C1] promotion[C2] demotion[--] latency usage *C2: type[C2] promotion[C3] demotion[C1] latency usage C3: type[C3] promotion[--] demotion[C2] latency usage
CPU throttling Doesn't work.
It works (at least using this script, but versions before 2.6.14-rc3 need a (small) patch from Rafael J. Wysocki <firstname.lastname@example.org>. Without the patch (at least in 18.104.22.168 through 2.6.14-rc2), the system freezes when there isn't enough swapspace to write the memory to.
I'm now using the "firmware" method to write the data to disk,
echo firmware > /sys/power/disk echo disk > /sys/power/state
Time to powerdown: 14 sec
Time from powerup to working X: 37 sec (of which 12 s is spent in BIOS).
After powerup, the only thing that doesn't come up automatically is the Ralink WiFi card, so I have a little script that does "ifdown/suspend/sleep 4/ifup ra0" automatically.
For the freeze-output (without the patch), see here
wget http://puzzle.dl.sourceforge.net/sourceforge/cdctl/cdctl-0.15.tar.gz tar -xvzf cdctl-0.15.tar.gz cd cdctl-0.15 ./configure make ./cdctl --lockdoor=1 Now the CD/DVD drive door will not open, even if it's empty and you push the eject button on the drive door. ./cdctl --lockdoor=0 Now you can open it again normally.
For more information on my linux kernel .config, lspci output, etc, see here
This site is listed on: tuxmobil.org and (finally) on
I haven't tested everything yet; I'll try to add more info later. If you would like me to test something, please email me.
Written by Joost Witteveen, joostje at komputilo.org; copyright: GPL
Other pages: SFT-2000 satelite receiver and Dimage Z2 camera. Toshiba Satellite L40-17O laptop.