ONBOARD SSD has died, never been used, now boot up takes 5 minutes. Attempted to block it with libata.force. Does nothing ata: [ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-3.13-1-amd64 root=/dev/mapper/g0-root ro quiet libata.force=2:disable acpi_backlight=vendor [ 0.000000] BIOS-e820: [mem 0x00000000a6fbf000-0x00000000a6ffefff] ACPI data [ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-3.13-1-amd64 root=/dev/mapper/g0-root ro quiet libata.force=2:disable acpi_backlight=vendor [ 0.000000] Memory: 3891500K/4042096K available (4809K kernel code, 693K rwdata, 1620K rodata, 988K init, 952K bss, 150596K reserved) [ 0.062077] perf_event_intel: PEBS disabled due to CPU errata, please upgrade microcode [ 0.201335] _OSC request data:1 1f 0 [ 0.216819] ACPI : EC: GPE = 0x17, I/O: command/status = 0x66, data = 0x62 [ 0.660782] Write protecting the kernel read-only data: 8192k [ 0.783414] libata version 3.00 loaded. [ 0.827909] ata1: SATA max UDMA/133 abar m2048@0xc0507000 port 0xc0507100 irq 42 [ 0.827912] ata2: SATA max UDMA/133 abar m2048@0xc0507000 port 0xc0507180 irq 42 [ 0.827914] ata3: DUMMY [ 0.827916] ata4: SATA max UDMA/133 abar m2048@0xc0507000 port 0xc0507280 irq 42 [ 0.827918] ata5: SATA max UDMA/133 abar m2048@0xc0507000 port 0xc0507300 irq 42 [ 0.827920] ata6: DUMMY [ 1.147146] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 1.148444] ata1.00: ATA-8: Hitachi HTS545050A7E380, GG2OA610, max UDMA/133 [ 1.148454] ata1.00: 976773168 sectors, multi 16: LBA48 NCQ (depth 31/32), AA [ 1.149749] ata1.00: configured for UDMA/133 [ 6.509616] ata2: link is slow to respond, please be patient (ready=0) [ 11.159774] ata2: COMRESET failed (errno=-16) [ 16.522235] ata2: link is slow to respond, please be patient (ready=0) [ 21.172402] ata2: COMRESET failed (errno=-16) [ 26.534865] ata2: link is slow to respond, please be patient (ready=0) [ 56.228611] ata2: COMRESET failed (errno=-16) [ 56.228685] ata2: limiting SATA link speed to 1.5 Gbps [ 61.254949] ata2: COMRESET failed (errno=-16) [ 61.255024] ata2: reset failed, giving up [ 61.575095] ata4: SATA link down (SStatus 0 SControl 300) [ 61.895247] ata5: SATA link down (SStatus 0 SControl 300) [ 85.642445] EXT4-fs (dm-1): mounted filesystem with ordered data mode. Opts: (null) [ 127.322928] EXT4-fs (dm-2): mounted filesystem with ordered data mode. Opts: (null) [ 127.459851] EXT4-fs (dm-4): mounted filesystem with ordered data mode. Opts: (null)
libata is not getting the parameter at all. Your initrd probably doesn't automatically parse the kernel command line to extract module params. Please consult with your distro on how to specify module params for modules loaded from initrd. If you can build your kernel with libata built-in, this'd be easy to verify. I'm closing the bug as INVALID for now. Thanks.
I have confirmed that the 'correct' method is to create a file in /etc/modprobe.d/ with options libata force=2:disable Followed by updating the initramfs. As seen with: ata2.00: FORCE: horkage modified (disable) (on my virtual machine) HOWEVER...as the original bug reports - disable fails, it does indeed fail to do as intended. (the intention of the author of this patch was for onboard SSD that had failed and soldiered onto the board). My syslog / dmesg reports: ata2: PATA max UDMA/33 cmd 0x1f0 ctl 0x3f6 bmdma 0xd000 irq 14 BEFORE the FORCE disables it. The problem with the users machine above, occurs at the ata2: part. BEFORE the disable kicks in. Which it never does, since ata2: reset failed, giving up; kicks in before a device is recognised to be disabled. So basically if libata.force only disables after the probe, i need to know how to disable the probe.... Happy for further information to be provided and this bug closed as invalid again, as long as i can get the users machine working as this libata.force is supposed to do... Thanks . .
also filed with debian - find more information there if neccessary, or advise on there if debian can do anything different with their kernel, thanks. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746361
Set Bug forwarded-to-address to 'https://bugzilla.kernel.org/show_bug.cgi?id=73691'. Request was from Ben Hutchings <ben@decadent.org.uk> to control@bugs.debian.org. (Sat, 03 May 2014 19:57:17 GMT) Full text and rfc822 format available. Please note the user tested with arch linux and the same issue, i will happily test with a few different distro's. but any information like, libata.force doesn't disable the probe because, we need a new patch, this is not what libata.force is for. etc would be good. thanks Anthony F. McInerney
(In reply to Tejun Heo from comment #1) > libata is not getting the parameter at all. Your initrd probably doesn't > automatically parse the kernel command line to extract module params. Please > consult with your distro on how to specify module params for modules loaded > from initrd. > > If you can build your kernel with libata built-in, this'd be easy to verify. > I'm closing the bug as INVALID for now. > > Thanks. libata.force=2:disable didn't affect slow boot times in my case, but libata.force=rstonce shortened delay from +60 seconds to +8 seconds. I think it proves that initrd parses kernel command line to extract module params, and at least libata.force=rstonce affects system.
same problem here, libata.force=2:disable is completely ignored, but libata.force=2:rstonce works fine, and produces the following confirmation in dmesg: [ 0.857339] ata2: FORCE: link flag 0x200 forced -> 0x200 when set to disable there is no message, and no effect Tested on 3.16.1
Okay, just tested libata.force=N:disable and it works as intended. It doesn't inhibit probing. It just disables the device after it's recognized. Using norst can probably avoid delay due to broken devices. Thanks.