Thursday Dec 18, 2008

Dutch OpenSolaris mirror

Bart Muijzer reports that the fine folks at NLUUG are now offering the latest OpenSolaris 2008.11 release for download on their site. They rsync daily, so all future OpenSolaris releases will show up there within a day of their release.

Get it here:

Thursday Nov 06, 2008

Support for the Intel 945GME

The fix for the Intel 945GME (6738342) has just been integrated in build 103. This makes X work out of the box on recent mini-notebooks such as my Medion Akoya E1210 (aka MSI Wind 100), the Acer Aspire One and some EEE PC models.

Together with the fix for the rge driver (6717107) that was integrated in build 99 and the fix for the keyboard problem (6695011) that was integrated in build 100, this makes Solaris work almost out-of-the-box on the E1210 (the only thing not yet supported is the wireless interface, but 14 Euros gets you a supported Intel mini PCIe wireless adapter.)

Monday Aug 18, 2008

Running Solaris on the Medion Akoya E1210 - Update

After getting OpenSolaris 2008.11 and Solaris Nevada to run on the Medion Akoya E1210 with some workarounds, I spent some evenings and a rainy Sunday on getting things to work even better.

  • WiFi

    The WiFi chipset in this system is the Ralink RT2790 (pci1814,781) which isn't supported by the ral(7D) driver yet. I filed 6736786 Need support for Ralink RT2790 for this and donated my WiFi card to the folks in Beijing so they have the hardware to test with.

  • Ethernet

    The Realtek 8101E chipset (pci10ec,8136) is not yet supported by the rge(7D) driver in current releases, but it is being worked on (6717107 Need to support Realtek 8102EL and new 8101E variants).

    I built a copy of the driver with the suggested fix listed in the bug, but the driver still failed to work properly on my system with IP hardware checksum offload enabled. It turned out that the chipset is a slightly different version of the 8101E than the 8101E_B listed in CR 6717107. Unlike other all other chipsets supported by the rge driver, these don't support hardware checksum, so the driver must disable hardware checksum offload for these chipsets. The following patch against the current version of rge(7D) makes this particular chipset work without having to disable IP hardware checksum globally in /etc/system.

    The day after updating the bug with this patch, I received an email from one of the engineers in Beijing with an updated version asking if I could run the HCTS network test on my system (since they don't have this particular variant). The new driver passes the HCTS, so this should work out of the box once the fix for 6717107 is integrated.

  • Graphics

    Starting X fails horribly:

    (EE) GARTInit: Unable to open /dev/agpgart (Resource temporarily unavailable)
    (WW) intel(0): /dev/agpgart is either not available, or no memory is available
    for allocation.  Using pre-allocated memory only.
    drmOpenDevice: node name is /dev/dri/card0
    drmOpenDevice: open result is -1, (No such device or address)
    drmOpenDevice: open result is -1, (No such device or address)
    drmOpenDevice: Open failed
    drmOpenDevice: node name is /dev/dri/card0
    drmOpenDevice: open result is -1, (No such device or address)
    drmOpenDevice: open result is -1, (No such device or address)
    drmOpenDevice: Open failed
    [drm] failed to load kernel module "i915"
    (II) intel(0): [drm] drmOpen failed
    (EE) intel(0): [dri] DRIScreenInit failed. Disabling DRI.
    (\*\*) intel(0): Framebuffer compression enabled
    (\*\*) intel(0): Tiling enabled
    (==) intel(0): VideoRam: 7932 KB
    (II) intel(0): Attempting memory allocation with tiled buffers.
    (EE) intel(0): Failed to allocate framebuffer. Is your VideoRAM set too low?
    (II) intel(0): Tiled allocation failed.
    (WW) intel(0): Couldn't allocate tiled memory, fb compression disabled
    (II) intel(0): Attempting memory allocation with untiled buffers.
    (WW) intel(0): Failed to allocate EXA offscreen memory.
    (II) intel(0): Untiled allocation failed.
    (EE) intel(0): Couldn't allocate video memory
    Fatal server error:
    AddScreen/ScreenInit failed for driver 0

    Using the VESA driver by creating an xorg.conf file worked of course, but that is kind of lame (Compiz anyone?). From the error messages it seemed that agpgart and DRI were not supported for the Intel i945GME.

    Looking through the code and webrevs of the initial agpgart and DRI putbacks and for adding i965 support later on, I was able to cook up the following patch that adds agpgart and DRI support for the i945GME. I have filed 6738342 Need support for Intel i945GME to track this. The patch has been lightly tested on my system only, so use with care.

With Ethernet working, a supported WiFi replacement card in the mail, and Compiz now happily running on this Medion Akoya E1210 mini notebook, I declare victory!

With some DIY (I bought this at a DIY store after all), this EUR 399 mini notebook turns out to be a fine Solaris system.

Saturday Aug 09, 2008

OpenSolaris 2008.11 on the Medion Akoya E1210

With ultra portable notebooks being all the rage and even a Dutch DIY franchise ("Dat zeg ik: GAMMA") selling them, I bought myself a Medion Akoya E1210 mini notebook. This is a rebadged MSI Wind (10" display @ 1024x600, 1.6 GHz Atom N270 CPU, 1 GB memory, 80 GB hard disk, wired and wireless LAN). Rather than using the preinstalled Windows XP, I wanted to run Solaris on this of course. The short version: it almost works.

Since this system does not have a CD to boot from, I created a bootable OpenSolaris USB stick using the usbgen and usbcopy tools from the Distro Constructor project.

$ hg clone ssh://
$ cd distro_constructor/tools
$ su
# ./usbgen /path/to/osol-0811-93.iso /path/to/osol-0811-93.usb /tmp/foo

This will take a couple of minutes. After that copy the generated image to the USB stick:

# ./usbcopy /path/to/osol-0811-93.usb

Insert the USB stick, power on, press F11 and select the USB stick as the boot device

This notebook suffers from the same timing issue as the ASUS Eee PC, so as a workaround change GRUB entry to read:

kernel$ /platform/i86pc/kernel/$ISADIR/unix -v
The system then boots and tries to start X without success (the good news is that the built-in USB webcam is recognized out of the box). The wired ethernet interface (RealTek 8101E) is supported by the rge driver and is plumbed automatically. It doesn't work completely however, pinging another host works but any serious networking like ssh fails silently. Disabling IP hardware checksumming fixes that:

# mdb -kw
> ip`dohwcksum/W 0
dohwcksum:      0               =       0x0

Now that I have networking up, I can save a copy of the original disk contents (just in case) and see if I can get OpenSolaris installed on the disk using a remote display so I don't have to manually apply the above workarounds each time. More on that later.

Update: I got X to run using this tip: Indiana: VESA if you need it. It's only VESA but it will at least make X usable until I figure out how to get the Intel driver working...

Monday Dec 24, 2007

Marvell Yukon ethernet and xVM

When xVM was integrated into Nevada in build 75, I immediately tried it on my laptop (a Toshiba M3). Only to find out that it didn't work because xVM requires GLD version 3 network drivers. My particular type of M3 unfortunately has a Marvell Yukon gigabit ethernet adapter and the skge driver from SysKonnect I had been using for the past years is not a GLD v3 driver.

While looking for a more recent version of skge (hoping for GLD v3 support in skge), I came across the myk driver written by Masayuki Murayama. This driver can be compiled as a GLD v3 driver and a quick look in the install script showed that the PCI ID of my Yukon chip was supported by myk. To compile a GLD v3 version of the driver you'll need the driver sources and a recent copy of the ON sources (for the required GLD header files).

$ gzcat myk-2.5.0.tar.gz | tar xf -
$ cd myk-2.5.0
$ rm Makefile.config
$ ln -s Makefile.config_gld3 Makefile.config
$ vi Makefile.config
Change -I to point to where you keep the ON sources:
# Common configuration infomations for all platforms
DRV     = myk
include version
          -DTX_BUF_SIZE=256 -DRX_BUF_SIZE=256 \\
          -I /export/home/ml93401/ws/onnv-gate/usr/src/uts/common  change appropriately
           -DGEM_CONFIG_POLLING \\

LDFLAGS += -dy -N misc/mac -N drv/ip
Build and install the driver:
$ make
$ su
# ./
After a reboot we should have a GLD v3 driver usable for xVM (if the type is not 'legacy' it is a GLD v3 driver):
# dladm show-link
myk0            type: non-vlan  mtu: 1500       device: myk0
iwi0            type: non-vlan  mtu: 1500       device: iwi0
Creating a DomU now works fine (as expected). If only I had more memory in this laptop...

Wednesday Sep 12, 2007

Resource control observability using kstats

One of the things I sometimes miss when using resource controls, is a simple way to see what the current usage of a particular resource control by a project or zone is. While finding out the limit for the rctl is no problem (for that we have prctl(1)), getting the actual usage requires work and implementation knowledge.

For instance, we could get the amount of System V shared memory used by a project using ipcs -Jam and some parsing of its output. Or fire up mdb(1) and lookup the value for kpd_shmmax in the project's kproject_t struct. And, if we wanted to get the usage of another resource control (say the number of lwps), we'd need to use another tool (prstat -LJc) or know that the number of lwps is kept in the kpj_nlwps member. Hardly usable for more than the occasional peek. Plus that relying on kernel implementation details such as these structure members is highly inadvisable as they may change in the future (they probably won't, but they are not stable interfaces so don't rely on them).

The addition of the swap and locked memory resource controls by PSARC 2006/598 Swap resource control; locked memory RM introduced a number of kstats for observability:

  • caps:{zoneid}:swapresv_zone_{zoneid}
  • caps:{zoneid}:lockedmem_zone_{zoneid}
  • caps:{zoneid}:lockedmem_project_{projid}

These kstats have a 'value' statistic for the current limit and a 'usage' statistic that holds the current usage:

$ kstat -c zone_caps -n swapresv_zone_0
module: caps                            instance: 0     
name:   swapresv_zone_0                 class:    zone_caps
        crtime                          0
        snaptime                        102512.50351337
        usage                           532168704
        value                           18446744073709551615
        zonename                        global

Exposing these values as kstats gives us exactly what is needed, a simple, well defined method to get the limit and usage for a resource control.

To satisfy my curiosity and to see what changes would be needed, I spent some evenings creating a prototype that adds kstats for all project.\* and zone.\* resource controls. The following extra kstats are available in the prototype:

  • caps:{projid}:contracts_project_{projid}
  • caps:{projid}:msgids_project_{projid}
  • caps:{zoneid}:msgids_zone_{zoneid}
  • caps:{projid}:nlwps_project_{projid}
  • caps:{zoneid}:nlwps_zone_{zoneid}
  • caps:{projid}:ntasks_project_{projid}
  • caps:{projid}:semids_project_{projid}
  • caps:{zoneid}:semids_zone_{zoneid}
  • caps:{projid}:shmids_project_{projid}
  • caps:{zoneid}:shmids_zone_{zoneid}
  • caps:{projid}:shmmem_project_{projid}
  • caps:{zoneid}:shmmem_zone_{zoneid}

Getting a list of the current usage of all resource controls is now as simple as typing:

$ kstat -p caps:::usage
caps:0:contracts_project_0:usage        33
caps:0:contracts_project_1:usage        2
caps:0:contracts_project_101:usage      0
caps:0:cryptomem_project_0:usage        0
caps:5:nlwps_project_0:usage    108
caps:5:nlwps_zone_5:usage       108
caps:5:ntasks_project_0:usage   15
caps:5:semids_project_0:usage   0
caps:5:semids_zone_5:usage      0
caps:5:shmids_project_0:usage   1
caps:5:shmids_zone_5:usage      1
caps:5:shmmem_project_0:usage   172032
caps:5:shmmem_zone_5:usage      172032
caps:5:swapresv_zone_5:usage    95178752

And now that we have the numbers as kstats, we can use any tool to massage the numbers into a form that suits us. The screenshot below is from a hacked up version of one of the JKstat demo programs and shows a graph of the number of LWPs in all projects and zones during boot and shutdown of a Zone.





« July 2016

No bookmarks in folder


No bookmarks in folder