By menno on Dec 18, 2008
Get it here:
Get it here:
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.)
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.
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.
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.
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.
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
usbcopy tools from the Distro Constructor project.
$ hg clone ssh://email@example.com/hg/caiman/distro_constructor $ 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 -vThe 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
rgedriver 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 \^D
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...
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.configChange -I to point to where you keep the ON sources:
# # Common configuration infomations for all platforms # DRV = myk include version DFLAGS = -DDEBUG -DDEBUG_LEVEL=0 -DGEM_DEBUG_LEVEL=0 \\ -DTX_BUF_SIZE=256 -DRX_BUF_SIZE=256 \\ -I /export/home/ml93401/ws/onnv-gate/usr/src/uts/common change appropriately # CFGFLAGS = -UCONFIG_OO \\ -DGEM_CONFIG_POLLING \\ -DGEM_CONFIG_VLAN -UCONFIG_HW_VLAN \\ -DGEM_CONFIG_CKSUM_OFFLOAD \\ -DGEM_CONFIG_GLDv3 -DSOLARIS10 LDFLAGS += -dy -N misc/mac -N drv/ipBuild and install the driver:
$ make $ su # ./adddrv.shAfter 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: iwi0Creating a DomU now works fine (as expected). If only I had more memory in this laptop...
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:
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:
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.
No bookmarks in folder
No bookmarks in folder