SuSE Addendum to Akkana's Vaio Linux Page

The single exception so far seems to be the jogdial. There are utilities to use it under Linux, but they simply fail on the SR33, but work fine on the SR17. On the other hand, this may also be a SuSE thang; not sure yet.

The screen brightness control via the sonypi driver works fine, however, and I'm using Ak's script to handle it.

An interesting power management note: the simple utility apm (without arguments) reports the battery/plugin situation and charge level immediately. This turns out to be easier and faster than anything else on either Linux, Windows or Mac. Very nice.

I had none of the sound card oddities Akkana reports, even on the original kernel (it's turned off in hers, which it also is in the standard SuSE kernel: they use ALSA instead) -- I don't personally use sound features, and the system beep is all I ever hear. Works fine.

One curiousity of the SR33 is the processor description as Celeron Coppermine. I'm no processor expert, but the Coppermine was the name for the PIII with the smaller, processor-speed L2 cache, and this unit has exactly that setup. What distinguishes it from a true PIII is not at all clear to me. Intel has released PIII designs as Celeron when they think the market won't bite otherwise.

Our philosophical differences about RedHat vs SuSE are not particularly strong. We both acknowledge weaknesses and strengths in both distributions, and the discovery that Linus Torvalds uses both leaves us with no clear idea of which is better. Suffice it to say the preference is not overwhelmingly strong on either part, and probably has a more to do with familiarity than any great advantage of either.

Partitioning Issues

First I broke the two existing partitions into four, with hda1 remaining Windows, hda2 becoming a /boot partition (old habit), hda3 a DOS partition (because WinME makes true DOS access a real pain, and the easiest way to get anything configured in windows is to run DOS) and hda4 as an extended partition with a 128MB swap and about 6gig /.

This happened in two stages. I originally planned to use the minix boot loader, but I realized I couldn't really get away with it if I wanted to use logical partitions (minix doesn't see them).

Round one was done using Partition Magic, a wonderful Windows program that is losing functionality as it goes along. Round 2 was done with the SuSE install partitioning software, which is fine and gave no hassles about the advanced position of the /boot partition.

Installation

Installing via cdrom issue is simple with the SR33, of course, since it includes a bootable cdrom. SuSE had no problem finding or running the CD.

As with partitioning (and about everything else I do) I ended up installing twice. The first time was SuSE Pro7.1, which I had lying around, and then I decided to get 7.2 for the laptop since I was going to be out on the "bleeding edge" and might as well have the very latest version of the distribution.

This was probably wise, though it's hard to say in the long run, since I had to build my own kernel and dig up a fair amount of software.

X Configuration

Otherwise, it started right up and has continued to run just fine, using the standard svga server.

Another, more troubling curiousity emerged when I was updating my desktop machine to 7.2: I had another mouse error, but this time Sax2 simply could not run or fix it. In the end, it required editing /etc/X11/XF86Config and inserting "PS/2" and removing the Sax2-inspired vendor line. Since then, everything has been fine.

Akkana had trouble with KDE on RedHat and went to Gnome/Saw*, which clearly loads faster (and is still butt ugly). On SuSE, I have had no problem running KDE, but did have the problem that RedHat/Sawfish seems to save the screen location/adjustments to the same file Windows uses, so one or the other is constantly out of place.

The slow startup of KDE2 is annoying, but it looks good and runs fine in my setup. That's my story and I'm sticking to it. Notably, however, Konsole is fouled again, and has trouble reading its own config files, so I finally gave up on it and shifted to rxvt, which has its own set of oddities, but they are more easily fixed.

Networking

I didn't have a pcmcia network card because I have never had a pcmcia portable before (having only personally owned a Zenith where I never got the networking to function).

Off to Frys where I got a Linksys NE2000-clone card that explicity said it supported Linux, but failed ignominiously. Oh well, back we go and get a Hawking card with less explicit claims, that also failed. Argh. Then I carefully compiled a list of supported cards, went back to Fry's, and picked up an inexpensive Ambicom card that has been excellent. However (and this would play a major role) it uses the tulip driver (tulip_cb.o) rather than xircom.

Nevertheless, I was up and running. Time to fool with kernels.

Building the 2.4.9 Kernel

My first approach was to try to get things working using the SuSE kernel sources as shipped with the distro, along with "borrowing" their config file and making a few small changes to accomodate my hardware needs.

The result? The modules would not build. I was unimpressed. So I started removing modules that I thought unnecessaary (and that would not build) and moving onward. Still, after three tries, make modules failed repeatedly.

Tiring of this game, I simply downloaded the sources from kernel.org and borrowed Ak's .config, which was already working, and went at it. Clean build on the first try, including modules and make modules_install.

That's when the real drama began.

Networking Revisited

After installing the kernel and System.map (Symbol tables. This is a step I was convinced was important, but which Ak had been skipping up to now) the Vaio booted just fine -- but networking failed.

Hmm. I had noticed that the original SuSE kernel explicitly did *not* load pcmcia networking at all, which struck me as odd. Another puzzling oddity was the lack of any option to select "tulip" in pcmcia networking devices, either as part of the kernel or as a module.

This all struck me as fishy, so it was time for a fishing expedition. The docs in /usr/src/mykernel indicated Dave Hinds' pcmcia rpm was perhaps something I should get, so I headed off to sourceforge (after the supplied link failed) to hunt it down. This entailed becoming a member for some reason (Ak says she never had to join) but what the heck -- it's a distinguished crowd.

What I ended up with was pcmcia-cs-3.1.29 with some nice documentation. Basically, it explained that the pcmcia networking paradigm was changing. As a result, support could now be built into the kernel with an enigmatic "yenta" driver (written by Linus Torvalds) that would incorporate existing PCI drivers to run pcmcia networking.

He also mentioned that another option was to simply turn off all pcmcia networking in the kernel and install his package (building the modules to run pcmcia the old way) and starting it all up from init. This looked awfully familiar, as the modules are present in the SuSE distribution set and (as previously mentioned) pcmcia networking is not set in the kernel.

It seemed the easiest (and coolest) thing to do was try the new setup by making sure pcmcia networking and cardbus were set in the kernel, and making sure the PCI "tulip" module was installed. I did this.

Pffft. No luck.

Do it again and fuss with it. No luck.

A web search located various other plaintive wails from people whose tulip pcmcia was failing. Ouch. So I decided maybe SuSE knew something after all and embarked on the (anticipated to be tedious) task of getting the pcmcia-cs-3.1.29 modules installed and working.

This turned out to be ridiculously easy, primarily due to the thorough job Dave Hinds did with the PCMCIA module makefiles and setup. Suffice it to say you copy the unzipped folder to your kernel source directory, type make, and Do The Obvious Things. It's that slick!

After that, no problem with the network. Also, unlike the RedHat init setup, the SuSE system was able to get the sequence right and there was no problem with the startup phase at all.

Using The Memory Stick

Hotplug sees the stick no problem, and implements it as a scsi device (don't ask; I don't really know). All you have to do is mount -t vfat /dev/sda1 [mount point/directory] and there it is! After that it will behave just like any other part of the file system.

For added convenience, enter it into your fstab and write a few aliases to mount, unmount and navigate (since likely you'll only use one directory most of the time, and it Will Be Named Something Silly).

Hooking Up The Visor

The USB Visor cradle, on the other hand, was just plug and play. The "visor" module was part of the SuSE install, so it was just a question of getting it cooking: modprobe visor.

At first, I loaded the module by hand. As things got solid, I put module startup in the init process at the end of runlevel three, and it works great.

First attempts involved using the kernal with the visor module available, creating the link pilot->/dev/usb/ttyUSB1 and fussing around with trying to get pilot-xfer -l to work. (You can, by the way, still use /dev/ttyUSB1 if you wish, but the usb subdirectory is more "modern.")

Like everything else, this failed at first, but eventually Ak found a good howto that clued us in to a weirdness: you have to press the hotsync button before any other activity to get the module to actually do its thing at all.

After that, the operation worked, and the Visor databases were listed out. My first experiment was to try to get KDE's Kpilot to work, which took about two minutes.

Though Kpilot is an excellent program, I also started to look at the more lighweight pilot-link/pilot-xfer utilities, and now prefer them . They are easily understood and offer a great deal of flexibility to arrange your palm-talk to your liking (including modifying your databases).

Coldsync seems heavily favored by visor users, but I was not able to get a happy config file, and did not anticipate (from reading the docs) that it had as many goodies as pilot-xfer anyway.

Even more challenging might be getting communications between Linux and the Diamond Mako / Psion Revo2 I got off the web (at about the time Psion decided to own up that they were discontinuing the unit). It was little problem getting the Mako going on my desktop unit, but the Vaio?

So far, no luck. I have config problems getting the USB/serial adaptor going (which works fine for Ak) though it might one day. But Psion never did get around to being cooperative with anyone but Windows, and the Revo actually is harder to talk to than earlier models were, so it may turn out the best way to work with it is via the internet, which it handles much better than palms (and I have a modem for it).

Hopefully I will get it working, and will report on that in due time.

The Carrying Case Issue

The best solution I have so far is something I picked up at a thrift store that is exactly the right size, which I use when I don't need to take along any peripherals.

In addition, I got the smallest Targus notebook case at Fry's for $24, and it is tolerable for carting all the peripheral stuff along with the unit.

This two-case approach is probably best, but it would be nice to have something better than a thrift-store bag for lightweight travel.

Wrapup

Power management is still a little rough, but you can easily get the screen brightness dropped, and that's the major wastage. Linux is pretty good with the disk already, and you can run about as long with Linux as Windows if you don't build too many kernels on battery (which I have done, but it does thrash the system pretty hard).

But it's a delight to use, especially on Linux. Windows has a way of "grabbing" the mouse and locking you out that is much more rare (usually not present at all) on Linux.

And, of course, KDE2 looks much better than anything to come out of Redmond.