Ubuntu 14.04.4 LTS Released

Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.

PigLover

Moderator
Jan 26, 2011
3,184
1,545
113
I wonder what Canonical thought was important enough to fix, or what hardware support was so urgent, that they'd do a point release like this so close to the release of 16.04 in late April?

Any chance Xeon-D wave-2 drove it?
 
  • Like
Reactions: Patriot

whitey

Moderator
Jun 30, 2014
2,766
868
113
41
Garbage for ZoL in an AIO config for me anyways, anyone else want to prove me wrong I bet you hit the same wall as me...something seriously sick w/ mpt2sas in latest Linux kernels it seems related to some PCI reallocation/enumeration that is all b|tched up. You can clearly see nasty errors in dmesg that do not allow HBA to initialize properly.

If someone would replicate I would be eternally grateful so I can stop questioning my sanity/conspiracy...which I will not go into now but maybe soon...it's a juicy one!

ENV:
vSphere/ESXi 6.x
LSI 2008 HBA v20 IT FW
Ubuntu LTS 14.04.4
add-apt-repository ppa:zfs-native/stable
 
Last edited:

PigLover

Moderator
Jan 26, 2011
3,184
1,545
113
It's not Ubuntu or the Linux kernel. It's the V20 firmware. Refresh to V19 or get hold of the recently re-released V20 image and you'll find happiness.
 
  • Like
Reactions: MiniKnight

whitey

Moderator
Jun 30, 2014
2,766
868
113
41
Hey @PigLover, I SWEAR I was NOT one of those early adopters of v20, quite the opposite in fact, I JUST updated to v20 a month or two ago after the initial v20 woes were sorted out. I'm using this release of v20. I was diehard v19 before that for sure.

DL'ed on 12/23/15

9211-8i_Package_P20_IR_IT_Firmware_BIOS_for_MSDOS_Windows

EDIT: BTW I was beating on rockstor and 4.3 kernels w/ v19 forever before I tried to update to v20...no love there either, thoroughly tested v20 on my OmniOs boxes and finally got FreeNAS to stop bitching as well w/ it but I lived/breathed/slept and preached v19 before. Even on these forums.

Hell I will re-flash back to v19 right now (take me less than 15 mins) if you think it will help here, you buy virtual beers if it does not :p

Ubuntu LTS 14.04.3 works like a champ btw, looks to have mpt2sas v18.0 LSI driver rolled in, very happy w/ v20 IT mode FW, can see ALL disk on instlal, post install reboot can still see all disks via lsblk, lay down ubuntu-zfs, create pools/filesystems/etc.

I'll reload 14.04.4 now, take snaps and show evidence so you all don't think I am losing my damn mind :-D
 
Last edited:

whitey

Moderator
Jun 30, 2014
2,766
868
113
41
And here is the evidence, same AIO config, same host, same HBA (of course I shutdown the 14.04.3 AIO that was assigned the HBA and moved it to 14.04.4 AIO). Can't even see disks hanging off HBA cause of this nonsense. I'll still take that bet that even w/ v19 it is 'the broke' in Centos7 1511 (4.3 kernel mpt2sas jacked up/unstable) and Ubuntu 14.04.4 (4.2 kernel mpt2sas jacked up/unstable) :-D
 

Attachments

rubylaser

Active Member
Jan 4, 2013
846
236
43
Michigan, USA
I'm running 14.04.4 with an even newer 4.4 kernel. I see a lot of messages in dmesg pertaining to mpt2sas, but nothing about failures. I wonder why the build line is referencing Wily and not Trusty?
 

whitey

Moderator
Jun 30, 2014
2,766
868
113
41
Anyone will to reproduce w/ same config as mine? I'll try a newer kernel I suppose
 

whitey

Moderator
Jun 30, 2014
2,766
868
113
41
4.3.x/4.4.x kernel don't fix it for me so far. I'm just abt done w/ this, was a failed science experiment especially if I can't get anyone else w/ as near identical config to validate/sanity check me.

4.4.x did move to a mpt3sas driver but still b|tched-up.

zol-ubuntu-14.04.4-mpt2sas-NOT-happy-v19-LSI-IT-FW-kernel-4.3.6.png
zol-ubuntu-14.04.4-mpt2sas-NOT-happy-v19-LSI-IT-FW-kernel-4.4.2.png
 
Last edited:

rubylaser

Active Member
Jan 4, 2013
846
236
43
Michigan, USA
I have Ubuntu 14.04.4 64-bit with 4.4.0 kernel, with (1) IBM m1015's flashed to v19 firmware (with optionROM removed) connected to an Intel Intel RES2SV240. This is on a Supermicro X9SRL-F with e5-2670 v1 with 32GB of ECC RAM in a Norco 4224 case (with the new backplanes). So other than not passing them through to a VM and my use of a SAS Expander, what else is different about our setups that you would like me to try?

Here's the results right after a clean reboot.

Code:
root@fileserver:~# dmesg | grep mpt2sas
[    2.503054] mpt2sas_cm0: 64 BIT PCI BUS DMA ADDRESSING SUPPORTED, total mem (16082264 kB)
[    2.559880] mpt2sas_cm0: MSI-X vectors supported: 1, no of cores: 4, max_msix_vectors: -1
[    2.559957] mpt2sas0-msix0: PCI-MSI-X enabled: IRQ 30
[    2.559958] mpt2sas_cm0: iomem(0x00000000f0ac0000), mapped(0xffffc90001b78000), size(16384)
[    2.559958] mpt2sas_cm0: ioport(0x000000000000e000), size(256)
[    2.649932] mpt2sas_cm0: Allocated physical memory: size(7445 kB)
[    2.649932] mpt2sas_cm0: Current Controller Queue Depth(3307),Max Controller Queue Depth(3432)
[    2.649933] mpt2sas_cm0: Scatter Gather Elements per IO(128)
[    2.694575] mpt2sas_cm0: LSISAS2008: FWVersion(19.00.00.00), ChipRevision(0x03), BiosVersion(07.31.00.00)
[    2.694576] mpt2sas_cm0: Protocol=(
[    2.694810] mpt2sas_cm0: sending port enable !!
[    4.245861] mpt2sas_cm0: host_add: handle(0x0001), sas_addr(0x500605b002b07f80), phys(8)
[    4.269894] mpt2sas_cm0: expander_add: handle(0x0009), parent(0x0001), sas_addr(0x5001e677b8d0efff), phys(26)
[   13.373435] mpt2sas_cm0: port enable: SUCCESS
[   17.893209] mpt2sas_cm0:     sas_address(0x4433221105000000), phy(5)
[   17.921290] mpt2sas_cm0:     enclosure_logical_id(0x500605b002b07f80),slot(6)
[   17.949144] mpt2sas_cm0:     handle(0x000a), ioc_status(success)(0x0000), smid(1)
[   17.976934] mpt2sas_cm0:     request_len(0), underflow(0), resid(0)
[   18.004460] mpt2sas_cm0:     tag(65535), transfer_count(0), sc->result(0x00000000)
[   18.031846] mpt2sas_cm0:     scsi_status(check condition)(0x02), scsi_state(autosense valid )(0x01)
[   18.059245] mpt2sas_cm0:     [sense_key,asc,ascq]: [0x06,0x29,0x00], count(18)
[   18.140753] mpt2sas_cm0:     sas_address(0x4433221106000000), phy(6)
[   18.167340] mpt2sas_cm0:     enclosure_logical_id(0x500605b002b07f80),slot(5)
[   18.193838] mpt2sas_cm0:     handle(0x000b), ioc_status(success)(0x0000), smid(2)
[   18.220219] mpt2sas_cm0:     request_len(0), underflow(0), resid(0)
[   18.246188] mpt2sas_cm0:     tag(65535), transfer_count(0), sc->result(0x00000000)
[   18.272043] mpt2sas_cm0:     scsi_status(check condition)(0x02), scsi_state(autosense valid )(0x01)
[   18.298048] mpt2sas_cm0:     [sense_key,asc,ascq]: [0x06,0x29,0x00], count(18)
[   18.450478] mpt2sas_cm0:     sas_address(0x5001e677b8d0efe4), phy(4)
[   18.475128] mpt2sas_cm0:     enclosure_logical_id(0x5001e677b8d0efff),slot(4)
[   18.499681] mpt2sas_cm0:     handle(0x000c), ioc_status(success)(0x0000), smid(3)
[   18.524158] mpt2sas_cm0:     request_len(0), underflow(0), resid(0)
[   18.548216] mpt2sas_cm0:     tag(65535), transfer_count(0), sc->result(0x00000000)
[   18.572151] mpt2sas_cm0:     scsi_status(check condition)(0x02), scsi_state(autosense valid )(0x01)
[   18.596227] mpt2sas_cm0:     [sense_key,asc,ascq]: [0x06,0x29,0x00], count(18)
[   18.620380] mpt2sas_cm0:     sas_address(0x5001e677b8d0efe5), phy(5)
[   18.620381] mpt2sas_cm0:     enclosure_logical_id(0x5001e677b8d0efff),slot(5)
[   18.620381] mpt2sas_cm0:     handle(0x000d), ioc_status(success)(0x0000), smid(3)
[   18.620382] mpt2sas_cm0:     request_len(0), underflow(0), resid(0)
[   18.620382] mpt2sas_cm0:     tag(65535), transfer_count(0), sc->result(0x00000000)
[   18.620382] mpt2sas_cm0:     scsi_status(check condition)(0x02), scsi_state(autosense valid )(0x01)
[   18.620383] mpt2sas_cm0:     [sense_key,asc,ascq]: [0x06,0x29,0x00], count(18)
[   18.620535] mpt2sas_cm0:     sas_address(0x5001e677b8d0efe6), phy(6)
[   18.620535] mpt2sas_cm0:     enclosure_logical_id(0x5001e677b8d0efff),slot(6)
[   18.620535] mpt2sas_cm0:     handle(0x000e), ioc_status(success)(0x0000), smid(4)
[   18.620536] mpt2sas_cm0:     request_len(0), underflow(0), resid(0)
[   18.620536] mpt2sas_cm0:     tag(65535), transfer_count(0), sc->result(0x00000000)
[   18.620536] mpt2sas_cm0:     scsi_status(check condition)(0x02), scsi_state(autosense valid )(0x01)
[   18.620537] mpt2sas_cm0:     [sense_key,asc,ascq]: [0x06,0x29,0x00], count(18)
[   18.620695] mpt2sas_cm0:     sas_address(0x5001e677b8d0efe7), phy(7)
[   18.620695] mpt2sas_cm0:     enclosure_logical_id(0x5001e677b8d0efff),slot(7)
[   18.620695] mpt2sas_cm0:     handle(0x000f), ioc_status(success)(0x0000), smid(5)
[   18.620695] mpt2sas_cm0:     request_len(0), underflow(0), resid(0)
[   18.620696] mpt2sas_cm0:     tag(65535), transfer_count(0), sc->result(0x00000000)
[   18.620696] mpt2sas_cm0:     scsi_status(check condition)(0x02), scsi_state(autosense valid )(0x01)
[   18.620697] mpt2sas_cm0:     [sense_key,asc,ascq]: [0x06,0x29,0x00], count(18)
...truncated more of the same for each disk
Code:
root@fileserver:~# root@fileserver:~# dmesg | grep mpt3sas
[    2.501909] mpt3sas version 09.102.00.00 loaded
 
Last edited:

whitey

Moderator
Jun 30, 2014
2,766
868
113
41
yeah if it isn't vt-D through ESXi to the ubuntu VM in and AIO config v.s. phys gonna be tough to test. I know a lot of folks here run VMware labs and a lot are coming up to speed on AIO configs so I was hoping I'd luck out and someone w/ damn near identical config could validate. Trying to wrap my head arnd where the limitation is.

FWIW, I never have these issues under OmniOS/FreeNAS/Solaris to date. Seems to be bleeding edge linux distro's or newer packaged kernels that suffer from this. I had the rockstor guys thoroughly perplexed as well a couple months back. Kept having me try different kernels...none worked.

Here is the thread, I need to update it and let them know that after a reboot it turded the bed again so the last post is not entirely accurate, still issues there as well but that's CentOS 7 1511.

VTd passthru of LSI2008 HBA not detecting disks in 3.8-10 Rockstor release
 

rubylaser

Active Member
Jan 4, 2013
846
236
43
Michigan, USA
yeah if it isn't vt-D through ESXi to the ubuntu VM in and AIO config v.s. phys gonna be tough to test. I know a lot of folks here run VMware labs and a lot are coming up to speed on AIO configs so I was hoping I'd luck out and someone w/ damn near identical config could validate. Trying to wrap my head arnd where the limitation is.
Sorry, I used to have this virtualized AIO in ESXi, then I moved to Proxmox. In the last few months, I've moved back to a physical host for my bulk media and Docker containers.
 

whitey

Moderator
Jun 30, 2014
2,766
868
113
41
Thanks for the input, will stick w/ ubuntu 14.04.3 ZoL config that does work for now. I've had enough of this bashing my head into keyboard :-D
 

canta

Well-Known Member
Nov 26, 2014
1,012
216
63
43
4.3.x/4.4.x kernel don't fix it for me so far. I'm just abt done w/ this, was a failed science experiment especially if I can't get anyone else w/ as near identical config to validate/sanity check me.

4.4.x did move to a mpt3sas driver but still b|tched-up.

View attachment 1672
View attachment 1674
I know 3.4 and later has some issue and the bug is still open : Bug 92351 – mpt2sas fails to load for a LSISAS2008 card

the work around is adding pci=realloc=off to kernel command line to disable PCI memory allocation.

good luck
 

whitey

Moderator
Jun 30, 2014
2,766
868
113
41
I've tried that 'pci=realloc=off' kernel line trick to no avail but I suppose I can try again.
 

whitey

Moderator
Jun 30, 2014
2,766
868
113
41
And the fix for me was:

mpt2sas.msix_disable=1 (for 4.3 or older kernels)
or
mpt3sas.msix_disable=1 (for 4.4 or newer kernels)

Added to kernel boot line parameters, adding here as well for prosperity's sake.
 
  • Like
Reactions: T_Minus and Patrick

whitey

Moderator
Jun 30, 2014
2,766
868
113
41
Update/more info

mpt2sas.msix_disable=1 (for 4.3 or older kernels)
or
mpt3sas.msix_disable=1 (for 4.4 or newer kernels)

Added to kernel boot line parameters, adding here as well for prosperity's sake.

Under ubuntu or CentOS using grub2 to make it stick edit the /etc/default/grub to the following:

GRUB_CMDLINE_LINUX_DEFAULT="mpt2sas.msix_disable=1"
(mpt3sas.msix_disable=1 for 4.4 or newer kernels)

Save file:

Then update grub2 files:

Ubuntu - update-grub
CentOS - grub2-mkconfig -o /boot/grub2/grub.cfg (BIOS based machines)
grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg (UEFI based machines)
 
Last edited: