IA64 – Updated to 4.17-rc1..

Posted on by April 16, 2018
Reply

Updated the IA64 system (HP RX2600) to 4.17-rc1, and the compile and install/boot was without incident..    The python-related warning with 4.16 was no longer present.. (see http://rglinuxtech.com/?p=2222 ).

...............
[ OK ] Started Getty on tty1.
[ OK ] Reached target Login Prompts.
[ OK ] Started Login Service.
[ OK ] Reached target Multi-User System.
[ OK ] Reached target Graphical Interface.

This is rgia64.unknown_domain (Linux ia64 4.17.0-rc1) 13:07:54
........................
# uname -a
Linux rgia64 4.17.0-rc1 #1 SMP Mon Apr 16 12:18:06 PDT 2018 ia64 Madison GenuineIntel GNU/Linux

Robert Gadsdon.  April 16, 2018.

Kernel – 4.17-rc1 Out – OK with Latest NVIDIA and VMware..

Posted on by April 15, 2018
Reply

Kernel 4.17-rc1 has been released, and brief details are here:  http://lkml.iu.edu/hypermail/linux/kernel/1804.1/06654.html

With the latest code-on-git milestone reached, there is speculation that a version bump to 5.x might be a possibility – but not just yet!

The latest NVIDIA driver (396.18) and VMware (14.1.1 – vmmon and vmnet) all compile OK..

Robert Gadsdon.   April 15, 2018

NVIDIA – Finally, a 4.16-Compatible Driver..

Posted on by April 10, 2018
Reply

NVIDIA has released beta driver 396.18, and – at last – this is compatible with Kernel 4.16 (tested with 4.16.1).

Details are here:  http://www.nvidia.com/Download/driverResults.aspx/133571/en-us     The ‘Release Highlights’ do not even mention kernel support..

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

Robert Gadsdon.   April 10, 2018

Kernel – Interim Changes for 4.17 – OK So Far..

Posted on by April 8, 2018
Reply

Testing the changes submitted to date for Kernel 4.17-rc1, which is – of course – not due out just yet..   Kernel version obtained from https://github.com/torvalds/linux today – April 8.

Latest VMware – 14.1.1 – vmnet/vmmon compile OK, and so does the latest NVIDIA – 390.48, with the 4.16 patch..

More changes to come, but all is good – so far..

Robert Gadsdon  April 8, 2018

 

Kernel – 4.16 Released – OK with Latest VMware, and (patched) NVIDIA..

Posted on by April 1, 2018
Reply

Kernel version 4.16 is out, and brief details of changes since -rc7 are here:  http://lkml.iu.edu/hypermail/linux/kernel/1804.0/00174.html

$ uname -a
Linux rglx 4.16.0 #1 SMP Sun Apr 1 15:20:00 PDT 2018 x86_64 x86_64 x86_64 GNU/Linux

This release is OK with VMware 14.1.1, and with NVIDIA 384.130/390.48 with the swiotlb-removing patch.. ( see http://rglinuxtech.com/?p=2227 ).

Hopefully NVIDIA will get round to releasing a 4.16-compatible version, soon..

Robert Gadsdon.   April 1, 2018.

 

NVIDIA – New Driver 384.130 – Still Fails with 4.16..

Posted on by March 29, 2018
1

NVIDIA have released driver 384.130, and details are here:  http://www.nvidia.com/download/driverResults.aspx/132524/en-us

The ‘Release Highlights’ clearly specify ”Improved compatibility with recent Linux kernels.”, and yet it still fails with Kernel 4.16 (tested with 4.16-rc7):

..................
ld -r -o /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.130/kernel/nvidia-modeset/nv-modeset-interface.o /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.130/kernel/nvidia-modeset/nvidia-modeset-linux.o
 Building modules, stage 2.
 MODPOST 4 modules
WARNING: "swiotlb_map_sg_attrs" [/home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.130/kernel/nvidia.ko] undefined!
 CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.130/kernel/nvidia-drm.mod.o
 LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.130/kernel/nvidia-drm.ko
 CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.130/kernel/nvidia-modeset.mod.o
 LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.130/kernel/nvidia-modeset.ko
 CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.130/kernel/nvidia-uvm.mod.o
 LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.130/kernel/nvidia-uvm.ko
 CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.130/kernel/nvidia.mod.o
 LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.130/kernel/nvidia.ko
make[2]: Leaving directory '/usr/src/linux-4.16-rc7'
make[1]: Leaving directory '/usr/src/linux-4.16-rc7'

Speculation:
It is just possible that this update has been released in error, as Kernel 4.16 is due to be out very soon, and – typically – the phrase ”Improved compatibility with recent Linux kernels.” signifies compatibility with the next major release, and the previous version – 384.111 – was already compatible with Kernel 4.15…

Robert Gadsdon.  March 29, 2018.

NVIDIA – Another New Driver – Still Broken with 4.16..

Posted on by March 28, 2018
Reply

NVIDIA have released another new driver – 390.48, and details are here: http://www.nvidia.com/Download/driverResults.aspx/132530/en-us

Surprisingly, this version is still not able to function with Kernel 4.16 (tested with 4.16-rc7):

....................
Building modules, stage 2.
 MODPOST 4 modules
WARNING: "swiotlb_map_sg_attrs" [/home/rgadsdon/kernel/NVIDIA-Linux-x86_64-390.48/kernel/nvidia.ko] undefined!
..................

I am still using the patched version of 384.111 (see http://rglinuxtech.com/?p=2227 ), and I should mention that this also works OK with Kernel 4.15..

Barring unforeseen issues, Kernel 4.16 ‘Final’ should be released in 4 days time from now…

Robert Gadsdon.  March 28, 2018.

Linux – Dual-Boot – Fixing the EFI FAT32 UUID..

Posted on by March 26, 2018
Reply

Although I had successfully achieved a dual-boot uEFI Fedora27/Windows7 system, the expanded EFI partition issue was still unresolved..   I had successfully expanded the partition size, but the expansion of the FAT32 filesystem on it did not work, as gparted was unable to handle it.   After more research, I came to the conclusion that the only reliable solution was to back-up the entire EFI partition contents, and re-create the FAT32 filesystem in the already-expanded partition, and restore the contents..

This worked, but I had to remember that current Fedora systems default to UUIDs in fstab, and – of course – the FAT32 partition UUID had changed with the filesystem re-creation..     Personally, I still prefer the old /dev/sdX format in fstab, but others may prefer to just change the UUID to the ‘new’ one, except that in this dual-boot scenario, that would not work..

The real problem came on rebooting into Win7, when it threw an ”error: no such device <oldUUID>.” error..   but then – after a while – went ahead and booted OK..    I needed to fix this, and restore the ‘original’ UUID..

It seems that changing the ‘UUID’ on FAT32 systems is relatively convoluted, and some of the suggestions I found simply did not work..   I used a spare USB stick with a FAT32 partition for testing..

Eventually I found a rather complex solution here:  https://superuser.com/questions/1247972/change-uuid-of-vfat-partition , and thanks to Tommy for the info..     I tested this on the USB stick first, and then on the actual boot disk, and it worked..   If you are going to try this yourself, I would recommend – carefully – cutting/pasting the ‘complex’ command, taking care to substitute the correct drive/partition info..

Robert Gadsdon.   March 26, 2018.

Kernel – GCC 8 Tests – Not Quite Ready…

Posted on by March 22, 2018
Reply

I decided to try updating a crash-and-burn test system to Fedora 28 (early-beta..) as this included GCC 8 (currently 8.0.1), to see how well the Kernel (4.16-rc6) compiled..

There were a lot of warnings generated:

........................
 CC [M] drivers/rtc/rtc-pcf8523.o
 CC drivers/usb/core/file.o
 CC drivers/video/hdmi.o
 CC [M] drivers/rtc/rtc-pcf8563.o
drivers/video/hdmi.c: In function ‘hdmi_spd_infoframe_init’:
drivers/video/hdmi.c:171:2: warning: ‘strncpy’ specified bound 8 equals destination size [-Wstringop-truncation]
 strncpy(frame->vendor, vendor, sizeof(frame->vendor));
 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/video/hdmi.c:172:2: warning: ‘strncpy’ specified bound 16 equals destination size [-Wstringop-truncation]
 strncpy(frame->product, product, sizeof(frame->product));
 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/usb/core/file.o: warning: objtool: usb_register_dev()+0x1b3: sibling call from callable instruction with modified stack frame
drivers/usb/core/file.o: warning: objtool: usb_major_init()+0x24: sibling call from callable instruction with modified stack frame
 CC drivers/usb/core/buffer.o
 CC drivers/video/backlight/backlight.o
 CC [M] drivers/rtc/rtc-pcf8583.o
 CC drivers/usb/core/sysfs.o
.................................
 CC drivers/usb/host/ehci-pci.o
 CC drivers/video/fbdev/core/softcursor.o
drivers/video/fbdev/core/fbcon.o: warning: objtool: fbcon_prepare_logo()+0x218: sibling call from callable instruction with modified stack frame
drivers/video/fbdev/core/fbcon.o: warning: objtool: fbcon_init()+0x4ba: sibling call from callable instruction with modified stack frame
drivers/video/fbdev/core/fbcon.o: warning: objtool: fbcon_switch()+0x47f: sibling call from callable instruction with modified stack frame
drivers/video/fbdev/core/fbcon.o: warning: objtool: con2fb_release_oldinfo.isra.9()+0xd2: sibling call from callable instruction with modified stack frame
drivers/video/fbdev/core/fbcon.o: warning: objtool: set_con2fb_map()+0x151: sibling call from callable instruction with modified stack frame
drivers/video/fbdev/core/fbcon.o: warning: objtool: fbcon_event_notify()+0x195: sibling call from callable instruction with modified stack frame
drivers/video/fbdev/core/fbcon.o: warning: objtool: fbcon_prepare_logo.cold.21()+0x20: sibling call from callable instruction with modified stack frame
 CC [M] drivers/usb/image/mdc800.o
....................................

These were displayed throughout the compile, although the process completed successfully, and the resulting kernel booted OK:

................
Fedora 28 (Workstation Edition)
Kernel 4.16.0-rc6 on an x86_64 (ttyS0)
...................
[root@rgup ~]# uname -a
Linux rgup 4.16.0-rc6 #1 SMP Tue Mar 20 19:52:54 PDT 2018 x86_64 x86_64 x86_64 GNU/Linux

When I tried to run grub-customizer, it crashed:

....
*** initializing (w/o specified bootloader type)…
 * reading partition info…
/usr/include/c++/8/bits/basic_string.h:1048: std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::reference std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::operator[](std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>; std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::reference = char&; std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type = long unsigned int]: Assertion '__pos <= size()' failed.
Aborted (core dumped)

So, I had to use grub2-mkconfig instead..

I compiled the NVIDIA driver (384.111 patched for 4.16) and this also gave warnings, but the compile completed OK..

...............
 CC [M] /usb3/kernel/NVIDIA-Linux-x86_64-384.111-custom/kernel/nvidia-uvm/uvm8_pmm_test.o
 /usb3/kernel/NVIDIA-Linux-x86_64-384.111-custom/kernel/nvidia-uvm/uvm8_pmm_test.o: warning: objtool: chunk_alloc_check_common.isra.5()+0x3b: sibling call from callable instruction with modified stack frame
 /usb3/kernel/NVIDIA-Linux-x86_64-384.111-custom/kernel/nvidia-uvm/uvm8_pmm_test.o: warning: objtool: split_test_single()+0x66: sibling call from callable instruction with modified stack frame
 /usb3/kernel/NVIDIA-Linux-x86_64-384.111-custom/kernel/nvidia-uvm/uvm8_pmm_test.o: warning: objtool: basic_test_alloc()+0x2a: sibling call from callable instruction with modified stack frame
 /usb3/kernel/NVIDIA-Linux-x86_64-384.111-custom/kernel/nvidia-uvm/uvm8_pmm_test.o: warning: objtool: uvm8_test_pmm_sanity()+0x9cc: sibling call from callable instruction with modified stack frame
 CC [M] /usb3/kernel/NVIDIA-Linux-x86_64-384.111-custom/kernel/nvidia-uvm/uvm8_perf_events_test.o
 /usb3/kernel/NVIDIA-Linux-x86_64-384.111-custom/kernel/nvidia-uvm/uvm8_perf_events_test.o: warning: objtool: test_events()+0x4c: sibling call from callable instruction with modified stack frame
 ........................

This was all only for testing purposes, and – obviously – none of this is recommended for real use, yet!

There are several gcc8-related patches for the kernel, proposed, and these should eventually be included in later -rc versions, and 4.17..

Robert Gadsdon.   March 21, 2018

Linux – Dual-Boot Nasty Hack..

Posted on by March 14, 2018
Reply

I am setting up an HP Z820 as – primarily – a video creating/editing/restoring system, but I need to be able to boot into Windows 7 Pro (for Vegas Pro, AviSynth, Prodrenalin, Mercalli, etc. etc..) and Linux (Fedora)..   I had set up dual-boot systems before, and I am still using Windows 7 Pro SP1, but this time I am using uEFI..

The problem..
Set up dual boot as usual (install Win7, then ‘shrink’ disk partition, then install Fedora 27).    First boot into Fedora brings up Grub2 menu correctly, with chainloader entry to boot Windows 7, but after subsequent reboot into Windows 7, only Windows 7 shows up, instead of Grub2.    I had read up on many suggested ‘fixes’ but most of these were not very helpful..    I updated the Z820 bios to the very latest version, but this made no difference.  The problem appears to be caused by Win7..

Fortunately, as I was using uEFI, I could use this from the Z820 setup UEFI menu option to select Grub2/Fedora manually (EFI- fedora – shimx64-fedora.efi), and still boot into Grub2/Fedora..

I did try one suggested fix, using efibootmgr to add back the ‘Fedora entry’, but after rebooting into Windows 7, this vanished again..

# efibootmgr
 Timeout: 2 seconds
 BootOrder: 0000,0004,0005,0008,0006,0009,0000
 Boot0000* Windows Boot Manager
 Boot0001 IP6 Intel(R) 82579LM Gigabit Network Connection
 Boot0004* DTO UEFI USB Hard Drive
 Boot0005* DTO UEFI USB Floppy/CD
 Boot0006* Hard Drive
 Boot0008* DTO UEFI ATAPI CD-ROM Drive
 Boot0009* CD/DVD Drive

Add Fedora entry back to efi boot menu:
efibootmgr -c -w -d /dev/sda -p 1 -l '\EFI\fedora\shimx64-fedora.efi' -L "Fedora"

# efibootmgr
 Timeout: 2 seconds
 BootOrder: 0002,0000,0004,0005,0008,0006,0009,0000
 Boot0000* Windows Boot Manager
 Boot0001 IP6 Intel(R) 82579LM Gigabit Network Connection
 Boot0002* Fedora
 Boot0004* DTO UEFI USB Hard Drive
 Boot0005* DTO UEFI USB Floppy/CD
 Boot0006* Hard Drive
 Boot0008* DTO UEFI ATAPI CD-ROM Drive
 Boot0009* CD/DVD Drive

Reboot into Windows 7, then Fedora (via uEFI menu!) and the Fedora entry has vanished:

# efibootmgr
 Timeout: 2 seconds
 BootOrder: 0000,0004,0005,0008,0006,0009,0000
 Boot0000* Windows Boot Manager
 Boot0001 IP6 Intel(R) 82579LM Gigabit Network Connection
 Boot0004* DTO UEFI USB Hard Drive
 Boot0005* DTO UEFI USB Floppy/CD
 Boot0006* Hard Drive
 Boot0008* DTO UEFI ATAPI CD-ROM Drive
 Boot0009* CD/DVD Drive

After more trial-and-error, I came up with the following solution, and it is nasty, but it does work!

Boot into Fedora.
As root, go to /boot/efi/EFI/Microsoft/Boot
Rename bootmgfw.efi to bootmgfwin7.efi
Copy shimx64-fedora.efi and grub64.efi from /boot/efi/EFI/fedora, and rename shimx64-fedora.efi to bootmgfw.efi
Run grub-customizer to edit Grub2 entry for ‘Windows Boot Manager‘:
change
chainloader /EFI/Microsoft/Boot/bootmgfw.efi
to
chainloader /EFI/Microsoft/Boot/bootmgfwin7.efi

So..  Windows 7 thinks it is rebooting into Windows 7, but is in fact rebooting into Grub2..

Robert Gadsdon.   March 14, 2018.