Dell XPS 9360 with Ubuntu 17.04 (Zesty Zapus)
In the following I summarised how happy I was with the operation of the Dell XPS 9360 with Windows / Ubuntu dual boot
In Summary: Very Happy
But, I was caught by a BIOS upgrade — the 1.3.2 update downloaded by the Dell updater is the prime suspect.
These do seem to have a tendency to hose the dual boot setup.
This time around the issue was not BIOS defaults, instead the Ubuntu partition could be discovered, but apparently not booted.
Arguably I should wean myself off the dual boot idea, but I’m not quite ready.
In retrospect, I wonder if this could have been a issue due to the signing of the bootloader, as I have temporarily turned off Secure Boot in the bios to allow the installer to work. The error messages did not seem crystal clear to me at the time.
But, given I never store files I care about on only one device, I thought I may as well take the opportunity to update to a clean Zesty Zapus install. Fetching some files back if I want them is a minor task.
I booted from a live USB stick populated from a desktop installer ISO download, and chose nothing controversial for the installation. No problems: very quick.
Ironically, this seems quicker and yields more certain results than debugging a non-bootable partition.
So how does it look ?
It looks pretty good, and initially seemed to behave OK.
Now, the interesting thing about the passage of time is that it happens simultaneously everywhere
At the time of first getting the machine and setting up the Ubuntu partition (16.04), it has to be recalled there were some niggles.
In linux land
- Audio device disappearing when switching from one OS to the other — NOW FIXED
- trackpad oddities — NOW FIXED
- some dmesg output about firmware not downloadable —STILL THERE
- some dmesg output which seems related to built in Intel audio —NOW FIXED
in Windows land
updates have appeared and:
- Devices and Printers — appears quickly; works; does not leave the CPU burning power after it’s been open
- the DSP channel in the audio driver has been landed and seems to work?
So on balance, after a while using the machine and switching between the 2 OS boots has been pretty seamless.
kernel update leads to spamming in dmesg
This seems to be the result of recent kernel updates.
[ 883.763051] pcieport 0000:00:1c.4: AER: Corrected error received: id=00e4
[ 883.763068] pcieport 0000:00:1c.4: PCIe Bus Error: severity=Corrected, type=Data Link Layer, id=00e4(Transmitter ID)
[ 883.763081] pcieport 0000:00:1c.4: device [8086:9d14] error status/mask=00001000/00002000
[ 883.763090] pcieport 0000:00:1c.4:  Replay Timer Timeout
Kernel 4.4 Error "AER: Corrected error received: id=00e0" - openmediavault
Source Code (2 lines) Hi guys, since I installed kernel 4.4 from the backports dmesg and system log show such errors…
This is “fixed” by adding pci=noaer (No Advanced Error Reporting) to the kernel parameters.
I’m not super happy about simply suppressing output I don’t want to see, but on the basis that the Windows partition has always run clean and
journalctl -f shows a nice clean output I’m assuming this is a question of verbosity that has been exposed.
The bad: issues only on Zesty Zapus
Start-up under 16.04 takes a few seconds — under 17.04 initial start-up *seems* slow — hard to tell if this is me being dense or if it a real thing as the mouse appears to need to be moved over the login box to make it appear. Although frankly IMHO this is odd UX this would be fine* apart for:
Missing mouse cursor at sign-in screen!
BOOM. I don’t know whether this is a very long delay in the mouse device coming up, a display glitch or something else.
Wifi transfers seem _super slow_ (over 10 times reduced throughput) an the connection seems generally flakier. Again the Windows and 16.04 boots provide a significant baseline of solid performance so I am assuming this is a regression.
There is a noticeable, quite lengthy video glitch upon every logon.
So by now you might have guessed that I reverted to installing 16.04.2, the latest LTS release build, which is how I discovered what things are fixed in that build.
This build is in very good shape, right out of the box, and we can see why.
$ dpkg -l | grep libinput
ii libinput10:amd64 1.2.3–1ubuntu1 amd64 input device management and event handling library — shared library
So libinput is now installed by default.
$ dmesg | grep snd_hda
[ 3.298638] snd_hda_intel 0000:00:1f.3: enabling device (0000 -> 0002)
[ 3.458644] snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
[ 3.519407] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC3246: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker
[ 3.519408] snd_hda_codec_realtek hdaudioC0D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
[ 3.519410] snd_hda_codec_realtek hdaudioC0D0: hp_outs=1 (0x21/0x0/0x0/0x0/0x0)
[ 3.519410] snd_hda_codec_realtek hdaudioC0D0: mono: mono_out=0x0
[ 3.519411] snd_hda_codec_realtek hdaudioC0D0: inputs:
[ 3.519412] snd_hda_codec_realtek hdaudioC0D0: Headset Mic=0x19
[ 3.519413] snd_hda_codec_realtek hdaudioC0D0: Headphone Mic=0x1a
[ 3.519414] snd_hda_codec_realtek hdaudioC0D0: Internal Mic=0x12
It’s interesting to see how the activity of hardware support is ever making incremental improvements at quite a tempo. Yes, sometimes there’s an element of 3 steps forward, 1 step back but that’s the nature of things.