Ubuntu Vivid Debian: Kernel I/O Errors SSD SATA NVIDIA Chipsets

If you use a PC with a SSD Drive and a Motherboard which uses NVIDIA chipsets you may see Errors on boot

Command „dmesg“ Output like..

Buffer I/O error on device sdc, logical block 41
ata5: EH complete
ata5: EH in SWNCQ mode,QC:qc_active 0x1 sactive 0x1
ata5: SWNCQ:qc_active 0x1 defer_bits 0x0 last_issue_tag 0x0
  dhfis 0x1 dmafis 0x1 sdbfis 0x0
ata5: ATA_REG 0x41 ERR_REG 0x84
ata5: tag : dhfis dmafis sdbfis sactive
ata5: tag 0x0: 1 1 0 1 
ata5.00: exception Emask 0x1 SAct 0x1 SErr 0x300000 action 0x6 frozen
ata5.00: Ata error. fis:0x21
ata5.00: cmd 60/08:00:07:04:00/00:00:00:00:00/40 tag 0 ncq 4096 in
         res 41/84:00:07:04:00/84:00:00:00:00/40 Emask 0x10 (ATA bus error)
ata5: hard resetting link
ata5: nv: skipping hardreset on occupied port
ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata5.00: configured for UDMA/133
sd 4:0:0:0: [sdc] 
Result: hostbyte=0x00 driverbyte=0x08
sd 4:0:0:0: [sdc] 
Sense Key : 0xb [current] [descriptor]
Descriptor sense data with sense descriptors (in hex):
        72 0b 47 00 00 00 00 0c 00 0a 80 00 00 00 00 00
        00 00 04 07
sd 4:0:0:0: [sdc] 
ASC=0x47 ASCQ=0x0...

This is a bug by the NVIDIA Manufacterer NOT by LINUX!

The Problem is that the hardware command „swncq“ (DMA-64bit) is set to on by the „default“ Kernels now, but older nvidia chips don’t support it! Only DMA-32bit

sata cable 600 with clip
sata cable 600 with clip

Info found here swnq libsata nvidia kernel (external Link)

Workaround on Gnome Terminal or Console:

  • $sudo echo ‚options sata_nv swncq=0‘ >> /etc/modprobe.d/sata_nv.conf
  • $sudo update-initramfs -u -k all
  • reboot and test with „dmesg“ command on Terminal! there should be NO Error now!
  • If the Problem still exists, then change SATA Cables to SATA-300/600 (II/III) „with Metal Clip on Connectors“ take „shortest length“
  • May be possible that this bug touches other OS like Windows too

 

Ubuntu Vivid: Systemd boot OS into rescue mode with tmpfs

If you setup a Laptop with 15.XX and a luks encrypted SSD, you did set on older OS „tmpfs“ for /tmp. Now under „systemd“ the the boot hangs cause systemd „automount“ tmpfs to /tmp by default!!! If you enter tmpfs into fstab like on ubuntu 14.10, the OS boots into the „RECOVERY RESCUE MODE“

Here some details, from a forum post:

Disable automatic mount

Under systemd, /tmp may be automatically mounted as a tmpfs even though you have no entry for that in your /etc/fstab.
To disable the automatic mount, run:
# systemctl mask tmp.mount
Files will no longer be stored in a tmpfs, but your block device instead. The /tmp contents will now be preserved between reboots, which you might not want. To regain the previous behavior and clean the /tmp folder automatically when restarting your machine, consider using tmpfiles.d:
/etc/tmpfiles.d/tmp.conf

# see tmpfiles.d
# always enable /tmp folder cleaning
D! /tmp 1777 root root 0

# remove files in /var/tmp older than 10 days
D /var/tmp 1777 root root 10d

# namespace mountpoints (PrivateTmp=yes) are excluded from removal
x /tmp/systemd-private-*
x /var/tmp/systemd-private-*
X /tmp/systemd-private-*/tmp
X /var/tmp/systemd-private-*/tmp