[SOLVED] Kernel Sata PMP Support for AMD Chipset? Any News?

Franky · 2016-06-10 07:43:22

Hi Guys!

Recently I bought myself my first SSD so I installed Arch on it right away, at first I thought I would get boot times about like 6 or 7 seconds, maybe I'm wrong about these times.

But anyway, my boot times are about 14 seconds, and it was because of this issue that I put attention to an error message that always appeared in my boot screen "ata2 sofreset failed (device not ready)"
So after read about the issue, on so many sites, I discover that this was making my system hangs on boot all the time since I was on HDD, and because of the bug, (that it's not even a bug in the kernel apperantly, it's some sort of incompatibility of AMD chipset) that on every boot the kernel needs to apply some workaround, my system hangs for about 70% of the time of my entire boot.

TL:DR... I read a lot and found (from this post of 7 years ago) that the only solution was to recompile the kernel with the PMP Support disabled.

So I've searched a lot on the net without success on getting a solution more simpler than recompile the kernel on every update, So I am asking anyone with this problem, Have you found anything simpler?
My motherboard is some years old, but my system still works great, my SSD gave it a real boost I gotta say, It's only the boot time that I would love to make it better.

Any advice, suggestion will be really appreciated.

systemd-analyze

Startup finished in 13.644s (kernel) + 626ms (userspace) = 14.271s

dmesg | grep ata5

[    1.426925] ata5: SATA max UDMA/133 abar m1024@0xfe02f000 port 0xfe02f100 irq 22
[    1.890071] ata5: softreset failed (device not ready)
[    1.890160] ata5: applying PMP SRST workaround and retrying
[    2.043406] ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[    2.050746] ata5.00: ATA-8: KINGSTON SV300S37A120G, 603ABBF0, max UDMA/133
[    2.050748] ata5.00: 234441648 sectors, multi 1: LBA48 NCQ (depth 31/32), AA
[    2.056416] ata5.00: configured for UDMA/133

Motherboard: Gigabye MA790X-UD4P
6GB DDR2
Phenom II Quad-Core 2.6Ghz
SSD Kingston SSDNow 300V 120GB

Last edited by Franky (2016-06-12 22:40:12)

R00KIE · 2016-06-10 13:43:34

Take a good look at the timestamps, it takes less than one second for the drive to be detected

The systemd-analyze command is probably not reporting everything accurately (as expected on a bios system), of those thirteen seconds a good part is most probably spent on bios initialization and boot manager. To me it also seems 626ms is too little for all the userspace stuff, unless you have almost nothing starting on system boot.

Franky · 2016-06-10 17:03:16

R00KIE wrote:

Take a good look at the timestamps, it takes less than one second for the drive to be detected
The systemd-analyze command is probably not reporting everything accurately (as expected on a bios system), of those thirteen seconds a good part is most probably spent on bios initialization and boot manager. To me it also seems 626ms is too little for all the userspace stuff, unless you have almost nothing starting on system boot.

Damn I feel foolish, to be honest I didn't pay attention to the timestamps.

I'll take a more meticulous look at those times. I took the time with my cellphone since I click the Arch entry in my grub, till GDM is shown, I paused and enter my pass, then continue the timer and stops again until Cinnamon desktp shows, and I get 24seconds, Is that a really slow time for a SSD? Btw, Yeah I have pretty much nothing set up on start, It's a fresh set up, just GDM and Cinnamon desktop.

Here's my systemd-analyze critical-chain

Startup finished in 13.651s (kernel) + 609ms (userspace) = 14.260s

graphical.target @609ms
└─gdm.service @567ms +40ms
  └─systemd-user-sessions.service @563ms +3ms
    └─network.target @562ms
      └─systemd-networkd.service @533ms +28ms
        └─dbus.service @498ms
          └─basic.target @497ms
            └─sockets.target @497ms
              └─dbus.socket @497ms
                └─sysinit.target @495ms
                  └─systemd-update-utmp.service @486ms +7ms
                    └─systemd-tmpfiles-setup.service @476ms +8ms
                      └─local-fs.target @475ms
                        └─home.mount @469ms +6ms
                          └─systemd-fsck@dev-disk-by\x2duuid-16180add\x2d1578\x2d4287\x2d919a\x2de1a73aa88e0c.service @402ms +43ms
                            └─dev-disk-by\x2duuid-16180add\x2d1578\x2d4287\x2d919a\x2de1a73aa88e0c.device @389ms

Thanks for your answear

Last edited by Franky (2016-06-10 17:04:09)

R00KIE · 2016-06-10 17:59:23

I'd say 24 seconds from grub to a fully blown DE is fine, specially if considering you are using an older machine and not doing any "special" optimizations to cut boot times.

Personally I have never bothered to optimize boot times as the time spent on bios/firmware initialization and grub is a large chunk of the time my machines take to boot. I can't provide right now numbers for an older laptop that broke down but with a new one (Thinkpad E560) it spends as much time on firmware initialization as it takes to get to a tty prompt (Startup finished in 9.903s (firmware) + 2.450s (loader) + 6.472s (kernel) + 1.418s (userspace) = 20.244s) and I have a good number of things starting with the system.

Franky · 2016-06-12 18:40:16

R00KIE wrote:

I'd say 24 seconds from grub to a fully blown DE is fine, specially if considering you are using an older machine and not doing any "special" optimizations to cut boot times.
Personally I have never bothered to optimize boot times as the time spent on bios/firmware initialization and grub is a large chunk of the time my machines take to boot. I can't provide right now numbers for an older laptop that broke down but with a new one (Thinkpad E560) it spends as much time on firmware initialization as it takes to get to a tty prompt (Startup finished in 9.903s (firmware) + 2.450s (loader) + 6.472s (kernel) + 1.418s (userspace) = 20.244s) and I have a good number of things starting with the system.

Hi Man, Sorry for the late reply, been kind of busy.

Yeah that's exactly what I have been thinking, I should consider the fact that my expected-boot-times are only reachable by a newer machine, I'm considering getting a new gig in the near future, but not right now, So for now like you said, my boot times are good for what I have.

But anyway, it seems like not much people care or know about the Sata-Pmp issue of past-amd chipsets.
For now your advice have left me pretty satisfied, Many Thanks for your time.
Now, how should I close the treath? I just put SOLVED on the title?

Last edited by Franky (2016-06-12 18:41:12)

R00KIE · 2016-06-12 18:56:02

You don't close the thread, you edit your first post and add [Solved] to the title [1]. Glad I could help

[1] https://wiki.archlinux.org/index.php/Co … ow_to_post

Arch Linux

#1 2016-06-10 07:43:22

[SOLVED] Kernel Sata PMP Support for AMD Chipset? Any News?

#2 2016-06-10 13:43:34

Re: [SOLVED] Kernel Sata PMP Support for AMD Chipset? Any News?

#3 2016-06-10 17:03:16

Re: [SOLVED] Kernel Sata PMP Support for AMD Chipset? Any News?

#4 2016-06-10 17:59:23

Re: [SOLVED] Kernel Sata PMP Support for AMD Chipset? Any News?

#5 2016-06-12 18:40:16

Re: [SOLVED] Kernel Sata PMP Support for AMD Chipset? Any News?

#6 2016-06-12 18:56:02

Re: [SOLVED] Kernel Sata PMP Support for AMD Chipset? Any News?

Board footer