There seem to be 5 variants of this laptop doing the rounds:
As far as I can tell, the 51P comes with no optical drive, the 51-P/A (my model) with a DVD-only (model PCGA-DVD1) drive, the 51-P/B with a CD-RW drive, and the SRX-99 (US version) with a combo DVD/CD-RW (PCGA-CRWD2 I think) drive. However, I was not able to get a straight answer on the exact configuration of each model from any websites or dealers I spoke to (even Sony Style direct). As far as I can tell the SRX-77 and SRX-99 do not have bluetooth. It is a shame I was unable to buy it with a DVD-RW drive (e.g. the PCGA-DVRW1) included. In the end I went for the DVD drive as I don't have one already and have lots of IDE/SCSI/USB external CD drives.
All the drives are IEEE1394/FireWire/i-Link models. I had thought this might cause installation problems, but it seems not. Certainly booting from the RH8.0 installation disk just works, and ohci1394 drivers are loaded are part of the boot process.
Although the RH 8.0 release notes claim that an install from IEEE1394 CD-ROM is possible, in practice after booting nicely from this drive it did not present any CD-ROM as a possible media. OTOH, I have a PCGA-CD51 IDE PCMCIA external CD drive from my old Vaio, so I tried plugging this in too, and the machine was happy to install from that after booting from the 1394 drive. It also booted from the CD51 okay.
Having installed RH8.0 however, I decided the least painful time to upgrade to RH9.0 was right at the start (this subsequently turned out to be a smart decision). RH9 both booted off the 1394 DVD and installed off of it, though it would not boot+ install of the CD51 (on either my SRX-51 or PCG-N505) for some reason. There was also some strangeness using the touch pad mouse (ALPS Glidepoint) during the RH9 installation that did not manifest itself during RH8, but I set the mouse type to a 2-button PS/2 and it was okay once the installed/upgraded Linux was booted proper.
I also tried my old Vaio's PCGA-UFD5 USB floppy drive, works with usb-storage to come up as a /dev/sd* device. Iomega CD-RW drives also work via both IEEE1394 and USB. These come up as a SCSI /dev/scd* devices for reading via SBP-2 emulation, and seem to be okay as /dev/sg* devices for writing (not tested yet).
On re-paritioning, I wimped out of all the tweaky stuff and just bought PowerQuest PartitionMagic 8.0 as previous versions of this software have worked nicely for me in the past, and it claimed it could deal with the Windows XP NTFS that comes on this machine as well as FAT32, ext2, ext3 etc.
I have left the NTFS Windows XP partition largely untouched, but created a smaller FAT32 partition for moving files between the two OSes. Here is the current partition table:
Disk /dev/hda: 3648 cylinders, 255 heads, 63 sectors/track Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0 Device Boot Start End #cyls #blocks Id System /dev/hda1 * 20+ 1299 1280- 10281568+ 7 HPFS/NTFS /dev/hda2 1829 3647 1819 14611117+ f Win95 Ext'd (LBA) /dev/hda3 0+ 19 20- 160618+ 83 Linux /boot /dev/hda4 1300 1828 529 4249192+ c Win95 FAT32 (LBA) /dev/hda5 1829+ 2593 765- 6144831 83 Linux /home /dev/hda6 2594+ 3115 522- 4192933+ 83 Linux /usr /dev/hda7 3116+ 3376 261- 2096451 83 Linux /var /dev/hda8 3377+ 3516 140- 1124518+ 82 Linux swap /dev/hda9 3517+ 3647 131- 1052226 83 Linux root
Next thing was to get ACPI working - I used the acpi-20021212-2.4.20 patch, this was straightforward and sorted out a lot of issues with USB and the built-in etc hardware and error messages.
As a lot of the hardware that comes, or indeed is built-in, to this machine is hot-pluggable, in general I found while customising the kernel it was best to build things as modular as possible. The current state of my config file can be found here.
In particular, the Wireless LAN interface, based on standard Orinoco/Hermes hardware, sits behind a second PCMCIA controller. The on/off switch for this on the side of the laptop is not a "soft eject", however, but rather seems to control power to the WLAN transceivers. Doing a "cardctl eject 1" does however appear to fully disable the Orinoco card and slightly reduce power consumption.
If anyone can point me to good tutorials on:
The Bluetooth interface and Memory stick slot sit behind a second USB controller. bus.
In order to get USB working it is necessary to apply a patch so that the Memory Stick device is recognised, otherwise the usb-storage module blocks. There does not appear to be a problem with this laptop found on other Vaios where IRQ10 is misused for USB, it gets it all right on the ACPI IRQ11.
I also compiled in the sonypi module.
Once the ACPI and Memory stick kernel patching was done, both the built-in wired Ethernet (an Intel e100) and the WLAN just worked nicely. I put PCIC_OPTS="cs_irq=11" in /etc/sysconfig/pcmcia as advised on other Vaio sites, but am unsure if this is needed. Note I used the kernel-based yenta_socket PCMCIA driver.
After some difficulty getting any of the Linux utilities to figure out correctly what sort of WinModem I had, I was pleasantly surprised by resorting to information from the Windows side to find that it was a Conexant HSF and that the drivers from the Linuxant did the job nicely. I used hsflinmodem-5.03.27lnxtbeta03042700-1.i386.rpm, which it needed to re-link into my custom kernel during installation.
My trusty aging Xircom CEM-56G PCMCIA modem also worked fine, however, and both modems have successfully done dial-up using kppp. Possibly there is slightly less latency with the hardware modem.
Another curious (and annoying) similarity between my old and new Vaios are the PSU and batteries. Both run off 16V DC with 11V LiI batteries. The batteries use very similar physical and electrical connectors, but look like they have been deliberately made to be non-interchangable. Typical Sony, I wish they'd see the benefits of generating customer loyality over using tweaky proprietary connector lock-in to force people to buy stuff they don't need to duplicate.
If I can find a source of matching connectors I'll try running the machines off each other's PSUs (taking care over maximum current needs).
One downside of this machine is the lack of a good old-fashioned RS-232 style serial port, not because I'm particularly fond of these, but rather this is the simplest way of connecting to a Nokia mobile phone.
The quick and easy way aorund this was to use my socket serial PCMCIA card, this with its DB9 cable and a Nokia DLR-3 cable were enough to get GSM data up and running with any of a Nokia 7110, 6210 and 6310i, at the cost of having to carry lots of bits around.
A solution involving one less cable (and 2 less plugs !) is the Xircom CEM-56G PCMCIA modem with GSM firmware and (DAU-9 style) cable - this worked to a Nokia 6190 and hence would presumably work with the older 6110 and 6150 Nokias. Both this and the Socket card work fine with the standard serial_cs driver module. However, the working internal winmodem means I don't need to carry a PCMICA modem around otherwise, and Xircom never did DLR-cable support for this card, so my next step was to get the part count down to just one cable.
I achieved this with a Mobile Action MA-8610C USB to Nokia cable (USB device ID 67b:2303:202). This is sold under various brands, in particular c/o Kondor in Dixons stores in the UK, but the important thing is that it contains a PL-2303 USB/serial convertor, which is supported by the pl2303.o CONFIG_USB_SERIAL_PL2303=y 2.4.20 kernel module. This worked nicely for my Nokia 6210 (and 7110), but did not seem to initialise correctly for the 6310i, causing the phones display to go into a "Accessory Connected" repeating loop (the Windows drivers seem to bodge around this somehow, there is also Linux source on the chipset manufacturers website which seems to be widely divergent from the standard source tree and which I did not try).
Eventually I got the 6310i to work by following the sequence:
Given the slightly unsatisfactory nature of the USB option for the 6310i (my preferred phone because of US 1900MHz and potential GPRS support), the next step was the cable-free holy grail of Laptop/Mobile connection via Bluetooth. I remain fairly sceptical of this technology, and was a bit suprised when I got it to work.
The wireless switch has a different effect for the Bluetooth interface, effectively connecting and disconnecting it from the USB bus.
Kernel config options are:
82431 /usr/local/rpm/bluez-bluefw-1.0-1.i386.rpm 29865 /usr/local/rpm/bluez-hcidump-1.5-1.i386.rpm 104365 /usr/local/rpm/bluez-libs-2.4-1.i386.rpm 26029 /usr/local/rpm/bluez-pan-1.1-1.i386.rpm 306949 /usr/local/rpm/bluez-sdp-1.1-1.i386.rpm 67705 /usr/local/rpm/bluez-utils-2.3-1.i386.rpm
The following steps (from the bluezhowto.html) are what it takes to get this to work:
Biggest problem I had here was with authentication - it only did so when I created both a /etc/bluetooth/pin and /etc/bluetooth/givepin script with the same PIN number in both - reference to /bin/bluepin in /etc/bluetooth/hcid.conf seemed spurious and did not work. After much fiddling I got the Vaio and phone to pair and save a link key in /etc/bluetooth/link_key.
I also had a Plantronics M1000 bluetooth headset which I was fairly seriously unimpressed by overall and did not get the Vaio to even discover under Linux.
I also tried two other single-part no-cable approaches.
My Nokia NCP-2 PCMCIA card worked fine in my old PCG-N505 laptop under RH6.2, so I thought this would be a quick fix in the new machine, even though this card has no GPRS or 1900MHz support. The key to getting it to work before was to apply a patch to serial_cs, as the NCP-2 otherwise looks like a double device to the kernel. However, despite the fact this patch had long since been merged back into the main release, I could not get this card to work with at all. Instead, I get an unenlightening error message:
Unable to free unallocated resourceWith no obvious cure - possibly I have messed up my /etc/pcmcia/config.opts file, though the other suspect may be the change of using the yenta_socket rather then pcmcia_cs code. I also now have similar problems with my Adaptec SCSI and some IDE PCMCIA cards (including the PCGA-CD51 CD-ROM) , which had worked when I first installed RH9.0 on the SRX-51 :-( Pointers very welcome.
The other attempt was with a USB/IrDA dongle, not least as it would also allow cable-free connection to my Psion. I bought a Sigmatel 4012 (USB device ID 66f:4200:8) dongle, mainly as it could plug straight into the USB port. Initially there were no Linux device drivers for this, but it now looks like there is experimental support from kernel 2.5.7 - will try in due course :-)
All this was complicated by the menu of possible serial devices in kppp not including /dev/ttyUSB*, /dev/rfcomm*, or /dev/HSF*, needing much swinging around of /dev/modem via symlinks - probably I could fix this by diddling with the kppp source.
I always have hassle with multimedia stuff, and this machine is no exception :-( Initially confused by Windows claims there was a Yahama device in there, in fact what was needed was "CONFIG_SOUND_ICH=m" for the Intel 810. Have had no luck getting the RealPlayer Mozilla plug-in to work.
As none of the function keys are supported in the BIOS c/o of APM, in order to force the video signal to the external SVGA display dongle it is necessary to use the i810switch utility - works nicely.
After several monthss work on this machine, It was time to back it up. For this is I used a SimpleTech PCMCIA IDE hard disk controller and a spare 2.5" 40Gb disk, which worked care of the ide-cs module. Unfortunately of the various Linux partition tools only cfdisk proved reliable for creating partitions with the exact same number of sectors on a disk of different geometry, and I had to resort to PartitionMagic to copy the Windows partitions wholesale. Once done, backing up via dd on a per-partition basis seems fine, if slow though.
What I have recently succeeded in doing is copying the Linux partitions off this machine onto a spare 20Gb hard disk, which is now happily living in my old N505 Vaio (together with GRUB and a copy of its old W98 parition). The hardware is sufficiently similar the same RH9+2.4.20 kernel kernel boots and runs fine, so I've both given it an instant upgrade and created an emergency standby laptop :-) Some tweaking of modules, XFree86 and other system files was needed, I will attempt to document all the changes needed here in due course.
The APM-based suspend on my N505 worked nicely, and I do not regard the lack of support for resume/suspend in ACPI as necessarily a step forward ! Once am feeling brave I will give swsusp.sourceforge.net a go.
Next on the list is probably to get GPRS working - doubtless this will be as fiddly, expensive and under-performing as other GSM-based mobile data solutions, roll on proper public 802.11 access....
What would be really cool would be to get LinPhone SIP VoIP working, with a bluetooth headset as the audio device, but this looks to be highly unstraightforward.
I found the following web pages invaluable in getting all of this up, and would like to express my sincere thanks to all the people who worked on them.
Last updated 16-Jan-04