VMware – 14.1.0 released – OK with Kernel 4.14, Still Broken with 4.15, and a Nasty Hack to Fix..

Just updated to VMware Workstation 14.1.0, and release notes are here:  https://docs.vmware.com/en/VMware-Workstation-Pro/14.0.0/rn/workstation-141-release-notes.html

This now works OK with Kernel 4.14 (tested with 4.14.8) but vmmon is still broken with Kernel 4.15 (tested with 4.15-rc4):

/tmp/modconfig-04hK9s/vmmon-only/linux/hostif.c: In function ‘HostIF_InitUptime’:
/tmp/modconfig-04hK9s/vmmon-only/linux/hostif.c:1770:4: error: implicit declaration of function ‘init_timer’; did you mean ‘init_timers’? [-Werror=implicit-function-declaration]
/tmp/modconfig-04hK9s/vmmon-only/linux/hostif.c:1771:31: error: assignment from incompatible pointer type [-Werror=incompatible-pointer-types]
 uptimeState.timer.function = HostIFUptimeResyncMono;
cc1: some warnings being treated as errors
make[2]: *** [scripts/Makefile.build:310: /tmp/modconfig-04hK9s/vmmon-only/linux/hostif.o] Error 1
make[1]: *** [Makefile:1502: _module_/tmp/modconfig-04hK9s/vmmon-only] Error 2
make[1]: Leaving directory '/usr/src/linux-4.15-rc4'
make: *** [Makefile:110: vmmon.ko] Error 2
make: Leaving directory '/tmp/modconfig-04hK9s/vmmon-only'
etc... etc...

As the compile fail appeared to be similar to the one with VMware 4.0.0 – for which a patch is available – I was able to do a ‘nasty hack‘ by creating and then applying a patch-set from the 4.15-patched VMware 4.0.0 versions of vmmon-only/linux/hostif.c and driver.c, against their VMware 4.1.0 equivalents, and copying across the ‘new’ header file vmmon-only/include/compat_timer.h.   This did work, but is – obviously – not an ideal solution, and hopefully someone with the necessary skills will be able to produce a ‘proper’ patch, soon..

Robert Gadsdon.  December 21, 2017.

IA64 – Hardware Issues Resolved, and Potential ‘Modern’ Distro..

Encountered some frustrating hardware conflicts when adding extra i/o cards to the RX2600, but eventually deduced that the ‘management board’ was causing these, and so disconnected it.

I manage to find a low-cost Adaptec SATA board for PCIX, and also a PCIX-to-PCI-Express converter, which enabled me to add USB3 connectivity, which AFAIK was never available on a PCIX board..   I never managed to get the AGP/PCIX combo to work, and so stayed with the all-PCIX connector board, and managed to get KDE working successfully, using the old Fedora 9 nv driver..

[root@rgia64 ~]# lspci
00:01.0 USB Controller: NEC Corporation USB (rev 41)
00:01.1 USB Controller: NEC Corporation USB (rev 41)
00:01.2 USB Controller: NEC Corporation USB 2.0 (rev 02)
00:02.0 IDE interface: Silicon Image, Inc. SiI 0649 Ultra ATA/100 PCI to ATA Host Controller (rev 02)
00:03.0 Ethernet controller: Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 (rev 0d)
20:01.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 07)
20:01.1 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 07)
20:02.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5701 Gigabit Ethernet (rev 15)
40:01.0 PCI bridge: PLX Technology, Inc. PEX 8114 PCI Express-to-PCI/PCI-X Bridge (rev bd)
41:00.0 USB Controller: Renesas Technology Corp. Unknown device 0015 (rev 02)
60:01.0 RAID bus controller: Adaptec AAC-RAID (rev 01)
80:01.0 VGA compatible controller: nVidia Corporation NV34GL [Quadro NVS 280 PCI] (rev a1)

I am guessing that the USB3 card (Renesas..) shows up as ‘unknown device’ as Fedora 9’s version of the USB subsystem is not yet capable of recognising it..?

I discovered that Gentoo Linux still had a – relatively – up-to-date IA64 version of their Distro, and more details are here:  https://wiki.gentoo.org/wiki/Handbook:IA64 .   I tried their ‘latest’ boot CD, but it failed to be recognised, and I found a forum post that mentioned that the last ‘working’ version of this was from 2016, but that is something I can work with, as it includes a 4.x kernel, and there is a more recent (December 2017) equivalent of a rootfs fileset (‘stage3…’) available..     I am by no means an expert on Gentoo, having used Red Hat – later Fedora – since 1997(!), so this will be a useful learning exercise.   More on this later…

I also understand that Debian are planning to revive their IA64 project (see comments below my original article – http://rglinuxtech.com/?p=2111 )

Robert Gadsdon December 17, 2017.


ARM64 – Fedora 27, UEFI and Pi3..

I decided – after some time – to do some more with the Raspberry Pi 3, and set it up as a small network print server..

As there was now an ‘official’ version of Fedora 27 for the Pi3, I decided to use this..   Details are here, and links to aarch64 images are near the bottom of the article..   https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi

This version uses u-boot to load EFI, which then boots the Pi3 in the ‘traditional’ way..   After creating the system on the micro-sd card, I ‘saved/restored’ the root filesystem, and modified the partition layout to make it resident on a ‘primary’ partition, rather than ‘extended’, but this was just a personal preference..

Device       Boot    Start   End       Sectors   Size  Id Type
/dev/mmcblk0p1 *     2048    342015    339968    166M  6  FAT16
/dev/mmcblk0p2       342016  2439167   2097152   1G    83 Linux
/dev/mmcblk0p3       2439168 3487743   1048576   512M  82 Linux swap / Solaris
/dev/mmcblk0p4       3487744 125042687 121554944 58G   83 Linux
# cat /etc/fstab
/dev/mmcblk0p1 /boot/efi vfat umask=0077,shortname=winnt 0 2
/dev/mmcblk0p2 /boot     ext4 defaults 1 2
/dev/mmcblk0p3 swap      swap defaults 0 0
/dev/mmcblk0p4 /         ext4 defaults 1 1

As I needed to use a serial console, I uncommented  enable_uart=1 in config.txt, and made the appropriate changes to the kernel boot command line..

As usual, the standard Fedora kernel config included many unwanted device selections and options, and so I decided to create a more Pi3-specific one..   A search found some possible candidates, and I tried several of these..

As a result, I found that the Broadcom GPU/DRM driver caused multiple tombstones during the boot process, and killed the HDMI monitor connection:

 OK ] Mounted Temporary Directory (/tmp).
vc4_hdmi 3f902000.hdmi: vc4-hdmi-hifi <-> 3f902000.hdmi mapping ok
vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops [vc4])
vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops [vc4])
vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4])
vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops vc4_crtc_ops [vc4])
vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops vc4_crtc_ops [vc4])
vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops vc4_crtc_ops [vc4])
vc4-drm soc:gpu: bound 3fc00000.v3d (ops vc4_v3d_ops [vc4])
[drm] Initialized vc4 0.0.0 20140616 for soc:gpu on minor 0
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] Driver supports precise vblank timestamp query.
Console: switching to colour frame buffer device 240x67
vc4-drm soc:gpu: fb0: frame buffer device
[ OK ] Started udev Wait for Complete Device Initialization.
[ OK ] Started LVM2 metadata daemon.
[ OK ] Started Monitoring of LVM2 mirrors,…sing dmeventd or progress polling.
[ OK ] Reached target Local File Systems (Pre).
 Starting File System Check on /dev/mmcblk0p1...
 Starting File System Check on /dev/mmcblk0p2...
[ OK ] Started File System Check on /dev/mmcblk0p1.
[ OK ] Started File System Check on /dev/mmcblk0p2.
 Mounting /boot...
[CRTC:67:crtc-2] vblank wait timed out
------------[ cut here ]------------
WARNING: CPU: 2 PID: 21 at drm_atomic_helper_wait_for_vblanks.part.7+0x248/0x278 [drm_kms_helper]
Modules linked in: vc4 snd_soc_core snd_pcm_dmaengine snd_seq snd_seq_device snd_pcm snd_timer snd smsc95xx drm_kms_helper usbnet cfbfillrect cfbimgblt mii cfbcopyarea drm syscopyarea sysfillrect sysimgblt fb_sys_fops uio_pdrv_genirq uio efivarfs pwm_bcm2835 i2c_bcm2835 ipv6
CPU: 2 PID: 21 Comm: kworker/2:0 Not tainted 4.14.5 #1
EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
Hardware name: raspberrypi rpi/rpi, BIOS 2017.09 10/10/2017
Workqueue: events output_poll_execute [drm_kms_helper]
task: ffffffc03c85c600 task.stack: ffffff80088c0000
PC is at drm_atomic_helper_wait_for_vblanks.part.7+0x248/0x278 [drm_kms_helper]
LR is at drm_atomic_helper_wait_for_vblanks.part.7+0x248/0x278 [drm_kms_helper]
pc : [<ffffff80007423e8>] lr : [<ffffff80007423e8>] pstate: 40000145
sp : ffffff80088c3aa0
................     etc... etc...

So, I disabled this ( ‘Broadcom VC4 Graphics‘ ), and just used the framebuffer option..     The device will (obviously) be used ‘headless’, so this is not an issue..

It was a refreshing change to be able to use the x86-standard kernel compile/install commands, and to be able to use grub-customizer to handle boot options etc..   I set up the dtb link in the /boot directory to match the Fedora example..

I did find slightly confusing behaviour with the console options…   I had (temporarily) modified grub.cfg to include the usual console=tty0 console=ttyS0,115200n8, and this worked OK at first boot, but after I had compiled/installed later kernels, and included this in the grub parameters, this stopped working, and there was no output on the serial/uart connection at boot time, after the usual grub menu dialogue..

I then discovered that – for some reason – the ports had changed, and now required console=tty1 console=ttyS1,115200n8. This worked OK for the Fedora-supplied kernels, but not for the self-compiled ones..   I then found that the uart/port selections in the kernel configs I was testing had been – deliberately – disabled, probably due to the fact that these console options cause performance degradation, because of design tradeoffs on the Pi3..

So, I modified the kernel config in the appropriate areas:

Select ‘Console on 8250/16550 serial port
Change ‘Maximum 8250/16550 and compatible serial ports‘  to ‘4
Change ‘Maximum 8250/16550 serial ports to register at runtime‘  to ‘4

After this, all was well:

[ 0.000349] console [tty1] enabled
[ 0.722248] 3f215040.serial: ttyS1 at MMIO 0x0 (irq = 61, base_baud = 31250000) is a 16550
[ 1.279189] console [ttyS1] enabled
Fedora 27 (Workstation Edition)
Kernel 4.14.5 on an aarch64 (ttyS1)
$ uname -a
Linux rgprint 4.14.5 #2 SMP PREEMPT Mon Dec 11 23:20:51 PST 2017 aarch64 aarch64 aarch64 GNU/Linux

I have put a copy of the  kernel config at https://pastebin.com/thmebsn0

Robert Gadsdon.  December 12, 2017.


NVIDIA – Kernel 4.15-rc3 fixes GPL Problem..

Just updated the test system to Kernel 4.15-rc3, and the GPL issue for NVIDIA drivers has been fixed, as mentioned – vaguely – in the brief details here:  http://lkml.iu.edu/hypermail/linux/kernel/1712.1/01379.html.

NVIDIA driver 384.98, with the first 4.15 patch (see http://rglinuxtech.com/?p=2134 ), now compiles and loads OK:

Building modules, stage 2.
 MODPOST 4 modules
 CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.98-415/kernel/nvidia-drm.mod.o
 LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.98-415/kernel/nvidia-drm.ko
 CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.98-415/kernel/nvidia-modeset.mod.o
 LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.98-415/kernel/nvidia-modeset.ko
 CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.98-415/kernel/nvidia-uvm.mod.o
 LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.98-415/kernel/nvidia-uvm.ko
 CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.98-415/kernel/nvidia.mod.o
 LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.98-415/kernel/nvidia.ko
make[2]: Leaving directory '/usr/src/linux-4.15-rc3'
make[1]: Leaving directory '/usr/src/linux-4.15-rc3'

Robert Gadsdon.   December 10, 2017.

IA64 – Update to Kernel 4.15-rc1..

Just updated the Itanium2 system (RX2600/ZX9000 hybrid) to kernel 4.15-rc1, but encountered a problem with the NFSv4 code.    Recent changes have exposed problems with ‘older’ compilers, and the system currently has GCC 4.3 (on Fedora 9/IA64):

 CALL scripts/checksyscalls.sh
<stdin>:1185:2: warning: #warning syscall perf_event_open not implemented
<stdin>:1239:2: warning: #warning syscall seccomp not implemented
<stdin>:1317:2: warning: #warning syscall pkey_mprotect not implemented
<stdin>:1320:2: warning: #warning syscall pkey_alloc not implemented
<stdin>:1323:2: warning: #warning syscall pkey_free not implemented
<stdin>:1326:2: warning: #warning syscall statx not implemented
 CHK scripts/mod/devicetable-offsets.h
 CHK include/generated/compile.h
 CHK include/generated/nr-irqs.h
 AR fs/nfs/nfs.o
 AR fs/nfs/nfsv2.o
 AR fs/nfs/nfsv3.o
 CC fs/nfs/nfs4state.o
fs/nfs/nfs4state.c:74: error: unknown field ‘seqid’ specified in initializer
fs/nfs/nfs4state.c:74: warning: missing braces around initializer
fs/nfs/nfs4state.c:74: warning: (near initialization for ‘invalid_stateid.<anonymous>.data’)
fs/nfs/nfs4state.c:74: warning: overflow in implicit constant conversion
fs/nfs/nfs4state.c:75: error: unknown field ‘other’ specified in initializer
fs/nfs/nfs4state.c:75: error: extra brace group at end of initializer
fs/nfs/nfs4state.c:75: error: (near initialization for ‘invalid_stateid.<anonymous>’)
fs/nfs/nfs4state.c:75: warning: excess elements in union initializer
fs/nfs/nfs4state.c:75: warning: (near initialization for ‘invalid_stateid.<anonymous>’)
make[2]: *** [fs/nfs/nfs4state.o] Error 1
make[1]: *** [fs/nfs] Error 2
make: *** [fs] Error 2

This is a ‘known problem’ and has – at least – been documented:  https://lkml.org/lkml/2017/11/18/224

The workaround – for the time being – is to simply deselect NFSv4 support in the Kernel config, and then the compile completes, and the system boots OK:

Starting cups: [ OK ]
Starting anacron: [ OK ]
Fedora release 9 (Sulphur)
Kernel 4.15.0-rc1 on an ia64 (/dev/ttyS0)
rgia64 login:
[root@rgia64 ~]# uname -a
Linux rgia64 4.15.0-rc1 #1 SMP Fri Dec 1 13:57:03 PST 2017 ia64 ia64 ia64 GNU/Linux

I have – so far – successfully swapped out the RX2600 all-PCI-X cage for a ZX9000 PCI-X/AGP one, and installed a NVIDIA Quadro 900 dual-DVI video card, but have not yet managed to get a more ‘modern’ version of Nouveau working, and so am still using framebuffer, and VNC.

Robert Gadsdon.  December 1, 2017.


NVIDIA – Fix for Kernel 4.15, but GPL Problem – Yet Again..

Thanks to milhouse, there is a set of two patches available for NVIDIA 384.98 and (legacy) 340.104 with Kernel 4.15-rc1, and details are here:   https://devtalk.nvidia.com/default/topic/1026911/linux/4-15-rc1-patches-for-384-98-and-340-104/

The first patch fixes the compile problems, but the load fails with yet another case of GPL incompatibility:

 Building modules, stage 2.
 MODPOST 4 modules
FATAL: modpost: GPL-incompatible module nvidia-drm.ko uses GPL-only symbol 'ex_handler_refcount'
make[3]: *** [/usr/src/linux-4.15-rc1/scripts/Makefile.modpost:92: __modpost] Error 1
make[2]: *** [/usr/src/linux-4.15-rc1/Makefile:1506: modules] Error 2
make[2]: Leaving directory '/usr/src/linux-4.15-rc1'
make[1]: *** [Makefile:146: sub-make] Error 2
make[1]: Leaving directory '/usr/src/linux-4.15-rc1'
make: *** [Makefile:81: modules] Error 2

The second patch is technically ‘illegal’, as it changes the licence in ~/kernel/nvidia-drm/nvidia-drm-linux.c from MIT to GPL… but does allow the driver to load successfully..

This GPL problem with NVIDIA seems to occur with monotonous regularity for each new kernel release, now..   If past experience is anything to go by, this will probably be fixed – eventually – by some kindly kernel dev opting to change the licensing requirement back to non-GPL-only..

I have done some digging around, and the change in kernel code would appear to be this mega-patch:  https://github.com/torvalds/linux/commit/b24413180f5600bcb3bb70fbed5cf186b60864bd

Another option, which may not be suitable for many systems – is to compile without drm..

# export NV_EXCLUDE_KERNEL_MODULES=nvidia-drm
# make ......etc..

Robert Gadsdon.   November 28, 2017.

VMware – Fix for Kernel 4.15-rc1..

Thanks – again – to mkubecek, there is now a fix for VMware 14.0.0 and Kernel 4.15 – and details are here:   https://github.com/mkubecek/vmware-host-modules/commit/562121d7bc06

The fix involves changes to vmmon-only/linux/driver.c and vmmon-only/linux/hostif.c, and a new file: vmmon-only/include/compat_timer.h .    I have tested this on 4.15-rc1, and now vmmon compiles, and vmware loads/runs, correctly.

Robert Gadsdon.  November 27, 2017.

Kernel – 4.15-rc1 is Out – Breaks VMware and NVIDIA…

Kernel 4.15-rc1 has been released, and brief details are here:  http://lkml.iu.edu/hypermail/linux/kernel/1711.3/00971.html

With VMware 14.0.0 – plus the 4.14 vmmon patch – vmmon breaks again:

/tmp/modconfig-hOVOTM/vmmon-only/linux/driver.c: In function ‘LinuxDriverInitTSCkHz’:
/tmp/modconfig-hOVOTM/vmmon-only/linux/driver.c:254:22: error: assignment from incompatible pointer type [-Werror=incompatible-pointer-types]
 tscTimer.function = LinuxDriverEstimateTSCkHzDeferred;
/tmp/modconfig-hOVOTM/vmmon-only/linux/driver.c:256:12: error: ‘struct timer_list’ has no member named ‘data’
 tscTimer.data = 0;
/tmp/modconfig-hOVOTM/vmmon-only/linux/driver.c: In function ‘init_module’:
/tmp/modconfig-hOVOTM/vmmon-only/linux/driver.c:338:4: error: implicit declaration of function ‘init_timer’; did you mean ‘init_timers’? [-Werror=implicit-function-declaration]
At top level:
/tmp/modconfig-hOVOTM/vmmon-only/linux/driver.c:981:1: warning: always_inline function might not be inlinable [-Wattributes]
 LinuxDriverSyncReadTSCs(uint64 *delta) // OUT: TSC max - TSC min
cc1: some warnings being treated as errors
make[2]: *** [scripts/Makefile.build:310: /tmp/modconfig-hOVOTM/vmmon-only/linux/driver.o] Error 1
make[2]: *** Waiting for unfinished jobs....
/tmp/modconfig-hOVOTM/vmmon-only/linux/hostif.c: In function ‘HostIF_InitUptime’:
/tmp/modconfig-hOVOTM/vmmon-only/linux/hostif.c:1779:4: error: implicit declaration of function ‘init_timer’; did you mean ‘init_timers’? [-Werror=implicit-function-declaration]
/tmp/modconfig-hOVOTM/vmmon-only/linux/hostif.c:1780:31: error: assignment from incompatible pointer type [-Werror=incompatible-pointer-types]
 uptimeState.timer.function = HostIFUptimeResyncMono;

NVIDIA 387.34 also fails to compile:

CONFTEST: is_export_symbol_gpl_refcount_dec_and_test
 CC [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-387.34/kernel/nvidia/nv-gpu-numa.o
 CC [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-387.34/kernel/nvidia/nv.o
/home/rgadsdon/kernel/NVIDIA-Linux-x86_64-387.34/kernel/nvidia/nv.c: In function ‘nv_start_rc_timer’:
/home/rgadsdon/kernel/NVIDIA-Linux-x86_64-387.34/kernel/nvidia/nv.c:3389:5: error: implicit declaration of function ‘init_timer’; did you mean ‘init_timers’? [-Werror=implicit-function-declaration]
/home/rgadsdon/kernel/NVIDIA-Linux-x86_64-387.34/kernel/nvidia/nv.c:3390:28: error: assignment from incompatible pointer type [-Werror=incompatible-pointer-types]
 nvl->rc_timer.function = nvidia_rc_timer;
/home/rgadsdon/kernel/NVIDIA-Linux-x86_64-387.34/kernel/nvidia/nv.c:3391:18: error: ‘struct timer_list’ has no member named ‘data’
 nvl->rc_timer.data = (unsigned long) nvl;
cc1: some warnings being treated as errors
make[3]: *** [/usr/src/linux-4.15-rc1/scripts/Makefile.build:311: /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-387.34/kernel/nvidia/nv.o] Error 1
make[2]: *** [/usr/src/linux-4.15-rc1/Makefile:1502: _module_/home/rgadsdon/kernel/NVIDIA-Linux-x86_64-387.34/kernel] Error 2
make[2]: Leaving directory '/usr/src/linux-4.15-rc1'
make[1]: *** [Makefile:146: sub-make] Error 2
make[1]: Leaving directory '/usr/src/linux-4.15-rc1'
make: *** [Makefile:84: modules] Error 2

More research needed, but no fixes found – so far..

Robert Gadsdon.   November 26, 2017.

IA64 – An Exercise in Nostalgia..

Ever since I spent some considerable time promoting HP’s IA64 Linux systems, way back in the early-2000’s, I have always wanted one for myself, and I recently managed to acquire an RX2600 1U server for a very reasonable price, and beef it up with some inexpensive parts from eBay..

The spec – at the moment – is 2x 1.5Ghz ‘Madison’ CPUs, and 8GB memory, and one 74GB U320 disk.. This basic chassis is identical to the one used for the ‘workstation’ version – the Z6000 – and I am planning to do a conversion, to allow better (AGP) graphics..

RX2600 Chassis

I had managed to track down the remaining IA64 versions of various Distros, and the ‘latest’ (2008..) one was Fedora 9, which is still available online, if you are able to do some digging.. I created a DVD install disk, and made a complete copy of the old repo, including all the packages..

This exercise was a good test of my install recollections from 9+ years ago, and was relatively straightforward.. As expected, there were a several things not there – or too ‘new’ – including EXT4 support. I settled on EXT3 for the time being, and this may be OK..

I had been cross-compiling the latest (4.14) kernels on my F27 x86_64 system, as – fortunately – there is still a viable ia64 cross-compiler available..

export ARCH=ia64
export CROSS_COMPILE=ia64-linux-gnu-

I also had to (re)remember all the old LILO stuff, as the system uses the EFI version of this – ELILO..

The server has 4 PCI-X slots (not PCI-Express..) and there are still a few i/o cards available for this.. It came with an old NVIDIA Quadro NVS280 card, and I was able to get a dual-hdmi connector ‘tail’ for this..

The install was only possible in ‘non-graphical’ mode, but this worked OK, and it was actually easier to use than the modern bells-and-whistles version.. IMHO..

At the end, I had a working system, running the ancient 2.6.25-14 kernel..

As the latest kernel still has some IA64 activity (although very little..) I decided to try to compile this natively, and get it running… More on this in a later article, but I did manage to get the compile to work, using a kernel config copied from the cross-compile testing, as I was unable to get any of the graphical configurators to work, and did not want to waste too much time..

Although there is some ‘nouveau’ content with FC9, I found that with nouveau configured in the kernel, the system started to boot and then crashed/re-booted, so I took nouveau support out for the time being (just using framebuffer)

Even with an ancient version of GCC (4.3.0) the kernel compile completed successfully, despite several warnings.. and after modifying the EFI and ELILO config a little – I actually got the system to boot:

 tg3 0000:20:02.0 eth1: Link is up at 1000 Mbps, full duplex
 tg3 0000:20:02.0 eth1: Flow control is on for TX and on for RX
 [rgadsdon@rgia64 ~]$ uname -a
 Linux rgia64 4.14.1 #1 SMP Tue Nov 21 06:19:05 PST 2017 ia64 ia64 ia64 GNU/Linux

So far, I have also got webmin to work:

Webmin IA64

That is all the progress to date, and my goal is to get MOCK working, and build an up-to-date Fedora 27 Distro, although this might be a touch too ambitious, as many of the tools to do this were never fully developed, and many projects on IA64 have been ‘abandoned’…

Robert Gadsdon..  November 21, 2017.

VMware – 12.5.8 Released – Still Incompatible..

There has been a new release of Workstation 12.5 – 12.5.8 – and the – rather vague – release notes are here:  https://docs.vmware.com/en/VMware-Workstation-Pro/12.0/rn/workstation-1258-release-notes.html

I tested this with a ‘clean’ install on my cash-and-burn system, and basically, it suffers from the same compatibility problems as 12.5.7.    GCC7, Fedora 26/27, and Kernel 14.x all cause it to fail.

# vmware ---> returns to cursor..
# vmware-modconfig --console --install-all
Failed to get gcc information.

Compiling vmmon (manually) with Kernel 14.0.0:

/usr/lib/vmware/modules/source/vmmon-only/linux/hostif.c: In function ‘HostIF_EstimateLockedPageLimit’:
/usr/lib/vmware/modules/source/vmmon-only/linux/hostif.c:1597:31: error: implicit declaration of function ‘global_page_state’; did you mean ‘global_numa_state’? [-Werror=implicit-function-declaration]
 unsigned int lockedPages = global_page_state(NR_PAGETABLE) +
cc1: some warnings being treated as errors
make[2]: *** [scripts/Makefile.build:315: /usr/lib/vmware/modules/source/vmmon-only/linux/hostif.o] Error 1
make[1]: *** [Makefile:1503: _module_/usr/lib/vmware/modules/source/vmmon-only] Error 2
make[1]: Leaving directory '/usr/src/linux-4.14'
make: *** [Makefile:120: vmmon.ko] Error 2

As I have already migrated to Workstation 14.0.0, I did not do any further testing..    I would speculate that the convoluted workarounds and patches used for 12.5.7 may still work with 12.5.8…     Hopefully there will be a 14.0.1 soon?

Robert Gadsdon.  November 17, 2017.