It seems like the Toshiba M30X isn't widely used with Linux yet though, and therefore finding information about getting it all working is hard to find. Therefore, I decided to create this page, listing my quest for getting the machine running with Linux.
| Machine identification | Toshiba M30X | Linux 2.6.9 config | ||||||
| CPU | Intel Pentium M Processor 1.60GHz 2048KB L2 cache |
CPU Frequency Scaling works | ||||||
| Memory | 512MB (2 x 256MB SODIMM) | |||||||
| Video | ATI Technologies Inc Radeon Mobility 9600 (M10) NP (AGP) |
|
||||||
| USB | Intel 82801DB |
|
||||||
| FireWire (IEEE 1394) | Via Technologies, Inc. IEEE 1394 Host Controller |
Not tested | ||||||
| Ethernet Controller | Realtek Semiconductor Co., Ltd. RTL-8139/8193C/8139C+ |
Linux 2.6.9 -> 8139too | ||||||
| Ethernet Controller | Atheros 802.11g (builtin) | Works fine using the MadWiFi driver | ||||||
| PCMCIA | ENE Technology Inc CardBus bridge |
PCMCIA starts up fine with yenta_socket Do not probe 0x800-0x8ff No actual PCMCIA card tried yet |
||||||
| IDE HD | Hitachi 40GB |
Works (of course) | ||||||
| DVD-RAM writer | Mashita DVD-RAM UJ-820S |
|
||||||
| Audio | Intel 82801DB AC'97 Audio | Linux 2.6.9 -> i810_audio | ||||||
| Modem | Intel 82801DB AC'97 Modem | Not tested | ||||||
| Sun Dec 12th, 2004 | |
| First attempt to get Debian to work from the Debian 3.0r2 install CD failed miserably. Shortly after the kernel startup the screen went blank. Not a good thing. After a sufficient amount of digging it turned out that the Debian install kernel has vesafb enabled and it needs a vga=0x317 kernel parameter. Beyond that, the install went well. Of course, most of the hardware isn't supported in the default 2.4.18 kernel, but that was expected. | |
| Mon Dec 13th, 2004 | |
|
Time to move to a 2.6.9 kernel, since then more hardware is likely
to be supported. Things like support for the Pentium M processors,
the audio hardware in the laptop, ... Still haven't tried to get X11
up and running, but I do not actually expect too many problems there.
Like I do on all my other machines, I'm going to compile XFree86
4.4.0 myself and try that. I always create fake deb packages to go
along with it, so that Debian won't complain when installing other
(dependent) packages.
And indeed, a compiled XFree86 4.4.0 works fine, and even at the native 1280x800 resolution without any tweaking. Switching between virtual consoles and X11 works fine as well. |
|
| Tue Dec 14th, 2004 | |
|
After some ugly printk-based debugging in the Linux kernel, I found
that the 0x800-0x8ff IO port range being probed by the pcmcia support
was causing the machine to hang. After excluding that range, pcmcia
starts up fine. I didn't bother trying to narrow it down to the
minimal port range that can be excluded, so if anyone wants to do so,
just know that the problem starts right at 0x800.
Also, after compiling and installing the MadWiFi driver and wireless tools it turns out that the Atheros 802.11g wireless adapter in this machine works fine. I only checked that it can talk to the 802.11b WAP I have here, but more testing will happen soon. |
|
| Thu Jan 13th, 2005 | |
| I finally got around to posting my kernel config for Linux 2.6.9 and my XFree86 4.4.0 configuration file on this webpage. I hope it will be useful for others. I received a couple of emails from other people who bought the M30X, either to request info about my configuration files, or to mention that they too managed to get Linux running on it. | |
| Mon Aug 15th, 2005 | |
|
Due to the birth of my daughter, a job change, and a relocation to
the other side of the country, I didn't get to spend much time on
playing with my not-so-new-anymore laptop. My current frustration
is that the ACPI battery status is a bit flaky. If I read the
content of /proc/acpi/battery/BAT1/status a few times in a row from
a text console (no X running), the system decides that the battery
got removed, and all status is gone (obviously). And the data that
was read while the battery was still believed to be present is not
correct.
When I start X things become interesting. Suddenly, doing the same repeated reading of /proc/acpi/battery/BAT1/status from an xterm does not result in the system after a while thinking the battery got removed. And all data read from the file is correct. This begs the question whether there is something happening at the ACPI level when X starts. Haven't figured out what though... |
|
| Fri Jun 16th, 2006 | |
|
So, for a while I have been using the Omnibook kernel module to query
and control ACPI functions of my Toshiba M30X. In fact, I even wrote
my own little widget (fashioned after xapm) that displays the battery
status based on this kernel module, with fallback on ACPI or APM if
that is needed (to support other laptops).
Then today, I upgraded to the 2.6.16 kernel in order to avoid some very ugly USB 2.0 issues I ran into. One of my USB sticks caused a spontaneous disconnect/reconnect loop, while 2 other USB sticks simply caused kernel lockups and related issues after large data transfers. The kernel upgrade did resolve the kernel lockups, and seems to let me used USB 2.0 devices without a problem, though one of my USB sticks is still running into the disconnect/reconnect loop. I have a feeling that it is just a bad USB stick, failing to implement the USB 2.0 standard correctly. A side effect of the upgrade is however that now, the Omnibook module no longer works right. On the other hand, it seems that the kernel ACPI support may now finally work OK on my Toshiba M30X. I still can't seem to control things like brightness and such, but that can't be too difficult either, since it actually still works using the Omnibook module. It's mainly the battery stuff that now works in the kernel but not through the external module. Go figure... Update at 18:38: After a reboot it turns out that the Omnibook module works anyway. It seems like it needs to be loaded during the boot process in order for it to work right. This seems to support my gut feeling early on that there is a timing dependency here. It makes me wonder whether the ACPI implementation on this laptop does some weird configuration tricks based on the first call into it, or something like that. |
|
| Sun Jan 28th, 2007 | |
| After another move across country (west to east this time), together with a job change, I had to deal with the unfortunate event of needing to re-install my entire system. I used Debian 3.1, and armed with my experiences from before (e.g. vga= kernel param and excluding a range for PCMCIA probing) the install went a lot faster. I also wrote a little replacement script for update-grub (listed below in the resources) to allow me to remove clutter from the /boot directory. I like using sub-directories, thank you very much. | |
Last modified: Jan 28th, 2007
©1995-2007 by Aedil